Add debian package generation to CMakeLists.txt

[zjeffer]

TODO:

• [x] Add dependencies for qt5 and qt6
• [x] Any other info that needs to be added to a deb?
• [x] Add CI/CD to generate .deb packages

[guihkx]

Right now the generated deb when you run cpack -G DEB is named like this:

Notes-0.1.1-Linux.deb

So a couple of suggestions:

• Set CPACK_PACKAGE_NAME to: notes (lower case is the "standard")
• Set CPACK_PACKAGE_VERSION to: ${PROJECT_VERSION}${GIT_REV}
• And then finally, set CPACK_PACKAGE_FILE_NAME to something like: ${CPACK_PACKAGE_NAME}_${CPACK_PACKAGE_VERSION}_${CPACK_DEBIAN_PACKAGE_ARCHITECTURE}

Though I'd love to have the short name of the distro at the end there (e.g. bionic or focal), but I haven't figured out how to do that easily.

[zjeffer]

For some reason my generated filename on my Ubuntu VM is now notes_2.1.0_.deb ? as if the architecture is empty?

And aren't dashes better than underscores here? Looks better to me for some reason.

[guihkx]

For some reason my generated filename on my Ubuntu VM is now notes_2.1.0_.deb ? as if the architecture is empty?

Odd... I'll investigate.

And dashes better than underscores here? Looks better to me for some reason.

As usual, I have no strong feelings about these things, but I'll just note that the naming convention for .debs seems to be using underscores instead of dashes. For example, the official qBittorrent deb is named like this: qbittorrent_4.0.3-1_amd64.deb.

[guihkx]

Based on what I could find, simply setting CPACK_DEBIAN_FILE_NAME to DEB-DEFAULT and then removing CPACK_PACKAGE_FILE_NAME, should work.

[guihkx]

@zjeffer First of all, I'm sorry I didn't let you know you that I was also working on this (on a local branch).

Right now, I have made some rather big changes there, which also includes an already-working GHA workflow (it's basically reusing the current build-apt job we have, but with some modifications).

So I wanted to ask you if it'd be okay for me to merge my changes here? Some of your changes will be lost, though.

One 'big' change is that I have moved away from manually-set dependencies...

If you want to inspect my changes first: guihkx/notes@feature/zjeffer/cpack.

I'm very close to getting the generated deb package to pass lintian checks - not that it has to, but it's definitely a "nice to have". :)

I haven't tested the generated debs yet, though.

The list of dependencies (that were generated automatically by dpkg-shlibdeps) seems to look okay too, but more testing would be appreciated.

[zjeffer]

Ah, ok, let's use your changes instead.

Mine were created mostly with ChatGPT anyway, I didn't spend that much time on it ;)

[guihkx]

I believe it's just a matter of getting rid of the lintian errors/warnings now, but the generated deb packages seem ok.

[zjeffer]

Getting this error when executing sudo dpkg -i notes_2.1.0+g3831c0a_amd64.deb on Ubuntu 22.04:

(Reading database ... 224956 files and directories currently installed.)
Preparing to unpack notes_2.1.0+g3831c0a_amd64.deb ...
Unpacking notes (2.1.0+g3831c0a) over (2.1.0+g3831c0a) ...
dpkg: dependency problems prevent configuration of notes:
 notes depends on qt6-base-abi (= 6.2.4); however:
  Package qt6-base-abi is not installed.
  Version of qt6-base-abi on system, provided by libqt6core6:amd64, is 6.3.1.

dpkg: error processing package notes (--install):
 dependency problems - leaving unconfigured
Processing triggers for mailcap (3.70+nmu1ubuntu1) ...
Processing triggers for gnome-menus (3.36.0-1ubuntu3) ...
Processing triggers for desktop-file-utils (0.26-1ubuntu4) ...
Processing triggers for hicolor-icon-theme (0.17-2) ...
Errors were encountered while processing:
 notes

[guihkx]

