Exclude png.h and pngconf.h by default on Linux?

[Lone_Wolf]

The reason is mentioned at the end of the Readme.md:

So oolite .gitmodules allows forks to use their own versions of the submodules ?
Especially for 3rd party submodules (mozilla js, vorbis , ogg ) that seems unusual.

[another_commander]

So oolite .gitmodules allows forks to use their own versions of the submodules ?

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.

[hiran]

The reason is mentioned at the end of the Readme.md:

So oolite .gitmodules allows forks to use their own versions of the submodules ?
Especially for 3rd party submodules (mozilla js, vorbis , ogg ) that seems unusual.

It has to. How else would you develop stuff that requires changes to the submodules?
Or the other way round: how would you maintain the submodules without being able to test them in the full project?

[Lone_Wolf]

I'd make the absolute paths the defaults and advise those that need to test local/other versions of submodules to override that.

Currently the local submodules are the default and the absolute urls the exception.
To me this gives the impression that the local versions are deemed more important then the absolute versions.

It is possible that this comes from differing point of views. Mine is that of a user / downstream packager, not of a developer.

[mcarans]

I would like to ask a basic question: are submodules necessary? Could we for example use a monorepo or possibly package management (eg. GitHub itself can house build artifacts)?

The reason I ask is in case there might be a simpler way to organise the project particularly after MrFlibble's changes, including removing things that are obsolete, are merged.

There is much debate about the usage of submodules these days eg.

"In my experience, git submodules combine the worst of monorepos and multirepos. I get the idea. You want to separate independent or shared parts of the project into separate repos for a clean architecture and separation of concerns. But then why not go all they way and manage the dependencies with a proper package manager? Just publish the library projects to an internal package repository and pull them in the dependant repo. Often, especially in smaller projects or teams, the extra overhead is not worth it. You want to be able to work on multiple of these projects in tandem and iterate quickly. So you use submodules, because that's almost as if it was all in a single repo. But then why not go with a monorepo?"

"During my last 8 years working in dev teams, DevOps teams and plain ops teams, using Submodules always resulted in chaos, to the point that all projects abandoned submodules and added linters that forbid adding submodules"

[MrFlibble]

"During my last 8 years working in dev teams, DevOps teams and plain ops teams, using Submodules always resulted in chaos, to the point that all projects abandoned submodules and added linters that forbid adding submodules"

I'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?

[mcarans]

"During my last 8 years working in dev teams, DevOps teams and plain ops teams, using Submodules always resulted in chaos, to the point that all projects abandoned submodules and added linters that forbid adding submodules"

I'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?

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.

NB: I've noticed it is possible to change the subject in a reply on this BB and have done so for this one. Is that the right thing to do if the topic shifts?

[Wildeblood]

I've noticed it is possible to change the subject in a reply on this BB and have done so for this one. Is that the right thing to do if the topic shifts?

YES.

[Cholmondely]

NB: I've noticed it is possible to change the subject in a reply on this BB and have done so for this one. Is that the right thing to do if the topic shifts?

As per Wildeblood above.

Further - the chap who started the thread can go back and edit the title on his first post to include any relevant red herrings which were introduced.

[MrFlibble]

Building with libpng16, there's quite a lot of "iCCP: known incorrect sRGB profile" in the log. These are only warnings, but they are still noise.

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.

I'm wondering whether it'd be better to ignore the warnings in texture.load, or clean up the png files in the OXZs. The latter doesn't look too hard. Clues here https://stackoverflow.com/questions/227 ... e#22747902

From a short run:

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

To test, I read the linked article, apt install pngcrush, unzip my hacked up version of DTT_Warlance, then use this script to select errant files in the tree, and remove only the troublesome profile.

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

Output:
Fixing: ./Textures/DTT_War_Lance_Emissions.png :Good

Re-zipped, sorted!

I doubt all OXPs and all PNGs are being hit in my short run. It's not too hard to iterate through a directory of OXPs with unzip and test the pngs. This ugly script munches all the managed addons placing any fixed packages in /tmp/fixer/out. If this is aborted mid-run, do delete the $WORKDIR before trying again.

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

For my HEAP of OXZs these are the output files.
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.Griff_alloys_and_wreckage.oxz
oolite.oxp.Murgh.MilitaryFiasco.oxz
oolite.oxp.Okti.Coyotes_Run.oxz
oolite.oxp.phkb.ExtraRockHermits.oxz
oolite.oxp.phkb.SpacebarFacelift.oxz
oolite.oxp.Ramirez.FeudalStates.oxz
oolite.oxp.smivs.Liners.oxz
oolite.oxp.spara.ImperialAstrofactory.oxz
oolite.oxp.spara.market_ads.oxz
oolite.oxp.spara.station_ads.oxz
oolite.oxp.Thargoid.TCAT.oxz
oolite.oxp.ZygoUgo.ZygoCinematicSkyNebulas.oxz
oolite.oxp.zzz.Montana05.KillerWolf.nuit_station.oxz

Logs look cleaner Obviously I'm not touching versions here.

[phkb]

Building with libpng16, there's quite a lot of "iCCP: known incorrect sRGB profile" in the log. These are only warnings, but they are still noise.

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?

[MrFlibble]

Building with libpng16, there's quite a lot of "iCCP: known incorrect sRGB profile" in the log. These are only warnings, but they are still noise.

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.

Make of that what you will

[Lone_Wolf]

https://stackoverflow.com/questions/227 ... gb-profile gives some details

[MrFlibble]

https://stackoverflow.com/questions/227 ... gb-profile gives some details

That's the article I quoted above.

An eleven year old issue. For us it's only a warning, so my suggested fix for affected OXZs is mostly cosmetic, reducing log spam, and possibly a little system load.