chore(deps): update dependency slskd/slskd to v0.25.0 #6062
Reference in New Issue
Block a user
Delete Branch "renovate/unified-slskd"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR contains the following updates:
0.24.5→0.25.0Release Notes
slskd/slskd (slskd/slskd)
v0.25.0Compare Source
🎉 Big Release!
This release contains a number of mostly unrelated changes.
Licensing
I have added 'Additional Terms' to the AGPLv3 that clarify the conditions under which folks can distribute and modify slskd, which Section 7 of the AGPLv3 allows. These terms include preservation of notices and licenses (already required by the AGPLv3, the terms spell the requirements out explicitly), mandatory identification of modifications (again, already required), mandatory rebranding (renaming forks to something that won't be confused with slskd), and the mandatory modification of the client version supplied to the server at login.
The full text of these Additional Terms can be found at the bottom of the LICENSE in the root of the repository. I've also added a NOTICE in the hopes that folks will be drawn to it and see that the LICENSE includes Additional Terms, and I've added a FORKING.md that explains the new terms in plain English.
To explain why I've done this, I'll share an excerpt from FORKING.md:
With AI becoming mainstream it is now incredibly easy to fork a project and manipulate it in ways that are harmful to users and/or the server(s) the software connects to. This behavior, unfortunately, is permissible under the AGPLv3. All I can do is ensure that users aren't deceived into using these untrusted and potentially harmful forks.
Docker User/Permissions
The slskd Docker container now supports both Docker's built in
--user/user:and now the Linuxserver/*arr stylePUID/PGIDmethods for running the container as a specific user. The built-in method is objectively superior, but I noticed that people frequently got hung up on permissions because they were usingPUID/PGIDwithout understanding that it wasn't supported.These methods are mutually exclusive; users must choose one or the other. Users should also be aware that when using the
PUID/PGIDmethod, the container willchownthe mounted/appdirectory on startup. This may be unexpected, but it is the intended behavior. Thechownisn't recursive; users will need to do that themselves if needed.Examples in the README and Docker docs have been updated to reflect these changes. I welcome any feedback about the approach in the Dockerfile or contents of the docs.
Configuration May Be Broken
Users who have configured things under the
global,groups, orintegrationkeys in the configuration file will find that the app will log an error and exit early until they apply the necessary changes. This is unfortunate, but the alternative was to not do that and allow people to continue using the app without their configuration being respected.Pull request #1704 outlines the changes and provides an example of what needs to be done by correcting the configuration docs. tl;dr:
globalkey totransfersintegrationkey tointegrationsThese changes were made to make room for upcoming features (stay tuned!). The rename of the integration key was admittedly not necessary for that, but I figured I would sneak it in.
What's Changed
New Contributors
Full Changelog: https://github.com/slskd/slskd/compare/0.24.5...0.25.0
Configuration
📅 Schedule: (in timezone America/Chicago)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
This PR has been generated by Renovate Bot.
940f4c7a86to62227a6b95