text:
layer CRS not correctly detected

Issue:
For some raster and vector layers conda QGIS is not able to detect the CRS.
E.g. C:/miniconda/envs/qgis/Library/resources/data/world_map.gpkg|layername=countries

In standard OSGeo4W QGIS the CRS is correctly detected.
Also in the conda console it seams to work:
(qgis) C:\Users\janzandr>python
Python 3.8.5 | packaged by conda-forge | (default, Aug 29 2020, 00:43:28) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from qgis.core import QgsVectorLayer
>>> v = QgsVectorLayer('C:/miniconda/envs/qgis/Library/resources/data/world_map.gpkg|layername=countries')
>>> v.crs()
<QgsCoordinateReferenceSystem: EPSG:4326>

Environment (conda list):

$ conda list
blas                      1.0                         mkl
boost-cpp                 1.72.0               h89d28cc_2    conda-forge
brotlipy                  0.7.0           py38h1e8a9f7_1000    conda-forge
bzip2                     1.0.8                he774522_3    conda-forge
ca-certificates           2020.6.20            hecda079_0    conda-forge
cairo                     1.16.0            h8a5e50b_1003    conda-forge
certifi                   2020.6.20        py38h32f6830_0    conda-forge
cffi                      1.14.1           py38hba49e27_0    conda-forge
cfitsio                   3.470                hbbe6aef_6    conda-forge
chardet                   3.0.4           py38h32f6830_1006    conda-forge
coverage                  5.2.1            py38h1e8a9f7_0    conda-forge
cryptography              3.1              py38hba49e27_0    conda-forge
curl                      7.71.1               h4b64cdc_5    conda-forge
exiv2                     0.27.1               hfa2c1cf_0    conda-forge
expat                     2.2.9                h33f27b4_2    conda-forge
freetype                  2.10.2               hd328e21_0    conda-forge
freexl                    1.0.5             hd288d7e_1002    conda-forge
future                    0.18.2           py38h32f6830_1    conda-forge
gdal                      3.1.1            py38h3ba59e7_0    conda-forge
geos                      3.8.1                he025d50_0    conda-forge
geotiff                   1.6.0                hcadc5cd_0    conda-forge
gettext                   0.19.8.1          hb01d8f6_1002    conda-forge
glib                      2.65.0               he4de6d7_0    conda-forge
gsl                       2.6                  h86b8168_0    conda-forge
hdf4                      4.2.13            hf8e6fe8_1003    conda-forge
hdf5                      1.10.6          nompi_he0bbb20_101    conda-forge
httplib2                  0.18.1             pyh9f0ad1d_0    conda-forge
icc_rt                    2019.0.0             h0cc432a_1
icu                       64.2                 he025d50_1    conda-forge
idna                      2.10               pyh9f0ad1d_0    conda-forge
intel-openmp              2020.1                      216
jinja2                    2.11.2             pyh9f0ad1d_0    conda-forge
joblib                    0.16.0                     py_0    conda-forge
jpeg                      9d                   he774522_0    conda-forge
kealib                    1.4.13               h3b59ab9_1    conda-forge
krb5                      1.17.1               hc04afaa_3    conda-forge
libblas                   3.8.0                    16_mkl    conda-forge
libcblas                  3.8.0                    16_mkl    conda-forge
libclang                  9.0.1           default_hf44288c_0    conda-forge
libcurl                   7.71.1               h4b64cdc_5    conda-forge
libffi                    3.2.1             ha925a31_1007    conda-forge
libgdal                   3.1.1                hbc6966c_0    conda-forge
libiconv                  1.16                 he774522_0    conda-forge
libkml                    1.3.0             h7e985d0_1011    conda-forge
liblapack                 3.8.0                    16_mkl    conda-forge
libnetcdf                 4.7.4           nompi_h256d12c_105    conda-forge
libpng                    1.6.37               ha81a0f5_2    conda-forge
libpq                     12.3                 hd9aa61d_0    conda-forge
libprotobuf               3.11.4               h1a1b453_0    conda-forge
libspatialindex           1.9.3                he025d50_3    conda-forge
libspatialite             4.3.0a            h51df0ed_1038    conda-forge
libssh2                   1.9.0                hb06d900_5    conda-forge
libtiff                   4.1.0                h885aae3_6    conda-forge
libwebp-base              1.1.0                hfa6e2cd_3    conda-forge
libxml2                   2.9.10               h1006b36_2    conda-forge
libzip                    1.5.1             h8f0db0c_1005    conda-forge
lz4-c                     1.9.2                h62dcd97_2    conda-forge
m2w64-expat               2.1.1                         2
m2w64-gcc-libgfortran     5.3.0                         6
m2w64-gcc-libs            5.3.0                         7
m2w64-gcc-libs-core       5.3.0                         7
m2w64-gettext             0.19.7                        2
m2w64-gmp                 6.1.0                         2
m2w64-libiconv            1.14                          6
m2w64-libwinpthread-git   5.0.0.4634.697f757               2
m2w64-xz                  5.2.2                         2
markupsafe                1.1.1            py38h9de7a3e_1    conda-forge
mkl                       2020.1                      216
mkl-service               2.3.0            py38hb782905_0
mock                      4.0.2            py38h32f6830_0    conda-forge
msys2-conda-epoch         20160418                      1
nose2                     0.9.2                      py_0    conda-forge
numpy                     1.19.1           py38h72c728b_0    conda-forge
openjpeg                  2.3.1                h57dd2e7_3    conda-forge
openssl                   1.1.1g               he774522_1    conda-forge
owslib                    0.20.0                     py_0    conda-forge
pcre                      8.44                 h6538335_0    conda-forge
pip                       20.2.3                     py_0    conda-forge
pixman                    0.38.0            hfa6e2cd_1003    conda-forge
plotly                    4.9.0              pyh9f0ad1d_0    conda-forge
poppler                   0.89.0               h5d62644_1    conda-forge
poppler-data              0.4.9                         1    conda-forge
postgresql                12.3                 he14cc48_0    conda-forge
proj                      7.0.0                haa36216_5    conda-forge
psycopg2                  2.8.6            py38hba49e27_0    conda-forge
pycparser                 2.20               pyh9f0ad1d_2    conda-forge
pygments                  2.6.1                      py_0    conda-forge
pyopenssl                 19.1.0                     py_1    conda-forge
pyproj                    2.6.1.post1      py38h1dd9442_0    conda-forge
pyqt                      5.12.3           py38h6538335_1    conda-forge
pyqt5-sip                 4.19.18                  pypi_0    pypi
pyqtwebengine             5.12.1                   pypi_0    pypi
pysocks                   1.7.1            py38h32f6830_1    conda-forge
python                    3.8.5           h60c2a47_7_cpython    conda-forge
python-dateutil           2.8.1                      py_0    conda-forge
python_abi                3.8                      1_cp38    conda-forge
pytz                      2020.1             pyh9f0ad1d_0    conda-forge
pyyaml                    5.3.1            py38h9de7a3e_0    conda-forge
qca                       2.2.1                hd7ce7fb_3    conda-forge
qgis                      3.14.1           py38h21d4842_0    conda-forge
qjson                     0.9.0             hd7ce7fb_1006    conda-forge
qscintilla2               2.11.2           py38h19e3e1c_2    conda-forge
qt                        5.12.5               h7ef1ec2_0    conda-forge
qtkeychain                0.10.0               hd7ce7fb_0    conda-forge
qtlocation                5.12.5               he025d50_0    conda-forge
qwt                       6.1.5                h265ddaf_0    conda-forge
qwtpolar                  1.1.1                hd7ce7fb_7    conda-forge
requests                  2.24.0             pyh9f0ad1d_0    conda-forge
retrying                  1.3.3                      py_2    conda-forge
scikit-learn              0.23.2           py38hf00eced_0    conda-forge
scipy                     1.5.0            py38h9439919_0
setuptools                49.6.0           py38h32f6830_0    conda-forge
sip                       4.19.20          py38h6538335_0    conda-forge
six                       1.15.0             pyh9f0ad1d_0    conda-forge
sqlite                    3.33.0               he774522_0    conda-forge
tbb                       2020.1               he980bc4_0    conda-forge
threadpoolctl             2.1.0              pyh5ca1d4c_0    conda-forge
tiledb                    2.0.8                h71c485d_0    conda-forge
tk                        8.6.10               he774522_0    conda-forge
urllib3                   1.25.10                    py_0    conda-forge
vc                        14.1                 h869be7e_1    conda-forge
vs2015_runtime            14.16.27012          h30e32a0_2    conda-forge
wheel                     0.35.1             pyh9f0ad1d_0    conda-forge
win_inet_pton             1.1.0                    py38_0    conda-forge
wincertstore              0.2                   py38_1003    conda-forge
xerces-c                  3.2.2             h6538335_1004    conda-forge
xz                        5.2.5                h62dcd97_1    conda-forge
yaml                      0.2.5                he774522_0    conda-forge
zlib                      1.2.11            h62dcd97_1009    conda-forge
zstd                      1.4.5                h1f3a1b7_2    conda-forge

Details about  conda and system ( conda info ):

$ conda info

     active environment : qgis
    active env location : C:\miniconda\envs\qgis
            shell level : 2
       user config file : C:\Users\janzandr\.condarc
 populated config files : C:\Users\janzandr\.condarc
          conda version : 4.7.12
    conda-build version : not installed
         python version : 3.7.4.final.0
       virtual packages : __cuda=10.2
       base environment : C:\miniconda  (writable)
           channel URLs : https://conda.anaconda.org/conda-forge/win-64
                          https://conda.anaconda.org/conda-forge/noarch
                          https://repo.anaconda.com/pkgs/main/win-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/win-64
                          https://repo.anaconda.com/pkgs/r/noarch
                          https://repo.anaconda.com/pkgs/msys2/win-64
                          https://repo.anaconda.com/pkgs/msys2/noarch
          package cache : C:\miniconda\pkgs
                          C:\Users\janzandr\.conda\pkgs
                          C:\Users\janzandr\AppData\Local\conda\conda\pkgs
       envs directories : C:\miniconda\envs
                          C:\Users\janzandr\.conda\envs
                          C:\Users\janzandr\AppData\Local\conda\conda\envs
               platform : win-64
             user-agent : conda/4.7.12 requests/2.22.0 CPython/3.7.4 Windows/10 Windows/10.0.17134
          administrator : False
             netrc file : None
           offline mode : False

@AndreasRabe can you please provide some sample data for testing?

You can use the world_map.gpkg that is shipped with QGIS. On my system it is found here:

Could not replicate the problem in Linux.

can you try again for QGIS 3.16.1?

I'm on a Windows 10 system. I updated a minute ago, but my Conda QGIS is still 3.14.16-Pi. The problem remains.

Yes, we are stuck on 3.14 for Windows until we have a new conda-build. I will try 3.14 on windows as I didn't see any problems on Linux.

We'll have a meeting tomorrow with some AnacondaInc folks. I'll ask for a new conda-build release that hopefully will fix this for good.

@AndreasRabe Windows builds are back. can you try the most recent version of QGIS and see if the CRS are detected now?

@AndreasRabe Windows builds are back. can you try the most recent version of QGIS and see if the CRS are detected now?

I installed version 3.16.3. Unfortunately, the problem still exists.

I installed version 3.16.3. Unfortunately, the problem still exists.

@AndreasRabe Are you install qgis into new environment?

@AndreasRabe Are you install qgis into new environment?

Yes, fresh env with qgis only:
conda create -n test qgis

Yes, fresh env with qgis only:
conda create -n test qgis

