On 29.04.19 14:21, IOhannes m zmoelnig wrote:

On 29.04.19 13:37, Roman Haefeli wrote:

...

Hey all

When running either 32bit or 64bit Windows build of Pd under Wine on Linux (amd64), I cannot install packages through 'Find externals'. Either nothing is downloaded or - more likely - a .dek file is downloaded, but immediately deleted without extracting it first. Though the GUI indicates success (progressbar wandering to the right), no traces are left afterwards.

How can I investigate this some more? Are others having success with such a setup?

hmm, i can confirm this :-(

so the problem is, that on windows we need to run a VBScript to do the actual unzipping. but wine doesn't support VBScripts out of the box.

a bit of duckduckgoing gave me [1]. after installing "wsh57", i get a bit further: while Pd/deken still doesn't properly unzip the package, at least it notices the failure and opens the file explorer at the installation location, prompting the user to manually unzip the file (with a number of missing linebreaks...)

fgmasdr IOhannes

[1] https://gist.github.com/Ravenstine/9ccbe8269e8d5d28305b

On 29.04.19 14:39, IOhannes m zmoelnig wrote:

so the problem is, that on windows we need to run a VBScript to do the actual unzipping. but wine doesn't support VBScripts out of the box.

a bit of duckduckgoing gave me [1]. after installing "wsh57", i get a bit further: while Pd/deken still doesn't properly unzip the package, at least it notices the failure and opens the file explorer at the installation location, prompting the user to manually unzip the file (with a number of missing linebreaks...)

one issue that prevents me from properly fixing the problem is, that i currently have no indication of whether the VBScript unzip (as used on windows, and non-functional on wine) succeeds or not (even if "wsh57" is not installed).

in the meantime i've added a deken-preference flag that prevents the downloaded package file from being deleted after a "successfull" installation. https://github.com/pure-data/deken/

gfmdrt IOhannes

On 29.04.19 19:23, Roman Haefeli wrote:

I wonder if extracting fails because the downloaded file is renamed:

oscv0.2~git20181006.dek -> oscv0.2~git20181006.dek.zip

Somewhere a .zip extension is appended to filename, .zip files end up with .zip.zip.

afaict, wine fails to unzip because it simply doesn't come with a built-in unzip utility (unlike proper windows). e.g. you (at least: I) cannot unzip a zip-file in the wine-explorer by any means.

the reason why the files are renamed, is that the built-in unzip utility on windows will only start working if it believes that the file it is supposed to unzip is a zip-file. windows being windows, this means that the file must have a .zip extension. So after downloading the deken package, we just rename by adding a .zip extension (there's no check whether the file already had a zip-extension (old-style deken packages), that's why you get a .zip.zip extension; afaict there's no problem with that, as windows still trusts that the file is a zip-file).

in any case, the file should be renamed back to the original name after the unzip attempt (whether successful or not), so i wonder why you see these files in the first place. (the time window where the .zip extension is present should be pretty small for a failing unzip attempt; it should definitely be gone once the exploder is fired up)

dmasr IOhannes

On 29.04.19 15:42, IOhannes m zmoelnig wrote:

one issue that prevents me from properly fixing the problem is, that i currently have no indication of whether the VBScript unzip (as used on windows, and non-functional on wine) succeeds or not (even if "wsh57" is not installed).

i think i've got this fixed in the current master at [1]. it still doesn't do any proper unzipping on wine, but at least it detects whether unzip failed and prompts the user for help.

i've tested this under wine (falling back to manual untip) and in a windows VM (properly unzipping)

test if you dare.

fgamsdr IOhannes

[1] https://github.com/pure-data/deken/