Package Details: sentry 9.1.2-1

Git Clone URL: (read-only, click to copy)
Package Base: sentry
Description: Python-based realtime logging and aggregation server.
Upstream URL:
Licenses: BSD
Submitter: zancarius
Maintainer: zancarius
Last Packager: zancarius
Votes: 14
Popularity: 0.90
First Submitted: 2012-11-04 17:15
Last Updated: 2019-08-31 02:03

Pinned Comments

zancarius commented on 2020-01-23 21:38

I have spent some time exploring options for upgrading this PKGBUILD to the latest version of Sentry and have encountered blocking changes that do not appear to have a clear resolution.

Currently, there were two PKGBUILDs that provide our required Clickhouse dependency but neither of these build successfully. Near as I can tell, some of Clickhouse's upstream dependencies have known issues that as yet have no resolution outside attempting to patch either Clickhouse or wait for the upstream developers to address these deficiencies. This is not something either myself or the maintainer(s) of the Clickhouse PKGBUILD(s) can address (not easily, anyway).

Consequently, I will be updating this PKGBUILD, bumping the pkgrel in effort to increase the visibility of this issue. We will be holding Sentry at its current state until we have a clear path forward.

If you need Sentry 10.x.x in your environment, consider installing their official Docker packages. This is the currently recommended method for installing Sentry.

zancarius commented on 2020-01-17 06:45

Sentry v10.0.0 is out, but I will not be upgrading this package for some time. In fact, I'm not sure when an upgrade will be available because the number of additional service dependencies has since exploded.

To illustrate, Sentry v10.x now depends on:

  • Zookeeper
  • Kafka
  • Clickhouse
  • Snuba

I don't believe Snuba can be disabled in Sentry post-v9.1.2. If this is true, then this means that Sentry now has an implicit dependency on the JRE which may be prohibitive for those users who are running Sentry on lower end hardware or memory-constrained environments.

The official installation guide recommends installing the on-premise edition of Sentry via Docker and advises against source installation, which is what we're doing here.

This leaves us with a couple of options (plus a third thrown in as an either/or):

1) Upgrade anyway and add a host of other dependencies to the PKGBUILD that may surprise some users. Given that Sentry is a complex piece of software to install, this will only add to the complexity and will require additional packages, configuration, etc., that will need to be completed before Sentry can even be upgraded. (The migration process moves events from the database into Snuba, for example.)

2) Cheat and take the easy way out; deprecate this PKGBUILD and point users to the official Docker images. There's no point trying to wrap the Docker images in a PKGBUILD.

3) Rename this package to something like sentry9.1, freezing it at this version, and then pick options #1 or #2.

When I have some time this weekend, I may ask around for advice. There's no easy solution in this case, and I know from past experience with this package that there are some users who may be uninterested in running Sentry v10 if it requires configuring at least 3 other services. I will leave this package flagged for the time being in the hopes users of this package check here.

Latest Comments

« First ‹ Previous ... 2 3 4 5 6 7 8 9 10 Next › Last »

zancarius commented on 2016-05-08 03:35

This looks to be related to your problem:

I'll see if there's something we can do to mitigate this. It might be the version of uWSGI Sentry is dependent on mixed with an unusual local configuration, but I'm unsure why I can't easily replicate it.

Is there a way you could try building Sentry under a clean environment, like with pacstrap + systemd-nspawn?

zancarius commented on 2016-05-08 01:27

Okay, I can't replicate the problem on a few systems even with -Werror in my CFLAGS (though I was able to make lxml fail to build).

I'd suggest looking at your /etc/makepkg.conf for starters--perhaps comparing it with the stock config from your local pacman package. Also examine your environment; in all likelihood, something is causing your gcc to bail on warnings.

zancarius commented on 2016-05-08 00:50

Builds fine for me. The problem appears to be with uWSGI. What happens if you install it separately, e.g.:

virtualenv2 ~/.test-env
source ~/.test-env/bin/activate
~/.test-env/bin/pip install uwsgi

If I'm not mistaken, this looks like it might be an issue with your CFLAGS or similar? In particular this part (probably triggered by -Werror=misleading-indentation):

>> cc1: all warnings being treated as errors

mitchhentges commented on 2016-05-08 00:41

Unfortunately, Sentry 8.4.0 doesn't seem to want to build. I'm assuming that this would be an issue with Sentry itself?

[thread 5][gcc -pthread] plugins/http/keepalive.o
[thread 6][gcc -pthread] plugins/http/https.o
[thread 7][gcc -pthread] plugins/http/spdy3.o
[thread 0][gcc -pthread] plugins/ugreen/ugreen.o
[thread 2][gcc -pthread] plugins/signal/signal_plugin.o
[thread 1][gcc -pthread] plugins/syslog/syslog_plugin.o
[thread 3][gcc -pthread] plugins/rsyslog/rsyslog_plugin.o
plugins/corerouter/cr_map.c: In function ‘uwsgi_cr_map_use_static_nodes’:
plugins/corerouter/cr_map.c:156:5: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation]
if (!next_node)
plugins/corerouter/cr_map.c:159:6: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘if’
while (tmp_node != next_node) {
[thread 2][gcc -pthread] plugins/logsocket/logsocket_plugin.o
[thread 1][gcc -pthread] plugins/router_uwsgi/router_uwsgi.o
[thread 5][gcc -pthread] plugins/router_redirect/router_redirect.o
cc1: all warnings being treated as errors

Command "/tmp/yaourt-tmp-mitch/aur-sentry/pkg/sentry/opt/sentry/bin/python2.7 -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-nXNUr8/uwsgi/';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-n3_YP1-record/install-record.txt --single-version-externally-managed --compile --install-headers /tmp/yaourt-tmp-mitch/aur-sentry/pkg/sentry/opt/sentry/include/site/python2.7/uwsgi" failed with error code 1 in /tmp/pip-build-nXNUr8/uwsgi/
==> ERROR: A failure occurred in package().
==> ERROR: Makepkg was unable to build sentry.

Mastacheata commented on 2016-04-20 12:16

Ohh, sorry. To me it looked like you read my comment and thought migration as in migrate away. (Which is a very common misconception if you encounter that term for the first time)

> At present, I can't find any immediate need to migrate specific configuration values from the old `` style config with the exception of Redis (a recent addition).

The Mail settings are even more important. Redis can still be configured in the without the UI complaining, but if you configure the mail settings in the python file, you'll get deprecation notices in the Web Interface.

zancarius commented on 2016-04-20 03:35

Okay, I've pushed the new PKGBUILD (same version; the `pkgrel` is the only thing that's changed).

