Re: [Openvpn-devel] [PATCH 00/35] build revolution

[Alon Bar-Lev]

Checked again, and working.

On Fri, Mar 16, 2012 at 7:43 PM, Alon Bar-Lev  wrote:
> It should be:
>
> CHOST=i686-w64-mingw32 CBUILD=i686-pc-cygwin
>
> On Fri, Mar 16, 2012 at 7:25 PM, Athanasios Douitsis  
> wrote:
>> I have installed cygwin just two days ago. And I issue:
>>
>> CHOST=i686-pc-mingw32 CBUILD=i686-pc-linux-gnu ./build
>>
>>
>>
>>
>> On Fri, Mar 16, 2012 at 7:05 PM, Alon Bar-Lev  wrote:
>>>
>>> Which toolchain do you use?
>>> It looks like you are trying to use an old toolchain...
>>>
>>> On Fri, Mar 16, 2012 at 6:51 PM, Athanasios Douitsis 
>>> wrote:
>>> > Hi everyone,
>>> >
>>> > Just to give an update, compilation on Alon's generic/ fails when it
>>> > tries
>>> > to compile openvpn with messages like:
>>> >
>>> > In file included from base64.c:40:0:
>>> > syshead.h:345:22: fatal error: ntddndis.h: No such file or directory
>>> > etc.
>>> >
>>> > ntddndis.h can be found in several places i.e. /usr/include/w32api/ddk,
>>> > but
>>> > including that path manually results in duplicate definitions and the
>>> > build
>>> > brakes again. Besides, I'm not sure including the path manually is the
>>> > right
>>> > thing to do.
>>> >
>>> > Ref: also my message from the 9th of March, where I had a similar
>>> > problem in
>>> > a completely different build environment in different builder system.
>>> > And
>>> > this has occurred with 2.3alpha1, not before.
>>> >
>>> > Cheers,
>>> > Athanasios
>>> >
>>> >
>>> >
>>> >
>>> > On Thu, Mar 15, 2012 at 1:39 AM, Alon Bar-Lev 
>>> > wrote:
>>> >>
>>> >> Next step is for you to create an installer :)
>>> >> Use the windows-nsis scripts.
>>> >>
>>> >> On Thu, Mar 15, 2012 at 1:37 AM, Athanasios Douitsis
>>> >> 
>>> >> wrote:
>>> >> >
>>> >> >
>>> >> > On Thu, Mar 15, 2012 at 1:19 AM, Alon Bar-Lev 
>>> >> > wrote:
>>> >> >>
>>> >> >> On Thu, Mar 15, 2012 at 1:05 AM, Athanasios Douitsis
>>> >> >> 
>>> >> >> wrote:
>>> >> >> > I was just thinking loudly, definitely not asking for someone to
>>> >> >> > write
>>> >> >> > it
>>> >> >> > and replace the existing build process(es). Having said that, I'd
>>> >> >> > like
>>> >> >> > to
>>> >> >> > clarify that what I meant is this would not be an additional
>>> >> >> > dependency
>>> >> >> > on
>>> >> >> > top of others, since neither cygwin nor msvc would be needed
>>> >> >> > anymore.
>>> >> >> > Anyway, not important, just a thought.
>>> >> >>
>>> >> >> Visual studio build is for compatibility for people who insist of
>>> >> >> using
>>> >> >> it.
>>> >> >>
>>> >> >> The "generic" build system is pure cross compile / native build
>>> >> >> system
>>> >> >> for dependencies and openvpn. It compiles openvpn using a given
>>> >> >> toolchain to any environment.
>>> >> >>
>>> >> >> For example, you can use it to compile at Linux for Linux on power
>>> >> >> pc
>>> >> >> or to Linux on arm.
>>> >> >> As a side effect you can also compile openvpn on Linux to windows
>>> >> >> using
>>> >> >> mingw.
>>> >> >> This exact same script without any modification can be used on
>>> >> >> Windows
>>> >> >> in cygwin environment to cross compile to windows native.
>>> >> >>
>>> >> >> So at the larger picture the target is to maintain a single build
>>> >> >> system for all environment... same dependencies, same utilities.
>>> >> >>
>>> >> >> Alon
>>> >> >
>>> >> >
>>> >> > Thanks for taking the time to explain! I'll be happy to provide as
>>> >> > much
>>> >> > feedback as possible on the windows native case with cygwin.
>>> >> >
>>> >> > Best regards,
>>> >> > --
>>> >> > Athanasios Douitsis
>>> >> >
>>> >> >
>>> >> >
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Athanasios Douitsis
>>> >
>>> >
>>> >
>>
>>
>>
>>
>> --
>> Athanasios Douitsis
>>
>>
>>

Re: [Openvpn-devel] [PATCH 35/52] build: proper selinux detection and usage

[Mr Dash Four]

However, from my experience it is not needed, people are most capable
of manage this without creating noise.
  
On the contrary, displaying meaningful error messages from configure is 
*never* a "noise". As Fabian pointed out - quite rightly - if make fails 
due to wrong/incorrect/missing dependencies then it is a bug in 
configure, no ifs, no buts, therefore displaying an error messages when 
some of the headers/libs are missing or misplaced makes perfect sense.

Re: [Openvpn-devel] [PATCH 00/35] build revolution

[Alon Bar-Lev]

It should be:

CHOST=i686-w64-mingw32 CBUILD=i686-pc-cygwin

