support/docker: improve and extend our docker image (branch yem/dockers)
cover support/docker: improve and extend our docker image (branch yem/dockers)
Hello All!
This series attempts to improve our docker image, to fulfill a few goals:
- provide a minimalist, basic image with only the strictly required set of packages, so that it is easy to test that a package does not have a hidden dependency on tools provided by the distribution (e.g. does not require a python interpreter);
- provide an image that can be used in the CI to run all our tooling:
check-package, run-time tests, etc...
- provide an image that users can run to have a known-working, reference environment without modifying their host distribution (when they can't or don't want to);
- provide a set of similar images for various mainstream distributions, that can be used to investigate build issues on those distributions.
Regards,
Yann E. MORIN.
Regards,
Yann E. MORIN.
----------------------------------------------------------------
Yann E. MORIN (9):
doc/manual: fixup ordered lists support/dependencies: make git a mandatory dependency support/docker: retry even more support/docker: allow the br-user to become root support/docker: introduce per-distribution sub-directory support/docker: add script to generate docker images support/docker: split base image into three docs/manual: add section about docker images support/docker: add a Fedora-38-based image
docs/manual/adding-packages-directory.adoc | 14 +++----
docs/manual/adding-packages-gettext.adoc | 6 +--
docs/manual/customize-quick-guide.adoc | 28 ++++++-------
docs/manual/prerequisite.adoc | 45 ++++++++++++++++++++-
package/pkg-generic.mk | 8 ----
support/dependencies/dependencies.sh | 2 +-
support/docker/build-all | 32 +++++++++++++++
.../docker/{ => debian-bullseye.base}/Dockerfile | 27 ++-----------
.../{ => debian-bullseye.base}/apt-sources.list | 0
support/docker/debian-bullseye.ci/Dockerfile | 43 ++++++++++++++++++++
support/docker/debian-bullseye.user/Dockerfile | 32 +++++++++++++++
support/docker/fedora-38.base/Dockerfile | 43 ++++++++++++++++++++
support/docker/fedora-38.ci/Dockerfile | 47 ++++++++++++++++++++++
support/docker/fedora-38.user/Dockerfile | 35 ++++++++++++++++
14 files changed, 305 insertions(+), 57 deletions(-)
create mode 100755 support/docker/build-all
rename support/docker/{ => debian-bullseye.base}/Dockerfile (61%)
rename support/docker/{ => debian-bullseye.base}/apt-sources.list (100%)
create mode 100644 support/docker/debian-bullseye.ci/Dockerfile
create mode 100644 support/docker/debian-bullseye.user/Dockerfile
create mode 100644 support/docker/fedora-38.base/Dockerfile
create mode 100644 support/docker/fedora-38.ci/Dockerfile
create mode 100644 support/docker/fedora-38.user/Dockerfile--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH 1/9 doc/manual: fixup ordered lists
Recent asiidoc versions (at least 10.2.0 is known to report that), rendering the manual yields a few warnings related to ordered lists:
asciidoc: WARNING: customize-quick-guide.adoc: line 13: list item index: expected 2 got 1
asciidoc: WARNING: customize-quick-guide.adoc: line 15: list item index: expected 3 got 1 [...]
asciidoc: WARNING: customize-quick-guide.adoc: line 65: list item index: expected 13 got 1
asciidoc: WARNING: customize-quick-guide.adoc: line 66: list item index: expected 14 got 1
asciidoc: WARNING: adding-packages-gettext.adoc: line 30: list item index: expected 2 got 1
asciidoc: WARNING: adding-packages-gettext.adoc: line 41: list item index: expected 3 got 1
The reason is that we use the same index to tell asciidoc to automatically number items.
However, the official way to provide an automatic index is to write no index:
https://docs.asciidoctor.org/asciidoc/latest/lists/ordered/
[...] since the numbering is obvious, the AsciiDoc processor will insert the numbers for you if you omit them:
[...]
If you number the ordered list explicitly, you have to manually keep the list numerals sequential. Otherwise, you will get a warning.
So, abide by the documentation, and drop the repeating indices to ordered lists where we want automatic numbering.
Note that there is another ordered list, in adding-packages-directory.adoc, but it does use explicit, sequential numbering. For consistency within the whole document, we also convert it.
To avoid extra useless churn, the idnentation of the items is not changed to match the elided indices.
--- docs/manual/adding-packages-directory.adoc | 14 +++++------ docs/manual/adding-packages-gettext.adoc | 6 ++--- docs/manual/customize-quick-guide.adoc | 28 +++++++++++----------- 3 files changed, 24 insertions(+), 24 deletions(-)
docs/manual/adding-packages-directory.adoc +7 -7
@@ -44,13 +44,13 @@ project after an empty line. As a convention specific to Buildroot, the ordering of the attributes is as follows: -1. The type of option: +bool+, +string+... with the prompt -2. If needed, the +default+ value(s) -3. Any dependencies on the target in +depends on+ form -4. Any dependencies on the toolchain in +depends on+ form -5. Any dependencies on other packages in +depends on+ form -6. Any dependency of the +select+ form -7. The help keyword and help text. +. The type of option: +bool+, +string+... with the prompt +. If needed, the +default+ value(s) +. Any dependencies on the target in +depends on+ form +. Any dependencies on the toolchain in +depends on+ form +. Any dependencies on other packages in +depends on+ form +. Any dependency of the +select+ form +. The help keyword and help text. You can add other sub-options into a +if BR2_PACKAGE_LIBFOO...endif+ statement to configure particular things in your software. You can look at
docs/manual/adding-packages-gettext.adoc +3 -3
@@ -23,11 +23,11 @@ Due to this, and in order to make sure that Native Language Support is properly handled, packages in Buildroot that can use NLS support should: -1. Ensure NLS support is enabled when +BR2_SYSTEM_ENABLE_NLS=y+. This +. Ensure NLS support is enabled when +BR2_SYSTEM_ENABLE_NLS=y+. This is done automatically for 'autotools' packages and therefore should only be done for packages using other package infrastructures. -1. Add +$(TARGET_NLS_DEPENDENCIES)+ to the package +. Add +$(TARGET_NLS_DEPENDENCIES)+ to the package +<pkg>_DEPENDENCIES+ variable. This addition should be done unconditionally: the value of this variable is automatically adjusted by the core infrastructure to contain the relevant list of
@@ -38,7 +38,7 @@ should: also contains +gettext+ in order to get the full-blown 'gettext' implementation. -1. If needed, add +$(TARGET_NLS_LIBS)+ to the linker flags, so that +. If needed, add +$(TARGET_NLS_LIBS)+ to the linker flags, so that the package gets linked with +libintl+. This is generally not needed with 'autotools' packages as they usually detect automatically that they should link with +libintl+. However,
docs/manual/customize-quick-guide.adoc +14 -14
@@ -9,11 +9,11 @@ now summarize all this by providing step-by-step instructions to storing your project-specific customizations. Clearly, the steps that are not relevant to your project can be skipped. -1. +make menuconfig+ to configure toolchain, packages and kernel. -1. +make linux-menuconfig+ to update the kernel config, similar for +. +make menuconfig+ to configure toolchain, packages and kernel. +. +make linux-menuconfig+ to update the kernel config, similar for other configuration like busybox, uclibc, ... -1. +mkdir -p board/<manufacturer>/<boardname>+ -1. Set the following options to +board/<manufacturer>/<boardname>/<package>.config+ +. +mkdir -p board/<manufacturer>/<boardname>+ +. Set the following options to +board/<manufacturer>/<boardname>/<package>.config+ (as far as they are relevant): * +BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE+ * +BR2_PACKAGE_BUSYBOX_CONFIG+
@@ -21,7 +21,7 @@ your project can be skipped. * +BR2_TARGET_AT91BOOTSTRAP3_CUSTOM_CONFIG_FILE+ * +BR2_TARGET_BAREBOX_CUSTOM_CONFIG_FILE+ * +BR2_TARGET_UBOOT_CUSTOM_CONFIG_FILE+ -1. Write the configuration files: +. Write the configuration files: * +make linux-update-defconfig+ * +make busybox-update-config+ * +make uclibc-update-config+
@@ -29,38 +29,38 @@ your project can be skipped. board/<manufacturer>/<boardname>/at91bootstrap3.config+ * +make barebox-update-defconfig+ * +make uboot-update-defconfig+ -1. Create +board/<manufacturer>/<boardname>/rootfs-overlay/+ and fill it +. Create +board/<manufacturer>/<boardname>/rootfs-overlay/+ and fill it with additional files you need on your rootfs, e.g. +board/<manufacturer>/<boardname>/rootfs-overlay/etc/inittab+. Set +BR2_ROOTFS_OVERLAY+ to +board/<manufacturer>/<boardname>/rootfs-overlay+. -1. Create a post-build script +. Create a post-build script +board/<manufacturer>/<boardname>/post_build.sh+. Set +BR2_ROOTFS_POST_BUILD_SCRIPT+ to +board/<manufacturer>/<boardname>/post_build.sh+ -1. If additional setuid permissions have to be set or device nodes have +. If additional setuid permissions have to be set or device nodes have to be created, create +board/<manufacturer>/<boardname>/device_table.txt+ and add that path to +BR2_ROOTFS_DEVICE_TABLE+. -1. If additional user accounts have to be created, create +. If additional user accounts have to be created, create +board/<manufacturer>/<boardname>/users_table.txt+ and add that path to +BR2_ROOTFS_USERS_TABLES+. -1. To add custom patches to certain packages, set +BR2_GLOBAL_PATCH_DIR+ +. To add custom patches to certain packages, set +BR2_GLOBAL_PATCH_DIR+ to +board/<manufacturer>/<boardname>/patches/+ and add your patches for each package in a subdirectory named after the package. Each patch should be called +<packagename>-<num>-<description>.patch+. -1. Specifically for the Linux kernel, there also exists the option +. Specifically for the Linux kernel, there also exists the option +BR2_LINUX_KERNEL_PATCH+ with as main advantage that it can also download patches from a URL. If you do not need this, +BR2_GLOBAL_PATCH_DIR+ is preferred. U-Boot, Barebox, at91bootstrap and at91bootstrap3 also have separate options, but these do not provide any advantage over +BR2_GLOBAL_PATCH_DIR+ and will likely be removed in the future. -1. If you need to add project-specific packages, create +. If you need to add project-specific packages, create +package/<manufacturer>/+ and place your packages in that directory. Create an overall +<manufacturer>.mk+ file that includes the +.mk+ files of all your packages. Create an overall +Config.in+ file that sources the +Config.in+ files of all your packages. Include this +Config.in+ file from Buildroot's +package/Config.in+ file. -1. +make savedefconfig+ to save the buildroot configuration. -1. +cp defconfig configs/<boardname>_defconfig+ +. +make savedefconfig+ to save the buildroot configuration. +. +cp defconfig configs/<boardname>_defconfig+
Signature · 6 lines
2.43.0 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH 2/9 support/dependencies: make git a mandatory dependency
In reply to Yann E. MORINCurrently, we only require wget as a download tool. However, git is very pervasive and used in many of the packages, making it a de facto requirement.
Act on that situation and promote git from an optional dependency to a mandatory dependency.
--- docs/manual/prerequisite.adoc | 2 +- package/pkg-generic.mk | 8 -------- support/dependencies/dependencies.sh | 2 +- 3 files changed, 2 insertions(+), 10 deletions(-)
docs/manual/prerequisite.adoc +1 -1
@@ -41,6 +41,7 @@ between distributions). * Source fetching tools: ** +wget+ +** +git+ [[requirement-optional]]
@@ -76,7 +77,6 @@ corresponding tool on the host system: + ** +bazaar+ ** +cvs+ -** +git+ ** +mercurial+ ** +scp+ ** +sftp+
package/pkg-generic.mk +0 -8
@@ -1240,7 +1240,6 @@ endif ifeq ($$($(2)_SITE_METHOD),svn) DL_TOOLS_DEPENDENCIES += svn else ifeq ($$($(2)_SITE_METHOD),git) -DL_TOOLS_DEPENDENCIES += git ifneq ($$($(2)_GIT_LFS),) DL_TOOLS_DEPENDENCIES += git-lfs endif
@@ -1254,13 +1253,6 @@ else ifeq ($$($(2)_SITE_METHOD),cvs) DL_TOOLS_DEPENDENCIES += cvs endif # SITE_METHOD -# cargo/go vendoring (may) need git -ifeq ($$($(2)_DOWNLOAD_POST_PROCESS),cargo) -DL_TOOLS_DEPENDENCIES += git -else ifeq ($$($(2)_DOWNLOAD_POST_PROCESS),go) -DL_TOOLS_DEPENDENCIES += git -endif - DL_TOOLS_DEPENDENCIES += $$(call extractor-system-dependency,$$($(2)_SOURCE)) # Ensure all virtual targets are PHONY. Listed alphabetically.
support/dependencies/dependencies.sh +1 -1
@@ -154,7 +154,7 @@ fi # Check that a few mandatory programs are installed missing_progs="no" -for prog in perl tar wget cpio unzip rsync bc cmp find xargs ${DL_TOOLS} ; do +for prog in perl tar wget git cpio unzip rsync bc cmp find xargs ${DL_TOOLS} ; do if ! which $prog > /dev/null ; then echo "You must install '$prog' on your build machine"; missing_progs="yes"
Signature · 6 lines
2.43.0 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH 3/9 support/docker: retry even more
In reply to Yann E. MORINWhen downloading from and old Debian snapshot, connections can timeout while their storage backend retrieves the requested file from cold (very cold!) storage, and this can take quite some time if that file has not been retrieved for a long time, so much so that retrying three times might not be enough.
Increase the number of retries yet a little bit more to avoid the issue.
--- support/docker/Dockerfile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
support/docker/Dockerfile +2 -2
@@ -20,8 +20,8 @@ COPY apt-sources.list /etc/apt/sources.list # The container has no package lists, so need to update first RUN dpkg --add-architecture i386 && \ - apt-get -o APT::Retries=3 update -y -RUN apt-get -o APT::Retries=3 install -y --no-install-recommends \ + apt-get -o APT::Retries=5 update -y +RUN apt-get -o APT::Retries=5 install -y --no-install-recommends \ bc \ build-essential \ bzr \
Signature · 6 lines
2.43.0 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH 4/9 support/docker: allow the br-user to become root
In reply to Yann E. MORINWhen our Dockerfiles (and images) get reused by users, they might need to locally add new packages or tweak the iamge to heir local needs.
It is posisble to become root in the container, but implies running a second command from another terminal, like so:
(term-1) $ ./utils/docker-run
$ colordiff --version
bash: colordiff: command not found
(termn-2) $ docker exec -u 0:0 -ti NAME sh # apt install -y colordiff
$ colordiff --version
diff (GNU diffutils) 3.7
[...]
Usually, however, people are a bit lazy and prefer to go the traditional way of using sudo. ;-)
So, register the br-user to become root by running (exactly!):
$ sudo su -
This will allow acutally becoing root without prompting for a password, but no other command will be accepted, and no other paramter will be accepted either, so that it is still possible to catch packages that try to run sudo as part of their build/install process.
--- support/docker/Dockerfile | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
support/docker/Dockerfile +4 -1
@@ -49,6 +49,7 @@ RUN apt-get -o APT::Retries=5 install -y --no-install-recommends \ rsync \ shellcheck \ subversion \ + sudo \ unzip \ wget \ && \
@@ -60,7 +61,9 @@ RUN sed -i 's/# \(en_US.UTF-8\)/\1/' /etc/locale.gen && \ /usr/sbin/locale-gen RUN useradd -ms /bin/bash br-user && \ - chown -R br-user:br-user /home/br-user + chown -R br-user:br-user /home/br-user && \ + printf 'br-user ALL=NOPASSWD: /bin/su -\n' >/etc/sudoers.d/br-user && \ + chmod 0440 /etc/sudoers.d/br-user USER br-user WORKDIR /home/br-user
Signature · 6 lines
2.43.0 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH 5/9 support/docker: introduce per-distribution sub-directory
In reply to Yann E. MORINCurrently, we only generate one docker image, for use by the gitlab-ci infra.
However, users have expressed an interest in using that image for other uses, like:
- reproducing build failures as reported by the gitlab-ci jobs,
- having a ready-to-use base image to use as-is, or as a template for further customisations.
Additionally, some users have reported the need for similar base images, but based off different distros, with the same goals as above, plus:
- reproducing build failures reported by users on other distros.
As a first step toward providing such images, move our Dockerfile and its accompanying resources to a sub-directory, named after the distribution it is based off.
Add a symlink that allows to also reference our base image without having to know what distribution it is based on.
---
support/docker/base | 1 +
support/docker/{ => debian-bullseye}/Dockerfile | 2 +-
support/docker/{ => debian-bullseye}/apt-sources.list | 0
3 files changed, 2 insertions(+), 1 deletion(-)
create mode 120000 support/docker/base
rename support/docker/{ => debian-bullseye}/Dockerfile (97%)
rename support/docker/{ => debian-bullseye}/apt-sources.list (100%)support/docker/base new file +1 -0
@@ -0,0 +1 @@ +debian-bullseye
support/docker/debian-bullseye/Dockerfile renamed from support/docker/Dockerfile +1 -1
@@ -1,6 +1,6 @@ # This Dockerfile generates the docker image that gets used by Gitlab CI # To build it (YYYYMMDD.HHMM is the current date and time in UTC): -# docker build -t registry.gitlab.com/buildroot.org/buildroot/base:YYYYMMDD.HHMM support/docker +# docker build -t registry.gitlab.com/buildroot.org/buildroot/base:YYYYMMDD.HHMM support/docker/debian-stretch # docker push registry.gitlab.com/buildroot.org/buildroot/base:YYYYMMDD.HHMM # We use a specific tag for the base image *and* the corresponding date
support/docker/debian-bullseye/apt-sources.list renamed from support/docker/apt-sources.list +0 -0
Signature · 6 lines
2.43.0 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH 6/9 support/docker: add script to generate docker images
In reply to Yann E. MORIN--- support/docker/build-all | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100755 support/docker/build-all
support/docker/build-all new file +17 -0
@@ -0,0 +1,17 @@ +#!/bin/sh +set -e + +BR2_DOCKER_VERSION="${1}" + +if [ -z "${BR2_DOCKER_VERSION}" ]; then + printf 'Usage: %s VERSION\n' "${0}" + exit 1 +fi + +BASE_DIR="${0%/*}" +for context_dir in "${BASE_DIR}"/*/; do \ + distro="$(basename "${context_dir}")" + docker build \ + -t "buildroot/${distro}:${BR2_DOCKER_VERSION}" \ + "${context_dir}" +done
Signature · 6 lines
2.43.0 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH 7/9 support/docker: split base image into three
In reply to Yann E. MORINOur basic image should have only what is strictly required to do the build, i.e. only the packages listed as mandatory in the manual.
Then we need an image for running our CI, with a few additional toolings.
Finally, we want an image that users can run to use Buildroot (not to develop on Buildroot, but just to use it).
---
support/docker/base | 1 -
support/docker/build-all | 31 +++++++++----
.../Dockerfile | 28 ++----------
.../apt-sources.list | 0
support/docker/debian-bullseye.ci/Dockerfile | 43 +++++++++++++++++++
.../docker/debian-bullseye.user/Dockerfile | 32 ++++++++++++++
6 files changed, 101 insertions(+), 34 deletions(-)
delete mode 120000 support/docker/base
rename support/docker/{debian-bullseye => debian-bullseye.base}/Dockerfile (59%)
rename support/docker/{debian-bullseye => debian-bullseye.base}/apt-sources.list (100%)
create mode 100644 support/docker/debian-bullseye.ci/Dockerfile
create mode 100644 support/docker/debian-bullseye.user/Dockerfilesupport/docker/base deleted +0 -1
@@ -1 +0,0 @@ -debian-bullseye
support/docker/build-all +23 -8
@@ -2,16 +2,31 @@ set -e BR2_DOCKER_VERSION="${1}" +BR2_REGISTRY="${2:-registry.gitlab.com/buildroot.org/}" -if [ -z "${BR2_DOCKER_VERSION}" ]; then - printf 'Usage: %s VERSION\n' "${0}" +case "${BR2_DOCKER_VERSION}" in + (""|*/*) + printf 'Usage: %s VERSION [REGSITRY]\n' "${0}" exit 1 -fi + ;; +esac +case "${BR2_REGISTRY}" in + (""|*/) ;; + (*) BR2_REGISTRY="${BR2_REGISTRY}/";; +esac BASE_DIR="${0%/*}" -for context_dir in "${BASE_DIR}"/*/; do \ - distro="$(basename "${context_dir}")" - docker build \ - -t "buildroot/${distro}:${BR2_DOCKER_VERSION}" \ - "${context_dir}" +# "ci" images use FROM on the "base" images, so need to ensure we build +# the "base" images first (don't rely on alphabetical ordering!). Ditto, +# the 'user' images are based on the 'ci' ones. +for type in base ci user; do + for context_dir in "${BASE_DIR}"/*."${type}"/; do \ + [ -e "${context_dir}" ] || continue + distro="$(basename "${context_dir}")" + docker build \ + --build-arg BR2_REGISTRY="${BR2_REGISTRY}" \ + --build-arg BR2_DOCKER_VERSION="${BR2_DOCKER_VERSION}" \ + -t "${BR2_REGISTRY}buildroot/${distro}:${BR2_DOCKER_VERSION}" \ + "${context_dir}" + done done
support/docker/debian-bullseye.base/Dockerfile renamed from support/docker/debian-bullseye/Dockerfile +3 -25
@@ -1,7 +1,5 @@ -# This Dockerfile generates the docker image that gets used by Gitlab CI -# To build it (YYYYMMDD.HHMM is the current date and time in UTC): -# docker build -t registry.gitlab.com/buildroot.org/buildroot/base:YYYYMMDD.HHMM support/docker/debian-stretch -# docker push registry.gitlab.com/buildroot.org/buildroot/base:YYYYMMDD.HHMM +# vi: ft=dockerfile +# Debian-based minimal image with only mandatory packages # We use a specific tag for the base image *and* the corresponding date # for the repository., so do not forget to update the apt-sources.list
@@ -24,32 +22,14 @@ RUN dpkg --add-architecture i386 && \ RUN apt-get -o APT::Retries=5 install -y --no-install-recommends \ bc \ build-essential \ - bzr \ ca-certificates \ - cmake \ cpio \ - cvs \ file \ g++-multilib \ git \ libc6:i386 \ - libncurses5-dev \ locales \ - mercurial \ - openssh-server \ - python3 \ - python3-flake8 \ - python3-magic \ - python3-nose2 \ - python3-pexpect \ - python3-pytest \ - qemu-system-arm \ - qemu-system-misc \ - qemu-system-x86 \ rsync \ - shellcheck \ - subversion \ - sudo \ unzip \ wget \ && \
@@ -61,9 +41,7 @@ RUN sed -i 's/# \(en_US.UTF-8\)/\1/' /etc/locale.gen && \ /usr/sbin/locale-gen RUN useradd -ms /bin/bash br-user && \ - chown -R br-user:br-user /home/br-user && \ - printf 'br-user ALL=NOPASSWD: /bin/su -\n' >/etc/sudoers.d/br-user && \ - chmod 0440 /etc/sudoers.d/br-user + chown -R br-user:br-user /home/br-user USER br-user WORKDIR /home/br-user
support/docker/debian-bullseye.base/apt-sources.list renamed from support/docker/debian-bullseye/apt-sources.list +0 -0
support/docker/debian-bullseye.ci/Dockerfile new file +43 -0
43 lines not on this page · raw message
support/docker/debian-bullseye.user/Dockerfile new file +32 -0
@@ -0,0 +1,32 @@ +# This Dockerfile generates the docker image that can be used by users +# to get a workign build environment +# To build it (YYYYMMDD.HHMM is the current date and time in UTC): +# docker build -t registry.gitlab.com/buildroot.org/buildroot/base:YYYYMMDD.HHMM support/docker/debian-stretch +# docker push registry.gitlab.com/buildroot.org/buildroot/base:YYYYMMDD.HHMM + +# Based on our reference build image +ARG BR2_REGISTRY +ARG BR2_DOCKER_VERSION +FROM ${BR2_REGISTRY}buildroot/debian-bullseye.ci:${BR2_DOCKER_VERSION} + +LABEL maintainer="Buildroot mailing list <[email protected]>" \ + vendor="Buildroot" \ +description="Container with everything needed to run Buildroot" + +USER root +WORKDIR /root +ENV HOME /root + +RUN apt-get -o APT::Retries=5 install -y --no-install-recommends \ + libncurses5-dev \ + sudo \ + && \ + apt-get -y autoremove && \ + apt-get -y clean && \ + printf 'br-user ALL=NOPASSWD: /bin/su -\n' >/etc/sudoers.d/br-user && \ + chmod 0440 /etc/sudoers.d/br-user + +USER br-user +WORKDIR /home/br-user +ENV HOME /home/br-user +ENV LC_ALL en_US.UTF-8
Signature · 6 lines
2.43.0 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH 8/9 docs/manual: add section about docker images
In reply to Yann E. MORIN--- docs/manual/prerequisite.adoc | 43 +++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+)
docs/manual/prerequisite.adoc +43 -0
@@ -96,3 +96,46 @@ corresponding tool on the host system: * Graph generation tools: ** +graphviz+ to use 'graph-depends' and '<pkg>-graph-depends' ** +python-matplotlib+ to use 'graph-build' + + +=== Docker images + +The Buildroot project also provides a set of Docker images descriptions, +in the directory `support/docker/`, which provide ready to use systems +for using Buildroot. Those images are available on the +https://gitlab.com/buildroot.org/buildroot/container_registry[docker +registry of the Buildroot project]. + +For a given distribution, and a given version of that distribution, +there are up to three variants: 'base', 'ci', and 'user': + +* the 'base' variant is a minimalist system, which contains only the + minimal set of packages required for running Buildroot (i.e. the + packages listed as mandatory in the manual). The 'base' image shall + be used to verify that a package has all its dependencies defined, + for example by using: + +** `utils/test-pkg` + +* the 'ci' image inherits from the 'base' one, and adds the few packages + that are needed to run the CI jobs. The 'ci' image shall be used to + run the various tests and tooling in Buildroot: + +** `make check-package` +** `support/testing/run-tests` +** `utils/check-symbols` + +* the 'user' image inherits from the 'ci' image, and adds a few more + packages and setup that are useful for interactive use (e.g. the + `br-user` is sudoer without any password, but can just run a login + shell, using _exactly_ `sudo su -`). + +The Buildroot developers by no mean enforce or recommend using those +images, or even suggest that Buildroot only works when using one of +those images; instead, they are known-working environments that can be +used where the distribution on the build machine can't be configured +to match Buildroot's needs (e.g. on a shared server), or to provide a +quick and easy way to test on various ditributions. + +Finally, those images can serve as the basis for further customisation: +one can use them in the `FROM` directive in their own +Dockerfile+.
Signature · 6 lines
2.43.0 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH 9/9 support/docker: add a Fedora-38-based image
In reply to Yann E. MORINUnlink Debian, Fedora does not provide any time-based snapshots that would provide a reproducible distribution.
However, it looks like the "main" repository does not change after the release, with updates going into the aptly named "updates" repository.
So, in order to be as reproducible as possible, we remove all non-main repositories, which also means no so-called modularity (but it's been dropped upstream anyway [0]), and no h264 decoder from Cisco (but we don;t need that for a Buildroot build image).
[0] https://fedoraproject.org/wiki/Changes/RetireModularity
--- support/docker/fedora-38.base/Dockerfile | 43 ++++++++++++++++++++++ support/docker/fedora-38.ci/Dockerfile | 47 ++++++++++++++++++++++++ support/docker/fedora-38.user/Dockerfile | 35 ++++++++++++++++++ 3 files changed, 125 insertions(+) create mode 100644 support/docker/fedora-38.base/Dockerfile create mode 100644 support/docker/fedora-38.ci/Dockerfile create mode 100644 support/docker/fedora-38.user/Dockerfile
support/docker/fedora-38.base/Dockerfile new file +43 -0
@@ -0,0 +1,43 @@ +# vi: ft=dockerfile +# Note: this dockerfile is not reproducible: even if we pin the image +# to a specific tag and hash, the repository where we fetch packages +# from is not pinned to a specific point in time; i.e. we'll get +# whatever is current at the moment we build. + +FROM fedora:38@sha256:e9b68b3351329d72df54dfa5d10b2310e10829f6af58a8c30e0fc612d4f3b749 + +LABEL maintainer="Buildroot mailing list <[email protected]>" \ + vendor="Buildroot" \ + description="Container based on Fedora 38, with everything needed to run Buildroot already installed" + +# Only keep the main repository, so we only get packages as they were +# at the time of release, and we get no update: this helps a bit with +# reproducibility. +RUN rm -f /etc/yum.repos.d/fedora-*.repo && \ + dnf -y install \ + @development-tools \ + bc \ + bzip2 \ + cpio \ + file \ + gcc-c++ \ + git \ + perl-English \ + perl-ExtUtils-MakeMaker \ + perl-FindBin \ + perl-IPC-Cmd \ + perl-Thread-Queue \ + rsync \ + unzip \ + wget \ + which \ + && \ + dnf -y clean all + +RUN useradd -ms /bin/bash br-user && \ + chown -R br-user:br-user /home/br-user + +USER br-user +WORKDIR /home/br-user +ENV HOME /home/br-user +ENV LC_ALL C.utf8
support/docker/fedora-38.ci/Dockerfile new file +47 -0
47 lines not on this page · raw message
support/docker/fedora-38.user/Dockerfile new file +35 -0
@@ -0,0 +1,35 @@ +# vi: ft=dockerfile +# Note: this dockerfile is not reproducible: even if we pin the image +# to a specific tag and hash, the repository where we fetch packages +# from is not pinned to a specific point in time; i.e. we'll get +# whatever is current at the moment we build. + +# Based on our reference build image +ARG BR2_REGISTRY +ARG BR2_DOCKER_VERSION +FROM ${BR2_REGISTRY}buildroot/fedora-38.ci:${BR2_DOCKER_VERSION} + +LABEL maintainer="Buildroot mailing list <[email protected]>" \ + vendor="Buildroot" \ + description="Container based on Fedora 38, with everything needed to run Buildroot already installed" + +USER root +WORKDIR /root +ENV HOME /root + +# Only keep the main repository, so we only get packages as they were +# at the time of release, and we get no update: this helps a bit with +# reproducibility. +RUN rm -f /etc/yum.repos.d/fedora-*.repo && \ + dnf -y install \ + ncurses-devel \ + sudo \ + && \ + dnf -y clean all && \ + printf 'br-user ALL=NOPASSWD: /usr/bin/su -\n' >/etc/sudoers.d/br-user && \ + chmod 0440 /etc/sudoers.d/br-user + +USER br-user +WORKDIR /home/br-user +ENV HOME /home/br-user +ENV LC_ALL C.utf8
Signature · 6 lines
2.43.0 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot