RE: Summary of meeting between NET-SNMP devs and ICEI

2018-04-25 Thread Steve Friedl 
Wow, these are names from the past; I find it hard to believe there is any
legitimate need to support these going forward.

Steve - who's ported to almost all of those platforms

-Original Message-
From: Eric S. Raymond [mailto:e...@thyrsus.com] 
Sent: Wednesday, April 25, 2018 8:25 PM
To: Bart Van Assche 
Cc: Susan Sons ; net-snmp-coders@lists.sourceforge.net;
Robert Story 
Subject: Re: Summary of meeting between NET-SNMP devs and ICEI

Bart Van Assche :
> Which of the following files under include/net-snmp/system do you 
> think are still relevant today? No changes other than trivial changes 
> have been made to these files in the past ten years:
> 
> dynix.h irix.h osf5.h svr5.h ultrix.h

LOL. I've seen this movie before.  It's very common in codebases of this age
and size range.

Nuke them from orbit, sez I.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute:
https://icei.org Please visit their site and donate: the civilization you
save might be your own.




--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Summary of meeting between NET-SNMP devs and ICEI

2018-04-25 Thread Eric S. Raymond 
Bart Van Assche :
> Which of the following files under include/net-snmp/system do you think are
> still relevant today? No changes other than trivial changes have been made
> to these files in the past ten years:
> 
> dynix.h irix.h osf5.h svr5.h ultrix.h

LOL. I've seen this movie before.  It's very common in codebases of this
age and size range.

Nuke them from orbit, sez I.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Summary of meeting between NET-SNMP devs and ICEI

2018-04-25 Thread Bart Van Assche 

On 04/25/18 13:08, Robert Story wrote:

IB> * clean up headers in /include/net-snmp/system/ which are a
IB> mess and have import loops
IB>
IB> * #ifdef hell / too many supported configurations

I'm a little nervous about these one, especially with folks that are
new to the code base. And as far as supported configurations, we're
very big on backwards compatibility.


Hello Robert,

Which of the following files under include/net-snmp/system do you think 
are still relevant today? No changes other than trivial changes have 
been made to these files in the past ten years:


dynix.h irix.h osf5.h svr5.h ultrix.h

Thanks,

Bart.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Summary of meeting between NET-SNMP devs and ICEI

2018-04-25 Thread Eric S. Raymond 
Robert Story :
>And as far as supported configurations, we're
> very big on backwards compatibility.

I think you are spending more effort on this than field conditions justify.
And there is a cost you probably have not audited.

I learned my Unix programming chops back in the 1980s when having thickets
of portability #ifdefs was definitely the right thing to do because there
was so much variation in platform APIs. I too acquired the reflex of never
throwing any of those out, just in case

This attitude has been obsolete for at least 9 years.

The reason I'm that precise about it is because of a learning
experience I had while maintaining GPSD in 2009. The important fact
about GPSD in this context is that it is deployed on a *huge* breadth
of hardware, not just datacenter machines but laptops and smartphones
and embedded gear of all sorts.

Came the day I was doing some routine cleanup, I tripped over a port
#ifdef for a species of big-iron Unix that will never again walk the
earth, and the following thought intruded: "What? Is this really needed?"

Slightly amazed at my own heresy, I continued to think "You know, this
is a build variant I can no longer test.  Why am I letting it clutter
up my code and complicate my build recipe?"

*blink*

Because I have a reflex about these things. I screen out their complexity
cost by habit.

So I went on an #ifdef hunt.  I had never really totaled up the number of
LOC added by alternate build options before.  It was significant.

My next step was to ask how I could reduce this.  The obvious thing to
try was to assume that the standards people won the war - anywhere I
found an #ifdef where one of the paths assumed SuSv2+C99 and rip out
all the other paths.

When I did that, the resulting patch was large but obviously reversible.
So I tried the bold thing.  I removed all that code and shipped a point release.

My reasoning was thus: point releases are cheap.  This change, if it's
bad, will throw an error at compile time well before it disrupts any
runtime behavior.  I can put back the pieces I actually need when the
build failures hit my bugtracker.

I never saw even one.

And that's how I learned that the standards people had succeeded.

Six years later I preformed a similar cruftectomy on the NTP code.
Again, never a peep of complaint from anyone downstream.

The benefits: (1) fewer LOC of more readable code, (2) fewer test paths,
(3) simpler build recipe.

> As 5.8 is getting really close to going out the door, this type of
> cleanup likely won't make it into that release.
> 
> 
> Got any cmake experts? One of the planned items for 5.9 is moving
> to cmake. The bulk of the work is done (patches from VMware against
> 5.7), but work will be needed to integrate to master and put on the
> finishing touches.

I occasionally used cmake when I was on the Battle for Wesnoth project.

I don't like it.  Not so much because cmake is bad in itself, it isn't.
It's a reasonable implementation of its design premises.

The problem is that one of cmake's premises is being a two-phase builder,
generating makefiles, rather than a one-phase builder that directly executes
its recipe.  This repeats the autoconf tragedy, making buld-failure
diagnosis *far* more complex and gnarly than it needs to be.

I have come to believe that all two-phase build engines should be shot
with silver bullets and buried at crossroads with stakes through
their hearts.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

5.8 testing status

2018-04-25 Thread Keith Mendoza 
Just want to see where everyone is regarding 5.8 release. Other than what's 
listed in the 5.8pre2 announcement are there any other features that will go 
into 5.8?

Other that the bugs I filed last week from running the test suite against 
master branch, are there any bugs that are part of 5.8?

Do we need to do a 5.8pre3? If so, when is that expected?

-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Summary of meeting between NET-SNMP devs and ICEI

2018-04-25 Thread Keith Mendoza 
On Wed, Apr 25, 2018, at 12:08 PM, Robert Story wrote:
> On Thu, 12 Apr 2018 10:31:13 -0500 Ian wrote:
> IB> This morning we (Keith, Ian) met with an assortment of the
> IB> NET-SNMP developers / contributors (primarily Bart Van Assche)
> IB> to discuss how we could best help the project. The meeting went
> IB> well, at least form our perspective.
> 
> I'm sorry I missed this meeting. I'm almost always on IRC, but
> sometimes go a while without checking the mailing list.
> 
> IB> The pain points we identified were:
> IB> 
> IB> * bug mountain
> IB> * help users on the mailing list
> IB> * patch / MR handling process
> 
> Yep, those are biggies.
> 
> IB> * move out of SourceForge
> 
> We've had recent discussions on this, and I think we'll be moving
> the source to github in the near future.

I think it would be best to get full agreement from the team on this. I hear 
bits-and-pieces that there have been some move in that direction. However, I 
think there should be a separate discussion just on that topic and what it 
would entail to officially move the Net-SNMP project over.

> 
> IB> * clean up headers in /include/net-snmp/system/ which are a
> IB> mess and have import loops
> IB> 
> IB> * #ifdef hell / too many supported configurations
> 
> I'm a little nervous about these one, especially with folks that are
> new to the code base. And as far as supported configurations, we're
> very big on backwards compatibility.
> 
> As 5.8 is getting really close to going out the door, this type of
> cleanup likely won't make it into that release.

Agree completely on both points. I feel that this project should be done by a 
group that's composed by those who know the code, and those new to the code. 
That way, we have assurance that things are not being dropped on the floor on 
accident and that a good knowledge transfer happens. I would go so far as to 
suggest that one member of this "team" should be tasked with documenting what's 
going on; essentially appoint a project librarian if you will.

One conversation I was a part of regarding the configuration is to modularize 
things better and leverage the build system to decide what source files will be 
included in the build based on the target system/configuration. I personally 
would suggest holding this off until we've moved to github.
 
> 
> 
> Got any cmake experts? One of the planned items for 5.9 is moving
> to cmake. The bulk of the work is done (patches from VMware against
> 5.7), but work will be needed to integrate to master and put on the
> finishing touches.

I have experience using cmake, and I'm sure I can tap other people if need be. 
I would suggest that we look into whether the cmake move should be part of the 
"#ifdef hell..." clean up. If you can point me to the branch where the 
CMake-related files are currently stored I'll do some research on it once 5.8 
is released.

As far as versioning is concerned; I personally feel if the build system is 
switched to cmake that it should be considered a major release. I feel that 
rolling it to 5.9 may give some package managers a nasty surprise when their 
packaging script suddenly starts breaking.

> 
> Robert
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

There are obviously a lot of irons that are suddenly being considered to be 
thrown in the fire. Would the Net-SNMP team be amenable to either a 
conference/meeting either on IRC, phone, or video chat to develop a long-term 
plan for the project? I have access to systems we can use for a phone or video 
conference.

-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Summary of meeting between NET-SNMP devs and ICEI

2018-04-25 Thread Ian Bruene 



On 04/25/2018 02:08 PM, Robert Story wrote:

On Thu, 12 Apr 2018 10:31:13 -0500 Ian wrote:
IB> * clean up headers in /include/net-snmp/system/ which are a
IB> mess and have import loops
IB>
IB> * #ifdef hell / too many supported configurations

I'm a little nervous about these one, especially with folks that are
new to the code base. And as far as supported configurations, we're
very big on backwards compatibility.

As 5.8 is getting really close to going out the door, this type of
cleanup likely won't make it into that release.


Understandable. Keith has been focusing on the patching and release 
process. I've had to take a back seat as another project I'm on is 
currently in pre-deadline crunch.

Got any cmake experts? One of the planned items for 5.9 is moving
to cmake. The bulk of the work is done (patches from VMware against
5.7), but work will be needed to integrate to master and put on the
finishing touches.

Robert


I think we do.

--
/"In the end; what separates a Man, from a Slave? Money? Power? No. A 
Man Chooses, a Slave Obeys."/ -- Andrew Ryan


/"Utopia cannot precede the Utopian. It will exist the moment we are fit 
to occupy it."/ -- Sophia Lamb


I work for the Internet Civil Engineering Institute , 
help us save the Internet from Entropy!


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: [PATCH RFC] Add Travis and Appveyor CI support

2018-04-25 Thread Bart Van Assche 

On 04/25/18 12:58, Robert Story wrote:

On Wed, 25 Apr 2018 09:06:28 -0600 Bart wrote:
BVA> One of the advantages of github over SourceForge is that
BVA> integration with continuous integration (CI) services like
BVA> Travis and Appveyor is easy. Adding such support however
BVA> requires to add proper configuration files and the necessary
BVA> scripts in the source tree. Hence this patch. As one can see
BVA> for Linux all regression tests are run, for OS/X some
BVA> regression tests are run and for MSVC and Cygwin no regression
BVA> tests are run. All four builds pass with this patch. As usual,
BVA> feedback is welcome.

I think that CI would be a great addition. My only concern with the
patch is the changes to simple_eval_tools.sh and whether the
changes might break testing on other platforms and/or older
releases of various platforms.

But I supposed the best way to find out would be to commit the
changes. We might need some discussion on 5.7, but I think it's fine
for master (so it will make it in to 5.8). Why don't you go ahead
an check it in on a new branch. Given some support from other core
devs and not significant objections, I'll merge that branch before
rc1 next week.


Hello Robert,

Please have a look at the master-ci branch on github. I have left out 
the simple_eval_tools.sh from that branch since I only needed these 
changes while testing the continuous integration scripts.


Thanks,

Bart.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Summary of meeting between NET-SNMP devs and ICEI

2018-04-25 Thread Robert Story 
On Thu, 12 Apr 2018 10:31:13 -0500 Ian wrote:
IB> This morning we (Keith, Ian) met with an assortment of the
IB> NET-SNMP developers / contributors (primarily Bart Van Assche)
IB> to discuss how we could best help the project. The meeting went
IB> well, at least form our perspective.

I'm sorry I missed this meeting. I'm almost always on IRC, but
sometimes go a while without checking the mailing list.

IB> The pain points we identified were:
IB> 
IB> * bug mountain
IB> * help users on the mailing list
IB> * patch / MR handling process

Yep, those are biggies.

IB> * move out of SourceForge

We've had recent discussions on this, and I think we'll be moving
the source to github in the near future.

IB> * clean up headers in /include/net-snmp/system/ which are a
IB> mess and have import loops
IB> 
IB> * #ifdef hell / too many supported configurations

I'm a little nervous about these one, especially with folks that are
new to the code base. And as far as supported configurations, we're
very big on backwards compatibility.

As 5.8 is getting really close to going out the door, this type of
cleanup likely won't make it into that release.


Got any cmake experts? One of the planned items for 5.9 is moving
to cmake. The bulk of the work is done (patches from VMware against
5.7), but work will be needed to integrate to master and put on the
finishing touches.

Robert

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: [PATCH RFC] Add Travis and Appveyor CI support

2018-04-25 Thread Robert Story 
On Wed, 25 Apr 2018 09:06:28 -0600 Bart wrote:
BVA> One of the advantages of github over SourceForge is that
BVA> integration with continuous integration (CI) services like
BVA> Travis and Appveyor is easy. Adding such support however
BVA> requires to add proper configuration files and the necessary
BVA> scripts in the source tree. Hence this patch. As one can see
BVA> for Linux all regression tests are run, for OS/X some
BVA> regression tests are run and for MSVC and Cygwin no regression
BVA> tests are run. All four builds pass with this patch. As usual,
BVA> feedback is welcome.

I think that CI would be a great addition. My only concern with the
patch is the changes to simple_eval_tools.sh and whether the
changes might break testing on other platforms and/or older
releases of various platforms.

But I supposed the best way to find out would be to commit the
changes. We might need some discussion on 5.7, but I think it's fine
for master (so it will make it in to 5.8). Why don't you go ahead
an check it in on a new branch. Given some support from other core
devs and not significant objections, I'll merge that branch before
rc1 next week.

Robert

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: [PATCH RFC] Add Travis and Appveyor CI support

2018-04-25 Thread Keith Mendoza 


On Wed, Apr 25, 2018, at 11:05 AM, Bart Van Assche wrote:
> On 04/25/18 11:54, Keith Mendoza wrote:
> > Out of curiosity, do you have a "fork" of Net-SNMP on github to connect it 
> > to Travis and Appveyor?
> 
> Hello Keith,
> 
> If you are looking for a Net-SNMP repository on github, please use 
> https://github.com/net-snmp/net-snmp. I hope Wes will connect that 
> repository to Travis and Appveyor.

Woo hoo. Now if we can plan out what other stuff we want moved from SF.

> 
> Thanks,
> 
> Bart.


-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: [PATCH RFC] Add Travis and Appveyor CI support

2018-04-25 Thread Bart Van Assche 

On 04/25/18 11:54, Keith Mendoza wrote:

Out of curiosity, do you have a "fork" of Net-SNMP on github to connect it to 
Travis and Appveyor?


Hello Keith,

If you are looking for a Net-SNMP repository on github, please use 
https://github.com/net-snmp/net-snmp. I hope Wes will connect that 
repository to Travis and Appveyor.


Thanks,

Bart.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Verify AES support when Blumenthal draft is enabled

2018-04-25 Thread Keith Mendoza 
Bart,

On Wed, Apr 25, 2018, at 9:28 AM, Bart Van Assche wrote:
> On 04/25/18 10:04, Keith Mendoza wrote:
> > Net-SNMP dev team,
> > I have submitted a merge request to verify that when the 
> > --enable-blumenthal-aes is used in configure that it checks that OpenSSL's 
> > aes.h and evp.h are available. Merge request is at 
> > https://sourceforge.net/p/net-snmp/code/merge-requests/14/. This should 
> > fully resolve the following bugs:
> > 
> > * #2859 Test case "T023snmpv3getMD5DES_simple" fails 
> > (https://sourceforge.net/p/net-snmp/bugs/2859/)
> > 
> > * #2855 Test case "T026snmpv3getSHAAES_simple" fails 
> > (https://sourceforge.net/p/net-snmp/bugs/2855/)
> > 
> > * #2854 Test case "T025snmpv3getSHADES_simple" fails 
> > (https://sourceforge.net/p/net-snmp/bugs/2854/)
> > 
> > * #2852 Test case "T024snmpv3getSHA1_simple" fails 
> > (https://sourceforge.net/p/net-snmp/bugs/2852/)
> > 
> > This fix provides a partial fix for #2853 Test case 
> > "T024snmpv3getSHA512_simple" fails (#2853 Test case 
> > "T024snmpv3getSHA512_simple" fails). The rest of the fix is Bart's commit 
> > 3c104a.
> 
> Hello Keith,
> 
> Are you aware that running something like "brew upgrade openssl" brings 
> in a version of openssl on OS/X that is recent enough for all Net-SNMP 
> features? 

>From what I know OpenSSL is available through Homebrew or Macports--among 
>others. Apple doesn't seem to provide OpenSSL by themselves. So doing that 
>should upgrade openssl provided the package info for the package manager has 
>been done too.

> Regarding your pull request: I'd like to avoid adding 
> AC_CHECK_HEADERS() calls in config_project_with_enable because whether 
> or not these succeed depend on the compiler flags (-I) and some compiler 
> flags are only set at a later phase.

I agree that placing the AC_CHECK_HEADERS() where it is _not_ the best place 
for it as it assumes that --with-ssl always occurs before 
--enable-blumenthal-aes. I suspect that if the --with-ssl code is moved after 
that the AC_CHECK_HEADERS will always fail. I felt that placing it there would 
be a good starting point; and I figured someone with more experience with the 
codebase will tell me where it should go as a rule-of-thumb for the project.

I feel the best solution would be to remove the typecasts going on inside 
sc_get_openssl_hashfn(). It seems to me that having these typecasts there is 
triggering the implicit declaration of EVP_sha512() that lead to the crash we 
both encountered. However, I don't want testing the "best" solution to block 
5.8 release.

> 
> Thanks,
> 
> Bart.


-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: [PATCH RFC] Add Travis and Appveyor CI support

2018-04-25 Thread Keith Mendoza 
Bart,
Out of curiosity, do you have a "fork" of Net-SNMP on github to connect it to 
Travis and Appveyor?

On Wed, Apr 25, 2018, at 8:06 AM, Bart Van Assche wrote:
> Hello,
> 
> One of the advantages of github over SourceForge is that integration 
> with continuous integration (CI) services like Travis and Appveyor is 
> easy. Adding such support however requires to add proper configuration 
> files and the necessary scripts in the source tree. Hence this patch. As 
> one can see for Linux all regression tests are run, for OS/X some 
> regression tests are run and for MSVC and Cygwin no regression tests are 
> run. All four builds pass with this patch. As usual, feedback is welcome.
> 
> Bart.
> 
> 
> ---
>   .appveyor.yml  |  10 +
>   .travis.yml|  35 
>   ci/build.bat   |  30 +++
>   ci/build.sh|  17 ++
>   ci/net-snmp-configure  | 211 +
>   ci/net-snmp-run-perl-tests |   9 +
>   ci/net-snmp-run-python-tests   |  16 ++
>   ci/net-snmp-run-tests  |  37 
>   .../fulltests/default/T200snmpv2cwalkall_simple|   2 +
>   testing/fulltests/support/simple_eval_tools.sh |  21 +-
>   10 files changed, 381 insertions(+), 7 deletions(-)
>   create mode 100644 .appveyor.yml
>   create mode 100644 .travis.yml
>   create mode 100644 ci/build.bat
>   create mode 100755 ci/build.sh
>   create mode 100755 ci/net-snmp-configure
>   create mode 100755 ci/net-snmp-run-perl-tests
>   create mode 100755 ci/net-snmp-run-python-tests
>   create mode 100755 ci/net-snmp-run-tests
> 
> diff --git a/.appveyor.yml b/.appveyor.yml
> new file mode 100644
> index ..137c52052d34
> --- /dev/null
> +++ b/.appveyor.yml
> @@ -0,0 +1,10 @@
> +image:
> +  - Visual Studio 2017
> +environment:
> +  matrix:
> +- BUILD: MSVC
> +# - BUILD: MinGW
> +- BUILD: Cygwin
> +clone_depth: 5
> +build_script:
> +  - 'call "ci\build.bat"'
> diff --git a/.travis.yml b/.travis.yml
> new file mode 100644
> index ..7262aa19aab0
> --- /dev/null
> +++ b/.travis.yml
> @@ -0,0 +1,35 @@
> +language: c
> +
> +os:
> +  - linux
> +  - osx
> +
> +dist: trusty
> +
> +sudo: required
> +
> +addons:
> +  apt:
> +packages:
> +  - dpkg
> +  - gcc
> +  - libatm-dev
> +  - libperl-dev
> +  - libsensors4-dev
> +  - libssh-dev
> +  - libssl-dev
> +  - make
> +  - perl-modules
> +  - pkg-config
> +  - python-dev
> +  - python-setuptools
> +
> +# Add an IPv6 config - see the corresponding Travis issue
> +# https://github.com/travis-ci/travis-ci/issues/8361
> +before_script:
> +  - if [ "${TRAVIS_OS_NAME}" == "linux" ]; then
> +  sudo sh -c 'echo 0 > /proc/sys/net/ipv6/conf/all/disable_ipv6; 
> printf "\n::1 localhost ipv6-localhost ipv6-loopback\n" >>/etc/hosts; 
> cat /etc/hosts';
> +fi
> +  - 'if [ "${TRAVIS_OS_NAME}" == "osx" ]; then brew upgrade openssl 
>  >/dev/null 2>&1; fi'
> +
> +script: ci/build.sh
> diff --git a/ci/build.bat b/ci/build.bat
> new file mode 100644
> index ..cea6a89a4886
> --- /dev/null
> +++ b/ci/build.bat
> @@ -0,0 +1,30 @@
> +echo "Build type %BUILD%"
> +@echo on
> +goto %BUILD%
> +echo "Error: unknown build type %BUILD%"
> +goto eof
> +
> +:MSVC
> +REM see also https://www.appveyor.com/docs/lang/cpp/
> +REM if exist "C:\Program Files (x86)\Microsoft Visual Studio\2017" (
> +REM   set "d=C:\Program Files (x86)\Microsoft Visual Studio\2017"
> +REM ) else if exist "C:\Program Files\Microsoft Visual Studio\2017" (
> +REM   set "d=C:\Program Files\Microsoft Visual Studio\2017"
> +REM )
> +REM cmd /c ""%d%"\Community\VC\Auxiliary\Build\vcvarsall.bat x86"
> +REM install:
> +call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
> \vcvarsall.bat"
> +cd win32
> +perl Configure --config=release --with-sdk --with-ipv6 --with-winextdll 
> --linktype=dynamic
> +nmake
> +goto eof
> +
> +:MinGW
> +C:\msys64\usr\bin\bash --login -c 'set -x; cd 
> "${APPVEYOR_BUILD_FOLDER}"; ci/build.sh'
> +goto eof
> +
> +:Cygwin
> +c:\cygwin\bin\bash --login -c 'set -x; cd "${APPVEYOR_BUILD_FOLDER}"; 
> ci/build.sh'
> +goto eof
> +
> +:eof
> diff --git a/ci/build.sh b/ci/build.sh
> new file mode 100755
> index ..3e306d82bf17
> --- /dev/null
> +++ b/ci/build.sh
> @@ -0,0 +1,17 @@
> +#!/bin/bash
> +
> +scriptdir="$(dirname "$0")"
> +export NOAUTODEPS=1
> +export SNMP_VERBOSE=1
> +if [ -z "$OSTYPE" ]; then
> +case "$(uname)" in
> +Linux)  OSTYPE=linux;;
> +Darwin) OSTYPE=darwin;;
> +*)  OSTYPE="UNKNOWN:$(uname)";;
> +esac
> +export OSTYPE
> +fi
> +"${scriptdir}"/net-snmp-configure master || exit $?
> +make -s  || exit $?
> +[ "$OSTYPE" = cygwin ]&& exit 0
> +"${scriptdir}"/net-snmp-run-tests

Re: Verify AES support when Blumenthal draft is enabled

2018-04-25 Thread Bart Van Assche 

On 04/25/18 10:04, Keith Mendoza wrote:

Net-SNMP dev team,
I have submitted a merge request to verify that when the 
--enable-blumenthal-aes is used in configure that it checks that OpenSSL's 
aes.h and evp.h are available. Merge request is at 
https://sourceforge.net/p/net-snmp/code/merge-requests/14/. This should fully 
resolve the following bugs:

* #2859 Test case "T023snmpv3getMD5DES_simple" fails 
(https://sourceforge.net/p/net-snmp/bugs/2859/)

* #2855 Test case "T026snmpv3getSHAAES_simple" fails 
(https://sourceforge.net/p/net-snmp/bugs/2855/)

* #2854 Test case "T025snmpv3getSHADES_simple" fails 
(https://sourceforge.net/p/net-snmp/bugs/2854/)

* #2852 Test case "T024snmpv3getSHA1_simple" fails 
(https://sourceforge.net/p/net-snmp/bugs/2852/)

This fix provides a partial fix for #2853 Test case "T024snmpv3getSHA512_simple" fails 
(#2853 Test case "T024snmpv3getSHA512_simple" fails). The rest of the fix is Bart's 
commit 3c104a.


Hello Keith,

Are you aware that running something like "brew upgrade openssl" brings 
in a version of openssl on OS/X that is recent enough for all Net-SNMP 
features? Regarding your pull request: I'd like to avoid adding 
AC_CHECK_HEADERS() calls in config_project_with_enable because whether 
or not these succeed depend on the compiler flags (-I) and some compiler 
flags are only set at a later phase.


Thanks,

Bart.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Verify AES support when Blumenthal draft is enabled

2018-04-25 Thread Keith Mendoza 
Net-SNMP dev team,
I have submitted a merge request to verify that when the 
--enable-blumenthal-aes is used in configure that it checks that OpenSSL's 
aes.h and evp.h are available. Merge request is at 
https://sourceforge.net/p/net-snmp/code/merge-requests/14/. This should fully 
resolve the following bugs:

* #2859 Test case "T023snmpv3getMD5DES_simple" fails 
(https://sourceforge.net/p/net-snmp/bugs/2859/)

* #2855 Test case "T026snmpv3getSHAAES_simple" fails 
(https://sourceforge.net/p/net-snmp/bugs/2855/)

* #2854 Test case "T025snmpv3getSHADES_simple" fails 
(https://sourceforge.net/p/net-snmp/bugs/2854/)

* #2852 Test case "T024snmpv3getSHA1_simple" fails 
(https://sourceforge.net/p/net-snmp/bugs/2852/)

This fix provides a partial fix for #2853 Test case 
"T024snmpv3getSHA512_simple" fails (#2853 Test case 
"T024snmpv3getSHA512_simple" fails). The rest of the fix is Bart's commit 
3c104a.

-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

[PATCH RFC] Add Travis and Appveyor CI support

2018-04-25 Thread Bart Van Assche 

Hello,

One of the advantages of github over SourceForge is that integration 
with continuous integration (CI) services like Travis and Appveyor is 
easy. Adding such support however requires to add proper configuration 
files and the necessary scripts in the source tree. Hence this patch. As 
one can see for Linux all regression tests are run, for OS/X some 
regression tests are run and for MSVC and Cygwin no regression tests are 
run. All four builds pass with this patch. As usual, feedback is welcome.


Bart.


---
 .appveyor.yml  |  10 +
 .travis.yml|  35 
 ci/build.bat   |  30 +++
 ci/build.sh|  17 ++
 ci/net-snmp-configure  | 211 +
 ci/net-snmp-run-perl-tests |   9 +
 ci/net-snmp-run-python-tests   |  16 ++
 ci/net-snmp-run-tests  |  37 
 .../fulltests/default/T200snmpv2cwalkall_simple|   2 +
 testing/fulltests/support/simple_eval_tools.sh |  21 +-
 10 files changed, 381 insertions(+), 7 deletions(-)
 create mode 100644 .appveyor.yml
 create mode 100644 .travis.yml
 create mode 100644 ci/build.bat
 create mode 100755 ci/build.sh
 create mode 100755 ci/net-snmp-configure
 create mode 100755 ci/net-snmp-run-perl-tests
 create mode 100755 ci/net-snmp-run-python-tests
 create mode 100755 ci/net-snmp-run-tests

diff --git a/.appveyor.yml b/.appveyor.yml
new file mode 100644
index ..137c52052d34
--- /dev/null
+++ b/.appveyor.yml
@@ -0,0 +1,10 @@
+image:
+  - Visual Studio 2017
+environment:
+  matrix:
+- BUILD: MSVC
+# - BUILD: MinGW
+- BUILD: Cygwin
+clone_depth: 5
+build_script:
+  - 'call "ci\build.bat"'
diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index ..7262aa19aab0
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,35 @@
+language: c
+
+os:
+  - linux
+  - osx
+
+dist: trusty
+
+sudo: required
+
+addons:
+  apt:
+packages:
+  - dpkg
+  - gcc
+  - libatm-dev
+  - libperl-dev
+  - libsensors4-dev
+  - libssh-dev
+  - libssl-dev
+  - make
+  - perl-modules
+  - pkg-config
+  - python-dev
+  - python-setuptools
+
+# Add an IPv6 config - see the corresponding Travis issue
+# https://github.com/travis-ci/travis-ci/issues/8361
+before_script:
+  - if [ "${TRAVIS_OS_NAME}" == "linux" ]; then
+  sudo sh -c 'echo 0 > /proc/sys/net/ipv6/conf/all/disable_ipv6; 
printf "\n::1 localhost ipv6-localhost ipv6-loopback\n" >>/etc/hosts; 
cat /etc/hosts';

+fi
+  - 'if [ "${TRAVIS_OS_NAME}" == "osx" ]; then brew upgrade openssl 
>/dev/null 2>&1; fi'

+
+script: ci/build.sh
diff --git a/ci/build.bat b/ci/build.bat
new file mode 100644
index ..cea6a89a4886
--- /dev/null
+++ b/ci/build.bat
@@ -0,0 +1,30 @@
+echo "Build type %BUILD%"
+@echo on
+goto %BUILD%
+echo "Error: unknown build type %BUILD%"
+goto eof
+
+:MSVC
+REM see also https://www.appveyor.com/docs/lang/cpp/
+REM if exist "C:\Program Files (x86)\Microsoft Visual Studio\2017" (
+REM   set "d=C:\Program Files (x86)\Microsoft Visual Studio\2017"
+REM ) else if exist "C:\Program Files\Microsoft Visual Studio\2017" (
+REM   set "d=C:\Program Files\Microsoft Visual Studio\2017"
+REM )
+REM cmd /c ""%d%"\Community\VC\Auxiliary\Build\vcvarsall.bat x86"
+REM install:
+call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat"
+cd win32
+perl Configure --config=release --with-sdk --with-ipv6 --with-winextdll 
--linktype=dynamic

+nmake
+goto eof
+
+:MinGW
+C:\msys64\usr\bin\bash --login -c 'set -x; cd 
"${APPVEYOR_BUILD_FOLDER}"; ci/build.sh'

+goto eof
+
+:Cygwin
+c:\cygwin\bin\bash --login -c 'set -x; cd "${APPVEYOR_BUILD_FOLDER}"; 
ci/build.sh'

+goto eof
+
+:eof
diff --git a/ci/build.sh b/ci/build.sh
new file mode 100755
index ..3e306d82bf17
--- /dev/null
+++ b/ci/build.sh
@@ -0,0 +1,17 @@
+#!/bin/bash
+
+scriptdir="$(dirname "$0")"
+export NOAUTODEPS=1
+export SNMP_VERBOSE=1
+if [ -z "$OSTYPE" ]; then
+case "$(uname)" in
+Linux)  OSTYPE=linux;;
+Darwin) OSTYPE=darwin;;
+*)  OSTYPE="UNKNOWN:$(uname)";;
+esac
+export OSTYPE
+fi
+"${scriptdir}"/net-snmp-configure master || exit $?
+make -s  || exit $?
+[ "$OSTYPE" = cygwin ]&& exit 0
+"${scriptdir}"/net-snmp-run-tests|| exit $?
diff --git a/ci/net-snmp-configure b/ci/net-snmp-configure
new file mode 100755
index ..03e12e7fe737
--- /dev/null
+++ b/ci/net-snmp-configure
@@ -0,0 +1,211 @@
+#!/usr/bin/env bash
+
+# Necessary software packages for building Net-SNMP:
+# autoconf automake libtool m4
+# glibc glibc-devel libssh2 libssh2-devel openssl openssl-devel rpm-devel
+# perl-ExtUtils-MakeMaker perl-ExtUtils-Embed perl-Test-Harness
+# python python-devel python-setuptools
+