[Buildroot] [PATCH 0 of 9 v4] linux/uboot: add support for custom Mercurial repositories

[Buildroot] [PATCH 0 of 9 v4] linux/uboot: add support for custom Mercurial repositories

[Thomas De Schampheleire]

Hi,

This series adds support for custom Mercurial repositories in uboot and linux
packages.

This version is rebased with the 2013.08 master, there are only a few
real changes.

Best regards, 
Thomas

 Config.in.legacy                       |  139 +++++++++++++++++++++++++++++++--
 boot/barebox/Config.in                 |    4 +-
 boot/uboot/Config.in                   |   37 +++++---
 boot/uboot/uboot.mk                    |    5 +-
 configs/arm_foundationv8_defconfig     |    4 +-
 configs/beaglebone_defconfig           |    4 +-
 configs/calao_snowball_defconfig       |    4 +-
 configs/cubieboard_defconfig           |    8 +-
 configs/ea3250_defconfig               |    8 +-
 configs/fdi3250_defconfig              |    8 +-
 configs/gnublin_defconfig              |    8 +-
 configs/mx53loco_defconfig             |    8 +-
 configs/phy3250_defconfig              |    8 +-
 configs/rpi_defconfig                  |    4 +-
 fs/jffs2/Config.in                     |    4 +-
 linux/Config.in                        |   38 ++++++--
 linux/linux.mk                         |    5 +-
 package/gcc/Config.in.host             |    2 +-
 package/linux-headers/Config.in.host   |    2 +-
 package/uclibc/Config.in               |    2 +-
 toolchain/toolchain-external/Config.in |    2 +-
 21 files changed, 225 insertions(+), 79 deletions(-)

[Buildroot] [PATCH 1 of 9 v4] Config.in.legacy: update description for developers

[Thomas De Schampheleire]

The existing comments in Config.in.legacy are not entirely in-line with
current practice. The comments implies that BR2_LEGACY should not be set when
the conversion from old-to-new symbol can be done automatically using the
appropriate 'select' statements. However, none of the existing legacy options
does it this way. Moreover, I think it's intentional that the user is notified
of the change, so that the removal of the legacy options in later buildroot
versions no longer poses a problem.
Additionally, the comments now describe how to handle string options.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

---
v4: no changes
v3:
    - reorganize description
    - update string description for automatic propagation
    - extend string example
    - 'depends on BR2_LEGACY' --> 'select BR2_LEGACY' (spotted by Arnout)
(v2): new patch in this series

 Config.in.legacy |  50 +++++++++++++++++++++++++++++++++++++++++++-------
 1 files changed, 43 insertions(+), 7 deletions(-)

diff --git a/Config.in.legacy b/Config.in.legacy
--- a/Config.in.legacy
+++ b/Config.in.legacy
@@ -1,13 +1,9 @@
 #
 # Config.in.legacy - support for backward compatibility
 #
-# When an existing Config.in symbol is removed, it should be added again in this
-# file, and take appropriate action to approximate backward compatibility. If
-# there is an equivalent (set of) new symbols, these can just be select'ed by
-# the old symbol. This makes sure that running 'make oldconfig' will make things
-# "just work" when upgrading to a new buildroot version. If the change is too
-# fundamental and cannot be fixed by a simple select, then the old symbol should
-# select BR2_LEGACY.  If that symbol is set, the build will issue an error.
+# When an existing Config.in symbol is removed, it should be added again in
+# this file, and take appropriate action to approximate backward compatibility.
+# This will make the transition for the user more convenient.
 #
 # When adding legacy symbols to this file, add them to the front. The oldest
 # symbols will be removed again after about two years.
@@ -15,6 +11,46 @@
 # The symbol should be copied as-is from the place where it was previously
 # defined, but the help text should be removed or replaced with something that
 # explains how to fix it.
+#
+# For bool options, the old symbol should select BR2_LEGACY, so that the user
+# is informed at build-time about selected legacy options.
+# If there is an equivalent (set of) new symbols, these should be select'ed by
+# the old symbol for backwards compatibility.
+#
+# For string options, it is not possible to directly select another symbol. In
+# this case, a hidden wrap bool option has to be added, that defaults to y if
+# the old string is not set at its default value. The wrap symbol should select
+# BR2_LEGACY.
+# If the original symbol has been renamed, the new symbol should use the value
+# of the old symbol as default. This requires a change outside of
+# Config.in.legacy, and this should be clearly marked as such below, so that
+# removal of legacy options also include the removal of these external
+# references.
+#
+# [Example: renaming a string option from FOO to BAR]
+# original symbol:
+#     config BR2_FOO_STRING
+#             string "Some foo string"
+#
+# becomes:
+#     config BR2_BAR_STRING
+#             string "Some bar string"
+#             default BR2_FOO_STRING if BR2_FOO_STRING != ""  # legacy
+#
+# and in Config.in.legacy:
+#     config BR2_FOO_STRING
+#             string "The foo string has been renamed"
+#             help
+#               <suitable help text>
+#
+#     config BR2_FOO_STRING_WRAP
+#             bool
+#             default y if BR2_FOO_STRING != ""
+#             select BR2_LEGACY
+#
+#     # Note: BR2_FOO_STRING is still referenced from package/foo/Config.in
+#
+# [End of example]
 
 config BR2_LEGACY
 	bool

[Buildroot] [PATCH 2 of 9 v4] Config.in.legacy: update description for users

[Thomas De Schampheleire]

This patch clarifies the message shown to users in the legacy menu.
It explicitly mentions the need to save the configuration before disabling the
legacy options.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
v4: - reorder paragraphs (and modify text a bit to suit this new order)
    - add "Once you have removed all ..." sentence
    - add vertical whitespace (I used the least visible * symbol to preserve
      whitespace)
    (all comments from Arnout)
(v3): new patch in this series

 Config.in.legacy |  24 ++++++++++++++++++++----
 1 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/Config.in.legacy b/Config.in.legacy
--- a/Config.in.legacy
+++ b/Config.in.legacy
@@ -69,11 +69,27 @@ menu "Legacy config options"
 
 if BR2_LEGACY
 comment "Your old configuration uses legacy options that no  "
-comment "longer exist in buildroot.                          "
-comment "Please look at the options which have been selected "
-comment "and read their help text.                           "
-comment "As long as these options stay selected, the build   "
+comment "longer exist in buildroot, as indicated in the menu "
+comment "below. As long as these options stay selected, or in"
+comment "case of string options are non-empty, the build     "
 comment "will fail.                                          "
+comment "*                                                   "
+comment "Where possible, an automatic conversion from old to "
+comment "new symbols has been performed. Before making any   "
+comment "change in this legacy menu, make sure to exit the   "
+comment "configuration editor a first time and save the      "
+comment "configuration. Otherwise, the automatic conversion  "
+comment "of symbols will be lost.                            "
+comment "*                                                   "
+comment "After this initial save, reopen the configuration   "
+comment "editor, inspect the options selected below, read    "
+comment "their help texts, and verify/update the new         "
+comment "configuration in the corresponding configuration    "
+comment "menus. When everything is ok, you can disable the   "
+comment "legacy options in the menu below. Once you have     "
+comment "disabled all legacy options, this text will         "
+comment "disappear and you will be able to start the build.  "
+comment "*                                                   "
 comment "Note: at some point in the future, the oldest legacy"
 comment "options will be removed, and configuration files    "
 comment "that still have those options set, will fail to     "

[Buildroot] [PATCH 3 of 9 v4] Config.in.legacy: add separator to description for users

[Thomas De Schampheleire]

When legacy symbols are selected, the menuconfig shows the explanation for
users, immediately followed by the line "Legacy options removed in 2013.08".
In order to visually keep these apart, we introduce a separator.

Note that a line with all spaces is not correctly shown by menuconfig (the
width will not be kept at 80 characters, so the output is '***   ***').
A dashed line seemed a logical alternative, and with another dashed line on
top, the description becomes a block.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

---
This patch is pure aesthetics. I kept it as a separate patch so it can be
rejected easily if you don't feel the same way.

v4: no changes
(v3): new patch in this series

 Config.in.legacy |  2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/Config.in.legacy b/Config.in.legacy
--- a/Config.in.legacy
+++ b/Config.in.legacy
@@ -68,6 +68,7 @@ comment "Legacy detected: check the cont
 menu "Legacy config options"
 
 if BR2_LEGACY
+comment "----------------------------------------------------"
 comment "Your old configuration uses legacy options that no  "
 comment "longer exist in buildroot, as indicated in the menu "
 comment "below. As long as these options stay selected, or in"
@@ -94,6 +95,7 @@ comment "Note: at some point in the futu
 comment "options will be removed, and configuration files    "
 comment "that still have those options set, will fail to     "
 comment "build, or run, in unpredictable ways.               "
+comment "----------------------------------------------------"
 endif
 
 ###############################################################################

[Buildroot] [PATCH 4 of 9 v4] Remove redundant dollar signs in Config.in files

[Thomas De Schampheleire]

Some Config.in(.host) files have constructs like:

config FOO_VERSION
	string
	default "1.0" if FOO_1_0
	default "2.0" if FOO_2_0
	default $FOO_CUSTOM_VERSION if FOO_CUSTOM

The dollar sign here is not needed and confusing, so can be removed.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
v4: also check Config.in.host
(v3): new patch in this series

 boot/barebox/Config.in                 |  4 ++--
 boot/uboot/Config.in                   |  4 ++--
 fs/jffs2/Config.in                     |  4 ++--
 linux/Config.in                        |  2 +-
 package/gcc/Config.in.host             |  2 +-
 package/linux-headers/Config.in.host   |  2 +-
 package/uclibc/Config.in               |  2 +-
 toolchain/toolchain-external/Config.in |  2 +-
 8 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/boot/barebox/Config.in b/boot/barebox/Config.in
--- a/boot/barebox/Config.in
+++ b/boot/barebox/Config.in
@@ -41,9 +41,9 @@ endif
 config BR2_TARGET_BAREBOX_VERSION
 	string
 	default "2013.07.0"	if BR2_TARGET_BAREBOX_LATEST_VERSION
