Various package/RRS updates
cover Various package/RRS updates
This week I've reviewed all the packages that have been last touched in 2013 or earlier (according to RRS) and this is the resulting patchset.
Since the feature freeze is happening soon, and there is still a large backlog of unmerged patches, I will stop the package version update at this point to avoid making the situation worse :) and will look into other things, perhaps these:
1) fixing gobject introspection
2) completing the work of porting matchbox stuff to gtk3 (or *gasp* looking into replacing it with the most minimal possible gnome 3 shell/launcher).
3) other suggestions?
The following changes since commit c80b582212336044c55052ad0d39f9da06d71438:
debianutils: create package for run-parts (2015-09-03 12:43:33 +0100)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib akanavin/package-version-updates
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/package-version-updates
Alexander Kanavin (12):
ccache: update to 3.2.3
mailx: update to 12.5-5
net-tools: update to 1.60-25
gnome-icon-theme: remove the recipe
libunique: remove the recipe
mkelfimage: add RECIPE_NO_UPDATE_REASON
python-async: update to 0.6.2
python-smmap: update to 0.9.0
remake: update to 4.1+dbg-1.1
uclibc: update PV to 0.9.33.2 to match latest upstream release
vte: add RECIPE_NO_UPDATE_REASON
package_regex.inc: various updates to improve RRS accuracy
meta/conf/distro/include/package_regex.inc | 14 +-
meta/recipes-core/uclibc/uclibc-git.inc | 2 +-
meta/recipes-devtools/ccache/ccache.inc | 4 +-
meta/recipes-devtools/ccache/ccache_3.1.11.bb | 7 -
meta/recipes-devtools/ccache/ccache_3.2.3.bb | 8 +
...ion-in-recent-change-related-to-zlib-in-n.patch | 73 ++++
meta/recipes-devtools/mkelfimage/mkelfimage_git.bb | 3 +
...python-async_0.6.1.bb => python-async_0.6.2.bb} | 4 +-
...python-smmap_0.8.2.bb => python-smmap_0.9.0.bb} | 4 +-
meta/recipes-devtools/remake/remake.inc | 4 +-
...ve-errors-about-colophon-and-cygnus-comma.patch | 39 --
.../{remake_git.bb => remake_4.1+dbg-1.1.bb} | 8 +-
...e-weak-symbol-optopt-to-fix-FTBFS-on-mips.patch | 59 +++
...-SSL2-support-since-it-is-no-longer-suppo.patch | 41 ++
...ntian-warning-warning-macro-N-not-defined.patch | 25 ++
.../0011-outof-Introduce-expandaddr-flag.patch | 70 ++++
...ble-option-processing-for-email-addresses.patch | 79 ++++
...c-Unconditionally-require-wordexp-support.patch | 113 ++++++
...4-globname-Invoke-wordexp-with-WRDE_NOCMD.patch | 30 ++
.../mailx/files/0015-usr-sbin-sendmail.patch | 38 ++
.../explicitly.disable.krb5.support.patch | 0
.../mailx/{mailx_12.5.bb => mailx_12.5-5.bb} | 21 +-
.../{net-tools_1.60-25.bb => net-tools_1.60-26.bb} | 6 +-
.../gnome/gnome-icon-theme/pkgconfig-native.patch | 28 --
.../recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb | 22 --
meta/recipes-gnome/libunique/libunique/build.patch | 421 ---------------------
.../libunique/fix_for_compile_with_gcc-4.6.0.patch | 36 --
.../libunique/libunique/noconst.patch | 130 -------
meta/recipes-gnome/libunique/libunique_1.1.6.bb | 25 --
meta/recipes-support/vte/vte_0.28.2.bb | 2 +
30 files changed, 579 insertions(+), 737 deletions(-)
delete mode 100644 meta/recipes-devtools/ccache/ccache_3.1.11.bb
create mode 100644 meta/recipes-devtools/ccache/ccache_3.2.3.bb
create mode 100644 meta/recipes-devtools/ccache/files/0001-Fix-regression-in-recent-change-related-to-zlib-in-n.patch
rename meta/recipes-devtools/python/{python-async_0.6.1.bb => python-async_0.6.2.bb} (77%)
rename meta/recipes-devtools/python/{python-smmap_0.8.2.bb => python-smmap_0.9.0.bb} (82%)
delete mode 100644 meta/recipes-devtools/remake/remake/remake-remove-errors-about-colophon-and-cygnus-comma.patch
rename meta/recipes-devtools/remake/{remake_git.bb => remake_4.1+dbg-1.1.bb} (80%)
create mode 100644 meta/recipes-extended/mailx/files/0001-Don-t-reuse-weak-symbol-optopt-to-fix-FTBFS-on-mips.patch
create mode 100644 meta/recipes-extended/mailx/files/0002-Patched-out-SSL2-support-since-it-is-no-longer-suppo.patch
create mode 100644 meta/recipes-extended/mailx/files/0003-Fixed-Lintian-warning-warning-macro-N-not-defined.patch
create mode 100644 meta/recipes-extended/mailx/files/0011-outof-Introduce-expandaddr-flag.patch
create mode 100644 meta/recipes-extended/mailx/files/0012-unpack-Disable-option-processing-for-email-addresses.patch
create mode 100644 meta/recipes-extended/mailx/files/0013-fio.c-Unconditionally-require-wordexp-support.patch
create mode 100644 meta/recipes-extended/mailx/files/0014-globname-Invoke-wordexp-with-WRDE_NOCMD.patch
create mode 100644 meta/recipes-extended/mailx/files/0015-usr-sbin-sendmail.patch
rename meta/recipes-extended/mailx/{mailx-12.5 => files}/explicitly.disable.krb5.support.patch (100%)
rename meta/recipes-extended/mailx/{mailx_12.5.bb => mailx_12.5-5.bb} (48%)
rename meta/recipes-extended/net-tools/{net-tools_1.60-25.bb => net-tools_1.60-26.bb} (91%)
delete mode 100644 meta/recipes-gnome/gnome/gnome-icon-theme/pkgconfig-native.patch
delete mode 100644 meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb
delete mode 100644 meta/recipes-gnome/libunique/libunique/build.patch
delete mode 100644 meta/recipes-gnome/libunique/libunique/fix_for_compile_with_gcc-4.6.0.patch
delete mode 100644 meta/recipes-gnome/libunique/libunique/noconst.patch
delete mode 100644 meta/recipes-gnome/libunique/libunique_1.1.6.bbSignature · 1 line
2.1.4
PATCH 1/12 ccache: update to 3.2.3
The LICENSE checksum has changed because of updated copyright years.
SRC_URI has been changed to git, because upstream tarball is broken (includes configure.ac but not .m4 files it depends on).
Add a backported patch that fixes builds with older versions of make and external zlib.
--- meta/recipes-devtools/ccache/ccache.inc | 4 +- meta/recipes-devtools/ccache/ccache_3.1.11.bb | 7 --- meta/recipes-devtools/ccache/ccache_3.2.3.bb | 8 +++ ...ion-in-recent-change-related-to-zlib-in-n.patch | 73 ++++++++++++++++++++++ 4 files changed, 84 insertions(+), 8 deletions(-) delete mode 100644 meta/recipes-devtools/ccache/ccache_3.1.11.bb create mode 100644 meta/recipes-devtools/ccache/ccache_3.2.3.bb create mode 100644 meta/recipes-devtools/ccache/files/0001-Fix-regression-in-recent-change-related-to-zlib-in-n.patch
meta/recipes-devtools/ccache/ccache.inc +3 -1
@@ -9,7 +9,9 @@ LICENSE = "GPLv3+" DEPENDS = "zlib" -SRC_URI = "http://samba.org/ftp/ccache/ccache-${PV}.tar.xz" +SRC_URI = "git://git.samba.org/ccache.git" + +S = "${WORKDIR}/git" inherit autotools
meta/recipes-devtools/ccache/ccache_3.1.11.bb deleted +0 -7
@@ -1,7 +0,0 @@ -require ccache.inc - -LICENSE = "GPLv3+" -LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=80e92ec45d4fca91f127864fb9e5d932" - -SRC_URI[md5sum] = "0f6df80c8941d9020a1fd5df5ad57dd7" -SRC_URI[sha256sum] = "60e9f3f1e60f528cfce910f3224bcc698029320f6ab77ec09a7b46bda2bc678e"
meta/recipes-devtools/ccache/ccache_3.2.3.bb new file +8 -0
@@ -0,0 +1,8 @@ +require ccache.inc + +LICENSE = "GPLv3+" +LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=b3c337e7664559a789d9f7a93e5283c1" + +SRCREV = "4cad46e8ee0053144bb00919f0dadd20c1f87013" + +SRC_URI += "file://0001-Fix-regression-in-recent-change-related-to-zlib-in-n.patch"
meta/recipes-devtools/ccache/files/0001-Fix-regression-in-recent-change-related-to-zlib-in-n.patch new file +73 -0
73 lines not on this page · raw message
Signature · 1 line
2.1.4
PATCH 2/12 mailx: update to 12.5-5
In reply to Alexander KanavinThis means adding new patches from Debian[1] and tweaking build options that were previously set by patching Makefile.
[1] ftp://ftp.debian.org/debian/pool/main/h/heirloom-mailx/
---
...e-weak-symbol-optopt-to-fix-FTBFS-on-mips.patch | 59 +++++++++++
...-SSL2-support-since-it-is-no-longer-suppo.patch | 41 ++++++++
...ntian-warning-warning-macro-N-not-defined.patch | 25 +++++
.../0011-outof-Introduce-expandaddr-flag.patch | 70 +++++++++++++
...ble-option-processing-for-email-addresses.patch | 79 ++++++++++++++
...c-Unconditionally-require-wordexp-support.patch | 113 +++++++++++++++++++++
...4-globname-Invoke-wordexp-with-WRDE_NOCMD.patch | 30 ++++++
.../mailx/files/0015-usr-sbin-sendmail.patch | 38 +++++++
.../explicitly.disable.krb5.support.patch | 0
.../mailx/{mailx_12.5.bb => mailx_12.5-5.bb} | 21 ++--
10 files changed, 469 insertions(+), 7 deletions(-)
create mode 100644 meta/recipes-extended/mailx/files/0001-Don-t-reuse-weak-symbol-optopt-to-fix-FTBFS-on-mips.patch
create mode 100644 meta/recipes-extended/mailx/files/0002-Patched-out-SSL2-support-since-it-is-no-longer-suppo.patch
create mode 100644 meta/recipes-extended/mailx/files/0003-Fixed-Lintian-warning-warning-macro-N-not-defined.patch
create mode 100644 meta/recipes-extended/mailx/files/0011-outof-Introduce-expandaddr-flag.patch
create mode 100644 meta/recipes-extended/mailx/files/0012-unpack-Disable-option-processing-for-email-addresses.patch
create mode 100644 meta/recipes-extended/mailx/files/0013-fio.c-Unconditionally-require-wordexp-support.patch
create mode 100644 meta/recipes-extended/mailx/files/0014-globname-Invoke-wordexp-with-WRDE_NOCMD.patch
create mode 100644 meta/recipes-extended/mailx/files/0015-usr-sbin-sendmail.patch
rename meta/recipes-extended/mailx/{mailx-12.5 => files}/explicitly.disable.krb5.support.patch (100%)
rename meta/recipes-extended/mailx/{mailx_12.5.bb => mailx_12.5-5.bb} (48%)meta/recipes-extended/mailx/files/0001-Don-t-reuse-weak-symbol-optopt-to-fix-FTBFS-on-mips.patch new file +59 -0
@@ -0,0 +1,59 @@ +From: Luk Claes <[email protected]> +Date: Sat, 4 Jul 2009 10:54:53 +0200 +Subject: Don't reuse weak symbol optopt to fix FTBFS on mips* + +This patch is taken from +ftp://ftp.debian.org/debian/pool/main/h/heirloom-mailx/heirloom-mailx_12.5-5.debian.tar.xz + +Upstream-status: Inappropriate [upstream is dead] +--- + getopt.c | 10 +++++----- + 1 file changed, 5 insertions(+), 5 deletions(-) + +diff --git a/getopt.c b/getopt.c +index 83ce628..82e983c 100644 +--- a/getopt.c ++++ b/getopt.c +@@ -43,7 +43,7 @@ typedef int ssize_t; + char *optarg; + int optind = 1; + int opterr = 1; +-int optopt; ++int optoptc; + + static void + error(const char *s, int c) +@@ -69,7 +69,7 @@ error(const char *s, int c) + *bp++ = *s++; + while (*msg) + *bp++ = *msg++; +- *bp++ = optopt; ++ *bp++ = optoptc; + *bp++ = '\n'; + write(2, buf, bp - buf); + ac_free(buf); +@@ -101,13 +101,13 @@ getopt(int argc, char *const argv[], const char *optstring) + } + curp = &argv[optind][1]; + } +- optopt = curp[0] & 0377; ++ optoptc = curp[0] & 0377; + while (optstring[0]) { + if (optstring[0] == ':') { + optstring++; + continue; + } +- if ((optstring[0] & 0377) == optopt) { ++ if ((optstring[0] & 0377) == optoptc) { + if (optstring[1] == ':') { + if (curp[1] != '\0') { + optarg = (char *)&curp[1]; +@@ -127,7 +127,7 @@ getopt(int argc, char *const argv[], const char *optstring) + optind++; + optarg = 0; + } +- return optopt; ++ return optoptc; + } + optstring++; + }
meta/recipes-extended/mailx/files/0002-Patched-out-SSL2-support-since-it-is-no-longer-suppo.patch new file +41 -0
41 lines not on this page · raw message
meta/recipes-extended/mailx/files/0003-Fixed-Lintian-warning-warning-macro-N-not-defined.patch new file +25 -0
@@ -0,0 +1,25 @@ +From: Hilko Bengen <[email protected]> +Date: Sat, 14 Apr 2012 20:22:43 +0200 +Subject: Fixed Lintian warning (warning: macro `N' not defined) + +This patch is taken from +ftp://ftp.debian.org/debian/pool/main/h/heirloom-mailx/heirloom-mailx_12.5-5.debian.tar.xz + +Upstream-status: Inappropriate [upstream is dead] +--- + mailx.1 | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/mailx.1 b/mailx.1 +index a02e430..b0723bd 100644 +--- a/mailx.1 ++++ b/mailx.1 +@@ -3781,7 +3781,7 @@ you could examine the first message by giving the command: + .sp + .fi + which might cause +-.N mailx ++.I mailx + to respond with, for example: + .nf + .sp
meta/recipes-extended/mailx/files/0011-outof-Introduce-expandaddr-flag.patch new file +70 -0
70 lines not on this page · raw message
meta/recipes-extended/mailx/files/0012-unpack-Disable-option-processing-for-email-addresses.patch new file +79 -0
79 lines not on this page · raw message
meta/recipes-extended/mailx/files/0013-fio.c-Unconditionally-require-wordexp-support.patch new file +113 -0
113 lines not on this page · raw message
meta/recipes-extended/mailx/files/0014-globname-Invoke-wordexp-with-WRDE_NOCMD.patch new file +30 -0
@@ -0,0 +1,30 @@ +From 73fefa0c1ac70043ec84f2d8b8f9f683213f168d Mon Sep 17 00:00:00 2001 +From: Florian Weimer <[email protected]> +Date: Mon, 17 Nov 2014 13:11:32 +0100 +Subject: [PATCH 4/4] globname: Invoke wordexp with WRDE_NOCMD (CVE-2004-2771) + +This patch is taken from +ftp://ftp.debian.org/debian/pool/main/h/heirloom-mailx/heirloom-mailx_12.5-5.debian.tar.xz + +Upstream-status: Inappropriate [upstream is dead] +--- + fio.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/fio.c b/fio.c +index 1529236..774a204 100644 +--- a/fio.c ++++ b/fio.c +@@ -497,7 +497,7 @@ globname(char *name) + sigemptyset(&nset); + sigaddset(&nset, SIGCHLD); + sigprocmask(SIG_BLOCK, &nset, NULL); +- i = wordexp(name, &we, 0); ++ i = wordexp(name, &we, WRDE_NOCMD); + sigprocmask(SIG_UNBLOCK, &nset, NULL); + switch (i) { + case 0: +-- +1.9.3 + +
meta/recipes-extended/mailx/files/0015-usr-sbin-sendmail.patch new file +38 -0
@@ -0,0 +1,38 @@ +Description: Sendmail is at /usr/sbin/sendmail + As per Debian Policy §11.6 +Author: Ryan Kavanagh <[email protected]> +Origin: Debian +Forwarded: no +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +Index: heirloom-mailx-12.5/Makefile +=================================================================== +This patch is taken from +ftp://ftp.debian.org/debian/pool/main/h/heirloom-mailx/heirloom-mailx_12.5-5.debian.tar.xz + +Upstream-status: Inappropriate [upstream is dead] + +--- heirloom-mailx-12.5.orig/Makefile 2011-04-26 17:23:22.000000000 -0400 ++++ heirloom-mailx-12.5/Makefile 2015-01-27 13:20:04.733542801 -0500 +@@ -13,7 +13,7 @@ + + MAILRC = $(SYSCONFDIR)/nail.rc + MAILSPOOL = /var/mail +-SENDMAIL = /usr/lib/sendmail ++SENDMAIL = /usr/sbin/sendmail + + DESTDIR = + +Index: heirloom-mailx-12.5/mailx.1 +=================================================================== +--- heirloom-mailx-12.5.orig/mailx.1 2015-01-27 13:18:49.000000000 -0500 ++++ heirloom-mailx-12.5/mailx.1 2015-01-27 13:20:32.382336867 -0500 +@@ -4922,7 +4922,7 @@ + which just acts as a proxy. + .PP + \fIMailx\fR immediately contacts the SMTP server (or +-.IR \%/usr/lib/sendmail ) ++.IR \%/usr/sbin/sendmail ) + even when operating in + .I disconnected + mode.
meta/recipes-extended/mailx/files/explicitly.disable.krb5.support.patch renamed from meta/recipes-extended/mailx/mailx-12.5/explicitly.disable.krb5.support.patch +0 -0
meta/recipes-extended/mailx/mailx_12.5-5.bb renamed from meta/recipes-extended/mailx/mailx_12.5.bb +14 -7
@@ -6,28 +6,35 @@ for MIME, IMAP, POP3, SMTP, and S/MIME." HOMEPAGE = "http://heirloom.sourceforge.net/mailx.html" SECTION = "console/network" -PR = "r2" LICENSE = "BSD & MPL-1" LIC_FILES_CHKSUM = "file://COPYING;md5=4202a0a62910cf94f7af8a3436a2a2dd" DEPENDS = "openssl" -SRC_URI = "https://launchpad.net/ubuntu/+archive/primary/+files/heirloom-mailx_12.5.orig.tar.gz;name=archive \ - https://launchpad.net/ubuntu/+archive/primary/+files/heirloom-mailx_12.5-1.diff.gz;name=patch \ +SRC_URI = "${DEBIAN_MIRROR}/main/h/heirloom-mailx/heirloom-mailx_12.5.orig.tar.gz;name=archive \ + file://0001-Don-t-reuse-weak-symbol-optopt-to-fix-FTBFS-on-mips.patch \ + file://0002-Patched-out-SSL2-support-since-it-is-no-longer-suppo.patch \ + file://0003-Fixed-Lintian-warning-warning-macro-N-not-defined.patch \ + file://0011-outof-Introduce-expandaddr-flag.patch \ + file://0012-unpack-Disable-option-processing-for-email-addresses.patch \ + file://0013-fio.c-Unconditionally-require-wordexp-support.patch \ + file://0014-globname-Invoke-wordexp-with-WRDE_NOCMD.patch \ + file://0015-usr-sbin-sendmail.patch \ file://explicitly.disable.krb5.support.patch \ " SRC_URI[archive.md5sum] = "29a6033ef1412824d02eb9d9213cb1f2" SRC_URI[archive.sha256sum] = "015ba4209135867f37a0245d22235a392b8bbed956913286b887c2e2a9a421ad" -SRC_URI[patch.md5sum] = "f466281336183be673bf136dd7096662" -SRC_URI[patch.sha256sum] = "aaf2a4bbf145e5ca9cdeb0843091ec8cc01df6c9568c997207a5e97b4dc5ba43" -S = "${WORKDIR}/heirloom-mailx-${PV}" +S = "${WORKDIR}/heirloom-mailx-12.5" inherit autotools-brokensep CFLAGS_append = " -D_BSD_SOURCE -DDEBIAN -I${S}/EXT" -EXTRA_OEMAKE = "SENDMAIL=${sbindir}/sendmail" + +# "STRIP=true" means that 'true' command will be used to 'strip' files which will achieve the effect of not stripping them +# mailx's Makefile doesn't allow a more straightforward way to avoid stripping +EXTRA_OEMAKE = "SENDMAIL=${sbindir}/sendmail IPv6=-DHAVE_IPv6_FUNCS PREFIX=/usr UCBINSTALL=/usr/bin/install STRIP=true" # The makeconfig can't run parallelly, otherwise the checking results # might be incorrect and lead to errors:
Signature · 1 line
2.1.4
PATCH 3/12 net-tools: update to 1.60-25
In reply to Alexander KanavinThis means fetching a newer Debian patchset which adds a few bug/security fixes.
---
.../net-tools/{net-tools_1.60-25.bb => net-tools_1.60-26.bb} | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
rename meta/recipes-extended/net-tools/{net-tools_1.60-25.bb => net-tools_1.60-26.bb} (91%)meta/recipes-extended/net-tools/net-tools_1.60-26.bb renamed from meta/recipes-extended/net-tools/net-tools_1.60-25.bb +3 -3
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b \ file://ifconfig.c;beginline=11;endline=15;md5=d1ca372080ad5401e23ca0afc35cf9ba" SRC_URI = "http://snapshot.debian.org/archive/debian/20050312T000000Z/pool/main/n/${BPN}/${BPN}_1.60.orig.tar.gz;name=tarball \ - http://snapshot.debian.org/archive/debian/20130511T214653Z/pool/main/n/${BPN}/${BPN}_${PV}.diff.gz;apply=no;name=patch \ + http://snapshot.debian.org/archive/debian//20150831T093342Z/pool/main/n/${BPN}/${BPN}_${PV}.diff.gz;apply=no;name=patch \ file://net-tools-config.h \ file://net-tools-config.make \ file://ifconfig-interface-0-del-IP-will-remove-the-aliased-.patch \
@@ -18,8 +18,8 @@ S = "${WORKDIR}/net-tools-1.60" SRC_URI[tarball.md5sum] = "ecaf37acb5b5daff4bdda77785fd916d" SRC_URI[tarball.sha256sum] = "ec67967cf7b1a3a3828a84762fbc013ac50ee5dc9aa3095d5c591f302c2de0f5" -SRC_URI[patch.md5sum] = "5ab1e2184d0fa6518031291138f2fc51" -SRC_URI[patch.sha256sum] = "1bddcd96ac60e794978cb20fb7ea4c2e77258c56c042c9ac8b6ec2b2033bc56f" +SRC_URI[patch.md5sum] = "ea3592f49ac8380962bc4d9b66c7e7e9" +SRC_URI[patch.sha256sum] = "aeeeafaff68866a446f01bb639d4e0146a60af34dcd20e31a3e46585022fc76c" inherit gettext
Signature · 1 line
2.1.4
PATCH 4/12 gnome-icon-theme: remove the recipe
In reply to Alexander KanavinIt is not used by anything in oe-core and will be moved to meta-gnome
--- .../gnome/gnome-icon-theme/pkgconfig-native.patch | 28 ---------------------- .../recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb | 22 ----------------- 2 files changed, 50 deletions(-) delete mode 100644 meta/recipes-gnome/gnome/gnome-icon-theme/pkgconfig-native.patch delete mode 100644 meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb
meta/recipes-gnome/gnome/gnome-icon-theme/pkgconfig-native.patch deleted +0 -28
@@ -1,28 +0,0 @@ -icon-naming-utils is a native dependency so we need to use the native pkg-config -to find it. Simply perform the old switcheroonie on $PKG_CONFIG so -pkg-config-native is used temporarily. - -Upstream-Status: Inappropriate (OE-specific) -Signed-off-by: Ross Burton <[email protected]> - -diff --git a/configure.ac b/configure.ac -index 6074f2c..3d38e49 100644 ---- a/configure.ac -+++ b/configure.ac -@@ -40,6 +40,8 @@ if test "x$enable_mapping" != "xno"; then - UTILS_REQUIRED=0.8.7 - - AC_MSG_CHECKING([icon-naming-utils >= $UTILS_REQUIRED]) -+ save_PKG_CONFIG=$PKG_CONFIG -+ PKG_CONFIG=pkg-config-native - PKG_CHECK_EXISTS(icon-naming-utils >= $UTILS_REQUIRED, - have_utils=yes, have_utils=no) - if test "x$have_utils" = "xyes"; then -@@ -51,6 +53,7 @@ if test "x$enable_mapping" != "xno"; then - AC_MSG_ERROR([icon-naming-utils >= $UTILS_REQUIRED is required to build - and install gnome-icon-theme]) - fi -+ PKG_CONFIG=save_PKG_CONFIG - else - ICONMAP="false" - fi
meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb deleted +0 -22
@@ -1,22 +0,0 @@ -SUMMARY = "GNOME 2 default icon themes" -HOMEPAGE = "http://www.gnome.org/" -BUGTRACKER = "https://bugzilla.gnome.org/" -SECTION = "x11/gnome" - -LICENSE = "LGPLv3+ | CC-BY-SA-3.0" -LIC_FILES_CHKSUM = "file://COPYING;md5=e7e289d90fc8bdceed5e3f142f98229e" - -PR = "r5" - -DEPENDS = "icon-naming-utils-native intltool-native libxml-simple-perl-native" - -inherit allarch autotools perlnative gtk-icon-cache pkgconfig gettext - -SRC_URI = "${GNOME_MIRROR}/${BPN}/2.31/${BPN}-${PV}.tar.bz2 \ - file://pkgconfig-native.patch" - -SRC_URI[md5sum] = "8e727703343d4c18c73c79dd2009f8ed" -SRC_URI[sha256sum] = "ea7e05b77ead159379392b3b275ca0c9cbacd7d936014e447cc7c5e27a767982" - -FILES_${PN} += "${datadir}/*" -RRECOMMENDS_${PN} += "librsvg-gtk"
Signature · 1 line
2.1.4
Re: [PATCH 04/12] gnome-icon-theme: remove the recipe
Quoted 2 lines · Alexander Kanavin
It is not used by anything in oe-core and will be moved to meta-gnome
I've a feeling that there are some apps in core-image-sato that actually like to have gnome-icon-theme installed (specifically I'm thinking pcmanfm). We should probably check that they work correctly without this installed (or more likely, show more icons when it is installed) before removing it.
Ross
Re: [PATCH 04/12] gnome-icon-theme: remove the recipe
Quoted 4 lines · Ross
On 3 September 2015 at 16:34, Alexander Kanavin <
[email protected]> wrote:
Quoted 9 lines
Quoted 2 lines
It is not used by anything in oe-core and will be moved to meta-gnome
I've a feeling that there are some apps in core-image-sato that actually like to have gnome-icon-theme installed (specifically I'm thinking pcmanfm). We should probably check that they work correctly without this installed (or more likely, show more icons when it is installed) before removing it.
Sounds like that's worth checking but I don't think that's related to Alexanders change: Even before Adwaita applications were supposed RRECOMMEND gnome-icon-theme if they needed it (not saying it's necessarily a good idea but that's how it used to work and still works). So if pcmanfm doesn't do that, it may be missing icons already and did so before adwaita as well (assuming nothing else in the image pulled in the icon theme).
I don't think it's likely but there is a chance that gnome-icon-theme contained icons that Adwaita does not provide (comparing them all turned out to be tricky). So double-checking how pcmanfm looks with Adwaita might make sense in any case.
Jussi
Re: [PATCH 04/12] gnome-icon-theme: remove the recipe
Quoted 4 lines · Jussi Kukkonen
I don't think it's likely but there is a chance that gnome-icon-theme contained icons that Adwaita does not provide (comparing them all turned out to be tricky). So double-checking how pcmanfm looks with Adwaita might make sense in any case.
I just did some tests and indeed pcmanfm looks bad when there is no icon theme at all, or when there is gnome-icon-theme, but looks ok with adwaita. So it needs a soft dependency on that, and gnome-icon-theme can still be dropped. If we find any other app that needs icons, then adwaita is the provider (which reminds me, I need to put the same dependency into epiphany recipe).
Alex
Re: [PATCH 04/12] gnome-icon-theme: remove the recipe
Quoted 7 lines · Alexander Kanavin
I just did some tests and indeed pcmanfm looks bad when there is no icon theme at all, or when there is gnome-icon-theme, but looks ok with adwaita. So it needs a soft dependency on that, and gnome-icon-theme can still be dropped. If we find any other app that needs icons, then adwaita is the provider (which reminds me, I need to put the same dependency into epiphany recipe).
Excellent, thanks.
Ross
Re: [PATCH 04/12] gnome-icon-theme: remove the recipe
In reply to Alexander KanavinQuoted 5 lines · Alexander Kanavin
It is not used by anything in oe-core and will be moved to meta-gnome
OK, please send the patch for meta-gnome as well. So we can merge them in more or less in sync
Quoted 78 lines
Signed-off-by Alexander Kanavin <[email protected]>---
.../gnome/gnome-icon-theme/pkgconfig-native.patch| 28 ---------------------- .../recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb | 22 -----------------2 files changed, 50 deletions(-)delete mode 100644
meta/recipes-gnome/gnome/gnome-icon-theme/pkgconfig-native.patchdelete mode 100644 meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bbmeta/recipes-gnome/gnome/gnome-icon-theme/pkgconfig-native.patch deleted +0
-28@@ -1,28 +0,0 @@ -icon-naming-utils is a native dependency so we need to use the native pkg-config -to find it. Simply perform the old switcheroonie on $PKG_CONFIG so -pkg-config-native is used temporarily. - -Upstream-Status: Inappropriate (OE-specific) -Signed-off-by: Ross Burton <[email protected]> - -diff --git a/configure.ac b/configure.ac -index 6074f2c..3d38e49 100644 ---- a/configure.ac -+++ b/configure.ac -@@ -40,6 +40,8 @@ if test "x$enable_mapping" != "xno"; then - UTILS_REQUIRED=0.8.7 - - AC_MSG_CHECKING([icon-naming-utils >= $UTILS_REQUIRED]) -+ save_PKG_CONFIG=$PKG_CONFIG -+ PKG_CONFIG=pkg-config-native - PKG_CHECK_EXISTS(icon-naming-utils >= $UTILS_REQUIRED, - have_utils=yes, have_utils=no) - if test "x$have_utils" = "xyes"; then -@@ -51,6 +53,7 @@ if test "x$enable_mapping" != "xno"; then - AC_MSG_ERROR([icon-naming-utils >= $UTILS_REQUIRED is required to build - and install gnome-icon-theme]) - fi -+ PKG_CONFIG=save_PKG_CONFIG - else - ICONMAP="false" - fimeta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb deleted +0
-23@@ -1,22 +0,0 @@ -SUMMARY = "GNOME 2 default icon themes" -HOMEPAGE = "http://www.gnome.org/" -BUGTRACKER = "https://bugzilla.gnome.org/" -SECTION = "x11/gnome" - -LICENSE = "LGPLv3+ | CC-BY-SA-3.0" -LIC_FILES_CHKSUM = "file://COPYING;md5=e7e289d90fc8bdceed5e3f142f98229e" - -PR = "r5" - -DEPENDS = "icon-naming-utils-native intltool-native libxml-simple-perl-native" - -inherit allarch autotools perlnative gtk-icon-cache pkgconfig gettext - -SRC_URI = "${GNOME_MIRROR}/${BPN}/2.31/${BPN}-${PV}.tar.bz2 \ - file://pkgconfig-native.patch" - -SRC_URI[md5sum] = "8e727703343d4c18c73c79dd2009f8ed" -SRC_URI[sha256sum] = "ea7e05b77ead159379392b3b275ca0c9cbacd7d936014e447cc7c5e27a767982" - -FILES_${PN} += "${datadir}/*" -RRECOMMENDS_${PN} += "librsvg-gtk" --2.1.4
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [PATCH 04/12] gnome-icon-theme: remove the recipe
Quoted 4 lines · Khem Raj
Quoted 2 lines
It is not used by anything in oe-core and will be moved to meta-gnome
OK, please send the patch for meta-gnome as well. So we can merge them in more or less in sync
I will send these patches only when oe-core is updated. Recipe moving is always controversial, and I don't want to cause confusion when the change is accepted by one side and rejected by the other.
Alex
Re: [PATCH 04/12] gnome-icon-theme: remove the recipe
Quoted 5 lines · Alexander Kanavin
On 09/04/2015 12:28 AM, Khem Raj wrote:
It is not used by anything in oe-core and will be moved to meta-gnome
Quoted 2 lines
Quoted 2 lines
Quoted 7 lines
Quoted 3 lines
OK, please send the patch for meta-gnome as well. So we can merge them in more or less in sync
I will send these patches only when oe-core is updated. Recipe moving is always controversial, and I don't want to cause confusion when the change is accepted by one side and rejected by the other.
On the contrary you can make a note in patch to destination layer citing the patch for source layer being a prerequisite to be accepted. Maintainers then can schedule it accordingly.
Quoted 4 lines
Alex
Re: [PATCH 04/12] gnome-icon-theme: remove the recipe
Quoted 8 lines · Khem Raj
I will send these patches only when oe-core is updated. Recipe moving is always controversial, and I don't want to cause confusion when the change is accepted by one side and rejected by the other.
On the contrary you can make a note in patch to destination layer citing the patch for source layer being a prerequisite to be accepted. Maintainers then can schedule it accordingly.
Martin, would you prefer this approach? My problem is that the gap between initial oe-core patch submission and their acceptance is often measured in weeks and sometimes months, so the corresponding meta-oe patches would be hanging in limbo, and may be easily forgotten.
Alex
Re: [PATCH 04/12] gnome-icon-theme: remove the recipe
Quoted 7 lines · Alexander Kanavin
Quoted 5 lines · Khem Raj
I will send these patches only when oe-core is updated. Recipe moving is always controversial, and I don't want to cause confusion when the change is accepted by one side and rejected by the other.
Quoted 5 lines
Quoted 3 lines
On the contrary you can make a note in patch to destination layer citing the patch for source layer being a prerequisite to be accepted. Maintainers then can schedule it accordingly.
Martin, would you prefer this approach? My problem is that the gap
yes
Quoted 3 lines
between initial oe-core patch submission and their acceptance is often measured in weeks and sometimes months, so the corresponding meta-oe patches would be hanging in limbo, and may be easily forgotten.
I shouldn't forget them, because they will sit in patchwork's queue or alternatively I'll cherry-pick the removal to my oe-core's jansa/master together with these changes in meta-oe's jansa/master branches so I'll build-test them in my Jenkins builds until it's merged in oe-core.
It's a bit error prone, but the delay will be shorter if we do it this way.
Full jenkins build test takes over 3 days (depending on sstate reuse, one MACHINE can take more than 24 hours), so if I add them to master-next after it's merged to oe-core it will take 3-6 days to build-test them (6 days if they are sent just after current queue is sent for build).
Regards,
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
World builds HW Was: [PATCH 04/12] gnome-icon-theme: remove the recipe
Quoted 8 lines · Randy MacLeod
Quoted 5 lines · Martin Jansa
Full jenkins build test takes over 3 days (depending on sstate reuse, one MACHINE can take more than 24 hours), so if I add them to master-next after it's merged to oe-core it will take 3-6 days to build-test them (6 days if they are sent just after current queue is sent for build).
Hi Martin,
Hi Randy,
Quoted 2 lines
Replying privately but you can add the list back in your reply if you like.
OK, adding both MLs
Quoted 5 lines
I never build all of meta-oe but a day seems like a long time. On a 3-4 year old 24 core system, with 64 GB RAM and
2 large disks, I build oe-core + a whitelist of meta-oe + misc layers in 5 hours using 18.3 of the 24 cores on average.
What are the specs of your build machine?
It's one of VMs running on box donated by HP to webos-ports project. It has access to 8 E5-2630L 0 @ 2.00GHz cores (from IIRC 24) and slow IO which we try to compensate a bit by using tmpfs for TMPDIR, VM has 80G RAM, so I'm using 72G for tmpfs.
Tom: please fill-in the gaps, I don't know any details about the real HW it's running on.
The same machine is also running some webos-ports builds sometimes.
BUT be aware that my world build is much bigger than what you're probably building and changes in oe-core almost always ensure very low sstate reuse.
e.g. last build with only small oe-core upgrade since previous build:
NOTE: Tasks Summary: Attempted 33283 tasks of which 5252 didn't need to be rerun and 33 failed. NOTE: Build completion summary: NOTE: do_populate_sysroot: 21% sstate reuse (485 setscene, 1750 scratch) NOTE: do_package_qa: 12% sstate reuse (262 setscene, 1760 scratch) NOTE: do_package: 4% sstate reuse (76 setscene, 1750 scratch) NOTE: do_packagedata: 13% sstate reuse (281 setscene, 1750 scratch) NOTE: do_package_write_ipk: 12% sstate reuse (262 setscene, 1756 scratch) NOTE: do_populate_lic: 22% sstate reuse (521 setscene, 1806 scratch)
real 1485m40.070s
user 4166m49.125s
sys 2825m50.068s
BTW: you can see all this information in the world logs I'm sending to MLs (but not all the builds make it to ML report).
Quoted 4 lines
A decent build box these days has 32+ cores, 64+ GB RAM and and SSD or RAID disk filesystem. The costs of such a system are significant but worth it given the number of people's time involved in meta-oe.
That's true, but I have to do with what I have available :).
Quoted 3 lines
Also, it would be nice if OE had a few such machines each working on builds for a MACHINE to reduce your turn-around to more like a day or so. :)
Yes, it would be nice, I'm trying to get Tom King to set another VM like this in another location (another HP donated server), hopefully he will finish it soon.
It's all hosted together with OE infrastructure, bandwidth is limited, but all I need for these builds is to fetch sources and upload the logs, there are no package feeds or sstate from these builds usable outside, but now it rsync the downloaded sources to sources.openembedded.org
If you know about some idling build servers, I would like to give them something to do :).
Regards,
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Re: World builds HW Was: [PATCH 04/12] gnome-icon-theme: remove the recipe
Quoted 38 lines · Martin Jansa
Quoted 8 lines · Randy MacLeod
Quoted 5 lines · Martin Jansa
Full jenkins build test takes over 3 days (depending on sstate reuse, one MACHINE can take more than 24 hours), so if I add them to master-next after it's merged to oe-core it will take 3-6 days to build-test them (6 days if they are sent just after current queue is sent for build).
Hi Martin,
Hi Randy,
Quoted 2 lines
Replying privately but you can add the list back in your reply if you like.
OK, adding both MLs
Quoted 5 lines
I never build all of meta-oe but a day seems like a long time. On a 3-4 year old 24 core system, with 64 GB RAM and
2 large disks, I build oe-core + a whitelist of meta-oe + misc layers in 5 hours using 18.3 of the 24 cores on average.
What are the specs of your build machine?It's one of VMs running on box donated by HP to webos-ports project. It has access to 8 E5-2630L 0 @ 2.00GHz cores (from IIRC 24) and slow IO which we try to compensate a bit by using tmpfs for TMPDIR, VM has 80G RAM, so I'm using 72G for tmpfs.
Tom: please fill-in the gaps, I don't know any details about the real HW it's running on.
The same machine is also running some webos-ports builds sometimes.
BUT be aware that my world build is much bigger than what you're probably building and changes in oe-core almost always ensure very low sstate reuse.
e.g. last build with only small oe-core upgrade since previous build:
Quoted 8 lines
NOTE: Tasks Summary: Attempted 33283 tasks of which 5252 didn't need to be rerun and 33 failed. NOTE: Build completion summary: NOTE: do_populate_sysroot: 21% sstate reuse (485 setscene, 1750 scratch) NOTE: do_package_qa: 12% sstate reuse (262 setscene, 1760 scratch) NOTE: do_package: 4% sstate reuse (76 setscene, 1750 scratch) NOTE: do_packagedata: 13% sstate reuse (281 setscene, 1750 scratch) NOTE: do_package_write_ipk: 12% sstate reuse (262 setscene, 1756 scratch) NOTE: do_populate_lic: 22% sstate reuse (521 setscene, 1806 scratch)
(slightly off topic): How did you get this report?
Quoted 35 lines
real 1485m40.070s
user 4166m49.125s
sys 2825m50.068sBTW: you can see all this information in the world logs I'm sending to MLs (but not all the builds make it to ML report).
Quoted 4 lines
A decent build box these days has 32+ cores, 64+ GB RAM and and SSD or RAID disk filesystem. The costs of such a system are significant but worth it given the number of people's time involved in meta-oe.
That's true, but I have to do with what I have available :).
Quoted 3 lines
Also, it would be nice if OE had a few such machines each working on builds for a MACHINE to reduce your turn-around to more like a day or so. :)
Yes, it would be nice, I'm trying to get Tom King to set another VM like this in another location (another HP donated server), hopefully he will finish it soon.
It's all hosted together with OE infrastructure, bandwidth is limited, but all I need for these builds is to fetch sources and upload the logs, there are no package feeds or sstate from these builds usable outside, but now it rsync the downloaded sources to sources.openembedded.org
If you know about some idling build servers, I would like to give them something to do :).
Regards,
Signature · 4 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------
Re: World builds HW Was: [PATCH 04/12] gnome-icon-theme: remove the recipe
Quoted 48 lines · Gary Thomas
Quoted 38 lines · Martin Jansa
Quoted 8 lines · Randy MacLeod
Quoted 5 lines · Martin Jansa
Full jenkins build test takes over 3 days (depending on sstate reuse, one MACHINE can take more than 24 hours), so if I add them to master-next after it's merged to oe-core it will take 3-6 days to build-test them (6 days if they are sent just after current queue is sent for build).
Hi Martin,
Hi Randy,
Quoted 2 lines
Replying privately but you can add the list back in your reply if you like.
OK, adding both MLs
Quoted 5 lines
I never build all of meta-oe but a day seems like a long time. On a 3-4 year old 24 core system, with 64 GB RAM and
2 large disks, I build oe-core + a whitelist of meta-oe + misc layers in 5 hours using 18.3 of the 24 cores on average.
What are the specs of your build machine?It's one of VMs running on box donated by HP to webos-ports project. It has access to 8 E5-2630L 0 @ 2.00GHz cores (from IIRC 24) and slow IO which we try to compensate a bit by using tmpfs for TMPDIR, VM has 80G RAM, so I'm using 72G for tmpfs.
Tom: please fill-in the gaps, I don't know any details about the real HW it's running on.
The same machine is also running some webos-ports builds sometimes.
BUT be aware that my world build is much bigger than what you're probably building and changes in oe-core almost always ensure very low sstate reuse.
e.g. last build with only small oe-core upgrade since previous build:
Quoted 8 lines
NOTE: Tasks Summary: Attempted 33283 tasks of which 5252 didn't need to be rerun and 33 failed. NOTE: Build completion summary: NOTE: do_populate_sysroot: 21% sstate reuse (485 setscene, 1750 scratch) NOTE: do_package_qa: 12% sstate reuse (262 setscene, 1760 scratch) NOTE: do_package: 4% sstate reuse (76 setscene, 1750 scratch) NOTE: do_packagedata: 13% sstate reuse (281 setscene, 1750 scratch) NOTE: do_package_write_ipk: 12% sstate reuse (262 setscene, 1756 scratch) NOTE: do_populate_lic: 22% sstate reuse (521 setscene, 1806 scratch)
Quoted 1 line
(slightly off topic): How did you get this report?
inherit buildstats-summary
Quoted 45 lines
Quoted 34 lines
real 1485m40.070s
user 4166m49.125s
sys 2825m50.068sBTW: you can see all this information in the world logs I'm sending to MLs (but not all the builds make it to ML report).
Quoted 4 lines
A decent build box these days has 32+ cores, 64+ GB RAM and and SSD or RAID disk filesystem. The costs of such a system are significant but worth it given the number of people's time involved in meta-oe.
That's true, but I have to do with what I have available :).
Quoted 3 lines
Also, it would be nice if OE had a few such machines each working on builds for a MACHINE to reduce your turn-around to more like a day or so. :)
Yes, it would be nice, I'm trying to get Tom King to set another VM like this in another location (another HP donated server), hopefully he will finish it soon.
It's all hosted together with OE infrastructure, bandwidth is limited, but all I need for these builds is to fetch sources and upload the logs, there are no package feeds or sstate from these builds usable outside, but now it rsync the downloaded sources to sources.openembedded.org
If you know about some idling build servers, I would like to give them something to do :).
Regards,
Signature · 9 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Re: World builds HW Was: [PATCH 04/12] gnome-icon-theme: remove the recipe
In reply to Martin JansaMartin, Randy et.al.:
I'm moving around things such that I can give Martin a full builder:
24Cores, 256GB RAM, up to 3TB storage from the donation that HP made to WebOS-Ports (as I consider it essential to webOS-Ports that OE has a strong foundation)
Tom
Quoted 83 lines · Martin Jansa
Quoted 8 lines · Randy MacLeod
Quoted 5 lines · Martin Jansa
Full jenkins build test takes over 3 days (depending on sstate reuse, one MACHINE can take more than 24 hours), so if I add them to master-next after it's merged to oe-core it will take 3-6 days to build-test them (6 days if they are sent just after current queue is sent for build).
Hi Martin,
Hi Randy,
Quoted 2 lines
Replying privately but you can add the list back in your reply if you like.
OK, adding both MLs
Quoted 5 lines
I never build all of meta-oe but a day seems like a long time. On a 3-4 year old 24 core system, with 64 GB RAM and
2 large disks, I build oe-core + a whitelist of meta-oe + misc layers in 5 hours using 18.3 of the 24 cores on average.
What are the specs of your build machine?It's one of VMs running on box donated by HP to webos-ports project. It has access to 8 E5-2630L 0 @ 2.00GHz cores (from IIRC 24) and slow IO which we try to compensate a bit by using tmpfs for TMPDIR, VM has 80G RAM, so I'm using 72G for tmpfs.
Tom: please fill-in the gaps, I don't know any details about the real HW it's running on.
The same machine is also running some webos-ports builds sometimes.
BUT be aware that my world build is much bigger than what you're probably building and changes in oe-core almost always ensure very low sstate reuse.
e.g. last build with only small oe-core upgrade since previous build:
NOTE: Tasks Summary: Attempted 33283 tasks of which 5252 didn't need to be rerun and 33 failed.NOTE: Build completion summary: NOTE: do_populate_sysroot: 21% sstate reuse (485 setscene, 1750 scratch) NOTE: do_package_qa: 12% sstate reuse (262 setscene, 1760 scratch) NOTE: do_package: 4% sstate reuse (76 setscene, 1750 scratch) NOTE: do_packagedata: 13% sstate reuse (281 setscene, 1750 scratch) NOTE: do_package_write_ipk: 12% sstate reuse (262 setscene, 1756 scratch) NOTE: do_populate_lic: 22% sstate reuse (521 setscene, 1806 scratch)real 1485m40.070s user 4166m49.125s sys 2825m50.068sBTW: you can see all this information in the world logs I'm sending to MLs (but not all the builds make it to ML report).
Quoted 4 lines
A decent build box these days has 32+ cores, 64+ GB RAM and and SSD or RAID disk filesystem. The costs of such a system are significant but worth it given the number of people's time involved in meta-oe.
That's true, but I have to do with what I have available :).
Quoted 3 lines
Also, it would be nice if OE had a few such machines each working on builds for a MACHINE to reduce your turn-around to more like a day or so. :)
Yes, it would be nice, I'm trying to get Tom King to set another VM like this in another location (another HP donated server), hopefully he will finish it soon.
It's all hosted together with OE infrastructure, bandwidth is limited, but all I need for these builds is to fetch sources and upload the logs, there are no package feeds or sstate from these builds usable outside, but now it rsync the downloaded sources to sources.openembedded.org
If you know about some idling build servers, I would like to give them something to do :).
Regards,
--
Martin 'JaMa' Jansa jabber: [email protected]
Re: World builds HW Was: [PATCH 04/12] gnome-icon-theme: remove the recipe
Quoted 9 lines · Tom King
Martin, Randy et.al <http://et.al>.:
I'm moving around things such that I can give Martin a full builder:
24Cores, 256GB RAM, up to 3TB storage from the donation that HP made to WebOS-Ports (as I consider it essential to webOS-Ports that OE has a strong foundation)
Tom
Thanks Tom.
I'm back from vacation, cleaning up old emails.
Did the upgrade help Martin?
Do you need additional systems?
../Randy
Quoted 99 lines
On Fri, Sep 18, 2015 at 10:30 AM, Martin Jansa <[email protected] <mailto:[email protected]>> wrote:
On Fri, Sep 18, 2015 at 12:24:00PM -0400, Randy MacLeod wrote:
> On 2015-09-07 11:14 AM, Martin Jansa wrote:
> > Full jenkins build test takes over 3 days (depending on sstate
reuse,
> > one MACHINE can take more than 24 hours), so if I add them to > > master-next after it's merged to oe-core it will take 3-6 days to > > build-test them (6 days if they are sent just after current
queue is
> > sent for build).
>
> Hi Martin,Hi Randy,
> Replying privately but you can add the list back in your > reply if you like.
OK, adding both MLs
> I never build all of meta-oe but a day seems like a long time. > On a 3-4 year old 24 core system, with 64 GB RAM and > 2 large disks, I build oe-core + a whitelist of meta-oe + misc
layers in
> 5 hours using 18.3 of the 24 cores on average.
> What are the specs of your build machine?It's one of VMs running on box donated by HP to webos-ports project. It has access to 8 E5-2630L 0 @ 2.00GHz cores (from IIRC 24) and slow IO which we try to compensate a bit by using tmpfs for TMPDIR, VM has 80G RAM, so I'm using 72G for tmpfs.
Tom: please fill-in the gaps, I don't know any details about the real HW it's running on.
The same machine is also running some webos-ports builds sometimes.
BUT be aware that my world build is much bigger than what you're probably building and changes in oe-core almost always ensure very low sstate reuse.
e.g. last build with only small oe-core upgrade since previous build:
NOTE: Tasks Summary: Attempted 33283 tasks of which 5252 didn't need to be rerun and 33 failed.
NOTE: Build completion summary:
NOTE:do_populate_sysroot: 21% sstate reuse (485 setscene, 1750
scratch)
NOTE:do_package_qa: 12% sstate reuse (262 setscene, 1760 scratch)
NOTE:do_package: 4% sstate reuse (76 setscene, 1750 scratch)
NOTE:do_packagedata: 13% sstate reuse (281 setscene, 1750 scratch)
NOTE:do_package_write_ipk: 12% sstate reuse (262 setscene, 1756
scratch)
NOTE:do_populate_lic: 22% sstate reuse (521 setscene, 1806 scratch)real 1485m40.070s
user 4166m49.125s
sys 2825m50.068sBTW: you can see all this information in the world logs I'm sending to MLs
(but not all the builds make it to ML report).> A decent build box these days has 32+ cores, 64+ GB RAM and > and SSD or RAID disk filesystem. The costs of such a system > are significant but worth it given the number of people's time > involved in meta-oe.
That's true, but I have to do with what I have available :).
> Also, it would be nice if OE had a few such machines each > working on builds for a MACHINE to reduce your turn-around > to more like a day or so. :)
Yes, it would be nice, I'm trying to get Tom King to set another VM like this in another location (another HP donated server), hopefully he will finish it soon.
It's all hosted together with OE infrastructure, bandwidth is limited, but
all I need for these builds is to fetch sources and upload the logs, there
are no package feeds or sstate from these builds usable outside, but now it
rsync the downloaded sources to sources.openembedded.org
<http://sources.openembedded.org>If you know about some idling build servers, I would like to give them something to do :).
Regards,
--
Martin 'JaMa' Jansa jabber: [email protected]
<mailto:[email protected]>
Signature · 2 lines
# Randy MacLeod. SMTS, Linux, Wind River Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada, K2K 2W5
Re: World builds HW Was: [PATCH 04/12] gnome-icon-theme: remove the recipe
Quoted 9 lines · Randy MacLeod
Quoted 8 lines · Tom King
Martin, Randy et.al <http://et.al>.:
I'm moving around things such that I can give Martin a full builder:
24Cores, 256GB RAM, up to 3TB storage from the donation that HP made to WebOS-Ports (as I consider it essential to webOS-Ports that OE has a strong foundation)
Quoted 6 lines
Quoted 1 line
Tom
Thanks Tom.
I'm back from vacation, cleaning up old emails.Did the upgrade help Martin?
I'm still waiting for access to that server.
Quoted 1 line
Do you need additional systems?
More builders are always welcome. In ideal case I would trigger all 3 architectures in parallel on different builders.
Quoted 106 lines
../Randy
Quoted 99 lines
On Fri, Sep 18, 2015 at 10:30 AM, Martin Jansa <[email protected] <mailto:[email protected]>> wrote:
On Fri, Sep 18, 2015 at 12:24:00PM -0400, Randy MacLeod wrote:
> On 2015-09-07 11:14 AM, Martin Jansa wrote:
> > Full jenkins build test takes over 3 days (depending on sstate
reuse,
> > one MACHINE can take more than 24 hours), so if I add them to > > master-next after it's merged to oe-core it will take 3-6 days to > > build-test them (6 days if they are sent just after current
queue is
> > sent for build).
>
> Hi Martin,Hi Randy,
> Replying privately but you can add the list back in your > reply if you like.
OK, adding both MLs
> I never build all of meta-oe but a day seems like a long time. > On a 3-4 year old 24 core system, with 64 GB RAM and > 2 large disks, I build oe-core + a whitelist of meta-oe + misc
layers in
> 5 hours using 18.3 of the 24 cores on average.
> What are the specs of your build machine?It's one of VMs running on box donated by HP to webos-ports project. It has access to 8 E5-2630L 0 @ 2.00GHz cores (from IIRC 24) and slow IO which we try to compensate a bit by using tmpfs for TMPDIR, VM has 80G RAM, so I'm using 72G for tmpfs.
Tom: please fill-in the gaps, I don't know any details about the real HW it's running on.
The same machine is also running some webos-ports builds sometimes.
BUT be aware that my world build is much bigger than what you're probably building and changes in oe-core almost always ensure very low sstate reuse.
e.g. last build with only small oe-core upgrade since previous build:
NOTE: Tasks Summary: Attempted 33283 tasks of which 5252 didn't need to be rerun and 33 failed.
NOTE: Build completion summary:
NOTE:do_populate_sysroot: 21% sstate reuse (485 setscene, 1750
scratch)
NOTE:do_package_qa: 12% sstate reuse (262 setscene, 1760 scratch)
NOTE:do_package: 4% sstate reuse (76 setscene, 1750 scratch)
NOTE:do_packagedata: 13% sstate reuse (281 setscene, 1750 scratch)
NOTE:do_package_write_ipk: 12% sstate reuse (262 setscene, 1756
scratch)
NOTE:do_populate_lic: 22% sstate reuse (521 setscene, 1806 scratch)real 1485m40.070s
user 4166m49.125s
sys 2825m50.068sBTW: you can see all this information in the world logs I'm sending to MLs
(but not all the builds make it to ML report).> A decent build box these days has 32+ cores, 64+ GB RAM and > and SSD or RAID disk filesystem. The costs of such a system > are significant but worth it given the number of people's time > involved in meta-oe.
That's true, but I have to do with what I have available :).
> Also, it would be nice if OE had a few such machines each > working on builds for a MACHINE to reduce your turn-around > to more like a day or so. :)
Yes, it would be nice, I'm trying to get Tom King to set another VM like this in another location (another HP donated server), hopefully he will finish it soon.
It's all hosted together with OE infrastructure, bandwidth is limited, but
all I need for these builds is to fetch sources and upload the logs, there
are no package feeds or sstate from these builds usable outside, but now it
rsync the downloaded sources to sources.openembedded.org
<http://sources.openembedded.org>If you know about some idling build servers, I would like to give them something to do :).
Regards,
--
Martin 'JaMa' Jansa jabber: [email protected]
<mailto:[email protected]>Signature · 3 lines
# Randy MacLeod. SMTS, Linux, Wind River Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada, K2K 2W5
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
PATCH 5/12 libunique: remove the recipe
In reply to Alexander KanavinIt is not used by anything in oe-core and will be moved to meta-oe
--- meta/recipes-gnome/libunique/libunique/build.patch | 421 --------------------- .../libunique/fix_for_compile_with_gcc-4.6.0.patch | 36 -- .../libunique/libunique/noconst.patch | 130 ------- meta/recipes-gnome/libunique/libunique_1.1.6.bb | 25 -- 4 files changed, 612 deletions(-) delete mode 100644 meta/recipes-gnome/libunique/libunique/build.patch delete mode 100644 meta/recipes-gnome/libunique/libunique/fix_for_compile_with_gcc-4.6.0.patch delete mode 100644 meta/recipes-gnome/libunique/libunique/noconst.patch delete mode 100644 meta/recipes-gnome/libunique/libunique_1.1.6.bb
meta/recipes-gnome/libunique/libunique/build.patch deleted +0 -421
@@ -1,421 +0,0 @@ -Upstream-Status: Backport [http://git.gnome.org/browse/unique/commit/?h=unique-1.1&id=f75ca2d7aad7d27686acca6090c1c569a79d7e63] -Signed-off-By: Ross Burton <[email protected]> - -From f75ca2d7aad7d27686acca6090c1c569a79d7e63 Mon Sep 17 00:00:00 2001 -From: Emmanuele Bassi <[email protected]> -Date: Sat, 08 May 2010 11:17:21 +0000 -Subject: build: Update the build environment - -Require autoconf 2.63, automake 1.11 and libtool 2.2.6 to remove Shave. - -Also bump up the requirement for gobject-introspection to 0.6.7. ---- -diff --git a/build/autotools/Makefile.am b/build/autotools/Makefile.am -index 5f35b85..b78428f 100644 ---- a/build/autotools/Makefile.am -+++ b/build/autotools/Makefile.am -@@ -1,7 +1,4 @@ - EXTRA_DIST = \ -- shave-libtool.in \ -- shave.in \ -- shave.m4 \ - as-compiler-flag.m4 \ - introspection.m4 \ - Makefile.am.enums \ -diff --git a/build/autotools/Makefile.am.silent b/build/autotools/Makefile.am.silent -index 249f6af..8576846 100644 ---- a/build/autotools/Makefile.am.silent -+++ b/build/autotools/Makefile.am.silent -@@ -1,10 +1,5 @@ - # custom rules for quiet builds - --if USE_SHAVE --QUIET_GEN = $(Q:@=@echo ' GEN '$@;) --QUIET_LN = $(Q:@=@echo ' LN '$@;) --QUIET_RM = $(Q:@=@echo ' RM '$@;) --else - QUIET_GEN = $(AM_V_GEN) - - QUIET_LN = $(QUIET_LN_$(V)) -@@ -14,4 +9,3 @@ QUIET_LN_0 = @echo ' LN '$@; - QUIET_RM = $(QUIET_RM_$(V)) - QUIET_RM_ = $(QUIET_RM_$(AM_DEFAULT_VERBOSITY)) - QUIET_RM_0 = @echo ' RM '$@; --endif # USE_SHAVE -diff --git a/build/autotools/introspection.m4 b/build/autotools/introspection.m4 -index f9ce49c..589721c 100644 ---- a/build/autotools/introspection.m4 -+++ b/build/autotools/introspection.m4 -@@ -59,12 +59,18 @@ m4_define([_GOBJECT_INTROSPECTION_CHECK_INTERNAL], - INTROSPECTION_GENERATE=`$PKG_CONFIG --variable=g_ir_generate gobject-introspection-1.0` - INTROSPECTION_GIRDIR=`$PKG_CONFIG --variable=girdir gobject-introspection-1.0` - INTROSPECTION_TYPELIBDIR="$($PKG_CONFIG --variable=typelibdir gobject-introspection-1.0)" -+ INTROSPECTION_CFLAGS=`$PKG_CONFIG --cflags gobject-introspection-1.0` -+ INTROSPECTION_LIBS=`$PKG_CONFIG --libs gobject-introspection-1.0` -+ INTROSPECTION_MAKEFILE=`$PKG_CONFIG --variable=datadir gobject-introspection-1.0`/gobject-introspection-1.0/Makefile.introspection - fi - AC_SUBST(INTROSPECTION_SCANNER) - AC_SUBST(INTROSPECTION_COMPILER) - AC_SUBST(INTROSPECTION_GENERATE) - AC_SUBST(INTROSPECTION_GIRDIR) - AC_SUBST(INTROSPECTION_TYPELIBDIR) -+ AC_SUBST(INTROSPECTION_CFLAGS) -+ AC_SUBST(INTROSPECTION_LIBS) -+ AC_SUBST(INTROSPECTION_MAKEFILE) - - AM_CONDITIONAL(HAVE_INTROSPECTION, test "x$found_introspection" = "xyes") - ]) -diff --git a/build/autotools/shave-libtool.in b/build/autotools/shave-libtool.in -deleted file mode 100644 -index 1f3a720..0000000 ---- a/build/autotools/shave-libtool.in -+++ b/dev/null -@@ -1,69 +0,0 @@ --#!/bin/sh -- --# we need sed --SED=@SED@ --if test -z "$SED" ; then --SED=sed --fi -- --lt_unmangle () --{ -- last_result=`echo $1 | $SED -e 's#.libs/##' -e 's#[0-9a-zA-Z_\-\.]*_la-##'` --} -- --# the real libtool to use --LIBTOOL="$1" --shift -- --# if 1, don't print anything, the underlaying wrapper will do it --pass_though=0 -- --# scan the arguments, keep the right ones for libtool, and discover the mode --preserved_args= --while test "$#" -gt 0; do -- opt="$1" -- shift -- -- case $opt in -- --mode=*) -- mode=`echo $opt | $SED -e 's/[-_a-zA-Z0-9]*=//'` -- preserved_args="$preserved_args $opt" -- ;; -- -o) -- lt_output="$1" -- preserved_args="$preserved_args $opt" -- ;; -- *) -- preserved_args="$preserved_args $opt" -- ;; -- esac --done -- --case "$mode" in --compile) -- # shave will be called and print the actual CC/CXX/LINK line -- preserved_args="$preserved_args --shave-mode=$mode" -- pass_though=1 -- ;; --link) -- preserved_args="$preserved_args --shave-mode=$mode" -- Q=" LINK " -- ;; --*) -- # let's u -- # echo "*** libtool: Unimplemented mode: $mode, fill a bug report" -- ;; --esac -- --lt_unmangle "$lt_output" --output=$last_result -- --if test -z $V; then -- if test $pass_though -eq 0; then -- echo "$Q$output" -- fi -- $LIBTOOL --silent $preserved_args --else -- echo $LIBTOOL $preserved_args -- $LIBTOOL $preserved_args --fi -diff --git a/build/autotools/shave.in b/build/autotools/shave.in -deleted file mode 100644 -index 5c16f27..0000000 ---- a/build/autotools/shave.in -+++ b/dev/null -@@ -1,79 +0,0 @@ --#!/bin/sh -- --# we need sed --SED=@SED@ --if test -z "$SED" ; then --SED=sed --fi -- --lt_unmangle () --{ -- last_result=`echo $1 | $SED -e 's#.libs/##' -e 's#[0-9a-zA-Z_\-\.]*_la-##'` --} -- --# the tool to wrap (cc, cxx, ar, ranlib, ..) --tool="$1" --shift -- --# the reel tool (to call) --REEL_TOOL="$1" --shift -- --pass_through=0 --preserved_args= --while test "$#" -gt 0; do -- opt="$1" -- shift -- -- case $opt in -- --shave-mode=*) -- mode=`echo $opt | $SED -e 's/[-_a-zA-Z0-9]*=//'` -- ;; -- -o) -- lt_output="$1" -- preserved_args="$preserved_args $opt" -- ;; -- *) -- preserved_args="$preserved_args $opt" -- ;; -- esac --done -- --# mode=link is handled in the libtool wrapper --case "$mode,$tool" in --link,*) -- pass_through=1 -- ;; --*,cxx) -- Q=" CXX " -- ;; --*,cc) -- Q=" CC " -- ;; --*,fc) -- Q=" FC " -- ;; --*,f77) -- Q=" F77 " -- ;; --*,objc) -- Q=" OBJC " -- ;; --*,*) -- # should not happen -- Q=" CC " -- ;; --esac -- --lt_unmangle "$lt_output" --output=$last_result -- --if test -z $V; then -- if test $pass_through -eq 0; then -- echo "$Q$output" -- fi -- $REEL_TOOL $preserved_args --else -- echo $REEL_TOOL $preserved_args -- $REEL_TOOL $preserved_args --fi -diff --git a/build/autotools/shave.m4 b/build/autotools/shave.m4 -deleted file mode 100644 -index 0a3509e..0000000 ---- a/build/autotools/shave.m4 -+++ b/dev/null -@@ -1,77 +0,0 @@ --dnl Make automake/libtool output more friendly to humans --dnl Damien Lespiau <[email protected]> --dnl --dnl SHAVE_INIT([shavedir],[default_mode]) --dnl --dnl shavedir: the directory where the shave scripts are, it defaults to --dnl $(top_builddir) --dnl default_mode: (enable|disable) default shave mode. This parameter --dnl controls shave's behaviour when no option has been --dnl given to configure. It defaults to disable. --dnl --dnl * SHAVE_INIT should be called late in your configure.(ac|in) file (just --dnl before AC_CONFIG_FILE/AC_OUTPUT is perfect. This macro rewrites CC and --dnl LIBTOOL, you don't want the configure tests to have these variables --dnl re-defined. --dnl * This macro requires GNU make's -s option. -- --AC_DEFUN([_SHAVE_ARG_ENABLE], --[ -- AC_ARG_ENABLE([shave], -- AS_HELP_STRING( -- [--enable-shave], -- [use shave to make the build pretty [[default=$1]]]),, -- [enable_shave=$1] -- ) --]) -- --AC_DEFUN([SHAVE_INIT], --[ -- dnl you can tweak the default value of enable_shave -- m4_if([$2], [enable], [_SHAVE_ARG_ENABLE(yes)], [_SHAVE_ARG_ENABLE(no)]) -- -- if test x"$enable_shave" = xyes; then -- dnl where can we find the shave scripts? -- m4_if([$1],, -- [shavedir="$ac_pwd"], -- [shavedir="$ac_pwd/$1"]) -- AC_SUBST(shavedir) -- -- dnl make is now quiet -- AC_SUBST([MAKEFLAGS], [-s]) -- AC_SUBST([AM_MAKEFLAGS], ['`test -z $V && echo -s`']) -- -- dnl we need sed -- AC_CHECK_PROG(SED,sed,sed,false) -- -- dnl substitute libtool -- SHAVE_SAVED_LIBTOOL=$LIBTOOL -- LIBTOOL="${SHELL} ${shavedir}/shave-libtool '${SHAVE_SAVED_LIBTOOL}'" -- AC_SUBST(LIBTOOL) -- -- dnl substitute cc/cxx -- SHAVE_SAVED_CC=$CC -- SHAVE_SAVED_CXX=$CXX -- SHAVE_SAVED_FC=$FC -- SHAVE_SAVED_F77=$F77 -- SHAVE_SAVED_OBJC=$OBJC -- CC="${SHELL} ${shavedir}/shave cc ${SHAVE_SAVED_CC}" -- CXX="${SHELL} ${shavedir}/shave cxx ${SHAVE_SAVED_CXX}" -- FC="${SHELL} ${shavedir}/shave fc ${SHAVE_SAVED_FC}" -- F77="${SHELL} ${shavedir}/shave f77 ${SHAVE_SAVED_F77}" -- OBJC="${SHELL} ${shavedir}/shave objc ${SHAVE_SAVED_OBJC}" -- AC_SUBST(CC) -- AC_SUBST(CXX) -- AC_SUBST(FC) -- AC_SUBST(F77) -- AC_SUBST(OBJC) -- -- V=@ -- else -- V=1 -- fi -- Q='$(V:1=)' -- AC_SUBST(V) -- AC_SUBST(Q) --]) -- -diff --git a/configure.ac b/configure.ac -index a3ed3ee..bc3163a 100644 ---- a/configure.ac -+++ b/configure.ac -@@ -14,7 +14,7 @@ m4_define([unique_api_version], [1.0]) - # This is the X.Y used in the protocol negotiation - m4_define([unique_protocol_version], [1.0]) - --AC_PREREQ([2.59]) -+AC_PREREQ([2.63]) - - AC_INIT([unique], [unique_version], - [http://bugzilla.gnome.org/enter_bug.cgi?product=libunique], -@@ -23,9 +23,21 @@ AC_INIT([unique], [unique_version], - AC_CONFIG_SRCDIR([unique/unique.h]) - AC_CONFIG_MACRO_DIR([build/autotools]) - --AM_INIT_AUTOMAKE([1.10]) -+AM_INIT_AUTOMAKE([1.11 no-define -Wno-portability dist-bzip2]) - AM_CONFIG_HEADER([config.h]) - -+AM_SILENT_RULES([yes]) -+ -+AC_PROG_CC_C_O -+ -+AM_PATH_GLIB_2_0 -+ -+LT_PREREQ([2.2.6]) -+LT_INIT([disable-static]) -+ -+# Honor aclocal flags -+ACLOCAL="$ACLOCAL $ACLOCAL_FLAGS" -+ - # version symbols - UNIQUE_MAJOR_VERSION=unique_major_version - UNIQUE_MINOR_VERSION=unique_minor_version -@@ -49,21 +61,6 @@ UNIQUE_LT_CURRENT_MINUS_AGE=m4_eval(lt_current - lt_age) - AC_SUBST(UNIQUE_LT_VERSION_INFO) - AC_SUBST(UNIQUE_LT_CURRENT_MINUS_AGE) - --AC_ISC_POSIX --AC_PROG_CC --AC_PROG_INSTALL --AC_PROG_MAKE_SET --AC_C_CONST --AC_PROG_LIBTOOL --AC_PATH_PROG(GLIB_MKENUMS, [glib-mkenums]) --AC_PATH_PROG(GLIB_GENMARSHAL, [glib-genmarshal]) -- --AM_SANITY_CHECK --AM_PROG_CC_STDC -- --# Honor aclocal flags --ACLOCAL="$ACLOCAL $ACLOCAL_FLAGS" -- - m4_define([glib_required], [2.12.0]) - m4_define([gtk_required], [2.11.0]) - m4_define([dbus_required], [0.70]) -@@ -122,7 +119,6 @@ AM_CONDITIONAL([HAVE_DBUS], [test "x$have_dbus" = "xyes"]) - dnl Bacon backend - dnl This is the fallback backend, so we *need* these headers and functions - dnl even if we end up using D-Bus --dnl D-Bus backend dependencies - m4_define([have_bacon_default], [yes]) - AC_ARG_ENABLE([bacon], - [AC_HELP_STRING([--enable-bacon=@<:@yes/no@:>@], -@@ -178,9 +174,9 @@ AC_ARG_ENABLE([maintainer-flags], - AS_IF([test "x$enable_maintainer_flags" = "xyes" && test "x$GCC" = "xyes"], - [ - AS_COMPILER_FLAGS([MAINTAINER_CFLAGS], -- ["-Werror -Wall -Wshadow -Wcast-align -- -Wno-uninitialized -Wempty-body -Wformat-security -- -Winit-self"]) -+ ["-Wall -Wshadow -Wcast-align -+ -Wno-uninitialized -Wempty-body -+ -Wformat-security -Winit-self"]) - ] - ) - -@@ -230,27 +226,10 @@ AC_DEFINE_UNQUOTED([GETTEXT_PACKAGE], - AM_GLIB_DEFINE_LOCALEDIR(UNIQUE_LOCALEDIR) - - # introspection --GOBJECT_INTROSPECTION_CHECK([0.6.3]) -+GOBJECT_INTROSPECTION_CHECK([0.6.7]) - - # gtk-doc --GTK_DOC_CHECK([1.11]) -- --# nice builds --m4_ifdef([AM_SILENT_RULES], -- [ -- AM_SILENT_RULES([yes]) -- use_shave=no -- ], -- [ -- SHAVE_INIT([build/autotools], [enable]) -- AC_CONFIG_FILES([ -- build/autotools/shave-libtool -- build/autotools/shave -- ]) -- use_shave=yes -- ]) -- --AM_CONDITIONAL([USE_SHAVE], [test "x$use_shave" = "xyes"]) -+GTK_DOC_CHECK([1.13]) - - AC_CONFIG_FILES([ - Makefile --- -cgit v0.9.0.2
meta/recipes-gnome/libunique/libunique/fix_for_compile_with_gcc-4.6.0.patch deleted +0 -36
@@ -1,36 +0,0 @@ -Upstream-Status: Pending - -Fix Following compilation errors with gcc 4.6.0 - -Nitin A Kamble <[email protected]> 2011/05/10 - -| uniquebackend-dbus.c: In function 'unique_backend_dbus_request_name': -| uniquebackend-dbus.c:87:22: error: variable 'backend_dbus' set but not used [-Werror=unused-but-set-variable] -| uniquebackend-dbus.c: In function 'unique_backend_dbus_send_message': -| uniquebackend-dbus.c:189:12: error: variable 'res' set but not used [-Werror=unused-but-set-variable] -| cc1: all warnings being treated as errors -| -| make[5]: *** [libunique_dbus_la-uniquebackend-dbus.lo] Error 1 - -Index: libunique-1.1.6/unique/dbus/uniquebackend-dbus.c -=================================================================== ---- libunique-1.1.6.orig/unique/dbus/uniquebackend-dbus.c -+++ libunique-1.1.6/unique/dbus/uniquebackend-dbus.c -@@ -84,7 +84,7 @@ unique_backend_dbus_register_proxy (Uniq - static gboolean - unique_backend_dbus_request_name (UniqueBackend *backend) - { -- UniqueBackendDBus *backend_dbus; -+ UniqueBackendDBus __attribute__((__unused__)) *backend_dbus; - const gchar *name; - DBusGConnection *connection; - DBusGProxy *proxy; -@@ -186,7 +186,7 @@ unique_backend_dbus_send_message (Unique - GValueArray *data; - gchar *cmd; - gchar *resp; -- gboolean res; -+ gboolean __attribute__((__unused__)) res; - GError *error; - UniqueResponse response; -
meta/recipes-gnome/libunique/libunique/noconst.patch deleted +0 -130
130 lines not on this page · raw message
meta/recipes-gnome/libunique/libunique_1.1.6.bb deleted +0 -25
@@ -1,25 +0,0 @@ -SUMMARY = "Library for supporting single instance GTK+ applications" -DESCRIPTION = "Unique is a library for writing single instance GTK+ applications. If you launch a single instance application twice, the second instance will either just quit or will send a message to the running instance." -HOMEPAGE = "https://wiki.gnome.org/Attic/LibUnique" -BUGTRACKER = "https://bugzilla.gnome.org/enter_bug.cgi?product=libunique" - -SRC_URI = "${GNOME_MIRROR}/libunique/1.1/libunique-${PV}.tar.bz2 \ - file://fix_for_compile_with_gcc-4.6.0.patch \ - file://noconst.patch \ - file://build.patch" - -SRC_URI[md5sum] = "7955769ef31f1bc4f83446dbb3625e6d" -SRC_URI[sha256sum] = "e5c8041cef8e33c55732f06a292381cb345db946cf792a4ae18aa5c66cdd4fbb" - -PR = "r7" - -DEPENDS = "glib-2.0 gtk+" - -PACKAGECONFIG ??= "dbus" -PACKAGECONFIG[dbus] = "--enable-dbus,--disable-dbus,dbus dbus-glib" - -LICENSE = "LGPLv2.1" -LIC_FILES_CHKSUM = "file://COPYING;md5=2d5025d4aa3495befef8f17206a5b0a1" - - -inherit autotools pkgconfig
Signature · 1 line
2.1.4
PATCH 6/12 mkelfimage: add RECIPE_NO_UPDATE_REASON
In reply to Alexander Kanavin--- meta/recipes-devtools/mkelfimage/mkelfimage_git.bb | 3 +++ 1 file changed, 3 insertions(+)
meta/recipes-devtools/mkelfimage/mkelfimage_git.bb +3 -0
@@ -6,6 +6,9 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=ea5bed2f60d357618ca161ad539f7c0a" SRCREV = "686a48a339b3200184c27e7f98d4c03180b2be6c" PV = "4.0+git${SRCPV}" +RECIPE_NO_UPDATE_REASON = "mkelfimage has been removed in coreboot 4.1 release: \ +http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=34fc4ab80b507739e2580d490dff67fcfdde11ea" + DEPENDS += "zlib"
Signature · 1 line
2.1.4
PATCH 7/12 python-async: update to 0.6.2
In reply to Alexander Kanavin---
.../python/{python-async_0.6.1.bb => python-async_0.6.2.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-devtools/python/{python-async_0.6.1.bb => python-async_0.6.2.bb} (77%)meta/recipes-devtools/python/python-async_0.6.2.bb renamed from meta/recipes-devtools/python/python-async_0.6.1.bb +2 -2
@@ -5,8 +5,8 @@ LICENSE = "BSD" LIC_FILES_CHKSUM = "file://PKG-INFO;beginline=8;endline=8;md5=88df8e78b9edfd744953862179f2d14e" SRC_URI = "http://pypi.python.org/packages/source/a/async/async-${PV}.tar.gz" -SRC_URI[md5sum] = "6f0e2ced1fe85f8410b9bde11be08587" -SRC_URI[sha256sum] = "41d14cc0456e03f34d13af284f65821d07d05c20e621bcaebd38f9ab5095d5d1" +SRC_URI[md5sum] = "9b06b5997de2154f3bc0273f80bcef6b" +SRC_URI[sha256sum] = "ac6894d876e45878faae493b0cf61d0e28ec417334448ac0a6ea2229d8343051" S = "${WORKDIR}/async-${PV}"
Signature · 1 line
2.1.4
PATCH 8/12 python-smmap: update to 0.9.0
In reply to Alexander Kanavin---
.../python/{python-smmap_0.8.2.bb => python-smmap_0.9.0.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-devtools/python/{python-smmap_0.8.2.bb => python-smmap_0.9.0.bb} (82%)meta/recipes-devtools/python/python-smmap_0.9.0.bb renamed from meta/recipes-devtools/python/python-smmap_0.8.2.bb +2 -2
@@ -8,8 +8,8 @@ LICENSE = "BSD" LIC_FILES_CHKSUM = "file://PKG-INFO;beginline=8;endline=8;md5=e910b35b0ef4e1f665b9a75d6afb7709" SRC_URI = "http://pypi.python.org/packages/source/s/smmap/smmap-${PV}.tar.gz" -SRC_URI[md5sum] = "f5426b7626ddcf5e447253fae0396b0c" -SRC_URI[sha256sum] = "dea2955cc045ec5527da6b762f7e95a5be7f645c683b54ccce52d56b4d7e2d6f" +SRC_URI[md5sum] = "d7932d5ace206bf4ae15198cf36fb6ab" +SRC_URI[sha256sum] = "0e2b62b497bd5f0afebc002eda4d90df9d209c30ef257e8673c90a6b5c119d62" S = "${WORKDIR}/smmap-${PV}"
Signature · 1 line
2.1.4
PATCH 9/12 remake: update to 4.1+dbg-1.1
In reply to Alexander Kanavinremake-remove-errors-about-colophon-and-cygnus-comma.patch has been merged upstream
inherit pkgconfig has been added because m4 macros defined by pkgconfig are now used in configure.ac
---
meta/recipes-devtools/remake/remake.inc | 4 +--
...ve-errors-about-colophon-and-cygnus-comma.patch | 39 ----------------------
.../{remake_git.bb => remake_4.1+dbg-1.1.bb} | 8 ++---
3 files changed, 4 insertions(+), 47 deletions(-)
delete mode 100644 meta/recipes-devtools/remake/remake/remake-remove-errors-about-colophon-and-cygnus-comma.patch
rename meta/recipes-devtools/remake/{remake_git.bb => remake_4.1+dbg-1.1.bb} (80%)meta/recipes-devtools/remake/remake.inc +2 -2
@@ -1,4 +1,4 @@ -SUMMARY = "Makefile debugger which is gnumake 3.81 compatible" +SUMMARY = "Makefile debugger which is gnumake compatible" DESCRIPTION = "remake is a patched and modernized version of GNU make \ utility that adds improved error reporting, the ability to trace \ execution in a comprehensible way, and a debugger."
@@ -8,7 +8,7 @@ SECTION = "devel" SRC_URI = "git://github.com/rocky/remake.git" -inherit autotools gettext update-alternatives +inherit autotools gettext update-alternatives pkgconfig ALTERNATIVE_${PN} = "make" ALTERNATIVE_LINK_NAME[make] = "${bindir}/make"
meta/recipes-devtools/remake/remake/remake-remove-errors-about-colophon-and-cygnus-comma.patch deleted +0 -39
@@ -1,39 +0,0 @@ -From 1316f10a97a4a2f5d11a30ec367aa61101318742 Mon Sep 17 00:00:00 2001 -From: "Maxin B. John" <[email protected]> -Date: Wed, 6 Aug 2014 15:05:56 +0200 -Subject: [PATCH] remake: remove errors about @colophon and @cygnus commands - not defined - -texinfo5 needs replacing @ with @@ when it is part of the text - -Upstream-Status: Backport -Signed-off-by: Maxin B. John <[email protected]> ---- - doc/remake.texi | 4 ++-- - 1 file changed, 2 insertions(+), 2 deletions(-) - -diff --git a/doc/remake.texi b/doc/remake.texi -index cd73437..fa5ba16 100644 ---- a/doc/remake.texi -+++ b/doc/remake.texi -@@ -2752,7 +2752,7 @@ this list, we would like to add your names! - @printindex cp - - @tex --% I think something like @colophon should be in texinfo. In the -+% I think something like @@colophon should be in texinfo. In the - % meantime: - \long\def\colophon{\hbox to0pt{}\vfill - \centerline{The body of this manual is set in} -@@ -2764,7 +2764,7 @@ this list, we would like to add your names! - \centerline{{\sl\fontname\tensl\/}} - \centerline{are used for emphasis.}\vfill} - \page\colophon --% Blame: [email protected], 1991. -+% Blame: doc@@cygnus.com, 1991. - @end tex - - @bye --- -1.9.1 -
meta/recipes-devtools/remake/remake_4.1+dbg-1.1.bb renamed from meta/recipes-devtools/remake/remake_git.bb +2 -6
@@ -1,4 +1,3 @@ -PR = "r1" LICENSE = "GPLv2" LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \ file://tests/COPYING;md5=d32239bcb673463ab874e80d47fae504 \
@@ -6,14 +5,11 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \ require remake.inc SRC_URI += "file://version-remake.texi.patch \ - file://remake-remove-errors-about-colophon-and-cygnus-comma.patch \ " -SRCREV = "f05508e521987c8494c92d9c2871aec46307d51d" +SRCREV = "cf54641d50a0165bb17622b3e9770f426ccbc561" S = "${WORKDIR}/git" -PV = "3.82+dbg-0.9+git${SRCPV}" - -DEPENDS += "readline" +DEPENDS += "readline guile" # Need to add "gettext-native" dependency to remake-native. # By default only "gettext-minimal-native" is added # when inherit gettext.
Signature · 1 line
2.1.4
PATCH 10/12 uclibc: update PV to 0.9.33.2 to match latest upstream release
In reply to Alexander KanavinThis fixes upstream version check. The git revision that is fetched is unchanged.
--- meta/recipes-core/uclibc/uclibc-git.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
meta/recipes-core/uclibc/uclibc-git.inc +1 -1
@@ -1,6 +1,6 @@ SRCREV = "ca1c74d67dd115d059a875150e10b8560a9c35a8" -PV = "0.9.33+git${SRCPV}" +PV = "0.9.33.2+git${SRCPV}" FILESEXTRAPATHS =. "${FILE_DIRNAME}/uclibc-git:"
Signature · 1 line
2.1.4
Re: [PATCH 10/12] uclibc: update PV to 0.9.33.2 to match latest upstream release
meta/recipes-core/uclibc/uclibc-git.inc line 3
Quoted 2 lines · Alexander Kanavin
meta/recipes-core/uclibc/uclibc-git.inc +1
-1-PV = "0.9.33+git${SRCPV}" +PV = "0.9.33.2+git${SRCPV}"
technically its not right since we are not on 0.9.33 branch at all. We could use 0.9.33+0.9.34+git${SRCPV}
Re: [PATCH 10/12] uclibc: update PV to 0.9.33.2 to match latest upstream release
Quoted 5 lines · Khem Raj
meta/recipes-core/uclibc/uclibc-git.inc line 3
Quoted 2 lines
meta/recipes-core/uclibc/uclibc-git.inc +1
-1-PV = "0.9.33+git${SRCPV}" +PV = "0.9.33.2+git${SRCPV}"technically its not right since we are not on 0.9.33 branch at all. We could use 0.9.33+0.9.34+git${SRCPV}
You're right. Nevermind then, uclibc is anyway one of those projects that can't be bothered to make a release. So there is no sensible upstream version check to perform.
Alex
PATCH 11/12 vte: add RECIPE_NO_UPDATE_REASON
In reply to Alexander Kanavin--- meta/recipes-support/vte/vte_0.28.2.bb | 2 ++ 1 file changed, 2 insertions(+)
meta/recipes-support/vte/vte_0.28.2.bb +2 -0
@@ -10,3 +10,5 @@ CFLAGS += "-D_GNU_SOURCE" SRC_URI[archive.md5sum] = "497f26e457308649e6ece32b3bb142ff" SRC_URI[archive.sha256sum] = "86cf0b81aa023fa93ed415653d51c96767f20b2d7334c893caba71e42654b0ae" + +RECIPE_NO_UPDATE_REASON = "matchbox-terminal needs to be ported over to new vte first"
Signature · 1 line
2.1.4
PATCH 12/12 package_regex.inc: various updates to improve RRS accuracy
In reply to Alexander Kanavin--- meta/conf/distro/include/package_regex.inc | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-)
meta/conf/distro/include/package_regex.inc +9 -5
@@ -44,6 +44,8 @@ REGEX_pn-nettle = "nettle-(?P<pver>\d+(\.\d+)+)\.tar" REGEX_pn-cairo = "cairo-(?P<pver>\d+(\.\d+)+)\.tar" REGEX_pn-cmake = "cmake-(?P<pver>\d+(\.\d+)+)\.tar" +REGEX_pn-libsdl = "SDL-(?P<pver>\d+(\.\d+)+)\.tar" +REGEX_pn-libxslt = "libxslt-(?P<pver>\d+(\.\d+)+)\.tar" # Exclude NC versions which lack AES encryption REGEX_pn-db = "db-(?P<pver>\d+\.\d+(\.\d+)?).tar"
@@ -171,9 +173,8 @@ REGEX_URI_pn-libpng12 = "http://sourceforge.net/projects/libpng/files/libpng12/" REGEX_pn-libpng12 = "/libpng12/${COMMON_REGEX}/" REGEX_URI_pn-docbook-dsssl-stylesheets = "http://sourceforge.net/projects/docbook/files/docbook-dsssl/" REGEX_pn-docbook-dsssl-stylesheets = "/docbook-dsssl/${COMMON_REGEX}/" -REGEX_URI_pn-openjade = "http://sourceforge.net/projects/openjade/files/openjade/" -REGEX_pn-openjade = "/openjade/${COMMON_REGEX}/" +REGEX_URI_pn-openjade = "http://openjade.sourceforge.net/download.html" REGEX_URI_pn-libpfm4 = "http://sourceforge.net/projects/perfmon2/files/libpfm4/" REGEX_URI_pn-liba52 = "http://liba52.sourceforge.net/downloads.html" REGEX_URI_pn-mpeg2dec = "http://libmpeg2.sourceforge.net/downloads.html"
@@ -202,6 +203,10 @@ GITTAGREGEX_pn-mx-1.0 = "(?P<pver>^\d+(\.(?!99)\d+)+)" # Blacklist a bogus tag GITTAGREGEX_pn-file = "FILE(?P<pver>(?!6_23).+)" +GITTAGREGEX_pn-xinetd = "xinetd-(?P<pver>(?!20030122).+)" + +# Blacklist debian-specific tags +GITTAGREGEX_pn-xf86-video-omapfb = "(?P<pver>\d+(\.\d+)+)(?!-)" # GNOME related. #
@@ -231,6 +236,7 @@ REGEX_pn-clutter-gtk-1.0 = "${GNOME_STABLE}" REGEX_pn-clutter-gst-3.0 = "${GNOME_STABLE}" REGEX_pn-cogl-1.0 = "${GNOME_STABLE}" REGEX_pn-adwaita-icon-theme = "${GNOME_STABLE}" +REGEX_pn-vte = "${GNOME_STABLE}" # not GNOME related but uses same even-minor-release-is-stable logic REGEX_pn-dbus = "${GNOME_STABLE}"
@@ -249,7 +255,7 @@ REGEX_pn-gstreamer1.0-rtsp-server = "${GNOME_STABLE}" REGEX_pn-perl = "${GNOME_STABLE}" # Keep old gcc versions at their major versions -REGEX_pn-gcc-source-4.9.2 = "gcc-(?P<pver>4\.9\.\d+).tar" +REGEX_pn-gcc-source-4.9.3 = "gcc-(?P<pver>4\.9\.\d+).tar" REGEX_pn-gcc-source-4.8.4 = "gcc-(?P<pver>4\.8\.\d+).tar" # these packages are taken from snapshots.debian.org; that source is static and goes stale
@@ -267,6 +273,4 @@ DEBIAN_PATCH_REGEX = "(?P<pver>((\d+\.*)+)-((\d+\.*)+))\.(diff|debian\.tar)\.(gz REGEX_pn-net-tools = "${DEBIAN_PATCH_REGEX}" REGEX_pn-apmd = "${DEBIAN_PATCH_REGEX}" REGEX_pn-blktool = "${DEBIAN_PATCH_REGEX}" -# mailx is fetched from launchpad -REGEX_URI_pn-mailx = "${DEBIAN_MIRROR}/main/h/heirloom-mailx/" REGEX_pn-mailx = "${DEBIAN_PATCH_REGEX}"
Signature · 1 line
2.1.4