Provide releases and deb/rpm packages via Bintray

[tboerger]

I would like to integrate a proper process to create real system packages and distribute them via Bintray, than users can just add a deb/rpm repository and got a clean upgrade path.

Beside that we can also publish our releases to a static page or also to Bintray for download.

[metalmatze]

Do we really need deb/rpm? Aren't just docker images enough? Idk, prove me wrong! :)

[metalmatze]

drone only has docker images, right?

[jhasse]

Gogs is using packager.io, why not reuse that?

[tboerger]

Because not everybody is/will use docker.

Packager.io only supports lts versions, beside that the golang packaging can be done much easier than with the overhead of Packager.io.

[jhasse]

Okay I don't know enough about Go. But having a solution for Ubuntu 16.04 would be great, as gogs/gogs#3617 didn't get merged :(

[tboerger]

To provide packages for any ubuntu/debian/whatever version we can wrap the same binary into the package and just need to adjust the init (sysvinit, systemd) script.

[jhasse]

Can we merge the 16.04 packager.io PR and enable gitea on it for the time being though?

[lunny]

Both binary and docker are needed.

[tboerger]

Can we merge the 16.04 packager.io PR and enable gitea on it for the time being though?

We don't have enabled anything over there yet, but since this issue is estimated for 1.0.0 I would like to introduce it for our first release.

[sbrl]

I also would like binary releases - I don't have a go development environment setup to compile things.

Also, will I be able to upgrade to gitea from gogs? I'd hate to loose my issues etc.

[tboerger]

We will have binary releases and hopefully also packages for the major Linux distributions. You don't need to compile anything.

We will also have binaries for the latest master version.

You will be able to directly launch gitea with the Gogs database. If we got database changes they are getting automatically migrated.

[sbrl]

Ooh sounds awesome! I'm looking forward to it then ☺

-- Starbeamrainbowlabs (keybase.io/sbrl)

[denji]

https://packagecloud.io (OSS — 25 GB Storage / 250 GB Bandwidth + CDN bintray.com 1TB/m)

@tboerger https://packagecloud.io/docs#os_distro_version LTS and non-LTS deb/rpm/etc…
elementary OS / Raspbian / Ubuntu / Debian / SUSE Linux Enterprise Server / openSUSE / Fedora / LinuxMint / poky distro / Oracle Linux / Scientific Linux / Enterprise Linux (CentOS, RedHat, Amazon Linux)

[tboerger]

@denji yeah I know packagecloud, maybe we will take it, but than we need a drone plugin for it :)

[tboerger]

This won't happen for 1.0.0, so I will move it to 1.1.0.

[jhasse]

Gogs already provides deb and rpm packages, so this would be a real pity if it won't happen for 1.0.0.

Will I be able to update Gogs 0.9.99.0903 to Gitea 1.1.0 without problems?

[tboerger]

Gogs is using a service that only supports lts versions and which does some strange binary wrapping. We want to have a real solution.

[lunny]

I think you could upgrade from Gogs 0.9.99.0903 to Gitea 1.1.0.

[bkcsoft]

@tboerger what about doing something like this? https://blog.codeship.com/using-docker-build-debian-packages/

@lunny I'm guessing @jhasse means upgrade by apt-get upgrade

[tboerger]

A plain apt-get upgrade won't work since we will have a different package name. But I think it will work to do apt-get remove gogs && apt-get install gitea :)

[lunny]

Then they have to copy Gogs' app.ini to Gitea.

[jhasse]

Then they have to copy Gogs' app.ini to Gitea.

They have to do that before apt-get install gitea though, otherwise the service would have already been started.

[bkcsoft]

@jhasse IIRC debian packaging rules forbid auto-enabling services on install 😉

[jhasse]

You can configure this: http://askubuntu.com/questions/365911/why-the-services-do-not-start-at-installation

And I think the default on Ubuntu is to auto-enable them. At least when I installed Gogs on Ubuntu 14.04 I didn't need to do it manually.

[RichieB2B]

It is true that packager.io does binary wrapping, but it is needed for gogs/gitea. Several environment variables need to be set up, etc. I found the CentOS 6 gogs RPM very simple to install and set up.
Whatever packaging solution you pick for gitea please make sure it is easy to install, configure and upgrade.

[6543]

@tboerger I'll try make a draft PR with the deb build script ...
& we have dl.gitea.io is it worth to upload the deb there too (and perhaps as atatchment on release)

[tboerger]

I personally wouldn't like to manage deb and rpm repos on my own, that's why Bintray would be great for that. Just uploading a deb or rpm file without any repository is IMHO pretty useless.

[waja]

Just uploading a deb or rpm file without any repository is IMHO pretty useless.

it's completely nonsens!

[lafriks]

We could also use nfpm for building deb and rpm files

[tboerger]

Somebody has already started some time ago to build a drone fpm plugin... I still want to build one within the plugins org based on the go fpm fork.

[techknowlogick]

Here is a drone plugin that I made for nfpm: https://github.com/techknowlogick/drone-nfpm

