NetworkManager unable to save OpenVPN settings properly

Issue description
NetworkManager unable to save OpenVPN setting
Steps to reproduce
Try to import previously working fine OpenVPN configuration - it will fail on cert file saving, setting ca key to both ca and cert and nothing to private key
Technical details

System: 18.03pre117327.3fe7cddc30 (Impala)
Nix version: nix-env (Nix) 1.11.15
Nixpkgs version: (run "18.03pre117327.3fe7cddc30")
Sandboxing enabled: yes

Oct 08 22:41:58 odyssey.otwiera.cz .nm-connection-[13784]: failed to commit changes to dconf: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name ca.desrt.dconf was not provided by any .service files

Possibly related to
https://github.com/NixOS/nixpkgs/issues/2448

With gnome.dconf installed, it fails with:
Oct 08 22:49:06 odyssey.otwiera.cz gnome-keyring-daemon[32063]: couldn't access control socket: /run/user/1000/keyring/control: No such file or directory
Oct 08 22:49:06 odyssey.otwiera.cz .gnome-keyring-[32063]: couldn't access control socket: /run/user/1000/keyring/control: No such file or directory

After manual creation of /etc/NetworkManager/system-connctions/my-vpn-file it worked. However, still unable to save VPN config.

try install nix-env -i dconf

I don't think this is dconf related, since nm-applet can create the vpn connection successfully.  It just set a wrong value for vpn.data:
$ nmcli conn edit vpn
nmcli> goto vpn
nmcli> goto data
nmcli> print
data: cert-pass-flags = 0, cert = /home/gebner/.vpn/ca.crt, ca = /home/gebner/.vpn/ca.crt, connection-type = tls, remote = ....

BTW, as a workaround you can fix the vpn connection manually using nmcli:
$ nmcli connection modify my-vpn vpn.data "connection-type = tls, key = /home/gebner/.vpn/some.key, ca = /home/gebner/.vpn/ca.crt, cert = /home/gebner/.vpn/some.crt, remote = example.com"

(triage) Is this issue still present in 19.03?

@baracoder No, thankfully it is fixed for me in 19.03.


⚠ Bofrost.lu has degraded performance

In fb6f931, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1380 ms

Resolved: Bofrost.lu performance has improved in 6e1df2c after 33 minutes.


Add --no-dev to composer install

Probably it is necessary add one more option for composer install like --no-dev.
For production environment not need libraries in section require-dev  in file composer.json

Resolved by commit 52580aff84266d8af1af9645fe0c19d671e15d27


Fix deploy.yml branch name

Branch name was set to my dev branch, this will fix it do deploy runs on master @jph00

Could you also pip import this?
https://pypi.org/project/nbdev-apl/
That should auto-add hyperlinks to APL docs.


Org policy need to set

constraints/compute.requireShieldedVm (Enforcement: Off)
constraints/storage.uniformBucketLevelAccess (Enforcement: Off)
constraints/cloudfunctions.allowedIngressSettings (Policy values: Allow ALL)

These org policies are set on some internal employee test environments but are not necessarily representative of environments where customers deploy this code.
It is recommended to loosen the org policies in your internal test environment, rather than accommodate some optional org policies in this workload-level terraform script that will consumed by people without the same org policy restrictions.
I've adjusted the Storage Bucket UBLA settings to reduce friction (it's a clear security best practice anyway) but the other 2 policies I won't fix.


Revisting project rules/search

One of the biggest complaints about projects is that its difficult for project curators to 'find suitable observations' to add to their projects. But the find suitable observation tool uses search filters that don't match the rules that projects rely on to control observations that can be added to the project.
This could be simplified if we revisited the project rules so that they matched observation search filters.
Currently, in order of the number of projects using them, project rules are distributed as follows:

a) in place, in taxa, wild, and on_list (with maybe these mods #631) and observation_fields already match search filters
b) has_media, has_photos, has_sound, georeferenced all seem to be used to select 'obs with appropriate metadata' which I think could be consolidated into the new 'verifiable' filter.
c) identified? seems to be mainly used by projects that don't have an understanding of how obs get ID'd in iNat (which is often after they are added to projects). I bet no one would complain if we removed it and offered the verifiable filter instead.
d) captive? is only used by a handful of arboretum projects murray set up that aren't being used. IMO this filter doesn't seem critical to the success of these projects and should be removed
e) I think we should add 'after start date' and 'before end date' as rules and get rid of the BioBlitz type project (BioBlitz type projects would be projects with start/end dates and the aggregator turned on). Its confusing to have this additional complexity of multiple project types and what it means for obs to be in a project.
f) a curator_coordinate_access rule has been requested #572

If these rules were in place, then every project could be use search filters to properly scope 'suitable obs' some of these project specific filters might be best to only display on the project_obs search (as opposed to the general obs search) as we currently do with the project and curator_id filters:

Sounds sensible, I think you're right about the use of "identified", and the addition of start and end dates would be really useful.
If the ultimate reason for the changes is to help project curators add observations, I think three other issuse need to be addressed too.

If you use "find suitable observations" to find observations, then try to narrow it down using search, it doesn't carry over the "not_in_project=" parameter, so your narrower search is meaningless.
If you do find some observation to add to the project, but the project has a required field, then the add to project operation silently fails see https://github.com/inaturalist/inaturalist/issues/689 (this wastes a lot of time)
I really miss the ability to add a batch of suitable observations as the "find suitable observations" function used to do, it would be great if curators could use a batch edit function on search results.


[Bug] Please enhance instruction for building Python package

Please update instruction or build script to make it work on any CUDA toolkit-enabled system.

Couldn't find include header

❯ pyenv activate cucim-3.8
❯ cd python
❯ python -m pip install .
Looking in indexes: https://pypi.org/simple, https://pypi.ngc.nvidia.com
Processing /home/gbae/repo/kvikio/python
  DEPRECATION: A future pip version will change local packages to be built in-place without first copying to a temporary directory. We recommend you use --use-feature=in-tree-build to test your packages with this new behavior before it becomes the default.
   pip 21.3 will remove support for this functionality. You can find discussion regarding this at https://github.com/pypa/pip/issues/7555.
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
    Preparing wheel metadata ... done
Collecting cython
  Downloading Cython-0.29.28-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.manylinux_2_24_x86_64.whl (1.9 MB)
     |████████████████████████████████| 1.9 MB 1.1 MB/s
Building wheels for collected packages: kvikio
  Building wheel for kvikio (PEP 517) ... error
  ERROR: Command errored out with exit status 1:
   command: /home/gbae/.pyenv/versions/cucim-3.8/bin/python /home/gbae/.pyenv/versions/cucim-3.8/lib/python3.8/site-packages/pip/_vendor/pep517/in_process/_in_process.py build_wheel /tmp/tmp7ibfglvk
       cwd: /tmp/pip-req-build-d06p8fxv
  Complete output (27 lines):
  running bdist_wheel
  running build
  running build_py
  creating build
  creating build/lib.linux-x86_64-3.8
  creating build/lib.linux-x86_64-3.8/kvikio
  copying kvikio/cufile.py -> build/lib.linux-x86_64-3.8/kvikio
  copying kvikio/zarr.py -> build/lib.linux-x86_64-3.8/kvikio
  copying kvikio/thread_pool.py -> build/lib.linux-x86_64-3.8/kvikio
  copying kvikio/_version.py -> build/lib.linux-x86_64-3.8/kvikio
  copying kvikio/__init__.py -> build/lib.linux-x86_64-3.8/kvikio
  creating build/lib.linux-x86_64-3.8/kvikio/_lib
  copying kvikio/_lib/__init__.py -> build/lib.linux-x86_64-3.8/kvikio/_lib
  copying kvikio/_lib/arr.pyi -> build/lib.linux-x86_64-3.8/kvikio/_lib
  UPDATING build/lib.linux-x86_64-3.8/kvikio/_version.py
  set build/lib.linux-x86_64-3.8/kvikio/_version.py to '0+unknown'
  running build_ext
  building 'kvikio._lib.libkvikio' extension
  creating build/temp.linux-x86_64-3.8
  creating build/temp.linux-x86_64-3.8/kvikio
  creating build/temp.linux-x86_64-3.8/kvikio/_lib
  gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -fwrapv -O3 -Wall -I/home/linuxbrew/.linuxbrew/opt/zlib -I/home/linuxbrew/.linuxbrew/opt/zlib -fPIC -O3 -I/home/gbae/.pyenv/versions/3.8.12/include -I/usr/local/cuda/include -I/home/gbae/.pyenv/versions/cucim-3.8/include -I/home/gbae/.pyenv/versions/3.8.12/include/python3.8 -c kvikio/_lib/libkvikio.cpp -o build/temp.linux-x86_64-3.8/kvikio/_lib/libkvikio.o -std=c++17
  kvikio/_lib/libkvikio.cpp:752:10: fatal error: kvikio/utils.hpp: No such file or directory
    752 | #include <kvikio/utils.hpp>
        |          ^~~~~~~~~~~~~~~~~~
  compilation terminated.
  error: command '/usr/bin/gcc' failed with exit code 1
  ----------------------------------------
  ERROR: Failed building wheel for kvikio
Failed to build kvikio
ERROR: Could not build wheels for kvikio which use PEP 517 and cannot be installed directly
WARNING: You are using pip version 21.1.1; however, version 22.0.3 is available.
You should consider upgrading via the '/home/gbae/.pyenv/versions/cucim-3.8/bin/python -m pip install --upgrade pip' command.

Couldn't find libnvidia-ml.so

❯ cd python
❯ python -m pip install .
Looking in indexes: https://pypi.org/simple, https://pypi.ngc.nvidia.com
Processing /home/gbae/repo/kvikio/python
  DEPRECATION: A future pip version will change local packages to be built in-place without first copying to a temporary directory. We recommend you use --use-feature=in-tree-build to test your packages with this new behavior before it becomes the default.
   pip 21.3 will remove support for this functionality. You can find discussion regarding this at https://github.com/pypa/pip/issues/7555.
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
    Preparing wheel metadata ... done
Collecting cython
  Downloading Cython-0.29.28-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.manylinux_2_24_x86_64.whl (1.9 MB)
     |████████████████████████████████| 1.9 MB 679 kB/s
