Pipfile python_version not taken into account when generating lockfile

Pipenv lock/install/sync generates a Pipfile.lock with package versions incompatible with the version of Python
output of python -m pipenv.help: https://pastebin.com/raw/r4WCG5AR

Expected result
Pipenv generates a lockfile with installable packages and then installs them.
Actual result
Pipenv generates a Pipfile.lock containing requirements that are incompatible with the version of Python specified in Pipfile using python_version or python_full_version and installation fails. Example:
Error message:
Collecting pylint-quotes==0.1.9 (from -r /var/folders/rj/210lgzrd4q5ccsyby0rdxg0924842d/T/pipenv-_auxxp4x-requirements/pipenv-u4w5lmul-requirement.txt (line 1))
  1 location(s) to search for versions of pylint-quotes:
  * https://pypi.python.org/simple/pylint-quotes/
  Getting page https://pypi.python.org/simple/pylint-quotes/
  Looking up "https://pypi.python.org/simple/pylint-quotes/" in the cache
  Current age based on date: 11
  Freshness lifetime from max-age: 600
  Freshness lifetime from request max-age: 600
  The response is "fresh", returning cached response
  600 > 11
  Analyzing links from page https://pypi.python.org/simple/pylint-quotes/
    Found link https://pypi.python.org/packages/7c/88/7a894a269a58a907fe173282f50d642dcbaa44a0b5d12043f4785347f11b/pylint-quotes-0.1.3.tar.gz#md5=2351ca090248406e0eeafa75d7a1eb10 (from https://pypi.python.org/simple/pylint-quotes/), version: 0.1.3
    Found link https://pypi.python.org/packages/a0/0a/372a8219a6a42a9fdba7bdc00aaffb3a9d88d01138022d76c08f6b83764a/pylint_quotes-0.1.3-py2.py3-none-any.whl#md5=1097eeffc8f0a75cc843cc0c97866be7 (from https://pypi.python.org/simple/pylint-quotes/), version: 0.1.3
    Found link https://pypi.python.org/packages/7d/a7/b1ddde1d38c1141ab2d7c51d307ef7f81d62b970fc035ea8db74911821c4/pylint-quotes-0.1.5.tar.gz#md5=1cd3ebbcfc518653c81593d2486da0d0 (from https://pypi.python.org/simple/pylint-quotes/), version: 0.1.5
    Found link https://pypi.python.org/packages/18/69/f19c51efaf3951fb570a78243b261a7bf178e66468f3692e1cd225fb4cfb/pylint_quotes-0.1.5-py2.py3-none-any.whl#md5=5cc78a567e4c25aa300c4bf933819e8b (from https://pypi.python.org/simple/pylint-quotes/), version: 0.1.5
    Found link https://pypi.python.org/packages/8c/c4/04c56b0446962f6c7424d76d5799747d40ad3472684e8995ba01a3fcdbdc/pylint-quotes-0.1.6.tar.gz#md5=86f79ae93e06a6fc488c7f73924be812 (from https://pypi.python.org/simple/pylint-quotes/), version: 0.1.6
    Found link https://pypi.python.org/packages/e7/ad/b3037ce9414ab986052d395b1b9cb6026e6e296afade18b2840d1363a073/pylint_quotes-0.1.6-py2.py3-none-any.whl#md5=1213fed2daec3507c9207d356de72b06 (from https://pypi.python.org/simple/pylint-quotes/), version: 0.1.6
    Found link https://pypi.python.org/packages/8d/ef/a135a29c4c4358b60712ef44b2eac21dda876ab9d0203bb4f254800d4255/pylint-quotes-0.1.7.tar.gz#md5=389d3ec970ef4b8d42d8247df3d08373 (from https://pypi.python.org/simple/pylint-quotes/), version: 0.1.7
    Found link https://pypi.python.org/packages/e8/b5/f03009ab72fe1d1442c4b8c3fc06680ecb4c1f0385b5b0bf2bf221b3195e/pylint_quotes-0.1.7-py2.py3-none-any.whl#md5=dea6d20e390fe80013d8a33be932d206 (from https://pypi.python.org/simple/pylint-quotes/), version: 0.1.7
    Found link https://pypi.python.org/packages/1c/b9/e14468554607a685abcb0d617d1ef7c5f25e5cbb1e280fed370594993006/pylint-quotes-0.1.8.tar.gz#md5=7330dcdb88e941ad2f03048ba95ede05 (from https://pypi.python.org/simple/pylint-quotes/), version: 0.1.8
    Found link https://pypi.python.org/packages/28/f5/e00a9b7597ba7b92b58ddac472f9cf5bfd347022a65a4beafd5f682a7758/pylint_quotes-0.1.8-py2.py3-none-any.whl#md5=fb713d376b27abdbd9491b126e85b5a5 (from https://pypi.python.org/simple/pylint-quotes/), version: 0.1.8
    The package https://pypi.python.org/packages/ba/20/4e59a01fd90fbe67385b790cb6ddb4a462f4d8e15548bab27c59c3b23fd3/pylint-quotes-0.1.9.tar.gz#md5=02eaa4853463f8f867f36e031b2503f0 (from https://pypi.python.org/simple/pylint-quotes/) (requires-python:>=3.4) is incompatible with the pythonversion in use. Acceptable python versions are:>=3.4
    The package https://pypi.python.org/packages/c2/cc/afc270fa43a12d10736422ddaa653c7c7664561f10b182b76884438637c2/pylint_quotes-0.1.9-py2.py3-none-any.whl#md5=7c680717a5af1c59e68809c865478f82 (from https://pypi.python.org/simple/pylint-quotes/) (requires-python:>=3.4) is incompatible with the pythonversion in use. Acceptable python versions are:>=3.4
  Could not find a version that satisfies the requirement pylint-quotes==0.1.9 (from -r /var/folders/rj/210lgzrd4q5ccsyby0rdxg0924842d/T/pipenv-_auxxp4x-requirements/pipenv-u4w5lmul-requirement.txt (line 1)) (from versions: 0.1.3, 0.1.5, 0.1.6, 0.1.7, 0.1.8)
Cleaning up...
No matching distribution found for pylint-quotes==0.1.9 (from -r /var/folders/rj/210lgzrd4q5ccsyby0rdxg0924842d/T/pipenv-_auxxp4x-requirements/pipenv-u4w5lmul-requirement.txt (line 1))
Exception information:
Traceback (most recent call last):
  File "/Users/<User>/.local/share/virtualenvs/py-VEuvpTJA/lib/python2.7/site-packages/pip/basecommand.py", line 215, in main
    status = self.run(options, args)
  File "/Users/<User>/.local/share/virtualenvs/py-VEuvpTJA/lib/python2.7/site-packages/pip/commands/install.py", line 335, in run
    wb.build(autobuilding=True)
  File "/Users/<User>/.local/share/virtualenvs/py-VEuvpTJA/lib/python2.7/site-packages/pip/wheel.py", line 749, in build
    self.requirement_set.prepare_files(self.finder)
  File "/Users/<User>/.local/share/virtualenvs/py-VEuvpTJA/lib/python2.7/site-packages/pip/req/req_set.py", line 380, in prepare_files
    ignore_dependencies=self.ignore_dependencies))
  File "/Users/<User>/.local/share/virtualenvs/py-VEuvpTJA/lib/python2.7/site-packages/pip/req/req_set.py", line 554, in _prepare_file
    require_hashes
  File "/Users/<User>/.local/share/virtualenvs/py-VEuvpTJA/lib/python2.7/site-packages/pip/req/req_install.py", line 278, in populate_link
    self.link = finder.find_requirement(self, upgrade)
  File "/Users/<User>/.local/share/virtualenvs/py-VEuvpTJA/lib/python2.7/site-packages/pip/index.py", line 514, in find_requirement
    'No matching distribution found for %s' % req
DistributionNotFound: No matching distribution found for pylint-quotes==0.1.9 (from -r /var/folders/rj/210lgzrd4q5ccsyby0rdxg0924842d/T/pipenv-_auxxp4x-requirements/pipenv-u4w5lmul-requirement.txt (line 1))

An error occurred while installing pylint-quotes==0.1.9! Will try again.

