[meta-mono] [PATCH 0/1] gtk-sharp: Updated to 2.12.21

[meta-mono] [PATCH 0/1] gtk-sharp: Updated to 2.12.21

[Alex J Lennon]

See following patch for details

The following changes since commit 7cd40847c65978c42a68f02cd1483c6a2254ff06:

  mono: Update Mono to 3.2.8 (2014-02-26 13:56:42 +0000)

are available in the git repository at:

  git://git.yoctoproject.org/meta-mono ajl/gtk-sharp
  http://git.yoctoproject.org/cgit.cgi/meta-mono/log/?h=ajl/gtk-sharp

Alex J Lennon (1):
  gtk-sharp: Updated to GTK# 2.12.21

 .../fix-ambiguous-actions-glib-includes.patch      |   99 -------------------
 recipes-mono/gtk-sharp/gtk-sharp.inc               |   36 ++++++-
 recipes-mono/gtk-sharp/gtk-sharp_2.10.2.bb         |  101 --------------------
 recipes-mono/gtk-sharp/gtk-sharp_2.12.21.bb        |   13 +++
 4 files changed, 46 insertions(+), 203 deletions(-)
 delete mode 100644 recipes-mono/gtk-sharp/files/fix-ambiguous-actions-glib-includes.patch
 delete mode 100644 recipes-mono/gtk-sharp/gtk-sharp_2.10.2.bb
 create mode 100644 recipes-mono/gtk-sharp/gtk-sharp_2.12.21.bb

-- 
1.7.9.5

[meta-mono] [PATCH 1/1] gtk-sharp: Updated to GTK# 2.12.21

[Alex J Lennon]

Synopsis:

- Previous recipe 2.10.2 was failing to build
- Updated to current GTK# release 2.12.21
- Cleaned up recipe

Testing:

- This change has been tested on a qemux86 image with the Mono GTK# 'hello world' example

@see: http://www.mono-project.com/GtkSharp:_Hello_World

Signed-off-by: Alex J Lennon <ajlennon@dynamicdevices.co.uk>
---
 .../fix-ambiguous-actions-glib-includes.patch      |   99 -------------------
 recipes-mono/gtk-sharp/gtk-sharp.inc               |   36 ++++++-
 recipes-mono/gtk-sharp/gtk-sharp_2.10.2.bb         |  101 --------------------
 recipes-mono/gtk-sharp/gtk-sharp_2.12.21.bb        |   13 +++
 4 files changed, 46 insertions(+), 203 deletions(-)
 delete mode 100644 recipes-mono/gtk-sharp/files/fix-ambiguous-actions-glib-includes.patch
 delete mode 100644 recipes-mono/gtk-sharp/gtk-sharp_2.10.2.bb
 create mode 100644 recipes-mono/gtk-sharp/gtk-sharp_2.12.21.bb

diff --git a/recipes-mono/gtk-sharp/files/fix-ambiguous-actions-glib-includes.patch b/recipes-mono/gtk-sharp/files/fix-ambiguous-actions-glib-includes.patch
deleted file mode 100644
index 0a4ea26..0000000
--- a/recipes-mono/gtk-sharp/files/fix-ambiguous-actions-glib-includes.patch
+++ /dev/null
@@ -1,99 +0,0 @@
-diff -ru gtk-sharp-2.10.2.org/glib/glue/list.c gtk-sharp-2.10.2/glib/glue/list.c
---- gtk-sharp-2.10.2.org/glib/glue/list.c	2012-12-25 10:59:05.203146111 +0000
-+++ gtk-sharp-2.10.2/glib/glue/list.c	2012-12-25 11:00:50.383148628 +0000
-@@ -20,7 +20,7 @@
-  */
- 
- 
--#include <glib/glist.h>
-+#include <glib.h>
- 
- /* Forward declarations */
- gpointer gtksharp_list_get_data (GList *l);
-diff -ru gtk-sharp-2.10.2.org/glib/glue/slist.c gtk-sharp-2.10.2/glib/glue/slist.c
---- gtk-sharp-2.10.2.org/glib/glue/slist.c	2012-12-25 10:59:05.127146109 +0000
-+++ gtk-sharp-2.10.2/glib/glue/slist.c	2012-12-25 11:01:04.155148277 +0000
-@@ -20,7 +20,7 @@
-  */
- 
- 
--#include <glib/gslist.h>
-+#include <glib.h>
- 
- /* Forward declarations */
- gpointer gtksharp_slist_get_data (GSList *l);
-diff -ru gtk-sharp-2.10.2.org/glib/glue/thread.c gtk-sharp-2.10.2/glib/glue/thread.c
---- gtk-sharp-2.10.2.org/glib/glue/thread.c	2012-12-25 10:59:05.147146108 +0000
-+++ gtk-sharp-2.10.2/glib/glue/thread.c	2012-12-25 11:01:23.279148643 +0000
-@@ -20,7 +20,7 @@
-  */
- 
- 
--#include <glib/gthread.h>
-+#include <glib.h>
- 
- gboolean
- glibsharp_g_thread_supported ()
-diff -ru gtk-sharp-2.10.2.org/sample/Actions.cs gtk-sharp-2.10.2/sample/Actions.cs
---- gtk-sharp-2.10.2.org/sample/Actions.cs	2012-12-25 10:59:14.603146276 +0000
-+++ gtk-sharp-2.10.2/sample/Actions.cs	2012-12-26 08:46:36.032548890 +0000
-@@ -189,7 +189,7 @@
- 
- 		static void OnActivate (object obj, EventArgs args)
- 		{
--			Action action = (Action)obj;
-+			Gtk.Action action = (Gtk.Action)obj;
- 			Console.WriteLine ("Action {0} (type={1}) activated",
- 					   action.Name, action.GetType ().FullName);
- 		}
-@@ -218,7 +218,7 @@
- 
- 		static void OnToggleCnp (object obj, EventArgs args)
- 		{
--			Action action = (ToggleAction)obj;
-+			Gtk.Action action = (ToggleAction)obj;
- 			bool sensitive = ((ToggleAction)action).Active;
- 			action = group.GetAction ("cut");
- 			action.Sensitive = sensitive;
-@@ -262,7 +262,7 @@
- 			for (int i = 0; i < num; i++) {
- 				string name = "DynAction" + i;
- 				string label = "Dynamic Action " + i;
--				Action action = new Action (name, label);
-+				Gtk.Action action = new Gtk.Action (name, label);
- 				dynGroup.Add (action);
- 				uim.AddUi (mergeId, "/menubar/DynamicMenu", name,
- 					   name, UIManagerItemType.Menuitem, false);
-@@ -299,7 +299,7 @@
- 
- 		static void OnSelect (object obj, EventArgs args)
- 		{
--			Action action = (Action) actions[obj];
-+			Gtk.Action action = (Gtk.Action) actions[obj];
- 			if (action.Tooltip != null)
- 				statusbar.Push (0, action.Tooltip);
- 		}
-diff -ru gtk-sharp-2.10.2.org/sample/GtkDemo/DemoApplicationWindow.cs gtk-sharp-2.10.2/sample/GtkDemo/DemoApplicationWindow.cs
---- gtk-sharp-2.10.2.org/sample/GtkDemo/DemoApplicationWindow.cs	2012-12-25 10:59:14.375146291 +0000
-+++ gtk-sharp-2.10.2/sample/GtkDemo/DemoApplicationWindow.cs	2012-12-26 08:42:42.732544622 +0000
-@@ -156,7 +156,7 @@
- 
- 		private void ActionActivated (object sender, EventArgs a)
- 		{
--			Action action = sender as Action;
-+			Gtk.Action action = sender as Gtk.Action;
- 			MessageDialog md;
- 
- 			md = new MessageDialog (this, DialogFlags.DestroyWithParent,
-diff -ru gtk-sharp-2.10.2.org/sample/GtkDemo/DemoUIManager.cs gtk-sharp-2.10.2/sample/GtkDemo/DemoUIManager.cs
---- gtk-sharp-2.10.2.org/sample/GtkDemo/DemoUIManager.cs	2012-12-25 10:59:14.355146264 +0000
-+++ gtk-sharp-2.10.2/sample/GtkDemo/DemoUIManager.cs	2012-12-26 08:43:33.388545656 +0000
-@@ -132,7 +132,7 @@
- 
- 		private void ActionActivated (object sender, EventArgs a)
- 		{
--			Action action = sender as Action;
-+			Gtk.Action action = sender as Gtk.Action;
- 			Console.WriteLine ("Action \"{0}\" activated", action.Name);
- 		}
- 
diff --git a/recipes-mono/gtk-sharp/gtk-sharp.inc b/recipes-mono/gtk-sharp/gtk-sharp.inc
index d279bb8..04e25ab 100644
--- a/recipes-mono/gtk-sharp/gtk-sharp.inc
+++ b/recipes-mono/gtk-sharp/gtk-sharp.inc
@@ -1,12 +1,42 @@
-DESCRIPTION = "GTK bindings for mono"
+SUMMARY = "GUI toolkit for Mono"
+DESCRIPTION = "GTK+ bindings for Mono"
 SECTION = "devel/mono"
-
+BUGTRACKER = "http://bugzilla.xamarin.com"
 DEPENDS = "mono mono-native gtk+ atk pango cairo glib-2.0 libglade "
 RDEPENDS_${PN} = "mono"
+LICENSE = "LGPL-2.1"
 
 inherit autotools
 
 # For some reason the URL template changes from version to version,
 # therefore use some variables for the directory and extension
-SRC_URI = "http://go-mono.com/sources/gtk-sharp${SDIRVER}/gtk-sharp-${PV}.tar.${SEXT}"
+SRC_URI = "http://download.mono-project.com/sources/gtk-sharp${SDIRVER}/gtk-sharp-${PV}.tar.${SEXT}"
+
+SDIRVER = "${@gtk_sharp_download_version(d)}"
+SEXT ??= "bz2"
+
+def gtk_sharp_download_version(d):
+    pvsplit = d.getVar('PV', True).split('.')
+    return pvsplit[0] + '' + pvsplit[1]
+
+FILESPATH =. "${FILE_DIRNAME}/gtk-sharp-${PV}:"
+
+FILES_${PN} = "\
+  ${bindir}/* \
+  ${libdir}/* \
+"
+
+FILES_${PN}-dbg = "\
+    ${libdir}/.debug \
+    ${datadir}/* \
+    /usr/src/* \
+"
+
+FILES_${PN}-doc = "\
+    ${libdir}/monodoc/* \
+"
+
+FILES_${PN}-dev = "\
+    ${libdir}/pkgconfig \
+"
 
diff --git a/recipes-mono/gtk-sharp/gtk-sharp_2.10.2.bb b/recipes-mono/gtk-sharp/gtk-sharp_2.10.2.bb
deleted file mode 100644
index 8891809..0000000
--- a/recipes-mono/gtk-sharp/gtk-sharp_2.10.2.bb
+++ /dev/null
@@ -1,101 +0,0 @@
-PV = "2.10.2"
-PR = "r1"
-SDIRVER = "210"
-SEXT = "bz2"
-
-LICENSE = "LGPL-2.1"
-LIC_FILES_CHKSUM = "files://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34"
-
-inherit pkgconfig
-require gtk-sharp.inc
-
-FILESEXTRAPATHS := "${THISDIR}/files"
-SRC_URI += " file://fix-ambiguous-actions-glib-includes.patch"
-
-FILES_libgtk2.0-cil = "/usr/lib/libgtksharpglue-2.so \
-/usr/lib/libgdksharpglue-2.so \
-/usr/lib/libpangosharpglue-2.so \
-/usr/lib/mono/gac/gtk-sharp \
-/usr/lib/mono/gac/gdk-sharp \
-/usr/lib/mono/gac/atk-sharp \
-/usr/lib/mono/gac/pango-sharp \
-/usr/lib/mono/gac/gtk-dotnet \
-/usr/lib/mono/gtk-sharp-2.0/gtk-sharp.dll \
-/usr/lib/mono/gtk-sharp-2.0/gdk-sharp.dll \
-/usr/lib/mono/gtk-sharp-2.0/atk-sharp.dll \
-/usr/lib/mono/gtk-sharp-2.0/pango-sharp.dll \
-/usr/lib/mono/gtk-sharp-2.0/gtk-dotnet.dll \
-/usr/lib/mono/gac/policy.2.*.gtk-sharp/ \
-/usr/lib/mono/gac/policy.2.*.gdk-sharp/ \
-/usr/lib/mono/gac/policy.2.*.atk-sharp/ \
-/usr/lib/mono/gac/policy.2.*.pango-sharp/ \
-/usr/lib/mono/gac/policy.2.*.gtk-dotnet/ \
-        /usr/lib/mono/gtk-sharp-2.0/policy.2.*.gtk-sharp.dll \
-        /usr/lib/mono/gtk-sharp-2.0/policy.2.*.gdk-sharp.dll \
-        /usr/lib/mono/gtk-sharp-2.0/policy.2.*.atk-sharp.dll \
-        /usr/lib/mono/gtk-sharp-2.0/policy.2.*.pango-sharp.dll \
-        /usr/lib/mono/gtk-sharp-2.0/policy.2.*.gtk-dotnet.dll \
-"
-FILES_libgtk2.0-cil-dev = "/usr/lib/pkgconfig/gtk-sharp-2.0.pc \
-/usr/lib/pkgconfig/gtk-dotnet-2.0.pc \
-/usr/share/gapi-2.0/pango-api.xml \
-/usr/share/gapi-2.0/atk-api.xml \
-        /usr/share/gapi-2.0/gdk-api.xml \
-        /usr/share/gapi-2.0/gtk-api.xml"
-FILES_libgtk2.0-cil-dbg += "/usr/lib/.debug/libgtksharpglue-2.so \
-/usr/lib/.debug/libgdksharpglue-2.so \
-/usr/lib/.debug/libpangosharpglue-2.so"
-
-FILES_libglib2.0-cil = "/usr/lib/mono/gac/glib-sharp \
-/usr/lib/libglibsharpglue-2.so \
-/usr/lib/mono/gtk-sharp-2.0/glib-sharp.dll \
-/usr/lib/mono/gac/policy.2.*.glib-sharp/ \
-/usr/lib/mono/gtk-sharp-2.0/policy.2.*.glib-sharp.dll"
-FILES_libglib2.0-cil-dev = "/usr/lib/pkgconfig/glib-sharp-2.0.pc"
-FILES_libglib2.0-cil-dbg += "/usr/lib/.debug/libglibsharpglue-2.so"
-
-FILES_libglade2.0-cil = "/usr/lib/mono/gac/glade-sharp \
-/usr/lib/libgladesharpglue-2.so \
-/usr/lib/mono/gtk-sharp-2.0/glade-sharp.dll \
-/usr/lib/mono/gac/policy.2.*.glade-sharp/ \
-/usr/lib/mono/gtk-sharp-2.0/policy.2.*.glade-sharp.dll"
-FILES_libglade2.0-cil-dev = "/usr/lib/pkgconfig/glade-sharp-2.0.pc \
-/usr/share/gapi-2.0/glade-api.xml"
-FILES_libglade2.0-cil-dbg += "/usr/lib/.debug/libgladesharpglue-2.so"
-
-FILES_gtk-sharp-gapi2 = " \
-/usr/bin/gapi2-* \
-/usr/lib/gtk-sharp-2.0/gapi*"
-FILES_gtk-sharp-gapi2-dev = "/usr/lib/pkgconfig/gapi-2.0.pc"
-
-FILES_gtk-sharp2-glue-staticdev = "/usr/lib/libgtksharpglue-2.la \
-/usr/lib/libgtksharpglue-2.a \
-/usr/lib/libpangosharpglue-2.la \
-/usr/lib/libpangosharpglue-2.a \
-/usr/lib/libgdksharpglue-2.la \
-/usr/lib/libgdksharpglue-2.a"
-
-FILES_glade-sharp2-glue-staticdev = " \
-/usr/lib/libgladesharpglue-2.la \
-/usr/lib/libgladesharpglue-2.a"
-
-FILES_glib-sharp2-glue-staticdev = " \
-/usr/lib/libglibsharpglue-2.la \
-/usr/lib/libglibsharpglue-2.a"
-
-PACKAGES = "libgtk2.0-cil libgtk2.0-cil-dev libgtk2.0-cil-dbg \
-libglib2.0-cil libglib2.0-cil-dev libglib2.0-cil-dbg \
-libglade2.0-cil libglade2.0-cil-dev libglade2.0-cil-dbg \
-gtk-sharp-gapi2 gtk-sharp-gapi2-dev \
-gtk-sharp2-glue-staticdev glade-sharp2-glue-staticdev glib-sharp2-glue-staticdev"
-
-SRC_URI[md5sum] = "7d509a677c58b2e6a8c85db51d0b1451"
-SRC_URI[sha256sum] = "8dc7f6180109a529b3216b6527f34a01e1e4484e42ebbd28d551e8f6ce0c243d"
-
-# There is a race condition in the gtk-sharp build which seems to result in failure to
-# properly sign assemblies (e.g. policy-2.4-foo.dll). We then fail installing those to
-# the GAC as they are delay signed rather than strong named as they should be. Until 
-# the race condition is identified and patched a workaround is to disable parallel make
-# tasks for this recipe (AJL 26/01/13)
-PARALLEL_MAKE=""
-
diff --git a/recipes-mono/gtk-sharp/gtk-sharp_2.12.21.bb b/recipes-mono/gtk-sharp/gtk-sharp_2.12.21.bb
new file mode 100644
index 0000000..a011126
--- /dev/null
+++ b/recipes-mono/gtk-sharp/gtk-sharp_2.12.21.bb
@@ -0,0 +1,13 @@
+require gtk-sharp.inc
+
+inherit pkgconfig
+
+PR = "r1"
+
+LIC_FILES_CHKSUM = "files://COPYING;md5=f14599a2f089f6ff8c97e2baa4e3d575"
+
+SRC_URI[md5sum] = "2e892f265877fe5c16f41b771edb7618"
+SRC_URI[sha256sum] = "ea02da7000433115dcc008102e0c217479c06d74b2c3af5b76527784f933b088"
+
+SEXT = "gz"
+
-- 
1.7.9.5

Re: [meta-mono] [PATCH 1/1] gtk-sharp: Updated to GTK# 2.12.21

[Khem Raj]

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


On Feb 27, 2014, at 6:16 AM, Alex J Lennon <ajlennon@dynamicdevices.co.uk> wrote:

> +PR = "r1"
> +

get rid of that

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

Re: [meta-mono] [PATCH 1/1] gtk-sharp: Updated to GTK# 2.12.21

[Alex J Lennon]

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


On 27/02/2014 15:50, Khem Raj wrote:
>
> On Feb 27, 2014, at 6:16 AM, Alex J Lennon
<ajlennon@dynamicdevices.co.uk> wrote:
>
>> +PR = "r1"
>> +
>
> get rid of that

Why is that Khem?


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

Re: [meta-mono] [PATCH 1/1] gtk-sharp: Updated to GTK# 2.12.21

[Khem Raj]

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


On Feb 27, 2014, at 7:59 AM, Alex J Lennon <ajlennon@dynamicdevices.co.uk> wrote:

> 
> On 27/02/2014 15:50, Khem Raj wrote:
> >
> 
>       > On Feb 27, 2014, at 6:16 AM, Alex J Lennon
>       <ajlennon@dynamicdevices.co.uk> wrote:
> 
>       >
> 
>       >> +PR = "r1"
> 
>       >> +
> 
>       >
> 
>       > get rid of that
> 
> Why is that Khem?
> 

we have automatic PR server now a days, its enabled by default. 

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

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

Re: [meta-mono] [PATCH 1/1] gtk-sharp: Updated to GTK# 2.12.21

[Alex J Lennon]

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


On 27/02/2014 16:30, Khem Raj wrote:
>
> On Feb 27, 2014, at 7:59 AM, Alex J Lennon
> <ajlennon@dynamicdevices.co.uk <mailto:ajlennon@dynamicdevices.co.uk>>
> wrote:
>
>>
>> On 27/02/2014 15:50, Khem Raj wrote:
>> >
>> > On Feb 27, 2014, at 6:16 AM, Alex J Lennon
>> <ajlennon@dynamicdevices.co.uk> wrote:
>> >
>> >> +PR = "r1"
>> >> +
>> >
>> > get rid of that
>>
>> Why is that Khem?
>>
>
> we have automatic PR server now a days, its enabled by default. 

OK thanks. These are on all / most of the recipes currently in
meta-mono, so I'll just remove all occurences of ${PR} then (?)

Rgds, Alex


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

Re: [meta-mono] [PATCH 1/1] gtk-sharp: Updated to GTK# 2.12.21

[Khem Raj]

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


On Feb 27, 2014, at 8:33 AM, Alex J Lennon <ajlennon@dynamicdevices.co.uk> wrote:

> 
> On 27/02/2014 16:30, Khem Raj wrote:
>> 
>> On Feb 27, 2014, at 7:59 AM, Alex J Lennon <ajlennon@dynamicdevices.co.uk> wrote:
>> 
>>> 
>>> On 27/02/2014 15:50, Khem Raj wrote:
>>> >
>>> 
>>>               > On Feb 27, 2014, at 6:16 AM, Alex J Lennon <ajlennon@dynamicdevices.co.uk>
>>>               wrote:
>>> 
>>>               >
>>> 
>>>               >> +PR = "r1"
>>> 
>>>               >> +
>>> 
>>>               >
>>> 
>>>               > get rid of that
>>> 
>>> Why is that Khem?
>>> 
>> 
>> we have automatic PR server now a days, its enabled by default. 
> 
> OK thanks. These are on all / most of the recipes currently in meta-mono, so I'll just remove all occurences of ${PR} then (?)

well, whenever you upgrade thats when you will do it. if PR is larger than 0 but if you have PR = “r0” that you can remove now

> 
> Rgds, Alex
> 


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

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

Re: [meta-mono] [PATCH 1/1] gtk-sharp: Updated to GTK# 2.12.21

[Alex J Lennon]

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


On 27/02/2014 17:04, Khem Raj wrote:
>
> On Feb 27, 2014, at 8:33 AM, Alex J Lennon
> <ajlennon@dynamicdevices.co.uk <mailto:ajlennon@dynamicdevices.co.uk>>
> wrote:
>
>>
>> On 27/02/2014 16:30, Khem Raj wrote:
>>>
>>> On Feb 27, 2014, at 7:59 AM, Alex J Lennon
>>> <ajlennon@dynamicdevices.co.uk
>>> <mailto:ajlennon@dynamicdevices.co.uk>> wrote:
>>>
>>>>
>>>> On 27/02/2014 15:50, Khem Raj wrote:
>>>> >
>>>> > On Feb 27, 2014, at 6:16 AM, Alex J Lennon
>>>> <ajlennon@dynamicdevices.co.uk> wrote:
>>>> >
>>>> >> +PR = "r1"
>>>> >> +
>>>> >
>>>> > get rid of that
>>>>
>>>> Why is that Khem?
>>>>
>>>
>>> we have automatic PR server now a days, its enabled by default. 
>>
>> OK thanks. These are on all / most of the recipes currently in
>> meta-mono, so I'll just remove all occurences of ${PR} then (?)
>
> well, whenever you upgrade thats when you will do it. if PR is larger
> than 0 but if you have PR = “r0” that you can remove now
>

Ok will do. Thanks.



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

Re: [meta-mono] [PATCH 1/1] gtk-sharp: Updated to GTK# 2.12.21

[Paul Eggleton]

On Thursday 27 February 2014 08:30:10 Khem Raj wrote:
> On Feb 27, 2014, at 7:59 AM, Alex J Lennon <ajlennon@dynamicdevices.co.uk>
> wrote:
> > On 27/02/2014 15:50, Khem Raj wrote:
> >       > On Feb 27, 2014, at 6:16 AM, Alex J Lennon
> >       
> >       <ajlennon@dynamicdevices.co.uk> wrote:
> >       >> +PR = "r1"
> >       >> 
> >       >> +
> >       > 
> >       > get rid of that
> > 
> > Why is that Khem?
> 
> we have automatic PR server now a days, its enabled by default.

FWIW, I don't think it's enabled by default, at least not in OE-Core/Poky. The 
point still stands though, it's the way PR should be managed rather than 
manual bumping.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [meta-mono] [PATCH 1/1] gtk-sharp: Updated to GTK# 2.12.21

[Khem Raj]

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


On Feb 27, 2014, at 9:09 AM, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:

> On Thursday 27 February 2014 08:30:10 Khem Raj wrote:
>> On Feb 27, 2014, at 7:59 AM, Alex J Lennon <ajlennon@dynamicdevices.co.uk>
>> wrote:
>>> On 27/02/2014 15:50, Khem Raj wrote:
>>>> On Feb 27, 2014, at 6:16 AM, Alex J Lennon
>>> 
>>>      <ajlennon@dynamicdevices.co.uk> wrote:
>>>>> +PR = "r1"
>>>>> 
>>>>> +
>>>> 
>>>> get rid of that
>>> 
>>> Why is that Khem?
>> 
>> we have automatic PR server now a days, its enabled by default.
> 
> FWIW, I don't think it's enabled by default,

yes its not enabled however is way forward

> at least not in OE-Core/Poky. The 
> point still stands though, it's the way PR should be managed rather than 
> manual bumping.
> 
> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre


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

Re: [meta-mono] [PATCH 1/1] gtk-sharp: Updated to GTK# 2.12.21

[Alex J Lennon]

On 27/02/2014 17:09, Paul Eggleton wrote:
> On Thursday 27 February 2014 08:30:10 Khem Raj wrote:
>> On Feb 27, 2014, at 7:59 AM, Alex J Lennon <ajlennon@dynamicdevices.co.uk>
>> wrote:
>>> On 27/02/2014 15:50, Khem Raj wrote:
>>>       > On Feb 27, 2014, at 6:16 AM, Alex J Lennon
>>>       
>>>       <ajlennon@dynamicdevices.co.uk> wrote:
>>>       >> +PR = "r1"
>>>       >> 
>>>       >> +
>>>       > 
>>>       > get rid of that
>>>
>>> Why is that Khem?
>> we have automatic PR server now a days, its enabled by default.
> FWIW, I don't think it's enabled by default, at least not in OE-Core/Poky. The 
> point still stands though, it's the way PR should be managed rather than 
> manual bumping.
>

<googling/> Are we talking about the "network based PR service"? 

Is this a single globally available nework service or a service that's
intended to be running local to a specific build farm?

My reading of the wiki page seems to imply it's intended to be local to
a build farm, or system, rather than globally unique?

So if I'm releasing packages to production this now becomes a critical
part of my infrastructure as I'll lose all my package revisions if
something goes wrong with it?

And my packages will have different revisions from somebody elses's
packages when they are running their own network based PR service?

I suppose the other question is, if I release a package of revision X,
then another which is up-rev'd' to Y as I made a change to the recipe
and so the NBPRS up-revs, then somebody comes back to me and tells me
they are having a problem with Xm then how do I link that rev X to the
specific commit that went to build it so I can audit ?

I haven't enabled this here, so does that mean all my package revisions
will be r0 as I remove the PR variables from recipes ?

Thanks,

Alex
 

Re: [meta-mono] [PATCH 1/1] gtk-sharp: Updated to GTK# 2.12.21

[Paul Eggleton]

On Thursday 27 February 2014 17:32:29 Alex J Lennon wrote:
> On 27/02/2014 17:09, Paul Eggleton wrote:
> > On Thursday 27 February 2014 08:30:10 Khem Raj wrote:
> >> On Feb 27, 2014, at 7:59 AM, Alex J Lennon
> >> <ajlennon@dynamicdevices.co.uk>
> >> 
> >> wrote:
> >>> On 27/02/2014 15:50, Khem Raj wrote:
> >>>       > On Feb 27, 2014, at 6:16 AM, Alex J Lennon
> >>>       
> >>>       <ajlennon@dynamicdevices.co.uk> wrote:
> >>>       >> +PR = "r1"
> >>>       >> 
> >>>       >> +
> >>>       > 
> >>>       > get rid of that
> >>> 
> >>> Why is that Khem?
> >> 
> >> we have automatic PR server now a days, its enabled by default.
> > 
> > FWIW, I don't think it's enabled by default, at least not in OE-Core/Poky.
> > The point still stands though, it's the way PR should be managed rather
> > than manual bumping.
>
> <googling/> Are we talking about the "network based PR service"?

Yes, see:

 http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working-with-a-pr-service
 
> Is this a single globally available nework service or a service that's
> intended to be running local to a specific build farm?

Specific build farm; it may be made externally accessible if necessary
however.

> My reading of the wiki page seems to imply it's intended to be local to
> a build farm, or system, rather than globally unique?

PR values needn't match up between different distros. The point is they should
get increased when a material change to the recipe's output happens; and this
can happen for example when:

* A class that the recipe inherits is changed 

* A dependency of the recipe that influences how the recipe is built gets
changed

* Some global configuration changed that affects how the recipe is built
e.g. DISTRO_FEATURES

* A bbappend is added or removed

In all of these cases the recipe itself does not get changed at all - prior to
the PR server we had to remember to manually bump PR in the affected recipes,
or (more often) we'd forget to handle it properly altogether. With the PR
server, PR bumps happen automatically in response to signatures changing,
which is about as accurate an indicator as we can get as far as determining
whether the output has changed, and certainly much less prone to mistakes.

> So if I'm releasing packages to production this now becomes a critical
> part of my infrastructure as I'll lose all my package revisions if
> something goes wrong with it?

Yes. Luckily it's not a particularly complicated piece of software; the only
extra thing you need to preserve is the sqlite database that contains the
hashes and corresponding PR values.
 
> And my packages will have different revisions from somebody elses's
> packages when they are running their own network based PR service?

Yes. If bbappends were involved all bets were off prior to the PR service
anyway since they were supposed to modify PR.
 
> I suppose the other question is, if I release a package of revision X,
> then another which is up-rev'd' to Y as I made a change to the recipe
> and so the NBPRS up-revs, then somebody comes back to me and tells me
> they are having a problem with Xm then how do I link that rev X to the
> specific commit that went to build it so I can audit ?

The PR server doesn't track this - however, all of this information does go
into buildhistory if you enable that.

> I haven't enabled this here, so does that mean all my package revisions
> will be r0 as I remove the PR variables from recipes ?

We're not talking about dropping all PR values in existing recipes, we're
talking about dropping them on upgrade (i.e. when PV changes), where
previously we'd have done that anyway or set them to "r0".

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [meta-mono] [PATCH 1/1] gtk-sharp: Updated to GTK# 2.12.21

[Paul Eggleton]

On Thursday 27 February 2014 18:18:29 Paul Eggleton wrote:
> On Thursday 27 February 2014 17:32:29 Alex J Lennon wrote:
> > On 27/02/2014 17:09, Paul Eggleton wrote:
> > > On Thursday 27 February 2014 08:30:10 Khem Raj wrote:
> > >> On Feb 27, 2014, at 7:59 AM, Alex J Lennon
> > >> <ajlennon@dynamicdevices.co.uk>
> > >> 
> > >> wrote:
> > >>> On 27/02/2014 15:50, Khem Raj wrote:
> > >>>       > On Feb 27, 2014, at 6:16 AM, Alex J Lennon
> > >>>       
> > >>>       <ajlennon@dynamicdevices.co.uk> wrote:
> > >>>       >> +PR = "r1"
> > >>>       >> 
> > >>>       >> +
> > >>>       > 
> > >>>       > get rid of that
> > >>> 
> > >>> Why is that Khem?
> > >> 
> > >> we have automatic PR server now a days, its enabled by default.
> > > 
> > > FWIW, I don't think it's enabled by default, at least not in
> > > OE-Core/Poky.
> > > The point still stands though, it's the way PR should be managed rather
> > > than manual bumping.
> > 
> > <googling/> Are we talking about the "network based PR service"?
> 
> Yes, see:
> 
>  http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working
> -with-a-pr-service
> > Is this a single globally available nework service or a service that's
> > intended to be running local to a specific build farm?
> 
> Specific build farm; it may be made externally accessible if necessary
> however.
> 
> > My reading of the wiki page seems to imply it's intended to be local to
> > a build farm, or system, rather than globally unique?
> 
> PR values needn't match up between different distros. The point is they
> should get increased when a material change to the recipe's output happens;
> and this can happen for example when:
> 
> * A class that the recipe inherits is changed
> 
> * A dependency of the recipe that influences how the recipe is built gets
> changed
> 
> * Some global configuration changed that affects how the recipe is built
> e.g. DISTRO_FEATURES
> 
> * A bbappend is added or removed
> 
> In all of these cases the recipe itself does not get changed at all - prior
> to the PR server we had to remember to manually bump PR in the affected
> recipes, or (more often) we'd forget to handle it properly altogether. With
> the PR server, PR bumps happen automatically in response to signatures
> changing, which is about as accurate an indicator as we can get as far as
> determining whether the output has changed, and certainly much less prone
> to mistakes.
> > So if I'm releasing packages to production this now becomes a critical
> > part of my infrastructure as I'll lose all my package revisions if
> > something goes wrong with it?
> 
> Yes. Luckily it's not a particularly complicated piece of software; the only
> extra thing you need to preserve is the sqlite database that contains the
> hashes and corresponding PR values.
> 
> > And my packages will have different revisions from somebody elses's
> > packages when they are running their own network based PR service?
> 
> Yes. If bbappends were involved all bets were off prior to the PR service
> anyway since they were supposed to modify PR.
> 
> > I suppose the other question is, if I release a package of revision X,
> > then another which is up-rev'd' to Y as I made a change to the recipe
> > and so the NBPRS up-revs, then somebody comes back to me and tells me
> > they are having a problem with Xm then how do I link that rev X to the
> > specific commit that went to build it so I can audit ?
> 
> The PR server doesn't track this - however, all of this information does go
> into buildhistory if you enable that.
> 
> > I haven't enabled this here, so does that mean all my package revisions
> > will be r0 as I remove the PR variables from recipes ?
> 
> We're not talking about dropping all PR values in existing recipes, we're
> talking about dropping them on upgrade (i.e. when PV changes), where
> previously we'd have done that anyway or set them to "r0".

I should point out also in case it's not obvious - you only really need to 
care about this if you enable the packaging system on the target (i.e. 
"package-management" is in IMAGE_FEATURES).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [meta-mono] [PATCH 1/1] gtk-sharp: Updated to GTK# 2.12.21

[Alex J Lennon]

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


On 27/02/2014 18:18, Paul Eggleton wrote:
> On Thursday 27 February 2014 17:32:29 Alex J Lennon wrote:
>> On 27/02/2014 17:09, Paul Eggleton wrote:
>>> On Thursday 27 February 2014 08:30:10 Khem Raj wrote:
>>>> On Feb 27, 2014, at 7:59 AM, Alex J Lennon
>>>> <ajlennon@dynamicdevices.co.uk>
>>>>
>>>> wrote:
>>>>> On 27/02/2014 15:50, Khem Raj wrote:
>>>>>       > On Feb 27, 2014, at 6:16 AM, Alex J Lennon
>>>>>       
>>>>>       <ajlennon@dynamicdevices.co.uk> wrote:
>>>>>       >> +PR = "r1"
>>>>>       >> 
>>>>>       >> +
>>>>>       > 
>>>>>       > get rid of that
>>>>>
>>>>> Why is that Khem?
>>>> we have automatic PR server now a days, its enabled by default.
>>> FWIW, I don't think it's enabled by default, at least not in OE-Core/Poky.
>>> The point still stands though, it's the way PR should be managed rather
>>> than manual bumping.
>> <googling/> Are we talking about the "network based PR service"?
> Yes, see:
>
>  http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working-with-a-pr-service
>  

OK thanks for this, it's very useful.


>> Is this a single globally available nework service or a service that's
>> intended to be running local to a specific build farm?
> Specific build farm; it may be made externally accessible if necessary
> however.
>
>> My reading of the wiki page seems to imply it's intended to be local to
>> a build farm, or system, rather than globally unique?
> PR values needn't match up between different distros. The point is they should
> get increased when a material change to the recipe's output happens; and this
> can happen for example when:
>
> * A class that the recipe inherits is changed 
>
> * A dependency of the recipe that influences how the recipe is built gets
> changed
>
> * Some global configuration changed that affects how the recipe is built
> e.g. DISTRO_FEATURES
>
> * A bbappend is added or removed
>
> In all of these cases the recipe itself does not get changed at all - prior to
> the PR server we had to remember to manually bump PR in the affected recipes,
> or (more often) we'd forget to handle it properly altogether. With the PR
> server, PR bumps happen automatically in response to signatures changing,
> which is about as accurate an indicator as we can get as far as determining
> whether the output has changed, and certainly much less prone to mistakes.

OK so I can't download the source code to a distribution and built
identical, identically
versioned packages to theirs? With something like RPM wouldn't I expect
to be able to
download an RPM source package and build an identical, versioned RPM
from it?

As a minimum my package revision naming will be different from the
upstream distro
presumably?

Taking a slightly different tack, if I upgrade a recipe PV from 1.0.0 to
2.0.0 to correspond
to the upstream source versioning, and at that time I remove PR and
build some packages.

Then a month later I realise I need something extra added to the
configuration options,
which gives me a different output, what do I change to make sure the new
package is
versioned differently from the old package? (i.e. presumably if the
network service is
running it will handle it for me, but if it's not running then new
package will be versioned
identically to my old package?)

Thanks, Alex

>> So if I'm releasing packages to production this now becomes a critical
>> part of my infrastructure as I'll lose all my package revisions if
>> something goes wrong with it?
> Yes. Luckily it's not a particularly complicated piece of software; the only
> extra thing you need to preserve is the sqlite database that contains the
> hashes and corresponding PR values.
>  
>> And my packages will have different revisions from somebody elses's
>> packages when they are running their own network based PR service?
> Yes. If bbappends were involved all bets were off prior to the PR service
> anyway since they were supposed to modify PR.
>  
>> I suppose the other question is, if I release a package of revision X,
>> then another which is up-rev'd' to Y as I made a change to the recipe
>> and so the NBPRS up-revs, then somebody comes back to me and tells me
>> they are having a problem with Xm then how do I link that rev X to the
>> specific commit that went to build it so I can audit ?
> The PR server doesn't track this - however, all of this information does go
> into buildhistory if you enable that.

Must look at that, yes.

>> I haven't enabled this here, so does that mean all my package revisions
>> will be r0 as I remove the PR variables from recipes ?
> We're not talking about dropping all PR values in existing recipes, we're
> talking about dropping them on upgrade (i.e. when PV changes), where
> previously we'd have done that anyway or set them to "r0".
>
> Cheers,
> Paul
>

-- 

Dynamic Devices Ltd <http://www.dynamicdevices.co.uk/>

Alex J Lennon / Director
1 Queensway, Liverpool L22 4RA

mobile: +44 (0)7956 668178

Linkedin <http://www.linkedin.com/in/alexjlennon> Skype
<skype:alexjlennon?add>

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended
recipient(s). Any unauthorized disclosure, dissemination, distribution,
copying or the taking of any action in reliance on the information
herein is prohibited. E-mails are not secure and cannot be guaranteed to
be error free as they can be intercepted, amended, or contain viruses.
Anyone who communicates with us by e-mail is deemed to have accepted
these risks. Company Name is not responsible for errors or omissions in
this message and denies any responsibility for any damage arising from
the use of e-mail. Any opinion and other statement contained in this
message and any attachment are solely those of the author and do not
necessarily represent those of the company.


[-- Attachment #2.1: Type: text/html, Size: 10261 bytes --]

[-- Attachment #2.2: ddlogo-4.png --]
[-- Type: image/png, Size: 3997 bytes --]

[-- Attachment #2.3: linkedin.png --]
[-- Type: image/png, Size: 631 bytes --]

[-- Attachment #2.4: skype.png --]
[-- Type: image/png, Size: 800 bytes --]

Re: [meta-mono] [PATCH 1/1] gtk-sharp: Updated to GTK# 2.12.21

[Paul Eggleton]

On Thursday 27 February 2014 18:29:59 Alex J Lennon wrote:
> On 27/02/2014 18:18, Paul Eggleton wrote:
> > PR values needn't match up between different distros. The point is they
> > should get increased when a material change to the recipe's output
> > happens; and this can happen for example when:
> > 
> > * A class that the recipe inherits is changed
> > 
> > * A dependency of the recipe that influences how the recipe is built gets
> > changed
> > 
> > * Some global configuration changed that affects how the recipe is built
> > e.g. DISTRO_FEATURES
> > 
> > * A bbappend is added or removed
> > 
> > In all of these cases the recipe itself does not get changed at all -
> > prior to the PR server we had to remember to manually bump PR in the
> > affected recipes, or (more often) we'd forget to handle it properly
> > altogether. With the PR server, PR bumps happen automatically in response
> > to signatures changing, which is about as accurate an indicator as we can
> > get as far as determining whether the output has changed, and certainly
> > much less prone to mistakes.
>
> OK so I can't download the source code to a distribution and built
> identical, identically versioned packages to theirs? With something like
> RPM wouldn't I expect to be able to download an RPM source package
> and build an identical, versioned RPM from it?

They'll always be "identical" as far as the material content goes, that's not
in question here - we're just talking about the PR values. For the PR values
it depends - which distro are we talking about? IIRC for example, SHR and
Angstrom both make their PR servers available so that people's PR values
will match up if they build it from source themselves.

However, I think we're starting to head into territory where you have to
ask who is maintaining this distro you are referring to. If you're making
changes to how things get built, arguably it's now a derivative distro
and you ought to be maintaining it yourself; at which point you shouldn't
expect the PR values to match up. How else would you signify that you'd
made the configuration change (or added your own patch, or ...) if it's
someone else's distro that doesn't contain that change "upstream"?

> Taking a slightly different tack, if I upgrade a recipe PV from 1.0.0 to
> 2.0.0 to correspond to the upstream source versioning, and at that
> time I remove PR and build some packages.
> 
> Then a month later I realise I need something extra added to the
> configuration options, which gives me a different output, what do I 
> change to make sure the new package is versioned differently from
> the old package? (i.e. presumably if the network service is
> running it will handle it for me, but if it's not running then new
> package will be versioned identically to my old package?)

Yes. If you care about PR values (i.e. you're using packaging on the
target) then you need to enable and use the PR server. If you do that,
you don't need to make any additional change other than the
configure option change you've already made - EXTRA_OECONF
would presumably have been changed -> do_configure signature
changes -> dependent task signatures change -> the PR value
changes automatically.

> >> I suppose the other question is, if I release a package of revision X,
> >> then another which is up-rev'd' to Y as I made a change to the recipe
> >> and so the NBPRS up-revs, then somebody comes back to me and tells me
> >> they are having a problem with Xm then how do I link that rev X to the
> >> specific commit that went to build it so I can audit ?
> > 
> > The PR server doesn't track this - however, all of this information does
> > go into buildhistory if you enable that.
> 
> Must look at that, yes.

For reference:

http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#maintaining-build-output-quality

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [meta-mono] [PATCH 1/1] gtk-sharp: Updated to GTK# 2.12.21

[Alex J Lennon]

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


On 27/02/2014 18:48, Paul Eggleton wrote:
> On Thursday 27 February 2014 18:29:59 Alex J Lennon wrote:
>> On 27/02/2014 18:18, Paul Eggleton wrote:
>>> PR values needn't match up between different distros. The point is they
>>> should get increased when a material change to the recipe's output
>>> happens; and this can happen for example when:
>>>
>>> * A class that the recipe inherits is changed
>>>
>>> * A dependency of the recipe that influences how the recipe is built gets
>>> changed
>>>
>>> * Some global configuration changed that affects how the recipe is built
>>> e.g. DISTRO_FEATURES
>>>
>>> * A bbappend is added or removed
>>>
>>> In all of these cases the recipe itself does not get changed at all -
>>> prior to the PR server we had to remember to manually bump PR in the
>>> affected recipes, or (more often) we'd forget to handle it properly
>>> altogether. With the PR server, PR bumps happen automatically in response
>>> to signatures changing, which is about as accurate an indicator as we can
>>> get as far as determining whether the output has changed, and certainly
>>> much less prone to mistakes.
>> OK so I can't download the source code to a distribution and built
>> identical, identically versioned packages to theirs? With something like
>> RPM wouldn't I expect to be able to download an RPM source package
>> and build an identical, versioned RPM from it?
> They'll always be "identical" as far as the material content goes, that's not
> in question here - we're just talking about the PR values. For the PR values
> it depends - which distro are we talking about? IIRC for example, SHR and
> Angstrom both make their PR servers available so that people's PR values
> will match up if they build it from source themselves.
>
> However, I think we're starting to head into territory where you have to
> ask who is maintaining this distro you are referring to. If you're making
> changes to how things get built, arguably it's now a derivative distro
> and you ought to be maintaining it yourself; at which point you shouldn't
> expect the PR values to match up. How else would you signify that you'd
> made the configuration change (or added your own patch, or ...) if it's
> someone else's distro that doesn't contain that change "upstream"?
>
>> Taking a slightly different tack, if I upgrade a recipe PV from 1.0.0 to
>> 2.0.0 to correspond to the upstream source versioning, and at that
>> time I remove PR and build some packages.
>>
>> Then a month later I realise I need something extra added to the
>> configuration options, which gives me a different output, what do I 
>> change to make sure the new package is versioned differently from
>> the old package? (i.e. presumably if the network service is
>> running it will handle it for me, but if it's not running then new
>> package will be versioned identically to my old package?)
> Yes. If you care about PR values (i.e. you're using packaging on the
> target) then you need to enable and use the PR server. If you do that,
> you don't need to make any additional change other than the
> configure option change you've already made - EXTRA_OECONF
> would presumably have been changed -> do_configure signature
> changes -> dependent task signatures change -> the PR value
> changes automatically.

OK thanks. I best get it switched on then :)

>>>> I suppose the other question is, if I release a package of revision X,
>>>> then another which is up-rev'd' to Y as I made a change to the recipe
>>>> and so the NBPRS up-revs, then somebody comes back to me and tells me
>>>> they are having a problem with Xm then how do I link that rev X to the
>>>> specific commit that went to build it so I can audit ?
>>> The PR server doesn't track this - however, all of this information does
>>> go into buildhistory if you enable that.
>> Must look at that, yes.
> For reference:
>
> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#maintaining-build-output-quality

Thanks

> Cheers,
> Paul
>

-- 

Dynamic Devices Ltd <http://www.dynamicdevices.co.uk/>

Alex J Lennon / Director
1 Queensway, Liverpool L22 4RA

mobile: +44 (0)7956 668178

Linkedin <http://www.linkedin.com/in/alexjlennon> Skype
<skype:alexjlennon?add>

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended
recipient(s). Any unauthorized disclosure, dissemination, distribution,
copying or the taking of any action in reliance on the information
herein is prohibited. E-mails are not secure and cannot be guaranteed to
be error free as they can be intercepted, amended, or contain viruses.
Anyone who communicates with us by e-mail is deemed to have accepted
these risks. Company Name is not responsible for errors or omissions in
this message and denies any responsibility for any damage arising from
the use of e-mail. Any opinion and other statement contained in this
message and any attachment are solely those of the author and do not
necessarily represent those of the company.


[-- Attachment #2.1: Type: text/html, Size: 8255 bytes --]

[-- Attachment #2.2: ddlogo-4.png --]
[-- Type: image/png, Size: 3997 bytes --]

[-- Attachment #2.3: linkedin.png --]
[-- Type: image/png, Size: 631 bytes --]

[-- Attachment #2.4: skype.png --]
[-- Type: image/png, Size: 800 bytes --]

Re: [meta-mono] [PATCH 1/1] gtk-sharp: Updated to GTK# 2.12.21

[Alex J Lennon]

On 27/02/2014 18:48, Paul Eggleton wrote:
> On Thursday 27 February 2014 18:29:59 Alex J Lennon wrote:
>> On 27/02/2014 18:18, Paul Eggleton wrote:
>>> PR values needn't match up between different distros. The point is they
>>> should get increased when a material change to the recipe's output
>>> happens; and this can happen for example when:
>>>
>>> * A class that the recipe inherits is changed
>>>
>>> * A dependency of the recipe that influences how the recipe is built gets
>>> changed
>>>
>>> * Some global configuration changed that affects how the recipe is built
>>> e.g. DISTRO_FEATURES
>>>
>>> * A bbappend is added or removed
>>>
>>> In all of these cases the recipe itself does not get changed at all -
>>> prior to the PR server we had to remember to manually bump PR in the
>>> affected recipes, or (more often) we'd forget to handle it properly
>>> altogether. With the PR server, PR bumps happen automatically in response
>>> to signatures changing, which is about as accurate an indicator as we can
>>> get as far as determining whether the output has changed, and certainly
>>> much less prone to mistakes.
>> OK so I can't download the source code to a distribution and built
>> identical, identically versioned packages to theirs? With something like
>> RPM wouldn't I expect to be able to download an RPM source package
>> and build an identical, versioned RPM from it?
> They'll always be "identical" as far as the material content goes, that's not
> in question here - we're just talking about the PR values. For the PR values
> it depends - which distro are we talking about? IIRC for example, SHR and
> Angstrom both make their PR servers available so that people's PR values
> will match up if they build it from source themselves.
>
> However, I think we're starting to head into territory where you have to
> ask who is maintaining this distro you are referring to. If you're making
> changes to how things get built, arguably it's now a derivative distro
> and you ought to be maintaining it yourself; at which point you shouldn't
> expect the PR values to match up. How else would you signify that you'd
> made the configuration change (or added your own patch, or ...) if it's
> someone else's distro that doesn't contain that change "upstream"?
>
>> Taking a slightly different tack, if I upgrade a recipe PV from 1.0.0 to
>> 2.0.0 to correspond to the upstream source versioning, and at that
>> time I remove PR and build some packages.
>>
>> Then a month later I realise I need something extra added to the
>> configuration options, which gives me a different output, what do I 
>> change to make sure the new package is versioned differently from
>> the old package? (i.e. presumably if the network service is
>> running it will handle it for me, but if it's not running then new
>> package will be versioned identically to my old package?)
> Yes. If you care about PR values (i.e. you're using packaging on the
> target) then you need to enable and use the PR server. If you do that,
> you don't need to make any additional change other than the
> configure option change you've already made - EXTRA_OECONF
> would presumably have been changed -> do_configure signature
> changes -> dependent task signatures change -> the PR value
> changes automatically.
>
>>>> I suppose the other question is, if I release a package of revision X,
>>>> then another which is up-rev'd' to Y as I made a change to the recipe
>>>> and so the NBPRS up-revs, then somebody comes back to me and tells me
>>>> they are having a problem with Xm then how do I link that rev X to the
>>>> specific commit that went to build it so I can audit ?
>>> The PR server doesn't track this - however, all of this information does
>>> go into buildhistory if you enable that.
>> Must look at that, yes.
> For reference:
>
> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#maintaining-build-output-quality
>
> Cheers,
> Paul
>

I've just noticed this which seems to usefully address some of my
questions; include for others who may come across the thread,

https://bugzilla.yoctoproject.org/show_bug.cgi?id=1556

Excellent. So I can export my current set of AUTOPR values to a file,
give that to another development team in the handover, or test, or
whomever,
who can then import and build packages with the same version/name
(assuming that they're on another site or otherwise don't have access to
my PR
network service ). I can see that will obviate the need for an
inordinate number of conversations with the test team.

Re: [meta-mono] [PATCH 1/1] gtk-sharp: Updated to GTK# 2.12.21

[Paul Eggleton]

On Thursday 27 February 2014 19:15:38 Alex J Lennon wrote:
> On 27/02/2014 18:48, Paul Eggleton wrote:
> > On Thursday 27 February 2014 18:29:59 Alex J Lennon wrote:
> >> On 27/02/2014 18:18, Paul Eggleton wrote:
> >>> PR values needn't match up between different distros. The point is they
> >>> should get increased when a material change to the recipe's output
> >>> happens; and this can happen for example when:
> >>> 
> >>> * A class that the recipe inherits is changed
> >>> 
> >>> * A dependency of the recipe that influences how the recipe is built
> >>> gets
> >>> changed
> >>> 
> >>> * Some global configuration changed that affects how the recipe is built
> >>> e.g. DISTRO_FEATURES
> >>> 
> >>> * A bbappend is added or removed
> >>> 
> >>> In all of these cases the recipe itself does not get changed at all -
> >>> prior to the PR server we had to remember to manually bump PR in the
> >>> affected recipes, or (more often) we'd forget to handle it properly
> >>> altogether. With the PR server, PR bumps happen automatically in
> >>> response
> >>> to signatures changing, which is about as accurate an indicator as we
> >>> can
> >>> get as far as determining whether the output has changed, and certainly
> >>> much less prone to mistakes.
> >> 
> >> OK so I can't download the source code to a distribution and built
> >> identical, identically versioned packages to theirs? With something like
> >> RPM wouldn't I expect to be able to download an RPM source package
> >> and build an identical, versioned RPM from it?
> > 
> > They'll always be "identical" as far as the material content goes, that's
> > not in question here - we're just talking about the PR values. For the PR
> > values it depends - which distro are we talking about? IIRC for example,
> > SHR and Angstrom both make their PR servers available so that people's PR
> > values will match up if they build it from source themselves.
> > 
> > However, I think we're starting to head into territory where you have to
> > ask who is maintaining this distro you are referring to. If you're making
> > changes to how things get built, arguably it's now a derivative distro
> > and you ought to be maintaining it yourself; at which point you shouldn't
> > expect the PR values to match up. How else would you signify that you'd
> > made the configuration change (or added your own patch, or ...) if it's
> > someone else's distro that doesn't contain that change "upstream"?
> > 
> >> Taking a slightly different tack, if I upgrade a recipe PV from 1.0.0 to
> >> 2.0.0 to correspond to the upstream source versioning, and at that
> >> time I remove PR and build some packages.
> >> 
> >> Then a month later I realise I need something extra added to the
> >> configuration options, which gives me a different output, what do I
> >> change to make sure the new package is versioned differently from
> >> the old package? (i.e. presumably if the network service is
> >> running it will handle it for me, but if it's not running then new
> >> package will be versioned identically to my old package?)
> > 
> > Yes. If you care about PR values (i.e. you're using packaging on the
> > target) then you need to enable and use the PR server. If you do that,
> > you don't need to make any additional change other than the
> > configure option change you've already made - EXTRA_OECONF
> > would presumably have been changed -> do_configure signature
> > changes -> dependent task signatures change -> the PR value
> > changes automatically.
> > 
> >>>> I suppose the other question is, if I release a package of revision X,
> >>>> then another which is up-rev'd' to Y as I made a change to the recipe
> >>>> and so the NBPRS up-revs, then somebody comes back to me and tells me
> >>>> they are having a problem with Xm then how do I link that rev X to the
> >>>> specific commit that went to build it so I can audit ?
> >>> 
> >>> The PR server doesn't track this - however, all of this information does
> >>> go into buildhistory if you enable that.
> >> 
> >> Must look at that, yes.
> > 
> > For reference:
> > 
> > http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#mainta
> > ining-build-output-quality
> > 
> > Cheers,
> > Paul
> 
> I've just noticed this which seems to usefully address some of my
> questions; include for others who may come across the thread,
> 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1556
> 
> Excellent. So I can export my current set of AUTOPR values to a file,
> give that to another development team in the handover, or test, or
> whomever,
> who can then import and build packages with the same version/name
> (assuming that they're on another site or otherwise don't have access to
> my PR
> network service ). I can see that will obviate the need for an
> inordinate number of conversations with the test team.

Ah yes, I completely forgot about that.

The thought springs to mind that if we're not covering this area sufficiently in 
the manual at the moment, we should probably try to figure out what we need to 
do to do so.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [meta-mono] [PATCH 1/1] gtk-sharp: Updated to GTK# 2.12.21

[Alex J Lennon]

On 27/02/2014 22:04, Paul Eggleton wrote:
> On Thursday 27 February 2014 19:15:38 Alex J Lennon wrote:
>> On 27/02/2014 18:48, Paul Eggleton wrote:
>>> On Thursday 27 February 2014 18:29:59 Alex J Lennon wrote:
>>>> On 27/02/2014 18:18, Paul Eggleton wrote:
>>>>> PR values needn't match up between different distros. The point is they
>>>>> should get increased when a material change to the recipe's output
>>>>> happens; and this can happen for example when:
>>>>>
>>>>> * A class that the recipe inherits is changed
>>>>>
>>>>> * A dependency of the recipe that influences how the recipe is built
>>>>> gets
>>>>> changed
>>>>>
>>>>> * Some global configuration changed that affects how the recipe is built
>>>>> e.g. DISTRO_FEATURES
>>>>>
>>>>> * A bbappend is added or removed
>>>>>
>>>>> In all of these cases the recipe itself does not get changed at all -
>>>>> prior to the PR server we had to remember to manually bump PR in the
>>>>> affected recipes, or (more often) we'd forget to handle it properly
>>>>> altogether. With the PR server, PR bumps happen automatically in
>>>>> response
>>>>> to signatures changing, which is about as accurate an indicator as we
>>>>> can
>>>>> get as far as determining whether the output has changed, and certainly
>>>>> much less prone to mistakes.
>>>> OK so I can't download the source code to a distribution and built
>>>> identical, identically versioned packages to theirs? With something like
>>>> RPM wouldn't I expect to be able to download an RPM source package
>>>> and build an identical, versioned RPM from it?
>>> They'll always be "identical" as far as the material content goes, that's
>>> not in question here - we're just talking about the PR values. For the PR
>>> values it depends - which distro are we talking about? IIRC for example,
>>> SHR and Angstrom both make their PR servers available so that people's PR
>>> values will match up if they build it from source themselves.
>>>
>>> However, I think we're starting to head into territory where you have to
>>> ask who is maintaining this distro you are referring to. If you're making
>>> changes to how things get built, arguably it's now a derivative distro
>>> and you ought to be maintaining it yourself; at which point you shouldn't
>>> expect the PR values to match up. How else would you signify that you'd
>>> made the configuration change (or added your own patch, or ...) if it's
>>> someone else's distro that doesn't contain that change "upstream"?
>>>
>>>> Taking a slightly different tack, if I upgrade a recipe PV from 1.0.0 to
>>>> 2.0.0 to correspond to the upstream source versioning, and at that
>>>> time I remove PR and build some packages.
>>>>
>>>> Then a month later I realise I need something extra added to the
>>>> configuration options, which gives me a different output, what do I
>>>> change to make sure the new package is versioned differently from
>>>> the old package? (i.e. presumably if the network service is
>>>> running it will handle it for me, but if it's not running then new
>>>> package will be versioned identically to my old package?)
>>> Yes. If you care about PR values (i.e. you're using packaging on the
>>> target) then you need to enable and use the PR server. If you do that,
>>> you don't need to make any additional change other than the
>>> configure option change you've already made - EXTRA_OECONF
>>> would presumably have been changed -> do_configure signature
>>> changes -> dependent task signatures change -> the PR value
>>> changes automatically.
>>>
>>>>>> I suppose the other question is, if I release a package of revision X,
>>>>>> then another which is up-rev'd' to Y as I made a change to the recipe
>>>>>> and so the NBPRS up-revs, then somebody comes back to me and tells me
>>>>>> they are having a problem with Xm then how do I link that rev X to the
>>>>>> specific commit that went to build it so I can audit ?
>>>>> The PR server doesn't track this - however, all of this information does
>>>>> go into buildhistory if you enable that.
>>>> Must look at that, yes.
>>> For reference:
>>>
>>> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#mainta
>>> ining-build-output-quality
>>>
>>> Cheers,
>>> Paul
>> I've just noticed this which seems to usefully address some of my
>> questions; include for others who may come across the thread,
>>
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1556
>>
>> Excellent. So I can export my current set of AUTOPR values to a file,
>> give that to another development team in the handover, or test, or
>> whomever,
>> who can then import and build packages with the same version/name
>> (assuming that they're on another site or otherwise don't have access to
>> my PR
>> network service ). I can see that will obviate the need for an
>> inordinate number of conversations with the test team.
> Ah yes, I completely forgot about that.
>
> The thought springs to mind that if we're not covering this area sufficiently in 
> the manual at the moment, we should probably try to figure out what we need to 
> do to do so.

Well it could of course be me being backward or lazy :) It seems pretty
imorptant though, to a newbie
like myself, as in my work I generally rely on a versioned file name
being a unique descriptor for a certain
snapshot of a binary codebase, whether .exe, archive or whatever.

I get a bit antsie when I can't relate a shipped binary of a given
versioning scheme to a source snapshot that
I can use to rebuild that shipped binary, as this type of thing always
comes back to bite me months or years
later.

I try hard to have a single versioned name that the whole supply chain
can use to relate to a certain
software module. It worries me (perhaps unduly I admit) that there's
additional complexity in this process,
when I'm undoubtedly going to have to explain at length why certain
parts of a file name/archive matter, and certain
other ones don't.

That aside, as I understand it this is a solution to another wider
problem which is the maintenance of those
PRs in the recipes so perhaps it is the lesser evil. Who am I to say?

If it's necessary to have the daemon active to handle bumping PRs, and
if the direction is to remove hardcoded PRs
then perhaps it merits the daemon being automatically launched via a
default local.conf as per #1126 and something
in the newbie guide about why this is?

Cheers, Alex