Alberto Salvia Novella

I have requested to upstream this patch to the original openal code: https://svn.thedarkmod.com/publicsvn/darkmod_src/trunk/ThirdParty/custom/openal/patches/1.21.1/mxcsr.patch Here: https://github.com/kcat/openal-soft/issues/926 They have proposed commit, but I have not enough knowledge about the patch to comment of it. If someone could go there and give it the "okay" it would be very appreciated.

Upgraded to include a patch for ffmpeg.

Building ThirdParty libraries fails on Linux with the latest gcc. But I have fixed it. Could someone kindly add the fix to the SVN? https://bugs.thedarkmod.com/view.php?id=6314

With C++ and gcc, who knows? Thanks.

I use: https://gitlab.com/es20490446e/darkmod-linux Although right now it has this small issue, due to an update on C++ standards: https://bugs.thedarkmod.com/view.php?id=6307 If someone could add that missing line to the SVN...

Just completed the mission, very nice!

Try removing "Darkmod.cfg".

Someone affected, please report this issue at the Linux Bugzilla. And maybe we will be lucky. I cannot do it myself now, because my affected computer is far away from me.

https://bugs.thedarkmod.com/view.php?id=5921

https://bugs.thedarkmod.com/view.php?id=5881#c14713

Only if it compiles, I can package it.

https://bugs.thedarkmod.com/view.php?id=5883

Yeap, it worked now. Thanks Maybe I should always build ThirdParty from trunk.

I see, we are using different bincrafters URLs for some reason. Lets try...

It cannot be that, because the Conan workspace is a temporal blank dir: ``` configureConan () { export CONAN_USER_HOME="${buildLibs}..." so conan config set general.revisions_enabled=True so conan remote add bincrafters https://api.bintray.com/conan/bincrafters/public-conan } ```

Not working: WARN: libcurl/7.61.1@thedarkmod/local: requirement zlib/1.2.11@conan/stable overridden by your conanfile to zlib/1.2.11 ERROR: Failed requirement 'mbedtls/2.13.0@bincrafters/stable' from 'libcurl/7.61.1@thedarkmod/local' ERROR: Permission denied for user: 'None'. [Remote: bincrafters]

What I mean is I try to avoid the packaging maintenance as much as possible. For that I automate the generation of recipes, and favor using the code from upstream. If I really need a customization I try to suggest it upstream, or I automatically append it to the original recipe. But I avoid trying to keep local recipes per se, because that would be a recurrent effort to maintain.

I went one step further and all my package definitions, dependencies and such, are generated procedurally at any given point in time. I only change a package recipe when it fails to retrieve the new data. For example: https://gitlab.com/es20490446e/express-repository/-/blob/master/recipes/ttf-twemoji/PKGBUILD

Well, I should have seen it: zlib/1.2.11: WARN: minizip option is deprecated. Please use the new minizip/1.2.11 package But fixing that: WARN: libcurl/7.61.1@thedarkmod/local: requirement zlib/1.2.11@conan/stable overridden by your conanfile to zlib/1.2.11 ERROR: Failed requirement 'mbedtls/2.13.0@bincrafters/stable' from 'libcurl/7.61.1@thedarkmod/local' And fixing that: Failed requirement 'zlib/1.2.11@conan/stable' from 'libcurl/7.61.1@thedarkmod/local' It seems there are more than a few things broken at conanfile.py. Please let me know when the published file works again, at least for you.

Minizip has been deprecated: https://github.com/conan-io/conan-center-index/pull/8425/commits/4a6aeaa625f137f1631ccc52bdafed542d729c76

=== terminal === $ conan install . --build --options platform_name=linux ERROR: zlib/1.2.11: option 'minizip' doesn't exist Possible options are ['shared', 'fPIC'] === conanfile.py === # build minizip too (it is part of zlib package) "zlib:minizip": True,

Nope: $conan install . --build --options platform_name=linux zlib/1.2.11: WARN: minizip option is deprecated. Please use the new minizip/1.2.11 package WARN: libcurl/7.61.1@thedarkmod/local: requirement zlib/1.2.11@conan/stable overridden by your conanfile to zlib/1.2.11 ERROR: Failed requirement 'mbedtls/2.13.0@bincrafters/stable' from 'libcurl/7.61.1@thedarkmod/local' ERROR: Unable to find 'mbedtls/2.13.0@bincrafters/stable' in remotes

https://bugs.thedarkmod.com/view.php?id=5839

The tricky point seems being able to detect if 64-bit color is supported. Are you sure there isn't a standard way to check which color formats are supported? Or perhaps which OpenGL version the driver supports, then infer from there the supported color formats. For example I get: $glxinfo | grep "OpenGL version string" OpenGL version string: 3.1 Mesa 21.2.2

Why? Isn't 64-bit intended for HDR screens nowadays, being that most aren't? I don't know, just asking.