Building wheels for collected packages: kvikio
  Building wheel for kvikio (PEP 517) ... error
  ERROR: Command errored out with exit status 1:
   command: /home/gbae/.pyenv/versions/cucim-3.8/bin/python /home/gbae/.pyenv/versions/cucim-3.8/lib/python3.8/site-packages/pip/_vendor/pep517/in_process/_in_process.py build_wheel /tmp/tmpio38_f81
       cwd: /tmp/pip-req-build-nnr151e7
  Complete output (62 lines):
  running bdist_wheel
  running build
  running build_py
  creating build
  creating build/lib.linux-x86_64-3.8
  creating build/lib.linux-x86_64-3.8/kvikio
  copying kvikio/cufile.py -> build/lib.linux-x86_64-3.8/kvikio
  copying kvikio/zarr.py -> build/lib.linux-x86_64-3.8/kvikio
  copying kvikio/thread_pool.py -> build/lib.linux-x86_64-3.8/kvikio
  copying kvikio/_version.py -> build/lib.linux-x86_64-3.8/kvikio
  copying kvikio/__init__.py -> build/lib.linux-x86_64-3.8/kvikio
  creating build/lib.linux-x86_64-3.8/kvikio/_lib
  copying kvikio/_lib/__init__.py -> build/lib.linux-x86_64-3.8/kvikio/_lib
  copying kvikio/_lib/arr.pyi -> build/lib.linux-x86_64-3.8/kvikio/_lib
  UPDATING build/lib.linux-x86_64-3.8/kvikio/_version.py
  set build/lib.linux-x86_64-3.8/kvikio/_version.py to '0+unknown'
  running build_ext
  building 'kvikio._lib.libkvikio' extension
  creating build/temp.linux-x86_64-3.8
  creating build/temp.linux-x86_64-3.8/kvikio
  creating build/temp.linux-x86_64-3.8/kvikio/_lib
  gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -fwrapv -O3 -Wall -I/home/linuxbrew/.linuxbrew/opt/zlib -I/home/linuxbrew/.linuxbrew/opt/zlib -fPIC -O3 -I/home/gbae/.pyenv/versions/3.8.12/include -I/home/gbae/repo/kvikio/cpp/include -I/usr/local/cuda/include -I/home/gbae/.pyenv/versions/cucim-3.8/include -I/home/gbae/.pyenv/versions/3.8.12/include/python3.8 -c kvikio/_lib/libkvikio.cpp -o build/temp.linux-x86_64-3.8/kvikio/_lib/libkvikio.o -std=c++17
  kvikio/_lib/libkvikio.cpp:15862:20: warning: ‘__pyx_mdef___pyx_memoryviewslice_3__setstate_cython__’ defined but not used [-Wunused-variable]
  15862 | static PyMethodDef __pyx_mdef___pyx_memoryviewslice_3__setstate_cython__ = {"__setstate_cython__", (PyCFunction)__pyx_pw___pyx_memoryviewslice_3__setstate_cython__, METH_O, 0};
        |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  kvikio/_lib/libkvikio.cpp:15804:20: warning: ‘__pyx_mdef___pyx_memoryviewslice_1__reduce_cython__’ defined but not used [-Wunused-variable]
  15804 | static PyMethodDef __pyx_mdef___pyx_memoryviewslice_1__reduce_cython__ = {"__reduce_cython__", (PyCFunction)__pyx_pw___pyx_memoryviewslice_1__reduce_cython__, METH_NOARGS, 0};
        |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  kvikio/_lib/libkvikio.cpp:12959:20: warning: ‘__pyx_mdef___pyx_memoryview_3__setstate_cython__’ defined but not used [-Wunused-variable]
  12959 | static PyMethodDef __pyx_mdef___pyx_memoryview_3__setstate_cython__ = {"__setstate_cython__", (PyCFunction)__pyx_pw___pyx_memoryview_3__setstate_cython__, METH_O, 0};
        |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  kvikio/_lib/libkvikio.cpp:12901:20: warning: ‘__pyx_mdef___pyx_memoryview_1__reduce_cython__’ defined but not used [-Wunused-variable]
  12901 | static PyMethodDef __pyx_mdef___pyx_memoryview_1__reduce_cython__ = {"__reduce_cython__", (PyCFunction)__pyx_pw___pyx_memoryview_1__reduce_cython__, METH_NOARGS, 0};
        |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  kvikio/_lib/libkvikio.cpp:12807:20: warning: ‘__pyx_mdef_15View_dot_MemoryView_10memoryview_23copy_fortran’ defined but not used [-Wunused-variable]
  12807 | static PyMethodDef __pyx_mdef_15View_dot_MemoryView_10memoryview_23copy_fortran = {"copy_fortran", (PyCFunction)__pyx_memoryview_copy_fortran, METH_NOARGS, 0};
        |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  kvikio/_lib/libkvikio.cpp:12712:20: warning: ‘__pyx_mdef_15View_dot_MemoryView_10memoryview_21copy’ defined but not used [-Wunused-variable]
  12712 | static PyMethodDef __pyx_mdef_15View_dot_MemoryView_10memoryview_21copy = {"copy", (PyCFunction)__pyx_memoryview_copy, METH_NOARGS, 0};
        |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  kvikio/_lib/libkvikio.cpp:12635:20: warning: ‘__pyx_mdef_15View_dot_MemoryView_10memoryview_19is_f_contig’ defined but not used [-Wunused-variable]
  12635 | static PyMethodDef __pyx_mdef_15View_dot_MemoryView_10memoryview_19is_f_contig = {"is_f_contig", (PyCFunction)__pyx_memoryview_is_f_contig, METH_NOARGS, 0};
        |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  kvikio/_lib/libkvikio.cpp:12558:20: warning: ‘__pyx_mdef_15View_dot_MemoryView_10memoryview_17is_c_contig’ defined but not used [-Wunused-variable]
  12558 | static PyMethodDef __pyx_mdef_15View_dot_MemoryView_10memoryview_17is_c_contig = {"is_c_contig", (PyCFunction)__pyx_memoryview_is_c_contig, METH_NOARGS, 0};
        |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  kvikio/_lib/libkvikio.cpp:8685:20: warning: ‘__pyx_mdef___pyx_MemviewEnum_3__setstate_cython__’ defined but not used [-Wunused-variable]
   8685 | static PyMethodDef __pyx_mdef___pyx_MemviewEnum_3__setstate_cython__ = {"__setstate_cython__", (PyCFunction)__pyx_pw___pyx_MemviewEnum_3__setstate_cython__, METH_O, 0};
        |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  kvikio/_lib/libkvikio.cpp:8449:20: warning: ‘__pyx_mdef___pyx_MemviewEnum_1__reduce_cython__’ defined but not used [-Wunused-variable]
   8449 | static PyMethodDef __pyx_mdef___pyx_MemviewEnum_1__reduce_cython__ = {"__reduce_cython__", (PyCFunction)__pyx_pw___pyx_MemviewEnum_1__reduce_cython__, METH_NOARGS, 0};
        |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  kvikio/_lib/libkvikio.cpp:8071:20: warning: ‘__pyx_mdef___pyx_array_3__setstate_cython__’ defined but not used [-Wunused-variable]
   8071 | static PyMethodDef __pyx_mdef___pyx_array_3__setstate_cython__ = {"__setstate_cython__", (PyCFunction)__pyx_pw___pyx_array_3__setstate_cython__, METH_O, 0};
        |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  kvikio/_lib/libkvikio.cpp:8013:20: warning: ‘__pyx_mdef___pyx_array_1__reduce_cython__’ defined but not used [-Wunused-variable]
   8013 | static PyMethodDef __pyx_mdef___pyx_array_1__reduce_cython__ = {"__reduce_cython__", (PyCFunction)__pyx_pw___pyx_array_1__reduce_cython__, METH_NOARGS, 0};
        |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  g++ -pthread -shared -L/home/linuxbrew/.linuxbrew/opt/readline/lib -L/home/gbae/.pyenv/versions/3.8.12/lib -L/home/linuxbrew/.linuxbrew/lib -L/home/linuxbrew/.linuxbrew/opt/readline/lib -L/home/gbae/.pyenv/versions/3.8.12/lib -L/home/linuxbrew/.linuxbrew/lib build/temp.linux-x86_64-3.8/kvikio/_lib/libkvikio.o -L/home/gbae/.pyenv/versions/cucim-3.8/lib/python3.8/site-packages -L/usr/local/cuda/lib64 -lcuda -lnvidia-ml -lcufile -o build/lib.linux-x86_64-3.8/kvikio/_lib/libkvikio.cpython-38-x86_64-linux-gnu.so
  /home/linuxbrew/.linuxbrew/bin/ld: cannot find -lnvidia-ml
  collect2: error: ld returned 1 exit status
  error: command '/usr/bin/g++' failed with exit code 1
  ----------------------------------------
  ERROR: Failed building wheel for kvikio

I workarounded the issue through the following change.
--- a/python/setup.py
+++ b/python/setup.py
@@ -45,8 +45,8 @@ this_setup_scrip_dir = os.path.dirname(os.path.realpath(__file__))

 # Throughout the script, we will populate `include_dirs`,
 # `library_dirs` and `depends`.
-include_dirs = [os.path.dirname(sysconfig.get_path("include"))]
-library_dirs = [get_python_lib()]
+include_dirs = [os.path.dirname(sysconfig.get_path("include"))] + ["/home/gbae/repo/kvikio/cpp/include"]
+library_dirs = [get_python_lib(), "/usr/local/cuda/lib64/stubs"]
 extra_objects = []
 depends = []  # Files to trigger rebuild when modified

