non makepkg build only producing lib and lib32 dirs for valve wine 9.0

xioren commented 2 months ago

As the titles suggests the build script is only producing the lib and lib32 directories but not bin, include, or share. Despite this the build did "complete" on my Github workflow, just without the above dirs. However when attempting to debug locally in a VM the script will not complete at all with the error:

'/home/runner/work/wine-tkg-git/wine-tkg-git/last_build_config.log' -> '/home/runner/work/wine-tkg-valve-exp-bleeding-experimental.bleeding.edge.9.0.93246.20240425/share/wine/wine-tkg-config.txt'
cp: cannot create regular file '/home/runner/work/wine-tkg-valve-exp-bleeding-experimental.bleeding.edge.9.0.93246.20240425/share/wine/wine-tkg-config.txt': No such file or directory

It gives this error because the share directory is never created and does not exist.

xioren commented 2 months ago

One thing I noticed: The reason it completed on the Github workflow was that _nomakepkg_prefix_path="/home/runner/work" was not set. For whatever reason it completed but the resulting build was missing the above mentioned directories and thus unusable. On my local vm I did have _nomakepkg_prefix_path set and the run failed with the above error, again because the necessary directories are not created.

Tk-Glitch commented 2 months ago

Would it be possible for you to share the full log? Thanks.

mirkobrombin commented 2 months ago

Here the build log https://github.com/bottlesdevs/wine/actions/runs/8827973913/job/24236117177.

We have a 11MB log from github actions (that should be safe to share) in case you are not able to see the output there.

Tk-Glitch commented 2 months ago

Thanks!

The build didn't succeed.

2024-04-25T07:16:44.9928957Z ../ValveSoftware-winegit/dlls/winegstreamer/media-converter/videoconv.c:1000:9: error: unknown type name ‘GstBufferMapInfo’; did you mean ‘GstMapInfo’?
2024-04-25T07:16:44.9931451Z  1000 |         GstBufferMapInfo map;
2024-04-25T07:16:44.9931998Z       |         ^~~~~~~~~~~~~~~~
2024-04-25T07:16:44.9932463Z       |         GstMapInfo

Looks like some deprecated gstreamer package as it doesn't fail on Arch. I however now can see the same error on my end with the buntu CI, and indeed it doesn't show up as a failed run, even though it is. I'll work on a workaround asap.

xioren commented 2 months ago

@Tk-Glitch Thanks for getting a patch out promptly. However the disable_mediaconv.myrevert patch only seems to work when _NOLIB32="wow64" is set. Otherwise the patch fails to apply:

=> Found 1 'to revert' userpatches for plain-wine:
/home/runner/work/wine-tkg-git/wine-tkg-git/disable_mediaconv.myrevert
=> ######################################################
=> 
=> Reverting your own plain-wine patch /home/runner/work/wine-tkg-git/wine-tkg-git/disable_mediaconv.myrevert
=> 
=> ######################################################
===> ERROR: Patch application has failed. The error was logged to /home/runner/work/wine-tkg-git/wine-tkg-git/prepare.log for your convenience.
=> Removed BIG_UGLY_FROGMINER - Ribbit
=> Removed Proton-tkg token - Valve Ribbit
=> exit cleanup done

I confirmed this using the wine-tkg-valve-exp-bleeding.cfg with and without setting _NOLIB32="wow64".

Tk-Glitch commented 2 months ago

That's.. Weird. I guess there's some additional patch(es) on non-wow64 path that may conflict. Thanks, I'll be fixing that as well asap.

Tk-Glitch commented 2 months ago

@Tk-Glitch Thanks for getting a patch out promptly. However the disable_mediaconv.myrevert patch only seems to work when _NOLIB32="wow64" is set. Otherwise the patch fails to apply:
=> Found 1 'to revert' userpatches for plain-wine:
/home/runner/work/wine-tkg-git/wine-tkg-git/disable_mediaconv.myrevert
=> ######################################################
=> 
=> Reverting your own plain-wine patch /home/runner/work/wine-tkg-git/wine-tkg-git/disable_mediaconv.myrevert
=> 
=> ######################################################
===> ERROR: Patch application has failed. The error was logged to /home/runner/work/wine-tkg-git/wine-tkg-git/prepare.log for your convenience.
=> Removed BIG_UGLY_FROGMINER - Ribbit
=> Removed Proton-tkg token - Valve Ribbit
=> exit cleanup done
I confirmed this using the wine-tkg-valve-exp-bleeding.cfg with and without setting _NOLIB32="wow64".

I'm not able to reproduce that issue. Could you please share the build log, and if available, the prepare.log file. Thank you!