[zeripath]

If you make packages for FHS systems remember to either use the shadowing script in contrib or build with the LDFLAGS set correctly.

[azlux]

Hi all, I have my own APT packages repository, I can add gitea on it.
See the project already included : https://packages.azlux.fr/
Now it's running, it's easy to add any .deb you want (I can even create it)

Azlux

[Janhouse]

@azlux it all comes down to the trust. You are probably a cool guy but I would rather install it from some known automation service where build scripts are maintained by the gitea dev team, than get it from some private repo. I have my own packages built as well, but ideally it would be managed by gitea team.

[azlux]

Ho ok
Thank for the info @Janhouse
I've setup my repo with reprepro, I can help if you need to.

Az

[azlux]

@Janhouse After a deeper thinking, The apt repo allows us to verify that the sources have not been modified in the meantime. Ideally, it's better to have gitea maintaining their own repo, but they can also put other repo as "unofficial repository".
Lot of project don't have a problem with that. Like that, People warned.

[zeripath]

I know I've said this before but...

If you're providing Deb packages, you should probably build Gitea so that it obeys the FHS by setting the LDFLAGS as described here:

https://docs.gitea.io/en-us/install-from-source/#changing-the-default-custompath-customconf-and-appworkpath

[sbrl]

Same here - I have a personal apt repo I can host in

[ghost]

I would also like to see gitea follow the FHS @zeripath , its silly they need a wrapper shell script to do so too.

Any news on RPMs in the meantime? I see a lot of discussion about DEBs but many enterprises will be using CentOS which does not use DEB packages. The BSDs seem to have their own packages (with patches) but their processes are a bit different.

[zeripath]

@evitalis you don't need a script if you build it with the appropriate LDFLAGS.

[ghost]

I know, I was referring to their need to even have this.

[sapk]

Just thinking of it. FHS path should be default for v2 as it would be a needed breaking change.

[zeripath]

I think we need to break that down a bit. There are four kinds of build at present:

• development builds - you download the source and you build with make
• personal builds - you download the source and you build with make but want this a running server
• release builds - we build with make release and stick on gitea.io and GH
• docker builds

FHS by default makes sense for up to 2 of those: release and possibly personal - but at present you can't tell if a personal build is a development build or vice versa. Breaking the development builds would be a very very bad idea.

The Docker should also have its defaults embedded - it's nonsensical to have to require "-c" by default on a docker build we build ourselves.

There's a possibility of changing where we look by default depending on where the binary is placed - but I suspect that might be a bad idea. I guess I'd have to check again what is normal practice for this. (hierarchies of config lookups? - ugh complex)

When I first made the LDFLAGS option work I proposed:

• Make a separate release with FHS paths embedded
• Make the docker have the default paths for docker embedded - which solves a few other weird issues with running gitea on the docker command line.
• Add/Expose a make endpoint for FHS builds that sets the flags properly <- Package builders should use this...

These are non-breaking changes that would not necessarily require waiting for 2.0 - we're just adding a new download option.

An alternative is to add a configure script and make install endpoints - as then it would look "normal" to people used to:

# get source by whatever means necessary
cd gitea
./configure
make
sudo make install

[tboerger]

It's absolutely normal to search within predefined paths for configs if you do not provide a flag for a custom path. That's as an example already part of https://github.com/spf13/viper to define multiple standard paths. The current fuckedup behavior of Gitea is totally uncommon.

[sbrl]

Perhaps it would be worth putting the release builds into the repos first would be a good 1st step?

[azlux]

@sbrl already done on my repo , the build script is store here : https://github.com/azlux/dpkg-deb
As you said, It use directly the release build.

[ghost]

@zeripath I think you are making this more complicated than it needs to be based on your reply, but I may be misinterpreting it. If people are running git clone and building things themselves then they should know problems might happen. For many projects either doing said build from the master branch or using a release is considered stable, anything else is not and can break at any time.

Even in Docker there is no reason to not follow the FHS so that case goes away too. For the rest as noted by @tboerger checking for a standard set of paths for a config is considered normal. Relying only on $PWD or random compile flags that most users won't ever see causes more issues, including with OS packaging. As someone who has packaged more than a few things the less standard the application the more work for me and the more patches I may have to introduce.

With all that said I am still interested in seeing official RPMs at least. I don't use Debian or Ubuntu but I am sure an official DEB would also be welcome. Thanks to everyone in this thread doing their best on the packaging in the interim.

[tboerger]

I'm not really involved into Gitea anymore, so I'm closing this issue. If there ist still interest please open a new issue and maybe link to this one for initial discussion. I want to get my issues cleaned up.

[fazlerabbi37]

f there ist still interest please open a new issue
@tboerger rather than opening a new issue and starting over again maybe you can just unsubscribe from the issue, and it can be re-opened for people who are interested?

[tboerger]

Just reference this issue on the new one to keep the context. Unsubscribe is not the same as having it in my open issues view on github. And as I can't transfer issues to somebody else it's closed. Beside that, nothing has changed for years...