Package Details: sentry 8.15.0-1

Git Clone URL: (read-only)
Package Base: sentry
Description: Python-based realtime logging and aggregation server.
Upstream URL:
Licenses: BSD
Submitter: zancarius
Maintainer: zancarius
Last Packager: zancarius
Votes: 7
Popularity: 0.177535
First Submitted: 2012-11-04 17:15
Last Updated: 2017-04-06 19:43

Latest Comments

zancarius commented on 2016-11-04 02:41

Bumped to version 8.10.0 (thanks Mitch!).

Beware: Pay very close attention to following the upgrade instructions. File storage settings have moved from into config.yml. If you neglect to move these configurations, you may experience breakage.

zancarius commented on 2016-10-06 03:51

This post is to acknowledge a warning related to the Sentry 8.9.0 upgrade:

First, symsynd is now listed as a Sentry dependency [1] and is no longer a separate plugin. As such, I am no longer offering this as a split package with sentry-dsym. If you're coming here because you can't find the sentry-dsym package or because of "exists in filesystem" errors, you'll need to remove sentry-dsym first *before* installing Sentry.

Unfortunately, the inclusion of symsynd now means that Sentry requires LLVM to be installed on the target host. I've included some suggestions in `sentry.install` in the event this is a problem, but it looks like this is the direction upstream is going, so we're going to have to follow suit.

Second, changes to symsynd now require ncurses 5.x. Unfortunately, Arch uses ncurses 6.x, so we currently have to pull an external lib from the AUR to install ncurses 5.x support (ncurses5-compat-libs). I don't have much confidence that symsynd will be updated to ncurses 6 any time soon, so if time permits, I may investigate other options.

If you experience problems with this release, it's likely they may be due to missing libraries or other dependencies I've missed. Feel free to submit a ticket on any of the repositories listed here [2].


zancarius commented on 2016-10-05 06:00

Got the outdated notification. I'll update to 8.9.0 sometime tomorrow or tomorrow evening (UTC-6).

zancarius commented on 2016-09-08 06:22

Updated to version 8.8.0. Thanks for the notification!

As always, report PKGBUILD bugs on my PKGBUILDs repository [1].

I now have mirrors configured elsewhere (see the README), so if you'd rather avoid GitHub or have a preference elsewhere, feel free to pick the host that suits your needs best and report bugs there.


zancarius commented on 2016-06-10 05:24


libxml2 is probably also required as well, strictly speaking, it's just that pulling in libxslt also installs libxml2.

For completeness sake, I've updated the makedepends to include both. Apparently the notion of adding it to the split package depends array never fully percolated to the top when I was considering makedepends.

Good catch, thanks!

Ahti333 commented on 2016-06-10 04:40

The makedepends of the PKGBUILD should include libxslt as well. The python2-lxml egg won't build without it.

zancarius commented on 2016-06-06 17:49

Thanks Mitch!

I appreciate your feedback and help!

mitchhentges commented on 2016-06-06 17:44

It appears to be working, even after a reboot. No errors or anything. Thanks!

zancarius commented on 2016-06-06 17:42

I usually forget to fix things because I'm an idiot. ;)

Also, keep an eye out for the unit file changes. They've moved a ton of stuff and deprecated some of the old runners, so I've split things out. You should only have to run sentry.service now (systemctl start sentry), which is nice. Unfortunately, it also spawns a couple of other things (celery and celery-beat via "sentry run worker" and "sentry run cron"). I'd like to know if that works for you.

mitchhentges commented on 2016-06-06 17:40

Ah, I hadn't checked the upgrade instructions, because I'm a skrub.

zancarius commented on 2016-06-06 17:38

Did I forget to change that in the upgrade instructions? Looks like something I'd do.

mitchhentges commented on 2016-06-06 17:37

Ah, it's because, when upgrading sentry, I was running `/opt/sentry/bin/sentry --config /etc/sentry/ upgrade", but it looks like now just the directory is specified for the --config option.

So: `/opt/sentry/bin/sentry --config /etc/sentry/ upgrade`

zancarius commented on 2016-06-06 17:35

Sentry's launcher has changed a bit as of 8.5.0. I might've missed something.

mitchhentges commented on 2016-06-06 17:33