-	default $BR2_TARGET_BAREBOX_CUSTOM_VERSION_VALUE if BR2_TARGET_BAREBOX_CUSTOM_VERSION
+	default BR2_TARGET_BAREBOX_CUSTOM_VERSION_VALUE if BR2_TARGET_BAREBOX_CUSTOM_VERSION
 	default "custom"	if BR2_TARGET_BAREBOX_CUSTOM_TARBALL
-	default $BR2_TARGET_BAREBOX_CUSTOM_GIT_VERSION if BR2_TARGET_BAREBOX_CUSTOM_GIT
+	default BR2_TARGET_BAREBOX_CUSTOM_GIT_VERSION if BR2_TARGET_BAREBOX_CUSTOM_GIT
 
 config BR2_TARGET_BAREBOX_CUSTOM_PATCH_DIR
 	string "custom patch dir"
diff --git a/boot/uboot/Config.in b/boot/uboot/Config.in
--- a/boot/uboot/Config.in
+++ b/boot/uboot/Config.in
@@ -47,9 +47,9 @@ endif
 config BR2_TARGET_UBOOT_VERSION
 	string
 	default "2013.07"	if BR2_TARGET_UBOOT_LATEST_VERSION
-	default $BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE if BR2_TARGET_UBOOT_CUSTOM_VERSION
+	default BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE if BR2_TARGET_UBOOT_CUSTOM_VERSION
 	default "custom"	if BR2_TARGET_UBOOT_CUSTOM_TARBALL
-	default $BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION if BR2_TARGET_UBOOT_CUSTOM_GIT
+	default BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION if BR2_TARGET_UBOOT_CUSTOM_GIT
 
 config BR2_TARGET_UBOOT_CUSTOM_PATCH_DIR
 	string "custom patch dir"
diff --git a/fs/jffs2/Config.in b/fs/jffs2/Config.in
--- a/fs/jffs2/Config.in
+++ b/fs/jffs2/Config.in
@@ -58,7 +58,7 @@ config BR2_TARGET_ROOTFS_JFFS2_PAGESIZE
 	default 0x800 if BR2_TARGET_ROOTFS_JFFS2_NANDFLASH_2K_128K
 	default 0x1000 if BR2_TARGET_ROOTFS_JFFS2_FLASH_128
 	default 0x1000 if BR2_TARGET_ROOTFS_JFFS2_FLASH_64
-	default $(BR2_TARGET_ROOTFS_JFFS2_CUSTOM_PAGESIZE) if BR2_TARGET_ROOTFS_JFFS2_CUSTOM
+	default BR2_TARGET_ROOTFS_JFFS2_CUSTOM_PAGESIZE if BR2_TARGET_ROOTFS_JFFS2_CUSTOM
 
 config BR2_TARGET_ROOTFS_JFFS2_EBSIZE
 	hex
@@ -68,7 +68,7 @@ config BR2_TARGET_ROOTFS_JFFS2_EBSIZE
 	default 0x20000 if BR2_TARGET_ROOTFS_JFFS2_NANDFLASH_2K_128K
 	default 0x20000 if BR2_TARGET_ROOTFS_JFFS2_FLASH_128
 	default 0x10000 if BR2_TARGET_ROOTFS_JFFS2_FLASH_64
-	default $(BR2_TARGET_ROOTFS_JFFS2_CUSTOM_EBSIZE) if BR2_TARGET_ROOTFS_JFFS2_CUSTOM
+	default BR2_TARGET_ROOTFS_JFFS2_CUSTOM_EBSIZE if BR2_TARGET_ROOTFS_JFFS2_CUSTOM
 
 config BR2_TARGET_ROOTFS_JFFS2_NOCLEANMARKER
 	bool "Do not use Cleanmarker"
diff --git a/linux/Config.in b/linux/Config.in
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -79,7 +79,7 @@ config BR2_LINUX_KERNEL_VERSION
 	default BR2_DEFAULT_KERNEL_HEADERS if BR2_LINUX_KERNEL_SAME_AS_HEADERS
 	default BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE if BR2_LINUX_KERNEL_CUSTOM_VERSION
 	default "custom" if BR2_LINUX_KERNEL_CUSTOM_TARBALL
-	default $BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION if BR2_LINUX_KERNEL_CUSTOM_GIT
+	default BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION if BR2_LINUX_KERNEL_CUSTOM_GIT
 
 #
 # Patch selection
diff --git a/package/gcc/Config.in.host b/package/gcc/Config.in.host
--- a/package/gcc/Config.in.host
+++ b/package/gcc/Config.in.host
@@ -91,7 +91,7 @@ config BR2_GCC_VERSION
 	default "4.7.3"     if BR2_GCC_VERSION_4_7_X
 	default "4.8.1"     if BR2_GCC_VERSION_4_8_X
 	default "4.8-arc"   if BR2_GCC_VERSION_4_8_ARC
-	default $BR2_GCC_SNAP_DATE if BR2_GCC_VERSION_SNAP
+	default BR2_GCC_SNAP_DATE if BR2_GCC_VERSION_SNAP
 
 config BR2_EXTRA_GCC_CONFIG_OPTIONS
 	string "Additional gcc options"
diff --git a/package/linux-headers/Config.in.host b/package/linux-headers/Config.in.host
--- a/package/linux-headers/Config.in.host
+++ b/package/linux-headers/Config.in.host
@@ -84,4 +84,4 @@ config BR2_DEFAULT_KERNEL_HEADERS
 	default "3.9.11"	if BR2_KERNEL_HEADERS_3_9
 	default "3.10.10"	if BR2_KERNEL_HEADERS_3_10
 	default "2.6"		if BR2_KERNEL_HEADERS_SNAP
-	default $BR2_DEFAULT_KERNEL_VERSION if BR2_KERNEL_HEADERS_VERSION
+	default BR2_DEFAULT_KERNEL_VERSION if BR2_KERNEL_HEADERS_VERSION
diff --git a/package/uclibc/Config.in b/package/uclibc/Config.in
--- a/package/uclibc/Config.in
+++ b/package/uclibc/Config.in
@@ -37,7 +37,7 @@ config BR2_UCLIBC_VERSION_STRING
 	default 0.9.32.1	if BR2_UCLIBC_VERSION_0_9_32
 	default 0.9.33.2	if BR2_UCLIBC_VERSION_0_9_33
 	default 0.9.33-arc	if BR2_UCLIBC_VERSION_0_9_33_ARC
-	default $BR2_USE_UCLIBC_SNAPSHOT	if BR2_UCLIBC_VERSION_SNAPSHOT
+	default BR2_USE_UCLIBC_SNAPSHOT	if BR2_UCLIBC_VERSION_SNAPSHOT
 
 config BR2_UCLIBC_CONFIG
 	string "uClibc configuration file to use?"
diff --git a/toolchain/toolchain-external/Config.in b/toolchain/toolchain-external/Config.in
--- a/toolchain/toolchain-external/Config.in
+++ b/toolchain/toolchain-external/Config.in
@@ -832,7 +832,7 @@ config BR2_TOOLCHAIN_EXTERNAL_PREFIX
 	default "bfin-linux-uclibc"	 if BR2_TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_2012R1 && BR2_BINFMT_FDPIC
 	default "bfin-uclinux"		 if BR2_TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_2012R2 && BR2_BINFMT_FLAT
 	default "bfin-linux-uclibc"	 if BR2_TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_2012R2 && BR2_BINFMT_FDPIC
-	default $(BR2_TOOLCHAIN_EXTERNAL_CUSTOM_PREFIX) \
+	default BR2_TOOLCHAIN_EXTERNAL_CUSTOM_PREFIX \
 					 if BR2_TOOLCHAIN_EXTERNAL_CUSTOM
 
 config BR2_TOOLCHAIN_EXTERNAL_GLIBC

[Buildroot] [PATCH 5 of 9 v4] linux: add support for custom Mercurial repository

[Thomas De Schampheleire]

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
v4: rebased
v3:
    - add automatic propagation of old->new values (comment Arnout)
    - fix legacy entries
v2: add Config.in.legacy entries (comment Peter)

 Config.in.legacy |  33 +++++++++++++++++++++++++++++++++
 linux/Config.in  |  32 +++++++++++++++++++++++---------
 linux/linux.mk   |   5 ++++-
 3 files changed, 60 insertions(+), 10 deletions(-)

diff --git a/Config.in.legacy b/Config.in.legacy
--- a/Config.in.legacy
+++ b/Config.in.legacy
@@ -99,6 +99,39 @@ comment "-------------------------------
 endif
 
 ###############################################################################
+comment "Legacy options removed in 2013.11"
+
+config BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL
+	string "linux: the git repository URL option has been renamed"
+	help
+	  The option BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL has
+	  been renamed to
+	  BR2_LINUX_KERNEL_CUSTOM_REPO_URL.
+
+config BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL_WRAP
+	bool
+	default y if BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL != ""
+	select BR2_LEGACY
+
+# Note: BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL is still referenced from
+# linux/Config.in
+
+config BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION
+	string "linux: the git repository version option has been renamed"
+	help
+	  The option BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION has
+	  been renamed to
+	  BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION.
+
+config BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION_WRAP
+	bool
+	default y if BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION != ""
+	select BR2_LEGACY
+
+# Note: BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION is still referenced from
+# linux/Config.in
+
+###############################################################################
 comment "Legacy options removed in 2013.08"
 
 config BR2_ARM_OABI
diff --git a/linux/Config.in b/linux/Config.in
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -52,6 +52,12 @@ config BR2_LINUX_KERNEL_CUSTOM_GIT
 	  This option allows Buildroot to get the Linux kernel source
 	  code from a Git repository.
 
+config BR2_LINUX_KERNEL_CUSTOM_HG
+	bool "Custom Mercurial repository"
+	help
+	  This option allows Buildroot to get the Linux kernel source
+	  code from a Mercurial repository.
+
 endchoice
 
 config BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE
@@ -62,24 +68,32 @@ config BR2_LINUX_KERNEL_CUSTOM_TARBALL_L
 	string "URL of custom kernel tarball"
 	depends on BR2_LINUX_KERNEL_CUSTOM_TARBALL
 
-config BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL
-	string "URL of custom Git repository"
-	depends on BR2_LINUX_KERNEL_CUSTOM_GIT
+if BR2_LINUX_KERNEL_CUSTOM_GIT || BR2_LINUX_KERNEL_CUSTOM_HG
 
