Building PPA Package for ESPResSo

[bishwash369]

Fixes #

Description of changes:

• Cherrypicked relevant code from https://github.com/RudolfWeeber/espresso/tree/debianization/debian
• Created a Launchpad account to build a PPA Package.
• Built a PPA package using GitHub Actions.
• modified the existing code for building and packaging.
• Successful build for Ubuntu versions of Jammy, Kinetic, and Lunar.
• Builds for Bionic and Focal were unsuccessful due to package dependencies.
• Link for PPA Packages: https://launchpad.net/~bishwash369/+archive/ubuntu/espressoppa/+packages

[jngrad]

Thanks for your work! I have a few general questions:

• can the workflow re-use the publish-ppa-package workflow directly from the marketplace to avoid code duplication?
  • using marketplace workflows helps a lot with code maintenance, security alerts, integration in the GitHub ecosystem, and allows us to give more credit to the authors of workflows
  • if the code duplication was required to extend the workflow functionality, we could propose these extensions upstream
• is there a way to control the CMake command that is invoked by the PPA build? This would be helpful to select which external features are enabled. Also, the default CMake command currently contains -DCMAKE_BUILD_TYPE=None, which emits a warning in our custom CMake functions, but in the future this warning might become a fatal error.
• is there a way to run the ESPResSo unit tests and python tests during the PPA build? This is the standard procedure on Fedora and OpenSUSE to block the release of broken ESPResSo builds. It helped us detect stealthy bugs that would only be triggered by very specific test cases due to floating-point precision errors and MPI communications errors.
• there are a few minor issues with Ubuntu package dependencies that I can take care of
• we officially no longer support 32bit architectures (e.g. i386) and Ubuntu versions older than 20.04; I would suggest you skip all architectures except for amd64
• the CMake package dependency issue that you see on Ubuntu 20.04 has a workaround that we use in our automatic build pipelines: we pip install a more recent CMake version as a regular user. I have never tried it in a packaging build system, though. It should not be an issue for the build, since CMake is just a dependency of the build process, and not of the package itself. However if the Pypi repositories are not accessible from within the build pipeline, then we cannot support the PPA on Ubuntu 20.04.