Fork merge (Apr 2023)

Update spack pointer
Update variants (libpng; fms)

[ ] @climbfuji Todo: check if these variants need to be set in other templates

Starting over with fresh branch due to conflicts.
Systems/configurations to test:

[ ] unified-dev(+UFS) on Acorn (@AlexanderRichert-NOAA)
[ ] ufs-weather-model-static(+UFS) on Acorn (@AlexanderRichert-NOAA)
[ ] unified-dev(+UFS) on Hera (@AlexanderRichert-NOAA)
[ ] unified-dev(+UFS) on Orion (@AlexanderRichert-NOAA)
[ ] jedi-bundle ctests and skylab on Orion using Alex's unified-dev build (@climbfuji or @srherbener)
[x] ufs-weather-model-static (build only) on personal machine (@AlexanderRichert-NOAA)
[ ] unified-dev and skylab-dev on Dom's macOS (@climbfuji)
[ ] jedi-bundle ctests and skylab on Dom's macOS (@climbfuji)
[ ] unified-dev on S4 (@climbfuji or @srherbener)
[ ] jedi-bundle ctests and skylab on S4 (@climbfuji or @srherbener)
[ ] unified-dev on Discover (@climbfuji or @srherbener)
[ ] jedi-bundle ctests and skylab on Discover (@climbfuji or @srherbener)
[ ] container builds (all three compilers) for JEDI (@climbfuji)
[ ] container tests (using JCSDA CI tests) for JEDI (@climbfuji)
[ ] ... more to come ...

Dependencies

waiting on https://github.com/NOAA-EMC/spack/pull/254

Issues
Fixes https://github.com/NOAA-EMC/spack/issues/209

@AlexanderRichert-NOAA CI builds failed, macOS because of the same undefined references to nlohmann-json stuff in<EMAIL_ADDRESS>that we've seen before:
  >> 7408    Undefined symbols for architecture x86_64:
     7409      "__ZNKSt13runtime_error4whatEv", referenced from:
     7410          __ZNK8nlohmann16json_abi_v3_11_26detail9exception4whatEv in
             libesmf.a(ESMCI_Info.o)
     7411          __ZNK8nlohmann16json_abi_v3_11_26detail9exception4whatEv in
             libesmf.a(ESMCI_Base.o)
     7412          __ZNK8nlohmann16json_abi_v3_11_26detail9exception4whatEv in
             libesmf.a(ESMCI_PIO_Handler.o)
     7413          __ZNK8nlohmann16json_abi_v3_11_26detail9exception4whatEv in
             libesmf.a(ESMC_InfoCDef.o)
     7414          __ZNK8nlohmann16json_abi_v3_11_26detail9exception4whatEv in
             libesmf.a(ESMCI_Array.o)

The build on my macOS failed for the same reason. The Ubuntu build failed with duplicate symbols. Wondering if you want to try removing the debug build of ufs-weather-model from unified-dev?

I also get duplicate symbols on AWS Parallel Cluster
==> Do you want to proceed? [y/n] y
==> Error: Name clashes detected in module files:

file: /home/ubuntu/sandpit/spack-stack-merge-auth-20230413/envs/unified-env-test/install/modulefiles/openmpi/4.1.4/gcc/9.4.0/base-env/1.0.0.lua
spec: base-env<EMAIL_ADDRESS>build_system=bundle arch=linux-ubuntu20.04-icelake
spec: base-env<EMAIL_ADDRESS>build_system=bundle arch=linux-ubuntu20.04-icelake

file: /home/ubuntu/sandpit/spack-stack-merge-auth-20230413/envs/unified-env-test/install/modulefiles/intel-oneapi-mpi/2021.6.0/intel/2022.1.0/base-env/1.0.0.lua
spec: base-env<EMAIL_ADDRESS>build_system=bundle arch=linux-ubuntu20.04-icelake
spec: base-env<EMAIL_ADDRESS>build_system=bundle arch=linux-ubuntu20.04-icelake

file: /home/ubuntu/sandpit/spack-stack-merge-auth-20230413/envs/unified-env-test/install/modulefiles/openmpi/4.1.4/gcc/9.4.0/jedi-base-env/1.0.0.lua
spec: jedi-base-env<EMAIL_ADDRESS>build_system=bundle arch=linux-ubuntu20.04-icelake
spec: jedi-base-env<EMAIL_ADDRESS>build_system=bundle arch=linux-ubuntu20.04-icelake

file: /home/ubuntu/sandpit/spack-stack-merge-auth-20230413/envs/unified-env-test/install/modulefiles/intel-oneapi-mpi/2021.6.0/intel/2022.1.0/jedi-base-env/1.0.0.lua
spec: jedi-base-env<EMAIL_ADDRESS>build_system=bundle arch=linux-ubuntu20.04-icelake
spec: jedi-base-env<EMAIL_ADDRESS>build_system=bundle arch=linux-ubuntu20.04-icelake

file: /home/ubuntu/sandpit/spack-stack-merge-auth-20230413/envs/unified-env-test/install/modulefiles/openmpi/4.1.4/gcc/9.4.0/parallelio/2.5.9.lua
spec: parallelio<EMAIL_ADDRESS>build_system=cmake build_type=RelWithDebInfo generator=make arch=linux-ubuntu20.04-icelake
spec: parallelio<EMAIL_ADDRESS>build_system=cmake build_type=RelWithDebInfo generator=make arch=linux-ubuntu20.04-icelake

file: /home/ubuntu/sandpit/spack-stack-merge-auth-20230413/envs/unified-env-test/install/modulefiles/intel-oneapi-mpi/2021.6.0/intel/2022.1.0/parallelio/2.5.9.lua
spec: parallelio<EMAIL_ADDRESS>build_system=cmake build_type=RelWithDebInfo generator=make arch=linux-ubuntu20.04-icelake
spec: parallelio<EMAIL_ADDRESS>build_system=cmake build_type=RelWithDebInfo generator=make arch=linux-ubuntu20.04-icelake

==> Error: Operation aborted

The duplicate modules are coming from variant differences in parallelio, see screenshot

@AlexanderRichert-NOAA CI builds failed, macOS because of the same undefined references to nlohmann-json stuff in<EMAIL_ADDRESS>that we've seen before:
  >> 7408    Undefined symbols for architecture x86_64:
     7409      "__ZNKSt13runtime_error4whatEv", referenced from:
     7410          __ZNK8nlohmann16json_abi_v3_11_26detail9exception4whatEv in
             libesmf.a(ESMCI_Info.o)
     7411          __ZNK8nlohmann16json_abi_v3_11_26detail9exception4whatEv in
             libesmf.a(ESMCI_Base.o)
     7412          __ZNK8nlohmann16json_abi_v3_11_26detail9exception4whatEv in
             libesmf.a(ESMCI_PIO_Handler.o)
     7413          __ZNK8nlohmann16json_abi_v3_11_26detail9exception4whatEv in
             libesmf.a(ESMC_InfoCDef.o)
     7414          __ZNK8nlohmann16json_abi_v3_11_26detail9exception4whatEv in
             libesmf.a(ESMCI_Array.o)