I can confirm the problem on Win10. It seems to be an issue related to srs.db
The following test returns True in OSGeo4W, but False in the conda installation:
wkt='GEOGCS["WGS 84",DATUM["World Geodetic System 1984",SPHEROID["WGS84",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433],AUTHORITY["EPSG","4326"]]'
QgsCoordinateReferenceSystem.fromWkt(wkt).isValid()

As a consequence, it is also impossible to add a custom CRS. To exclude a possible connections to the parallel OSGeo4W installation, I deleted C:\Users\...\Roaming\QGIS and C:\Users\...\AppData\Local\QGIS before installing the conda QGIS, but this did not help.
During the conda QGIS installation I got this error:
SafetyError: The package for qgis located at D:\miniconda3\pkgs\qgis-3.16.3-py38h4dc3349_0
appears to be corrupted. The path 'Library/resources/srs.db'
has an incorrect size.
  reported size: 2777088 bytes
  actual size: 2755584 bytes

I can confirm the problem on Win10. It seems to be an issue related to srs.db
The following test returns True in OSGeo4W, but False in the conda installation:
wkt='GEOGCS["WGS 84",DATUM["World Geodetic System 1984",SPHEROID["WGS84",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433],AUTHORITY["EPSG","4326"]]'
QgsCoordinateReferenceSystem.fromWkt(wkt).isValid()

As a consequence, it is also impossible to add a custom CRS. To exclude a possible connections to the parallel OSGeo4W installation, I deleted C:\Users\...\Roaming\QGIS and C:\Users\...\AppData\Local\QGIS before installing the conda QGIS, but this did not help.
During the conda QGIS installation I got this error:
SafetyError: The package for qgis located at D:\miniconda3\pkgs\qgis-3.16.3-py38h4dc3349_0
appears to be corrupted. The path 'Library/resources/srs.db'
has an incorrect size.
  reported size: 2777088 bytes
  actual size: 2755584 bytes

I wonder if Library/resources/srs.db is already installed by another package...?

I wonder if Library/resources/srs.db is already installed by another package...?

I run a sqldiff between OSGeo4W and conda srs.db, but this did not reveal any difference.

I run a sqldiff between OSGeo4W and conda srs.db, but this did not reveal any difference.

The paths returned by QgsProjUtils.searchPaths() are slightly different in the way how they refer to the internal share folder:
Conda returns returns ...\share, while (the working) OSGeo4W refers to ..\share\proj.

The paths returned by QgsProjUtils.searchPaths() are slightly different in the way how they refer to the internal share folder:
Conda returns returns ...\share, while (the working) OSGeo4W refers to ..\share\proj.

@AndreasRabe you can fix this problem manually:

open your %CONDA_PREFIX%\Library\bin\qgis.env
ensure that PROJ_LIB ends on share\proj, e.g.
PROJ_LIB=D:\miniconda3\envs\qgis_stable\Library\share\proj

@AndreasRabe you can fix this problem manually:

open your %CONDA_PREFIX%\Library\bin\qgis.env
ensure that PROJ_LIB ends on share\proj, e.g.
PROJ_LIB=D:\miniconda3\envs\qgis_stable\Library\share\proj

Thanks a lot! Is working now.

Thanks a lot! Is working now.

authors: AndreasRabe SrNetoChan gillins jakimowb ocefpaf

repo: conda-forge/qgis-feedstock


