Arch Linux User Repository

Removed my previous comment. @mitchhentges I've pinned your resolution. I don't know if you want to add a little extra commentary to it to indicate the source of the problem or not, but feel free if so.

Resolved the migration issue by following https://github.com/getsentry/sentry/issues/5502. 1. Ensure Sentry is stopped 2. Enter the sentry shell: "sudo -u sentry /opt/sentry/bin/sentry --config=/etc/sentry shell" 3. Copy and paste the script from https://github.com/getsentry/sentry/issues/5502#issuecomment-305902686 - Note: I had some issues with the python interpreter not liking the paste, but if you copy and paste my edited contents in two separate chunks, it should work:https://pastebin.com/1sya7XET and https://pastebin.com/xn7cdJYu 4. Check that you don't have duplicates anymore by running the following script on the shell, which should give you "[]". from sentry.models import * dupe_envs = Environment.objects.values('name', 'organization_id').annotate(ecount=Count('id')).filter(ecount__gt=1) print(dupe_envs) 5. Try migrating again: sudo -u sentry /opt/sentry/bin/sentry --config=/etc/sentry upgrade 6. If migrating again didn't work due to |"sentry_environment_organization_id_6c9098a3d53d6a9a" already exists|, then skip the partially-applied migration: "sudo -u sentry /opt/sentry/bin/sentry --config=/etc/sentry django migrate --fake sentry 0321_auto__add_unique_environment_organization_id_name", then migrate again ----- I'm not sure that there's a way to make this easier within the "sentry" package, or if it's even within the role of the AUR package to handle this issue. Either way, the technical solution is ^

Hmm, I got an error while migrating, I'll see if anything exists in the Sentry issue tracker. --------------------------------------- $ sudo -u sentry /opt/sentry/bin/sentry --config=/etc/sentry upgrade // snip Running migrations for sentry: - Migrating forwards to 0326_auto__add_field_groupsnooze_count__add_field_groupsnooze_window__add_f. > sentry:0321_auto__add_unique_environment_organization_id_name FATAL ERROR - The following SQL query failed: CREATE UNIQUE INDEX CONCURRENTLY sentry_environment_organization_id_6c9098a3d53d6a9a ON sentry_environment (organization_id, name) The error was: ProgrammingError('relation "sentry_environment_organization_id_6c9098a3d53d6a9a" already exists\n',) SQL: CREATE UNIQUE INDEX CONCURRENTLY sentry_environment_organization_id_6c9098a3d53d6a9a ON sentry_environment (organization_id, name) Traceback (most recent call last): File "/opt/sentry/bin/sentry", line 14, in <module> sys.exit(main()) File "/opt/sentry/lib/python2.7/site-packages/sentry/runner/__init__.py", line 160, in main cli(prog_name=get_prog(), obj={}, max_content_width=100) File "/opt/sentry/lib/python2.7/site-packages/click/core.py", line 722, in __call__ return self.main(*args, **kwargs) File "/opt/sentry/lib/python2.7/site-packages/click/core.py", line 697, in main rv = self.invoke(ctx) File "/opt/sentry/lib/python2.7/site-packages/click/core.py", line 1066, in invoke return _process_result(sub_ctx.command.invoke(sub_ctx)) File "/opt/sentry/lib/python2.7/site-packages/click/core.py", line 895, in invoke return ctx.invoke(self.callback, **ctx.params) File "/opt/sentry/lib/python2.7/site-packages/click/core.py", line 535, in invoke return callback(*args, **kwargs) File "/opt/sentry/lib/python2.7/site-packages/click/decorators.py", line 17, in new_func return f(get_current_context(), *args, **kwargs) File "/opt/sentry/lib/python2.7/site-packages/sentry/runner/decorators.py", line 36, in inner return ctx.invoke(f, *args, **kwargs) File "/opt/sentry/lib/python2.7/site-packages/click/core.py", line 535, in invoke return callback(*args, **kwargs) File "/opt/sentry/lib/python2.7/site-packages/click/decorators.py", line 17, in new_func return f(get_current_context(), *args, **kwargs) File "/opt/sentry/lib/python2.7/site-packages/sentry/runner/commands/upgrade.py", line 60, in upgrade _upgrade(not noinput, traceback, verbosity, not no_repair) File "/opt/sentry/lib/python2.7/site-packages/sentry/runner/commands/upgrade.py", line 29, in _upgrade verbosity=verbosity, File "/opt/sentry/lib/python2.7/site-packages/django/core/management/__init__.py", line 159, in call_command return klass.execute(*args, **defaults) File "/opt/sentry/lib/python2.7/site-packages/django/core/management/base.py", line 285, in execute output = self.handle(*args, **options) File "/opt/sentry/lib/python2.7/site-packages/south/management/commands/migrate.py", line 111, in handle ignore_ghosts = ignore_ghosts, File "/opt/sentry/lib/python2.7/site-packages/south/migration/__init__.py", line 220, in migrate_app success = migrator.migrate_many(target, workplan, database) File "/opt/sentry/lib/python2.7/site-packages/south/migration/migrators.py", line 256, in migrate_many result = migrator.__class__.migrate_many(migrator, target, migrations, database) File "/opt/sentry/lib/python2.7/site-packages/south/migration/migrators.py", line 331, in migrate_many result = self.migrate(migration, database) File "/opt/sentry/lib/python2.7/site-packages/south/migration/migrators.py", line 133, in migrate result = self.run(migration, database) File "/opt/sentry/lib/python2.7/site-packages/south/migration/migrators.py", line 114, in run return self.run_migration(migration, database) File "/opt/sentry/lib/python2.7/site-packages/south/migration/migrators.py", line 91, in run_migration south.db.db.rollback_transaction() File "/opt/sentry/lib/python2.7/site-packages/south/db/generic.py", line 1000, in rollback_transaction transaction.leave_transaction_management(using=self.db_alias) File "/opt/sentry/lib/python2.7/site-packages/django/db/transaction.py", line 78, in leave_transaction_management get_connection(using).leave_transaction_management() File "/opt/sentry/lib/python2.7/site-packages/django/db/backends/__init__.py", line 310, in leave_transaction_management "This code isn't under transaction management") django.db.transaction.TransactionManagementError: This code isn't under transaction management

