Page 61 of 66

Re: [Unofficial] Deluge 2.0.x installer

Posted: Fri Aug 07, 2020 3:55 am
by petersasi
Hi @Bobby,

If you look at the changelog in the README on the google drive, this was the first release with the new loaders:

### 31-Jul-2020 - 34% smaller, Win integration, portability&build fixes, new vers

2. Better Windows integration through alternative loaders, courtesy of @MHerz:

All installers with a date before that will not have those loaders.

Bobby wrote:I can confirm, that if we use the older version from the arhcive the plugins is working, both autoremoveplus and yarrs2 plugin. Just if anyone is having issiues like i did.

Btw petersasi and mhertz

Both of you are doing a huge job taking this on, i know there is not so much respons in the forum, but i know there is alot there is using this builds, and are deeply greatfull for the time and effort taking into this, thank you both alot

Re: [Unofficial] Deluge 2.0.x installer

Posted: Fri Aug 07, 2020 5:29 am
by petersasi
Okay, I will put these back in, at the same time I just realized this plugin is not part of the default 10 included so that is why it was not part of the profiling. :)
I might just add it to the installer build for simplicity. I went to it's site and saw there is no py38 version, so will probably need a renaming too.

Re: [Unofficial] Deluge 2.0.x installer

Posted: Fri Aug 07, 2020 11:37 am
by Bobby
You are correct sir, i just renamed the python version to 3.8 and it was all fine.

Re: [Unofficial] Deluge 2.0.x installer

Posted: Sat Aug 08, 2020 9:05 pm
by mhertz
Finally solved/workaround'ed the issue...

Because of the new loader which doesn't branch off into new thread, then was only getting the exe name when trying find the py file said exe was running(from 'inspect.stack()' call), and when then sent to for tokenizing, failed because was exe file and not py file. I checked manually with testing tokenizing the exe of the previous loader which also failed(python -m tokenize -e deluge.exe), so it was because of said missing to catch py file from exe file.

I looked into if could somehow patch without giving bad results to other stuff, but then found out another solution/workaround actually instead.

The reason why only that plugin failed and not others I tested, was the failing plugin used an older deprecated way of enabling logging, which fired off that inspect > tokenize failing step, and when changing to the newer method, then those steps aren't run and hence doesn't fail.

Deluge's source-file included following section additionally, I found by chance while reading through it:

Code: Select all