Hmm, I'm having an issue with `system.secret-key` allegedly not being set. It's fixed by moving my config to `/opt/sentry/.sentry/` but that's not a great solution. I'm not sure why it's failing when the config is at `/etc/sentry/` though. Maybe that's just for me?

zancarius commented on 2016-06-06 17:11

Sorry about that. Unexpected dependency creep. :(

mitchhentges commented on 2016-06-06 17:10

After installing `libjpeg-turbo`, it appears to be working. Thanks!

zancarius commented on 2016-06-06 17:00


After some poking around, I was able to replicate your problem by removing libjpeg from a container and clearing my pip wheels cache.

Could you try installing libjpeg-turbo and try again? Looks like this needs to go into the dependency list.

I don't recall seeing Pillow in previous versions of Sentry, so I'm wondering if this is a new addition.

Edit: I tested this a few times. Looks like adding libjpeg-turbo to makedepends (and it's probably a run time dependency for Pillow, too, so it's in Sentry's depends list) fixes things, so I pushed a new pkgrel.

mitchhentges commented on 2016-06-06 09:34

I'm getting an error when building:

Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/tmp/pip-build-cuM9f7/Pillow/", line 767, in <module>
zip_safe=not debug_build(), )
File "/usr/lib64/python2.7/distutils/", line 151, in setup
File "/usr/lib64/python2.7/distutils/", line 953, in run_commands
File "/usr/lib64/python2.7/distutils/", line 972, in run_command
File "/tmp/yaourt-tmp-mitch/aur-sentry/pkg/sentry/opt/sentry/lib/python2.7/site-packages/setuptools/command/", line 61, in run
File "/usr/lib64/python2.7/distutils/command/", line 563, in run
File "/usr/lib64/python2.7/distutils/", line 326, in run_command
File "/usr/lib64/python2.7/distutils/", line 972, in run_command
File "/usr/lib64/python2.7/distutils/command/", line 127, in run
File "/usr/lib64/python2.7/distutils/", line 326, in run_command
File "/usr/lib64/python2.7/distutils/", line 972, in run_command
File "/usr/lib64/python2.7/distutils/command/", line 339, in run
File "/tmp/pip-build-cuM9f7/Pillow/", line 512, in build_extensions
' using --disable-%s, aborting' % (f, f))
ValueError: jpeg is required unless explicitly disabled using --disable-jpeg, aborting

zancarius commented on 2016-06-06 06:16

As of this version, I've introduced a few new unit files. This means the upgrade process may require particular attention to detail. I'd recommend stopping Sentry prior to this upgrade and then following the instructions as normal:

sudo systemctl stop sentry sentry-celery

Once you've upgraded Sentry, be sure to issue:

sudo systemctl daemon-reload

to load the new unit files. Control over Sentry has now coalesced into a single unit file:

sudo systemctl start sentry

If you have upgraded Sentry and issued a "systemctl daemon-reload" without first heeding these instructions, you may have to stop Sentry manually by sending a SIGINT to the uWSGI master process.

I'm hopeful this will be the last major change in Sentry's unit files for the foreseeable future. Future upgrades will require restarting only sentry.service, and I'll make note of that when the time comes.

As always with changes of this sort, there's a potential for breakage. Please report your problems here or on the GitHub repo containing this PKGBUILD [1].


zancarius commented on 2016-06-06 04:41

I'll be posting a new PKGBUILD later tonight or tomorrow evening. It seems that as of 8.5.0, `sentry celery` has been replaced with `sentry run worker` and `sentry run cron`, continuing the deprecation of named tasks and their replacement with `run`.

I don't want to force ever growing numbers of unit files on everyone, so we're going to be replacing this with a or similar and rolling it up into a new sentry.service file that will launch all dependencies.

If you happen to miss the note here, I'll be including it in the upgrade instructions.

Thanks again, everyone.

zancarius commented on 2016-05-25 21:51

@Ahti333: If you could, here's a PKGBUILD containing the split package [1]. I'm not entirely sure if the dependencies are correct or if this will work with dsym support enabled. It should, but I have no means of testing it at this point in time.

You'll need the supporting files as well (sentry.install, sentry.service, sentry-celery.service).

I hope this is more in line with what you had in mind, though it does involve some rather ugly copying of libraries for the sentry-dsym package.