If you're having trouble launching Sentry due to a missing libssl.so (probably 1.0.0), it's likely a consequence of OpenSSL 1.0.x's recent move into the extra/openssl-1.0 package. OpenSSL 1.1 is now the version installed with the core/openssl package, and building Sentry on a system that previously had OpenSSL 1.0.0 installed may cause problems immediately following an update. At this time, there are three possible workarounds. In order of increasing difficulty they are: 1) Update your system. Rebuild Sentry and install. Do not rebuild Sentry with an AUR helper. Use makepkg directly; you can use yaourt -G to download the package to a build directory, however. AUR helpers add an extra layer of complexity and may make troubleshooting difficult. If you've already updated your system, update it again using pacman (not yaourt or another wrapper). Rebuild Sentry and reinstall. Again. 2) Install extra/openssl-1.0. This workaround should be adequate for the foreseeable future but doesn't address the underlying problem of uWSGI not building against the latest version of OpenSSL. 3) Uninstall/reinstall uWSGI from Sentry's directory if it refuses to pick up the correct OpenSSL version: $ /opt/sentry/bin/pip uninstall uwsgi $ /opt/sentry/bin/pip install --prefix=/opt/sentry uwsgi (Only do this if you absolutely have to get Sentry running and have no other alternatives.) ========= This issue has nothing to do with Sentry or with uWSGI's build process (nor is there any reason it should). I've been unable to replicate the problem on any of my machines thusfar, including ones with both core/openssl and extra/openssl-1.0 installed. Therefore, I believe it's possible that the problem may be caused or aggravated by automated tools or scripts (particularly yaourt, if used to update the system + AUR packages) that attempt to update the system (again, including AUR packages) in a single pass or by an ld cache that hasn't yet picked up the new version of OpenSSL. If you're having trouble with OpenSSL versions, you may need to run ldconfig manually to update the appropriate caches (-p may be helpful to see what ldconfig is seeing before updating the cache; see below for reporting difficulties). Given the nature of OpenSSL and the depth to which it is often intertwined with userland applications, you SHOULD reboot your machine following any update has changed/updated it unless you're comfortable with restarting *all* services by hand. Rebooting is probably faster/easier/less error prone. REPORTING DIFFICULTIES If you continue to have trouble, be absolutely certain you've updated your system, rebooted, rebuilt and reinstalled Sentry, and then provide the output of the following: $ ldconfig -p | grep libssl $ ldd /opt/sentry/bin/uwsgi | grep libssl This post may be edited for clarity or to provide further information. Thanks!

I'm not sure I can explain this given that I can't replicate the problem. It *should* be linking against whatever OpenSSL version is on the build host. I suppose you could grep through ldconfig -v to see what it thinks it sees, but I'm not optimistic that will yield any clues. Outside something like ld.so.cache not updating properly (which should've meant uWSGI would fail to build), I'm out of ideas. I doubt it'll happen again but being as this PKGBUILD simply calls `pip` to install Sentry there's no reason it shouldn't have worked any differently from installing uWSGI into the Sentry directory manually. Possibly interesting discussion thread begins here suggesting some packages may not have been fully built against OpenSSL 1.1.x.: https://bugs.archlinux.org/task/53776 Honestly, I'm not sure this is an issue that can be resolved with this PKGBUILD or even Sentry for that matter.

I didn't install extra/openssl-1.0, but here's what I found: Re-building with yaourt (after clearing /tmp/yaourt-tmp-mitch), |ldd /opt/sentry/bin/uwsgi| showed "not found" for libssl.so.1.0 After manually running makepkg, then extracting the package, |ldd uwsgi| showed "not found" for libssl.so.1.0.0 Interestingly, if I sftp'd /the same/ uwsgi file from ^ to my desktop (from my server, where sentry was being built), I successfully got: "libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007fbeb4e6b000)" Finally, installing uwsgi through pip solved my problem, |ldd /opt/sentry/bin/uwsgi| on my server shows: "libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0x00007fcaf9357000) It's running now, but I'm nervous about the next update "

I'm wondering if there's something wrong with your linker or yaourt is interfering. Upon rebuilding Sentry or reinstalling uWSGI, ldd shows the following: [corona:sentry]$ ldd /opt/sentry/bin/uwsgi [snip] libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0x00007f8f91c4b000) I'd imagine yours is still showing libssl.so.1.0.0. I'd suggest trying at least one of the following: - Don't use yaourt. Build the package with makepkg. You can use yaourt to collect the package, e.g.: $ yaourt -G sentry $ cd sentry && makepkg - If the above doesn't work, try installing uwsgi by hand and see whether ldd shows any changes: $ cd /opt/sentry $ sudo -u sentry ./bin/pip uninstall uwsgi $ sudo -u sentry ./bin pip install --prefix=/opt/sentry uwsgi

For the time being, it looks like you may need to install the package extra/openssl-1.0. I may update this PKGBUILD to include that in the dependencies, but I'd much rather find a more permanent solution.

I rebuilt Sentry (yaourt -S sentry). That didn't do the trick, but I'm not too worried. Thanks for investigating into this, let me know if you need more details!