On Fri, Mar 16, 2012 at 7:25 PM, Athanasios Douitsis  wrote:
> I have installed cygwin just two days ago. And I issue:
>
> CHOST=i686-pc-mingw32 CBUILD=i686-pc-linux-gnu ./build
>
>
>
>
> On Fri, Mar 16, 2012 at 7:05 PM, Alon Bar-Lev  wrote:
>>
>> Which toolchain do you use?
>> It looks like you are trying to use an old toolchain...
>>
>> On Fri, Mar 16, 2012 at 6:51 PM, Athanasios Douitsis 
>> wrote:
>> > Hi everyone,
>> >
>> > Just to give an update, compilation on Alon's generic/ fails when it
>> > tries
>> > to compile openvpn with messages like:
>> >
>> > In file included from base64.c:40:0:
>> > syshead.h:345:22: fatal error: ntddndis.h: No such file or directory
>> > etc.
>> >
>> > ntddndis.h can be found in several places i.e. /usr/include/w32api/ddk,
>> > but
>> > including that path manually results in duplicate definitions and the
>> > build
>> > brakes again. Besides, I'm not sure including the path manually is the
>> > right
>> > thing to do.
>> >
>> > Ref: also my message from the 9th of March, where I had a similar
>> > problem in
>> > a completely different build environment in different builder system.
>> > And
>> > this has occurred with 2.3alpha1, not before.
>> >
>> > Cheers,
>> > Athanasios
>> >
>> >
>> >
>> >
>> > On Thu, Mar 15, 2012 at 1:39 AM, Alon Bar-Lev 
>> > wrote:
>> >>
>> >> Next step is for you to create an installer :)
>> >> Use the windows-nsis scripts.
>> >>
>> >> On Thu, Mar 15, 2012 at 1:37 AM, Athanasios Douitsis
>> >> 
>> >> wrote:
>> >> >
>> >> >
>> >> > On Thu, Mar 15, 2012 at 1:19 AM, Alon Bar-Lev 
>> >> > wrote:
>> >> >>
>> >> >> On Thu, Mar 15, 2012 at 1:05 AM, Athanasios Douitsis
>> >> >> 
>> >> >> wrote:
>> >> >> > I was just thinking loudly, definitely not asking for someone to
>> >> >> > write
>> >> >> > it
>> >> >> > and replace the existing build process(es). Having said that, I'd
>> >> >> > like
>> >> >> > to
>> >> >> > clarify that what I meant is this would not be an additional
>> >> >> > dependency
>> >> >> > on
>> >> >> > top of others, since neither cygwin nor msvc would be needed
>> >> >> > anymore.
>> >> >> > Anyway, not important, just a thought.
>> >> >>
>> >> >> Visual studio build is for compatibility for people who insist of
>> >> >> using
>> >> >> it.
>> >> >>
>> >> >> The "generic" build system is pure cross compile / native build
>> >> >> system
>> >> >> for dependencies and openvpn. It compiles openvpn using a given
>> >> >> toolchain to any environment.
>> >> >>
>> >> >> For example, you can use it to compile at Linux for Linux on power
>> >> >> pc
>> >> >> or to Linux on arm.
>> >> >> As a side effect you can also compile openvpn on Linux to windows
>> >> >> using
>> >> >> mingw.
>> >> >> This exact same script without any modification can be used on
>> >> >> Windows
>> >> >> in cygwin environment to cross compile to windows native.
>> >> >>
>> >> >> So at the larger picture the target is to maintain a single build
>> >> >> system for all environment... same dependencies, same utilities.
>> >> >>
>> >> >> Alon
>> >> >
>> >> >
>> >> > Thanks for taking the time to explain! I'll be happy to provide as
>> >> > much
>> >> > feedback as possible on the windows native case with cygwin.
>> >> >
>> >> > Best regards,
>> >> > --
>> >> > Athanasios Douitsis
>> >> >
>> >> >
>> >> >
>> >
>> >
>> >
>> >
>> > --
>> > Athanasios Douitsis
>> >
>> >
>> >
>
>
>
>
> --
> Athanasios Douitsis
>
>
>

Re: [Openvpn-devel] [PATCH 00/35] build revolution

[Athanasios Douitsis]

I have installed cygwin just two days ago. And I issue:

CHOST=i686-pc-mingw32 CBUILD=i686-pc-linux-gnu ./build



On Fri, Mar 16, 2012 at 7:05 PM, Alon Bar-Lev  wrote:

> Which toolchain do you use?
> It looks like you are trying to use an old toolchain...
>
> On Fri, Mar 16, 2012 at 6:51 PM, Athanasios Douitsis 
> wrote:
> > Hi everyone,
> >
> > Just to give an update, compilation on Alon's generic/ fails when it
> tries
> > to compile openvpn with messages like:
> >
> > In file included from base64.c:40:0:
> > syshead.h:345:22: fatal error: ntddndis.h: No such file or directory
> > etc.
> >
> > ntddndis.h can be found in several places i.e. /usr/include/w32api/ddk,
> but
> > including that path manually results in duplicate definitions and the
> build
> > brakes again. Besides, I'm not sure including the path manually is the
> right
> > thing to do.
> >
> > Ref: also my message from the 9th of March, where I had a similar
> problem in
> > a completely different build environment in different builder system. And
> > this has occurred with 2.3alpha1, not before.
> >
> > Cheers,
> > Athanasios
> >
> >
> >
> >
> > On Thu, Mar 15, 2012 at 1:39 AM, Alon Bar-Lev 
> wrote:
> >>
> >> Next step is for you to create an installer :)
> >> Use the windows-nsis scripts.
> >>
> >> On Thu, Mar 15, 2012 at 1:37 AM, Athanasios Douitsis <
> aduit...@gmail.com>
> >> wrote:
> >> >
> >> >
> >> > On Thu, Mar 15, 2012 at 1:19 AM, Alon Bar-Lev 
> >> > wrote:
> >> >>
> >> >> On Thu, Mar 15, 2012 at 1:05 AM, Athanasios Douitsis
> >> >> 
> >> >> wrote:
> >> >> > I was just thinking loudly, definitely not asking for someone to
> >> >> > write
> >> >> > it
> >> >> > and replace the existing build process(es). Having said that, I'd
> >> >> > like
> >> >> > to
> >> >> > clarify that what I meant is this would not be an additional
> >> >> > dependency
> >> >> > on
> >> >> > top of others, since neither cygwin nor msvc would be needed
> anymore.
> >> >> > Anyway, not important, just a thought.
> >> >>
> >> >> Visual studio build is for compatibility for people who insist of
> using
> >> >> it.
> >> >>
> >> >> The "generic" build system is pure cross compile / native build
> system
> >> >> for dependencies and openvpn. It compiles openvpn using a given
> >> >> toolchain to any environment.
> >> >>
> >> >> For example, you can use it to compile at Linux for Linux on power pc
> >> >> or to Linux on arm.
> >> >> As a side effect you can also compile openvpn on Linux to windows
> using
> >> >> mingw.
> >> >> This exact same script without any modification can be used on
> Windows
> >> >> in cygwin environment to cross compile to windows native.
> >> >>
> >> >> So at the larger picture the target is to maintain a single build
> >> >> system for all environment... same dependencies, same utilities.
> >> >>
> >> >> Alon
> >> >
> >> >
> >> > Thanks for taking the time to explain! I'll be happy to provide as
> much
> >> > feedback as possible on the windows native case with cygwin.
> >> >
> >> > Best regards,
> >> > --
> >> > Athanasios Douitsis
> >> >
> >> >
> >> >
> >
> >
> >
> >
> > --
> > Athanasios Douitsis
> >
> >
> >
>



-- 
Athanasios Douitsis

Re: [Openvpn-devel] [PATCH 00/35] build revolution

[Alon Bar-Lev]

Which toolchain do you use?
It looks like you are trying to use an old toolchain...

