text:
updated to v0.5.0, using git and not the tarball

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.

authors: conda-forge-linter rikigigi

repo: conda-forge/analisi-feedstock


text:
patch 1.2.0 to support ray 2.40

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] 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/meta.yaml) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe/meta.yaml:

ℹ No valid build backend found for Python recipe for package autogluon using pip. Python recipes using pip need to explicitly specify a build backend in the host section. If your recipe has built with only pip in the host section in the past, you likely should add setuptools to the host section of your recipe.
ℹ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.

For the host section of the recipe, you should usually use python {{ python_min }} for the python entry.
For the run section of the recipe, you should usually use python >={{ python_min }} for the python entry.
For the test.requires section of the recipe, you should usually use python {{ python_min }} for the python entry.
If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/12265078091. Examine the logs at this URL for more detail.

source: gharchive/pull-request

authors: conda-forge-admin suzhoum

repo: conda-forge/autogluon-feedstock

license_type: permissive

license_source: github-api


text:
release 0.0.1.dev2

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.

authors: conda-forge-linter wolfv

repo: conda-forge/boa-feedstock


text:
Target platform

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.

authors: conda-forge-linter isuruf

repo: conda-forge/cross-python-feedstock


text:
MNT: rerender

Hi! This is the friendly automated conda-forge-webservice.
I've started rerendering the recipe as instructed in #82.
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.