text:
Branch 3.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)
[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.

source: gharchive/pull-request

repo: conda-forge/r-sparkr-feedstock

license_type: permissive

license_source: github-api


text:
MNT: rerender

Hi! This is the friendly automated conda-forge-webservice.
I've started rerendering the recipe as instructed in #28.
If I find any needed changes to the recipe, I'll push them to this PR shortly. Thank you for waiting!
Here's a checklist to do before merging.

[ ] Bump the build number if needed

Fixes #28

@conda-forge-admin please rerender

authors: conda-forge-admin mfansler


text:
ENH: update package version

Hi! This is the friendly automated conda-forge-webservice.
I've started a version update as instructed in #18.
I'm currently searching for new versions and will update this PR shortly if I find one! Thank you for waiting!
Fixes #18

Sorry bot we are going to use the other PR.

authors: conda-forge-admin tdejager


text:
Uses Accelerate framework instead of the blas package from conda-forge

Reported by @isuruf in https://github.com/conda-forge/slycot-feedstock/pull/22#issuecomment-578444017 :

This package is using Accelerate framework instead of the blas package from conda-forge.

See the build logs from https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=115074&view=logs&j=a8dee1cf-d17f-5cb0-b53f-4a93dfdbfb0c&t=aafbbd55-dd7b-5830-1c88-bc5f3db40f31&l=1673 :
number of files: 42
Fixing linking of /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate in /usr/local/miniconda/conda-bld/slycot_1580144896043/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeh/lib/python3.8/site-packages/slycot/_wrapper.cpython-38-darwin.so
New link location is None
Fixing linking of @rpath/libgfortran.4.dylib in /usr/local/miniconda/conda-bld/slycot_1580144896043/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeh/lib/python3.8/site-packages/slycot/_wrapper.cpython-38-darwin.so
New link location is None
Fixing linking of /usr/lib/libSystem.B.dylib in /usr/local/miniconda/conda-bld/slycot_1580144896043/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeh/lib/python3.8/site-packages/slycot/_wrapper.cpython-38-darwin.so
New link location is None
Fixing linking of /usr/local/miniconda/conda-bld/slycot_1580144896043/_build_env/lib/libgcc_s.1.dylib in /usr/local/miniconda/conda-bld/slycot_1580144896043/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeh/lib/python3.8/site-packages/slycot/_wrapper.cpython-38-darwin.so
.. seems to be linking to a compiler runtime, replacing build prefix with host prefix and
.. fixing linking of /usr/local/miniconda/conda-bld/slycot_1580144896043/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeh/lib/libgcc_s.1.dylib in /usr/local/miniconda/conda-bld/slycot_1580144896043/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeh/lib/python3.8/site-packages/slycot/_wrapper.cpython-38-darwin.so instead
New link location is lib/libgcc_s.1.dylib
Fixing linking of @rpath/libquadmath.0.dylib in /usr/local/miniconda/conda-bld/slycot_1580144896043/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeh/lib/python3.8/site-packages/slycot/_wrapper.cpython-38-darwin.so
New link location is None

   INFO (slycot,lib/python3.8/site-packages/slycot/_wrapper.cpython-38-darwin.so): Needed DSO /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate found in the whitelist
   INFO (slycot,lib/python3.8/site-packages/slycot/_wrapper.cpython-38-darwin.so): Needed DSO /usr/lib/libSystem.B.dylib found in the whitelist
   INFO (slycot,lib/python3.8/site-packages/slycot/_wrapper.cpython-38-darwin.so): Needed DSO lib/libgfortran.4.dylib found in conda-forge::libgfortran-4.0.0-2
   INFO (slycot,lib/python3.8/site-packages/slycot/_wrapper.cpython-38-darwin.so): Needed DSO lib/libgcc_s.1.dylib found in conda-forge::libgfortran-4.0.0-2
   INFO (slycot,lib/python3.8/site-packages/slycot/_wrapper.cpython-38-darwin.so): Needed DSO lib/libquadmath.0.dylib found in conda-forge::libgfortran-4.0.0-2
   INFO (slycot): plugin library package conda-forge::numpy-1.14.6-py38hde6bac1_1201 in requirements/run but it is not used (i.e. it is overdepending or perhaps statically linked? If that is what you want then add it to `build/ignore_run_exports`)
WARNING (slycot): run-exports library package conda-forge::liblapack-3.8.0-7_h4bb4525_netlib in requirements/run but it is not used (i.e. it is overdepending or perhaps statically linked? If that is what you want then add it to `build/ignore_run_exports`)
WARNING (slycot): run-exports library package conda-forge::libcblas-3.8.0-7_h4bb4525_netlib in requirements/run but it is not used (i.e. it is overdepending or perhaps statically linked? If that is what you want then add it to `build/ignore_run_exports`)
WARNING (slycot): dso library package conda-forge::python-3.8.1-h5c2c468_1 in requirements/run but it is not used (i.e. it is overdepending or perhaps statically linked? If that is what you want then add it to `build/ignore_run_exports`)
WARNING (slycot): run-exports library package conda-forge::libblas-3.8.0-7_h4bb4525_netlib in requirements/run but it is not used (i.e. it is overdepending or perhaps statically linked? If that is what you want then add it to `build/ignore_run_exports`)
Fixing permissions

Work is underway to release a new version of slycot. I propose addressing it then.
Is there a specific preference for yes/no using the openblas vs accelerate framework for OSX? Current recipes in the python-control/Slycot repository now explicitly use Accelerate BLAS.

It could be worth seeing if there is a convention for conda forge packages for this. My vote would be to follow their convention if there is one.

I see scipy using plain old blas/cblas and lapack...

Maybe this is the practice:
https://conda-forge.org/docs/maintainer/knowledge_base.html#switching-blas-implementation
i.e. that the users installs whatever versions they want in their environment.
This is how Ubuntu works for example, with configuring alternative packages.

Fixed in #28.

source: gharchive/issue

authors: mbargull moorepants repagh

repo: conda-forge/slycot-feedstock


text:
Update urls

Update urls (github->gitlab)
Fixes #5

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[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.

Fixes #5

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

Thanks for updating!
Note that you only have to update the meta.yaml file. The README is updated by the rerender command.

Note that you only have to update the meta.yaml file. The README is updated by the rerender command.

Yes, that's what I did. The README was updated automatically in 0d7529a
... but I noticed that the conda-forge page in anaconda cloud still shows the old URLs, even after the new with the fixed meta.yml is uploaded, and PyPI metadata is also ok.
@beenje , do you know if we need to change something else apart from meta.yml?

No, that's strange. I don't know how anaconda.org is updated (it's separate from conda-forge).
But this information must come from the package (about.json) and that's generated from the meta.yaml.
Maybe it's only updated for new version and not build number? (There is no build version mentioned on that page).

ok. We''ll see if that is the case when we push higher version (which, BTW I expect will be automerged, since I activated it)

authors: beenje conda-forge-linter cpascual


text:
Update to 12.0.4

Checklist

[x] 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 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:

Jinja2 variable references are suggested to take a {{<one space><variable name><one space>}} form. See lines [20].

@conda-forge-admin, please rerender

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 dbast

repo: conda-forge/tokei-feedstock


text:
vit-pytorch v1.6.4

Dependency pins updated per https://github.com/lucidrains/vit-pytorch/blob/1.6.4/setup.py

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.

@conda-forge-admin, please rerender

@conda-forge-admin, please rerender

Hi @lucidrains, would it be possible to merge in this PR please to get a new version of vit-pytorch on conda-forge? I've also added myself to the recipe maintainer list to help with maintaining future versions.
Thanks in advance!

Thank you.

repo: conda-forge/vit-pytorch-feedstock


text:
Try Python 3.7

Checklist

[ ] 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.

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 jan-janssen

repo: conda-forge/votca-feedstock


text:
Improve build pipeline

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.

@conda-forge-admin, please rerender

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.

Hi! This is the friendly conda-forge automerge bot!
I considered the following status checks when analyzing this PR:

linter: passed
azure: passed

Thus the PR was passing and merged! Have a great day!

authors: conda-forge-admin ehfd

repo: conda-forge/xclip-feedstock


text:
conda-tree 1.1.0 package on conda-forge is flagged by conda-forga as possibly malicious

https://conda-forge.org/blog/posts/2023-03-12-circle-ci-security-breach/#circleci-security-incident
contains a json listing packages which potentially are malicious since they were released during the time when conda-forge's keys were compromised. I'm puzzled that this release is still available on conda-forge but this is their issue. Could you please re-release the package to ensure its security? Even if this was a false-positive and you are certain that it was not tampered with: I could not currently install conda-tree from conda-forge according to my company policies since it is blacklisted via the json from conda-forge.
Thanks!

thanks for the warning, I was not aware of this, I triggered a rebuild of the package on the conda-forge repo.

new rebuild is up.

authors: cafhach rvalieris

repo: conda-incubator/conda-tree

license: MIT


text:
use conda-build's get_build_index function rather than conda's get_index

The hope is that this will allow the package resolving process to respect condarc.  It may also be faster due to caching on the conda-build side.

Codecov Report

Merging #18 into master will decrease coverage by 1.3%.
The diff coverage is 100%.

@@           Coverage Diff            @@
##           master     #18     +/-   ##
========================================
- Coverage    93.8%   92.4%   -1.3%
========================================
  Files           6       6
  Lines         674     674
========================================
- Hits          632     623      -9
- Misses         42      51      +9

Impacted Files
Coverage Δ

conda_concourse_ci/execute.py
89.4% <100%> (-2.6%)
:arrow_down:

Continue to review full report at Codecov.

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

authors: codecov-io msarahan

repo: conda/conda-concourse-ci

license_source: bigquery


text:
Privileges escalate by default for Windows on CI

Checklist

[X] I added a descriptive title
[X] I searched open reports and couldn't find a duplicate

What happened?
@jaimergp, when testing the Windows installers for Spyder, menuinst creates the shortcut for _mode=system rather than _mode=user, but only on CI. This does not occur for macOS or Linux.

The installer appears to build correctly, but when testing the install, it creates the shortcut in the wrong place when run on CI. (I'm using /InstallationType=JustMe /NoRegistry=1 flags). See this run. When I ssh into the workflow, I see that .nonadmin is present in both the base and target prefixes.
When I bypass the install test on CI, the workflow succeeds and I can download the artifact and test the install on my local machine. This works perfectly: shortcut is created for the user, not system. I've tried both the GUI and and the command prompt (even using /NoRegistry=1) with the same successful result. See this run without test.

What could be causing the problem on CI?
Conda Info
See https://github.com/spyder-ide/spyder/actions/runs/7589583691/job/20674537112
Conda Config
See https://github.com/spyder-ide/spyder/actions/runs/7589583691/job/20674537112
Conda list
See https://github.com/spyder-ide/spyder/actions/runs/7589583691/job/20674537112
Additional Context
No response

@jaimergp, also, do you know of a way to display or save the install log from NSIS when executing the installer from the command line?

GHA on Windows runs as an administrator account, so constructor, conda-standalone and menuinst will run in sudo mode, believing it's an all-users install. I've observed the same behavior in napari and gave up because it does work locally. Maybe we can allow overrides at some point but for now that's the known behavior.
For the logs, you need to build your installers with the logging build of nsis. See https://github.com/conda/constructor/blob/d934f13d103359d0d208108fa53ccf529d143cd7/dev/extra-requirements-windows.txt#L1.

GHA on Windows runs as an administrator account, so constructor, conda-standalone and menuinst will run in sudo mode, believing it's an all-users install. I've observed the same behavior in napari and gave up because it does work locally. Maybe we can allow overrides at some point but for now that's the known behavior.

I see, thank you. So menuinst will install the shortcut based on its current privileges; .nonadmin only tells menuinst whether or not to elevate those privileges. I'll update our workflow accordingly. I'm just glad to know that there wasn't a bug 😁.

For the logs, you need to build your installers with the logging build of nsis. See https://github.com/conda/constructor/blob/d934f13d103359d0d208108fa53ccf529d143cd7/dev/extra-requirements-windows.txt#L1.

Thank you! 🙏 😊 I was not aware of that! Is there a flag I need to use on the command line? Or will it automatically send logs to stdout? to log file?

You will find a install.log file in the target location. It's not perfect but it's something. This is how we use it in the constructor test suite.

You will find a install.log file in the target location. You don't have to do anything else.

start /wait Spyder-6.0.0a4.dev150-Windows-x86_64.exe /S

Hmm... I can't find the log file... What am I missing?
Installer Build Environment
# packages in environment at C:\Users\rclary\.conda\envs\spy-inst:
#
# Name                    Version                   Build  Channel
anyio                     3.7.1              pyhd8ed1ab_0    conda-forge
archspec                  0.2.2              pyhd8ed1ab_0    conda-forge
attrs                     23.2.0             pyh71513ae_0    conda-forge
beautifulsoup4            4.12.3             pyha770c72_0    conda-forge
boa                       0.16.0             pyhd8ed1ab_1    conda-forge
boltons                   23.1.1             pyhd8ed1ab_0    conda-forge
brotli-python             1.1.0           py310h00ffb61_1    conda-forge
bzip2                     1.0.8                hcfcfb64_5    conda-forge
ca-certificates           2023.11.17           h56e8100_0    conda-forge
certifi                   2023.11.17         pyhd8ed1ab_0    conda-forge
cffi                      1.16.0          py310h8d17308_0    conda-forge
chardet                   5.2.0           py310h5588dad_1    conda-forge
charset-normalizer        3.3.2              pyhd8ed1ab_0    conda-forge
click                     8.1.7           win_pyh7428d3b_0    conda-forge
colorama                  0.4.6              pyhd8ed1ab_0    conda-forge
conda                     23.11.0         py310h5588dad_1    conda-forge
conda-build               3.28.4          py310h5588dad_0    conda-forge
conda-index               0.3.0              pyhd8ed1ab_1    conda-forge
conda-libmamba-solver     23.12.0            pyhd8ed1ab_0    conda-forge
conda-package-handling    2.2.0              pyh38be061_0    conda-forge
conda-package-streaming   0.9.0              pyhd8ed1ab_0    conda-forge
conda-standalone          23.11.0              h57928b3_1    conda-forge
constructor               3.6.0              pyh31a35d3_0    conda-forge
distro                    1.9.0              pyhd8ed1ab_0    conda-forge
exceptiongroup            1.2.0              pyhd8ed1ab_2    conda-forge
filelock                  3.13.1             pyhd8ed1ab_0    conda-forge
fmt                       10.2.1               h181d51b_0    conda-forge
freetype                  2.12.1               hdaf720e_2    conda-forge
gitdb                     4.0.11             pyhd8ed1ab_0    conda-forge
gitpython                 3.1.41             pyhd8ed1ab_0    conda-forge
idna                      3.6                pyhd8ed1ab_0    conda-forge
importlib_resources       6.1.1              pyhd8ed1ab_0    conda-forge
jinja2                    3.1.3              pyhd8ed1ab_0    conda-forge
joblib                    1.3.2              pyhd8ed1ab_0    conda-forge
json5                     0.9.14             pyhd8ed1ab_0    conda-forge
jsonpatch                 1.33               pyhd8ed1ab_0    conda-forge
jsonpointer               2.4             py310h5588dad_3    conda-forge
jsonschema                4.21.1             pyhd8ed1ab_0    conda-forge
jsonschema-specifications 2023.12.1          pyhd8ed1ab_0    conda-forge
krb5                      1.21.2               heb0366b_0    conda-forge
lcms2                     2.16                 h67d730c_0    conda-forge
lerc                      4.0.0                h63175ca_0    conda-forge
libarchive                3.7.2                h313118b_1    conda-forge
libcurl                   8.5.0                hd5e4a3a_0    conda-forge
libdeflate                1.19                 hcfcfb64_0    conda-forge
libffi                    3.4.2                h8ffe710_5    conda-forge
libiconv                  1.17                 hcfcfb64_2    conda-forge
libjpeg-turbo             3.0.0                hcfcfb64_1    conda-forge
liblief                   0.12.3               h63175ca_0    conda-forge
libmamba                  1.5.6                h3f09ed1_0    conda-forge
libmambapy                1.5.6           py310h04f2035_0    conda-forge
libpng                    1.6.39               h19919ed_0    conda-forge
libsolv                   0.7.27               h12be248_0    conda-forge
libsqlite                 3.44.2               hcfcfb64_0    conda-forge
libssh2                   1.11.0               h7dfc565_0    conda-forge
libtiff                   4.6.0                h6e2ebb7_2    conda-forge
libwebp-base              1.3.2                hcfcfb64_0    conda-forge
libxcb                    1.15                 hcd874cb_0    conda-forge
libxml2                   2.12.4               hc3477c8_1    conda-forge
libzlib                   1.2.13               hcfcfb64_5    conda-forge
lz4-c                     1.9.4                hcfcfb64_0    conda-forge
lzo                       2.10              he774522_1000    conda-forge
m2-msys2-runtime          2.5.0.17080.65c939c               3    conda-forge
m2-patch                  2.7.5                         2    conda-forge
m2w64-gcc-libgfortran     5.3.0                         6    conda-forge
m2w64-gcc-libs            5.3.0                         7    conda-forge
m2w64-gcc-libs-core       5.3.0                         7    conda-forge
m2w64-gmp                 6.1.0                         2    conda-forge
m2w64-libwinpthread-git   5.0.0.4634.697f757               2    conda-forge
mamba                     1.5.6           py310hd9d798f_0    conda-forge
markdown-it-py            3.0.0              pyhd8ed1ab_0    conda-forge
markupsafe                2.1.4           py310h8d17308_0    conda-forge
mdurl                     0.1.2              pyhd8ed1ab_0    conda-forge
menuinst                  2.0.2           py310h00ffb61_0    conda-forge
more-itertools            10.2.0             pyhd8ed1ab_0    conda-forge
msys2-conda-epoch         20160418                      1    conda-forge
nsis                      3.08             h9ead6bc_log_2    conda-forge
openjpeg                  2.5.0                h3d672ee_3    conda-forge
openssl                   3.2.0                hcfcfb64_1    conda-forge
packaging                 23.2               pyhd8ed1ab_0    conda-forge
pillow                    10.2.0          py310h1e6a543_0    conda-forge
pip                       23.3.2             pyhd8ed1ab_0    conda-forge
pkginfo                   1.9.6              pyhd8ed1ab_0    conda-forge
pkgutil-resolve-name      1.3.10             pyhd8ed1ab_1    conda-forge
platformdirs              4.1.0              pyhd8ed1ab_0    conda-forge
pluggy                    1.4.0              pyhd8ed1ab_0    conda-forge
prompt-toolkit            3.0.42             pyha770c72_0    conda-forge
prompt_toolkit            3.0.42               hd8ed1ab_0    conda-forge
psutil                    5.9.8           py310h8d17308_0    conda-forge
pthread-stubs             0.4               hcd874cb_1001    conda-forge
py-lief                   0.12.3          py310h00ffb61_0    conda-forge
pybind11-abi              4                    hd8ed1ab_3    conda-forge
pycosat                   0.6.6           py310h8d17308_0    conda-forge
pycparser                 2.21               pyhd8ed1ab_0    conda-forge
pygments                  2.17.2             pyhd8ed1ab_0    conda-forge
pysocks                   1.7.1              pyh0701188_6    conda-forge
python                    3.10.13         h4de0772_1_cpython    conda-forge
python-libarchive-c       5.0             py310h5588dad_2    conda-forge
python_abi                3.10                    4_cp310    conda-forge
pytz                      2023.3.post1       pyhd8ed1ab_0    conda-forge
pyyaml                    6.0.1           py310h8d17308_1    conda-forge
referencing               0.32.1             pyhd8ed1ab_0    conda-forge
reproc                    14.2.4.post0         hcfcfb64_1    conda-forge
reproc-cpp                14.2.4.post0         h63175ca_1    conda-forge
requests                  2.31.0             pyhd8ed1ab_0    conda-forge
rich                      13.7.0             pyhd8ed1ab_0    conda-forge
ripgrep                   14.1.0               h7f3b576_0    conda-forge
rpds-py                   0.17.1          py310h87d50f1_0    conda-forge
ruamel.yaml               0.18.5          py310h8d17308_0    conda-forge
ruamel.yaml.clib          0.2.7           py310h8d17308_2    conda-forge
ruamel.yaml.jinja2        0.2.4                      py_1    conda-forge
setuptools                69.0.3             pyhd8ed1ab_0    conda-forge
setuptools-scm            8.0.4              pyhd8ed1ab_0    conda-forge
setuptools_scm            8.0.4                hd8ed1ab_0    conda-forge
smmap                     5.0.0              pyhd8ed1ab_0    conda-forge
sniffio                   1.3.0              pyhd8ed1ab_0    conda-forge
soupsieve                 2.5                pyhd8ed1ab_1    conda-forge
tk                        8.6.13               h5226925_1    conda-forge
tomli                     2.0.1              pyhd8ed1ab_0    conda-forge
tqdm                      4.66.1             pyhd8ed1ab_0    conda-forge
truststore                0.8.0              pyhd8ed1ab_0    conda-forge
typing-extensions         4.9.0                hd8ed1ab_0    conda-forge
typing_extensions         4.9.0              pyha770c72_0    conda-forge
tzdata                    2023d                h0c530f3_0    conda-forge
ucrt                      10.0.22621.0         h57928b3_0    conda-forge
urllib3                   2.1.0              pyhd8ed1ab_0    conda-forge
vc                        14.3                hcf57466_18    conda-forge
vc14_runtime              14.38.33130         h82b7239_18    conda-forge
vs2015_runtime            14.38.33130         hcb4865c_18    conda-forge
watchgod                  0.8.2              pyhd8ed1ab_0    conda-forge
wcwidth                   0.2.13             pyhd8ed1ab_0    conda-forge
wheel                     0.42.0             pyhd8ed1ab_0    conda-forge
win_inet_pton             1.1.0              pyhd8ed1ab_6    conda-forge
xorg-libxau               1.0.11               hcd874cb_0    conda-forge
xorg-libxdmcp             1.1.3                hcd874cb_0    conda-forge
xz                        5.2.6                h8d14728_0    conda-forge
yaml                      0.2.5                h8ffe710_2    conda-forge
yaml-cpp                  0.8.0                h63175ca_0    conda-forge
zipp                      3.17.0             pyhd8ed1ab_0    conda-forge
zstandard                 0.22.0          py310h0009e47_0    conda-forge
zstd                      1.5.5                h12be248_0    conda-forge

construct.yaml
name: Spyder
company: Spyder-IDE
reverse_domain_identifier: org.spyder-ide.Spyder
version: 6.0.0a4.dev150
channels:
  - local
  - conda-forge/label/spyder_kernels_rc
  - conda-forge
conda_default_channels:
  - conda-forge
  - defaults
specs:
  - python=3.10.13
  - conda >=23.11.0
  - menuinst >=2.0.2
  - mamba
installer_filename: Spyder-6.0.0a4.dev150-Windows-x86_64.exe
installer_type: exe
initialize_by_default: false
initialize_conda: false
register_python: false
register_envs: false
extra_envs:
  spyder-runtime:
    specs:
      - python=3.10.13
      - spyder=6.0.0a4.dev150
      - cython
      - matplotlib
      - numpy
      - openpyxl
      - pandas
      - scipy
      - sympy
      - python-lsp-server=1.9.1.dev6
      - qtconsole=5.5.1.dev1
      - spyder-kernels=3.0.0b4.dev3
extra_files:
  - C:\Users\rclary\Documents\Repos\spyder\installers-conda\resources\bundle_readme.md: README.txt
  - C:\Users\rclary\Documents\Repos\spyder\installers-conda\build\condarc: .condarc
license_file:
  C:\Users\rclary\Documents\Repos\spyder\installers-conda\resources\bundle_license.rtf
welcome_image:
  C:\Users\rclary\Documents\Repos\spyder\installers-conda\build\welcome_img_win.png
header_image: C:\Users\rclary\Documents\Repos\spyder\installers-conda\build\header_img_win.png
icon_image: C:\Users\rclary\Documents\Repos\spyder\img_src\spyder.ico
default_prefix: '%LOCALAPPDATA%\spyder-6'
default_prefix_domain_user: '%LOCALAPPDATA%\spyder-6'
default_prefix_all_users: '%ALLUSERSPROFILE%\spyder-6'
check_path_length: false
pre_install:
  C:\Users\rclary\Documents\Repos\spyder\installers-conda\resources\pre-install.bat
post_install:
  C:\Users\rclary\Documents\Repos\spyder\installers-conda\resources\post-install.bat

That should be enough, I think?
This is how we run it in CI, in case it helps. Maybe specify /D=some-path to make sure where to expect the file.

This is how we run it in CI, in case it helps. Maybe specify /D=some-path to make sure where to expect the file.

I tried that as well. However, I'm running it locally right now, so maybe it needs admin privileges for some reason? I'll test that also...

That should be enough, I think?

Found the issue. The environment variable NSIS_USING_LOG_BUILD=1 also needs to be set prior to the build.
https://github.com/conda/constructor/blob/d934f13d103359d0d208108fa53ccf529d143cd7/constructor/winexe.py#L352
@jaimergp, thanks for all your help on this! I really appreciate all the work you and others have done on upgrading constructor and menuinst. It is a great help to the Spyder project.

Aaah, yes, I remember now. Sorry about that obscure detail 😬 I'll add it to the documentation.

@jaimergp, when uninstalling, the uninstaller requests the user to restart now or later. This seems to be a result of failing to remove the install.log from the base environment directory. Is this a bug?

I can add some more perspective about that log file and why we (on the Anaconda side) don't use it in production:

If you install into an empty directory (which the current implementation of constructor allows), it will write the log file before the installer checks if the directory is empty, which makes the installer fail. That can of course be fixed by excluding that file.
When you hit "Browse" in the GUI to change the destination path, the installer will write the log file into %USERPROFILE%, which is not ideal (and would be a red flag for me as a user).

@jaimergp, when uninstalling, the uninstaller requests the user to restart now or later. This seems to be a result of failing to remove the install.log from the base environment directory. Is this a bug?

This is not a bug. NSIS, which is the backend of the installers, calls all logs install.log. So, this is the log of the uninstaller. It is marked for deletion and should be removed on reboot.

I can add some more perspective about that log file and why we (on the Anaconda side) don't use it in production:

If you install into an empty directory (which the current implementation of constructor allows), it will write the log file before the installer checks if the directory is empty, which makes the installer fail. That can of course be fixed by excluding that file.
When you hit "Browse" in the GUI to change the destination path, the installer will write the log file into %USERPROFILE%, which is not ideal (and would be a red flag for me as a user).

@jaimergp, when uninstalling, the uninstaller requests the user to restart now or later. This seems to be a result of failing to remove the install.log from the base environment directory. Is this a bug?

This is not a bug. NSIS, which is the backend of the installers, calls all logs install.log. So, this is the log of the uninstaller. It is marked for deletion and should be removed on reboot.

Hmm...thanks @marcoesters, I will reconsider using the NSIS log version. My motivation was to provide some debugging information for developers, but if it will cause more problems for end users it may be counterproductive.

For CIs, enabling logging could be okay because these corner cases don't apply there/are easily fixable.
What I do is enable logging for dev builds of installers and integration testing. I only disable logging for production.

authors: jaimergp marcoesters mrclary

repo: conda/menuinst


text:
Allow users to configure embeddings for RAGAS metrics

Is your feature request related to a problem? Please describe.
The versions of deepeval and ragas that I'm using:

deepeval==0.20.70
ragas==0.1.1

I was trying to use RAGASAnswerRelevancyMetric to evaluate the generated output of my Microsoft Azure Endpoints for the Open AI GPT models. Under the hood, in ragas/evaluation.py, embeddings are used for the calculation, and I cannot find a way to override the embeddings with the deepeval library. ragas library supports Microsoft Azure endpoints - their instruction:
"In order to use the library with Microsoft Azure endpoints, you need to set the OPENAI_API_TYPE, OPENAI_API_BASE, OPENAI_API_KEY and OPENAI_API_VERSION. The OPENAI_API_TYPE must be set to 'azure' and the others correspond to the properties of your endpoint. In addition, the deployment name must be passed as the model parameter."
I'm not sure how I can pass the deployment name as the model parameter to ragas from deepeval.
Describe the solution you'd like
I hope users of deepeval can have a better control over how embeddings are generated when using ragas-related metrics.
Describe alternatives you've considered
Not applicable
Additional context
Not applicable
P.S. thanks for open-sourcing this great library.

@Li0425 Hey! No problem, we'll support it

@Li0425 It's done! Newest version 0.20.71, here are the docs: https://docs.confident-ai.com/docs/metrics-ragas#example
Note that only the RAGASAnswerRelevancy metric uses embeddings, it doesn't matter to the implementation but just as a piece of info :)
Come join our discord to talk :) : https://discord.com/invite/a3K9c8GRGt

Hi @penguine-ip, thanks for the super quick update! Joined the discord 👍

@Li0425 no problem :) and happy to have u

Hello @penguine-ip , regarding this change: for answer relevancy it works well. However, for other ragas metrics that don't really calculate based on embeddings, embedding_factory() in ragas library would be hit anyways, and deepeval test couldn't be run again due to not able to configure combeddings

@Li0425 Can you give an example? I thought only Answer relevancy uses embeddings. I tried using the RAGAS metric and didn't run into errors.
Also come to discord if you're on there! https://discord.com/invite/a3K9c8GRGt I check it a lot more often

repo: confident-ai/deepeval


text:
cloud-api-adaptor ds rolling update

Follow up of the issue https://github.com/confidential-containers/cloud-api-adaptor/issues/1240.
The proposed solution is to leverage the rolling update feature in Daemonset in CR and add additional probes:

liveness, readiness or startup probes
containers postStart hook

So, we can make sure all PeerPod instances on specific nodes can be running before update another node. Diagram like:

DaemonSetController rolling update cloud-api-adaptor ds, steps as below

Update the cloud-api-adaptor pod on Node-1
cloud-api-adaptor pod recreated and startup on Node-1
PeerPod VM-1 on Node-1 recreated and running
Probes return ready (via readiness probe, startup probe or containers lifecycle hook)
Update the cloud-api-adaptor pod on Node-2
cloud-api-adaptor pod recreated and startup on Node-2
PeerPod VM-2 on Node-2 recreated and running
Probes return ready (via readiness probe, startup probe or containers lifecycle hook

So, we need:

Add a http service for probe in cloud-api-adaptor container
Add probes in cloud-adi-adaptor ds yaml
Implement the probe service to check all Pod instance status with runtimeClass and nodename fields match

@jtumber-ibm @stevenhorsman @bpradipt @liudalibj @surajssd @jensfr This is the proposed solution based on the discussion on the weekly meeting on Wed, may you please help give your comments on that?

As far as I understand, the proposal right now requires 2 nodes to be able to update. I think it would be beneficial if we could manage to update single nodes clusters. While most production clusters likely consist of multiple nodes, for testing, especially in CI, its much easier to run on a single node cluster.
Would it be possible to update pods on the same node one-by-one to the new CAA version? Very naive approach:

Have two instances of a pod running on the same node
Start new version CAA pod next to old CAA pod (changes required to make that possible I guess)
For one pod at a time, terminate it and recreate under the new version

authors: huoqifeng katexochen


text:
스프린트 회의 로그 (3차) 🏃♀🏃♂

스프린트 회의 로그 (3차) 🏃♀🏃♂
스프린트 목표 🏈

버전 1.0 배포
중간 데모 드로피로 시연하기
메인페이지에서 채널새성과 채널입장이 가능하다.
채널 페이지에서 스피커와 리스너의 슬라이드 동기화가 이루어진다.
채널 페이지에서 사용자 채팅이 가능하다.
마이페이지에서 사용자의 히스토리를 확인 할 수 있다.

스프린트 단위 🗓

3일 (2019.11.26(화) ~ 2019.11.28(목))

스크럼 마스터 👨🔧

김재원 @load0ne

회의 내용 💬

목요일까지 버전 1을 배포하기 위해 MVP를 구현한다.
서비스를 4개의 작은 부분으로 나누어 할당하였다.

- Main Page : 슬라이드 드롭다운, 채널코드 생성 및 공유
- Channel page
    - Slide : 슬라이드 뷰어, 슬라이드 동기화
    - Chat : 채팅 좋아요, 채팅 sorting
- My page: 마이페이지 UI, 유저 히스토리 조회

스프린트 백로그 ✍
#11 메인 화면에서 슬라이드를 드롭다운 할 수 있다.

Issue: #48
Assignee: 이미림 @always-awake
Manday: 1

[ ] 메인 화면의 Drag & Drop Page에 파일을 드롭다운 할 수 있다.
[ ] 파일을 드롭다운하면, 파일이 image-converter 서버로 전송된다.
[ ] image-converter 서버의 응답이 있기 전까지는 유저에게 로딩화면을 보여준다.
[ ] image-converter 서버의 응답이 ok라면, 채널 화면이 보여지도록 한다.
[ ] image-converter 서버의 응답이 ok가 아니라면(error 발생), 에러 페이지를 보여준다.

#31 채널 코드를 입력할 수 있다.

Issue: #50
Assignee: 이미림 @always-awake
Manday: 1.5

[ ] 채널 코드를 입력할 수 있는 Input 컴포넌트를 생성해야 한다.
[ ] 만약, 입력한 채널의 코드가 다른 채널의 코드와 동일하다면, 동일한 채널 코드를 갖는 채널 목록을 보여주는 페이지가 보여진다. (채널 목록은 스크롤 되어야 한다.)
[ ] 채널 목록 페이지에는 헤더와 채널 정보가 담겨있는 채널 카드 컴포넌트 리스트가 보여진다.
[ ] 특정 카드를 클릭하면 해당 채널 페이지가 보여진다.
[ ] 선택된 채널 페이지로 이동할 때, 채널 컴포넌트가 로딩되기 전까지는 로딩화면이 보여진다.

#13, #37 공유 버튼을 이용해서 생성한 프레젠테이션 채널 코드를 복사하고, 공유할 수 있다.

Issue: #51
Assignee: 이미림 @always-awake
Manday: 1

[ ] 채널 내 공유하기 버튼 컴포넌트를 구현한다.
[ ] 버튼을 클릭하면 채널 코드가 복사된다.

#18, #43 특정 채팅글에 좋아요 가능하다.

Issue: #
Assignee: 김재원 @load0ne
Manday: 2

익명의 사용자에게도 익명 사용자 토큰을 넘겨주도록 인증시스템을 수정한다.
좋아요을 하기 위해서 채팅 UI를 완성한다.
DB에 좋아요 로그를 저장한다.
좋아요를 한 채팅은 다시 좋아요 하지 못하도록 한다.
좋아요 상태를 채팅 UI에 표시한다.

#16 채팅을 공감순/최신순으로 정렬할 수 있다.

Issue: #
Assignee: 김재원 @load0ne
Manday: 1/2

채팅을 공감순으로 정렬해서 렌더링 가능하다.
채팅을 최신순으로 정렬해서 렌더링 가능하다.(default)
현재 정렬상태를 UI로 강조한다.

#17, 39 채팅창을 토글할 수 있다.

Issue: #
Assignee: 김재원 @load0ne
Manday: 1/2

채팅창 토글버튼 UI를 클릭시 채팅뷰가 토글된다.
토글될 때 적절한 애니메이션이 발생한다.(옵션)

#3 로그인 된 사용자는 마이페이지로 이동 할 수 있다.

Issue: #
Assignee: 김도현 @happydhKim
Manday: 1

[ ] 새로운 페이지를 만들어야 한다.
[ ] 프로젝트의 컬러에 맞는 UI를 그려야 한다.
[ ] 기존의 구조에 맞게 컴포넌트를 설계해야 한다.
[ ] 로그인 된 사용자만 사용하며, 상태를 확인해야 한다.
[ ] 회원정보를 담은 스키마를 정의해야 한다.
[ ] 채널정보를 담은 스키마를 정의해야 한다.

#7 스피커로써 생성한 채널 목록 확인

Issue: #
Assignee: 김도현 @happydhKim
Manday: 0.5

[ ] 스피커와 리스너를 구별해야 한다.
[ ] GraphQL을 이용해 최소한의 정보를 불러와야 한다.
[ ] 채널 목록을 뿌려주는 UI 컴포넌트를 생성해야 한다.
[ ] 서버와 연동해야 한다.

#8 스피커 히스토리카드로 채널 입장 가능

Issue: #
Assignee: 김도현 @happydhKim
Manday: 0.5

[ ] 스피커와 리스너를 구별해야 한다.
[ ] GraphQL을 이용해 최소한의 정보를 불러와야 한다.
[ ] 히스토리카드 UI 컴포넌트를 생성해야 한다.
[ ] 서버와 연동해야한다.

#10 리스너 히스토리 카드를 통해 채널로 입장 가능

Issue: #
Assignee: 김도현 @happydhKim
Manday: 0.5

[ ] 스피커와 리스너를 구별해야 한다.
[ ] GraphQL을 이용해 최소한의 정보를 불러와야 한다.
[ ] 히스토리카드 UI 컴포넌트를 생성해야 한다.
[ ] 서버와 연동해야 한다.

#14, #35 슬라이드를 앞뒤로 넘길 수 있다.

Issue: #
Assignee: 조애리 @aereeeee
Manday: 1

[ ] 슬라이드 뷰어 UI 구현
[ ] 슬라이드 애니메이션 구현
[ ] 이미지 로딩 프로세스 구현

#32 스피커의 화면을 동기화하여 볼 수 있다.

Issue: #
Assignee: 조애리 @aereeeee
Manday: 2

[ ] 스피커의 위치를 리스너가 subscription해야한다.
[ ] 슬라이드 동기화 버튼 UI구현
[ ] 동기화 활성화 시 리스너와 스피커의 슬라이드가 동기화 된다.

확인했습니다 화이띵!!!🤠

확인하고, 이슈 생성했습니다!
이번주 스프린트도 화이팅합시다 👊

확인했습니다~~~ 화이팅!!! 💪

authors: aereeeee always-awake happydhKim load0ne


text:
[feat] Render vocaList if it exists

설명
voca item이 존재하는 경우, voca item 렌더링하기
할일

[ ] voca 페이지에 접근했을 때, 유저가 vaca list를 가지고 있는지 확인한다. (서버에 요청)
[ ] 가지고 있다면 voca List를 렌더링한다.
[ ] 가지고 있지 않다면 +버튼 요소만 렌더링한다.

참조

Route methods

진행해주세요

해당 issue 지금 진행해도 될까요?

authors: leejaelll parkseonup


text:
Optimise calculate relayer fee

Description

Type of change

[ ] Docs change / dependency upgrade
[ ] Configuration / tooling changes
[ ] Refactoring
[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Requires changes in customer code

High-level change(s) description - from the user's perspective

Related Issue(s)
Fixes
Related pull request(s)

We have circular deps with importing txservice into utils.

authors: just-a-node sanchaymittal

repo: connext/monorepo


text:
Make Semaphore.core container Operational

semaphore-core

Base image: python 3.10
Ports: None
Files: src directory (except for API directory and runner.py
.h5 files, dspec files at runtime?
.env
Library: from requirements.txt
Volume:

Status

ALL tests pass!
Need entry point

repo: conrad-blucher-institute/semaphore


text:
Btnotificationenabler on iOS 8.1.1 problem

Hello conradev, I'm on iOS 8.1.1 I installed and reinstalled btnotificationenabler a lot of times to see if it fix this problem but it won't, my problem is I don't have that view over bluetooth option in notifications... even with the show on lock screen switch on won't work. What you recommend me to do if there is a possible fix. Thanks in advance.

I have the same issue.  I'm running 8.1.2 on an iPhone 5s

repo: conradev/BTNotificationEnabler

license: mit


text:
Fork implementing GraphQL API + React frontend - How to organize PRs?

Hey Conrado,
I made a fork for the project with lot's of changes. Modifications include:

Addition of a merkle root to the block header. Miners now use the block header for the hashing input in the proof-of-work algorithm. This makes mining more perfomant, since mining effort is no longer relative to the number of transactions in a block. Core functions were updated to use the merkle root when validating the chain.
GraphQL API instead of the traditional HTTP approach
Frontend app for consuming the API
Reimplementation of the p2p communication to also use the GraphQL API. Nodes now forward peers to their known peers when receiving a valid block. This makes connecting to other peers more "organic".

I would love to organize these in pull requests to this project, but since it's so many changes and since I never actually submitted a PR to a open source project, I'm kinda confused as to how I should do it. I haven't rewritten the test suite. Should I start there?
If anyone has doubts as to how they can start the dev environment with docker, give me a ping.

I think you have created a new repository instead of a fork. I can't merge it that way. It's even hard to compare, hehe.
I also need to think if I should merge your vision of this project here or if I should link my project to yours in case someone wants to see your vision of the project (which is nice, because of the merkle root and graphql).
Tell me what you think.
Best

Hey Conrado. Thanks for the kudos :100:
I've done everything based of the master branch. I'll fork the repo again from the v1.0.0 and organize the pull requests in:

Merkle Root implementation
GraphQL API and rewriting of p2p communication
Docker workflow, with links to the frontend app

There are still more things in my roadmap which I would like to discuss, but I guess we should take one step at a time.

authors: conradoqg eaverdeja

repo: conradoqg/naivecoin


text:
GMP: Execution of IpcEnvelope

[x] Implementation of new data structures for IpcEnvelope and cross-net messages as described here
[x] Implementation of the new subnet actor and gateway methods required in the gateway to forward and trigger the execution of the IpcEnvelope as detailed here. Remember that the design still mentions the enforcement of firewall policies, but these are out of scope for the first iteration. Cross-net message ACLs are explicitly implemented as part of the IPC-enabled user smart contracts.

Merged to main in https://github.com/consensus-shipyard/ipc/pull/543.

authors: adlrocha raulk

repo: consensus-shipyard/ipc


text:
knownArch in gb/importer/pkg.go misses s390x

Go in Ubuntu 16.04 has a patch enabling support for s390x, but gb doesn't realize that it shouldn't compile files called things like asm_s390x.s.

I'll do a 0.4.1 release soon to pick up these small improvements.
On Tue, Mar 15, 2016 at 12:30 PM, Michael Hudson-Doyle <
notifications@github.com> wrote:

Go in Ubuntu 16.04 has a patch enabling support for s390x, but gb doesn't
realize that it shouldn't compile files called things like asm_s390x.s.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/constabulary/gb/issues/580

authors: davecheney mwhudson

repo: constabulary/gb


text:
🛑 degelite.org is down

In a5085f0, degelite.org (https://degelite.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: degelite.org is back up in d6e8d85.

repo: constructions-incongrues/status


text:
implement PNC artifacts download and fetch-artifacts-schema

Story MMENG-1252
Epic MMENG-1282
Maintainers will complete the following section

[x] Commit messages are descriptive enough
[x] Code coverage from testing does not decrease and new code is covered
[x] JSON/YAML configuration changes are updated in the relevant schema
[x] Changes to metadata also update the documentation for the metadata
[x] Pull request has a link to an osbs-docs PR for user documentation updates
[x] New feature can be disabled from a configuration file

release notes updated

repo: containerbuildsystem/atomic-reactor


text:
report which specific task was sucessful

CLOUDBLD-10933

Signed-off-by: Robert Cerven rcerven@redhat.com
Maintainers will complete the following section

[ ] Commit messages are descriptive enough
[ ] Code coverage from testing does not decrease and new code is covered
[ ] Python type annotations added to new code
[ ] JSON/YAML configuration changes are updated in the relevant schema
[ ] Changes to metadata also update the documentation for the metadata
[ ] Pull request has a link to an osbs-docs PR for user documentation updates
[ ] New feature can be disabled from a configuration file

generally looks good to me. But it seems to me that the class itself should have the information about its name instead of passing the name to the class in the params. Seems more reasonable, but if there is no simple way to do that then I'll ack this PR.

generally looks good to me. But it seems to me that the class itself should have the information about its name instead of passing the name to the class in the params. Seems more reasonable, but if there is no simple way to do that then I'll ack this PR.

fixed

change in unreleased feature no rn update

authors: mkosiarc rcerven


text:
TestRuntimeHandler logging empty string in CRI Integration tests

Description
The CRI Integration Test logs for the TestRuntimeHandler test are logging empty strings.
Steps to reproduce the issue:

Run the TestRuntimeHandler apart of the CRI integration tests
Check the output logs

Describe the results you received:
=== RUN   TestRuntimeHandler
    runtime_handler_test.go:30: Create a sandbox
    runtime_handler_test.go:32: the --runtime-handler flag value is:
    runtime_handler_test.go:41: Verify runtimeService.PodSandboxStatus sets RuntimeHandler
    runtime_handler_test.go:44: runtimeService.PodSandboxStatus sets RuntimeHandler to
    runtime_handler_test.go:47: Verify runtimeService.ListPodSandbox sets RuntimeHandler
    runtime_handler_test.go:50: runtimeService.ListPodSandbox sets RuntimeHandler to

Describe the results you expected:
=== RUN   TestRuntimeHandler
    runtime_handler_test.go:30: Create a sandbox
    runtime_handler_test.go:32: the --runtime-handler flag value is: <runtime here>
    runtime_handler_test.go:41: Verify runtimeService.PodSandboxStatus sets RuntimeHandler
    runtime_handler_test.go:44: runtimeService.PodSandboxStatus sets RuntimeHandler to <runtime here>
    runtime_handler_test.go:47: Verify runtimeService.ListPodSandbox sets RuntimeHandler
    runtime_handler_test.go:50: runtimeService.ListPodSandbox sets RuntimeHandler to <runtime here>

Output of containerd --version:
containerd containerd.io 1.4.3 269548fa27e0089a8b8278fc4fc781d7f65a939b

Any other relevant information:
N/A

Thanks for the chat @chrisfregly looking forward to your PR

authors: chrisfregly mikebrow

repo: containerd/containerd


text:
cgroup.event_control: operation not supported

Description
When deploying a container I have this error:
level=error msg="add cg to OOM monitor" error="write /sys/fs/cgroup/memory/docker/85658e63e3ce613704e58cdc71d9dc8ff571d980e062937fbb47d0105561e841/cgroup.event_control: operation not supported"
time="2023-02-16T12:09:32.696019615+01:00" level=info msg="loading plugin \"io.containerd.event.v1.publisher\"..." runtime=io.containerd.runc.v2 type=io.containerd.event.v1
time="2023-02-16T12:09:32.696225191+01:00" level=info msg="loading plugin \"io.containerd.internal.v1.shutdown\"..." runtime=io.containerd.runc.v2 type=io.containerd.internal.v1
time="2023-02-16T12:09:32.696560298+01:00" level=info msg="loading plugin \"io.containerd.ttrpc.v1.task\"..." runtime=io.containerd.runc.v2 type=io.containerd.ttrpc.v1
time="2023-02-16T12:09:32.697990085+01:00" level=info msg="starting signal loop" namespace=moby path=/run/docker/containerd/daemon/io.containerd.runtime.v2.task/moby/85658e63e3ce613704e58cdc71d9dc8ff571d980e062937fbb47d0105561e841 pid=14731 runtime=io.containerd.runc.v2
time="2023-02-16T12:09:34.012697746+01:00" level=error msg="add cg to OOM monitor" error="write /sys/fs/cgroup/memory/docker/85658e63e3ce613704e58cdc71d9dc8ff571d980e062937fbb47d0105561e841/cgroup.event_control: operation not supported"
INFO[2023-02-16T12:09:34.079059445+01:00] ignoring event                                container=85658e63e3ce613704e58cdc71d9dc8ff571d980e062937fbb47d0105561e841 module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
INFO[2023-02-16T12:09:34.080524569+01:00] shim disconnected                             id=85658e63e3ce613704e58cdc71d9dc8ff571d980e062937fbb47d0105561e841
WARN[2023-02-16T12:09:34.081323647+01:00] cleaning up after shim disconnected           id=85658e63e3ce613704e58cdc71d9dc8ff571d980e062937fbb47d0105561e841 namespace=moby
INFO[2023-02-16T12:09:34.081542468+01:00] cleaning up dead shim
WARN[2023-02-16T12:09:34.098014852+01:00] cleanup warnings time="2023-02-16T12:09:34+01:00" level=info msg="starting signal loop" namespace=moby pid=15111 runtime=io.containerd.runc.v2

Steps to reproduce the issue
docker run --rm hello-world
Describe the results you received and expected
Container works, but not mapping ports.
What version of containerd are you using?
v1.6.16
Any other relevant information
runc version 1.1.4
commit: v1.1.4-0-g5fd4c4d
spec: 1.0.2-dev
go: go1.19.5
libseccomp: 2.5.1

Linux NI-cRIO-9045-01F88633 5.15.92-rt57-g414876561405-dirty #1 SMP PREEMPT_RT Thu Feb 16 14:19:34 CET 2023 x86_64 x86_64 x86_64 GNU/Linux

Kernel checks:

cgroup mounts:
cgroup on /sys/fs/cgroup type tmpfs (rw,relatime,mode=755)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu type cgroup (rw,relatime,cpu)
cgroup on /sys/fs/cgroup/cpuacct type cgroup (rw,relatime,cpuacct)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,relatime,blkio)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,relatime,net_cls)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,relatime,perf_event)
cgroup on /sys/fs/cgroup/net_prio type cgroup (rw,relatime,net_prio)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,relatime,hugetlb)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,relatime,pids)

Show configuration if it is related to CRI plugin.
No response

Hi! I would like to work on this issue


text:
diff: set "containerd.io/empty-layer" label to an empty layer

This fix is intended to allow BuildKit to detect empty layers without
comparing the magic digest value.
https://github.com/moby/buildkit/blob/f1dac983fa3e64d98964dfb91a45ae0adde2c253/exporter/containerimage/writer.go#L30
https://github.com/moby/buildkit/blob/f1dac983fa3e64d98964dfb91a45ae0adde2c253/snapshot/imagerefchecker/checker.go#L19
Signed-off-by: Akihiro Suda suda.akihiro@lab.ntt.co.jp

@tonistiigi @dmcgowan

Codecov Report

Merging #3044 into master will increase coverage by 0.03%.
The diff coverage is 77.77%.

@@            Coverage Diff             @@
##           master    #3044      +/-   ##
==========================================
+ Coverage   43.87%   43.91%   +0.03%
==========================================
  Files         102      102
  Lines       10903    10915      +12
==========================================
+ Hits         4784     4793       +9
- Misses       5384     5387       +3
  Partials      735      735

Flag
Coverage Δ

#linux
47.54% <93.33%> (+0.05%)
:arrow_up:

#windows
41.03% <0%> (-0.06%)
:arrow_down:

Impacted Files
Coverage Δ

archive/tar.go
44.58% <77.77%> (+0.79%)
:arrow_up:

Continue to review full report at Codecov.

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

This can be implemented without a breaking interface change by either using the Opt pattern on Diff or defining an interface which can be type asserted on the Reader/Writer. I think the opt pattern is acceptable since there could be other diff options we want to pass in the future.

any update @AkihiroSuda ?

updated

Is the main motivation here that using magic values is bad or that the empty tar output might change?

Empty tar might not change but tar.gz can change

Or wondering whether we can update OCI Image Spec to officially use sha256:4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1 as the empty tar.gz binary

failure seems unrelated
    --- FAIL: TestContentClient/CommitErrorState (3.44s)
        testsuite.go:117: Cleanup failed: unknown
            github.com/containerd/containerd/errdefs.init
            	C:/gopath/src/github.com/containerd/containerd/errdefs/errors.go:39
            github.com/containerd/containerd/content.init
            	<autogenerated>:1
            github.com/containerd/containerd.init
            	<autogenerated>:1
            main.init
            	<autogenerated>:1
            runtime.main
            	C:/go/src/runtime/proc.go:189
            runtime.goexit
            	C:/go/src/runtime/asm_amd64.s:1333
            could not read updatedat: open C:\Program Files\containerd\root-test\io.containerd.content.v1.content\ingest\9101c5f249b4cb38a50dddda86a787c09f31099573c87c525fc50774ac21d05d\updatedat: The process cannot access the file because it is being used by another process.
            github.com/containerd/containerd/errdefs.FromGRPC
            	C:/gopath/src/github.com/containerd/containerd/errdefs/grpc.go:98
            github.com/containerd/containerd/content/proxy.(*proxyContentStore).ListStatuses
            	C:/gopath/src/github.com/containerd/containerd/content/proxy/content_store.go:144
            github.com/containerd/containerd.newContentStore.func2
            	C:/gopath/src/github.com/containerd/containerd/content_test.go:55
            github.com/containerd/containerd/content/testsuite.makeTest.func1.1
            	C:/gopath/src/github.com/containerd/containerd/content/testsuite/testsuite.go:116
            github.com/containerd/containerd/content/testsuite.makeTest.func1
            	C:/gopath/src/github.com/containerd/containerd/content/testsuite/testsuite.go:137
            testing.tRunner
            	C:/go/src/testing/testing.go:827
            runtime.goexit
            	C:/go/src/runtime/asm_amd64.s:1333

ping @dmcgowan any update here?

Or wondering whether we can update OCI Image Spec to officially use sha256:4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1 as the empty tar.gz binary

I don't think the hash needs to be official. I was thinking more that within a single compiled version, the empty hash will always be the same. You could calculate with a sync.Once or just have a test that will fail if the hardcoded value changes.

I'm going to close this one as there is an alternative solution which does not require metadata storage or updates to the diff service behavior.

authors: AkihiroSuda codecov-io dmcgowan fuweid


text:
Prepare release notes for v1.6.0-beta.5

See generated notes https://gist.github.com/dmcgowan/d9eba0f8f79c11c46734a109b6f7faef

/retest

/retest


text:
nerdctl login should warn about passing along an explicit scheme

Description
While pull and push do not allow explicit schemes (as image identifiers do not), both docker and nerdctl login DO allow it, albeit ignoring them entirely.
Our suggestion is to:

warn the user that this syntax is only supported as a convenience and that the scheme is ignored (which docker should do too)

This will impact #3046 - which I believe still matters as there should be a way to talk TLS even with localhost.
Steps to reproduce the issue
dmp@lima-dock:/Users/dmp/Projects/go/nerdctl$ sudo nerdctl login http://192.168.5.15

Describe the results you received and expected
ERRO[0000] failed to call tryLoginWithRegHost            error="failed to call rh.Client.Do: Get \"https://192.168.5.15/v2/\": dial tcp 192.168.5.15:443: connect: connection refused" i=0

What version of nerdctl are you using?
1.7.6
Are you using a variant of nerdctl? (e.g., Rancher Desktop)
None
Host information
No response

Hi @apostasie,
the scheme is not ignored during nerdctl login, there is a fallback to http in specific situations where we can add a warning message to notify the user

@fahedouch any user specified scheme in the url is just ignored entirely.
Try for example: nerdctl login http://index.docker.io
The fact that we fallback from https to http (typically through --insecure-registry) is orthogonal.

@fahedouch any user specified scheme in the url is just ignored entirely.
Try for example: nerdctl login http://index.docker.io
The fact that we fallback from https to http (typically through --insecure-registry) is orthogonal.

It looks like a bug. It is not the intended behavior. Let me check this.

authors: apostasie fahedouch

repo: containerd/nerdctl


text:
Documentation: adding new contributors git cheat-sheet

New open-source contributors - well-intended, competent developers that are not used to public contributions, do regularly struggle with some of the git athletics:
https://github.com/containerd/nerdctl/pull/3366#issuecomment-2311082228
Pretty simple stuff that seems obvious for OGs, like squashing, rebasing, managing a commit pile, etc.
This small doc is meant to list the basic stuff, that we can refer people to instead of explaining again and again how this works.
Point being: lowering the bar for contributions is good for the project.
Let me know if this is useful or if you feel people should just RTFM instead :-).

