Re: CouchDB 2.0 as Snap

[Michael Hall]

t;>>>>>> On 09/19/2016 12:10 PM, Jan Lehnardt wrote:
>>>>>>> Heya, nice effort here :)
>>>>>>>
>>>>>>> CouchDB 2.0 doesn’t use autotools. It mimics them minimally, but only
>>>>>>> insofar as it is useful for CouchDB and not for tools that expect
>>>>>>> autotools-like behaviour.
>>>>>>>
>>>>>>> Over time, we want to make it so that the CouchDB install procedure
>>>>>>> fits right into normal tooling, but we are not there yet.
>>>>>>>
>>>>>>> Especially, `make install` is not available in 2.0. Instead, we
>>>>>>> have `make release` which produces a location independent directory
>>>>>>> `./rel/couchdb` that you can move into your system where you need it.
>>>>>>>
>>>>>>> There is no way to externalise log files or so from a setup perspective
>>>>>>> (although it can be configured in local.ini).
>>>>>>>
>>>>>>> HTH
>>>>>>>
>>>>>>> Best
>>>>>>> Jan
>>>>>>> --
>>>>>>>
>>>>>>>> On 19 Sep 2016, at 17:48, Michael Hall <mhall...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> I have attached the snapcraft.yaml file I've started. This is used by
>>>>>>>> the snapcraft tool to build and package a .snap file (just run
>>>>>>>> `snapcraft snap` in the same directory as this file).
>>>>>>>>
>>>>>>>> You can see that most of it is dedicated to grabbing the source,
>>>>>>>> specifying build dependencies (build-packages) and runtime dependencies
>>>>>>>> (stage-packages). The 'autotools' plugin will run the standard
>>>>>>>> "./configure; make; make install" steps on the source, and while the
>>>>>>>> output of those claims to be successful, make returns with a non-zero
>>>>>>>> status code ($?=2) which causes snapcraft to abort after building.
>>>>>>>>
>>>>>>>> As mentioned previously, this could be significantly simplified if it
>>>>>>>> could use the build processes already in place. In that case the
>>>>>>>> snapcraft.yaml would only need to be pointed to the local directory
>>>>>>>> containing the binary files needed to include in the .snap package. If
>>>>>>>> somebody wants to give that a try, I can put together a new
>>>>>>>> snapcraft.yaml that will do that.
>>>>>>>>
>>>>>>>>
>>>>>>>> Michael Hall
>>>>>>>> mhall...@gmail.com
>>>>>>>>
>>>>>>>>> On 09/19/2016 02:56 AM, Constantin Teodorescu wrote:
>>>>>>>>> It would be nice to have two snap packages:
>>>>>>>>> - CouchDB 2.0 UN-CLUSTERED
>>>>>>>>> - CouchDB 2.0 CLUSTERED VERSION
>>>>>>>>>
>>>>>>>>> That will encourage a lot of "standalone" CouchDB users to upgrade to 
>>>>>>>>> a 2.0
>>>>>>>>> version without the clustering overload stuff, and thus make a big 
>>>>>>>>> pool of
>>>>>>>>> 2.0 testers and bug-reporters!
>>>>>>>>> Teo
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Mon, Sep 19, 2016 at 4:47 AM, Michael Hall <mhall...@gmail.com> 
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> First off, congratulations on the upcoming 2.0 release!
>>>>>>>>>>
>>>>>>>>>> I would love to see this new version available as a Snap package for
>>>>>>>>>> users of Ubuntu 16.04 LTS, since the archive version will be frozen 
>>>>>>>>>> on
>>>>>>>>>> 1.6.0 for the next 5 years of it's lifecycle.
>>>>>>>>>>
>>>>>>>>>> Snaps are self-contained packages that include all of the 
>>>>>>>>>> dependencies
>>>>>>>>>> they need, which lets them run as you (the upstream) intended across 
>>>>>>>>>> new
>>>>>>>>>> releases of Ubuntu, Debian, Arch, and many other distros. They run 
>>>>>>>>>> in a
>>>>>>>>>> sandbox that protects them from changes made to the user's system, 
>>>>>>>>>> but
>>>>>>>>>> with a number of optional interfaces if you need deeper interaction 
>>>>>>>>>> or
>>>>>>>>>> to share data with other apps.
>>>>>>>>>>
>>>>>>>>>> Every snap includes its own file tree, and is run on top of the same
>>>>>>>>>> base image regardless of distro or form factor. This keeps the
>>>>>>>>>> application's own files isolated from other apps and the host 
>>>>>>>>>> system, in
>>>>>>>>>> a read-only filesystem, which makes updating them safe and simple 
>>>>>>>>>> while
>>>>>>>>>> keeping you in control of the whole stack that your application runs 
>>>>>>>>>> on.
>>>>>>>>>> The snappy runtime then provides writable areas for storing both
>>>>>>>>>> versioned and unversioned data, as well as system-wide or per-user 
>>>>>>>>>> data.
>>>>>>>>>>
>>>>>>>>>> We also provide a Snap Store, which combines the speed of
>>>>>>>>>> self-publishing with the discoverability of a central archive. It is
>>>>>>>>>> used by default across all Ubuntu 16.04 flavors and derivatives, and 
>>>>>>>>>> any
>>>>>>>>>> distro where snaps have been enabled. Thanks to Snap's confinement,
>>>>>>>>>> applications can be published immediately after uploading. This means
>>>>>>>>>> that your application and updates are available to tens of millions 
>>>>>>>>>> of
>>>>>>>>>> users as soon as you press the button.
>>>>>>>>>>
>>>>>>>>>> I started the work on producing a Snap package for Couchdb 2.0, but 
>>>>>>>>>> as I
>>>>>>>>>> couldn't find a binary release I had to try building it from source 
>>>>>>>>>> and
>>>>>>>>>> unfortunately I was not successful on that step. I am happy to share 
>>>>>>>>>> my
>>>>>>>>>> packaging configuration with anybody here who knows the build process
>>>>>>>>>> better than me, but it would be even simpler to create the snap 
>>>>>>>>>> package
>>>>>>>>>> at the end of whatever process you already have to build binary
>>>>>>>>>> releases. I am happy to help with either or both approaches, and you 
>>>>>>>>>> can
>>>>>>>>>> also learn more about the snap format and tools here: 
>>>>>>>>>> http://snapcraft.io/
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Michael Hall
>>>>>>>>>> mhall...@gmail.com
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> 
>>>>>>>
>>>>>
>>>> 
>>>
>> 
> 

Re: CouchDB 2.0 as Snap

[Michael Hall]

