Here's the summary of the IRC meeting.



Place: #openvpn-meeting on irc.freenode.net
Date: Thursday 10th October 2019
Time: 20:00 CEST (18:00 UTC)

Planned meeting topics for this meeting were here:


Your local meeting time is easy to check from services such as



cron2, dazo, lev, mattock and ordex participated in this meeting.


Talked about the new buildslaves. Cron2 added OpenBSD 6.5 (recent
release), NetBSD 8.1 (recent release), OpenIndiana (Solaris fork, recent
release) buildslaves with working t_client tests yesterday. Cron2 will
attempt to bring back at least part of the buildslaves that got
destroyed earlier.

Mattock finished migrating Ubuntu 18.04 and Fedora 30 to Amazon EC2 as
well to allow others to go have a look at them when there are issues.

The Fedora 30 buildslave is failing t_net.sh tests. Ordex and cron2 are
debugging the problem which seems timing-related.


Noted that mattock now has a new, more beefy (but still unconfigured)
Windows instance that can be used to build _and_ sign tap-windows6. This
greatly simplifies and speeds up the tap-windows6 building and signing


Mattock's plan forward with community work is this:

1) Finish internal OpenVPN work related to the buildslave setup (PRs)
2) Release tap-windows6 test installer
3) Setup the "builder" instance (~the old "Windows buildslave")
4) Setup a true Windows _buildbot_ buildslave for testing VS2019 builds


Noted that the VLAN patchset is slowly getting merged. The first patch
is already in.


Talked about the wintun patches from Lev and in particular the patch
that upgrades Visual Studio project files to VS2019 format. After a
lengthy discussion cron2 proposed the following:

- Have a Trac document that explains how to build with VS
- Merge the patch
- Get a VS buildslave (to help avoid breaking VS builds)

We did not reach a consensus on this yet.


Talked about OpenVPN apt repositories:


The topic was added by wiscii who was not present. It was not clear to
the meeting participants what the issue with the repositories is. We
will have to wait for more info.


