Flatpak

[sztomi]

I've started creating a flatpak package for Rio here: https://github.com/sztomi/flathub/tree/new-pr

It builds and runs, but I'm running into a problem: when it starts, it seems to run the shell that is in the sandbox instead of the system. I would think this is because of the sandboxing, but I used the wezterm flatpak as a starting point and wezterm doesn't seem to have that issue: https://github.com/flathub/org.wezfurlong.wezterm/blob/master/org.wezfurlong.wezterm.json

My guess is that rio is falling back to running sh due to some assumptions that don't hold when being ran in a container. Any ideas what might be happening here?

FWIW, this is how I build and run the above:

$ flatpak-builder --force-clean --user --install --repo=repo build-dir io.raphamorim.Rio.json
$ flatpak run io.raphamorim.Rio

---

Slightly unrelated, but it would be useful to include an icon that is smaller because flatpak refuses to export an icon over 512x512. So now I'm resorting to building imagemagick and resizing it.

[sztomi]

I think I can answer my question: wezterm is doing something special when running in flatpak: https://github.com/wez/wezterm/blob/99c9613966a73d5388344fd0df68d5977b493c7c/mux/src/domain.rs#L364

Is there interest in accepting a PR that adds this feature?

[raphamorim]

Thanks for the issue @sztomi

Is there interest in accepting a PR that adds this feature?

Yes, that would be great

The issue is exactly what you found, Rio can't retrieve $SHELL outside of sandbox.

https://github.com/wez/wezterm/blob/99c9613966a73d5388344fd0df68d5977b493c7c/mux/src/domain.rs#L394-L404

I created a branch with similar approach as wezterm for retrieve the SHELL would mind check it? https://github.com/raphamorim/rio/tree/flatpak

Slightly unrelated, but it would be useful to include an icon that is smaller because flatpak refuses to export an icon over 512x512. So now I'm resorting to building imagemagick and resizing it.

I assume it does not support svg icons right?

[sztomi]

I created a branch with similar approach as wezterm for retrieve the SHELL

It's not working for some reason (but looking at the code, it should). I can also run the same command and get the right shell and the .flatpak-info file exists.

I assume it does not support svg icons right?

That's a good question, it probably does (flatpak relies heavily on Freedesktop specifications) but there might be a requirement to also provide a non-vector icon. I'll look into it.

[raphamorim]

It's not working for some reason (but looking at the code, it should). I can also run the same command and get the right shell and the .flatpak-info file exists.

Did you have configured shell in config file? if it does exist it will override shell coming from environment. Wondering if the function is even being called in teletypewriter.

That's a good question, it probably does (flatpak relies heavily on Freedesktop specifications) but there might be a requirement to also provide a non-vector icon. I'll look into it.

Cool please let me know any finding otherwise I can for sure add an icon with 512x521 to the project.

[sztomi]

Did you have configured shell in config file?

No, I don't have anything configured, actually.

Cool please let me know any finding

Sounds like svg is fine: "Icons should be named with the application’s ID, be in either PNG or SVG format" https://docs.flatpak.org/en/latest/conventions.html#application-icons

[raphamorim]

No, I don't have anything configured, actually.

I see, just pushed few changes (realized get_pw_entry was being called twice and overwriting SHELL env). Could you check again? @sztomi

Sounds like svg is fine: "Icons should be named with the application’s ID, be in either PNG or SVG format" https://docs.flatpak.org/en/latest/conventions.html#application-icons

Cool! the svg path is https://github.com/raphamorim/rio/blob/main/misc/logo.svg

[sztomi]

The svg icon works and I made the change to use it (no more imagemagick! haha)

The latest changes on the flatpak branch lead to crash right after startup. I made a new branch that allows building from a local copy if you'd like to iterate on this: https://github.com/sztomi/flathub/tree/local

To get started:

$ flatpak install flathub org.flatpak.Builder
$ flatpak install flathub org.freedesktop.Platform//22.08 org.freedesktop.Sdk//22.08
$ flatpak install flathub org.freedesktop.Sdk.Extension.rust-stable/x86_64/22.08
$ alias flatpak-builder='flatpak run org.flatpak.Builder'
$ ln -s <your rio source dir> ./rio  # (or change the json file to point to the absolute path)

After each change,

$ flatpak-builder --force-clean --user --install build-dir io.raphamorim.Rio.json
$ flatpak run io.raphamorim.Rio  # or use the desktop launcher

(if not, that's fine, I'll try to fiddle with it)

Another question: does Rio support falling back to x11 if wayland is not available? I sort of assumed it did when built with both features, but I can't tell. Doing so is the preferred behavior for flatpak applications, as you can't really provide different versions (unless you package two different app IDs, but flathub might reject that).

