Package Details: sentry 23.3.1-3

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
Keywords: sentry
Licenses: BSD
Submitter: zancarius
Maintainer: sergej
Last Packager: sergej
Votes: 14
Popularity: 0.000000
First Submitted: 2012-11-04 17:15 (UTC)
Last Updated: 2023-04-02 00:25 (UTC)

Dependencies (12)

Required by (0)

Sources (8)

Latest Comments

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

zancarius commented on 2016-06-06 17:00 (UTC) (edited on 2016-06-06 17:05 (UTC) by zancarius)

@mitchhentges: 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 (UTC) (edited on 2016-06-06 09:35 (UTC) by mitchhentges)

I'm getting an error when building: Traceback (most recent call last): File "<string>", line 1, in <module> File "/tmp/pip-build-cuM9f7/Pillow/setup.py", line 767, in <module> zip_safe=not debug_build(), ) File "/usr/lib64/python2.7/distutils/core.py", line 151, in setup dist.run_commands() File "/usr/lib64/python2.7/distutils/dist.py", line 953, in run_commands self.run_command(cmd) File "/usr/lib64/python2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/tmp/yaourt-tmp-mitch/aur-sentry/pkg/sentry/opt/sentry/lib/python2.7/site-packages/setuptools/command/install.py", line 61, in run return orig.install.run(self) File "/usr/lib64/python2.7/distutils/command/install.py", line 563, in run self.run_command('build') File "/usr/lib64/python2.7/distutils/cmd.py", line 326, in run_command self.distribution.run_command(command) File "/usr/lib64/python2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/usr/lib64/python2.7/distutils/command/build.py", line 127, in run self.run_command(cmd_name) File "/usr/lib64/python2.7/distutils/cmd.py", line 326, in run_command self.distribution.run_command(command) File "/usr/lib64/python2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/usr/lib64/python2.7/distutils/command/build_ext.py", line 339, in run self.build_extensions() File "/tmp/pip-build-cuM9f7/Pillow/setup.py", 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 (UTC)

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]. [1] https://github.com/zancarius/archlinux-pkgbuilds

zancarius commented on 2016-06-06 04:41 (UTC)

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 sentry.target 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 (UTC)

@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. [1] https://github.com/zancarius/archlinux-pkgbuilds/blob/0fbdb300ae5325a558766ef88f482a19c7e6011a/sentry/PKGBUILD

zancarius commented on 2016-05-24 22:59 (UTC)

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. [1] https://github.com/zancarius/archlinux-pkgbuilds/issues/7

zancarius commented on 2016-05-24 20:34 (UTC)

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 (UTC)

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 (UTC) (edited on 2016-05-24 20:31 (UTC) by zancarius)

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 (UTC)

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.

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