GitHub autogenerated artifacts fail to checksum as something changed in the autogeneration process again
Here is what we see on CI (attached log for posterity):
Traceback (most recent call last):
  File "/opt/conda/bin/conda-build", line 11, in <module>
    sys.exit(execute())
  File "/opt/conda/lib/python3.10/site-packages/conda_build/cli/main_build.py", line 590, in execute
    api.build(
  File "/opt/conda/lib/python3.10/site-packages/conda_build/api.py", line 250, in build
    return build_tree(
  File "/opt/conda/lib/python3.10/site-packages/conda_build/build.py", line 3638, in build_tree
    packages_from_this = build(
  File "/opt/conda/lib/python3.10/site-packages/conda_build/build.py", line 2419, in build
    try_download(m, no_download_source=False, raise_error=True)
  File "/opt/conda/lib/python3.10/site-packages/conda_build/render.py", line 762, in try_download
    source.provide(metadata)
  File "/opt/conda/lib/python3.10/site-packages/conda_build/source.py", line 1035, in provide
    unpack(
  File "/opt/conda/lib/python3.10/site-packages/conda_build/source.py", line 169, in unpack
    src_path, unhashed_fn = download_to_cache(
  File "/opt/conda/lib/python3.10/site-packages/conda_build/source.py", line 125, in download_to_cache
    raise RuntimeError(
RuntimeError: SHA256 mismatch: 'eb6d1b2cd881de0c14963ddb9cb7f3ec5df1b31370133267678265e31fb743b2' != 'ee7e3df43da7d924207e03efa4d5e5466801510b3e1f0377d425c6e6a8d823bb'

Think this is working as we can see lines like this on CI:
 Parsing headers in "['/home/conda/feedstock_root/build_artifacts/cuda-python_1719430415930/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/targets/x86_64-linux/include', '/home/conda/feedstock_root/build_artifacts/cuda-python_1719430415930/_build_env/targets/x86_64-linux/include']" (Caching False)

authors: conda-forge-admin jakirkham

repo: conda-forge/cuda-python-feedstock


text:
Windows support?

I am currently using the non-dev version on Windows, but I need PTX which seems to be included here. Is there some particular reason/complication for not supporting Windows right now?

it seems Windows is not supported since the beginning https://github.com/conda-forge/cudatoolkit-dev-feedstock/commit/c4e857426afe1a3e95106e3c610a57868d87cefd#diff-f3725a55bf339595bf865fec73bda8ac99f283b0810c205442021f29c06eea9aR16
I don't know the details, but feel free to open a PR adding the support for Windows.
probably the main files you should change would be https://github.com/conda-forge/cudatoolkit-dev-feedstock/blob/master/recipe/cudatoolkit-dev-post-install.py and the meta.yaml ... but maybe you would need to change other files as well, but at least these two files should be the main ones.
thanks!

Hello! We are also interested in windows support for cudatoolkit-dev, hence I have submitted a PR for this.
I would be very grateful for any feedback. I will also be grateful for any tips on building successfully with the github ci and conda-forge, since I am new to this.
I also would like to ask whether it is possible to build and deploy in conda-forge past cuda windows versions (especially cuda 10.1) if this PR is accepted. Thanks in advance!

I also would like to ask whether it is possible to build and deploy in conda-forge past cuda windows versions (especially cuda 10.1) if this PR is accepted. Thanks in advance!

@kidfisch I think that would be fine.
when we have https://github.com/conda-forge/cudatoolkit-dev-feedstock/pull/42 merged
the next step would be following these instructions https://conda-forge.org/docs/maintainer/updating_pkgs.html?highlight=branch#maintaining-several-versions
let me know if you have any questions! thank you for all the help!

@nnkwame @xmnlab
We are also in need of cudatoolkit-dev on windows for older cuda versions (eg 10.x).
Currently on conda-forge, I only see windows builds of cudatoolkit-dev for cuda 11.x.
Am I mistaken here? Are there plans to release builds for older cuda versions on win-64?
Thanks, any information appreciated!
Allen
@nnkwame had made this comment: "I also would like to ask whether it is possible to build and deploy in conda-forge past cuda windows versions (especially cuda 10.1) if this PR is accepted. Thanks in advance!"

I just created a new branch here: https://github.com/conda-forge/cudatoolkit-dev-feedstock/tree/10.x
feel free to open a PR to add the recipe for version 10. so you should open the PR to the branch 10.x (not to the main branch)
you can find something useful from the history: https://github.com/conda-forge/cudatoolkit-dev-feedstock/tree/e20bbc739df0e6029b4a78a274da9e76a21e8d15/recipe
thanks!

source: gharchive/issue

authors: allenleetc grudloff kidfisch xmnlab

repo: conda-forge/cudatoolkit-dev-feedstock


text:
Update to deepspeed v0.14.2

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.

Follow up on #57 that has merge issues.

@conda-forge-admin, please rerender

Still getting the same csrc/cpu/comm/ccl.cpp:8:10: fatal error: oneapi/ccl.hpp: No such file or directory error on the CUDA 11.8 and 12.0 builds as mentioned at https://github.com/conda-forge/deepspeed-feedstock/pull/56#issuecomment-2065192465. Has there been a bugfix for this upstream yet? We can try to patch things here if you can point me to the patch commit.

repo: conda-forge/deepspeed-feedstock


text:
Playing with python version

Checklist

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

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

authors: conda-forge-linter eacharles

repo: conda-forge/fermipy-feedstock


text:
Manual repair 4.13 without freezing

Checklist

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

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 ymontmarin

repo: conda-forge/hpp-corbaserver-feedstock


text:
@conda-forge-admin rerender

Additional comment:
No response

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I rerendered the recipe in conda-forge/metadetect-feedstock#31.

authors: beckermr conda-forge-linter

repo: conda-forge/metadetect-feedstock


text:
Remove osx arm64

Description
This pull request updates the build configuration files to:

Use netmod for specifying network modules (OFI and UCX).
Remove support for macOS (osx-arm64) for now.

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

repo: conda-forge/mvapich-feedstock


text:
Update meta.yaml

update to v0.1.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)
[ ] 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

repo: conda-forge/ncdata-feedstock


text:
Update nutpie to 0.2

Checklist

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

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

@conda-forge-admin, please rerender

authors: aseyboldt conda-forge-linter

repo: conda-forge/nutpie-feedstock


text:
Recipe for OCaml v4.02.0 (note licence terms)

The licensing changed from OCaml v4.03 onwards, along with splitting out bits like ocamlbuild into its own release.

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.

Sadly #3 also affects the older OCaml v4.02.0 as well.

@nsoranzo does this look sane from the point of view of using a new branch (4.02) for an older release?

Not knowing much about OCaml, it looks fine to me. For a more authoritative answer, let's ping @conda-forge/core .

I'm going to delay merging this until solving #3, the OCaml team have given some feedback so fingers crossed there.

New branch is okay for an old release if you think users might want the old ones. But yeah, waiting to fix the recipe first makes sense. :)

The recent recipe fixes included jumping to v4.06, so most of this is clearly obsolete.
As to the license, the good news is as of v4.03, https://ocaml.org/releases/4.03.html

The whole code base (compilers, libraries and tools) is now licensed under the LGPL v2.1 with static linking exception.

I remember now why I was working on v4.02 - it was specifically that I needed for ocamlbuild for another tool, and it looked like having this older version of ocaml in conda would be the simplest route forward.
It would be worth trying packaging the now separate ocamlbuild tool as a conda package...

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

Jinja2 variable definitions are suggested to take a {%<one space>set<one space><variable name><one space>=<one space><expression><one space>%} form. See lines [4, 5]
Using toolchain directly in this manner is deprecated.  Consider using the compilers outlined here.

authors: conda-forge-linter dougalsutherland nsoranzo peterjc

repo: conda-forge/ocaml-feedstock


text:
availability of pybel: from openbabel import pybel

Comment:
Hi,
I met the issue cannot import name 'pybel' from 'openbabel'. I am following the intruction for installation using :
conda config --add channels conda-forge
conda config --set channel_priority strict
conda install openbabel

it was shown successfully installed.  I can import openbabel just fine. Is there something that I miss? Thanks for your help!
I have checked the previous issue #8 , but it is not the same.

Environment (conda list):
packages in environment at /opt/anaconda3/envs/equcc:
 Name                    Version                   Build  Channel
bzip2                     1.0.8                h0d85af4_4    conda-forge
ca-certificates           2021.10.8            h033912b_0    conda-forge
cairo                     1.16.0            h9e0e54b_1010    conda-forge
expat                     2.4.7                h96cf925_0    conda-forge
font-ttf-dejavu-sans-mono 2.37                 hab24e00_0    conda-forge
font-ttf-inconsolata      3.000                h77eed37_0    conda-forge
font-ttf-source-code-pro  2.038                h77eed37_0    conda-forge
font-ttf-ubuntu           0.83                 hab24e00_0    conda-forge
fontconfig                2.13.96              h676cef8_2    conda-forge
fonts-conda-ecosystem     1                             0    conda-forge
fonts-conda-forge         1                             0    conda-forge
freetype                  2.10.4               h4cff582_1    conda-forge
gettext                   0.19.8.1          hd1a6beb_1008    conda-forge
icu                       69.1                 he49afe7_0    conda-forge
libcxx                    13.0.1               hc203e6f_0    conda-forge
libffi                    3.4.2                h0d85af4_5    conda-forge
libglib                   2.70.2               hf1fb8c0_4    conda-forge
libiconv                  1.16                 haf1e3a3_0    conda-forge
libpng                    1.6.37               h7cec526_2    conda-forge
libxml2                   2.9.12               h7e28ab6_1    conda-forge
libzlib                   1.2.11            h9173be1_1013    conda-forge
ncurses                   6.3                  he49afe7_0    conda-forge
openbabel                 3.1.1           py310he467037_3    conda-forge
openssl                   3.0.2                h6c3fc93_1    conda-forge
pcre                      8.45                 he49afe7_0    conda-forge
pip                       22.0.4             pyhd8ed1ab_0    conda-forge
pixman                    0.40.0               hbcb3906_0    conda-forge
python                    3.10.4          h1cc4136_0_cpython    conda-forge
python_abi                3.10                    2_cp310    conda-forge
readline                  8.1                  h05e3726_0    conda-forge
setuptools                60.10.0                  pypi_0    pypi
sqlite                    3.37.1               hb516253_0    conda-forge
tk                        8.6.12               h5dbffcc_0    conda-forge
tzdata                    2022a                h191b570_0    conda-forge
wheel                     0.37.1             pyhd8ed1ab_0    conda-forge
xz                        5.2.5                haf1e3a3_1    conda-forge
zlib                      1.2.11            h9173be1_1013    conda-forge

Details about conda and system ( conda info ):
 active environment : equcc
    active env location : /opt/anaconda3/envs/equcc
            shell level : 2
       user config file : /Users/feiranl/.condarc
 populated config files : /Users/feiranl/.condarc
          conda version : 4.8.5
    conda-build version : 3.18.9
         python version : 3.7.4.final.0
       virtual packages : __osx=10.16
       base environment : /opt/anaconda3  (writable)
           channel URLs : https://conda.anaconda.org/conda-forge/osx-64
                          https://conda.anaconda.org/conda-forge/noarch
                          https://repo.anaconda.com/pkgs/main/osx-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/osx-64
                          https://repo.anaconda.com/pkgs/r/noarch
          package cache : /opt/anaconda3/pkgs
                          /Users/feiranl/.conda/pkgs
       envs directories : /opt/anaconda3/envs
                          /Users/feiranl/.conda/envs
               platform : osx-64
             user-agent : conda/4.8.5 requests/2.22.0 CPython/3.7.4 Darwin/21.3.0 OSX/10.16
                UID:GID : 45692255:20
             netrc file : None
           offline mode : False

Hello,
When you say that you can import openbabel, did you use that wording? Non from openbabel import openbabel? In that case, there seems like you have a mismatch between the conda environment and the python used to run the code.

Thanks! It has been solved!

For future measurement, could you elaborate on how it was solved? I'm closing this issue btw.

I was trying to import openbabel in Python3.8.8 before. After changing to python3.10.4, it was ok.

I have the question, I met the issue - [ cannot import name 'pybel' from 'openbabel'] when I use - [ from 'openbabel' import 'pybel'] as well. So I tried to use - [ import 'openbabel' as 'op'], which was succeed. However, I was faild when I use - [ from 'openbabel' import 'openbabel'].

Then you have an old version of OpenBabel installed. How did you install? Did you use conda install -c conda-forge openbabel? Are you sure that you have the correct conda environment activated? If so, you could try conda update -c conda-forge openbabel to get a newer OpenBabel.

Thank you, let me try.^^
At 2022-07-08 17:03:18, "fredrikw" @.***> wrote:
Then you have an old version of OpenBabel installed. How did you install? Did you use conda install -c conda-forge openbabel? Are you sure that you have the correct conda environment activated? If so, you could try conda update -c conda-forge openbabel to get a newer OpenBabel.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>

Thank you for your help, I have followed your advice but I still haven't succeed. Python is too difficult for me. ：(

authors: feiranl fredrikw lzhzzzzwill

repo: conda-forge/openbabel-feedstock


text:
Update to version 3.3.0a67

Checklist

[x] Used a 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.

Update to alpha67

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 restart CI

@conda-forge-admin, please restart CI

@conda-forge-admin , please restart CI

@conda-forge/core. The build keeps failing for Python 3.6 on Windows only due to dependency conflicts/incompatibilities which I don't understand. Officially this package doesn't support python 3.6 anyway (only 2.7 and 3.7 onwards), so are you ok with if I omit the failing build?

@conda-forge-admin, please rerender

You can add this to the build section and then rerender
build:
  ...
  skip: True  # [not (py>36 or py2k)]

This should skip python 3.6.

Closed in favor of https://github.com/conda-forge/opensesame-feedstock/pull/2

authors: beckermr conda-forge-linter dschreij

repo: conda-forge/opensesame-feedstock


text:
Remove upper bound on cryptography version to match upstream

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.

Resolves #20 by matching constraints in upstream repo to remove the upper bound.

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 tpdownes

repo: conda-forge/pyjwt-feedstock


text:
MNT: Re-render the feedstock

Hi! This is the friendly conda-forge-admin automated user.
I've re-rendered this feedstock with the latest version of conda-smithy (0.10.3) and noticed some changes.
If the changes look good, then please go ahead and merge this PR.
If you have any questions about the changes though, please feel free to ping the 'conda-forge/core' team (using the @ notation in a comment).
Remember, for any changes to the recipe you would normally need to increment the version or the build number of the package.
Since this is an infrastructural change, we don't actually need/want a new version to be uploaded to anaconda.org/conda-forge, so the version and build/number are left unchanged and the CI has been skipped.
Thanks!

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-admin conda-forge-linter

repo: conda-forge/pykml-feedstock


text:
switch to grayskull update

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.

@conda-forge-admin, please rerender

repo: conda-forge/pymatgen-feedstock


text:
Update to 2.1.0

Checklist

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

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

@conda-forge-admin, please rerender

authors: conda-forge-linter rly

repo: conda-forge/pynwb-feedstock


text:
MNT: Re-render the feedstock [ci skip]

Hi! This is the friendly conda-forge-admin automated user.
I've re-rendered this feedstock with the latest version of conda-smithy (2.2.2) and noticed some changes.
If the changes look good, then please go ahead and merge this PR.
If you have any questions about the changes though, please feel free to ping the 'conda-forge/core' team (using the @ notation in a comment).
Remember, for any changes to the recipe you would normally need to increment the version or the build number of the package.
Since this is an infrastructural change, we don't actually need/want a new version to be uploaded to anaconda.org/conda-forge, so the version and build/number are left unchanged and the CI has been skipped.
Thanks!

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.

repo: conda-forge/pysolr-feedstock


text:
Remove Ostrich dependency on Windows

Checklist

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

repo: conda-forge/ravenpy-feedstock


text:
Removed the slugify dependency

According to the upstream requirements.txt this depends on python-slugify not slugify which are two different packages on PyPi. This causes a ClobberWarning when both are installed. See https://github.com/conda-forge/python-slugify-feedstock/issues/33 for more information on the ClobberWarning.

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] 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/sphinx-material please consider merging this: it's likely no version of this theme is presently installable.

Can this be merged? sphinx material can no longer be installed with conda.

@mxr-conda @ndmaxar @oblute @rluria14 Can someone please review this and merge it in? Sphinx-material theme is completely broken right now due to the double dependency.
FWIW, someone from my org would be willing to be added as a feedstock maintainer here since we depend on this pretty heavily internally (if y'all are open to that).

We're well over the week threshold of radio silence from @conda-forge/sphinx-material, at this point.
This means someone who cares about this package can:

make a bot command issue to @conda-forge-admin, please add user @username themselves
ask @conda-forge/core to merge it (linking to this PR)
merge this PR

As I don't, particularly, care about this feedstock, I'm unsubscribing: good luck!

@conda-forge/core can you merge this and also add us as maintainers? Thanks.

Happy to merge if you add yourself as maintainer :)

@conda-forge-admin please rerender

Thanks.

authors: FaustinCarter bollwyvl hmaarrfk moorepants wolfv

repo: conda-forge/sphinx-material-feedstock


text:
[REL] - 2024.11.1

Release details
Scheduled release date - <2024/11/08>
Release captain responsible - @soapy1 @peytondmurray

1. Pre-flight checks

[x] Ensure there are no open issues with a block-release ⛔ label

2. Prepare the codebase for a new release

[x] Create a new git branch for the release git checkout -b release-2024.9.1

[x] Prepare the branch just in case git clean -fxdq

[x] Bump conda-store version in conda-store/conda-store/__init__.py

[x] Bump conda-store-server version in conda-store-server/conda-store-server/__init__.py

[x] Update the conda-store-ui version used in conda-store-server conda-store-server/hatch_build.py

[x] Update the CHANGELOG.md file with the new version, release date, and relevant changes[^github-activity].

[x] Check the version locally with hatch version

[x] Build and test locally

[x] For conda-store and conda-store-server:
# Note you will need to run this twice, once for each package
cd conda-store # or cd conda-store-server
hatch build
twine check dist/*
hatch clean

[x] After building conda-store-server and before hatch clean run the server in standalone mode:
cd conda-store-server
conda-store-server --standalone

To do a manual inspection of the build and ui vendoring process.

[x] Make a release commit: git commit -m 'REL - 2024.9.1'

[x] Push the release (REL) commit git push upstream main

[x] If a release candidate is needed, tick this box when we're ready for a full release.

3. Make the release

[x] Start a new GitHub release

Call the release the current version, e.g. 2024.9.1
In the Choose a Tag: dropdown, type in the release name (e.g., 2024.9.1) and click "Create new tag"
In the Target: dropdown, pin it to the release commit you've recently pushed.
Add release notes in the field below[^github-activity]; you can copy/paste the Changelog from the CHANGELOG.md file.

[x] Confirm that the release completed

The release GitHub action job has completed successfully in the actions tab.
The conda-store PyPI version is updated
The conda-store-server PyPI version is updated
The Docker images have been published

[ ] Update the conda-forge feedstock version through a PR or review and merge the regro-bot PR.

[ ] If needed - update meta.yaml or recipe.yaml and re-render the feedstock.

[ ] Open a follow-up PR to bump conda-store and conda-store-server versions to the next dev-release number (for example 2024.10.1).
[ ] Open a follow-up PR to bump the conda-store-server version in the conda-store-ui compose file.
[ ] Celebrate, you're done! 🎉

[^github-activity]: If you wish, use github-activity to generate a Changelog, e.g. github-activity conda-incubator/conda-store --since 2024.9.1 --until 2023.10.1.

Waiting on the conda-forge feedstock PR to be generated...

Blocked until https://github.com/conda-incubator/conda-store/pull/973 gets merged.

repo: conda-incubator/conda-store


text:
/relock-conda command does not work on draft PRs

The relock command fails for draft PRs.

Well the tests run on a draft PR, so this is no right. closing.

repo: conda-incubator/relock-conda


text:
Provide "dry-run" functionality

Checklist

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

What is the idea?
The current (and in development?) API supports the ability to create and remove shortcuts by pointing to a path or providing a dictionary of metadata.
Why is this needed?
In some cases it is nice to know what will happen without actually running the creation or removal process.
What should happen?
Provide a parameter or flag so that the result of create/remove is the same, but without actually executing the process of creation or removal in a similar vein to the "--dry-run" functionality of condaProvide a parameter or flag so that the result of create/remove is the same, but without actually executing the process of creation or removal in a similar vein to the "--dry-run" functionality of conda
Additional Context
No response

not stale

This standard feature seems like a good idea

authors: goanpeca jaimergp jypeter

repo: conda/menuinst


text:
New tee type: CCA (Confidential Compute Architecture)

CCA verifier is actually done by forwarding the evidence to Verasion[1].
[1] https://github.com/veraison/services

/cc @Xynnn007 @jialez0 @sameo
This is ready for review now, thanks!

thanks @Xynnn007 for the review, I am still ramp up the rust :)

@Xynnn007 all comments either addressed or replied, pls take another look, thanks!

hey @chendave please rebase the code as https://github.com/confidential-containers/attestation-service/pull/125 is merged. Let's see whether the CI will be happy

rebased to fix merge conflict + return error if attestation failed

kindly ping @sameo Can you pls take a look?

@chendave I don't think this is the right architecture for an AS verifier.
I suggest you take a look at how https://github.com/confidential-containers/kbs/pull/77 added support for Amber+TDX verification, I would expect Veraison+CCA) to be added in much the same way in github.com/confidential-containers/kbs, not in this repository.

I suggest you take a look at how https://github.com/confidential-containers/kbs/pull/77 added support for Amber+TDX verification, I would expect Veraison+CCA) to be added in much the same way in github.com/confidential-containers/kbs, not in this repository.

Before Amber was added we had discussed supporting external verifiers in the AS with a proxy approach. I'm not totally sure why Amber wasn't implemented like that. I wouldn't necessarily say that the Amber PR rules out doing the kind of integration we have here.

I suggest you take a look at how https://github.com/confidential-containers/kbs/pull/77 added support for Amber+TDX verification, I would expect Veraison+CCA) to be added in much the same way in github.com/confidential-containers/kbs, not in this repository.

Hi @jepio, thanks for the comments! We do think about that, both of approaches should workable for us, I think the major consideration is that we want cca to feature parity with other verifier, i.e. have a cca verifier to validate the cca token (evidence), besides, I didn't see a clear guideline that an external verifier must go with kbs like Amber.
Initially, we consider to rustify the core component from Verasion here for verification but the efforts is not trivial per our estimation.

Before Amber was added we had discussed supporting external verifiers in the AS with a proxy approach. I'm not totally sure why Amber wasn't implemented like that. I wouldn't necessarily say that the Amber PR rules out doing the kind of integration we have here.

@fitzthum thanks for providing the context of Amber.

Before Amber was added we had discussed supporting external verifiers in the AS with a proxy approach. I'm not totally sure why Amber wasn't implemented like that. I wouldn't necessarily say that the Amber PR rules out doing the kind of integration we have here.

I don't think this approach makes sense any longer, with the features recently implemented in KBS (passport model support, verifying externally issued attestation tokens). For one, different attestation services place different requirements on how to include user data (pubkey/nonce/...) in the attestation report/token, eg. Amber requires SHA512, MAA requires SHA256 of a JSON doc, CoCo AS uses SHA384. So trying to "proxy" from CoCo AS to another AS (like Veraison) will immediately hit this restriction (and other limitations) and so be of limited practical use.
Integrating Veraison in KBS (especially now with passport model support) as another attestation service makes way more sense.

Hi @jepio, thanks for the comments! We do think about that, both of approaches should workable for us, I think the major consideration is that we want cca to feature parity with other verifier, i.e. have a cca verifier to validate the cca token (evidence), besides, I didn't see a clear guideline that an external verifier must go with kbs like Amber.
Initially, we considered to rustify the core components from Verasion here for verification but the efforts is not trivial per our estimation.

No worry, a rust evidence verifier for CoCo AS can be implemented later. But Veraison works as a full-blown Attestation Service equivalent to CoCo AS (policy engine, reference value store) so the cleaner architecture overall would be to support it in KBS, since it matches existing abstractions and communication patterns.

Before Amber was added we had discussed supporting external verifiers in the AS with a proxy approach. I'm not totally sure why Amber wasn't implemented like that. I wouldn't necessarily say that the Amber PR rules out doing the kind of integration we have here.

I don't think this approach makes sense any longer, with the features recently implemented in KBS (passport model support, verifying externally issued attestation tokens). For one, different attestation services place different requirements on how to include user data (pubkey/nonce/...) in the attestation report/token, eg. Amber requires SHA512, MAA requires SHA256 of a JSON doc, CoCo AS uses SHA384. So trying to "proxy" from CoCo AS to another AS (like Veraison) will immediately hit this restriction (and other limitations) and so be of limited practical use.

In verasion's repo, it supplies the challenge-response document. It is somehow similiar with RCAR protocol for KBS. The context of AS/KBS shows that we should have the following two parts:

An attestation service that verifies the evidence due to the OPA and Endorsements, and then returns the attestation token that includes the attestation results. Like current AS. This service does not care what is included inside the user data. It only checks the TCB information inside the evidence.
An attestation protocol that works over the attestation service, providing anti-replay, integrity and other properties. Like current KBS RCAR protocol and challenge-response protocol in verasion. It uses the attestation service to check the trustiness of TCB, and also uses the attestation service to extract the user data that should be used in the protocol.

@jepio points out that verasion can work as a combination of an attestation service and an attestation protocol. In this way, it is better for verasion to be an entity that equals to KBS. That means a direct attestation client in the guest to request verasion for tokens.
For CoCo KBS/AS, it is better to only use part 1. That means CoCo KBS provides the attestation protocol and verasion provides the attestation service. But I am not sure whether verasion can work only as an attestation service.
WDYT? @chendave @fitzthum

This service does not care what is included inside the user data. It only checks the TCB information inside the evidence.

An attestation protocol that works over the attestation service, providing anti-replay, integrity and other properties.

For something I can tell, verasion doesn't check some data, e.g. client challenge (nonce passed in guest to get the token), since verasion doesn't have such knowledge, it receives a cca token and does the verification against this token.
So, it doesn't have the ability to avoid the anti-replay you mentioned here, but I would say as a verifier, verasion has the ability to check the integrity of the cca token (based on the token layout, and provision service defined in the verasion).
Overall, verasion does,

integrity check after the parse of the token from cbor to json claims. (depends on the initial attestation key provisioned by provision service).
compare the claims with the reference value (depends on the endorsement provisioned by provision service).

But I am not sure whether verasion can work only as an attestation service.

yes, this pr is using the verasion as an attestation service.

I am still skeptical of the Amber integration, so I don't think we should use that as a model.
I guess we have recently changed AA/CDH to separate the token provider from the resource provider, which might make it more feasible to use something like veraison as a token provider while still getting resources from somewhere else. I think conceptually it might be a little bit simpler to stick with the current approach.

I am still skeptical of the Amber integration, so I don't think we should use that as a model.

I'm curious what makes you skeptical but don't want to derail the discussion too much. I'd like to see us use the same model for Amber and Veraison, whichever model that is.

I guess we have recently changed AA/CDH to separate the token provider from the resource provider, which might make it more feasible to use something like veraison as a token provider while still getting resources from somewhere else. I think conceptually it might be a little bit simpler to stick with the current approach.

There are three tasks that KBS has:

attestation evidence verification
token generation
resource retrieval

KBS offloads to either Amber or CoCo AS for 1), but does 2) itself. KBS supports a passport configuration that does only 1) and 2). Amber (and MAA) can do 1) and 2) but the KBS integration uses Amber for 1) and then discards the token that Amber generated and generates its own token. Veraison would fit nicely in this model.
You could also have AA talk to Amber/MAA/Veraison directly to retrieve a token. The token could then be passed to KBS for resource retrieval. This does not currently fit with AA design though.

After some constructive discussion with @chendave , we reached some agreements.
As Veraison is somehow similiar to current CoCo-AS, s.t. has both attestation service and reference value things. We might have three methods to support Arm CCA that are not mutually exclusive.
Way 1: CCA as a verifier driver
As @fitzthum suggests
This should have two phases. Phase 1 is as this PR. Veraison plays the role of CCA driver. The reason is that veraison is the only thing we can use to verify a CCA evidence.

Phase 2 can be done in future when Arm CCA rust native verifier driver is ready. We can replace the veraison with the driver at that time.

Way 2: Veraison as an attestation service
As @jepio suggests

Way 3: Veraison as a attestation token plugin in attestation agent
Way 1 and Way 2 aims to return a KBS token to the guest after verifying CCA evidence. Way 3 does not involve KBS/AS and directly returns veraison EAR (attestation token) to the attestation agent. The EAR (attestation token) can then be used by CDH or app container.

Summary

Way
Application scenario

way 1
CoCo-AS/KBS can support multi archs

way 2
Arm CCA is the only Tee arch in the context

way 3
no KBS/AS is required to be deployed by the user

Three ways are not exclusive! We can support three ways at the same time, and use any of them who meets the application scenario.
Thus this PR now seems good to me.

thanks @Xynnn007  for such detail clarification!
@Xynnn007 @fitzthum @jepio  I addressed or replied all the comments, could you pls take a look again? thanks!

After some constructive discussion with @chendave , we reached some agreements.
As Veraison is somehow similiar to current CoCo-AS, s.t. has both attestation service and reference value things. We might have three methods to support Arm CCA that are not mutually exclusive.

Thanks for clarifying all the different options @Xynnn007
I think one thing we need to clarify here is that the goal of this PR is to support ARM's confidential computing implementation, not yet another attestation service. So our end goal, as far as the Attestation Service project is concerned, should be way 1, phase 2 (CCA verifier). We want the AS to be a standalone component that can support as many hardware TEEs as possible, and CCA is a hardware TEE. I understood from @chendave last week presentation that this was the goal. So iiuc this PR is an an intermediate step, in which case it's fine with me.
The other acceptable option is way 2, when e.g. we want to support a different attestation service (e.g. Veraison or Amber). If we want to support the Veraison attestation service, we should submit a different PR for that purpose. This one here aims at supporting CCA.
Way 3 is out of scope for the AS.

thanks @sameo for the wrap up!  and thanks @fitzthum  @jepio @Xynnn007 @jialez0 for the review, if there is no more objection, can we merge this? so that it will be included in the latest release.

authors: Xynnn007 chendave fitzthum jepio sameo


text:
Update runtime payload runtimeclassname

This PR updates the peer pod fork of the runtime payload to install to the kata-remote runtime class.
This is in prep for us switching over to the upstream coco operator rather than using our own fork.
I don't think there is any automation for building the payload image, so this is fairly safe to merge, but then we will need to build the runtime-payload manually and follow up with the doc, webhook and e2e compatible fixes in #904

To limit the chances of having broken changes I suggest we review this and #904 at the same time then the flow is:

Merge #903
Manually rebuild quay.io/confidential-containers/peer-pods-runtime-payload
Merge #904

The clock for breaking changes exists once the peer-pods-runtime-payload is pushed

@stevenhorsman weren't we suppose to remove the custom payload from this repo and solely rely on the kata-containers payload that is used with operator and have the remote hypervisor config ?

@stevenhorsman weren't we suppose to remove the custom payload from this repo and solely rely on the kata-containers payload that is used with operator and have the remote hypervisor config ?

Yes, but we seemed to all agree that doing it in stages was the best way to limit the breaking changes, so switching to the coco operator is in #870 and the removal of the custom payload is part of #871. If you want to merge all of these changes into a single PR we can, but I think it will be very disruptive to upstream and any downstream projects to switch it all over in a single go?

Yes, but we seemed to all agree that doing it in stages was the best way to limit the breaking changes, so switching to the coco operator is in #870 and the removal of the custom payload is part of #871. If you want to merge all of these changes into a single PR we can, but I think it will be very disruptive to upstream and any downstream projects to switch it all over in a single go?

I see.  I don't have any concern with the approach. Just wanted to ensure that there is no duplication.

I see. I don't have any concern with the approach. Just wanted to ensure that there is no duplication.

Thanks, it is a little bit wasteful fixing up (and updating) the old peer-pods-runtime-payload before we remove it, but I hope it de-risks the switch, so it's a trade off that I'm happy to make. Looking forward to getting rid of the duplicated code soon though :)

authors: bpradipt stevenhorsman


text:
Implement CreditCard Cfgu Type

Closes #142

@SanchitMahajan236 thanks for this PR!

@SanchitMahajan236 notice you have got a lint error. please fix it so we can merge 🙏 .

Hi @SanchitMahajan236,
I noticed you decided to close this PR, and I was curious about the reason. It was approved and just needed the small adjustment that David mentioned before merging. If you’ve encountered any issues or need assistance with the final changes, feel free to let us know—we’re happy to help.
Thanks!

I ran through some problem at my end and to get it sorted I had to delete the repo and fork it again that is why I have generated a new PR #485 . Sorry, for the inconvenience caused by me.

repo: configu/configu


text:
Deploy Connectors in a RBAC cluster

Description
This PR adds a new feature to deploy connectors on a RBAC cluster. Along with that, deploying connectors with mutual TLS is also supported in this PR.
Fixes # ANSIENG-2939
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] This change requires a documentation update

How Has This Been Tested?
tested in on-demand job
Checklist:

[x] Any variable/code changes have been validated to be backwards compatible (doesn't break upgrade)
[x] I have added tests that prove my fix is effective or that my feature works
[ ] If required, I have ensured the changes can be discovered by cp-ansible discovery codebase
[x] My code follows the style guidelines of this project
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] Any dependent changes have been merged and published in downstream modules

Thank you @mansisinha this should fix my issue https://github.com/confluentinc/cp-ansible/issues/1413

Thank you @mansisinha this should fix my issue #1413

great! However, please note that since it is a new feature in CP-Ansible, we will introduce this in upcoming minor release 7.6.0, so you would need to upgrade to 7.6.0 to use it

authors: ElfoLiNk mansisinha

repo: confluentinc/cp-ansible


text:
Validate SR URIs to only allow http and https schemes

Connection validations should ensure that Schema Registry URIs only use https or http schemes.

@rhauch Do you think it's worth adding a validation check on the Form input for this ?

@noeldevelops, yes, it probably would be a faster UX if they enter an invalid URL.

authors: noeldevelops rhauch

repo: confluentinc/ide-sidecar


text:
Eliminate protobuf dependencies when using useBinaryFormat: false

Is your feature request related to a problem? Please describe.
I would like a smaller package when not using protobuf serialization.
Both the ConnectRPC protocol and grpc-web (application/grpc-web+json) support JSON encoding as an alternative to protobuf. In these schemes, most of the protobuf logic is not necessary. These libraries take up a significant portion of a package (67% of the 55kb in this example).
   ├ node_modules/@bufbuild/protobuf/dist/esm/private/json-format.js                    7.6kb   14.2%
   ├ node_modules/@bufbuild/protobuf/dist/esm/private/binary-format.js                  4.5kb    8.5%
   ├ node_modules/@bufbuild/protobuf/dist/esm/binary-encoding.js                        3.8kb    7.2%
   ├ node_modules/@bufbuild/protobuf/dist/esm/private/util-common.js                    2.6kb    4.8%
   ├ node_modules/@bufbuild/protobuf/dist/esm/google/protobuf/any_pb.js                 2.4kb    4.5%
   ├ node_modules/@bufbuild/protobuf/dist/esm/google/varint.js                          2.1kb    3.8%
   ├ node_modules/@bufbuild/protobuf/dist/esm/proto-int64.js                            1.4kb    2.7%
   ├ node_modules/@bufbuild/protobuf/dist/esm/extension-accessor.js                     1.1kb    2.1%
   ├ node_modules/@bufbuild/protobuf/dist/esm/message.js                                1.0kb    1.9%
   ├ node_modules/@bufbuild/protobuf/dist/esm/proto-base64.js                           950b     1.7%
   ├ node_modules/@bufbuild/protobuf/dist/esm/private/extensions.js                     794b     1.5%
   ├ node_modules/@bufbuild/protobuf/dist/esm/private/scalars.js                        720b     1.3%
   ├ node_modules/@bufbuild/protobuf/dist/esm/private/field-normalize.js                688b     1.3%
   ├ node_modules/@bufbuild/protobuf/dist/esm/private/field-list.js                     664b     1.2%
   ├ node_modules/@bufbuild/protobuf/dist/esm/private/enum.js                           631b     1.2%
   ├ node_modules/@bufbuild/protobuf/dist/esm/private/names.js                          619b     1.1%
   ├ node_modules/@bufbuild/protobuf/dist/esm/private/reflect.js                        618b     1.1%
   ├ node_modules/@bufbuild/protobuf/dist/esm/private/assert.js                         608b     1.1%
   ├ node_modules/@bufbuild/protobuf/dist/esm/private/message-type.js                   489b     0.9%
   ├ node_modules/@bufbuild/protobuf/dist/esm/scalar.js                                 461b     0.8%
   ├ node_modules/@bufbuild/protobuf/dist/esm/private/field.js                          442b     0.8%
   ├ node_modules/@bufbuild/protobuf/dist/esm/private/field-wrapper.js                  424b     0.8%
   ├ node_modules/@bufbuild/protobuf/dist/esm/proto3.js                                 322b     0.6%
   ├ node_modules/@bufbuild/protobuf/dist/esm/is-message.js                             285b     0.5%
   ├ node_modules/@bufbuild/protobuf/dist/esm/service-type.js                           275b     0.5%
   ├ node_modules/@bufbuild/protobuf/dist/esm/private/proto-runtime.js                  261b     0.5%

Describe the solution you'd like
I would like to rely solely on JSON.parse and JSON.stringify and eliminate protobuf from the dependency tree. Unfortunately, the protobuf package is scattered around the tree. This would likely require changes to the generated code.
While this is relevant to both Node and Web client implementations, it is more important for web.
Describe alternatives you've considered
I have tried various tree shaking and deadcode elimination techniques but have not had much success. Snipping code (i.e., replacing with stubs) is effective but cumbersome and prone to regressions.
Additional context
This is very similar--and possibly identical--to https://github.com/connectrpc/connect-es/issues/1030.
Thanks!

This is not as simple as it may seem. A simple message serializes as expected with JSON.stringify, but bytes (Uint8Array), int64 (BigInt) and several other types and constructs do not. To serialize or parse between the Protobuf JSON format and the generated class, schema information is required.
Protobuf-ES V2 supports JSON types. They match the Protobuf JSON format, which allows us to potentially provide clients that accept and return these JSON types, and do not require schema information.
In the upcoming version 2 of Connect-ES (see release candidate here), we are updating the Connect packages to support Protobuf-ES version 2, but we do not decouple from the Protobuf JSON and binary formats yet (more details in https://github.com/connectrpc/connect-es/issues/1233#issuecomment-2355138379).
I'm closing this to consolidate in #1030. Thanks for the issue!

Thanks for the quick reply! That makes perfect sense that it would need a pass to recursively transform all the typed arrays (plus any serialized i64). It would still end up being much simpler without all of the varint machinery, etc., but definitely not trivial! It makes sense to close in favor of that issue.
Thanks for the information on the RC. Cheers!

authors: kjvalencik timostamm

repo: connectrpc/connect-es


text:
As a user, I want to see metrics about a given stableswap pool in the Pool UI

Problem
The cartographer should expose pool metrics that can be queried by developers or ingested by the SDK.
Ideas to solve this
For each stableswap pool, the following metrics are needed:

liquidity - current amount in USD
volume - by day (24h), week, month, year, total
fees - by day (24h), week, month, year, total
apy - by day (24h), week, month, year, total

Acceptance Criteria

[ ] able to query cartographer for pool liquidity
[ ] able to query cartographer for pool volume
[ ] able to query cartographer for pool fees
[ ] able to query cartographer for pool apy

Dependent tasks
https://github.com/connext/nxtp/issues/1535

Launch Blocker:

Liquidity
Next up:
Volume
Fees
APY

split this up @alexwhte

Break out fees and APY from Beta

Per @wanglonghong  on July (closed task) for posterity
We should be able to fetch the events in both cases
[case 1] - Internal StableSwap --> we need to update the events of swapUtils because all the events of swapUtils doesn't include canonicalId. cc @LayneHaber
[case 2] - External StableSwap --> In case we deploy stableswap contract externally, we should be able to handle events in the same subgraph.

authors: alexwhte just-a-node

repo: connext/nxtp

license: MIT


text:
Arbitrum Nova subgraph issues

Describe the bug
The Arbitrum Nova subgraph appears to be unreachable or missing. This (I believe) causes a "Not enough bridge liquidity to complete transfer. Use a smaller amount." error to appear when trying to transfer TO Arbitrum Nova.
To Reproduce
Steps to reproduce the behavior:

Go to https://bridge.connext.network/
Select destination chain Arbitrum Nova
Select origin chain BNB/Arbitrum/Optimism/Polygon (all of these are supported by the router with USDC liquidity)
Choose an amount like 100 USDC
See error (the estimated received will appear because a bid was received, but the site will still show not enough liquidity)

Expected behavior
The Arbitrum Nova subgraph should work correctly.
Additional context
It seems that after some time the subgraph loaded, and now the error doesn't show up and the subgraph data appears correctly in the status page of the explorer. This may be a temporary/intermittent issue.
Screenshots

This is temporary/intermittent, unfortunately won't fix this.


text:
how to integrate with detectron2?

how to integrate with detectron2?

@jinfagang This Link @

authors: LEE-SEON-WOO jinfagang

repo: conradry/copy-paste-aug


text:
ERC-20 ： 添加 SAFE价格显示

block.cc 链接：https://mifengcha.com/coin/safe
代币简称：SAFE
合约地址：0xEE9c1Ea4DCF0AAf4Ff2D78B6fF83AA69797B65Eb
Etherscan 链接：https://etherscan.io/token/0xEE9c1Ea4DCF0AAf4Ff2D78B6fF83AA69797B65Eb

block.cc 链接：https://mifengcha.com/coin/safe
代币简称：SAFE
合约地址：0xEE9c1Ea4DCF0AAf4Ff2D78B6fF83AA69797B65Eb
Etherscan 链接：https://etherscan.io/token/0xEE9c1Ea4DCF0AAf4Ff2D78B6fF83AA69797B65Eb

authors: CryptoCoinLab Tochipeter

repo: consenlabs/token-profile


text:
🛑 nulsidecouvert.org is down

In 0e030e1, nulsidecouvert.org (https://www.nulsidecouvert.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: nulsidecouvert.org is back up in a1a86ec after 9 hours, 29 minutes.


text:
🛑 mazemod.org is down

In b861c39, mazemod.org (https://mazemod.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: mazemod.org is back up in aad1d58.

repo: constructions-incongrues/status


text:
🛑 data.constructions-incongrues.net is down

In ed90520, data.constructions-incongrues.net (https://data.constructions-incongrues.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: data.constructions-incongrues.net is back up in 29f2bb6.

Resolved: data.constructions-incongrues.net is back up in 6b79754.


text:
🛑 moncul.org is down

In 527f37c, moncul.org (https://moncul.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: moncul.org is back up in c4f6ece.


text:
modern and tasty look & feel

Goal:
It is necessary to change the look & feel of the individual components and global styles for getting closer to what has already been done in the Contatlab Marketing Cloud's project. The Contactlab Design Tokens are a guideline.

Perform the following tasks:

Simplify the SCSS syntax by removing complex nestings, useless functions or mixins;
Convert the .scss files to .css leaving the SASS language features intact;
Add postcss and the related Marketing Cloud's config. Next step is to build the CSS through the postcss-cli;
Add stylelint and the related Marketing Cloud's config. Next step is linting the code;
Remove old fonts (Open Sans and Frutiger);
Update style's reset, typography and variables with Contactlab Design Tokens;
Add and update some dev dependencies used in Contactlab Marketing Cloud project;
Update UI components demo;
Refine folder structures and building scripts;
Develop and refine the style of the components by testing in the web applications based on the pattern library.

State of art:

[x] Task 1
[x] Task 2
[x] Task 3
[x] Task 4
[x] Task 5
[x] Task 6
[ ] Task 7
[ ] Task 8
[ ] Task 9
[ ] Task 10

Resolved by #222

repo: contactlab/contactlab-ui-components

license_source: bigquery


text:
Artifacts

Hello,
It would be cool to support single files and empty base images
Thanks !

Can you check the build error? @johnpoth

Updated GO version, hope that is ok ? looks like it needs another approval for the build to run again

authors: johnpoth nicolaferraro

repo: container-tools/spectrum


text:
inspect container

I can use crictl inspect <cid> to display the container information.
But containerd does not seem to have this interface

ctr c info <ID>, or nerdctl container inspect <ID>

crictl inspect

crictl inspect should work just fine for containers created by CRI... you probably have a version mismatch between the version of containerd you are using and the version of crictl

Thanks
I use crictl inspect to get container pid, but there is no interface to get  Pid in containerd
import "github.com/containerd/containerd"
func main(){
    c, err := containerd.New("/run/containerd/containerd.sock")
    // How to get pid through client?
}

c, err := client.LoadContainer(ctx, id)
t, err := c.Task(ctx, nil)
pid := t.Pid()

https://pkg.go.dev/github.com/containerd/containerd#Container

authors: AkihiroSuda chinazj mikebrow

repo: containerd/containerd


text:
Clarify text on ctr support/inclusion

Add some clarifying language around the expectations on ctr.
Signed-off-by: Phil Estes estesp@linux.vnet.ibm.com

LGTM

authors: crosbymichael estesp


text:
delete compare i with max

in the for loop, there is no possibility I equal or bigger then len(max), so just compare I with len(min)  looks simpler
Signed-off-by: Xiaoyu Zhang ideoutrea@163.com

Thank you for your contribution, I think it worth to leave both checks for clarity.

authors: ide-rea mxpv


text:
Make OpenLab's CI jobs blocking

Since the jobs are relatively stable, we have official ARM binaries and
we could technically still ignore them, we should remove "voting: false"
from them.
Signed-off-by: Kazuyoshi Kato katokazu@amazon.com

The jobs are relatively slow, but not the slowest compared to other automated checks.

And GitHub Actions are less stable sadly. Let me re-run them...


text:
Don't run CI on push

Remove push event (e.g. don't run the CI once merged). Instead it'll be added to the merge queue and built from there.
https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue#triggering-merge-group-checks-with-github-actions

I'm going to add this to merge queue to test

authors: dmcgowan mxpv


text:
Move GenerateRuntimeOptions() to pkg/cri/config

This PR moves GenerateRuntimeOptions() to the cri config package. This will be useful to have for the image pull per runtime class feature where we would need to initialize list of platform matchers for each runtime.

This would help avoid to have a separate helper pkg in pkg/cri that was created in this PR https://github.com/containerd/containerd/commit/5ed062749e1ae396320182c0acf4841115d8e295

@dmcgowan could you take a look if you have some time please? Thanks!


text:
init cni in local cluster installation

When I tried containerd as kubernetes runtime in local cluster, node becomes notReady because of the cni plugin not initialized error in kubelet runtimeStatus api. It takes me some time to solve this problem.
I think cni initialization should be mentioned in the local cluster setup for beginners.

further more, can containerd/cri support no cni in local cluster such as k8s/no-op

@gongguan make install.deps should have setup cni for local test for you.

@Random-Liu cri release package doesn't have cni config and binaries, it may be a little confused to solve it.

@gongguan make install.deps should have setup cni for local test for you.

@Random-Liu Can I close the pr now?

@gongguan please go ahead :)

/close

authors: Random-Liu fuweid gongguan

repo: containerd/cri


text:
Support profiles in nerdctl compose

What is the problem you're trying to solve
compose spec uses profiles to group services within a docker-compose.yml (each service can belong to multiple profiles, e.g., test, debug, etc).
This allows users to put all services (debug, test, prod) in one docker-compose.yml and share other configs (volumns, networks, etc. profiles only applies to services). Users can enable specific groups/profiles when running compose command. all profiles are enabled by default if no profile is given via flag/env (basically, the current behavior).
# syntax may not correct, just for demo
#
# no profile is given, all profiles are enabled (so all services up)
$ nerdctl compose up -d

# only services with a `test` or `debug` profile attached are up
$ nerdctl --profile test,debug compose up -d
$ COMPOSE_PROFILES=test,debug nerdctl compose up -d

Notice that:

If a service name(s) is passed as arguments, all profiles they belong to are enabled automatically.
profiles are just a limitation on which services are visible/in-scope, and shouldn't handle dependencies etc.

# suppose svc0 belongs to p0 and depends on svc1, whereas svc1 belongs to p1 not p0
# this should fail because svc1 should up as a dependency of svc0, but p1 is not enabled.
$ nerdctl compose up -d svc0
# this should succeed because p1 is enabled, so as p0 (enabled automatically by svc0 being a arg)
$ nerdctl --profile p1 compose up -d svc0

Describe the solution you'd like

Support the profiles field in docker-compose.yml, which specifies which service belongs to which profiles.
Support the profile compose flag and COMPOSE_PROFILES env variable, which explicitly specifies which profiles are enabled.

Additional context
docker compose profile example
profiles in compose spec

+1

https://github.com/adsblol/feed/blob/main/bin/adsblol-init A really bad workaround for this feature. Please consider adding this! ❤

@djdongjin mind If I take a look at this?

@danishprakash please go ahead

authors: danishprakash djdongjin katlol tranngoclam

repo: containerd/nerdctl


text:
Publishing udp range larger than 16383 ending with 65535 breaks dns resolution on user defined networks with root networking.

Issue Description
When publishing a udp range larger than 16383 ports ending with 65535, dns resolution on user defined networks stops working. I could only reproduce it with larger ranges ending with 65535.
(the intended use-case was coturn)

49152-65535:49152-65535/udp (doesn't work)
49152-65535:49152-65535/tcp (tcp - works)
49153-65535:49153-65535/udp (1 port smaller - works)
45000-65534:45000-65534/udp (much larger range, but ends 1 port before 65535 - works)

Steps to reproduce the issue
Steps to reproduce the issue

podman network create debug
podman run --rm -it --publish 45000-65534:45000-65534/udp docker.io/debian
podman run --rm -it --network=debug docker.io/debian apt update

Describe the results you received
DNS requests inside container time out.
Describe the results you expected
DNS requests inside container get a response.
podman info output
host:
  arch: amd64
  buildahVersion: 1.35.4
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - hugetlb
  - pids
  - rdma
  - misc
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.10-1.fc40.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.10, commit: '
  cpuUtilization:
    idlePercent: 96.41
    systemPercent: 2.57
    userPercent: 1.03
  cpus: 4
  databaseBackend: sqlite
  distribution:
    distribution: fedora
    variant: coreos
    version: "40"
  eventLogger: journald
  freeLocks: 2047
  hostname: uncontrol-old
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 6.8.9-300.fc40.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 4969246720
  memTotal: 8319741952
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: aardvark-dns-1.10.0-1.fc40.x86_64
      path: /usr/libexec/podman/aardvark-dns
      version: aardvark-dns 1.10.0
    package: netavark-1.10.3-3.fc40.x86_64
    path: /usr/libexec/podman/netavark
    version: netavark 1.10.3
  ociRuntime:
    name: crun
    package: crun-1.15-1.fc40.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.15
      commit: e6eacaf4034e84185fd8780ac9262bbf57082278
      rundir: /run/user/0/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: passt-0^20240510.g7288448-1.fc40.x86_64
    version: |
      pasta 0^20240510.g7288448-1.fc40.x86_64
      Copyright Red Hat
      GNU General Public License, version 2 or later
        <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
  remoteSocket:
    exists: false
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.2-2.fc40.x86_64
    version: |-
      slirp4netns version 1.2.2
      commit: 0ee2d87523e906518d34a6b423271e4826f71faf
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.3
  swapFree: 0
  swapTotal: 0
  uptime: 0h 30m 58.00s
  variant: ""
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /usr/share/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 1
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.imagestore: /usr/lib/containers/storage
    overlay.mountopt: nodev,metacopy=on
  graphRoot: /var/lib/containers/storage
  graphRootAllocated: 171260751872

Podman in a container
No
Privileged Or Rootless
Privileged
Upstream Latest Release
No
Additional environment details
QEMU/KVM (netcup.eu)
Additional information
No response

I'm sorry, I don't completely follow. Why would freeing up port 65535 fix it if this was the case, since it's well outside of the ip_local_port_range and the chance of it being picked randomly seems extremely low?

I agree that is seems odd to we hit 65535 randomly but I looked at the code and this is what our lib is doing, it also does not respect ip_local_port_range at all.
https://github.com/hickory-dns/hickory-dns/blob/f1489da675c21fddc189f2c9505bc9da6c156835/crates/proto/src/udp/udp_stream.rs#L291-L339
No idea why they did this instead of just binding to 0 and let the kernel pick the port.

I created https://github.com/hickory-dns/hickory-dns/pull/2260 over there

repo: containers/aardvark-dns


text:
Rootless podman on EL7.8 can't start read-only containers if we have userns=keep-id

I am not able to run containers with the read-only flag if I want to keep the id in my user-ns. Without keeping the id it works:
$ id -u
1011
$ podman  run -it  --read-only=true --user=root --userns=keep-id fedora:31
Error: container_linux.go:345: starting container process caused "process_linux.go:430: container init caused \"rootfs_linux.go:147: setting rootfs as readonly caused \\\"operation not permitted\\\"\"": OCI runtime permission denied error
$ podman  run -it  --read-only=true --user=root fedora:31
[root@0f44a3e2bb94 /]#

Debug:
$ podman  run --log-level=debug -it  --read-only=true --user=root --userns=keep-id fedora:31
WARN[0000] The cgroups manager is set to systemd but there is no systemd user session available
WARN[0000] For using systemd, you may need to login using an user session
WARN[0000] Alternatively, you can enable lingering with: `loginctl enable-linger 1011` (possibly as root)
WARN[0000] Falling back to --cgroup-manager=cgroupfs and --events-backend=file
DEBU[0000] Using conmon: "/usr/bin/conmon"
DEBU[0000] Initializing boltdb state at /var/lib/containers/users/user/storage/libpod/bolt_state.db
DEBU[0000] Using graph driver overlay
DEBU[0000] Using graph root /var/lib/containers/users/user/storage
DEBU[0000] Using run root /var/lib/containers/users/user/run
DEBU[0000] Using static dir /var/lib/containers/users/user/storage/libpod
DEBU[0000] Using tmp dir /run/pods/user/libpod/tmp
DEBU[0000] Using volume path /var/lib/containers/users/user/storage/volumes
DEBU[0000] Set libpod namespace to ""
DEBU[0000] [graphdriver] trying provided driver "overlay"
DEBU[0000] overlay: mount_program=/bin/fuse-overlayfs
DEBU[0000] backingFs=xfs, projectQuotaSupported=false, useNativeDiff=false, usingMetacopy=false
DEBU[0000] Initializing event backend file
DEBU[0000] using runtime "/usr/bin/runc"
DEBU[0000] Failed to add podman to systemd sandbox cgroup: dial unix /run/user/0/bus: connect: permission denied
INFO[0000] running as rootless
WARN[0000] The cgroups manager is set to systemd but there is no systemd user session available
WARN[0000] For using systemd, you may need to login using an user session
WARN[0000] Alternatively, you can enable lingering with: `loginctl enable-linger 1011` (possibly as root)
WARN[0000] Falling back to --cgroup-manager=cgroupfs and --events-backend=file
DEBU[0000] Using conmon: "/usr/bin/conmon"
DEBU[0000] Initializing boltdb state at /var/lib/containers/users/user/storage/libpod/bolt_state.db
DEBU[0000] Using graph driver overlay
DEBU[0000] Using graph root /var/lib/containers/users/user/storage
DEBU[0000] Using run root /var/lib/containers/users/user/run
DEBU[0000] Using static dir /var/lib/containers/users/user/storage/libpod
DEBU[0000] Using tmp dir /run/pods/user/libpod/tmp
DEBU[0000] Using volume path /var/lib/containers/users/user/storage/volumes
DEBU[0000] Set libpod namespace to ""
DEBU[0000] Initializing event backend file
DEBU[0000] using runtime "/usr/bin/runc"
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/users/user/storage+/var/lib/containers/users/user/run:overlay.mount_program=/bin/fuse-overlayfs]docker.io/libra
ry/fedora:31"
DEBU[0000] reference "[overlay@/var/lib/containers/users/user/storage+/var/lib/containers/users/user/run:overlay.mount_program=/bin/fuse-overlayfs]docker.io/library/fedora:31
" does not resolve to an image ID
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/users/user/storage+/var/lib/containers/users/user/run:overlay.mount_program=/bin/fuse-overlayfs]localhost/fedor
a:31"
DEBU[0000] reference "[overlay@/var/lib/containers/users/user/storage+/var/lib/containers/users/user/run:overlay.mount_program=/bin/fuse-overlayfs]localhost/fedora:31" does n
ot resolve to an image ID
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/users/user/storage+/var/lib/containers/users/user/run:overlay.mount_program=/bin/fuse-overlayfs]@fac75bdc1c86b5
f45a252fe3a149d6657522a576a8fe330dfcac110cb6881c86"
DEBU[0000] exporting opaque data as blob "sha256:fac75bdc1c86b5f45a252fe3a149d6657522a576a8fe330dfcac110cb6881c86"
DEBU[0000] No hostname set; container's hostname will default to runtime default
DEBU[0000] Using slirp4netns netmode
DEBU[0000] Adding mount /proc
DEBU[0000] Adding mount /dev
DEBU[0000] Adding mount /dev/pts
DEBU[0000] Adding mount /dev/mqueue
DEBU[0000] Adding mount /sys
DEBU[0000] Adding mount /sys/fs/cgroup
DEBU[0000] created OCI spec and options for new container
DEBU[0000] Allocated lock 7 for container 8d91c86cd41b8f342c2779e27930d7bb50538821f4789f193a13af6b43520801
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/users/user/storage+/var/lib/containers/users/user/run:overlay.mount_program=/bin/fuse-overlayfs]@fac75bdc1c86b5
f45a252fe3a149d6657522a576a8fe330dfcac110cb6881c86"
DEBU[0000] exporting opaque data as blob "sha256:fac75bdc1c86b5f45a252fe3a149d6657522a576a8fe330dfcac110cb6881c86"
DEBU[0000] created container "8d91c86cd41b8f342c2779e27930d7bb50538821f4789f193a13af6b43520801"
DEBU[0000] container "8d91c86cd41b8f342c2779e27930d7bb50538821f4789f193a13af6b43520801" has work directory "/var/lib/containers/users/user/storage/overlay-containers/8d91c86cd41b
8f342c2779e27930d7bb50538821f4789f193a13af6b43520801/userdata"
DEBU[0000] container "8d91c86cd41b8f342c2779e27930d7bb50538821f4789f193a13af6b43520801" has run directory "/var/lib/containers/users/user/run/overlay-containers/8d91c86cd41b8f342
c2779e27930d7bb50538821f4789f193a13af6b43520801/userdata"
DEBU[0000] New container created "8d91c86cd41b8f342c2779e27930d7bb50538821f4789f193a13af6b43520801"
DEBU[0000] container "8d91c86cd41b8f342c2779e27930d7bb50538821f4789f193a13af6b43520801" has CgroupParent "/libpod_parent/libpod-8d91c86cd41b8f342c2779e27930d7bb50538821f4789f193a13af
6b43520801"
DEBU[0000] Handling terminal attach
DEBU[0000] overlay: mount_data=lowerdir=/var/lib/containers/users/user/storage/overlay/l/GEBGOKA2ARXLLWG26ATNZF73AF,upperdir=/var/lib/containers/users/user/storage/overlay/1b
f2f0248cb927f67d669700534583f8b68fd3057e73a917088630290dd2c211/diff,workdir=/var/lib/containers/users/user/storage/overlay/1bf2f0248cb927f67d669700534583f8b68fd3057e73a9170886302
90dd2c211/work,context="system_u:object_r:svirt_sandbox_file_t:s0:c168,c961"
DEBU[0000] mounted container "8d91c86cd41b8f342c2779e27930d7bb50538821f4789f193a13af6b43520801" at "/var/lib/containers/users/user/storage/overlay/1bf2f0248cb927f67d669700534583f
8b68fd3057e73a917088630290dd2c211/merged"
DEBU[0000] Created root filesystem for container 8d91c86cd41b8f342c2779e27930d7bb50538821f4789f193a13af6b43520801 at /var/lib/containers/users/user/storage/overlay/1bf2f0248cb927
f67d669700534583f8b68fd3057e73a917088630290dd2c211/merged
DEBU[0001] /etc/system-fips does not exist on host, not mounting FIPS mode secret
DEBU[0001] Created OCI spec for container 8d91c86cd41b8f342c2779e27930d7bb50538821f4789f193a13af6b43520801 at /var/lib/containers/users/user/storage/overlay-containers/8d91c86cd4
1b8f342c2779e27930d7bb50538821f4789f193a13af6b43520801/userdata/config.json
DEBU[0001] /usr/bin/conmon messages will be logged to syslog
DEBU[0001] running conmon: /usr/bin/conmon               args="[--api-version 1 -c 8d91c86cd41b8f342c2779e27930d7bb50538821f4789f193a13af6b43520801 -u 8d91c86cd41b8f342c2779e27930d7b
b50538821f4789f193a13af6b43520801 -r /usr/bin/runc -b /var/lib/containers/users/user/storage/overlay-containers/8d91c86cd41b8f342c2779e27930d7bb50538821f4789f193a13af6b43520801/u
serdata -p /var/lib/containers/users/user/run/overlay-containers/8d91c86cd41b8f342c2779e27930d7bb50538821f4789f193a13af6b43520801/userdata/pidfile -l k8s-file:/var/lib/containers
/users/user/storage/overlay-containers/8d91c86cd41b8f342c2779e27930d7bb50538821f4789f193a13af6b43520801/userdata/ctr.log --exit-dir /run/pods/user/libpod/tmp/exits --socket-d
ir-path /run/pods/user/libpod/tmp/socket --log-level debug --syslog -t --conmon-pidfile /var/lib/containers/users/user/run/overlay-containers/8d91c86cd41b8f342c2779e27930d7bb
50538821f4789f193a13af6b43520801/userdata/conmon.pid --exit-command /usr/bin/podman --exit-command-arg --root --exit-command-arg /var/lib/containers/users/user/storage --exit-com
mand-arg --runroot --exit-command-arg /var/lib/containers/users/user/run --exit-command-arg --log-level --exit-command-arg debug --exit-command-arg --cgroup-manager --exit-comman
d-arg cgroupfs --exit-command-arg --tmpdir --exit-command-arg /run/pods/user/libpod/tmp --exit-command-arg --runtime --exit-command-arg runc --exit-command-arg --storage-driver -
-exit-command-arg overlay --exit-command-arg --storage-opt --exit-command-arg overlay.mount_program=/bin/fuse-overlayfs --exit-command-arg --events-backend --exit-command-arg file --
exit-command-arg container --exit-command-arg cleanup --exit-command-arg 8d91c86cd41b8f342c2779e27930d7bb50538821f4789f193a13af6b43520801]"
WARN[0001] Failed to add conmon to cgroupfs sandbox cgroup: error creating cgroup for cpu: mkdir /sys/fs/cgroup/cpu/libpod_parent: permission denied
DEBU[0001] Received: -1
DEBU[0001] Cleaning up container 8d91c86cd41b8f342c2779e27930d7bb50538821f4789f193a13af6b43520801
DEBU[0001] Network is already cleaned up, skipping...
DEBU[0001] unmounted container "8d91c86cd41b8f342c2779e27930d7bb50538821f4789f193a13af6b43520801"
DEBU[0001] ExitCode msg: "container_linux.go:345: starting container process caused \"process_linux.go:430: container init caused \\\"rootfs_linux.go:147: setting rootfs as readonly
caused \\\\\\\"operation not permitted\\\\\\\"\\\"\": oci runtime permission denied error"
ERRO[0001] container_linux.go:345: starting container process caused "process_linux.go:430: container init caused \"rootfs_linux.go:147: setting rootfs as readonly caused \\\"operati
on not permitted\\\"\"": OCI runtime permission denied error

$ podman info --debug
debug:
  compiler: gc
  git commit: ""
  go version: go1.12.12
  podman version: 1.6.4
host:
  BuildahVersion: 1.12.0-dev
  CgroupVersion: v1
  Conmon:
    package: conmon-2.0.8-1.el7.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.8, commit: f85c8b1ce77b73bcd48b2d802396321217008762'
  Distribution:
    distribution: '"centos"'
    version: "7"
  IDMappings:
    gidmap:
    - container_id: 0
      host_id: 1015
      size: 1
    - container_id: 1
      host_id: 165536
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1011
      size: 1
    - container_id: 1
      host_id: 165536
      size: 65536
  MemFree: 134238208
  MemTotal: 3959992320
  OCIRuntime:
    name: runc
    package: runc-1.0.0-89.dev.git029124d.el7.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc7+dev
      commit: 98107a1959795eaa8040ea0f5770fa381a5f0b58
      spec: 1.0.1-dev
  SwapFree: 3887067136
  SwapTotal: 4190105600
  arch: amd64
  cpus: 4
  eventlogger: file
  hostname: pods.example.com
  kernel: 3.10.0-1127.el7.x86_64
  os: linux
  rootless: true
  slirp4netns:
    Executable: /bin/slirp4netns
    Package: slirp4netns-0.4.3-4.el7_8.x86_64
    Version: |-
      slirp4netns version 0.4.3
      commit: 2244b9b6461afeccad1678fac3d6e478c28b4ad6
  uptime: 50h 34m 50.22s (Approximately 2.08 days)
registries:
  blocked: null
  insecure: null
  search:
  - registry.access.redhat.com
  - registry.fedoraproject.org
  - registry.centos.org
  - docker.io
store:
  ConfigFile: /home/user/.config/containers/storage.conf
  ContainerStore:
    number: 6
  GraphDriverName: overlay
  GraphOptions:
    overlay.mount_program:
      Executable: /bin/fuse-overlayfs
      Package: fuse-overlayfs-0.7.2-6.el7_8.x86_64
      Version: |-
        fuse-overlayfs: version 0.7.2
        FUSE library version 3.6.1
        using FUSE kernel interface version 7.29
  GraphRoot: /var/lib/containers/users/user/storage
  GraphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 2
  RunRoot: /var/lib/containers/users/user/run
  VolumePath: /var/lib/containers/users/user/storage/volumes

This looks like it works on Fedora and perhaps newer versions of podman on RHEL8.  Any chance you could try this on RHEL8?

It works on Centos 8.1 using podman 1.6.4 - though this is not yet with cgroupv2

Please open a bugzilla on this, since this is not an issue in the upstream.

authors: duritong rhatdan

repo: containers/libpod


text:
APIv2 compat container creation endpoint mishandles volumes

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
The APIv2 compat handler for /containers/create doesn't appear to support volumes as described by the Docker engine API docs. Named volumes or host bind mounts are replaced with anonymous volumes in the created container.
Steps to reproduce the issue:

Create a container with some named volume using podman create, and inspect it

Create a container with the bind spec as a key for a mapping to an empty object (ie. Volumes is a map[string]struct {}), and inspect it (see transcript below)

Create a container with the bind spec included under HostConfig as specified at https://docs.docker.com/engine/api/v1.40/#operation/ContainerCreate, and inspect it. Observe that the named volume has been disregarded and an anonymous volume has taken its place

Describe the results you received:
Named volumes are replaced with new, anonymous volumes when we hit the /containers/create compat APIv2 endpoint.
Describe the results you expected:
We should be able to specify a Volumes mapping of container paths to empty objects, and then describe the bindings in HostConfig, like so:
{
  "Image": "foo",
  "Volumes": {
    "/some_path": {}
  },
  "HostConfig": {
    "Binds": [
      "foobarbaz:/some_path"
    ]
  }
}

Additional information you deem important (e.g. issue happens only occasionally):
Shell transcript:
sh-5.0$ podman create -v foobarbaz:/some_path alpine
b29eefda3709f95c663f3523e1f61b0dd3b11e9f4a031b0267523be7c3e6e935
sh-5.0$ podman inspect b29eefda3709 | jq '.[0]["Mounts"], .[0]["HostConfig"]["Binds"]'
[
  {
    "Type": "volume",
    "Name": "foobarbaz",
    "Source": "/home/user/.local/share/containers/storage/volumes/foobarbaz/_data",
    "Destination": "/some_path",
    "Driver": "local",
    "Mode": "",
    "Options": [
      "nosuid",
      "nodev",
      "rbind"
    ],
    "RW": true,
    "Propagation": "rprivate"
  }
]
[
  "foobarbaz:/some_path:rw,rprivate,nosuid,nodev,rbind"
]
sh-5.0$ curl --unix-socket /tmp/podman.sock -H "Content-Type: application/json" http://unixsocket/containers/create --data '{"Image": "alpine", "Volumes": {"foobarbaz:/some_path": {}}}'
{"Id":"724804b17f38d0b24baddb0042ec9392516e931ede80d294c1a6d6ddbfa232c5","Warnings":[]}
sh-5.0$ podman inspect 724804b17f38 | jq '.[0]["Mounts"], .[0]["HostConfig"]["Binds"]'
[
  {
    "Type": "volume",
    "Name": "foobarbaz",
    "Source": "/home/user/.local/share/containers/storage/volumes/foobarbaz/_data",
    "Destination": "/some_path",
    "Driver": "local",
    "Mode": "",
    "Options": [
      "nosuid",
      "nodev",
      "rbind"
    ],
    "RW": true,
    "Propagation": "rprivate"
  }
]
[
  "foobarbaz:/some_path:rw,rprivate,nosuid,nodev,rbind"
]
sh-5.0$ curl --unix-socket /tmp/podman.sock -H "Content-Type: application/json" http://unixsocket/containers/create --data '{"Image": "alpine", "Volumes": {"/some_path": {}}, "HostConfig": {"Binds": ["foobarbaz:/some_path"]}}'
{"Id":"17372175c11915bb208274eb85c6b2f69d2779b8bae8b259994e55e88d45de31","Warnings":[]}
sh-5.0$ podman inspect 17372175c119 | jq '.[0]["Mounts"], .[0]["HostConfig"]["Binds"]'
[
  {
    "Type": "volume",
    "Name": "f3adebf8d23e37fea6d177e99ba26c39d241df6af0b09a17df4c99b492f580dd",
    "Source": "/home/user/.local/share/containers/storage/volumes/f3adebf8d23e37fea6d177e99ba26c39d241df6af0b09a17df4c99b492f580dd/_data",
    "Destination": "/some_path",
    "Driver": "local",
    "Mode": "",
    "Options": [
      "nosuid",
      "nodev",
      "rbind"
    ],
    "RW": true,
    "Propagation": "rprivate"
  }
]
[
  "f3adebf8d23e37fea6d177e99ba26c39d241df6af0b09a17df4c99b492f580dd:/some_path:rw,rprivate,nosuid,nodev,rbind"
]

Output of podman version:
sh-5.0$  podman version
Version:            1.9.3
RemoteAPI Version:  1
Go Version:         go1.14.2
OS/Arch:            linux/amd64

Output of podman info --debug:
sh-5.0$ podman info --debug
debug:
  compiler: gc
  gitCommit: ""
  goVersion: go1.14.2
  podmanVersion: 1.9.3
host:
  arch: amd64
  buildahVersion: 1.14.9
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.17-1.fc32.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.17, commit: bb8e273f5925c1a51737644637ef65d094a67ab1'
  cpus: 8
  distribution:
    distribution: fedora
    version: "32"
  eventLogger: file
  hostname: host
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 31337
      size: 1
    - container_id: 1
      host_id: 165536
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1001
      size: 1
    - container_id: 1
      host_id: 165536
      size: 65536
  kernel: 5.6.14-300.fc32.x86_64
  memFree: 796708864
  memTotal: 8235126784
  ociRuntime:
    name: crun
    package: crun-0.13-2.fc32.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.13
      commit: e79e4de4ac16da0ce48777afb72c6241de870525
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  rootless: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.1-1.fc32.x86_64
    version: |-
      slirp4netns version 1.1.1
      commit: bbf27c5acd4356edb97fa639b4e15e0cd56a39d5
      libslirp: 4.2.0
      SLIRP_CONFIG_VERSION_MAX: 2
  swapFree: 8390963200
  swapTotal: 8392798208
  uptime: 5h 35m 44.55s (Approximately 0.21 days)
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - docker.io
store:
  configFile: /home/user/.config/containers/storage.conf
  containerStore:
    number: 3
    paused: 0
    running: 0
    stopped: 3
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.0.0-1.fc32.x86_64
      Version: |-
        fusermount3 version: 3.9.1
        fuse-overlayfs: version 1.0.0
        FUSE library version 3.9.1
        using FUSE kernel interface version 7.31
  graphRoot: /home/user/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 39
  runRoot: /run/user/1001/containers
  volumePath: /home/user/.local/share/containers/storage/volumes

Package info (e.g. output of rpm -q podman or apt list podman):
sh-5.0$ rpm -q podman
podman-1.9.3-1.fc32.x86_64

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

I did try the podman 2.0.0 testing package on the Fedora repos, and bellieve the behaviour is still present. It looks like https://github.com/containers/libpod/blob/200cfa41a434b7143620c2c252b3eb7ab3ef92f9/pkg/api/handlers/compat/containers_create.go#L140 just naively copies lines which it expects to be formatted like bind specs. I don't see any handing of the ["HostConfig"]["Binds"] key in there which would be necessary to interpret the JSON blob I suggest submitting to the API in step 3 of my repro.

@rhatdan This can probably be closed with the merge of #6742. I don't think I put a fixes line in the commit :# Thanks for merging that btw


text:
Initial checking for readthedocs

Signed-off-by: baude bbaude@redhat.com

LGTM

/lgtm
/hold

/hold cancel

Where does one get  sphinx-build from?

authors: TomSweeneyRedHat baude mheon rhatdan


text:
v2 api: top improvements

Use pkg/adapter to increase code reuse and reduce code redundancy.
Extend swagger docs to mention AIX descriptors.
Document the libpod endpoint which shares the same handler.

Signed-off-by: Valentin Rothberg rothberg@redhat.com
@baude @jwhonce PTAL

While testing I found a small bug in the top-backend. In some cases, we fall back to exec-ing ps(1) in the container. Via the v2 api, I've seen conmon debug messages in the returned data. That was because the top-backend was using one pipe for stderr and stdout. I assume we never caught that because we don't run top in debug-mode. Anyhow, it's fixed now.


text:
podmanv2 fix runtime assignment

when provided by the command line, the runtime assignment needs to send the right attribute
Signed-off-by: Brent Baude bbaude@redhat.com

/lgtm
/hold

LGTM

/hold cancel

authors: baude mheon rhatdan


text:
feat: add banner for promoting GPU enabled machine

Fixes #1582
What does this PR do?
Add a banner when creating an inference server or launching a recipe if GPU flag is on but podman machine is not GPU enabled (MacOS only)
Screenshot / video of UI
https://github.com/user-attachments/assets/f7dca714-56b0-46d3-b117-581b3a5846b7
What issues does this PR fix or reference?
#1582
How to test this PR?

Enable the GPU experimental flag
Create an inference server on an Applehv machine

When the "Experimental GPU" preference is disabled, I get the message "Non GPU enabled machine
". I would expect to not see it

Any reason why you don't open the create new ... page directly?

Do we have the API ?

Do we have the API ?

It seems not, should we update podman desktop? We can also merge this PR as it is and then update it when we have the new API

Do we have the API ?

It seems not, should we update podman desktop? We can also merge this PR as it is and then update it when we have the new API

Yes my plan was to have a follow up PR

authors: feloy jeffmaury lstocchi


text:
Check for "krunkit" or "libkrun" strings

I think the latest version of podman machine/krunkit displays libkrun here.

I'm gonna treat #304 as a LGTM from @maxandersen 😄

libkrun was the correct value to check, my mistake.

authors: ericcurtin rhatdan

repo: containers/ramalama


text:
libcgroup build is broken for individual feature v1, v2 or systemd

Currently, we default the libcgroup feature to [v1, v2, systemd], so this went under our radar. However, if we compile libcontainer with individual features, the libcgroups fails to compile.
For example, this will fail.
cargo build --no-default-features --package libcontainer --features v2

I tried to update libcontainer/libcgroup in aurae but I got this error aswell

I tried to update libcontainer/libcgroup in aurae but I got this error aswell

Yes, it is currently broken. We did not do a good job keeping this usecase working. I have a fix locally already, so I am hoping this can unblock you next week. I will follow up with works to make libcontainer tests running in CI so it is better maintained.

authors: izissise yihuaf

repo: containers/youki