Bug#1014376: openvpn: Using unreleased version with backwards incompatible changes is not a good idea
Hi, On Fri, 8 Jul 2022 11:36:51 +0200 Raphael Hertzog wrote: > On Wed, 06 Jul 2022, Bernhard Schmidt wrote: > > > As such I really believe that this git snapshot should have stayed in > > > experimental. Why was it uploaded to unstable before its upstream > > > release? > > > > I respectfully disagree. This is what unstable/testing is for. 2.6 is to be > > released really soon, it contains breaking changes which we need to iron out > > / document with both upstream and Debian packaging. This can't wait until > > the last minute before the freeze. The 2.6 upload was influenced by OpenSSL > > 3.0, but this was definitely not the only reason to do this. The current snapshot actually is missing one important commit to better support OpenSSL 3: https://github.com/OpenVPN/openvpn/commit/88342ed8277c579704c0 This is a recommendation from one of the upstream developers here: https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/1975574/comments/3 Could we try at least to get a newer snapshot which includes the mentioned upstream commit? Another thing worrying this upstream maintainer was the fact that we seem to have experimental OpenVPN dco code which has been constantly improved: https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/1975574/comments/6 > If you were aware of regressions to iron out, it would have made sense to > file an RC bug to avoid the migration to testing until it has matured in > unstable. > > I understand it's always a trade off and that not all Debian developers > put the bar at the same level, but keeping testing "constantly usable" > has been something of a goal for a long time. I do not see the current version as unusable but a version with important breaking changes, and those will hit users at some point. > > This could be discussed with upstream. > > I certainly encourage you to discuss with upsream on whether they believe > a git snapshot ought to be delivered to unstable/testing (and thus > ultimately ubuntu too). As Raphael mentioned, upstream is against distros using snapshots from the master branch, however I do understand the reasons to do it earlier. >From the Debian perspective, I believe the important thing here is to make sure we ship 2.6 in the next release. -- Lucas Kanashiro
Bug#1014376: openvpn: Using unreleased version with backwards incompatible changes is not a good idea
On Wed, 06 Jul 2022, Bernhard Schmidt wrote: > > As such I really believe that this git snapshot should have stayed in > > experimental. Why was it uploaded to unstable before its upstream > > release? > > I respectfully disagree. This is what unstable/testing is for. 2.6 is to be > released really soon, it contains breaking changes which we need to iron out > / document with both upstream and Debian packaging. This can't wait until > the last minute before the freeze. The 2.6 upload was influenced by OpenSSL > 3.0, but this was definitely not the only reason to do this. If you were aware of regressions to iron out, it would have made sense to file an RC bug to avoid the migration to testing until it has matured in unstable. I understand it's always a trade off and that not all Debian developers put the bar at the same level, but keeping testing "constantly usable" has been something of a goal for a long time. > This could be discussed with upstream. I certainly encourage you to discuss with upsream on whether they believe a git snapshot ought to be delivered to unstable/testing (and thus ultimately ubuntu too). Cheers, -- Raphaël Hertzog ◈ Freexian SARL ◈ Tel: +33 (0)6 88 21 35 47 https://www.freexian.com
Bug#1014376: openvpn: Using unreleased version with backwards incompatible changes is not a good idea
Am 05.07.22 um 09:23 schrieb Raphaël Hertzog: as Kali is based on Debian testing, our users started to experience the git snapshot of OpenVPN that you uploaded. Unfortunately, we got multiple reports that their VPN break because many VPN services ship .opvn files that rely on --cipher. At the same time, it's not really reasonable to expect (commercial) services to be ready for a version of OpenVPN that is not released yet. Upstream OpenVPN contributors are blaming Debian/Kali for this choice: https://forums.openvpn.net/viewtopic.php?p=107165#p107154 As such I really believe that this git snapshot should have stayed in experimental. Why was it uploaded to unstable before its upstream release? I respectfully disagree. This is what unstable/testing is for. 2.6 is to be released really soon, it contains breaking changes which we need to iron out / document with both upstream and Debian packaging. This can't wait until the last minute before the freeze. The 2.6 upload was influenced by OpenSSL 3.0, but this was definitely not the only reason to do this. If we don't want to switch back to 2.5.x, it might make sense to temporarily revert the backwards incompatible change that breaks most people's setup, I'm speaking of this commit: https://github.com/OpenVPN/openvpn/commit/65f6da8eeb84fbcea357765e13fa73d0169a143c I don't see a good reason to do this in Debian. We either have to keep that change forever, or at some point later revert the revert, which will immediately break these setups again. At least this way users see a major version upgrade in their apt log. This could be discussed with upstream. Bernhard
Bug#1014376: openvpn: Using unreleased version with backwards incompatible changes is not a good idea
Package: openvpn Version: 2.6.0~git20220518+dco-2 Severity: important User: de...@kali.org Usertags: origin-kali X-Debbugs-Cc: raph...@freexian.com Hello Bernhard, as Kali is based on Debian testing, our users started to experience the git snapshot of OpenVPN that you uploaded. Unfortunately, we got multiple reports that their VPN break because many VPN services ship .opvn files that rely on --cipher. At the same time, it's not really reasonable to expect (commercial) services to be ready for a version of OpenVPN that is not released yet. Upstream OpenVPN contributors are blaming Debian/Kali for this choice: https://forums.openvpn.net/viewtopic.php?p=107165#p107154 As such I really believe that this git snapshot should have stayed in experimental. Why was it uploaded to unstable before its upstream release? I assume it was due to OpenSSL 3 becoming the default. However I notice that upstream released 2.5.7 on May 31 that adds limited support of OpenSSL 3.x. Can we switch back to 2.5.7 until 2.6 is released upstream? (We will likely do this in Kali with a version like 2.6.0~really2.5.7) If we don't want to switch back to 2.5.x, it might make sense to temporarily revert the backwards incompatible change that breaks most people's setup, I'm speaking of this commit: https://github.com/OpenVPN/openvpn/commit/65f6da8eeb84fbcea357765e13fa73d0169a143c It seems to be the change that is causing most issues. Thank you for maintaining such an important package!