Various Updates

GIT PULL Saul Wold 11 participants 38 messages Oct 19, 2011 – Oct 20, 2011

Share & tools

Saul Wold

author

2011-10-19 08:34 UTC #0 lore raw

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%)

Signature · 1 line

1.7.6.2

Saul Wold

author

2011-10-19 08:34 UTC #1 lore raw

[CONSOLIDATED PULL 01/16] poky: fix broken ubifs link in deploy folder

From: Lauri Hintsala <[email protected]>

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 <[email protected]>

---
 meta/classes/image_types.bbclass |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

meta/classes/image_types.bbclass +1 -1

index 2260915..0d64705 100644
@@ -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"

Signature · 1 line

1.7.6.2

Saul Wold

author

2011-10-19 08:34 UTC #2 lore raw

[CONSOLIDATED PULL 02/16] bluez4: Add glib-2.0 to DEPENDS

In reply to Saul Wold

From: Khem Raj <[email protected]>

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 <[email protected]>

---
 meta/recipes-connectivity/bluez/bluez4.inc     |    2 +-
 meta/recipes-connectivity/bluez/bluez4_4.96.bb |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

meta/recipes-connectivity/bluez/bluez4.inc +1 -1

index fc515f6..9158687 100644
@@ -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 = ""

meta/recipes-connectivity/bluez/bluez4_4.96.bb +1 -1

index 52268cf..88ec7a4 100644
@@ -1,6 +1,6 @@
 require bluez4.inc
 
-PR = "r3"
+PR = "r4"
 
 SRC_URI += "file://bluetooth.conf"

Signature · 1 line

1.7.6.2

Saul Wold

author

2011-10-19 08:34 UTC #3 lore raw

[CONSOLIDATED PULL 03/16] gcc-4.6: Upgrade SRCREV to latest FSF 4.6 branch

In reply to Saul Wold

From: Khem Raj <[email protected]>

Signed-off-by Khem Raj <[email protected]>

---
 meta/recipes-devtools/gcc/gcc-4.6.inc |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

meta/recipes-devtools/gcc/gcc-4.6.inc +1 -1

index 8ca3174..0fb6287 100644
@@ -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)}"

Signature · 1 line

1.7.6.2

Saul Wold

author

2011-10-19 08:34 UTC #4 lore raw

[CONSOLIDATED PULL 04/16] gcc-4.6: Backport PR46934 fix

In reply to Saul Wold

From: Khem Raj <[email protected]>

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 <[email protected]>

---
 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

meta/recipes-devtools/gcc/gcc-4.6.inc +2 -1

index 0fb6287..fbc90ea 100644
@@ -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 "

meta/recipes-devtools/gcc/gcc-4.6/pr46934.patch new file +392 -0

392 lines not on this page · raw message

Signature · 1 line

1.7.6.2

Saul Wold

author

2011-10-19 08:34 UTC #5 lore raw

[CONSOLIDATED PULL 06/16] src_distribute.bbclass, src_distribute_local.bbclass: mostly rewritten

In reply to Saul Wold

From: Otavio Salvador <[email protected]>

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 <[email protected]>

---
 meta/classes/src_distribute.bbclass       |   54 ++++++++++++++++++++---------
 meta/classes/src_distribute_local.bbclass |   28 ++++++++-------
 2 files changed, 52 insertions(+), 30 deletions(-)

meta/classes/src_distribute.bbclass +37 ~~-17~~

index 17d6c09..fbfbdf0 100644
@@ -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

meta/classes/src_distribute_local.bbclass +15 ~~-13~~

index 5f0cef5..17b67e3 100644
@@ -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
 }

Signature · 1 line

1.7.6.2

Saul Wold

author

2011-10-19 08:34 UTC #6 lore raw

[CONSOLIDATED PULL 07/16] ghostscript: renamed x86_64 to x86-64 for patch to work

In reply to Saul Wold

Signed-off-by Saul Wold <[email protected]>

---
 .../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%)

meta/recipes-extended/ghostscript/ghostscript/x86-64/objarch.h renamed from meta/recipes-extended/ghostscript/ghostscript/x86_64/objarch.h +0 -0

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

meta/recipes-extended/ghostscript/ghostscript/x86-64/soobjarch.h renamed from meta/recipes-extended/ghostscript/ghostscript/x86_64/soobjarch.h +0 -0

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

Signature · 1 line

1.7.6.2

Saul Wold

author

2011-10-19 08:34 UTC #7 lore raw

[CONSOLIDATED PULL 05/16] ghostscript: Disable parallel make due to install issues

In reply to Saul Wold

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 <[email protected]>

---
 .../ghostscript/ghostscript_9.02.bb                |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

meta/recipes-extended/ghostscript/ghostscript_9.02.bb +4 -0

index 9b21c66..1d48cce 100644
@@ -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=""

Signature · 1 line

1.7.6.2

Saul Wold

author

2011-10-19 08:34 UTC #8 lore raw

[CONSOLIDATED PULL 10/16] gmp: also generate the libgmpcxx library

In reply to Saul Wold

From: Nitin A Kamble <[email protected]>

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 <[email protected]>

---
 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(-)

meta/recipes-support/gmp/gmp.inc +2 -0

index 66349e6..3c662a0 100644
@@ -14,3 +14,5 @@ ARM_INSTRUCTION_SET = "arm"
 acpaths = ""
 
 BBCLASSEXTEND = "native nativesdk"
+
+EXTRA_OECONF += " --enable-cxx=detect"

meta/recipes-support/gmp/gmp_4.2.1.bb +1 -1

index 74da6b8..97ac4b2 100644
@@ -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"

meta/recipes-support/gmp/gmp_5.0.2.bb +1 -1

