Failed to cross compile on WSL2

Version
Microsoft Windows [Version 10.0.22000.282]
WSL Version

[X] WSL 2
[ ] WSL 1

Kernel Version
5.10.16
Distro Version
Ubuntu 20.04
Other Software
snapdragon-llvm-<IP_ADDRESS>-compiler-linux64
Repro Steps
Run custom build script.
Expected Behavior
Build should be fine since compilation succeeded with same code on another computer with same hardware under native Ubuntu 20.04.
Actual Behavior
Got a "Segmentation fault" and build broken with scons reported "Error 139"
Diagnostic Logs
Here's some log I got with "dmesg".
[ 1972.933940] arm-ar[1753] vsyscall attempted with vsyscall=none ip:ffffffffff600400 cs:33 sp:7ffd91602908 ax:ffffffffff600400 si:4c5823 di:0
[ 1972.934039] arm-ar[1753]: segfault at ffffffffff600400 ip ffffffffff600400 sp 00007ffd91602908 error 15
[ 1972.934113] Code: Unable to access opcode bytes at RIP 0xffffffffff6003d6.
[ 1972.934117] potentially unexpected fatal signal 11.
[ 1972.934119] CPU: 1 PID: 1753 Comm: arm-ar Not tainted <IP_ADDRESS>-microsoft-standard-WSL2 #1
[ 1972.934294] RIP: 0033:0xffffffffff600400
[ 1972.934297] Code: Unable to access opcode bytes at RIP 0xffffffffff6003d6.
[ 1972.934299] RSP: 002b:00007ffd91602908 EFLAGS: 00010202
[ 1972.934302] RAX: ffffffffff600400 RBX: 00007ffd91602ab0 RCX:<PHONE_NUMBER>00002f
[ 1972.934304] RDX:<PHONE_NUMBER>000000 RSI:<PHONE_NUMBER>4c5823 RDI:<PHONE_NUMBER>000000
[ 1972.934306] RBP:<PHONE_NUMBER>00004a R08:<PHONE_NUMBER>000001 R09:<PHONE_NUMBER>6f06d0
[ 1972.934308] R10:<PHONE_NUMBER>eb8620 R11:<PHONE_NUMBER>000010 R12:<PHONE_NUMBER>4c5822
[ 1972.934310] R13:<PHONE_NUMBER>eb5280 R14:<PHONE_NUMBER>eb81f0 R15:<PHONE_NUMBER>000000
[ 1972.934312] FS:<PHONE_NUMBER>ead860 GS:<PHONE_NUMBER>000000

To be honest, I don't know much about how the "cross compiler" interacts with "kernel". So I'm not sure if this is a bug or just because I got some wrong configuration. But same code compiles fine under native Ubuntu 20.04, I think the behavior should be the same under WSL2.

I just updated my kernel to <IP_ADDRESS>-microsoft-standard-WSL2 and this problem still happens
[   41.549021] arm-ar[494] vsyscall attempted with vsyscall=none ip:ffffffffff600400 cs:33 sp:7fff00c26bb8 ax:ffffffffff600400 si:4c5823 di:0
[   41.549023] arm-ar[494]: segfault at ffffffffff600400 ip ffffffffff600400 sp 00007fff00c26bb8 error 15
[   41.549025] Code: Unable to access opcode bytes at RIP 0xffffffffff6003d6.
[   41.549030] potentially unexpected fatal signal 11.
[   41.549031] CPU: 3 PID: 494 Comm: arm-ar Not tainted <IP_ADDRESS>-microsoft-standard-WSL2 #1
[   41.549036] RIP: 0033:0xffffffffff600400
[   41.549037] Code: Unable to access opcode bytes at RIP 0xffffffffff6003d6.
[   41.549038] RSP: 002b:00007fff00c26bb8 EFLAGS: 00010206
[   41.549040] RAX: ffffffffff600400 RBX: 00007fff00c26d60 RCX:<PHONE_NUMBER>00002f
[   41.549041] RDX:<PHONE_NUMBER>000000 RSI:<PHONE_NUMBER>4c5823 RDI:<PHONE_NUMBER>000000
[   41.549043] RBP:<PHONE_NUMBER>000064 R08:<PHONE_NUMBER>000001 R09:<PHONE_NUMBER>6f06d0
[   41.549044] R10:<PHONE_NUMBER>9b4830 R11:<PHONE_NUMBER>000010 R12:<PHONE_NUMBER>4c5822
[   41.549045] R13:<PHONE_NUMBER>9b1490 R14:<PHONE_NUMBER>9b4400 R15:<PHONE_NUMBER>000000
[   41.549047] FS:<PHONE_NUMBER>9a8860 GS:<PHONE_NUMBER>000000

Finally......
I found this: https://github.com/microsoft/WSL/issues/4694
and it works


⚠ SceneTime has degraded performance

In cac8d07, SceneTime ($ST) experienced degraded performance:

HTTP code: 200
Response time: 1211 ms

Resolved: SceneTime performance has improved in 83cf4b0 after 10 minutes.


etcdctl/ctlv3: don't crash when we should prompt for pw.

etcdctl/ctlv3: don't crash when we should prompt for pw.
when 'etcdctl --user name get blah' is invoked to
prompt for password, don't panic.
addresses the segfault part of #6343

lgtm


Includes (Eager Loading) and JSON

Hi,
I'm trying to do some basic eager loading but I am unable to get it to work. I'm not sure whether I'm just doing it wrong or whether it's a bug. I'd think the former.
My database.yml
development:
  host: localhost
  database: webdv
  pool_size: 5
  identity_map_enabled: true

Then in rails console I try this:
User.includes(:folders).to_json

The only thing it returns is an array of users, nothing else. Even when doing something like:
User.includes(:folders).to_a

Still just returns an array of users, but no folders (as far as I can see at least).
Tried it with the latest gem and also with the latest master branch (3.0.0). Can't seem to get it to work.
Any help much appreciated.

You need to tell the json serialization to include the posts as well:
User.includes(:folders).to_json(:include => :folders)

@durran thanks, that did the trick!


use decimal128 instead decimal64 for aggr sum

What type of PR is this：

[x] bug
[ ] feature
[ ] enhancement
[ ] others

Which issues of this PR fixes ：

Problem Summary(Required) ：

when aggregation function sum is applied to billions of rows of decimal64 or decimal32  values, the result would overflows, so use decimal128 instead of decimal64 for sum.

may be we need describe it in our document

run starrocks_fe_unittest