gt;> Michael Hall
>>>>>> mhall...@gmail.com
>>>>>>
>>>>>>> On 09/19/2016 12:10 PM, Jan Lehnardt wrote:
>>>>>>> Heya, nice effort here :)
>>>>>>>
>>>>>>> CouchDB 2.0 doesn’t use autotools. It mimics them minimally, but only
>>>>>>> insofar as it is useful for CouchDB and not for tools that expect
>>>>>>> autotools-like behaviour.
>>>>>>>
>>>>>>> Over time, we want to make it so that the CouchDB install procedure
>>>>>>> fits right into normal tooling, but we are not there yet.
>>>>>>>
>>>>>>> Especially, `make install` is not available in 2.0. Instead, we
>>>>>>> have `make release` which produces a location independent directory
>>>>>>> `./rel/couchdb` that you can move into your system where you need it.
>>>>>>>
>>>>>>> There is no way to externalise log files or so from a setup perspective
>>>>>>> (although it can be configured in local.ini).
>>>>>>>
>>>>>>> HTH
>>>>>>>
>>>>>>> Best
>>>>>>> Jan
>>>>>>> --
>>>>>>>
>>>>>>>> On 19 Sep 2016, at 17:48, Michael Hall <mhall...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> I have attached the snapcraft.yaml file I've started. This is used by
>>>>>>>> the snapcraft tool to build and package a .snap file (just run
>>>>>>>> `snapcraft snap` in the same directory as this file).
>>>>>>>>
>>>>>>>> You can see that most of it is dedicated to grabbing the source,
>>>>>>>> specifying build dependencies (build-packages) and runtime dependencies
>>>>>>>> (stage-packages). The 'autotools' plugin will run the standard
>>>>>>>> "./configure; make; make install" steps on the source, and while the
>>>>>>>> output of those claims to be successful, make returns with a non-zero
>>>>>>>> status code ($?=2) which causes snapcraft to abort after building.
>>>>>>>>
>>>>>>>> As mentioned previously, this could be significantly simplified if it
>>>>>>>> could use the build processes already in place. In that case the
>>>>>>>> snapcraft.yaml would only need to be pointed to the local directory
>>>>>>>> containing the binary files needed to include in the .snap package. If
>>>>>>>> somebody wants to give that a try, I can put together a new
>>>>>>>> snapcraft.yaml that will do that.
>>>>>>>>
>>>>>>>>
>>>>>>>> Michael Hall
>>>>>>>> mhall...@gmail.com
>>>>>>>>
>>>>>>>>> On 09/19/2016 02:56 AM, Constantin Teodorescu wrote:
>>>>>>>>> It would be nice to have two snap packages:
>>>>>>>>> - CouchDB 2.0 UN-CLUSTERED
>>>>>>>>> - CouchDB 2.0 CLUSTERED VERSION
>>>>>>>>>
>>>>>>>>> That will encourage a lot of "standalone" CouchDB users to upgrade to 
>>>>>>>>> a 2.0
>>>>>>>>> version without the clustering overload stuff, and thus make a big 
>>>>>>>>> pool of
>>>>>>>>> 2.0 testers and bug-reporters!
>>>>>>>>> Teo
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Mon, Sep 19, 2016 at 4:47 AM, Michael Hall <mhall...@gmail.com> 
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> First off, congratulations on the upcoming 2.0 release!
>>>>>>>>>>
>>>>>>>>>> I would love to see this new version available as a Snap package for
>>>>>>>>>> users of Ubuntu 16.04 LTS, since the archive version will be frozen 
>>>>>>>>>> on
>>>>>>>>>> 1.6.0 for the next 5 years of it's lifecycle.
>>>>>>>>>>
>>>>>>>>>> Snaps are self-contained packages that include all of the 
>>>>>>>>>> dependencies
>>>>>>>>>> they need, which lets them run as you (the upstream) intended across 
>>>>>>>>>> new
>>>>>>>>>> releases of Ubuntu, Debian, Arch, and many other distros. They run 
>>>>>>>>>> in a
>>>>>>>>>> sandbox that protects them from changes made to the user's system, 
>>>>>>>>>> but
>>>>>>>>>> with a number of optional interfaces if you need deeper interaction 
>>>>>>>>>> or
>>>>>>>>>> to share data with other apps.
>>>>>>>>>>
>>>>>>>>>> Every snap includes its own file tree, and is run on top of the same
>>>>>>>>>> base image regardless of distro or form factor. This keeps the
>>>>>>>>>> application's own files isolated from other apps and the host 
>>>>>>>>>> system, in
>>>>>>>>>> a read-only filesystem, which makes updating them safe and simple 
>>>>>>>>>> while
>>>>>>>>>> keeping you in control of the whole stack that your application runs 
>>>>>>>>>> on.
>>>>>>>>>> The snappy runtime then provides writable areas for storing both
>>>>>>>>>> versioned and unversioned data, as well as system-wide or per-user 
>>>>>>>>>> data.
>>>>>>>>>>
>>>>>>>>>> We also provide a Snap Store, which combines the speed of
>>>>>>>>>> self-publishing with the discoverability of a central archive. It is
>>>>>>>>>> used by default across all Ubuntu 16.04 flavors and derivatives, and 
>>>>>>>>>> any
>>>>>>>>>> distro where snaps have been enabled. Thanks to Snap's confinement,
>>>>>>>>>> applications can be published immediately after uploading. This means
>>>>>>>>>> that your application and updates are available to tens of millions 
>>>>>>>>>> of
>>>>>>>>>> users as soon as you press the button.
>>>>>>>>>>
>>>>>>>>>> I started the work on producing a Snap package for Couchdb 2.0, but 
>>>>>>>>>> as I
>>>>>>>>>> couldn't find a binary release I had to try building it from source 
>>>>>>>>>> and
>>>>>>>>>> unfortunately I was not successful on that step. I am happy to share 
>>>>>>>>>> my
>>>>>>>>>> packaging configuration with anybody here who knows the build process
>>>>>>>>>> better than me, but it would be even simpler to create the snap 
>>>>>>>>>> package
>>>>>>>>>> at the end of whatever process you already have to build binary
>>>>>>>>>> releases. I am happy to help with either or both approaches, and you 
>>>>>>>>>> can
>>>>>>>>>> also learn more about the snap format and tools here: 
>>>>>>>>>> http://snapcraft.io/
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Michael Hall
>>>>>>>>>> mhall...@gmail.com
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> 
>>>>>>>
>>>>>
>>>> 
>>>
>> 
> 

Re: CouchDB 2.0 as Snap

[Adam Kocoloski]