index 03fef45..f80971e 100644
@@ -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 "

Signature · 1 line

1.7.6.2

Saul Wold

author

2011-10-19 08:34 UTC #9 lore raw

[CONSOLIDATED PULL 08/16] insane.bbclass: print full path on invalid LICENSE_FILES_CHKSUM

In reply to Saul Wold

From: Darren Hart <[email protected]>

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 <[email protected]>

---
 meta/classes/insane.bbclass |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

meta/classes/insane.bbclass +1 -1

index b861e85..017f7be 100644
@@ -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)

Signature · 1 line

1.7.6.2

Saul Wold

author

2011-10-19 08:34 UTC #10 lore raw

[CONSOLIDATED PULL 11/16] python-scons: upgrade from 2.0.1 to 2.1.0

In reply to Saul Wold

From: Nitin A Kamble <[email protected]>

the LICENSE.txt has added 2011 year to the copyright line he nce the MD5 sum is different.

Signed-off-by Nitin A Kamble <[email protected]>

---
 ...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%)

meta/recipes-devtools/python/python-scons-native_2.1.0.bb renamed from meta/recipes-devtools/python/python-scons-native_2.0.1.bb +1 -2

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
@@ -2,5 +2,4 @@ require python-scons_${PV}.bb
 inherit native
 DEPENDS = "python-native"
 RDEPENDS_${PN} = ""
-PR = "r1"
-
+PR = "r0"

meta/recipes-devtools/python/python-scons_2.1.0.bb renamed from meta/recipes-devtools/python/python-scons_2.0.1.bb +3 -3

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
@@ -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

Signature · 1 line

1.7.6.2

Saul Wold

author

2011-10-19 08:34 UTC #11 lore raw

[CONSOLIDATED PULL 09/16] x86 tune files: set baselib for x32 tune as libx32

In reply to Saul Wold

From: Nitin A Kamble <[email protected]>

Signed-off-by Nitin A Kamble <[email protected]>

---
 meta/conf/machine/include/ia32/arch-ia32.inc |    2 +-
 meta/conf/machine/include/tune-core2.inc     |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

meta/conf/machine/include/ia32/arch-ia32.inc +1 -1

index a52e33a..ee91983 100644
@@ -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)}"

meta/conf/machine/include/tune-core2.inc +1 -1

index 78f8f4d..565a39c 100644
@@ -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"

Signature · 1 line

1.7.6.2

Saul Wold

author

2011-10-19 08:34 UTC #12 lore raw

[CONSOLIDATED PULL 12/16] python-dbus: upgrade from 0.83.2 to 0.84.0

In reply to Saul Wold

From: Nitin A Kamble <[email protected]>

Signed-off-by Nitin A Kamble <[email protected]>

---
 ...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%)

meta/recipes-devtools/python/python-dbus_0.84.0.bb renamed from meta/recipes-devtools/python/python-dbus_0.83.2.bb +2 -2

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
@@ -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

Signature · 1 line

1.7.6.2

Saul Wold

author

2011-10-19 08:34 UTC #13 lore raw

[CONSOLIDATED PULL 15/16] gst-plugins-good: update to 0.10.30

In reply to Saul Wold

From: Joshua Lock <[email protected]>

Signed-off-by Joshua Lock <[email protected]>

---
 ...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%)

meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.30.bb renamed from meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.28.bb +2 -2

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
@@ -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"

Signature · 1 line

1.7.6.2

Saul Wold

author

2011-10-19 08:34 UTC #14 lore raw

[CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes

In reply to Saul Wold

From: Nitin A Kamble <[email protected]>

Signed-off-by Nitin A Kamble <[email protected]>

---
 .../conf/distro/include/distro_tracking_fields.inc |   42 ++++++++++++--------
 1 files changed, 25 insertions(+), 17 deletions(-)

meta/conf/distro/include/distro_tracking_fields.inc +25 ~~-17~~

index abc2cbf..e68bbe1 100644
@@ -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 <[email protected]>"
 
-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 <[email protected]>"
 
+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 <[email protected]>"
+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 <[email protected]>"
 
-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 <[email protected]>"
 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 <[email protected]>"
 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 <[email protected]>"

@@ -3087,15 +3096,16 @@ RECIPE_LATEST_VERSION_pn-unifdef="2.6.18+git"
 RECIPE_MAINTAINER_pn-unifdef = "Nitin A Kamble <[email protected]>"
 
 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 <[email protected]>"
 
 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 <[email protected]>"
 
 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 <[email protected]>"
 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 <[email protected]>"
 
 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 <[email protected]>"
 
 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 <[email protected]>"
 
 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 <[email protected]>"
-
 DISTRO_PN_ALIAS_pn-rt-tests = "Debian=rt-tests Ubuntu=rt-tests"
 RECIPE_MAINTAINER_pn-rt-tests = "Darren Hart <[email protected]>"

Signature · 1 line

1.7.6.2

Saul Wold

author

2011-10-19 08:34 UTC #36 lore raw

[CONSOLIDATED PULL 13/16] libxml-parser-perl: upgrade from 2.40 to 2.41

In reply to Saul Wold

From: Nitin A Kamble <[email protected]>

Signed-off-by Nitin A Kamble <[email protected]>

---
 ...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%)

meta/recipes-devtools/perl/libxml-parser-perl_2.41.bb renamed from meta/recipes-devtools/perl/libxml-parser-perl_2.40.bb +3 -3

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
@@ -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}"

Signature · 1 line

1.7.6.2

Saul Wold

author

2011-10-19 08:34 UTC #37 lore raw

[CONSOLIDATED PULL 16/16] tzdata: updated SRC_URI and update to 2011k

