[Buildroot] [PATCH 1/3] vala: add vala/valac wrapper

[Buildroot] [PATCH 1/3] vala: add vala/valac wrapper

[Gustavo Zacarias]

vala/valac can use gir and vapi data files installed by other packages,
but since these are normally installed to staging and host-vala looks
for them in the host directory (logically) this leads to failure.
So wrap them to call the real tool and add this information via
command-line parameters to them.

This is required for libgee-granite vala-in-vala bindings.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 package/vala/vala-wrapper |  2 ++
 package/vala/vala.mk      | 18 ++++++++++++++++++
 2 files changed, 20 insertions(+)
 create mode 100644 package/vala/vala-wrapper

diff --git a/package/vala/vala-wrapper b/package/vala/vala-wrapper
new file mode 100644
index 0000000..ea0bd09
--- /dev/null
+++ b/package/vala/vala-wrapper
@@ -0,0 +1,2 @@
+#!/bin/sh
+$0- at VALA_VERSION@ --vapidir=@STAGING_DIR@/usr/share/vala/vapi --girdir=@STAGING_DIR@/usr/share/gir-1.0 $@
diff --git a/package/vala/vala.mk b/package/vala/vala.mk
index 56d4db3..5267f68 100644
--- a/package/vala/vala.mk
+++ b/package/vala/vala.mk
@@ -16,4 +16,22 @@ HOST_VALA_DEPENDENCIES = host-bison host-flex host-libglib2
 # available".
 HOST_VALA_CONF_ENV = ac_cv_path_XSLTPROC=:
 
+# We wrap vala & valac to point to the proper gir and vapi data dirs
+# Otherwise we'll get host directory data which isn't enough
+define HOST_VALA_INSTALL_WRAPPER
+	$(INSTALL) -D -m 0755 package/vala/vala-wrapper \
+		$(HOST_DIR)/usr/bin/vala
+	$(INSTALL) -D -m 0755 package/vala/vala-wrapper \
+		$(HOST_DIR)/usr/bin/valac
+	$(SED) 's, at VALA_VERSION@,$(VALA_VERSION_MAJOR),' \
+		$(HOST_DIR)/usr/bin/vala
+	$(SED) 's, at STAGING_DIR@,$(STAGING_DIR),g' \
+		$(HOST_DIR)/usr/bin/vala
+	$(SED) 's, at VALA_VERSION@,$(VALA_VERSION_MAJOR),' \
+		$(HOST_DIR)/usr/bin/valac
+	$(SED) 's, at STAGING_DIR@,$(STAGING_DIR),g' \
+		$(HOST_DIR)/usr/bin/valac
+endef
+HOST_VALA_POST_INSTALL_HOOKS += HOST_VALA_INSTALL_WRAPPER
+
 $(eval $(host-autotools-package))
-- 
2.4.10

[Buildroot] [PATCH 2/3] libgee: new package

[Gustavo Zacarias]

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 package/Config.in          |  1 +
 package/libgee/Config.in   | 15 +++++++++++++++
 package/libgee/libgee.hash |  2 ++
 package/libgee/libgee.mk   | 16 ++++++++++++++++
 4 files changed, 34 insertions(+)
 create mode 100644 package/libgee/Config.in
 create mode 100644 package/libgee/libgee.hash
 create mode 100644 package/libgee/libgee.mk

diff --git a/package/Config.in b/package/Config.in
index c087ff1..cd64613 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -1178,6 +1178,7 @@ menu "Other"
 	source "package/libevdev/Config.in"
 	source "package/libevent/Config.in"
 	source "package/libffi/Config.in"
+	source "package/libgee/Config.in"
 	source "package/libglib2/Config.in"
 	source "package/libical/Config.in"
 	source "package/liblinear/Config.in"
