images: Add Arch Linux image #861

erazemk · 2021-08-11T12:59:38Z

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-common package, as recommended by @xPMo, which should fix the problems mentioned in #710 and I've worked in a separate branch instead of in main to avoid merging issues.

The image is built from the upstream archlinux:base-devel tag.

It includes most of the packages that the Fedora-based images do, but currently excludes flatpak (required for flatpak-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 latest and base-devel versions 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).

softwarefactory-project-zuul · 2021-08-11T13:19:28Z

Build failed.

unit-test : SUCCESS in 3m 14s
system-test-fedora-33 : SUCCESS in 11m 41s
system-test-fedora-34 : SUCCESS in 10m 34s
system-test-fedora-rawhide : RETRY_LIMIT in 5m 45s

Foxboron · 2021-08-17T13:58:05Z

Needs flatpak-xdg-utils for toolbox support inside the container. I'm not super clear why packages like mlocate is installed though?

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.

erazemk · 2021-08-17T14:05:02Z

I'm not super clear why packages like mlocate is installed though?

I added mlocate and others to have a similar set of packages to official Fedora versions. If you think some of them aren't needed, please tell me which ones and I'll gladly remove them to make the image smaller.

Edit: I'll remove mlocate together with the other packages to reduce clutter, so I'll wait for your response before pushing the commit.

Foxboron · 2021-08-17T14:13:56Z

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 :)

It includes most of the packages that the Fedora-based images do, but currently excludes flatpak (required for flatpak-spawn), since it adds ~690 MB of extra packages/dependencies.

Just to clarify, flatpak never provided flatpak-spawn. It's provided by a separate project which I packaged as flatpak-xdg-utils recently.

erazemk · 2021-08-17T14:17:59Z

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 :)

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.

It includes most of the packages that the Fedora-based images do, but currently excludes flatpak (required for flatpak-spawn), since it adds ~690 MB of extra packages/dependencies.

Just to clarify, flatpak never provided flatpak-spawn. It's provided by a separate project which I packaged as flatpak-xdg-utils recently.

That's great, not needing flatpak installed inside the container reduces the image size significantly.

softwarefactory-project-zuul · 2021-08-17T14:21:58Z

Build failed.

unit-test : SUCCESS in 2m 43s
system-test-fedora-33 : SUCCESS in 8m 17s
system-test-fedora-34 : SUCCESS in 8m 33s
system-test-fedora-rawhide : FAILURE in 8m 23s

softwarefactory-project-zuul · 2021-08-20T16:30:54Z

Build failed.

unit-test : SUCCESS in 4m 01s
system-test-fedora-33 : SUCCESS in 8m 35s
system-test-fedora-34 : SUCCESS in 11m 10s
system-test-fedora-rawhide : FAILURE in 10m 47s

anthr76 · 2021-08-21T14:14:42Z

Are man pages working in here? I have a similar image and doesn't seem like so..

Foxboron · 2021-08-21T14:16:39Z

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

images/archlinux/Containerfile

erazemk · 2021-08-21T14:20:48Z

We explicitly remove all the man pages and a lot of fluff such as translations, locales to keep the image size down

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.

anthr76 · 2021-08-21T14:28:44Z

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

sudo pacman -S $(sudo pacman -Qq $(sudo pacman -Fq /usr/share/man/ | cut -d/ -f2) 2> /dev/null)

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

erazemk · 2021-08-21T14:30:37Z

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?

softwarefactory-project-zuul · 2021-08-21T14:39:42Z

Build failed.

unit-test : SUCCESS in 2m 52s
system-test-fedora-33 : SUCCESS in 10m 39s
system-test-fedora-34 : SUCCESS in 11m 00s
system-test-fedora-rawhide : FAILURE in 8m 12s

anthr76 · 2021-08-29T15:04:10Z

A little side note, Arch's glibc is out of date so being blocked by:

https://archlinux.org/packages/core/x86_64/glibc/ || #821

juhp · 2021-09-10T01:40:09Z

Just for reference/FYI: https://github.com/toolbox-images/toolbox-images/tree/main/images/arch

erazemk · 2021-09-17T13:04:43Z

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.

Foxboron · 2021-09-17T13:07:23Z

That container is a "hack" and doesn't conform to the toolbox specification defined in this repo.

anthr76 · 2021-09-17T15:16:16Z

+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.

juhp · 2021-09-18T03:21:46Z

BTW mlocate does work in the fedora toolboxes now.

erazemk · 2021-10-05T18:49:55Z

@HarryMichal are you interested in including the Arch image in toolbox? The PR is complete, there are no more changes planned for now.

juhp · 2021-10-06T06:05:09Z

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.