[FE PR Coverage check]
:heart_eyes: pass : 9 / 9 (100.00%)
file detail

path
covered line
new line
coverage

:large_blue_circle:
com/starrocks/planner/AggregationNode.java
1
1
100.00%

:large_blue_circle:
com/starrocks/catalog/FunctionSet.java
6
6
100.00%

:large_blue_circle:
com/starrocks/sql/analyzer/DecimalV3FunctionAnalyzer.java
2
2
100.00%

@Mergifyio backport branch-2.2

@Mergifyio backport branch-2.1


Forms with Scriptblock

Hi @Badgerati,
I am trying to execute a Scriptblock after a user chose a value from a select-Element and pressed a button. As it it not possible to access the Select-Element directly, I wonder if a Form could do the trick.  The Submit-Button could execute a Script instead of invoking a Get or a Post.

Hi @hvoges,
A button with a scriptblock would still invoke a Post, similar to a Form's Submit button - just the Form would also send the Select's value as well to a Form's -ScriptBlock.
Using events on a Select element's change event should also do the same, and remove the need for a button (if it's not 100% needed): https://badgerati.github.io/Pode.Web/Tutorials/Events/

This appears that it will be covered by #457 - closing.


Problem with running on a mac

Hi,
For some reason fasd is not working properly on my mac. If I type fasd -d, I get the history of visited directories. But I have trouble changing into a directory with fasd -d NAME:
fasd -d -i gives me:
3   45.4386    /Users/sergei/Documents/Development/ruby
2   59.1902    /Users/sergei/Documents/Development/perl
1   120.832    /Users/sergei/bin

But fasd -d Deve has no effect.
Any ideas?

I don't think it's supposed to. fasd -d is only supposed to show the weight of the matched directory; I believe the command you're looking for is fasd_cd -d which is aliased to z by default.

You're right, but fasd_cd -d has no effect either.
I also tried zz but even selecting interactively didn't work. After I changed #!/usr/bin/env sh to #!/usr/bin/env bash the interactive mode started working, z is still not working.

I'm proud to say i found the reason for fasd not working on my Mac which took me an hour to find out. The problem is that the grep version on my Mac (Sierra) is a BSD grep, which has the peculiar behavior of printing (standard input) whenever a match on standard input occurs.
For example:
(standard input):something

I don't know the rationale for printing that but it seems there's no way to suppress it. So, a solution is to install the GNU grep (through something like brew) and change the code of fasd to make grep a definable parameter in .fasdrc?


Add a License to your VS Code Extension

Thank you for being part of the Open VSX community by adding your extensions to the Open VSX Registry. Please note that the service was recently transferred to the Eclipse Foundation and urgent action on your part is needed so we can continue to list your extensions. To ensure uninterrupted service, please add a license to your extension and upload a new version as early as possible before January 15, 2021. To include a license with the extension, add a license field with the license identifier in the package.json and add a LICENSE file with the full license text. If you are unsure which license to choose, check the list of OSI-approved licenses.
Regrettably if this is not done by that date, extension versions that have no license will be deleted. Of course you can publish them again with a license at a later date.
Please note, the latest version of the ovsx tool offers to add the MIT license when you try to publish without a license.
A reminder  that all extension publishers MUST sign the Eclipse Publisher Agreement.
Useful links:
Eclipse Publisher Agreement
Eclipse Foundation Open VSX Registry Frequently Asked Questions (FAQ)
More details are in these recent blog posts:
https://blogs.eclipse.org/post/brian-king/open-vsx-registry-under-new-management
https://blogs.eclipse.org/post/brian-king/new-era-open-vsx-registry

@madeindjs As the project maintainer, we also recommend you to claim the namespace for your extension(s). To find out how to do this, see:
https://github.com/eclipse/openvsx/wiki/Namespace-Access

@madeindjs As the project maintainer, we also recommend you to claim the namespace for your extension(s). To find out how to do this, see:
https://github.com/eclipse/openvsx/wiki/Namespace-Access


Added an option to highlight/mark syntactically not correct lines

This will let user change those lines manually and see the diff if s/he wants.

I tried to run your code, but with no luck:
Error detected while processing function <SNR>49_TryAllFormatters[48]..<SNR>49_TryFormatterPython3:
line  102:
Traceback (most recent call last):
  File "<string>", line 49, in <module>
NameError: name 'NamedTemporaryFile' is not defined

Ops sorry I forgot to tell you that I couldn't test it in with python3. I could only test python section and copy-pasted to python3.
Honestly, it felt weird to copy paste blindly, but, it also seems unnecessary to have python dependency for a minor task. I think we can convert python code to vimscript easily - like many other plugins with pure vimscript making linter-based operations.

I think we can convert python code to vimscript easily - like many other plugins with pure vimscript making linter-based operations.

If you mean converting the entire plugin to vim script, then no, this cannot be done easily. Vim-autoformat used to be vim-script only, but we needed to migrate to python code for technical reasons related to the calling of the format program.

Ops sorry I forgot to tell you that I couldn't test it in with python3.

It shouldn't be too hard to get your hands on a vim that can do both. My vim installation (on windows) can do either 2 or 3, just whichever is called first.

Python3 code works now (many encoding issues pheew).
As far as I can see you are using python to stream-in/out lines - which I think some formatters are working stdin/stdout only? It is hard to imagine a unix program with stdin/out support without file in/out - generally all should be doable playing with command line switches, no? If thats the case can't we just write a small python executable that warps such "executables" and add file in/out capabilities?
As I have been trying to add Python3 support (and cannot add both at the same time) I am convinced that wout dependency is more reachable. Many plugins are rewritten to drop external dependencies and they are advertising it. So pushing the rubbish under to hoods (in a python executable wrapper) is cleaner than vice versa (adding the pythonXX codes directly in the plugin).

Still runtime errors:
Error detected while processing function <SNR>49_TryAllFormatters[48]..<SNR>49_TryFormatterPython3:
line  104:
Traceback (most recent call last):
  File "<string>", line 61, in <module>
  File "<string>", line 61, in <listcomp>
TypeError: Can't convert 'bytes' object to str implicitly

As I have been trying to add Python3 support (and cannot add both at the same time) I am convinced that wout dependency is more reachable. Many plugins are rewritten to drop external dependencies and they are advertising it. So pushing the rubbish under to hoods (in a python executable wrapper) is cleaner than vice versa (adding the pythonXX codes directly in the plugin).