Full chatlog attached.
(21:00:43) mattock: good evening
(21:02:06) cron2: aloah
(21:03:32) mattock: hi
(21:03:39) mattock: who else?
(21:05:47) mattock: hmm quiet
(21:06:22) dazo: you missed my message, mattock1 ;-)
(21:06:24) ***dazo will arrive a bit later today ... 
(21:06:27) dazo: in the middle of getting kids into bed
(21:06:40) mattock: ok!
(21:06:59) mattock: ok let's begin
(21:07:45) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2019-10-10
(21:07:47) vpnHelper: Title: Topics-2019-10-10 – OpenVPN Community (at 
(21:08:12) mattock: fairly clean topic list
(21:08:14) mattock: I'd add one
(21:08:16) mattock: buildslaves
(21:08:42) mattock: I have not checked the latest status of my buildslaves so 
I'll do it now
(21:09:07) cron2: fedora still borked on t_net.sh tests.  The rest is all green.
(21:09:23) mattock: yeah
(21:09:39) mattock: has there been any discussion as to why the t_net.sh tests 
(21:09:47) mattock: I did not have time to look into it
(21:09:50) cron2: this seems to be a timing issue
(21:10:00) lev__: guten abend
(21:10:06) dazo: chronyd not running?
(21:10:10) dazo: (or ntpd?)
(21:10:16) cron2: we had this on the arch linux one as well, and sprinkling 
sleep()s over the script helped
(21:10:42) mattock: dazo: I'll check - Fedora 30 is unlike anything else we run 
in our infrastructure
(21:11:04) cron2: dazo: nah, it's more like "some time after <mumble>, 
something happens with <thingsie>, so if your test is very fast, it will 
succeed.  If the machine is slow enough, <thingsie> will not look "right", and 
the test fails
(21:11:19) cron2: the arch linux machine is slowwwwwwwwwwww, so triggered this 
(21:11:27) dazo: ahh, okay
(21:11:32) cron2: mattock1: is the fedora machine particularily slow?
(21:11:40) cron2: like, "we only bought the 50 MHz license"?
(21:11:48) mattock: clock is good
(21:12:10) cron2: it's a local race condition, between "ip" manipulating things 
and "sitnl code" doing the same, comparing the results
(21:12:27) mattock: it is t3.small so low-end, but so is the ubuntu 18.04 VM
(21:12:36) cron2: plus the kernel code deciding *after some time* to change 
values printed by "ip link show" IIRC
(21:12:39) cron2: ordex knows
(21:13:40) dazo: "ip link show" is part of iproute2, so the output is depending 
on that package, not necessarily the kernel itself
(21:14:03) cron2: you run "ip link show", wait a second, run "ip link show" 
again, get a different result
(21:14:09) dazo: ahh
(21:14:14) dazo: that's interesting
(21:14:56) cron2: I forgot the specifics, which chain of commands trigger this 
- but if you finish in "wait a second" time, all is good.  If you're too slow, 
you hit "different result" and that makes the t_net comparison fail
(21:15:33) dazo: Maybe we need to implement our own "extract the info we need" 
utility based on sitnl for Linux tests :-P
(21:16:04) dazo: (which accounts for these details)
(21:16:06) cron2: this is why commit 8aa037161f37 exists :) but it seems this 
was not the true solution
(21:16:13) cron2: ah
(21:16:17) cron2:     t_net.sh: wait for NO-CARRIER bit to settle before 
starting test
(21:16:17) cron2:     
(21:16:17) cron2:     Interfaces of type tun are marked as NO-CARRIER when no 
process is
(21:16:17) cron2:     attached to them. However, this bit gets set with some 
delay after
(21:16:17) cron2:     creation.
(21:16:35) cron2: maybe a better fix would be to just ignore the NO-CARRIER on 
(21:17:06) cron2: yeah, same thing again - from the buildbot output:
(21:17:11) cron2: after unit-test:
(21:17:12) cron2: dummy0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc 
fq_codel state UNKNOWN mode DEFAULT group default qlen 100
(21:17:15) dazo: yeah ... or to have a polling loop which continues once 
NO-CARRIER is gone
(21:17:15) cron2: after iproute command:
(21:17:16) cron2: dummy0: <NO-CARRIER,POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 
qdisc fq_codel state DOWN mode DEFAULT group default qlen 100
(21:17:29) dazo: hmm
(21:17:39) cron2: (and the "state DOWN" goes along with "NO CARRIER")
(21:17:49) dazo: yeah
(21:18:17) dazo: alright ... lets not hold up the meeting for this debugging :)
(21:19:09) cron2: indeed :) ("ip link show | sed -e 's/NO-CARRIER,//' -e 
's/state DOWN/state UNKNOWN/'" *cough*
(21:20:06) cron2: aaanyway.  just for the record, I've added OpenBSD 6.5 
(recent release), NetBSD 8.1 (recent release), OpenIndiana (Solaris fork, 
recent release) with working t_client tests yesterday
(21:20:21) cron2: there is still hope I can get my "really old" boxes back
(21:20:36) cron2: and then I'll clean up the intermediate stuff that does not 
really serve a useful function anymore
(21:21:00) cron2: ("if we have OpenBSD 4.9 and 6.5, we do not need to run the 
tests on 6.0 every time")
(21:21:35) cron2: mattock1: anything else you had in mind?  like, windows/mingw 
buildbot, or MSVC builder?
(21:22:10) mattock: I'm still tying some loose ends on these Ubuntu 18.04 and 
Fedora 30 buildslaves - stuff not visible to you, but internal PRs and such
(21:22:29) mattock: I have a "Windows buildslave" as well, but is not fully 
(21:22:48) mattock: so the plan is:
(21:22:48) mattock: - tie in loose ends with current buildslaves
(21:22:48) mattock: - tap-windows6 test release
(21:22:48) mattock: - builder
(21:22:56) mattock: builder being the "Windows buildslave"
(21:23:05) cron2: looks good
(21:23:29) mattock: we recently got a new tap-windows6 building computer that 
actually has the signing dongle in it
(21:23:37) mattock: which simplifies the build/sign process quite a bit
(21:23:42) lev__: mattock1: is Windows slave with cygwin or VS?
(21:23:56) ***lev__ hopes for VS
(21:23:59) mattock: lev: it does not have anything at the moment, but I will 
setup Visual Studio
(21:24:06) mattock: because it is for tap-windows6 building primarily
(21:24:36) mattock: we can do away with Ubuntu 18.04 + openvpn-build for 
OpenVPN Windows installer builds
(21:24:49) mattock: as a non-EV authenticode cert is sufficient
(21:25:23) mattock: oh, so
(21:25:29) mattock: the Windows "slave" will just run openvpn-build
(21:25:51) mattock: in theory we could run buildbot on Windows, but nobody has 
tried it
(21:26:12) cron2: you're the master of python :)  (but most likely it assumes 
too much about "how to run things")
(21:26:48) mattock: it seems possible: 
(21:26:51) vpnHelper: Title: Buildbot Setup for Windows - MariaDB Knowledge 
Base (at mariadb.com)
(21:28:12) mattock: I'm not sure if it assumes that the commands run in 
powershell or cmd.exe - I hope the former
(21:28:15) mattock: or maybe it is configurable
(21:28:30) mattock: I think I could work on this with Lev, our Visual Studio 
guy :P
(21:28:49) mattock: but I think that would be the fourth step in my list
(21:29:01) ordex: thanks for debugging my iproute2 weirdness
(21:29:01) ordex: :D
(21:29:27) cron2: ordex: we didn't actually debug anything, just assign the 
blame half on you and half on the linux kernel :)
(21:29:39) ordex: :D
(21:32:54) mattock: ok so where to next?
(21:33:30) mattock: t_net.sh thing debugging will continue, buildslave status 
updated, buildslave setup plans revealed...
(21:33:35) mattock: anything on 2.5?
(21:34:36) cron2: vlan patches have been reviewed once, the (supposedly) 
reworked new branch has been posted to the list, and patch 1/9 has been merged 
(21:34:48) cron2: argv patches have been rebased, reworked, posted
(21:35:20) cron2: OpenSolaris tap mode has been repaired ("someone" broke it at 
refactoring tun.c)
(21:35:39) cron2: the visual studio / wintun patches could need a bit of 
(21:36:32) lev__: it is mostly wintun, only first one (of 7) is about VS
(21:37:29) lev__: it would be nice if someone could run openvpn-gui installer 
with wintun 0.7, I have been using it for a while already
(21:37:32) mattock: lev: I created an internal ticket about the Windows 
_buildbot_ buildslave
(21:37:41) mattock: you should have received a notification (OSS project)
(21:37:58) lev__: yeah got it
(21:38:57) lev__: we could / should use VS2019 Community (after merging the 
first patch from wintun series, it just updates project files to VS2019)
(21:41:23) mattock: I'll make a note of that
(21:41:32) mattock: (for Windows buildslave)
(21:43:02) mattock: 18 mins left - anything else?
(21:43:16) cron2: lev__: so will it then no longer work with older versions?  
Or what does it do?
(21:46:08) lev__: cron2: it updates project files to use newer build toolset, 
which is included into VS2019 
(21:46:30) dazo: and VS2019 is available as a community/free (no cost) version
(21:46:33) cron2: lev__: so if you do that, it breaks compilation with VS2016?
(21:46:48) cron2: the commit message for patch 1/7 is a bit funny
(21:46:58) cron2: it explains the whole patch series and all the fairy tales 
about wintun...
(21:47:28) cron2: https://patchwork.openvpn.net/patch/824/
(21:47:29) vpnHelper: Title: [Openvpn-devel,1/7] Visual Studio: upgrade project 
files to VS2019 - Patchwork (at patchwork.openvpn.net)
(21:47:33) lev__: cron2: if you mean VS2015/2017 then yes, unless you install 
VS2019 build toolset
(21:47:47) cron2: so what is the benefit of this patch?
(21:47:49) dazo: yeah .... I've talready rolled lev__ internally about 'git 
format-patch --cover-letter' ....
(21:47:53) lev__: cron2: I was not aware about --cover-letter option
(21:48:00) dazo: I've already trolled*
(21:48:20) lev__: yes blame dazo because he didn't tell it to me earlier
(21:48:27) dazo: :-D
(21:48:37) cron2: my git format-patch doesn't have that option
(21:49:26) dazo: double check with git format-patch --help .... I think it's 
missing mentioning in the man page
(21:49:33) cron2: anyway: so what is the *benefit* of bumping the version to 
VS2019, if it has the drawback of breaking people's compile if they use VS2016 
(21:49:42) cron2: better optimization?  it does not work with 2016 anyway?
(21:49:45) lev__: in fact, the commit message to the first patch could just be 
"upgrade project files to VS2019"
(21:50:13) lev__: cron2: there is no VS2016, it is either 2015 or 2017
(21:50:36) dazo: well, but will it break any of those?
(21:50:42) cron2: whatever "some earlier versions"
(21:51:45) lev__: yes, but I don't see it as an issue, you cannot easily 
download earlier versions nowadays (you need to create an MS account first for 
(21:52:57) dazo: I would suggest we try to pull in this patch (it affects only 
a well defined set of users) ... and if people complain, then we need to 
consider what should be the VS requirements for OpenVPN
(21:53:14) cron2: for someone who has a working build environment today, 
breaking this with no clear benefits is "an issue".
(21:53:39) cron2: if have yet to hear why this patch is an improvement...
(21:53:53) cron2: sorry for being so complicated, but this should be an easy 
(21:54:05) dazo: True ... but if they don't chime in on the patches to the 
mailing list ... that's a silent approval in my view point
(21:54:24) lev__: well, we use 2019 in openvpn3 and I see no reason to have 
both installations on my laptop
(21:54:31) cron2: does it not build at all with 2019?  is the optimization 
better?  compatibility with Win10 2020?
(21:54:40) cron2: lev__: this is not the point
(21:54:48) cron2: *why* *is* *this* *change* *needed*?
(21:54:58) lev__: also when you open vs2017 project in vs2019 the first thing 
you see is a dialog "do you want to upgrade"
(21:54:59) cron2: dazo: it does not work that way
(21:55:11) mattock: also, can't you keep the old project file around?
(21:55:22) dazo: lev__: let's flip it around ... if we don't pull in this 
change ... what happens in the VS2019 environment?
(21:55:34) cron2: dazo: most patches enticit no response, and we still do not 
merge them "someone would complain otherwise!"
(21:55:57) dazo: cron2: we still do have the 2 weeks lazy-ack policy ;-)
(21:56:14) mattock: we've been quite lazy in lazy-ACK'ing
(21:56:25) cron2: which we very very rarely excercise, especially not for 
patches with unclear benefits and side-effects
(21:56:35) dazo: that's true
(21:56:48) lev__: dazo: it won't work if you have only newer build toolset from 
2019 unless you upgrade project files locally
(21:57:41) cron2: lev__: so it will just fail to build?  like a makefile 
calling "gcc-5" unconditionally, no matter which version is there?
(21:57:41) dazo: okay, so this is essentially some MS mess .... upgrade from 
prior versions, and everything works as expected.  Install a fresh VS2019 and 
things break.  Update the project files and only VS2019 environments works 
(21:57:47) dazo: is that correct, lev__ ?
(21:58:57) lev__: cron2: VS build files have build toolset hardcoded, if you 
open old project files with a new VS it will prompt you either to upgrade 
project files or install previous build toolset version
(22:00:05) lev__: dazo: yes, it is a bit differrent from autotools, since 
compiler version (build toolset) is essentially hardcoded
(22:00:42) dazo: Now I'm beginning to lean towards not touching the project 
files .... unless there is an obvious benefit for the OpenVPN project to 
enforce a specific toolset version
(22:00:55) dazo: enforce a newer specific version, I mean
(22:01:01) lev__: some other kernel tunnel driver uses VS2019 
(22:01:34) lev__: I am surpised you guys care so much about visual studio 
(22:01:38) mattock: :)
(22:01:47) mattock: they're just concerned about users
(22:01:56) mattock: even Windows users are humans
(22:02:01) dazo: well, breaking other developers environment is important to 
(22:02:37) cron2: we can document "to build 2.5, you need VS2019" and I think 
that would be fine (since it's freely available)
(22:02:43) cron2: lev__: can you downgrade?
(22:02:48) lev__: you can flip it other way and wait for "openvpn doesn't work 
with VS2019" complains
(22:02:52) dazo: just like we care about stuff functioning on ancient AIX and 
Solaris distributions .... we even have RHEL-6 defined as the oldest supported 
Linux distro
(22:03:15) mattock: lev: that sounds reasonable to me
(22:03:41) dazo: so far we have been lacking this kind of "what is required for 
building OpenVPN with VS" specification
(22:03:45) mattock: I _guess_ you could have multiple visual studios side by 
side, but that's kind of crapy
(22:03:48) mattock: crappy
(22:03:59) lev__: cron2: you can edit project files manually, or rather install 
vs2019 build toolset and use vs2017 IDE, if you wish 
(22:04:08) dazo: mattock1: it's more about the build toolset being installed, 
which defines the compiler versions
(22:04:40) mattock: dazo: oh yes
(22:04:56) mattock: 4 minutes overtime
(22:05:05) mattock: can we reach a conclusion today?
(22:05:31) dazo: I propose we define a specification for VS requirements, and 
we stick to that
(22:05:33) cron2: just for the record, I do understand the patch now, it's a 
mess, but I'm not opposing it - if VS2019 can be had freely, and earlier 
versions not, it's a good argument
(22:05:43) cron2: dazo: yes
(22:05:43) lev__: I think before arguing that upgrading VS will break other 
developers setup, it makes more sense to make sure our commits do not break VS 
(22:06:19) lev__: (which should be fixed by windows buildbot)
(22:06:22) cron2: lev__: that's a bit of a knee-jerk reaction :-) - we don't do 
this intentionally, VS is just too backwards
(22:07:20) dazo: lev__: for all we know, there might be enterprise developers 
being required to use VS2017 as part of their job ... but if it's easily solved 
to just install the build toolset from VS2019, then it's less of a problem from 
my perspective
(22:07:47) dazo: but that doesn't escape that we are essentially missing a 
specification for minimum VS requirements building openvpn
(22:08:07) cron2: do we have build instructions somewhere?
(22:08:15) lev__: how deep back in time we should go
(22:08:25) lev__: I started with VS 5.0
(22:08:39) lev__: cron2: no, I should probably fix that
(22:08:44) dazo: lev__: what is officially supported by Microsoft today?
(22:08:55) dazo: (within normal support contracts)
(22:08:58) lev__: at the moment you can just run build.bat from openvpn-build 
to build everything
(22:09:16) cron2: I think that would be a good outcome - we have a Trac 
document that explains how to build with VS, we merge the patch, and we get a 
VS buildslave :-)
(22:09:24) lev__: but using VS for development requires some work, OTOH you 
just do it once
(22:09:38) lev__: sounds like a plan
(22:10:02) cron2: mattock1: on "3. do something about these repos" - I think 
that's all yours, innit?
(22:11:10) mattock: cron2: I did not understand a word
(22:11:13) mattock: please explain :)
(22:12:05) lev__: btw I think I understand your point about minimal version - 
in Linux you sometimes stuck with certain compiler version which is part of OS 
and bumping it without reason sounds wrong and will likely break many setups
(22:12:09) cron2: mattock1: item "3" on the agenda
(22:12:40) dazo: lev__: yes, exactly
(22:12:50) lev__: but I don't think it applies in windows, you can just install 
newest VS or just build toolset on (almost) any Windows version
(22:12:51) mattock: ah
(22:14:26) mattock: so "Update, or something, these repos" means what?
(22:14:35) mattock: I assume there is a problem there?
(22:14:36) dazo: lev__: the difference is essentially how packages/software is 
distributed ... Linux distros, it's the distro who packages and distributes the 
software.  In Windows, there is no such thing as a "software repository" (well, 
except Windows Store, or such like)
(22:14:39) cron2: update, hide, burn with fire :)
(22:14:58) cron2: mattock1: I did not put it on the agenda, but it implies 
"these are stale".  Is that a possibility?
(22:15:30) mattock: they're not no more stale than our OpenVPN 2.x releases
(22:15:59) dazo: It's wiscii/tincantech who added that topic ... don't see him 
here though
(22:16:02) cron2: tincantec/wiscii added that
(22:16:04) cron2: yeah
(22:16:19) mattock: ok, no point in discussing this
(22:16:28) mattock: afaik they work perfectly and have the latest packages
(22:16:39) cron2: okay, item closed :)
(22:16:41) mattock: I have not received any complaints about them from anyone
(22:17:08) mattock: so do we go with cron2's suggestion, i.e.
(22:17:08) mattock: - Have a Trac document that explains how to build with VS
(22:17:08) mattock: - Merge the patch
(22:17:08) mattock: - Get a VS buildslave
(22:17:09) lev__: dazo: in fact windows has apt-like repo, chocolatey
(22:17:20) mattock: yes, I use that with Puppet
(22:17:20) ***lev__ drops the ball to mattock1 and runs
(22:17:22) mattock: and manually
(22:17:25) dazo: lev__: well, but the Windows OS isn't distributed via that 
channel ;-)
(22:17:50) dazo: it's basically a "random" community repository
(22:18:22) cron2: I'm out... need to take a break, ahve a network change in 40 
minutes... *wave*
(22:18:31) dazo: c'ya!
(22:18:33) mattock: yes, let's kill this meeting
(22:18:35) ***dazo need to go too
(22:18:41) mattock: yes, 22:18 here

Attachment: signature.asc
Description: OpenPGP digital signature

Openvpn-devel mailing list

Reply via email to