also 'rugged' gem is now build with separated libgit2 library,
otherwise the comilation result depends on the system where it is
built (and even if can fail).

so that we can explicitly specify which libraries should be / should
not be used and set RPATH appropriately, otherwise existing system
libraries may be used and the result depends on the environment where
rugged is built.

otherwise system libdb can be linked.

/reviewed-by @kirr
/reviewed-on nexedi/slapos!62

@kazuhiko also says:

with our current usage on gitlab, missing RPATH is not an issue but if
you invoke './parts/icu/bin/makeconv', it fails before my change.

/reviewed-by @kirr
/reviewed-on nexedi/slapos!62

* patch nltk egg so that the default data location is (buildout_directory)/parts/nltk-data without explicitly specifing by NLTK_DATA environment variable.
* download collection can be overridden like 'collection = aaa bbb ccc'.

/ref http://community.slapos.org/forum/NLTK-Buildout--Download-and-install-nltk_data

/cc @klaus, @Kreisel 

/reviewed-on nexedi/slapos!58

To pick up

    gitlab-workhorse@32ec77c4

/reviewed-by TrustMe  (I hope)

@rafael says:

    Use master instead.

    nexedi/slapos@000d0e5a (comment 4716)

So lamp-edge -> master

@rafael says:

    development stuff from marco, it was probably removed or not even
    included.

    In theory you can use master instead.

    nexedi/slapos@692729bc (comment 4713)

So lapp-resilient3 -> master

To pick up

    nexedi/gitlab-ce@827d3914

/reviewed-by TrustMe (I hope)

To pick up

    nexedi/gitlab-ce@1bfb586a

/reviewed-by @kazuhiko

kirr/ remains as my personal development place and nexedi/ ones become
official repositories.

Discussed with @kazuhiko
/reviewed-by TrustMe

version up: OpenSSL 1.0.2g, fixing CVE-2016-0800, CVE-2016-0705, CVE-2016-0798, CVE-2016-0797, CVE-2016-0799, and CVE-2016-0702.

To pick up

    gitlab-ce@8d922ec3
    gitlab-ce@5d6b7eba

See:

    gitlab-ce@5a6e6e55

for discussion.

/cc @kazuhiko, @jerome
/reviewed-by TrustMe

Shacache now uses CDN based URL for download.


  Update configuration to use CDN based domains for download date from CDN. 

See merge request !56

- GitLab Software + patches ported to latest stable GitLab 8.5.1
  (including fix for raw downloading to work in browser for private
repositories);
- Sync-with-upstream procedure streamlined (now only 1 branch for
  tracking upstream configuration files);
- Base software upgraded: Ruby, Redis, Nginx, Git;
- misc fixes.

/cc @jerome, @jm
/reviewed-by @kazuhiko
/reviewed-on nexedi/slapos!55

    $ git diff 8.4.4+ce.0-0-g1680742..8.5.1+ce.0-1-ge732b39 --  \
        files/gitlab-cookbooks/gitlab/templates/default/sv-sidekiq-run.erb

shows nothing.

I manually reviewed

    $ git diff 8.4.2+ce.0-3-g68d5ee8..8.5.1+ce.0-1-ge732b39 \
        files/gitlab-config-template/gitlab.rb.template \
        files/gitlab-cookbooks/gitlab/attributes/default.rb

in omnibus-gitlab, and module proxy_set_header change, which we already
addressed in previous patch in Nginx config, there are no more changes
for us.

    - relative URL support: comment out - we do not need it - gitlab is
      always located at /.

    - Nginx-http: restore our version for proxy_set_header - upstream
      turned to allowing users to configure this, see e.g.

        https://gitlab.com/gitlab-org/omnibus-gitlab/commit/e13d5e42
        https://gitlab.com/gitlab-org/omnibus-gitlab/commit/a450585e

      but doing this way creates more complexity for gitlab SR, so I've
      restored our version which essentially does the same as default in
      omnibus-gitlab, and if we'll need to tune it - we can do directly in
      Nginx config.

      In other words slapos version does not allow users to tune nginx
      headers as instance parameter.

This does only pure merge. We will slaposify / adjust config and
corresponding md5sum in the following patches.

/cc @kazuhiko, @jerome

As it is said in 97dcf455 (gitlab: Establish proper 1 branch for
tracking upstream configs) we are switching to a model where we track
upstream configureation files on only one branch.

This merge does not change files on master - because we already have all
current upstream changes in - just establish a proper structure for future
updates.

/cc @kazuhiko, @jerome