~mig5 thanks for the confirmation!
Comment by ~mig5 on ~tsileo/microblog.pub
I reproduced the issue and I confirm that for me the latest from v2 branch has fixed it.
Comment by ~mig5 on ~tsileo/microblog.pub
Thanks! I realise now that yeah, they are two distinct things.. maybe if there was a button on each profile at /followers that said 'remove' (though I don't know whether people would get confused between that and 'unfollow' being two different things too.. we don't really have a word for 'Make them stop following me'. Maybe the buttons could be 'Unfollow them' and 'Unfollow me' ?).
And leave 'blocking' as a separate thing altogether since that already does its job.
Ticket created by ~mig5 on ~tsileo/microblog.pub
It may be just how ActivityPub works, and that I'm used to the Mastodon model, but I was surprised to see that blocking an account that follows me, still appears as a follower (albeit also that they are 'blocked').
I expected that the act of blocking them would also implicitly force them to unfollow me. Is that not the case?
Comment by ~mig5 on ~tsileo/microblog.pub
Ah. It works in Google Chrome (blurry / not blurry), but not Firefox or Safari. There you go
Comment by ~mig5 on ~tsileo/microblog.pub
It's in both the stream and the inbox.
Loading https://testing.microblog.pub/o/84849c3252914035a2ce769f0c60ddef in Firefox 91.13.0esr on Debian 11, as well as in Safari on iOS, in both cases if I click 'show/hide sensitive content' nothing happens, and I always see the image.
Ticket created by ~mig5 on ~tsileo/microblog.pub
The 'Show/Hide sensitive content' button over an image does not do anything when pressed. The sensitive image is in fact displayed visibly no matter what.
The content warning over text (show/hide more) button, however, works.
Ticket created by ~mig5 on ~tsileo/microblog.pub
I am trying to add a flag emoji to my custom emojis:
🇵🇲
(https://emojiguide.org/flag-st-pierre-miquelon)
This causes this internal server error when going to /admin/new:
==> data/uvicorn.log <== <span class="ji">{{ emoji | emojify(True) | safe }}</span> File "/app/./app/templates.py", line 390, in _emojify return emoji.replace_emoji( File "/opt/venv/.venv/lib/python3.10/site-packages/emoji/core.py", line 270, in replace_emoji return demojize(string, language='en', version=-1, handle_version=replace) File "/opt/venv/.venv/lib/python3.10/site-packages/emoji/core.py", line 218, in demojize replace_str = handle_version(code_points, emj_data) File "/app/./app/templates.py", line 382, in _replace_emoji filename = hex(ord(u))[2:] TypeError: ord() expected a character, but string of length 2 found
Do any flag emojis work for you?
Ticket created by ~mig5 on ~tsileo/microblog.pub
Somehow, yesterday, my incoming worker stopped.
microblog@mig5:~/mig5.social$ docker logs microblogpub boussole compile 06:35:49 - Building project 06:35:49 - Output: /app/app/static/css/main.css Done alembic upgrade head INFO [alembic.runtime.migration] Context impl SQLiteImpl. INFO [alembic.runtime.migration] Will assume non-transactional DDL. 2022-08-31 06:35:51,606 INFO supervisord started with pid 1 2022-08-31 06:35:52,608 INFO spawned: 'incoming_worker' with pid 18 2022-08-31 06:35:52,610 INFO spawned: 'outgoing_worker' with pid 19 2022-08-31 06:35:52,611 INFO spawned: 'uvicorn' with pid 20 2022-08-31 06:35:53,613 INFO success: incoming_worker entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2022-08-31 06:35:53,613 INFO success: outgoing_worker entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2022-08-31 06:35:53,613 INFO success: uvicorn entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2022-08-31 06:53:00,446 INFO exited: incoming_worker (exit status 0; expected)
The result was my stream stayed 'dead' for about 15 hours until I noticed and restarted by container.
Putting aside the 'why' of the exit (might've been my fault, dunno), I'm wondering if it would be good if you set autorestart=true in each of the supervisord programs, just to try and opportunistically recover from such an issue.
I was about to send a patch but then I got confused by the fact that there's both a misc/supervisord.conf and a misc/docker-supervisord.conf (along with the Yunohost one). It looked to me like misc/supervisord.conf is not used, but then I saw you made commits to it on the 28th August, as well as the docker one 2 days earlier, so I got confused. Anyway, I'll leave it with you :)
Ticket created by ~mig5 on ~tsileo/microblog.pub
I have a pinned post (https://mig5.social/o/004764df39a442c8971f7a5a6d0ae730) but it is no long er 'pinned' to the top of the https://mig5.social (Public) page. Have I misunderstood or is this a bug?