On Fri, Mar 16, 2012 at 6:51 PM, Athanasios Douitsis  wrote:
> Hi everyone,
>
> Just to give an update, compilation on Alon's generic/ fails when it tries
> to compile openvpn with messages like:
>
> In file included from base64.c:40:0:
> syshead.h:345:22: fatal error: ntddndis.h: No such file or directory
> etc.
>
> ntddndis.h can be found in several places i.e. /usr/include/w32api/ddk, but
> including that path manually results in duplicate definitions and the build
> brakes again. Besides, I'm not sure including the path manually is the right
> thing to do.
>
> Ref: also my message from the 9th of March, where I had a similar problem in
> a completely different build environment in different builder system. And
> this has occurred with 2.3alpha1, not before.
>
> Cheers,
> Athanasios
>
>
>
>
> On Thu, Mar 15, 2012 at 1:39 AM, Alon Bar-Lev  wrote:
>>
>> Next step is for you to create an installer :)
>> Use the windows-nsis scripts.
>>
>> On Thu, Mar 15, 2012 at 1:37 AM, Athanasios Douitsis 
>> wrote:
>> >
>> >
>> > On Thu, Mar 15, 2012 at 1:19 AM, Alon Bar-Lev 
>> > wrote:
>> >>
>> >> On Thu, Mar 15, 2012 at 1:05 AM, Athanasios Douitsis
>> >> 
>> >> wrote:
>> >> > I was just thinking loudly, definitely not asking for someone to
>> >> > write
>> >> > it
>> >> > and replace the existing build process(es). Having said that, I'd
>> >> > like
>> >> > to
>> >> > clarify that what I meant is this would not be an additional
>> >> > dependency
>> >> > on
>> >> > top of others, since neither cygwin nor msvc would be needed anymore.
>> >> > Anyway, not important, just a thought.
>> >>
>> >> Visual studio build is for compatibility for people who insist of using
>> >> it.
>> >>
>> >> The "generic" build system is pure cross compile / native build system
>> >> for dependencies and openvpn. It compiles openvpn using a given
>> >> toolchain to any environment.
>> >>
>> >> For example, you can use it to compile at Linux for Linux on power pc
>> >> or to Linux on arm.
>> >> As a side effect you can also compile openvpn on Linux to windows using
>> >> mingw.
>> >> This exact same script without any modification can be used on Windows
>> >> in cygwin environment to cross compile to windows native.
>> >>
>> >> So at the larger picture the target is to maintain a single build
>> >> system for all environment... same dependencies, same utilities.
>> >>
>> >> Alon
>> >
>> >
>> > Thanks for taking the time to explain! I'll be happy to provide as much
>> > feedback as possible on the windows native case with cygwin.
>> >
>> > Best regards,
>> > --
>> > Athanasios Douitsis
>> >
>> >
>> >
>
>
>
>
> --
> Athanasios Douitsis
>
>
>

Re: [Openvpn-devel] [PATCH 00/35] build revolution

[Athanasios Douitsis]

Hi everyone,

Just to give an update, compilation on Alon's generic/ fails when it tries
to compile openvpn with messages like:

In file included from base64.c:40:0:
syshead.h:345:22: fatal error: ntddndis.h: No such file or directory
etc.

ntddndis.h can be found in several places i.e. /usr/include/w32api/ddk, but
including that path manually results in duplicate definitions and the build
brakes again. Besides, I'm not sure including the path manually is the
right thing to do.

Ref: also my message from the 9th of March, where I had a similar problem
in a completely different build environment in different builder system.
And this has occurred with 2.3alpha1, not before.

Cheers,
Athanasios



On Thu, Mar 15, 2012 at 1:39 AM, Alon Bar-Lev  wrote:

> Next step is for you to create an installer :)
> Use the windows-nsis scripts.
>
> On Thu, Mar 15, 2012 at 1:37 AM, Athanasios Douitsis 
> wrote:
> >
> >
> > On Thu, Mar 15, 2012 at 1:19 AM, Alon Bar-Lev 
> wrote:
> >>
> >> On Thu, Mar 15, 2012 at 1:05 AM, Athanasios Douitsis <
> aduit...@gmail.com>
> >> wrote:
> >> > I was just thinking loudly, definitely not asking for someone to write
> >> > it
> >> > and replace the existing build process(es). Having said that, I'd like
> >> > to
> >> > clarify that what I meant is this would not be an additional
> dependency
> >> > on
> >> > top of others, since neither cygwin nor msvc would be needed anymore.
> >> > Anyway, not important, just a thought.
> >>
> >> Visual studio build is for compatibility for people who insist of using
> >> it.
> >>
> >> The "generic" build system is pure cross compile / native build system
> >> for dependencies and openvpn. It compiles openvpn using a given
> >> toolchain to any environment.
> >>
> >> For example, you can use it to compile at Linux for Linux on power pc
> >> or to Linux on arm.
> >> As a side effect you can also compile openvpn on Linux to windows using
> >> mingw.
> >> This exact same script without any modification can be used on Windows
> >> in cygwin environment to cross compile to windows native.
> >>
> >> So at the larger picture the target is to maintain a single build
> >> system for all environment... same dependencies, same utilities.
> >>
> >> Alon
> >
> >
> > Thanks for taking the time to explain! I'll be happy to provide as much
> > feedback as possible on the windows native case with cygwin.
> >
> > Best regards,
> > --
> > Athanasios Douitsis
> >
> >
> >
>



-- 
Athanasios Douitsis

Re: [Openvpn-devel] [PATCH 35/52] build: proper selinux detection and usage

[Alon Bar-Lev]

On Fri, Mar 16, 2012 at 6:29 PM, Fabian Knittel
 wrote:
> So it sounds as if we're actually somewhat in agreement! You don't
> want complex, automatic detection of non-standard situations and I
> agree wholeheartedly.
> But I _do_ want basic checking to achieve clear error messages at
> configuration time, not obscure build errors far later in the build
> process. Rule of thumb: If "make" fails due to missing or wrong
> dependencies, it's a bug in configure, because it didn't detect the
> problem beforehand.

I understand your argument.
However, from my experience it is not needed, people are most capable
of manage this without creating noise.
I suggest to leave this as-is and if for some reason the audience of
openvpn is different than other project I handle, we modify it.

Alon.

Re: [Openvpn-devel] [PATCH 35/52] build: proper selinux detection and usage

[Fabian Knittel]

Hi Alon,

>> AC_CHECK_LIB([selinux], [setcon], [SELINUX_LIBS="-lselinux"])
>>
>> versus
>>
>> AC_CHECK_HEADER([selinux/selinux.h], [
>>    AC_CHECK_LIB([selinux], [setcon], [SELINUX_LIBS="-lselinux"],
>>        [AC_MSG_RESULT([SELinux library not found.])]
>>    )],  [AC_MSG_ERROR([SELinux headers not found.])]
>> )
>>
>> doesn't really qualify as "very complex" to me.
>
> This is untrue.
> As most features needs custom CFLAGs as well, it looks like:
>
> old_CFLAGS="${CFLAGS}"
> CFLAGS="${CFLAGS} ${SOME_CFLAGS}"
> AC_CHECK_HEADER([...])
> CFLAGS="${old_CFLAGS}"

I can see where this would be necessary if you wanted to "search
additional non-standard paths for the libraries and headers" (see my
last email), but it wouldn't be necessary for the simple case, where
you want to make sure that library and header are available and
compilable with the flags the user provided.

So it sounds as if we're actually somewhat in agreement! You don't
want complex, automatic detection of non-standard situations and I
agree wholeheartedly.
But I _do_ want basic checking to achieve clear error messages at
configuration time, not obscure build errors far later in the build
process. Rule of thumb: If "make" fails due to missing or wrong
dependencies, it's a bug in configure, because it didn't detect the
problem beforehand.

Cheers
Fabian

