text:
MNT: rerender

Hi! This is the friendly automated conda-forge-webservice.
I've rerendered the recipe as instructed in #13.
Here's a checklist to do before merging.

[ ] Bump the build number if needed.

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/automake-feedstock


text:
Enable Windows build

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

@conda-forge-admin, please rerender

source: gharchive/pull-request

repo: conda-forge/bmf-feedstock

license_type: permissive

license_source: github-api


text:
wrong version of ncurses

A fresh install of casacore (currently 2.4.1) and python-casacore for python2.7 seems to point to the wrong version of ncurses. The casacore dependency is ncurses>=6.1,<6.2.0a0 but when attempting to import most casacore modules (e.g. casacore.tables), it seems to expect libncursesw.5 and I get the following error:
import casacore.tables
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/anaconda3/envs/casacore/lib/python2.7/site-packages/casacore/tables/__init__.py", line 60, in <module>
    from .msutil import *
  File "/anaconda3/envs/casacore/lib/python2.7/site-packages/casacore/tables/msutil.py", line 29, in <module>
    from casacore.tables.table import table, taql, _required_ms_desc
  File "/anaconda3/envs/casacore/lib/python2.7/site-packages/casacore/tables/table.py", line 43, in <module>
    from ._tables import (Table,
ImportError: dlopen(/anaconda3/envs/casacore/lib/python2.7/site-packages/casacore/tables/_tables.so, 2): Library not loaded: @rpath/libncursesw.5.dylib
  Referenced from: /anaconda3/envs/casacore/lib/libcasa_tables.2.dylib
  Reason: image not found

This was in a fresh environment created with conda create -n casacore -c conda-forge python=2.7 casacore python-casacore.

Environment (conda list):

$ conda list
# packages in environment at /anaconda3/envs/casacore:
#
# Name                    Version                   Build  Channel
boost                     1.67.0           py27h3e44d54_0    conda-forge
boost-cpp                 1.67.0               h3a22d5f_0    conda-forge
bzip2                     1.0.6                         1    conda-forge
ca-certificates           2018.4.16                     0    conda-forge
casacore                  2.4.1            py27he94f398_3    conda-forge
certifi                   2018.4.16                py27_0    conda-forge
cfitsio                   3.430                hd130d23_0    conda-forge
curl                      7.60.0               h93b3f91_0    conda-forge
fftw                      3.3.8                h470a237_0    conda-forge
hdf5                      1.10.2               hc401514_1    conda-forge
icu                       58.2                 hfc679d8_0    conda-forge
intel-openmp              2018.0.3                      0
krb5                      1.14.6                        0    conda-forge
libgfortran               3.0.1                h93005f0_2
libgfortran-ng            3.0.1                h93005f0_2
libpng                    1.6.35               ha92aebf_0    conda-forge
libssh2                   1.8.0                h5b517e9_2    conda-forge
libxcb                    1.13                 h470a237_1    conda-forge
mkl                       2018.0.3                      1
mkl_fft                   1.0.2                    py27_0    conda-forge
mkl_random                1.0.1                    py27_0    conda-forge
ncurses                   6.1                           0    conda-forge
numpy                     1.14.2           py27ha9ae307_1
openblas                  0.2.20                        8    conda-forge
openssl                   1.0.2o                        0    conda-forge
pgplot                    5.2.2                hd376476_3    conda-forge
pip                       9.0.3                    py27_0    conda-forge
pthread-stubs             0.4                  h470a237_1    conda-forge
python                    2.7.15                        0    conda-forge
python-casacore           2.2.1            py27h5c5fb89_1    conda-forge
readline                  7.0                  hc1231fa_4
setuptools                40.0.0                   py27_0    conda-forge
sqlite                    3.20.1                        0    conda-forge
tk                        8.6.7                         0    conda-forge
wcslib                    5.18                          2    conda-forge
wheel                     0.31.1                   py27_0    conda-forge
xorg-kbproto              1.0.7                h470a237_2    conda-forge
xorg-libx11               1.6.5                h470a237_1    conda-forge
xorg-libxau               1.0.8                h470a237_5    conda-forge
xorg-libxdmcp             1.1.2                h470a237_6    conda-forge
xorg-xproto               7.0.31               h470a237_7    conda-forge
xz                        5.2.3                         0    conda-forge
zlib                      1.2.11               h470a237_3    conda-forge

Details about  conda and system ( conda info ):

$ conda info

     active environment : casacore
    active env location : /anaconda3/envs/casacore
            shell level : 2
       user config file : /Users/marxide/.condarc
 populated config files : /Users/marxide/.condarc
          conda version : 4.4.10
    conda-build version : 3.4.1
         python version : 3.6.4.final.0
       base environment : /anaconda3  (writable)
           channel URLs : https://repo.continuum.io/pkgs/main/osx-64
                          https://repo.continuum.io/pkgs/main/noarch
                          https://repo.continuum.io/pkgs/free/osx-64
                          https://repo.continuum.io/pkgs/free/noarch
                          https://repo.continuum.io/pkgs/r/osx-64
                          https://repo.continuum.io/pkgs/r/noarch
                          https://repo.continuum.io/pkgs/pro/osx-64
                          https://repo.continuum.io/pkgs/pro/noarch
          package cache : /anaconda3/pkgs
                          /Users/marxide/.conda/pkgs
       envs directories : /anaconda3/envs
                          /Users/marxide/.conda/envs
               platform : osx-64
             user-agent : conda/4.4.10 requests/2.18.4 CPython/3.6.4 Darwin/16.7.0 OSX/10.12.6
                UID:GID : 26778:286781
             netrc file : None
           offline mode : False

@conda-forge/staged-recipes Tagging since this problem could pop up and cause subtle problems for other cmake-using packages, I think.

Ping @conda-forge/core

You should be able to rerender the recipe to get the latest ncurses pinning.

Does this mean we need to be faster getting packages onto the new pinnings?

@CJ-Wright That would be nice and would help, I think, but there's always going to be some lag time given how the project operates.
I think I have identified a pretty straightforward way to avoid the problem going forward, though. Testing is ongoing.

Ah ok. The bot has some pin-shift-rebuild capabilities but they haven't been put into production yet. I'm trying to gauge need and such so I can do some prioritization.
Attn:
@justcalamari

First-cut workaround PR filed.

OK @marxide, a build should be coming along that fixes this.
BTW, in the CI output for the build behind the most recent deployed version, conda inspect indeed pointed out the libncurses.5.dylib was "not found" ... it was always a bit weird to me that this was not a build-killing error. But I guess we're moving away from conda inspect anyway, right?

Many thanks! Latest build seems to fix this.

source: gharchive/issue

authors: CJ-Wright marxide ocefpaf pkgw scopatz

repo: conda-forge/casacore-feedstock


text:
ENH make old-style CDTs conflict with new sysroot

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.

Here is the diff
Downloading: https://conda.anaconda.org/conda-forge/noarch/repodata_from_packages.json.bz2
Downloading: https://conda.anaconda.org/conda-forge/noarch/repodata.json.bz2
noarch::ca-certificates-cos7-aarch64-2018.2.22-h1341992_2.tar.bz2
-  "version": "2018.2.22"
+  "version": "2018.2.22",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::chkconfig-cos7-aarch64-1.7.4-h1341992_2.tar.bz2
-  "version": "1.7.4"
+  "version": "1.7.4",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::copy-jdk-configs-cos7-aarch64-3.3-h1341992_2.tar.bz2
-  "version": "3.3"
+  "version": "3.3",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::expat-cos7-aarch64-2.1.0-h1341992_0.tar.bz2
-  "version": "2.1.0"
+  "version": "2.1.0",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::expat-devel-cos7-aarch64-2.1.0-h1341992_0.tar.bz2
-  "version": "2.1.0"
+  "version": "2.1.0",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::gconf2-cos7-aarch64-3.2.6-h1341992_2.tar.bz2
-  "version": "3.2.6"
+  "version": "3.2.6",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::gtkmm24-cos7-ppc64le-2.24.5-h1341992_0.tar.bz2
-  "version": "2.24.5"
+  "version": "2.24.5",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::gtkmm24-devel-cos7-ppc64le-2.24.5-h1341992_0.tar.bz2
-  "version": "2.24.5"
+  "version": "2.24.5",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::java-1.7.0-openjdk-cos7-aarch64-1.7.0.221-h1341992_2.tar.bz2
-  "version": "1.7.0.221"
+  "version": "1.7.0.221",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::java-1.7.0-openjdk-headless-cos7-aarch64-1.7.0.221-h1341992_2.tar.bz2
-  "version": "1.7.0.221"
+  "version": "1.7.0.221",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::javapackages-tools-cos7-aarch64-3.4.1-h1341992_2.tar.bz2
-  "version": "3.4.1"
+  "version": "3.4.1",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libdrm-cos7-aarch64-2.4.91-h1341992_0.tar.bz2
-  "version": "2.4.91"
+  "version": "2.4.91",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libdrm-cos7-ppc64le-2.4.97-h1341992_0.tar.bz2
-  "version": "2.4.97"
+  "version": "2.4.97",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libdrm-devel-cos7-aarch64-2.4.91-h1341992_0.tar.bz2
-  "version": "2.4.91"
+  "version": "2.4.91",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libdrm-devel-cos7-ppc64le-2.4.97-h1341992_0.tar.bz2
-  "version": "2.4.97"
+  "version": "2.4.97",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libglvnd-cos7-aarch64-1.0.1-h1341992_0.tar.bz2
-  "version": "1.0.1"
+  "version": "1.0.1",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libglvnd-cos7-ppc64le-1.0.1-h1341992_0.tar.bz2
-  "version": "1.0.1"
+  "version": "1.0.1",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libglvnd-glx-cos7-aarch64-1.0.1-h1341992_0.tar.bz2
-  "version": "1.0.1"
+  "version": "1.0.1",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libglvnd-glx-cos7-ppc64le-1.0.1-h1341992_0.tar.bz2
-  "version": "1.0.1"
+  "version": "1.0.1",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libibcm-cos6-x86_64-1.0.5-h1341992_0.tar.bz2
-  "version": "1.0.5"
+  "version": "1.0.5",
+  "constrains": [
+    "sysroot_linux-64 ==99999999999"
+  ]
noarch::libibcm-devel-cos6-x86_64-1.0.5-h1341992_0.tar.bz2
-  "version": "1.0.5"
+  "version": "1.0.5",
+  "constrains": [
+    "sysroot_linux-64 ==99999999999"
+  ]
noarch::libibverbs-cos6-x86_64-1.1.8-h1341992_0.tar.bz2
-  "version": "1.1.8"
+  "version": "1.1.8",
+  "constrains": [
+    "sysroot_linux-64 ==99999999999"
+  ]
noarch::libibverbs-devel-cos6-x86_64-1.1.8-h1341992_0.tar.bz2
-  "version": "1.1.8"
+  "version": "1.1.8",
+  "constrains": [
+    "sysroot_linux-64 ==99999999999"
+  ]
noarch::libice-cos7-aarch64-1.0.9-h1341992_0.tar.bz2
-  "version": "1.0.9"
+  "version": "1.0.9",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libice-cos7-ppc64le-1.0.9-h1341992_0.tar.bz2
-  "version": "1.0.9"
+  "version": "1.0.9",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libice-cos7-ppc64le-1.0.9-h1341992_1.tar.bz2
-  "version": "1.0.9"
+  "version": "1.0.9",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libice-devel-cos7-aarch64-1.0.9-h1341992_0.tar.bz2
-  "version": "1.0.9"
+  "version": "1.0.9",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libice-devel-cos7-ppc64le-1.0.9-h1341992_0.tar.bz2
-  "version": "1.0.9"
+  "version": "1.0.9",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libice-devel-cos7-ppc64le-1.0.9-h1341992_1.tar.bz2
-  "version": "1.0.9"
+  "version": "1.0.9",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libjpeg-turbo-cos7-aarch64-1.2.90-h1341992_2.tar.bz2
-  "version": "1.2.90"
+  "version": "1.2.90",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libnl-cos6-x86_64-1.1.4-0.tar.bz2
-  "version": "1.1.4"
+  "version": "1.1.4",
+  "constrains": [
+    "sysroot_linux-64 ==99999999999"
+  ]
noarch::libnl-cos6-x86_64-1.1.4-1.tar.bz2
-  "version": "1.1.4"
+  "version": "1.1.4",
+  "constrains": [
+    "sysroot_linux-64 ==99999999999"
+  ]
noarch::libnl-devel-cos6-x86_64-1.1.4-h1341992_0.tar.bz2
-  "version": "1.1.4"
+  "version": "1.1.4",
+  "constrains": [
+    "sysroot_linux-64 ==99999999999"
+  ]
noarch::librdmacm-cos6-x86_64-1.0.21-h1341992_0.tar.bz2
-  "version": "1.0.21"
+  "version": "1.0.21",
+  "constrains": [
+    "sysroot_linux-64 ==99999999999"
+  ]
noarch::librdmacm-devel-cos6-x86_64-1.0.21-h1341992_0.tar.bz2
-  "version": "1.0.21"
+  "version": "1.0.21",
+  "constrains": [
+    "sysroot_linux-64 ==99999999999"
+  ]
noarch::libselinux-cos7-aarch64-2.5-h1341992_0.tar.bz2
-  "version": "2.5"
+  "version": "2.5",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libselinux-devel-cos7-aarch64-2.5-h1341992_0.tar.bz2
-  "version": "2.5"
+  "version": "2.5",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libsm-cos7-aarch64-1.2.2-h1341992_0.tar.bz2
-  "version": "1.2.2"
+  "version": "1.2.2",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libsm-cos7-ppc64le-1.2.2-h1341992_0.tar.bz2
-  "version": "1.2.2"
+  "version": "1.2.2",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libsm-cos7-ppc64le-1.2.2-h1341992_1.tar.bz2
-  "version": "1.2.2"
+  "version": "1.2.2",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libsm-devel-cos7-aarch64-1.2.2-h1341992_0.tar.bz2
-  "version": "1.2.2"
+  "version": "1.2.2",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libsm-devel-cos7-ppc64le-1.2.2-h1341992_0.tar.bz2
-  "version": "1.2.2"
+  "version": "1.2.2",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libsm-devel-cos7-ppc64le-1.2.2-h1341992_1.tar.bz2
-  "version": "1.2.2"
+  "version": "1.2.2",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libudev-cos6-x86_64-147-h1341992_0.tar.bz2
-  "version": "147"
+  "version": "147",
+  "constrains": [
+    "sysroot_linux-64 ==99999999999"
+  ]
noarch::libudev-devel-cos6-x86_64-147-h1341992_0.tar.bz2
-  "version": "147"
+  "version": "147",
+  "constrains": [
+    "sysroot_linux-64 ==99999999999"
+  ]
noarch::libx11-common-cos7-aarch64-1.6.7-h1341992_0.tar.bz2
-  "version": "1.6.7"
+  "version": "1.6.7",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libx11-cos7-aarch64-1.6.7-h1341992_0.tar.bz2
-  "version": "1.6.7"
+  "version": "1.6.7",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libx11-devel-cos7-aarch64-1.6.7-h1341992_0.tar.bz2
-  "version": "1.6.7"
+  "version": "1.6.7",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libxau-cos7-aarch64-1.0.8-h1341992_0.tar.bz2
-  "version": "1.0.8"
+  "version": "1.0.8",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libxau-devel-cos7-aarch64-1.0.8-h1341992_0.tar.bz2
-  "version": "1.0.8"
+  "version": "1.0.8",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libxcb-cos7-aarch64-1.13-h1341992_0.tar.bz2
-  "version": "1.13"
+  "version": "1.13",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libxcomposite-cos7-ppc64le-0.4.4-h1341992_0.tar.bz2
-  "version": "0.4.4"
+  "version": "0.4.4",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libxcomposite-devel-cos7-ppc64le-0.4.4-h1341992_0.tar.bz2
-  "version": "0.4.4"
+  "version": "0.4.4",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libxcursor-cos7-ppc64le-1.1.15-h1341992_0.tar.bz2
-  "version": "1.1.15"
+  "version": "1.1.15",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libxcursor-devel-cos7-ppc64le-1.1.15-h1341992_0.tar.bz2
-  "version": "1.1.15"
+  "version": "1.1.15",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libxdamage-cos7-aarch64-1.1.4-h1341992_0.tar.bz2
-  "version": "1.1.4"
+  "version": "1.1.4",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libxdamage-devel-cos7-aarch64-1.1.4-h1341992_0.tar.bz2
-  "version": "1.1.4"
+  "version": "1.1.4",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libxext-cos7-aarch64-1.3.3-h1341992_0.tar.bz2
-  "version": "1.3.3"
+  "version": "1.3.3",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libxext-devel-cos7-aarch64-1.3.3-h1341992_0.tar.bz2
-  "version": "1.3.3"
+  "version": "1.3.3",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libxfixes-cos7-aarch64-5.0.3-h1341992_0.tar.bz2
-  "version": "5.0.3"
+  "version": "5.0.3",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libxfixes-devel-cos7-aarch64-5.0.3-h1341992_0.tar.bz2
-  "version": "5.0.3"
+  "version": "5.0.3",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libxrender-cos7-aarch64-0.9.10-h1341992_0.tar.bz2
-  "version": "0.9.10"
+  "version": "0.9.10",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libxrender-devel-cos7-aarch64-0.9.10-h1341992_0.tar.bz2
-  "version": "0.9.10"
+  "version": "0.9.10",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libxscrnsaver-cos7-ppc64le-1.2.2-h1341992_0.tar.bz2
-  "version": "1.2.2"
+  "version": "1.2.2",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libxscrnsaver-devel-cos7-ppc64le-1.2.2-h1341992_0.tar.bz2
-  "version": "1.2.2"
+  "version": "1.2.2",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libxshmfence-cos7-aarch64-1.2-h1341992_0.tar.bz2
-  "version": "1.2"
+  "version": "1.2",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libxshmfence-cos7-ppc64le-1.2-h1341992_0.tar.bz2
-  "version": "1.2"
+  "version": "1.2",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libxshmfence-devel-cos7-aarch64-1.2-h1341992_0.tar.bz2
-  "version": "1.2"
+  "version": "1.2",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libxshmfence-devel-cos7-ppc64le-1.2-h1341992_0.tar.bz2
-  "version": "1.2"
+  "version": "1.2",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libxt-cos7-aarch64-1.1.5-h1341992_0.tar.bz2
-  "version": "1.1.5"
+  "version": "1.1.5",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libxt-cos7-ppc64le-1.1.5-h1341992_0.tar.bz2
-  "version": "1.1.5"
+  "version": "1.1.5",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libxt-cos7-ppc64le-1.1.5-h1341992_1.tar.bz2
-  "version": "1.1.5"
+  "version": "1.1.5",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libxt-devel-cos7-aarch64-1.1.5-h1341992_0.tar.bz2
-  "version": "1.1.5"
+  "version": "1.1.5",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libxt-devel-cos7-ppc64le-1.1.5-h1341992_0.tar.bz2
-  "version": "1.1.5"
+  "version": "1.1.5",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libxt-devel-cos7-ppc64le-1.1.5-h1341992_1.tar.bz2
-  "version": "1.1.5"
+  "version": "1.1.5",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libxtst-cos7-ppc64le-1.2.3-h1341992_0.tar.bz2
-  "version": "1.2.3"
+  "version": "1.2.3",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libxtst-devel-cos7-ppc64le-1.2.3-h1341992_0.tar.bz2
-  "version": "1.2.3"
+  "version": "1.2.3",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libxxf86vm-cos7-aarch64-1.1.4-h1341992_0.tar.bz2
-  "version": "1.1.4"
+  "version": "1.1.4",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libxxf86vm-cos7-ppc64le-1.1.4-h1341992_0.tar.bz2
-  "version": "1.1.4"
+  "version": "1.1.4",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::libxxf86vm-devel-cos7-aarch64-1.1.4-h1341992_0.tar.bz2
-  "version": "1.1.4"
+  "version": "1.1.4",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::libxxf86vm-devel-cos7-ppc64le-1.1.4-h1341992_0.tar.bz2
-  "version": "1.1.4"
+  "version": "1.1.4",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::mesa-dri-drivers-cos7-aarch64-18.0.5-h1341992_0.tar.bz2
-  "version": "18.0.5"
+  "version": "18.0.5",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::mesa-khr-devel-cos7-aarch64-18.3.4-h1341992_0.tar.bz2
-  "version": "18.3.4"
+  "version": "18.3.4",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::mesa-khr-devel-cos7-ppc64le-18.3.4-h1341992_0.tar.bz2
-  "version": "18.3.4"
+  "version": "18.3.4",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::mesa-libegl-cos7-aarch64-18.3.4-h1341992_0.tar.bz2
-  "version": "18.3.4"
+  "version": "18.3.4",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::mesa-libegl-cos7-ppc64le-18.3.4-h1341992_0.tar.bz2
-  "version": "18.3.4"
+  "version": "18.3.4",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::mesa-libegl-devel-cos7-aarch64-18.3.4-h1341992_0.tar.bz2
-  "version": "18.3.4"
+  "version": "18.3.4",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::mesa-libegl-devel-cos7-ppc64le-18.3.4-h1341992_0.tar.bz2
-  "version": "18.3.4"
+  "version": "18.3.4",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::mesa-libgl-cos7-aarch64-18.0.5-h1341992_0.tar.bz2
-  "version": "18.0.5"
+  "version": "18.0.5",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::mesa-libgl-cos7-ppc64le-18.3.4-h1341992_0.tar.bz2
-  "version": "18.3.4"
+  "version": "18.3.4",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::mesa-libgl-devel-cos7-aarch64-18.0.5-h1341992_0.tar.bz2
-  "version": "18.0.5"
+  "version": "18.0.5",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::mesa-libgl-devel-cos7-ppc64le-18.3.4-h1341992_0.tar.bz2
-  "version": "18.3.4"
+  "version": "18.3.4",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::mesa-libglapi-cos7-aarch64-18.0.5-h1341992_0.tar.bz2
-  "version": "18.0.5"
+  "version": "18.0.5",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::mesa-libglapi-cos7-ppc64le-18.3.4-h1341992_0.tar.bz2
-  "version": "18.3.4"
+  "version": "18.3.4",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::nspr-cos7-aarch64-4.21.0-h1341992_2.tar.bz2
-  "version": "4.21.0"
+  "version": "4.21.0",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::nss-cos7-aarch64-3.44.0-h1341992_2.tar.bz2
-  "version": "3.44.0"
+  "version": "3.44.0",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::nss-softokn-cos7-aarch64-3.44.0-h1341992_2.tar.bz2
-  "version": "3.44.0"
+  "version": "3.44.0",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::nss-softokn-freebl-cos7-aarch64-3.44.0-h1341992_2.tar.bz2
-  "version": "3.44.0"
+  "version": "3.44.0",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::nss-util-cos7-aarch64-3.44.0-h1341992_2.tar.bz2
-  "version": "3.44.0"
+  "version": "3.44.0",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::numactl-cos6-x86_64-2.0.9-h1341992_0.tar.bz2
-  "version": "2.0.9"
+  "version": "2.0.9",
+  "constrains": [
+    "sysroot_linux-64 ==99999999999"
+  ]
noarch::numactl-devel-cos6-x86_64-2.0.9-h1341992_0.tar.bz2
-  "version": "2.0.9"
+  "version": "2.0.9",
+  "constrains": [
+    "sysroot_linux-64 ==99999999999"
+  ]
noarch::orbit2-cos7-aarch64-2.14.19-h1341992_2.tar.bz2
-  "version": "2.14.19"
+  "version": "2.14.19",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::p11-kit-cos7-aarch64-0.23.5-h1341992_2.tar.bz2
-  "version": "0.23.5"
+  "version": "0.23.5",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::p11-kit-trust-cos7-aarch64-0.23.5-h1341992_2.tar.bz2
-  "version": "0.23.5"
+  "version": "0.23.5",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::pciutils-devel-cos7-ppc64le-3.5.1-h1341992_0.tar.bz2
-  "version": "3.5.1"
+  "version": "3.5.1",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::pciutils-libs-cos7-ppc64le-3.5.1-h1341992_0.tar.bz2
-  "version": "3.5.1"
+  "version": "3.5.1",
+  "constrains": [
+    "sysroot_linux-ppc64le ==99999999999"
+  ]
noarch::python-javapackages-cos7-aarch64-3.4.1-h1341992_2.tar.bz2
-  "version": "3.4.1"
+  "version": "3.4.1",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
noarch::xorg-x11-proto-devel-cos7-aarch64-2018.4-h1341992_0.tar.bz2
-  "version": "2018.4"
+  "version": "2018.4",
+  "constrains": [
+    "sysroot_linux-aarch64 ==99999999999"
+  ]
Downloading: https://conda.anaconda.org/conda-forge/linux-64/repodata_from_packages.json.bz2
Downloading: https://conda.anaconda.org/conda-forge/linux-64/repodata.json.bz2
linux-64::mlflow-ui-dbg-1.9.1-0.tar.bz2
-  "version": "1.9.1"
+  "version": "1.9.1",
+  "constrains": []
Downloading: https://conda.anaconda.org/conda-forge/linux-armv7l/repodata_from_packages.json.bz2
Downloading: https://conda.anaconda.org/conda-forge/linux-armv7l/repodata.json.bz2
Downloading: https://conda.anaconda.org/conda-forge/linux-aarch64/repodata_from_packages.json.bz2
Downloading: https://conda.anaconda.org/conda-forge/linux-aarch64/repodata.json.bz2
linux-aarch64::mlflow-ui-dbg-1.9.1-0.tar.bz2
-  "version": "1.9.1"
+  "version": "1.9.1",
+  "constrains": []
Downloading: https://conda.anaconda.org/conda-forge/linux-ppc64le/repodata_from_packages.json.bz2
Downloading: https://conda.anaconda.org/conda-forge/linux-ppc64le/repodata.json.bz2
linux-ppc64le::mlflow-ui-dbg-1.9.1-0.tar.bz2
-  "version": "1.9.1"
+  "version": "1.9.1",
+  "constrains": []
Downloading: https://conda.anaconda.org/conda-forge/osx-64/repodata_from_packages.json.bz2
Downloading: https://conda.anaconda.org/conda-forge/osx-64/repodata.json.bz2
osx-64::mlflow-ui-dbg-1.9.1-0.tar.bz2
-  "version": "1.9.1"
+  "version": "1.9.1",
+  "constrains": []
Downloading: https://conda.anaconda.org/conda-forge/win-32/repodata_from_packages.json.bz2
Downloading: https://conda.anaconda.org/conda-forge/win-32/repodata.json.bz2
Downloading: https://conda.anaconda.org/conda-forge/win-64/repodata_from_packages.json.bz2
Downloading: https://conda.anaconda.org/conda-forge/win-64/repodata.json.bz2
win-64::mlflow-ui-dbg-1.9.1-0.tar.bz2
-  "version": "1.9.1"
+  "version": "1.9.1",
+  "constrains": []

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 rerender

@conda-forge/core @isuruf this is ready for review!

authors: beckermr conda-forge-linter


text:
Bump version to 0.4.5

Checklist

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

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

@conda-forge-admin, please rerender

authors: conda-forge-linter costrouc

repo: conda-forge/conda-store-feedstock


text:
Bump to faim-ipa-0.6.1

Checklist

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


text:
Updated to v0.16.4

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 giswqs

repo: conda-forge/geemap-feedstock


text:
Pin package version numbers

Checklist

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

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

@conda-forge-admin, please rerender

repo: conda-forge/geospatial-feedstock


text:
[ci skip] NO_CI add fcollonval as maintainer

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)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-linting service.
I 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:

noarch: python recipes are required to have a lower bound on the python version. Typically this means putting python >=3.6 in both host and run but you should check upstream for the package's Python compatibility.

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 fcollonval


text:
Add run_constrained

Checklist

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

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

authors: conda-forge-linter duncanmmacleod

repo: conda-forge/lalsimulation-feedstock


text:
test CUDA

Checklist

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

I'm concerned that CUDA isn't actually being activated and that #58 passing isn't testing what we think. This tries to activate more explicitly to serve as comparison. linux-64 only for CUDA.

The problem seems to be that the operational check fails when cuda is enabled Segmentation fault      (core dumped) xc-info 100 . https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=795193&view=logs&j=4f922444-fdfe-5dcf-b824-02f86439ef14&t=937c195f-508d-5135-dc9f-d4b5730df0f7&l=2671

@awvwgk , would you mind confirming what worked at time of your initial CUDA addition? Did xc-info 100 work then? We merged the C/Fortran/Py split the CUDA PRs so near that I suspect something got lost, especially ENABLE_CUDA=ON.

@awvwgk , would you have a moment to follow up here? We would appreciate hearing your insights 🙂

I did run the build of the recipe locally on a GPU enabled machine. I can check whether I still have the artifact to check again, but as far as I remember it was working as intended.

@conda-forge-admin , please re-render

