*OLD-THREAD - SEE NEW* [Unofficial] Deluge 2.0.x installer

Specific support for Deluge on Microsoft Windows OS
petersasi
Leecher
Leecher
Posts: 93
Joined: Sun Nov 17, 2019 8:09 am

Re: [Unofficial] Deluge 2.0.x installer [Unmaintained/unsupported]

Postby petersasi » Tue May 26, 2020 11:56 am

Thanks, took some time but I read through all your posts, although I am quite sure I will later have to circle back for details. Downloaded the packages, bookmarked the release pages to watch and now going to start install-components as Administrator with a large CMD buffer just in case. :)

Fingers crossed will report back: just one quesiton:

do you always re-download / git check-out the latest tracked version (master / dev / etc) or the release watcing and updating, downloading of the newer versions have to be done manually each time there is one?

Thanks for all the work!

mhertz wrote:The stable deluge build script, previously builded from latest release tag on git, but was hard for me to find out how to script be automatic between updates, so had to update a variable every time new version came(I think I can now though, like I do with python, but previously had issues when trying). Then I found I didn't even have too, because in deluge, then master branch is latest stable, so latest commit of master branch is last commit of deluge 2.0.3 currently, so that is why I use master in there, but it is in fact stable release.

BTW, I used to use cygwin as didn't have msys2 in beginning as couldn't build gvsbuild in beginning and just used Cas's last build. Anyway it needed forward slashes for patch.exe, hence script uses such still, even though supported in windows backwards way in msys2.

I used a dos notion of program files one place, as was specifically needed, as double quotes didn't work, and tried all things possible, where only that worked, as issue in python function in path with spaces.

Someplaces, because I added %programfiles% to a path for patch, then slashes are mixed, both regular and backwards, but it works still, and so was to lazy to change.

Not important, but some things look strange, but usually isn't an oversight, but just needed, or lazyness from changing old to new.

Also, deluge scripts use %programfiles%, whereas all others do not, for python install, and again was from old times, soon a year ago, where I provided batchfiles to install deluge2, in another thread not of mine, and didn't bothered change, as made no difference in end result and I would need edit 30 lines or so, to change,for no functional reason.

For libtorrent's, I originally tested almost 10 different boost versions, and only one worked for me, so stuck to that, and there's a range of supported boost versions for each branch of libtorrent, and the ones I use are within range, and I also saw suggested by others to be working good for them on libtorrent mailing-list. There's always a bunch of warnings displayed during building those, which you should simply ignore and is normal. If actual error happens, the building will fully stop and not produce any end result I.e libtorrent.pyd, and so if a libtorrent.pyd is produced then it is working. I think I made around 100 runs initially to get those libtorrent's to build to end, as had no experience either with such and depends on combinations used of your used versions of libtorrent, boost, python and msvc. Luckily I got it down to one msvc version recently, instead of 2 or 3, as each is 3.5gb install size as also includes windows sdk and such.

Forgot to say initially, that you should expect about 4.5 used install-size from running install-components.cmd batch file, where most is msvc(3.5gb roughly) and msys2(900'ish mb reported from windows properties dialog, though read windows has issues calculating such properly because of hardlinks and whatnot, and also seem very excessive to me, so actual size is around 600mb as calculated by 'du -h C:\msys64' linux command, and where additionally an extra hundred could be shaved off to clear cache, which I almost did from install_components.cmd, but decided against in end, as usually is recommended against i.e. not cleaning other older versions fom cache, which of-course is fine, but actually cleaning the single version of each installed package stored there, which is advised against for being able to revert back to working version again if an update F's something up on your system. This is a needed component for gvsbuild anyway, hence I install in that also git, patch and diff and such too, instead of installing/using cygwin or git for windows etc). If wanting save the around 100mb for cache, and it shouldn't honestly hurt in our case here regardless, as not updating msys2 after initial install/update, atleast not from my scripts(and is just tools used during, and not going to be included in the build deluge or components), then you can run this from a command-prompt, or win+r dialog, and not need admin rights for this:

Code: Select all

C:\msys64\usr\bin\pacman.exe -Scc --noconfirm

That line could also be added to install_components.cmd if wanted, somewhere after the msys2 install and update part, for future use).

If you want, you can add new line with:

Code: Select all

 
pause

As last line to all scripts, so they don't close when finished, and so you can see if error'ed out or not, and which I always do during testing, but not afterwards as I e.g sometimes start scripts from my Linux system, where I have setup a system where I run a command with the scripts I want run after each other and then the win10 VM is started headless in background and batch-files are run in there and close VM afterwards, but that would not work if using such pause command as each script would block the next script from running as would need a key press to continue to next script and not be automatic anymore.

