text:
Missing GSL Dependency on conda-forge

Solution to issue cannot be found in the documentation.

[X] I checked the documentation.

Issue
conda install conda-forge::python-casacore has a missing dependence on gsl. Installation is successful but using casacore.tables.table() fails because gsl is missing. If gsl is installed using conda, the package works as expected
Installed packages
# Name                    Version                   Build  Channel
anyio                     3.5.0           py311hca03da5_0
appnope                   0.1.2           py311hca03da5_1001
argon2-cffi               21.3.0             pyhd3eb1b0_0
argon2-cffi-bindings      21.2.0          py311h80987f9_0
asttokens                 2.0.5              pyhd3eb1b0_0
async-lru                 2.0.4              pyhd8ed1ab_0    conda-forge
attrs                     23.1.0          py311hca03da5_0
babel                     2.11.0          py311hca03da5_0
backcall                  0.2.0              pyhd3eb1b0_0
beautifulsoup4            4.12.2          py311hca03da5_0
blas                      1.0                    openblas
bleach                    4.1.0              pyhd3eb1b0_0
brotlipy                  0.7.0           py311h80987f9_1002
bzip2                     1.0.8                h620ffc9_4
c-ares                    1.19.1               h80987f9_0
ca-certificates           2023.08.22           hca03da5_0
casacore                  3.5.0           nompi_py311h8baa3da_111    conda-forge
certifi                   2023.7.22       py311hca03da5_0
cffi                      1.15.1          py311h80987f9_3
cfitsio                   4.3.0                hca87796_0    conda-forge
charset-normalizer        2.0.4              pyhd3eb1b0_0
comm                      0.1.2           py311hca03da5_0
cryptography              41.0.3          py311hd4332d6_0
debugpy                   1.6.7           py311h313beb8_0
decorator                 5.1.1              pyhd3eb1b0_0
defusedxml                0.7.1              pyhd3eb1b0_0
entrypoints               0.4             py311hca03da5_0
executing                 0.8.3              pyhd3eb1b0_0
fftw                      3.3.10          nompi_h3046061_108    conda-forge
gsl                       2.7.1                h442ca57_1
hdf5                      1.14.1          nompi_h3aba7b3_100    conda-forge
icu                       73.1                 h313beb8_0
idna                      3.4             py311hca03da5_0
importlib-metadata        6.0.0           py311hca03da5_0
importlib_metadata        6.0.0                hd3eb1b0_0
importlib_resources       5.2.0              pyhd3eb1b0_1
ipykernel                 6.25.0          py311hb6e6a13_0
ipython                   8.15.0          py311hca03da5_0
jedi                      0.18.1          py311hca03da5_1
jinja2                    3.1.2           py311hca03da5_0
json5                     0.9.6              pyhd3eb1b0_0
jsonschema                4.17.3          py311hca03da5_0
jupyter-lsp               2.2.0              pyhd8ed1ab_0    conda-forge
jupyter_client            8.1.0           py311hca03da5_0
jupyter_core              5.3.0           py311hca03da5_0
jupyter_events            0.6.3           py311hca03da5_0
jupyter_server            2.5.0           py311hca03da5_0
jupyter_server_terminals  0.4.4           py311hca03da5_1
jupyterlab                4.0.6              pyhd8ed1ab_0    conda-forge
jupyterlab_pygments       0.1.2                      py_0
jupyterlab_server         2.22.0          py311hca03da5_0
krb5                      1.20.1               hf3e1bf2_1
libaec                    1.1.1                h13dd4ca_0    conda-forge
libblas                   3.9.0           16_osxarm64_openblas    conda-forge
libboost                  1.82.0               hdbf59fe_1
libboost-python           1.82.0          py311hddbb800_5    conda-forge
libcblas                  3.9.0           16_osxarm64_openblas    conda-forge
libcurl                   8.2.1                h3e2b118_0
libcxx                    16.0.6               h4653b0c_0    conda-forge
libedit                   3.1.20221030         h80987f9_0
libev                     4.33                 h1a28f6b_1
libexpat                  2.5.0                hb7217d7_1    conda-forge
libffi                    3.4.4                hca03da5_0
libgfortran               5.0.0           13_2_0_hd922786_1    conda-forge
libgfortran5              13.2.0               hf226fd6_1    conda-forge
libiconv                  1.16                 h1a28f6b_2
liblapack                 3.9.0           16_osxarm64_openblas    conda-forge
libnghttp2                1.52.0               h62f6fdd_1
libopenblas               0.3.21               h269037a_0
libpng                    1.6.39               h80987f9_0
libsodium                 1.0.18               h1a28f6b_0
libsqlite                 3.43.0               hb31c410_0    conda-forge
libssh2                   1.10.0               h02f6b3c_2
libxcb                    1.15                 hf346824_0    conda-forge
libxml2                   2.10.4               h0dcf63f_1
libxslt                   1.1.37               h80987f9_1
libzlib                   1.2.13               h53f4e23_5    conda-forge
llvm-openmp               14.0.6               hc6e5704_0
lxml                      4.9.3           py311h50ffb84_0
lz4-c                     1.9.4                h313beb8_0
markupsafe                2.1.1           py311h80987f9_0
matplotlib-inline         0.1.6           py311hca03da5_0
mistune                   0.8.4           py311h80987f9_1000
nbclient                  0.5.13          py311hca03da5_0
nbconvert                 6.5.4           py311hca03da5_0
nbformat                  5.9.2           py311hca03da5_0
ncurses                   6.4                  h313beb8_0
nest-asyncio              1.5.6           py311hca03da5_0
notebook-shim             0.2.2           py311hca03da5_0
numpy                     1.26.0          py311he598dae_0
numpy-base                1.26.0          py311hfbfe69c_0
openssl                   3.1.3                h53f4e23_0    conda-forge
packaging                 23.1            py311hca03da5_0
pandocfilters             1.5.0              pyhd3eb1b0_0
parso                     0.8.3              pyhd3eb1b0_0
pexpect                   4.8.0              pyhd3eb1b0_3
pgplot                    5.2.2             h86977c9_1008    conda-forge
pickleshare               0.7.5           pyhd3eb1b0_1003
pip                       23.2.1          py311hca03da5_0
platformdirs              3.10.0          py311hca03da5_0
prometheus_client         0.14.1          py311hca03da5_0
prompt-toolkit            3.0.36          py311hca03da5_0
psutil                    5.9.0           py311h80987f9_0
pthread-stubs             0.3                  h1a28f6b_1
ptyprocess                0.7.0              pyhd3eb1b0_2
pure_eval                 0.2.2              pyhd3eb1b0_0
pycparser                 2.21               pyhd3eb1b0_0
pygments                  2.15.1          py311hca03da5_1
pyopenssl                 23.2.0          py311hca03da5_0
pyrsistent                0.18.0          py311h80987f9_0
pysocks                   1.7.1           py311hca03da5_0
python                    3.11.5          h47c9636_0_cpython    conda-forge
python-casacore           3.5.2           py311h003c353_2    conda-forge
python-dateutil           2.8.2              pyhd3eb1b0_0
python-fastjsonschema     2.16.2          py311hca03da5_0
python-json-logger        2.0.7           py311hca03da5_0
python_abi                3.11                    4_cp311    conda-forge
pytz                      2023.3.post1    py311hca03da5_0
pyyaml                    6.0             py311h80987f9_1
pyzmq                     25.1.0          py311h313beb8_0
readline                  8.2                  h1a28f6b_0
requests                  2.31.0          py311hca03da5_0
rfc3339-validator         0.1.4           py311hca03da5_0
rfc3986-validator         0.1.1           py311hca03da5_0
send2trash                1.8.0              pyhd3eb1b0_1
setuptools                68.0.0          py311hca03da5_0
six                       1.16.0             pyhd3eb1b0_1
sniffio                   1.2.0           py311hca03da5_1
soupsieve                 2.4             py311hca03da5_0
stack_data                0.2.0              pyhd3eb1b0_0
terminado                 0.17.1          py311hca03da5_0
tinycss2                  1.2.1           py311hca03da5_0
tk                        8.6.12               hb8d0fd4_0
tomli                     2.0.1           py311hca03da5_0
tornado                   6.3.2           py311h80987f9_0
traitlets                 5.7.1           py311hca03da5_0
typing-extensions         4.7.1           py311hca03da5_0
typing_extensions         4.7.1           py311hca03da5_0
tzdata                    2023c                h04d1e81_0
urllib3                   1.26.16         py311hca03da5_0
wcslib                    8.1                  hbf8d308_1    conda-forge
wcwidth                   0.2.5              pyhd3eb1b0_0
webencodings              0.5.1           py311hca03da5_1
websocket-client          0.58.0          py311hca03da5_4
wheel                     0.41.2          py311hca03da5_0
xorg-kbproto              1.0.7             h27ca646_1002    conda-forge
xorg-libx11               1.8.6                hfd9643e_0    conda-forge
xorg-libxau               1.0.11               hb547adb_0    conda-forge
xorg-libxdmcp             1.1.3                h27ca646_0    conda-forge
xorg-xextproto            7.3.0             h1a8c8d9_1003    conda-forge
xorg-xproto               7.0.31            h1a28f6b_1007
xz                        5.4.2                h80987f9_0
yaml                      0.2.5                h1a28f6b_0
zeromq                    4.3.4                hc377ac9_0
zipp                      3.11.0          py311hca03da5_0
zlib                      1.2.13               h53f4e23_5    conda-forge
zstd                      1.5.5                hd90d995_0