Re: [Openvpn-devel] [PATCH 30/52] build: add libtool + windows resources for executables

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 16/03/12 13:02, Samuli Seppänen wrote:
> Hi,
> 
> This patch was ACKed in the IRC meeting on 15th Mar 2012:
> 
> 
> 
> However some of the lines in "src/openvpn/openvpn_win32_resources.rc" 
> may need to be fixed:
> 
> VALUE "CompanyName", "OpenVPN.net" VALUE "LegalCopyright", "Copyright
> � OpenVPN Project"
> 
> Quoting 
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa381058%28v=vs.85%29.aspx
>
>  "CompanyNameCompany that produced the file, for example,
> "Microsoft Corporation" or "Standard Microsystems Corporation, Inc."
> This string is required."
> 
> "LegalCopyrightCopyright notices that apply to the file. This
> should include the full text of all notices, legal symbols, copyright
> dates, and so on. This string is optional."
> 
> I think we could use the same entity name (e.g. "OpenVPN project") in 
> both fields. I also think that the choice of wording revolves around 
> copyright ownership... in 2.1.x series James Yonan/OpenVPN
> Technologies, Inc. owned _most_ of the copyrights to the codebase.
> However, in this post-2.3-alpha1 age, copyrights to very large parts
> of the codebase belong to community developers. So, attributing
> copyright to "OpenVPN Technologies, Inc. and contributors" would
> probably not be proper.
> 
> So, what should we call this "entity" that owns the copyrights to the 
> codebase?

I would even go back to OpenVPN 2.2-beta1.  Which includes over 150
patches from the community.  But that's nit-picking.

I really think attributing the *project* is the better.  The company
itself does not really own the copyright to the contributed code.
However the community and the company are both heavily involved in the
project.

Just an idea ... what about to see how other open source projects solve
this in Windows builds?  Not sure about anything concrete, but maybe
virtio drivers for Windows is a place worth checking out?  (virtio
drivers in Windows are used for paravirt enabling when running as guest
on a KVM host; I believe these drivers are developed with a community
project these days)


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9jZ5wACgkQDC186MBRfrogqgCeMA+4shPIDUvIMpHw2uYsSi3H
lLAAnAsqw5C4+Hli+PwqejYHkaGoavcN
=+TP5
-END PGP SIGNATURE-

Re: [Openvpn-devel] New generic buildsystem: lzo enabled or disabled by default?

[Gert Doering]

Hi,

On Fri, Mar 16, 2012 at 02:29:22PM +0100, Fabian Knittel wrote:
> In my opinion, the build defaults should reflect what the project
> considers as the recommended defaults - the features we want to see in
> every typical OpenVPN server and client. 

Fully seconded.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpom77KjFAtz.pgp
Description: PGP signature

Re: [Openvpn-devel] New generic buildsystem: lzo enabled or disabled by default?

[Gert Doering]

Hi,

On Fri, Mar 16, 2012 at 03:07:24PM +0200, Samuli Seppänen wrote:
> Having as much stuff as possible disabled by default and then enabled
> selectively _feels_ cleaner. But I'm fine with either approach.

I think the default should be "what most people are using".

 - enable crypto and ssl
 - enable lzo

> Personally, I don't think we'll get many complaints if lzo is disabled
> by default. As Alon points out, this is not the only thing packagers
> need to adjust to, so they expect things to work differently. Hopefully
> this translates to them paying some attention while doing the builds :).

It would annoy me a lot to have to remember to add --enable-lzo whenever
I build, and I see no compelling reason to change the default.

About the only time you want to disable lzo is if you need to save code
space, like on very small embedded systems - and that's the exception,
not the common case.

