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

zancarius commented on 2016-05-08 01:27 (UTC)

Okay, I can't replicate the problem on a few systems even with -Werror in my CFLAGS (though I was able to make lxml fail to build). I'd suggest looking at your /etc/makepkg.conf for starters--perhaps comparing it with the stock config from your local pacman package. Also examine your environment; in all likelihood, something is causing your gcc to bail on warnings.

zancarius commented on 2016-05-08 00:50 (UTC)

Builds fine for me. The problem appears to be with uWSGI. What happens if you install it separately, e.g.: virtualenv2 ~/.test-env source ~/.test-env/bin/activate ~/.test-env/bin/pip install uwsgi If I'm not mistaken, this looks like it might be an issue with your CFLAGS or similar? In particular this part (probably triggered by -Werror=misleading-indentation): >> cc1: all warnings being treated as errors

mitchhentges commented on 2016-05-08 00:41 (UTC)

Unfortunately, Sentry 8.4.0 doesn't seem to want to build. I'm assuming that this would be an issue with Sentry itself? [thread 5][gcc -pthread] plugins/http/keepalive.o [thread 6][gcc -pthread] plugins/http/https.o [thread 7][gcc -pthread] plugins/http/spdy3.o [thread 0][gcc -pthread] plugins/ugreen/ugreen.o [thread 2][gcc -pthread] plugins/signal/signal_plugin.o [thread 1][gcc -pthread] plugins/syslog/syslog_plugin.o [thread 3][gcc -pthread] plugins/rsyslog/rsyslog_plugin.o plugins/corerouter/cr_map.c: In function ‘uwsgi_cr_map_use_static_nodes’: plugins/corerouter/cr_map.c:156:5: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation] if (!next_node) ^~ plugins/corerouter/cr_map.c:159:6: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘if’ while (tmp_node != next_node) { ^~~~~ [thread 2][gcc -pthread] plugins/logsocket/logsocket_plugin.o [thread 1][gcc -pthread] plugins/router_uwsgi/router_uwsgi.o [thread 5][gcc -pthread] plugins/router_redirect/router_redirect.o cc1: all warnings being treated as errors ---------------------------------------- Command "/tmp/yaourt-tmp-mitch/aur-sentry/pkg/sentry/opt/sentry/bin/python2.7 -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-nXNUr8/uwsgi/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-n3_YP1-record/install-record.txt --single-version-externally-managed --compile --install-headers /tmp/yaourt-tmp-mitch/aur-sentry/pkg/sentry/opt/sentry/include/site/python2.7/uwsgi" failed with error code 1 in /tmp/pip-build-nXNUr8/uwsgi/ ==> ERROR: A failure occurred in package(). Aborting... ==> ERROR: Makepkg was unable to build sentry.

Mastacheata commented on 2016-04-20 12:16 (UTC)

Ohh, sorry. To me it looked like you read my comment and thought migration as in migrate away. (Which is a very common misconception if you encounter that term for the first time) > At present, I can't find any immediate need to migrate specific configuration values from the old `sentry.conf.py` style config with the exception of Redis (a recent addition). The Mail settings are even more important. Redis can still be configured in the sentry.conf.py without the UI complaining, but if you configure the mail settings in the python file, you'll get deprecation notices in the Web Interface.

zancarius commented on 2016-04-20 03:35 (UTC)

Okay, I've pushed the new PKGBUILD (same version; the `pkgrel` is the only thing that's changed). If you're coming upon the comments here because you're somewhat perplexed or concerned about the deprecation of MySQL support as indicated in the upgrade notes, you'll need to read the official stance in the Sentry changelog for 8.0 [1]. There isn't much we can do about this, and you'll need to plan accordingly. I've linked some tools in the upgrade text that might help you but bear in mind that using them is completely unsupported. In addition, you're strongly encouraged to read the PostgreSQL user's guide which details migrating your data from MySQL to Postgres, concerns, and likely problems [2] (it's possible but only you can decide if it's worth the effort). There are other scripts out there that can assist you with migrating your data, but I'll leave using them as an exercise to the reader. I'm reluctant to get into the politics of it here, but you really ought to use a Real™ DBMS if you're not already--in particular, PostgreSQL has support for DDL changes within a transaction, making schema migrations relatively painless if something should go wrong (MySQL doesn't and therefore has the propensity to cause many sleepless nights--ask me how I know). Otherwise, thanks to the efforts of mastacheata, the last vestiges of our Sentry package's dependencies on the old configuration style are mostly on their way out. You still have to use it, but the initialization process and instructions have been updated accordingly. (Note: The official documentation uses envvars for conveying configuration location; I'm yet undecided whether or not we'll end up using those instead.) At present, I can't find any immediate need to migrate specific configuration values from the old `sentry.conf.py` style config with the exception of Redis (a recent addition). If this concerns you, you may want to generate a new configuration using `sudo -u /opt/sentry/bin/sentry init` where appropriate or follow the upgrade instructions. Be aware that you'll need to keep your secret key (now contained in /etc/sentry/config.yml), otherwise all of your existing login sessions are likely to fail. As usual, I cannot stress enough the necessity of backing-up your database and test the installation on a development machine before deploying this package. If you encounter difficulties, post them here or open a ticket on the repository containing this PKGBUILD [3]. [1] http://blog.getsentry.com/2016/01/08/sentry-8-on-premise.html [2] https://wiki.postgresql.org/wiki/How_to_make_a_proper_migration_from_MySQL_to_PostgreSQL [3] https://github.com/zancarius/archlinux-pkgbuilds