I think because of bind mounting /usr/bin/toolbox which is linked to glibc-2.34 in Rawhide and F35.

softwarefactory-project-zuul · 2021-10-21T13:15:05Z

Build succeeded.

unit-test : SUCCESS in 3m 05s
system-test-fedora-33 : SUCCESS in 10m 07s
system-test-fedora-34 : SUCCESS in 13m 15s
system-test-fedora-rawhide : SUCCESS in 8m 55s

MinmoTech · 2021-11-09T18:21:13Z

Could this be merged then? :)

anthr76 · 2021-12-01T14:53:09Z

For the folks that been testing a similar Arch toolbox has xdg-open been working correctly?

TheEvilSkeleton · 2021-12-01T18:19:40Z

No.

anthr76 · 2021-12-01T21:07:04Z

Right, flatpak-spawn proplely works but not xdg-open we might need to communicate some package tweaks to Arch packagers to get that working.

juhp · 2021-12-03T15:19:27Z

Well, xdg-open doesn't work for fedora-toolbox either, unless you mean something different.
I use flatpak-spawn --host xdg-open ... as a workaround.

anthr76 · 2021-12-21T19:10:01Z

#568 I'm now facing this. Anyone else? Is there a good community on matrix to talk about and squash these things?

debarshiray · 2023-05-22T11:13:14Z

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.

It would be similar to forcing Linux Mint to use Ubuntu, or Ubuntu to use Debian. At least in the Manjaro example.

Ok, understood!.

images/archlinux/Containerfile

softwarefactory-project-zuul · 2023-05-22T19:51:21Z

Build succeeded.
https://softwarefactory-project.io/zuul/t/local/buildset/382e93815e794f01a2918cd4594ac325

✔️ unit-test SUCCESS in 9m 33s
✔️ unit-test-migration-path-for-coreos-toolbox SUCCESS in 3m 06s
✔️ unit-test-restricted SUCCESS in 8m 33s
✔️ system-test-fedora-rawhide SUCCESS in 20m 30s
✔️ system-test-fedora-38 SUCCESS in 20m 13s
✔️ system-test-fedora-37 SUCCESS in 20m 15s
✔️ system-test-fedora-36 SUCCESS in 19m 53s

Foxboron · 2023-06-06T13:37:27Z

@debarshiray
Fwiw, with the email thread and the issues I have lost a bit of track what needs to be done to merge this. Please be explicit if you need me to look into anything :)

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

softwarefactory-project-zuul · 2023-06-06T21:01:04Z

Build succeeded.
https://softwarefactory-project.io/zuul/t/local/buildset/494d89f322f44e19acca3a0041280f64

✔️ unit-test SUCCESS in 9m 10s
✔️ unit-test-migration-path-for-coreos-toolbox SUCCESS in 2m 46s
✔️ unit-test-restricted SUCCESS in 8m 33s
✔️ system-test-fedora-rawhide SUCCESS in 20m 19s
✔️ system-test-fedora-38 SUCCESS in 19m 27s
✔️ system-test-fedora-37 SUCCESS in 19m 35s
✔️ system-test-fedora-36 SUCCESS in 19m 08s

softwarefactory-project-zuul · 2023-06-06T21:25:51Z

Build succeeded.
https://softwarefactory-project.io/zuul/t/local/buildset/12307d0fccfa4cd5bd55570102ffd5f9

✔️ unit-test SUCCESS in 9m 38s
✔️ unit-test-migration-path-for-coreos-toolbox SUCCESS in 2m 48s
✔️ unit-test-restricted SUCCESS in 8m 34s
✔️ system-test-fedora-rawhide SUCCESS in 20m 15s
✔️ system-test-fedora-38 SUCCESS in 19m 15s
✔️ system-test-fedora-37 SUCCESS in 18m 52s
✔️ system-test-fedora-36 SUCCESS in 19m 28s

debarshiray · 2023-06-06T22:08:21Z

I merged the definition of the arch-toolbox image. Let's figure out how to wire it to --distro in a different pull request. This one has gone on for too long already. :)

@debarshiray Fwiw, with the email thread and the issues I have lost a bit of track what needs to be done to merge this. Please be explicit if you need me to look into anything :)

The most important thing is to rename the image on the registry. Otherwise, it won't work with --distro.

Other than that, issues that might need changes directly in Toolbx:

Figure out how to customize the shell prompt inside a Toolbx container on Arch Linux. This is due to the order in which the default Arch Linux host prompt is set by the Bash start-up scripts, specifically ~/.bashrc. I am open to ideas on how to address this one.
Extending the welcome to Toolbox banner to include pacman(8), just like DNF. This is easy.
Figure out how to make locales other than C, C.UTF-8 and POSIX available inside the Toolbx container for Arch. I might already have a solution for it. See Arch images errors with manpath: can't set the locale; make sure $LC_* and $LANG are correct (but run anyway) toolbx-images/images#76