-config BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION
-	string "Custom Git version"
-	depends on BR2_LINUX_KERNEL_CUSTOM_GIT
+config BR2_LINUX_KERNEL_CUSTOM_REPO_URL
+	string "URL of custom repository"
+	default BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL \
+		if BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL != ""  # legacy
+
+config BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION
+	string "Custom repository version"
+	default BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION \
+		if BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION != ""  # legacy
 	help
-	  Git revision to use in the format used by git rev-parse,
+	  Revision to use in the typical format used by Git/Mercurial
 	  E.G. a sha id, a tag, branch, ..
 
+endif
+
 config BR2_LINUX_KERNEL_VERSION
 	string
 	default "3.10.10" if BR2_LINUX_KERNEL_LATEST_VERSION
 	default BR2_DEFAULT_KERNEL_HEADERS if BR2_LINUX_KERNEL_SAME_AS_HEADERS
-	default BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE if BR2_LINUX_KERNEL_CUSTOM_VERSION
+	default BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE \
+		if BR2_LINUX_KERNEL_CUSTOM_VERSION
 	default "custom" if BR2_LINUX_KERNEL_CUSTOM_TARBALL
-	default BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION if BR2_LINUX_KERNEL_CUSTOM_GIT
+	default BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION \
+		if BR2_LINUX_KERNEL_CUSTOM_GIT || BR2_LINUX_KERNEL_CUSTOM_HG
 
 #
 # Patch selection
diff --git a/linux/linux.mk b/linux/linux.mk
--- a/linux/linux.mk
+++ b/linux/linux.mk
@@ -14,8 +14,11 @@ LINUX_TARBALL = $(call qstrip,$(BR2_LINU
 LINUX_SITE = $(patsubst %/,%,$(dir $(LINUX_TARBALL)))
 LINUX_SOURCE = $(notdir $(LINUX_TARBALL))
 else ifeq ($(BR2_LINUX_KERNEL_CUSTOM_GIT),y)
-LINUX_SITE = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL))
+LINUX_SITE = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_REPO_URL))
 LINUX_SITE_METHOD = git
+else ifeq ($(BR2_LINUX_KERNEL_CUSTOM_HG),y)
+LINUX_SITE = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_REPO_URL))
+LINUX_SITE_METHOD = hg
 else
 LINUX_SOURCE = linux-$(LINUX_VERSION).tar.xz
 # In X.Y.Z, get X and Y. We replace dots and dashes by spaces in order

[Buildroot] [PATCH 6 of 9 v4] u-boot: add support for custom Mercurial repository

[Thomas De Schampheleire]

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
v4: no changes
v3:
    - add automatic propagation of old->new values
    - fix legacy entries
v2: add Config.in.legacy entries (comment Peter)

 Config.in.legacy     |  30 ++++++++++++++++++++++++++++++
 boot/uboot/Config.in |  23 ++++++++++++++++-------
 boot/uboot/uboot.mk  |   5 ++++-
 3 files changed, 50 insertions(+), 8 deletions(-)

diff --git a/Config.in.legacy b/Config.in.legacy
--- a/Config.in.legacy
+++ b/Config.in.legacy
@@ -101,6 +101,36 @@ endif
 ###############################################################################
 comment "Legacy options removed in 2013.11"
 
+config BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL
+	string "u-boot: the git repository URL option has been renamed"
+	help
+	  The option BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL has
+	  been renamed to
+	  BR2_TARGET_UBOOT_CUSTOM_REPO_URL.
+
+config BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL_WRAP
+	bool
+	default y if BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL != ""
+	select BR2_LEGACY
+
+# Note: BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL is still referenced from
+# boot/uboot/Config.in
+
+config BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION
+	string "u-boot: the git repository version option has been renamed"
+	help
+	  The option BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION has
+	  been renamed to
+	  BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION.
+
+config BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION_WRAP
+	bool
+	default y if BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION != ""
+	select BR2_LEGACY
+
+# Note: BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION is still referenced from
+# boot/uboot/Config.in
+
 config BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL
 	string "linux: the git repository URL option has been renamed"
 	help
diff --git a/boot/uboot/Config.in b/boot/uboot/Config.in
--- a/boot/uboot/Config.in
+++ b/boot/uboot/Config.in
@@ -31,6 +31,9 @@ config BR2_TARGET_UBOOT_CUSTOM_TARBALL
 config BR2_TARGET_UBOOT_CUSTOM_GIT
 	bool "Custom Git repository"
 
+config BR2_TARGET_UBOOT_CUSTOM_HG
+	bool "Custom Mercurial repository"
+
 endchoice
 
 config BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE
@@ -47,9 +50,11 @@ endif
 config BR2_TARGET_UBOOT_VERSION
 	string
 	default "2013.07"	if BR2_TARGET_UBOOT_LATEST_VERSION
-	default BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE if BR2_TARGET_UBOOT_CUSTOM_VERSION
+	default BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE \
+		if BR2_TARGET_UBOOT_CUSTOM_VERSION
 	default "custom"	if BR2_TARGET_UBOOT_CUSTOM_TARBALL
-	default BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION if BR2_TARGET_UBOOT_CUSTOM_GIT
+	default BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION \
+		if BR2_TARGET_UBOOT_CUSTOM_GIT || BR2_TARGET_UBOOT_CUSTOM_HG
 
 config BR2_TARGET_UBOOT_CUSTOM_PATCH_DIR
 	string "custom patch dir"
@@ -60,13 +65,17 @@ config BR2_TARGET_UBOOT_CUSTOM_PATCH_DIR
 
 	  Most users may leave this empty
 
-if BR2_TARGET_UBOOT_CUSTOM_GIT
+if BR2_TARGET_UBOOT_CUSTOM_GIT || BR2_TARGET_UBOOT_CUSTOM_HG
 
-config BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL
-	string "URL of custom Git repository"
+config BR2_TARGET_UBOOT_CUSTOM_REPO_URL
+	string "URL of custom repository"
+	default BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL \
+		if BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL != ""  # legacy
 
-config BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION
-	string "Custom Git version"
+config BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION
+	string "Custom repository version"
+	default BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION \
+		if BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION != ""  # legacy
 
 endif
 