Environment info
active environment : casacore_tmp
    active env location : /Users/seanstansill/miniconda3/envs/casacore_tmp
            shell level : 2
       user config file : /Users/seanstansill/.condarc
 populated config files : /Users/seanstansill/.condarc
          conda version : 23.7.4
    conda-build version : not installed
         python version : 3.11.4.final.0
       virtual packages : __archspec=1=arm64
                          __osx=13.5.2=0
                          __unix=0=0
       base environment : /Users/seanstansill/miniconda3  (writable)
      conda av data dir : /Users/seanstansill/miniconda3/etc/conda
  conda av metadata url : None
           channel URLs : https://repo.anaconda.com/pkgs/main/osx-arm64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/osx-arm64
                          https://repo.anaconda.com/pkgs/r/noarch
          package cache : /Users/seanstansill/miniconda3/pkgs
                          /Users/seanstansill/.conda/pkgs
       envs directories : /Users/seanstansill/miniconda3/envs
                          /Users/seanstansill/.conda/envs
               platform : osx-arm64
             user-agent : conda/23.7.4 requests/2.29.0 CPython/3.11.4 Darwin/22.6.0 OSX/13.5.2 solver/libmamba conda-libmamba-solver/23.7.0 libmambapy/1.4.1
                UID:GID : 501:20
             netrc file : None
           offline mode : False

Hmm. As far as I can tell, the underlying casacore library properly depends on gsl, so I'm not sure how this would happen.
Can you provide minimal a conda create ... specification that reproduces the issue for you, and the list of packages that are installed for that specification? Does it happen if you set up an environment using entirely packages from conda-forge?

I think that I found this problem too - basically python-casacore installs but I get the error ImportError: libgsl.so.25: cannot open shared object file: No such file or directory when I try to import casacore.measures. Here is some code that should reproduce the error:
conda create --name Test_env python=3
conda activate Test_env
conda install conda-forge::python-casacore
python
from casacore.measures import measures

gives the error:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/user/miniconda3/envs/P_test/lib/python3.9/site-packages/casacore/measures/__init__.py", line 29, in <module>
    from ._measures import measures as _measures
ImportError: libgsl.so.25: cannot open shared object file: No such file or directory

Whereas if I just use pip install python-casacore I do not get this error.

Hmmm. Looking at your report and the initial report, now I'm guessing that the common thread is mixing packages from conda-forge and mainline Anaconda. I wouldn't be surprised if the Anaconda version of libgsl has a different shared object version number (the 25) in the above.
If you do something like the following:
conda create --name Test_env -c conda-forge python=3 python-casacore

... does the resulting installation work? This command should install everything from the conda-forge channel, which should make everything self-consistent if my hypothesis is correct.

The installation seems to work. However, when I conda install the other packages I need, there are a lot of conflicts that needed resolving. Things seem to work after that, but maybe it's worth looking into?
The conda packages there were issues with are given in this command:
conda install astropy colorlog Jinja2 numpy psycopg2 python-dateutil pytz scipy sqlalchemy=1.4 alembic monotonic psutil pytest dask dask[array]

@AntoniaR OK, yes, that's probably also a consequence of mixing and matching packages from commercial Anaconda and conda-forge. In general, that's something that we don't recommend doing, precisely due to these kinds of problems. Our suggested approach to using conda-forge is to configure your environment to always pull everything from conda-forge:
https://conda-forge.org/docs/user/introduction/#how-can-i-install-packages-from-conda-forge
I feel that our docs on this topic could be a bit better but hopefully that can point you in the right direction. It's helpful to if you're comfortable using Conda sub-environments for this kind of stuff since they help a lot with reducing the odds of messing up your entire installation.
I'm going to close this GitHub issue since I think that the proximate problem is now understood and there isn't anything to be done here in this package about it. Antonia, if you have further problems and get stuck trying to work through them, feel free to reach out to me directly.

authors: AntoniaR pkgw sstansill

repo: conda-forge/python-casacore-feedstock


text:
Update to 5.15.0 (WIP)

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 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:

The build section contained an unexpected subsection name. rpath_patcher is not a valid subsection name.
The test section contained an unexpected subsection name. script_env is not a valid subsection name.

So far, I have managed to build this for Windows locally.

hello, any news on this ?

Not much from my side. I push new commits when i can though. Progress is being made but slowly.

Not to this branch mind you ..

oh ok, thanks

See https://github.com/conda-forge/qt-feedstock/pull/206

source: gharchive/pull-request

authors: Tobias-Fischer conda-forge-linter jschueller mingwandroid

repo: conda-forge/qt-feedstock

license_type: permissive

license_source: bigquery


text:
Update to version 0.1.9

Checklist

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

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

authors: conda-forge-linter dbast

repo: conda-forge/r-gdtools-feedstock

license_source: github-api


text:
Update meta.yaml

Checklist

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

@conda-forge-admin please rerender

close in favor #40

authors: iparask mtitov


text:
@conda-forge-admin, please add user @maximilian-hoffmann

Additional comment:
No response

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I added user @maximilian-hoffmann in conda-forge/tsam-feedstock#2.

source: gharchive/issue

authors: conda-forge-linter julian-belina

repo: conda-forge/tsam-feedstock


text:
@conda-forge-admin, please update circle

@conda-forge-admin, please update circle

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I updated the circle-ci deploy key and followed the project.

authors: conda-forge-linter ocefpaf

repo: conda-forge/ulmo-feedstock


text:
xpdAn v0.8.0

Merge only after success.
This pull request was auto-generated by rever

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: CJ-Wright conda-forge-linter

repo: conda-forge/xpdan-feedstock


text:
Develop helm chart for conda-store and public to chartpress

Links:

chartpress https://github.com/jupyterhub/chartpress

Would like to follow the same pattern that dask-gateway took:

https://github.com/dask/dask-gateway/tree/main/resources
https://github.com/dask/dask-gateway/blob/main/.github/workflows/build-publish-helm-chart.yaml

This would create an official helm chart for conda-store. This will allow qhub to decouple from conda-store more.

@costrouc  is this still applicable?

Long term this should be created. We need an easy way to deploy conda-store on Kubernetes and this would help nebari so that we don't need to maintain a terraform module for conda-store there.
But I think this is worth closing until we have a need.

authors: costrouc trallard

repo: conda-incubator/conda-store


text:
Update README.md

typo: should be environment.yaml

LGTM! The build failure is unrelated

authors: gabalafou krassowski

repo: conda-incubator/jupyterlab-conda-store


text:
Add and configure prettier

Latest stylelint does not check formatting.
https://prettier.io/docs/en/configuration
.prettierrc.yml

stylelint could also have a human-friendly .stylelintrc.yml

@adamlaki Easy.
.prettierrc.yml
tabWidth: 2
printWidth: 120
semi: true
singleQuote: true
trailingComma: "es5"

prettier --check preview/assets/scss/ preview/assets/js/ preview/pug/ scss/ test/
# and --write

repo: conedevelopment/sprucecss

license: MIT


text:
Support building on IBM Power

The ARCH variable needs to be munged for IBM Power.

Another thing: @manojnkumar please take a look at #64 (which introduced support for building for s390x / IBM Z) and make sure you modify all the relevant places to include POWER as well.

Hi @manojnkumar. Do you mind closing this PR since the support for Power has been merged?

Closing, as this is resolved by https://github.com/confidential-containers/attestation-agent/pull/193.

authors: Amulyam24 dubek manojnkumar


text:
Ibmcloud: fix guest selinux is enabled in k8s worker

Add disable_guest_selinux = true to the kata configuration on the k8s worker.
With the change in https://github.com/confidential-containers/cloud-api-adaptor/pull/441 this makes setting up the nginx container demo environment using Terraform work again.

If PR #441 can be merged I'll edit this PR to remove the 2d45bda commit.


text:
Initialize OC in genesis

After discussion with Martin, we decided that for both OC (Oversight Community) and AP (Arbiter Pool), we will already know off-chain the identities of the genesis participants and have their consent for initial setup. This means we can take a list of members in the genesis file and set it up during InitGenesis call. The process will be:
Validate:

Ensure all accounts in the initial list have a bank balance of more than "escrow_amount" utgd

Execute:

Create Trusted-Circle (OC or AP) using the first member of the member list as creator, and sending the min escrow.
Creator makes a proposal to add all other members
Create executes this proposal
Loop over all other members, call DepositEscrow with the minimum amount
Check the voting member set is equal to the list of all members defined in genesis

All these calls can be done in Go and is the only way to send tokens from many accounts to a contract.

Another useful test case to base on in Rust https://github.com/confio/tgrade-contracts/blob/main/contracts/tgrade-trusted-circle/src/tests/bdd_tests.rs#L116-L141
The relevant Go code is here https://github.com/confio/tgrade/blob/main/x/poe/bootstrap.go#L84-L95 which just creates with one member. We need to add a function to proposal all the other voters and have each deposit their escrow one by one (just as in the Rust code from unit test setup)

@kmw101 can we safely assume and check that all OC members have enough tokens to pay the escrow?

@kmw101 can we safely assume and check that all OC members have enough tokens to pay the escrow?

We will allocate tokens in Genesis to OC members.

authors: alpe ethanfrey kmw101

repo: confio/tgrade


text:
Unable to load DLL 'librdkafka' in dotnet4.6.1

Hi, I am facing same exact issue.
Confluent.Kafka version="2.2.0".
OS: windows 64x
Framework: .net4.6.1
IDE: visual studio 2022.
I tested in a console application, you can take a look to the screenshots attached.

Originally posted by @HanaaGhasoub in https://github.com/confluentinc/confluent-kafka-dotnet/issues/364#issuecomment-1743061634

I tried others recommendations like install c++ redistributions, or using visual studio 2019, or passing the librdkafka.dll path to Library.Load() method, but still same result.

Supported framework is only 462 https://www.nuget.org/packages/Confluent.Kafka/#supportedframeworks-body-tab

repo: confluentinc/confluent-kafka-dotnet


text:
Disconnected while requesting ApiVersion: might be caused by incorrect security.protocol configuration

Description
OK, I'm new to C# and .net, but have a working implementation with a java client on my machine and am trying to help our .net developers connect to the kafka service.
Kafka is running inside a kubernetes cluster on a private network (for example 10.1.2.3:9092). When I connect from my workstation with a java client, I only have to specify the bootstrap server and everything else works without any issue. This means that the network configuration is fine and there are no firewall issues blocking the connection.
However I try to configure the client, either plaintext, ssl or sasl I get either the following error, or an issue with ssl handshake. In java it's not necessary to configure anything related to ssl or sasl.
%7|1703086748.514|MEMBERID|rdkafka#consumer-1| [thrd:app]: Group "test-consumer-group": updating member id "(not-set)" -> ""
%7|1703086748.518|INIT|rdkafka#consumer-1| [thrd:app]: librdkafka v2.3.0 (0x20300ff) rdkafka#consumer-1 initialized (builtin.features gzip,snappy,ssl,sasl,regex,lz4,sasl_gssapi,sasl_plain,sasl_scram,plugins,zstd,sasl_oauthbearer,http,oidc, SSL ZLIB SNAPPY ZSTD CURL SASL_SCRAM SASL_OAUTHBEARER PLUGINS HDRHISTOGRAM, debug 0x2504)
%7|1703086748.518|CGRPSTATE|rdkafka#consumer-1| [thrd:main]: Group "test-consumer-group" changed state init -> query-coord (join-state init)
%7|1703086748.518|CGRPQUERY|rdkafka#consumer-1| [thrd:main]: Group "test-consumer-group": no broker available for coordinator query: intervaled in state query-coord
%7|1703086748.527|CGRPOP|rdkafka#consumer-1| [thrd:main]: Group "test-consumer-group" received op SUBSCRIBE in state query-coord (join-state init)
%7|1703086748.527|SUBSCRIBE|rdkafka#consumer-1| [thrd:main]: Group "test-consumer-group": subscribe to new subscription of 1 topics (join-state init)
%7|1703086748.527|CGRPQUERY|rdkafka#consumer-1| [thrd:main]: Group "test-consumer-group": no broker available for coordinator query: intervaled in state query-coord
%6|1703086748.529|FAIL|rdkafka#consumer-1| [thrd:sasl_plaintext://10.1.2.3:9092/bootstrap]: sasl_plaintext://10.1.2.3:9092/bootstrap: Disconnected while requesting ApiVersion: might be caused by incorrect security.protocol configuration (connecting to a SSL listener?) or broker version is < 0.10 (see api.version.request) (after 1ms in state APIVERSION_QUERY)
%3|1703086748.529|ERROR|rdkafka#consumer-1| [thrd:sasl_plaintext://10.1.2.3:9092/bootstrap]: 1/1 brokers are down
%3|1703086748.530|ERROR|rdkafka#consumer-1| [thrd:app]: rdkafka#consumer-1: sasl_plaintext://10.1.2.3:9092/bootstrap: Disconnected while requesting ApiVersion: might be caused by incorrect security.protocol configuration (connecting to a SSL listener?) or broker version is < 0.10 (see api.version.request) (after 1ms in state APIVERSION_QUERY)
%6|1703086748.737|FAIL|rdkafka#consumer-1| [thrd:sasl_plaintext://10.1.2.3:9092/bootstrap]: sasl_plaintext://10.1.2.3:9092/bootstrap: Disconnected while requesting ApiVersion: might be caused by incorrect security.protocol configuration (connecting to a SSL listener?) or broker version is < 0.10 (see api.version.request) (after 0ms in state APIVERSION_QUERY, 1 identical error(s) suppressed)

How to reproduce
The following is the most simple implementation in .net
using Confluent.Kafka;
using Microsoft.Extensions.Hosting;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace Connector_Simplified
{
    internal class Worker : BackgroundService
    {
        protected override async Task ExecuteAsync(CancellationToken stoppingToken)
        {
            await Task.Yield();
            ConsumerConfig config = new ConsumerConfig
            {
                BootstrapServers = "10.1.2.3:9094",
                GroupId = "test-consumer-group",
                ApiVersionRequest = true,
                AutoOffsetReset = AutoOffsetReset.Earliest,
                SecurityProtocol= SecurityProtocol.SaslPlaintext,
                Debug = "consumer, cgrp, topic, fetch",
                SaslMechanism=Confluent.Kafka.SaslMechanism.Gssapi,
//                SslEndpointIdentificationAlgorithm = SslEndpointIdentificationAlgorithm.Https,
//                SecurityProtocol = SecurityProtocol.SaslSsl,
                SslCaLocation = "probe"
            };
            IConsumer<Ignore, string> consumer = new ConsumerBuilder<Ignore, string>(config).Build();
            consumer.Subscribe("test-topic");

            while (!stoppingToken.IsCancellationRequested)
            {
                ConsumeResult<Ignore, string> message = consumer.Consume(stoppingToken);
                Console.WriteLine($"Received message at {message.TopicPartitionOffset}: {message.Message.Value}");
            }
        }
    }
}

I have played with every possible combination of PlainText, Sasl and SSL that I can think of, nothing works.
Checklist
Please provide the following information:

Confluent.Kafka nuget version: 2.3.0
Apache Kafka version 3.3.1
Operating system - client is running on windows workstation, kafka is running inside a kubernetes cluster deployed using the bitnami helm template.
Broker log excerpts - the broker does not produce any logs when the .net consumer attempts to connect, but does provide logs when the java consumer connects.

I'm fairly sure I am, I think I've tried everything just in case. We're now looking to reconfigure the broker to see if we can set up something that mutually works, but it needs to be done in conjunction with other systems that are currently working.


text:
chore: update repo by service bot

update repo by Service Bot

CHANGELOG
FILE NAME - CHANGED BY - COMMIT MESSAGE
.github/CODEOWNERS - framework - chore: update repo codeowners [ci skip]

repo: confluentinc/maven


text:
Use WebXR Raw Camera Access API

With WebXR Raw Camera Access API in Chrome:
https://bugs.chromium.org/p/chromium/issues/detail?id=1090056
WebXR Raw Camera Access API Explainer:
https://github.com/immersive-web/raw-camera-access/blob/main/explainer.md
We should revisit our ARMarker and support a CV pipeline using one of the following:

AR Headset: capture camera facing forward using getUserMedia
Phone/tablet with WebXR Camera Capture API support: capture passthrough camera frames using this API
iPhone/iPad: camera capture for WebXRViewer/WebARViewer (current CV support)

Describe the solution you'd like
Support a CV pipeline to detect AR markers that can support more devices (Chrome v93+ on Android).

Partially implemented with https://github.com/conix-center/ARENA-core/commit/d642801d59d32c5942e468d60df6caad61345801.
Missing AR Headset camera capture.
Known issues:
In chrome, grabbing both cameras at the same time seems to not work quite well.

Should be complete with c297323.

repo: conix-center/ARENA-core


text:
[13-2] 제한시간이 끝나면 전광판에 O/X가 표시된다.

예상시간: 2h

실제 시간: 1.5h


text:
378 virtual amm

The Problem

The Solution

Checklist

[x]  Integrate StableSwap contracts into the codebase.
[x]  Make sure unit tests for the contracts are sufficient.
[x]  Integrate router code to query swap rate on auction.
[x]  Unit tests.
[x]  Deploy contract to chain.
[x]  Load tests.

Closing in favor of other PR.

authors: rhlsthrm wanglonghong

repo: connext/nxtp


text:
Rss feed doesn't seem to be updating

I noticed that despite the flat workflow triggering it isn't populating my rss folder.  When I tried out one of the rss feeds you already have set up I also noticed that the feed was a few tiktoks behind- including one iamtabithabrown had uploaded 2 hours ago

It looks like TikTok has broken the library this tool relies on, yet again. It's really a game of whack-a-mole by the library author, as TikTok constantly change things (presumably to prevent bots etc). Generally what happens is that a library fix is made and we'll automatically get it on the next run of this tool.
TBH, I wouldn't rely on tiktok-rss-flat - we really need TikTok to provide a proper API or actual RSS feeds.

authors: Balentay conoro

repo: conoro/tiktok-rss-flat


text:
VEMC

因VMC名称已有重复名称的代币，为了更好的诠释贴合项目，以及VEM是Vending Machine简写，所以将名称由 VMC 更改至 VEMC。
原VMC已提交改为VMC_Old：https://github.com/consenlabs/token-profile/pull/1111

你好，请提供完整的项目信息，谢谢。https://help-center.token.im/hc/article/360007261813

repo: consenlabs/token-profile


text:
Add uno token

团队背景：UNO是【UNIWORLD】 中的数字资产，由新加坡主体 UNI Capital 发起并运营，经游戏挖矿产出，可用于抵押、交易、租赁等。UNO总量2100万枚，每日产出1.4W枚，前3年内每季度产量减少10%，3年后产量维持不变，总共可挖21年。
项目基本情况：在金融方面，UNO已获得由韩国长理资本、新加坡斯特资本等后起之秀的500万美金战略投资，帮助推进全球范围内跨链挖矿及UNIWORLD生态应用落地。
其实UNO是致力于探索一种全新的跨链挖矿方式，解决现有算力资源的浪费，产出效率价值低等问题。
收录的交易所：Aofex.com
转账所需 Gas Limit（对 ERC-20 项目方）：60000

请不要提交多余的文件。


text:
Add ETHD token

官方公告：http://ethd.petbaby77.com/
团队背景：
ETHD团队成立于2019年10月，团队成员包括区块链专家、金融专家、营销顾问，在金融科技和数字货币领域有丰富的经验。创始人曾创建金融科技公司ACCELE Holdun ，有丰富的创业和管理经验，在区块链领域也有深入的研究。
项目基本情况：
ETHD是一个建立在以太坊网络上的去中心化开放式平台，旨在解决目前公链性能瓶颈，成为新一代的区块链应用操作系统。ETHD的网络核心是一个独特设计的公开的区块链系统，是为了解决以太坊令人诟病的可拓展性不足以及效率低下的问题而生的，拥有智能合约，高交易应用程序，分布式账本等功能。
媒体报道：
金色财经：https://www.jinse.com/blockchain/585409.html
收录的交易所：
转账所需 Gas Limit（对 ERC-20 项目方）： 60000

非常抱歉，由于该项目存在较多不实信息，无法合并。


text:
🛑 trashley.incongru.org is down

