Some software decides based on uid/gid whether a user is a system or
normal (human) user, with different behaviour for those flavors (example
journald [2]).
So adding logic to create system-users is necessary, we take the now
common ranges from [1].
This extends the mkusers script to allow -2 for uid/gid, this argument
will take an identifier from the user range. All identifiers used up to
now should have been from the system range, so -1 is now interpreted as
a system user/group.
Note that after this commit, all the UIDs and GIDs that are created
automatically (with -1) will change. That means if there is peristent
data on an existing system that was created by such an automatic user,
it will suddenly belong to a different user. However, this could already
happen before: if a USERS line is added to a package, then other UIDs
may change as well.
Add system/user ranges as variables, and the argument for user/system
uid variable as well. Thus some magic constants could be removed, some
further occurences of -1 were replaced with equivalent logic. For
consistency, the existing MIN/MAX_UID/GID variables are renamed to
FIRST/LAST_USER_UID/GID.
Update the documentation with the new automatic ranges.
[1] - https://systemd.io/UIDS-GIDS/
[2] - https://www.freedesktop.org/software/systemd/man/journald.conf.html
Signed-off-by: Norbert Lange <nolange79@gmail.com>
[Arnout: use -1 for system users; refactor the changes a bit]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
From [1]:
"Even though the ordering has absolutely no consequences in Kconfig, it
is not logical (when reading). It is more logical and far easier to
understand when depends come first, followed by the selects."
Also, the Config.in example in the manual suggests to use this coding
style [2]."
Use the correct coding style in the chapter "Choosing depends on or select"
in the manual.
[1] http://lists.busybox.net/pipermail/buildroot/2015-October/142955.html
[2] https://nightly.buildroot.org/manual.html#_coding_style
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit 1ba85b7f87 (support/download: add explicit no-hash support)
introduced the 'none' hash type, in an attempt to make hash files
mandatory, but not failing on archives localy generated, like those
for git or svn repositories, especially for those packages where a
version choice was present, which would allow for either remote
archives for which we'd have a hash or VCS trees for which we could
not have a hash for the localy generated archive.
Indeed, back in the time, we did not have a mean to generate
reproducible archives, so having a hash file without a hash for
thosel ocally generated archives would trigger an error in the
hash-checking machinery.
But now, low-and-behold, we do know how to generate those archives,
and we have a mechanism to explicitly exclude some archives from being
hash-checked (e.g. when the version string itself can be user-provided).
As such, the 'none' hash type no longer has any raison d'être, we do not
use it in-tree, and its use in a br2-external tree is most probably
inexistent (as is the use of hash files alotgether most probably).
So we simply drop the support for that.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
[Thomas: drop support in checkpackagelib, as reported by Ricardo.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The Buildroot manual was already providing some details on how to
integrate Cargo packages, and those details now need to be updated
with a proper documentation for the cargo-package infrastructure, as
well as updates related to vendoring support, which affects how
dependencies are handled.
In addition, now that we have vendoring support for Cargo packages,
let's rewrite the dependency management section in a more accurate
way.
We drop the part about the local cache of the registry, because
+CARGO_HOME+ in Buildroot points to $(HOST_DIR)/share/cargo, which is
not shared between builds nor preserved accross builds, so its effect
as a cache is limited.
Signed-off-by: Patrick Havelange <patrick.havelange@essensium.com>
[Thomas: numerous updates and extensions.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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>
Git Large File Storage replaces large files with text pointers in the
Git repository while storing the contents on a remote server. If a
repository is using this extension, then git-lfs must be used to
checkout the large files before the source archive is generated.
Signed-off-by: John Keeping <john@metanate.com>
[vfazio:
- add git-lfs to DL_TOOLS_DEPENDENCIES
- fixup for 5a0d681394
("infra/pkg-download: make the DOWNLOAD macro fully parameterised")
]
Signed-off-by: Vincent Fazio <vfazio@xes-inc.com>
[Arnout:
- don't "git lfs install";
- recurse into submodules.
]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Add Secure File Transfer Program (SFTP) support using a simple wrapper.
SFTP is a common protocol used to transfer files securely between
enterprises, but it is not currently supported in Buildroot because all
of the packages are usually available via HTTP, git or some other
download method.
SFTP is similar to FTP but it preforms all operations over an encrypted
SSH transport using a specific protocol. This is unlike ftps, which is
traditional FTP over an SSL/TLS connection.
Signed-off-by: Thomas Preston <thomas.preston@codethink.co.uk>
Signed-off-by: Michael Drake <michael.drake@codethink.co.uk>
[Arnout:
- update documentation with sftp everywhere scp is mentioned;
- rename "verbose" variable to "quiet";
- print the sftp command, similar to wget and scp helpers.
]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Use single space in LIBFOO_{DEVICES,PERMISSIONS} to be consistent with
LIBFOO_USERS, package/makedevs/README and most examples/packages
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add allowed notations section for genimage.cfg files by specifying the
accepted suffix or prefix. Note that "K" has been decided to specify
KiloBytes as 1024 bytes. This has been done because in Buildroot the 90%
of the cases were using "K" and not "k".
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
libffi supports ARC since commit 34c2afeb75 ("libffi: back-port support
for ARC") in 2014.
Add nds32 and ARMv7-M to the list.
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This patch adds the explanation for the genimage.cfg files coding standard.
A real standard is not defined upstream by the genimage utility
developers[1], but I try to give one here in Buildroot for consistency.
[1]: https://github.com/pengutronix/genimage
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
The current documentation was poorly organized, with for example the
"Here is an example walk through of running a test case" sentence
followed by the explanation of how to list available test cases, but
not how to run one.
Many other aspects of the wording were confusing, or not really
accurate.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
The directory that containts tests is "support/testing/tests/", not
"supporting/testing/test".
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
The current Gitlab CI mechanism allows to trigger all tests in a CI
pipeline by pushing a branch named <something>-runtime-tests, or to
trigger a single test in a CI pipeline by pushing a branch name
<something>-tests.<name of test>.
However, there are cases where it is useful to run a suite of tests,
for example to run all tests in tests.init.test_busybox.
This commit makes that possible by extending the current semantic of
<something>-tests.<name of test> to not expect a complete test name,
but instead to accept all tests that starts with the given pattern.
This allows to do:
git push gitlab HEAD:foobar-tests.init.test_busybox.TestInitSystemBusyboxRo
like it was the case before. But it now also allows to do:
git push gitlab HEAD:foobar-tests.init.test_busybox
to run all Busybox tests.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
A gdbinit file passed via '-x' will be read _after_ parsing any
object/core file passed on the command-line. In cross-compilation context,
this is particularly a problem when loading a core file, because without the
'sysroot' specified in the gdbinit file, it will give a lot of warnings,
like:
warning: .dynamic section for "/lib/libstdc++.so.6" is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for "/lib/librt.so.1" is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for "/lib/libm.so.6" is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for "/lib/libgcc_s.so.1" is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for "/lib/libc.so.6" is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for "/lib/ld-linux.so.2" is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for "/lib/libanl.so.1" is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for "/lib/libdl.so.2" is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for "/lib/libpthread.so.0" is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for "/usr/lib/libz.so.1" is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for "/lib/libnss_files.so.2" is not at the expected address (wrong library or version mismatch?)
warning: Could not load shared library symbols for 17 libraries, e.g. [...]
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
In contrast, the '-ix' option will load the specified gdbinit file _before_
parsing object/core files. This will remove said warnings.
See also: https://sourceware.org/bugzilla/show_bug.cgi?id=28330
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Since commit 39d334faa5 (package/pkg-qmake: add <pkg>_SYNC_QT_HEADERS
support), the qmake-package infra recognises said variable but the
manual has the wrong variable name, which is missing the "_QT" part.
We fix that by amending the manual to document the proper variable name.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This is based on Yann's and Arnout's experience with migrating
Buildroot.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
[yann.morin.1998@free.fr: add "For more details, "]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Currently, as Thomas pointed out [0], the help for kconfig packages is
not consistently used and handled by the different packages.
This commit introduces a generic help text for kconfig packages, that is
based on what the package declares:
- the list of kconfig editors it supports;
- whether it is possible to save back the configuration (impossible if
the package uses an in-tree defconfig file);
- whether the package actually supports (loading and saving) defconfig
files, by introducing a new variable a package can set if it does
not (only busybox is known to be in that case).
That new help helper is only used if the package does not already define
its own help, to be consistent with what we do for other _CMDS.
[0] http://lists.busybox.net/pipermail/buildroot/2021-July/313570.html
Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
The CMAKE_BUILD_TYPE is currently set as 'Debug' in case BR2_ENABLE_DEBUG is
set, and as 'Release' in other cases. However, while the description of
BR2_ENABLE_DEBUG is to enable debug symbols (no runtime impact), the 'Debug'
build type in CMake can actually have runtime impact. For one, because it
does not set -DNDEBUG like is done for 'Release', but also because packages
may do custom things based on it.
The question of which CMAKE_BUILD_TYPE Buildroot should set, be it 'Debug',
'Release', 'RelWithDebInfo' or others, has come up several times in the
past. See some references below:
- July 2016: switch from Debug to RelWithDebInfo:
https://git.buildroot.org/buildroot/commit/?id=4b0120183404913f7f7788ef4f0f6b51498ef363
- October 2016: switch from RelWithDebInfo back to Debug:
https://git.buildroot.org/buildroot/commit/?id=104bb29e0490bfb487e2e665448dd3ca07fcc2b5
and changes to make sure Buildroot's flags are respected:
https://git.buildroot.org/buildroot/commit/?id=12494ef48f893684d0800e7f6fe39a2ceaed0451
- August 2017: bug #10246 - "BR2_ENABLE_DEBUG does not have the expected
effect for cmake packages"
https://bugs.busybox.net/show_bug.cgi?id=10246
- August 2017: mail thread following bug #10246:
http://lists.busybox.net/pipermail/buildroot/2017-August/200778.html
In the last mail thread, Samuel Martin confirmed that the 'Release' build
type could be used in all cases, because Buildroot is actually making sure
that the optimization flags are those determined by Buildroot, not the
defaults of cmake, thanks to commit 12494ef48f.
But Arnout Vandecappelle objected to using always 'Release', stating that
users may actually want the extra assertions.
With the introduction of BR2_ENABLE_RUNTIME_DEBUG, Buildroot can now cater
for all cases:
- use CMAKE_BUILD_TYPE=Release by default. This makes sure that there is no
unexpected performance degradation triggered by enabling BR2_ENABLE_DEBUG.
- users can optionally enable BR2_ENABLE_RUNTIME_DEBUG if they want runtime
debug info like assertions, at the risk of introducing performance
degradation. In this case, we switch to CMAKE_BUILD_TYPE=Debug.
- orthogonally to the above, BR2_ENABLE_DEBUG still determines passing the
'-g' flag to enable debug symbols, and BR2_OPTIMIZE_X still determines the
used optimization flags.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Due to the recent events at Frenode [0], the channel has become a bit
unreliable (much spammed), and users have started to move away already,
as quite a few other projects have moved their IRC presence away from
Freenode.
There are a few alternatives. The first to spring to mind, is the new
Libera.Chat network [1], managed by the previous Freenode staff, so we
could expect quite a good experience there. However, it is a very young
network. The second well known alternative is the long-established OFTC,
which has been very reliable in its 20 years of existence.
So, let's move to OFTC, just because it has a track-record of robustness
(which Libera.Chat still has to build, for being young).
Note: there are a lot of other IRC networks, some very good too, but we
probably would be much off-topic on most of them.
[0] https://lwn.net/Articles/856543/
[1] https://libera.chat/
[2] https://www.oftc.net/
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: Matthew Weber <matthew.weber@collins.com>
Acked-by: Heiko Thiery <heiko.thiery@gmail.com>
Acked-By: Vincent Fazio <vfazio@xes-inc.com>
Acked-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Sometimes, post-build or post-image scripts need to reinvoke
Buildroot's make, for example to execute "make printvars".
However, so far post-build/image/fakeroot can't trivially run printvars
in a way that worked for both in-tree and out-of-tree builds. Indeed:
* "make printvars" would work for in-tree builds, but not out of tree
builds
* "make -C ${O} printvars" would work for out-of-tree builds, but not
in-tree builds
* "make -C ${BR2_CONFIG%/*} printvars" works in both cases, but it is
a bit cryptic, and two maintainers did not even immediately think of
it
In order to solve this, this commit exposes $(CONFIG_DIR) to
post-build/image/fakeroot scripts, through the EXTRA_ENV variable.
The documentation is updated accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr:
- reference BR2_CONFIG as an exemple
- slightly reword the commit log accordingly
- move the doc for CONFIG_DIR next to that of BR2_CONFIG
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The Github macro example shows something that is now considered
incorrect: using v1.0 as the VERSION. This is not longer recommended
as it prevents from matching with release-monitoring.org details.
Let's update the example, and add a note to explain this in more
details.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
FOO_CPE_ID_VALID is an internal implementation detail. Packages should
really define an actual CPE_ID variable to trigger their full CPE_ID
definition.
Reported-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Matthew Weber <matthew.weber@rockwellcollins.com>
Cc: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[Peter: completely drop any mention of _CPE_ID_VALID in the manual]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since commit dfcc18f84b cmake-package
_INSTALL_STAGING_OPTS/_INSTALL_TARGET_OPTS use 'install/fast'
instead of 'install', adjust documentation accordingly.
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The manual incorrectly refers to the script file as `setup-environment';
it is actually called `environment-setup'.
Signed-off-by: Konrad Schwarz <konrad.schwarz@siemens.com>
Reviewed-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Some qmake based packages need to call the syncqt.pl script before
building to have a properly populated "include" directory inside the
package build tree.
This script is normally automatically executed by qmake when a source
tree is from a git clone: buildroot purges the .git directory hence
the script never runs, and we need to call it explicitly. Setting
<pkg>_SYNC_QT_HEADERS = YES will force calling this script.
Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In order to simplify the usage of a buildroot toolchain within
the buildroot shell, a "configure" alias is provided to call
./configure with the correct flags.
Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Install an helper script to setup a build environment based on
Buildroot. It's useful when a developer wants to use a Buildroot
generated SDK to build an external project.
Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com>
Tested-by: Michael Trimarchi <michael@amarulasolutions.com>
Tested-by: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Maury Anderson <maury.anderson@collins.com>
Signed-off-by: Matt Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
[yann.morin.1998@free.fr:
- move before skeletons
- select the custom 'mine' skeleton, not the sysv one
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
[yann.morin.1998@free.fr:
- alphabetical order (skeleton before toolchain)
- leave the list of choices 'open'
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Add documentation about how to use SELinux in Buildroot, and what are
the available mechanisms to extend and customize the SELinux policy.
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
[Thomas: misc improvements.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The manual has a section on adding board support to upstream buildroot,
but it fails to mention some of the things we expect. Add more of them.
- Internal toolchain.
- Beautify defconfig file.
- Fixed versions for components.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Adam Duskett <Aduskett@gmail.com>
Reviewed-by: Adam Duskett <aduskett@gmail.com>
[yann.morin.1998@free.fr:
- use +monospace+ for the variables
- use _italic_ for sections in defconfig
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
There is no debug profile on cargo. The available profiles are: dev
(enabled by default), release, test and bench.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
