On increasing visibility into experimental features.

2016-11-01 Thread Alex Rukletsov 
Folks,

Additionally to the "known bugs" proposal in a parallel thread, we think
that maintaining a list of still experimental features for each minor
release will significantly help users
to adjust their expectations.

Our suggestion is to include a new section into the CHANGELOG called
"Experimental Features" starting with the upcoming 1.1.0 release.
Populating this section should be relatively easy: take the contents of
this section from the previous minor release, remove features declared
stable, and add new experimental features.

With this change users will have a complete overview of experimental
functionality per release, without searching the CHANGELOG for when and
whether a certain feature became production-ready.

What do you think?

AlexR.

On increasing visibility into known bugs and issues.

2016-11-01 Thread Alex Rukletsov 
Folks,

There have been several suggestions recently about how we can help people
understand which known issues are in certain Mesos releases (thanks Joris
for kicking this off!). With a time-based release strategy we may not have
enough time to fix all the known issues prior to cutting an RC. However, we
definitely want to be honest and tell users about those issues before they
run into something obscure and start searching for this on JIRA.

Hence, we suggest to include a new section into the CHANGELOG called "Known
Issues", starting with the upcoming 1.1.0 release.

>From now on, release managers will have to find and triage all blocker and
critical bugs and call them out in the CHANGELOG; a JIRA query which may be
helpful: `project = Mesos AND type = bug AND status != Resolved AND
priority IN (blocker, critical)`.

To help release managers, we would like to encourage all committers,
shepherds, and seasoned contributors to classify and set target version
properly on every bug with critical or blocker priority they open.

Right now there are 33 such bugs, with the oldest one filed in April 2014.
Shepherds, please look into your issues from this list and
classify/close/re-target them accordingly.

AlexR.

Re: Build failed in Jenkins: Mesos » autotools,gcc,--verbose --enable-libevent --enable-ssl,GLOG_v=1 MESOS_VERBOSE=1,centos:7,(docker||Hadoop)&&(!ubuntu-us1)&&(!ubuntu-6) #2852

2016-11-01 Thread Alex Rukletsov 
Filed https://issues.apache.org/jira/browse/INFRA-12852

On Mon, Oct 31, 2016 at 4:26 PM, Neil Conway  wrote:

> I spent a little while looking into this. The
> "PersistentVolumeEndpointsTest.OfferCreateThenEndpointRemove" test
> fails on the following expectations:
>
> https://github.com/apache/mesos/blob/1e57459b7d3f571bdf18fec29b070e
> 78ce719319/src/tests/persistent_volume_endpoints_tests.cpp#L1562
> https://github.com/apache/mesos/blob/1e57459b7d3f571bdf18fec29b070e
> 78ce719319/src/tests/persistent_volume_endpoints_tests.cpp#L1564
> https://github.com/apache/mesos/blob/1e57459b7d3f571bdf18fec29b070e
> 78ce719319/src/tests/persistent_volume_endpoints_tests.cpp#L1573
>
> Which all seem quite innocent: similar or identical preamble code
> occurs in many test cases. Looking at the log, it seems the scheduler
> begins the authentication process but authentication times out:
>
> 12:27:56.527899 31618 sched.cpp:226] Version: 1.2.0
> 12:27:56.528548 31638 sched.cpp:330] New master detected at
> master@172.17.0.2:48653
> 12:27:56.528661 31638 sched.cpp:396] Authenticating with master
> master@172.17.0.2:48653
> 12:27:56.528681 31638 sched.cpp:403] Using default CRAM-MD5 authenticatee
> 12:28:01.529717 31637 sched.cpp:526] Authentication timed out
> 12:28:10.795253 31637 sched.cpp:466] Failed to authenticate with
> master master@172.17.0.2:48653: Authentication discarded
>
> In the scheduler driver, we fail the "authenticating" future at
> 12:28:01, but it is ~9 seconds before the associated `onAny` callback
> is invoked to schedule retrying authentication; by the time the retry
> backoff timeout expires, we've exceeded the 15 second Future timeout
> in the test case.
>
> Note that between 12:28:01.5 and 12:28:10.8, there is essentially
> nothing happening:
>
> W1031 12:28:01.529717 31637 sched.cpp:526] Authentication timed out
> W1031 12:28:01.529752 31645 master.cpp:6789] Authentication timed out
> I1031 12:28:10.794798 31652 status_update_manager.cpp:203] Recovering
> status update manager
> W1031 12:28:10.795033 31645 master.cpp:6769] Failed to authenticate
> scheduler-877be3e9-9dc1-4de1-bf3e-a19b77b3d124@172.17.0.2:48653:
> Authentication discarded
> I1031 12:28:10.794939 31647 authenticator.cpp:432] Authentication
> session cleanup for crammd5-authenticatee(655)@172.17.0.2:48653
> I1031 12:28:10.795253 31637 sched.cpp:466] Failed to authenticate with
> master master@172.17.0.2:48653: Authentication discarded
>
> So I think the most likely culprit is VM lag.
>
> We can try to workaround this by increasing some of the timeouts for
> the test expectation futures, but of course that is just a kludge: if
> we're going to experience random ~9.5 second VM-wide pauses, the tests
> are likely to continue to be flaky unless we make more widespread
> changes (e.g., increasing ALL expectation futures timeouts).
>
> Neil
>
>
> On Mon, Oct 31, 2016 at 8:34 AM, Apache Jenkins Server
>  wrote:
> > See  COMPILER=gcc,CONFIGURATION=--verbose%20--enable-libevent%
> 20--enable-ssl,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=
> centos%3A7,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(
> !ubuntu-6)/2852/changes>
> >
> > Changes:
> >
> > [alexr] Updated the stale comment in agent flags.
> >
> > --
> > [...truncated 219320 lines...]
> > W1031 12:32:10.921492 31618 backend.cpp:76] Failed to create 'aufs'
> backend: AufsBackend requires root privileges, but is running as user mesos
> > W1031 12:32:10.921664 31618 backend.cpp:76] Failed to create 'bind'
> backend: BindBackend requires root privileges
> > I1031 12:32:10.925060 31647 slave.cpp:208] Mesos agent started on (635)@
> 172.17.0.2:48653
> > I1031 12:32:10.925091 31647 slave.cpp:209] Flags at startup: --acls=""
> --appc_simple_discovery_uri_prefix="http://; 
> --appc_store_dir="/tmp/mesos/store/appc"
> --authenticate_http_readonly="true" --authenticate_http_readwrite="true"
> --authenticatee="crammd5" --authentication_backoff_factor="1secs"
> --authorizer="local" --cgroups_cpu_enable_pids_and_tids_count="false"
> --cgroups_enable_cfs="false" --cgroups_hierarchy="/sys/fs/cgroup"
> --cgroups_limit_swap="false" --cgroups_root="mesos" 
> --container_disk_watch_interval="15secs"
> --containerizers="mesos" --credential="/tmp/Endpoint_SlaveEndpointTest_
> AuthorizedRequest_1_j6HfxC/credential" --default_role="*"
> --disk_watch_interval="1mins" --docker="docker"
> --docker_kill_orphans="true" --docker_registry="https://
> registry-1.docker.io" --docker_remove_delay="6hrs"
> --docker_socket="/var/run/docker.sock" --docker_stop_timeout="0ns"
> --docker_store_dir="/tmp/mesos/store/docker" --docker_volume_checkpoint_
> dir="/var/run/mesos/isolators/docker/volume" 
> --enforce_container_disk_quota="false"
> --executor_registration_timeout="1mins" 
> --executor_shutdown_grace_period="5secs"
>

Re: Please add me as a contributor

2016-11-01 Thread Joseph Wu 
Added!

On Tue, Nov 1, 2016 at 1:25 PM, Steven Locke  wrote:

> Hello,
>
> Please add me as a Mesos contributor to enable being assigned Jira issues.
>
> I signed up for Reviewboard and Jira as "slocke".
>
> Thanks,
> Steven
>
> --
> Steven Locke
> Software Engineering Intern
> www.mesosphere.com
>

Fwd: Please add me as a contributor

2016-11-01 Thread Steven Locke 
Hello,

Please add me as a Mesos contributor to enable being assigned Jira issues.

I signed up for Reviewboard and Jira as "slocke".

Thanks,
Steven

--
Steven Locke
Software Engineering Intern
www.mesosphere.com

Re: [VOTE] Release Apache Mesos 1.0.2 (rc2)

2016-11-01 Thread Joris Van Remoortere 
-1

Based on my message in the 1.1.0 vote:

My understanding after speaking with BenM is that the fix for
https://issues.apache.org/jira/browse/MESOS-6457 should be straight forward.

I don't think the cost of debugging and fixing production systems if they
run into this is worth skipping an easy fix. I have re-targeted the JIRA to
1.1.0, and 1.0.2.

Joris

On Mon, Oct 31, 2016 at 4:35 PM, Vinod Kone  wrote:

> Hi all,
>
>
> Please vote on releasing the following candidate as Apache Mesos 1.0.2.
>
>
> This is a bug fix release.
>
>
> The CHANGELOG for the release is available at:
>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_
> plain;f=CHANGELOG;hb=1.0.2-rc2
>
> 
> 
>
>
> The candidate for Mesos 1.0.2 release is available at:
>
> https://dist.apache.org/repos/dist/dev/mesos/1.0.2-rc2/mesos-1.0.2.tar.gz
>
>
> The tag to be voted on is 1.0.2-rc2:
>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.2-rc2
>
>
> The MD5 checksum of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/1.0.2-rc2/
> mesos-1.0.2.tar.gz.md5
>
>
> The signature of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/1.0.2-rc2/
> mesos-1.0.2.tar.gz.asc
>
>
> The PGP key used to sign the release is here:
>
> https://dist.apache.org/repos/dist/release/mesos/KEYS
>
>
> The JAR is up in Maven in a staging repository here:
>
> https://repository.apache.org/content/repositories/orgapachemesos-1164
>
>
> Please vote on releasing this package as Apache Mesos 1.0.2!
>
>
> The vote is open until Thu Nov  3 16:34:20 PDT 2016 and passes if a
> majority of at least 3 +1 PMC votes are cast.
>
>
> [ ] +1 Release this package as Apache Mesos 1.0.2
>
> [ ] -1 Do not release this package because ...
>
>
> Thanks,
>

Re: [VOTE] Release Apache Mesos 1.1.0 (rc2)

2016-11-01 Thread Joris Van Remoortere 
-1

My understanding after speaking with BenM is that the fix for
https://issues.apache.org/jira/browse/MESOS-6457 should be straight forward.

I don't think the cost of debugging and fixing production systems if they
run into this is worth skipping an easy fix. I have re-targeted the JIRA to
1.1.0.

Joris

On Mon, Oct 31, 2016 at 7:00 AM, Till Toenshoff  wrote:

> Hi all,
>
> Please vote on releasing the following candidate as Apache Mesos 1.1.0.
>
>
> 1.1.0 includes the following:
> 
> 
>  * [MESOS-2449] - **Experimental** support for launching a group of tasks
> via a new `LAUNCH_GROUP` Offer operation. Mesos will guarantee that
> either
> all tasks or none of the tasks in the group are delivered to the
> executor.
> Executors receive the task group via a new `LAUNCH_GROUP` event.
>
>   * [MESOS-2533] - **Experimental** support for HTTP and HTTPS health
> checks.
> Executors may now use the updated `HealthCheck` protobuf to implement
> HTTP(S) health checks. Both default executors (command and docker)
> leverage
> `curl` binary for sending HTTP(S) requests and connect to `127.0.0.1`,
> hence a task must listen on all interfaces. On Linux, For BRIDGE and
> USER
> modes, docker executor enters the task's network namespace.
>
>   * [MESOS-3421] - **Experimental** Support sharing of resources across
> containers. Currently persistent volumes are the only resources
> allowed to
> be shared.
>
>   * [MESOS-3567] - **Experimental** support for TCP health checks.
> Executors
> may now use the updated `HealthCheck` protobuf to implement TCP health
> checks. Both default executors (command and docker) connect to
> `127.0.0.1`,
> hence a task must listen on all interfaces. On Linux, For BRIDGE and
> USER
> modes, docker executor enters the task's network namespace.
>
>   * [MESOS-4324] - Allow access to persistent volumes as read-only or
> read-write
> by tasks. Mesos doesn't allow persistent volumes to be created as
> read-only
> but in 1.1 it starts allow tasks to use the volumes as read-only. This
> is
> mainly motivated by shared persistent volumes but applies to regular
> persistent volumes as well.
>
>   * [MESOS-5275] - **Experimental** support for linux capabilities.
> Frameworks
> or operators now have fine-grained control over the capabilities that a
> container may have. This allows a container to run as root, but not
> have all
> the privileges associated with the root user (e.g., CAP_SYS_ADMIN).
>
>   * [MESOS-5344] -- **Experimental** support for partition-aware Mesos
> frameworks. In previous Mesos releases, when an agent is partitioned
> from
> the master and then reregisters with the cluster, all tasks running on
> the
> agent are terminated and the agent is shutdown. In Mesos 1.1,
> partitioned
> agents will no longer be shutdown when they reregister with the
> master. By
> default, tasks running on such agents will still be killed (for
> backward
> compatibility); however, frameworks can opt-in to the new
> PARTITION_AWARE
> capability. If they do this, their tasks will not be killed when a
> partition
> is healed. This allows frameworks to define their own policies for how
> to
> handle partitioned tasks. Enabling the PARTITION_AWARE capability also
> introduces a new set of task states: TASK_UNREACHABLE, TASK_DROPPED,
> TASK_GONE, TASK_GONE_BY_OPERATOR, and TASK_UNKNOWN. These new states
> are
> intended to eventually replace the TASK_LOST state.
>
>   * [MESOS-6077] - **Experimental** A new default executor is introduced
> which
> frameworks can use to launch task groups as nested containers. All the
> nested containers share resources likes cpu, memory, network and
> volumes.
>
>   * [MESOS-6014] - **Experimental** A new port-mapper CNI plugin, the
> `mesos-cni-port-mapper` has been introduced. For Mesos containers,
> with the
> CNI port-mapper plugin, users can now expose container ports through
> host
> ports using DNAT. This is especially useful when Mesos containers are
> attached to isolated CNI networks such as private bridge networks, and
> the
> services running in the container needs to be exposed outside these
> isolated networks.
>
>
> The CHANGELOG for the release is available at:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_
> plain;f=CHANGELOG;hb=1.1.0-rc2
> 
> 
>
> The candidate for Mesos 1.1.0 release is available at:
> https://dist.apache.org/repos/dist/dev/mesos/1.1.0-rc2/mesos-1.1.0.tar.gz
>
> The tag to be voted on is 1.1.0-rc2:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.1.0-rc2
>
> The MD5 checksum of the tarball can be found at:
> https://dist.apache.org/repos/dist/dev/mesos/1.1.0-rc2/
>

Re: mesos 1.0.1 build error on CentOS 7.2

2016-11-01 Thread Yu Wei 
It seems that it's python problem. It failed to get correct result when 
comparing "pytz 2012d" and "pytz 2010".

After update "pytz>=2010d" to "pytz>=2010d" in 
mesos-1.0.1/build/3rdparty/protobuf-2.6.1/python/.eggs/google_apputils-0.4.2-py2.7.egg/EGG-INFOrequires.txt,
 build succeeded.


Thanks,

Jared, (韦煜）
Software developer
Interested in open source software, big data, Linux


From: haosdent 
Sent: Tuesday, November 1, 2016 2:30:54 PM
To: dev
Subject: Re: mesos 1.0.1 build error on CentOS 7.2

Have you install pytz in your operate system? What's the output of `pip
freeze|grep pytz`?

On Tue, Nov 1, 2016 at 2:17 PM, Yu Wei  wrote:

> Hi Guys,
>
> I tried to build mesos 1.0.1 on centos 7.2 and met following error.
>
> Building protobuf Python egg ...
> cd ../3rdparty/protobuf-2.6.1/python &&\
>   CC="gcc"\
>   CXX="g++"\
>   CFLAGS="-g1 -O0 -Wno-unused-local-typedefs"\
>   CXXFLAGS="-g1 -O0 -Wno-unused-local-typedefs -std=c++11"\
>   PYTHONPATH=/home/dcos/repo/mesos-1.0.1/build/3rdparty/setuptools-20.9.0
>   \
>   /usr/bin/python setup.py build bdist_egg
>
> Installed /home/dcos/repo/mesos-1.0.1/build/3rdparty/protobuf-2.6.1/
> python/.eggs/google_apputils-0.4.2-py2.7.egg
> Traceback (most recent call last):
>   File "setup.py", line 200, in 
> "Protocol Buffers are Google's data interchange format.",
>   File "/usr/lib64/python2.7/distutils/core.py", line 112, in setup
> _setup_distribution = dist = klass(attrs)
>   File 
> "/home/dcos/repo/mesos-1.0.1/build/3rdparty/setuptools-20.9.0/setuptools/dist.py",
> line 269, in __init__
> self.fetch_build_eggs(attrs['setup_requires'])
>   File 
> "/home/dcos/repo/mesos-1.0.1/build/3rdparty/setuptools-20.9.0/setuptools/dist.py",
> line 313, in fetch_build_eggs
> replace_conflicting=True,
>   File "/home/dcos/repo/mesos-1.0.1/build/3rdparty/setuptools-20.
> 9.0/pkg_resources/__init__.py", line 826, in resolve
> dist = best[req.key] = env.best_match(req, ws, installer)
>   File "/home/dcos/repo/mesos-1.0.1/build/3rdparty/setuptools-20.
> 9.0/pkg_resources/__init__.py", line 1085, in best_match
> dist = working_set.find(req)
>   File "/home/dcos/repo/mesos-1.0.1/build/3rdparty/setuptools-20.
> 9.0/pkg_resources/__init__.py", line 695, in find
> raise VersionConflict(dist, req)
> pkg_resources.VersionConflict: (pytz 2012d (/usr/lib/python2.7/site-packages),
> Requirement.parse('pytz>=2010'))
> make[2]: *** [../3rdparty/protobuf-2.6.1/python/dist/protobuf-2.6.1-py2.7.egg]
> Error 1
> make[2]: Leaving directory `/home/dcos/repo/mesos-1.0.1/build/src'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/home/dcos/repo/mesos-1.0.1/build/src'
> make: *** [all-recursive] Error 1
>
>
> Any thoughts about this?
>
>
> Thanks,
>
> Jared, (??)
> Software developer
> Interested in open source software, big data, Linux
>



--
Best Regards,
Haosdent Huang

Re: mesos 1.0.1 build error on CentOS 7.2

2016-11-01 Thread haosdent 
Have you install pytz in your operate system? What's the output of `pip
freeze|grep pytz`?

On Tue, Nov 1, 2016 at 2:17 PM, Yu Wei  wrote:

> Hi Guys,
>
> I tried to build mesos 1.0.1 on centos 7.2 and met following error.
>
> Building protobuf Python egg ...
> cd ../3rdparty/protobuf-2.6.1/python &&\
>   CC="gcc"\
>   CXX="g++"\
>   CFLAGS="-g1 -O0 -Wno-unused-local-typedefs"\
>   CXXFLAGS="-g1 -O0 -Wno-unused-local-typedefs -std=c++11"\
>   PYTHONPATH=/home/dcos/repo/mesos-1.0.1/build/3rdparty/setuptools-20.9.0
>   \
>   /usr/bin/python setup.py build bdist_egg
>
> Installed /home/dcos/repo/mesos-1.0.1/build/3rdparty/protobuf-2.6.1/
> python/.eggs/google_apputils-0.4.2-py2.7.egg
> Traceback (most recent call last):
>   File "setup.py", line 200, in 
> "Protocol Buffers are Google's data interchange format.",
>   File "/usr/lib64/python2.7/distutils/core.py", line 112, in setup
> _setup_distribution = dist = klass(attrs)
>   File 
> "/home/dcos/repo/mesos-1.0.1/build/3rdparty/setuptools-20.9.0/setuptools/dist.py",
> line 269, in __init__
> self.fetch_build_eggs(attrs['setup_requires'])
>   File 
> "/home/dcos/repo/mesos-1.0.1/build/3rdparty/setuptools-20.9.0/setuptools/dist.py",
> line 313, in fetch_build_eggs
> replace_conflicting=True,
>   File "/home/dcos/repo/mesos-1.0.1/build/3rdparty/setuptools-20.
> 9.0/pkg_resources/__init__.py", line 826, in resolve
> dist = best[req.key] = env.best_match(req, ws, installer)
>   File "/home/dcos/repo/mesos-1.0.1/build/3rdparty/setuptools-20.
> 9.0/pkg_resources/__init__.py", line 1085, in best_match
> dist = working_set.find(req)
>   File "/home/dcos/repo/mesos-1.0.1/build/3rdparty/setuptools-20.
> 9.0/pkg_resources/__init__.py", line 695, in find
> raise VersionConflict(dist, req)
> pkg_resources.VersionConflict: (pytz 2012d (/usr/lib/python2.7/site-packages),
> Requirement.parse('pytz>=2010'))
> make[2]: *** [../3rdparty/protobuf-2.6.1/python/dist/protobuf-2.6.1-py2.7.egg]
> Error 1
> make[2]: Leaving directory `/home/dcos/repo/mesos-1.0.1/build/src'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/home/dcos/repo/mesos-1.0.1/build/src'
> make: *** [all-recursive] Error 1
>
>
> Any thoughts about this?
>
>
> Thanks,
>
> Jared, (??)
> Software developer
> Interested in open source software, big data, Linux
>



-- 
Best Regards,
Haosdent Huang

mesos 1.0.1 build error on CentOS 7.2

2016-11-01 Thread Yu Wei 
Hi Guys,

I tried to build mesos 1.0.1 on centos 7.2 and met following error.

Building protobuf Python egg ...
cd ../3rdparty/protobuf-2.6.1/python &&\
  CC="gcc"\
  CXX="g++"\
  CFLAGS="-g1 -O0 -Wno-unused-local-typedefs"\
  CXXFLAGS="-g1 -O0 -Wno-unused-local-typedefs -std=c++11"\
  PYTHONPATH=/home/dcos/repo/mesos-1.0.1/build/3rdparty/setuptools-20.9.0\
  /usr/bin/python setup.py build bdist_egg

Installed 
/home/dcos/repo/mesos-1.0.1/build/3rdparty/protobuf-2.6.1/python/.eggs/google_apputils-0.4.2-py2.7.egg
Traceback (most recent call last):
  File "setup.py", line 200, in 
"Protocol Buffers are Google's data interchange format.",
  File "/usr/lib64/python2.7/distutils/core.py", line 112, in setup
_setup_distribution = dist = klass(attrs)
  File 
"/home/dcos/repo/mesos-1.0.1/build/3rdparty/setuptools-20.9.0/setuptools/dist.py",
 line 269, in __init__
self.fetch_build_eggs(attrs['setup_requires'])
  File 
"/home/dcos/repo/mesos-1.0.1/build/3rdparty/setuptools-20.9.0/setuptools/dist.py",
 line 313, in fetch_build_eggs
replace_conflicting=True,
  File 
"/home/dcos/repo/mesos-1.0.1/build/3rdparty/setuptools-20.9.0/pkg_resources/__init__.py",
 line 826, in resolve
dist = best[req.key] = env.best_match(req, ws, installer)
  File 
"/home/dcos/repo/mesos-1.0.1/build/3rdparty/setuptools-20.9.0/pkg_resources/__init__.py",
 line 1085, in best_match
dist = working_set.find(req)
  File 
"/home/dcos/repo/mesos-1.0.1/build/3rdparty/setuptools-20.9.0/pkg_resources/__init__.py",
 line 695, in find
raise VersionConflict(dist, req)
pkg_resources.VersionConflict: (pytz 2012d (/usr/lib/python2.7/site-packages), 
Requirement.parse('pytz>=2010'))
make[2]: *** [../3rdparty/protobuf-2.6.1/python/dist/protobuf-2.6.1-py2.7.egg] 
Error 1
make[2]: Leaving directory `/home/dcos/repo/mesos-1.0.1/build/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/dcos/repo/mesos-1.0.1/build/src'
make: *** [all-recursive] Error 1


Any thoughts about this?


Thanks,

Jared, (??)
Software developer
Interested in open source software, big data, Linux