If you're coming upon the comments here because you're somewhat perplexed or concerned about the deprecation of MySQL support as indicated in the upgrade notes, you'll need to read the official stance in the Sentry changelog for 8.0 [1]. There isn't much we can do about this, and you'll need to plan accordingly. I've linked some tools in the upgrade text that might help you but bear in mind that using them is completely unsupported. In addition, you're strongly encouraged to read the PostgreSQL user's guide which details migrating your data from MySQL to Postgres, concerns, and likely problems [2] (it's possible but only you can decide if it's worth the effort). There are other scripts out there that can assist you with migrating your data, but I'll leave using them as an exercise to the reader. I'm reluctant to get into the politics of it here, but you really ought to use a Real™ DBMS if you're not already--in particular, PostgreSQL has support for DDL changes within a transaction, making schema migrations relatively painless if something should go wrong (MySQL doesn't and therefore has the propensity to cause many sleepless nights--ask me how I know).

Otherwise, thanks to the efforts of mastacheata, the last vestiges of our Sentry package's dependencies on the old configuration style are mostly on their way out. You still have to use it, but the initialization process and instructions have been updated accordingly. (Note: The official documentation uses envvars for conveying configuration location; I'm yet undecided whether or not we'll end up using those instead.)

At present, I can't find any immediate need to migrate specific configuration values from the old `` style config with the exception of Redis (a recent addition). If this concerns you, you may want to generate a new configuration using `sudo -u /opt/sentry/bin/sentry init` where appropriate or follow the upgrade instructions. Be aware that you'll need to keep your secret key (now contained in /etc/sentry/config.yml), otherwise all of your existing login sessions are likely to fail.

As usual, I cannot stress enough the necessity of backing-up your database and test the installation on a development machine before deploying this package. If you encounter difficulties, post them here or open a ticket on the repository containing this PKGBUILD [3].


zancarius commented on 2016-04-20 02:42

*face palm* I'm well aware of what what migrations are (currently, I'm developing some relatively large Flask-based applications with my preference being SQLAlchemy), but there are tools to migrate data away from different DBMSes (with different degrees of success). Hence the link in my earlier comment.

In this context, though, I'm referring to migrating 1) existing configurations (this needs research) and 2) possible options for migrating data away from MySQL for those users who may have done that.

I'm not referring to schema migrations. Perhaps the appropriate term is "export" but you're still dealing with migrating data away from one platform on onto another.

For what it's worth, I've actually been running Sentry under MySQL for quite some time. The Django ORM and Sentry's existing migration utilities and libraries have been working fine for this purpose (with the exception of one or two changes I've had to make recently to individual migrations).

Mastacheata commented on 2016-04-20 02:32

Re 2)
Migration has nothing to do with switching database systems in this context. A migration is basically a script or program that performs changes on the database (structure). Basically these scripts are built so that you can have a version control for your project's database structure. For more information see here:

Sentry is known for modifying their database structure very often. These changes between program versions would usually be performed by the upgrade command. However as of sentry 7 only changes to postgres are automated (run upgrade command and be happy).
You CAN continue to use mysql or sqlite since the code for reading and storing data is pretty easy to keep platform independent. But you need to perform any changes made to the postgres structure in your mysql or sqlite db by hand. (i.e. Rename column x in table y or change the data type or add a new index, or or or)

Thanks for looking into this so quickly.

zancarius commented on 2016-04-20 01:32

1) I'm currently looking at the PR request. I'll merge it, but I need to see what may be required in the future for existing users for the config migration.

2) Dropping MySQL-related notices would probably be pertinent. I'll freely admit I don't follow Sentry's release notes all that closely. (Shameful.)

As far as database migration from MySQL to Postgres, I think that's the user's responsibility (and they'll have to decide how they want to handle migrating away from MySQL, if they're using it). Sentry AFAIK is a Django app and there are tools that may help [1], but I don't think that's something this package should be concerned with--even if someone has been using MySQL previously.

Unfortunately, that's the nature of large "some assembly required" applications that require additional configuration and work out of the box.


Mastacheata commented on 2016-04-20 01:23

One more thing: Does it make sense to keep the mysql/mariadb and sqlite bindings mentioned here? The sentry team stopped maintaining the database migrations for these backends in version 7 and announced to drop support completely in the future.

That means any database changes made since the announcement will work automatically using the upgrade command for postgres, but will have to be made by hand using only the postgres sourcecode for any other backend. (Yes you really need to look at their postgres migrations and find out what it does there and how to apply that in MySQL/SQLite Syntax if that's even possible at all)