70 Replies
So realisically, we want to move all toolboxes to https://github.com/ublue-os/toolboxes
GitHub
GitHub - ublue-os/toolboxes: Centralized repository of containers d...
Centralized repository of containers designed for Toolbox/Distrobox - GitHub - ublue-os/toolboxes: Centralized repository of containers designed for Toolbox/Distrobox
I'm assuming we would want to move these: https://github.com/ublue-os/bluefin/tree/main/toolboxes
and these three:
https://github.com/ublue-os/fedora-distrobox
https://github.com/ublue-os/arch-distrobox
https://github.com/ublue-os/bazzite-arch
any that I missed? @Kyle Gospo @j0rge
Gonna create an issue to track progress on moving them.
ubuntu, and fedora in bluefin repo, we may need to consolidate the fedora ones
Oh, so we have multiple toolboxes for Fedora?
yeah mine might be based on kyle's
forgot, lol
I was just telling a colleague, the awesome part of this set up is you can move so fast with so few people, the bad part is missing docs and stuff
we do an obs-studio box in partnership with wimpy that should be in there
wait, let me rephrase
keep it in it's own repo, but we should account for it. (actions, etc.)
ok, so OBS Studio stays where it is?
I thinking this is more meant for just general toolboxes that anyone (ourselves included) can consume.
more specialized application ones may make more sense to keep in their separate repo.
yeah
the reason I mention it is if we do like, centralized actions and stuff, like I'm not sure how often it builds in relation to the others, that kind of thing
I see, might be worth discussing and getting a consensus?
We are lazy and remaking actions doesn't really align with that value 😉
yeah
I just want to make sure those boxes don't get left behind if we fix up tooling I guess is my concern. The payload not so much
understandable!
like, are we doing sig store checks on the obs one? I don't think we are but we are in bazzifin, that sort of thing.
I think the 4 bluefin ones could move more or less as is right now. The only one that is odd is that the bluefin fedora one pulls from fedora-distrobox and then calls it fedora-toolbox. So that's kinda not great
Will start looking at moving the bluefin containers.
Do we want quadlets in the new repo? I can see either way. Rootless are going to require some workarounds since we would probably have edits through as we work through quadlets.
quadlets seem fine
how do we ingest them into bluefin?
like just git clone the service units over?
A git submodule? Or just git clone during build.
The only difference between our fedora-toolbox and fedora-distrobox is .... we install vim and ripgrep.
ah
The only place we specifically call our fedora-toolbox is the distrobox.ini in bluefin-dx.
oh wow, I didn't know we were so inconsistent
I vote we get rid of our fedora-toolbox. And just add vim/ripgrep to fedora-distrobox. Or only vim. Rename the distrobox.ini and move on.
If anyone using distrobox or toolbox tries and consume the old image. They will have to run dnf update as part of setup so shouldn't be too much of a concern
I won't remove it yet. Looking for consensus. But I see no reason to keep both.
agreed
I have most of bluefin's stuff getting setup in the new repo. Need to modify stuff to handle the new names/paths. But should at least start getting the repo churning.
I want to compare the Wolfi box and our bluefin-cli. I think the end result right now is that our bluefin-cli has brew and Wolfi doesn't. Some other small differences but a lot of duplication. Most of the Wolfi packages are just what get installed when you create with distrobox.
I think distrobox implementation of bluefin-cli is fine now with using the
just bluefin-cli.
I know size is a concern for the bluefin-cli box, but I think it might get a little larger since the distrobox packages won't get pulled automatically when used via quadlet.I was talking to dustin and I think kyle would agree, we should PR wolfi into distrobox to not just install those packages. The reason it's doing so is because it thinks it's alpine and just tosses it all there.
but like we don't need a bunch of the X stuff because there are no graphical apps in there.
plus we know it's going to grow, there's too much awesome stuff out there to not grow hahahaha.
but with wolfi we can go bottom up while building, with ubuntu we tried to go top down and it's just, gah, we're not doing that it's too messy.
That makes sense.
also like 3 or 4 of us have fixes in distrobox, it's so awesome when they do a release and one of us is in there, we celebrated last time
boom, both @adamisrael and @EyeCantCU, so awesome
Have an open PR that would allow people to override the start shell too 🙂
So the logic for what gets added is simply which package manager does the container have. Attempt to install these dependencies. If we want a Wolfi specific, we would need a code path to by-pass all of that instead.
Interactive quadlets look non-trivial. For bluefin-cli distrobox sets up 317 volume mounts While a lot of them are not necessary for the cli. It is quite a bit. I'll see if there is a way to programatically get stuff.
Ack. I will likely need to look at this tomorrow. I also don't have a huge amount experience with GitHub actions, so I will need to lean on others for review as well.
No worries.
More quadlet thinking.
There multiple stages for the lifecycle of using the container.
Using distrobox as a bit of a guiding point: 1. Container setup. A. The container needs to have a corresponding user inside the container for use. Or at the very least needs to have a correctly mapped UID/GID so permissions don't get screwed up on host. B. Correct user shell. C. Volume mounts. Expectation of transparent access to home. D. Host integrations. Continuing with volume mounts we need to mount in sockets, host networking, dbus, themes, X socket. 2. Entrypoint. Quadlets get transformed into systemd units that can be enabled. What do we actually connect to. 3. Updates. Pulling new images are going to nuke things. How to minimize this as much as possible.
Using distrobox as a bit of a guiding point: 1. Container setup. A. The container needs to have a corresponding user inside the container for use. Or at the very least needs to have a correctly mapped UID/GID so permissions don't get screwed up on host. B. Correct user shell. C. Volume mounts. Expectation of transparent access to home. D. Host integrations. Continuing with volume mounts we need to mount in sockets, host networking, dbus, themes, X socket. 2. Entrypoint. Quadlets get transformed into systemd units that can be enabled. What do we actually connect to. 3. Updates. Pulling new images are going to nuke things. How to minimize this as much as possible.
Ok, so question time.
Do you think given what you've seen so far that doing that work is worth the effort?
like I think prompt calls toolbox directly right (I think @Kyle Gospo would know), would it just make sense to have bluefin-cli be a toolbox, which purposely doesn't have as many features, since we know there will never be GUI apps, etc. in there.
because toolbox doesn't install extra packages, etc, I think it just doesn't try to care and goes right into the container
I want to think a bit more on this. But quadlets might need to be generated in order to match the integration. Toolbox might actually make a ton of sense so long as I understand all the features.
Quadlets seem awesome right now for replacing docker-compose.
I also don't want to reinvent distrobox.
right
yeah for sure they created quadlets to give you compose-like convenience but right in the service unit
GitHub
bluefin/just/custom.just at 6b781fb5b2d9f0916b3fd847ce0937c7fedbf3c...
An interpretation of the Ubuntu spirit built on Fedora technology - ublue-os/bluefin
Okay looking at some of the older versions of toolbox, I think I can do some of it in a quadlet. The only thing I'm not liking is that systemd units don't have a convenience key for $XDG_DATA_HOME.
sorry that link was for @HikariKnight
mixing up my threads, that's a just thing
@j0rge when you say old Nvidia card, make sure it's 2000 series and up
Nothing prior to that is going to work well
2080
ack
So i'm able to get the entrypoint working inside a quadlet. Now working through attaching to the container
However that is as the Exec command. It needs to be the entrypoint
Apparently we have a different version of podman?
The container works. Now need to figure how to replicate distrobox-enter
but using a quadlet it creates the container. However, it ain't persistant at all right now
Prompt does not have the container as an option to select. But distrobox ls see's it
And it's now showing up in prompt.... but immediately dies when I connect to it. Probably missing something.
Distrobox enter seems to work. The container showed up after I made a toolbox container. The container is removed on exit so you have to redo the entire distrobox enter first setup each time.
@j0rge @Noel https://github.com/ublue-os/toolboxes/pull/5
quadlets and systemd oneshots for distrobox containers. I'll figure out toolbox but might be a bit more complicated. I actually like the oneshots a bit better than quadlet for distrobox since you can easily modify the ini file for additional packages and a bit of an easier pattern than the quadlet.
GitHub
feat: quadlets and systemd service files for distrobox containers b...
Adds example quadlets that uses distrobox for entrypoint.
Adds example systemd-oneshot services for creating distrobox containers along with example *.ini files.
And toolbox quadlet is working. Will add that shortly as well
ok is it time to turn off the workflows in bluefin and turn the one in toolboxes on?
that's why we're failing with the pushes
We are failing since we cannot login to ghcr I think
The images build fine (except wolfi right now due to libcap)
yeah, someone PRed a fix to that earlier
I'm just getting to the PC I can help transition us to this
I gave you the proper access on the repo
Okay. I'm bringing over the rest of the quadlets right now. So both distrobox and toolbox style for these containers. Will match systemd-oneshots for toolbox later.
Following that I'll start rounding up the rest of the individual containers we have.
feel free to just push
let's just get it done, then I'll turn on branch protection
fedora, wolfi, ubuntu, and bluefin all successfully pushed
NICE
Bluefin stuff is over. I think we are missing some credential right now for the ghcr login?
@Kyle Gospo what's the tldr on this? https://github.com/ublue-os/waydroid-distrobox
GitHub
GitHub - ublue-os/waydroid-distrobox: Fedora distrobox images with ...
Fedora distrobox images with packages required for Waydroid added OOTB - GitHub - ublue-os/waydroid-distrobox: Fedora distrobox images with packages required for Waydroid added OOTB
whereat?
things look green here
Delete
We good. I was reading something wrong
Was based on what vanilla was doing
Not a good experience at all
archived
@Kyle Gospo do you guys need to persist state in the fedora distrobox for ujust commands?
to explain the ghcr errors. In an org if a repo pushes a package, another repo can't publish that same package. So I had to manually delete the packages in ghcr.io, and then build in the new repo and then it's all green
ah
everything is green so we can turn-off the bluefin stuff and remove those from bluefin repo now.
PRed to fin already, just needs a review
https://github.com/ublue-os/bluefin/pull/814
acked
I'm going to PR building wolfi/bluefin-cli more than once a day, I'm catching up on some wolfi vids and they move very fast, so I'm thinking 4 times a day?
actually I'll start with twice
We need shadow in wolfi
@Kyle Gospo do we wanna move the arch toolbox into the toolboxes repo?
@j0rge yup
IMO we should leave bazzite-arch and the obs one in their own thing
Sure, fine by me
i will start working on the toolbox recipes on tuesday, will probably have to play around a bit with toolbox to figure out what would make sense with it
justfile cleanup @ bazzite is done now too, so that's ready for you to look at w/o having a ton of duplicates and mess
also there's a bug where kargs are wrapped by quotations that may be worth looking at
great, means i get to brush off the dust from the VM