text:
Missing symbol on MacOS

Solution to issue cannot be found in the documentation.

[X] I checked the documentation.

Issue
I'm not a mac user myself, but I have a downstream project that installs iDynTree distributed with conda-forge for continuous integration checks. I just got a overnight failure in the macOS job of a GitHub action that imports the SWIG-based Python bindings. Here below the following error message:
 ============================= test session starts ==============================
platform darwin -- Python 3.10.15, pytest-8.3.3, pluggy-1.5.0 -- /Users/runner/miniconda3/envs/test/bin/python3.10
cachedir: .pytest_cache
rootdir: /Users/runner/work/rod/rod
configfile: setup.cfg
testpaths: tests
collecting ... collected 2 items / 2 errors

==================================== ERRORS ====================================
_________________ ERROR collecting tests/test_urdf_exporter.py _________________
ImportError while importing test module '/Users/runner/work/rod/rod/tests/test_urdf_exporter.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
../../../miniconda3/envs/test/lib/python3.10/importlib/__init__.py:126: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
tests/test_urdf_exporter.py:1: in <module>
    import idyntree.bindings as idt
../../../miniconda3/envs/test/lib/python3.10/site-packages/idyntree/__init__.py:1: in <module>
    from . import swig
../../../miniconda3/envs/test/lib/python3.10/site-packages/idyntree/swig.py:10: in <module>
    from . import _iDynTree
E   ImportError: dlopen(/Users/runner/miniconda3/envs/test/lib/python3.10/site-packages/idyntree/_iDynTree.so, 0x0002): symbol not found in flat namespace '_SCOTCH_errorPrint'
_________________ ERROR collecting tests/test_urdf_parsing.py __________________
ImportError while importing test module '/Users/runner/work/rod/rod/tests/test_urdf_parsing.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
../../../miniconda3/envs/test/lib/python3.10/importlib/__init__.py:126: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
tests/test_urdf_parsing.py:3: in <module>
    import robot_descriptions.loaders.idyntree
../../../miniconda3/envs/test/lib/python3.10/site-packages/robot_descriptions/loaders/idyntree.py:14: in <module>
    import idyntree.swig as idyn
../../../miniconda3/envs/test/lib/python3.10/site-packages/idyntree/__init__.py:1: in <module>
    from . import swig
../../../miniconda3/envs/test/lib/python3.10/site-packages/idyntree/swig.py:10: in <module>
    from . import _iDynTree
E   ImportError: dlopen(/Users/runner/miniconda3/envs/test/lib/python3.10/site-packages/idyntree/_iDynTree.so, 0x0002): symbol not found in flat namespace '_SCOTCH_errorPrint'
!!!!!!!!!!!!!!!!!!! Interrupted: 2 errors during collection !!!!!!!!!!!!!!!!!!!!
============================== 2 errors in 0.86s ===============================

