Could I get another approval for this PR please: https://github.com/ublue-os/packages/pull/364 π
GitHub
The systemd unit and tmpfiles.d configuration is pulled from Aurora. We can consolidate this package for both Aurora and Bluefin.
RI'm a bit confused by this. Why not install libvirt as part of this? It kind of makes it confusing to manage since the configurations and package installation are in completely different places
Nyou got it boss
BSo this means the spec should require libvirt and be renamed to be libvirt specific not just βdx-servicesβ. Right?
RI guess. It only contains libvirt workarounds, so it could be ublue-os-libvirt to install (via Requires) the package and workarounds
JJ@Zeglius we'd need this for bazzite and aurora too
IPropably needed for all
Jyeah I just wanted concensus before we copy and blast.
Jor we could centralize it somewhere
ZMain?
JI was thinking in a package?
J<-- lol kill me
Jlike in one of the centralized packages the aurorafinzitte uses
Z:glorp:
ZWhat happened to you. You were cooler than this
JI know
Jhold me
ZBesides it is just a file
ZI refuse to add an rpm just for that
JI was thinking collectively for all the things we have per image.
Jlike there's a PR for a dx services rpm right now
B@ledif why did this get merged when we were literally in the middle of discussion changes to it?
Bit (the docker nat thing) could fit in the PR which just got merged ( https://github.com/ublue-os/packages/pull/364 ) if its not going to require libvirt
JI think I have that on dx?
JI am unsure if libvirt needs to be on the host these days with the virt-manager flatpak being a thing?
Bvirt-manager is just a UI to libvirt
BI think we may want to revert this... I don't know if this is adequate concensus for Bluefin as it seems to have been just Aurora approval
Bor, nevermind, since it's a new RPM it's not going to impact Bluefin without being explictly included
LYeah, it's just a new package that isn't being included by anything right now. I'm happy to rename it to be more libvirt focused or change it to whatever makes sense
R"dx-services" name suggests it's used to install everything on DX - Docker, libvirt, vscode etc. Making the "dx" images pretty much
This is only libvirt-workarounds, so IMO it should either be named "ublue-os-libvirt-workarounds" or manage the installation of libvirt itself
dnf install ublue-os-dx-servicesThis is only libvirt-workarounds, so IMO it should either be named "ublue-os-libvirt-workarounds" or manage the installation of libvirt itself
Lublue-os-libvirt-workarounds makes sense to me, I'll put up a new PR to rename itR@bsherman Do you have any thoughts?
L
BI agree with the name change.
Iβm indifferent on Requires libvirt vs the current Supplements.
Iβm indifferent on Requires libvirt vs the current Supplements.
οΏ½(nevermind moved to #
custom-image-support )
custom-image-support )οΏ½maybe this would be better suited in #custom-image-support sorry
custom-image-support sorry
Ewhat's
With the preference to use containers over pets it feels kinda odd to be there, unless it's just an example.
distrobox/app.ini for in packages repo?With the preference to use containers over pets it feels kinda odd to be there, unless it's just an example.
KIt's the opposite of pets
KIt's a container definition you can recreate any time you want in one command
EI think I get it now. Building out "custom" containers without needing to run through the whole container build process. Is that it?
Jyeah if you want say, an ubuntu container but it always installs emacs, you'd add it to distrobox.ini
Jso when you blow it away and recreate it you don't need to go in and manually install stuff
Twhenever you have a setup that works for you, use boxkit and make it effectively instant to instantiate
Tsince the image w/ ur things will be cached
Eso then the
app.ini just takes this one setup further by setting up init services. Could be done in distrobox.ini but it's just separated for cleanlinessEok, I might just be dumb. I completely misunderstood what distrobox was actually for. I kept viewing it as a "pet base" tooling, forgetting that it can be used to speed up the creation of container based "toolsets" that need to tightly integrate with the host.
Thanks for the help in realizing this!
Thanks for the help in realizing this!
ZZSo how does one open an issue to update a dependency in fedora repos?
ZT@M2 @Robert (p5) @bsherman do you guys know where is the secureboot key stored on
/usr? that one we enroll during installation on the anaconda ISOs