;>>> Especially, `make install` is not available in 2.0. Instead, we
>>>>>> have `make release` which produces a location independent directory
>>>>>> `./rel/couchdb` that you can move into your system where you need it.
>>>>>> 
>>>>>> There is no way to externalise log files or so from a setup perspective
>>>>>> (although it can be configured in local.ini).
>>>>>> 
>>>>>> HTH
>>>>>> 
>>>>>> Best
>>>>>> Jan
>>>>>> --
>>>>>> 
>>>>>>> On 19 Sep 2016, at 17:48, Michael Hall <mhall...@gmail.com> wrote:
>>>>>>> 
>>>>>>> I have attached the snapcraft.yaml file I've started. This is used by
>>>>>>> the snapcraft tool to build and package a .snap file (just run
>>>>>>> `snapcraft snap` in the same directory as this file).
>>>>>>> 
>>>>>>> You can see that most of it is dedicated to grabbing the source,
>>>>>>> specifying build dependencies (build-packages) and runtime dependencies
>>>>>>> (stage-packages). The 'autotools' plugin will run the standard
>>>>>>> "./configure; make; make install" steps on the source, and while the
>>>>>>> output of those claims to be successful, make returns with a non-zero
>>>>>>> status code ($?=2) which causes snapcraft to abort after building.
>>>>>>> 
>>>>>>> As mentioned previously, this could be significantly simplified if it
>>>>>>> could use the build processes already in place. In that case the
>>>>>>> snapcraft.yaml would only need to be pointed to the local directory
>>>>>>> containing the binary files needed to include in the .snap package. If
>>>>>>> somebody wants to give that a try, I can put together a new
>>>>>>> snapcraft.yaml that will do that.
>>>>>>> 
>>>>>>> 
>>>>>>> Michael Hall
>>>>>>> mhall...@gmail.com
>>>>>>> 
>>>>>>>> On 09/19/2016 02:56 AM, Constantin Teodorescu wrote:
>>>>>>>> It would be nice to have two snap packages:
>>>>>>>> - CouchDB 2.0 UN-CLUSTERED
>>>>>>>> - CouchDB 2.0 CLUSTERED VERSION
>>>>>>>> 
>>>>>>>> That will encourage a lot of "standalone" CouchDB users to upgrade to 
>>>>>>>> a 2.0
>>>>>>>> version without the clustering overload stuff, and thus make a big 
>>>>>>>> pool of
>>>>>>>> 2.0 testers and bug-reporters!
>>>>>>>> Teo
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Mon, Sep 19, 2016 at 4:47 AM, Michael Hall <mhall...@gmail.com> 
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> First off, congratulations on the upcoming 2.0 release!
>>>>>>>>> 
>>>>>>>>> I would love to see this new version available as a Snap package for
>>>>>>>>> users of Ubuntu 16.04 LTS, since the archive version will be frozen on
>>>>>>>>> 1.6.0 for the next 5 years of it's lifecycle.
>>>>>>>>> 
>>>>>>>>> Snaps are self-contained packages that include all of the dependencies
>>>>>>>>> they need, which lets them run as you (the upstream) intended across 
>>>>>>>>> new
>>>>>>>>> releases of Ubuntu, Debian, Arch, and many other distros. They run in 
>>>>>>>>> a
>>>>>>>>> sandbox that protects them from changes made to the user's system, but
>>>>>>>>> with a number of optional interfaces if you need deeper interaction or
>>>>>>>>> to share data with other apps.
>>>>>>>>> 
>>>>>>>>> Every snap includes its own file tree, and is run on top of the same
>>>>>>>>> base image regardless of distro or form factor. This keeps the
>>>>>>>>> application's own files isolated from other apps and the host system, 
>>>>>>>>> in
>>>>>>>>> a read-only filesystem, which makes updating them safe and simple 
>>>>>>>>> while
>>>>>>>>> keeping you in control of the whole stack that your application runs 
>>>>>>>>> on.
>>>>>>>>> The snappy runtime then provides writable areas for storing both
>>>>>>>>> versioned and unversioned data, as well as system-wide or per-user 
>>>>>>>>> data.
>>>>>>>>> 
>>>>>>>>> We also provide a Snap Store, which combines the speed of
>>>>>>>>> self-publishing with the discoverability of a central archive. It is
>>>>>>>>> used by default across all Ubuntu 16.04 flavors and derivatives, and 
>>>>>>>>> any
>>>>>>>>> distro where snaps have been enabled. Thanks to Snap's confinement,
>>>>>>>>> applications can be published immediately after uploading. This means
>>>>>>>>> that your application and updates are available to tens of millions of
>>>>>>>>> users as soon as you press the button.
>>>>>>>>> 
>>>>>>>>> I started the work on producing a Snap package for Couchdb 2.0, but 
>>>>>>>>> as I
>>>>>>>>> couldn't find a binary release I had to try building it from source 
>>>>>>>>> and
>>>>>>>>> unfortunately I was not successful on that step. I am happy to share 
>>>>>>>>> my
>>>>>>>>> packaging configuration with anybody here who knows the build process
>>>>>>>>> better than me, but it would be even simpler to create the snap 
>>>>>>>>> package
>>>>>>>>> at the end of whatever process you already have to build binary
>>>>>>>>> releases. I am happy to help with either or both approaches, and you 
>>>>>>>>> can
>>>>>>>>> also learn more about the snap format and tools here: 
>>>>>>>>> http://snapcraft.io/
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Michael Hall
>>>>>>>>> mhall...@gmail.com
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>>> 
>> 
> 

Re: CouchDB 2.0 as Snap

[Michael Hall]

>>> the snapcraft tool to build and package a .snap file (just run
>>>>>> `snapcraft snap` in the same directory as this file).
>>>>>>
>>>>>> You can see that most of it is dedicated to grabbing the source,
>>>>>> specifying build dependencies (build-packages) and runtime dependencies
>>>>>> (stage-packages). The 'autotools' plugin will run the standard
>>>>>> "./configure; make; make install" steps on the source, and while the
>>>>>> output of those claims to be successful, make returns with a non-zero
>>>>>> status code ($?=2) which causes snapcraft to abort after building.
>>>>>>
>>>>>> As mentioned previously, this could be significantly simplified if it
>>>>>> could use the build processes already in place. In that case the
>>>>>> snapcraft.yaml would only need to be pointed to the local directory
>>>>>> containing the binary files needed to include in the .snap package. If
>>>>>> somebody wants to give that a try, I can put together a new
>>>>>> snapcraft.yaml that will do that.
>>>>>>
>>>>>>
>>>>>> Michael Hall
>>>>>> mhall...@gmail.com
>>>>>>
>>>>>>> On 09/19/2016 02:56 AM, Constantin Teodorescu wrote:
>>>>>>> It would be nice to have two snap packages:
>>>>>>> - CouchDB 2.0 UN-CLUSTERED
>>>>>>> - CouchDB 2.0 CLUSTERED VERSION
>>>>>>>
>>>>>>> That will encourage a lot of "standalone" CouchDB users to upgrade to a 
>>>>>>> 2.0
>>>>>>> version without the clustering overload stuff, and thus make a big pool 
>>>>>>> of
>>>>>>> 2.0 testers and bug-reporters!
>>>>>>> Teo
>>>>>>>
>>>>>>>
>>>>>>>> On Mon, Sep 19, 2016 at 4:47 AM, Michael Hall <mhall...@gmail.com> 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> First off, congratulations on the upcoming 2.0 release!
>>>>>>>>
>>>>>>>> I would love to see this new version available as a Snap package for
>>>>>>>> users of Ubuntu 16.04 LTS, since the archive version will be frozen on
>>>>>>>> 1.6.0 for the next 5 years of it's lifecycle.
>>>>>>>>
>>>>>>>> Snaps are self-contained packages that include all of the dependencies
>>>>>>>> they need, which lets them run as you (the upstream) intended across 
>>>>>>>> new
>>>>>>>> releases of Ubuntu, Debian, Arch, and many other distros. They run in a
>>>>>>>> sandbox that protects them from changes made to the user's system, but
>>>>>>>> with a number of optional interfaces if you need deeper interaction or
>>>>>>>> to share data with other apps.
>>>>>>>>
>>>>>>>> Every snap includes its own file tree, and is run on top of the same
>>>>>>>> base image regardless of distro or form factor. This keeps the
>>>>>>>> application's own files isolated from other apps and the host system, 
>>>>>>>> in
>>>>>>>> a read-only filesystem, which makes updating them safe and simple while
>>>>>>>> keeping you in control of the whole stack that your application runs 
>>>>>>>> on.
>>>>>>>> The snappy runtime then provides writable areas for storing both
>>>>>>>> versioned and unversioned data, as well as system-wide or per-user 
>>>>>>>> data.
>>>>>>>>
>>>>>>>> We also provide a Snap Store, which combines the speed of
>>>>>>>> self-publishing with the discoverability of a central archive. It is
>>>>>>>> used by default across all Ubuntu 16.04 flavors and derivatives, and 
>>>>>>>> any
>>>>>>>> distro where snaps have been enabled. Thanks to Snap's confinement,
>>>>>>>> applications can be published immediately after uploading. This means
>>>>>>>> that your application and updates are available to tens of millions of
>>>>>>>> users as soon as you press the button.
>>>>>>>>
>>>>>>>> I started the work on producing a Snap package for Couchdb 2.0, but as 
>>>>>>>> I
>>>>>>>> couldn't find a binary release I had to try building it from source and
>>>>>>>> unfortunately I was not successful on that step. I am happy to share my
>>>>>>>> packaging configuration with anybody here who knows the build process
>>>>>>>> better than me, but it would be even simpler to create the snap package
>>>>>>>> at the end of whatever process you already have to build binary
>>>>>>>> releases. I am happy to help with either or both approaches, and you 
>>>>>>>> can
>>>>>>>> also learn more about the snap format and tools here: 
>>>>>>>> http://snapcraft.io/
>>>>>>>>
>>>>>>>> --
>>>>>>>> Michael Hall
>>>>>>>> mhall...@gmail.com
>>>>>>>>
>>>>>>>
>>>>>> 
>>>>>
>>>
>> 
> 
; Snap-specific Configuration Settings

