[PATCH] parted_1.8.6.bb: add parted that not GPLv3

[PATCH] parted_1.8.6.bb: add parted that not GPLv3

[Lei Maohui]

Add parted-1.8.6 which is not GPLv3.

Signed-off-by: Lei Maohui <leimaohui@cn.fujitsu.com>
---
 .../parted-1.8.6/1000parted-1.8.6-warnings1.patch  | 17 ++++++
 .../1001parted-1.8.6-notransname1.patch            | 45 ++++++++++++++++
 .../1002parted-1.8.6-off-by-one1.patch             | 31 +++++++++++
 .../1003parted-1.8.6-primary-boundary1.patch       | 18 +++++++
 .../parted-1.8.6/1004parted-1.8.6-xvd1.patch       | 56 ++++++++++++++++++++
 .../1005parted-1.8.6-devmapper-header1.patch       | 19 +++++++
 .../parted/parted-1.8.6/ui.c-fix-build-error.patch | 29 ++++++++++
 meta/recipes-extended/parted/parted_1.8.6.bb       | 61 ++++++++++++++++++++++
 8 files changed, 276 insertions(+)
 create mode 100644 meta/recipes-extended/parted/parted-1.8.6/1000parted-1.8.6-warnings1.patch
 create mode 100644 meta/recipes-extended/parted/parted-1.8.6/1001parted-1.8.6-notransname1.patch
 create mode 100644 meta/recipes-extended/parted/parted-1.8.6/1002parted-1.8.6-off-by-one1.patch
 create mode 100644 meta/recipes-extended/parted/parted-1.8.6/1003parted-1.8.6-primary-boundary1.patch
 create mode 100644 meta/recipes-extended/parted/parted-1.8.6/1004parted-1.8.6-xvd1.patch
 create mode 100644 meta/recipes-extended/parted/parted-1.8.6/1005parted-1.8.6-devmapper-header1.patch
 create mode 100644 meta/recipes-extended/parted/parted-1.8.6/ui.c-fix-build-error.patch
 create mode 100644 meta/recipes-extended/parted/parted_1.8.6.bb