You can make own scripts for different scenarios, where you make new text file ending in bat or cmd, and add on each line "call pathToScriptToRun" and repeat new lines of that underneath, with each new script you want run after eachother, and then rightclick/run-as-admin for that new script, just like you would do with the others, so e.g one script which build all, another which build only this and that, etc, but there's too many combinations for doing that for all scenarios, so I didn't include that in archive, as couldn't decide either which scenarios to include and which not to.

mhertz
Compulsive Poster
Compulsive Poster
Posts: 841
Joined: Wed Jan 22, 2014 5:05 am
Location: Denmark

Re: [Unofficial] Deluge 2.0.x installer [Unmaintained/unsupported]

Postby mhertz » Tue May 26, 2020 12:35 pm

You're welcome, thank you too for voluntering :)

I'm sorry, i'll try from now on keep things strictly short(short for me ;) ), and then i'll just let you answer questions specifically and i'll answer. You can just answer new questions again, you don't need reread all older posts if not wanting.

Anyway, yeah, every time you run a build-script then finds, downloads, installs or checksout latest components of deluge, libtorrent, python, gvsbuild, and I believe that was it. There's still a few things I do manually that I honestly forgot here, and haven't implemented automatic scripting for, and that is at times I check if there is an openssl update and if there are then I download and install that and need copy the updated libcrypto*.dll and libssl*.dll from C:\OpenSSL-Win64 and into/overwrite the olds from: C:\deluge2\overlay\lib\site-packages, and that is enough if then rebuilding deluge afterwards, but if not wanting rebuild deluge as if no updates to deluge, then also paste/overwrite into the two "old" build deluge folders, if available, under C:\deluge2 folder in same dir as before(lib\site-packages).

https://slproweb.com/products/Win32OpenSSL.html (should be exe installer and not a light one, probably usually always number 2 link from top, and always install on-top of old, and don't uninstall old first, as I specifically made the install path work for libtorrent by default and so direct updates inherent that, but fresh installs default to %programfiles% instead). You don't need to update openssl all the time either, and it's not that often updated either.

Other than that, you shouldn't need change anything whenever updates come, and links was just to know when to fire build-scripts up again. Well, not after every update, but just when updates available and "feeling for it". I was little to excessive wih it honestly, and so you just decide yourself what your updating style will be as your perogatory of course(most probably wrong word there :) ).

It could be made smarter, for sure, and so not reclone and instead just pull changes from last time etc, but atleast it works, and so just kept it like that and always does other things anyway during the building, so doesn't matter to me if taking little extra time.

There's still the chance however, that something e.g. patch or watnot, can break after some big update, and will need fixing somehow, but normally it should just work, unless being unfortunate in that situation.

Hope it works for you :)

mhertz
Compulsive Poster
Compulsive Poster
Posts: 841
Joined: Wed Jan 22, 2014 5:05 am
Location: Denmark

Re: [Unofficial] Deluge 2.0.x installer [Unmaintained/unsupported]

Postby mhertz » Tue May 26, 2020 2:13 pm

Instead of the manual work needed for openssl upgrades which I forgot before, then I have made a new buildscript for that:

http://s000.tinyupload.com/index.php?fi ... 1646550939

Extract into your C:\deluge2 folder and you then have a new folder named openssl-build with openssl.cmd inside, which you rightclick and run as admin, as need that for installing openssl.

It finds latest openssl and downloads/installs it and copies the two needed dll's over and overwrites the old ones in the three different subdirs(overlay, deluge-stable and deluge-dev), and deletes the openssl installer afterwards.

I have tested that it works a couple of times already :)

Edit:

@all,

I just realized something because of a conversation on gvsbuild github issues section. I have previously said "CU around the forums", which was my clumsy way to say/mean "around other subsections of this forum", and not about other forums than deluge forum, as was thinking this thread here would die out soon, and since I'm usually on other sections than windows section, I believe, except this thread here of-course.

Not that it matters whatsoever, lol, but just wanted to clarify so it doesn't sound like I cannot make up my mind :lol:

User avatar
adelphiaUK
New User
New User
Posts: 8
Joined: Sun Jul 29, 2018 11:30 am
Location: Hayling Island, United Kingdom
Contact:

Re: [Unofficial] Deluge 2.0.x installer [Unmaintained/unsupported]

Postby adelphiaUK » Tue May 26, 2020 6:11 pm