Not sure why the CI is not happy.
Will try to summon the dark-god of project checks, Sir Phil @estesp.

Thanks, but probably this should be merged to https://github.com/containerd/project/blob/main/CONTRIBUTING.md

Thanks, but probably this should be merged to https://github.com/containerd/project/blob/main/CONTRIBUTING.md

Sure. That works too. Will move it there.
I want this PR to stay open as-is though (because of the project check fail thay may be of interest).

Closing.
After some thoughts, this is definitely generic content that could be reused across many projects.
Pushing it there instead:
https://github.com/farcloser/open-source-help-desk/pull/1
Once merged and properly configured, that should become visible under:
https://dev.farcloser.world/open-source-help-desk
Where hopefully we can send people to when they have basic questions about that stuff.
Thank you folks!
Will ping you for review over there if you have time for that.

authors: AkihiroSuda apostasie


text:
cmd: improve user interface for help message by add default text

Default values were missing in help text after v0.6.1, this patch fixes it.
And sorted out some usage information.

Current help message:
NAME:
   containerd-nydus-grpc - Nydus remote snapshotter for containerd

USAGE:
   containerd-nydus-grpc [global options] command [command options] [arguments...]

COMMANDS:
   help, h  Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --version                                   print version and build information (default: false)
   --root value                                directory to save the working state of nydus-snapshotter (default: /var/lib/containerd-nydus)
   --address value                             gRPC socket path of nydus-snapshotter (default: /run/containerd-nydus/containerd-nydus-grpc.sock)
   --config value                              path to nydus-snapshotter configuration (such as: config.toml)
   --nydusd-config value, --config-path value  path to nydusd configuration (such as: nydusd-config.json or configuration_v2.toml) (default: /etc/nydus/nydusd-config.json)
   --daemon-mode value                         spawning nydusd daemon mode, possible values are: "multiple", "shared" or "none" (default: multiple)
   --fs-driver value                           image service based on which fs driver, possible values are: "fusedev", "fscache" (default: fusedev)
   --log-level value                           logging level, possible values are: "trace", "debug", "info", "warn", "error" (default: info)
   --log-to-stdout                             print log messages to standard output (default: false)
   --nydus-image nydus-image                   nydus-image binary path, it will be searched from $PATH if this option is not provided (such as: /usr/local/bin/nydus-image)
   --nydusd nydusd                             nydusd binary path, it will be searched from $PATH if this option is not provided (such as: /usr/local/bin/nydusd)
   --help, -h                                  show help

