Package Details: sentry 9.1.2-1

Git Clone URL: https://aur.archlinux.org/sentry.git (read-only, click to copy)
Package Base: sentry
Description: Python-based realtime logging and aggregation server.
Upstream URL: http://pypi.python.org/pypi/sentry
Licenses: BSD
Submitter: zancarius
Maintainer: zancarius
Last Packager: zancarius
Votes: 14
Popularity: 0.000012
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

1 2 3 4 5 6 ... Next › Last »

zancarius commented on 2021-05-02 18:03

@dreieck:

Can you move all the download stuff which is now in package() into prepare()?

What is your use case?

(Do consider reading the lengthy treatise that follows; it explains my reasoning in detail.)

Even better, to use source-array.

No.

There are reasons for the choices that you find made in this PKGBUILD.

This PKGBUILD has a long and storied history regarding the violence that I have committed against it, and specifically, there was a point in time about 6 years ago(!)[1] where this package did exactly what you described, defining the package sources in the source=() array, downloading, and then installing it. There was even a point where I was polite enough to use depends=()!

The months prior to [1] lead to a growing degree of frustration. The Sentry developers have long pinned Sentry to specific versions of its dependencies which would require me to pester 4 or 5 other maintainers of packages in the AUR to update their PKGBUILDs. Or I would have to maintain version-specific packages in order for Sentry to build.

Obviously, I could have modified the requirements.txt for this package to remove the "==" version checks, but as I'm not familiar with the Sentry code base, I have no idea which or whether any versions beyond the ones required by Sentry would work. I have at least had some experience with a handful of these packages outright causing Sentry to fail by attempting to use the newest one available in either [extra] or [community]; and I have some vague recollections that attempting to use older packages from the AUR was a no-go.

You'll also notice in [1] that there was still a lingering call to pip to install "pytest"; I don't remember the exact reasons for this specific package, but in all likelihood it was either missing from the AUR at that time or Sentry pinned a version that was not available in any other repo.

So what do you do?

In the changes I made immediately following [1], I dropped using the Sentry source package and opted to use pip instead[2], because chasing down so many AUR maintainers (some of whom stopped responding to my posts!) was quickly becoming a waste of time. For a package as complex as Sentry, I made the decision that a dependency on pip to install Sentry into a venv, wrapping that venv up into a package, and packaging that was the most efficient use of my time.

Now, having said that, the Sentry package is currently flagged as out-of-date and this status is unlikely to change. I would STRONGLY advise that you do not use this package (I've left it here for historical reasons, but it may be removed at any point; this comment serving as a reminder to that end) and opt instead for the Docker image officially supported by the Sentry team.

You really should use the official upstream Docker image. Honest.

If you'd rather build it from the PKGBUILD instead, I would be happy to include another maintainer or pass off maintenance to someone who's willing to do the legwork, but you will quickly discover--as I have--any or all of the following:

1) Following accepted guidance by splitting the package into separate prepare(), build(), and package() functions sounds like a great idea, but if you're relying on configuring the source=() array and shifting all of the dependencies Sentry requires to depends=(), you're going to waste a substantial amount of time chasing down package versions that don't match, editing the requirements.txt, or any of the previous. Sometimes it may even build.

2) Sentry 10+ no longer builds on non-Intel systems due to a hard dependency on Clickhouse. The Clickhouse packages are often either out of date or require patching their cmake configuration to get it to build on non-Intel (AMD...) machines because of some stupid flag choices. You may be able to optionally work around this by using the Clickhouse Docker image, but after discussing the possibility with other users of the Sentry package (in particular Mitchell Hentges who helped me substantially with this over the years!), we came to the conclusion that forcing Docker on users was probably not worth it for a single dependency when Sentry offers a Docker image that rolls everything (including Clickhouse) up into a single package. I'm not sure there's much value in doing this.

Hopefully this essay explains why the Sentry PKGBUILD commits the rather heinous act of using pip instead of doing the polite thing and allowing re-use of already installed dependencies!

Thank you for your comment!

[1] https://github.com/zancarius/archlinux-pkgbuilds/blob/2090e6a1e0cb006677c4689cf0b58d1e47bafc2a/sentry/PKGBUILD

[2] https://github.com/zancarius/archlinux-pkgbuilds/commit/0bc8127cbf02b730a6b7fe5050dcd8038df594d8#diff-0cf6855c1a3c323bfb9d788f7a55f0ce6cc765b2922c247c28ea21babf00c919

dreieck commented on 2021-05-02 10:21

Can you move all the download stuff which is now in package() into prepare()?

Even better, to use source-array. Python packages can usually also be downloaded via makepkg's builtin download functions, integretiy checksum checked, and built and installed with python-setuptools. No another package manager (pip) required.

Thanks for maintaining!

zancarius commented on 2020-03-01 07:53

Thanks for the feedback, Mitch! And I agree, I think #2 is probably the best option.

As is probably apparent from the most recent stickied post, there doesn't appear to be a way forward with option #1 and option #3 is encouraging use of no-longer-maintained-software. It's not ideal but it is what it is. Sentry is updating according to their needs, and if it aligns with ours--all the better. If not, well, there's not much we can do!

I'm somewhat reluctant to orphan or request deletion for this package quite yet in the hopes that Clickhouse will (eventually) be fixed, but because it's an issue with one of Intel's packages not building they're more or less blocked by an upstream dependency themselves. I suspect they're not hugely interested in resolving this either since they also offer a Docker image. Sigh.

There was also a discussion on the AUR mailing list from one of the Clickhouse maintainers that hinted to me that I shouldn't be expecting much movement on this matter either as there were some criticisms raised related to the PKGBUILDs that remain unaddressed AFAIK. Regardless, I'll keep an eye out, but I think it's best to assume this package will be retired and eventually deleted.

There's really not much any of us can do about it at this point, and I greatly appreciate your feedback and assistance over the years. Thanks again, Mitch!

mitchhentges commented on 2020-03-01 07:44

Thanks for the update zancarius! It's been a good run, and thanks for the hard work maintaining this :)

Out of these options, I'd lean towards option 2, since it sounds like corralling all the upstreams into something usable would be tricky.

My 14yo server that was running Sentry won't quite cut it anymore if Docker is involved, but hey, it was 14 years old, maybe it's time for it to retire ;)

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.

zancarius commented on 2019-04-23 21:03

I have updated Sentry to v9.1.1. This update is noteworthy and may require some changes during install or upgrade if you're planning on moving Sentry to a different system.

First, I have cleaned up several dependencies. In particular, Redis is still required, but I've opted to move it to the "optdepends" declaration for those who are running Sentry on a system separate from their Redis server or may be running Sentry in a systemd-nspawn container (I'm doing the latter). If you're installing Sentry for the first time and ignore the installation instructions, you may discover sentry-celery fails to start. If so, this is probably the reason.

Second, LLVM has also been moved into the "optdepends" array as it may not be required for everyone. In particular, LLVM is only necessary if you require dsym parsing. For users authoring software in Xcode, compiling with LLVM, or writing Rust, you will likely require LLVM to be installed alongside your Sentry instance (i.e. LLVM will need to be installed on the same system). This is an improvement for users who may not have this requirement as LLVM can pull in several related libraries.

Finally, I've removed the package ncurses5-compat-libs from the dependencies as it appears it is no longer needed. I've done some preliminary searching through the code base to validate this decision and have installed Sentry on some test containers, and I believe this to be true. If you encounter issues, verify that you have ncurses (from the official Arch repos) installed first before trying to install the old ncurses5 compatibility library. If you already have it installed, you may remove it.

If you encounter other issues with this particular release, please post them here. I don't expect you will, but there is a possibility as several old dependencies have been removed and the PKGBUILD has seen a small amount of cleanup. The installation and upgrade instructions have also been cleaned up, improved, and old information removed.

zancarius commented on 2019-04-04 08:05

Sentry updated to 9.1.0. Some manual intervention may be required:

In particular, during the update process, pacman may complain about the file "/opt/sentry/lib/python2.7/ntpath.pyc"; remove this before continuing.

I'll soon be exploring the possibility of changing this package to depend on Python 3.x rather than Python 2.7. At present, some of the libraries Sentry depends on will fail during the build process (BeautifulSoup 3.x has one or more unit tests that fail). I will try to keep this migration as painless as possible, but bear in mind that you may need to upgrade to the new interpreter if you haven't already. Python 2.7 will be deprecated at the start of 2020.

zancarius commented on 2018-07-14 04:44

Sentry updated to 9.0.0. You may notice an error akin to:

duplicate key value violates unique constraint "sentry_environmentproject_project_id_29250c1307d3722b_uniq"

This appears to be part of Sentry's normal operation as per #8004 [1].

Be aware that building this PKGBUILD on a machine that isn't in sync with the Sentry host may potentially create a package where uWSGI expects differing versions of glibc or libicu*. Your build and Sentry hosts should always be either 1) updated or 2) in sync.

[1] https://github.com/getsentry/sentry/issues/8004

zancarius commented on 2017-12-24 22:20

I'll release another pkgrel tonight (possibly) with a patch for Sentry's requirements as it appears upstream still has psycopg2>=2.6.0,<2.7.0[1]. I wasn't able to find an active ticket on their repository, either, so feel free to submit one.

[1] https://github.com/getsentry/sentry/blob/ee10875b2649a80e221a5df9a2db675e00d5c3e6/requirements-base.txt#L32