[raphamorim]

Sorry about delay regarding this issue,

Another question: does Rio support falling back to x11 if wayland is not available? I sort of assumed it did when built with both features, but I can't tell. Doing so is the preferred behavior for flatpak applications, as you can't really provide different versions (unless you package two different app IDs, but flathub might reject that).

Doesn't have support for it natively, often rio is distributed with x11 or wayland label. Do you know how alacritty does? (if exist in flatpak)

[raphamorim]

The svg icon works and I made the change to use it (no more imagemagick! haha)

That's great news!

The latest changes on the flatpak branch lead to crash right after startup. I made a new branch that allows building from a local copy if you'd like to iterate on this: https://github.com/sztomi/flathub/tree/local

I will try it once I get my linux machine back lately have been switch between windows/macos due to work.

[sztomi]

Do you know how alacritty does? (if exist in flatpak)

No alacritty flatpak and from what I've seen in the repo, the maintainers have no interest in any packaging (they did state that they will accept patches to support packaging needs though). Wezterm on the other hand does this (they declare the flatpak supporting wayland with an X11 fallback).

[raphamorim]

Running locally and I am assuming it has some sort of fallback because it started for me with wayland instead of X11.

I didn't figured out how to point the flatpack-builder to the local directory

[sztomi]

how to point the flatpack-builder to the local directory

In my local branch, I changed the source from a tarball to a local dir here: https://github.com/sztomi/flathub/blob/local/io.raphamorim.Rio.json#L44

And I created a symlink from my local checkout to ./rio: ln -s ~/projects/rio ./rio. But you may also simply set an absolute path on that line, maybe that's even easier.

[raphamorim]

Coolio that works! pushed a change in latest main branch regarding flatpak, have not completely tested yet (feel free to test if you want) but will look it further.

[raphamorim]

Ok figured out why,

It runs and ask for the SHELL as is supposed to be and then crash because /usr/bin/zsh does not exist in the sandbox.

[raphamorim]

Which it does not really exists, do you know if is possible to map it to the sandbox?

[sztomi]

Which it does not really exists, do you know if is possible to map it to the sandbox?

It's not (without excessive filesystem permissions), but there is an escape hatch in the form of flatpak-spawn. I think that's likely the solution to this.

Edit: looking at wezterm again, that seems to be exactly what they are doing: https://github.com/wez/wezterm/blob/99c9613966a73d5388344fd0df68d5977b493c7c/mux/src/domain.rs#L364

[raphamorim]

yea..

the configuration is very alike as well https://github.com/wez/wezterm/blob/70931f58f1c7a57fd377f9862597e7b1fe070b52/assets/flatpak/org.wezfurlong.wezterm.json#L16

https://github.com/wez/wezterm/blob/70931f58f1c7a57fd377f9862597e7b1fe070b52/ci/flatpak.sh#L4

will take a further look later

[sztomi]

the configuration is very alike as well

That is no coincidence, I used wezterm's config as a starting point.

wez/wezterm@70931f5/ci/flatpak.sh#L4

This can also be useful as a starting point for automating the flatpak creation. I wouldn't necessarily do it exactly like this, but the concepts will be largely the same.

[raphamorim]

Got it! re-reading wezterm code i understand, i naively thought would just need the shell for the fork/spawn

[raphamorim]

@sztomi can you check with latest main? Besides that I believe that you mentioned the fact that should support x11 and wayland right?

I tested locally and I have x11/wayland but it does choose wayland to open it. In your case it opened with wayland too right?

[sztomi]

@raphamorim Success! It runs fine and uses my shell. Yes, it picks wayland. I think the interesting test would be installing the same flatpak on an xorg system. I'll try that in a VM.

I'm almost sure it's unrelated, but tmux is acting a little weird when I switch between the panes and the split line was very hard to drag with the mouse. If I switch to the right pane, the windows contents change like this without doing anything else. They switch back if I switch to the left pane.

[raphamorim]

@raphamorim Success! It runs fine and uses my shell. Yes, it picks wayland. I think the interesting test would be installing the same flatpak on an xorg system. I'll try that in a VM.

Nice, great to hear!! Btw I checked out and is winit https://crates.io/crates/winit that chooses between wayland or x11. If the user has a configuration to prefer x11 or wayland in the compositor that will be choice.

I'm almost sure it's unrelated, but tmux is acting a little weird when I switch between the panes and the split line was very hard to drag with the mouse. If I switch to the right pane, the windows contents change like this without doing anything else. They switch back if I switch to the left pane.

