[Bug]: Run_script not working

[alextrical]

I'm currently experiencing problems getting the Run_script action to work using the information provided by the maintainers guide here

Also created a test application based on the information found in issue bottlesdevs/programs#24 Unfortunately no such luck getting the expected output to show.

Please can you advise if I'm doing something wrong, it seems that I cannot get this action to work on Kbuntu 23.10, but I haven't tried on any other devices/workstations yet

[mirkobrombin]

Looking at the trace, the installer is failing to get the executable icon. Do you have one in your manifest?

[alextrical]

I don't have an exe by that name at that location, however the script action should be fired before that is checked. I expect echoed commands between 'Executing Installer script...' and 'finished executing installer script.'

Specifically I expect this output that you have achieved in bottlesdevs/programs#24 as I'm using the script found there and in the maintainers guide

[alextrical]

So to try and eliminate the Example application being a source of the issue, I have configured a manifest to install Notepad++

notepadpp.yml

However the issue of no scripts running/printing to terminal still occurs

Successful trace:

[mirkobrombin]

There is something wrong happening here I did a full code checkup yesterday and this one was the more cursed one. I'll take a look again asap, feel free to check it out if you know how to py.

[alextrical]

Unfortunately I don't know how to code python yet, but it's is as good a reason as any to get my feet wet 😉

Glad to hear that you can also confirm there is a bug hiding somewhere.

[alextrical]

I think the first thing to try would be adding a logging.info to installer.py after line 251 to see what the contents of the script variable are. Currently fighting with a medium-low spec laptop that doesn't have much power for compiling, and fighting some unexpected compile time errors. Still every day is a learning day, so hopefully i will get more proficient soon.

Any idea what I'm doing wrong to get the following error using the org.flatpak.Builder instructions from the main branch?

[mirkobrombin]

use the build.sh script in the root of the project, it will fail on some points listing what platforms and sdks are missing, then run it again to proceed. It will also start flatpak as the final step

[alextrical]

I think I'm still missing a trick, the script exits with no printed error, as it cant find 'flatpak-spawn' Looking online it seems I need to be inside of a sandbox, from the Docs

Give me a day to play around with it, and see what I can do to get it working, and then after that I will ask for some pointers, I don't want to waste your time ;) There may be some pointers i can advise to make it easier for on boarding of new developers in the future

[mirkobrombin]

I see the error, I am missing a call

[mirkobrombin]

I just updated the script https://github.com/bottlesdevs/Bottles/commit/2bd8b60608661228ea3e804edbd7ab0dc05faa0c

[alextrical]

Awesome I can confirm that build.sh is now behaving itself nicely, though I'm now struggling to get past some permissions errors.

Edit: Ha, I think i know what the issue is, my git repo's on my laptop are stored on a NTFS formatted drive. Welp, that wasted a day. Live and learn ;)

Edit2: Yep it was NTFS messing me up. if anyone else has error 'Invalid mode 0100777 with bits 00002' its probably the filesystem being used

[alextrical]

So after testing the Run script definition inside installer.py, it looks like the issue likes in lines 256-257, as commenting out

            # stdout=subprocess.PIPE,
            # stderr=subprocess.PIPE,

Bottles then starts executing the script as expected. So the question is what is wrong with them causing subprocess.Popen to not work?

[alextrical]

@mirkobrombin How is the user script functionality intended to work? I'm guessing anything printed should show up in the terminal is Bottles was opened from terminal. I'm also guessing that its desirable to wait for the script to complete before moving onto the next step. What I cant see as of yet is how the py script is meant to handle a non 0 exit code, i.e. stderr, is there anything that checks for that and will stop the install on a failure?

[mirkobrombin]

That allows you to capture the output to handle it but I don't think we're actually handling it. In any case, if it works now it means that it was just a problem with where the outputs landed and therefore it was still working. I think it's ok to leave them commented.

About the exit handler, I would make the installer fail.

[alextrical]

Got a working script runner after a lot of testing. It can now print to the terminal, and handle errors raised from the user script. However i have set it to print an error but continue, as i cant see a way to gracefully terminate the installation without locking up the application.

I.e. raise Exception(err_msg) works to terminate the installation process, but has no way for the GUI to recover that i can see so far

After all this I still need to investigate what the Run_script is capable of achieving once it works as intended.

[mirkobrombin]

So is that PR still in draft? :thinking:

[alextrical]

It depends on there being a possibility in Bottles to gracefully raise an error to the user through the GUI. If there is an example in the existing system I can try and replicate it (I would expect something around the dependency code)

Not something I've looked into yet, so it may be best to merge the current state, and then make a second pass to add a graceful fail instead of the current continue on error?

[alextrical]

At the end of the day the current goal I'm aiming for is to get applications that require mimetype registration for login working smoothly with bottles. Specifically Autodesk Fusion. But it will also be useful for other "cloud"/SSO applications such as Melodics https://gist.github.com/adrienbeau/1d0af5c53a1f952a07b41da02ed2d7c2

One thing with this project that confused me in the beginning was that the user had to create the Bottle knowing the requirements of an application, rather than the application manifest defining the runner to use. I'm still not exactly sure why it's up to the user to pick that, but there should at least be ways for the manifest to block installs on known bad bottles (i.e. wine below or above a specific version)

[mirkobrombin]

To make it fail, simply return False, actually there is a also a missing return True in __step_run_script. I dropped a comment in your PR.