Just posting so I can follow / subscribe so you know I'm keeping my beady eyes open on developments.
Chris
Image

mhertz
Compulsive Poster
Compulsive Poster
Posts: 841
Joined: Wed Jan 22, 2014 5:05 am
Location: Denmark

Re: [Unofficial] Deluge 2.0.x installer [Unmaintained/unsupported]

Postby mhertz » Wed May 27, 2020 1:18 am

Glad to see you here too mate, and appreciate you posting :)

petersasi
Leecher
Leecher
Posts: 93
Joined: Sun Nov 17, 2019 8:09 am

Overall build progress

Postby petersasi » Wed May 27, 2020 5:40 am

Hi downloaded this and extracted into c:\deluge2

Running it reveals an msys git error: "msys prcedure entry point "uname_x "could not be located in the dynamic link library c:\msys64\usr\bin\git.exe"
Any chance you have also encountered that?
EDIT: resolved by manually deleting the complete c:\msys64, re-extracting the .tar and running the 3 commands in the script manually, now git.exe ran as expected.

I have also modified your:
  1. install_components.cmd
  2. openssl.cmd
  3. gvsbuild.cmd
  • commented out the del at the end to keep install packages
  • added -C - to all file downloading curl commands, but not the http://www.python.org page scraper :D to resume / skip their downloads should the local file exist.
I have space and for some reason these downloads tool several minutes each for me (otherwise I am on a gigabit fiber upling, all copper ethernet LAN, so speedtest.net does 900+Mbit/s in both DL and UL - wierd but this way I have achieved fast restartability.

Next step is trying all builds, what is the preferred order?
  1. OpenSSL - DONE
  2. GTK - DONE
  3. Libtorrent 1.1.x - DONE
  4. Libtorrent 1.2.x - DONE
  5. deluge2-stable -DONE
  6. deluge2-dev - DONE
  7. build both installers - DONE
Would this be correct?

Thanks!

mhertz wrote:Instead of the manual work needed for openssl upgrades which I forgot before, then I have made a new buildscript for that:

http://s000.tinyupload.com/index.php?fi ... 1646550939

Extract into your C:\deluge2 folder and you then have a new folder named openssl-build with openssl.cmd inside, which you rightclick and run as admin, as need that for installing openssl.

It finds latest openssl and downloads/installs it and copies the two needed dll's over and overwrites the old ones in the three different subdirs(overlay, deluge-stable and deluge-dev), and deletes the openssl installer afterwards.

I have tested that it works a couple of times already :)

Edit:

@all,

I just realized something because of a conversation on gvsbuild github issues section. I have previously said "CU around the forums", which was my clumsy way to say/mean "around other subsections of this forum", and not about other forums than deluge forum, as was thinking this thread here would die out soon, and since I'm usually on other sections than windows section, I believe, except this thread here of-course.

Not that it matters whatsoever, lol, but just wanted to clarify so it doesn't sound like I cannot make up my mind :lol:
Last edited by petersasi on Thu May 28, 2020 7:22 am, edited 5 times in total.

petersasi
Leecher
Leecher
Posts: 93
Joined: Sun Nov 17, 2019 8:09 am

GTK build falied

Postby petersasi » Wed May 27, 2020 7:06 am

While building GTK Python told me:

Code: Select all

WARNING: You are using pip version 19.2.3, however version 20.1.1 is available.
You should consider upgrading via the 'python -m pip install --upgrade pip' command.

Do you think I should add that upgrade command to the script?

I have added and echo on after the call to vcvars.bat so that I can see what goes wrong. What is see is python fails the build GTK:

Code: Select all

