jackdandy / sickgear Goto Github PK

Hi @Lukewh

For the last 24 hours, SnapCraft is showing refusal to build 4 of the 6 archs for SickGear. There are no changes to the SickGear build files. Do you have any idea what is wrong? Cheers.

Hi @JourneyOver

I was looking at Choco AU packagers and saw your collection focuses on automation tools of the type that is SickGear.

Of the Sick* folks, SickGear is differentiated with a focus on fostering a rock solid tool for ourselves and our user-base since 2014. I invite you to scan the main repo issue and commit tracker to get a feel to its quality. Can I ask if you would kindly consider making a Choco AU package for SickGear. I understand if it's not something for you, but thought I'd give it a go and ask. Anyway, thanks for considering.

JackDandy

Hi @clinton-hall

Hope you are well.

We made a couple major change to the SG repos this last month...

1. The default branch is now main (not master)
2. Python 3 is now the minimum required

Minor changes over the last few years since you published Asustor packages,
3) requirements.txt and recommended.txt are now in use

in checks, I saw a couple of potential issues and thought to reach out to you for help,

1. Maybe the Asustor package now fails due to 1+2 above.
2. The Qnap package you mentioned has not been updated, and someone reported it as failing

Your help is greatly appreciated, and if you can't look into the above, please help by letting me know so we can deprecate these.

JD

Hello @tbille @jkfran

The SSL certificate is failing at: https://www.rarlab.com/rar/unrarsrc-5.6.8.tar.gz

The snapcraft.yaml file contains...

  unrar:
    plugin: make
    source: https://www.rarlab.com/rar/unrarsrc-5.6.8.tar.gz
    source-type: tar

    build-packages:
      - to i386: ["g++:i386"]
      - to amd64: ["g++:amd64"]
      - to arm64: ["g++:arm64"]
      - to armhf: ["g++:armhf"]
      - to s390x: ["g++:s390x"]
      - to ppc64el: ["g++:ppc64el"]

This markup has worked 100% without change and without any issue for at least 2 years now.

Today, the package build failed with error...

Pulling unrar
+ snapcraftctl pull
Network request error: HTTPSConnectionPool(host='www.rarlab.com', port=443): Max retries exceeded with url: /rar/unrarsrc-5.6.8.tar.gz (Caused by SSLError(SSLError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:852)'),))
Build failed

So I reached out and asked rarlabs if they could fix what I thought was their SSL cert. Eugene promptly replied saying no cert issue was found according to this sslabs test and asked if it could be some network connectivity issue on my (Canonical) end.

Given that the issue will not be easily fixable, I would like to disable ssl_verify in the yaml file for that snapcraftctl pull part. Can you help?

Thank you for your time.

Hi @caronc

Failed to do a Windows test on cmd line...

... `apprise\apprise>python Apprise.py`

Traceback (most recent call last):
  File "Apprise.py", line 31, in <module>
    from .common import NotifyType
ValueError: Attempted relative import in non-package

Any ideas?

Thanks

Hi @caronc

(1)

... and send the notifications directly if you want. I mean you don't even have to do the QA on the URLs. Just provide a long blank so users can identify 1 or more (Apprise) URLs separated by comma's or spaces. Apprise will do all the legwork to detect one from another when you pass it into the library.

(2)

You can even hijack the notification logging and make it part of SABNzbd too. Anyway... just food for thought

This interests me greatly as it sounds nice and simple - but from your perspective!

We did add Apprise to SickGear way back, but only implemented a little bit of it, not realising about 1+2 above. Do you have an example or unittest of the above 2, that we can try and implement.