CI logs had expired. So tried to rerun, but it looks like there are conflicts
A question about the test. Is this trying to use a GPU as part of the test? If so, there are not GPUs to test with on CI. So it may be expected that it doesn't work
We could configure CI to cache a package from the PR so it could be downloaded for testing (though we might need to disable the problematic test to get far enough in the CI build to create a package). Maybe then someone can explore whether that package works as expected on a system with a GPU (or share what issues they uncover)

@conda-forge-admin , please re-render

A question about the test. Is this trying to use a GPU as part of the test? If so, there are not GPUs to test with on CI. So it may be expected that it doesn't work

The offending line was xc-info 100. That's printing a few lines of stored text, so no intended GPU involvement. But xc-info is a compiled executable that might have GPU libs linked in, so maybe it should be an xfail.

We could configure CI to cache a package from the PR so it could be downloaded for testing (though we might need to disable the problematic test to get far enough in the CI build to create a package). Maybe then someone can explore whether that package works as expected on a system with a GPU (or share what issues they uncover)

Good notion. I've disabled the xc-info for the gpu-build and asked it to save artifacts. I may need to disable more pylibxc stuff to get a passing build. Unfortunately I don't have a local GPU box for trial.

@awvwgk could you please help us test out the binaries here?
Here are some relevant docs on using CI artifacts locally
Some examples with screenshots in issue: https://github.com/conda-forge/conda-forge.github.io/issues/1424

@njzjz , as abacus is a downstream user of libxc, am wondering if you would be willing to help us test the CI package artifacts

@njzjz , as abacus is a downstream user of libxc, am wondering if you would be willing to help us test the CI package artifacts

OK, I will take a test.
cc @caic99

Hi @loriab ,
I tested the libxc cuda build (hc895d526af) with ABACUS. Unfortunately, it produces an error:
error: output variable, out->v2rhotau, is a null pointer
The default recipe of ABACUS uses conda-forge::libxc-c-6.2.2-cuda_h60e1ed8_2. Is that version GPU accelerated? Do we need to adapt codes for the new package?
Test case used

I read libxc documentation, and I'm afraid that abacus doesn't support libxc cuda. It says

When running with libxc compiled with Cuda, both the input and output arrays must always be allocated on the GPU (or using unified memory). Libxc will fail (most likely you will get a segmentation fault) if a CPU array is passed.

@caic99 So we may need to force the libxc CPU version before abacus really supports it. If the previous libxc cuda package works, it may not actually be compiled with cuda.

