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.

[mleeman]

FYI, there is some low hanging fruit (spelling errors) that got picked up by the debian tooling

https://mentors.debian.net/package/openvpn3-linux/
https://mentors.debian.net/package/openvpn3/

    authentification authentication [usr/bin/ovpncli]
    authentification authentication [usr/lib/x86_64-linux-gnu/_ovpncli.so]
    laoding loading [usr/bin/ovpncli]
    laoding loading [usr/lib/x86_64-linux-gnu/_ovpncli.so]

and

    Adress Address [usr/libexec/openvpn3-linux/openvpn3-service-netcfg]
    Transfered Transferred [usr/libexec/openvpn3-linux/openvpn3-service-configmgr]
    Transfered Transferred [usr/libexec/openvpn3-linux/openvpn3-service-sessionmgr]
    Unkown Unknown [usr/sbin/openvpn3-admin]
    authentification authentication [usr/bin/openvpn3]
    authentification authentication [usr/libexec/openvpn3-linux/openvpn3-service-client]
    laoding loading [usr/bin/openvpn3]
    laoding loading [usr/libexec/openvpn3-linux/openvpn3-service-aws]
    laoding loading [usr/libexec/openvpn3-linux/openvpn3-service-client]
    occured occurred [usr/sbin/openvpn3-admin]
    subsciber subscriber [usr/bin/openvpn3]
    subsciber subscriber [usr/sbin/openvpn3-admin]
    unkown unknown [usr/libexec/openvpn3-linux/openvpn3-service-client]

[dsommers]

• Source tarball
  While I see the simplicity of pulling the tarball from github, it is not a proper distribution tarball; it's a git snapshot not including any dependencies. The tarballs we publish will have all dependencies and those tarballs are what is being used across all our builds - including Fedora Copr builds (and later upstream Fedora packaging). These tarballs are the one used through our QA processes and should also be prepared to comply to reproducible builds requirements; that the built binary will be identical - as long as the distribution and compiler chain is the same. And the authenticity of these tarballs can be verified through our PGP signature.

