* [Buildroot] [PATCH 1/3] vala: add vala/valac wrapper
@ 2016-02-02 16:01 Gustavo Zacarias
2016-02-02 16:01 ` [Buildroot] [PATCH 2/3] libgee: new package Gustavo Zacarias
` (3 more replies)
0 siblings, 4 replies; 18+ messages in thread
From: Gustavo Zacarias @ 2016-02-02 16:01 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply related [flat|nested] 18+ messages in thread* [Buildroot] [PATCH 2/3] libgee: new package 2016-02-02 16:01 [Buildroot] [PATCH 1/3] vala: add vala/valac wrapper Gustavo Zacarias @ 2016-02-02 16:01 ` Gustavo Zacarias 2016-02-02 16:01 ` [Buildroot] [PATCH 3/3] granite: " Gustavo Zacarias ` (2 subsequent siblings) 3 siblings, 0 replies; 18+ messages in thread From: Gustavo Zacarias @ 2016-02-02 16:01 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 3/3] granite: new package 2016-02-02 16:01 [Buildroot] [PATCH 1/3] vala: add vala/valac wrapper Gustavo Zacarias 2016-02-02 16:01 ` [Buildroot] [PATCH 2/3] libgee: new package Gustavo Zacarias @ 2016-02-02 16:01 ` Gustavo Zacarias 2016-02-21 21:28 ` [Buildroot] [PATCH 1/3] vala: add vala/valac wrapper Thomas Petazzoni 2016-02-22 23:48 ` Arnout Vandecappelle 3 siblings, 0 replies; 18+ messages in thread From: Gustavo Zacarias @ 2016-02-02 16:01 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 1/3] vala: add vala/valac wrapper 2016-02-02 16:01 [Buildroot] [PATCH 1/3] vala: add vala/valac wrapper Gustavo Zacarias 2016-02-02 16:01 ` [Buildroot] [PATCH 2/3] libgee: new package Gustavo Zacarias 2016-02-02 16:01 ` [Buildroot] [PATCH 3/3] granite: " Gustavo Zacarias @ 2016-02-21 21:28 ` Thomas Petazzoni 2016-02-22 1:22 ` Gustavo Zacarias 2016-02-22 23:48 ` Arnout Vandecappelle 3 siblings, 1 reply; 18+ messages in thread From: Thomas Petazzoni @ 2016-02-21 21:28 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 1/3] vala: add vala/valac wrapper 2016-02-21 21:28 ` [Buildroot] [PATCH 1/3] vala: add vala/valac wrapper Thomas Petazzoni @ 2016-02-22 1:22 ` Gustavo Zacarias 2016-02-22 23:47 ` Arnout Vandecappelle 0 siblings, 1 reply; 18+ messages in thread From: Gustavo Zacarias @ 2016-02-22 1:22 UTC (permalink / raw) To: buildroot 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 1/3] vala: add vala/valac wrapper 2016-02-22 1:22 ` Gustavo Zacarias @ 2016-02-22 23:47 ` Arnout Vandecappelle 2016-02-23 0:18 ` Gustavo Zacarias 0 siblings, 1 reply; 18+ messages in thread From: Arnout Vandecappelle @ 2016-02-22 23:47 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 1/3] vala: add vala/valac wrapper 2016-02-22 23:47 ` Arnout Vandecappelle @ 2016-02-23 0:18 ` Gustavo Zacarias 2016-02-23 0:40 ` Arnout Vandecappelle 2016-02-23 9:10 ` Thomas Petazzoni 0 siblings, 2 replies; 18+ messages in thread From: Gustavo Zacarias @ 2016-02-23 0:18 UTC (permalink / raw) To: buildroot 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 1/3] vala: add vala/valac wrapper 2016-02-23 0:18 ` Gustavo Zacarias @ 2016-02-23 0:40 ` Arnout Vandecappelle 2016-02-23 1:06 ` Gustavo Zacarias 2016-02-23 9:10 ` Thomas Petazzoni 1 sibling, 1 reply; 18+ messages in thread From: Arnout Vandecappelle @ 2016-02-23 0:40 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 1/3] vala: add vala/valac wrapper 2016-02-23 0:40 ` Arnout Vandecappelle @ 2016-02-23 1:06 ` Gustavo Zacarias 2016-02-23 9:42 ` Arnout Vandecappelle 0 siblings, 1 reply; 18+ messages in thread From: Gustavo Zacarias @ 2016-02-23 1:06 UTC (permalink / raw) To: buildroot 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 1/3] vala: add vala/valac wrapper 2016-02-23 1:06 ` Gustavo Zacarias @ 2016-02-23 9:42 ` Arnout Vandecappelle 2016-02-23 9:48 ` Thomas Petazzoni 0 siblings, 1 reply; 18+ messages in thread From: Arnout Vandecappelle @ 2016-02-23 9:42 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 1/3] vala: add vala/valac wrapper 2016-02-23 9:42 ` Arnout Vandecappelle @ 2016-02-23 9:48 ` Thomas Petazzoni 2016-02-23 15:19 ` Peter Korsgaard 2016-02-23 19:43 ` Arnout Vandecappelle 0 siblings, 2 replies; 18+ messages in thread From: Thomas Petazzoni @ 2016-02-23 9:48 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 1/3] vala: add vala/valac wrapper 2016-02-23 9:48 ` Thomas Petazzoni @ 2016-02-23 15:19 ` Peter Korsgaard 2016-02-23 19:43 ` Arnout Vandecappelle 1 sibling, 0 replies; 18+ messages in thread From: Peter Korsgaard @ 2016-02-23 15:19 UTC (permalink / raw) To: buildroot >>>>> "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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 1/3] vala: add vala/valac wrapper 2016-02-23 9:48 ` Thomas Petazzoni 2016-02-23 15:19 ` Peter Korsgaard @ 2016-02-23 19:43 ` Arnout Vandecappelle 2016-02-23 20:58 ` Thomas Petazzoni 1 sibling, 1 reply; 18+ messages in thread From: Arnout Vandecappelle @ 2016-02-23 19:43 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 1/3] vala: add vala/valac wrapper 2016-02-23 19:43 ` Arnout Vandecappelle @ 2016-02-23 20:58 ` Thomas Petazzoni 0 siblings, 0 replies; 18+ messages in thread From: Thomas Petazzoni @ 2016-02-23 20:58 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 1/3] vala: add vala/valac wrapper 2016-02-23 0:18 ` Gustavo Zacarias 2016-02-23 0:40 ` Arnout Vandecappelle @ 2016-02-23 9:10 ` Thomas Petazzoni 1 sibling, 0 replies; 18+ messages in thread From: Thomas Petazzoni @ 2016-02-23 9:10 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 1/3] vala: add vala/valac wrapper 2016-02-02 16:01 [Buildroot] [PATCH 1/3] vala: add vala/valac wrapper Gustavo Zacarias ` (2 preceding siblings ...) 2016-02-21 21:28 ` [Buildroot] [PATCH 1/3] vala: add vala/valac wrapper Thomas Petazzoni @ 2016-02-22 23:48 ` Arnout Vandecappelle 2016-02-23 0:27 ` Gustavo Zacarias 3 siblings, 1 reply; 18+ messages in thread From: Arnout Vandecappelle @ 2016-02-22 23:48 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 1/3] vala: add vala/valac wrapper 2016-02-22 23:48 ` Arnout Vandecappelle @ 2016-02-23 0:27 ` Gustavo Zacarias 2016-02-23 0:30 ` Arnout Vandecappelle 0 siblings, 1 reply; 18+ messages in thread From: Gustavo Zacarias @ 2016-02-23 0:27 UTC (permalink / raw) To: buildroot 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 1/3] vala: add vala/valac wrapper 2016-02-23 0:27 ` Gustavo Zacarias @ 2016-02-23 0:30 ` Arnout Vandecappelle 0 siblings, 0 replies; 18+ messages in thread From: Arnout Vandecappelle @ 2016-02-23 0:30 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2016-02-23 20:58 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-02-02 16:01 [Buildroot] [PATCH 1/3] vala: add vala/valac wrapper Gustavo Zacarias 2016-02-02 16:01 ` [Buildroot] [PATCH 2/3] libgee: new package Gustavo Zacarias 2016-02-02 16:01 ` [Buildroot] [PATCH 3/3] granite: " Gustavo Zacarias 2016-02-21 21:28 ` [Buildroot] [PATCH 1/3] vala: add vala/valac wrapper Thomas Petazzoni 2016-02-22 1:22 ` Gustavo Zacarias 2016-02-22 23:47 ` Arnout Vandecappelle 2016-02-23 0:18 ` Gustavo Zacarias 2016-02-23 0:40 ` Arnout Vandecappelle 2016-02-23 1:06 ` Gustavo Zacarias 2016-02-23 9:42 ` Arnout Vandecappelle 2016-02-23 9:48 ` Thomas Petazzoni 2016-02-23 15:19 ` Peter Korsgaard 2016-02-23 19:43 ` Arnout Vandecappelle 2016-02-23 20:58 ` Thomas Petazzoni 2016-02-23 9:10 ` Thomas Petazzoni 2016-02-22 23:48 ` Arnout Vandecappelle 2016-02-23 0:27 ` Gustavo Zacarias 2016-02-23 0:30 ` Arnout Vandecappelle
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.