Codecov Report
Patch coverage: 100.00% and project coverage change: +0.06 :tada:

Comparison is base (f848ed1) 37.13% compared to head (7216120) 37.20%.

:exclamation: Current head 7216120 differs from pull request most recent head 4521807. Consider uploading reports for the commit 4521807 to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #456      +/-   ##
==========================================
+ Coverage   37.13%   37.20%   +0.06%
==========================================
  Files          60       60
  Lines        6912     6919       +7
==========================================
+ Hits         2567     2574       +7
  Misses       4048     4048
  Partials      297      297

Impacted Files
Coverage Δ

internal/flags/flags.go
100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

@sctb512 Please check the optimizer E2E test. It randomly fails, which is somewhat upset.

repo: containerd/nydus-snapshotter


text:
Automate crates publishing

This PRs add a workflows that can be launched from the Github UI to publish a crate.

LGTM
I don't seem to have ability to re-run actions.  The windows failure here is #153, I will try to get some time to fix that next week.

authors: jsturtevant mxpv

repo: containerd/rust-extensions


text:
Stop pre-installing podman utils/tools

Commit
https://github.com/containers/podman/commit/c7827957a427c8c85c37fcb67b3d5999dd372aa7 altered the way tooling is installed for podman making it incompatible with a c/automation_images pre-install.  Several attempts were made to update podman's scripts and Makefile to de-hardcode this.  All failed and/or were too complex.  Instead, abandon the effort entirely, allowing podman to suffer any consequential runtime-install flakes or other bad behaviors.
Signed-off-by: Chris Evich cevich@redhat.com