[couchdb]
database_dir = /var/snap/couchdb/common/data
view_index_dir = /var/snap/couchdb/common/data

[chttpd]
;port = 5984
bind_address = 0.0.0.0

[httpd]
;port = 5986
bind_address = 0.0.0.0

[log]
writer = file
file = /var/snap/couchdb/current/couchdb.log
;level = info


snapcraft.yaml
Description: application/yaml
#!/bin/sh

export HOME=$SNAP_DATA
export ERL_FLAGS="-couch_ini ${SNAP}/couchdb/etc/default.ini 
${SNAP}/couchdb/etc/snap.ini ${SNAP_DATA}/local.ini"
if [ ! -e ${SNAP_DATA}/local.ini ]; then
touch ${SNAP_DATA}/local.ini
fi

exec ${SNAP}/couchdb/bin/couchdb

Re: CouchDB 2.0 as Snap

[Robert Kowalski]

wow thats super cool!

thank you!

On Mon, Sep 19, 2016 at 11:47 PM, Michael Hall <mhall...@gmail.com> wrote:

> Thanks to help from Jan and Wohali on IRC, I was able to manually build
> couchdb from the 2.0.x branch, and then snap-package the resulting
> binary. I have attached the snapcraft.yaml used for this. Put this file
> in a directory with the couchdb directory built in ./rel/, then run
> "snapcraft snap" to build couchdb_2.0_amd64.snap
>
> The snap package will create a systemd service file for running couchdb
> as a daemon, but due to the way it launches a background epmd process
> this isn't working right (systemd thinks it failed to start and keeps
> trying to restart it until it givesup). Because of that, I've also
> included a /snap/bin/couchdb.run which will manually kick it off, but
> this should only be temporary until the daemon process can be fixed.
>
> One last caveat, you'll need to copy /snap/couchdb/current/etc/*.ini
> into /var/snap/couchdb/current/ and mkdir /var/snap/couchdb/current/data
> before running it. This could be done at runtime either by couchdb
> itself, or with a custom wrapper script for the snap command.
>
> Michael Hall
> mhall...@gmail.com
>
> On 09/19/2016 01:19 PM, Jan Lehnardt wrote:
> >
> >> On 19 Sep 2016, at 19:13, Michael Hall <mhall...@gmail.com> wrote:
> >>
> >> Maybe I'm using the wrong branch, because the Makefile has an "install"
> >> target but not a "release" target. I'm using developer-preview-2.0, if
> >> that's not the correct one, which should I use?
> >
> > Please use the `2.0.x` branch.
> >
> > Best
> > Jan
> > --
> >
> >>
> >> Michael Hall
> >> mhall...@gmail.com
> >>
> >> On 09/19/2016 12:10 PM, Jan Lehnardt wrote:
> >>> Heya, nice effort here :)
> >>>
> >>> CouchDB 2.0 doesn’t use autotools. It mimics them minimally, but only
> >>> insofar as it is useful for CouchDB and not for tools that expect
> >>> autotools-like behaviour.
> >>>
> >>> Over time, we want to make it so that the CouchDB install procedure
> >>> fits right into normal tooling, but we are not there yet.
> >>>
> >>> Especially, `make install` is not available in 2.0. Instead, we
> >>> have `make release` which produces a location independent directory
> >>> `./rel/couchdb` that you can move into your system where you need it.
> >>>
> >>> There is no way to externalise log files or so from a setup perspective
> >>> (although it can be configured in local.ini).
> >>>
> >>> HTH
> >>>
> >>> Best
> >>> Jan
> >>> --
> >>>
> >>>> On 19 Sep 2016, at 17:48, Michael Hall <mhall...@gmail.com> wrote:
> >>>>
> >>>> I have attached the snapcraft.yaml file I've started. This is used by
> >>>> the snapcraft tool to build and package a .snap file (just run
> >>>> `snapcraft snap` in the same directory as this file).
> >>>>
> >>>> You can see that most of it is dedicated to grabbing the source,
> >>>> specifying build dependencies (build-packages) and runtime
> dependencies
> >>>> (stage-packages). The 'autotools' plugin will run the standard
> >>>> "./configure; make; make install" steps on the source, and while the
> >>>> output of those claims to be successful, make returns with a non-zero
> >>>> status code ($?=2) which causes snapcraft to abort after building.
> >>>>
> >>>> As mentioned previously, this could be significantly simplified if it
> >>>> could use the build processes already in place. In that case the
> >>>> snapcraft.yaml would only need to be pointed to the local directory
> >>>> containing the binary files needed to include in the .snap package. If
> >>>> somebody wants to give that a try, I can put together a new
> >>>> snapcraft.yaml that will do that.
> >>>>
> >>>>
> >>>> Michael Hall
> >>>> mhall...@gmail.com
> >>>>
> >>>> On 09/19/2016 02:56 AM, Constantin Teodorescu wrote:
> >>>>> It would be nice to have two snap packages:
> >>>>> - CouchDB 2.0 UN-CLUSTERED
> >>>>> - CouchDB 2.0 CLUSTERED VERSION
> >>>>>
> >>>>> That will encourage a lot of "standalone" CouchDB users to upgrade

Re: CouchDB 2.0 as Snap

[Dave Cottlehuber]

> However at present they have a serious limitation wrt storage that is a
> production showstopper - each snap version creates a new copy of
> couchdb, and copies across the data files. I can't confirm yet if this

BTW damjan on IRC pointed out SNAP_COMMON: writable area persistent
across all revisions of the snap at
http://snapcraft.io/docs/reference/env  which if suitable would be
great.

A+
Dave

Re: CouchDB 2.0 as Snap

[Dave Cottlehuber]

> >>> On Mon, Sep 19, 2016 at 4:47 AM, Michael Hall  
> >>> wrote:
> >>> 
> >>> First off, congratulations on the upcoming 2.0 release!
> >>> 
> >>> I would love to see this new version available as a Snap package for
> >>> users of Ubuntu 16.04 LTS, since the archive version will be frozen on

Thanks Michael,

These sound awesome. Snaps are looking great -- especially compared to
the frustration of older debian / centos packaging tools that carry 2
decades of cruft under the hood.

However at present they have a serious limitation wrt storage that is a
production showstopper - each snap version creates a new copy of
couchdb, and copies across the data files. I can't confirm yet if this
is copy-on-write or not which at least would not be (initially) too bad,
or a naive copy that duplicate disk blocks entirely. I suspect the
latter as there is not much choice when it comes to cross-filesystem
compatibility. Either way, if you have reasonably sized couches & viewed
snaps will put you in a situation of needing to clean up old data to
avoid running out of free disk space (e.g. during compaction) due to
data kept in old snaps.