Thank you for testing, @caic99 . I can't look at details for the next few days, I'm afraid (conference).
The libxc-c-6.2.2-cuda_h60e1ed8_2 you're using by default nominally should be GPU accelerated. The kerfluffle of this test PR is that it seems likely that the libxc-c-*-cuda packages currently on c-f aren't actually conda enabled (not the libxc+cuda+recipe author's fault -- there was a lot of recipe changes around then).

Thanks Jinzhe and Chun! 🙏
Really appreciate the help testing 🙂

Edit: Are either of you able to run xc-info 100 with the package?

@jakirkham It works
xc-info 100
libxc version 6.2.2
S. Lehtola, C. Steigemann, M. J.T. Oliveira, and M. A.L. Marques.,  SoftwareX 7, 1–5 (2018)
doi: 10.1016/j.softx.2017.11.002

   func_id: 100
      name: gga_c_tca
    family: XC_FAMILY_GGA
      kind: XC_CORRELATION
   comment: Tognetti, Cortona, Adamo

Reference(s):
  *) V. Tognetti, P. Cortona, and C. Adamo.,  J. Chem. Phys. 128, 034101 (2008)
     doi: 10.1063/1.2816137
     bibtex key: Tognetti2008_034101

Implementation has support for:
  *) energy
  *) first derivative
  *) second derivative

Default thresholds:
density: 1.000000e-14
   zeta: 2.220446e-16
  sigma: 2.154435e-19

Functional has no external parameters.

Thanks Chun! 🙏

Going back to question about libraries linked into xc-info, there is some info in the CI log
Looking at the results there don't appear to be any dynamic CUDA libraries linked. However there could be static CUDA libraries that are linked in. This is important to note as cudart is statically linked by default (NVCC and CMake default)
+ ldd -v $PREFIX/bin/xc-info
	linux-vdso.so.1 =>  (0x00007ffd8f7f7000)
	libxc.so.12 => $PREFIX/bin/../lib/libxc.so.12 (0x00007f3c1d600000)
	librt.so.1 => /lib64/librt.so.1 (0x00007f3c1d3f8000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3c1d1dc000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f3c1cfd8000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f3c1cc0a000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f3c2b2e9000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f3c1c908000)

Do we need to adapt codes for the new package?

Libxc docs said

When running with libxc compiled with Cuda, both the input and output arrays must always be allocated on the GPU (or using unified memory).
Libxc will fail (most likely you will get a segmentation fault) if a CPU array is passed.

Does it mean ABACUS should change the array allocation to GPU if CUDA-supported Libxc is used? If so, how to determine if the Libxc provided is CUDA-supported on runtime/compile time?

^ Am guessing this is a question for @njzjz

@caic99, I submitted https://github.com/conda-forge/abacus-feedstock/pull/20 since we should use the CPU version of libxc for the current codes. For the GPU interface, perhaps we should create a new issue in the abacus repository.

@loriab , hope the conference well
Not sure if you saw, but it looks like testing libxc with CUDA works
Think the segfault is just due to lack of a working GPU. So maybe skipping the tests when building for CUDA is appropriate

@conda-forge-admin, please rerender

Not sure if you saw, but it looks like testing libxc with CUDA https://github.com/conda-forge/libxc-feedstock/pull/59#issuecomment-1844815261

Think the segfault is just due to lack of a working GPU. So maybe skipping the tests when building for CUDA is appropriate

thanks, @jakirkham and testers. I've set this PR up to be mergeable and will see if @jan-janssen wants to look it over; otherwise will merge tomorrow. Then, I suppose, back to #58.

Thanks everyone! 🙏

authors: awvwgk caic99 jakirkham loriab njzjz

repo: conda-forge/libxc-feedstock


text:
Add auto merge

@conda-forge-admin, please add bot automerge

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I added bot automerge in conda-forge/molsimplify-feedstock#2.

authors: conda-forge-linter jan-janssen

repo: conda-forge/molsimplify-feedstock


text:
add pip check, use more traditional version selector

Checklist

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

In trying to set up a [development environment](https://github.com/conda-forge/staged-recipes/pull/12516#issuecomment-774761464 for jupyter-book), I've run into issues with the dependency that uses the tilde operator. this uses the more explicit >=x,<x+1 form.
Also adds pip check, given the number of deps we're dealing with here.
Since I'm not super in need of this package until jupyter-book is available, i haven't added myself as a maintainer, but would be happy to do so at that time!

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

@bollwyvl I'm not really sure whether this is ready to be merged or not...I don't think that we have the reviewer bandwidth to keep up with these conda-forge versions as well. Also I don't have write access to this repository so I'm not sure I can do anything myself

Also I don't have write access to this repository so I'm not sure I can do anything myself

I'll take a look at re-syncing the deps on #10, and will add the @conda-forge/jupyter-book team...

bandwidth to keep up with these conda-forge versions

Right, that's the goal of having teams (rather than individuals) to spread the tasks more broadly, and trying to adopt reasonable practices so that it's just "click the button," or "report bug we find by actually testing things as people might want to install them,"

Hi! This is the friendly automated conda-forge-linting service.
I was trying to look for recipes to lint for you, but it appears we have a merge conflict.
Please try to merge or rebase with the base branch to resolve this conflict.
Please ping the 'conda-forge/core' team (using the @ notation in a comment) if you believe this is a bug.

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:

Failed to even lint the recipe, probably because of a conda-smithy bug :cry:. This likely indicates a problem in your meta.yaml, though. To get a traceback to help figure out what's going on, install conda-smithy and run conda smithy recipe-lint . from the recipe directory.

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.

@bollwyvl I certainly agree with that goal! I think the challenge that I have is that, because I don't understand how the conda forge infrastructure works, it is unclear to me whether things are actually as simple as just clicking the button or not haha.

Hey all - I appreciate this discussion around conventions for how to handle dependency specifications for conda-forge recipes, and I appreciate the interest that folks have in ensuring compatibility across the broader conda forge ecosystem.
It sounds like there are reasonable cases to be made on both sides here, and I don't think that there is a single obviously right answer. That being said, I also don't think that this PR is the right place to decide when to change team conventions within executablebooks/ stuff. If there's a strong reason for one convention or another, this should be decided at the project level within the practices that we follow, rather than on an ad-hoc basis in one PR. Otherwise I fear that the standards we follow will start to organically diverge, and it will make the ecosystem harder to keep track of and follow.

I don't think anyone is asking to change anything about EBP or any of it's projects. This is a conda-forge project we are communicating on. Seems to me that conda-forge principles and patterns are what govern these repositories. I'm bowing out at this point, as there doesn't seem to be much room for consensus making. Have a great weekend!
P.S. @bollwyvl I was seemingly added to the conda forge jupyter-book team. How do I go about getting off that? As I'd like to stop getting notifications about these recipes.

I think this is a challenging aspect of Conda Forge. On the one hand, yes it is in a different organization. On the other hand, as maintainers of the upstream EBP projects we feel an obligation to participate in this space in order to keep the packages up to date.
Realistically it is people following EPB community practices that will be coming here to maintain things. If conda forge recipes go out of date or don't work properly, people are going to come to the EBP repositories to ask for changes, updates, etc. It's not as easy as saying that different practices should be followed just because the repository is in a different GitHub org.
My assumption was that conda forge recipes respect the community practices of the projects that are hosted here. Is that wrong?

thanks for all these points everyone. I have opened a discussion thread for consideration of these points: https://github.com/executablebooks/meta/discussions/481

authors: bollwyvl choldgraf conda-forge-linter mmcky moorepants

repo: conda-forge/myst-nb-feedstock


text:
update 20240122

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/parallel-feedstock


text:
Version on anaconda.org behind this repo

At https://anaconda.org/conda-forge/platformdirs, the current version is v2.3.0 (uploaded 5 months ago), but the version in the recipe in this repo is v2.4.1
I'm not sure how the packages are built and uploaded but I guess something has gone wrong somewhere.

Thank you very much for reporting this. I am not sure what happened, but I will try forcing a rebuild and hopefully that fixes the issue.

That seemed to do it.

authors: adament domdfcoding

repo: conda-forge/platformdirs-feedstock


text:
4.4

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.

Closes #60

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.

Thanks! This supersedes #60 then. 👍

I had reported the incosistent line ending issue upstream, but it never got fixed.

repo: conda-forge/pyinstaller-feedstock


text:
Constraints declared in the recipe do not correspond to constraints found in index.json of main conda channel.

Conda package in question
https://anaconda.org/main/pyjwt/2.1.0/download/win-64/pyjwt-2.1.0-py36haa95532_0.tar.bz2
Issue
meta.yaml inside the said tarball declares cryptography >=2.6,<3.0.0
index.json in conda main channel declares cryptography >=3.3.1,<4.0.0
$ conda search pyjwt=2.1.0=py39haa95532_0 --info
Loading channels: done
pyjwt 2.1.0 py39haa95532_0
--------------------------
file name   : pyjwt-2.1.0-py39haa95532_0.conda
name        : pyjwt
version     : 2.1.0
build       : py39haa95532_0
build number: 0
size        : 32 KB
license     : MIT
subdir      : win-64
url         : https://repo.anaconda.com/pkgs/main/win-64/pyjwt-2.1.0-py39haa95532_0.conda
md5         : e754d2b9054fbc45bb0260c17af3d626
timestamp   : 2021-04-29 07:52:48 UTC
constraints :
  - cryptography >=3.3.1,<4.0.0
dependencies:
  - python >=3.9,<3.10.0a0

The contemporary constraints in the upstream repo had the upper-bound removed on October 18, 2021:
https://github.com/jpadilla/pyjwt/commit/19ce9c5ec7947428d35aaffd302eb2629210a697#diff-fa602a8a75dc9dcc92261bac5f533c2a85e34fcceaff63b3a3a81d9acde2fc52
The impact of this here is that now we are stuck not upgrading either pyjwt or cryptography.
~❯❯❯ conda update --name default --all --yes
Collecting package metadata (current_repodata.json): done
Solving environment: |
Warning: 2 possible package resolutions (only showing differing packages):
  - conda-forge/noarch::pyjwt-2.3.0-pyhd8ed1ab_0, conda-forge/osx-64::cryptography-35.0.0-py39h209aa08_2
  - conda-forge/noarch::pyjwt-1.7.1-py_0, conda-forge/osx-64::cryptography-36.0.0-py39h209aa08done

I believe that it makes sense to remove the upper bound here, too.

repo: conda-forge/pyjwt-feedstock


text:
version 0.16.2

Checklist

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

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

@conda-forge-admin, please rerender

authors: conda-forge-linter johntruckenbrodt

repo: conda-forge/pyrosar-feedstock


text:
[ci skip] adding user @CSSFrancis

Hi! This is the friendly automated conda-forge-webservice.
I've added user @CSSFrancis as instructed in #27.
Merge this PR to add the user. Please do not rerender this PR or change it in any way. It has [ci skip] in the commit message to avoid pushing a new build and so the build configuration in the feedstock should not be changed.
Please contact conda-forge/core to have this PR merged, if the maintainer is unresponsive.
Fixes #27

doing this simul made more problems than it solved. closing and redoing.

repo: conda-forge/pyxem-feedstock


text:
@conda-forge-admin, please rerender

@conda-forge-admin, please rerender

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

authors: conda-forge-linter dbast

repo: conda-forge/r-class-feedstock


text:
Fix lockfile error

rebuild with libmamba 0.13
bump build number

Checklist

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

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

authors: adriendelsalle conda-forge-linter

repo: conda-forge/rhumba-feedstock


text:
Corrected dependencies.

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] 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)
[x] Ensured the license file is being packaged.