I'm not sure what you mean here. Python3 is a very common dependency. There is hardly any reason to compile vim without the python support. And to properly communicate with vim you want to use the python API, so using an external python executable is not a better option.
If you're interested, one of the reasons for introducing python code is this issue: https://github.com/Chiel92/vim-autoformat/issues/10

Hi,
It is working perfectly with brew installed macvim 8.0-172. Could you please correct it if you have Python3 experience? As the problematic line seems to be
   for eol in possible_eols:         lines = [splitline for line in lines for splitline in line.split(eol.encode('utf-8'))]
Maybe we can decompose this list comprehension in 2 loops and see where exactly it is failing. There is no problem here so I am unable to fix it easily.

I think you haven't actually tested it with python 3.
The part eol.encode('utf-8') is downright wrong, since the split function cannot take a bytes object.
It will always fail.
E.g. try running ''.split(b',') in a python interpreter.

`
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Jan 25 2017 10:14:43)
MacOS X (unix) version
Included patches: 1-172
Compiled by Homebrew
Huge version with MacVim GUI.  GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-8<IP_ADDRESS>)] on darwin!!!
!!!Type "help", "copyright", "credits" or "license" for more information.!!!

''.split(b',')
!!!Traceback (most recent call last):!!!
!!!  File "", line 1, in !!!
!!!TypeError: must be str or None, not bytes!!!
''.split(',')
['']

`
But it works! How...

But it works! How...

That means it doesn't hit that line of code.
I don't know what testing scenario you use, but try playing around with that.
To determine what code is actually executed, you can put print statements in the code.

The feature was for my needs anyways - won't make further efforts to merge it and apply my ideas to my fork.
Sorry for disturbing.
All the Best!

No problem!
Cheers


Grid-like datasets are not scaled correctly in the DataSet

Issue Description
When one restart the calculation, the dataset will be scaled before retrieving the realization from that dataset. If grid-like sampler is used, the scale factor could be zero, since the grid points for some variable could be constant, this will cause the failure of the restart capability as recently reported by one of our users.
What did you expect to see happen?
The grid sampler with restart should work.
What did you see instead?
From raven user:
so I started a test without the meshfile variable. Left it running for some time so I had a dataset of 34 restart points. Then cancled Raven and tried to restart from the previous results but again the same error and Raven ignored the restart points completely and started sampling the same points again that already exist in the restart data.

Do you have a suggested fix for the development team?
@mandd and I found we have an issue with the SCALE in the DataSet. The fix can be found in
https://github.com/idaholab/raven/tree/wangc/std_issue
Please attach the input file(s) that generate this error.  The simpler the input, the faster we can find the issue.

For Change Control Board: Issue Review
This review should occur before any development is performed as a response to this issue.

[x] 1. Is it tagged with a type: defect or improvement?
[x] 2. Is it tagged with a priority: critical, normal or minor?
[x] 3. If it will impact requirements or requirements tests, is it tagged with requirements?
[x] 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
[x] 5. Is a rationale provided? (Such as explaining why the improvement is needed or why current code is wrong.)

For Change Control Board: Issue Closure
This review should occur when the issue is imminently going to be closed.

[x] 1. If the issue is a defect, is the defect fixed?
[x] 2. If the issue is a defect, is the defect tested for in the regression test system?  (If not explain why not.)
[x] 3. If the issue can impact users, has an email to the users group been written (the email should specify if the defect impacts stable or master)?
[x] 4. If the issue is a defect, does it impact the latest stable branch? If yes, is there any issue tagged with stable (create if needed)?
[x] 5. If the issue is being closed without a merge request, has an explanation of why it is being closed been provided?

closure check list passed...
No email to users is necessary since this issue can not cause wrong results but was causing a crash.


Added build file

yml file for build via github actions (test + coverage)

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Allow users to set their locale

Some users will prefer a certain locale, but not have their browser correctly configured. The user profile should allow users to define their locale. The default should be 'auto' which uses the browser's language, but that can be overridden. If overridden, the language should be applied on user login.

Should use impactasaurus/server#277 to store and load

Example of an async language detected available at https://github.com/i18next/i18next-browser-languageDetector/issues/188.

To build the list of languages can use a library like https://www.npmjs.com/package/language-name-map. Should only allow selection of languages which have a decent coverage of the app's strings (80%?)


Split request telemetry

User story
We should further break-out and investigate the following in request telemetry:

Conditional-Update as its own sub-type
Conditional-Create as its own sub-type
Capabilities as its own sub-type
Do we double-log? Bundle-post + transition/batch
Can we log RUs in call

AB#77729

AB#77729


[HANA] hyperlink in sql console for table doesn't work without specifying the scheme

System information:

Win 10
DBeaver CE 21.2.1

Connection specification:

SAP HANA

Describe the problem you're observing:

Open SQL editor for HANA connection.
Select active scheme
write a simple script (like this : SELECT * FROM NEWTABLE;) with the name of the table, but without specifying the schema.
Expected: you can navigate to the table with ctrl pressed and mouse click
Actual: you can't do this without using fully qualified name

Fixed

verified


[STYLE]Enhancing the UI of containers of every section

Hello! I am Mahima Churi, a proud contributor of GSSoc'23.
📌I have gone through your website and came across the containers you added for each and every section of your website.

I would like to enhance it, by adding more animations and making it more user-friendly.
I would be doing it using tailwind css. I have worked on similar types of containers earlier, u can see my work below :

📌The Web Dev Resource heading is static, I would like to make it interactive so that it redirects back again to the home page

📌After solving this issue I would also like to work on adding a dark theme to the website
If you think it is legit then do assign me the issue under GSSoC '23 with the level of the PR as well

Yeah that's a good idea.
You can work on it!
Please go through contributing guidelines.
All the best!

Yes sure I will go ahead with it

Important Announcement: Closure of GitHub Repository Issues, Website Redesign, and Discord Channel Invitation
We apologize for the inconvenience caused, but we must inform you that all current issues in our repository will be closed. This decision aims to improve our development process and enhance organization.
Excitingly, we are announcing a complete redesign of our website, focused on improving user experience and incorporating new features aligned with our goals.
Please note that approximately half of the existing issues are redundant and will be closed accordingly.
We also invite you to join our Discord channel for project collaboration and communication. Visit GSSoC server and assign yourself Web Resource Hub project role using the self-roles feature.
Join here
Your feedback and support are invaluable to us. We look forward to hearing your thoughts on the upcoming changes.
Thank you for your understanding and continued support.
Sincerely,
Project Admin