zancarius commented on 2016-04-20 02:42 (UTC)

*face palm* I'm well aware of what what migrations are (currently, I'm developing some relatively large Flask-based applications with my preference being SQLAlchemy), but there are tools to migrate data away from different DBMSes (with different degrees of success). Hence the link in my earlier comment. In this context, though, I'm referring to migrating 1) existing configurations (this needs research) and 2) possible options for migrating data away from MySQL for those users who may have done that. I'm not referring to schema migrations. Perhaps the appropriate term is "export" but you're still dealing with migrating data away from one platform on onto another. For what it's worth, I've actually been running Sentry under MySQL for quite some time. The Django ORM and Sentry's existing migration utilities and libraries have been working fine for this purpose (with the exception of one or two changes I've had to make recently to individual migrations).

Mastacheata commented on 2016-04-20 02:32 (UTC)

Re 2) Migration has nothing to do with switching database systems in this context. A migration is basically a script or program that performs changes on the database (structure). Basically these scripts are built so that you can have a version control for your project's database structure. For more information see here: https://en.m.wikipedia.org/wiki/Schema_migration Sentry is known for modifying their database structure very often. These changes between program versions would usually be performed by the upgrade command. However as of sentry 7 only changes to postgres are automated (run upgrade command and be happy). You CAN continue to use mysql or sqlite since the code for reading and storing data is pretty easy to keep platform independent. But you need to perform any changes made to the postgres structure in your mysql or sqlite db by hand. (i.e. Rename column x in table y or change the data type or add a new index, or or or) Thanks for looking into this so quickly.

zancarius commented on 2016-04-20 01:32 (UTC)

1) I'm currently looking at the PR request. I'll merge it, but I need to see what may be required in the future for existing users for the config migration. 2) Dropping MySQL-related notices would probably be pertinent. I'll freely admit I don't follow Sentry's release notes all that closely. (Shameful.) As far as database migration from MySQL to Postgres, I think that's the user's responsibility (and they'll have to decide how they want to handle migrating away from MySQL, if they're using it). Sentry AFAIK is a Django app and there are tools that may help [1], but I don't think that's something this package should be concerned with--even if someone has been using MySQL previously. Unfortunately, that's the nature of large "some assembly required" applications that require additional configuration and work out of the box. [1] https://www.calazan.com/migrating-django-app-from-mysql-to-postgresql/

Mastacheata commented on 2016-04-20 01:23 (UTC)

One more thing: Does it make sense to keep the mysql/mariadb and sqlite bindings mentioned here? The sentry team stopped maintaining the database migrations for these backends in version 7 and announced to drop support completely in the future. That means any database changes made since the announcement will work automatically using the upgrade command for postgres, but will have to be made by hand using only the postgres sourcecode for any other backend. (Yes you really need to look at their postgres migrations and find out what it does there and how to apply that in MySQL/SQLite Syntax if that's even possible at all)

Mastacheata commented on 2016-04-20 01:16 (UTC)

You already accounted for the config.yml file to be present, but you seem to have missed the adjustment of the config parameter. In order for settings in config.yml to be applied, sentry must be started with the config parameter set to the parent directory. (/etc/sentry in this case) Previously you had to set this to the sentry.conf.py file. Even though the config.yml doesn't do that much harm to this date (they simply haven't migrated any of the critical settings there yet), it caused me a major headache to find out why my sentry was ignoring the mail.use-tls setting entered in the config.yml while adhering to the EMAIL_USE_TLS directive in the sentry.conf.py (with the downside of having a deprecation notice on top of the sentry webinterface). I submitted a PR to your github repo.

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