Peter Seiderer [Fri, 27 Oct 2017 17:44:26 +0000 (19:44 +0200)]
gstreamer1-editing-services: new package
[Peter: select and add to dependencies good/bad plugins,
enable/disable examples if gtk2/3 with x11 backend is available] Signed-off-by: Peter Seiderer <[email protected]> Signed-off-by: Peter Korsgaard <[email protected]>
Peter Seiderer [Fri, 27 Oct 2017 17:16:22 +0000 (19:16 +0200)]
gst1-interpipe: new package
[Peter: use a normal config option instead of menuconfig, update DEVELOPERS] Signed-off-by: Peter Seiderer <[email protected]> Signed-off-by: Peter Korsgaard <[email protected]>
This allows using <PKG>_SRCDIR_OVERRIDE_RSYNC_EXCLUSIONS in local.mk to
skip copying parts of source trees unneeded for building. For example,
when developing WebKitGTK+, it's handy to skip copying all the tests and
other build directories, which are huge:
This saves a good chunk of time when rsync is used for the first time to
copy the source tree over before building.
Signed-off-by: Adrian Perez de Castro <[email protected]>
[Arnout: move documentation to the end of the section] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <[email protected]>
package/pkg-golang: use 'build' instead of 'install'
So far, we were using the 'go install' mechanism to build a package
and have its binary installed in
$$($(2)_WORKSPACE)/bin/linux_$$(GO_GOARCH). This worked fine when
building on x86-64 for ARM, but failed when building on x86-64 for
x86-64 because the binaries were installed in $$($(2)_WORKSPACE)/bin/.
Instead of doing some complicated logic to guess whether Go is going
to put our binaries in $$($(2)_WORKSPACE)/bin/ or in
$$($(2)_WORKSPACE)/bin/linux_$$(GO_GOARCH), we revert back to using
"go build", as it was done before the introduction of the golang
package infrastructure. "go build" lets us pass explicitly the
destination path of the binary to be generated.
There's just one complexity with how to decide on the name of the
binary that should be produced, and we have two cases:
- <pkg>_BUILD_TARGETS is the default, i.e ".". In this case we assume
a single binary is produced by "go build", and we name if after the
lower case package name. We allow this to be overridden thanks to
<pkg>_BIN_NAME.
- <pkg>_BUILD_TARGETS is non-default, and typically contains
something like "foo bar" or "cmd/foo cmd/bar". In this case, we
assume the binaries to be produced are "foo" and "bar", i.e we take
the non-directory part of the build target to name the binaries.
Because we're using this -o option, we no longer need to explicitly
create the binary directory, it is done by "go build".
[Peter: use $(or instead of $(if as suggested by Arnout] Signed-off-by: Thomas Petazzoni <[email protected]> Reviewed-by: "Yann E. MORIN" <[email protected]> Signed-off-by: Peter Korsgaard <[email protected]>
Thomas Petazzoni [Fri, 23 Mar 2018 21:48:14 +0000 (22:48 +0100)]
test-pkg: test a subset of toolchains by default, add -a and -n options
During the latest Buildroot Developers meeting, we discussed that
test-pkg would perhaps be more widely used if it tested a smaller
subset of toolchains. Indeed, it currently tests 47 toolchains, which
takes very long to build. Several of the toolchain configurations are
quite similar, and it is perhaps not necessary for contributors to
test them all before submitting a package.
Therefore, this commit changes the test-pkg script to only test a
subset of the toolchain configurations by default. The N first
configurations of the CSV files are tested, where N is hard-coded in
the script. The CSV file has therefore been re-organized to have the
first N toolchains be the most important ones.
A -a/--all option is added to test with all toolchains, while a
-n/--number option is added to test with the first N toolchains, N
being passed on the command line.
Note that the list of toolchains (built in the "toolchains" shell
variable) is no longer sorted. Indeed, when the first N toolchains are
tested, we want them to be tested in the same order as they are listed
in the CSV file, as we are careful to order them in an interesting
order. We only sort when all toolchains are tested.
Thomas Petazzoni [Fri, 23 Mar 2018 21:48:13 +0000 (22:48 +0100)]
toolchain-configs.csv: re-organize for test-pkg
This commit reorganizes the toolchain-configs.csv so that the first
toolchains are a subset of "useful" toolchains to be tested by
contributors to validate a package. This subset is the one that will
be used by default by test-pkg.
Gaël PORTAY [Mon, 6 Nov 2017 00:46:50 +0000 (19:46 -0500)]
support/download: keep files downloaded without hash
In the situation where the hash is missing from the hash file, the
dl-wrapper downloads the file again and again until the developer
specifies the hash to complete the download step.
To avoid this situation, the freshly-downloaded file is not removed
anymore after a successful download.
After this change, the behaviour is as follows:
- Hash file doesn't exist, or file is in BR_NO_CHECK_HASH_FOR
=> always succeeds.
- Hash file exists, but file is not present
=> file is NOT removed, build is terminated immediately (i.e.
secondary site is not tried).
- Hash file exists, file is present, but hash mismatch
=> file is removed, secondary site is tried.
=> If all primary/secondary site downloads or hash checks fail, the
build is terminated.
Jason Pruitt [Sat, 31 Mar 2018 20:57:58 +0000 (22:57 +0200)]
hackrf: new package
This patch adds hackrf/host tools for HackRF, a low cost, open source
Software Defined Radio platform.
Sources of host tools are available on GitHub here:
https://github.com/mossmann/hackrf/tree/master/host
Signed-off-by: Jason Pruitt <[email protected]> Signed-off-by: Alexey Brodkin <[email protected]>
[Arnout:
- Rename package to hackrf to match upstream name;
- Reorder dependencies and remove empty line (check-package);
- Use only sha256 hash;
- Add hash for license file;
- Bump to 2018.01.1;
- Use uploaded tarball rather than github-generated one;
- Fix dependencies of comment (|| instead of &&)
- Add UDEV_RULES_GROUP=plugdev in case the build host doesn't have
this group;
- Add patch fixing build without C++ compiler.
] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <[email protected]> Signed-off-by: Peter Korsgaard <[email protected]>
Peter Seiderer [Sat, 3 Feb 2018 22:07:33 +0000 (23:07 +0100)]
quotatool: new package
Signed-off-by: Peter Seiderer <[email protected]>
[Thomas: as suggested by Romain Naour, use
QUOTATOOL_INSTALL_TARGET_OPTS to avoid installing man pages, as it
fails due to a bug in the upstream package Makefile] Signed-off-by: Thomas Petazzoni <[email protected]>
where variable FOO_BASE_NAME is clashing between these two packages.
Specific cases where this clash is already existing are:
- alljoyn-base
- alljoyn-tcl-base
- perl-xml-sax-base
The problem is generic and can occur for a number of variables in Buildroot.
A non-exhaustive list:
<pkg>_BASE and <pkg>_BASE_NAME
<pkg>_BASE_NAME and <pkg>_RAW_BASE_NAME
<pkg>_DIR and <pkg>_DL_DIR
<pkg>_VERSION and <pkg>_DL_VERSION
<pkg>_SOURCE and <pkg>_TARGET_SOURCE
<pkg>_INSTALL_IMAGES and <pkg>_TARGET_INSTALL_IMAGES (same for _STAGING and _TARGET)
<pkg>_LICENSE_FILES and <pkg>_MANIFEST_LICENSE_FILES
<pkg>_DEPENDENCIES and <pkg>_FINAL_DEPENDENCIES
One solution is to use another separator than '_' to separate the
package name from the rest of the variable name. For example, a double
underscore:
FOO__NAME
FOO__BASE_NAME
FOO_BASE__NAME
FOO_BASE__BASE_NAME
However, making that change for only this case means that the variable
naming is no longer consistent. And making the change for all variables has
a large impact, also on certain user scripts.
For now, keep it simple, and rename FOO_BASE_NAME into FOO_BASENAME, so that
the variables become:
FOO_NAME
FOO_BASENAME
FOO_BASE_NAME
FOO_BASE_BASENAME
For consistency, also adapt FOO_RAW_BASE_NAME. Since FOO_RAW_BASENAME would
still pose a conflict with a package called 'foo-raw', take the opportunity
to rename it into FOO_BASENAME_RAW instead, which does not pose a conflict
as we have no variable called FOO_RAW.
Jan Kundrát [Mon, 4 Sep 2017 20:30:08 +0000 (22:30 +0200)]
New board: SolidRun ClearFog Base
My goal was to rely on upstreamed features as much as possible, which
means that some bits are only half-baked for now:
- Due to the DTS restructuring in upstream kernel, we require 4.11+. The
latest LTS or CIP kernels do not know about the -Base model.
- Linux has no generic support for SFP cages (yet). It seems that this
has hit the net-next tree in August 2017, but there's been no release
(it's probably targettting 4.14). Also, the merge only included the
required infrastructure; the mvneta driver conversion is not included.
Patches which finalize this exist in Russel King's tree and also in
random vendor trees.
- There's no access to the SPI flash in these versions of
uboot/linux/dts.
Signed-off-by: Jan Kundrát <[email protected]>
[Arnout:
- rename to solidrun_clearfog_defconfig;
- specify kernel headers version (default is now 4.15);
- remove ext2 fs size override, the 4 extra MB are not needed;
- U-Boot needs dtc and openssl;
- add comments to defconfig;
- update .gitlab-ci.yml;
- mention in readme.txt that SFP support is missing;
- add Jan to DEVELOPERS.
] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <[email protected]>
In both cases, upstream suggests using a different target definition
instead. E.G. from issue 685:
You may use NORTHWOOD on x86: make TARGET=NORTHWOOD that uses SSE2
instructions. It's very hard to find non-SSE2 x86 CPUs today. For x86-64
use the PRESCOTT target
So drop the SSE_GENERIC target. The only x86_64 variant we support not
covered by a more specific openblas target is the default variant, nocona
and jaguar.
Nocona was a Xeon variant of the P4 "Prescott" architecture, so use the
PRESCOTT openblas target:
Sasha Shyrokov [Tue, 6 Mar 2018 15:58:10 +0000 (10:58 -0500)]
opencv3: fix Python module build for Python 3.x
When the OpenCV3 Python support is enabled with Python 3.x, it builds
properly, and the resulting .so file is built for the target
architecture, but its name is wrong:
This solution was suggested by Arnout Vandecappelle in
https://stackoverflow.com/questions/49059035/buildroot-opencv3-python-package-builds-for-the-wrong-target.
With Python 2.x, the module is named just cv2.so so this problem isn't
visible. However, for consistency, we also pass
PKG_PYTHON_DISTUTILS_ENV when building against Python 2.x, by putting
the OPENCV3_CONF_ENV assignment inside the
BR2_PACKAGE_OPENCV3_LIB_PYTHON condition, but outside the
BR2_PACKAGE_PYTHON3/BR2_PACKAGE_PYTHON condition.
Signed-off-by: Sasha Shyrokov <[email protected]>
[Thomas: extend the commit log, apply the solution to Python 2.x.] Signed-off-by: Thomas Petazzoni <[email protected]>
.gitlab-ci.yml: extend check-package test to Config.* files
Now that all issues in Config.in files have been fixed, let's try to
make sure we don't introduce new ones by checking regularly these files
issues in Gitlab CI.
utils/checkpackagelib: exclude four files from Config.in indentation check
package/Config.in, package/Config.in.host, package/x11r7/Config.in and
package/kodi/Config.in do not comply with the normal Config.in
indentation rules. However, this violation of the rule is legitimate, so
let's skip them in check-package for this specific indentation check.
This removes the last 2197 remaining warnings on Config.in files.
Signed-off-by: Thomas Petazzoni <[email protected]>
[Ricardo: rebase patch to use relative paths passed by the main script,
fix flake8 warnings, add package/Config.* to the list] Signed-off-by: Ricardo Martincoski <[email protected]> Cc: Yann E. MORIN <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
The toolchain directory can benefit from this script to prevent common
mistakes when submitting patches.
In order to accomplish this:
Do not ignore anymore files from the toolchain/ directory.
Ignore this symbol:
- BR_LIBC: defined by the buildroot toolchain, used by gcc-final.mk.
Ignore toolchain/toolchain-external/pkg-toolchain-external.mk as it
declares a package infra and not a package itself.
Ignore toolchain/helpers.mk as it contains only helper functions.
This directory can benefit from this script to prevent common mistakes
when submitting patches.
In order to accomplish this:
Do not ignore anymore files from the linux/ directory.
Ignore missing LINUX_EXT_ prefix as the variables for linux extensions
do not use it.
Ignore this symbol:
- LINUX_EXTENSIONS: defined by each linux extension, used by
linux/linux.mk.
The filesystem types can benefit from this script to prevent common
mistakes when submitting patches.
In order to accomplish this:
Do not ignore anymore files from the fs/ directory.
Ignore fs/common.mk as it declares a package infra and not a package itself.
Register the ROOTFS_ as a valid prefix for variables.
Ignore these symbols:
- PACKAGES_PERMISSIONS_TABLE: defined either by packages through
pkg-generic or by filesystem types, used by fs/common.mk;
- SUMTOOL: defined by package mtd, used by filesystem jffs2;
- TARGETS_ROOTFS: defined by filesystem types, used in the main
Makefile.
Keep using loose checks that warn about common mistakes while keep the
code simple.
As a consequence the check functions do not differentiate between
packages and filesystems so the symbol PACKAGE_UBI would not generate a
warning for the ubi filesystem neither the symbol ROOTFS_MTD would
generate a warning for the mtd package. But those kind of mistakes are
not common and are obvious in the code review, unlike typos i.e.
ROOTFS_UBl or PACKAGE_MID that would be hard to see in the code review.
This directory can benefit from this script to prevent common mistakes
when submitting patches.
In order to accomplish this:
Do not ignore anymore files from the boot/ directory.
Ignore boot/barebox/barebox.mk as it declares a package infra and not a
package itself.
Rearrange the header of the .mk file so it becomes similar to a header
from a package. It doesn't fit in one line, so split the details to a
comment below the header.
GCONV_LIBS is only used inside this file, so rename it to start with
TOOLCHAIN_, following the namespace convention already used by packages.
Rename the hook COPY_GCONV_LIBS to TOOLCHAIN_GLIBC_COPY_GCONV_LIBS
following the convention used for hooks in packages.
toolchain-common.in is a Config.in file with an uncommon name.
It is just included by toolchain/Config.in, and toolchain/Config.in is
not that long, so instead of renaming the file, merge it to
toolchain/Config.in.
Move the raw contents from the file to the exact location it is
currently included in order to not change the order in the menu.
linux/linux.mk: use namespace for internal variables
These three symbols:
KERNEL_ARCH_PATH
KERNEL_DTBS
KERNEL_DTS_NAME
are defined and used only inside this file, so use the LINUX_ namespace
for them instead of KERNEL_.
UBINIZE_CONFIG_FILE_PATH is only used inside this file, so rename it to
start with UBI_, following the namespace convention already used by
common packages.
check-package: prepare to extend to other directories
Currently the script only checks files inside the package/ directory.
Upcoming patches will enable it for other directories.
In order to reliably test for file names, i.e. the Config.in in the base
directory, normalize the path of files to check to a relative path to
the base directory.
Rename the variable that holds the compiled regexp to better represent
its content and rearrange how it is declared to make easy to later add
new directories to check. As a consequence the files that declare
package infra types would not be ignored anymore, so create a new
variable to list the files intree to be ignored during the check. The
same variable will be used by upcoming patches to ignore other files.
Ignore pkg-*.mk and doc-asciidoc.mk since they are package infra files.
In order to not produce weird results when used for files outside the
tree (i.e. in a private br2-external) add an explicit command line
option (-b) that bypasses any checks that would make a file be ignored
by the path that contains it.
When in this out-of-tree mode, the user is responsible for providing a
list of files to check that do not contain files the script does not
understand, e.g. package infra files.
As a result of this patch, besides the known use:
$ ./utils/check-package package/new-package/*
someone with the utils/ directory in the path can now also run:
$ cd package/new-package/
$ check-package *
or
$ check-package -b /path/to/br2-ext-tree/package/staging-package/*
Peter Korsgaard [Fri, 30 Mar 2018 21:48:07 +0000 (23:48 +0200)]
utils/scanpypi: don't hardcode python2
Commit 3a0c20c5309b (scanpypi: add support for Python3) adapted the script
to work with python 3.x, but the shebang still said python2 making it
unlikely to work on systems without python 2.x.
Carlos Santos [Thu, 12 Oct 2017 15:14:18 +0000 (12:14 -0300)]
netcat: add forced dependence on BusyBox
It may be necessary if packages become built in parallel, leading to a
race condition on the creation of the "nc" link.
Of course this still leaves a race conditon if other netcat competitors
but we must assume thet the user is a grown-up person who knows what is
doing.
Signed-off-by: Carlos Santos <[email protected]>
[Arnout: Don't force-remove the existing nc, not needed according to
Romain.] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <[email protected]>
Bernd Kuhls [Sun, 4 Mar 2018 15:06:06 +0000 (16:06 +0100)]
package/kodi: remove imx support
https://git.buildroot.net/buildroot/commit/?id=266208972192f1e0869f89d7be941de6294a810a
broke imx support in Kodi because previously the G2D libraries were
part of the imx-gpu-viv package:
CMake Error at /usr/share/cmake-3.7/Modules/FindPackageHandleStandardArgs.cmake:138 (message):
Could NOT find IMX (missing: G2D_LIBRARY)
Adjusting the Kodi package to use the imx-gpu-g2d as well still does
not provide a working build:
/home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/linux/imx/IMX.cpp: In member function 'void CIMX::Deinitialize()':
/home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/linux/imx/IMX.cpp:79:21: error: 'DCIC_IOC_STOP_VSYNC' was not declared in this scope
ioctl(m_fddcic, DCIC_IOC_STOP_VSYNC, 0);
^~~~~~~~~~~~~~~~~~~
/home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/linux/imx/IMX.cpp: In member function 'bool CIMX::UpdateDCIC()':
/home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/linux/imx/IMX.cpp:109:19: error: 'DCIC_IOC_STOP_VSYNC' was not declared in this scope
ioctl(m_fddcic, DCIC_IOC_STOP_VSYNC, 0);
^~~~~~~~~~~~~~~~~~~
/home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/linux/imx/IMX.cpp:115:21: error: 'DCIC_IOC_START_VSYNC' was not declared in this scope
ioctl(m_fddcic, DCIC_IOC_START_VSYNC, 0);
^~~~~~~~~~~~~~~~~~~~
/home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/linux/imx/IMX.cpp: In member function 'virtual void CIMX::Process()':
/home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/linux/imx/IMX.cpp:125:19: error: 'DCIC_IOC_START_VSYNC' was not declared in this scope
ioctl(m_fddcic, DCIC_IOC_START_VSYNC, 0);
^~~~~~~~~~~~~~~~~~~~
/home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/linux/imx/IMX.cpp:131:19: error: 'DCIC_IOC_STOP_VSYNC' was not declared in this scope
ioctl(m_fddcic, DCIC_IOC_STOP_VSYNC, 0);
^~~~~~~~~~~~~~~~~~~
Although it might be possible to fix these bugs with something like
check-package would flag tabs before a backslash ('\t\\'),
two spaces before a backslash (' \\') but would not flag a tab before space
before backslash ('\t \\'), allowing someone to bypass the check.
package/xterm: Avoid freetype2 path poisoning using imake
When imake is installed on the host, it tries to include
freetype headers from host, so we must override ac_cv_path_IMAKE
to avoid this.
Extract from config.log:
configure:14803: checking if we should use imake to help
configure:14820: result: yes
configure:14829: checking for xmkmf
configure:14846: found /usr/bin/xmkmf
configure:14857: result: /usr/bin/xmkmf
configure:14920: testing Using /usr/bin/xmkmf ...
configure:15015: testing IMAKE_CFLAGS -I. -I/usr/include/freetype2
Signed-off-by: Valentin Korenblit <[email protected]>
[Thomas: pass ac_cv_path_IMAKE="" as suggested by Romain Naour.] Reviewed-by: Romain Naour <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
Fabrice Fontaine [Tue, 13 Mar 2018 21:18:25 +0000 (22:18 +0100)]
meson: fix error when restorecon unavailable
host-meson is used by some packages such as libmpdclient.
If selinuxenabled is installed on host but restorecon is unavailable
(for an "unknwown" reason), install will crash.
Jörg Krause [Wed, 14 Mar 2018 19:43:56 +0000 (20:43 +0100)]
package/libbsd: enable for non-glibc toolchains
libbsd builds now almost fine with a musl or uClibc toolchain, except
for one issue introduced in the latest version bump. Upstream commit 22fbd62368c39de8ac5e249d1502d5ac0ffdef30 [1] uses the glibc-only macro
`__GLIBC_PREREQ`. The issue is fixed by the attached patch from upstream,
which fixes the use of `__GLIBC_PREREQ` on non-glibc toolchains.
netcat-openbsd is the only package selecting libbsd. However, building
it still needs a glibc toolchain, as it uses `b64_ntop` which is not
available in musl or uClibc.
Build has been successfully tested with:
* armv7-eabihf--glibc--bleeding-edge-2017.11-1
* armv7-eabihf--musl--bleeding-edge-2018.02-1
* armv7-eabihf--uclibc--bleeding-edge-2018.02-1
Add a test to check Python code style in the whole buildroot tree.
Search files by type in order to help flake8 to find the Python scripts
without .py extension. But don't rely only in the output of 'file' as it
uses heuristics and sometimes it is wrong (specially identifying Python
files as C++ source for the 'file' version currently in the Docker
image).
Include in the output:
- the list of Python files processed;
- statistics for each kind of warning;
- the total number of warnings;
- the number of Python files processed.
André Hentschel [Thu, 15 Mar 2018 19:45:54 +0000 (20:45 +0100)]
wine: depend on shared libraries
Even if --enable-static --disable-shared is passed, wine tries to
build a shared library, causing a build failure in a BR2_STATIC_LIBS=y
configuration:
/home/test/buildroot/output/host/i686-buildroot-linux-uclibc/sysroot/usr/lib/libc.a(__uClibc_main.os): In function `__uClibc_fini':
__uClibc_main.c:(.text.__uClibc_fini+0x10): undefined reference to `__fini_array_start'
/home/test/buildroot/output/host/lib/gcc/i686-buildroot-linux-uclibc/6.4.0/../../../../i686-buildroot-linux-uclibc/bin/ld: /home/test/buildroot/output/host/i686-buildroot-linux-uclibc/sysroot/usr/lib/libc.a(__uClibc_main.os): relocation R_386_GOTOFF again
st undefined hidden symbol `__fini_array_start' can not be used when making a shared object
/home/test/buildroot/output/host/lib/gcc/i686-buildroot-linux-uclibc/6.4.0/../../../../i686-buildroot-linux-uclibc/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [libwine.so.1.0] Error 1
make[2]: Leaving directory `/home/test/buildroot/output/build/wine-3.0/libs/wine'
make[1]: *** [libs/wine] Error 2
Since using wine in a static linking environment is fairly unlikely,
we simply mark the wine package unavailable on static-only
configurations.
Since we need to add a Config.in comment, we also introduced a
BR2_PACKAGE_WINE_ARCH_SUPPORTS hidden boolean, to share the
architecture dependencies definition between the wine config option
and the comment.
Signed-off-by: André Hentschel <[email protected]>
[Thomas:
- add a comment in the Config.in file about the dependency
- add BR2_PACKAGE_WINE_ARCH_SUPPORTS
- extend the commit log] Signed-off-by: Thomas Petazzoni <[email protected]>
Yann E. MORIN [Fri, 1 Dec 2017 15:09:46 +0000 (16:09 +0100)]
infra/pkg-kconfig: do not update-(def)config to a directory
Currently, if the user specifies the path to an existing directory as
the path to the custom (def)config file (FOO_KCONFIG_FILE), then we
happily create a file in there, either 'defconfig' or '.config' (or
whatever the .config is named for that package), depending on whether
we're saving a defconfig or a full config.
So, we could save the file, but then the Buildroot defconfig file that
contains that path would no longer be reusable as-is, because we
interpret that path as a path to a file.
Furthermore, if the directory-portion of FOO_KCONFIG_FILE does not
exist yet, the update would fail, because cp does not create missing
directory components.
So we fix that by adding an explicit test for the directory-ness of the
target file, and then an explicit mkdir to create missing directory
components.
Yann E. MORIN [Fri, 1 Dec 2017 15:09:45 +0000 (16:09 +0100)]
infra/pkg-config: hide away non-critical commands
When updating back the (def)config file, the touch command is not very
useful by default, so hide it away.
We do not hide away the cp command, as that could confuse the user under
some circunmstances. For example, when the toolchain does not yet exist,
the uClibc buildsystem will complain multiple times about gcc not being
found, like so:
make[2]: /home/ymorin/dev/buildroot/O/host/bin/i686-buildroot-linux-uclibc-gcc: Command not found
(Note that we can not suppress those warnings, as they are on stderr,
and we still want to see stderr in case of real errors).
So, if we were to hide the cp command, the user could be left confused,
even though we were sucessful in updating back the (def)config file.
Except for the nice human-friendly reminder of the command that the user
was just running, and the name of the file to copy from, those two rules
are exactly the same.
Make that a common macro that is shared, so that it's easier to add more
checks, and to simplify maintenance.
Peter Korsgaard [Sat, 31 Mar 2018 19:03:57 +0000 (21:03 +0200)]
Makefile: Ensure BASE_TARGET_DIR exists, not TARGET_DIR
This was present in Yann's original patch, but got dropped when I rebased
commit 7e9870ce32 (core: introduce intermediate BASE_TARGET_DIR variable) to
fix the Makefile conflicts.
Peter Korsgaard [Sat, 21 Oct 2017 20:54:57 +0000 (22:54 +0200)]
lua: always use host-lua for host-luainterpreter
Similar to how we do for openssl.
host-luainterpreter is only used by the luarocks infrastructure, and there
is afaik no specific reason why the host lua variant must match the target one.
Luajit only supports a limited number of architectures, so building it for
the host limits the architectures Buildroot can be used on (E.G. powerpc64
autobuilders).
To fix this, always use host-lua. Slightly rework lua.mk to ensure
host-lua-5.1 is used when luajit is selected, and drop the logic for using
host-luajit.
Peter Korsgaard [Sat, 31 Mar 2018 10:27:11 +0000 (12:27 +0200)]
ktap: bump version for linux-4.8 support
Fixes #10776
The upstream git repo contains a number of fixes for building against newer
kernel versions, so bump the version.
git shortlog eb66d40310c93dc82bc8eac889744c1ed1f01f7b..
Alain Kalker (2):
uprobe: Print the symbol, not the matching pattern
uprobe: Blacklist uretprobes on _start
Aleksa Sarai (2):
runtime: update GFP_WAIT to GFP_RECLAIM
userspace: fix up argument parsing NULL dereference
Alexey Makhalov (1):
Fix building for v4.8 kernel
Azat Khuzhin (12):
Use get_unused_fd_flags(0) instead of get_unused_fd()
Support trace_seq::seq
Ignore separate debug files (*.dwo)
Use trace_seq_has_overflowed()
makefile: split vim plugins installing into separate target
makefile: use DESTDIR for install (allow to change install dir)
makefile: install: create dirs
makefile: use ldflags for linking ktap
makefile: add CPPFLAGS to KTAPC_CFLAGS, to allow change default flags
ignore: exclude /debian
Support compilation for 4.2 (ftrace_events cleanup)
runtime: fix building on 4.3
Jovi Zhangwei (11):
Merge pull request #84 from azat/linux-3.19-fixes-v3
Merge pull request #85 from azat/debian-preparations-v2
Merge pull request #88 from NanXiao/master
Merge pull request #89 from NanXiao/patch-1
Merge pull request #91 from NanXiao/patch-1
Merge pull request #90 from azat/linux-4.2-compilation-fixes
Merge pull request #99 from cyphar/fix-null-deref
Merge pull request #98 from cyphar/fix-gfp-reclaim
Merge pull request #97 from azat/fix-building-4.3-__GFP_RECLAIM
Merge pull request #103 from ackalker/blacklist
Merge pull request #104 from YustasSwamp/master
Nan Xiao (3):
Update tutorial.md
Update Makefile
Fix memory leak issue in main function.
WEI ZHANG (1):
ktap: Change the copyright to Huawei Technologies
While we are at it, also add a hash for the license file.
Yann E. MORIN [Sat, 31 Mar 2018 09:06:01 +0000 (11:06 +0200)]
fs: remove intermediate artefacts
Each of the intermediate, per-rootfs target directories, as well as the
intermediate tarball, can take quite some place, and is mostly a
duplication of what's already in target/. The only delta, if any, would
be the tweaks made by the filesystem image generations, but those tweaks
are most probably only meaningful when seen as root.
We normally do not remove intermediate files, but those can be quite
large, and are not directly usable by, nor accessible to the user.
So, get rid of them once the filesystem has been generated.
Yann E. MORIN [Sat, 31 Mar 2018 09:06:00 +0000 (11:06 +0200)]
fs: get rid of package-provided post-fs hooks
Now that the pre-fs ones are run on a transient copy of target/, the
post-fs hooks are no longer needed because we no longer need to restore
the target/ directory as it is only a internal copy.
Remove support for the post-fs hooks, and update the sole package using
them.
We do not add a legacy check because this was mostly a purely-internal
detail that was never really exposed nor documented.
Yann E. MORIN [Sat, 31 Mar 2018 09:05:59 +0000 (11:05 +0200)]
fs: run packages' filesystem hooks in a copy of target/
Currently, some packages may register hooks to be run just before and
just after the generic tarball image is generated, because they need to
prepare the filesystem for read-only or read-write operation.
However, this means that, if any of the hooks or the image generation
fails, the target directory is left in a dangling, inconsistent state.
We fix that by doing a copy of target/, run the hooks on that copy,
generate the generic tarball image out of that, and get rid of the copy.
This way, we can guarantee consistency of the target directory, and we
can even ditch support for post-fs hooks (those that restore target/).
Yann E. MORIN [Sat, 31 Mar 2018 09:05:58 +0000 (11:05 +0200)]
fs: use a common tarball as base for the other filesystems
Currently, some filesystems may want to tweak the content of the target
directory, create special device nodes etc... This all means that:
- the content of the target directory for a specific filesystems may
depend on whether another filesystem is enabled or not; for example,
cpio will create a /init script or symlink and a /dev/console node;
- the filesystems can not be built in parallel, because they may change
the content of the target directory while another is being assembled.
Furthermore, the same fakeroot script is executed over-and-over-again
for each filesystem, to create the device nodes, the users and their
homes and files, and setting permissions...
We introduce an intermediate tarball, for which we do the full fakeroot
shebang.
That tarball then serves as the base for the other filesystems, with a
very simple fakeroot script that untars the common tarball, and calls
the actual filesystem image generator on that.
Note that we use a very simple tar command to generate the intermediate
tarball, because we are not concerned with reproducibility of the
archive itself (only of the archived files).
Yann E. MORIN [Sat, 31 Mar 2018 09:05:56 +0000 (11:05 +0200)]
fs: new intermediate rootfs-common to gather common dependencies
Before we can create an intermediate tarball for all filesystems, we
nedd to move the common dependencies needed to generate that
intermediate tarball, rather than leave those dependencies to each
filesystem.
So, we introduce rootfs-common, which gathers all those common
dependencies.
Yann E. MORIN [Sat, 31 Mar 2018 09:05:53 +0000 (11:05 +0200)]
fs: use a per-rootfs fakeroot script
... and locate that script in a per-rootfs directory.
Just like for ROOTFS, this variable will leak down the dependency tree to
target-finalize and packages - But it doesn't matter as it isn't used
outside fs/.
Yann E. MORIN [Sat, 31 Mar 2018 09:05:51 +0000 (11:05 +0200)]
fs: set per-rootfs variable name
Like we do for packages with the PKG variable, set ROOTFS to contain the
upper-case name of the rootfs currently being generated.
This will be useful in later patches, when we need more per-rootfs
variables, like a per-rootfs TARGET_DIR for example.
In Makefiles, per-rule variables trickle down the dependency chain, to
all dependencies of that rule, so we have to stop ROOTFS as soon as
we're not in a rootfs. This means we have to stop it at target-finalize
(which is a dependency of all filesystems), and for each package
individually, since some packages (host or target) can be direct
dependencies of filesystems as well.
This new BASE_TARGET_DIR variable is set in stone to point to the real
location where packages will be installed. Its name is modelled after
its definition: it is located in $(BASE_DIR), and it is named 'target/',
hence BASE_TARGET_DIR.
The already-existing TARGET_DIR variable now simply points to the same
location, except that it is recursively expanded, so that we can later
change it depending on the context.
All locations that really need to reference the existing target/
directory, are changed to use BASE_TARGET_DIR; surprinsigly enough, they
all seem to be located in the main Makefile. :-) The rest is left with
using good-old TARGET_DIR.
Yann E. MORIN [Sat, 31 Mar 2018 09:05:48 +0000 (11:05 +0200)]
fs/cpio: don't extend packages' permissions table
Currently, when we build a cpio filesystem without static devices, we
shoehorn the /dev/console node as if it were specified by a package.
This means that this device is added for all filesystems as well, not
just the cpio. But if we disable cpio, that device is not created for
other filesystems.
This is not very clean, and may break expectations.
Instead, use an explicit mknod as part of the _CMD, as we know it's
going to run under fakeroot.
This is still visible to all filesystems built after cpio, and not to
those built before it, though.
projects / buildroot-mgba.git / log