Combined with https://github.com/containers/automation_images/pull/238

https://github.com/containers/automation_images/pull/238 closed, re-opening this.

Note to me: Be sure to tag a new version after merging.


text:
Fix forget_grandchild retain condition

What type of PR is this?
/kind bug
What this PR does / why we need it:
I think the retain condition in ChildReaper::forget_grandchild was flipped.
The function passed to retain specifies which elements to keep, but the specified condition returned which element we want to remove. (docs)
That results in the removal of all grandchildren except the one we want to forget.
Which issue(s) this PR fixes:
None
Special notes for your reviewer:
I assume that the forget_grandchild function should remove the grandchild with pid == grandchild_pid and not keep it.
There could be existing use cases that depend on the fact, that the ChildReaper forgot the wrong grandchildren by accident.
I'm not sure, but it could be the case that conmon-rs didn't terminate spawned childs on exit because of this and will do this now. This could be a braking change? If this is the case, we should mention it in the release note block below.
Does this PR introduce a user-facing change?
None

Codecov Report

Merging #1505 (225c05f) into main (f132a00) will increase coverage by 0.44%.
The diff coverage is n/a.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1505      +/-   ##
==========================================
+ Coverage   34.18%   34.62%   +0.44%
==========================================
  Files          13       13
  Lines        1135     1135
  Branches      392      394       +2
