Arch Linux User Repository

I've got a sick patch for fixing `systemctl stop sentry`: http://hastebin.com/adoxupikiv.avrasm See https://github.com/getsentry/sentry/issues/2845 for details

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! https://github.com/getsentry/sentry/releases/tag/8.2.3

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.

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]. [1] https://github.com/getsentry/sentry/issues/1665 [2] https://github.com/getsentry/sentry/issues/1584 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.

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 setup.py 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. Enjoy.

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.)

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). [1] https://github.com/getsentry/sentry/blob/7.6.2/CHANGES

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.

Very nice work on this. So very thorough!

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/sentry.conf.py 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/sentry.conf.py /etc/sentry/sentry.conf.py.pacnew` 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: # MySQL 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. [1] https://github.com/zancarius/archlinux-pkgbuilds