Package Details: diaspora-mysql 0.9.0.0-2

Git Clone URL: https://aur.archlinux.org/diaspora-mysql.git (read-only, click to copy)
Package Base: diaspora-mysql
Description: A distributed privacy aware social network (MariaDB/MySQL)
Upstream URL: https://diasporafoundation.org
Licenses: AGPL3
Conflicts: diaspora-mysql-git, diaspora-postgresql, diaspora-postgresql-git
Submitter: jhass
Maintainer: jhass
Last Packager: jhass
Votes: 7
Popularity: 0.000006
First Submitted: 2016-09-05 18:58 (UTC)
Last Updated: 2025-01-28 13:29 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 Next › Last »

jhass commented on 2021-04-19 17:14 (UTC) (edited on 2021-04-19 17:14 (UTC) by jhass)

I wasn't sure how backup would deal with removing a file so I kept it in there for the benefit of the doubt. Note that the toml was added too.

There's no straight forward converter, I would recommend to apply the settings to the new file manually with a side by side view with the yml. Meanwhile you can still re-create the symlink to /usr/share/webapps/diaspora/config/diaspora.yml and it'll continue working until 0.8, I just couldn't think of a good way to keep this in the package without superfluous and confusing deprecation warnings for users that chose to migrate.

I don't think references to $srcdir in such auxillary files is a real issue. I won't bother with cleaning this up, if you find a good and maintainable way, contributions welcome :) https://github.com/jhass/PKGBUILDs/tree/main/diaspora

Please always ignore each and every non-error messages from bundler, diaspora developers take care of those :)

fordprefect commented on 2021-04-19 09:52 (UTC) (edited on 2021-04-19 09:53 (UTC) by fordprefect)

Thank you for the update. It has a few issues, however:

  • etc/webapps/diaspora/diaspora.yml has been renamed to diaspora.toml, but the backup entry in the PKGBUILD is still the yml file. How to convert existing yml to toml by the way?

  • some files contain references to the $srcdir, but upon inspection these seem pretty unnecessary. Among these files is a Makefile for ruby_http_parser and som gem_make.out files seemingly containing log information from the gem compilation. Can these safely be deleted?

  • There are concerning post-install messages from the gems 'encryptor' and 'attr_encrypted' dealing with security implications. Are these safe to ignore?

Thanks for maintaining this software and making it available in the AUR. Much appreciated!

jhass commented on 2020-06-14 21:24 (UTC)

Hey, I just updated the package to 0.7.14 and thus Ruby 2.6. Does this still happen for you?

agaskins commented on 2020-06-14 21:08 (UTC) 

bundler: command not found: rake-2.5
Install missing gem executables with `bundle install`
==> ERROR: A failure occurred in build().
    Aborting...

fordprefect commented on 2020-04-24 17:29 (UTC)

Thanks, working with ruby2.5 now and all seems fine, bundler however needed to be downgraded to 1.7.3 (last version of the 1.x branch). Wasn't diaspora running with bundler 2.x already on ruby2.4? Sorry for so many questions…

jhass commented on 2020-04-23 16:12 (UTC)

Ruby 2.7 will just drown you in deprecation warnings, otherwise yes, it might.

Welp, anyways I just went ahead and updated the packages to use Ruby 2.5, let's see how that'll go...

fordprefect commented on 2020-04-22 15:42 (UTC)

Sounds like even the up-to-date extra/ruby (2.7.1) could be an option if run only in production? Maybe the PKGBUILD could get a _rubyver variable to easily build for a different version (I suppose that is the only thing that needs to be done switching ruby versions?)? Thanks for the very reliable work!

jhass commented on 2020-04-22 15:27 (UTC)

Kinda... https://github.com/diaspora/diaspora/pull/7929

Many of us are already running on 2.5 or 2.6 without issues.

fordprefect commented on 2020-04-22 14:59 (UTC)

@jhass: ruby2.4 still seems to be a dependency for this package, but you just deprecated that package. Any plans to update diaspora to a newer ruby version?

jhass commented on 2018-05-11 17:28 (UTC)

Okay, my workaround for https://bugs.archlinux.org/index.php?do=details&task_id=58414 doesn't do. I'm grateful for any ideas anybody has, otherwise we have to wait for the ecosystem to catch up, sorry.

Meanwhile you should be able to start back up with writing some systemd units that avoid eye and start unicorn and sidekiq directly.

« First ‹ Previous 1 2 3 Next › Last »