Everyone running bluefin getting the open in prompt nautilus thingy?
Everyone running bluefin getting the open in prompt nautilus thingy?
Kyea
KBazzite as well
Kit also takes over as the default terminal so bash scripts you launch will open in prompt and so on
KWanted to brainstorm this at some point -- kernel signing
KI wonder if it would be possible to sign kernels w/ our akmods key post-install
Kthrough github
EI'd imagine it should be
Athen the users would need to have a private key no?
Kyeah, though most already do since the akmod key is needed for Nvidia & numerous features @ bazzite
Kwe've also been warning people w/ a profile script that don't have the key, nagging them to enroll it
Kso if we could re-use that key as a kernel signing key we could put what's on
:testing:latestWe don’t ship the private key though no?
AWe shipped signed kmods and a public key
Kright, anything with the private key would need to be done in github
Kon our side
AWhat do you wanna sign post-install? 
Knot post-install, during OCI build post-kernel-install
Kand the kernel
Ksurface-kernel is signed with their own key, kernel-fsync isn't signed
Kand I think asus-linux isn't signed
Ksigning all of them with our key would be a great improvement
AOh okay makes sense
BI can't install SDDM themes, I get a could not decompress error message. However, I am able to change in case something is already installed
Kyou can install them manually
Kproblem is the store tries to install them to system dirs
Kwhich are read only
BYep, I have installed all the others manually after much searching and finally realising I am on an immutable OS!
FLatest is currently F39, but it will be F40 when F40 gets officially released
39 stays on 39 forever
39 stays on 39 forever
F@HikariKnight I remember you saying that you fiddle a lot with configs and some things with VM's which modify the OS.
What do you think about my proposal?
https://github.com/ublue-os/config/issues/171
What do you think about my proposal?
https://github.com/ublue-os/config/issues/171
GitHub
Why It is useful for tracking modifications you did on top of the OS you may want to revert in the future. It is also useful for troubleshooting issues from the affected users. Example I want to hi...
Hi think its a good idea if implemented well as it would help with cleaning up the just files too indirectly where we can replace the "enable" "remove" "add" and "disable" commands with toggles
https://github.com/ublue-os/config/issues/148
i havent gotten to start looking at that even yet as i will need to sit down, draft something and suggest it first (unless someone beats me to it
)
my mother has needed some extra help unexpectedly so i had my hands more full than i expected this month so far.
https://github.com/ublue-os/config/issues/148
i havent gotten to start looking at that even yet as i will need to sit down, draft something and suggest it first (unless someone beats me to it
)my mother has needed some extra help unexpectedly so i had my hands more full than i expected this month so far.
GitHub
I see at least three styles of enable/disable scripts in just --list: disable-updates ⬌ enable-updates disable-broadcom-wl ⬌ use-broadcom-wl use-stock-gamepads ⬌ use-ublue-gamepads Worth standardiz...
FYeah, this issue is also something I kept in mind, but I think it is hard to solve.
Some commands are enabling/disabling, some commands are installing/uninstalling, some commands are copying/removing etc.
But maybe there is a solution we missed
Some commands are enabling/disabling, some commands are installing/uninstalling, some commands are copying/removing etc.
But maybe there is a solution we missed
Hmost likely, i am still getting used to everything
FMaybe using something like gum is the solution. Gum is used for VRR toggle on Bluefin, so there is some hope
Hhuh never heard of gum and here i am literally making my own version inside golang for my other project 
ELike
history | grep just?
Hi think they mean more of what commands have actually been run and which of the just commands are actually active, kind of like
ESo more for checking the state. There'd need to be separation between scripts ran as a user and by the system but it's doable
Hthats what i gathered, which would help in cleaning up and reorging the just files
MThat would be helpful to easily get the status.
Hheck a cool thing it would let us do is even make a template to just 
well it would be cool for things that can do it without needing to do extra steps after a reboot
ujust set-states "file.conf" and it would just apply all the selected states well it would be cool for things that can do it without needing to do extra steps after a rebootMyou could ship a set-states default, source it, and then iterate through. The ujust commands are mostly bash scripts now.
AIt sounds like reinventing configuration management
Bcheckout "huh" too, if you're looking for a similar thing in Go by the same people.
Hthe funny thing is that i did try to use bubbletea for my project but it was way overkill for what i needed
Byeah same. that's why huh is nice. all the bubbletea bits are wrapped nicely out of the way.
Hstarting to get tired of rewriting the tui at this point, gone from pure bash to golang with bubbletea to my own choice dialogs and now youre saying i didnt need to do that
Hhaha
BI feel your pain. I've rewritten blincus in go, go + web, wails, and now bash.
Hhttps://github.com/HikariKnight/quickpassthrough/tree/dev
thats what i have been working on when i had the time
thats what i have been working on when i had the time
GitHub
A project to remove the complexity of setting up GPU passthrough for qemu - GitHub - HikariKnight/quickpassthrough at dev