Steps to replicate
Create a Pipfile that specifies a python version and packages with a version range that includes versions that are both compatible and incompatible with the python_version specified.
Example Pipfile:
[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true

[requires]
python_version = "2.7"
python_full_version = "2.7.14"

[packages]
beaker = "==1.9.0"
bottle = "==0.12.13"
funcsigs = "==1.0.2"
gevent = "==1.2.2"
greenlet = "==0.4.12"
influxdb = "<=6.0.0"
jsoncomment = "==0.3.0"
netaddr = "==0.7.19"
numpy = "==1.11.2"
pandas = "==0.19.1"
pyrad = "==2.1"
python-dateutil = "==2.6.1"
pytz = "==2017.2"
requests = "*"
schedule = "==0.4.2"
tacacs-plus = "==2.0"
ujson = "==1.35"
bson = "*"
pymongo = "*"
"h5py" = "*"
environs = "*"
pyyaml = "*"
deprecated = "*"
appdirs = "*"
pycryptodome = "==3.4.11"
click = "*"
pyopenssl = "*"
pem = "*"

[dev-packages]
pytest = "*"
rope = "*"
ipython = "*"
mock = "*"
pylint = "*"
pylint-quotes = "*"
yapf = "*"
teamcity-messages = "*"
webtest = "*"
requests-mock = "*"
pdbpp = "*"
pytest-mock = "*"
pytest-cov = "*"
pytest-pythonpath = "*"

With this Pipfile both pylint-quotes and ipython will fail since pylint-quotes 1.9 and ipython 6.3.0 are both incompatible with python 2.7.14

This issue does exist on pipenv 11.10.0. The root cause is the resolver doesn't compare the current python version with python_requires and always picks the latest one.
Pipfile content:
[requires]
python_version = "2.7"

[packages]
django = "*"    # python2.7 requires django < 2

$ python -V
Python 2.7.14

pipenv lock verbose output
Locking [packages] dependencies…

Using pip: -i https://pypi.python.org/simple

                          ROUND 1
Current constraints:
  django

Finding the best candidates:
  found candidate django==2.0.4 (constraint was <any>)

Finding secondary dependencies:
  django==2.0.4 not in cache, need to check index
  django==2.0.4             requires pytz

New dependencies found in this round:
  adding [u'pytz', '', '[]']
Removed dependencies in this round:
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 1: not stable

                          ROUND 2
Current constraints:
  django
  pytz

Finding the best candidates:
  found candidate django==2.0.4 (constraint was <any>)
  found candidate pytz==2018.4 (constraint was <any>)

Finding secondary dependencies:
  django==2.0.4             requires pytz
  pytz==2018.4 not in cache, need to check index
  pytz==2018.4              requires -
------------------------------------------------------------
Result of round 2: stable, done

Updated Pipfile.lock (0454a4)!

This still isn't fixed

This is not fixed

To clarify, the words in your pipfile are used to generate your environment; the environment itself performs resolution. I need to see the output of pipenv lock —verbose to really understand what’s going on but I’m guessing based on the small part that you included that it one of your dependencies actually requires this version

Here is a simplified Pipfile that reproduces the issue
[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true
name = "pypi"

[packages]
ipython = "*"

[dev-packages]

[requires]
python_version = "2.7"

pipenv lock -vvv
Locking [dev-packages] dependencies…
Using pip: -i https://pypi.python.org/simple

                          ROUND 1
Current constraints:

Finding the best candidates:

Finding secondary dependencies:
------------------------------------------------------------
Result of round 1: stable, done

Locking [packages] dependencies…
Using pip: -i https://pypi.python.org/simple

                          ROUND 1
Current constraints:
  ipython

Finding the best candidates:
  found candidate ipython==6.3.1 (constraint was <any>)

Finding secondary dependencies:
  ipython==6.3.1            requires appnope; sys_platform == "darwin", backcall, decorator, jedi>=0.10, pexpect; sys_platform != "win32", pickleshare, prompt-toolkit<2.0.0,>=1.0.15, pygments, setuptools>=18.5, simplegeneric>0.8, traitlets>=4.2, typing; python_version <= "3.4"

New dependencies found in this round:
  adding [u'appnope', '', '[]']
  adding [u'backcall', '', '[]']
  adding [u'decorator', '', '[]']
  adding [u'jedi', '>=0.10', '[]']
  adding [u'pexpect', '', '[]']
  adding [u'pickleshare', '', '[]']
  adding [u'prompt-toolkit', '<2.0.0,>=1.0.15', '[]']
  adding [u'pygments', '', '[]']
  adding [u'simplegeneric', '>0.8', '[]']
  adding [u'traitlets', '>=4.2', '[]']
  adding [u'typing', '', '[]']
Removed dependencies in this round:
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 1: not stable

                          ROUND 2
Current constraints:
  appnope
  backcall
  decorator
  ipython
  jedi>=0.10
  pexpect
  pickleshare
  prompt-toolkit<2.0.0,>=1.0.15
  pygments
  simplegeneric>0.8
  traitlets>=4.2
  typing

Finding the best candidates:
  found candidate appnope==0.1.0 (constraint was <any>)
  found candidate backcall==0.1.0 (constraint was <any>)
  found candidate decorator==4.3.0 (constraint was <any>)
  found candidate ipython==6.3.1 (constraint was <any>)
  found candidate jedi==0.12.0 (constraint was >=0.10)
  found candidate pexpect==4.5.0 (constraint was <any>)
  found candidate pickleshare==0.7.4 (constraint was <any>)
  found candidate prompt-toolkit==1.0.15 (constraint was >=1.0.15,<2.0.0)
  found candidate pygments==2.2.0 (constraint was <any>)
  found candidate simplegeneric==0.8.1 (constraint was >0.8)
  found candidate traitlets==4.3.2 (constraint was >=4.2)
  found candidate typing==3.6.4 (constraint was <any>)

Finding secondary dependencies:
  decorator==4.3.0          requires -
  backcall==0.1.0           requires -
  pickleshare==0.7.4        requires pathlib2; python_version in "2.6 2.7 3.2 3.3"
  ipython==6.3.1            requires appnope; sys_platform == "darwin", backcall, decorator, jedi>=0.10, pexpect; sys_platform != "win32", pickleshare, prompt-toolkit<2.0.0,>=1.0.15, pygments, setuptools>=18.5, simplegeneric>0.8, traitlets>=4.2, typing; python_version <= "3.4"
  jedi==0.12.0              requires parso>=0.2.0
  simplegeneric==0.8.1      requires -
  pygments==2.2.0           requires -
  prompt-toolkit==1.0.15    requires six>=1.9.0, wcwidth
  traitlets==4.3.2          requires decorator, enum34; python_version == "2.7", ipython-genutils, six

New dependencies found in this round:
  adding [u'enum34', '', '[]']
  adding [u'ipython-genutils', '', '[]']
  adding [u'parso', '>=0.2.0', '[]']
  adding [u'pathlib2', '', '[]']
  adding [u'ptyprocess', '>=0.5', '[]']
  adding [u'six', '>=1.9.0', '[]']
  adding [u'wcwidth', '', '[]']
Removed dependencies in this round:
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 2: not stable

                          ROUND 3
Current constraints:
  appnope
  backcall
  decorator
  enum34
  ipython
  ipython-genutils
  jedi>=0.10
  parso>=0.2.0
  pathlib2
  pexpect
  pickleshare
  prompt-toolkit<2.0.0,>=1.0.15
  ptyprocess>=0.5
  pygments
  simplegeneric>0.8
  six>=1.9.0
  traitlets>=4.2
  typing
  wcwidth

Finding the best candidates:
  found candidate appnope==0.1.0 (constraint was <any>)
  found candidate backcall==0.1.0 (constraint was <any>)
  found candidate decorator==4.3.0 (constraint was <any>)
  found candidate enum34==1.1.6 (constraint was <any>)
  found candidate ipython==6.3.1 (constraint was <any>)
  found candidate ipython-genutils==0.2.0 (constraint was <any>)
  found candidate jedi==0.12.0 (constraint was >=0.10)
  found candidate parso==0.2.0 (constraint was >=0.2.0)
  found candidate pathlib2==2.3.0 (constraint was <any>)
  found candidate pexpect==4.5.0 (constraint was <any>)
  found candidate pickleshare==0.7.4 (constraint was <any>)
  found candidate prompt-toolkit==1.0.15 (constraint was >=1.0.15,<2.0.0)
  found candidate ptyprocess==0.5.2 (constraint was >=0.5)
  found candidate pygments==2.2.0 (constraint was <any>)
  found candidate simplegeneric==0.8.1 (constraint was >0.8)
  found candidate six==1.11.0 (constraint was >=1.9.0)
  found candidate traitlets==4.3.2 (constraint was >=4.2)
  found candidate typing==3.6.4 (constraint was <any>)
  found candidate wcwidth==0.1.7 (constraint was <any>)

Finding secondary dependencies:
  backcall==0.1.0           requires -
  prompt-toolkit==1.0.15    requires six>=1.9.0, wcwidth
  wcwidth==0.1.7            requires -
  pygments==2.2.0           requires -
  ptyprocess==0.5.2         requires -
  ipython-genutils==0.2.0   requires -
  traitlets==4.3.2          requires decorator, enum34; python_version == "2.7", ipython-genutils, six
  decorator==4.3.0          requires -
  pickleshare==0.7.4        requires pathlib2; python_version in "2.6 2.7 3.2 3.3"
  six==1.11.0               requires -
  ipython==6.3.1            requires appnope; sys_platform == "darwin", backcall, decorator, jedi>=0.10, pexpect; sys_platform != "win32", pickleshare, prompt-toolkit<2.0.0,>=1.0.15, pygments, setuptools>=18.5, simplegeneric>0.8, traitlets>=4.2, typing; python_version <= "3.4"
  jedi==0.12.0              requires parso>=0.2.0
  simplegeneric==0.8.1      requires -
  parso==0.2.0              requires -

New dependencies found in this round:
  adding [u'scandir', '', '[]']
Removed dependencies in this round:
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 3: not stable

                          ROUND 4
Current constraints:
  appnope
  backcall
  decorator
  enum34
  ipython
  ipython-genutils
  jedi>=0.10
  parso>=0.2.0
  pathlib2
  pexpect
  pickleshare
  prompt-toolkit<2.0.0,>=1.0.15
  ptyprocess>=0.5
  pygments
  scandir; python_version < "3.5"
  simplegeneric>0.8
  six>=1.9.0
  traitlets>=4.2
  typing
  wcwidth

Finding the best candidates:
  found candidate appnope==0.1.0 (constraint was <any>)
  found candidate backcall==0.1.0 (constraint was <any>)
  found candidate decorator==4.3.0 (constraint was <any>)
  found candidate enum34==1.1.6 (constraint was <any>)
  found candidate ipython==6.3.1 (constraint was <any>)
  found candidate ipython-genutils==0.2.0 (constraint was <any>)
  found candidate jedi==0.12.0 (constraint was >=0.10)
  found candidate parso==0.2.0 (constraint was >=0.2.0)
  found candidate pathlib2==2.3.0 (constraint was <any>)
  found candidate pexpect==4.5.0 (constraint was <any>)
  found candidate pickleshare==0.7.4 (constraint was <any>)
  found candidate prompt-toolkit==1.0.15 (constraint was >=1.0.15,<2.0.0)
  found candidate ptyprocess==0.5.2 (constraint was >=0.5)
  found candidate pygments==2.2.0 (constraint was <any>)
  found candidate scandir==1.7 (constraint was <any>)
  found candidate simplegeneric==0.8.1 (constraint was >0.8)
  found candidate six==1.11.0 (constraint was >=1.9.0)
  found candidate traitlets==4.3.2 (constraint was >=4.2)
  found candidate typing==3.6.4 (constraint was <any>)
  found candidate wcwidth==0.1.7 (constraint was <any>)

Finding secondary dependencies:
  parso==0.2.0              requires -
  prompt-toolkit==1.0.15    requires six>=1.9.0, wcwidth
  pygments==2.2.0           requires -
  ipython-genutils==0.2.0   requires -
  simplegeneric==0.8.1      requires -
  backcall==0.1.0           requires -
  pickleshare==0.7.4        requires pathlib2; python_version in "2.6 2.7 3.2 3.3"
  six==1.11.0               requires -
  ipython==6.3.1            requires appnope; sys_platform == "darwin", backcall, decorator, jedi>=0.10, pexpect; sys_platform != "win32", pickleshare, prompt-toolkit<2.0.0,>=1.0.15, pygments, setuptools>=18.5, simplegeneric>0.8, traitlets>=4.2, typing; python_version <= "3.4"
  jedi==0.12.0              requires parso>=0.2.0
  wcwidth==0.1.7            requires -
  traitlets==4.3.2          requires decorator, enum34; python_version == "2.7", ipython-genutils, six
  decorator==4.3.0          requires -
  ptyprocess==0.5.2         requires -
------------------------------------------------------------
Result of round 4: stable, done

Updated Pipfile.lock (ddddcd)!

Pipenv lock sets the ipython version to 6.3.1 when it should be 5.6.0. Worth noting this actually works in pipenv 10.x but not 11.

Ah, so the bug is that you are running python 2.7, and the last version of ipython to support python 2.7 was version 5.6.0, which is why version 6.3.1 is incorrect.
What if you run pipenv lock --clear? If not, can you provide pipenv-resolver --debug ipython (it will be a lot of info)

Looks like it’s grabbing the sdists and all. For the record the virtualenv python version should be all that matters. Are you using Homebrew at all? If so you should remove any pipenv installs you did with homebrew and try pip install —user —upgrade —pre pipenv. Ideally use pip 10 then also.

Using pyenv to manage environments. Tried the prerelease and pip 10 with the same results:
$ pip --version && pipenv --version && pipenv lock --clear && grep -A7 \"ipython\" < Pipfile.lock
pip 10.0.1 from /Users/rhutchison/.pyenv/versions/3.6.5/lib/python3.6/site-packages/pip (python 3.6)
pipenv, version 11.10.1.dev5
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (ddddcd)!
        "ipython": {
            "hashes": [
                "sha256:85882f97d75122ff8cdfe129215a408085a26039527110c8d4a2b8a5e45b7639",
                "sha256:a6ac981381b3f5f604b37a293369963485200e3639fb0404fa76092383c10c41"
            ],
            "index": "pypi",
            "version": "==6.3.1"
        },

I actually saw this on windows today too. I have no idea why. I don’t think we are respecting python_requires for some reason

@techalchemy @rainyday
Here are some investigations I did and I hope they help:
All the magic happens when switching the ignore_compatibility flag to False in https://github.com/pypa/pipenv/blob/master/pipenv/patched/notpip/index.py#L645. However, it is never overwritten from the grep result.
It is an easy fix but I am afraid it will break things since it will generate lock files very different from existing ones.
If it is intentional that lock files are guaranteed to work on only specific environment. Then we should remove all package versions that is incompatible with current environment from lock file.

Hey sorry for being slow. What we settled on was doing the best we can to be cross platform but single python version (so we still need this)

Also @frostming I believe this is actually caused by there being an sdist since there’s only a python 3 wheel. We just need to crack open the sdist and check the python requires. We do this... somewhere...

Fixed, I believe.

@uranusjr @techalchemy were these fixes deployed to 2018.6.25? Because if so it looks like they still haven't solved this :(
Using the same ipython Pipfile example from above:
$ pipenv lock --clear -v
Locking [dev-packages] dependencies...
Locking [packages] dependencies...
using sources: [{u'url': u'https://pypi.python.org/simple', u'verify_ssl': True, u'name': u'pypi'}]
Using pip: -i https://pypi.python.org/simple

                          ROUND 1
Current constraints:
  ipython (from -r /var/folders/rj/210lgzrd4q5ccsyby0rdxg0924842d/T/pipenv-dZ2Ugs-requirements/pipenv-AEx6XM-constraints.txt (line 2))

Finding the best candidates:
  found candidate ipython==6.4.0 (constraint was <any>)

Finding secondary dependencies:
  ipython==6.4.0 not in cache, need to check index
  ipython==6.4.0            requires appnope; sys_platform == "darwin", backcall, decorator, enum34; python_version == "2.7", ipython-genutils, ipython==6.4.0, jedi>=0.10, parso>=0.2.0, pathlib2; python_version in "2.6 2.7 3.2 3.3", pexpect; sys_platform != "win32", pickleshare, prompt-toolkit<2.0.0,>=1.0.15, ptyprocess>=0.5, pygments, scandir; python_version < "3.5", setuptools>=18.5, simplegeneric>0.8, six>=1.9.0, traitlets>=4.2, typing; python_version <= "3.4", wcwidth

New dependencies found in this round:
  adding [u'appnope', '', '[]']
  adding [u'backcall', '', '[]']
  adding [u'decorator', '', '[]']
  adding [u'enum34', '', '[]']
  adding [u'ipython', '==6.4.0', '[]']
  adding [u'ipython-genutils', '', '[]']
  adding [u'jedi', '>=0.10', '[]']
  adding [u'parso', '>=0.2.0', '[]']
  adding [u'pathlib2', '', '[]']
  adding [u'pexpect', '', '[]']
  adding [u'pickleshare', '', '[]']
  adding [u'prompt-toolkit', '<2.0.0,>=1.0.15', '[]']
  adding [u'ptyprocess', '>=0.5', '[]']
  adding [u'pygments', '', '[]']
  adding [u'scandir', '', '[]']
  adding [u'simplegeneric', '>0.8', '[]']
  adding [u'six', '>=1.9.0', '[]']
  adding [u'traitlets', '>=4.2', '[]']
  adding [u'typing', '', '[]']
  adding [u'wcwidth', '', '[]']
Removed dependencies in this round:
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 1: not stable

                          ROUND 2
Current constraints:
  appnope
  backcall
  decorator
  enum34
  ipython==6.4.0 (from -r /var/folders/rj/210lgzrd4q5ccsyby0rdxg0924842d/T/pipenv-dZ2Ugs-requirements/pipenv-AEx6XM-constraints.txt (line 2))
  ipython-genutils
  jedi>=0.10
  parso>=0.2.0
  pathlib2
  pexpect
  pickleshare
  prompt-toolkit<2.0.0,>=1.0.15
  ptyprocess>=0.5
  pygments
  scandir
  simplegeneric>0.8
  six>=1.9.0
  traitlets>=4.2
  typing
  wcwidth

Finding the best candidates:
  found candidate appnope==0.1.0 (constraint was <any>)
  found candidate backcall==0.1.0 (constraint was <any>)
  found candidate decorator==4.3.0 (constraint was <any>)
  found candidate enum34==1.1.6 (constraint was <any>)
  found candidate ipython==6.4.0 (constraint was ==6.4.0)
  found candidate ipython-genutils==0.2.0 (constraint was <any>)
  found candidate jedi==0.12.0 (constraint was >=0.10)
  found candidate parso==0.2.1 (constraint was >=0.2.0)
  found candidate pathlib2==2.3.2 (constraint was <any>)
  found candidate pexpect==4.6.0 (constraint was <any>)
  found candidate pickleshare==0.7.4 (constraint was <any>)
  found candidate prompt-toolkit==1.0.15 (constraint was >=1.0.15,<2.0.0)
  found candidate ptyprocess==0.6.0 (constraint was >=0.5)
  found candidate pygments==2.2.0 (constraint was <any>)
  found candidate scandir==1.7 (constraint was <any>)
  found candidate simplegeneric==0.8.1 (constraint was >0.8)
  found candidate six==1.11.0 (constraint was >=1.9.0)
  found candidate traitlets==4.3.2 (constraint was >=4.2)
  found candidate typing==3.6.4 (constraint was <any>)
  found candidate wcwidth==0.1.7 (constraint was <any>)

Finding secondary dependencies:
  simplegeneric==0.8.1 not in cache, need to check index
  simplegeneric==0.8.1      requires simplegeneric==0.8.1
  pygments==2.2.0 not in cache, need to check index
  pygments==2.2.0           requires pygments==2.2.0
  backcall==0.1.0 not in cache, need to check index
  backcall==0.1.0           requires backcall==0.1.0
  ipython==6.4.0            requires appnope; sys_platform == "darwin", backcall, decorator, enum34; python_version == "2.7", ipython-genutils, ipython==6.4.0, jedi>=0.10, parso>=0.2.0, pathlib2; python_version in "2.6 2.7 3.2 3.3", pexpect; sys_platform != "win32", pickleshare, prompt-toolkit<2.0.0,>=1.0.15, ptyprocess>=0.5, pygments, scandir; python_version < "3.5", setuptools>=18.5, simplegeneric>0.8, six>=1.9.0, traitlets>=4.2, typing; python_version <= "3.4", wcwidth
  ptyprocess==0.6.0 not in cache, need to check index
  ptyprocess==0.6.0         requires ptyprocess==0.6.0
  parso==0.2.1 not in cache, need to check index
  parso==0.2.1              requires parso==0.2.1
  traitlets==4.3.2 not in cache, need to check index
  traitlets==4.3.2          requires decorator, enum34; python_version == "2.7", ipython-genutils, six, traitlets==4.3.2
  jedi==0.12.0 not in cache, need to check index
  jedi==0.12.0              requires jedi==0.12.0, parso>=0.2.0
  pickleshare==0.7.4 not in cache, need to check index
  pickleshare==0.7.4        requires pathlib2; python_version in "2.6 2.7 3.2 3.3", pickleshare==0.7.4, scandir; python_version < "3.5", six
  prompt-toolkit==1.0.15 not in cache, need to check index
  prompt-toolkit==1.0.15    requires prompt-toolkit==1.0.15, six>=1.9.0, wcwidth
  wcwidth==0.1.7 not in cache, need to check index
  wcwidth==0.1.7            requires wcwidth==0.1.7
  decorator==4.3.0 not in cache, need to check index
  decorator==4.3.0          requires decorator==4.3.0
  ipython-genutils==0.2.0 not in cache, need to check index
  ipython-genutils==0.2.0   requires ipython-genutils==0.2.0
  six==1.11.0 not in cache, need to check index
  six==1.11.0               requires six==1.11.0

New dependencies found in this round:
  adding [u'appnope', '==0.1.0', '[]']
  adding [u'backcall', '==0.1.0', '[]']
  adding [u'decorator', '==4.3.0', '[]']
  adding [u'enum34', '==1.1.6', '[]']
  adding [u'ipython-genutils', '==0.2.0', '[]']
  adding [u'jedi', '==0.12.0,>=0.10', '[]']
  adding [u'parso', '==0.2.1,>=0.2.0', '[]']
  adding [u'pathlib2', '==2.3.2', '[]']
  adding [u'pexpect', '==4.6.0', '[]']
  adding [u'pickleshare', '==0.7.4', '[]']
  adding [u'prompt-toolkit', '<2.0.0,==1.0.15,>=1.0.15', '[]']
  adding [u'ptyprocess', '==0.6.0,>=0.5', '[]']
  adding [u'pygments', '==2.2.0', '[]']
  adding [u'scandir', '==1.7', '[]']
  adding [u'simplegeneric', '==0.8.1,>0.8', '[]']
  adding [u'six', '==1.11.0,>=1.9.0', '[]']
  adding [u'traitlets', '==4.3.2,>=4.2', '[]']
  adding [u'typing', '==3.6.4', '[]']
  adding [u'wcwidth', '==0.1.7', '[]']
Removed dependencies in this round:
  removing [u'appnope', '', '[]']
  removing [u'backcall', '', '[]']
  removing [u'decorator', '', '[]']
  removing [u'enum34', '', '[]']
  removing [u'ipython-genutils', '', '[]']
  removing [u'jedi', '>=0.10', '[]']
  removing [u'parso', '>=0.2.0', '[]']
  removing [u'pathlib2', '', '[]']
  removing [u'pexpect', '', '[]']
  removing [u'pickleshare', '', '[]']
  removing [u'prompt-toolkit', '<2.0.0,>=1.0.15', '[]']
  removing [u'ptyprocess', '>=0.5', '[]']
  removing [u'pygments', '', '[]']
  removing [u'scandir', '', '[]']
  removing [u'simplegeneric', '>0.8', '[]']
  removing [u'six', '>=1.9.0', '[]']
  removing [u'traitlets', '>=4.2', '[]']
  removing [u'typing', '', '[]']
  removing [u'wcwidth', '', '[]']
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 2: not stable

                          ROUND 3
Current constraints:
  appnope==0.1.0
  backcall==0.1.0
  decorator==4.3.0
  enum34==1.1.6
  ipython==6.4.0 (from -r /var/folders/rj/210lgzrd4q5ccsyby0rdxg0924842d/T/pipenv-dZ2Ugs-requirements/pipenv-AEx6XM-constraints.txt (line 2))
  ipython-genutils==0.2.0
  jedi==0.12.0,>=0.10
  parso==0.2.1,>=0.2.0
  pathlib2==2.3.2
  pexpect==4.6.0
  pickleshare==0.7.4
  prompt-toolkit<2.0.0,==1.0.15,>=1.0.15
  ptyprocess==0.6.0,>=0.5
  pygments==2.2.0
  scandir==1.7
  simplegeneric==0.8.1,>0.8
  six==1.11.0,>=1.9.0
  traitlets==4.3.2,>=4.2
  typing==3.6.4
  wcwidth==0.1.7

Finding the best candidates:
  found candidate appnope==0.1.0 (constraint was ==0.1.0)
  found candidate backcall==0.1.0 (constraint was ==0.1.0)
  found candidate decorator==4.3.0 (constraint was ==4.3.0)
  found candidate enum34==1.1.6 (constraint was ==1.1.6)
  found candidate ipython==6.4.0 (constraint was ==6.4.0)
  found candidate ipython-genutils==0.2.0 (constraint was ==0.2.0)
  found candidate jedi==0.12.0 (constraint was >=0.10,==0.12.0)
  found candidate parso==0.2.1 (constraint was >=0.2.0,==0.2.1)
  found candidate pathlib2==2.3.2 (constraint was ==2.3.2)
  found candidate pexpect==4.6.0 (constraint was ==4.6.0)
  found candidate pickleshare==0.7.4 (constraint was ==0.7.4)
  found candidate prompt-toolkit==1.0.15 (constraint was ==1.0.15,>=1.0.15,<2.0.0)
  found candidate ptyprocess==0.6.0 (constraint was >=0.5,==0.6.0)
  found candidate pygments==2.2.0 (constraint was ==2.2.0)
  found candidate scandir==1.7 (constraint was ==1.7)
  found candidate simplegeneric==0.8.1 (constraint was >0.8,==0.8.1)
  found candidate six==1.11.0 (constraint was ==1.11.0,>=1.9.0)
  found candidate traitlets==4.3.2 (constraint was >=4.2,==4.3.2)
  found candidate typing==3.6.4 (constraint was ==3.6.4)
  found candidate wcwidth==0.1.7 (constraint was ==0.1.7)

Finding secondary dependencies:
  pickleshare==0.7.4        requires pathlib2; python_version in "2.6 2.7 3.2 3.3", pickleshare==0.7.4, scandir; python_version < "3.5", six
  backcall==0.1.0           requires backcall==0.1.0
  pygments==2.2.0           requires pygments==2.2.0
  ipython-genutils==0.2.0   requires ipython-genutils==0.2.0
  six==1.11.0               requires six==1.11.0
  prompt-toolkit==1.0.15    requires prompt-toolkit==1.0.15, six>=1.9.0, wcwidth
  parso==0.2.1              requires parso==0.2.1
  wcwidth==0.1.7            requires wcwidth==0.1.7
  decorator==4.3.0          requires decorator==4.3.0
  ptyprocess==0.6.0         requires ptyprocess==0.6.0
  jedi==0.12.0              requires jedi==0.12.0, parso>=0.2.0
  simplegeneric==0.8.1      requires simplegeneric==0.8.1
  ipython==6.4.0            requires appnope; sys_platform == "darwin", backcall, decorator, enum34; python_version == "2.7", ipython-genutils, ipython==6.4.0, jedi>=0.10, parso>=0.2.0, pathlib2; python_version in "2.6 2.7 3.2 3.3", pexpect; sys_platform != "win32", pickleshare, prompt-toolkit<2.0.0,>=1.0.15, ptyprocess>=0.5, pygments, scandir; python_version < "3.5", setuptools>=18.5, simplegeneric>0.8, six>=1.9.0, traitlets>=4.2, typing; python_version <= "3.4", wcwidth
  traitlets==4.3.2          requires decorator, enum34; python_version == "2.7", ipython-genutils, six, traitlets==4.3.2
------------------------------------------------------------
Result of round 3: stable, done

Updated Pipfile.lock (ddddcd)!

Seems the fix was reverted in https://github.com/pypa/pipenv/commit/c31a311dc7fbd2e523fa16b60a8508a2e71a5471. @techalchemy , was it by mistake?

Test case for this specifically was a bit difficult, if you can come up with one I’d appreciate it. I think I see the line that’s missing which needs to be included. I’ll check when I get to the office

ugh, we used to do that but it was not fun.
I meant to fix this, do I get points for that ?! :p

tested and it is in today's release. thanks for your hard work guys.


Customized file name with lang when distributing

Is there a way to customize a file name with specified language when distributing?
For example,
/* now */
files: {
  "dist/subfolder/index.html": "www/subfolder/index.jade"
}

then files generated are "dist/subfolder/zh_CN/index.html" and "dist/subfolder/en_US/index.html", but I want it to be "dist/zh_CN/subfolder/index.html".  So I need something like this:
/* wanted */
files: {
  "dist/{{language}}/subfolder/index.html": "www/subfolder/index.jade"
}

So {{language}} will be filled with "zh_CN" and "en_US" during different distributes.

You cannot do that at Grunt runtime level.
You should use another task to copy files to the desired folder structure


Ability to pull previous consumption for X previous days

Describe the feature
Talking to Octopus support almost every month due to export previous consumption sometimes doesn't come through in days. Sometimes also actual import consumption. It is frustrating as I have to manually inject these values to reflect the missing import export.
Expected behaviour
Pull data for X previous days and inject into DB.
Use Case
Octopus have no fix for this unfortunately. They say sometimes their system need to catch up and verify data from the 3rd parties before it is available to users.
Confirmation

[X] By submitting this feature request, you agree that you have read the documentation and confirmed it does not already exist
[X] I am willing/able to help contribute to the solution of this feature

Hello and sorry you're having issues. You can adjust the number of days the sensor looks back at when pulling through data if your meter consistently reports data late (e.g. always look at data 2 days behind).
There is also an existing action/service which allows you to refesh the statistics sensors linked to the previous consumption sensors from a given point in time. It can't load data into the history of the sensors themselves as none of the HA APIs seem to support this. This is not done automatically as data can be missing for a variety of reasons (e.g HA loses connection to OE servers) and doing so automatically could end up in pulling a large volume of data providing strain on OE servers and the users internet connection (which could be metered)

That's great and thanks for the quick response.
It has been 6 days now so will have to contact them again.
Might be a silly question but where is this action/service located or how can I run it please? I couldn't find it anywhere.

Also I see it is only for import and gas at the moment. Would it be possible to have it available for export consumption as well as all _cost entities?

The service/action can be run via an automation (not recommended) or via the developer tools.
It can be run against the export variants of the specified sensors and as stated will update both the consumption and cost variants of the related statistics sensors.

Tried the offset and it kind of worked. But had to do one change for each missing day but at least it added them to the history so that's good.

I assume by this you mean you updated the offset to be 5 (for example), let it update, then updated to 4, etc?
As mentioned, this configuration is more of a long term change for those whose meters are always behind. There is a proposition to change this behaviour so that the sensor will automatically shift. This won't add any days between the last successful pull of information and the latest available information.

In terms of the action/service that did not work. In the notifications it said started/finished but not changed or added anything and tried both gas and electricity.

Were you checking the entities themselves or the statistics sensors (the ones described in the energy dashboard setup docs)? If the former, as previously mentioned the service cannot update the history of the entities themselves as the last time I checked HA didn't properly support it (it appeared to initially work and then a negative spike occurred of the total data added appeared). I have it on my list to investigate again, but other things are higher up the list. If it was the latter, did you have any errors in your logs?

That's correct.
Ah good thought on the proposition. Understandable it is not a priority. Bear in mind there are few scenarios such as consumers with multiple days missing and then when you phone them they load all of it in but maybe with gaps between days which also happened to me. So Mon nothing, Tue there was and Wed nothing etc. Would have to ignore the working days if you re-run after again I guess.
I was checking the entities so fair play. Not sure how the statistics would help me in this case to be honest. I think the offset will do it for now.

If you have multiple days missing, that is outside of the scope, design and functionality of the sensors. This is why the service exists for those edge case scenarios. Same as adding the integration for the first time with years worth of data available on OE servers.
The statistics sensors are built for the energy dashboard as they break the data down into hourly chunks. These sensors tmk can be used with other things like apex charts.

Ok that's great. Thanks for your help.


question about linebreaks

Just for my understanding of the linebreak option: If I set linebreak to true like in your example:
echo Parsedown::instance()
   ->setBreaksEnabled(true) # enables automatic line breaks
   ->text("1st line \n 2nd line");

then I get the linebreak. But if I switch linebreaks off and use two or more spaces before the break like this:
echo Parsedown::instance()
   ->setBreaksEnabled(false) # disables automatic line breaks
   ->text("1st line \n 2nd line"); # used two spaced here before \n

then I get the linebreak, too. I have seen, that this is the defined markdown-behavior, so the functionality of setBreaksEnabled() is simply to reduce two spaces to one space?
My expection was that linebreaks are totally turned off and only turned on if setBreaksEnabled is true. Also I am not sure if this is a new behavior? Because in my old code, the line-breaks do not work by default.
By the way, the new version of parsedown is really really cool, I was able to reduce my custom-code to 50% now, that was a great surprise :)

According to markdown implementation, newline is added after 2 whitespaces. Parsedown follows that, but along with it have introduced an easier method by just pressing enter when automatic breaks are enabled.


added Spin the wheel

Please resolve merge conflict

Please resolve merge conflict

i have resolved merge conflict.

please help resolve this


Preventing collisions

Is there a way to make static bodies to not collide with each other?

Well currently static bodies will report collisions but will trigger no force. A mechanism to filter collisions already exists on ncollide (cf. CollisionGroups) though they are not completely exploited by nphysics yet.
In the mean time, a work-around may be to test if the collisions that were reported to you involve only static rigid bodies (for which the rigid_body.can_move() method will return false).

The problem is not that I want to detect if the colliding bodies are static, but that if I have static bodies colliding it will slow down the simulation to crawl.

@sebcrozet You probably just answer to my question in the message above, is it possible to use the CollisionGroups when adding a body to the world ?
It seems that .add_body() already fix a collisionGroup, which gives a real world physic...

@Kerosene2000 Not it is not yet possible. There are still two features related to CollisionGroups to be implemented:

Allowing the user to pass its own collision group to the physics engine at rigid-body construction time. This should be implemented soon.
Allowing the user to change the collision group of a rigid body after it has been added to the scene. This one involves some intricate development on ncollide so it is much more complicated and won't be added in the very short term.

I am actually working on a project that will need the collisionGroups at the rigid body creation.
What means soon for you ? :smile:
If you want, you can let me work on the code in progress, if you don't have time, I will be glad to work on this crate !

@Kerosene2000 I'd say soon equals a week or so. I wanted to have a first implementation of #20 before tackling this. If you want to give it a try, I've provided some outlines on the issue #55 I just created for that.


Apex Legends support

Apex legends was just updated with Razer Chroma support. Adding a wrapper for Aurora would be fantastic.

You should label this room for "game support" so that the devs can easily find this room :)

