ktap doesn't build with recent kernels (e.g. 5.10.104-cip3 or 5.15.37)
and is not maintained anymore (latest release in 2013 and latest commit
more than 5 years ago):
In file included from /home/autobuild/autobuild/instance-6/output-1/build/ktap-23bc7a4a94bd9e4e1b8b7c06632e61c041d57b5f/./runtime/amalg.c:21:
/home/autobuild/autobuild/instance-6/output-1/build/ktap-23bc7a4a94bd9e4e1b8b7c06632e61c041d57b5f/./runtime/ktap.c:30:6: warning: "CONFIG_EVENT_TRACING" is not defined, evaluates to 0 [-Wundef]
30 | #if !CONFIG_EVENT_TRACING
| ^~~~~~~~~~~~~~~~~~~~
/home/autobuild/autobuild/instance-6/output-1/build/ktap-23bc7a4a94bd9e4e1b8b7c06632e61c041d57b5f/./runtime/ktap.c:31:2: error: #error "Please enable CONFIG_EVENT_TRACING before compile ktap"
31 | #error "Please enable CONFIG_EVENT_TRACING before compile ktap"
| ^~~~~
In file included from /home/autobuild/autobuild/instance-6/output-1/build/ktap-23bc7a4a94bd9e4e1b8b7c06632e61c041d57b5f/./runtime/amalg.c:21:
/home/autobuild/autobuild/instance-6/output-1/build/ktap-23bc7a4a94bd9e4e1b8b7c06632e61c041d57b5f/./runtime/ktap.c: In function ‘gettimeofday_ns’:
/home/autobuild/autobuild/instance-6/output-1/build/ktap-23bc7a4a94bd9e4e1b8b7c06632e61c041d57b5f/./runtime/ktap.c:56:18: error: storage size of ‘now’ isn’t known
56 | struct timespec now;
| ^~~
/home/autobuild/autobuild/instance-6/output-1/build/ktap-23bc7a4a94bd9e4e1b8b7c06632e61c041d57b5f/./runtime/ktap.c:58:2: error: implicit declaration of function ‘getnstimeofday’; did you mean ‘gettimeofday_ns’? [-Werror=implicit-function-declaration]
58 | getnstimeofday(&now);
| ^~~~~~~~~~~~~~
| gettimeofday_ns
/home/autobuild/autobuild/instance-6/output-1/build/ktap-23bc7a4a94bd9e4e1b8b7c06632e61c041d57b5f/./runtime/ktap.c:56:18: warning: unused variable ‘now’ [-Wunused-variable]
56 | struct timespec now;
| ^~~
In file included from /home/autobuild/autobuild/instance-6/output-1/build/ktap-23bc7a4a94bd9e4e1b8b7c06632e61c041d57b5f/./runtime/amalg.c:22:
/home/autobuild/autobuild/instance-6/output-1/build/ktap-23bc7a4a94bd9e4e1b8b7c06632e61c041d57b5f/./runtime/kp_obj.c: In function ‘kp_obj_kstack2str’:
/home/autobuild/autobuild/instance-6/output-1/build/ktap-23bc7a4a94bd9e4e1b8b7c06632e61c041d57b5f/./runtime/kp_obj.c:243:21: error: storage size of ‘trace’ isn’t known
243 | struct stack_trace trace;
| ^~~~~
/home/autobuild/autobuild/instance-6/output-1/build/ktap-23bc7a4a94bd9e4e1b8b7c06632e61c041d57b5f/./runtime/kp_obj.c:253:2: error: implicit declaration of function ‘save_stack_trace’ [-Werror=implicit-function-declaration]
253 | save_stack_trace(&trace);
| ^~~~~~~~~~~~~~~~
/home/autobuild/autobuild/instance-6/output-1/build/ktap-23bc7a4a94bd9e4e1b8b7c06632e61c041d57b5f/./runtime/kp_obj.c:243:21: warning: unused variable ‘trace’ [-Wunused-variable]
243 | struct stack_trace trace;
| ^~~~~
In file included from /home/autobuild/autobuild/instance-6/output-1/build/ktap-23bc7a4a94bd9e4e1b8b7c06632e61c041d57b5f/./runtime/amalg.c:27:
/home/autobuild/autobuild/instance-6/output-1/build/ktap-23bc7a4a94bd9e4e1b8b7c06632e61c041d57b5f/./runtime/kp_transport.c: In function ‘trace_empty’:
/home/autobuild/autobuild/instance-6/output-1/build/ktap-23bc7a4a94bd9e4e1b8b7c06632e61c041d57b5f/./runtime/kp_transport.c:105:39: error: passing argument 1 of ‘ring_buffer_empty_cpu’ from incompatible pointer type [-Werror=incompatible-pointer-types]
105 | if (!ring_buffer_empty_cpu(ktap_iter->buffer, cpu))
| ~~~~~~~~~^~~~~~~~
| |
| struct ring_buffer *
In file included from ./include/linux/trace_events.h:6,
from /home/autobuild/autobuild/instance-6/output-1/build/ktap-23bc7a4a94bd9e4e1b8b7c06632e61c041d57b5f/./runtime/trace_events.h:5,
from /home/autobuild/autobuild/instance-6/output-1/build/ktap-23bc7a4a94bd9e4e1b8b7c06632e61c041d57b5f/./runtime/kp_events.h:4,
from /home/autobuild/autobuild/instance-6/output-1/build/ktap-23bc7a4a94bd9e4e1b8b7c06632e61c041d57b5f/./runtime/kp_str.c:35,
from /home/autobuild/autobuild/instance-6/output-1/build/ktap-23bc7a4a94bd9e4e1b8b7c06632e61c041d57b5f/./runtime/amalg.c:24:
./include/linux/ring_buffer.h:162:49: note: expected ‘struct trace_buffer *’ but argument is of type ‘struct ring_buffer *’
162 | bool ring_buffer_empty_cpu(struct trace_buffer *buffer, int cpu);
| ~~~~~~~~~~~~~~~~~~~~~^~~~~~
In file included from /home/autobuild/autobuild/instance-6/output-1/build/ktap-23bc7a4a94bd9e4e1b8b7c06632e61c041d57b5f/./runtime/amalg.c:27:
/home/autobuild/autobuild/instance-6/output-1/build/ktap-23bc7a4a94bd9e4e1b8b7c06632e61c041d57b5f/./runtime/kp_transport.c: In function ‘trace_consume’:
/home/autobuild/autobuild/instance-6/output-1/build/ktap-23bc7a4a94bd9e4e1b8b7c06632e61c041d57b5f/./runtime/kp_transport.c:116:31: error: passing argument 1 of ‘ring_buffer_consume’ from incompatible pointer type [-Werror=incompatible-pointer-types]
116 | ring_buffer_consume(ktap_iter->buffer, iter->cpu, &iter->ts,
| ~~~~~~~~~^~~~~~~~
| |
| struct ring_buffer *
Fixes:
- http://autobuild.buildroot.org/results/9067192962b4011e0da27ac2b2dc53eb1e31582c
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The prompt and variable name for the OCI "entrypoint arguments" are
somewhat incorrect. Indeed, they are in fact used to set the image
"command". Yet, using "command" would be confusing too, because the
interplay between entrypoint and command is tricky [0].
TL-DR; when both entrrypoint and command are set, command acts as
arguments passed to the entrypoint.
Additionally, we currently can only pass a single item as either
entrypoint or command. This precludes passing actual arguments to the
entrypoint, or passing multiple arguments as command.
For example:
BR2_TARGET_ROOTFS_OCI_ENTRYPOINT="/bin/tini -g -p SIGTERM --"
BR2_TARGET_ROOTFS_OCI_ENTRYPOINT_ARGS="/usr/bin/env sh"
generates an images with (only relevant fields are included below):
{
"config": {
"Entrypoint": [ "/bin/tini -g -p SIGTERM --" ],
"Cmd": [ "/usr/bin/env sh" ]
}
}
This is obviously incorrect, and not what one would expect:
{
"config": {
"Entrypoint": [ "/bin/tini", "-g", "-p", "SIGTERM", "--" ],
"Cmd": [ "/usr/bin/env", "sh" ]
}
}
However, some people do want to be able to pass an actual shell
scriptlet as a command, such as:
{
"config": {
"Entrypoint": [ "/bin/sh", "-c" ],
"Cmd": [ "my shell logic goes here" ]
}
}
Handling both is obviously conflicting: we can't both split-on-spaces
and not-split-on-spaces at the same time...
So, we fix that in two ways:
- make the current _OCI_ENTRYPOINT_ARGS a legacy option, and introduce
the new _OCI_CMD option with different semantics (see below) and an
appropriate prompt;
- we interpret both _OCI_ENTRYPOINT and _OCI_CMD as shell strings,
which we subject to the usual shell quoting [1] and token
recognition [2];
Since _OCI_ENTRYPOINT_ARGS used to be interpreted as a single string, we
can't easily change its meaning to be a space-separated list, as that
would break existing setups, which is the reason we make it legacy and
introduce a new option.
Ideally, we would like to default the new option _OCI_CMD to be the
quoted value of the previous _OCI_ENTRYPOINT_ARGS, but this is not
possible in Kconfig. Still, users that had a _OCI_ENTRYPOINT_ARGS set
will now get an early build error, and can still detect they need to do
something about it.
As for _OCI_ENTRYPOINT, it does not make much sense to support both cases.
Indeed, without splitting on spaces, we'd end up with an entrypoint that
would have a single item:
{
"config": {
"entrypoint: [ "some string with some spaces" ]
}
}
which in this case would try to execute the program which name is
actually "some string with some spaces", so we do not expect that
existing entrypoints are set with any space in them, and so the new
behaviour, unlike for _OCI_ENTRYPOINT_ARGS vs. _OCI_CMD, is compatible
with existing configurations, and so we do not need to make it a legacy
option and introduce a new one.
[0] https://docs.docker.com/engine/reference/builder/#understand-how-cmd-and-entrypoint-interact
[1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02
[2] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_03
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Sergio Prado <sergio.prado@e-labworks.com>
Cc: Matthew Weber <matthew.weber@collins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The 5.16.x series is now EOL upstream, so drop the linux-headers option and
add legacy handling for it.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The 4.4.x series is now EOL upstream, so drop the linux-headers option and
add legacy handling for it.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Now that recent versions of binutils work with FLAT binaries, we can
drop the old 2.32 version, which was kept only to keep support FLAT
binaries.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Until commit "arch/Config.in.sh: fixup MMU selection" in this series,
SH2A could either be used with BR2_USE_MMU disabled or BR2_USE_MMU
enabled.
The later made absolutely no sense, since SH2A does not have a MMU:
MMU support was introduced starting from SH3 according to
https://en.wikipedia.org/wiki/SuperH#SH-3
Also, since commit 22d5501e03 ("arch:
tidy up binary formats config"), which was merged in Buildroot
2015.05, the architecture tuple used when BR2_sh2a=y and BR2_USE_MMU
disabled is sh2a-buildroot-uclinux-uclibc, and this was already
unsupported back in the days of Buildroot 2015.08 and binutils 2.24,
causing the build to fail with:
*** BFD does not support target sh2a-buildroot-uclinux-uclibc.
just like it fails to build today with recent version of binutils.
So, this has been broken since 2015.08, and nobody complained. SH2A is
seldom used, so it's time to kill it.
It is worth mentioning that there had been an attempt at resurrecting
SH2 support around 2015 (see https://lwn.net/Articles/647636/) as part
of the J2 core. This effort led to the addition of FDPIC support for
SH2A in the musl C library (and therefore proper ELF binaries, with
shared libraries), but that was never supported in Buildroot. Now that
the J2 project is essentially dead, there is no reason to bother with
this.
Fixes:
http://autobuild.buildroot.net/results/63d01d33ae30f86b63b9f42a9fea116f2f3e9005/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Drop boost tagged layout which raises the following build failure with
botan or libcpprestsdk:
/nvmedata/autobuild/instance-31/output-1/host/opt/ext-toolchain/bin/../lib/gcc/m68k-buildroot-linux-uclibc/11.2.0/../../../../m68k-buildroot-linux-uclibc/bin/ld: cannot find -lboost_system
CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find Boost (missing: random system thread filesystem chrono
atomic date_time regex) (found version "1.78.0")
While at it:
- drop BR2_PACKAGE_BOOST_LAYOUT and BR2_PACKAGE_BOOST_LAYOUT_SYSTEM
- move --layout=system, --ignore-site-config,
--user-config=$(@D)/user-config.jam, -j$(PARALLEL_JOBS), -q and
--prefix=$(HOST_DIR) to BOOST_OPTS and HOST_BOOST_OPTS
- drop parentheses to avoid spawning a useless sub-shell
- use b2 everywhere instead of mixing b2 and
tools/build/src/engine/bjam
- drop uneeded 'echo "" >> $(@D)/user-config.jam'
BR2_PACKAGE_BOOST_LAYOUT_SYSTEM is not added to Config.in.legacy since
nothing changes for configs which already had it selected.
Fixes:
- http://autobuild.buildroot.org/results/f237c9345faf8c28f3c73f7d8acb49271fe61780
- http://autobuild.buildroot.org/results/a73225e40fa29bc3b24f36a86719e80c8e469d1f
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[Arnout: don't add BR2_PACKAGE_BOOST_LAYOUT_SYSTEM to Config.in.legacy]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Changelog: https://curl.se/changes.html
Updated license hash due to copyright year bump:
0409192b1f
The NSS crypto backend requires a special option now, without it
configure errors out with:
configure: error: NSS use must be confirmed using --with-nss-deprecated. NSS support will be dropped from curl in August 2022. See docs/DEPRECATE.md
Since it will be removed entirely soon anyway, and since this version
doesn't fix any CVEs so doesn't need to be backported to stable
branches, drop the NSS option entirely.
Since NSS is going to be removed soon, drop the --without-nss as well.
It is never going to be enabled automatically.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
[Arnout: drop NSS option entirely, as suggested by Baruch Siach.]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Even with the two upstream patches added in commit
b2e6e376a2, python-pycli still raises the
following build failure since bump of python3 to version 3.10.1 in
commit 25b1fc2898 due to the new "Multiple
Exception types without parentheses" exception
(https://docs.python.org/3/whatsnew/3.10.html):
error: File "/usr/lib/python3.10/site-packages/cli/test.py", line 142
except raises, e:
^^^^^^^^^
SyntaxError: multiple exception types must be parenthesized
So drop the package as the last release was made 10 years ago.
Fixes:
- http://autobuild.buildroot.org/results/6112e1830ce608abcea4a26b659c10e5ff09a66a
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Move the target bpftool build out of linux-tools so that it is
up to date.
This also fixes build issues due to differences between kernel
versions. The latest version should be fully backwards compatible.
The host bpftool is needed for enabling features such as the systemd
bpf-framework (to be added in a future patch).
Use the git download method to get the libbpf submodule.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
- removed 0001-neon-Allow-building-against-neon-0-32-x.patch
(from upstream [1])
- add codecalpha option (VP8/VP9 alpha support)
- add qroverlay option (overlay data on top of video in the form of a QR code)
with json-glib and libqrencode dependencies (omit json-glib explicit
dependencies as they are the same as for gstreamer1, glib2 BR2_USE_WCHAR,
BR2_TOOLCHAIN_HAS_THREADS and BR2_USE_MMU), place instead to 'plugins without
external deps' section into 'plugins that need external deps' section as it
clearly has dependencies (prelimary to upstream commit [2])
- add aes option (AES encryption/decryption plugin)
- disable new option asio (Steinberg Audio Streaming, windows only)
- disable new option gs (Google Cloud Storage, needs storage_client library)
- disable new option ldac (LDAC bluetooth audio codec, needs ldacBT-enc library)
- remove legacy option ofa (disabled)
- disable new option onnx (ONNX neural network, needs libonnxruntime library)
- disable new option isac (iSAC plugin, needs webrtc-audio-coding-1 library)
- removed libmms ('Microsoft Multi Media Server streaming protocol' option,
add Config.in.legacy entry
- enable new gpl option ('Allow build plugins that have (A)GPL-licensed
dependencies') in case gpl plugin enabled
[1] b83e85ab67.patch
[2] 5d70c168b3.patch
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Python 2.7 is EOL since April 2020, so drop support for the target package.
https://www.python.org/dev/peps/pep-0373/
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Since commit 6dd5a33c48 (zynq_zed: bump U-Boot to xilinx-v2016.2), we
have no in-tree users of zynq-boot-bin.py, as U-Boot has since v2016.01
been able to natively generate Xilinx images.
zynq-boot-bin.py is python2-only and there is zero chance that upstream
will move it to python3. We could carry a python3-compatible copy, but
that tool is now virtually unused.
6 years have passed now; let it rest in peace at last.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: James Hilliard <james.hilliard1@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Move rpi-bt-firmware and rpi-wifi-firmware packages to the new
brcmfmac_sdio-firmware-rpi one (as they are the same upstream
package).
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
[yann.morin.1998@free.fr:
- fix check-package
- legacy symbols still depend on arm || aarch64
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Since at least gdb 7.8, python3 support has been available. As part of
the progressive retiring of python2 support, it is time to drop its
support in gdb by:
- Removing BR2_PACKAGE_HOST_GDB_PYTHON in package/gdb/Config.in.host
and removing the choice to leave just a BR2_PACKAGE_HOST_GDB_PYTHON3
option.
- Adding BR2_PACKAGE_HOST_GDB_PYTHON to Config.in.legacy
- Changing depends on BR2_PACKAGE_PYTHON || BR2_PACKAGE_PYTHON3 to
depends on BR2_PACKAGE_PYTHON3 in package/gdb/Config.in
Signed-off-by: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The 5.14.x series is now EOL, so drop it.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[yann.morin.1998@free.fr: actualyl drop it from the choice list]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
When the BR2_PACKAGE_SYSTEMD_TMPFILES was removed, it was added to
Config.in. The idea was to warn users who use the symbol in their
br2-external.
However, most users don't have a br2-external that uses this symbol.
Since the symbol defaults to y when systemd is enabled, they'll get this
legacy warning - which is completely meaningless for them since nothing
changes.
The annoyance of the many is worse than the possible unexpected change
for the few. And anyone actually relying on BR2_PACKAGE_SYSTEMD_TMPFILES
will probably easily discover the issue in testing (e.g. because the
tmpfiles conf is missing in the target).
Therefore, remove BR2_PACKAGE_SYSTEMD_TMPFILES from Config.in.legacy.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
python-setuptools-scm dropped python 2 support since
f0be71fbcf
resulting in the following build failure since bump to version 6.3.2 in
commit 12e3527fd9:
/buildroot/autobuild/instance-2/output-1/host/lib" INTLTOOL_PERL=/usr/bin/perl /home/buildroot/autobuild/instance-2/output-1/host/bin/python setup.py build )
File "setup.py", line 22
f"{type(self).__name__} is forbidden, "
^
Fixes:
- http://autobuild.buildroot.org/results/2f6125993de364b4a44d259f16806e6dfd792402
With python 2 support dropped, python-backports-functools-lru-cache can no
longer be built, so drop it.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since tmpfiles is no longer optional, the Config.in symbol serves no
purpose. It was only used in cryptsetup.mk, where we replace it with
BR2_PACKAGE_SYSTEMD.
Advise to do the same in Config.in.legacy.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Drop BR2_PACKAGE_CIVETWEB_WITH_LUA and enable Lua support depending on
BR2_PACKAGE_LUA and BR2_PACKAGE_LUAJIT
It should be noted that civetweb will still use its embedded version of
sqlite
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[Peter: add !BR2_STATIC_LIBS, pass LUA_SHARED_LIB_FLAG, explicitly link with
-ldl, rework order]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This package provides a Mali kernel driver for Sunxi Mali Utgard GPUs. The
trailing -mainline is historical and was used at a time when there was
two packages providing this driver. The "non-upstream" package has
been removed some time ago so before adding new packages bringing
support for other ARM Mali GPU versions or implementations, rename
sunxi-mali-mainline-driver into sunxi-mali-utgard-driver.
Add a legacy entry.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Giulio: rebase on master. Add legacy entry instead of substituting the
blob's one]
Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This package provides Mali libraries for Sunxi Mali Utgard GPUs. The
trailing -mainline is historical and was used at a time when there was
two packages providing these libraries. The "non-upstream" package has
been removed some time ago so before adding new packages bringing
support for other ARM Mali GPU versions or implementations, rename
sunxi-mali-mainline into sunxi-mali-utgard.
Add a legacy entry.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Giulio: rebase on master. Rename SUNXI_MALI_MAINLINE_REV to
SUNXI_MALI_UTGARD_REV in sunxi-mali-mailine-driver.mk and
BR2_PACKAGE_SUNXI_MALI_MAINLINE to BR2_PACKAGE_SUNXI_UTGARD in
sunxi-mali-mainline-driver/Config.in to respect bisectability]
Tested-by: Luca Ceresoli <luca@lucaceresoli.net>
[Build tested only]
Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
[Arnout: also update existing select in Config.in.legacy]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