It will be good if /etc/localtime can be changed into a relative symbolic link on Arch Linux hosts. However, that doesn't need changes in Toolbx and isn't causing any immediate problems today. It's something for the Arch distribution.

debarshiray · 2023-06-07T16:21:06Z

Let's figure out how to wire it to --distro in a different pull request.

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.

Foxboron · 2023-06-07T21:54:53Z

Figure out how to customize the shell prompt inside a Toolbx container on Arch Linux. This is due to the order in which the default Arch Linux host prompt is set by the Bash start-up scripts, specifically ~/.bashrc. I am open to ideas on how to address this one.

I had a quick look at this.

~/.bashrc doesn't actually play into it since toolbox is running with bash -l.

The issue is that the the following snippet is missing from /etc/bash.bashrc.

for i in /etc/profile.d/*.sh; do
    if [ -r "$i" ]; then
        if [ "$PS1" ]; then
            . "$i"
        else
            . "$i" >/dev/null
        fi
    fi
done

And quickly looking it seems this is done twice in fedore. One in /etc/profile and once in /etc/bashrc. Meanwhile Arch has a simpler /etc/bash.bashrc file which does not do this and unconditionally set PS1.

https://gitlab.archlinux.org/archlinux/packaging/packages/bash/-/blob/main/system.bashrc

The question is if I should poke the Arch bash maintainers to figure out why we overwrite $PS1?

travier · 2023-06-08T08:46:36Z

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.

debarshiray · 2023-06-08T17:04:09Z

Figure out how to customize the shell prompt inside a Toolbx container on Arch Linux. This is due to the order in which the default Arch Linux host prompt is set by the Bash start-up scripts, specifically ~/.bashrc. I am open to ideas on how to address this one.

I had a quick look at this.

~/.bashrc doesn't actually play into it since toolbox is running with bash -l.

On my Arch Linux host, ~/.bash_profile sources ~/.bashrc, and /etc/profile sources /etc/bash.bashrc. Both the rc files set PS1 to the same '[\u@\h \W]\$ '.

PS: I deliberately went with a login shell (ie., bash -l) to ensure that all the different shell start-up scripts get read. I remember GNOME Terminal faced problems because Ubuntu's non-login shells would skip some start-up scripts, which led to weird loss in functionality or bugs.

The issue is that the the following snippet is missing from /etc/bash.bashrc.

for i in /etc/profile.d/*.sh; do
    if [ -r "$i" ]; then
        if [ "$PS1" ]; then
            . "$i"
        else
            . "$i" >/dev/null
        fi
    fi
done

That looks like the code in Fedora's /etc/profile. :)

I didn't understand why it's absence in Arch's /etc/bash.bashrc would matter. Arch's /etc/profile already reads /etc/profile.d and sources /etc/bash.bashrc. So that's enough, isn't it?

I think the problem is that the rc files are sourced after /etc/profile.d and since they both set PS1, Toolbx's customization gets overridden.

And quickly looking it seems this is done twice in fedore. One in /etc/profile and once in /etc/bashrc.

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.

Meanwhile Arch has a simpler /etc/bash.bashrc file which does not do this and unconditionally set PS1.

https://gitlab.archlinux.org/archlinux/packaging/packages/bash/-/blob/main/system.bashrc

The question is if I should poke the Arch bash maintainers to figure out why we overwrite $PS1?

Yes, please.

I think they set PS1 in ~/.bashrc just as a way to demonstrate to the user how they can easily change their primary prompt. However, that could also be done by leaving it in as a comment.

Secondly, it makes sense to me to let the /etc/profile.d snippets overwrite the PS1 set by /etc/bash.bashrc

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

debarshiray · 2023-06-08T17:58:30Z

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.

Thanks, @travier ! Done: #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

Foxboron · 2023-06-09T10:46:13Z

For the prompt, I think there are two issues:

How to show the prompt on Arch hosts
How to show the prompt on non-Arch hosts.

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

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

debarshiray · 2023-06-12T18:13:01Z

Let's figure out how to wire it to --distro in a different pull request.

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.

This should wrap up the --distro wiring: #1311

debarshiray · 2023-06-12T18:31:26Z

For the prompt, I think there are two issues
1. How to show the prompt on Arch hosts

2. How to show the prompt on non-Arch hosts.
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.

Okay.

I think the common (sub-)problem across those cases is that Arch Linux's /etc/bash.bashrc is sourced after /etc/profile.d. Since /etc/bash.bashrc sets PS1, Toolbx's customization in /etc/profile.d gets overridden.

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 $HOME to set PS1. This is because Fedora's default ~/.bash_profile and ~/.bashrc don't set PS1. Only /etc/bashrc sets PS1 (to the default) on Fedora.

It won't solve the Arch-on-Arch or Arch-on-Ubuntu cases, because both Arch and Ubuntu's default ~/.bashrc sets PS1.

I think we should really move the discussion about customizing the shell prompt on Arch Linux somewhere else other than this merged pull request. :)

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 run the CI on 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. A similar change was made to toolbox(1) in commits 2ee82af and d14fd7b. [1] https://www.freedesktop.org/software/systemd/man/os-release.html [2] Commit 2568528 containers@2568528cb7f52663 containers#861 [3] Commit a4e5861 containers@a4e5861ae5c93625 containers#1308 containers#1438

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 run the CI on 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. A similar change was made to toolbox(1) in commits 2ee82af and d14fd7b. [1] https://www.freedesktop.org/software/systemd/man/os-release.html [2] Commit 2568528 containers@2568528cb7f52663 containers#861 [3] Commit a4e5861 containers@a4e5861ae5c93625 containers#1308 containers#1438 containers#1535

erazemk mentioned this pull request Aug 11, 2021

Toolbox - any linux distro inside. #789

Closed

Foxboron reviewed Aug 21, 2021

View reviewed changes

images/archlinux/Containerfile Outdated Show resolved Hide resolved

debarshiray requested changes May 22, 2023

View reviewed changes

images/archlinux/Containerfile Outdated Show resolved Hide resolved

debarshiray mentioned this pull request Jun 2, 2023

Arch images errors with manpath: can't set the locale; make sure $LC_* and $LANG are correct (but run anyway) toolbx-images/images#76

Closed

debarshiray mentioned this pull request Jun 6, 2023

Withdraw the Arch Linux image (renamed) toolbx-images/images#82

Merged

debarshiray merged commit 2568528 into containers:main Jun 6, 2023

debarshiray mentioned this pull request Jun 8, 2023

.github/workflows: Publish the Arch Linux image at quay.io/toolbx/... #1308

Merged

images: Add Arch Linux image #861

images: Add Arch Linux image #861

Conversation

erazemk commented Aug 11, 2021

softwarefactory-project-zuul bot commented Aug 11, 2021

Foxboron commented Aug 17, 2021 • edited Loading

erazemk commented Aug 17, 2021 • edited Loading

Foxboron commented Aug 17, 2021 • edited Loading

erazemk commented Aug 17, 2021

softwarefactory-project-zuul bot commented Aug 17, 2021

softwarefactory-project-zuul bot commented Aug 20, 2021

anthr76 commented Aug 21, 2021

Foxboron commented Aug 21, 2021

erazemk commented Aug 21, 2021

anthr76 commented Aug 21, 2021

erazemk commented Aug 21, 2021

softwarefactory-project-zuul bot commented Aug 21, 2021

anthr76 commented Aug 29, 2021

juhp commented Sep 10, 2021

erazemk commented Sep 17, 2021

Foxboron commented Sep 17, 2021

anthr76 commented Sep 17, 2021

juhp commented Sep 18, 2021

erazemk commented Oct 5, 2021

juhp commented Oct 6, 2021

softwarefactory-project-zuul bot commented Oct 21, 2021

MinmoTech commented Nov 9, 2021

anthr76 commented Dec 1, 2021

TheEvilSkeleton commented Dec 1, 2021

anthr76 commented Dec 1, 2021

juhp commented Dec 3, 2021

anthr76 commented Dec 21, 2021

debarshiray commented May 22, 2023

softwarefactory-project-zuul bot commented May 22, 2023

Foxboron commented Jun 6, 2023

softwarefactory-project-zuul bot commented Jun 6, 2023

softwarefactory-project-zuul bot commented Jun 6, 2023

debarshiray commented Jun 6, 2023

debarshiray commented Jun 7, 2023

Foxboron commented Jun 7, 2023 • edited Loading

travier commented Jun 8, 2023

debarshiray commented Jun 8, 2023

debarshiray commented Jun 8, 2023

Foxboron commented Jun 9, 2023

debarshiray commented Jun 12, 2023

debarshiray commented Jun 12, 2023 • edited Loading

Foxboron commented Aug 17, 2021 •

edited

Loading

erazemk commented Aug 17, 2021 •

edited

Loading

Foxboron commented Aug 17, 2021 •

edited

Loading

Foxboron commented Jun 7, 2023 •

edited

Loading

debarshiray commented Jun 12, 2023 •

edited

Loading