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-05-24 19:03 (UTC)

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

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

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

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

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

You're also going to have problems building lxml.

zancarius commented on 2016-05-08 04:53 (UTC)

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

mitchhentges commented on 2016-05-08 04:50 (UTC)

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 [1] https://github.com/unbit/uwsgi/issues/1247

zancarius commented on 2016-05-08 04:41 (UTC) (edited on 2016-05-08 04:51 (UTC) by zancarius)

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). [1] https://www.phoronix.com/scan.php?page=news_item&px=GCC6-Misleading-Indentation [2] https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot [3] https://wiki.archlinux.org/index.php/Systemd-nspawn (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 (UTC)

This looks to be related to your problem: https://github.com/unbit/uwsgi/issues/1162 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?

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