Skipping link: none of the wheel's tags (cp37-cp37m-manylinux2014_x86_64, cp37-cp37m-manylinux_2_17_x86_64) are compatible (run pip debug --verbose to show compatible tags): https://files.pythonhosted.org/packages/81/9b/c1f7d49c78ece63412c7f54fa0b89e5a81702e28cd46ea787f9bbd49b489/mujoco-2.2.0-cp37-cp37m-manylinux_2_17_x86_64.manylinux2014_x86_64.whl#sha256=7b8d28f35cc4efdb284feb8d145cc2245fb08c9c68c4682464249933e015e9ad (from https://pypi.org/simple/mujoco/) (requires-python:>=3.7)
Skipping link: none of the wheel's tags (cp37-cp37m-win_amd64) are compatible (run pip debug --verbose to show compatible tags): https://files.pythonhosted.org/packages/d2/64/abc09049e6e55f2d7cffa05b765f80a0d1bd6b6c5d027df133983eed8baf/mujoco-2.2.0-cp37-cp37m-win_amd64.whl#sha256=969ca82382686707166451362f96f467da5602e44af3542fdd0ed4babb92a9f1 (from https://pypi.org/simple/mujoco/) (requires-python:>=3.7)
Skipping link: none of the wheel's tags (cp38-cp38-macosx_10_12_x86_64) are compatible (run pip debug --verbose to show compatible tags): https://files.pythonhosted.org/packages/88/21/c571626ffa081dfde57e3f9e0d39fad1af7c749bef6ca04bdf381c28def3/mujoco-2.2.0-cp38-cp38-macosx_10_12_x86_64.whl#sha256=adb2e3dfef47648e3daf95cb40433653ef80eb97f22527906c13b47be2dd6c06 (from https://pypi.org/simple/mujoco/) (requires-python:>=3.7)
Skipping link: none of the wheel's tags (cp38-cp38-macosx_11_0_arm64) are compatible (run pip debug --verbose to show compatible tags): https://files.pythonhosted.org/packages/de/63/4db2838ae6d12a43165c3c57e5014984ffd10c122e39e800344398d3e0f1/mujoco-2.2.0-cp38-cp38-macosx_11_0_arm64.whl#sha256=0d76ab6a13fd66d98f80a41e7b29f8410eac13ec1f9b1badc927270876afc266 (from https://pypi.org/simple/mujoco/) (requires-python:>=3.7)
Skipping link: none of the wheel's tags (cp38-cp38-manylinux2014_aarch64, cp38-cp38-manylinux_2_17_aarch64) are compatible (run pip debug --verbose to show compatible tags): https://files.pythonhosted.org/packages/76/de/b8f6a98db837cfd52da58f88cc83820c59898deaa382b444d17d243f43d3/mujoco-2.2.0-cp38-cp38-manylinux_2_17_aarch64.manylinux2014_aarch64.whl#sha256=f47d94afcd0081bd547a2e858af98e5efe31c647f824fc93a5edde656e078d55 (from https://pypi.org/simple/mujoco/) (requires-python:>=3.7)
Skipping link: none of the wheel's tags (cp38-cp38-manylinux2014_x86_64, cp38-cp38-manylinux_2_17_x86_64) are compatible (run pip debug --verbose to show compatible tags): https://files.pythonhosted.org/packages/f7/12/07f757612f66141ded841130a97dd6c49b6b6879ebac7db6489b9c65ae5c/mujoco-2.2.0-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl#sha256=7da2485571c8e2c1a4b08b0a298ea7e2a68e4d994fd16f7842da0b7202790d03 (from https://pypi.org/simple/mujoco/) (requires-python:>=3.7)
Skipping link: none of the wheel's tags (cp38-cp38-win_amd64) are compatible (run pip debug --verbose to show compatible tags): https://files.pythonhosted.org/packages/1e/18/59a9a4c3996f48ace1d3c1aabb92440fe735ab01e1c47608749bba9abe8a/mujoco-2.2.0-cp38-cp38-win_amd64.whl#sha256=8698ba1e48c17b506c138408fb66a3b27e3930a2f2fad6eae1f2123500970013 (from https://pypi.org/simple/mujoco/) (requires-python:>=3.7)
Skipping link: none of the wheel's tags (cp39-cp39-macosx_10_12_x86_64) are compatible (run pip debug --verbose to show compatible tags): https://files.pythonhosted.org/packages/08/14/ff0aa984236ccf8b8ff3752a7967060296eb96b6e54e96f840f70e24e136/mujoco-2.2.0-cp39-cp39-macosx_10_12_x86_64.whl#sha256=7f3855256e880a7e5517c38d7aabc4b1dd6548723b1ba9ce0dfb0155cf667698 (from https://pypi.org/simple/mujoco/) (requires-python:>=3.7)
Skipping link: none of the wheel's tags (cp39-cp39-macosx_11_0_arm64) are compatible (run pip debug --verbose to show compatible tags): https://files.pythonhosted.org/packages/71/2e/0179822671e6ffd0cfedf391eb5892aaa2484c7fc15516f92329debfbc27/mujoco-2.2.0-cp39-cp39-macosx_11_0_arm64.whl#sha256=3fdcf6b9092f0f74042c61fe0231bfa03f4fa9a044c216b8daab8bf691ac44e8 (from https://pypi.org/simple/mujoco/) (requires-python:>=3.7)
Skipping link: none of the wheel's tags (cp39-cp39-manylinux2014_aarch64, cp39-cp39-manylinux_2_17_aarch64) are compatible (run pip debug --verbose to show compatible tags): https://files.pythonhosted.org/packages/25/e8/bc59bea458ca1c5e836cc9328ea4601afc99dcea3d0e7f814ea79c4ba86c/mujoco-2.2.0-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl#sha256=ec1cfc369ebf574655731a2823ba05b46c268595eebdd960698f3e1dd965d893 (from https://pypi.org/simple/mujoco/) (requires-python:>=3.7)
Skipping link: none of the wheel's tags (cp39-cp39-manylinux2014_x86_64, cp39-cp39-manylinux_2_17_x86_64) are compatible (run pip debug --verbose to show compatible tags): https://files.pythonhosted.org/packages/0c/24/efa05ae99eb293d2071181af9842189a3834d43671a7b4c72777004c372b/mujoco-2.2.0-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl#sha256=4c2e3505614c92debfdf4fa182473012cc634915e995ed13bfbf3724e86d9983 (from https://pypi.org/simple/mujoco/) (requires-python:>=3.7)
Skipping link: none of the wheel's tags (cp39-cp39-win_amd64) are compatible (run pip debug --verbose to show compatible tags): https://files.pythonhosted.org/packages/ae/a1/3a85fc4325bd662ce2fdcf880cd901dfb8d71db6c6eaabf21f80437e2705/mujoco-2.2.0-cp39-cp39-win_amd64.whl#sha256=6fad79862c9d77bd8db7353e9184790dd5b78d2a100ff0583350ec03c65aa78b (from https://pypi.org/simple/mujoco/) (requires-python:>=3.7)
Found link https://files.pythonhosted.org/packages/ad/52/3af0a5c1669eaf3bb81f3aeb04dfddceff9938c54f52033243428cc81e0d/mujoco-2.2.0.tar.gz#sha256=1bb370365a10f3e76eee8a438c8eafcd0d2721e05c1c9bf602cded8223f819cf (from https://pypi.org/simple/mujoco/) (requires-python:>=3.7), version: 2.2.0
Skipping link: not a file: https://pypi.org/simple/mujoco/
Given no hashes to check 6 links for project 'mujoco': discarding no candidates
Collecting mujoco
Created temporary directory: /tmp/pbs.6371704.pbsserver/pip-unpack-c2xk6m4f
Looking up "https://files.pythonhosted.org/packages/ad/52/3af0a5c1669eaf3bb81f3aeb04dfddceff9938c54f52033243428cc81e0d/mujoco-2.2.0.tar.gz" in the cache
Current age based on date: 515983
Ignoring unknown cache-control directive: immutable
Freshness lifetime from max-age: 365000000
The response is "fresh", returning cached response
365000000 > 515983
Using cached mujoco-2.2.0.tar.gz (138 kB)
Added mujoco from https://files.pythonhosted.org/packages/ad/52/3af0a5c1669eaf3bb81f3aeb04dfddceff9938c54f52033243428cc81e0d/mujoco-2.2.0.tar.gz#sha256=1bb370365a10f3e76eee8a438c8eafcd0d2721e05c1c9bf602cded8223f819cf to build tracker '/tmp/pbs.6371704.pbsserver/pip-build-tracker-cjeegs9e'
Running setup.py (path:/tmp/pbs.6371704.pbsserver/pip-install-y9bq5kdf/mujoco_4d5013efb38040138a506bb606318bb4/setup.py) egg_info for package mujoco
Created temporary directory: /tmp/pbs.6371704.pbsserver/pip-pip-egg-info-eoohdrm0
Running command python setup.py egg_info
running egg_info
creating /tmp/pbs.6371704.pbsserver/pip-pip-egg-info-eoohdrm0/mujoco.egg-info
writing /tmp/pbs.6371704.pbsserver/pip-pip-egg-info-eoohdrm0/mujoco.egg-info/PKG-INFO
writing dependency_links to /tmp/pbs.6371704.pbsserver/pip-pip-egg-info-eoohdrm0/mujoco.egg-info/dependency_links.txt
writing requirements to /tmp/pbs.6371704.pbsserver/pip-pip-egg-info-eoohdrm0/mujoco.egg-info/requires.txt
writing top-level names to /tmp/pbs.6371704.pbsserver/pip-pip-egg-info-eoohdrm0/mujoco.egg-info/top_level.txt
writing manifest file '/tmp/pbs.6371704.pbsserver/pip-pip-egg-info-eoohdrm0/mujoco.egg-info/SOURCES.txt'
/usr/local/python/3.7.7/lib/python3.7/site-packages/setuptools_scm/integration.py:39: RuntimeWarning:
ERROR: setuptools==41.2.0 is used in combination with setuptools_scm>=6.x
Your build configuration is incomplete and previously worked by accident!
This happens as setuptools is unable to replace itself when a activated build dependency
requires a more recent setuptools version
(it does not respect "setuptools>X" in setup_requires).
setuptools>=31 is required for setup.cfg metadata support
setuptools>=42 is required for pyproject.toml configuration support
Suggested workarounds if applicable:

preinstalling build dependencies like setuptools_scm before running setup.py
installing setuptools_scm using the system package manager to ensure consistency
migrating from the deprecated setup_requires mechanism to pep517/518
and using a pyproject.toml to declare build dependencies
which are reliably pre-installed before running the build tools

