Re: [OE-core] [PATCH 0/3] [oe-core & yocto RC] Fix unfetchable zypp-related packages
* Saul Wold [110920 20:11]: > On 09/20/2011 01:32 AM, Anders Darander wrote: > > openSUSE has moved several of it's projects from gitorious to github. > > Lately, > > these has become unfetchable from gitorius, thus the SRC_URI fixes are > > needed > > also for the upcoming yocto release. > > No other changes are included, SRCREV's are kept the same. > >sat-solver: git repo moved to github > >zypper: git repo moved to github > > meta/recipes-extended/libzypp/libzypp_git.bb |2 +- > > meta/recipes-extended/sat-solver/sat-solver_git.bb |2 +- > > meta/recipes-extended/zypper/zypper_git.bb |2 +- > > 3 files changed, 3 insertions(+), 3 deletions(-) > Do these need PR Bumps? No, nothing the in the source or the generated package should differ. We're still checking out the same SRCREV from the git repo, it's just the location of the git repo that has been changed. 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
[OE-core] [PATCH 5/7] Update python dependencies to be simply to "python"
Previously python dependencies were of the format "python(abi) = ..."
This format is not yet supportable within OE, so revert to a form
we know we can handle.
Introduce a change to package.bbclass that ensures it will causes the
sstate-cache's "package" to invalidate. Since pythondeps changed, the
output of rpmdeps changes, which causes the per-file dependency
information to change thus we need to invalidate the cache!
Signed-off-by: Mark Hatle
---
meta/classes/package.bbclass|6 ++
meta/recipes-devtools/rpm/rpm/pythondeps.sh | 16
meta/recipes-devtools/rpm/rpm_5.4.0.bb |4 +++-
3 files changed, 25 insertions(+), 1 deletions(-)
create mode 100755 meta/recipes-devtools/rpm/rpm/pythondeps.sh
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 3f5c904..e581ae2 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -1,3 +1,9 @@
+# Change the following version to cause sstate to invalidate the package
+# cache. This is useful if an item this class depends on changes in a
+# way that the output of this class changes. rpmdeps is a good example
+# as any change to rpmdeps requires this to be rerun.
+PACKAGE_BBCLASS_VERSION = "r1"
+
#
# Packaging process
#
diff --git a/meta/recipes-devtools/rpm/rpm/pythondeps.sh
b/meta/recipes-devtools/rpm/rpm/pythondeps.sh
new file mode 100755
index 000..083b174
--- /dev/null
+++ b/meta/recipes-devtools/rpm/rpm/pythondeps.sh
@@ -0,0 +1,16 @@
+#!/bin/sh
+
+[ $# -ge 1 ] || {
+cat > /dev/null
+exit 0
+}
+
+case $1 in
+-R|--requires)
+shift
+grep "/usr/\(lib[^/]*\|share\)/python[^/]*/" >/dev/null && echo "python"
+exit 0
+;;
+esac
+
+exit 0
diff --git a/meta/recipes-devtools/rpm/rpm_5.4.0.bb
b/meta/recipes-devtools/rpm/rpm_5.4.0.bb
index b805f7d..a7b360d 100644
--- a/meta/recipes-devtools/rpm/rpm_5.4.0.bb
+++ b/meta/recipes-devtools/rpm/rpm_5.4.0.bb
@@ -45,7 +45,7 @@ LIC_FILES_CHKSUM =
"file://COPYING.LIB;md5=2d5025d4aa3495befef8f17206a5b0a1"
DEPENDS = "bzip2 zlib db openssl elfutils expat libpcre attr acl popt
${extrarpmdeps}"
extrarpmdeps = "python perl"
extrarpmdeps_virtclass-native = ""
-PR = "r20"
+PR = "r21"
# rpm2cpio is a shell script, which is part of the rpm src.rpm. It is needed
# in order to extract the distribution SRPM into a format we can extract...
@@ -63,6 +63,7 @@ SRC_URI =
"http://www.rpm5.org/files/rpm/rpm-5.4/rpm-5.4.0-0.20101229.src.rpm;ex
file://rpm-fileclass.patch \
file://rpm-canonarch.patch \
file://rpm-no-loopmsg.patch \
+ file://pythondeps.sh \
"
# file://rpm-autoconf.patch \
@@ -352,6 +353,7 @@ do_install_append() {
# Enable Debian style arbitrary tags...
sed -i -e 's,%_arbitrary_tags[^_].*,%_arbitrary_tags
%{_arbitrary_tags_debian},' ${D}/${libdir}/rpm/macros
+ install -m 0755 ${WORKDIR}/pythondeps.sh
${D}/${libdir}/rpm/pythondeps.sh
install -m 0755 ${WORKDIR}/perfile_rpmdeps.sh
${D}/${libdir}/rpm/perfile_rpmdeps.sh
# Remove unpackaged files (based on list in rpm.spec)
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 7/7] multilib_global.bbclass: Fix non-multilib package provides [v2]
In non-multilib packages, configured in a multilib configuration we
need to adjust the system provides and rprovides to include the
virtual multilib variant.
This resolves a problem introduced in the
329d864f9bbf94ad3aae8df43d63fe10e4237e4f commit. Where "allarch"
packages were suddenly providing all variants of an object.
Signed-off-by: Mark Hatle
---
meta/classes/multilib_global.bbclass | 27 ++-
1 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/meta/classes/multilib_global.bbclass
b/meta/classes/multilib_global.bbclass
index ed14565..cd22163 100644
--- a/meta/classes/multilib_global.bbclass
+++ b/meta/classes/multilib_global.bbclass
@@ -6,16 +6,33 @@ python multilib_virtclass_handler_global () {
if isinstance(e, bb.event.RecipeParsed) and not variant:
if bb.data.inherits_class('kernel', e.data) or
bb.data.inherits_class('module-base', e.data) or
bb.data.inherits_class('allarch', e.data):
-origprovs = provs = e.data.getVar("PROVIDES", True)
-rprovs = e.data.getVar("RPROVIDES", True)
variants = (e.data.getVar("MULTILIB_VARIANTS", True) or "").split()
+
+# Process PROVIDES
+origprovs = provs = e.data.getVar("PROVIDES", True) or ""
for variant in variants:
provs = provs + " " + multilib_map_variable("PROVIDES",
variant, e.data)
-for pkg in e.data.getVar("PACKAGES", True).split():
-rprovs = rprovs + " " + variant + "-" + pkg
+# Reset to original value so next time around
multilib_map_variable works properly
e.data.setVar("PROVIDES", origprovs)
e.data.setVar("PROVIDES", provs)
+
+# Process RPROVIDES
+origrprovs = rprovs = e.data.getVar("RPROVIDES", True) or ""
+for variant in variants:
+rprovs = rprovs + " " + multilib_map_variable("RPROVIDES",
variant, e.data)
+# Reset to original value so next time around
multilib_map_variable works properly
+e.data.setVar("RPROVIDES", origrprovs)
e.data.setVar("RPROVIDES", rprovs)
+
+ # Process RPROVIDES_${PN}...
+for pkg in (e.data.getVar("PACKAGES", True) or "").split():
+origrprovs = rprovs = e.data.getVar("RPROVIDES_%s" % pkg,
True) or ""
+for variant in variants:
+rprovs = rprovs + " " +
multilib_map_variable("RPROVIDES_%s" % pkg, variant, e.data)
+rprovs = rprovs + " " + variant + "-" + pkg
+# Reset to original value so next time around
multilib_map_variable works properly
+e.data.setVar("RPROVIDES_%s" % pkg, origrprovs)
+e.data.setVar("RPROVIDES_%s" % pkg, rprovs)
}
addhandler multilib_virtclass_handler_global
@@ -35,7 +52,7 @@ def multilib_extend_name(variant, name):
def multilib_map_variable(varname, variant, d):
var = d.getVar(varname, True)
if not var:
-return
+return ""
var = var.split()
newvar = []
for v in var:
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 6/7] busybox: Enhance to add dynamic per-file provides
When using the RPM package backend, we need a full list of per-file
provides (and requires). The busybox package provides a number of
command line utilities, such as /usr/bin/env. However, because
the utilities are created at post install time via scripting the
provide of each of the links was never made. So any programs,
such as python, that require /usr/bin/env were unable to resolve
the dependency and failed.
This change only affects packaging backends that use per-file
dependency data. Currently RPM is the only packaging backend
with this ability.
Signed-off-by: Mark Hatle
---
meta/recipes-core/busybox/busybox.inc | 32 +++
meta/recipes-core/busybox/busybox_1.18.5.bb |2 +-
2 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-core/busybox/busybox.inc
b/meta/recipes-core/busybox/busybox.inc
index 3f93358..acd635b 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -205,6 +205,38 @@ do_install () {
install -m 0644 ${S}/busybox.links ${D}${sysconfdir}
}
+python package_do_filedeps_append () {
+ # We need to load the full set of busybox provides from the
/etc/busybox.links
+ # The pkg_postinst_ is what creates the actual links
+
+ pkg = d.getVar('PN', True)
+ f_busybox = "/bin/busybox"
+ f_busybox_links = "/etc/busybox.links"
+
+ requires_files = []
+ provides_files = []
+
+ # Load/backup original set
+ filerprovides = d.getVar('FILERPROVIDES_%s_%s' % (f_busybox, pkg),
True) or ""
+
+ dep_pipe = os.popen('sed -e "s,^,Provides: ," %s/%s%s' % (pkgdest, pkg,
f_busybox_links))
+
+ process_deps(dep_pipe, pkg, "%s/%s%s" % (pkgdest, pkg, f_busybox),
provides_files, requires_files)
+
+ # Add the new set
+ filerprovides += d.getVar('FILERPROVIDES_%s_%s' % (f_busybox, pkg),
True) or ""
+
+ # Make sure there is an entry for this item in the FILERPROVIDESFLIST...
+ filerprovidesflist = (d.getVar('FILERPROVIDESFLIST_%s' % pkg, True) or
"").split()
+ for file in provides_files:
+ if file not in filerprovidesflist:
+ filerprovidesflist.append(file)
+ d.setVar('FILERPROVIDESFLIST_%s' % pkg, " ".join(filerprovidesflist))
+
+ # Store the new provides
+ d.setVar('FILERPROVIDES_%s_%s' % (f_busybox, pkg), filerprovides)
+}
+
pkg_postinst_${PN} () {
# If we are not making an image we create links for the utilities that
doesn't exist
# so the update-alternatives script will get the utilities it needs
diff --git a/meta/recipes-core/busybox/busybox_1.18.5.bb
b/meta/recipes-core/busybox/busybox_1.18.5.bb
index c0dc1d4..bdafb31 100644
--- a/meta/recipes-core/busybox/busybox_1.18.5.bb
+++ b/meta/recipes-core/busybox/busybox_1.18.5.bb
@@ -1,5 +1,5 @@
require busybox.inc
-PR = "r0"
+PR = "r1"
SRC_URI = "http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball
\
file://udhcpscript.patch \
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/7] rpm: add multilib prefix for archs under deploy/rpm [v2]
From: Dongxiao Xu
Currently MACHINE_ARCH deploy folder is unique in multilib system, thus
a lib32 version of rpm package will override a normal rpm package if
its PACKAGE_ARCH is ${MACHINE_ARCH}.
Define different deploy folder for multilib architectures to avoid the
confliction.
Signed-off-by: Dongxiao Xu
Signed-off-by: Mark Hatle
---
meta/classes/multilib.bbclass |5 +
meta/classes/rootfs_rpm.bbclass |4 +++-
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index 583d76b..138dd27 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -76,4 +76,9 @@ python __anonymous () {
multilib_map_variable("PACKAGES_DYNAMIC", variant, d)
multilib_map_variable("PACKAGE_INSTALL", variant, d)
multilib_map_variable("INITSCRIPT_PACKAGES", variant, d)
+
+package_arch = d.getVar("PACKAGE_ARCH", True)
+machine_arch = d.getVar("MACHINE_ARCH", True)
+if package_arch == machine_arch:
+d.setVar("PACKAGE_ARCH", variant + "_" + package_arch)
}
diff --git a/meta/classes/rootfs_rpm.bbclass b/meta/classes/rootfs_rpm.bbclass
index 135ca75..7936d77 100644
--- a/meta/classes/rootfs_rpm.bbclass
+++ b/meta/classes/rootfs_rpm.bbclass
@@ -218,7 +218,9 @@ python () {
default_tune = localdata.getVar("DEFAULTTUNE_virtclass-multilib-"
+ eext[1], False)
if default_tune:
localdata.setVar("DEFAULTTUNE", default_tune)
-ml_package_archs += localdata.getVar("PACKAGE_ARCHS", True) or ""
+localdata.setVar("MACHINE_ARCH", eext[1] + "_" +
localdata.getVar("MACHINE_ARCH", False))
+package_archs = localdata.getVar("PACKAGE_ARCHS", True) or ""
+ml_package_archs += " " + package_archs
#bb.note("ML_PACKAGE_ARCHS %s %s %s" % (eext[1],
localdata.getVar("PACKAGE_ARCHS", True) or "(none)", overrides))
bb.data.setVar('MULTILIB_PACKAGE_ARCHS', ml_package_archs, d)
}
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/7] Add a run-time dependency that eglibc support GNU_HASH
RPM checks to see if binaries require GNU_HASH, if they do it adds
an automatic dependency of "rtld(GNU_HASH)". We need to satisfy
this dependency, and we do it by providing rtld(GNU_HASH) in the
package(s) that provide a runtime-linker.
Signed-off-by: Mark Hatle
---
meta/recipes-core/eglibc/eglibc-package.inc |3 ++-
meta/recipes-core/eglibc/eglibc_2.12.bb |2 +-
meta/recipes-core/eglibc/eglibc_2.13.bb |2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-core/eglibc/eglibc-package.inc
b/meta/recipes-core/eglibc/eglibc-package.inc
index 469e02d..519a49c 100644
--- a/meta/recipes-core/eglibc/eglibc-package.inc
+++ b/meta/recipes-core/eglibc/eglibc-package.inc
@@ -22,7 +22,8 @@ PKGSUFFIX_virtclass-nativesdk = "-nativesdk"
PACKAGES = "${PN}-dbg ${PN} catchsegv${PKGSUFFIX} sln${PKGSUFFIX}
nscd${PKGSUFFIX} ldd${PKGSUFFIX} ${PN}-utils eglibc-extra-nss${PKGSUFFIX}
eglibc-thread-db${PKGSUFFIX} ${PN}-pic ${PN}-dev ${PN}-doc libcidn${PKGSUFFIX}
libmemusage${PKGSUFFIX} libsegfault${PKGSUFFIX} ${PN}-pcprofile
libsotruss${PKGSUFFIX}"
-RPROVIDES_${PN} = "glibc${PKGSUFFIX}"
+# The ld.so in this eglibc supports the GNU_HASH
+RPROVIDES_${PN} = "glibc${PKGSUFFIX} rtld(GNU_HASH)"
RPROVIDES_${PN}-utils = "glibc${PKGSUFFIX}-utils"
RPROVIDES_${PN}-pic = "glibc${PKGSUFFIX}-pic"
RPROVIDES_${PN}-dev = "glibc${PKGSUFFIX}-dev"
diff --git a/meta/recipes-core/eglibc/eglibc_2.12.bb
b/meta/recipes-core/eglibc/eglibc_2.12.bb
index a71c4d4..a9d208b 100644
--- a/meta/recipes-core/eglibc/eglibc_2.12.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.12.bb
@@ -1,7 +1,7 @@
require eglibc.inc
DEPENDS += "gperf-native"
-PR = "r23"
+PR = "r24"
SRCREV = "14158"
diff --git a/meta/recipes-core/eglibc/eglibc_2.13.bb
b/meta/recipes-core/eglibc/eglibc_2.13.bb
index b2da697..b549496 100644
--- a/meta/recipes-core/eglibc/eglibc_2.13.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.13.bb
@@ -3,7 +3,7 @@ require eglibc.inc
SRCREV = "14157"
DEPENDS += "gperf-native"
-PR = "r14"
+PR = "r15"
PR_append = "+svnr${SRCPV}"
EGLIBC_BRANCH="eglibc-2_13"
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/7] Fix RPM dependencies
When packaging for RPM, dependencies were not being properly added
to the packages. Only the "providing" dependencies were added due
to a typo.
Signed-off-by: Mark Hatle
---
meta/classes/package_rpm.bbclass |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index 4605ec8..d822b54 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -840,7 +840,7 @@ python do_package_rpm () {
os.chmod(outdepends, 0755)
# Poky / RPM Provides
- outprovides = workdir + "/" + srcname + ".requires"
+ outprovides = workdir + "/" + srcname + ".provides"
try:
from __builtin__ import file
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/7] Fix a number of package installation related items [v2]
This set of patches fixes a number of items related to regular and multilib package installs. *** Updated the first two patches from Dongxiao. *** The next 4 patches are required to fix the basic problems with rpm installation. Due to a typo, the provides were not being set properly causing various invalid rootfs's to be created. Fixing this typo showed a small number of additional runtime dependencies were not being accounted for: * "rpmdeps" checks for GNU_HASH, and adds a requirement. For compatibility we now set rtld(GNU_HASH) as being provided by eglibc. * the python specific requirements were versioned, however there is no easy way to satisfy the versioning within the OE-Core environment today. This was modified to instead simply require "python", which the python-core package satisfies... a small change to packages.bbclass was required to invalidate the sstate-cache as well. * Enhance busybox to specific list a per-file runtime dependency for each link that /bin/busybox is capable of satisfying. This per-file dep is available for all packaging backends, but only affects RPM at this time. Finally the last patch fixes a problem in the multilib_global.bbclass which causes incorrect provide and rprovides to be placed into packages when multilib builds are enabled. *** Fourth patch was updated to remove debugging messages that were accidently left in --- All of the above has been tested with MACHINE = "qemux86_64" MULTILIB_IMAGE_INSTALL = "lib32-connman-gnome lib32-task-base-3g lib32-task-base-wifi lib32-task-base-bluetooth" require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "x86" I have build core-image-minimal, core-image-core and core-image-sato. Each image was built with and without the MULTILIB_IMAGE_INSTALL being enabled. The following changes since commit 81274f4488fbc4d68d150870735ec0181b60b451: freetype: disable bzip2 compressed font support (2011-09-19 13:14:03 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib mhatle/rpm.deps http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/rpm.deps Dongxiao Xu (2): rpm: add multilib prefix for archs under deploy/rpm multilib: install MULTILIB_IMAGE_INSTALL Mark Hatle (5): Fix RPM dependencies Add a run-time dependency that eglibc support GNU_HASH Update python dependencies to be simply to "python" busybox: Enhance to add dynamic per-file provides multilib_global.bbclass: Fix non-multilib package provides meta/classes/multilib.bbclass |5 +++ meta/classes/multilib_global.bbclass| 27 +--- meta/classes/package.bbclass|6 meta/classes/package_rpm.bbclass| 44 +- meta/classes/rootfs_rpm.bbclass |8 - meta/recipes-core/busybox/busybox.inc | 32 +++ meta/recipes-core/busybox/busybox_1.18.5.bb |2 +- meta/recipes-core/eglibc/eglibc-package.inc |3 +- meta/recipes-core/eglibc/eglibc_2.12.bb |2 +- meta/recipes-core/eglibc/eglibc_2.13.bb |2 +- meta/recipes-devtools/rpm/rpm/pythondeps.sh | 16 ++ meta/recipes-devtools/rpm/rpm_5.4.0.bb |4 ++- 12 files changed, 125 insertions(+), 26 deletions(-) create mode 100755 meta/recipes-devtools/rpm/rpm/pythondeps.sh -- 1.7.3.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/7] multilib: install MULTILIB_IMAGE_INSTALL [v2]
From: Dongxiao Xu
If user set MULTILIB_IMAGE_INSTALL, we need to install those multitlib
packages into the final image.
Also fix the logic in handling multilib prefix. For certain case like a
normal image contains several multilib libraries, the image recipe isn't
extended with MLPREFIX, therefore we need to enumerate the possible
multilib prefixes and compare them with package prefixes.
Signed-off-by: Dongxiao Xu
Signed-off-by: Mark Hatle
---
meta/classes/package_rpm.bbclass | 42 +
meta/classes/rootfs_rpm.bbclass |4 +++
2 files changed, 32 insertions(+), 14 deletions(-)
diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index 9ef1acd..4605ec8 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -166,7 +166,7 @@ package_install_internal_rpm () {
local platform="${INSTALL_PLATFORM_RPM}"
local platform_extra="${INSTALL_PLATFORM_EXTRA_RPM}"
local confbase="${INSTALL_CONFBASE_RPM}"
- local package_to_install="${INSTALL_PACKAGES_NORMAL_RPM}"
+ local package_to_install="${INSTALL_PACKAGES_NORMAL_RPM}
${INSTALL_PACKAGES_MULTILIB_RPM}"
local package_attemptonly="${INSTALL_PACKAGES_ATTEMPTONLY_RPM}"
local package_linguas="${INSTALL_PACKAGES_LINGUAS_RPM}"
local providename="${INSTALL_PROVIDENAME_RPM}"
@@ -210,10 +210,15 @@ package_install_internal_rpm () {
echo "Processing $pkg..."
archvar=base_archs
- ml_pkg=$(echo ${pkg} | sed
"s,^${MLPREFIX}\(.*\),\1,")
- if [ "${ml_pkg}" != "${pkg}" ]; then
- archvar=ml_archs
- fi
+ ml_prefix=`echo ${pkg} | cut -d'-' -f1`
+ ml_pkg=$pkg
+ for i in ${MULTILIB_PREFIX_LIST} ; do
+ if [ ${ml_prefix} == ${i} ]; then
+ ml_pkg=$(echo ${pkg} | sed
"s,^${ml_prefix}-\(.*\),\1,")
+ archvar=ml_archs
+ break
+ fi
+ done
pkg_name=$(resolve_package_rpm
${confbase}-${archvar}.conf ${ml_pkg})
if [ -z "$pkg_name" ]; then
@@ -224,16 +229,20 @@ package_install_internal_rpm () {
done
fi
fi
-
if [ ! -z "${package_to_install}" ]; then
for pkg in ${package_to_install} ; do
echo "Processing $pkg..."
archvar=base_archs
- ml_pkg=$(echo ${pkg} | sed "s,^${MLPREFIX}\(.*\),\1,")
- if [ "${ml_pkg}" != "${pkg}" ]; then
- archvar=ml_archs
- fi
+ ml_prefix=`echo ${pkg} | cut -d'-' -f1`
+ ml_pkg=$pkg
+ for i in ${MULTILIB_PREFIX_LIST} ; do
+ if [ ${ml_prefix} == ${i} ]; then
+ ml_pkg=$(echo ${pkg} | sed
"s,^${ml_prefix}-\(.*\),\1,")
+ archvar=ml_archs
+ break
+ fi
+ done
pkg_name=$(resolve_package_rpm
${confbase}-${archvar}.conf ${ml_pkg})
if [ -z "$pkg_name" ]; then
@@ -258,10 +267,15 @@ package_install_internal_rpm () {
for pkg in ${package_attemptonly} ; do
echo "Processing $pkg..."
archvar=base_archs
- ml_pkg=$(echo ${pkg} | sed "s,^${MLPREFIX}\(.*\),\1,")
- if [ "${ml_pkg}" != "${pkg}" ]; then
- archvar=ml_archs
- fi
+ ml_prefix=`echo ${pkg} | cut -d'-' -f1`
+ ml_pkg=$pkg
+ for i in ${MULTILIB_PREFIX_LIST} ; do
+ if [ ${ml_prefix} == ${i} ]; then
+ ml_pkg=$(echo ${pkg} | sed
"s,^${ml_prefix}-\(.*\),\1,")
+ archvar=ml_archs
+ break
+ fi
+ done
pkg_name=$(resolve_package_rpm
${confbase}-${archvar}.conf ${ml_pkg})
if [ -z "$pkg_name" ]; then
diff --git a/meta/classes/rootfs_rpm.bbclass b/meta/classes/rootfs_rpm.bbclass
index 7936d77..5ac6bca 100644
--- a/meta/classes/rootfs_rpm.bbclass
+++ b/meta/classes/rootfs_rpm.bbclass
@@ -58,6 +58,7 @@ fakeroot rootfs_rpm_do_r
Re: [OE-core] [PATCH 1/7] rootfs_rpm: Use specific MACHINE_ARCH for multilib recipes
Hi Richard and Mark,
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Richard Purdie
> Sent: Wednesday, September 21, 2011 5:50 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 1/7] rootfs_rpm: Use specific MACHINE_ARCH
> for multilib recipes
>
> On Tue, 2011-09-20 at 16:33 -0500, Mark Hatle wrote:
> > From: Dongxiao Xu
> >
> > Currently MACHINE_ARCH deploy folder is unique in multilib system,
> > thus a lib32 version of rpm package will override a normal rpm package
> > if its PACKAGE_ARCH is ${MACHINE_ARCH}.
> >
> > Take netbase as an example, which the PACKAGE_ARCH = MACHINE_ARCH.
> > Both the normal version of netbase package and the lib32 version are
> > named as "netbase-4.45-r1.qemux86_64.rpm" putting in
> > tmp/deploy/rpm/qemux86-64 directory, so we need to differentiate them.
> >
> > Here we define spedific MACHINE_virtclass-multilib-lib(xx) to override
> > the default MACHINE value, thus got different MACHINE_ARCH to fix this
> > issue.
>
> We simply *cannot* do this and this patch cannot be merged. I thought I'd
> explained this once but I will try and do so again.
>
> The problem is MACHINE specific packages can have generic content. They
> may have binaries, libraries or other things contained within them. Lets
> assume we have a strange system which has files in /lib, /lib32 and /lib64. We
> need the following permutations:
>
> qemux86 /lib
> qemux86 /lib64
> qemux86 /lib32
>
> and these are not equal to:
>
> qemux86_64 /lib
> qemux86_64 /lib64
> qemux86_64 /lib32
>
> which may or may not have different contents or different optimisations
> applied to the binaries/libraries contained within.
>
> You are trying to take a shortcut here and cross link these two sets and that
> doesn't scale to generic combinations.
>
> Furthermore, MACHINE is meant to be consistent within a given build and
> changing MACHINE for different multilibs will have all kinds of unintended
> consequences (such as the cache file location changing for different recipes).
>
> Wasn't there an alternative proposal from Dongxiao that added MLPREFIX to
> MACHINE_ARCH and resolved this issue that way instead? I know that causes
> issues at the package management level but I think we're going to have to run
> with that approach and resolve any issues it leads to...
I have an updated commit in
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=dxu4/ml4&id=6b2ed895e25bf6d76cc362c87661fd66231c4b4a
You can cherry-pick that to your pull request.
Thanks,
Dongxiao
>
> Cheers,
>
> Richard
>
>
>
>
>
>
> ___
> 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] [RC Fixes 7/8] distro tracking: Update Distro Aliases
Signed-off-by: Saul Wold --- .../conf/distro/include/distro_tracking_fields.inc | 83 +++- 1 files changed, 81 insertions(+), 2 deletions(-) diff --git a/meta/conf/distro/include/distro_tracking_fields.inc b/meta/conf/distro/include/distro_tracking_fields.inc index b150af8..7ff233c 100644 --- a/meta/conf/distro/include/distro_tracking_fields.inc +++ b/meta/conf/distro/include/distro_tracking_fields.inc @@ -613,6 +613,7 @@ RECIPE_MAINTAINER_pn-libzypp = "Mark Hatle " RECIPE_LATEST_VERSION_pn-libzypp = "git" RECIPE_INTEL_SECTION_pn-libzypp = "base libs" RECIPE_COMMENTS_pn-libzypp = "" +DISTRO_PN_ALIAS_pn-libzypp = "OpenSuse=libzypp Meego=libzypp" RECIPE_STATUS_pn-dbus-wait = "green" RECIPE_DEPENDENCY_CHECK_pn-dbus-wait = "not done" @@ -743,6 +744,8 @@ RECIPE_COMMENTS_pn-opkg = "" RECIPE_LAST_UPDATE_pn-opkg = "Jul 21, 2010" RECIPE_MANUAL_CHECK_DATE_pn-opkg = "Jun 29, 2011" RECIPE_MAINTAINER_pn-opkg = "Dongxiao Xu http://svn.openmoko.org/trunk/src/tar"; + RECIPE_STATUS_pn-opkg_nogpg = "green" RECIPE_DEPENDENCY_CHECK_pn-opkg_nogpg = "not done" @@ -753,6 +756,8 @@ RECIPE_LATEST_RELEASE_DATE_pn-opkg_nogpg = "02/2010" RECIPE_COMMENTS_pn-opkg_nogpg = "" RECIPE_LAST_UPDATE_pn-opkg_nogpg = "Jul 21, 2010" RECIPE_MAINTAINER_pn-opkg_nogpg = "Dongxiao Xu http://svn.openmoko.org/trunk/s + RECIPE_STATUS_pn-dpkg = "green" RECIPE_LATEST_VERSION_pn-dpkg = "1.16.0.3" @@ -1051,6 +1056,7 @@ RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-shadow = "7 months" RECIPE_LATEST_RELEASE_DATE_pn-shadow = "Feb 15, 2011" RECIPE_LAST_UPDATE_pn-shadow = "Jun 4, 2011" RECIPE_MAINTAINER_pn-shadow = "Scott Garman " +DISTRO_PN_ALIAS_pn-shadow-sysroot = "Ubuntu=shadow Fedora=shadow" RECIPE_STATUS_pn-coreutils = "green" RECIPE_LAST_UPDATE_pn-coreutils = "Jul 2, 2011" @@ -1151,6 +1157,7 @@ RECIPE_LATEST_RELEASE_DATE_pn-libgdbus = "09/2008" RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-libgdbus = "unknown" RECIPE_LAST_UPDATE_pn-libgdbus = "Jan 4, 2011" RECIPE_MAINTAINER_pn-libgdbus = "Scott Garman " +DISTRO_PN_ALIAS_pn-libgdbus = "Intel" RECIPE_STATUS_pn-apr = "green" RECIPE_LATEST_VERSION_pn-apr = "1.4.5" @@ -1712,6 +1719,8 @@ RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-tzdata = "1 month" RECIPE_LATEST_RELEASE_DATE_pn-tzdata = "05/2010" RECIPE_MANUAL_CHECK_DATE_pn-tzdata = "May 24, 2011" RECIPE_COMMENTS_pn-tzdata = "" +DISTRO_PN_ALIAS_pn-tzcode = "OSPDT" + RECIPE_STATUS_pn-tinylogin = "yellow"# replaced, place holder for tracking RECIPE_LAST_UPDATE_pn-tinylogin = "Jul 21, 2006" @@ -1792,6 +1801,7 @@ RECIPE_MAINTAINER_pn-zypper = "Mark Hatle " RECIPE_LATEST_VERSION_pn-zypper = "git" RECIPE_INTEL_SECTION_pn-zypper = "base utils" RECIPE_COMMENTS_pn-zypper = "" +DISTRO_PN_ALIAS_pn-zypper = "OpenSuse=zypper Meego=zypper" RECIPE_STATUS_pn-sysstat = "green" RECIPE_LAST_UPDATE_pn-sysstat = "May 24, 2011" @@ -2467,10 +2477,12 @@ DISTRO_PN_ALIAS_pn-core-image-sdk = "OE-Core" RECIPE_STATUS_pn-task-core-console = "green" RECIPE_LATEST_VERSION_pn-task-core-console = "1.0" RECIPE_MAINTAINER_pn-task-core-console = "Dongxiao Xu " +DISTRO_PN_ALIAS_pn-core-console = "OE-Core" RECIPE_STATUS_pn-task-core-x11 = "green" RECIPE_LATEST_VERSION_pn-task-core-x11 = "1.0" RECIPE_MAINTAINER_pn-task-core-x11 = "Dongxiao Xu " +DISTRO_PN_ALIAS_pn-core-x11 = "OE-Core" RECIPE_STATUS_pn-task-core-basic = "green" RECIPE_LATEST_VERSION_pn-task-core-basic = "1.0" @@ -2795,7 +2807,7 @@ RECIPE_LAST_UPDATE_pn-latencytop = "Jul 22, 2010" RECIPE_MAINTAINER_pn-latencytop = "Dexuan Cui " RECIPE_STATUS_pn-tcf-agent = "green" -DISTRO_PN_ALIAS_pn-tcf-agent = "WindRiver upstream=http://www.eclipse.org/dsdp/tm/"; +DISTRO_PN_ALIAS_pn-tcf-agent = "Windriver upstream=http://www.eclipse.org/dsdp/tm/"; RECIPE_DEPENDENCY_CHECK_pn-tcf-agent = "not done" RECIPE_LATEST_VERSION_pn-tcf-agent = "0.0+svnr1855" RECIPE_MANUAL_CHECK_DATE_pn-tcf-agent = "Jul 21, 2011" @@ -2899,6 +2911,8 @@ RECIPE_LATEST_VERSION_pn-gcc="4.6.1" RECIPE_LAST_UPDATE_pn-gcc = "May 1, 2011" RECIPE_MANUAL_CHECK_DATE_pn-gcc = "Jul 06, 2011" RECIPE_MAINTAINER_pn-gcc = "Nitin A Kamble " +DISTRO_PN_ALIAS_pn-gcc-runtime = "Ubuntu=gcc Fedora=gcc" + RECIPE_STATUS_pn-autoconf="red" RECIPE_LATEST_VERSION_pn-autoconf="2.68" @@ -3438,6 +3452,7 @@ RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-qt4-tools-nativesdk = "2 months" RECIPE_LATEST_RELEASE_DATE_pn-qt4-tools-nativesdk = "2011/05/04" RECIPE_LAST_UPDATE_pn-qt4-tools-nativesdk = "May 12, 2011" RECIPE_MAINTAINER_pn-qt4-tools-nativesdk = "Paul Eggleton " +DISTRO_PN_ALIAS_pn-qt4-tools-nativesdk = "Mandriva=libqt4-devel Ubuntu=libqt4-dev" RECIPE_STATUS_pn-qt4-embedded = "green" RECIPE_LATEST_VERSION_pn-qt4-embedded = "4.7.3" @@ -3445,6 +3460,7 @@ RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-qt4-embedded = "2 months" RECIPE_LATEST_RELEASE_DATE_pn-qt4-embedded = "2011/05/04" RECIPE_LAST_UPDATE_pn-qt4-embedded = "May 12, 2011" RECIPE_MAINTAINER_pn-qt4-embedded = "Paul Eggleton " +DISTRO_PN_ALIAS_pn-qt4-emb
[OE-core] [RC Fixes 8/8] avahi: Refactor recipe to move UI to avahi-ui
[YOCTO #1492]
This patch refactors avahi into a core non ui and avahi-ui, OE-Classic
has a similar factoring, and it was used as a refernce to make this
occur correctly here.
This allows the package to be built without gtk and GPLv3 issues.
Signed-off-by: Saul Wold
---
meta/recipes-connectivity/avahi/avahi-ui_0.6.30.bb | 37 +
meta/recipes-connectivity/avahi/avahi.inc | 86 ++-
meta/recipes-connectivity/avahi/avahi_0.6.30.bb|6 +-
3 files changed, 87 insertions(+), 42 deletions(-)
create mode 100644 meta/recipes-connectivity/avahi/avahi-ui_0.6.30.bb
diff --git a/meta/recipes-connectivity/avahi/avahi-ui_0.6.30.bb
b/meta/recipes-connectivity/avahi/avahi-ui_0.6.30.bb
new file mode 100644
index 000..e0733a9
--- /dev/null
+++ b/meta/recipes-connectivity/avahi/avahi-ui_0.6.30.bb
@@ -0,0 +1,37 @@
+LIC_FILES_CHKSUM = "file://LICENSE;md5=2d5025d4aa3495befef8f17206a5b0a1 \
+
file://avahi-common/address.h;endline=25;md5=b1d1d2cda1c07eb848ea7d6215712d9d \
+
file://avahi-core/dns.h;endline=23;md5=6fe82590b81aa0ddea5095b548e2fdcb \
+
file://avahi-daemon/main.c;endline=21;md5=9ee77368c5407af77caaef1b07285969 \
+
file://avahi-client/client.h;endline=23;md5=f4ac741a25c4f434039ba3e18c8674cf"
+
+require avahi.inc
+
+PR = "${INC_PR}.0"
+
+DEPENDS += "avahi gtk+ libglade"
+
+AVAHI_GTK = "--enable-gtk --disable-gtk3"
+
+S = "${WORKDIR}/avahi-${PV}"
+
+PACKAGES = "${PN} ${PN}-utils ${PN}-dbg ${PN}-dev python-avahi avahi-discover
avahi-discover-standalone"
+
+FILES_${PN} = "${libdir}/libavahi-ui*.so.*"
+FILES_${PN}-dbg += "${libdir}/.debug/libavah-ui*"
+FILES_${PN}-dev += "${libdir}/libavahi-ui*"
+
+FILES_${PN}-utils = "${bindir}/b* ${datadir}/applications/b*"
+
+FILES_python-avahi = "${PYTHON_SITEPACKAGES_DIR}/avahi/*"
+FILES_avahi-discover = "${bindir}/avahi-discover \
+${datadir}/applications/avahi-discover.desktop \
+${datadir}/avahi/interfaces/avahi-discover.glade"
+FILES_avahi-discover-standalone = "${bindir}/avahi-discover-standalone \
+
${datadir}/avahi/interfaces/avahi-discover.glade"
+
+RDEPENDS_avahi-discover = "python-avahi python-pygtk"
+RDEPENDS_python-avahi = "python-dbus"
+
+
+SRC_URI[md5sum] = "e4db89a2a403ff4c47d66ac66fad1f43"
+SRC_URI[sha256sum] =
"f9e4316c2339d0020726edd846d01bee0c39980906db0c247479e5807457ff1f"
diff --git a/meta/recipes-connectivity/avahi/avahi.inc
b/meta/recipes-connectivity/avahi/avahi.inc
index 24ea458..a847394 100644
--- a/meta/recipes-connectivity/avahi/avahi.inc
+++ b/meta/recipes-connectivity/avahi/avahi.inc
@@ -14,8 +14,9 @@ SECTION = "network"
# python scripts are under GPLv2+
LICENSE = "GPLv2+ & LGPLv2.1+"
-X11DEPENDS = "gtk+ libglade"
-DEPENDS = "expat libcap libdaemon dbus glib-2.0
${@base_contains('DISTRO_FEATURES', 'x11', '${X11DEPENDS}', '', d)}"
+INC_PR = "r6"
+
+DEPENDS = "expat libcap libdaemon dbus glib-2.0"
SRC_URI = "http://avahi.org/download/avahi-${PV}.tar.gz \
file://00avahi-autoipd \
@@ -25,58 +26,38 @@ SRC_URI = "http://avahi.org/download/avahi-${PV}.tar.gz \
inherit autotools pkgconfig update-rc.d gettext
EXTRA_OECONF = "--with-distro=debian \
+ --disable-introspection \
--with-avahi-priv-access-group=adm \
--disable-stack-protector \
--disable-gdbm \
--disable-mono \
--disable-monodoc \
- --disable-gtk3 \
-${@base_contains('DISTRO_FEATURES', 'x11', '--enable-gtk',
'--disable-gtk', d)} \
--disable-qt3 \
--disable-qt4 \
--disable-python \
--disable-doxygen-doc \
--with-systemdsystemunitdir=${base_libdir}/systemd/system/ \
-"
-
-PACKAGES =+ "avahi-systemd avahi-daemon libavahi-common libavahi-core
libavahi-client avahi-dnsconfd libavahi-glib libavahi-gobject avahi-autoipd
avahi-ui-utils avahi-utils libavahi-ui libavahi-ui-dev"
+ ${AVAHI_GTK} \
+ "
-FILES_avahi-systemd = "${base_libdir}/systemd"
-RDEPENDS_avahi-systemd = "avahi-daemon"
+AVAHI_GTK ?= "--disable-gtk --disable-gtk3"
-pkg_postinst_avahi-systemd() {
- # can't do this offline
- if [ "x$D" != "x" ]; then
- exit 1
- fi
-
- systemctl enable avahi-daemon.service
-}
-
-pkg_postrm_avahi-systemd() {
- # can't do this offline
- if [ "x$D" != "x" ]; then
- exit 1
- fi
+LDFLAGS_append_libc-uclibc = " -lintl"
+LDFLAGS_append_uclinux-uclibc = " -lintl"
- systemctl disable avahi-daemon.service
+do_configure_prepend() {
+sed 's:AM_CHECK_PYMOD:echo "no pymod" #AM_CHECK_PYMOD:g' -i configure.ac
}
-# uclibc has no nss
-RRECOMMENDS_avahi-daemon_append_libc-glibc = "libnss-mdns"
-RRECOMMENDS_${PN}_append_libc-glibc = "libnss-mdns"
-RDEPENDS_avahi-daemon = "sysvinit-pidof"
+PACKAGES =+ "avahi-
[OE-core] [RC Fixes 5/8] zypper: git repo moved to github
From: Anders Darander Signed-off-by: Anders Darander --- meta/recipes-extended/zypper/zypper_git.bb |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta/recipes-extended/zypper/zypper_git.bb b/meta/recipes-extended/zypper/zypper_git.bb index 299fcb5..7f7ceb3 100644 --- a/meta/recipes-extended/zypper/zypper_git.bb +++ b/meta/recipes-extended/zypper/zypper_git.bb @@ -11,7 +11,7 @@ SRCREV = "2c5bb6ceb99ecd950ef993e43d77bf0569ea0582" inherit cmake -SRC_URI = "git://gitorious.org/opensuse/zypper.git;protocol=git \ +SRC_URI = "git://github.com/openSUSE/zypper.git;protocol=git \ file://cmake.patch \ file://dso_linking_change_build_fix.patch \ file://rpm5-flag.patch \ -- 1.7.6 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RC Fixes 6/8] distrodata: fix distro_check code
This fixes a problem with package names from inherits showing up
Signed-off-by: Saul Wold
---
meta/classes/distrodata.bbclass | 19 +--
meta/lib/oe/distro_check.py |8
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/meta/classes/distrodata.bbclass b/meta/classes/distrodata.bbclass
index e91200d..ce7b931 100644
--- a/meta/classes/distrodata.bbclass
+++ b/meta/classes/distrodata.bbclass
@@ -8,7 +8,7 @@ python distro_eventhandler() {
logfile = dc.create_log_file(e.data, "distrodata.csv")
lf = bb.utils.lockfile("%s.lock" % logfile)
f = open(logfile, "a")
-
f.write("Package,Description,Owner,License,ChkSum,Status,VerMatch,Version,Upsteam,Non-Update,Reason,Recipe
Status\n")
+
f.write("Package,Description,Owner,License,ChkSum,Status,VerMatch,Version,Upsteam,Non-Update,Reason,Recipe
Status,Distro 1,Distro 2,Distro 3\n")
f.close()
bb.utils.unlockfile(lf)
@@ -34,12 +34,24 @@ python do_distrodata_np() {
bb.data.setVar('OVERRIDES', "pn-" + pnstripped[0] + ":" +
bb.data.getVar('OVERRIDES', d, True), localdata)
bb.data.update_data(localdata)
+ if pn.find("-nativesdk") != -1:
+ pnstripped = pn.split("-nativesdk")
+ bb.note("Native Split: %s" % pnstripped)
+ bb.data.setVar('OVERRIDES', "pn-" + pnstripped[0] + ":" +
bb.data.getVar('OVERRIDES', d, True), localdata)
+ bb.data.update_data(localdata)
+
if pn.find("-cross") != -1:
pnstripped = pn.split("-cross")
bb.note("cross Split: %s" % pnstripped)
bb.data.setVar('OVERRIDES', "pn-" + pnstripped[0] + ":" +
bb.data.getVar('OVERRIDES', d, True), localdata)
bb.data.update_data(localdata)
+ if pn.find("-crosssdk") != -1:
+ pnstripped = pn.split("-crosssdk")
+ bb.note("cross Split: %s" % pnstripped)
+ bb.data.setVar('OVERRIDES', "pn-" + pnstripped[0] + ":" +
bb.data.getVar('OVERRIDES', d, True), localdata)
+ bb.data.update_data(localdata)
+
if pn.find("-initial") != -1:
pnstripped = pn.split("-initial")
bb.note("initial Split: %s" % pnstripped)
@@ -181,7 +193,7 @@ python do_distrodata() {
lf = bb.utils.lockfile("%s.lock" % logfile)
f = open(logfile, "a")
- f.write("%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s," % \
+ f.write("%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s" % \
(pname, pdesc, maintainer, plicense, pchksum, hasrstatus,
vermatch, pcurver, pupver, noupdate, noupdate_reason, rstatus))
line = ""
for i in result:
@@ -671,6 +683,9 @@ python do_distro_check() {
import oe.distro_check as dc
import bb
import shutil
+if bb.data.inherits_class('native', d) or bb.data.inherits_class('cross',
d) or bb.data.inherits_class('sdk', d) or bb.data.inherits_class('crosssdk', d)
or bb.data.inherits_class('nativesdk',d):
+return
+
localdata = bb.data.createCopy(d)
bb.data.update_data(localdata)
tmpdir = bb.data.getVar('TMPDIR', d, True)
diff --git a/meta/lib/oe/distro_check.py b/meta/lib/oe/distro_check.py
index 55cdcad..4721355 100644
--- a/meta/lib/oe/distro_check.py
+++ b/meta/lib/oe/distro_check.py
@@ -73,9 +73,9 @@ def clean_package_list(package_list):
def get_latest_released_meego_source_package_list():
"Returns list of all the name os packages in the latest meego distro"
-if not os.path.isfile("/tmp/Meego-1.0"):
-os.mknod("/tmp/Meego-1.0")
-f = open("/tmp/Meego-1.0", "r")
+if not os.path.isfile("/tmp/Meego-1.1"):
+os.mknod("/tmp/Meego-1.1")
+f = open("/tmp/Meego-1.1", "r")
package_names = []
for line in f:
package_names.append(line[:-1] + ":" + "main") # Also strip the '\n'
at the end
@@ -303,7 +303,7 @@ def compare_in_distro_packages_list(distro_check_dir, d):
bb.note("Recipe: %s" % recipe_name)
tmp = bb.data.getVar('DISTRO_PN_ALIAS', localdata, True)
-distro_exceptions = dict({"OE-Core":'OE-Core', "OpenedHand":'OpenedHand',
"Intel":'Intel', "Upstream":'Upstream', "WindRiver":'Windriver', "OSPDT":'OSPDT
Approved', "Poky":'poky'})
+distro_exceptions = dict({"OE-Core":'OE-Core', "OpenedHand":'OpenedHand',
"Intel":'Intel', "Upstream":'Upstream', "Windriver":'Windriver', "OSPDT":'OSPDT
Approved', "Poky":'poky'})
if tmp:
list = tmp.split(' ')
--
1.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RC Fixes 4/8] sat-solver: git repo moved to github
From: Anders Darander Signed-off-by: Anders Darander --- meta/recipes-extended/sat-solver/sat-solver_git.bb |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta/recipes-extended/sat-solver/sat-solver_git.bb b/meta/recipes-extended/sat-solver/sat-solver_git.bb index 9b212db..0d9a439 100644 --- a/meta/recipes-extended/sat-solver/sat-solver_git.bb +++ b/meta/recipes-extended/sat-solver/sat-solver_git.bb @@ -12,7 +12,7 @@ PR = "r11" PARALLEL_MAKE="" -SRC_URI = "git://gitorious.org/opensuse/sat-solver.git;protocol=git \ +SRC_URI = "git://github.com/openSUSE/sat-solver.git;protocol=git \ file://sat-solver_rpm5.patch \ file://sat-solver_obsolete.patch \ file://cmake.patch \ -- 1.7.6 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RC Fixes 2/8] deb packages support: switch from /var/dpkg to /var/lib/dpkg
From: Dexuan Cui
[YOCTO #1086]
The pach was backported from OE:
http://git.openembedded.net/cgit.cgi/openembedded/commit/?id=41e0fbf792037f249d1b8d283b3de81718887c9f
Signed-off-by: Dexuan Cui
---
meta/classes/package_deb.bbclass | 10 +-
meta/classes/populate_sdk_deb.bbclass |4 ++--
meta/classes/rootfs_deb.bbclass| 20 ++--
meta/recipes-devtools/apt/apt-native_0.7.14.bb |2 +-
meta/recipes-devtools/apt/apt_0.7.14.bb|2 +-
meta/recipes-devtools/apt/files/apt.conf |4 ++--
.../dpkg/run-postinsts/run-postinsts |2 +-
.../dpkg/run-postinsts/run-postinsts.awk |2 +-
meta/recipes-devtools/dpkg/run-postinsts_1.0.bb|2 +-
.../update-alternatives-dpkg.inc |6 +++---
10 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/meta/classes/package_deb.bbclass b/meta/classes/package_deb.bbclass
index 5a32047..6733e64 100644
--- a/meta/classes/package_deb.bbclass
+++ b/meta/classes/package_deb.bbclass
@@ -135,11 +135,11 @@ package_install_internal_deb () {
export APT_CONFIG="${STAGING_ETCDIR_NATIVE}/apt/apt-${task}.conf"
- mkdir -p ${target_rootfs}/var/dpkg/info
- mkdir -p ${target_rootfs}/var/dpkg/updates
+ mkdir -p ${target_rootfs}/var/lib/dpkg/info
+ mkdir -p ${target_rootfs}/var/lib/dpkg/updates
- > ${target_rootfs}/var/dpkg/status
- > ${target_rootfs}/var/dpkg/available
+ > ${target_rootfs}/var/lib/dpkg/status
+ > ${target_rootfs}/var/lib/dpkg/available
apt-get update
@@ -179,7 +179,7 @@ package_install_internal_deb () {
done
# Mark all packages installed
- sed -i -e "s/Status: install ok unpacked/Status: install ok
installed/;" ${target_rootfs}/var/dpkg/status
+ sed -i -e "s/Status: install ok unpacked/Status: install ok
installed/;" ${target_rootfs}/var/lib/dpkg/status
}
deb_log_check() {
diff --git a/meta/classes/populate_sdk_deb.bbclass
b/meta/classes/populate_sdk_deb.bbclass
index 2cff69e..be7b552 100644
--- a/meta/classes/populate_sdk_deb.bbclass
+++ b/meta/classes/populate_sdk_deb.bbclass
@@ -52,8 +52,8 @@ fakeroot populate_sdk_deb () {
populate_sdk_post_deb ${SDK_OUTPUT}/${SDKPATHNATIVE}
#move remainings
- install -d ${SDK_OUTPUT}/${SDKPATHNATIVE}/var/dpkg
- mv ${SDK_OUTPUT}/var/dpkg/* ${SDK_OUTPUT}/${SDKPATHNATIVE}/var/dpkg
+ install -d ${SDK_OUTPUT}/${SDKPATHNATIVE}/var/lib/dpkg
+ mv ${SDK_OUTPUT}/var/lib/dpkg/*
${SDK_OUTPUT}/${SDKPATHNATIVE}/var/lib/dpkg
rm -rf ${SDK_OUTPUT}/var
populate_sdk_log_check populate_sdk
diff --git a/meta/classes/rootfs_deb.bbclass b/meta/classes/rootfs_deb.bbclass
index e03e80b..bab8e1e 100644
--- a/meta/classes/rootfs_deb.bbclass
+++ b/meta/classes/rootfs_deb.bbclass
@@ -13,7 +13,7 @@ opkglibdir = "${localstatedir}/lib/opkg"
fakeroot rootfs_deb_do_rootfs () {
set +e
- mkdir -p ${IMAGE_ROOTFS}/var/dpkg/alternatives
+ mkdir -p ${IMAGE_ROOTFS}/var/lib/dpkg/alternatives
# update index
package_update_index_deb
@@ -36,15 +36,15 @@ fakeroot rootfs_deb_do_rootfs () {
export OPKG_OFFLINE_ROOT=${IMAGE_ROOTFS}
_flag () {
- sed -i -e "/^Package: $2\$/{n; s/Status: install ok .*/Status:
install ok $1/;}" ${IMAGE_ROOTFS}/var/dpkg/status
+ sed -i -e "/^Package: $2\$/{n; s/Status: install ok .*/Status:
install ok $1/;}" ${IMAGE_ROOTFS}/var/lib/dpkg/status
}
_getflag () {
- cat ${IMAGE_ROOTFS}/var/dpkg/status | sed -n -e "/^Package:
$2\$/{n; s/Status: install ok .*/$1/; p}"
+ cat ${IMAGE_ROOTFS}/var/lib/dpkg/status | sed -n -e "/^Package:
$2\$/{n; s/Status: install ok .*/$1/; p}"
}
# Attempt to run preinsts
# Mark packages with preinst failures as unpacked
- for i in ${IMAGE_ROOTFS}/var/dpkg/info/*.preinst; do
+ for i in ${IMAGE_ROOTFS}/var/lib/dpkg/info/*.preinst; do
if [ -f $i ] && ! sh $i; then
_flag unpacked `basename $i .preinst`
fi
@@ -52,7 +52,7 @@ fakeroot rootfs_deb_do_rootfs () {
# Attempt to run postinsts
# Mark packages with postinst failures as unpacked
- for i in ${IMAGE_ROOTFS}/var/dpkg/info/*.postinst; do
+ for i in ${IMAGE_ROOTFS}/var/lib/dpkg/info/*.postinst; do
if [ -f $i ] && ! sh $i configure; then
_flag unpacked `basename $i .postinst`
fi
@@ -65,12 +65,12 @@ fakeroot rootfs_deb_do_rootfs () {
# Hacks to allow opkg's update-alternatives and opkg to coexist for now
mkdir -p ${IMAGE_ROOTFS}${opkglibdir}
- if [ -e ${IMAGE_ROOTFS}/var/dpkg/alternatives ]; then
- rmdir ${IMAGE_ROOTFS}/var/dpkg/alternatives
+ if [ -e ${IMAGE_ROOTFS}/var/lib/dpkg/alternatives ]; th
[OE-core] [RC Fixes 0/8] Avahi, OpenSUSE and other fixes
Richard, This set contains fixes from other folks that have been vetted, it also contains my (hopefully) final pass at the avahi refactor along with a bunch of Distro Data Fixes and updates prior to release. Sau! The following changes since commit 81274f4488fbc4d68d150870735ec0181b60b451: freetype: disable bzip2 compressed font support (2011-09-19 13:14:03 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib sgw/stage http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=sgw/stage Anders Darander (3): libzypp: git repo moved to github sat-solver: git repo moved to github zypper: git repo moved to github Dexuan Cui (1): deb packages support: switch from /var/dpkg to /var/lib/dpkg Paul Eggleton (1): scripts/combo-layer: fix still overzealous regex in default hook script Saul Wold (3): distrodata: fix distro_check code distro tracking: Update Distro Aliases avahi: Refactor recipe to move UI to avahi-ui meta/classes/distrodata.bbclass| 19 - meta/classes/package_deb.bbclass | 10 +- meta/classes/populate_sdk_deb.bbclass |4 +- meta/classes/rootfs_deb.bbclass| 20 +++--- .../conf/distro/include/distro_tracking_fields.inc | 83 ++- meta/lib/oe/distro_check.py|8 +- meta/recipes-connectivity/avahi/avahi-ui_0.6.30.bb | 37 + meta/recipes-connectivity/avahi/avahi.inc | 86 ++- meta/recipes-connectivity/avahi/avahi_0.6.30.bb|6 +- meta/recipes-devtools/apt/apt-native_0.7.14.bb |2 +- meta/recipes-devtools/apt/apt_0.7.14.bb|2 +- meta/recipes-devtools/apt/files/apt.conf |4 +- .../dpkg/run-postinsts/run-postinsts |2 +- .../dpkg/run-postinsts/run-postinsts.awk |2 +- meta/recipes-devtools/dpkg/run-postinsts_1.0.bb|2 +- .../update-alternatives-dpkg.inc |6 +- meta/recipes-extended/libzypp/libzypp_git.bb |2 +- meta/recipes-extended/sat-solver/sat-solver_git.bb |2 +- meta/recipes-extended/zypper/zypper_git.bb |2 +- scripts/combo-layer-hook-default.sh|2 +- 20 files changed, 220 insertions(+), 81 deletions(-) create mode 100644 meta/recipes-connectivity/avahi/avahi-ui_0.6.30.bb -- 1.7.6 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RC Fixes 3/8] libzypp: git repo moved to github
From: Anders Darander
Signed-off-by: Anders Darander
---
meta/recipes-extended/libzypp/libzypp_git.bb |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-extended/libzypp/libzypp_git.bb
b/meta/recipes-extended/libzypp/libzypp_git.bb
index aeae7df..4b1b8e4 100644
--- a/meta/recipes-extended/libzypp/libzypp_git.bb
+++ b/meta/recipes-extended/libzypp/libzypp_git.bb
@@ -16,7 +16,7 @@ SRCREV = "15b6c52260bbc52b3d8e585e271b67e10cc7c433"
PV = "0.0-git${SRCPV}"
PR = "r14"
-SRC_URI = "git://gitorious.org/opensuse/libzypp.git;protocol=git \
+SRC_URI = "git://github.com/openSUSE/libzypp.git;protocol=git \
file://no-doc.patch \
file://rpm5.patch \
file://rpm5-no-rpmdbinit.patch \
--
1.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RC Fixes 1/8] scripts/combo-layer: fix still overzealous regex in default hook script
From: Paul Eggleton In the previous fix to this hook script (OE core revision e7aae45414e4597e9244f86a81fbc940f73785c8) a start-of-line (^) marker was missed, so if a commit had no Signed-off-by line but it contained an inner patch that did, the inner patch was modified causing a "corrupt patch" error. Signed-off-by: Paul Eggleton --- scripts/combo-layer-hook-default.sh |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/scripts/combo-layer-hook-default.sh b/scripts/combo-layer-hook-default.sh index e535d5f..8b148ac 100755 --- a/scripts/combo-layer-hook-default.sh +++ b/scripts/combo-layer-hook-default.sh @@ -10,4 +10,4 @@ rev=$2 reponame=$3 sed -i -e "s#^Subject: \[PATCH\] \(.*\)#Subject: \[PATCH\] $reponame: \1#" $patchfile -sed -i -e "0,/^Signed-off-by:/s#\(Signed-off-by:.*\)#\($reponame rev: $rev\)\n\n\1#" $patchfile +sed -i -e "0,/^Signed-off-by:/s#\(^Signed-off-by:.*\)#\($reponame rev: $rev\)\n\n\1#" $patchfile -- 1.7.6 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] Fix alsa-utils package dependencies
Make alsa-utils main package depend on all of the more specific alsa-utils
packages (such as alsa-utils-alsamixer).
Signed-off-by: Daniel Lazzari Jr
---
.../recipes-multimedia/alsa/alsa-utils_1.0.24.2.bb |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-multimedia/alsa/alsa-utils_1.0.24.2.bb
b/meta/recipes-multimedia/alsa/alsa-utils_1.0.24.2.bb
index 52a7871..307f293 100644
--- a/meta/recipes-multimedia/alsa/alsa-utils_1.0.24.2.bb
+++ b/meta/recipes-multimedia/alsa/alsa-utils_1.0.24.2.bb
@@ -28,7 +28,7 @@ inherit autotools gettext
# This are all packages that we need to make. Also, the now empty alsa-utils
# ipk depends on them.
-PACKAGES += "\
+ALSA_UTILS_PKGS = "\
alsa-utils-alsamixer \
alsa-utils-midi \
alsa-utils-aplay \
@@ -44,6 +44,9 @@ PACKAGES += "\
alsa-utils-alsaucm \
"
+PACKAGES += "${ALSA_UTILS_PKGS}"
+RDEPENDS_${PN} += "${ALSA_UTILS_PKGS}"
+
# We omit alsaconf, because
# a) this is a bash script
# b) it creates config files not suitable for OE-based distros
--
1.7.0.4
Dan Lazzari Jr.
Firmware Engineer
dlazz...@leapfrog.com
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Correct way of having the PN package depend on
> Its defintely a bug in the recipe with the "alsa-utils" package just being
> broken. We need to do something like:
>
> ALSAUTILSPKGS = "alsa-utils-x \
> alsa-utils-y \
> alsa-utils-z"
>
> PACKAGES += "${ALSAUTILSPKGS}"
> RDEPENDS_${PN} += "${ALSAUTILSPKGS}"
>
> which should make the recipe do what it says it should do.
>
> Cheers,
>
> Richard
This is the info I needed, thanks! I'll try and draw up a patch for this.
Dan Lazzari Jr.
Firmware Engineer
dlazz...@leapfrog.com
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/7] rootfs_rpm: Use specific MACHINE_ARCH for multilib recipes
On Tue, 2011-09-20 at 16:33 -0500, Mark Hatle wrote:
> From: Dongxiao Xu
>
> Currently MACHINE_ARCH deploy folder is unique in multilib system, thus
> a lib32 version of rpm package will override a normal rpm package if its
> PACKAGE_ARCH is ${MACHINE_ARCH}.
>
> Take netbase as an example, which the PACKAGE_ARCH = MACHINE_ARCH. Both
> the normal version of netbase package and the lib32 version are named as
> "netbase-4.45-r1.qemux86_64.rpm" putting in tmp/deploy/rpm/qemux86-64
> directory, so we need to differentiate them.
>
> Here we define spedific MACHINE_virtclass-multilib-lib(xx) to override
> the default MACHINE value, thus got different MACHINE_ARCH to fix this
> issue.
We simply *cannot* do this and this patch cannot be merged. I thought
I'd explained this once but I will try and do so again.
The problem is MACHINE specific packages can have generic content. They
may have binaries, libraries or other things contained within them. Lets
assume we have a strange system which has files in /lib, /lib32
and /lib64. We need the following permutations:
qemux86 /lib
qemux86 /lib64
qemux86 /lib32
and these are not equal to:
qemux86_64 /lib
qemux86_64 /lib64
qemux86_64 /lib32
which may or may not have different contents or different optimisations
applied to the binaries/libraries contained within.
You are trying to take a shortcut here and cross link these two sets and
that doesn't scale to generic combinations.
Furthermore, MACHINE is meant to be consistent within a given build and
changing MACHINE for different multilibs will have all kinds of
unintended consequences (such as the cache file location changing for
different recipes).
Wasn't there an alternative proposal from Dongxiao that added MLPREFIX
to MACHINE_ARCH and resolved this issue that way instead? I know that
causes issues at the package management level but I think we're going to
have to run with that approach and resolve any issues it leads to...
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] qt4: update to latest version 4.7.4
Hi, ok 2 branches are available here : git://github.com/eukrea/oe-core.git - qt4_improve for improvement to existing qt 4.7.3, - qt4_upgrade for adding qt 4.7.4 (with DEFAULT_PREFERENCE=-1 as suggested by Koen. Please test them so that we can fix potential failures and send the pull request (I have compile test actually running with the latest changes in qt4_upgrade branch so this one is not yet fully tested). For more details : ** branch qt4_improve The following changes since commit 81274f4488fbc4d68d150870735ec0181b60b451: freetype: disable bzip2 compressed font support (2011-09-19 13:14:03 +0100) are available in the git repository at: git://github.com/eukrea/oe-core.git qt4_improve Denis Carikli (3): qt4.inc: remove the optional documentation package from the demo's RRECOMMENDS qt4(embedded and x11): disable neon for armv6-vfp qt4.inc: package qtdemo's docs in a separate package Eric Bénard (2): qt4e-demo-image: improve image qt4: fix generated sdk meta/recipes-qt/images/qt4e-demo-image.bb |2 +- meta/recipes-qt/meta/meta-toolchain-qte.bb |7 +++ meta/recipes-qt/qt4/qt4-embedded.inc|2 +- meta/recipes-qt/qt4/qt4-embedded_4.7.3.bb |4 ++-- meta/recipes-qt/qt4/qt4-tools-nativesdk.inc | 22 +++--- meta/recipes-qt/qt4/qt4-x11-free.inc|2 +- meta/recipes-qt/qt4/qt4-x11-free_4.7.3.bb |4 ++-- meta/recipes-qt/qt4/qt4.inc |7 ++- 8 files changed, 31 insertions(+), 19 deletions(-) ** branch qt4_upgrade : The following changes since commit 69482033e9b5841c2bd46c86679383a52bc4abea: qt4.inc: package qtdemo's docs in a separate package (2011-09-20 21:42:36 +0200) are available in the git repository at: git://github.com/eukrea/oe-core.git qt4_upgrade Eric Bénard (1): qt4: update to latest version 4.7.4 meta/recipes-qt/qt4/qt-4.7.4.inc | 62 ++ .../0001-Added-Openembedded-crossarch-option.patch | 47 ++ meta/recipes-qt/qt4/qt-4.7.4/fix-qtbug-20925.patch | 56 + meta/recipes-qt/qt4/qt-4.7.4/g++.conf | 60 ++ .../qt4/qt-4.7.4/hack-out-pg2-4.7.0.patch | 31 + meta/recipes-qt/qt4/qt-4.7.4/linux.conf| 66 meta/recipes-qt/qt4/qt4-embedded_4.7.4.bb | 12 meta/recipes-qt/qt4/qt4-native_4.7.4.bb| 18 + meta/recipes-qt/qt4/qt4-tools-nativesdk_4.7.4.bb | 11 +++ meta/recipes-qt/qt4/qt4-x11-free_4.7.4.bb | 13 10 files changed, 376 insertions(+), 0 deletions(-) create mode 100644 meta/recipes-qt/qt4/qt-4.7.4.inc create mode 100644 meta/recipes-qt/qt4/qt-4.7.4/0001-Added-Openembedded-crossarch-option.patch create mode 100644 meta/recipes-qt/qt4/qt-4.7.4/fix-qtbug-20925.patch create mode 100644 meta/recipes-qt/qt4/qt-4.7.4/g++.conf create mode 100644 meta/recipes-qt/qt4/qt-4.7.4/hack-out-pg2-4.7.0.patch create mode 100644 meta/recipes-qt/qt4/qt-4.7.4/linux.conf create mode 100644 meta/recipes-qt/qt4/qt4-embedded_4.7.4.bb create mode 100644 meta/recipes-qt/qt4/qt4-native_4.7.4.bb create mode 100644 meta/recipes-qt/qt4/qt4-tools-nativesdk_4.7.4.bb create mode 100644 meta/recipes-qt/qt4/qt4-x11-free_4.7.4.bb Thanks Eric ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 6/7] busybox: Enhance to add dynamic per-file provides
When using the RPM package backend, we need a full list of per-file
provides (and requires). The busybox package provides a number of
command line utilities, such as /usr/bin/env. However, because
the utilities are created at post install time via scripting the
provide of each of the links was never made. So any programs,
such as python, that require /usr/bin/env were unable to resolve
the dependency and failed.
This change only affects packaging backends that use per-file
dependency data. Currently RPM is the only packaging backend
with this ability.
Signed-off-by: Mark Hatle
---
meta/recipes-core/busybox/busybox.inc | 32 +++
meta/recipes-core/busybox/busybox_1.18.5.bb |2 +-
2 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-core/busybox/busybox.inc
b/meta/recipes-core/busybox/busybox.inc
index 3f93358..acd635b 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -205,6 +205,38 @@ do_install () {
install -m 0644 ${S}/busybox.links ${D}${sysconfdir}
}
+python package_do_filedeps_append () {
+ # We need to load the full set of busybox provides from the
/etc/busybox.links
+ # The pkg_postinst_ is what creates the actual links
+
+ pkg = d.getVar('PN', True)
+ f_busybox = "/bin/busybox"
+ f_busybox_links = "/etc/busybox.links"
+
+ requires_files = []
+ provides_files = []
+
+ # Load/backup original set
+ filerprovides = d.getVar('FILERPROVIDES_%s_%s' % (f_busybox, pkg),
True) or ""
+
+ dep_pipe = os.popen('sed -e "s,^,Provides: ," %s/%s%s' % (pkgdest, pkg,
f_busybox_links))
+
+ process_deps(dep_pipe, pkg, "%s/%s%s" % (pkgdest, pkg, f_busybox),
provides_files, requires_files)
+
+ # Add the new set
+ filerprovides += d.getVar('FILERPROVIDES_%s_%s' % (f_busybox, pkg),
True) or ""
+
+ # Make sure there is an entry for this item in the FILERPROVIDESFLIST...
+ filerprovidesflist = (d.getVar('FILERPROVIDESFLIST_%s' % pkg, True) or
"").split()
+ for file in provides_files:
+ if file not in filerprovidesflist:
+ filerprovidesflist.append(file)
+ d.setVar('FILERPROVIDESFLIST_%s' % pkg, " ".join(filerprovidesflist))
+
+ # Store the new provides
+ d.setVar('FILERPROVIDES_%s_%s' % (f_busybox, pkg), filerprovides)
+}
+
pkg_postinst_${PN} () {
# If we are not making an image we create links for the utilities that
doesn't exist
# so the update-alternatives script will get the utilities it needs
diff --git a/meta/recipes-core/busybox/busybox_1.18.5.bb
b/meta/recipes-core/busybox/busybox_1.18.5.bb
index c0dc1d4..bdafb31 100644
--- a/meta/recipes-core/busybox/busybox_1.18.5.bb
+++ b/meta/recipes-core/busybox/busybox_1.18.5.bb
@@ -1,5 +1,5 @@
require busybox.inc
-PR = "r0"
+PR = "r1"
SRC_URI = "http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball
\
file://udhcpscript.patch \
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 7/7] multilib_global.bbclass: Fix non-multilib package provides
In non-multilib packages, configured in a multilib configuration we
need to adjust the system provides and rprovides to include the
virtual multilib variant.
This resolves a problem introduced in the
329d864f9bbf94ad3aae8df43d63fe10e4237e4f commit. Where "allarch"
packages were suddenly providing all variants of an object.
Signed-off-by: Mark Hatle
---
meta/classes/multilib_global.bbclass | 30 +-
1 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/meta/classes/multilib_global.bbclass
b/meta/classes/multilib_global.bbclass
index ed14565..c9bbe8f 100644
--- a/meta/classes/multilib_global.bbclass
+++ b/meta/classes/multilib_global.bbclass
@@ -6,16 +6,36 @@ python multilib_virtclass_handler_global () {
if isinstance(e, bb.event.RecipeParsed) and not variant:
if bb.data.inherits_class('kernel', e.data) or
bb.data.inherits_class('module-base', e.data) or
bb.data.inherits_class('allarch', e.data):
-origprovs = provs = e.data.getVar("PROVIDES", True)
-rprovs = e.data.getVar("RPROVIDES", True)
variants = (e.data.getVar("MULTILIB_VARIANTS", True) or "").split()
+
+# Process PROVIDES
+origprovs = provs = e.data.getVar("PROVIDES", True) or ""
for variant in variants:
provs = provs + " " + multilib_map_variable("PROVIDES",
variant, e.data)
-for pkg in e.data.getVar("PACKAGES", True).split():
-rprovs = rprovs + " " + variant + "-" + pkg
+# Reset to original value so next time around
multilib_map_variable works properly
e.data.setVar("PROVIDES", origprovs)
+bb.warn("PROVIDES: %s" % (provs))
e.data.setVar("PROVIDES", provs)
+
+# Process RPROVIDES
+origrprovs = rprovs = e.data.getVar("RPROVIDES", True) or ""
+for variant in variants:
+rprovs = rprovs + " " + multilib_map_variable("RPROVIDES",
variant, e.data)
+# Reset to original value so next time around
multilib_map_variable works properly
+e.data.setVar("RPROVIDES", origrprovs)
+bb.warn("RPROVIDES: %s" % (rprovs))
e.data.setVar("RPROVIDES", rprovs)
+
+ # Process RPROVIDES_${PN}...
+for pkg in (e.data.getVar("PACKAGES", True) or "").split():
+origrprovs = rprovs = e.data.getVar("RPROVIDES_%s" % pkg,
True) or ""
+for variant in variants:
+rprovs = rprovs + " " +
multilib_map_variable("RPROVIDES_%s" % pkg, variant, e.data)
+rprovs = rprovs + " " + variant + "-" + pkg
+# Reset to original value so next time around
multilib_map_variable works properly
+e.data.setVar("RPROVIDES_%s" % pkg, origrprovs)
+bb.warn("RPROVIDES_%s: %s" % (pkg, rprovs))
+e.data.setVar("RPROVIDES_%s" % pkg, rprovs)
}
addhandler multilib_virtclass_handler_global
@@ -35,7 +55,7 @@ def multilib_extend_name(variant, name):
def multilib_map_variable(varname, variant, d):
var = d.getVar(varname, True)
if not var:
-return
+return ""
var = var.split()
newvar = []
for v in var:
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/7] Fix RPM dependencies
When packaging for RPM, dependencies were not being properly added
to the packages. Only the "providing" dependencies were added due
to a typo.
Signed-off-by: Mark Hatle
---
meta/classes/package_rpm.bbclass |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index 4605ec8..d822b54 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -840,7 +840,7 @@ python do_package_rpm () {
os.chmod(outdepends, 0755)
# Poky / RPM Provides
- outprovides = workdir + "/" + srcname + ".requires"
+ outprovides = workdir + "/" + srcname + ".provides"
try:
from __builtin__ import file
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/7] Add a run-time dependency that eglibc support GNU_HASH
RPM checks to see if binaries require GNU_HASH, if they do it adds
an automatic dependency of "rtld(GNU_HASH)". We need to satisfy
this dependency, and we do it by providing rtld(GNU_HASH) in the
package(s) that provide a runtime-linker.
Signed-off-by: Mark Hatle
---
meta/recipes-core/eglibc/eglibc-package.inc |3 ++-
meta/recipes-core/eglibc/eglibc_2.12.bb |2 +-
meta/recipes-core/eglibc/eglibc_2.13.bb |2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-core/eglibc/eglibc-package.inc
b/meta/recipes-core/eglibc/eglibc-package.inc
index 469e02d..519a49c 100644
--- a/meta/recipes-core/eglibc/eglibc-package.inc
+++ b/meta/recipes-core/eglibc/eglibc-package.inc
@@ -22,7 +22,8 @@ PKGSUFFIX_virtclass-nativesdk = "-nativesdk"
PACKAGES = "${PN}-dbg ${PN} catchsegv${PKGSUFFIX} sln${PKGSUFFIX}
nscd${PKGSUFFIX} ldd${PKGSUFFIX} ${PN}-utils eglibc-extra-nss${PKGSUFFIX}
eglibc-thread-db${PKGSUFFIX} ${PN}-pic ${PN}-dev ${PN}-doc libcidn${PKGSUFFIX}
libmemusage${PKGSUFFIX} libsegfault${PKGSUFFIX} ${PN}-pcprofile
libsotruss${PKGSUFFIX}"
-RPROVIDES_${PN} = "glibc${PKGSUFFIX}"
+# The ld.so in this eglibc supports the GNU_HASH
+RPROVIDES_${PN} = "glibc${PKGSUFFIX} rtld(GNU_HASH)"
RPROVIDES_${PN}-utils = "glibc${PKGSUFFIX}-utils"
RPROVIDES_${PN}-pic = "glibc${PKGSUFFIX}-pic"
RPROVIDES_${PN}-dev = "glibc${PKGSUFFIX}-dev"
diff --git a/meta/recipes-core/eglibc/eglibc_2.12.bb
b/meta/recipes-core/eglibc/eglibc_2.12.bb
index a71c4d4..a9d208b 100644
--- a/meta/recipes-core/eglibc/eglibc_2.12.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.12.bb
@@ -1,7 +1,7 @@
require eglibc.inc
DEPENDS += "gperf-native"
-PR = "r23"
+PR = "r24"
SRCREV = "14158"
diff --git a/meta/recipes-core/eglibc/eglibc_2.13.bb
b/meta/recipes-core/eglibc/eglibc_2.13.bb
index b2da697..b549496 100644
--- a/meta/recipes-core/eglibc/eglibc_2.13.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.13.bb
@@ -3,7 +3,7 @@ require eglibc.inc
SRCREV = "14157"
DEPENDS += "gperf-native"
-PR = "r14"
+PR = "r15"
PR_append = "+svnr${SRCPV}"
EGLIBC_BRANCH="eglibc-2_13"
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/7] Update python dependencies to be simply to "python"
Previously python dependencies were of the format "python(abi) = ..."
This format is not yet supportable within OE, so revert to a form
we know we can handle.
Introduce a change to package.bbclass that ensures it will causes the
sstate-cache's "package" to invalidate. Since pythondeps changed, the
output of rpmdeps changes, which causes the per-file dependency
information to change thus we need to invalidate the cache!
Signed-off-by: Mark Hatle
---
meta/classes/package.bbclass|6 ++
meta/recipes-devtools/rpm/rpm/pythondeps.sh | 16
meta/recipes-devtools/rpm/rpm_5.4.0.bb |4 +++-
3 files changed, 25 insertions(+), 1 deletions(-)
create mode 100755 meta/recipes-devtools/rpm/rpm/pythondeps.sh
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 3f5c904..e581ae2 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -1,3 +1,9 @@
+# Change the following version to cause sstate to invalidate the package
+# cache. This is useful if an item this class depends on changes in a
+# way that the output of this class changes. rpmdeps is a good example
+# as any change to rpmdeps requires this to be rerun.
+PACKAGE_BBCLASS_VERSION = "r1"
+
#
# Packaging process
#
diff --git a/meta/recipes-devtools/rpm/rpm/pythondeps.sh
b/meta/recipes-devtools/rpm/rpm/pythondeps.sh
new file mode 100755
index 000..083b174
--- /dev/null
+++ b/meta/recipes-devtools/rpm/rpm/pythondeps.sh
@@ -0,0 +1,16 @@
+#!/bin/sh
+
+[ $# -ge 1 ] || {
+cat > /dev/null
+exit 0
+}
+
+case $1 in
+-R|--requires)
+shift
+grep "/usr/\(lib[^/]*\|share\)/python[^/]*/" >/dev/null && echo "python"
+exit 0
+;;
+esac
+
+exit 0
diff --git a/meta/recipes-devtools/rpm/rpm_5.4.0.bb
b/meta/recipes-devtools/rpm/rpm_5.4.0.bb
index b805f7d..a7b360d 100644
--- a/meta/recipes-devtools/rpm/rpm_5.4.0.bb
+++ b/meta/recipes-devtools/rpm/rpm_5.4.0.bb
@@ -45,7 +45,7 @@ LIC_FILES_CHKSUM =
"file://COPYING.LIB;md5=2d5025d4aa3495befef8f17206a5b0a1"
DEPENDS = "bzip2 zlib db openssl elfutils expat libpcre attr acl popt
${extrarpmdeps}"
extrarpmdeps = "python perl"
extrarpmdeps_virtclass-native = ""
-PR = "r20"
+PR = "r21"
# rpm2cpio is a shell script, which is part of the rpm src.rpm. It is needed
# in order to extract the distribution SRPM into a format we can extract...
@@ -63,6 +63,7 @@ SRC_URI =
"http://www.rpm5.org/files/rpm/rpm-5.4/rpm-5.4.0-0.20101229.src.rpm;ex
file://rpm-fileclass.patch \
file://rpm-canonarch.patch \
file://rpm-no-loopmsg.patch \
+ file://pythondeps.sh \
"
# file://rpm-autoconf.patch \
@@ -352,6 +353,7 @@ do_install_append() {
# Enable Debian style arbitrary tags...
sed -i -e 's,%_arbitrary_tags[^_].*,%_arbitrary_tags
%{_arbitrary_tags_debian},' ${D}/${libdir}/rpm/macros
+ install -m 0755 ${WORKDIR}/pythondeps.sh
${D}/${libdir}/rpm/pythondeps.sh
install -m 0755 ${WORKDIR}/perfile_rpmdeps.sh
${D}/${libdir}/rpm/perfile_rpmdeps.sh
# Remove unpackaged files (based on list in rpm.spec)
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/7] multilib: install MULTILIB_IMAGE_INSTALL
From: Dongxiao Xu
If user set MULTILIB_IMAGE_INSTALL, we need to install those multitlib
packages into the final image.
Also fix the logic in handling multilib prefix. For certain case like a
normal image contains several multilib libraries, the image recipe isn't
extended with MLPREFIX, therefore we need to enumerate the possible
multilib prefixes and compare them with package prefixes.
Signed-off-by: Dongxiao Xu
Signed-off-by: Mark Hatle
---
meta/classes/package_rpm.bbclass | 42 +
meta/classes/rootfs_rpm.bbclass |4 +++
2 files changed, 32 insertions(+), 14 deletions(-)
diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index 9ef1acd..4605ec8 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -166,7 +166,7 @@ package_install_internal_rpm () {
local platform="${INSTALL_PLATFORM_RPM}"
local platform_extra="${INSTALL_PLATFORM_EXTRA_RPM}"
local confbase="${INSTALL_CONFBASE_RPM}"
- local package_to_install="${INSTALL_PACKAGES_NORMAL_RPM}"
+ local package_to_install="${INSTALL_PACKAGES_NORMAL_RPM}
${INSTALL_PACKAGES_MULTILIB_RPM}"
local package_attemptonly="${INSTALL_PACKAGES_ATTEMPTONLY_RPM}"
local package_linguas="${INSTALL_PACKAGES_LINGUAS_RPM}"
local providename="${INSTALL_PROVIDENAME_RPM}"
@@ -210,10 +210,15 @@ package_install_internal_rpm () {
echo "Processing $pkg..."
archvar=base_archs
- ml_pkg=$(echo ${pkg} | sed
"s,^${MLPREFIX}\(.*\),\1,")
- if [ "${ml_pkg}" != "${pkg}" ]; then
- archvar=ml_archs
- fi
+ ml_prefix=`echo ${pkg} | cut -d'-' -f1`
+ ml_pkg=$pkg
+ for i in ${MULTILIB_PREFIX_LIST} ; do
+ if [ ${ml_prefix} == ${i} ]; then
+ ml_pkg=$(echo ${pkg} | sed
"s,^${ml_prefix}-\(.*\),\1,")
+ archvar=ml_archs
+ break
+ fi
+ done
pkg_name=$(resolve_package_rpm
${confbase}-${archvar}.conf ${ml_pkg})
if [ -z "$pkg_name" ]; then
@@ -224,16 +229,20 @@ package_install_internal_rpm () {
done
fi
fi
-
if [ ! -z "${package_to_install}" ]; then
for pkg in ${package_to_install} ; do
echo "Processing $pkg..."
archvar=base_archs
- ml_pkg=$(echo ${pkg} | sed "s,^${MLPREFIX}\(.*\),\1,")
- if [ "${ml_pkg}" != "${pkg}" ]; then
- archvar=ml_archs
- fi
+ ml_prefix=`echo ${pkg} | cut -d'-' -f1`
+ ml_pkg=$pkg
+ for i in ${MULTILIB_PREFIX_LIST} ; do
+ if [ ${ml_prefix} == ${i} ]; then
+ ml_pkg=$(echo ${pkg} | sed
"s,^${ml_prefix}-\(.*\),\1,")
+ archvar=ml_archs
+ break
+ fi
+ done
pkg_name=$(resolve_package_rpm
${confbase}-${archvar}.conf ${ml_pkg})
if [ -z "$pkg_name" ]; then
@@ -258,10 +267,15 @@ package_install_internal_rpm () {
for pkg in ${package_attemptonly} ; do
echo "Processing $pkg..."
archvar=base_archs
- ml_pkg=$(echo ${pkg} | sed "s,^${MLPREFIX}\(.*\),\1,")
- if [ "${ml_pkg}" != "${pkg}" ]; then
- archvar=ml_archs
- fi
+ ml_prefix=`echo ${pkg} | cut -d'-' -f1`
+ ml_pkg=$pkg
+ for i in ${MULTILIB_PREFIX_LIST} ; do
+ if [ ${ml_prefix} == ${i} ]; then
+ ml_pkg=$(echo ${pkg} | sed
"s,^${ml_prefix}-\(.*\),\1,")
+ archvar=ml_archs
+ break
+ fi
+ done
pkg_name=$(resolve_package_rpm
${confbase}-${archvar}.conf ${ml_pkg})
if [ -z "$pkg_name" ]; then
diff --git a/meta/classes/rootfs_rpm.bbclass b/meta/classes/rootfs_rpm.bbclass
index 56c1a85..ec58700 100644
--- a/meta/classes/rootfs_rpm.bbclass
+++ b/meta/classes/rootfs_rpm.bbclass
@@ -58,6 +58,7 @@ fakeroot rootfs_rpm_do_r
[OE-core] [PATCH 1/7] rootfs_rpm: Use specific MACHINE_ARCH for multilib recipes
From: Dongxiao Xu
Currently MACHINE_ARCH deploy folder is unique in multilib system, thus
a lib32 version of rpm package will override a normal rpm package if its
PACKAGE_ARCH is ${MACHINE_ARCH}.
Take netbase as an example, which the PACKAGE_ARCH = MACHINE_ARCH. Both
the normal version of netbase package and the lib32 version are named as
"netbase-4.45-r1.qemux86_64.rpm" putting in tmp/deploy/rpm/qemux86-64
directory, so we need to differentiate them.
Here we define spedific MACHINE_virtclass-multilib-lib(xx) to override
the default MACHINE value, thus got different MACHINE_ARCH to fix this
issue.
Signed-off-by: Dongxiao Xu
Signed-off-by: Mark Hatle
---
meta/classes/rootfs_rpm.bbclass |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/meta/classes/rootfs_rpm.bbclass b/meta/classes/rootfs_rpm.bbclass
index 135ca75..56c1a85 100644
--- a/meta/classes/rootfs_rpm.bbclass
+++ b/meta/classes/rootfs_rpm.bbclass
@@ -218,6 +218,9 @@ python () {
default_tune = localdata.getVar("DEFAULTTUNE_virtclass-multilib-"
+ eext[1], False)
if default_tune:
localdata.setVar("DEFAULTTUNE", default_tune)
+machine = localdata.getVar("MACHINE_virtclass-multilib-" +
eext[1], False)
+if machine:
+localdata.setVar("MACHINE", machine)
ml_package_archs += localdata.getVar("PACKAGE_ARCHS", True) or ""
#bb.note("ML_PACKAGE_ARCHS %s %s %s" % (eext[1],
localdata.getVar("PACKAGE_ARCHS", True) or "(none)", overrides))
bb.data.setVar('MULTILIB_PACKAGE_ARCHS', ml_package_archs, d)
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/7] Fix a number of package installation related items
This set of patches fixes a number of items related to regular and multilib package installs. The first two commits are from Dongxiao Xu's series. I believe this is the latest version of each. These commits are required to use the MULTILIB_IMAGE_INSTALL option, as well as avoid conflicts when building some types of packages (machine specific packages). These can be left out if they're deemed not ready yet. The next 4 patches are required to fix the basic problems with rpm installation. Due to a typo, the provides were not being set properly causing various invalid rootfs's to be created. Fixing this typo showed a small number of additional runtime dependencies were not being accounted for: * "rpmdeps" checks for GNU_HASH, and adds a requirement. For compatibility we now set rtld(GNU_HASH) as being provided by eglibc. * the python specific requirements were versioned, however there is no easy way to satisfy the versioning within the OE-Core environment today. This was modified to instead simply require "python", which the python-core package satisfies... a small change to packages.bbclass was required to invalidate the sstate-cache as well. * Enhance busybox to specific list a per-file runtime dependency for each link that /bin/busybox is capable of satisfying. This per-file dep is available for all packaging backends, but only affects RPM at this time. Finally the last patch fixes a problem in the multilib_global.bbclass which causes incorrect provide and rprovides to be placed into packages when multilib builds are enabled. --- All of the above has been tested with MACHINE = "qemux86_64" MULTILIB_IMAGE_INSTALL = "lib32-connman-gnome lib32-task-base-3g lib32-task-base-wifi lib32-task-base-bluetooth" require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "x86" MACHINE_virtclass-multilib-lib32 = "qemux86" I have build core-image-minimal, core-image-core and core-image-sato. Each image was built with and without the MULTILIB_IMAGE_INSTALL being enabled. The following changes since commit 81274f4488fbc4d68d150870735ec0181b60b451: freetype: disable bzip2 compressed font support (2011-09-19 13:14:03 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib mhatle/rpm.deps http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/rpm.deps Dongxiao Xu (2): rootfs_rpm: Use specific MACHINE_ARCH for multilib recipes multilib: install MULTILIB_IMAGE_INSTALL Mark Hatle (5): Fix RPM dependencies Add a run-time dependency that eglibc support GNU_HASH Update python dependencies to be simply to "python" busybox: Enhance to add dynamic per-file provides multilib_global.bbclass: Fix non-multilib package provides meta/classes/multilib_global.bbclass| 30 +++--- meta/classes/package.bbclass|6 meta/classes/package_rpm.bbclass| 44 +- meta/classes/rootfs_rpm.bbclass |7 meta/recipes-core/busybox/busybox.inc | 32 +++ meta/recipes-core/busybox/busybox_1.18.5.bb |2 +- meta/recipes-core/eglibc/eglibc-package.inc |3 +- meta/recipes-core/eglibc/eglibc_2.12.bb |2 +- meta/recipes-core/eglibc/eglibc_2.13.bb |2 +- meta/recipes-devtools/rpm/rpm/pythondeps.sh | 16 ++ meta/recipes-devtools/rpm/rpm_5.4.0.bb |4 ++- 11 files changed, 123 insertions(+), 25 deletions(-) create mode 100755 meta/recipes-devtools/rpm/rpm/pythondeps.sh -- 1.7.3.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Correct way of having the PN package depend on
On Tue, 2011-09-20 at 14:00 -0700, Chris Larson wrote:
> On Tue, Sep 20, 2011 at 1:24 PM, Daniel Lazzari wrote:
> >> On 9/20/11 2:03 PM, Daniel Lazzari wrote:
> >> > I noticed a problem with the alsa-utils package where the alsa-utils
> >> > package does not depend on all of the little extra packages it's
> >> > supposed to pull in. I'm not sure what the best way to fix this is
> >> > though. Can anyone give me a little guidance or point me at a recipe
> >> > that does this correctly already?
> >>
> >> If you are using the RPM backend, I'm currently working on something that
> >> may
> > resolve this issue for you. Hopefully ready today.
> >>
> >> Otherwise, switch to ipk or deb and see if you get the same behavior.
> >
> > I'm using ipk already.
> >
> >> I don't see why this is a problem, personally. If someone wants a recipe's
> >> main package to depend on the other packages it emits, they're free to
> >> make the recipe do so. But the ${PN} package is not defined to include
> >> everything from the recipe, it never has been.
> >
> > I understand that. With the alsa-utils package, the recipe specifically
> > mentions
> > # This are all packages that we need to make. Also, the now empty alsa-utils
> > # ipk depends on them.
> >
> > Right above adding packages such as "alsa-utils-alsamixer" to the PACKAGES
> > variable. I need all of those more specific packages and if I understand
> > correctly, I should be able to get them by just adding the "alsa-utils"
> > package to my custom image.
>
> Sounds like it's just a recipe bug then, if it claims to do something
> which it doesn't do.
Its defintely a bug in the recipe with the "alsa-utils" package just
being broken. We need to do something like:
ALSAUTILSPKGS = "alsa-utils-x \
alsa-utils-y \
alsa-utils-z"
PACKAGES += "${ALSAUTILSPKGS}"
RDEPENDS_${PN} += "${ALSAUTILSPKGS}"
which should make the recipe do what it says it should do.
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/1 v3] Fix avahi x11 dependency with non-GPLv3 Build
On 09/20/2011 01:53 PM, Saul Wold wrote: Richard, Koen was right, it was a little half baked, I forgot to commit the avahi_0.6.30.bb file with the PR set up correctly. Otherwise, at this point, read my last comment, if someone has a need for the avahi-ui bits, then they can request that the be add back into OE-core, at this point we don't beleive anyone is using them. Time to insert foot in mouth! Turns out I don't know our own system that well, as oprofileui uses avahi-ui bits. I guess I will try to pull the OE bits in, I started to look at earlier. Sau! As this is targeted for the RC3 build, I do not want to take in more change than necessary. Thanks Sau! The following changes since commit 81274f4488fbc4d68d150870735ec0181b60b451: freetype: disable bzip2 compressed font support (2011-09-19 13:14:03 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib sgw/oe-fix http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=sgw/oe-fix Saul Wold (1): avahi: remove avahi-ui related packages meta/recipes-connectivity/avahi/avahi.inc | 19 +++ meta/recipes-connectivity/avahi/avahi_0.6.30.bb |2 +- 2 files changed, 8 insertions(+), 13 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Correct way of having the PN package depend on
On Tue, Sep 20, 2011 at 1:24 PM, Daniel Lazzari wrote:
>> On 9/20/11 2:03 PM, Daniel Lazzari wrote:
>> > I noticed a problem with the alsa-utils package where the alsa-utils
>> > package does not depend on all of the little extra packages it's supposed
>> > to pull in. I'm not sure what the best way to fix this is though. Can
>> > anyone give me a little guidance or point me at a recipe that does this
>> > correctly already?
>>
>> If you are using the RPM backend, I'm currently working on something that may
> resolve this issue for you. Hopefully ready today.
>>
>> Otherwise, switch to ipk or deb and see if you get the same behavior.
>
> I'm using ipk already.
>
>> I don't see why this is a problem, personally. If someone wants a recipe's
>> main package to depend on the other packages it emits, they're free to make
>> the recipe do so. But the ${PN} package is not defined to include everything
>> from the recipe, it never has been.
>
> I understand that. With the alsa-utils package, the recipe specifically
> mentions
> # This are all packages that we need to make. Also, the now empty alsa-utils
> # ipk depends on them.
>
> Right above adding packages such as "alsa-utils-alsamixer" to the PACKAGES
> variable. I need all of those more specific packages and if I understand
> correctly, I should be able to get them by just adding the "alsa-utils"
> package to my custom image.
Sounds like it's just a recipe bug then, if it claims to do something
which it doesn't do.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] avahi: remove avahi-ui related packages
[YOCTO #1492]
This patch removes the UI related packages from avahi. This
allows the package to be built without gtk and GPLv3 issues.
Signed-off-by: Saul Wold
---
meta/recipes-connectivity/avahi/avahi.inc | 19 +++
meta/recipes-connectivity/avahi/avahi_0.6.30.bb |2 +-
2 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/meta/recipes-connectivity/avahi/avahi.inc
b/meta/recipes-connectivity/avahi/avahi.inc
index 24ea458..025805a 100644
--- a/meta/recipes-connectivity/avahi/avahi.inc
+++ b/meta/recipes-connectivity/avahi/avahi.inc
@@ -14,8 +14,9 @@ SECTION = "network"
# python scripts are under GPLv2+
LICENSE = "GPLv2+ & LGPLv2.1+"
-X11DEPENDS = "gtk+ libglade"
-DEPENDS = "expat libcap libdaemon dbus glib-2.0
${@base_contains('DISTRO_FEATURES', 'x11', '${X11DEPENDS}', '', d)}"
+INC_PR = "r6"
+
+DEPENDS = "expat libcap libdaemon dbus glib-2.0"
SRC_URI = "http://avahi.org/download/avahi-${PV}.tar.gz \
file://00avahi-autoipd \
@@ -30,8 +31,8 @@ EXTRA_OECONF = "--with-distro=debian \
--disable-gdbm \
--disable-mono \
--disable-monodoc \
+ --disable-gtk \
--disable-gtk3 \
-${@base_contains('DISTRO_FEATURES', 'x11', '--enable-gtk',
'--disable-gtk', d)} \
--disable-qt3 \
--disable-qt4 \
--disable-python \
@@ -39,7 +40,7 @@ EXTRA_OECONF = "--with-distro=debian \
--with-systemdsystemunitdir=${base_libdir}/systemd/system/ \
"
-PACKAGES =+ "avahi-systemd avahi-daemon libavahi-common libavahi-core
libavahi-client avahi-dnsconfd libavahi-glib libavahi-gobject avahi-autoipd
avahi-ui-utils avahi-utils libavahi-ui libavahi-ui-dev"
+PACKAGES =+ "avahi-systemd avahi-daemon libavahi-common libavahi-core
libavahi-client avahi-dnsconfd libavahi-glib libavahi-gobject libavahi-ui
avahi-autoipd avahi-utils"
FILES_avahi-systemd = "${base_libdir}/systemd"
RDEPENDS_avahi-systemd = "avahi-daemon"
@@ -73,10 +74,6 @@ FILES_avahi-autoipd = "${sbindir}/avahi-autoipd \
${sysconfdir}/dhcp3/*/avahi-autoipd"
FILES_libavahi-common = "${libdir}/libavahi-common.so.*"
FILES_libavahi-core = "${libdir}/libavahi-core.so.*"
-FILES_libavahi-ui = "${libdir}/libavahi-ui.so.*"
-FILES_libavahi-ui-dev = "${libdir}/libavahi-ui.* \
- ${includedir}/avahi-ui/* \
- ${libdir}/pkgconfig/avahi-ui.pc"
FILES_avahi-daemon = "${sbindir}/avahi-daemon \
${sysconfdir}/avahi/avahi-daemon.conf \
${sysconfdir}/avahi/hosts \
@@ -88,16 +85,13 @@ FILES_avahi-daemon = "${sbindir}/avahi-daemon \
${datadir}/avahi/service-types \
${datadir}/dbus-1/system-services"
FILES_libavahi-client = "${libdir}/libavahi-client.so.*"
+FILES_libavahi-ui = "${libdir}/libavahi-ui.so.*"
FILES_avahi-dnsconfd = "${sbindir}/avahi-dnsconfd \
${sysconfdir}/avahi/avahi-dnsconfd.action \
${sysconfdir}/init.d/avahi-dnsconfd"
FILES_libavahi-glib = "${libdir}/libavahi-glib.so.*"
FILES_libavahi-gobject = "${libdir}/libavahi-gobject.so.*"
FILES_avahi-utils = "${bindir}/avahi-*"
-FILES_avahi-ui-utils = "${bindir}/bssh ${bindir}/bvnc ${bindir}/bshell \
-${bindir}/avahi-discover-standalone \
-${datadir}/applications \
-${datadir}/avahi/interfaces"
RRECOMMENDS_avahi-dev = "expat-dev libcap-dev libdaemon-dev dbus-dev
glib-2.0-dev update-rc.d-dev"
RRECOMMENDS_avahi-dev_append_libc-glibc = " gettext-dev"
@@ -119,6 +113,7 @@ do_install() {
# /var/run of current version is empty, so just remove it.
# if /var/run become non-empty in the future, need to install it via
volatile
rm -rf ${D}/var/run
+ rm -rf ${D}${datadir}/dbus-1/interfaces
}
# At the time the postinst runs, dbus might not be setup so only restart if
running
diff --git a/meta/recipes-connectivity/avahi/avahi_0.6.30.bb
b/meta/recipes-connectivity/avahi/avahi_0.6.30.bb
index 05716d0..5094961 100644
--- a/meta/recipes-connectivity/avahi/avahi_0.6.30.bb
+++ b/meta/recipes-connectivity/avahi/avahi_0.6.30.bb
@@ -6,7 +6,7 @@ LIC_FILES_CHKSUM =
"file://LICENSE;md5=2d5025d4aa3495befef8f17206a5b0a1 \
file://avahi-daemon/main.c;endline=21;md5=9ee77368c5407af77caaef1b07285969 \
file://avahi-client/client.h;endline=23;md5=f4ac741a25c4f434039ba3e18c8674cf"
-PR = "r4"
+PR = "${INC_PR}.0"
SRC_URI[md5sum] = "e4db89a2a403ff4c47d66ac66fad1f43"
SRC_URI[sha256sum] =
"f9e4316c2339d0020726edd846d01bee0c39980906db0c247479e5807457ff1f"
--
1.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1 v3] Fix avahi x11 dependency with non-GPLv3 Build
Richard, Koen was right, it was a little half baked, I forgot to commit the avahi_0.6.30.bb file with the PR set up correctly. Otherwise, at this point, read my last comment, if someone has a need for the avahi-ui bits, then they can request that the be add back into OE-core, at this point we don't beleive anyone is using them. As this is targeted for the RC3 build, I do not want to take in more change than necessary. Thanks Sau! The following changes since commit 81274f4488fbc4d68d150870735ec0181b60b451: freetype: disable bzip2 compressed font support (2011-09-19 13:14:03 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib sgw/oe-fix http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=sgw/oe-fix Saul Wold (1): avahi: remove avahi-ui related packages meta/recipes-connectivity/avahi/avahi.inc | 19 +++ meta/recipes-connectivity/avahi/avahi_0.6.30.bb |2 +- 2 files changed, 8 insertions(+), 13 deletions(-) -- 1.7.6 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] policy proposal: INC_PR
On Tue, 2011-09-20 at 22:36 +0200, Koen Kooi wrote: > Op 20 sep 2011, om 22:30 heeft Richard Purdie het volgende geschreven: > > > On Tue, 2011-09-20 at 14:10 -0500, Mark Hatle wrote: > >> On 9/20/11 2:04 PM, Dmitry Eremin-Solenikov wrote: > >>> Hello, colleagues, > >>> > >>> While debugging some stuff in oe-core & company I've noticed that > >>> lot's of packages > >>> either don't use INC_PR, or misuse it (e.g. .inc has INC_PR, but > >>> then > >>> .bb just defines PR = "rX"). > >> > >> I've noticed similar things. I'd agree, we should define and use > >> INC_PR for > >> items that have .inc files. There have been many times that I need > >> to fix a bug > >> in the .inc file and end up manually updating the PR is 2 or 3 > >> recipes that use > >> the .inc. > >> > >> One question though, how do we handle packages with multilib .inc > >> files? > >> > >> INC_PR += ... (or is it .=) > > > > I'm going to disagree here. I'd actually like to see the whole PR > > thing > > become irrelevant. Its insane we have to spend so much time doing > > something the system should be able to figure out for itself. It > > currently serves two purposes: > > > > 1. Triggers rebuilds of packages when they change > > 2. Handles package feed upgrades correctly > > > > For 1, we can use the sstate checksums and for 2, we can use some kind > > of PR server, either local or networked. > > > > I'm therefore proposing that after the current release is finished, we > > enable the BasicHash signature generator (which adds the sstate > > checksums to the stamp files) and stop bumping PR values (so INC_PR > > can > > die and PR values can likely fade out of recipes). If the tooling we > > have for 2 isn't enough we'll then just simply have to improve it and > > make it work. > > > > Comments? > > Judging from the previous big changes in OE-core, can we have the > tooling actually work before abolishing PR? > AFAICT the PR 'syncing' across all builders for a distro hasn't been > solved properly yet. With the current tooling it is impossible for > people to rebuild a tag and get the same PRs as the master build had > at the time of the tag. This is the first time that problem has been specifically rasied to my knowledge so yes, we need to have a solution for that I agree. Likely, the best way to handle it is going to be to dump the PR server's database into an include file which sets the PR values as needed and then the include file can be included in the tagged release. This would mean that anyone building the checkout would then have the correct set of base PR values to be consistent with the main package repo as released. Alternatives would be including the PR database itself somehow but it probably makes sense to start a separate discussion about this. Are there any other problems that need to get fixed? I still think we are going to need to switch sooner than later so we can start to find and address issues as if we continue to wait, few people actually test and figure them out sadly :( Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] policy proposal: INC_PR
Op 20 sep 2011, om 22:30 heeft Richard Purdie het volgende geschreven: On Tue, 2011-09-20 at 14:10 -0500, Mark Hatle wrote: On 9/20/11 2:04 PM, Dmitry Eremin-Solenikov wrote: Hello, colleagues, While debugging some stuff in oe-core & company I've noticed that lot's of packages either don't use INC_PR, or misuse it (e.g. .inc has INC_PR, but then .bb just defines PR = "rX"). I've noticed similar things. I'd agree, we should define and use INC_PR for items that have .inc files. There have been many times that I need to fix a bug in the .inc file and end up manually updating the PR is 2 or 3 recipes that use the .inc. One question though, how do we handle packages with multilib .inc files? INC_PR += ... (or is it .=) I'm going to disagree here. I'd actually like to see the whole PR thing become irrelevant. Its insane we have to spend so much time doing something the system should be able to figure out for itself. It currently serves two purposes: 1. Triggers rebuilds of packages when they change 2. Handles package feed upgrades correctly For 1, we can use the sstate checksums and for 2, we can use some kind of PR server, either local or networked. I'm therefore proposing that after the current release is finished, we enable the BasicHash signature generator (which adds the sstate checksums to the stamp files) and stop bumping PR values (so INC_PR can die and PR values can likely fade out of recipes). If the tooling we have for 2 isn't enough we'll then just simply have to improve it and make it work. Comments? Judging from the previous big changes in OE-core, can we have the tooling actually work before abolishing PR? AFAICT the PR 'syncing' across all builders for a distro hasn't been solved properly yet. With the current tooling it is impossible for people to rebuild a tag and get the same PRs as the master build had at the time of the tag. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] policy proposal: INC_PR
On Tue, 2011-09-20 at 14:10 -0500, Mark Hatle wrote: > On 9/20/11 2:04 PM, Dmitry Eremin-Solenikov wrote: > > Hello, colleagues, > > > > While debugging some stuff in oe-core & company I've noticed that > > lot's of packages > > either don't use INC_PR, or misuse it (e.g. .inc has INC_PR, but then > > .bb just defines PR = "rX"). > > I've noticed similar things. I'd agree, we should define and use INC_PR for > items that have .inc files. There have been many times that I need to fix a > bug > in the .inc file and end up manually updating the PR is 2 or 3 recipes that > use > the .inc. > > One question though, how do we handle packages with multilib .inc files? > > INC_PR += ... (or is it .=) I'm going to disagree here. I'd actually like to see the whole PR thing become irrelevant. Its insane we have to spend so much time doing something the system should be able to figure out for itself. It currently serves two purposes: 1. Triggers rebuilds of packages when they change 2. Handles package feed upgrades correctly For 1, we can use the sstate checksums and for 2, we can use some kind of PR server, either local or networked. I'm therefore proposing that after the current release is finished, we enable the BasicHash signature generator (which adds the sstate checksums to the stamp files) and stop bumping PR values (so INC_PR can die and PR values can likely fade out of recipes). If the tooling we have for 2 isn't enough we'll then just simply have to improve it and make it work. Comments? Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Correct way of having the PN package depend on
> On 9/20/11 2:03 PM, Daniel Lazzari wrote:
> > I noticed a problem with the alsa-utils package where the alsa-utils
> > package does not depend on all of the little extra packages it's supposed
> > to pull in. I'm not sure what the best way to fix this is though. Can
> > anyone give me a little guidance or point me at a recipe that does this
> > correctly already?
>
> If you are using the RPM backend, I'm currently working on something that may
resolve this issue for you. Hopefully ready today.
>
> Otherwise, switch to ipk or deb and see if you get the same behavior.
I'm using ipk already.
> I don't see why this is a problem, personally. If someone wants a recipe's
> main package to depend on the other packages it emits, they're free to make
> the recipe do so. But the ${PN} package is not defined to include everything
> from the recipe, it never has been.
I understand that. With the alsa-utils package, the recipe specifically mentions
# This are all packages that we need to make. Also, the now empty alsa-utils
# ipk depends on them.
Right above adding packages such as "alsa-utils-alsamixer" to the PACKAGES
variable. I need all of those more specific packages and if I understand
correctly, I should be able to get them by just adding the "alsa-utils" package
to my custom image.
Dan Lazzari Jr.
Firmware Engineer
dlazz...@leapfrog.com
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Correct way of having the PN package depend on the other packages?
On Tue, Sep 20, 2011 at 12:03 PM, Daniel Lazzari wrote:
> I noticed a problem with the alsa-utils package where the alsa-utils package
> does not depend on all of the little extra packages it's supposed to pull in.
> I'm not sure what the best way to fix this is though. Can anyone give me a
> little guidance or point me at a recipe that does this correctly already?
I don't see why this is a problem, personally. If someone wants a
recipe's main package to depend on the other packages it emits,
they're free to make the recipe do so. But the ${PN} package is not
defined to include everything from the recipe, it never has been.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
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] [oe-core & yocto RC] Fix unfetchable zypp-related packages
On Tue, 2011-09-20 at 11:10 -0700, Saul Wold wrote: > On 09/20/2011 01:32 AM, Anders Darander wrote: > > > > openSUSE has moved several of it's projects from gitorious to github. > > Lately, > > these has become unfetchable from gitorius, thus the SRC_URI fixes are > > needed > > also for the upcoming yocto release. > > > > No other changes are included, SRCREV's are kept the same. > > > > The following changes since commit 81274f4488fbc4d68d150870735ec0181b60b451: > > > >freetype: disable bzip2 compressed font support (2011-09-19 13:14:03 > > +0100) > > > > are available in the git repository at: > >git://github.com/darander/oe-core opensuse-fixes > >https://github.com/darander/oe-core/tree/opensuse-fixes > > > > Anders Darander (3): > >libzypp: git repo moved to github > >sat-solver: git repo moved to github > >zypper: git repo moved to github > > > > meta/recipes-extended/libzypp/libzypp_git.bb |2 +- > > meta/recipes-extended/sat-solver/sat-solver_git.bb |2 +- > > meta/recipes-extended/zypper/zypper_git.bb |2 +- > > 3 files changed, 3 insertions(+), 3 deletions(-) > > > Do these need PR Bumps? No, since the generated output didn't change and with git, we can be pretty sure we're building the same thing if the hashes match. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] policy proposal: INC_PR
On 9/20/11 2:04 PM, Dmitry Eremin-Solenikov wrote: > Hello, colleagues, > > While debugging some stuff in oe-core & company I've noticed that > lot's of packages > either don't use INC_PR, or misuse it (e.g. .inc has INC_PR, but then > .bb just defines PR = "rX"). I've noticed similar things. I'd agree, we should define and use INC_PR for items that have .inc files. There have been many times that I need to fix a bug in the .inc file and end up manually updating the PR is 2 or 3 recipes that use the .inc. One question though, how do we handle packages with multilib .inc files? INC_PR += ... (or is it .=) --Mark > From my previous experience with oe-dev, I found INC_PR very usefull > and error-prone feature. > What about making usage of INC_PR a policy decision, demanding that > all new packages should use INC_PR for their recipes, if .inc files > are used. And then define a grace period > during which all remaining packages should be converted to INC_PR (3 > months? Next release? I really don't know). > > I'm sorry if this issue was already discussed somewhere and I'm > duplicating the efforts > or proposing already discarded idea. > ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Correct way of having the PN package depend on the other packages?
On 9/20/11 2:03 PM, Daniel Lazzari wrote: > I noticed a problem with the alsa-utils package where the alsa-utils package > does not depend on all of the little extra packages it's supposed to pull in. > I'm not sure what the best way to fix this is though. Can anyone give me a > little guidance or point me at a recipe that does this correctly already? If you are using the RPM backend, I'm currently working on something that may resolve this issue for you. Hopefully ready today. Otherwise, switch to ipk or deb and see if you get the same behavior. --Mark > Thanks, > > Dan Lazzari Jr. > Firmware Engineer > dlazz...@leapfrog.com > > > ___ > 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] [RFC] policy proposal: INC_PR
Hello, colleagues, While debugging some stuff in oe-core & company I've noticed that lot's of packages either don't use INC_PR, or misuse it (e.g. .inc has INC_PR, but then .bb just defines PR = "rX"). >From my previous experience with oe-dev, I found INC_PR very usefull and error-prone feature. What about making usage of INC_PR a policy decision, demanding that all new packages should use INC_PR for their recipes, if .inc files are used. And then define a grace period during which all remaining packages should be converted to INC_PR (3 months? Next release? I really don't know). I'm sorry if this issue was already discussed somewhere and I'm duplicating the efforts or proposing already discarded idea. -- With best wishes Dmitry ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Correct way of having the PN package depend on the other packages?
I noticed a problem with the alsa-utils package where the alsa-utils package does not depend on all of the little extra packages it's supposed to pull in. I'm not sure what the best way to fix this is though. Can anyone give me a little guidance or point me at a recipe that does this correctly already? Thanks, Dan Lazzari Jr. Firmware Engineer dlazz...@leapfrog.com ___ 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 v2] Fix avahi x11 dependency with non-GPLv3 Build
Op 20 sep. 2011, om 20:26 heeft Saul Wold het volgende geschreven: > This version removes the DISTRO_FEATURE check for x11 and simply > removes the DEPENDS on gtk and sets --disable-gtk to EXTRA_OECONF. > > If someone uses/needs the avahi-ui bits, they are available in the > OE repo, we would consider taking them into oe-core if there is a clear > need for it. Can't you just port over the OE classic recipe instead of this half-baked patch? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] avahi: remove avahi-ui related packages
[YOCTO #1492]
This patch removes the UI related packages from avahi. This
allows the package to be built without gtk and GPLv3 issues.
Signed-off-by: Saul Wold
---
meta/recipes-connectivity/avahi/avahi.inc | 19 +++
1 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/meta/recipes-connectivity/avahi/avahi.inc
b/meta/recipes-connectivity/avahi/avahi.inc
index 24ea458..025805a 100644
--- a/meta/recipes-connectivity/avahi/avahi.inc
+++ b/meta/recipes-connectivity/avahi/avahi.inc
@@ -14,8 +14,9 @@ SECTION = "network"
# python scripts are under GPLv2+
LICENSE = "GPLv2+ & LGPLv2.1+"
-X11DEPENDS = "gtk+ libglade"
-DEPENDS = "expat libcap libdaemon dbus glib-2.0
${@base_contains('DISTRO_FEATURES', 'x11', '${X11DEPENDS}', '', d)}"
+INC_PR = "r6"
+
+DEPENDS = "expat libcap libdaemon dbus glib-2.0"
SRC_URI = "http://avahi.org/download/avahi-${PV}.tar.gz \
file://00avahi-autoipd \
@@ -30,8 +31,8 @@ EXTRA_OECONF = "--with-distro=debian \
--disable-gdbm \
--disable-mono \
--disable-monodoc \
+ --disable-gtk \
--disable-gtk3 \
-${@base_contains('DISTRO_FEATURES', 'x11', '--enable-gtk',
'--disable-gtk', d)} \
--disable-qt3 \
--disable-qt4 \
--disable-python \
@@ -39,7 +40,7 @@ EXTRA_OECONF = "--with-distro=debian \
--with-systemdsystemunitdir=${base_libdir}/systemd/system/ \
"
-PACKAGES =+ "avahi-systemd avahi-daemon libavahi-common libavahi-core
libavahi-client avahi-dnsconfd libavahi-glib libavahi-gobject avahi-autoipd
avahi-ui-utils avahi-utils libavahi-ui libavahi-ui-dev"
+PACKAGES =+ "avahi-systemd avahi-daemon libavahi-common libavahi-core
libavahi-client avahi-dnsconfd libavahi-glib libavahi-gobject libavahi-ui
avahi-autoipd avahi-utils"
FILES_avahi-systemd = "${base_libdir}/systemd"
RDEPENDS_avahi-systemd = "avahi-daemon"
@@ -73,10 +74,6 @@ FILES_avahi-autoipd = "${sbindir}/avahi-autoipd \
${sysconfdir}/dhcp3/*/avahi-autoipd"
FILES_libavahi-common = "${libdir}/libavahi-common.so.*"
FILES_libavahi-core = "${libdir}/libavahi-core.so.*"
-FILES_libavahi-ui = "${libdir}/libavahi-ui.so.*"
-FILES_libavahi-ui-dev = "${libdir}/libavahi-ui.* \
- ${includedir}/avahi-ui/* \
- ${libdir}/pkgconfig/avahi-ui.pc"
FILES_avahi-daemon = "${sbindir}/avahi-daemon \
${sysconfdir}/avahi/avahi-daemon.conf \
${sysconfdir}/avahi/hosts \
@@ -88,16 +85,13 @@ FILES_avahi-daemon = "${sbindir}/avahi-daemon \
${datadir}/avahi/service-types \
${datadir}/dbus-1/system-services"
FILES_libavahi-client = "${libdir}/libavahi-client.so.*"
+FILES_libavahi-ui = "${libdir}/libavahi-ui.so.*"
FILES_avahi-dnsconfd = "${sbindir}/avahi-dnsconfd \
${sysconfdir}/avahi/avahi-dnsconfd.action \
${sysconfdir}/init.d/avahi-dnsconfd"
FILES_libavahi-glib = "${libdir}/libavahi-glib.so.*"
FILES_libavahi-gobject = "${libdir}/libavahi-gobject.so.*"
FILES_avahi-utils = "${bindir}/avahi-*"
-FILES_avahi-ui-utils = "${bindir}/bssh ${bindir}/bvnc ${bindir}/bshell \
-${bindir}/avahi-discover-standalone \
-${datadir}/applications \
-${datadir}/avahi/interfaces"
RRECOMMENDS_avahi-dev = "expat-dev libcap-dev libdaemon-dev dbus-dev
glib-2.0-dev update-rc.d-dev"
RRECOMMENDS_avahi-dev_append_libc-glibc = " gettext-dev"
@@ -119,6 +113,7 @@ do_install() {
# /var/run of current version is empty, so just remove it.
# if /var/run become non-empty in the future, need to install it via
volatile
rm -rf ${D}/var/run
+ rm -rf ${D}${datadir}/dbus-1/interfaces
}
# At the time the postinst runs, dbus might not be setup so only restart if
running
--
1.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1 v2] Fix avahi x11 dependency with non-GPLv3 Build
This version removes the DISTRO_FEATURE check for x11 and simply removes the DEPENDS on gtk and sets --disable-gtk to EXTRA_OECONF. If someone uses/needs the avahi-ui bits, they are available in the OE repo, we would consider taking them into oe-core if there is a clear need for it. Sau! The following changes since commit 81274f4488fbc4d68d150870735ec0181b60b451: freetype: disable bzip2 compressed font support (2011-09-19 13:14:03 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib sgw/oe-fix http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=sgw/oe-fix Saul Wold (1): avahi: remove avahi-ui related packages meta/recipes-connectivity/avahi/avahi.inc | 19 +++ 1 files changed, 7 insertions(+), 12 deletions(-) -- 1.7.6 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Multilib status
On 9/20/11 12:34 PM, Xu, Dongxiao wrote:
>> -Original Message-
>> From: Mark Hatle [mailto:mark.ha...@windriver.com]
>> Sent: Wednesday, September 21, 2011 1:06 AM
>> To: Xu, Dongxiao
>> Cc: Richard Purdie; openembedded-core
>> Subject: Re: Multilib status
>>
>> commit id aea5b9ef458099efd8f9a83428af84bbbe69eed2
>>
>> I'm really not sure what I have is right though.. it seems to be not
>> failing..
>> ;) But you likely know what should trigger these changes and if what I did
>> is
>> correct or not.
>
> What I was trying to solve with the previous commit is to handle the multiple
> (r)provider issue of those allarch recipes.
>
> It seems that although your changes don't solve the above problem, they are
> needed to handle RPROVIDES mappings.
>
> For the multiple provider issue, I will discuss it with Richard tomorrow.
Ya, what I sent out early was broken.. I think I have it working now:
poky-contrib.git -- commit id: d971a73d970b8f0beeded599f95a6d8ce5c32a4c
This seems to correctly specify the PROVIDES, RPROVIDES and RPROVIDES_ for
the multilibs now.. I'm still not sure that this is right though, because it may
change the PROVIDES/RPROVIDES for packages that were previously cached from non
multilib builds.. but it's progress.
--Mark
> Thanks,
> Dongxiao
>
>>
>> --Mark
>>
>> On 9/20/11 11:57 AM, Xu, Dongxiao wrote:
>> -Original Message-
>> From: Mark Hatle [mailto:mark.ha...@windriver.com]
>> Sent: Saturday, September 17, 2011 2:19 AM
>> To: Mark Hatle
>> Cc: Xu, Dongxiao; Richard Purdie; openembedded-core
>> Subject: Re: Multilib status
>>
>> Just an FYI. I'm working through a bunch of issues. I found out
>> that the RPM dependency resolution was completely broken, due to a
>> small bug in the package_rpm.bbclass.. Packages were not being
>> given the proper provide information, so RPM was attempting best
>> match -- and failing as noted in the previous discussion..
>>
>> Unfortunately this has opened up a small can of worms which I'm
>> trying to deal with. The simplistic fix for the bug is:
>>
>> --- a/meta/classes/package_rpm.bbclass
>> +++ b/meta/classes/package_rpm.bbclass
>> @@ -840,7 +840,7 @@ python do_package_rpm () {
>> os.chmod(outdepends, 0755)
>>
>> # Poky / RPM Provides
>> - outprovides = workdir + "/" + srcname + ".requires"
>> + outprovides = workdir + "/" + srcname + ".provides"
>>
>> try:
>> from __builtin__ import file
>>
>> Unfortunately this has exposed a large set of problems that I
>> didn't realize we had
>>
>> Will do a more formal pull request as soon as I get things working again.
>>
>> --Mark
>
> I just had a test after cherry-pick some of your changes in
> mhatle/rpm, here
are some problems I found and some investigations:
>
> 1. do_rootfs failed.
> The error log reports unmet dependency of pkgconfig(libpng).
> This is due to the dangling link in libpng package. libpng.pc links
> to libpng12.pc
which has been packaged into libpng12.
Ahh this is a bit different then the failures I've seen. We'll have to
fix that
>> one.
> 2. There is a wrong commit I suppose it should be reverted. When you
debugging your code, please revert it.
> I will discuss it with Richard tomorrow.
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=mha
> tl e/rpm&id=329d864f9bbf94ad3aae8df43d63fe10e4237e4f
Ahh, ya I just ran into that problem... I have a fix for that commit I just
>> finished.
(Do you have a newer version, if so I'll update to that and see if my
change is still
needed.)
>>>
>>> No I haven't worked on a new version of that patch. Could you share yours?
>>>
>>> Thanks,
>>> Dongxiao
>>>
> 3. After the above issue got fixed, rootfs succeed but we saw the
> final image is
still in a mess. We need some x86_64 rpm to be installed, however
what we got is x86 rpm package. Then I tried another approach we ever
talked about that, firstly install base image, then install the
multilib packages. I added a parameter "--replacepkgs" to rpm command
to avoid errors like "package xxx has already installed". With this
approach, the final image could boot up with multilib library installed.
>
> Some of my testing code is located under
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=dxu4/m
> l-
> testing
I'll run through the testing code and see if I can figure out what is
different.
--Mark
> Thanks,
> Dongxiao
>
>
>>
>> On 9/16/11 10:26 AM, Mark Hatle wrote:
>>> On 9/16/11 10:21 AM, Xu, Dongxiao wrote:
>>> -Original Message-
>>> From: Mark Hatle [mailto:mark.ha...@windriver.com]
>>> Sent: Friday, Se
Re: [OE-core] [PATCH 0/3] [oe-core & yocto RC] Fix unfetchable zypp-related packages
On 09/20/2011 01:32 AM, Anders Darander wrote: openSUSE has moved several of it's projects from gitorious to github. Lately, these has become unfetchable from gitorius, thus the SRC_URI fixes are needed also for the upcoming yocto release. No other changes are included, SRCREV's are kept the same. The following changes since commit 81274f4488fbc4d68d150870735ec0181b60b451: freetype: disable bzip2 compressed font support (2011-09-19 13:14:03 +0100) are available in the git repository at: git://github.com/darander/oe-core opensuse-fixes https://github.com/darander/oe-core/tree/opensuse-fixes Anders Darander (3): libzypp: git repo moved to github sat-solver: git repo moved to github zypper: git repo moved to github meta/recipes-extended/libzypp/libzypp_git.bb |2 +- meta/recipes-extended/sat-solver/sat-solver_git.bb |2 +- meta/recipes-extended/zypper/zypper_git.bb |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) Do these need PR Bumps? Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Multilib status
> -Original Message-
> From: Mark Hatle [mailto:mark.ha...@windriver.com]
> Sent: Wednesday, September 21, 2011 1:06 AM
> To: Xu, Dongxiao
> Cc: Richard Purdie; openembedded-core
> Subject: Re: Multilib status
>
> commit id aea5b9ef458099efd8f9a83428af84bbbe69eed2
>
> I'm really not sure what I have is right though.. it seems to be not failing..
> ;) But you likely know what should trigger these changes and if what I did is
> correct or not.
What I was trying to solve with the previous commit is to handle the multiple
(r)provider issue of those allarch recipes.
It seems that although your changes don't solve the above problem, they are
needed to handle RPROVIDES mappings.
For the multiple provider issue, I will discuss it with Richard tomorrow.
Thanks,
Dongxiao
>
> --Mark
>
> On 9/20/11 11:57 AM, Xu, Dongxiao wrote:
> -Original Message-
> From: Mark Hatle [mailto:mark.ha...@windriver.com]
> Sent: Saturday, September 17, 2011 2:19 AM
> To: Mark Hatle
> Cc: Xu, Dongxiao; Richard Purdie; openembedded-core
> Subject: Re: Multilib status
>
> Just an FYI. I'm working through a bunch of issues. I found out
> that the RPM dependency resolution was completely broken, due to a
> small bug in the package_rpm.bbclass.. Packages were not being
> given the proper provide information, so RPM was attempting best
> match -- and failing as noted in the previous discussion..
>
> Unfortunately this has opened up a small can of worms which I'm
> trying to deal with. The simplistic fix for the bug is:
>
> --- a/meta/classes/package_rpm.bbclass
> +++ b/meta/classes/package_rpm.bbclass
> @@ -840,7 +840,7 @@ python do_package_rpm () {
> os.chmod(outdepends, 0755)
>
> # Poky / RPM Provides
> - outprovides = workdir + "/" + srcname + ".requires"
> + outprovides = workdir + "/" + srcname + ".provides"
>
> try:
> from __builtin__ import file
>
> Unfortunately this has exposed a large set of problems that I
> didn't realize we had
>
> Will do a more formal pull request as soon as I get things working again.
>
> --Mark
> >>>
> >>> I just had a test after cherry-pick some of your changes in
> >>> mhatle/rpm, here
> >> are some problems I found and some investigations:
> >>>
> >>> 1. do_rootfs failed.
> >>> The error log reports unmet dependency of pkgconfig(libpng).
> >>> This is due to the dangling link in libpng package. libpng.pc links
> >>> to libpng12.pc
> >> which has been packaged into libpng12.
> >>
> >> Ahh this is a bit different then the failures I've seen. We'll have to
> >> fix that
> one.
> >>
> >>> 2. There is a wrong commit I suppose it should be reverted. When you
> >> debugging your code, please revert it.
> >>> I will discuss it with Richard tomorrow.
> >>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=mha
> >>> tl e/rpm&id=329d864f9bbf94ad3aae8df43d63fe10e4237e4f
> >>
> >> Ahh, ya I just ran into that problem... I have a fix for that commit I just
> finished.
> >> (Do you have a newer version, if so I'll update to that and see if my
> >> change is still
> >> needed.)
> >
> > No I haven't worked on a new version of that patch. Could you share yours?
> >
> > Thanks,
> > Dongxiao
> >
> >>
> >>> 3. After the above issue got fixed, rootfs succeed but we saw the
> >>> final image is
> >> still in a mess. We need some x86_64 rpm to be installed, however
> >> what we got is x86 rpm package. Then I tried another approach we ever
> >> talked about that, firstly install base image, then install the
> >> multilib packages. I added a parameter "--replacepkgs" to rpm command
> >> to avoid errors like "package xxx has already installed". With this
> >> approach, the final image could boot up with multilib library installed.
> >>>
> >>> Some of my testing code is located under
> >>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=dxu4/m
> >>> l-
> >>> testing
> >>
> >> I'll run through the testing code and see if I can figure out what is
> >> different.
> >>
> >> --Mark
> >>
> >>> Thanks,
> >>> Dongxiao
> >>>
> >>>
>
> On 9/16/11 10:26 AM, Mark Hatle wrote:
> > On 9/16/11 10:21 AM, Xu, Dongxiao wrote:
> > -Original Message-
> > From: Mark Hatle [mailto:mark.ha...@windriver.com]
> > Sent: Friday, September 16, 2011 10:51 PM
> > To: Richard Purdie
> > Cc: Xu, Dongxiao; openembedded-core
> > Subject: Re: Multilib status
> >
> > On 9/16/11 4:32 AM, Richard Purdie wrote:
> >>> Hi Mark/Dongxaio,
> >>>
> >>> We really need to get the remainder of the multilib bugs
> >>> wrapped up. I think there is some confusion about the exact
> >>> approach to take to fix some of them so I'm hoping to try
> >>> and summarise the probl
Re: [OE-core] Multilib status
commit id aea5b9ef458099efd8f9a83428af84bbbe69eed2
I'm really not sure what I have is right though.. it seems to be not failing..
;) But you likely know what should trigger these changes and if what I did is
correct or not.
--Mark
On 9/20/11 11:57 AM, Xu, Dongxiao wrote:
-Original Message-
From: Mark Hatle [mailto:mark.ha...@windriver.com]
Sent: Saturday, September 17, 2011 2:19 AM
To: Mark Hatle
Cc: Xu, Dongxiao; Richard Purdie; openembedded-core
Subject: Re: Multilib status
Just an FYI. I'm working through a bunch of issues. I found out
that the RPM dependency resolution was completely broken, due to a
small bug in the package_rpm.bbclass.. Packages were not being given
the proper provide information, so RPM was attempting best match --
and failing as noted in the previous discussion..
Unfortunately this has opened up a small can of worms which I'm
trying to deal with. The simplistic fix for the bug is:
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -840,7 +840,7 @@ python do_package_rpm () {
os.chmod(outdepends, 0755)
# Poky / RPM Provides
- outprovides = workdir + "/" + srcname + ".requires"
+ outprovides = workdir + "/" + srcname + ".provides"
try:
from __builtin__ import file
Unfortunately this has exposed a large set of problems that I didn't
realize we had
Will do a more formal pull request as soon as I get things working again.
--Mark
>>>
>>> I just had a test after cherry-pick some of your changes in mhatle/rpm, here
>> are some problems I found and some investigations:
>>>
>>> 1. do_rootfs failed.
>>> The error log reports unmet dependency of pkgconfig(libpng).
>>> This is due to the dangling link in libpng package. libpng.pc links to
>>> libpng12.pc
>> which has been packaged into libpng12.
>>
>> Ahh this is a bit different then the failures I've seen. We'll have to fix
>> that one.
>>
>>> 2. There is a wrong commit I suppose it should be reverted. When you
>> debugging your code, please revert it.
>>> I will discuss it with Richard tomorrow.
>>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=mhatl
>>> e/rpm&id=329d864f9bbf94ad3aae8df43d63fe10e4237e4f
>>
>> Ahh, ya I just ran into that problem... I have a fix for that commit I just
>> finished.
>> (Do you have a newer version, if so I'll update to that and see if my change
>> is still
>> needed.)
>
> No I haven't worked on a new version of that patch. Could you share yours?
>
> Thanks,
> Dongxiao
>
>>
>>> 3. After the above issue got fixed, rootfs succeed but we saw the final
>>> image is
>> still in a mess. We need some x86_64 rpm to be installed, however what we got
>> is x86 rpm package. Then I tried another approach we ever talked about that,
>> firstly install base image, then install the multilib packages. I added a
>> parameter
>> "--replacepkgs" to rpm command to avoid errors like "package xxx has already
>> installed". With this approach, the final image could boot up with multilib
>> library
>> installed.
>>>
>>> Some of my testing code is located under
>>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=dxu4/ml-
>>> testing
>>
>> I'll run through the testing code and see if I can figure out what is
>> different.
>>
>> --Mark
>>
>>> Thanks,
>>> Dongxiao
>>>
>>>
On 9/16/11 10:26 AM, Mark Hatle wrote:
> On 9/16/11 10:21 AM, Xu, Dongxiao wrote:
> -Original Message-
> From: Mark Hatle [mailto:mark.ha...@windriver.com]
> Sent: Friday, September 16, 2011 10:51 PM
> To: Richard Purdie
> Cc: Xu, Dongxiao; openembedded-core
> Subject: Re: Multilib status
>
> On 9/16/11 4:32 AM, Richard Purdie wrote:
>>> Hi Mark/Dongxaio,
>>>
>>> We really need to get the remainder of the multilib bugs
>>> wrapped up. I think there is some confusion about the exact
>>> approach to take to fix some of them so I'm hoping to try and
>>> summarise the problems here so we can work out some resolutions.
>
> Let me explain where I am quickly. I just spent two days
> working on reproducing the issue(s). So far I've not reproduced
> the direct failures but a series of others. I finally figured
> out part of the reason I wasn't seeing this. I had a typo in my
configuration:
>
> DEFAULTTUNE-virtclass-mulitlib-lib32 = "x86"
>
> This resulted in two sets of binaries normal and lib32 that were
> more or less identical in the RPM case. We -really- need a
> sanity check that stupid typos like that don't cause problems.
>
> ---
>
> So now that I finally have a built with that done... see below.
>
Re: [OE-core] Multilib status
> >> -Original Message-
> >> From: Mark Hatle [mailto:mark.ha...@windriver.com]
> >> Sent: Saturday, September 17, 2011 2:19 AM
> >> To: Mark Hatle
> >> Cc: Xu, Dongxiao; Richard Purdie; openembedded-core
> >> Subject: Re: Multilib status
> >>
> >> Just an FYI. I'm working through a bunch of issues. I found out
> >> that the RPM dependency resolution was completely broken, due to a
> >> small bug in the package_rpm.bbclass.. Packages were not being given
> >> the proper provide information, so RPM was attempting best match --
> >> and failing as noted in the previous discussion..
> >>
> >> Unfortunately this has opened up a small can of worms which I'm
> >> trying to deal with. The simplistic fix for the bug is:
> >>
> >> --- a/meta/classes/package_rpm.bbclass
> >> +++ b/meta/classes/package_rpm.bbclass
> >> @@ -840,7 +840,7 @@ python do_package_rpm () {
> >> os.chmod(outdepends, 0755)
> >>
> >> # Poky / RPM Provides
> >> - outprovides = workdir + "/" + srcname + ".requires"
> >> + outprovides = workdir + "/" + srcname + ".provides"
> >>
> >> try:
> >> from __builtin__ import file
> >>
> >> Unfortunately this has exposed a large set of problems that I didn't
> >> realize we had
> >>
> >> Will do a more formal pull request as soon as I get things working again.
> >>
> >> --Mark
> >
> > I just had a test after cherry-pick some of your changes in mhatle/rpm, here
> are some problems I found and some investigations:
> >
> > 1. do_rootfs failed.
> > The error log reports unmet dependency of pkgconfig(libpng).
> > This is due to the dangling link in libpng package. libpng.pc links to
> > libpng12.pc
> which has been packaged into libpng12.
>
> Ahh this is a bit different then the failures I've seen. We'll have to fix
> that one.
>
> > 2. There is a wrong commit I suppose it should be reverted. When you
> debugging your code, please revert it.
> > I will discuss it with Richard tomorrow.
> > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=mhatl
> > e/rpm&id=329d864f9bbf94ad3aae8df43d63fe10e4237e4f
>
> Ahh, ya I just ran into that problem... I have a fix for that commit I just
> finished.
> (Do you have a newer version, if so I'll update to that and see if my change
> is still
> needed.)
No I haven't worked on a new version of that patch. Could you share yours?
Thanks,
Dongxiao
>
> > 3. After the above issue got fixed, rootfs succeed but we saw the final
> > image is
> still in a mess. We need some x86_64 rpm to be installed, however what we got
> is x86 rpm package. Then I tried another approach we ever talked about that,
> firstly install base image, then install the multilib packages. I added a
> parameter
> "--replacepkgs" to rpm command to avoid errors like "package xxx has already
> installed". With this approach, the final image could boot up with multilib
> library
> installed.
> >
> > Some of my testing code is located under
> > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=dxu4/ml-
> > testing
>
> I'll run through the testing code and see if I can figure out what is
> different.
>
> --Mark
>
> > Thanks,
> > Dongxiao
> >
> >
> >>
> >> On 9/16/11 10:26 AM, Mark Hatle wrote:
> >>> On 9/16/11 10:21 AM, Xu, Dongxiao wrote:
> >>> -Original Message-
> >>> From: Mark Hatle [mailto:mark.ha...@windriver.com]
> >>> Sent: Friday, September 16, 2011 10:51 PM
> >>> To: Richard Purdie
> >>> Cc: Xu, Dongxiao; openembedded-core
> >>> Subject: Re: Multilib status
> >>>
> >>> On 9/16/11 4:32 AM, Richard Purdie wrote:
> > Hi Mark/Dongxaio,
> >
> > We really need to get the remainder of the multilib bugs
> > wrapped up. I think there is some confusion about the exact
> > approach to take to fix some of them so I'm hoping to try and
> > summarise the problems here so we can work out some resolutions.
> >>>
> >>> Let me explain where I am quickly. I just spent two days
> >>> working on reproducing the issue(s). So far I've not reproduced
> >>> the direct failures but a series of others. I finally figured
> >>> out part of the reason I wasn't seeing this. I had a typo in my
> >> configuration:
> >>>
> >>> DEFAULTTUNE-virtclass-mulitlib-lib32 = "x86"
> >>>
> >>> This resulted in two sets of binaries normal and lib32 that were
> >>> more or less identical in the RPM case. We -really- need a
> >>> sanity check that stupid typos like that don't cause problems.
> >>>
> >>> ---
> >>>
> >>> So now that I finally have a built with that done... see below.
> >>>
> > Problem A
> > =
> >
> > We can have multiple forms of "machine specific" packages now,
> > one for each multilib e.g.:
> >
> > task-core-x11-base-1.0-r34.qemux86_64.rpm ("normal")
> > task-core-x11-base-1.0-r34.qemux86_64.rpm ("lib64
Re: [OE-core] Multilib status
On 9/20/11 10:01 AM, Xu, Dongxiao wrote:
> Hi Mark,
>
>> -Original Message-
>> From: Mark Hatle [mailto:mark.ha...@windriver.com]
>> Sent: Saturday, September 17, 2011 2:19 AM
>> To: Mark Hatle
>> Cc: Xu, Dongxiao; Richard Purdie; openembedded-core
>> Subject: Re: Multilib status
>>
>> Just an FYI. I'm working through a bunch of issues. I found out that the
>> RPM
>> dependency resolution was completely broken, due to a small bug in the
>> package_rpm.bbclass.. Packages were not being given the proper provide
>> information, so RPM was attempting best match -- and failing as noted in the
>> previous discussion..
>>
>> Unfortunately this has opened up a small can of worms which I'm trying to
>> deal
>> with. The simplistic fix for the bug is:
>>
>> --- a/meta/classes/package_rpm.bbclass
>> +++ b/meta/classes/package_rpm.bbclass
>> @@ -840,7 +840,7 @@ python do_package_rpm () {
>> os.chmod(outdepends, 0755)
>>
>> # Poky / RPM Provides
>> - outprovides = workdir + "/" + srcname + ".requires"
>> + outprovides = workdir + "/" + srcname + ".provides"
>>
>> try:
>> from __builtin__ import file
>>
>> Unfortunately this has exposed a large set of problems that I didn't realize
>> we
>> had
>>
>> Will do a more formal pull request as soon as I get things working again.
>>
>> --Mark
>
> I just had a test after cherry-pick some of your changes in mhatle/rpm, here
> are some problems I found and some investigations:
>
> 1. do_rootfs failed.
> The error log reports unmet dependency of pkgconfig(libpng).
> This is due to the dangling link in libpng package. libpng.pc links to
> libpng12.pc which has been packaged into libpng12.
Ahh this is a bit different then the failures I've seen. We'll have to fix that
one.
> 2. There is a wrong commit I suppose it should be reverted. When you
> debugging your code, please revert it.
> I will discuss it with Richard tomorrow.
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=mhatle/rpm&id=329d864f9bbf94ad3aae8df43d63fe10e4237e4f
Ahh, ya I just ran into that problem... I have a fix for that commit I just
finished. (Do you have a newer version, if so I'll update to that and see if my
change is still needed.)
> 3. After the above issue got fixed, rootfs succeed but we saw the final image
> is still in a mess. We need some x86_64 rpm to be installed, however what we
> got is x86 rpm package. Then I tried another approach we ever talked about
> that, firstly install base image, then install the multilib packages. I added
> a parameter "--replacepkgs" to rpm command to avoid errors like "package xxx
> has already installed". With this approach, the final image could boot up
> with multilib library installed.
>
> Some of my testing code is located under
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=dxu4/ml-testing
I'll run through the testing code and see if I can figure out what is different.
--Mark
> Thanks,
> Dongxiao
>
>
>>
>> On 9/16/11 10:26 AM, Mark Hatle wrote:
>>> On 9/16/11 10:21 AM, Xu, Dongxiao wrote:
>>> -Original Message-
>>> From: Mark Hatle [mailto:mark.ha...@windriver.com]
>>> Sent: Friday, September 16, 2011 10:51 PM
>>> To: Richard Purdie
>>> Cc: Xu, Dongxiao; openembedded-core
>>> Subject: Re: Multilib status
>>>
>>> On 9/16/11 4:32 AM, Richard Purdie wrote:
> Hi Mark/Dongxaio,
>
> We really need to get the remainder of the multilib bugs
> wrapped up. I think there is some confusion about the exact
> approach to take to fix some of them so I'm hoping to try and
> summarise the problems here so we can work out some resolutions.
>>>
>>> Let me explain where I am quickly. I just spent two days working
>>> on reproducing the issue(s). So far I've not reproduced the
>>> direct failures but a series of others. I finally figured out
>>> part of the reason I wasn't seeing this. I had a typo in my
>> configuration:
>>>
>>> DEFAULTTUNE-virtclass-mulitlib-lib32 = "x86"
>>>
>>> This resulted in two sets of binaries normal and lib32 that were
>>> more or less identical in the RPM case. We -really- need a
>>> sanity check that stupid typos like that don't cause problems.
>>>
>>> ---
>>>
>>> So now that I finally have a built with that done... see below.
>>>
> Problem A
> =
>
> We can have multiple forms of "machine specific" packages now,
> one for each multilib e.g.:
>
> task-core-x11-base-1.0-r34.qemux86_64.rpm ("normal")
> task-core-x11-base-1.0-r34.qemux86_64.rpm ("lib64")
> task-core-x11-base-1.0-r34.qemux86_64.rpm ("lib32")
>
> (lets assume the first uses /lib/, the second /lib64/ and the
> thrid /lib32/, an artificial example I realise)
>
> I know one proposal was to map:
Re: [OE-core] Multilib status
Hi Mark,
> -Original Message-
> From: Mark Hatle [mailto:mark.ha...@windriver.com]
> Sent: Saturday, September 17, 2011 2:19 AM
> To: Mark Hatle
> Cc: Xu, Dongxiao; Richard Purdie; openembedded-core
> Subject: Re: Multilib status
>
> Just an FYI. I'm working through a bunch of issues. I found out that the RPM
> dependency resolution was completely broken, due to a small bug in the
> package_rpm.bbclass.. Packages were not being given the proper provide
> information, so RPM was attempting best match -- and failing as noted in the
> previous discussion..
>
> Unfortunately this has opened up a small can of worms which I'm trying to deal
> with. The simplistic fix for the bug is:
>
> --- a/meta/classes/package_rpm.bbclass
> +++ b/meta/classes/package_rpm.bbclass
> @@ -840,7 +840,7 @@ python do_package_rpm () {
> os.chmod(outdepends, 0755)
>
> # Poky / RPM Provides
> - outprovides = workdir + "/" + srcname + ".requires"
> + outprovides = workdir + "/" + srcname + ".provides"
>
> try:
> from __builtin__ import file
>
> Unfortunately this has exposed a large set of problems that I didn't realize
> we
> had
>
> Will do a more formal pull request as soon as I get things working again.
>
> --Mark
I just had a test after cherry-pick some of your changes in mhatle/rpm, here
are some problems I found and some investigations:
1. do_rootfs failed.
The error log reports unmet dependency of pkgconfig(libpng).
This is due to the dangling link in libpng package. libpng.pc links to
libpng12.pc which has been packaged into libpng12.
2. There is a wrong commit I suppose it should be reverted. When you debugging
your code, please revert it.
I will discuss it with Richard tomorrow.
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=mhatle/rpm&id=329d864f9bbf94ad3aae8df43d63fe10e4237e4f
3. After the above issue got fixed, rootfs succeed but we saw the final image
is still in a mess. We need some x86_64 rpm to be installed, however what we
got is x86 rpm package. Then I tried another approach we ever talked about
that, firstly install base image, then install the multilib packages. I added a
parameter "--replacepkgs" to rpm command to avoid errors like "package xxx has
already installed". With this approach, the final image could boot up with
multilib library installed.
Some of my testing code is located under
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=dxu4/ml-testing
Thanks,
Dongxiao
>
> On 9/16/11 10:26 AM, Mark Hatle wrote:
> > On 9/16/11 10:21 AM, Xu, Dongxiao wrote:
> >>> >> -Original Message-
> >>> >> From: Mark Hatle [mailto:mark.ha...@windriver.com]
> >>> >> Sent: Friday, September 16, 2011 10:51 PM
> >>> >> To: Richard Purdie
> >>> >> Cc: Xu, Dongxiao; openembedded-core
> >>> >> Subject: Re: Multilib status
> >>> >>
> >>> >> On 9/16/11 4:32 AM, Richard Purdie wrote:
> >>> Hi Mark/Dongxaio,
> >>>
> >>> We really need to get the remainder of the multilib bugs
> >>> wrapped up. I think there is some confusion about the exact
> >>> approach to take to fix some of them so I'm hoping to try and
> >>> summarise the problems here so we can work out some resolutions.
> >>> >>
> >>> >> Let me explain where I am quickly. I just spent two days working
> >>> >> on reproducing the issue(s). So far I've not reproduced the
> >>> >> direct failures but a series of others. I finally figured out
> >>> >> part of the reason I wasn't seeing this. I had a typo in my
> configuration:
> >>> >>
> >>> >> DEFAULTTUNE-virtclass-mulitlib-lib32 = "x86"
> >>> >>
> >>> >> This resulted in two sets of binaries normal and lib32 that were
> >>> >> more or less identical in the RPM case. We -really- need a
> >>> >> sanity check that stupid typos like that don't cause problems.
> >>> >>
> >>> >> ---
> >>> >>
> >>> >> So now that I finally have a built with that done... see below.
> >>> >>
> >>> Problem A
> >>> =
> >>>
> >>> We can have multiple forms of "machine specific" packages now,
> >>> one for each multilib e.g.:
> >>>
> >>> task-core-x11-base-1.0-r34.qemux86_64.rpm ("normal")
> >>> task-core-x11-base-1.0-r34.qemux86_64.rpm ("lib64")
> >>> task-core-x11-base-1.0-r34.qemux86_64.rpm ("lib32")
> >>>
> >>> (lets assume the first uses /lib/, the second /lib64/ and the
> >>> thrid /lib32/, an artificial example I realise)
> >>>
> >>> I know one proposal was to map:
> >>>
> >>> task-core-x11-base-1.0-r34.lib32_qemux86_64.rpm to
> >>> task-core-x11-base-1.0-r34.lib32_qemux86.rpm but this isn't
> >>> correct since the library directories are different. In this
> >>> specific case it might not matter but in general it would. What
> >>> is also important is that the different versions imply
> >>> different dependencies. The lib64 bit version would pull in and
> >>> sele
Re: [OE-core] [PATCH 0/3] Various hob fixes
Wrong list, apologies for the noise! Joshua On Mon, 2011-09-19 at 15:41 -0700, Joshua Lock wrote: > This series contains 3 bug fixes. > > The first has been submitted previously but hasn't been applied or commented > on so I've rolled it into this pull request. > > Patch one and two contain bug fixes for reported issues, patch three is a > minor change but a noticable one should one stumble accross it. > > Please review and consider for master and the Yocto 1.1 release. > > Regards, > Joshua > > The following changes since commit 3e7f8afeacf7c8c8de3e87778a3907e33d4a06b3: > > fetch2/git: fix subpath destination directory (2011-09-19 12:33:38 +0100) > > are available in the git repository at: > git://github.com/incandescant/bitbake hob > https://github.com/incandescant/bitbake/tree/hob > > Joshua Lock (3): > ui/crumbs/hobprefs: re-enable reloading of data after prefs changes > hob: fix build again when building packages only > hob: enable package only builds even if an image has been built > > lib/bb/ui/crumbs/hobeventhandler.py | 13 + > lib/bb/ui/crumbs/hobprefs.py|2 +- > lib/bb/ui/hob.py| 12 > 3 files changed, 14 insertions(+), 13 deletions(-) > -- Joshua Lock Yocto Project "Johannes factotum" 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] [RFC] bluez4: split gstreamer plugin into a seperate recipe
On Tuesday 20 September 2011 12:08:16 Koen Kooi wrote:
> This eliminates a good chunk of buildtime when building console-only image.
>
> The bluez4 and this recipe share a .inc file since the source is the same.
>
> Signed-off-by: Koen Kooi
> ---
> meta/recipes-connectivity/bluez/bluez4.inc | 37 +++
> meta/recipes-connectivity/bluez/bluez4_4.96.bb | 49
> +++- .../bluez/gst-plugin-bluetooth_4.96.bb |
> 28 +++ 3 files changed, 72 insertions(+), 42 deletions(-)
> create mode 100644 meta/recipes-connectivity/bluez/bluez4.inc
> create mode 100644
> meta/recipes-connectivity/bluez/gst-plugin-bluetooth_4.96.bb
>
> diff --git a/meta/recipes-connectivity/bluez/bluez4.inc
> b/meta/recipes-connectivity/bluez/bluez4.inc new file mode 100644
> index 000..cc9810e
> --- /dev/null
> +++ b/meta/recipes-connectivity/bluez/bluez4.inc
> @@ -0,0 +1,37 @@
> +SUMMARY = "Linux Bluetooth Stack Userland V4"
> +DESCRIPTION = "Linux Bluetooth stack V4 userland components. These
> include a system configurations, daemons, tools and system libraries."
> +HOMEPAGE = "http://www.bluez.org";
> +SECTION = "libs"
> +LICENSE = "GPLv2+ & LGPLv2.1+"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
> +
> file://COPYING.LIB;md5=fb504b67c50331fc78734fed90fb0e09 \ +
>
> file://src/main.c;beginline=1;endline=24;md5=9bc54b93cd7e17bf03f52513f39f9
> 26e \ +
> file://sbc/sbc.c;beginline=1;endline=25;md5=1a40781ed30d50d8639323a184aeb1
> 91" +DEPENDS = "udev alsa-lib libusb dbus-glib"
> +RDEPENDS_${PN}-dev = "bluez-hcidump"
> +
> +ASNEEDED = ""
> +
> +SRC_URI = "\
> + ${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.gz \
> +"
> +S = "${WORKDIR}/bluez-${PV}"
> +
> +inherit autotools
> +
> +EXTRA_OECONF = "\
> + --disable-gstreamer \
> + --enable-alsa \
> + --enable-usb \
> + --enable-tools \
> + --enable-bccmd \
> + --enable-hid2hci \
> + --enable-dfutool \
> + --enable-hidd \
> + --enable-pand \
> + --enable-dund \
> + --disable-cups \
> + --enable-test \
> + --enable-configfiles \
> +"
> +
> diff --git a/meta/recipes-connectivity/bluez/bluez4_4.96.bb
> b/meta/recipes-connectivity/bluez/bluez4_4.96.bb index 994cec7..505e8f7
> 100644
> --- a/meta/recipes-connectivity/bluez/bluez4_4.96.bb
> +++ b/meta/recipes-connectivity/bluez/bluez4_4.96.bb
> @@ -1,47 +1,12 @@
> -SUMMARY = "Linux Bluetooth Stack Userland V4"
> -DESCRIPTION = "Linux Bluetooth stack V4 userland components. These
> include a system configurations, daemons, tools and system libraries."
> -HOMEPAGE = "http://www.bluez.org";
> -SECTION = "libs"
> -LICENSE = "GPLv2+ & LGPLv2.1+"
> -LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
> -
> file://COPYING.LIB;md5=fb504b67c50331fc78734fed90fb0e09 \ -
>
> file://src/main.c;beginline=1;endline=24;md5=9bc54b93cd7e17bf03f52513f39f9
> 26e \ -
> file://sbc/sbc.c;beginline=1;endline=25;md5=1a40781ed30d50d8639323a184aeb1
> 91" -DEPENDS = "udev gst-plugins-base alsa-lib libusb dbus-glib"
> -RDEPENDS_${PN}-dev = "bluez-hcidump"
> -
> -ASNEEDED = ""
> +require bluez4.inc
>
> -PR = "r0"
> +PR = "r1"
>
> -SRC_URI = "\
> - ${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.gz \
> - file://bluetooth.conf \
> -"
> +SRC_URI += "file://bluetooth.conf"
>
> SRC_URI[md5sum] = "296111afac49e3f9035085ac14daf518"
> SRC_URI[sha256sum] =
> "c06fd50fd77909cad55e3181a42c6bce7cfcf7abb8cd87871c13d0d70f87fa99"
>
> -S = "${WORKDIR}/bluez-${PV}"
> -
> -inherit autotools
> -
> -EXTRA_OECONF = "\
> - --enable-gstreamer \
> - --enable-alsa \
> - --enable-usb \
> - --enable-tools \
> - --enable-bccmd \
> - --enable-hid2hci \
> - --enable-dfutool \
> - --enable-hidd \
> - --enable-pand \
> - --enable-dund \
> - --disable-cups \
> - --enable-test \
> - --enable-configfiles \
> -"
> -
> do_install_append() {
> install -m 0644 ${S}/audio/audio.conf ${D}/${sysconfdir}/bluetooth/
> install -m 0644 ${S}/network/network.conf ${D}/${sysconfdir}/bluetooth/
> @@ -50,19 +15,19 @@ do_install_append() {
> install -m 0644 ${WORKDIR}/bluetooth.conf
> ${D}/${sysconfdir}/dbus-1/system.d/ }
>
> -PACKAGES =+ "gst-plugin-bluez libasound-module-bluez"
> +RDEPENDS_${PN}-dev = "bluez-hcidump"
> +
> +PACKAGES =+ "libasound-module-bluez"
>
> -FILES_gst-plugin-bluez = "${libdir}/gstreamer-0.10/lib*.so"
> FILES_libasound-module-bluez = "${libdir}/alsa-lib/lib*.so
> ${datadir}/alsa" FILES_${PN} += "${libdir}/bluetooth/plugins/*.so
> ${base_libdir}/udev/ ${base_libdir}/systemd/" FILES_${PN}-dev += "\
>${libdir}/bluetooth/plugins/*.la \
>${libdir}/alsa-lib/*.la \
> - ${libdir}/gstreamer-0.10/*.la \
> "
>
> FILES_${PN}-dbg += "\
>${libdir}/bluetooth/plugins/.debug \
>${libdir}/*/.debug \
>${base_libdir}/udev/.debug \
> -"
> +
> diff --git a/meta/recipes-connectivity/bluez/gst-plugin-bluetooth
[OE-core] OE Changelog for 2011-09-12 to 2011-09-19
Changelog for 2011-09-12 to 2011-09-19. Projects included in this report:
bitbake: git://git.openembedded.org/bitbake
openembedded-core: git://git.openembedded.org/openembedded-core
meta-openembedded: git://git.openembedded.org/meta-openembedded
meta-angstrom: git://git.angstrom-distribution.org/meta-angstrom
meta-yocto: git://git.yoctoproject.org/poky
meta-texasinstruments: git://git.angstrom-distribution.org/meta-texasinstruments
meta-smartphone: http://git.shr-project.org/repo/meta-smartphone.git
meta-micro: git://git.openembedded.org/meta-micro
meta-slugos: git://github.com/kraj/meta-slugos
meta-nslu2: git://github.com/kraj/meta-nslu2
meta-intel: git://git.yoctoproject.org/meta-intel
meta-handheld: git://git.openembedded.org/meta-handheld
meta-opie: git://git.openembedded.org/meta-opie
openembedded: git://git.openembedded.org/openembedded
Changelog for bitbake:
Christopher Larson (1):
taskdata: fix string formatting of an error message
Joshua Lock (5):
ui/crumbs/hobeventhandler: fix test for BBFILES
ui/crumbs/hobeventhandler: don't check BBPATH and BBFILES each build
hob: correctly handle an exception
hob: correctly set the selected image when loading a recipe
fetch2/wget: make checkstatus() quieter
Martin Jansa (2):
fetch2/git: fix logger.debug
fetch2/git: be more carefull in _contains_ref when checking git log output
Paul Eggleton (1):
fetch2/git: fix subpath destination directory
Richard Purdie (2):
git.py: Fix logging vs logger typo
cooker.py: Fix key expansion issues in showVersions
Changelog for openembedded-core:
Bernhard Guillon (1):
liboil-0.3.17: add upstream Fix-enable-vfp-flag patch
Bruce Ashfield (3):
linux-yocto: move common tasks to a common location
linux-yocto: split e100 and e1000 support
linux-yocto-rt: correct 3.0.3->3.0.4 mismerge for, stop_machine.c
Darren Hart (2):
Set an explicit path for the initrd scripts
Prevent IMAGE_FEATURES from contaminating initrd
Dexuan Cui (3):
dpkg: fix pkg_postinst_dpkg, don't supply {bindir}/update-alternatives
package_deb.bbclass, populate_sdk_deb.bbclass: fix meta-toolchain-gmae build
distro-tracking: Update package alias
Dmitry Eremin-Solenikov (3):
icecc-create-env: a tool to create icecc toolchain tarballs
icecc.bbclass: replace with updated version
bugzilla.bbclass: add a class to report build problems to bugzilla
Dongxiao Xu (3):
base.bbclass: do not expand PREFERRED_PROVIDER for kernel recipe
multilib: Remove recipe from multilib.conf that inherits allarch
distro_tracking: update package alias
Eric Bénard (1):
qt4: add blacklist-diginotar-certs patch
Joshua Lock (2):
sanity: disable mirrors for connectivity check
texinfo: several changes to build without zlib and ncurses headers on host
Khem Raj (1):
eglibc-2.13: Replace oewarn with bbwarn
Lianhao Lu (3):
debian/_ipk.bbclass: Added multilib support for package_name_hook()
Misc: Added MLPREFIX to final pkg names in case of DEBIAN_NAMES.
image/package.bbclass: Revise multilib support for DEBIAN_NAME.
Mark Hatle (1):
Uprev to latest version of prelink_git, fixing TLS issues
Martin Jansa (5):
openssh: update init script to create ECDSA keys if needed
task-core-boot: allow distributions to define login and init manager
subversion: remove neon-detection.patch and --with-neon option
abiword: be carefull with # comments ending with backslash
claws-mail: be carefull with # comments ending with backslash
Paul Eggleton (6):
task-core: split into task-core-console and task-core-x11
lib/oe/terminal.py: declare konsole from KDE 4.x as unsupported
sanity.bbclass: add a sanity check for KDE 4.x konsole in TERMCMD
libgcrypt: add libcap to DEPENDS
libgnome-keyring: add libgcrypt to DEPENDS
freetype: disable bzip2 compressed font support
Richard Purdie (4):
Revert "pango: use qemu to generate pango.modules during rootfs construction
core-image-minimal: Add missing POKY_EXTRA_IMAGE variable
cml1/kernel: Update do_menuconfig to use oe.terminal()
qemu: Fix reversed BGR values on ARM Versatile emulation
Saul Wold (4):
libzypp: move package-manger to it own package
task-core-sdk: change task-core -> task-core-console
web: Fix SRCREV due to lost commit in web-sato
base.bbclass: add crosssdk items to INCOMPATIBLE_LICENSE exclude list
Tom Zanussi (8):
initramfs-live-install: add support for grub2
grub2: new recipe
liberation-fonts_1.04: add PN to RDEPENDS
liberation-fonts_1.06: add PN to RDEPENDS
ttf-bitstream-vera_1.10: add PN to RDEPENDS
grub_1.99: add PN to RDEPENDS
initramfs-live-install: add PN to RDEPENDS
package.bbclass: fix spurious 'installed but not shipped' warning
Yu Ke (1):
distro_tracking_field: add distro checking field
Zhai Edwin (2):
opensp: Fix hard path in native nsgmls.
distro-tracking: Update alias
==
[OE-core] [RFC] bluez4: split gstreamer plugin into a seperate recipe
This eliminates a good chunk of buildtime when building console-only image.
The bluez4 and this recipe share a .inc file since the source is the same.
Signed-off-by: Koen Kooi
---
meta/recipes-connectivity/bluez/bluez4.inc | 37 +++
meta/recipes-connectivity/bluez/bluez4_4.96.bb | 49 +++-
.../bluez/gst-plugin-bluetooth_4.96.bb | 28 +++
3 files changed, 72 insertions(+), 42 deletions(-)
create mode 100644 meta/recipes-connectivity/bluez/bluez4.inc
create mode 100644 meta/recipes-connectivity/bluez/gst-plugin-bluetooth_4.96.bb
diff --git a/meta/recipes-connectivity/bluez/bluez4.inc
b/meta/recipes-connectivity/bluez/bluez4.inc
new file mode 100644
index 000..cc9810e
--- /dev/null
+++ b/meta/recipes-connectivity/bluez/bluez4.inc
@@ -0,0 +1,37 @@
+SUMMARY = "Linux Bluetooth Stack Userland V4"
+DESCRIPTION = "Linux Bluetooth stack V4 userland components. These include a
system configurations, daemons, tools and system libraries."
+HOMEPAGE = "http://www.bluez.org";
+SECTION = "libs"
+LICENSE = "GPLv2+ & LGPLv2.1+"
+LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
+file://COPYING.LIB;md5=fb504b67c50331fc78734fed90fb0e09 \
+
file://src/main.c;beginline=1;endline=24;md5=9bc54b93cd7e17bf03f52513f39f926e \
+
file://sbc/sbc.c;beginline=1;endline=25;md5=1a40781ed30d50d8639323a184aeb191"
+DEPENDS = "udev alsa-lib libusb dbus-glib"
+RDEPENDS_${PN}-dev = "bluez-hcidump"
+
+ASNEEDED = ""
+
+SRC_URI = "\
+ ${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.gz \
+"
+S = "${WORKDIR}/bluez-${PV}"
+
+inherit autotools
+
+EXTRA_OECONF = "\
+ --disable-gstreamer \
+ --enable-alsa \
+ --enable-usb \
+ --enable-tools \
+ --enable-bccmd \
+ --enable-hid2hci \
+ --enable-dfutool \
+ --enable-hidd \
+ --enable-pand \
+ --enable-dund \
+ --disable-cups \
+ --enable-test \
+ --enable-configfiles \
+"
+
diff --git a/meta/recipes-connectivity/bluez/bluez4_4.96.bb
b/meta/recipes-connectivity/bluez/bluez4_4.96.bb
index 994cec7..505e8f7 100644
--- a/meta/recipes-connectivity/bluez/bluez4_4.96.bb
+++ b/meta/recipes-connectivity/bluez/bluez4_4.96.bb
@@ -1,47 +1,12 @@
-SUMMARY = "Linux Bluetooth Stack Userland V4"
-DESCRIPTION = "Linux Bluetooth stack V4 userland components. These include a
system configurations, daemons, tools and system libraries."
-HOMEPAGE = "http://www.bluez.org";
-SECTION = "libs"
-LICENSE = "GPLv2+ & LGPLv2.1+"
-LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
-file://COPYING.LIB;md5=fb504b67c50331fc78734fed90fb0e09 \
-
file://src/main.c;beginline=1;endline=24;md5=9bc54b93cd7e17bf03f52513f39f926e \
-
file://sbc/sbc.c;beginline=1;endline=25;md5=1a40781ed30d50d8639323a184aeb191"
-DEPENDS = "udev gst-plugins-base alsa-lib libusb dbus-glib"
-RDEPENDS_${PN}-dev = "bluez-hcidump"
-
-ASNEEDED = ""
+require bluez4.inc
-PR = "r0"
+PR = "r1"
-SRC_URI = "\
- ${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.gz \
- file://bluetooth.conf \
-"
+SRC_URI += "file://bluetooth.conf"
SRC_URI[md5sum] = "296111afac49e3f9035085ac14daf518"
SRC_URI[sha256sum] =
"c06fd50fd77909cad55e3181a42c6bce7cfcf7abb8cd87871c13d0d70f87fa99"
-S = "${WORKDIR}/bluez-${PV}"
-
-inherit autotools
-
-EXTRA_OECONF = "\
- --enable-gstreamer \
- --enable-alsa \
- --enable-usb \
- --enable-tools \
- --enable-bccmd \
- --enable-hid2hci \
- --enable-dfutool \
- --enable-hidd \
- --enable-pand \
- --enable-dund \
- --disable-cups \
- --enable-test \
- --enable-configfiles \
-"
-
do_install_append() {
install -m 0644 ${S}/audio/audio.conf ${D}/${sysconfdir}/bluetooth/
install -m 0644 ${S}/network/network.conf ${D}/${sysconfdir}/bluetooth/
@@ -50,19 +15,19 @@ do_install_append() {
install -m 0644 ${WORKDIR}/bluetooth.conf
${D}/${sysconfdir}/dbus-1/system.d/
}
-PACKAGES =+ "gst-plugin-bluez libasound-module-bluez"
+RDEPENDS_${PN}-dev = "bluez-hcidump"
+
+PACKAGES =+ "libasound-module-bluez"
-FILES_gst-plugin-bluez = "${libdir}/gstreamer-0.10/lib*.so"
FILES_libasound-module-bluez = "${libdir}/alsa-lib/lib*.so ${datadir}/alsa"
FILES_${PN} += "${libdir}/bluetooth/plugins/*.so ${base_libdir}/udev/
${base_libdir}/systemd/"
FILES_${PN}-dev += "\
${libdir}/bluetooth/plugins/*.la \
${libdir}/alsa-lib/*.la \
- ${libdir}/gstreamer-0.10/*.la \
"
FILES_${PN}-dbg += "\
${libdir}/bluetooth/plugins/.debug \
${libdir}/*/.debug \
${base_libdir}/udev/.debug \
-"
+
diff --git a/meta/recipes-connectivity/bluez/gst-plugin-bluetooth_4.96.bb
b/meta/recipes-connectivity/bluez/gst-plugin-bluetooth_4.96.bb
new file mode 100644
index 000..a137b12
--- /dev/null
+++ b/meta/recipes-connectivity/bluez/gst-plugin-bluetooth_4.96.bb
@@ -0,0 +1,28 @@
+require bluez4.inc
+require recipes-multimedia/gstreamer/gst-plugins-package.inc
+
+DEPENDS = "bluez4 gst-pl
[OE-core] [PATCH 3/3] zypper: git repo moved to github
Signed-off-by: Anders Darander --- meta/recipes-extended/zypper/zypper_git.bb |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta/recipes-extended/zypper/zypper_git.bb b/meta/recipes-extended/zypper/zypper_git.bb index 299fcb5..7f7ceb3 100644 --- a/meta/recipes-extended/zypper/zypper_git.bb +++ b/meta/recipes-extended/zypper/zypper_git.bb @@ -11,7 +11,7 @@ SRCREV = "2c5bb6ceb99ecd950ef993e43d77bf0569ea0582" inherit cmake -SRC_URI = "git://gitorious.org/opensuse/zypper.git;protocol=git \ +SRC_URI = "git://github.com/openSUSE/zypper.git;protocol=git \ file://cmake.patch \ file://dso_linking_change_build_fix.patch \ file://rpm5-flag.patch \ -- 1.7.6.3 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] libzypp: git repo moved to github
Signed-off-by: Anders Darander
---
meta/recipes-extended/libzypp/libzypp_git.bb |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-extended/libzypp/libzypp_git.bb
b/meta/recipes-extended/libzypp/libzypp_git.bb
index aeae7df..4b1b8e4 100644
--- a/meta/recipes-extended/libzypp/libzypp_git.bb
+++ b/meta/recipes-extended/libzypp/libzypp_git.bb
@@ -16,7 +16,7 @@ SRCREV = "15b6c52260bbc52b3d8e585e271b67e10cc7c433"
PV = "0.0-git${SRCPV}"
PR = "r14"
-SRC_URI = "git://gitorious.org/opensuse/libzypp.git;protocol=git \
+SRC_URI = "git://github.com/openSUSE/libzypp.git;protocol=git \
file://no-doc.patch \
file://rpm5.patch \
file://rpm5-no-rpmdbinit.patch \
--
1.7.6.3
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] sat-solver: git repo moved to github
Signed-off-by: Anders Darander --- meta/recipes-extended/sat-solver/sat-solver_git.bb |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta/recipes-extended/sat-solver/sat-solver_git.bb b/meta/recipes-extended/sat-solver/sat-solver_git.bb index 9b212db..0d9a439 100644 --- a/meta/recipes-extended/sat-solver/sat-solver_git.bb +++ b/meta/recipes-extended/sat-solver/sat-solver_git.bb @@ -12,7 +12,7 @@ PR = "r11" PARALLEL_MAKE="" -SRC_URI = "git://gitorious.org/opensuse/sat-solver.git;protocol=git \ +SRC_URI = "git://github.com/openSUSE/sat-solver.git;protocol=git \ file://sat-solver_rpm5.patch \ file://sat-solver_obsolete.patch \ file://cmake.patch \ -- 1.7.6.3 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/3] [oe-core & yocto RC] Fix unfetchable zypp-related packages
openSUSE has moved several of it's projects from gitorious to github. Lately, these has become unfetchable from gitorius, thus the SRC_URI fixes are needed also for the upcoming yocto release. No other changes are included, SRCREV's are kept the same. The following changes since commit 81274f4488fbc4d68d150870735ec0181b60b451: freetype: disable bzip2 compressed font support (2011-09-19 13:14:03 +0100) are available in the git repository at: git://github.com/darander/oe-core opensuse-fixes https://github.com/darander/oe-core/tree/opensuse-fixes Anders Darander (3): libzypp: git repo moved to github sat-solver: git repo moved to github zypper: git repo moved to github meta/recipes-extended/libzypp/libzypp_git.bb |2 +- meta/recipes-extended/sat-solver/sat-solver_git.bb |2 +- meta/recipes-extended/zypper/zypper_git.bb |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) -- 1.7.6.3 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