I wonder why dpkg-shlibdeps listed qt6-base-abi as requiring exactly version (= 6.2.4). Maybe because we're using private Qt headers?

Anyway, I'll try to get rid of that...

[zjeffer]

Same problem.

[guihkx]

It's always too good to be true. 🥲

Just out of curiosity, can you try to install the Qt 5 deb (and see if it runs)?

[zjeffer]

(Reading database ... 224956 files and directories currently installed.)
Preparing to unpack notes_2.1.0+g2b63bab_amd64.deb ...
Unpacking notes (2.1.0+g2b63bab) over (2.1.0+g2b63bab) ...
dpkg: dependency problems prevent configuration of notes:
 notes depends on libqt5core5a (>= 5.9.0~beta); however:
  Package libqt5core5a is not installed.
 notes depends on libqt5gui5 (>= 5.8.0); however:
  Package libqt5gui5 is not installed.
 notes depends on libqt5network5 (>= 5.0.2); however:
  Package libqt5network5 is not installed.
 notes depends on libqt5sql5 (>= 5.0.2); however:
  Package libqt5sql5 is not installed.
 notes depends on libqt5widgets5 (>= 5.9.0~beta); however:
  Package libqt5widgets5 is not installed.

dpkg: error processing package notes (--install):
 dependency problems - leaving unconfigured
Processing triggers for mailcap (3.70+nmu1ubuntu1) ...
Processing triggers for gnome-menus (3.36.0-1ubuntu3) ...
Processing triggers for desktop-file-utils (0.26-1ubuntu4) ...
Processing triggers for hicolor-icon-theme (0.17-2) ...
Errors were encountered while processing:
 notes

[guihkx]

Since you're installing the deb with dpkg, it won't automatically install the dependencies for you. You have to run sudo apt-get -f install afterward.

You can try installing the deb with sudo apt install --fix-broken notes.deb.

But it always weirded me out that sudo dpkg -i didn't do that automatically...

[zjeffer]

Works!

[guihkx]

Based on what I could find on Google, I don't see any way around this except by also building for the latest non-LTS Ubuntu release... :S

I'm not sure if listing the dependencies ourselves is recommended, so I'd like to avoid that (unless someone more experienced with deb packaging can chime in)...

[bjorn]

Based on what I could find on Google, I don't see any way around this except by also building for the latest non-LTS Ubuntu release... :S

Or, we could try not to rely on private Qt headers? Did you confirm whether that is the reason for the specific version? (it would make sense, at least)

[guihkx]

Or, we could try not to rely on private Qt headers?

I believe we have to, if we want to have the global shortcut feature (provided by Qxt). I'm not sure if we rely on private headers in other places, though.

Did you confirm whether that is the reason for the specific version

Not really, but it's likely that's the reason... I found this Debian bug report that mentions that qt6-base needs a transition due to ABI changes, and private headers are mentioned too.

[zjeffer]

I think we should merge this (if it all looks good) & create a new release with the latest changes (windows default native decorations & font resizing fixes), so we can create a debian package. We could call the release 2.1.1? @nuttyartist

[guihkx]

I'm not in favor of merging this (just yet).

I was able to get rid of a couple of lintian warnings, but I still want to at least get rid of the errors (the remaining warnings we can figure later).

Ubuntu 18.04:

Ubuntu 22.04 / 22.10:

The errors should not be too hard to get rid of, I think.

[guihkx]

I got rid of the lintian errors. Now, on latest Ubuntu there's just a single warning about a missing manpage, which should be fine to ignore for now.

I couldn't figure out a way to install these Debian-related files (i.e. copyright and changelog.gz) only when running cpack -G DEB, so instead of installing these files on every Linux distro (which is kind of silly, in my opinion), I'm simply checking if the file /etc/debian_version is present on the host before I generate/install them. This approach kinda makes sense, but doesn't feel 100% right to me.

Anyway, here's a summary of the important changes so far:

• We now generate .deb packages for the following Ubuntu versions:

  • 18.04 LTS (Bionic Beaver) - Qt 5 build
  • 22.04 LTS (Jammy Jellyfish) - Qt 6 build
  • 22.10 (Kinetic Kudu) - Qt 6 build

  The reason we don't generate deb packages for 20.04 LTS (Focal Fossa), is because it doesn't provide Qt 6 packages (yet?), so instead, users of that distro can just use the deb package from Ubuntu 18.04, which should work just fine.

  Also, the reason we generate two deb packages for the Qt 6 build, is because, apparently there have been some ABI changes in between Qt 6.2 (present on Ubuntu 22.04) and 6.3 (present on Ubuntu 22.10) releases, and because we make use of private Qt headers, we probably can't just build against Qt 6.2 and expect everything to work properly when we run against Qt 6.3 (maybe).

• I removed leftover files that were used for deb packaging (in packaging/linux/debian)

• I added a bunch of common variables in CMakeLists.txt (e.g. app author's name, email, website, this git repository...), and I used them to configure some files directly from CMake, which is very helpful to avoid duplicating this information.

For more details, please check each commit's description.

[nuttyartist]

I think we should merge this (if it all looks good) & create a new release with the latest changes (windows default native decorations & font resizing fixes), so we can create a debian package. We could call the release 2.1.1? @nuttyartist

I think if we want to release at such a fast iteration pace we should at least automate:

• Signing on macOS
• Release page content
• Uploading binaries with correct name changes to the release
• Changing UPDATES.json file

Otherwise, it's an annoying number of manual steps each time

But overall I'm down for releasing 2.1.1

EDIT: Whenever @guihkx sufficiently solves the .deb related stuff.

[guihkx]

Whenever @guihkx sufficiently solves the .deb related stuff.

In my opinion, the issue is as 'solved' as it can be: We have to build different debs for different distros....

I think if we want to release at such a fast iteration pace we should at least automate:

I can try to work on macOS signing after I work on building rpm packages too, which should be easier for me since I'm more familiar with Linux.

I noticed you have two pages on your website for openSUSE and Fedora packages, so I'm thinking of building two rpm packages for the oldest (yet still supported) releases of openSUSE and Fedora. Does this sound good?

[bjorn]

Maybe it's just my opinion, but I feel like the Flatpak release already sufficiently covers Fedora, especially after https://www.fedoraproject.org/wiki/Changes/UnfilteredFlathub (Fedora 38). On openSUSE it appears Flatpak is not enabled by default, but it can be quite easily installed, so it may be covered as well.

(but at the very least https://www.get-notes.com/linux-download should be updated to link to the Notes Flatpak as well)

[guihkx]

I kind of agree. Although, at the same time, adding RPM support at this point seems very easy. And there are people who would prefer installing 'native' rpm packages, instead of having to install the rather huge Flatpak KDE runtime we use.

[guihkx]

Fixed a couple of small issues related to CI.

@nuttyartist I think this is ready to be merged now (unless you guys have other questions/concerns).

[nuttyartist]

@guihkx Awesome, feel free to merge.

RPM support sounds good to me 👍

I can try to work on macOS signing after I work on building rpm packages too, which should be easier for me since I'm more familiar with Linux.

Alrighty, whenever you're ready I'll upload all the appropriate secrets. The signing and notarization scripts should be fairly easy to add.

(but at the very least https://www.get-notes.com/linux-download should be updated to link to the Notes Flatpak as well)

Where's the link for the generated Flatpack?

[guihkx]

Where's the link for the generated Flatpack?

We could generate our own Flatpak package and put there, but in order for users to get auto-updating features we'd have to set up our own Flatpak repository, which IMO doesn't make much sense.

I'd recommend providing a link to the Flathub store: https://flathub.org/apps/details/io.github.nuttyartist.notes, or steps using the command line:

$ flatpak install io.github.nuttyartist.notes

Flathub provides some badges you can use too: https://beta.flathub.org/badges

Or, if you need just an icon, you could use this vector: https://beta.flathub.org/favicon.svg (you probably have to paint it black on your own, though)