Hi, Here's the summary of the previous IRC meeting / sprint.
--- COMMUNITY MEETING Place: #openvpn-devel on irc.freenode.net List-Post: openvpn-devel@lists.sourceforge.net Date: Thursday 24th Nov 2011 Time: 18:00 UTC Planned meeting topics for this meeting were on this page: <https://community.openvpn.net/openvpn/wiki/Topics-2011-11-24> Next meeting will be announced in advance, but will probably be on the same weekday and at the same time. Your local meeting time is easy to check from services such as <http://www.timeanddate.com/worldclock> or with $ date -u SUMMARY andj, cron2, dazo, krzie and mattock participated in this meeting. -- Discussed current state of OpenVPN buildsystems. Agreed that for 2.2.2 and 2.3 releases no big changes should be made. However, rethinking the (Windows) building after 2.3 would make sense: for example, split the TAP-driver into it's own (sub)project and build and sign the OpenVPN binary for Windows on Cygwin + mingw_w64. For details, see <https://community.openvpn.net/openvpn/ticket/174> -- Discussed "IPV6_RECVPKTINFO vs. IPV6_PKTINFO" patch briefly: <http://thread.gmane.org/gmane.network.openvpn.devel/4775> This patch has not yet been ACKed. Mattock will ask JJO to review this. -- Discussed the "openvpn-2.2.1-install.exe contains unsigned openvpn-gui-1.0.3.exe" bug: <https://community.openvpn.net/openvpn/ticket/171> Mattock will fix this for 2.2.2. -- Attempted to generate an OpenVPN installer from "master" that works for all supported Windows versions in both IPv4 and IPv6 modes. The following installer seems to work ok on WinXP 32-bit and Win7 32-bit: <http://build.openvpn.net/downloads/snapshots/openvpn-2.3-openvpn-inet-ntop-install.exe> The following two bugs have been fixed in this installer: <https://community.openvpn.net/openvpn/ticket/126> <https://community.openvpn.net/openvpn/ticket/169> For some reason the installer did not work on mattock's Windows 7 64-bit VM. If you want to try this out on that platform, you need to put Windows 7 64-bit into test mode. For details, look here: <https://community.openvpn.net/openvpn/wiki/BuildingOnWindows#Method2:Enablingtestmodeontargetcomputer> Also note that WinXP might not have IPv6 support installed by default. -- Discussed OpenVPN 2.3 release in general. Current ticket list can be viewed from here: <https://community.openvpn.net/openvpn/report/3> Agreed that releasing the first 2.3 alpha in January is doable. -- Discussed various bugs related to <connection> profile handling: <https://community.openvpn.net/openvpn/ticket/16> <https://community.openvpn.net/openvpn/ticket/19> <https://community.openvpn.net/openvpn/ticket/78> Decided to postpone fixing profile handling for good until 2.4, so that 2.3 release does not get delayed any further. -- Discussed the "OpenVPN Install and the Windows Path Environment variable" bug: <https://community.openvpn.net/openvpn/ticket/34> Mattock will do some research to find out how difficult fixing this would be. -- Discussed the "Option --register-dns does not work in conjunction with --win-sys" bug: <https://community.openvpn.net/openvpn/ticket/106> There are still some hardcoded paths in win32.c in latest "master", one of them in a critical place. --- Full chatlog as an attachment -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock
mattock 19:58:42 almost meeting time... andj 19:59:17 I'm going to miss most of the meeting I'm afraid cron2 20:01:48 so cron2 is here! 20:01 mattock 20:02:31 will dazo attend today? cron2 20:05:11 haven't seen anything mattock 20:05:34 well, I'll check my own list of "things to do before 2.2.1" ...while waiting 20:05:43 cron2 20:05:50 we're at "before 2.2.2" now mattock 20:06:41 oops cron2 20:07:30 let me briefly test the openvpn.exe I built this morning, so I can say for sure whether my patching worked mattock 20:07:43 ok this bug report is still unresolved: https://community.openvpn.net/openvpn/ticket/126 20:07:53 then there's the "IPV6_RECVPKTINFO vs. IPV6_PKTINFO" patch, which was sent to jjo for review 20:08:21 no clue what it's current status is 20:08:27 cron2 20:08:49 #126 is unresolved because we don't know whether the 9.9 tap driver works on Win7 it works for me on XP and fixes the small-packet issue 20:09:02 mattock: I think we need a signed tap driver for the reporter of #126 to test 20:11:17 mattock 20:11:29 ok, it seems IPV6_RECVPKTINFO patch has not gone anywhere... from jjo on 10th Aug: "Thanks a lot for looping me in, afaics at a glance I'd propose a bit diff approach, to avoid "generalizing" the osx mishandling of these symbols into other platforms. Will take a look on the weekend && reply." maybe I'll push jjo a little more 20:11:41 cron2 20:11:47 mattock: so if you could get James to sign the driver, this could be tested and closed for good mattock 20:12:14 so this #126 is what your recent patches fix? cron2 20:12:21 yes mattock 20:12:24 ah, ok I'll mail james 20:12:31 cron2 20:12:39 the patches to tapdrvr.c, and for completeness, version.m4 and tun.c mattock 20:12:41 maybe he could provide signed 9.9 tap drivers cron2 20:12:52 that would be great, so win7 people could then test mattock 20:14:59 mail sent cron2 20:16:55 *sigh*, windows is hating me again mattock 20:18:49 updated #126 ...now 20:19:01 cron2 20:20:18 mmmh, the binary I built today is not working at all, but maybe I forgot some sort of finalize step mattock: could you build an installer with "master" plus http://pastebin.com/Zr7T9jrv 20:21:58 so we can see whether that one works on XP now? 20:22:12 I think it should 20:22:15 mattock 20:22:16 ok cron2 20:23:00 most likely I'm just not supposed to copy-away the openvpn.exe from the build directory before some manifest thingie is updated, or so mattock 20:27:23 patching argh, issues with the patch format 20:31:35 cron2 20:31:59 huh, what is it disliking? mattock 20:32:51 not sure, it can't detect the patch format I'll try the downloaded version with plain patch 20:33:08 http://pastebin.com/sGbJ4xdr 20:34:04 it apparently does not like the git line 20:34:15 cron2 20:34:32 just throw it out, then and the "index" line as well 20:35:02 mattock 20:36:27 did not help, got tons of rejects cron2 20:36:46 I'll put up a proper git format patch. mom. mattock 20:36:54 I was about to ask 20:36:57 cron2 20:37:22 no idea what happened, must have been windows mangling things mattock 20:37:31 might be, it was in DOS format cron2 20:40:55 mattock: you have mail mattock 20:41:19 not yet, but probably soon arrived 20:42:59 applied cleanly 20:43:33 damn, those inet_ntop errors (yet) again 20:45:07 cron2 20:45:16 wut? oh 20:45:25 mattock 20:45:27 I'll double check and then paste an error log cron2 20:45:29 patch is incomplete mattock 20:45:31 ok cron2 20:46:17 please change the two lines above the #define inet_ntop() in win32.h to read "int openvpn_inet_pton..." and "const char * openvpn_inet_pton". Missed that part when re-doing the fix. Or just move the two #define lines two lines up, before the "inet_ntop" line gah 20:46:22 mattock 20:46:59 just sec a 20:47:01 cron2 20:48:45 mattock: will send you a new patch mattock 20:49:01 just patched it myself, but feel free cron2 20:49:31 sent mattock 20:49:58 looks better now built and packaged 20:51:41 cron2 20:51:47 good mattock 20:51:50 I'll copy the installer + tap-driver + openvpn.exe to build.openvpn.net cron2 20:52:17 I'll download and test the installer then mattock 20:55:58 ok, here: http://build.openvpn.net/downloads/snapshots/ cron2 20:56:04 yeah, downloading mattock 20:56:04 it's the inet-ntop stuff cron2 20:59:05 meh mattock 20:59:50 I wonder if I have to install another Win7 64-bit test VM to get rid of the messy driver situation cron2 20:59:53 the binary starts, but then IPv6 fails the replacement functions do not work properly 21:00:28 I use inet_pton() to ask the system "is this a valid IPv6 address?" and I get back "no!" for everything 21:01:35 mattock 21:03:07 time for a custom IPv6 address verifying function using regular expressions? cron2 21:03:15 nah if inet_pton() isn't working, we get more problems in other places 21:03:27 mattock 21:04:46 cron2: do you want to take a stab at fixing this today? it seems the official meeting is stub today 21:04:55 cron2 21:07:23 mattock: well, as it seems nobody else is here, let's briefly discuss what we have on the agenda mattock 21:07:31 ok build system? 21:07:38 I was wondering if Cygwin could be used for (official) Windows builds 21:08:06 except for TAP-driver building + signing 21:08:13 cron2 21:08:40 you can build the TAP driver on mingw+msys, so I'm sure you can build it on cygwin+mingw64 - you just need the windows ddk/sdk installed so it's really up to you (and James) to decide what the official build system should be like - you're the ones that have the nice task of building "official" installers... 21:09:13 mattock 21:09:20 currently windows building is a mess, and visual studio is constantly causing issues cron2 will try to make MSVC builds work, but prefers (by FAR) anything that is gcc-based 21:09 mattock 21:10:21 the VS/Python builds works really well now, but having to use the VS C compiler seems to be problematic when coding, that is 21:10:32 or that's my feeling 21:10:36 cron2 21:10:59 it's very strict about things, which is problematic when trying to do portable stuff mattock 21:11:14 I think we should stick with VS/Python for official builds for 2.3 in any case hmm, I wonder if it could be made less strict somehow 21:11:22 I think I'll try Cygwin builds in the near future to get a feel for them 21:13:37 cron2 21:13:46 I don't think we can decide much here today - needs input from James, testing Cygwin, etc. mattock 21:13:49 yep cron2 21:13:58 2.2.2 release mattock 21:14:06 ok, so here's the list of tickets per milestone: https://community.openvpn.net/openvpn/report/3 cron2 21:14:09 what we need is a signed + tested tap 9.9 driver mattock 21:14:23 yep and I probably need to reinstall Win7, as the tap-driver behavior is not too encouraging 21:14:41 cron2 21:14:59 ouch, that is a lot of open bugs I think we should focus on "tap driver fix", "get xp to work again" and "remove the warning in #147" 21:15:45 mattock 21:16:33 yeah some of the bugs are "legacy" (from sf.net bug tracker) 21:16:44 although many were removed before moving them over, and even after that 21:16:57 this we can probably manage with a small effort: https://community.openvpn.net/openvpn/ticket/127 21:17:34 cron2 21:18:09 yeah mattock 21:18:17 for this we need to poke the reporter: https://community.openvpn.net/openvpn/ticket/154 I'll do it right now 21:18:32 ah, dazo should get here 21:20:08 he said he'll be "20-30 minutes late" 21:20:18 so, I guess he forgot to check "date -u" 21:20:31 cron2 21:20:54 patch in your mailbox applies on top of "master" (includes previous patch) 21:21:05 L'utente dazo_afk è ora conosciuto come dazo 21:21 dazo here now 21:22 mattock 21:22:33 hi dazo! dazo 21:22:34 sorry about the delay dazo catches up on scrollback 21:22 mattock 21:23:11 I was afraid the meeting would be a stub I mailed james at around 20:20, so far no response 21:23:21 cron2 21:24:23 mattock: could you build a new installer, please? dazo 21:24:52 regarding build system core for Windows ... I have no problems with moving towards cygwin/msys/mingw/what-ever-its-called .... I see that the TAP driver might need VS, but that's a different issue cron2 21:25:13 no, not VS, Windows SDK, which is a separate thing from VS cron2 has succeeded in building a tap driver with mingw+msys plus wdk (domake-win) 21:25 mattock 21:25:37 james is on a vacation dazo 21:25:40 ahh! cron2 21:25:48 mattock: when will he be back? mattock 21:25:51 good for him, afaik he's been working way too much not sure, asked him via email 21:25:55 dazo 21:26:04 okay, then it's even easier ... I thought VS was tightly hooked into these things To be honest, I'd really like to get the Windows TAP driver out of the stock OpenVPN stuff ... it's not related to OpenVPN (except it provides a tun/tap device) ... It's the installers task to pull in the needed sub-parts for the overall user experience, in my eyes ... so I'm along with Alon's thoughts here 21:26:42 mattock 21:26:44 cron2: the "patch 4" is borked or something cron2 21:26:53 mattock: what happens? dazo: yeah 21:27:01 dazo 21:27:12 get a OpenVPN MSI for only OpenVPN stuff ... and WinTAP MSI for the TUN/TAP driver ... and the installer ships them both cron2 is with dazo on that. for 2.3 or for 2.4? 21:27 cron2 21:27:38 for 2.2.2 we need to stick to what we have dazo 21:27:42 agreed I'd like to see this already for 2.3 21:27:49 mattock 21:27:53 cron2: patch format detection fails (git am), hunks get rejected (patch) dazo 21:28:07 Not necessarily the first alpha/beta stuff ... but at least for RCs cron2 21:28:10 meh, this is straight out of "git diff" dazo 21:28:23 git apply cron2 21:28:32 mattock: please do git apply dazo 21:28:40 (or patch -p1 if 'git apply' gets grumpy) cron2 21:29:03 yeah, git am wants mail headers on top, which are not there dazo 21:29:14 yeah mattock 21:30:17 git apply failed, patch -p1 worked interesting how difficult patching can be 21:30:23 dazo 21:31:29 hehe ... git is hyper-sensitive to patches .... which I consider a good thing mattock 21:32:50 building... ok, on build now 21:35:42 http://build.openvpn.net/downloads/snapshots 21:35:57 *-patch4-* 21:36:07 cron2 21:36:19 installing... meh, still fails, with WSAEINVAL 21:37:56 mattock 21:38:55 this is interesting: https://community.openvpn.net/openvpn/ticket/171 cron2 21:39:07 mattock: patch5 on its way to you mattock 21:39:08 did not realize somebody (James?) had signed the GUI also cron2: ok 21:39:14 cron2 21:39:38 indeed, having a signed gui is useful mattock 21:40:16 I'll fix that, it's trivial patching 21:41:20 cron2 21:42:14 oh gaaah 21:42:21 Support for IPv6 addresses using the WSAStringToAddress function was added on Windows XP with Service Pack 1 (SP1) and later. IPv6 must also be installed on the local computer for the WSAStringToAddress function to support IPv6 addresses. 21:42:42 mattock 21:42:52 building dazo 21:43:19 whoops cron2: does that mean that you need to install some extra IPv6 patches for the new TAP driver to work in XP? 21:43:54 cron2 21:43:57 I think my IPv6 failures are just due to "no IPv6 installed on that XP VM" just enable it 21:44:00 netsh interface ipv6 install 21:44:04 let me re-test 21:44:08 mattock 21:44:22 ok let me know if you need the patch5-based installer 21:44:38 meanwhile I'll skim through all bug reports 21:44:50 cron2 21:45:10 works perfectly patch4 based, that is 21:45:16 I'll go back to the last one 21:45:21 inet-ntop 21:45:33 that was purely a problem with the XP VM I cloned monday, which - purposely - did not have v6 yet 21:46:03 dazo 21:46:19 just a side related thought .... WinXP has end of support from Microsoft April 8, 2014 ... shall we kill XP support at that time as well? ... will that make things easier for us? mattock 21:46:30 this might be "works for me": https://community.openvpn.net/openvpn/ticket/68 cron2 21:46:42 dazo: let's keep it for 2.3, and then kill it mattock 21:46:43 a custom windows build with an issue andj is back 21:46 mattock 21:47:00 hi andj! cron2 21:47:11 mattock: inet-ntop installer works with ipv6 on xp \o/ mattock 21:47:17 nice! cron2 21:47:26 also works with small packets dazo 21:47:32 cron2: fair enough ... as long as building XP binaries doesn't get too complicated .... like what we experienced with TAP driver for Win2k cron2 21:47:34 (ping -l 1) dazo 21:48:05 cron2: so, IPv6 needs to be enabled for the new TAP driver to function? (the netsh stuff) 21:48:14 cron2 21:48:15 dazo: no andj 21:48:17 how's the meeting going? and any news on blockers for the 2.3 alpha? cron2 21:48:28 that's unrelated to the tap driver, that's needed to make inet_pton() accept IPv6 addresses dazo: we can build XP-compatible binaries now 21:48:43 dazo 21:48:44 andj: I'm late in as well, but I think it's 2.2.2 stuff which is being solved yet ack! 21:48:49 cron2 21:49:01 dazo: actually it's fixing #169 mattock 21:49:10 it'd be great if the installer would work on 64-bit Win7, too nobody around with test-mode win7 64-bit around? 21:49:27 oops 21:49:30 andj 21:50:00 mattock: I have one at work, but not here I'm afraid mattock 21:50:32 andj: could you smoketest this installer there: http://build.openvpn.net/downloads/snapshots/openvpn-2.3-openvpn-inet-ntop-install.exe andj 21:51:00 yes, but that'll be somewhere tomorrow mattock 21:51:01 my win7 seems to reject it and I'm not sure if it's because windows is borked or not that's fine 21:51:08 cron2 21:51:26 patch (0001-work-around-inet_ntop-inet_pton-problems-for-MSVC-bu.patch mattock 21:51:27 I'd rather not reinstall my win7 VM just to verify that cron2 21:51:29 ) sent to list andj 21:52:48 mattock: I'll see what I can do, I've got a VM image with a win 2008R2 in test mode lying around somewhere mattock 21:52:57 andj: that'd be great! andj 21:53:14 so it isn't win7 as promised earlier cron2 21:54:53 so - coming back to 2.2.2 release do we know when James will come back? (Or is there anyone else who can sign drivers)? 21:55:15 do I need a signed driver on win7/32? 21:55:38 mattock 21:56:17 cron2: he hasn't responded yet, so no regarding "anybody else"... no, not atm 21:56:29 for 32-bit Windows signing is not mandatory 21:56:46 cron2 21:56:53 ok, let me try win7/32 dazo 21:56:58 cron2: looking at the patch you sent ... just wondering, you #define inet_* -> openvpn_inet_* .... but you declare inet_* functions in socket.c ... shouldn't they be openvpn_inet_*? cron2 21:57:24 they get renamed on declaration macros also apply there 21:57:45 if you think this is not clean, I'll change that as well (it was that way before I put my hands on it, so I didn't want to change too much) 21:58:14 dazo 21:59:07 well, the windows code is pretty nasty spaghetti for me ... so I might lack the overall understanding here now cron2 21:59:46 yep, tap 9.8 fails on "ping -l 1 -4 ..." let's try tap 9.9 21:59:49 dazo 22:00:28 because I don't see where the openvpn_inet_ntop() function is ... I see it is declared in win32.h but not where the "contents" of that function is ... cron2 22:00:40 socket.c search for "just" inet_ntop() and inet_pton() 22:00:51 but since the declaration is after the #define, the function gets renamed right away 22:01:02 dazo 22:01:42 there is$ git grep openvpn_inet_ntop | wc -l 0 22:01:43 cron2 22:01:50 21:00 <@cron2> search for "just" inet_ntop() and inet_pton() 21:00 <@cron2> search for "just" inet_ntop() and inet_pton() 22:01:51 21:00 <@cron2> search for "just" inet_ntop() and inet_pton() 22:01:51 dazo 22:01:52 (this is before this patch) cron2 22:01:55 21:00 <@cron2> search for "just" inet_ntop() and inet_pton() socket.c 22:02:02 dazo 22:02:36 yeah ... but this define then looks strange: #define inet_ntop(af,src,dst,size) openvpn_inet_ntop(af,src,dst,size) as it defines something known to something unknown 22:02:45 cron2 gives dazo a mug of coffee, and asks him to re-read what I wrote 22:03 cron2 22:04:55 ok, topic switch: tap driver 9.9 works for me on win7/32, and "ping -l 1 -4 ..." is fixed, so this is fixing the small-ipv4-packets problem for good topic switch back 22:05:00 dazo: if you think it's more clean, we can rename the inet_ntop and inet_pton functions in socket.c to openvpn_inet_ntop and openvpn_inet_pton just fine. I just didn't do that (yet) since the #define will take care of this anyway. 22:05:40 mattock 22:06:13 that would probably reduce some confusion dazo 22:06:15 cron2: I'm just quite tired these days, so I'm trying to see what you see ... but I don't see it yet ... I'm applying the patch to see how things looks like then cron2 22:06:37 dazo: socket.c has a function "inet_ntop()" it includes something that includes win32.h 22:06:47 dazo 22:06:57 cron2: it might be cleaner to avoid name confusion like this ... by prefixing our own "versions" of it cron2 22:07:07 so when the compiler reads socket.c, the #define from win32.h is active, and the preprocessor will change it to openvpn_inet_ntop() ok 22:07:12 cron2 goes re-spin the patch 22:07 cron2 22:11:05 sent L'utente uuuppz è entrato nella stanza 22:11 cron2 22:11:58 mattock: you're taking notes what we need to fix for 2.2.2? mattock 22:12:19 not really, but we should put that stuff to trac and we got 6 trac tickets already for 2.2.2 22:13:29 anything else besides those? 22:13:35 cron2 22:13:48 which ones are the 2.2.2 ones? lost track mattock 22:13:58 just a sec https://community.openvpn.net/openvpn/report/3 22:14:03 scroll back to the bottom 22:14:08 and there's more on the next page 22:14:14 cron2 22:14:44 #126 should be fixed now, as soon as we have a signed tap driver mattock 22:14:52 I've been reviewing the bug reports and there are quite a few that could probably closed cron2 22:15:31 #147 is something I wanted to look into dazo 22:15:56 #126 I believe will be closed now, with the "small packet fix" from cron2 ... #147 and #171 are "outstanding" ... #127, I'd say we either fix quickly before release, or postpone it again cron2 22:16:22 #154 is hard to fix without configs dazo 22:16:41 yeah, I wonder if that's a firewall issue, not openvpn issue mattock 22:16:42 dazo: quick fix sounds good cron2 22:16:55 ah, indeed dazo 22:17:05 #127 isn't that important either cron2 22:17:11 "not having client-to-client in the config" just translates to "all packets traverse the tun adaptor" so if there's no firewall on the server host, there's nothing to prevent client-to-client config - so this might be a misunderstanding by the user 22:17:40 dazo 22:17:44 exactly mattock 22:18:22 close the bug report? cron2 22:18:56 I've added a comment explaining this, and since he never sent configs, yes, close well 22:19:06 trac is slow today in accepting comments 22:19:12 mattock 22:19:18 I noticed the same it seems to accept the comments and changes, but hangs forever 22:19:30 if you stop and reload, you'll see the changes 22:19:39 not sure if I should be worried... 22:19:44 seems like google bot is crawling the site 22:21:06 the damn slow Trac git repository, to be exact 22:21:28 so no worries 22:21:31 should we discuss 2.3 briefly? 22:22:47 dazo 22:23:49 please, lets do that andj 22:24:28 I'm interested mattock 22:24:35 so, we have the ticket list here: https://community.openvpn.net/openvpn/report/3 bottom of the page 22:24:39 cron2 22:24:45 I'm listening, but I feel a bit exhausted mattock 22:24:46 is that up-to-date? dazo 22:25:23 pretty much I did go through a little while ago, where I cleaned up a bit 22:25:41 mattock 22:27:30 what's our 2.3 schedule? dazo 22:27:41 screwed up? mattock 22:27:42 the original schedule went out of the door a while back yeah 22:27:44 cron2 22:28:33 I want to do more platform cleanups before 2.3 mattock 22:28:34 I would postpone any major build system changes to post-2.3 period cron2 22:28:42 mattock: +1 mattock 22:28:44 there's "enough stuff" there already cron2 22:29:07 let's aim for early feb 2012 for a first 2.3 beta dazo 22:29:22 yeah, that sounds reasonable mattock 22:29:57 #78 sounds like a more generic problem with <connection> profiles I recall Jason Haar complaining (rightly) about those in another context 22:30:11 I also recall that was discussed a long while ago 22:30:21 dazo 22:31:27 yeah' mattock 22:31:46 can we/should we fix this in 2.3? we can always make new releases if we feel like it 22:32:01 dazo 22:32:47 Yeah,I'm reluctant to say "yes, lets fix it!" ... as we have quite some things which needs to be looked at our table but I'm also that pragmatic that if people don't whine about stuff that often ... is it that needed to fix such stuff urgently? 22:33:16 #78 has been uncommented for 10 months 22:33:42 (we probably need some bug vote system) 22:33:57 mattock 22:34:03 that'd help then we'd need somebody to fix the upvoted bugs 22:34:21 well, better to fix upvoted bugs than bugs nobody really cares about 22:34:41 dazo 22:35:03 exactly mattock 22:35:27 #110 would be nice to have, but requires some Windows service knowledge dazo 22:35:37 I don't mind letting #78 slip 2.3 ... if it gets noisy, let's pull it into 2.4 or 2.3.x if urgent mattock 22:35:41 and nobody has touched the OpenVPN service code in many, many years #78 is on the border of "bug fix" and "new feature" 22:36:06 dazo 22:36:10 agreed ... #110 would be nice to fix ... is that something d12fk could look at? mattock 22:36:11 not sure which one it is dazo 22:36:30 considering the few complaints about it .... -> feature mattock 22:38:21 added milestone 2.4 moving #78 there 22:38:26 dazo 22:38:43 lets see what happens then mattock 22:40:36 let's see what else... #153 is easy fix 22:41:12 I'll do it 22:41:16 #151 and #152 should be doable if 2.3 comes out around Christmas 22:41:47 dazo: you fixed #34? 22:42:20 dazo looks 22:42 cron2 22:43:15 that's actually a different one, and I'm not sure I understand this this is more an installer issue than a openvpn.exe runtime thing 22:43:40 dazo 22:43:52 it's requested that OpenVPN installation does not update the environment table with paths for openvpn/openssl binaries which might make easy-rsa on windows explode when it doesn't find openssl.exe 22:44:15 mattock 22:44:30 ah, read it too quickly yes, setpath.nsi does that magic 22:45:20 I can probably fix this easily 22:45:29 dazo 22:45:59 if we can avoid updating environment variables, that'd be the very best ... if not easy, let's close it it's not a high profile bug, I believe 22:46:09 mattock 22:48:22 well, no-one else has commented on the bug report, so it probably affects a limited subset of users #73 should be easy to fix, simply print out a warning if ccd dir can't be opened 22:49:54 cron2 calls it a day for today. wife is starting to get annoyed 22:50 mattock 22:50:18 what about #106? cron2: that's always bad 22:50:49 see you later 22:50:55 dazo 22:51:20 #73 should be fixed, I believe ... not sure though mattock 22:54:48 did not find anything from git logs dazo 22:55:37 I know I wrote some patches which did a lot of file path checks hmmm ... maybe it slipped my own patch queue ... 22:55:50 mattock 22:56:19 ok, let's not close it yet, then then we got two more: https://community.openvpn.net/openvpn/ticket/61 22:56:34 https://community.openvpn.net/openvpn/ticket/106 22:56:41 #61 is being handled by cron2 22:57:04 dazo 22:58:38 that might be another pebkac, unless cron2 have discovered something potential ... could be it has been solved .... no response in 14 months, might indicate so mattock 22:59:36 in win32.c: fp = fopen ("c:\\windows\\system32\\route.exe", "rb"); also a couple more in the same file 22:59:53 dazo 23:00:46 oh crap well, I only see that one when greping for "c:\" 23:01:46 mattock 23:02:43 grep -irn "c...windows" * gives three matches in win32.c 23:02:57 dazo 23:03:39 the one on 108 and 877, I don't dare to touch but 89, must be fixed 23:03:47 108 and 877 just sets some environment variables, so they're "safer" 23:04:10 mattock 23:05:14 mkay, so we're more or less done with the 2.2.1 and 2.3 TODO review shall we call it a day, I'm getting tired 23:05:20 dazo 23:05:31 yeah, lets do that mattock 23:05:40 nice! I hope we get signed TAP-drivers soon, so that 2.2.2 can be released 23:06:12 and I think 2.3 in early January is fully doable 23:06:42 what do you think? 23:06:44 krzie 23:06:55 windows tap device got changed again? mattock 23:07:34 krzie: a bugfix dazo 23:08:02 krzie: small packets on tap driver doesn't go through krzie 23:08:44 ahh good to know dazo 23:09:14 yeah, cron2 got it fixed, and have done some quick tests ... all looking good andj 23:09:52 2.3 in early januari: that would be a beta? mattock 23:10:05 signed drivers would allow us to publish a really usable "beta" of 2.2.2 dazo 23:10:17 I think he meant early february ... but yeah, I'd say beta (or alpha, if we're not confident enough) 23:10:27 andj 23:10:46 cool mattock 23:10:59 I meant "first 2.3 alpha in early January" dazo 23:11:04 mattock: do we really need to go through betas for minor release? (2.2.2) 23:11:17 mattock 23:11:18 not really but a preview 23:11:21 krzie 23:11:25 whoa 2.3 that soon? 2.3 gets full ipv6 right? dazo 23:11:28 yeah krzie 23:11:37 you guys are badass ^5 23:11:40 dazo 23:11:53 that "soon", our initial idea would have been to have the first alphas already released ... but we screwed those plans mattock 23:11:55 I don't trust my Windows test boxes anymore, especially when it comes to TAP-drivers yeah, I think the original release date was last September 23:12:22 krzie 23:12:26 its still impressive ;] mattock 23:12:36 krzie: if it holds together dazo 23:12:52 compared to the 2.1 release .... anything is impressive when it comes to dates ... krzie 23:13:04 lol 2true mattock 23:13:35 ok, see you later, got to get some rest dazo 23:13:45 2.2 came ~1 year after 2.1, which was good ... and we're keeping that pace, which I think is more realistic for our working methods mattock 23:13:45 I'll try to summarize this tomorrow dazo 23:13:54 mattock: thx a lot! mattock 23:14:04 np, good that you made it today I was afraid the meeting had become a stub 23:14:24 dazo 23:14:29 I'm sorry about that ... but life is just too hectic these days, and now the body is soon going to protest, so I need to calm down too 23:14:54 mattock 23:14:56 one more thing... we should probably quickly review the bug reports with no milestone dazo even feels he is more grumpier than usually 23:15 mattock 23:15:20 take your time, we're not really in any hurry dazo 23:15:44 mattock: yeah, that's a good point ... I've went through most of of them ... and decided to let most of them stay ... some I picked for 2.2.2 and for 2.3, but that's about it mattock 23:15:58 I look at a few which seemed obsolete dazo 23:16:11 yeah, some might be mattock 23:16:14 I'll review the rest and we can discuss them in another meeting or unofficially e.g. one bug with linux 2.4 kernels 23:16:27 dazo goes to try to look for the missing file access check patch before closing for today 23:16 mattock 23:16:32 not confirmed for 2.6 anyways, until next time... take care guys! 23:16:50 dazo 23:17:01 2.4 kernels .... uhm ... wontfix ... RHEL3 was the last RHEL release with 2.4 kernel ... and that's EOL dazo just found something nasty in 'master' ... 23:31 dazo 23:31:29 ./openvpn --dev tun ..... this behaves bad andj 23:31:55 that's weird, I use that in some of my tests dazo need to say it again ... he loves 'git bisect' .... 5 more steps 23:32 dazo 23:32:53 I'm only starting openvpn with --dev tun ... no more arguments it's not a valid config ... but it's something I do to test things some times 23:33:04 andj 23:33:11 ah, ok dazo 23:33:27 the faulty one spews out: Thu Nov 24 22:33:15 2011 read from TUN/TAP : File descriptor in bad state (code=77) 23:33:28 constantly 23:33:30 the good one just exits 23:33:35 andj 23:33:45 heading off as well... dazo 23:34:23 enjoy the evening andj 23:34:46 thanks It's 10:30PM here though dazo 23:35:00 here too hmmm 23:35:53
