35 Replies
rpm-md repo 'updates-archive' (cached); generated: 2024-03-28T01:49:15Z solvables: 37996
error: No matches for 'vte-profile' in repo 'copr:copr.fedorainfracloud.org:kylegospo:prompt' in the container buildGitHub
chore: fix build issues related to tuned-ppd (#1070) Ā· ublue-os/blu...
An interpretation of the Ubuntu spirit built on Fedora technology - chore: fix build issues related to tuned-ppd (#1070) Ā· ublue-os/bluefin@d2be880
@Kyle Gospo Was gonna say, it's fine on 38 but realized we don't build it for 38 lol
i'll take a look at the ptyxis copr stuff
oh, i can't really help it's all under kyle's copr and personal github repo
Goshdarnit Kyle lol
Just kidding Kyle, we appreciate you!
hmm... I use the same copr as a source for ptyxis on my custom image and as of yesterday's build, my ptyxis is still good
i wonder if today's would be broken
yeah it just broke today
maybe we should centralize a bunch of packages in the packages repo while we're converting them to 40?
interesting that there were no ptyxis copr builds yesterday/today, but i see an update to vte packages that identify themselves as from the copr
hmm... yeah, i see the same error after updating to today's build, but the diff is so curious
I'm not sure where
0.74.2-4.fc39.prompt is coming from
well, per my build log, it's from the prompt COPR as we'd expect:
vte291-0.74.2-4.fc39.prompt.x86_64 (copr:copr.fedorainfracloud.org:kylegospo:prompt)
i'm just confused since i don't see a build from yesterday:
https://copr.fedorainfracloud.org/coprs/kylegospo/prompt/package/vte291/
so why the change?I think that should go on the list.
having the repos spread out everywhere and not all maintainers having access to them is a bit of an issue.
not saying I can help troubleshoot RPM package issues.
I agree that this is one case where centralization is a good thing
i partially agree... we don't pull every package we install under our own control
This may be a non issue once we hopefully get our own repo at some point.
but... if it's a personal git and copr which is installed on multiple ublue-org images that is maintained by one of us... yeah, it likely fits for being in the org
i think the https://github.com/KyleGospo/prompt repo could possibly be a subdir within https://github.com/ublue-os/packages like under
staging/prompt or somethingyeah I thought we were going to move stuff into there
so sign of ptyxis in distro either or incoming, so I think that blog is wrong
OH!
it looks like this COPR build for vte291 is set to auto-build... i wonder if after kyle made some changes in github yesterday, then vt291, well, auto-built... and Kyle saw that and deleted the build... but maybe the artifact is still inthe copr yum cache or something
yeah, i think this theory is correct... Kyle yanked the "bad build" but now, there's nothing there
because when i search with DNF, i can't find his vte packages
and when i try a rebuild of my image
error: No matches for 'vte-profile' in repo 'copr:copr.fedorainfracloud.org:kylegospo:prompt'
similar reason bluefin can't rebuild
if you guys want, i can work on getting the last good version (for F39) of everything working in a shared copr...yeah or just toss it in /packages
might as well be the next one?
Almost have the new version of this ready to go
And I'll get this into our packages now
kyle went and got gross
i see what you did there, you went dark, and came back with a miracle
I'll be playing destiny with an old friend tonight, so I'll miss this.
Please feel empathy for me.
I feel empathy for you playing Destiny š
So just run updates from TTY once it's back in place?
Yep
Been out at appointments all day, picked a great day for this to happen
We're going to get something better out of it though, so at least there's that
did I correctly deduce what happened? you did delete the build to prevent more breakage, right?
fishing for "attaboys" here
lol, also, let me know if i can help
Yes you are correct, usually that doesn't delete the only available package, but the previous build must have been old enough to trigger that
Better than shipping something broken I suppose, but unfortunate
this is me learning to better use COPR, thank you
Added bonus, this may fix the funny little accessibility icons on switches we were getting in some apps
thanks to no longer needing a beta build of libadwaita
instead, I'm building the F40 spec on F39
Once I confirm this is all happy, I'll open PRs against Bluefin & Bazzite to switch them to the packages repo for Ptyxis
it's building!!!
vte291 looks good, waiting on gtk4
then libadwaita
then ptyxis for 39
(ptyxis for 40 should build rn)
my custom F39 and F40 both built... i'll test F39 after dinner with fam
I'm sorry to report:
ptyxis hasn't built yet
almost done
oh
š
PHEW!
ok, bbiab
@j0rge @bsherman https://github.com/ublue-os/bluefin/pull/1073
GitHub
fix: Use Ptyxis from the ublue-os/staging copr repo by KyleGospo Ā· ...
Ptyxis now lives at staging in a new Fedora 40 compatible format.
Don't merge yet, this is almost done building in copr
GTK4 takes a full 50 minutes š
feel free to approve if you agree w/ contrainerfile changes though