Update SABnzbd to 3.6.0

[Safihre]

Update SABnzbd to 3.6.0.

I also limited the size of the cross/p7zip dependency, which is only used by SABnzbd.

[hgy59]

@Safihre was sabnzbd ever able to use 7za that could not be found in the path?

[Safihre]

@Safihre was sabnzbd ever able to use 7za that could not be found in the path?

It was always able to find it, somehow it was in the PATH.

[Safihre]

Ah, before it found:

2022-04-29 09:55:10,867::INFO::[SABnzbd:471] 7za binary... found (/bin/7z)

Now it finds:

2022-06-15 13:27:48,704::INFO::[SABnzbd:471] 7za binary... found (/volume1/@appstore/sabnzbd/bin/7za)

Thanks @hgy59

[Safihre]

@th0ma7 For some reason the build fails on cryptography, even though it worked yesterday.
I can't figure out why.. do you see the difference?
Today: https://github.com/SynoCommunity/spksrc/actions/runs/2501879929
Yesterday: https://github.com/Safihre/spksrc/actions/runs/2474706131

[Safihre]

Right, the problem is in setuptools==62.4.0, which is installed by get-pip. See the changelog: https://github.com/pypa/setuptools/blob/main/CHANGES.rst

Strange, because after get-pip we install the old setuptools.. So seems it's keeping some old leftovers?

[Safihre]

@th0ma7 Seems we made a mistake, the get-pip.py "pip==21.3.1" is not how you can call the script, it always installs the latest pip.
However, it does have the ability to supply --no-setuptools --no-wheel parameters:
Safihre@c734828

But, it still doesn't work 😢
https://github.com/Safihre/spksrc/runs/6919748449?check_suite_focus=true

Seems maybe the problem is this latest pip version..

[th0ma7]

If I recall the only pip being installed as "latest" is at package installation time.
At build time I'll have to investigate a little more as all versions are fixed in cross/python310 and native/python310.
I'll run a few tests while playing with deluge PR to find out.

[th0ma7]

If I recall the only pip being installed as "latest" is at package installation time. At build time I'll have to investigate a little more as all versions are fixed in cross/python310 and native/python310. I'll run a few tests while playing with deluge PR to find out.

EDIT: And btw, setuptools==62.4.0 was tested against all crossenv wheels before merging... perhaps the issue is elsewhere.

[Safihre]

If I recall the only pip being installed as "latest" is at package installation time. At build time I'll have to investigate a little more as all versions are fixed in cross/python310 and native/python310. I'll run a few tests while playing with deluge PR to find out.

No, that's not what happens. Check the build logs and it can be seen in the content of get-pip.py. It controls which version is installed, and is regularly updated: https://bootstrap.pypa.io/get-pip.py

If we want to control exact the pip version, we should use python -m ensurepip and install the bundled old version and then update it to our specified that version.

I think we should also really apply my patch for setuptools and wheel: Safihre@c734828

But it all still doesn't fix cryptography.. If I rerun my exact old build that once succeeded (so not a single line of code changed) it now fails.. So something changed upstream.

Original build (success): https://github.com/Safihre/spksrc/actions/runs/2474706131/attempts/1
Attempt 2 of same commit (failure): https://github.com/Safihre/spksrc/actions/runs/2474706131/attempts/2

[Safihre]

Ok, fixed it!