Yeah I'm just hoping to have one place to point people so we don't have to keep explaining it over a
Yeah I'm just hoping to have one place to point people so we don't have to keep explaining it over and over
Byeah... i'm searing a bit for another explanation online but not finding one
BIt really seems like something which should be covered in this doc: https://coreos.github.io/rpm-ostree/container/#rebasing-a-client-system
BI added a comment to the issue.
Bit is possible to disable but not remove becuase of very basic fact that it is using a OCI IMAGE with some packages disabling works with some it doesnt but from what i have seen not being disabled is mostly function of is it a dependency of something
EI wonder how much bigger the image would be if we embedded just Prompt. Of course, that would come with its own issue of missing updates until the image received an update but it would mean GNOME Terminal could be removed without consequences
Jyeah or perhaps as an rpm, but there are vte patches, I figure for now let's let the people who want to opt in play while we discuss with christian on how to do it in a way that works. I kinda don't wanna package it because he put a ton of effort making it flatpak friendly.
BIn my image i plan to keep gnome-terminal if for no other reason as a backup
BBut prompt is a must have
CI don't like the idea of replacing Gnome Terminal with Prompt because Prompt is just about the worst possible name for a terminal app and makes troubleshooting nearly impossible
CThe repo is unsearchable unless you have a direct link
CAlso, Gnome Terminal has been a reliable and decently feature-complete default for years, while Prompt looks like this for me:
CThe features I've seen y'all describe sound neat, and I'm all for modern GUI features in a terminal app, but I am not confident in Prompt's readiness for prime time as a default, let alone a singular option with Gnome Terminal completely removed
CMostly the issue for me is that it is unsearchable, so it is difficult or impossible for me to find information about Prompt which could address my other concerns
Jyours looks like that because you're on nvidia and it's a nightly snapshot, by the time it lands in flathub you shouldn't have that issue
J
Jlol
EI applied but... Didn't go so hot
CFingers crossed. I'll keep an eye on it
Jit's only a few weeks old
Emaybe prompt could benefit a search-friendly alias, like how go has golang
CI think so
J@xyny images-website had a bunch of dependabot updates backed up and some of them were pretty severe so I merged them, everything appears to be working normally so just a heads up
KWant to give this a try for me? You can run it through distro box
TAlready got the flatpak working with an env var
TCan try the copr too if you want
KI would appreciate it, I don't have any Nvidia hardware to test against and I'm thinking about pushing this on a test build
KShould work with no environment variable since it's built against stable gtk
TDistrobox appears to be broken again
CNot sure when I'll get to it but I'll try to give that a shot
TAnyone know how to solve
Error: OCI runtime error: crun: ptsname: Inappropriate ioctl for device on a fresh fedora distrobox?TWait it just went away
Tnever seen that one before
TSeems to be working here, apart from being able to find containers on the host which I'd expect to not work since it's running inside a distrobox
KAwesome, thank you!
Xsure thanks, it appears i'm not watching the repo, i should get to that...
K@j0rge
Kdisappearing windows is some wobbly window bug
Kignore that lol
ESweet! Incredible work on getting all of this together
Jcan you post an update here? https://universal-blue.discourse.group/t/moving-to-gnomes-prompt-for-a-default-terminal/248
Universal Blue
Alright folks, here it is! https://blogs.gnome.org/chergert/2023/12/14/prompt/ and here’s a companion video I made: Find the repo here: Christian Hergert / prompt · GitLab Let’s use this thread for feedback/ideas, and then we can be good OSS citizens by kicking the tyres to get the terminal of our dreams! Here’s our in progress...
XI just noticed something funny.
XAll Ublue repos I checked have a checkout action step like this:
XI wondered why this makes no sense. Then I googled "Checkout Push to Registry action" and found this: https://github.com/redhat-actions/push-to-registry/blob/9986a6552bc4571882a4a67e016b17361412b4df/.github/workflows/multiple-build.yaml#L30C1-L32C34
XThe build action for the
push-to-registry action that we use uses the exact some checkout step, with a different version.XSeems that at some point someone, probably jorge, copied some code that builds the
push-to-registry action and this was with it. Then no-one bothered to change this part, neither cryptic the name or the comment, which refer to checking out the push-to-registry repo and not any Ublue repo.Jwe're using
actions/checkout@v4 right?XYeah
