NGitHub
Centralized repository of containers designed for Toolbox/Distrobox - GitHub - ublue-os/toolboxes: Centralized repository of containers designed for Toolbox/Distrobox
NNNany that I missed? @Kyle Gospo @j0rge
NGonna create an issue to track progress on moving them.
Jubuntu, and fedora in bluefin repo, we may need to consolidate the fedora ones
NOh, so we have multiple toolboxes for Fedora?
Jyeah mine might be based on kyle's
Jforgot, lol
NJI 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
Jwe do an obs-studio box in partnership with wimpy that should be in there
Jwait, let me rephrase
Jkeep it in it's own repo, but we should account for it. (actions, etc.)
Nok, so OBS Studio stays where it is?
NI thinking this is more meant for just general toolboxes that anyone (ourselves included) can consume.
Nmore specialized application ones may make more sense to keep in their separate repo.
Jyeah
Jthe 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
NI see, might be worth discussing and getting a consensus?
NWe are lazy and remaking actions doesn't really align with that value 
Jyeah
JI 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
Nunderstandable!
Jlike, 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.
MI 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
MWill 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.
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.
Jquadlets seem fine
Jhow do we ingest them into bluefin?
Jlike just git clone the service units over?
MA git submodule? Or just git clone during build.
The only difference between our fedora-toolbox and fedora-distrobox is .... we install vim and ripgrep.
The only difference between our fedora-toolbox and fedora-distrobox is .... we install vim and ripgrep.
Jah
MThe only place we specifically call our fedora-toolbox is the distrobox.ini in bluefin-dx.
Joh wow, I didn't know we were so inconsistent
MI 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
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
MI won't remove it yet. Looking for consensus. But I see no reason to keep both.
Jagreed
MI 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
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 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.
JI 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.
Jbut like we don't need a bunch of the X stuff because there are no graphical apps in there.
Jplus we know it's going to grow, there's too much awesome stuff out there to not grow hahahaha.
Jbut 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.
MThat makes sense.
Jalso 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
Jboom, both @adamisrael and @EyeCantCU, so awesome
EHave an open PR that would allow people to override the start shell too 
MSo 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.
M
MInteractive 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.
NAck. 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.
