Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/7] docs/manual: update 'adding packages' with the new _AVAILABLE symbol
Date: Thu, 01 Nov 2012 02:30:32 +0100	[thread overview]
Message-ID: <5091D0B8.6050404@mind.be> (raw)
In-Reply-To: <1347234052-10527-2-git-send-email-yann.morin.1998@free.fr>

On 09/10/12 01:40, Yann E. MORIN wrote:
> Signed-off-by: "Yann E. MORIN"<yann.morin.1998@free.fr>
> ---
>   docs/manual/adding-packages-autotools.txt |   48 ++++++--
>   docs/manual/adding-packages-directory.txt |  190 +++++++++++++++--------------
>   docs/manual/adding-packages-generic.txt   |   85 ++++++++-----
>   3 files changed, 191 insertions(+), 132 deletions(-)
>
> diff --git a/docs/manual/adding-packages-autotools.txt b/docs/manual/adding-packages-autotools.txt
> index 9fb0918..0f14489 100644
> --- a/docs/manual/adding-packages-autotools.txt
> +++ b/docs/manual/adding-packages-autotools.txt
> @@ -20,10 +20,24 @@ package, with an example :
>   08: LIBFOO_SITE = http://www.foosoftware.org/download
>   09: LIBFOO_INSTALL_STAGING = YES
>   10: LIBFOO_INSTALL_TARGET = YES
> -11: LIBFOO_CONF_OPT = --enable-shared
> -12: LIBFOO_DEPENDENCIES = libglib2 host-pkg-config
> -13:
> -14: $(eval $(autotools-package))
> +11: LIBFOO_DEPENDENCIES = host-libaaa libbbb

  In the Config.in example, it's libbar, not libbb.

> +12:
> +13: ifeq ($(BR2_PACKAGE_LIBFOO_FROBBLE),y)
> +14: LIBFOO_CONF_OPT += --enable-frobble
> +15: else
> +16: LIBFOO_CONF_OPT += --disable-frobble
> +17: endif
> +18:
> +19: LIBFOO_CONF_OPT += --with-gazzle-level=$(BR2_PACKAGE_LIBFOO_GAZZLE_LEVEL)

  This one is going a bit too far...  And if you keep it, it should
probably have a qstrip.

> +20:
> +21: ifeq ($(BR2_PACKAGE_LIBFOO_GOO),y)
> +22: LIBFOO_DEPENDENCIES += goo
> +23: LIBFOO_CONF_OPT += --enable-goo
> +24: else
> +25: LIBFOO_CONF_OPT += --disable-goo
> +26: endif

  While you're at it, an automatic enable/disable example would
be nice too.

> +27:
> +28: $(eval $(autotools-package))
>   ------------------------
>
>   On line 6, we declare the version of the package.
> @@ -50,16 +64,26 @@ installation is enabled, so in fact, this line is not strictly
>   necessary. Also by default, packages are installed in this location
>   using the +make install+ command.
>
> -On line 11, we tell Buildroot to pass a custom configure option, that
> -will be passed to the +./configure+ script before configuring
> -and building the package.
> +On line 11, we declare our dependencies, so that they are built before the
> +build process of our package starts.
>
> -On line 12, we declare our dependencies, so that they are built
> -before the build process of our package starts.
> +On lines 13 to 17, if the user selected the option 'frobble'
> ++BR2_PACKAGE_LIBFOO_FROBBLE+, we add the corresponding configure option
> +to enable 'frobble' (line 14), or disable it (line 16), that will be
> +passed to the +./configure+ script before configuring and building the
> +package.

  "before configuring and building the package" is redundant.

>
> -Finally, on line line 14, we invoke the +autotools-package+
> -macro that generates all the Makefile rules that actually allows the
> -package to be built.
> +Similarly, on line 19, we add the configure option that defines the
> +'bazzle level' +BR2_PACKAGE_LIBFOO_GAZZLE_LEVEL+.

  bazzle -> gazzle.