We've had this discussion on Discord and unfortunately the user reported that the wrapper was blocked by Easy Anti-Cheat (EAC) and wasn't allowed to be loaded. There's unfortunately nothing we can do about this.
You can easily prove this for yourself by adding Apex into Aurora using the plus button on the left menu and selecting the exe and add a wrapper layer to the new profile. Then go to settings, 'Devices & Wrappers' and 'Install Aurora Wrapper Patch for Razer'.

You should label this room for "game support" so that the devs can easily find this room :)

whoops, didn't know how to label

damn easy cheat blocks everything but the cheaters I guess.

this seems to be working now since i tried it and it's enabled + success on r5apex.exe

Confirmed that just now, but the chroma and wrapper layer are not doing anything.

Hello, may I ask how to make Apex Legends work with Aurora? I installed Aurora on my pc but there is no Apex Legends on it.

Hello, may I ask how to make Apex Legends work with Aurora? I installed Aurora on my pc but there is no Apex Legends on it.

Hi, it has been quite a while and I have not tested it since.
Yet it did work, I think I had to add it manually and use the Razer wrapper. Don't know if it is still possible though.
from what I can remember I added the r5apex.exe to aurora.


FLAKE E2E: [FAIL] MagicCatalog when an existing magic catalog exists [It] should succeed when the magic catalog is updated

