Pre-built binary for openvpn3 client for the new stable release of Debian (version 12 codename bookworm)

[jim-barber-he]

The latest Debian stable release came out on the 10th of June 2023.
Currently there is no pre-built openvpn3 Debian package built for the bookworm distribution.
This is a request for adding a new package to support this since the other .deb packages have dependencies on packages that are too old.

[mschlachter]

I contacted support about this and they told me it's planned for the v21 release. I would love to have a timeline for when this will be available if possible.

[dsommers]

This is not a promise. But I do hope I can manage to have a v21 release out by end of August/early September. This will definitely include Debian 12 builds. It is holiday season now, so not much will happen in July.

[samiramer]

Hey @dsommers do you have an update on the release timeline? This would be a lifesaver.

[samiramer]

Related to #201 and #171

[dsommers]

The v21 release has been delayed due to work related to solve #171 as well as some issues reported in the Core library by our internal QA. Hopefully a v21 for stable distribution releases (aka LTS distros, Debian, Ubuntu LTS, RHEL/CentOS) will be ready for internal QA within 2 weeks. Since #171 has now been taken out of the v21 release, I'm already wrapping up the last outstanding issues to get a proper build and packaging done. Once QA has approved the release, it will be shipped.

The v21 release will ship with an updated OpenVPN 3 Core library, which is currently going through QA now. Even though issues found by QA in this library has so far had a very small impact on OpenVPN 3 Linux (it is also used in OpenVPN Connect), there are a still a few potential issues which might affect this project as well.

[bhack]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904044

[Drizzt321]

@dsommers any further work on v21? I can muddle through with old openvpn2 client, but the v3 would be great to be able to use.

[dsommers]

@Drizzt321 The v21 is going through QA these days. If all goes well, end of the month is the main goal for the final release.

I'm pushing out fixes needed for this release in the releaseprep/v21 branch.

[dsommers]

@mschlachter @jim-barber-he @samiramer @Drizzt321 I've attached here the latest QA build for Debian 12. Feel free to test it if you want. Any feedback would be valuable.

openvpn3_0-20230919git6361bd5-1+bookworm_amd64.deb.gz

Since GitHub is picky about such attachments, you need to gunzip this file before running:

 apt install ./openvpn3_0-20230919git6361bd5-1+bookworm_amd64.deb

[bhack]

@mleeman is also preparing a regular/official Debian package at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904044#27

[mleeman]

Dang, busted :-P

I've added some comments in the ticket, the highlights are:

1. The debian builders do not like git submodules (no network access). In order to avoid having to recompress the releases; I decided to make 2 packages: openvpn3 (library) and openvpn3-linux (client). The package names match the repository names; this allows easy maintenance with git-buildpackage when a new release is tagged
2. I have added pkg-config support in openvpn3 for better support in the client compilation.
3. Minor patches are applied to avoid git and git submodule checkout/update
4. I need to add a binary conflict to openvpn3 to avoid problems with ppl that have both repos enabled

These should work for amd64/bookworm or newer; I have a compilation issue with bullseye that I need to figure out (not much of a C++ expert, got stuck at C/glib myself).

/usr//include/openvpn/client/ovpncli.hpp:571:5: warning: inline variables are only available with ‘-std=c++17’ or ‘-std=gnu++17’

i386 compilation is also failing, didn't look into that one either.

Just checkout master and run fakeroot dpkg-buildpackage --no-sign; sudo debi

Feel free to comment, review
https://salsa.debian.org/televic-team/openvpn3
https://salsa.debian.org/televic-team/openvpn3-linux

[dsommers]

@mleeman That's really cool you're looking into this!

In regards to i386 ... There are some issues on some of the C++ templates converting between C++ data types to D-Bus data types which is not really happy on 32-bit platforms. Since the wast majority of users are on 64-bit platforms, this has not been a high priority to resolve.

The documentation need to be updated also, the minimum C++ standard now will be C++17; this is due to the OpenVPN 3 Core library moved to that a while back. Further, the glib2 refactoring for #171 will also require C++17.

In regards to source code, we will always publish source code as tarballs as well; which includes everything needed to build with ./configure. The v20 is pushed out here:
https://swupdate.openvpn.net/community/releases/openvpn3-linux-20.tar.xz
https://swupdate.openvpn.net/community/releases/openvpn3-linux-20.tar.xz.asc

If you want, I can provide a similar development source tarball for the binary posted a bit earlier today.

Please reach out to me if you see any changes on our end to make the packaging better and/or smoother. Ideally we should not need to ship our own builds as a third-party repos. And this goes both for potential packaging efforts of the OpenVPN 3 Core library as well as the OpenVPN 3 Linux project.

In regards to packaging, lintian will complain about D-Bus policies being too broad. I discussed a missing feature with the upstream "dbus-daemon" developers some years ago, and got acceptance for the send_destination_prefix support. IIRC, that arrived in dbus-daemon-1.14, but I'm uncertain about dbus-broker support. This is basically the main detail to get rid of the lintian complaints.

[mleeman]

To me, it does not really matter; packaging follows (as much as possible) upstream.

I have mirrored the packaging structure on the git repo; so if you tag your release in github, I can fetch the tarball from there.

$ cat debian/watch 
version=4
opts=filenamemangle=s/.+\/v?(\d\S+)\.tar\.gz/openvpn3-$1\.tar\.gz/ \
  https://github.com/openvpn/openvpn3/tags .*/v?(\d\S+)@ARCHIVE_EXT@

If you prefer to have full/integrated tarballs that you release on your website, I can change the watch files to match.

I have indeed added a number of lintian-overrides (needs to be reviewed over time), but we have a working solution atm.

As for patches, I'll send the ones that are valuable to the mailing list once the dust settles.