My suspicion is that the package is compiled and distributed linking dynamically against a specific version of a C++ dependency, but then the resolved downstream environment installs a different version of this library that is not ABI-compatible (there's a missing symbol).
Installed packages
Channels:
 - conda-forge
 - defaults
Platform: osx-arm64
Collecting package metadata (repodata.json): ...working... done
Solving environment: ...working... done

## Package Plan ##

  environment location: /Users/runner/miniconda3/envs/test

  added / updated specs:
    - black
    - coloredlogs
    - idyntree
    - isort
    - libgz-tools2
    - libsdformat13
    - mashumaro
    - numpy
    - packaging
    - pptree
    - pytest
    - resolve-robotics-uri-py
    - robot_descriptions
    - scipy
    - trimesh
    - xmltodict

The following packages will be downloaded:

    package                    |            build
    ---------------------------|-----------------
    ampl-mp-3.1.0              |    hbec66e7_1006         968 KB  conda-forge
    assimp-5.4.3               |       ha9c0b8d_0         2.4 MB  conda-forge
    black-24.8.0               |  py310hbe9552e_1         299 KB  conda-forge
    cli11-2.4.1                |       hebf3989_0          82 KB  conda-forge
    click-8.1.7                |unix_pyh707e725_0          82 KB  conda-forge
    colorama-0.4.6             |     pyhd8ed1ab_0          25 KB  conda-forge
    coloredlogs-15.0.1         |     pyhd8ed1ab_3          40 KB  conda-forge
    console_bridge-1.0.2       |       h3e96240_1          17 KB  conda-forge
    eigen-3.4.0                |       h1995070_0         1.0 MB  conda-forge
    exceptiongroup-1.2.2       |     pyhd8ed1ab_0          20 KB  conda-forge
    gettext-0.22.5             |       h8414b35_3         472 KB  conda-forge
    gettext-tools-0.22.5       |       h8414b35_3         2.4 MB  conda-forge
    gitdb-4.0.11               |     pyhd8ed1ab_0          52 KB  conda-forge
    gitpython-3.1.43           |     pyhd8ed1ab_0         153 KB  conda-forge
    glfw-3.4                   |       h93a5062_0         111 KB  conda-forge
    gmp-6.3.0                  |       h7bae524_2         357 KB  conda-forge
    humanfriendly-10.0         |     pyhd8ed1ab_6          72 KB  conda-forge
    icu-75.1                   |       hfee45f7_0        11.3 MB  conda-forge
    idyntree-13.0.0            |  py310h450bec7_1         1.9 MB  conda-forge
    iniconfig-2.0.0            |     pyhd8ed1ab_0          11 KB  conda-forge
    ipopt-3.14.16              |       h4500666_5         738 KB  conda-forge
    irrlicht-1.8.5             |       hdfd4c6d_5         1.1 MB  conda-forge
    isort-5.13.2               |     pyhd8ed1ab_0          72 KB  conda-forge
    libasprintf-0.22.5         |       h8414b35_3          40 KB  conda-forge
    libasprintf-devel-0.22.5   |       h8414b35_3          34 KB  conda-forge
    libblas-3.9.0              |24_osxarm64_openblas          15 KB  conda-forge
    libboost-1.86.0            |       h29978a0_2         1.9 MB  conda-forge
    libcblas-3.9.0             |24_osxarm64_openblas          15 KB  conda-forge
    libcxx-19.1.0              |       ha82da77_0         509 KB  conda-forge
    libedit-3.1.20191231       |       hc8eb9b7_2          94 KB  conda-forge
    libgettextpo-0.22.5        |       h8414b35_3         156 KB  conda-forge
    libgettextpo-devel-0.22.5  |       h8414b35_3          36 KB  conda-forge
    libgfortran-5.0.0          |13_2_0_hd922786_3         108 KB  conda-forge
    libgfortran5-13.2.0        |       hf226fd6_3         974 KB  conda-forge
    libgz-cmake3-3.5.3         |       h00cdb27_0         201 KB  conda-forge
    libgz-math7-7.5.1          |       hf9b8971_0         218 KB  conda-forge
    libgz-tools2-2.0.1         |       hce4b3f6_0          38 KB  conda-forge
    libgz-utils2-2.2.0         |       hf9b8971_0          54 KB  conda-forge
    libiconv-1.17              |       h0d3ecfb_2         661 KB  conda-forge
    libintl-0.22.5             |       h8414b35_3          79 KB  conda-forge
    libintl-devel-0.22.5       |       h8414b35_3          38 KB  conda-forge
    libjpeg-turbo-3.0.0        |       hb547adb_1         535 KB  conda-forge
  zstd               conda-forge/osx-arm64::zstd-1.5.6-hb46c0d2_0

Downloading and Extracting Packages: ...working... done
Preparing transaction: ...working... done
Verifying transaction: ...working... done
Executing transaction: ...working... done

Environment info
https://github.com/ami-iit/rod/actions/runs/11044452210/job/30680404191

This will be fixed by https://github.com/conda-forge/ipopt-feedstock/pull/111 .

Awesome, great! I anticipated that issue by good.... 5 minutes :laughing:

The issue was solved in https://github.com/conda-forge/ipopt-feedstock/pull/111 but reintroduced in some form in https://github.com/conda-forge/ipopt-feedstock/pull/112, see https://github.com/conda-forge/ipopt-feedstock/issues/114 .

Fixed by https://github.com/conda-forge/ipopt-feedstock/pull/120 .

Thanks! I triggered manually the failed CI runs and I confirm that the problem is now solved. Here below the resolved environment:
Channels:
 - conda-forge
 - defaults
Platform: osx-arm64
Collecting package metadata (repodata.json): ...working... done
Solving environment: ...working... done
## Package Plan ##
  environment location: /Users/runner/miniconda3/envs/test
  added / updated specs:
    - black
    - coloredlogs
    - idyntree
    - isort
    - libgz-tools2
    - libsdformat13
    - mashumaro
    - numpy
    - packaging
    - pptree
    - pytest
    - resolve-robotics-uri-py
    - robot_descriptions
    - scipy
    - trimesh
    - xmltodict
The following packages will be downloaded:
    package                    |            build
    ---------------------------|-----------------
    ampl-mp-3.1.0              |    hbec66e7_1006         968 KB  conda-forge
    assimp-5.4.3               |       ha9c0b8d_0         2.4 MB  conda-forge
    black-24.8.0               |  py310hbe9552e_1         299 KB  conda-forge
    cli11-2.4.1                |       hebf3989_0          82 KB  conda-forge
    click-8.1.7                |unix_pyh707e725_0          82 KB  conda-forge
    colorama-0.4.6             |     pyhd8ed1ab_0          25 KB  conda-forge
    coloredlogs-15.0.1         |     pyhd8ed1ab_3          40 KB  conda-forge
    console_bridge-1.0.2       |       h3e96240_1          17 KB  conda-forge
    eigen-3.4.0                |       h1995070_0         1.0 MB  conda-forge
    exceptiongroup-1.2.2       |     pyhd8ed1ab_0          20 KB  conda-forge
    gettext-0.22.5             |       h8414b35_3         472 KB  conda-forge
    gettext-tools-0.22.5       |       h8414b35_3         2.4 MB  conda-forge
    gitdb-4.0.11               |     pyhd8ed1ab_0          52 KB  conda-forge
    gitpython-3.1.43           |     pyhd8ed1ab_0         153 KB  conda-forge
    glfw-3.4                   |       h93a5062_0         111 KB  conda-forge
    gmp-6.3.0                  |       h7bae524_2         357 KB  conda-forge
    humanfriendly-10.0         |     pyhd8ed1ab_6          72 KB  conda-forge
    icu-75.1                   |       hfee45f7_0        11.3 MB  conda-forge
    idyntree-13.0.0            |  py310h450bec7_1         1.9 MB  conda-forge
    iniconfig-2.0.0            |     pyhd8ed1ab_0          11 KB  conda-forge
    ipopt-3.14.16              |       h1cdd005_9         739 KB  conda-forge
    irrlicht-1.8.5             |       hdfd4c6d_5         1.1 MB  conda-forge
    isort-5.13.2               |     pyhd8ed1ab_0          72 KB  conda-forge
    libasprintf-0.22.5         |       h8414b35_3          40 KB  conda-forge
    libasprintf-devel-0.22.5   |       h8414b35_3          34 KB  conda-forge
    libblas-3.9.0              |24_osxarm64_openblas          15 KB  conda-forge
    libboost-1.86.0            |       h29978a0_2         1.9 MB  conda-forge
    libcblas-3.9.0             |24_osxarm64_openblas          15 KB  conda-forge
    libcxx-19.1.0              |       ha82da77_0         509 KB  conda-forge
    libedit-3.1.20191231       |       hc8eb9b7_2          94 KB  conda-forge
    libgettextpo-0.22.5        |       h8414b35_3         156 KB  conda-forge
    libgettextpo-devel-0.22.5  |       h8414b35_3          36 KB  conda-forge
    libgfortran-5.0.0          |13_2_0_hd922786_3         108 KB  conda-forge
    libgfortran5-13.2.0        |       hf226fd6_3         974 KB  conda-forge
    libgz-cmake3-3.5.3         |       h00cdb27_0         201 KB  conda-forge
    libgz-math7-7.5.1          |       hf9b8971_0         218 KB  conda-forge
    libgz-tools2-2.0.1         |       hce4b3f6_0          38 KB  conda-forge
    libgz-utils2-2.2.0         |       hf9b8971_0          54 KB  conda-forge
    libiconv-1.17              |       h0d3ecfb_2         661 KB  conda-forge
    libintl-0.22.5             |       h8414b35_3          79 KB  conda-forge
    libintl-devel-0.22.5       |       h8414b35_3          38 KB  conda-forge
    libjpeg-turbo-3.0.0        |       hb547adb_1         535 KB  conda-forge
    liblapack-3.9.0            |24_osxarm64_openblas          15 KB  conda-forge
    libopenblas-0.3.27         |openmp_h517c56d_1         2.8 MB  conda-forge
    libosqp-0.6.3              |       h13dd4ca_0          63 KB  conda-forge
    libpng-1.6.44              |       hc14010f_0         257 KB  conda-forge
    libqdldl-0.1.5             |       hb7217d7_1          15 KB  conda-forge
    libscotch-7.0.4            |       h7c38b86_5         266 KB  conda-forge
    libsdformat13-13.6.0       |       h79a30e3_4         722 KB  conda-forge
    libxcb-1.17.0              |       hdb1d25a_0         316 KB  conda-forge
    libxml2-2.12.7             |       h01dff8b_4         575 KB  conda-forge
    llvm-openmp-18.1.8         |       hde57baf_1         270 KB  conda-forge
    mashumaro-3.13.1           |     pyhd8ed1ab_0          71 KB  conda-forge
    metis-5.1.0                |    h13dd4ca_1007         3.7 MB  conda-forge
    mumps-include-5.7.3        |       hce30654_4          23 KB  conda-forge
    mumps-seq-5.7.3            |       h5112546_4         2.1 MB  conda-forge
    mypy_extensions-1.0.0      |     pyha770c72_0          10 KB  conda-forge
    numpy-2.1.1                |  py310hcaf17df_0         5.6 MB  conda-forge
    osqp-eigen-0.8.1           |       h136a8c3_1          33 KB  conda-forge
    packaging-24.1             |     pyhd8ed1ab_0          49 KB  conda-forge
    pathspec-0.12.1            |     pyhd8ed1ab_0          40 KB  conda-forge
    platformdirs-4.3.6         |     pyhd8ed1ab_0          20 KB  conda-forge
    pluggy-1.5.0               |     pyhd8ed1ab_0          23 KB  conda-forge
    pptree-3.1                 |     pyhd8ed1ab_0           9 KB  conda-forge
    pthread-stubs-0.4          |    hd74edd7_1002           8 KB  conda-forge
    pytest-8.3.3               |     pyhd8ed1ab_0         252 KB  conda-forge
    python_abi-3.10            |          5_cp310           6 KB  conda-forge
    resolve-robotics-uri-py-0.3.0|     pyhd8ed1ab_0          12 KB  conda-forge
    robot_descriptions-1.12.0  |     pyhd8ed1ab_0          38 KB  conda-forge
    ruby-3.3.3                 |       h57ff7e8_0         8.2 MB  conda-forge
    scipy-1.14.1               |  py310h35b72dc_0        13.7 MB  conda-forge
    sdl-1.2.68                 |       hfc12253_0         152 KB  conda-forge
    sdl2-2.30.7                |       hf9b8971_0         1.2 MB  conda-forge
    smmap-5.0.0                |     pyhd8ed1ab_0          22 KB  conda-forge
    tinyxml2-10.0.0            |       hebf3989_0         110 KB  conda-forge
    tomli-2.0.1                |     pyhd8ed1ab_0          16 KB  conda-forge
    tqdm-4.66.5                |     pyhd8ed1ab_0          87 KB  conda-forge
    trimesh-4.4.9              |     pyhd8ed1ab_0         553 KB  conda-forge
    typing-extensions-4.12.2   |       hd8ed1ab_0          10 KB  conda-forge
    typing_extensions-4.12.2   |     pyha770c72_0          39 KB  conda-forge
    unixodbc-2.3.12            |       h0e2417a_0         248 KB  conda-forge
    urdfdom-4.0.1              |       h922ef61_0          91 KB  conda-forge
    urdfdom_headers-1.1.2      |       h7b3277c_0          19 KB  conda-forge
    xmltodict-0.13.0           |     pyhd8ed1ab_0          13 KB  conda-forge
    xorg-libx11-1.8.10         |       h2321a68_0         736 KB  conda-forge
    xorg-libxau-1.0.11         |       hd74edd7_1          13 KB  conda-forge
    xorg-libxdmcp-1.1.3        |       hd74edd7_1          18 KB  conda-forge
    xorg-libxext-1.3.4         |       h1a8c8d9_2          41 KB  conda-forge
    xorg-xextproto-7.3.0       |    hd74edd7_1004          30 KB  conda-forge
    xorg-xorgproto-2024.1      |       hd74edd7_1         554 KB  conda-forge
    yaml-0.2.5                 |       h3422bc3_2          86 KB  conda-forge
    zlib-1.3.1                 |       hfb2fe0b_1          76 KB  conda-forge
    zstd-1.5.6                 |       hb46c0d2_0         396 KB  conda-forge
    ------------------------------------------------------------

authors: diegoferigo traversaro

repo: conda-forge/idyntree-feedstock


text:
Release 1.0.0

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

@conda-forge-admin, please rerender

@conda-forge-admin, please rerender

Just an FYI, https://status.quay.io/ might have issues pulling down an image

source: gharchive/pull-request

authors: RiesBen mikemhenry

repo: conda-forge/kartograf-feedstock

license_type: permissive

license_source: github-api


text:
Pin libxml2 to 2.9.3

See https://github.com/conda-forge/conda-forge.github.io/pull/260#issue-186803328

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Closing this for now. Waiting for @kwilcox, @rsignell-usgs, and @tomkralidis tests.

Tests results are in and libxml2 2.9.3 is OK! Stay away from libxml2 2.9.4 though.

authors: conda-forge-linter ocefpaf

repo: conda-forge/lxml-feedstock


text:
Update to 1.3.1

Checklist

[X] Used a personal fork of the feedstock to propose changes
[X] Bumped the build number (if the version is unchanged)
[X] Reset the build number to 0 (if the version changed)
[X] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[X] Ensured the license file is being packaged.

thanks! :)

authors: pavelzw wolfv

repo: conda-forge/micromamba-feedstock


text:
Do not merge: Update to v5.2.0

Checklist

