* [CONSOLIDATED PULL 00/16] Various Updates
@ 2011-10-19 8:28 Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 01/16] poky: fix broken ubifs link in deploy folder Saul Wold
` (15 more replies)
0 siblings, 16 replies; 38+ messages in thread
From: Saul Wold @ 2011-10-19 8:28 UTC (permalink / raw)
To: openembedded-core
Richard,
This set include upgrades from Khem for GCC along with Nitin for various
toolchain items. There are also some other good updates from Josh.
Please look at the change from Otavio for src_distrubute, It looks good
to me, but need another set of eyes on code.
Thanks
Sau!
The following changes since commit e31dd9b65f3b03f79cabab25eca157532de3bd9c:
fontconfig: fix fix-pkgconfig.patch (2011-10-18 18:13:47 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib sgw/stage
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/stage
Darren Hart (1):
insane.bbclass: print full path on invalid LICENSE_FILES_CHKSUM
Joshua Lock (2):
gst-plugins-good: update to 0.10.30
tzdata: updated SRC_URI and update to 2011k
Khem Raj (3):
bluez4: Add glib-2.0 to DEPENDS
gcc-4.6: Upgrade SRCREV to latest FSF 4.6 branch
gcc-4.6: Backport PR46934 fix
Lauri Hintsala (1):
poky: fix broken ubifs link in deploy folder
Nitin A Kamble (6):
x86 tune files: set baselib for x32 tune as libx32
gmp: also generate the libgmpcxx library
python-scons: upgrade from 2.0.1 to 2.1.0
python-dbus: upgrade from 0.83.2 to 0.84.0
libxml-parser-perl: upgrade from 2.40 to 2.41
distro-tracking: update data for some toolchain recipes
Otavio Salvador (1):
src_distribute.bbclass, src_distribute_local.bbclass: mostly
rewritten
Saul Wold (2):
ghostscript: Disable parallel make due to install issues
ghostscript: renamed x86_64 to x86-64 for patch to work
meta/classes/image_types.bbclass | 2 +-
meta/classes/insane.bbclass | 2 +-
meta/classes/src_distribute.bbclass | 54 ++-
meta/classes/src_distribute_local.bbclass | 28 +-
.../conf/distro/include/distro_tracking_fields.inc | 42 ++-
meta/conf/machine/include/ia32/arch-ia32.inc | 2 +-
meta/conf/machine/include/tune-core2.inc | 2 +-
meta/recipes-connectivity/bluez/bluez4.inc | 2 +-
meta/recipes-connectivity/bluez/bluez4_4.96.bb | 2 +-
meta/recipes-devtools/gcc/gcc-4.6.inc | 5 +-
meta/recipes-devtools/gcc/gcc-4.6/pr46934.patch | 392 ++++++++++++++++++++
...ser-perl_2.40.bb => libxml-parser-perl_2.41.bb} | 6 +-
...python-dbus_0.83.2.bb => python-dbus_0.84.0.bb} | 4 +-
...ative_2.0.1.bb => python-scons-native_2.1.0.bb} | 3 +-
...python-scons_2.0.1.bb => python-scons_2.1.0.bb} | 6 +-
.../ghostscript/{x86_64 => x86-64}/objarch.h | 0
.../ghostscript/{x86_64 => x86-64}/soobjarch.h | 0
.../ghostscript/ghostscript_9.02.bb | 4 +
.../tzdata/{tzdata_2011k.bb => tzdata_2011l.bb} | 6 +-
...good_0.10.28.bb => gst-plugins-good_0.10.30.bb} | 4 +-
meta/recipes-support/gmp/gmp.inc | 2 +
meta/recipes-support/gmp/gmp_4.2.1.bb | 2 +-
meta/recipes-support/gmp/gmp_5.0.2.bb | 2 +-
23 files changed, 500 insertions(+), 72 deletions(-)
create mode 100644 meta/recipes-devtools/gcc/gcc-4.6/pr46934.patch
rename meta/recipes-devtools/perl/{libxml-parser-perl_2.40.bb => libxml-parser-perl_2.41.bb} (82%)
rename meta/recipes-devtools/python/{python-dbus_0.83.2.bb => python-dbus_0.84.0.bb} (83%)
rename meta/recipes-devtools/python/{python-scons-native_2.0.1.bb => python-scons-native_2.1.0.bb} (89%)
rename meta/recipes-devtools/python/{python-scons_2.0.1.bb => python-scons_2.1.0.bb} (51%)
rename meta/recipes-extended/ghostscript/ghostscript/{x86_64 => x86-64}/objarch.h (100%)
rename meta/recipes-extended/ghostscript/ghostscript/{x86_64 => x86-64}/soobjarch.h (100%)
rename meta/recipes-extended/tzdata/{tzdata_2011k.bb => tzdata_2011l.bb} (96%)
rename meta/recipes-multimedia/gstreamer/{gst-plugins-good_0.10.28.bb => gst-plugins-good_0.10.30.bb} (84%)
--
1.7.6.2
^ permalink raw reply [flat|nested] 38+ messages in thread
* [CONSOLIDATED PULL 01/16] poky: fix broken ubifs link in deploy folder
2011-10-19 8:28 [CONSOLIDATED PULL 00/16] Various Updates Saul Wold
@ 2011-10-19 8:28 ` Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 02/16] bluez4: Add glib-2.0 to DEPENDS Saul Wold
` (14 subsequent siblings)
15 siblings, 0 replies; 38+ messages in thread
From: Saul Wold @ 2011-10-19 8:28 UTC (permalink / raw)
To: openembedded-core
From: Lauri Hintsala <lauri.hintsala@bluegiga.com>
Fix broken rootfs image link when ubifs is used.
Function runimagecmd is using image name "${IMAGE_NAME}.rootfs.${type}".
Let's use the same name in IMAGE_CMD_ubifs.
Signed-off-by: Lauri Hintsala <lauri.hintsala@bluegiga.com>
---
meta/classes/image_types.bbclass | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 2260915..0d64705 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -125,7 +125,7 @@ IMAGE_CMD_ubi () {
echo vol_flags=autoresize >> ubinize.cfg
mkfs.ubifs -r ${IMAGE_ROOTFS} -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs ${MKUBIFS_ARGS} && ubinize -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubi ${UBINIZE_ARGS} ubinize.cfg
}
-IMAGE_CMD_ubifs = "mkfs.ubifs -r ${IMAGE_ROOTFS} -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.ubifs.img ${MKUBIFS_ARGS}"
+IMAGE_CMD_ubifs = "mkfs.ubifs -r ${IMAGE_ROOTFS} -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs ${MKUBIFS_ARGS}"
EXTRA_IMAGECMD = ""
EXTRA_IMAGECMD_jffs2 ?= "--pad --little-endian --eraseblock=0x40000"
--
1.7.6.2
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [CONSOLIDATED PULL 02/16] bluez4: Add glib-2.0 to DEPENDS
2011-10-19 8:28 [CONSOLIDATED PULL 00/16] Various Updates Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 01/16] poky: fix broken ubifs link in deploy folder Saul Wold
@ 2011-10-19 8:28 ` Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 03/16] gcc-4.6: Upgrade SRCREV to latest FSF 4.6 branch Saul Wold
` (13 subsequent siblings)
15 siblings, 0 replies; 38+ messages in thread
From: Saul Wold @ 2011-10-19 8:28 UTC (permalink / raw)
To: openembedded-core
From: Khem Raj <raj.khem@gmail.com>
Fixes
| attrib/utils.c:25:18: fatal error: glib.h: No such file or directory
| compilation terminated.
| make[1]: *** [attrib/utils.o] Error 1
| make[1]: *** Waiting for unfinished jobs....
| attrib/interactive.c:27:18: fatal error: glib.h: No such file or
directory
| compilation terminated.
| make[1]: *** [attrib/interactive.o] Error 1
| make: *** [all] Error 2
Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
meta/recipes-connectivity/bluez/bluez4.inc | 2 +-
meta/recipes-connectivity/bluez/bluez4_4.96.bb | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-connectivity/bluez/bluez4.inc b/meta/recipes-connectivity/bluez/bluez4.inc
index fc515f6..9158687 100644
--- a/meta/recipes-connectivity/bluez/bluez4.inc
+++ b/meta/recipes-connectivity/bluez/bluez4.inc
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
file://COPYING.LIB;md5=fb504b67c50331fc78734fed90fb0e09 \
file://src/main.c;beginline=1;endline=24;md5=9bc54b93cd7e17bf03f52513f39f926e \
file://sbc/sbc.c;beginline=1;endline=25;md5=1a40781ed30d50d8639323a184aeb191"
-DEPENDS = "udev alsa-lib libusb dbus-glib"
+DEPENDS = "udev alsa-lib libusb dbus-glib glib-2.0"
RDEPENDS_${PN}-dev = "bluez-hcidump"
ASNEEDED = ""
diff --git a/meta/recipes-connectivity/bluez/bluez4_4.96.bb b/meta/recipes-connectivity/bluez/bluez4_4.96.bb
index 52268cf..88ec7a4 100644
--- a/meta/recipes-connectivity/bluez/bluez4_4.96.bb
+++ b/meta/recipes-connectivity/bluez/bluez4_4.96.bb
@@ -1,6 +1,6 @@
require bluez4.inc
-PR = "r3"
+PR = "r4"
SRC_URI += "file://bluetooth.conf"
--
1.7.6.2
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [CONSOLIDATED PULL 03/16] gcc-4.6: Upgrade SRCREV to latest FSF 4.6 branch
2011-10-19 8:28 [CONSOLIDATED PULL 00/16] Various Updates Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 01/16] poky: fix broken ubifs link in deploy folder Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 02/16] bluez4: Add glib-2.0 to DEPENDS Saul Wold
@ 2011-10-19 8:28 ` Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 04/16] gcc-4.6: Backport PR46934 fix Saul Wold
` (12 subsequent siblings)
15 siblings, 0 replies; 38+ messages in thread
From: Saul Wold @ 2011-10-19 8:28 UTC (permalink / raw)
To: openembedded-core
From: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
meta/recipes-devtools/gcc/gcc-4.6.inc | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc b/meta/recipes-devtools/gcc/gcc-4.6.inc
index 8ca3174..0fb6287 100644
--- a/meta/recipes-devtools/gcc/gcc-4.6.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.6.inc
@@ -18,7 +18,7 @@ PV = "4.6.1+svnr${SRCPV}"
BINV = "4.6.2"
-SRCREV = 178924
+SRCREV = 180099
BRANCH = "gcc-4_6-branch"
FILESPATH = "${@base_set_filespath([ '${FILE_DIRNAME}/gcc-4.6' ], d)}"
--
1.7.6.2
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [CONSOLIDATED PULL 04/16] gcc-4.6: Backport PR46934 fix
2011-10-19 8:28 [CONSOLIDATED PULL 00/16] Various Updates Saul Wold
` (2 preceding siblings ...)
2011-10-19 8:28 ` [CONSOLIDATED PULL 03/16] gcc-4.6: Upgrade SRCREV to latest FSF 4.6 branch Saul Wold
@ 2011-10-19 8:28 ` Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 05/16] ghostscript: Disable parallel make due to install issues Saul Wold
` (11 subsequent siblings)
15 siblings, 0 replies; 38+ messages in thread
From: Saul Wold @ 2011-10-19 8:28 UTC (permalink / raw)
To: openembedded-core
From: Khem Raj <raj.khem@gmail.com>
We have been hitting this issue on ARM/thumb and
have a workaround in place to compile samba
http://git.openembedded.org/openembedded/commit/recipes/samba/samba_3.2.15.bb?id=4ba7aa07c0dcd28f94515ff9927e2a04403fcf15
This backport should fix the gcc bug
Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
meta/recipes-devtools/gcc/gcc-4.6.inc | 3 +-
meta/recipes-devtools/gcc/gcc-4.6/pr46934.patch | 392 +++++++++++++++++++++++
2 files changed, 394 insertions(+), 1 deletions(-)
create mode 100644 meta/recipes-devtools/gcc/gcc-4.6/pr46934.patch
diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc b/meta/recipes-devtools/gcc/gcc-4.6.inc
index 0fb6287..fbc90ea 100644
--- a/meta/recipes-devtools/gcc/gcc-4.6.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.6.inc
@@ -1,6 +1,6 @@
require gcc-common.inc
-PR = "r14"
+PR = "r15"
# Third digit in PV should be incremented after a minor release
# happens from this branch on gcc e.g. currently its 4.6.0
@@ -69,6 +69,7 @@ SRC_URI = "svn://gcc.gnu.org/svn/gcc/branches;module=${BRANCH};proto=http \
file://powerpc-e5500.patch \
file://fix-for-ice-50099.patch \
file://gcc-with-linker-hash-style.patch \
+ file://pr46934.patch \
"
SRC_URI_append_sh3 = " file://sh3-installfix-fixheaders.patch "
diff --git a/meta/recipes-devtools/gcc/gcc-4.6/pr46934.patch b/meta/recipes-devtools/gcc/gcc-4.6/pr46934.patch
new file mode 100644
index 0000000..afd3eef
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-4.6/pr46934.patch
@@ -0,0 +1,392 @@
+2011-09-19 chengbin <bin.cheng@arm.com>
+
+ Backport r174035 from mainline
+ 2011-05-22 Tom de Vries <tom@codesourcery.com>
+
+ PR middle-end/48689
+ * fold-const.c (fold_checksum_tree): Guard TREE_CHAIN use with
+ CODE_CONTAINS_STRUCT (TS_COMMON).
+
+ Backport r172297 from mainline
+ 2011-04-11 Chung-Lin Tang <cltang@codesourcery.com>
+ Richard Earnshaw <rearnsha@arm.com>
+
+ PR target/48250
+ * config/arm/arm.c (arm_legitimize_reload_address): Update cases
+ to use sign-magnitude offsets. Reject unsupported unaligned
+ cases. Add detailed description in comments.
+ * config/arm/arm.md (reload_outdf): Disable for ARM mode; change
+ condition from TARGET_32BIT to TARGET_ARM.
+
+ Backport r171978 from mainline
+ 2011-04-05 Tom de Vries <tom@codesourcery.com>
+
+ PR target/43920
+ * config/arm/arm.h (BRANCH_COST): Set to 1 for Thumb-2 when optimizing
+ for size.
+
+ Backport r171632 from mainline
+ 2011-03-28 Richard Sandiford <richard.sandiford@linaro.org>
+
+ * builtins.c (expand_builtin_memset_args): Use gen_int_mode
+ instead of GEN_INT.
+
+ Backport r171379 from mainline
+ 2011-03-23 Chung-Lin Tang <cltang@codesourcery.com>
+
+ PR target/46934
+ * config/arm/arm.md (casesi): Use the gen_int_mode() function
+ to subtract lower bound instead of GEN_INT().
+
+ Backport r171251 from mainline
+ 2011-03-21 Daniel Jacobowitz <dan@codesourcery.com>
+
+ * config/arm/unwind-arm.c (__gnu_unwind_pr_common): Correct test
+ for barrier handlers.
+
+ Backport r171096 from mainline
+ 2011-03-17 Chung-Lin Tang <cltang@codesourcery.com>
+
+ PR target/43872
+ * config/arm/arm.c (arm_get_frame_offsets): Adjust early
+ return condition with !cfun->calls_alloca.
+
+Index: gcc-4_6-branch/gcc/builtins.c
+===================================================================
+--- gcc-4_6-branch.orig/gcc/builtins.c 2011-10-17 17:45:32.050502963 -0700
++++ gcc-4_6-branch/gcc/builtins.c 2011-10-17 17:46:11.154696878 -0700
+@@ -3972,6 +3972,7 @@
+ {
+ tree fndecl, fn;
+ enum built_in_function fcode;
++ enum machine_mode val_mode;
+ char c;
+ unsigned int dest_align;
+ rtx dest_mem, dest_addr, len_rtx;
+@@ -4006,14 +4007,14 @@
+
+ len_rtx = expand_normal (len);
+ dest_mem = get_memory_rtx (dest, len);
++ val_mode = TYPE_MODE (unsigned_char_type_node);
+
+ if (TREE_CODE (val) != INTEGER_CST)
+ {
+ rtx val_rtx;
+
+ val_rtx = expand_normal (val);
+- val_rtx = convert_to_mode (TYPE_MODE (unsigned_char_type_node),
+- val_rtx, 0);
++ val_rtx = convert_to_mode (val_mode, val_rtx, 0);
+
+ /* Assume that we can memset by pieces if we can store
+ * the coefficients by pieces (in the required modes).
+@@ -4024,8 +4025,7 @@
+ builtin_memset_read_str, &c, dest_align,
+ true))
+ {
+- val_rtx = force_reg (TYPE_MODE (unsigned_char_type_node),
+- val_rtx);
++ val_rtx = force_reg (val_mode, val_rtx);
+ store_by_pieces (dest_mem, tree_low_cst (len, 1),
+ builtin_memset_gen_str, val_rtx, dest_align,
+ true, 0);
+@@ -4051,7 +4051,8 @@
+ true))
+ store_by_pieces (dest_mem, tree_low_cst (len, 1),
+ builtin_memset_read_str, &c, dest_align, true, 0);
+- else if (!set_storage_via_setmem (dest_mem, len_rtx, GEN_INT (c),
++ else if (!set_storage_via_setmem (dest_mem, len_rtx,
++ gen_int_mode (c, val_mode),
+ dest_align, expected_align,
+ expected_size))
+ goto do_libcall;
+Index: gcc-4_6-branch/gcc/config/arm/arm.c
+===================================================================
+--- gcc-4_6-branch.orig/gcc/config/arm/arm.c 2011-10-17 17:45:41.914551883 -0700
++++ gcc-4_6-branch/gcc/config/arm/arm.c 2011-10-17 17:48:35.447412371 -0700
+@@ -6406,23 +6406,126 @@
+ HOST_WIDE_INT val = INTVAL (XEXP (*p, 1));
+ HOST_WIDE_INT low, high;
+
+- if (mode == DImode || (mode == DFmode && TARGET_SOFT_FLOAT))
+- low = ((val & 0xf) ^ 0x8) - 0x8;
+- else if (TARGET_MAVERICK && TARGET_HARD_FLOAT)
+- /* Need to be careful, -256 is not a valid offset. */
+- low = val >= 0 ? (val & 0xff) : -((-val) & 0xff);
+- else if (mode == SImode
+- || (mode == SFmode && TARGET_SOFT_FLOAT)
+- || ((mode == HImode || mode == QImode) && ! arm_arch4))
+- /* Need to be careful, -4096 is not a valid offset. */
+- low = val >= 0 ? (val & 0xfff) : -((-val) & 0xfff);
+- else if ((mode == HImode || mode == QImode) && arm_arch4)
+- /* Need to be careful, -256 is not a valid offset. */
+- low = val >= 0 ? (val & 0xff) : -((-val) & 0xff);
+- else if (GET_MODE_CLASS (mode) == MODE_FLOAT
+- && TARGET_HARD_FLOAT && TARGET_FPA)
+- /* Need to be careful, -1024 is not a valid offset. */
+- low = val >= 0 ? (val & 0x3ff) : -((-val) & 0x3ff);
++ /* Detect coprocessor load/stores. */
++ bool coproc_p = ((TARGET_HARD_FLOAT
++ && (TARGET_VFP || TARGET_FPA || TARGET_MAVERICK)
++ && (mode == SFmode || mode == DFmode
++ || (mode == DImode && TARGET_MAVERICK)))
++ || (TARGET_REALLY_IWMMXT
++ && VALID_IWMMXT_REG_MODE (mode))
++ || (TARGET_NEON
++ && (VALID_NEON_DREG_MODE (mode)
++ || VALID_NEON_QREG_MODE (mode))));
++
++ /* For some conditions, bail out when lower two bits are unaligned. */
++ if ((val & 0x3) != 0
++ /* Coprocessor load/store indexes are 8-bits + '00' appended. */
++ && (coproc_p
++ /* For DI, and DF under soft-float: */
++ || ((mode == DImode || mode == DFmode)
++ /* Without ldrd, we use stm/ldm, which does not
++ fair well with unaligned bits. */
++ && (! TARGET_LDRD
++ /* Thumb-2 ldrd/strd is [-1020,+1020] in steps of 4. */
++ || TARGET_THUMB2))))
++ return false;
++
++ /* When breaking down a [reg+index] reload address into [(reg+high)+low],
++ of which the (reg+high) gets turned into a reload add insn,
++ we try to decompose the index into high/low values that can often
++ also lead to better reload CSE.
++ For example:
++ ldr r0, [r2, #4100] // Offset too large
++ ldr r1, [r2, #4104] // Offset too large
++
++ is best reloaded as:
++ add t1, r2, #4096
++ ldr r0, [t1, #4]
++ add t2, r2, #4096
++ ldr r1, [t2, #8]
++
++ which post-reload CSE can simplify in most cases to eliminate the
++ second add instruction:
++ add t1, r2, #4096
++ ldr r0, [t1, #4]
++ ldr r1, [t1, #8]
++
++ The idea here is that we want to split out the bits of the constant
++ as a mask, rather than as subtracting the maximum offset that the
++ respective type of load/store used can handle.
++
++ When encountering negative offsets, we can still utilize it even if
++ the overall offset is positive; sometimes this may lead to an immediate
++ that can be constructed with fewer instructions.
++ For example:
++ ldr r0, [r2, #0x3FFFFC]
++
++ This is best reloaded as:
++ add t1, r2, #0x400000
++ ldr r0, [t1, #-4]
++
++ The trick for spotting this for a load insn with N bits of offset
++ (i.e. bits N-1:0) is to look at bit N; if it is set, then chose a
++ negative offset that is going to make bit N and all the bits below
++ it become zero in the remainder part.
++
++ The SIGN_MAG_LOW_ADDR_BITS macro below implements this, with respect
++ to sign-magnitude addressing (i.e. separate +- bit, or 1's complement),
++ used in most cases of ARM load/store instructions. */
++
++#define SIGN_MAG_LOW_ADDR_BITS(VAL, N) \
++ (((VAL) & ((1 << (N)) - 1)) \
++ ? (((VAL) & ((1 << ((N) + 1)) - 1)) ^ (1 << (N))) - (1 << (N)) \
++ : 0)
++
++ if (coproc_p)
++ low = SIGN_MAG_LOW_ADDR_BITS (val, 10);
++ else if (GET_MODE_SIZE (mode) == 8)
++ {
++ if (TARGET_LDRD)
++ low = (TARGET_THUMB2
++ ? SIGN_MAG_LOW_ADDR_BITS (val, 10)
++ : SIGN_MAG_LOW_ADDR_BITS (val, 8));
++ else
++ /* For pre-ARMv5TE (without ldrd), we use ldm/stm(db/da/ib)
++ to access doublewords. The supported load/store offsets are
++ -8, -4, and 4, which we try to produce here. */
++ low = ((val & 0xf) ^ 0x8) - 0x8;
++ }
++ else if (GET_MODE_SIZE (mode) < 8)
++ {
++ /* NEON element load/stores do not have an offset. */
++ if (TARGET_NEON_FP16 && mode == HFmode)
++ return false;
++
++ if (TARGET_THUMB2)
++ {
++ /* Thumb-2 has an asymmetrical index range of (-256,4096).
++ Try the wider 12-bit range first, and re-try if the result
++ is out of range. */
++ low = SIGN_MAG_LOW_ADDR_BITS (val, 12);
++ if (low < -255)
++ low = SIGN_MAG_LOW_ADDR_BITS (val, 8);
++ }
++ else
++ {
++ if (mode == HImode || mode == HFmode)
++ {
++ if (arm_arch4)
++ low = SIGN_MAG_LOW_ADDR_BITS (val, 8);
++ else
++ {
++ /* The storehi/movhi_bytes fallbacks can use only
++ [-4094,+4094] of the full ldrb/strb index range. */
++ low = SIGN_MAG_LOW_ADDR_BITS (val, 12);
++ if (low == 4095 || low == -4095)
++ return false;
++ }
++ }
++ else
++ low = SIGN_MAG_LOW_ADDR_BITS (val, 12);
++ }
++ }
+ else
+ return false;
+
+@@ -15415,7 +15518,10 @@
+ offsets->soft_frame = offsets->saved_regs + CALLER_INTERWORKING_SLOT_SIZE;
+ /* A leaf function does not need any stack alignment if it has nothing
+ on the stack. */
+- if (leaf && frame_size == 0)
++ if (leaf && frame_size == 0
++ /* However if it calls alloca(), we have a dynamically allocated
++ block of BIGGEST_ALIGNMENT on stack, so still do stack alignment. */
++ && ! cfun->calls_alloca)
+ {
+ offsets->outgoing_args = offsets->soft_frame;
+ offsets->locals_base = offsets->soft_frame;
+Index: gcc-4_6-branch/gcc/config/arm/arm.h
+===================================================================
+--- gcc-4_6-branch.orig/gcc/config/arm/arm.h 2011-10-17 17:45:41.910551858 -0700
++++ gcc-4_6-branch/gcc/config/arm/arm.h 2011-10-17 17:48:35.447412371 -0700
+@@ -2041,7 +2041,8 @@
+ /* Try to generate sequences that don't involve branches, we can then use
+ conditional instructions */
+ #define BRANCH_COST(speed_p, predictable_p) \
+- (TARGET_32BIT ? 4 : (optimize > 0 ? 2 : 0))
++ (TARGET_32BIT ? (TARGET_THUMB2 && !speed_p ? 1 : 4) \
++ : (optimize > 0 ? 2 : 0))
+ \f
+ /* Position Independent Code. */
+ /* We decide which register to use based on the compilation options and
+Index: gcc-4_6-branch/gcc/config/arm/arm.md
+===================================================================
+--- gcc-4_6-branch.orig/gcc/config/arm/arm.md 2011-10-17 17:46:11.002696119 -0700
++++ gcc-4_6-branch/gcc/config/arm/arm.md 2011-10-17 17:46:11.202697111 -0700
+@@ -6187,7 +6187,7 @@
+ [(match_operand:DF 0 "arm_reload_memory_operand" "=o")
+ (match_operand:DF 1 "s_register_operand" "r")
+ (match_operand:SI 2 "s_register_operand" "=&r")]
+- "TARGET_32BIT"
++ "TARGET_THUMB2"
+ "
+ {
+ enum rtx_code code = GET_CODE (XEXP (operands[0], 0));
+@@ -8359,7 +8359,8 @@
+ rtx reg = gen_reg_rtx (SImode);
+
+ emit_insn (gen_addsi3 (reg, operands[0],
+- GEN_INT (-INTVAL (operands[1]))));
++ gen_int_mode (-INTVAL (operands[1]),
++ SImode)));
+ operands[0] = reg;
+ }
+
+Index: gcc-4_6-branch/gcc/config/arm/unwind-arm.c
+===================================================================
+--- gcc-4_6-branch.orig/gcc/config/arm/unwind-arm.c 2011-10-17 17:45:41.390549278 -0700
++++ gcc-4_6-branch/gcc/config/arm/unwind-arm.c 2011-10-17 17:46:11.000000000 -0700
+@@ -1196,8 +1196,6 @@
+ ucbp->barrier_cache.bitpattern[4] = (_uw) &data[1];
+
+ if (data[0] & uint32_highbit)
+- phase2_call_unexpected_after_unwind = 1;
+- else
+ {
+ data += rtti_count + 1;
+ /* Setup for entry to the handler. */
+@@ -1207,6 +1205,8 @@
+ _Unwind_SetGR (context, 0, (_uw) ucbp);
+ return _URC_INSTALL_CONTEXT;
+ }
++ else
++ phase2_call_unexpected_after_unwind = 1;
+ }
+ if (data[0] & uint32_highbit)
+ data++;
+Index: gcc-4_6-branch/gcc/fold-const.c
+===================================================================
+--- gcc-4_6-branch.orig/gcc/fold-const.c 2011-10-17 17:45:32.050502963 -0700
++++ gcc-4_6-branch/gcc/fold-const.c 2011-10-17 17:46:11.178696990 -0700
+@@ -13788,7 +13788,8 @@
+ if (TREE_CODE_CLASS (code) != tcc_type
+ && TREE_CODE_CLASS (code) != tcc_declaration
+ && code != TREE_LIST
+- && code != SSA_NAME)
++ && code != SSA_NAME
++ && CODE_CONTAINS_STRUCT (code, TS_COMMON))
+ fold_checksum_tree (TREE_CHAIN (expr), ctx, ht);
+ switch (TREE_CODE_CLASS (code))
+ {
+Index: gcc-4_6-branch/gcc/testsuite/gcc.target/arm/pr40887.c
+===================================================================
+--- gcc-4_6-branch.orig/gcc/testsuite/gcc.target/arm/pr40887.c 2011-06-24 08:13:47.000000000 -0700
++++ gcc-4_6-branch/gcc/testsuite/gcc.target/arm/pr40887.c 2011-10-17 17:46:11.182697014 -0700
+@@ -1,5 +1,6 @@
+ /* { dg-options "-O2 -march=armv5te" } */
+ /* { dg-final { scan-assembler "blx" } } */
++/* { dg-prune-output "switch .* conflicts with" } */
+
+ int (*indirect_func)();
+
+Index: gcc-4_6-branch/gcc/testsuite/gcc.target/arm/pr42575.c
+===================================================================
+--- gcc-4_6-branch.orig/gcc/testsuite/gcc.target/arm/pr42575.c 2011-06-24 08:13:47.000000000 -0700
++++ gcc-4_6-branch/gcc/testsuite/gcc.target/arm/pr42575.c 2011-10-17 17:46:11.182697014 -0700
+@@ -1,4 +1,4 @@
+-/* { dg-options "-O2 -march=armv7-a" } */
++/* { dg-options "-O2" } */
+ /* Make sure RA does good job allocating registers and avoids
+ unnecessary moves. */
+ /* { dg-final { scan-assembler-not "mov" } } */
+Index: gcc-4_6-branch/gcc/testsuite/gcc.target/arm/pr43698.c
+===================================================================
+--- gcc-4_6-branch.orig/gcc/testsuite/gcc.target/arm/pr43698.c 2011-06-24 08:13:47.000000000 -0700
++++ gcc-4_6-branch/gcc/testsuite/gcc.target/arm/pr43698.c 2011-10-17 17:46:11.182697014 -0700
+@@ -1,5 +1,5 @@
+ /* { dg-do run } */
+-/* { dg-options "-Os -march=armv7-a" } */
++/* { dg-options "-Os" } */
+ #include <stdint.h>
+ #include <stdlib.h>
+
+Index: gcc-4_6-branch/gcc/testsuite/gcc.target/arm/pr44788.c
+===================================================================
+--- gcc-4_6-branch.orig/gcc/testsuite/gcc.target/arm/pr44788.c 2011-06-24 08:13:47.000000000 -0700
++++ gcc-4_6-branch/gcc/testsuite/gcc.target/arm/pr44788.c 2011-10-17 17:46:11.182697014 -0700
+@@ -1,6 +1,6 @@
+ /* { dg-do compile } */
+ /* { dg-require-effective-target arm_thumb2_ok } */
+-/* { dg-options "-Os -fno-strict-aliasing -fPIC -mthumb -march=armv7-a -mfpu=vfp3 -mfloat-abi=softfp" } */
++/* { dg-options "-Os -fno-strict-aliasing -fPIC -mthumb -mfpu=vfp3 -mfloat-abi=softfp" } */
+
+ void joint_decode(float* mlt_buffer1, int t) {
+ int i;
+Index: gcc-4_6-branch/gcc/testsuite/gcc.target/arm/sync-1.c
+===================================================================
+--- gcc-4_6-branch.orig/gcc/testsuite/gcc.target/arm/sync-1.c 2011-06-24 08:13:47.000000000 -0700
++++ gcc-4_6-branch/gcc/testsuite/gcc.target/arm/sync-1.c 2011-10-17 17:46:11.182697014 -0700
+@@ -1,5 +1,6 @@
+-/* { dg-do run } */
+-/* { dg-options "-O2 -march=armv7-a" } */
++
++/* { dg-do run { target sync_int_long } } */
++/* { dg-options "-O2" } */
+
+ volatile int mem;
+
--
1.7.6.2
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [CONSOLIDATED PULL 05/16] ghostscript: Disable parallel make due to install issues
2011-10-19 8:28 [CONSOLIDATED PULL 00/16] Various Updates Saul Wold
` (3 preceding siblings ...)
2011-10-19 8:28 ` [CONSOLIDATED PULL 04/16] gcc-4.6: Backport PR46934 fix Saul Wold
@ 2011-10-19 8:28 ` Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 06/16] src_distribute.bbclass, src_distribute_local.bbclass: mostly rewritten Saul Wold
` (10 subsequent siblings)
15 siblings, 0 replies; 38+ messages in thread
From: Saul Wold @ 2011-10-19 8:28 UTC (permalink / raw)
To: openembedded-core
ghostscript uses a script called instcopy to install files first
to temp dir and then rm's and copies dirs|files to the final destination.
When parallel make happens multiple threads of this runs and tries to
remove existing directories with contents, not a good thing, therefore
disable parallel make for install.
Signed-off-by: Saul Wold <sgw@linux.intel.com>
---
.../ghostscript/ghostscript_9.02.bb | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-extended/ghostscript/ghostscript_9.02.bb b/meta/recipes-extended/ghostscript/ghostscript_9.02.bb
index 9b21c66..1d48cce 100644
--- a/meta/recipes-extended/ghostscript/ghostscript_9.02.bb
+++ b/meta/recipes-extended/ghostscript/ghostscript_9.02.bb
@@ -90,3 +90,7 @@ do_install_virtclass-native () {
}
BBCLASSEXTEND = "native"
+
+# Ghostscript install tool 'instcopy' tries to remove already created
+# directories during install and parallel make causes problems.
+PARALLEL_MAKEINST=""
--
1.7.6.2
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [CONSOLIDATED PULL 06/16] src_distribute.bbclass, src_distribute_local.bbclass: mostly rewritten
2011-10-19 8:28 [CONSOLIDATED PULL 00/16] Various Updates Saul Wold
` (4 preceding siblings ...)
2011-10-19 8:28 ` [CONSOLIDATED PULL 05/16] ghostscript: Disable parallel make due to install issues Saul Wold
@ 2011-10-19 8:28 ` Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 07/16] ghostscript: renamed x86_64 to x86-64 for patch to work Saul Wold
` (9 subsequent siblings)
15 siblings, 0 replies; 38+ messages in thread
From: Saul Wold @ 2011-10-19 8:28 UTC (permalink / raw)
To: openembedded-core
From: Otavio Salvador <otavio@ossystems.com.br>
The code used to reference unavailable variables and mistakenly define
the tasks so fully demonstrating this have not been in use for a
while.
During the code rewrite, it was extended to copy also the patches into
the source distribution directory but using the PF as prefix to avoid
name colision among other recipes.
As 'distsrcall' task was not properly defined and noone noticed it,
until now, it got renamed to 'distribute_sources_all' as it is a
better and more meanful name for the task.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
meta/classes/src_distribute.bbclass | 54 ++++++++++++++++++++---------
meta/classes/src_distribute_local.bbclass | 28 ++++++++-------
2 files changed, 52 insertions(+), 30 deletions(-)
diff --git a/meta/classes/src_distribute.bbclass b/meta/classes/src_distribute.bbclass
index 17d6c09..fbfbdf0 100644
--- a/meta/classes/src_distribute.bbclass
+++ b/meta/classes/src_distribute.bbclass
@@ -2,28 +2,48 @@ SRC_DISTRIBUTECOMMAND[func] = "1"
python do_distribute_sources () {
l = bb.data.createCopy(d)
bb.data.update_data(l)
- licenses = (bb.data.getVar('LICENSE', d, 1) or "unknown").split()
sources_dir = bb.data.getVar('SRC_DISTRIBUTEDIR', d, 1)
- import re
- for license in licenses:
- for entry in license.split("|"):
- for s in (bb.data.getVar('A', d, 1) or "").split():
- s = re.sub(';.*$', '', s)
- cmd = bb.data.getVar('SRC_DISTRIBUTECOMMAND', d, 1)
- if not cmd:
- raise bb.build.FuncFailed("Unable to distribute sources, SRC_DISTRIBUTECOMMAND not defined")
- bb.data.setVar('SRC', s, d)
- bb.data.setVar('SRC_DISTRIBUTEDIR', "%s/%s" % (sources_dir, entry), d)
- bb.build.exec_func('SRC_DISTRIBUTECOMMAND', d)
+ src_uri = bb.data.getVar('SRC_URI', d, 1).split()
+ fetcher = bb.fetch2.Fetch(src_uri, d)
+ ud = fetcher.ud
+
+ licenses = bb.data.getVar('LICENSE', d, 1).replace('&', '|')
+ licenses = licenses.replace('(', '').replace(')', '')
+ clean_licenses = ""
+ for x in licenses.split():
+ if x.strip() == '' or x == 'CLOSED':
+ continue
+
+ if x != "|":
+ clean_licenses += x
+
+ for license in clean_licenses.split('|'):
+ for url in ud.values():
+ cmd = bb.data.getVar('SRC_DISTRIBUTECOMMAND', d, 1)
+ if not cmd:
+ raise bb.build.FuncFailed("Unable to distribute sources, SRC_DISTRIBUTECOMMAND not defined")
+ url.setup_localpath(d)
+ bb.data.setVar('SRC', url.localpath, d)
+ if url.type == 'file':
+ if url.basename == '*':
+ import os.path
+ dest_dir = os.path.basename(os.path.dirname(os.path.abspath(url.localpath)))
+ bb.data.setVar('DEST', "%s_%s/" % (bb.data.getVar('PF', d, 1), dest_dir), d)
+ else:
+ bb.data.setVar('DEST', "%s_%s" % (bb.data.getVar('PF', d, 1), url.basename), d)
+ else:
+ bb.data.setVar('DEST', '', d)
+
+ bb.data.setVar('SRC_DISTRIBUTEDIR', "%s/%s" % (sources_dir, license), d)
+ bb.build.exec_func('SRC_DISTRIBUTECOMMAND', d)
}
addtask distribute_sources before do_build after do_fetch
-addtask distsrcall after do_distribute_sources
-do_distall[recrdeptask] = "do_distribute_sources"
-base_do_distsrcall() {
+addtask distribute_sources_all after do_distribute_sources
+do_distribute_sources_all[recrdeptask] = "do_distribute_sources"
+do_distribute_sources_all[nostamp] = "1"
+do_distribute_sources_all () {
:
}
-
-EXPORT_FUNCTIONS do_distsrcall
diff --git a/meta/classes/src_distribute_local.bbclass b/meta/classes/src_distribute_local.bbclass
index 5f0cef5..17b67e3 100644
--- a/meta/classes/src_distribute_local.bbclass
+++ b/meta/classes/src_distribute_local.bbclass
@@ -1,31 +1,33 @@
inherit src_distribute
# SRC_DIST_LOCAL possible values:
-# copy copies the files from ${A} to the distributedir
-# symlink symlinks the files from ${A} to the distributedir
+# copy copies the files to the distributedir
+# symlink symlinks the files to the distributedir
# move+symlink moves the files into distributedir, and symlinks them back
SRC_DIST_LOCAL ?= "move+symlink"
SRC_DISTRIBUTEDIR ?= "${DEPLOY_DIR}/sources"
SRC_DISTRIBUTECOMMAND () {
s="${SRC}"
- if [ ! -L "$s" ] && (echo "$s"|grep "^${DL_DIR}"); then
- :
- else
- exit 0;
- fi
+ d="${DEST}"
+
mkdir -p ${SRC_DISTRIBUTEDIR}
+
+ if echo $d | grep -q '/$'; then
+ mkdir -p ${SRC_DISTRIBUTEDIR}/$d
+ fi
+
case "${SRC_DIST_LOCAL}" in
copy)
- test -e $s.md5 && cp -f $s.md5 ${SRC_DISTRIBUTEDIR}/
- cp -f $s ${SRC_DISTRIBUTEDIR}/
+ test -e $s.md5 && cp -f $s.md5 ${SRC_DISTRIBUTEDIR}/$d.md5
+ cp -f $s ${SRC_DISTRIBUTEDIR}/$d
;;
symlink)
- test -e $s.md5 && ln -sf $s.md5 ${SRC_DISTRIBUTEDIR}/
- ln -sf $s ${SRC_DISTRIBUTEDIR}/
+ test -e $s.md5 && ln -sf $s.md5 ${SRC_DISTRIBUTEDIR}/$d.md5
+ ln -sf $s ${SRC_DISTRIBUTEDIR}/$d
;;
move+symlink)
- mv $s ${SRC_DISTRIBUTEDIR}/
- ln -sf ${SRC_DISTRIBUTEDIR}/`basename $s` $s
+ mv $s ${SRC_DISTRIBUTEDIR}/$d
+ ln -sf ${SRC_DISTRIBUTEDIR}/$d $s
;;
esac
}
--
1.7.6.2
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [CONSOLIDATED PULL 07/16] ghostscript: renamed x86_64 to x86-64 for patch to work
2011-10-19 8:28 [CONSOLIDATED PULL 00/16] Various Updates Saul Wold
` (5 preceding siblings ...)
2011-10-19 8:28 ` [CONSOLIDATED PULL 06/16] src_distribute.bbclass, src_distribute_local.bbclass: mostly rewritten Saul Wold
@ 2011-10-19 8:28 ` Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 08/16] insane.bbclass: print full path on invalid LICENSE_FILES_CHKSUM Saul Wold
` (8 subsequent siblings)
15 siblings, 0 replies; 38+ messages in thread
From: Saul Wold @ 2011-10-19 8:28 UTC (permalink / raw)
To: openembedded-core
Signed-off-by: Saul Wold <sgw@linux.intel.com>
---
.../ghostscript/{x86_64 => x86-64}/objarch.h | 0
.../ghostscript/{x86_64 => x86-64}/soobjarch.h | 0
2 files changed, 0 insertions(+), 0 deletions(-)
rename meta/recipes-extended/ghostscript/ghostscript/{x86_64 => x86-64}/objarch.h (100%)
rename meta/recipes-extended/ghostscript/ghostscript/{x86_64 => x86-64}/soobjarch.h (100%)
diff --git a/meta/recipes-extended/ghostscript/ghostscript/x86_64/objarch.h b/meta/recipes-extended/ghostscript/ghostscript/x86-64/objarch.h
similarity index 100%
rename from meta/recipes-extended/ghostscript/ghostscript/x86_64/objarch.h
rename to meta/recipes-extended/ghostscript/ghostscript/x86-64/objarch.h
diff --git a/meta/recipes-extended/ghostscript/ghostscript/x86_64/soobjarch.h b/meta/recipes-extended/ghostscript/ghostscript/x86-64/soobjarch.h
similarity index 100%
rename from meta/recipes-extended/ghostscript/ghostscript/x86_64/soobjarch.h
rename to meta/recipes-extended/ghostscript/ghostscript/x86-64/soobjarch.h
--
1.7.6.2
^ permalink raw reply [flat|nested] 38+ messages in thread
* [CONSOLIDATED PULL 08/16] insane.bbclass: print full path on invalid LICENSE_FILES_CHKSUM
2011-10-19 8:28 [CONSOLIDATED PULL 00/16] Various Updates Saul Wold
` (6 preceding siblings ...)
2011-10-19 8:28 ` [CONSOLIDATED PULL 07/16] ghostscript: renamed x86_64 to x86-64 for patch to work Saul Wold
@ 2011-10-19 8:28 ` Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 09/16] x86 tune files: set baselib for x32 tune as libx32 Saul Wold
` (7 subsequent siblings)
15 siblings, 0 replies; 38+ messages in thread
From: Saul Wold @ 2011-10-19 8:28 UTC (permalink / raw)
To: openembedded-core
From: Darren Hart <dvhart@linux.intel.com>
Currently only the basename is printed when os.path.isfile() returns a failure
for the license file. If the file is present, but in the wrong directory, this
can be non-obvious to debug. Use the full path instead.
Make a minor grammatical correction in the error message while we're at it.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
---
meta/classes/insane.bbclass | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index b861e85..017f7be 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -330,7 +330,7 @@ def package_qa_check_license(workdir, d):
(type, host, path, user, pswd, parm) = bb.decodeurl(url)
srclicfile = os.path.join(srcdir, path)
if not os.path.isfile(srclicfile):
- raise bb.build.FuncFailed( pn + ": LIC_FILES_CHKSUM points to invalid file: " + path)
+ raise bb.build.FuncFailed( pn + ": LIC_FILES_CHKSUM points to an invalid file: " + srclicfile)
if 'md5' not in parm:
bb.error(pn + ": md5 checksum is not specified for ", url)
--
1.7.6.2
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [CONSOLIDATED PULL 09/16] x86 tune files: set baselib for x32 tune as libx32
2011-10-19 8:28 [CONSOLIDATED PULL 00/16] Various Updates Saul Wold
` (7 preceding siblings ...)
2011-10-19 8:28 ` [CONSOLIDATED PULL 08/16] insane.bbclass: print full path on invalid LICENSE_FILES_CHKSUM Saul Wold
@ 2011-10-19 8:28 ` Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 10/16] gmp: also generate the libgmpcxx library Saul Wold
` (6 subsequent siblings)
15 siblings, 0 replies; 38+ messages in thread
From: Saul Wold @ 2011-10-19 8:28 UTC (permalink / raw)
To: openembedded-core
From: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
---
meta/conf/machine/include/ia32/arch-ia32.inc | 2 +-
meta/conf/machine/include/tune-core2.inc | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/conf/machine/include/ia32/arch-ia32.inc b/meta/conf/machine/include/ia32/arch-ia32.inc
index a52e33a..ee91983 100644
--- a/meta/conf/machine/include/ia32/arch-ia32.inc
+++ b/meta/conf/machine/include/ia32/arch-ia32.inc
@@ -44,6 +44,6 @@ PACKAGE_EXTRA_ARCHS_tune-x86-64 = "x86_64"
AVAILTUNES += "x86-64-x32"
TUNE_FEATURES_tune-x86-64-x32 ?= "mx32"
-BASE_LIB_tune-x86-64-x32 ?= "lib"
+BASE_LIB_tune-x86-64-x32 ?= "libx32"
PACKAGE_EXTRA_ARCHS_tune-x86-64-x32 = "x86_64-x32"
TUNE_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-x32", "", d)}"
diff --git a/meta/conf/machine/include/tune-core2.inc b/meta/conf/machine/include/tune-core2.inc
index 78f8f4d..565a39c 100644
--- a/meta/conf/machine/include/tune-core2.inc
+++ b/meta/conf/machine/include/tune-core2.inc
@@ -20,5 +20,5 @@ PACKAGE_EXTRA_ARCHS_tune-core2-64 = "${PACKAGE_EXTRA_ARCHS_tune-x86-64} core2-64
AVAILTUNES += "core2-64-x32"
TUNE_FEATURES_tune-core2-64-x32 ?= "${TUNE_FEATURES_tune-x86-64-x32} core2"
-BASE_LIB_tune-core2-64-x32 ?= "lib"
+BASE_LIB_tune-core2-64-x32 ?= "libx32"
PACKAGE_EXTRA_ARCHS_tune-core2-64-x32 = "${PACKAGE_EXTRA_ARCHS_tune-x86-64-x32} core2-64-x32"
--
1.7.6.2
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [CONSOLIDATED PULL 10/16] gmp: also generate the libgmpcxx library
2011-10-19 8:28 [CONSOLIDATED PULL 00/16] Various Updates Saul Wold
` (8 preceding siblings ...)
2011-10-19 8:28 ` [CONSOLIDATED PULL 09/16] x86 tune files: set baselib for x32 tune as libx32 Saul Wold
@ 2011-10-19 8:28 ` Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 11/16] python-scons: upgrade from 2.0.1 to 2.1.0 Saul Wold
` (5 subsequent siblings)
15 siblings, 0 replies; 38+ messages in thread
From: Saul Wold @ 2011-10-19 8:28 UTC (permalink / raw)
To: openembedded-core
From: Nitin A Kamble <nitin.a.kamble@intel.com>
configure runs few checks to make sure c++ compiler and runtime are working as expected
with the --enable-cxx=detect option.
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
---
meta/recipes-support/gmp/gmp.inc | 2 ++
meta/recipes-support/gmp/gmp_4.2.1.bb | 2 +-
meta/recipes-support/gmp/gmp_5.0.2.bb | 2 +-
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-support/gmp/gmp.inc b/meta/recipes-support/gmp/gmp.inc
index 66349e6..3c662a0 100644
--- a/meta/recipes-support/gmp/gmp.inc
+++ b/meta/recipes-support/gmp/gmp.inc
@@ -14,3 +14,5 @@ ARM_INSTRUCTION_SET = "arm"
acpaths = ""
BBCLASSEXTEND = "native nativesdk"
+
+EXTRA_OECONF += " --enable-cxx=detect"
diff --git a/meta/recipes-support/gmp/gmp_4.2.1.bb b/meta/recipes-support/gmp/gmp_4.2.1.bb
index 74da6b8..97ac4b2 100644
--- a/meta/recipes-support/gmp/gmp_4.2.1.bb
+++ b/meta/recipes-support/gmp/gmp_4.2.1.bb
@@ -6,7 +6,7 @@ LICENSE = "LGPLv2.1+"
LIC_FILES_CHKSUM = "file://COPYING;md5=892f569a555ba9c07a568a7c0c4fa63a \
file://COPYING.LIB;md5=fbc093901857fcd118f065f900982c24 \
file://gmp-h.in;startline=6;endline=21;md5=5e25ffd16996faba8c1cd27b04b16099"
-PR = "r0"
+PR = "r1"
SRC_URI = "${GNU_MIRROR}/gmp/${BP}.tar.bz2 \
file://disable-stdc.patch"
diff --git a/meta/recipes-support/gmp/gmp_5.0.2.bb b/meta/recipes-support/gmp/gmp_5.0.2.bb
index 03fef45..f80971e 100644
--- a/meta/recipes-support/gmp/gmp_5.0.2.bb
+++ b/meta/recipes-support/gmp/gmp_5.0.2.bb
@@ -2,7 +2,7 @@ require gmp.inc
LICENSE="LGPLv3&GPLv3"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
file://version.c;endline=18;md5=d8c56b52b9092346b9f93b4da65ef790"
-PR = "r0"
+PR = "r1"
SRC_URI_append += "file://sh4-asmfix.patch \
file://use-includedir.patch "
--
1.7.6.2
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [CONSOLIDATED PULL 11/16] python-scons: upgrade from 2.0.1 to 2.1.0
2011-10-19 8:28 [CONSOLIDATED PULL 00/16] Various Updates Saul Wold
` (9 preceding siblings ...)
2011-10-19 8:28 ` [CONSOLIDATED PULL 10/16] gmp: also generate the libgmpcxx library Saul Wold
@ 2011-10-19 8:28 ` Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 12/16] python-dbus: upgrade from 0.83.2 to 0.84.0 Saul Wold
` (4 subsequent siblings)
15 siblings, 0 replies; 38+ messages in thread
From: Saul Wold @ 2011-10-19 8:28 UTC (permalink / raw)
To: openembedded-core
From: Nitin A Kamble <nitin.a.kamble@intel.com>
the LICENSE.txt has added 2011 year to the copyright line he nce the MD5 sum is different.
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
---
...ative_2.0.1.bb => python-scons-native_2.1.0.bb} | 3 +--
...python-scons_2.0.1.bb => python-scons_2.1.0.bb} | 6 +++---
2 files changed, 4 insertions(+), 5 deletions(-)
rename meta/recipes-devtools/python/{python-scons-native_2.0.1.bb => python-scons-native_2.1.0.bb} (89%)
rename meta/recipes-devtools/python/{python-scons_2.0.1.bb => python-scons_2.1.0.bb} (51%)
diff --git a/meta/recipes-devtools/python/python-scons-native_2.0.1.bb b/meta/recipes-devtools/python/python-scons-native_2.1.0.bb
similarity index 89%
rename from meta/recipes-devtools/python/python-scons-native_2.0.1.bb
rename to meta/recipes-devtools/python/python-scons-native_2.1.0.bb
index f7646a2..083ad15 100644
--- a/meta/recipes-devtools/python/python-scons-native_2.0.1.bb
+++ b/meta/recipes-devtools/python/python-scons-native_2.1.0.bb
@@ -2,5 +2,4 @@ require python-scons_${PV}.bb
inherit native
DEPENDS = "python-native"
RDEPENDS_${PN} = ""
-PR = "r1"
-
+PR = "r0"
diff --git a/meta/recipes-devtools/python/python-scons_2.0.1.bb b/meta/recipes-devtools/python/python-scons_2.1.0.bb
similarity index 51%
rename from meta/recipes-devtools/python/python-scons_2.0.1.bb
rename to meta/recipes-devtools/python/python-scons_2.1.0.bb
index 1c7939e..22df333 100644
--- a/meta/recipes-devtools/python/python-scons_2.0.1.bb
+++ b/meta/recipes-devtools/python/python-scons_2.1.0.bb
@@ -1,15 +1,15 @@
DESCRIPTION = "A Software Construction Tool"
SECTION = "devel/python"
LICENSE = "MIT"
-LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=8481211ebbeaed9cdc7ad5a3b0c98aaf"
+LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=ab8b65435c2e520ed18e67459f1f9bb9"
SRCNAME = "scons"
PR = "r0"
SRC_URI = "${SOURCEFORGE_MIRROR}/scons/scons-${PV}.tar.gz"
-SRC_URI[md5sum] = "beca648b894cdbf85383fffc79516d18"
-SRC_URI[sha256sum] = "0a8151da41c4a26c776c84f44f747ce03e093d43be3e83b38c14a76ab3256762"
+SRC_URI[md5sum] = "47daf989e303a045b76c11236df719df"
+SRC_URI[sha256sum] = "4139ed14f60dd2ebcd47c59984d14705636180eb27b3d1b2949489e514b1921d"
S = "${WORKDIR}/${SRCNAME}-${PV}"
inherit distutils
--
1.7.6.2
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [CONSOLIDATED PULL 12/16] python-dbus: upgrade from 0.83.2 to 0.84.0
2011-10-19 8:28 [CONSOLIDATED PULL 00/16] Various Updates Saul Wold
` (10 preceding siblings ...)
2011-10-19 8:28 ` [CONSOLIDATED PULL 11/16] python-scons: upgrade from 2.0.1 to 2.1.0 Saul Wold
@ 2011-10-19 8:28 ` Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 13/16] libxml-parser-perl: upgrade from 2.40 to 2.41 Saul Wold
` (3 subsequent siblings)
15 siblings, 0 replies; 38+ messages in thread
From: Saul Wold @ 2011-10-19 8:28 UTC (permalink / raw)
To: openembedded-core
From: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
---
...python-dbus_0.83.2.bb => python-dbus_0.84.0.bb} | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-devtools/python/{python-dbus_0.83.2.bb => python-dbus_0.84.0.bb} (83%)
diff --git a/meta/recipes-devtools/python/python-dbus_0.83.2.bb b/meta/recipes-devtools/python/python-dbus_0.84.0.bb
similarity index 83%
rename from meta/recipes-devtools/python/python-dbus_0.83.2.bb
rename to meta/recipes-devtools/python/python-dbus_0.84.0.bb
index 323dae5..fff8649 100644
--- a/meta/recipes-devtools/python/python-dbus_0.83.2.bb
+++ b/meta/recipes-devtools/python/python-dbus_0.84.0.bb
@@ -8,8 +8,8 @@ PR = "r0"
SRC_URI = "http://dbus.freedesktop.org/releases/dbus-python/dbus-python-${PV}.tar.gz"
-SRC_URI[md5sum] = "4ebcaa905bdcb4132b915196b0a3691b"
-SRC_URI[sha256sum] = "883729c98f40790021e3be0f7028ae863ee1c4a7b922a5578c1342592adfff64"
+SRC_URI[md5sum] = "fe69a2613e824463e74f10913708c88a"
+SRC_URI[sha256sum] = "b85bc7aaf1a976627ca461b1ca7b0c4ddddff709f52fe44c9b2d1d7d8fac5906"
S = "${WORKDIR}/dbus-python-${PV}"
inherit distutils-base autotools pkgconfig
--
1.7.6.2
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [CONSOLIDATED PULL 13/16] libxml-parser-perl: upgrade from 2.40 to 2.41
2011-10-19 8:28 [CONSOLIDATED PULL 00/16] Various Updates Saul Wold
` (11 preceding siblings ...)
2011-10-19 8:28 ` [CONSOLIDATED PULL 12/16] python-dbus: upgrade from 0.83.2 to 0.84.0 Saul Wold
@ 2011-10-19 8:28 ` Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes Saul Wold
` (2 subsequent siblings)
15 siblings, 0 replies; 38+ messages in thread
From: Saul Wold @ 2011-10-19 8:28 UTC (permalink / raw)
To: openembedded-core
From: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
---
...ser-perl_2.40.bb => libxml-parser-perl_2.41.bb} | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
rename meta/recipes-devtools/perl/{libxml-parser-perl_2.40.bb => libxml-parser-perl_2.41.bb} (82%)
diff --git a/meta/recipes-devtools/perl/libxml-parser-perl_2.40.bb b/meta/recipes-devtools/perl/libxml-parser-perl_2.41.bb
similarity index 82%
rename from meta/recipes-devtools/perl/libxml-parser-perl_2.40.bb
rename to meta/recipes-devtools/perl/libxml-parser-perl_2.41.bb
index 1d1593b..caf5704 100644
--- a/meta/recipes-devtools/perl/libxml-parser-perl_2.40.bb
+++ b/meta/recipes-devtools/perl/libxml-parser-perl_2.41.bb
@@ -5,11 +5,11 @@ LIC_FILES_CHKSUM = "file://README;beginline=2;endline=6;md5=c8767d7516229f07b26e
DEPENDS += "expat expat-native"
-PR = "r4"
+PR = "r0"
SRC_URI = "http://www.cpan.org/modules/by-module/XML/XML-Parser-${PV}.tar.gz"
-SRC_URI[md5sum] = "c66e9adba003d0667cc40115ccd837a5"
-SRC_URI[sha256sum] = "e5e433684e799ef7b6b852c0ca31b71054717628555444d3dc9fceac0df71512"
+SRC_URI[md5sum] = "c320d2ffa459e6cdc6f9f59c1185855e"
+SRC_URI[sha256sum] = "b48197cd2265a26c5f016489f11a7b450d8833cb8b3d6a46ee15975740894de9"
S = "${WORKDIR}/XML-Parser-${PV}"
--
1.7.6.2
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
2011-10-19 8:28 [CONSOLIDATED PULL 00/16] Various Updates Saul Wold
` (12 preceding siblings ...)
2011-10-19 8:28 ` [CONSOLIDATED PULL 13/16] libxml-parser-perl: upgrade from 2.40 to 2.41 Saul Wold
@ 2011-10-19 8:28 ` Saul Wold
2011-10-19 8:30 ` Koen Kooi
2011-10-19 8:28 ` [CONSOLIDATED PULL 15/16] gst-plugins-good: update to 0.10.30 Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 16/16] tzdata: updated SRC_URI and update to 2011k Saul Wold
15 siblings, 1 reply; 38+ messages in thread
From: Saul Wold @ 2011-10-19 8:28 UTC (permalink / raw)
To: openembedded-core
From: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
---
.../conf/distro/include/distro_tracking_fields.inc | 42 ++++++++++++--------
1 files changed, 25 insertions(+), 17 deletions(-)
diff --git a/meta/conf/distro/include/distro_tracking_fields.inc b/meta/conf/distro/include/distro_tracking_fields.inc
index abc2cbf..e68bbe1 100644
--- a/meta/conf/distro/include/distro_tracking_fields.inc
+++ b/meta/conf/distro/include/distro_tracking_fields.inc
@@ -3005,11 +3005,19 @@ RECIPE_STATUS_pn-run-postinsts="green" # all local code
RECIPE_LATEST_VERSION_pn-postinsts="1.0"
RECIPE_MAINTAINER_pn-postinsts = "Nitin A Kamble <nitin.a.kamble@intel.com>"
-RECIPE_STATUS_pn-nasm="green"
+RECIPE_STATUS_pn-nasm="green"
RECIPE_LATEST_VERSION_pn-nasm="2.07"
-RECIPE_MANUAL_CHECK_DATE_pn-nasm = "Jul 06, 2011"
+RECIPE_MANUAL_CHECK_DATE_pn-nasm = "Oct 18, 2011"
+RECIPE_LAST_UPDATE_pn-nasm = "Jun 23, 2010"
RECIPE_MAINTAINER_pn-nasm = "Nitin A Kamble <nitin.a.kamble@intel.com>"
+RECIPE_STATUS_pn-btrfs-tools="green"
+RECIPE_LATEST_VERSION_pn-btrfs-tools="git"
+RECIPE_MANUAL_CHECK_DATE_pn-btrfs-tools = "Oct 18, 2011"
+RECIPE_LAST_UPDATE_pn-btrfs-tools = "Jun 09, 2011"
+RECIPE_MAINTAINER_pn-btrfs-tools = "Nitin A Kamble <nitin.a.kamble@intel.com>"
+DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-progs"
+
RECIPE_STATUS_pn-perl="red" # upgrade needed
RECIPE_LATEST_VERSION_pn-perl="5.12.1"
RECIPE_LAST_UPDATE_pn-perl = "May 27, 2007"
@@ -3020,9 +3028,9 @@ RECIPE_LATEST_VERSION_pn-prelink="1.0+git0+0x909470ee441237563d6236c505cb2d02ddc
RECIPE_LAST_UPDATE_pn-perl = "Jul 23, 2010"
RECIPE_MAINTAINER_pn-prelink = "Mark Hatle <mark.hatle@windriver.com>"
-RECIPE_STATUS_pn-python-dbus="red"
-RECIPE_LATEST_VERSION_pn-python-dbus="0.83.1"
-RECIPE_LAST_UPDATE_pn-python-dbus = "Jul 7, 2010"
+RECIPE_STATUS_pn-python-dbus="green"
+RECIPE_LATEST_VERSION_pn-python-dbus="0.84.0"
+RECIPE_LAST_UPDATE_pn-python-dbus = "Oct 18, 2011"
RECIPE_MAINTAINER_pn-python-dbus = "Nitin A Kamble <nitin.a.kamble@intel.com>"
DISTRO_PN_ALIAS_pn-python-dbus = "Ubuntu=python-dbus Debian=python-dbus Mandriva=python-dbus"
@@ -3062,7 +3070,8 @@ RECIPE_MAINTAINER_pn-python-pyrex = "Nitin A Kamble <nitin.a.kamble@intel.com>"
DISTRO_PN_ALIAS_pn-python-pyrex = "Mandriva=python-pyrex Ubuntu=python-pyrex"
RECIPE_STATUS_pn-python-scons="green"
-RECIPE_LATEST_VERSION_pn-python-scons="2.0.1"
+RECIPE_LATEST_VERSION_pn-python-scons="2.1.0"
+RECIPE_LAST_UPDATE_pn-python-scons = "Oct 18, 2011"
DISTRO_PN_ALIAS_pn-python-scons = "Fedora=scons OpenSuSE=scons Ubuntu=scons Mandriva=scons Debian=scons"
RECIPE_LAST_UPDATE_pn-python-scons = "Nov 8, 2010"
RECIPE_MAINTAINER_pn-python-scons = "Nitin A Kamble <nitin.a.kamble@intel.com>"
@@ -3087,15 +3096,16 @@ RECIPE_LATEST_VERSION_pn-unifdef="2.6.18+git"
RECIPE_MAINTAINER_pn-unifdef = "Nitin A Kamble <nitin.a.kamble@intel.com>"
RECIPE_STATUS_pn-gnu-config="green"
-RECIPE_LATEST_VERSION_pn-gnu-config="0.0+git3155524"
+RECIPE_LATEST_VERSION_pn-gnu-config="svn"
DISTRO_PN_ALIAS_pn-gnu-config = "OpenedHand"
RECIPE_LAST_UPDATE_pn-gnu-config = "Jun 21, 2010"
-RECIPE_MANUAL_CHECK_DATE_pn-gnu-config = "Jul 06, 2011"
+RECIPE_MANUAL_CHECK_DATE_pn-gnu-config = "Oct 18, 2011"
RECIPE_MAINTAINER_pn-gnu-config = "Nitin A Kamble <nitin.a.kamble@intel.com>"
RECIPE_STATUS_pn-mpfr="green"
-RECIPE_LATEST_VERSION_pn-mpfr="3.0.0"
-RECIPE_MANUAL_CHECK_DATE_pn-mpfr = "Jul 06, 2011"
+RECIPE_LATEST_VERSION_pn-mpfr="3.0.1"
+RECIPE_MANUAL_CHECK_DATE_pn-mpfr = "Oct 18, 2011"
+RECIPE_LAST_UPDATE_pn-mpfr = "Apr 07, 2011"
RECIPE_MAINTAINER_pn-mpfr = "Nitin A Kamble <nitin.a.kamble@intel.com>"
RECIPE_STATUS_pn-gmp="green"
@@ -3110,9 +3120,10 @@ RECIPE_MANUAL_CHECK_DATE_pn-libmpc = "Jan 25, 2011"
RECIPE_MAINTAINER_pn-libmpc = "Nitin A Kamble <nitin.a.kamble@intel.com>"
DISTRO_PN_ALIAS_pn-libmpc = "Fedora=libmpc OpenSuse=libmpc2"
-RECIPE_STATUS_pn-byacc="red"
+RECIPE_STATUS_pn-byacc="green"
RECIPE_LATEST_VERSION_pn-byacc="20101229"
-RECIPE_MANUAL_CHECK_DATE_pn-byacc = "Jul 06, 2011"
+RECIPE_MANUAL_CHECK_DATE_pn-byacc = "Oct 18, 2011"
+RECIPE_LAST_UPDATE_pn-byacc = "Oct 18, 2010"
RECIPE_MAINTAINER_pn-byacc = "Nitin A Kamble <nitin.a.kamble@intel.com>"
RECIPE_STATUS_pn-libconvert-asn1-perl="green"
@@ -3122,8 +3133,8 @@ RECIPE_LAST_UPDATE_pn-libconvert-asn1-perl = "Aug 13, 2010"
RECIPE_MAINTAINER_pn-libconvert-asn1-perl = "Nitin A Kamble <nitin.a.kamble@intel.com>"
RECIPE_STATUS_pn-libxml-parser-perl="green"
-RECIPE_LATEST_VERSION_pn-libxml-parser-perl="2.36"
-RECIPE_LAST_UPDATE_pn-libxml-parser-perl = "Nov 18, 2009"
+RECIPE_LATEST_VERSION_pn-libxml-parser-perl="2.41"
+RECIPE_LAST_UPDATE_pn-libxml-parser-perl = "Oct 18, 2011"
RECIPE_MAINTAINER_pn-libxml-parser-perl = "Nitin A Kamble <nitin.a.kamble@intel.com>"
RECIPE_STATUS_pn-cmake-native="green"
@@ -5922,9 +5933,6 @@ RECIPE_COMMENTS_pn-pseudo = "Yocto Project maintained"
RECIPE_MANUAL_CHECK_DATE_pn-pseudo = "Jun 06, 2011"
DISTRO_PN_ALIAS_pn-pseudo = "Windriver"
-DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-progs"
-RECIPE_MAINTAINER_pn-btrfs-tools = "Nitin A Kamble <nitin.a.kamble@intel.com>"
-
DISTRO_PN_ALIAS_pn-rt-tests = "Debian=rt-tests Ubuntu=rt-tests"
RECIPE_MAINTAINER_pn-rt-tests = "Darren Hart <dvhart@linux.intel.com>"
--
1.7.6.2
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [CONSOLIDATED PULL 15/16] gst-plugins-good: update to 0.10.30
2011-10-19 8:28 [CONSOLIDATED PULL 00/16] Various Updates Saul Wold
` (13 preceding siblings ...)
2011-10-19 8:28 ` [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes Saul Wold
@ 2011-10-19 8:28 ` Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 16/16] tzdata: updated SRC_URI and update to 2011k Saul Wold
15 siblings, 0 replies; 38+ messages in thread
From: Saul Wold @ 2011-10-19 8:28 UTC (permalink / raw)
To: openembedded-core
From: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
---
...good_0.10.28.bb => gst-plugins-good_0.10.30.bb} | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-multimedia/gstreamer/{gst-plugins-good_0.10.28.bb => gst-plugins-good_0.10.30.bb} (84%)
diff --git a/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.28.bb b/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.30.bb
similarity index 84%
rename from meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.28.bb
rename to meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.30.bb
index 6c837a7..96855aa 100644
--- a/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.28.bb
+++ b/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.30.bb
@@ -18,5 +18,5 @@ do_configure_prepend() {
rm ${S}/m4/lib-link.m4 || true
}
-SRC_URI[md5sum] = "6ef1588921f59d85c44ee2e49a3c97a0"
-SRC_URI[sha256sum] = "adfbce68b9fbadb7a7aeda2227af6afe1928ef025af4158726617b9d6834b028"
+SRC_URI[md5sum] = "62fd7a3ef187c4f99b3d7c352d58dae9"
+SRC_URI[sha256sum] = "b12cba90b27d8423cd0a808939098d19db3996cfb9bf528507c6321782e095f6"
--
1.7.6.2
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [CONSOLIDATED PULL 16/16] tzdata: updated SRC_URI and update to 2011k
2011-10-19 8:28 [CONSOLIDATED PULL 00/16] Various Updates Saul Wold
` (14 preceding siblings ...)
2011-10-19 8:28 ` [CONSOLIDATED PULL 15/16] gst-plugins-good: update to 0.10.30 Saul Wold
@ 2011-10-19 8:28 ` Saul Wold
15 siblings, 0 replies; 38+ messages in thread
From: Saul Wold @ 2011-10-19 8:28 UTC (permalink / raw)
To: openembedded-core
From: Joshua Lock <josh@linux.intel.com>
tzdata is now hosted by IANA at http://www.iana.org/time-zones
Signed-off-by: Joshua Lock <josh@linux.intel.com>
---
.../tzdata/{tzdata_2011k.bb => tzdata_2011l.bb} | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
rename meta/recipes-extended/tzdata/{tzdata_2011k.bb => tzdata_2011l.bb} (96%)
diff --git a/meta/recipes-extended/tzdata/tzdata_2011k.bb b/meta/recipes-extended/tzdata/tzdata_2011l.bb
similarity index 96%
rename from meta/recipes-extended/tzdata/tzdata_2011k.bb
rename to meta/recipes-extended/tzdata/tzdata_2011l.bb
index 45f2c4d..140f8ed 100644
--- a/meta/recipes-extended/tzdata/tzdata_2011k.bb
+++ b/meta/recipes-extended/tzdata/tzdata_2011l.bb
@@ -12,10 +12,10 @@ RCONFLICTS= "timezones timezone-africa timezone-america timezone-antarctica \
timezone-australia timezone-europe timezone-indian \
timezone-iso3166.tab timezone-pacific timezone-zone.tab"
-SRC_URI = "ftp://elsie.nci.nih.gov/pub/tzdata${PV}.tar.gz;name=tzdata"
+SRC_URI = "http://www.iana.org/time-zones/repository/releases/tzdata${PV}.tar.gz;name=tzdata"
-SRC_URI[tzdata.md5sum] = "9da1c2d4d1a01f9f504b73ccd371830f"
-SRC_URI[tzdata.sha256sum] = "51f7d2a42b7fb9465feced642a6676afdf8b04a071e55f3fef1f0925bd67ef21"
+SRC_URI[tzdata.md5sum] = "bae1b93673e1aef80186c90dfd493f1c"
+SRC_URI[tzdata.sha256sum] = "cb9fec68a19c9c3b900bb71f3ca20d0051a863f765387b52fc2d144a5bbb0c7d"
S = "${WORKDIR}"
--
1.7.6.2
^ permalink raw reply related [flat|nested] 38+ messages in thread
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
2011-10-19 8:28 ` [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes Saul Wold
@ 2011-10-19 8:30 ` Koen Kooi
2011-10-19 15:49 ` Kamble, Nitin A
0 siblings, 1 reply; 38+ messages in thread
From: Koen Kooi @ 2011-10-19 8:30 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
btrfs-tools is a toolchain recipe?!?!?!
Op 19 okt. 2011, om 10:28 heeft Saul Wold het volgende geschreven:
> From: Nitin A Kamble <nitin.a.kamble@intel.com>
>
> Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
> ---
> .../conf/distro/include/distro_tracking_fields.inc | 42 ++++++++++++--------
> 1 files changed, 25 insertions(+), 17 deletions(-)
>
> diff --git a/meta/conf/distro/include/distro_tracking_fields.inc b/meta/conf/distro/include/distro_tracking_fields.inc
> index abc2cbf..e68bbe1 100644
> --- a/meta/conf/distro/include/distro_tracking_fields.inc
> +++ b/meta/conf/distro/include/distro_tracking_fields.inc
> @@ -3005,11 +3005,19 @@ RECIPE_STATUS_pn-run-postinsts="green" # all local code
> RECIPE_LATEST_VERSION_pn-postinsts="1.0"
> RECIPE_MAINTAINER_pn-postinsts = "Nitin A Kamble <nitin.a.kamble@intel.com>"
>
> -RECIPE_STATUS_pn-nasm="green"
> +RECIPE_STATUS_pn-nasm="green"
> RECIPE_LATEST_VERSION_pn-nasm="2.07"
> -RECIPE_MANUAL_CHECK_DATE_pn-nasm = "Jul 06, 2011"
> +RECIPE_MANUAL_CHECK_DATE_pn-nasm = "Oct 18, 2011"
> +RECIPE_LAST_UPDATE_pn-nasm = "Jun 23, 2010"
> RECIPE_MAINTAINER_pn-nasm = "Nitin A Kamble <nitin.a.kamble@intel.com>"
>
> +RECIPE_STATUS_pn-btrfs-tools="green"
> +RECIPE_LATEST_VERSION_pn-btrfs-tools="git"
> +RECIPE_MANUAL_CHECK_DATE_pn-btrfs-tools = "Oct 18, 2011"
> +RECIPE_LAST_UPDATE_pn-btrfs-tools = "Jun 09, 2011"
> +RECIPE_MAINTAINER_pn-btrfs-tools = "Nitin A Kamble <nitin.a.kamble@intel.com>"
> +DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-progs"
> +
> RECIPE_STATUS_pn-perl="red" # upgrade needed
> RECIPE_LATEST_VERSION_pn-perl="5.12.1"
> RECIPE_LAST_UPDATE_pn-perl = "May 27, 2007"
> @@ -3020,9 +3028,9 @@ RECIPE_LATEST_VERSION_pn-prelink="1.0+git0+0x909470ee441237563d6236c505cb2d02ddc
> RECIPE_LAST_UPDATE_pn-perl = "Jul 23, 2010"
> RECIPE_MAINTAINER_pn-prelink = "Mark Hatle <mark.hatle@windriver.com>"
>
> -RECIPE_STATUS_pn-python-dbus="red"
> -RECIPE_LATEST_VERSION_pn-python-dbus="0.83.1"
> -RECIPE_LAST_UPDATE_pn-python-dbus = "Jul 7, 2010"
> +RECIPE_STATUS_pn-python-dbus="green"
> +RECIPE_LATEST_VERSION_pn-python-dbus="0.84.0"
> +RECIPE_LAST_UPDATE_pn-python-dbus = "Oct 18, 2011"
> RECIPE_MAINTAINER_pn-python-dbus = "Nitin A Kamble <nitin.a.kamble@intel.com>"
> DISTRO_PN_ALIAS_pn-python-dbus = "Ubuntu=python-dbus Debian=python-dbus Mandriva=python-dbus"
>
> @@ -3062,7 +3070,8 @@ RECIPE_MAINTAINER_pn-python-pyrex = "Nitin A Kamble <nitin.a.kamble@intel.com>"
> DISTRO_PN_ALIAS_pn-python-pyrex = "Mandriva=python-pyrex Ubuntu=python-pyrex"
>
> RECIPE_STATUS_pn-python-scons="green"
> -RECIPE_LATEST_VERSION_pn-python-scons="2.0.1"
> +RECIPE_LATEST_VERSION_pn-python-scons="2.1.0"
> +RECIPE_LAST_UPDATE_pn-python-scons = "Oct 18, 2011"
> DISTRO_PN_ALIAS_pn-python-scons = "Fedora=scons OpenSuSE=scons Ubuntu=scons Mandriva=scons Debian=scons"
> RECIPE_LAST_UPDATE_pn-python-scons = "Nov 8, 2010"
> RECIPE_MAINTAINER_pn-python-scons = "Nitin A Kamble <nitin.a.kamble@intel.com>"
> @@ -3087,15 +3096,16 @@ RECIPE_LATEST_VERSION_pn-unifdef="2.6.18+git"
> RECIPE_MAINTAINER_pn-unifdef = "Nitin A Kamble <nitin.a.kamble@intel.com>"
>
> RECIPE_STATUS_pn-gnu-config="green"
> -RECIPE_LATEST_VERSION_pn-gnu-config="0.0+git3155524"
> +RECIPE_LATEST_VERSION_pn-gnu-config="svn"
> DISTRO_PN_ALIAS_pn-gnu-config = "OpenedHand"
> RECIPE_LAST_UPDATE_pn-gnu-config = "Jun 21, 2010"
> -RECIPE_MANUAL_CHECK_DATE_pn-gnu-config = "Jul 06, 2011"
> +RECIPE_MANUAL_CHECK_DATE_pn-gnu-config = "Oct 18, 2011"
> RECIPE_MAINTAINER_pn-gnu-config = "Nitin A Kamble <nitin.a.kamble@intel.com>"
>
> RECIPE_STATUS_pn-mpfr="green"
> -RECIPE_LATEST_VERSION_pn-mpfr="3.0.0"
> -RECIPE_MANUAL_CHECK_DATE_pn-mpfr = "Jul 06, 2011"
> +RECIPE_LATEST_VERSION_pn-mpfr="3.0.1"
> +RECIPE_MANUAL_CHECK_DATE_pn-mpfr = "Oct 18, 2011"
> +RECIPE_LAST_UPDATE_pn-mpfr = "Apr 07, 2011"
> RECIPE_MAINTAINER_pn-mpfr = "Nitin A Kamble <nitin.a.kamble@intel.com>"
>
> RECIPE_STATUS_pn-gmp="green"
> @@ -3110,9 +3120,10 @@ RECIPE_MANUAL_CHECK_DATE_pn-libmpc = "Jan 25, 2011"
> RECIPE_MAINTAINER_pn-libmpc = "Nitin A Kamble <nitin.a.kamble@intel.com>"
> DISTRO_PN_ALIAS_pn-libmpc = "Fedora=libmpc OpenSuse=libmpc2"
>
> -RECIPE_STATUS_pn-byacc="red"
> +RECIPE_STATUS_pn-byacc="green"
> RECIPE_LATEST_VERSION_pn-byacc="20101229"
> -RECIPE_MANUAL_CHECK_DATE_pn-byacc = "Jul 06, 2011"
> +RECIPE_MANUAL_CHECK_DATE_pn-byacc = "Oct 18, 2011"
> +RECIPE_LAST_UPDATE_pn-byacc = "Oct 18, 2010"
> RECIPE_MAINTAINER_pn-byacc = "Nitin A Kamble <nitin.a.kamble@intel.com>"
>
> RECIPE_STATUS_pn-libconvert-asn1-perl="green"
> @@ -3122,8 +3133,8 @@ RECIPE_LAST_UPDATE_pn-libconvert-asn1-perl = "Aug 13, 2010"
> RECIPE_MAINTAINER_pn-libconvert-asn1-perl = "Nitin A Kamble <nitin.a.kamble@intel.com>"
>
> RECIPE_STATUS_pn-libxml-parser-perl="green"
> -RECIPE_LATEST_VERSION_pn-libxml-parser-perl="2.36"
> -RECIPE_LAST_UPDATE_pn-libxml-parser-perl = "Nov 18, 2009"
> +RECIPE_LATEST_VERSION_pn-libxml-parser-perl="2.41"
> +RECIPE_LAST_UPDATE_pn-libxml-parser-perl = "Oct 18, 2011"
> RECIPE_MAINTAINER_pn-libxml-parser-perl = "Nitin A Kamble <nitin.a.kamble@intel.com>"
>
> RECIPE_STATUS_pn-cmake-native="green"
> @@ -5922,9 +5933,6 @@ RECIPE_COMMENTS_pn-pseudo = "Yocto Project maintained"
> RECIPE_MANUAL_CHECK_DATE_pn-pseudo = "Jun 06, 2011"
> DISTRO_PN_ALIAS_pn-pseudo = "Windriver"
>
> -DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-progs"
> -RECIPE_MAINTAINER_pn-btrfs-tools = "Nitin A Kamble <nitin.a.kamble@intel.com>"
> -
> DISTRO_PN_ALIAS_pn-rt-tests = "Debian=rt-tests Ubuntu=rt-tests"
> RECIPE_MAINTAINER_pn-rt-tests = "Darren Hart <dvhart@linux.intel.com>"
>
> --
> 1.7.6.2
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
2011-10-19 8:30 ` Koen Kooi
@ 2011-10-19 15:49 ` Kamble, Nitin A
2011-10-19 15:52 ` Koen Kooi
0 siblings, 1 reply; 38+ messages in thread
From: Kamble, Nitin A @ 2011-10-19 15:49 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Koen,
Why do you ask ?
Nitin
> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Koen Kooi
> Sent: Wednesday, October 19, 2011 1:31 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking:
> update data for some toolchain recipes
>
> btrfs-tools is a toolchain recipe?!?!?!
>
>
>
> Op 19 okt. 2011, om 10:28 heeft Saul Wold het volgende geschreven:
>
> > From: Nitin A Kamble <nitin.a.kamble@intel.com>
> >
> > Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
> > ---
> > .../conf/distro/include/distro_tracking_fields.inc | 42
> ++++++++++++--------
> > 1 files changed, 25 insertions(+), 17 deletions(-)
> >
> > diff --git a/meta/conf/distro/include/distro_tracking_fields.inc
> b/meta/conf/distro/include/distro_tracking_fields.inc
> > index abc2cbf..e68bbe1 100644
> > --- a/meta/conf/distro/include/distro_tracking_fields.inc
> > +++ b/meta/conf/distro/include/distro_tracking_fields.inc
> > @@ -3005,11 +3005,19 @@ RECIPE_STATUS_pn-run-postinsts="green" # all
> local code
> > RECIPE_LATEST_VERSION_pn-postinsts="1.0"
> > RECIPE_MAINTAINER_pn-postinsts = "Nitin A Kamble
> <nitin.a.kamble@intel.com>"
> >
> > -RECIPE_STATUS_pn-nasm="green"
> > +RECIPE_STATUS_pn-nasm="green"
> > RECIPE_LATEST_VERSION_pn-nasm="2.07"
> > -RECIPE_MANUAL_CHECK_DATE_pn-nasm = "Jul 06, 2011"
> > +RECIPE_MANUAL_CHECK_DATE_pn-nasm = "Oct 18, 2011"
> > +RECIPE_LAST_UPDATE_pn-nasm = "Jun 23, 2010"
> > RECIPE_MAINTAINER_pn-nasm = "Nitin A Kamble
> <nitin.a.kamble@intel.com>"
> >
> > +RECIPE_STATUS_pn-btrfs-tools="green"
> > +RECIPE_LATEST_VERSION_pn-btrfs-tools="git"
> > +RECIPE_MANUAL_CHECK_DATE_pn-btrfs-tools = "Oct 18, 2011"
> > +RECIPE_LAST_UPDATE_pn-btrfs-tools = "Jun 09, 2011"
> > +RECIPE_MAINTAINER_pn-btrfs-tools = "Nitin A Kamble
> <nitin.a.kamble@intel.com>"
> > +DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-
> progs"
> > +
> > RECIPE_STATUS_pn-perl="red" # upgrade needed
> > RECIPE_LATEST_VERSION_pn-perl="5.12.1"
> > RECIPE_LAST_UPDATE_pn-perl = "May 27, 2007"
> > @@ -3020,9 +3028,9 @@ RECIPE_LATEST_VERSION_pn-
> prelink="1.0+git0+0x909470ee441237563d6236c505cb2d02ddc
> > RECIPE_LAST_UPDATE_pn-perl = "Jul 23, 2010"
> > RECIPE_MAINTAINER_pn-prelink = "Mark Hatle
> <mark.hatle@windriver.com>"
> >
> > -RECIPE_STATUS_pn-python-dbus="red"
> > -RECIPE_LATEST_VERSION_pn-python-dbus="0.83.1"
> > -RECIPE_LAST_UPDATE_pn-python-dbus = "Jul 7, 2010"
> > +RECIPE_STATUS_pn-python-dbus="green"
> > +RECIPE_LATEST_VERSION_pn-python-dbus="0.84.0"
> > +RECIPE_LAST_UPDATE_pn-python-dbus = "Oct 18, 2011"
> > RECIPE_MAINTAINER_pn-python-dbus = "Nitin A Kamble
> <nitin.a.kamble@intel.com>"
> > DISTRO_PN_ALIAS_pn-python-dbus = "Ubuntu=python-dbus Debian=python-
> dbus Mandriva=python-dbus"
> >
> > @@ -3062,7 +3070,8 @@ RECIPE_MAINTAINER_pn-python-pyrex = "Nitin A
> Kamble <nitin.a.kamble@intel.com>"
> > DISTRO_PN_ALIAS_pn-python-pyrex = "Mandriva=python-pyrex
> Ubuntu=python-pyrex"
> >
> > RECIPE_STATUS_pn-python-scons="green"
> > -RECIPE_LATEST_VERSION_pn-python-scons="2.0.1"
> > +RECIPE_LATEST_VERSION_pn-python-scons="2.1.0"
> > +RECIPE_LAST_UPDATE_pn-python-scons = "Oct 18, 2011"
> > DISTRO_PN_ALIAS_pn-python-scons = "Fedora=scons OpenSuSE=scons
> Ubuntu=scons Mandriva=scons Debian=scons"
> > RECIPE_LAST_UPDATE_pn-python-scons = "Nov 8, 2010"
> > RECIPE_MAINTAINER_pn-python-scons = "Nitin A Kamble
> <nitin.a.kamble@intel.com>"
> > @@ -3087,15 +3096,16 @@ RECIPE_LATEST_VERSION_pn-unifdef="2.6.18+git"
> > RECIPE_MAINTAINER_pn-unifdef = "Nitin A Kamble
> <nitin.a.kamble@intel.com>"
> >
> > RECIPE_STATUS_pn-gnu-config="green"
> > -RECIPE_LATEST_VERSION_pn-gnu-config="0.0+git3155524"
> > +RECIPE_LATEST_VERSION_pn-gnu-config="svn"
> > DISTRO_PN_ALIAS_pn-gnu-config = "OpenedHand"
> > RECIPE_LAST_UPDATE_pn-gnu-config = "Jun 21, 2010"
> > -RECIPE_MANUAL_CHECK_DATE_pn-gnu-config = "Jul 06, 2011"
> > +RECIPE_MANUAL_CHECK_DATE_pn-gnu-config = "Oct 18, 2011"
> > RECIPE_MAINTAINER_pn-gnu-config = "Nitin A Kamble
> <nitin.a.kamble@intel.com>"
> >
> > RECIPE_STATUS_pn-mpfr="green"
> > -RECIPE_LATEST_VERSION_pn-mpfr="3.0.0"
> > -RECIPE_MANUAL_CHECK_DATE_pn-mpfr = "Jul 06, 2011"
> > +RECIPE_LATEST_VERSION_pn-mpfr="3.0.1"
> > +RECIPE_MANUAL_CHECK_DATE_pn-mpfr = "Oct 18, 2011"
> > +RECIPE_LAST_UPDATE_pn-mpfr = "Apr 07, 2011"
> > RECIPE_MAINTAINER_pn-mpfr = "Nitin A Kamble
> <nitin.a.kamble@intel.com>"
> >
> > RECIPE_STATUS_pn-gmp="green"
> > @@ -3110,9 +3120,10 @@ RECIPE_MANUAL_CHECK_DATE_pn-libmpc = "Jan 25,
> 2011"
> > RECIPE_MAINTAINER_pn-libmpc = "Nitin A Kamble
> <nitin.a.kamble@intel.com>"
> > DISTRO_PN_ALIAS_pn-libmpc = "Fedora=libmpc OpenSuse=libmpc2"
> >
> > -RECIPE_STATUS_pn-byacc="red"
> > +RECIPE_STATUS_pn-byacc="green"
> > RECIPE_LATEST_VERSION_pn-byacc="20101229"
> > -RECIPE_MANUAL_CHECK_DATE_pn-byacc = "Jul 06, 2011"
> > +RECIPE_MANUAL_CHECK_DATE_pn-byacc = "Oct 18, 2011"
> > +RECIPE_LAST_UPDATE_pn-byacc = "Oct 18, 2010"
> > RECIPE_MAINTAINER_pn-byacc = "Nitin A Kamble
> <nitin.a.kamble@intel.com>"
> >
> > RECIPE_STATUS_pn-libconvert-asn1-perl="green"
> > @@ -3122,8 +3133,8 @@ RECIPE_LAST_UPDATE_pn-libconvert-asn1-perl =
> "Aug 13, 2010"
> > RECIPE_MAINTAINER_pn-libconvert-asn1-perl = "Nitin A Kamble
> <nitin.a.kamble@intel.com>"
> >
> > RECIPE_STATUS_pn-libxml-parser-perl="green"
> > -RECIPE_LATEST_VERSION_pn-libxml-parser-perl="2.36"
> > -RECIPE_LAST_UPDATE_pn-libxml-parser-perl = "Nov 18, 2009"
> > +RECIPE_LATEST_VERSION_pn-libxml-parser-perl="2.41"
> > +RECIPE_LAST_UPDATE_pn-libxml-parser-perl = "Oct 18, 2011"
> > RECIPE_MAINTAINER_pn-libxml-parser-perl = "Nitin A Kamble
> <nitin.a.kamble@intel.com>"
> >
> > RECIPE_STATUS_pn-cmake-native="green"
> > @@ -5922,9 +5933,6 @@ RECIPE_COMMENTS_pn-pseudo = "Yocto Project
> maintained"
> > RECIPE_MANUAL_CHECK_DATE_pn-pseudo = "Jun 06, 2011"
> > DISTRO_PN_ALIAS_pn-pseudo = "Windriver"
> >
> > -DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-
> progs"
> > -RECIPE_MAINTAINER_pn-btrfs-tools = "Nitin A Kamble
> <nitin.a.kamble@intel.com>"
> > -
> > DISTRO_PN_ALIAS_pn-rt-tests = "Debian=rt-tests Ubuntu=rt-tests"
> > RECIPE_MAINTAINER_pn-rt-tests = "Darren Hart
> <dvhart@linux.intel.com>"
> >
> > --
> > 1.7.6.2
> >
> >
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
2011-10-19 15:49 ` Kamble, Nitin A
@ 2011-10-19 15:52 ` Koen Kooi
2011-10-19 16:24 ` Kamble, Nitin A
0 siblings, 1 reply; 38+ messages in thread
From: Koen Kooi @ 2011-10-19 15:52 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Op 19 okt. 2011, om 17:49 heeft Kamble, Nitin A het volgende geschreven:
> Koen,
> Why do you ask ?
Because I want the commit message to match to commit and now it doesn't.
>
> Nitin
>
>> -----Original Message-----
>> From: openembedded-core-bounces@lists.openembedded.org
>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
>> Koen Kooi
>> Sent: Wednesday, October 19, 2011 1:31 AM
>> To: Patches and discussions about the oe-core layer
>> Subject: Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking:
>> update data for some toolchain recipes
>>
>> btrfs-tools is a toolchain recipe?!?!?!
>>
>>
>>
>> Op 19 okt. 2011, om 10:28 heeft Saul Wold het volgende geschreven:
>>
>>> From: Nitin A Kamble <nitin.a.kamble@intel.com>
>>>
>>> Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
>>> ---
>>> .../conf/distro/include/distro_tracking_fields.inc | 42
>> ++++++++++++--------
>>> 1 files changed, 25 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/meta/conf/distro/include/distro_tracking_fields.inc
>> b/meta/conf/distro/include/distro_tracking_fields.inc
>>> index abc2cbf..e68bbe1 100644
>>> --- a/meta/conf/distro/include/distro_tracking_fields.inc
>>> +++ b/meta/conf/distro/include/distro_tracking_fields.inc
>>> @@ -3005,11 +3005,19 @@ RECIPE_STATUS_pn-run-postinsts="green" # all
>> local code
>>> RECIPE_LATEST_VERSION_pn-postinsts="1.0"
>>> RECIPE_MAINTAINER_pn-postinsts = "Nitin A Kamble
>> <nitin.a.kamble@intel.com>"
>>>
>>> -RECIPE_STATUS_pn-nasm="green"
>>> +RECIPE_STATUS_pn-nasm="green"
>>> RECIPE_LATEST_VERSION_pn-nasm="2.07"
>>> -RECIPE_MANUAL_CHECK_DATE_pn-nasm = "Jul 06, 2011"
>>> +RECIPE_MANUAL_CHECK_DATE_pn-nasm = "Oct 18, 2011"
>>> +RECIPE_LAST_UPDATE_pn-nasm = "Jun 23, 2010"
>>> RECIPE_MAINTAINER_pn-nasm = "Nitin A Kamble
>> <nitin.a.kamble@intel.com>"
>>>
>>> +RECIPE_STATUS_pn-btrfs-tools="green"
>>> +RECIPE_LATEST_VERSION_pn-btrfs-tools="git"
>>> +RECIPE_MANUAL_CHECK_DATE_pn-btrfs-tools = "Oct 18, 2011"
>>> +RECIPE_LAST_UPDATE_pn-btrfs-tools = "Jun 09, 2011"
>>> +RECIPE_MAINTAINER_pn-btrfs-tools = "Nitin A Kamble
>> <nitin.a.kamble@intel.com>"
>>> +DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-
>> progs"
>>> +
>>> RECIPE_STATUS_pn-perl="red" # upgrade needed
>>> RECIPE_LATEST_VERSION_pn-perl="5.12.1"
>>> RECIPE_LAST_UPDATE_pn-perl = "May 27, 2007"
>>> @@ -3020,9 +3028,9 @@ RECIPE_LATEST_VERSION_pn-
>> prelink="1.0+git0+0x909470ee441237563d6236c505cb2d02ddc
>>> RECIPE_LAST_UPDATE_pn-perl = "Jul 23, 2010"
>>> RECIPE_MAINTAINER_pn-prelink = "Mark Hatle
>> <mark.hatle@windriver.com>"
>>>
>>> -RECIPE_STATUS_pn-python-dbus="red"
>>> -RECIPE_LATEST_VERSION_pn-python-dbus="0.83.1"
>>> -RECIPE_LAST_UPDATE_pn-python-dbus = "Jul 7, 2010"
>>> +RECIPE_STATUS_pn-python-dbus="green"
>>> +RECIPE_LATEST_VERSION_pn-python-dbus="0.84.0"
>>> +RECIPE_LAST_UPDATE_pn-python-dbus = "Oct 18, 2011"
>>> RECIPE_MAINTAINER_pn-python-dbus = "Nitin A Kamble
>> <nitin.a.kamble@intel.com>"
>>> DISTRO_PN_ALIAS_pn-python-dbus = "Ubuntu=python-dbus Debian=python-
>> dbus Mandriva=python-dbus"
>>>
>>> @@ -3062,7 +3070,8 @@ RECIPE_MAINTAINER_pn-python-pyrex = "Nitin A
>> Kamble <nitin.a.kamble@intel.com>"
>>> DISTRO_PN_ALIAS_pn-python-pyrex = "Mandriva=python-pyrex
>> Ubuntu=python-pyrex"
>>>
>>> RECIPE_STATUS_pn-python-scons="green"
>>> -RECIPE_LATEST_VERSION_pn-python-scons="2.0.1"
>>> +RECIPE_LATEST_VERSION_pn-python-scons="2.1.0"
>>> +RECIPE_LAST_UPDATE_pn-python-scons = "Oct 18, 2011"
>>> DISTRO_PN_ALIAS_pn-python-scons = "Fedora=scons OpenSuSE=scons
>> Ubuntu=scons Mandriva=scons Debian=scons"
>>> RECIPE_LAST_UPDATE_pn-python-scons = "Nov 8, 2010"
>>> RECIPE_MAINTAINER_pn-python-scons = "Nitin A Kamble
>> <nitin.a.kamble@intel.com>"
>>> @@ -3087,15 +3096,16 @@ RECIPE_LATEST_VERSION_pn-unifdef="2.6.18+git"
>>> RECIPE_MAINTAINER_pn-unifdef = "Nitin A Kamble
>> <nitin.a.kamble@intel.com>"
>>>
>>> RECIPE_STATUS_pn-gnu-config="green"
>>> -RECIPE_LATEST_VERSION_pn-gnu-config="0.0+git3155524"
>>> +RECIPE_LATEST_VERSION_pn-gnu-config="svn"
>>> DISTRO_PN_ALIAS_pn-gnu-config = "OpenedHand"
>>> RECIPE_LAST_UPDATE_pn-gnu-config = "Jun 21, 2010"
>>> -RECIPE_MANUAL_CHECK_DATE_pn-gnu-config = "Jul 06, 2011"
>>> +RECIPE_MANUAL_CHECK_DATE_pn-gnu-config = "Oct 18, 2011"
>>> RECIPE_MAINTAINER_pn-gnu-config = "Nitin A Kamble
>> <nitin.a.kamble@intel.com>"
>>>
>>> RECIPE_STATUS_pn-mpfr="green"
>>> -RECIPE_LATEST_VERSION_pn-mpfr="3.0.0"
>>> -RECIPE_MANUAL_CHECK_DATE_pn-mpfr = "Jul 06, 2011"
>>> +RECIPE_LATEST_VERSION_pn-mpfr="3.0.1"
>>> +RECIPE_MANUAL_CHECK_DATE_pn-mpfr = "Oct 18, 2011"
>>> +RECIPE_LAST_UPDATE_pn-mpfr = "Apr 07, 2011"
>>> RECIPE_MAINTAINER_pn-mpfr = "Nitin A Kamble
>> <nitin.a.kamble@intel.com>"
>>>
>>> RECIPE_STATUS_pn-gmp="green"
>>> @@ -3110,9 +3120,10 @@ RECIPE_MANUAL_CHECK_DATE_pn-libmpc = "Jan 25,
>> 2011"
>>> RECIPE_MAINTAINER_pn-libmpc = "Nitin A Kamble
>> <nitin.a.kamble@intel.com>"
>>> DISTRO_PN_ALIAS_pn-libmpc = "Fedora=libmpc OpenSuse=libmpc2"
>>>
>>> -RECIPE_STATUS_pn-byacc="red"
>>> +RECIPE_STATUS_pn-byacc="green"
>>> RECIPE_LATEST_VERSION_pn-byacc="20101229"
>>> -RECIPE_MANUAL_CHECK_DATE_pn-byacc = "Jul 06, 2011"
>>> +RECIPE_MANUAL_CHECK_DATE_pn-byacc = "Oct 18, 2011"
>>> +RECIPE_LAST_UPDATE_pn-byacc = "Oct 18, 2010"
>>> RECIPE_MAINTAINER_pn-byacc = "Nitin A Kamble
>> <nitin.a.kamble@intel.com>"
>>>
>>> RECIPE_STATUS_pn-libconvert-asn1-perl="green"
>>> @@ -3122,8 +3133,8 @@ RECIPE_LAST_UPDATE_pn-libconvert-asn1-perl =
>> "Aug 13, 2010"
>>> RECIPE_MAINTAINER_pn-libconvert-asn1-perl = "Nitin A Kamble
>> <nitin.a.kamble@intel.com>"
>>>
>>> RECIPE_STATUS_pn-libxml-parser-perl="green"
>>> -RECIPE_LATEST_VERSION_pn-libxml-parser-perl="2.36"
>>> -RECIPE_LAST_UPDATE_pn-libxml-parser-perl = "Nov 18, 2009"
>>> +RECIPE_LATEST_VERSION_pn-libxml-parser-perl="2.41"
>>> +RECIPE_LAST_UPDATE_pn-libxml-parser-perl = "Oct 18, 2011"
>>> RECIPE_MAINTAINER_pn-libxml-parser-perl = "Nitin A Kamble
>> <nitin.a.kamble@intel.com>"
>>>
>>> RECIPE_STATUS_pn-cmake-native="green"
>>> @@ -5922,9 +5933,6 @@ RECIPE_COMMENTS_pn-pseudo = "Yocto Project
>> maintained"
>>> RECIPE_MANUAL_CHECK_DATE_pn-pseudo = "Jun 06, 2011"
>>> DISTRO_PN_ALIAS_pn-pseudo = "Windriver"
>>>
>>> -DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-
>> progs"
>>> -RECIPE_MAINTAINER_pn-btrfs-tools = "Nitin A Kamble
>> <nitin.a.kamble@intel.com>"
>>> -
>>> DISTRO_PN_ALIAS_pn-rt-tests = "Debian=rt-tests Ubuntu=rt-tests"
>>> RECIPE_MAINTAINER_pn-rt-tests = "Darren Hart
>> <dvhart@linux.intel.com>"
>>>
>>> --
>>> 1.7.6.2
>>>
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
2011-10-19 15:52 ` Koen Kooi
@ 2011-10-19 16:24 ` Kamble, Nitin A
2011-10-19 16:37 ` Koen Kooi
0 siblings, 1 reply; 38+ messages in thread
From: Kamble, Nitin A @ 2011-10-19 16:24 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Koen Kooi
> Sent: Wednesday, October 19, 2011 8:52 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking:
> update data for some toolchain recipes
>
>
> Op 19 okt. 2011, om 17:49 heeft Kamble, Nitin A het volgende
> geschreven:
>
> > Koen,
> > Why do you ask ?
>
> Because I want the commit message to match to commit and now it
> doesn't.
>
It will be too many recipes to list on one line, shall I split the commit into multiple one for each recipe whose data is changed?
Nitin
> >
> > Nitin
> >
> >> -----Original Message-----
> >> From: openembedded-core-bounces@lists.openembedded.org
> >> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf
> Of
> >> Koen Kooi
> >> Sent: Wednesday, October 19, 2011 1:31 AM
> >> To: Patches and discussions about the oe-core layer
> >> Subject: Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking:
> >> update data for some toolchain recipes
> >>
> >> btrfs-tools is a toolchain recipe?!?!?!
> >>
> >>
> >>
> >> Op 19 okt. 2011, om 10:28 heeft Saul Wold het volgende geschreven:
> >>
> >>> From: Nitin A Kamble <nitin.a.kamble@intel.com>
> >>>
> >>> Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
> >>> ---
> >>> .../conf/distro/include/distro_tracking_fields.inc | 42
> >> ++++++++++++--------
> >>> 1 files changed, 25 insertions(+), 17 deletions(-)
> >>>
> >>> diff --git a/meta/conf/distro/include/distro_tracking_fields.inc
> >> b/meta/conf/distro/include/distro_tracking_fields.inc
> >>> index abc2cbf..e68bbe1 100644
> >>> --- a/meta/conf/distro/include/distro_tracking_fields.inc
> >>> +++ b/meta/conf/distro/include/distro_tracking_fields.inc
> >>> @@ -3005,11 +3005,19 @@ RECIPE_STATUS_pn-run-postinsts="green" #
> all
> >> local code
> >>> RECIPE_LATEST_VERSION_pn-postinsts="1.0"
> >>> RECIPE_MAINTAINER_pn-postinsts = "Nitin A Kamble
> >> <nitin.a.kamble@intel.com>"
> >>>
> >>> -RECIPE_STATUS_pn-nasm="green"
> >>> +RECIPE_STATUS_pn-nasm="green"
> >>> RECIPE_LATEST_VERSION_pn-nasm="2.07"
> >>> -RECIPE_MANUAL_CHECK_DATE_pn-nasm = "Jul 06, 2011"
> >>> +RECIPE_MANUAL_CHECK_DATE_pn-nasm = "Oct 18, 2011"
> >>> +RECIPE_LAST_UPDATE_pn-nasm = "Jun 23, 2010"
> >>> RECIPE_MAINTAINER_pn-nasm = "Nitin A Kamble
> >> <nitin.a.kamble@intel.com>"
> >>>
> >>> +RECIPE_STATUS_pn-btrfs-tools="green"
> >>> +RECIPE_LATEST_VERSION_pn-btrfs-tools="git"
> >>> +RECIPE_MANUAL_CHECK_DATE_pn-btrfs-tools = "Oct 18, 2011"
> >>> +RECIPE_LAST_UPDATE_pn-btrfs-tools = "Jun 09, 2011"
> >>> +RECIPE_MAINTAINER_pn-btrfs-tools = "Nitin A Kamble
> >> <nitin.a.kamble@intel.com>"
> >>> +DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-
> >> progs"
> >>> +
> >>> RECIPE_STATUS_pn-perl="red" # upgrade needed
> >>> RECIPE_LATEST_VERSION_pn-perl="5.12.1"
> >>> RECIPE_LAST_UPDATE_pn-perl = "May 27, 2007"
> >>> @@ -3020,9 +3028,9 @@ RECIPE_LATEST_VERSION_pn-
> >> prelink="1.0+git0+0x909470ee441237563d6236c505cb2d02ddc
> >>> RECIPE_LAST_UPDATE_pn-perl = "Jul 23, 2010"
> >>> RECIPE_MAINTAINER_pn-prelink = "Mark Hatle
> >> <mark.hatle@windriver.com>"
> >>>
> >>> -RECIPE_STATUS_pn-python-dbus="red"
> >>> -RECIPE_LATEST_VERSION_pn-python-dbus="0.83.1"
> >>> -RECIPE_LAST_UPDATE_pn-python-dbus = "Jul 7, 2010"
> >>> +RECIPE_STATUS_pn-python-dbus="green"
> >>> +RECIPE_LATEST_VERSION_pn-python-dbus="0.84.0"
> >>> +RECIPE_LAST_UPDATE_pn-python-dbus = "Oct 18, 2011"
> >>> RECIPE_MAINTAINER_pn-python-dbus = "Nitin A Kamble
> >> <nitin.a.kamble@intel.com>"
> >>> DISTRO_PN_ALIAS_pn-python-dbus = "Ubuntu=python-dbus Debian=python-
> >> dbus Mandriva=python-dbus"
> >>>
> >>> @@ -3062,7 +3070,8 @@ RECIPE_MAINTAINER_pn-python-pyrex = "Nitin A
> >> Kamble <nitin.a.kamble@intel.com>"
> >>> DISTRO_PN_ALIAS_pn-python-pyrex = "Mandriva=python-pyrex
> >> Ubuntu=python-pyrex"
> >>>
> >>> RECIPE_STATUS_pn-python-scons="green"
> >>> -RECIPE_LATEST_VERSION_pn-python-scons="2.0.1"
> >>> +RECIPE_LATEST_VERSION_pn-python-scons="2.1.0"
> >>> +RECIPE_LAST_UPDATE_pn-python-scons = "Oct 18, 2011"
> >>> DISTRO_PN_ALIAS_pn-python-scons = "Fedora=scons OpenSuSE=scons
> >> Ubuntu=scons Mandriva=scons Debian=scons"
> >>> RECIPE_LAST_UPDATE_pn-python-scons = "Nov 8, 2010"
> >>> RECIPE_MAINTAINER_pn-python-scons = "Nitin A Kamble
> >> <nitin.a.kamble@intel.com>"
> >>> @@ -3087,15 +3096,16 @@ RECIPE_LATEST_VERSION_pn-
> unifdef="2.6.18+git"
> >>> RECIPE_MAINTAINER_pn-unifdef = "Nitin A Kamble
> >> <nitin.a.kamble@intel.com>"
> >>>
> >>> RECIPE_STATUS_pn-gnu-config="green"
> >>> -RECIPE_LATEST_VERSION_pn-gnu-config="0.0+git3155524"
> >>> +RECIPE_LATEST_VERSION_pn-gnu-config="svn"
> >>> DISTRO_PN_ALIAS_pn-gnu-config = "OpenedHand"
> >>> RECIPE_LAST_UPDATE_pn-gnu-config = "Jun 21, 2010"
> >>> -RECIPE_MANUAL_CHECK_DATE_pn-gnu-config = "Jul 06, 2011"
> >>> +RECIPE_MANUAL_CHECK_DATE_pn-gnu-config = "Oct 18, 2011"
> >>> RECIPE_MAINTAINER_pn-gnu-config = "Nitin A Kamble
> >> <nitin.a.kamble@intel.com>"
> >>>
> >>> RECIPE_STATUS_pn-mpfr="green"
> >>> -RECIPE_LATEST_VERSION_pn-mpfr="3.0.0"
> >>> -RECIPE_MANUAL_CHECK_DATE_pn-mpfr = "Jul 06, 2011"
> >>> +RECIPE_LATEST_VERSION_pn-mpfr="3.0.1"
> >>> +RECIPE_MANUAL_CHECK_DATE_pn-mpfr = "Oct 18, 2011"
> >>> +RECIPE_LAST_UPDATE_pn-mpfr = "Apr 07, 2011"
> >>> RECIPE_MAINTAINER_pn-mpfr = "Nitin A Kamble
> >> <nitin.a.kamble@intel.com>"
> >>>
> >>> RECIPE_STATUS_pn-gmp="green"
> >>> @@ -3110,9 +3120,10 @@ RECIPE_MANUAL_CHECK_DATE_pn-libmpc = "Jan
> 25,
> >> 2011"
> >>> RECIPE_MAINTAINER_pn-libmpc = "Nitin A Kamble
> >> <nitin.a.kamble@intel.com>"
> >>> DISTRO_PN_ALIAS_pn-libmpc = "Fedora=libmpc OpenSuse=libmpc2"
> >>>
> >>> -RECIPE_STATUS_pn-byacc="red"
> >>> +RECIPE_STATUS_pn-byacc="green"
> >>> RECIPE_LATEST_VERSION_pn-byacc="20101229"
> >>> -RECIPE_MANUAL_CHECK_DATE_pn-byacc = "Jul 06, 2011"
> >>> +RECIPE_MANUAL_CHECK_DATE_pn-byacc = "Oct 18, 2011"
> >>> +RECIPE_LAST_UPDATE_pn-byacc = "Oct 18, 2010"
> >>> RECIPE_MAINTAINER_pn-byacc = "Nitin A Kamble
> >> <nitin.a.kamble@intel.com>"
> >>>
> >>> RECIPE_STATUS_pn-libconvert-asn1-perl="green"
> >>> @@ -3122,8 +3133,8 @@ RECIPE_LAST_UPDATE_pn-libconvert-asn1-perl =
> >> "Aug 13, 2010"
> >>> RECIPE_MAINTAINER_pn-libconvert-asn1-perl = "Nitin A Kamble
> >> <nitin.a.kamble@intel.com>"
> >>>
> >>> RECIPE_STATUS_pn-libxml-parser-perl="green"
> >>> -RECIPE_LATEST_VERSION_pn-libxml-parser-perl="2.36"
> >>> -RECIPE_LAST_UPDATE_pn-libxml-parser-perl = "Nov 18, 2009"
> >>> +RECIPE_LATEST_VERSION_pn-libxml-parser-perl="2.41"
> >>> +RECIPE_LAST_UPDATE_pn-libxml-parser-perl = "Oct 18, 2011"
> >>> RECIPE_MAINTAINER_pn-libxml-parser-perl = "Nitin A Kamble
> >> <nitin.a.kamble@intel.com>"
> >>>
> >>> RECIPE_STATUS_pn-cmake-native="green"
> >>> @@ -5922,9 +5933,6 @@ RECIPE_COMMENTS_pn-pseudo = "Yocto Project
> >> maintained"
> >>> RECIPE_MANUAL_CHECK_DATE_pn-pseudo = "Jun 06, 2011"
> >>> DISTRO_PN_ALIAS_pn-pseudo = "Windriver"
> >>>
> >>> -DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-
> >> progs"
> >>> -RECIPE_MAINTAINER_pn-btrfs-tools = "Nitin A Kamble
> >> <nitin.a.kamble@intel.com>"
> >>> -
> >>> DISTRO_PN_ALIAS_pn-rt-tests = "Debian=rt-tests Ubuntu=rt-tests"
> >>> RECIPE_MAINTAINER_pn-rt-tests = "Darren Hart
> >> <dvhart@linux.intel.com>"
> >>>
> >>> --
> >>> 1.7.6.2
> >>>
> >>>
> >>> _______________________________________________
> >>> Openembedded-core mailing list
> >>> Openembedded-core@lists.openembedded.org
> >>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-
> core
> >>
> >>
> >> _______________________________________________
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-
> core
> >
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
2011-10-19 16:24 ` Kamble, Nitin A
@ 2011-10-19 16:37 ` Koen Kooi
2011-10-19 16:49 ` Phil Blundell
0 siblings, 1 reply; 38+ messages in thread
From: Koen Kooi @ 2011-10-19 16:37 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Op 19 okt. 2011, om 18:24 heeft Kamble, Nitin A het volgende geschreven:
>
>
>> -----Original Message-----
>> From: openembedded-core-bounces@lists.openembedded.org
>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
>> Koen Kooi
>> Sent: Wednesday, October 19, 2011 8:52 AM
>> To: Patches and discussions about the oe-core layer
>> Subject: Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking:
>> update data for some toolchain recipes
>>
>>
>> Op 19 okt. 2011, om 17:49 heeft Kamble, Nitin A het volgende
>> geschreven:
>>
>>> Koen,
>>> Why do you ask ?
>>
>> Because I want the commit message to match to commit and now it
>> doesn't.
>>
> It will be too many recipes to list on one line, shall I split the commit into multiple one for each recipe whose data is changed?
Or per group, but saying "some toolchain recipes" is way too vague.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
2011-10-19 16:37 ` Koen Kooi
@ 2011-10-19 16:49 ` Phil Blundell
2011-10-19 16:57 ` Saul Wold
0 siblings, 1 reply; 38+ messages in thread
From: Phil Blundell @ 2011-10-19 16:49 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Wed, 2011-10-19 at 18:37 +0200, Koen Kooi wrote:
> Op 19 okt. 2011, om 18:24 heeft Kamble, Nitin A het volgende geschreven:
> > It will be too many recipes to list on one line, shall I split the commit into multiple one for each recipe whose data is changed?
>
> Or per group, but saying "some toolchain recipes" is way too vague.
Why do we have this distro tracking data in oe-core git anyway? I'm not
entirely clear on what it's used by.
p.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
2011-10-19 16:49 ` Phil Blundell
@ 2011-10-19 16:57 ` Saul Wold
2011-10-19 17:00 ` Khem Raj
0 siblings, 1 reply; 38+ messages in thread
From: Saul Wold @ 2011-10-19 16:57 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Phil Blundell
On 10/19/2011 09:49 AM, Phil Blundell wrote:
> On Wed, 2011-10-19 at 18:37 +0200, Koen Kooi wrote:
>> Op 19 okt. 2011, om 18:24 heeft Kamble, Nitin A het volgende geschreven:
>>> It will be too many recipes to list on one line, shall I split the commit into multiple one for each recipe whose data is changed?
>>
>> Or per group, but saying "some toolchain recipes" is way too vague.
>
> Why do we have this distro tracking data in oe-core git anyway? I'm not
> entirely clear on what it's used by.
>
Phil:
It's used by the tools that build http://packages.yoctoproject.org and
to help recipe manage maintainer-ship and track what needs updating.
Many upstreams we can't track if updates are required automagically, so
we need a place to record when the last manual check was, also possible
reasons why we should not update to newer versions, ...
Sau!
> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
2011-10-19 16:57 ` Saul Wold
@ 2011-10-19 17:00 ` Khem Raj
2011-10-19 17:45 ` Saul Wold
0 siblings, 1 reply; 38+ messages in thread
From: Khem Raj @ 2011-10-19 17:00 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Phil Blundell
On Wed, Oct 19, 2011 at 9:57 AM, Saul Wold <saul.wold@intel.com> wrote:
> On 10/19/2011 09:49 AM, Phil Blundell wrote:
>>
>> On Wed, 2011-10-19 at 18:37 +0200, Koen Kooi wrote:
>>>
>>> Op 19 okt. 2011, om 18:24 heeft Kamble, Nitin A het volgende geschreven:
>>>>
>>>> It will be too many recipes to list on one line, shall I split the
>>>> commit into multiple one for each recipe whose data is changed?
>>>
>>> Or per group, but saying "some toolchain recipes" is way too vague.
>>
>> Why do we have this distro tracking data in oe-core git anyway? I'm not
>> entirely clear on what it's used by.
>>
> Phil:
>
> It's used by the tools that build http://packages.yoctoproject.org and to
> help recipe manage maintainer-ship and track what needs updating.
This could be managed via meta-data in packages I believe all that
information is there.
>
> Many upstreams we can't track if updates are required automagically, so we
> need a place to record when the last manual check was, also possible reasons
> why we should not update to newer versions, ...
>
> Sau!
>
>
>> p.
>>
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
2011-10-19 17:00 ` Khem Raj
@ 2011-10-19 17:45 ` Saul Wold
2011-10-19 18:30 ` Khem Raj
0 siblings, 1 reply; 38+ messages in thread
From: Saul Wold @ 2011-10-19 17:45 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Phil Blundell
On 10/19/2011 10:00 AM, Khem Raj wrote:
> On Wed, Oct 19, 2011 at 9:57 AM, Saul Wold<saul.wold@intel.com> wrote:
>> On 10/19/2011 09:49 AM, Phil Blundell wrote:
>>>
>>> On Wed, 2011-10-19 at 18:37 +0200, Koen Kooi wrote:
>>>>
>>>> Op 19 okt. 2011, om 18:24 heeft Kamble, Nitin A het volgende geschreven:
>>>>>
>>>>> It will be too many recipes to list on one line, shall I split the
>>>>> commit into multiple one for each recipe whose data is changed?
>>>>
>>>> Or per group, but saying "some toolchain recipes" is way too vague.
>>>
>>> Why do we have this distro tracking data in oe-core git anyway? I'm not
>>> entirely clear on what it's used by.
>>>
>> Phil:
>>
>> It's used by the tools that build http://packages.yoctoproject.org and to
>> help recipe manage maintainer-ship and track what needs updating.
>
> This could be managed via meta-data in packages I believe all that
> information is there.
>
Khem,
I am not quite following, are you suggesting incorporating the
distro_tracking_fields info into the final packages (this word is
overloaded sometimes), or adding it the recipe bb files?
If adding it to the recipe bb files, this was discussed and deemed
inappropriate, as it's too dynamic and would clutter the recipe.
Sau!
>>
>> Many upstreams we can't track if updates are required automagically, so we
>> need a place to record when the last manual check was, also possible reasons
>> why we should not update to newer versions, ...
>>
>> Sau!
>>
>>
>>> p.
>>>
>>>
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
2011-10-19 17:45 ` Saul Wold
@ 2011-10-19 18:30 ` Khem Raj
2011-10-19 19:00 ` Otavio Salvador
0 siblings, 1 reply; 38+ messages in thread
From: Khem Raj @ 2011-10-19 18:30 UTC (permalink / raw)
To: Saul Wold; +Cc: Phil Blundell, Patches and discussions about the oe-core layer
On Wed, Oct 19, 2011 at 10:45 AM, Saul Wold <saul.wold@intel.com> wrote:
> On 10/19/2011 10:00 AM, Khem Raj wrote:
>>
>> On Wed, Oct 19, 2011 at 9:57 AM, Saul Wold<saul.wold@intel.com> wrote:
>>>
>>> On 10/19/2011 09:49 AM, Phil Blundell wrote:
>>>>
>>>> On Wed, 2011-10-19 at 18:37 +0200, Koen Kooi wrote:
>>>>>
>>>>> Op 19 okt. 2011, om 18:24 heeft Kamble, Nitin A het volgende
>>>>> geschreven:
>>>>>>
>>>>>> It will be too many recipes to list on one line, shall I split the
>>>>>> commit into multiple one for each recipe whose data is changed?
>>>>>
>>>>> Or per group, but saying "some toolchain recipes" is way too vague.
>>>>
>>>> Why do we have this distro tracking data in oe-core git anyway? I'm not
>>>> entirely clear on what it's used by.
>>>>
>>> Phil:
>>>
>>> It's used by the tools that build http://packages.yoctoproject.org and to
>>> help recipe manage maintainer-ship and track what needs updating.
>>
>> This could be managed via meta-data in packages I believe all that
>> information is there.
>>
> Khem,
>
> I am not quite following, are you suggesting incorporating the
> distro_tracking_fields info into the final packages (this word is overloaded
> sometimes), or adding it the recipe bb files?
I think this information is better generated at build time. Since that
will be accurate and the meta data can be
>
> If adding it to the recipe bb files, this was discussed and deemed
> inappropriate, as it's too dynamic and would clutter the recipe.
is it more dynamic than making any other change to the recipe ?
in other words are there chances that you just need to change the
recipe to mark this information.
>
> Sau!
>>>
>>> Many upstreams we can't track if updates are required automagically, so
>>> we
>>> need a place to record when the last manual check was, also possible
>>> reasons
>>> why we should not update to newer versions, ...
hmm manual check means it has to be done manually is there any thing
that needs it ?
I think unless they are distro specific which seems not since they are
in oe-core
they could exist in recipes thats my opinion.
>>>
>>> Sau!
>>>
>>>
>>>> p.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Openembedded-core mailing list
>>>> Openembedded-core@lists.openembedded.org
>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>>
>>>
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
2011-10-19 18:30 ` Khem Raj
@ 2011-10-19 19:00 ` Otavio Salvador
2011-10-19 23:33 ` Saul Wold
2011-10-20 16:02 ` Eric Bénard
0 siblings, 2 replies; 38+ messages in thread
From: Otavio Salvador @ 2011-10-19 19:00 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Phil Blundell, Saul Wold
On Wed, Oct 19, 2011 at 16:30, Khem Raj <raj.khem@gmail.com> wrote:
...
>>>> Many upstreams we can't track if updates are required automagically, so
>>>> we
>>>> need a place to record when the last manual check was, also possible
>>>> reasons
>>>> why we should not update to newer versions, ...
>
> hmm manual check means it has to be done manually is there any thing
> that needs it ?
>
> I think unless they are distro specific which seems not since they are
> in oe-core
> they could exist in recipes thats my opinion.
I agree that this should be put into the recipes. Besides this allows
for checking if it was updated when the version has been updated.
If done right, when updating the version this data will be updated
together. I see no change in the amount of changes.
A plus of this choice is it will be more difficult to forget to update
that info. This happened in last qt update for an example.
--
Otavio Salvador O.S. Systems
E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
2011-10-19 19:00 ` Otavio Salvador
@ 2011-10-19 23:33 ` Saul Wold
2011-10-20 14:25 ` Richard Purdie
2011-10-20 16:02 ` Eric Bénard
1 sibling, 1 reply; 38+ messages in thread
From: Saul Wold @ 2011-10-19 23:33 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Phil Blundell
On 10/19/2011 12:00 PM, Otavio Salvador wrote:
> On Wed, Oct 19, 2011 at 16:30, Khem Raj<raj.khem@gmail.com> wrote:
> ...
>>>>> Many upstreams we can't track if updates are required automagically, so
>>>>> we
>>>>> need a place to record when the last manual check was, also possible
>>>>> reasons
>>>>> why we should not update to newer versions, ...
>>
>> hmm manual check means it has to be done manually is there any thing
>> that needs it ?
>>
>> I think unless they are distro specific which seems not since they are
>> in oe-core
>> they could exist in recipes thats my opinion.
>
> I agree that this should be put into the recipes. Besides this allows
> for checking if it was updated when the version has been updated.
>
> If done right, when updating the version this data will be updated
> together. I see no change in the amount of changes.
>
> A plus of this choice is it will be more difficult to forget to update
> that info. This happened in last qt update for an example.
>
This may need to be something that the TSC brings up, possibly we can
talk about it in Prague next week.
Sau!
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
2011-10-19 23:33 ` Saul Wold
@ 2011-10-20 14:25 ` Richard Purdie
2011-10-20 14:36 ` Martin Jansa
2011-10-20 16:18 ` Khem Raj
0 siblings, 2 replies; 38+ messages in thread
From: Richard Purdie @ 2011-10-20 14:25 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Phil Blundell
On Wed, 2011-10-19 at 16:33 -0700, Saul Wold wrote:
> On 10/19/2011 12:00 PM, Otavio Salvador wrote:
> > On Wed, Oct 19, 2011 at 16:30, Khem Raj<raj.khem@gmail.com> wrote:
> > ...
> >>>>> Many upstreams we can't track if updates are required automagically, so
> >>>>> we
> >>>>> need a place to record when the last manual check was, also possible
> >>>>> reasons
> >>>>> why we should not update to newer versions, ...
> >>
> >> hmm manual check means it has to be done manually is there any thing
> >> that needs it ?
> >>
> >> I think unless they are distro specific which seems not since they are
> >> in oe-core
> >> they could exist in recipes thats my opinion.
> >
> > I agree that this should be put into the recipes. Besides this allows
> > for checking if it was updated when the version has been updated.
> >
> > If done right, when updating the version this data will be updated
> > together. I see no change in the amount of changes.
> >
> > A plus of this choice is it will be more difficult to forget to update
> > that info. This happened in last qt update for an example.
> >
>
> This may need to be something that the TSC brings up, possibly we can
> talk about it in Prague next week.
So just to give some background here, the information in those files was
added by Yocto people to give some idea of the update status of various
recipes. This included when the version was last checked/updated for
recipes which we can't automate that process for, when certain cleanup
checks were made, what the general state of the recipe was and who on
the Yocto team was specifically looking after given recipes.
When it was discussed, some of it was Yocto specific, some of it wasn't
and popular opinion was against it going into the recipes themselves. I
was ok with that given we have the pn- overrides and can handle the
problem that way just fine.
OE-Core happened and we kept the data with OE-Core at least for now. We
have several options:
a) Keep the data where it is
b) Merge the data into the recipes
c) Move the data out of OE-Core
Since a lot of that data is fairly Yocto process specific, it may make
sense to move it over to meta-yocto...
Cheers,
Richard
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
2011-10-20 14:25 ` Richard Purdie
@ 2011-10-20 14:36 ` Martin Jansa
2011-10-20 14:48 ` Koen Kooi
2011-10-20 15:55 ` Richard Purdie
2011-10-20 16:18 ` Khem Raj
1 sibling, 2 replies; 38+ messages in thread
From: Martin Jansa @ 2011-10-20 14:36 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 3286 bytes --]
On Thu, Oct 20, 2011 at 03:25:52PM +0100, Richard Purdie wrote:
> On Wed, 2011-10-19 at 16:33 -0700, Saul Wold wrote:
> > On 10/19/2011 12:00 PM, Otavio Salvador wrote:
> > > On Wed, Oct 19, 2011 at 16:30, Khem Raj<raj.khem@gmail.com> wrote:
> > > ...
> > >>>>> Many upstreams we can't track if updates are required automagically, so
> > >>>>> we
> > >>>>> need a place to record when the last manual check was, also possible
> > >>>>> reasons
> > >>>>> why we should not update to newer versions, ...
> > >>
> > >> hmm manual check means it has to be done manually is there any thing
> > >> that needs it ?
> > >>
> > >> I think unless they are distro specific which seems not since they are
> > >> in oe-core
> > >> they could exist in recipes thats my opinion.
> > >
> > > I agree that this should be put into the recipes. Besides this allows
> > > for checking if it was updated when the version has been updated.
> > >
> > > If done right, when updating the version this data will be updated
> > > together. I see no change in the amount of changes.
> > >
> > > A plus of this choice is it will be more difficult to forget to update
> > > that info. This happened in last qt update for an example.
> > >
> >
> > This may need to be something that the TSC brings up, possibly we can
> > talk about it in Prague next week.
>
> So just to give some background here, the information in those files was
> added by Yocto people to give some idea of the update status of various
> recipes. This included when the version was last checked/updated for
> recipes which we can't automate that process for, when certain cleanup
> checks were made, what the general state of the recipe was and who on
> the Yocto team was specifically looking after given recipes.
>
> When it was discussed, some of it was Yocto specific, some of it wasn't
> and popular opinion was against it going into the recipes themselves. I
> was ok with that given we have the pn- overrides and can handle the
> problem that way just fine.
>
> OE-Core happened and we kept the data with OE-Core at least for now. We
> have several options:
>
> a) Keep the data where it is
> b) Merge the data into the recipes
> c) Move the data out of OE-Core
>
> Since a lot of that data is fairly Yocto process specific, it may make
> sense to move it over to meta-yocto...
I don't like "global" files where many people should maintain their info
and it's so easy to forgot when it's somewhere else then real changes
(like it was with checksums.ini and sane-src*.ini).
So I vote for b) Merge the data into the recipes, only problem with this
is that if we have 2 versions of foo (foo_1.0.bb, foo_git.bb) without
any foo.inc, will we create foo.inc just for distro-tracking info? Maybe
we should and move at least DESCRIPTION and similar variables too.
c) moving it to meta-yocto will probably make distro-tracking info even
more outdated as sometimes different people then who did upgrade in
oe-core will have to update distro-tracking info in this layer (this is
also the case now sometimes, but with distro-tracking info in recipe we
can try better to update it with upgrades).
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
2011-10-20 14:36 ` Martin Jansa
@ 2011-10-20 14:48 ` Koen Kooi
2011-10-20 15:55 ` Richard Purdie
1 sibling, 0 replies; 38+ messages in thread
From: Koen Kooi @ 2011-10-20 14:48 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Op 20 okt. 2011, om 16:36 heeft Martin Jansa het volgende geschreven:
> On Thu, Oct 20, 2011 at 03:25:52PM +0100, Richard Purdie wrote:
>> On Wed, 2011-10-19 at 16:33 -0700, Saul Wold wrote:
>>> On 10/19/2011 12:00 PM, Otavio Salvador wrote:
>>>> On Wed, Oct 19, 2011 at 16:30, Khem Raj<raj.khem@gmail.com> wrote:
>>>> ...
>>>>>>>> Many upstreams we can't track if updates are required automagically, so
>>>>>>>> we
>>>>>>>> need a place to record when the last manual check was, also possible
>>>>>>>> reasons
>>>>>>>> why we should not update to newer versions, ...
>>>>>
>>>>> hmm manual check means it has to be done manually is there any thing
>>>>> that needs it ?
>>>>>
>>>>> I think unless they are distro specific which seems not since they are
>>>>> in oe-core
>>>>> they could exist in recipes thats my opinion.
>>>>
>>>> I agree that this should be put into the recipes. Besides this allows
>>>> for checking if it was updated when the version has been updated.
>>>>
>>>> If done right, when updating the version this data will be updated
>>>> together. I see no change in the amount of changes.
>>>>
>>>> A plus of this choice is it will be more difficult to forget to update
>>>> that info. This happened in last qt update for an example.
>>>>
>>>
>>> This may need to be something that the TSC brings up, possibly we can
>>> talk about it in Prague next week.
>>
>> So just to give some background here, the information in those files was
>> added by Yocto people to give some idea of the update status of various
>> recipes. This included when the version was last checked/updated for
>> recipes which we can't automate that process for, when certain cleanup
>> checks were made, what the general state of the recipe was and who on
>> the Yocto team was specifically looking after given recipes.
>>
>> When it was discussed, some of it was Yocto specific, some of it wasn't
>> and popular opinion was against it going into the recipes themselves. I
>> was ok with that given we have the pn- overrides and can handle the
>> problem that way just fine.
>>
>> OE-Core happened and we kept the data with OE-Core at least for now. We
>> have several options:
>>
>> a) Keep the data where it is
>> b) Merge the data into the recipes
>> c) Move the data out of OE-Core
>>
>> Since a lot of that data is fairly Yocto process specific, it may make
>> sense to move it over to meta-yocto...
>
> I don't like "global" files where many people should maintain their info
> and it's so easy to forgot when it's somewhere else then real changes
> (like it was with checksums.ini and sane-src*.ini).
>
> So I vote for b) Merge the data into the recipes, only problem with this
> is that if we have 2 versions of foo (foo_1.0.bb, foo_git.bb) without
> any foo.inc, will we create foo.inc just for distro-tracking info? Maybe
> we should and move at least DESCRIPTION and similar variables too.
>
> c) moving it to meta-yocto will probably make distro-tracking info even
> more outdated as sometimes different people then who did upgrade in
> oe-core will have to update distro-tracking info in this layer (this is
> also the case now sometimes, but with distro-tracking info in recipe we
> can try better to update it with upgrades).
I agree completely with Martin.
regards,
Koen
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
2011-10-20 14:36 ` Martin Jansa
2011-10-20 14:48 ` Koen Kooi
@ 2011-10-20 15:55 ` Richard Purdie
2011-10-20 16:24 ` Koen Kooi
2011-10-20 21:28 ` Saul Wold
1 sibling, 2 replies; 38+ messages in thread
From: Richard Purdie @ 2011-10-20 15:55 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Thu, 2011-10-20 at 16:36 +0200, Martin Jansa wrote:
> On Thu, Oct 20, 2011 at 03:25:52PM +0100, Richard Purdie wrote:
> > On Wed, 2011-10-19 at 16:33 -0700, Saul Wold wrote:
> > > On 10/19/2011 12:00 PM, Otavio Salvador wrote:
> > > > On Wed, Oct 19, 2011 at 16:30, Khem Raj<raj.khem@gmail.com> wrote:
> > > > ...
> > > >>>>> Many upstreams we can't track if updates are required automagically, so
> > > >>>>> we
> > > >>>>> need a place to record when the last manual check was, also possible
> > > >>>>> reasons
> > > >>>>> why we should not update to newer versions, ...
> > > >>
> > > >> hmm manual check means it has to be done manually is there any thing
> > > >> that needs it ?
> > > >>
> > > >> I think unless they are distro specific which seems not since they are
> > > >> in oe-core
> > > >> they could exist in recipes thats my opinion.
> > > >
> > > > I agree that this should be put into the recipes. Besides this allows
> > > > for checking if it was updated when the version has been updated.
> > > >
> > > > If done right, when updating the version this data will be updated
> > > > together. I see no change in the amount of changes.
> > > >
> > > > A plus of this choice is it will be more difficult to forget to update
> > > > that info. This happened in last qt update for an example.
> > > >
> > >
> > > This may need to be something that the TSC brings up, possibly we can
> > > talk about it in Prague next week.
> >
> > So just to give some background here, the information in those files was
> > added by Yocto people to give some idea of the update status of various
> > recipes. This included when the version was last checked/updated for
> > recipes which we can't automate that process for, when certain cleanup
> > checks were made, what the general state of the recipe was and who on
> > the Yocto team was specifically looking after given recipes.
> >
> > When it was discussed, some of it was Yocto specific, some of it wasn't
> > and popular opinion was against it going into the recipes themselves. I
> > was ok with that given we have the pn- overrides and can handle the
> > problem that way just fine.
> >
> > OE-Core happened and we kept the data with OE-Core at least for now. We
> > have several options:
> >
> > a) Keep the data where it is
> > b) Merge the data into the recipes
> > c) Move the data out of OE-Core
> >
> > Since a lot of that data is fairly Yocto process specific, it may make
> > sense to move it over to meta-yocto...
>
> I don't like "global" files where many people should maintain their info
> and it's so easy to forgot when it's somewhere else then real changes
> (like it was with checksums.ini and sane-src*.ini).
Some data does make sense to be maintained globally and I don't think we
should automatically say its bad. It depends what the use case is and
how its intended to be used.
> So I vote for b) Merge the data into the recipes, only problem with this
> is that if we have 2 versions of foo (foo_1.0.bb, foo_git.bb) without
> any foo.inc, will we create foo.inc just for distro-tracking info? Maybe
> we should and move at least DESCRIPTION and similar variables too.
>
> c) moving it to meta-yocto will probably make distro-tracking info even
> more outdated as sometimes different people then who did upgrade in
> oe-core will have to update distro-tracking info in this layer (this is
> also the case now sometimes, but with distro-tracking info in recipe we
> can try better to update it with upgrades).
I'd actually like Saul's view on this since he generally looks after
that data. There as been discussion about whether it is "internal" yocto
tracking stuff or whether its more general OE focused and I don't know
what the answer is there. I think there is a mixture of uses. I'm also
wary of "pushing" Yocto policy into OE which I think this might amount
to.
As a specific example, we've moved away from wanting MAINTAINER info in
the recipes in the past and this gets us back there again. I don't
really want to loop over adding data and then removing it again
repeatedly so this needs thought/discussion. Who gets their name in the
MAINTAINER field exactly? What is the process for that and what
responsibilities does that person have?
Cheers,
Richard
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
2011-10-19 19:00 ` Otavio Salvador
2011-10-19 23:33 ` Saul Wold
@ 2011-10-20 16:02 ` Eric Bénard
1 sibling, 0 replies; 38+ messages in thread
From: Eric Bénard @ 2011-10-20 16:02 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Hi,
Le 19/10/2011 21:00, Otavio Salvador a écrit :
> A plus of this choice is it will be more difficult to forget to update
> that info. This happened in last qt update for an example.
>
in fact that was in the first patch submitted but got lost in the v2 :-(
Eric
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
2011-10-20 14:25 ` Richard Purdie
2011-10-20 14:36 ` Martin Jansa
@ 2011-10-20 16:18 ` Khem Raj
1 sibling, 0 replies; 38+ messages in thread
From: Khem Raj @ 2011-10-20 16:18 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Phil Blundell
On Thu, Oct 20, 2011 at 7:25 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> a) Keep the data where it is
> b) Merge the data into the recipes
We once had maintainers and then backed out of it
this would reintroduce that and bitbake might have
to eat more memory to parse this information.
> c) Move the data out of OE-Core
For now this would be a better solution IMO
>
> Since a lot of that data is fairly Yocto process specific, it may make
> sense to move it over to meta-yocto...
>
Yes it seems to be apt.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
2011-10-20 15:55 ` Richard Purdie
@ 2011-10-20 16:24 ` Koen Kooi
2011-10-20 17:38 ` Joshua Lock
2011-10-20 21:28 ` Saul Wold
1 sibling, 1 reply; 38+ messages in thread
From: Koen Kooi @ 2011-10-20 16:24 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Op 20 okt. 2011, om 17:55 heeft Richard Purdie het volgende geschreven:
> On Thu, 2011-10-20 at 16:36 +0200, Martin Jansa wrote:
>> On Thu, Oct 20, 2011 at 03:25:52PM +0100, Richard Purdie wrote:
>>> On Wed, 2011-10-19 at 16:33 -0700, Saul Wold wrote:
>>>> On 10/19/2011 12:00 PM, Otavio Salvador wrote:
>>>>> On Wed, Oct 19, 2011 at 16:30, Khem Raj<raj.khem@gmail.com> wrote:
>>>>> ...
>>>>>>>>> Many upstreams we can't track if updates are required automagically, so
>>>>>>>>> we
>>>>>>>>> need a place to record when the last manual check was, also possible
>>>>>>>>> reasons
>>>>>>>>> why we should not update to newer versions, ...
>>>>>>
>>>>>> hmm manual check means it has to be done manually is there any thing
>>>>>> that needs it ?
>>>>>>
>>>>>> I think unless they are distro specific which seems not since they are
>>>>>> in oe-core
>>>>>> they could exist in recipes thats my opinion.
>>>>>
>>>>> I agree that this should be put into the recipes. Besides this allows
>>>>> for checking if it was updated when the version has been updated.
>>>>>
>>>>> If done right, when updating the version this data will be updated
>>>>> together. I see no change in the amount of changes.
>>>>>
>>>>> A plus of this choice is it will be more difficult to forget to update
>>>>> that info. This happened in last qt update for an example.
>>>>>
>>>>
>>>> This may need to be something that the TSC brings up, possibly we can
>>>> talk about it in Prague next week.
>>>
>>> So just to give some background here, the information in those files was
>>> added by Yocto people to give some idea of the update status of various
>>> recipes. This included when the version was last checked/updated for
>>> recipes which we can't automate that process for, when certain cleanup
>>> checks were made, what the general state of the recipe was and who on
>>> the Yocto team was specifically looking after given recipes.
>>>
>>> When it was discussed, some of it was Yocto specific, some of it wasn't
>>> and popular opinion was against it going into the recipes themselves. I
>>> was ok with that given we have the pn- overrides and can handle the
>>> problem that way just fine.
>>>
>>> OE-Core happened and we kept the data with OE-Core at least for now. We
>>> have several options:
>>>
>>> a) Keep the data where it is
>>> b) Merge the data into the recipes
>>> c) Move the data out of OE-Core
>>>
>>> Since a lot of that data is fairly Yocto process specific, it may make
>>> sense to move it over to meta-yocto...
>>
>> I don't like "global" files where many people should maintain their info
>> and it's so easy to forgot when it's somewhere else then real changes
>> (like it was with checksums.ini and sane-src*.ini).
>
> Some data does make sense to be maintained globally and I don't think we
> should automatically say its bad. It depends what the use case is and
> how its intended to be used.
>
>> So I vote for b) Merge the data into the recipes, only problem with this
>> is that if we have 2 versions of foo (foo_1.0.bb, foo_git.bb) without
>> any foo.inc, will we create foo.inc just for distro-tracking info? Maybe
>> we should and move at least DESCRIPTION and similar variables too.
>>
>> c) moving it to meta-yocto will probably make distro-tracking info even
>> more outdated as sometimes different people then who did upgrade in
>> oe-core will have to update distro-tracking info in this layer (this is
>> also the case now sometimes, but with distro-tracking info in recipe we
>> can try better to update it with upgrades).
>
> I'd actually like Saul's view on this since he generally looks after
> that data. There as been discussion about whether it is "internal" yocto
> tracking stuff or whether its more general OE focused and I don't know
> what the answer is there. I think there is a mixture of uses. I'm also
> wary of "pushing" Yocto policy into OE which I think this might amount
> to.
>
> As a specific example, we've moved away from wanting MAINTAINER info in
> the recipes in the past and this gets us back there again. I don't
> really want to loop over adding data and then removing it again
> repeatedly so this needs thought/discussion. Who gets their name in the
> MAINTAINER field exactly? What is the process for that and what
> responsibilities does that person have?
The problem wasn't with MAINTAINER being in the recipe, the problem was MAINTAINER ending up in the ipk data. The 'abiword crashes' bugs we had years ago illustrated the problem clearly. Abiword only crashed if you used code sourcery binutils, but not with stock binutils. Graeme couldn't get the message thru that he was indeed maintaining abi in OE but wasn't responsible for people using broken toolchains. The specific abiword issue was resolved when the distro in question stopped using CSL stuff (familiar or angstrom, I forget).
I'm in favour of having info in the recipe (or bbappend!) who is looking after it if it doesn't end up in the output package.
Regardless of where to put the info, I would like to propose to orphan every recipe in OE-core and ask for volunteers. There's a ton of stuff I want to look after (bluez, gstreamer, pulse, avahi, X) which already has a maintainer from its yocto/poky/whatever legacy, but I feel is not being looked after with much attention. And adding to the problem is that most yocto people aren't using OE-core, but poky.
regards,
Koen
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
2011-10-20 16:24 ` Koen Kooi
@ 2011-10-20 17:38 ` Joshua Lock
0 siblings, 0 replies; 38+ messages in thread
From: Joshua Lock @ 2011-10-20 17:38 UTC (permalink / raw)
To: openembedded-core
On 10/20/2011 09:24 AM, Koen Kooi wrote:>
> I'm in favour of having info in the recipe (or bbappend!) who is looking after it if it doesn't end up in the output package.
>
> Regardless of where to put the info, I would like to propose to orphan every recipe in OE-core and ask for volunteers. There's a ton of stuff I want to look after (bluez, gstreamer, pulse, avahi, X) which already has a maintainer from its yocto/poky/whatever legacy, but I feel is not being looked after with much attention. And adding to the problem is that most yocto people aren't using OE-core, but poky.
I feel the need to point out that you don't have to be the named
maintainer to submit a patch.
Personally I'd be happy to see maintainer ship go to other members of
the community.
I think a better approach would be to seek volunteers before we orphan
things? That way things which don't receive volunteers can stay with the
current maintainer?
Cheers,
Joshua
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
2011-10-20 15:55 ` Richard Purdie
2011-10-20 16:24 ` Koen Kooi
@ 2011-10-20 21:28 ` Saul Wold
1 sibling, 0 replies; 38+ messages in thread
From: Saul Wold @ 2011-10-20 21:28 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On 10/20/2011 08:55 AM, Richard Purdie wrote:
> On Thu, 2011-10-20 at 16:36 +0200, Martin Jansa wrote:
>> On Thu, Oct 20, 2011 at 03:25:52PM +0100, Richard Purdie wrote:
>>> On Wed, 2011-10-19 at 16:33 -0700, Saul Wold wrote:
>>>> On 10/19/2011 12:00 PM, Otavio Salvador wrote:
>>>>> On Wed, Oct 19, 2011 at 16:30, Khem Raj<raj.khem@gmail.com> wrote:
>>>>> ...
>>>>>>>>> Many upstreams we can't track if updates are required automagically, so
>>>>>>>>> we
>>>>>>>>> need a place to record when the last manual check was, also possible
>>>>>>>>> reasons
>>>>>>>>> why we should not update to newer versions, ...
>>>>>>
>>>>>> hmm manual check means it has to be done manually is there any thing
>>>>>> that needs it ?
>>>>>>
>>>>>> I think unless they are distro specific which seems not since they are
>>>>>> in oe-core
>>>>>> they could exist in recipes thats my opinion.
>>>>>
>>>>> I agree that this should be put into the recipes. Besides this allows
>>>>> for checking if it was updated when the version has been updated.
>>>>>
>>>>> If done right, when updating the version this data will be updated
>>>>> together. I see no change in the amount of changes.
>>>>>
>>>>> A plus of this choice is it will be more difficult to forget to update
>>>>> that info. This happened in last qt update for an example.
>>>>>
>>>>
>>>> This may need to be something that the TSC brings up, possibly we can
>>>> talk about it in Prague next week.
>>>
>>> So just to give some background here, the information in those files was
>>> added by Yocto people to give some idea of the update status of various
>>> recipes. This included when the version was last checked/updated for
>>> recipes which we can't automate that process for, when certain cleanup
>>> checks were made, what the general state of the recipe was and who on
>>> the Yocto team was specifically looking after given recipes.
>>>
>>> When it was discussed, some of it was Yocto specific, some of it wasn't
>>> and popular opinion was against it going into the recipes themselves. I
>>> was ok with that given we have the pn- overrides and can handle the
>>> problem that way just fine.
>>>
>>> OE-Core happened and we kept the data with OE-Core at least for now. We
>>> have several options:
>>>
>>> a) Keep the data where it is
>>> b) Merge the data into the recipes
>>> c) Move the data out of OE-Core
>>>
>>> Since a lot of that data is fairly Yocto process specific, it may make
>>> sense to move it over to meta-yocto...
>>
>> I don't like "global" files where many people should maintain their info
>> and it's so easy to forgot when it's somewhere else then real changes
>> (like it was with checksums.ini and sane-src*.ini).
>
> Some data does make sense to be maintained globally and I don't think we
> should automatically say its bad. It depends what the use case is and
> how its intended to be used.
>
>> So I vote for b) Merge the data into the recipes, only problem with this
>> is that if we have 2 versions of foo (foo_1.0.bb, foo_git.bb) without
>> any foo.inc, will we create foo.inc just for distro-tracking info? Maybe
>> we should and move at least DESCRIPTION and similar variables too.
>>
>> c) moving it to meta-yocto will probably make distro-tracking info even
>> more outdated as sometimes different people then who did upgrade in
>> oe-core will have to update distro-tracking info in this layer (this is
>> also the case now sometimes, but with distro-tracking info in recipe we
>> can try better to update it with upgrades).
>
> I'd actually like Saul's view on this since he generally looks after
> that data. There as been discussion about whether it is "internal" yocto
> tracking stuff or whether its more general OE focused and I don't know
> what the answer is there. I think there is a mixture of uses. I'm also
> wary of "pushing" Yocto policy into OE which I think this might amount
> to.
>
> As a specific example, we've moved away from wanting MAINTAINER info in
> the recipes in the past and this gets us back there again. I don't
> really want to loop over adding data and then removing it again
> repeatedly so this needs thought/discussion. Who gets their name in the
> MAINTAINER field exactly? What is the process for that and what
> responsibilities does that person have?
>
I am working on a proposal that will be a mix of the above, move some of
the Version tracking and Updating information into the recipes and keep
the large distro tracking file, but move it to meta-yocto.
It's clear based on these emails (and the following ones), that there
has been some history with maintainer-ship of the recipes, so we need to
generate some policy and process around this. As Josh already noted,
this is a community project there for a having updates and input from
the community is important.
Part of our original purpose of putting people's names in the
distro_tracking_fields was to have those people do the updates, interact
with the upstream community and work to address any issues with the
recipes they where marked for. This was all a starting point.
I plan to have a proposal by next week that will address the current
distro_tracking_fields.inc file, I do not think I am going to tackle the
maintainer-ship issue at this point, that will be the next steps.
I, of course, welcome people's constructive feedback
Thanks
Sau!
> Cheers,
>
> Richard
>
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply [flat|nested] 38+ messages in thread
end of thread, other threads:[~2011-10-20 21:34 UTC | newest]
Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-10-19 8:28 [CONSOLIDATED PULL 00/16] Various Updates Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 01/16] poky: fix broken ubifs link in deploy folder Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 02/16] bluez4: Add glib-2.0 to DEPENDS Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 03/16] gcc-4.6: Upgrade SRCREV to latest FSF 4.6 branch Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 04/16] gcc-4.6: Backport PR46934 fix Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 05/16] ghostscript: Disable parallel make due to install issues Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 06/16] src_distribute.bbclass, src_distribute_local.bbclass: mostly rewritten Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 07/16] ghostscript: renamed x86_64 to x86-64 for patch to work Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 08/16] insane.bbclass: print full path on invalid LICENSE_FILES_CHKSUM Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 09/16] x86 tune files: set baselib for x32 tune as libx32 Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 10/16] gmp: also generate the libgmpcxx library Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 11/16] python-scons: upgrade from 2.0.1 to 2.1.0 Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 12/16] python-dbus: upgrade from 0.83.2 to 0.84.0 Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 13/16] libxml-parser-perl: upgrade from 2.40 to 2.41 Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes Saul Wold
2011-10-19 8:30 ` Koen Kooi
2011-10-19 15:49 ` Kamble, Nitin A
2011-10-19 15:52 ` Koen Kooi
2011-10-19 16:24 ` Kamble, Nitin A
2011-10-19 16:37 ` Koen Kooi
2011-10-19 16:49 ` Phil Blundell
2011-10-19 16:57 ` Saul Wold
2011-10-19 17:00 ` Khem Raj
2011-10-19 17:45 ` Saul Wold
2011-10-19 18:30 ` Khem Raj
2011-10-19 19:00 ` Otavio Salvador
2011-10-19 23:33 ` Saul Wold
2011-10-20 14:25 ` Richard Purdie
2011-10-20 14:36 ` Martin Jansa
2011-10-20 14:48 ` Koen Kooi
2011-10-20 15:55 ` Richard Purdie
2011-10-20 16:24 ` Koen Kooi
2011-10-20 17:38 ` Joshua Lock
2011-10-20 21:28 ` Saul Wold
2011-10-20 16:18 ` Khem Raj
2011-10-20 16:02 ` Eric Bénard
2011-10-19 8:28 ` [CONSOLIDATED PULL 15/16] gst-plugins-good: update to 0.10.30 Saul Wold
2011-10-19 8:28 ` [CONSOLIDATED PULL 16/16] tzdata: updated SRC_URI and update to 2011k Saul Wold
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.