diff --git a/boot/uboot/uboot.mk b/boot/uboot/uboot.mk
--- a/boot/uboot/uboot.mk
+++ b/boot/uboot/uboot.mk
@@ -18,8 +18,11 @@ UBOOT_TARBALL = $(call qstrip,$(BR2_TARG
 UBOOT_SITE    = $(patsubst %/,%,$(dir $(UBOOT_TARBALL)))
 UBOOT_SOURCE  = $(notdir $(UBOOT_TARBALL))
 else ifeq ($(BR2_TARGET_UBOOT_CUSTOM_GIT),y)
-UBOOT_SITE        = $(call qstrip,$(BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL))
+UBOOT_SITE        = $(call qstrip,$(BR2_TARGET_UBOOT_CUSTOM_REPO_URL))
 UBOOT_SITE_METHOD = git
+else ifeq ($(BR2_TARGET_UBOOT_CUSTOM_HG),y)
+UBOOT_SITE        = $(call qstrip,$(BR2_TARGET_UBOOT_CUSTOM_REPO_URL))
+UBOOT_SITE_METHOD = hg
 else
 # Handle stable official U-Boot versions
 UBOOT_SITE    = ftp://ftp.denx.de/pub/u-boot

[Buildroot] [PATCH 7 of 9 v4] linux/uboot: line-up repository-related configuration options

[Thomas De Schampheleire]

Although the configuration options for custom repository locations and
versions are very similar between the linux and uboot packages, there are
some minor differences. This patch lines up both packages.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
v4: no changes
v3: update after changes in previous patches
v2:
- remove 'HEAD/tip' defaults for repository version (comment Peter)
- replace if/config/endif with config/depends for uboot tarball
- move repo url/version settings before unrelated 'custom patch dir'

Note: one remaining difference is that there are help texts in linux for
options BR2_LINUX_KERNEL_CUSTOM_GIT and BR2_LINUX_KERNEL_CUSTOM_HG. I
didn't add them to uboot because it seems a bit redundant, but if you
prefer we can line this up as well (either add help texts to uboot or
remove them from linux).

 boot/uboot/Config.in |  32 ++++++++++++++++----------------
 linux/Config.in      |   2 +-
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/boot/uboot/Config.in b/boot/uboot/Config.in
--- a/boot/uboot/Config.in
+++ b/boot/uboot/Config.in
@@ -40,10 +40,24 @@ config BR2_TARGET_UBOOT_CUSTOM_VERSION_V
 	string "U-Boot version"
 	depends on BR2_TARGET_UBOOT_CUSTOM_VERSION
 
-if BR2_TARGET_UBOOT_CUSTOM_TARBALL
-
 config BR2_TARGET_UBOOT_CUSTOM_TARBALL_LOCATION
 	string "URL of custom U-Boot tarball"
+	depends on BR2_TARGET_UBOOT_CUSTOM_TARBALL
+
+if BR2_TARGET_UBOOT_CUSTOM_GIT || BR2_TARGET_UBOOT_CUSTOM_HG
+
+config BR2_TARGET_UBOOT_CUSTOM_REPO_URL
+	string "URL of custom repository"
+	default BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL \
+		if BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL != ""  # legacy
+
+config BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION
+	string "Custom repository version"
+	default BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION \
+		if BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION != ""  # legacy
+	help
+	  Revision to use in the typical format used by Git/Mercurial
+	  E.G. a sha id, a tag, branch, ..
 
 endif
 
@@ -65,20 +79,6 @@ config BR2_TARGET_UBOOT_CUSTOM_PATCH_DIR
 
 	  Most users may leave this empty
 
-if BR2_TARGET_UBOOT_CUSTOM_GIT || BR2_TARGET_UBOOT_CUSTOM_HG
-
-config BR2_TARGET_UBOOT_CUSTOM_REPO_URL
-	string "URL of custom repository"
-	default BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL \
-		if BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL != ""  # legacy
-
-config BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION
-	string "Custom repository version"
-	default BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION \
-		if BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION != ""  # legacy
-
-endif
-
 choice
 	prompt "U-Boot binary format"
 	default BR2_TARGET_UBOOT_FORMAT_BIN
diff --git a/linux/Config.in b/linux/Config.in
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -47,7 +47,7 @@ config BR2_LINUX_KERNEL_CUSTOM_TARBALL
 	  specific kernel source tarball
 
 config BR2_LINUX_KERNEL_CUSTOM_GIT
-	bool "Custom Git tree"
+	bool "Custom Git repository"
 	help
 	  This option allows Buildroot to get the Linux kernel source
 	  code from a Git repository.

[Buildroot] [PATCH 8 of 9 v4] defconfigs: update after rename of custom git repo/version options

[Thomas De Schampheleire]

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
v4: no changes
(v3): new patch in this series (comment Arnout)

 configs/arm_foundationv8_defconfig |  4 ++--
 configs/beaglebone_defconfig       |  4 ++--
 configs/calao_snowball_defconfig   |  4 ++--
 configs/cubieboard_defconfig       |  8 ++++----
 configs/ea3250_defconfig           |  8 ++++----
 configs/fdi3250_defconfig          |  8 ++++----
 configs/gnublin_defconfig          |  8 ++++----
 configs/mx53loco_defconfig         |  8 ++++----
 configs/phy3250_defconfig          |  8 ++++----
 configs/rpi_defconfig              |  4 ++--
 10 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/configs/arm_foundationv8_defconfig b/configs/arm_foundationv8_defconfig
--- a/configs/arm_foundationv8_defconfig
+++ b/configs/arm_foundationv8_defconfig
@@ -8,8 +8,8 @@ BR2_TARGET_BOOT_WRAPPER_AARCH64_DTS="vex
 BR2_TARGET_BOOT_WRAPPER_AARCH64_BOOTARGS="root=/dev/vda consolelog=9 console=ttyAMA0 rw"
 BR2_LINUX_KERNEL=y
 BR2_LINUX_KERNEL_CUSTOM_GIT=y
-BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL="git://git.linaro.org/kernel/linaro-aarch64.git"
-BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION="7181edd0539e195f78adedbb6c3878f9f1e0c4bb"
+BR2_LINUX_KERNEL_CUSTOM_REPO_URL="git://git.linaro.org/kernel/linaro-aarch64.git"
+BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="7181edd0539e195f78adedbb6c3878f9f1e0c4bb"
 BR2_LINUX_KERNEL_DEFCONFIG="vexpress"
 BR2_LINUX_KERNEL_IMAGE_TARGET_CUSTOM=y
 BR2_LINUX_KERNEL_IMAGE_TARGET_NAME="Image"
diff --git a/configs/beaglebone_defconfig b/configs/beaglebone_defconfig
--- a/configs/beaglebone_defconfig
+++ b/configs/beaglebone_defconfig
@@ -30,8 +30,8 @@ BR2_TARGET_UBOOT_SPL_NAME="MLO"
 # kernel
 BR2_LINUX_KERNEL=y
 BR2_LINUX_KERNEL_CUSTOM_GIT=y
-BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL="git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git"
-BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION="935f6c2f82056d538b528272e2bdbb5c08d69a58"
+BR2_LINUX_KERNEL_CUSTOM_REPO_URL="git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git"
+BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="935f6c2f82056d538b528272e2bdbb5c08d69a58"
 BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
 BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/beaglebone/linux-3.8.config"
 BR2_LINUX_KERNEL_DTS_SUPPORT=y
diff --git a/configs/calao_snowball_defconfig b/configs/calao_snowball_defconfig
--- a/configs/calao_snowball_defconfig
+++ b/configs/calao_snowball_defconfig
@@ -16,8 +16,8 @@ BR2_TARGET_UBOOT=y
 BR2_TARGET_UBOOT_BOARDNAME="snowball"
 BR2_LINUX_KERNEL=y
 BR2_LINUX_KERNEL_CUSTOM_GIT=y
-BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL="https://github.com/igloocommunity/igloo-kernel"
-BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION="stable-linux-ux500-3.4"
+BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/igloocommunity/igloo-kernel"
+BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="stable-linux-ux500-3.4"
 BR2_LINUX_KERNEL_PATCH="board/calao/snowball/"
 BR2_LINUX_KERNEL_DEFCONFIG="u8500"
 BR2_LINUX_KERNEL_INSTALL_TARGET=y
diff --git a/configs/cubieboard_defconfig b/configs/cubieboard_defconfig
--- a/configs/cubieboard_defconfig
+++ b/configs/cubieboard_defconfig
@@ -22,8 +22,8 @@ BR2_KERNEL_HEADERS_3_4=y
 # Kernel
 BR2_LINUX_KERNEL=y
 BR2_LINUX_KERNEL_CUSTOM_GIT=y
-BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL="https://github.com/linux-sunxi/linux-sunxi.git"
-BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION="274a66a7bfcbaabb88d63e4eba161965383cc416"
+BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/linux-sunxi/linux-sunxi.git"
+BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="274a66a7bfcbaabb88d63e4eba161965383cc416"
 BR2_LINUX_KERNEL_VERSION="sunxi-3.4"
 BR2_LINUX_KERNEL_DEFCONFIG="sun4i"
 
@@ -32,8 +32,8 @@ BR2_TARGET_UBOOT=y
 BR2_TARGET_UBOOT_BOARDNAME="cubieboard"
 BR2_TARGET_UBOOT_CUSTOM_GIT=y
 BR2_TARGET_UBOOT_VERSION="sunxi"
-BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL="https://github.com/linux-sunxi/u-boot-sunxi.git"
-BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION="1a8ac55429f7f8cc9f100c1cf2dc0195cf81e76f"
+BR2_TARGET_UBOOT_CUSTOM_REPO_URL="https://github.com/linux-sunxi/u-boot-sunxi.git"
+BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION="1a8ac55429f7f8cc9f100c1cf2dc0195cf81e76f"
 BR2_TARGET_UBOOT_FORMAT_BIN=y
 BR2_TARGET_UBOOT_SPL=y
 BR2_TARGET_UBOOT_SPL_NAME="spl/sunxi-spl.bin"
diff --git a/configs/ea3250_defconfig b/configs/ea3250_defconfig
--- a/configs/ea3250_defconfig
+++ b/configs/ea3250_defconfig
@@ -27,8 +27,8 @@ BR2_TARGET_UBOOT=y
 BR2_TARGET_UBOOT_BOARDNAME="ea3250"
 BR2_TARGET_UBOOT_CUSTOM_GIT=y
 BR2_TARGET_UBOOT_VERSION="master"
-BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL="git://git.lpclinux.com/uboot-2009.03-lpc32xx"
-BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION="master"
+BR2_TARGET_UBOOT_CUSTOM_REPO_URL="git://git.lpclinux.com/uboot-2009.03-lpc32xx"
+BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION="master"
 BR2_TARGET_UBOOT_FORMAT_BIN=y
 BR2_TARGET_LPC32XXCDL=y
 BR2_TARGET_LPC32XXCDL_BOARDNAME="ea3250"
@@ -39,8 +39,8 @@ BR2_TARGET_LPC32XXCDL_BOARDNAME="ea3250"
 #
 BR2_LINUX_KERNEL=y
 BR2_LINUX_KERNEL_CUSTOM_GIT=y
-BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL="git://git.lpclinux.com/linux-2.6.34-lpc32xx"
-BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION="master"
+BR2_LINUX_KERNEL_CUSTOM_REPO_URL="git://git.lpclinux.com/linux-2.6.34-lpc32xx"
+BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="master"
 BR2_LINUX_KERNEL_VERSION="master"
 BR2_LINUX_KERNEL_PATCH=""
 BR2_LINUX_KERNEL_USE_DEFCONFIG=y
diff --git a/configs/fdi3250_defconfig b/configs/fdi3250_defconfig
--- a/configs/fdi3250_defconfig
+++ b/configs/fdi3250_defconfig
@@ -27,8 +27,8 @@ BR2_TARGET_UBOOT=y
 BR2_TARGET_UBOOT_BOARDNAME="fdi3250"
 BR2_TARGET_UBOOT_CUSTOM_GIT=y
 BR2_TARGET_UBOOT_VERSION="master"
-BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL="git://git.lpclinux.com/uboot-2009.03-lpc32xx"
-BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION="master"
+BR2_TARGET_UBOOT_CUSTOM_REPO_URL="git://git.lpclinux.com/uboot-2009.03-lpc32xx"
+BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION="master"
 BR2_TARGET_UBOOT_FORMAT_BIN=y
 BR2_TARGET_LPC32XXCDL=y
 BR2_TARGET_LPC32XXCDL_BOARDNAME="fdi3250"
@@ -39,8 +39,8 @@ BR2_TARGET_LPC32XXCDL_BOARDNAME="fdi3250
 #
 BR2_LINUX_KERNEL=y
 BR2_LINUX_KERNEL_CUSTOM_GIT=y
-BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL="git://git.lpclinux.com/linux-2.6.34-lpc32xx"
-BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION="master"
+BR2_LINUX_KERNEL_CUSTOM_REPO_URL="git://git.lpclinux.com/linux-2.6.34-lpc32xx"
+BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="master"
 BR2_LINUX_KERNEL_VERSION="master"
 BR2_LINUX_KERNEL_PATCH=""
 BR2_LINUX_KERNEL_USE_DEFCONFIG=y
diff --git a/configs/gnublin_defconfig b/configs/gnublin_defconfig
--- a/configs/gnublin_defconfig
+++ b/configs/gnublin_defconfig
@@ -15,13 +15,13 @@ BR2_TARGET_ROOTFS_EXT2_BLOCKS=475000
 BR2_TARGET_UBOOT=y
 BR2_TARGET_UBOOT_BOARDNAME="GNUBLIN"
 BR2_TARGET_UBOOT_CUSTOM_GIT=y
-BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL="git://gitorious.org/u-boot-gnublin-support/u-boot-gnublin-support.git"
-BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION="2009.11_gnublin_support_v2"
+BR2_TARGET_UBOOT_CUSTOM_REPO_URL="git://gitorious.org/u-boot-gnublin-support/u-boot-gnublin-support.git"
+BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION="2009.11_gnublin_support_v2"
 
 # Kernel
 BR2_LINUX_KERNEL=y
 BR2_LINUX_KERNEL_CUSTOM_GIT=y
-BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL="git://gitorious.org/linux-3-7-gnublin/linux-3-7-gnublin.git"
-BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION="v3.7-gnublin-2"
+BR2_LINUX_KERNEL_CUSTOM_REPO_URL="git://gitorious.org/linux-3-7-gnublin/linux-3-7-gnublin.git"
+BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="v3.7-gnublin-2"
 BR2_LINUX_KERNEL_DEFCONFIG="gnublin"
 BR2_LINUX_KERNEL_INSTALL_TARGET=y
diff --git a/configs/mx53loco_defconfig b/configs/mx53loco_defconfig
--- a/configs/mx53loco_defconfig
+++ b/configs/mx53loco_defconfig
@@ -8,8 +8,8 @@ BR2_TARGET_GENERIC_GETTY_PORT="ttymxc0"
 BR2_TARGET_UBOOT=y
 BR2_TARGET_UBOOT_BOARDNAME="mx53_loco"
 BR2_TARGET_UBOOT_CUSTOM_GIT=y
-BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL="git://git.freescale.com/imx/uboot-imx.git"
-BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION="rel_imx_2.6.35_11.09.01"
+BR2_TARGET_UBOOT_CUSTOM_REPO_URL="git://git.freescale.com/imx/uboot-imx.git"
+BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION="rel_imx_2.6.35_11.09.01"
 
 # filesystem
 BR2_TARGET_ROOTFS_EXT2=y
@@ -17,6 +17,6 @@ BR2_TARGET_ROOTFS_EXT2=y
 # Kernel
 BR2_LINUX_KERNEL=y
 BR2_LINUX_KERNEL_CUSTOM_GIT=y
-BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL="git://git.freescale.com/imx/linux-2.6-imx.git"
-BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION="rel_imx_2.6.35_11.09.01"
+BR2_LINUX_KERNEL_CUSTOM_REPO_URL="git://git.freescale.com/imx/linux-2.6-imx.git"
+BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="rel_imx_2.6.35_11.09.01"
 BR2_LINUX_KERNEL_DEFCONFIG="imx5"
diff --git a/configs/phy3250_defconfig b/configs/phy3250_defconfig
--- a/configs/phy3250_defconfig
+++ b/configs/phy3250_defconfig
@@ -27,8 +27,8 @@ BR2_TARGET_UBOOT=y
 BR2_TARGET_UBOOT_BOARDNAME="phy3250"
 BR2_TARGET_UBOOT_CUSTOM_GIT=y
 BR2_TARGET_UBOOT_VERSION="master"
-BR2_TARGET_UBOOT_CUSTOM_GIT_REPO_URL="git://git.lpclinux.com/uboot-2009.03-lpc32xx"
-BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION="master"
+BR2_TARGET_UBOOT_CUSTOM_REPO_URL="git://git.lpclinux.com/uboot-2009.03-lpc32xx"
+BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION="master"
 BR2_TARGET_UBOOT_FORMAT_BIN=y
 BR2_TARGET_LPC32XXCDL=y
 BR2_TARGET_LPC32XXCDL_BOARDNAME="phy3250"
@@ -39,8 +39,8 @@ BR2_TARGET_LPC32XXCDL_BOARDNAME="phy3250
 #
 BR2_LINUX_KERNEL=y
 BR2_LINUX_KERNEL_CUSTOM_GIT=y
-BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL="git://git.lpclinux.com/linux-2.6.34-lpc32xx"
-BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION="master"
+BR2_LINUX_KERNEL_CUSTOM_REPO_URL="git://git.lpclinux.com/linux-2.6.34-lpc32xx"
+BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="master"
 BR2_LINUX_KERNEL_VERSION="master"
 BR2_LINUX_KERNEL_PATCH=""
 BR2_LINUX_KERNEL_USE_DEFCONFIG=y
diff --git a/configs/rpi_defconfig b/configs/rpi_defconfig
--- a/configs/rpi_defconfig
+++ b/configs/rpi_defconfig
@@ -16,8 +16,8 @@ BR2_DEFAULT_KERNEL_VERSION="3.6.11"
 
 BR2_LINUX_KERNEL=y
 BR2_LINUX_KERNEL_CUSTOM_GIT=y
-BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL="git://github.com/raspberrypi/linux.git"
-BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION="0006326"
+BR2_LINUX_KERNEL_CUSTOM_REPO_URL="git://github.com/raspberrypi/linux.git"
+BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="0006326"
 BR2_LINUX_KERNEL_USE_DEFCONFIG=y
 BR2_LINUX_KERNEL_DEFCONFIG="bcmrpi"
 BR2_LINUX_KERNEL_ZIMAGE=y

[Buildroot] [PATCH 9 of 9 v4] linux: mention 3.x.y kernels in 'custom version' help

[Thomas De Schampheleire]

(also fix grammatical error versions -> version)

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
v4: no changes
v3: no changes
(v2): new patch in series, although only loosely related.

 linux/Config.in |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/linux/Config.in b/linux/Config.in
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -37,8 +37,8 @@ config BR2_LINUX_KERNEL_SAME_AS_HEADERS
 config BR2_LINUX_KERNEL_CUSTOM_VERSION
 	bool "Custom version"
 	help
-	  This option allows to use a specific 2.6.x or 2.6.x.y
-	  official versions, as available on kernel.org
+	  This option allows to use a specific official version from
+	  kernel.org, like 2.6.x, 2.6.x.y, 3.x.y, ...
 
 config BR2_LINUX_KERNEL_CUSTOM_TARBALL
 	bool "Custom tarball"

[Buildroot] [PATCH 1 of 9 v4] Config.in.legacy: update description for developers

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Mon, 02 Sep 2013 22:07:50 +0200, Thomas De Schampheleire wrote:

> The existing comments in Config.in.legacy are not entirely in-line with
> current practice. The comments implies that BR2_LEGACY should not be set when
> the conversion from old-to-new symbol can be done automatically using the
> appropriate 'select' statements. However, none of the existing legacy options
> does it this way. Moreover, I think it's intentional that the user is notified
> of the change, so that the removal of the legacy options in later buildroot
> versions no longer poses a problem.

Does what we are doing today really makes sense? For example, option
BR2_PACKAGE_FOO_BAR is renamed to BR2_PACKAGE_FOO_BARBLEH.
BR2_PACKAGE_FOO_BAR is added to Config.in.legacy, with a message like
"Option bar for package foo has been renamed barbleh". So the user goes
into the sub-options of package "foo"... and discovers that barbleh is
already enabled. So he kind of wonders what sort of drug Buildroot
developers are taking, no?

When there is a direct 1:1 mapping between the old option and the new
option, is it really necessary to select BR2_LEGACY ?

Shouldn't be select BR2_LEGACY only when there is really a change in
behavior (like a package has been entirely removed, or a feature like
toolchain on target has been removed) ?

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 2 of 9 v4] Config.in.legacy: update description for users

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Mon, 02 Sep 2013 22:07:51 +0200, Thomas De Schampheleire wrote:

>  if BR2_LEGACY
>  comment "Your old configuration uses legacy options that no  "
> -comment "longer exist in buildroot.                          "
> -comment "Please look at the options which have been selected "
> -comment "and read their help text.                           "
> -comment "As long as these options stay selected, the build   "
> +comment "longer exist in buildroot, as indicated in the menu "
> +comment "below. As long as these options stay selected, or in"
> +comment "case of string options are non-empty, the build     "
>  comment "will fail.                                          "
> +comment "*                                                   "
> +comment "Where possible, an automatic conversion from old to "
> +comment "new symbols has been performed. Before making any   "
> +comment "change in this legacy menu, make sure to exit the   "
> +comment "configuration editor a first time and save the      "
> +comment "configuration. Otherwise, the automatic conversion  "
> +comment "of symbols will be lost.                            "

This really seems ugly for users, no? I know it's been discussed, but
can you summarize why this should be done by our users?

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 9 of 9 v4] linux: mention 3.x.y kernels in 'custom version' help

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Mon, 02 Sep 2013 22:07:58 +0200, Thomas De Schampheleire wrote:
> (also fix grammatical error versions -> version)
> 
> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Peter, I believe this one can be committed now.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 2 of 9 v4] Config.in.legacy: update description for users