In 6fa314b, trashley.incongru.org (https://trashley.incongru.org) was down:

HTTP code: 403
Response time: 32 ms

Resolved: trashley.incongru.org is back up in ccea747.

repo: constructions-incongrues/status


text:
Fix remote_sources jsonschema

Maintainers will complete the following section

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

rn notes: Fix remote_sources jsonschema

repo: containerbuildsystem/osbs-client


text:
[snapshots/devmapper] race window causing process IO hang

Description
The issue beblow happens several times beforing the root
cause found:
  1. A `fdisk -l` process has being hung up for a long time;
  2. A image layer snapshot device is visiable to dmsetup, which
       should *not* happen because it should be deactivated after
       `Commit()`;

The backtrace of fdisk is always the same over time:
    [<ffffffff810bbc6a>] io_schedule+0x2a/0x80
    [<ffffffff81295a3f>] do_blockdev_direct_IO+0x1e9f/0x2f10
    [<ffffffff81296aea>] __blockdev_direct_IO+0x3a/0x40
    [<ffffffff81290e43>] blkdev_direct_IO+0x43/0x50
    [<ffffffff811b8a14>] generic_file_read_iter+0x374/0x960
    [<ffffffff81291ad5>] blkdev_read_iter+0x35/0x40
    [<ffffffff8125229b>] new_sync_read+0xfb/0x240
    [<ffffffff81252406>] __vfs_read+0x26/0x40
    [<ffffffff81252b96>] vfs_read+0x96/0x130
    [<ffffffff812540e5>] SyS_read+0x55/0xc0
    [<ffffffff81003c04>] do_syscall_64+0x74/0x180

Steps to reproduce the issue:
One reproducer is:
1. enlarge the race window by putting sleep seconds there;
2. run while true; do sudo fdisk -l; sleep 0.5; done on one terminal;
3. and pull image on another terminal;
Describe the results you received:

fdisk -l IO hang on the image snapshot device

Describe the results you expected:
No process hang, and image snapshot device is not visible to dmsetup ls;
Output of containerd --version:
containerd --version
containerd github.com/containerd/containerd 1.2.5 05572c5e0a678f0d26c98e47582282c74a844c78
Any other relevant information:

Some steps to narrow down:
the fdisk process

which device is waiting on?

crash> foreach 130130 files
PID: 130130  TASK: ffff887d03b48000  CPU: 46  COMMAND: "fdisk"
ROOT: /
...
4 ffff887975d2c8c0 ffff88031fa2dc80 ffff887c3a590dd8 BLK  /dev/dm-3

the stack

crash> bt 130130
PID: 130130  TASK: ffff887d03b48000  CPU: 46  COMMAND: "fdisk"
#5 [ffffc900769afcb0] wait_on_page_bit_killable at ffffffff811b8695
#6 [ffffc900769afd08] generic_file_read_iter at ffffffff811b8823
#7 [ffffc900769afdc8] blkdev_read_iter at ffffffff81291ad5
#8 [ffffc900769afdd8] new_sync_read at ffffffff8125229b
#9 [ffffc900769afe98] __vfs_read at ffffffff81252406
#10 [ffffc900769afea8] vfs_read at ffffffff81252b96

the code

crash> dis -l 0xffffffff811b8823
mm/filemap.c: 1734

if (!PageUptodate(page)) {
/*
* See comment in do_read_cache_page on why
* wait_on_page_locked is used to avoid unnecessarily
* serialisations and why it's safe.
*/
error = wait_on_page_locked_killable(page);

the device state

no inflight io

crash> dev -d
253 ffff887d05c1d000   dm-3       ffff8818a4730000       0     0     0     0

but there is IO on deferred list

crash> gendisk.private_data ffff887d05c1d000
  private_data = 0xffffc900316cd000
crash> mapped_device.deferred 0xffffc900316cd000
  deferred = {
    head = 0xffff887975d2e6c0,
    tail = 0xffff880262511040
  }
 crash> bio.task 0xffff887975d2e6c0
  task = 0xffff887d03b48000
crash> task_struct.comm 0xffff887d03b48000
  comm = "fdisk\000h\000ec\000\000\000\000\000"

why the IO cannot complete?
the device is suspened:

crash> mapped_device.flags 0xffffc900316cd000
flags = 71
crash> p/t 71
$2 = 100 0111

The responding flags are:
#define DMF_SUSPENDED 1
#define DMF_FROZEN 2
#define DMF_FREEING 3
#define DMF_DEFERRED_REMOVE 6

repo: containerd/containerd


text:
Proposal: mount slice support extra options

What is the problem you're trying to solve
Nydus is a open source project which provide a new image format and bring lazyload ability to containers. It mainly consist of nydus-snapshotter(remote snapshotter), nydusd(fuse/virtiofs daemon), nydusify(for build image) and so on. Runc and Kata Container both have supported Nydus；
When integrating Kata Container with Nydus, it need to  delivery some config information from nydus-snapshotter to kata-shim, but the Mount struct has no suitable field to carry information.
Describe the solution you'd like
I think there are two ways to support this case:

Mount struct adds a new field like ExtraOptions []string,  in this way, Containerd does not  need to modify;
Append config information(format: extraopton=xxxx) to Mount struct Options field, in this way, Containerd need filter extraoption=xxx option in Mount method.

I would prefer first method, as it is more clear.
Additional context
No response

Hi, Is there any ideas?

What type of config information?

What type of config information?

@dmcgowan  Config information is struct type, but it can be serialized to string, just like
type RafsOption struct {
	Source      string `json:"source"`
	Config      string `json:"config"`
	Snapshotdir string `json:"snapshotdir"`
}

authors: dmcgowan luodw


text:
Some performance optimization when there are lots of containers to list

When use 'ctr c info ':
The result of api named Get contains all container info, we don't need to call Get API again.
When use 'ctr c ls':
The result of api named List contains all container's info, we don't need to call Get API for each container.
This is useful when there are lots of containers to list.
Please check it, thanks.

I think this is a good idea, thinking more on how we want to handle this with the client methods

authors: crosbymichael lifubang


text:
Cherrypick #843 to release/1.0

Cherrypick #843 to release/1.0 to avoid issues for future 1.0 releases.

/test pull-cri-containerd-node-e2e

repo: containerd/cri


text:
OCI runtime start failed: container process is already dead: unknown" OCI Runtime start failed: Container process is already dead: unknown"

Description
sudo /usr/local/bin/nerdctl run -d --name istcs-prometheus-config-reloader \
--restart=always \
-v "/mnt/plugins"/prometheus/conf:/etc/config:ro \
"10.102.26.195/monitoring_containers/prometheus-config-reloader:v0.65.1" \
--watch-interval=5s \
--reload-timeout=2s \
--watched-dir=/etc/config \
- reload - url = http://10.102.26.195: "9090" / - / reload

When I go to run when the time, but not seen running late, and the problem about: https://github.com/docker/for-linux/issues/647, not sure what causes it
Steps to reproduce the issue
Run the above command, which runs a prometheus and a reload container
sudo /usr/local/bin/nerdctl run -d --name istcs-prometheus-server \
--restart=always \
--net=host \
-p "9090":9090 \
-v "/mnt/plugins"/prometheus/conf:/etc/config \
-v "/mnt/plugins"/prometheus/rules:/etc/config/rules \
-v "/mnt/plugins"/prometheus/data:/data \
-v "/mnt/plugins"/prometheus/prome-tokens:/etc/prome-tokens:ro \
"10.102.26.195 / monitoring_containers/Prometheus: v2.44.0 \"
--storage.tsdb.retention.time=90d \
--config.file=/etc/config/prometheus.yml \
--storage.tsdb.path=/data \
--web.listen-address="0.0.0.0:9090" \
--web.console.libraries=/etc/prometheus/console_libraries \
--web.console.templates=/etc/prometheus/consoles \
--web.enable-lifecycle \
--web.enable-admin-api \
--query.max-concurrency=100

Find a docker hub image and try to use the same image, here I changed to my private image repository address
Describe the results you received and expected
Expect no such error, which I found once
What version of nerdctl are you using?
nerdctl -v
nerdctl version 1.7.3
[root@localhost script-rollback]# runc -v
runc version 1.1.12
commit: v1.1.12-0-g51d5e946
spec: 1.0.2-dev
go: go1.20.13
libseccomp: 2.5.4
[root@localhost script-rollback]# containerd -v
containerd github.com/containerd/containerd v1.7.13 7c3aca7a610df76212171d200ca3811ff6096eb8

Are you using a variant of nerdctl? (e.g., Rancher Desktop)
None
Host information
cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)

 uname  -a
Linux localhost.localdomain 3.10.0-1160.el7.x86_64 #1 SMP Mon Oct 19 16:18:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

@kubecto could you provide a simple way to reproduce this?
Obviously, we do not have access to your private registry.
What about you push these images on the hub?

authors: apostasie kubecto

repo: containerd/nerdctl


text:
Release1.2.0

coredns: do not combine results of A and AAAA records
run,serve: create aardvark pid in child before we notify parent process
coredns: response message set recursion available if RD is true
document configuration format

/lgtm
/hold

/hold cancel

authors: baude mheon

repo: containers/aardvark-dns


text:
copr workaround: temporarily re-add .autocopr/aardvark-dns.spec

This should be gotten rid of once the copr infra upgrade to f35 is
complete in favor of aardvark-dns.spec.rpkg.
Signed-off-by: Lokesh Mandvekar lsm5@fedoraproject.org
@mheon @baude @rhatdan PTAL.

LGTM

/lgtm

authors: flouthoc lsm5 mheon


text:
Builds fail with "no such device or address"

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description

All of a sudden podman stopped building images, when it tries to commit the first build step, it always fails with no such device or address:
Steps to reproduce the issue:

I don't how to get podman into this state

Describe the results you received:
DEBU[0072] COMMIT
DEBU[0072] parsed reference into "[overlay@/home/jreimann/.local/share/containers/storage+/run/user/XXX/containers:overlay.mount_program=/usr/bin/fuse-overlayfs]docker.io/library/808b6b1ad1d9de6f7d21a816efa7d62de5b50a6fe15690813aa168d8dde6de77-tmp:latest"
DEBU[0072] committing image with reference "containers-storage:[overlay@/home/jreimann/.local/share/containers/storage+/run/user/XXX/containers:overlay.mount_program=/usr/bin/fuse-overlayfs]docker.io/library/808b6b1ad1d9de6f7d21a816efa7d62de5b50a6fe15690813aa168d8dde6de77-tmp:latest" is allowed by policy
DEBU[0072] parsed reference into "[overlay@/home/jreimann/.local/share/containers/storage+/run/user/XXX/containers:overlay.mount_program=/usr/bin/fuse-overlayfs]@9382431041983a6d9bc305bddbe238b262d8d5a888667c8b0075e0261c44077d"
DEBU[0072] base image "9382431041983a6d9bc305bddbe238b262d8d5a888667c8b0075e0261c44077d" is already present in local storage, no need to copy its layers
DEBU[0072] layer list: ["fc86ad79496a0932dd56764ae4e00954f6a760d84a27967bd61a41c6ce0bc59c" "91ede8b45c8090bf46f464486216e90182dcbaa6fdb1060ea3020da416156d3d"]
DEBU[0072] using "/var/tmp/buildah869835859" to hold temporary data
DEBU[0072] compressing layer "91ede8b45c8090bf46f464486216e90182dcbaa6fdb1060ea3020da416156d3d" with gzip
DEBU[0072] overlay: mount_data=ro,lowerdir=/home/jreimann/.local/share/containers/storage/overlay/fc86ad79496a0932dd56764ae4e00954f6a760d84a27967bd61a41c6ce0bc59c/empty,upperdir=/home/jreimann/.local/share/containers/storage/overlay/fc86ad79496a0932dd56764ae4e00954f6a760d84a27967bd61a41c6ce0bc59c/diff,workdir=/home/jreimann/.local/share/containers/storage/overlay/fc86ad79496a0932dd56764ae4e00954f6a760d84a27967bd61a41c6ce0bc59c/work,context="system_u:object_r:container_file_t:s0:c338,c515"
Error: error committing container for step {Env:[DISTTAG=f31container FGC=f31 container=oci  PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin] Command:run Args:[microdnf -y install java-11-openjdk-headless] Flags:[] Attrs:map[] Message:RUN microdnf -y install java-11-openjdk-headless Original:RUN microdnf -y install java-11-openjdk-headless}: error copying layers and metadata for container "015c297dc28b5c6d29e323a257660177a3576cbc1444e10819afd294e0dbf8e7": Error initializing source containers-storage:fedora-minimal-working-container: error extracting layer "91ede8b45c8090bf46f464486216e90182dcbaa6fdb1060ea3020da416156d3d": no such device or address

Describe the results you expected:
A working build, as before.
Additional information you deem important (e.g. issue happens only occasionally):
Output of podman version:
$ podman version
Version:            1.8.0
RemoteAPI Version:  1
Go Version:         go1.13.6
OS/Arch:            linux/amd64

Output of podman info --debug:
debug:
  compiler: gc
  git commit: ""
  go version: go1.13.6
  podman version: 1.8.0
host:
  BuildahVersion: 1.13.1
  CgroupVersion: v2
  Conmon:
    package: conmon-2.0.10-2.fc31.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.10, commit: 6b526d9888abb86b9e7de7dfdeec0da98ad32ee0'
  Distribution:
    distribution: fedora
    version: "31"
  IDMappings:
    gidmap:
    - container_id: 0
      host_id: 110147
      size: 1
    - container_id: 1
      host_id: 120000
      size: 165536
    uidmap:
    - container_id: 0
      host_id: 110147
      size: 1
    - container_id: 1
      host_id: 120000
      size: 165536
  MemFree: 5785677824
  MemTotal: 33441271808
  OCIRuntime:
    name: crun
    package: crun-0.12.2.1-1.fc31.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.12.2.1
      commit: cd7cea7114db5f6aa35fbb69fa307c19c2728a31
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  SwapFree: 16793989120
  SwapTotal: 16793989120
  arch: amd64
  cpus: 8
  eventlogger: journald
  hostname: flunder
  kernel: 5.5.7-200.fc31.x86_64
  os: linux
  rootless: true
  slirp4netns:
    Executable: /usr/bin/slirp4netns
    Package: slirp4netns-0.4.0-20.1.dev.gitbbd6f25.fc31.x86_64
    Version: |-
      slirp4netns version 0.4.0-beta.3+dev
      commit: bbd6f25c70d5db2a1cd3bfb0416a8db99a75ed7e
  uptime: 101h 0m 55.65s (Approximately 4.21 days)
registries:
  search:
  - docker.io
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - quay.io
store:
  ConfigFile: /home/jreimann/.config/containers/storage.conf
  ContainerStore:
    number: 0
  GraphDriverName: overlay
  GraphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-0.7.5-2.fc31.x86_64
      Version: |-
        fusermount3 version: 3.6.2
        fuse-overlayfs: version 0.7.5
        FUSE library version 3.6.2
        using FUSE kernel interface version 7.29
  GraphRoot: /home/jreimann/.local/share/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 1
  RunRoot: /run/user/110147/containers
  VolumePath: /home/jreimann/.local/share/containers/storage/volumes

Package info (e.g. output of rpm -q podman or apt list podman):
podman-1.8.0-2.fc31.x86_64

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

Could you try the podman release that is in updates-testing?

Also make sure you have the latest crun and fuse-overlayfs

I just figured out, that it doesn't seem to be an issue with my machine, but with the base image:
It fails with FROM registry.fedoraproject.org/fedora-minimal:31, but works when I change back to registry.access.redhat.com/ubi8/ubi-minimal.

Could you try the podman release that is in updates-testing?

If you can tell me "how", sure.

dnf -y update podman --enablerepo=updates-testing

So here is a bit more information:

When I use a RUN touch foo step, it seems to work. When I use my original command RUN microdnf -y install java-11-openjdk-headless it fails (but works when using the UBI image, however that might also indicate some issue with the RPM or microdnf)

Next I installed podman from testing:
$ rpm -q podman && podman --version
podman-1.8.0-2.fc31.x86_64
podman version 1.8.0

I see no change with the updated version:
STEP 3: COMMIT
Error: error committing container for step {Env:[DISTTAG=f31container FGC=f31 container=oci  PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin] Command:run Args:[microdnf -y install java-11-openjdk-headless] Flags:[] Attrs:map[] Message:RUN microdnf -y install java-11-openjdk-headless Original:RUN microdnf -y install java-11-openjdk-headless}: error copying layers and metadata for container "873b04708bff2da664bfad51e10a556b5944feddb14adaa43a1159f080270c96": Error initializing source containers-storage:fedora-minimal-working-container: error extracting layer "a5e18415fc61888a750929d9a94ba829a062d99cd84e58f36adf34f3dacd0ac5": no such device or address

@giuseppe Any ideas?

Is this the same issue as https://github.com/containers/buildah/issues/2161?

For the record, I see this problem when building from registry.fedoraproject.org/fedora:32 or registry.fedoraproject.org/fedora:rawhide images but not with registry.fedoraproject.org/fedora:31, registry.fedoraproject.org/fedora:30, or registry.fedoraproject.org/fedora:29.

@adelton it may be the same, but I'd like to keep this open until we fully determine that.  Sure looks like it though.

@adelton @TomSweeneyRedHat Still looking at this or should we close?

I do not experience any issues with rootless podman-1.8.2-2.fc31.x86_64.

I can no longer reproduce this issue. Maybe it was my update to podman 1.8.2, or maybe it was due to some update in the fedora images, I can't tell. Now it works for me.

authors: TomSweeneyRedHat adelton ctron rhatdan

repo: containers/libpod


text:
run different cgroup tests depending on conditions

when running podman's integration tests, we need to be able to understand
our environment because the podman command will differ as will the results.
there is no 100% way to know if we are in a container, but using a combination
of container= and checking /proc seemed reasonable for our test suite.  non of this
code is run in podman proper.
Signed-off-by: baude bbaude@redhat.com

LGTM

LGTM, assuming happy tests.

@rh-atomic-bot r+

@rh-atomic-bot retry

authors: TomSweeneyRedHat baude mheon


text:
Add missing 'container cp' alias and document missing 'container update' command

Some notes

Also reorder the missing update command to better match the container update command (it is in the same management namespace)
'docker cp' is an alias for 'docker container cp', and podman should have the equivalent alias.

/approve

@josegonzalez Thanks for the PR.
Could you also update the man page docs/podman-container.1.md to add podman container cp.
Also update completions for bash and zsh to include it.

/ok-to-test

The Gating failure is our manpage checker - updating podman-container.1.md as @rhatdan requested should resolve it

@rhatdan I don't see how to update the zsh completions, not sure there is anything to do there.

ZSH is autogenerated, you should be fine

LGTM

/lgtm
/approve

authors: TomSweeneyRedHat josegonzalez mheon rhatdan


text:
podman v2 remove bloat v2

rid ourseleves of libpod references in v2 client
Signed-off-by: Brent Baude bbaude@redhat.com

/hold
/lgtm

/lgtm

/hold cancel

authors: baude jwhonce rhatdan


text:
Fix pdPath parameter to point to an executable file

PdPath points to a folder not an executable right now.

Is this why all actions are failing?

@adrianriobo it fixes just Podman Desktop E2E Podman Installation step in one workflow that used locally built executable.
Job I tried to run after adjusting the pde2e-builder image: https://github.com/containers/podman-desktop-e2e/actions/runs/6948326419. The steps is now again passing. Although there are other failures, not related to this. So the fix is at place, now I need to address other problems.

The fix was to pass an executable path rather then folder with executable. We fixed this here, I forgot to update it in the image.

fixed by https://github.com/odockal/pde2e-builder/commit/ea1ca8c96e6da1e36d7fbd070cbfbf670b4e159f.

authors: adrianriobo odockal


text:
Kubernetes Ingress: Buffering annotation is not recognised.

Do you want to request a feature or report a bug?
(Potential) Bug
What did you do?
I tried to configure buffering for an Kubernetes Ingress.
What did you expect to see?
The buffering annotation getting recognised and applied.
What did you see instead?
Nothing, no error in the log, nothing in the dashboard.
I tried removing "traefik" from the annotation. I added it back, tried different things I found online.
Traefik does not seem to notice the annotation at all.
And the documentation was not very percise how it should be configured correctly, it only dokuments that the annotation exists.
Output of traefik version: (What version of Traefik are you using?)
Traefik docker container 1.7.1
What is your environment & configuration (arguments, toml, provider, platform, ...)?
# (paste your configuration here)

Kubernetes Ingress Annotation
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    traefik.ingress.kubernetes.io/buffering: |
      maxrequestbodybytes: 10485760
      memrequestbodybytes: 2097153
      maxresponsebodybytes: 10485761
      memresponsebodybytes: 2097152
      retryexpression: IsNetworkError() && Attempts() <= 2
    kubernetes.io/ingress.class: traefik

If applicable, please paste the log output in DEBUG level (--logLevel=DEBUG switch)

Hi @Flyffies ,
We think that your problem is in your yaml configuration file because we tested this option here https://github.com/containous/traefik/blob/v1.7/provider/kubernetes/kubernetes_test.go#L908
Could you use https://yaml-multiline.info/ and double check your configuration?

Hi @jbdoumenjou,
I put my YAML through a yaml validator, and it is valid. The multiline part gets read correct.
However, the newlines get converted into '\n's. Maybe they dont get read correctly when inside the annotation? I extracted the annottion and ran it through the validator as well. When replacing the \n with a newline it was also valid...
I just get it to work and the log contains nothing...

could try:
    traefik.ingress.kubernetes.io/buffering: |-
      maxrequestbodybytes: 10485760
      memrequestbodybytes: 2097153
      maxresponsebodybytes: 10485761
      memresponsebodybytes: 2097152
      retryexpression: IsNetworkError() && Attempts() <= 2

Sorry for getting back so late... I tried it, and it does not work... Traefik is still not able to pick the annotation up.
Here is my complete Ingress:
`apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: traefik
traefik.ingress.kubernetes.io/buffering: |-
maxrequestbodybytes: 10485760
memrequestbodybytes: 2097153
maxresponsebodybytes: 10485761
memresponsebodybytes: 2097152
retryexpression: IsNetworkError() && Attempts() <= 2
name: demo-app
namespace: default
spec:
rules:

host: demo.
http:
paths:

backend:
serviceName: demo-app
servicePort: 80
`

In fact, the annotation must be set on the service not on the ingress.
I updated the documentation https://github.com/containous/traefik/pull/3991

Thanks, yes. Now it works.

authors: Flyffies jbdoumenjou ldez

repo: containous/traefik


text:
Properly add response headers for CORS

What does this PR do?
Reworks the response header handling for the new v2 middleware chain handling
Motivation
fixes #4825, #4979
More

[x] Added/updated tests
[x] Added/updated documentation - None needed, bugfix

Need to address https://github.com/containous/traefik/issues/4979
This middleware is hijacking CORS requests when the cors features aren't enabled

I need to wrap my head around CORS again before I can properly review the code, but I'm already noting that the integration tests used to pass for me on mac, and that they're not passing now with this PR.
I think it would be preferable not to introduce the "passes on linux only" bias for yet another test, so it would be nice if you could find another way to set up the tests for that PR.

TESTFLAGS="-tlog -check.f HeadersSuite" make test-integration CI=2 Should work.
The issue stems from the fact that integration tests run slower in docker for mac. Extending the timeout allows the tests to run and pass.

I don't know why there are conflicts. I don't have any conflicts on my branch:
https://github.com/containous/traefik/compare/v2.0...dtomcej:issue-4825

authors: dtomcej mpl


text:
Gem revamp

Warning!!! breaking changes ahead
New version of this middleman extension:

This new version is no longer coupled to blog sites
Custom mappers
Rebuild only when changes in the imported data
Entries stored as local data

Looks good so far, can you also sprinkle some ( and ) around the method calls :cherry_blossom:

I guess @asaaki will have a lot more to add

We should remove the version bump from this PR.
(It's quite common to do this in a dedicated commit/PR to avoid possible conflicts with concurrent PRs.)

Remove bump in version.rb
Adjust changelog headline to [Unreleased][unreleased] (like proposed at http://keepachangelog.com/).

Will review the rest of the PR later.

@asaaki good point! Done.

Looks good to me now, should we make one commit out if this?

Yes, I think squashing all this mess makes sense

I'll wait for @asaaki comments before doing that

I don't mind, if you really want to get it out now.
Otherwise I would have a final look at this PR tonight.
Also: Some tweaks can always follow in upcoming PR(s).
It's up to you to decide.

@asaaki so let's get this merged and fix anything else in upcoming commits

@pxlpnk has to do this, I'm not an official collaborator/maintainer. :wink:

:+1:  on this.
If you could add a note about the breaking changes to the changelog (I know a major release kind of implies this but better be too verbose here) and squash the commits.

@pxlpnk whenever you want

Merging it somewhat later today and will release a new version on rubygems.

authors: asaaki madtrick pxlpnk

license: mit


text:
[Enhancement] Add a method to force Continue to include file(s) in the index

Validations

[X] I believe this is a way to improve. I'll try to join the Continue Discord for questions
[X] I'm not able to find an open issue that requests the same enhancement

Problem
Continue indexing uses .gitignore to determine files that should not be in the index. There is currently no way to force the index to include a file or directory that is listed in .gitignore.
Solution
Create a .continueinclude file that is checked after ignore to add missing files and directories back into the index.

@sealad886 With .gitignore syntax in .continueignore you can use the negation operator, which should override previous rules, like !node_modules if you wanted this. I'd be curious whether this works for your use case

So my use-case is specifically in a Flask project, where I don't want to check in a couple dot-env files into git, but I still want the index to recognize that I do have those variables defined...so the LLM will stop creating code that loads environment variables, config files, etc.
It's a very edge use-case for me, but realistically the concepts of "include in index" and "include in git" aren't interchangeable. I could imagine others might have more examples.

I kind of like this idea, too. I'd like finer controls over what is/isn't indexed. For example, I'm working on an app now with a 3rdparty directory that I have no intention of ever needing. It's eating up a lot of indexing power. Maybe something like this in vscode settings.json?
{
  "indexing": {
     "include": [
         "${workspaceFolder}/app"
     ],
     "exclude": [
         "${workspaceFolder}/3rdparty"
     ]
  }
}

I realize continuedev is not just for VSCode, so there might be a better way to do it agnostic of server/vscode.

@sestinj I've tried to use the negation operator, but it does not appear to have an effect in the .continueignore file (it works if I edit .gitignore). Possibly related to #1191.

@meanderix I've gotten it to work in .continueignore
https://github.com/continuedev/continue/issues/1191#issuecomment-2359193348
taken from suggestions on the node-ignore repo: https://github.com/kaelzhang/node-ignore/issues/57#issuecomment-555343453
*.*
!*.go

authors: meanderix sealad886 sestinj shannonrdunn src-r-r

repo: continuedev/continue


text:
Secure STN <-> Contiv Agent GRPC connection by using unix-domain sock…

…et instead of TCP

Coverage decreased (-0.1%) to 76.621% when pulling 7e3cdf8fac6a9581607c75344212b2b45fbe3366 on rastislavszabo:stn-socket into 1460f110868927a34ff8abcb6f4b5be55730f632 on contiv:master.

authors: coveralls rastislavszabo

repo: contiv/vpp


text:
Customizable padding around the screen

Maybe like so:
padding:
    top: 0px
    left: 0px
    bottom: auto
    right: auto

Valid values would be number of pixels, or number of pixels with px appended, or string "auto" for auto-computation.

It is implemented in release 0.4.1 and called margins, not padding.

It is implemented in release 0.4.1 and called margins, not padding.

repo: contour-terminal/contour


text:
Update required GITHUB_TOKEN permissions

contents: read should be enough when signatures are stored in a remote repository.
Tested here: https://github.com/pellared/test-cla/pull/1

@ibakshay Can you please take a look?

@pellared,
I am really sorry. I will have a look in the next coming days and merge this PR :) thanks so much for the contribution! I highly appreciate it..

authors: ibakshay pellared

repo: contributor-assistant/github-action


text:
🛑 CC - BACKOFFICE POC is down

In 0b4d54c, CC - BACKOFFICE POC (https://dev.lief.macoapp.de) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CC - BACKOFFICE POC is back up in fda232f after 20 minutes.

repo: conuti-das/status-lfrcs


text:
[Bug]: The .env file from the repository is being overwritten by the project's environment parameters.

Description
Hello.
I have a .env file in the repository, but I've noticed that it's being overwritten by the project's environment parameters.
How can I avoid this?
Minimal Reproduction (if possible, example repository)

Place the .env file in the root directory of the repository with some parameters.
Use these parameters in the application.

Exception or Error
Symfony\Component\DependencyInjection\Exception\EnvNotFoundException:
Environment variable not found: "ENABLE_PAYMENTS".
Version
v4.0.0-beta.259

It's not good practice to commit a .env file... I would guess that this functionality is intended

@ashermyers  Thanks for the answer.
It was working before, about 1 week ago.
Normally, the .env file keeps KEYS and default values, while .env.local and OS environments should override them. It's a common practice. (I'm sure you know it)
I think overriding the entire app file instead of extending it isn't how it should work.
Maybe in this case, Coolify should throw an exception like "Unexpected file" or at leas warning message.
P.S. Where should default values be stored instead?

Okay gotcha.. That makes a lot more sense. I thought you were trying to load secrets from a github repository of some sorts...

The new version will respect the .env file, but any environment variables defined in Coolify will overwrite this environment.

I reverted it for now in v264, because it caused issues for some people.

Hi, when there will be a workaround, so the .env variables won't be overridden?
Deleting of .env caused critical bugs to my projects few times in a row :(

What are the best practice for the workaround till it is not fixed?

Normally, the .env file keeps default values, while .env.local and OS environments should override them. It's a common practice.

It is definitely not:

It is added to each project but NOT committed to source control.

https://www.dotenv.org/docs/security/env
If you want to distribute examples to your devs, please use a file like env.example. This is the way a lot of projects solve this

@codesalatdev
Thanks for clarifying. Common practice ≠ best practice. Now I see that it is even a common mistake to push the .env file.
In the .env file, I store default values like "ENABLE_PAYMENTS", which has no sensitive info.

@VCasecnikovs  Quick workaround: moving envs inside the Environment Variables section.
That's what I did.

@VCasecnikovs Quick workaround: moving envs inside the Environment Variables section.
That's what I did.
Do you mean Coolify's environent variable for resource section?

@VCasecnikovs Quick workaround: moving envs inside the Environment Variables section.
That's what I did.
Do you mean Coolify's environent variable for resource section?

I mean to put .env variables here.

authors: VCasecnikovs andrasbacsai ashermyers codesalatdev victorshdev

repo: coollabsio/coolify


text:
[Bug]: No SSL cert for non-www domain for Docker Compose stack

Is there an existing issue for this?

[X] I have searched the existing issues

Example public repository
coolify
Description
When using docker compose stack and having domain set with a www subdomain
ex.:
www.domain.com
When entering https://domain.com, before the redirect can trigger, I receive an SSL error
NET::ERR_CERT_AUTHORITY_INVALID
certificate is
Subject: TRAEFIK DEFAULT CERT
Issuer: TRAEFIK DEFAULT CERT
looks like non-www cert is not generated, but there is no option to enable it for docker compose stack.
Steps To Reproduce

create app with docker compose stack
setup domain with www subdomain
deploy
enter non-www url
grind your teeth ;-)

Version
3.12.17 (also previously on 3.12.2)

I also get the TRAEFIK DEFAULT CERT when publishing a new project, old projects are working and the certificate is also on the traefik instance in "/etc/traefik/acme/acme.json" but there is no new cert for the new site.

My Problem today was that there was a CAA Entry on DNS.
If there is a CAA Entry on the DNS than you also have to set the one for Letsencrypt.org also.
Otherwise you won't get a SSL Certificate from LetsEncrypt. https://letsencrypt.org/docs/caa/
CAA 0 issue „letsencrypt.org"

I'm closing this issue, because tracking features will be moved to GitHub discussions. Github issues will be only for bugs.
Version 4 is in full focus. v3 related issues will be closed, if it is not a critical bug.
Thanks for your understanding.

authors: andrasbacsai cruonline dissy123


text:
Add new service dolibarr

Changes

Add new Service Dolibarr

I have tested this service and it does not really work on my end. Can you please test the service again? Can I just access it through the domain or does it need https (no http support)? or how do I test it.

Hello i did test it with docker compose empty and it works perfectly. I needed to wait a little bit until dolibarr start and run the migrations.

Thanks for the clarification, after waiting a while it worked, I guess I'm just impatient 😅.
Thanks for the PR, I will merge it.

authors: peaklabs-dev zairigimad


text:
关于切换委托频道,   baby.channel(channelName)后面必须跟scan或者connect方法才能切换成功?

我试了.如果直接baby.channel(channelName).begin();是会报错的.要先扫描或者connect之类的
//切换到委托频道
baby.channel(channelName)
//扫描设备并chan开始执行
.scanForPeripherals().begin();

我的意思是: 如果有一个设备列表, 我一进入设备列表的时候就已经把当前页面上的设备全部connect上了. 点击对应cell上的设备,进入设备详情页. 但是我进入设备详情页控制器的的时候, 如果我要切换channel. 还是必须先执行scan. connect 才能切换委托.

因为我觉得当前设备已经是连接上了的 没必要再去连接扫描.

可以不扫描的。have方法可以传对象
发自我的 iPhone
在 2016年12月6日，上午11:13，Lance <notifications@github.commailto:notifications@github.com> 写道：
因为我觉得当前设备已经是连接上了的 没必要再去连接扫描.
―
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHubhttps://github.com/coolnameismy/BabyBluetooth/issues/61#issuecomment-265049128, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AEx1bzur3tv8BbfkZePbwAmiOBSLIu03ks5rFNLwgaJpZM4JPVH5.

我是用have方法持有已经连接的设备的. 然后还是需要再次调用connect方法才能切换channel. 这样的话就是再次连接了吗?

可以看demo的示例

您的demo 没有这种示例

authors: coolnameismy ldhios

repo: coolnameismy/BabyBluetooth


text:
Further Documentation Improvements

I was able to take the time to go through each individual document and make final changes. I also corrected one of my own typos. Now, I probably could have been patient and waited to send them until I had done all of them, but I'm still pretty new to Git and wasn't sure I'd be able to get to the remainder of the documentation so soon, so apologies for doing this twice in a short period of time.
Hope the documentation changes help!

Thanks again <3

hey @Aurora-Eluvia, is there an email or discord account where I could reach you?

hey @Aurora-Eluvia, is there an email or discord account where I could reach you?

I'll get in touch on Discord.

authors: Aurora-Eluvia coppolaemilio

repo: coppolaemilio/dialogic


text:
Windows 3.1 not starting

I tried to use windows 3.1, i read some other issue about it not working so i thought i would just play around with it but it just gets stuck here

it just stays here and isent doing anything. any ideas?
I have tried with acpi on and off but it hasent fixed anything. tried different memory values but nothing has changed. :(

Duplicate of https://github.com/copy/v86/issues/208

authors: abundant-ray copy


text:
Corrputing playerdata

I was hosting a server with my friend and was asking for help because it did not allow us to join because of a code but they believed that was caused by the mod.  Our playerdata to got corrupted. We where adjusting the config. to make the backpacks openable by players and able to be worn with chestplates. Then the issue occured

https://paste.gg/p/anonymous/1b523c6296354e05843b2d01c88765d7

I checked the log but could not find anything that would indicate WearableBackpack being at fault.
When looking for the error, I can find EnigmaticaModpacks/Enigmatica2Expert#1592. Have a look through that and see if any of the suggested fixes work for you. As this is unlikely to actually be an issue with my mod, I'll close this issue for now. I'll still respond to any comments if I can help with anything, though.

authors: Cummo copygirl

repo: copygirl/WearableBackpacks


text:
ts: AccountClient isn't properly typed

Querying for accounts like program.account.myAccount.fetch(addr) should return an object that is strictly typed for the myAccount account type definition.
However, the client currently types the object as being the union of properties between all IDL defined account structs.

As seen in the screenshot, the typing on the listing account client includes the properties of other account types.

probably for the same reason, using program.methods.accounts({ .. }) is also not typed properly

it it fixed for you? its not working for me

Fixed in https://github.com/coral-xyz/anchor/pull/2440

authors: acheroncrypto callensm paul-schaaf

repo: coral-xyz/anchor


text:
Anchor.toml is unable to parse * while mentioning workspace members

I was trying to add workspace members to anchor.toml file since the smart contracts were in a different directory than the default programs directory. And i observed that when i mentioned the folder path in the workspace members with a *, the anchor.toml  similar to what we have in cargo.toml, it was not able to understand it.
For eg:
[workspace]
members = [
  "solana/my-programs/*"
]

The above didnt work.
But it works fine when the exact directory is mentioned like below.
[workspace]
members = [
  "solana/my-programs/example-program"
]

Is there a particular reason why we dont allow all the * to include all the directories in a particular folder ?
If there isnt, I am happy to open a PR for the above fix.

Is there a particular reason why we dont allow all the * to include all the directories in a particular folder ?

Nothing particular other than globs not being supported by default.

If there isnt, I am happy to open a PR for the above fix

Sounds great!

Added in https://github.com/coral-xyz/anchor/pull/2785

authors: acheroncrypto dhruvja


text:
🛑 Guangdianyun Consoles is down

In 20723c0, Guangdianyun Consoles (https://consoles.guangdianyun.tv) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Guangdianyun Consoles is back up in d583d48.

repo: corcd/charlotte


text:
Differnet backend per listener mix HTTP and HTTPS?

It is possible at this time, or will it be possible in the future to create multiple backends, some HTTP and some HTTPS and specify which listener port listens to which backend? Currently it looks like I can specify multiple backends, but not specify which goes with with listener. Also, it appears that all backends are all HTTP or all HTTPS.

This is super important to simplify how redirecting works. If you can specify different backends for the same host/path based on if it's http or https then you can put in a simple http to https redirect backend that does the 301 (like https://github.com/coreos/docker-nginx-https-redirect).
At the moment the only way to achieve this is to catch it in each application and do the redirect there.
What would be even nicer is if alb-ingress-controller paid attention to ingress.kubernetes.io/ssl-redirect: "true" for us. In ALB there is no native way to do this so we could automate spinning up a redirect service in k8s and point the http part to that service.

It's not possible. Would this be something that could be addressed by multiple ingress definitions?

Would #135 solve your problem?

authors: adamdunkley bigkraig bsharitt

repo: coreos/alb-ingress-controller


text:
fix check for min CoreOS version required when using rkt

There is a minimum version of CoreOS required when using rkt and not
using the alpha channel. This commit fixes the semver comparison

@dimpavloff could you move this PR over to https://github.com/coreos/kube-aws?

@dimpavloff Sorry to bother you but If your fix is intended the same with https://github.com/coreos/kube-aws/commit/46054e97104071586669d1b69f68e028993aed49, it is already merged there.
AFYI, rkt+stable is supported since several days ago
https://github.com/coreos/kube-aws/issues/21
Thanks for your contribution anyway!

Hi guys, thanks for looking! Yes, https://github.com/coreos/kube-aws/commit/46054e97104071586669d1b69f68e028993aed49 fixes the same problem

authors: colhom dimpavloff mumoshu

repo: coreos/coreos-kubernetes


text:
Mounting Storage EXT4 update

Mounting storage (https://coreos.com/docs/cluster-management/setup/mounting-storage/) documentation has not been updated to reflect that EXT4 is now the default filesystem.
Especially the "Use Attached Storage for Docker" should be updated to show what the correct parameters when creating EXT4 filesystem should be. I believe the coreos root volume uses non-default inode values, for example.
I would love to send a pull request myself but I'm not quite sure what the parameters to /usr/sbin/mkfs.ext4 should be and if there are some other issues you should take into account.

Closed by #706

authors: joshix scatterbrain

repo: coreos/docs


text:
ETCD backup policy is not working

I understood that version 0.8.4 onwards ETCD backup policy is working. I have tested the version 0.9.3 and other version as well. It seems ETCD backup policy is not working.
Following is my backup CRD yaml file
apiVersion: "etcd.database.coreos.com/v1beta2"
kind: "EtcdBackup"
metadata:
  name: example-etcd-cluster-backup
  namespace: rook-ceph
spec:
  etcdEndpoints:
  - https://127.0.0.1:2379
  clientTLSSecret: "etcd-peer-tls3"
  storageType: S3
  backupPolicy:
    timeoutInSecond: 30
  s3:
    # The format of "path" must be: "<s3-bucket-name>/<path-to-backup-file>"
    # e.g: "mybucket/etcd.backup"
    path: my-store-external/kannan/etcd.backup-1
    awsSecret: aws1
    endpoint: http://kannan.svc.cluster.local

It is able to take the backup of ETCD snapshot and push it to S3 first time. But further it is not triggering to take the backup.
Kindly let me know whether my configuration is wrong or any problem on the etcd-backup operator

@kannanvr etcd backup policy was changed to be a one time action and not periodic. It was suggested to use a CronJob to schedule backups.
Later there was a proposal to add periodic backups as part of specification in #1841  and it is being concluded here #2028. Good part is you might see it soon in an upcoming release.
@hexfusion will it support iam roles as in kube2iam?

authors: kannanvr raoofm

repo: coreos/etcd-operator


text:
How to use TLS in the etcd go client?

Hi there,
I am a newbie in go, trying to improve https://github.com/crewjam/etcd-aws/ to add TLS in the native design.
I can successfully update the etcd command in the etcd-aws to operate with certificates, and adapt the docker image to use TLS. Unfortunately, that breaks the other interesting tools (auto backup and restore).
I noticed the library used is go-etcd, which seems to be deprecated, so I also thought I could port it to the native client.
Unfortunately I don't understand how to enable TLS in the etcd go client lib. It seems Clientv3 adds TLS options (tls.Config), but not the current client.
What would be the recommendation? Should I use the client v3 even if the etcd cluster is 2.3? Is there an example to configure the client with TLS that someone might share (I probably didn't formulate properly my question to friendly Google, couldn't find any insight there)
Thanks in advance for your help, and sorry for the basic question.

@SaMnCo As @gyuho mentioned, you need to pass the tls config, which is a standard TLS configuration object in go.

@gyuho, Superb thanks. I will give it a try.
On Sun, Aug 7, 2016 at 5:34 PM, Xiang Li notifications@github.com wrote:

Closed #6083 https://github.com/coreos/etcd/issues/6083.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/coreos/etcd/issues/6083#event-747704937, or mute the
thread
https://github.com/notifications/unsubscribe-auth/ACN4dxHsQXO0dnsCLgkNiXjLSUynxH4Aks5qdfsdgaJpZM4JabVp
.

--
SaM'n'Co
R'U Ready? I was BORN ready!

If we are using client v2 for an etcd v2.x, how should we configure the client with TLS?
The client does not take a client v3 tls Config.
https://github.com/coreos/etcd/blob/master/client/client.go#L82-L144

You pass tls enabled transport to v2 client.
e.g. https://github.com/coreos/etcd/blob/master/etcdctl/ctlv2/command/util.go#L153-L314

authors: SaMnCo genevievelesperance gyuho xiang90

repo: coreos/etcd


text:
etcd v3.1rc.1 etcdctl times out with API=3 but is OK with API=2

I setup a single node with SSL/TLS using cfssl. The cluster came up and I set following environment variables:
ETCDCTL_CA_FILE=/etc/ssl/etcd/ca.pem
ETCDCTL_KEY_FILE=/etc/ssl/etcd/etcdv3ssl.key
ETCDCTL_API=3
ETCDCTL_CERT_FILE=/etc/ssl/etcd/etcdv3ssl.pem
if I type "etcdctl member list", it says:
"Error:  context deadline exceeded" after about a 3s pause.
But if I type "ETCDCTL_API=2 etcdctl member list", it works:
ETCDCTL_API=2 etcdctl member list
34b2b20e19938f29: name=etcdv3 peerURLs=https://10.0.0.254:2380 clientURLs=https://52.43.85.31:2379 isLeader=true
journalctl says the cluster is up and running fine.

Since you have ETCDCTL_API=3 as environment variable, etcdctl member list defaults to v3 member list command. And our current v3 etcdctl commands do not parse environment variable. So you might want to explicitly pass certs flags to etcdctl member list command.

Well, that’s good to know. I’ll try that.
—
Predicting is tough. Especially about the future.--Yogi Berra
We sometimes make too many wrong mistakes.--Yogi Berra
You can observe a lot by watching.--Yogi Berra
The future ain’t what it used to be.--Yogi Berra
Nobody goes there anymore.  It's to crowded--Yogi Berra
On Wed, Nov 30, 2016 at 3:43 PM, Gyu-Ho Lee notifications@github.com
wrote:

Since you have ETCDCTL_API=3 as environment variable, etcdctl member list
defaults to v3 member list command. And our current v3 etcdctl commands
do not parse environment variable. So you might want to explicitly pass
certs flags to etcdctl member list command.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/coreos/etcd/issues/6915#issuecomment-264032907, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ARbCQYvWw0nxmJKk-FXFsrP5xxBe6y-tks5rDgoOgaJpZM4LA0aU
.

@michael-px Sorry, it is supported, but with different flag strings.
See https://github.com/coreos/etcd/issues/6645.
Basically you need
ETCDCTL_CACERT=/tmp/ca.pem
ETCDCTL_CERT=/tmp/cert.pem
ETCDCTL_KEY=/tmp/key.pem

since we have changed the flag strings for v3.

I defined these variables with the correct keys and I still get
Error:  grpc: timed out when dialing
So, this doesn't seem to work.

@michael-px Could you create a separate issue with etcd logs and a way to reproduce?
Works fine on our side.

OK, should I title it something like
API=3 ignores environment variables or something like that?
—
Predicting is tough. Especially about the future.--Yogi Berra
We sometimes make too many wrong mistakes.--Yogi Berra
You can observe a lot by watching.--Yogi Berra
The future ain’t what it used to be.--Yogi Berra
Nobody goes there anymore.  It's to crowded--Yogi Berra
On Thu, Dec 1, 2016 at 5:09 PM, Gyu-Ho Lee notifications@github.com wrote:

@michael-px https://github.com/michael-px Could you create a separate
issue with etcd logs and a way to reproduce?
Works fine on our side.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/coreos/etcd/issues/6915#issuecomment-264344886, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ARbCQYyzPf3DrAsemnOQ6DgkqIwL1-0Zks5rD2-sgaJpZM4LA0aU
.

I think it's a separate issue?
If that doesn't work, it could be TLS configuration issue.
Either way, we need etcd server logs with client errors.
Thanks.

OK, I see the problem with TLS and without TLS, so it most likely is a
separate issue;
—
Predicting is tough. Especially about the future.--Yogi Berra
We sometimes make too many wrong mistakes.--Yogi Berra
You can observe a lot by watching.--Yogi Berra
The future ain’t what it used to be.--Yogi Berra
Nobody goes there anymore.  It's to crowded--Yogi Berra
On Thu, Dec 1, 2016 at 5:15 PM, Gyu-Ho Lee notifications@github.com wrote:

I think it's a separate issue?
If that doesn't work, it could be TLS configuration issue.
Either way, we need etcd server logs with client errors.
Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/coreos/etcd/issues/6915#issuecomment-264345851, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ARbCQXwnv52bz-XqACIIgnyWXC8N2YHXks5rD3EmgaJpZM4LA0aU
.

Error: context deadline exceeded seems like the world's most unhelpful way to say TLS certificate authentication didn't work 🤕

authors: gyuho michael-px whereisaaron


text:
Provide a php client for etcd v3

https://github.com/CatsSystem/swoole-etcd

we do not maintain php client. and we have no plan for it.

@LinkedDestiny please open a PR adding the client to https://github.com/coreos/etcd/blob/master/Documentation/integrations.md under PHP Libraries if you'd like etcd to link to the project. Thanks!

authors: LinkedDestiny heyitsanthony xiang90


text:
e2e: use unix port for release tests

Fix https://github.com/coreos/etcd/issues/5947.
When we restart, the previous port could have been still bind
by the OS. Use Unix port to avoid such rebind cases.

@heyitsanthony All addressed. PTAL.
Thanks!

lgtm from the stop/stopall code duplication. Thanks!

authors: gyuho heyitsanthony


text:
Loading kernel module through unit file?

I'm trying to run pptp on CoreOS inside a Docker container. So far, the file looks like this (it's my first try):
[Unit]
Description=PPTP
After=docker.service
Requires=docker.service
[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill pptp
ExecStartPre=-/usr/bin/docker rm pptp
ExecStartPre=/usr/bin/docker pull olalond3/vpn-pptp
ExecStartPre=/usr/bin/mknod /dev/ppp c 108 0
ExecStart=/bin/bash -c "\
  docker run \
    --name pptp \
    --privileged \
    --env PPTP_USERNAME=$(etcdctl get /pptp_username) \
    --env PPTP_PASSWORD=$(etcdctl get /pptp_password) \
    -p 1723:1723 \
    olalond3/vpn-pptp \
"
ExecStop=/usr/bin/docker stop pptp

When doing fleetctl start pptp, and fleetctl journal -f pptp, I'm getting this error message:
bash[10051]: modprobe: ERROR: ../libkmod/libkmod.c:556 kmod_search_moddep() could not open moddep file '/lib/modules/3.18.1/modules.dep.bin'
bash[10051]: /usr/sbin/pppd: Please load the ppp_generic kernel module.

I assume this means my unit file should probably be loading some kernel module? Is that possible and if so, how?

$ modprobe ppp_generic
modprobe: FATAL: Module ppp_generic not found.

This doesn't appear to work. Any ideas which step I should take now? Do I have to compile ppp_generic module myself and put it in CoreOS through the cloud init file?

This issue was moved to coreos/bugs#313

I have the same issue  :+1:

authors: D-Roch jonboulle olalonde

repo: coreos/fleet


text:
update yaml.v2 to latest commit

Looks like they force-pushed a change to the license, nothing else.

Included in #43

repo: coreos/mayday


text:
oem/ami: make snapshots public

This is needed so that users can copy the public AMIs into their own
accounts.

Fixes https://github.com/coreos/bugs/issues/1090.

repo: coreos/scripts