We're not the only database to experience this constraint however and
I'm sure a suitable solution will appear in due course. Go snaps!

A+
Dave

Re: CouchDB 2.0 as Snap

[Robert Newson]

Make a separate systemd service for epmd and have the couch one depend on it. 
There is a parameter you can add to couch's vm.args file to prevent it even 
trying to start epmd. 

Sent from my iPhone

> On 19 Sep 2016, at 22:47, Michael Hall <mhall...@gmail.com> wrote:
> 
> Thanks to help from Jan and Wohali on IRC, I was able to manually build
> couchdb from the 2.0.x branch, and then snap-package the resulting
> binary. I have attached the snapcraft.yaml used for this. Put this file
> in a directory with the couchdb directory built in ./rel/, then run
> "snapcraft snap" to build couchdb_2.0_amd64.snap
> 
> The snap package will create a systemd service file for running couchdb
> as a daemon, but due to the way it launches a background epmd process
> this isn't working right (systemd thinks it failed to start and keeps
> trying to restart it until it givesup). Because of that, I've also
> included a /snap/bin/couchdb.run which will manually kick it off, but
> this should only be temporary until the daemon process can be fixed.
> 
> One last caveat, you'll need to copy /snap/couchdb/current/etc/*.ini
> into /var/snap/couchdb/current/ and mkdir /var/snap/couchdb/current/data
> before running it. This could be done at runtime either by couchdb
> itself, or with a custom wrapper script for the snap command.
> 
> Michael Hall
> mhall...@gmail.com
> 
>> On 09/19/2016 01:19 PM, Jan Lehnardt wrote:
>> 
>>> On 19 Sep 2016, at 19:13, Michael Hall <mhall...@gmail.com> wrote:
>>> 
>>> Maybe I'm using the wrong branch, because the Makefile has an "install"
>>> target but not a "release" target. I'm using developer-preview-2.0, if
>>> that's not the correct one, which should I use?
>> 
>> Please use the `2.0.x` branch.
>> 
>> Best
>> Jan
>> --
>> 
>>> 
>>> Michael Hall
>>> mhall...@gmail.com
>>> 
>>>> On 09/19/2016 12:10 PM, Jan Lehnardt wrote:
>>>> Heya, nice effort here :)
>>>> 
>>>> CouchDB 2.0 doesn’t use autotools. It mimics them minimally, but only
>>>> insofar as it is useful for CouchDB and not for tools that expect
>>>> autotools-like behaviour.
>>>> 
>>>> Over time, we want to make it so that the CouchDB install procedure
>>>> fits right into normal tooling, but we are not there yet.
>>>> 
>>>> Especially, `make install` is not available in 2.0. Instead, we
>>>> have `make release` which produces a location independent directory
>>>> `./rel/couchdb` that you can move into your system where you need it.
>>>> 
>>>> There is no way to externalise log files or so from a setup perspective
>>>> (although it can be configured in local.ini).
>>>> 
>>>> HTH
>>>> 
>>>> Best
>>>> Jan
>>>> --
>>>> 
>>>>> On 19 Sep 2016, at 17:48, Michael Hall <mhall...@gmail.com> wrote:
>>>>> 
>>>>> I have attached the snapcraft.yaml file I've started. This is used by
>>>>> the snapcraft tool to build and package a .snap file (just run
>>>>> `snapcraft snap` in the same directory as this file).
>>>>> 
>>>>> You can see that most of it is dedicated to grabbing the source,
>>>>> specifying build dependencies (build-packages) and runtime dependencies
>>>>> (stage-packages). The 'autotools' plugin will run the standard
>>>>> "./configure; make; make install" steps on the source, and while the
>>>>> output of those claims to be successful, make returns with a non-zero
>>>>> status code ($?=2) which causes snapcraft to abort after building.
>>>>> 
>>>>> As mentioned previously, this could be significantly simplified if it
>>>>> could use the build processes already in place. In that case the
>>>>> snapcraft.yaml would only need to be pointed to the local directory
>>>>> containing the binary files needed to include in the .snap package. If
>>>>> somebody wants to give that a try, I can put together a new
>>>>> snapcraft.yaml that will do that.
>>>>> 
>>>>> 
>>>>> Michael Hall
>>>>> mhall...@gmail.com
>>>>> 
>>>>>> On 09/19/2016 02:56 AM, Constantin Teodorescu wrote:
>>>>>> It would be nice to have two snap packages:
>>>>>> - CouchDB 2.0 UN-CLUSTERED
>>>>>> - CouchDB 2.0 CLUSTER

Re: CouchDB 2.0 as Snap

[Michael Hall]

Thanks to help from Jan and Wohali on IRC, I was able to manually build
couchdb from the 2.0.x branch, and then snap-package the resulting
binary. I have attached the snapcraft.yaml used for this. Put this file
in a directory with the couchdb directory built in ./rel/, then run
"snapcraft snap" to build couchdb_2.0_amd64.snap

The snap package will create a systemd service file for running couchdb
as a daemon, but due to the way it launches a background epmd process
this isn't working right (systemd thinks it failed to start and keeps
trying to restart it until it givesup). Because of that, I've also
included a /snap/bin/couchdb.run which will manually kick it off, but
this should only be temporary until the daemon process can be fixed.

One last caveat, you'll need to copy /snap/couchdb/current/etc/*.ini
into /var/snap/couchdb/current/ and mkdir /var/snap/couchdb/current/data
before running it. This could be done at runtime either by couchdb
itself, or with a custom wrapper script for the snap command.

Michael Hall
mhall...@gmail.com

On 09/19/2016 01:19 PM, Jan Lehnardt wrote:
> 
>> On 19 Sep 2016, at 19:13, Michael Hall <mhall...@gmail.com> wrote:
>>
>> Maybe I'm using the wrong branch, because the Makefile has an "install"
>> target but not a "release" target. I'm using developer-preview-2.0, if
>> that's not the correct one, which should I use?
> 
> Please use the `2.0.x` branch.
> 
> Best
> Jan
> --
> 
>>
>> Michael Hall
>> mhall...@gmail.com
>>
>> On 09/19/2016 12:10 PM, Jan Lehnardt wrote:
>>> Heya, nice effort here :)
>>>
>>> CouchDB 2.0 doesn’t use autotools. It mimics them minimally, but only
>>> insofar as it is useful for CouchDB and not for tools that expect
>>> autotools-like behaviour.
>>>
>>> Over time, we want to make it so that the CouchDB install procedure
>>> fits right into normal tooling, but we are not there yet.
>>>
>>> Especially, `make install` is not available in 2.0. Instead, we
>>> have `make release` which produces a location independent directory
>>> `./rel/couchdb` that you can move into your system where you need it.
>>>
>>> There is no way to externalise log files or so from a setup perspective
>>> (although it can be configured in local.ini).
>>>
>>> HTH
>>>
>>> Best
>>> Jan
>>> --
>>>
>>>> On 19 Sep 2016, at 17:48, Michael Hall <mhall...@gmail.com> wrote:
>>>>
>>>> I have attached the snapcraft.yaml file I've started. This is used by
>>>> the snapcraft tool to build and package a .snap file (just run
>>>> `snapcraft snap` in the same directory as this file).
>>>>
>>>> You can see that most of it is dedicated to grabbing the source,
>>>> specifying build dependencies (build-packages) and runtime dependencies
>>>> (stage-packages). The 'autotools' plugin will run the standard
>>>> "./configure; make; make install" steps on the source, and while the
>>>> output of those claims to be successful, make returns with a non-zero
>>>> status code ($?=2) which causes snapcraft to abort after building.
>>>>
>>>> As mentioned previously, this could be significantly simplified if it
>>>> could use the build processes already in place. In that case the
>>>> snapcraft.yaml would only need to be pointed to the local directory
>>>> containing the binary files needed to include in the .snap package. If
>>>> somebody wants to give that a try, I can put together a new
>>>> snapcraft.yaml that will do that.
>>>>
>>>>
>>>> Michael Hall
>>>> mhall...@gmail.com
>>>>
>>>> On 09/19/2016 02:56 AM, Constantin Teodorescu wrote:
>>>>> It would be nice to have two snap packages:
>>>>> - CouchDB 2.0 UN-CLUSTERED
>>>>> - CouchDB 2.0 CLUSTERED VERSION
>>>>>
>>>>> That will encourage a lot of "standalone" CouchDB users to upgrade to a 
>>>>> 2.0
>>>>> version without the clustering overload stuff, and thus make a big pool of
>>>>> 2.0 testers and bug-reporters!
>>>>> Teo
>>>>>
>>>>>
>>>>> On Mon, Sep 19, 2016 at 4:47 AM, Michael Hall <mhall...@gmail.com> wrote:
>>>>>
>>>>>> First off, congratulations on the upcoming 2.0 release!
>>>>>>
>>>>>> I would love to see this new version available as a Snap package for
>>>