extra characters inserted in "Select by Attributes" WHERE options

After using the "Load osm" and "OSM Attribute Selector" tools, if I open a "Select by Attributes" window, the list of available WHERE fields show "osm_" before the key. Example: instead of cycleway, I have osm_cycleway. Also, "58" seems to replace ":" Example: osm_cycleway_58_left instead of cycleway:left.

After using the "Load osm" and "OSM Attribute Selector" tools, if I open a "Select by Attributes" window, the list of available WHERE fields show "osm_" before the key. Example: instead of cycleway, I have osm_cycleway. Also, "58" seems to replace ":" Example: osm_cycleway_58_left instead of cycleway:left.

This is by design. Database field names can not contain a ":" character, hence it is replaced by its (ASCII?) index number. Also, the "-" char (much less common in OSM key names), is similarily replaced by "45".
Yes, it also prepends the "osm_" to field names. It helps distinguishing the default set of OSM keys the tool always extracts (e.g. "highway", "railway", "building"), from fields extracted by the OSM Attribute Selector tool. I actually use this information heavily in my ArcGIS Renderer...
So you need to adjust you SQL statements, like in a layer file's Definition Query, to deal with this. Not a big issue though, you just need to be aware of this.
The tools do set a proper alias though, to make the fields more easily recognizable.

@mboeringa thanks!


Remove duplicate file id

https://keboola.atlassian.net/browse/PS-1646

@odinuv I can't click you as reviewer because it's originally your PR, but this is ready...

yeah, had a look through it - i think it's ok - so I set you as a reviewer :)

:-) thanks.  I'll just change thoae fails to expected exceptions


Qt metapackage mutually incompatible with PyQt on Python 3.11

Solution to issue cannot be found in the documentation.

[X] I checked the documentation.

Issue
When upgrading QtPy's CI matrix to test on Python 3.11 in spyder-ide/qtpy#392 , I've discovered an issue with the current pinning in this metapackage on Python 3.11, which @ccordoba12 recommended I report here, where it seems most proximate and solvable. Specifically, no version of the qt metapackage and pyqt are mutually compatible on Python 3.11, and running
conda create -n test-env python=3.11 pyqt qt

or equivalently
conda create -n test-env python=3.11 pyqt=5.15 qt=5.15

fails on all platforms with a dependency resolution error, which you can see the full output of on CI for each platform in e.g. this run.
Specifically, I've traced the issue to following three incompatible constraints:

The latest pyqt 5.15.7 is the earliest version supported on Python 3.11 (5.15.4 will not install)
pyqt 5.15.7 requires qt-main, of which only 5.15.6 is mutually compatible with pyqt (5.15.4 is mutually incompatible, but will install on its own on Python 3.11, or with pyqt 5.15.7on Python <3.11)
The latest version of the qt 5.15 meta-package is 5.15.4, which pins on qt-main and qt-webengine of the same point version

To note,
conda create -n test-env python=3.11 pyqt=5.15.7 qt-main=5.15.6 qt-webengine=5.15.4

does resolve. Also, 5.15.4 is the latest version of qt-webengine, though conda-forge/qt-webengine-feedstock#20 is open to update it to 5.15.7—though that wouldn't be in sync with the latest qt-main version, so I'm not sure if that can be pinned with qt unless qt-main is also updated to that version.
Presumably, at least one of the following need to happen:

A new re-rendered build of the existing versions of the qt metapackage and the qt-main 5.15.4 packge, if conda-smithy re-rendering for Python 3.11 will fix it.
A new release of the qt metapackage keeping the existing qt-webengine and upgrading qt-main to the working 5.15.6 version (but then the versions wouldn't match)
Updating qt-webengine to 5.15.6 and releasing a new qt 5.15.6 metapackage with both deps pinned to that version
Merging conda-forge/qt-webengine-feedstock#20  for qt-webengine 5.15.7, and updating qt-main to 5.15.7, and finally releasing a new qt metapackage version accordingly
Some other easier solution to the fundamental incompatibility?

However, you'd be the ones with the expertise and experience to determine the best course of action. Thanks!
Installed packages
See the Test PyQt step of each CI runs for full command output, conda list, conflict information and other details for each platform.
In addition, the problem can be reproduced in a new clean environment by running
conda create -n test-env python=3.11 pyqt qt
or equivalently
conda create -n test-env python=3.11 pyqt=5.15 qt=5.15

Environment info
See the Conda Info step of each CI runs for full output of conda info and other environment information for each platform.

I think I likely "fixed" this in https://github.com/conda-forge/qt-feedstock/pull/235
Though we really don't recommend depending on this package anymore.
Most of the effort has moved toward qt-main

Yup, I can confirm this is fixed by #235—the above install specs now resolve successfully, and our CIs work again without the complexity of separate code paths for installing different minor versions. We don't actually hard depend on the qt metapackage, and for Qt6 on Conda our CIs install qt6-main, so this shouldn't be an issue long term. Thanks!


TypeError: fileno() takes 0 positional arguments but 1 was given

Expected Behavior
My CLI should work correctly when installed outside its development venv. These are some of the commands that produces the error.
mycli

mycli commandthatusesecho

mycli --help

Actual Behavior
Instead it produces this kind of error when the CLI is being called in the terminal. It works well on commands that doesn't use click.echo().
My Project Structure
my_package\
	__init__.py
	cli.py
	my_module.py
	my_other_module.py
setup.py

cli.py
import click
from click import echo, types

@click.group()
def cli():
    """My CLI"""
    pass

@cli.command()
def commandthatusesecho():
    echo("Bad")

@cli.command()
def workingcommand():
    print("Good")

setup.py
import setuptools

setuptools.setup(
	name="my_package",
    version="version",
    packages=setuptools.find_packages(),
    include_package_data=True,
    install_requires=[
        "click",
        "other_dependency"
    ],
    entry_points="""
    	[console_scripts]
    	mycli=my_package.cli:cli
    """
)

The Error
Traceback (most recent call last):
  File "C:\Users\desktop\AppData\Local\Programs\Python\Python38\Scripts\pydeezer-script.py", line 11, in <module>
    load_entry_point('py-deezer', 'console_scripts', 'pydeezer')()
  File "c:\users\desktop\appdata\local\programs\python\python38\lib\site-packages\click\core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "c:\users\desktop\appdata\local\programs\python\python38\lib\site-packages\click\core.py", line 781, in main
    with self.make_context(prog_name, args, **extra) as ctx:
  File "c:\users\desktop\appdata\local\programs\python\python38\lib\site-packages\click\core.py", line 700, in make_cont
ext
    self.parse_args(ctx, args)
  File "c:\users\desktop\appdata\local\programs\python\python38\lib\site-packages\click\core.py", line 1209, in parse_ar
gs
    echo(ctx.get_help(), color=ctx.color)
  File "c:\users\desktop\appdata\local\programs\python\python38\lib\site-packages\click\utils.py", line 230, in echo
    file = _default_text_stdout()
  File "c:\users\desktop\appdata\local\programs\python\python38\lib\site-packages\click\_compat.py", line 764, in func
    rv = wrapper_func()
  File "c:\users\desktop\appdata\local\programs\python\python38\lib\site-packages\click\_compat.py", line 459, in get_te
xt_stdout
    rv = _get_windows_console_stream(sys.stdout, encoding, errors)
  File "c:\users\desktop\appdata\local\programs\python\python38\lib\site-packages\click\_winconsole.py", line 356, in _g
et_windows_console_stream
    and _is_console(f)
  File "c:\users\desktop\appdata\local\programs\python\python38\lib\site-packages\click\_winconsole.py", line 343, in _i
s_console
    fileno = f.fileno()
TypeError: fileno() takes 0 positional arguments but 1 was given

Environment

Python version: Python 3.8.2
Click version: 7.1.1

Turns out the issue is my environment. I have a friend install and try it for me and it works for him.


pull request for e2e test at 01/31/2017 19:26:13

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Added smbambling as co-owener of sensu-plugins-tomcat repository

Can you please add me as a co-owner to this repository

I sent an invite to be a collaborator with write access (only could do that since I created the repo and would not have access to do so on existing repos). Can we close this or do you really need admin? I would certainly not be comfortable giving you that without having a discussion with @mattyjones first.

Nope write access should be more then plenty, my usage of co-owner was just incorrect. Thank you!


gdxListOf gone?

After refreshing to latest SNAPSHOT today I saw that gdxListOf is no longer there. Also tried version b6 but also there it is gone., Seems like I can simply replace it with gdxArrayOf but I wonder what happened to gdxListOf? Was that something very old that was cached somehow on my end?

No, it was removed in the 1.9.10-b6 release. It was a very old collection with some safety issues that would require significant changes.
I reviewed the implementation while refactoring operators in gdx-collections and noticed that PooledList reuses a single iterator, which makes concurrent iteration impossible and might lead to some unexpected behaviours. Besides, the name suggests that it is a direct equivalent to stdlib listOf, while this is not the case - this was more of a linked list and gdxArrayOf should be preferred most of the time.
What were you using it for? If that was a collection you iterated over and removed elements during iteration, PooledLinkedList from LibGDX would be a direct equivalent with a slightly worse API (it's not Iterable). Otherwise you can use gdxArrayOf or linked list from stdlib.
If you'd like to refactor the collection (e.g. add pooled iterator instances rather than a single reused iterator), I'll happily review the PR, but I have no plans to add it for now.

I could replace it with gdxArrayOf. I think it originally came from your example with assetstorage where we stored the loadAsync calls in a flat list to use joinAll later.
Changing to gdxArrayOf worked here as well and it also contained the flatten function.
I will close this issue then - solved  :)

That's exactly what I've mentioned - you used gdxListOf instead of listOf, while what you needed was an ArrayList equivalent - gdxArrayOf. PooledList (or gdxListOf) was a pretty niche collection with too vague of a name, and admittedly it was not a very well designed part of KTX API.


Skype getting Crashed once I viewed the profile from group

Hello Team,
My skype getting crashed when I have viewed user profile from the group list.
Steps to reproduce:

Open Skype
Open  Group list
Choose a user
Choose view profile
Tap on the user image
Press the close button app gets crashed

Configuration:
iPhone 8 - iOS 12
Skype version: 8.33
Reference Video:
https://www.dropbox.com/s/7eob3va8rpwyo25/skype crash.MP4?dl=0

@satheesh-mallow
Thanks for your feedback. We use Github issues for documentation bugs, not for developer support. Please try the developer community on Stack Overflow (https://stackoverflow.com) where you can get help from actual developers. If you find a bug in our documentation, please let us know! Thanks!


Update to wasmvm / cosmwasm 0.16

There will be one more update before
Key Changes:

Lots of changes to the IbcChannel*Msg types
CounterPartyVersion is no longer in IbcChannel but in some of those messages
Change standard contract_address event attribute (for wasm type) to _contract_address.
Enforce the contract cannot return any _* attributes and thus conflict with any special "trusted" attributes from the runtime.
Handle custom events from IbcBasicResponse and IbcReceiveResponse (not just attributes)

contract_address event attribute (for wasmtype) to_contract_address`.

This affects custom events as well. Alex started injecting wasmd attributes into those as well to make it possible to trust the origin of those events (see contractSDKEventAttributes in https://github.com/CosmWasm/wasmd/pull/548). This makes reserving all _* more important and powerful. You then get the guarantee that all _* attributes are written by wasmd, not the contract.


Replace renderOneFrame for per-workspace update calls

🎉 New feature
Implements #323 for ign-rendering
Summary
Explanation is in the ticket
The ticket shouldn't be closed until all modules are merged.
Test it
This PR is currently defaulting SetCameraPassCountPerGpuFlush to 0 avoid breaking ign-sensors.
In order to fully test it, checkout:

https://github.com/darksylinc/ign-rendering/tree/matias-PostFrame5
https://github.com/darksylinc/ign-gazebo/tree/matias-PostFrame5
https://github.com/darksylinc/ign-sensors/tree/matias-PostFrame5

And set SetCameraPassCountPerGpuFlush to non-0 (e.g. set Ogre2ScenePrivate::cameraPassCountPerGpuFlush to 6)
This change is mostly a performance one; but it also affects particle FXs (and possibly some postprocessing FXs) because without this PR, Ogre2GpuRays rendering a cubemap with particle FXs will render each of the 6 faces in a different time; i.e. as if the simulation moved forward 6 times
Checklist

[x] Signed all commits for DCO
[ ] Added tests
[ ] Added example and/or tutorial
[ ] Updated documentation (as needed)
[ ] Updated migration guide (as needed)
[x] codecheck passed (See contributing)
[x] All tests passed (See test coverage)
[x] While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge

Hi @darksylinc , mind updating the PR title to be a bit more descriptive? Thanks!

Hi @darksylinc , mind updating the PR title to be a bit more descriptive? Thanks!

Done! Sorry!!! :frowning:

This looks good. Can you also update your other branches (ign-sensors and ign-gazebo5) to rebase off of main and create PRs for those? thanks

Done! Rebased all 3 to main branch.

https://github.com/ignitionrobotics/ign-rendering/pull/353 (this PR)
https://github.com/ignitionrobotics/ign-gazebo/pull/921
https://github.com/ignitionrobotics/ign-sensors/pull/145


[Snyk] Security upgrade org.apache.cassandra:cassandra-all from 3.11.2 to 5.0.0

Snyk has created this PR to fix 14 vulnerabilities in the maven dependencies of this project.
Snyk changed the following file(s):

cassandra/java/pom.xml

Vulnerabilities that will be fixed with an upgrade:

Issue
Score
Upgrade

Arbitrary Code Execution SNYK-JAVA-ORGYAML-3152153
  555
org.apache.cassandra:cassandra-all:  3.11.2 -> 5.0.0 Major version upgrade No Path Found Proof of Concept

Denial of Service (DoS) SNYK-JAVA-ORGYAML-2806360
  525
org.apache.cassandra:cassandra-all:  3.11.2 -> 5.0.0 Major version upgrade No Path Found No Known Exploit

Denial of Service (DoS) SNYK-JAVA-ORGYAML-6056527
  525
org.apache.cassandra:cassandra-all:  3.11.2 -> 5.0.0 Major version upgrade No Path Found No Known Exploit

Denial of Service (DoS) SNYK-JAVA-ORGYAML-537645
  495
org.apache.cassandra:cassandra-all:  3.11.2 -> 5.0.0 Major version upgrade No Path Found Proof of Concept

Cross-site Scripting (XSS) SNYK-JAVA-ORGHIBERNATE-569100
  483
org.apache.cassandra:cassandra-all:  3.11.2 -> 5.0.0 Major version upgrade No Path Found No Known Exploit

Stack-based Buffer Overflow SNYK-JAVA-ORGYAML-3016891
  440
org.apache.cassandra:cassandra-all:  3.11.2 -> 5.0.0 Major version upgrade No Path Found Proof of Concept

JSM bypass via ReflectionHelper SNYK-JAVA-ORGHIBERNATE-30098
  415
org.apache.cassandra:cassandra-all:  3.11.2 -> 5.0.0 Major version upgrade No Path Found No Known Exploit

Improper Input Validation SNYK-JAVA-ORGHIBERNATE-568162
  415
org.apache.cassandra:cassandra-all:  3.11.2 -> 5.0.0 Major version upgrade No Path Found No Known Exploit

Stack-based Buffer Overflow SNYK-JAVA-ORGYAML-3016888
  410
org.apache.cassandra:cassandra-all:  3.11.2 -> 5.0.0 Major version upgrade No Path Found Proof of Concept

Information Disclosure SNYK-JAVA-COMGOOGLEGUAVA-1015415
  390
org.apache.cassandra:cassandra-all:  3.11.2 -> 5.0.0 Major version upgrade No Path Found Proof of Concept

Information Exposure SNYK-JAVA-COMMONSCODEC-561518
  335
org.apache.cassandra:cassandra-all:  3.11.2 -> 5.0.0 Major version upgrade No Path Found No Known Exploit

Stack-based Buffer Overflow SNYK-JAVA-ORGYAML-3016889
  335
org.apache.cassandra:cassandra-all:  3.11.2 -> 5.0.0 Major version upgrade No Path Found No Known Exploit

Stack-based Buffer Overflow SNYK-JAVA-ORGYAML-3113851
  335
org.apache.cassandra:cassandra-all:  3.11.2 -> 5.0.0 Major version upgrade No Path Found No Known Exploit

Creation of Temporary File in Directory with Insecure Permissions SNYK-JAVA-COMGOOGLEGUAVA-5710356
  315
org.apache.cassandra:cassandra-all:  3.11.2 -> 5.0.0 Major version upgrade No Path Found No Known Exploit

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
Max score is 1000. Note that the real score may have changed since the PR was raised.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Creation of Temporary File in Directory with Insecure Permissions
🦉 Improper Input Validation
🦉 Cross-site Scripting (XSS)
🦉 More lessons are available in Snyk Learn

Checkmarx One – Scan Summary & Details – a8c639bf-27a2-4d4a-b1e8-23f8eb436473
New Issues

Severity
Issue
Source File / Package
Checkmarx Insight

Container Is Privileged
/sysdig-daemonset.yaml: 44
Privileged containers lack essential security restrictions and should be avoided by removing the 'privileged' flag or by changing its value to false

Container Is Privileged
/nfs-server-deployment.yaml: 26
Privileged containers lack essential security restrictions and should be avoided by removing the 'privileged' flag or by changing its value to false

Container Is Privileged
/es-rc.yaml: 21
Privileged containers lack essential security restrictions and should be avoided by removing the 'privileged' flag or by changing its value to false

Container Is Privileged
/sysdig-rc.yaml: 42
Privileged containers lack essential security restrictions and should be avoided by removing the 'privileged' flag or by changing its value to false

Container Is Privileged
/ds.yaml: 17
Privileged containers lack essential security restrictions and should be avoided by removing the 'privileged' flag or by changing its value to false

Container Is Privileged
/newrelic-infra-daemonset.yaml: 28
Privileged containers lack essential security restrictions and should be avoided by removing the 'privileged' flag or by changing its value to false

Container Is Privileged
/newrelic-daemonset.yaml: 34
Privileged containers lack essential security restrictions and should be avoided by removing the 'privileged' flag or by changing its value to false

Passwords And Secrets - Password in URL
/sysdig-daemonset.yaml: 57
Query to find passwords and secrets in infrastructure code.

Privilege Escalation Allowed
/mongo-pod.json: 23
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/pod-uses-shared-hdd.yaml: 10
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/openshift-controller.yaml: 26
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/selenium-hub-deployment.yaml: 18
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/flocker-pod.yml: 7
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/iscsi.yaml: 8
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/minio-standalone-deployment.yaml: 25
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/rbd.yaml: 8
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/quobyte-pod.yaml: 7
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/pod-uses-dedicated-hdd.yaml: 10
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/cassandra-statefulset.yaml: 39
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/pxc-node2.yaml: 38
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/exclusive-3.yaml: 8
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/etcd-controller-template.yaml: 3
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/be.yaml: 8
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/shared.yaml: 8
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/es-rc.yaml: 24
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/frontend-deployment.yaml: 18
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/mysql.yaml: 13
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/rbd-with-secret.yaml: 8
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/redis-replica.yaml: 36
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/javaweb-2.yaml: 15
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/nginx.yaml: 8
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/spark-worker-controller.yaml: 15
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/storm-worker-controller.yaml: 20
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/javaweb.yaml: 15
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/nginx-app.yaml: 38
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/cockroachdb-statefulset.yaml: 100
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/redis-master.yaml: 24
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/vtctld-controller-template.yaml: 14
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/cockroachdb-statefulset.yaml: 127
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/redis-sentinel-controller.yaml: 17
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/spark-master-controller.yaml: 18
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/etcd-discovery-controller.yaml: 31
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/spark-worker-controller.yaml: 19
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/dns-backend-rc.yaml: 17
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/redis-master.yaml: 11
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/pod-uses-account-hdd.yaml: 10
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/nginx-nfs.yaml: 8
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/es-client-rc.yaml: 19
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/selenium-node-firefox-deployment.yaml: 22
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/pod.yaml: 15
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/mysql-deployment.yaml: 49
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/guestbook-all-in-one.yaml: 81
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/es-rc.yaml: 20
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/vsphere-volume-pvcpod.yaml: 7
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/vsphere-volume-pod.yaml: 8
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/storm-nimbus.json: 13
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/newrelic-daemonset.yaml: 28
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/azure.yaml: 8
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/vttablet-pod-template.yaml: 3
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/minio-distributed-statefulset.yaml: 19
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/wildfly-rc.yaml: 16
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/redis-master-deployment.yaml: 20
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/vsphere-volume-pvcscvsanpod.yaml: 7
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/cinder-web.yaml: 7
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/nfs-web-deployment.yaml: 19
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/admin-pod.yaml: 11
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/web-controller-demo.yaml: 20
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/aws-ebs-web.yaml: 7
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/web-controller.yaml: 18
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/javaweb.yaml: 8
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/guestbook-all-in-one.yaml: 134
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/fc.yaml: 8
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/deployment.yaml: 16
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/selenium-node-chrome-deployment.yaml: 22
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/redis-controller.yaml: 16
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/simple-statefulset.yaml: 34
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/nginx-dummy-attachable.yaml: 8
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/wordpress-deployment.yaml: 49
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/redis-replica-controller.yaml: 19
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/pod.yaml: 8
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/glusterfs-pod.yaml: 7
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/pxc-node1.yaml: 37
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/example-pod.yaml: 15
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/pod-uses-managed-hdd.yaml: 10
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/pod.yaml: 7
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/pod-uses-existing-managed-disk.yaml: 10
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/rc.yaml: 20
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/guestbook-controller.yaml: 14
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/flocker-pod-with-rc.yml: 31
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/pod-uses-managed-ssd.yaml: 10
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/storageos-pod.yaml: 10
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/zookeeper.json: 13
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/etcd-controller.yaml: 49
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/exclusive-2.yaml: 8
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/example-pod.yaml: 15
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/sysdig-rc.yaml: 41
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/pod.yaml: 9
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/cephfs.yaml: 7
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/portworx-volume-pod.yaml: 8
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/guestbook-all-in-one.yaml: 37
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/redis-replica-controller.json: 27
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/vsphere-volume-pvcscpod.yaml: 7
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/mysql-pod.yaml: 10
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/redis-master-controller.yaml: 19
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/storageos-pvcpod.yaml: 10
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/frontend.yaml: 37
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/sysdig-daemonset.yaml: 43
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/nginx-lvm.yaml: 8
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/azure.yaml: 8
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/pod-sc-pvc.yaml: 7
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/azure-2.yaml: 8
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/zeppelin-controller.yaml: 15
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/dns-frontend-pod.yaml: 9
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/cephfs-with-secret.yaml: 7
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/frontend-controller.yaml: 14
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/iscsi-chap.yaml: 8
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/mongo-controller.yaml: 16
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/exclusive-4.yaml: 8
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/guestbook-controller.json: 24
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/pod_priv.yaml: 13
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/nfs-server-deployment.yaml: 25
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/pxc-node3.yaml: 38
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/newrelic-infra-daemonset.yaml: 25
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/redis-replica-deployment.yaml: 20
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/nfs-busybox-deployment.yaml: 25
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/vtgate-controller-template.yaml: 14
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/spark-ui-proxy-controller.yaml: 15
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/exclusive-1.yaml: 8
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/javaweb-2.yaml: 8
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/portworx-volume-pvcpod.yaml: 7
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/meteor-controller.json: 21
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/storageos-sc-pvcpod.yaml: 10
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/redis-master-controller.json: 27
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/vttablet-pod-template.yaml: 3
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/phabricator-controller.json: 24
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/es-master-rc.yaml: 19
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/ds.yaml: 16
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/spark-master-controller.yaml: 15
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/es-data-rc.yaml: 19
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/pod-uses-shared-ssd.yaml: 10
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/portworx-volume-pvcscpod.yaml: 7
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/nginx-dummy.yaml: 8
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Privilege Escalation Allowed
/hazelcast-deployment.yaml: 17
Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process

Apt Get Install Pin Version Not Defined
/Dockerfile: 15
When installing a package, its pin version should be defined

Apt Get Install Pin Version Not Defined
/Dockerfile: 15
When installing a package, its pin version should be defined

Apt Get Install Pin Version Not Defined
/Dockerfile: 15
When installing a package, its pin version should be defined

CPU Limits Not Set
/redis-master-controller.json: 27
CPU limits should be set because if the system has CPU time free, a container is guaranteed to be allocated as much CPU as it requests

CPU Limits Not Set
/guestbook-controller.json: 24
CPU limits should be set because if the system has CPU time free, a container is guaranteed to be allocated as much CPU as it requests

CPU Limits Not Set
/mongo-pod.json: 23
CPU limits should be set because if the system has CPU time free, a container is guaranteed to be allocated as much CPU as it requests

CPU Limits Not Set
/meteor-controller.json: 21
CPU limits should be set because if the system has CPU time free, a container is guaranteed to be allocated as much CPU as it requests

CPU Limits Not Set
/redis-replica-controller.json: 27
CPU limits should be set because if the system has CPU time free, a container is guaranteed to be allocated as much CPU as it requests

CPU Limits Not Set
/phabricator-controller.json: 24
CPU limits should be set because if the system has CPU time free, a container is guaranteed to be allocated as much CPU as it requests

CPU Requests Not Set
/redis-master-controller.json: 27
CPU requests should be set to ensure the sum of the resource requests of the scheduled Containers is less than the capacity of the node

CPU Requests Not Set
/meteor-controller.json: 21
CPU requests should be set to ensure the sum of the resource requests of the scheduled Containers is less than the capacity of the node

CPU Requests Not Set
/redis-replica-controller.json: 27
CPU requests should be set to ensure the sum of the resource requests of the scheduled Containers is less than the capacity of the node

CPU Requests Not Set
/zookeeper.json: 20
CPU requests should be set to ensure the sum of the resource requests of the scheduled Containers is less than the capacity of the node

CPU Requests Not Set
/storm-nimbus.json: 20
CPU requests should be set to ensure the sum of the resource requests of the scheduled Containers is less than the capacity of the node

CPU Requests Not Set
/phabricator-controller.json: 24
CPU requests should be set to ensure the sum of the resource requests of the scheduled Containers is less than the capacity of the node

CPU Requests Not Set
/guestbook-controller.json: 24
CPU requests should be set to ensure the sum of the resource requests of the scheduled Containers is less than the capacity of the node

CPU Requests Not Set
/mongo-pod.json: 23
CPU requests should be set to ensure the sum of the resource requests of the scheduled Containers is less than the capacity of the node

Container Running As Root
/pod_priv.yaml: 13
Containers should only run as non-root user. This limits the exploitability of security misconfigurations and restricts an attacker's possibilities...

Container Running As Root
/pxc-node2.yaml: 38

More results are available on AST platform


Scaling plan creation failing [fixed]

Overview/Summary
There was a bug in the code that stopped the scaling plan from being created. It was caused by the role assignment not giving the correct role. This resulted in a permission error when creating the scaling plan. I solved the bug by changing the application_id to object_id, as the terraform documentation suggests.
This PR fixes/adds/changes/removes

I have fixed the error in the 4 scenarios in the greenfield folder

Breaking Changes

Fix the error in the role assignment using object_id instead of application_id

Testing Evidence
I have personally tested only the ADDS scenario, that make me confident the scaling plan creation is working as expected as a consequence of right role assignment fixed.
As part of this Pull Request I have

[ ] Read the Contribution Guide and ensured this PR is compliant with the guide
[ ] Ensured the resource API versions in .bicep file/s I am adding/editing are using the latest API version possible
[ ] Checked for duplicate Pull Requests
[ ] Associated it with relevant GitHub Issues
[ ] (AVD LZA Team Only) Associated it with relevant ADO Items
[ ] Ensured my code/branch is up-to-date with the latest changes in the main branch
[ ] Performed testing and provided evidence.
[ ] Updated relevant and associated documentation (e.g. Contribution Guide, Module READMEs, Docs etc.)

@ripom thanks for your contribution.
@jensheerin @sihbher please you help checking.


Higher memory consumption with AdoptOpenJDK

Hello,
We are currently planning to switch our product from Oracle JRE to AdoptOpenJDK. Here we use the following variants:
Oracle JRE: Version 8u192, Windows x32
AdoptOpenJDK JRE: Version 8u192, Hotspot, Windows x32
If we analyze the memory consumption and the performance of the main use case in our product with these two runtimes, we get the following values:
Oracle JRE:

Performance: 47 seconds
Memory: 195 MB
AdoptOpenJDK JRE:
Performance: 38 seconds
Memory: 520 MB

We then looked at the possible starting parameters of the two JREs. Here we found the switch "-Xincgc" (activating incremental garbage collection) at the Oracle JRE. If we activate this switch, we get the same performance and the same memory consumption as with AdoptOpenJDK. However, we could not find this switch in the JRE of AdoptOpenJDK.
In our scenario, performance is important, but memory consumption is more important. Therefore we would like to ask if there is a setting possibility of the AdoptOpenJDK JRE, with which it behaves like the Oracle JRE?

@GitHubHans1 The -Xincgc should work for the AdoptOpenJDK JRE - what occurs if you use that?

Hi karianna,
Thank you very much for your quick answer.
In the meantime we have done further tests with various parameters.
Unfortunately, if we use this switch, the memory consumption will increase even further.
Can you help us to get memory consumption to a level similar to Oracle JRE?

Can you run -XX:+PrintFlagsFinal for both the Oracle JDK and the AdoptOpenJDK and attach them here?

OracleJDK8_AllFlags.txt
OpenJDK8_AllFlags.txt
Thank you very much for your fast answer.
Attached you will find the Flags.

Hi @karianna
I'm also seeing higher memory consumption in Ubuntu OS with 8u192. I can pass more information if you want. Is this known issue? (I'm trying to understand "Waiting on OP" means). Thanks

Possibly related to this thread...  We're starting to dig into differences in memory consumption between the Alpine Linux package of 8u222 (which is linked against musl) and AdoptOpenJDK running on the same Alpine base.  Based on our testing so far, AdoptOpenJDK does use more memory for the same code.
A co-worker pointed out that musl is optimized to reduce memory footprint whereas glibc is optimized for CPU utilization.  We're not seeing the same delta reported by @GitHubHans1 , but the fact that the AdoptOpenJDK test had higher performance matches that.
I'd also be interested to hear if anyone has seen increased memory usage on applications that run large numbers of threads.  https://wiki.musl-libc.org/functional-differences-from-glibc.html documents a different default thread stack size when using musl.

Thanks @tmancill ,
Our application has large number of threads and we relatively see more memory usage with 8u212 (compared with same version of oracle JDK).
I have analyzed few heap dumps using MAT and I can see sun.security.ssl.SSLSocketImpl doesn't garbage collected (or takes very long time to GC) compare to oracle JDK. I think it is because of finalize() method in sun.security.ssl.BaseSSLSocketImpl (but I assume both AdoptOpenJDK and Oracle JDK has same implementation for this class). This is still puzzle for me to understand why oracle JDK can do GC faster than AdoptOpenJDK?
Our application heavily use SSLSocketImpl. Any thoughts on this please?

I finally got around diff the two text files, it's pretty clear that the Oracle GC settings are different from what you're getting from OpenJDK.  You'll need to set your GC settings explicitly

Thank you very much for analyzing the two text files. Could you please name the relevant settings that make the difference?

@GitHubHans1
Just sort and diff. This is one minute task

@GitHubHans1
Were you managed to resolve this issue ? I am getting somewhat similar issue with my microservice.