I have a need for an Ubuntu 22 based distrobox but it’s not obvious if anything like that is available in ghcr.io/ublue-os. I tried building my own based on the the Canonical official container images but that seems to be missing some of the host-integration pieces that are in the ublue-os repo.
Is my best choice to clone that repo, change the base image, and rebuild? Then just push to my namespace on ghcr.io?
Drew
It’s probably easier to fork the boxkit repo, which is designed for “I need a toolbox for a distro”: GitHub - ublue-os/boxkit: Build your own custom OCI distrobox container
That way you don’t pull in all the other stuff in the toolbox repo. Then replace the containerfile and packages with the stuff in this directory: toolboxes/toolboxes/ubuntu-toolbox at main · ublue-os/toolboxes · GitHub
You may need to adjust the packages if something isn’t in 22.04 but I think you should be good. The boxkit repo contains all the github actions to push to ghcr.io, etc, so that should be all set up, all you need to do is generate a new keypair for signing, which is covered in the readme. That should be it!
So, adding to this thread which helped me learn.
To really spell out the typical workflow (for newbies like me), you:
podman image build -t myimage . to create the image locallytoolbox create -i myimagetoolbox enter myimageOnce happy with the result, you can commit your changes to your (forked) repo.
Hey Alex @akarypid, I commend you for spelling out this workflow! 
You mean copy paste and adapt it to your needs?
Like FROM docker.io/library/ubuntu:22.04 in this example right?
Could you expand on what you were trying to do @akarypid ?
Thanks a lot!
There are some applications I use, that do not have flatpaks. Examples are TWS and Citrix.
I would like to have a custom toolbox where they are pre-installed, and export their launchers on the host so that I can use them without layering packages on the host.
I have been able to use distrobox as well in this workflow after telling distrobox to use local images rather than always pull from repos.
Not sure if this is what you’re looking for.
distrobox-export --app APPNAME
Hey @Bambiraptor,
I’ve just uploaded the scripts that I came up with to containerize the two applications I use, for which there are no flatpaks in my box-apps repo.
this is great @akarypid ! thanks for sharing, I love to see real example of what is discussed
Agreed. I managed to get my custom Ubuntu box built and running. Thanks all for the help.
I have two open items I want to implement:
Drew
For (1) you can just go to Gnome’s settings and change the custom shortcut. I suppose if you use KDE there is a similar settings screen:
For (2), look at line 10 of my script for building distrobox. My solution was to run the export command from inside the box, after it has been created. I don’t know if there is some better way of doing this, but this worked for me. Notably, toolbox does not have a way of doing the same so I created an export-tbox.sh script, though as I write in the README.md, I’m sure that someone has a proper script for doing this (mine works with the specific application). I’ve made a note to look for something along those lines when I get some time…
I was not able to edit the ptyxis profiles due to this issue. But I was able to swap in my image by editing the /etc/containers/systemd/users/ubuntu-toolbox.container file.
As for automatically exporting, your script assumes the container image is being generated on the host you want the app exported to but I’m building on a separate Ubuntu build machine. I guess for now I’ll have to do the manual steps.
Hello! Yes indeed, but that is intentional. See my post here: Ditrobox ignores local podman image (toolbox is fine with it) - #2 by akarypid
For the application export though, it doesn’t really matter where you build your image. The export action is done from a container (not an image) to the host running that container. So you create from any image (wherever it came from), then create a container anywhere else (though that would require downloading the image to that host).
Either way, once you have a container, just use the command I referenced to enter the container and have it export the app (from the container to the host running it). It does not have to be part of the script that builds the image.