C:\gtk-build\github\gvsbuild>python build.py -d build --gtk3-ver=3.24 --archives-download-dir=C:\gtk-cache --vs-ver=16 --platform=x64 --vs-install-path="c:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools" --python-dir=C:\python -k --enable-gi --py-wheel --py-egg --python-ver=3.8.3 enchant gtk gtk3-full pycairo pygobject lz4 --skip gtksourceview3,emeus,clutter,adwaita-icon-theme
Log directory C:\gtk-build\logs created
Debug: Version from file name:                 <- rustup-init.exe
Debug: Version from file name:3.7.2            <- cmake-3.7.2-win64-x64.zip
Debug: Version from file name:0.52.0           <- meson-0.52.0.zip
Debug: Version from file name:2.13.03          <- nasm-2.13.03-win64.zip
Debug: Version from file name:1.8.2            <- ninja-win-1.8.2.zip
Debug: Version from file name:5.4.0            <- nuget-5.4.0.exe
Debug: Version from file name:5.20.0           <- perl-5.20.0-x64.tar.xz
Debug: Version from file name:1.3.0            <- yasm-1.3.0-win64.exe
Debug: Version from file name:1.10             <- go1.10.windows-amd64.zip
Debug: Version from file name:3.36.0           <- adwaita-icon-theme-3.36.0.tar.xz
Debug: Version from file name:2.36.0           <- atk-2.36.0.tar.xz
Debug: Version from file name:1.16.0           <- cairo-1.16.0.tar.xz
Debug: Version from file name:1.26.4           <- clutter-1.26.4.tar.xz
Debug: Version from file name:1.22.6           <- cogl-1.22.6.tar.xz
Debug: Version from file name:2.1.28           <- cyrus-sasl-2.1.28.tar.xz
Debug: Version from file name:0.1.8            <- dcv-color-primitives-0.1.8.tar.gz
Debug: Version from file name:1.6.1            <- enchant-1.6.1.tar.xz
Debug: Version from file name:4.2.2            <- ffmpeg-4.2.2.tar.xz
Debug: Version from file name:2.13.0           <- fontconfig-2.13.0.tar.gz
Debug: Version from file name:098dd70cb1845b8c325ef4801c5f2e09e476b1ed <- freetype2-098dd70cb1845b8c325ef4801c5f2e09e476b1ed.tar.gz
Debug: Version from file name:2.40.0           <- gdk-pixbuf-2.40.0.tar.xz
Debug: Version from file name:0.19.7           <- gettext-0.19.7.tar.gz
Debug: Version from file name:2.64.2           <- glib-2.64.2.tar.xz
Debug: Version from file name:2.64.1           <- glib-networking-2.64.1.tar.xz
Debug: Version from file name:2.50.8           <- glib-openssl-2.50.8.tar.xz
Debug: Version from file name:1.64.1           <- gobject-introspection-1.64.1.tar.xz
Debug: Version from file name:3.36.0           <- gsettings-desktop-schemas-3.36.0.tar.xz
Debug: Version from file name:1.16.2           <- gstreamer-1.16.2.tar.xz
Debug: Version from file name:1.16.2           <- gst-plugins-base-1.16.2.tar.xz
Debug: Version from file name:1.16.2           <- gst-plugins-good-1.16.2.tar.xz
Debug: Version from file name:1.16.2           <- gst-plugins-bad-1.16.2.tar.xz
Debug: Version from file name:1.16.2           <- gst-python-1.16.2.tar.xz
Debug: Version from file name:2.24.31          <- gtk+-2.24.31.tar.xz
Debug: Version from file name:3.22.2           <- gtksourceview-3.22.2.tar.xz
Debug: Version from file name:2.6.4            <- harfbuzz-2.6.4.tar.xz
Debug: Version from file name:0.17             <- hicolor-icon-theme-0.17.tar.xz
Debug: Version from file name:2.0.14           <- jasper-2.0.14.tar.gz
Debug: Version from file name:0.12.1-20160607  <- json-c-0.12.1-20160607.tar.gz
Debug: Version from file name:1.4.4            <- json-glib-1.4.4.tar.xz
Debug: Version from file name:1.20             <- leveldb-1.20.tar.gz
Debug: Version from file name:3.4.1            <- libarchive-3.4.1.tar.xz
Debug: Version from file name:0.6.13           <- libcroco-0.6.13.tar.xz
Debug: Version from file name:1.5.3            <- libepoxy-1.5.3.tar.xz
Debug: Version from file name:0.3.1            <- libgxps-0.3.1.tar.xz
Debug: Version from file name:2.0.4            <- libjpeg-turbo-2.0.4.tar.gz
Debug: Version from file name:0.9.54           <- libmicrohttpd-0.9.54.tar.gz
Debug: Version from file name:1.6.37           <- libpng-1.6.37.tar.xz
Debug: Version from file name:2.40.20          <- librsvg-2.40.20.tar.xz
Debug: Version from file name:7.54.0           <- curl-7.54.0.tar.gz
Debug: Version from file name:2.70.0           <- libsoup-2.70.0.tar.xz
Debug: Version from file name:0.9.3            <- libssh-0.9.3.tar.xz
Debug: Version from file name:1.8.0            <- libssh2-1.8.0.tar.gz
Debug: Version from file name:4.1.0            <- tiff-4.1.0.tar.gz
Debug: Version from file name:1.35.0           <- v1.35.0.tar.gz
Debug: Version from file name:2.9.10           <- libxml2-2.9.10.tar.gz
Debug: Version from file name:1.2.0            <- libzip-1.2.0.tar.gz
Debug: Version from file name:2.1.0            <- LuaJIT-2.1.0-beta3.tar.gz
Debug: Version from file name:1.9.2            <- lz4-1.9.2.tar.gz
Debug: Version from file name:1.16.1           <- krb5-1.16.1-final.tar.gz
Debug: Version from file name:1.1.1g           <- openssl-1.1.1g.tar.gz
Debug: Version from file name:1.3.1            <- opus-1.3.1.tar.gz
Debug: Version from file name:0.4.31           <- orc-0.4.31.tar.xz
Debug: Version from file name:1.44.7           <- pango-1.44.7.tar.xz
Debug: Version from file name:0.38.4           <- pixman-0.38.4.tar.gz
Debug: Version from file name:190600_20161030  <- pa_stable_v190600_20161030.tgz
Debug: Version from file name:3.9.2            <- protobuf-cpp-3.9.2.tar.gz
Debug: Version from file name:1.3.2            <- protobuf-c-1.3.2.tar.gz
Debug: Version from file name:1.19.1           <- pycairo-1.19.1.tar.gz
Debug: Version from file name:3.36.0           <- pygobject-3.36.0.tar.xz
Debug: Version from file name:3310100          <- sqlite-autoconf-3310100.tar.gz
Debug: Version from file name:0.0.8            <- win-iconv-0.0.8.tar.gz
Debug: Version from file name:3.4              <- wing-v0.3.4.tar.gz
Debug: Version from file name:1.2.11           <- zlib-1.2.11.tar.xz
Debug: Options are:
  '_load_python': False,
  '_vs_path_auto': False,
  'archives_download_dir': 'C:\gtk-cache',
  'build_dir': 'C:\gtk-build',
  'capture_out': False,
  'cargo_opts': '',
  'check_hash': False,
  'clean': False,
  'clean_built': False,
  'configuration': 'release',
  'debug': True,
  'enable_gi': True,
  'fast_build': False,
  'ffmpeg_enable_gpl': False,
  'from_scratch': False,
  'git_expand_dir': 'C:\gtk-cache\git-exp',
  'gtk3_ver': '3.24',
  'keep': True,
  'keep_tools': False,
  'log_single': False,
  'log_size': 0,
  'make_zip': False,
  'msbuild_opts': '',
  'msys_dir': 'C:\Msys64',
  'ninja_opts': '',
  'no_deps': False,
  'patches_root_dir': 'C:\gtk-build\github\gvsbuild\patches',
  'platform': 'x64',
  'print_out': False,
  'projects': ['enchant', 'gtk', 'gtk3-full', 'pycairo', 'pygobject', 'lz4'],
  'py_egg': True,
  'py_wheel': True,
  'python_dir': 'C:\python',
  'python_ver': '3.8.3',
  'same_python': False,
  'skip': 'gtksourceview3,emeus,clutter,adwaita-icon-theme',
  'tools_root_dir': 'C:\gtk-build\tools',
  'use_env': False,
  'verbose': False,
  'vs_install_path': 'c:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools',
  'vs_ver': '16',
  'win_sdk_ver': None,
  'zip_continue': False,