Also, I haven't test-built this from a clean container. If I'm missing a dependency, please share.


zancarius commented on 2016-05-24 22:59

I've posted an issue on my GitHub repo for this PKGBUILD [1]. I won't push a new version of this package until I get a little extra input from some of Sentry's known users who have contributed in the past to improving this PKGBUILD, until a new version is released, or until a week's time has expired with no further input.

My reason for delaying this is to avoid interfering too badly with other users in the event they have automated building/deployment of Sentry, and this is a bit of a big-ish change to the PKGBUILD that may violate the principle of least surprise.


zancarius commented on 2016-05-24 20:34

Okay, LLVM will have to be a dependency during build. makedepends can't be overridden in a split package.

zancarius commented on 2016-05-24 20:30

I should add that this would be easier to fix if I weren't so stupid and decided a long time ago to switch Sentry to build from PyPI directly via pip instead of downloading the package and running Unfortunately, the old way meant having to track down a half dozen maintainers on the AUR just to keep their PKGBUILDs in sync with Sentry's dependencies (or patching if they were ahead), and it was entirely too much work. Using `pip install` from the PKGBUILD is the path of least resistance, and much easier, but leads us to this trouble where we can't simply use optdepends to install, say, symsynd by itself into the global site-packages (maybe we could, but we'd have to edit the behavior of the virtualenv).

I think I like your suggestion (split packages) better than struggling to fit optdepends into this without reverting back to the Old Painful Way™ of doing things.

zancarius commented on 2016-05-24 20:25

A split PKGBUILD might be the way to go since I'm not terribly fond of maintaining a separate package just for dsym support (but it's doable). The only caveat being that we essentially have two choices: 1) Create a split package that builds Sentry twice (one with dsym support via dsym_requires) or 2) create a split package that just installs the required modules (symsynd and friends). The former means build times would take twice as long, but we wouldn't have to worry about copying the right dependencies. The latter means we would have to do a little extra work, but it could be built as a separate kind of "extension" package, for lack of a better term.

I *think* #2 should be possible (and I'd rather go that route) since I don't believe pip stores a registry anywhere like easy_install used to do, and the virtualenvs just change sys.path to point to the new site-packages directory. Thus, as long as we can stuff dependencies into Sentry's site-packages, we should be good--with the added bonus that it'll be tracked by pacman's database.