[Arnout Vandecappelle]

On 09/02/13 22:55, Thomas Petazzoni wrote:
> Dear Thomas De Schampheleire,
>
> On Mon, 02 Sep 2013 22:07:51 +0200, Thomas De Schampheleire wrote:
>
>>   if BR2_LEGACY
>>   comment "Your old configuration uses legacy options that no  "
>> -comment "longer exist in buildroot.                          "
>> -comment "Please look at the options which have been selected "
>> -comment "and read their help text.                           "
>> -comment "As long as these options stay selected, the build   "
>> +comment "longer exist in buildroot, as indicated in the menu "
>> +comment "below. As long as these options stay selected, or in"
>> +comment "case of string options are non-empty, the build     "
>>   comment "will fail.                                          "
>> +comment "*                                                   "
>> +comment "Where possible, an automatic conversion from old to "
>> +comment "new symbols has been performed. Before making any   "
>> +comment "change in this legacy menu, make sure to exit the   "
>> +comment "configuration editor a first time and save the      "
>> +comment "configuration. Otherwise, the automatic conversion  "
>> +comment "of symbols will be lost.                            "
>
> This really seems ugly for users, no? I know it's been discussed, but
> can you summarize why this should be done by our users?

  I.e., add "because of Kconfig limitations", right?

  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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 2 of 9 v4] Config.in.legacy: update description for users

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Tue, 03 Sep 2013 08:16:04 +0200, Arnout Vandecappelle wrote:

