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 <zma...@apache.org> 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 <j...@conductant.com> 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 > > > <module> > > > 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 <module> > > > 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 <wfar...@apache.org> > > 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 <wfar...@apache.org> > > 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> >