DEPRECATION_WARNING = """You seem to be using old style logging on your code, ie:
    from deluge.log import LOG as log

    from deluge.log import get_plugin_logger

This has been deprecated in favour of an enhanced logging system and both "LOG"
and "get_plugin_logger" will be removed on the next major version release of Deluge,
meaning, code will break, specially plugins.
If you're seeing this message and you're not the developer of the plugin which
triggered this warning, please report to it's author.
If you're the developer, please stop using the above code and instead use:

   import logging
   log = logging.getLogger(__name__)

I never gotten above deprecation warning message in my debug logs, which would have helped troubleshooting otherwise alot lol, and just found by chance when reading thru all the last referenced source-files in debug-log before the fail, and logging was the very last thing I troubleshooted/suspected and wasted much time on other parts i.e trying fix the failing step, and before that, one. I never gotten that warning, because the preceding part failed just before reaching it.

When I changed the logging in plugin to new, non-deprecated style and rebuilt it, then it worked fine, so I uploaded it, plus I will submit a PR fixing this, to tote94's github repo soon, probbaly tomorrow.

Also, there is another popular fork of this plugin from jools, which features some extra and different options, including Sonarr/Radarr/Lidarr support etc(though his fork can only be configured from webui, but works from everywhere though), which has same issue, so also rebuilt that with fixed logging and uploaded, and again will submit PR soon to jools also, against his github repo, with otherwise same fix. Note, this last fork from jools currently doesn't run in petersasi's version, since missing a single file:

Code: Select all


Lastly, as this isn't my project and i'm always somewhat affraid of overstepping my welcome here, or how to speak, then from now on i'll let petersasi alone handle things, which I know he's capable off anyway, so no reason for me interferring also, and so if needing my help for anything then ask me specifically, and i'll respond with my take on it also, if knowing anything about it of-sourse, that is :).

tote94's fork - fixed rebuild:

Jool's fork - fixed rebuild (As said, missing a file to get working currently):

Edit: Github doesn't support forking more than one fork at a time(of same original repo), which I could've worked around in hindsight, but anyway I think i'll just submit one PR at a time(not that good at git honestly), starting here with tote94's fork first:

Edit2: Submitted new ticket about this in meantime also on springjools github's issues section: ... /issues/32

Edit3: Hmm, I got to think about other plugins possibly also has this deprecated logging, so would be nice not needing rebuild those plugins to be able to be used with unofficial installer and to not need submitting PRs etc, so I looked to see if I could patch in deluge to not fail on this no-more. After knowing now what the issue actually is about, then I can google it now much more precisely, and I also read btw that exe's freezed with pyinstaller will also fail finding py from exe, through those inspect calls deluge also uses, so when official installer comes through, then will behave same as like with this new loader here I believe(so fail on same plugins), since uses pyinstaller for freezing. Anyway, there where some other code-changes suggested(not deluge related, but in general), and maybe that would work, I dunno, but honestly I used so much time on this already, so for now just slashed the failing code away and left the part where deluge logs a warning in log about the deprecated logging found and recommended a plugin rebuild, but atleast works then however. The code I slashed away was deluge trying to change the deprecated logging to the new logging, which it in the process failed in doing so.

If wanting to add this, then copy/paste in following new line e.g. just before the pycairo dll patch line, in both deluge build scripts(stable+dev):

Code: Select all

patch "%programfiles%/Deluge2/Lib/site-packages/deluge/" < logging.patch

(Change to match your setup of-course, i.e. I believe to remember you use 'deluge' folder instead of 'deluge2' now, in your scripts).

'logging.patch' to go into "C:\deluge2\deluge-build" folder:

just tested it working with vanilla plugins of autoremoveplus from tote94 and jools in my fresh rebuild of both deluge-stable and deluge-dev.

Re: [Unofficial] Deluge 2.0.x installer

Posted: Sat Aug 08, 2020 9:54 pm
by Bobby
Ok i just added youre fix of tote94's fork of autoremove+ and it works with latest version of petersasi deluge.

Btw is there anyway of doing the same fix to the yarrs2 plugin, even tho it python 3.7 and 3.6 its not possible to enable them in the gui ?

Re: [Unofficial] Deluge 2.0.x installer

Posted: Sat Aug 08, 2020 11:00 pm
by mhertz
I'm guessing you're talking to me, with that last comment(otherwise I apologize in advance - please everyone, use my name specifically when wanting a reply from me from now on, or else i'll avoid answering out of respect/etiquet)

The yarss2 issue is unrelated to this and was a matter of missing files and petersasi stated he would add them in his previous reply, so should be included in his next release.

Just in case needing them badly in meantime, i'll here upload an archieve of the missing files, and in the folders they should be in, so could be extracted directly into deluge's INSTALL-DIR i.e. by default: '%programfiles%\deluge', though needs admin-rights for that path however, and e.g. 7-zip isn't good at raising UAC prompt, don't know about winrar etc, but you could instead e.g. to override installed extractor-app then rightclick archieve and select 'open-with > windows explorer' and then select 'extract-all' and select INSTALL-DIR of deluge, and this will raise UAC prompt I checked, so easiest solution probably, in addition to just copy/paste manually etc. Lastly, get the py3.7 plugin, and rename to py3.8.

Re: [Unofficial] Deluge 2.0.x installer

Posted: Sun Aug 09, 2020 3:01 pm
by petersasi
Thanks MHerz for the extensive and successful debugging!

Let me build a new release tomorrow with the missing files (both yards and config parser too) and possibly the fixed plugins too if MHerz still has the patches available.

To me it seems much more forward looking not to hack apart a depreciation check (so that patch I will not apply) but to fix the plugins that use deprecated methods. That I am happy to do. :D

Re: [Unofficial] Deluge 2.0.x installer

Posted: Sun Aug 09, 2020 3:25 pm
by mhertz
Thanks :) The original deluge deprecation check is supposed to log a warning about this and run plugins anyway, whenever not being able to fix it firstly through monkey patching(dynamic run-time updating), but that curently fails and I just allowed it to do it's intended behaviour when that happens, instead of as now failing with a syntax error, though better way obviously would be fixing the failing code itself, but regardless. Sorry if you already knew that, and just wanted to clarify just in case. Though I understand if you also want to override that original intended deluge behaviour, by not applying patch. The part I removed will always fail with this loader and probably also in an official installer and will need fixing(I mean not fail a deprecation check, but actual failing python code i.e. code bug / syntax-error raised), and so never gets to the part about logging deprecation warning and continuing anyway, which wasen't my code, but deluge's I just allowed to run in said patch, by removing preceding buggy failing code.

I don't have patches for the plugins, only uploaded fixed plugins, but I can make for you if need, just give me a shout then, but as I have submitted PR/issue reports about this, then should be fixed anyways upstream soon, so not sure if worthwhile but your call. Ohh, the tote94 repo PR does of-course have the needed patch already in it, and so just missing the one for springjools fork, but as said, just give me a shout if needed later :)

Re: [Unofficial] Deluge 2.0.x installer

Posted: Mon Aug 10, 2020 11:30 am
by petersasi
Hi @MHerz,

Still working on the deluge paching and plugins' updates, in the meantime, can you please check your build for a few files?
It seems to me that even after a fresh GTK 3.24.21 build C:\deluge2\overlay\data\share\locale\en\LC_MESSAGES only has 2 files: and while:
C:\deluge2\overlay\data\share\locale\en@shaw\LC_MESSAGES has 5
C:\deluge2\overlay\data\share\locale\en_CA\LC_MESSAGES has 6
C:\deluge2\overlay\data\share\locale\en_GB\LC_MESSAGES has 7
All including the above 2.
And I do see this in the tried-to-open-but-not- found files.

Can this be a GTK build error, what do you think?

Re: [Unofficial] Deluge 2.0.x installer

Posted: Mon Aug 10, 2020 12:26 pm
by mhertz
I have the same scenario as you on my end. It was the same also in previous GTK release I just checked.

Sorry, I don't know why there's missing files referenced honestly, but it's normal atleast that the amount of files in these folders varies, e.g. on my linux system, I also have varying files, since the gtk3 package itself installs these two gtk3 files into these folders and then the other files added in varies folders are from other packages e.g. gtk3 deps or explicitly installed other packages adding localization files to the various locales, varying from package to package, e.g. as an example, on my linux system, I can see who owns i.e. installed, the different localization files:

Code: Select all

martin@arch ~ % pacqo /usr/share/locale/en{,@shaw,_CA,_GB}/LC_MESSAGES/*
/usr/share/locale/en/LC_MESSAGES/ is owned by gtk3 1:3.24.21-1
/usr/share/locale/en/LC_MESSAGES/ is owned by gtk3 1:3.24.21-1
/usr/share/locale/en/LC_MESSAGES/ is owned by iso-codes 4.5.0-1
/usr/share/locale/en/LC_MESSAGES/ is owned by iso-codes 4.5.0-1
/usr/share/locale/en/LC_MESSAGES/ is owned by yay-bin 10.0.3-1
/usr/share/locale/en@shaw/LC_MESSAGES/ is owned by atk 2.36.0-1
/usr/share/locale/en@shaw/LC_MESSAGES/ is owned by gdk-pixbuf2 2.40.0+6+g5432316df-1
/usr/share/locale/en@shaw/LC_MESSAGES/ is owned by glib2 2.64.4-1
/usr/share/locale/en@shaw/LC_MESSAGES/ is owned by gtk3 1:3.24.21-1
/usr/share/locale/en@shaw/LC_MESSAGES/ is owned by gtk3 1:3.24.21-1
/usr/share/locale/en_CA/LC_MESSAGES/ is owned by at-spi2-core 2.36.0-1
/usr/share/locale/en_CA/LC_MESSAGES/ is owned by atk 2.36.0-1
/usr/share/locale/en_CA/LC_MESSAGES/ is owned by avahi 0.8+15+ge8a3dd0-1
/usr/share/locale/en_CA/LC_MESSAGES/ is owned by gdk-pixbuf2 2.40.0+6+g5432316df-1
/usr/share/locale/en_CA/LC_MESSAGES/ is owned by glib-networking 2.64.3-2
/usr/share/locale/en_CA/LC_MESSAGES/ is owned by glib2 2.64.4-1
/usr/share/locale/en_CA/LC_MESSAGES/ is owned by gtk2 2.24.32-2
/usr/share/locale/en_CA/LC_MESSAGES/ is owned by gtk2 2.24.32-2
/usr/share/locale/en_CA/LC_MESSAGES/ is owned by gtk3 1:3.24.21-1
/usr/share/locale/en_CA/LC_MESSAGES/ is owned by gtk3 1:3.24.21-1
/usr/share/locale/en_GB/LC_MESSAGES/ is owned by at-spi2-core 2.36.0-1
/usr/share/locale/en_GB/LC_MESSAGES/ is owned by atk 2.36.0-1
/usr/share/locale/en_GB/LC_MESSAGES/ is owned by avahi 0.8+15+ge8a3dd0-1
/usr/share/locale/en_GB/LC_MESSAGES/ is owned by colord 1.4.4+9+g1ce26da-2
/usr/share/locale/en_GB/LC_MESSAGES/ is owned by gdk-pixbuf2 2.40.0+6+g5432316df-1
/usr/share/locale/en_GB/LC_MESSAGES/ is owned by glib-networking 2.64.3-2
/usr/share/locale/en_GB/LC_MESSAGES/ is owned by glib2 2.64.4-1
/usr/share/locale/en_GB/LC_MESSAGES/ is owned by gsettings-desktop-schemas 3.36.1-1
/usr/share/locale/en_GB/LC_MESSAGES/ is owned by gst-plugins-base-libs 1.16.2-2
/usr/share/locale/en_GB/LC_MESSAGES/ is owned by gstreamer 1.16.2-2
/usr/share/locale/en_GB/LC_MESSAGES/ is owned by gtk2 2.24.32-2
/usr/share/locale/en_GB/LC_MESSAGES/ is owned by gtk2 2.24.32-2
/usr/share/locale/en_GB/LC_MESSAGES/ is owned by gtk3 1:3.24.21-1
/usr/share/locale/en_GB/LC_MESSAGES/ is owned by gtk3 1:3.24.21-1
/usr/share/locale/en_GB/LC_MESSAGES/ is owned by json-glib 1.4.4-2
/usr/share/locale/en_GB/LC_MESSAGES/ is owned by pacman 5.2.2-1
/usr/share/locale/en_GB/LC_MESSAGES/ is owned by glibc 2.31-5
/usr/share/locale/en_GB/LC_MESSAGES/ is owned by libsecret 0.20.3-1
/usr/share/locale/en_GB/LC_MESSAGES/ is owned by libsoup 2.70.0-1
/usr/share/locale/en_GB/LC_MESSAGES/ is owned by libp11-kit 0.23.20-5
/usr/share/locale/en_GB/LC_MESSAGES/ is owned by pacman 5.2.2-1
/usr/share/locale/en_GB/LC_MESSAGES/ is owned by pacman 5.2.2-1
/usr/share/locale/en_GB/LC_MESSAGES/ is owned by shared-mime-info 2.0+1+g6bf9e4f-2
/usr/share/locale/en_GB/LC_MESSAGES/ is owned by xkeyboard-config 2.30-2
martin@arch ~ %