> >>   if BR2_LEGACY
> >>   comment "Your old configuration uses legacy options that no  "
> >> -comment "longer exist in buildroot.                          "
> >> -comment "Please look at the options which have been selected "
> >> -comment "and read their help text.                           "
> >> -comment "As long as these options stay selected, the build   "
> >> +comment "longer exist in buildroot, as indicated in the menu "
> >> +comment "below. As long as these options stay selected, or in"
> >> +comment "case of string options are non-empty, the build     "
> >>   comment "will fail.                                          "
> >> +comment "*                                                   "
> >> +comment "Where possible, an automatic conversion from old to "
> >> +comment "new symbols has been performed. Before making any   "
> >> +comment "change in this legacy menu, make sure to exit the   "
> >> +comment "configuration editor a first time and save the      "
> >> +comment "configuration. Otherwise, the automatic conversion  "
> >> +comment "of symbols will be lost.                            "
> >
> > This really seems ugly for users, no? I know it's been discussed, but
> > can you summarize why this should be done by our users?
> 
>   I.e., add "because of Kconfig limitations", right?

That I understood, but for my own culture, can you summarize what are
those limitations? Maybe it would be good to document them in the big
fat comment inside Config.in.legacy (not the one shown to the user, but
the one inside the source code). Having to exit menuconfig, and restart
it doesn't seem like a really great thing, so I'd like to understand
why we need that, and what are our options to maybe solve this in the
future.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 2 of 9 v4] Config.in.legacy: update description for users

[Thomas De Schampheleire]

Hi Thomas, all,

On Tue, Sep 3, 2013 at 9:18 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Arnout Vandecappelle,
>
> On Tue, 03 Sep 2013 08:16:04 +0200, Arnout Vandecappelle wrote:
>
>> >>   if BR2_LEGACY
>> >>   comment "Your old configuration uses legacy options that no  "
>> >> -comment "longer exist in buildroot.                          "
>> >> -comment "Please look at the options which have been selected "
>> >> -comment "and read their help text.                           "
>> >> -comment "As long as these options stay selected, the build   "
>> >> +comment "longer exist in buildroot, as indicated in the menu "
>> >> +comment "below. As long as these options stay selected, or in"
>> >> +comment "case of string options are non-empty, the build     "
>> >>   comment "will fail.                                          "
>> >> +comment "*                                                   "
>> >> +comment "Where possible, an automatic conversion from old to "
>> >> +comment "new symbols has been performed. Before making any   "
>> >> +comment "change in this legacy menu, make sure to exit the   "
>> >> +comment "configuration editor a first time and save the      "
>> >> +comment "configuration. Otherwise, the automatic conversion  "
>> >> +comment "of symbols will be lost.                            "
>> >
>> > This really seems ugly for users, no? I know it's been discussed, but
>> > can you summarize why this should be done by our users?
>>
>>   I.e., add "because of Kconfig limitations", right?
>
> That I understood, but for my own culture, can you summarize what are
> those limitations? Maybe it would be good to document them in the big
> fat comment inside Config.in.legacy (not the one shown to the user, but
> the one inside the source code). Having to exit menuconfig, and restart
> it doesn't seem like a really great thing, so I'd like to understand
> why we need that, and what are our options to maybe solve this in the
> future.
>

The basic problem is that kconfig seems to remember how a given symbol
was selected, *within one kconfig session*. 'How' can be: explicitly
selected by the user, or selected through a 'select' statement of
another symbol. In the latter case, when the first symbol is disabled,
the 'selected' symbol is also automatically disabled.
When you start a new kconfig session (by saving the configuration and
reopening it) kconfig has no clue anymore about how the different
symbols became selected, because clearly there is no indication about
this whatsoever in the .config file.

Applied to the legacy symbols: suppose symbol FOO is renamed into BAR,
and we have made the legacy symbol FOO 'select' the new symbol BAR
through Config.in.legacy. The user opens the menuconfig, sees that
there is something in the legacy menu, reads the help text, goes to
the menu where FOO used to be selected, sees that BAR is already
correctly selected thanks to the automatic propagation, and decides to
clear the legacy FOO symbol in the legacy menu. Then he saves the
configuration.
If you check the .config file afterwards (or even if you check the BAR
symbol after deselecting FOO before exiting menuconfig) you will see
that BAR is no longer selected. The only way to saveguard that is by
saving the configuration before fiddling with the legacy menu, thereby
'flattening' the symbols.

Provided we want automatic propagation of symbols (boolean or
otherwise), I don't see another solution.
See also the other thread where you asked whether it's at all logical
to have something in legacy for such renames.

Best regards,
Thomas

[Buildroot] [PATCH 2 of 9 v4] Config.in.legacy: update description for users

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Tue, 3 Sep 2013 13:42:39 +0200, Thomas De Schampheleire wrote:

> >> > This really seems ugly for users, no? I know it's been discussed, but
> >> > can you summarize why this should be done by our users?
> >>
> >>   I.e., add "because of Kconfig limitations", right?
> >
> > That I understood, but for my own culture, can you summarize what are
> > those limitations? Maybe it would be good to document them in the big
> > fat comment inside Config.in.legacy (not the one shown to the user, but
> > the one inside the source code). Having to exit menuconfig, and restart
> > it doesn't seem like a really great thing, so I'd like to understand
> > why we need that, and what are our options to maybe solve this in the
> > future.
> >
> 
> The basic problem is that kconfig seems to remember how a given symbol
> was selected, *within one kconfig session*. 'How' can be: explicitly
> selected by the user, or selected through a 'select' statement of
> another symbol. In the latter case, when the first symbol is disabled,
> the 'selected' symbol is also automatically disabled.
> When you start a new kconfig session (by saving the configuration and
> reopening it) kconfig has no clue anymore about how the different
> symbols became selected, because clearly there is no indication about
> this whatsoever in the .config file.
> 
> Applied to the legacy symbols: suppose symbol FOO is renamed into BAR,
> and we have made the legacy symbol FOO 'select' the new symbol BAR
> through Config.in.legacy. The user opens the menuconfig, sees that
> there is something in the legacy menu, reads the help text, goes to
> the menu where FOO used to be selected, sees that BAR is already
> correctly selected thanks to the automatic propagation, and decides to
> clear the legacy FOO symbol in the legacy menu. Then he saves the
> configuration.
> If you check the .config file afterwards (or even if you check the BAR
> symbol after deselecting FOO before exiting menuconfig) you will see
> that BAR is no longer selected. The only way to saveguard that is by
> saving the configuration before fiddling with the legacy menu, thereby
> 'flattening' the symbols.

Thanks for the great summary. I now understand the problem (sorry for
being slow).

> Provided we want automatic propagation of symbols (boolean or
> otherwise), I don't see another solution.
> See also the other thread where you asked whether it's at all logical
> to have something in legacy for such renames.

In the light of this, I indeed restate my question asking whether it's
logical to select BR2_LEGACY for renames that are equivalent.

So I believe I would rather classify the legacy options in two
categories:

 (1) Options that have been renamed, or can be approximated in such a
     close way that letting the user know about the rename or change is
     not important: we simply add an hidden Config.in.legacy symbol that
     selects the new relevant option. This legacy symbol does not select
     BR2_LEGACY, and things are fully transparent for the user. Of
     course the symbol remains =y in the .config file, but it's clearly
     identified as such.

 (2) Options that have been removed, or changed in such a way that it's
     not possible to approximate the modification by selecting other
     options. In this case, the legacy Config.in.legacy symbol is not
     hidden, and only selects BR2_LEGACY and no other option, and the
     user is requested to act by disabling this option and doing the
     necessary configuration changes.

So far, the only problem I see with this are related to minimal
defconfigs. In the case (1) above, the minimal defconfig will continue
to contain the name of the legacy option, and not the name of the new
option, since the new option is selected by the legacy option. This is
annoying since it means minimal defconfigs are not progressively
updated to use the new option name. And this probably makes my entire
proposal moot.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 1 of 9 v4] Config.in.legacy: update description for developers

[Thomas De Schampheleire]

Hi Thomas, all,

On Mon, Sep 2, 2013 at 10:54 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Mon, 02 Sep 2013 22:07:50 +0200, Thomas De Schampheleire wrote:
>
>> The existing comments in Config.in.legacy are not entirely in-line with
>> current practice. The comments implies that BR2_LEGACY should not be set when
>> the conversion from old-to-new symbol can be done automatically using the
>> appropriate 'select' statements. However, none of the existing legacy options
>> does it this way. Moreover, I think it's intentional that the user is notified
>> of the change, so that the removal of the legacy options in later buildroot
>> versions no longer poses a problem.
>
> Does what we are doing today really makes sense? For example, option
> BR2_PACKAGE_FOO_BAR is renamed to BR2_PACKAGE_FOO_BARBLEH.
> BR2_PACKAGE_FOO_BAR is added to Config.in.legacy, with a message like
> "Option bar for package foo has been renamed barbleh". So the user goes
> into the sub-options of package "foo"... and discovers that barbleh is
> already enabled. So he kind of wonders what sort of drug Buildroot
> developers are taking, no?

:-D

>
> When there is a direct 1:1 mapping between the old option and the new
> option, is it really necessary to select BR2_LEGACY ?
>
> Shouldn't be select BR2_LEGACY only when there is really a change in
> behavior (like a package has been entirely removed, or a feature like
> toolchain on target has been removed) ?

I think there are only a few options:

1. Don't ever rename or remove symbols (so no legacy problems ever). I
don't think this is feasible/desirable.

2. Allow symbols to be renamed/removed if there is a good reason for
it, but only mention it in the README or Changelog when there is a new
release (no legacy menu). In this case, the user is completely on his
own when migrating to another buildroot release, every action is
manual. This was the situation before the legacy menu was introduced.

3. Use a legacy menu for renamed/removed symbols, indicating which
symbols are now legacy. Don't do any automatic propagation of old to
new symbols: simply warn the user and let him/her review and update
the configuration. This is the simplest to implement, there are also
no problems with weird kconfig behavior. By disabling the legacy
option, the user simply acknowledges that he has seen the legacy
messages, and the rest of the configuration remains untouched.

4. Use a legacy menu as in 3., but additionally perform automatic
propagation of old to new symbols where possible and appropriate. This
means 'select'ing the right symbols, and also introducing the
following kconfig behavior: if you disable the legacy option that
automatically selected the new symbol, the new symbol will be disabled
too if you did not save your configuration yet (see my other patch and
the resulting discussion). This is what is done at the moment, and
this is the same path my patch series was continuing on.

