* [PATCH 01/12] ccache: update to 3.2.3
2015-09-03 15:34 [PATCH 00/12] Various package/RRS updates Alexander Kanavin
@ 2015-09-03 15:34 ` Alexander Kanavin
2015-09-03 15:34 ` [PATCH 02/12] mailx: update to 12.5-5 Alexander Kanavin
` (10 subsequent siblings)
11 siblings, 0 replies; 30+ messages in thread
From: Alexander Kanavin @ 2015-09-03 15:34 UTC (permalink / raw)
To: openembedded-core
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.
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
---
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
diff --git a/meta/recipes-devtools/ccache/ccache.inc b/meta/recipes-devtools/ccache/ccache.inc
index 087cb7d..4790021 100644
--- a/meta/recipes-devtools/ccache/ccache.inc
+++ b/meta/recipes-devtools/ccache/ccache.inc
@@ -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
diff --git a/meta/recipes-devtools/ccache/ccache_3.1.11.bb b/meta/recipes-devtools/ccache/ccache_3.1.11.bb
deleted file mode 100644
index 7696003..0000000
--- a/meta/recipes-devtools/ccache/ccache_3.1.11.bb
+++ /dev/null
@@ -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"
diff --git a/meta/recipes-devtools/ccache/ccache_3.2.3.bb b/meta/recipes-devtools/ccache/ccache_3.2.3.bb
new file mode 100644
index 0000000..357df75
--- /dev/null
+++ b/meta/recipes-devtools/ccache/ccache_3.2.3.bb
@@ -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"
diff --git a/meta/recipes-devtools/ccache/files/0001-Fix-regression-in-recent-change-related-to-zlib-in-n.patch b/meta/recipes-devtools/ccache/files/0001-Fix-regression-in-recent-change-related-to-zlib-in-n.patch
new file mode 100644
index 0000000..a8400d5
--- /dev/null
+++ b/meta/recipes-devtools/ccache/files/0001-Fix-regression-in-recent-change-related-to-zlib-in-n.patch
@@ -0,0 +1,73 @@
+From f74c76107933046309861680b741adc67ac2a34e Mon Sep 17 00:00:00 2001
+From: Joel Rosdahl <joel@rosdahl.net>
+Date: Mon, 17 Aug 2015 19:05:14 +0200
+Subject: [PATCH] Fix regression in recent change related to zlib in
+ nonstandard location
+
+To allow for specifying a -L flag in LDFLAGS and have it take effect for
+-lz, 0220de9c8ebfb18caae2ac1aa163d060e98ceade put -lz in extra_libs
+instead of extra_ldflags. However, extra_libs is supposed to contain
+paths to libraries which are prerequisites of the ccache link rule, and
+some older versions of make got confused by seeing -lz as a
+prerequisite.
+
+This fix is to revert 0220de9c8ebfb18caae2ac1aa163d060e98ceade and
+instead make sure that LDFLAGS comes before extra_ldflags.
+
+Upstream-status: Backport
+---
+ Makefile.in | 2 +-
+ NEWS.txt | 10 ++++++++++
+ configure.ac | 2 +-
+ 3 files changed, 12 insertions(+), 2 deletions(-)
+
+diff --git a/Makefile.in b/Makefile.in
+index e7515b1..d3621cd 100644
+--- a/Makefile.in
++++ b/Makefile.in
+@@ -20,7 +20,7 @@ RANLIB = @RANLIB@
+
+ all_cflags = $(CFLAGS)
+ all_cppflags = @DEFS@ @extra_cppflags@ -DSYSCONFDIR=$(sysconfdir) -I. -I$(srcdir) $(CPPFLAGS)
+-all_ldflags = @extra_ldflags@ $(LDFLAGS)
++all_ldflags = $(LDFLAGS) @extra_ldflags@
+ extra_libs = @extra_libs@
+
+ base_sources = \
+diff --git a/NEWS.txt b/NEWS.txt
+index f13feeb..eaeadf6 100644
+--- a/NEWS.txt
++++ b/NEWS.txt
+@@ -2,6 +2,16 @@ ccache news
+ ===========
+
+
++Unreleased 3.2.4
++----------------
++
++Bug fixes
++~~~~~~~~~
++
++- Fixed build error related to zlib on systems with older make versions
++ (regression in ccache 3.2.3).
++
++
+ ccache 3.2.3
+ ------------
+ Release date: 2015-08-16
+diff --git a/configure.ac b/configure.ac
+index 8d8ce92..9e65588 100644
+--- a/configure.ac
++++ b/configure.ac
+@@ -120,7 +120,7 @@ if test x${use_bundled_zlib} = xyes; then
+ extra_libs="zlib/libz.a"
+ mkdir -p zlib
+ else
+- extra_libs="-lz"
++ extra_ldflags="-lz"
+ fi
+
+ dnl Linking on Windows needs ws2_32
+--
+2.1.4
+
--
2.1.4
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 02/12] mailx: update to 12.5-5
2015-09-03 15:34 [PATCH 00/12] Various package/RRS updates Alexander Kanavin
2015-09-03 15:34 ` [PATCH 01/12] ccache: update to 3.2.3 Alexander Kanavin
@ 2015-09-03 15:34 ` Alexander Kanavin
2015-09-03 15:34 ` [PATCH 03/12] net-tools: update to 1.60-25 Alexander Kanavin
` (9 subsequent siblings)
11 siblings, 0 replies; 30+ messages in thread
From: Alexander Kanavin @ 2015-09-03 15:34 UTC (permalink / raw)
To: openembedded-core
This 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/
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
---
...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%)
diff --git a/meta/recipes-extended/mailx/files/0001-Don-t-reuse-weak-symbol-optopt-to-fix-FTBFS-on-mips.patch b/meta/recipes-extended/mailx/files/0001-Don-t-reuse-weak-symbol-optopt-to-fix-FTBFS-on-mips.patch
new file mode 100644
index 0000000..126f505
--- /dev/null
+++ b/meta/recipes-extended/mailx/files/0001-Don-t-reuse-weak-symbol-optopt-to-fix-FTBFS-on-mips.patch
@@ -0,0 +1,59 @@
+From: Luk Claes <luk@debian.org>
+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++;
+ }
diff --git a/meta/recipes-extended/mailx/files/0002-Patched-out-SSL2-support-since-it-is-no-longer-suppo.patch b/meta/recipes-extended/mailx/files/0002-Patched-out-SSL2-support-since-it-is-no-longer-suppo.patch
new file mode 100644
index 0000000..f70f8fc
--- /dev/null
+++ b/meta/recipes-extended/mailx/files/0002-Patched-out-SSL2-support-since-it-is-no-longer-suppo.patch
@@ -0,0 +1,41 @@
+From: Hilko Bengen <bengen@debian.org>
+Date: Wed, 27 Apr 2011 00:18:42 +0200
+Subject: Patched out SSL2 support since it is no longer supported by OpenSSL.
+
+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 +-
+ openssl.c | 4 +---
+ 2 files changed, 2 insertions(+), 4 deletions(-)
+
+diff --git a/mailx.1 b/mailx.1
+index 417ea04..a02e430 100644
+--- a/mailx.1
++++ b/mailx.1
+@@ -3575,7 +3575,7 @@ Only applicable if SSL/TLS support is built using OpenSSL.
+ .TP
+ .B ssl-method
+ Selects a SSL/TLS protocol version;
+-valid values are `ssl2', `ssl3', and `tls1'.
++valid values are `ssl3', and `tls1'.
+ If unset, the method is selected automatically,
+ if possible.
+ .TP
+diff --git a/openssl.c b/openssl.c
+index b4e33fc..44fe4e5 100644
+--- a/openssl.c
++++ b/openssl.c
+@@ -216,9 +216,7 @@ ssl_select_method(const char *uhp)
+
+ cp = ssl_method_string(uhp);
+ if (cp != NULL) {
+- if (equal(cp, "ssl2"))
+- method = SSLv2_client_method();
+- else if (equal(cp, "ssl3"))
++ if (equal(cp, "ssl3"))
+ method = SSLv3_client_method();
+ else if (equal(cp, "tls1"))
+ method = TLSv1_client_method();
diff --git a/meta/recipes-extended/mailx/files/0003-Fixed-Lintian-warning-warning-macro-N-not-defined.patch b/meta/recipes-extended/mailx/files/0003-Fixed-Lintian-warning-warning-macro-N-not-defined.patch
new file mode 100644
index 0000000..0ee133a
--- /dev/null
+++ b/meta/recipes-extended/mailx/files/0003-Fixed-Lintian-warning-warning-macro-N-not-defined.patch
@@ -0,0 +1,25 @@
+From: Hilko Bengen <bengen@debian.org>
+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
diff --git a/meta/recipes-extended/mailx/files/0011-outof-Introduce-expandaddr-flag.patch b/meta/recipes-extended/mailx/files/0011-outof-Introduce-expandaddr-flag.patch
new file mode 100644
index 0000000..fdce13f
--- /dev/null
+++ b/meta/recipes-extended/mailx/files/0011-outof-Introduce-expandaddr-flag.patch
@@ -0,0 +1,70 @@
+From 9984ae5cb0ea0d61df1612b06952a61323c083d9 Mon Sep 17 00:00:00 2001
+From: Florian Weimer <fweimer@redhat.com>
+Date: Mon, 17 Nov 2014 11:13:38 +0100
+Subject: [PATCH 1/4] outof: Introduce expandaddr flag
+
+Document that address expansion is disabled unless the expandaddr
+binary option is set.
+
+This has been assigned CVE-2014-7844 for BSD mailx, but it is not
+a vulnerability in Heirloom mailx because this feature was documented.
+
+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 | 14 ++++++++++++++
+ names.c | 3 +++
+ 2 files changed, 17 insertions(+)
+
+diff --git a/mailx.1 b/mailx.1
+index 70a7859..22a171b 100644
+--- a/mailx.1
++++ b/mailx.1
+@@ -656,6 +656,14 @@ but any reply returned to the machine
+ will have the system wide alias expanded
+ as all mail goes through sendmail.
+ .SS "Recipient address specifications"
++If the
++.I expandaddr
++option is not set (the default), recipient addresses must be names of
++local mailboxes or Internet mail addresses.
++.PP
++If the
++.I expandaddr
++option is set, the following rules apply:
+ When an address is used to name a recipient
+ (in any of To, Cc, or Bcc),
+ names of local mail folders
+@@ -2391,6 +2399,12 @@ and exits immediately.
+ If this option is set,
+ \fImailx\fR starts even with an empty mailbox.
+ .TP
++.B expandaddr
++Causes
++.I mailx
++to expand message recipient addresses, as explained in the section,
++Recipient address specifications.
++.TP
+ .B flipr
+ Exchanges the
+ .I Respond
+diff --git a/names.c b/names.c
+index 66e976b..c69560f 100644
+--- a/names.c
++++ b/names.c
+@@ -268,6 +268,9 @@ outof(struct name *names, FILE *fo, struct header *hp)
+ FILE *fout, *fin;
+ int ispipe;
+
++ if (value("expandaddr") == NULL)
++ return names;
++
+ top = names;
+ np = names;
+ time(&now);
+--
+1.9.3
+
+
diff --git a/meta/recipes-extended/mailx/files/0012-unpack-Disable-option-processing-for-email-addresses.patch b/meta/recipes-extended/mailx/files/0012-unpack-Disable-option-processing-for-email-addresses.patch
new file mode 100644
index 0000000..b51472f
--- /dev/null
+++ b/meta/recipes-extended/mailx/files/0012-unpack-Disable-option-processing-for-email-addresses.patch
@@ -0,0 +1,79 @@
+From e34e2ac67b80497080ebecccec40c3b61456167d Mon Sep 17 00:00:00 2001
+From: Florian Weimer <fweimer@redhat.com>
+Date: Mon, 17 Nov 2014 11:14:06 +0100
+Subject: [PATCH 2/4] unpack: Disable option processing for email addresses
+ when calling sendmail
+
+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]
+---
+ extern.h | 2 +-
+ names.c | 8 ++++++--
+ sendout.c | 2 +-
+ 3 files changed, 8 insertions(+), 4 deletions(-)
+
+diff --git a/extern.h b/extern.h
+index 6b85ba0..8873fe8 100644
+--- a/extern.h
++++ b/extern.h
+@@ -396,7 +396,7 @@ struct name *outof(struct name *names, FILE *fo, struct header *hp);
+ int is_fileaddr(char *name);
+ struct name *usermap(struct name *names);
+ struct name *cat(struct name *n1, struct name *n2);
+-char **unpack(struct name *np);
++char **unpack(struct name *smopts, struct name *np);
+ struct name *elide(struct name *names);
+ int count(struct name *np);
+ struct name *delete_alternates(struct name *np);
+diff --git a/names.c b/names.c
+index c69560f..45bbaed 100644
+--- a/names.c
++++ b/names.c
+@@ -549,7 +549,7 @@ cat(struct name *n1, struct name *n2)
+ * Return an error if the name list won't fit.
+ */
+ char **
+-unpack(struct name *np)
++unpack(struct name *smopts, struct name *np)
+ {
+ char **ap, **top;
+ struct name *n;
+@@ -564,7 +564,7 @@ unpack(struct name *np)
+ * the terminating 0 pointer. Additional spots may be needed
+ * to pass along -f to the host mailer.
+ */
+- extra = 2;
++ extra = 3 + count(smopts);
+ extra++;
+ metoo = value("metoo") != NULL;
+ if (metoo)
+@@ -581,6 +581,10 @@ unpack(struct name *np)
+ *ap++ = "-m";
+ if (verbose)
+ *ap++ = "-v";
++ for (; smopts != NULL; smopts = smopts->n_flink)
++ if ((smopts->n_type & GDEL) == 0)
++ *ap++ = smopts->n_name;
++ *ap++ = "--";
+ for (; n != NULL; n = n->n_flink)
+ if ((n->n_type & GDEL) == 0)
+ *ap++ = n->n_name;
+diff --git a/sendout.c b/sendout.c
+index 7b7f2eb..c52f15d 100644
+--- a/sendout.c
++++ b/sendout.c
+@@ -835,7 +835,7 @@ start_mta(struct name *to, struct name *mailargs, FILE *input,
+ #endif /* HAVE_SOCKETS */
+
+ if ((smtp = value("smtp")) == NULL) {
+- args = unpack(cat(mailargs, to));
++ args = unpack(mailargs, to);
+ if (debug || value("debug")) {
+ printf(catgets(catd, CATSET, 181,
+ "Sendmail arguments:"));
+--
+1.9.3
+
+
diff --git a/meta/recipes-extended/mailx/files/0013-fio.c-Unconditionally-require-wordexp-support.patch b/meta/recipes-extended/mailx/files/0013-fio.c-Unconditionally-require-wordexp-support.patch
new file mode 100644
index 0000000..5bf3cdd
--- /dev/null
+++ b/meta/recipes-extended/mailx/files/0013-fio.c-Unconditionally-require-wordexp-support.patch
@@ -0,0 +1,113 @@
+From 2bae8ecf04ec2ba6bb9f0af5b80485dd0edb427d Mon Sep 17 00:00:00 2001
+From: Florian Weimer <fweimer@redhat.com>
+Date: Mon, 17 Nov 2014 12:48:25 +0100
+Subject: [PATCH 3/4] fio.c: Unconditionally require wordexp support
+
+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 | 67 +++++--------------------------------------------------------------
+ 1 file changed, 5 insertions(+), 62 deletions(-)
+
+diff --git a/fio.c b/fio.c
+index 65e8f10..1529236 100644
+--- a/fio.c
++++ b/fio.c
+@@ -43,12 +43,15 @@ static char sccsid[] = "@(#)fio.c 2.76 (gritter) 9/16/09";
+ #endif /* not lint */
+
+ #include "rcv.h"
++
++#ifndef HAVE_WORDEXP
++#error wordexp support is required
++#endif
++
+ #include <sys/stat.h>
+ #include <sys/file.h>
+ #include <sys/wait.h>
+-#ifdef HAVE_WORDEXP
+ #include <wordexp.h>
+-#endif /* HAVE_WORDEXP */
+ #include <unistd.h>
+
+ #if defined (USE_NSS)
+@@ -481,7 +484,6 @@ next:
+ static char *
+ globname(char *name)
+ {
+-#ifdef HAVE_WORDEXP
+ wordexp_t we;
+ char *cp;
+ sigset_t nset;
+@@ -527,65 +529,6 @@ globname(char *name)
+ }
+ wordfree(&we);
+ return cp;
+-#else /* !HAVE_WORDEXP */
+- char xname[PATHSIZE];
+- char cmdbuf[PATHSIZE]; /* also used for file names */
+- int pid, l;
+- char *cp, *shell;
+- int pivec[2];
+- extern int wait_status;
+- struct stat sbuf;
+-
+- if (pipe(pivec) < 0) {
+- perror("pipe");
+- return name;
+- }
+- snprintf(cmdbuf, sizeof cmdbuf, "echo %s", name);
+- if ((shell = value("SHELL")) == NULL)
+- shell = SHELL;
+- pid = start_command(shell, 0, -1, pivec[1], "-c", cmdbuf, NULL);
+- if (pid < 0) {
+- close(pivec[0]);
+- close(pivec[1]);
+- return NULL;
+- }
+- close(pivec[1]);
+-again:
+- l = read(pivec[0], xname, sizeof xname);
+- if (l < 0) {
+- if (errno == EINTR)
+- goto again;
+- perror("read");
+- close(pivec[0]);
+- return NULL;
+- }
+- close(pivec[0]);
+- if (wait_child(pid) < 0 && WTERMSIG(wait_status) != SIGPIPE) {
+- fprintf(stderr, catgets(catd, CATSET, 81,
+- "\"%s\": Expansion failed.\n"), name);
+- return NULL;
+- }
+- if (l == 0) {
+- fprintf(stderr, catgets(catd, CATSET, 82,
+- "\"%s\": No match.\n"), name);
+- return NULL;
+- }
+- if (l == sizeof xname) {
+- fprintf(stderr, catgets(catd, CATSET, 83,
+- "\"%s\": Expansion buffer overflow.\n"), name);
+- return NULL;
+- }
+- xname[l] = 0;
+- for (cp = &xname[l-1]; *cp == '\n' && cp > xname; cp--)
+- ;
+- cp[1] = '\0';
+- if (strchr(xname, ' ') && stat(xname, &sbuf) < 0) {
+- fprintf(stderr, catgets(catd, CATSET, 84,
+- "\"%s\": Ambiguous.\n"), name);
+- return NULL;
+- }
+- return savestr(xname);
+-#endif /* !HAVE_WORDEXP */
+ }
+
+ /*
+--
+1.9.3
+
+
diff --git a/meta/recipes-extended/mailx/files/0014-globname-Invoke-wordexp-with-WRDE_NOCMD.patch b/meta/recipes-extended/mailx/files/0014-globname-Invoke-wordexp-with-WRDE_NOCMD.patch
new file mode 100644
index 0000000..6f162ea
--- /dev/null
+++ b/meta/recipes-extended/mailx/files/0014-globname-Invoke-wordexp-with-WRDE_NOCMD.patch
@@ -0,0 +1,30 @@
+From 73fefa0c1ac70043ec84f2d8b8f9f683213f168d Mon Sep 17 00:00:00 2001
+From: Florian Weimer <fweimer@redhat.com>
+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
+
+
diff --git a/meta/recipes-extended/mailx/files/0015-usr-sbin-sendmail.patch b/meta/recipes-extended/mailx/files/0015-usr-sbin-sendmail.patch
new file mode 100644
index 0000000..7e33789
--- /dev/null
+++ b/meta/recipes-extended/mailx/files/0015-usr-sbin-sendmail.patch
@@ -0,0 +1,38 @@
+Description: Sendmail is at /usr/sbin/sendmail
+ As per Debian Policy §11.6
+Author: Ryan Kavanagh <rak@debian.org>
+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.
diff --git a/meta/recipes-extended/mailx/mailx-12.5/explicitly.disable.krb5.support.patch b/meta/recipes-extended/mailx/files/explicitly.disable.krb5.support.patch
similarity index 100%
rename from meta/recipes-extended/mailx/mailx-12.5/explicitly.disable.krb5.support.patch
rename to meta/recipes-extended/mailx/files/explicitly.disable.krb5.support.patch
diff --git a/meta/recipes-extended/mailx/mailx_12.5.bb b/meta/recipes-extended/mailx/mailx_12.5-5.bb
similarity index 48%
rename from meta/recipes-extended/mailx/mailx_12.5.bb
rename to meta/recipes-extended/mailx/mailx_12.5-5.bb
index a53da3a..ffa9049 100644
--- a/meta/recipes-extended/mailx/mailx_12.5.bb
+++ b/meta/recipes-extended/mailx/mailx_12.5-5.bb
@@ -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:
--
2.1.4
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 03/12] net-tools: update to 1.60-25
2015-09-03 15:34 [PATCH 00/12] Various package/RRS updates Alexander Kanavin
2015-09-03 15:34 ` [PATCH 01/12] ccache: update to 3.2.3 Alexander Kanavin
2015-09-03 15:34 ` [PATCH 02/12] mailx: update to 12.5-5 Alexander Kanavin
@ 2015-09-03 15:34 ` Alexander Kanavin
2015-09-03 15:34 ` [PATCH 04/12] gnome-icon-theme: remove the recipe Alexander Kanavin
` (8 subsequent siblings)
11 siblings, 0 replies; 30+ messages in thread
From: Alexander Kanavin @ 2015-09-03 15:34 UTC (permalink / raw)
To: openembedded-core
This means fetching a newer Debian patchset which adds a few
bug/security fixes.
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
---
.../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%)
diff --git a/meta/recipes-extended/net-tools/net-tools_1.60-25.bb b/meta/recipes-extended/net-tools/net-tools_1.60-26.bb
similarity index 91%
rename from meta/recipes-extended/net-tools/net-tools_1.60-25.bb
rename to meta/recipes-extended/net-tools/net-tools_1.60-26.bb
index c47d69a..aefc1e6 100644
--- a/meta/recipes-extended/net-tools/net-tools_1.60-25.bb
+++ b/meta/recipes-extended/net-tools/net-tools_1.60-26.bb
@@ -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
--
2.1.4
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 04/12] gnome-icon-theme: remove the recipe
2015-09-03 15:34 [PATCH 00/12] Various package/RRS updates Alexander Kanavin
` (2 preceding siblings ...)
2015-09-03 15:34 ` [PATCH 03/12] net-tools: update to 1.60-25 Alexander Kanavin
@ 2015-09-03 15:34 ` Alexander Kanavin
2015-09-03 16:08 ` Burton, Ross
2015-09-03 21:28 ` Khem Raj
2015-09-03 15:34 ` [PATCH 05/12] libunique: " Alexander Kanavin
` (7 subsequent siblings)
11 siblings, 2 replies; 30+ messages in thread
From: Alexander Kanavin @ 2015-09-03 15:34 UTC (permalink / raw)
To: openembedded-core
It is not used by anything in oe-core and will be moved to meta-gnome
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
---
.../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
diff --git a/meta/recipes-gnome/gnome/gnome-icon-theme/pkgconfig-native.patch b/meta/recipes-gnome/gnome/gnome-icon-theme/pkgconfig-native.patch
deleted file mode 100644
index 6139eab..0000000
--- a/meta/recipes-gnome/gnome/gnome-icon-theme/pkgconfig-native.patch
+++ /dev/null
@@ -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 <ross.burton@intel.com>
-
-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
diff --git a/meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb b/meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb
deleted file mode 100644
index a6a3afa..0000000
--- a/meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb
+++ /dev/null
@@ -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
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [PATCH 04/12] gnome-icon-theme: remove the recipe
2015-09-03 15:34 ` [PATCH 04/12] gnome-icon-theme: remove the recipe Alexander Kanavin
@ 2015-09-03 16:08 ` Burton, Ross
2015-09-04 11:56 ` Jussi Kukkonen
2015-09-03 21:28 ` Khem Raj
1 sibling, 1 reply; 30+ messages in thread
From: Burton, Ross @ 2015-09-03 16:08 UTC (permalink / raw)
To: Alexander Kanavin; +Cc: OE-core
[-- Attachment #1: Type: text/plain, Size: 486 bytes --]
On 3 September 2015 at 16:34, Alexander Kanavin <
alexander.kanavin@linux.intel.com> wrote:
> 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
[-- Attachment #2: Type: text/html, Size: 893 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 04/12] gnome-icon-theme: remove the recipe
2015-09-03 16:08 ` Burton, Ross
@ 2015-09-04 11:56 ` Jussi Kukkonen
2015-09-04 12:12 ` Alexander Kanavin
0 siblings, 1 reply; 30+ messages in thread
From: Jussi Kukkonen @ 2015-09-04 11:56 UTC (permalink / raw)
To: Burton, Ross; +Cc: OE-core
[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]
On 3 September 2015 at 19:08, Burton, Ross <ross.burton@intel.com> wrote:
>
> On 3 September 2015 at 16:34, Alexander Kanavin <
> alexander.kanavin@linux.intel.com> wrote:
>
>> 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
[-- Attachment #2: Type: text/html, Size: 2161 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 04/12] gnome-icon-theme: remove the recipe
2015-09-04 11:56 ` Jussi Kukkonen
@ 2015-09-04 12:12 ` Alexander Kanavin
2015-09-04 13:32 ` Burton, Ross
0 siblings, 1 reply; 30+ messages in thread
From: Alexander Kanavin @ 2015-09-04 12:12 UTC (permalink / raw)
To: Jussi Kukkonen, Burton, Ross; +Cc: OE-core
On 09/04/2015 02:56 PM, Jussi Kukkonen wrote:
> 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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 04/12] gnome-icon-theme: remove the recipe
2015-09-04 12:12 ` Alexander Kanavin
@ 2015-09-04 13:32 ` Burton, Ross
0 siblings, 0 replies; 30+ messages in thread
From: Burton, Ross @ 2015-09-04 13:32 UTC (permalink / raw)
To: Alexander Kanavin; +Cc: OE-core
[-- Attachment #1: Type: text/plain, Size: 526 bytes --]
On 4 September 2015 at 13:12, Alexander Kanavin <
alexander.kanavin@linux.intel.com> wrote:
> 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
[-- Attachment #2: Type: text/html, Size: 929 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 04/12] gnome-icon-theme: remove the recipe
2015-09-03 15:34 ` [PATCH 04/12] gnome-icon-theme: remove the recipe Alexander Kanavin
2015-09-03 16:08 ` Burton, Ross
@ 2015-09-03 21:28 ` Khem Raj
2015-09-04 12:14 ` Alexander Kanavin
1 sibling, 1 reply; 30+ messages in thread
From: Khem Raj @ 2015-09-03 21:28 UTC (permalink / raw)
To: Alexander Kanavin; +Cc: openembedded-core
[-- Attachment #1: Type: text/plain, Size: 3467 bytes --]
> On Sep 3, 2015, at 8:34 AM, Alexander Kanavin <alexander.kanavin@linux.intel.com> wrote:
>
> 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
> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
> ---
> .../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
>
> diff --git a/meta/recipes-gnome/gnome/gnome-icon-theme/pkgconfig-native.patch b/meta/recipes-gnome/gnome/gnome-icon-theme/pkgconfig-native.patch
> deleted file mode 100644
> index 6139eab..0000000
> --- a/meta/recipes-gnome/gnome/gnome-icon-theme/pkgconfig-native.patch
> +++ /dev/null
> @@ -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 <ross.burton@intel.com>
> -
> -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
> diff --git a/meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb b/meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb
> deleted file mode 100644
> index a6a3afa..0000000
> --- a/meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb
> +++ /dev/null
> @@ -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
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH 04/12] gnome-icon-theme: remove the recipe
2015-09-03 21:28 ` Khem Raj
@ 2015-09-04 12:14 ` Alexander Kanavin
2015-09-04 14:16 ` Khem Raj
0 siblings, 1 reply; 30+ messages in thread
From: Alexander Kanavin @ 2015-09-04 12:14 UTC (permalink / raw)
To: Khem Raj; +Cc: openembedded-core
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
>>
>
> 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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 04/12] gnome-icon-theme: remove the recipe
2015-09-04 12:14 ` Alexander Kanavin
@ 2015-09-04 14:16 ` Khem Raj
2015-09-07 9:37 ` Alexander Kanavin
0 siblings, 1 reply; 30+ messages in thread
From: Khem Raj @ 2015-09-04 14:16 UTC (permalink / raw)
To: Alexander Kanavin; +Cc: openembedded-core
[-- Attachment #1: Type: text/plain, Size: 751 bytes --]
On Friday, September 4, 2015, Alexander Kanavin <
alexander.kanavin@linux.intel.com> wrote:
> 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
>>>
>>>
>> 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.
>
> Alex
>
>
[-- Attachment #2: Type: text/html, Size: 1312 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 04/12] gnome-icon-theme: remove the recipe
2015-09-04 14:16 ` Khem Raj
@ 2015-09-07 9:37 ` Alexander Kanavin
2015-09-07 15:14 ` Martin Jansa
0 siblings, 1 reply; 30+ messages in thread
From: Alexander Kanavin @ 2015-09-07 9:37 UTC (permalink / raw)
To: Martin Jansa, openembedded-core
On 09/04/2015 05:16 PM, Khem Raj wrote:
> 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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 04/12] gnome-icon-theme: remove the recipe
2015-09-07 9:37 ` Alexander Kanavin
@ 2015-09-07 15:14 ` Martin Jansa
2015-09-18 17:30 ` World builds HW Was: " Martin Jansa
0 siblings, 1 reply; 30+ messages in thread
From: Martin Jansa @ 2015-09-07 15:14 UTC (permalink / raw)
To: Alexander Kanavin; +Cc: openembedded-core
[-- Attachment #1: Type: text/plain, Size: 1581 bytes --]
On Mon, Sep 07, 2015 at 12:37:35PM +0300, Alexander Kanavin wrote:
> On 09/04/2015 05:16 PM, Khem Raj wrote:
>
> > 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
yes
> 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,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* World builds HW Was: [PATCH 04/12] gnome-icon-theme: remove the recipe
2015-09-07 15:14 ` Martin Jansa
@ 2015-09-18 17:30 ` Martin Jansa
2015-09-18 17:38 ` Gary Thomas
2015-09-18 17:56 ` Tom King
0 siblings, 2 replies; 30+ messages in thread
From: Martin Jansa @ 2015-09-18 17:30 UTC (permalink / raw)
To: Randy MacLeod, openembedded-core
[-- Attachment #1: Type: text/plain, Size: 3308 bytes --]
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.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).
> 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
If you know about some idling build servers, I would like to give them
something to do :).
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: World builds HW Was: [PATCH 04/12] gnome-icon-theme: remove the recipe
2015-09-18 17:30 ` World builds HW Was: " Martin Jansa
@ 2015-09-18 17:38 ` Gary Thomas
2015-09-18 17:52 ` Martin Jansa
2015-09-18 17:56 ` Tom King
1 sibling, 1 reply; 30+ messages in thread
From: Gary Thomas @ 2015-09-18 17:38 UTC (permalink / raw)
To: openembedded-core
On 2015-09-18 11:30, Martin Jansa 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)
(slightly off topic): How did you get this report?
>
> 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).
>
>> 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
>
> If you know about some idling build servers, I would like to give them
> something to do :).
>
> Regards,
>
>
>
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: World builds HW Was: [PATCH 04/12] gnome-icon-theme: remove the recipe
2015-09-18 17:38 ` Gary Thomas
@ 2015-09-18 17:52 ` Martin Jansa
0 siblings, 0 replies; 30+ messages in thread
From: Martin Jansa @ 2015-09-18 17:52 UTC (permalink / raw)
To: Gary Thomas; +Cc: openembedded-core
[-- Attachment #1: Type: text/plain, Size: 4227 bytes --]
On Fri, Sep 18, 2015 at 11:38:30AM -0600, Gary Thomas wrote:
> On 2015-09-18 11:30, Martin Jansa 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)
>
> (slightly off topic): How did you get this report?
inherit buildstats-summary
> > 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).
> >
> >> 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
> >
> > If you know about some idling build servers, I would like to give them
> > something to do :).
> >
> > Regards,
> >
> >
> >
>
> --
> ------------------------------------------------------------
> Gary Thomas | Consulting for the
> MLB Associates | Embedded world
> ------------------------------------------------------------
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: World builds HW Was: [PATCH 04/12] gnome-icon-theme: remove the recipe
2015-09-18 17:30 ` World builds HW Was: " Martin Jansa
2015-09-18 17:38 ` Gary Thomas
@ 2015-09-18 17:56 ` Tom King
2015-10-13 20:43 ` Randy MacLeod
1 sibling, 1 reply; 30+ messages in thread
From: Tom King @ 2015-09-18 17:56 UTC (permalink / raw)
To: Martin Jansa; +Cc: openembedded-core
[-- Attachment #1: Type: text/plain, Size: 3818 bytes --]
Martin, 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
On Fri, Sep 18, 2015 at 10:30 AM, Martin Jansa <martin.jansa@gmail.com>
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.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).
>
> > 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
>
> If you know about some idling build servers, I would like to give them
> something to do :).
>
> Regards,
>
> --
> Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
>
[-- Attachment #2: Type: text/html, Size: 4721 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: World builds HW Was: [PATCH 04/12] gnome-icon-theme: remove the recipe
2015-09-18 17:56 ` Tom King
@ 2015-10-13 20:43 ` Randy MacLeod
2015-10-14 13:01 ` Martin Jansa
0 siblings, 1 reply; 30+ messages in thread
From: Randy MacLeod @ 2015-10-13 20:43 UTC (permalink / raw)
To: Tom King, Martin Jansa; +Cc: openembedded-core
On 2015-09-18 01:56 PM, Tom King wrote:
> 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
>
> On Fri, Sep 18, 2015 at 10:30 AM, Martin Jansa <martin.jansa@gmail.com
> <mailto:martin.jansa@gmail.com>> 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.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).
>
> > 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: Martin.Jansa@gmail.com
> <mailto:Martin.Jansa@gmail.com>
>
>
--
# Randy MacLeod. SMTS, Linux, Wind River
Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON,
Canada, K2K 2W5
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: World builds HW Was: [PATCH 04/12] gnome-icon-theme: remove the recipe
2015-10-13 20:43 ` Randy MacLeod
@ 2015-10-14 13:01 ` Martin Jansa
0 siblings, 0 replies; 30+ messages in thread
From: Martin Jansa @ 2015-10-14 13:01 UTC (permalink / raw)
To: Randy MacLeod; +Cc: openembedded-core
[-- Attachment #1: Type: text/plain, Size: 5169 bytes --]
On Tue, Oct 13, 2015 at 04:43:44PM -0400, Randy MacLeod wrote:
> On 2015-09-18 01:56 PM, Tom King wrote:
> > 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?
I'm still waiting for access to that server.
> Do you need additional systems?
More builders are always welcome. In ideal case I would trigger all 3
architectures in parallel on different builders.
> ../Randy
> >
> > On Fri, Sep 18, 2015 at 10:30 AM, Martin Jansa <martin.jansa@gmail.com
> > <mailto:martin.jansa@gmail.com>> 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.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).
> >
> > > 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: Martin.Jansa@gmail.com
> > <mailto:Martin.Jansa@gmail.com>
> >
> >
>
>
> --
> # Randy MacLeod. SMTS, Linux, Wind River
> Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON,
> Canada, K2K 2W5
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 05/12] libunique: remove the recipe
2015-09-03 15:34 [PATCH 00/12] Various package/RRS updates Alexander Kanavin
` (3 preceding siblings ...)
2015-09-03 15:34 ` [PATCH 04/12] gnome-icon-theme: remove the recipe Alexander Kanavin
@ 2015-09-03 15:34 ` Alexander Kanavin
2015-09-03 15:34 ` [PATCH 06/12] mkelfimage: add RECIPE_NO_UPDATE_REASON Alexander Kanavin
` (6 subsequent siblings)
11 siblings, 0 replies; 30+ messages in thread
From: Alexander Kanavin @ 2015-09-03 15:34 UTC (permalink / raw)
To: openembedded-core
It is not used by anything in oe-core and will be moved to meta-oe
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
---
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
diff --git a/meta/recipes-gnome/libunique/libunique/build.patch b/meta/recipes-gnome/libunique/libunique/build.patch
deleted file mode 100644
index 46a5c62..0000000
--- a/meta/recipes-gnome/libunique/libunique/build.patch
+++ /dev/null
@@ -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 <ross.burton@intel.com>
-
-From f75ca2d7aad7d27686acca6090c1c569a79d7e63 Mon Sep 17 00:00:00 2001
-From: Emmanuele Bassi <ebassi@gnome.org>
-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 <damien.lespiau@gmail.com>
--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
diff --git a/meta/recipes-gnome/libunique/libunique/fix_for_compile_with_gcc-4.6.0.patch b/meta/recipes-gnome/libunique/libunique/fix_for_compile_with_gcc-4.6.0.patch
deleted file mode 100644
index d75de93..0000000
--- a/meta/recipes-gnome/libunique/libunique/fix_for_compile_with_gcc-4.6.0.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-Upstream-Status: Pending
-
-Fix Following compilation errors with gcc 4.6.0
-
-Nitin A Kamble <nitin.a.kamble@intel.com> 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;
-
diff --git a/meta/recipes-gnome/libunique/libunique/noconst.patch b/meta/recipes-gnome/libunique/libunique/noconst.patch
deleted file mode 100644
index 2cc0347..0000000
--- a/meta/recipes-gnome/libunique/libunique/noconst.patch
+++ /dev/null
@@ -1,130 +0,0 @@
-G_CONST_RETURN is deprecated in glib 2.30 so remove to to avoid
-build failures.
-
-RP 2011/10/12
-
-Upstream-Status: Pending
-
-Index: libunique-1.1.6/unique/uniqueapp.c
-===================================================================
---- libunique-1.1.6.orig/unique/uniqueapp.c 2011-10-12 01:21:25.842046488 +0100
-+++ libunique-1.1.6/unique/uniqueapp.c 2011-10-12 01:21:55.062046796 +0100
-@@ -781,7 +781,7 @@
- }
-
-
--G_CONST_RETURN gchar *
-+const gchar *
- unique_command_to_string (UniqueApp *app,
- gint command)
- {
-@@ -863,7 +863,7 @@
- return retval;
- }
-
--G_CONST_RETURN gchar *
-+const gchar *
- unique_response_to_string (UniqueResponse response)
- {
- GEnumClass *enum_class;
-Index: libunique-1.1.6/unique/uniquebackend.c
-===================================================================
---- libunique-1.1.6.orig/unique/uniquebackend.c 2011-10-12 01:21:25.742046323 +0100
-+++ libunique-1.1.6/unique/uniquebackend.c 2011-10-12 01:21:55.062046796 +0100
-@@ -111,7 +111,7 @@
- *
- * Return value: FIXME
- */
--G_CONST_RETURN gchar *
-+const gchar *
- unique_backend_get_name (UniqueBackend *backend)
- {
- g_return_val_if_fail (UNIQUE_IS_BACKEND (backend), NULL);
-@@ -154,7 +154,7 @@
- *
- * Return value: FIXME
- */
--G_CONST_RETURN gchar *
-+const gchar *
- unique_backend_get_startup_id (UniqueBackend *backend)
- {
- g_return_val_if_fail (UNIQUE_IS_BACKEND (backend), NULL);
-Index: libunique-1.1.6/unique/uniquebackend.h
-===================================================================
---- libunique-1.1.6.orig/unique/uniquebackend.h 2011-10-12 01:21:25.992046521 +0100
-+++ libunique-1.1.6/unique/uniquebackend.h 2011-10-12 01:21:56.512047875 +0100
-@@ -94,10 +94,10 @@
-
- UniqueBackend * unique_backend_create (void);
-
--G_CONST_RETURN gchar *unique_backend_get_name (UniqueBackend *backend);
-+const gchar *unique_backend_get_name (UniqueBackend *backend);
- void unique_backend_set_name (UniqueBackend *backend,
- const gchar *name);
--G_CONST_RETURN gchar *unique_backend_get_startup_id (UniqueBackend *backend);
-+const gchar *unique_backend_get_startup_id (UniqueBackend *backend);
- void unique_backend_set_startup_id (UniqueBackend *backend,
- const gchar *startup_id);
- GdkScreen * unique_backend_get_screen (UniqueBackend *backend);
-Index: libunique-1.1.6/unique/uniqueinternals.h
-===================================================================
---- libunique-1.1.6.orig/unique/uniqueinternals.h 2011-10-12 01:21:25.892046532 +0100
-+++ libunique-1.1.6/unique/uniqueinternals.h 2011-10-12 01:21:56.512047875 +0100
-@@ -44,11 +44,11 @@
- * and then back into an id
- */
- UniqueResponse unique_response_from_string (const gchar *response);
--G_CONST_RETURN gchar *unique_response_to_string (UniqueResponse response);
-+const gchar *unique_response_to_string (UniqueResponse response);
-
- gint unique_command_from_string (UniqueApp *app,
- const gchar *command);
--G_CONST_RETURN gchar *unique_command_to_string (UniqueApp *app,
-+const gchar *unique_command_to_string (UniqueApp *app,
- gint command);
-
- G_END_DECLS
-Index: libunique-1.1.6/unique/uniquemessage.c
-===================================================================
---- libunique-1.1.6.orig/unique/uniquemessage.c 2011-10-12 01:21:25.942046524 +0100
-+++ libunique-1.1.6/unique/uniquemessage.c 2011-10-12 01:21:55.072046595 +0100
-@@ -185,7 +185,7 @@
- *
- * Since: 1.0.2
- */
--G_CONST_RETURN guchar *
-+const guchar *
- unique_message_data_get (UniqueMessageData *message_data,
- gsize *length)
- {
-@@ -525,7 +525,7 @@
- * owned by the #UniqueMessageData structure and should not be
- * modified or freed
- */
--G_CONST_RETURN gchar *
-+const gchar *
- unique_message_data_get_startup_id (UniqueMessageData *message_data)
- {
- g_return_val_if_fail (message_data != NULL, NULL);
-Index: libunique-1.1.6/unique/uniquemessage.h
-===================================================================
---- libunique-1.1.6.orig/unique/uniquemessage.h 2011-10-12 01:21:25.792046596 +0100
-+++ libunique-1.1.6/unique/uniquemessage.h 2011-10-12 01:21:56.512047875 +0100
-@@ -48,7 +48,7 @@
- void unique_message_data_set (UniqueMessageData *message_data,
- const guchar *data,
- gsize length);
--G_CONST_RETURN guchar *unique_message_data_get (UniqueMessageData *message_data,
-+const guchar *unique_message_data_get (UniqueMessageData *message_data,
- gsize *length);
-
- gboolean unique_message_data_set_text (UniqueMessageData *message_data,
-@@ -63,7 +63,7 @@
- gchar * unique_message_data_get_filename (UniqueMessageData *message_data);
-
- GdkScreen * unique_message_data_get_screen (UniqueMessageData *message_data);
--G_CONST_RETURN gchar * unique_message_data_get_startup_id (UniqueMessageData *message_data);
-+const gchar * unique_message_data_get_startup_id (UniqueMessageData *message_data);
- guint unique_message_data_get_workspace (UniqueMessageData *message_data);
-
- G_END_DECLS
diff --git a/meta/recipes-gnome/libunique/libunique_1.1.6.bb b/meta/recipes-gnome/libunique/libunique_1.1.6.bb
deleted file mode 100644
index d97d1d6..0000000
--- a/meta/recipes-gnome/libunique/libunique_1.1.6.bb
+++ /dev/null
@@ -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
--
2.1.4
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 06/12] mkelfimage: add RECIPE_NO_UPDATE_REASON
2015-09-03 15:34 [PATCH 00/12] Various package/RRS updates Alexander Kanavin
` (4 preceding siblings ...)
2015-09-03 15:34 ` [PATCH 05/12] libunique: " Alexander Kanavin
@ 2015-09-03 15:34 ` Alexander Kanavin
2015-09-03 15:34 ` [PATCH 07/12] python-async: update to 0.6.2 Alexander Kanavin
` (5 subsequent siblings)
11 siblings, 0 replies; 30+ messages in thread
From: Alexander Kanavin @ 2015-09-03 15:34 UTC (permalink / raw)
To: openembedded-core
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
---
meta/recipes-devtools/mkelfimage/mkelfimage_git.bb | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-devtools/mkelfimage/mkelfimage_git.bb b/meta/recipes-devtools/mkelfimage/mkelfimage_git.bb
index 28aff91..2845b8c 100644
--- a/meta/recipes-devtools/mkelfimage/mkelfimage_git.bb
+++ b/meta/recipes-devtools/mkelfimage/mkelfimage_git.bb
@@ -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"
--
2.1.4
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 07/12] python-async: update to 0.6.2
2015-09-03 15:34 [PATCH 00/12] Various package/RRS updates Alexander Kanavin
` (5 preceding siblings ...)
2015-09-03 15:34 ` [PATCH 06/12] mkelfimage: add RECIPE_NO_UPDATE_REASON Alexander Kanavin
@ 2015-09-03 15:34 ` Alexander Kanavin
2015-09-03 15:34 ` [PATCH 08/12] python-smmap: update to 0.9.0 Alexander Kanavin
` (4 subsequent siblings)
11 siblings, 0 replies; 30+ messages in thread
From: Alexander Kanavin @ 2015-09-03 15:34 UTC (permalink / raw)
To: openembedded-core
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
---
.../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%)
diff --git a/meta/recipes-devtools/python/python-async_0.6.1.bb b/meta/recipes-devtools/python/python-async_0.6.2.bb
similarity index 77%
rename from meta/recipes-devtools/python/python-async_0.6.1.bb
rename to meta/recipes-devtools/python/python-async_0.6.2.bb
index 1794820..8ed0b03 100644
--- a/meta/recipes-devtools/python/python-async_0.6.1.bb
+++ b/meta/recipes-devtools/python/python-async_0.6.2.bb
@@ -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}"
--
2.1.4
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 08/12] python-smmap: update to 0.9.0
2015-09-03 15:34 [PATCH 00/12] Various package/RRS updates Alexander Kanavin
` (6 preceding siblings ...)
2015-09-03 15:34 ` [PATCH 07/12] python-async: update to 0.6.2 Alexander Kanavin
@ 2015-09-03 15:34 ` Alexander Kanavin
2015-09-03 15:34 ` [PATCH 09/12] remake: update to 4.1+dbg-1.1 Alexander Kanavin
` (3 subsequent siblings)
11 siblings, 0 replies; 30+ messages in thread
From: Alexander Kanavin @ 2015-09-03 15:34 UTC (permalink / raw)
To: openembedded-core
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
---
.../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%)
diff --git a/meta/recipes-devtools/python/python-smmap_0.8.2.bb b/meta/recipes-devtools/python/python-smmap_0.9.0.bb
similarity index 82%
rename from meta/recipes-devtools/python/python-smmap_0.8.2.bb
rename to meta/recipes-devtools/python/python-smmap_0.9.0.bb
index 64f812d..b658be8 100644
--- a/meta/recipes-devtools/python/python-smmap_0.8.2.bb
+++ b/meta/recipes-devtools/python/python-smmap_0.9.0.bb
@@ -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}"
--
2.1.4
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 09/12] remake: update to 4.1+dbg-1.1
2015-09-03 15:34 [PATCH 00/12] Various package/RRS updates Alexander Kanavin
` (7 preceding siblings ...)
2015-09-03 15:34 ` [PATCH 08/12] python-smmap: update to 0.9.0 Alexander Kanavin
@ 2015-09-03 15:34 ` Alexander Kanavin
2015-09-03 15:34 ` [PATCH 10/12] uclibc: update PV to 0.9.33.2 to match latest upstream release Alexander Kanavin
` (2 subsequent siblings)
11 siblings, 0 replies; 30+ messages in thread
From: Alexander Kanavin @ 2015-09-03 15:34 UTC (permalink / raw)
To: openembedded-core
remake-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
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
---
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%)
diff --git a/meta/recipes-devtools/remake/remake.inc b/meta/recipes-devtools/remake/remake.inc
index 6ac833e..df889fc 100644
--- a/meta/recipes-devtools/remake/remake.inc
+++ b/meta/recipes-devtools/remake/remake.inc
@@ -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"
diff --git a/meta/recipes-devtools/remake/remake/remake-remove-errors-about-colophon-and-cygnus-comma.patch b/meta/recipes-devtools/remake/remake/remake-remove-errors-about-colophon-and-cygnus-comma.patch
deleted file mode 100644
index 98b6460..0000000
--- a/meta/recipes-devtools/remake/remake/remake-remove-errors-about-colophon-and-cygnus-comma.patch
+++ /dev/null
@@ -1,39 +0,0 @@
-From 1316f10a97a4a2f5d11a30ec367aa61101318742 Mon Sep 17 00:00:00 2001
-From: "Maxin B. John" <maxin.john@enea.com>
-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 <maxin.john@enea.com>
----
- 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: doc@cygnus.com, 1991.
-+% Blame: doc@@cygnus.com, 1991.
- @end tex
-
- @bye
---
-1.9.1
-
diff --git a/meta/recipes-devtools/remake/remake_git.bb b/meta/recipes-devtools/remake/remake_4.1+dbg-1.1.bb
similarity index 80%
rename from meta/recipes-devtools/remake/remake_git.bb
rename to meta/recipes-devtools/remake/remake_4.1+dbg-1.1.bb
index 2ba2b80..c61913d 100644
--- a/meta/recipes-devtools/remake/remake_git.bb
+++ b/meta/recipes-devtools/remake/remake_4.1+dbg-1.1.bb
@@ -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.
--
2.1.4
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 10/12] uclibc: update PV to 0.9.33.2 to match latest upstream release
2015-09-03 15:34 [PATCH 00/12] Various package/RRS updates Alexander Kanavin
` (8 preceding siblings ...)
2015-09-03 15:34 ` [PATCH 09/12] remake: update to 4.1+dbg-1.1 Alexander Kanavin
@ 2015-09-03 15:34 ` Alexander Kanavin
2015-09-03 20:14 ` Khem Raj
2015-09-03 15:34 ` [PATCH 11/12] vte: add RECIPE_NO_UPDATE_REASON Alexander Kanavin
2015-09-03 15:34 ` [PATCH 12/12] package_regex.inc: various updates to improve RRS accuracy Alexander Kanavin
11 siblings, 1 reply; 30+ messages in thread
From: Alexander Kanavin @ 2015-09-03 15:34 UTC (permalink / raw)
To: openembedded-core
This fixes upstream version check. The git revision that is fetched
is unchanged.
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
---
meta/recipes-core/uclibc/uclibc-git.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/uclibc/uclibc-git.inc b/meta/recipes-core/uclibc/uclibc-git.inc
index 14a577f..f4af36a 100644
--- a/meta/recipes-core/uclibc/uclibc-git.inc
+++ b/meta/recipes-core/uclibc/uclibc-git.inc
@@ -1,6 +1,6 @@
SRCREV = "ca1c74d67dd115d059a875150e10b8560a9c35a8"
-PV = "0.9.33+git${SRCPV}"
+PV = "0.9.33.2+git${SRCPV}"
FILESEXTRAPATHS =. "${FILE_DIRNAME}/uclibc-git:"
--
2.1.4
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 11/12] vte: add RECIPE_NO_UPDATE_REASON
2015-09-03 15:34 [PATCH 00/12] Various package/RRS updates Alexander Kanavin
` (9 preceding siblings ...)
2015-09-03 15:34 ` [PATCH 10/12] uclibc: update PV to 0.9.33.2 to match latest upstream release Alexander Kanavin
@ 2015-09-03 15:34 ` Alexander Kanavin
2015-09-03 15:34 ` [PATCH 12/12] package_regex.inc: various updates to improve RRS accuracy Alexander Kanavin
11 siblings, 0 replies; 30+ messages in thread
From: Alexander Kanavin @ 2015-09-03 15:34 UTC (permalink / raw)
To: openembedded-core
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
---
meta/recipes-support/vte/vte_0.28.2.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-support/vte/vte_0.28.2.bb b/meta/recipes-support/vte/vte_0.28.2.bb
index 68bc16d..b1025cb 100644
--- a/meta/recipes-support/vte/vte_0.28.2.bb
+++ b/meta/recipes-support/vte/vte_0.28.2.bb
@@ -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"
--
2.1.4
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 12/12] package_regex.inc: various updates to improve RRS accuracy
2015-09-03 15:34 [PATCH 00/12] Various package/RRS updates Alexander Kanavin
` (10 preceding siblings ...)
2015-09-03 15:34 ` [PATCH 11/12] vte: add RECIPE_NO_UPDATE_REASON Alexander Kanavin
@ 2015-09-03 15:34 ` Alexander Kanavin
11 siblings, 0 replies; 30+ messages in thread
From: Alexander Kanavin @ 2015-09-03 15:34 UTC (permalink / raw)
To: openembedded-core
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
---
meta/conf/distro/include/package_regex.inc | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/meta/conf/distro/include/package_regex.inc b/meta/conf/distro/include/package_regex.inc
index df384e2..8fc112c 100644
--- a/meta/conf/distro/include/package_regex.inc
+++ b/meta/conf/distro/include/package_regex.inc
@@ -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}"
--
2.1.4
^ permalink raw reply related [flat|nested] 30+ messages in thread