diff --git a/package/libgee/Config.in b/package/libgee/Config.in
new file mode 100644
index 0000000..07c387c
--- /dev/null
+++ b/package/libgee/Config.in
@@ -0,0 +1,15 @@
+config BR2_PACKAGE_LIBGEE
+	bool "libgee"
+	depends on BR2_USE_WCHAR
+	depends on BR2_TOOLCHAIN_HAS_THREADS
+	depends on BR2_USE_MMU # fork()
+	select BR2_PACKAGE_LIBGLIB2
+	help
+	  Libgee is an utility library providing GObject-based
+	  interfaces and classes for commonly used data structures.
+
+	  https://wiki.gnome.org/Projects/Libgee
+
+comment "libgee needs a toolchain w/ wchar, threads"
+	depends on BR2_USE_MMU
+	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/libgee/libgee.hash b/package/libgee/libgee.hash
new file mode 100644
index 0000000..4c38c78
--- /dev/null
+++ b/package/libgee/libgee.hash
@@ -0,0 +1,2 @@
+# From http://ftp.acc.umu.se/pub/gnome/sources/libgee/0.18/libgee-0.18.0.sha256sum
+sha256	4ad99ef937d071b4883c061df40bfe233f7649d50c354cf81235f180b4244399	libgee-0.18.0.tar.xz
diff --git a/package/libgee/libgee.mk b/package/libgee/libgee.mk
new file mode 100644
index 0000000..1df322c
--- /dev/null
+++ b/package/libgee/libgee.mk
@@ -0,0 +1,16 @@
+################################################################################
+#
+# libgee
+#
+################################################################################
+
+LIBGEE_VERSION_MAJOR = 0.18
+LIBGEE_VERSION = $(LIBGEE_VERSION_MAJOR).0
+LIBGEE_SITE = http://ftp.gnome.org/pub/gnome/sources/libgee/$(LIBGEE_VERSION_MAJOR)
+LIBGEE_SOURCE = libgee-$(LIBGEE_VERSION).tar.xz
+LIBGEE_DEPENDENCIES = host-pkgconf host-vala libglib2
+LIBGEE_INSTALL_STAGING = YES
+LIBGEE_LICENSE = LGPLv2.1+
+LIBGEE_LICENSE_FILES = COPYING
+
+$(eval $(autotools-package))
-- 
2.4.10

[Buildroot] [PATCH 3/3] granite: new package

[Gustavo Zacarias]

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 package/Config.in            |  1 +
 package/granite/Config.in    | 18 ++++++++++++++++++
 package/granite/granite.hash |  4 ++++
 package/granite/granite.mk   | 16 ++++++++++++++++
 4 files changed, 39 insertions(+)
 create mode 100644 package/granite/Config.in
 create mode 100644 package/granite/granite.hash
 create mode 100644 package/granite/granite.mk

diff --git a/package/Config.in b/package/Config.in
index cd64613..3c1f4f0 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -855,6 +855,7 @@ menu "Graphics"
 	source "package/gdk-pixbuf/Config.in"
 	source "package/giblib/Config.in"
 	source "package/giflib/Config.in"
+	source "package/granite/Config.in"
 	source "package/graphite2/Config.in"
 	source "package/gtkmm3/Config.in"
 	source "package/harfbuzz/Config.in"
diff --git a/package/granite/Config.in b/package/granite/Config.in
new file mode 100644
index 0000000..fef5e27
--- /dev/null
+++ b/package/granite/Config.in
@@ -0,0 +1,18 @@
+config BR2_PACKAGE_GRANITE
+	bool "granite"
+	depends on BR2_USE_WCHAR
+	depends on BR2_TOOLCHAIN_HAS_THREADS
+	depends on BR2_USE_MMU # fork()
+	depends on BR2_PACKAGE_LIBGTK3
+	select BR2_PACKAGE_LIBGEE
+	select BR2_PACKAGE_LIBGLIB2
+	help
+	  An extension to GTK+ that provides several useful widgets and
+	  classes to ease application development.
+
+	  https://launchpad.net/granite
+
+comment "granite needs libgtk3 and a toolchain w/ wchar, threads"
+	depends on BR2_USE_MMU
+	depends on !BR2_PACKAGE_LIBGTK3 || !BR2_USE_WCHAR \
+		|| !BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/granite/granite.hash b/package/granite/granite.hash
new file mode 100644
index 0000000..5ce95e6
--- /dev/null
+++ b/package/granite/granite.hash
@@ -0,0 +1,4 @@
+# From https://launchpad.net/granite/0.3/0.3.1/+download/granite-0.3.1.tar.xz/+md5
+md5	4297d4fcec8cfe2e08b460a45c779bbe	granite-0.3.1.tar.xz
+# Calculated based on the hash above
+sha256	8ec1d61f9aba75f1b3a745e721288b0dfb34cb11d1307be80cef7b0571c2dec6	granite-0.3.1.tar.xz
diff --git a/package/granite/granite.mk b/package/granite/granite.mk
new file mode 100644
index 0000000..dd5a09e
--- /dev/null
+++ b/package/granite/granite.mk
@@ -0,0 +1,16 @@
+################################################################################
+#
+# granite
+#
+################################################################################
+
+GRANITE_VERSION_MAJOR = 0.3
+GRANITE_VERSION = $(GRANITE_VERSION_MAJOR).1
+GRANITE_SITE = https://launchpad.net/granite/$(GRANITE_VERSION_MAJOR)/$(GRANITE_VERSION)/+download
+GRANITE_SOURCE = granite-$(GRANITE_VERSION).tar.xz
+GRANITE_DEPENDENCIES = host-pkgconf host-vala libgee libglib2 libgtk3
+GRANITE_INSTALL_STAGING = YES
+GRANITE_LICENSE = LGPLv3+
+GRANITE_LICENSE_FILES = COPYING
+
+$(eval $(cmake-package))
-- 
2.4.10