5. Use a legacy menu only for symbols that cannot be automatically
propagated. For all other legacy symbols, do the automatic propagation
but do not inform the user. Here you will still have an old symbol
'select'ing the new one, and the old symbol should remain hidden (I
think, to not confuse the user). I haven't tried this yet, but in my
understanding the old symbol will remain selected, and will also be
part of the defconfig. This would be confusing.
Since in this case there is no communication to the user, I think
there can be a problem with migration of defconfigs. Consider the
following: a user starts with buildroot version A, saves his project's
defconfig. Then he migrates to version B, in which some symbols have
been marked as legacy, but automatically propagated. The user does not
see a reason to update his defconfig as everything still works and he
doesn't know better. Then, he migrates to buildroot version C, where
the legacy symbols have suddenly been removed. Since his defconfig was
not changed, there is no reference to the new alternatives of the
legacy symbols, and his configuration is suddenly dysfunctional. I
think this is not very nice.
If the user would have been warned between the A->B transition, he
would have realized he needed to save a new defconfig, and the
transition from B->C would be successful.


As it stands, I'm leaning towards 3 or 4, but am open for discussion.

Best regards,
Thomas

[Buildroot] [PATCH 2 of 9 v4] Config.in.legacy: update description for users

[Peter Korsgaard]

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


 Thomas> So far, the only problem I see with this are related to minimal
 Thomas> defconfigs. In the case (1) above, the minimal defconfig will continue
 Thomas> to contain the name of the legacy option, and not the name of the new
 Thomas> option, since the new option is selected by the legacy option. This is
 Thomas> annoying since it means minimal defconfigs are not progressively
 Thomas> updated to use the new option name. And this probably makes my entire
 Thomas> proposal moot.

Damn, yes :/

So people really do need to explictly change to the new option / restart
make menuconfig.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 1 of 9 v4] Config.in.legacy: update description for developers

[Arnout Vandecappelle]

On 09/03/13 14:13, Thomas De Schampheleire wrote:
> Hi Thomas, all,
>
> On Mon, Sep 2, 2013 at 10:54 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
[snip]
>> When there is a direct 1:1 mapping between the old option and the new
>> option, is it really necessary to select BR2_LEGACY ?
>>
>> Shouldn't be select BR2_LEGACY only when there is really a change in
>> behavior (like a package has been entirely removed, or a feature like
>> toolchain on target has been removed) ?
>
> I think there are only a few options:

  Nice analysis!


> 1. Don't ever rename or remove symbols (so no legacy problems ever). I
> don't think this is feasible/desirable.

  This was actually more or less the intention when the Config.in.legacy 
was introduced. It was not really intended for giving Kconfig symbols 
more consistent names. Instead, it was intended to have a path forward in 
a situation as for gettext/libintl. There used to be a 
BR2_PACKAGE_LIBINTL symbol, which actually enabled an option in the 
gettext package instead of selecting the libintl package.

  Peter's point of view was/is that the Kconfig symbols are not visible 
to the user, so the user doesn't care about inconsistencies there. 
However, if a symbol is renamed, it suddenly does become visible to the 
user (even with the current legacy approach), so that should be avoided.


> 2. Allow symbols to be renamed/removed if there is a good reason for
> it, but only mention it in the README or Changelog when there is a new
> release (no legacy menu). In this case, the user is completely on his
> own when migrating to another buildroot release, every action is
> manual. This was the situation before the legacy menu was introduced.
>
> 3. Use a legacy menu for renamed/removed symbols, indicating which
> symbols are now legacy. Don't do any automatic propagation of old to
> new symbols: simply warn the user and let him/her review and update
> the configuration. This is the simplest to implement, there are also
> no problems with weird kconfig behavior. By disabling the legacy
> option, the user simply acknowledges that he has seen the legacy
> messages, and the rest of the configuration remains untouched.
>
> 4. Use a legacy menu as in 3., but additionally perform automatic
> propagation of old to new symbols where possible and appropriate. This
> means 'select'ing the right symbols, and also introducing the
> following kconfig behavior: if you disable the legacy option that
> automatically selected the new symbol, the new symbol will be disabled
> too if you did not save your configuration yet (see my other patch and
> the resulting discussion). This is what is done at the moment, and
> this is the same path my patch series was continuing on.
>
> 5. Use a legacy menu only for symbols that cannot be automatically
> propagated. For all other legacy symbols, do the automatic propagation
> but do not inform the user. Here you will still have an old symbol
> 'select'ing the new one, and the old symbol should remain hidden (I
> think, to not confuse the user). I haven't tried this yet, but in my
> understanding the old symbol will remain selected, and will also be
> part of the defconfig. This would be confusing.

  It's even worse.

  The option _must_ remain visible, otherwise it is stripped from the 
.config when it is read in.

  Also, when a defconfig is saved, it will be saved under the old name 
and the new name will not appear in the defconfig. So if the legacy part 
is removed a couple of years down the line, users who rely on defconfigs 
are screwed.


  IMHO, Kconfig is just too limited to do all the things we want to do.


> Since in this case there is no communication to the user, I think
> there can be a problem with migration of defconfigs. Consider the
> following: a user starts with buildroot version A, saves his project's
> defconfig. Then he migrates to version B, in which some symbols have
> been marked as legacy, but automatically propagated. The user does not
> see a reason to update his defconfig as everything still works and he
> doesn't know better. Then, he migrates to buildroot version C, where
> the legacy symbols have suddenly been removed. Since his defconfig was
> not changed, there is no reference to the new alternatives of the
> legacy symbols, and his configuration is suddenly dysfunctional. I
> think this is not very nice.
> If the user would have been warned between the A->B transition, he
> would have realized he needed to save a new defconfig, and the
> transition from B->C would be successful.
>
>
> As it stands, I'm leaning towards 3 or 4, but am open for discussion.

  I prefer to keep things as they are, i.e. option 4.

  I'm also in favour of minimizing the number of simple renames. For 
instance, I think the rename of BR2_PACKAGE_DOSFSTOOLS_DOSFSCK was 
unnecessary.

  Regards,
  Arnout

>
> Best regards,
> Thomas
>
>


-- 
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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 2 of 9 v4] Config.in.legacy: update description for users

[Arnout Vandecappelle]

On 09/03/13 17:06, Peter Korsgaard wrote:
>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
>
>
>   Thomas> So far, the only problem I see with this are related to minimal
>   Thomas> defconfigs. In the case (1) above, the minimal defconfig will continue
>   Thomas> to contain the name of the legacy option, and not the name of the new
>   Thomas> option, since the new option is selected by the legacy option. This is
>   Thomas> annoying since it means minimal defconfigs are not progressively
>   Thomas> updated to use the new option name. And this probably makes my entire
>   Thomas> proposal moot.
>
> Damn, yes :/
>
> So people really do need to explictly change to the new option / restart
> make menuconfig.

  I never tried it, but a workaround could be to run olddefconfig before 
any interactive config (menuconfig, nconfig, xconfig, qconfig). 
olddefconfig should be equivalent to saving immediately.

  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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 2 of 9 v4] Config.in.legacy: update description for users

[Thomas De Schampheleire]

Hi Arnout,

On Tue, Sep 3, 2013 at 6:50 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 09/03/13 17:06, Peter Korsgaard wrote:
>>>>>>>
>>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>>>>>>> writes:
>>
>>
>>
>>   Thomas> So far, the only problem I see with this are related to minimal
>>   Thomas> defconfigs. In the case (1) above, the minimal defconfig will
>> continue
>>   Thomas> to contain the name of the legacy option, and not the name of
>> the new
>>   Thomas> option, since the new option is selected by the legacy option.
>> This is
>>   Thomas> annoying since it means minimal defconfigs are not progressively
>>   Thomas> updated to use the new option name. And this probably makes my
>> entire
>>   Thomas> proposal moot.
>>
>> Damn, yes :/
>>
>> So people really do need to explictly change to the new option / restart
>> make menuconfig.
>
>
>  I never tried it, but a workaround could be to run olddefconfig before any
> interactive config (menuconfig, nconfig, xconfig, qconfig). olddefconfig
> should be equivalent to saving immediately.

I tried it manually (not yet integrated in a Makefile) and it works as expected.
However, a disadvantage is that any new symbol will no longer be
marked as NEW in the interactive config. So the trade-off would be
between loosing this NEW marker, and requiring the user to do an
intermediate save.

Best regards,
Thomas

[Buildroot] [PATCH 2 of 9 v4] Config.in.legacy: update description for users

[Arnout Vandecappelle]

On 09/04/13 10:33, Thomas De Schampheleire wrote:
> Hi Arnout,
>
> On Tue, Sep 3, 2013 at 6:50 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
>> On 09/03/13 17:06, Peter Korsgaard wrote:
>>>>>>>>
>>>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>>>>>>>> writes:
>>>
>>>
>>>
>>>    Thomas> So far, the only problem I see with this are related to minimal
>>>    Thomas> defconfigs. In the case (1) above, the minimal defconfig will
>>> continue
>>>    Thomas> to contain the name of the legacy option, and not the name of
>>> the new
>>>    Thomas> option, since the new option is selected by the legacy option.
>>> This is
>>>    Thomas> annoying since it means minimal defconfigs are not progressively
>>>    Thomas> updated to use the new option name. And this probably makes my
>>> entire
>>>    Thomas> proposal moot.
>>>
>>> Damn, yes :/
>>>
>>> So people really do need to explictly change to the new option / restart
>>> make menuconfig.
>>
>>
>>   I never tried it, but a workaround could be to run olddefconfig before any
>> interactive config (menuconfig, nconfig, xconfig, qconfig). olddefconfig
>> should be equivalent to saving immediately.
>
> I tried it manually (not yet integrated in a Makefile) and it works as expected.
> However, a disadvantage is that any new symbol will no longer be
> marked as NEW in the interactive config. So the trade-off would be
> between loosing this NEW marker, and requiring the user to do an
> intermediate save.

  If the user does an intermediate save, the NEW marker will also be gone...

  But at least, this is only for a user that has legacy stuff, not for 
all those innocent people out there that just do a 'make menuconfig' 
after 'git pull'.

  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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 2 of 9 v4] Config.in.legacy: update description for users

[Thomas De Schampheleire]

