deluge 2 upgrade to python 3.10 fix for DSM7 (follow-up #4153) #5398
Conversation
Co-Authored-by: hgy59 <hpgy59@gmail.com> Co-Authored-by: Christophe David <david.christophe@protonmail.com>
|
Manual daemon startup now works: Along with connecting to default web page http://192.168.x.y:8112/ using @hgy59 finally got a success on this one! Left is changing the code in order to allow starting up multiple daemons. |
|
DONE: TODO: |
|
@hgy59 a second pair of eyes would be appreciated on this PR, mostly on I have completed the changes in order to allow managing multiple daemon for start|stop|status. It currently is tested for non-background mode with PID tracking (e.g. non-daemonized). Still left are:
I'm getting real close to finally complete this long-standing PR 😄 . |
|
@SynoCommunity/developers I need some help for DSM7, related to permission management. When installing on DSM7 it fails miserably (I mean it says installation error). After investigating through the logs it seems related to permission management. In this case, both DSM7 NAS I'm testing against are vanilla images, imaged from DSM7 natively (one virtual x64 and one physical armv7) using default configurations. Issues I see while testing deluge are:
Output from Auto-generated
In comparison on my DSM6 where it works like a charm:
I've re-read the https://github.com/SynoCommunity/spksrc/wiki/Permission-Management and didn't find the right answer (or I misread). My guess is that I need a Help would be really much appreciated. |
|
What you are seeing is exactly as they should be on DSM 7.. All the nice stuff we could do on DSM6, we cannot do anymore on DSM7. Sucks for the user, but it's safer because malicious packages can no longer hijack permissions all over the disk. |
|
Thnx @Safihre , it hapens that I just hit |
mk/spksrc.service.start-stop-status
Outdated
| else | ||
| date >> ${LOG_FILE} | ||
| fi | ||
| # Keep logs by default |
There was a problem hiding this comment.
Please do not change such a default behaviour!
- packages might write a lot of log output
- log is never deleted and old log is kept on package updates
- logs are neigther rotated nor compressed by our generic service support
- to report issues, the log since service start is sufficient and I assume that users will include the full log to issues reported here
If you have services that really should keep the logs, it would be better, we could write logs to /var/log/packages were those might get rotated (not verified yet).
IMHO the option SVC_QUIET = no is more for package development than for production. Currently no package defines SVC_QUIET, this shows that deleting the logs on service start is a good default behaviour.
There was a problem hiding this comment.
I'll revert to the original behavior. Although while playing with the package I find it really anoying to remove thel previous log, always. The best would be to incorporate a logrotate by default. Page 107 for Syslog Config mentions something about that similar to (but that's for another time and PR):
"syslog-config": {
"logrotate-relpath": "etc/<appname>-logrotate.conf"
}
Beyond that, any thought otherwise on the proposed changes?
|
@hgy59 this now LGTM and ready for review. I'll resume testing on my DSM7 EDIT: Issue found! This is cause by |
|
While playing with multiple install + upgrade on DSM6 I ended noticing something wrong with the setting up of the permissions which led into creating 40+ ACL entries on my Notice that the important part of the installer log is: There might have been a which needs to be converting A patch is on the way as well for fixing this. |
|
@hgy59 Now fully complete and ready for merge. |
|
@Ber-Flo Feel free to give this a shot for testing. Wait for updated build to be available in the "Checks" summary page. |
x64-7.0 is working like a charm on DSM 7.1-42661, just had to install python3.2 and enable sc-deluge read/write rights for my target folder on DSM. Thank you so much, it's the only DSM torrent client supporting socks5 proxy. Merci :) |
@Ber-Flo can you please confirm, you mention python3.2 but really that should be python 3.10...
Au plaisir :) |
3.10 not 3.20 indeed |
| mkdir -p "${shared_folder}/incomplete" | ||
| mkdir -p "${shared_folder}/complete" | ||
| mkdir -p "${shared_folder}/watch" | ||
| install -m 0775 -o ${EFF_USER} -g ${GROUP} -d "${shared_folder}/incomplete" |
There was a problem hiding this comment.
@hgy59 Does this not break ACL permissions by forcing Linux-style permissions?
There was a problem hiding this comment.
The end result is identical to the mkdir being theses sub-directories are in Linux mode with no ACL under DSM7. As such it needs the 0775 + ${GROUP} to be set properly otherwise it won't work for other packages.
EDIT: Note that this was tested and behavior discovered on vanilla DSM7 on both x64 and armv7. I believe the workaround would be using the resources file by adapting the jq call in spksrc.service.mk so it can handle multiple arguments, even some relative to wizard variable in the Makefile such as:
SERVICE_WIZARD_SHARE = wizard_download_dir
SERVICE_WIZARD_SHARE += wizard_download_dir/incomplete
SERVICE_WIZARD_SHARE += wizard_download_dir/complete
SERVICE_WIZARD_SHARE += wizard_download_dir/watch
I briefly looked at it and clearly my jq skillset is lacking... so I left it as is 🤷
There was a problem hiding this comment.
Yeah I will test if this is needed at all. Maybe those folders don't need to be created during install, because SABnzbd also creates them at startup. I think when SAB creates them at startup, they will be created in the right way with correct ACL.
th0ma7
added
status/published
Co-Authored-by: hgy59 hpgy59@gmail.com
Co-Authored-by: Christophe David david.christophe@protonmail.com
Description
Upgrade deluge and migrate to DSM7
Checklist
all-supportedcompleted successfullyType of change
Testing
x64-6.1migrate/upgrade | install | upgradex64-7.0install | upgradearmv7-7.0install | upgrade