search

hannesm / jackline

minimalistic secure XMPP client in OCaml
BSD 2-Clause "Simplified" License
251 stars 20 forks source link

(WIP) Initial minimalistic Debian packaging #208

Closed mato closed 2 years ago

mato commented 4 years ago

This is a counter-proposal to #206, with the following overall goals:

  1. As minimalist as possible, i.e. only uses dh/debhelper, no need for git-buildpackage.
  2. The Debian package build must be as automated as possible, and must NOT rely on manual steps on the build system. An OPAM switch with all dependencies must be built from scratch. This will also allow us to migrate to orb for Reproducible Builds in the future.
  3. The Debian package build must work from a "clean slate", i.e. a standard, clean Debian system/chroot/container with only the Build-Depends from debian/control installed.

Status

  1. Done.
  2. Works, with some hackery in DH_OPTIONS and debian/source/options to allow us to create the OPAM switch under debian/.
  3. Partly done, needs work.

Bulding the Debian package

See https://github.com/hannesm/jackline/pull/208#issuecomment-587081505.

Notable differences from #206

  1. The built package uses the recommended versioning scheme for unreleased upstream packages. See Source: Section 2.6.
  2. Source package format is 3.0 (native).
  3. Additional fixes, e.g. debian/copyright, etc. to pass all lintian checks except binary-without-manpage.

TODO

  1. [x] The build target in debian/rules should (safely) depend on x-prepare, i.e. debian/rules x-prepare should not be required as a manual step.
  2. [x] It would be good to have the package version reflect the git commit used, at least until such a point as jackline gets real releases. Something like 0~YYYYMMDD+g1234567. At the same time, we could update the timestamp in debian/changelog. This should be possible by generating debian/changelog from a template. Edit: Done, but conflicts with (1) above since without a debian/changelog present a bunch of the Debian tooling gets confused.
  3. [x] Currently does not work with stock opam in Debian due to solver problems; I've seen this happen before, need to track down the upstream issue(s). Edit: See further comments, workaround in place.
  4. [x] Test in a Docker container and/or pbuilder or similar.
  5. [ ] Add to Travis, so that the DEB build process is tested as part of CI.

/cc @hannesm @cfcs

verbosemode commented 4 years ago

It seems like aspcud is broken in the current Debian 10 Buster stable release. The Opam version in Debian is 2.0.3, but the package relies on aspcud instead of using the internal solver. Anil and Louis had commented on the Debian bug tracker about the situation. Unfortunately the fix for Opam hasn't landed in stable yet.

The only viable solution currently is to use mccs as solver.

I've managed to build the Debian package on an almost clean VM, based on the Vagrant "debian/contrib-buster64" box. It only had build-essential already installed on top of the minimal base system. Only "main" was enabled in the sources.list.

After that I've installed the build dependencies:

apt install opam devscript libgmp-dev mccs

Then I've added --solver=mccs to all opam commands in the debian/rules file (I'm sure there is a nicer way. I don't have a clue about Makefiles :D). The diff is here.

And last but not least, I've followed your instructions and had an installable Debian package afterwards.

mato commented 4 years ago

Hi @verbosemode,

It seems like aspcud is broken in the current Debian 10 Buster stable release. Anil and Louis had commented on the Debian bug tracker about the situation. Unfortunately the fix for opam hasn't landed in stable yet.

Indeed, that was the bug I was thinking of. Thanks for the pointer.

The only viable solution currently is to use mccs as solver.

I have some ideas about possible fixes that might be acceptable for Debian stable. Will discuss them in the above issue, and/or open a new Debian bug as #908203 is fixed in unstable and archived.

I've managed to build the Debian package on an almost clean VM, based on the Vagrant "debian/contrib-buster64" box. It only had build-essential already installed on top of the minimal base system. Only "main" was enabled in the sources.list.

Great, thanks for testing that!

After that I've installed the build dependencies:

apt install opam devscript libgmp-dev mccs

Then I've prefixed all opam commands with --solver=mccs in the debian/rules file (I'm sure there is a nicer way. I don't have a clue about Makefiles :D). The diff is here.

I've pushed a slightly different solution in c470d34, exporting OPAMEXTERNALSOLVER in debian/rules to force the same behaviour.

And last but not least, I've followed your instructions and had an installable Debian package afterwards.

That's good news, and confirms that this approach for building Debian packages works. Thanks.

mato commented 4 years ago

So, in 1e8a60c I've re-worked things yet again to always use an own OPAMROOT, plus some more tweaks to make the build work with pbuilder and whalebuilder. The package build process is now a bit different:

  1. First, build the Debian source package: a. git clone -b debian git://github.com/mato/jackline b. cd jackline && debian/rules x-source This will generate debian/changelog to match the Git version and produce a jackline_<VERSION>.dsc and jackline_<VERSION>.tar.xz in the parent directory.
  2. You can now build the Debian binary package using normal tooling, from the source package: a. With plain debuild: dpkg-source -x jackline_<VERSION>.dsc && cd jackline_<VERSION> && debuild -us -uc b. With pbuilder: sudo pbuilder build --use-network yes jackline_<VERSION>.dsc c. With whalebuilder: whalebuilder build --network bridge <BASE_IMAGE> jackline_<VERSION>.dsc
  3. Alternatively, a plain debuild -us -uc for an "in tree" build sould also just work after running debian/rules x-source; this is useful for developing the package itself, but does not guarantee that the build is 100% clean.
mato commented 4 years ago

As of e2f48dd this now builds Debian packages on Travis CI. However, please don't merge anything until I give the green light -- still deciding on the best way to e.g. name/version the package in order to facilitate uploading to an APT repository.

hannesm commented 2 years ago

thanks, a different approach (using dpkg-deb and orb) has been merged as 459cbe7 -- and binary packages will show up soon on https://builds.robur.coop