Update package dependencies for Debian 12+ and Ubuntu 22.10+

[rcalixte]

• Fixes Libraries libwxbase and libwxgtk3 are deprecated in Debian 12 - unable to install the provided .deb file #1674
• Fixes package install fails on debian trixie #1662

[federico-terzi]

Hey @rcalixte! Thanks for the help :) (and sorry for the late reply)

The PR looks good, but we also need to update the CI scripts/dockerfile to include the updated packages: https://github.com/espanso/espanso/blob/dev/.github/scripts/ubuntu/Dockerfile

I'm wondering if there's a way we can create a deb package that is compatible with ubuntu 22+ and <22, any ideas?

[rcalixte]

Hey @rcalixte! Thanks for the help :) (and sorry for the late reply)

No need for apologies!

The PR looks good, but we also need to update the CI scripts/dockerfile to include the updated packages: https://github.com/espanso/espanso/blob/dev/.github/scripts/ubuntu/Dockerfile

I'm wondering if there's a way we can create a deb package that is compatible with ubuntu 22+ and <22, any ideas?

This is using 18.04 as the base image and therefore will only have 18.04 repositories available. We would need to create a new Dockerfile for either 22.10+ (or wait until the next LTS in a few months). But the resulting .deb file should be compatible with both versions since the package name changed but the underlying library is mostly the same? The local distribution would be able to handle package dependency resolution using the repositories that are available.

Is there a way to test a build against this pull request?

[rcalixte]

@federico-terzi If you can fix the build issues in the source repository, I can rebase the forked repository with the changes and test a build with these changes. I tried running the build and there are issues with some of the Rust components but once they are resolved, we can reliably test the results before merging. Let me know if this sounds like a good plan!

[federico-terzi]

@rcalixte I'll try to do it in the upcoming week :)

[federico-terzi]

@federico-terzi If you can fix the build issues in the source repository, I can rebase the forked repository with the changes and test a build with these changes. I tried running the build and there are issues with some of the Rust components but once they are resolved, we can reliably test the results before merging. Let me know if this sounds like a good plan!

Hey @rcalixte :) Build errors on the dev branch should be fixed, so feel free to proceed whenever you have the chance :)

Thanks for your help!

[rcalixte]

@federico-terzi I was able to get it working. I tested both x11 and Wayland packages on Ubuntu 22.04 and Debian 12. The fix ended up being to remove the $auto keyword from the Cargo.toml file (for now?). The $auto keyword made cargo-deb add hard-coded dependencies that would only be for one or the other. So I pulled out the resulting dependencies and removed that keyword.

The release page with the deb build assets is here until the fork is deleted at some point. You can download and test with those.

Essentially, this ended up being a tradeoff for simplicity. The other option is to rework the entire build process to support both package variants until the older ones are end of life. I would lean toward waiting for the end of life for the older distributions and then updating the Cargo.toml to re-add the $auto keyword once it would be safe to do so. This means only having to do the change to the build process once and in the future with the advantage of proper planning. Provided that the dependencies don't change too much, this isn't a bad option.

[AucaCoyan]

Looks great to me! Great job!
Thank you 🙏🏼

[federico-terzi]

Thanks! Seems to work correctly on Ubuntu 20 as well, good to go