Cleaning up the build environment
Debug: windir -> c:\\windows
Debug:    Skip 'c:\program files (x86)\microsoft visual studio\2019\buildtools\vc\tools\msvc\14.26.28801\bin\hostx64\x64'
Debug:    Skip 'c:\program files (x86)\microsoft visual studio\2019\buildtools\common7\ide\commonextensions\microsoft\testwindow'
Debug:    Skip 'c:\program files (x86)\microsoft visual studio\2019\buildtools\msbuild\current\bin\roslyn'
Debug:    Skip 'c:\program files (x86)\windows kits\10\bin\10.0.18362.0\x64'
Debug:    Skip 'c:\program files (x86)\windows kits\10\bin\x64'
Debug:    Skip 'c:\program files (x86)\microsoft visual studio\2019\buildtools\msbuild\current\bin'
Debug: Add 'c:\windows\microsoft.net\framework64\v4.0.30319'
Debug:    Skip 'c:\program files (x86)\microsoft visual studio\2019\buildtools\common7\ide'
Debug:    Skip 'c:\program files (x86)\microsoft visual studio\2019\buildtools\common7\tools'
Debug:    Skip 'c:\python'
Debug:    Skip 'c:\python\scripts'
Debug:    Skip 'c:\gtk-build\gtk\x64\release\bin'
Debug:    Skip 'c:\msys64\usr\bin'
Debug:    Skip 'c:\program files (x86)\microsoft visual studio\2019\buildtools\vc\tools\msvc\14.26.28801\bin\hostx64\x64'
Debug:    Skip 'c:\program files (x86)\microsoft visual studio\2019\buildtools\common7\ide\commonextensions\microsoft\testwindow'
Debug:    Skip 'c:\program files (x86)\microsoft visual studio\2019\buildtools\msbuild\current\bin\roslyn'
Debug:    Skip 'c:\program files (x86)\windows kits\10\bin\10.0.18362.0\x64'
Debug:    Skip 'c:\program files (x86)\windows kits\10\bin\x64'
Debug:    Skip 'c:\program files (x86)\microsoft visual studio\2019\buildtools\msbuild\current\bin'
Debug:    Already present: 'c:\windows\microsoft.net\framework64\v4.0.30319'
Debug:    Skip 'c:\program files (x86)\microsoft visual studio\2019\buildtools\common7\ide'
Debug:    Skip 'c:\program files (x86)\microsoft visual studio\2019\buildtools\common7\tools'
Debug:    Skip 'c:\python'
Debug:    Skip 'c:\python\scripts'
Debug:    Skip 'c:\gtk-build\gtk\x64\release\bin'
Debug:    Skip 'c:\msys64\usr\bin'
Debug:    Skip 'c:\msys64\usr\bin'
Debug:    Skip 'c:\msys64\usr\bin'
Debug: Add 'c:\windows\system32'
Debug: Add 'c:\windows'
Debug: Add 'c:\windows\system32\wbem'
Debug: Add 'c:\windows\system32\windowspowershell\v1.0'
Debug: Add 'c:\windows\system32\openssh'
Debug:    Skip 'c:\users\pétersasi\appdata\local\microsoft\windowsapps'
Debug:    Skip 'c:\program files (x86)\microsoft visual studio\2019\buildtools\common7\ide\commonextensions\microsoft\cmake\cmake\bin'
Debug:    Skip 'c:\program files (x86)\microsoft visual studio\2019\buildtools\common7\ide\commonextensions\microsoft\cmake\ninja'
Debug:    Skip 'c:\program files (x86)\microsoft visual studio\2019\buildtools\common7\ide\commonextensions\microsoft\cmake\cmake\bin'
Debug:    Skip 'c:\program files (x86)\microsoft visual studio\2019\buildtools\common7\ide\commonextensions\microsoft\cmake\ninja'
Debug: Final path:
Debug:     c:\windows\microsoft.net\framework64\v4.0.30319
Debug:     c:\windows\system32
Debug:     c:\windows
Debug:     c:\windows\system32\wbem
Debug:     c:\windows\system32\windowspowershell\v1.0
Debug:     c:\windows\system32\openssh
Checking msys tool
Debug: patch: C:\Msys64\usr\bin\patch.exe
Checking Msvc tool
Running script "c:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Auxiliary\Build\vcvars64.bat"
Debug: vs env:ALLUSERSPROFILE -> [C:\ProgramData]
Traceback (most recent call last):
  File "build.py", line 48, in <module>
    args.func(args)
  File "C:\gtk-build\github\gvsbuild\gvsbuild\utils\parser.py", line 160, in do_build
    builder = Builder(opts)
  File "C:\gtk-build\github\gvsbuild\gvsbuild\utils\builder.py", line 86, in __init__
    self.__check_vs(opts)
  File "C:\gtk-build\github\gvsbuild\gvsbuild\utils\builder.py", line 369, in __check_vs
    l = l.decode('utf-8') if isinstance(l, bytes) else l
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x82 in position 18: invalid start byte
Last edited by petersasi on Thu May 28, 2020 2:08 am, edited 1 time in total.

