When the favicon image was added in f26e61319f (docs/website: add
favicon.png), it was added to a different directory then where the header's
icon link points. This causes the favicon to fail to load with 404.
While we are here, remove the "shortcut" rel attribute as it is non-standard
and it's recommended not to use it[1].
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel#sect4
Signed-off-by: Brandon Maier <brandon.maier@collins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 8ad1a2eaa5)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add a script to manage the .hash files in the BR2_GLOBAL_PATCH_DIR for
packages using custom versions.
To use it, run in a configured Buildroot directory, E.G.
make foo_defconfig; ./utils/add-custom-hashes
We support multiple patch directories in BR2_GLOBAL_PATCH_DIR. If multiple
directories are specified then use the last one as that is likely to be the
most specific one.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Peter: silence command -v invocation]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 4984d0f230)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, we expect and only use hash files that lie within the package
directory, alongside the .mk file. Those hash files are thus bundled
with Buildroot.
This implies that only what's known to Buildroot can ever get into those
hash files. For packages where the version is fixed (or a static
choice), then we can carry hashes for those known versions.
However, we do have a few packages for which the version is a free-form
entry, where the user can provide a custom location and/or version. like
a custom VCS tree and revision, or a custom tarball URL. This means that
Buildroot has no way to be able to cary hashes for such custom versions.
This means that there is no integrity check that what was downloaded is
what was expected. For a sha1 in a git tree, this is a minor issue,
because the sha1 by itself is already a hash of the expected content.
But for custom tarballs URLs, or for a tag in a VCS, there is indeed no
integrity check.
Buildroot can't provide such hashes, but interested users may want to
provide those, and currently there is no (easy) way to do so.
We leverage the existing global-patch-dir mechanism to look for extra
hash files. We use the same heuristic that is used for bundled hash
files, and for each global patch directory <dir>, we use the first file
to exist among:
1. look into <dir>/<package>/<version>/<package>.hash
2. look into <dir>/<package>/<package>.hash
Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 5d36710e36)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since commit 89f5e98932 (support/download/svn: generate reproducible
svn archives), we've been able to generate reproducible archives, and
thus we have been able to verify the hashes for those archives.
However, the manual was not changed, and still falsely hinted that this
was not the cae.
Fix that.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 6898781f03)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Sometimes it happens that a Company or a Physical Person sponsors the
creation and/or the upstreaming process of a patch, but at the moment
there is no way to give credits to it. In Linux they prepend '+sponsor'
to the e-mail of the contributor in both authorship and commit log tag as
discussed here[0]. So let's describe in the manual how to do that as a
standard.
[0]: https://lore.kernel.org/linux-doc/20230817220957.41582-1-giulio.benetti@benettiengineering.com/
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[yann.morin.1998@free.fr:
- reword to reference sub-addressing and the RFC
- move to the "submitting patches" section, that already deals with
SoB tags
- differentiate between Your/Their names
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit de349df08c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thierry GUIBERT <thierry.guibert@croix-rouge.fr>
[yann.morin.1998@free.fr: split off the previous patch by Thierry]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 4468f82885)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add a paragraph and an example about using the Buildroot image registry
hosted on gtilab.com, for people who want to build their own image based
on the offical one.
Signed-off-by: Thierry GUIBERT <thierry.guibert@croix-rouge.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit d9228faa4d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Previously, the documentation only requested links to upstream commits
when backporting patches.
Based on a mailing list discussion [0], patches should, when possible
and when approriate, provide a link as evidence that the patch has been
submitted upstream.
The motivation is that hopefully the patch gets applied to upstream at
some point reducing the long term maintenance burden within Buildroot.
This also makes future patch review on subsequent package version bumps
more streamlined.
For patches that are unique to BR and do not apply to the upstream
repository, patches should have a comment explaining why they do not
apply upstream.
[0] https://lists.buildroot.org/pipermail/buildroot/2023-March/666000.html
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 5b00b40a05)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The value of the RM variable in make is 'rm -f' [0], thus the additional
-f is redundant. Avoid it on the docs to avoid developers taking it as a
good example to follow.
[0] https://www.gnu.org/software/make/manual/make.html#index-RM
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 9a3d4e3818)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
If the examples given for launching an out-of-tree build are executed
as-is, this will result in the error message
Please configure Buildroot first (e.g. "make menuconfig")
Even if "make menuconfig" was run before, it's still not going to work
because the out-of-tree build doesn't use the in-tree .config.
Therefore, the example really should start with some config option.
Since "make menuconfig" is used in most other examples of creating a
config, use that here as well. Extend both examples with "menuconfig".
Reported-by: AndreiCherniaev <dungeonlords789@yandex.ru>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Add 'utils/docker-run make check-package' to the default workflow of
submitting patches, just after the rebase and before using format-patch.
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Cc: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Removing the "[Buildroot]" and the "Re:" from messages title to have a
cleaner look on the "news" boxes.
Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Feed source is moved to a local atom file available on the web server to
remove further problems with unreliable feed sources.
Moving the feed required a bit of refactor of the load_activity function
so it won't download two times te same url.
This change requires a cron job like this enabled on the website:
* * * * * wget -O new.atom https://lore.kernel.org/buildroot/new.atom
Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Historically we have been (more-or-less consistently, sometimes forgetting
some files) updating the end year of the copyright statements at the
beginning of a new year.
We're naturally not alone in that. Recently this was discussed in curl, and
it turns out that copyright years are not really required:
https://daniel.haxx.se/blog/2023/01/08/copyright-without-years/
So drop the years and simplify the copyright statements. While we're at it,
also ensure the same syntax (capital C, email address) is used everywhere.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
- Thank Smile for sponsoring the Buildroot Developers Meeting of
February 2023 by providing the meeting room
- Thank Armadeus and Logilin for their financial sponsoring in 2022
- Move older sponsors to the "Past sponsors" section
- Remove section about the Buildroot.org domain sponsor, as that
sponsoring ended in 2019.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The script "utils/check-package" checks that patch email prefix are
not be numbered. See:
https://git.buildroot.org/buildroot/tree/utils/checkpackagelib/lib_patch.py?h=2022.08-rc1#n42
The error message recommends to generate patches to be included in
Buildroot with the command 'git format-patch -N'.
The patch policy section in the Buildroot manual does mention that.
This commit adds a note about that requirement.
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The "find" and "xargs" commands, from the "findutils" package are used
during the build process. See for example [1].
Even if it's a quite common package which is almost sure to be present
on the host, it should be listed here. When writing new recipes, hooks
and scripts, it is generally safe and portable to restrict to the
host dependencies listed in those prerequisites.
This commit just add the missing "findutils" package in this list.
[1] https://git.buildroot.org/buildroot/tree/Makefile?h=2022.05.1#n737
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The manual explanation seemed to imply that the cache is always in
~/.buildroot-ccache/, but it's just the default value. Clarify this
point.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Back many years ago, we developed an Eclipse plugin that simplified
the usage of Buildroot toolchains. Enabling the BR2_ECLIPSE_REGISTER=y
was registering the Buildroot toolchain into a special file in your
HOME folder that the Eclipse plugin would recognize to allow to
directly use the Buildroot cross-compiler.
This Eclipse plugin has not been maintained for years. The last commit
in the repository dates back from September 2017. Since then Eclipse
has moved on, and the plugin is no longer compatible with current
versions of Eclipse.
Also, Eclipse is probably no longer that widely used in the embedded
Linux space, as other more modern IDEs have become more popular.
All in all, it's time to say good bye to this Eclipse integration.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Add a section to the "Integration topics" chapter about how we integrate
systemd. Add a first subsection about how dbus and dbus-broker work with
systemd.
This is just the start of the integration information about systemd.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