Flaky Test Report
This is occurring more and more frequently.
Summarizing 1 Failure:
[FAIL] MagicCatalog when an existing magic catalog exists [It] should succeed when the magic catalog is updated
/home/runner/work/operator-lifecycle-manager/operator-lifecycle-manager/test/e2e/magic_catalog_test.go:71

Failure Log Link
Failure Log
You can get the link by clicking on the line number in the job logs and copying the url from your browser.
Relevant Failure Log

------------------------------
• [FAILED] [322.714 seconds]
MagicCatalog when an existing magic catalog exists [It] should succeed when the magic catalog is updated
/home/runner/work/operator-lifecycle-manager/operator-lifecycle-manager/test/e2e/magic_catalog_test.go:66

  Captured StdOut/StdErr Output >>
  Using the kubectl kubectl binary
  Using the artifacts/magic-catalog-e2e-78gnv output directory
  Storing the test artifact output in the artifacts/magic-catalog-e2e-78gnv directory
  Collecting get catalogsources -o yaml output...
  Collecting get subscriptions -o yaml output...
  Collecting get operatorgroups -o yaml output...
  Collecting get clusterserviceversions -o yaml output...
  Collecting get installplans -o yaml output...
  Collecting get pods -o wide output...
  No resources found in magic-catalog-e2e-78gnv namespace.
  Collecting get events --sort-by .lastTimestamp output...
  << Captured StdOut/StdErr Output

  Timeline >>
  created the magic-catalog-e2e-78gnv testing namespace
  created the magic-catalog-e2e-78gnv/magic-catalog-e2e-78gnv-operatorgroup operator group
  [FAILED] in [It] - /home/runner/work/operator-lifecycle-manager/operator-lifecycle-manager/test/e2e/magic_catalog_test.go:71 @ 01/04/24 15:09:48.772
  collecting the magic-catalog-e2e-78gnv namespace artifacts as the 'should succeed when the magic catalog is updated' test case failed
  collecting logs in the ./artifacts/ artifacts directory
  tearing down the magic-catalog-e2e-78gnv namespace
  resetting e2e kube client
  deleting magic-catalog-e2e-78gnv/mc-e2e-catalog-p4p4r-pod
  deleting magic-catalog-e2e-78gnv/mc-e2e-catalog-p4p4r-configmap
  deleting magic-catalog-e2e-78gnv/mc-e2e-catalog-p4p4r
  deleting magic-catalog-e2e-78gnv/mc-e2e-catalog-p4p4r-svc
  deleting magic-catalog-e2e-78gnv/mc-e2e-catalog-p4p4r-pod
  deleting magic-catalog-e2e-78gnv/mc-e2e-catalog-p4p4r-configmap
  deleting magic-catalog-e2e-78gnv/magic-catalog-e2e-78gnv-operatorgroup
  deleting <global>/magic-catalog-e2e-78gnv
  garbage collecting CRDs
  << Timeline

  [FAILED] Expected
      <wait.errInterrupted>:
      timed out waiting for the condition
      {
          cause: <*errors.errorString | 0xc0001b8110>{
              s: "timed out waiting for the condition",
          },
      }
  to be nil
  In [It] at: /home/runner/work/operator-lifecycle-manager/operator-lifecycle-manager/test/e2e/magic_catalog_test.go:71 @ 01/04/24 15:09:48.772

  Full Stack Trace
    github.com/operator-framework/operator-lifecycle-manager/test/e2e.glob..func17.4.3()
    	/home/runner/work/operator-lifecycle-manager/operator-lifecycle-manager/test/e2e/magic_catalog_test.go:71 +0x323
