SynoCommunity / spksrc

Cross compilation framework to create native packages for the Synology's NAS
https://synocommunity.com
Other
2.99k stars 1.22k forks source link

Need to Point Installed Sickbeard Custom to Python 3 on Synology NAS for Pymedusa (Now Python 3 Compatible) #3710

Open wreid23 opened 5 years ago

wreid23 commented 5 years ago

For new Package Requests, see the guidelines

Setup

Package Name: sickbeard-custom Package Version:

NAS Model: DS3615xs NAS Architecture: XPENOLOGY INTEL DSM version: DSM 6.1.7-15284 Update 3

Expected behavior

Tell us what should happen:

I Need Package to start and use Python 3 package that is currently installed on NAS. Pymedusa now supports python3: https://github.com/pymedusa/Medusa/wiki/Switch-to-Python-3 Need to point pymedusa to python3 module in: /volume1/@appstore/python3/bin and confirm that it will start and look for python3 going forward instead of 2.7 not sure how to do that .

Actual behavior

Tell us what happens instead: medusa Python 2.7 is used as it is currently the default

Steps to reproduce

1. Start Pymedusa branch from Sickbeard-Custom 2. When in Pymedusa it will show running 2.7 3. Not sure what to change to use installed python3 packages

Package log

Check Package Center or /usr/local/{package}/var/

Insert the package log here

Other logs

E.g. /var/log/messages or /var/log/synopkg.log

Insert log here
zapru commented 3 years ago

Thank you, thank you, thank you, .... Works :) "torents / Magnets" is the correct setting and not / torents / Magnets

noob :))))

dpprdan commented 3 years ago

You need to install Python 3 from the SynoCommunity and after that my medusa package. You can find it here: BenjV/SYNO-packages

Do you already have plans for making it a SynoCommunity package, @BenjV?

BenjV commented 3 years ago

Not at this moment. I created a package for my own application (autosub) and this package is very easy to adopt for any Python application that is maintained on github. So I created Python3 packages for SickBeard and Medusa with little effort, because the Python3 version was nowhere available. It will take too much effort for me to convert it to the spksrc for the SynoCommunity.

scott451 commented 3 years ago

Hello,

I tried to install the BenjV Medusa package with the Synology Python3 package installed (v3.8.x). It does not recognize this version and will not install. Am I missing something ?

BenjV commented 3 years ago

Most likely you have the wrong Python3. You need Python3 from the SynoCommunity and their version is Python 3.7.7.

sackman68 commented 3 years ago

I'm happy to report that I successfully installed Medusa from BenjV's package. I'm now getting the following message upon startup in the Medusa Web UI: "Unable to find your git executable. Set git executable path in Advanced Settings OR shutdown application and delete your .git folder and run from source to enable updates." As a result, the Medusa Branch and Version are unknown.

I've added the following in General > Advanced Settings > Git executable Path: /usr/local/git/bin/git/var/packages/git and it does not resolve the issue.

Do you have a recommendation? Could this be a bug in Medusa?

Thanks!

BenjV commented 3 years ago

It should not be needed to set that Git executable path. And if you add it shoulde be:

/var/packages/git/target/bin/git

Did you install the git package from the Synocommunity?

Do you use docker?

sackman68 commented 3 years ago

I updated it to the path which you indicated, restarted Medusa and it did not work. I then updated it to the path: /var/packages/git/target/bin/git , restarted Medusa and message disappeared.

I now indicates the following information for Branch and Version. Previously they were unknown. Branch: master Commit: 1c1d3279ea1c3bb891b8581671e21543aea00c8c Version: fatal: No names found, cannot describe anything.

I am using the following Git Package from the SynoCommunity: Developer: Safihre Installed Version 2.15.1-11

I'm not using docker.

My installation indicates: All non-absolute folder locations are relative to /volume1/@appstore/medusa/var

Thanks!

BenjV commented 3 years ago

Apparently medusa needs the name of the binary in that field and not only the path. But normally git should be found by Medusa via the PATH environment variable and that setting should not be needed.

But you have a very old version of git installed, the latest version is v2.28.0-16 Most likely that is the problem, so update git.

sackman68 commented 3 years ago

This morning Medusa was working and correctly downloading shows, even though I had to manually maintain the git_path.

I've updated git to v2.28.0-16 and unfortunately now the Medusa ui starts to load but stops with the pop-up: 192.168.0.xxx:8897says Unable to connect to Medusa!

Any ideas how I can resolve this?

BenjV commented 3 years ago

Maybe a firewall issue? Or some other network issue. Did you look in the medusa log? Post a question on the Medusa github, because I don't think this has anything to do with the Synology package.

sackman68 commented 3 years ago

I posted a message in the Medusa github, since 4+ days and they're not picking it up. The issue seems to be due to an incompatibility with git 2.28.0-16. I'm trying to downgrade git to 2.24.1-12, but it says that I can't downgrade, and when I try to uninstall git, it says that I need to uninstall Medusa first. When I try to uninstall Medusa, I get a message "Failed to Uninstall the Package." I then uninstalled it via the command: synopkg uninstall medusa-1.1 and the package is no longer there, yet its still visible in the Package Center, and so when I try to uninstall git, it still believes that its installed.

Do you have any idea how I can remove the traces of the Medusa package from the package center?

BenjV commented 3 years ago

You clearly have some corruption in your system. So this has nothing to do with git versions.

You could try it from the commandline with this command:

sudo synopkg uninstall medusa

By the way the restart from within medusa does not work, so after an upgrade you need to start medusa from the Synology package center. It seems to work because the webserver is kept running but the actual medusa code does not restart.

sackman68 commented 3 years ago

Thanks for your response. I'm not sure why you conclude that there is a corruption in my system.
I'd like to ask your help to uninstall the Medusa package.

I performed:

sudo synopkg uninstall medusa

The result is that there are no traces of medusa here:

When I perform:

synopkg status medusa

The result is: No such package medusa Status: [255]

All of this would suggest that the medusa uninstall was successful, however when I perform:

synopkg list | sed 's/: .*$//'

medusa-1.1 remains in the list.

When I enter the Package Center, the Medusa entry is still visible. Only the uninstall option is possible. (The run option is no longer available.) When I select the uninstall option, the result is: "Failed to uninstall the package".

Would it be possible to run the uninstall script from the CLI, so that I could see what is causing the message?

BenjV commented 3 years ago

This is precise why I said that your system is corrupt. The package center still thinks medusa is present while it clearly is not, so Dsm is corrupted.

Did you try a reboot of your Nas?

sackman68 commented 3 years ago

I have tried a reboot and the situation remains. I've opened up a support ticket with Synology and here is their response:

The package "Medusa" is a 3rd party package and we're afraid we cannot provide troubleshoot for a 3rd party package. We suggest to re-isntall the DSM to have a clean DSM environment again and packages will needs to be installed afterwards. You can backup the DSM configuration from the control panel/ update&restore and restore the configuration after re-installation.

My DSM was not corrupted before I installed the Medusa package.
Have you successfully uninstalled the Medusa package, without getting the message:

"Failed to uninstall the package".

Are you able to help me debug why I'm getting this message, and perhaps help me to complete the uninstall?

BenjV commented 3 years ago

Sure many times did I install and remove the Medusa package on two different devices. I just tried it again on my DS116 with no problem at all. So I have no idea where your problem stem from.

Maybe just try to install it again?

zapru commented 3 years ago

after last update Of Medusa, I have warnings:

2021-01-19 15:53:02 WARNING DAILYSEARCHER :: [698ca1d] Manual search is running. Unable to start Daily search 2021-01-19 13:39:23 WARNING CHECKVERSION :: [698ca1d] git branch master --set-upstream-to origin/master returned : error: could not lock config file .git/config: File exists error: Unable to write upstream branch configuration hint: hint: After fixing the error cause you may try to fix up hint: the remote tracking information by invoking hint: "git branch --set-upstream-to=origin/master".. Treat as error for now 2021-01-19 13:39:21 WARNING CHECKVERSION :: [698ca1d] git config remote.origin.url https://github.com/pymedusa/Medusa returned : error: could not lock config file .git/config: File exists. Treat as error for now

Tailslide commented 3 years ago

I'm getting the same error after the most recent update.. the previous few updates applied fine I'm wondering if they broke something. I can't seem to find the lock file it's complaining about.

BenjV commented 3 years ago

Please ask this kind of questions on the medusa github. This is a medusa issue and has nothing to do with the Synology package.

sackman68 commented 3 years ago

I'm happy to report that all issues are resolved, including my uninstalling and reinstalling the package. There seems to be an incompatibility with Medusa (Branch: master / Commit: 698ca1db9903a9f716d9ed1910972cbf70ea50e8 / Version: 0.5.3) and Git version 2.28.0. When I uninstalled Medusa and Git 2.28.0 and then reinstalled Git 2.24.1 and Medusa. All issues were resolved. Also I am not getting the "git branch master" error reported by @zapru & @Tailslide.

I've described more details in my Medusa Ticket 9002

Thanks for your help @BenjV

BenjV commented 3 years ago

@sackman68 Nice everything is working again.

@zapru and @Tailslide It seems to me according to your warning something went wrong and a .lock file is left behind. My advice would be to stop medusa and manually remove all .lock files. I am not sure where they are located but start the search for .lock files at :

/var/packages/medusa/target/var/src/.git

Tailslide commented 3 years ago

My .git folder doesn't have any .lock files in it.

Sorry for discussing this here.. the medusa project keeps closing issues about this saying its not their problem. I also have git 2.28.0 so that may be the culprit. I'll try reverting it later.

BenjV commented 3 years ago

You must look in al subfolder too.

And it has nothing to do with git 2.28-16 That version is needed for TLS3 support and in the near future github will stop support for lower versions.

By the way your problem seems to be somewhat familiar to this one. https://github.com/pymedusa/Medusa/issues/9055

Tailslide commented 3 years ago

ls -alR | grep lock

returns nothing from the .git folder.

p0psicles commented 3 years ago

In the issue you mention, we noticed a bug where the update process was queued twice. So that could cause locks. That should be fixed in medusa develop branch