I upgraded from old 0.7.n to 0.7.16.0.
Warning: the gem 'rails-assets-bootstrap' was found in multiple sources. Installed from: https://gems.diasporafoundation.org/ Also found in: * https://rubygems.org/ . You should add a source requirement to restrict this gem to your preferred source. For example: gem 'rails-assets-bootstrap', :source => 'https://gems.diasporafoundation.org/.' Then uninstall the gem 'rails-assets-bootstrap' (or delete all bundled gems) and then install again.
Starting Redis server... Required ruby-2.6.6 is not installed. To install do: 'rvm install "ruby-2.6.6."' WARNING: Project gemset is diaspora but you are using ruby-2.6.10 Starting Diaspora in production mode with 1 Sidekiq worker(s).
Someone here said install 2.6.10.
After this I get proxy webserver internal server error.
If you can help me fix my node, I’ll restart a node I let a few scientific/mathematical people use.
It’s extremely unfortunate most installation unstructions (saying to do rvm and git in different places) aren’t matched by update instructions (which say to do rvm and git in same place) so many/most people doing upgrades will fail. I think I fixed the ruby problems, and now it just runs still when viewed in web browser saying ‘500 Internal Server Error.’ A Unix-style top command shows eye and sidekiq running.
Diaspora is dead! No help here nor on IRC after maybe three months!
I’m afraid I can’t offer help as I don’t have the technical expertise.
I hope a few podmins won’t mind if I ping them: @flaburgan @koehn @supertux88 @tclaus @denschub – hopefully one of them will have time to help you.
As I already told @dchmelik on IRC, if he has an issue with RVM, he should ask the RVM people for help, because it works for everyone but him and we’re not the experts of debugging RVM. And if there is an issue with diaspora, we’d need to see
production.log, because we can’t crystal ball our way into a solution.
Unfortunately, if the only reaction we get is messages like
[02:37:19] <darwin> i guess I'll give up and move on to the largest, mastodon
then problems don’t get solved and the personal willingness to interact with a person declines over time.
Thanks for replying, Dennis.
@dchmelik please note. And please don’t accuse Diaspora’s community of giving you no help when they have already, um, given you all the help that they can.
Months ago on IRC I was told post here, then never got reply until I gave up.
It was no longer an RVM problem (already fixed, no thanks to incorrect upgrade instructions) yet for months wasn’t told what log was needed until I gave up.
These aren’t accusations but what happened.
… and yet, you still refuse to provide the information we asked for - and you’re also not telling us what is supposed to be wrong with the upgrade instructions, which, let me say it again, appears to work for everyone. We published a security release after you already had issues, and people were able to update to that just fine.
We might be able to make adjustments to the documentation if there are any weird edge-cases, but for that to be possible, we need to know what actually happened - and “it’s wrong” and “it doesn’t work” doesn’t help with that.
If you want help, then you need to tell us what’s actually wrong. This includes logfiles, and probably also an overview of any local changes to the code you may have made (I’m just assuming that there are local changes, as your startup complains about requiring
ruby-2.6.6, which diaspora* should never do, as we only require
ruby-2.6, not a patch-level version)
If you want to continue complaining about how diaspora* is a dead project and how you’re moving on to Mastodon, then fine. I’ll continue to ignore this thread until there is actionable information here.
Again, no RVM problem for months (as updated original post ‘afer this’ mentioned subsequent problem… I should’ve clarified but it was late then the post was frozen.) I never refused, rather than no log instructions given until few minutes ago. It’s popular to blame other software, but on every upgrade I made for years, since upgrade instructions omit saying use same RVM directory as installation instructions–leading people to believe to use upgrade instructions’ previously-mentioned one–RVM broke every time (except sometimes after first time when remembered)… when I switched from upgrade instructions’ RVM directory to installation instructions’ one, RVM worked every time.
For what it’s worth, I despised all the configuration management hell enough that I put every thing into a Docker image (koehn/diaspora) so that it was isolated from everything else.