In reply to Saul Wold

From: Joshua Lock <[email protected]>

tzdata is now hosted by IANA at http://www.iana.org/time-zones

Signed-off-by Joshua Lock <[email protected]>

---
 .../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%)

meta/recipes-extended/tzdata/tzdata_2011l.bb renamed from meta/recipes-extended/tzdata/tzdata_2011k.bb +3 -3

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
@@ -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}"

Signature · 1 line

1.7.6.2

Koen Kooi

2011-10-19 08:36 UTC #15 lore raw

Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes

In reply to Saul Wold

btrfs-tools is a toolchain recipe?!?!?!

Op 19 okt. 2011, om 10:28 heeft Saul Wold het volgende geschreven:

Quoted 119 lines

From: Nitin A Kamble <[email protected]>
Signed-off-by Nitin A Kamble <[email protected]>
---
.../conf/distro/include/distro_tracking_fields.inc | 42 ++++++++++++--------
1 files changed, 25 insertions(+), 17 deletions(-)
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
index abc2cbf..e68bbe1 100644
@@ -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 <[email protected]>"
meta/conf/distro/include/distro_tracking_fields.inc +1 -1
-RECIPE_STATUS_pn-nasm="green" 
+RECIPE_STATUS_pn-nasm="green"
RECIPE_LATEST_VERSION_pn-nasm="2.07"
meta/conf/distro/include/distro_tracking_fields.inc +2 -1
-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 <[email protected]>"
meta/conf/distro/include/distro_tracking_fields.inc +7 -0
+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 <[email protected]>"
+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"
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -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 <[email protected]>"
meta/conf/distro/include/distro_tracking_fields.inc +3 -3
-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 <[email protected]>" DISTRO_PN_ALIAS_pn-python-dbus = "Ubuntu=python-dbus Debian=python-dbus Mandriva=python-dbus"
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -3062,7 +3070,8 @@ RECIPE_MAINTAINER_pn-python-pyrex = "Nitin A Kamble <[email protected]>"
DISTRO_PN_ALIAS_pn-python-pyrex = "Mandriva=python-pyrex Ubuntu=python-pyrex"
RECIPE_STATUS_pn-python-scons="green"
meta/conf/distro/include/distro_tracking_fields.inc +2 -1
-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 <[email protected]>"
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -3087,15 +3096,16 @@ RECIPE_LATEST_VERSION_pn-unifdef="2.6.18+git"
RECIPE_MAINTAINER_pn-unifdef = "Nitin A Kamble <[email protected]>"
RECIPE_STATUS_pn-gnu-config="green"
meta/conf/distro/include/distro_tracking_fields.inc +1 -1
-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"
meta/conf/distro/include/distro_tracking_fields.inc +1 -1
-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 <[email protected]>"
RECIPE_STATUS_pn-mpfr="green"
meta/conf/distro/include/distro_tracking_fields.inc +3 -2
-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 <[email protected]>"
RECIPE_STATUS_pn-gmp="green"
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -3110,9 +3120,10 @@ RECIPE_MANUAL_CHECK_DATE_pn-libmpc = "Jan 25, 2011"
RECIPE_MAINTAINER_pn-libmpc = "Nitin A Kamble <[email protected]>" DISTRO_PN_ALIAS_pn-libmpc = "Fedora=libmpc OpenSuse=libmpc2"
meta/conf/distro/include/distro_tracking_fields.inc +1 -1
-RECIPE_STATUS_pn-byacc="red" 
+RECIPE_STATUS_pn-byacc="green" 
RECIPE_LATEST_VERSION_pn-byacc="20101229"
meta/conf/distro/include/distro_tracking_fields.inc +2 -1
-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 <[email protected]>"
RECIPE_STATUS_pn-libconvert-asn1-perl="green"
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -3122,8 +3133,8 @@ RECIPE_LAST_UPDATE_pn-libconvert-asn1-perl = "Aug 13, 2010"
RECIPE_MAINTAINER_pn-libconvert-asn1-perl = "Nitin A Kamble <[email protected]>"
RECIPE_STATUS_pn-libxml-parser-perl="green"
meta/conf/distro/include/distro_tracking_fields.inc +2 -2
-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 <[email protected]>"
RECIPE_STATUS_pn-cmake-native="green"
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -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"
meta/conf/distro/include/distro_tracking_fields.inc +0 -3
-DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-progs"
-RECIPE_MAINTAINER_pn-btrfs-tools = "Nitin A Kamble <[email protected]>"
-
DISTRO_PN_ALIAS_pn-rt-tests = "Debian=rt-tests Ubuntu=rt-tests" RECIPE_MAINTAINER_pn-rt-tests = "Darren Hart <[email protected]>"
Signature · 7 lines
1.7.6.2


_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Kamble, Nitin A

2011-10-19 15:55 UTC #16 lore raw

Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes

Koen,
Why do you ask ?

Nitin