[x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe:

License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

@conda-forge-admin, please rerender

@vijaysm, could you check to make sure the dependencies have been updated correctly?

@vijaysm, it seems that MOAB isn't building successfully with Open MPI.  This is one of the reasons I was hoping for a release candidate to test out before you made a release.  I'm doing a local build so I can hopefully at least see the error log.  Let me know if you have ideas on how to maybe patch this.

Here's what I'm seeing in the error log:
$ cat parallel_unit_tests.log
Loading /home/xylar/miniconda3/conda-bld/moab_1595241940583/work/MeshFiles/unittest/64bricks_512hex.h5m..
Loading /home/xylar/miniconda3/conda-bld/moab_1595241940583/work/MeshFiles/unittest/64bricks_512hex.h5m..
test_elements_on_several_procs : success
test_ghost_elements_3_2_1 : success
test_ghost_elements_3_2_2 : success
test_ghost_elements_3_0_1 : success
test_ghost_elements_2_0_1 : success
test_ghost_tag_exchange : success
regression_ghost_tag_exchange_no_default : success
test_delete_entities : success
test_sequences_after_ghosting : success
test_ghost_polyhedra : success
test_too_few_parts : success
test_assign_global_ids : success
test_shared_sets : success
test_reduce_tags : success
[0]MOAB ERROR: --------------------- Error Message ------------------------------------
[0]MOAB ERROR: Sizes between src and dst tags don't match!
[0]MOAB ERROR: reduce_tags() line 7347 in src/ParallelComm.cpp
[0]MOAB ERROR: --------------------- Error Message ------------------------------------
[0]MOAB ERROR: Src tag must have default value!
[0]MOAB ERROR: reduce_tags() line 7339 in src/ParallelComm.cpp
[1]MOAB ERROR: --------------------- Error Message ------------------------------------
[1]MOAB ERROR: Sizes between src and dst tags don't match!
[1]MOAB ERROR: reduce_tags() line 7347 in src/ParallelComm.cpp
[1]MOAB ERROR: --------------------- Error Message ------------------------------------
[1]MOAB ERROR: Src tag must have default value!
[1]MOAB ERROR: reduce_tags() line 7339 in src/ParallelComm.cpp
test_reduce_tag_failures : success
test_reduce_tag_explicit_dest : success
test_interface_owners : success
test_ghosted_entity_shared_data : success
Running test_trivial_partition ...
regression_owners_with_ghosting : success
Running test_trivial_partition ...
 send sizes  6 10

 send sizes  6 10

All tests passed
PASS parallel_unit_tests (exit status: 0)

Let me know if you have any ideas...

@vijaysm, to build locally, install Miniconda3, then install conda-build, then run:
conda build -m .ci_support/linux_mpiopenmpipython3.7.____cpythontempesttempest.yaml recipe

on this branch.

I think we are not catching some return error codes properly in the parallel_unit_tests. But looks like all the tests seem to pass correctly however.
I will test try this locally and will let you know if I can resolve the openmpi errors.

Ok, looks like ghost_thin_layers test is failing in all the OpenMPI builds. That is weird. @iulian787 I'll ping you about this once I find out why its erroring out.

@xylar I was able to debug and find the issue. I have a fix in a branch. For now, I want to make sure there aren't any other failures. Should I just change the tarball path and then use it to debug locally ?
I will consolidate all necessary fixes and we will release a minor version end of the week to get this working. We are also looking at updating our debian and homebrew builds and so they will also be part of the new changes in the minor release. Just FYI.

Should I just change the tarball path and then use it to debug locally ?

Yes, you can do that or you can just give it a relative path to the code or a git URL if that's easier.

I will consolidate all necessary fixes and we will release a minor version end of the week to get this working. We are also looking at updating our debian and homebrew builds and so they will also be part of the new changes in the minor release. Just FYI.

That sounds good.  Probably easier than patching the existing release.  I'll close this PR once we have another one working.
Could you make a tarball of the expected minor release (or point me to a branch) before actually releasing so we can do a full conda-forge test build before the release?

BTW, can we delete the branches vijaysm/5.1.0 and vijaysm-mbpart?  You should be pushing branches to your fork, not to the main feedstock because the branches on the main feedstock actually produce and upload packages when merges are made to them.

Sounds good. I'll upload a test tarball to verify locally. And will let you know once we are ready with the minor release tarball.
Yes, please go ahead and delete the old branches from the original moab-feedstock repository. Or I can do that if you dont have the permissions.

Can you also add a dependency on metis ? This would ensure we have a partitioner available as well during the build.
I also see that Zoltan has a conda package and that would be a better dependency for parallel runs. Though it also has dependency on OpenMPI and MPICH and I am not sure about full compatibility in the build matrix. So for now, let's leave this one out.
This is important for the offline remapping workflow if you want to run some parallel jobs with mbtempest. I see that I originally added metis as dependency in the vijaysm-mbpart branch but never merged it.

@vijaysm,

Can you also add a dependency on metis ? This would ensure we have a partitioner available as well during the build.

You added this to host in the branch I just deleted.  Are you sure that's what you want?  Is it used in the process of building the package or should it be installed along with the package or both?

I made the following changes after uploading a fix to our ftp site. My local builds with OpenMPI finished cleanly on Linux.
diff --git a/recipe/meta.yaml b/recipe/meta.yaml
index 51f9e00..161389b 100644
--- a/recipe/meta.yaml
+++ b/recipe/meta.yaml
@@ -19,8 +19,10 @@ package:

 source:
   fn: {{ name }}-{{ version }}.tar.gz
-  url: http://ftp.mcs.anl.gov/pub/fathom/{{ name }}-{{ version }}.tar.gz
-  sha256: 805ed3546deff39e076be4d1f68aba1cf0dda8c34ce43e1fc179d1aff57c5d5d
+  #url: http://ftp.mcs.anl.gov/pub/fathom/{{ name }}-{{ version }}.tar.gz
+  #sha256: 805ed3546deff39e076be4d1f68aba1cf0dda8c34ce43e1fc179d1aff57c5d5d
+  url: http://ftp.mcs.anl.gov/pub/fathom/moab-conda-test.tar.gz
+  sha256: 53ec6efe5e943d7342216068e86869a4f6392e0fc24ab00158c9e4310b2dbe18

 build:
   number: {{ build }}

I also noticed a minor warning during the build/install stage.
WARNING (moab,lib/libMOAB.so.5.0.2): Needed DSO lib/libopenblas.so.0 found in ['libopenblas']
WARNING (moab,lib/libMOAB.so.5.0.2): .. but ['libopenblas'] not in reqs/run, (i.e. it is overlinking) (likely) or a missing dependency (less likely)

Two things here.

Why is the MOAB library version 5.0.2 instead of 5.2.0 ?
We should add libopenblas as a dependency for Linux.

Why is the MOAB library version 5.0.2 instead of 5.2.0 ?

That's definitely not one I can answer.  I'd grep the code to see if there's a typo somewhere.

We should add libopenblas as a dependency for Linux.

Okay, good, I'll add that.

@conda-forge-admin, please rerender

What build options results in a BLAS dependency?  Does the METIS options require that?

@conda-forge-admin, please rerender

No TempestRemap has an explicit BLAS dependency. @xylar we should probably
add this only for the TR build variants. Pure MOAB can be built with just
eigen. This is an important requirement especially for Windows and to
negate a need for Fortran compilers on certain machines.
On Mon, Jul 20, 2020 at 3:48 PM Paul Wilson notifications@github.com
wrote:

What build options results in a BLAS dependency? Does the METIS options
require that?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/conda-forge/moab-feedstock/pull/34#issuecomment-661297499,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACVEPKKAMRM5BSQ5ME4HW3R4SNSLANCNFSM4PCDTBAQ
.

No TempestRemap has an explicit BLAS dependency. @xylar we should probably
add this only for the TR build variants. Pure MOAB can be built with just
eigen. This is an important requirement especially for Windows and to
negate a need for Fortran compilers on certain machines.

It sounds like this is a missing dependency from the tempest-remap package itself, then, not just the local build?

libblas is a tempest-remap dependency already (not openblas specifically, though).  So maybe that is the issue?

Pure MOAB can be built with just eigen.

We're definitely not building with just eigen right now when we build without tempest.

This is an important requirement especially for Windows and to negate a need for Fortran compilers on certain machines.

We're not doing a windows build right now.  Is that something you want to start doing?

@conda-forge-admin, please rerender

I definitely think Paul and few other users will be interested in Windows
builds if we can get that working. A serial variant may suffice IMO for
now. We haven't fully tested MOAB on Windows+MPI and so I don't want to add
this and have to go through a whole lot of changes to get the stack working
in this PR.
On Mon., Jul. 20, 2020, 16:11 Xylar Asay-Davis, notifications@github.com
wrote:

Pure MOAB can be built with just eigen.
We're definitely not building with just eigen right now when we build
without tempest.
This is an important requirement especially for Windows and to negate a
need for Fortran compilers on certain machines.
We're not doing a windows build right now. Is that something you want to
start doing?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/conda-forge/moab-feedstock/pull/34#issuecomment-661308121,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACVEPKUUT64B5ZJ22HUBXLR4SQH7ANCNFSM4PCDTBAQ
.

As much as I'm interested in a Windows build, I'd recommend leaving that for a different PR....

@xylar The changes are looking good. I don't understand the failing builds. That looks like some internal network issue. I'll relaunch the job.

@conda-forge-admin, please rerender

@conda-forge-admin, please rerender

Everything seems to be building.  Let me know what you want to do about enabling/disabling BLAS/LAPACK.  FYI, it comes in at runtime regardless through dependency on numpy.  So if there's not a clear advantage in disabling it, I would suggest keeping it enabled.

In retrospect, whether or not BLAS/LAPACK is enabled doesn't matter much if it all works here.  In my experience the BLAS/LAPACK dependency of MOAB itself can be troublesome when trying to port to different systems with a build from source, but the point of this is to avoid that.

Okay, in that case, I think we should go back to having BLAS/LAPACK support for all builds.  @gonuke, I sympathize with your reasoning -- fewer dependencies is often better when you have to build a thing from source -- but that's kind of the point of conda-forge as you realize.

@conda-forge-admin, please rerender

@conda-forge-admin, please rerender

@vijaysm, I think we're good here.  You can make your minor release whenever you're ready and I'll make the corresponding PR.

In the future, we ca create a dev branch and if you create a release candidate with a bit more notice, I can build packages for it on a moab_dev label.  That way, we can actually run some tests with with it outside of CI.  But I don't think it makes sense to do that in this case.

Thanks @xylar

In the future, we ca create a dev branch and if you create a release candidate with a bit more notice, I can build packages for it on a moab_dev label. That way, we can actually run some tests with with it outside of CI. But I don't think it makes sense to do that in this case.

Yes we should have done that this time. We were making sure that the tarball was consistent and I forgot about the conda compatibility before the actual release. There are some things that we want to merge soon and so a minor release in the next week or so makes sense to us anyway. And we will make sure the conda meta gets tested and updated before the next release.

@vijaysm has the minor release happened already and I missed it?

@xylar we have a performance update PR for mbtempest waiting review. Will
release after that is finished.
On Sat., Aug. 8, 2020, 07:39 Xylar Asay-Davis, notifications@github.com
wrote:

@vijaysm https://github.com/vijaysm has the minor release happened
already and I missed it?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/conda-forge/moab-feedstock/pull/34#issuecomment-670918945,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACVEPOGUUWCCMTTKF5Q4E3R7U2PNANCNFSM4PCDTBAQ
.

authors: conda-forge-linter gonuke vijaysm xylar

repo: conda-forge/moab-feedstock


text:
Release v0.1.8

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

authors: cheginit conda-forge-linter

repo: conda-forge/pygeoutils-feedstock


text:
Update to v1.9.0 (no release on PyPI yet!)

There is currently no v1.9.0 sdist on PyPI, but I requested it be uploaded: https://github.com/FlorianRhiem/pyGLFW/issues/40
Until then, fetch sources from GitHub.

Checklist

[x] Used a fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-webservice.
I tried to re-render for you but ran into some issues, please ping conda-forge/core for further assistance. You can also try re-rendering locally.

Ok I proposed a change upstream: https://github.com/FlorianRhiem/pyGLFW/pull/41

authors: conda-forge-linter hoechenberger

repo: conda-forge/pyglfw-feedstock


text:
[ci skip] [cf admin skip] NO_CI adding bot automerge

Hi! This is the friendly automated conda-forge-webservice.
I've added bot automerge as instructed in #1.
Merge this PR to enable bot automerging.
Fixes #1

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

repo: conda-forge/pyroll-report-feedstock


text:
QE 7.2 bump

Checklist

[x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Based on https://github.com/conda-forge/qe-feedstock/pull/38 try to pin the compiler version again.

@conda-forge-admin, please rerender

@conda-forge-admin, please rerender

Test result linux
Total Test time (real) = 2080.94 sec

The following tests FAILED:
	211 - system--pw_relax-correctness (Failed)
	317 - system--pw_workflow_vc-relax_scf-correctness (Failed)

Test result macos
Total Test time (real) = 2474.92 sec

The following tests FAILED:
	 35 - test_qe_lapack_zdotc (Failed)
	165 - system--pw_metaGGA-correctness (Failed)
	211 - system--pw_relax-correctness (Failed)
	219 - system--pw_scf-correctness (Failed)
	297 - system--pw_workflow_exx_nscf-correctness (Failed)
	317 - system--pw_workflow_vc-relax_scf-correctness (Failed)

authors: ltalirz unkcpz

repo: conda-forge/qe-feedstock


text:
Update LTR Branch to 3.22.13

Checklist

[x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

@conda-forge-admin, please rerender

Merged all commits from main (3.28.1) into the LTR branch. Downgraded qgis version and local pinning. Cleaned up some patches.

@SrNetoChan are you going to pin gdal like this: https://github.com/conda-forge/qgis-feedstock/pull/275#pullrequestreview-1205700362 ?

Oh! I forgot about this. I can try. Let's just see if it builds until now.

Oh it didn't work. I will try it tomorrow.

@gillins do you think this kind of min and max pinning will work in the local pinning? Does it make any sense?
Also, from that recommendation seems that we really want gdal > 3.6, which seems to be the problem with the failing builds.

Should work with local pinning, I think you need to have:
- {{ pin_compatible('gdal', max_pin='x.x') }}
- {{ pin_compatible('libgdal', max_pin='x.x') }}

In the meta.yaml (instead of gdal and libgdal), but I'm no expert. @weiji14 may be able to advise?

So I tried pinning gdal to 3.5 in the conda_build_config, and it seems to be ignored. The build start using gdal 3.6 instead.

Let's see how it goes...

Python 3.11 are failing, which makes sense since older version of the dependencies were not built for it. I wonder if we remove 3.11 from the LTR recipe, or we just give up on the pinning for now...

Sigh. Yes maybe give up on the pinning for now, it does seem to be too hard.

Is there a way to rerun just the OSX python 3.8 build?

Not sure, I can't see a way but I thought i'd done something like this before. Seems to be running now...

Not sure, I can't see a way but I thought i'd done something like this before. Seems to be running now...

@gillins it's possible to do it in the checks tab. Found after asking. I was trying directly on Azure

I will merge this (as it's working) and then do cleaning.

@gillins any idea why the packages are not appearing on conda channel?
I remember there's a place to see the merged recipes being built and uploaded to the channel, but can't remember where.

https://dev.azure.com/conda-forge/feedstock-builds/_build?definitionId=4674&_a=summary - seems like the most recent build succeeded?

Indeed. But no packages on anaconda... @ocefpaf any idea of what may have happened?

authors: SrNetoChan conda-forge-linter gillins

repo: conda-forge/qgis-feedstock


text:
Update recipe + Rebuild for Python 3.7, GCC 7, R 3.5.1, openBLAS 0.3.2

Checklist

[ ] Used a fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.
Here's what I've got...
For recipe:

Using toolchain directly in this manner is deprecated.  Consider using the compilers outlined here.

gcc7 label required for r-naturalsort

Done.

Ready to merge

authors: bgruening conda-forge-linter dbast

repo: conda-forge/r-castor-feedstock


text:
DM-34610: Update rubin-env to v4 and add rubin-env-extras (dev branch).

Still python 3.10.
Add PyLD, skyproj.
Add rubin-env-extras output including packages from sciplat-lab,
shared_stack, sims, and add in imagemagick and ffmpeg.
Update cfitsio to 4.1.0 and flake8 to 4.0.

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

@conda-forge-admin, please rerender

I think the conda forge python 3.10 numpy pin is at 1.21.

But I still fully don't understand how the numpy pinning works.

@conda-forge-admin, please rerender

@conda-forge-admin, please rerender

@conda-forge-admin, please rerender

Late-breaking update!  I poked the george py310 migration last night, which got Dan Foreman-Mackey's attention and he fixed it promptly:  https://github.com/conda-forge/george-feedstock/pull/15. I checked and it appears to be available now.  (But note that it is not available on osx-arm64 or aarch64).

george isn't compatible with aarch64.  Nor is it compatible with osx-arm64, but we don't actually test anything with osx-arm64 since it's a cross-build, so that just disappears into the ether.

authors: erykoff ktlim

repo: conda-forge/rubinenv-feedstock


text:
Document how we choose the runtime dependencies

and check that Sage actually starts (as we claim in the comment)

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

authors: conda-forge-linter saraedum

repo: conda-forge/sagelib-feedstock


text:
Update to smbus2 v0.4.0

Checklist

[X] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

I released a new version of smbus2 today on PyPi. It's readme includes conda-forge as install option now :). Figured it would be feasible to tick up the conda-forge recipe to build 0.4.0 too.
As a conda-forge noob, I didn't quite catch the build/number instructions... Sorry, but you guys need to take over from here.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe:

noarch: python recipes are recommended to have a lower bound on the python version. This recommendation will become a requirement in the future.

Hey @kplindegaard
There is a bot that automatically comes around to make PRs to this repo (see #2) (a little slower, but handles all the build number stuff/rerendering automatically, though does not automatically make changes to e.g. dependencies and such)
I'm going to close this PR as the bot did come around. That said you did do the right thing (at least the manual step).
If you are interested in getting merge rights to this repo, I believe all I have to do is add your gh username to the maintainers section in the recipe.yml (then more automated infrastructure comes in and adds you to the repo).
Let me know, perfectly happy to do so.

HI,
Thanks for reaching out. If it's OK with you I will politely decline that
offer if that's OK. Too much stuff going on my life right now, and I don't
think there will be a new smbus2 release anytime soon anyway.
KP
On Sun, Dec 6, 2020 at 1:05 AM Kyle Sunden notifications@github.com wrote:

Hey @kplindegaard https://github.com/kplindegaard
There is a bot that automatically comes around to make PRs to this repo
(see #2 https://github.com/conda-forge/smbus2-feedstock/pull/2) (a
little slower, but handles all the build number stuff/rerendering
automatically, though does not automatically make changes to e.g.
dependencies and such)
I'm going to close this PR as the bot did come around. That said you did
do the right thing (at least the manual step).
If you are interested in getting merge rights to this repo, I believe all
I have to do is add your gh username to the maintainers section in the
recipe.yml (then more automated infrastructure comes in and adds you to the
repo).
Let me know, perfectly happy to do so.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/conda-forge/smbus2-feedstock/pull/1#issuecomment-739433559,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABL6MR3VZ2TQUYQPTRMLYMLSTLDENANCNFSM4UOXGWLQ
.

authors: conda-forge-linter kplindegaard ksunden


text:
ppc64le timeouts

Currently, there is no way to increase the 50min build time for ppc64le.
Besides trying to reduce the build time on the app time with long-term build variant unification for geometries, splitting out AMReX in its own package (with many, many incompatible build variants) there is another way:
Cross-compile from x86 via setting the build platform: https://conda-forge.org/docs/maintainer/conda_forge_yml.html?highlight=cross compile#build-platform
Example feedstock doing this: https://github.com/conda-forge/clangdev-feedstock

Implementing cross-compilation needs PRs to BLAS++ and LAPACK++, which currently have try_compile components in their build logic that does not work out-of-the-box for cross-compilation workflows.

Solved via #33

source: gharchive/issue

repo: conda-forge/warpx-feedstock


text:
Remove old requirement restricts

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

authors: conda-forge-linter gsheni

repo: conda-forge/woodwork-feedstock


text:
Fix Broken Links on Synced Docs

HOW_WE_USE_GITHUB is not rendering labels properly:

The RELEASE document is also not rendering links properly:

Not sure why the jinja syntax isn't working here, but I've changed the links to be either relative file paths or links that point to the conda/infrastructure repository so that the links show up properly while we figure out how to populate specific repositories via a variable.

Note: a previously committed change will now be done in another PR (if necessary), waiting for the work being done in this PR to get merged

The RELEASE document is also not rendering links properly:

Not sure why the jinja syntax isn't working here, but I've changed the links to be either relative file paths or links that point to the conda/infrastructure repository so that the links show up properly while we figure out how to populate specific repositories via a variable.

repo: conda/infrastructure


text:
add logs to the task result

Add logs to the task result and change the log message from info to error in case of an exception during the task execution.

Just pulled and execute locally - integration tests running fine :)
(failed due to missing secrets at forked repo)

repo: conductor-sdk/conductor-python


text:
e2e: enable more than one pod in one test case

Enable test framework to support more than one pod in one test case
Fixes: https://github.com/confidential-containers/cloud-api-adaptor/issues/16

The case is tested against self managed cluster on ibmcloud. Test log as below.
INFO[0000] IamServiceURL is: https://iam.cloud.ibm.com/identity/token.
INFO[0000] VpcServiceURL is: https://jp-tok.iaas.cloud.ibm.com/v1.
INFO[0000] IksServiceURL is: https://containers.cloud.ibm.com/global.
INFO[0000] [warning] SSH_KEY_ID was not set.
INFO[0000] Do setup
=== RUN   TestExtraPods
=== RUN   TestExtraPods/TestExtraPods_test
    assessment_runner_test.go:247: Waiting for containers in pod: nginx are ready
INFO[0042] webserver service is available on cluster IP: None
Provision extra pod busybox    assessment_helpers_test.go:402: Waiting for containers in pod: busybox are ready
=== RUN   TestExtraPods/TestExtraPods_test/Failed_to_test_extra_pod.
INFO[0078] PodVM name: nginx
INFO[0087] Success to access nginx service. <!DOCTYPE html>

<title>Welcome to nginx!</title>

Welcome to nginx!

If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.

For online documentation and support please refer to
nginx.org.

Commercial support is available at
nginx.com.

Thank you for using nginx.

    assessment_runner_test.go:463: Output when execute test commands:
INFO[0087] PodVM name: busybox
INFO[0089] Deleting pod nginx...
INFO[0094] Pod nginx has been successfully deleted within 60s
INFO[0094] Deleting pod busybox...
INFO[0099] Pod busybox has been successfully deleted within 60s
INFO[0100] Deleting Service... nginx
--- PASS: TestExtraPods (99.69s)
    --- PASS: TestExtraPods/TestExtraPods_test (99.69s)
        --- PASS: TestExtraPods/TestExtraPods_test/Failed_to_test_extra_pod. (11.14s)
PASS
ok  	github.com/confidential-containers/cloud-api-adaptor/test/e2e	100.872s


text:
DO NOT MERGE Add threat model docs

Addresses issues https://github.com/confidential-containers/confidentialcontainers.org/issues/24 and https://github.com/confidential-containers/confidentialcontainers.org/issues/25
Also pulls in the threads-overview file:
https://github.com/confidential-containers/confidential-containers/blob/main/threats_overview.md
PR to remove these docs from confidential-containers: https://github.com/confidential-containers/confidential-containers/pull/190

Hi @surajssd,
I threw the threat docs under Overview; maybe double-check that that seems reasonable.
Also, I tried two different ways of displaying the personas_model.svg (see here for how it used to look). With the svg file in static/, both of these lines work on a local docker compose up test:
![Persona model](/persona_model.svg)
<img src="images/persona_model.svg">
But neither are showing in the netlify preview. Any advice welcome.

@portersrc the svg file is invalid.

Yuck. Good catch. It seems to be displaying properly now. Thanks!

I wonder if the Container Image Provider persona is tied too much to the assumption that users will deploy encrypted/signed container images and should be revisited. There is no mention of secure key-release at runtime, for example. Maybe it can be generalized into a "Secret Provider" persona, i.e. someone who manages secrets?

I don't think you're wrong here. That also would affect the personas diagram. I'm OK with updating that or leaving as-is. @magowan any thoughts on this (because I think you supplied a lot of the initial ideas here)?

@portersrc @mkulke can we merge this? or we are waiting on something?

I think we're OK to merge. @mkulke indeed raised follow-up issues:
https://github.com/confidential-containers/confidential-containers/issues/194
https://github.com/confidential-containers/confidential-containers/issues/195
I will bump the PR in the main repo if/when you merge this.

authors: portersrc surajssd


text:
KBS: fix session status

When an attested session sends a new attest request, the session should not do anything else but only return the old token if it is still valid.
Close #374

Changes look fine, but why are we calling the /attest endpoint multiple times in the first place? Shouldn't this only happen once per guest/token?

Yes. For normal cases, attest endpoint would be called only once. But due to network error, retry from client (async) or some unexpected reason, one or more duplicated requests could reach. The error reported by @ChengyuZhu6 is caught when doing performance test, but I think it should be treated more gerenicly. We should better promote the robust of the code.

repo: confidential-containers/trustee


text:
Fix broken SE link

The refactor of the repository broke this link.
We also have some issues with rustup not being available on the az runners. I wasn't sure if we should add rustup installation to the tests or do it locally. wdyt @mkulke

yup I made a fix in #438

authors: fitzthum mkulke


text:
Implement aliases Property for Cfgu Declaration

Description
Introduce an aliases property to the Cfgu declaration. This property, represented as an array of strings, will enable users to reference a single configuration by multiple alias names. When performing an upsert, users can utilize any of the aliases. Meanwhile, during an eval, all associated aliases will return the same value.
{
  ...
  "MY_EMAIL": {
    "type": "Email",
    "aliases": ["myEmail", "EMAIL", ...]
  }
  ...
}

Motivation
To enhance the flexibility and usability of the Cfgu declaration by allowing multiple reference points for a single configuration.
Additional context

Can u assign me this issue . Thank you

@rannn505
could you please assign me this issue.

Hi @Aman1919, I'll clarify the requirements for you:
Schema validations
The inclusion of this new Cfgu property needs to include the following suite of validations:

Aliases must not conflict with other schema keys or aliases belonging to other schema keys.
Aliases must be of type array.
An alias cannot be an empty string.
An alias must conform to the same validations as config keys (no reserved words, invalid characters, etc...). The existing key validations can be reused for this.

The parse method of the ConfigSchema class should handle this.
Examples:
Valid schema
{
  ...
  "MY_EMAIL": {
    "type": "Email",
    "aliases": ["myEmail", "EMAIL"]
  }
  ...
}

Invalid schema - alias conflicting with another key:
{
  ...
  "MY_EMAIL": {
    "type": "Email",
    "aliases": ["myEmail", "EMAIL"]
  }
 "EMAIL": {
    "type": "Email"
  }
  ...
}

Invalid schema - alias conflicting with another alias:
{
  ...
  "MY_EMAIL": {
    "type": "Email",
    "aliases": ["myEmail", "EMAIL"]
  }
 "SUPPORT_EMAIL": {
    "type": "Email",
    "aliases": ["EMAIL"]
  }
  ...
}

Upsert
When performing an upsert, any of the aliases of a specific key can be used to perform the upsert. The upsert command should identify the key that the alias correlates to and then complete the upsert using the original key. The upsert command needs to validate that only a single alias can be provided per key AND that the key cannot be provided together with the alias, this is to keep the upsert deterministic.
Given this schema:
{
  ...
  "MY_EMAIL": {
    "type": "Email",
    "aliases": ["myEmail", "EMAIL"]
  }
  ...
}

Upserting with only one of MY_EMAIL, myEmail, or EMAIL is valid.
Upserting with more than one of any of the above is invalid.

Eval
When performing an eval, the aliases of any specific key should also be present in the eval result with their value corresponding to the value of their original key.
Given this schema:
{
  ...
  "MY_EMAIL": {
    "type": "Email",
    "aliases": ["myEmail", "EMAIL"]
  }
  ...
}

And given that the evaluated value of MY_EMAIL is SOME_VALUE, the resulting eval should be:
{
  ...
  "MY_EMAIL": "SOME_VALUE",
  "myEmail": "SOME_VALUE",
  "EMAIL": "SOME_VALUE",
  ...
}

You can also take a look at an excellent PR that implemented the options Cfgu to draw inspiration for implementation details.
Hope this clarifies everything. Let me know if you need any further clarification.

@RichardAkman Could u review the pr I changed the ts file first . If this commit is ok then I'll update other files

Can you please assign me the issue?

repo: configu/configu


text:
CC-25311: Bump postgresql driver version to 42.6.1

https://confluentinc.atlassian.net/browse/CC-25311

The build has been failing for these two tests across different runs:
io.debezium.connector.postgresql.RecordsSnapshotParallelProducerIT.shouldGenerateSnapshotAndContinueStreaming
io.debezium.connector.sqlserver.IncrementalSnapshotWithRecompileIT.stopCurrentIncrementalSnapshotWithoutCollectionsAndTakeNewNewIncrementalSnapshotAfterRestart
Both seems flaky as they are passing when ran locally. But somehow failing in the build.

repo: confluentinc/debezium


text:
Can we do dynamic rewind in setting offset to earlier point on the fly?

We used to do something like
doRewind(topicAndTime); // reset offset based on the topic and partition
kafkaConsumer.poll(getPollTimeMillis());

however, based on the parallel-consumer's architecture diagram, there is a work state management. We're not sure if we can directly manage that. Could you please advice? Is there any way that we can update the offset on the fly while the consumers are still consuming messages?
Note: our consumer has self-protection mechanism to process "new" data only, so no concern to us to do so in real time.

https://github.com/confluentinc/parallel-consumer/issues/782 covered

repo: confluentinc/parallel-consumer


text:
[feature/setting] 0-5

commit convention 정한대로 commitlint를 설정하였습니다.
code convention에 맞춰 eslint를 설정하였습니다.
create-react-app으로 client 생성하였습니다.

문제없이 적용됨.

VSCode의 eslint extension 재설치하니 잘 작동되네요!
수고하셨습니다!!

authors: bellaah gyustar young-do

license: MIT


text:
Allow keeping original method names

Is your feature request related to a problem? Please describe.
protoc-gen-connect-es always turns the first character of a method name to lower case. While this might make sense for some names (e.g. GenerateThing => generateThing) it makes the names really weird when there are multiple uppercase letters at the front. This is fairly common when the names start with a Group/Type (e.g. IPBanAdd, which turns into iPBanAdd).
Describe the solution you'd like
I think there should be an option to tell protoc-gen-connect-es to just keep the name as it is (like it does for messages and services).
Describe alternatives you've considered
Additional context
The name change happens because of a call to localName here, which calls results in this code returning the mangled name.

Casing of message and service names is left alone because it's best practice to use PascalCase for them in Protobuf and in ECMAScript.
Function and method names are lowerCamelCase in ECMAScript, but it's best practice to use PascalCase in Protobuf. It would be confusing to users to see an object method start with an uppercase letter.
The same applies to Java. A Protobuf RPC IPBanAdd will generate a Java gRPC client method iPBanAdd. The best way to avoid this problem is to capitalize abbreviations as a single word, like the style guide on protobuf.dev recommends.
The good news: It's trivial to write your own plugin for your use case - it's just 50 LoC if you settle on TypeScript output, and you don't have to publish it on npmjs.com to work (see the example here).

The good news: It's trivial to write your own plugin for your use case - it's just 50 LoC if you settle on TypeScript output

Which is what I already did, I just thought a general option to make the output similar between the reference implementation in C++ and Typescript might be useful to others. I guess its not ;)

authors: Thalhammer timostamm

repo: connectrpc/connect-es


text:
Deprecate @bufbuild/* packages

Is your feature request related to a problem? Please describe.
The @bufbuild/connect-* packages still exist on the npm registry and there's no indication of or reference to the new @connectrpc/* packages there. This means that people who usually regularly run pnpm update -irL will not see that updates are indeed happening, just under a different package name ;-)
Describe the solution you'd like
Tag the @bufbuild/connect-* packages as deprecated with a hint pointing at their successor(s).

Good call 🙂
Within the last week, a good chunk of users moved from @bufbuild/connect@0.13.0 to @connectrpc/connect. We want to ride that momentum for a bit, but definitely deprecated the old names soon.

All Connect packages in the @bufbuild scope have just been deprecated.
To switch to the new scope @connectrpc, you can run npx @connectrpc/connect-migrate@latest. For details, see https://github.com/connectrpc/connect-es/releases/tag/v0.13.1

authors: fubhy timostamm


text:
incorrect balance error bridging receive nextAsset

I saw this error on every destination chain. It also didnt load certain fees.  When I refreshed and came back it went away

Choose Ethereum
Choose receive next asset
See error
Change destination chain
See error still

working for me, cannot seem to repro

is your wallet connected? @alexwhte

This could be because of some issue on BSC RPC. Changed the RPC.

LGTM too, @alexwhte to confirm your side?

authors: alexwhte jakekidd just-a-node pjenviri

repo: connext/monorepo


text:
V2 FW/HW receiver finds no candidates

Not yet sure if this is a fw or a hw problem

Executing the V2.00 firmware (modified to set WIRE_ETC as Wire, and to disable process_touch()) found only 1 candidate out of 20 receive cycles on 7074.  The problem appears to be hardware independent.

V1.10 also fails to decode FT8 traffic on V1.10 hw.  But... the waterfall displayed a couple traces today on V1.10.

Teensy library update replaces the modified AudioStream.h file containing the Pocket FT8 requirement for a 6400 samples/second rate.


text:
Create 0xb414f8ec2d14c64f37.jsonb1559cbe43746284514596

为确保 Token Profile 的顺利通过，务必逐一确保以下检查项并补充项目资料：
.json 及 .png 文件检查项

[x] logo 尺寸：120*120 px
[ ] logo 背景：透明
[ ] 代币有至少一笔成功的转账记录
[ ] 此项对于 ERC-20 项目方：合约地址有大小写（做 checksum）
[ ] .json 和 .png 文件名一致（包括大小写）

项目资料：
官方公告：
团队背景：
项目基本情况：
媒体报道：
收录的交易所：
转账所需 Gas Limit（对 ERC-20 项目方）：（默认为 60000）

Please check the following to ensure a successful verification of Token Profile
.json and .png document checklists

[x] logo dimensions: 120*120 px
[ ] logo background: Transparent
[ ] At least one transaction on the token contract
[ ] For ERC-20 project teams: Upper and lower capitalized alphabets in token address (For checksum purposes)
[ ] Same document name for both .json and .png (Including capitalization)

Project background:
Official announcement:
Project team background:
Project basic information:
Media publications:
Tradeable exchanges:
Recommended Gas Limit (For ERC-20 project teams) for transaction: (Default is 60,000)

非常抱歉，请参考教程提供更多项目相关内容

repo: consenlabs/token-profile


text:
Added info

Hoping you will approve our request as soon as possible.

你好，提交的格式有误，请认真阅读相关说明内容，为了不影响其他项目审核进度，再次提交的项目，将在下一个周期审核通过，感谢你的支持，谢谢。

authors: ronealdenila wenyanwang


text:
🛑 collectionrevue.com is down

In b14ca0f, collectionrevue.com (https://collectionrevue.com) was down:

HTTP code: 520
Response time: 10884 ms

Resolved: collectionrevue.com is back up in 1e67b38.

repo: constructions-incongrues/status


text:
🛑 tdm.incongru.org is down

In 9de5ccb, tdm.incongru.org (https://tdm.incongru.org) was down:

HTTP code: 503
Response time: 27024 ms

Resolved: tdm.incongru.org is back up in aebe23f after 2 minutes.


text:
🛑 Mazemod is down

In 0d0af7b, Mazemod (https://www.mazemod.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Mazemod is back up in 98f1efc after 2 hours, 11 minutes.


text:
[Unity3D Project C#] Upon typing the 1st character, it starts loading for 2 seconds before IDE responds.

It looks like Consulo is trying to find the references of related characters for autocompletion.
Is it just me or you are also experiencing this issue?
I am using Macbook Pro mid-2014 model, Yosemite.
My project has more than 50 CS files inside Assembly-CSharp, including a Spine-csharp library.

Please read this: https://github.com/consulo/consulo/wiki/Frequently-Asked-Questions

Thanks for your quick reply. I didn't look through carefully.

Np. Try and notify me about results

I found that in my Consolas /content   the file is called: idea.vmoptions

Set to 2048MB, Much Faster!

Thanks, name 'idea' is legacy(forgot to change it on mac)
Sorry for that, .NET impl is not optimized too much.

authors: VISTALL VansonLeung

repo: consulo/consulo

license_source: bigquery


text:
feat!: move files from buildpack to containerbase

Files are moved

/usr/local/buildpack to /usr/local/containerbase
/opt/buildpack to /opt/containerbase

/usr/local/containerbase will contain the tools and bash scripts.
/opt/containerbase will contain the generated files and installed tools.

closes #826

BREAKING CHANGE: Containerbase files are moved, so check custom image samples for required changes

Tools are still installed to /opt/buildpack because of overlapping folders 😕

Can you explain more? I was hoping to remove all buildpack remnants

will do another change.
source bash scripts and tools will be put to /usr/local/containerbase which is only writable by root and installed tools and other generated files to /opt/containerbase, which is writable by our custom user.

@rarkins I've moved files again, see PR description. #1016 will be ladst buildpack piece which get's removed in the following major (probably v9)

authors: rarkins viceice

repo: containerbase/base


text:
Don't show hide files magic in Dockerfile inside image in /root/build…

…info/

OSBS-7865

Signed-off-by: Robert Cerven rcerven@redhat.com

rn updated

Don't show hide files magic in Dockerfile inside image in /root/buildinfo/

repo: containerbuildsystem/osbs-client


text:
oci: fix the file mode of the device

The file mode of the device in the OCI runtime specification does not contain file type bits
unix.Stat_t.Mode contains the file type and mode，details are in "The file type and mode" section of inode
This issue causes some config.json to fail the runtime spec schema validation
For example, the config.json for the kube-proxy container
devices:
    [
            {
                "path":"/dev/sda",
                "type":"b",
                "major":8,
                "minor":0,
                "fileMode":25008,
                "uid":0,
                "gid":6
            },
           {
                "path":"/dev/null",
                "type":"c",
                "major":1,
                "minor":3,
                "fileMode":8630,
                "uid":0,
                "gid":0
            },
            {
                "path":"/dev/tty0",
                "type":"c",
                "major":4,
                "minor":0,
                "fileMode":8592,
                "uid":0,
                "gid":5
            },
            ...
    ]

Discussions about FileMode: https://github.com/opencontainers/runtime-spec/pull/1082

@AkihiroSuda does libcontainer/devices.DeviceFromPath need a similar change?

@thaJeztah @AkihiroSuda runc may be modified in more places
eg. https://github.com/opencontainers/runc/blob/master/libcontainer/rootfs_linux.go#L663
# libcontainer/devices/device.go
type Device struct {
        Rule

        // Path to the device.
        Path string `json:"path"`

        // FileMode permission bits for the device.
        FileMode os.FileMode `json:"file_mode"`

        // Uid of the device.
        Uid uint32 `json:"uid"`

        // Gid of the device.
        Gid uint32 `json:"gid"`
}

mode &^ unix.S_IFMT should be added when setting device.FileMode.

I'm going to try to fix this issue in runc

I'm going to try to fix this issue in runc

Thank you!

@thaJeztah https://github.com/opencontainers/runc/pull/2804 is approved, pls review.

@AkihiroSuda PTAL, Thanks

@AkihiroSuda Is it necessary to fix the previous version?

I'd prefer not to backport this unless there is a strong reason

This issue was found in the use of 1.2.10, the essence of the issue is that it does not comply with the OCI runtime specification, fixing the previous version may make sense
Of course, this issue does not cause program anomalies, but may cause confusion in the use of

authors: AkihiroSuda Iceber thaJeztah

repo: containerd/containerd


text:
Move historical docs to docs/.historical

To clarify that end users do not need to read these docs, and that these docs do not need to be updated

RFC: do we want to move https://github.com/containerd/containerd/tree/main/design too ? (Last update was 2018)

If these are outdated and no longer useful, why not to just remove them? We have Git to keep history.

Changed the dir to docs/historical.

If these are outdated and no longer useful, why not to just remove them? We have Git to keep history.

For historians 😃
We can consider removing most of them, though.

authors: AkihiroSuda mxpv


text:
Clean CI yaml

Signed-off-by: Maksym Pavlenko pavlenko.maksym@gmail.com

Why can the code in github/workflows/ci.yml be safely deleted?

@sbuckfelder containerd no longer needs to be in GOPATH to produce binaries.
It's in the past for a while.
The only place we still need it is protobuf code generator.

Re-running failed jobs...

Rebased against main to include changes from https://github.com/containerd/containerd/pull/8074

authors: kzys mxpv


text:
runtime/shim: rename RunManager to Run and remove runc/v2/services package

According to the 2.0 removal plan:

remove shim.Run and rename shim.RunManager to shim.Run
delete ID and ContainerdBinary fields from StartOpts
remove runc/v2/services package

@mxpv PTAL, Thanks

@dmcgowan PTAL as well.

authors: Iceber mxpv


text:
Bind mount throws error if the directory does not exit beforehand

Description
Discussed in https://github.com/rancher-sandbox/rancher-desktop/issues/3603
Hello
I am running nerdctl on windows, using rancher desktop version 1.6.2.
I have a simple compose file with directory mounts, nothing fancy just a mysql container.
services:
  mysql_db:
    image: mysql:8.0.30
    restart: always
    volumes:
      - ./mysql_db_data:/var/lib/mysql
      - ./mysql_db_config:/etc/mysql/conf.d
    environment:
      - MYSQL_DATABASE=keycloak
      - MYSQL_ROOT_PASSWORD=root_password
      - MYSQL_USER=db_user
      - MYSQL_PASSWORD=db_password
      - TZ=Asia/Tokyo

But nerdctl compose up fails if I run without the mount directory manually first. The output I get with --debug option is as follow
WARN[0000] Ignoring: volume: Bind: [CreateHostPath]
WARN[0000] Ignoring: volume: Bind: [CreateHostPath]
INFO[0000] Ensuring image mysql:8.0.30
DEBU[0000] filters: [labels."com.docker.compose.project"==20221213githubtokenforjenkinsjobincoverity,labels."com.docker.compose.service"==mysql_db]
INFO[0000] Creating container mysql_mysql_db_1
FATA[0000] error while creating container mysql_mysql_db_1: exit status 1

I can run the compose file if I change my container engine to Dockerd/moby and use docker compose up.
If I remove the volume binds I can run the compose file with nerdctl compose up.
nerdctl compose and nerdctl run -v S\should make empty mount directories if those do not already exist like docker compose and docker run -v in windows.
Steps to reproduce the issue

run nerdctl run -v mysql_db_data:/var/lib/mysql mysql:8.0.30 without creaating the mysql_db_data directory in the host.

Or

Run nerdctl compose up with follwing compose file.services:
  mysql_db:
    image: mysql:8.0.30
    restart: always
    volumes:
      - ./mysql_db_data:/var/lib/mysql

Describe the results you received and expected
Recieved
nerdctl run -v mysql_db_data:/var/lib/mysql mysql:8.0.30 fails with following error
FATA[0000] failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "/mnt/c/Users/mirzap/Works Folder/mysql/mysql_db_data" to rootfs at "/var/lib/mysql": stat /mnt/c/Users/mirzap/Works Folder/mysql/mysql_db_data: no such file or directory: unknown

nerdctl compose up fails with following error.
WARN[0000] Ignoring: volume: Bind: [CreateHostPath]
WARN[0000] Ignoring: volume: Bind: [CreateHostPath]
INFO[0000] Ensuring image mysql:8.0.30
DEBU[0000] filters: [labels."com.docker.compose.project"==20221213githubtokenforjenkinsjobincoverity,labels."com.docker.compose.service"==mysql_db]
INFO[0000] Creating container mysql_mysql_db_1
FATA[0000] error while creating container mysql_mysql_db_1: exit status 1

Expected
nerdctl to create the bind mount directory if it does not already exist and container properly starts without any error.
What version of nerdctl are you using?
Client:
Version:       v0.23.0
OS/Arch:       linux/amd64
Git commit:    660680b7ddfde1d38a66ec1c7f08f8d89ab92c68
buildctl:
Version:      v0.10.4
GitCommit:    a2ba6869363812a210fcc3ded6926757ab780b5f
Server:
containerd:
Version:      v1.6.8
GitCommit:    9cd3357b7fd7218e4aec3eae239db1f68a5a6ec6
runc:
Version:      1.1.4
GitCommit:    5fd4c4d144137e991c4acebb2146ab1483a97925
Are you using a variant of nerdctl? (e.g., Rancher Desktop)
Rancher Desktop for Windows
Host information
Client:
Namespace:     default
Debug Mode:    false
Server:
Server Version: v1.6.8
Storage Driver: overlayfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 1
Plugins:
Log: fluentd journald json-file
Storage: native overlayfs
Security Options:
seccomp
Profile: default
Kernel Version: 5.10.16.3-microsoft-standard-WSL2
Operating System: Rancher Desktop WSL Distribution
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 12.24GiB
Name: 11-11569698
ID: 8e7f6d3b-981b-48f3-81ac-40260dd40697

AFAICT bind mounts simply do not work with compose (even if directory exists on the host beforehand). In contrast, nerdctl run will work will bind mounts, if the directory already exists on the host beforehand.

Maybe there are discrepencies in different distribution? I can use bind mount on windows using the nerdctl shipped with RancherDesktop.

Something similar happens if you try to mount a file into a folder that exists but is itself about to be mounted:
$ mkdir folder
$ touch file
$ nerdctl.lima run -it --rm -v "${PWD}/folder:/mnt" -v "${PWD}/file:/mnt/test" ubuntu ls -la /mnt/test
FATA[0000] failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "/Users/administrator/file" to rootfs at "/mnt/test": open /run/containerd/io.containerd.runtime.v2.task/default/00f3d744c2b7f9ae3cc5f130cddfdbc19d31839dfc3201a59b89e65878254bdf/rootfs/mnt/test: read-only file system: unknown
$ docker run -it --rm -v "${PWD}/folder:/mnt" -v "${PWD}/file:/mnt/test" ubuntu ls -la /mnt/test
-rw-r--r-- 1 root root 0 Jan 15 01:01 /mnt/test

authors: iainnicol mirzaprangon saurik

repo: containerd/nerdctl


text:
Update run_test to be more robust

Hey there, I would skip these tests if not supported by the running platform.

Thanks! The changes LGTM but the commit message could be more descriptive.

Thanks! The changes LGTM but the commit message could be more descriptive.

Alright, I changed the message to be a more precise.

/approve

/ok-to-test
LGTM
@baude PTAL

LGTM

Rebased on top of the latest master branch.

authors: TomSweeneyRedHat mheon rhatdan saschagrunert vrothberg

repo: containers/libpod


text:
Reduce Cylomatic Complexity of linter to 15 from 20

Proposal
Reduce:
  [linters-settings.gocyclo]
    min-complexity = 20.0

to
  [linters-settings.gocyclo]
    min-complexity = 15.0

Background
Keeping the cyclo limit low means that we don't have giant functions, but it does slow down early dev, when things are not optimized.

Running this returns only one offending function:
The BuildConfig method in the SMI provider.
Since that function is being worked on for #264, this should be done after.
Blocked by #264

repo: containous/maesh


text:
Enable Ingress Status updates

What does this PR do?
Allows Traefik to update the Status section of Ingress objects either via static IP/Hostname configuration, or via extracting the status section of a fronting service.
Motivation
Fixes #2173
Users requested that the status field be set so that DNS and other discovery tools would work properly.
More

[x] Added/updated tests
[x] Added/updated documentation

Additional Notes
This configuration is entirely optional, and will only apply if one of the 3 configuration settings are enabled.

It's already merged.

Will this be cherry-picked for the older versions?

@anandsinghkunwar we cherry-pick bug fixes only to minimize the risk of affecting otherwise stable releases adversely. Especially in this case, the code delta is quite big.
Traefik 1.7 is on the horizon though, it shouldn't take much longer anymore until we ship.

authors: anandsinghkunwar dtomcej ldez timoreimann

repo: containous/traefik


text:
Backport "Same Configuration Check" from master

Fixes #6626

What does this PR do?
Use the same approach for Same Configuration Check as in master.
Motivation
To fix the bug.
More

[ ] Added/updated tests
[ ] Added/updated documentation

Additional Notes

Do I need to do some extra stuff here to get it merged?


text:
feat: add support for contentful.js v10

Add --v10 option to generate types compatible with contentful.js v10.
Details

Add new renderer for v10 types
Add new renderer for v10 type guards
Update JsDoc renderer to support new skeleton type
Add --v10 option to switch to v10 renderer
Support combining other options with --v10 (except for --localized which is redundant and throws error)

Example output
import type { ChainModifiers, Entry, EntryFieldTypes, EntrySkeletonType, LocaleCode } from "contentful";

export interface TypeAllFieldsFields {
    richText?: EntryFieldTypes.RichText;
    symbol?: EntryFieldTypes.Symbol;
    symbolWithValues?: EntryFieldTypes.Symbol<"option a" | "option b">;
    symbolList?: EntryFieldTypes.Array<EntryFieldTypes.Symbol>;
    symbolListWithValues?: EntryFieldTypes.Array<EntryFieldTypes.Symbol<"option a" | "option b">>;
    text?: EntryFieldTypes.Text;
    textWithValues?: EntryFieldTypes.Text<"option a" | "option b">;
    integer?: EntryFieldTypes.Integer;
    integerWithValues?: EntryFieldTypes.Integer<1 | 2 | 3>;
    decimal?: EntryFieldTypes.Number;
    decimalWithValues?: EntryFieldTypes.Number<1 | 2 | 3>;
    datetime?: EntryFieldTypes.Date;
    location?: EntryFieldTypes.Location;
    media?: EntryFieldTypes.AssetLink;
    mediaList?: EntryFieldTypes.Array<EntryFieldTypes.AssetLink>;
    boolean?: EntryFieldTypes.Boolean;
    json?: EntryFieldTypes.Object;
    reference?: EntryFieldTypes.EntryLink<EntrySkeletonType>;
    referenceWith1Ct?: EntryFieldTypes.EntryLink<TypeLinkedContentType1Skeleton>;
    referenceWith2CTs?: EntryFieldTypes.EntryLink<TypeLinkedContentType1Skeleton | TypeLinkedContentType2Skeleton>;
    referenceList?: EntryFieldTypes.Array<EntryFieldTypes.EntryLink<EntrySkeletonType>>;
    referenceListWith1Ct?: EntryFieldTypes.Array<EntryFieldTypes.EntryLink<TypeLinkedContentType1Skeleton>>;
    referenceListWith2CTs?: EntryFieldTypes.Array<EntryFieldTypes.EntryLink<TypeLinkedContentType1Skeleton | TypeLinkedContentType2Skeleton>>;
    resourceLink?: EntryFieldTypes.EntryResourceLink<EntrySkeletonType>;
}

export type TypeAllFieldsSkeleton = EntrySkeletonType<TypeAllFieldsFields, "allFields">;
export type TypeAllFields<Modifiers extends ChainModifiers, Locales extends LocaleCode> = Entry<TypeAllFieldsSkeleton, Modifiers, Locales>;

export function isTypeAllFields<Modifiers extends ChainModifiers, Locales extends LocaleCode>(entry: Entry<EntrySkeletonType, Modifiers, Locales>): entry is TypeAllFields<Modifiers, Locales> {
    return entry.sys.contentType.sys.id === 'allFields'
}

export interface TypeLinkedContentType1Fields {
    title?: EntryFieldTypes.Symbol;
}

export type TypeLinkedContentType1Skeleton = EntrySkeletonType<TypeLinkedContentType1Fields, "linkedContentType1">;
export type TypeLinkedContentType1<Modifiers extends ChainModifiers, Locales extends LocaleCode> = Entry<TypeLinkedContentType1Skeleton, Modifiers, Locales>;

export function isTypeLinkedContentType1<Modifiers extends ChainModifiers, Locales extends LocaleCode>(entry: Entry<EntrySkeletonType, Modifiers, Locales>): entry is TypeLinkedContentType1<Modifiers, Locales> {
    return entry.sys.contentType.sys.id === 'linkedContentType1'
}

export interface TypeLinkedContentType2Fields {
    title?: EntryFieldTypes.Symbol;
}

export type TypeLinkedContentType2Skeleton = EntrySkeletonType<TypeLinkedContentType2Fields, "linkedContentType2">;
export type TypeLinkedContentType2<Modifiers extends ChainModifiers, Locales extends LocaleCode> = Entry<TypeLinkedContentType2Skeleton, Modifiers, Locales>;

export function isTypeLinkedContentType2<Modifiers extends ChainModifiers, Locales extends LocaleCode>(entry: Entry<EntrySkeletonType, Modifiers, Locales>): entry is TypeLinkedContentType2<Modifiers, Locales> {
    return entry.sys.contentType.sys.id === 'linkedContentType2'
}

Solves #203

authors: marcolink veu


text:
feat: show the disable state on fields

There are "issues" when you disable a field using the isInitiallyDisabled prop

Some fields will be disabled but the UI does not reflect that ( JSON/Rich Text/ Markdown ).
The user can still edit them in a way (Map/Radio).

This PR is to fix that

@MohammedAl-Rowad would you mind turning this into a fix version instead of a feature.

@anho I replaced this PR with this https://github.com/contentful/field-editors/pull/1071

authors: MohammedAl-Rowad anho

repo: contentful/field-editors


text:
LinkResolverInterface

Hello,
I am confused with what the LinkResolverInterface argument should be. I am following the example in https://github.com/contentful/rich-text.php#parsing

Trying to parse multiple paragraph nodeType

Hi @ray-itech ,
the documentation is, unfortunately, a bit outdated at the moment. Refreshing that is on my TODO-List. For now, you can create a link resolver via:
$resolver = new \Contentful\Delivery\LinkResolver($client, $client->getResourcePool());

where $client is your Delivery SDK client. You usually also don't need to parse rich text data when received via the SDK, it already does that for you.
If you're using the Management SDK, you can create a link resolver via:
$resolver = new \Contentful\Management\LinkResolver($client, new \Contentful\Management\ApiConfiguration(), new \Contentful\Management\RequestUriBuilder());

In the next update I'll include a method to directly create the resolver from the client. Hope this helps!

Hello @Sebb767 ,
Thanks for the response, this helps 😃


text:
MDX problem in windows with contentlayer

Warning: Found 3 problems in 3 documents.
└── Invalid markdown in 3 documents. (Skipping documents)
 • "blogs/blog-one.mdx" failed with YAMLParseError: Unexpected scalar at node end at line 9, column 29:

 image: '../images/proj1.jpg'
                             ^

 • "blogs/blog-three.mdx" failed with YAMLParseError: Unexpected scalar at node end at line 9, column 29:

 image: '../images/proj3.jpg'
                             ^

 • "blogs/blog-two.mdx" failed with YAMLParseError: Unexpected scalar at node end at line 8, column 191:

 …1mZWVkfDMyfGJvOGpRS1RhRTBZfHxlbnwwfHx8fA%3D%3D&auto=format&fit=crop&w=500&q=60'

I found this error when I build on windows.
My stack is:
Next.js 13.5.6  (pages dir)
Node 18.18.2
"contentlayer": "^0.3.4",
The source code is available at:
https://github.com/VittorioMorellini/Portfolio
When I deploy on Vercel it works fine.
Can anyone help me?

Hi @VittorioMorellini! I'm also on windows. Honestly actually probably the same error as I have on:

https://github.com/contentlayerdev/contentlayer/issues/594

Wherein Frontmatter YAML parsing fails at the end of the frontmatter for some reason. Thing is, this is a valid YAML actually:

Here's a workaround though.
The single quotes aren't actually necessary for your "string" types to parse as "string". I noticed upon removing the single quotes for the last property in the frontmatter, it actually started building the document haha. So maybe just do that.
I only use the quotes when I have actual quotes or ":" within my string
description: 'my undergrad thesis: automatic assessment of scoliosis'

With that said, change your frontmatter to this on blog-one.mdx
title: 'dotnet Blazor'
publishedAt: 'April 1, 2023'
description: 'Learn how to create an application in Blazor'
#credit: 'Fabio Biondi'
cover: '/optimized/articles/blog-three/hero.webp'
seoDescription: 'This is the for React redux.'
category: 'dotnet'
image: ../images/proj3.jpg

Thank you for you quick answer. You solved my trouble, than you very much

This is still an issue

Yes, is still an issue. I have been struggling with it lately,  I suppose its because I am trying to run an app on a Windows machine , in powershell, that was originally written on a Mac/linux:
Im using
yarn 1.22.22
Next.js 14.1.0
Contentlayer 0.3.4
react 18.2.0
node 18.19.0
npm 10.2.3

authors: Blankeos VittorioMorellini austenjt m6io

repo: contentlayerdev/contentlayer


text:
netctl: provide fallback for user.Current

This PR fixes the static netctl binary. This makes it possible to run a statically built netctl binary without a panic.

Since I don't think we intend to ever go back to non-static binaries, can we just remove the user.Current call entirely?

build PR

@dseevr: In case we start building binaries for other platforms, I'd rather have it there.
I've modified the error message.

build PR

build pr

build PR

build PR

This is green now. I'll merge.

authors: chrisplo dseevr unclejack

repo: contiv/netplugin