EOh wow. This is nicer. Just need to extract the zip and copy to /usr/blah where system extensions are
EAnd no problem. Happy to help with anything
JYeah in theory it should streamline the build as there's be no need for NPM
JAlthough I still wonder what to do about these build failures
JAt this point the image is just providing the extension so that a user doesn't have to manually install it into their homedir
Jdo we copr that one?
JWhich would also help avoid potential extension since we'd ensure that only a compatible extension version is used for each image
J
VIs there an issue with the fedora 39 ublue nvidia variant? It seems like there's a package resolution issue ongoing with it.
EThere's an issue right now with RPM Fusion and builds but it shouldn't impact user installations
VWell my custom image is refusing to update due to an issue with the kernel 6.6.4, it might be unrelated but I came to check just in case.
JWhat does the package resolution ouput look like?
VOne sec
V
JWhat packages are you layering?
J--> #
custom-image-support is for custom image stuff
custom-image-support is for custom image stuffVAlright, heading over there
CMade a lot of progress on the image switcher app. Nearly all logic is implemented. I'll need assistance running commands from a Flatpak and refining the UI a little bit, but I do not expect those aspects to be particularly difficult
CThe UI definition could be condensed by a factor of 5-10 by converting the raw XML to Python declarations, I just happened to figure out the XML first. It is currently 240 lines
CThe app itself is 16 lines of code, not counting the template code/files provided by Gnome Builder
Rdoes anyone know what happened to silverblue updates? 
https://github.com/fedora-silverblue/issue-tracker/issues/516
https://github.com/fedora-silverblue/issue-tracker/issues/516GitHub
The composes seem to be finishing correctly, but rpm-ostree upgrade isn't finding them. Notably, this means the fix for containers/podman#20872 hasn't gone out yet. https://kojipkgs.fedorap...
ZI had an update just yesterday
JThe fix is in the images for ublue sinxe that bases from something else iirc
JCould be something specific missing in the pipelines of SB themselves, not accounting for new stuff in ostree. Either way didn't affect ublue builds at all
Joof dang that sucks
Ryeah time to switch image to quay
Rinstead of the old walters github actions
E@jstone sorry for the delay there - GNOME shell extension was updated
JThank you!
ENo problem
J4,002,014 pulls!
EWasn't it 2 like a month ago?
C@EyeCantCU
C9 days, 450k
EWowza
C50k per day, many people have more than one machine, some don't auto update, etc... I'd guess roughly 30-40,000 people
JIs there a graph we could use to track numbers and correlate with press coverage?
JJall our historical data is there, just need to graph it
J@αchilleaς Putting this convo on your radar! https://universal-blue.discourse.group/t/what-is-universal-blue-doing-that-you-would-like-the-fedora-project-to-do-instead/218/5
Universal Blue
Thanks for these notes! Good to have a clear view on where Fedora can help. That sounds like a great idea! I think the closest conversation so this idea has been the topic of removing Firefox from the atomic spins because so many people end up wanting the Flathub Firefox anyway. If folks are willing to drop the browser, I think there may be lo...
E@KyleGospo I feel like this is almost right. I've got to get off my computer for the night unfortunately
I had considered building it from source but their CI already does that. Plus releases would have to be pinned regardless. So I took the source tarball and tried to package it that way. The problem being auto setup tries to enter a directory that doesn't exist.
Spec is here:
https://github.com/EyeCantCU/devpod/blob/main/devpod.spec
Feel free to use it or completely repackage it in a way that makes more sense. I figured I'd try it since I said I would. Completely spaced on it until I saw it mentioned
Copr here:
https://copr.fedorainfracloud.org/coprs/eyecantcu/DevPod/
I had considered building it from source but their CI already does that. Plus releases would have to be pinned regardless. So I took the source tarball and tried to package it that way. The problem being auto setup tries to enter a directory that doesn't exist.
Spec is here:
https://github.com/EyeCantCU/devpod/blob/main/devpod.spec
Feel free to use it or completely repackage it in a way that makes more sense. I figured I'd try it since I said I would. Completely spaced on it until I saw it mentioned
Copr here:
https://copr.fedorainfracloud.org/coprs/eyecantcu/DevPod/
AYou can pass some arguments to customize what %auto setup does
ΑThanks. Things have gotten a bit hectic recently and priorities are shifting, but there's cool stuff coming.
EYeah. Read up on them last night. None of them tell it to remain in the current directory. Will tackle it this morning
AYou could try something wild like
%autosetup -n .AOr maybe
%autosetup -c mmEI'll give it a go. Thank you!
EThat worked! But ack:
error: Checkout devpod-v0.4.2-1.fc39.x86_64: Hardlinking 15/10c2874e5e606e06544cf0cf70d0645b4e51226bb78e4649b9a59243adc189.file to xdg-open: File existsEExtracted the last RPM built for DevPod and it excludes the xdg-open binary as well as the glib-2.0 schemes... Will exclude those in the spec
EOkay, building again. I think this is it!