We are working on CI build setup and package builds in PR ( https://github.com/rapidsai/kvikio/pull/5 ). Maybe we can just wait for that? If not, that should at least have some more info (admittedly in code form) for doing builds.

We are working on CI build setup and package builds in PR ( #5 ). Maybe we can just wait for that? If not, that should at least have some more info (admittedly in code form) for doing builds.

@jakirkham
With GPUCI, those issues won't happen because

it first build libkvikio and install it in the conda environment so kvikio header is in Conda environment's system include path.

For users who doesn't build libkvikio, something like below is needed
+include_dirs = [os.path.dirname(sysconfig.get_path("include"))] + [os.path.join(os.path.pardir(os.path.dirname(os.path.realpath(__file__))), 'cpp', 'include']

folder to libnvidia-ml.so looks available in LD_LIBRARY_PATH when using Conda environment with CUDA Toolkit.

For users who doesn't use Conda environment, library path to libnvidia-ml.so is needed.
+library_dirs = [get_python_lib(), "/usr/local/cuda/lib64/stubs"]

@gigony with https://github.com/rapidsai/kvikio/pull/20, the linking issue should be fixed but I cannot reproduce the include issue.
Is the setup.py file moved out of the source tree? Otherwise kvikio_include_dir in the following should point to the header dir right?
https://github.com/rapidsai/kvikio/blob/4d9f905aa3dbdad5f2e8e78f6305ef40d2791ba2/python/setup.py#L79

@gigony with #20, the linking issue should be fixed but I cannot reproduce the include issue.
Is the setup.py file moved out of the source tree? Otherwise kvikio_include_dir in the following should point to the header dir right?
https://github.com/rapidsai/kvikio/blob/4d9f905aa3dbdad5f2e8e78f6305ef40d2791ba2/python/setup.py#L79

source code is copied to temporary folder (such as  /tmp/pip-req-build-zy15kbon) for build and it is not accessible through the path({this_setup_scrip_dir}/../cpp/include).

❯ pip install .
Looking in indexes: https://pypi.org/simple, https://pypi.ngc.nvidia.com
Processing /home/gbae/repo/kvikio/python
  DEPRECATION: A future pip version will change local packages to be built in-place without first copying to a temporary directory. We recommend you use --use-feature=in-tree-build to test your packages with this new behavior before it becomes the default.
   pip 21.3 will remove support for this functionality. You can find discussion regarding this at https://github.com/pypa/pip/issues/7555.
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
    Preparing wheel metadata ... done
Requirement already satisfied: cython in /home/gbae/.pyenv/versions/3.8.12/envs/cucim-3.8/lib/python3.8/site-packages (from kvikio==0+unknown) (0.29.28)
Building wheels for collected packages: kvikio
  Building wheel for kvikio (PEP 517) ... error
  ERROR: Command errored out with exit status 1:
   command: /home/gbae/.pyenv/versions/3.8.12/envs/cucim-3.8/bin/python3.8 /home/gbae/.pyenv/versions/3.8.12/envs/cucim-3.8/lib/python3.8/site-packages/pip/_vendor/pep517/in_process/_in_process.py build_wheel /tmp/tmpw2uvh1qf
       cwd: /tmp/pip-req-build-zy15kbon
  Complete output (29 lines):
  # /tmp/pip-req-build-zy15kbon
  running bdist_wheel
  running build
  running build_py
  creating build
  creating build/lib.linux-x86_64-3.8
  creating build/lib.linux-x86_64-3.8/kvikio
  copying kvikio/cufile.py -> build/lib.linux-x86_64-3.8/kvikio
  copying kvikio/zarr.py -> build/lib.linux-x86_64-3.8/kvikio
  copying kvikio/config.py -> build/lib.linux-x86_64-3.8/kvikio
  copying kvikio/thread_pool.py -> build/lib.linux-x86_64-3.8/kvikio
  copying kvikio/_version.py -> build/lib.linux-x86_64-3.8/kvikio
  copying kvikio/__init__.py -> build/lib.linux-x86_64-3.8/kvikio
  creating build/lib.linux-x86_64-3.8/kvikio/_lib
  copying kvikio/_lib/__init__.py -> build/lib.linux-x86_64-3.8/kvikio/_lib
  copying kvikio/_lib/arr.pyi -> build/lib.linux-x86_64-3.8/kvikio/_lib
  UPDATING build/lib.linux-x86_64-3.8/kvikio/_version.py
  set build/lib.linux-x86_64-3.8/kvikio/_version.py to '0+unknown'
  running build_ext
  building 'kvikio._lib.libkvikio' extension
  creating build/temp.linux-x86_64-3.8
  creating build/temp.linux-x86_64-3.8/kvikio
  creating build/temp.linux-x86_64-3.8/kvikio/_lib
  gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -fwrapv -O3 -Wall -I/home/linuxbrew/.linuxbrew/opt/zlib -I/home/linuxbrew/.linuxbrew/opt/zlib -fPIC -O3 -I/home/gbae/.pyenv/versions/3.8.12/include -I/usr/local/cuda/include -I/home/gbae/.pyenv/versions/3.8.12/envs/cucim-3.8/include -I/home/gbae/.pyenv/versions/3.8.12/include/python3.8 -c kvikio/_lib/libkvikio.cpp -o build/temp.linux-x86_64-3.8/kvikio/_lib/libkvikio.o -std=c++17
  kvikio/_lib/libkvikio.cpp:751:10: fatal error: kvikio/utils.hpp: No such file or directory
    751 | #include <kvikio/utils.hpp>
        |          ^~~~~~~~~~~~~~~~~~
  compilation terminated.
  error: command '/usr/bin/gcc' failed with exit code 1
  ----------------------------------------
  ERROR: Failed building wheel for kvikio
Failed to build kvikio
ERROR: Could not build wheels for kvikio which use PEP 517 and cannot be installed directly
WARNING: You are using pip version 21.1.1; however, version 22.0.4 is available.
You should consider upgrading via the '/home/gbae/.pyenv/versions/3.8.12/envs/cucim-3.8/bin/python3.8 -m pip install --upgrade pip' command.

I think #32 should have resolved the issue of finding libkvikio if it is already installed by passing a CMake variable like so python setup.py install -- -DFIND_KVIKIO_CPP=ON. I don't know where the libnvidia-ml.so library dependency is coming from though or what should be responsible for finding it.

We don’t depend on nvidia-ml.so anymore so that shouldn’t be a problem.
On Tue, 29 Mar 2022 at 19.08, Vyas Ramasubramani @.***>
wrote:

I think #32 https://github.com/rapidsai/kvikio/pull/32 should have
resolved the issue of finding libkvikio if it is already installed by
passing a CMake variable like so python setup.py install --
-DFIND_KVIKIO_CPP=ON. I don't know where the libnvidia-ml.so library
dependency is coming from though or what should be responsible for finding
it.
—
Reply to this email directly, view it on GitHub
https://github.com/rapidsai/kvikio/issues/12#issuecomment-1082142399,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAH6FQCSXZ656CJQDLWIDJLVCM2G7ANCNFSM5PFVQCGQ
.
You are receiving this because you commented.Message ID:
@.***>

Still had an issue with the temporary directory.

Log

❯ pip install --force-reinstall python/
Processing ./python
  DEPRECATION: A future pip version will change local packages to be built in-place without first copying to a temporary directory. We recommend you use --use-feature=in-tree-build to test your packages with this new behavior before it becomes the default.
   pip 21.3 will remove support for this functionality. You can find discussion regarding this at https://github.com/pypa/pip/issues/7555.
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
    Preparing wheel metadata ... done
Collecting numpy
  Using cached numpy-1.22.3-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (16.8 MB)
Building wheels for collected packages: kvikio
  Building wheel for kvikio (PEP 517) ... error
  ERROR: Command errored out with exit status 1:
   command: /home/gbae/.pyenv/versions/3.9.10/envs/cucim-3.9/bin/python3.9 /home/gbae/.pyenv/versions/3.9.10/envs/cucim-3.9/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py build_wheel /tmp/tmpgp2jqwqk
       cwd: /tmp/pip-req-build-o8r5x4le
  Complete output (108 lines):
  Not searching for unused variables given on the command line.
  -- The C compiler identification is GNU 9.4.0
  -- Detecting C compiler ABI info
  -- Detecting C compiler ABI info - done
  -- Check for working C compiler: /usr/bin/cc - skipped
  -- Detecting C compile features
  -- Detecting C compile features - done
  -- The CXX compiler identification is GNU 9.4.0
  -- Detecting CXX compiler ABI info
  -- Detecting CXX compiler ABI info - done
  -- Check for working CXX compiler: /usr/bin/c++ - skipped
  -- Detecting CXX compile features
  -- Detecting CXX compile features - done
  -- Configuring done
  -- Generating done
  -- Build files have been written to: /tmp/pip-req-build-o8r5x4le/_cmake_test_compile/build
  -- The C compiler identification is GNU 9.4.0
  -- The CXX compiler identification is GNU 9.4.0
  -- The CUDA compiler identification is NVIDIA 11.6.112
  -- Detecting C compiler ABI info
  -- Detecting C compiler ABI info - done
  -- Check for working C compiler: /usr/bin/cc - skipped
  -- Detecting C compile features
  -- Detecting C compile features - done
  -- Detecting CXX compiler ABI info
  -- Detecting CXX compiler ABI info - done
  -- Check for working CXX compiler: /usr/bin/c++ - skipped
  -- Detecting CXX compile features
  -- Detecting CXX compile features - done
  -- Detecting CUDA compiler ABI info
  -- Detecting CUDA compiler ABI info - done
  -- Check for working CUDA compiler: /usr/local/cuda/bin/nvcc - skipped
  -- Detecting CUDA compile features
  -- Detecting CUDA compile features - done
  -- Found PythonInterp: /home/gbae/.pyenv/versions/3.9.10/envs/cucim-3.9/bin/python3.9 (found version "3.9.10")
  -- Found PythonLibs: /home/gbae/.pyenv/versions/3.9.10/lib/libpython3.9.a (found version "3.9.10")
  -- Found Cython: /tmp/pip-build-env-p7ijqr06/overlay/bin/cython
  CMake Error at CMakeLists.txt:38 (include):
    include could not find requested file:

      ../cpp/cmake/Modules/FindcuFile.cmake

  -- Found CUDAToolkit: /usr/local/cuda/include (found version "11.6.112")
  -- Looking for pthread.h
  -- Looking for pthread.h - found
  -- Performing Test CMAKE_HAVE_LIBC_PTHREAD
  -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
  -- Looking for pthread_create in pthreads
  -- Looking for pthread_create in pthreads - not found
  -- Looking for pthread_create in pthread
  -- Looking for pthread_create in pthread - found
  -- Found Threads: TRUE
  CMake Error at CMakeLists.txt:52 (add_subdirectory):
    add_subdirectory given source "../cpp" which is not an existing directory.

  CMake Error at cmake/thirdparty/get_nvcomp.cmake:19 (rapids_cpm_find):
    Unknown CMake command "rapids_cpm_find".
  Call Stack (most recent call first):
    cmake/thirdparty/get_nvcomp.cmake:40 (find_and_configure_nvcomp)
    cmake/CMakeLists.txt:15 (include)

  -- Configuring incomplete, errors occurred!
  See also "/tmp/pip-req-build-o8r5x4le/_skbuild/linux-x86_64-3.9/cmake-build/CMakeFiles/CMakeOutput.log".
  See also "/tmp/pip-req-build-o8r5x4le/_skbuild/linux-x86_64-3.9/cmake-build/CMakeFiles/CMakeError.log".
    File "/tmp/pip-build-env-p7ijqr06/overlay/lib/python3.9/site-packages/skbuild/setuptools_wrap.py", line 588, in setup
      env = cmkr.configure(cmake_args,
    File "/tmp/pip-build-env-p7ijqr06/overlay/lib/python3.9/site-packages/skbuild/cmaker.py", line 289, in configure
      raise SKBuildError(

  --------------------------------------------------------------------------------
  -- Trying "Ninja" generator
  --------------------------------
  ---------------------------
  ----------------------
  -----------------
  ------------
  -------
  --
  --
  -------
  ------------
  -----------------
  ----------------------
  ---------------------------
  --------------------------------
  -- Trying "Ninja" generator - success
  --------------------------------------------------------------------------------

  Configuring Project
    Working directory:
      /tmp/pip-req-build-o8r5x4le/_skbuild/linux-x86_64-3.9/cmake-build
    Command:
      cmake /tmp/pip-req-build-o8r5x4le -G Ninja -DCMAKE_INSTALL_PREFIX:PATH=/tmp/pip-req-build-o8r5x4le/_skbuild/linux-x86_64-3.9/cmake-install -DPYTHON_EXECUTABLE:FILEPATH=/home/gbae/.pyenv/versions/3.9.10/envs/cucim-3.9/bin/python3.9 -DPYTHON_VERSION_STRING:STRING=3.9.10 -DPYTHON_INCLUDE_DIR:PATH=/home/gbae/.pyenv/versions/3.9.10/include/python3.9 -DPYTHON_LIBRARY:FILEPATH=/home/gbae/.pyenv/versions/3.9.10/lib/libpython3.9.a -DSKBUILD:INTERNAL=TRUE -DCMAKE_MODULE_PATH:PATH=/tmp/pip-build-env-p7ijqr06/overlay/lib/python3.9/site-packages/skbuild/resources/cmake -DCMAKE_MAKE_PROGRAM:FILEPATH=/tmp/pip-build-env-p7ijqr06/overlay/lib/python3.9/site-packages/ninja/data/bin/ninja -DCMAKE_BUILD_TYPE:STRING=Release

  Traceback (most recent call last):

  An error occurred while configuring with CMake.
    Command:
      cmake /tmp/pip-req-build-o8r5x4le -G Ninja -DCMAKE_INSTALL_PREFIX:PATH=/tmp/pip-req-build-o8r5x4le/_skbuild/linux-x86_64-3.9/cmake-install -DPYTHON_EXECUTABLE:FILEPATH=/home/gbae/.pyenv/versions/3.9.10/envs/cucim-3.9/bin/python3.9 -DPYTHON_VERSION_STRING:STRING=3.9.10 -DPYTHON_INCLUDE_DIR:PATH=/home/gbae/.pyenv/versions/3.9.10/include/python3.9 -DPYTHON_LIBRARY:FILEPATH=/home/gbae/.pyenv/versions/3.9.10/lib/libpython3.9.a -DSKBUILD:INTERNAL=TRUE -DCMAKE_MODULE_PATH:PATH=/tmp/pip-build-env-p7ijqr06/overlay/lib/python3.9/site-packages/skbuild/resources/cmake -DCMAKE_MAKE_PROGRAM:FILEPATH=/tmp/pip-build-env-p7ijqr06/overlay/lib/python3.9/site-packages/ninja/data/bin/ninja -DCMAKE_BUILD_TYPE:STRING=Release
    Source directory:
      /tmp/pip-req-build-o8r5x4le
    Working directory:
      /tmp/pip-req-build-o8r5x4le/_skbuild/linux-x86_64-3.9/cmake-build
  Please see CMake's output for more information.
  ----------------------------------------
  ERROR: Failed building wheel for kvikio
Failed to build kvikio
ERROR: Could not build wheels for kvikio which use PEP 517 and cannot be installed directly
WARNING: You are using pip version 21.2.4; however, version 22.0.4 is available.
You should consider upgrading via the '/home/gbae/.pyenv/versions/3.9.10/envs/cucim-3.9/bin/python3.9 -m pip install --upgrade pip' command.

  ~/repo/kvikio   branch-22.04 ?3 ─────────────────────────────────────────────────────────────────────────────────────────────────  9s  cucim-3.9 3.9.10  18:48:05

  DEPRECATION: A future pip version will change local packages to be built in-place without first copying to a temporary directory. We recommend you use --use-feature=in-tree-build to test your packages with this new behavior before it becomes the default.
   pip 21.3 will remove support for this functionality. You can find discussion regarding this at https://github.com/pypa/pip/issues/7555.

Adding --use-feature=in-tree-build solved the issue and I can see it is building.
❯ pip install --force-reinstall --use-feature=in-tree-build python/
Processing ./python
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
    Preparing wheel metadata ... done
Collecting numpy
  Using cached numpy-1.22.3-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (16.8 MB)
Building wheels for collected packages: kvikio
  Building wheel for kvikio (PEP 517) ... done
  Created wheel for kvikio: filename=kvikio-22.4.0a0+58.g568070b-cp39-cp39-linux_x86_64.whl size=27335903 sha256=f1cc2ed81215583196ba7f06fd52b87d00fab194cb6406b7276870d605376a74
  Stored in directory: /tmp/pip-ephem-wheel-cache-ynq0e0xj/wheels/07/71/a5/3d678f817af5ce7121ebedb7ed139e02a8dd68c0ec90329c09
Successfully built kvikio
Installing collected packages: numpy, kvikio
  Attempting uninstall: numpy
    Found existing installation: numpy 1.22.3
    Uninstalling numpy-1.22.3:
      Successfully uninstalled numpy-1.22.3
Successfully installed kvikio-22.4.0a0+58.g568070b numpy-1.22.3
WARNING: You are using pip version 21.2.4; however, version 22.0.4 is available.
You should consider upgrading via the '/home/gbae/.pyenv/versions/3.9.10/bin/python3.9 -m pip install --upgrade pip' command.

Using --no-build-isolation caused the following error.
❯ pip install --force-reinstall --no-build-isolation python/
Processing ./python
  DEPRECATION: A future pip version will change local packages to be built in-place without first copying to a temporary directory. We recommend you use --use-feature=in-tree-build to test your packages with this new behavior before it becomes the default.
   pip 21.3 will remove support for this functionality. You can find discussion regarding this at https://github.com/pypa/pip/issues/7555.
    Preparing wheel metadata ... error
    ERROR: Command errored out with exit status 1:
     command: /home/gbae/.pyenv/versions/3.9.10/bin/python3.9 /home/gbae/.pyenv/versions/3.9.10/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py prepare_metadata_for_build_wheel /tmp/tmpeaahxtx1
         cwd: /tmp/pip-req-build-i_uvx97q
    Complete output (16 lines):
    Traceback (most recent call last):
      File "/home/gbae/.pyenv/versions/3.9.10/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 349, in <module>
        main()
      File "/home/gbae/.pyenv/versions/3.9.10/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 331, in main
        json_out['return_val'] = hook(**hook_input['kwargs'])
      File "/home/gbae/.pyenv/versions/3.9.10/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 151, in prepare_metadata_for_build_wheel
        return hook(metadata_directory, config_settings)
      File "/home/gbae/.pyenv/versions/3.9.10/lib/python3.9/site-packages/setuptools/build_meta.py", line 166, in prepare_metadata_for_build_wheel
        self.run_setup()
      File "/home/gbae/.pyenv/versions/3.9.10/lib/python3.9/site-packages/setuptools/build_meta.py", line 258, in run_setup
        super(_BuildMetaLegacyBackend,
      File "/home/gbae/.pyenv/versions/3.9.10/lib/python3.9/site-packages/setuptools/build_meta.py", line 150, in run_setup
        exec(compile(code, __file__, 'exec'), locals())
      File "setup.py", line 5, in <module>
        from skbuild import setup
    ModuleNotFoundError: No module named 'skbuild'
    ----------------------------------------
WARNING: Discarding file:///home/gbae/repo/kvikio/python. Command errored out with exit status 1: /home/gbae/.pyenv/versions/3.9.10/bin/python3.9 /home/gbae/.pyenv/versions/3.9.10/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py prepare_metadata_for_build_wheel /tmp/tmpeaahxtx1 Check the logs for full command output.
ERROR: Command errored out with exit status 1: /home/gbae/.pyenv/versions/3.9.10/bin/python3.9 /home/gbae/.pyenv/versions/3.9.10/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py prepare_metadata_for_build_wheel /tmp/tmpeaahxtx1 Check the logs for full command output.
WARNING: You are using pip version 21.2.4; however, version 22.0.4 is available.
You should consider upgrading via the '/home/gbae/.pyenv/versions/3.9.10/bin/python3.9 -m pip install --upgrade pip' command.
❯ pip install --force-reinstall --no-build-isolation python/
Processing ./python
  DEPRECATION: A future pip version will change local packages to be built in-place without first copying to a temporary directory. We recommend you use --use-feature=in-tree-build to test your packages with this new behavior before it becomes the default.
   pip 21.3 will remove support for this functionality. You can find discussion regarding this at https://github.com/pypa/pip/issues/7555.
    Preparing wheel metadata ... error
    ERROR: Command errored out with exit status 1:
     command: /home/gbae/.pyenv/versions/3.9.10/bin/python3.9 /home/gbae/.pyenv/versions/3.9.10/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py prepare_metadata_for_build_wheel /tmp/tmpl5atu4v4
         cwd: /tmp/pip-req-build-82p_28gm
    Complete output (16 lines):
    Traceback (most recent call last):
      File "/home/gbae/.pyenv/versions/3.9.10/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 349, in <module>
        main()
      File "/home/gbae/.pyenv/versions/3.9.10/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 331, in main
        json_out['return_val'] = hook(**hook_input['kwargs'])
      File "/home/gbae/.pyenv/versions/3.9.10/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 151, in prepare_metadata_for_build_wheel
        return hook(metadata_directory, config_settings)
      File "/home/gbae/.pyenv/versions/3.9.10/lib/python3.9/site-packages/setuptools/build_meta.py", line 166, in prepare_metadata_for_build_wheel
        self.run_setup()
      File "/home/gbae/.pyenv/versions/3.9.10/lib/python3.9/site-packages/setuptools/build_meta.py", line 258, in run_setup
        super(_BuildMetaLegacyBackend,
      File "/home/gbae/.pyenv/versions/3.9.10/lib/python3.9/site-packages/setuptools/build_meta.py", line 150, in run_setup
        exec(compile(code, __file__, 'exec'), locals())
      File "setup.py", line 5, in <module>
        from skbuild import setup
    ModuleNotFoundError: No module named 'skbuild'
    ----------------------------------------
WARNING: Discarding file:///home/gbae/repo/kvikio/python. Command errored out with exit status 1: /home/gbae/.pyenv/versions/3.9.10/bin/python3.9 /home/gbae/.pyenv/versions/3.9.10/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py prepare_metadata_for_build_wheel /tmp/tmpl5atu4v4 Check the logs for full command output.
ERROR: Command errored out with exit status 1: /home/gbae/.pyenv/versions/3.9.10/bin/python3.9 /home/gbae/.pyenv/versions/3.9.10/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py prepare_metadata_for_build_wheel /tmp/tmpl5atu4v4 Check the logs for full command output.
WARNING: You are using pip version 21.2.4; however, version 22.0.4 is available.
You should consider upgrading via the '/home/gbae/.pyenv/versions/3.9.10/bin/python3.9 -m pip install --upgrade pip' command.

The first failure just seems like something isn't getting copied over. Maybe there is some flag we need to add to scikit-build or we need to add files to MANIFEST.in (though the latter would cause these to also get packaged, which we may not want). This probably deserves a closer look.
With the last failure, this seems to be expected. Kvikio has build requirements specified according PEP 518. However passing --no-build-isolation to pip disables installing these build dependencies (quote from the docs below).

Disable isolation when building a modern source distribution. Build dependencies specified by PEP 518 must be already installed if this option is used.

Maybe the answer here is just to build with --use-feature=in-tree-build. Especially since this is the way pip is going anyways. The upside is once pip makes this default no flag will be needed and the build will work. Though looking into the first failure more seems worthwhile.

That ../* path should probably be modified to be relative to PROJECT_SOURCE_DIR (or in this case KvikIO_SOURCE_DIR might be better). That should help resolve the issue.

So poked at this a bit locally in a Docker image. Think it is just a matter of cd-ing into the python/ directory. Once there things seemed to work
$ python -m pip install .
Processing /home/conda/kvikio/python
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Requirement already satisfied: numpy in /opt/conda/envs/bld/lib/python3.9/site-packages (from kvikio==22.4.0a0+59.g44b22f9) (1.22.3)
Building wheels for collected packages: kvikio
  Building wheel for kvikio (pyproject.toml) ... done
  Created wheel for kvikio: filename=kvikio-22.4.0a0+59.g44b22f9-cp39-cp39-linux_x86_64.whl size=27405313 sha256=ac67da534c625f89f44056ac95a62cd1e91497d0368229c52f06b863db93c12c
  Stored in directory: /tmp/pip-ephem-wheel-cache-j9u2twfz/wheels/c6/08/1e/297f350e053242ba2f3a1697624da565aa6b6eea0681989a1e
Successfully built kvikio
Installing collected packages: kvikio
Successfully installed kvikio-22.4.0a0+59.g44b22f9

When you have time, this would be good to retry Gigon, but no rush if you are busy with other things 🙂

Right, I think changing the relative path to be relative to PROJECT_SOURCE_DIR should make that work from out of source as well.

skbuild doesn't remove/update CMakeCache if the environment is changed?
I tried to execute the same command again and I see the following error message.
> pip install --force-reinstall python/

 CMake Error: The current CMakeCache.txt directory /tmp/pip-req-build-z5x0vncg/_skbuild/linux-x86_64-3.9/cmake-build/CMakeCache.txt is different than the directory /home/gbae/repo/kvikio/python/_skbuild/linux-x86_64-3.9/cmake-build where CMakeCache.txt was created. This may result in binaries being created in the wrong place. If you are not sure, reedit the CMakeCache.txt
  CMake Error: The source "/tmp/pip-req-build-z5x0vncg/CMakeLists.txt" does not match the source "/home/gbae/repo/kvikio/python/CMakeLists.txt" used to generate cache.  Re-run cmake with a different source directory.

Executing rm -rf /home/gbae/repo/kvikio/python/_skbuild/linux-x86_64-3.9/cmake-build was needed to pass the error.

 detailed log
> pip install --force-reinstall python/
Processing ./python
  DEPRECATION: A future pip version will change local packages to be built in-place without first copying to a temporary directory. We recommend you use --use-feature=in-tree-build to test your packages with this new behavior before it becomes the default.
   pip 21.3 will remove support for this functionality. You can find discussion regarding this at https://github.com/pypa/pip/issues/7555.
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
    Preparing wheel metadata ... done
Collecting numpy
  Using cached numpy-1.22.3-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (16.8 MB)
Building wheels for collected packages: kvikio
  Building wheel for kvikio (PEP 517) ... error
  ERROR: Command errored out with exit status 1:
   command: /home/gbae/.pyenv/versions/3.9.10/envs/cucim-3.9/bin/python3.9 /home/gbae/.pyenv/versions/3.9.10/envs/cucim-3.9/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py build_wheel /tmp/tmpvj6n4ob2
       cwd: /tmp/pip-req-build-z5x0vncg
  Complete output (59 lines):
  Not searching for unused variables given on the command line.
  -- The C compiler identification is GNU 9.4.0
  -- Detecting C compiler ABI info
  -- Detecting C compiler ABI info - done
  -- Check for working C compiler: /usr/bin/cc - skipped
  -- Detecting C compile features
  -- Detecting C compile features - done
  -- The CXX compiler identification is GNU 9.4.0
  -- Detecting CXX compiler ABI info
  -- Detecting CXX compiler ABI info - done
  -- Check for working CXX compiler: /usr/bin/c++ - skipped
  -- Detecting CXX compile features
  -- Detecting CXX compile features - done
  -- Configuring done
  -- Generating done
  -- Build files have been written to: /tmp/pip-req-build-z5x0vncg/_cmake_test_compile/build
  CMake Error: The current CMakeCache.txt directory /tmp/pip-req-build-z5x0vncg/_skbuild/linux-x86_64-3.9/cmake-build/CMakeCache.txt is different than the directory /home/gbae/repo/kvikio/python/_skbuild/linux-x86_64-3.9/cmake-build where CMakeCache.txt was created. This may result in binaries being created in the wrong place. If you are not sure, reedit the CMakeCache.txt
  CMake Error: The source "/tmp/pip-req-build-z5x0vncg/CMakeLists.txt" does not match the source "/home/gbae/repo/kvikio/python/CMakeLists.txt" used to generate cache.  Re-run cmake with a different source directory.
    File "/tmp/pip-build-env-9hr6w2gs/overlay/lib/python3.9/site-packages/skbuild/setuptools_wrap.py", line 588, in setup
      env = cmkr.configure(cmake_args,
    File "/tmp/pip-build-env-9hr6w2gs/overlay/lib/python3.9/site-packages/skbuild/cmaker.py", line 289, in configure
      raise SKBuildError(

  --------------------------------------------------------------------------------
  -- Trying "Ninja" generator
  --------------------------------
  ---------------------------
  ----------------------
  -----------------
  ------------
  -------
  --
  --
  -------
  ------------
  -----------------
  ----------------------
  ---------------------------
  --------------------------------
  -- Trying "Ninja" generator - success
  --------------------------------------------------------------------------------

  Configuring Project
    Working directory:
      /tmp/pip-req-build-z5x0vncg/_skbuild/linux-x86_64-3.9/cmake-build
    Command:
      cmake /tmp/pip-req-build-z5x0vncg -G Ninja -DCMAKE_INSTALL_PREFIX:PATH=/tmp/pip-req-build-z5x0vncg/_skbuild/linux-x86_64-3.9/cmake-install -DPYTHON_EXECUTABLE:FILEPATH=/home/gbae/.pyenv/versions/3.9.10/envs/cucim-3.9/bin/python3.9 -DPYTHON_VERSION_STRING:STRING=3.9.10 -DPYTHON_INCLUDE_DIR:PATH=/home/gbae/.pyenv/versions/3.9.10/include/python3.9 -DPYTHON_LIBRARY:FILEPATH=/home/gbae/.pyenv/versions/3.9.10/lib/libpython3.9.a -DSKBUILD:INTERNAL=TRUE -DCMAKE_MODULE_PATH:PATH=/tmp/pip-build-env-9hr6w2gs/overlay/lib/python3.9/site-packages/skbuild/resources/cmake -DCMAKE_MAKE_PROGRAM:FILEPATH=/tmp/pip-build-env-9hr6w2gs/overlay/lib/python3.9/site-packages/ninja/data/bin/ninja -DCMAKE_BUILD_TYPE:STRING=Release

  Traceback (most recent call last):

  An error occurred while configuring with CMake.
    Command:
      cmake /tmp/pip-req-build-z5x0vncg -G Ninja -DCMAKE_INSTALL_PREFIX:PATH=/tmp/pip-req-build-z5x0vncg/_skbuild/linux-x86_64-3.9/cmake-install -DPYTHON_EXECUTABLE:FILEPATH=/home/gbae/.pyenv/versions/3.9.10/envs/cucim-3.9/bin/python3.9 -DPYTHON_VERSION_STRING:STRING=3.9.10 -DPYTHON_INCLUDE_DIR:PATH=/home/gbae/.pyenv/versions/3.9.10/include/python3.9 -DPYTHON_LIBRARY:FILEPATH=/home/gbae/.pyenv/versions/3.9.10/lib/libpython3.9.a -DSKBUILD:INTERNAL=TRUE -DCMAKE_MODULE_PATH:PATH=/tmp/pip-build-env-9hr6w2gs/overlay/lib/python3.9/site-packages/skbuild/resources/cmake -DCMAKE_MAKE_PROGRAM:FILEPATH=/tmp/pip-build-env-9hr6w2gs/overlay/lib/python3.9/site-packages/ninja/data/bin/ninja -DCMAKE_BUILD_TYPE:STRING=Release
    Source directory:
      /tmp/pip-req-build-z5x0vncg
    Working directory:
      /tmp/pip-req-build-z5x0vncg/_skbuild/linux-x86_64-3.9/cmake-build
  Please see CMake's output for more information.
  ----------------------------------------
  ERROR: Failed building wheel for kvikio
Failed to build kvikio
ERROR: Could not build wheels for kvikio which use PEP 517 and cannot be installed directly
WARNING: You are using pip version 21.2.4; however, version 22.0.4 is available.
You should consider upgrading via the '/home/gbae/.pyenv/versions/3.9.10/envs/cucim-3.9/bin/python3.9 -m pip install --upgrade pip' command.

Executing at python folder didn't help unless I upgrade pip from 21.2.4 to newer version(22.0.4) or using --use-feature=in-tree-build option.

 detailed log
~/repo/kvikio/python❯ python -m pip install .
Processing /home/gbae/repo/kvikio/python
  DEPRECATION: A future pip version will change local packages to be built in-place without first copying to a temporary directory. We recommend you use --use-feature=in-tree-build to test your packages with this new behavior before it becomes the default.
   pip 21.3 will remove support for this functionality. You can find discussion regarding this at https://github.com/pypa/pip/issues/7555.
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
    Preparing wheel metadata ... done
Requirement already satisfied: numpy in /home/gbae/.pyenv/versions/3.9.10/envs/cucim-3.9/lib/python3.9/site-packages (from kvikio==0+unknown) (1.22.3)
Building wheels for collected packages: kvikio
  Building wheel for kvikio (PEP 517) ... error
  ERROR: Command errored out with exit status 1:
   command: /home/gbae/.pyenv/versions/cucim-3.9/bin/python /home/gbae/.pyenv/versions/cucim-3.9/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py build_wheel /tmp/tmpj3lgrei9
       cwd: /tmp/pip-req-build-ok4ccu2r
  Complete output (108 lines):
  Not searching for unused variables given on the command line.
  -- The C compiler identification is GNU 9.4.0
  -- Detecting C compiler ABI info
  -- Detecting C compiler ABI info - done
  -- Check for working C compiler: /usr/bin/cc - skipped
  -- Detecting C compile features
  -- Detecting C compile features - done
  -- The CXX compiler identification is GNU 9.4.0
  -- Detecting CXX compiler ABI info
  -- Detecting CXX compiler ABI info - done
  -- Check for working CXX compiler: /usr/bin/c++ - skipped
  -- Detecting CXX compile features
  -- Detecting CXX compile features - done
  -- Configuring done
  -- Generating done
  -- Build files have been written to: /tmp/pip-req-build-ok4ccu2r/_cmake_test_compile/build
  -- The C compiler identification is GNU 9.4.0
  -- The CXX compiler identification is GNU 9.4.0
  -- The CUDA compiler identification is NVIDIA 11.6.112
  -- Detecting C compiler ABI info
  -- Detecting C compiler ABI info - done
  -- Check for working C compiler: /usr/bin/cc - skipped
  -- Detecting C compile features
  -- Detecting C compile features - done
  -- Detecting CXX compiler ABI info
  -- Detecting CXX compiler ABI info - done
  -- Check for working CXX compiler: /usr/bin/c++ - skipped
  -- Detecting CXX compile features
  -- Detecting CXX compile features - done
  -- Detecting CUDA compiler ABI info
  -- Detecting CUDA compiler ABI info - done
  -- Check for working CUDA compiler: /usr/local/cuda/bin/nvcc - skipped
  -- Detecting CUDA compile features
  -- Detecting CUDA compile features - done
  -- Found PythonInterp: /home/gbae/.pyenv/versions/cucim-3.9/bin/python (found version "3.9.10")
  -- Found PythonLibs: /home/gbae/.pyenv/versions/3.9.10/lib/libpython3.9.a (found version "3.9.10")
  -- Found Cython: /tmp/pip-build-env-jzz17i2u/overlay/bin/cython
  CMake Error at CMakeLists.txt:38 (include):
    include could not find requested file:

      ../cpp/cmake/Modules/FindcuFile.cmake

  -- Found CUDAToolkit: /usr/local/cuda/include (found version "11.6.112")
  -- Looking for pthread.h
  -- Looking for pthread.h - found
  -- Performing Test CMAKE_HAVE_LIBC_PTHREAD
  -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
  -- Looking for pthread_create in pthreads
  -- Looking for pthread_create in pthreads - not found
  -- Looking for pthread_create in pthread
  -- Looking for pthread_create in pthread - found
  -- Found Threads: TRUE
  CMake Error at CMakeLists.txt:52 (add_subdirectory):
    add_subdirectory given source "../cpp" which is not an existing directory.

  CMake Error at cmake/thirdparty/get_nvcomp.cmake:19 (rapids_cpm_find):
    Unknown CMake command "rapids_cpm_find".
  Call Stack (most recent call first):
    cmake/thirdparty/get_nvcomp.cmake:40 (find_and_configure_nvcomp)
    cmake/CMakeLists.txt:15 (include)

  -- Configuring incomplete, errors occurred!
  See also "/tmp/pip-req-build-ok4ccu2r/_skbuild/linux-x86_64-3.9/cmake-build/CMakeFiles/CMakeOutput.log".
  See also "/tmp/pip-req-build-ok4ccu2r/_skbuild/linux-x86_64-3.9/cmake-build/CMakeFiles/CMakeError.log".
    File "/tmp/pip-build-env-jzz17i2u/overlay/lib/python3.9/site-packages/skbuild/setuptools_wrap.py", line 588, in setup
      env = cmkr.configure(cmake_args,
    File "/tmp/pip-build-env-jzz17i2u/overlay/lib/python3.9/site-packages/skbuild/cmaker.py", line 289, in configure
      raise SKBuildError(

  --------------------------------------------------------------------------------
  -- Trying "Ninja" generator
  --------------------------------
  ---------------------------
  ----------------------
  -----------------
  ------------
  -------
  --
  --
  -------
  ------------
  -----------------
  ----------------------
  ---------------------------
  --------------------------------
  -- Trying "Ninja" generator - success
  --------------------------------------------------------------------------------

  Configuring Project
    Working directory:
      /tmp/pip-req-build-ok4ccu2r/_skbuild/linux-x86_64-3.9/cmake-build
    Command:
      cmake /tmp/pip-req-build-ok4ccu2r -G Ninja -DCMAKE_INSTALL_PREFIX:PATH=/tmp/pip-req-build-ok4ccu2r/_skbuild/linux-x86_64-3.9/cmake-install -DPYTHON_EXECUTABLE:FILEPATH=/home/gbae/.pyenv/versions/cucim-3.9/bin/python -DPYTHON_VERSION_STRING:STRING=3.9.10 -DPYTHON_INCLUDE_DIR:PATH=/home/gbae/.pyenv/versions/3.9.10/include/python3.9 -DPYTHON_LIBRARY:FILEPATH=/home/gbae/.pyenv/versions/3.9.10/lib/libpython3.9.a -DSKBUILD:INTERNAL=TRUE -DCMAKE_MODULE_PATH:PATH=/tmp/pip-build-env-jzz17i2u/overlay/lib/python3.9/site-packages/skbuild/resources/cmake -DCMAKE_MAKE_PROGRAM:FILEPATH=/tmp/pip-build-env-jzz17i2u/overlay/lib/python3.9/site-packages/ninja/data/bin/ninja -DCMAKE_BUILD_TYPE:STRING=Release

  Traceback (most recent call last):

  An error occurred while configuring with CMake.
    Command:
      cmake /tmp/pip-req-build-ok4ccu2r -G Ninja -DCMAKE_INSTALL_PREFIX:PATH=/tmp/pip-req-build-ok4ccu2r/_skbuild/linux-x86_64-3.9/cmake-install -DPYTHON_EXECUTABLE:FILEPATH=/home/gbae/.pyenv/versions/cucim-3.9/bin/python -DPYTHON_VERSION_STRING:STRING=3.9.10 -DPYTHON_INCLUDE_DIR:PATH=/home/gbae/.pyenv/versions/3.9.10/include/python3.9 -DPYTHON_LIBRARY:FILEPATH=/home/gbae/.pyenv/versions/3.9.10/lib/libpython3.9.a -DSKBUILD:INTERNAL=TRUE -DCMAKE_MODULE_PATH:PATH=/tmp/pip-build-env-jzz17i2u/overlay/lib/python3.9/site-packages/skbuild/resources/cmake -DCMAKE_MAKE_PROGRAM:FILEPATH=/tmp/pip-build-env-jzz17i2u/overlay/lib/python3.9/site-packages/ninja/data/bin/ninja -DCMAKE_BUILD_TYPE:STRING=Release
    Source directory:
      /tmp/pip-req-build-ok4ccu2r
    Working directory:
      /tmp/pip-req-build-ok4ccu2r/_skbuild/linux-x86_64-3.9/cmake-build
  Please see CMake's output for more information.
  ----------------------------------------
  ERROR: Failed building wheel for kvikio
Failed to build kvikio
ERROR: Could not build wheels for kvikio which use PEP 517 and cannot be installed directly
WARNING: You are using pip version 21.2.4; however, version 22.0.4 is available.
You should consider upgrading via the '/home/gbae/.pyenv/versions/cucim-3.9/bin/python -m pip install --upgrade pip' command.

As to cleaning, think something like python setup.py clean might work. Haven't tried, but there does seem to be some indication in scikit-build that this should work.

Yup, setup.py clean should fix that. I think this is an upstream issue in scikit-build, it looks similar but not exactly identical to https://github.com/scikit-build/scikit-build/issues/521

FWIW did a bit more digging into the pip version 21.2 error above ( https://github.com/rapidsai/kvikio/issues/12#issuecomment-1084880376 ). It does appear that the cpp directory tree is not copied over to the temporary directory (though everything in the python directory tree is). So errors like this come up
add_subdirectory given source "/tmp/pip-req-build-x628d_ie/../cpp" which is
    not an existing directory.

Have played with MANIFEST.in and package_data, but it doesn't seem to be copying these over. Could very be something I'm doing wrong or not understanding about scikit-build.
That all being said, wonder how much this is worth digging into given pip version 21.3+ don't have this issue and older pip versions have --use-feature=in-tree-build to opt-in to this new behavior.

@Weigaa we build Conda packages, which you could install. Stable ones are in rapidsai and dev ones are in rapidsai-nightly

Closing this, please re-open if this is still an issue


Use webpack or rollup to export package properly

Tried to integrate simple example in my code base today and ran into that error "export 'withNamespaces' was not found in '../i18n'
i18n.js:
import NextI18Next from 'next-i18next'

const options = {}
export default new NextI18Next(options)

next-i18next: v0.23.1
i18next: v.14.0.1
react-i18next: v9.0.9
next: v7.0.2
react: v16.6.3
node: v11.6.0
npm: v6.6.0

I'll be merging #159 soon, but in general there's no way to get named exports off a class with ES modules without explicitly declaring them.
If anyone has any questions let me know.

You can use this workaroud:
const i18n = new NextI18Next(options);
export default i18n;
export const withNamespaces = i18n.withNamespaces;
export const Link = i18n.Link;
export const Trans = i18n.Trans;
export const appWithTranslation = i18n.appWithTranslation;
export const config = i18n.config;

Thanks, that fixed the import issue I had from my server file.

TypeError: Cannot read property 'cloneInstance' of undefined

TypeError: Cannot read property 'cloneInstance' of undefined

me too since updating to:
const NextI18Next = require('next-i18next').default;

const NextI18NextInstance = new NextI18Next({
  defaultLanguage: 'en',
  otherLanguages: ['pl'],
});

module.exports = {
  default: NextI18NextInstance,
  withNamespaces: NextI18NextInstance.withNamespaces,
  Link: NextI18NextInstance.Link,
  Trans: NextI18NextInstance.Trans,
  appWithTranslation: NextI18NextInstance.appWithTranslation,
  config: NextI18NextInstance.config,
};

Hi @husseinbob. This CodeSandbox runs that exact code without issue. Please post on StackOverflow for help requests.

@husseinbob @isaachinman seems like exporting only the given properties causes the issue - i18next isn't passed to the middleware's handle function (thus the undefined error)
Fixed it for me by exporting the entire instance:
const NextI18Next = require('next-i18next').default;

const NextI18NextInstance = new NextI18Next({
  defaultLanguage: 'bg',
  otherLanguages: ['en'],
  ignoreRoutes: ['/_next/', '/static/', 'robots.txt']
});

module.exports = NextI18NextInstance;

TypeError: Cannot read property 'cloneInstance' of undefined

export const i18n solves the problem:
`import NextI18Next from 'next-i18next'
const NextI18NextInstance = new NextI18Next({
defaultLanguage: 'en',
otherLanguages: ['pl']
})
export default NextI18NextInstance
export const {
appWithTranslation,
Link,
Trans,
config,
withTranslation,
i18n,
} = NextI18NextInstance`


Mipmap icon support

I would just like to request mipmap icon support.
Thx for your work.

There shouldn't be any change required as far as I know.

I don't believe there's an additional API, they're loaded the same way a regular drawable is loaded.


[🐛] HUAWEI mate30 pro,  "系统服务 检测到  删除了图片，已成功拦截"

Description
Explain the bug in as much detail as possible
ImagePicker.showImagePicker, when user tap camera cancel, response.didCancel execute,  notification center show "系统服务 检测到XXX删除了图片，已成功拦截"
How to repeat issue and example
ImagePicker.showImagePicker, when user tap camera cancel, response.didCancel execute,  notification center show "系统服务 检测到XXX删除了图片，已成功拦截"
Solution
How to clear up the notification message?
Additional Information

Image Picker version: [2.3.4]
React Native version: [0.62]
Platform: [Android]
Development Operating System: [MacOS]
Dev tools: [Android] navigation crash for Android

Sorry we could not respond in time.
Version 2.x.x is not longer supported, please upgrade to 3.x.x


Don't adjust decimal places based on step, fix decimal calc

Connected to https://github.com/vaadin/vaadin-text-field-flow/issues/172

This change is

I'm working on #395 and would like to get this PR merged first as this is slightly related.


readme updated

Coverage remained the same at 29.231% when pulling 1948ff9bc7502f7a3ae5c0483e4fbb6751efdc81 on vitalca:master into 6253586e9163ae56802970d518d012197480c89f on Ericsson:master.


⚠ Bofrost.lu has degraded performance

In 115d9f3, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1211 ms

Resolved: Bofrost.lu performance has improved in 8292c8c after 16 minutes.


feat(friendshipper): increase http buffer size in git config

7561492698

We're good with allocating 1GB of memory on every git push?

We're good with allocating 1GB of memory on every git push?

Yea that might be over allocating for now. I can drop it back down to 524288000 and if we see any more connection issues we can bump it back up.


Transcribe

Currently, it is not possible to continuously transcribe. Only one VAD marked voice one at a time.
TWO feedback for Godot
(a) Every VAD Marked captured sentence add to a list and display as multiline textbox
(b) It is possible to upload a MP3 audio and see the transcription proceeds in real time, adding each line of new VAD captured text into the List

It is done


'podman' is not 'delegated'.

Hello,
I'm currently trying to set up molecule testing in the Ansible role inside my RHEL8 system. but when I'm trying to run the below command it is showing me an error 'podman' is not 'delegated'.
[rchakrab@rchakrab:~/Rough/Zeus/roles/motd]$ molecule init scenario --role-name motd --driver-name podman
Usage: molecule init scenario [OPTIONS] [SCENARIO_NAME]
Try 'molecule init scenario --help' for help.

Error: Invalid value for '--driver-name' / '-d': 'podman' is not 'delegated'.

[rchakrab@rchakrab:~/Rough/Zeus/roles/motd]$ molecule init scenario --help
Usage: molecule init scenario [OPTIONS] [SCENARIO_NAME]

  Initialize a new scenario for use with Molecule.

  If name is not specified the 'default' value will be used.

Options:
  --dependency-name [galaxy]      Name of dependency to initialize. (galaxy)
  -d, --driver-name [delegated]   Name of driver to initialize. (delegated)
  --lint-name [yamllint]          Name of lint to initialize. (ansible-lint)
  --provisioner-name [ansible]    Name of provisioner to initialize. (ansible)
  -r, --role-name TEXT            Name of the role to create.
  --verifier-name [ansible|testinfra]
                                  Name of verifier to initialize. (ansible)
  --help                          Show this message and exit.

Output of podman version
[rchakrab@rchakrab:~/Rough/Zeus/roles/motd]$ podman version
Version:      3.2.3
API Version:  3.2.3
Go Version:   go1.15.7
Built:        Tue Jul 27 12:59:39 2021
OS/Arch:      linux/amd64

Output of podman info --debug
[rchakrab@rchakrab:~/Rough/Zeus/roles/motd]$ podman info --debug
host:
  arch: amd64
  buildahVersion: 1.21.3
  cgroupControllers: []
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: conmon-2.0.29-1.module+el8.4.0+11822+6cc1e7d7.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.29, commit: ae467a0c8001179d4d0adf4ada381108a893d7ec'
  cpus: 8
  distribution:
    distribution: '"rhel"'
    version: "8.4"
  eventLogger: file
  hostname: rchakrab.pnq.csb
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 119656
      size: 1
    uidmap:
    - container_id: 0
      host_id: 119656
      size: 1
  kernel: 4.18.0-305.17.1.el8_4.x86_64
  linkmode: dynamic
  memFree:<PHONE_NUMBER>4
  memTotal:<PHONE_NUMBER>6
  ociRuntime:
    name: runc
    package: runc-1.0.0-74.rc95.module+el8.4.0+11822+6cc1e7d7.x86_64
    path: /usr/bin/runc
    version: |-
      runc version spec: 1.0.2-dev
      go: go1.15.13
      libseccomp: 2.5.1
  os: linux
  remoteSocket:
    path: /run/user/119656/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_NET_RAW,CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.8-1.module+el8.4.0+11822+6cc1e7d7.x86_64
    version: |-
      slirp4netns version 1.1.8
      commit: d361001f495417b880f20329121e3aa431a8f90f
      libslirp: 4.3.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.1
  swapFree:<PHONE_NUMBER>
  swapTotal:<PHONE_NUMBER>
  uptime: 9h 42m 11.98s (Approximately 0.38 days)
registries:
  search:
  - registry.access.redhat.com
  - registry.redhat.io
  - docker.io
store:
  configFile: /home/rchakrab/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.6-1.module+el8.4.0+11822+6cc1e7d7.x86_64
      Version: |-
        fusermount3 version: 3.2.1
        fuse-overlayfs: version 1.6
        FUSE library version 3.2.1
        using FUSE kernel interface version 7.26
  graphRoot: /home/rchakrab/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 0
  runRoot: /run/user/119656/containers
  volumePath: /home/rchakrab/.local/share/containers/storage/volumes
version:
  APIVersion: 3.2.3
  Built:<PHONE_NUMBER>
  BuiltTime: Tue Jul 27 12:59:39 2021
  GitCommit: ""
  GoVersion: go1.15.7
  OsArch: linux/amd64
  Version: 3.2.3

Agreed. I suppose the error message could be clearer, though.

Thanks! @tadeboro
I think the logger message should be more clearer. instead of saying Invalid value for '--driver-name' when we are actually providing the right driver name. It should be something like Error: please install an appropriate driver package.

@RanabirChakraborty Molecule does not have a built-in list of drivers, so there is no such thing as "right driver name". Molecule only knows about the drivers that are installed. But I agree, the error message should contain some information about how one can install additional drivers. Something along the lines of Invalid value for --driver-name: podman. Available drivers: delegated, ... Did you install the appropriate Molecule driver?.

$ molecule init role testproj --driver-name podman
Usage: molecule init role [OPTIONS] ROLE_NAME
Try 'molecule init role --help' for help.

Error: Invalid value for '--driver-name' / '-d': 'podman' is not one of 'delegated', 'vagrant'.
$ pip3 list | grep podman
molecule-podman                   1.0.1
podman                            3.2.1
$ podman --version
podman version 3.4.2
$ podman info | head -n10
host:
  arch: amd64
  buildahVersion: 1.23.1
  cgroupControllers:
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.30-2.fc35.x86_64

Fixed by installing molecule-3.5.3.dev22


Fix incorrect scroll on welcome screen with attachments for keyboard

Address issue with incorrect content scrolling offset when on welcome screen several attachments are added and keyboard is presented.
MOB-2128

!merge


[Improvement] Introduce config to customize assignment server numbers in client side

What changes were proposed in this pull request?
[Improvement] Introduce config to customize assignment server numbers in client side.
Changelog

Introduce the config of <client_type>.rss.client.assignment.shuffle.nodes.max

Why are the changes needed?
Now the assignment number specified by coordinator's conf of rss.coordinator.shuffle.nodes.max. But i think it's not suitable for all spark jobs.
We should introduce new config to let client specify the assignment server number. rss.coordinator.shuffle.nodes.max should be as a max limitation of clients' number.

Does this PR introduce any user-facing change?
YES.

How was this patch tested?
UT.

Ping @jerqi

Codecov Report

Merging #100 (9b1aef7) into master (cdbacca) will decrease coverage by 0.83%.
The diff coverage is 58.82%.

@@             Coverage Diff              @@
##             master     #100      +/-   ##
============================================
- Coverage     56.34%   55.51%   -0.84%
+ Complexity     1175     1106      -69
============================================
  Files           149      140       -9
  Lines          7977     7627     -350
  Branches        765      737      -28
============================================
- Hits           4495     4234     -261
+ Misses         3239     3160      -79
+ Partials        243      233      -10

Impacted Files
Coverage Δ

.../java/org/apache/hadoop/mapreduce/RssMRConfig.java
66.66% <ø> (ø)

...apache/hadoop/mapreduce/v2/app/RssMRAppMaster.java
0.00% <0.00%> (ø)

...he/uniffle/client/impl/ShuffleWriteClientImpl.java
25.95% <ø> (ø)

...rg/apache/uniffle/client/util/RssClientConfig.java
0.00% <ø> (ø)

...he/uniffle/coordinator/CoordinatorGrpcService.java
2.33% <0.00%> (-0.03%)
:arrow_down:

...e/uniffle/coordinator/BasicAssignmentStrategy.java
96.77% <100.00%> (+0.34%)
:arrow_up:

...rg/apache/uniffle/coordinator/CoordinatorConf.java
96.15% <100.00%> (ø)

...oordinator/PartitionBalanceAssignmentStrategy.java
98.46% <100.00%> (+4.91%)
:arrow_up:

...storage/handler/impl/DataSkippableReadHandler.java
81.25% <0.00%> (-3.13%)
:arrow_down:

...org/apache/uniffle/server/ShuffleFlushManager.java
76.70% <0.00%> (-1.71%)
:arrow_down:

... and 13 more

Help us with your feedback. Take ten seconds to tell us how you rate us.

How to rerun the CI @jerqi

How to rerun the CI @jerqi
Close and reopen pull request.

Updated @jerqi

@zuston Thanks for the contribution, it's flexible for different kind of jobs. And please update Constants.SHUFFLE_SERVER_VERSION for version compatible.

@zuston Thanks for the contribution, it's flexible for different kind of jobs. And please update Constants.SHUFFLE_SERVER_VERSION for version compatible.

It should be a compatible feature, we don't need update the Constants.SHUFFLE_SERVER_VERSION.

@zuston Thanks for the contribution, it's flexible for different kind of jobs. And please update Constants.SHUFFLE_SERVER_VERSION for version compatible.

It should be a compatible feature, we don't need update the Constants.SHUFFLE_SERVER_VERSION.

ok, it's only updated for coordinator.
+1, LGTM


[5.2] Allow custom stubs

Build-able in /resources/stubs/.

As discussed in #internals of Larachat Slack.

This idea was previously rejected by Taylor, but I'll guess we'll see.

+1
I'm not a fan of this helper though. A trait looks much better there because it's not a thing for app, it's a thing for core

@arrilot Yeah. This whole approach seems wrong to me.

So, people would prefer this as a trait? Can do, where's the best place for this trait to live? Illuminate\Console ? Foundation\Support ?

You should squash these commits down.

If you feel like this is headed n the right direction, I'll be happy to squash 'em down. Just not doing too much cleaning till people say we're getting close.

You don't want to have the trait in Illuminate/Foundation because the auth, cache, database, etc packages won't be able to use the console commands without requiring the entire framework. I would imagine you probably want to add it to Illuminate/Console, since that is the package required to run commands anyway.

You don't want to have the trait in Illuminate/Foundation because the auth, cache, database, etc packages won't be able to use the console commands without requiring the entire framework. I would imagine you probably want to add it to Illuminate/Console, since that is the package required to run commands anyway.

You have no option because base_base is only defined in there.

After a little more digging around, it seems as if the console commands and Illuminate/Console aren't as decoupled from the Laravel framework as I had originally thought.
@GrahamCampbell In an effort to help ease future decoupling efforts, maybe call to the base_path() helper method should be replaced with $this->laravel->basePath() in this PR?

TBH I'm actually :-1: on this happening at all, and would recommend you stop making changes until Taylor gives it the go ahead here.

@GrahamCampbell why are you against this concept? The reason I am for it is because I had to extend Blueprint. So my goal behind all of this is to update my migration stub to use our extended Blueprint class.

:+1: for larger apps you end up having a lot of changes you make to the base generated model. From common traits, to extending a more common base model.
These add up and at this point its easier for me to copy/paste from another existing model than to run the console commands. This PR would change that.

Yep, I agree with @tomschlick's points. This would be very useful.

Please squash to one commit.

I would love to squash to one commit, but git isn't cooperating. And I've followed a lot of tutorials at this point, trying to make it squash.
So.
Plan B: Perhaps I should make a git patch of all these changes, close this PR, and start a new one from a clean state, then apply that patch.
Deal?

try this one... http://blog.steveklabnik.com/posts/2012-11-08-how-to-squash-commits-in-a-github-pull-request

Thanks @tomschlick, but I think the problem is that I pulled from 5.2, merging somebody else's code into this PR, therefore making it impossible. I fear the options are A: accept PR in its current ugly state, or B: make a patch and start fresh.

Creating a new PR with your changes is probably the best option if you cant rebase/squash. Just make sure to reference it here.

This has quite a few problems in that we can't reference Illuminate\Foundation from the sub-splitted components. I almost wonder if it would be easier to just distributed this as a package that adds an Artisan command namespace like stub:foo and it would check in resources/stubs.

Are you talking a 3rd-party package or an official laravel package? I can open this up for discussion on the new internals repo if you want...

@scottconnerly thoughts on making a package for this like @taylorotwell suggested?

Definitely want to make a package for it. Might be a few more weeks before I can take that on though. I'll be sure to post back here when it's ready.

Fantastic! Let me know if you want any help!


[bugfix] Spacing Bug Mobile View @Home Page

closes #792

- I have participated in GSSOC and CrossWoC

Check the deploy preview please


JWT Question #2

postman with /authentication screen
Show /authenticate endpoint code in Visual Studio Code

Show and Demo /authenticate in Postman…

Demo calling to endpoint
Show JSON data passed in call
Show Response window
Show Cookie acquired window

Cut/Copy/Paste Cookie into jwt.io and show decrypting payload

Frontend code is NOT the code that is executed when you run from POSTMAN.   In this case POSTMAN, replace the front end UI and run code that is associated with api endpoint.    None of that is shown


[nlohmann-json] Delete the docs folder to reduce open source vulnerability alerts.

My project has a process that scans for open source dependencies with known security vulnerabilities. When one is detected, it creates an alert which must be either addressed or dismissed as a false positive. I have often received alerts due to vulnerabilities in the Python components used within the "docs" folder for Nlohmann JSON. However, these are always false positives because I'm just using the C++ code from this repo and not building the documentation. I'd like to stop these alerts once and for all by having Vcpkg simply delete the docs folder from the Nlohmann JSON source code before it runs CMake. This will remove the code which generates so many alerts so the vulnerability detector will quit raising alerts for it.
Checklist:

[X] Changes comply with the maintainer guide
[X] SHA512s are updated for each updated download
[X] The "supports" clause reflects platforms that may be fixed by this new version
[X] Any fixed CI baseline entries are removed from that file.
[X] Any patches that are no longer applied are deleted from the port's directory.
[X] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[X] Only one version is added to each modified port's versions file.

I don't think this is going to be meaningful, since you're only messing with the source tree, not anything installed. It looks like they don't install those docs files anywhere...

I don't think this is going to be meaningful, since you're only messing with the source tree, not anything installed. It looks like they don't install those docs files anywhere...

The open source vulnerabilities are detected through source scanning. I can share the links to you via work email since my project is internal to Microsoft.

If they are looking at source scanning why is the situation going to be any different if the docs were ever on disk in the first place?

The source scan occurs after the build completes. Since Vcpkg doesn't use anything from the "docs" folder, it isn't cheating to just delete it right away. We aren't hiding any vulnerabilities that actually apply to projects using Nlohmann JSON. (I've sent you an email internally which includes links to the 7 vulnerability alerts I've received so far this year due to this issue.)

Also, in case it isn't clear, the folder is picked up by the soruce scan because we clone the vcpkg repo into the source directory as part of the build. Something I didn't consider until now is that I might be able to work around this by cloning vcpkg to a different folder outside the repo so it doesn't get scanned with the source scanner.

Sorry, one more comment to clarify even further. This is the path which triggers the vulnerability alerts:
/s/clone/vcpkg/buildtrees/nlohmann-json/src/v3.11.2-efdad4750e.clean/docs/mkdocs/requirements.txt
We clone vcpkg to "clone\vcpkg" within the source tree. The source for nlohmann-json is downloaded to the "buildtrees" folder as part of the vcpkg install. The vulneratiblity scanner just sees that within my project's source tree, so it thinks I am the one using the python modules reference in requirements.txt. Hopefully that clarifies.

The source scan occurs after the build completes. Since Vcpkg doesn't use anything from the "docs" folder, it isn't cheating to just delete it right away. We aren't hiding any vulnerabilities that actually apply to projects using Nlohmann JSON. (I've sent you an email internally which includes links to the 7 vulnerability alerts I've received so far this year due to this issue.)

Why can't you use the --clean-buildtrees-after-build flag for the install command?

Hi @PDeets, I'm not sure that this would solve your problem. Have you verified this fix / could you demonstrate an overlay port with this fix? Additionally, would you mind trying out @Thomas1664 suggestion above? I just want to make sure this actually fixes your problem since this would invalidate other users' binary cache.

Hello, sorry for the delay. I went on vacation, but I'm back now. --clean-buildtrees-after-build sounds like it could work for me. I'll try that out and share an update here.

I've confirmed that using --clean-buildtrees-after-build addresses this issue for me. I'll close the PR now.


refactor(sql-execute): refactor SQL async execute api into streaming return

What type of PR is this?
type-feature

What this PR does / why we need it:
In ODC 4.3.0, We hope to refactor the SQL async execute api into a streaming return method. Each time, it returns the results that has already been finished.
Therefore, I added a AsyncExecuteContext to cache the results of ODCStatementCallBack.
When the ODC server receives a request for getResult, it will first block for one second to determine whether the SQL execution is complete.
If the execution is completed, the result will be directly returned. The status is SUCCESS.
If it is not completed, the results completed during the period from the last request to now will be returned. At this point, the status is RUNNING.

pr gets conflict with dev/4.3.x


Correct typo in viewport meta tag

s/intial/initial/

Thank you for the fix!

Thank you for the fix!


Set-up kanban board

https://github.com/users/M-AminAlizadeh/projects/5
This is Recipe App rails capstone project, there are two of us in this project:
Amin
[Aly] https://github.com/AlyAtalla

Hi @AlyAtalla and @M-AminAlizadeh ,
Your project is complete!  There is nothing else to say other than... it's time to merge it :shipit:
Congratulations! 🎉 🎉 🎉
Highlights
✔ Set up the Kanban board correctly with all required columns.
✔ Ensured all tasks from the project requirements have been added correctly.
Optional suggestions
Every comment with the [OPTIONAL] prefix won't stop the approval of this PR. However, I strongly recommend you to take them into account as they can make your code better. Some of them were simply missed by the previous reviewer and addressing them will really improve your application.
Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, remember to tag me in your question so I can receive the notification.

As described in the Code reviews limits policy  you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.


A test is connecting to github.com and makes CircleCI to fail

These are the last lines from CircleCI output, so I suppose that the test with the problem is under test_backend.py.
It seems that this does not affect TravisCI because I didn't see it here, but it does affect CircleCI and tests from Corporate are not passing because of this.
Also, tests should not download anything from GitHub anyway.
We need to research a little more here to find the issue and use a local repository for this purpose.
../.tox/py36/readthedocs.org/readthedocs/rtd_tests/tests/test_backend.py . [ 44%]
The authenticity of host 'github.com (<IP_ADDRESS>)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no)? Too long with no output (exceeded 10m0s)

Tried this offline, it works. But I'm thinking something about this line is causing the problem https://github.com/rtfd/readthedocs.org/blob/f4d3a93a5c487351e836d51066faf40511a0b45a/readthedocs/rtd_tests/utils.py#L72-L72

or even better https://discuss.circleci.com/t/git-clone-fails-in-circle-2-0/15211/2


Login for services with 2FA not remembered

Bug Description
For services with which I have 2FA enabled, I must log in every time in spite of checking "Remember Me" (Login and pass) and "Remember this Computer" (2FA).
This occurs with Slack and Google Hangouts. For Slack services that I do not have 2FA enabled, the login is remembered. For other services, e.g., Whatsapp, the login is remembered. It's only for those services with 2FA that I must log in every time.
To Reproduce
Steps to reproduce the behavior:

Open Ferdi
Add Service with 2FA
Log in
Enter 2FA
Use service
Close Ferdi and reboot machine
Reopen Ferdi
Login to saved service(s) again

Expected behavior
Login details should be saved such that I don't have to log in and add 2FA details every time I wish to use thee service when I've checked "Remember Me" and "Remember this Computer".
Desktop (please complete the following information):

OS: Linux (Manjaro)
Browser Firefox 70
Version 5.3.3
Release 4.2.12 / linux / x64

Yes, Firefox remembers the logins between sessions. Ferdi does not.
On Wed, 30 Oct 2019 at 11:15, Bennett<EMAIL_ADDRESS>wrote:

Is this behaviour different when using your normal browser? Normally,
Ferdi should not change the behaviour of sessions and cookies.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/getferdi/ferdi/issues/177?email_source=notifications&email_token=AAYMIAX7LGADZ5ZJ3MSHND3QRGJGXA5CNFSM4JGZOHRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECUK2EI#issuecomment-547925265,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYMIAW75ZMG4IGLLJP54HTQRGJGXANCNFSM4JGZOHRA
.

--
Dr Adam H. Sparks
http://adamhsparks.netlify.com/
Associate Professor of Field Crops Pathology   |   Centre for Crop Health
|  Office C313
Phone (+61) 07 46311948  |  Mobile 0415 489 422 | Twitter @adamhsparks
https://twitter.com/adamhsparks
Institute for Life Sciences and the Environment |  Research and Innovation
Division
University of Southern Queensland | Toowoomba, Queensland | 4350 | Australia

Hangouts works for me, with 2FA enabled on Google account.
Mac, v5.3.3.

I can try one of my Mac's later when I have access to them. But that still
doesn't fix the issue I have with the Linux machine I'm using right now...
On Wed, 30 Oct 2019 at 14:22, Paweł Antczak<EMAIL_ADDRESS>wrote:

Hangouts works for me, with 2FA enabled on Google account.
Mac, v5.3.3.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/getferdi/ferdi/issues/177?email_source=notifications&email_token=AAYMIASKSVQLEG3MB2S6XUDQRG7GFA5CNFSM4JGZOHRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECVB7HI#issuecomment-548020125,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYMIAU4BQPD5RKQZ3XEYK3QRG7GFANCNFSM4JGZOHRA
.

--
Dr Adam H. Sparks
http://adamhsparks.netlify.com/
Associate Professor of Field Crops Pathology   |   Centre for Crop Health
|  Office C313
Phone (+61) 07 46311948  |  Mobile 0415 489 422 | Twitter @adamhsparks
https://twitter.com/adamhsparks
Institute for Life Sciences and the Environment |  Research and Innovation
Division
University of Southern Queensland | Toowoomba, Queensland | 4350 | Australia

I believe you, just wanted to indicate that is't not black and white bug.

I'm experiencing the same issue - with Facebook Messenger specifically.
Have there been some updates on this?
I had the same issue with Franz if that is an indication of something.

Am having the same issue too. I use a lot of services with Ferdi and I have 2 step verification for my google accounts. Logging into everything will take 10 minutes!

Closing due to inactivity.


Test Kroxylicious against older Kafka Brokers

Currently the test suite is only exercising the Kroxylicious against the version of Kafka Kroxylicious is build against.  We ought to have a test matrix that tests against earlier versions of Kafka Broker in order to assure compatibility.
We probably need a test matrix and some way of disabling  tests that should only be run for certain version of Kafka.
We might be able to exploit the CONTAINER mode of the Kroxylicious Junit Test Extension to allow the test suite to be executed against older Brokers.

We should raise another issue for "testing all versions of Kafka client".

We should raise another issue for "testing all versions of Kafka client".

https://github.com/kroxylicious/kroxylicious/issues/1131


Error processing "restartFrame": Error: Internal error

I was testing https://github.com/microsoft/vscode/issues/85626, which works nicely, by debugging VS Code. The only inline action is restart frame, and when I click it I get this error in the debug console:
Error processing "restartFrame": Error: Internal error
    at Client.processMessage (c:\Users\alros\.vscode-insiders\extensions\msjsdiag.debugger-for-chrome-4.12.2\node_modules\noice-json-rpc\lib\noice-json-rpc.js:66:36)
    at LoggingSocket.<anonymous> (c:\Users\alros\.vscode-insiders\extensions\msjsdiag.debugger-for-chrome-4.12.2\node_modules\noice-json-rpc\lib\noice-json-rpc.js:42:48)
    at LoggingSocket.emit (events.js:205:15)
    at Receiver.receiverOnMessage (c:\Users\alros\.vscode-insiders\extensions\msjsdiag.debugger-for-chrome-4.12.2\node_modules\ws\lib\websocket.js:789:20)
    at Receiver.emit (events.js:200:13)
    at Receiver.dataMessage (c:\Users\alros\.vscode-insiders\extensions\msjsdiag.debugger-for-chrome-4.12.2\node_modules\ws\lib\receiver.js:422:14)
    at c:\Users\alros\.vscode-insiders\extensions\msjsdiag.debugger-for-chrome-4.12.2\node_modules\ws\lib\receiver.js:379:23
    at c:\Users\alros\.vscode-insiders\extensions\msjsdiag.debugger-for-chrome-4.12.2\node_modules\ws\lib\permessage-deflate.js:298:9
    at c:\Users\alros\.vscode-insiders\extensions\msjsdiag.debugger-for-chrome-4.12.2\node_modules\ws\lib\permessage-deflate.js:376:7
    at afterWrite (_stream_writable.js:483:3)

It happens on any of the frames and the frame doesn't appear to restart. frame does restart.

This is coming from the node debug adapter.
The isse is that the node debug adapter can only restart the top frame. And currently we do not have a capaibiltiy for the node extnesino to notify vscode that this action should be disabled.
Assigning also to @roblourens
fyi @weinand

I see the error even on the top frame.

I leave that up to @roblourens and @connor4312 since the error is coming from the extension

Cool, this is not supported by Electron. Not only that but if you send restartFrame to the window then the window breaks. We don't really detect if we are debugging Chrome vs Electron but I guess I need to do that.

Eh I take that back, I got into a bad state once but in other cases it seems fine to just ignore the error. Fixing in the DA.

Fyi I had this happen on Node 10 putting together https://github.com/microsoft/vscode-pwa/pull/160. Switching my runtime version to 12 resolved the issue, and everything looked peachy in the traces, so I think it's some V8 issue.

Yeah I filed an upstream issue then realized that it's fixed in Electron 7. I'm just going to leave this alone.

Oh this affects extensionHost debugging too, I will work around it for this release

Thanks for jumping on this Rob

Can be verifid in chrome-debug starting now

Verified works debugging VS Code


community-operators konveyor-forklift-operator (2.0.0)

Signed-off-by: Franco Bladilo<EMAIL_ADDRESS>Thanks submitting your Operator. Please check below list before you create your Pull Request.
New Submissions

[ ] Are you familiar with our contribution guidelines?
[ ] Have you packaged and deployed your Operator for Operator Framework?

[ ] Have you tested your Operator in all supported installation modes?
[ ] Have you considered whether you want use semantic versioning order?
[x] Is your submission signed?
[ ] Is operator icon set?

Updates to existing Operators

[x] Did you create a ci.yaml file according to the update instructions?
[ ] Is your new CSV pointing to the previous version with the replaces property if you chose replaces-mode via the updateGraph property in ci.yaml?
[ ] Is your new CSV referenced in the appropriate channel defined in the package.yaml or annotations.yaml ?
[ ] Have you tested an update to your Operator when deployed via OLM?
[ ] Is your submission signed?

Your submission should not

[ ] Modify more than one operator
[ ] Modify an Operator you don't own
[ ] Rename an operator - please remove and add with a different name instead
[ ] Submit operators to both upstream-community-operators and community-operators at once
[ ] Modify any files outside the above mentioned folders
[ ] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[ ] Description about the managed Application and where to find more information
[ ] Features and capabilities of your Operator and how to use it
[ ] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[ ] Human readable name and 1-liner description about your Operator
[ ] Valid category name1
[ ] One of the pre-defined capability levels2
[ ] Links to the maintainer, source code and documentation
[ ] Example templates for all Custom Resource Definitions intended to be used
[ ] A quadratic logo

Remember that you can preview your CSV here.
--
1 If you feel your Operator does not fit any of the pre-defined categories, file an issue against this repo and explain your need
2 For more information see here

/test 4.7-deploy-operator-on-openshift

/test 4.6-deploy-operator-on-openshift

@mvalarh I don't think we will ever succeed installation on OCP 4.6, the CSV has a minKubeVersion: 1.20.0 (CNV requirement)

/merge possible

@fbladilo can you signoff commits? More info here

@mvalarh Both commits signed now, sorry for the inconvenience.

/merge possible


[Feature Request] Provide Global Success/Failure Hooks into Throttling Methods

Is your feature request related to a problem? Please describe
I'm always frustrated when I would like to log the rate-limiting behavior for the sake of  monitoring. Adding a global hook into the rate limiting throttle success and failure states allows us to use the RateLimit.throttle without worrying about exceptions in many cases. For example
Code Block (1)
if RateLimit.throttle(topic: 'login', namespace: :user_id, value: user.id)
  login(user)
else
  return false
end

If I need to add logging to that I would have to use RateLimit.throttle! method instead to be able to catch the RateLimit::Errors::LimitExceededError error, as follows
Code Block (2)
begin
  RateLimit.throttle!(topic: 'login', namespace: :user_id, value: user.id)
  Logger.post(event: 'RateLimitSucceeded', topic: 'login', value: user.id)
  login(user)
rescue RateLimit::Errors::LimitExceededError => e
  Logger.post(event:  'RateLimitFailed', topic: e.topic, value: user.id, threshold: e.threshold, interval: e.interval)
  return false
end

Describe the solution you'd like
I would like to be able to configure a global hooks to the throttler though the configuration. Something like:
RateLimit.configure do |config|
  config.on_success = proc { |topic, namespace,  value|
    # Success Logging Logic Goes HERE
    Logger.post(event: 'RateLimitSucceeded', topic: topic, value: value)
  }

  config.on_failure = proc { |topic,  namespace,  value,  threshold,  interval|
    # Failure Logging Logic Goes HERE
    Logger.post(event:  'RateLimitFailed', topic: topic, value: value, threshold: threshold, interval: interval)
  }
end

Therefore I would be able to use Code Block (1) and ensure that the on_success and on_failure hooks will take care of the given proc logic (logging in my example) on every usage of the throttling methods
Describe alternatives you've considered
Replicating the logging logic in every usage of the throttle as shown in Code Block (2)
Additional context

NONE

Personally I don't like global actions, rarely is the case that you need global actions based on success or failure logic.
in this particular usage I think a result object might be a better choice so the if RateLimit.throttle returns a Result the code block could look something like
result = RateLimit.throttle!(topic: 'login', namespace: :user_id, value: user.id)
if result.limit_exceeded?
  Logger.post(event:  'RateLimitFailed', topic: result.topic, value: user.id, threshold: result.threshold, interval: result.interval)
  return false
else
  Logger.post(event: 'RateLimitSucceeded', topic: 'login', value: user.id)
  login(user)
end

wdyt ?

@dhruvCW I like the idea of result object, it decreases the need of dealing with exceptions manually 👍🏻
However it does bot solve my issue, I would still have to write duplicate logging logic every time I need to throttle (5 times in my case).
I have also considered building my interface in my app but I didn't like that since i need to clone it to other services.

However it does not solve my issue, I would still have to write duplicate logging logic every time I need to throttle (5 times in my case).

oh, I guess your case is the rare situation wherein a global hook makes sense 👍 .