Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for Debian 12 and Fedora 40 #101

Merged
merged 9 commits into from Apr 1, 2024
Merged

Conversation

robwoolley
Copy link
Contributor

I added support for Debian 12 and Fedora 40.

The major problem for Debian was that it didn't like using pip to install virtualenv instead of using the distro's version. As part of fixing that, I also removed the change that used the Poky host tools to build dumb-init for the distro. All distros now use the provided virtualenv from the distro to create the virtualenv that is used to build dumb-init and run the tests with tox.

The major problem for Fedora was that wget has been replaced with wget2. This re-write currently does not support FTP. This caused the bitbake fetch to fail because we pass --passive-ftp to wget by default. I added the build tools to Fedora 40 so that the wget-native they provide could satisfy the requirement by bitbake.

This should fix #79 and replace #94.

Results for the GitHub Action workflow across all distro images can be found here: https://github.com/robwoolley/yocto-dockerfiles/actions/runs/8493277006

Skips the deployment step if we do not have the write credentials.

This ensures that forks can still run the workflow successfully
without publishing any container images.

Signed-off-by: Rob Woolley <rob.woolley@windriver.com>
All the distros explicitly install python3-pip in their Dockerfile.
Installing python3-pip in build-install-dumb-init.sh is redundant.

However, since only Debian, Ubuntu, and openSUSE remove python3-pip
in build-install-dumb-init.sh this makes the container images
inconsistent.

Signed-off-by: Rob Woolley <rob.woolley@windriver.com>
This sorts the list of packages and replaces tabs with spaces to
make it consistent between the two Debian releases.

Signed-off-by: Rob Woolley <rob.woolley@windriver.com>
The Python virtualenv package is provided by all distros.  We were
installing it with pip, however recent changes in Python produce
an error message:

  error: externally-managed-environment

This uses the package provided by the distro instead.

CentOS 7 calls the package python-virtualenv, but the virtualenv
command functions correctly with python3.

Signed-off-by: Rob Woolley <rob.woolley@windriver.com>
The buildtools environment is intended for running the poky builds.

It was sourced to provide Python3 to create a virtualenv for building
dumb-init.  However, dumb-init is not related to Poky.  The Python
interpreter and necessary tools should come from the distro.

Signed-off-by: Rob Woolley <rob.woolley@windriver.com>
The virtualenv script is provided by the python-virtualenv package
in the older Debian and Ubuntu releases.

This means that we need to install both python-virtualenv and
python3-virtualenv in order to use the virtualenv command with
Python3 and the Python3 version of the virtualenv module.

Signed-off-by: Rob Woolley <rob.woolley@windriver.com>
This is based on Debian 11 with the addition of the file package.

Signed-off-by: Rob Woolley <rob.woolley@windriver.com>
Based on the Fedora 39 Dockerfile.

Fedora 40 replaces wget with the re-write wget2.  This drop-in
replacement does not yet have support for FTP. As a result the
bitbake fetcher fails when it uses the wget provided by Fedora
with --passive-ftp.

The workaround is to use the poky build tools to use the
wget-native provided by the Yocto Project.

Signed-off-by: Rob Woolley <rob.woolley@windriver.com>
Signed-off-by: Rob Woolley <rob.woolley@windriver.com>
Copy link
Member

@moto-timo moto-timo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The original reason for the packages being in this order was to follow the Yocto Project documentation. I have long intended to send patches to yocto-docs to sort the packages alphabetically there (and the docs maintainer was open to this). Trying to find the one missing dependency when the list is not sorted is madness.

Copy link
Member

@moto-timo moto-timo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch. Thank you.

Copy link
Member

@moto-timo moto-timo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I no longer remember why we needed this work around. It is from long ago out of phase pip packages in the distributions, back in 2016-2017 or so. We do not want to carry distro specific workarounds if they are not needed. Excellent simplification. Thank you.

Copy link
Member

@moto-timo moto-timo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. This. This is exactly how we want to handle a new addition: all the distros act the same.

Copy link
Member

@moto-timo moto-timo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was likely necessary in 2016-2018 timeframe because the distributions carried ancient versions of python3. This is another nice simplification for modern times. If we see any issues with dumb-init that seem to be hosttools specific, we can revisit this design. There is a mild risk that we get different behaviors from different host python3.

Copy link
Member

@moto-timo moto-timo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not entirely sure we need to carry "python" (== python2) anymore, but this is sensible for the situation we have now. These are the oldest distributions we support and these are therefore the most likely to build old versions of Yocto Project that still had python2 support (pre-kirkstone). These distributions will go EOL soon anyway and we will drop them.

Copy link
Member

@moto-timo moto-timo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense. Thank you.

Copy link
Member

@moto-timo moto-timo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had already forgotten that I had added fedora-39. I need to sleep more. Thank you for the troublesome fix for wget2 and fedora-40. This was on my radar as a problem child, but I hadn't had any time to look yet.

Copy link
Member

@moto-timo moto-timo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is easy to miss. When we get around to documentation, we need to make sure to highlight this need. Thank you.

Copy link
Member

@moto-timo moto-timo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Everything looks good to me, or at least an improvement. Anything that turns up later from these changes can be addressed at that time. Adding virtualenv has been on "The List" for quite some time now and it is good to see the dumb-init compilation be simplified. I want to especially thank you for getting to the bottom of the two known troublesome releases, debian-12 and fedora-40.

@moto-timo moto-timo merged commit 505870b into crops:master Apr 1, 2024
16 checks passed
@moto-timo
Copy link
Member

Very thorough and following the practices of the completely undocumented design of the project. Thank you.

@moto-timo
Copy link
Member

Even though I am a Fedora Packager, I had forgotten that the Fedora 40 release date is not until April 12-15, 2024. However, there is no solid reason for us to not support "soon to be released" distributions, especially since we have historically caught a lot of HOSTTOOLS dependency problems with the crops containers. And we have likely achieved that again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

miss python3-pip package
2 participants