mhertz
Compulsive Poster
Compulsive Poster
Posts: 841
Joined: Wed Jan 22, 2014 5:05 am
Location: Denmark

Re: [Unofficial] Deluge 2.0.x installer [Unmaintained/unsupported]

Postby mhertz » Wed May 27, 2020 12:30 pm

Sorry to hear you're having problems :(

First the initial points out of the way; You can add upgrade command for pip if wanted, that's fine, though I didn't bother since as it worked fine without, and built end-result doesn't change in any way regardless, but doesn't hurt either of-course to add/use. As said, i'm the lazy type honestly ;)

For the most part, the downloads are fast for me, with 300mbit down line, but sometimes a download site is really slow, don't know if they rotate mirrors internally or what-have-you, but ussually for me is fast enough 30 secs max roughly, per download, and that's max.

Cool that you change the scripts to your liking, good job :) In openssl script I found a nicer way to find latest stable version, which I didn't knew when making the python-install part of rest of scripts, which awkwardly scrapes main python page(as you noticed :D ), but works atleast. The more standard ways often don't work, e.g. the "latest" method from github release page, as e.g. there's RC versions posted amongst stable etc, though I guess I could just use RC for python too, but haven't yet though. Anyway, I wasen't even thinking about python also being in a git-repo, which makes it easier to extract in end.