Now, AFAIK, split packages should allow us to add a separate makedepends per package, thus keeping LLVM local to sentry-dsym (for example). Unfortunately, I'm not completely sure if there is a way to tell makepkg which packages to build by default, or if there is a way to selectively pick and choose what we want to build without having to edit the downloaded PKGBUILD, because otherwise it'll build everything listed in the pkgname array (and would require everyone to suddenly install LLVM if they weren't aware of this). I *thought* I've used an interactive build tool that let me pick packages, but I seem to be remembering this wrong. makepkg(8) doesn't seem to hint at anything we could use.

I'll do some research to see what our options are, and if you or anyone else would like to pitch in, let's see what we can do that might alleviate forcing LLVM on people who don't want to build a sentry-dsym package while keeping it as simple as possible for people who need dsym support.

Ahti333 commented on 2016-05-24 19:48

Yep, that's pretty much what I'm using locally right now.

I'm not very experienced with makepkg, but there is a way to create multiple packages after building things (see for an example), so it may be possible to build sentry with dsym support and then seperate the built tree into two separate packages (core sentry and dsym plugin). I don't know wether that would be easy to do with the way pip works.

zancarius commented on 2016-05-24 19:03

I'm reluctant to change the current package to enforce dsym_requires on existing installs, but I also can't see an easy way to add this as a "smaller" package (think plugin) as installing symsynd into a separate virtualenv and attempting to merge it into the existing Sentry path would be too painful. So, the only way to accommodate both sides might be to create a separate package. Were you thinking of something like this?

Ahti333 commented on 2016-05-24 18:30

The current PKGBUILD does not build a sentry capable of symbolicating backtraces (at least those sent by iOS devices).

To fix this, we'd need to change the pip command to install "sentry[dsym]==${pkgver}" instead of "sentry==${pkgver}". We'd also need to add a runtime dependency on llvm, since it contains `llvm-symbolizer` which is needed.

I don't know wether it might be worth it to break this out into a separate package, since the llvm dependency is 115mb installed size.

Any thoughts?

zancarius commented on 2016-05-15 06:00

I'll update this shortly. If it doesn't make it out with a new pkgrel, it'll most likely make it in the next version bump.


Ahti333 commented on 2016-05-15 05:57

the sentry binary help states that `sentry start` is deprecated in favour of `sentry run`, so sentry.service should probably be adapted.

zancarius commented on 2016-05-08 05:14

Here's a workaround, but you have to do something yourself:

I've uploaded a package that mucks with your CFLAGS if you so choose, but because not everyone is guaranteed to be running GCC 6.1 yet, it's necessary for you to edit the package() section in the PKGBUILD as appropriate. Look for the lines below:

#CFLAGS="-Wno-error" "${pkgdir}/opt/sentry/bin/pip" install "sentry==${pkgver}"
"${pkgdir}/opt/sentry/bin/pip" install "sentry==${pkgver}"

Uncomment the CFLAGS line and comment out the line immediately below it, then build Sentry as normal. If you want to be more specific, replace -Wno-error with -Wno-misleading-indentation.

Optionally, add either of these two flags to your CFLAGS in /etc/makepkg.conf.

zancarius commented on 2016-05-08 04:55

You're also going to have problems building lxml.

zancarius commented on 2016-05-08 04:53

It's fixed in the uWSGI master (2.1-dev). Creating an issue with them probably won't do much since it was already reported previously. See [1].


mitchhentges commented on 2016-05-08 04:50

Aww, you beat me to it. I should've checked here before investigating from scratch. Yep, I'm using GCC 6.1.1, and uWSGI's -Werror flag is killing the build. I've created an issue for uWSGI[1], but there's not much that they can do except release the next build


zancarius commented on 2016-05-08 04:41

Some observations, but first I'd like to apologize for spamming those of you who may have been subscribed to notifications on this package. It's important we get this resolved in the event someone else encounters similar issues.

I know what the issue is now, but I don't yet have a fix. If you have updated recently, say within the last 3-4 days, you will be affected by this, and you will not be able to build Sentry.

- GCC was recently updated to 6.1.x on Arch. This version will warn about misleading indentation, but the warning allegedly isn't enabled by default [1]. However, the uWSGI package enables -Wall and -Werror. It's possible as of GCC 6.1 that these errors may have been enabled.

- Unfortunately, uWSGI isn't the only package the fails with GCC 6.1. lxml will also fail but for different reasons.

- Sentry 8.4.0 depends on uWSGI > 2.0.0 and < 2.1.0. It appears to be pulling down 2.0.12, <strike-this> which has the fix in the linked issue, but still causes a failure related to misleading indentation </strike-this> which does NOT have the fix. I'm suspicious -Wall must be enabled by default.

So, the problem is entirely due to GCC 6.1 refusing to compile uWSGI and lxml. I don't presently have a workaround.

If you haven't updated your Arch install yet and you're still running GCC 5.3, I'd advise sticking with it for the time being. Otherwise, if you must build Sentry and you're running GCC 6.1, your only option at this point might be to downgrade GCC briefly (or use a systemd-nspawn container to downgrade, build Sentry, and copy it from there. See [2] for instructions on creating an nspawn-backed "chroot" or [3] if you'd rather boot into a clean Arch environment you could downgrade (use --bind=/var/cache/pacman/pkg:/var/cache/pacman/pkg if using #3 so you can have access to your previously downloaded packages if available).


(Edited to add missing footnote and clarification on the note about GCC.)

Further notes:

Adding CFLAGS="-Wno-misleading-indentation" will fix the build issues with Sentry. This will not fix lxml.

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)

Mastacheata commented on 2016-04-20 01:16

You already accounted for the config.yml file to be present, but you seem to have missed the adjustment of the config parameter.

In order for settings in config.yml to be applied, sentry must be started with the config parameter set to the parent directory. (/etc/sentry in this case)
Previously you had to set this to the file.

Even though the config.yml doesn't do that much harm to this date (they simply haven't migrated any of the critical settings there yet), it caused me a major headache to find out why my sentry was ignoring the mail.use-tls setting entered in the config.yml while adhering to the EMAIL_USE_TLS directive in the (with the downside of having a deprecation notice on top of the sentry webinterface).