Quoted 168 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] 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:
Quoted 5 lines
From: Nitin A Kamble <[email protected]>
Signed-off-by Nitin A Kamble <[email protected]>
---
.../conf/distro/include/distro_tracking_fields.inc | 42
++++++++++++--------
Review
Quoted 3 lines
1 files changed, 25 insertions(+), 17 deletions(-)
(quoted diff) +0 -0
b/meta/conf/distro/include/distro_tracking_fields.inc
meta/conf/distro/include/distro_tracking_fields.inc RECIPE_STATUS_pn-run-postinsts="green" # all
Quoted 4 lines
index abc2cbf..e68bbe1 100644
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -3005,11 +3005,19 @@ RECIPE_STATUS_pn-run-postinsts="green" # all
local code
Quoted 2 lines
RECIPE_LATEST_VERSION_pn-postinsts="1.0"
RECIPE_MAINTAINER_pn-postinsts = "Nitin A Kamble
<[email protected]>"
Quoted 8 lines
meta/conf/distro/include/distro_tracking_fields.inc +1 -1
-RECIPE_STATUS_pn-nasm="green"
+RECIPE_STATUS_pn-nasm="green"
RECIPE_LATEST_VERSION_pn-nasm="2.07"
meta/conf/distro/include/distro_tracking_fields.inc +2 -1
-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
<[email protected]>"
meta/conf/distro/include/distro_tracking_fields.inc RECIPE_STATUS_pn-run-postinsts="green" # all local code
Quoted 6 lines
meta/conf/distro/include/distro_tracking_fields.inc +5 -0
+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
<[email protected]>"
Quoted 1 line
+DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-
progs"
meta/conf/distro/include/distro_tracking_fields.inc RECIPE_LATEST_VERSION_pn-
Quoted 5 lines
+
RECIPE_STATUS_pn-perl="red" # upgrade needed
RECIPE_LATEST_VERSION_pn-perl="5.12.1"
RECIPE_LAST_UPDATE_pn-perl = "May 27, 2007"
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -3020,9 +3028,9 @@ RECIPE_LATEST_VERSION_pn-
prelink="1.0+git0+0x909470ee441237563d6236c505cb2d02ddc
Quoted 2 lines
RECIPE_LAST_UPDATE_pn-perl = "Jul 23, 2010"
RECIPE_MAINTAINER_pn-prelink = "Mark Hatle
<[email protected]>"
Quoted 8 lines
meta/conf/distro/include/distro_tracking_fields.inc +3 -3
-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
<[email protected]>"
Quoted 1 line
DISTRO_PN_ALIAS_pn-python-dbus = "Ubuntu=python-dbus Debian=python-
dbus Mandriva=python-dbus"
meta/conf/distro/include/distro_tracking_fields.inc RECIPE_MAINTAINER_pn-python-pyrex = "Nitin A
Quoted 2 lines
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -3062,7 +3070,8 @@ RECIPE_MAINTAINER_pn-python-pyrex = "Nitin A
Kamble <[email protected]>"
Quoted 1 line
DISTRO_PN_ALIAS_pn-python-pyrex = "Mandriva=python-pyrex
Ubuntu=python-pyrex"
Quoted 6 lines
RECIPE_STATUS_pn-python-scons="green"
meta/conf/distro/include/distro_tracking_fields.inc +2 -1
-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"
Quoted 2 lines
RECIPE_LAST_UPDATE_pn-python-scons = "Nov 8, 2010" RECIPE_MAINTAINER_pn-python-scons = "Nitin A Kamble
<[email protected]>"
Quoted 2 lines
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -3087,15 +3096,16 @@ RECIPE_LATEST_VERSION_pn-unifdef="2.6.18+git"
RECIPE_MAINTAINER_pn-unifdef = "Nitin A Kamble
<[email protected]>"
Quoted 9 lines
RECIPE_STATUS_pn-gnu-config="green"
meta/conf/distro/include/distro_tracking_fields.inc +1 -1
-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"
meta/conf/distro/include/distro_tracking_fields.inc +1 -1
-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
<[email protected]>"
Quoted 8 lines
RECIPE_STATUS_pn-mpfr="green"
meta/conf/distro/include/distro_tracking_fields.inc +3 -2
-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
<[email protected]>"
meta/conf/distro/include/distro_tracking_fields.inc RECIPE_MANUAL_CHECK_DATE_pn-libmpc = "Jan 25,
Quoted 3 lines
RECIPE_STATUS_pn-gmp="green"
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -3110,9 +3120,10 @@ RECIPE_MANUAL_CHECK_DATE_pn-libmpc = "Jan 25,
2011"
Quoted 1 line
RECIPE_MAINTAINER_pn-libmpc = "Nitin A Kamble
<[email protected]>"
Quoted 9 lines
DISTRO_PN_ALIAS_pn-libmpc = "Fedora=libmpc OpenSuse=libmpc2"
meta/conf/distro/include/distro_tracking_fields.inc +1 -1
-RECIPE_STATUS_pn-byacc="red"
+RECIPE_STATUS_pn-byacc="green"
RECIPE_LATEST_VERSION_pn-byacc="20101229"
meta/conf/distro/include/distro_tracking_fields.inc +2 -1
-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
<[email protected]>"
meta/conf/distro/include/distro_tracking_fields.inc RECIPE_LAST_UPDATE_pn-libconvert-asn1-perl =
Quoted 3 lines
RECIPE_STATUS_pn-libconvert-asn1-perl="green"
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -3122,8 +3133,8 @@ RECIPE_LAST_UPDATE_pn-libconvert-asn1-perl =
"Aug 13, 2010"
Quoted 1 line
RECIPE_MAINTAINER_pn-libconvert-asn1-perl = "Nitin A Kamble
<[email protected]>"
Quoted 7 lines
RECIPE_STATUS_pn-libxml-parser-perl="green"
meta/conf/distro/include/distro_tracking_fields.inc +2 -2
-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
<[email protected]>"
meta/conf/distro/include/distro_tracking_fields.inc RECIPE_COMMENTS_pn-pseudo = "Yocto Project
Quoted 3 lines
RECIPE_STATUS_pn-cmake-native="green"
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -5922,9 +5933,6 @@ RECIPE_COMMENTS_pn-pseudo = "Yocto Project
maintained"
Quoted 4 lines
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"
Quoted 1 line
-RECIPE_MAINTAINER_pn-btrfs-tools = "Nitin A Kamble
<[email protected]>"
Quoted 3 lines
-
DISTRO_PN_ALIAS_pn-rt-tests = "Debian=rt-tests Ubuntu=rt-tests" RECIPE_MAINTAINER_pn-rt-tests = "Darren Hart
<[email protected]>"
Quoted 9 lines
--
1.7.6.2
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Koen Kooi