==========================================
+ Hits          388      393       +5
+ Misses        493      483      -10
- Partials      254      259       +5

/lgtm

authors: codecov-commenter mgjm saschagrunert

repo: containers/conmon-rs


text:
More podman wiring

containers reasonably small refinements to vm functions as i have begun to wire up podman with libhvee.  some changes are based on testing and are simply fixes; otherwise new changes.

/lgtm

repo: containers/libhvee


text:
XDG_CONFIG_HOME ignored on linux

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
The XDG_CONFIG_HOME environment variable is ignored

Steps to reproduce the issue:
export XDG_DATA_HOME=/tmp/podman/local
export XDG_CONFIG_HOME=/tmp/podman/config
pkill podman
rm -rf $HOME/.local/share/containers $HOME/.config/containers/ $XDG_DATA_HOME $XDG_CONFIG_HOME
mkdir $XDG_DATA_HOME
mkdir $XDG_CONFIG_HOME
tree   $HOME/.local/share/containers $HOME/.config/containers/ $XDG_DATA_HOME $XDG_CONFIG_HOME
podman info
tree   $HOME/.local/share/containers $HOME/.config/containers/ $XDG_DATA_HOME $XDG_CONFIG_HOME

Describe the results you received:
% export XDG_DATA_HOME=/tmp/podman/local
% export XDG_CONFIG_HOME=/tmp/podman/config
% pkill podman
% rm -rf $HOME/.local/share/containers $HOME/.config/containers/ $XDG_DATA_HOME $XDG_CONFIG_HOME
% mkdir $XDG_DATA_HOME
% mkdir $XDG_CONFIG_HOME
% tree   $HOME/.local/share/containers $HOME/.config/containers/ $XDG_DATA_HOME $XDG_CONFIG_HOME
/home/dj/.local/share/containers [error opening dir]
/home/dj/.config/containers/ [error opening dir]
/tmp/podman/local
/tmp/podman/config

0 directories, 0 files
% podman info
host:
  BuildahVersion: 1.14.2
  CgroupVersion: v1
  Conmon:
    package: 'conmon: /usr/libexec/podman/conmon'
    path: /usr/libexec/podman/conmon
    version: 'conmon version 2.0.11, commit: '
  Distribution:
    distribution: debian
    version: "10"
  IDMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  MemFree: 255942656
  MemTotal: 8261079040
  OCIRuntime:
    name: runc
    package: 'runc: /usr/sbin/runc'
    path: /usr/sbin/runc
    version: |-
      runc version 1.0.0~rc6+dfsg1
      commit: 1.0.0~rc6+dfsg1-3
      spec: 1.0.1
  SwapFree: 9951842304
  SwapTotal: 9999216640
  arch: amd64
  cpus: 4
  eventlogger: journald
  hostname: fern
  kernel: 4.19.0-8-amd64
  os: linux
  rootless: true
  slirp4netns:
    Executable: /usr/bin/slirp4netns
    Package: 'slirp4netns: /usr/bin/slirp4netns'
    Version: |-
      slirp4netns version 0.4.3
      commit: unknown
  uptime: 8h 13m 41.47s (Approximately 0.33 days)
registries:
  search:
  - docker.io
  - quay.io
store:
  ConfigFile: /home/dj/.config/containers/storage.conf
  ContainerStore:
    number: 0
  GraphDriverName: vfs
  GraphOptions: {}
  GraphRoot: /tmp/podman/local/containers/storage
  GraphStatus: {}
  ImageStore:
    number: 0
  RunRoot: /run/user/1000/containers
  VolumePath: /tmp/podman/local/containers/storage/volumes

% tree   $HOME/.local/share/containers $HOME/.config/containers/ $XDG_DATA_HOME $XDG_CONFIG_HOME
/home/dj/.local/share/containers [error opening dir]
/home/dj/.config/containers/
└── storage.conf
/tmp/podman/local
└── containers
    └── storage
        ├── libpod
        │   └── bolt_state.db
        ├── mounts
        ├── storage.lock
        ├── tmp
        ├── vfs
        ├── vfs-containers
        │   └── containers.lock
        ├── vfs-images
        │   └── images.lock
        └── vfs-layers
            └── layers.lock
/tmp/podman/config

9 directories, 6 files
%

Describe the results you expected:
I expected that the configuration directory would be  $XDG_CONFIG_HOME/containers, i.e., /tmp/podman/config/containers and that the storage configuration file would be written there.
Additional information you deem important (e.g. issue happens only occasionally):
Output of podman version:
Version:            1.8.1
RemoteAPI Version:  1
Go Version:         go1.11.6
OS/Arch:            linux/amd64