Do it happens also outside of flatpak? if does then we can create an issue regarding it.

[sztomi]

If the user has a configuration to prefer x11 or wayland in the compositor that will be choice.

Yep, good to know there is explicit documentation supporting this. I can confirm it works with X as well. I installed the flatpak on a Ubuntu 20.04 VM running Xorg and it had no problems.

Do it happens also outside of flatpak? if does then we can create an issue regarding it.

I could definitely reproduce the difficulty with dragging the split. I could not get the weird switching behavior, but that could be due to window size and content.

OK, as for the flatpak, the next steps should be (provided you want it published on Flathub):

• I'll wait for a release that contains your fixes for running in a flatpak. In the meantime, I'll confirm the config file location and open a PR in this repo to add that to the documentation
• Do you want to own/maintain this package on Flathub.org? If so, you can fork my flathub repo and open a PR in flathub/flathub against the new-pr branch. The flathub process is getting a your PR approved and then they will create a repo under the flathub org that you have access to. If you don't want to maintain it, I'm happy to commit to it for a while.

Releases on flathub are created via PRs against that repo in the flathub org (i.e. editing the metadata to point to the latest release). There is an intermediate step due to flatpak requiring offline builds. The generated-sources.json file is created from Cargo.lock like this in wezterm's automation: https://github.com/wez/wezterm/blob/main/ci/flatpak.sh#L12C8-L12C8 I did the same manually, but I think it is worth doing something similar to that in Github Actions, in a job that runs on a new release. That way, maintaining the flatpak is mostly no-op after the initial setup.

[raphamorim]

Yep, good to know there is explicit documentation supporting this. I can confirm it works with X as well. I installed the flatpak on a Ubuntu 20.04 VM running Xorg and it had no problems.

🥳

I could definitely reproduce the difficulty with dragging the split. I could not get the weird switching behavior, but that could be due to window size and content.

Ok, I will mark it to take a look on next version.

I'll wait for a release that contains your fixes for running in a flatpak. In the meantime, I'll confirm the config file location and open a PR in this repo to add that to the documentation

Sounds good, believe by end of next week or beginning of last week I should wrap up a release candidate.

Do you want to own/maintain this package on Flathub.org? If so, you can fork my flathub repo and open a PR in flathub/flathub against the new-pr branch. The flathub process is getting a your PR approved and then they will create a repo under the flathub org that you have access to. If you don't want to maintain it, I'm happy to commit to it for a while.

I rather skip maintaining it for now as other packages I also try to don't have the direct ownership. If you could take it would be the best and if at some moment want to stop maintaining it we can ask the community in the discord if anyone would volunteer or I can take it.

[sztomi]

@raphamorim alright, I'm happy to maintain it for a while and I will let you know if I have a change of plans. The automation would be best hosted in this repo still (to push a PR to the flathub repo when there is a new release). Will you accept a PR with some github actions / build script changes to facilitate that?

[raphamorim]

alright, I'm happy to maintain it for a while and I will let you know if I have a change of plans. The automation would be best hosted in this repo still (to push a PR to the flathub repo when there is a new release). Will you accept a PR with some github actions / build script changes to facilitate that?

Of course 💯

[raphamorim]

@sztomi released v0.0.19 https://raphamorim.io/rio/release-0.0.19/

[sztomi]

@raphamorim thanks! I ran into a snag:

error: failed to select a version for the requirement `image = "^0.24.6"` (locked to 0.24.6)
candidate versions found which didn't match: 0.24.7
location searched: directory source `/run/build/rio/cargo/vendor` (which is replacing registry `crates-io`)
required by package `sugarloaf v0.0.18 (/run/build/rio/sugarloaf)`
perhaps a crate was updated and forgotten to be re-vendored?

It looks like image = "0.24.6" is specified in the dev-dependencies of sugarloaf, but the lockfile specifies 0.24.7 (which is what ends up in the generated sources json, i.e. what's downloaded by flatpak-builder.

[raphamorim]

hmmm, @sztomi pushed a fix for it in the main.

[sztomi]

@raphamorim thanks, that seems to have worked :tada: Will you cut a patch version with this fix? Or should I wait for the next one? (I'd rather not upload a non-release commit to flathub)

[raphamorim]

🥇 of course, once I prepare to release I will ping you here 🙏

[raphamorim]

0.0.20 released 👍

[sztomi]

@raphamorim I opened the flathub PR (link above) against v0.0.22.

[raphamorim]

That's exciting! please let me know anything I can help @sztomi

[Brianalmeida]

Is there any update on this issue? Would love to see this happen