2011-10-19 15:58 UTC #17 lore raw

Re: [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:

Quoted 2 lines

Koen,
Why do you ask ?

Because I want the commit message to match to commit and now it doesn't.

Quoted 176 lines

Nitin
Quoted 164 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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:
Quoted 5 lines
From: Nitin A Kamble <[email protected]>
Signed-off-by Nitin A Kamble <[email protected]>
---
.../conf/distro/include/distro_tracking_fields.inc | 42
++++++++++++--------
Review
Quoted 3 lines
1 files changed, 25 insertions(+), 17 deletions(-)
(quoted diff) +0 -0
b/meta/conf/distro/include/distro_tracking_fields.inc
meta/conf/distro/include/distro_tracking_fields.inc RECIPE_STATUS_pn-run-postinsts="green" # all
Quoted 4 lines
index abc2cbf..e68bbe1 100644
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -3005,11 +3005,19 @@ RECIPE_STATUS_pn-run-postinsts="green" # all
local code
Quoted 2 lines
RECIPE_LATEST_VERSION_pn-postinsts="1.0"
RECIPE_MAINTAINER_pn-postinsts = "Nitin A Kamble
<[email protected]>"
Quoted 8 lines
meta/conf/distro/include/distro_tracking_fields.inc +1 -1
-RECIPE_STATUS_pn-nasm="green"
+RECIPE_STATUS_pn-nasm="green"
RECIPE_LATEST_VERSION_pn-nasm="2.07"
meta/conf/distro/include/distro_tracking_fields.inc +2 -1
-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
<[email protected]>"
meta/conf/distro/include/distro_tracking_fields.inc RECIPE_STATUS_pn-run-postinsts="green" # all local code
Quoted 6 lines
meta/conf/distro/include/distro_tracking_fields.inc +5 -0
+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
<[email protected]>"
Quoted 1 line
+DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-
progs"
meta/conf/distro/include/distro_tracking_fields.inc RECIPE_LATEST_VERSION_pn-
Quoted 5 lines
+
RECIPE_STATUS_pn-perl="red" # upgrade needed
RECIPE_LATEST_VERSION_pn-perl="5.12.1"
RECIPE_LAST_UPDATE_pn-perl = "May 27, 2007"
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -3020,9 +3028,9 @@ RECIPE_LATEST_VERSION_pn-
prelink="1.0+git0+0x909470ee441237563d6236c505cb2d02ddc
Quoted 2 lines
RECIPE_LAST_UPDATE_pn-perl = "Jul 23, 2010"
RECIPE_MAINTAINER_pn-prelink = "Mark Hatle
<[email protected]>"
Quoted 8 lines
meta/conf/distro/include/distro_tracking_fields.inc +3 -3
-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
<[email protected]>"
Quoted 1 line
DISTRO_PN_ALIAS_pn-python-dbus = "Ubuntu=python-dbus Debian=python-
dbus Mandriva=python-dbus"
meta/conf/distro/include/distro_tracking_fields.inc RECIPE_MAINTAINER_pn-python-pyrex = "Nitin A
Quoted 2 lines
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -3062,7 +3070,8 @@ RECIPE_MAINTAINER_pn-python-pyrex = "Nitin A
Kamble <[email protected]>"
Quoted 1 line
DISTRO_PN_ALIAS_pn-python-pyrex = "Mandriva=python-pyrex
Ubuntu=python-pyrex"
Quoted 6 lines
RECIPE_STATUS_pn-python-scons="green"
meta/conf/distro/include/distro_tracking_fields.inc +2 -1
-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"
Quoted 2 lines
RECIPE_LAST_UPDATE_pn-python-scons = "Nov 8, 2010" RECIPE_MAINTAINER_pn-python-scons = "Nitin A Kamble
<[email protected]>"
Quoted 2 lines
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -3087,15 +3096,16 @@ RECIPE_LATEST_VERSION_pn-unifdef="2.6.18+git"
RECIPE_MAINTAINER_pn-unifdef = "Nitin A Kamble
<[email protected]>"
Quoted 9 lines
RECIPE_STATUS_pn-gnu-config="green"
meta/conf/distro/include/distro_tracking_fields.inc +1 -1
-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"
meta/conf/distro/include/distro_tracking_fields.inc +1 -1
-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
<[email protected]>"
Quoted 8 lines
RECIPE_STATUS_pn-mpfr="green"
meta/conf/distro/include/distro_tracking_fields.inc +3 -2
-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
<[email protected]>"
meta/conf/distro/include/distro_tracking_fields.inc RECIPE_MANUAL_CHECK_DATE_pn-libmpc = "Jan 25,
Quoted 3 lines
RECIPE_STATUS_pn-gmp="green"
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -3110,9 +3120,10 @@ RECIPE_MANUAL_CHECK_DATE_pn-libmpc = "Jan 25,
2011"
Quoted 1 line
RECIPE_MAINTAINER_pn-libmpc = "Nitin A Kamble
<[email protected]>"
Quoted 9 lines
DISTRO_PN_ALIAS_pn-libmpc = "Fedora=libmpc OpenSuse=libmpc2"
meta/conf/distro/include/distro_tracking_fields.inc +1 -1
-RECIPE_STATUS_pn-byacc="red"
+RECIPE_STATUS_pn-byacc="green"
RECIPE_LATEST_VERSION_pn-byacc="20101229"
meta/conf/distro/include/distro_tracking_fields.inc +2 -1
-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
<[email protected]>"
meta/conf/distro/include/distro_tracking_fields.inc RECIPE_LAST_UPDATE_pn-libconvert-asn1-perl =
Quoted 3 lines
RECIPE_STATUS_pn-libconvert-asn1-perl="green"
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -3122,8 +3133,8 @@ RECIPE_LAST_UPDATE_pn-libconvert-asn1-perl =
"Aug 13, 2010"
Quoted 1 line
RECIPE_MAINTAINER_pn-libconvert-asn1-perl = "Nitin A Kamble
<[email protected]>"
Quoted 7 lines
RECIPE_STATUS_pn-libxml-parser-perl="green"
meta/conf/distro/include/distro_tracking_fields.inc +2 -2
-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
<[email protected]>"
meta/conf/distro/include/distro_tracking_fields.inc RECIPE_COMMENTS_pn-pseudo = "Yocto Project
Quoted 3 lines
RECIPE_STATUS_pn-cmake-native="green"
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -5922,9 +5933,6 @@ RECIPE_COMMENTS_pn-pseudo = "Yocto Project
maintained"
Quoted 4 lines
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"
Quoted 1 line
-RECIPE_MAINTAINER_pn-btrfs-tools = "Nitin A Kamble
<[email protected]>"
Quoted 3 lines
-
DISTRO_PN_ALIAS_pn-rt-tests = "Debian=rt-tests Ubuntu=rt-tests" RECIPE_MAINTAINER_pn-rt-tests = "Darren Hart
<[email protected]>"
Quoted 9 lines
--
1.7.6.2
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 4 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Kamble, Nitin A

2011-10-19 16:30 UTC #18 lore raw

Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes

Quoted 12 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] 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

