Ri know
Kthis just keeps us fixed while we wait for upstream to build
RGitHub
As of rpm-ostree 2024.7, this is available: coreos/rpm-ostree#4974
IHey can you explain to me what you expect to find? I wanted to try to improve this but I am not sure what you meant. Thx.
Auh i dont remember
Awhat we need now is simple
Afind out the file that causes the crash
Ato do that, you need debug symbols
IYes I am aware of that. I will try to find time for this. The other question: Are our build tags in some form strange or confusing? I do not know how they are supposed to look.
IWe did layer the debug symbols but it did not work. I will try it again this weekend.
Aturns out github was broken when i was checking it
Aand then ghcr died after a few hours
Rwhat are you going to try? layering debuginfo packages doesn't cause them to be loaded
II did not had time to think about this. I wanted to fork the repo and include the packages in the build itself. That would be my first try
Rby layering in the build? likely will be the same
RRcan we get a rebuild across the ublue stack for this? main is rebuilt but hwe/bluefin/bazzite all have no fuse support temporarily
Ri guess a few hours of no appimages isn't the worst thing ever 
KNature is healing
RYouTubeFedora Project
As the popularity of atomic and immutable Linux distros grows, how does Fedora take things to the next level? Short answer: bootc. By learning from container...
TJust started listening; I was going to share as well.
RGitHub
coreos/rpm-ostree#4974
ublue-os/main#632
ublue-os/main#632
J@yukidream lol your snap question on the fedora podcast, hahaha
NGonna listen as soon as I can 
Dtbh i want snap support on Fedora Atomic for stuff that is not available on homebrew like unsandboxed GUI apps
Ryou can always use
bubblejailR@Kyle Gospo I wonder if the rpm-ostreed.conf is ignored because rpm-ostreed needs to be restarted?
Rto pick up the change?
Rnvm, no wonder it's ignored:
N@Kyle Gospo @antheas thinking about this a bit more, @imbev made this project which might be useful for pre installing Flatpaks that we wouldn't want the user to remove potentially? Stuff gnome apps, KDE apps, etc.?
N
NThat way, at least if you rebase, you have a base set of software that is included in the image?
NNot sure how this would interact with rechunk however.
KI think that would also mean the flatpaks update with the system
KFor security reasons I definitely don't want to do that
KEither that, or they exist in the read only part and also in a readable part, meaning it takes up double the space that does now
KRather just let them uninstall stuff
J@Noel if you have the capacity to ask around to see if owen taylor's plan for /etc/preinstall for flatpaks is still the plan that would be useful. There's an upstream issue in flatpak for it.
Ai mean rechunk just repackages the image as an ostree commit
Aflatpaks are something we can revisit now that rechunk can handle partitioning big applications
Aonce i receive the ally x i plan to work on a dx bazzite image, at the beginning for personal use
Acertain flatpaks might make sense to package in the image, e.g., filelight and calculator
JLooks like bootupd, bootc, and dnf are going to be included in F41 atomic spins https://fedoraproject.org/wiki/Changes/DNFAndBootcInImageModeFedora https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd
R@j0rge @Kyle Gospo should we just go ahead with https://github.com/ublue-os/config/pull/316 ?
it at least helps with these cases https://github.com/ublue-os/main/issues/632#issuecomment-2302192396
it at least helps with these cases https://github.com/ublue-os/main/issues/632#issuecomment-2302192396
Kyes, I think it's good for the end-user
Rcool, I just need one more approval then
I'll leave the issue open though since it's only partially resolved
I'll leave the issue open though since it's only partially resolved
RAre there any plans for a rawhide or testing branch for aurora/bluefin?
Twas attempted for ublue's main images long ago
Twas not worth maintaining
Ttoo many issues and headaches