------------------------------

In the logs of the failed run, I found this:
2024-01-04T15:25:28.739907535Z stderr F time="2024-01-04T15:25:28Z" level=info msg="state.Key.Namespace=magic-catalog-e2e-d2mqw state.Key.Name=mc-e2e-catalog-b79bv state.State=CONNECTING"
2024-01-04T15:25:29.762994465Z stderr F time="2024-01-04T15:25:29Z" level=info msg="state.Key.Namespace=magic-catalog-e2e-d2mqw state.Key.Name=mc-e2e-catalog-b79bv state.State=TRANSIENT_FAILURE"
2024-01-04T15:25:39.419490022Z stderr F time="2024-01-04T15:25:39Z" level=info msg="state.Key.Namespace=magic-catalog-e2e-d2mqw state.Key.Name=mc-e2e-catalog-b79bv state.State=READY"
2024-01-04T15:25:39.547681038Z stderr F time="2024-01-04T15:25:39Z" level=info msg="state.Key.Namespace=magic-catalog-e2e-d2mqw state.Key.Name=mc-e2e-catalog-b79bv state.State=IDLE"

So it gets to READY, but then very quickly moves to IDLE.
I suspect this is the underlying issue. the state never moves back to READY. My hunch here is that there is a race condition between (a) this READY to IDLE transition and (b) the e2e checking for READY.

if (a) wins, the test flakes
if (b) wins, the test continues.

A quick fix here for this particular test might be to allow either READY or IDLE.
A better fix may be to have the catalog operator perform its own health checks, which should keep its connection in the READY state.

See discussion: https://kubernetes.slack.com/archives/C0181L6JYQ2/p1704381324922659

Though it isn't clear to me why the connection would move so quickly from READY to IDLE. It seems like we need to better understanding of why that is happening before we decide on a more permanent fix.

I did a few things:

I started up opm serve with the operatorhub catalog and using the same version of opm that it seems the e2e would use (latest). Then I ran a very short program that I wrote using the same grpc-go client library version that OLM is using that essentially just does grpc.Dial and then reports connection state changes. I ran it a few times, and each time the connection stayed in the READY state for the full 30m (the default idle timeout) before moving to IDLE.
I went dumpter diving to the GRPC client code that manages the connection state, and I don't see anything that stands out that would explain why the connection goes from READY to IDLE so quickly.

Next up, I'm going to try finding other examples of this flake to check to see if they all share this READY to IDLE transition. If so, I'll submit a PR that turns on GRPC logging/tracing so that we can hopefully get a better idea about what's going on.

Ah, one more interesting observation: with my experiment from (1), I killed the opm serve command while the client was running and in the READY state. That caused the server to send a GOAWAY and close the connection. And that caused the client to immediately move to the IDLE state.
After restarting the server, I noticed that my toy client did not attempt to re-establish the connection. I assume it won't until a subsequent RPC call is made.
Here's a hypothesis:

