Problems building with Ubuntu 24.10 (native / Docker)

[hackgrid]

Version of the game

a8c4692

Ares v140

First time I built with CMake today.
I had to upgrade to ubuntu 24.10, because CMake 3.28 was the minimum required version, just FYI.

• The building docs tell you to set DCMAKE_TOOLCHAIN_FILE, but when running cmake it gave me a warning that this variable was not used at all by the script.

https://github.com/mwpenny/portal64-still-alive/blob/master/documentation/building/building.md

• Maybe we should move the "apt install ninja-build" above the configuration phase as optional step, because if you run the configuration before that, it just quits with an error.

• Also, since I am unfamiliar with cmake, maybe we should add "cmake --build build --target clean" to the docs for cleaning?

• Is there a way to log all build messages for debugging of issues?

• After that everything was fine, but the version identifier on the menu screen does not work correctly:

Maybe because I built from my fork? Have not checked yet how that works.
I "git clone"d, I did not build from a source archive.

• Also the portal gun looks a bit funny?

I snapped Blender 3.6.19, this is fairly recent, maybe they introduced a bug there?

• There is also a visual bug with the first door in chamber 16:

• Last door too:

• I think the Portal borders look more broken than usual now?

edit:

• Sorry, it seems all my doors are broken:

It was a clean cmake build on a fresh Ubuntu system, so maybe the door texture is lacking from the cmake list?

edit2:

• so textures / models for stuff like ball catcher / thrower is missing too, so I guess I did something wrong?

[mwpenny]

Thanks for all of these details.

The Dockerfile has been at Ubuntu 24.04 for a while and it is the latest LTS. 24.10 should be okay.

The building docs tell you to set DCMAKE_TOOLCHAIN_FILE, but when running cmake it gave me a warning that this variable was not used at all by the script.

This is normal. CMake remembers variables you set and only reads the toolchain variable for initial configuration. So if you run CMake again with the variable set it is not used, and can/should be omitted in subsequent calls. Basically, after populating the build directory it is no longer needed.

Good ideas about the docs. Those suggestions will make things clearer. I can do this while looking at the rest of the issues if you don't first.

Is there a way to log all build messages for debugging of issues?

You can set the environment variable VERBOSE=1 to see more information. If you run ninja directly, you could also use -j 1 to disable parallelism.

I agree it looks like an issue loading the models. Unfortunately I haven't run into this before. Does it happen:

• Using Docker?
• Using your same setup but with an older Blender version?
• Using make instead of ninja?
• Using the upstream repo instead of your fork?

[hackgrid]

Thx, I will check later! no Docker, native 24.10 VM. Which version of Blender do you use? Matt Penny ***@***.***> schrieb am Mi., 1. Jan. 2025, 17:07:

…

Thanks for all of these details. The Dockerfile has been at Ubuntu 24.04 for a while and it is the latest LTS. 24.10 should be okay. The building docs tell you to set DCMAKE_TOOLCHAIN_FILE, but when running cmake it gave me a warning that this variable was not used at all by the script. This is normal. CMake remembers variables you set and only reads the toolchain variable for initial configuration. So if you run CMake again with the variable set it is not used, and can/should be omitted in subsequent calls. Basically, after populating the build directory it is no longer needed. Good ideas about the docs. Those suggestions will make things clearer. I can do this while looking at the rest of the issues if you don't first. Is there a way to log all build messages for debugging of issues? You can set the environment variable VERBOSE=1 to see more information. If you run ninja directly, you could also use -j 1 to disable parallelism. I agree it looks like an issue loading the models. Unfortunately I haven't run into this before. Does it happen: - Using the Dockerfile? - Using your same setup but with an older Blender version? - Using make instead of ninja? - Using the upstream repo instead of your fork? — Reply to this email directly, view it on GitHub <#98 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAANGLHAZF44VWXDIPYA6XT2IQHFXAVCNFSM6AAAAABUOWF5IGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRXGA3DGNJUHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mwpenny]

I've updated the docs.

For the version identifier: it is generated by first trying to run the command git describe --tags HEAD. If this fails, the build assumes it's being run on a source archive and uses the contents of <portal64>/version.txt (which will have been replaced by git archive in that case). Here, I see your fork has no tags and so the git command will fail (on success the output references the most recent tag), causing the unprocessed contents of version.txt to be used. I've updated the git command to use the --always flag, which causes it to fall back to the commit hash in this situation.

