When I have a spack install failing deep down in the dependencies, I usually get the list of dependencies from spack and try to install those with spack individually so I can see what is failing.
So, try "spack spec dea...@9.3.0" and that will give you the list of dependencies Spack thinks are needed (or it will fail doing that and tell you what it can't find). So in that list somewhere, you should see your dependency for gmsh. If that is what is
failing, then I would try to "spack install" that particular piece by itself (so, spack install gmsh@<version>) and see what happens. It simplifies the error messages you're dealing with so you only have to deal with one issue at a time.
I also try to use system-provided packages whenever I can. So, for instance, if a package I want to install with spack has a zlib dependency, I'm SURE that there's a zlib implementation I can install on the system without it having to be built with spack.
I then tell spack about it in the packages.yaml file so it knows it's there and doesn't try to build it. It's one less thing to worry about at that point. Note this isn't always the best solution, but for very common packages, I prefer it.
Good luck!