For information and discussion about Oolite.
https://bb.oolite.space/
So oolite .gitmodules allows forks to use their own versions of the submodules ?another_commander wrote: ↑Sat Aug 02, 2025 5:12 pmThe reason is mentioned at the end of the Readme.md:
Not entirely sure as I never encountered any issues myself, nor did I have to build from a cloned fork, but what is described in the readme has happened in the past, hence the action to mitigate any potential problems.
It has to. How else would you develop stuff that requires changes to the submodules?Lone_Wolf wrote: ↑Sat Aug 02, 2025 5:35 pmSo oolite .gitmodules allows forks to use their own versions of the submodules ?another_commander wrote: ↑Sat Aug 02, 2025 5:12 pmThe reason is mentioned at the end of the Readme.md:
Especially for 3rd party submodules (mozilla js, vorbis , ogg ) that seems unusual.
I've had such 'fun' wrangling the submodule with git. Mercifully it was the submodule that suffered frequently from a detached head
I can imagine that it wasn't much fun dealing with that. I expect it is simply inertia that has kept things unchanged all this time. In the beginning maybe multiple developers were iterating simultaneously in both submodules and main code, so there may have been some benefit but now those submodules are not touched so much and submodules get in the way, it would be good to simplify.MrFlibble wrote: ↑Mon Aug 04, 2025 10:29 pmI've had such 'fun' wrangling the submodule with git. Mercifully it was the submodule that suffered frequently from a detached head
Hopefully someone will clarify the point of the submodules in Oolite source. Surely they've remained in use here for so long for a good reason?
As per Wildeblood above.
Code: Select all
13:04:13.745 [texture.load.png.warning]: ----- A PNG loading warning occurred for /home/flibble/GNUstep/Library/ApplicationSupport/Oolite/ManagedAddOns/oolite.oxp.DrNil.YAH-SetF.oxz/Textures/yah_set_F_10.png: iCCP: known incorrect sRGB profile.Code: Select all
$ grep iCCP Latest.log | awk '{print $10}' | sed 's@^.*AddOns/@@g;s@/.*$@@g' | sort | uniq
DTT.War_Lance.Paradox_Flibble.02.oxz
oolite.oxp.DrNil.YAH.oxz
oolite.oxp.DrNil.YAH-SetA.oxz
oolite.oxp.DrNil.YAH-SetB.oxz
oolite.oxp.DrNil.YAH-SetC.oxz
oolite.oxp.DrNil.YAH-SetD.oxz
oolite.oxp.DrNil.YAH-SetE.oxz
oolite.oxp.DrNil.YAH-SetF.oxz
oolite.oxp.DrNil.YAH-SetG.oxz
oolite.oxp.phkb.ExtraRockHermits.oxz
oolite.oxp.smivs.Liners.oxz
oolite.oxp.spara.station_ads.oxz
oolite.oxp.ZygoUgo.ZygoCinematicSkyNebulas.oxz
oolite.oxp.zzz.Montana05.KillerWolf.nuit_station.oxz
Code: Select all
find . -name "*.png" -type f 2>/dev/null | while read fn ; do
pngcrush -n -q "$fn" 2>&1 | grep -q "iCCP: Not recognizing known sRGB profile that has been edited" && {
echo -n "Fixing: $fn :"
pngcrush -ow -rem iCCP "$fn" >/dev/null 2>&1 && echo Good || {
echo Fail ; exit 1
}
}
done
Code: Select all
#!/bin/bash
DIR="$HOME/GNUstep/Library/ApplicationSupport/Oolite/ManagedAddOns"
WORKDIR=/tmp/fixer/in
OUTDIR=/tmp/fixer/out
mkdir -p "$OUTDIR"
flagfile=fixpng.touched
failfile=fixpng.broke
dienow(){ echo "$*" >&2 ; exit 2 ; }
fixpng(){
find . -name "*.png" -type f 2>/dev/null | while read fn ; do
pngcrush -n -q "$fn" 2>&1 | grep -q "iCCP: Not recognizing known sRGB profile that has been edited" && {
pngcrush -ow -rem iCCP "$fn" >/dev/null 2>&1 || {
touch $failfile ; break
}
touch $flagfile
}
done
}
ls -1 "$DIR" | grep ".oxz$" | while read fn ; do
echo -n "Processing $fn : "
mkdir -p "$WORKDIR" && cd "$WORKDIR" || dienow mkdir
unzip -q "$DIR/$fn" || dienow "Unzip issue"
fixpng
[ -f "$failfile" ] && {
echo ERROR
rm "$failfile" ; dienow fixpng
}
[ -f "$flagfile" ] && {
echo Hit
rm $flagfile
zip -qr "$OUTDIR/$fn" * || dienow zip
} || echo "Miss"
cd - >/dev/null
rm -Rf "$WORKDIR"
done
Obviously I'm not touching versions here.What does one have to do when creating a texture to avoid this issue? I mean, yeah, we can run a script to update them, but the errors would just reappear when I resave my textures, wouldn't they?
I suspect it'd only matter if making textures with very old tools.
That's the article I quoted above.Lone_Wolf wrote: ↑Wed Aug 13, 2025 12:43 pmhttps://stackoverflow.com/questions/227 ... gb-profile gives some details
The coloured blocks is the problem I get if I compile and don't delete or rename the 2 headers. Is it possible that those 2 headers are being found somewhere else on your system so that it is using older headers with newer library?Lone_Wolf wrote: ↑Sat Jul 26, 2025 2:43 pmI build oolite trunk against libpng 16 in a clean chrootJust starting oolite gave these errors and lead to no text visibile in menu , only colored blocks.Code: Select all
$ ldd /usr/share/oolite-git/oolite | grep png libpng16.so.16 => /usr/lib/libpng16.so.16 (0x00007fb53f8c5000) $
removing those 2 files didn't help.
Code: Select all
16:35:58.180 [texture.load.png.warning]: ----- A PNG loading warning occurred for (null): Application built with libpng-1.4.7 but running with 1.6.50. 16:35:58.253 [script.javascript.init]: JavaScript reset successful. 16:35:58.314 [texture.load.png.warning]: ----- A PNG loading warning occurred for (null): Application built with libpng-1.4.7 but running with 1.6.50. 16:35:58.314 [texture.load.png.setup.failed]: ***** Error preparing to read /usr/share/oolite-git/Resources/Textures/trumblekit.png. 16:35:58.370 [texture.load.png.warning]: ----- A PNG loading warning occurred for (null): Application built with libpng-1.4.7 but running with 1.6.50. 16:35:58.572 [display.initGL]: Requested a new surface of 2560 x 1440, fullscreen. 16:35:58.677 [display.initGL]: Created a new surface of 2560 x 1440, fullscreen. 16:35:58.687 [startup.complete]: ========== Loading complete in 2.23 seconds. ========== 16:35:58.874 [texture.load.png.warning]: ----- A PNG loading warning occurred for (null): Application built with libpng-1.4.7 but running with 1.6.50. 16:35:58.874 [texture.load.png.setup.failed]: ***** Error preparing to read /home/panoramix/GNUstep/Library/ApplicationSupport/Oolite/ManagedAddOns/oolite.oxp.Svengali.BGS.oxz/Images/bgs_intro.png.