Corrected dependencies per the recommendations of the Dependency Analysis.

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 paulsaxe

repo: conda-forge/seamm-feedstock


text:
Move to Azure for Windows

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

license_file entry is missing, but is required.

#31 includes moving to Azure for Windows.

Closing in favor of #31.

authors: chrisdembia conda-forge-linter moorepants xhochy

repo: conda-forge/simbody-feedstock


text:
Use MSVC as the windows compiler

Checklist

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

windows ci taking >3h reminds me a bit of https://github.com/conda/conda-build/issues/5126...

unfortunately there are still some kinks for rattler-build in conda-forge ci when cross-compiling that we would need to resolve first before migrating :/ https://github.com/conda-forge/pyright-feedstock/pull/179

authors: pavelzw xhochy

repo: conda-forge/typos-feedstock


text:
Your pinning does not match what's currently installed

Hi there.
I install the package as follows:
!pip install -q condacolab
import condacolab
condacolab.install()

The runtime restarts. When I try to install packages, e.g. using
!mamba install -c conda-forge -c intel -c astra-toolbox -c ccpi cil numpy astra-toolbox --quiet

I get the error as follows:
Your pinning does not match what's currently installed. Please remove the pin and fix your installation
  Pin: python=3.9
  Currently installed: conda-forge/linux-64::python==3.8.15=h4a9ceb5_0_cpython

Note that I did not have the issue yesterday. Yesterday I believe Google Collaborative worked with Python 3.8. It somehow has changed.
Regards,

This is due to colab now using python 3.9; they've rolled out a new version yesterday evening
https://github.com/googlecolab/colabtools/issues/3450
Current workaround includes;

Connecting to a runtime without running conda-colab installation (click on reconnect kernal status)

Opening the command palette

Using fallback runtime

From the earlier colab issue, this will only work for the next few weeks

Hi, thanks for the report!
Can you try with this hotfix? If it works I'll cut a new 0.1.x release:
!pip install -q https://github.com/conda-incubator/condacolab/archive/py39.tar.gz
import condacolab
condacolab.install()

Hi @jaimergp
it works like a charm (see. Please let me know when you deploy the solution. And a big thank for this wonderful project. It's so useful!

0.1.6 is now out!

https://github.com/conda-incubator/condacolab/releases/tag/v0.1.6
https://pypi.org/project/condacolab/

authors: WYVERN2742 effepivi jaimergp

repo: conda-incubator/condacolab

license: MIT


text:
Override environment.yaml name

Is there a way to override the name of the environment created from an environment.yaml file (a.k.a. the --name flag)?
BTW, thanks for your work, it saved me a lot fo time!

Hi @JulioV, thanks for your suggestion and your kind words :)

Is there a way to override the name of the environment created from an environment.yaml file (a.k.a. the --name flag)?

Well could you describe a bit more what you are trying to accomplish?

Our conda environment is named like this projectYYYYMM, so every time the name attributes changes in our environment.yaml file I need to change activate-environment in your action. Is there a way to pass an environment name to your action, so that it does not have to match the name attribute in the file?

Is there a way to pass an environment name to your action, so that it does not have to match the name attribute in the file?

test-environment serves this purpose, but I think they need to be the same, or it needs to be missing from he env yaml, so I don't think we support you use case at the moment.

Oh OK, can I transform this issue into a future request? :)

You could patch the environment.yml file in a previous step with sed and friends. Ugly but would work for now :)

@jaimergp, thanks, that's what I thought. For anyone seeing this in the future I did   sed -i "" "s/name:.*/name:my_new_name/g" environment.yml

So do you want your environment to get created with the name:

test
projectyyymmdd
or some other name specified in your file (other than base or root)