That msys error I have never had, very strange, and have run all script several times after making/fixing-up them, and all sucessfully. Hmm, come to think of it, i'm pretty sure you have some dll which git uses, somewhere in your path, usually system32 or elsewhere defined in PATH, which messes it up/conflicts, as remember people having same kinda type error from deluge2 reports in older times, before changing to py38 which fixed it, and I before workarounded it as good as I could when I could find conflicting dll. I'm reffering to error regarding missing entry-point in xxx, usually xxx is not the culprit, but some dll it depends on which is used in wrong version from other place. Sorry I don't know what dll it could be, but at same time as it worked when running it manually, then it doesn't sound like that either??? Or somehow the msys folder became corrpuped somehow as worked again after you re-extracted it and re-run commands manually??? Sorry don't know, and have just uninstalled and reinstalled again without anything like that, and all fine. Btw, you need really big scrollback buffer to catch all output from a gvsbuild run, and changing the cmd prompt settings to max buffer isn't enough, but you can add as last two extra commands to build.py in gvsbuild.cmd: '--capture-out --print-out', which though will make the screen-output not run down as "fluid" as before, during the build while watching it, but after the build, then you will have a complete log of everything on screen in: C:\gtk-build\logs\gvsbuild-log.txt. Without those added commands. you will not get full output in that log and only a small portion off it, which often doesn't help, as omits actual error line often. The file gets rewritten upon each run, with those commands added. I just retested again, which I could see worked as usual on screen during and testing running deluge with it afterwards, and I had added these commands to make full log, but after the build then the log wasen't there, as I had forgot that I delete the folder where e.g. log is stored, so if doing that, then you would need remove the 'rd /s /q' of C:\gtk-build folder, but after checking log or copying elsewhere, then delete the folder, or add such delete command(rd /s /q, prefferably twise after eachother in new line) in beginning of script somewhere, as it's reused if available upon next gvsbuild runs, and sometimes will fail because of that. Well, there is another command that could be added I believe for build.py, for starting fully fresh regardless(--from-scratch, or alike, check docs if needing it, or ask me for finding it), but nonetheless, just for complete info on it.

The order of scripts doesn't matter whatsoever, and the only thing is that you obviously need build installer(s) after updating deluge and/or one of it's components i.e. if building installers first and afterwards upgrading deluge and/or components, then obviously would not have the updated deluge/components included in installers, before next time running installer-buildings, but that is pretty self-evident I presume. Other than that, then components are copied to overlay folder when finished building, and when building deluge then it inherents overlay contents(copied-over), so have the new components, so order doesn't matter. Also, as said before, already build deluge(s) gets new components copied into them and overwrite old, in addition to being copied to overlay for feature use. So you just run whatever script for whatever is updated at that time, and if wanted, builds installers afterwards to include it, or just waits more time if wanting include more before releasing/building installers, and so just if wanted to keep on-top of things or how to say it. You can also add shortcuts to all the scripts into C:\deluge2 main dir, so you don't have to go in/out of dirs, if needing build several things, and then you can also rightclick each shortcut and define them to be run as admin, so you don't have to remember that each time and so can just double-click instead of rightclick/install-as-admin. As said previously, only scripts not needing run as admin are the scripts in installer-build, except if you change the build-dir in the NSIS installer script to use other folder than %onedrive%\Deluge2 and that folder needs admin rights to write to.

I have no Idea about your gvsbuild issue, as have never ever experienced such neither. (Edit: You can go straight down to Edit3 for possible fix, at end of this post.)

It fails in gvsbuild\utils\builder.py line 369, in this function here:

Code: Select all