> +
> +On lines 21 to 26, if user selected the option 'goo' +BR2_PACKAGE_LIBFOO_GOO+,
> +we add a dependency on the package +goo+ (line 22), and add the corresponding
> +configure option to enable 'goo' (line 23); or if 'goo' support is not
> +selected, we pass the configure option to disable it (line 25).
> +
> +Finally, on line line 28, we invoke the +autotools-package+ macro that
> +generates all the Makefile rules that actually allows the package to be
> +built.
>
>   [[autotools-package-reference]]
>
> diff --git a/docs/manual/adding-packages-directory.txt b/docs/manual/adding-packages-directory.txt
> index 4a96415..4863332 100644
> --- a/docs/manual/adding-packages-directory.txt
> +++ b/docs/manual/adding-packages-directory.txt
> @@ -12,30 +12,37 @@ one of these categories, then create your package directory in these.
>   +Config.in+ file
>   ~~~~~~~~~~~~~~~~
>
> -Then, create a file named +Config.in+. This file will contain the
> -option descriptions related to our +libfoo+ software that will be used
> -and displayed in the configuration tool. It should basically contain:
> +Then, create a file named +Config.in+. This file will contain the option
> +descriptions related to our +libfoo+ software that will be used and
> +displayed in the configuration tool. It should basically contain:
>
>   ---------------------------
> +config BR2_PACKAGE_LIBFOO_AVAILABLE
> +	def_bool y
> +
>   config BR2_PACKAGE_LIBFOO
>   	bool "libfoo"
> +	depends on BR2_PACKAGE_LIBFOO_AVAILABLE
>   	help
>   	  This is a comment that explains what libfoo is.
>
>   	  http://foosoftware.org/libfoo/
>   ---------------------------
>
> -The +bool+ line, +help+ line and other meta-informations about the
> -configuration option must be indented with one tab. The help text
> -itself should be indented with one tab and two spaces, and it must
> -mention the upstream URL of the project.
> +*Notes*
> +
> +* This is a very simple example, not really complete, for a very simple
> +  package with no dependency.
> +
> +* The syntax of the +Config.in+ file is the same as the one for the kernel
> +  Kconfig file. The documentation for this syntax is available at:
> +  https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/kbuild/kconfig-language.txt[]

  http://kernel.org/doc/Documentation/kbuild/kconfig-language.txt

