Apparition4 isn't really maintained anymore and there are no new releases
and it always logs a lot of errors, making the output hard to read.
So lets switch to cuprite, as it also supports everything we need and is
still maintained.
Supersedes #8330
Yes, I know this is a very ugly workaround, but it works ...
Chrome now requires to add `about:blank` as parameter to open and be
able to use remote debugging. The jasmine-gem isn't supported anymore,
and we need to switch to the `jasmine-browser-runner`, I was working on
that a few months ago, but ran into problems.
As the jasmine-gem doesn't allow to add parameters without `--` infront
of it, lets just add a dummy parameter and add the required
`about:blank` with a space after that. This is ugly, but works for now,
until we can upgrade to the new jasmine version. We could also just
replace the `nil` of the last parameter with that value, but I think
that way it's clearer that this is a workaround and how it works.
Some imagemagick-versions (I tested Ubuntu 22.04 and debian bullseye)
always loose exif data when converting from jpg to webp. So this made
our CI fail now, but even if it wasn't failing before, some pods always
had and have versions which might loose the information anyway. So
having a setting to keep exif information is kinda pointless, if we
can't guarantee that the information isn't lost. Also, diaspora isn't a
photo sharing platform and we don't display exif information anywhere,
so I think we should just always strip exif data (which was already the
default before), as we don't need them.
The unique index doesn't work when the port is `NULL`. So use `-1`
instead for when using the default ports (80/443), as if we would use
the real ports, we could still have both 80 and 443 in the database at
the same time.
This URL is only used in the mobile UI, but when somebody then copies
the link and sends it to somebody on the desktop UI, they don't see
anything. So lets just redirect to the post containing the photo, so
there is at least something to show.
If there is no linked post, just redirect to the image instead.
Fixes#8352
Before the images were only pulled once and then never updated which
lead to really outdated images and OS dependencies. Now all images
(including the base image for the diaspora container) are pulled when
running `setup`. So the idea is to run the `setup` command from time to
time to bring everything up to date again.
Usernames that contained underscores were parsed by markdown first. This
broke the diaspora IDs and also added weird html at places where it
wasn't needed. Escaping them before sending the message through the
markdown parser fixes this issue.
As underscores are the only allowed character that can be used for
markdown that is also allowed inside a diaspora ID, this escaping can be
kept pretty simple.
This only fixes it for the mobile UI at the moment, for the desktop UI
it's probably better to fix it in markdown-it.
Related to #7975
As the docker-compose.yml contains variables, it can't just be used with
docker-compose directly. So this manually use docker-compose commands
with all the required environment variables set.
When puma was introduced in #8392 the default listen configuration was
set to only localhost, which makes sense for most development setups,
but when run within docker, it needs to listen on all IPs so the port
can be forwarded to be accessable outside of docker.
Because the new default makes sense without docker, I overwrite the
option with a environment variable only in the docker-setup. This also
ensures that it always contains the right value needed for the
docker-setup to work, no matter what was configured outside of docker.
Newly generated binstubs will check for the string
`This file was generated by Bundler` inside `bin/bundle`, so we'd have
to update that anyway.
Also, there is a non-zero chance the updated `bundle` binstub resolves
some of the setup-specific issues we've seen.
Newly generated binstubs will check for the string
`This file was generated by Bundler` inside `bin/bundle`, so we'd have
to update that anyway.
Also, there is a non-zero chance the updated `bundle` binstub resolves
some of the setup-specific issues we've seen.