Op 4-sep.-2013 20:35 schreef "Arnout Vandecappelle" <arnout@mind.be> het
volgende:
>
> On 09/04/13 10:33, Thomas De Schampheleire wrote:
>>
>> Hi Arnout,
>>
>> On Tue, Sep 3, 2013 at 6:50 PM, Arnout Vandecappelle <arnout@mind.be>
wrote:
>>>
>>> On 09/03/13 17:06, Peter Korsgaard wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>>>>>>>>> writes:
>>>>
>>>>
>>>>
>>>>
>>>>    Thomas> So far, the only problem I see with this are related to
minimal
>>>>    Thomas> defconfigs. In the case (1) above, the minimal defconfig
will
>>>> continue
>>>>    Thomas> to contain the name of the legacy option, and not the name
of
>>>> the new
>>>>    Thomas> option, since the new option is selected by the legacy
option.
>>>> This is
>>>>    Thomas> annoying since it means minimal defconfigs are not
progressively
>>>>    Thomas> updated to use the new option name. And this probably makes
my
>>>> entire
>>>>    Thomas> proposal moot.
>>>>
>>>> Damn, yes :/
>>>>
>>>> So people really do need to explictly change to the new option /
restart
>>>> make menuconfig.
>>>
>>>
>>>
>>>   I never tried it, but a workaround could be to run olddefconfig
before any
>>> interactive config (menuconfig, nconfig, xconfig, qconfig). olddefconfig
>>> should be equivalent to saving immediately.
>>
>>
>> I tried it manually (not yet integrated in a Makefile) and it works as
expected.
>> However, a disadvantage is that any new symbol will no longer be
>> marked as NEW in the interactive config. So the trade-off would be
>> between loosing this NEW marker, and requiring the user to do an
>> intermediate save.
>
>
>  If the user does an intermediate save, the NEW marker will also be
gone...

Yes, but before that save he does see the markers...

>
>  But at least, this is only for a user that has legacy stuff, not for all
those innocent people out there that just do a 'make menuconfig' after 'git
pull'.

Right.

To proceed with this, I think the community should decide which alternative
we prefer, knowing that each one has its pros and cons...

Looking forward to everyone's input...

Best regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130904/5990fb74/attachment-0001.html>

[Buildroot] [PATCH 0 of 9 v4] linux/uboot: add support for custom Mercurial repositories

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Mon, 02 Sep 2013 22:07:49 +0200, Thomas De Schampheleire wrote:

> This series adds support for custom Mercurial repositories in uboot and linux
> packages.
> 
> This version is rebased with the 2013.08 master, there are only a few
> real changes.

Since it seems we have issues deciding what to do with the
Config.in.legacy handling for string options, I was thinking: can't we
just avoid the problem altogether? Instead of having separate Config.in
options for each of Git, Mercurial, SVN and so on, what about just
adding an option "BR2_TARGET_LINUX_CUSTOM_REPO_METHOD" which allows the
user to select git, hg, svn or cvs, and keep the other option names
unchanged. I admit it's a bit funky to keep options such as
BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL to store the location of a
Mercurial repository, but well, since we can't make up your mind on the
Config.in.legacy stuff, maybe that's a way of at least getting your
feature merged.

I'm just thinking of a way to move forward, not sure it's the right
solution.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 0 of 9 v4] linux/uboot: add support for custom Mercurial repositories

[Thomas De Schampheleire]

Hi Thomas,

Thanks for coming back to this...

On Thu, Sep 19, 2013 at 9:49 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Mon, 02 Sep 2013 22:07:49 +0200, Thomas De Schampheleire wrote:
>
>> This series adds support for custom Mercurial repositories in uboot and linux
>> packages.
>>
>> This version is rebased with the 2013.08 master, there are only a few
>> real changes.
>
> Since it seems we have issues deciding what to do with the
> Config.in.legacy handling for string options, I was thinking: can't we
> just avoid the problem altogether? Instead of having separate Config.in
> options for each of Git, Mercurial, SVN and so on, what about just
> adding an option "BR2_TARGET_LINUX_CUSTOM_REPO_METHOD" which allows the
> user to select git, hg, svn or cvs, and keep the other option names
> unchanged. I admit it's a bit funky to keep options such as
> BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL to store the location of a
> Mercurial repository, but well, since we can't make up your mind on the
> Config.in.legacy stuff, maybe that's a way of at least getting your
> feature merged.
>
> I'm just thinking of a way to move forward, not sure it's the right
> solution.
>

Currently, both for Linux and Uboot, the choice between Git and Hg is
done via the 'Version' choice (which provides the choice between a
number of real versions, custom tarball, and git and hg). So there is
already a choice and no real separate option for each version control
system.
What my patches did was avoid adding extra options for Mercurial, by
re-using (and renaming) the git options to specify the URL and
revision. Not renaming the git options is indeed possible, but pretty
funky indeed. I'm not a big fan of this, to be honest.

It's true that it seems difficult to reach a decision in the legacy
questions. From the top of my head, the main questions are:
1. Do we want that legacy options are automatically propagated to
their new options, when possible, or should the user do this?
2. Do we accept that the user needs to save-and-reopen menuconfig in
case we opt for automatic propagation.

I see three ways out:
a. we reach a consensus
b. a decision is taken by the maintainer, possibly without consensus
c. we leave the current situation (for now)

Note that my patchset does not _change_ the current situation. Rather,
it merely documents how you should handle legacy options in this
current situation, both to the user and the developer. The Mercurial
support just follows the existing approach.
This provides a good way forward in my opinion, if a and b turn out to
be impossible: we accept the patchset as it is, knowing that it just
follows the same route as we were going, and if we want to change
something about the legacy handling we can do that later.

Note also that regardless of how we proceed, I really want this to be
part of 2013.11, because this series is already circulating for a long
time.

Best regards,
Thomas

[Buildroot] [PATCH 0 of 9 v4] linux/uboot: add support for custom Mercurial repositories

[Thomas De Schampheleire]

All,

On Fri, Sep 20, 2013 at 11:22 AM, Thomas De Schampheleire
<patrickdepinguin+buildroot@gmail.com> wrote:
> Hi Thomas,
>
> Thanks for coming back to this...
>
> On Thu, Sep 19, 2013 at 9:49 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> Dear Thomas De Schampheleire,
>>
>> On Mon, 02 Sep 2013 22:07:49 +0200, Thomas De Schampheleire wrote:
>>
>>> This series adds support for custom Mercurial repositories in uboot and linux
>>> packages.
>>>
>>> This version is rebased with the 2013.08 master, there are only a few
>>> real changes.
>>
>> Since it seems we have issues deciding what to do with the
>> Config.in.legacy handling for string options, I was thinking: can't we
>> just avoid the problem altogether? Instead of having separate Config.in
>> options for each of Git, Mercurial, SVN and so on, what about just
>> adding an option "BR2_TARGET_LINUX_CUSTOM_REPO_METHOD" which allows the
>> user to select git, hg, svn or cvs, and keep the other option names
>> unchanged. I admit it's a bit funky to keep options such as
>> BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL to store the location of a
>> Mercurial repository, but well, since we can't make up your mind on the
>> Config.in.legacy stuff, maybe that's a way of at least getting your
>> feature merged.
>>
>> I'm just thinking of a way to move forward, not sure it's the right
>> solution.
>>
>
> Currently, both for Linux and Uboot, the choice between Git and Hg is
> done via the 'Version' choice (which provides the choice between a
> number of real versions, custom tarball, and git and hg). So there is
> already a choice and no real separate option for each version control
> system.
> What my patches did was avoid adding extra options for Mercurial, by
> re-using (and renaming) the git options to specify the URL and
> revision. Not renaming the git options is indeed possible, but pretty
> funky indeed. I'm not a big fan of this, to be honest.
>
> It's true that it seems difficult to reach a decision in the legacy
> questions. From the top of my head, the main questions are:
> 1. Do we want that legacy options are automatically propagated to
> their new options, when possible, or should the user do this?
> 2. Do we accept that the user needs to save-and-reopen menuconfig in
> case we opt for automatic propagation.
>
> I see three ways out:
> a. we reach a consensus
> b. a decision is taken by the maintainer, possibly without consensus
> c. we leave the current situation (for now)
>
> Note that my patchset does not _change_ the current situation. Rather,
> it merely documents how you should handle legacy options in this
> current situation, both to the user and the developer. The Mercurial
> support just follows the existing approach.
> This provides a good way forward in my opinion, if a and b turn out to
> be impossible: we accept the patchset as it is, knowing that it just
> follows the same route as we were going, and if we want to change
> something about the legacy handling we can do that later.
>
> Note also that regardless of how we proceed, I really want this to be
> part of 2013.11, because this series is already circulating for a long
> time.

ping?

Thanks,
Thomas

[Buildroot] [PATCH 1 of 9 v4] Config.in.legacy: update description for developers

[Peter Korsgaard]

>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> writes:

Hi,

 > The existing comments in Config.in.legacy are not entirely in-line with
 > current practice. The comments implies that BR2_LEGACY should not be set when
 > the conversion from old-to-new symbol can be done automatically using the
 > appropriate 'select' statements. However, none of the existing legacy options
 > does it this way. Moreover, I think it's intentional that the user is notified
 > of the change, so that the removal of the legacy options in later buildroot
 > versions no longer poses a problem.
 > Additionally, the comments now describe how to handle string options.

 > Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
 > Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

(Finally) committed series with some minor fixups to get them to apply,
thanks!

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 1 of 9 v4] Config.in.legacy: update description for developers

[Thomas De Schampheleire]

On Sun, Oct 27, 2013 at 8:24 AM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> writes:
>
> Hi,
>
>  > The existing comments in Config.in.legacy are not entirely in-line with
>  > current practice. The comments implies that BR2_LEGACY should not be set when
>  > the conversion from old-to-new symbol can be done automatically using the
>  > appropriate 'select' statements. However, none of the existing legacy options
>  > does it this way. Moreover, I think it's intentional that the user is notified
>  > of the change, so that the removal of the legacy options in later buildroot
>  > versions no longer poses a problem.
>  > Additionally, the comments now describe how to handle string options.
>
>  > Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
>  > Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
>
> (Finally) committed series with some minor fixups to get them to apply,
> thanks!

Thanks Peter! (and also thanks to the other fabulous people present at
the Buildroot Developer Days :-) )