> +
> +* The +bool+ line, +help+ line and other meta-informations about the
> +  configuration option must be indented with one tab. The help text
> +  itself should be indented with one tab and two spaces, and it must
> +  mention the upstream URL of the project.
>
> -Of course, you can add other sub-options into a +if
> -BR2_PACKAGE_LIBFOO...endif+ statement to configure particular things
> -in your software. You can look at examples in other packages. The
> -syntax of the +Config.in+ file is the same as the one for the kernel
> -Kconfig file. The documentation for this syntax is available at
> -http://lxr.free-electrons.com/source/Documentation/kbuild/kconfig-language.txt[]
>
>   Finally you have to add your new +libfoo/Config.in+ to
>   +package/Config.in+ (or in a category subdirectory if you decided to
> @@ -47,103 +54,108 @@ supposed to contain anything but the 'bare' name of the package.
>   source "package/libfoo/Config.in"
>   --------------------------
>
> -The +Config.in+ file of your package must also ensure that
> -dependencies are enabled. Typically, Buildroot uses the following
> -rules:
> +The +Config.in+ file for your package must also ensure that its
> +dependencies are available. This is done in four steps:
>
> -* Use a +select+ type of dependency for dependencies on
> -  libraries. These dependencies are generally not obvious and it
> -  therefore make sense to have the kconfig system ensure that the
> -  dependencies are selected. For example, the _libgtk2_ package uses
> -  +select BR2_PACKAGE_LIBGLIB2+ to make sure this library is also
> -  enabled.
> +1. The +BR2_PACKAGE_LIBFOO_AVAILABLE+ symbol shall +depends on+ any
> +other package's +_AVAILABLE+ symbol. It may also depend on any other
> +symbol, such as toolchain features, but should not directly depend on
> +any package's main symbol.

  ... except for _XORG7, _PYTHON, etc.

>
> -* Use a +depends on+ type of dependency when the user really needs to
> -  be aware of the dependency. Typically, Buildroot uses this type of
> -  dependency for dependencies on toolchain options (large file
> -  support, RPC support, IPV6 support), or for dependencies on "big"
> -  things, such as the X.org system. In some cases, especially
> -  dependency on toolchain options, it is recommended to add a
> -  +comment+ displayed when the option is not enabled, so that the user
> -  knows why the package is not available.
> +1. The main +BR2_PACKAGE_LIBFOO+ symbol should directly +depends
> +on+ it's own +_AVAILABLE+ symbol, +BR2_PACKAGE_LIBFOO_AVAILABLE+, and
> +should not depend on any other symbol.
>
> -An example illustrates both the usage of +select+ and +depends on+.
> +1. For each +_AVAILABLE+ symbol your package's own +_AVAILABLE+
> +symbol depends on, your package's main symbol should +select+ the
> +corresponding package's main symbol.
> +
> +1. Add a +comment+ briefly explaining why your package is not
> +available. That +comment+ shall have a single negative dependency on
> +your package's +_AVAILABLE+ symbol.
> +
> +The example below illustrates this mechanism for our libfoo package:
>
>   --------------------------
> -config BR2_PACKAGE_ACL
> -        bool "acl"
> -        select BR2_PACKAGE_ATTR
> -        depends on BR2_LARGEFILE
> -        help
> -          POSIX Access Control Lists, which are used to define more
> -          fine-grained discretionary access rights for files and
> -          directories.
> -          This package also provides libacl.
> -
> -          http://savannah.nongnu.org/projects/acl
> -
> -comment "acl requires a toolchain with LARGEFILE support"
> -        depends on !BR2_LARGEFILE
> +config BR2_PACKAGE_LIBFOO_AVAILABLE
> +	def_bool y
> +	depends on BR2_LARGEFILE
> +	depends on BR2_PACKAGE_LIBBAR
> +
> +comment "libfoo requires libbar, and a toolchain with support for LARGEFILEs"
> +	depends on !BR2_PACKAGE_LIBFOO_AVAILABLE
> +
> +config BR2_PACKAGE_LIBFOO
> +	bool "libfoo"
> +	depends on BR2_PACKAGE_LIBFOO_AVAILABLE
> +	select BR2_PACKAGE_LIBBAR
> +	help
> +	  This is a comment that explains what libfoo is.
> +
> +	  http://foosoftware.org/libfoo/
>   --------------------------
>
> +*Notes*
> +
> +* Even if your package does not have any dependency, you should anyway
> +  add the corresponding +_AVAILABLE+ symbol. This way, other packages can
> +  safely use the mechanism above to select your package, even if it is later
> +  updated and dependencies are added (eg. a new version of the package is
> +  released; or features, initially disabled, are now enabled...)
> +
> +* The symbols and the comment should be in this order, so that the
> +  +menuconfig+ will be properly laid out.
> +
> +* The dependencies in +Config.in+ will make sure that your package's
> +  dependencies options are also enabled, but they will not necessarily be
> +  built before your package. To do so, these dependencies also need to be
> +  expressed in the +.mk+ file of the package (see below).
>
> -Note that these two dependency types are only transitive with the
> -dependencies of the same kind.
> +If your package can be fine-tuned, you can add sub-options, enclosed inside
> +an +if BR2_PACKAGE_LIBFOO ... endif+ block. You can even have each option
> +depend on other packages, using the +_AVAILABLE+ and main symbols for
> +those pacakges.
>
> -This means, in the following example:
> +Finally, here's our now-complete example package:
>
>   --------------------------
> -config BR2_PACKAGE_A
> -        bool "Package A"
> +config BR2_PACKAGE_LIBFOO_AVAILABLE
> +	def_bool y
> +	depends on BR2_LARGEFILE
> +	depends on BR2_PACKAGE_LIBBAR
>
> -config BR2_PACKAGE_B
> -        bool "Package B"
> -        depends on BR2_PACKAGE_A
> +comment "libfoo requires libbar"

  And largefile.  Copy the comment from above.

> +	depends on !BR2_PACKAGE_LIBFOO_AVAILABLE
>
> -config BR2_PACKAGE_C
> -        bool "Package C"
> -        depends on BR2_PACKAGE_B
> +config BR2_PACKAGE_LIBFOO
> +	bool "libfoo"
> +	depends on BR2_PACKAGE_LIBFOO_AVAILABLE
> +	select BR2_PACKAGE_LIBBAR
> +	help
> +	  This is a comment that explains what libfoo is.
>
> -config BR2_PACKAGE_D
> -        bool "Package D"
> -        select BR2_PACKAGE_B
> +	  http://foosoftware.org/libfoo/
>
> -config BR2_PACKAGE_E
> -        bool "Package E"
> -        select BR2_PACKAGE_D
> ---------------------------
> +if BR2_PACKAGE_LIBFOO
>
> -* Selecting +Package C+ will be visible if +Package B+ has been
> -  selected, which in turn is only visible if +Package A+ has been
> -  selected.
> +config BR2_PACKAGE_LIBFOO_FROBBLE
> +	bool "Frobble the foo"
>
> -* Selecting +Package E+ will select +Package D+, which will select
> -  +Package B+, it will not check for the dependencies of +Package B+,
> -  so it will not select +Package A+.
> +config BR2_PACKAGE_LIBFOO_GAZZLE_LEVEL
> +	int "Gazzle level"
> +	range 0 10

  We currently don't have a single range config option, and only one int.
So the example is a bit contrived...  If you add an extra example, a string
option that is qstripped in the .mk file is more appropriate.

>
> -* Since +Package B+ is selected but +Package A+ is not, this violates
> -  the dependency of +Package B+ on +Package A+.  Therefore, in such a
> -  situation, the transitive dependency has to be added explicitly:
> +comment "goo option requires package goo"
> +	depends on !BR2_PACKAGE_GOO_AVAILABLE
>
> ---------------------------
> -config BR2_PACKAGE_D
> -	bool "Package D"
> -	select BR2_PACKAGE_B
> -	depends on BR2_PACKAGE_A
> -
> -config BR2_PACKAGE_E
> -	bool "Package E"
> -	select BR2_PACKAGE_D
> -	depends on BR2_PACKAGE_A
> ---------------------------
> +config BR2_PACKAGE_LIBFOO_GOO
> +	bool "goo"
> +	depends on BR2_PACKAGE_GOO_AVAILABLE
> +	select BR2_PACKAGE_GOO
>
> -Overall, for package library dependencies, +select+ should be
> -preferred.
> +endif
> +--------------------------
>
> -Note that such dependencies will make sure that the dependency option
> -is also enabled, but not necessarily built before your package. To do
> -so, the dependency also needs to be expressed in the +.mk+ file of the
> -package.
>
>   The +.mk+ file
>   ~~~~~~~~~~~~~~
> diff --git a/docs/manual/adding-packages-generic.txt b/docs/manual/adding-packages-generic.txt
> index d3a4abb..3e4c864 100644
> --- a/docs/manual/adding-packages-generic.txt
> +++ b/docs/manual/adding-packages-generic.txt
> @@ -23,30 +23,45 @@ system is based on hand-written Makefiles or shell scripts.
>   09: LIBFOO_INSTALL_STAGING = YES
>   10: LIBFOO_DEPENDENCIES = host-libaaa libbbb

  libbar

>   11:
> -12: define LIBFOO_BUILD_CMDS
> -13: 	$(MAKE) CC="$(TARGET_CC)" LD="$(TARGET_LD)" -C $(@D) all
> -14: endef
> +12: ifeq ($(BR2_PACKAGE_LIBFOO_FROBBLE),y)
> +13: LIBFOO_CFLAGS += -DFROBBLE
> +14: endif
>   15:
> -16: define LIBFOO_INSTALL_STAGING_CMDS
> -17: 	$(INSTALL) -D -m 0755 $(@D)/libfoo.a $(STAGING_DIR)/usr/lib/libfoo.a
> -18: 	$(INSTALL) -D -m 0644 $(@D)/foo.h $(STAGING_DIR)/usr/include/foo.h
> -19: 	$(INSTALL) -D -m 0755 $(@D)/libfoo.so* $(STAGING_DIR)/usr/lib
> -20: endef
> -21:
> -22: define LIBFOO_INSTALL_TARGET_CMDS
> -23: 	$(INSTALL) -D -m 0755 $(@D)/libfoo.so* $(TARGET_DIR)/usr/lib
> -24: 	$(INSTALL) -d -m 0755 $(TARGET_DIR)/etc/foo.d
> -25: endef
> -26:
> -27: define LIBFOO_DEVICES
> -28: 	/dev/foo  c  666  0  0  42  0  -  -  -
> +16: LIBFOO_CFLAGS += -DGAZZLE_LEVEL=$(BR2_PACKAGE_LIBFOO_GAZZLE_LEVEL)
> +17:
> +18: ifeq ($(BR2_PACKAGE_LIBFOO_GOO),y)
> +19: LIBFOO_DEPENDENCIES += goo
> +20: LIBFOO_CFLAGS       += -DGOO
> +21: LIBFOO_LDFLAGS      += -lgoo
> +22: endif
> +23:
> +24: define LIBFOO_BUILD_CMDS
> +25: 	$(MAKE) -C $(@D)                                        \
> +26: 	        CC="$(TARGET_CC)" CFLAGS="$(LIBFOO_CFLAGS)"     \
> +27: 	        LD="$(TARGET_LD)" LDFLAGS="$(LIBFOO_LDFLAGS)"   \
> +28: 	        all
>   29: endef
>   30:
> -31: define LIBFOO_PERMISSIONS
> -32: 	/bin/foo  f  4755  0  0  -  -  -  -  -
> -33: endef
> -34:
> -35: $(eval $(generic-package))
> +31: define LIBFOO_INSTALL_STAGING_CMDS
> +32: 	$(INSTALL) -D -m 0755 $(@D)/libfoo.a $(STAGING_DIR)/usr/lib/libfoo.a
> +33: 	$(INSTALL) -D -m 0644 $(@D)/foo.h $(STAGING_DIR)/usr/include/foo.h
> +34: 	$(INSTALL) -D -m 0755 $(@D)/libfoo.so* $(STAGING_DIR)/usr/lib
> +35: endef
> +36:
> +37: define LIBFOO_INSTALL_TARGET_CMDS
> +38: 	$(INSTALL) -D -m 0755 $(@D)/libfoo.so* $(TARGET_DIR)/usr/lib
> +39: 	$(INSTALL) -d -m 0755 $(TARGET_DIR)/etc/foo.d
> +40: endef
> +41:
> +42: define LIBFOO_DEVICES
> +43: 	/dev/foo  c  666  0  0  42  0  -  -  -
> +44: endef
> +45:
> +46: define LIBFOO_PERMISSIONS
> +47: 	/bin/foo  f  4755  0  0  -  -  -  -  -
> +48: endef
> +49:
> +50: $(eval $(generic-package))
>   --------------------------------
>
>   The Makefile begins on line 6 to 8 with metadata information: the
> @@ -64,12 +79,20 @@ install header files and other development files in the staging space.
>   This will ensure that the commands listed in the
>   +LIBFOO_INSTALL_STAGING_CMDS+ variable will be executed.
>
> -On line 10, we specify the list of dependencies this package relies
> -on. These dependencies are listed in terms of lower-case package names,
> -which can be packages for the target (without the +host-+
> -prefix) or packages for the host (with the +host-+) prefix).
> -Buildroot will ensure that all these packages are built and installed
> -'before' the current package starts its configuration.
> +On line 10, we specify the list of dependencies this package relies on.
> +These dependencies are listed in terms of lower-case package names, which
> +can be packages for the target (without the +host-+ prefix) or packages
> +for the host (with the +host-+ prefix). Buildroot will ensure that all
> +these packages are built and installed 'before' the current package starts
> +its configuration.
> +
> +On lines 12 to 14, if the user did select the option
> ++BR2_PACKAGE_LIBFOO_FROBBLE+ (see above, in the +Config.in+), we
> +conditionnally add a value to the +CFLAGS+. On line 16, we add the 'gazzle

  conditionally