• Packaging of OpenVPN 3 Core library is dubious
  It is primarily a source header-only library. While it can produce a libopenvpn3.so in some cases; that is only used for clients not written in C++ where a glue layer is needed - and it depends on swig to work. OpenVPN 3 Linux does not depend on a shared library (and probably won't go that path). Packaging OpenVPN 3 Core library should probably just be a -dev package with only the header files from ./client, ./doc and ./openvpn.

• I'll look at all the typos and such; that should be fine to get fixed.

[dsommers]

@mleeman Two quick patches fixing the openvpn3-linux typ0s ...

• https://codeberg.org/OpenVPN/openvpn3-linux/commit/2755c95728cae3bfe347c4153d6d4f959d02a4ca
• https://codeberg.org/OpenVPN/openvpn3-linux/commit/8881bf35c835c7deab439c87a7efc09444caef84

These are queued up for the coming v21 release.

[mleeman]

fine with me, I will adjust the client to use your published snapshots.

Is there a page where the index can be queried of the releases, any other URL but https://swupdate.openvpn.net/community/releases/openvpn3-linux-21.tar.xz does not seem to work.

the openvpn maintainers use this page:

https://openvpn.net/index.php/open-source/downloads.html 

But openvpn3 is not listed there.

$ cat Development/salsa/openvpn/debian/watch 
version=4
https://openvpn.net/index.php/open-source/downloads.html \
(?:|.*/)openvpn(?:[_\-]v?|)(\d[^\s/]*)\.(?:tar\.xz|txz|tar\.bz2|tbz2|tar\.gz|tgz)

[dsommers]

@mleeman Good point on the publicity aspects of new releases. We will look into how to do that better. Perhaps a quick solution for now would be to have use this file I just now pushed out: https://swupdate.openvpn.net/community/releases/openvpn3-linux.latest

If you want a different layout here, we can probably script that a bit better.

The version scheme is also fairly simple. I'm going to use three "release categories":

• stable releases: v20 - openvpn3-linux-20.tar.xz{,.asc}
• beta releases: v19_beta - openvpn3-linux-19_beta.tar.xz{,.asc}
• development releases: v22_dev - openvpn3-linux-22_dev.tar.xz{,.asc}

Stable releases will be the only releases which might have a minor version, like v20.1. This is only happening where the next stable release is "too far away" and there is an important bug or security fix needed. In this case, the version strings will be:

• stable hotfix: v20.1 - openvpn3-linux-20.1.tar.xz{,.asc}

This openvpn3-linux.latest could perhaps be extended to have a "release category" tag as well. Like stable:20 and development:22_dev. With a "stable hotfix", the stable: line would be stable:20.1.

In a Debian and Ubuntu LTS context, I think it would be best stay on the stable releases in the longer run. For Ubuntu non-LTS, the beta releases might be applicable. The development builds might be best being a separate repository we update more frequently.

Let me know what you think about this.

[mleeman]

• Starting from your snapshot and by removing all the patches (that I had previously added) gives a clean compilation, so your release tarball is an excellent starting point. If you prefer this route, then this is the one we'll be taking. It's easy and it's clean.
• I agree that only the stable releases should come in Debian, it's fine if someone uses the build infrastructure to experiment, but that is outside of the scope of Debian itself.
• One thing I was thinking about over the weekend is the name of the package. At the moment it is openvpn3 or openvpn3-linux. When comparing this to the openvpn2 releases, a better name might be openvpn3-client, since (AFAIK) it only contains the client part. Nothing changes at your end, just on mine.

Let me know what you prefer and I'll reset my salsa branches to your to the release tarball instead of the one generated from github.

[dsommers]

Regarding 1), that sounds like the best approach to me too; I generally would like package maintainers to add as few additional patches as possible - get them upstream first. (I'm also a Fedora package maintainer, so I have some packaging experience as well)

We are aligned on the "stable" versions in Debian, so nothing more to discuss there.

Packaging names ... okay, so this is "complicated". But it is related to some project names:

• "OpenVPN 3 Linux" (openvpn3-linux) is this project; the (primarily, but not necessarily restricted to) Linux implementation of the "OpenVPN 3 generation"
• "OpenVPN 3 Core Library" (openvpn3) is the implementation of the OpenVPN protocol as the 3rd generation.

Currently the openvpn3-linux project has only implemented the client side - but I would like to have a server side implementation too in the future. In the Fedora packaging, there are more sub-packages:

• openvpn3
  Provides the generic components; configuration manager (openvpn3-service-configmgr), log service (openvpn3-service-logger), network configuration (openvpn3-service-netcfg), the Python module [1], the openvpn3and openvpn3-admin CLI tools, the openvpn3-autoload (deprecated, but will be shipped at least until next summer - RHEL 7 EOL), as well as some support files for all of this and some docs.
• openvpn3-client
  Provides the client side components: The client services (openvpn3-service-backendstart, openvpn3-service-client), the openvpn2 and openvpn3-as CLI tools and the openvpn3-systemd helper and the [email protected] systemd unit, plus other related support files, man pages and such
• openvpn3-addon-aws -
  Contains an optional add-on component (for AWS-VPC integration), provides the openvpn3-service-aws and related support files and man page
• openvpn3-selinux
  SELinux policy to confine the some of the services and allow D-Bus daemon to pass access to the tun/dco interfaces between two D-Bus enabled processes.
• openvpn3-devel
  Contains some generated files which is installed under /usr/include/openvpn3 ... and they are not related to the Core library itself.

The intension behind these package names is that

• openvpn3 itself is what is needed to run either a client or a server functionality. It does not relate to the OpenVPN 3 Core library (header) files, as that is not an end-user functionality.
• openvpn3-client need to depend on openvpn3, since that component builds on the openvpn3 basic functionality to provide the client functionality. This is the same rationale as for the openvpn3-addon-aws package.
• When a server functionality will come, that would ideally be an openvpn3-server sub-package; which can be installed without the openvpn3-client package installed - and vice versa.

If we would package the OpenVPN 3 Core library, that should be named libopenvpn3-devel or something like that. It does not provide an end-user product, but a library to implement the OpenVPN protocol. This code does contain a reference test client, but that is not something you would put into production as is.

The reason the Debian packaging does not have such splits as the Fedora is that I heard from a Debian maintainer many years ago that Debian generally prefers to avoid sub-packages and only use them when strictly needed. In the Fedora land, sub-packages are more often used to split out functionality which does not need to be installed to have something working. The -selinux package is also more a common way how to clearly indicate that this project will touch the SELinux policy on the system.

But you are of course free to do package this project in Debian as you see fit best with the Debian packaging guidelines.

[mleeman]

Debian packaging (in general) does tend to use smaller sub packages. What I would propose is to:

1. start by packaging openvpn3-linux into a package openvpn3-client. It describes clearly what it is: a client for openvpn3 functionality. For starters, I'd bundle all the tools that are shipped with openvpn3-linux.
2. it's great that there is a server component coming. At that point a bit more work will be needed; though I think that the starting point will probably not be the tarball we discussed before; but a number of different sub releases. When this is the case, we'll probably have packages with names like: libopenvpn3-dev (including the version to avoid conflicting with /usr/include/openvpn) and libopenvpn3 that are dependencies for openvpn3-client and openvpn3-server. To some extent, this was they way I started working; but in retrospect (and until there is a server component,) it is probably overkill.

This way, the packaging names match to some extent the ones you defined for rpm packaging. As the need arises and if it is useful, I can split off components into different packages. At the moment, I would focus on getting openvpn3 into Debian/Ubuntu as is, while staying very close to your releases: it give you a much better level of control on what you want to release and in what form.

How does this sound?

[dsommers]

That sounds great! Currently the packages (and docs) in our provided releases uses the openvpn3 package name. There are also some docs for CloudConnexa which also needs to be updated.

Perhaps we should move our (OpenVPN Inc provided) packaging to also use the openvpn3-client with a "Provides" openvpn3 for a short time as we move forward? It would be great if the packages we provide will be compliant with the upstream Debian ones and not causing conflicts in any way.

[flichtenheld]

In openvpn2 we use the official Debian/Ubuntu packages as base and update from that as needed for the Community releases. Once there is official Debian packaging for openvpn3 we should probably go to a similar model.

[mleeman]

I have an initial version, most of the code could be re-used

https://salsa.debian.org/televic-team/openvpn3-client

One lintian error popped up that will probably require me to re-package the code:

E: openvpn3-client source: license-problem-convert-utf-code [openvpn3-core/openvpn/common/unicode-impl.hpp]
N: 
N:   The following file source files include material under a non-free license from Unicode Inc. Therefore, it is not possible to ship this in main or contrib.
N:   
N:   This license does not grant any permission to modify the files (thus failing DFSG#3). Moreover, the license grant seems to attempt to restrict use to "products supporting the Unicode
N:   Standard" (thus failing DFSG#6).
N:   
N:   In this case a solution is to use libicu and to remove this code by repacking.
N: 
N:   Please refer to Bug#823100 for details.
N: 
N:   Visibility: error
N:   Show-Always: no
N:   Check: cruft
N: 
N:

Another one I need to look into, seems to be some data that is used during a test

E: openvpn3-client source: source-is-missing [openvpn3-core/test/unittests/comp-testdata/sum]

[dsommers]

We need to come up with a solution for that license issue in the OpenVPN 3 Core library. It's essentially a public domain license, which shouldn't really be a problem - but legalese is always annoying.

that comp-testdata/sum is essentially just a random binary which is only used for compression testing in the Core library unit tests. That file should also be replaced by some real random binary data and not a binary executable (which in this case is even for the Sparc CPU arch).

Both of these issues are coming from the OpenVPN 3 Core library.

[mleeman]

I am searching a bit and have found e.g.

https://llvm.org/doxygen/ConvertUTF_8h_source.html

it seems to be the same source and llvm is in main. The warning states:

N:   This license does not grant any permission to modify the files (thus failing DFSG#3). Moreover, the license grant seems to attempt to restrict use to "products supporting the Unicode
N:   Standard" (thus failing DFSG#6).

while the header file says (copy):

17  * Unicode, Inc. hereby grants the right to freely use the information
 18  * supplied in this file in the creation of products supporting the
 19  * Unicode Standard, and to make copies of this file in any form
 20  * for internal or external distribution as long as this notice
 21  * remains attached.

The file in llvm has a more recent copyright:

/*===--- ConvertUTF.h - Universal Character Names conversions ---------------===
 *
 * Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 * See https://llvm.org/LICENSE.txt for license information.
 * SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 *
 *==------------------------------------------------------------------------==*/
/*
 * Copyright © 1991-2015 Unicode, Inc. All rights reserved.
 * Distributed under the Terms of Use in
 * http://www.unicode.org/copyright.html.
 *
 * Permission is hereby granted, free of charge, to any person obtaining
 * a copy of the Unicode data files and any associated documentation
 * (the "Data Files") or Unicode software and any associated documentation
 * (the "Software") to deal in the Data Files or Software
 * without restriction, including without limitation the rights to use,
 * copy, modify, merge, publish, distribute, and/or sell copies of
 * the Data Files or Software, and to permit persons to whom the Data Files
 * or Software are furnished to do so, provided that
 * (a) this copyright and permission notice appear with all copies
 * of the Data Files or Software,
 * (b) this copyright and permission notice appear in associated
 * documentation, and
 * (c) there is clear notice in each modified Data File or in the Software
 * as well as in the documentation associated with the Data File(s) or
 * Software that the data or software has been modified.
 *
 * THE DATA FILES AND SOFTWARE ARE PROVIDED "AS IS", WITHOUT WARRANTY OF
 * ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
 * WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
 * NONINFRINGEMENT OF THIRD PARTY RIGHTS.
 * IN NO EVENT SHALL THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS
 * NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL
 * DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
 * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
 * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 * PERFORMANCE OF THE DATA FILES OR SOFTWARE.
 *
 * Except as contained in this notice, the name of a copyright holder
 * shall not be used in advertising or otherwise to promote the sale,
 * use or other dealings in these Data Files or Software without prior
 * written authorization of the copyright holder.
 */

Maybe there has been an update since the 2001-2004 version that is in the core lib?

Another reference:
https://sources.debian.org/src/desmume/0.9.11-2/src/utils/ConvertUTF.h/

[dsommers]

Good find! Thanks a lot for your research! Will dig into this and find a better licensed version.

This is anyhow something needed to be tackled in the openvpn3 repository and will need to come in the next OpenVPN 3 Core release before pulling it into this (openvpn3-linux) project.

[bhack]

A bit unrelated:
do you think that this package is going to conflict with network manager openvpn in distros?
See #46

[mleeman]

took some time to get feedback on Debian, I am now processing it.

[mleeman]

https://salsa.debian.org/erpel/openvpn3-client/-/blob/master/debian/patches/0001_openvpn-to-_openvpn-user.patch

[mleeman]

I have to remove the unicode-impl.hpp because of the copyright, by pulling and adjusting the one from llvm this seem tackled.

That one has a more recent copyright and should not be a problem for DFSG

https://salsa.debian.org/erpel/openvpn3-client/-/blob/master/debian/patches/0002_import-unicode-impl-from-llvm.patch

[alee-ntap]

@mleeman May I know the status of the package? It seems to me the original upstream tarball contains the non-DFSG code and you provided a DFSG-free replacement as a Debian package patch. So that it's still blocks your package to upload into Debian. Please correct me if I'm wrong.

[mleeman]

As far as I know, the package can be uploaded to Debian, I don't think anything should block the upload. The DFSG patch was from another package that is free (in essence, a newer licence header).

The only thing I need, is a sponsor; I have some ppl I could ask, but I preferred 'to follow the process' over calling in some favour.

There was someone from OpenVPN that said he'd sponsor, but haven't heard from him after I asked.

I've uploaded it twice already to mentors, but it gets stuck there.

[alee-ntap]

As far as I know, the package can be uploaded to Debian, I don't think anything should block the upload. The DFSG patch was from another package that is free (in essence, a newer licence header).

The package will be reject directly from NEW if the original upstream tarball contains any non DFSG code. Please upstream your DFSG-free patch instead. And then roll a git release tarball or wait for a new upstream release for the Debian package upload.

The only thing I need, is a sponsor; I have some ppl I could ask, but I preferred 'to follow the process' over calling in some favour.

There was someone from OpenVPN that said he'd sponsor, but haven't heard from him after I asked.

I am surely can find you sponsor once you solved all the issues in the package. The upstream tarball should no contains any non-DFSG license. And fixed all the issue that lintian detected on mentors:
https://mentors.debian.net/package/openvpn3-client/
Highly suggest to use DEP5 format for the debian/copyright file. So that can be parse by montors.

I've uploaded it twice already to mentors, but it gets stuck there.

And I also highly recommend to use the source package name matches with upstream tarball unless it has been taken by another package in Debian. This helps you to keep your debian/watch file simple. You probably should update the package name in the ITP #904044 as well.

[mleeman]

It's been a couple months since I worked on it, but AFAIK

1. The code has been repackaged to exclude the non-dfsg code
2. The watch file is not there because OpenVPN does not provide an indexable web site: there is no way that I know of that I could scan for new releases. I checked this off with upstream, and there was word that it was something that would be considered in the future
3. The update of the header file that has the updated copyright is something that upstream is considering; but it needs to be integrated in an upstream release and when the problem was raised, they were too far in their test cycle.
4. The package name was renamed with a clear purpose: upstream calls it 'openvpn3-linux'. I do not have a problem with the naming; but the release openvpn3-linux is a combination of to parts: a library part and a client part that is released as a single archive. As far as I understood the longer term goals of upstream, the 'library' part is intended to be re-used for a server component in the future. With that reasoning, I concluded that 'openvpn3-client' would reflect the reality better than 'openvpn3-linux', especially when upstream might have an 'openvpn3-server' component and possibly s separate library release component.

It's true, I decided to keep on referencing the single and validated source release of upstream and leave the bundling to them. This is also the reason why I have not split it off at the moment: the library is only used by a single application (i.e.. openvpn3-client).

Picking openvpn3-client as a package is IMHO future proof and avoids creating transitional packages and reflects the reality better: contrary to openvpn2, openvpn3 only has a client component at the moment. openvpn3-client over openvpn3-linux has the benefit of clarity.

[dsommers]

And I also highly recommend to use the source package name matches with upstream tarball unless it has been taken by another package in Debian. This helps you to keep your debian/watch file simple. You probably should update the package name in the ITP #904044 as well.

Just beware that this is a bit "complicated".

Upstream projects:

• openvpn3 -> OpenVPN 3 Core Library (library implementing the OpenVPN protocol as a C++ library)
• openvpn3-linux -> Linux focused implementation of the OpenVPN 3 Core library, with the full config/session management stack

Package names used in the OpenVPN Inc provided packages:

• openvpn3 -> Base package, having the core functionality for the OpenVPN 3 Linux service stack and front-end tools
• openvpn3-client -> Provides the OpenVPN 3 client components (provides the pieces to connect to a server)
• openvpn3-selinux -> Provides SELinux policies for the OpenVPN 3 Linux stack for RPM packages (part of openvpn3 in .deb)
• openvpn3-devel -> Provides C header files for some constant values (part of openvpn3 in .deb)
• openvpn3-addon-aws -> Optional package, provides AWS VPC integration support

In the future, when efforts to provide an OpenVPN 3 based server implementation happens, that is expected to end up in an openvpn3-server package.

This was discussed with @mleeman a while back, and he decided to put most of this into the openvpn3-client package. I come from Fedora/RHEL packaging where more and smaller packages with a dedicated functionality is the normal approach, while Debian seems to go the opposite way, wanting as much as possible in a single package.

I won't object to to the Debian packaging policies, I'm sure they have valid reasons for their decisions and if Debian wants more into each package, sure, that's fine. But documentation wise, it would be good if the "client functionality" would be placed in the openvpn3-client package. That would then be consistent across distributions and easier for users to relate to.

[alee-ntap]

1. The code has been repackaged to exclude the non-dfsg code

Good to know.

2. The watch file is not there because OpenVPN does not provide an indexable web site: there is no way that I know of that I could scan for new releases. I checked this off with upstream, and there was word that it was something that would be considered in the future

Please temporary provide a lintian-override with the reason for debian-watch-file-is-missing.

3. The update of the header file that has the updated copyright is something that upstream is considering; but it needs to be integrated in an upstream release and when the problem was raised, they were too far in their test cycle.

Please update your patches in DEP-3 format with proper tags and address the reason to have these patches and link with open issue addressed in upstream.

[skip..]

Picking openvpn3-client as a package is IMHO future proof and avoids creating transitional packages and reflects the reality better: contrary to openvpn2, openvpn3 only has a client component at the moment. openvpn3-client over openvpn3-linux has the benefit of clarity.

Thank you for explain this. Now I understood why it's named openvpn3-client. Please update your ITP with the reason you mentioned here and make the openvpn3-client package name matches with the package name in Debian ITP Bug you want to closed in debian/changelog.

BTW, does any reason that the package sets Architecture: amd64 in debian/control?

Please fix or override lintian errors that detected in your latest upload on mentors and provide debian/upstream/metadata file. Also the pkg-config in build-depends has been superseded that was not detected on mentors.

[dsommers]

@alee-ntap

BTW, does any reason that the package sets Architecture: amd64 in debian/control?

Yes, there has been some challenges compiling it successfully on 32-bit CPU architectures. There are some challenges with the C++ templates ending up with the wrong and conflicting data types; iirc it was related to 32-bit vs 64-bit int and long data types.

This might change with the v22_dev work, where there is a brand new D-Bus integration where some if this code is changed and done a bit differently. But I'm not ready yet to lift the 32-bit exclusion. It needs to be thoroughly tested.

[alee-ntap]

@alee-ntap
Yes, there has been some challenges compiling it successfully on 32-bit CPU architectures. There are some challenges with the C++ templates ending up with the wrong and conflicting data types; iirc it was related to 32-bit vs 64-bit int and long data types.

In that case, we can specific more 64-bit architectures that Debian 13 will supported, eg:

Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x

[mleeman]

I did a test build locally with arm64 and that one seems to compile, we just assume that that the architectures above work too and let the debian builders veirfy them (takes me the better part of an hour to verify a architecture with muti-arch/pdebuild)/cowbuilder.

[dsommers]

The Fedora Copr builds we already do a similar set of architectures as @alee-ntap suggests. They all build fine, but I don't know if anyone uses it on those. We do have reports though that the arm64 works on the 64-bit capable RPi.

[alee-ntap]

I did a test build locally with arm64 and that one seems to compile, we just assume that that the architectures above work too and let the debian builders veirfy them (takes me the better part of an hour to verify a architecture with muti-arch/pdebuild)/cowbuilder.

I already tested it works in an arm64 VM. Let's get all the lintian error fixed and upload into Debian. Would you prefer to use mentors or just your package git repo on salsa for reviews?

[mleeman]

I already tested it works in an arm64 VM. Let's get all the lintian error fixed and upload into Debian. Would you prefer to use mentors or just your package git repo on salsa for reviews?

I don't mind where the reviews are as long I as I pick them up, but a detailed Debian specific review might be better off on salsa.

I uploaded a new copy, the watch warning is still there (even with the debian/source/lintian-overrides), added DEP3 headers (tnx, need to do that for another project too), DEP5 is on the back burner.

[alee-ntap]

I uploaded a new copy, the watch warning is still there (even with the debian/source/lintian-overrides), added DEP3 headers (tnx, need to do that for another project too), DEP5 is on the back burner.

I saw it's override correctly in your new upload:

Now only redundant-control-relation that you have two entries for libxml2-utils. That can be easily fixed by wrap-and-sort command from devscripts package.

Besides the lintian errors. Why does the debian/rules file has to specify these:

$(shell dpkg-buildflags --export=configure) --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE)

--disable-unit-tests \
--disable-build-test-progs \

[skip..]

$(EXTRA_ARGS)

?

[dsommers]

I would recommend to keep --disable-build-test-progs ... it avoids building lots of development test programs, not installed (and not really useful for end-users). That speeds up the compiling a bit. The unit-tests can be valuable as a check-point, if they are run later on in the build/packaging process.

[mleeman]

I either based my work on openvpn2 packaging or used work from @dsommers , I don't remember. In any case, I'll enable the unit testing (2 tests I see) and remove the unused variable.

make[5]: Entering directory '/home/marc/Development/salsa/openvpn3-client'
PASS: src/tests/unit/unit-tests
PASS: src/policy/syntax-check.sh
============================================================================
Testsuite summary for OpenVPN3/Linux 21
============================================================================
# TOTAL: 2
# PASS:  2
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================

The test-progs we leave out?

[alee-ntap]

I either based my work on openvpn2 packaging or used work from @dsommers , I don't remember. In any case, I'll enable the unit testing (2 tests I see) and remove the unused variable.

It's better to have the review on your git repo on salsa then. :D

The test-progs we leave out?

I think so. Unless it would be useful to provide in separate binary package eg: openvpn3-client-test-progs?

[dsommers]

I think so. Unless it would be useful to provide in separate binary package eg: openvpn3-client-test-progs?

There might be one or two programs here which might be handy in really low level debugging. But if you need this kind of debugging, then you most likely are already deep into the code itself - so you have these tools easily available in a local build. Most of these programs are more to test various internal APIs and was more useful in the early days of the implementation before all the APIs had settled. If any of these tests programs are useful for general testing, I tend to convert them into a unit-tests instead. I would just leave them aside for now.

In regards to the unit-test being disabled; yeah, we might have disabled that in the OpenVPN Inc packaging, as some of these tests depends on D-Bus and some systemd capabilities being available and functional. We do these builds inside docker containers where that is not the case, so the unit test would fail due to infrastructure issues. These tests are run elsewhere in our build infrastructure, as well as I'm running them regularly during development.

[alee-ntap]

@mleeman Great! You have mostly fixed all the issue that lintien detects. \o/
Let's fix the debian/copyright file. You made mistake in Source: field and I think you should add Comment: field as the source tarball has modified due to DFSG reason. More info for the fields you can find here:
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

I found more than one Authors in the git log. Please add them into the copyright list. And also add yourself and if any others into Files: debian/*.

Here are an example package that also License: AGPL-3+:
https://salsa.debian.org/java-team/pdfsam/-/blob/master/debian/copyright

And I highly recommend to use licensecheck to review the copyright,. I did that and surprisedly found there are a lot of info are missing in your debian/copyright file. You can find more details for copyright review tools here:
https://wiki.debian.org/CopyrightReviewTools

[alee-ntap]

$(shell dpkg-buildflags --export=configure) --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE)

I think this can be drop as Debhelper compatibility level 13 already handles that.

[mleeman]

Thanks for the review @alee-ntap , very much appreciated.

The licence is something that I need to get a hang of, the debian/* part was removed because someone else suggested me that it was not needed if I kept the debian/* directory under the same licence as upstream.

Files: *
Copyright: 2010-2023, OpenVPN Solutions LLC
License: AGPL-3

Files: debian/*
Copyright: 2023-2024, Marc Leeman <[email protected]>
License: AGPL-3

The only thing that would warrant a difference here is the dates because the upstream code was released in 2023, while we are still working on the rest.

In git log (salsa), I only see one name (mine), though the git commit might show a different e-mail. That should not matter, I think.

I am certain a lot of ppl have worked on the openvpn3 code itself; but shouldn't that be covered by the over arching copyright when released by upstream: if they state AGPL and covered with their company; does packaging need to provide more information, by extracting the authors from git?

The licensecheck is a nice tool, and I see indeed that some copyrights are missing in debian/copyright (.e.g autotools/generated files). Again, do we need to provide the licence information that is part of upstream (and in this case, generated files)? I cannot imagine that this package is the only one that would sin against this.

[alee-ntap]

The only thing that would warrant a difference here is the dates because the upstream code was released in 2023, while we are still working on the rest.

Right, so keep it as same as the example package will helps. :)

In git log (salsa), I only see one name (mine), though the git commit might show a different e-mail. That should not matter, I think.
There is not need to list multiple emails with the same person.

I am certain a lot of ppl have worked on the openvpn3 code itself; but shouldn't that be covered by the over arching copyright when released by upstream: if they state AGPL and covered with their company; does packaging need to provide more information, by extracting the authors from git?

Correct, as the ftp-master will check to ensure the copyright is completely listed and without any non-DFSG code and binary file. Or your package will get rejected. That will takes more time to get another sponsor upload.

The licensecheck is a nice tool, and I see indeed that some copyrights are missing in debian/copyright (.e.g autotools/generated files). Again, do we need to provide the licence information that is part of upstream (and in this case, generated files)? I cannot imagine that this package is the only one that would sin against this.

All the packages in Debian are required to list complete copyright due to Debian policy. And I found file in the vendor/ has copyright info are not listed. These are must listed in the copyright file. Also I haven't checked the binaries files, eg: .pdf and .png also needs to check and list the licenses.

I can easily find some examples on
https://codesearch.debian.net
You may search eg:

.png path:debian/copyright
.pdf path:debian/copyright

Hope that helpful.

[mleeman]

Back to the drawing board, some more work:

Hi

There are two license inompatibilities:
(A)GPL-3 and BSD-4-Clause-UC are incompatible (yes, I saw the comment,
but this makes the license either a custom one or possibly a
BSD-3-Clause)
GPL-2 and AGPL-3 are incompatible

AGPL is not suitable for non-network code, so at least debian/* should
get something else.

Your lintian overrides don't match what ftp-master still expects, see
all the errors.

The polkit maintainer just asked to reject new packages for shipping
legacy polkit pkla files.  So please remove the stuff from
/var/lib/polkit-1 and convert to the new-style rules.

Please drop all autoconf/automake generated and vendored files.  We've
just seen what this produces as problems.

There is vendored code, but also a dependency on the same library
(libasio-dev).

Some other remarks:
- Please use dh_installtmpfiles (rename debian/openvpn3-client.conf to
  .tmpfiles I think), enabled in debhelper compat 13
- You could use debhelper compat 14 directly and avoid some of the
  overrides in debian/rules, as it calls dh_installsysusers
- Preemptive architecture limits are not the way to go, please remove
  this list
- It contains DSA keys in /etc/openvpn3/awscerts, which a current crypto
  policy should not really accept
- There seems to be two distinct was to start it,
  openvpn3-autoload.service and [email protected], is this
  necessary?
- /var is not really for user config, but for state.
- Is /var/lib/openvpn3 supposed to be in the package or created via
  systemd-tmpfiles?  Currently I see both.

[schwabe]

Why is AGPL not suitable for non-network code? Sure the difference between AGPL and GPL only affects code that uses network but that does not make AGPL3 unsuitable for other code.

[mleeman]

@schwabe TBH, I do not know. One thing I've learnt when packaging this package; every different DD will give you different answers, especially for this software that has so many contribution from different corners.

I think, in this particular case, is to change the licence of the debian directory.

I have had a quick look and some other remarks are more technical so I can start working on those.

[mleeman]

It might be quiet about the topic of getting it in Debian, but sometimes I have to find some time to make the changes (or understand them) and getting things moving within Debian is another matter too; it just takes more time than anticipated.

I cannot remember that this was the case years ago...

[schwabe]

@mleeman to be honest that debian directory cannot be AGPL3 if the whole project is AGPL3 sounds ridicioulous and probalby been said by someone with little experience/knowledge in liceses. That would like saying, you have to put man pages under a different license in GPL projects since GPL has section about code and libraries and man pages are only text.

[mleeman]

FYI:

There are some minor spelling errors that lintian picked up:
https://salsa.debian.org/erpel/openvpn3-client/-/blob/master/debian/patches/0003_lintian-spelling-errors.patch?ref_type=heads