More broadly: what should the order of preference be (not your preference for this use case, but least surprising for the most people? Practically, I think over on #127 i'm at a place where I can fix this, if it hasn't already done so.
My spitballing hierarchy, from most- to least-explicit:

no name in env, name in workflow:  whatever was in workflow (if not base or root)
name in env, name in workflow: whatever was in workflow (if not base or root)
name in env, no name in workflow: ????

i think it's test right now, and not sure if anybody likes that, but also don't know if we can change it, now

no name in env, no name in workflow: test

Some thoughts for the future:

explicit envs already don't have a name, so there's nothing to fall back on
if multiple env files are supported, what then?

Concretely from #127: the YAML installer (in env/yaml.ts) doesn't even look at the name specified in the enviroment file... but it could, if we agree on that logic above. Though likely, we should just resolve it on a separate PR, adding new tests, etc.

Hi @bollwyvl, let's keep the effort of fixing other bugs separate from the refactoring work :)

As of master, this is probably fixed:
https://github.com/conda-incubator/setup-miniconda/blob/master/src/env/yaml.ts#L122

Thanks @bollwyvl closing for now

authors: JulioV bollwyvl goanpeca jaimergp

repo: conda-incubator/setup-miniconda


text:
CEP: Recipe serialization in packages

Rendered version: ✏ https://github.com/wolfv/ceps/blob/cep-recipe-serialization/cep-recipe-serialization.md

Why not .json?
Do we still need info/recipe/meta.yaml ?

@conda/steering-council
This vote falls under the "Enhancement Proposal Approval" policy of the conda governance policy,
please vote and/or comment on this proposal at your earliest convenience.
It needs 60% of the Steering Council to vote yes to pass.
To vote, please leave yes, no or abstain as comments below.
If you have questions concerning the proposal, you may also leave a comment or code review.
This vote will end on 2024-07-16, End of Day, Anywhere on Earth (AoE). This is an extended voting period due to summer holiday time in the Northern Hemisphere.

yes

Please use the following form to vote:
@xhochy (Uwe Korn)

[ ]  yes
[ ]  no
[ ]  abstain

@cj-wright (Christopher J. 'CJ' Wright)

[ ]  yes
[ ]  no
[ ]  abstain

@mariusvniekerk (Marius van Niekerk)

[ ]  yes
[ ]  no
[ ]  abstain

@goanpeca (Gonzalo Peña-Castellanos)

[ ]  yes
[ ]  no
[ ]  abstain

@chenghlee (Cheng H. Lee)

[ ]  yes
[ ]  no
[ ]  abstain

@ocefpaf (Filipe Fernandes)

[ ]  yes
[ ]  no
[ ]  abstain

@marcelotrevisani (Marcelo Duarte Trevisani)

[ ]  yes
[ ]  no
[ ]  abstain

@msarahan (Michael Sarahan)

[ ]  yes
[ ]  no
[ ]  abstain

@mbargull (Marcel Bargull)

[ ]  yes
[ ]  no
[ ]  abstain

@jakirkham (John Kirkham)

[ ]  yes
[ ]  no
[ ]  abstain

@jezdez (Jannis Leidel)

[ ]  yes
[ ]  no
[ ]  abstain

@wolfv (Wolf Vollprecht)

[ ]  yes
[ ]  no
[ ]  abstain

@jaimergp (Jaime Rodríguez-Guerra)

[ ]  yes
[ ]  no
[ ]  abstain

@kkraus14 (Keith Kraus)

[ ]  yes
[ ]  no
[ ]  abstain

@baszalmstra (Bas Zalmstra)

[ ]  yes
[ ]  no
[ ]  abstain

@marcelotrevisani @jakirkham @cj-wright @mbargull last chance to vote!

For the record: voted "no" because while I like the ideas presented in this CEP, I don't think the CEP as written is ready to be adopted as a specification. IMO, various unanswered questions/comments need to be addressed before adoption, and we should better separate behavioral specifications from implementation details.

I think it is good to have these parts of the build output/process specified which is why I support to have a proposal for it here.
I do agree with Cheng in that this is not yet ready to be put in, though, since the "Specification" section is a bit light in detail and the bigger part of the text, i.e., description of implementation details, are likely to change, so nothing we'd set in stone here.

(tried to use the checkbox, but had issues with it for some reason)

@jakirkham
It's really odd that it doesn't like to accept your edit :/.
I checked "yes" on your behalf.

Thanks Marcel! 🙏
Yeah this happened to me a couple times. So just used "approved" to mean the same thing. Think it is because I tried on my iPhone with GitHub Mobile (not sure why it can't check a box or why it makes an empty edit though 🤷♂)

The vote is closed, and we have the following result:
Total voters: 15 (valid: 13 = 86.67%)
Yes votes (11 / 84.62%):

@xhochy (Uwe Korn)
@mariusvniekerk (Marius van Niekerk)
@goanpeca (Gonzalo Peña-Castellanos)
@ocefpaf (Filipe Fernandes)
@msarahan (Michael Sarahan)
@jakirkham (John Kirkham)
@jezdez (Jannis Leidel)
@wolfv (Wolf Vollprecht)
@jaimergp (Jaime Rodríguez-Guerra)
@kkraus14 (Keith Kraus)
@baszalmstra (Bas Zalmstra)

No votes (2 / 15.38%)):

@chenghlee (Cheng H. Lee)
@mbargull (Marcel Bargull)

Abstain votes (0 / 0.00%):
Not voted (2):

@cj-wright (Christopher J. 'CJ' Wright)
@marcelotrevisani (Marcelo Duarte Trevisani)

Invalid votes (0):
Thus we reached quorum and enough YES votes to mark this as accepted. 🎉

authors: baszalmstra chenghlee dholth jakirkham jezdez mbargull wolfv

repo: conda/ceps


text:
(WIP) Add Dockerfile for concourse-ci linux-32

CC @msarahan @mingwandroid

@msarahan I have added the script to build the fly 32-bit binary and now it will be built each time the container is built. Now the only thing we need to fix is:
PackageNotFoundError: Package missing in current linux-32 channels:
  - conda-concourse-ci

Excellent, nice work. I will use this container to build the initial version of c3i for Linux 32 today.

Let's make two directories within the root docker directory in this repo.  The current contents in master within the docker directory should go into a directory named c3i-linux-64, since this is the base image for the linux-64 subdir, and the new Dockerfile and other work here should go into c3i-linux-32.  The image names can then match those directory names.

Merging for now, will make PRs for changes as needed.

authors: kalefranz msarahan nehaljwani

repo: conda/conda-concourse-ci

license_source: bigquery


text:
Merge upstream changes

Description
Merge changes from kafka connector.

Conflicts are resolved in this PR: https://github.com/conduitio-labs/conduit-connector-redpanda/pull/25.


text:
Picked: QA Steps to check breakages in CI

Let's ensure all 0.6.x updates are 100% compatible with 0.6.0.
Acceptance Criteria

The CI should run something to enforce that.
The main/0.7 tag may include breaks from 0.6. Those need to be noted in human-readable docs. Where?
We can also consider what level of automated support we can/want to use here. Document a set of test an create a collection of issues for that on the board. Should it be split from this task?

There are some questions open and need to be clarified in the refinement.

authors: BirgitPohl ethanfrey

repo: confio/poe-contracts


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/avro-c-packaging


text:
Consumer error Local_MaxPollExceeded is Fatal for consumer

Description
When my code  got stuck (dumping, debugging, lack of system resources, bad code...), and as a result of it I do not call Consume method on Consumer longer than  max.poll.interval.ms  Consumer throws exception with error
Code=Local_MaxPollExceeded
IsBrokerError=false
IsError=true
IsFatal=false
IsLocalError=true
Consumer does not recover, and I need to restart my app (I suppose recreating consumer would also work). From my point of view, shouldn't this error be Fatal? If not why Consumer does not recover?
How to reproduce
Consume some message from topic, then break app using Thread.Sleep() for longer interval than max.poll.interval.ms
Checklist
Please provide the following information:

[x] A complete (i.e. we can run it), minimal program demonstrating the problem. No need to supply a project file.
[x] Confluent.Kafka nuget version. 1.3.0
[x] Apache Kafka version. kafka_2.12-2.2.0
[x] Operating system. - windows/linux

The consumer shall recover as soon as you start calling Consume() again, which will trigger a rejoin of the group.

I was expecting same behaviour, but after this exception Consumer.Consume  keeps returning null.

It will return null (after timeout expires) until the consumer has rejoined the group and received a new assignment, which may take up to max.poll.interval.ms + session.timeout.ms.

Tested right now, and it does not work.
I overrided settings to this:
consumerConfig.SessionTimeoutMs = 20000; consumerConfig.MaxPollIntervalMs = 30000;
and after first call to consumer.Consume() I called Thread.Sleep(40000);  => exception
now I am checking Consume result for more that 4 minutes after exception and consumer.Consume keeps returning null

One thing to note - we do not use consumer groups and assign the start offset manually.

Can you reproduce this with Debug: "cgrp" set and provide us the logs?

Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:app]: Group "myGroup": updating member id "(not-set)" -> ""
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:app]: librdkafka v1.3.0 (0x10300ff) rdkafka#consumer-1 initialized (builtin.features gzip,snappy,ssl,sasl,regex,lz4,sasl_gssapi,sasl_plain,sasl_scram,plugins,zstd,sasl_oauthbearer, SSL ZLIB SNAPPY SASL_SCRAM PLUGINS HDRHISTOGRAM, debug 0x100)
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" changed state init -> query-coord (v1, join-state init)
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: 10.1.1.20:9092/1: Group "myGroup": querying for coordinator: intervaled in state query-coord
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" changed state query-coord -> wait-coord (v1, join-state init)
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: 10.1.1.20:9092/1: Group "myGroup" coordinator is 10.1.1.22:9092 id 3
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" changing coordinator -1 -> 3
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" coordinator set to broker 10.1.1.22:9092/3
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" changed state wait-coord -> wait-broker-transport (v1, join-state init)
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: 10.1.1.20:9092/1: Group "myGroup": querying for coordinator: intervaled in state wait-broker-transport
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: 10.1.1.20:9092/1: Group "myGroup" coordinator is 10.1.1.22:9092 id 3
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" changed state wait-broker-transport -> up (v1, join-state init)
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" received op ASSIGN (v0) in state up (join state init, v1 vs 0)
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup": new assignment of 1 partition(s) in join state init
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup": rd_kafka_cgrp_assign:2432: new version barrier v2
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup": assigning 1 partition(s) in join state init
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" changed join state init -> assigned (v2, state up)
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup": rd_kafka_cgrp_partitions_fetch_start0:1736: new version barrier v3
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup": starting fetchers for 1 assigned partition(s) in join-state assigned (usable_offsets=no, v3, line 2477)
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: List with 1 partition(s):
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]:  company-events-metadata-991935-637171562028072598 [0] offset 0
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" changed join state assigned -> started (v3, state up)
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" received op PARTITION_JOIN in state up (join state started, v3) for company-events-metadata-991935-637171562028072598 [0]
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup": add company-events-metadata-991935-637171562028072598 [0]
Handle: rdkafka#consumer-1	Level: Warning	Message:[thrd:main]: Application maximum poll interval (30000ms) exceeded by 288ms (adjust max.poll.interval.ms for long-running message processing): leaving group
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup": leave (in state up)
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" is rebalancing in state up (join-state started) with assignment: max.poll.interval.ms exceeded
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" changed join state started -> wait-unassign (v3, state up)
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup": rd_kafka_cgrp_unassign:2345: new version barrier v4
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup": unassigning 1 partition(s) (v4)
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Unassign not done yet (1 wait_unassign, 1 assigned, 0 wait commit, join state wait-unassign): unassign
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" received op PARTITION_LEAVE in state up (join state wait-unassign, v4) for company-events-metadata-991935-637171562028072598 [0]
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup": delete company-events-metadata-991935-637171562028072598 [0]
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" received op REPLY:FETCH_STOP in state up (join state wait-unassign, v4) for company-events-metadata-991935-637171562028072598 [0]
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup": unassign done in state up (join state wait-unassign): without new assignment: FETCH_STOP done
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" changed join state wait-unassign -> init (v4, state up)
Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: LeaveGroup response error in state up: Broker: Unknown member

Is that all the logs there are? Nothing else emitted after that last line?

thats all

Even after waiting 30s or so?

I will give it another try, wait for it :)

No it is all, I waited 7 min, no other info in log.

Okay, thank you, will investigate.
Can you provide your consumer config?

OK after 10 min fer more lines:
Time: 15:03:53	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:app]: Group "myGroup": updating member id "(not-set)" -> ""
Time: 15:03:53	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:app]: librdkafka v1.3.0 (0x10300ff) rdkafka#consumer-1 initialized (builtin.features gzip,snappy,ssl,sasl,regex,lz4,sasl_gssapi,sasl_plain,sasl_scram,plugins,zstd,sasl_oauthbearer, SSL ZLIB SNAPPY SASL_SCRAM PLUGINS HDRHISTOGRAM, debug 0x100)
Time: 15:03:53	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" changed state init -> query-coord (v1, join-state init)
Time: 15:03:53	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: 10.1.1.20:9092/1: Group "myGroup": querying for coordinator: intervaled in state query-coord
Time: 15:03:53	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" changed state query-coord -> wait-coord (v1, join-state init)
Time: 15:03:54	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: 10.1.1.20:9092/1: Group "myGroup" coordinator is 10.1.1.22:9092 id 3
Time: 15:03:54	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" changing coordinator -1 -> 3
Time: 15:03:54	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" coordinator set to broker 10.1.1.22:9092/3
Time: 15:03:54	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" changed state wait-coord -> wait-broker-transport (v1, join-state init)
Time: 15:03:54	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: 10.1.1.20:9092/1: Group "myGroup": querying for coordinator: intervaled in state wait-broker-transport
Time: 15:03:54	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: 10.1.1.20:9092/1: Group "myGroup" coordinator is 10.1.1.22:9092 id 3
Time: 15:03:54	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" changed state wait-broker-transport -> up (v1, join-state init)
Time: 15:03:54	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" received op ASSIGN (v0) in state up (join state init, v1 vs 0)
Time: 15:03:54	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup": new assignment of 1 partition(s) in join state init
Time: 15:03:54	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup": rd_kafka_cgrp_assign:2432: new version barrier v2
Time: 15:03:54	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup": assigning 1 partition(s) in join state init
Time: 15:03:54	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" changed join state init -> assigned (v2, state up)
Time: 15:03:54	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup": rd_kafka_cgrp_partitions_fetch_start0:1736: new version barrier v3
Time: 15:03:54	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup": starting fetchers for 1 assigned partition(s) in join-state assigned (usable_offsets=no, v3, line 2477)
Time: 15:03:54	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: List with 1 partition(s):
Time: 15:03:54	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]:  company-events-metadata-991935-637171562028072598 [0] offset 0
Time: 15:03:54	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" changed join state assigned -> started (v3, state up)
Time: 15:03:54	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" received op PARTITION_JOIN in state up (join state started, v3) for company-events-metadata-991935-637171562028072598 [0]
Time: 15:03:54	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup": add company-events-metadata-991935-637171562028072598 [0]
Time: 15:04:25	Handle: rdkafka#consumer-1	Level: Warning	Message:[thrd:main]: Application maximum poll interval (30000ms) exceeded by 312ms (adjust max.poll.interval.ms for long-running message processing): leaving group
Time: 15:04:25	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup": leave (in state up)
Time: 15:04:25	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" is rebalancing in state up (join-state started) with assignment: max.poll.interval.ms exceeded
Time: 15:04:25	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" changed join state started -> wait-unassign (v3, state up)
Time: 15:04:25	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup": rd_kafka_cgrp_unassign:2345: new version barrier v4
Time: 15:04:25	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup": unassigning 1 partition(s) (v4)
Time: 15:04:25	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Unassign not done yet (1 wait_unassign, 1 assigned, 0 wait commit, join state wait-unassign): unassign
Time: 15:04:25	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" received op PARTITION_LEAVE in state up (join state wait-unassign, v4) for company-events-metadata-991935-637171562028072598 [0]
Time: 15:04:25	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup": delete company-events-metadata-991935-637171562028072598 [0]
Time: 15:04:25	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" received op REPLY:FETCH_STOP in state up (join state wait-unassign, v4) for company-events-metadata-991935-637171562028072598 [0]
Time: 15:04:25	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup": unassign done in state up (join state wait-unassign): without new assignment: FETCH_STOP done
Time: 15:04:25	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" changed join state wait-unassign -> init (v4, state up)
Time: 15:04:25	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: LeaveGroup response error in state up: Broker: Unknown member
Time: 15:14:01	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: 10.1.1.21:9092/2: Group "myGroup": querying for coordinator: intervaled in state up
Time: 15:14:02	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: 10.1.1.21:9092/2: Group "myGroup" coordinator is 10.1.1.22:9092 id 3
Time: 15:14:31	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" changed state up -> query-coord (v4, join-state init)
Time: 15:14:31	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: 10.1.1.20:9092/1: Group "myGroup": querying for coordinator: intervaled in state query-coord
Time: 15:14:31	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" changed state query-coord -> wait-coord (v4, join-state init)
Time: 15:14:31	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: 10.1.1.20:9092/1: Group "myGroup" coordinator is 10.1.1.22:9092 id 3
Time: 15:14:31	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" changed state wait-coord -> wait-broker-transport (v4, join-state init)
Time: 15:14:31	Handle: rdkafka#consumer-1	Level: Debug	Message:[thrd:main]: Group "myGroup" changed state wait-broker-transport -> up (v4, join-state init)

