search

OpenVPN / openvpn3-linux

OpenVPN 3 Linux client
GNU Affero General Public License v3.0
558 stars 150 forks source link

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

Open jim-barber-he opened 1 year ago

jim-barber-he commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

samiramer commented 1 year ago

Related to #201 and #171

dsommers commented 1 year ago

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 commented 1 year ago

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

Drizzt321 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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

mleeman commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago
dsommers commented 1 year ago

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

These are queued up for the coming v21 release.

mleeman commented 1 year ago

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 commented 1 year ago

@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 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:

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 commented 1 year ago

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 commented 1 year ago

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:

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:

The intension behind these package names is that

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

A bit unrelated: do you think that this package is going to conflict with network manager openvpn in distros? See https://github.com/OpenVPN/openvpn3-linux/issues/46

darkbasic commented 1 year ago

I personally hope that NetworkManager won't use openvpn3 because it doesn't support fragment, which is mandatory with certain providers that tunnel traffic thus breaking PMTUD: https://forum.fibra.click/d/44630-lista-nera-dei-provider-che-multiplexano-le-sessioni-ppp-via-tunnel-l2tp

dsommers commented 1 year ago

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

@bhack No, it will not conflict with NetworkManager. That's a different set of package names with different package dependencies. A NetworkManager-openvpn3 add-on is wanted and requested by many, and that will use a very different integration than the approach the current one does.

Drizzt321 commented 1 year ago

Just getting back to this ticket, looks like a lot of good work has been done so far! :)

Looking forward to the official Debian packages, thanks for all the hard work, and crosses fingers that NM plugin sooner than later, even though the gnome ticket doesn't seem to have any movement recently.

mleeman commented 1 year ago

I was about to ask, is the update of the unicode code going to be part of 22 or not?

If not, I will continue to investigate creating a dfsg package.

At the moment, I am waiting in order to keep the official release tarball.

Just let me know what you decide and I'll continue.

dsommers commented 1 year ago

@mleeman The unicode change need to happen in the OpenVPN 3 Core Library first. If that can go into a OpenVPN 3 Core v3.8.3 or if it first happens in Core v3.9 is not decided yet. Once that is released, that's when I can start thinking about pulling in a new Core library in OpenVPN 3 Linux.

The v21 has almost completed QA. There is one issue I need to double check on Ubuntu 20.04 - but except of that, it's looking quite good. That release will hopefully make it out the door this week. If you want to test a source tarball on the current QA build, let me know and I'll upload one for you.

mleeman commented 1 year ago

No, I will need to do a dfsg package, if it is the 20 or 22, I don't think it will matter much.

I'll need to replace that file with.

update: since I seem to bump into more references to this file; I am asking around; either we need to change this and certainly a couple of other projects are wrong or this is not a problem and lintian is wrong.

mleeman commented 1 year ago

Feedback from debian-mentors on IRC (legalese is tricky):

TinoDidriksen
It is functionally the same MIT-esque license and otherwise is clearly a newer version of the file, both from the Unicode org. I'd say there is no problem and that it is a false positive. Ignore it.
dsommers commented 1 year ago

Thats' good. Yes, legalese is tricky. We will still work on this internally, upgrade to the later Unicode version and get that tested - just to avoid this reoccurring again.

I got a "Golden GO!" from QA yesterday, so I'm preparing the release of v21 now. I'll have the source tarball and git trees pushed out and updated during today. Our provided apt repository (and Fedora Copr) will be published on Monday, to not kill the weekend if something breaks for some users.

dsommers commented 1 year ago

@mleeman Source tarballs are available

https://swupdate.openvpn.net/community/releases/openvpn3-linux-21.tar.xz https://swupdate.openvpn.net/community/releases/openvpn3-linux-21.tar.xz.asc

mleeman commented 12 months ago

@dsommers integrated the new release on our internal distro for testing, builds fine for both bullseye and bookworm on mini-buildd,

I'll push an update for unstable next.

dsommers commented 12 months ago

That's awesome work, @mleeman! Once your work is ready and widely available through native Debian repos ... lets update the install instructions here: https://community.openvpn.net/openvpn/wiki/OpenVPN3Linux (adding a "native Debian repo" section).

Drizzt321 commented 12 months ago

@mleeman sounds like that means it'll be in debian unstable repo shortly? That's great news. Sadly might mean a while before it backs it to bookworm-backports or 12.3 (if there is one) of bookworm, but I can hope. Unless I have a misunderstanding of debian repo progressions.

Although I have been considering just moving to testing so I get updates quicker.

mleeman commented 12 months ago

It should be in unstable soon, and in testing (Trixie) the week after that.

It will never get in bookworm (that one is frozen for new software), though I could upload a package to bookworm-backports once it is in testing.

dsommers commented 12 months ago

@Drizzt321 In parallel to Marc's work, we will also provide some new repositories for our Cloud Connexa users providing only stable releases. That is undergoing QA right now. Once that is done, documentation will be updated. And I will ensure our builds are up to the same standards as the Marc's packaging.

But attached is a v21 .deb package for Debian 12 from our own internal builds: openvpn3_21-1+bookworm_amd64.deb.gz

Update: Just to remove any unclarity: Once OpenVPN 3 Linux is available in the standard Debian repos out-of-the-box, we will avoid as much as possible to duplicate the efforts from the Debian community. The only reason for OpenVPN Inc to potentially add such a "side-load repo" in the future will only be if there are critically needed features not being possible to get backported into the Debian builds. But we will always try to avoid that for as long as possible. But right now ("today"), we need to have some repos available for our Debian users until it's all in the proper upstream Debian repositories.

mleeman commented 10 months ago

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

mleeman commented 10 months ago

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

mleeman commented 10 months ago

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 commented 7 months ago

@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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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:

Package names used in the OpenVPN Inc provided packages:

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.