Instead of manually testing MAKECMDGOALS, use the newly introduced
BR_BUILDING variable to know if we're building or not.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
This commit removes BR2_LINUX_KERNEL_EXT_RTAI_PATCH because this
option never worked. It was added in commit
8797a9cd1f, which added package/rtai/
and RTAI as a Linux extension.
The option prompt says "Path for RTAI patch file", so let's say you
specify /home/foo/bar/myrtai.patch as the value for
BR2_LINUX_KERNEL_EXT_RTAI_PATCH.
Then the code does:
RTAI_PATCH = $(call qstrip,$(BR2_LINUX_KERNEL_EXT_RTAI_PATCH))
and we have a package called 'rtai', so the normal logic of
<pkg>_PATCH applies. Since the <pkg>_PATCH value does not contain
ftp://, http:// or https://, the package infrastructure will try to
download $(RTAI_SITE)/$(RTAI_PATCH), i.e:
https://www.rtai.org/userfiles/downloads/RTAI/home/foo/bar/myrtai.patch
Pretty clear that it has no chance of working.
Now, let's assume an URL is used as the value of
BR2_LINUX_KERNEL_EXT_RTAI_PATCH, such as
http://foo.com/bar/myrtai.patch. In this case, it will be properly
downloaded by the package infrastructure. But then, the following code
kicks in:
define RTAI_PREPARE_KERNEL
$(APPLY_PATCHES) \
$(LINUX_DIR) \
$(dir $(RTAI_PATCH)) \
$(notdir $(RTAI_PATCH))
endef
The value of $(dir $(RTAI_PATCH)) will be http://foo.com/bar/. How
can $(APPLY_PATCHES) make use of such a stupid patch location?
[Thomas: add Config.in.legacy handling, as suggested by Arnout, even
if we believe that no-one could have ever used this option.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
linux has uImage generation support for powerpc64 as well as powerpc,
since 2.6.15.
Signed-off-by: Erico Nunes <erico.nunes@datacom.ind.br>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes fbtft kernel extension bug reported by Richard Fergusson ([1]):
drivers/video/Kconfig:2525: can't open file
"drivers/video/fbdev/fbtft/Kconfig"
Fix: write the right fbtft/KConfig path to video/Kconfig or
video/fbdev/Kconfig (instead of hard coded one)
[1] http://lists.busybox.net/pipermail/buildroot/2015-January/117057.html
Reported-by: Richard Fergusson <fergie4000@gmail.com>
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Curently, all three linux extensions follow the same layout:
- test if the extension is enabled
- add itself to linux' patch-dependencies
- declare a macro, added as the pre-patch hook
Except for the macro, all can be commonalised.
Add a simple infrastructure for that:
- extensions declare themselves in the list of extensions
- extensions define their macro
- the infra adds them to the patch-dependencies and pre-patch
hooks as appropriate
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since the move to the kconfig-package infra, linux extensions are
broken.
In our linux package, extensions are applied as pre-patch hooks.
Before the kconfig-package infra, we had custom rules for the
linux-*config targets, which were of the form:
linux-menuconfig: linux-configure
$(MAKE) -C $(LINUX_DIR) menuconfig
This caused the linux tree to be fully configured before running the
configurators, and thus linux dependencies were entirely fullfilled, and
extensions were properly applied.
Since we migrated (in dff25ea), the kconfig-package infra introduces a
(hidden, internal) intermediate step 'kconfig-fixup' and decorelates the
kconfig-part of the configuration from the actual package-part of the
configuration:
linux-configure -------> kconfig-fixup --> .config --> $(LINUX_CONFIG_FILE)
/
linux-menuconfig --'
As thus, this (very useful!) use-case breaks (starting from a clean
Buildroot tree):
make menuconfig
-> enable a kernel and at least one extension
-> save and exit
make linux-menuconfig
-> extensions are not available
Fix that by using the newly-introduced patch-dependencies, so that
extensions are available before we try to patch the linux kernel.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: fix issues noticed by Arnout:
- Rewrap the linux/Config.in paragraph
- Revert the "is a toolchain dependency" -> "has a toolchain
dependency" change from pkg-generic.mk, as the original was
correct.]
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Several packages have some logic to apply custom patches that existed
before the BR2_GLOBAL_PATCH_DIR mechanism: at91bootstrap,
at91bootstrap3, barebox, uboot and linux. Currently, the logic of
those packages to apply custom patches is to match
<package-name>-*.patch, which is not consistent with what we've done
for patches stored in the package directory, and for patches stored in
BR2_GLOBAL_PATCH_DIR: in such cases, we simply apply *.patch.
Therefore, for consistency reasons, this commit changes these packages
to also apply *.patch.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
This commit doesn't touch infra packages.
Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The linux package has a special handling of patches, with quite a bit
of legacy in it. A problem caused by this special handling is that the
linux package calls directly the DOWNLOAD_WGET macro, which means that
the package infrastructure isn't aware of which patches get
downloaded, and it prevents doing changes inside the package download
infrastructure.
This commit changes the handling of patches in the linux package in
the following way:
* The LINUX_PATCHES variable is kept as is: it lists all the patches
mentioned in the Config.in option BR2_LINUX_KERNEL_PATCH. This
option can contain http://, ftp://, https:// URLs, path to local
files or local directories.
This variable is *not* used by the generic package infrastructure,
so it is purely internal to the Linux package.
* The LINUX_PATCH variable is now filled in with the list of patches
that should be downloaded. It is derived from LINUX_PATCHES by
filtering the patches that have http://, ftp:// or https:// in
their path. Since <pkg>_PATCH is handled by the package
infrastructure, it means that those patches are now automatically
downloaded and applied by the package infrastructure.
* The LINUX_APPLY_PATCHES hook is renamed to
LINUX_APPLY_LOCAL_PATCHES, because it is now only responsible of
applying local patches: remote patches are handled by
LINUX_PATCH. The implementation of the hook is changed to filter
out the patches that have already taken care of by LINUX_PATCH, so
that we only iterate through the list of local patches or local
patch directories.
[Thomas: adjust comment in the code according to Yann comments.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Romain Naour <romain.naour@openwide.fr>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reword the help text and get ride of the supported kernel
version list which is outdated since Xenomai version bump.
[Thomas: rewrap text to the appropriate length, fix some typos.]
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
If you have several linux patches directories, Buildroot does not stop
if one patches of the first directories don't apply. This patch fixes
this.
Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The recommended form is without the trailing slash. Buildroot will add a slash
between FOO_SITE and FOO_SOURCE as appropriate.
Reported-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE can either be a complete
.config file or a defconfig file, it can be confusing to the user
whether to choose BR2_LINUX_KERNEL_USE_DEFCONFIG or
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG.
To avoid that confusion, clarify Kconfig entry messages for in-tree
defconfig and custom (def)config files.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When building device tree blobs from custom *.dts files, buildroot
initializes KERNEL_DTS_NAME variable from all given file names.
This causes that user can't provide one *.dts file and some other
*.dtsi files as dependencies.
Problem is fixed by adding filter for initializing KERNEL_DTS_NAME
variable with *.dts files only. All user provided files are copied
into kernel source tree, but only file names suffixed with *.dts
are used for building appropriate *.dtb files.
[Thomas: add comment into the code to explain why we are filtering
.dts files only.]
Signed-off-by: Ivo Slanina <ivo.slanina@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When Buildroot is configured to append the root filesystem to the Linux
kernel as initramfs, Buildroot sets the path to the initramfs source
dynamically in the Linux configuration file.
As this path is specified as an absolute path, typically being different
for different users of the same project (e.g. containing a username),
saving the configuration to a version control system (for example using
'make linux-update-defconfig') would result in a difference for this
path at every invocation by a different user.
Although this is technically not an issue, it is confusing that this
generates a difference.
Address this issue by using a not-yet-expanded make variable to specify
the path to the initramfs source. That variable will be expanded by the
Linux build system, which uses it both as a Makefile variable and a
shell variable; thus, it needs to be specified in LINUX_MAKE_ENV (so
it is exported and available in sub-processes of make). Any saved
configuration file would simply contain the reference to the
not-yet-expanded variable.
As in the Linux build system, the config variables are both read from
make as from a shell script, we cannot use $() syntax as this would be
interpreted as a command invocation by the shell. Instead, use ${}
syntax which is interpreted as variable reference both by the shell as
by make.
[Thomas:
- Really make the patch work by using $(LINUX_MAKE_ENV) instead of
$(TARGET_MAKE_ENV). Otherwise, the new BR2_BINARIES_DIR variable is
not passed at all stages of the build process, which makes the
build fail when an initramfs is used.]
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: "Yann E. Morin" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Migrate the linux package to the kconfig infrastructure.
A notable change compared to the original behavior:
- the targets linux-update-(def)config are now always saving the config
file, even for a defconfig bundled in the linux sources. This is done
to keep the kconfig infrastructure simple.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: "Yann E. Morin" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Even though this is not strictly necessary with the current version of
linux.mk, it becomes necessary when migrating linux.mk to the kconfig
infrastructure.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: "Yann E. Morin" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The help text for Linux option 'Custom tarball' only refers to ftp or
http tarballs, while in reality file or scp protocols are also
supported.
Triggered by a recent support question, update the help text to clarify
this.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Patches located at ftp or http(s) URLs were downloaded using DOWNLOAD
macro. For example, if linux source was located at external git
repository, DOWNLOAD macro uses git scheme as well and buildroot
tried to downlod a path using DOWNLOAD_GIT macro. As a result, nothing
was downloaded and build siletly passes.
Patches located at mentioned URLs is now downloaded directly with
DOWNLOAD_WGET macro.
Signed-off-by: Ivo Slanina <ivo.slanina@gmail.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Patches located at https:// scheme URL were threated as directories,
causing build failures.
Fixed by adding https:// pattern.
Signed-off-by: Ivo Slanina <ivo.slanina@gmail.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Enable the required conntrack/netfilter options, otherwise
xtables-addons will fail to build.
The basic iptables options are already covered by the iptables package
which is a required dependency anyway.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Enable the basic kernel options for iptables to be useful at least to
filter incoming connections.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested with RaspberryPi B+ and PiTFT Mini Kit - 320x240 2.8" TFT
(see [1] and [2]) and the following target configuration changes:
- cmdline.txt: add 'fbcon=map:10 fbcon=font:VGA8x8'
- add /etc/modules-load.d/fbtft.conf with 'fbtft_device'
- add /etc/modprobe.d/00-fbtft.conf with 'options fbtft_device name=adafruit28 rotate=90 gpios=dc:25'
[1] http://h65951.serverkompetenz.net/PeterSeiderer/upload/PiTFT_2_8_ct/Image9893.jpg
[2] http://h65951.serverkompetenz.net/PeterSeiderer/upload/PiTFT_2_8_ct/Image9897.jpg
[Thomas:
- Rename prompt of the Linux extension to "FB TFT drivers"
- Remove the full name of the kernel config options in the help
text. Giving their CONFIG_<foo> name is enough.
- Remove the mention of CONFIG_SPI_BCM2708, since this makes the
description RaspberryPi specific, while these drivers can work
with any SPI controller.
- Refactor the code in linux-ext-fbtft.mk to avoid duplication
between the < 3.15 and >= 3.15 cases.
- Make the fbtft package a promptless package, since there is no
point in selecting only this package, without the kernel
extension.
- Change the license to GPLv2, since it's kernel code.]
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When using a custom local tree, we're using the OVERRIDE_SRCDIR
internally, which means we do not apply patches. Since this is the
expected behavior, make BR2_LINUX_KERNEL_PATCH and
BR2_LINUX_KERNEL_CUSTOM_LOCAL options exclusive.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The current prompt seems to imply that we want to add Device Tree
support to the Linux kernel:
[*] Device tree support
But what it really means is that Buildroot will build a DTB.
Change the prompt so that it is obvious that this is the intended
behaviour, and users do not get mislead as to why Device Tree support is
not automatically added to their Linux kernel.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Unbreak qemu_xtensa_lx60_defconfig where LINUX_IMAGE_NAME !=
LINUX_TARGET_NAME.
It incorrectly overwrites LINUX_IMAGE_NAME even if it was set before,
defeating the purpose of IMAGE being different than TARGET.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When running 'make printvars', the output stops at the time we dump the
Linux related variables, with:
linux/linux.mk:109: *** Recursive variable `LINUX_TARGET_NAME'
references itself (eventually). Stop.
And that's expected, since we have:
109 LINUX_TARGET_NAME = $(LINUX_IMAGE_NAME)
[...]
112 ifeq ($(LINUX_IMAGE_NAME),)
113 LINUX_IMAGE_NAME = $(LINUX_TARGET_NAME)
114 endif
Even though they are defined in a way that ensures they are in fact not
recursively defined (the if-block ensures that), 'printvars' does dump
all our variables by evaluating all of them, which in that specific case
implies they are recursively defined.
Fix that by explicitly setting LINUX_IMAGE_NAME in each if-block.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
To easy up adding optional parameters when calling the
"apply-patches.sh" add and use the "APPLY_PATCHES" variable to execute
the script.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The Buildroot coding style defines one space around make assignments and
does not align the assignment symbols.
This patch does a bulk fix of offending packages. The package
infrastructures (or more in general assignments to calculated variable
names, like $(2)_FOO) are not touched.
Alignment of line continuation characters (\) is kept as-is.
The sed command used to do this replacement is:
find * -name "*.mk" | xargs sed -i \
-e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*$#\1 \2#'
-e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*\([^\\]\+\)$#\1 \2 \3#'
-e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*\([^\\ \t]\+\s*\\\)\s*$#\1 \2 \3#'
-e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\(\s*\\\)#\1 \2\3#'
Brief explanation of this command:
^\([A-Z0-9a-z_]\+\) a regular variable at the beginning of the line
\([?:+]\?=\) any assignment character =, :=, ?=, +=
\([^\\]\+\) any string not containing a line continuation
\([^\\ \t]\+\s*\\\) string, optional whitespace, followed by a
line continuation character
\(\s*\\\) optional whitespace, followed by a line
continuation character
Hence, the first subexpression handles empty assignments, the second
handles regular assignments, the third handles regular assignments with
line continuation, and the fourth empty assignments with line
continuation.
This expression was tested on following test text: (initial tab not
included)
FOO = spaces before
FOO = spaces before and after
FOO = tab before
FOO = tab and spaces before
FOO = tab after
FOO = tab and spaces after
FOO = spaces and tab after
FOO = \
FOO = bar \
FOO = bar space \
FOO = \
GENIMAGE_DEPENDENCIES = host-pkgconf libconfuse
FOO += spaces before
FOO ?= spaces before and after
FOO :=
FOO =
FOO =
FOO =
FOO =
$(MAKE1) CROSS_COMPILE=$(TARGET_CROSS) -C
AT91BOOTSTRAP3_DEFCONFIG = \
AXEL_DISABLE_I18N=--i18n=0
After this bulk change, following manual fixups were done:
- fix line continuation alignment in cegui06 and spice (the sed
expression leaves the number of whitespace between the value and line
continuation character intact, but the whitespace before that could have
changed, causing misalignment.
- qt5base was reverted, as this package uses extensive alignment which
actually makes the code more readable.
Finally, the end result was manually reviewed.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Cc: Yann E. Morin <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
To be consistent with the recent change of FOO_MAKE_OPT into FOO_MAKE_OPTS,
change remaining occurrences of _OPT into _OPTS.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since the trailing slash is stripped from $($(PKG)_SITE) by pkg-generic.mk:
$(call DOWNLOAD,$($(PKG)_SITE:/=)/$($(PKG)_SOURCE))
so it is redundant.
This patch removes it from $(PKG)_SITE variable for BR consistency.
Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The linux-* mirror targets of linux26-* have been added a very long time ago
(2010) and linux 2.6 is now considered 'old' anyway. It no longer makes
sense to support these linux26-* targets, so this patch removes them.
This is a simplification introduced in preparation of the kconfig-package
infrastructure.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: fix minor typo in help text.]
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The new variable LINUX_TARGET_NAME is unconditionally used but it may be
unset leading to a default kernel build (which might not be uImage or
other requested format).
See http://lists.busybox.net/pipermail/buildroot/2014-July/102069.html
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
For example the upcoming qemu-xtensa patch is using this feature,
where the target is called "zImage", but the resulting kernel name
is "Image.elf".
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The echo statements in the kconfig helpers are currently using double
quotes. For KCONFIG_SET_OPT this is problematic when the value argument
itself contains a double quote (a string value). In this case, the statement
echo "$(1)=$(2)" >> $(3)
would become:
echo "FOO="string value"" >> /some/path/.config
resulting in the string
FOO=string value
in the config file, rather than the properly quoted
FOO="string value"
The linux package worked around this by escaping the quote characters, but
a prettier solution is to use single quoting in the helpers (or
alternatively use no quoting at all).
A side effect of this change is that a $variable in the key or value would
no longer be interpreted by the shell, removing any unexpected behavior.
This change is only really necessary for KCONFIG_SET_OPT, but for symmetry
reasons the other helpers are updated too.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This enables powerpc64 and powerpc64le. Currently, le needs at least
glibc 2.19 and gcc 4.9.0. For gdb, 7.7.1 works (added in an earlier
patch).
[Peter: also disallow gcc 4.8 for ppc64le]
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Starting from U-Boot v2014.04 ARC architecture is supported,
so now it's possible to create uImage for ARC as well.
Signed-off-by: Mischa Jonker <mjonker@synopsys.com>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- fix networking in Qemu using a small patch
- disable DTS, because linux.bin does not include any DTB the
default Qemu included DTB is used and this is okay and works fine
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Tested-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
SMACK stands for Simplified Mandatory Access Control Kernel. It is a Linux
Security Module which provides a Mandatory Access Control mechanism,
like SELinux, but aiming towards simplicity.
This package provides the tools to load/unload the policy from the
kernel as well as a library allowing applications to interact with
SMACK. The proper kernel options are also set.
[Thomas:
- fixed license to be LGPLv2.1 instead of LGPLv2.1+. Even though the
debian/copyright file has the "or later" indication, none of the .c
source files carry it, so I suppose LGPLv2.1 is more correct.
- added !BR2_PREFER_STATIC_LIB dependency.
- added dependency on host-pkgconf, since Smack configure.ac uses
PKG_CHECK_MODULES.]
Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The "dirs" dependency is redundant because now the "generic-package"
infrastructure add automatically the "dirs" dependency so just remove
the redundant references.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As stated in the Buildroot user manual add one space before and after
a = sign.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This reverts commit ca80782f45. The
whole host-lzop optional dependency logic cannot work, since the
configuration file will only be known after the kernel sources are
extracted, if an internal kernel defconfig is used, which is quite
common.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This reverts commit b4cacbf5b1. The
whole host-lzop optional dependency logic cannot work, since the
configuration file will only be known after the kernel sources are
extracted, if an internal kernel defconfig is used, which is quite
common.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This reverts commit 477c28cf1d. The
whole host-lzop optional dependency logic cannot work, since the
configuration file will only be known after the kernel sources are
extracted, if an internal kernel defconfig is used, which is quite
common.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This reverts commit 4ad1ea59a5. The
whole host-lzop optional dependency logic cannot work, since the
configuration file will only be known after the kernel sources are
extracted, if an internal kernel defconfig is used, which is quite
common.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The KCONFIG_GET_OPT calls added by
ca80782f45 ('linux: only depend on
host-lzop if needed') are made even if the kernel package is not
selected. This hangs the linux.mk parsing as they try to read from a
file that doesn't exist.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
... and abort early, before we even use it.
Reported-by: Peter Korsgaard <jacmet@uclibc.org>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>