LeandroStanger
All 21 comments
If anyone is interesting in picking this issue up: feel free.
I've read through the docs and it requires quite some changes to the build process (including bundling SDL2 and SDL_mixer). Since I have zero experience with Flatpak I will have to invest too much time in this.
bvschaik
on 11 Jan 2020
ghost
on 12 Jan 2020
Why would we want to support Flatpak? We already have AppImage and I don't see why we would bother maintaining two different universal executables.
devnoname120
on 13 Jan 2020
I don't mind having support for Flatpak, if it doesn't require much maintenance. I certainly do not have the time to do the initial setup though.
bvschaik
on 15 Jan 2020
Nobody stepped in and no strong argument has been made to specifically add support for this (why Flatpak and not Snap for example?). I suggest to close this issue.
devnoname120
on 22 Jan 2020
Says someone who contributed AppImage support? :) Surely you're not partial about this!
That being said, we expect upstream to have write access and ideally also handle basic maintenance like updates. I can write initial manifest if @bvschaik or someone else from the team is interested in keeping it up to date.
barthalion
on 25 Jan 2020
Never claimed to be impartial. I've done my research and after weighing the pros and the cons of the different technologies I've decided to settle on AppImage for the specific use case of julius.
Good thing if you contribute the Flatpak. I hope this won't disorient users though (should I use the AppImage or the Flatpak?)
devnoname120
on 25 Jan 2020
I think Flatpak has some interesting points.
Flatpak in being wildly adopted by the main Linux desktop project (GNOME), KDE and several distros are enabling it.
The main store of Flatpak is Flathub. Many people search by new software there (directly at the site or via "app store" like Gnome Software). So, if someone has his software in flatpak+flathub:
- Easier to new users discover it. (By App Store or Flathub site)
- Easier to install. Just a click in the App Store (like Gnome/Ubuntu Software), in the same way as their other distro packages (rpm, debs, etc.). So, people don't need to know the site of the developer or the existence of AppImages, etc.
- Automatically updates
- Gnome Software and Flathub have "buttons" to donate to the project.
- Better integration with Desktop (we can see it in the software center, with version, license, button to remove, etc.)
And there are other points like sandboxing, etc.
felipehw
on 25 Jan 2020
That being said, we expect upstream to have write access and ideally also handle basic maintenance like updates. I can write initial manifest if @bvschaik or someone else from the team is interested in keeping it up to date.
That'd be great. How much maintenance does it require?
bvschaik
on 26 Jan 2020
Wrote a manifest yesterday:
{
"app-id": "com.github.bvshaik.julius",
"runtime": "org.freedesktop.Platform",
"runtime-version": "19.08",
"sdk": "org.freedesktop.Sdk",
"finish-args": [
"--filesystem=home",
"--device=all",
"--share=ipc",
"--share=network",
"--socket=x11",
"--socket=pulseaudio"
],
"command": "julius",
"rename-desktop-file": "julius.desktop",
"rename-icon": "julius",
"modules": [
{
"name": "boost",
"buildsystem": "simple",
"build-commands": [
"./bootstrap.sh --prefix=/app --with-libraries=iostreams,filesystem,program_options,date_time",
"./b2 -j $FLATPAK_BUILDER_N_JOBS install"
],
"cleanup": [
"*.a",
"/include"
],
"sources": [
{
"type": "archive",
"url": "https://dl.bintray.com/boostorg/release/1.69.0/source/boost_1_69_0.tar.bz2",
"sha256": "8f32d4617390d1c2d16f26a27ab60d97807b35440d45891fa340fc2648b04406"
}
]
},
{
"name": "innoextract",
"buildsystem": "cmake-ninja",
"sources": [
{
"type": "archive",
"url": "https://constexpr.org/innoextract/files/innoextract-1.8.tar.gz",
"sha256": "5e78f6295119eeda08a54dcac75306a1a4a40d0cb812ff3cd405e9862c285269"
}
]
},
{
"name": "xprop",
"sources": [
{
"type": "archive",
"url": "https://xorg.freedesktop.org/archive/individual/app/xprop-1.2.4.tar.bz2",
"sha256": "8c77fb096e46c60032b7e2bde9492c3ffcc18734f50b395085a5f10bfd3cf753"
}
]
},
{
"name": "julius",
"buildsystem": "cmake-ninja",
"sources": [
{
"type": "archive",
"url": "https://github.com/bvschaik/julius/archive/v1.2.0.tar.gz",
"sha256": "72395c30d3709823de15c2337a552e5ccfa466803a2bd97bc5bee8180b9471e5"
}
]
}
]
}
It still needs an appdata file to be displayed in Flathub/GNOME Software/KDE Discover, I will try to come up with it and submit PR to Julius tomorrow.
@bvschaik Julius seems easy to package so the only thing would be updating releases section in the appdata file and changing version in the manifest.
barthalion
on 27 Jan 2020
@barthalion I'm trying to understand the manifest: what are those boost, innoextract and xprop dependencies?
bvschaik
on 27 Jan 2020
I decided to include innoextract as I can imagine someone using EndlessOS (or other mostly read-only distro like Fedora Silverblue) will find it useful to extract assets from GOG installer. It requires boost to build. xprop is used by tinyfiledialogs:
barthalion
on 27 Jan 2020
I decided to include innoextract as I can imagine someone using EndlessOS (or other mostly read-only distro like Fedora Silverblue) will find it useful to extract assets from GOG installer. It requires boost to build.
Then they can install innoextract themselves. I don't like having it as dependency "just in case".
bvschaik
on 28 Jan 2020
Ack.
{
"app-id": "com.github.bvschaik.julius",
"runtime": "org.freedesktop.Platform",
"runtime-version": "19.08",
"sdk": "org.freedesktop.Sdk",
"finish-args": [
"--filesystem=home",
"--share=ipc",
"--socket=wayland",
"--socket=fallback-x11",
"--socket=pulseaudio"
],
"command": "julius",
"modules": [
{
"name": "xprop",
"sources": [
{
"type": "archive",
"url": "https://xorg.freedesktop.org/archive/individual/app/xprop-1.2.4.tar.bz2",
"sha256": "8c77fb096e46c60032b7e2bde9492c3ffcc18734f50b395085a5f10bfd3cf753"
}
]
},
{
"name": "julius",
"buildsystem": "cmake-ninja",
"sources": [
{
"type": "archive",
"url": "https://github.com/bvschaik/julius/archive/v1.2.0.tar.gz",
"sha256": "72395c30d3709823de15c2337a552e5ccfa466803a2bd97bc5bee8180b9471e5"
},
{
"type": "patch",
"path": "metainfo.patch"
}
]
}
]
}
metainfo.patch is https://github.com/bvschaik/julius/pull/285. When (if) it's merged, I'll create a submission to Flathub.
barthalion
on 28 Jan 2020
285 has been merged.
bvschaik
on 28 Jan 2020
Hey @barthalion , question: say I want to release Julius 1.2.1. What should I do to get the new release pushed to Flathub?
bvschaik
on 29 Jan 2020
I've opened PR with Julius just today so at the moment I can update it there: https://github.com/flathub/flathub/pull/1351
After it's merged, you will have write access to separate git repo where you can push changes to the manifest.
barthalion
on 29 Jan 2020
Merged, please take a look at the welcome message. It will become visible at https://flathub.org in a couple of hours.
barthalion
on 29 Jan 2020
Thanks! If I understand correctly, next release I can remove the metainfo.patch because those changes are now in the Julius repo, right?
bvschaik
on 29 Jan 2020
Yup! Please remember to update release info in appdata file.
Looks like it's visible in web frontend already: https://flathub.org/apps/details/com.github.bvschaik.julius
barthalion
on 29 Jan 2020
@barthalion Someone opened an issue that TinyFileDialogs cannot find any file dialogs (because Julius is sandboxed?), and suggested including zenity as dependency. Could you perhaps help adding it?
bvschaik
on 12 Mar 2020
Related issues
jonathanmcnamee
路
3Comments
jdmillard
路
3Comments
giggietto
路
8Comments
LePatator
路
5Comments
pingwinator
路
8Comments
Most helpful comment
Says someone who contributed AppImage support? :) Surely you're not partial about this!
That being said, we expect upstream to have write access and ideally also handle basic maintenance like updates. I can write initial manifest if @bvschaik or someone else from the team is interested in keeping it up to date.