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.000092
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 1 2 3 4 5 6 7 8 9 10 11 Next › Last »

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 setup.py. 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 setup.py 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 https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=swift-development 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?

https://gist.github.com/zancarius/5cd9b793919be6e26741cd87a4ee7241

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.

Thanks.

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

[1] https://github.com/unbit/uwsgi/issues/1162