feat: Jan is distributed via flatpak
Problem Statement
- AppImage distribution got a lot of problems on different linux distro
- can't start on Arch
- can't start on opensuse
Feature Idea
Jan will be distributed via flatpak.
Here for related issue https://github.com/menloresearch/jan/issues/5380
Currently some issues we have identified:
- cortex server fails to start from inside the sandbox because a file required is missing
- Jan auto updater needs to be disabled and let flatpak handle the update
- copying stuff from rootdir should not be done, instead, they should be downloaded separately during first launch (low priority)
Decided to ship with the new llamacpp-extension because cortex seems buggy inside the sandbox.
the flathub version of it is closed for no reason, please open the PR in flathub repo and submit it again!
Oh no, I've been monitoring this closely, there is no chance to get it by 0.6.9? 😢
Hey @linuxkernel94 it is still in the work But we are being blocked on the upstream right now https://github.com/flathub/flathub/pull/6820
Do give us more support there if you can 😿
Got it, Unfortunately I’m not a programmer, but thank you for sharing the link. I really appreciate your work and will follow that one instead 🐱
Hi @LazyYuuki I see that the status now says "[awaiting-changes]" is upstream still blocking you? Just to let you know in case you have missed the notification.
Thanks!!
Hi @linuxkernel94 yes They are being a bit tough on us for some reason Even though they let quite a bit of other package that doesnt build from source through also
We can only rely on the community to help unblock us 😢
@LazyYuuki I left a message in the issue, and I also know a few people on the forums who are interested in a Flatpak version, I told them to leave a message in case nobody respond.
But someone just replied on the issue. Let me know if there's anything else I can do to help.
I'd really love to see Jan on Flathub 🙏
Hi @LazyYuuki I just wanted to know if you got my last message.
Thank you!
hey @linuxkernel94 we are still working on it, we are trying to see how to build it from source to satisfy their requirements.
any idea when it will be available as flatpak on flathub https://docs.flatpak.org/en/latest/first-build.html https://discourse.flathub.org/t/building-my-first-flatpak/4882
Hey @olumolu, we are trying to build from source and resubmit the app to flathub soon! We'll keep everyone posted on the ticket!
Todo: https://github.com/menloresearch/jan/issues/6511
Hey @olumolu, we are trying to build from source and resubmit the app to flathub soon! We'll keep everyone posted on the ticket!
Todo: #6511
i think now i can install jan from flathub as flatpak...?
Hey @Minh141120 just checking in on Flatpak support. I see this is marked Blocked under v0.7.3; is there any update or specific blockers?
This is a super anticipated feature
Hey everyone, Sorry for the late update!
We’ve been working on building the package from source, but unfortunately ran into issues with flatpak-node-generator, which doesn’t seem to handle Yarn dependencies correctly. The build process fails with the following error:
Found 13 lockfiles.
Reading packages from lockfiles...
Traceback (most recent call last):
...
File "providers/yarn.py", line 68, in parse_lockfile
key, value = shlex.split(line)
ValueError: too many values to unpack (expected 2)
We were able to successfully generate dependencies for the Rust backend using flatpak-cargo-generator
However, the issue arises when handling Yarn dependencies — it seems the current toolchain doesn’t fully support our setup.
The node generator does not supportyarn v2+ lockfiles https://github.com/flatpak/flatpak-builder-tools/issues/361
Given this, we’ll proceed with providing other Linux distribution packages first (AUR, RPM, etc.) while we continue to investigate Flatpak compatibility.
@Minh141120: The yarn tool in Flatpak was deprecated (as seen in their README). They recommend to use flatpak-node-generator instead.
I guess that leaves 4 options:
- Push for yarn2 support in flatpak-builder-tools's yarn tool. An implementation is at https://github.com/flatpak/flatpak-builder-tools/pull/252 but there seems to be no promise of actually merging. Consider the maintainers have marked the tool deprecated, they might not merge that at all.
- Patch the tool yourself before using. Or write your own tool to replace it for your purpose.
- Use conversion tools like synp, in the build process, to convert yarn.lock to package-lock.json and then use flatpak-node-generator.
- Migrate from
yarntonpm, which I suppose is better supported by flatpak-node-generator.
Option 3 should be the most feasible one.
Option 4 is also not a bad option. I doubt if there is any reason to specifically use yarn (but not npm) in this project other than personal preference.
@Minh141120
I would consider PNPM tbh. yarn has made design choices not widely adopted by the node ecosystem and often hits issues due to its new storage formats. PNPM works to keep node_modules while de-bloating the disk via symlinks. My opinion is it would likely be a less eng effort to move to pnpm, and improve DevX then to DIY stuff, assuming that works with flatpak-node-generator. It might be of benefit to create a small pnpm based tauri app and test that.
I would consider PNPM tbh. yarn has made design choices not widely adopted by the node ecosystem and often hits issues due to its new storage formats. PNPM works to keep
node_moduleswhile de-bloating the disk via symlinks. My opinion is it would likely be a less eng effort to move to pnpm, and improve DevX then to DIY stuff, assuming that works withflatpak-node-generator. It might be of benefit to create a small pnpm based tauri app and test that.
https://github.com/flatpak/flatpak-builder-tools/issues/383
If I may, I would like to remind everyone here that the feature request was to release the app in Flatpak. Not making the perfect release workflow.
Sometimes it's almost easier to think of a perfect solution than to formulate one that works ASAP. Who don't want perfect setup? But what user wants here is a working setup for a Flatpak deliverable. Not a perfect one.
The below solutions should work with a relatively easy development:
- Using File source to copy a prebuilt binary (e.g. .deb as shown in their example) into the bubblewrap sandbox for extract.
- Use conversion tools like synp, in the build process, to convert yarn.lock to package-lock.json and then use flatpak-node-generator.
I suggest to go for either one for the moment. And then worry about migrating to a better implementation later.
Using [File source(https://docs.flatpak.org/en/latest/module-sources.html#file-sources) to copy a prebuilt binary (e.g. .deb as shown in their example) into the bubblewrap sandbox for extract.
For approach 1, we actually tried submitting the prebuilt binary file, but unfortunately it wasn’t accepted.
We’re actively working on this and definitely want to bring the Flatpak release to our users as soon as possible.
Use conversion tools like synp, in the build process, to convert yarn.lock to package-lock.json and then use flatpak-node-generator.
We'll continue exploring the options that @yookoala suggested. Thanks again for the valuable input!
Thanks so much for the valuable insights and support, everyone — we really appreciate it!
Can you call contact for help maybe https://discourse.flathub.org/
FYI: The Flatpak submission has now been accepted: https://github.com/flathub/flathub/pull/6820
We’ll proceed with the domain verification next, and once that’s completed the app should be fully ready on Flathub.
Thank you all so much for your patience and for waiting through this long process — we really appreciate it.
We’ll close this issue for now