Mattermost-server: `sudo apt-get install mattermost`

[it33]

In Mattermost 3.5 shipping November 16, 2016 we're removing our NGINX dependency, and we're adding the ability to auto-configure certs via Let's Encrypt.

This simplifies the process of creating a package for Mattermost, and once that's available we can work on the various needed to get to sudo apt-get install mattermost

Anyone interested in helping on this?

[thorsummoner]

You'll probably want to use a ppa with launchpad.net, I wouldn't expect getting into the mainline repositories. I'm unfamiliar with the requirements to get in with the debian repository, I expect a maintainer would be a minimum and be expected to be asked to support LTS versions of the app with security fixes for years. (This is what I expect from an outside view, I don't really know)
With ppa you control what you publish directly.

Your installation insurrections get as simple as

apt-add-repository <pparef>
apt-get update
apt-get install <name>

I disagree with this following practice I see from Google, but if you're feeling particularly opaque, Google distributes chrome as a .deb file that uses install-time arbitrary code execution to add their repository to the target system. I assume this would work with a ppa source as well but there's no reason you couldn't host your own debian-format repository and ask people to install your repository to their system like with the ppa.

Sorry if I'm rambling things you already know. Posted with <3

---

PS. If anyone knows what the process is to get into the main debian repository, I would love to know.

[it33]

Thanks @thorsummoner, appreciate your input. If you'd like to join an on-going discussion, please join us on our Mattermost channel about installers and images.

[pravi]

I'm a debian developer and maintains gitlab and diaspora in debian. I can guide, mentor and sponsor (officially upload to debian) the package if some one is interested to do the packaging work.

[cpanato]

I have interest in doing that, if have some guidance @pravi @it33

[jasonblais]

Thanks @pravi and @cpanato, appreciate your interest!

If you'd like to join an on-going discussion, please join us on our Mattermost channel about installers and images.

[pravi]

@cpanato great! Lets take it forward via irc/matrix/xmpp/email.

[cpanato]

@pravi we can talk direct in the Mattermost server, what do you think? @jasonblais post the link to join

[pravi]

I don't use mattermost, a friend forwarded me this link. I prefer to use irc/matrix/xmpp/email.

[senk]

@pravi just drop you xmpp please, i'm also interested

[cpanato]

@pravi my xmpp is cpanato at xmpp.jp

[pravi]

My xmpp is praveen at poddery.com

[Rudloff]

I started some basic work on a Debian package here: https://github.com/Rudloff/platform/commit/adc0da67f16dacfd5806fe0f864d6c6e7daac251
But it seems the following Go dependencies are not yet available as Debian packages:

• github.com/ssor/bom
• code.google.com/p/freetype-go/freetype
• bitbucket.org/taruti/pbkdf2.go
• code.google.com/p/goplan9/plan9/acme
• github.com/decker502/dnspod-go
• github.com/edeckers/auroradnsclient
• github.com/ovh/go-ovh/ovh
• github.com/pyr/egoscale/src/egoscale
• github.com/rainycape/memcache
• github.com/timewasted/linode/dns
• google.golang.org/api/dns/v1
• gopkg.in/ns1/ns1-go.v2/rest

[grundleborg]

@Rudloff cool stuff, but I'm wondering, given that the Mattermost binary is statically compiled, and all the go dependencies are vendored in the repository, why the need to depend on Debian packages for them, rather than just compiling Mattermost as it would normally be with the vendored dependencies?

[Rudloff]

The policy for official Debian packages is to have every dependency available as a Debian package.
However if your goal is not to include the package in the official Debian repositories, you can totally ignore that and build Mattermost directly.

[grundleborg]

Ah, right, thought it might be something to do with Debian policy. That's an interesting question actually - I guess it depends on the extent to which the Debian packages will be officially supported by Mattermost Inc. I'll put this on the agenda for tomorrow's public developer team discussion - do drop in if you are available and would like to join the discussion. It's at 10am San Francisco time, and you can see the agenda and hangouts link here: https://pre-release.mattermost.com/core/channels/developers-meeting

[onlyjob]

Serious blockers are #8884, #8885, #8886.

[agnivade]

What are everyone's thoughts about having our own ppa and store the package there ? That should circumvent a lot of the debian policy restrictions and let us get this resolved quicker.

[onlyjob]

I'm strongly against the idea. Vendor packages are always of terrible quality. You can only do the job properly by working with Debian maintainers.

Debian policy is not the blocker here and circumventing the policy won't lead to anything good.

Instead I'd recommend to apply some pressure on Mattermost team to address the remaining blockers.