Client config:
GroupId = "myGroup";
EnableAutoCommit = false;
EnablePartitionEof = true;
MaxPartitionFetchBytes = 50 * 1024 * 1024;
AutoOffsetReset = AutoOffsetReset.Earliest;
SessionTimeoutMs = 20000;
MaxPollIntervalMs = 30000;
Debug = "cgrp";
BootstrapServers = "10.1.1.20:9092,10.1.1.21:9092,10.1.1.22:9092",
TopicMetadataRefreshIntervalMs = 30000,
MessageMaxBytes = 50 * 1024 * 1024,
ReceiveMessageMaxBytes = 2* 50 * 1024 * 1024,

Ah, I think I know what the problem is, you are not using Subscribe(), but Assign()ing partitions directly.
The max.poll.interval.ms should not be enforced unless there is an active group subscription, this is a bug in librdkafka that we'll fix for v1.4.0.
The workaround is to set max.poll.interval.ms to its maximum value.

Thank you for help

Fixed in upcoming v1.4.0

The consumer shall recover as soon as you start calling Consume() again, which will trigger a rejoin of the group.

If the consumption partition is rejoined, another problem will arise. The previous consumption offset has not been submitted successfully, and the previous message will be re-consumed all the time.

authors: e-jlion edenhill klesta490 tomasdeml

repo: confluentinc/confluent-kafka-dotnet


text:
Creating partitions in producer

Hi, is it possible to create partitions using confluent.kafka package.
Even when I am using patitioner.random in the config, but still I am seeing only one partition
How to reproduce
Checklist
Please provide the following information:

[ ] Confluent.Kafka nuget version:
[ ] Apache Kafka version:
[ ] Client configuration:
[ ] Operating system:
[ ] Provide logs (with "debug" : "..." as necessary in configuration)
[ ] Provide broker log excerpts
[ ] Critical issue

yes, you can specify the number of partitions in AdminClient.CreateTopicsAsync, or increase the number of partitions in an existing topic using AdminClient.CreatePartitionsAsync. typically you should specify the number of partitions when you create the topic and not change this. note that auto topic creation is on by default (a broker setting), which will create topics you reference automatically if they don't exist and by default this will create topics with one partition. i'm guessing you're doing that?

Yep I am making use of automatic topic creation . Yep I'll give a try with AdminClient

authors: mhowlett pavanarya


text:
ST-2811: Adding support for running as appuser in rhel image

The base image now has a user account "appuser" and this change will make the service run as that user instead of root.
The PR build for this will not succeed until the new version of the base image is published with the appuser.

@confluentinc It looks like @elismaga just signed our Contributor License Agreement. :+1:
Always at your service,
clabot

authors: ConfluentCLABot elismaga

repo: confluentinc/kafka-streams-examples


text:
fix state directory cleanup

@guozhangwang
The current implementation of StreamThread.maybeClean() is a nasty time bomb. It destroys local state after the cleanup delay time.
StreamThread cleans up unused state directories after the cleanup delay time. But it knows only the tasks assigned to it. It means it deletes any task directory that does not belong to itself. Thus the threads destroys each other's local state. :(
To solve this, I added a lock file to each state directory as protection. ProcessorStateManager acquires this lock. maybeClean() also tries to acquire this lock before cleaning up the directory. If successful, it can clean the directory, otherwise, skip it. This works when there are multiple instance of KafkaStreaming running either in the same JVM or different JVMs.
I also added a code to reset lastClean to the current timestamp in onPartitionAssigned because we should time the cleanup delay after partitions are assigned.

lgtm

authors: guozhangwang ymatsuda

repo: confluentinc/kafka


text:
Is it possible to use existing tools to remove indentation/whitespace using prism?

In a nutshell I'm basically trying to ensure that this gets formatted correctly:
                ...

                <SyntaxHighlighter language='html' style={xonokai}>{`

 This is an alert

                `}</SyntaxHighlighter>

                ...

I've attempted to use preCode.js, with the result being the following: https://imgur.com/a/PdYNo - the formatting works, but all highlighting has been removed.
Is it possible to achieve this with my setup?

This is my version of process function (TypeScript). Removes both leading and trailing empty lines and trims all lines more aggressively.
function process(code: React.ReactNode) {
  let skippedLeadingEmptyLines = false;
  let lastLineIdx = 0;
  let indentation = Number.MAX_SAFE_INTEGER;
  let numRemovedLines = 0;

  function processNonEmptyLine(line: string, i: number) {
    lastLineIdx = i - numRemovedLines;
    indentation = Math.min(indentation, Math.max(0, line.search(/[^ \t]/)));
    return [line.trimRight()];
  }

  const lines = `${code}`
    .split('\n')
    .flatMap((line, i) => {
      if (!skippedLeadingEmptyLines) {
        if (line.match(/^[ \t]*$/)) {
          numRemovedLines += 1;
          return [];
        }

        skippedLeadingEmptyLines = true;
        return processNonEmptyLine(line, i);
      }

      if (line.match(/^[ \t]*$/)) {
        return [''];
      }

      return processNonEmptyLine(line, i);
    })
    .slice(0, lastLineIdx + 1);

  if (lines.length === 0) {
    return '';
  }

  return (indentation !== 0
    ? lines.map(line => line.substring(indentation))
    : lines
  ).join('\n');
}

The version of @trustin works really good, but it was hard for me to understand the functionality. So I refactored it a little bit and want to share it here:
const process = (code: string) => {
  let skippedLeadingEmptyLines = false;
  let lastNonEmptyLineIndex = 0;
  let minRawStringIndentation = Number.MAX_SAFE_INTEGER;
  let numberOfRemovedLines = 0;

  const processNonEmptyLine = (line: string, index: number) => {
    // keep track of the index of the last non-empty line
    lastNonEmptyLineIndex = index - numberOfRemovedLines;
    // determine the minimum indentation level
    minRawStringIndentation = Math.min(minRawStringIndentation, Math.max(0, line.search(/\S/)));
    // return the processed line
    return [line.trimEnd()];
  };

  // split code into lines
  const codeLines = code.split('\n');

  // remove empty lines, and process non-empty lines
  const nonEmptyLinesAtStart = codeLines.flatMap((line, index) => {
    if (!skippedLeadingEmptyLines) {
      if (line.match(/^\s*$/)) {
        numberOfRemovedLines += 1;
        return [];
      }

      skippedLeadingEmptyLines = true;
      return processNonEmptyLine(line, index);
    }

    if (line.match(/^\s*$/)) return [''];

    return processNonEmptyLine(line, index);
  });

  const nonEmptyLinesStartAndEnd = nonEmptyLinesAtStart.slice(0, lastNonEmptyLineIndex + 1);

  // If there are no non-empty lines, return an empty string
  if (nonEmptyLinesStartAndEnd.length === 0) return '';

  const nonRawStringIndentationLines =
    minRawStringIndentation !== 0
      ? nonEmptyLinesStartAndEnd.map((line) => line.substring(minRawStringIndentation))
      : nonEmptyLinesStartAndEnd;

  return nonRawStringIndentationLines.join('\n');
};

authors: MatchuPitchu esr360 trustin

repo: conorhastings/react-syntax-highlighter

license: mit


text:
Stellar Classic

{
"symbol": "XLMX",
"address": "0xab2282e27533749d7883e24f82dc8dfa2b3e3c85",
"overview": {
"en": "Stellar Classic Ecosystem is a modern age freelance marketplace created with the aim to resolve issues faced by traditional freelance industry and enable seamless, risk-free connectivity between free-lancers and buyers at minimal costs.",
"zh": Stellar Classic Ecosystem是一个现代化的自由市场，旨在解决传统自由职业所面临的问题，并以最低成本实现自由职业者与买家之间的无缝，无风险连接。"
},
"email": "support@stellarclassics.com",
"website": "http://stellarclassics.com/",
"whitepaper": "http://stellarclassics.com/images/StellarClassic_Whitepaper_v.1.0_en.pdf",
"state": "NORMAL",
"published_on": "2018-12-20",
"initial_price":{
"ETH":"0.0000001 ETH",
},
"links": {
"twitter": "https://twitter.com/classicstellar",
"telegram": "https://telegram.me/stellarcla
ssics",
"reddit": "https://www.reddit.com/user/stellarclassic/",
"github": "https://github.com/Classicstellar",
"facebook": "https://www.facebook.com/Stellarclassics",
}
}

代币信息提交有误，请参考此教程 https://github.com/consenlabs/token-profile/blob/master/README.zh-CN.md，
建议和你们的技术和设计协作完成资料的提交。

authors: ClassicStellar tstt

repo: consenlabs/token-profile


text:
update-Green-token

官方公告：
http://www.cgreenchain.com/?lang=zh
团队背景：
Green团队均为区块链经验丰富从业者。首席技术官Darren在美国哥伦比亚大学获得计算机博士学位，曾在雅虎、谷歌任职，有着丰富的大型科技公司的工作经验，并在谷歌负责搜索引擎的前端页面以及后端数据库的处理，曾多次获得谷歌最多代码贡献人。也曾在一知名公链内存块链项目里出任CTO，负责分片技术的设计和开发。
项目基本情况：
Green是由新加坡碳资产管理公司开发并管理的去中心化森林碳汇稳定币，每个Green单位代表0.1吨真实的森林碳汇合约。1Green=0.1t森林碳汇合约。Green的价值将随全球各碳市场的快速发展而不断增值。
媒体报道