I did a clean build (both on this repo and your fork) and couldn't reproduce the other problems.

Which version of Blender do you use?

On my main dev machine I use 3.6.7. When travelling I use 3.6.11. At the time I set up each environment, I just grabbed the latest 3.6.x.

From what I've read, Blender uses a versioning scheme similar to semantic versioning. Minor releases should not contain breaking changes, but of course there could be bugs. I built with 3.6.19 to be safe and couldn't reproduce the graphical issues.

[hackgrid]

Thx, I will see if there any errors concerning textures in the build log. In the past, the version number did already fall back to commit hashes I think, great that you fixed it :) Matt Penny ***@***.***> schrieb am Mi., 1. Jan. 2025, 23:28:

…

I've updated the docs. For the version identifier: it is generated by first trying to run the command git describe --tags HEAD. If this fails, the build assumes it's being run on a source archive and uses the contents of <portal64>/version.txt (which will have been replaced by git archive in that case). Here, I see your fork has no tags and so the git command will fail (on success the output references the most recent tag), causing the unprocessed contents of version.txt to be used. I've updated the git command to use the --always flag, which causes it to fall back to the commit hash in this situation. I did a clean build (both on this repo and your fork) and couldn't reproduce the other problems. Which version of Blender do you use? On my main dev machine I use 3.6.7. When travelling I use 3.6.11. At the time I set up each environment, I just grabbed the latest 3.6.x. From what I've read, Blender uses a versioning scheme similar to semantic versioning. Minor releases should not contain breaking changes, but of course there could be bugs. I built with 3.6.19 to be safe and couldn't reproduce the graphical issues. — Reply to this email directly, view it on GitHub <#98 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAANGLGCS7CTNF7WOY6LN2D2IRT2PAVCNFSM6AAAAABUOWF5IGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRXGE3DMMBTGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mwpenny]

Sounds good. It could be textures, or also related to models (which would explain the Portal gun).

The old version logic fell back to commit hashes, but relied on the assumption that the repo would have at least one tag. So using a fork (no tags) was what triggered it.

Good find!

[hackgrid]

I tried building with make and it is the same problem.
I tried with Docker and it works though - so maybe it is Ubuntu 24.10 that causes broken builds?
I will try with 24.04 later...

[mwpenny]

Interesting. Sounds like either misconfiguration or a breaking change in a build dependency. If a 24.04 VM set up the same way works then we could look at which packages changed in 24.10.

[hackgrid]

So I set up an Ubuntu 24.04 VM exactly as my 24.10 one (just a fresh install with default options)
and compiled portal64 (just git clone + setup_ubuntu + cmake build) and it worked fine.

So I guess Ubuntu 24.10 might be the culprit here?
Should be easy to test, if we change the Docker container to use 24.10, I may try later :-)

[hackgrid]

So I changed the Dockerfile to Ubuntu 24.10 and the resulting build had the same problems as described here.
So this problem is definately caused by some changes since Ubuntu 24.10 :-)

[mwpenny]

Nice, that narrows it down.

I went through the Ubuntu repos to see which build-relevant packages changed between the two versions:

Package	24.04	24.10
cmake	3.28.3-1build7	3.30.3-1
ffmpeg	7:6.1.1-3ubuntu5	7:7.0.2-3ubuntu1
git	1:2.43.0-1ubuntu7.1	1:2.45.2-1ubuntu1
imagemagick	8:6.9.12.98+dfsg1-5.2build2	8:6.9.13.12+dfsg1-1
libassimp-dev	5.3.1+ds-2build1	5.4.2+ds-1
libpng-dev	1.6.43-5build1	1.6.44-1
libtiff-dev	4.5.1+git230720-4ubuntu2.2	4.5.1+git230720-4ubuntu4
ninja-build	1.11.1-2	1.12.1-1
nodejs	18.19.1+dfsg-6ubuntu5	20.16.0+dfsg-1ubuntu1
pip	0.40-7	0.40-8
pipx	1.4.3-1	1.6.0-1
python3	3.12.3-0ubuntu2	3.12.6-0ubuntu1
sox	14.4.2+git20190427-4build4	14.4.2+git20190427-5
unzip	6.0-28ubuntu4.1	6.0-28ubuntu6

You could try changing individual packages. libassimp-dev seems the most likely to me since it's used for reading the levels and models during conversion.