Re: CouchDB 2.0 as Snap

[Jan Lehnardt]

> On 19 Sep 2016, at 19:13, Michael Hall <mhall...@gmail.com> wrote:
> 
> Maybe I'm using the wrong branch, because the Makefile has an "install"
> target but not a "release" target. I'm using developer-preview-2.0, if
> that's not the correct one, which should I use?

Please use the `2.0.x` branch.

Best
Jan
--

> 
> Michael Hall
> mhall...@gmail.com
> 
> On 09/19/2016 12:10 PM, Jan Lehnardt wrote:
>> Heya, nice effort here :)
>> 
>> CouchDB 2.0 doesn’t use autotools. It mimics them minimally, but only
>> insofar as it is useful for CouchDB and not for tools that expect
>> autotools-like behaviour.
>> 
>> Over time, we want to make it so that the CouchDB install procedure
>> fits right into normal tooling, but we are not there yet.
>> 
>> Especially, `make install` is not available in 2.0. Instead, we
>> have `make release` which produces a location independent directory
>> `./rel/couchdb` that you can move into your system where you need it.
>> 
>> There is no way to externalise log files or so from a setup perspective
>> (although it can be configured in local.ini).
>> 
>> HTH
>> 
>> Best
>> Jan
>> --
>> 
>>> On 19 Sep 2016, at 17:48, Michael Hall <mhall...@gmail.com> wrote:
>>> 
>>> I have attached the snapcraft.yaml file I've started. This is used by
>>> the snapcraft tool to build and package a .snap file (just run
>>> `snapcraft snap` in the same directory as this file).
>>> 
>>> You can see that most of it is dedicated to grabbing the source,
>>> specifying build dependencies (build-packages) and runtime dependencies
>>> (stage-packages). The 'autotools' plugin will run the standard
>>> "./configure; make; make install" steps on the source, and while the
>>> output of those claims to be successful, make returns with a non-zero
>>> status code ($?=2) which causes snapcraft to abort after building.
>>> 
>>> As mentioned previously, this could be significantly simplified if it
>>> could use the build processes already in place. In that case the
>>> snapcraft.yaml would only need to be pointed to the local directory
>>> containing the binary files needed to include in the .snap package. If
>>> somebody wants to give that a try, I can put together a new
>>> snapcraft.yaml that will do that.
>>> 
>>> 
>>> Michael Hall
>>> mhall...@gmail.com
>>> 
>>> On 09/19/2016 02:56 AM, Constantin Teodorescu wrote:
>>>> It would be nice to have two snap packages:
>>>> - CouchDB 2.0 UN-CLUSTERED
>>>> - CouchDB 2.0 CLUSTERED VERSION
>>>> 
>>>> That will encourage a lot of "standalone" CouchDB users to upgrade to a 2.0
>>>> version without the clustering overload stuff, and thus make a big pool of
>>>> 2.0 testers and bug-reporters!
>>>> Teo
>>>> 
>>>> 
>>>> On Mon, Sep 19, 2016 at 4:47 AM, Michael Hall <mhall...@gmail.com> wrote:
>>>> 
>>>>> First off, congratulations on the upcoming 2.0 release!
>>>>> 
>>>>> I would love to see this new version available as a Snap package for
>>>>> users of Ubuntu 16.04 LTS, since the archive version will be frozen on
>>>>> 1.6.0 for the next 5 years of it's lifecycle.
>>>>> 
>>>>> Snaps are self-contained packages that include all of the dependencies
>>>>> they need, which lets them run as you (the upstream) intended across new
>>>>> releases of Ubuntu, Debian, Arch, and many other distros. They run in a
>>>>> sandbox that protects them from changes made to the user's system, but
>>>>> with a number of optional interfaces if you need deeper interaction or
>>>>> to share data with other apps.
>>>>> 
>>>>> Every snap includes its own file tree, and is run on top of the same
>>>>> base image regardless of distro or form factor. This keeps the
>>>>> application's own files isolated from other apps and the host system, in
>>>>> a read-only filesystem, which makes updating them safe and simple while
>>>>> keeping you in control of the whole stack that your application runs on.
>>>>> The snappy runtime then provides writable areas for storing both
>>>>> versioned and unversioned data, as well as system-wide or per-user data.
>>>>> 
>>>>> We also provide a Snap Store, which combines the sp

Re: CouchDB 2.0 as Snap

[Michael Hall]

Maybe I'm using the wrong branch, because the Makefile has an "install"
target but not a "release" target. I'm using developer-preview-2.0, if
that's not the correct one, which should I use?

Michael Hall
mhall...@gmail.com