(And I don't see any reason why "the packages that people ship" should
be built with non-default options, except "the default options do not
make sense, so all the packagers need to change the options")

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgp1OHOTl1veX.pgp
Description: PGP signature

Re: [Openvpn-devel] New generic buildsystem: lzo enabled or disabled by default?

[Fabian Knittel]

Hi Alon,

2012/3/16 Alon Bar-Lev :
> On Fri, Mar 16, 2012 at 3:29 PM, Fabian Knittel
>  wrote:
>> In my opinion, the build defaults should reflect what the project
>> considers as the recommended defaults - the features we want to see in
>> every typical OpenVPN server and client.
>
> I strongly against that approach.
> This is a common mix up between distribution and software project.
>
> A software project provides the possibility of using the software in
> different configurations.
> A distribution is in charge of the "typical" configuration.

A typical free software project distributes the source as the primary
artefact, correct.  IMHO it also communicates a set of defaults,
especially for software that needs to interact across platforms and
architectures.  Part of communicating what those defaults are, is done
by providing a default build configuration.

A dedicated distribution project (like Gentoo or Debian) is in charge
of allowing a set of software to properly run (binary distribution) or
compile (source distribution) in combination with all the other
available software.
Whether the program is built on a 64 bit processor, where the
libraries are to be found, which SSL library is to be used, etc. are
questions a distribution may answer for you. Whether to enable
encryption or a specific compression mode would be something that the
distribution should only fiddle with in special cases (for example if
it's an embedded distribution).

I don't want to be able to connect to an OpenVPN server depending on
what distribution it was built on.


> Your comment is true for rhel packager, people expect that yum install
> openvpn will be a "typical" rhel configuration, what exactly this
> configuration is depends on distribution procedures.

OpenVPN provides a source distribution. People expect configure, make,
make install to provide a "typical" OpenVPN configuration.

> Why is lzo different than PKCS#11 or selinux? Which are "typical"?
> Mind "typical" is probably different between server and client.

It's not. I'm just saying that what we set as a default in the build
system is meaningful and should match what we document as the default
in the rest of the documentation.

> The software project should not make any assumption of its usage, nor
> enable/disable features for the sake of best practices instead of
> proper documentation.

Setting build defaults is a communication device which should be used
_in addition_ to other documentation.

Cheers
Fabian

Re: [Openvpn-devel] New generic buildsystem: lzo enabled or disabled by default?

[Alon Bar-Lev]

On Fri, Mar 16, 2012 at 3:29 PM, Fabian Knittel
 wrote:
> In my opinion, the build defaults should reflect what the project
> considers as the recommended defaults - the features we want to see in
> every typical OpenVPN server and client.

I strongly against that approach.
This is a common mix up between distribution and software project.

A software project provides the possibility of using the software in
different configurations.
A distribution is in charge of the "typical" configuration.

Your comment is true for rhel packager, people expect that yum install
openvpn will be a "typical" rhel configuration, what exactly this
configuration is depends on distribution procedures.

Why is lzo different than PKCS#11 or selinux? Which are "typical"?
Mind "typical" is probably different between server and client.

The software project should not make any assumption of its usage, nor
enable/disable features for the sake of best practices instead of
proper documentation.

Alon.

Re: [Openvpn-devel] New generic buildsystem: lzo enabled or disabled by default?

[Fabian Knittel]

Hi,

2012/3/16 Alon Bar-Lev :
> If we do not want to do auto detection, enabling optional components
> may lead to configure failure, and force the user to explicitly
> disable this feature.
>
> It is possible, and I don't mind so much, however, I prefer configure
> to use the minimum absolutely needed components by default, and in
> majority of valid cases succeed.
>
> Disabling by default does not effect users nor building via build
> script nor building via package management (rpmbuild, deb). It only
> effects people who build manually from sources.

In my opinion, the build defaults should reflect what the project
considers as the recommended defaults - the features we want to see in
every typical OpenVPN server and client. Apart from the
Windows-binaries, the _source_ is the relevant artefact that gets
released as official "OpenVPN" and therefore the defaults in the build
system are important.

If we want to avoid confusing compile-time errors, we should present
useful and informative warnings to the user at configure-time: "Could
not find library X, if you want to compile without support for X, pass
--disable-X" or something similar. No need to hide this from the user.
(I haven't looked at the build system, so this type of error message
might already be present.)

While building a piece of software I often notice additional
dependencies based on what configure tells me. This then causes me to
install additional dev-packages / libraries before continuing
compilation. If we simply cut down the dependencies I'd probably
notice a missing feature much later, e.g. while debugging connection
problems...

The usual

  $ ./configure
  $ make
  $ make install

... should hold as few surprises as possible, IMHO.

Cheers
Fabian

Re: [Openvpn-devel] New generic buildsystem: lzo enabled or disabled by default?

[Samuli Seppänen]

> On Fri, Mar 16, 2012 at 2:47 PM, David Sommerseth
>  wrote:
>> The impact on this change mainly hits packagers on the Linux, *BSD and
>> Solaris packagers platforms - and those who do their own Windows builds.
>>  The official Windows builds we control and can make sure this feature is
>> enabled.
> Please keep in mind that this is not the only change packager will
> need to do when this is released.
> I rewrote the Gentoo ebuild, in preparation for this.
> I rewrote the spec file within the openvpn tree.
> When release of beta, a large note should be written for other
> packagers to update their packages for this version.
>
> Alon.
>
Having as much stuff as possible disabled by default and then enabled
selectively _feels_ cleaner. But I'm fine with either approach.

Personally, I don't think we'll get many complaints if lzo is disabled
by default. As Alon points out, this is not the only thing packagers
need to adjust to, so they expect things to work differently. Hopefully
this translates to them paying some attention while doing the builds :).

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

Re: [Openvpn-devel] New generic buildsystem: lzo enabled or disabled by default?

[Alberto Gonzalez Iniesta]

On Fri, Mar 16, 2012 at 02:09:44PM +0200, Alon Bar-Lev wrote:
> On Fri, Mar 16, 2012 at 1:47 PM, Alberto Gonzalez Iniesta
>  wrote:
> > Since support for LZO is enabled/disabled in runtime configuration, I
> > don't see why disabling it on built time, thus limiting its use later.
> 
> We are talking about the build.

I know.

> Runtime is irrelevant.

Sure. Specially after you build a package that no longer supports a
feature present before.


-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
agi@(inittab.org|debian.org)| en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 9782 04E7 2B75 405C F5E9  0C81 C514 AF8E 4BA4 01C3

Re: [Openvpn-devel] New generic buildsystem: lzo enabled or disabled by default?

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 16/03/12 13:09, Alon Bar-Lev wrote:
> On Fri, Mar 16, 2012 at 1:47 PM, Alberto Gonzalez Iniesta 
>  wrote:
>> Since support for LZO is enabled/disabled in runtime configuration,
>> I don't see why disabling it on built time, thus limiting its use
>> later.
> 
> We are talking about the build. Runtime is irrelevant.


Correct.  However, this may indirectly have an impact on end users, if
the packager is not aware of this change.  And as 'enabled' has been the
standard so far, forcing you to explicit disable LZO, this change may
cause some compatibility issues.

The impact on this change mainly hits packagers on the Linux, *BSD and
Solaris packagers platforms - and those who do their own Windows builds.
 The official Windows builds we control and can make sure this feature is
enabled.


But let me redirect this discussion slightly.  What is the *benefit* of
disabling LZO by default?

The argument I see why we should keep it enabled, is that this has been
the default since almost the very beginning - it is kind of expected in
most environments that LZO support is available.

The benefit I see from disabling it, is that less default dependencies
are needed to build it.  But it requires awareness to remember to enable
this feature when building, to stay compliant with what most end-users
expect.


If I could be sure we would not get a rush of "OpenVPN 2.3 doesn't work
anymore!"-complaints, I couldn't really care less.  But as I fear that
many builds *may* break the end-users expectations, I'm more doubtful.
Of course, it all depends on the awareness of the packagers.  But I'm not
really convinced this is the most clever step we do.

Well, I'm torn into both directions, really.  And considering LZO
compression is in most cases a very useful feature, I'm beginning to lean
towards 'enabled as default'.  Unless I hear some really compelling
reasons why that's a bad idea - except of enforcing builders to make sure
lzo libs are installed or they should use --enable-lzo if they want this
feature. After all, the LZO feature has been enabled as default at least
since the OpenVPN 2.0 era.


Anyhow ... the patch which disables it by default, will be included as it
is.  If we decide to go back to 'enabled by default' we'll add that as an
patch on top of Alon's work.  So this is the current situation.



kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9jNm0ACgkQDC186MBRfrru9wCfY0VBkGpuxlkQYgTRm8XUwY0V
/CIAnjDzRMAMZuJUghW/e+KSfGk6JgRO
=l3kb
-END PGP SIGNATURE-

Re: [Openvpn-devel] [tap-windows 05/11] build: set default to newer ddk

[Samuli Seppänen]

I think we can drop WinDDK <= 5600 support entirely. If I'm not
mistaken, this means supporting Visual Studio 2008 and later only, which
is fine. Afaik the only "reason" to support Visual Studio 2005 and older
is Win2k support, which we don't need. OpenVPN 2.1.3 was the last
version with Win2k support anyways.

Besides that, it's an ACK.

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock


> Signed-off-by: Alon Bar-Lev 
> ---
>  src/prototypes.h |2 +-
>  src/tapdrvr.c|5 +
>  2 files changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/src/prototypes.h b/src/prototypes.h
> index 55454d5..18c566f 100755
> --- a/src/prototypes.h
> +++ b/src/prototypes.h
> @@ -202,7 +202,7 @@ VOID HookDispatchFunctions();
>  
>  #if ENABLE_NONADMIN
>  
> -#if DDKVER_MAJOR < 5600
> +#if defined(DDKVER_MAJOR) && DDKVER_MAJOR < 5600
>  /*
>   * Better solution for use on Vista DDK, but possibly not compatible with
>   * earlier DDKs:
> diff --git a/src/tapdrvr.c b/src/tapdrvr.c
> index 0df076a..0f75b77 100755
> --- a/src/tapdrvr.c
> +++ b/src/tapdrvr.c
> @@ -36,9 +36,6 @@
>  //==
>  
>  #include "common.h"
> -#ifndef DDKVER_MAJOR
> -#error DDKVER_MAJOR must be defined as the major number of the DDK Version
> -#endif
>  
>  #define NDIS_MINIPORT_DRIVER
>  #define BINARY_COMPATIBLE 0
> @@ -66,7 +63,7 @@
>  //
>  #define ENABLE_NONADMIN 1
>  
> -#if DDKVER_MAJOR < 5600
> +#if defined(DDKVER_MAJOR) && DDKVER_MAJOR < 5600
>  #include 
>  #include 
>  #include 

Re: [Openvpn-devel] [tap-windows 03/11] cleanup: remove warnings of redefinition of macros

[Samuli Seppänen]

ACK.

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

> Signed-off-by: Alon Bar-Lev 
> ---
>  src/resource.rc |5 +
>  1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/src/resource.rc b/src/resource.rc
> index 84884cf..8b2d2f6 100755
> --- a/src/resource.rc
> +++ b/src/resource.rc
> @@ -4,6 +4,11 @@
>  /* get VERSION */
>  #include "common.h"
>  
> +#undef VER_PRODUCTVERSION
> +#undef VER_PRODUCTVERSION_STR
> +#undef VER_COMPANYNAME_STR
> +#undef VER_PRODUCTNAME_STR
> +
>  /* VER_FILETYPE, VER_FILESUBTYPE, VER_FILEDESCRIPTION_STR
>   * and VER_INTERNALNAME_STR must be defined before including COMMON.VER
>   * The strings don't need a '\0', since common.ver has them.

Re: [Openvpn-devel] [tap-windows 04/11] debug: add DbgPrint support

[Samuli Seppänen]

The vDbgPrintEx[1] sends a message to the Windows kernel debugger, if
"DBG_PRINT" is defined. The va_start and va_end macros[2] fetch
function's optional arguments. They only move the list pointer around,
so va_start after va_end is safe.

I don't see a problem with this and it sounds useful, so it's an ACK.

[1]

[2] 

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock


> Signed-off-by: Alon Bar-Lev 
> ---
>  src/error.c |5 +
>  1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/src/error.c b/src/error.c
> index 5b25f48..0541bc3 100755
> --- a/src/error.c
> +++ b/src/error.c
> @@ -81,6 +81,11 @@ MyDebugPrint (const unsigned char* format, ...)
> NTSTATUS status;
> char *end;
>  
> +#ifdef DBG_PRINT
> +   va_start (args, format);
> +   vDbgPrintEx (DPFLTR_IHVNETWORK_ID, DPFLTR_INFO_LEVEL, format, 
> args);
> +   va_end (args);
> +#endif
> va_start (args, format);
> status = RtlStringCchVPrintfExA (g_Debug.text + g_Debug.out,
>  remaining,

Re: [Openvpn-devel] New generic buildsystem: lzo enabled or disabled by default?

[Alon Bar-Lev]

On Fri, Mar 16, 2012 at 1:47 PM, Alberto Gonzalez Iniesta
 wrote:
> Since support for LZO is enabled/disabled in runtime configuration, I
> don't see why disabling it on built time, thus limiting its use later.

We are talking about the build. Runtime is irrelevant.

Alon

Re: [Openvpn-devel] [PATCH 30/52] build: add libtool + windows resources for executables

[Alon Bar-Lev]

I left the OpenVPN.net not to cause copyright discussion :)
But here we are...
"The OpenVPN Project" is good for me.

2012/3/16 Samuli Seppänen :
> Hi,
>
> This patch was ACKed in the IRC meeting on 15th Mar 2012:
>
> 
>
> However some of the lines in "src/openvpn/openvpn_win32_resources.rc"
> may need to be fixed:
>
> VALUE "CompanyName", "OpenVPN.net"
> VALUE "LegalCopyright", "Copyright � OpenVPN Project"
>
> Quoting
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa381058%28v=vs.85%29.aspx
>
> "CompanyName    Company that produced the file, for example, "Microsoft
> Corporation" or "Standard Microsystems Corporation, Inc." This string is
> required."
>
> "LegalCopyright    Copyright notices that apply to the file. This should
> include the full text of all notices, legal symbols, copyright dates,
> and so on. This string is optional."
>
> I think we could use the same entity name (e.g. "OpenVPN project") in
> both fields. I also think that the choice of wording revolves around
> copyright ownership... in 2.1.x series James Yonan/OpenVPN Technologies,
> Inc. owned _most_ of the copyrights to the codebase. However, in this
> post-2.3-alpha1 age, copyrights to very large parts of the codebase
> belong to community developers. So, attributing copyright to "OpenVPN
> Technologies, Inc. and contributors" would probably not be proper.
>
> So, what should we call this "entity" that owns the copyrights to the
> codebase?
>
> --
> Samuli Seppänen
> Community Manager
> OpenVPN Technologies, Inc
>
> irc freenode net: mattock
>
>
> PS. I'll try to apply some  Git magic to produce concrete numbers
> regarding the copyright ownership in the OpenVPN codebase.
>
>
>> Signed-off-by: Alon Bar-Lev 
>> ---
>>  .gitignore                               |    6 
>>  Makefile.am                              |    5 +++-
>>  build/Makefile.am                        |   15 +++
>>  build/ltrc.inc                           |   23 
>>  configure.ac                             |   20 ++-
>>  src/openvpn/Makefile.am                  |    6 
>>  src/openvpn/openvpn_win32_resources.rc   |   41 
>> ++
>>  src/openvpnserv/Makefile.am              |    5 +++-
>>  src/openvpnserv/openvpnserv_resources.rc |   41 
>> ++
>>  version.m4                               |    1 +
>>  10 files changed, 160 insertions(+), 3 deletions(-)
>>  create mode 100644 build/Makefile.am
>>  create mode 100644 build/ltrc.inc
>>  create mode 100644 src/openvpn/openvpn_win32_resources.rc
>>  create mode 100644 src/openvpnserv/openvpnserv_resources.rc
>>
>> diff --git a/.gitignore b/.gitignore
>> index 46cd4c8..156b2c2 100644
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -26,6 +26,12 @@ depcomp
>>  stamp-h1
>>  install-sh
>>  missing
>> +ltmain.sh
>> +m4/libtool.m4
>> +m4/ltoptions.m4
>> +m4/ltsugar.m4
>> +m4/ltversion.m4
>> +m4/lt~obsolete.m4
>>
>>  doc/openvpn.8.html
>>  distro/rpm/openvpn.spec
>> diff --git a/Makefile.am b/Makefile.am
>> index 850074b..ebc2252 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -34,6 +34,9 @@ MAINTAINERCLEANFILES = \
>>         $(srcdir)/Makefile.in \
>>         $(srcdir)/config.h.in $(srcdir)/config.h.in~ $(srcdir)/configure \
>>         $(srcdir)/install-sh $(srcdir)/ltmain.sh $(srcdir)/missing \
>> +       $(srcdir)/m4/libtool.m4 $(srcdir)/m4/lt~obsolete.m4 \
>> +       $(srcdir)/m4/ltoptions.m4 $(srcdir)/m4/ltsugar.m4 \
>> +       $(srcdir)/m4/ltversion.m4 \
>>         $(srcdir)/depcomp $(srcdir)/aclocal.m4 \
>>         $(srcdir)/config.guess $(srcdir)/config.sub
>>
>> @@ -41,7 +44,7 @@ EXTRA_DIST = \
>>         contrib \
>>         debug
>>
>> -SUBDIRS = distro include src sample doc tests
>> +SUBDIRS = build distro include src sample doc tests
>>
>>  dist_doc_DATA = \
>>         COPYRIGHT.GPL \
>> diff --git a/build/Makefile.am b/build/Makefile.am
>> new file mode 100644
>> index 000..a993b20
>> --- /dev/null
>> +++ b/build/Makefile.am
>> @@ -0,0 +1,15 @@
>> +#
>> +#  OpenVPN -- An application to securely tunnel IP networks
>> +#             over a single UDP port, with support for SSL/TLS-based
>> +#             session authentication and key exchange,
>> +#             packet encryption, packet authentication, and
>> +#             packet compression.
>> +#
>> +#  Copyright (C) 2002-2010 OpenVPN Technologies, Inc. 
>> +#
>> +
>> +MAINTAINERCLEANFILES = \
>> +       $(srcdir)/Makefile.in
>> +
>> +EXTRA_DIST = \
>> +       ltrc.inc
>> diff --git a/build/ltrc.inc b/build/ltrc.inc
>> new file mode 100644
>> index 000..701f200
>> --- /dev/null
>> +++ b/build/ltrc.inc
>> @@ -0,0 +1,23 @@
>> +#
>> +#  OpenVPN -- An application to securely tunnel IP networks
>> +#             over a single UDP port, with support for SSL/TLS-based
>> +#             session authentication and key exchange,
>> 

Re: [Openvpn-devel] New generic buildsystem: lzo enabled or disabled by default?

[Alon Bar-Lev]

Or:
[1] http://permalink.gmane.org/gmane.network.openvpn.devel/5535

2012/3/16 Alon Bar-Lev :
> Sorry...
> [1] http://thread.gmane.org/gmane.network.openvpn.devel/5772/focus=5947
>
> 2012/3/16 Alon Bar-Lev :
>> Hello,
>>
>> Part of the reasoning was discussed here[1].
>>
>> If we do not want to do auto detection, enabling optional components
>> may lead to configure failure, and force the user to explicitly
>> disable this feature.
>>
>> It is possible, and I don't mind so much, however, I prefer configure
>> to use the minimum absolutely needed components by default, and in
>> majority of valid cases succeed.
>>
>> Disabling by default does not effect users nor building via build
>> script nor building via package management (rpmbuild, deb). It only
>> effects people who build manually from sources. These people should
>> not only consider the lzo enable/disable but many more configure
>> options so lzo is no exception.
>>
>> Alon.
>>
>> [1] http://thread.gmane.org/gmane.network.openvpn.devel/5772/focus=5811
>>
>> 2012/3/16 Samuli Seppänen :
>>> Hi all,
>>>
>>> In yesterday's meeting we reviewed this patch
>>>
>>> PATCH 39/52 build: proper lzo detection and usage
>>>  URL: http://thread.gmane.org/gmane.network.openvpn.devel/5772/focus=5811
>>>
>>> The patch was ACKed, but there was disagreement whether LZO should be 
>>> enabled or disabled by default. Whichever the case, it will only affect 
>>> people building OpenVPN, not the end-users. Official builds will continue 
>>> to have LZO support.
>>>
>>> Opinions?
>>>
>>> --
>>> Samuli Seppänen
>>> Community Manager
>>> OpenVPN Technologies, Inc
>>>
>>> irc freenode net: mattock
>>>
>>>
>>> --
>>> This SF email is sponsosred by:
>>> Try Windows Azure free for 90 days Click Here
>>> http://p.sf.net/sfu/sfd2d-msazure
>>> ___
>>> Openvpn-devel mailing list
>>> Openvpn-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] New generic buildsystem: lzo enabled or disabled by default?

[Alberto Gonzalez Iniesta]

On Fri, Mar 16, 2012 at 01:38:47PM +0200, Samuli Seppänen wrote:
> Hi all,
> 
> In yesterday's meeting we reviewed this patch
> 
> PATCH 39/52 build: proper lzo detection and usage
>  URL: http://thread.gmane.org/gmane.network.openvpn.devel/5772/focus=5811
> 
> The patch was ACKed, but there was disagreement whether LZO should be enabled 
> or disabled by default. Whichever the case, it will only affect people 
> building OpenVPN, not the end-users. Official builds will continue to have 
> LZO support.
> 
> Opinions?
> 

I'll still build Debian packages with LZO support (if I don't forget to
set the option when upgrading to the new version).

Since support for LZO is enabled/disabled in runtime configuration, I
don't see why disabling it on built time, thus limiting its use later.

Regards,

Alberto

-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
agi@(inittab.org|debian.org)| en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 9782 04E7 2B75 405C F5E9  0C81 C514 AF8E 4BA4 01C3

Re: [Openvpn-devel] [PATCH 30/52] build: add libtool + windows resources for executables

[Samuli Seppänen]

Hi,

This patch was ACKed in the IRC meeting on 15th Mar 2012:



However some of the lines in "src/openvpn/openvpn_win32_resources.rc"
may need to be fixed:

VALUE "CompanyName", "OpenVPN.net"
VALUE "LegalCopyright", "Copyright � OpenVPN Project"

Quoting
http://msdn.microsoft.com/en-us/library/windows/desktop/aa381058%28v=vs.85%29.aspx

"CompanyNameCompany that produced the file, for example, "Microsoft
Corporation" or "Standard Microsystems Corporation, Inc." This string is
required."

"LegalCopyrightCopyright notices that apply to the file. This should
include the full text of all notices, legal symbols, copyright dates,
and so on. This string is optional."

I think we could use the same entity name (e.g. "OpenVPN project") in
both fields. I also think that the choice of wording revolves around
copyright ownership... in 2.1.x series James Yonan/OpenVPN Technologies,
Inc. owned _most_ of the copyrights to the codebase. However, in this
post-2.3-alpha1 age, copyrights to very large parts of the codebase
belong to community developers. So, attributing copyright to "OpenVPN
Technologies, Inc. and contributors" would probably not be proper.

So, what should we call this "entity" that owns the copyrights to the
codebase?

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock


PS. I'll try to apply some  Git magic to produce concrete numbers
regarding the copyright ownership in the OpenVPN codebase.


> Signed-off-by: Alon Bar-Lev 
> ---
>  .gitignore   |6 
>  Makefile.am  |5 +++-
>  build/Makefile.am|   15 +++
>  build/ltrc.inc   |   23 
>  configure.ac |   20 ++-
>  src/openvpn/Makefile.am  |6 
>  src/openvpn/openvpn_win32_resources.rc   |   41 
> ++
>  src/openvpnserv/Makefile.am  |5 +++-
>  src/openvpnserv/openvpnserv_resources.rc |   41 
> ++
>  version.m4   |1 +
>  10 files changed, 160 insertions(+), 3 deletions(-)
>  create mode 100644 build/Makefile.am
>  create mode 100644 build/ltrc.inc
>  create mode 100644 src/openvpn/openvpn_win32_resources.rc
>  create mode 100644 src/openvpnserv/openvpnserv_resources.rc
>
> diff --git a/.gitignore b/.gitignore
> index 46cd4c8..156b2c2 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -26,6 +26,12 @@ depcomp
>  stamp-h1
>  install-sh
>  missing
> +ltmain.sh
> +m4/libtool.m4
> +m4/ltoptions.m4
> +m4/ltsugar.m4
> +m4/ltversion.m4
> +m4/lt~obsolete.m4
>
>  doc/openvpn.8.html
>  distro/rpm/openvpn.spec
> diff --git a/Makefile.am b/Makefile.am
> index 850074b..ebc2252 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -34,6 +34,9 @@ MAINTAINERCLEANFILES = \
> $(srcdir)/Makefile.in \
> $(srcdir)/config.h.in $(srcdir)/config.h.in~ $(srcdir)/configure \
> $(srcdir)/install-sh $(srcdir)/ltmain.sh $(srcdir)/missing \
> +   $(srcdir)/m4/libtool.m4 $(srcdir)/m4/lt~obsolete.m4 \
> +   $(srcdir)/m4/ltoptions.m4 $(srcdir)/m4/ltsugar.m4 \
> +   $(srcdir)/m4/ltversion.m4 \
> $(srcdir)/depcomp $(srcdir)/aclocal.m4 \
> $(srcdir)/config.guess $(srcdir)/config.sub
>
> @@ -41,7 +44,7 @@ EXTRA_DIST = \
> contrib \
> debug
>
> -SUBDIRS = distro include src sample doc tests
> +SUBDIRS = build distro include src sample doc tests
>
>  dist_doc_DATA = \
> COPYRIGHT.GPL \
> diff --git a/build/Makefile.am b/build/Makefile.am
> new file mode 100644
> index 000..a993b20
> --- /dev/null
> +++ b/build/Makefile.am
> @@ -0,0 +1,15 @@
> +#
> +#  OpenVPN -- An application to securely tunnel IP networks
> +# over a single UDP port, with support for SSL/TLS-based
> +# session authentication and key exchange,
> +# packet encryption, packet authentication, and
> +# packet compression.
> +#
> +#  Copyright (C) 2002-2010 OpenVPN Technologies, Inc. 
> +#
> +
> +MAINTAINERCLEANFILES = \
> +   $(srcdir)/Makefile.in
> +
> +EXTRA_DIST = \
> +   ltrc.inc
> diff --git a/build/ltrc.inc b/build/ltrc.inc
> new file mode 100644
> index 000..701f200
> --- /dev/null
> +++ b/build/ltrc.inc
> @@ -0,0 +1,23 @@
> +#
> +#  OpenVPN -- An application to securely tunnel IP networks
> +# over a single UDP port, with support for SSL/TLS-based
> +# session authentication and key exchange,
> +# packet encryption, packet authentication, and
> +# packet compression.
> +#
> +#  Copyright (C) 2008-2012 Alon Bar-Lev 
> +#
> +# Required to build Windows resource file
> +
> +RCCOMPILE = $(RC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
> +   $(AM_CPPFLAGS) $(CPPFLAGS)
> 

Re: [Openvpn-devel] New generic buildsystem: lzo enabled or disabled by default?

[Alon Bar-Lev]

Sorry...
[1] http://thread.gmane.org/gmane.network.openvpn.devel/5772/focus=5947

2012/3/16 Alon Bar-Lev :
> Hello,
>
> Part of the reasoning was discussed here[1].
>
> If we do not want to do auto detection, enabling optional components
> may lead to configure failure, and force the user to explicitly
> disable this feature.
>
> It is possible, and I don't mind so much, however, I prefer configure
> to use the minimum absolutely needed components by default, and in
> majority of valid cases succeed.
>
> Disabling by default does not effect users nor building via build
> script nor building via package management (rpmbuild, deb). It only
> effects people who build manually from sources. These people should
> not only consider the lzo enable/disable but many more configure
> options so lzo is no exception.
>
> Alon.
>
> [1] http://thread.gmane.org/gmane.network.openvpn.devel/5772/focus=5811
>
> 2012/3/16 Samuli Seppänen :
>> Hi all,
>>
>> In yesterday's meeting we reviewed this patch
>>
>> PATCH 39/52 build: proper lzo detection and usage
>>  URL: http://thread.gmane.org/gmane.network.openvpn.devel/5772/focus=5811
>>
>> The patch was ACKed, but there was disagreement whether LZO should be 
>> enabled or disabled by default. Whichever the case, it will only affect 
>> people building OpenVPN, not the end-users. Official builds will continue to 
>> have LZO support.
>>
>> Opinions?
>>
>> --
>> Samuli Seppänen
>> Community Manager
>> OpenVPN Technologies, Inc
>>
>> irc freenode net: mattock
>>
>>
>> --
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> ___
>> Openvpn-devel mailing list
>> Openvpn-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] New generic buildsystem: lzo enabled or disabled by default?

[Alon Bar-Lev]

Hello,

Part of the reasoning was discussed here[1].

If we do not want to do auto detection, enabling optional components
may lead to configure failure, and force the user to explicitly
disable this feature.

It is possible, and I don't mind so much, however, I prefer configure
to use the minimum absolutely needed components by default, and in
majority of valid cases succeed.

Disabling by default does not effect users nor building via build
script nor building via package management (rpmbuild, deb). It only
effects people who build manually from sources. These people should
not only consider the lzo enable/disable but many more configure
options so lzo is no exception.

Alon.

[1] http://thread.gmane.org/gmane.network.openvpn.devel/5772/focus=5811

2012/3/16 Samuli Seppänen :
> Hi all,
>
> In yesterday's meeting we reviewed this patch
>
> PATCH 39/52 build: proper lzo detection and usage
>  URL: http://thread.gmane.org/gmane.network.openvpn.devel/5772/focus=5811
>
> The patch was ACKed, but there was disagreement whether LZO should be enabled 
> or disabled by default. Whichever the case, it will only affect people 
> building OpenVPN, not the end-users. Official builds will continue to have 
> LZO support.
>
> Opinions?
>
> --
> Samuli Seppänen
> Community Manager
> OpenVPN Technologies, Inc
>
> irc freenode net: mattock
>
>
> --
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] New generic buildsystem: lzo enabled or disabled by default?

[Samuli Seppänen]

Hi all,

In yesterday's meeting we reviewed this patch

PATCH 39/52 build: proper lzo detection and usage
 URL: http://thread.gmane.org/gmane.network.openvpn.devel/5772/focus=5811

The patch was ACKed, but there was disagreement whether LZO should be enabled 
or disabled by default. Whichever the case, it will only affect people building 
OpenVPN, not the end-users. Official builds will continue to have LZO support.

Opinions?

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock