Re: [VOTE] Release Apache Aurora 0.11.0 debs

2015-12-28 Thread Mauricio Garavaglia 
+1 non-binding, with the amended "Installing Mesos" section in the install
guide.

On Mon, Dec 28, 2015 at 12:19 PM, John Sirois  wrote:

> On Sun, Dec 27, 2015 at 1:33 PM, Bill Farner  wrote:
>
> > +1 to proposing this on the mesos dev list!
> >
>
> +1 - it would be wonderful to have mesos support deb (and rpm) directly as
> part of its release process.
>
>
> >
> > On Sat, Dec 26, 2015 at 3:21 PM, ben...@gmail.com 
> > wrote:
> >
> > > I've been producing a set of Mesos debs that are not derived from the
> > > Mesosphere packages, with the goal of having a set of debs that follow
> > > Debian conventions and packaging policies as closely as I can get them.
> > > For instance, rather than a single mesos.deb containing everything,
> there
> > > are separate packages for libmesos, libmesos-dev, python-mesos,
> > > mesos-master, and mesos-slave, with each having a corrected set of
> > > dependencies.
> > >
> > > I also decided to forego the init wrapper script from the mesosphere
> > debs,
> > > meaning that daemon configuration is handled via
> > /etc/default/mesos-master
> > > and /etc/default/mesos-slave rather than many files in /etc/mesos/*
> > > /etc/mesos-master/* /etc/mesos-slave/*, and daemon log output is
> handled
> > by
> > > upstart rather than piped to syslog.
> > >
> > > My source tree can be found at
> > > https://github.com/benley/mesos/tree/debian-packaging
> > >
> > > I've published a set of the resulting debs for Ubuntu 14.04 at
> > > http://zoiks.net/~benley/debs/mesos/ if anyone wants to check them
> out.
> > > They depend on libnl, which is backported for trusty at
> > > http://zoiks.net/~benley/debs/libnl/.
> > >
> > > All of this is a continuation of work that was begun by jfarrell, so
> > thanks
> > > are due to him for providing a starting point.
> > >
> > > If people find these alternative packages useful I'd be happy to
> > contribute
> > > the sources to the mesos project in whatever way is appropriate.  I'm
> > also
> > > open to suggestions for things to change about the builds, of course.
> > >
> > > On Wed, Dec 23, 2015 at 5:56 PM Zameer Manji 
> wrote:
> > >
> > > > John,
> > > >
> > > > I think you you have found a bug either in the installation guide or
> in
> > > our
> > > > packages. We can either amend the "Installing Mesos" section to
> include
> > > > installing this package or we can fix our packages to list this
> > > dependency.
> > > > I'm not sure on how packages should behave, so I am not sure on what
> we
> > > > should do here.
> > > >
> > > > Maybe we could amend the guide for now, release these debs and figure
> > out
> > > > how to prevent this issue for the next release? Perhaps we could
> assist
> > > the
> > > > Mesos project in hosting their own packages so we don't need to rely
> on
> > > > these incorrectly packaged artifacts from Mesosphere Inc?
> > > >
> > > >
> > > > On Wed, Dec 23, 2015 at 4:23 PM, John Sirois 
> > > wrote:
> > > >
> > > > > On Wed, Dec 23, 2015 at 2:14 PM, John Sirois 
> > > > wrote:
> > > > >
> > > > > > -1 non-binding
> > > > > >
> > > > > > Tested using new installing guide in Vagrant image using
> > > > > 'ubuntu/trusty64'
> > > > > > against mesos 0.24.1.
> > > > > > Everything worked after 2 tweaks:
> > > > > > 1. sudo apt-get install libcurl4-nss-dev
> > > > > > 2. $ diff /etc/init/thermos.conf.orig /etc/init/thermos.conf
> > > > > > 23a24
> > > > > > > --mesos-root=/tmp/mesos \
> > > > > >
> > > > > > Without item 1 the thermos-executor fails to operate:
> > > > > > Traceback (most recent call last):
> > > > > >   File "apache/aurora/executor/bin/thermos_executor_main.py",
> line
> > > 45,
> > > > in
> > > > > > 
> > > > > > from mesos.native import MesosExecutorDriver
> > > > > >   File
> > > > > >
> > > > >
> > > >
> > >
> >
> "/root/.pex/install/mesos.native-0.24.1-py2.7-linux-x86_64.egg.c2a926cdb8d599d35c7a569171311edaebda9341/mesos.native-0.24.1-py2.7-linux-x86_64.egg/mesos/native/__init__.py",
> > > > > > line 17, in 
> > > > > > from ._mesos import MesosExecutorDriverImpl
> > > > > > ImportError: libcurl-nss.so.4: cannot open shared object file: No
> > > such
> > > > > > file or directory
> > > > > >
> > > > > > Seems like `libcurl4-nss-dev` should be a dependency of the
> > > > > > aurora-executor deb.
> > > > > >
> > > > >
> > > > > I guess libcurl is properly a dependency of mesos which just means
> > the
> > > > > install guide rec to use the mesosphere mesos debs is suboptimal.
> > That
> > > > > said - aurora-executor and aurora-scheduler should really depend on
> > > > mesos,
> > > > > but much of the install guide works around the fact these deps
> aren't
> > > > > expressed in the debs either.
> > > > > I think I'm realizing this means the current partial-working state
> of
> > > the
> > > > > debs is accepted as better than no debs ... so
> > > > >
> > > > > I change my vote

Re: [VOTE] Release Apache Aurora 0.11.0 debs

2015-12-28 Thread John Sirois 
On Sun, Dec 27, 2015 at 1:33 PM, Bill Farner  wrote:

> +1 to proposing this on the mesos dev list!
>

+1 - it would be wonderful to have mesos support deb (and rpm) directly as
part of its release process.


>
> On Sat, Dec 26, 2015 at 3:21 PM, ben...@gmail.com 
> wrote:
>
> > I've been producing a set of Mesos debs that are not derived from the
> > Mesosphere packages, with the goal of having a set of debs that follow
> > Debian conventions and packaging policies as closely as I can get them.
> > For instance, rather than a single mesos.deb containing everything, there
> > are separate packages for libmesos, libmesos-dev, python-mesos,
> > mesos-master, and mesos-slave, with each having a corrected set of
> > dependencies.
> >
> > I also decided to forego the init wrapper script from the mesosphere
> debs,
> > meaning that daemon configuration is handled via
> /etc/default/mesos-master
> > and /etc/default/mesos-slave rather than many files in /etc/mesos/*
> > /etc/mesos-master/* /etc/mesos-slave/*, and daemon log output is handled
> by
> > upstart rather than piped to syslog.
> >
> > My source tree can be found at
> > https://github.com/benley/mesos/tree/debian-packaging
> >
> > I've published a set of the resulting debs for Ubuntu 14.04 at
> > http://zoiks.net/~benley/debs/mesos/ if anyone wants to check them out.
> > They depend on libnl, which is backported for trusty at
> > http://zoiks.net/~benley/debs/libnl/.
> >
> > All of this is a continuation of work that was begun by jfarrell, so
> thanks
> > are due to him for providing a starting point.
> >
> > If people find these alternative packages useful I'd be happy to
> contribute
> > the sources to the mesos project in whatever way is appropriate.  I'm
> also
> > open to suggestions for things to change about the builds, of course.
> >
> > On Wed, Dec 23, 2015 at 5:56 PM Zameer Manji  wrote:
> >
> > > John,
> > >
> > > I think you you have found a bug either in the installation guide or in
> > our
> > > packages. We can either amend the "Installing Mesos" section to include
> > > installing this package or we can fix our packages to list this
> > dependency.
> > > I'm not sure on how packages should behave, so I am not sure on what we
> > > should do here.
> > >
> > > Maybe we could amend the guide for now, release these debs and figure
> out
> > > how to prevent this issue for the next release? Perhaps we could assist
> > the
> > > Mesos project in hosting their own packages so we don't need to rely on
> > > these incorrectly packaged artifacts from Mesosphere Inc?
> > >
> > >
> > > On Wed, Dec 23, 2015 at 4:23 PM, John Sirois 
> > wrote:
> > >
> > > > On Wed, Dec 23, 2015 at 2:14 PM, John Sirois 
> > > wrote:
> > > >
> > > > > -1 non-binding
> > > > >
> > > > > Tested using new installing guide in Vagrant image using
> > > > 'ubuntu/trusty64'
> > > > > against mesos 0.24.1.
> > > > > Everything worked after 2 tweaks:
> > > > > 1. sudo apt-get install libcurl4-nss-dev
> > > > > 2. $ diff /etc/init/thermos.conf.orig /etc/init/thermos.conf
> > > > > 23a24
> > > > > > --mesos-root=/tmp/mesos \
> > > > >
> > > > > Without item 1 the thermos-executor fails to operate:
> > > > > Traceback (most recent call last):
> > > > >   File "apache/aurora/executor/bin/thermos_executor_main.py", line
> > 45,
> > > in
> > > > > 
> > > > > from mesos.native import MesosExecutorDriver
> > > > >   File
> > > > >
> > > >
> > >
> >
> "/root/.pex/install/mesos.native-0.24.1-py2.7-linux-x86_64.egg.c2a926cdb8d599d35c7a569171311edaebda9341/mesos.native-0.24.1-py2.7-linux-x86_64.egg/mesos/native/__init__.py",
> > > > > line 17, in 
> > > > > from ._mesos import MesosExecutorDriverImpl
> > > > > ImportError: libcurl-nss.so.4: cannot open shared object file: No
> > such
> > > > > file or directory
> > > > >
> > > > > Seems like `libcurl4-nss-dev` should be a dependency of the
> > > > > aurora-executor deb.
> > > > >
> > > >
> > > > I guess libcurl is properly a dependency of mesos which just means
> the
> > > > install guide rec to use the mesosphere mesos debs is suboptimal.
> That
> > > > said - aurora-executor and aurora-scheduler should really depend on
> > > mesos,
> > > > but much of the install guide works around the fact these deps aren't
> > > > expressed in the debs either.
> > > > I think I'm realizing this means the current partial-working state of
> > the
> > > > debs is accepted as better than no debs ... so
> > > >
> > > > I change my vote to +1
> > > >
> > > >
> > > > >
> > > > >
> > > > > On Wed, Dec 23, 2015 at 10:44 AM, Bill Farner 
> > > > wrote:
> > > > >
> > > > >> Note that i've lengthened this vote to accommodate the holidays.
> > > > >>
> > > > >> Please consider verifying these debs using the recently-added
> > install
> > > > >> guide:
> > > https://github.com/apache/aurora/blob/master/docs/installing.md
> > > > >>
> > > >

Re: Ticket cleanup

2015-12-28 Thread Joshua Cohen 
I'm not sure I agree with this sentiment. I don't have any problems with an
aspirational backlog of tickets. At the very least it's a place to refer
people who request commonly asked for features. Perhaps the solution isn't
to close tickets that we don't imagine will see attention in the immediate
future, but rather to label them so they're easy to filter out from the
ones what will?

Also, in the future, perhaps have this discussion before closing tickets
en-masse? Especially over a holiday weekend when people aren't around to
discuss? It's not likely that first thing back from a long weekend many
folks are going to take time to scan read through a list of a hundred jira
emails to see if any of their pet issues were resolved ;).

On Mon, Dec 28, 2015 at 10:01 AM, Erb, Stephan 
wrote:

> +1. Having a well-groomed bug tracker is very helpful for everyone
> involved.
>
> In particular, it would be great if we could get the bug count to 0 over
> the course of the next months. Either bugs are important and we get them
> fixed, or we have to guts to close them as won't fix and update the
> documentation accordingly.
>
> Best Regards,
> Stephan
>
>
> 
> From: Bill Farner 
> Sent: Monday, December 28, 2015 4:44 PM
> To: dev@aurora.apache.org
> Subject: Ticket cleanup
>
> I'd like to share some rationale on my JIRA activity last night.  I'm happy
> to undo any of the changes if folks disagree.
>
> We had approximately 450 open tickets prior to last night.  Personally, I
> found it daunting to find things we should actually work on.  To remedy
> this, I started by skimming through tickets that have not been touched in
> the last 6 months.  This quickly identified a swath of tickets that may be
> valid, but I did not imagine them being valuable enough to address in the
> foreseeable future.
>
> If there is interest in doing more of this, I welcome help from others to
> continue reducing the queue to something more manageable.  My culling
> reduced the queue but it is still very large.
>
> If you do participate in this, please try to avoid using "Resolved, Fixed"
> so as to not add noise to the changelog in the next release.
>

Re: Ticket cleanup

2015-12-28 Thread Bill Farner 
>
> I don't have any problems with an aspirational backlog of tickets.


I don't either, until they rot.  Many of the tickets i closed haven't been
touched in over a year, some nearly 2.  This doesn't always mean they're
invalid, but definitely means we don't care much about completing them.
Personally, i think we should move on from these tickets and reopen them if
we ever decide to revisit

Also, in the future, perhaps have this discussion before closing tickets
> en-masse?


I can see why that is frustrating.  I had an impromptu discussion with
Zameer prior to this, and in the past others have remarked on the
overwhelming nature of our queue; which prompted me to take action.  Not
consensus by any means, but i was assuming at the least i can undo my
changes.

In case it's helpful, here's a query that captures the tickets i closed
yesterday:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20AURORA%20and%20status%3DResolved%20and%20status%20changed%20by%20wfarner%20and%20updatedDate%3E%272015%2F12%2F27%27%20and%20updatedDate%3C%272015%2F12%2F28%27

On Mon, Dec 28, 2015 at 8:26 AM, Joshua Cohen  wrote:

> I'm not sure I agree with this sentiment. I don't have any problems with an
> aspirational backlog of tickets. At the very least it's a place to refer
> people who request commonly asked for features. Perhaps the solution isn't
> to close tickets that we don't imagine will see attention in the immediate
> future, but rather to label them so they're easy to filter out from the
> ones what will?
>
> Also, in the future, perhaps have this discussion before closing tickets
> en-masse? Especially over a holiday weekend when people aren't around to
> discuss? It's not likely that first thing back from a long weekend many
> folks are going to take time to scan read through a list of a hundred jira
> emails to see if any of their pet issues were resolved ;).
>
> On Mon, Dec 28, 2015 at 10:01 AM, Erb, Stephan <
> stephan@blue-yonder.com>
> wrote:
>
> > +1. Having a well-groomed bug tracker is very helpful for everyone
> > involved.
> >
> > In particular, it would be great if we could get the bug count to 0 over
> > the course of the next months. Either bugs are important and we get them
> > fixed, or we have to guts to close them as won't fix and update the
> > documentation accordingly.
> >
> > Best Regards,
> > Stephan
> >
> >
> > 
> > From: Bill Farner 
> > Sent: Monday, December 28, 2015 4:44 PM
> > To: dev@aurora.apache.org
> > Subject: Ticket cleanup
> >
> > I'd like to share some rationale on my JIRA activity last night.  I'm
> happy
> > to undo any of the changes if folks disagree.
> >
> > We had approximately 450 open tickets prior to last night.  Personally, I
> > found it daunting to find things we should actually work on.  To remedy
> > this, I started by skimming through tickets that have not been touched in
> > the last 6 months.  This quickly identified a swath of tickets that may
> be
> > valid, but I did not imagine them being valuable enough to address in the
> > foreseeable future.
> >
> > If there is interest in doing more of this, I welcome help from others to
> > continue reducing the queue to something more manageable.  My culling
> > reduced the queue but it is still very large.
> >
> > If you do participate in this, please try to avoid using "Resolved,
> Fixed"
> > so as to not add noise to the changelog in the next release.
> >
>

Re: Ticket cleanup

2015-12-28 Thread Erb, Stephan 
+1. Having a well-groomed bug tracker is very helpful for everyone involved.

In particular, it would be great if we could get the bug count to 0 over the 
course of the next months. Either bugs are important and we get them fixed, or 
we have to guts to close them as won't fix and update the documentation 
accordingly.

Best Regards,
Stephan



From: Bill Farner 
Sent: Monday, December 28, 2015 4:44 PM
To: dev@aurora.apache.org
Subject: Ticket cleanup

I'd like to share some rationale on my JIRA activity last night.  I'm happy
to undo any of the changes if folks disagree.

We had approximately 450 open tickets prior to last night.  Personally, I
found it daunting to find things we should actually work on.  To remedy
this, I started by skimming through tickets that have not been touched in
the last 6 months.  This quickly identified a swath of tickets that may be
valid, but I did not imagine them being valuable enough to address in the
foreseeable future.

If there is interest in doing more of this, I welcome help from others to
continue reducing the queue to something more manageable.  My culling
reduced the queue but it is still very large.

If you do participate in this, please try to avoid using "Resolved, Fixed"
so as to not add noise to the changelog in the next release.

AURORA-1440 Evaluate Fenzo scheduling library

2015-12-28 Thread Mauricio Garavaglia 
Hello,

I found the issue AURORA-1440
 about evaluating fenzo
to replace the scheduling algorithm. Has there been any progress on it? is
the intention just replace the implementation or also expose part of the
configurations that fenzo allows?

It would be handy to be able to select, for example, between cpu bin
packing and memory bin packing. But also take advantage of the rich
scheduling constraints api that it has. I assume a lot of discussion would
be needed regarding how to expose them though :)
Thanks


Mauricio

Re: [PROPOSAL] Use standard logging practices

2015-12-28 Thread Zameer Manji 
+1

Could we still keep the Glog formatter class so folks who want to have the
same log formatting between the Aurora log lines and the Mesos driver
(which prints to stderr by default) just have to add a line to their
logging.properties?

The alternative means users would have to build their own glog formatter
and add it to the classpath in addition to setting the formatter in
logging.properties which is not straight forward if you want to have
reasonably formatted log entries between the driver and the scheduler.

On Mon, Dec 28, 2015 at 2:54 PM, Bill Farner  wrote:

> We're currently using some logging scaffolding carried over from Twitter
> commons.  I would like to propose that we dismantle some of this in favor
> of more standard java application logging conventions.
>
> Concretely, i propose we remove the following scheduler command line
> arguments:
> -logtostderr
> -alsologtostderr
> -vlog
> -vmodule
> -use_glog_formatter
>
> Instead of these, we can allow users to customize logging via standard
> java.util.logging inputs (e.g. logging.properties).  We could explore using
> an alternative to java.util.logging, but i suggest we retain that backend
> for now (since it's what we're currently using).
>
> --
> Zameer Manji
>
>

Re: Build failed in Jenkins: aurora-packaging-nightly #142

2015-12-28 Thread John Sirois 
On Mon, Dec 28, 2015 at 5:31 PM, Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See 
>
> --
> [...truncated 3091 lines...]
> +
> PATH=/usr/lib/jvm/java-1.8.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> + wget https://services.gradle.org/distributions/gradle-2.7-bin.zip
> --2015-12-29 00:24:34--
> https://services.gradle.org/distributions/gradle-2.7-bin.zip
> Resolving services.gradle.org (services.gradle.org)... 104.25.173.23,
> 104.25.172.23, 2400:cb00:2048:1::6819:ad17, ...
> Connecting to services.gradle.org (services.gradle.org)|104.25.173.23|:443...
> connected.
> HTTP request sent, awaiting response... 301 Moved Permanently
> Location: https://downloads.gradle.org/distributions/gradle-2.7-bin.zip
> [following]
> --2015-12-29 00:24:34--
> https://downloads.gradle.org/distributions/gradle-2.7-bin.zip
> Resolving downloads.gradle.org (downloads.gradle.org)... 54.230.145.94
> Connecting to downloads.gradle.org 
> (downloads.gradle.org)|54.230.145.94|:443...
> connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 44809759 (43M) [application/zip]
> Saving to: 'gradle-2.7-bin.zip'
>
>
>  0% [   ] 0   --.-K/s
>  0% [   ] 242,984 1.08MB/s
>  1% [   ] 849,192 1.88MB/s
>  4% [>  ] 2,209,064   3.26MB/s
> 11% [===>   ] 5,174,568   5.73MB/s
> 24% [>  ] 11,014,966  9.89MB/s
> 46% [=> ] 20,707,854  15.6MB/s
> 64% [>  ] 28,861,006  18.8MB/s
> 79% [=> ] 35,535,326  20.4MB/s
> 95% [>  ] 42,998,950  22.0MB/s
> 100%[==>] 44,809,759  22.4MB/s   in
> 1.9s
>
> 2015-12-29 00:24:36 (22.4 MB/s) - 'gradle-2.7-bin.zip' saved
> [44809759/44809759]
>
> + unzip gradle-2.7-bin.zip
> Archive:  gradle-2.7-bin.zip
>creating: gradle-2.7/
>   inflating: gradle-2.7/getting-started.html
>   inflating: gradle-2.7/LICENSE
>   inflating: gradle-2.7/NOTICE
>   inflating: gradle-2.7/changelog.txt
>creating: gradle-2.7/init.d/
>   inflating: gradle-2.7/init.d/readme.txt
>creating: gradle-2.7/media/
>   inflating: gradle-2.7/media/gradle-icon-512x512.png
>   inflating: gradle-2.7/media/gradle-icon-16x16.png
>   inflating: gradle-2.7/media/gradle.icns
>   inflating: gradle-2.7/media/gradle-icon-128x128.png
>   inflating: gradle-2.7/media/gradle-icon-256x256.png
>   inflating: gradle-2.7/media/gradle-icon-48x48.png
>   inflating: gradle-2.7/media/gradle-icon-24x24.png
>   inflating: gradle-2.7/media/gradle-icon-64x64.png
>   inflating: gradle-2.7/media/gradle-icon-32x32.png
>creating: gradle-2.7/bin/
>   inflating: gradle-2.7/bin/gradle.bat
>   inflating: gradle-2.7/bin/gradle
>creating: gradle-2.7/lib/
>   inflating: gradle-2.7/lib/gradle-launcher-2.7.jar
>   inflating: gradle-2.7/lib/gradle-wrapper-2.7.jar
>   inflating: gradle-2.7/lib/gradle-base-services-2.7.jar
>   inflating: gradle-2.7/lib/gradle-core-2.7.jar
>   inflating: gradle-2.7/lib/gradle-cli-2.7.jar
>   inflating: gradle-2.7/lib/gradle-ui-2.7.jar
>   inflating: gradle-2.7/lib/gradle-tooling-api-2.7.jar
>   inflating: gradle-2.7/lib/gradle-native-2.7.jar
>   inflating: gradle-2.7/lib/slf4j-api-1.7.10.jar
>   inflating: gradle-2.7/lib/guava-jdk5-17.0.jar
>   inflating: gradle-2.7/lib/commons-lang-2.6.jar
>   inflating: gradle-2.7/lib/groovy-all-2.3.10.jar
>   inflating: gradle-2.7/lib/gradle-model-core-2.7.jar
>   inflating: gradle-2.7/lib/gradle-model-groovy-2.7.jar
>   inflating: gradle-2.7/lib/asm-all-5.0.3.jar
>   inflating: gradle-2.7/lib/ant-1.9.3.jar
>   inflating: gradle-2.7/lib/commons-collections-3.2.1.jar
>   inflating: gradle-2.7/lib/commons-io-1.4.jar
>   inflating: gradle-2.7/lib/jcip-annotations-1.0.jar
>   inflating: gradle-2.7/lib/jul-to-slf4j-1.7.10.jar
>   inflating: gradle-2.7/lib/jarjar-1.3.jar
>   inflating: gradle-2.7/lib/javax.inject-1.jar
>   inflating: gradle-2.7/lib/gradle-base-services-groovy-2.7.jar
>   inflating: gradle-2.7/lib/gradle-messaging-2.7.jar
>   inflating: gradle-2.7/lib/gradle-resources-2.7.jar
>   inflating: gradle-2.7/lib/gradle-docs-2.7.jar
>   inflating: gradle-2.7/lib/log4j-over-slf4j-1.7.10.jar
>   inflating: gradle-2.7/lib/jcl-over-slf4j-1.7.10.jar
>   inflating: gradle-2.7/lib/gradle-open-api-2.7.jar
>   inflating: gradle-2.7/lib/dom4j-1.6.1.jar
>   inflating: gradle-2.7/lib/jaxen-1.1.jar
>   inflating: gradle-2.7/lib/jna-3.2.7.jar
>   inflating: gradle-2.7/lib/native-platform-0.10.jar
>   inflating: gradle-2.7/lib/jansi-1.2.1.jar
>   inflating: gradle-2.7/lib/ant-launcher-1.9.3.jar
>   inflating: gradle-2.7/lib/kryo-2.20.jar
>   inflating:

Build failed in Jenkins: aurora-packaging-nightly #142

2015-12-28 Thread Apache Jenkins Server 
See 

--
[...truncated 3091 lines...]
+ 
PATH=/usr/lib/jvm/java-1.8.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
+ wget https://services.gradle.org/distributions/gradle-2.7-bin.zip
--2015-12-29 00:24:34--  
https://services.gradle.org/distributions/gradle-2.7-bin.zip
Resolving services.gradle.org (services.gradle.org)... 104.25.173.23, 
104.25.172.23, 2400:cb00:2048:1::6819:ad17, ...
Connecting to services.gradle.org (services.gradle.org)|104.25.173.23|:443... 
connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://downloads.gradle.org/distributions/gradle-2.7-bin.zip 
[following]
--2015-12-29 00:24:34--  
https://downloads.gradle.org/distributions/gradle-2.7-bin.zip
Resolving downloads.gradle.org (downloads.gradle.org)... 54.230.145.94
Connecting to downloads.gradle.org (downloads.gradle.org)|54.230.145.94|:443... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: 44809759 (43M) [application/zip]
Saving to: 'gradle-2.7-bin.zip'


 0% [   ] 0   --.-K/s  
 0% [   ] 242,984 1.08MB/s 
 1% [   ] 849,192 1.88MB/s 
 4% [>  ] 2,209,064   3.26MB/s 
11% [===>   ] 5,174,568   5.73MB/s 
24% [>  ] 11,014,966  9.89MB/s 
46% [=> ] 20,707,854  15.6MB/s 
64% [>  ] 28,861,006  18.8MB/s 
79% [=> ] 35,535,326  20.4MB/s 
95% [>  ] 42,998,950  22.0MB/s 
100%[==>] 44,809,759  22.4MB/s   in 1.9s   

2015-12-29 00:24:36 (22.4 MB/s) - 'gradle-2.7-bin.zip' saved [44809759/44809759]

+ unzip gradle-2.7-bin.zip
Archive:  gradle-2.7-bin.zip
   creating: gradle-2.7/
  inflating: gradle-2.7/getting-started.html  
  inflating: gradle-2.7/LICENSE  
  inflating: gradle-2.7/NOTICE   
  inflating: gradle-2.7/changelog.txt  
   creating: gradle-2.7/init.d/
  inflating: gradle-2.7/init.d/readme.txt  
   creating: gradle-2.7/media/
  inflating: gradle-2.7/media/gradle-icon-512x512.png  
  inflating: gradle-2.7/media/gradle-icon-16x16.png  
  inflating: gradle-2.7/media/gradle.icns  
  inflating: gradle-2.7/media/gradle-icon-128x128.png  
  inflating: gradle-2.7/media/gradle-icon-256x256.png  
  inflating: gradle-2.7/media/gradle-icon-48x48.png  
  inflating: gradle-2.7/media/gradle-icon-24x24.png  
  inflating: gradle-2.7/media/gradle-icon-64x64.png  
  inflating: gradle-2.7/media/gradle-icon-32x32.png  
   creating: gradle-2.7/bin/
  inflating: gradle-2.7/bin/gradle.bat  
  inflating: gradle-2.7/bin/gradle   
   creating: gradle-2.7/lib/
  inflating: gradle-2.7/lib/gradle-launcher-2.7.jar  
  inflating: gradle-2.7/lib/gradle-wrapper-2.7.jar  
  inflating: gradle-2.7/lib/gradle-base-services-2.7.jar  
  inflating: gradle-2.7/lib/gradle-core-2.7.jar  
  inflating: gradle-2.7/lib/gradle-cli-2.7.jar  
  inflating: gradle-2.7/lib/gradle-ui-2.7.jar  
  inflating: gradle-2.7/lib/gradle-tooling-api-2.7.jar  
  inflating: gradle-2.7/lib/gradle-native-2.7.jar  
  inflating: gradle-2.7/lib/slf4j-api-1.7.10.jar  
  inflating: gradle-2.7/lib/guava-jdk5-17.0.jar  
  inflating: gradle-2.7/lib/commons-lang-2.6.jar  
  inflating: gradle-2.7/lib/groovy-all-2.3.10.jar  
  inflating: gradle-2.7/lib/gradle-model-core-2.7.jar  
  inflating: gradle-2.7/lib/gradle-model-groovy-2.7.jar  
  inflating: gradle-2.7/lib/asm-all-5.0.3.jar  
  inflating: gradle-2.7/lib/ant-1.9.3.jar  
  inflating: gradle-2.7/lib/commons-collections-3.2.1.jar  
  inflating: gradle-2.7/lib/commons-io-1.4.jar  
  inflating: gradle-2.7/lib/jcip-annotations-1.0.jar  
  inflating: gradle-2.7/lib/jul-to-slf4j-1.7.10.jar  
  inflating: gradle-2.7/lib/jarjar-1.3.jar  
  inflating: gradle-2.7/lib/javax.inject-1.jar  
  inflating: gradle-2.7/lib/gradle-base-services-groovy-2.7.jar  
  inflating: gradle-2.7/lib/gradle-messaging-2.7.jar  
  inflating: gradle-2.7/lib/gradle-resources-2.7.jar  
  inflating: gradle-2.7/lib/gradle-docs-2.7.jar  
  inflating: gradle-2.7/lib/log4j-over-slf4j-1.7.10.jar  
  inflating: gradle-2.7/lib/jcl-over-slf4j-1.7.10.jar  
  inflating: gradle-2.7/lib/gradle-open-api-2.7.jar  
  inflating: gradle-2.7/lib/dom4j-1.6.1.jar  
  inflating: gradle-2.7/lib/jaxen-1.1.jar  
  inflating: gradle-2.7/lib/jna-3.2.7.jar  
  inflating: gradle-2.7/lib/native-platform-0.10.jar  
  inflating: gradle-2.7/lib/jansi-1.2.1.jar  
  inflating: gradle-2.7/lib/ant-launcher-1.9.3.jar  
  inflating: gradle-2.7/lib/kryo-2.20.jar  
  inflating: gradle-2.7/lib/native-platform-osx-i386-0.10.jar