微博 https://weibo.com/u/7282324101?topnav=1&wvr=6&topsug=1&is_all=1

建议 gas limit：60000

修改token初始价格。麻烦同步下。谢谢。


text:
0x119f095a45df2a77337042bcc4f2e52fA6e7e881.json and png

Official announcement:https://twitter.com/Minesweeper_SM/status/1460918247943901186
Team background：
The SuperMinesweeper team is located in Australia, and the core members have more than 10 years of Internet product development experience on average，Greg is an experienced CEO with an amazing history of contributing significant value to Fortune 500 companies. Greg has expertise in developing business strategies and a strong interest in the blockchain space. As an early adopter of NFT and a fan of multiple fields including games, art and anime, Greg is striving to define the NFT ecosystem with cutting-edge innovative solutions.
Project Basic Information：
The biggest difference between "Super Minesweeper" and Microsoft Minesweeper is that it empowers the game map to make a perfectly replicated decentralized + NFT + P2E + DeFi game for the vast number of cryptocurrency lovers and Minesweeper lovers. The game map that users play is not generated by the system, but a unique game map created by users, uploading the map parameters to the block chain to obtain NFT credentials, Minesweeper starts by referring to the NFT parameters on the chain to obtain the game map. At the same time, the user creates and generates the game map NFT can be stored and traded.
Website：https://smcoin.info，
Twitter: https://twitter.com/Minesweeper_SM
Media reports:
AP NEWS https://apnews.com/press-release/kisspr/technology-blockchain-2f1c91832b02eac815f95f154873605b
Recommended gas limit: 60000
Exchange：
https://pancakeswap.finance/swap?outputCurrency=0x119f095a45df2a77337042bcc4f2e52fa6e7e881

The official website has too little content and untrue information


text:
gb silently fails on build errors

$ gb build -v -a
DEBUG project root "/Users/kelseyhightower/confd"
DEBUG matchPackages: [/Users/kelseyhightower/confd/src] ...
DEBUG args: [github.com/kelseyhightower/confd github.com/kelseyhightower/confd/backends github.com/kelseyhightower/confd/backends/consul github.com/kelseyhightower/confd/backends/dynamodb github.com/kelseyhightower/confd/backends/env github.com/kelseyhightower/confd/backends/etcd github.com/kelseyhightower/confd/backends/redis github.com/kelseyhightower/confd/backends/zookeeper github.com/kelseyhightower/confd/integration/zookeeper github.com/kelseyhightower/confd/log github.com/kelseyhightower/confd/resource/template]
DEBUG skipping "github.com/kelseyhightower/confd" because of error "no buildable Go source files in /Users/kelseyhightower/confd/vendor/src/github.com/BurntSushi/toml"
DEBUG loadPackage: github.com/hashicorp/consul/api false (/Users/kelseyhightower/confd/vendor/src/github.com/hashicorp/consul/api)
DEBUG loadPackage: github.com/kelseyhightower/confd/backends/consul false (/Users/kelseyhightower/confd/src/github.com/kelseyhightower/confd/backends/consul)
DEBUG loadPackage: github.com/awslabs/aws-sdk-go/aws/awserr true (/Users/kelseyhightower/confd/vendor/src/github.com/awslabs/aws-sdk-go/aws/awserr)
DEBUG loadPackage: github.com/awslabs/aws-sdk-go/internal/apierr true (/Users/kelseyhightower/confd/vendor/src/github.com/awslabs/aws-sdk-go/internal/apierr)
DEBUG skipping "github.com/kelseyhightower/confd/backends" because of error "no buildable Go source files in /Users/kelseyhightower/confd/vendor/src/github.com/vaughan0/go-ini"
DEBUG skipping "github.com/kelseyhightower/confd/backends/dynamodb" because of error "no buildable Go source files in /Users/kelseyhightower/confd/vendor/src/github.com/vaughan0/go-ini"
DEBUG loadPackage: github.com/kelseyhightower/confd/backends/env false (/Users/kelseyhightower/confd/src/github.com/kelseyhightower/confd/backends/env)
DEBUG loadPackage: github.com/coreos/go-etcd/etcd false (/Users/kelseyhightower/confd/vendor/src/github.com/coreos/go-etcd/etcd)
DEBUG loadPackage: github.com/kelseyhightower/confd/backends/etcd false (/Users/kelseyhightower/confd/src/github.com/kelseyhightower/confd/backends/etcd)
DEBUG loadPackage: github.com/garyburd/redigo/internal false (/Users/kelseyhightower/confd/vendor/src/github.com/garyburd/redigo/internal)
DEBUG loadPackage: github.com/garyburd/redigo/redis false (/Users/kelseyhightower/confd/vendor/src/github.com/garyburd/redigo/redis)
DEBUG loadPackage: github.com/kelseyhightower/confd/backends/redis false (/Users/kelseyhightower/confd/src/github.com/kelseyhightower/confd/backends/redis)
DEBUG loadPackage: github.com/samuel/go-zookeeper/zk false (/Users/kelseyhightower/confd/vendor/src/github.com/samuel/go-zookeeper/zk)
DEBUG loadPackage: github.com/kelseyhightower/confd/backends/zookeeper false (/Users/kelseyhightower/confd/src/github.com/kelseyhightower/confd/backends/zookeeper)
DEBUG loadPackage: github.com/kelseyhightower/confd/integration/zookeeper true (/Users/kelseyhightower/confd/src/github.com/kelseyhightower/confd/integration/zookeeper)
DEBUG skipping "github.com/kelseyhightower/confd/log" because of error "no buildable Go source files in /Users/kelseyhightower/confd/vendor/src/github.com/Sirupsen/logrus"
DEBUG skipping "github.com/kelseyhightower/confd/resource/template" because of error "no buildable Go source files in /Users/kelseyhightower/confd/vendor/src/github.com/BurntSushi/toml"
DEBUG buildPackage: github.com/kelseyhightower/confd/backends/consul
DEBUG buildPackage: github.com/hashicorp/consul/api
DEBUG buildPackage: github.com/kelseyhightower/confd/backends/env
DEBUG buildPackage: github.com/kelseyhightower/confd/backends/etcd
DEBUG buildPackage: github.com/coreos/go-etcd/etcd
DEBUG buildPackage: github.com/kelseyhightower/confd/backends/redis
DEBUG buildPackage: github.com/garyburd/redigo/redis
DEBUG buildPackage: github.com/garyburd/redigo/internal
DEBUG buildPackage: github.com/kelseyhightower/confd/backends/zookeeper
DEBUG buildPackage: github.com/samuel/go-zookeeper/zk
DEBUG buildPackage: github.com/kelseyhightower/confd/integration/zookeeper
DEBUG {main github.com/kelseyhightower/confd/integration/zookeeper /Users/kelseyhightower/confd/src/github.com/kelseyhightower/confd/integration/zookeeper} is a main package, not installing
INFO github.com/kelseyhightower/confd/integration/zookeeper
DEBUG gc:gc github.com/kelseyhightower/confd/integration/zookeeper /Users/kelseyhightower/confd /var/folders/ds/jbxmdvmx0rj1z7vc4br6j97h0000gn/T/gb915817495/github.com/kelseyhightower/confd/integration/zookeeper/main.a [src/github.com/kelseyhightower/confd/integration/zookeeper/main.go]
DEBUG cd /Users/kelseyhightower/confd; [/usr/local/go/pkg/tool/darwin_amd64/6g -p github.com/kelseyhightower/confd/integration/zookeeper -pack -o /var/folders/ds/jbxmdvmx0rj1z7vc4br6j97h0000gn/T/gb915817495/github.com/kelseyhightower/confd/integration/zookeeper/main.a -I /var/folders/ds/jbxmdvmx0rj1z7vc4br6j97h0000gn/T/gb915817495 -I /Users/kelseyhightower/confd/pkg/darwin/amd64 -complete src/github.com/kelseyhightower/confd/integration/zookeeper/main.go]
DEBUG cd .; [/usr/local/go/pkg/tool/darwin_amd64/6l -o /Users/kelseyhightower/confd/bin/zookeeper -L /var/folders/ds/jbxmdvmx0rj1z7vc4br6j97h0000gn/T/gb915817495 -L /Users/kelseyhightower/confd/pkg/darwin/amd64 -extld=gcc /var/folders/ds/jbxmdvmx0rj1z7vc4br6j97h0000gn/T/gb915817495/github.com/kelseyhightower/confd/integration/zookeeper/main.a]
DEBUG removing work directory: /var/folders/ds/jbxmdvmx0rj1z7vc4br6j97h0000gn/T/gb915817495
DEBUG build duration: 327.099683ms map[compile:25.094244ms link:285.695742ms]
confd $ echo $?
0

@kelseyhightower where is the build error ?

DEBUG skipping "github.com/kelseyhightower/confd/resource/template" because of error "no buildable Go source files in /Users/kelseyhightower/confd/vendor/src/github.com/BurntSushi/toml"

Thanks.

+1

@kelseyhightower I think the original problem was fixed in #126, when I fixed copypath, but I can replicate the problem.

authors: davecheney kelseyhightower pires

repo: constabulary/gb


text:
🛑 moncul.org is down

In 9a5baf1, moncul.org (https://moncul.org) was down:

HTTP code: 520
Response time: 869 ms

Resolved: moncul.org is back up in b726bb1.

repo: constructions-incongrues/status


text:
🛑 thebrainradio.com is down

In febc8cd, thebrainradio.com (https://thebrainradio.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: thebrainradio.com is back up in a179e04.


text:
fix #3: remove insecure registry step

From the docs, it doesn't seem like this step is needed to interact with the registry, we'll see if the checks pass

From the docs, it doesn't seem like this step is needed to interact with the registry, we'll see if the checks pass

Right, I guess there's some IP range match that makes it insecure by default.

authors: johnpoth nicolaferraro

repo: container-tools/kind-action


text:
go-client: Return an ExitStatus struct when calling process.Delete()

Signed-off-by: Kenfe-Mickael Laventure mickael.laventure@gmail.com

Codecov Report

Merging #1417 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1417   +/-   ##
=======================================
  Coverage   40.81%   40.81%
=======================================
  Files          23       23
  Lines        2923     2923
=======================================
  Hits         1193     1193
  Misses       1452     1452
  Partials      278      278

Continue to review full report at Codecov.

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

LGTM

LGTM

authors: codecov-io crosbymichael dmcgowan mlaventure

repo: containerd/containerd