Output of podman info --debug:
debug:
  compiler: gc
  git commit: ""
  go version: go1.11.6
  podman version: 1.8.1
host:
  BuildahVersion: 1.14.2
  CgroupVersion: v1
  Conmon:
    package: 'conmon: /usr/libexec/podman/conmon'
    path: /usr/libexec/podman/conmon
    version: 'conmon version 2.0.11, commit: '
  Distribution:
    distribution: debian
    version: "10"
  IDMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  MemFree: 481423360
  MemTotal: 8261079040
  OCIRuntime:
    name: runc
    package: 'runc: /usr/sbin/runc'
    path: /usr/sbin/runc
    version: |-
      runc version 1.0.0~rc6+dfsg1
      commit: 1.0.0~rc6+dfsg1-3
      spec: 1.0.1
  SwapFree: 9951842304
  SwapTotal: 9999216640
  arch: amd64
  cpus: 4
  eventlogger: journald
  hostname: fern
  kernel: 4.19.0-8-amd64
  os: linux
  rootless: true
  slirp4netns:
    Executable: /usr/bin/slirp4netns
    Package: 'slirp4netns: /usr/bin/slirp4netns'
    Version: |-
      slirp4netns version 0.4.3
      commit: unknown
  uptime: 8h 11m 15.78s (Approximately 0.33 days)
registries:
  search:
  - docker.io
  - quay.io
store:
  ConfigFile: /home/dj/.config/containers/storage.conf
  ContainerStore:
    number: 0
  GraphDriverName: vfs
  GraphOptions: {}
  GraphRoot: /tmp/podman/local/containers/storage
  GraphStatus: {}
  ImageStore:
    number: 0
  RunRoot: /run/user/1000/containers
  VolumePath: /tmp/podman/local/containers/storage/volumes

Package info (e.g. output of rpm -q podman or apt list podman):
Listing...
podman/unknown,now 1.8.1~1 amd64 [installed]
podman/unknown 1.8.1~1 arm64
podman/unknown 1.8.1~1 armhf
podman/unknown 1.8.1~1 ppc64el

Additional environment details (AWS, VirtualBox, physical, etc.):

@giuseppe PTAL

opened two PRs:
https://github.com/containers/common/pull/91
https://github.com/containers/storage/pull/562

it is fixed in master, closing the issue

authors: djerius giuseppe mheon

repo: containers/libpod


text:
Podman pod create now errors on receiving CLI args

It has never accepted arguments, so we should error when passed args we will never use.

I was bitten by this, yesterday.
LGTM

I was bitten by this, yesterday.
LGTM

LGTM

/lgtm

authors: TomSweeneyRedHat mheon rhatdan


text:
Implement detached exec

Implement detached exec for containers (ability to run a command in a container without attaching to it).
TODO:

Support for exec exit commands has been added, but they are not yet being used. Modify podman container cleanup so it can clean up an individual exec session and generate exit commands using it.
The APIv2 endpoint will need to be changed to use the new code once exit command generation is ready

This is mostly complete as it, though. podman exec -d is working; it's just never getting rid of the exec session without a container restart or removal.

Cleanup processes implemented.

Problem: we don't know enough at time of creation to know if we should add a cleanup process to remove the exec session. Thus, this works for local, but not remote.
I'm going to fix gating, add some local-only tests, and un-mark WIP so I can tackle this issue in a separate PR.

Test added. Dropping WIP.

@rhatdan @baude @vrothberg @giuseppe @TomSweeneyRedHat PTAL

Would like a nod from @jwhonce on the pkg/domain changes as well

/lgtm

authors: baude mheon


text:
Release v0.8.0

Release Process

[x] Create and push new release branch
Local release preparations (on the release branch)

[x] Run e2e tests
[x] Sync/tidy up dependencies.

[x] Run go mod tidy.
[x] Run git commit -m 'go.mod,go.sum: update dependencies.' go.{mod,sum}, if necessary.

[x] Run git tag -a -m "NRI plugins $VERSION" $VERSION.

Publishing

[x] Push the tag with git push $VERSION.
[x] Check that new container images are published for the tag.

for i in nri-resource-policy-topology-aware nri-resource-policy-balloons nri-resource-policy-template nri-config-manager nri-memory-qos nri-memtierd; do \
    skopeo inspect --format "$i: {{.Digest}}" docker://ghcr.io/containers/nri-plugins/$i:$VERSION;
done

[x] Finalize the new draft release created by CI

[x] Check that all artefacts (Helm charts) were uploaded
[x] Write the change log to the release.
[x] Get the change log OK'd by other maintainers.

[x] Publish the draft as a release.
[x] Verify that the Helm repo was updated
[x] Add a link to the tagged release in this issue.
[ ] Generate the operator bundle by running make bundle within deployment/operator directory and submit the generated content to the community-operators.

[ ] Create and push unannotated development tag X.Y.0-devel for next release cycle.
[ ] Close this issue.

Tagged release v0.8.0

repo: containers/nri-plugins


text:
rewrite-target invalid for kubernetes ingress on root path

Do you want to request a feature or report a bug?
Bug
What did you do?
Creating an Ingress resource on a subdomain having only one rule on / that point to a backend handling requests on /app.
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.class: traefik
    traefik.ingress.kubernetes.io/rewrite-target: /app
spec:
  rules:
  - host: app.my-domain.fr
    http:
      paths:
      - path: /
        backend:
          serviceName: my-app
          servicePort: http

What did you expect to see?
Traefik to send all requests with URLs on domain with app.my-domain.fr to my backend on path:

/ -> /app/
/foo/ -> /app/foo/

Same as nginx.ingress.kubernetes.io/rewrite-target behavior.
What did you see instead?
curl -s https://app.my-domain.fr/ | grep GET

Cannot GET /app

with a 404 status code.
But, request on https://app.my-domain.fr// (notice the additional / at end) give a 200 with expected response.
traefik version
In Kubernetes, installed with Helm chart stable/traefik v1.82.3
traefik-helm: traefik:1.7.19

What is your environment & configuration (arguments, toml, provider, platform, ...)?
Route rule (on dashboard):
PathPrefix:/;ReplacePathRegex: ^/(.*) /app$1
Host:app.my-domain.fr

# traefik.toml
logLevel = "info"
defaultEntryPoints = ["http","https"]
[entryPoints]
  [entryPoints.http]
  address = ":80"
  compress = true
  [entryPoints.https]
  address = ":443"
  compress = true
    [entryPoints.https.tls]
      [[entryPoints.https.tls.certificates]]
      CertFile = "/ssl/tls.crt"
      KeyFile = "/ssl/tls.key"
  [entryPoints.traefik]
  address = ":8080"
[ping]
entryPoint = "http"
[kubernetes]
ingressClass = "traefik"
[traefikLog]
  format = "json"
[accessLog]
  format = "json"
[accessLog.fields]
  defaultMode = "keep"
[accessLog.fields.names]
[accessLog.fields.headers]
  defaultMode = "keep"
[accessLog.fields.headers.names]
[api]
  entryPoint = "traefik"
  dashboard = true

Hello @seboudry,
You gave an example of what you expected to happen:

Hi @dtomcej !
Here's my working Nginx ingress definition:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress-nginx
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /app/
spec:
  rules:
  - host: app.my-domain.fr
    http:
      paths:
      - backend:
          serviceName: my-app
          servicePort: http

So indeed the target have a trailing slash and app listen on /app/, will expose it later for Treafik.
And I don't have to specify path: / on path rules spec as it's the default value (same behaviour with or without it).
Using Traefik, if I add a trailing slash with traefik.ingress.kubernetes.io/rewrite-target: /app/, it doesn't seems to be used.
Indeed, ReplacePathRegex rule doesn't include it.
Route rule (on dashboard):
PathPrefix:/;ReplacePathRegex: ^/(.*) /app$1
Host:app.my-domain.fr

If I remove path: / on path rules spec, nothing is applied (regardless of trailing slash is defined on rewrite-target).
Route rule (on dashboard):
Host:app.my-domain.fr

So it seems the fix is to have the trailing slash on rewrite-target annotation added to ReplacePathRegex rule.

Hello @seboudry
This behavior was last changed almost a year and a half ago with this PR:

There might be an edge case when the path matched is /

Yes, It works fine when path contains something without trailing slash (/testing in the PR example).
But when path is on root / it breaks.
Just giving a hand on Traefik since this week ;)
Like it but this issue will make migration from Nginx difficult.
I'm planning to use Traefik on a couple of services and then migrate whole on v2.

Ok, then let's change this title a bit.

Ok. So it is the edge case. Will look at making a PR.

Exactly!
And using the test requests from previous PR:
$ curl -v app.my-domain.fr/ -silent 2>&1 | grep GET

> GET / HTTP/1.1
GET /app/ HTTP/1.1

$ curl -v app.my-domain.fr/foo/ -silent 2>&1 | grep GET

> GET /foo/ HTTP/1.1
GET /app/foo/ HTTP/1.1

Thanks for the quick consideration of this! 👍

@seboudry, feel free to test with this PR to see if it works for you (it should).

PR tested OK ;)
https://github.com/containous/traefik/pull/6005#issuecomment-565009424

Closed by #6005.

authors: dtomcej seboudry traefiker

repo: containous/traefik


text:
Fixes 4339: add uploads API

Summary
Testing steps

Create a repository in the UI or Api
use the ./scripts/upload.py script to upload some repositories

IDENTITY_HEADER="eyJpZGVudGl0eSI6eyJvcmdfaWQiOiI5IiwgInR5cGUiOiJVc2VyIiwidXNlciI6eyJ1c2VybmFtZSI6ImZvbyJ9LCJhY2NvdW50X251bWJlciI6ImZvbyIsImludGVybmFsIjp7Im9yZ19pZCI6IjkifX19Cg==" python ./scripts/uploads.py      "8695b221-bf5d-4f5b-b544-43e563e0f558"  ~/rpms/crow-0.8-1.noarch.rpm   ~/rpms/foo-1.2.3.noarch.rpm

try with large RPMs, many rpms, etc...
Note, you'll need to make sure you use the same org in the identity header as you've used to create the repo

Fetch the repository and check the package_count, fetch the repository rpms  (/repositories/UUID/rpms)

check that a snapshot is made each time, and that the snapshots show the rpms that should be there

access the repo in pulp for the snapshots and verify expected rpms are present

Re-run the command with rpms that have already been uploaded, (or a mix of some that have and haven't), if there are no new rpms, no snapshot should be made

If you want run the command with  -f to finalize the uploads before adding them.  Note that this will fail if the rpms are already present in the org (we likely won't be using this method going forward)

Checklist

[ ] Tested with snapshotting feature disabled and pulp server URL not configured if appropriate

https://issues.redhat.com/browse/HMS-4339

/retest

/retest

feedback should now be addressed

added upload permissions to this PR in a new commit

https://issues.redhat.com/browse/HMS-4371

apparently the previous pr that tried to prevent creation/update of upload repos with snapshot set to false wasn't working properly.  I've adjusted here and added better tests.
In addition i added a catch at the start of the task so it won't panic


text:
Option to completely disable Richtext Commands dialogue box from 'field-editor-rich-text'

Hi there.
Is there a way to completely disable the functionality of the dialogue box / richtext commands? Currently, if you do not have embed as a selected option for the RTF, then a slash will result in a buggy situation where it doesn't display anything and locks the RTF field. Is there a way to make slashes work normally? Thank you :)

Will get this resolved directly through support.

repo: contentful/field-editors