[Buildroot] [PATCH 1/3] vala: add vala/valac wrapper

[Thomas Petazzoni]

Gustavo,

On Tue,  2 Feb 2016 13:01:46 -0300, Gustavo Zacarias wrote:

> +# We wrap vala & valac to point to the proper gir and vapi data dirs
> +# Otherwise we'll get host directory data which isn't enough
> +define HOST_VALA_INSTALL_WRAPPER
> +	$(INSTALL) -D -m 0755 package/vala/vala-wrapper \
> +		$(HOST_DIR)/usr/bin/vala
> +	$(INSTALL) -D -m 0755 package/vala/vala-wrapper \
> +		$(HOST_DIR)/usr/bin/valac
> +	$(SED) 's, at VALA_VERSION@,$(VALA_VERSION_MAJOR),' \
> +		$(HOST_DIR)/usr/bin/vala
> +	$(SED) 's, at STAGING_DIR@,$(STAGING_DIR),g' \
> +		$(HOST_DIR)/usr/bin/vala
> +	$(SED) 's, at VALA_VERSION@,$(VALA_VERSION_MAJOR),' \
> +		$(HOST_DIR)/usr/bin/valac
> +	$(SED) 's, at STAGING_DIR@,$(STAGING_DIR),g' \
> +		$(HOST_DIR)/usr/bin/valac
> +endef
> +HOST_VALA_POST_INSTALL_HOOKS += HOST_VALA_INSTALL_WRAPPER

So if I understand correctly, the idea is to replace the vala ->
vala-3.0 and valac -> valac-3.0 symbolic links by wrappers.

So I did a test, first without your patch, with a stupid vala hello
world program:

thomas at skate:~/projets/buildroot (next)$ cat > pouet.vala
class Demo.HelloWorld : GLib.Object {

    public static int main(string[] args) {

        stdout.printf("Hello, World\n");

        return 0;
    }
}
thomas at skate:~/projets/buildroot (next)$ ./output/host/usr/bin/vala pouet.vala 
Hello, World
thomas at skate:~/projets/buildroot (next)$ ./output/host/usr/bin/valac pouet.vala 
thomas at skate:~/projets/buildroot (next)$ file pouet
pouet: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=d13ab11a4b8d24623f8ead3e8e3c1c9e73d16df0, not stripped

So, the program runs fine on the host with "vala", and compiles to a
x86-64 executable. Not really surprising since it's a host-vala
installation not tuned for cross-compilation.

Then, I apply your patch, rebuild host-vala, and do the same test:

thomas at skate:~/projets/buildroot (next)$ ./output/host/usr/bin/vala pouet.vala 
error: --girdir=/home/thomas/projets/buildroot/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/share/gir-1.0 not found

What package is supposed to install gir-1.0 in staging ?

thomas at skate:~/projets/buildroot (next)$ ./output/host/usr/bin/valac pouet.vala 
thomas at skate:~/projets/buildroot (next)$ file pouet
pouet: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=d13ab11a4b8d24623f8ead3e8e3c1c9e73d16df0, not stripped

But it still compiles to a host binary. Am I missing something ?

Could you improve the commit log with more explanations for people
(like me) who don't know vala, and don't understand what your patch is
fixing exactly ?

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 1/3] vala: add vala/valac wrapper

[Gustavo Zacarias]

On 21/02/16 18:28, Thomas Petazzoni wrote:

> So if I understand correctly, the idea is to replace the vala ->
> vala-3.0 and valac -> valac-3.0 symbolic links by wrappers.

Hi, yes.

> So I did a test, first without your patch, with a stupid vala hello
> world program:
>
> thomas at skate:~/projets/buildroot (next)$ cat > pouet.vala
> class Demo.HelloWorld : GLib.Object {
>
>      public static int main(string[] args) {
>
>          stdout.printf("Hello, World\n");
>
>          return 0;
>      }
> }
> thomas at skate:~/projets/buildroot (next)$ ./output/host/usr/bin/vala pouet.vala
> Hello, World
> thomas at skate:~/projets/buildroot (next)$ ./output/host/usr/bin/valac pouet.vala
> thomas at skate:~/projets/buildroot (next)$ file pouet
> pouet: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=d13ab11a4b8d24623f8ead3e8e3c1c9e73d16df0, not stripped
>
> So, the program runs fine on the host with "vala", and compiles to a
> x86-64 executable. Not really surprising since it's a host-vala
> installation not tuned for cross-compilation.
>
> Then, I apply your patch, rebuild host-vala, and do the same test:
>
> thomas at skate:~/projets/buildroot (next)$ ./output/host/usr/bin/vala pouet.vala
> error: --girdir=/home/thomas/projets/buildroot/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/share/gir-1.0 not found
>
> What package is supposed to install gir-1.0 in staging ?

vala isn't normally used, only valac & vapigen are, so your usage 
doesn't mirror reality with packages that we currently ship.
IIRC "vala" is a deprecated form of invocation from several years ago, 
still kept for compatibility purposes.
And valac doesn't mind if the directory isn't present.
That being said, gir-1.0 comes from enabling gobject-introspection which 
i have as a WIP patchset but haven't submitted yet.
I've tested this patchset and it doesn't break our current host-vala 
using packages.

> thomas at skate:~/projets/buildroot (next)$ ./output/host/usr/bin/valac pouet.vala
> thomas at skate:~/projets/buildroot (next)$ file pouet
> pouet: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=d13ab11a4b8d24623f8ead3e8e3c1c9e73d16df0, not stripped
>
> But it still compiles to a host binary. Am I missing something ?

Yes, you need to pass full build env variables (CC & friends) to it, it 
doesn't work magically.

> Could you improve the commit log with more explanations for people
> (like me) who don't know vala, and don't understand what your patch is
> fixing exactly ?

It's part of the webkitgtk/midori major bump, which depends on libgtk3, 
which depends on libepoxy patching outside x11r7, which depends on these 
as well.
And, by the way, the webkitgtk bump accounts for like 40+ security bugs 
from http://webkitgtk.org/security/WSA-2015-0002.html
And there are no plans to backport those to 2.4.x
Currently i've got the 2.10.x (the latest stable branch) patchset cooked 
up, and 2.12.x is coming soon - we're 3 major releases behind.
What this solves is pretty simple, if you try to build a vala app (like 
midori) which uses vala bindings (vapi) from others it will fail, 
miserably, because it can't find them (they're in staging, and host-vala 
as it is will search for them in the host dir -> not found -> boom).
Like this:

-----
make[3]: Entering directory 
'/home/gustavoz/b/midori.wayland/output/build/midori-0.5.11'
error: [  1%] Generating nn.gmo
Package make[3]: Leaving directory 
'/home/gustavoz/b/midori.wayland/output/build/midori-0.5.11'
`granite' not found in specified Vala API directories or 
GObject-Introspection GIR directories
-----

We haven't seen this because the only applications in buildroot that use 
vala, gmpc and midori (not bumped) don't use vala bindings.
But for the midori bump granite is highly recommended (building without 
it is likely going away for the next release), hence i've added libgee 
and granite which are prereqs for usability/friendlyness.

The thing is keeping all of this split is quite an amount of work, 
keeping in sync/rebasing against master and so on.
I've been sending what most i could in split sets to keep gtk3, wayland 
and webkitgtk going forward in a reasonable way.
However my patience is wearing quite thin and i'm very tempted to just 
let everything stale, we're about to ship another release with 
non-existant gtk3-wayland support again, a feature that was working just 
fine a few releases ago.

Heck, now that i remember not even the webkitgtk24 patches in patchwork 
are in the release/tree, and the multimedia one fixes autobuilder 
failures with the new dep checking (Peter pointed me to it on IRC), 
besides making life terribly easier for people wanting the video/audio 
features without hunting for many gstreamer options.
The rpi one also fixes and autobuilder failure, why do i care again?

Also if anybody is fool enough to think qt webkit is in better shape 
better read:
https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/
...and sleep on it.

Regards.

[Buildroot] [PATCH 1/3] vala: add vala/valac wrapper

[Arnout Vandecappelle]

 Hi Gustavo,

On 02/22/16 02:22, Gustavo Zacarias wrote:
> The thing is keeping all of this split is quite an amount of work, keeping in
> sync/rebasing against master and so on.

 I can imagine!

> I've been sending what most i could in split sets to keep gtk3, wayland and
> webkitgtk going forward in a reasonable way.

 Sounds like a good idea.

> However my patience is wearing quite thin and i'm very tempted to just let
> everything stale, we're about to ship another release with non-existant
> gtk3-wayland support again, a feature that was working just fine a few releases
> ago.

 I'm not sure what your message is here. Do you mean that it's problematic that
we have 291 patches left in patchwork, just after Thomas did about 70 commits? I
think we all agree on that, so if you have a solution, please let us know. Or do
you mean that we should just apply your patches without review? Or are you
complaining that of the 365 patches you submitted since 2015.11, only 338 were
merged up to now?


 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 1/3] vala: add vala/valac wrapper

[Arnout Vandecappelle]

On 02/02/16 17:01, Gustavo Zacarias wrote:
> vala/valac can use gir and vapi data files installed by other packages,
> but since these are normally installed to staging and host-vala looks
> for them in the host directory (logically) this leads to failure.
> So wrap them to call the real tool and add this information via
> command-line parameters to them.
> 
> This is required for libgee-granite vala-in-vala bindings.
> 
> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
> ---
>  package/vala/vala-wrapper |  2 ++
>  package/vala/vala.mk      | 18 ++++++++++++++++++
>  2 files changed, 20 insertions(+)
>  create mode 100644 package/vala/vala-wrapper
> 
> diff --git a/package/vala/vala-wrapper b/package/vala/vala-wrapper
> new file mode 100644
> index 0000000..ea0bd09
> --- /dev/null
> +++ b/package/vala/vala-wrapper
> @@ -0,0 +1,2 @@
> +#!/bin/sh
> +$0- at VALA_VERSION@ --vapidir=@STAGING_DIR@/usr/share/vala/vapi --girdir=@STAGING_DIR@/usr/share/gir-1.0 $@

 This makes it non-relocatable. Instead, just use the ${STAGING_DIR} that is
passed in the environment. That means you can't use vala/c outside of buildroot,
but I don't think that's an issue, right?

> diff --git a/package/vala/vala.mk b/package/vala/vala.mk
> index 56d4db3..5267f68 100644
> --- a/package/vala/vala.mk
> +++ b/package/vala/vala.mk
> @@ -16,4 +16,22 @@ HOST_VALA_DEPENDENCIES = host-bison host-flex host-libglib2
>  # available".
>  HOST_VALA_CONF_ENV = ac_cv_path_XSLTPROC=:
>  
> +# We wrap vala & valac to point to the proper gir and vapi data dirs
> +# Otherwise we'll get host directory data which isn't enough
> +define HOST_VALA_INSTALL_WRAPPER
> +	$(INSTALL) -D -m 0755 package/vala/vala-wrapper \
> +		$(HOST_DIR)/usr/bin/vala
> +	$(INSTALL) -D -m 0755 package/vala/vala-wrapper \
> +		$(HOST_DIR)/usr/bin/valac
> +	$(SED) 's, at VALA_VERSION@,$(VALA_VERSION_MAJOR),' \
> +		$(HOST_DIR)/usr/bin/vala
> +	$(SED) 's, at STAGING_DIR@,$(STAGING_DIR),g' \
> +		$(HOST_DIR)/usr/bin/vala
> +	$(SED) 's, at VALA_VERSION@,$(VALA_VERSION_MAJOR),' \
> +		$(HOST_DIR)/usr/bin/valac

 I would handle vala and valac in a singel SED line.

 Regards,
 Arnout

> +	$(SED) 's, at STAGING_DIR@,$(STAGING_DIR),g' \
> +		$(HOST_DIR)/usr/bin/valac
> +endef
> +HOST_VALA_POST_INSTALL_HOOKS += HOST_VALA_INSTALL_WRAPPER
> +
>  $(eval $(host-autotools-package))
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 1/3] vala: add vala/valac wrapper

[Gustavo Zacarias]

On 22/02/16 20:47, Arnout Vandecappelle wrote:

>   Hi Gustavo,

Hi.

>> However my patience is wearing quite thin and i'm very tempted to just let
>> everything stale, we're about to ship another release with non-existant
>> gtk3-wayland support again, a feature that was working just fine a few releases
>> ago.
>
>   I'm not sure what your message is here. Do you mean that it's problematic that
> we have 291 patches left in patchwork, just after Thomas did about 70 commits? I
> think we all agree on that, so if you have a solution, please let us know. Or do
> you mean that we should just apply your patches without review? Or are you
> complaining that of the 365 patches you submitted since 2015.11, only 338 were
> merged up to now?

I was asked to step in and maintain webkitgtk, gtk3 & accesory packages.
And this has been sitting in patchwork for quite some time with no 
comments or anything and rotting down (this = the gtk3 bump and other 
pieces that depend on it).
It means i'll just take is as there's no interest and just leave it rot 
completely - i didn't pick this up because it's something i use or have 
any particular interest in.
If you're implying i don't help in other aspects and i just care about 
what i send i suggest you take a look at lots of autobuilder fixes for 
packages i never use.
Regards.

[Buildroot] [PATCH 1/3] vala: add vala/valac wrapper

[Gustavo Zacarias]

On 22/02/16 20:48, Arnout Vandecappelle wrote:

>> +#!/bin/sh
>> +$0- at VALA_VERSION@ --vapidir=@STAGING_DIR@/usr/share/vala/vapi --girdir=@STAGING_DIR@/usr/share/gir-1.0 $@
>
>   This makes it non-relocatable. Instead, just use the ${STAGING_DIR} that is
> passed in the environment. That means you can't use vala/c outside of buildroot,
> but I don't think that's an issue, right?

Hi.
Not more so than the pkg-config wrapper or the toolchain wrapper, which 
i can bet is more used/important than this one.
Regards.

[Buildroot] [PATCH 1/3] vala: add vala/valac wrapper

[Arnout Vandecappelle]

On 02/23/16 01:27, Gustavo Zacarias wrote:
> On 22/02/16 20:48, Arnout Vandecappelle wrote:
>
> >> +#!/bin/sh
> >> +$0- at VALA_VERSION@ --vapidir=@STAGING_DIR@/usr/share/vala/vapi
> >> --girdir=@STAGING_DIR@/usr/share/gir-1.0 $@
> >
> >   This makes it non-relocatable. Instead, just use the ${STAGING_DIR} that is
> > passed in the environment. That means you can't use vala/c outside of buildroot,
> > but I don't think that's an issue, right?
>
> Hi.
> Not more so than the pkg-config wrapper or the toolchain wrapper, which i can
> bet is more used/important than this one.

 Both of which should be fixed as well. But let's try to avoid adding more
non-relocatable stuff, when possible and easy.

 Regards,
 Arnout

-- 
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 1/3] vala: add vala/valac wrapper

[Arnout Vandecappelle]

On 02/23/16 01:18, Gustavo Zacarias wrote:
> On 22/02/16 20:47, Arnout Vandecappelle wrote:
> 
>>   Hi Gustavo,
> 
> Hi.
> 
>>> However my patience is wearing quite thin and i'm very tempted to just let
>>> everything stale, we're about to ship another release with non-existant
>>> gtk3-wayland support again, a feature that was working just fine a few releases
>>> ago.
>>
>>   I'm not sure what your message is here. Do you mean that it's problematic that
>> we have 291 patches left in patchwork, just after Thomas did about 70 commits? I
>> think we all agree on that, so if you have a solution, please let us know. Or do
>> you mean that we should just apply your patches without review? Or are you
>> complaining that of the 365 patches you submitted since 2015.11, only 338 were
>> merged up to now?
> 
> I was asked to step in and maintain webkitgtk, gtk3 & accesory packages.
> And this has been sitting in patchwork for quite some time with no comments or
> anything and rotting down (this = the gtk3 bump and other pieces that depend on
> it).
> It means i'll just take is as there's no interest and just leave it rot
> completely - i didn't pick this up because it's something i use or have any
> particular interest in.

 I think you should take it as: between the 291 - sorry, 300 by now - other
patches, this series has been overlooked. Again, if you have ideas that can help
to reduce the backlog from 300 to, say, 30: everybody will be glad to hear it!
Well, except if your idea is to stop sending patches of course.

> If you're implying i don't help in other aspects and i just care about what i
> send i suggest you take a look at lots of autobuilder fixes for packages i never
> use.

 That's why I mentioned that 92% of the patches you submitted have already been
applied. The other buildroot contributors really appreciate the work you do. And
share your frustration that too many patches tend to linger, and need to be
rebased all the time. In fact, Thomas and Peter have the additional frustration
that all of their time is taken up by applying other people's patches, leaving
no time to work on their own ideas.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 1/3] vala: add vala/valac wrapper

[Gustavo Zacarias]

On 22/02/16 21:40, Arnout Vandecappelle wrote:

>> If you're implying i don't help in other aspects and i just care about what i
>> send i suggest you take a look at lots of autobuilder fixes for packages i never
>> use.
>
>   That's why I mentioned that 92% of the patches you submitted have already been
> applied. The other buildroot contributors really appreciate the work you do. And
> share your frustration that too many patches tend to linger, and need to be
> rebased all the time. In fact, Thomas and Peter have the additional frustration
> that all of their time is taken up by applying other people's patches, leaving
> no time to work on their own ideas.

Oh come on, you're smarter than that: most of my merged patches are trivial.
That's the consequence of let's call them "big series" lingering on 
forever - it really demotivates to work on anything groundbreaking since 
you've gotta rebase forever to keep them sane on top of other changes 
with nothing happening to it.
How about relinquising some control? Add a new committer, maybe Yann, 
yourself or some other trusted volunteer, that way the new committer(s) 
can clean up the simple queue and leave the more contentious series for 
the more experienced ones. Maybe put on some simple ground rules like 
don't commit your own stuff and so on.
They will make mistakes, sure, but then everybody does and both Peter & 
Thomas will get some free time for their particular interests.
Otherwise we end up with these emails that make a lot of noise and then 
everything cools down and nothing changes, the scaling remains at the 
same sucklevel.
It's not a life-forever thing, if it doesn't work then try some other 
thing, but if there's no trying for some new approach evidently nothing 
will change no matter how much you push for new blood, reviews, tested 
and acks.
Regards.

[Buildroot] [PATCH 1/3] vala: add vala/valac wrapper

[Thomas Petazzoni]

Hello Gustavo,

On Mon, 22 Feb 2016 21:18:15 -0300, Gustavo Zacarias wrote:

> I was asked to step in and maintain webkitgtk, gtk3 & accesory packages.
> And this has been sitting in patchwork for quite some time with no 
> comments or anything and rotting down (this = the gtk3 bump and other 
> pieces that depend on it).
> It means i'll just take is as there's no interest and just leave it rot 
> completely - i didn't pick this up because it's something i use or have 
> any particular interest in.
> If you're implying i don't help in other aspects and i just care about 
> what i send i suggest you take a look at lots of autobuilder fixes for 
> packages i never use.

As Arnout said, all our patches are definitely appreciated, and most of
them are applied really quickly. Some of them indeed take more time,
but there's nothing personal against you: we have ~300 other patches
sitting in patchwork.

However, you are almost never helping us by reviewing/testing patches
from others. Due to this, instead of applying your patches, I have to
review and test patches from other contributors. Conclusion: if you
want your patches to be applied faster, the best way is to help the
community by reviewing and testing patches. Your review and test effort
would be really valuable: you are a long-time Buildroot developer, so
you know all the best practices, usual pitfalls and all, which means
that we trust your review.

Thanks a lot!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 1/3] vala: add vala/valac wrapper

[Arnout Vandecappelle]

On 02/23/16 02:06, Gustavo Zacarias wrote:
> How about relinquising some control? Add a new committer, maybe Yann, yourself
> or some other trusted volunteer, that way the new committer(s) can clean up the
> simple queue and leave the more contentious series for the more experienced
> ones. Maybe put on some simple ground rules like don't commit your own stuff and
> so on.

 This could indeed be a good idea. One reason to limit the number of committers
was to avoid conflicts (i.e. two committers working on the same patch in
parallel), but as I understand it, Thomas and Peter noticed that this isn't
really a problem in practice.

 So indeed, having a third person that applies trivial patches could be
worthwhile to try.

 That said, Yann and I are already spending a large part of our buildroot time
on reviewing patches. I don't think that applying them immediately is going to
make that much of a difference.

 Regards,
 Arnout

-- 
Arnout Vandecappelle      arnout dot vandecappelle at essensium dot com
Senior Embedded Software Architect . . . . . . +32-478-010353 (mobile)
Essensium, Mind division . . . . . . . . . . . . . . http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium . . . . . BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 1/3] vala: add vala/valac wrapper

[Thomas Petazzoni]

Hello,

On Tue, 23 Feb 2016 10:42:24 +0100, Arnout Vandecappelle wrote:

>  This could indeed be a good idea. One reason to limit the number of committers
> was to avoid conflicts (i.e. two committers working on the same patch in
> parallel), but as I understand it, Thomas and Peter noticed that this isn't
> really a problem in practice.
> 
>  So indeed, having a third person that applies trivial patches could be
> worthwhile to try.
> 
>  That said, Yann and I are already spending a large part of our buildroot time
> on reviewing patches. I don't think that applying them immediately is going to
> make that much of a difference.

Fully agreed: applying the patch is clearly not what takes time. It's a
mechanical and stupid operation.

What takes time is that when there is no Acked-by/Reviewed-by/Tested-by
from a trusted person and the patch is not obviously trivial, then I
have to go review the patch myself entirely. Download the source code,
check that the license is correct, verify that optional dependencies
are properly handled, build in a few basic situations, etc. All those
steps I skip when there has been some previous A/R/T tags given by
trusted persons.

When I see that Arnout or Yann has started reviewing a specific patch
or patch series, I assume that they will continue to handle the
discussion with the submitter until they give their
Acked-by/Reviewed-by. And therefore, I simply skip that patch or patch
series, and move on to other topics.

So what *really* saves time is people reviewing and testing patches. Of
course, the more "trusted" those persons are, the more valuable this
effort is. Gustavo, you're a person with a high trust, but
unfortunately, you're doing none of this review/testing effort.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 1/3] vala: add vala/valac wrapper

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Hello,
 > On Tue, 23 Feb 2016 10:42:24 +0100, Arnout Vandecappelle wrote:

 >> This could indeed be a good idea. One reason to limit the number of committers
 >> was to avoid conflicts (i.e. two committers working on the same patch in
 >> parallel), but as I understand it, Thomas and Peter noticed that this isn't
 >> really a problem in practice.
 >> 
 >> So indeed, having a third person that applies trivial patches could be
 >> worthwhile to try.
 >> 
 >> That said, Yann and I are already spending a large part of our buildroot time
 >> on reviewing patches. I don't think that applying them immediately is going to
 >> make that much of a difference.

 > Fully agreed: applying the patch is clearly not what takes time. It's a
 > mechanical and stupid operation.

Agreed. I'm all for ways of improving our ways of working, but I don't
think this will change much. Adding Thomas as a co-maintainer has imho
been very good, but adding a 3rd committer without having more reviewers
imho won't make any significant difference.

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [PATCH 1/3] vala: add vala/valac wrapper

[Arnout Vandecappelle]

On 02/23/16 10:48, Thomas Petazzoni wrote:
> Hello,
> 
> On Tue, 23 Feb 2016 10:42:24 +0100, Arnout Vandecappelle wrote:
> 
>>  This could indeed be a good idea. One reason to limit the number of committers
>> was to avoid conflicts (i.e. two committers working on the same patch in
>> parallel), but as I understand it, Thomas and Peter noticed that this isn't
>> really a problem in practice.
>>
>>  So indeed, having a third person that applies trivial patches could be
>> worthwhile to try.
>>
>>  That said, Yann and I are already spending a large part of our buildroot time
>> on reviewing patches. I don't think that applying them immediately is going to
>> make that much of a difference.
> 
> Fully agreed: applying the patch is clearly not what takes time. It's a
> mechanical and stupid operation.
> 
> What takes time is that when there is no Acked-by/Reviewed-by/Tested-by
> from a trusted person and the patch is not obviously trivial, then I
> have to go review the patch myself entirely. Download the source code,
> check that the license is correct, verify that optional dependencies
> are properly handled, build in a few basic situations, etc. All those
> steps I skip when there has been some previous A/R/T tags given by
> trusted persons.
> 
> When I see that Arnout or Yann has started reviewing a specific patch
> or patch series, I assume that they will continue to handle the
> discussion with the submitter until they give their
> Acked-by/Reviewed-by. And therefore, I simply skip that patch or patch
> series, and move on to other topics.
> 
> So what *really* saves time is people reviewing and testing patches. Of
> course, the more "trusted" those persons are, the more valuable this
> effort is. Gustavo, you're a person with a high trust, but
> unfortunately, you're doing none of this review/testing effort.

 There is one indirect gain, however. In case something needs to be fixed up
(not quite the majority but still a significant subset of the patches), then
Yann and I currently just give comments and wait for a v2 of the patch. This
often leads to several iterations. Fixing the patch right away and pushing it
will take less time.

 Regards,
 Arnout

-- 
Arnout Vandecappelle      arnout dot vandecappelle at essensium dot com
Senior Embedded Software Architect . . . . . . +32-478-010353 (mobile)
Essensium, Mind division . . . . . . . . . . . . . . http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium . . . . . BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 1/3] vala: add vala/valac wrapper

[Thomas Petazzoni]

Arnout,

On Tue, 23 Feb 2016 20:43:44 +0100, Arnout Vandecappelle wrote:

> > So what *really* saves time is people reviewing and testing patches. Of
> > course, the more "trusted" those persons are, the more valuable this
> > effort is. Gustavo, you're a person with a high trust, but
> > unfortunately, you're doing none of this review/testing effort.
> 
>  There is one indirect gain, however. In case something needs to be fixed up
> (not quite the majority but still a significant subset of the patches), then
> Yann and I currently just give comments and wait for a v2 of the patch. This
> often leads to several iterations. Fixing the patch right away and pushing it
> will take less time.

This is true. One quick and simple workaround to this issue is that
when you are in such a situation, just pick-up the patch and resend it
for your minor fixes.

Of course, if the minor fix is really super trivial, then just indicate
it in your review, and Peter and I can fix that up. But if the
requested changes are a bit more significant, it does make sense to
resend the patch.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com