I submitted a PR to your github repo.

mitchhentges commented on 2016-04-12 19:47

These are really good points. That makes sense, thanks guys!

zancarius commented on 2016-04-12 17:23

It's my belief that automatically applying database migrations is the antithesis of Arch philosophy (although there are counter-examples to this). In addition to the reasons codekoala touched on, it's generally a good idea to backup your existing database prior to upgrading, and I can't see an effective way to do this automatically with the tools Sentry provides in a manner that would appease all users (multiple DBMS support, backup placement, etc).

Having said that, the GitLab PKGBUILD in the AUR [1] is the only one I'm aware of that actively applies database migrations, handles backups, etc., during the upgrade process. GitLab is a fairly complex system to install, but being being a RoR app it provides a few helpful utilities for doing much of this automatically (including backups) and is therefore relatively self-contained (to the best of my knowledge, Sentry only provides migration support out of the box). However, I'm not completely convinced the extra complexity in a PKGBUILD install script is warranted. It's more to maintain, it's more that requires testing following each upgrade, and a failure of the upgrade process could be harmful to your data. I've had Sentry migrations fail (6.x or 7.x to 8.x failures) or halt when they want to remove unused roles, requiring manual intervention anyway.

I guess this is just a long-winded way of saying that my philosophy is analogous to what codekoala touched on: I see the PKGBUILD and its install/upgrade process as a way of installing (or updating) the application. I'm reluctant to touch your data as I feel that's your responsibility. I can't account for all use cases where Sentry is installed, and some of the larger deployments generally require planning before an upgrade. Automatically doing *anything* could introduce errors into this process, so I took the more conservative route of printing (hopefully) helpful notices following an upgrade detailing what you need to do before restarting Sentry (and reminding you to take backups of your database!).

Incidentally, the official PostgreSQL packages don't upgrade your installed databases automatically either, as an example of an official package and its behavior. You're expected to install postgresql-old-upgrade and follow the instructions on the wiki [2]. Hence, I believe this PKGBUILD follows more closely with the official philosophy, of which I can think of no examples that do anything without manual intervention (this is why I dislike Debian distributions--they start services automatically after installation without so much as a chance to configure them).

You're welcome to create an issue on the GitHub repository containing this PKGBUILD [3] where we can discuss this further. I'm open to making things easier (perhaps the instructions we print following an upgrade are too verbose and need to be rendered more concise?), but I also hesitate to do anything that might cause headaches for deployments that have already been installed and may have automated tooling and review processes that assist them during an upgrade.


codekoala commented on 2016-04-12 15:48

Here's another scenario: let's say you upgrade a database from one major version to another. For example, if you upgraded PostgreSQL 9.4 to 9.5, would you want the package to worry about migrating all of your data to the new version's format? While it would be convenient, it could be a very destructive operation that you'd want more control over. Say you have custom extensions for 9.4 that have not yet been updated or compiled/installed for 9.5. Bad things would happen, and you'd likely lose data.

Upgrades dealing with data are generally left to be manual operations. The migration command that sentry provides is about as automatic as I'd personally prefer to see. In the case of Firefox, it upgrades itself regardless of platform. It's built into Firefox, not into the Arch package.

mitchhentges commented on 2016-04-12 15:42

Does it go against the Arch way? Looking at the functions that are allowed in the install script, it appears that handling upgrades are one of the core features of a PKGBUILD [0] (install, upgrade, remove).

I'd argue that this isn't the same as enabling or starting services, because running an upgrade script is strictly a one-time operation. I feel that it's very similar to an install script.

Finally, or paying attention to what's being installed or upgraded: this is the only package that I have needed to manually execute a command for upon the application being upgraded. Whenever I upgrade Firefox, I don't need to manually make it update its local schema.

At the same time, I'm not maintaining my own AUR packages, so this is mostly an outside opinion. Perhaps there are other packages which require manual upgrades.


codekoala commented on 2016-04-12 14:35

@mitchhentges it's certainly possible, but it goes against the arch way. No (official) packages that I'm aware of automatically enable/start services, and this falls into the same category in my opinion.

The expectation for us as arch users is that we pay attention to what's being installed or upgraded. The informative message that this package already provides after installation is exactly what it should be.

