You can pass some arguments to customize what %auto setup does
You 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 .Or maybe
%autosetup -cI'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!
Erpm-ostree install https://download.copr.fedorainfracloud.org/results/eyecantcu/DevPod/fedora-39-x86_64/06741455-devpod/devpod-v0.4.2-1.fc39.x86_64.rpmEWorks perfectly. Again, unsure if this is how we should package it though
AI can review your spec
AMaybe we should file an issue to ask why glib and xdg-open are in the release tarball
AThat doesn’t seem right at all
EThat would be great
EI'll look around first then file just to be sure. I extracted the last RPM published (one of the 0.4.0 alphas) and they weren't there. Seems off
ATry extracting the tarball manually
AMaybe it’s just tarball being messed up
EI have - they're in the tarball :/
ASounds like a bug
AGitHub
Codespaces but open-source, client-only and unopinionated: Works with any IDE and lets you use any cloud, kubernetes or just localhost docker. - loft-sh/devpod
EI'll open a PR that adds them as excludes
AGreat work 
EI appreciate the help with this. Thank you so much. I wouldn't have thought to do that otherwise
EPR opened
AGlad to help 
Kgreat work you guys, this is excellent
EThank you! PR was just merged too
J
Jyou made the prerelease notes!
J
Jhuh, check this out
LThis might be what I need! 
Jyeah I think @EyeCantCU would wanna see it too
APutting the flatpak installation inside the image means that those applications cannot be removed nor updated
LThat's OK, it's a purpose built image.
I'd use a general image otherwise
I'd use a general image otherwise
EThat's awesome!
EI'll definitely have to take a look at this. Might be the solution we need. Lots of good stuff going down today
LAyy! It worked. Got pre-installed Flatpak applications without post-installation downloading
JDo they just update on first boot?
JAnd did it pull in the runtime?
JAlso I'm sure someone would be interested in centos stream builds 
LI think they’ll update when the image updates, will take an explore!
EWill try this out here in a bit in Bazzite :unstable
JThat's probably more reliable than the first boot systemd service but the tradeoff is size of the iso
EI have an idea though. Create a new tag. Call it release, include the Flatpaks in this tag, use the tag as the default in the installer, then post install you get rebased to latest without the Flatpaks built into the image. They should still be a part of the system
ETag would only get refreshed when release please triggers ISO generation
EI think it's possible at least
EDoesn't work around fighting GHCR for space though
EBut does work around large updates
