images: Add Arch Linux image #861
Conversation
|
Build failed.
|
|
Needs I'm a package maintainer in Arch and maintain most of the container stack there. I'm interested in this support so if there is anything missing please do poke me and I'll try solve it. |
I added Edit: I'll remove |
|
I'm not sure what upstream expects frankly. But if they want a similar base set of packages thats fine. Arch doesn't lend itself to small disk footprints though :)
Just to clarify, |
Besides the required files listed in the readme, I didn't come across any specific minimal set of packages described anywhere, so I don't think they have an official list. The Fedora version of the package list looks like common programs developers would use, so if there are more useful alternatives that more Arch users use, we can add those instead.
That's great, not needing flatpak installed inside the container reduces the image size significantly. |
|
Build failed.
|
|
Build failed.
|
|
Are man pages working in here? I have a similar image and doesn't seem like so.. |
|
We explicitly remove all the man pages and a lot of fluff such as translations, locales to keep the image size down. https://github.com/archlinux/archlinux-docker/blob/master/pacman-conf.d-noextract.conf#L8 |
While on that note, I will probably update the readme to be Arch-specific (although I'm not sure why every image even has to have its own readme if they all look the same as the main readme) and I wanted to list the steps required to re-add the manpages if so desired. Can you please describe the process or commands needed to re-add the manpages or point me to the proper wiki article. |
|
I think just removing that like at the end of the build should be sufficent (https://github.com/archlinux/archlinux-docker/blob/master/pacman-conf.d-noextract.conf#L8). I just removed that line and did something like
and alas had manpages. Like @Foxboron said it's probaly a good idea not to ship the image with them though and instead let them get pulled in as the user updates and installs packages within the toolbox |
Yup, this is what I meant, not shipping manpages with the image or having to create your own image with manpages, but rather allowing users to re-add the manpages inside the container if needed. Is reinstalling / updating the packages the only way to re-add them? |
|
Build failed.
|
|
A little side note, Arch's glibc is out of date so being blocked by: |
|
Just for reference/FYI: https://github.com/toolbox-images/toolbox-images/tree/main/images/arch |
Didn't realize how easy it was to set that up, but in any case, the PR adds extra toolbox-specific packages so I think it's still useful. I have no idea why it fails for Rawhide though, any info on that is very welcome. |
|
That container is a "hack" and doesn't conform to the toolbox specification defined in this repo. |
|
+1 on @Foxboron thought and including some critical packages to have in the toolbox. It's a good workaround but much preferred to have a tailored image. |
|
BTW mlocate does work in the fedora toolboxes now. |
|
@HarryMichal are you interested in including the Arch image in toolbox? The PR is complete, there are no more changes planned for now. |
I think because of bind mounting /usr/bin/toolbox which is linked to glibc-2.34 in Rawhide and F35. |
|
Build succeeded.
|
|
Could this be merged then? :) |
|
For the folks that been testing a similar Arch toolbox has xdg-open been working correctly? |
|
No. |
|
Right, flatpak-spawn proplely works but not |
|
Well, xdg-open doesn't work for fedora-toolbox either, unless you mean something different. |
|
#568 I'm now facing this. Anyone else? Is there a good community on matrix to talk about and squash these things? |
|
Build succeeded. ✔️ unit-test SUCCESS in 9m 21s |
|
Here is a diff with the changes I had locally. But looking at it now, if we moved diff --git a/src/pkg/utils/utils.go b/src/pkg/utils/utils.go
index 7a6b29a..1c8316f 100644
--- a/src/pkg/utils/utils.go
+++ b/src/pkg/utils/utils.go
@@ -47,6 +47,7 @@ type Distro struct {
ImageBasename string
GetFullyQualifiedImage GetFullyQualifiedImageFunc
ParseRelease ParseReleaseFunc
+ OverrideRelease string
}
const (
@@ -102,18 +103,28 @@ var (
"fedora-toolbox",
getFullyQualifiedImageFedora,
parseReleaseFedora,
+ "",
},
"rhel": {
"rhel-toolbox",
"toolbox",
getFullyQualifiedImageRHEL,
parseReleaseRHEL,
+ "",
},
"ubuntu": {
"ubuntu-toolbox",
"ubuntu-toolbox",
getFullyQualifiedImageUbuntu,
parseReleaseUbuntu,
+ "",
+ },
+ "arch": {
+ "archlinux-toolbox",
+ "archlinux-toolbox",
+ getFullyQualifiedImageArchLinux,
+ parseReleaseArchLinux,
+ "latest",
},
}
)
@@ -144,6 +155,9 @@ func init() {
if err == nil {
containerNamePrefixDefault = distroObj.ContainerNamePrefix
distroDefault = hostID
+ if distroObj.OverrideRelease != "" {
+ release = distroObj.OverrideRelease
+ }
releaseDefault = release
}
}
@@ -355,6 +369,11 @@ func getFullyQualifiedImageUbuntu(image, release string) string {
return imageFull
}
+func getFullyQualifiedImageArchLinux(image, release string) string {
+ imageFull := "quay.io/toolbx-images/" + image
+ return imageFull
+}
+
// GetGroupForSudo returns the name of the sudoers group.
//
// Some distros call it 'sudo' (eg. Ubuntu) and some call it 'wheel' (eg. Fedora).
@@ -727,6 +746,10 @@ func parseReleaseUbuntu(release string) (string, error) {
return release, nil
}
+func parseReleaseArchLinux(release string) (string, error) {
+ return "latest", nil
+}
+
// PathExists wraps around os.Stat providing a nice interface for checking an existence of a path.
func PathExists(path string) bool {
if _, err := os.Stat(path); !os.IsNotExist(err) { |
|
Do you think we should make hosts running Arch derivates like Manjaro use the Arch images? I don't know how similar Arch and Manjaro are. Are they like Fedora/RHEL and Debian/Ubuntu, where the derived distribution might have significant changes? Or are they like RHEL and its clones? If they are sufficiently similar, then it might be worth making Manjaro hosts use the Arch image. I did create a Manjaro virtual machine, but I know too little about the Arch universe to be able to figure it out with certainty. I did notice differences like Arch using Wayland but not Manjaro, differences in GNOME versions (44 versus 43), different terminal emulation applications, different shells (Bash versus Z shell), different entries in |
It would be similar to forcing Linux Mint to use Ubuntu, or Ubuntu to use Debian. At least in the Manjaro example. |
Ok, understood!. |
|
Build succeeded. ✔️ unit-test SUCCESS in 9m 33s |
|
@debarshiray |
This is the definition of the arch-toolbox image for Arch Linux that plays well with Toolbx. Today, it's published at quay.io/toolbx-images/archlinux-toolbox:latest, but the name of the published image will be changed to arch-toolbox [1] to match the os-release(5) ID on Arch Linux. The convention of naming the Toolbx images according to the os-release(5) ID is deeply ingrained in the Toolbx code base. It will be better to keep things simple by continuing that practice, instead of adding a one-off exception. Maintenance of this image has been passed to Morten Linderud. [1] toolbx-images/images#82 #861
|
Build succeeded. ✔️ unit-test SUCCESS in 9m 10s |
|
Build succeeded. ✔️ unit-test SUCCESS in 9m 38s |
|
I merged the definition of the
The most important thing is to rename the image on the registry. Otherwise, it won't work with Other than that, issues that might need changes directly in Toolbx:
It will be good if |
I have some work-in-progress code here: #1303 It needs some more testing, test cases, and we need to wait for the image to get renamed on the registry. |
I had a quick look at this.
The issue is that the the following snippet is missing from for i in /etc/profile.d/*.sh; do
if [ -r "$i" ]; then
if [ "$PS1" ]; then
. "$i"
else
. "$i" >/dev/null
fi
fi
doneAnd quickly looking it seems this is done twice in fedore. One in https://gitlab.archlinux.org/archlinux/packaging/packages/bash/-/blob/main/system.bashrc The question is if I should poke the Arch |
|
I've set up the https://quay.io/repository/toolbx/arch-toolbox repo on Quay.io. You can mirror the GitHub Action from the Ubuntu PR to make one for this image and push to the repo. |
On my Arch Linux host, PS: I deliberately went with a login shell (ie.,
That looks like the code in Fedora's I didn't understand why it's absence in Arch's I think the problem is that the rc files are sourced after
Of course it does. These are shell start-up scripts. They have to be convoluted, non-standard and confusing. :) I have tried to straighten out bits and pieces of Bash and Z shell's start-up scripts in Fedora, but there's so much more. Let me know if you spot something.
Yes, please. I think they set Secondly, it makes sense to me to let the |
Until now, the Arch Linux image was being published at quay.io/toolbx-images/archlinux-toolbox:latest. This renames the image to arch-toolbox [1] to match the os-release(5) ID on Arch, and changes the location to quay.io/toolbx/arch-toolbox:latest. Build and push when there are changes in the 'images/arch' directory or in the GitHub workflow itself, as well as every other week (7th and 21st days of a month to be precise). [1] Commit 2568528 containers#861
Until now, the Arch Linux image was being published at quay.io/toolbx-images/archlinux-toolbox:latest. This renames the image to arch-toolbox [1] to match the os-release(5) ID on Arch, and changes the location to quay.io/toolbx/arch-toolbox:latest. Build and push when there are changes in the 'images/arch' directory or in the GitHub workflow itself, as well as every other week (7th and 21st days of a month to be precise). [1] Commit 2568528 containers#861 containers#1308
|
Until now, the Arch Linux image was being published at quay.io/toolbx-images/archlinux-toolbox:latest. This renames the image to arch-toolbox [1] to match the os-release(5) ID on Arch, and changes the location to quay.io/toolbx/arch-toolbox:latest. Build and push when there are changes in the 'images/arch' directory or in the GitHub workflow itself, as well as at 00:00 every Monday. [1] Commit 2568528 containers#861 containers#1308
|
For the prompt, I think there are two issues:
I think getting the first one solved is less of a priority as we can include documentation in the ArchWiki, while the second point should probably be fixed. |
Until now, the Arch Linux image was being published at quay.io/toolbx-images/archlinux-toolbox:latest. This renames the image to arch-toolbox [1] to match the os-release(5) ID on Arch, and changes the location to quay.io/toolbx/arch-toolbox:latest. Build and push when there are changes in the 'images/arch' directory or in the GitHub workflow itself, as well as at 00:00 every Monday. [1] Commit 2568528 containers#861 containers#1308
Until now, the Arch Linux image was being published at quay.io/toolbx-images/archlinux-toolbox:latest. This renames the image to arch-toolbox [1] to match the os-release(5) ID on Arch, and changes the location to quay.io/toolbx/arch-toolbox:latest. Build and push when there are changes in the 'images/arch' directory or in the GitHub workflow itself, as well as at 00:00 every Monday. [1] Commit 2568528 containers#861 containers#1308
The VERSION_ID field in os-release(5) is optional [1]. It's absent on Arch Linux, which follows a rolling-release model and uses the BUILD_ID field instead: BUILD_ID=rolling A subsequent commit will add built-in support for Arch Linux. Hence, the code to get the default release from the host operating system can no longer assume the presence of the VERSION_ID field in os-release(5). Note that the arch-toolbox image is tagged with 'latest', in accordance with OCI conventions, not 'rolling' [2,3], which is the os-release(5) BUILD_ID. Therefore, it will be wise to use 'latest' as the default release on Arch Linux, to simplify how the default release matches with the default image's tag. This means that a os-release(5) field can't be used for the default release on Arch. [1] https://www.freedesktop.org/software/systemd/man/os-release.html [2] Commit 2568528 containers#861 [3] Commit a4e5861 containers#1308 containers#1303
Okay. I think the common (sub-)problem across those cases is that Arch Linux's Solving this will retain the customized shell prompt inside Arch containers running on all Fedora hosts where the user didn't change the shell start-up files in It won't solve the Arch-on-Arch or Arch-on-Ubuntu cases, because both Arch and Ubuntu's default I think we should really move the discussion about customizing the shell prompt on Arch Linux somewhere else other than this merged pull request. :) |
This commit intends to add Arch Linux support to toolbox. It was built based on work from my three previous PRs (#328, #520 and #710), hopefully this one will be the last.
Compared to previous PRs I've added the
vte-commonpackage, as recommended by @xPMo, which should fix the problems mentioned in #710 and I've worked in a separate branch instead of inmainto avoid merging issues.The image is built from the upstream
archlinux:base-develtag.It includes most of the packages that the Fedora-based images do, but currently excludes
flatpak(required forflatpak-spawn), since it adds ~690 MB of extra packages/dependencies.If the final size is very important I can try and base it off of
archlinux:latest(which includes only the base packages, not also development-related ones), but that would still require adding some of the missing packages back.Another option could be to separate
latestandbase-develversions into separate images, similarly to what is done with Fedora versions.If this PR is merged into toolbox I also plan to add documentation on how to create an Arch Linux-based container and which distributions are available, since this would be the first image that is not Fedora-based (for now).