Quoted 9 lines

Op 19 okt. 2011, om 17:49 heeft Kamble, Nitin A het volgende geschreven:
Quoted 2 lines
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

Quoted 188 lines

Quoted 6 lines
Nitin
Quoted 3 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of
Quoted 18 lines
Quoted 18 lines
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:
Quoted 5 lines
From: Nitin A Kamble <[email protected]>
Signed-off-by Nitin A Kamble <[email protected]>
---
.../conf/distro/include/distro_tracking_fields.inc | 42
++++++++++++--------
Quoted 8 lines
Quoted 8 lines
Review
Quoted 3 lines
1 files changed, 25 insertions(+), 17 deletions(-)
(quoted diff) +0 -0
b/meta/conf/distro/include/distro_tracking_fields.inc
meta/conf/distro/include/distro_tracking_fields.inc RECIPE_STATUS_pn-run-postinsts="green" #
Quoted 4 lines
index abc2cbf..e68bbe1 100644
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -3005,11 +3005,19 @@ RECIPE_STATUS_pn-run-postinsts="green" #
all
Quoted 54 lines
Quoted 54 lines
local code
Quoted 2 lines
RECIPE_LATEST_VERSION_pn-postinsts="1.0"
RECIPE_MAINTAINER_pn-postinsts = "Nitin A Kamble
<[email protected]>"
Quoted 8 lines
meta/conf/distro/include/distro_tracking_fields.inc +1 -1
-RECIPE_STATUS_pn-nasm="green"
+RECIPE_STATUS_pn-nasm="green"
RECIPE_LATEST_VERSION_pn-nasm="2.07"
meta/conf/distro/include/distro_tracking_fields.inc +2 -1
-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
<[email protected]>"
meta/conf/distro/include/distro_tracking_fields.inc RECIPE_STATUS_pn-run-postinsts="green" # all local code
Quoted 6 lines
meta/conf/distro/include/distro_tracking_fields.inc +5 -0
+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
<[email protected]>"
Quoted 1 line
+DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-
progs"
meta/conf/distro/include/distro_tracking_fields.inc RECIPE_LATEST_VERSION_pn-
Quoted 5 lines
+
RECIPE_STATUS_pn-perl="red" # upgrade needed
RECIPE_LATEST_VERSION_pn-perl="5.12.1"
RECIPE_LAST_UPDATE_pn-perl = "May 27, 2007"
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -3020,9 +3028,9 @@ RECIPE_LATEST_VERSION_pn-
prelink="1.0+git0+0x909470ee441237563d6236c505cb2d02ddc
Quoted 2 lines
RECIPE_LAST_UPDATE_pn-perl = "Jul 23, 2010"
RECIPE_MAINTAINER_pn-prelink = "Mark Hatle
<[email protected]>"
Quoted 8 lines
meta/conf/distro/include/distro_tracking_fields.inc +3 -3
-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
<[email protected]>"
Quoted 1 line
DISTRO_PN_ALIAS_pn-python-dbus = "Ubuntu=python-dbus Debian=python-
dbus Mandriva=python-dbus"
meta/conf/distro/include/distro_tracking_fields.inc RECIPE_MAINTAINER_pn-python-pyrex = "Nitin A
Quoted 2 lines
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -3062,7 +3070,8 @@ RECIPE_MAINTAINER_pn-python-pyrex = "Nitin A
Kamble <[email protected]>"
Quoted 1 line
DISTRO_PN_ALIAS_pn-python-pyrex = "Mandriva=python-pyrex
Ubuntu=python-pyrex"
Quoted 6 lines
RECIPE_STATUS_pn-python-scons="green"
meta/conf/distro/include/distro_tracking_fields.inc +2 -1
-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"
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
RECIPE_LAST_UPDATE_pn-python-scons = "Nov 8, 2010" RECIPE_MAINTAINER_pn-python-scons = "Nitin A Kamble
<[email protected]>"
meta/conf/distro/include/distro_tracking_fields.inc RECIPE_LATEST_VERSION_pn-
Quoted 1 line
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -3087,15 +3096,16 @@ RECIPE_LATEST_VERSION_pn-
unifdef="2.6.18+git"
Quoted 22 lines
Quoted 22 lines
Quoted 1 line
RECIPE_MAINTAINER_pn-unifdef = "Nitin A Kamble
<[email protected]>"
Quoted 9 lines
RECIPE_STATUS_pn-gnu-config="green"
meta/conf/distro/include/distro_tracking_fields.inc +1 -1
-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"
meta/conf/distro/include/distro_tracking_fields.inc +1 -1
-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
<[email protected]>"
Quoted 8 lines
RECIPE_STATUS_pn-mpfr="green"
meta/conf/distro/include/distro_tracking_fields.inc +3 -2
-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
<[email protected]>"
Quoted 1 line
Quoted 2 lines
Quoted 2 lines
meta/conf/distro/include/distro_tracking_fields.inc RECIPE_MANUAL_CHECK_DATE_pn-libmpc = "Jan
Quoted 2 lines
RECIPE_STATUS_pn-gmp="green"
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -3110,9 +3120,10 @@ RECIPE_MANUAL_CHECK_DATE_pn-libmpc = "Jan
25,
Quoted 43 lines
Quoted 43 lines
2011"
Quoted 1 line
RECIPE_MAINTAINER_pn-libmpc = "Nitin A Kamble
<[email protected]>"
Quoted 9 lines
DISTRO_PN_ALIAS_pn-libmpc = "Fedora=libmpc OpenSuse=libmpc2"
meta/conf/distro/include/distro_tracking_fields.inc +1 -1
-RECIPE_STATUS_pn-byacc="red"
+RECIPE_STATUS_pn-byacc="green"
RECIPE_LATEST_VERSION_pn-byacc="20101229"
meta/conf/distro/include/distro_tracking_fields.inc +2 -1
-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
<[email protected]>"
meta/conf/distro/include/distro_tracking_fields.inc RECIPE_LAST_UPDATE_pn-libconvert-asn1-perl =
Quoted 3 lines
RECIPE_STATUS_pn-libconvert-asn1-perl="green"
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -3122,8 +3133,8 @@ RECIPE_LAST_UPDATE_pn-libconvert-asn1-perl =
"Aug 13, 2010"
Quoted 1 line
RECIPE_MAINTAINER_pn-libconvert-asn1-perl = "Nitin A Kamble
<[email protected]>"
Quoted 7 lines
RECIPE_STATUS_pn-libxml-parser-perl="green"
meta/conf/distro/include/distro_tracking_fields.inc +2 -2
-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
<[email protected]>"
meta/conf/distro/include/distro_tracking_fields.inc RECIPE_COMMENTS_pn-pseudo = "Yocto Project
Quoted 3 lines
RECIPE_STATUS_pn-cmake-native="green"
meta/conf/distro/include/distro_tracking_fields.inc +0 -0
@@ -5922,9 +5933,6 @@ RECIPE_COMMENTS_pn-pseudo = "Yocto Project
maintained"
Quoted 4 lines
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"
Quoted 1 line
-RECIPE_MAINTAINER_pn-btrfs-tools = "Nitin A Kamble
<[email protected]>"
Quoted 3 lines
-
DISTRO_PN_ALIAS_pn-rt-tests = "Debian=rt-tests Ubuntu=rt-tests" RECIPE_MAINTAINER_pn-rt-tests = "Darren Hart
<[email protected]>"
Quoted 1 line
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
--
1.7.6.2
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-
core
Quoted 6 lines
Quoted 6 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-
core
Quoted 5 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Koen Kooi