xioren commented 2 months ago

I had already deleted the runs from earlier so I just ran another. Currently using this config file but earlier when debugging I tried commenting out all the patches to see if any were conflicting but was still failing.

https://github.com/xioren/wine/actions/runs/8864041546/job/24338791954

Ill run it again locally to get the prepare.log.

Tk-Glitch commented 2 months ago

Ok I think I see the issue. Your approach jams the profile loading for bleeding edge, so you only get HEAD of the experimental_9.0 (https://github.com/ValveSoftware/wine/tree/experimental_9.0) branch instead of the actual bleeding edge tree (https://github.com/ValveSoftware/wine/tree/32b9ae734d81c68e96546c86bd665c59813d5de2) for which the patch was made against. Adding _LOCAL_PRESET="valve-exp-bleeding" to your wine-tkg.cfg should work I guess.

edit: Not exactly sure why the wow64 option would make a difference though.

xioren commented 2 months ago

Okay I will give that a shot. Doesn't using the local preset nullify my own config though? And as far as wow64, I probably made a bad assumption. The first time I got a run to complete was with that added but perhaps it was a red herring.

Edit: In other words you are saying I need to specify a staging version _staging_version="cab93f47b8d095eb968bb3c7debf9117a91307ce" in my config for the patch to apply? That is really the only significant omission between wine-tkg-valve-exp-bleeding.cfg and my config file.

Tk-Glitch commented 2 months ago

There are other dependency issues without wow64 on Ubuntu, depending on the day and mood of the package maintainers, so we ended up defaulting to it enabled for buntu builds on our end now that it's in a better shape. Not sure if it would go through without wow64 right now, but maybe.

Using the local preset will enforce only the options that are in it. For bleeding edge that means:

_PKGNAME_OVERRIDE="valve-exp-bleeding"
_custom_wine_source="https://github.com/ValveSoftware/wine.git"
_plain_version="experimental_9.0"
_proton_branch="experimental_9.0" # this doesn't affect non-proton builds
_staging_version="cab93f47b8d095eb968bb3c7debf9117a91307ce" # this doesn't affect you with staging disabled
_bleeding_tag=""
_NOINITIALPROMPT="true"
_user_patches="true"
_user_patches_no_confirm="true"

# These are simply not compatible with valve trees
_CSMT_toggle="false"
_GLSL_toggle="false"
_lol920_fix="false"

For what overlaps, it's pretty similar to what you have. The problem lies in the logic behind how we handle bleeding edge quirks through some code that's only triggered by this exact profile file getting loaded. Not its content mind you. In your log we can see:

No _LOCAL_PRESET set in .cfg. Please select your desired base (or hit enter for default) :

Since you auto-answer it takes it as "default". But default will set _LOCAL_PRESET="none" then source the wine-tkg-default-tkg.cfg profile (an empty file basically), which doesn't trigger any of the logic for valve trees, let alone the very special bleeding edge path. For that _LOCAL_PRESET needs to be set to one of the valve options. That's how you got missing GE patches also.

We have some plans to disconnect valve trees handling from the profiles but currently it pretty much depends on this.

xioren commented 2 months ago

Okay that makes sense. I will go ahead and enable _LOCAL_PRESET for now. Thanks for your help! You probably need some sleep lol.

Tk-Glitch commented 2 months ago

Also, replacing that profile file with yours would also work. It just absolutely needs to be that filename, and your frogminer config could just have _LOCAL_PRESET="valve-exp-bleeding" in it.

You probably need some sleep lol.

You couldn't be more right :frog:

Tk-Glitch commented 2 months ago

@xioren As an addition in case it was unclear (since I didn't mention this clearly earlier), loading a profile will only overwrite/enforce the variables it sets and not any other. So outside of what's set in the profile file, every other option will work as usual from .cfg files including frogminer ones and won't get overwritten/cleared.

To be more precise customization.cfg and advanced-customization.cfg are loaded first (to set our baseline), then any user .cfg, and at last the profile .cfg. Since the profile is loaded last, the variables it doesn't contain and which were set by any previous .cfg files will stay.

xioren commented 2 months ago

Thank you for clarifying that as I had assumed the opposite. i.e. a local preset is used instead of rather than in addition to a user config file. This should change our workflow approach a bit.

Tk-Glitch commented 2 months ago

That's what I thought - but I wasn't totally sure - after checking out the threads on bottlesdevs. I'm happy things are now clearer and you could make it simpler on your end. Also, a huge thank you :frog: :heart:

Frogging-Family / wine-tkg-git

non makepkg build only producing lib and lib32 dirs for valve wine 9.0 #1161