> +level' +BR2_PACKAGE_LIBFOO_GAZZLE_LEVEL+ to the +CFLAGS+. And on lines 18
> +to 22, if the user selected 'goo' support, +BR2_PACKAGE_LIBFOO_GOO+, we
> +add a dependency on the package +goo+, and add appropriate +CFLAGS+ and
> ++LDFLAGS+.
>
>   The rest of the Makefile defines what should be done at the different
>   steps of the package configuration, compilation and installation.
> @@ -79,11 +102,11 @@ steps should be performed to install the package in the staging space.
>   +LIBFOO_INSTALL_TARGET_CMDS+ tells what steps should be
>   performed to install the package in the target space.

  Shouldn't _DEVICES and _PERMISSIONS be explained?

>
> -All these steps rely on the +$(@D)+ variable, which
> -contains the directory where the source code of the package has been
> -extracted.
> +All these steps rely on the +$(@D)+ variable, which contains the directory
> +where the source code of the package has been extracted, and where the
> +package is being built.
>
> -Finally, on line 35, we call the +generic-package+ which
> +Finally, on line 50, we call the +generic-package+ which
>   generates, according to the variables defined previously, all the
>   Makefile code necessary to make your package working.
>


  Overall, a very good addition to the doc, regardless of the _AVAILABLE stuff!

  Regards,
  Arnout
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

  reply	other threads:[~2012-11-01  1:30 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-09 23:40 [Buildroot] [PATCH 0/7] Introduce the _AVAILABLE mechanism Yann E. MORIN
2012-09-09 23:40 ` [Buildroot] [PATCH 1/7] docs/manual: update 'adding packages' with the new _AVAILABLE symbol Yann E. MORIN
2012-11-01  1:30   ` Arnout Vandecappelle [this message]
2012-11-01 16:21     ` Yann E. MORIN
2012-11-01 22:40       ` Arnout Vandecappelle
2012-11-02  8:59         ` Thomas Petazzoni
2012-09-09 23:40 ` [Buildroot] [PATCH 2/7] support/scripts: add a script to add a new package Yann E. MORIN
2012-10-14 11:14   ` [Buildroot] [PATCH] pkg-avail: make it work without stgit Thomas Petazzoni
2012-10-14 12:03     ` Baruch Siach
2012-10-14 12:12       ` Yann E. MORIN
2012-10-14 13:33     ` Yann E. MORIN
2012-10-14 13:52       ` Thomas Petazzoni
2012-11-01  2:00   ` [Buildroot] [PATCH 2/7] support/scripts: add a script to add a new package Arnout Vandecappelle
2012-11-01  9:09     ` Thomas Petazzoni
2012-11-01 17:00       ` Yann E. MORIN
2012-11-01 16:56     ` Yann E. MORIN
2012-11-01 17:25     ` Yann E. MORIN
2012-09-09 23:40 ` [Buildroot] [PATCH 3/7] support/scripts: add a script to automate the migration to _AVAILABLE Yann E. MORIN
2012-09-09 23:40 ` [Buildroot] [PATCH 4/7] packages: introduce the _AVAILABLE symbol to all packages Yann E. MORIN
2012-09-09 23:40 ` [Buildroot] [PATCH 5/7] packages: use the newly-introduced _AVAILABLE symbol Yann E. MORIN
2012-09-09 23:40 ` [Buildroot] [PATCH 6/7] packages: check proper use of 'select' against packages Yann E. MORIN
2012-09-09 23:40 ` [Buildroot] [PATCH 7/7] script/support: get rid of now-useless pkg-avail script Yann E. MORIN
2012-09-09 23:45 ` [Buildroot] [PATCH 0/7] Introduce the _AVAILABLE mechanism Yann E. MORIN
2012-09-10  6:51   ` Peter Korsgaard
2012-10-14 10:53 ` Thomas Petazzoni
2012-10-14 14:05 ` Thomas Petazzoni
2012-10-14 14:31   ` Yann E. MORIN
2012-10-14 17:38     ` Thomas Petazzoni
2012-10-16  5:39       ` Arnout Vandecappelle
2012-10-16 17:34         ` Yann E. MORIN
2012-10-17 21:33           ` Arnout Vandecappelle
2012-10-17 19:30         ` Thomas Petazzoni
2012-10-17 19:47           ` Yann E. MORIN
2012-10-17 20:05             ` Thomas Petazzoni
2012-10-17 20:16               ` Yann E. MORIN
2012-10-17 20:41                 ` Thomas Petazzoni
2012-10-17 20:48                   ` Arnout Vandecappelle
2012-10-30 23:11 ` Arnout Vandecappelle
2012-10-30 23:35   ` Yann E. MORIN
2012-10-30 23:44     ` Yann E. MORIN
2012-10-30 23:48     ` Arnout Vandecappelle
2012-10-30 23:58       ` Yann E. MORIN

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5091D0B8.6050404@mind.be \
    --to=arnout@mind.be \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox