Re: [VOTE] Release Apache Aurora 0.11.0 debs

[Jake Farrell]

+1

-Jake

On Wed, Dec 23, 2015 at 12:43 PM, Bill Farner  wrote:

> I propose that we accept the following artifacts as the official deb
> packaging for
> Apache Aurora 0.11.0.
>
>
> http://people.apache.org/~wfarner/aurora/distributions/0.11.0/deb/ubuntu-trusty/
>
> The Aurora deb packaging includes the following:
> ---
> The CHANGELOG is available at:
>
> https://git1-us-west.apache.org/repos/asf?p=aurora-packaging.git;a=blob_plain;f=specs/debian/changelog;hb=refs/heads/0.11.x
>
> The branch used to create the packaging is:
>
> https://git1-us-west.apache.org/repos/asf?p=aurora-packaging.git;a=tree;h=refs/heads/0.11.x
>
> The packages are available at:
>
> http://people.apache.org/~wfarner/aurora/distributions/0.11.0/deb/ubuntu-trusty/
>
> The GPG keys used to sign the packages are available at:
> https://dist.apache.org/repos/dist/release/aurora/KEYS
>
> Please download, verify, and test.
>
> The vote will close on Wed Jan 6 20:00:00 PT 2015
>
> [ ] +1 Release these as the deb packages for Apache Aurora 0.11.0
> [ ] +0
> [ ] -1 Do not release these artifacts because...
>
> I would like to get the voting started off with my own +1
>

Re: [VOTE] Release Apache Aurora 0.11.0 debs

[Bill Farner]

Folks, I respectfully ask that we keep this thread on the topic of the vote
at hand.

PMC members - please vote.  We need to make progress and release packages
for our latest release.

On Friday, January 8, 2016, Jake Farrell  wrote:

> I pushed the api bindings for 0.8 to repository.a.o [1] after a one off
> vote for that specific binary artifact, but we never incorporated that as
> part of our official release process. we need to look into making the
> convenience binaries (deb, rpm, jar) easier to package and assemble for a
> vote at some point
>
> -Jake
>
>
> [1]: https://repository.apache.org/#nexus-search;quick~aurora
>
> On Fri, Jan 8, 2016 at 5:41 AM, Matthias Bach <
> matthias.b...@blue-yonder.com 
> > wrote:
>
> > Hi,
> >
> > Am 27.12.2015 um 00:21 schrieb ben...@gmail.com :
> > > 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.
> >
> > Great work. This are far more advanced than what I have hacked together
> > so far. Especially adding all those man-pages…
> >
> > Is there any particular reason you did not include the Java bindings,
> > though? Or have I just been too blind to find them?
> >
> > Regards,
> > Matthias
> >
> > --
> > Dr. Matthias Bach
> > Senior Software Engineer
> > *Blue Yonder GmbH*
> > Ohiostraße 8
> > D-76149 Karlsruhe
> >
> > Tel +49 (0)721 383 117 6244
> > Fax +49 (0)721 383 117 69
> >
> > matthias.b...@blue-yonder.com   matthias.b...@blue-yonder.com >
> > www.blue-yonder.com 
> > Registergericht Mannheim, HRB 704547
> > USt-IdNr. DE DE 277 091 535
> > Geschäftsführer: Jochen Bossert, Uwe Weiss (CEO)
> >
> > 
> >
>

Re: [VOTE] Release Apache Aurora 0.11.0 debs

[Matthias Bach]

Hi,

Am 27.12.2015 um 00:21 schrieb ben...@gmail.com:
> 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.

Great work. This are far more advanced than what I have hacked together
so far. Especially adding all those man-pages…

Is there any particular reason you did not include the Java bindings,
though? Or have I just been too blind to find them?

Regards,
Matthias

-- 
Dr. Matthias Bach
Senior Software Engineer
*Blue Yonder GmbH*
Ohiostraße 8
D-76149 Karlsruhe

Tel +49 (0)721 383 117 6244
Fax +49 (0)721 383 117 69

matthias.b...@blue-yonder.com 
www.blue-yonder.com 
Registergericht Mannheim, HRB 704547
USt-IdNr. DE DE 277 091 535
Geschäftsführer: Jochen Bossert, Uwe Weiss (CEO)

Re: [VOTE] Release Apache Aurora 0.11.0 debs

[Jake Farrell]

I pushed the api bindings for 0.8 to repository.a.o [1] after a one off
vote for that specific binary artifact, but we never incorporated that as
part of our official release process. we need to look into making the
convenience binaries (deb, rpm, jar) easier to package and assemble for a
vote at some point

-Jake


[1]: https://repository.apache.org/#nexus-search;quick~aurora

On Fri, Jan 8, 2016 at 5:41 AM, Matthias Bach  wrote:

> Hi,
>
> Am 27.12.2015 um 00:21 schrieb ben...@gmail.com:
> > 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.
>
> Great work. This are far more advanced than what I have hacked together
> so far. Especially adding all those man-pages…
>
> Is there any particular reason you did not include the Java bindings,
> though? Or have I just been too blind to find them?
>
> Regards,
> Matthias
>
> --
> Dr. Matthias Bach
> Senior Software Engineer
> *Blue Yonder GmbH*
> Ohiostraße 8
> D-76149 Karlsruhe
>
> Tel +49 (0)721 383 117 6244
> Fax +49 (0)721 383 117 69
>
> matthias.b...@blue-yonder.com 
> www.blue-yonder.com 
> Registergericht Mannheim, HRB 704547
> USt-IdNr. DE DE 277 091 535
> Geschäftsführer: Jochen Bossert, Uwe Weiss (CEO)
>
> 
>

Re: [VOTE] Release Apache Aurora 0.11.0 debs

[Bill Farner]

I'll be posting the requested change for the dependency issue.  As it
stands, we don't have enough binding votes for this release.

Anyone with a binding vote - i'd greatly appreciate your participation.

On Mon, Dec 28, 2015 at 1:54 PM, Mauricio Garavaglia <
mauriciogaravag...@gmail.com> wrote:

> +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 <
> j...@conductant.com>
> > > > > 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.
> > > > > > >
> > > > > >
> > > 

Re: [VOTE] Release Apache Aurora 0.11.0 debs