The build on my macOS failed for the same reason. The Ubuntu build failed with duplicate symbols. Wondering if you want to try removing the debug build of ufs-weather-model from unified-dev?

@jedwards4b @theurich Are you aware of these linker issues with<EMAIL_ADDRESS>on macOS?
I think we have an idea about the ESMF build errors reported previously for Cray machines (#517), thanks to @AlexanderRichert-NOAA 's detective work. It's got to do with the recent change from edit to setup_build_environment. But the macOS thing is new. Seems like<EMAIL_ADDRESS>needs nlohmann-json?

Just removed the +debug. The errors almost look like different versions of nlohmann-json are getting used in different places? If removing the +debug doesn't make it go away we could see if there's a system installation that's confusing things.

I think the parallelio duplicate is because in the updated ESMF package, when ESMF has ~pnetcdf, then the dependency is<EMAIL_ADDRESS>+mpi~pnetcdf", but the default setting for parallelio is +pnetcdf in common/packages.yaml. Can we safely switch the parallelio default to ~pnetcdf or do we need it for something?

Hmm... The fact that it wasn't breaking before would tend to suggest that parallelio+pnetcdf wasn't breaking anything (at least I'm assuming that's what we were getting, I haven't looked). @theurich how important is that restriction (esmf~pnetcdf requires parallelio~pnetcdf)?

Hmm... The fact that it wasn't breaking before would tend to suggest that parallelio+pnetcdf wasn't breaking anything (at least I'm assuming that's what we were getting, I haven't looked). @theurich how important is that restriction (esmf~pnetcdf requires parallelio~pnetcdf)?

@AlexanderRichert-NOAA  I don't think it is critical. I just probably thought it made sense to aligned parallelio with esmf as for the pnetcdf usage. It was part of the change where I aligned ESMF's default of pnetcdf to what parallelio is doing (i.e. default to False) . But I see now that pushing the specific ESMF concretization down to the parallelio dependency is probably not a smart thing to do.  That agree with reverting that part of the change, especially if it fixes the issue at hand.

Hmm... The fact that it wasn't breaking before would tend to suggest that parallelio+pnetcdf wasn't breaking anything (at least I'm assuming that's what we were getting, I haven't looked). @theurich how important is that restriction (esmf~pnetcdf requires parallelio~pnetcdf)?

@AlexanderRichert-NOAA I don't think it is critical. I just probably thought it made sense to aligned parallelio with esmf as for the pnetcdf usage. It was part of the change where I aligned ESMF's default of pnetcdf to what parallelio is doing (i.e. default to False) . But I see now that pushing the specific ESMF concretization down to the parallelio dependency is probably not a smart thing to do. I agree with reverting that part of the change, especially if it fixes the issue at hand.

Thanks very much @theurich ! That's what I was thinking as well. ESMF shouldn't (and probably doesn't) care about whether parallelio can handle pnetcdf or not. If ESMF doesn't want to use it, it should simply ignore the functionality in parallelio if present (and I am pretty sure it does).

@AlexanderRichert-NOAA CI builds failed, macOS because of the same undefined references to nlohmann-json stuff in<EMAIL_ADDRESS>that we've seen before:
  >> 7408    Undefined symbols for architecture x86_64:
     7409      "__ZNKSt13runtime_error4whatEv", referenced from:
     7410          __ZNK8nlohmann16json_abi_v3_11_26detail9exception4whatEv in
             libesmf.a(ESMCI_Info.o)
     7411          __ZNK8nlohmann16json_abi_v3_11_26detail9exception4whatEv in
             libesmf.a(ESMCI_Base.o)
     7412          __ZNK8nlohmann16json_abi_v3_11_26detail9exception4whatEv in
             libesmf.a(ESMCI_PIO_Handler.o)
     7413          __ZNK8nlohmann16json_abi_v3_11_26detail9exception4whatEv in
             libesmf.a(ESMC_InfoCDef.o)
     7414          __ZNK8nlohmann16json_abi_v3_11_26detail9exception4whatEv in
             libesmf.a(ESMCI_Array.o)

The build on my macOS failed for the same reason. The Ubuntu build failed with duplicate symbols. Wondering if you want to try removing the debug build of ufs-weather-model from unified-dev?

@jedwards4b @theurich Are you aware of these linker issues with<EMAIL_ADDRESS>on macOS?
I think we have an idea about the ESMF build errors reported previously for Cray machines (#517), thanks to @AlexanderRichert-NOAA 's detective work. It's got to do with the recent change from edit to setup_build_environment. But the macOS thing is new. Seems like<EMAIL_ADDRESS>needs nlohmann-json?

@climbfuji - What setting of ESMF_COMPILER are you ending up with in this macOS build? For previous versions of ESMF that worked vs. now with<EMAIL_ADDRESS>Also, any chance the actual compiler version changed any? We are testing nightly on macOS. E.g. for the v8.4.1 release see the Darwin entries on the full release test table. To drill down into the test artifacts, follow the link in the last column of the table for any line you are interested in. Bottom line though is that we are not seeing any linking issues in our Darwin tests for v8.4.1.
As far as the Nlohmann JSON implementation ESMF uses, it consists of a single header file src/Infrastructure/Base/include/nlohmann/json/json.hpp which is part of the ESMF source tree.
One interesting observation from the link errors you are getting is that it seems to be only a very small number of symbols not found. My suspicion is that the Clang++ compiler for some reason does not create these specific instantiations of the associated template. I have no idea why that would have changed, or why your version of Clang is special in that regard, but that's kind of what it looks like. We could try to work around this by explicitly adding the flagged instantiations. But first maybe lets start figuring out what might have changed wrt ESMF_COMPILER and or Clang version.

@theurich would the same principle apply for mpi? That is, can we get rid of logic to the effect of depends("parallelio~mpi", when="~mpi") in esmf/package.py, or is that an actual constraint?

@AlexanderRichert-NOAA I think the mpi constraint between ESMF and ParallelIO is real. If ESMF is built with +mpi, it does assume that the ParallelIO it is using is also built the same way. Same for ~mpi.

@AlexanderRichert-NOAA I think the mpi constraint between ESMF and ParallelIO is real. If ESMF is built with +mpi, it does assume that the ParallelIO it is using is also built the same way. Same for ~mpi.

Fortunately that won't ever be a problem for us.

@theurich @climbfuji I'm now getting a different error from ESMF after removing the deprecated=True from 8.3.0b09, which previously was keeping it from being used (because packages.yaml settings are "soft" preferences): https://github.com/NOAA-EMC/spack-stack/actions/runs/4735552982/jobs/8405956769
I have no idea where this is coming from... Could it be related to OpenMPI version? Also, with the changes in ESMF variants, please check that my updated variants make sense:
Current: ~xerces ~pnetcdf +pio snapshot=b09 ~shared
New: ~xerces ~pnetcdf snapshot=b09 ~shared esmf_pio=internal

Hmm not sure, I think this is a problem that it doesn't set the -fallow-argument-mismatch flag correctly for 8.3.0b09 with internal PIO: https://github.com/AlexanderRichert-NOAA/spack/blob/deadeb2d6f2dc1647ea38ede4090ea307e9559bb/var/spack/repos/builtin/packages/esmf/package.py#L267

That seems pretty promising. I'm adding 8.3.0b09 to see if that does the trick, then we can figure out the best permanent fix.

@AlexanderRichert-NOAA and @climbfuji - when I made that change wrt -fallow-argument-mismatch in the ESMF Spack package.py, I was really hoping that we were getting away from this random v8.3.0b09 snapshot. That's also why I marked it as deprecated in that same PR. But apparently the transition is taking a lot longer than I thought.
I wonder, what are the outstanding issues that prevent UFS apps to move on to ESMF v8.4.1? Is that something we need @junwang-noaa to comment on? Or is it something else that is slowing this down?

We have been tested ESMF 8.4.1 on hera/orion/acorn etc. My understanding is that we are waiting for NCO to install the new version libraries (HDF 1.14.0, netcdf 4.9.2, esmf 8.4.1 and mapl 2.35.2) on wcoss2. Once these libraries are available we will update the model to use these libraries.

@junwang-noaa @theurich There are a couple of show stoppers for this transition:

ESMF 8.4.1 doesn't build on macOS and it doesn't build on a few other systems if I recall correctly due to missing dependencies: https://github.com/NOAA-EMC/spack-stack/issues/517#issuecomment-1499546962
<EMAIL_ADDRESS>a requirement for ESMF 8.4.1, breaks JEDI: plotting scripts performing masked array operations on hdf5 objects through py-h5py take several minutes per operations as opposed to fractions of a second with<EMAIL_ADDRESS>There are also downstream dependency problems, namely<EMAIL_ADDRESS>not building on certain cray systems: https://github.com/NOAA-EMC/spack-stack/issues/524

Further:

ESMF in general doesn't build anymore on Narwhal - see https://github.com/NOAA-EMC/spack-stack/issues/517, and see also https://github.com/NOAA-EMC/spack-stack/issues/523 and talk to @AlexanderRichert-NOAA about the general problem that the ESMF build now depends on the modules loaded by the installer

So, in summary, if we want a unified environment we need to

find a solution for the<EMAIL_ADDRESS>problem
fix the ESMF builds once again (all of them)
fix the MAPL issues

@climbfuji Thanks for sharing the issues. From my understanding,

we do need to go to ESMF 8.4.1 release to replace the current ESMF 830b9 snapshot, do you have issues ESMF830b9 on macOS or Narwhal?
HDF 1.14.0 is not a requirement for ESMF 8.4.1 if I understand correctly. We have to go to HDF 1.12.2 or higher to fix the parallel netcdf issue seen in the RRFS parallel.  If we  change to HDF 1.12.2, we need to submit new request to NCO, the RRFS group has been waiting for the library update.
We need to update MAPL (2.35.2) to enable GOCART threading capability.
In general we want to first confirm the libraries run successfully on tier-1 platforms in order to update UFS WM. I am not sure if it is required to run them on all the platforms (macOS and Narwhal). Also it takes time for NCO to install libraries. I am worried that we may be not able to update libraries with all these requirements any time soon. @arunchawla-NOAA FYI.

I do not think ESMF 8.4.1 requires hdf5/1.14.0, we have built ESMF 8.4.1 with hdf5/1.10.6 in operations. Will hdf5/1.12.2 be an appropriate compromise solution till the JEDI team determines the issues with hdf5/1.14.0?

@climbfuji I fixed the remaining Mac OS failure by unspecifying the openmpi version number in two places in the github actions (I think the one it was failing on was the packages.yaml provider setting, which wasn't matching with the version in the module directory structure). Alternative approaches would be to update it to the new latest openmpi version (4.1.5), or to set the default openmpi version in common/packages.yaml.

hdf5 1.12.2 would be perfect, yes.
Reminds me that GSI also didn’t like hdf5 1.14.0, so going to 1.12.2 will be good for them too.

On Apr 18, 2023, at 7:18 PM, arun chawla @.***> wrote:
I do not think ESMF 8.4.1 requires hdf5/1.14.0, we have built ESMF 8.4.1 with hdf5/1.10.6 in operations. Will hdf5/1.12.2 be an appropriate compromise solution till the JEDI team determines the issues with hdf5/1.14.0?
—
Reply to this email directly, view it on GitHub https://github.com/NOAA-EMC/spack-stack/pull/545#issuecomment-1513999481, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB5C2RKLM67JTIZS5MOPRP3XB44P7ANCNFSM6AAAAAAW5WQF3U.
You are receiving this because you were mentioned.

On Apr 18, 2023, at 6:35 PM, Jun Wang @.***> wrote:
@climbfuji https://github.com/climbfuji Thanks for sharing the issues. From my understanding,
we do need to go to ESMF 8.4.1 release to replace the current ESMF 830b9 snapshot, do you have issues ESMF830b9 on macOS or Narwhal?
no issues with esmf 830b09 on macOS; but issues with all versions (since a recent update to the ESMF package in spack) on Narwhal. The latter isn’t the most pressing problem, the former is more important.
HDF 1.14.0 is not a requirement for ESMF 8.4.1 if I understand correctly. We have to go to HDF 1.12.2 or higher to fix the parallel netcdf issue seen in the RRFS parallel. If we change to HDF 1.12.2, we need to submit new request to NCO, the RRFS group has been waiting for the library update.
thanks for that correction, 1.12.2 is perfet

We need to update MAPL (2.35.2) to enable GOCART threading capability.
In general we want to first confirm the libraries run successfully on tier-1 platforms in order to update UFS WM. I am not sure if it is required to run them on all the platforms (macOS and Narwhal). Also it takes time for NCO to install libraries. I am worried that we may be not able to update libraries with all these requirements any time soon. @arunchawla-NOAA https://github.com/arunchawla-NOAA FYI.
I hope that the ESMF and MAPL developers come to aid and help fix the build problems we are seeing. We’ll do as much as we can. For JEDI-UFS, we need to be able to build on macOS. We can stay “behind” in terms of ufs-weather-model for a bit so that we can stick with mapl 2.22, but then we won’t be able to merge our updates back into the UFS authoritative repositories.

—
Reply to this email directly, view it on GitHub https://github.com/NOAA-EMC/spack-stack/pull/545#issuecomment-1513954487, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB5C2ROK6FGIQZIIGODEIWTXB4XM5ANCNFSM6AAAAAAW5WQF3U.
You are receiving this because you were mentioned.

@climbfuji I fixed the remaining Mac OS failure by unspecifying the openmpi version number in two places in the github actions (I think the one it was failing on was the packages.yaml provider setting, which wasn't matching with the version in the module directory structure). Alternative approaches would be to update it to the new latest openmpi version (4.1.5), or to set the default openmpi version in common/packages.yaml.

Does this mean the MacOS issues @climbfuji  mentioned as critical for JEDI are resolved, or are there outstanding ones?

@climbfuji I fixed the remaining Mac OS failure by unspecifying the openmpi version number in two places in the github actions (I think the one it was failing on was the packages.yaml provider setting, which wasn't matching with the version in the module directory structure). Alternative approaches would be to update it to the new latest openmpi version (4.1.5), or to set the default openmpi version in common/packages.yaml.

Does this mean the MacOS issues @climbfuji mentioned as critical for JEDI are resolved, or are there outstanding ones?

I think not, because the default ESMF is still 8.3.0b09 and that gets built in the CI tests. We still have this problem with missing nlohjmann-json symbols, and I need to do a bit of investigation on my end and give you the answers (I just remembered).

@climbfuji - this is very useful info!! The problem has to do with the explicit setting of ESMF_CXX and ESMF_F90, which is causing issues here because for Darwin.gfortranclang we need to link with the C++ wrapper, even when main is in Fortran. Let me work on this on the ESMF side. I will let you know when I have a snapshot that would be good to test next. This will be a v8.4.2b snapshot... since we have that in the pipeline for EMC anyway... and will likely supersede v8.4.1 very soon.

@climbfuji - this is very useful info!! The problem has to do with the explicit setting of ESMF_CXX and ESMF_F90, which is causing issues here because for Darwin.gfortranclang we need to link with the C++ wrapper, even when main is in Fortran. Let me work on this on the ESMF side. I will let you know when I have a snapshot that would be good to test next. This will be a v8.4.2b snapshot... since we have that in the pipeline for EMC anyway... and will likely supersede v8.4.1 very soon.

Thanks very much @theurich ! Looking forward to testing the new snapshot.

@climbfuji - please give ESMF v8.4.2b02 a shot. If I got it right, this should fix the ESMF linking problem you reported under Spack on macOS. Thanks!

Apparently the updated compiler logic in hdf5/package.py (MPI_C_COMPILER instead of CMAKE_C_COMPILER, etc.) needs cmake 3.23 or later, so I'm removing the external<EMAIL_ADDRESS>from the Orion config to force it to build 3.23.1. At some point I'll put in a bug report for spack/hdf5 because that should be a requirement.

@climbfuji - please give ESMF v8.4.2b02 a shot. If I got it right, this should fix the ESMF linking problem you reported under Spack on macOS. Thanks!

Brilliant, thanks very much @theurich! This builds cleanly on my macOS. I heard today that the new target for the UFS is<EMAIL_ADDRESS>with<EMAIL_ADDRESS>and that<EMAIL_ADDRESS>will be ready soon-ish.  So I guess we'll just need to use 8.4.2b02 instead of 8.4.1 (this should be a separate PR on top of this one, maybe also fixing the problems on Narwhal at the same time.)

@AlexanderRichert-NOAA FYI Seems like with this update, spack does no longer like the "exclude" syntax, because it is trying to build jedi-tools-env with Intel. I haven' looked into it at all, but wanted to report back.

==> Warning: Skipping build of py-pygithub-1.55-hsl2wzgcc5t3x6cicfpgrazcbhn3nqc7 since py-pynacl-1.5.0-ff7jjvtr7dcef2tcsqdkydsmfivzheue failed
==> Warning: Skipping build of jedi-tools-env-unified-dev-6f6bxo3z5ffoiiji56ko6sy6hwlghkbr since py-pygithub-1.55-hsl2wzgcc5t3x6cicfpgrazcbhn3nqc7 failed
==> Error: jedi-tools-env-unified-dev-6f6bxo3z5ffoiiji56ko6sy6hwlghkbr: Package was not installed
==> Error: Installation request failed.  Refer to reported errors for failing package(s).
[+] /home/ubuntu/sandpit/spack-stack-fork-merge/envs/unified-env/install/intel/2022.1.0/py-requests-2.28.2-fhpakcz
[+] /home/ubuntu/sandpit/spack-stack-fork-merge/envs/unified-env/install/intel/2022.1.0/py-pyproject-metadata-0.7.1-s74xuvj
[+] /home/ubuntu/sandpit/spack-stack-fork-merge/envs/unified-env/install/intel/2022.1.0/py-numexpr-2.8.3-5bxjyvd
[+] /home/ubuntu/sandpit/spack-stack-fork-merge/envs/unified-env/install/intel/2022.1.0/py-versioneer-0.28-x3zh7ns
[+] /home/ubuntu/sandpit/spack-stack-fork-merge/envs/unified-env/install/intel/2022.1.0/py-pyproject-hooks-1.0.0-vj2blsr
[+] /home/ubuntu/sandpit/spack-stack-fork-merge/envs/unified-env/install/intel/2022.1.0/py-setuptools-scm-7.0.5-yhnmvey
[+] /home/ubuntu/sandpit/spack-stack-fork-merge/envs/unified-env/install/intel/2022.1.0/py-sphinx-6.0.0-hpxmjkk
[+] /home/ubuntu/sandpit/spack-stack-fork-merge/envs/unified-env/install/intel/2022.1.0/py-meson-python-0.13.0.pre0-fhijt2d
[+] /home/ubuntu/sandpit/spack-stack-fork-merge/envs/unified-env/install/intel/2022.1.0/py-bottleneck-1.3.5-ijcomjp
[+] /home/ubuntu/sandpit/spack-stack-fork-merge/envs/unified-env/install/intel/2022.1.0/py-build-0.10.0-dldrigz
[+] /home/ubuntu/sandpit/spack-stack-fork-merge/envs/unified-env/install/intel/2022.1.0/py-python-dateutil-2.8.2-jwrcdkq
[+] /home/ubuntu/sandpit/spack-stack-fork-merge/envs/unified-env/install/intel/2022.1.0/py-scipy-1.9.3-zuxmlld
[+] /home/ubuntu/sandpit/spack-stack-fork-merge/envs/unified-env/install/intel/2022.1.0/py-pandas-1.4.0-kj3rz5k
==> Removing failure mark on py-pynacl-1.5.0-ff7jjvtr7dcef2tcsqdkydsmfivzheue
==> Removing failure mark on py-pygithub-1.55-hsl2wzgcc5t3x6cicfpgrazcbhn3nqc7
==> Removing failure mark on jedi-tools-env-unified-dev-6f6bxo3z5ffoiiji56ko6sy6hwlghkbr

Hmm that doesn't sound right, I haven't seen any jedi-tools-env%intel in my testing, and I concretized unified-dev on my personal machine with the latest commit just now. Can you show maybe upload your spack concretize output?

Hmm that doesn't sound right, I haven't seen any jedi-tools-env%intel in my testing, and I concretized unified-dev on my personal machine with the latest commit just now. Can you show maybe upload your spack concretize output?

Yes, this is weird. When I ran the first install of everything, it didn't try to install jedi-tools-env with intel, concretized correctly. But then I added the additional versions of esmf, mapl, crtm and the concretizer got confused. Not sure why, never happened before. Anyway, not a show stopper.

I got another problem on my macOS that didn't happen with release 1.3.1. When the new spack finds an external gmake in the homebrew installation, it wants to use that one but can't find make (because homebrew keeps it as gmake). Poking around in the spack code I see that the spack install of gmake creates a symlink from gmake to make after installation, but of course it doesn't do that for external packages. Wondering if something in spack/lib/spack changed so that instead of calling either gmake or make, whichever available, it always wants to use make. For now, I manually removed the external gmake installation in the homebrew folder, there is still the native Apple make install in /usr. Hopefully that works fine. But we'll need to figure out what has changed and how to fix this w/o manual intervention.

Hmm that doesn't sound right, I haven't seen any jedi-tools-env%intel in my testing, and I concretized unified-dev on my personal machine with the latest commit just now. Can you show maybe upload your spack concretize output?

Yes, this is weird. When I ran the first install of everything, it didn't try to install jedi-tools-env with intel, concretized correctly. But then I added the additional versions of esmf, mapl, crtm and the concretizer got confused. Not sure why, never happened before. Anyway, not a show stopper.

This is how the concretizer messed up:
==> Concretized jedi-tools-env@unified-dev%gcc
 -   6f6bxo3  jedi-tools-env<EMAIL_ADDRESS>build_system=bundle arch=linux-ubuntu20.04-icelake
 -   hsl2wzg      ^py-pygithub<EMAIL_ADDRESS>build_system=python_pip arch=linux-ubuntu20.04-icelake
 -   ff7jjvt          ^py-pynacl<EMAIL_ADDRESS>build_system=python_pip arch=linux-ubuntu20.04-icelake

Here's an update on my testing on Orion.

I successfully built jedi-bundle, develop branches, using @AlexanderRichert-NOAA's unified-dev build.
All jedi tests pass except for the following tests which are currently broken in develop

1261:fv3jedi_test_tier1_hyb-3dvar_gfs_aero
1265:fv3jedi_test_tier1_hyb-fgat_gfs_aero
1328:test_soca_ensvariance

I ran a couple skylab tests

gfs-hofx4d-c96.yaml

This failed due to a fault in the observation data file names (not related to spack-stack)

l95-4dvar.yaml

Completed successfully

skylab-atm-land.yaml

This appears to be hanging on eda member variational runs (or executing very slowly)

I noticed that the unified-dev has<EMAIL_ADDRESS>which is known to have performance issues with some of the python script (h5py package). Perhaps this is related to the slow runtimes of the variational runs.
I also noticed that the feature branch for this PR is out of sync with develop which has<EMAIL_ADDRESS>as the default version for hdf5. Does it make sense to sync this feature branch with develop and rebuild the unified-dev spack-stack before continuing with testing on Orion?

Hmm yep good point. I had held off merging this to avoid rebuilding for every little change, but it would make sense to rebuild since I merged the hdf5 changes. I'll do that and let you know, sorry I didn't think to mention that.

@AlexanderRichert-NOAA sounds great! Thank you for doing the rebuild, I realize that's a bit of work and I appreciate your effort to do so.

Okay @srherbener try /work/noaa/nems/arichert/merge-test/spack-stack/envs/unified-test-2may2023/install/modulefiles/Core

Thanks @AlexanderRichert-NOAA! I'll give it a try.

Bummer, it looks like the wrong version of CRTM got built. The new unified-test-2may2023 stack has<EMAIL_ADDRESS>instead of<EMAIL_ADDRESS>(which is in the original unified-test stack). @climbfuji is my assessment correct?
Does that mean that develop has the wrong version?

Looks like the crtm version change (in jedi-base-env/package.py) occurred between 1.3.0 and 1.31 (https://github.com/NOAA-EMC/spack/pull/259).
ufo doesn't compile for me now (using<EMAIL_ADDRESS>with an error:
[ 62%] Building Fortran object ufo/src/ufo/CMakeFiles/ufo.dir/operators/gnssro/BndNBAM/ufo_gnssro_bndnbam_mod.F90.o
/work/noaa/da/herbener/jedi/jedi-bundle/ufo/src/ufo/operators/crtm/ufo_crtm_utils_mod.F90(130): error #6775: The size of SOURCE must be greater than or equal to PRODUCT(SHAPE).   [RESHAPE]
         reshape( &
---------^
/work/noaa/da/herbener/jedi/jedi-bundle/ufo/src/ufo/operators/crtm/ufo_crtm_utils_mod.F90(140): error #6366: The shapes of the array expressions do not conform.   [CRTM_CLOUD_ID]
      CRTM_Cloud_Id(N_VALID_CLOUD_CATEGORIES) = &
------^

Am I doing something wrong with my build?
Thanks!

This has been discussed extensively in the jcsda-core slack channel (but you were on leave during that time). If using spack-stack-1.3.1, you need to manually load<EMAIL_ADDRESS>after loading the usual modules. This will swap out the<EMAIL_ADDRESS>module. The oops PR that is needed for<EMAIL_ADDRESS>hasn't been merged yet, although I was asked to provide the new version in a hurry so that the PR can go in ...

Thanks @climbfuji for the explanation. It makes sense. I tried running module load crtm/v2.4.1-jedi.2, but I'm getting this error:
Lmod has detected the following error:  The following module(s) are unknown:
"crtm/v2.4.1-jedi.2"

Please check the spelling or version number. Also try "module spider ..."
It is also possible your cache file is out-of-date; it may help to try:
  $ module --ignore-cache load "crtm/v2.4.1-jedi.2"

Also make sure that all modulefiles written in TCL start with the string #%Module

It looks like only the<EMAIL_ADDRESS>version was built:
(venv) Orion-login-2[56] herbener$ ll /work/noaa/nems/arichert/merge-test/spack-stack/envs/unified-test-2may2023/install/intel/2022.0.2/ | grep crtm
drwxr-sr-x   5 arichert nems  4096 May  3 07:09 crtm-2.4.0-rfba2zn/
drwxr-sr-x   4 arichert nems  4096 May  3 03:07 crtm-fix-2.4.0_emc-r5j6suo/
drwxr-sr-x   6 arichert nems  4096 May  3 07:12 crtm-v2.4.1-jedi-f6bxsc4/

Would it make sense to wait for the oops PR (enabling<EMAIL_ADDRESS>before proceeding?

ohhh that's because @AlexanderRichert-NOAA didn't install the additional versions that we post-install manually in any spack-stack-1.3.1 installation:
#!/bin/bash

spack install --add --verbose<EMAIL_ADDRESS>2>&1 | tee log.install.unified-env.002.crtm-v3.0.0-rc.1.intel
spack install --add --verbose<EMAIL_ADDRESS> 2>&1 | tee log.install.unified-env.002.crtm-v3.0.0-rc.1.gcc

spack install --add --verbose<EMAIL_ADDRESS>2>&1 | tee log.install.unified-env.003.crtm-v2.4-jedi.2.intel
spack install --add --verbose<EMAIL_ADDRESS> 2>&1 | tee log.install.unified-env.003.crtm-v2.4-jedi.2.gcc

spack install --add --verbose<EMAIL_ADDRESS>~debug+external-parallelio snapshot=none 2>&1 | tee log.install.unified-env.004.esmf-8.4.1.intel
spack install --add --verbose<EMAIL_ADDRESS> ~debug+external-parallelio snapshot=none 2>&1 | tee log.install.unified-env.004.esmf-8.4.1.gcc

spack install --add --verbose<EMAIL_ADDRESS>~debug<EMAIL_ADDRESS>~debug+external-parallelio snapshot=none 2>&1 | tee log.install.unified-env.005.mapl-2.35.2.intel
spack install --add --verbose<EMAIL_ADDRESS> ~debug<EMAIL_ADDRESS> ~debug+external-parallelio snapshot=none 2>&1 | tee log.install.unified-env.005.mapl-2.35.2.gcc

No, we should not make this PR dependent on yet another PR, it already depends on two pending issues/PRs in the authoritative spack repo (changes are that the ufo PR gets merged before these two are addressed, but one never knows).

I got a lot further on macOS, environment built successfully, and I can build jedi-bundle. But running ctest fails with
1265: Test command: /Users/heinzell/scratch/spack-stack-fork-merge-20230504/envs/unified-env/install/apple-clang/13.1.6/openmpi-4.1.5-h3kxjfp/bin/mpiexec "-n" "6" "/Users/heinzell/scratch/skylab_testing_fork_merge/build-release/bin/fv3jedi_error_covariance_training.x" "testinput/bumpparameters_nicas_geos.yaml"
1265: Environment variables:
1265:  OMP_NUM_THREADS=1
1265: Test timeout computed to be: 1500
1265: dyld[25909]: Library not loaded: liblz4.1.dylib
1265:   Referenced from: /Users/heinzell/scratch/spack-stack-fork-merge-20230504/envs/unified-env/install/apple-clang/13.1.6/eckit-1.23.0-insao47/lib/libeckit.dylib
1265:   Reason: tried: '/Users/heinzell/scratch/spack-stack-fork-merge-20230504/envs/unified-env/install/apple-clang/13.1.6/crtm-v2.4-jedi.2-mmpiqv2/lib/liblz4.1.dylib' (no such file), '/Users/heinzell/scratch/spack-stack-fork-merge-20230504/envs/unified-env/install/apple-clang/13.1.6/py-ruamel-yaml-clib-0.2.4-6tw2vbq/lib/liblz4.1.dylib' (no such file), '/Users/heinzell/scratch/spack-stack-fork-merge-20230504/envs/unified-env/install/apple-clang/13.1.6/py-ruamel-yaml-0.17.16-pcexadp/lib/liblz4.1.dylib' (no such file), '/Users/heinzell/scratch/spack-stack-fork-merge-20230504/envs/unified-env/install/apple-clang/13.1.6/py-jinja2-3.1.2-prspy5d/lib/liblz4.1.dylib' (no such file), '/Users/heinzell/scratch/spack-stack-fork-merge-20230504/envs/unified-env/install/apple-clang/13.1.6/py-markupsafe-2.1.1-drcgnhh/lib/liblz4.1.dylib' (no such file), '/Users/heinzell/scratch/spack-stack-fork-merge-20230504/envs/unified-env/install/apple-clang/13.1.6/py-gitpython-3.1.27-46ptewn/lib/liblz4.1.dylib' (no such file), '/Users/heinzell/scratch/spack-stack-fork-merge-20230504/envs/unified-env/install/apple-clang/13.1.6/py-gitdb-4.0.9-srzqny5/lib/liblz4.1.dylib' (no such file), '/Users/heinzell/scratch/spack-stack-fork-merge-20230504/envs/unified-env/install/apple-clang/13.1.6/py-smmap-5.0.0-56e2ijj/lib/liblz4.1.dylib' (no such file), '/Users/heinzell/scratch/spack-stack-fork-merge-20230504/envs/unified-env/install/apple-clang/13.1.6/py-cartopy-0.21.1-eviv26u/lib/liblz4.1.dylib' (no such file), '/Users/heinzell/scratch/spack-stack-fork-merge-20230504/envs/unified-env/install/apple-clang/13.1.6/py-shapely-1.8.0-w4qeukb/lib/liblz4.1.dylib' (no such file), '/Users/heinzell/scratch/spack-stack-fork-merge-20230504/envs/unified-env/install/apple-clang/13.1.6/py-pyshp-2.1.0-my2as5c/lib/liblz4.1.dylib' (no such file), '/Users/heinzell/scratch/spack-stack-fork-merge-20230504/envs/unified-env/install/apple-clang/13.1.6/py-pyproj-3.1.0-otay7x7/lib/liblz4.1.dylib' (no such file), '/Users/heinzell/scratch/spack-stack-fork-merge-20230504/envs/unified-env/install/apple-clang/13.1.6/py-certifi-2022.12.7-lvstdld/lib/liblz4.1.dylib' (no such file), '/Users/heinzell/scratch/spack-stack-fork-merge-20230504/envs/unified-env/install/apple-clang/13.1.6/py-matplotlib-3.7.1-doss2ms/lib/liblz4.1.dylib' (no such file), '/Users/heinzell/scratch/spack-stack-fork-merge-20230504/envs/unified-env/install/apple-clang/13.1.6/py-pyparsing-3.0.9-bzk45in/lib/liblz4.1.dylib' (no such file), '/Users/heinzell/scratch/spack-stack-fork-merge-20230504/envs/unified-env/install/apple-clang/13.1.6/py-pillow-9.4.0-kisagqa/lib/liblz4.1.dylib' (no such file), '/Users/heinzell/scratch/spack-stack-fork-merge-20230504/envs/unified-env/install/apple-clang/13.1.6/py-kiwisolver-1.3.2-g4afv54/lib/liblz4.1.dylib' (no such file), '/Users/heinzell/scratch/spack-stack-fork-merge-20230504/envs/unified-env/install/apple-clang/13.1.6/py-fonttools-4.37.3-ul6kbeb/lib/liblz4.1.dylib' (no such file), '/Users/heinzell/scratch/spack-stack-fork-merge-20230504/envs/unified-env/install/apple-clang/13.1.6/py-cycler-0.11.0-o5ohfyb/lib/liblz4.1.dylib' (no such file), '/Users/heinzell/scratch/spack-stack-fork-merge-20230504/envs/unified-env/install/apple-clang/13.1.6/py-contourpy-1.0.

This works with spack-stack-1.3.1.

Here is the otool -L output. Something is wrong with lz4:
> otool -L ~/prod/spack-stack-1.3.1/envs/unified-env/install/apple-clang/13.1.6/eckit-1.23.0-wgxbjei/lib/libeckit.dylib
/Users/heinzell/prod/spack-stack-1.3.1/envs/unified-env/install/apple-clang/13.1.6/eckit-1.23.0-wgxbjei/lib/libeckit.dylib:
	@rpath/libeckit.dylib (compatibility version 0.0.0, current version 0.0.0)
	/Users/heinzell/prod/spack-stack-1.3.1/envs/unified-env/install/apple-clang/13.1.6/ncurses-6.3-i32fmsa/lib/libncurses.6.dylib (compatibility version 6.0.0, current version 6.0.0)
	/Users/heinzell/prod/spack-stack-1.3.1/envs/unified-env/install/apple-clang/13.1.6/ncurses-6.3-i32fmsa/lib/libtinfo.6.dylib (compatibility version 6.0.0, current version 6.0.0)
	/Users/heinzell/prod/spack-stack-1.3.1/envs/unified-env/install/apple-clang/13.1.6/ncurses-6.3-i32fmsa/lib/libncursesw.6.dylib (compatibility version 6.0.0, current version 6.0.0)
	/Users/heinzell/prod/spack-stack-1.3.1/envs/unified-env/install/apple-clang/13.1.6/ncurses-6.3-i32fmsa/lib/libtinfow.6.dylib (compatibility version 6.0.0, current version 6.0.0)
	/Users/heinzell/prod/spack-stack-1.3.1/envs/unified-env/install/apple-clang/13.1.6/lz4-1.9.4-sscnvlj/lib/liblz4.1.dylib (compatibility version 1.0.0, current version 1.9.4)
	@rpath/libbz2.1.dylib (compatibility version 1.0.8, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.23.0)

versus
> otool -L envs/unified-env/install/apple-clang/13.1.6/eckit-1.23.0-insao47/lib/libeckit.dylib
envs/unified-env/install/apple-clang/13.1.6/eckit-1.23.0-insao47/lib/libeckit.dylib:
	@rpath/libeckit.dylib (compatibility version 0.0.0, current version 0.0.0)
	/Users/heinzell/scratch/spack-stack-fork-merge-20230504/envs/unified-env/install/apple-clang/13.1.6/ncurses-6.4-wf5xx3x/lib/libncurses.6.dylib (compatibility version 6.0.0, current version 6.0.0)
	/Users/heinzell/scratch/spack-stack-fork-merge-20230504/envs/unified-env/install/apple-clang/13.1.6/ncurses-6.4-wf5xx3x/lib/libtinfo.6.dylib (compatibility version 6.0.0, current version 6.0.0)
	/Users/heinzell/scratch/spack-stack-fork-merge-20230504/envs/unified-env/install/apple-clang/13.1.6/ncurses-6.4-wf5xx3x/lib/libncursesw.6.dylib (compatibility version 6.0.0, current version 6.0.0)
	/Users/heinzell/scratch/spack-stack-fork-merge-20230504/envs/unified-env/install/apple-clang/13.1.6/ncurses-6.4-wf5xx3x/lib/libtinfow.6.dylib (compatibility version 6.0.0, current version 6.0.0)
	liblz4.1.dylib (compatibility version 1.0.0, current version 1.9.4)
	@rpath/libbz2.1.dylib (compatibility version 1.0.8, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.23.0)

@AlexanderRichert-NOAA Please update the spack submodule pointer to the latest hash when you get the chance. Thanks!

Please ignore the failing readthedocs build here, this will be fixed in the next PR (commit https://github.com/NOAA-EMC/spack-stack/pull/555/commits/354a9654807ea434a7455f53d38e02270206e838)

@climbfuji--
2) I believe these are all correct now after I updated the external-parallelio variant name for ESMF, but I'm doing one last build on Acorn to make sure. That'll be done in a few minutes.
3) I just updated the external-parallelio variant in those commented lines; is there anything else in the unified-dev template that needs to change?

Ok, let me try on Narwhal

Ok, let me try on Narwhal

Getting this on Narwhal:
> spack concretize 2>&1 | tee log.concretize
==> Error: Cannot find valid provider for virtual mpi

Hm cool that's weird. Try (re)moving your ~/.spack? I've run into similar provider issues when moving between spack versions.

I removed the target: any and it worked

On May 9, 2023, at 11:23 AM, Alex Richert @.***> wrote:
Hm cool that's weird. Try (re)moving your ~/.spack? I've run into similar provider issues when moving between spack versions.
—
Reply to this email directly, view it on GitHub https://github.com/NOAA-EMC/spack-stack/pull/545#issuecomment-1540573704, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB5C2RMSAG7TPITHRBZERKDXFJ4QVANCNFSM6AAAAAAW5WQF3U.
You are receiving this because you were mentioned.

Cool, I'll take care of them in one go.

No need to retest CI for the last few commits. Should I merge?

Good point. I'll go ahead and do the merge if you don't mind.


Ensure special keys for completion are processed immediately

This will make a difference for fast typists who have keys queued up in the typeahead buffer.
See #231.

I can't reproduce the random chars issue anymore!
Not sure why the build is failing, but doesn't look major, so I'm gonna go ahead and merge this. Thanks!

Great news :)


Languages Not Showing Up

For some reason, the Korean, Japanese, and Dutch text does not show up in docs.neo.org for the main index. Furthermore, Dutch translation does not show up on the top bar.

Fixed.


Will you upload wheel file for tensorflow 1.8.0 for Python 3.6. You only have for 3.5 & 2.7

Will you upload wheel file for tensorflow 1.8.0 for Python 3.6. You only have for 3.5 & 2.7

@parallelo since we publish 3.6 packages now, would you mind share some info here and close this ticket?


New app : GPS Speed Alt

Tweaked setting to allow a maximum locale time offset of +13 hours to cater for current New Zealand daylight saving time.
Adding a new GPS speedometer app.

This looks great - thanks!

This looks great - thanks!

Just a quick one though - what is the Theme set for? (theme: jekyll-theme-slate in _config.yml)
It seems that since the main site is styled with its own CSS, we probably don't want this? Or am I missing something?

Just a quick one though - what is the Theme set for? (theme: jekyll-theme-slate in _config.yml)
It seems that since the main site is styled with its own CSS, we probably don't want this? Or am I missing something?

Hi Gordon,Honestly, I dont have a clue where that theme file came from. I Followed the tutorial and instructions for adding an app and I only spotted it when doing a compare earlier today before the pull request. 10pm right now so give me a day to work it out. I haven't consciously included anything like that so delete if you like. My intention is to add a bog standard app to the list.  Cheers Mike.
-------- Original message --------From: Gordon Williams<EMAIL_ADDRESS>Date: 29/01/21  21:48  (GMT+12:00) To: espruino/BangleApps<EMAIL_ADDRESS>Cc: nujw<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [espruino/BangleApps] New app : GPS Speed Alt (#651)
Just a quick one though - what is the Theme set for? (theme: jekyll-theme-slate in _config.yml)
It seems that since the main site is styled with its own CSS, we probably don't want this? Or am I missing something?
—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.
[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/espruino/BangleApps/pull/651#issuecomment-769667096",
"url": "https://github.com/espruino/BangleApps/pull/651#issuecomment-769667096",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]

Hi Gordon,Honestly, I dont have a clue where that theme file came from. I Followed the tutorial and instructions for adding an app and I only spotted it when doing a compare earlier today before the pull request. 10pm right now so give me a day to work it out. I haven't consciously included anything like that so delete if you like. My intention is to add a bog standard app to the list.  Cheers Mike.
-------- Original message --------From: Gordon Williams<EMAIL_ADDRESS>Date: 29/01/21  21:48  (GMT+12:00) To: espruino/BangleApps<EMAIL_ADDRESS>Cc: nujw<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [espruino/BangleApps] New app : GPS Speed Alt (#651)
Just a quick one though - what is the Theme set for? (theme: jekyll-theme-slate in _config.yml)
It seems that since the main site is styled with its own CSS, we probably don't want this? Or am I missing something?
—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.
[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/espruino/BangleApps/pull/651#issuecomment-769667096",
"url": "https://github.com/espruino/BangleApps/pull/651#issuecomment-769667096",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]

No worries - I'll take it out now and add it to 'gitignore' so it doesn't happen to anyone in the future. Everything else is spot on
I think it might be something that Git tries to put into new projects by default now.

No worries - I'll take it out now and add it to 'gitignore' so it doesn't happen to anyone in the future. Everything else is spot on
I think it might be something that Git tries to put into new projects by default now.


Reminders feature v1.3

Coverage decreased (-0.9%) to 88.192% when pulling 49cdd3a356acbdb5337949b98107adbb5885a3b1 on justinpoh:Reminders-Feature into d3b9578bb84a7ff374158cc912e6777e81aa034f on CS2103AUG2017-W14-B1:master.

Coverage increased (+0.4%) to 89.866% when pulling 081e1e11d22ec0b18a7dc12bfc958a7fb3dc065b on justinpoh:Reminders-Feature into dc3d8e503f0cc6a452e49514c9247ffaf94973ff on CS2103AUG2017-W14-B1:master.


Add JVKE by golden hour original song

Song Name
JVKE
Artist Name
golden hour original song
Source
Youtube
Youtube Link
iYrWwdMxwUzZrlAQ
Direct File Link
No response
Song ID
1278923
Start Offset [ms]
0
Extra
Created from Auto Nong.
Created for level: 103709056

reject
the link is invalid and you swapped artist and song name

Accept
Em dom., 7 de jul. de 2024, 06:11, auto-nong[bot] @.***>
escreveu:

Closed #956 https://github.com/FlafyDev/auto-nong-indexes/issues/956 as
not planned.
—
Reply to this email directly, view it on GitHub
https://github.com/FlafyDev/auto-nong-indexes/issues/956#event-13413660582,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BJUUOIXULWCBZH3NTR6CWBLZLEA4JAVCNFSM6AAAAABKKVBWLGVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJTGQYTGNRWGA2TQMQ
.
You are receiving this because you authored the thread.Message ID:
@.***>


docs(resources): adding nextjs template link

Related Ticket(s)
No related issue
Description
This adds the new resource link for the NextJS template
Changelog
Changed

Resources page includes link to the NextJS Template

NextJS template url added to resources:
https://ibmdotcom-library.s3.us-south.cloud-object-storage.appdomain.cloud/deploy-previews/478/resources


INS-316: create SM object without reason

there is no need in reason, SM object shares data, goes further into
sending VStateRequest, constructor or VStateReport just fill in data
immediately before request is sent

incorrect task mark


Interface issue on Android 15

Hey. First time ever posting issue on GitHub.
I have experienced a bug in the interface after updating to Android 15 on Pixel 7. The app clashes with the status bar. I have attached a screenshot.

Hi, thanks for the bug report,
I experienced the same thing, I try to fix that as soon as possible.

Hi, thanks for the bug report, I experienced the same thing, I try to fix that as soon as possible.

Good to know. Thanks for Your hard work there.
Have a nice day.

Please test it out at https://github.com/cyb3rko/flashdim/releases/tag/v2.3.5

I've freshly reinstalled the app. Everything seems to be fine for now. If I encounter any new bugs I'll update this post.


Danish currency

Danish currency is not divided by a . on the thousands and the symbol is on the right not the left.

Thanks.