-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bump hometown to Mastodon 4.2.9 #1337
base: hometown-dev
Are you sure you want to change the base?
Bump hometown to Mastodon 4.2.9 #1337
Conversation
Co-authored-by: Claire <[email protected]>
Co-authored-by: GitHub Actions <[email protected]>
Co-authored-by: GitHub Actions <[email protected]>
Co-authored-by: GitHub Actions <[email protected]>
Co-authored-by: GitHub Actions <[email protected]>
Co-authored-by: GitHub Actions <[email protected]>
Co-authored-by: GitHub Actions <[email protected]>
Chiming here to notify you that we updated the Same thing with the security patches, I haven't checked whether they interfere with Hometown features, but I don't think they should, and they also apply cleanly, so merging them should not be an issue, and you should be on track for the release! |
@ClearlyClaire Thank you for letting us know! I've merged the stable-4.2 branch into this again, went smooth as butter. 👍 |
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
ea4545e
to
c72697c
Compare
I just realised that I accidentally leaked stuff from my personal fork into this branch. I don't know when it happened. Anyway, I removed said commits, sorry for any confusion caused by this. |
Oops! Can you give an example personal commit for me to look out for just
to make extra sure it's not in the final release or my test builds?
|
af8b8ee would be one such example, I think it's in your branch as well. 🙈 |
Okay I did a force update on https://github.com/hometown-fork/hometown/tree/hometown-4.2-merge -- going to attempt to fix the pastel themes since those are the main thing broken. |
@nachtjasmin Interesting -- it seems like no user themes (pastel or not) are saving state for me. Like I go to change my user set theme and no matter what I change it to it always reverts to Mastodon (Dark). But if I change the site theme that does change and save it for everyone. Can you reproduce this? Or is this just a problem for me... |
Hmm looks like a rollback is happening here when it tries to save the setting... 09:20:36 web.1 | Setting Load (0.3ms) SELECT "settings".* FROM "settings" WHERE (thing_type is NULL and thing_id is NULL) AND "settings"."var" = $1 ORDER BY "settings"."id" ASC LIMIT $2 [["var", "theme"], ["LIMIT", 1]]
09:20:36 web.1 | ↳ app/models/setting.rb:28:in `block in []'
09:20:36 web.1 | Cache write: rails_settings_cached/8d13a7825611181d5a70a3c9add28ef1/theme ({:compress=>true, :compress_threshold=>1024})
09:20:36 web.1 | Cache read: rails_settings_cached/8d13a7825611181d5a70a3c9add28ef1/theme ({:compress=>true, :compress_threshold=>1024})
09:20:36 web.1 | Cache fetch_hit: rails_settings_cached/8d13a7825611181d5a70a3c9add28ef1/theme ({:compress=>true, :compress_threshold=>1024})
09:20:36 web.1 | UserRole Load (0.1ms) SELECT "user_roles".* FROM "user_roles" WHERE "user_roles"."id" = $1 LIMIT $2 [["id", 3], ["LIMIT", 1]]
09:20:36 web.1 | ↳ app/models/user.rb:159:in `role'
09:20:36 web.1 | TRANSACTION (0.1ms) ROLLBACK
09:20:36 web.1 | ↳ app/controllers/settings/preferences/base_controller.rb:7:in `update'
09:20:36 web.1 | Rendering layout layouts/admin.html.haml
10:10:41 web.1 | Setting Load (0.2ms) SELECT "settings".* FROM "settings" WHERE (thing_type is NULL and thing_id is NULL) AND "settings"."var" = $1 ORDER BY "settings"."id" ASC LIMIT $2 [["var", "theme"], ["LIMIT", 1]]
10:10:41 web.1 | ↳ app/models/setting.rb:28:in `block in []'
10:10:41 web.1 | Cache write: rails_settings_cached/e23eceea1dbbecf09d779eb1d9007c03/theme ({:compress=>true, :compress_threshold=>1024})
10:10:41 web.1 | Cache read: rails_settings_cached/e23eceea1dbbecf09d779eb1d9007c03/theme ({:compress=>true, :compress_threshold=>1024})
10:10:41 web.1 | Cache fetch_hit: rails_settings_cached/e23eceea1dbbecf09d779eb1d9007c03/theme ({:compress=>true, :compress_threshold=>1024})
10:10:41 web.1 | UserRole Load (0.1ms) SELECT "user_roles".* FROM "user_roles" WHERE "user_roles"."id" = $1 LIMIT $2 [["id", 3], ["LIMIT", 1]]
10:10:41 web.1 | ↳ app/models/user.rb:159:in `role'
10:10:41 web.1 | User Update (0.2ms) UPDATE "users" SET "updated_at" = $1, "settings" = $2 WHERE "users"."id" = $3 [["updated_at", "2024-07-03 17:10:41.849632"], ["settings", "{\"theme\":\"default\",\"web.advanced_layout\":false,\"web.trends\":true,\"web.use_blurhash\":true,\"web.use_pending_items\":false,\"web.use_system_font\":false,\"web.disable_swiping\":false,\"web.delete_modal\":true,\"web.reblog_modal\":false,\"web.unfollow_modal\":true,\"web.reduce_motion\":false,\"web.expand_content_warnings\":false,\"web.display_media\":\"default\",\"web.auto_play\":false}"], ["id", 1]]
10:10:41 web.1 | ↳ app/controllers/settings/preferences/base_controller.rb:7:in `update'
10:10:41 web.1 | TRANSACTION (0.5ms) COMMIT See how it goes straight from the |
Oh I think I am starting to see... Mastodon introduced UserRole since v4.0. There is probably a missing migration or something where users lack an appropriate UserRole so the validation doesn't happen and triggers a rollback? |
So I have confirmed that this error only occurs when a server has been migrated from Hometown running v4.0.15 to the new v4.2.9 merge branch. If you install it clean it's fine, but something about the migration is an issue. After migration there is indeed a |
Lol okay this is a problem with email addresses on the default admin account!! In 4.0.15 it was |
Okay I changed my admin email to |
It's been 16 months since Mastodon 4.1.0 dropped, and over 2k commits. Releasing today, maybe with a note about tomorrow's expected security release, could help surface any issues sooner. It could give the hosted services some room to work and do some indexing, too. (Apologies if that's just my anxiety.) |
@pronoiac Hmm I see your point but I do not have physical availability to monitor a release until tomorrow morning anyway. I think it's more important that I'm around to help put out fires than to do a prerelease and disappear until a second actual release tomorrow morning. But if anyone wants to try out the prerelease, they can run this branch: https://github.com/hometown-fork/hometown/tree/hometown-4.2-merge It's currently running on Friend Camp just fine. Here is my draft installation guide for anyone who wants to try it: Hometown v4.2.9+1.1.1 release (not a real release, I'm waiting for the security patch tomorrow)This is a security release that keeps us up to date with Mastodon v4.2.9. Thank you once again to [@nachtjasmin](https://github.com/nachtjasmin) for the help with this merge. ChangelogPlease [see the Mastodon 4.2.0 release notes for details](https://github.com/mastodon/mastodon/releases/tag/v4.2.0). You can check the release notes up to 4.2.9 as well, though they are mostly bugfixes minus a big moderation change that I highlight below. The really big changes for users are:
Upgrade stepsThese are instructions for upgrading from Hometown As always, make sure you have backups of the database before performing any upgrades. A postgres backup command would look something like this:
DependenciesExternal dependencies have changed since v4.1.7, with the Ruby, PostgreSQL and Node.js minimum version being higher.
Moderation and registration changes
We are changing the default, so that opening registrations is always a conscious choice. If you have never changed or saved the registrations mode yourself, this update will switch your server to not accepting new users. Simply change the setting again after the update if you wish to restore the old behavior. Database replica configurationThe way Mastodon handles read replicas has changed, removing the This changes how database replicas are configured. Instead of editing If you are using If you aren't using database replicas or have no idea what this is about... don't sweat it, you're fine. Streaming server changesWe have dropped built-in clustering support from the streaming server, which means, depending on the load you are facing, that you may need to run multiple instances of it and configure a load-balancer. Unless you are using Docker, it is recommended that you update your
If you then need to run more than one
Automatic update checkingStarting from this release, Mastodon will periodically check for updates by querying That URL can be changed using the Update steps
|
Does that URL also know about Hometown releases? or should this be changed to account for running a fork? |
What that api returns right now, prettified: {
"updatesAvailable": [
{
"version": "4.2.9",
"type": "patch",
"releaseNotes": "https://github.com/mastodon/mastodon/releases/tag/v4.2.9",
"urgent": false
}
]
} |
It does not - I can probably provide a new URL for Hometown releases but it
wasn't priority for this security push.
…On Wed, Jul 3, 2024, 6:57 PM James Young ***@***.***> wrote:
What that api returns right now, prettified:
{
"updatesAvailable": [
{
"version": "4.2.9",
"type": "patch",
"releaseNotes": "https://github.com/mastodon/mastodon/releases/tag/v4.2.9",
"urgent": false
}
]
}
—
Reply to this email directly, view it on GitHub
<#1337 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACBBVQKY5BFOTAME7EWOQLZKSTZTAVCNFSM6AAAAAA7O5HSMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBXHA3DENRTGY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Is there a clean path to migrate from this to v4.2.10? Just attempted it this morning and ran into a whole host of issues myself |
@reesericci I suggest filing a new issue, and including details of the issues there |
I more just ended up hurting myself with git & bundler than anything specific (updated the dependencies too far, etc) |
The recent Hometown release already includes the patch, so you should be fine following the instructions there. This PR is also part of said release. |
That worked for me! |
Update 2023-12-29: It is ready for review!
Update 2023-12-30: I just deployed it on queer.group, so yes, this PR is already running in production.
This PR is a replacement for #1325, since I started from scratch. The last tag, v4.0.10+hometown-1.1.1 is used as the root for this PR.
For anyone who wants to support me, feel free: https://ko-fi.com/queergroup
Current TODO list:
is_exclusive
, upstream uses justexclusive
)Permalink
component which was added in b8802af and was only removed by me (f825010) for easier conflict resolutionAnd then it's time for the integration tests.