e2e test creates catalog.
Server starts, connection goes to READY, catalog operator successfully queries what it needs.
Server is killed (don't know the reason yet)
Catalog operator's GRPC client observes (2) and sets state to IDLE and updates catalog source status to IDLE
e2e test begins waiting for READY state to be observed in the catalog source status
e2e test timeout (5m) occurs prior to the catalog operator deciding to make another RPC (which would move the status from IDLE to READY)

As expected, when I update my toy client to ping the server for health checks on a short-ish interval, the connection state moves from IDLE back to READY after the server comes back up and the health RPC call is attempted.


Support for amphp/file v2

This amphp library is blocking the amphp/file v2 upgrade in our dependency chain.

Adding support for v2 should be straight forward. Do you want to take a look?

I will likely not get to it in the next weeks. But probably no one else will run into this "issue" on the same time span. If it's still open when I get back to this, I'll look into it.

It seems amphp/file isn't used all that much here. I think you just need to allow it in composer,json + add a class_exists condition here.

I did this time time ago and failed to ever tag a version – too busy with Amp v3 I suppose.


Measure Kubernetes API performance

Develop synthetic workload tests to measure basic Kubernetes API performance. Since tests will run on shared resources (e.g. GCE) individual tests should be run N times to weed out any statistical outliers from the performance results.

We created some "hello world" type container-pairs using Dockerfiles for app-stacks that are common for our customers.  The hello world pages take an argument/switch that optionally runs a db query.  i.e. http://host/index.php?DB=true.  Then we blow out N-number of these container pairs that use Docker links.  DB=true runs an un-cacheable query to model worst case performance scenario.  Then we fire http workload generators at it.

@saad-ali This has some good ideas for the workload generator.

@timothysc  @rrati (please cc Jay too) Thanks for looking into Kubernetes performance related issue. You can use this issue to dump the information you guys collected recently.

@wojtek-t @fgrzadkowski

cc/ @jayunit100

I would like to /metrics and /debug from the api-server as options on some of the e2e tests.

@timothysc if you want us to add new metrics in API server or other components, please reopen #1625 and list them there.

This is very related to #3139 so I'm assigning to @piosz
/cc @fgrzadkowski @wojtek-t

We already have some metrics, e.g.:
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/apiserver/apiserver.go#L59
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/apiserver/apiserver.go#L68
And code to verify them in e2e tests:
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/test/e2e/util.go#L780

+1 to @fgrzadkowski , we're already gathering and plotting.
Are there other metrics that folks are interested in?

It seems we are measuring what we are currently interested in.
If we want to measure something else, we can create a dedicated new issue for it.


creating a branch via an issue bases the branch on the creation date of the issue

creating a branch directly from the arrow showing next to the issue  in VS Code seems to rebase the branch on the date of creation of the issue. Is there anyway to avoid/set this? Any support will be nice!
VS code version 1.64.0

@fraziercs2i let me make sure I understand:

You "Start working" on an issue from the arrow next to the issue.
A branch is created for you.
You do some work, but don't finish in one day so you stop working on the issue and check out another branch.
Some days later you "Start working" on the same issue again using the arrow next to the issue.
The branch's head pointer is at the same place you left it. Instead, you want the branch to be updated.

Is that correct?

@alexr00 yes it is correct! Thank you for responding.


Basic client demo setup

This contains a basic vue setup (essentially vue create) + client docker setup + getting a minimal parameterized query to run. It should produce something like this:

It does work, but there's an error in the browser console
TypeError: "_vm.item is undefined"
    render HelloWorld.vue:26

Thanks for noticing that. I think it tried to display the label once the user had entered the item id, which happened before the query actually ran. Should be fixed with c43a9295601d70e2c0876fa1a710217e62375bea :+1:


Asset Mapper Support

Hi, what do you think support for Asset mapper?

Hi, yes AssetMapper looks great but I need to study it more as it's a relatively recent addition to the Symfony ecosystem and I haven't had the chance to use it a lot yet.
I definitely plan to add support for it since it's recommended for new projects
I'll probably have the time to check this out more in the coming weeks 👍


settings: Disable auto-hide on right pane scrollbar

Closes #11694.
Personally I’m not sure I agree with this change. #11694 describes a bug where the scrollbar would fail to appear, and that bug has now been fixed by #11792. So I’m not convinced it should be necessary to make the scrollbar even more persistent.
But, if we decide this is a change we want, here it is.
(The first commit, replacing imperative ui.set_up_scrollbar() calls with the declarative <div data-simplebar> syntax, seems like a nicer way to create SimpleBars either way.)
Testing Plan: Ran test-js-with-node, test-js-with-casper, manual tests.

I merged the first commit, since indeed that seems like a great improvement.
@rishig for revisiting whether we want the always-on behavior on that scrollbar (also note it's a 1-line change to enable that if there are other scrollbars that we think need it).

I see Anders' point, though I think my inclination is to still have it always-on, and ideally even a bit darker/more contrasty than we have now. I think given that admins only rarely visit the settings pages, it's more important for them to realize that there is stuff under the fold, than for the page to look nice.
I saw another product do: scrollbar is on if the mouse is anywhere over the right pane, and off otherwise, which I think also works well, if we wanted to hide the scrollbar in some cases. In their case the scrollbar has very high contrast with the underlying background.

I saw another product do: scrollbar is on if the mouse is anywhere over the right pane, and off otherwise, which I think also works well, if we wanted to hide the scrollbar in some cases.

SimpleBar doesn’t have that particular behavior as an option.
On #10544 you said:

If it's in a modal .. we should consider using the browser scrollbar, but if we can't, we should use a high-contrast, always-on scrollbar.

I don’t think there’s a reason not to use the browser scrollbar here, and I think I’d prefer it too—should we just do that?
(Meanwhile, I’ll see what we can do about the SimpleBar contrast; I set it to gray to avoid needing separate colors for night mode, but we should probably just have separate colors.)

Merged, thanks @andersk!  @rishig can you open a follow-up issue with additional widgets that should have this?  (Or possibly a PR that changes them -- it's 1 line-change to the HTML, so probably pretty easy to just do)

Opened as #12434 and #12435


Add BitHumb

Url:
https://www.bithumb.com/u1/US127
Tasks:

[ ] Tests
[ ] REST Wrapper
[ ] Pair Formatter
[ ] Interface

@nlsdfnbch I had added pair/ticker/orderbook/wallet of CoinOne/BitHumb/CEX.IO in my fork dev branch

@ajeep8 what are you waiting to submit a PR? ;)

@firepol I just copy&modify the pair/ticker/orderbook/wallet of CoinOne/BitHumb/CEX.IO/CoinNest/Exmo/Gate.IO, but other methods are neither completed or removed, so it seem unsuitable for submit yet. I will complete or remove the uncompleted method when I have time.


Empty string parameters are not passed correctly to choco.exe

When a user provides an empty string as the value of a parameter, such as --parameters or --install-arguments (which is perfectly legal by choco.exe rules), the empty string is not quoted in the command line passed to choco.exe, so it effectively "disappears", breaking the command line (because the next nonblank token will be interpreted as the value of that parameter and all following parameters will be parsed incorrectly).
Example:
Install-ChocoPackage -Name cpu-z -Parameters ''
This should be a valid invocation and would work correctly from cmd.exe (choco install cpu-z --parameters ""). However, with Foil, the command line passed to choco.exe will be either
choco install cpu-z --parameters
or
choco install --parameters cpu-z
(the ordering is not deterministic, because the parameters do not have OriginalPosition defined in Foil and are put in a hashtable, so there are no guarantees and the ordering may change between, for example, .NET versions, including monthly patches)
Both possible command lines sent by Foil are obviously broken.
The root problem seems to be in Crescendo (I've submitted https://github.com/PowerShell/Crescendo/issues/100) and is a consequence of unfortunate PowerShell behavior with regard to passing parameters to native executables, which Crescendo does not take into account.
Considering that the upstream issue may take time to fix (it may be seen as controversial/by design), perhaps it would be best to make Foil immune to it. Given that choco supports also the "equals" syntax (--package-parameters="foo bar"), changing the parameter definitions in Foil to use that syntax might fix the problem without depending on Crescendo changes.

Good catch - all the other optional string-type command parameters use the 'equals' syntax, but --parameters and --install-arguments aren't.


Fix fade_beats defined as int in audio_stream_interactive.h

fixes #99172
changed type in audio_stream_interactive.h line 103

Thanks!


Create onboarding_guide.rst

Adds guidance to service teams for onboarding new command modules. Supplemental material.
cc/ @mayurid

I think we should also add a section on how to reach out to the CLI team.  Realistically, only XRP has a 'CLI contact', and in most cases, they would not know who that is.  We should instead put up the team alias.
Additionally, maybe not for this first draft, we should consider integrated the 'teams' based approach being tried by Storage/Portal (we should bring this up in SCRUM)

Maybe also a section on relative amount of work and time they should expect from the process?

@JasonRShaver the idea is that you and/or @mayurid would give the onboarding team the contact info of one of the CLI devs and that dev would be the one to do the kickoff meeting, command reviews and PR review, and that choice will likely depend on other factors.  I can put the generic workgroup alias for general questions, and/or links to our public question channels. On that note... which ones would you want?
For time estimates, it really depends on the scope of their module and, hopefully I stressed this in the guide, the amount of early feedback and periodic review they get from us. Trying to charge ahead blindly takes a long time spent fumbling, and then a lot of time to review (because it will usually have a lot of issues) and then a lot of rework time. So I'm not sure I could say anything not incredibly vague on that.


Segmentation fault

Hey, I wrote OCaml bindings for this library and while testing with random variables I got segmentation fault error.
I tried with the Python binding, the same error occurs.
Here is the data that can reproduce the error:
points = np.array([
    [2.8982, -2.7502],
    [2.0700, 4.6681],
    [-3.3455, -0.8006],
    [0.7183, 4.6198],
    [-0.7986, -1.7616],
    [4.1368, 1.7246],
    [3.7679, 4.1976],
    [3.2638, 2.1536],
    [1.8979, 1.6000],
    [2.7282, -3.5276],
    [-2.4856, 2.7415]])

gdb tells me it fails on following line:
pargeo::parBufCollect<std::tuple<pargeo::_point<2, double, double, pargeo::_empty>*, pargeo::_point<2, double, double, pargeo::_empty>*, double> >(pargeo::parBuf<std::tuple<pargeo::_point<2, double, double, pargeo
::_empty>*, pargeo::_point<2, double, double, pargeo::_empty>*, double> >**, unsigned long)::{lambda(unsigned long)#1}::operator()(unsigned long) const::{lambda(unsigned long)#1}::operator()(unsigned long) const (
parent=<optimized out>, __closure=<optimized out>) at parBuf.h:154
154                              all[vecSizes[p] + buf->m_parentSizes[parent] + elem] = buf->m_parent[parent][elem];

I've began debugging it and trying to understand where the error might come from but I decided to submit an issue if you might have an answer or a hint.

Thanks for your feedback. I will try to reproduce the error and see what's wrong. Could you let me know the minPts value that you used to get the segfault?

I see, thanks. I will try to see what's wrong with the code.

Hi, I had some trouble reproducing the error you had. I tried your input data using both the executable and the Python binding, and they seem to work fine. I tried to valgrind the executable but no memory errors were reported. Did you figure out what's wrong?
If you let me know the hardware and OS you are using it may also be helpful.

Please open a new issue if the problem persists. Thank you for your feedback.

I will try to come back to this issue when I have some free time.


Add social cards and preview info

Add social cards and preview info for better share-out of site content.

[x] Request social card art from design-shop based on agreed name/logo
[x] Determine which parameters get included in preview
[ ] Test on all major social platforms

Card content tests OK, but I think the image isn't going to work correctly until we cut over to the actual domain: docs/.vuepress/config.js specifies a DEPLOY_DOMAIN that I believe is used as the base for the relative path of the URL for the social card image.
Closing this issue, but adding a to-do in the launch checklist in https://github.com/protocol/nft-website/issues/7 to confirm we are OK once DNS is set up.


Grunt git_changelog doesn't work

I am trying to use this plugin but doesn't work.
Every time I try to run task git_changelog the console show me log Warning: Task "git_changelog" not found. Use --force to continue

Hi Mauricio, how did you installed It? Have you used the -g option to
install It?
Are you under another OS different than Linux?
El 17 oct. 2016 12:11 p. m., "Maurizio Battaghini"<EMAIL_ADDRESS>escribió:

I am trying to use this plugin but doesn't work.
Every time I try to run task git_changelog the console show me log Warning:
Task "git_changelog" not found. Use --force to continue
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rafinskipg/git-changelog/issues/59, or mute the
thread
https://github.com/notifications/unsubscribe-auth/ABGXAHREFpqkRNXjcGtBkgcX75ZXxXQyks5q00nNgaJpZM4KYc0D
.


clientcert never initialized (IDFGH-5771)

Environment

Development Kit:      any (esp32 lolin lite)
Kit version (for WroverKit/PicoKit/DevKitC): N/A
Module or chip used:  ESP32
IDF version (run git describe --tags to find it): esp-idf-v4.3
Build System:         idf.py
Compiler version (run xtensa-esp32-elf-gcc --version to find it): xtensa-esp32-elf-gcc (crosstool-NG esp-2020r3) 8.4.0
Operating System:     Linux
(Windows only) environment type: N/A
Using an IDE?: No
Power Supply:         USB

Problem Description
When establishing a client-server connection via esp-https-server (so esp32 runs a web server), it's not possible to inspect the client certificate of the https connection.
That's because the certificate is never copied to the clientcert field in the esp-tls layer.
//Detailed problem description goes here.
Suggested fix : do this at the end of esp_mbedtls_server_session_create() by calling mbedtls_ssl_get_peer_cert().
I would give a more detailed diff but I don't see exactly how to copy a mbedtls_x509_crt structure. My current proof of concept has this code :
  mbedtls_ssl_context *ssl = &tls->ssl;
  mbedtls_x509_crt *cert = mbedtls_ssl_get_peer_cert(ssl);
  tls->clientcert = *mbedtls_ssl_get_peer_cert(ssl);

but the last line is obviously wrong as it doesn't get allocation right, and my sample code then crashes on memory allocation code (mbedtls_x509_crt_free is in the panic call stack).
Expected Behavior
For the clientcert field not to be unused in the entire code base
Actual Behavior
The clientcert field only has code that frees it if non-zero.
Code to reproduce this issue
Is rather large, sorry.
https://sourceforge.net/p/emptyesp32/code/HEAD/tree/https/

Hi @dannybackx, by default the server is used with MBEDTLS_SSL_VERIFY_NONE option. In that case no peer certificate is asked by the server and thus the output of mbedtls_ssl_get_peer_cert(ssl) is always NULL.
When the appropriate CA certificate is provided in the server configuration for client authentication. Then internally the client certificate obtained at the time of handshake (peer certificate) is verified against the provided CA certificate.
I agree the clientcert field is unused in the entire code-base in case of the server. But it is used in case of client. and since the esp-tls server and client share the same esp_tls_t structure, It remains unused in case of server.
For the code that you have mentioned to work we will have to create a pointer of the type mbedtls_x509_crt *clientcert_ptr and then set this ptr with the output of the mbedtls_ssl_get_peer_cert(ssl).
Is there any reason/requirement in you code for inspecting the peer certificate ?

I want access to the certificate for authentication.

Hi @dannybackx, I am not sure why you want to access the certificate for authentication when you can just tell mbedtls to do the authentication for you, without having to worry about the peer cert.
Anyways,
Even if the code change is made according to your suggestion. I am not sure how you will be able to access the esp_tls_t structure from esp_https_server, as it is internally handled and I think the TLS context for a particular session is currently not exposed publicly.

Maybe I should have said authorization.
As far as I know the builtin mechanism, even with mutual authentication, will only assess that both parties in the communication have valid certificates. I need to go a step further.

Also my sample code above shows that mbedtls_ssl_get_peer_cert() exposes the peer certificate. So it is available, it just needs to be extracted by the esp_https_server.

Hi @dannybackx
I have prepared a patch, which allows you to access the peer certificate when a new ssl connection is formed.
Please take a look
get_peer_certificate.patch.zip

This works, thanks.
Is there any chance to merge this with the general branch ?

@dannybackx Yes, thanks for the suggestion. Yes we plan to merge it the master and then it would a part of the upcoming release. ( It would not be a part of already released branches, considering its a new feature).

Perfect, thanks

Pff reported in August. Four months later, still not in the newest release.

Hi @dannybackx Please check that the respective  user callback  has already been added in the esp_https_server.


fix(nuxt): components auto-import for JSX

🔗 Linked issue
fix #14862

❓ Type of change

[ ] 📖 Documentation (updates to the documentation, readme or JSdoc annotations)
[x] 🐞 Bug fix (a non-breaking change that fixes an issue)
[ ] 👌 Enhancement (improving an existing functionality like performance)
[ ] ✨ New feature (a non-breaking change that adds functionality)
[ ] 🧹 Chore (updates to the build process or auxiliary tools and libraries)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

📝 Checklist

[ ] I have linked an issue or discussion.
[ ] I have updated the documentation accordingly.

You could open an issue to track it - I think we could support this for *.{js,ts,jsx,tsx} files 🙏


Error caused by two files with same name with different case and extensions

Module not found: Error: [CaseSensitivePathsPlugin] `/[path]/components/screener/screener.jsx` does not match the corresponding path on disk `Screener.jsx`.

This error was caused by having both a screener.json file and a Screener.jsx file. I confirmed this was the case by renaming the json file and having the error go away.
When importing, the JSON file was always imported with its extension whereas the JSX file was imported without (error did not go away even if I explicitly imported with .jsx extension).

I'll take a look when I get a chance.
In the meantime, what version of the plugin are you on? There's been some internal structure changes lately.

I have same issue, by having register directory and Register.js file in same location:
Cannot find file: 'register.js' does not match the corresponding name on disk: './src/pages/Register.js'.

I'm using create-react-app with plugin version 2.4.0

Sorry, I forgot to respond. I'm using version 2.3.0


4.2.2 - TLS handshake failed

Sep 26 07:36:41 puck nsd[1576860]: TLS handshake failed
Sep 26 07:36:41 puck nsd[1576539]: [2019-09-26 07:36:41.561] nsd[1576860]: error: TLS handshake failed
Sep 26 07:36:41 puck nsd[1576860]: TLS handshake failed
Sep 26 07:36:41 puck nsd[1576539]: [2019-09-26 07:36:41.595] nsd[1576860]: error: TLS handshake failed
Sep 26 07:36:47 puck nsd[1576860]: TLS handshake failed
Sep 26 07:36:47 puck nsd[1576539]: [2019-09-26 07:36:47.577] nsd[1576860]: error: TLS handshake failed
Sep 26 07:36:47 puck nsd[1576860]: TLS handshake failed
Sep 26 07:36:47 puck nsd[1576539]: [2019-09-26 07:36:47.619] nsd[1576860]: error: TLS handshake failed

Logs contain the above messages without any further details.  I'm thinking it should provide the IP address in the log message if possible, as well as perhaps reducing duplicate logs or it being a debug/traceoption

Hi Jared,
Fixed this by logging the address and failure reason.  It also omits certain frequent ones, that were complained about for Unbound, from the logs, unless a high verbosity is used, then they are shown.
Let me know if this works out for you.
Best regards, Wouter

The error message looks like this error: TLS handshake failed from <IP_ADDRESS> crypto error:140940F4:SSL routines:ssl3_read_bytes:unexpected message


Interface to view full variable values in separate window

Hello. Maintainer of https://github.com/xdebug/vscode-php-debug here. When inspecting variables the DBGp implementation (Xdebug debug protocol) does not transfer whole property values, but only the first 1024 bytes. So longer strings get truncated.
There is however a protocol level command to fetch the whole data.
It would make sense to give the user an option to view the full string value of a property, something like VisualStudio has:

Proposing to use DAP Evaluate Requests context value "detail".

IIRC, VS Code already uses the evaluate request to get the full string.
@isidorn can you provide more details?

The only way I found so far to trigger a DAP request for variable is click the "Copy Value..." context menu.

Since I don't set the supportsClipboardContext CAP I get context variables.
-> evaluateRequest
{
  command: 'evaluate',
  arguments: { expression: '$aVeryLongString', frameId: 1, context: 'variables' },
  type: 'request',
  seq: 20
}

If I do set that CAP I get a different context.
-> evaluateRequest
{
  command: 'evaluate',
  arguments: { expression: '$aVeryLongString', frameId: 1, context: 'clipboard' },
  type: 'request',
  seq: 20
}

That, I think, is expected. What is the variables context used for besides "Copy Value..."?
Are there any plans to implement a "Details" window?
Thank you.

Sorry for the slow response I was on vacation.
There are no plans to implement the "Details" window. Maybe this could be contributed by your extension using a custom tree?
And yes we currently use the evaluate only for "copy value".
Here's where the context is computed https://github.com/microsoft/vscode/blob/main/src/vs/workbench/contrib/debug/browser/variablesView.ts#L440
So you can follow the flow and look at references to figure out how is the context used.


Robust parsing

Right now our user query parser and our content-disposition parser use lots of raw pointer manipulation. This is obviously a bad idea.
One example of a parser that is designed to be secure is Nom, from the VLC project. It's written in Rust, which we could either embed in C (if we don't mind the dependency) or port/learn from.

One option is the Lemon parser generator from SQLite: https://www.sqlite.org/arch.html


Notifications are not coming. Error Unable to save the Post

Hi, we stopped receiving notifications for some events, according to the logs, this is an error
{"timestamp":"2024-03-21 11:18:31.454 Z","level":"error","msg":"WebhookWorker id: 2, error posting to channel, err: CreatePost: Unable to save the Post.","caller":"app/plugin_api.go:1003","plugin_id":"jira"} {"timestamp":"2024-03-21 11:18:34.467 Z","level":"error","msg":"WebhookWorker id: 3, error posting to channel, err: CreatePost: Unable to save the Post.","caller":"app/plugin_api.go:1003","plugin_id":"jira"}

Hi @Sadisms, thanks for filing this issue. Can you please set your log level to DEBUG if not already set? There may be some more logs related to this near this log line. Thank you!

Hi  @mickmister , sorry for the very late reply, the error still appears, debug log is enabled, no strange logs are seen, here is an example:
{"timestamp":"2024-05-23 05:00:27.431 Z","level":"debug","msg":"Received HTTP request","caller":"web/handlers.go:187","method":"POST","url":"/api/v4/users/ids","request_id":"tuicm7cx37re3k8iscr9th58se","user_id":"a56gykefwpduf84k4eopygq>{"timestamp":"2024-05-23 05:00:27.440 Z","level":"debug","msg":"Received HTTP request","caller":"web/handlers.go:187","method":"POST","url":"/api/v4/users/status/ids","request_id":"x8cxw5ce7t83zneno69uia46xy","user_id":"kpo3mtp5hp8mi8sx>{"timestamp":"2024-05-23 05:00:27.444 Z","level":"debug","msg":"Received HTTP request","caller":"web/handlers.go:187","method":"GET","url":"/api/v4/users/me","request_id":"hoo7ke5au3dmtmbfxzwwj1hgko","user_id":"jimjbexcm7f67rg8rmy1ntszz>{"timestamp":"2024-05-23 05:00:27.446 Z","level":"error","msg":"WebhookWorker id: 7, error posting to channel, err: CreatePost: Unable to save the Post.","caller":"app/plugin_api.go:1003","plugin_id":"jira"}
{"timestamp":"2024-05-23 05:00:27.449 Z","level":"debug","msg":"Websocket request","caller":"wsapi/websocket_handler.go:26","action":"user_update_active_status"}
{"timestamp":"2024-05-23 05:00:27.450 Z","level":"debug","msg":"Websocket request","caller":"wsapi/websocket_handler.go:26","action":"user_update_active_status"}
{"timestamp":"2024-05-23 05:00:27.451 Z","level":"debug","msg":"Websocket request","caller":"wsapi/websocket_handler.go:26","action":"user_update_active_status"}

@mickmister Explored a bit on this, the issue seems to be on the mattermost side(internal server error from their side), here is the permalink for the line from mattermost server which appears to be the source of the error.
On the Jira side, there seems to be no code that can cause this error. The only point from where an error can be returned is the call to the createPost function of the mattermost server. Here are some related permalinks. errorSouce,  createPost Call

@Kshitij-Katiyar That's strange that we don't have a more descriptive error here
From the code that prepares the post in the plugin, it looks like we only populate:

ChannelId
UserId
Message
Props.Attachments (conditionally)

https://github.com/mattermost/mattermost-plugin-jira/blob/1b9490bffa36a6ec4fcc0b521a82885f3d1408bd/server/webhook.go#L63-L100
I'm thinking there may be an issue with the channel id provided. Maybe the channel is archived?

@mic

@Kshitij-Katiyar That's strange that we don't have a more descriptive error here
From the code that prepares the post in the plugin, it looks like we only populate:

ChannelId
UserId
Message
Props.Attachments (conditionally)

https://github.com/mattermost/mattermost-plugin-jira/blob/1b9490bffa36a6ec4fcc0b521a82885f3d1408bd/server/webhook.go#L63-L100
I'm thinking there may be an issue with the channel id provided. Maybe the channel is archived?

@mickmister I tried a few cases, but this error does not seem to reproduce:

Archived Channel: The message gets posted regardless.

Closed Channel: No message is posted in this case, but no error is logged in the system logs.

@Sadisms Are you still facing this issue or can we close it?

Closing for now, can reopen if someone faces the issue.


fix: emitDecoratorMetadata

Codecov Report

Merging #269 (f386675) into master (0f50734) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #269      +/-   ##
==========================================
+ Coverage   88.61%   88.62%   +0.01%
==========================================
  Files          40       40
  Lines        3812     3817       +5
  Branches     1116     1117       +1
==========================================
+ Hits         3378     3383       +5
  Misses        400      400
  Partials       34       34

Impacted Files
Coverage Δ

packages/cli-plugin-check/src/index.ts
94.30% <100.00%> (+0.07%)
:arrow_up:

packages/gateway-common-http/src/common.ts
91.66% <100.00%> (ø)

Continue to review full report at Codecov.

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


[Tracking] arm64 kola test failures

SELinux-related (see PR: https://github.com/kinvolk/coreos-overlay/pull/135):

[x] coreos.selinux.boolean (https://github.com/kinvolk/mantle/pull/209)
[x] coreos.selinux.enforce (https://github.com/kinvolk/mantle/pull/209)
[ ] docker.userns: there is an explicit setenforce 1 so test is failing

Missing multiarch images (see PR: https://github.com/kinvolk/coreos-overlay/pull/1179):

[ ] cl.etcd-member.discovery
[ ] kubeadm.base
[ ] cl.etcd-member.v2-backup-restore
[ ] google.kubernetes.basic.docker.v1.18.0
[ ] google.kubernetes.basic.docker.v1.16.8
[ ] google.kubernetes.basic.docker.v1.14.10
[ ] cl.locksmith.cluster
[ ] coreos.locksmith.tls: it's related to the etcd failure because we first verify etcd has a valid TLS connection ready since etcd does not boot, openssl is failing to verify the TLS connection
[ ] cl.etcd-member.etcdctlv3 ("error while dialing :2379: connect: connection refused" )
[ ] cl.flannel.vxlan ("cluster failed starting machine: ssh unreachable or system not ready" )
[ ] cl.flannel.udp ("cluster failed starting machine: ssh unreachable or system not ready" )

Polkit related (see PR: https://github.com/kinvolk/coreos-overlay/pull/863):

[ ] cl.basic/DbusPerms: kolet: Process exited with status 1

according to @pothos, these are related to "kernel soft lockup coming from slow QEMU emulation".
"waiting for UPDATE_STATUS_UPDATED_NEED_REBOOT: time limit exceeded"

[ ] cl.update.payload

"cluster failed starting machines: connect: connection refused"

[ ] cl.ignition.v2.btrfsroot

Also ref #470 to normalise the test running environment. As it stands now, kola is happy to run its test suite without verifying that the host system is configured properly (and, what constitutes "properly" is still somewhat hazy).

cl.ignition.v2.btrfsroot and cl.update.payload both should work, and if there are temporary failures it's due to the kernel soft lockup coming from slow QEMU emulation.

@pothos What's the path forward on those, then? Are we sunk unless we're testing those on actual hardware?

We can tweak the QEMU invocation but otherwise it's like on amd64 where some tests have to be rerun, too.

Alright, have updated the list to reflect this.

For completeness, here the paste of failure messages from the 2955.0.0 release:
https://pastebin.com/raw/y93uUVs1
The cl.flannel.* tests also seem to be related to flanneld.service itself not coming up which causes systemctl is-system-running to return a failure.
The underlying cause there is that quay.io/coreos/flannel:v0.12.0 is not a multiarch image (one has to explicitly use quay.io/coreos/flannel:v0.12.0-arm64) and this can be resolved by updating to quay.io/coreos/flannel:v0.13.0 or quay.io/coreos/flannel:v0.14.0 which both are multiarch images.

Same problem for etcd: The quay.io/coreos/etcd:v3.3.25 image is not a multiarch image, and we need to update to quay.io/coreos/etcd:v3.5.0

AFAIK SELinux things are not installed on arm64 - that's why basic tests are failing because it does not find the SELinux binary tools.

I also got a temporary verity test failure and filed a PR to make it more robust: https://github.com/kinvolk/mantle/pull/202

@pothos @wrl for docker.userns I get it working by removing the failing setenforce 1 but it appears that we have some race condition with torcx.
Sometime, torcx is not sealed so we can't run docker -> The program docker is managed by torcx, which did not run..
Comparing the two console.txt from _kola_temp ; we have the following:
// success
$ cat _kola_temp/qemu-2021-08-17-1538-10573/docker.userns/99f84f72-844c-4c59-8df9-be4b180e164c/console.txt | grep -i torcx
[   77.765874] systemd[1]: Condition check resulted in Populate torcx store to satisfy profile being skipped.
[  217.515997] systemd[1]: Reached target Verify torcx succeeded.
[  OK  ] Reached target Verify torcx succeeded.
// failure
$ cat _kola_temp/qemu-latest/docker.userns/9fae9ad7-40ac-4c98-8ced-9f209d2c507d/console.txt| grep -i torcx
[   67.623773] systemd[1]: Condition check resulted in Populate torcx store to satisfy profile being skipped.

And comparing journal logs:
// success
$ cat _kola_temp/qemu-2021-08-17-1538-10573/docker.userns/99f84f72-844c-4c59-8df9-be4b180e164c/journal.txt | grep -i torcx
...
Aug 17 15:40:26.839093 /usr/lib/systemd/system-generators/torcx-generator[755]: time="2021-08-17T13:40:26Z" level=info msg="store skipped" err="open /usr/share/oem/torcx/store: no such file or directory" path=/usr/share/oem/torcx/store
Aug 17 15:40:26.843044 /usr/lib/systemd/system-generators/torcx-generator[755]: time="2021-08-17T13:40:26Z" level=info msg="store skipped" err="open /var/lib/torcx/store/2942.0.0: no such file or directory" path=/var/lib/torcx/store/2942.0.0
Aug 17 15:40:26.846258 /usr/lib/systemd/system-generators/torcx-generator[755]: time="2021-08-17T13:40:26Z" level=info msg="store skipped" err="open /var/lib/torcx/store: no such file or directory" path=/var/lib/torcx/store
Aug 17 15:41:27.152038 /usr/lib/systemd/system-generators/torcx-generator[755]: time="2021-08-17T13:41:27Z" level=debug msg="image unpacked" image=docker path=/run/torcx/unpack/docker reference=com.coreos.cl
...
// failure
$ cat _kola_temp/qemu-latest/docker.userns/9fae9ad7-40ac-4c98-8ced-9f209d2c507d/journal.txt | grep -i torcx
Aug 17 16:06:53.561320 /usr/lib/systemd/system-generators/torcx-generator[756]: time="2021-08-17T14:06:53Z" level=info msg="store skipped" err="open /usr/share/oem/torcx/store: no such file or directory" path=/usr/share/oem/torcx/store
Aug 17 16:06:53.593780 /usr/lib/systemd/system-generators/torcx-generator[756]: time="2021-08-17T14:06:53Z" level=info msg="store skipped" err="open /var/lib/torcx/store/2942.0.0: no such file or directory" path=/var/lib/torcx/store/2942.0.0
Aug 17 16:06:53.595867 /usr/lib/systemd/system-generators/torcx-generator[756]: time="2021-08-17T14:06:53Z" level=info msg="store skipped" err="open /var/lib/torcx/store: no such file or directory" path=/var/lib/torcx/store

:arrow_up: on the success we have the image unpacked log and friends but on the failure, it stops on the last store skipped the no more news from torcx like it was just killed.

I created a new PR to install selinux tools and enable selinux on arm64 https://github.com/kinvolk/coreos-overlay/pull/1245 (replacing https://github.com/kinvolk/coreos-overlay/pull/135).
This will hopefully allow us to enable the SELinux tests for arm64 again.

The tests now pass with SELinux enabled:
ok - coreos.selinux.enforce
ok - coreos.selinux.boolean
ok - docker.userns


[ELE-37] Detection of deleted columns in Bigquery

Elementary pulls the data to detect schema changes from the information schema columns view.
This view is updated in a delay (unclear how long), so the alert on deleted columns is delayed as well.
Possible solution
Research if there is an alternative source that updates in real time.
ELE-37

Test comment

Closing this issue since it's pretty old, but please re-open if still relevant!


Resource policy documentation

Documentation from cri-rm updated for nri resource policy.

ping @askervin, @marquiz, @kad, @klihub
Lets try to review this by the end of the week so we can get this merged sooner than later, so please take a look at these.

A few comments

Thanks, I updated most of the documentation. The installation/setup/quick-start needs still some work but that needs to wait the #45.

A few comments innocent

A big thanks for the thorough review !

I'm going to submit another documentation RP which will include that and other ways of installing the plugins.

Thinking from the users perspective, IMO the one thing that needs to be in reasonable shape are the deployment/installation instructions. Easy-to-follow step-by-step insrtuctions how to get the plugins running in a cluster. Something like
IMAGE_REPO=my-custom-repo
make image
make image-push
kubectl apply -k deployment/overlays/topology-aware

Another concern/question: how to track the unresolved comments if this gets merged?

I'm going to submit another documentation RP which will include that and other ways of installing the plugins.

I'm going to submit another documentation RP which will include that and other ways of installing the plugins.

That's cool. I suggest to drop all the installation/quick start stuff from this PR, then. WDYT?

I think we could merge this. If we do, @jukkar could you create an issue tracking the unresolved comments?

create an issue tracking the unresolved comments?

Created #58 for tracking pending work.


Cannot open projects without installing dependencies

All projects fail to load without MicroBuild installed. We should allow projects to be opened without this, even if the build is going to fail (we provide a useful error message in this case, but the error when projects cannot be opened is not helpful).

Already resolved


Include a search box with the search query on the search results page

After searching on the docs, the search result page doesn't include a search box with the search terms to allow me to fine-tune my search based upon the results. This is contrary to Bing, Google, and search experience standards for many years.

⚠ Idea migrated from UserVoice
Created By: Paul
Created On: 2017/03/20 14:22:42 +0000
Votes at Migration: 2
Supporters at Migration: 2

We have the search box with the search terms after searching, though it's not that big.

We have a feature of adding facets in search page, in which we plan to make the search box bigger and centered in search page.

@dend Shall we close the issue? How can inform the true user.

I will close this as can't repro. If you have other question related this, we will reopen the issue and continue the discussion.


ncc_unistore failed because Cannot find module 'unistore'

When running cd packages/next && npm run release I get this error:
[15:15:50] ncc_unistore failed because Cannot find module 'unistore'

Is it suppose to be globally installed? I can't find it in any package.json.

Was a problem with my npm not finished correctly.


Add footer

Please assign me to this issue.
Under JWOC.

I want to work on this issue under JWOC

already in progress.


Issue with "CWPP API" in @site/api/cloud/cwpp/cwpp-home.md

Thank you for taking the time to help us improve our documentation! Please describe the problem and a suggested fix below and we'll get back to you as soon as we can. --DevRel
Describe the problem
The content in this topic needs some fixes and additional information.
Suggested fix
Here is what I suggest:
The Prisma Cloud Workload Protection APIs enable both automation and integration. Use the REST APIs to set up, configure, reconfigure, and deploy Prisma Cloud Compute components that enable you to secure your host, container, and serverless computing environments against vulnerabilities, malware, and compliance violations. You can also use it to extract data and integrate it with monitoring, alerting, and other systems in your environment.
For information on how to access the APIs, see https://prisma.pan.dev/docs/cloud/cwpp/cwpp-gs.
And if you are using the self-hosted version (Prisma Cloud Compute Edition), see https://prisma.pan.dev/docs/cloud/cwpp/porting-guide for the differences between versions 21.04 and 20.12.

Fixed in the update that will go live on Jun 14.


CDS NOT SENT on sidecars after creating/editing DestinationRule

Bug description
I'm running istio in a multi-cluster with replicated control planes as described in the docs.
When updating a DR, CDS synchronization to sidecars breaks.
Restarting pilot will not fix the issue. Restarting the sidecars seems to re-sync those specific sidecars.
I've built a custom pilot image with more logging for debugging purposes and it seems that for those NOT_SYNCED connections, CDSWatch is set to false. From my understanding of the flow, i believe that because Envoy does not initiate a CDS watch, pilot will not push any updates to it.
I'm trying to figure out whether that's normal envoy behavior or if it should actually initiate CDS watch when reconnecting to a newly started pilot instance.
Expected behavior
CDS updates are sent to sidecars, istioctl ps shows all items as SYNCED
Steps to reproduce the bug
Hard to reproduce. I've noticed that on apply/delete/edit of the DR in this manifest, the de-sync tends to occur: https://gist.github.com/valer-cara/f69314783f3be5d11dfe3e53ad876e69
After a de-sync, i haven't found a way to make sidecars to resync.
I've noticed that force-restarting the sidecars will get them in a SYNCed state, but if i re-apply or simply edit the destination rule, CDS again goes to STALE.
Edits on the ServiceEntry or VirtualSerice, in the manifest above create no issues and are being propagated. It's only the DR.
Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
client version: 1.4.0
citadel version: 1.4.3
galley version: 1.4.3
ingressgateway version: 1.4.3
pilot version: unknown
sidecar-injector version: 1.4.3
data plane version: 1.4-alpha.c095f0b1409134b71de04ffb52675e9ce7e5cd88 (4 proxies), 1.4.3 (1 proxies)

How was Istio installed?
Via the istio-operator, version 1.4-dev
Environment where bug was observed (cloud vendor, OS, etc)
AWS provisioned with https://typhoon.psdn.io/

We have the same issue (#19902).
We are currently looking into locality aware routing as a root cause. We have first seen this appearing after we tested different modes. Also we have one cluster with 1.3, which does not use locality based routing (also because it does not have the common labels required), where this issue is not seen.

Done some more testing, trying all sorts of "permutation" of the inputs and i think i'm able to reproduce this.
In my scenario, the DR has a few subsets with labels and the ServiceEntry lists endpoints for each of those labels.
If i edit the DR and add a subset with a label that's not currently defined & synced in the cluster; the STALE condition is triggered and the only way to get out of it is to fix the label mismatch in the DR (or remove the label for good) and force restart the sidecars (eg: pkill -f svc.cluster.local on the machines -- but be cautious not to kill passers by)

Yup, i can now confirm that the above fixes my issue. :jack_o_lantern:
The ServiceEntry endpoints matching each of the DR subset labels must exist & be synced before creating the DR in order to avoid CDS going STALE.

I've tried to put together a test case for this issue, managed to reproduce it following the steps in the README. https://github.com/valer-cara/istio-testcase-20120
Feedback welcome.
PS: MUTUAL_TLS must be enabled for this to occur

I also have a reproduction rule now, but a different one.

Deploy a cluster with:

global:
  localityLbSetting:
    enabled: false

Change the config to

global:
  localityLbSetting:
    enabled: true
    distribute:
      - from: "europe-west4/europe-west4-b/*"
        to:
          "europe-west4/europe-west4-b": 90
          "europe-west4/europe-west4-c": 10
      - from: "europe-west4/europe-west4-c/*"
        to:
          "europe-west4/europe-west4-b": 10
          "europe-west4/europe-west4-c": 90

And restart pilot.
After the pilot restart is done, all pods are in CDS "NOT SENT" state until the sidecar is restarted and don't accept cluster updates (e.g. outlier detection anymore).


Allow stepping into functions with the VSCode debugger

Michal says if we didn't dynamically import functions maybe we could step into them.
(if I understand right)
We could codegen an api-like object that has all the functions attached, or we could change the api to require importing them statically to run them?

Thread for context: https://discord.com/channels/1019350475847499849/1230211387230392422
This might be fixable in Vitest or VS Code as well.

I noticed that debugger; statement works

This was fixed.


feat(KCard): setup syntax [KHCP-6495]

Summary
https://konghq.atlassian.net/browse/KHCP-6495
Switch to setup syntax
PR Checklist

[ x] Does not introduce dependencies
[ x] Functional: all changes do not break existing APIs and if so, bump major version.
[ x] Tests pass: check the output of yarn test
[ x] Naming: the files and the method and prop variables use the same naming conventions as other Kongponents
[ x] Framework style: abides by the essential rules in Vue's style guide
[x ] Cleanliness: does not have formatting issues, unused code (e.g., console.logs, debugger), or leftover comments
[x ] Docs: includes a technically accurate README, uses JSDOC where appropriate

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Daria Yeromina seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


docs: Add user guide for change the stream description.

Added user guide for changing the description of a stream.
Added a link to it from the table of contents in index.md.

Automated message from Dropbox CLA bot
@maydhak, it looks like you've already signed the Dropbox CLA. Thanks!

@maydhak, small feedback left, looks good otherwise.

I've made the requested changes.

@maydhak, lgtm. @showell, can you do a final review? Thanks.

Merged, thanks @maydhak!


Add Observable variant Single

RxJava and other have implemented the variant called Single:
http://reactivex.io/documentation/single.html
I believe since golang is heavily used in developing Restful APIs the Single pattern will be really effective in developing microservices where to satisfy a single Rest call the server has to actual coordinate with multiple backends. In this scenario the Single patter will allow for asynchronous handling of Rest requests, making the code a lot more declarative.

+1 for the Single interface.
Meanwhile, I tried to propose something regarding the migration of Observer, Observable and Connectable to interfaces: https://github.com/ReactiveX/RxGo/pull/90

implemented on RxGo 2 (in development) https://github.com/ReactiveX/RxGo/pull/95


fail to save after training ml.net  forcasting  all is updated tryed also without updating

at System.Version.VersionResult.SetFailure(ParseFailureKind failure, String argument)
at System.Version.TryParseVersion(String version, VersionResult& result)
at System.Version.Parse(String input)
at System.Version..ctor(String version)
at Microsoft.ML.ModelBuilder.Utils.Utilities.InstalledVersionNeedsUpdate(String installedString, String requestedString)
at Microsoft.ML.ModelBuilder.Utils.Utilities.d__17.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Microsoft.ML.ModelBuilder.ViewModels.TrainViewModel.d__105.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
at Microsoft.ML.ModelBuilder.ViewModels.TrainViewModel.d__104.MoveNext()

MLModel1-JX5DZJ.txt

Thanks for reporting. In the meantime, you can ignore that error and install package manually.


BTT BitTorrent

Hi Martin
Thanks for your awesome icons set!
If you could, please, add one more icon?
Thanks in advance
Coin name (BitTorrent)

https://www.bittorrent.com/btt/btt-img/BTT_Token_Graphic.png
https://www.bittorrent.com/btt/

Any updates on this?

White SVG format logo
https://www.bittorrent.com/btt/btt-img/BTT_Token_Logo_White.svg


feat(validator): Create core logic that is reusable for validator and authorizer

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

72 of 72 (100.0%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.03%) to 99.099%

Totals

Change from base Build<PHONE_NUMBER>:
-0.03%

Covered Lines:
137

Relevant Lines:
137

💛  - Coveralls