mitchhentges commented on 2016-04-12 12:23

Is it possible to run a script on upgrade? It took me a little bit to realize that all my requests were failing: turned out I needed to run
./bin/sentry --config /etc/sentry/ upgrade

It would be awesome if this package could run this command itself.

zancarius commented on 2016-04-11 07:30

I'll be posting the updated PKGBUILD tomorrow 20160411, possibly around noon (MDT). I haven't had time yet to examine some of the upstream changes including uWSGI's new "die-on-term" option. The "correct" solution is to probably continue sending a SIGINT until uWSGI 2.1 is released and Sentry updates to it.

zancarius commented on 2016-03-15 19:11

Okay, bumped version to 8.2.3, including @mitchhentges' SIGINT fix for uWSGI. If uWSGI changes this behavior, it might be necessary to remove this in the future. Thus, a healthy dose of caution is required for each update from this point onward.

We may consider moving to systemd.targets for Sentry. I was considering adding that in this patch, but it occurred to me that the possibility of using different DBMSes causes a bit of a problem insofar as target dependencies go (and I'm not sure what the best solution is in this case).

On the other hand, is launching two separate services (sentry + sentry-celery) problematic/annoying enough to warrant a

zancarius commented on 2016-03-15 16:52

Oh gosh, I'm an idiot. I've been working with uWSGI, too, for some of my own projects and ran into this exact issue, but apparently the idea never once occurred to me to add this to the unit files for Sentry.

I have absolutely nothing in my defense other than to say that reading the uWSGI docs for unrelated reasons sometime in the last month or two must've flushed that *weird* behavior out of my conscious memory.

Good catch, @mitchhentges, and great detective work! I'm thinking the systemd unit fix is the best option!

I'll be getting to your PR later today when I have some time. Thanks!

mitchhentges commented on 2016-03-15 15:02

I've submitted a PR to Sentry[0], you might not need my patch if it's in when you update this package.


mitchhentges commented on 2016-03-15 13:34

I've got a sick patch for fixing `systemctl stop sentry`:

See for details

mitchhentges commented on 2016-03-15 11:50

Awesome package! Two small issues:
* `systemctl stop sentry` doesn't actually stop the service, and just hangs. Not sure if that's a sentry bug, or an issue with this AUR itself. Sorry for my lack of knowledge, I'm getting there ;)
* Sentry 8.2.3 is out!

zancarius commented on 2015-09-10 06:08

Addendum to my previous post: It would appear that the sentry.tasks.check_alerts error is only likely to appear if you've forgotten to regenerate your Sentry configuration (sentry init).

Thusfar, I'm not aware of any other causes.

zancarius commented on 2015-09-09 06:06

When upgrading to Sentry 7.7.0, you may notice celerybeat warnings containing the following:

> KeyError: 'sentry.tasks.check_alerts'

It appears this task has been removed in recent versions of Sentry and the error can be ignored [1][2].


If it's particularly noisome, ask upstream and send me a pull request (on the Github repo) if you run across a workaround/fix. Otherwise, wait until a later version resolves the warning.

zancarius commented on 2015-08-18 20:51

Okay, PKGREL 7.7.0-2 should function normally.

Rather than downloading the tarball and installing from there, we automate the installation process using pip to ensure necessary dependencies are pulled down. I'm not *quite* sure why this was failing with the tarball from PyPI (same thing, right?), but running the contained from the PKGBUILD was ignoring certain dependencies Sentry needed.

Either way, it probably doesn't matter. I've long been considering automating the installation via pip but needed something of a kick to do so.


zancarius commented on 2015-08-18 20:36

The current PKGREL (7.7.0-1) is broken. I'm in the process of figuring out a solution since the PyPI package refuses to install all of the appropriate dependencies. (I have a better idea in mind than the current method of distribution, but it requires some testing first.)

zancarius commented on 2015-07-25 20:16

The Sentry 7.6.x branch is no longer linked from Sentry's PyPI landing page likely due to some of the requirements listed in the project's CHANGES [1]. The problem is, I've since updated this package to v7.6.0.

Since I'm not interested in maintaining two different versions of Sentry in the AUR, and neither am I interested in downgrading the package (the intent is to follow the latest version available), I want you to be mindful of this particular quote from the CHANGES file before upgrading:

> This releases entirely removes Access Groups. If you're upgrading
> form [sic] an installation that had yet to migrate away from this
> system you should first upgrade to a previous version, run the
> migration wizard, and then continue the upgrade.

If this applies to you, you may need to manually upgrade sentry (using pip) before upgrading to the latest version in the AUR:

$ cd /opt/sentry
$ source ./bin/activate
$ sudo pip install --upgrade sentry==7.5.6

(It might be necessary to substitute the version, 7.5.6, with later versions of the Sentry 7.5.x branch as appropriate.)

If this does not apply to you, continue your upgrade as per usual. In most cases, you should be able to upgrade from the previous version (7.5.4) without trouble (I did).


zancarius commented on 2015-03-22 22:40

Updated to Sentry 7.4.1. Sorry about the delay. I don't have my version check script running periodically and haven't gotten around to fix it.

Here's a couple of things I've observed that may be worth taking note of:

Be aware that the upgrade process will now complain if you haven't set SENTRY_ADMIN_EMAIL. It doesn't do any harm, but now is probably a good time to set this configuration if you haven't already. If the Sentry developers think it's important enough to warn about, it's probably important enough to configure!

Also, note that the package dependencies should probably include OpenSSL. I haven't added that to the PKGBUILD yet, but then most systems will probably have it installed anyway...

Unfortunately, one of the side effects of building against OpenSSL means that if you're building or planning to build Sentry for mass deployment, you must ensure you have ABI compatible versions of OpenSSL between your build host and all of your targets. If not, you'll receive something like "cffi.ffiplatform.VerificationError" during start. This will even affect the virtualenv once you've upgraded Sentry (and you won't be able to run pip from there until you do, if you have other packages you want to add to Sentry).