On 09/19/2016 12:10 PM, Jan Lehnardt wrote:
> Heya, nice effort here :)
> 
> CouchDB 2.0 doesn’t use autotools. It mimics them minimally, but only
> insofar as it is useful for CouchDB and not for tools that expect
> autotools-like behaviour.
> 
> Over time, we want to make it so that the CouchDB install procedure
> fits right into normal tooling, but we are not there yet.
> 
> Especially, `make install` is not available in 2.0. Instead, we
> have `make release` which produces a location independent directory
> `./rel/couchdb` that you can move into your system where you need it.
> 
> There is no way to externalise log files or so from a setup perspective
> (although it can be configured in local.ini).
> 
> HTH
> 
> Best
> Jan
> --
> 
>> On 19 Sep 2016, at 17:48, Michael Hall <mhall...@gmail.com> wrote:
>>
>> I have attached the snapcraft.yaml file I've started. This is used by
>> the snapcraft tool to build and package a .snap file (just run
>> `snapcraft snap` in the same directory as this file).
>>
>> You can see that most of it is dedicated to grabbing the source,
>> specifying build dependencies (build-packages) and runtime dependencies
>> (stage-packages). The 'autotools' plugin will run the standard
>> "./configure; make; make install" steps on the source, and while the
>> output of those claims to be successful, make returns with a non-zero
>> status code ($?=2) which causes snapcraft to abort after building.
>>
>> As mentioned previously, this could be significantly simplified if it
>> could use the build processes already in place. In that case the
>> snapcraft.yaml would only need to be pointed to the local directory
>> containing the binary files needed to include in the .snap package. If
>> somebody wants to give that a try, I can put together a new
>> snapcraft.yaml that will do that.
>>
>>
>> Michael Hall
>> mhall...@gmail.com
>>
>> On 09/19/2016 02:56 AM, Constantin Teodorescu wrote:
>>> It would be nice to have two snap packages:
>>> - CouchDB 2.0 UN-CLUSTERED
>>> - CouchDB 2.0 CLUSTERED VERSION
>>>
>>> That will encourage a lot of "standalone" CouchDB users to upgrade to a 2.0
>>> version without the clustering overload stuff, and thus make a big pool of
>>> 2.0 testers and bug-reporters!
>>> Teo
>>>
>>>
>>> On Mon, Sep 19, 2016 at 4:47 AM, Michael Hall <mhall...@gmail.com> wrote:
>>>
>>>> First off, congratulations on the upcoming 2.0 release!
>>>>
>>>> I would love to see this new version available as a Snap package for
>>>> users of Ubuntu 16.04 LTS, since the archive version will be frozen on
>>>> 1.6.0 for the next 5 years of it's lifecycle.
>>>>
>>>> Snaps are self-contained packages that include all of the dependencies
>>>> they need, which lets them run as you (the upstream) intended across new
>>>> releases of Ubuntu, Debian, Arch, and many other distros. They run in a
>>>> sandbox that protects them from changes made to the user's system, but
>>>> with a number of optional interfaces if you need deeper interaction or
>>>> to share data with other apps.
>>>>
>>>> Every snap includes its own file tree, and is run on top of the same
>>>> base image regardless of distro or form factor. This keeps the
>>>> application's own files isolated from other apps and the host system, in
>>>> a read-only filesystem, which makes updating them safe and simple while
>>>> keeping you in control of the whole stack that your application runs on.
>>>> The snappy runtime then provides writable areas for storing both
>>>> versioned and unversioned data, as well as system-wide or per-user data.
>>>>
>>>> We also provide a Snap Store, which combines the speed of
>>>> self-publishing with the discoverability of a central archive. It is
>>>> used by default across all Ubuntu 16.04 flavors and derivatives, and any
>>>> distro where snaps have been enabled. Thanks to Snap's confinement,
>>>> applications can be published immediately after uploading. This means
>>>> that your application and updates are available to tens of millions of
>>>> users as soon as you press the button.
>>>>
>>>> I started the work on producing a Snap package for Couchdb 2.0, but as I
>>>> couldn't find a binary release I had to try building it from source and
>>>> unfortunately I was not successful on that step. I am happy to share my
>>>> packaging configuration with anybody here who knows the build process
>>>> better than me, but it would be even simpler to create the snap package
>>>> at the end of whatever process you already have to build binary
>>>> releases. I am happy to help with either or both approaches, and you can
>>>> also learn more about the snap format and tools here: http://snapcraft.io/
>>>>
>>>> --
>>>> Michael Hall
>>>> mhall...@gmail.com
>>>>
>>>
>> 
> 

Re: CouchDB 2.0 as Snap

[Jan Lehnardt]

Heya, nice effort here :)

CouchDB 2.0 doesn’t use autotools. It mimics them minimally, but only
insofar as it is useful for CouchDB and not for tools that expect
autotools-like behaviour.

Over time, we want to make it so that the CouchDB install procedure
fits right into normal tooling, but we are not there yet.

Especially, `make install` is not available in 2.0. Instead, we
have `make release` which produces a location independent directory
`./rel/couchdb` that you can move into your system where you need it.

There is no way to externalise log files or so from a setup perspective
(although it can be configured in local.ini).

HTH

Best
Jan
--

> On 19 Sep 2016, at 17:48, Michael Hall <mhall...@gmail.com> wrote:
> 
> I have attached the snapcraft.yaml file I've started. This is used by
> the snapcraft tool to build and package a .snap file (just run
> `snapcraft snap` in the same directory as this file).
> 
> You can see that most of it is dedicated to grabbing the source,
> specifying build dependencies (build-packages) and runtime dependencies
> (stage-packages). The 'autotools' plugin will run the standard
> "./configure; make; make install" steps on the source, and while the
> output of those claims to be successful, make returns with a non-zero
> status code ($?=2) which causes snapcraft to abort after building.
> 
> As mentioned previously, this could be significantly simplified if it
> could use the build processes already in place. In that case the
> snapcraft.yaml would only need to be pointed to the local directory
> containing the binary files needed to include in the .snap package. If
> somebody wants to give that a try, I can put together a new
> snapcraft.yaml that will do that.
> 
> 
> Michael Hall
> mhall...@gmail.com
> 
> On 09/19/2016 02:56 AM, Constantin Teodorescu wrote:
>> It would be nice to have two snap packages:
>> - CouchDB 2.0 UN-CLUSTERED
>> - CouchDB 2.0 CLUSTERED VERSION
>> 
>> That will encourage a lot of "standalone" CouchDB users to upgrade to a 2.0
>> version without the clustering overload stuff, and thus make a big pool of
>> 2.0 testers and bug-reporters!
>> Teo
>> 
>> 
>> On Mon, Sep 19, 2016 at 4:47 AM, Michael Hall <mhall...@gmail.com> wrote:
>> 
>>> First off, congratulations on the upcoming 2.0 release!
>>> 
>>> I would love to see this new version available as a Snap package for
>>> users of Ubuntu 16.04 LTS, since the archive version will be frozen on
>>> 1.6.0 for the next 5 years of it's lifecycle.
>>> 
>>> Snaps are self-contained packages that include all of the dependencies
>>> they need, which lets them run as you (the upstream) intended across new
>>> releases of Ubuntu, Debian, Arch, and many other distros. They run in a
>>> sandbox that protects them from changes made to the user's system, but
>>> with a number of optional interfaces if you need deeper interaction or
>>> to share data with other apps.
>>> 
>>> Every snap includes its own file tree, and is run on top of the same
>>> base image regardless of distro or form factor. This keeps the
>>> application's own files isolated from other apps and the host system, in
>>> a read-only filesystem, which makes updating them safe and simple while
>>> keeping you in control of the whole stack that your application runs on.
>>> The snappy runtime then provides writable areas for storing both
>>> versioned and unversioned data, as well as system-wide or per-user data.
>>> 
>>> We also provide a Snap Store, which combines the speed of
>>> self-publishing with the discoverability of a central archive. It is
>>> used by default across all Ubuntu 16.04 flavors and derivatives, and any
>>> distro where snaps have been enabled. Thanks to Snap's confinement,
>>> applications can be published immediately after uploading. This means
>>> that your application and updates are available to tens of millions of
>>> users as soon as you press the button.
>>> 
>>> I started the work on producing a Snap package for Couchdb 2.0, but as I
>>> couldn't find a binary release I had to try building it from source and
>>> unfortunately I was not successful on that step. I am happy to share my
>>> packaging configuration with anybody here who knows the build process
>>> better than me, but it would be even simpler to create the snap package
>>> at the end of whatever process you already have to build binary
>>> releases. I am happy to help with either or both approaches, and you can
>>> also learn more about the snap format and tools here: http://snapcraft.io/
>>> 
>>> --
>>> Michael Hall
>>> mhall...@gmail.com
>>> 
>> 
> 

-- 
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/

