s0600204

Was that with or without the differential Stan` mentioned above (D3127) applied? (Because that should now work...)

Unfortunately SETUPTOOLS_USE_DISTUTILS=stdlib is not a long-term solution, as the python standard lib's distutils is deprecated as of python 3.10 and due to be removed as part of python 3.12 (scheduled to be released October 2023). If spidermonkey intends to keep using distutils past that point, they are going to have to use setuptools' vendored version. (And either spidermonkey, Debian, setuptools - or a combination of all three - are going to have to come up with an official solution to this.) @Itms with the caveat that as of writing this I haven't completed a full build of spidermonkey on my VM - so there may be failure later in the build - here's the patch:FixInstallScheme.diff Needless to say it's not suitable for applying on Windows systems (as that would, at a guess, use the "nt" scheme).

Ok, I've now created a Bookworm VM myself, and my current findings: I can duplicate the build failure if python3-setuptools is installed from the Debian repos. Uninstalling it clears the issue. (@hyperion this is probably what you're missing.) My earlier patch doesn't work. The reason it doesn't work is because of how setuptools resolves the installation scheme - ask it to use "posix_prefix", and setuptools asks sysconfig what the preferred scheme is for "prefix", whereupon it gets the response "posix_local". So setuptools uses that scheme instead. That reason sysconfig returns that value is due to the modifications Debian has made to that module. (It's also where the detection of virtual environments takes place. And fails because this bit of the process isn't being run inside a virtualenv.) setuptools attempts to use "posix_prefix" on posix-y systems anyway under certain circumstances (which spidermonkey's build process meets), so my patch - even if it was correct - is redundant. @Itms I may have an alternate solution - albeit one that will conflict with the patch you've imported from SM - but I need to sleep right now so I shall have to get back to you with it.

The links not surviving is to be expected - until you have a successful build of spidermonkey, /home/domowy/svn/0ad/libraries/source/spidermonkey/mozjs-91.13.1/ will be nuked every time update-workspaces.sh is run.

Heh, looks like @Itms was a few of hours ahead of me in investigating! At a guess, this: https://salsa.debian.org/cpython-team/python3/-/blob/python3.10/debian/patches/distutils-install-layout.diff (There is also https://salsa.debian.org/cpython-team/python3/-/blob/python3.10/debian/patches/sysconfig-debian-schemes.diff which modifies sysconfig, which appears to be where DEB_PYTHON_INSTALL_LAYOUT is read.) It adds two new "Install Schemes": unix_local and deb_system. The default "Install Scheme" for Debian(-derived) distros is unix_local; which has the "purelib" path template of '{base}/local/lib/python{py_version_short}/dist-packages' which matches @zyli's initial report above. With the DEB_PYTHON_INSTALL_LAYOUT environment variable set to "deb", the "Install Scheme" used changes to deb_system; which has the "purelib" path template of '{base}/lib/python3/dist-packages', which matches the last reported attempt. Both patches have code that detects virtual environments (and uses the posix_prefix install scheme instead in that case) - however this detection only functions when it is run inside a virtual environment, and this point of the spidermonkey build process is run outside it. That said, I may have a solution:installscheme.patch @hyperion Out of curiosity, are setuptools/virtualenv/distutils installed globally in that image? (Or need installing globally as part of the process?)

Something has changed: the path given by the "FileNotFound" error message earlier: '/home/domowy/svn/0ad/libraries/source/spidermonkey/mozjs-91.13.1/build-debug/_virtualenvs/common/local/lib/python3.10/dist-packages' has now lost its "local" subpath '/home/domowy/svn/0ad/libraries/source/spidermonkey/mozjs-91.13.1/build-debug/_virtualenvs/common/lib/python3/dist-packages' One step forward! @zyli, would I be right in thinking that if you go to /home/domowy/svn/0ad/libraries/source/spidermonkey/mozjs-91.13.1/build-debug/_virtualenvs/common/lib/python3 there is a "site-packages" subdirectory but not "dist-packages"?

Out of curiosity @zyli, if you enter the following into a python3 interpreter... >>> import sysconfig >>> sysconfig.get_default_scheme() >>> sysconfig.get_scheme_names() >>> sysconfig._get_preferred_schemes() ...what output do you get? Also, do you happen to have python3-distutils installed?

Intentional (by design of the session UI, not the Structure Tree), and dates back to this Revision. Easily changed by altering this line of code. Note the same thing occurs in the game setup screen (also by design, and also that Revision, but behaviour defined in a different file).

My thoughts: I like git; (Bit controversial, but) I also like Phabricator (and, despite its flaws, arcanist!) (So I'd like to see consideration of migrating across to Phorge - once the Phorge team release a guide as to how to do that!) I'd like to see the repository split to differentiate between the engine and the game; I'd like to see binaries off-loaded via git-lfs or some other suitable tool; I'd like to for us to stop committing Windows-only binaries into the repository, but make them available through other means for those unable (or unwilling) to build themselves: The same process could potentially be used to provide "nightly" builds for macOS and some Linux distros as well; (On a related note, I'd also like to see a build script for Windows like the one we have for macOS - e.g. it also fetches and builds the libraries/dependencies. But that's for another thread.) We should continue to be self-hosted where possible;

In the initial flurry of interest from/discussion between various concerned parties to continue Phabricator in some form, one user proposed dropping support for subversion and mercurial (so as to permit pushing directly to a phabricator-managed git repo with "git push" instead of having to use arcanist). There was some push back from others about losing mercurial support but not a single voice against the proposed loss of support for subversion. (Link to the discussion - requires login.) Since the fork ("Phorge") has established itself, the only mention to subversion that I can find (in the publicly/guest accessible bits, anyway) is in the list of "projects" for the various components of Phorge. As you might note - a project hasn't been created for subversion, although it is in the list. According to the comments below the list, projects will be created on a "as-needed" basis. So it looks like there's no plan to drop subversion support... but also no-one has stepped forward to express an interest in maintaining it either. (Unlike mercurial, who does have someone.)

Reference: https://code.wildfiregames.com/D4316

Some other long words in English: https://www.youtube.com/watch?v=NQrxzgd6ASA And there are plenty of suggestions in the comments for other long words both in English and other languages... hope no one suffers from hippopotomonstrosesquippedaliophobia*! (* - Fear of long words)

(@hyperion if you did that, you would get the following: WARNING: specificName should be an object of civ->name mappings in budhist_evangelism.json) @PyrrhicVictoryGuy It should read something like: ... "specificName": { "bact": "Buddhist Evangelism" }, ...

Pretty self-explanatory. Please specify the correct civ within your structure templates. Either provide the missing template, or provide a suitable alternative under SkirmishReplacements in simulation/data/civs/bact.json.

@Stan` Not yet - at a cursory glance, it looks like https://code.wildfiregames.com/D3613 might resolve it. (I'm a little busy with work right now, so if anyone wishes to commandeer and take it further do feel free.)