"""
listing git files failed - pretending there aren't any
reading manifest file '/tmp/pbs.6371704.pbsserver/pip-pip-egg-info-eoohdrm0/mujoco.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file '/tmp/pbs.6371704.pbsserver/pip-pip-egg-info-eoohdrm0/mujoco.egg-info/SOURCES.txt'
Preparing metadata (setup.py) ... done
Source in /tmp/pbs.6371704.pbsserver/pip-install-y9bq5kdf/mujoco_4d5013efb38040138a506bb606318bb4 has version 2.2.0, which satisfies requirement mujoco from https://files.pythonhosted.org/packages/ad/52/3af0a5c1669eaf3bb81f3aeb04dfddceff9938c54f52033243428cc81e0d/mujoco-2.2.0.tar.gz#sha256=1bb370365a10f3e76eee8a438c8eafcd0d2721e05c1c9bf602cded8223f819cf
Removed mujoco from https://files.pythonhosted.org/packages/ad/52/3af0a5c1669eaf3bb81f3aeb04dfddceff9938c54f52033243428cc81e0d/mujoco-2.2.0.tar.gz#sha256=1bb370365a10f3e76eee8a438c8eafcd0d2721e05c1c9bf602cded8223f819cf from build tracker '/tmp/pbs.6371704.pbsserver/pip-build-tracker-cjeegs9e'
Requirement already satisfied: absl-py in ./.local/lib/python3.7/site-packages (from mujoco) (0.15.0)
Requirement already satisfied: glfw in ./.local/lib/python3.7/site-packages (from mujoco) (2.5.3)
Requirement already satisfied: numpy in ./.local/lib/python3.7/site-packages (from mujoco) (1.19.5)
Requirement already satisfied: pyopengl in ./.local/lib/python3.7/site-packages (from mujoco) (3.1.6)
Requirement already satisfied: six in /usr/local/python/3.7.7/lib/python3.7/site-packages (from absl-py->mujoco) (1.15.0)
Created temporary directory: /tmp/pbs.6371704.pbsserver/pip-unpack-f19p_t_7
Building wheels for collected packages: mujoco
Created temporary directory: /tmp/pbs.6371704.pbsserver/pip-wheel-x7f7mjve
Building wheel for mujoco (setup.py) ...   Destination directory: /tmp/pbs.6371704.pbsserver/pip-wheel-x7f7mjve
Running command python setup.py bdist_wheel
running bdist_wheel
running build
running build_py
creating build
creating build/lib.linux-x86_64-3.7
creating build/lib.linux-x86_64-3.7/mujoco
copying mujoco/render_test.py -> build/lib.linux-x86_64-3.7/mujoco
copying mujoco/rollout.py -> build/lib.linux-x86_64-3.7/mujoco
copying mujoco/rollout_test.py -> build/lib.linux-x86_64-3.7/mujoco
copying mujoco/bindings_test.py -> build/lib.linux-x86_64-3.7/mujoco
copying mujoco/init.py -> build/lib.linux-x86_64-3.7/mujoco
creating build/lib.linux-x86_64-3.7/mujoco/glfw
copying mujoco/glfw/init.py -> build/lib.linux-x86_64-3.7/mujoco/glfw
creating build/lib.linux-x86_64-3.7/mujoco/osmesa
copying mujoco/osmesa/init.py -> build/lib.linux-x86_64-3.7/mujoco/osmesa
creating build/lib.linux-x86_64-3.7/mujoco/egl
copying mujoco/egl/egl_ext.py -> build/lib.linux-x86_64-3.7/mujoco/egl
copying mujoco/egl/init.py -> build/lib.linux-x86_64-3.7/mujoco/egl
running build_ext
Configuring CMake with the following arguments:
-DPython3_ROOT_DIR:PATH=/usr/local/python/3.7.7
-DPython3_EXECUTABLE:STRING=/usr/local/python/3.7.7/bin/python3.7
-DCMAKE_MODULE_PATH:PATH=/tmp/pbs.6371704.pbsserver/pip-install-y9bq5kdf/mujoco_4d5013efb38040138a506bb606318bb4/cmake
-DCMAKE_BUILD_TYPE:STRING=Release
-DCMAKE_LIBRARY_OUTPUT_DIRECTORY:PATH=build/temp.linux-x86_64-3.7
-DCMAKE_INTERPROCEDURAL_OPTIMIZATION=:BOOLON
-DCMAKE_Fortran_COMPILER:STRING=
-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON
-DBUILD_TESTING:BOOL=OFF
-DMUJOCO_LIBRARY_DIR:PATH=/project/RDS-FEI-ImitationLearn-RW/mujocosource/mujoco-2.2.0/lib
-DMUJOCO_INCLUDE_DIR:PATH=/project/RDS-FEI-ImitationLearn-RW/mujocosource/mujoco-2.2.0/include
-DPython3_LIBRARY=/usr/local/python/3.7.7/lib/python3.7
-DPython3_INCLUDE_DIR=/usr/local/python/3.7.7/include/python3.7m
-- The C compiler identification is Clang 14.0.0
-- The CXX compiler identification is Clang 14.0.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/local/llvm/14.0.0/bin/clang - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/local/llvm/14.0.0/bin/clang++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Performing Test SUPPORTS_LLD
-- Performing Test SUPPORTS_LLD - Failed
-- Performing Test SUPPORTS_GOLD
-- Performing Test SUPPORTS_GOLD - Failed
-- Performing Test SUPPORTS_GC_SECTIONS
-- Performing Test SUPPORTS_GC_SECTIONS - Success
-- Found Python3: /usr/local/python/3.7.7/bin/python3.7 (found version "3.7.7") found components: Interpreter Development Development.Module Development.Embed
MuJoCo is at /project/RDS-FEI-ImitationLearn-RW/mujocosource/mujoco-2.2.0/lib/libmujoco.so
MuJoCo headers are at /project/RDS-FEI-ImitationLearn-RW/mujocosource/mujoco-2.2.0/include
-- mujoco::FindOrFetch: checking for targets in package absl
-- mujoco::FindOrFetch: checking for targets in package absl - target absl::core_headers not defined.
-- mujoco::FindOrFetch: Using FetchContent to retrieve abseil-cpp
CMake Warning at /tmp/pbs.6371704.pbsserver/pip-install-y9bq5kdf/mujoco_4d5013efb38040138a506bb606318bb4/build/temp.linux-x86_64-3.7/_deps/abseil-cpp-src/CMakeLists.txt:70 (message):
A future Abseil release will default ABSL_PROPAGATE_CXX_STD to ON for CMake
3.8 and up.  We recommend enabling this option to ensure your project still
builds correctly.
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- mujoco::FindOrFetch: Using FetchContent to retrieve abseil-cpp - Done
-- mujoco::FindOrFetch: checking for targets in package Eigen3
-- mujoco::FindOrFetch: checking for targets in package Eigen3 - target Eigen3::Eigen not defined.
-- mujoco::FindOrFetch: Using FetchContent to retrieve eigen

Are you able to access the eigen git repository from the server? i.e:
git clone -n https://gitlab.com/libeigen/eigen
cd eigen
git checkout 3147391d946bb4b6c68edd901f2add6ac1f31f8c

@zhihaocheng any luck?

Thanks @nimrod-gileadi. Thank you @saran-t. I have tried to git clone eigen and the server is able to access it. A difference is that the code working is as follows. However, even if I clone eigen, the same problem occurs as in my last post.
git clone -n https://gitlab.com/libeigen/eigen.git

Is this issue still affecting you?

Is this issue still affecting you?

Thanks @saran-t and sorry for the late reply. Actually, I cannot solve this problem until now. I can only run experiments on some small workstations that I have the root privilege rather than the HPC of the university, which slows down my research. Thanks again for you contact, and I will close this issue.

@zhihaocheng the only suggestion I have is to clone the Eigen repo manually and point CMake to it using the -DFETCHCONTENT_SOURCE_DIR_EIGEN3:PATH=/path/to/your/eigen" flag.

Hi @saran-t , thanks for your advice. I will try it. In the previous discussion, you said that the problem is due to running on CentOS 6. Would it be possible that I build the mujoco on a CentOS 6 machine that I have full control from source and then migrate the compiled files to the HPC of university?

Yes that should work.

Thanks @saran-t , I'm one step closer to solving the problem. Today, I tried to install the Python Mujoco by building from source. I find that the previous problem is resulted from the URL of eigen. If I replace "https://gitlab.com/libeigen/eigen" with "https://gitlab.com/libeigen/eigen.git" in mujoco-2.2.1/python/mujoco/CMakeLists.txt, the building wheel process with not be stuck. However, a further problem appeared as follows. I have searched in Google, but failed to find what is wrong with /usr/bin/ld. Could you please help me?
Currently Loaded Modulefiles:

zlib/1.2.8       3) python/3.7.7     5) gmp/5.1.3        7) mpc/1.0.3        9) llvm/14.0.0
sqlite/3080802   4) cmake/3.21.1     6) mpfr/3.1.4       8) gcc/8.4.0       10) clang/6.0.1

I also explicitly assign the complier.
export CC=/usr/local/llvm/14.0.0/bin/clang
export CXX=/usr/local/llvm/14.0.0/bin/clang++
pip wheel dist/mujoco-2.2.1.tar.gz, and then
[ 58%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_strings.dir/str_cat.cc.o
[ 58%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_strings.dir/numbers.cc.o
[ 58%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_strings.dir/str_replace.cc.o
[ 58%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_strings.dir/str_split.cc.o
[ 58%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_strings.dir/string_view.cc.o
[ 58%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_strings.dir/substitute.cc.o
[ 58%] Linking CXX static library libabsl_city.a
[ 58%] Built target absl_city
[ 58%] Linking CXX static library libabsl_malloc_internal.a
[ 58%] Built target absl_malloc_internal
[ 58%] Building CXX object _deps/abseil-cpp-build/absl/synchronization/CMakeFiles/absl_graphcycles_internal.dir/internal/graphcycles.cc.o
[ 58%] Linking CXX static library libabsl_demangle_internal.a
[ 58%] Built target absl_demangle_internal
[ 58%] Linking CXX static library libabsl_graphcycles_internal.a
[ 58%] Built target absl_graphcycles_internal
[ 58%] Linking CXX static library libabsl_strings.a
[ 58%] Built target absl_strings
[ 58%] Building CXX object _deps/abseil-cpp-build/absl/debugging/CMakeFiles/absl_symbolize.dir/symbolize.cc.o
[ 66%] Building CXX object _deps/abseil-cpp-build/absl/hash/CMakeFiles/absl_hash.dir/internal/hash.cc.o
[ 66%] Building CXX object _deps/abseil-cpp-build/absl/time/CMakeFiles/absl_time.dir/civil_time.cc.o
[ 66%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_cord_internal.dir/internal/cord_internal.cc.o
[ 66%] Building CXX object _deps/abseil-cpp-build/absl/time/CMakeFiles/absl_time.dir/clock.cc.o
[ 66%] Building CXX object _deps/abseil-cpp-build/absl/time/CMakeFiles/absl_time.dir/duration.cc.o
[ 66%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_cord_internal.dir/internal/cord_rep_btree.cc.o
[ 66%] Building CXX object _deps/abseil-cpp-build/absl/time/CMakeFiles/absl_time.dir/time.cc.o
[ 66%] Building CXX object _deps/abseil-cpp-build/absl/time/CMakeFiles/absl_time.dir/format.cc.o
[ 66%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_cord_internal.dir/internal/cord_rep_btree_navigator.cc.o
[ 66%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_cord_internal.dir/internal/cord_rep_btree_reader.cc.o
[ 75%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_cord_internal.dir/internal/cord_rep_concat.cc.o
[ 75%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_cord_internal.dir/internal/cord_rep_crc.cc.o
[ 75%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_cord_internal.dir/internal/cord_rep_ring.cc.o
[ 75%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_cord_internal.dir/internal/cord_rep_consume.cc.o
[ 75%] Linking CXX shared module _constants.cpython-37m-x86_64-linux-gnu.so
/usr/bin/ld: unrecognized option '-plugin'
/usr/bin/ld: use the --help option for usage information
clang-14: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[2]: *** [_constants.cpython-37m-x86_64-linux-gnu.so] Error 1
gmake[1]: *** [CMakeFiles/_constants.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs....
[ 75%] Linking CXX static library libabsl_symbolize.a
[ 75%] Built target absl_symbolize
[ 75%] Linking CXX static library libabsl_time.a
[ 75%] Built target absl_time
[ 75%] Linking CXX static library libabsl_hash.a
[ 75%] Built target absl_hash
[ 75%] Linking CXX static library libabsl_cord_internal.a
[ 75%] Built target absl_cord_internal
[ 75%] Linking CXX shared module _errors.cpython-37m-x86_64-linux-gnu.so
/usr/bin/ld: unrecognized option '-plugin'
/usr/bin/ld: use the --help option for usage information
clang-14: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[2]: *** [_errors.cpython-37m-x86_64-linux-gnu.so] Error 1
gmake[1]: *** [CMakeFiles/_errors.dir/all] Error 2
[ 75%] Linking CXX shared module _enums.cpython-37m-x86_64-linux-gnu.so
/usr/bin/ld: unrecognized option '-plugin'
/usr/bin/ld: use the --help option for usage information
clang-14: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[2]: *** [_enums.cpython-37m-x86_64-linux-gnu.so] Error 1
gmake[1]: *** [CMakeFiles/_enums.dir/all] Error 2
gmake: *** [all] Error 2
Traceback (most recent call last):
File "", line 36, in
File "", line 34, in
File "/tmp/pbs.6440532.pbsserver/pip-req-build-bn1addkc/setup.py", line 321, in
'include/mujoco/*.h',
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/init.py", line 87, in setup
return distutils.core.setup(**attrs)
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/_distutils/core.py", line 185, in setup
return run_commands(dist)
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/_distutils/core.py", line 201, in run_commands
dist.run_commands()
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/_distutils/dist.py", line 973, in run_commands
self.run_command(cmd)
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/dist.py", line 1217, in run_command
super().run_command(command)
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/_distutils/dist.py", line 992, in run_command
cmd_obj.run()
File "/usr/local/python/3.7.7/lib/python3.7/site-packages/wheel/bdist_wheel.py", line 223, in run
self.run_command('build')
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/_distutils/cmd.py", line 319, in run_command
self.distribution.run_command(command)
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/dist.py", line 1217, in run_command
super().run_command(command)
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/_distutils/dist.py", line 992, in run_command
cmd_obj.run()
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/command/build.py", line 24, in run
super().run()
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/_distutils/command/build.py", line 132, in run
self.run_command(cmd_name)
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/_distutils/cmd.py", line 319, in run_command
self.distribution.run_command(command)
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/dist.py", line 1217, in run_command
super().run_command(command)
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/_distutils/dist.py", line 992, in run_command
cmd_obj.run()
File "/tmp/pbs.6440532.pbsserver/pip-req-build-bn1addkc/setup.py", line 144, in run
self._configure_cmake()
File "/tmp/pbs.6440532.pbsserver/pip-req-build-bn1addkc/setup.py", line 244, in _configure_cmake
cwd=self.build_temp)
File "/usr/local/python/3.7.7/lib/python3.7/subprocess.py", line 363, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['cmake', '--build', '.', '-j24', '--config', 'Release']' returned non-zero exit status 2.
error: subprocess-exited-with-error
× python setup.py bdist_wheel did not run successfully.
│ exit code: 1
╰─> See above for output.
note: This error originates from a subprocess, and is likely not a problem with pip.
full command: /usr/local/python/3.7.7/bin/python3.7 -u -c '
exec(compile('"'"''"'"''"'"'
This is  -- a caller that pip uses to run setup.py

- It imports setuptools before invoking setup.py, to enable projects that directly
import from distutils.core to work with newer packaging standards.
- It provides a clear error message when setuptools is not installed.
- It sets sys.argv[0] to the underlying setup.py, when invoking setup.py so
setuptools doesn'"'"'t think the script is -c. This avoids the following warning:
manifest_maker: standard file '"'"'-c'"'"' not found".
- It generates a shim setup.py, for handling setup.cfg-only projects.
import os, sys, tokenize
try:
import setuptools
except ImportError as error:
print(
"ERROR: Can not execute setup.py since setuptools is not available in "
"the build environment.",
file=sys.stderr,
)
sys.exit(1)
file = %r
sys.argv[0] = file
if os.path.exists(file):
filename = file
with tokenize.open(file) as f:
setup_py_code = f.read()
else:
filename = ""
setup_py_code = "from setuptools import setup; setup()"
exec(compile(setup_py_code, filename, "exec"))
'"'"''"'"''"'"' % ('"'"'/tmp/pbs.6440532.pbsserver/pip-req-build-bn1addkc/setup.py'"'"',), "", "exec"))' bdist_wheel -d /tmp/pbs.6440532.pbsserver/pip-wheel-d1r6m3tv
cwd: /tmp/pbs.6440532.pbsserver/pip-req-build-bn1addkc/
error
ERROR: Failed building wheel for mujoco
Running setup.py clean for mujoco
Running command python setup.py clean
running clean
removing 'build/temp.linux-x86_64-cpython-37' (and everything under it)
removing 'build/lib.linux-x86_64-cpython-37' (and everything under it)
'build/bdist.linux-x86_64' does not exist -- can't clean it
'build/scripts-3.7' does not exist -- can't clean it
removing 'build'
Failed to build mujoco
ERROR: Failed to build one or more wheels
Exception information:
Traceback (most recent call last):
File "/home/zhc/.local/lib/python3.7/site-packages/pip/_internal/cli/base_command.py", line 167, in exc_logging_wrapper
status = run_func(*args)
File "/home/zhc/.local/lib/python3.7/site-packages/pip/_internal/cli/req_command.py", line 247, in wrapper
return func(self, options, args)
File "/home/zhc/.local/lib/python3.7/site-packages/pip/_internal/commands/wheel.py", line 176, in run
raise CommandError("Failed to build one or more wheels")
pip._internal.exceptions.CommandError: Failed to build one or more wheels
Remote version of pip: 22.2.2
Local version of pip:  22.2.2
Was pip installed by pip? True
Removed build tracker: '/tmp/pbs.6440532.pbsserver/pip-build-tracker-ey5d2xv0'

Thanks @saran-t , I'm one step closer to solving the problem. Today, I tried to install the Python Mujoco by building from source. I find that the previous problem is resulted from the URL of eigen. If I replace "https://gitlab.com/libeigen/eigen" with "https://gitlab.com/libeigen/eigen.git" in mujoco-2.2.1/python/mujoco/CMakeLists.txt, the building wheel process with not be stuck. However, a further problem appeared as follows. I have searched in Google, but failed to find what is wrong with /usr/bin/ld. Could you please help me?
Currently Loaded Modulefiles:

zlib/1.2.8       3) python/3.7.7     5) gmp/5.1.3        7) mpc/1.0.3        9) llvm/14.0.0
sqlite/3080802   4) cmake/3.21.1     6) mpfr/3.1.4       8) gcc/8.4.0       10) clang/6.0.1

I also explicitly assign the complier.
export CC=/usr/local/llvm/14.0.0/bin/clang
export CXX=/usr/local/llvm/14.0.0/bin/clang++
pip wheel dist/mujoco-2.2.1.tar.gz, and then
[ 58%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_strings.dir/str_cat.cc.o
[ 58%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_strings.dir/numbers.cc.o
[ 58%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_strings.dir/str_replace.cc.o
[ 58%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_strings.dir/str_split.cc.o
[ 58%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_strings.dir/string_view.cc.o
[ 58%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_strings.dir/substitute.cc.o
[ 58%] Linking CXX static library libabsl_city.a
[ 58%] Built target absl_city
[ 58%] Linking CXX static library libabsl_malloc_internal.a
[ 58%] Built target absl_malloc_internal
[ 58%] Building CXX object _deps/abseil-cpp-build/absl/synchronization/CMakeFiles/absl_graphcycles_internal.dir/internal/graphcycles.cc.o
[ 58%] Linking CXX static library libabsl_demangle_internal.a
[ 58%] Built target absl_demangle_internal
[ 58%] Linking CXX static library libabsl_graphcycles_internal.a
[ 58%] Built target absl_graphcycles_internal
[ 58%] Linking CXX static library libabsl_strings.a
[ 58%] Built target absl_strings
[ 58%] Building CXX object _deps/abseil-cpp-build/absl/debugging/CMakeFiles/absl_symbolize.dir/symbolize.cc.o
[ 66%] Building CXX object _deps/abseil-cpp-build/absl/hash/CMakeFiles/absl_hash.dir/internal/hash.cc.o
[ 66%] Building CXX object _deps/abseil-cpp-build/absl/time/CMakeFiles/absl_time.dir/civil_time.cc.o
[ 66%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_cord_internal.dir/internal/cord_internal.cc.o
[ 66%] Building CXX object _deps/abseil-cpp-build/absl/time/CMakeFiles/absl_time.dir/clock.cc.o
[ 66%] Building CXX object _deps/abseil-cpp-build/absl/time/CMakeFiles/absl_time.dir/duration.cc.o
[ 66%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_cord_internal.dir/internal/cord_rep_btree.cc.o
[ 66%] Building CXX object _deps/abseil-cpp-build/absl/time/CMakeFiles/absl_time.dir/time.cc.o
[ 66%] Building CXX object _deps/abseil-cpp-build/absl/time/CMakeFiles/absl_time.dir/format.cc.o
[ 66%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_cord_internal.dir/internal/cord_rep_btree_navigator.cc.o
[ 66%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_cord_internal.dir/internal/cord_rep_btree_reader.cc.o
[ 75%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_cord_internal.dir/internal/cord_rep_concat.cc.o
[ 75%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_cord_internal.dir/internal/cord_rep_crc.cc.o
[ 75%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_cord_internal.dir/internal/cord_rep_ring.cc.o
[ 75%] Building CXX object _deps/abseil-cpp-build/absl/strings/CMakeFiles/absl_cord_internal.dir/internal/cord_rep_consume.cc.o
[ 75%] Linking CXX shared module _constants.cpython-37m-x86_64-linux-gnu.so
/usr/bin/ld: unrecognized option '-plugin'
/usr/bin/ld: use the --help option for usage information
clang-14: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[2]: *** [_constants.cpython-37m-x86_64-linux-gnu.so] Error 1
gmake[1]: *** [CMakeFiles/_constants.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs....
[ 75%] Linking CXX static library libabsl_symbolize.a
[ 75%] Built target absl_symbolize
[ 75%] Linking CXX static library libabsl_time.a
[ 75%] Built target absl_time
[ 75%] Linking CXX static library libabsl_hash.a
[ 75%] Built target absl_hash
[ 75%] Linking CXX static library libabsl_cord_internal.a
[ 75%] Built target absl_cord_internal
[ 75%] Linking CXX shared module _errors.cpython-37m-x86_64-linux-gnu.so
/usr/bin/ld: unrecognized option '-plugin'
/usr/bin/ld: use the --help option for usage information
clang-14: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[2]: *** [_errors.cpython-37m-x86_64-linux-gnu.so] Error 1
gmake[1]: *** [CMakeFiles/_errors.dir/all] Error 2
[ 75%] Linking CXX shared module _enums.cpython-37m-x86_64-linux-gnu.so
/usr/bin/ld: unrecognized option '-plugin'
/usr/bin/ld: use the --help option for usage information
clang-14: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[2]: *** [_enums.cpython-37m-x86_64-linux-gnu.so] Error 1
gmake[1]: *** [CMakeFiles/_enums.dir/all] Error 2
gmake: *** [all] Error 2
Traceback (most recent call last):
File "", line 36, in
File "", line 34, in
File "/tmp/pbs.6440532.pbsserver/pip-req-build-bn1addkc/setup.py", line 321, in
'include/mujoco/*.h',
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/init.py", line 87, in setup
return distutils.core.setup(**attrs)
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/_distutils/core.py", line 185, in setup
return run_commands(dist)
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/_distutils/core.py", line 201, in run_commands
dist.run_commands()
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/_distutils/dist.py", line 973, in run_commands
self.run_command(cmd)
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/dist.py", line 1217, in run_command
super().run_command(command)
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/_distutils/dist.py", line 992, in run_command
cmd_obj.run()
File "/usr/local/python/3.7.7/lib/python3.7/site-packages/wheel/bdist_wheel.py", line 223, in run
self.run_command('build')
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/_distutils/cmd.py", line 319, in run_command
self.distribution.run_command(command)
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/dist.py", line 1217, in run_command
super().run_command(command)
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/_distutils/dist.py", line 992, in run_command
cmd_obj.run()
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/command/build.py", line 24, in run
super().run()
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/_distutils/command/build.py", line 132, in run
self.run_command(cmd_name)
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/_distutils/cmd.py", line 319, in run_command
self.distribution.run_command(command)
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/dist.py", line 1217, in run_command
super().run_command(command)
File "/home/zhc/.local/lib/python3.7/site-packages/setuptools/_distutils/dist.py", line 992, in run_command
cmd_obj.run()
File "/tmp/pbs.6440532.pbsserver/pip-req-build-bn1addkc/setup.py", line 144, in run
self._configure_cmake()
File "/tmp/pbs.6440532.pbsserver/pip-req-build-bn1addkc/setup.py", line 244, in _configure_cmake
cwd=self.build_temp)
File "/usr/local/python/3.7.7/lib/python3.7/subprocess.py", line 363, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['cmake', '--build', '.', '-j24', '--config', 'Release']' returned non-zero exit status 2.
error: subprocess-exited-with-error
× python setup.py bdist_wheel did not run successfully.
│ exit code: 1
╰─> See above for output.
note: This error originates from a subprocess, and is likely not a problem with pip.
full command: /usr/local/python/3.7.7/bin/python3.7 -u -c '
exec(compile('""""""
This is  -- a caller that pip uses to run setup.py
#
# - It imports setuptools before invoking setup.py, to enable projects that directly
#   import from distutils.core to work with newer packaging standards.
# - It provides a clear error message when setuptools is not installed.
# - It sets sys.argv[0] to the underlying setup.py, when invoking setup.py so
#   setuptools doesn'"'"'t think the script is -c. This avoids the following warning:
#     manifest_maker: standard file '"'"'-c'"'"' not found".
# - It generates a shim setup.py, for handling setup.cfg-only projects.
import os, sys, tokenize
try:
import setuptools
except ImportError as error:
print(
"ERROR: Can not execute setup.py since setuptools is not available in "
"the build environment.",
file=sys.stderr,
)
sys.exit(1)
file = %r
sys.argv[0] = file
if os.path.exists(file):
filename = file
with tokenize.open(file) as f:
setup_py_code = f.read()
else:
filename = ""
setup_py_code = "from setuptools import setup; setup()"
exec(compile(setup_py_code, filename, "exec"))
'"'"''"'"''"'"' % ('"'"'/tmp/pbs.6440532.pbsserver/pip-req-build-bn1addkc/setup.py'"'"',), "", "exec"))' bdist_wheel -d /tmp/pbs.6440532.pbsserver/pip-wheel-d1r6m3tv
cwd: /tmp/pbs.6440532.pbsserver/pip-req-build-bn1addkc/
error
ERROR: Failed building wheel for mujoco
Running setup.py clean for mujoco
Running command python setup.py clean
running clean
removing 'build/temp.linux-x86_64-cpython-37' (and everything under it)
removing 'build/lib.linux-x86_64-cpython-37' (and everything under it)
'build/bdist.linux-x86_64' does not exist -- can't clean it
'build/scripts-3.7' does not exist -- can't clean it
removing 'build'
Failed to build mujoco
ERROR: Failed to build one or more wheels
Exception information:
Traceback (most recent call last):
File "/home/zhc/.local/lib/python3.7/site-packages/pip/_internal/cli/base_command.py", line 167, in exc_logging_wrapper
status = run_func(*args)
File "/home/zhc/.local/lib/python3.7/site-packages/pip/_internal/cli/req_command.py", line 247, in wrapper
return func(self, options, args)
File "/home/zhc/.local/lib/python3.7/site-packages/pip/_internal/commands/wheel.py", line 176, in run
raise CommandError("Failed to build one or more wheels")
pip._internal.exceptions.CommandError: Failed to build one or more wheels
Remote version of pip: 22.2.2
Local version of pip:  22.2.2
Was pip installed by pip? True
Removed build tracker: '/tmp/pbs.6440532.pbsserver/pip-build-tracker-ey5d2xv0'

I am having issue building mujoco on apple sillicon m1
Building wheel for mujoco (pyproject.toml) ... error
error: subprocess-exited-with-error
× Building wheel for mujoco (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> [71 lines of output]
running bdist_wheel
running build
running build_py
creating build
creating build/lib.macosx-10.9-x86_64-cpython-311
creating build/lib.macosx-10.9-x86_64-cpython-311/mujoco
copying mujoco/init.py -> build/lib.macosx-10.9-x86_64-cpython-311/mujoco
copying mujoco/rollout.py -> build/lib.macosx-10.9-x86_64-cpython-311/mujoco
copying mujoco/rollout_test.py -> build/lib.macosx-10.9-x86_64-cpython-311/mujoco
copying mujoco/bindings_test.py -> build/lib.macosx-10.9-x86_64-cpython-311/mujoco
copying mujoco/render_test.py -> build/lib.macosx-10.9-x86_64-cpython-311/mujoco
creating build/lib.macosx-10.9-x86_64-cpython-311/mujoco/egl
copying mujoco/egl/init.py -> build/lib.macosx-10.9-x86_64-cpython-311/mujoco/egl
copying mujoco/egl/egl_ext.py -> build/lib.macosx-10.9-x86_64-cpython-311/mujoco/egl
creating build/lib.macosx-10.9-x86_64-cpython-311/mujoco/osmesa
copying mujoco/osmesa/init.py -> build/lib.macosx-10.9-x86_64-cpython-311/mujoco/osmesa
creating build/lib.macosx-10.9-x86_64-cpython-311/mujoco/glfw
copying mujoco/glfw/init.py -> build/lib.macosx-10.9-x86_64-cpython-311/mujoco/glfw
running build_ext
Traceback (most recent call last):
File "/tmp/mujoco/lib/python3.11/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 353, in
main()
File "/tmp/mujoco/lib/python3.11/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 335, in main
json_out['return_val'] = hook(**hook_input['kwargs'])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/tmp/mujoco/lib/python3.11/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 251, in build_wheel
return _build_backend().build_wheel(wheel_directory, config_settings,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/private/var/folders/25/3c_cvnxx415_zr7xxz5k1_zh0000gn/T/pip-build-env-bahz24fd/overlay/lib/python3.11/site-packages/setuptools/build_meta.py", line 434, in build_wheel
return self._build_with_temp_dir(
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/private/var/folders/25/3c_cvnxx415_zr7xxz5k1_zh0000gn/T/pip-build-env-bahz24fd/overlay/lib/python3.11/site-packages/setuptools/build_meta.py", line 419, in _build_with_temp_dir
self.run_setup()
File "/private/var/folders/25/3c_cvnxx415_zr7xxz5k1_zh0000gn/T/pip-build-env-bahz24fd/overlay/lib/python3.11/site-packages/setuptools/build_meta.py", line 507, in run_setup
super(_BuildMetaLegacyBackend, self).run_setup(setup_script=setup_script)
File "/private/var/folders/25/3c_cvnxx415_zr7xxz5k1_zh0000gn/T/pip-build-env-bahz24fd/overlay/lib/python3.11/site-packages/setuptools/build_meta.py", line 341, in run_setup
exec(code, locals())
File "", line 265, in
File "/private/var/folders/25/3c_cvnxx415_zr7xxz5k1_zh0000gn/T/pip-build-env-bahz24fd/overlay/lib/python3.11/site-packages/setuptools/init.py", line 103, in setup
return distutils.core.setup(**attrs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/private/var/folders/25/3c_cvnxx415_zr7xxz5k1_zh0000gn/T/pip-build-env-bahz24fd/overlay/lib/python3.11/site-packages/setuptools/_distutils/core.py", line 185, in setup
return run_commands(dist)
^^^^^^^^^^^^^^^^^^
File "/private/var/folders/25/3c_cvnxx415_zr7xxz5k1_zh0000gn/T/pip-build-env-bahz24fd/overlay/lib/python3.11/site-packages/setuptools/_distutils/core.py", line 201, in run_commands
dist.run_commands()
File "/private/var/folders/25/3c_cvnxx415_zr7xxz5k1_zh0000gn/T/pip-build-env-bahz24fd/overlay/lib/python3.11/site-packages/setuptools/_distutils/dist.py", line 969, in run_commands
self.run_command(cmd)
File "/private/var/folders/25/3c_cvnxx415_zr7xxz5k1_zh0000gn/T/pip-build-env-bahz24fd/overlay/lib/python3.11/site-packages/setuptools/dist.py", line 989, in run_command
super().run_command(command)
File "/private/var/folders/25/3c_cvnxx415_zr7xxz5k1_zh0000gn/T/pip-build-env-bahz24fd/overlay/lib/python3.11/site-packages/setuptools/_distutils/dist.py", line 988, in run_command
cmd_obj.run()
File "/private/var/folders/25/3c_cvnxx415_zr7xxz5k1_zh0000gn/T/pip-build-env-bahz24fd/overlay/lib/python3.11/site-packages/wheel/bdist_wheel.py", line 364, in run
self.run_command("build")
File "/private/var/folders/25/3c_cvnxx415_zr7xxz5k1_zh0000gn/T/pip-build-env-bahz24fd/overlay/lib/python3.11/site-packages/setuptools/_distutils/cmd.py", line 318, in run_command
self.distribution.run_command(command)
File "/private/var/folders/25/3c_cvnxx415_zr7xxz5k1_zh0000gn/T/pip-build-env-bahz24fd/overlay/lib/python3.11/site-packages/setuptools/dist.py", line 989, in run_command
super().run_command(command)
File "/private/var/folders/25/3c_cvnxx415_zr7xxz5k1_zh0000gn/T/pip-build-env-bahz24fd/overlay/lib/python3.11/site-packages/setuptools/_distutils/dist.py", line 988, in run_command
cmd_obj.run()
File "/private/var/folders/25/3c_cvnxx415_zr7xxz5k1_zh0000gn/T/pip-build-env-bahz24fd/overlay/lib/python3.11/site-packages/setuptools/_distutils/command/build.py", line 131, in run
self.run_command(cmd_name)
File "/private/var/folders/25/3c_cvnxx415_zr7xxz5k1_zh0000gn/T/pip-build-env-bahz24fd/overlay/lib/python3.11/site-packages/setuptools/_distutils/cmd.py", line 318, in run_command
self.distribution.run_command(command)
File "/private/var/folders/25/3c_cvnxx415_zr7xxz5k1_zh0000gn/T/pip-build-env-bahz24fd/overlay/lib/python3.11/site-packages/setuptools/dist.py", line 989, in run_command
super().run_command(command)
File "/private/var/folders/25/3c_cvnxx415_zr7xxz5k1_zh0000gn/T/pip-build-env-bahz24fd/overlay/lib/python3.11/site-packages/setuptools/_distutils/dist.py", line 988, in run_command
cmd_obj.run()
File "", line 143, in run
File "", line 154, in _find_mujoco
RuntimeError: MUJOCO_PATH environment variable is not set
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
ERROR: Failed building wheel for mujoco
Building wheel for pygame (pyproject.toml) ... error
error: subprocess-exited-with-error
× Building wheel for pygame (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> [13 lines of output]
src_c/_sdl2/sdl2.c:211:12: fatal error: 'longintrepr.h' file not found
#include "longintrepr.h"
^~~~~~~~~~~~~~~
1 error generated.
  ---
  For help with compilation see:
      https://www.pygame.org/wiki/MacCompile
  To contribute to pygame development see:
      https://www.pygame.org/contribute.html
  ---

  error: command '/usr/bin/clang' failed with exit code 1

I am stuck with installing mujoco on apple siliicon m1
Building wheels for collected packages: mujoco
Building wheel for mujoco (setup.py) ... error
error: subprocess-exited-with-error
× python setup.py bdist_wheel did not run successfully.
│ exit code: 1
╰─> [68 lines of output]
running bdist_wheel
running build
running build_py
creating build
creating build/lib.macosx-10.9-x86_64-cpython-311
creating build/lib.macosx-10.9-x86_64-cpython-311/mujoco
copying mujoco/viewer.py -> build/lib.macosx-10.9-x86_64-cpython-311/mujoco
copying mujoco/renderer.py -> build/lib.macosx-10.9-x86_64-cpython-311/mujoco
copying mujoco/renderer_test.py -> build/lib.macosx-10.9-x86_64-cpython-311/mujoco
copying mujoco/init.py -> build/lib.macosx-10.9-x86_64-cpython-311/mujoco
copying mujoco/rollout.py -> build/lib.macosx-10.9-x86_64-cpython-311/mujoco
copying mujoco/rollout_test.py -> build/lib.macosx-10.9-x86_64-cpython-311/mujoco
copying mujoco/bindings_test.py -> build/lib.macosx-10.9-x86_64-cpython-311/mujoco
copying mujoco/viewer_test.py -> build/lib.macosx-10.9-x86_64-cpython-311/mujoco
copying mujoco/render_test.py -> build/lib.macosx-10.9-x86_64-cpython-311/mujoco
copying mujoco/gl_context.py -> build/lib.macosx-10.9-x86_64-cpython-311/mujoco
creating build/lib.macosx-10.9-x86_64-cpython-311/mujoco/cgl
copying mujoco/cgl/cgl.py -> build/lib.macosx-10.9-x86_64-cpython-311/mujoco/cgl
copying mujoco/cgl/init.py -> build/lib.macosx-10.9-x86_64-cpython-311/mujoco/cgl
creating build/lib.macosx-10.9-x86_64-cpython-311/mujoco/egl
copying mujoco/egl/init.py -> build/lib.macosx-10.9-x86_64-cpython-311/mujoco/egl
copying mujoco/egl/egl_ext.py -> build/lib.macosx-10.9-x86_64-cpython-311/mujoco/egl
creating build/lib.macosx-10.9-x86_64-cpython-311/mujoco/osmesa
copying mujoco/osmesa/init.py -> build/lib.macosx-10.9-x86_64-cpython-311/mujoco/osmesa
creating build/lib.macosx-10.9-x86_64-cpython-311/mujoco/glfw
copying mujoco/glfw/init.py -> build/lib.macosx-10.9-x86_64-cpython-311/mujoco/glfw
running build_ext
Traceback (most recent call last):
File "", line 2, in
File "", line 34, in
File "/private/var/folders/25/3c_cvnxx415_zr7xxz5k1_zh0000gn/T/pip-install-pscr4xgl/mujoco_d4b94e5e211c43dcbadb4e0ddb330867/setup.py", line 418, in
setup(**SETUP_KWARGS)
File "/Users/raviwar/miniconda/lib/python3.11/site-packages/setuptools/init.py", line 103, in setup
return distutils.core.setup(**attrs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/raviwar/miniconda/lib/python3.11/site-packages/setuptools/_distutils/core.py", line 185, in setup
return run_commands(dist)
^^^^^^^^^^^^^^^^^^
File "/Users/raviwar/miniconda/lib/python3.11/site-packages/setuptools/_distutils/core.py", line 201, in run_commands
dist.run_commands()
File "/Users/raviwar/miniconda/lib/python3.11/site-packages/setuptools/_distutils/dist.py", line 969, in run_commands
self.run_command(cmd)
File "/Users/raviwar/miniconda/lib/python3.11/site-packages/setuptools/dist.py", line 989, in run_command
super().run_command(command)
File "/Users/raviwar/miniconda/lib/python3.11/site-packages/setuptools/_distutils/dist.py", line 988, in run_command
cmd_obj.run()
File "/Users/raviwar/miniconda/lib/python3.11/site-packages/wheel/bdist_wheel.py", line 364, in run
self.run_command("build")
File "/Users/raviwar/miniconda/lib/python3.11/site-packages/setuptools/_distutils/cmd.py", line 318, in run_command
self.distribution.run_command(command)
File "/Users/raviwar/miniconda/lib/python3.11/site-packages/setuptools/dist.py", line 989, in run_command
super().run_command(command)
File "/Users/raviwar/miniconda/lib/python3.11/site-packages/setuptools/_distutils/dist.py", line 988, in run_command
cmd_obj.run()
File "/Users/raviwar/miniconda/lib/python3.11/site-packages/setuptools/_distutils/command/build.py", line 131, in run
self.run_command(cmd_name)
File "/Users/raviwar/miniconda/lib/python3.11/site-packages/setuptools/_distutils/cmd.py", line 318, in run_command
self.distribution.run_command(command)
File "/Users/raviwar/miniconda/lib/python3.11/site-packages/setuptools/dist.py", line 989, in run_command
super().run_command(command)
File "/Users/raviwar/miniconda/lib/python3.11/site-packages/setuptools/_distutils/dist.py", line 988, in run_command
cmd_obj.run()
File "/private/var/folders/25/3c_cvnxx415_zr7xxz5k1_zh0000gn/T/pip-install-pscr4xgl/mujoco_d4b94e5e211c43dcbadb4e0ddb330867/setup.py", line 156, in run
self._mujoco_framework_path) = self._find_mujoco()
^^^^^^^^^^^^^^^^^^^
File "/private/var/folders/25/3c_cvnxx415_zr7xxz5k1_zh0000gn/T/pip-install-pscr4xgl/mujoco_d4b94e5e211c43dcbadb4e0ddb330867/setup.py", line 170, in _find_mujoco
raise RuntimeError(
RuntimeError: MUJOCO_PATH environment variable is not set
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
ERROR: Failed building wheel for mujoco
Running setup.py clean for mujoco
Failed to build mujoco

@raviwaarr Make sure to set your environment variables MUJOCO_PATH and MUJOCO_PLUGIN_PATH to point to the correct directories (the root mujoco path like /home/users/ben/.mujoco/mujoco-3.0.0 and /home/users/ben/.mujoco/mujoco-3.0.0/bin/mujoco_plugin)

best not use conda environments if possible. I switched to python venv and nothing went wrong :)


DESIGN: POC to discuss about SPAL Serialization implementation strategies and approaches

STX.Serialization.Core renamed to STX.Serialization.Providers as suggested by @cjdutoit
Overview

STX.Serialization.Providers

STX.SPAL.Core


New typography feature prevents theme's custom.typography value from appearing

Issue Summary
I have a (now-outdated) theme with a custom.typography value.  It used to show up in the admin dashboard for theme customization.  Now it doesn't.  Renaming the variable to typographyb causes it to appear, so I suspect a conflict with the new typography dropdowns.
Steps to Reproduce
Install an older theme with a custom.typography setting defined in package.json.
Observe that the custom value does not appear with the other custom values in the admin dashboard.
Ghost Version
5.101.1
Node.js Version
18
How did you install Ghost?
local install.
Database type
SQLite3
Browser & OS version
Chrome, windows 10, recent version
Relevant log / error output
No response
Code of Conduct

[X] I agree to be friendly and polite to people in this repository

Solo and Episode are impacted.

Hey @cathysarisky. Just to confirm, it only happened when you used one of the official themes, is that correct? Seeing that you mentioned Solo and Episode were impacted, I assume that was the case, but just wanted to be extra sure.

Hey @minimaluminium , I saw it first on a client's site, which is a heavily-modified version of episode.  It was installed by uploading a zip, not via the one-click deploy.

Thank you for bringing this to our attention.
Let me clarify how our current implementation works:

We've hidden font settings specifically for our official themes to accommodate the new custom fonts feature.
The system currently identifies official themes by checking the theme name. This means:

If you're using an official theme (unmodified), the font settings will be hidden
If you're using a modified version of an official theme but haven't changed the theme name, the font settings will still be hidden
To make font settings visible for your modified theme, you'll need to save it as a new theme with a different name

To make this more convenient for users who modify official themes, we're considering adding an additional check: verifying the author name in the package.json file. This way, you wouldn't need to change the theme name – you could simply update the author name in your modified version, and the font settings would become visible.
Would this alternative solution be more convenient for your workflow? We'd appreciate your feedback on whether checking the author name would be a better approach.

@minimaluminium , I saw a comment from you that has disappeared.  So I think I understand that this is the intended behavior for official themes with a typography attribute, and you're checking for theme name and maybe now author.  (Although I don't normally update those fields, it isn't hard to do so if it's documented.)  But... rather than trying to come up with some logic that removes the existing displayed typography settings from two variables, why not just update those two themes?  That way, anyone running an old version still has access to episode's "wide" and "narrow" typography settings.  I'm not sure I see the benefit of hiding the setting unless you're also patching out the use of the custom variable.  (Which, when I checked episode this morning, you hadn't.)


Non-default user extensions dir causes error in server

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.77.3
OS Version: RHEL8

Steps to Reproduce:

Start a VSCode Server build with an --extensions-dir argument pointing to a folder whose parent doesn't exist
Observe an error

Error: ENOENT: no such file or directory, mkdir '/no/no/yes'
    at Object.mkdirSync (node:fs:1336:3)
    at ...path-to-bundle/out/vs/server/node/server.main.js:188:1809

The problem is here:
https://github.com/microsoft/vscode/blob/d867c0a0f462706effbeacbefe14a33a2dd2436b/src/vs/server/node/server.main.ts#L49-L57
With default arguments, the parent folder will be created before the extensions folder, but with custom arguments, there's no guarantee that the parent folder will exist, and the recursive flag is not set in the mkdirSync call.

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.78.2. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

The problem is still in the code of the latest version, so the bug still exists.


Vickel: Watch karepoindia.com

Vickel requests the watch of the watch_keyword karepoindia\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

karepoindia\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


remove account file existence check

Codecov Report

Merging #71 into dev will decrease coverage by 0.49%.
The diff coverage is 0.81%.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c8bd969...494b407. Read the comment docs.


[TW#18946] i2s_adc_dac

Hi,
I have just tried the i2s_adc_dac example and it is working fine. it recorded the audio and played well :)
But i do not know how to save  the data from flash. should i use SPIFFS and write the data to a file or is there any other way which is already implemented somewhere ?
i need to save the recorded data for some analysis, how should i proceed?

Hi,
What do you want to save in flash, an audio file or other data? If it is an audio file, what format is it?

Hi panfeng-espressif,
Thanks for the reply.
Actually i forgot to close this issue. I was reading the data from microphone through adc and wanted to do some analysis of the data.
now i am sending the data through a tcp connection and using a python script on my system to do the analysis.
Anyway once again thanks for the support, is it okay if i re-open this issue in case of any help in future?


Special Characters like ñ will convert a word into number 0 on import

Prerequisites
[x ] Have read and understood: https://github.com/Maatwebsite/Laravel-Excel/blob/3.1/.github/SUPPORT.md
[x ] Checked if your Laravel Excel version is still supported: https://docs.laravel-excel.com/3.1/getting-started/support.html#supported-versions
Checked that your question isn't already asked before.
Filled in the entire issue template
Versions
PHP version: 7.2
Laravel version: 5.8
Package version: ^3.1
Description
I have a CSV file with some rows that has text/words that contain a special character like ñ, what happened is that when I tried to import the file the words with characters above or alike will be converted to 0. Not sure if it is related to encoding, I found some solutions in the StackOverflow but none of them seem to work.
Additional Information
I am using the ToModel
use Maatwebsite\Excel\Concerns\ToModel;
To reproduce this, just try to put a special character in one of the cell of your CSV, then import it like:
Excel::import(new CsvImport, request()->file('file'));
The resulting inserted data that has a special character will be stored as 0

You need to set the correct input encoding in the config https://github.com/Maatwebsite/Laravel-Excel/blob/3.1/config/excel.php#L128

@patrickbrouwers , Not working i already use this
output like :-
Array
(
[name] => ?????
[email] => 123@pt
[phone_number] => 12345675
[password] => 1837323
[annual] => 431
)

We just call PhpSpreadsheet code to parse the Csv, you'll have to ask there or on Stackoverflow then.

Solution :-
https://docs.laravel-excel.com/3.1/imports/custom-csv-settings.html#available-settings

In Header use Maatwebsite\Excel\Concerns\WithCustomCsvSettings;
adding the WithCustomCsvSettings interface
Add this function in your config/excel.php file
public function getCsvSettings(): array
{
return [
'input_encoding' => 'ISO-8859-1'
];
}

@patrickbrouwers , thank you for reply


[core-paging] set PageT default to T[]

We don't really need type inference here.

@sadasant how do you feel about the keyvault changes?

It's too bad we didn't ship this as part of core-paging 1.1

@jeremymeng honestly, I'm using this PR to learn more about core-paging, so I don't think I'm the most appropriate to review this 🌞 but thank you for making it! And for mentioning me. I'll be able to provide better feedback on a future PR.


Take-away Improvements from Grand Prix

I added a new category for primitives that generate new features. We can add more primitives like this https://feature-engine.trainindata.com/en/latest/api_doc/creation/index.html but in another PR.  Feel free to merge it.


Downloading from vandaldata.polito.it

Hi,
Thank you for the great code and datasets !
However, it seems rsync can not connect to host vandaldata.polito.it to download the dataset sample.
Thank you

Hi, can you share a screenshot of your terminal so that I can see what the problem is? I am able to download the dataset simply like this, also on servers on different continents.
rsync -rhz --info=progress2 --ignore-existing rsync://vandaldata.polito.it/sf_xl/mesh_vpr_datasets/test_sets/val_set .

Hi,
Thank for the quick answer.
Here is the screenshot.

The same for nc:
(base) [chidlovs@sensei ~]$ nc -zv <IP_ADDRESS> 22
Ncat: Version 7.70 ( https://nmap.org/ncat )
Ncat: Connection timed out.
We have a firewall but from our server we can http/ssh/rsync .
You have mentioned remote servers, does any of them set a firewall ?
Thank you
PS> I ll check on out side as well

After verification, the problem was on our side, with rsync parameters .
Sorry for misleading message.
and thank you again

No worries, I hope MeshVPR can be helpful for your goals :)


std.csv assert messages

@thewilsonator thank you

@jondegenhardt thank you for the review

LGTM. Thanks for making the changes.

@jondegenhardt that's what review is for

@burner please do remind me about these when I forget, (unless you've forgotten too...).

@thewilsonator sure thing, thanks


actions: add cloudlab

Add actions for interacting with CloudLab (e.g. request, release, renew, etc.). This can leverage the scripts contained in this repo.

Can you explain this issue

hey @ulshell, this is already being worked by @barbaraDorame . However, #512 is similar to this issue, so that would be another alternative to work on


Insert space in titles after # if missing

Corrected 7 missing spaces which caused misinterpretation as paragraph instead of title (heading).

Thank you!

@all-contributors please add @clifflu for translation

@all-contributors please add @clifflu for translation


GitHub OAuth

Use GitHub OAuth to log into repomint.
TODO:

[x] GitHub OAuth setup (localhost:3000 + localhost:3000/github/callback)
[ ] POC (In Progress)
[ ] Full auth implementation

POC
Using a simple Button href in in Settings to work through this.

Note that for the first POC I used https://cors-anywhere.herokuapp.com/ as a reverse proxy. ppl recommend using gatekeeper, so I'll put a poc together for that.

For the full authentication implementation I wanted to research how different people manage doing this. I'm not familiar with this ecosystem.
So far I feel like this  looks good, but I would love some feedback from someone more knowledgeable.

Yup this looks ok - which is using a backend server to communicate to Github. If you need help, we can break this to smaller chunks of issues - and we can choose which one to work on

I'm going to give it a shot. I want to learn. Will lyk if I'm struggling. Thanks! 🙏


your Node.js example in integrating via OpenAI proxy in the docs might be missing a bracket

my mistake, I'll make an issue for this


Mobile Ads: Visual Studio -> Unpacking failed.

When I add the NuGet in VS on Windows and try to build I get:
Unpacking failed. Please download 'https://dl.google.com/dl/cpdc/3605b6f6378a6399-Google-Mobile-Ads-SDK-7.13.0.tar.gz' and extract it to the 'C:\GitHub\app\packages.xbcache\Gmbladssdk-7.13.0' directory and create an empty file called 'C:\GitHub\app\packages.xbcache\Gmbladssdk-7.13.0.unpacked'.
If I follow these steps it works alright, but I shouldn't have to. On XS on Mac it works great (and on build servers).

I have the same error, how I can fix it?

@jamesmontemagno @SergeyMNet
Sometimes, the download will fail because the download path, plus, the name of tar.gz/.zip hits the Microsoft MAX_PATH limit. Please try these workarounds, if not, let me know to review it.

As a first step in troubleshooting, attempt to download and extract the files manually as indicated in the error message. Remember to create the empty file listed in the error message.
If that still doesn't result in a project that can successfully build, check to ensure the MAX_PATH limit (on Windows only) is not being hit. Try moving the project to the root of the disk.
If moving the solution to the root of the disk is not possible or does not solve the issue, the extraction location can be changed through a .csproj property. Add the following lines to the app's csproj file (this will cause the files to be extracted to C:\Code\.xc):

Add to .csproj:

<PropertyGroup>
  <XamarinBuildDownloadDir>C:\Code\.xc</XamarinBuildDownloadDir>
</PropertyGroup>

There is also the possibility that the download file was corrupted and not downloaded correctly. In order to force the task to re-download the file, delete the contents of the cache location. Locations for each platform are:

OSX: ~/Library/Caches/XamarinBuildDownload
Windows: %localappdata%\XamarinBuildDownloadCache


Prepare for it kv5

Prepare for ITK v5.  Some deprecated interfaces are being used for SImpleITK.

@blowekamp This is just the start of some fixes for SImpleITK to conform to future ITKv5.  There are deprecated interfaces being used.

This is very much appreciated.  Can you please base the fixes on master?
On Dec 14, 2017, at 6:25 PM, Hans Johnson <notifications<EMAIL_ADDRESS>wrote:
@blowekamphttps://github.com/blowekamp This is just the start of some fixes for SImpleITK to conform to future ITKv5. There are deprecated interfaces being used.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/SimpleITK/SimpleITK/pull/354#issuecomment-351866979, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AATmJQMPTmgZax9q5M769vpCDAbUCCkLks5tAa5TgaJpZM4RCzpC.

Yes.  After master has a version of ITK that support the recent ITK_FUTURE_LEGACY_REMOVE bug.
Hans
From<EMAIL_ADDRESS><EMAIL_ADDRESS>Reply-To: SimpleITK/SimpleITK<EMAIL_ADDRESS>Date: Thursday, December 14, 2017 at 5:43 PM
To: SimpleITK/SimpleITK<EMAIL_ADDRESS>Cc: Hans Johnson<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [SimpleITK/SimpleITK] Prepare for it kv5 (#354)
This is very much appreciated. Can you please base the fixes on master?
On Dec 14, 2017, at 6:25 PM, Hans Johnson <notifications<EMAIL_ADDRESS>wrote:
@blowekamphttps://github.com/blowekamp This is just the start of some fixes for SImpleITK to conform to future ITKv5. There are deprecated interfaces being used.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/SimpleITK/SimpleITK/pull/354#issuecomment-351866979, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AATmJQMPTmgZax9q5M769vpCDAbUCCkLks5tAa5TgaJpZM4RCzpC.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

It is my understanding that these changes should still be compatible with the prior version. If you just need to test the against the current ITK, when you do you SimpleITK Superbuild configuration you could just add "-DITK_GIT_TAG=v4.13rc02 -DITK_FUTURE_LEGACY_REMOVE=ON" and the version of ITK build should be as you desire. There are a lot of options to configure ITK with and the should just get passed OK with the SimpleITK super build, just FYI about these.
There are a couple test failures that I have started to track down. Hopefully it won't be too long before we merge 4.13rc, so I guess there is no rush.

https://github.com/SimpleITK/SimpleITK/blob/next/SuperBuild/External_ITK.cmake#L50

rebased onto master here:
#355


Is it possible to replace a constructor implementation?

const Ctor = Class.method(".ctor");
Ctor.implementation =
	function (param1: number, param2: number): ??? {
		const instance = Class.alloc();
		instance.method(".ctor").invoke(param1, param2);
		console.log(param1, param2);
		return ???;
	};

I'm not sure if this is possible or if I'm missing something really obvious.

Alright nevermind I figured it out by re-reading issue #25

Yup, constructors do not return any value


bug: Title doesn't show in ion-header-bar with bar-subh

Type: bug
Platform: all
I'd like a subheader with two buttons and a title.  When I try this, the h1 doesn't appear.
    <ion-header-bar class="bar-positive bar-subheader">

        <button class="button button-icon icon ion-ios-minus-outline"
          ng-click="showDelete = !showDelete">
        </button>

Help!  I'm nowhere to be found!

        <button class="button" ui-sref="app.tips">
          Tips
        </button>

    </ion-header-bar>

    <ion-content class="ion-subheader">

      <ion-list show-delete="showDelete"  show-reorder="!showDelete">
     ...

Your system information:
Cordova CLI: 5.0.0
Gulp version:  CLI version 3.8.11
Gulp local:   Local version 3.8.11
Ionic Version: 1.0.0
Ionic CLI Version: 1.4.5
Ionic App Lib Version: 0.0.22
OS: Distributor ID:	LinuxMint Description:	Linux Mint 17 Qiana
Node Version: v0.12.0

Greetings @MichaelJCole!
I've closed this issue because my sensors indicated it was old and inactive, and may have already been fixed in recent versions of Ionic. However, if you are still experiencing this issue, please feel free to reopen this issue by creating a new one, and include any examples and other necessary information, so that we can look into it further.
Thank you for allowing me to assist you.


[BUG] Argo fails to upload output artifacts (when the artifacts are heavier) when there is a service mesh like LinkerD

Pre-requisites

[X] I have double-checked my configuration
[X] I can confirm the issue exists when I tested with :latest
[X] I have searched existing issues and could not find a match for this bug
[ ] I'd like to contribute the fix myself (see contributing guide)

What happened/what did you expect to happen?
Bug:

I have added a pod annotation to kill the linkerd-proxy container - workflows.argoproj.io/kill-cmd-linkerd-proxy: ["/usr/lib/linkerd/linkerd-await", "--shutdown", "--", "sleep", "--help"]
Above mentioned command is executed just after the main container is completed, so, the wait container is only having the grace period to complete it's uploading of output artifacts to the S3
When the output artifacts are heavier or there is a lot of output artifacts to be uploaded, the wait container is stuck in the middle after the grace period while uploading the artifacts. This happens due to the death of the linkerd-proxy container

Ideal Solution:

The command to kill the linkerd-proxy container, should be executed after the wait container

Version
v3.5.5 (latest)
Paste a small workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.
I used the Golang SDK to publish pipelines

- You can use any workflow this
- LinkerD should be installed in the cluster
- Output artifacts should be heavier

Logs from the workflow controller
kubectl logs -n argo deploy/workflow-controller | grep ${workflow}

Logs from in your workflow's wait container
kubectl logs -n argo -c wait -l workflows.argoproj.io/workflow=${workflow},workflow.argoproj.io/phase!=Succeeded

I tried this with the latest version available (v3.5.5), but the issue is still there, hence I opened this issue
But, I could solve this using sidecars - https://argo-workflows.readthedocs.io/en/latest/walk-through/sidecars/
Below is the hack I did to solve this (Hope this will help someone with the same issue):
Implemented a sidecar to do the following things

Modify the pod annotation for Linkerd - I have configured the workflow to add a pod annotation to kill the linkerd-proxy container. (workflows.argoproj.io/kill-cmd-linkerd-proxy: ["/usr/lib/linkerd/linkerd-await", "--shutdown", "--", "sleep", "--help"]). I can't remove this annotation from the workflow, since this annotation is not only for the template pod where this new sidecar runs, but also for the finalizer pod, so, If remove this annotation the workflow will keep running since the linkerd-proxy container is never dying. Hence I added a logic to the sidecar to modify the pod annotation only in the template pod
Modify the pod annotation for this new sidecar - Sidecars are killed just after the main container is completed. But, we can override those killing commands by adding another pod annotation. Here is the pod annotation I add - workflows.argoproj.io/kill-cmd-{name of the sidecar}: ["echo"]
Watch for the status of the wait container
Call the shutdown hook of the linkerd-proxy once the wait container is completed - curl -X POST http://localhost:4191/shutdown
Complete the self pod

NOTE: You can take a look at the code here - https://github.com/HasithaAthukorala/argo-sidecar

Noting that this is a follow-up to this Slack thread

@agilgur5  Is this related to that? I feel like this is the place where all the custom pod annotations are executed (killing all the sidecars). https://github.com/argoproj/argo-workflows/blob/0b625a61a3473f9045d35a6bc0ae8a99db73e2ca/workflow/controller/controller.go#L362-L363

I mean, at a really high-level yes, but you have to go down several layers of the call stack to get to SignalContainer which actually runs the kill command.
The question is why is that occurring, as normally containers are only killed when the Workflow has been stopped or cancelled, or the step has exceed its deadline. In the codebase, that is when Pods are queued up with action terminateContainers or killContainers.
I suspect it is deeper than that; there seems to be an assumption somewhere that when the main container finishes, all containers should be killed and that wait executes after main is killed.
The solution to that seems non-trivial, the first kill should only take out main (and maybe others if you have sidecars or a containerSet?) and then there needs to be a second kill after wait finishes to get the remaining containers.

I suspect it is deeper than that; there seems to be an assumption somewhere that when the main container finishes, all containers should be killed and that wait executes after main is killed.

Ok I found that assumption in the codebase which basically says that in the comments: https://github.com/argoproj/argo-workflows/blob/7c04653543cdfd48e6f2ec96fc4bb87779ed2773/workflow/controller/operator.go#L1504
This originates from the injected sidecar support PR #5383, which did check for the wait container specifically. Then a check for the main container was added in #6033. Then the wait check was moved in #8478
That code still exists, so this is possibly a regression from #8478?

Yes, I believe this is happening due to the feature, Sidecar Injection - https://argo-workflows.readthedocs.io/en/latest/sidecar-injection/
To solve this issue, I used above feature as a hack to inject another sidecar to kill the linkerd-proxy container. So, I could see that, all the sidecars are killed just after the main container is completed. That is also mentioned in the documentation as well - https://argo-workflows.readthedocs.io/en/latest/sidecar-injection/#:~:text=It can be impossible for the wait container to terminate the sidecar.

Your comment is not quite correct, so I will correct it below. But it's not related to my analysis either, it's just a misunderstanding of the features.

Yes, I believe this is happening due to the feature, Sidecar Injection - https://argo-workflows.readthedocs.io/en/latest/sidecar-injection/

Er, that's the feature that makes using Sidecar Injection with Argo even work in the first place. Without it, Pods hang.
There's just a bug in it.

To solve this issue, I used above feature as a hack to inject another sidecar

As you wrote previously, you used regular Sidecars: https://argo-workflows.readthedocs.io/en/latest/walk-through/sidecars/.
"Injected" means that they're added by a different controller, LinkerD in your case, and not Argo. You didn't "inject" anything other than LinkerD, you just added a regular sidecar.
The "injection" is what makes service mesh sidecars cause bugs with lots of different tools. The tools don't know about the injected sidecar as they didn't add them themselves, something else "injected" them. Often that means the tool now has to support them somehow in a wacky way, which is what Argo tries to do.
You did use the kill command feature, which is normally for injected sidecars, as a hack to allow your new sidecar to keep running. That is a clever workaround.

all the sidecars are killed just after the main container is completed. That is also mentioned in the documentation as well - https://argo-workflows.readthedocs.io/en/latest/sidecar-injection/#:~:text=It can be impossible for the wait container to terminate the sidecar.

That's not what that quote says. It says that the wait container itself cannot necessarily kill other containers.
The interesting thing here is that you showed that a sidecar can kill it in this case since it's available over the local network, which you did in your workaround.
The wait container is itself a sidecar and could potentially do something similar.


Remove blogs

Removes blogs from here since they are on the website repo now.

[x] I've read the contributing guidelines.
[x] I've read "What is a Good PR?"
[x] I've included a good title and brief description along with how to review them.
[x] I've linked any associated an issue.

#1182 should be merged first since those changes seem to be part of this PR as well


Protobuf Schema Register - ConfluentSchemaRegistryError: not implemented yet

I am trying to register a protobuf schema like so
const registry = new SchemaRegistry({ host: 'http://<IP_ADDRESS>:8081/' })

const schema = `
  package examples;
  message RandomTest {
    required string fullName = 1;
  }
`

const run = async () => {
    const { id } = await registry.register({ type: SchemaType.PROTOBUF, schema: schema })
}

run().catch(console.error)

but I receive an error of
ConfluentSchemaRegistryError: not implemented yet

Is protobuf not supported yet?

Protobuf is supported, but you have to provide a subject to register the schema for. In Avro, we generate a subject automatically if one is not provided, but we don't have that for Protobuf and JSON Schema.
I can see that the example Protobuf usage does not include the subject, which is bad. Should be something like:
const { SchemaType } = require('@kafkajs/confluent-schema-registry')

const schema = `
  package examples;
  message RandomTest {
    required string fullName = 1;
  }
`
const { id } = await registry.register(
  { type: SchemaType.PROTOBUF, schema },
  { subject: "examples.RandomTest" }
)

So I have an example of a proto file
_syntax = "proto3";
package com.mhowlett;
import "google/protobuf/wrappers.proto";
message LogLine {
string ip = 1;
uint64 timestamp = 2;
string url = 3;
string referer = 4;
string useragent = 5;
google.protobuf.UInt64Value session_id = 6;
}_
Using this kafkajs example, the schema that gets registered on the schema registry is missing the reference field driven by the import..
should be -
{
"subject": "com.mhowlett-value",
"version": 1,
"id": 3,
"schemaType": "PROTOBUF",
"references": [
{
"name": "google/protobuf/wrappers.proto",
"subject": "google/protobuf/wrappers.proto",
"version": 1
}
],
"schema": "syntax = "proto3";\npackage com.mhowlett;\n\nimport "google/protobuf/wrappers.proto";\n\nmessage LogLine {\n  string ip = 1;\n  uint64 timestamp = 2;\n  string url = 3;\n  string referer = 4;\n  string useragent = 5;\n  .google.protobuf.UInt64Value session_id = 6;\n}\n"
}
but what this gives is -
{
"subject": "com.mhowlett-value",
"version": 1,
"id": 3,
"schemaType": "PROTOBUF",
"schema": "syntax = "proto3";\npackage com.mhowlett;\n\nimport "google/protobuf/wrappers.proto";\n\nmessage LogLine {\n  string ip = 1;\n  uint64 timestamp = 2;\n  string url = 3;\n  string referer = 4;\n  string useragent = 5;\n  google.protobuf.UInt64Value session_id = 6;\n}\n"
}
Note that a dot(.) is also missing in front of google.protobuf.UInt64Value session_id comparing to the actual ..

Schema references (imports) are not supported in Protobuf #82

I would like to take a stab at solving this, since we need Protocol Buffer support as well.
@Nick0412 do you mind taking a look at https://github.com/kafkajs/confluent-schema-registry/pull/135 and let me know if you think that change would help in your case?

You can work around this lack by registering your protos separately from using the schema registry.  I use the maven plugin to run a registration step for all of my protos as part of my build process.  That way, clients only need to look up schemas, not parse them correctly. The java implementation is really the only registry client that is trustworthy. This is important, as many languages have schema registry client implementations that don't correctly parse protobuf schemas (golang and js just for starters.  And python and .NET have broken serializer implementations that don't encode the wire protocol for protobufs correctly, though it's possible they at least do proto registration correctly).


helper-cli: Add a command to generate a flat analyzer result

The command defines a data model called SimpleDefinitionFile which is
read as input using any of the known file extensions. It outputs an
analyzer result with a single project containing the provided
dependencies as a flat list.
When a project does not use a package manager, currently the only way of
scanning it with ORT is to craft SPDX files and running the analyzer
against them. This command tries to provide a minimalistic alternative
to fullfil the requirements of the underlying need.
Note: This is a first experimental version. Furthermore, VcsInfo is deliberately not used, in order to:
      1. avoid nesting to in turn make it easier to generate the input file.
      2. make all attributes optional.

This command tries to provide a minimalistic alternative
to fullfil the requirements of the underlying need.

Typo in "fullfil", should be "fulfill".
In general this sentence is a bit cryptic. Please be transparent about what the "underlying need" is and document it in the commit message.

currently the only way of
scanning it with ORT is to craft SPDX files and running the analyzer
against them.

I want to start by saying that I agree that writing / generating SPDX files as a substitute for a lack of supported definition files for ORT is cumbersome, mostly because SPDX is such a terrible format IMO. Maybe we should have instead used AboutCode Data or an ORT-specific "fake definition file" formats that's easier to use than writing whole analyzer result files from hand.
That said, I believe this goal of this PR should be implemented differently: As a company-internal package manager plugin that uses your SimpleDefinitionFile as definition files. How do @mnonnenmacher and @MarcelBochtler think about this?

That said, I believe this goal of this PR should be implemented differently: As a company-internal package manager plugin that uses your SimpleDefinitionFile as definition files.

I thought it makes sense to try it out as helper-cli command first before turning it into a package manager plugin, as I believe it is quicker to develop. That is, I planned to refactor this in future when it matured a bit, into a package manager (disabled by default).
Why do you think it should remain company internal? Do you think nobody would be interrested in using it in the long run?

Mostly because of the "I believe it is quicker to develop" rationale you mentioned

I think we've added "experimental" things to ORT / helper-cli already before this PR.

Mostly because of the "I believe it is quicker to develop" rationale you mentioned

I think we've added "experimental" things to ORT / helper-cli already before this PR.

Right, but this is not about the level of "experimentality", but about where the code fits, whatever the maturity is. And to me a dedicated package manager so clearly is a better fit (if I'm getting the use-case right), that personally I'd draw a line here. Otherwise Bosch, Porsche and others could have contributed their plugins also as helper-cli commands (but we've turned them down).

Frank forgot to mention we also want to use this new helper functionality for scanning. Having this helper command would make it more easier to implement inbound FOSS scanning or pre-scanning.
Inbound FOSS scanning is something we started working whilst at HERE, the idea is to scan a FOSS package the moment it's introduced into the organization.
Developer does dependencies update -> packages are being fetched from internal package registry (artifactory) -> artifactory does not have version so retrieves package form public package registry and at the same time trigger inbound FOSS scan via REST API providing package url and VCS url -> inbound FOSS scan executes helper cli command to generate analyzer file -> trigger ORT scan with ScanCode -> Scan results is added to scan storage -> when developer create pull/merge request ORT scan is done and new version of dependency is already scanned.
Similarly one can also implement pre-scanning - from Artifactory usage stats one can deduct most used FOSS package and then logic can be implement to trigger inbound FOSS ORT scan the moment package popular within the org release a new version.

inbound FOSS scan executes helper cli command to generate analyzer file defined in this PR

How's the required SimpleDefinitionFile input provided in that scenario?

I would appreciate if we could discuss it in a community meeting after the summer break to collect requirements.

I needed something quick in place to help during the next couple of weeks. I understand you guys don't want that, I'll just turn the PR into a draft and keep the branch around for while.

I've added a test which tests end to end through helper main, which illustrates the input format (and the expected output).

Please note the detekt issues (and rebase to get rid of an unrelated test failure).


[WIP] QFT circuit synthesis for linear nearest neighbor connectivity

Summary
#9036
Synthesis of QFT circuits for linear nearest neighbor connectivity
based on Fowler et al, Fig 2.b from https://arxiv.org/abs/quant-ph/0402196
Details and comments

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

14 of 14 (100.0%)  changed or added relevant lines in 3 files are covered.
24 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.03%) to 85.897%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/lex.rs
6
91.67%

crates/qasm2/src/parse.rs
18
96.2%

Totals

Change from base Build<PHONE_NUMBER>:
-0.03%

Covered Lines:
65926

Relevant Lines:
76750

💛  - Coveralls

Here are some performance benchmarks done with @alexanderivrii
10-qubit QFT circuits:
Original QFT code (do_swaps=False)
Transpiled using Qiskit: depth = 523, count-2q = 172, depth-2q = 111
Transpiler using TKet:   depth = 323, count-2q = 169, depth-2q = 91
QFT-LNN code (do_swaps = True)
Transpiled using Qiskit: depth = 252, count-2q = 135, depth-2q = 51
Transpiler using TKet:   depth = 269, count-2q = 149, depth-2q = 77

50-qubit QFT circuits:
Original QFT code (do_swaps=False)
Transpiled using Qiskit: depth = 4552, count-2q = 4940, depth-2q = 951
Transpiler using TKet:   depth = 3040, count-2q = 4267, depth-2q = 910
QFT-LNN code (do_swaps = True)
Transpiled using Qiskit: depth = 1458, count-2q = 3675, depth-2q = 291
Transpiler using TKet:   depth = 3036, count-2q = 4265, depth-2q = 910

LGTM, just left some tiny comments above. The one thing I'm still not quite understanding is how this has the approximately same number of gates as the tket example but is way shallower. But as long as the synthesis is correct I guess that's good 🙂


Update troubleshooting.md

Reason for Change:

Requirements

[ ] squashed commits
[ ] included documentation
[ ] added unit tests and e2e tests (if applicable).

Issue Fixed:

Please answer the following questions with yes/no:
Does this change contain code from or inspired by another project? If so, did you notify the maintainers and provide attribution?

[ ] yes
[x] no

Notes for Reviewers:

Closing this with https://github.com/Azure/azure-workload-identity/pull/1224#pullrequestreview-1805179030. Feel free to reopen after the comments have been addressed.