Make sure you've also upgraded pip and setuptools to their latest versions.

Cheers, folks.

codekoala commented on 2015-02-06 05:00

Very nice work on this. So very thorough!

zancarius commented on 2015-02-05 22:32

The Sentry package has now been updated to 7.1.4. I've caught a few mistakes made during the process and have corrected everything I could find. Of course, this means there may remain a few issues, but the lion's share of them have been squashed. My stupidity and oversight knows no bounds, so be cautious during the upgrade process and backup your database first.

A few notable changes from this update:

- Sentry now REQUIRES Celery to run separately. This was reported by @codekoala and appears to be a major change fairly recently (6.x -> 7.x). Previous versions of Sentry could be used without an immediate need for configuring (or running) Celery separately, and I naïvely believed this to be the case when I first released the Sentry 7.1.1 PKGBUILD. As a result, Sentry has a non-negotiable dependency on Redis. Celery runs via the sentry-celery systemd unit and will be started automatically when starting sentry, though it's advisable to enable both (`systemctl enable sentry sentry-celery`).

- You MUST perform a database migration, regardless of which version you're upgrading from:

sudo -u sentry /opt/sentry/bin/sentry --config=/etc/sentry/ upgrade

- The Sentry configuration has been updated rather dramatically. If you're migrating from an earlier version (6.x), you MUST import these changes into your existing configuration or overwrite it with the new version. `vimdiff /etc/sentry/ /etc/sentry/` is sufficient. However, do not overwrite your SECRET_KEY that was generated the first time you installed Sentry unless you want to invalidate existing logins and possibly create other unexpected side effects. Be absolutely certain that 1) the queue has been configured (usually uncommenting CELERY_ALWAYS_EAGER and BROKER_URL is enough depending on your requirements) and 2) your configuration contains entries for the TSDB. Failure to update your configuration will prevent Sentry from accumulating new events.

This version of the package should install a fully functional version of Sentry that uses SQLite as its database store. As you'll find when installation completes, if you're planning on using MySQL or PostgreSQL as your backend, you will need to install those drivers into Sentry's virtualenv. I may eventually look into options allowing users of this package to install them via pacman, but Sentry has such an incredibly detailed list of upstream dependencies, I'm reluctant to do so as it's easier for you and me both to use the created virtualenv. Bugging upstream maintainers for weeks on end and trying to upload dozens of package versions myself, keeping them in sync with Sentry's requirements was a colossal PITA that I'd rather not repeat. :)

To install MySQL or PostgreSQL support will require you to do either of the following:

sudo -u sentry -- /usr/bin/bash -c \\
'source /opt/sentry/bin/activate && /opt/sentry/bin/pip install mysql-python'

# PostgreSQL
sudo -u sentry -- /usr/bin/bash -c \\
'source /opt/sentry/bin/activate && /opt/sentry/bin/pip install psycopg2'

(This is noted in the post-installation/post-upgrade message as well.)

During this upgrade, if you're migrating from earlier versions, you'll notice a large number of ownership and/or permission warnings generated by pacman. This is due to a fairly significant change in pacman 4.2. I've corrected this by changing ownership of all the respective files to root:root, as pacman expects. Configuration files and those directories that sentry must write to are now the only things actively changed to the sentry user's ownership.

Subsequent upgrades may notice an error regarding /opt/sentry/.python-eggs. This directory is currently created by the PKGBUILD itself and later chown'd to the sentry user; pacman doesn't like this, but the message is itself harmless. I may move this logic into the installation scripts since it's a location used at runtime by Sentry and isn't used (or required) by the installation process.

Please report issues with this package here or open a new ticket [1] should you encounter problems.


codekoala commented on 2015-02-05 19:01

Perhaps it would make sense to add another systemd service to this package to handle running the celery worker? That was the biggest hurdle I had while playing with sentry this morning. It took me a while to figure out that, by default, the events only appear in the web UI after celery processes them.

What do you think?

zancarius commented on 2015-02-05 17:12

Thanks for the kind words @codekoala! They're very much appreciated!

I'm in the process of updating it now. The current version of pacman appears to complain about package ownership, if you're upgrading, so I need to implement a workaround.

The package should be updated to 7.1.4 later today after testing, etc.

codekoala commented on 2015-02-05 17:08

This is a great package! I've always been scared off from installing sentry in the past, but this makes it incredibly simple. Thanks for putting the time and effort into it :)

zancarius commented on 2014-02-20 17:29

Whoops. Apparently I've been sitting on the updated PKGBUILD for about a month and a half. I guess I need to tweak my update scripts to periodically alert me if my repo and my AUR packages are out of sync.

Sorry folks!

zancarius commented on 2013-09-30 07:40

I apologize that it took me some time to update this package. I have no other excuse than I forgot and have been distracted with other obligations!

zancarius commented on 2013-07-24 20:10

I've made some fixes to the PKGBUILD so /opt/sentry/bin/activate should now be usable if you wish to use pip to install packages from PyPI (such as MySQL or PostgreSQL support or any of the various Sentry plugins now available). I've also (hopefully!) clarified the instructions that get spit out from sentry.install. If you have issues, please report them here!

zancarius commented on 2013-04-10 07:32

Added --relocatable as per Abram's suggestion and fixed some additional issues related to the manner in which Sentry is built. This *should* fix Sentry (finally?), and the install script now contains additional information. The service file has been updated to (correctly) use the appropriate environment, so you'll likely need to issue:

systemctl --system daemon-reload

if you're upgrading.

Also of importance: Neither mysql-python nor psycopg2 are installed by default now since the virtualenv does not (and cannot) rely on the system's site-packages. Instructions for adding MySQL or PostgreSQL support are now included in sentry.install (and should display whether you're installing fresh or upgrading). You will probably need to install these by hand following each upgrade, if you need them.

If you have upgraded from a much earlier version and are using MySQL, you may encounter problems with a few of the socialauth tables (specifically social_auth_usersocialauth, social_auth_nonce, and social_auth_association). The only options may be to migrate these by hand or drop them. PostgreSQL shouldn't be affected.

As always, be sure to create backups of your Sentry database prior to installation. I've tested installation on a couple of Arch machines without issue (but did not try anything prior to 5.1), so if you have further problems with this PKGBUILD, please leave a comment and any relevant error messages. I'll try to fix it as soon as I am able.

Abram commented on 2013-04-09 13:19

Please add
virtualenv2 --relocatable "${pkgdir}/opt/sentry"
at the end of build()

zancarius commented on 2012-11-09 20:52

python-anyjson has been changed to python2-anyjson. Please update python-anyjson (the Python 3 package) or uninstall Sentry and python-anyjson first, otherwise you'll encounter file system conflicts when updating Sentry and its dependencies.