Re: CouchDB 2.0 as Snap

[Michael Hall]

I have attached the snapcraft.yaml file I've started. This is used by
the snapcraft tool to build and package a .snap file (just run
`snapcraft snap` in the same directory as this file).

You can see that most of it is dedicated to grabbing the source,
specifying build dependencies (build-packages) and runtime dependencies
(stage-packages). The 'autotools' plugin will run the standard
"./configure; make; make install" steps on the source, and while the
output of those claims to be successful, make returns with a non-zero
status code ($?=2) which causes snapcraft to abort after building.

As mentioned previously, this could be significantly simplified if it
could use the build processes already in place. In that case the
snapcraft.yaml would only need to be pointed to the local directory
containing the binary files needed to include in the .snap package. If
somebody wants to give that a try, I can put together a new
snapcraft.yaml that will do that.


Michael Hall
mhall...@gmail.com

On 09/19/2016 02:56 AM, Constantin Teodorescu wrote:
> It would be nice to have two snap packages:
> - CouchDB 2.0 UN-CLUSTERED
> - CouchDB 2.0 CLUSTERED VERSION
> 
> That will encourage a lot of "standalone" CouchDB users to upgrade to a 2.0
> version without the clustering overload stuff, and thus make a big pool of
> 2.0 testers and bug-reporters!
> Teo
> 
> 
> On Mon, Sep 19, 2016 at 4:47 AM, Michael Hall <mhall...@gmail.com> wrote:
> 
>> First off, congratulations on the upcoming 2.0 release!
>>
>> I would love to see this new version available as a Snap package for
>> users of Ubuntu 16.04 LTS, since the archive version will be frozen on
>> 1.6.0 for the next 5 years of it's lifecycle.
>>
>> Snaps are self-contained packages that include all of the dependencies
>> they need, which lets them run as you (the upstream) intended across new
>> releases of Ubuntu, Debian, Arch, and many other distros. They run in a
>> sandbox that protects them from changes made to the user's system, but
>> with a number of optional interfaces if you need deeper interaction or
>> to share data with other apps.
>>
>> Every snap includes its own file tree, and is run on top of the same
>> base image regardless of distro or form factor. This keeps the
>> application's own files isolated from other apps and the host system, in
>> a read-only filesystem, which makes updating them safe and simple while
>> keeping you in control of the whole stack that your application runs on.
>> The snappy runtime then provides writable areas for storing both
>> versioned and unversioned data, as well as system-wide or per-user data.
>>
>> We also provide a Snap Store, which combines the speed of
>> self-publishing with the discoverability of a central archive. It is
>> used by default across all Ubuntu 16.04 flavors and derivatives, and any
>> distro where snaps have been enabled. Thanks to Snap's confinement,
>> applications can be published immediately after uploading. This means
>> that your application and updates are available to tens of millions of
>> users as soon as you press the button.
>>
>> I started the work on producing a Snap package for Couchdb 2.0, but as I
>> couldn't find a binary release I had to try building it from source and
>> unfortunately I was not successful on that step. I am happy to share my
>> packaging configuration with anybody here who knows the build process
>> better than me, but it would be even simpler to create the snap package
>> at the end of whatever process you already have to build binary
>> releases. I am happy to help with either or both approaches, and you can
>> also learn more about the snap format and tools here: http://snapcraft.io/
>>
>> --
>> Michael Hall
>> mhall...@gmail.com
>>
> 


snapcraft.yaml
Description: application/yaml

Re: CouchDB 2.0 as Snap

[Constantin Teodorescu]

It would be nice to have two snap packages:
- CouchDB 2.0 UN-CLUSTERED
- CouchDB 2.0 CLUSTERED VERSION

That will encourage a lot of "standalone" CouchDB users to upgrade to a 2.0
version without the clustering overload stuff, and thus make a big pool of
2.0 testers and bug-reporters!
Teo


On Mon, Sep 19, 2016 at 4:47 AM, Michael Hall <mhall...@gmail.com> wrote:

> First off, congratulations on the upcoming 2.0 release!
>
> I would love to see this new version available as a Snap package for
> users of Ubuntu 16.04 LTS, since the archive version will be frozen on
> 1.6.0 for the next 5 years of it's lifecycle.
>
> Snaps are self-contained packages that include all of the dependencies
> they need, which lets them run as you (the upstream) intended across new
> releases of Ubuntu, Debian, Arch, and many other distros. They run in a
> sandbox that protects them from changes made to the user's system, but
> with a number of optional interfaces if you need deeper interaction or
> to share data with other apps.
>
> Every snap includes its own file tree, and is run on top of the same
> base image regardless of distro or form factor. This keeps the
> application's own files isolated from other apps and the host system, in
> a read-only filesystem, which makes updating them safe and simple while
> keeping you in control of the whole stack that your application runs on.
> The snappy runtime then provides writable areas for storing both
> versioned and unversioned data, as well as system-wide or per-user data.
>
> We also provide a Snap Store, which combines the speed of
> self-publishing with the discoverability of a central archive. It is
> used by default across all Ubuntu 16.04 flavors and derivatives, and any
> distro where snaps have been enabled. Thanks to Snap's confinement,
> applications can be published immediately after uploading. This means
> that your application and updates are available to tens of millions of
> users as soon as you press the button.
>
> I started the work on producing a Snap package for Couchdb 2.0, but as I
> couldn't find a binary release I had to try building it from source and
> unfortunately I was not successful on that step. I am happy to share my
> packaging configuration with anybody here who knows the build process
> better than me, but it would be even simpler to create the snap package
> at the end of whatever process you already have to build binary
> releases. I am happy to help with either or both approaches, and you can
> also learn more about the snap format and tools here: http://snapcraft.io/
>
> --
> Michael Hall
> mhall...@gmail.com
>

CouchDB 2.0 as Snap

[Michael Hall]

First off, congratulations on the upcoming 2.0 release!

I would love to see this new version available as a Snap package for
users of Ubuntu 16.04 LTS, since the archive version will be frozen on
1.6.0 for the next 5 years of it's lifecycle.

Snaps are self-contained packages that include all of the dependencies
they need, which lets them run as you (the upstream) intended across new
releases of Ubuntu, Debian, Arch, and many other distros. They run in a
sandbox that protects them from changes made to the user's system, but
with a number of optional interfaces if you need deeper interaction or
to share data with other apps.

Every snap includes its own file tree, and is run on top of the same
base image regardless of distro or form factor. This keeps the
application's own files isolated from other apps and the host system, in
a read-only filesystem, which makes updating them safe and simple while
keeping you in control of the whole stack that your application runs on.
The snappy runtime then provides writable areas for storing both
versioned and unversioned data, as well as system-wide or per-user data.

We also provide a Snap Store, which combines the speed of
self-publishing with the discoverability of a central archive. It is
used by default across all Ubuntu 16.04 flavors and derivatives, and any
distro where snaps have been enabled. Thanks to Snap's confinement,
applications can be published immediately after uploading. This means
that your application and updates are available to tens of millions of
users as soon as you press the button.

I started the work on producing a Snap package for Couchdb 2.0, but as I
couldn't find a binary release I had to try building it from source and
unfortunately I was not successful on that step. I am happy to share my
packaging configuration with anybody here who knows the build process
better than me, but it would be even simpler to create the snap package
at the end of whatever process you already have to build binary
releases. I am happy to help with either or both approaches, and you can
also learn more about the snap format and tools here: http://snapcraft.io/

-- 
Michael Hall
mhall...@gmail.com