[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

[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: [VOTE] Release Apache Aurora 0.11.0 debs

[Bill Farner]

+1 to proposing this on the mesos dev list!

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
> > > >>
> > > >> On Wed, Dec 23, 2015 at 9:43 AM, Bill Farner 
> > > wrote:
> > > >>
> > > >> > I propose that we accept the following artifacts as the official
> deb
> > > >> > packaging for
> > > >> > Apache Aurora 0.11.0.
> > > >> >
> > > >> >
> > > >> >
> > > >>
> > >
> >
> http://people.apache.org/~wfarner/aurora/distributions/0.11.0/deb/ubuntu-trusty/
> > > >> >
> > > >> > The Aurora deb packaging includes the 

Re: [VOTE] Release Apache Aurora 0.11.0 debs

[ben...@gmail.com]

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
> > >>
> > >> On Wed, Dec 23, 2015 at 9:43 AM, Bill Farner 
> > wrote:
> > >>
> > >> > I propose that we accept the following artifacts as the official deb
> > >> > packaging for
> > >> > Apache Aurora 0.11.0.
> > >> >
> > >> >
> > >> >
> > >>
> >
> http://people.apache.org/~wfarner/aurora/distributions/0.11.0/deb/ubuntu-trusty/
> > >> >
> > >> > The Aurora deb packaging includes the following:
> > >> > ---
> > >> > The CHANGELOG is available at:
> > >> >
> > >> >
> > >>
> >
> https://git1-us-west.apache.org/repos/asf?p=aurora-packaging.git;a=blob_plain;f=specs/debian/changelog;hb=refs/heads/0.11.x
> > >> >
> > >> > The branch used to create the packaging is:
> > >> >
> > >> >
> > >>
> >
> 

Re: [VOTE] Release Apache Aurora 0.11.0 debs

[Bill Farner]

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

On Wed, Dec 23, 2015 at 9:43 AM, Bill Farner  wrote:

> I propose that we accept the following artifacts as the official deb
> packaging for
> Apache Aurora 0.11.0.
>
>
> http://people.apache.org/~wfarner/aurora/distributions/0.11.0/deb/ubuntu-trusty/
>
> The Aurora deb packaging includes the following:
> ---
> The CHANGELOG is available at:
>
> https://git1-us-west.apache.org/repos/asf?p=aurora-packaging.git;a=blob_plain;f=specs/debian/changelog;hb=refs/heads/0.11.x
>
> The branch used to create the packaging is:
>
> https://git1-us-west.apache.org/repos/asf?p=aurora-packaging.git;a=tree;h=refs/heads/0.11.x
>
> The packages are available at:
>
> http://people.apache.org/~wfarner/aurora/distributions/0.11.0/deb/ubuntu-trusty/
>
> The GPG keys used to sign the packages are available at:
> https://dist.apache.org/repos/dist/release/aurora/KEYS
>
> Please download, verify, and test.
>
> The vote will close on Wed Jan 6 20:00:00 PT 2015
>
> [ ] +1 Release these as the deb packages for Apache Aurora 0.11.0
> [ ] +0
> [ ] -1 Do not release these artifacts because...
>
> I would like to get the voting started off with my own +1
>

[VOTE] Release Apache Aurora 0.11.0 debs

[Bill Farner]

I propose that we accept the following artifacts as the official deb
packaging for
Apache Aurora 0.11.0.

http://people.apache.org/~wfarner/aurora/distributions/0.11.0/deb/ubuntu-trusty/

The Aurora deb packaging includes the following:
---
The CHANGELOG is available at:
https://git1-us-west.apache.org/repos/asf?p=aurora-packaging.git;a=blob_plain;f=specs/debian/changelog;hb=refs/heads/0.11.x

The branch used to create the packaging is:
https://git1-us-west.apache.org/repos/asf?p=aurora-packaging.git;a=tree;h=refs/heads/0.11.x

The packages are available at:
http://people.apache.org/~wfarner/aurora/distributions/0.11.0/deb/ubuntu-trusty/

The GPG keys used to sign the packages are available at:
https://dist.apache.org/repos/dist/release/aurora/KEYS

Please download, verify, and test.

The vote will close on Wed Jan 6 20:00:00 PT 2015

[ ] +1 Release these as the deb packages for Apache Aurora 0.11.0
[ ] +0
[ ] -1 Do not release these artifacts because...

I would like to get the voting started off with my own +1

Re: [VOTE] Release Apache Aurora 0.11.0 debs

[Zameer Manji]

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
> >>
> >> On Wed, Dec 23, 2015 at 9:43 AM, Bill Farner 
> wrote:
> >>
> >> > I propose that we accept the following artifacts as the official deb
> >> > packaging for
> >> > Apache Aurora 0.11.0.
> >> >
> >> >
> >> >
> >>
> http://people.apache.org/~wfarner/aurora/distributions/0.11.0/deb/ubuntu-trusty/
> >> >
> >> > The Aurora deb packaging includes the following:
> >> > ---
> >> > The CHANGELOG is available at:
> >> >
> >> >
> >>
> https://git1-us-west.apache.org/repos/asf?p=aurora-packaging.git;a=blob_plain;f=specs/debian/changelog;hb=refs/heads/0.11.x
> >> >
> >> > The branch used to create the packaging is:
> >> >
> >> >
> >>
> https://git1-us-west.apache.org/repos/asf?p=aurora-packaging.git;a=tree;h=refs/heads/0.11.x
> >> >
> >> > The packages are available at:
> >> >
> >> >
> >>
> http://people.apache.org/~wfarner/aurora/distributions/0.11.0/deb/ubuntu-trusty/
> >> >
> >> > The GPG keys used to sign the packages are available at:
> >> > https://dist.apache.org/repos/dist/release/aurora/KEYS
> >> >
> >> > Please download, verify, and test.
> >> >
> >> > The vote will close on Wed Jan 6 20:00:00 PT 2015
> >> >
> >> > [ ] +1 Release these as the deb packages for Apache Aurora 0.11.0
> >> > [ ] +0
> >> > [ ] -1 Do not release these artifacts because...
> >> >
> >> > I would like to get the voting started off with my own +1
> >> >
> >>
> >
> >
> >
> > --
> > John Sirois
> > 303-512-3301
> >
>
>
>
> --
> John Sirois
> 303-512-3301
>
> --
> Zameer Manji
>
> <303-512-3301>