2011-10-19 16:43 UTC #19 lore raw

Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes

Op 19 okt. 2011, om 18:24 heeft Kamble, Nitin A het volgende geschreven:

Quoted 15 lines

Quoted 15 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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:

Quoted 7 lines

Quoted 6 lines
Quoted 2 lines
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.

Phil Blundell

2011-10-19 16:55 UTC #20 lore raw

Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes

Quoted 4 lines · Koen Kooi

Op 19 okt. 2011, om 18:24 heeft Kamble, Nitin A het volgende geschreven:
Quoted 1 line
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.

Saul Wold

2011-10-19 17:03 UTC #21 lore raw

Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes

Quoted 9 lines · Phil Blundell

Quoted 4 lines · Koen Kooi
Op 19 okt. 2011, om 18:24 heeft Kamble, Nitin A het volgende geschreven:
Quoted 1 line
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!

Quoted 9 lines

p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Khem Raj

2011-10-19 17:06 UTC #22 lore raw

Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes

Quoted 11 lines · Saul Wold

Quoted 10 lines · Phil Blundell
Quoted 7 lines · Koen Kooi
Op 19 okt. 2011, om 18:24 heeft Kamble, Nitin A het volgende geschreven:
Quoted 3 lines
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.

Quoted 7 lines

Quoted 3 lines
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.

Quoted 24 lines

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!
Quoted 9 lines
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Saul Wold

2011-10-19 17:51 UTC #23 lore raw

Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes

Quoted 15 lines · Khem Raj

Quoted 14 lines · Saul Wold
Quoted 13 lines · Phil Blundell
Quoted 7 lines · Koen Kooi
Op 19 okt. 2011, om 18:24 heeft Kamble, Nitin A het volgende geschreven:
Quoted 3 lines
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.

Quoted 8 lines

Quoted 4 lines
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!

Quoted 29 lines

Quoted 19 lines
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!
Quoted 9 lines
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 5 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Khem Raj

2011-10-19 18:36 UTC #24 lore raw

Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes

Quoted 24 lines · Saul Wold

Quoted 23 lines · Khem Raj
Quoted 20 lines · Saul Wold
Quoted 6 lines · Phil Blundell
Quoted 4 lines · Koen Kooi
Op 19 okt. 2011, om 18:24 heeft Kamble, Nitin A het volgende geschreven:
Quoted 1 line
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
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.

Quoted 8 lines

Quoted 3 lines
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

Quoted 3 lines

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.

Quoted 8 lines

Sau!
Quoted 6 lines
Quoted 6 lines
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.

Quoted 27 lines

Quoted 25 lines
Quoted 15 lines
Sau!
Quoted 9 lines
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 5 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Otavio Salvador

2011-10-19 19:05 UTC #25 lore raw

Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes

On Wed, Oct 19, 2011 at 16:30, Khem Raj <[email protected]> wrote:
...

Quoted 6 lines

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
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, ...

Quoted 6 lines

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.

Signature · 3 lines

Otavio Salvador                             O.S. Systems
E-mail: [email protected]  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Saul Wold

2011-10-19 23:39 UTC #26 lore raw

Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes

Quoted 15 lines · Otavio Salvador

On Wed, Oct 19, 2011 at 16:30, Khem Raj<[email protected]> wrote:
...
Quoted 6 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
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, ...
Quoted 6 lines
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.

Quoted 9 lines

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!

Richard Purdie

2011-10-20 14:32 UTC #27 lore raw

Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes

Quoted 22 lines · Saul Wold

Quoted 21 lines · Otavio Salvador
On Wed, Oct 19, 2011 at 16:30, Khem Raj<[email protected]> wrote:
...
Quoted 6 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
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, ...
Quoted 6 lines
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.

Quoted 6 lines

Quoted 3 lines
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

Martin Jansa

2011-10-20 14:49 UTC #28 lore raw

Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes

Quoted 45 lines · Richard Purdie

Quoted 22 lines · Saul Wold
Quoted 21 lines · Otavio Salvador
On Wed, Oct 19, 2011 at 16:30, Khem Raj<[email protected]> wrote:
...
Quoted 6 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
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, ...
Quoted 6 lines
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.
Quoted 6 lines
Quoted 3 lines
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:

Quoted 6 lines

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,

Signature · 1 line

Martin 'JaMa' Jansa     jabber: [email protected]

Koen Kooi

2011-10-20 14:54 UTC #29 lore raw

Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes

Op 20 okt. 2011, om 16:36 heeft Martin Jansa het volgende geschreven:

Quoted 62 lines · Richard Purdie

Quoted 45 lines · Saul Wold
Quoted 22 lines · Otavio Salvador
Quoted 21 lines · Khem Raj
...
Quoted 6 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
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, ...
Quoted 6 lines
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.
Quoted 6 lines
Quoted 3 lines
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:
Quoted 6 lines
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.

Quoted 5 lines

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

Richard Purdie

2011-10-20 16:01 UTC #30 lore raw

Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes

In reply to Martin Jansa

Quoted 50 lines · Martin Jansa

Quoted 49 lines · Richard Purdie
Quoted 22 lines · Saul Wold
Quoted 21 lines · Otavio Salvador
On Wed, Oct 19, 2011 at 16:30, Khem Raj<[email protected]> wrote:
...
Quoted 6 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
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, ...
Quoted 6 lines
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.
Quoted 6 lines
Quoted 3 lines
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

Quoted 6 lines

Quoted 2 lines
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.

Quoted 10 lines

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

Eric Bénard

2011-10-20 16:08 UTC #35 lore raw

Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes

In reply to Otavio Salvador

Hi,

Quoted 3 lines · Otavio Salvador

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

Khem Raj

2011-10-20 16:25 UTC #34 lore raw

Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes

In reply to Richard Purdie

Quoted 2 lines · Richard Purdie

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.

Quoted 1 line

c) Move the data out of OE-Core

For now this would be a better solution IMO

Quoted 4 lines

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.

Koen Kooi

2011-10-20 16:30 UTC #31 lore raw

Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes

In reply to Richard Purdie

Op 20 okt. 2011, om 17:55 heeft Richard Purdie het volgende geschreven:

Quoted 80 lines · Martin Jansa

Quoted 50 lines · Richard Purdie
Quoted 49 lines · Saul Wold
Quoted 22 lines · Otavio Salvador
Quoted 21 lines · Khem Raj
...
Quoted 6 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
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, ...
Quoted 6 lines
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.
Quoted 6 lines
Quoted 3 lines
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
Quoted 6 lines
Quoted 2 lines
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.
Quoted 10 lines
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.

Quoted 6 lines

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

Joshua Lock

2011-10-20 17:44 UTC #32 lore raw

Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes

On 10/20/2011 09:24 AM, Koen Kooi wrote:>

Quoted 3 lines

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

Signature · 3 lines

Joshua Lock
        Yocto Project "Johannes factotum"
        Intel Open Source Technology Centre

Saul Wold

2011-10-20 21:34 UTC #33 lore raw

Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes

In reply to Richard Purdie

Quoted 80 lines · Richard Purdie

Quoted 50 lines · Martin Jansa
Quoted 49 lines · Richard Purdie
Quoted 22 lines · Saul Wold
Quoted 21 lines · Otavio Salvador
On Wed, Oct 19, 2011 at 16:30, Khem Raj<[email protected]> wrote:
...
Quoted 6 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
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, ...
Quoted 6 lines
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.
Quoted 6 lines
Quoted 3 lines
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
Quoted 6 lines
Quoted 2 lines
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.
Quoted 10 lines
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.

Quoted 7 lines

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!

Quoted 12 lines

Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core