[OE-core] [PATCH] sstate-cache-management: hide error message when one of possible layer location doesn't exist
* fixes [YOCTO #3116] Signed-off-by: Martin Jansa --- scripts/sstate-cache-management.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/sstate-cache-management.sh b/scripts/sstate-cache-management.sh index f519555..4c06fe8 100755 --- a/scripts/sstate-cache-management.sh +++ b/scripts/sstate-cache-management.sh @@ -174,7 +174,7 @@ remove_duplicated () { topdir=$(dirname $oe_core_dir) tunedirs="`find $topdir/meta* ${oe_core_dir}/meta* $layers -path '*/meta*/conf/machine/include'`" [ -n "$tunedirs" ] || echo_error "Can't find the tune directory" - all_machines="`find $topdir/meta* ${oe_core_dir}/meta* $layers -path '*/meta*/conf/machine/*' -name '*.conf' | sed -e 's/.*\///' -e 's/.conf$//'`" + all_machines="`find $topdir/meta* ${oe_core_dir}/meta* $layers -path '*/meta*/conf/machine/*' -name '*.conf' 2>/dev/null | sed -e 's/.*\///' -e 's/.conf$//'`" all_archs=`grep -r -h "^AVAILTUNES .*=" $tunedirs | sed -e 's/.*=//' -e 's/\"//g'` # Add the qemu and native archs # Use the "_" to substitute "-", e.g., x86-64 to x86_64 -- 1.7.12 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] autotools.bbclass: using relative paths for acpaths
From: Wenzong Fan Fix autotools.bbclass to use relative paths for acpaths instead of absolute ones. Since absolute paths may cause potential autoreconf error like: Can't exec "/bin/sh": Argument list too long ... This error occurs while building coreutils with long TMPDIR, because it has bunch of m4 files need to be expanded. [YOCTO #2766] The following changes since commit 0b09e50810162a07ef0aecee91ee32b4a36334a3: busybox: Fix misplaced quote (2012-09-26 18:28:36 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib wenzong/2766 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/2766 Wenzong Fan (1): autotools.bbclass: using relative paths for acpaths meta/classes/autotools.bbclass |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] autotools.bbclass: using relative paths for acpaths
From: Wenzong Fan Fix autotools.bbclass to use relative paths for acpaths instead of absolute ones. Since absolute paths may cause potential autoreconf error like: Can't exec "/bin/sh": Argument list too long ... This error occurs while building coreutils with long TMPDIR, because it has bunch of m4 files need to be expanded. [YOCTO #2766] Signed-off-by: Wenzong Fan --- meta/classes/autotools.bbclass |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass index e4e034b..874e01d 100644 --- a/meta/classes/autotools.bbclass +++ b/meta/classes/autotools.bbclass @@ -130,7 +130,8 @@ autotools_do_configure() { if [ x"${acpaths}" = xdefault ]; then acpaths= for i in `find ${S} -maxdepth 2 -name \*.m4|grep -v 'aclocal.m4'| \ - grep -v 'acinclude.m4' | sed -e 's,\(.*/\).*$,\1,'|sort -u`; do + grep -v 'acinclude.m4' | sed -e 's,\(.*/\).*$,\1,'|sort -u| \ + sed -e 's,${S},\.,'`; do acpaths="$acpaths -I $i" done else -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote: > On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote: > > * bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE > > * this way xscale or arm926ejs is not used by default when some machine > > includes its tune*.inc, but it's easy for DISTRO to say it wants > > OPTDEFAULTTUNE for some packages or always (if they don't want to > > share built packages between xscale and arm926ejs). > > > > Signed-off-by: Martin Jansa > > --- > > meta/conf/bitbake.conf | 1 + > > meta/conf/machine/include/tune-arm926ejs.inc | 3 ++- > > meta/conf/machine/include/tune-xscale.inc| 3 ++- > > 3 files changed, 5 insertions(+), 2 deletions(-) > > > > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf > > index 9b41749..e433fcb 100644 > > --- a/meta/conf/bitbake.conf > > +++ b/meta/conf/bitbake.conf > > @@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}" > > HOST_AS_ARCH = "${TARGET_AS_ARCH}" > > HOST_EXEEXT = "" > > > > +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}" > > TUNE_ARCH ??= "INVALID" > > TUNE_CCARGS ??= "" > > TUNE_LDARGS ??= "" > > As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage > or in meaning and we need to find a better solution. I'm therefore not > keen on this change. OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use different PKGARCH for different TUNE_CCARGS? > I also still think this is a distro packaging issue and should be solved > by the distro, even if that means more complexity there. That is the > right place for this particular complexity IMO. I'm happy to support > that from the core but not in something as user visible and confusing as > this variable. Agreed OPTDEFAULTTUNE is to help distro configs, because complexity there will be much worse then when it's defined in tune-* files, because now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or TUNE_FEATURE) it supports and it's less orthogonal (machine/distro config) then it could be. Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gnome-keyring: include unpackaged files with PAM enabled
Include missing files/dirs: ${base_libdir}/security/*.la ${base_libdir}/security/*${SOLIBSDEV} ${base_libdir}/security/.debug/ [YOCTO #2805] Signed-off-by: Constantin Musca --- meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb |9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb b/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb index d822721..92e0e1b 100644 --- a/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb +++ b/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb @@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \ SECTION = "x11/gnome" -PR = "r9" +PR = "r10" inherit autotools gnome gtk-doc pkgconfig @@ -43,7 +43,10 @@ FILES_${PN} += "${datadir}/dbus-1/services ${datadir}/gcr" FILES_${PN}-dev += "${libdir}/${BPN}/devel/*.la \ ${libdir}/${BPN}/devel/*${SOLIBSDEV} \ -${libdir}/${BPN}/standalone/*.la" +${libdir}/${BPN}/standalone/*.la \ +${base_libdir}/security/*.la \ +${base_libdir}/security/*${SOLIBSDEV}" FILES_${PN}-dbg += "${libdir}/${BPN}/standalone/.debug/ \ -${libdir}/${BPN}/devel/.debug/" +${libdir}/${BPN}/devel/.debug/ \ +${base_libdir}/security/.debug/" -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gdk-pixbuf: Use qemu to run postinsts in offline root mode
On Wed, 2012-09-26 at 13:28 +0100, Phil Blundell wrote: > On Wed, 2012-09-26 at 14:23 +0200, Martin Jansa wrote: > > On Wed, Sep 26, 2012 at 01:11:44PM +0100, Phil Blundell wrote: > > > This makes it possible to use gdk-pixbuf on a read-only rootfs. > > > > Isn't this issue resolved in "[RFC 0/7] Postinstall improvements" too? > > Ah, possibly. I haven't really been following that thread. I'll take a > look. I found the patch that I guess you were referring to: http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/029913.html Personally I don't like that solution so much; the reliance on NATIVE_ROOT containing the appropriate bits seems a bit fragile. But I suppose it's a matter of opinion. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] perl-nativesdk interesting fail in do_install
On 2012-09-24 12:28, Marcin Juszkiewicz wrote: > I want to build 'meta-toolchain' but on my Ubuntu 12.10 it fails on > 'nativesdk-perl' recipe in do_install: > > | > /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/perl/5.14.2/pod/perlxstut.pod > | > /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/perl/5.14.2/pod/a2p.pod > | > | Warning: perl appears in your path in the following locations beyond where > | we just installed it: > | > /home/hrw/HDD/devel/canonical/ci-linaro/oecore/build/tmp-eglibc/sysroots/x86_64-linux/usr/bin/perl-native/perl > | /usr/bin/perl > | > | make[1]: Nothing to be done for `install.man'. > | make[1]: Leaving directory > `/home/hrw/HDD/devel/canonical/ci-linaro/oecore/build/tmp-eglibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-perl-5.14.2-r9/perl-5.14.2' > | > /home/hrw/HDD/devel/canonical/ci-linaro/oecore/build/tmp-eglibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-perl-5.14.2-r9/image > /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin > | ln: failed to create symbolic link > `/home/hrw/HDD/devel/canonical/ci-linaro/oecore/build/tmp-eglibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-perl-5.14.2-r9/image/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/perl': > No such file or directory > | ERROR: Function failed: do_install (see > /home/hrw/HDD/devel/canonical/ci-linaro/oecore/build/tmp-eglibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-perl-5.14.2-r9/temp/log.do_install.24991 > for further information) > ERROR: Task 2 > (virtual:nativesdk:/home/hrw/HDD/devel/canonical/ci-linaro/oecore/openembedded-core/meta/recipes-devtools/perl/perl_5.14.2.bb, > do_install) failed with exit code '1' > > Perl is installed as /home/hrw/HDD/devel/canonical/ci-linaro/ \ > oecore/build/tmp-eglibc/work/x86_64-nativesdk-oesdk-linux/ \ > nativesdk-perl-5.14.2-r9/image/ \ > usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/ \ > usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/ \ > usr/bin/perl > > Note repeated "/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux" in > path. > > Any idea how it happened? Did someone built 'meta-toolchain' recently? I'm having the same error at the moment. I suppose commit 38234f2e276356b1d77a87ceabc486107e336d19 was meant to fix the issue, but it doesn't. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] eglibc: Remove bogus PACKAGES_DYNAMIC setting
It transpires that eglibc has been setting PACKAGES_DYNAMIC = "libc6*" for some time. However, this is bogus for at least two reasons: 1. Bitbake interprets PACKAGES_DYNAMIC as a regex, not a glob, so this will match against any package whose name starts "libc" plus zero or more sixes. This is particularly toxic because the nativesdk variant picks up the same value and will, consequently, start trying to build itself at the slightest excuse. 2. eglibc doesn't actually build any packages named "libc6", other than the ones that are named in PACKAGES anyway, so the dynamic provider declaration is in any case useless. Simply deleting the line is not sufficient since then we get the default value from bitbake.conf which causes eglibc.bb to fight with eglibc-locale.bb. So instead we must set it to the empty string for good results. Signed-off-by: Phil Blundell --- meta/recipes-core/eglibc/eglibc_2.16.bb |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/recipes-core/eglibc/eglibc_2.16.bb b/meta/recipes-core/eglibc/eglibc_2.16.bb index 3a7ae50..b37922d 100644 --- a/meta/recipes-core/eglibc/eglibc_2.16.bb +++ b/meta/recipes-core/eglibc/eglibc_2.16.bb @@ -43,7 +43,8 @@ SRC_URI_append_virtclass-nativesdk = " file://ld-search-order.patch \ S = "${WORKDIR}/${EGLIBC_BRANCH}/libc" B = "${WORKDIR}/build-${TARGET_SYS}" -PACKAGES_DYNAMIC = "libc6*" +PACKAGES_DYNAMIC = "" + RPROVIDES_${PN}-dev = "libc6-dev virtual-libc-dev" PROVIDES_${PN}-dbg = "glibc-dbg" -- 1.7.10.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] perl: Fix nativesdk install path
Commit 38234f2e276356b1d77a87ceabc486107e336d19 tried to fix the sed expressions by anchoring the left side of the search regexp to prevent $prefix$prefix type expression in the perl config. For nativesdk this is not enough. Adding anchors on both side fixes this. Signed-off-by: Christian Glindkamp --- This is currently only build tested, but buildhistory for perl did not change. meta/recipes-devtools/perl/perl_5.14.2.bb |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/meta/recipes-devtools/perl/perl_5.14.2.bb b/meta/recipes-devtools/perl/perl_5.14.2.bb index 3c1360f..0009855 100644 --- a/meta/recipes-devtools/perl/perl_5.14.2.bb +++ b/meta/recipes-devtools/perl/perl_5.14.2.bb @@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = "file://Copying;md5=2b4c6ffbcfcbdee469f02565f253d81a \ # We need gnugrep (for -I) DEPENDS = "virtual/db grep-native" DEPENDS += "gdbm zlib" -PR = "r9" +PR = "r10" # 5.10.1 has Module::Build built-in PROVIDES += "libmodule-build-perl" @@ -150,9 +150,9 @@ do_configure() { -e 's,@ARCH@-thread-multi,,g' \ -e 's,@ARCH@,${TARGET_ARCH}-${TARGET_OS},g' \ -e 's,@STAGINGDIR@,${STAGING_DIR_HOST},g' \ - -e "s%\([ \"^\',=]\+\)/usr/include%\1${STAGING_INCDIR}%g" \ - -e "s%\([ \"^\',=]\+\)/usr/lib/%\1${libdir}/%g" \ - -e "s%\([ \"^\',=]\+\)/usr/%\1${exec_prefix}/%g" \ + -e "s%\([ \"^\',=]\+\)/usr/include\([ \"^\',=]\+\)%\1${STAGING_INCDIR}\2%g" \ + -e "s%\([ \"^\',=]\+\)/usr/lib/\([ \"^\',=]\+\)%\1${libdir}/\2%g" \ + -e "s%\([ \"^\',=]\+\)/usr/\([ \"^\',=]\+\)%\1${exec_prefix}/\2%g" \ -e "s%/perl5%/perl%g" \ config.sh-${TARGET_ARCH}-${TARGET_OS} -- 1.7.2.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] overuse of bitbake flags considered harmful
I was mildly amused to discover, the other day, that the output of "bitbake -e rpm | grep PACKAGECONFIG" is not quite as one might naïvely expect. I guess the right response to this is perhaps that bitbake ought nowadays to find some other way to store its own internal state, since the idiom of using flags is pretty well established in oe-core. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] siteinfo.bbclass: add AArch64 support
Signed-off-by: Marcin Juszkiewicz --- meta/classes/siteinfo.bbclass |2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/classes/siteinfo.bbclass b/meta/classes/siteinfo.bbclass index 8c256ce..aab0867 100644 --- a/meta/classes/siteinfo.bbclass +++ b/meta/classes/siteinfo.bbclass @@ -18,6 +18,7 @@ def siteinfo_data(d): archinfo = { "allarch": "endian-little bit-32", # bogus, but better than special-casing the checks below for allarch +"aarch64": "endian-little bit-64 arm-common", "arm": "endian-little bit-32 arm-common", "armeb": "endian-big bit-32 arm-common", "avr32": "endian-big bit-32 avr32-common", @@ -60,6 +61,7 @@ def siteinfo_data(d): "mingw32": "common-mingw", } targetinfo = { +"aarch64-linux-gnu": "aarch64-linux", "arm-linux-gnueabi": "arm-linux", "arm-linux-uclibceabi": "arm-linux-uclibc", "armeb-linux-gnueabi": "armeb-linux", -- 1.7.10.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Add AArch64 support into OE-Core
This patchset adds support for AArch64 in all required classes: - insane - kernel-arch - siteinfo Everything is from public available information (binutils, linux). ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] kernel-arch.bblass: add AArch64 support
Signed-off-by: Marcin Juszkiewicz --- meta/classes/kernel-arch.bbclass |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel-arch.bbclass index 6446504..b3b78b6 100644 --- a/meta/classes/kernel-arch.bbclass +++ b/meta/classes/kernel-arch.bbclass @@ -8,7 +8,7 @@ valid_archs = "alpha cris ia64 \ i386 x86 \ m68knommu m68k ppc powerpc powerpc64 ppc64 \ sparc sparc64 \ - arm \ + arm aarch64 \ m32r mips \ sh sh64 um h8300 \ parisc s390 v850 \ @@ -22,6 +22,7 @@ def map_kernel_arch(a, d): if re.match('(i.86|athlon|x86.64)$', a): return 'x86' elif re.match('armeb$', a): return 'arm' +elif re.match('aarch64$', a): return 'arm64' elif re.match('mips(el|64|64el)$', a): return 'mips' elif re.match('p(pc|owerpc)(|64)', a): return 'powerpc' elif re.match('sh(3|4)$', a): return 'sh' -- 1.7.10.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] insane.bbclass: add AArch64 support
Signed-off-by: Marcin Juszkiewicz --- meta/classes/insane.bbclass |1 + 1 file changed, 1 insertion(+) diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass index 1fb8970..b390242 100644 --- a/meta/classes/insane.bbclass +++ b/meta/classes/insane.bbclass @@ -44,6 +44,7 @@ def package_qa_get_machine_dict(): "arm" : (40, 0,0, True, 32), }, "linux" : { +"aarch64" : (183,0,0, True, 64), "arm" : (40,97,0, True, 32), "armeb": (40,97,0, False, 32), "powerpc":(20, 0,0, False, 32), -- 1.7.10.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] sanity.bbclass: bblayers.conf should be updated automatically
- add check_bblayers_conf bitbake function which does the bblayers.conf v4 -> v5 update if necessary (every layer should make its specific bblayers.conf upgrades appending to the check_bblayers_conf function) - we ask the user to re-run bitbake because we can't trigger reparsing without being invasive [YOCTO #3082] Signed-off-by: Constantin Musca --- meta/classes/sanity.bbclass | 61 ++- 1 file changed, 60 insertions(+), 1 deletion(-) diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass index 385d733..9c3ab1f 100644 --- a/meta/classes/sanity.bbclass +++ b/meta/classes/sanity.bbclass @@ -4,6 +4,56 @@ SANITY_REQUIRED_UTILITIES ?= "patch diffstat makeinfo git bzip2 tar gzip gawk chrpath wget cpio" +python check_bblayers_conf() { +bblayers_fn = os.path.join(d.getVar('TOPDIR', True), 'conf/bblayers.conf') + +current_lconf = int(d.getVar('LCONF_VERSION', True)) +if not current_lconf: +sys.exit() +lconf_version = int(d.getVar('LAYER_CONF_VERSION', True)) +lines = [] + +import re +def find_line(pattern, lines): +return next(((index, line) +for index, line in enumerate(lines) +if re.search(pattern, line)), (None, None)) + +if current_lconf < 4: +sys.exit() + +with open(bblayers_fn, 'r') as f: +lines = f.readlines() + +if current_lconf == 4: +topdir_var = '$' + '{TOPDIR}' +index, bbpath_line = find_line('BBPATH', lines) +if bbpath_line: +start = bbpath_line.find('"') +if start != -1 and (len(bbpath_line) != (start + 1)): +if bbpath_line[start + 1] == '"': +lines[index] = (bbpath_line[:start + 1] + +topdir_var + bbpath_line[start + 1:]) +else: +if not topdir_var in bbpath_line: +lines[index] = (bbpath_line[:start + 1] + +topdir_var + ':' + bbpath_line[start + 1:]) +else: +sys.exit() +else: +index, bbfiles_line = find_line('BBFILES', lines) +if bbfiles_line: +lines.insert(index, 'BBPATH = "' + topdir_var + '"\n') +else: +sys.exit() + +index, line = find_line('LCONF_VERSION', lines) +current_lconf += 1 +lines[index] = 'LCONF_VERSION = "%d"\n' % current_lconf +with open(bblayers_fn, "w") as f: +f.write(''.join(lines)) +} + def raise_sanity_error(msg, d): if d.getVar("SANITY_USE_EVENTS", True) == "1": bb.event.fire(bb.event.SanityCheckFailed(msg), d) @@ -337,7 +387,16 @@ def check_sanity(sanity_data): current_lconf = sanity_data.getVar('LCONF_VERSION', True) lconf_version = sanity_data.getVar('LAYER_CONF_VERSION', True) if current_lconf != lconf_version: -messages = messages + "Your version of bblayers.conf was generated from an older version of bblayers.conf.sample and there have been updates made to this file. Please compare the two files and merge any changes before continuing.\nMatching the version numbers will remove this message.\n\"meld conf/bblayers.conf ${COREBASE}/meta*/conf/bblayers.conf.sample\" is a good way to visualise the changes.\n" +try: +bb.build.exec_func("check_bblayers_conf", sanity_data) +if sanity_data.getVar("SANITY_USE_EVENTS", True) == "1": +bb.event.fire(bb.event.SanityCheckFailed("Your conf/bblayers.conf has been automatically updated. Please close and re-run."), sanity_data) +return +else: +bb.note("Your conf/bblayers.conf has been automatically updated. Please re-run %s." % os.path.basename(sys.argv[0])) +sys.exit(0) +except Exception: +messages = messages + "Your version of bblayers.conf was generated from an older version of bblayers.conf.sample and there have been updates made to this file. Please compare the two files and merge any changes before continuing.\nMatching the version numbers will remove this message.\n\"meld conf/bblayers.conf ${COREBASE}/meta*/conf/bblayers.conf.sample\" is a good way to visualise the changes.\n" # If we have a site.conf, check it's valid if check_conf_exists("conf/site.conf", sanity_data): -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] cml1.bbclass: Convert tab indentation in python functions into four-space
Based on the previous commit 604d46c686d06d62d5a07b9c7f4fa170f99307d8 (Convert tab indentation in python functions into four-space), the cml.bbclass was not converted, and in order to properly extend it with external bbappend's it needs to be converted. Signed-off-by: Jason Wessel --- meta/classes/cml1.bbclass | 28 ++-- 1 files changed, 14 insertions(+), 14 deletions(-) diff --git a/meta/classes/cml1.bbclass b/meta/classes/cml1.bbclass index 37ed792..ba44196 100644 --- a/meta/classes/cml1.bbclass +++ b/meta/classes/cml1.bbclass @@ -15,23 +15,23 @@ HOSTLDFLAGS = "${BUILD_LDFLAGS}" HOST_LOADLIBES = "-lncurses" python do_menuconfig() { -try: -mtime = os.path.getmtime(".config") -except OSError: -mtime = 0 +try: +mtime = os.path.getmtime(".config") +except OSError: +mtime = 0 -oe_terminal("${SHELL} -c \"make menuconfig; if [ $? -ne 0 ]; then echo 'Command failed.'; printf 'Press any key to continue... '; read r; fi\"", '${PN} Configuration', d) +oe_terminal("${SHELL} -c \"make menuconfig; if [ $? -ne 0 ]; then echo 'Command failed.'; printf 'Press any key to continue... '; read r; fi\"", '${PN} Configuration', d) -# FIXME this check can be removed when the minimum bitbake version has been bumped -if hasattr(bb.build, 'write_taint'): -try: -newmtime = os.path.getmtime(".config") -except OSError: -newmtime = 0 +# FIXME this check can be removed when the minimum bitbake version has been bumped +if hasattr(bb.build, 'write_taint'): +try: +newmtime = os.path.getmtime(".config") +except OSError: +newmtime = 0 -if newmtime > mtime: -bb.note("Configuration changed, recompile will be forced") -bb.build.write_taint('do_compile', d) +if newmtime > mtime: +bb.note("Configuration changed, recompile will be forced") +bb.build.write_taint('do_compile', d) } do_menuconfig[depends] += "ncurses-native:do_populate_sysroot" do_menuconfig[nostamp] = "1" -- 1.7.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] jpeg-native: Do not use libtool-cross for native recipe
On Wed, Sep 26, 2012 at 6:59 AM, Richard Purdie wrote: > On Tue, 2012-09-25 at 06:27 -0700, Khem Raj wrote: >> On Tue, Sep 25, 2012 at 1:14 AM, Richard Purdie >> wrote: >> > This wallpapers over cracks. Why is libtool-native/libtool-cross broken? >> > Shouldn't we fix whatever is breaking libtool? >> > >> >> it is not broken. But we were ending up using cross-libtool for native >> recipe that does not seem right. > > Looking at your original error message, it says: > > /work/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/bin/x86_64-linux-libtool > > which is libtool-native. I appreciate that the OEMAKE line to use the > cross version is wrong but it looks like it still manages to find the > native libtool and that it isn't working. hmmm I tried and it worked fine when libtool-cross was staged. I guess my problem was that it was trying to find native sed in native sysroot. I cant reproduce it. But I guess the patch still makes sense. I can send it with commit message changed if you are ok with that > > Cheers, > > Richard > > ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] initramfs: Make mkdir not fail
From: Damien Lespiau This patch make "mkdir foo" not fail if foo already exists. Signed-off-by: Damien Lespiau Signed-off-by: Ross Burton --- meta/recipes-core/initrdscripts/files/init-live.sh |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/meta/recipes-core/initrdscripts/files/init-live.sh b/meta/recipes-core/initrdscripts/files/init-live.sh index fb7af31..2639308 100644 --- a/meta/recipes-core/initrdscripts/files/init-live.sh +++ b/meta/recipes-core/initrdscripts/files/init-live.sh @@ -21,15 +21,15 @@ ISOLINUX="" UNIONFS="no" early_setup() { -mkdir /proc -mkdir /sys +mkdir -p /proc +mkdir -p /sys mount -t proc proc /proc mount -t sysfs sysfs /sys # support modular kernel modprobe isofs 2> /dev/null -mkdir /run +mkdir -p /run udevd --daemon udevadm trigger --action=add } -- 1.7.10 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] initrd: Spawn an emergency shell when something goes wrong
From: Damien Lespiau set -e allows to exit if a command fails. We install a trap and execute emergency_shell() when either the init script exits or when ctrl-c is typed (say if we are stuck somewhere and we want to debug it). Signed-off-by: Damien Lespiau Signed-off-by: Ross Burton --- meta/recipes-core/initrdscripts/files/init-live.sh | 11 +++ 1 file changed, 11 insertions(+) diff --git a/meta/recipes-core/initrdscripts/files/init-live.sh b/meta/recipes-core/initrdscripts/files/init-live.sh index 3fba7dc..fb7af31 100644 --- a/meta/recipes-core/initrdscripts/files/init-live.sh +++ b/meta/recipes-core/initrdscripts/files/init-live.sh @@ -2,6 +2,17 @@ PATH=/sbin:/bin:/usr/sbin:/usr/bin +emergency_shell() +{ +echo "Bug in initramfs /init detected. Dropping to a shell. Good luck!" +echo +sh +} +trap "emergency_shell" 0 2 + +# exit immediately if a command fails +set -e + ROOT_MOUNT="/rootfs/" ROOT_IMAGE="rootfs.img" MOUNT="/bin/mount" -- 1.7.10 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2] initramfs fixes
A colleague was working on an initramfs-based yocto system and encounting some issues because the initial script is quite fragile. Attached are two patches to make it less fragile, and drop you to a shell if it does break. The following changes since commit 55b3e7bf48a67c0ce42308b8332262fbe4eccd24: dbus: disable all X11 when native (2012-09-26 21:23:37 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib ross/initramfs for you to fetch changes up to 265e1e50186d5982b40d87f37f0662a0e09a7daa: initramfs: Make mkdir not fail (2012-09-27 15:17:35 +0100) Damien Lespiau (2): initrd: Spawn an emergency shell when something goes wrong initramfs: Make mkdir not fail meta/recipes-core/initrdscripts/files/init-live.sh | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) Damien Lespiau (2): initrd: Spawn an emergency shell when something goes wrong initramfs: Make mkdir not fail meta/recipes-core/initrdscripts/files/init-live.sh | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) -- 1.7.10 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Fail in perl-native_5.14.2.bb
Hello, peace be with thee... :) I found a mistake in the "do_configure()" function of: "perl-native_5.14.2.bb" I am not experienced enough with mailing list to produce patches, but i will try... Explanation: sed is in " -e "s%/perl5%/perl%g" \ " replacing parts of @DESTDIR@ which makes its patch way to long and doubles up parts of it's folders... This patch works for me... Index: perl/perl_5.14.2.bb === --- perl.orig/perl_5.14.2.bb +++ perl/perl_5.14.2.bb @@ -146,14 +146,14 @@ do_configure() { ${@base_contains('DISTRO_FEATURES', 'largefile', '', 'do_nolargefile', d)} # Update some paths in the configuration -sed -i -e 's,@DESTDIR@,${prefix},g' \ - -e 's,@ARCH@-thread-multi,,g' \ +sed -i -e 's,@ARCH@-thread-multi,,g' \ -e 's,@ARCH@,${TARGET_ARCH}-${TARGET_OS},g' \ -e 's,@STAGINGDIR@,${STAGING_DIR_HOST},g' \ -e "s%\([ \"^\',=]\+\)/usr/include%\1${STAGING_INCDIR}%g" \ -e "s%\([ \"^\',=]\+\)/usr/lib/%\1${libdir}/%g" \ -e "s%\([ \"^\',=]\+\)/usr/%\1${exec_prefix}/%g" \ -e "s%/perl5%/perl%g" \ + -e 's,@DESTDIR@,${prefix},g' \ config.sh-${TARGET_ARCH}-${TARGET_OS} case "${TARGET_ARCH}" in ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH 00/10] qt4: upgrade to 4.8.3 and cleanup
On Thursday 27 September 2012 00:27:05 Martin Jansa wrote: > Please test on more architectures. > I've tested complete qt4-native + qt4-free-x11 on armv4t. > And only do_patch for nativesdk-qt4-tools, qt-mobility-*, qt4-embedded. So this is great work and these patches look good, although I'm still not particularly happy with breaking out so many of the configure options because I'm convinced it won't stop here; but it's possible I might be overruled on this issue. The bigger problem is when these patches are arriving - we're late into the stabilisation period and given the choice I'd prefer not to merge them until the next development cycle. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] jpeg-native: Do not use libtool-cross for native recipe
On Thu, 2012-09-27 at 07:14 -0700, Khem Raj wrote: > On Wed, Sep 26, 2012 at 6:59 AM, Richard Purdie > wrote: > > On Tue, 2012-09-25 at 06:27 -0700, Khem Raj wrote: > >> On Tue, Sep 25, 2012 at 1:14 AM, Richard Purdie > >> wrote: > >> > This wallpapers over cracks. Why is libtool-native/libtool-cross broken? > >> > Shouldn't we fix whatever is breaking libtool? > >> > > >> > >> it is not broken. But we were ending up using cross-libtool for native > >> recipe that does not seem right. > > > > Looking at your original error message, it says: > > > > > > /work/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/bin/x86_64-linux-libtool > > > > which is libtool-native. I appreciate that the OEMAKE line to use the > > cross version is wrong but it looks like it still manages to find the > > native libtool and that it isn't working. > > hmmm I tried and it worked fine when libtool-cross was staged. I guess > my problem was > that it was trying to find native sed in native sysroot. I cant > reproduce it. But I guess > the patch still makes sense. I can send it with commit message changed > if you are ok with that I'm not really. I'd like to understand what the problem is we're fixing before I take patches. We don't understand what is wrong here. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] overuse of bitbake flags considered harmful
On Thu, 2012-09-27 at 13:22 +0100, Phil Blundell wrote: > I was mildly amused to discover, the other day, that the output of > "bitbake -e rpm | grep PACKAGECONFIG" is not quite as one might naïvely > expect. > > I guess the right response to this is perhaps that bitbake ought > nowadays to find some other way to store its own internal state, since > the idiom of using flags is pretty well established in oe-core. For those who don't realise what's going on here, the output is: python PACKAGECONFIG () { db bzip2 zlib beecrypt openssl libelf python} since "python" is a flag bitbake uses to identify python functions too. I suspect the better solution would be to use "_python" internally since we already have a convention within bitbake of prefixing internally used flags with "_". http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake/lib/bb/data_smart.py?id=49bc007c80e429090c4db51e30c5ce27e8a72558 http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake/lib/bb/data_smart.py?id=980d658f3f1e6c5b459f741385533a11d35009ca This would mean the metadata shouldn't use that namespace but I think we can live with that. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] perl: Fix nativesdk install path
On 09/27/2012 05:20 AM, Christian Glindkamp wrote: Commit 38234f2e276356b1d77a87ceabc486107e336d19 tried to fix the sed expressions by anchoring the left side of the search regexp to prevent $prefix$prefix type expression in the perl config. For nativesdk this is not enough. Adding anchors on both side fixes this. Signed-off-by: Christian Glindkamp --- This is currently only build tested, but buildhistory for perl did not change. meta/recipes-devtools/perl/perl_5.14.2.bb |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/meta/recipes-devtools/perl/perl_5.14.2.bb b/meta/recipes-devtools/perl/perl_5.14.2.bb index 3c1360f..0009855 100644 --- a/meta/recipes-devtools/perl/perl_5.14.2.bb +++ b/meta/recipes-devtools/perl/perl_5.14.2.bb @@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = "file://Copying;md5=2b4c6ffbcfcbdee469f02565f253d81a \ # We need gnugrep (for -I) DEPENDS = "virtual/db grep-native" DEPENDS += "gdbm zlib" -PR = "r9" +PR = "r10" # 5.10.1 has Module::Build built-in PROVIDES += "libmodule-build-perl" @@ -150,9 +150,9 @@ do_configure() { -e 's,@ARCH@-thread-multi,,g' \ -e 's,@ARCH@,${TARGET_ARCH}-${TARGET_OS},g' \ -e 's,@STAGINGDIR@,${STAGING_DIR_HOST},g' \ - -e "s%\([ \"^\',=]\+\)/usr/include%\1${STAGING_INCDIR}%g" \ - -e "s%\([ \"^\',=]\+\)/usr/lib/%\1${libdir}/%g" \ - -e "s%\([ \"^\',=]\+\)/usr/%\1${exec_prefix}/%g" \ + -e "s%\([ \"^\',=]\+\)/usr/include\([ \"^\',=]\+\)%\1${STAGING_INCDIR}\2%g" \ + -e "s%\([ \"^\',=]\+\)/usr/lib/\([ \"^\',=]\+\)%\1${libdir}/\2%g" \ + -e "s%\([ \"^\',=]\+\)/usr/\([ \"^\',=]\+\)%\1${exec_prefix}/\2%g" \ -e "s%/perl5%/perl%g" \ config.sh-${TARGET_ARCH}-${TARGET_OS} Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] dbus: disable all X11 when native
On 09/26/2012 01:25 PM, Ross Burton wrote: Without --without-x the X11 detection would still go ahead and find the host X11 headers, which seems to cause problems at link time. Signed-off-by: Ross Burton --- meta/recipes-core/dbus/dbus.inc |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc index 5c99e11..550eb0a 100644 --- a/meta/recipes-core/dbus/dbus.inc +++ b/meta/recipes-core/dbus/dbus.inc @@ -10,7 +10,7 @@ DEPENDS = "expat virtual/libintl ${@base_contains('DISTRO_FEATURES', 'x11', '${X DEPENDS_virtclass-native = "expat-native virtual/libintl-native" DEPENDS_virtclass-nativesdk = "nativesdk-expat virtual/nativesdk-libintl virtual/libx11" -INC_PR = "r4" +INC_PR = "r5" SRC_URI = "http://dbus.freedesktop.org/releases/dbus/dbus-${PV}.tar.gz \ file://tmpdir.patch; \ @@ -64,7 +64,7 @@ pkg_postinst_dbus() { } EXTRA_OECONF_X = "${@base_contains('DISTRO_FEATURES', 'x11', '--with-x', '--without-x', d)}" -EXTRA_OECONF_X_virtclass-native = "--disable-x11-autolaunch" +EXTRA_OECONF_X_virtclass-native = "--without-x --disable-x11-autolaunch" EXTRA_OECONF = "--disable-tests \ --disable-checks \ Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-commits] Martin Jansa : xserver-xorg: use EXTENDPKGV instead of PV in RCONFLICTS_${PN}-module-exa
On Thu, Sep 27, 2012 at 02:29:25PM +, g...@git.openembedded.org wrote: > Module: openembedded-core.git > Branch: master > Commit: ed0216d29fc4355c5220f3ad51df04a63cacb0c3 > URL: > http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=ed0216d29fc4355c5220f3ad51df04a63cacb0c3 > > Author: Martin Jansa > Date: Sat Sep 22 19:13:14 2012 +0200 > > xserver-xorg: use EXTENDPKGV instead of PV in RCONFLICTS_${PN}-module-exa > > * it doesn't make much sense with PV, because xserver-xorg-module-exa > was introduced in > > http://git.openembedded.org/openembedded-core/commit/meta/recipes-graphics/xorg-xserver?id=1a666ee1cda3c0b74daba5881fc5f62e13deec66 > so our xserver-xorg-module-exa RCONFLICTS with xserver-xorg (<= 1.11.2-r4) > and (< 1.11.2) is not good enough > > * because we don't know how many PRINC are in BSP/DISTRO layers, > then it's safer to RCONFLICTS with every older version then current > EXTENDPKGV > > Also fixes whitespace to work correctly with opkg The whitespace problem wasn't opkg fault AFAIK, but bb.utils.explode_dep_versions as shown in http://patchwork.openembedded.org/patch/37069/ Cheers > > Signed-off-by: Martin Jansa > > -- > > * I haven't really tested this with IPK, since it was changed from > RREPLACES to RCONFLICTS (because of RPM) and all my installed devices > are already upgraded > Signed-off-by: Richard Purdie > > --- > > .../recipes-graphics/xorg-xserver/xserver-xorg.inc |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc > b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc > index 643ca70..7513399 100644 > --- a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc > +++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc > @@ -66,7 +66,7 @@ PACKAGES =+ "${PN}-security-policy \ > > RRECOMMENDS_${PN} += "${PN}-security-policy xkeyboard-config rgb > xserver-xf86-config" > RDEPENDS_${PN}-xvfb += "xkeyboard-config" > -RCONFLICTS_${PN}-module-exa = "${PN} (<${PV})" > +RCONFLICTS_${PN}-module-exa = "${PN} (< ${EXTENDPKGV})" > > FILES_${PN} = "${bindir} ${libdir}/X11/Options ${libdir}/X11/Cards > ${libdir}/X11/getconfig ${libdir}/X11/etc ${libdir}/modules/*.so > ${libdir}/xorg/modules/*.so /etc/X11 ${libdir}/xorg/protocol.txt > ${datadir}/X11/xorg.conf.d" > FILES_${PN}-dev += "${libdir}/xorg/modules/*.la > ${libdir}/xorg/modules/*/*.la" > > > ___ > Openembedded-commits mailing list > openembedded-comm...@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-commits -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] eglibc: Remove bogus PACKAGES_DYNAMIC setting
On 09/27/2012 04:44 AM, Phil Blundell wrote: It transpires that eglibc has been setting PACKAGES_DYNAMIC = "libc6*" for some time. However, this is bogus for at least two reasons: 1. Bitbake interprets PACKAGES_DYNAMIC as a regex, not a glob, so this will match against any package whose name starts "libc" plus zero or more sixes. This is particularly toxic because the nativesdk variant picks up the same value and will, consequently, start trying to build itself at the slightest excuse. 2. eglibc doesn't actually build any packages named "libc6", other than the ones that are named in PACKAGES anyway, so the dynamic provider declaration is in any case useless. Simply deleting the line is not sufficient since then we get the default value from bitbake.conf which causes eglibc.bb to fight with eglibc-locale.bb. So instead we must set it to the empty string for good results. Signed-off-by: Phil Blundell --- meta/recipes-core/eglibc/eglibc_2.16.bb |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/recipes-core/eglibc/eglibc_2.16.bb b/meta/recipes-core/eglibc/eglibc_2.16.bb index 3a7ae50..b37922d 100644 --- a/meta/recipes-core/eglibc/eglibc_2.16.bb +++ b/meta/recipes-core/eglibc/eglibc_2.16.bb @@ -43,7 +43,8 @@ SRC_URI_append_virtclass-nativesdk = " file://ld-search-order.patch \ S = "${WORKDIR}/${EGLIBC_BRANCH}/libc" B = "${WORKDIR}/build-${TARGET_SYS}" -PACKAGES_DYNAMIC = "libc6*" +PACKAGES_DYNAMIC = "" + RPROVIDES_${PN}-dev = "libc6-dev virtual-libc-dev" PROVIDES_${PN}-dbg = "glibc-dbg" Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] cml1.bbclass: Convert tab indentation in python functions into four-space
On 09/27/2012 06:52 AM, Jason Wessel wrote: Based on the previous commit 604d46c686d06d62d5a07b9c7f4fa170f99307d8 (Convert tab indentation in python functions into four-space), the cml.bbclass was not converted, and in order to properly extend it with external bbappend's it needs to be converted. Signed-off-by: Jason Wessel --- meta/classes/cml1.bbclass | 28 ++-- 1 files changed, 14 insertions(+), 14 deletions(-) diff --git a/meta/classes/cml1.bbclass b/meta/classes/cml1.bbclass index 37ed792..ba44196 100644 --- a/meta/classes/cml1.bbclass +++ b/meta/classes/cml1.bbclass @@ -15,23 +15,23 @@ HOSTLDFLAGS = "${BUILD_LDFLAGS}" HOST_LOADLIBES = "-lncurses" python do_menuconfig() { -try: -mtime = os.path.getmtime(".config") -except OSError: -mtime = 0 +try: +mtime = os.path.getmtime(".config") +except OSError: +mtime = 0 -oe_terminal("${SHELL} -c \"make menuconfig; if [ $? -ne 0 ]; then echo 'Command failed.'; printf 'Press any key to continue... '; read r; fi\"", '${PN} Configuration', d) +oe_terminal("${SHELL} -c \"make menuconfig; if [ $? -ne 0 ]; then echo 'Command failed.'; printf 'Press any key to continue... '; read r; fi\"", '${PN} Configuration', d) -# FIXME this check can be removed when the minimum bitbake version has been bumped -if hasattr(bb.build, 'write_taint'): -try: -newmtime = os.path.getmtime(".config") -except OSError: -newmtime = 0 +# FIXME this check can be removed when the minimum bitbake version has been bumped +if hasattr(bb.build, 'write_taint'): +try: +newmtime = os.path.getmtime(".config") +except OSError: +newmtime = 0 -if newmtime > mtime: -bb.note("Configuration changed, recompile will be forced") -bb.build.write_taint('do_compile', d) +if newmtime > mtime: +bb.note("Configuration changed, recompile will be forced") +bb.build.write_taint('do_compile', d) } do_menuconfig[depends] += "ncurses-native:do_populate_sysroot" do_menuconfig[nostamp] = "1" Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] util-linux: Don't package chkdupexe
On 09/25/2012 06:04 AM, Phil Blundell wrote: The chkdupexe utility is fairly worthless and drags perl in as a build dependency of the whole util-linux recipe. If anybody actually wants to use this script then we should package it separately, but for the time being let's just delete it. Signed-off-by: Phil Blundell --- meta/recipes-core/util-linux/util-linux.inc |6 +++--- meta/recipes-core/util-linux/util-linux_2.21.2.bb |6 +- 2 files changed, 4 insertions(+), 8 deletions(-) diff --git a/meta/recipes-core/util-linux/util-linux.inc b/meta/recipes-core/util-linux/util-linux.inc index b2a1552..d62d406 100644 --- a/meta/recipes-core/util-linux/util-linux.inc +++ b/meta/recipes-core/util-linux/util-linux.inc @@ -31,7 +31,7 @@ PACKAGES =+ "util-linux-agetty util-linux-fdisk util-linux-cfdisk util-linux-sfd util-linux-mount util-linux-readprofile util-linux-libblkid \ util-linux-libblkid-dev util-linux-libuuid util-linux-libuuid-dev \ util-linux-uuidgen util-linux-lscpu util-linux-fsck util-linux-blkid \ - util-linux-chkdupexe util-linux-mkfs util-linux-mcookie" + util-linux-mkfs util-linux-mcookie" EXTRA_OECONF = "--libdir=${base_libdir} --disable-use-tty-group \ --disable-makeinstall-chown --enable-elvtune --enable-init \ @@ -63,7 +63,6 @@ FILES_util-linux-libuuid-dev = "${base_libdir}/libuuid.so ${base_libdir}/libuuid FILES_util-linux-lscpu = "${bindir}/lscpu" FILES_util-linux-fsck = "${base_sbindir}/fsck*" -FILES_util-linux-chkdupexe = "${bindir}/chkdupexe" FILES_util-linux-mkfs = "${sbindir}/mkfs" # Util-linux' blkid replaces the e2fsprogs one @@ -72,7 +71,6 @@ RCONFLICTS_util-linux-blkid = "e2fsprogs-blkid" RREPLACES_util-linux-blkid = "e2fsprogs-blkid" RDEPENDS_${PN} = "util-linux-umount util-linux-swaponoff util-linux-losetup" -RDEPENDS_${PN}-chkdupexe = "perl" RRECOMMENDS_${PN} = "util-linux-fdisk util-linux-cfdisk util-linux-sfdisk util-linux-mount util-linux-readprofile util-linux-mkfs " RRECOMMENDS_${PN}_virtclass-native = "" @@ -125,6 +123,8 @@ do_install () { ln -sf swapon.${BPN} ${D}${base_sbindir}/swapoff.${BPN} rm -f ${D}${sbindir}/swapoff + + rm -f ${D}${bindir}/chkdupexe } inherit update-alternatives diff --git a/meta/recipes-core/util-linux/util-linux_2.21.2.bb b/meta/recipes-core/util-linux/util-linux_2.21.2.bb index 792730c..39e3609 100644 --- a/meta/recipes-core/util-linux/util-linux_2.21.2.bb +++ b/meta/recipes-core/util-linux/util-linux_2.21.2.bb @@ -1,5 +1,5 @@ MAJOR_VERSION = "2.21" -PR = "r4" +PR = "r5" require util-linux.inc # note that `lscpu' is under GPLv3+ @@ -40,7 +40,3 @@ addtask remove_lscpu before do_configure after do_patch CACHED_CONFIGUREVARS += "scanf_cv_alloc_modifier=as" EXTRA_OECONF_virtclass-native += "--disable-fallocate --disable-use-tty-group" - -do_install_append () { - sed -i -e '1s,.*,#!${bindir}/env perl,' ${D}${bindir}/chkdupexe -} Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] util-linux: Remove static libraries from -dev packages
On 09/25/2012 05:54 AM, Phil Blundell wrote: Fixes the QA warnings: WARNING: QA Issue: non -staticdev package contains static .a library: util-linux-libblkid-dev path '/work/mips32el-oe-linux/util-linux/2.21.2-r3micro3/packages-split/util-linux-libblkid-dev/lib/libblkid.a' WARNING: QA Issue: non -staticdev package contains static .a library: util-linux-libuuid-dev path '/work/mips32el-oe-linux/util-linux/2.21.2-r3micro3/packages-split/util-linux-libuuid-dev/lib/libuuid.a' Signed-off-by: Phil Blundell --- meta/recipes-core/util-linux/util-linux.inc |4 ++-- meta/recipes-core/util-linux/util-linux_2.21.2.bb |2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/meta/recipes-core/util-linux/util-linux.inc b/meta/recipes-core/util-linux/util-linux.inc index 2c5267f..b2a1552 100644 --- a/meta/recipes-core/util-linux/util-linux.inc +++ b/meta/recipes-core/util-linux/util-linux.inc @@ -57,9 +57,9 @@ FILES_util-linux-readprofile = "${base_sbindir}/readprofile.${BPN}" FILES_util-linux-uuidgen = "${bindir}/uuidgen" FILES_util-linux-libblkid = "${base_libdir}/libblkid.so.*" -FILES_util-linux-libblkid-dev = "${base_libdir}/libblkid.so ${base_libdir}/libblkid.a ${base_libdir}/libblkid.la ${includedir}/blkid ${libdir}/pkgconfig/blkid.pc" +FILES_util-linux-libblkid-dev = "${base_libdir}/libblkid.so ${base_libdir}/libblkid.la ${includedir}/blkid ${libdir}/pkgconfig/blkid.pc" FILES_util-linux-libuuid = "${base_libdir}/libuuid.so.*" -FILES_util-linux-libuuid-dev = "${base_libdir}/libuuid.so ${base_libdir}/libuuid.a ${base_libdir}/libuuid.la ${includedir}/uuid ${libdir}/pkgconfig/uuid.pc" +FILES_util-linux-libuuid-dev = "${base_libdir}/libuuid.so ${base_libdir}/libuuid.la ${includedir}/uuid ${libdir}/pkgconfig/uuid.pc" FILES_util-linux-lscpu = "${bindir}/lscpu" FILES_util-linux-fsck = "${base_sbindir}/fsck*" diff --git a/meta/recipes-core/util-linux/util-linux_2.21.2.bb b/meta/recipes-core/util-linux/util-linux_2.21.2.bb index e8f00fc..792730c 100644 --- a/meta/recipes-core/util-linux/util-linux_2.21.2.bb +++ b/meta/recipes-core/util-linux/util-linux_2.21.2.bb @@ -1,5 +1,5 @@ MAJOR_VERSION = "2.21" -PR = "r3" +PR = "r4" require util-linux.inc # note that `lscpu' is under GPLv3+ Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] package_rpm.bbclass: change the arch's "-" to "_" for platform
On 09/25/2012 06:38 AM, Robert Yang wrote: The platform and platform_extra will be written to /etc/rpm/platform, the rpm's arch has changed the "-" to "_", so the value in platform should also be updated. [YOCTO #3159] Signed-off-by: Robert Yang --- meta/classes/package_rpm.bbclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass index 64689d8..be6bd45 100644 --- a/meta/classes/package_rpm.bbclass +++ b/meta/classes/package_rpm.bbclass @@ -276,8 +276,8 @@ process_pkg_list_rpm() { package_install_internal_rpm () { local target_rootfs="${INSTALL_ROOTFS_RPM}" - local platform="${INSTALL_PLATFORM_RPM}" - local platform_extra="${INSTALL_PLATFORM_EXTRA_RPM}" + local platform="`echo ${INSTALL_PLATFORM_RPM} | sed 's#-#_#g'`" + local platform_extra="`echo ${INSTALL_PLATFORM_EXTRA_RPM} | sed 's#-#_#g'`" local confbase="${INSTALL_CONFBASE_RPM}" local package_to_install="${INSTALL_PACKAGES_RPM}" local package_attemptonly="${INSTALL_PACKAGES_ATTEMPTONLY_RPM}" Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] jpeg-native: Do not use libtool-cross for native recipe
On Thu, Sep 27, 2012 at 8:16 AM, Richard Purdie wrote: > On Thu, 2012-09-27 at 07:14 -0700, Khem Raj wrote: >> On Wed, Sep 26, 2012 at 6:59 AM, Richard Purdie >> wrote: >> > On Tue, 2012-09-25 at 06:27 -0700, Khem Raj wrote: >> >> On Tue, Sep 25, 2012 at 1:14 AM, Richard Purdie >> >> wrote: >> >> > This wallpapers over cracks. Why is libtool-native/libtool-cross broken? >> >> > Shouldn't we fix whatever is breaking libtool? >> >> > >> >> >> >> it is not broken. But we were ending up using cross-libtool for native >> >> recipe that does not seem right. >> > >> > Looking at your original error message, it says: >> > >> > >> > /work/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/bin/x86_64-linux-libtool >> > >> > which is libtool-native. I appreciate that the OEMAKE line to use the >> > cross version is wrong but it looks like it still manages to find the >> > native libtool and that it isn't working. >> >> hmmm I tried and it worked fine when libtool-cross was staged. I guess >> my problem was >> that it was trying to find native sed in native sysroot. I cant >> reproduce it. But I guess >> the patch still makes sense. I can send it with commit message changed >> if you are ok with that > > I'm not really. I'd like to understand what the problem is we're fixing > before I take patches. We don't understand what is wrong here. > yes it seems something else is going on since for native recipes STAGING_BINDIR_CROSS=${STAGING_BINDIR_NATIVE} which means it ends up sourcing the native libtool for jpeg-native When I did bitbake jpeg-native from scratch it worked fine too. It appeared on a build server so it could have some weird race condition show up. I will keep an eye if it happens again then I would like to understand and hopefully reproduce. Let me withdraw this patch. > Cheers, > > Richard > ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2] package_rpm.bbclass: two fixes
On 09/25/2012 06:38 AM, Robert Yang wrote: * Two fixes - Change the arch's "-" to "_" in /etc/rpm/platform - Fix the incremental rpm image generation // Robert The following changes since commit 8b3aa00029e62df6d05710cf166fd5d09bdb29cf: documentation/poky-ref-manual/ref-variables.xml: Update B variable (2012-09-24 16:36:09 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib robert/rpm_arch_inc http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/rpm_arch_inc Robert Yang (2): package_rpm.bbclass: change the arch's "-" to "_" for platform package_rpm.bbclass: no initial_solution in the second build meta/classes/package_rpm.bbclass | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) Merged both into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH 00/10] qt4: upgrade to 4.8.3 and cleanup
On Thu, Sep 27, 2012 at 04:10:20PM +0100, Paul Eggleton wrote: > On Thursday 27 September 2012 00:27:05 Martin Jansa wrote: > > Please test on more architectures. > > I've tested complete qt4-native + qt4-free-x11 on armv4t. > > And only do_patch for nativesdk-qt4-tools, qt-mobility-*, qt4-embedded. > > So this is great work and these patches look good, although I'm still not > particularly happy with breaking out so many of the configure options because > I'm convinced it won't stop here; but it's possible I might be overruled on > this issue. I've added that, because meta-webos layer disables more stuff then .inc file forces enabled, so I would have to rewrite whole QT_CONFIG_FLAGS (if I don't want to have e.g. -webkit from .inc and -no-webkit appended after that through QT_DISTRO_FLAGS). But it can be just 2 variables instead of 6 if it's issue. > The bigger problem is when these patches are arriving - we're late into the > stabilisation period and given the choice I'd prefer not to merge them until > the next development cycle. The cleanup part is formal only, so with low risk IMHO. I have some layer with .bbappends to it which needs 4.8.3 (or 4.8.2) so recipe even with negative D_P would help me to be able to use next oe-core release. Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] layer.conf: allow other layers to depend on this version
On 09/25/2012 07:58 AM, Paul Eggleton wrote: Set LAYERVERSION and rename the collection to "core". Given changes such as the tabs to spaces cleanup for python functions in the current version, this allows other layers to depend on this version of OE-Core specifically should they choose to do so, by specifying the following in their own layer.conf: LAYERDEPENDS_layername = "core:1" Where layername is whatever value is being added to BBFILE_COLLECTIONS. (This change does nothing unless a layer has LAYERDEPENDS set.) Signed-off-by: Paul Eggleton --- meta/conf/layer.conf | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf index ed50f1c..78ceae9 100644 --- a/meta/conf/layer.conf +++ b/meta/conf/layer.conf @@ -3,9 +3,13 @@ BBPATH .= ":${LAYERDIR}" # We have a packages directory, add to BBFILES BBFILES += "${LAYERDIR}/recipes-*/*/*.bb" -BBFILE_COLLECTIONS += "normal" -BBFILE_PATTERN_normal := "^${LAYERDIR}/" -BBFILE_PRIORITY_normal = "5" +BBFILE_COLLECTIONS += "core" +BBFILE_PATTERN_core := "^${LAYERDIR}/" +BBFILE_PRIORITY_core = "5" + +# This should only be incremented on significant changes that will +# cause compatibility issues with other layers +LAYERVERSION_core = "1" # Set a variable to get to the top of the metadata location COREBASE := '${@os.path.normpath("${LAYERDIR}/../")}' Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] iproute2: Use configured values for ${base_sbindir} and ${libdir}
On 09/25/2012 09:38 AM, Phil Blundell wrote: These were previously being hard-coded to "/sbin" and "/usr/lib" respectively, resulting in unpackaged files if the configured values were something else. Signed-off-by: Phil Blundell --- meta/recipes-connectivity/iproute2/iproute2.inc |2 +- meta/recipes-connectivity/iproute2/iproute2_3.5.1.bb |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-connectivity/iproute2/iproute2.inc b/meta/recipes-connectivity/iproute2/iproute2.inc index 7caf7d0..d8b1a17 100644 --- a/meta/recipes-connectivity/iproute2/iproute2.inc +++ b/meta/recipes-connectivity/iproute2/iproute2.inc @@ -13,7 +13,7 @@ DEPENDS = "flex-native bison-native" inherit update-alternatives -EXTRA_OEMAKE = "CC='${CC}' KERNEL_INCLUDE=${STAGING_KERNEL_DIR}/include DOCDIR=${docdir}/iproute2 SUBDIRS='lib tc ip' SBINDIR=/sbin" +EXTRA_OEMAKE = "CC='${CC}' KERNEL_INCLUDE=${STAGING_KERNEL_DIR}/include DOCDIR=${docdir}/iproute2 SUBDIRS='lib tc ip' SBINDIR='${base_sbindir}' LIBDIR='${libdir}'" do_install () { oe_runmake DESTDIR=${D} install diff --git a/meta/recipes-connectivity/iproute2/iproute2_3.5.1.bb b/meta/recipes-connectivity/iproute2/iproute2_3.5.1.bb index fc7292e..c1e9bd3 100644 --- a/meta/recipes-connectivity/iproute2/iproute2_3.5.1.bb +++ b/meta/recipes-connectivity/iproute2/iproute2_3.5.1.bb @@ -1,6 +1,6 @@ require iproute2.inc -PR = "r0" +PR = "r1" SRC_URI = "${KERNELORG_MIRROR}/linux/utils/net/${BPN}/${BPN}-${PV}.tar.xz \ file://configure-cross.patch" Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] SDK: trap any IO errors in the relocate script
On 09/25/2012 09:35 AM, Laurentiu Palcu wrote: BTW: in the future it's good to say the "filename: " So this would be "relocate_sdk.py: " If the files being relocated are already used by other processes the relocate script will fail with a traceback. This patch will trap any IO errors when opening such a file and gracefully report them to the user. Also change the exit code from 1 to -1 for a better adt-installer user experience (like pointing the user to the adt_installer.log). [YOCTO #3164] Signed-off-by: Laurentiu Palcu --- scripts/relocate_sdk.py | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/scripts/relocate_sdk.py b/scripts/relocate_sdk.py index b247e65..637ffe9 100755 --- a/scripts/relocate_sdk.py +++ b/scripts/relocate_sdk.py @@ -29,6 +29,7 @@ import sys import stat import os import re +import errno old_prefix = re.compile("##DEFAULT_INSTALL_DIR##") @@ -171,7 +172,7 @@ def change_dl_sysdirs(): # MAIN if len(sys.argv) < 4: -exit(1) +exit(-1) new_prefix = sys.argv[1] new_dl_path = sys.argv[2] @@ -184,7 +185,16 @@ for e in executables_list: else: os.chmod(e, perms|stat.S_IRWXU) -f = open(e, "r+b") +try: +f = open(e, "r+b") +except IOError as ioex: +if ioex.errno == errno.ETXTBSY: +print("Could not open %s. File used by another process.\nPlease "\ + "make sure you exit all processes that might use any SDK "\ + "binaries." % e) +else: +print("Could not open %s: %s(%d)" % (e, ioex.strerror, ioex.errno)) +exit(-1) arch = get_arch() if arch: Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] Correcting LICENSE for ossp-uuid
On 09/25/2012 03:31 PM, Elizabeth Flanagan wrote: LICENSE information for ossp-uuid was tossing a warning. this fixes license as well as provides a more detailed LIC_FILES_CHKSUM. The following changes since commit a8edf79fce381d0433f18bd38df6cd74008e5179: bitbake: fetch2/git: Don't use deprecated API (2012-09-25 15:55:57 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib eflanagan/ossp-uuid-native http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=eflanagan/ossp-uuid-native Elizabeth Flanagan (1): ossp-uuid: LICENSE type corrections. meta/recipes-devtools/ossp-uuid/ossp-uuid_1.6.2.bb |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] at: atd remove useless --make-pidfile option.
On 09/26/2012 12:09 AM, Xin Ouyang wrote: For start-stop-daemon, --make-pidfile is used when starting a program that does not create its own pid file. atd would create its own /var/run/atd.pid, so remove this option. Signed-off-by: Xin Ouyang --- meta/recipes-extended/at/at_3.1.13.bb |2 +- meta/recipes-extended/at/files/S99at |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-extended/at/at_3.1.13.bb b/meta/recipes-extended/at/at_3.1.13.bb index a391d6e..3580e09 100644 --- a/meta/recipes-extended/at/at_3.1.13.bb +++ b/meta/recipes-extended/at/at_3.1.13.bb @@ -11,7 +11,7 @@ PAM_DEPS = "libpam libpam-runtime pam-plugin-env pam-plugin-limits" RCONFLICTS_${PN} = "atd" RREPLACES_${PN} = "atd" -PR = "r3" +PR = "r4" SRC_URI = "${DEBIAN_MIRROR}/main/a/at/at_${PV}.orig.tar.gz \ file://configure.patch \ diff --git a/meta/recipes-extended/at/files/S99at b/meta/recipes-extended/at/files/S99at index bcfcbda..386f8a4 100644 --- a/meta/recipes-extended/at/files/S99at +++ b/meta/recipes-extended/at/files/S99at @@ -7,7 +7,7 @@ umask 077 start() { echo -n "Starting atd: " - start-stop-daemon --start --quiet --make-pidfile --pidfile /var/run/atd.pid --background --exec /usr/sbin/atd -- -f + start-stop-daemon --start --quiet --pidfile /var/run/atd.pid --background --exec /usr/sbin/atd -- -f echo "OK" } stop() { Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core] ysvinit-inittab: fix hang issue of series consoles check
On 09/26/2012 12:18 AM, b19...@freescale.com wrote: From: Zhenhua Luo the kernel boot process hangs when /proc/consoles doesn't exists, check the existence of /proc/consoles before executing pkg_postinst script. Following is the log when /proc/consoles doesn't exist: Running postinst /etc/rpm-postinsts/102... cat: /proc/consoles: No such file or directory cat: /proc/consoles: No such file or directory cat: /proc/consoles: No such file or directory INIT: Entering runlevel: 5 Starting OpenBSD Secure Shell server: sshd generating ssh RSA key... generating ssh ECDSA key... generating ssh DSA key... done. Starting network benchmark server: netserver. Starting system log daemon...0 Starting kernel log daemon...0 Stopping Bootlog daemon: bootlogd. INIT: no more processes left in this runlevel Signed-off-by: Zhenhua Luo --- .../sysvinit/sysvinit-inittab_2.88dsf.bb |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb index 5b79caf..b289853 100644 --- a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb +++ b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb @@ -2,7 +2,7 @@ DESCRIPTION = "Inittab for sysvinit" LICENSE = "GPLv2" LIC_FILES_CHKSUM = "file://${COREBASE}/meta/files/common-licenses/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6" -PR = "r8" +PR = "r9" SRC_URI = "file://inittab" @@ -54,7 +54,7 @@ EOF pkg_postinst_${PN} () { # run this on the target -if [ "x$D" = "x" ]; then +if [ "x$D" = "x" ] && [ -e /proc/consoles ]; then tmp="${SERIAL_CONSOLES_CHECK}" for i in $tmp do Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] package_ipk: Remove spurious '-i' in grep command for log_check
On 09/26/2012 04:55 AM, Phil Blundell wrote: ipk_log_check uses a case-sensitive grep (which is correct) when deciding whether there were any errors or not. But if it decides that there were, it then uses a case-insensitive grep to display them. This results in a large amount of irrelevant and confusing output which makes it hard to see the real errors amongst the noise. Suppress this by removing the unwanted -i. Signed-off-by: Phil Blundell --- meta/classes/package_ipk.bbclass |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/classes/package_ipk.bbclass b/meta/classes/package_ipk.bbclass index efe299e..59cb856 100644 --- a/meta/classes/package_ipk.bbclass +++ b/meta/classes/package_ipk.bbclass @@ -182,7 +182,7 @@ ipk_log_check() { then echo "log_check: There were error messages in the logfile" printf "log_check: Matched keyword: [$keyword_die]\n\n" - echo "$lf_txt" | grep -v log_check | grep -C 5 -i "$keyword_die" + echo "$lf_txt" | grep -v log_check | grep -C 5 "$keyword_die" echo "" do_exit=1 fi Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kexec-tools: admit mips as a COMPATIBLE_HOST
On 09/24/2012 04:49 AM, Phil Blundell wrote: Signed-off-by: Phil Blundell --- meta/recipes-kernel/kexec/kexec-tools.inc |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-kernel/kexec/kexec-tools.inc b/meta/recipes-kernel/kexec/kexec-tools.inc index 278ce34..ee1f1e8 100644 --- a/meta/recipes-kernel/kexec/kexec-tools.inc +++ b/meta/recipes-kernel/kexec/kexec-tools.inc @@ -12,6 +12,6 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/utils/kernel/kexec/kexec-tools-${PV}.tar.gz inherit autotools -COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*)-(linux|freebsd.*)' +COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*|mips.*)-(linux|freebsd.*)' INSANE_SKIP_${PN} = "arch" Merged into OE-Core Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] qemu-native: fix build on hosts without libX11 installed
On 09/22/2012 03:30 AM, Martin Jansa wrote: Signed-off-by: Martin Jansa --- meta/recipes-devtools/qemu/qemu_1.2.0.bb | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/meta/recipes-devtools/qemu/qemu_1.2.0.bb b/meta/recipes-devtools/qemu/qemu_1.2.0.bb index 7091f6d..191ee48 100644 --- a/meta/recipes-devtools/qemu/qemu_1.2.0.bb +++ b/meta/recipes-devtools/qemu/qemu_1.2.0.bb @@ -17,7 +17,7 @@ SRC_URI = "\ SRC_URI[md5sum] = "78eb1e984f4532aa9f2bdd3c127b5b61" SRC_URI[sha256sum] = "c8b84420d9f4869397f84cad2dabd9a475b7723d619a924a873740353e9df936" -PR = "r1" +PR = "r2" SRC_URI_append_virtclass-nativesdk = "\ file://relocatable_sdk.patch \ @@ -29,4 +29,8 @@ do_configure_prepend_virtclass-nativesdk() { sed -i 's/-lX11//g' Makefile.target fi } +do_configure_prepend_virtclass-native() { + # Undo the -lX11 added by linker-flags.patch, don't assume that host has libX11 installed + sed -i 's/-lX11//g' Makefile.target +} Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] autotools.bbclass: using relative paths for acpaths
On 09/27/2012 01:23 AM, wenzong@windriver.com wrote: From: Wenzong Fan Fix autotools.bbclass to use relative paths for acpaths instead of absolute ones. Since absolute paths may cause potential autoreconf error like: Can't exec "/bin/sh": Argument list too long ... This error occurs while building coreutils with long TMPDIR, because it has bunch of m4 files need to be expanded. [YOCTO #2766] The following changes since commit 0b09e50810162a07ef0aecee91ee32b4a36334a3: busybox: Fix misplaced quote (2012-09-26 18:28:36 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib wenzong/2766 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/2766 Wenzong Fan (1): autotools.bbclass: using relative paths for acpaths meta/classes/autotools.bbclass |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gnome-keyring: include unpackaged files with PAM enabled
On 09/27/2012 01:17 AM, Constantin Musca wrote: Include missing files/dirs: ${base_libdir}/security/*.la ${base_libdir}/security/*${SOLIBSDEV} ${base_libdir}/security/.debug/ [YOCTO #2805] Signed-off-by: Constantin Musca --- meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb |9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb b/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb index d822721..92e0e1b 100644 --- a/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb +++ b/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb @@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \ SECTION = "x11/gnome" -PR = "r9" +PR = "r10" inherit autotools gnome gtk-doc pkgconfig @@ -43,7 +43,10 @@ FILES_${PN} += "${datadir}/dbus-1/services ${datadir}/gcr" FILES_${PN}-dev += "${libdir}/${BPN}/devel/*.la \ ${libdir}/${BPN}/devel/*${SOLIBSDEV} \ -${libdir}/${BPN}/standalone/*.la" +${libdir}/${BPN}/standalone/*.la \ +${base_libdir}/security/*.la \ +${base_libdir}/security/*${SOLIBSDEV}" FILES_${PN}-dbg += "${libdir}/${BPN}/standalone/.debug/ \ -${libdir}/${BPN}/devel/.debug/" +${libdir}/${BPN}/devel/.debug/ \ +${base_libdir}/security/.debug/" Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] sstate-cache-management: hide error message when one of possible layer location doesn't exist
On 09/27/2012 12:36 AM, Martin Jansa wrote: * fixes [YOCTO #3116] Signed-off-by: Martin Jansa --- scripts/sstate-cache-management.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/sstate-cache-management.sh b/scripts/sstate-cache-management.sh index f519555..4c06fe8 100755 --- a/scripts/sstate-cache-management.sh +++ b/scripts/sstate-cache-management.sh @@ -174,7 +174,7 @@ remove_duplicated () { topdir=$(dirname $oe_core_dir) tunedirs="`find $topdir/meta* ${oe_core_dir}/meta* $layers -path '*/meta*/conf/machine/include'`" [ -n "$tunedirs" ] || echo_error "Can't find the tune directory" - all_machines="`find $topdir/meta* ${oe_core_dir}/meta* $layers -path '*/meta*/conf/machine/*' -name '*.conf' | sed -e 's/.*\///' -e 's/.conf$//'`" + all_machines="`find $topdir/meta* ${oe_core_dir}/meta* $layers -path '*/meta*/conf/machine/*' -name '*.conf' 2>/dev/null | sed -e 's/.*\///' -e 's/.conf$//'`" all_archs=`grep -r -h "^AVAILTUNES .*=" $tunedirs | sed -e 's/.*=//' -e 's/\"//g'` # Add the qemu and native archs # Use the "_" to substitute "-", e.g., x86-64 to x86_64 Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] license.bbclass: Variable standardization
On 09/26/2012 02:50 PM, Elizabeth Flanagan wrote: The variable mentioned in license.conf is LICENSE_PATH. The variable used in license.bbclass is LICENSE_DIR. Conforming to what is in license.conf Signed-off-by: Elizabeth Flanagan --- meta/classes/license.bbclass |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass index ffcaf93..ad543f6 100644 --- a/meta/classes/license.bbclass +++ b/meta/classes/license.bbclass @@ -186,7 +186,7 @@ python do_populate_lic() { license_source_dirs = [] license_source_dirs.append(generic_directory) try: -additional_lic_dirs = d.getVar('LICENSE_DIR', True).split() +additional_lic_dirs = d.getVar('LICENSE_PATH', True).split() Beth, I found that we also have LICENSE_DIRECTORY, so the intent here is to be a multiple directory (such as a search PATH) for licenses? There is also some documentation that needs to be changed, should not prevent this patch from being pulled. Sau! for lic_dir in additional_lic_dirs: license_source_dirs.append(lic_dir) except: ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] autotools.bbclass: using relative paths for acpaths
On Thu, 2012-09-27 at 16:23 +0800, wenzong@windriver.com wrote: > From: Wenzong Fan > > Fix autotools.bbclass to use relative paths for acpaths instead of > absolute ones. Since absolute paths may cause potential autoreconf > error like: > > Can't exec "/bin/sh": Argument list too long ... > > This error occurs while building coreutils with long TMPDIR, because > it has bunch of m4 files need to be expanded. > > [YOCTO #2766] > > Signed-off-by: Wenzong Fan > --- > meta/classes/autotools.bbclass |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass > index e4e034b..874e01d 100644 > --- a/meta/classes/autotools.bbclass > +++ b/meta/classes/autotools.bbclass > @@ -130,7 +130,8 @@ autotools_do_configure() { > if [ x"${acpaths}" = xdefault ]; then > acpaths= > for i in `find ${S} -maxdepth 2 -name \*.m4|grep -v > 'aclocal.m4'| \ > - grep -v 'acinclude.m4' | sed -e > 's,\(.*/\).*$,\1,'|sort -u`; do > + grep -v 'acinclude.m4' | sed -e > 's,\(.*/\).*$,\1,'|sort -u| \ > + sed -e 's,${S},\.,'`; do > acpaths="$acpaths -I $i" > done > else We applied this but it nearly instantly caused build failure reports. Anything with multiple configure.ac files where sub configures are used such as bdwgc-native will fail after this. I've therefore reverted it and we need to find another way. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] license.bbclass fixes
On 09/26/2012 02:50 PM, Elizabeth Flanagan wrote: [YOCTO #3118] license.conf hasn't been being parsed. This commit series ensures that license.conf is parsed, that it contains useful variables that should be in a global conf file and that those variables are not kept within license.bbclass. So where is the inherit license bbclass? Sau! This also fixes an discreprancy between the documentation of LICENSE_PATH (which is what we tell people to use) and what we were using "LICENSE_DIR". This ensures that when the end user needs to add additional licenses, that they use LICENSE_PATH += "path/to/additional/licenses" and that it works. The following changes since commit 0b09e50810162a07ef0aecee91ee32b4a36334a3: busybox: Fix misplaced quote (2012-09-26 18:28:36 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib eflanagan/LICENSE_PATH http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=eflanagan/LICENSE_PATH Elizabeth Flanagan (3): license.bbclass: Variable standardization bitbake.conf: parse license config license.conf/bbclass: Move globals to license.conf meta/classes/license.bbclass | 67 +- meta/conf/bitbake.conf |1 + meta/conf/licenses.conf | 64 3 files changed, 66 insertions(+), 66 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-commits] Martin Jansa : xserver-xorg: use EXTENDPKGV instead of PV in RCONFLICTS_${PN}-module-exa
On Thu, Sep 27, 2012 at 05:34:19PM +0200, Martin Jansa wrote: > On Thu, Sep 27, 2012 at 02:29:25PM +, g...@git.openembedded.org wrote: > > Module: openembedded-core.git > > Branch: master > > Commit: ed0216d29fc4355c5220f3ad51df04a63cacb0c3 > > URL: > > http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=ed0216d29fc4355c5220f3ad51df04a63cacb0c3 > > > > Author: Martin Jansa > > Date: Sat Sep 22 19:13:14 2012 +0200 > > > > xserver-xorg: use EXTENDPKGV instead of PV in RCONFLICTS_${PN}-module-exa > > > > * it doesn't make much sense with PV, because xserver-xorg-module-exa > > was introduced in > > > > http://git.openembedded.org/openembedded-core/commit/meta/recipes-graphics/xorg-xserver?id=1a666ee1cda3c0b74daba5881fc5f62e13deec66 > > so our xserver-xorg-module-exa RCONFLICTS with xserver-xorg (<= 1.11.2-r4) > > and (< 1.11.2) is not good enough > > > > * because we don't know how many PRINC are in BSP/DISTRO layers, > > then it's safer to RCONFLICTS with every older version then current > > EXTENDPKGV > > > > Also fixes whitespace to work correctly with opkg > > The whitespace problem wasn't opkg fault AFAIK, but > bb.utils.explode_dep_versions as shown in > http://patchwork.openembedded.org/patch/37069/ Ah and it was meant to be applied together with this patch, so now it's missing PR bump.. Cheers, > > Signed-off-by: Martin Jansa > > > > -- > > > > * I haven't really tested this with IPK, since it was changed from > > RREPLACES to RCONFLICTS (because of RPM) and all my installed devices > > are already upgraded > > Signed-off-by: Richard Purdie > > > > --- > > > > .../recipes-graphics/xorg-xserver/xserver-xorg.inc |2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc > > b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc > > index 643ca70..7513399 100644 > > --- a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc > > +++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc > > @@ -66,7 +66,7 @@ PACKAGES =+ "${PN}-security-policy \ > > > > RRECOMMENDS_${PN} += "${PN}-security-policy xkeyboard-config rgb > > xserver-xf86-config" > > RDEPENDS_${PN}-xvfb += "xkeyboard-config" > > -RCONFLICTS_${PN}-module-exa = "${PN} (<${PV})" > > +RCONFLICTS_${PN}-module-exa = "${PN} (< ${EXTENDPKGV})" > > > > FILES_${PN} = "${bindir} ${libdir}/X11/Options ${libdir}/X11/Cards > > ${libdir}/X11/getconfig ${libdir}/X11/etc ${libdir}/modules/*.so > > ${libdir}/xorg/modules/*.so /etc/X11 ${libdir}/xorg/protocol.txt > > ${datadir}/X11/xorg.conf.d" > > FILES_${PN}-dev += "${libdir}/xorg/modules/*.la > > ${libdir}/xorg/modules/*/*.la" > > > > > > ___ > > Openembedded-commits mailing list > > openembedded-comm...@lists.openembedded.org > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-commits > > -- > Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-commits] Martin Jansa : xserver-xorg: use EXTENDPKGV instead of PV in RCONFLICTS_${PN}-module-exa
On Thu, Sep 27, 2012 at 2:55 PM, Martin Jansa wrote: > On Thu, Sep 27, 2012 at 05:34:19PM +0200, Martin Jansa wrote: >> On Thu, Sep 27, 2012 at 02:29:25PM +, g...@git.openembedded.org wrote: >> > Module: openembedded-core.git >> > Branch: master >> > Commit: ed0216d29fc4355c5220f3ad51df04a63cacb0c3 >> > URL: >> > http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=ed0216d29fc4355c5220f3ad51df04a63cacb0c3 >> > >> > Author: Martin Jansa >> > Date: Sat Sep 22 19:13:14 2012 +0200 >> > >> > xserver-xorg: use EXTENDPKGV instead of PV in RCONFLICTS_${PN}-module-exa >> > >> > * it doesn't make much sense with PV, because xserver-xorg-module-exa >> > was introduced in >> > >> > http://git.openembedded.org/openembedded-core/commit/meta/recipes-graphics/xorg-xserver?id=1a666ee1cda3c0b74daba5881fc5f62e13deec66 >> > so our xserver-xorg-module-exa RCONFLICTS with xserver-xorg (<= >> > 1.11.2-r4) >> > and (< 1.11.2) is not good enough >> > >> > * because we don't know how many PRINC are in BSP/DISTRO layers, >> > then it's safer to RCONFLICTS with every older version then current >> > EXTENDPKGV >> > >> > Also fixes whitespace to work correctly with opkg >> >> The whitespace problem wasn't opkg fault AFAIK, but >> bb.utils.explode_dep_versions as shown in >> http://patchwork.openembedded.org/patch/37069/ > > Ah and it was meant to be applied together with this patch, so now it's > missing PR bump.. It keeps failing for me. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] xserver-xorg: Use rdepends to ensure xserver-xorg-module-exa match version
This fix the installation of xserver-xorg-module-exa package at rootfs using opkg. It were failing as conflicts where not working properly. Signed-off-by: Otavio Salvador --- .../xorg-xserver/xserver-xorg-1.11.2.inc |2 +- .../recipes-graphics/xorg-xserver/xserver-xorg.inc |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg-1.11.2.inc b/meta/recipes-graphics/xorg-xserver/xserver-xorg-1.11.2.inc index 35cb33a..32bd9fd 100644 --- a/meta/recipes-graphics/xorg-xserver/xserver-xorg-1.11.2.inc +++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg-1.11.2.inc @@ -8,4 +8,4 @@ SRC_URI += "file://crosscompile.patch \ SRC_URI[md5sum] = "8796fff441e5435ee36a72579008af24" SRC_URI[sha256sum] = "fa415decf02027ca278b06254ccfbcceba2a83c2741405257ebf749da4a73cf2" -PR = "r8" +PR = "r9" diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc index 7513399..bea0252 100644 --- a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc +++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc @@ -66,7 +66,7 @@ PACKAGES =+ "${PN}-security-policy \ RRECOMMENDS_${PN} += "${PN}-security-policy xkeyboard-config rgb xserver-xf86-config" RDEPENDS_${PN}-xvfb += "xkeyboard-config" -RCONFLICTS_${PN}-module-exa = "${PN} (< ${EXTENDPKGV})" +RDEPENDS_${PN}-module-exa = "${PN} (= ${EXTENDPKGV})" FILES_${PN} = "${bindir} ${libdir}/X11/Options ${libdir}/X11/Cards ${libdir}/X11/getconfig ${libdir}/X11/etc ${libdir}/modules/*.so ${libdir}/xorg/modules/*.so /etc/X11 ${libdir}/xorg/protocol.txt ${datadir}/X11/xorg.conf.d" FILES_${PN}-dev += "${libdir}/xorg/modules/*.la ${libdir}/xorg/modules/*/*.la" -- 1.7.2.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
Let me preface this by I have read the patch set.. Martin asked me to comment on the items below... On 9/27/12 3:37 AM, Martin Jansa wrote: On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote: On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote: * bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE * this way xscale or arm926ejs is not used by default when some machine includes its tune*.inc, but it's easy for DISTRO to say it wants OPTDEFAULTTUNE for some packages or always (if they don't want to share built packages between xscale and arm926ejs). Signed-off-by: Martin Jansa --- meta/conf/bitbake.conf | 1 + meta/conf/machine/include/tune-arm926ejs.inc | 3 ++- meta/conf/machine/include/tune-xscale.inc| 3 ++- 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index 9b41749..e433fcb 100644 --- a/meta/conf/bitbake.conf +++ b/meta/conf/bitbake.conf @@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}" HOST_AS_ARCH = "${TARGET_AS_ARCH}" HOST_EXEEXT = "" +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}" TUNE_ARCH ??= "INVALID" TUNE_CCARGS ??= "" TUNE_LDARGS ??= "" As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage or in meaning and we need to find a better solution. I'm therefore not keen on this change. OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use different PKGARCH for different TUNE_CCARGS? I've been an advocate for a while that the processor optimization (CCARGS) does make it into the PKGARCH. ARMPKGSFX_CPU seems like a reasonable approach to do this. It allows each tune to set something to tell people what that binary is really built for, and for the 'base' tunes (i.e. armv5) it can be left off. The only concern I have with that is: +ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-arm926ejs", "", d)}" That probably should be a .= instead of just '='. That way if the user loads multiple compatible tunes the right ARMPKGSFX_CPU will be used. (Alternatively using the overrides would work as well for this.. i.e. ARMPKGSFX_CPU_tune-arm926ejs instead... I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead... This is fine as well, and it was designed to be overriden.. but again the .= or -tune_... syntax should be used... Anyway, my point in this is I like having the stuff unique, but we need to be sure that you can specify more then one tune file during a build w/o clashes. I also still think this is a distro packaging issue and should be solved by the distro, even if that means more complexity there. That is the right place for this particular complexity IMO. I'm happy to support that from the core but not in something as user visible and confusing as this variable. Agreed OPTDEFAULTTUNE is to help distro configs, because complexity there will be much worse then when it's defined in tune-* files, because now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or TUNE_FEATURE) it supports and it's less orthogonal (machine/distro config) then it could be. I really don't have a strong opinion on this either way. I know for the stuff I've done in the past (not oe-based) we've just manually configured (the equivalent of the distro conf) with the information on the handful of items that people wanted optimized the most... eglibc, openssl, mysql/posgresql... otherwise folks don't seem to care, and re-use works fine. If the list is small (i.e. less then 10 packages) that specifying it via package specific overrides in the distro file should be fine.. if it's more then 10 (typically) then we need to start looking for another approach. I'd almost suggest in the distro file you could do: OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP (or elsewhere), if set use that value, otherwise using the DEFAULTTUNE value. DEFAULTTUNE- = "${OPTDEFAULTTUNE}" and then everything can be encapsulated into the distro file (and distro BSPs). The downside of this approach is that it's not the 'standard' implementation. --Mark Cheers, ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
On Thu, Sep 27, 2012 at 01:58:35PM -0500, Mark Hatle wrote: > Let me preface this by I have read the patch set.. Martin asked me to comment > on > the items below... > > On 9/27/12 3:37 AM, Martin Jansa wrote: > > On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote: > >> On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote: > >>> * bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE > >>> * this way xscale or arm926ejs is not used by default when some machine > >>>includes its tune*.inc, but it's easy for DISTRO to say it wants > >>>OPTDEFAULTTUNE for some packages or always (if they don't want to > >>>share built packages between xscale and arm926ejs). > >>> > >>> Signed-off-by: Martin Jansa > >>> --- > >>> meta/conf/bitbake.conf | 1 + > >>> meta/conf/machine/include/tune-arm926ejs.inc | 3 ++- > >>> meta/conf/machine/include/tune-xscale.inc| 3 ++- > >>> 3 files changed, 5 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf > >>> index 9b41749..e433fcb 100644 > >>> --- a/meta/conf/bitbake.conf > >>> +++ b/meta/conf/bitbake.conf > >>> @@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}" > >>> HOST_AS_ARCH = "${TARGET_AS_ARCH}" > >>> HOST_EXEEXT = "" > >>> > >>> +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}" > >>> TUNE_ARCH ??= "INVALID" > >>> TUNE_CCARGS ??= "" > >>> TUNE_LDARGS ??= "" > >> > >> As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage > >> or in meaning and we need to find a better solution. I'm therefore not > >> keen on this change. > > > > OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use > > different PKGARCH for different TUNE_CCARGS? > > I've been an advocate for a while that the processor optimization (CCARGS) > does > make it into the PKGARCH. ARMPKGSFX_CPU seems like a reasonable approach to > do > this. It allows each tune to set something to tell people what that binary > is > really built for, and for the 'base' tunes (i.e. armv5) it can be left off. > > The only concern I have with that is: > > +ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", > "-arm926ejs", "", d)}" > > That probably should be a .= instead of just '='. That way if the user loads > multiple compatible tunes the right ARMPKGSFX_CPU will be used. > (Alternatively > using the overrides would work as well for this.. i.e. > ARMPKGSFX_CPU_tune-arm926ejs instead... OK. > I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead... This is > fine as well, and it was designed to be overriden.. but again the .= or > -tune_... syntax should be used... I tend to prefer ARMPKGARCH as it's shorter xscale-te/armv5te-xscale. But not sure what to do with all "lower" PACKAGE_EXTRA_ARCHS: PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}" do we want PACKAGE_EXTRA_ARCHS_tune-armv5teb only or also something like armv4t-xscale? Well whole PACKAGE_EXTRA_ARCHS has too many entries already (opkg update would try to download many feeds but only a few does exist). > Anyway, my point in this is I like having the stuff unique, but we need to be > sure that you can specify more then one tune file during a build w/o clashes. > > >> I also still think this is a distro packaging issue and should be solved > >> by the distro, even if that means more complexity there. That is the > >> right place for this particular complexity IMO. I'm happy to support > >> that from the core but not in something as user visible and confusing as > >> this variable. > > > > Agreed OPTDEFAULTTUNE is to help distro configs, because complexity > > there will be much worse then when it's defined in tune-* files, because > > now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or > > TUNE_FEATURE) it supports and it's less orthogonal (machine/distro > > config) then it could be. > > I really don't have a strong opinion on this either way. I know for the > stuff > I've done in the past (not oe-based) we've just manually configured (the > equivalent of the distro conf) with the information on the handful of items > that > people wanted optimized the most... eglibc, openssl, mysql/posgresql... > otherwise folks don't seem to care, and re-use works fine. > > If the list is small (i.e. less then 10 packages) that specifying it via > package > specific overrides in the distro file should be fine.. if it's more then 10 > (typically) then we need to start looking for another approach. > > I'd almost suggest in the distro file you could do: > > OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP > (or > elsewhere), if set use that value, otherwise using the DEFAULTTUNE value. > > DEFAULTTUNE- = "${OPTDEFAULTTUNE}" Yes but first I have to say: DEFAULTTUNE_spitz = armv5te OPTDEFAULTTUNE_spitz = xscale DEFAULTTUNE_qemuarm = armv5te OPTDEFAULTTUNE_qemuarm = arm926ejs or DEFA
Re: [OE-core] [oe-core][RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
On 9/27/12 2:12 PM, Martin Jansa wrote: On Thu, Sep 27, 2012 at 01:58:35PM -0500, Mark Hatle wrote: Let me preface this by I have read the patch set.. Martin asked me to comment on the items below... On 9/27/12 3:37 AM, Martin Jansa wrote: On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote: On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote: * bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE * this way xscale or arm926ejs is not used by default when some machine includes its tune*.inc, but it's easy for DISTRO to say it wants OPTDEFAULTTUNE for some packages or always (if they don't want to share built packages between xscale and arm926ejs). Signed-off-by: Martin Jansa --- meta/conf/bitbake.conf | 1 + meta/conf/machine/include/tune-arm926ejs.inc | 3 ++- meta/conf/machine/include/tune-xscale.inc| 3 ++- 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index 9b41749..e433fcb 100644 --- a/meta/conf/bitbake.conf +++ b/meta/conf/bitbake.conf @@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}" HOST_AS_ARCH = "${TARGET_AS_ARCH}" HOST_EXEEXT = "" +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}" TUNE_ARCH ??= "INVALID" TUNE_CCARGS ??= "" TUNE_LDARGS ??= "" As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage or in meaning and we need to find a better solution. I'm therefore not keen on this change. OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use different PKGARCH for different TUNE_CCARGS? I've been an advocate for a while that the processor optimization (CCARGS) does make it into the PKGARCH. ARMPKGSFX_CPU seems like a reasonable approach to do this. It allows each tune to set something to tell people what that binary is really built for, and for the 'base' tunes (i.e. armv5) it can be left off. The only concern I have with that is: +ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-arm926ejs", "", d)}" That probably should be a .= instead of just '='. That way if the user loads multiple compatible tunes the right ARMPKGSFX_CPU will be used. (Alternatively using the overrides would work as well for this.. i.e. ARMPKGSFX_CPU_tune-arm926ejs instead... OK. I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead... This is fine as well, and it was designed to be overriden.. but again the .= or -tune_... syntax should be used... I tend to prefer ARMPKGARCH as it's shorter xscale-te/armv5te-xscale. But not sure what to do with all "lower" PACKAGE_EXTRA_ARCHS: PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}" do we want PACKAGE_EXTRA_ARCHS_tune-armv5teb only or also something like armv4t-xscale? Well whole PACKAGE_EXTRA_ARCHS has too many entries already (opkg update would try to download many feeds but only a few does exist). The PACKAGE_EXTRA_ARCHS should contain all of the 'compatible' arch names. Which of course feed into the list of feeds used by the various packaging systems. I think it's up to the distribution to modify or limit the feeds resolved, but I don't know if there is a clean way to do this. I always error on listing more then less, because I don't know how people are going to want to mix and match things. (And a BSP or end user can always just define what the PACKAGE_EXTRA_ARCHS value should be.) Anyway, my point in this is I like having the stuff unique, but we need to be sure that you can specify more then one tune file during a build w/o clashes. I also still think this is a distro packaging issue and should be solved by the distro, even if that means more complexity there. That is the right place for this particular complexity IMO. I'm happy to support that from the core but not in something as user visible and confusing as this variable. Agreed OPTDEFAULTTUNE is to help distro configs, because complexity there will be much worse then when it's defined in tune-* files, because now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or TUNE_FEATURE) it supports and it's less orthogonal (machine/distro config) then it could be. I really don't have a strong opinion on this either way. I know for the stuff I've done in the past (not oe-based) we've just manually configured (the equivalent of the distro conf) with the information on the handful of items that people wanted optimized the most... eglibc, openssl, mysql/posgresql... otherwise folks don't seem to care, and re-use works fine. If the list is small (i.e. less then 10 packages) that specifying it via package specific overrides in the distro file should be fine.. if it's more then 10 (typically) then we need to start looking for another approach. I'd almost suggest in the distro file you could do: OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP (or elsewhere), if set use that value, otherwise using the DE
Re: [OE-core] [oe-core][RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
On Thu, Sep 27, 2012 at 02:18:07PM -0500, Mark Hatle wrote: > On 9/27/12 2:12 PM, Martin Jansa wrote: > > On Thu, Sep 27, 2012 at 01:58:35PM -0500, Mark Hatle wrote: > >> Let me preface this by I have read the patch set.. Martin asked me to > >> comment on > >> the items below... > >> > >> On 9/27/12 3:37 AM, Martin Jansa wrote: > >>> On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote: > On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote: > > * bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE > > * this way xscale or arm926ejs is not used by default when some machine > > includes its tune*.inc, but it's easy for DISTRO to say it wants > > OPTDEFAULTTUNE for some packages or always (if they don't want to > > share built packages between xscale and arm926ejs). > > > > Signed-off-by: Martin Jansa > > --- > >meta/conf/bitbake.conf | 1 + > >meta/conf/machine/include/tune-arm926ejs.inc | 3 ++- > >meta/conf/machine/include/tune-xscale.inc| 3 ++- > >3 files changed, 5 insertions(+), 2 deletions(-) > > > > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf > > index 9b41749..e433fcb 100644 > > --- a/meta/conf/bitbake.conf > > +++ b/meta/conf/bitbake.conf > > @@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}" > >HOST_AS_ARCH = "${TARGET_AS_ARCH}" > >HOST_EXEEXT = "" > > > > +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}" > >TUNE_ARCH ??= "INVALID" > >TUNE_CCARGS ??= "" > >TUNE_LDARGS ??= "" > > As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage > or in meaning and we need to find a better solution. I'm therefore not > keen on this change. > >>> > >>> OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use > >>> different PKGARCH for different TUNE_CCARGS? > >> > >> I've been an advocate for a while that the processor optimization (CCARGS) > >> does > >> make it into the PKGARCH. ARMPKGSFX_CPU seems like a reasonable approach > >> to do > >> this. It allows each tune to set something to tell people what that > >> binary is > >> really built for, and for the 'base' tunes (i.e. armv5) it can be left off. > >> > >> The only concern I have with that is: > >> > >> +ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", > >> "-arm926ejs", "", d)}" > >> > >> That probably should be a .= instead of just '='. That way if the user > >> loads > >> multiple compatible tunes the right ARMPKGSFX_CPU will be used. > >> (Alternatively > >> using the overrides would work as well for this.. i.e. > >> ARMPKGSFX_CPU_tune-arm926ejs instead... > > > > OK. > > > >> I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead... This > >> is > >> fine as well, and it was designed to be overriden.. but again the .= or > >> -tune_... syntax should be used... > > > > I tend to prefer ARMPKGARCH as it's shorter xscale-te/armv5te-xscale. > > > > But not sure what to do with all "lower" PACKAGE_EXTRA_ARCHS: > > PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}" > > do we want PACKAGE_EXTRA_ARCHS_tune-armv5teb only or also something like > > armv4t-xscale? > > > > Well whole PACKAGE_EXTRA_ARCHS has too many entries already (opkg update > > would try to download many feeds but only a few does exist). > > The PACKAGE_EXTRA_ARCHS should contain all of the 'compatible' arch names. > Which of course feed into the list of feeds used by the various packaging > systems. I think it's up to the distribution to modify or limit the feeds > resolved, but I don't know if there is a clean way to do this. I always > error > on listing more then less, because I don't know how people are going to want > to > mix and match things. (And a BSP or end user can always just define what the > PACKAGE_EXTRA_ARCHS value should be.) Yes that's what I do now, but I'm not too happy about it :/ SUPPORTED_EXTRA_ARCHS ?= "armv4t armv5te armv6-novfp armv7a-vfp-neon x86_64 x86" SUPPORTED_EXTRA_ARCHS_armv7a ?= "armv7a-vfp-neon" SUPPORTED_EXTRA_ARCHS_armv6 ?= "armv6-novfp" > >> Anyway, my point in this is I like having the stuff unique, but we need to > >> be > >> sure that you can specify more then one tune file during a build w/o > >> clashes. > >> > I also still think this is a distro packaging issue and should be solved > by the distro, even if that means more complexity there. That is the > right place for this particular complexity IMO. I'm happy to support > that from the core but not in something as user visible and confusing as > this variable. > >>> > >>> Agreed OPTDEFAULTTUNE is to help distro configs, because complexity > >>> there will be much worse then when it's defined in tune-* files, because > >>> now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or > >>> TUNE_FEATURE) it supports
Re: [OE-core] [oe-core][RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
On 9/27/12 2:40 PM, Martin Jansa wrote: On Thu, Sep 27, 2012 at 02:18:07PM -0500, Mark Hatle wrote: On 9/27/12 2:12 PM, Martin Jansa wrote: On Thu, Sep 27, 2012 at 01:58:35PM -0500, Mark Hatle wrote: Let me preface this by I have read the patch set.. Martin asked me to comment on the items below... On 9/27/12 3:37 AM, Martin Jansa wrote: On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote: On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote: * bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE * this way xscale or arm926ejs is not used by default when some machine includes its tune*.inc, but it's easy for DISTRO to say it wants OPTDEFAULTTUNE for some packages or always (if they don't want to share built packages between xscale and arm926ejs). Signed-off-by: Martin Jansa --- meta/conf/bitbake.conf | 1 + meta/conf/machine/include/tune-arm926ejs.inc | 3 ++- meta/conf/machine/include/tune-xscale.inc| 3 ++- 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index 9b41749..e433fcb 100644 --- a/meta/conf/bitbake.conf +++ b/meta/conf/bitbake.conf @@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}" HOST_AS_ARCH = "${TARGET_AS_ARCH}" HOST_EXEEXT = "" +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}" TUNE_ARCH ??= "INVALID" TUNE_CCARGS ??= "" TUNE_LDARGS ??= "" As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage or in meaning and we need to find a better solution. I'm therefore not keen on this change. OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use different PKGARCH for different TUNE_CCARGS? I've been an advocate for a while that the processor optimization (CCARGS) does make it into the PKGARCH. ARMPKGSFX_CPU seems like a reasonable approach to do this. It allows each tune to set something to tell people what that binary is really built for, and for the 'base' tunes (i.e. armv5) it can be left off. The only concern I have with that is: +ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-arm926ejs", "", d)}" That probably should be a .= instead of just '='. That way if the user loads multiple compatible tunes the right ARMPKGSFX_CPU will be used. (Alternatively using the overrides would work as well for this.. i.e. ARMPKGSFX_CPU_tune-arm926ejs instead... OK. I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead... This is fine as well, and it was designed to be overriden.. but again the .= or -tune_... syntax should be used... I tend to prefer ARMPKGARCH as it's shorter xscale-te/armv5te-xscale. But not sure what to do with all "lower" PACKAGE_EXTRA_ARCHS: PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}" do we want PACKAGE_EXTRA_ARCHS_tune-armv5teb only or also something like armv4t-xscale? Well whole PACKAGE_EXTRA_ARCHS has too many entries already (opkg update would try to download many feeds but only a few does exist). The PACKAGE_EXTRA_ARCHS should contain all of the 'compatible' arch names. Which of course feed into the list of feeds used by the various packaging systems. I think it's up to the distribution to modify or limit the feeds resolved, but I don't know if there is a clean way to do this. I always error on listing more then less, because I don't know how people are going to want to mix and match things. (And a BSP or end user can always just define what the PACKAGE_EXTRA_ARCHS value should be.) Yes that's what I do now, but I'm not too happy about it :/ SUPPORTED_EXTRA_ARCHS ?= "armv4t armv5te armv6-novfp armv7a-vfp-neon x86_64 x86" SUPPORTED_EXTRA_ARCHS_armv7a ?= "armv7a-vfp-neon" SUPPORTED_EXTRA_ARCHS_armv6 ?= "armv6-novfp" Anyway, my point in this is I like having the stuff unique, but we need to be sure that you can specify more then one tune file during a build w/o clashes. I also still think this is a distro packaging issue and should be solved by the distro, even if that means more complexity there. That is the right place for this particular complexity IMO. I'm happy to support that from the core but not in something as user visible and confusing as this variable. Agreed OPTDEFAULTTUNE is to help distro configs, because complexity there will be much worse then when it's defined in tune-* files, because now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or TUNE_FEATURE) it supports and it's less orthogonal (machine/distro config) then it could be. I really don't have a strong opinion on this either way. I know for the stuff I've done in the past (not oe-based) we've just manually configured (the equivalent of the distro conf) with the information on the handful of items that people wanted optimized the most... eglibc, openssl, mysql/posgresql... otherwise folks don't seem to care, and re-use works fine. If the list is small (i.e. less then 10 packages) that specifying
Re: [OE-core] [PATCH] perl: Fix nativesdk install path
I had to revert this patch. With it enabled, if I enable multilibs and build for x86_64 (so my libdir == /usr/lib64), perl no longer finishes do_install(). When I revert it fixes that issue, but of course then the nativesdk is broken again. --Mark On 9/27/12 10:32 AM, Saul Wold wrote: On 09/27/2012 05:20 AM, Christian Glindkamp wrote: Commit 38234f2e276356b1d77a87ceabc486107e336d19 tried to fix the sed expressions by anchoring the left side of the search regexp to prevent $prefix$prefix type expression in the perl config. For nativesdk this is not enough. Adding anchors on both side fixes this. Signed-off-by: Christian Glindkamp --- This is currently only build tested, but buildhistory for perl did not change. meta/recipes-devtools/perl/perl_5.14.2.bb |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/meta/recipes-devtools/perl/perl_5.14.2.bb b/meta/recipes-devtools/perl/perl_5.14.2.bb index 3c1360f..0009855 100644 --- a/meta/recipes-devtools/perl/perl_5.14.2.bb +++ b/meta/recipes-devtools/perl/perl_5.14.2.bb @@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = "file://Copying;md5=2b4c6ffbcfcbdee469f02565f253d81a \ # We need gnugrep (for -I) DEPENDS = "virtual/db grep-native" DEPENDS += "gdbm zlib" -PR = "r9" +PR = "r10" # 5.10.1 has Module::Build built-in PROVIDES += "libmodule-build-perl" @@ -150,9 +150,9 @@ do_configure() { -e 's,@ARCH@-thread-multi,,g' \ -e 's,@ARCH@,${TARGET_ARCH}-${TARGET_OS},g' \ -e 's,@STAGINGDIR@,${STAGING_DIR_HOST},g' \ - -e "s%\([ \"^\',=]\+\)/usr/include%\1${STAGING_INCDIR}%g" \ - -e "s%\([ \"^\',=]\+\)/usr/lib/%\1${libdir}/%g" \ - -e "s%\([ \"^\',=]\+\)/usr/%\1${exec_prefix}/%g" \ + -e "s%\([ \"^\',=]\+\)/usr/include\([ \"^\',=]\+\)%\1${STAGING_INCDIR}\2%g" \ + -e "s%\([ \"^\',=]\+\)/usr/lib/\([ \"^\',=]\+\)%\1${libdir}/\2%g" \ + -e "s%\([ \"^\',=]\+\)/usr/\([ \"^\',=]\+\)%\1${exec_prefix}/\2%g" \ -e "s%/perl5%/perl%g" \ config.sh-${TARGET_ARCH}-${TARGET_OS} Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
On Thu, Sep 27, 2012 at 02:53:21PM -0500, Mark Hatle wrote: > On 9/27/12 2:40 PM, Martin Jansa wrote: > > On Thu, Sep 27, 2012 at 02:18:07PM -0500, Mark Hatle wrote: > >> On 9/27/12 2:12 PM, Martin Jansa wrote: > >>> On Thu, Sep 27, 2012 at 01:58:35PM -0500, Mark Hatle wrote: > Let me preface this by I have read the patch set.. Martin asked me to > comment on > the items below... > > On 9/27/12 3:37 AM, Martin Jansa wrote: > > On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote: > >> On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote: > >>> * bitbake.conf has OPTDEFAULTTUNE with weak default value of > >>> DEFAULTTUNE > >>> * this way xscale or arm926ejs is not used by default when some > >>> machine > >>> includes its tune*.inc, but it's easy for DISTRO to say it wants > >>> OPTDEFAULTTUNE for some packages or always (if they don't want to > >>> share built packages between xscale and arm926ejs). > >>> > >>> Signed-off-by: Martin Jansa > >>> --- > >>> meta/conf/bitbake.conf | 1 + > >>> meta/conf/machine/include/tune-arm926ejs.inc | 3 ++- > >>> meta/conf/machine/include/tune-xscale.inc| 3 ++- > >>> 3 files changed, 5 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf > >>> index 9b41749..e433fcb 100644 > >>> --- a/meta/conf/bitbake.conf > >>> +++ b/meta/conf/bitbake.conf > >>> @@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}" > >>> HOST_AS_ARCH = "${TARGET_AS_ARCH}" > >>> HOST_EXEEXT = "" > >>> > >>> +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}" > >>> TUNE_ARCH ??= "INVALID" > >>> TUNE_CCARGS ??= "" > >>> TUNE_LDARGS ??= "" > >> > >> As I've said previously, I do not think OPTDEFAULTTUNE is clear in > >> usage > >> or in meaning and we need to find a better solution. I'm therefore not > >> keen on this change. > > > > OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use > > different PKGARCH for different TUNE_CCARGS? > > I've been an advocate for a while that the processor optimization > (CCARGS) does > make it into the PKGARCH. ARMPKGSFX_CPU seems like a reasonable > approach to do > this. It allows each tune to set something to tell people what that > binary is > really built for, and for the 'base' tunes (i.e. armv5) it can be left > off. > > The only concern I have with that is: > > +ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", > "-arm926ejs", "", d)}" > > That probably should be a .= instead of just '='. That way if the user > loads > multiple compatible tunes the right ARMPKGSFX_CPU will be used. > (Alternatively > using the overrides would work as well for this.. i.e. > ARMPKGSFX_CPU_tune-arm926ejs instead... > >>> > >>> OK. > >>> > I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead... > This is > fine as well, and it was designed to be overriden.. but again the .= or > -tune_... syntax should be used... > >>> > >>> I tend to prefer ARMPKGARCH as it's shorter xscale-te/armv5te-xscale. > >>> > >>> But not sure what to do with all "lower" PACKAGE_EXTRA_ARCHS: > >>> PACKAGE_EXTRA_ARCHS_tune-xscale-be = > >>> "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}" > >>> do we want PACKAGE_EXTRA_ARCHS_tune-armv5teb only or also something like > >>> armv4t-xscale? > >>> > >>> Well whole PACKAGE_EXTRA_ARCHS has too many entries already (opkg update > >>> would try to download many feeds but only a few does exist). > >> > >> The PACKAGE_EXTRA_ARCHS should contain all of the 'compatible' arch names. > >> Which of course feed into the list of feeds used by the various packaging > >> systems. I think it's up to the distribution to modify or limit the feeds > >> resolved, but I don't know if there is a clean way to do this. I always > >> error > >> on listing more then less, because I don't know how people are going to > >> want to > >> mix and match things. (And a BSP or end user can always just define what > >> the > >> PACKAGE_EXTRA_ARCHS value should be.) > > > > Yes that's what I do now, but I'm not too happy about it :/ > > SUPPORTED_EXTRA_ARCHS ?= "armv4t armv5te armv6-novfp armv7a-vfp-neon x86_64 > > x86" > > SUPPORTED_EXTRA_ARCHS_armv7a ?= "armv7a-vfp-neon" > > SUPPORTED_EXTRA_ARCHS_armv6 ?= "armv6-novfp" > > > Anyway, my point in this is I like having the stuff unique, but we need > to be > sure that you can specify more then one tune file during a build w/o > clashes. > > >> I also still think this is a distro packaging issue and should be > >> solved > >> by the distro, even if that means more complexity there. That is the > >> right place for this particular comp
Re: [OE-core] [oe-commits] Andrei Gherzan : busybox: Package hwclock.sh initscript separately
On Fri, Aug 17, 2012 at 05:09:34PM +, g...@git.openembedded.org wrote: > Module: openembedded-core.git > Branch: master > Commit: b97e37e1444ef32e7837dcc79e3fad36c4284b65 > URL: > http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=b97e37e1444ef32e7837dcc79e3fad36c4284b65 > > Author: Andrei Gherzan > Date: Fri Aug 17 00:15:15 2012 +0300 > > busybox: Package hwclock.sh initscript separately > > We package this separately to be able to pull this in only if this makes > sense for the MACHINE. > > Signed-off-by: Andrei Gherzan > Signed-off-by: Saul Wold > > --- > > meta/recipes-core/busybox/busybox.inc |5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/meta/recipes-core/busybox/busybox.inc > b/meta/recipes-core/busybox/busybox.inc > index 78239a2..5a5b383 100644 > --- a/meta/recipes-core/busybox/busybox.inc > +++ b/meta/recipes-core/busybox/busybox.inc > @@ -14,15 +14,16 @@ SECTION = "base" > export EXTRA_CFLAGS = "${CFLAGS}" > export EXTRA_LDFLAGS = "${LDFLAGS}" > > -PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev" > +PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev > ${PN}-hwclock" > > FILES_${PN}-httpd = "${sysconfdir}/init.d/busybox-httpd /srv/www" > FILES_${PN}-syslog = "${sysconfdir}/init.d/syslog* > ${sysconfdir}/syslog-startup.conf*" > FILES_${PN}-mdev = "${sysconfdir}/init.d/mdev ${sysconfdir}/mdev.conf" > FILES_${PN}-udhcpd = "${sysconfdir}/init.d/busybox-udhcpd" > FILES_${PN}-udhcpc = "${sysconfdir}/udhcpc.d ${datadir}/udhcpc" > +FILES_${PN}-hwclock = "${sysconfdir}/init.d/hwclock.sh" > > -INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev" > +INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev > ${PN}-hwclock"" > > INITSCRIPT_NAME_${PN}-httpd = "busybox-httpd" > INITSCRIPT_NAME_${PN}-syslog = "syslog" Missing INITSCRIPT_NAME_${PN}-hwclock = "hwclock.sh" ? Did you test it? Here it fails like this: Configuring busybox-hwclock. usage: update-rc.d [-n] [-f] [-r ] remove update-rc.d [-n] [-r ] [-s] defaults [NN | sNN kNN] update-rc.d [-n] [-r ] [-s] start|stop NN runlvl [runlvl] [...] . -n: not really -f: force -v: verbose -r: alternate root path (default is /) -s: invoke start methods if appropriate to current runlevel Collected errors: * pkg_run_script: package "busybox-hwclock" postinst script returned status 1. * opkg_configure: busybox-hwclock.postinst returned 1. And indeed it's broken: SHR root@qemux86-64 ~ $ cat /var/lib/opkg/info/busybox-hwclock.postinst #!/bin/sh if test "x$D" != "x"; then OPT="-r $D" else OPT="-s" fi update-rc.d $OPT ${INITSCRIPT_NAME} defaults Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] staging: Avoid staging the same binaries again and again
On Mon, 2012-09-24 at 10:54 +0100, Richard Purdie wrote: > sysroot_stage_* are symmetrical so I can't imagine this happening. > > The main worry would be something happening before sysroot_stage_all. > SYSROOT_PREPROCESS_FUNCS happen afterwards so there is at least a hook > used in most cases that would avoid the issue. > > I'm torn whether its better to be simple or less fragile in this case. > Or simply do some tests (if ${bindir} != ${sbindir}) and so on. I'm not quite sure what the conclusion was from this previous discussion. Did you want me to redo the patch to work in some other way? p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] staging: Avoid staging the same binaries again and again
On Thu, 2012-09-27 at 22:18 +0100, Phil Blundell wrote: > On Mon, 2012-09-24 at 10:54 +0100, Richard Purdie wrote: > > sysroot_stage_* are symmetrical so I can't imagine this happening. > > > > The main worry would be something happening before sysroot_stage_all. > > SYSROOT_PREPROCESS_FUNCS happen afterwards so there is at least a hook > > used in most cases that would avoid the issue. > > > > I'm torn whether its better to be simple or less fragile in this case. > > Or simply do some tests (if ${bindir} != ${sbindir}) and so on. > > I'm not quite sure what the conclusion was from this previous > discussion. Did you want me to redo the patch to work in some other > way? The release is now at -rc2 and this patch hasn't reached the threshold of things I'm willing to take. I've tried to at least get some of the patches you're posted in but I wish we'd had them a couple of weeks ago :/. I also wish we could find some neater/simpler way of doing this since I'm not a fan of "obscuring" the code more than we have to. I'm not coming up with any great ways of doing it though. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] OE-Core Release Status
We're now at -rc2 for the October release of OE-Core. I've noticed a sudden surge of patches on the list, several of which are things like version increments which are no longer really appropriate at this point in the release cycle. Why haven't we branched? The plus side of branching now would be continued patches into master. The downside is that QA and autobuilder resources are concentrating on release and hence not on ensuring regressions are being added. I also really need my energy focused on the release rather than reviewing other code. I'm out of bandwidth so I'm putting off branching. There is also the risk that if we branch, people will continue with master development and ignore the release branch and I'd like to apply a little pressure against this. So if patches are getting ignored its likely they've been deemed not suited to the state of the tree right now. I may start to queue things on master-next but no guarantees and I would ask people to try and help make the release a good one. If there are patches being ignored you think do qualify for -rcX, please ping me as it is hard to keep track of everything. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] tcl: Fix dangerous do_install staging references
Nothing should ever be poking files directly into the staging/sysroot directories, it should always go through ${D}. This patch ensures this recipe does this and hence fixes various potential build issues such as lack of sstate tracking of files. Signed-off-by: Richard Purdie --- diff --git a/meta/recipes-devtools/tcltk/tcl_8.5.11.bb b/meta/recipes-devtools/tcltk/tcl_8.5.11.bb index e5fe7d3..fab6057 100644 --- a/meta/recipes-devtools/tcltk/tcl_8.5.11.bb +++ b/meta/recipes-devtools/tcltk/tcl_8.5.11.bb @@ -44,7 +44,7 @@ do_compile_prepend() { do_install() { autotools_do_install - oe_libinstall -so libtcl8.5 ${STAGING_LIBDIR} + oe_libinstall -so libtcl8.5 ${D}${libdir} ln -sf ./tclsh8.5 ${D}${bindir}/tclsh sed -i "s+${WORKDIR}+${STAGING_INCDIR}+g" tclConfig.sh sed -i "s,-L${libdir},-L=${libdir},g" tclConfig.sh @@ -54,8 +54,8 @@ do_install() { cd .. for dir in compat generic unix do - install -d ${STAGING_INCDIR}/tcl${PV}/$dir - install -m 0644 $dir/*.h ${STAGING_INCDIR}/tcl${PV}/$dir/ + install -d ${D}${includedir}/tcl${PV}/$dir + install -m 0644 $dir/*.h ${D}${includedir}/tcl${PV}/$dir/ done } ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] sstate: Relax the duplicate file whitelist for now
do_package is a machine specific task at the moment due to packagedata. This means do_package tasks and their dependencies rerun between different machines with various duplicate file installations. There are plans to fix this but they're too invasive before release. This patch relaxes the whitelist for sstate duplicate file detection to account for this. Post-release, we re-enable stricter settings once do_package is not machine specific. Signed-off-by: Richard Purdie --- diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass index 6878e1a..03f083e 100644 --- a/meta/classes/sstate.bbclass +++ b/meta/classes/sstate.bbclass @@ -17,7 +17,11 @@ SSTATE_EXTRAPATH = "" SSTATE_EXTRAPATHWILDCARD = "" SSTATE_PATHSPEC = "${SSTATE_DIR}/${SSTATE_EXTRAPATHWILDCARD}*/${SSTATE_PKGSPEC}" -SSTATE_DUPWHITELIST = "${DEPLOY_DIR_IMAGE}/ ${DEPLOY_DIR}/licenses/ ${DEPLOY_DIR_IPK}/all/ ${DEPLOY_DIR_RPM}/all ${DEPLOY_DIR_DEB}/all/" +# In theory we should be using: +# SSTATE_DUPWHITELIST = "${DEPLOY_DIR_IMAGE}/ ${DEPLOY_DIR}/licenses/ ${DEPLOY_DIR_IPK}/all/ ${DEPLOY_DIR_RPM}/all ${DEPLOY_DIR_DEB}/all/ ${TMPDIR}/pkgdata/all${TARGET_VENDOR}-${TARGET_OS}" +# However until do_package is not machine specific, we'll have to make do with this: +SSTATE_DUPWHITELIST = "${DEPLOY_DIR}/ ${TMPDIR}/pkgdata/" + SSTATE_SCAN_FILES ?= "*.la *-config *_config" SSTATE_SCAN_CMD ?= 'find ${SSTATE_BUILDDIR} \( -name "${@"\" -o -name \"".join(d.getVar("SSTATE_SCAN_FILES", True).split())}" \) -type f' ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-commits] Martin Jansa : xserver-xorg: use EXTENDPKGV instead of PV in RCONFLICTS_${PN}-module-exa
Just an FYI -- Martin Jansa found a problem with the implement of the package version comparison. In deb and ipk, they do not support '<' or '>', instead it's '<<' and '>>'. (Odd, historical reasons apparently). While RPM doesn't have any idea what '<<' or '>>' is. Talking with RP and others it seems like the best approach is to implement a conversion, in the deb and ipk packaging classes, to convert '<' and '>' to the '<<' and '>>' equivalents. As well as add a sanity check that nobody is using '<<' or '>>'. I'm in the process of doing that now. --Mark On 9/27/12 1:08 PM, Otavio Salvador wrote: On Thu, Sep 27, 2012 at 2:55 PM, Martin Jansa wrote: On Thu, Sep 27, 2012 at 05:34:19PM +0200, Martin Jansa wrote: On Thu, Sep 27, 2012 at 02:29:25PM +, g...@git.openembedded.org wrote: Module: openembedded-core.git Branch: master Commit: ed0216d29fc4355c5220f3ad51df04a63cacb0c3 URL: http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=ed0216d29fc4355c5220f3ad51df04a63cacb0c3 Author: Martin Jansa Date: Sat Sep 22 19:13:14 2012 +0200 xserver-xorg: use EXTENDPKGV instead of PV in RCONFLICTS_${PN}-module-exa * it doesn't make much sense with PV, because xserver-xorg-module-exa was introduced in http://git.openembedded.org/openembedded-core/commit/meta/recipes-graphics/xorg-xserver?id=1a666ee1cda3c0b74daba5881fc5f62e13deec66 so our xserver-xorg-module-exa RCONFLICTS with xserver-xorg (<= 1.11.2-r4) and (< 1.11.2) is not good enough * because we don't know how many PRINC are in BSP/DISTRO layers, then it's safer to RCONFLICTS with every older version then current EXTENDPKGV Also fixes whitespace to work correctly with opkg The whitespace problem wasn't opkg fault AFAIK, but bb.utils.explode_dep_versions as shown in http://patchwork.openembedded.org/patch/37069/ Ah and it was meant to be applied together with this patch, so now it's missing PR bump.. It keeps failing for me. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-commits] Martin Jansa : xserver-xorg: use EXTENDPKGV instead of PV in RCONFLICTS_${PN}-module-exa
On Fri, Sep 28, 2012 at 12:41 AM, Mark Hatle wrote: > Just an FYI -- Martin Jansa found a problem with the implement of the > package version comparison. > > In deb and ipk, they do not support '<' or '>', instead it's '<<' and '>>'. > (Odd, historical reasons apparently). > > While RPM doesn't have any idea what '<<' or '>>' is. > > Talking with RP and others it seems like the best approach is to implement a > conversion, in the deb and ipk packaging classes, to convert '<' and '>' to > the '<<' and '>>' equivalents. As well as add a sanity check that nobody is > using '<<' or '>>'. > > I'm in the process of doing that now. > > --Mark There is still some problem in opkg, now when I'm testing << with opkg which should work as LESS (and < as LESS_EQUAL), it still shows <= in opkg status and behaves like <=. So there is probably some bug in opkg still hidden :/ ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] license.bbclass fixes
On Thu, Sep 27, 2012 at 10:08 AM, Saul Wold wrote: > On 09/26/2012 02:50 PM, Elizabeth Flanagan wrote: >> >> [YOCTO #3118] >> >> license.conf hasn't been being parsed. This commit series ensures that >> license.conf is parsed, that it contains useful variables that should be >> in a global conf file and that those variables are not kept within >> license.bbclass. >> > So where is the inherit license bbclass? For the yocto project it's an INHERIT += within poky.conf. meta-angstrom does not inherit it within conf/distro/include/angstrom.inc. -b > > Sau! > > >> This also fixes an discreprancy between the documentation of LICENSE_PATH >> (which >> is what we tell people to use) and what we were using "LICENSE_DIR". This >> ensures >> that when the end user needs to add additional licenses, that they use >> LICENSE_PATH += "path/to/additional/licenses" and that it works. >> > >> The following changes since commit >> 0b09e50810162a07ef0aecee91ee32b4a36334a3: >> >>busybox: Fix misplaced quote (2012-09-26 18:28:36 +0100) >> >> are available in the git repository at: >>git://git.yoctoproject.org/poky-contrib eflanagan/LICENSE_PATH >> >> http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=eflanagan/LICENSE_PATH >> >> Elizabeth Flanagan (3): >>license.bbclass: Variable standardization >>bitbake.conf: parse license config >>license.conf/bbclass: Move globals to license.conf >> >> meta/classes/license.bbclass | 67 >> +- >> meta/conf/bitbake.conf |1 + >> meta/conf/licenses.conf | 64 >> >> 3 files changed, 66 insertions(+), 66 deletions(-) >> > -- Elizabeth Flanagan Yocto Project Build and Release ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] license.bbclass fixes
On 09/27/2012 04:50 PM, Flanagan, Elizabeth wrote: On Thu, Sep 27, 2012 at 10:08 AM, Saul Wold wrote: On 09/26/2012 02:50 PM, Elizabeth Flanagan wrote: [YOCTO #3118] license.conf hasn't been being parsed. This commit series ensures that license.conf is parsed, that it contains useful variables that should be in a global conf file and that those variables are not kept within license.bbclass. So where is the inherit license bbclass? For the yocto project it's an INHERIT += within poky.conf. meta-angstrom does not inherit it within conf/distro/include/angstrom.inc. -b Acked-by: Saul Wold Sau! This also fixes an discreprancy between the documentation of LICENSE_PATH (which is what we tell people to use) and what we were using "LICENSE_DIR". This ensures that when the end user needs to add additional licenses, that they use LICENSE_PATH += "path/to/additional/licenses" and that it works. The following changes since commit 0b09e50810162a07ef0aecee91ee32b4a36334a3: busybox: Fix misplaced quote (2012-09-26 18:28:36 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib eflanagan/LICENSE_PATH http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=eflanagan/LICENSE_PATH Elizabeth Flanagan (3): license.bbclass: Variable standardization bitbake.conf: parse license config license.conf/bbclass: Move globals to license.conf meta/classes/license.bbclass | 67 +- meta/conf/bitbake.conf |1 + meta/conf/licenses.conf | 64 3 files changed, 66 insertions(+), 66 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 09/10] binutils.inc: add vardep on multiarch DISTRO_FEATURE
binutils will build differently if this feature is enabled, so make the do_configure step depend on it Signed-off-by: Matthew McClintock --- Not sure if we should try to fix via configure options v2: update commit message a bit meta/recipes-devtools/binutils/binutils.inc |2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/recipes-devtools/binutils/binutils.inc b/meta/recipes-devtools/binutils/binutils.inc index ee748a4..ff64882 100644 --- a/meta/recipes-devtools/binutils/binutils.inc +++ b/meta/recipes-devtools/binutils/binutils.inc @@ -80,6 +80,8 @@ export CC_FOR_BUILD = "LD_LIBRARY_PATH= ${BUILD_CC}" export CPP_FOR_BUILD = "${BUILD_CPP}" export CFLAGS_FOR_BUILD = "${BUILD_CFLAGS}" +MULTIARCH := "${@bb.utils.contains("DISTRO_FEATURES", "multiarch", "yes", "no", d)}" +do_configure[vardeps] += "MULTIARCH" do_configure () { (cd ${S}; gnu-configize) || die "Failed to run gnu-configize" oe_runconf -- 1.7.9.7 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 05/10] arch-powerpc.inc: add altivec as a valid tune feature
Signed-off-by: Matthew McClintock --- v2: no changes This patch and the others should fix Yocto bug #3072 meta/conf/machine/include/powerpc/arch-powerpc.inc |2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc b/meta/conf/machine/include/powerpc/arch-powerpc.inc index 12909d9..ae81cde 100644 --- a/meta/conf/machine/include/powerpc/arch-powerpc.inc +++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc @@ -19,6 +19,8 @@ TUNEVALID[fpu-soft] = "Use software FPU." TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "-msoft-float", "", d)}" TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "soft", "", d)}" +TUNEVALID[altivec] = "Altivec" + # Basic tune definitions AVAILTUNES += "powerpc powerpc-nf" TUNE_FEATURES_tune-powerpc-nf = "m32 fpu-soft" -- 1.7.9.7 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 04/10] eglibc_2.16.bb: refresh fsl-ppc-no-fsqrt.patch for Freescale targets
Signed-off-by: Matthew McClintock --- v2: refresh for all Freescale targets, and fix mixup between single and double precision .../eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch | 50 ++-- meta/recipes-core/eglibc/eglibc_2.16.bb|2 +- 2 files changed, 47 insertions(+), 5 deletions(-) diff --git a/meta/recipes-core/eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch b/meta/recipes-core/eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch index 712b353..f619f08 100644 --- a/meta/recipes-core/eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch +++ b/meta/recipes-core/eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch @@ -9,8 +9,8 @@ Upstream-Status: Pending Index: libc/sysdeps/powerpc/fpu/math_private.h === libc.orig/sysdeps/powerpc/fpu/math_private.h 2012-09-03 22:37:58.0 -0700 -+++ libc/sysdeps/powerpc/fpu/math_private.h2012-09-17 09:35:09.709124003 -0700 +--- libc.orig/sysdeps/powerpc/fpu/math_private.h libc/sysdeps/powerpc/fpu/math_private.h @@ -25,10 +25,12 @@ #include #include_next @@ -30,8 +30,50 @@ Index: libc/sysdeps/powerpc/fpu/math_private.h extern double __slow_ieee754_sqrt (double); Index: libc/ports/sysdeps/powerpc/powerpc64/e5500/fpu/math_private.h === /dev/null 1970-01-01 00:00:00.0 + -+++ libc/ports/sysdeps/powerpc/powerpc64/e5500/fpu/math_private.h 2012-09-17 09:56:59.129124074 -0700 +--- /dev/null libc/ports/sysdeps/powerpc/powerpc64/e5500/fpu/math_private.h +@@ -0,0 +1,9 @@ ++#ifndef _E5500_MATH_PRIVATE_H_ ++#define _E5500_MATH_PRIVATE_H_ 1 ++/* E5500 core FPU does not implement ++ fsqrt */ ++ ++#define __CPU_HAS_FSQRT 0 ++#include_next ++ ++#endif /* _E5500_MATH_PRIVATE_H_ */ +Index: libc/ports/sysdeps/powerpc/powerpc64/e6500/fpu/math_private.h +=== +--- /dev/null libc/ports/sysdeps/powerpc/powerpc64/e6500/fpu/math_private.h +@@ -0,0 +1,9 @@ ++#ifndef _E6500_MATH_PRIVATE_H_ ++#define _E6500_MATH_PRIVATE_H_ 1 ++/* E6500 core FPU does not implement ++ fsqrt */ ++ ++#define __CPU_HAS_FSQRT 0 ++#include_next ++ ++#endif /* _E6500_MATH_PRIVATE_H_ */ +Index: libc/ports/sysdeps/powerpc/powerpc32/e500mc/fpu/math_private.h +=== +--- /dev/null libc/ports/sysdeps/powerpc/powerpc32/e500mc/fpu/math_private.h +@@ -0,0 +1,9 @@ ++#ifndef _E500MC_MATH_PRIVATE_H_ ++#define _E500MC_MATH_PRIVATE_H_ 1 ++/* E500MC core FPU does not implement ++ fsqrt */ ++ ++#define __CPU_HAS_FSQRT 0 ++#include_next ++ ++#endif /* _E500MC_MATH_PRIVATE_H_ */ +Index: libc/ports/sysdeps/powerpc/powerpc32/e5500/fpu/math_private.h +=== +--- /dev/null libc/ports/sysdeps/powerpc/powerpc32/e5500/fpu/math_private.h @@ -0,0 +1,9 @@ +#ifndef _E5500_MATH_PRIVATE_H_ +#define _E5500_MATH_PRIVATE_H_ 1 diff --git a/meta/recipes-core/eglibc/eglibc_2.16.bb b/meta/recipes-core/eglibc/eglibc_2.16.bb index 5d88831..a0824cd 100644 --- a/meta/recipes-core/eglibc/eglibc_2.16.bb +++ b/meta/recipes-core/eglibc/eglibc_2.16.bb @@ -3,7 +3,7 @@ require eglibc.inc SRCREV = "20393" DEPENDS += "gperf-native kconfig-frontends-native" -PR = "r13" +PR = "r14" PR_append = "+svnr${SRCPV}" EGLIBC_BRANCH="eglibc-2_16" -- 1.7.9.7 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 08/10] insane.bbclass: skip checking arch (machine/bits) for powerpc kernel recipe
For a 32-bit machine, we still might always (or optionally) want to build a 64-bit kernel so we add an exception. Signed-off-by: Matthew McClintock --- Not sure if we should just skip for all virtual/kernel's? Should we use some variable for this instead? -BUILD_64BIT_KERNEL? PROMOTE_TO_64BIT_KERNEL? meta/classes/insane.bbclass |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass index 1fb8970..173b71f 100644 --- a/meta/classes/insane.bbclass +++ b/meta/classes/insane.bbclass @@ -402,11 +402,13 @@ def package_qa_check_arch(path,name,d, elf, messages): # Check the architecture and endiannes of the binary if not ((machine == elf.machine()) or \ - ("virtual/kernel" in provides) and (target_os == "linux-gnux32")): + ("virtual/kernel" in provides) and (target_os == "linux-gnux32") or \ + ("virtual/kernel" in provides) and (target_arch == "powerpc")): messages.append("Architecture did not match (%d to %d) on %s" % \ (machine, elf.machine(), package_qa_clean_path(path,d))) elif not ((bits == elf.abiSize()) or \ - ("virtual/kernel" in provides) and (target_os == "linux-gnux32")): + ("virtual/kernel" in provides) and (target_os == "linux-gnux32") or \ + ("virtual/kernel" in provides) and (target_arch == "powerpc")): messages.append("Bit size did not match (%d to %d) %s on %s" % \ (bits, elf.abiSize(), bpn, package_qa_clean_path(path,d))) elif not littleendian == elf.isLittleEndian(): -- 1.7.9.7 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 07/10] flac_1.2.1.bb: use TUNE_FEATURES to enable/disable altivec
Signed-off-by: Matthew McClintock --- v2: no changes meta/recipes-multimedia/flac/flac_1.2.1.bb |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/meta/recipes-multimedia/flac/flac_1.2.1.bb b/meta/recipes-multimedia/flac/flac_1.2.1.bb index 157128f..6520b71 100644 --- a/meta/recipes-multimedia/flac/flac_1.2.1.bb +++ b/meta/recipes-multimedia/flac/flac_1.2.1.bb @@ -36,10 +36,8 @@ EXTRA_OECONF = "--disable-oggtest --disable-id3libtest \ --without-xmms-exec-prefix \ --without-libiconv-prefix \ --without-id3lib" -EXTRA_OECONF_prepend_e500mc = "--disable-altivec " -EXTRA_OECONF_prepend_e5500 = "--disable-altivec " -EXTRA_OECONF_prepend_e5500-64b = "--disable-altivec " -EXTRA_OECONF_prepend_mpc8315e-rdb = "--disable-altivec " + +EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "altivec", " --enable-altivec", " --disable-altivec", d)}" PACKAGES += "libflac libflac++ liboggflac liboggflac++" FILES_${PN} = "${bindir}/*" -- 1.7.9.7 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 03/10] eglibc_2.16.bb: refresh ppc_slow_ieee754_sqrt.patch for Freescale targets
Make same changes for e6500 fpu as done with others Signed-off-by: Matthew McClintock --- v2: refresh patch for other new arches that were added by the previous commit which was causing new build errors .../eglibc/eglibc-2.16/ppc_slow_ieee754_sqrt.patch | 278 ++-- meta/recipes-core/eglibc/eglibc_2.16.bb|2 +- 2 files changed, 261 insertions(+), 19 deletions(-) diff --git a/meta/recipes-core/eglibc/eglibc-2.16/ppc_slow_ieee754_sqrt.patch b/meta/recipes-core/eglibc/eglibc-2.16/ppc_slow_ieee754_sqrt.patch index 9a932ff..60532cb 100644 --- a/meta/recipes-core/eglibc/eglibc-2.16/ppc_slow_ieee754_sqrt.patch +++ b/meta/recipes-core/eglibc/eglibc-2.16/ppc_slow_ieee754_sqrt.patch @@ -5,9 +5,9 @@ Signed-off-by: Khem Raj Upstream-Status: Pending Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c === libc.orig/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c 2012-07-03 22:36:01.172386436 -0700 -+++ libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c 2012-07-03 23:04:37.396469515 -0700 -@@ -40,7 +40,7 @@ +--- libc.orig/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c +@@ -40,7 +40,7 @@ static const float half = 0.5; simultaneously. */ double @@ -16,7 +16,7 @@ Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c { if (__builtin_expect (b > 0, 1)) { -@@ -77,7 +77,7 @@ +@@ -77,7 +77,7 @@ __ieee754_sqrt (double b) /* Handle small numbers by scaling. */ if (__builtin_expect ((u.parts.msw & 0x7ff0) <= 0x0200, 0)) @@ -25,7 +25,7 @@ Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c #define FMADD(a_, c_, b_) \ ({ double __r;\ -@@ -126,4 +126,12 @@ +@@ -126,4 +126,12 @@ __ieee754_sqrt (double b) } return f_wash (b); } @@ -40,9 +40,9 @@ Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c strong_alias (__ieee754_sqrt, __sqrt_finite) Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c === libc.orig/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c 2012-07-03 22:36:01.172386436 -0700 -+++ libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c 2012-07-03 23:07:06.260476775 -0700 -@@ -38,7 +38,7 @@ +--- libc.orig/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c +@@ -38,7 +38,7 @@ static const float threehalf = 1.5; square root. */ float @@ -51,7 +51,7 @@ Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c { if (__builtin_expect (b > 0, 1)) { -@@ -93,4 +93,10 @@ +@@ -93,4 +93,10 @@ __ieee754_sqrtf (float b) } return f_washf (b); } @@ -64,9 +64,9 @@ Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c strong_alias (__ieee754_sqrtf, __sqrtf_finite) Index: libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c === libc.orig/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c 2012-07-03 22:36:01.176386435 -0700 -+++ libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c 2012-07-03 23:14:16.328497458 -0700 -@@ -40,7 +40,7 @@ +--- libc.orig/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c +@@ -40,7 +40,7 @@ static const float half = 0.5; simultaneously. */ double @@ -75,7 +75,7 @@ Index: libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c { if (__builtin_expect (b > 0, 1)) { -@@ -77,7 +77,7 @@ +@@ -77,7 +77,7 @@ __ieee754_sqrt (double b) /* Handle small numbers by scaling. */ if (__builtin_expect ((u.parts.msw & 0x7ff0) <= 0x0200, 0)) @@ -84,7 +84,7 @@ Index: libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c #define FMADD(a_, c_, b_) \ ({ double __r;\ -@@ -126,4 +126,12 @@ +@@ -126,4 +126,12 @@ __ieee754_sqrt (double b) } return f_wash (b); } @@ -99,9 +99,9 @@ Index: libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c strong_alias (__ieee754_sqrt, __sqrt_finite) Index: libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c === libc.orig/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c2012-07-03 22:36:01.176386435 -0700 -+++ libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c 2012-07-03 23:13:52.732496373 -0700 -@@ -38,7 +38,7 @@ +--- libc.orig/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c +@@ -38,7 +38,7 @@ static const float threehalf = 1.5; square root. */ float @@ -110,7 +110,7 @@ Index: libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c { if (__builtin_expect (b > 0, 1)) {
[OE-core] [PATCH v2 06/10] tune-ppce6500.inc: add e6500 tune files
Also supports a new altivec TUNE_FEATURE Signed-off-by: Matthew McClintock --- v2: no changes meta/conf/machine/include/tune-ppce6500.inc | 21 + 1 file changed, 21 insertions(+) create mode 100644 meta/conf/machine/include/tune-ppce6500.inc diff --git a/meta/conf/machine/include/tune-ppce6500.inc b/meta/conf/machine/include/tune-ppce6500.inc new file mode 100644 index 000..982a7a4 --- /dev/null +++ b/meta/conf/machine/include/tune-ppce6500.inc @@ -0,0 +1,21 @@ +DEFAULTTUNE ?= "ppce6500" + +require conf/machine/include/powerpc/arch-powerpc64.inc + +TUNEVALID[e6500] = "Enable Freescale e6500 specific processor optimizations" +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "e6500", "-mcpu=e6500", "", d)}" + +AVAILTUNES += "ppce6500 ppc64e6500" +TUNE_FEATURES_tune-ppce6500 = "m32 fpu-hard e6500 altivec" +BASE_LIB_tune-ppce6500 = "lib" +TUNE_PKGARCH_tune-ppce6500 = "ppce6500" +PACKAGE_EXTRA_ARCHS_tune-ppce6500 = "${PACKAGE_EXTRA_ARCHS_tune-powerpc} ppce6500" + +TUNE_FEATURES_tune-ppc64e6500 = "m64 fpu-hard e6500 altivec" +BASE_LIB_tune-ppc64e6500 = "lib64" +TUNE_PKGARCH_tune-ppc64e6500 = "ppc64e6500" +PACKAGE_EXTRA_ARCHS_tune-ppc64e6500 = "${PACKAGE_EXTRA_ARCHS_tune-powerpc64} ppc64e6500" + +# glibc configure options to get e6500 specific library +GLIBC_EXTRA_OECONF_powerpc64 += "${@bb.utils.contains("TUNE_FEATURES", "e6500", "--with-cpu=e6500", "", d)}" +GLIBC_EXTRA_OECONF_powerpc += "${@bb.utils.contains("TUNE_FEATURES", "e6500", "--with-cpu=603e", "", d)}" -- 1.7.9.7 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 10/10] libx11.inc: fix build issues for older CentOS distros
Fixes these sorts of issues present on older gcc (CentOS 5.x in this case) | cc1: error: unrecognized command line option "-Werror=implicit" | cc1: error: unrecognized command line option "-Werror=nonnull" | cc1: error: unrecognized command line option "-Werror=init-self" | cc1: error: unrecognized command line option "-Werror=main" | cc1: error: unrecognized command line option "-Werror=missing-braces" | cc1: error: unrecognized command line option "-Werror=sequence-point" | cc1: error: unrecognized command line option "-Werror=return-type" | cc1: error: unrecognized command line option "-Werror=trigraphs" | cc1: error: unrecognized command line option "-Werror=array-bounds" | cc1: error: unrecognized command line option "-Werror=write-strings" | cc1: error: unrecognized command line option "-Werror=address" | cc1: error: unrecognized command line option "-Werror=int-to-pointer-cast" | cc1: error: unrecognized command line option "-Werror=pointer-to-int-cast" Also fixes: makekeys-makekeys.o: In function `main': makekeys.c:(.text+0x85): undefined reference to `__isoc99_sscanf' makekeys.c:(.text+0xa7): undefined reference to `__isoc99_sscanf' collect2: ld returned 1 exit status make: *** [makekeys] Error 1 Older libc do not have this defined, we can use the -D_GNU_SOURCE to the compiler to prevent generating calls to this function and make linking work Signed-off-by: Matthew McClintock --- This replaces the previous patch series that fixes libx11 issues meta/recipes-graphics/xorg-lib/libx11.inc |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/meta/recipes-graphics/xorg-lib/libx11.inc b/meta/recipes-graphics/xorg-lib/libx11.inc index 3ecd9e5..97bd1c2 100644 --- a/meta/recipes-graphics/xorg-lib/libx11.inc +++ b/meta/recipes-graphics/xorg-lib/libx11.inc @@ -11,7 +11,7 @@ inherit siteinfo FILESPATH = "${FILE_DIRNAME}/libx11" PE = "1" -INC_PR = "r8" +INC_PR = "r9" PROVIDES = "virtual/libx11" @@ -23,6 +23,7 @@ DEPENDS += "xproto xextproto xtrans libxcb kbproto inputproto" DEPENDS += "xproto-native" EXTRA_OECONF += "--with-keysymdefdir=${STAGING_INCDIR}/X11/" +EXTRA_OEMAKE += 'CWARNFLAGS=""' # Let people with incredibly archaic requirements enable Xcms and BigFont, but # disable them by default. @@ -33,7 +34,7 @@ PACKAGECONFIG[bigfont] = "--enable-xf86bigfont,--disable-xf86bigfont,xf86bigfont # src/util/makekeys needs to be compiled natively, so tell it what compiler to # use. export CC_FOR_BUILD = "${BUILD_CC}" -export CFLAGS_FOR_BUILD = "${BUILD_CFLAGS}" +export CFLAGS_FOR_BUILD = "${BUILD_CFLAGS} -D_GNU_SOURCE" export CPPFLAGS_FOR_BUILD = "${BUILD_CPPFLAGS}" export LDFLAGS_FOR_BUILD = "${BUILD_LDFLAGS}" -- 1.7.9.7 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 02/10] eglibc_2.16.bb: refresh ppc-sqrt_finite.patch for Freescale targets
Signed-off-by: Matthew McClintock --- v2: add the current changes for the new arches here as well .../eglibc/eglibc-2.16/ppc-sqrt_finite.patch | 104 +--- meta/recipes-core/eglibc/eglibc_2.16.bb|2 +- 2 files changed, 89 insertions(+), 17 deletions(-) diff --git a/meta/recipes-core/eglibc/eglibc-2.16/ppc-sqrt_finite.patch b/meta/recipes-core/eglibc/eglibc-2.16/ppc-sqrt_finite.patch index 5289051..6ea666b 100644 --- a/meta/recipes-core/eglibc/eglibc-2.16/ppc-sqrt_finite.patch +++ b/meta/recipes-core/eglibc/eglibc-2.16/ppc-sqrt_finite.patch @@ -16,9 +16,9 @@ ChangeLog Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c === libc.orig/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c 2012-01-06 18:07:42.296909187 -0800 -+++ libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c 2012-01-06 18:09:22.572914856 -0800 -@@ -39,14 +39,8 @@ +--- libc.orig/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c +@@ -39,14 +39,8 @@ static const float half = 0.5; We find the actual square root and half of its reciprocal simultaneously. */ @@ -33,16 +33,16 @@ Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c { if (__builtin_expect (b > 0, 1)) { -@@ -132,3 +126,4 @@ +@@ -132,3 +126,4 @@ __ieee754_sqrt (b) } return f_wash (b); } +strong_alias (__ieee754_sqrt, __sqrt_finite) Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c === libc.orig/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c 2012-01-06 18:10:37.068917644 -0800 -+++ libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c 2012-01-06 18:11:33.408920635 -0800 -@@ -37,14 +37,8 @@ +--- libc.orig/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c +@@ -37,14 +37,8 @@ static const float threehalf = 1.5; We find the reciprocal square root and use that to compute the actual square root. */ @@ -57,16 +57,16 @@ Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c { if (__builtin_expect (b > 0, 1)) { -@@ -99,3 +93,4 @@ +@@ -99,3 +93,4 @@ __ieee754_sqrtf (b) } return f_washf (b); } +strong_alias (__ieee754_sqrtf, __sqrtf_finite) Index: libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c === libc.orig/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c 2012-01-06 18:11:51.460925644 -0800 -+++ libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c 2012-01-06 18:12:39.344924405 -0800 -@@ -39,14 +39,8 @@ +--- libc.orig/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c +@@ -39,14 +39,8 @@ static const float half = 0.5; We find the actual square root and half of its reciprocal simultaneously. */ @@ -81,16 +81,16 @@ Index: libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c { if (__builtin_expect (b > 0, 1)) { -@@ -132,3 +126,4 @@ +@@ -132,3 +126,4 @@ __ieee754_sqrt (b) } return f_wash (b); } +strong_alias (__ieee754_sqrt, __sqrt_finite) Index: libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c === libc.orig/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c2012-01-06 18:13:00.892924586 -0800 -+++ libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c 2012-01-06 18:15:27.992931106 -0800 -@@ -37,14 +37,8 @@ +--- libc.orig/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c +@@ -37,14 +37,8 @@ static const float threehalf = 1.5; We find the reciprocal square root and use that to compute the actual square root. */ @@ -105,7 +105,79 @@ Index: libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c { if (__builtin_expect (b > 0, 1)) { -@@ -99,3 +93,4 @@ +@@ -99,3 +93,4 @@ __ieee754_sqrtf (b) + } + return f_washf (b); + } ++strong_alias (__ieee754_sqrtf, __sqrtf_finite) +Index: libc/sysdeps/powerpc/powerpc32/e500mc/fpu/e_sqrt.c +=== +--- libc.orig/sysdeps/powerpc/powerpc32/e500mc/fpu/e_sqrt.c libc/sysdeps/powerpc/powerpc32/e500mc/fpu/e_sqrt.c +@@ -132,3 +132,4 @@ __ieee754_sqrt (b) + } + return f_wash (b); + } ++strong_alias (__ieee754_sqrt, __sqrt_finite) +Index: libc/sysdeps/powerpc/powerpc32/e500mc/fpu/e_sqrtf.c +=== +--- libc.orig/sysdeps/powerpc/powerpc32/e500mc/fpu/e_sqrtf.c libc/sysdeps/powerpc/powerpc32/e500mc/fpu/e_sqrtf.c +@@ -99,3 +99,4 @@ __ieee754_sqrtf (b) + } + return f_washf (b); + } ++strong_alias (__ieee754_sqrtf, __sqrtf_finite) +Index: libc/sysdeps/powerpc/powerpc32/e5500/fpu/e_sqrt.c +=== +--- libc.orig/s
[OE-core] [PATCH v2 04/10] eglibc_2.16.bb: refresh fsl-ppc-no-fsqrt.patch for Freescale targets
Signed-off-by: Matthew McClintock --- v2: refresh for all Freescale targets, and fix mixup between single and double precision v3: add 32-bit e6500 which was missed .../eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch | 68 ++-- meta/recipes-core/eglibc/eglibc_2.16.bb|2 +- 2 files changed, 65 insertions(+), 5 deletions(-) diff --git a/meta/recipes-core/eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch b/meta/recipes-core/eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch index 712b353..89a330f 100644 --- a/meta/recipes-core/eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch +++ b/meta/recipes-core/eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch @@ -9,8 +9,8 @@ Upstream-Status: Pending Index: libc/sysdeps/powerpc/fpu/math_private.h === libc.orig/sysdeps/powerpc/fpu/math_private.h 2012-09-03 22:37:58.0 -0700 -+++ libc/sysdeps/powerpc/fpu/math_private.h2012-09-17 09:35:09.709124003 -0700 +--- libc.orig/sysdeps/powerpc/fpu/math_private.h libc/sysdeps/powerpc/fpu/math_private.h @@ -25,10 +25,12 @@ #include #include_next @@ -30,8 +30,8 @@ Index: libc/sysdeps/powerpc/fpu/math_private.h extern double __slow_ieee754_sqrt (double); Index: libc/ports/sysdeps/powerpc/powerpc64/e5500/fpu/math_private.h === /dev/null 1970-01-01 00:00:00.0 + -+++ libc/ports/sysdeps/powerpc/powerpc64/e5500/fpu/math_private.h 2012-09-17 09:56:59.129124074 -0700 +--- /dev/null libc/ports/sysdeps/powerpc/powerpc64/e5500/fpu/math_private.h @@ -0,0 +1,9 @@ +#ifndef _E5500_MATH_PRIVATE_H_ +#define _E5500_MATH_PRIVATE_H_ 1 @@ -42,3 +42,63 @@ Index: libc/ports/sysdeps/powerpc/powerpc64/e5500/fpu/math_private.h +#include_next + +#endif /* _E5500_MATH_PRIVATE_H_ */ +Index: libc/ports/sysdeps/powerpc/powerpc64/e6500/fpu/math_private.h +=== +--- /dev/null libc/ports/sysdeps/powerpc/powerpc64/e6500/fpu/math_private.h +@@ -0,0 +1,9 @@ ++#ifndef _E6500_MATH_PRIVATE_H_ ++#define _E6500_MATH_PRIVATE_H_ 1 ++/* E6500 core FPU does not implement ++ fsqrt */ ++ ++#define __CPU_HAS_FSQRT 0 ++#include_next ++ ++#endif /* _E6500_MATH_PRIVATE_H_ */ +Index: libc/ports/sysdeps/powerpc/powerpc32/e500mc/fpu/math_private.h +=== +--- /dev/null libc/ports/sysdeps/powerpc/powerpc32/e500mc/fpu/math_private.h +@@ -0,0 +1,9 @@ ++#ifndef _E500MC_MATH_PRIVATE_H_ ++#define _E500MC_MATH_PRIVATE_H_ 1 ++/* E500MC core FPU does not implement ++ fsqrt */ ++ ++#define __CPU_HAS_FSQRT 0 ++#include_next ++ ++#endif /* _E500MC_MATH_PRIVATE_H_ */ +Index: libc/ports/sysdeps/powerpc/powerpc32/e5500/fpu/math_private.h +=== +--- /dev/null libc/ports/sysdeps/powerpc/powerpc32/e5500/fpu/math_private.h +@@ -0,0 +1,9 @@ ++#ifndef _E5500_MATH_PRIVATE_H_ ++#define _E5500_MATH_PRIVATE_H_ 1 ++/* E5500 core FPU does not implement ++ fsqrt */ ++ ++#define __CPU_HAS_FSQRT 0 ++#include_next ++ ++#endif /* _E5500_MATH_PRIVATE_H_ */ +Index: libc/ports/sysdeps/powerpc/powerpc32/e6500/fpu/math_private.h +=== +--- libc.orig/ports/sysdeps/powerpc/powerpc32/e6500/fpu/math_private.h libc/ports/sysdeps/powerpc/powerpc32/e6500/fpu/math_private.h +@@ -1,9 +1,9 @@ +-#ifndef _E5500_MATH_PRIVATE_H_ +-#define _E5500_MATH_PRIVATE_H_ 1 +-/* E5500 core FPU does not implement ++#ifndef _E6500_MATH_PRIVATE_H_ ++#define _E6500_MATH_PRIVATE_H_ 1 ++/* E6500 core FPU does not implement +fsqrt */ + + #define __CPU_HAS_FSQRT 0 + #include_next + +-#endif /* _E5500_MATH_PRIVATE_H_ */ ++#endif /* _E6500_MATH_PRIVATE_H_ */ diff --git a/meta/recipes-core/eglibc/eglibc_2.16.bb b/meta/recipes-core/eglibc/eglibc_2.16.bb index 5d88831..a0824cd 100644 --- a/meta/recipes-core/eglibc/eglibc_2.16.bb +++ b/meta/recipes-core/eglibc/eglibc_2.16.bb @@ -3,7 +3,7 @@ require eglibc.inc SRCREV = "20393" DEPENDS += "gperf-native kconfig-frontends-native" -PR = "r13" +PR = "r14" PR_append = "+svnr${SRCPV}" EGLIBC_BRANCH="eglibc-2_16" -- 1.7.9.7 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] perl install error
Hi On ppc64 I am getting | Warning: perl appears in your path in the following locations beyond where | we just installed it: | /work/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/bin/perl-native/perl | | make[1]: Nothing to be done for `install.man'. | make[1]: Leaving directory `/work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/perl-5.14.2' | ln: failed to create symbolic link `/work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/image//usr/lib64/perl5': No such file or directory | ERROR: Function failed: do_install (see /work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/temp/log.do_install.6656 for further information) ERROR: Task 1679 (/work/yocto/poky/meta/recipes-devtools/perl/perl_5.14.2.bb, do_install) failed with exit code '1' NOTE: Tasks Summary: Attempted 4082 tasks of which 4057 didn't need to be rerun and 1 failed. It was working fine yesterday anyone else seeing it ? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] perl install error
On Sep 27, 2012, at 8:22 PM, Khem Raj wrote: > Hi > > On ppc64 I am getting > > | Warning: perl appears in your path in the following locations beyond where > | we just installed it: > | > /work/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/bin/perl-native/perl > | > | make[1]: Nothing to be done for `install.man'. > | make[1]: Leaving directory > `/work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/perl-5.14.2' > | ln: failed to create symbolic link > `/work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/image//usr/lib64/perl5': > No such file or directory > | ERROR: Function failed: do_install (see > /work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/temp/log.do_install.6656 > for further information) > ERROR: Task 1679 (/work/yocto/poky/meta/recipes-devtools/perl/perl_5.14.2.bb, > do_install) failed with exit code '1' > NOTE: Tasks Summary: Attempted 4082 tasks of which 4057 didn't need to be > rerun and 1 failed. > > > It was working fine yesterday > anyone else seeing it ? If I revert perl: Fix nativesdk install path Commit 38234f2e276356b1d77a87ceabc486107e336d19 tried to fix the sed expressions by anchoring the left side of the search regexp to prevent $prefix$prefix type expression in the perl config. For nativesdk this is not enough. Adding anchors on both side fixes this. Signed-off-by: Christian Glindkamp Signed-off-by: Richard Purdie It works again Thanks -Khem ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 04/10] eglibc_2.16.bb: refresh fsl-ppc-no-fsqrt.patch for Freescale targets
Signed-off-by: Matthew McClintock --- v2: refresh for all Freescale targets, and fix mixup between single and double precision v3: add 32-bit e6500 which was missed v4: Screwed up the patch, fixed in v4 All these patches are on my tree in poky-contrib: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/master .../eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch | 64 ++-- meta/recipes-core/eglibc/eglibc_2.16.bb|2 +- 2 files changed, 61 insertions(+), 5 deletions(-) diff --git a/meta/recipes-core/eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch b/meta/recipes-core/eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch index 712b353..511ee9d 100644 --- a/meta/recipes-core/eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch +++ b/meta/recipes-core/eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch @@ -9,8 +9,8 @@ Upstream-Status: Pending Index: libc/sysdeps/powerpc/fpu/math_private.h === libc.orig/sysdeps/powerpc/fpu/math_private.h 2012-09-03 22:37:58.0 -0700 -+++ libc/sysdeps/powerpc/fpu/math_private.h2012-09-17 09:35:09.709124003 -0700 +--- libc.orig/sysdeps/powerpc/fpu/math_private.h libc/sysdeps/powerpc/fpu/math_private.h @@ -25,10 +25,12 @@ #include #include_next @@ -30,8 +30,8 @@ Index: libc/sysdeps/powerpc/fpu/math_private.h extern double __slow_ieee754_sqrt (double); Index: libc/ports/sysdeps/powerpc/powerpc64/e5500/fpu/math_private.h === /dev/null 1970-01-01 00:00:00.0 + -+++ libc/ports/sysdeps/powerpc/powerpc64/e5500/fpu/math_private.h 2012-09-17 09:56:59.129124074 -0700 +--- /dev/null libc/ports/sysdeps/powerpc/powerpc64/e5500/fpu/math_private.h @@ -0,0 +1,9 @@ +#ifndef _E5500_MATH_PRIVATE_H_ +#define _E5500_MATH_PRIVATE_H_ 1 @@ -42,3 +42,59 @@ Index: libc/ports/sysdeps/powerpc/powerpc64/e5500/fpu/math_private.h +#include_next + +#endif /* _E5500_MATH_PRIVATE_H_ */ +Index: libc/ports/sysdeps/powerpc/powerpc64/e6500/fpu/math_private.h +=== +--- /dev/null libc/ports/sysdeps/powerpc/powerpc64/e6500/fpu/math_private.h +@@ -0,0 +1,9 @@ ++#ifndef _E6500_MATH_PRIVATE_H_ ++#define _E6500_MATH_PRIVATE_H_ 1 ++/* E6500 core FPU does not implement ++ fsqrt */ ++ ++#define __CPU_HAS_FSQRT 0 ++#include_next ++ ++#endif /* _E6500_MATH_PRIVATE_H_ */ +Index: libc/ports/sysdeps/powerpc/powerpc32/e500mc/fpu/math_private.h +=== +--- /dev/null libc/ports/sysdeps/powerpc/powerpc32/e500mc/fpu/math_private.h +@@ -0,0 +1,9 @@ ++#ifndef _E500MC_MATH_PRIVATE_H_ ++#define _E500MC_MATH_PRIVATE_H_ 1 ++/* E500MC core FPU does not implement ++ fsqrt */ ++ ++#define __CPU_HAS_FSQRT 0 ++#include_next ++ ++#endif /* _E500MC_MATH_PRIVATE_H_ */ +Index: libc/ports/sysdeps/powerpc/powerpc32/e5500/fpu/math_private.h +=== +--- /dev/null libc/ports/sysdeps/powerpc/powerpc32/e5500/fpu/math_private.h +@@ -0,0 +1,9 @@ ++#ifndef _E5500_MATH_PRIVATE_H_ ++#define _E5500_MATH_PRIVATE_H_ 1 ++/* E5500 core FPU does not implement ++ fsqrt */ ++ ++#define __CPU_HAS_FSQRT 0 ++#include_next ++ ++#endif /* _E5500_MATH_PRIVATE_H_ */ +Index: libc/ports/sysdeps/powerpc/powerpc32/e6500/fpu/math_private.h +=== +--- /dev/null libc/ports/sysdeps/powerpc/powerpc32/e6500/fpu/math_private.h +@@ -0,0 +1,9 @@ ++#ifndef _E6500_MATH_PRIVATE_H_ ++#define _E6500_MATH_PRIVATE_H_ 1 ++/* E6500 core FPU does not implement ++ fsqrt */ ++ ++#define __CPU_HAS_FSQRT 0 ++#include_next ++ ++#endif /* _E6500_MATH_PRIVATE_H_ */ diff --git a/meta/recipes-core/eglibc/eglibc_2.16.bb b/meta/recipes-core/eglibc/eglibc_2.16.bb index 5d88831..a0824cd 100644 --- a/meta/recipes-core/eglibc/eglibc_2.16.bb +++ b/meta/recipes-core/eglibc/eglibc_2.16.bb @@ -3,7 +3,7 @@ require eglibc.inc SRCREV = "20393" DEPENDS += "gperf-native kconfig-frontends-native" -PR = "r13" +PR = "r14" PR_append = "+svnr${SRCPV}" EGLIBC_BRANCH="eglibc-2_16" -- 1.7.9.7 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] perl install error
Khem, I'm just not looking at a similiar issue. Do this: cat tmp/sstate-control/manifest-* | grep usr/lib/perl5 And see which recipe is making this folder. It should be the perl recipe, first not some other recipe... Side question are you using FSL layers? -M On Thu, Sep 27, 2012 at 10:28 PM, Khem Raj wrote: > > On Sep 27, 2012, at 8:22 PM, Khem Raj wrote: > >> Hi >> >> On ppc64 I am getting >> >> | Warning: perl appears in your path in the following locations beyond where >> | we just installed it: >> | >> /work/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/bin/perl-native/perl >> | >> | make[1]: Nothing to be done for `install.man'. >> | make[1]: Leaving directory >> `/work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/perl-5.14.2' >> | ln: failed to create symbolic link >> `/work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/image//usr/lib64/perl5': >> No such file or directory >> | ERROR: Function failed: do_install (see >> /work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/temp/log.do_install.6656 >> for further information) >> ERROR: Task 1679 >> (/work/yocto/poky/meta/recipes-devtools/perl/perl_5.14.2.bb, do_install) >> failed with exit code '1' >> NOTE: Tasks Summary: Attempted 4082 tasks of which 4057 didn't need to be >> rerun and 1 failed. >> >> >> It was working fine yesterday >> anyone else seeing it ? > > > If I revert > > perl: Fix nativesdk install path > Commit 38234f2e276356b1d77a87ceabc486107e336d19 tried to fix the sed > expressions by anchoring the left side of the search regexp to prevent > $prefix$prefix type expression in the perl config. For nativesdk this is > not enough. Adding anchors on both side fixes this. > > Signed-off-by: Christian Glindkamp > Signed-off-by: Richard Purdie > > > > It works again > > Thanks > -Khem > > > > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] boost: Support enums in hash
Fixes builds which were building fine with previous versions of boost Signed-off-by: Khem Raj --- meta/recipes-support/boost/boost_1.51.0.bb|6 ++- meta/recipes-support/boost/files/hash_enums.patch | 45 + 2 files changed, 49 insertions(+), 2 deletions(-) create mode 100644 meta/recipes-support/boost/files/hash_enums.patch diff --git a/meta/recipes-support/boost/boost_1.51.0.bb b/meta/recipes-support/boost/boost_1.51.0.bb index 1564b0e..b95049f 100644 --- a/meta/recipes-support/boost/boost_1.51.0.bb +++ b/meta/recipes-support/boost/boost_1.51.0.bb @@ -2,8 +2,10 @@ include boost.inc LIC_FILES_CHKSUM = "file://LICENSE_1_0.txt;md5=e4224ccaecb14d942c71d31bef20d78c" -PR = "${INC_PR}.0" +PR = "${INC_PR}.1" -SRC_URI += "file://arm-intrinsics.patch" +SRC_URI += "file://arm-intrinsics.patch \ +file://hash_enums.patch \ + " SRC_URI[md5sum] = "4b6bd483b692fd138aef84ed2c8eb679" SRC_URI[sha256sum] = "fb2d2335a29ee7fe040a197292bfce982af84a645c81688a915c84c925b69696" diff --git a/meta/recipes-support/boost/files/hash_enums.patch b/meta/recipes-support/boost/files/hash_enums.patch new file mode 100644 index 000..368da96 --- /dev/null +++ b/meta/recipes-support/boost/files/hash_enums.patch @@ -0,0 +1,45 @@ +Allow hashing of enums. +Fixes errors like + +/opt/poky/1.3.0-1/sysroots/i586-poky-linux/usr/include/boost/functional/hash/extensions.hpp:257:34: error: no matching function for call to 'hash_value(const myspace::idx&)' + +Upstream-Status: Pending +Singed-off-by: Khem Raj + +Index: boost_1_51_0/boost/functional/hash/hash.hpp +=== +--- boost_1_51_0.orig/boost/functional/hash/hash.hpp 2012-07-15 16:28:30.0 -0700 boost_1_51_0/boost/functional/hash/hash.hpp2012-09-26 14:00:57.738364002 -0700 +@@ -15,6 +15,8 @@ + #include + #include + #include ++#include ++#include + + #if defined(BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION) + #include +@@ -89,6 +91,9 @@ + typename boost::hash_detail::long_numbers::type hash_value(T); + template + typename boost::hash_detail::ulong_numbers::type hash_value(T); ++template ++typename boost::enable_if, std::size_t>::type ++ hash_value(T); + + #if !BOOST_WORKAROUND(__DMC__, <= 0x848) + template std::size_t hash_value(T* const&); +@@ -178,7 +183,12 @@ + { + return hash_detail::hash_value_unsigned(v); + } +- ++template ++typename boost::enable_if, std::size_t>::type ++ hash_value(T v) ++{ ++ return static_cast(v); ++} + // Implementation by Alberto Barbati and Dave Harris. + #if !BOOST_WORKAROUND(__DMC__, <= 0x848) + template std::size_t hash_value(T* const& v) -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] flex,bison: Add nativesdk variants
It is needed in some SDKs that we ship own version of lex/yacc for sdk host Signed-off-by: Khem Raj --- meta/recipes-devtools/bison/bison_2.5.1.bb |2 +- meta/recipes-devtools/flex/flex_2.5.35.bb |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-devtools/bison/bison_2.5.1.bb b/meta/recipes-devtools/bison/bison_2.5.1.bb index d53c1d6..47b4a6c 100644 --- a/meta/recipes-devtools/bison/bison_2.5.1.bb +++ b/meta/recipes-devtools/bison/bison_2.5.1.bb @@ -33,4 +33,4 @@ do_install_append_virtclass-native() { BISON_PKGDATADIR=${STAGING_DATADIR_NATIVE}/bison } #bison-native encodes the staging M4 path -BBCLASSEXTEND = "native" +BBCLASSEXTEND = "native nativesdk" diff --git a/meta/recipes-devtools/flex/flex_2.5.35.bb b/meta/recipes-devtools/flex/flex_2.5.35.bb index 7419f10..2218c91 100644 --- a/meta/recipes-devtools/flex/flex_2.5.35.bb +++ b/meta/recipes-devtools/flex/flex_2.5.35.bb @@ -2,7 +2,7 @@ require flex.inc PR = "r3" LICENSE="BSD" LIC_FILES_CHKSUM = "file://COPYING;md5=e4742cf92e89040b39486a6219b68067" -BBCLASSEXTEND = "native" +BBCLASSEXTEND = "native nativesdk" SRC_URI += "file://avoid-FORTIFY-warnings.patch \ file://int-is-not-the-same-size-as-size_t.patch" -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] perl install error
On Sep 27, 2012, at 8:40 PM, McClintock Matthew-B29882 wrote: > Khem, > > I'm just not looking at a similiar issue. Do this: > just 'not' or just 'now' ? > cat tmp/sstate-control/manifest-* | grep usr/lib/perl5 > > And see which recipe is making this folder. It should be the perl > recipe, first not some other recipe… cat sstate-control/manifest-* | grep usr/lib/perl5 return nothing > > Side question are you using FSL layers? yes > > -M > > On Thu, Sep 27, 2012 at 10:28 PM, Khem Raj wrote: >> >> On Sep 27, 2012, at 8:22 PM, Khem Raj wrote: >> >>> Hi >>> >>> On ppc64 I am getting >>> >>> | Warning: perl appears in your path in the following locations beyond where >>> | we just installed it: >>> | >>> /work/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/bin/perl-native/perl >>> | >>> | make[1]: Nothing to be done for `install.man'. >>> | make[1]: Leaving directory >>> `/work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/perl-5.14.2' >>> | ln: failed to create symbolic link >>> `/work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/image//usr/lib64/perl5': >>> No such file or directory >>> | ERROR: Function failed: do_install (see >>> /work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/temp/log.do_install.6656 >>> for further information) >>> ERROR: Task 1679 >>> (/work/yocto/poky/meta/recipes-devtools/perl/perl_5.14.2.bb, do_install) >>> failed with exit code '1' >>> NOTE: Tasks Summary: Attempted 4082 tasks of which 4057 didn't need to be >>> rerun and 1 failed. >>> >>> >>> It was working fine yesterday >>> anyone else seeing it ? >> >> >> If I revert >> >> perl: Fix nativesdk install path >> Commit 38234f2e276356b1d77a87ceabc486107e336d19 tried to fix the sed >> expressions by anchoring the left side of the search regexp to prevent >> $prefix$prefix type expression in the perl config. For nativesdk this is >> not enough. Adding anchors on both side fixes this. >> >> Signed-off-by: Christian Glindkamp >> Signed-off-by: Richard Purdie >> >> >> >> It works again >> >> Thanks >> -Khem >> >> >> >> ___ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] perl install error
On Sep 27, 2012, at 8:52 PM, McClintock Matthew-B29882 wrote: > On Thu, Sep 27, 2012 at 10:43 PM, Khem Raj wrote: >> >> On Sep 27, 2012, at 8:40 PM, McClintock Matthew-B29882 >> wrote: >> >>> Khem, >>> >>> I'm just not looking at a similiar issue. Do this: >>> >> >> >> just 'not' or just 'now' ? >> >>> cat tmp/sstate-control/manifest-* | grep usr/lib/perl5 >>> >>> And see which recipe is making this folder. It should be the perl >>> recipe, first not some other recipe… >> >> >> cat sstate-control/manifest-* | grep usr/lib/perl5 >> >> return nothing > > Maybe this is not the same root cause then. reverting that commit fixed it. before that I tried to cleans state clean all perl and perl-native to no avail. > >> >>> >>> Side question are you using FSL layers? >> >> yes > > Is libhugetlbfs getting built? No ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] perl install error
On Thu, Sep 27, 2012 at 11:18 PM, Khem Raj wrote: > > On Sep 27, 2012, at 8:52 PM, McClintock Matthew-B29882 > wrote: > >> On Thu, Sep 27, 2012 at 10:43 PM, Khem Raj wrote: >>> >>> On Sep 27, 2012, at 8:40 PM, McClintock Matthew-B29882 >>> wrote: >>> Khem, I'm just not looking at a similiar issue. Do this: >>> >>> >>> just 'not' or just 'now' ? >>> cat tmp/sstate-control/manifest-* | grep usr/lib/perl5 And see which recipe is making this folder. It should be the perl recipe, first not some other recipe… >>> >>> >>> cat sstate-control/manifest-* | grep usr/lib/perl5 >>> >>> return nothing >> >> Maybe this is not the same root cause then. > > reverting that commit fixed it. before that I tried to cleans state clean all > perl and perl-native > to no avail. OK, well we got the same error and ours was from another sstate-cache installing files in /usr/lib/perl5 before perl installed it's own symlink. cleaning cache for perl did not help either. Reverting that patch could have causes rebuilds and change of ordering (possibly) that might mask the error a little longer. If ours are related. -M >> >>> Side question are you using FSL layers? >>> >>> yes >> >> Is libhugetlbfs getting built? > > No > > > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] perl install error
On Sep 27, 2012, at 9:23 PM, McClintock Matthew-B29882 wrote: > On Thu, Sep 27, 2012 at 11:18 PM, Khem Raj wrote: >> >> On Sep 27, 2012, at 8:52 PM, McClintock Matthew-B29882 >> wrote: >> >>> On Thu, Sep 27, 2012 at 10:43 PM, Khem Raj wrote: On Sep 27, 2012, at 8:40 PM, McClintock Matthew-B29882 wrote: > Khem, > > I'm just not looking at a similiar issue. Do this: > just 'not' or just 'now' ? > cat tmp/sstate-control/manifest-* | grep usr/lib/perl5 > > And see which recipe is making this folder. It should be the perl > recipe, first not some other recipe… cat sstate-control/manifest-* | grep usr/lib/perl5 return nothing >>> >>> Maybe this is not the same root cause then. >> >> reverting that commit fixed it. before that I tried to cleans state clean >> all perl and perl-native >> to no avail. > > OK, well we got the same error and ours was from another sstate-cache > installing files in /usr/lib/perl5 before perl installed it's own > symlink. cleaning cache for perl did not help either. > > Reverting that patch could have causes rebuilds and change of ordering > (possibly) that might mask the error a little longer. If ours are > related. Does it mean that if I invalidate whole state it will work ? thats kind of gross > > -M > >>> > > Side question are you using FSL layers? yes >>> >>> Is libhugetlbfs getting built? >> >> No >> >> >> ___ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] perl install error
On Thu, Sep 27, 2012 at 11:38 PM, Khem Raj wrote: > > On Sep 27, 2012, at 9:23 PM, McClintock Matthew-B29882 > wrote: > >> On Thu, Sep 27, 2012 at 11:18 PM, Khem Raj wrote: >>> >>> On Sep 27, 2012, at 8:52 PM, McClintock Matthew-B29882 >>> wrote: >>> On Thu, Sep 27, 2012 at 10:43 PM, Khem Raj wrote: > > On Sep 27, 2012, at 8:40 PM, McClintock Matthew-B29882 > wrote: > >> Khem, >> >> I'm just not looking at a similiar issue. Do this: >> > > > just 'not' or just 'now' ? > >> cat tmp/sstate-control/manifest-* | grep usr/lib/perl5 >> >> And see which recipe is making this folder. It should be the perl >> recipe, first not some other recipe… > > > cat sstate-control/manifest-* | grep usr/lib/perl5 > > return nothing Maybe this is not the same root cause then. >>> >>> reverting that commit fixed it. before that I tried to cleans state clean >>> all perl and perl-native >>> to no avail. >> >> OK, well we got the same error and ours was from another sstate-cache >> installing files in /usr/lib/perl5 before perl installed it's own >> symlink. cleaning cache for perl did not help either. >> >> Reverting that patch could have causes rebuilds and change of ordering >> (possibly) that might mask the error a little longer. If ours are >> related. > > > Does it mean that if I invalidate whole state it will work ? > thats kind of gross I think just making sure perl is deployed to sysroot first fixes this issue. For us we were simply missing a 'DEPENDS = perl' for a recipe which installed stuff in /usr/lib/perl5 - if perl is deployed to sysroot first the symlink is always in place properly. -M > > >> >> -M >> > >> >> Side question are you using FSL layers? > > yes Is libhugetlbfs getting built? >>> >>> No >>> >>> >>> ___ >>> Openembedded-core mailing list >>> Openembedded-core@lists.openembedded.org >>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > > > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-commits] Richard Purdie : sstate.bbclass: Detect overwriting files in sstate controlled directories
On Fri, Aug 31, 2012 at 2:38 AM, wrote: > Module: openembedded-core.git > Branch: master > Commit: 1f1b6f93d6b7aa8c9bd9bb5b1826997812e36932 > URL: > http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=1f1b6f93d6b7aa8c9bd9bb5b1826997812e36932 > > Author: Richard Purdie > Date: Sat Aug 25 15:48:14 2012 + > > sstate.bbclass: Detect overwriting files in sstate controlled directories > > We have a potential problem where two sstate packages try and touch the same > file. This adds code which will print a warning whenever this happens. > > The implementation does but by maintaining a master file list and comparing > file accesses against this. There are a number of places we have duplicate > accesses which are harmless, mostly in the deploy directory so these > are whitelisted. > > For now the code prints warnings, this could be strengthened in future to > become error messages. Whilst working on this code on and off over the past > few months various issues were uncovered, some serious. > > [YOCTO #238] > > Signed-off-by: Richard Purdie > > --- > > meta/classes/sstate.bbclass | 45 > ++- > 1 files changed, 44 insertions(+), 1 deletions(-) > > diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass > index 6762e32..02594a7 100644 > --- a/meta/classes/sstate.bbclass > +++ b/meta/classes/sstate.bbclass > @@ -3,6 +3,7 @@ SSTATE_VERSION = "2" > SSTATE_MANIFESTS ?= "${TMPDIR}/sstate-control" > SSTATE_MANFILEBASE = "${SSTATE_MANIFESTS}/manifest-${SSTATE_MANMACH}-" > SSTATE_MANFILEPREFIX = "${SSTATE_MANFILEBASE}${PN}" > +SSTATE_MASTERMANIFEST = "${SSTATE_MANIFESTS}/master.list" > > def generate_sstatefn(spec, hash, d): > if not hash: > @@ -17,6 +18,7 @@ SSTATE_EXTRAPATH = "" > SSTATE_EXTRAPATHWILDCARD = "" > SSTATE_PATHSPEC = > "${SSTATE_DIR}/${SSTATE_EXTRAPATHWILDCARD}*/${SSTATE_PKGSPEC}" > > +SSTATE_DUPWHITELIST = "${DEPLOY_DIR_IMAGE}/ ${DEPLOY_DIR}/licenses/ > ${DEPLOY_DIR_IPK}/all/ ${DEPLOY_DIR_RPM}/all ${DEPLOY_DIR_DEB}/all/" > > SSTATE_SCAN_FILES ?= "*.la *-config *_config" > SSTATE_SCAN_CMD ?= 'find ${SSTATE_BUILDDIR} \( -name "${@"\" -o -name > \"".join(d.getVar("SSTATE_SCAN_FILES", True).split())}" \) -type f' > @@ -125,7 +127,6 @@ def sstate_install(ss, d): > locks.append(bb.utils.lockfile(lock)) > > for state in ss['dirs']: > -oe.path.copytree(state[1], state[2]) > for walkroot, dirs, files in os.walk(state[1]): > bb.debug(2, "Staging files from %s to %s" % (state[1], state[2])) > for file in files: > @@ -140,9 +141,35 @@ def sstate_install(ss, d): > if not dstdir.endswith("/"): > dstdir = dstdir + "/" > shareddirs.append(dstdir) > + > +# Check the file list for conflicts against the master manifest > +mastermanifest = d.getVar("SSTATE_MASTERMANIFEST", True) > +whitelist = d.getVar("SSTATE_DUPWHITELIST", True) > +lock = bb.utils.lockfile(mastermanifest + ".lock") > +fileslist = [line.strip() for line in open(mastermanifest)] > +bb.utils.unlockfile(lock) > +match = [] > +for f in sharedfiles: > +if f in fileslist: > +realmatch = True > +for w in whitelist: > +if f.startswith(w): > +realmatch = False > +break > +if realmatch: > +match.append(f) > +if match: > +bb.warn("The recipe is trying to install files into a shared area > when those files already exist. Those files are:\n %s" % "\n > ".join(match)) > + > +# Write out the manifest and add to the task's manifest file > +lock = bb.utils.lockfile(mastermanifest + ".lock") > +mf = open(mastermanifest, "a") > f = open(manifest, "w") > for file in sharedfiles: > +mf.write(file + "\n") > f.write(file + "\n") > +bb.utils.unlockfile(lock) > + > # We want to ensure that directories appear at the end of the manifest > # so that when we test to see if they should be deleted any contents > # added by the task will have been removed first. > @@ -152,6 +179,10 @@ def sstate_install(ss, d): > f.write(di + "\n") > f.close() > > +# Run the actual file install > +for state in ss['dirs']: > +oe.path.copytree(state[1], state[2]) > + > for postinst in (d.getVar('SSTATEPOSTINSTFUNCS', True) or '').split(): > bb.build.exec_func(postinst, d) > > @@ -268,6 +299,18 @@ def sstate_clean_manifest(manifest, d): > except OSError: > pass > > +# Remove the entries from the master manifest > +mastermanifest = d.getVar("SSTATE_MASTERMANIFEST", True) > +lock = bb.utils.lockfile(mastermanifest + ".lock") > +mf = open(mastermanifest + ".new", "w") > +for line in open(mastermanifest, "r"): > +if not line or line in entries: > +continue > +mf.write(lin
Re: [OE-core] [oe-core][PATCH 00/10] qt4: upgrade to 4.8.3 and cleanup
* Martin Jansa [120927 17:44]: > On Thu, Sep 27, 2012 at 04:10:20PM +0100, Paul Eggleton wrote: > > On Thursday 27 September 2012 00:27:05 Martin Jansa wrote: > > > Please test on more architectures. > > > I've tested complete qt4-native + qt4-free-x11 on armv4t. > > > And only do_patch for nativesdk-qt4-tools, qt-mobility-*, qt4-embedded. > > > > So this is great work and these patches look good, although I'm still not > > particularly happy with breaking out so many of the configure options > > because > > I'm convinced it won't stop here; but it's possible I might be overruled on > > this issue. > I've added that, because meta-webos layer disables more stuff then .inc > file forces enabled, so I would have to rewrite whole QT_CONFIG_FLAGS > (if I don't want to have e.g. -webkit from .inc and -no-webkit appended > after that through QT_DISTRO_FLAGS). > But it can be just 2 variables instead of 6 if it's issue. I haven't looked closely at the patches, but we're also disabling lots of stuff (though, quite a bit of that comes from meta-oe). Thus, I'm leaning towards an easier way to handle this. We're currently using an approach were we add to QT_CONFIG_FLAGS, to set our desired config, and oe_filter_out() to remove certain defaults from oe-core and meta-oe. Thus, everything that can help reduce this mess is something we'd appreciate. Cheers, Anders -- Anders Darander ChargeStorm AB / eStorm AB ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] SDK: trap any IO errors in the relocate script
On 09/27/2012 06:49 PM, Saul Wold wrote: > On 09/25/2012 09:35 AM, Laurentiu Palcu wrote: > > BTW: in the future it's good to say the "filename: " This is what I usually use when I change single files. However, sometimes (and I know this particular patch is not the case), I change multiple files to fix a single problem or add a feature. In this case your BKM is not quite appropriate. I will end up with a commit subject like this: filename1, filename2, filename3: If those files belong to a certain functional area, say SDK, I thought it was more appropriate to prepend the subject with SDK. Also, the contribution guidelines on the wiki, state the same (see rpm example): https://wiki.yoctoproject.org/wiki/Contribution_Guidelines Am I wrong here? Thanks, Laurentiu > > So this would be "relocate_sdk.py: " >> If the files being relocated are already used by other processes the >> relocate script will fail with a traceback. This patch will trap any IO >> errors when opening such a file and gracefully report them to the user. >> >> Also change the exit code from 1 to -1 for a better adt-installer user >> experience (like pointing the user to the adt_installer.log). >> >> [YOCTO #3164] >> >> Signed-off-by: Laurentiu Palcu >> --- >> scripts/relocate_sdk.py | 14 -- >> 1 file changed, 12 insertions(+), 2 deletions(-) >> >> diff --git a/scripts/relocate_sdk.py b/scripts/relocate_sdk.py >> index b247e65..637ffe9 100755 >> --- a/scripts/relocate_sdk.py >> +++ b/scripts/relocate_sdk.py >> @@ -29,6 +29,7 @@ import sys >> import stat >> import os >> import re >> +import errno >> >> old_prefix = re.compile("##DEFAULT_INSTALL_DIR##") >> >> @@ -171,7 +172,7 @@ def change_dl_sysdirs(): >> >> # MAIN >> if len(sys.argv) < 4: >> -exit(1) >> +exit(-1) >> >> new_prefix = sys.argv[1] >> new_dl_path = sys.argv[2] >> @@ -184,7 +185,16 @@ for e in executables_list: >> else: >> os.chmod(e, perms|stat.S_IRWXU) >> >> -f = open(e, "r+b") >> +try: >> +f = open(e, "r+b") >> +except IOError as ioex: >> +if ioex.errno == errno.ETXTBSY: >> +print("Could not open %s. File used by another process.\nPlease >> "\ >> + "make sure you exit all processes that might use any SDK >> "\ >> + "binaries." % e) >> +else: >> +print("Could not open %s: %s(%d)" % (e, ioex.strerror, >> ioex.errno)) >> +exit(-1) >> >> arch = get_arch() >> if arch: >> > Merged into OE-Core > > Thanks > Sau! > ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] ltp: add dependency libcap
The following changes since commit 3c58f92d46e32c40b80575f14e0f6f66c9920c66: Revert "autotools.bbclass: using relative paths for acpaths" (2012-09-27 17:57:58 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib kangkai/ltp-dep http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kangkai/ltp-dep Kang Kai (1): ltp: add dependency libcap meta/recipes-extended/ltp/ltp_20120903.bb |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) -- 1.7.5.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] ltp: add dependency libcap
Similar to libaio, libcap is another dependency of ltp. If libcap has been done populate_sysroot but rpm/ipk package is not created, ltp will be compiled with libcap. So when install ltp to a image, it complains that package libcap is not found. [Yocto #2973] Signed-off-by: Kang Kai --- meta/recipes-extended/ltp/ltp_20120903.bb |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-extended/ltp/ltp_20120903.bb b/meta/recipes-extended/ltp/ltp_20120903.bb index 85270ea..e3e760d 100644 --- a/meta/recipes-extended/ltp/ltp_20120903.bb +++ b/meta/recipes-extended/ltp/ltp_20120903.bb @@ -19,9 +19,9 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \ file://utils/benchmark/kernbench-0.42/COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \ " -DEPENDS = "attr libaio" +DEPENDS = "attr libaio libcap" -PR = "r0" +PR = "r1" SRC_URI = "${SOURCEFORGE_MIRROR}/ltp/ltp-full-${PV}.bz2" -- 1.7.5.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core