diff --git a/meta/recipes-extended/parted/parted-1.8.6/1000parted-1.8.6-warnings1.patch b/meta/recipes-extended/parted/parted-1.8.6/1000parted-1.8.6-warnings1.patch
new file mode 100644
index 0000000..83455ee
--- /dev/null
+++ b/meta/recipes-extended/parted/parted-1.8.6/1000parted-1.8.6-warnings1.patch
@@ -0,0 +1,17 @@
+This patch comes from: http://pkgs.fedoraproject.org/cgit/parted.git/commit/?id=ce690b23703eb5295d116cdb972a04260ef5ddec
+
+Upstream-Status: Pending
+
+Signed-off-by: Signed-off-by: Lei Maohui <leimaohui@cn.fujitsu.com>
+
+--- parted-1.8.6/libparted/fs/linux_swap/linux_swap.c.warnings	2007-03-20 13:22:36.000000000 -0400
++++ parted-1.8.6/libparted/fs/linux_swap/linux_swap.c	2007-03-20 13:59:11.000000000 -0400
+@@ -123,7 +123,7 @@
+ 
+ error_close_fs:
+ 	swap_close (fs);
+-error:
++
+ 	return 0;
+ }
+ #endif /* !DISCOVER_ONLY */
diff --git a/meta/recipes-extended/parted/parted-1.8.6/1001parted-1.8.6-notransname1.patch b/meta/recipes-extended/parted/parted-1.8.6/1001parted-1.8.6-notransname1.patch
new file mode 100644
index 0000000..7fbfde7
--- /dev/null
+++ b/meta/recipes-extended/parted/parted-1.8.6/1001parted-1.8.6-notransname1.patch
@@ -0,0 +1,45 @@
+This patch comes from: http://pkgs.fedoraproject.org/cgit/parted.git/commit/?id=e13022c01a2cd944e28c61827c96b0a37f4eecf0
+
+Upstream-Status: Pending
+
+Signed-off-by: Signed-off-by: Lei Maohui <leimaohui@cn.fujitsu.com>
+
+--- parted-1.8.6/parted/parted.c.notransname	2007-03-13 13:01:09.000000000 -0400
++++ parted-1.8.6/parted/parted.c	2007-03-21 10:50:35.000000000 -0400
+@@ -1429,7 +1429,7 @@
+                                              part->fs_type->name : "");
+ 
+                             if (has_name) {
+-                                    name = _(ped_partition_get_name (part));
++                                    name = ped_partition_get_name (part);
+                                     str_list_append (row, name);
+                             }
+ 
+--- parted-1.8.6/parted/table.c.notransname	2007-03-13 13:01:09.000000000 -0400
++++ parted-1.8.6/parted/table.c	2007-03-21 10:51:31.000000000 -0400
+@@ -191,7 +191,8 @@
+         len += wcslen(COLSUFFIX);
+ 
+         newsize = (wcslen(*s) + len + 1) * sizeof(wchar_t);
+-        *s = realloc (*s, newsize);
++        *s = (wchar_t *) realloc (*s, newsize);
++        assert(*s != NULL);
+ 
+         for (i = 0; i < ncols; ++i)
+         {
+@@ -199,6 +200,7 @@
+                 int nspaces = max(t->widths[i] - wcswidth(row[i], MAX_WIDTH),
+                                   0);
+                 wchar_t* pad = malloc ( (nspaces + 1) * sizeof(wchar_t) );
++                assert(pad != NULL);
+ 
+                 for (j = 0; j < nspaces; ++j)
+                        pad[j] = L' '; 
+@@ -211,6 +213,7 @@
+                         wcscat (*s, DELIMITER);
+ 
+                 free (pad);
++                pad = NULL;
+         }
+ 
+         wcscat (*s, COLSUFFIX);
diff --git a/meta/recipes-extended/parted/parted-1.8.6/1002parted-1.8.6-off-by-one1.patch b/meta/recipes-extended/parted/parted-1.8.6/1002parted-1.8.6-off-by-one1.patch
new file mode 100644
index 0000000..dde5c29
--- /dev/null
+++ b/meta/recipes-extended/parted/parted-1.8.6/1002parted-1.8.6-off-by-one1.patch
@@ -0,0 +1,31 @@
+This patch comes from: http://pkgs.fedoraproject.org/cgit/parted.git/commit/?id=cb95a1496c040be5e9de8f674224619fd47648c3
+
+Upstream-Status: Pending
+
+Signed-off-by: Signed-off-by: Lei Maohui <leimaohui@cn.fujitsu.com>
+
+--- parted-1.8.6/parted/parted.c.offbyone	2007-04-11 12:13:06.000000000 -0400
++++ parted-1.8.6/parted/parted.c	2007-04-11 12:13:21.000000000 -0400
+@@ -1217,6 +1217,7 @@
+ static int
+ do_print (PedDevice** dev)
+ {
++        PedUnit         default_unit;
+         PedDisk*        disk;
+         Table*          table;
+         StrList*        row;
+@@ -1303,11 +1304,12 @@
+         }
+ 
+         start = ped_unit_format (*dev, 0);
++        default_unit = ped_unit_get_default ();
+         end = ped_unit_format_byte (*dev, (*dev)->length * (*dev)->sector_size
+-                                          - 1 );
++         - (default_unit == PED_UNIT_CHS || default_unit == PED_UNIT_CYLINDER));
+         
+         if (opt_machine_mode) {
+-            switch (ped_unit_get_default ()) {
++            switch (default_unit) {
+                 case PED_UNIT_CHS:      puts ("CHS;");
+                                         break;
+                 case PED_UNIT_CYLINDER: puts ("CYL;");
diff --git a/meta/recipes-extended/parted/parted-1.8.6/1003parted-1.8.6-primary-boundary1.patch b/meta/recipes-extended/parted/parted-1.8.6/1003parted-1.8.6-primary-boundary1.patch
new file mode 100644
index 0000000..b671503
--- /dev/null
+++ b/meta/recipes-extended/parted/parted-1.8.6/1003parted-1.8.6-primary-boundary1.patch
@@ -0,0 +1,18 @@
+This patch comes from: http://pkgs.fedoraproject.org/cgit/parted.git/commit/?id=19cd527b151ec518ae72b6566efc1a882b2f79d8
+
+Upstream-Status: Pending
+
+Signed-off-by: Signed-off-by: Lei Maohui <leimaohui@cn.fujitsu.com>
+
+--- parted-1.8.6/libparted/labels/dos.c.boundary	2007-03-13 13:01:09.000000000 -0400
++++ parted-1.8.6/libparted/labels/dos.c	2007-04-11 14:56:54.000000000 -0400
+@@ -1696,8 +1696,7 @@
+ 					 _primary_start_constraint (disk, part,
+ 						 bios_geom, min_geom)));
+ 
+-	if (!solution)
+-		solution = _best_solution (part, bios_geom, solution,
++	solution = _best_solution (part, bios_geom, solution,
+ 			_try_constraint (part, constraint,
+ 				_primary_constraint (disk, bios_geom,
+ 				min_geom)));
diff --git a/meta/recipes-extended/parted/parted-1.8.6/1004parted-1.8.6-xvd1.patch b/meta/recipes-extended/parted/parted-1.8.6/1004parted-1.8.6-xvd1.patch
new file mode 100644
index 0000000..7dbdab2
--- /dev/null
+++ b/meta/recipes-extended/parted/parted-1.8.6/1004parted-1.8.6-xvd1.patch
@@ -0,0 +1,56 @@
+This patch comes from: http://pkgs.fedoraproject.org/cgit/parted.git/commit/?id=f6ed55a348c50836977e04dedaad4bbb5e77c3a3
+
+Upstream-Status: Pending
+
+Signed-off-by: Signed-off-by: Lei Maohui <leimaohui@cn.fujitsu.com>
+
+diff -up parted-1.8.6/libparted/arch/linux.c.xvd parted-1.8.6/libparted/arch/linux.c
+--- parted-1.8.6/libparted/arch/linux.c.xvd	2007-08-07 14:05:59.000000000 -0400
++++ parted-1.8.6/libparted/arch/linux.c	2007-08-07 14:07:13.000000000 -0400
+@@ -248,6 +248,7 @@ struct blkdev_ioctl_param {
+ #define VIODASD_MAJOR           112
+ #define SX8_MAJOR1              160
+ #define SX8_MAJOR2              161
++#define XVD_MAJOR               202
+ 
+ #define SCSI_BLK_MAJOR(M) (                                             \
+                 (M) == SCSI_DISK0_MAJOR                                 \
+@@ -450,6 +451,8 @@ _device_probe_type (PedDevice* dev)
+         } else if (_is_dm_major(dev_major)) {
+                 dev->type = PED_DEVICE_DM;
+ #endif
++        } else if (dev_major == XVD_MAJOR && (dev_minor % 0x10 == 0)) {
++                dev->type = PED_DEVICE_XVD;
+         } else {
+                 dev->type = PED_DEVICE_UNKNOWN;
+         }
+@@ -1152,6 +1155,11 @@ linux_new (const char* path)
+                 break;
+ #endif
+ 
++        case PED_DEVICE_XVD:
++                if (!init_generic (dev, _("Xen Virtual Block Device")))
++                        goto error_free_arch_specific;
++                break;
++
+         case PED_DEVICE_UNKNOWN:
+                 if (!init_generic (dev, _("Unknown")))
+                         goto error_free_arch_specific;
+diff -up parted-1.8.6/include/parted/device.h.xvd parted-1.8.6/include/parted/device.h
+--- parted-1.8.6/include/parted/device.h.xvd	2007-01-12 10:15:10.000000000 -0500
++++ parted-1.8.6/include/parted/device.h	2007-08-07 14:07:13.000000000 -0400
+@@ -45,11 +45,11 @@ typedef enum {
+         PED_DEVICE_UBD          = 8,
+         PED_DEVICE_DASD         = 9,
+         PED_DEVICE_VIODASD      = 10,
+-        PED_DEVICE_SX8          = 11
++        PED_DEVICE_SX8          = 11,
+ #ifdef ENABLE_DEVICE_MAPPER
+-                                    ,
+-        PED_DEVICE_DM           = 12
++        PED_DEVICE_DM           = 12,
+ #endif
++        PED_DEVICE_XVD          = 13
+ } PedDeviceType;
+ 
+ typedef struct _PedDevice PedDevice;
diff --git a/meta/recipes-extended/parted/parted-1.8.6/1005parted-1.8.6-devmapper-header1.patch b/meta/recipes-extended/parted/parted-1.8.6/1005parted-1.8.6-devmapper-header1.patch
new file mode 100644
index 0000000..cc410ef
--- /dev/null
+++ b/meta/recipes-extended/parted/parted-1.8.6/1005parted-1.8.6-devmapper-header1.patch
@@ -0,0 +1,19 @@
+This patch comes from: http://pkgs.fedoraproject.org/cgit/parted.git/commit/?id=2b24ccacbd8e454ba62027fb5c85fc8f175e1da7
+
+Upstream-Status: Pending
+
+Signed-off-by: Signed-off-by: Lei Maohui <leimaohui@cn.fujitsu.com>
+
+diff -up parted-1.8.6/include/parted/device.h.devmapper parted-1.8.6/include/parted/device.h
+--- parted-1.8.6/include/parted/device.h.devmapper	2007-10-04 15:39:27.000000000 -0400
++++ parted-1.8.6/include/parted/device.h	2007-10-04 15:40:11.000000000 -0400
+@@ -46,9 +46,7 @@ typedef enum {
+         PED_DEVICE_DASD         = 9,
+         PED_DEVICE_VIODASD      = 10,
+         PED_DEVICE_SX8          = 11,
+-#ifdef ENABLE_DEVICE_MAPPER
+         PED_DEVICE_DM           = 12,
+-#endif
+         PED_DEVICE_XVD          = 13
+ } PedDeviceType;
+ 
diff --git a/meta/recipes-extended/parted/parted-1.8.6/ui.c-fix-build-error.patch b/meta/recipes-extended/parted/parted-1.8.6/ui.c-fix-build-error.patch
new file mode 100644
index 0000000..82e2146
--- /dev/null
+++ b/meta/recipes-extended/parted/parted-1.8.6/ui.c-fix-build-error.patch
@@ -0,0 +1,29 @@
+From 4f4dfd5aabdaadd8f495e193ca8daed5a3a1782a Mon Sep 17 00:00:00 2001
+From: Li xin <lixin.fnst@cn.fujitsu.com>
+Date: Fri, 28 Nov 2014 02:49:19 +0900
+Subject: [PATCH] parted/ui.c : fix build error
+
+Otherwise,there will be an error when build for arm as the following:
+"error: 'CPPFunction' undeclared (first use in this function)"
+
+Signed-off-by: Li Xin <lixin.fnst@cn.fujitsu.com>
+---
+ parted/ui.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/parted/ui.c b/parted/ui.c
+index 59cb98b..b583693 100644
+--- a/parted/ui.c
++++ b/parted/ui.c
+@@ -1376,7 +1376,7 @@ init_ui ()
+ 
+ #ifdef HAVE_LIBREADLINE
+         rl_initialize ();
+-        rl_attempted_completion_function = (CPPFunction*) complete_function;
++        rl_attempted_completion_function = (rl_completion_func_t*) complete_function;
+         readline_state.in_readline = 0;
+ #endif
+ 
+-- 
+1.8.4.2
+
diff --git a/meta/recipes-extended/parted/parted_1.8.6.bb b/meta/recipes-extended/parted/parted_1.8.6.bb
new file mode 100644
index 0000000..9c19b0f
--- /dev/null
+++ b/meta/recipes-extended/parted/parted_1.8.6.bb
@@ -0,0 +1,61 @@
+SUMMARY = "The GNU disk partition manipulation program"
+DESCRIPTION = "The GNU Parted program allows you to create, destroy, resize, move, \
+and copy hard disk partitions. Parted can be used for creating space \
+for new operating systems, reorganizing disk usage, and copying data \
+to new hard disks."
+HOMEPAGE = "http://www.gnu.org/software/parted"
+SECTION = "Applications/System"
+
+SRC_URI = "http://ftp.gnu.org/gnu/parted/parted-1.8.6.tar.bz2 \
+	   file://1000parted-1.8.6-warnings1.patch \
+	   file://1001parted-1.8.6-notransname1.patch \
+	   file://1002parted-1.8.6-off-by-one1.patch \
+	   file://1003parted-1.8.6-primary-boundary1.patch \
+	   file://1004parted-1.8.6-xvd1.patch \
+	   file://1005parted-1.8.6-devmapper-header1.patch \
+           file://ui.c-fix-build-error.patch \
+	   "
+
+SRC_URI[md5sum] = "03c967ae0e915e08da90605d68ba93d7"
+SRC_URI[sha256sum] = "82d94c9bb58cccd1eacfc5ff3a9331d179cc26d8fbe00c451e2c84feb6d23408"
+
+LICENSE = "GPLv2+"
+LIC_FILES_CHKSUM = "file://COPYING;md5=eb723b61539feef013de476e68b5c50a"
+
+inherit autotools gettext pkgconfig
+
+DEPENDS = "lvm2 readline"
+
+EXTRA_OECONF = "--enable-device-mapper \
+	        --disable-selinux \
+	        --disable-static \
+	        --sbindir=${sbindir} \
+	        --disable-Werror \
+	        --disable-rpath \
+	        "
+EXTRA_OEMAKE = "DESTDIR=${D}"
+
+do_configure_prepend() {
+	# ltmain.sh will set rpath to path on host.
+	for l in `find ${S} -name "ltmain\.sh"` ; do
+		sed -i -e 's/\$compile_rpath//g' \
+		       -e 's/\$finalize_rpath//g' ${l}
+	done
+
+	# FIXME: Some option may be needed by EXTRA_OECONF.
+	sed -i 's/ac_cv_func_malloc_0_nonnull=no/ac_cv_func_malloc_0_nonnull=yes/g' ${S}/configure
+	sed -i 's/ac_cv_func_calloc_0_nonnull=no/ac_cv_func_calloc_0_nonnull=yes/g' ${S}/configure
+	sed -i 's/ac_cv_func_memcmp_working=no/ac_cv_func_memcmp_working=yes/g' ${S}/configure
+	sed -i 's/ac_cv_func_realloc_0_nonnull=no/ac_cv_func_realloc_0_nonnull=yes/g' ${S}/configure
+}
+
+do_configure() {
+	oe_runconf
+}
+
+do_install_append() {
+	/bin/rm -rf ${D}/${libdir}/*.la
+	/bin/rm -rf ${D}/usr/share/info/dir
+	/bin/rm -fr ${D}/usr/bin
+}
+
-- 
2.1.0

Re: [PATCH] parted_1.8.6.bb: add parted that not GPLv3

[alexander.kanavin]

> Add parted-1.8.6 which is not GPLv3.

I have to say, I still can't support having this in oe-core. Providing
alternatives to GPLv3 software is fine, but not when the 'alternative' is
a very old, unsupported version of the same software, which inevitably
brings issues in functionality and maintenance.

But if Ross and/or Richard disagree, then I'll have to accept it.

> +Upstream-Status: Pending

"Inappropriate" is a better reason here, with clarification that the
patches are to make an old version work and upstream won't be interested
in them.

> +do_install_append() {
> +	/bin/rm -rf ${D}/${libdir}/*.la
> +	/bin/rm -rf ${D}/usr/share/info/dir
> +	/bin/rm -fr ${D}/usr/bin
> +}

What are you deleting here and why?

Alex

Re: [PATCH] parted_1.8.6.bb: add parted that not GPLv3

[Otavio Salvador]

On Thu, Jul 9, 2015 at 8:33 AM,  <alexander.kanavin@linux.intel.com> wrote:
>> Add parted-1.8.6 which is not GPLv3.
>
> I have to say, I still can't support having this in oe-core. Providing
> alternatives to GPLv3 software is fine, but not when the 'alternative' is
> a very old, unsupported version of the same software, which inevitably
> brings issues in functionality and maintenance.

Parted 1.8 is very old and not supported at all. The number of fixes
after it is such huge which makes Parted mostly useless in new storage
and disk formats. I see NO benefit in having it and a serious
maintenance burden.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH] parted_1.8.6.bb: add parted that not GPLv3

[Lei, Maohui]

Hi Alex

> > +do_install_append() {
> > +	/bin/rm -rf ${D}/${libdir}/*.la
> > +	/bin/rm -rf ${D}/usr/share/info/dir
> > +	/bin/rm -fr ${D}/usr/bin
> > +}
>

Reference to fedora and Ubuntu, I delete these files.


Cheers
Lei


> -----Original Message-----
> From: alexander.kanavin@linux.intel.com [mailto:alexander.kanavin@linux.intel.com]
> Sent: Thursday, July 09, 2015 7:33 PM
> To: Lei, Maohui
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] parted_1.8.6.bb: add parted that not GPLv3
> 
> > Add parted-1.8.6 which is not GPLv3.
> 
> I have to say, I still can't support having this in oe-core. Providing alternatives to GPLv3
> software is fine, but not when the 'alternative' is a very old, unsupported version of the
> same software, which inevitably brings issues in functionality and maintenance.
> 
> But if Ross and/or Richard disagree, then I'll have to accept it.
> 
> > +Upstream-Status: Pending
> 
> "Inappropriate" is a better reason here, with clarification that the patches are to make an
> old version work and upstream won't be interested in them.
> 
> > +do_install_append() {
> > +	/bin/rm -rf ${D}/${libdir}/*.la
> > +	/bin/rm -rf ${D}/usr/share/info/dir
> > +	/bin/rm -fr ${D}/usr/bin
> > +}
> 
> What are you deleting here and why?
> 
> Alex

Re: [PATCH] parted_1.8.6.bb: add parted that not GPLv3

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 449 bytes --]

On 9 July 2015 at 12:38, Otavio Salvador <otavio@ossystems.com.br> wrote:

> Parted 1.8 is very old and not supported at all. The number of fixes
> after it is such huge which makes Parted mostly useless in new storage
> and disk formats. I see NO benefit in having it and a serious
> maintenance burden.
>

I wasn't aware the situation with the old parted was that bad...  maybe
this should be in meta-oe (if anywhere) after all?

Ross

[-- Attachment #2: Type: text/html, Size: 865 bytes --]

Re: [PATCH] parted_1.8.6.bb: add parted that not GPLv3

[Andre McCurdy]

On Fri, Jul 10, 2015 at 3:31 PM, Burton, Ross <ross.burton@intel.com> wrote:
>
> On 9 July 2015 at 12:38, Otavio Salvador <otavio@ossystems.com.br> wrote:
>>
>> Parted 1.8 is very old and not supported at all. The number of fixes
>> after it is such huge which makes Parted mostly useless in new storage
>> and disk formats. I see NO benefit in having it and a serious
>> maintenance burden.
>
> I wasn't aware the situation with the old parted was that bad...  maybe this
> should be in meta-oe (if anywhere) after all?

GPLv3 was released in June 2007 and most GNU packages transitioned to
it fairly quickly, so by definition, the pre-GPLv3 version of any GNU
package is now very old and unsupported. We do have a precedent for
keeping pre-GPLv3 versions alive though (a good thing for those of us
who need them!). What makes parted different from the other pre-GPLv3
packages which are already in oe-core?

Looking at the parted changelog, there have certainly been a lot of
bug fixes since 1.8.7 (the last GPLv2 version) but it's difficult to
tell how many are for functionality which would be relevant to a
typical embedded system.

  http://git.savannah.gnu.org/cgit/parted.git/tree/NEWS

RHEL 5 seems to have been maintaining it's version of parted 1.8.1 up
until Jan 2013. RHEL's 33 patches might be a good source of fixes for
parted 1.8.7.

  http://vault.centos.org/5.11/os/SRPMS/parted-1.8.1-30.el5.src.rpm

As someone has volunteered to maintain the pre-GPLv3 parted recipe
(and I'll volunteer as a secondary maintainer, if that helps)
hopefully there would not be a "serious maintenance burden" on anyone
who doesn't have an interest in the older version.

>
> Ross
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Richard Purdie]

On Sat, 2015-07-11 at 00:20 -0700, Andre McCurdy wrote:
> GPLv3 was released in June 2007 and most GNU packages transitioned to
> it fairly quickly, so by definition, the pre-GPLv3 version of any GNU
> package is now very old and unsupported. We do have a precedent for
> keeping pre-GPLv3 versions alive though (a good thing for those of us
> who need them!). What makes parted different from the other pre-GPLv3
> packages which are already in oe-core?
> 
> Looking at the parted changelog, there have certainly been a lot of
> bug fixes since 1.8.7 (the last GPLv2 version) but it's difficult to
> tell how many are for functionality which would be relevant to a
> typical embedded system.
> 
>   http://git.savannah.gnu.org/cgit/parted.git/tree/NEWS
> 
> RHEL 5 seems to have been maintaining it's version of parted 1.8.1 up
> until Jan 2013. RHEL's 33 patches might be a good source of fixes for
> parted 1.8.7.
> 
>   http://vault.centos.org/5.11/os/SRPMS/parted-1.8.1-30.el5.src.rpm
> 
> As someone has volunteered to maintain the pre-GPLv3 parted recipe
> (and I'll volunteer as a secondary maintainer, if that helps)
> hopefully there would not be a "serious maintenance burden" on anyone
> who doesn't have an interest in the older version.

This does touch on something I have wondered about for a while, which is
whether the time has come to move the GPLv2 pieces to their own layer
and possibly their own maintainership. Obviously there are pros and cons
to doing that.

Thoughts?

Cheers,

Richard

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Alexander Kanavin]

On 07/11/2015 10:57 AM, Richard Purdie wrote:

> This does touch on something I have wondered about for a while, which is
> whether the time has come to move the GPLv2 pieces to their own layer
> and possibly their own maintainership. Obviously there are pros and cons
> to doing that.
>
> Thoughts?

I'm all for that, which shouldn't be surprising :) The rationale is that 
we need to keep the scope and breadth of oe-core sane and manageable. 
The emphasis should be on having lesser amount of high quality, 
up-to-date recipes than vice versa.

That means a continuous lookout for possible things to remove. Qt4 is 
one such thing, old GPLv2 software is another.


Alex

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Andre McCurdy]

On Thu, Jul 30, 2015 at 5:06 AM, Alexander Kanavin
<alexander.kanavin@linux.intel.com> wrote:
> On 07/11/2015 10:57 AM, Richard Purdie wrote:
>
>> This does touch on something I have wondered about for a while, which is
>> whether the time has come to move the GPLv2 pieces to their own layer
>> and possibly their own maintainership. Obviously there are pros and cons
>> to doing that.
>>
>> Thoughts?
>
> I'm all for that, which shouldn't be surprising :) The rationale is that we
> need to keep the scope and breadth of oe-core sane and manageable. The
> emphasis should be on having lesser amount of high quality, up-to-date
> recipes than vice versa.

To play devil's advocate, a counter argument could be:

The number of high quality recipes which can be maintained in oe-core
depends on the number of developers actively using and contributing to
oe-core. More active developers means more recipes can be maintained
to a high quality.

By restricting the scope of oe-core you reduce the number of
developers who are able to use it directly. If the developers who can
no longer use oe-core directly lose interest in tracking master
between releases or start to go off and maintain their own personal
forks, then you reduce the number of developers actively using and
contributing to oe-core.

Whether oe-core is at a stage in it's life cycle where it would
benefit more from growing it's developer base or from knuckling down
and focusing on a smaller set of core functionality is an interesting
question...


> That means a continuous lookout for possible things to remove. Qt4 is one
> such thing, old GPLv2 software is another.
>
>
> Alex
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Alexander Kanavin]

On 07/31/2015 02:14 AM, Andre McCurdy wrote:

> The number of high quality recipes which can be maintained in oe-core
> depends on the number of developers actively using and contributing to
> oe-core. More active developers means more recipes can be maintained
> to a high quality.

My issue here is quality control. Someone still has to review the work 
of those volunteer developers, and take action when they fail to take 
action. Yocto at the moment does not have such a self-sustaining 
community process - it all still goes through 'core' oe-core developers, 
and those developers can't have any more workload.


Alex

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Khem Raj]

On Sat, Jul 11, 2015 at 12:57 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>> As someone has volunteered to maintain the pre-GPLv3 parted recipe
>> (and I'll volunteer as a secondary maintainer, if that helps)
>> hopefully there would not be a "serious maintenance burden" on anyone
>> who doesn't have an interest in the older version.
>
> This does touch on something I have wondered about for a while, which is
> whether the time has come to move the GPLv2 pieces to their own layer
> and possibly their own maintainership. Obviously there are pros and cons
> to doing that.
>
> Thoughts?
>

interesting case, although, I know lot of real usecases of OE which
disable GPLv3 distro wide and in fact is considered a strong point for
its users, if we were to maintain them in separate layer
this would be fine but we will send a wrong message to users since we
have to clarify its not all gpl2 code but only the code which is old
and has moved to v3 etc. can cause confusion, OE's users are a bit
different than desktop distros. Now if we were talking about moving
all of GPL recipes to layer of its own thats a separate case and may
be more useful but is that possible ?

I suggest to do a survey of its use before dropping it out.

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Khem Raj]

On Fri, Jul 31, 2015 at 4:41 AM, Alexander Kanavin
<alexander.kanavin@linux.intel.com> wrote:
> My issue here is quality control. Someone still has to review the work of
> those volunteer developers, and take action when they fail to take action.
> Yocto at the moment does not have such a self-sustaining community process -
> it all still goes through 'core' oe-core developers, and those developers
> can't have any more workload.

its a delicate balance of usability of target audience as well. If you
make it high quality but ignore real use case of end users you lose
and you lose otherway around too.

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Philip Balister]

On 08/07/2015 08:12 AM, Khem Raj wrote:
> On Fri, Jul 31, 2015 at 4:41 AM, Alexander Kanavin
> <alexander.kanavin@linux.intel.com> wrote:
>> My issue here is quality control. Someone still has to review the work of
>> those volunteer developers, and take action when they fail to take action.
>> Yocto at the moment does not have such a self-sustaining community process -
>> it all still goes through 'core' oe-core developers, and those developers
>> can't have any more workload.
> 
> its a delicate balance of usability of target audience as well. If you
> make it high quality but ignore real use case of end users you lose
> and you lose otherway around too.
> 

Thanks Khem. I also do not agree that we lack a self-sustaining
community. OpenEmbedded has functioned independently for far longer than
the Yocto Project has existed.

Philip

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Alexander Kanavin]

On 08/07/2015 12:17 PM, Philip Balister wrote:

> Thanks Khem. I also do not agree that we lack a self-sustaining
> community. OpenEmbedded has functioned independently for far longer than
> the Yocto Project has existed.

By 'self-sustaining' I mean 'being able to continuously produce quality 
work'. Looking at layers in meta-openembedded, not all of them are of 
high quality. Meta-gnome in particular is badly out of date, because no 
one wants to maintain it properly. If oe-core starts taking a lot more 
volunteer contributions, and the same thing happens (a volunteer 
contributes a large set of recipes, then disappears), what is supposed 
to happen then?


Alex

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 970 bytes --]


> On Aug 7, 2015, at 5:26 AM, Alexander Kanavin <alexander.kanavin@linux.intel.com> wrote:
> 
> On 08/07/2015 12:17 PM, Philip Balister wrote:
> 
>> Thanks Khem. I also do not agree that we lack a self-sustaining
>> community. OpenEmbedded has functioned independently for far longer than
>> the Yocto Project has existed.
> 
> By 'self-sustaining' I mean 'being able to continuously produce quality work'. Looking at layers in meta-openembedded, not all of them are of high quality. Meta-gnome in particular is badly out of date, because no one wants to maintain it properly. If oe-core starts taking a lot more volunteer contributions,

what a bizarre statement. Let me remind you OE is a open source project still and maintained by volunteers.

> and the same thing happens (a volunteer contributes a large set of recipes, then disappears), what is supposed to happen then?

someone else picks it up or it rots and get relegated.

> 
> 
> Alex


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Philip Balister]

On 08/07/2015 02:26 PM, Alexander Kanavin wrote:
> On 08/07/2015 12:17 PM, Philip Balister wrote:
> 
>> Thanks Khem. I also do not agree that we lack a self-sustaining
>> community. OpenEmbedded has functioned independently for far longer than
>> the Yocto Project has existed.
> 
> By 'self-sustaining' I mean 'being able to continuously produce quality
> work'. Looking at layers in meta-openembedded, not all of them are of
> high quality. Meta-gnome in particular is badly out of date, because no
> one wants to maintain it properly. If oe-core starts taking a lot more
> volunteer contributions, and the same thing happens (a volunteer
> contributes a large set of recipes, then disappears), what is supposed
> to happen then?

You are missing the point. We now use layers to segregate sets of
recipes o stuff that is not interesting to many people and becomes
obsolete may decline without compromising heavily used layers. This is
all part of the evolution of OpenEmbedded over many, many years.

If people lose interest in meta-gplv2, then so be it.

Philip

> 
> 
> Alex
> 

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Alexander Kanavin]

On 08/08/2015 08:09 PM, Philip Balister wrote:
>> By 'self-sustaining' I mean 'being able to continuously produce quality
>> work'. Looking at layers in meta-openembedded, not all of them are of
>> high quality. Meta-gnome in particular is badly out of date, because no
>> one wants to maintain it properly. If oe-core starts taking a lot more
>> volunteer contributions, and the same thing happens (a volunteer
>> contributes a large set of recipes, then disappears), what is supposed
>> to happen then?
>
> You are missing the point. We now use layers to segregate sets of
> recipes o stuff that is not interesting to many people and becomes
> obsolete may decline without compromising heavily used layers. This is
> all part of the evolution of OpenEmbedded over many, many years.
>
> If people lose interest in meta-gplv2, then so be it.

This is perfectly fine with me. However, the subject has been whether 
the scope of *oe-core/poky* can be expanded without compromising 
quality. I'm not sure at which point it got confused with general OE, so 
I can only refer you back to several emails up this thread:

http://lists.openembedded.org/pipermail/openembedded-core/2015-July/108037.html
http://lists.openembedded.org/pipermail/openembedded-core/2015-July/108167.html
http://lists.openembedded.org/pipermail/openembedded-core/2015-July/108208.html


Alex

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Philip Balister]

On 08/10/2015 02:13 PM, Alexander Kanavin wrote:
> On 08/08/2015 08:09 PM, Philip Balister wrote:
>>> By 'self-sustaining' I mean 'being able to continuously produce quality
>>> work'. Looking at layers in meta-openembedded, not all of them are of
>>> high quality. Meta-gnome in particular is badly out of date, because no
>>> one wants to maintain it properly. If oe-core starts taking a lot more
>>> volunteer contributions, and the same thing happens (a volunteer
>>> contributes a large set of recipes, then disappears), what is supposed
>>> to happen then?
>>
>> You are missing the point. We now use layers to segregate sets of
>> recipes o stuff that is not interesting to many people and becomes
>> obsolete may decline without compromising heavily used layers. This is
>> all part of the evolution of OpenEmbedded over many, many years.
>>
>> If people lose interest in meta-gplv2, then so be it.
> 
> This is perfectly fine with me. However, the subject has been whether
> the scope of *oe-core/poky* can be expanded without compromising

What is Poky?

Philip

> quality. I'm not sure at which point it got confused with general OE, so
> I can only refer you back to several emails up this thread:
> 
> http://lists.openembedded.org/pipermail/openembedded-core/2015-July/108037.html
> 
> http://lists.openembedded.org/pipermail/openembedded-core/2015-July/108167.html
> 
> http://lists.openembedded.org/pipermail/openembedded-core/2015-July/108208.html
> 
> 
> 
> Alex
> 

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Alexander Kanavin]

On 08/10/2015 10:15 PM, Philip Balister wrote:

>> This is perfectly fine with me. However, the subject has been whether
>> the scope of *oe-core/poky* can be expanded without compromising
>
> What is Poky?

Uhm... http://git.yoctoproject.org/cgit/cgit.cgi/poky/about/


Alex

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Khem Raj]

On Tue, Aug 11, 2015 at 6:26 AM, Alexander Kanavin
<alexander.kanavin@linux.intel.com> wrote:
> On 08/10/2015 10:15 PM, Philip Balister wrote:
>
>>> This is perfectly fine with me. However, the subject has been whether
>>> the scope of *oe-core/poky* can be expanded without compromising
>>
>>
>> What is Poky?
>
>
> Uhm... http://git.yoctoproject.org/cgit/cgit.cgi/poky/about/
>

can we freeze this thread please.

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]

On 11 August 2015 at 16:46, Khem Raj <raj.khem@gmail.com> wrote:

> can we freeze this thread please.
>

Or more usefully, reboot it.  Philip, you're turning into Koen!  Alex, if
someone on this list asks what Poky is, 99% of the time they're trolling.
 :)

The original and unanswered question was "should oe-core continue to
maintain GPLv2 recipes where upstream has moved to GPLv3 or should those
recipes move to a standalone layer" with various implied questions:

- If the v2 recipes move to a separate layer, who own/maintains/tests it?
- Should there be v2 recipes for every recipe that has moved to v3, or only
(as is now) the "more-core" recipes (currently YP tests that
core-image-base builds without GPLv3, nothing else more complicated)
- Should meta-gplv2 only contain recipes from oe-core, or all layers?  If
other layers decide to hold both v3 and v2 recipes (not that I'm aware any
have), what makes oe-core special?

I'm torn, Richard is torn.  Neither of those are useful to forming a
decision.  Does anyone else have any *useful* feedback?

Ross

[-- Attachment #2: Type: text/html, Size: 1590 bytes --]

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Otavio Salvador]

On Tue, Aug 11, 2015 at 5:36 PM, Burton, Ross <ross.burton@intel.com> wrote:
>
> On 11 August 2015 at 16:46, Khem Raj <raj.khem@gmail.com> wrote:
>>
>> can we freeze this thread please.
>
>
> Or more usefully, reboot it.  Philip, you're turning into Koen!  Alex, if
> someone on this list asks what Poky is, 99% of the time they're trolling.
> :)
>
> The original and unanswered question was "should oe-core continue to
> maintain GPLv2 recipes where upstream has moved to GPLv3 or should those
> recipes move to a standalone layer" with various implied questions:
>
> - If the v2 recipes move to a separate layer, who own/maintains/tests it?
> - Should there be v2 recipes for every recipe that has moved to v3, or only
> (as is now) the "more-core" recipes (currently YP tests that core-image-base
> builds without GPLv3, nothing else more complicated)
> - Should meta-gplv2 only contain recipes from oe-core, or all layers?  If
> other layers decide to hold both v3 and v2 recipes (not that I'm aware any
> have), what makes oe-core special?
>
> I'm torn, Richard is torn.  Neither of those are useful to forming a
> decision.  Does anyone else have any *useful* feedback?

I think it is a matter of resource usage.

Up to now, the GPLv2 maintenance has not been so hard and thus I would
say for us to stay as is for now. We should revisit this for every
release and review if it is time for split it or not.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Khem Raj]

[-- Attachment #1.1: Type: text/plain, Size: 2641 bytes --]


> On Aug 11, 2015, at 1:36 PM, Burton, Ross <ross.burton@intel.com> wrote:
> 
> 
> On 11 August 2015 at 16:46, Khem Raj <raj.khem@gmail.com <mailto:raj.khem@gmail.com>> wrote:
> can we freeze this thread please.
> 
> Or more usefully, reboot it.  Philip, you're turning into Koen!  Alex, if someone on this list asks what Poky is, 99% of the time they're trolling.  :)

this ml it might be. But I interact with many folks who hear of it for first time and in general its quite confusing when you explain this to someone new. They get confused when they see yocto 1.8 and then poky 13.0, bitbake 1.26
and oe-core branched with codenames, poky distro layer is called meta-yocto and it also has BSPs in same repo, if you think from their POV its very confusing for some one new who is trying to get some understanding of this all. may be we can do without some of these now a days. but thats discussion for another day :)

> 
> The original and unanswered question was "should oe-core continue to maintain GPLv2 recipes where upstream has moved to GPLv3 or should those recipes move to a standalone layer" with various implied questions:
> 
> - If the v2 recipes move to a separate layer, who own/maintains/tests it?

motivated enough to use OE some folks might come up but it won’t be same, at this time I know it gets more users for OE may be less developers but then look at patches to these components has come from users turned developers. We should also look into the case why glibc folded the secondary class architectures which were maintained in ports repository into glibc proper.

> - Should there be v2 recipes for every recipe that has moved to v3, or only (as is now) the "more-core" recipes (currently YP tests that core-image-base builds without GPLv3, nothing else more complicated)
> - Should meta-gplv2 only contain recipes from oe-core, or all layers?  If other layers decide to hold both v3 and v2 recipes (not that I'm aware any have), what makes oe-core special?

These are pertinent questions that I have raised earlier on thread that can cause more confusion to end user, but i think if we keep the check for choosing GPLv2 only packages in OE-Core and move these recipes to something like meta-legacy or something like that and not associate it with license name then we don’t have to worry about above questions.

> 
> I'm torn, Richard is torn.  Neither of those are useful to forming a decision.  Does anyone else have any *useful* feedback?

however it can be left in there if its not causing a lot of maintenance burden since it still serves a purpose downstream.

> 
> Ross


[-- Attachment #1.2: Type: text/html, Size: 4537 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Mark Hatle]

On 8/11/15 3:36 PM, Burton, Ross wrote:
> 
> On 11 August 2015 at 16:46, Khem Raj <raj.khem@gmail.com
> <mailto:raj.khem@gmail.com>> wrote:
> 
>     can we freeze this thread please.
> 
> 
> Or more usefully, reboot it.  Philip, you're turning into Koen!  Alex, if
> someone on this list asks what Poky is, 99% of the time they're trolling.  :)
> 
> The original and unanswered question was "should oe-core continue to maintain
> GPLv2 recipes where upstream has moved to GPLv3 or should those recipes move to
> a standalone layer" with various implied questions:
> 
> - If the v2 recipes move to a separate layer, who own/maintains/tests it?
> - Should there be v2 recipes for every recipe that has moved to v3, or only (as
> is now) the "more-core" recipes (currently YP tests that core-image-base builds
> without GPLv3, nothing else more complicated)
> - Should meta-gplv2 only contain recipes from oe-core, or all layers?  If other
> layers decide to hold both v3 and v2 recipes (not that I'm aware any have), what
> makes oe-core special?
> 
> I'm torn, Richard is torn.  Neither of those are useful to forming a decision. 
> Does anyone else have any *useful* feedback?

Not sure how useful, but I can give what I remember as the history behind the
GPLv2 work and my opinion as someone who has a lot of customers who don't want
GPLv3 software on the target.

Originally when this work was proposed (keeping older GPLv2 software in oe-core)
the decision was made to keep a small core set of components.  Things that the
system wouldn't work without.  I.e. coreutils, util-linux, gettext, etc..  I
believe the bar was set just above core-image-minimal.

Anything more then a small (busybox or discrete component) filesystem can
require GPLv3 and at that point it's up to others to figure out how they want to
deal with it.

So based on the original theory here, parted (GPLv2) is right on the edge of
small system or not.  It wasn't originally included because were were not
considering (embedded) systems that would have to be partition at runtime.  (I
did much of the original scoping for GPLv2 components... so at least that is why
I left it off the list.)

(opinion part) That however doesn't mean we have to just reject this as being
out of scope, but I think it does push this more toward the "not part of
oe-core" side of things.

As someone who has a lot of customers that need non-GPLv2 components for various
reasons, I would like an ecosystem for components above and beyond what is
allowed into oe-core for contributed things like this older version of parted,
but not concern is bit-rot.  If it's in oe-core, it's (generally) being used and
tested and we get discussions like this... if it's shifted off into another
layer, that layer needs a maintainer or it's going to fall away.

So I honestly don't want to move any of the existing GPLv2 items out of oe-core
at this time.. possibly someday, but not now.  Additional (old) GPLv2 versions
really should be able to go somewhere and be shared, but I don't have a good
idea as to "where".  This is an opportunity for a new layer to focus on
non-oe-core GPLv2 or possibly a layer as part of meta-openembedded.  (I'm not
sure though Martin wants to take on that, even if it turns out to be minimal
additional work.)

(rant part)
In the end for people who can't use GPLv3 for whatever reason, there really
should be a coordinated effort to either update old versions of software (GPLv2)
or simply replace the items with BSD/MIT or other appropriately sourced and
licensed code.  I just don't see much coordination beyond oe-core (and the Yocto
Project) for this kind of work -- and the most I'm willing to sign up for is to
keep what we have functional for as long as my customers need it.

--Mark

> Ross
> 
> 

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Philip Balister]

On 08/11/2015 10:46 PM, Otavio Salvador wrote:
> On Tue, Aug 11, 2015 at 5:36 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>
>> On 11 August 2015 at 16:46, Khem Raj <raj.khem@gmail.com> wrote:
>>>
>>> can we freeze this thread please.
>>
>>
>> Or more usefully, reboot it.  Philip, you're turning into Koen!  Alex, if
>> someone on this list asks what Poky is, 99% of the time they're trolling.
>> :)
>>
>> The original and unanswered question was "should oe-core continue to
>> maintain GPLv2 recipes where upstream has moved to GPLv3 or should those
>> recipes move to a standalone layer" with various implied questions:
>>
>> - If the v2 recipes move to a separate layer, who own/maintains/tests it?
>> - Should there be v2 recipes for every recipe that has moved to v3, or only
>> (as is now) the "more-core" recipes (currently YP tests that core-image-base
>> builds without GPLv3, nothing else more complicated)
>> - Should meta-gplv2 only contain recipes from oe-core, or all layers?  If
>> other layers decide to hold both v3 and v2 recipes (not that I'm aware any
>> have), what makes oe-core special?
>>
>> I'm torn, Richard is torn.  Neither of those are useful to forming a
>> decision.  Does anyone else have any *useful* feedback?
> 
> I think it is a matter of resource usage.
> 
> Up to now, the GPLv2 maintenance has not been so hard and thus I would
> say for us to stay as is for now. We should revisit this for every
> release and review if it is time for split it or not.
> 

This would be a good time to remind us who the audience is for the gplv2
recipes so we understand the amount of manpower behind their maintenance.

My concern keeping then in core is that the commnunity who uses them
will reduce over time and they will bitrot. If that happens, we should
create a layer for them and remove them from core.

Philip

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Anders Darander]

* Mark Hatle <mark.hatle@windriver.com> [150812 16:50]:

> On 8/11/15 3:36 PM, Burton, Ross wrote:

> > Or more usefully, reboot it.  Philip, you're turning into Koen!  Alex, if
> > someone on this list asks what Poky is, 99% of the time they're trolling.  :)

> > The original and unanswered question was "should oe-core continue to maintain
> > GPLv2 recipes where upstream has moved to GPLv3 or should those recipes move to
> > a standalone layer" with various implied questions:

> > - If the v2 recipes move to a separate layer, who own/maintains/tests it?
> > - Should there be v2 recipes for every recipe that has moved to v3, or only (as
> > is now) the "more-core" recipes (currently YP tests that core-image-base builds
> > without GPLv3, nothing else more complicated)
> > - Should meta-gplv2 only contain recipes from oe-core, or all layers?  If other
> > layers decide to hold both v3 and v2 recipes (not that I'm aware any have), what
> > makes oe-core special?

> > I'm torn, Richard is torn.  Neither of those are useful to forming a decision. 
> > Does anyone else have any *useful* feedback?

> Not sure how useful, but I can give what I remember as the history behind the
> GPLv2 work and my opinion as someone who has a lot of customers who don't want
> GPLv3 software on the target.

I'm basically agreeing with Mark, as quite often, customers want a
non-GPLv3 image (and this is one of the strong selling points during
training sessions on OpenEmbedded / Yocto Project, that we have the
INCOMPATIBLE_LICENSE option). And having that option, and testing it,
requires that we have at least enough for a core-image-minimal to be
built and deployed.

I'm also using non-GPLv3 builds internally, for the same reasons...

From reading earlier discussions, when recipe updates are proposed,
which replaces GPLv2-versions with GPLv3-versions, there usually are a
few people complaining (if they notice the change).

> Originally when this work was proposed (keeping older GPLv2 software in oe-core)
> the decision was made to keep a small core set of components.  Things that the
> system wouldn't work without.  I.e. coreutils, util-linux, gettext, etc..  I
> believe the bar was set just above core-image-minimal.

> Anything more then a small (busybox or discrete component) filesystem can
> require GPLv3 and at that point it's up to others to figure out how they want to
> deal with it.

> So based on the original theory here, parted (GPLv2) is right on the edge of
> small system or not.  It wasn't originally included because were were not
> considering (embedded) systems that would have to be partition at runtime.  (I
> did much of the original scoping for GPLv2 components... so at least that is why
> I left it off the list.)

> (opinion part) That however doesn't mean we have to just reject this as being
> out of scope, but I think it does push this more toward the "not part of
> oe-core" side of things.

Sure, we need to revise that "core" part, and which of the components
are required in order to really state that we can support non-GPLv3
builds. Both as SW migrates from GPLv2 -> GPLv3, but also as HW and
system changes, as that might make new applications "really core".

> As someone who has a lot of customers that need non-GPLv2 components for various
> reasons, I would like an ecosystem for components above and beyond what is
> allowed into oe-core for contributed things like this older version of parted,
> but not concern is bit-rot.  If it's in oe-core, it's (generally) being used and
> tested and we get discussions like this... if it's shifted off into another
> layer, that layer needs a maintainer or it's going to fall away.

Yep, it's that part, the testing of non-GPLv3 builds that's so
attrictive to a lot of potential new-comers.

> So I honestly don't want to move any of the existing GPLv2 items out of oe-core
> at this time.. possibly someday, but not now.  

I have to agree with Mark here; the GPLv2 components in oe-core should
really stay in core at this time. (And for quite some time)

> Additional (old) GPLv2 versions
> really should be able to go somewhere and be shared, but I don't have a good
> idea as to "where".  This is an opportunity for a new layer to focus on
> non-oe-core GPLv2 or possibly a layer as part of meta-openembedded.  (I'm not
> sure though Martin wants to take on that, even if it turns out to be minimal
> additional work.)

Sure, a meta-legacy or meta-gplv2 layer for the rest of non-core
applications and libraries would likely be a good idea. The main
question is as always, can we get enough to help maintain that stuff.

> (rant part)
> In the end for people who can't use GPLv3 for whatever reason, there really
> should be a coordinated effort to either update old versions of software (GPLv2)
> or simply replace the items with BSD/MIT or other appropriately sourced and
> licensed code.  I just don't see much coordination beyond oe-core (and the Yocto
> Project) for this kind of work -- and the most I'm willing to sign up for is to
> keep what we have functional for as long as my customers need it.

Cheers,
Anders

-- 
Anders Darander
ChargeStorm AB / eStorm AB

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Mark Hatle]

On 8/13/15 3:42 AM, Philip Balister wrote:
> On 08/11/2015 10:46 PM, Otavio Salvador wrote:
>> On Tue, Aug 11, 2015 at 5:36 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>>
>>> On 11 August 2015 at 16:46, Khem Raj <raj.khem@gmail.com> wrote:
>>>>
>>>> can we freeze this thread please.
>>>
>>>
>>> Or more usefully, reboot it.  Philip, you're turning into Koen!  Alex, if
>>> someone on this list asks what Poky is, 99% of the time they're trolling.
>>> :)
>>>
>>> The original and unanswered question was "should oe-core continue to
>>> maintain GPLv2 recipes where upstream has moved to GPLv3 or should those
>>> recipes move to a standalone layer" with various implied questions:
>>>
>>> - If the v2 recipes move to a separate layer, who own/maintains/tests it?
>>> - Should there be v2 recipes for every recipe that has moved to v3, or only
>>> (as is now) the "more-core" recipes (currently YP tests that core-image-base
>>> builds without GPLv3, nothing else more complicated)
>>> - Should meta-gplv2 only contain recipes from oe-core, or all layers?  If
>>> other layers decide to hold both v3 and v2 recipes (not that I'm aware any
>>> have), what makes oe-core special?
>>>
>>> I'm torn, Richard is torn.  Neither of those are useful to forming a
>>> decision.  Does anyone else have any *useful* feedback?
>>
>> I think it is a matter of resource usage.
>>
>> Up to now, the GPLv2 maintenance has not been so hard and thus I would
>> say for us to stay as is for now. We should revisit this for every
>> release and review if it is time for split it or not.
>>
> 
> This would be a good time to remind us who the audience is for the gplv2
> recipes so we understand the amount of manpower behind their maintenance.

I can only speak for the customers I know of directly.  They are:

* People whose lawyers tell them they can't use GPLv3, for no other reason that
FUD.  (This is diminishing.)

The follow are all around the 'TiVo-ization clause' concerns...

* People in the medical space
  - Some devices if modified have serious safety concerns.  So they want to be
able to lock down the device and must due so to get things like FDA certification.

* People in the automotive space (IVI, etc)
  - In some countries if a user modifies the device, due to the automaker
permitting modifications, the automake suddenly becomes liable for the users
changes.  This is a pretty nasty catch in their laws.  So the automakes want the
ability again to lock down the device to prevent liability issues, as well as
for potential safety concerns.

* Aeronautics
  - I've only talked to a few people on this, so I don't know if it is accurate
or not.. but again the issue is for FAA certification and similar they can't
permit changes to various flight systems.  If they permit a user to modify the
device it may fail FAA certification.

* Consumer Electronics
  - Some devices may be built in such a way that the designer does not want to
permit the user from modifying the device.  This is generally around things like
DRM, or devices that have physical components (like tape control) that can be
damaged due to improper control.

  - DRM if implemented in software can be a concern simply due to contractural
issues..

  - Physical device issues are all about warranty concerns.  (Personally I think
it's a red herring, but I've heard the concern on a number of devices from a few
large manufacturers.)

> My concern keeping then in core is that the commnunity who uses them
> will reduce over time and they will bitrot. If that happens, we should
> create a layer for them and remove them from core.

I think GPLv2 is a limited set of the community, but I also think that it's an
important set.  It removes some of the traditional embedded Linux concerns from
various markets.  As for bitrot, for the existing components, I don't see this
as a concern for the next few years at least.  There is still a health
(commercial) community using these components regularly, and worst case fixes
are being developed and sent back to the community via OSVs and integrators.

--Mark

> Philip
> 

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Andre McCurdy]

On Thu, Aug 13, 2015 at 1:42 AM, Philip Balister <philip@balister.org> wrote:
> On 08/11/2015 10:46 PM, Otavio Salvador wrote:
>> On Tue, Aug 11, 2015 at 5:36 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>>
>>> On 11 August 2015 at 16:46, Khem Raj <raj.khem@gmail.com> wrote:
>>>>
>>>> can we freeze this thread please.
>>>
>>>
>>> Or more usefully, reboot it.  Philip, you're turning into Koen!  Alex, if
>>> someone on this list asks what Poky is, 99% of the time they're trolling.
>>> :)
>>>
>>> The original and unanswered question was "should oe-core continue to
>>> maintain GPLv2 recipes where upstream has moved to GPLv3 or should those
>>> recipes move to a standalone layer" with various implied questions:
>>>
>>> - If the v2 recipes move to a separate layer, who own/maintains/tests it?
>>> - Should there be v2 recipes for every recipe that has moved to v3, or only
>>> (as is now) the "more-core" recipes (currently YP tests that core-image-base
>>> builds without GPLv3, nothing else more complicated)
>>> - Should meta-gplv2 only contain recipes from oe-core, or all layers?  If
>>> other layers decide to hold both v3 and v2 recipes (not that I'm aware any
>>> have), what makes oe-core special?
>>>
>>> I'm torn, Richard is torn.  Neither of those are useful to forming a
>>> decision.  Does anyone else have any *useful* feedback?
>>
>> I think it is a matter of resource usage.
>>
>> Up to now, the GPLv2 maintenance has not been so hard and thus I would
>> say for us to stay as is for now. We should revisit this for every
>> release and review if it is time for split it or not.
>>
>
> This would be a good time to remind us who the audience is for the gplv2
> recipes so we understand the amount of manpower behind their maintenance.
>
> My concern keeping then in core is that the commnunity who uses them
> will reduce over time and they will bitrot. If that happens, we should
> create a layer for them and remove them from core.

As others have also mentioned, there are certain classes of product
(set-top boxes, automotive, medical, etc, etc) where secure boot and
signed firmware images are a non-negotiable requirement. I don't see
these classes of product going away any time soon, so it's hard to see
the overall need for "GPLv3-free" embedded distros reducing.

Some forward-thinking companies making these types of products are
already switching to OE [1], but I guess the majority are still using
legacy build environments and home-grown distros. Since these
home-grown distros typically take a "conservative" approach to
updating packages, the pain of sticking with older, pre-GPLv3 versions
might not be felt very strongly yet. It will inevitably increase over
time though and as it does there's going to be a growing number of
developers working to maintain pre-GPLv3 versions (or working to
switch to replacement packages with more permissive licenses).

 [1] http://www.slideshare.net/linaroorg/hkg15506-comcast-lessons-learned-from-migrating-the-rdk-code-base-to-the-openembeddedyocto-build-framework


> Philip
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1745 bytes --]

On Fri, Aug 07, 2015 at 03:26:45PM +0300, Alexander Kanavin wrote:
> On 08/07/2015 12:17 PM, Philip Balister wrote:
> 
> > Thanks Khem. I also do not agree that we lack a self-sustaining
> > community. OpenEmbedded has functioned independently for far longer than
> > the Yocto Project has existed.
> 
> By 'self-sustaining' I mean 'being able to continuously produce quality 
> work'. Looking at layers in meta-openembedded, not all of them are of 
> high quality. Meta-gnome in particular is badly out of date, because no 
> one wants to maintain it properly. If oe-core starts taking a lot more 
> volunteer contributions, and the same thing happens (a volunteer 
> contributes a large set of recipes, then disappears), what is supposed 
> to happen then?

Having latest version of all recipes is good thing, but it's not the
best quality indicator.

In meta-oe and oe-classic package upgrades were usually done by people
who were actively using those recipes and only when the new version
introduced something they really needed or wanted. Still it was causing
new issues, because nobody can test every combination how something can
be used.

Now we see a lot of upgrades in oe-core which are done by people just
because "package upgrade report" says it's possible and the upgrade is
tested mostly by autobuilder (which doesn't exersize any "extra" layers
and runtime-test coverage is very low) - so in the end many of these
"good to have" upgrades are breaking some other components which aren't
upgraded so often or breaking/changing runtime behavior and only couple
months later someone who is actually using them will report that.

Regards,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2348 bytes --]

On Thu, Aug 13, 2015 at 10:42:54AM +0200, Philip Balister wrote:
> On 08/11/2015 10:46 PM, Otavio Salvador wrote:
> > On Tue, Aug 11, 2015 at 5:36 PM, Burton, Ross <ross.burton@intel.com> wrote:
> >>
> >> On 11 August 2015 at 16:46, Khem Raj <raj.khem@gmail.com> wrote:
> >>>
> >>> can we freeze this thread please.
> >>
> >>
> >> Or more usefully, reboot it.  Philip, you're turning into Koen!  Alex, if
> >> someone on this list asks what Poky is, 99% of the time they're trolling.
> >> :)
> >>
> >> The original and unanswered question was "should oe-core continue to
> >> maintain GPLv2 recipes where upstream has moved to GPLv3 or should those
> >> recipes move to a standalone layer" with various implied questions:
> >>
> >> - If the v2 recipes move to a separate layer, who own/maintains/tests it?
> >> - Should there be v2 recipes for every recipe that has moved to v3, or only
> >> (as is now) the "more-core" recipes (currently YP tests that core-image-base
> >> builds without GPLv3, nothing else more complicated)
> >> - Should meta-gplv2 only contain recipes from oe-core, or all layers?  If
> >> other layers decide to hold both v3 and v2 recipes (not that I'm aware any
> >> have), what makes oe-core special?
> >>
> >> I'm torn, Richard is torn.  Neither of those are useful to forming a
> >> decision.  Does anyone else have any *useful* feedback?
> > 
> > I think it is a matter of resource usage.
> > 
> > Up to now, the GPLv2 maintenance has not been so hard and thus I would
> > say for us to stay as is for now. We should revisit this for every
> > release and review if it is time for split it or not.
> > 
> 
> This would be a good time to remind us who the audience is for the gplv2
> recipes so we understand the amount of manpower behind their maintenance.
> 
> My concern keeping then in core is that the commnunity who uses them
> will reduce over time and they will bitrot. If that happens, we should
> create a layer for them and remove them from core.

It's still better to let them bitrot collectively in central layer than
every OE user with this requirement maintaining old GPLv2 recipes in own
layers and re-inventing the workarounds needed to build the rest of the
system with latest upstream layers.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Richard Purdie]

On Tue, 2015-08-18 at 11:03 +0200, Martin Jansa wrote:
> On Thu, Aug 13, 2015 at 10:42:54AM +0200, Philip Balister wrote:
> > On 08/11/2015 10:46 PM, Otavio Salvador wrote:
> > > On Tue, Aug 11, 2015 at 5:36 PM, Burton, Ross <ross.burton@intel.com> wrote:
> > >>
> > >> On 11 August 2015 at 16:46, Khem Raj <raj.khem@gmail.com> wrote:
> > >>>
> > >>> can we freeze this thread please.
> > >>
> > >>
> > >> Or more usefully, reboot it.  Philip, you're turning into Koen!  Alex, if
> > >> someone on this list asks what Poky is, 99% of the time they're trolling.
> > >> :)
> > >>
> > >> The original and unanswered question was "should oe-core continue to
> > >> maintain GPLv2 recipes where upstream has moved to GPLv3 or should those
> > >> recipes move to a standalone layer" with various implied questions:
> > >>
> > >> - If the v2 recipes move to a separate layer, who own/maintains/tests it?
> > >> - Should there be v2 recipes for every recipe that has moved to v3, or only
> > >> (as is now) the "more-core" recipes (currently YP tests that core-image-base
> > >> builds without GPLv3, nothing else more complicated)
> > >> - Should meta-gplv2 only contain recipes from oe-core, or all layers?  If
> > >> other layers decide to hold both v3 and v2 recipes (not that I'm aware any
> > >> have), what makes oe-core special?
> > >>
> > >> I'm torn, Richard is torn.  Neither of those are useful to forming a
> > >> decision.  Does anyone else have any *useful* feedback?
> > > 
> > > I think it is a matter of resource usage.
> > > 
> > > Up to now, the GPLv2 maintenance has not been so hard and thus I would
> > > say for us to stay as is for now. We should revisit this for every
> > > release and review if it is time for split it or not.
> > > 
> > 
> > This would be a good time to remind us who the audience is for the gplv2
> > recipes so we understand the amount of manpower behind their maintenance.
> > 
> > My concern keeping then in core is that the commnunity who uses them
> > will reduce over time and they will bitrot. If that happens, we should
> > create a layer for them and remove them from core.
> 
> It's still better to let them bitrot collectively in central layer than
> every OE user with this requirement maintaining old GPLv2 recipes in own
> layers and re-inventing the workarounds needed to build the rest of the
> system with latest upstream layers.

I don't think anyone is suggesting we just abandon the idea and force
everyone to do this individually. The question is more about whether it
still makes sense to have the GPLv2 recipes in OE-Core or a separate
layer. It does also raise questions of scope, there are GPLv2 recipes
which OE-Core doesn't have and are not part of its stated policy (e.g.
screen being the current example).

I do think its right to ask these questions although I'm still undecided
about what the best solution is...

Cheers,

Richard

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Alexander Kanavin]

On 08/18/2015 10:54 AM, Martin Jansa wrote:

> Now we see a lot of upgrades in oe-core which are done by people just
> because "package upgrade report" says it's possible and the upgrade is
> tested mostly by autobuilder (which doesn't exersize any "extra" layers
> and runtime-test coverage is very low) - so in the end many of these
> "good to have" upgrades are breaking some other components which aren't
> upgraded so often or breaking/changing runtime behavior and only couple
> months later someone who is actually using them will report that.

The alternative isn't great either. Older, out-of-date software tends to 
require more effort to backport security fixes and prevent bitrot (maybe 
as much effort as would be spent simply updating it to latest versions). 
Or if no one does the backporting then you have an insecure software stack.

Then, when gigantic, must-have updates happen, they take forever to 
prepare, review, (rebase, update, review)* and merge, they're met with 
more resistance, and cause even more breakage and pain in the other 
layers than if the same thing would have been achieved via small, 
incremental updates.

Test automation is being worked on, so when that is in place, then 
rolling, small updates approach will be clearly superior.

Regards,
Alex

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3982 bytes --]

On Tue, Aug 18, 2015 at 11:11:11AM +0100, Richard Purdie wrote:
> On Tue, 2015-08-18 at 11:03 +0200, Martin Jansa wrote:
> > On Thu, Aug 13, 2015 at 10:42:54AM +0200, Philip Balister wrote:
> > > On 08/11/2015 10:46 PM, Otavio Salvador wrote:
> > > > On Tue, Aug 11, 2015 at 5:36 PM, Burton, Ross <ross.burton@intel.com> wrote:
> > > >>
> > > >> On 11 August 2015 at 16:46, Khem Raj <raj.khem@gmail.com> wrote:
> > > >>>
> > > >>> can we freeze this thread please.
> > > >>
> > > >>
> > > >> Or more usefully, reboot it.  Philip, you're turning into Koen!  Alex, if
> > > >> someone on this list asks what Poky is, 99% of the time they're trolling.
> > > >> :)
> > > >>
> > > >> The original and unanswered question was "should oe-core continue to
> > > >> maintain GPLv2 recipes where upstream has moved to GPLv3 or should those
> > > >> recipes move to a standalone layer" with various implied questions:
> > > >>
> > > >> - If the v2 recipes move to a separate layer, who own/maintains/tests it?
> > > >> - Should there be v2 recipes for every recipe that has moved to v3, or only
> > > >> (as is now) the "more-core" recipes (currently YP tests that core-image-base
> > > >> builds without GPLv3, nothing else more complicated)
> > > >> - Should meta-gplv2 only contain recipes from oe-core, or all layers?  If
> > > >> other layers decide to hold both v3 and v2 recipes (not that I'm aware any
> > > >> have), what makes oe-core special?
> > > >>
> > > >> I'm torn, Richard is torn.  Neither of those are useful to forming a
> > > >> decision.  Does anyone else have any *useful* feedback?
> > > > 
> > > > I think it is a matter of resource usage.
> > > > 
> > > > Up to now, the GPLv2 maintenance has not been so hard and thus I would
> > > > say for us to stay as is for now. We should revisit this for every
> > > > release and review if it is time for split it or not.
> > > > 
> > > 
> > > This would be a good time to remind us who the audience is for the gplv2
> > > recipes so we understand the amount of manpower behind their maintenance.
> > > 
> > > My concern keeping then in core is that the commnunity who uses them
> > > will reduce over time and they will bitrot. If that happens, we should
> > > create a layer for them and remove them from core.
> > 
> > It's still better to let them bitrot collectively in central layer than
> > every OE user with this requirement maintaining old GPLv2 recipes in own
> > layers and re-inventing the workarounds needed to build the rest of the
> > system with latest upstream layers.
> 
> I don't think anyone is suggesting we just abandon the idea and force
> everyone to do this individually. The question is more about whether it
> still makes sense to have the GPLv2 recipes in OE-Core or a separate
> layer. It does also raise questions of scope, there are GPLv2 recipes
> which OE-Core doesn't have and are not part of its stated policy (e.g.
> screen being the current example).
> 
> I do think its right to ask these questions although I'm still undecided
> about what the best solution is...

Is it still true that autobuilder cannot test different sets of layers
for different builds?

It would be nice to see meta-gplv2 as separate layer, but tested and
maintained as it is now inside oe-core (possibly with more help from
outside especially if we can move some other recipes there as well).
That way autobuilder can test meta-gplv2 layer only in non-GPLv3 builds
and people who don't mind having GPLv3 components don't need to see
"bit-rotten old versions" in proper oe-core.

I was suggesting the same for sato in OEDAM (core-image built without
meta-sato in one autobuilder job, then sato-image with meta-sato
included in separate job), but IIRC there were some autobuilder
limitations which prevented to use metadata layers like this (which
seems very sad).

Regards,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Richard Purdie]

On Tue, 2015-08-18 at 13:16 +0200, Martin Jansa wrote:
> Is it still true that autobuilder cannot test different sets of layers
> for different builds?
>
> It would be nice to see meta-gplv2 as separate layer, but tested and
> maintained as it is now inside oe-core (possibly with more help from
> outside especially if we can move some other recipes there as well).
> That way autobuilder can test meta-gplv2 layer only in non-GPLv3 builds
> and people who don't mind having GPLv3 components don't need to see
> "bit-rotten old versions" in proper oe-core.
> 
> I was suggesting the same for sato in OEDAM (core-image built without
> meta-sato in one autobuilder job, then sato-image with meta-sato
> included in separate job), but IIRC there were some autobuilder
> limitations which prevented to use metadata layers like this (which
> seems very sad).

I think things are improving in this area, it can handle simple layer
changes. That said, I'm nervous about touching the autobuilder config
too much as even simpler changes to the autobuilder configuration tend
to have issues which cause massive headaches trying to keep patches
moving. I don't think the shear amount of pain we're suffering at the
moment is particularly visible to people :/. 

Separating out sato from the core, particularly within the tests is
likely to be quite some work. Its certainly doable, the question is
whether its a priority with the resources available and to put it
simply, there isn't the bandwidth/resources.

It would also likely mean we end up building twice the quantity of
builds with and without sato which we simply don't have the autobuilder
resources for (or we accept testing cycles double).

Cheers,

Richard