Skip to contentSkip to conversation

support/docker: improve and extend our docker image (branch yem/dockers)

PATCH New Yann E. MORIN 1 participant 10 messages Dec 16, 2023

lore
Share & tools
lore
#0 lore raw

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

#1 lore raw

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
index 5a0f298eb1..b7519cc01a 100644
@@ -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
index e9c6968e79..739bed25d5 100644
@@ -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
index 627ecbacb1..315027c590 100644
@@ -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
#2 lore raw

PATCH 2/9 support/dependencies: make git a mandatory dependency

In reply to Yann E. MORIN

Currently, 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
index 262a5153f5..6f07cba551 100644
@@ -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
index 577a148c1e..87931f09c1 100644
@@ -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
index 6e7d067ccd..e18e799922 100755
@@ -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
#3 lore raw

PATCH 3/9 support/docker: retry even more

In reply to Yann E. MORIN

When 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
index 8c6e2add60..dd9b9c0f93 100644
@@ -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
#4 lore raw

PATCH 4/9 support/docker: allow the br-user to become root

In reply to Yann E. MORIN

When 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
index dd9b9c0f93..b62cf32824 100644
@@ -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
#5 lore raw

PATCH 5/9 support/docker: introduce per-distribution sub-directory

In reply to Yann E. MORIN

Currently, 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
new file mode 120000
index 0000000000..95f9ccb9fc
@@ -0,0 +1 @@
+debian-bullseye
\ No newline at end of file
support/docker/debian-bullseye/Dockerfile renamed from support/docker/Dockerfile +1 -1
similarity index 97%
rename from support/docker/Dockerfile
rename to support/docker/debian-bullseye/Dockerfile
index b62cf32824..f45ff6b0f8 100644
@@ -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
similarity index 100%
rename from support/docker/apt-sources.list
rename to support/docker/debian-bullseye/apt-sources.list
Signature · 6 lines
2.43.0

_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot
#6 lore raw

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
new file mode 100755
index 0000000000..d5c01771cf
@@ -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
#7 lore raw

PATCH 7/9 support/docker: split base image into three

In reply to Yann E. MORIN

Our 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/Dockerfile
support/docker/base deleted +0 -1
deleted file mode 120000
index 95f9ccb9fc..0000000000
@@ -1 +0,0 @@
-debian-bullseye
\ No newline at end of file
support/docker/build-all +23 -8
index d5c01771cf..6ae4ba5d25 100755
@@ -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
similarity index 59%
rename from support/docker/debian-bullseye/Dockerfile
rename to support/docker/debian-bullseye.base/Dockerfile
index f45ff6b0f8..a3e90a79ab 100644
@@ -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
similarity index 100%
rename from support/docker/debian-bullseye/apt-sources.list
rename to support/docker/debian-bullseye.base/apt-sources.list
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
new file mode 100644
index 0000000000..72f807b2d5
@@ -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
#8 lore raw

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
index 6f07cba551..d15f0a972a 100644
@@ -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
#9 lore raw

PATCH 9/9 support/docker: add a Fedora-38-based image

In reply to Yann E. MORIN

Unlink 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
new file mode 100644
index 0000000000..e48a621103
@@ -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
new file mode 100644
index 0000000000..fd0ebccade
@@ -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