self.vs_env = {}
        dbg = log.debug_on()
        for l in output.splitlines():
            # Python3 str is not bytes and no need to decode
            l = l.decode('utf-8') if isinstance(l, bytes) else l
            e = l.split("=", 1)
            if len(e) < 2:
                log.debug('vs env: ignoring %s' % (l))
                continue
            k, v = e
            # Be sure to have PATH in upper case because we need to manipulate it
            if k.upper() == 'PATH':
                k = 'PATH'
            self.vs_env[k] = v
            if dbg:
                vl = v.split(';')
                if len(vl) > 1:
                    log.debug('vs env: %s: [' % (k, ))
                    for i in vl:
                        log.message_indent('  ' + i)
                    log.message_indent(']')
                else:
                    log.debug('vs env:%s -> [%s]' % (k, v, ))

In this line specifically(369):

Code: Select all

 l = l.decode('utf-8') if isinstance(l, bytes) else l

I'm gonna submit a report in gvsbuild github issues section shortly, and report back when hopefully getting further help/feedback on it. I couldn't find reports of this issue for gvsbuild, but for other projects, it seems be described by some to possibly be issue of special chars somewhere in a file. I remember when reading docs of msvc unattended installer commands available, that there where also commands for forcing to not install for other languages or something. I have US locale defined, so maybe if you have your local country defined, then it have used a localized version, but this sounds really far fetched imho that such should be cause of actual failure, as would break for alot of people then with non US setups, so probably wrong, but cannot think of anything else. Does this file here have special chars and is it localized in your lang or english: C;\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Auxilitary\build\vcvarsall.bat. I guess that is the file in question here. Though as it uses utf8 to parse it, then should be able to parse most other countries i'd highly presume, so probably a wild-goose-chase here however.

Hope we can get this sorted out eventually.

Btw, forgot to say in a previous post, that in addition to later updates possibly can break some patch or something, though not usually happens, but regardless, then when gtk3 gets updated to newer version in gvsbuild, then it will break my patch for that, which means that the version gvsbuild updated to, will be used, which is fine as new, and then the small fix I added for better visibility of some fields in win32 theme(white on grey by default, changed to black text on grey background), will not be there, so not end of the world but little annoying. I haven't found a way to fix that yet, but haven't encountered it yet, as they only update gtk3 maybe every 6 months or so, not fully sure though, and has recently updated it, actually they merged my pull-request for it. Just for full disclosure.

Edit:

Here's the ticket I posted, which also have some more info I found online:

https://github.com/wingtk/gvsbuild/issues/368

Btw, if you open that vcvarsall.bat and vcvarx64.bat in notepad and select save-as, then does it say utf-8 as encoding like it does on my end? Don't save the file, but just check it and exit the dialog afterwards. Some state to change the encoding in the python code to windows-1252, like I mentioned in that ticket, though not for this issue here, but as generalised issue with UnicodeDecodeError of 0x92 char, which is smart/curly quote. Others suggested success with resaving the file as utf-8, if not already, but if you try that, then just in case backup the original files in question first.

Edit2: I just reinstalled buildtools using Czech lang, from provided command-line of such, just to test other langs out and see if interfering, and under languages it afterwards also listed just czech as only lang installed, but the vcvars files where the same and in utf8 and the gvsbuild didn't fail here either, so now im not even sure that's related? I'm now not even fully sure either it's vcvars file it fails reading, as imho hard to decipher from the code. Still waiting on reply from ticket on github though.

Edit3: The always helpfull guruDanny67 at gvsbuild upstream just replied and pushed a fix hopefully working, so if you can please rerun script when you feel like it to test, as script clones git and gets the fix automatically. It was related btw, to illegal chars somewhere parsed, I'm guessing "Skip 'c:\users\pétersasi\appdata\local\microsoft\windowsapps'" from debug output, or elsewhere that username is parsed, as part of the reply of Danny was:

"probably had some windows environment with char > 128 (e.g. some accented, probably é or something similar like ò, à, ù ...) and this gives the decoding error.".
Last edited by mhertz on Thu May 28, 2020 1:16 am, edited 5 times in total.

idiocracy
Leecher
Leecher
Posts: 62
Joined: Tue Jul 23, 2019 11:04 am

Re: [Unofficial] Deluge 2.0.x installer [Unmaintained/unsupported]

Postby idiocracy » Wed May 27, 2020 7:50 pm

I'm happy to see this is still being worked on.

mhertz
Compulsive Poster
Compulsive Poster
Posts: 841
Joined: Wed Jan 22, 2014 5:05 am
Location: Denmark

Re: [Unofficial] Deluge 2.0.x installer [Unmaintained/unsupported]

Postby mhertz » Wed May 27, 2020 11:34 pm

Yes, big props to petersasi for stepping up and overtaking this :)


Return to “Windows OS”

Who is online

Users browsing this forum: No registered users and 6 guests