Improvements to Linux packaging

[guihkx]

These changes are meant to make things easier for package maintainers to distribute Notes on their Linux distribution.

We now use CMake to configure and install:

• The desktop file
• The AppStream metadata file (added just now!)
• ... And of course, our app icons in many resolutions!

Now, Linux package maintainers won't have to look for those files manually, or perhaps tweak them before packaging Notes: It should be all done automagically!

The build steps for packaging should be as easy as:

$ cmake -B builddir -DCMAKE_INSTALL_PREFIX=/usr \
    -DCMAKE_BUILD_TYPE=Release \
    -DUPDATE_CHECKER=OFF 
$ cmake --build builddir
$ DESTDIR="package_dir" cmake --install builddir

P.S.: There are some changes unrelated to Linux here as well, but since they're so minor, I decided to include them here instead of opening a new PR. Hope it's okay.... :)

[guihkx]

If someone wants to inspect the contents of the AppImage we're building, you can extract it with:

$ ./Notes*.AppImage --appimage-extract

And then you can browse the squashfs-root/usr directory to look at the files we're shipping. :)

[nuttyartist]

Great.

The build steps for packaging should be as easy as:

Should we add this to README?

BTW, I want to disclose md5 hashes of the binaries created by ~AppVeyor~ Github Actions that we're going to put in under the Release. Maybe we can automatically generate them? I guess for the macOS version, it currently doesn't make sense since I will need to sign and notarize it on my own machine.

Another question, on release (pushing to the main) the binaries' names not gonna have the commit id, etc attached to them, right?

Another question, Is the flatpack also going to be auto-generated via Actions as well?

EDIT: Not AppVeyor but Github Actions (didn't drink enough coffee today hah).

[guihkx]

Should we add this to README?

I'm actually working on documenting the build steps (and build options) across Windows, macOS and Linux, but it's quite extensive and a bit messy, so it's not ready yet...

BTW, I want to disclose md5 hashes of the binaries created by Github Actions that we're going to put in under the Release. Maybe we can automatically generate them? I guess for the macOS version, it currently doesn't make sense since I will need to sign and notarize it on my own machine.

This is possible, but in my opinion it should be done once we get the notarization and signing done completely in CI too.

Once that is achieved, we can even use a GitHub "release action" to automate the releasing process even further, and then the checksums can be generated there as well.

Another question, on release (pushing to the main) the binaries' names not gonna have the commit id, etc attached to them, right?

Once you push a tag (e.g. v2.1.0), then GitHub Actions will actually trigger a new build. And this build will not have the commit id attached to the app version.

Another question, Is the flatpack also going to be auto-generated via Actions as well?

No, the Flatpak manifest will be maintained on separate repository, under the flathub namespace on GitHub, where we will have commit access.

For example, the Flatpak manifest for LibreOffice is maintained here:

https://github.com/flathub/org.libreoffice.LibreOffice

The actual building is then done by the Flathub infrastructure (take a loook at Flatpak apps being built here). And regarding its maintainability, it should be very easy, and mostly automated.

Don't worry, you'll get to see it in action once the app is submitted to Flathub. :)

[nuttyartist]

I'm actually working on documenting the build steps (and build options) across Windows, macOS and Linux, but it's quite extensive and a bit messy, so it's not ready yet...

Okay, we'll wait.

This is possible, but in my opinion it should be done once we get the notarization and signing done completely in CI too.

Once that is achieved, we can even use a GitHub "release action" to automate the releasing process even further, and then the checksums can be generated there as well.

Alrighty, sounds like a cool plan (:

Once you push a tag (e.g. v2.1.0), then GitHub Actions will actually trigger a new build. And this build will not have the commit id attached to the app version.

👍

No, the Flatpak manifest will be maintained on separate repository, under the flathub namespace on GitHub, where we will have commit access.

Oh, ok. Nice.

[guihkx]

This didn't get any formal reviews yet, but I really want to include these changes before v2.1.0 is released.

@nuttyartist Do I have your approval?

[nuttyartist]

It's good to have someone else also review this. I think we can push this before 2.1.0 is released.

[nuttyartist]

Still trying to figure out some issues with notarizing Notes (Getting invalid status over Unnotarized Developer ID). So delaying it for at least tomorrow.

[nuttyartist]

I believe we can merge this. And we can release 2.1.0 today.

[bjorn]

I won't have time to give this a detailed review and it's a bit outside of my area anyway since I'm not really familiar with CMake, so please don't wait on me. :-)