Failure to create a new hive source. What can be done about it?

创建hive源，开启了kdc认证，本地可以hive直接登录，但是作为hive源连接的话就报如下错误，引用了hive的jiar包后，服务则无法启动，想知道报这种错误是哪里设置不对还是什么问题？要怎么解决？谢谢！

Please check whether the hive jar version referenced by ds is consistent with the hive server version, and whether there are fewer jars. If you are not sure, you can copy all the hive server hive-*.jar to the ds lib directory.

请查看ds 引用的hive jar 版本和 hive 服务端版本是否一致，是否少jar，如果不确定可以把hive 服务端 hive-*.jar 全部拷贝到ds lib目录下

please update the title in English

https://github.com/apache/incubator-dolphinscheduler/issues/3791#issuecomment-697073154
我把hive-*.jar包全部拷贝到lib目录下后，重新安装后，api-server服务无法启动，页面打不开了，帮忙看看
[INFO] 2020-09-23 10:53:11.837 org.eclipse.jetty.util.log:[193] - Logging initialized @3214ms to org.eclipse.jetty.util.log.Slf4jLog
[INFO] 2020-09-23 10:53:11.927 org.eclipse.jetty.server.Server:[370] - jetty-9.4.14.v20181114; built: 2018-11-14T21:20:31.478Z; git: c4550056e785fb5665914545889f21dc136ad9e6; jvm 1.8.0_202-b08
[INFO] 2020-09-23 10:53:11.958 org.eclipse.jetty.server.handler.ContextHandler.application:[2345] - Initializing Spring embedded WebApplicationContext
[INFO] 2020-09-23 10:53:12.001 org.eclipse.jetty.server.session:[365] - DefaultSessionIdManager workerName=node0
[INFO] 2020-09-23 10:53:12.001 org.eclipse.jetty.server.session:[370] - No SessionScavenger set, using defaults
[INFO] 2020-09-23 10:53:12.003 org.eclipse.jetty.server.session:[149] - node0 Scavenging every 660000ms
[INFO] 2020-09-23 10:53:12.007 org.eclipse.jetty.server.handler.ContextHandler:[855] - Started o.s.b.w.e.j.JettyEmbeddedWebAppContext@4b87074a{application,/dolphinscheduler,[file:///tmp/jetty-docbase.7667266662126961927.9200/, jar:file:/opt/soft/dolphinscheduler/lib/swagger-bootstrap-ui-1.9.3.jar!/META-INF/resources, jar:file:/opt/soft/dolphinscheduler/lib/springfox-swagger-ui-2.9.2.jar!/META-INF/resources],AVAILABLE}
[INFO] 2020-09-23 10:53:12.008 org.eclipse.jetty.server.Server:[407] - Started @3387ms
[INFO] 2020-09-23 10:53:12.023 org.apache.dolphinscheduler.service.zk.ZookeeperOperator:[82] - zookeeper registry center init, server lists is: <IP_ADDRESS>:2181,<IP_ADDRESS>:2181,<IP_ADDRESS>:2181.
[INFO] 2020-09-23 10:53:12.079 org.apache.curator.utils.Compatibility:[48] - Running in ZooKeeper 3.4.x compatibility mode
[INFO] 2020-09-23 10:53:12.080 org.apache.curator.utils.Compatibility:[61] - Using emulated InjectSessionExpiration
[INFO] 2020-09-23 10:53:12.156 org.apache.curator.framework.imps.CuratorFrameworkImpl:[308] - Starting
[INFO] 2020-09-23 10:53:12.181 org.apache.curator.framework.imps.CuratorFrameworkImpl:[356] - Default schema
[INFO] 2020-09-23 10:53:12.193 org.apache.curator.framework.state.ConnectionStateManager:[251] - State change: CONNECTED
[INFO] 2020-09-23 10:53:12.197 org.apache.dolphinscheduler.service.zk.ZookeeperOperator:[82] - zookeeper registry center init, server lists is: <IP_ADDRESS>:2181,<IP_ADDRESS>:2181,<IP_ADDRESS>:2181.
[INFO] 2020-09-23 10:53:12.197 org.apache.curator.framework.imps.CuratorFrameworkImpl:[308] - Starting
[INFO] 2020-09-23 10:53:12.198 org.apache.curator.framework.imps.CuratorFrameworkImpl:[356] - Default schema
[INFO] 2020-09-23 10:53:12.199 org.apache.curator.framework.state.ConnectionStateManager:[251] - State change: CONNECTED
[INFO] 2020-09-23 10:53:12.207 org.apache.dolphinscheduler.service.zk.ZookeeperCachedOperator:[43] - add listener to zk path: /dolphinscheduler
[INFO] 2020-09-23 10:53:13.360 org.apache.dolphinscheduler.service.zk.ZookeeperOperator:[82] - zookeeper registry center init, server lists is: <IP_ADDRESS>:2181,<IP_ADDRESS>:2181,<IP_ADDRESS>:2181.
[INFO] 2020-09-23 10:53:13.361 org.apache.curator.framework.imps.CuratorFrameworkImpl:[308] - Starting
[INFO] 2020-09-23 10:53:13.362 org.apache.curator.framework.imps.CuratorFrameworkImpl:[356] - Default schema
[INFO] 2020-09-23 10:53:13.363 org.apache.curator.framework.state.ConnectionStateManager:[251] - State change: CONNECTED
[INFO] 2020-09-23 10:53:13.364 org.apache.dolphinscheduler.service.zk.ZookeeperCachedOperator:[43] - add listener to zk path: /dolphinscheduler
[INFO] 2020-09-23 10:53:14.384 springfox.documentation.spring.web.plugins.DocumentationPluginsBootstrapper:[160] - Context refreshed
[INFO] 2020-09-23 10:53:14.399 springfox.documentation.spring.web.plugins.DocumentationPluginsBootstrapper:[163] - Found 1 custom documentation plugin(s)
[INFO] 2020-09-23 10:53:14.478 springfox.documentation.spring.web.scanners.ApiListingReferenceScanner:[41] - Scanning for api listing references
[INFO] 2020-09-23 10:53:14.524 org.apache.dolphinscheduler.remote.NettyRemotingClient:[376] - netty client closed
[INFO] 2020-09-23 10:53:14.525 org.apache.dolphinscheduler.service.log.LogClientService:[59] - logger client closed
[INFO] 2020-09-23 10:53:14.531 org.eclipse.jetty.server.session:[167] - node0 Stopped scavenging
[INFO] 2020-09-23 10:53:14.533 org.eclipse.jetty.server.handler.ContextHandler:[1045] - Stopped o.s.b.w.e.j.JettyEmbeddedWebAppContext@4b87074a{application,/dolphinscheduler,[file:///tmp/jetty-docbase.7667266662126961927.9200/, jar:file:/opt/soft/dolphinscheduler/lib/swagger-bootstrap-ui-1.9.3.jar!/META-INF/resources, jar:file:/opt/soft/dolphinscheduler/lib/springfox-swagger-ui-2.9.2.jar!/META-INF/resources],UNAVAILABLE}

Has the issue been resolved？

Not Resolved, is the current version does not support the connection of HIV 3?

Is the environment variable HIVE_HOME configured in  conf/env/dolphinscheduler_env.sh of DS

Configured as shown in figure：

Need to configure the environment variables of the hive-client

What do you mean? You mean the environment variable for the current user of the system: . Yeah, this?

< What do you mean? You mean the environment variable for the current user of the system: . Yeah, this?
yes

修改过后还是不行，报错依旧，先确定下当前1.3.2的jar包版本是否支持hive3的数据源连接？

Using hive3, you can modify the source pom file, and recompile and package, please refer to this article https://my.oschina.net/dailidong/blog/4483145

The current environment is not CDH environment, and Hadoop, hive and other versions are already 3. The X version, is there any other way to solve it? No source compiled, there is no compiled good tar package can be shared under, thank you!

Which version of DS?

which version of hive3 ?

1.3.2的版本

hive3需要哪个版本？

version <IP_ADDRESS>.1.4.0-315

The installation package is extracted from the link below
链接: https://pan.baidu.com/s/1GQOOAALZVkbrGkuDeJnD8g 提取码: b279
You can replace hive 2.1.0 jar in the lib directory with 3.1.0, then restart the service

Thank you very much. Would you like to simply replace the jar package? No need to reinstall it, right?

Thank you very much. Would you like to simply replace the jar package? No need to reinstall it, right?

yes, you need restart the api/worker server

Wether the problem  has solved?

还没来得急测试，这两天试一下再回复你！

当前报错：

当前报错：

Thank you very much. That problem has been solved. The reason for the problem is that hive doesn't create the source link using the ticket in the DS configuration file. I set the ticket in the DS to:

However, the correct setting of the Principal value at the time of creation of the HIVE source should be consistent with the Principal value of the source host, otherwise it will fail:


M64Py "Failed to load dynlib/dll"

Hello, I'm using M64Py version 0.2.5. I installed the plugin, but it doesn't seem to show up in the input drop down list. I checked the log viewer, and noticed this error message related to it.
Frontend: ERROR: failed to load plugin C:\Program Files (x86)\M64Py\mupen64plus-input-gca.dll: Failed to load dynlib/dll 'C:\Program Files (x86)\M64Py\mupen64plus-input-gca.dll'. Most probably this dynlib/dll was not found when the application was frozen.
This seems to be the case for both the compact and regular version of the plugin. This very well may be an issue on my end, but any help would be appreciated.

This plugin is 64-bit, while m64py is 32-bit. It simply won't run with it.
You'll need to use a launcher/frontend that is running 64-bit mupen64plus.
https://github.com/GhostlyDark/EMG
https://github.com/Rosalie241/RMG

Thanks for the response! I switched to simple64 and it worked great.


Avoid using function declarations in conditionals.

The use of function declarations here is causing the webppl tests to fail on older versions of node (inc. v0.12) and phantomjs.
We could consider dropping support for older versions of node (from adnn and webppl), but the phantomjs failure happens with the latest version, so making this change seems like the easiest way to proceed.

Thanks for catching this--I'm perfectly fine with making this change.


if statement have been removed and assertion messages have been appended

Appending the below lines
System.out.println("Stdout of ${commandRepr}: \n");
System.out.println(stdout);
System.err.println("Stderr of ${commandRepr}: \n");
System.err.println(IOUtils.toString(process.getErrorStream(), StandardCharsets.UTF_8));
to a assertion message for the issue #757.

Okay first unexpected obstacle... can you the CI error message at the build (link)? Log in with GitHub.
That happens since CircleCI doesn't pass secret (env vars) to builds coming from forks like yours.
To fix, patch scripts/enforce-change-notes-updated-on-pr-to-master: in line 10, require not only CI_PULL_REQUEST to be set, but also GITHUB_TOKEN (to skip the script execution on PRs from forks)

CI_PULL_REQUEST

@PawelLipski i have generate the personal access token and have look onto the CI error message which is regarding pre-build check but not getting idea of scripts/enforce-change-notes-updated-on-pr-to-master: in line 10,  and CI_PULL_REQUEST

Just replace:
if [[ ${CI_PULL_REQUEST-} ]]; then

with
if [[ ${CI_PULL_REQUEST-} && ${GITHUB_TOKEN-} ]]; then

I did the changes

Okay another failing check... pls add the following to scripts/enforce-version-bump, line 8 (right before last_tag=$(git describe --tags --abbrev=0)):
if ! [[ $(git tag) ]]; then exit 0; fi

Okay another fix to introduce, in scripts/prohibit-direct-merges-to-master, right before current_branch=$(git branch --show-current):
if [[ ${CI-} ]] && ! [[ ${GITHUB_TOKEN-} ]]; then exit 0; fi

Aaand more fixes, this time in buildSrc/src/main/kotlin/com/virtuslab/gitmachete/buildsrc/VersionFromGit.kt:
Instead of
    val lastTag = git.tag.list().sortedBy { it.dateTime }.last()
    val commitsSinceLastTag =
      git.log(mapOf("includes" to listOf("HEAD"), "excludes" to listOf(lastTag.fullName)))

put:
    val tags = git.tag.list().sortedBy { it.dateTime }
    val commitsSinceLastTag = if (tags.isEmpty()) {
      git.log(mapOf("includes" to listOf("HEAD")))
    } else {
      git.log(mapOf("includes" to listOf("HEAD"), "excludes" to listOf(tags.last().fullName)))
    }

Okay we've passed through the scripted checks 😅 now time for the formatting! Pls set up the environment as in https://github.com/VirtusLab/git-machete-intellij-plugin/blob/master/CONTRIBUTING.md#prerequisites, and then build as per https://github.com/VirtusLab/git-machete-intellij-plugin/blob/master/CONTRIBUTING.md#build. The build process will include spotlessApply Gradle task, which formats the code. Pls report any unexpected errors you might encounter in the process

Yes we have passed it and i did actually learned about by looking what kind of changes you ask to do , i love it :) , sure let me do formatting now

Yes we have passed it and i did actually learned about by looking what kind of changes you ask to do

Gr8 🎉 that's actually a first PR from fork (and not from this original repo) in a long time, it turned out that certain assumptions we've got in those scripts aren't correct for PRs from forks (git tags might be missing + CI secrets aren't available)

@PawelLipski  I have followed the steps of prerequisites successfully but when I am trying to build by --info , Local(non -CI) and -Xmx i am getting this error :

org.gradle.api.InvalidUserDataException: Invalid TOML catalog definition:

Problem: In version catalog libs, parsing failed with 1 error.
Reason: At line 1, column 1: Unexpected '.', expected a-z, A-Z, 0-9, ', ", a table key, a newline, or end-of-input.
Possible solution: Fix the TOML file according to the syntax described at https://toml.io.
Please refer to https://docs.gradle.org/7.5.1/userguide/version_catalog_problems.html#toml_syntax_error for more details about this problem.
←[33m> ←[39mInvalid TOML catalog definition:

Problem: In version catalog libs, parsing failed with 1 error.
Reason: At line 1, column 1: Unexpected '.', expected a-z, A-Z, 0-9, ', ", a table key, a newline, or end-of-input.
Possible solution: Fix the TOML file according to the syntax described at https://toml.io.
Please refer to https://docs.gradle.org/7.5.1/userguide/version_catalog_problems.html#toml_syntax_error for more details about this problem.

Try:
←[33m> ←[39mRun with ←[1m--stacktrace←[m option to get the stack trace.
←[33m> ←[39mRun with ←[1m--info←[m or ←[1m--debug←[m option to get more log output.
←[33m> ←[39mRun with ←[1m--scan←[m to get full insights.

I have Checked it and came across it might be related to gradle version mismatch with gradle-wrapper-properties and distributionUrl but even after fixing it , it is showing the same error . Any suggestions ?

Hmmm actually... are you running on Windows? 🤔 also, can you provide the screenshot of the entire terminal window with the error message?

If so, I think a quick workaround might be to copy gradle/libs.versions.toml into buildSrc/gradle/libs.versions.toml. The latter is a symlink... and there might be a problem with a proper support on Windows :/

@PawelLipski sorry for the late reply i did what you ask and i rerun the build but getting this error

Huh another known error, already reported to https://github.com/JetBrains/gradle-grammar-kit-plugin/issues/97... pls upvote
In the meantime,  pls try the points from https://github.com/VirtusLab/git-machete-intellij-plugin/blob/master/CONTRIBUTING.md#build -> In case of spurious..., lmk if any helped

Or even before that, pls pass an extra to gradle commands:
./gradlew -PoverrideBuildTarget=2022.2.3 build

@PawelLipski  I tried the command you shared and I am getting these errors and exceptions : 🤔

And below is the test report for the backend/impl

Hmmm okay, looks like a Windows-specific failure, unfortunately :/ anyway, could you push the code to GitHub? let's see what are the failures in the CI, then we'll think of the subsequent steps

Aaaand pls note that adding the stdout/stderr of the executed command would be very useful to debug the failure you experience :) you might need to fall back to string concatenation tho, string interpolations seem not to work in your case for some reason 🤔

Hi @PawelLipski I just want  update you that I am pretty much working on installation of Linux so I can contribute on this issue much better  :) so if you want me to know something else or anything i can make changes regarding it you can tell me . 🚀

Okay! on Linux and Mac this entire project should build without such issues 😅 anyway, we aim to make the project compilable on Windows... and in fact, the major obstacle is exactly the problem you've encountered:

and the task #757 should be a major step towards getting the build on Windows fixed

@PawelLipski I was setting up the code base in linux now but getting this error

and do i need java 17 or java 11 is fine to test the code i will write ?

setting up the code base in linux now but getting this error

Hmmm okay... it looks like again the problem with symlink, which was understandable under Windows, but not under Linux 🤔 did you make a fresh clone of the project onto this Linux?
Pls show me the results of ls -l gradle/ and ls -l buildSrc/gradle/

./gradlew: permission denied

Hmm amirite that you're using a Linux VM within Windows, and sharing the project directory from Windows host into Linux VM? 🤔 if so, pls clone the project anew onto Linux VM directly. Does gradlew have permissions to execute? See ls -l gradlew

and do i need java 17 or java 11 is fine to test the code i will write ?

Ideally, just having any Java (8 or higher) on the system is enough. Gradle should download the required JDK version on its own if missing (see https://docs.gradle.org/current/userguide/toolchains.html)

@PawelLipski Thank you for admiring me :) , i just dual boot my pc in a way that i can access the drive of my window's drive data and trying my best .
I took fresh clone this is the error i am getting now .

Hmm are you currently on your own branch ☝🏻 the problem you've got with .last() call is already solved on this PR :) see buildSrc/src/main/kotlin/com/virtuslab/gitmachete/buildsrc/VersionFromGit.kt

Hey @ishu-thakur... need any further help here?

@PawelLipski  i need some confirmation that is this error because this branch i am using is the sub branch of the fork branch ?

@PawelLipski i need some confirmation that is this error because this branch i am using is the sub branch of the fork branch ?

Hmmm for clarity... is this error happening on Windows or on Linux? 🤔
Also, first thing to do... pls replace the string interpolations in testCommon/src/testFixtures/java/com/virtuslab/gitmachete/testcommon/TestProcessUtils.java:29 and around, with regular +... for some reason, string interpolation (https://github.com/antkorwin/better-strings) doesn't seem to work in your setup (?)

@PawelLipski yes this error happening on linux .
and yes after removing the "+" it is giving the same error.

Okay pls include the log after changing to +s... and we'll try to point what specific process execution fails and why 🤔

Gr8, we know now that the failing place is the execution of testCommon/src/testFixtures/resources/setup-for-overridden-fork-point.sh... let's now check which exact place in the script fails.
Modify testCommon/src/testFixtures/resources/setup-for-overridden-fork-point.sh: to line 3 (with set), add -x option. See https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html for details

Also... pls push your current version of codebase to the branch 🤔


Implement live browsing for seekable backing streams

It would be extremely useful to be able to live browse tar files without extracting them - like a virtual FS.

IIRC this was done historically but got very difficult to manage after more features were added. That being said I don't think it'd be impossible, so I'd be willing to see a PR to game it out!

Ah, I see. Thanks! I'm using embedded tar files (i.e. in a byte string/include_bytes!) to store game assets.


queryKey doesn't support symbol

Describe the bug
let url = '/api'
const [symbol,setSymbol] = useState(Symbol())

const fetchFn = ()=> fetch('https://jsonplaceholder.typicode.com/todos/1')
      .then(response => response.json())
      .then(json => console.log(json))

const queryKey = [url,symbol]
useQuery(queryKey,fetchFn) // when symbol changed, it doesn't refetch

<button onClick={()=>setSymbol(Symbol())}>submit</button>

Your minimal, reproducible example
https://stackblitz.com/edit/react-ts-edd29f?file=App.tsx
Steps to reproduce
stackbliz
Expected behavior
..
How often does this bug happen?
None
Screenshots or Videos
No response
Platform
chrome
TanStack Query version
latest
TypeScript version
No response
Additional context
No response

thanks, but Symbol().toString is not ok,


Cannot find RANCHER_STATE partition on Hyper-V

It started just fine. I can also get on to the network and see /dev/sda. I was able to format the /dev/sda partition and give it the RANCHER_STATE label.
The problem is it fails to detect RANCHER_STATE partition after reboot.

This problem is going to be the same as VMware SCSI I'm guessing.  HyperV needs a kernel model loaded but we run udev to late.  RancherOS is supposed reorder this so that we launch udev before mounting state.  This sound be released this week.


force external encoding to UTF-8 for tests

This is needed to make the test suite succeed in environment where UTF-8 is not the default (like Debian package building machines)

forget about it, it is not needed. Sorry for the noise.


messageHeaderAsHtml: Modify topic header to include date.

Many times when people are scrolling through messages they need to see
what date it is. This modification is made for this use-case. Users can
simply see the header to determine the date a particular message was sent.
This is implemented using some basic css and js. When writing the css
selector for the header of the topic, there was an issue arising where the
sticky header (because a small part of it gets cut out) was showing
misalignment. This is the reason why margin-top: 0.2em was added to
.topic-header selector.
Tests have been conducted, and behaviour is checked for both Android and
iOS, light and dark mode.
Fixes #1336

Hi @ishammahajan -- thanks for this contribution!

First quick bit of feedback: for a change like this one that's aimed at the UI, please include screenshots in the PR. They can help a lot in making it quicker for people to review.

For this design overall, I'm not yet convinced. In particular, these won't show up at all when narrowed to a single topic, or to a PM (1:1 or group) conversation. So it doesn't really fix #1336 -- we need something that applies to those too.

Some specific bits that would be important to fix if we did go with a version of this:

Should say "Today" for today; in general, should have the same logic as the date dividers.
It isn't aligned with the topic name.
Touching a topic header (to narrow to the topic) no longer works.

Closing this PR in favor of continuing the overall design discussion in #1336 . Thanks again!


Unable to reproduce MTEB leaderboard results on TRECCOVID using Snowflake/snowflake-arctic-embed-m-v1.5

I am using this model Snowflake/snowflake-arctic-embed-m-v1.5 to reproduce the MTEB leaderboard results on the TRECCOVID dataset. Based on the leaderboard, the Normalized Discounted Cumulative Gain @ 10 (nDCG@10) for TRECCOVID should be 84.61. I am getting 39.39.
If you cannot see the model Snowflake/snowflake-arctic-embed-m-v1.5 easily, you should set the task to “Retrieval” only from the leaderboard and the model should be in position 35 (as of today) from the top.
Below is how I tried to reproduce the results
import mteb
from sentence_transformers import SentenceTransformer

model_name = "Snowflake/snowflake-arctic-embed-m-v1.5"

model = SentenceTransformer(model_name, trust_remote_code=True)
tasks = mteb.get_tasks(tasks=["TRECCOVID"])
evaluation = mteb.MTEB(tasks=tasks)
results = evaluation.run(model, output_folder=f"results/{model_name}")
print(results[0].scores['test'][0]['ndcg_at_10'])

Expected output: 0.8641
Actual output: 0.3939
Model details: "name": "Snowflake/snowflake-arctic-embed-m-v1.5", "revision": "3b5a16eaf17e47bd997da998988dce5877a57092"
System specifications:
MacOS Sonoma 14.6.1 (23G93)
python 3.12.5
mteb 1.14.20

Thanks for reporting this @AndreaSottana.
It might be worth making an issue here as the score is reported by the model authors.
However, please do link this issue as well.
@Muennighoff we have no good practice for what to do in these cases, any suggestions?

Great point; I think we should work with the authors to reproduce it and if it cannot be reproduced after significant effort maybe adjust the scores or something though such a large drop looks like a bug maybe in our modeling code.


Test suite fails...

Devuan GNU/Linux Chimaera
main branch

Steps to reproduce
configure, build, make test.
Log
$ ctest --rerun-failed --output-on-failure
Test project /home/eyalroz/src/mine/dylib/build
      Start  1: exemple.exemple_test
 1/10 Test  #1: exemple.exemple_test .............***Failed    0.00 sec
Note: Google Test filter = exemple.exemple_test
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from exemple
[ RUN      ] exemple.exemple_test
/home/eyalroz/src/mine/dylib/tests/tests.cpp:50: Failure
Expected equality of these values:
  true
  false
[  FAILED  ] exemple.exemple_test (0 ms)
[----------] 1 test from exemple (0 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (0 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] exemple.exemple_test

 1 FAILED TEST

      Start  3: multiple_handles.basic_test
 2/10 Test  #3: multiple_handles.basic_test ......***Failed    0.00 sec
Note: Google Test filter = multiple_handles.basic_test
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from multiple_handles
[ RUN      ] multiple_handles.basic_test
unknown file: Failure
C++ exception with description "dylib: error while loading dynamic library "./dynamic_lib.so"
./dynamic_lib.so: cannot open shared object file: No such file or directory" thrown in the test body.
[  FAILED  ] multiple_handles.basic_test (0 ms)
[----------] 1 test from multiple_handles (0 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (0 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] multiple_handles.basic_test

 1 FAILED TEST

      Start  6: get_function.bad_symbol
 3/10 Test  #6: get_function.bad_symbol ..........***Failed    0.00 sec
Note: Google Test filter = get_function.bad_symbol
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from get_function
[ RUN      ] get_function.bad_symbol
unknown file: Failure
C++ exception with description "dylib: error while loading dynamic library "./dynamic_lib.so"
./dynamic_lib.so: cannot open shared object file: No such file or directory" thrown in the test body.
[  FAILED  ] get_function.bad_symbol (0 ms)
[----------] 1 test from get_function (0 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (0 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] get_function.bad_symbol

 1 FAILED TEST

      Start  8: get_variable.bad_symbol
 4/10 Test  #8: get_variable.bad_symbol ..........***Failed    0.00 sec
Note: Google Test filter = get_variable.bad_symbol
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from get_variable
[ RUN      ] get_variable.bad_symbol
unknown file: Failure
C++ exception with description "dylib: error while loading dynamic library "./dynamic_lib.so"
./dynamic_lib.so: cannot open shared object file: No such file or directory" thrown in the test body.
[  FAILED  ] get_variable.bad_symbol (0 ms)
[----------] 1 test from get_variable (0 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (0 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] get_variable.bad_symbol

 1 FAILED TEST

      Start  9: get_variable.alter_variables
 5/10 Test  #9: get_variable.alter_variables .....***Failed    0.00 sec
Note: Google Test filter = get_variable.alter_variables
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from get_variable
[ RUN      ] get_variable.alter_variables
/home/eyalroz/src/mine/dylib/tests/tests.cpp:151: Failure
Expected equality of these values:
  true
  false
[  FAILED  ] get_variable.alter_variables (0 ms)
[----------] 1 test from get_variable (0 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (0 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] get_variable.alter_variables

 1 FAILED TEST

      Start 10: bad_arguments.null_pointer
 6/10 Test #10: bad_arguments.null_pointer .......***Failed    0.00 sec
Note: Google Test filter = bad_arguments.null_pointer
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from bad_arguments
[ RUN      ] bad_arguments.null_pointer
unknown file: Failure
C++ exception with description "dylib: error while loading dynamic library "./dynamic_lib.so"
./dynamic_lib.so: cannot open shared object file: No such file or directory" thrown in the test body.
[  FAILED  ] bad_arguments.null_pointer (0 ms)
[----------] 1 test from bad_arguments (0 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (0 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] bad_arguments.null_pointer

 1 FAILED TEST

      Start 12: os_detector.basic_test
 7/10 Test #12: os_detector.basic_test ...........***Failed    0.00 sec
Note: Google Test filter = os_detector.basic_test
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from os_detector
[ RUN      ] os_detector.basic_test
/home/eyalroz/src/mine/dylib/tests/tests.cpp:221: Failure
Expected equality of these values:
  true
  false
[  FAILED  ] os_detector.basic_test (0 ms)
[----------] 1 test from os_detector (0 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (0 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] os_detector.basic_test

 1 FAILED TEST

      Start 14: has_symbol.basic_test
 8/10 Test #14: has_symbol.basic_test ............***Failed    0.00 sec
Note: Google Test filter = has_symbol.basic_test
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from has_symbol
[ RUN      ] has_symbol.basic_test
unknown file: Failure
C++ exception with description "dylib: error while loading dynamic library "./dynamic_lib.so"
./dynamic_lib.so: cannot open shared object file: No such file or directory" thrown in the test body.
[  FAILED  ] has_symbol.basic_test (0 ms)
[----------] 1 test from has_symbol (0 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (0 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] has_symbol.basic_test

 1 FAILED TEST

      Start 15: operator_bool.basic_test
 9/10 Test #15: operator_bool.basic_test .........***Failed    0.00 sec
Note: Google Test filter = operator_bool.basic_test
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from operator_bool
[ RUN      ] operator_bool.basic_test
unknown file: Failure
C++ exception with description "dylib: error while loading dynamic library "./dynamic_lib.so"
./dynamic_lib.so: cannot open shared object file: No such file or directory" thrown in the test body.
[  FAILED  ] operator_bool.basic_test (0 ms)
[----------] 1 test from operator_bool (0 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (0 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] operator_bool.basic_test

 1 FAILED TEST

      Start 16: handle_management.basic_test
10/10 Test #16: handle_management.basic_test .....***Failed    0.00 sec
Note: Google Test filter = handle_management.basic_test
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from handle_management
[ RUN      ] handle_management.basic_test
unknown file: Failure
C++ exception with description "dylib: error while loading dynamic library "./dynamic_lib.so"
./dynamic_lib.so: cannot open shared object file: No such file or directory" thrown in the test body.
[  FAILED  ] handle_management.basic_test (0 ms)
[----------] 1 test from handle_management (0 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (0 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] handle_management.basic_test

 1 FAILED TEST

0% tests passed, 10 tests failed out of 10

Total Test time (real) =   0.03 sec

The following tests FAILED:
	  1 - exemple.exemple_test (Failed)
	  3 - multiple_handles.basic_test (Failed)
	  6 - get_function.bad_symbol (Failed)
	  8 - get_variable.bad_symbol (Failed)
	  9 - get_variable.alter_variables (Failed)
	 10 - bad_arguments.null_pointer (Failed)
	 12 - os_detector.basic_test (Failed)
	 14 - has_symbol.basic_test (Failed)
	 15 - operator_bool.basic_test (Failed)
	 16 - handle_management.basic_test (Failed)

Hello,
C++ exception with description "dylib: error while loading dynamic library "./dynamic_lib.so"
./dynamic_lib.so: cannot open shared object file: No such file or directory" thrown in the test body.

I think the test suite is failing because you are not in the same directory as the test binary and the dynamic library.
The test suite is looking at ./dynamic_lib.so

Also, you must not build into the source directory (${PROJECT_SOURCE_DIR}), only under ${PROJECT_BINARY_DIR}.

Could you provide the exact commands you ran because writing "configure, build, make test." when there is no configure script on the project and we don't know how you actually built the project isn't helping troubleshoot the issue you're facing

ccmake -S /path/to/src/dir -B /path/to/build/dir
cmake --build /path/to/build/dir
make -C /path/to/build/dir test

I just made your requested changes on https://github.com/martin-olivier/dylib/pull/24
Feel free to make a review on those changes, after what i will merge them


Improve velph-phono3py

Codecov Report
Attention: Patch coverage is 83.78378% with 6 lines in your changes missing coverage. Please review.

Project coverage is 73.21%. Comparing base (79725c8) to head (3159f2e).
Report is 72 commits behind head on develop.

Files with missing lines
Patch %
Lines

src/phelel/velph/cli/init/init.py
42.85%
4 Missing :warning:

src/phelel/velph/cli/phono3py/__init__.py
66.66%
1 Missing :warning:

src/phelel/velph/cli/phono3py/init.py
83.33%
1 Missing :warning:

Additional details and impacted files
@@             Coverage Diff             @@
##           develop      #41      +/-   ##
===========================================
- Coverage    73.42%   73.21%   -0.21%
===========================================
  Files           74       77       +3
  Lines         5223     5500     +277
===========================================
+ Hits          3835     4027     +192
- Misses        1388     1473      +85

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


fixing unit conversion for timeseries

[x] closing https://github.com/Deltares/FloodAdapt/issues/205
[x] closing https://github.com/Deltares/FloodAdapt/issues/126

I decided to not save time series files in metric units but instead keep everything in the backend in gui units and only convert units in the sfincs adapter


很棒又簡易

可惜手機上無法創建是否請前輩可以教授，謝謝您。

I am closing this issue.
Please us English as the main language as this keeps our repositories better readable and allows for easy translation to your native language.
It is perfectly fine to use Google translate or any other translation tool.
我正在關閉這個問題。
請使用英語作為主要語言，因為這可以使我們的儲存庫具有更好的可讀性，並且可以輕鬆翻譯為您的母語。
使用Google翻譯或任何其他翻譯工具是完全可以的。

Sorry, I have been busy with my own affairs recently and forgot to come back to read your reply. I will ask questions in English in the future.


[SR-16120] Navbar dropdown chevron icon not showing

Previous ID
SR-16120

Radar
None

Original Reporter
@sofiaromorales

Type
Bug

Environment
Safari 15.3
Testing locally using `swift-docc-render` repo with HEAD in commit id 6471e29

Additional Detail from JIRA

Votes
0

Component/s
Swift-DocC-Render

Labels
Bug

Assignee
@sofiaromorales

Priority
Medium

md5: 538d9691ff42c6199dc4eb4d61b32ed0

Issue Description:
In certain viewports, and zoom levels in Safari, when in collapse range the chevron icon from the dropdown menu is disappearing. The element still exists and it can be clicked but the `:before` and `:after` elements aren't visible.
Steps to reproduce:

Open `http://localhost:8080/documentation/slothcreator\`
In Safari select Develop > Open Responsive Design Mode
Select viewport 800 x 700 resolution 1x
Zoom out to 85% (clicking once `⌘ -`)

I believe this was addressed by #179


Events emitting is broken in Angular 10 (and 9 as I see)

Environment
Provide version numbers for the following components (information can be retrieved by running tns info in your project folder or by inspecting the package.json of the project):
tns info
✔ Getting NativeScript components versions information...
✔ Component nativescript has 7.0.8 version and is up to date.
✔ Component @nativescript/core has 7.0.3 version and is up to date.
✔ Component @nativescript/ios has 7.0.0 version and is up to date.
✖ Component @nativescript/android is not installed.
package.json
{
  "name": "@nativescript/template-hello-world-ng",
  "main": "main.js",
  "version": "7.0.2",
  "author": "NativeScript Team<EMAIL_ADDRESS>  "description": "NativeScript Application",
  "license": "SEE LICENSE IN <your-license-filename>",
  "publishConfig": {
    "access": "public"
  },
  "keywords": [
    "nativescript",
    "mobile",
    "angular",
    "{N}",
    "template"
  ],
  "repository": "<fill-your-repository-here>",
  "bugs": {
    "url": "https://github.com/NativeScript/NativeScript/issues"
  },
  "scripts": {
    "ngcc": "ngcc --properties es2015 module main --first-only",
    "postinstall": "npm run ngcc"
  },
  "dependencies": {
    "@angular/animations": "~10.1.0",
    "@angular/common": "~10.1.0",
    "@angular/compiler": "~10.1.0",
    "@angular/core": "~10.1.0",
    "@angular/forms": "~10.1.0",
    "@angular/platform-browser": "~10.1.0",
    "@angular/platform-browser-dynamic": "~10.1.0",
    "@angular/router": "~10.1.0",
    "@nativescript/angular": "~10.1.0",
    "@nativescript/core": "~7.0.0",
    "@nativescript/theme": "~2.3.0",
    "reflect-metadata": "~0.1.12",
    "rxjs": "^6.6.0",
    "zone.js": "~0.11.1"
  },
  "devDependencies": {
    "@angular/compiler-cli": "~10.1.0",
    "@nativescript/ios": "7.0.0",
    "@nativescript/types": "~7.0.0",
    "@nativescript/webpack": "~3.0.0",
    "@ngtools/webpack": "~10.1.0",
    "typescript": "~3.9.0"
  },
  "private": "true",
  "readme": "NativeScript Application"
}

Describe the bug
After any navigation events like focus or blur stop emitting.
To Reproduce
Run my sample project. Tap between text fields. Navigate to next page. Tab between text fields again. See for the logs.
(All the instruction you can also find in the ReadMe.md)
Expected behavior
All events are emitted regardless of my navigation
Sample project
https://github.com/SergeyMell/nativescript-ivy-issue
Additional context
I think the problem is related to ivy rendered. On Angular9 it can be fixed either by disabling Ivy or removing wrapper around page-router-outlet

@SergeyMell This should be fixed with 10.1.4. Can you try it?

@edusperoni Actually retested on 10.1.6 and can confirm that it works correctly now


Combining command options does not work

Bug Description
Hey,
I'm trying to create a reversible sequential migration file. By reading the --help menu I thought that executing the the following command:  sqlx migrate add -rs post would create two files, 0001_post.up.sql and 0001_post.down.sql.
But it only creates one file, 0001_post.up.sql.
Using just the -r flag works but it does not create a sequential file.
I don't know if this is the expected behavior or a bug.
Thanks in advance!
Minimal Reproduction
Execute:
sqlx migrate add -rs post
Info

SQLx version: sqlx-cli 0.7.4
SQLx features enabled: sqlx = { version = "0.7", features = [ "postgres", "uuid", "runtime-tokio", "tls-native-tls" ] }
Database server and version: PostgreSQL 16.3
Operating system: Linux
rustc --version: rustc 1.76.0

This would appear to be a bug, yes.

I tried writing a testcase for this but failed to reproduce the results.
Could you re-check your sqlx-cli version?

Sure, here is a screenshot of my current version and problem

What does your directory look like? Maybe there is a combination of additions/removals that I am missing.
Could you try to also reproduce this in a fresh directory? (Thus ruling out that there is a platform/.. issue)

Hey, sorry for the delay.
It works fine in a fresh directory. And I think I found the issue.
I have a non-reversible migration in my migrations directory. After removing it, the -rs flag works.
I thought having a combination of reversible and non-reversible migration files was possible.

@abonander so that I can provide the correct fix as a PR. Should the behavior be:

create a down migration for all in the current directory
create down only for the added migration (mixing up+down)


Add 'forceIp' to force use IP from "IpAddressess" for containers (for marathon 1.3)

Add boolean "forceIp" parameter for containers that allows use ip (Task.effectiveIp) from "ipAddressess" without conditions.
It resolves issue when using docker container with custom network:
Marathon try to get incorrect "agentInfo.host" for ip (host of container's custom network)  instead of IpAddressess

@meichstedt @jdef could you please review it?

Hi @ikuzniatsou ! Could you open up a ticket describing the motive and proposal for this change? Please include the app definition and any information about the custom network that you are using.
BTW - I once worked around this myself when I launched containers using MacVLAN... set "ipAddress": {}. It was a work-around that worked, but, I think enriching the logic so that Marathon is more aware of the Docker container network specified is the right way to go.

Hi @timcharper @jdef  !
Sorry, maybe I didn't  quite clearly describe situation.
For now 1.3 is tested and worked properly in our environment, migration to 1.4\1.5  is planned but not now.
So, it was look like the best way was a quick fix for 1.3 only.
About issue:  we have a host-machine with it's own IP.
There is a bunch of docker containers ( mesos-agents ) started on it. Each of these containers (agents) have it's own IP as required in preconfigured docker network policy.  Agents are registered in mesos with it's container-IP.
It's work perfectly except health-check in marathon 1.3.
( Yes, Health-checks works with 1.5, but as I said above, we can't migrate now...)
Sorry, I can't remember exactly reason why is this so, but marathon 1.3 does not receive runSpec.ipAddress variable in this case. So, as provied in health-check logic, it does not use IP from ipAddresses variable (with correct IP of container (agent), but get IP of host-machine.
I hope, it's more clearly now.


Standardized the composer file

Standardize composer file
Ignore commit of lock file
Unlock the version of nikic/php-parser

Ignore commit of lock file
Unlock the version of nikic/php-parser

Thank you for your contribution. However, the current practice of pinning the version of nikic/php-parser and committing the lock file in the repository is done intentionally for specific reasons.
Pinning the version helps us ensure that all developers and environments are using the exact same version of the dependency, which can help prevent bugs that might occur due to differences in dependency versions.
Including the lock file in the repository ensures that everyone installs the exact same dependencies, which is important for achieving reproducible builds and for ensuring that our application behaves the same way in all environments.
We appreciate your effort, but we would need compelling reasons to change these practices. Could you please explain the benefits of the changes you proposed?

@kayw-geek (Kai) Thanks for contributing. one more thing to clarify. we are using conventional commits on this project. so please read the doc ( https://www.conventionalcommits.org/en/v1.0.0/ )  to see how to write the commit message. if you have Node.JS installed, please run pnpm install to enable Husky. there would be a pre-commit lint to ensure the commit message is correct.

@liby I don't know if we can accept the change range of the upstream package.
Can it be changed to "nikic/php-parser": "~4.17.1" or "nikic/php-parser": "~4.17" without limiting the patch or minor version?


[CMT-530-836] fix: update newsletter layout

Description
Fixes #818
before:

after: (remove unused box + used same layout as other pages)

idk why the PR broke the images, here are the before/after images again:
before:

after:


Remove the usage of Validate.isTrue method to avoid unnecessary construction of string

Description
Avoid the usage of method Validate.isTrue.

coverage: 44.522% (+0.03%) from 44.492% when pulling 8ecf6f8953689ed49f0cec70991db5a316424917 on beyyes/imporve_statistic_judgement into 0fa2300e5825aabd1c3716ef0e48ad6e66b3311a on master.


Orbital Blues Character Sheet V1_2

Changes / Comments
Added functional Orbital Blues character sheet
Roll20 Requests
Comments are very helpful for reviewing the code changes. Please answer the relevant questions below in your comment.

[X] Does the pull request title have the sheet name(s)? Include each sheet name.
Sheet Name: Orbital Blues Character Sheet.
[ ] Is this a bug fix?
[ ] Does this add functional enhancements (new features or extending existing features) ?
[ ] Does this add or change functional aesthetics (such as layout or color scheme) ?
[ ] If changing or removing attributes, what steps have you taken, if any, to preserve player data ?
[X] If this is a new sheet, did you follow [Building Character Sheets standards]
(https://wiki.roll20.net/Building_Character_Sheets#Roll20_Character_Sheets_Repository) ?
Yes.

If you do not know English. Please leave a comment in your native language.

Character Sheet Info Roll20 Internal Use only.


attrs = self._cert.subject.get_attributes_for_oid

in the version 10.3.0
there is errors : /Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/mitmproxy/certs.py:146: UserWarning: Country names should be two characters, but the attribute is 0 characters in length.
attrs = self._cert.subject.get_attributes_for_oid(x509.NameOID.COMMON_NAME)
/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/mitmproxy/certs.py:153: UserWarning: Country names should be two characters, but the attribute is 0 characters in length.
attrs = self._cert.subject.get_attributes_for_oid(

Can you please provide a reproducer?


feat(RHTAPREL-818): add new releaseNotes keys

This commit adds the releaseNotes.product_name and releaseNotes.product_version keys. They are both required, so check-data-keys was modified to check for them. Also, they must come from the ReleasePlanAdmission, so collect-data was modified to ensure they are not present in the Release or ReleasePlan.

/test release-pipelines-e2e-suite

/test release-pipelines-e2e-suite

/test release-pipelines-e2e-suite

/test release-pipelines-e2e-suite

/test release-pipelines-e2e-suite

/test release-pipelines-e2e-suite

/test release-pipelines-e2e-suite

/test release-pipelines-e2e-suite


Error if "member" entry does not exist.

The module fails to add a user to a group if the user does not exist.
The module fails to indicate that it has failed and instead issues a notice of change.
The notice of change is not true stating:
members changed 'user1,user2,user3 to ['user1', 'user2', 'user3', 'notexist']

Where notexist is a username that does not exist.
Using a check for the username like bash/gnu id $user would ensure the user exists or fail before attempting to manage the group. Otherwise, I'm not sure this module is working as expected.

@cheyngoodman Thanks for the bug report. We'll try to get a reproducer in place and go from there.

@cheyngoodman Can you please provide the output of a puppet run when using the --debug option?
Make sure to scrub any sensitive information! We're just looking for the gpasswd related items.

I used CentOS 7 in Vagrant to reproduce the issue:
Vagrant.configure('2') do |config|
  config.vm.box = 'centos/7'
  config.vm.provision 'shell',
                      path: 'provision.sh'
end

Provisioned with this provision.sh script:
#!/bin/bash
. /etc/os-release
rpm_url="https://yum.puppet.com/puppet-release-el-${VERSION_ID}.noarch.rpm"
rpm -q puppet-release \
  || yum -y install "$rpm_url"
yum -y install puppet-agent
puppet module install gpasswd
puppet apply /vagrant/manifest.pp

Applying this puppet code manifest.pp:
user { 'real': ensure => present }
user { 'fake': ensure => absent }
group { 'real': members => ['real','fake'] }

Which will produce this output on first run:
Notice: Compiled catalog for localhost.localdomain in environment production in 0.01 seconds
Notice: /Stage[main]/Main/Group[real]/members: members changed '' to ['fake', 'real']
Notice: Applied catalog in 0.06 seconds

And outputs this every next run:
Notice: Compiled catalog for localhost.localdomain in environment production in 0.02 seconds
Notice: /Stage[main]/Main/Group[real]/members: members changed 'real' to ['fake', 'real']
Notice: Applied catalog in 0.04 seconds

Since the module does not actually add the "fake" user, I believe this to be a bug.
The complete debug output is below:

Debug: Runtime environment: puppet_version=6.11.1, ruby_version=2.5.7, run_mode=user, default_encoding=UTF-8
Debug: Loading external facts from /opt/puppetlabs/puppet/cache/facts.d
Debug: Facter: loading external fact directories from config file
Debug: Facter: fact "facterversion" has resolved to "3.14.6".
Debug: Facter: fact "aio_agent_version" has resolved to "6.11.1".
Debug: Facter: searching "/opt/puppetlabs/facter/facts.d" for external facts.
Debug: Facter: skipping external facts for "/etc/facter/facts.d": No such file or directory
Debug: Facter: skipping external facts for "/etc/puppetlabs/facter/facts.d": No such file or directory
Debug: Facter: searching "/opt/puppetlabs/puppet/cache/facts.d" for external facts.
Debug: Facter: no external facts were found.
Debug: Facter: loading all custom facts.
Debug: Facter: loading custom fact directories from config file
Debug: Facter: fact "agent_specified_environment" resolved to null and will not be added.
Debug: Facter: fact "puppetversion" has resolved to "6.11.1".
Debug: Facter: resolving ruby facts.
Debug: Facter: fact "rubyplatform" has resolved to "x86_64-linux".
Debug: Facter: fact "rubysitedir" has resolved to "/opt/puppetlabs/puppet/lib/ruby/site_ruby/2.5.0".
Debug: Facter: fact "rubyversion" has resolved to "2.5.7".
Debug: Facter: fact "ruby" has resolved to {
  platform => "x86_64-linux",
  sitedir => "/opt/puppetlabs/puppet/lib/ruby/site_ruby/2.5.0",
  version => "2.5.7"
}.
Debug: Facter: resolving path facts.
Debug: Facter: fact "path" has resolved to "/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/opt/puppetlabs/bin:/root/bin".
Debug: Facter: resolving EC2 facts.
Debug: Facter: resolving virtualization facts.
Debug: Facter: resolving desktop management interface facts.
Debug: Facter: fact "bios_vendor" has resolved to "innotek GmbH".
Debug: Facter: fact "bios_version" has resolved to "VirtualBox".
Debug: Facter: fact "bios_release_date" has resolved to "12/01/2006".
Debug: Facter: fact "boardmanufacturer" has resolved to "Oracle Corporation".
Debug: Facter: fact "boardproductname" has resolved to "VirtualBox".
Debug: Facter: fact "boardserialnumber" has resolved to "0".
Debug: Facter: fact "productname" has resolved to "VirtualBox".
Debug: Facter: fact "serialnumber" has resolved to "0".
Debug: Facter: fact "uuid" has resolved to "CE7904ED-5A03-4C45-AE2B-D47C3AB1E662".
Debug: Facter: fact "chassistype" has resolved to "Other".
Debug: Facter: fact "manufacturer" has resolved to "innotek GmbH".
Debug: Facter: fact "dmi" has resolved to {
  bios => {
    release_date => "12/01/2006",
    vendor => "innotek GmbH",
    version => "VirtualBox"
  },
  board => {
    manufacturer => "Oracle Corporation",
    product => "VirtualBox",
    serial_number => "0"
  },
  chassis => {
    type => "Other"
  },
  manufacturer => "innotek GmbH",
  product => {
    name => "VirtualBox",
    serial_number => "0",
    uuid => "CE7904ED-5A03-4C45-AE2B-D47C3AB1E662"
  }
}.
Debug: Facter: executing command: /opt/puppetlabs/puppet/bin/virt-what
Debug: Facter: virtualbox
Debug: Facter: completed processing output: closing child pipes.
Debug: Facter: process was signaled with signal 13.
Debug: Facter: searching "/var/lib/dhcp" for dhclient lease files.
Debug: Facter: searching "/var/lib/NetworkManager" for dhclient lease files.
Debug: Facter: reading "/var/lib/NetworkManager/dhclient-5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03-eth0.lease" for dhclient lease azure information.
Debug: Facter: fact "is_virtual" has resolved to true.
Debug: Facter: fact "virtual" has resolved to "virtualbox".
Debug: Facter: EC2 facts are unavailable: not running under an EC2 instance.
Debug: Facter: resolving GCE facts.
Debug: Facter: not running under a GCE instance.
Debug: Facter: resolving augeas facts.
Debug: Facter: executing command: /opt/puppetlabs/puppet/bin/augparse --version
Debug: Facter: augparse 1.12.0 <http://augeas.net/>
Debug: Facter: completed processing output: closing child pipes.
Debug: Facter: process exited with status code 0.
Debug: Facter: fact "augeasversion" has resolved to "1.12.0".
Debug: Facter: fact "augeas" has resolved to {
  version => "1.12.0"
}.
Debug: Facter: resolving hypervisors facts.
Debug: Facter: executing command: /sbin/dmidecode
Debug: Facter: # dmidecode 3.1
Getting SMBIOS data from sysfs.
SMBIOS 2.5 present.
10 structures occupying 450 bytes.
Table at 0x000E1000.

Handle 0x0000, DMI type 0, 20 bytes
BIOS Information
	Vendor: innotek GmbH
	Version: VirtualBox
	Release Date: 12/01/2006
	Address: 0xE0000
	Runtime Size: 128 kB
	ROM Size: 128 kB
	Characteristics:
		ISA is supported
		PCI is supported
		Boot from CD is supported
		Selectable boot is supported
		8042 keyboard services are supported (int 9h)
		CGA/mono video services are supported (int 10h)
		ACPI is supported

Handle 0x0001, DMI type 1, 27 bytes
System Information
	Manufacturer: innotek GmbH
	Product Name: VirtualBox
	Version: 1.2
	Serial Number: 0
	UUID: ce7904ed-5a03-4c45-ae2b-d47c3ab1e662
	Wake-up Type: Power Switch
	SKU Number: Not Specified
	Family: Virtual Machine

Handle 0x0008, DMI type 2, 15 bytes
Base Board Information
	Manufacturer: Oracle Corporation
	Product Name: VirtualBox
	Version: 1.2
	Serial Number: 0
	Asset Tag: Not Specified
	Features:
		Board is a hosting board
	Location In Chassis: Not Specified
	Chassis Handle: 0x0003
	Type: Motherboard
	Contained Object Handles: 0

Handle 0x0003, DMI type 3, 13 bytes
Chassis Information
	Manufacturer: Oracle Corporation
	Type: Other
	Lock: Not Present
	Version: Not Specified
	Serial Number: Not Specified
	Asset Tag: Not Specified
	Boot-up State: Safe
	Power Supply State: Safe
	Thermal State: Safe
	Security Status: None

Handle 0x0007, DMI type 126, 42 bytes
Inactive

Handle 0x0005, DMI type 126, 15 bytes
Inactive

Handle 0x0006, DMI type 126, 28 bytes
Inactive

Handle 0x0002, DMI type 11, 7 bytes
OEM Strings
	String 1: vboxVer_6.0.10
	String 2: vboxRev_132072

Handle 0x0008, DMI type 128, 8 bytes
OEM-specific Type
	Header and Data:
		80 08 08 00 7F 77 35 00

Handle 0xFEFF, DMI type 127, 4 bytes
End Of Table
Debug: Facter: process exited with status code 0.
Debug: Facter: oslevel executable not found
Debug: Facter: zonename executable not found
Debug: Facter: fact "hypervisors" has resolved to {
  virtualbox => {
    revision => "132072",
    version => "6.0.10"
  }
}.
Debug: Facter: resolving kernel facts.
Debug: Facter: fact "kernel" has resolved to "Linux".
Debug: Facter: fact "kernelrelease" has resolved to "3.10.0-957.12.2.el7.x86_64".
Debug: Facter: fact "kernelmajversion" has resolved to "3.10".
Debug: Facter: fact "kernelversion" has resolved to "3.10.0".
Debug: Facter: resolving operating system facts.
Debug: Facter: executing command: lsb_release -a
Debug: Facter: lsb_release was not found on the PATH.
Debug: Facter: fact "osfamily" has resolved to "RedHat".
Debug: Facter: fact "operatingsystemmajrelease" has resolved to "7".
Debug: Facter: fact "operatingsystemrelease" has resolved to "7.7.1908".
Debug: Facter: fact "hardwaremodel" has resolved to "x86_64".
Debug: Facter: fact "architecture" has resolved to "x86_64".
Debug: Facter: fact "operatingsystem" has resolved to "CentOS".
Debug: Facter: fact "selinux" has resolved to true.
Debug: Facter: fact "selinux_enforced" has resolved to true.
Debug: Facter: fact "selinux_current_mode" has resolved to "enforcing".
Debug: Facter: fact "selinux_config_mode" has resolved to "enforcing".
Debug: Facter: fact "selinux_config_policy" has resolved to "targeted".
Debug: Facter: fact "selinux_policyversion" has resolved to "31".
Debug: Facter: fact "os" has resolved to {
  architecture => "x86_64",
  family => "RedHat",
  hardware => "x86_64",
  name => "CentOS",
  release => {
    full => "7.7.1908",
    major => "7",
    minor => "7"
  },
  selinux => {
    config_mode => "enforcing",
    config_policy => "targeted",
    current_mode => "enforcing",
    enabled => true,
    enforced => true,
    policy_version => "31"
  }
}.
Debug: Facter: resolving networking facts.
Debug: Facter: executing command: /sbin/ip route show
Debug: Facter: default via <IP_ADDRESS> dev eth0 proto dhcp metric 100
Debug: Facter: <IP_ADDRESS>/24 dev eth0 proto kernel scope link src <IP_ADDRESS> metric 100
Debug: Facter: process exited with status code 0.

Debug: Facter: using the FQDN returned by gethostname: localhost.localdomain.
Debug: Facter: executing command: /sbin/ip link show
Debug: Facter: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
Debug: Facter: link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
Debug: Facter: 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
Debug: Facter: link/ether 52:54:00:8a:fe:e6 brd ff:ff:ff:ff:ff:ff
Debug: Facter: process exited with status code 0.
Debug: Facter: searching "/run/systemd/netif/leases/" for systemd-networkd DHCP lease files
Debug: Facter: searching "/var/lib/dhclient" for dhclient lease files.
Debug: Facter: searching "/var/lib/dhcp" for dhclient lease files.
Debug: Facter: searching "/var/lib/dhcp3" for dhclient lease files.
Debug: Facter: searching "/var/lib/NetworkManager" for dhclient lease files.
Debug: Facter: reading "/var/lib/NetworkManager/dhclient-5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03-eth0.lease" for dhclient lease information.
Debug: Facter: searching "/var/db" for dhclient lease files.
Debug: Facter: executing command: dhcpcd -U lo
Debug: Facter: dhcpcd was not found on the PATH.
Debug: Facter: executing command: /sbin/ip link show eth0
Debug: Facter: 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
Debug: Facter: link/ether 52:54:00:8a:fe:e6 brd ff:ff:ff:ff:ff:ff
Debug: Facter: process exited with status code 0.
Debug: Facter: executing command: /sbin/ip link show lo
Debug: Facter: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
Debug: Facter: link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
Debug: Facter: process exited with status code 0.
Debug: Facter: fact "ipaddress_eth0" has resolved to "<IP_ADDRESS>".
Debug: Facter: fact "ipaddress" has resolved to "<IP_ADDRESS>".
Debug: Facter: fact "netmask_eth0" has resolved to "<IP_ADDRESS>".
Debug: Facter: fact "netmask" has resolved to "<IP_ADDRESS>".
Debug: Facter: fact "network_eth0" has resolved to "<IP_ADDRESS>".
Debug: Facter: fact "network" has resolved to "<IP_ADDRESS>".
Debug: Facter: fact "ipaddress6_eth0" has resolved to "fe80::5054:ff:fe8a:fee6".
Debug: Facter: fact "scope6_eth0" has resolved to "link".
Debug: Facter: fact "ipaddress6" has resolved to "fe80::5054:ff:fe8a:fee6".
Debug: Facter: fact "scope6" has resolved to "link".
Debug: Facter: fact "netmask6_eth0" has resolved to "ffff:ffff:ffff:ffff::".
Debug: Facter: fact "netmask6" has resolved to "ffff:ffff:ffff:ffff::".
Debug: Facter: fact "network6_eth0" has resolved to "fe80::".
Debug: Facter: fact "network6" has resolved to "fe80::".
Debug: Facter: fact "macaddress_eth0" has resolved to "52:54:00:8a:fe:e6".
Debug: Facter: fact "macaddress" has resolved to "52:54:00:8a:fe:e6".
Debug: Facter: fact "mtu_eth0" has resolved to 1500.
Debug: Facter: fact "ipaddress_lo" has resolved to "<IP_ADDRESS>".
Debug: Facter: fact "netmask_lo" has resolved to "<IP_ADDRESS>".
Debug: Facter: fact "network_lo" has resolved to "<IP_ADDRESS>".
Debug: Facter: fact "ipaddress6_lo" has resolved to "::1".
Debug: Facter: fact "scope6_lo" has resolved to "host".
Debug: Facter: fact "netmask6_lo" has resolved to "ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff".
Debug: Facter: fact "network6_lo" has resolved to "::1".
Debug: Facter: fact "mtu_lo" has resolved to 65536.
Debug: Facter: fact "hostname" has resolved to "localhost".
Debug: Facter: fact "domain" has resolved to "localdomain".
Debug: Facter: fact "fqdn" has resolved to "localhost.localdomain".
Debug: Facter: fact "interfaces" has resolved to "eth0,lo".
Debug: Facter: fact "dhcp_servers" has resolved to {
  eth0 => "<IP_ADDRESS>",
  system => "<IP_ADDRESS>"
}.
Debug: Facter: fact "networking" has resolved to {
  dhcp => "<IP_ADDRESS>",
  domain => "localdomain",
  fqdn => "localhost.localdomain",
  hostname => "localhost",
  interfaces => {
    eth0 => {
      bindings => [
        {
          address => "<IP_ADDRESS>",
          netmask => "<IP_ADDRESS>",
          network => "<IP_ADDRESS>"
        }
      ],
      bindings6 => [
        {
          address => "fe80::5054:ff:fe8a:fee6",
          netmask => "ffff:ffff:ffff:ffff::",
          network => "fe80::"
        }
      ],
      dhcp => "<IP_ADDRESS>",
      ip => "<IP_ADDRESS>",
      ip6 => "fe80::5054:ff:fe8a:fee6",
      mac => "52:54:00:8a:fe:e6",
      mtu => 1500,
      netmask => "<IP_ADDRESS>",
      netmask6 => "ffff:ffff:ffff:ffff::",
      network => "<IP_ADDRESS>",
      network6 => "fe80::",
      scope6 => "link"
    },
    lo => {
      bindings => [
        {
          address => "<IP_ADDRESS>",
          netmask => "<IP_ADDRESS>",
          network => "<IP_ADDRESS>"
        }
      ],
      bindings6 => [
        {
          address => "::1",
          netmask => "ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff",
          network => "::1"
        }
      ],
      ip => "<IP_ADDRESS>",
      ip6 => "::1",
      mtu => 65536,
      netmask => "<IP_ADDRESS>",
      netmask6 => "ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff",
      network => "<IP_ADDRESS>",
      network6 => "::1",
      scope6 => "host"
    }
  },
  ip => "<IP_ADDRESS>",
  ip6 => "fe80::5054:ff:fe8a:fee6",
  mac => "52:54:00:8a:fe:e6",
  mtu => 1500,
  netmask => "<IP_ADDRESS>",
  netmask6 => "ffff:ffff:ffff:ffff::",
  network => "<IP_ADDRESS>",
  network6 => "fe80::",
  primary => "eth0",
  scope6 => "link"
}.
Debug: Facter: resolving disk facts.
Debug: Facter: fact "blockdevice_sda_vendor" has resolved to "ATA".
Debug: Facter: fact "blockdevice_sda_model" has resolved to "VBOX HARDDISK".
Debug: Facter: fact "blockdevice_sda_size" has resolved to<PHONE_NUMBER>0.
Debug: Facter: fact "blockdevices" has resolved to "sda".
Debug: Facter: fact "disks" has resolved to {
  sda => {
    model => "VBOX HARDDISK",
    size => "40.00 GiB",
    size_bytes =><PHONE_NUMBER>0,
    vendor => "ATA"
  }
}.
Debug: Facter: resolving processor facts.
Debug: Facter: executing command: /bin/uname -p
Debug: Facter: x86_64
Debug: Facter: process exited with status code 0.
Debug: Facter: fact "hardwareisa" has resolved to "x86_64".
Debug: Facter: fact "processorcount" has resolved to 1.
Debug: Facter: fact "physicalprocessorcount" has resolved to 1.
Debug: Facter: fact "processor0" has resolved to "Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz".
Debug: Facter: fact "processors" has resolved to {
  count => 1,
  isa => "x86_64",
  models => [
    "Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz"
  ],
  physicalcount => 1
}.
Debug: Facter: resolving uptime facts.
Debug: Facter: fact "uptime_seconds" has resolved to 1817.
Debug: Facter: fact "uptime_hours" has resolved to 0.
Debug: Facter: fact "uptime_days" has resolved to 0.
Debug: Facter: fact "uptime" has resolved to "0:30 hours".
Debug: Facter: fact "system_uptime" has resolved to {
  days => 0,
  hours => 0,
  seconds => 1817,
  uptime => "0:30 hours"
}.
Debug: Facter: resolving ssh facts.
Debug: Facter: ssh_host_dsa_key.pub could not be located.
Debug: Facter: fact "sshrsakey" has resolved to "AAAAB3NzaC1yc2EAAAADAQABAAABAQDr/1KbriuigSA8fmYkWz3PHFTZTv1BfNimczSucDbjlAOXVvg/H18esgguYyBgvP1AgfzBxiA9nhN1zo8W2wVZj6KVrwITrRn2f4zdTNVRAd+136vtQoe+ibj8sfGVsLOGpVWQdqLmprzkO0KBCrRxPNni2h1GWq/l243zWQ7OTMb5cFAUKnSK6+ReLSGt7THKuCFp7Y9B/hU5wbEFw9z8uheDVR0ttYOu/cNyARLfD/paNrfG/+AXIoWNVhkIh0eok/DpUK9AuP6PpMRdIPB/LTSL9W7I96AcrUHeYg/U6dfp01nggF9LmTz3PWvX9I7Jym50irCwMOIr76Mb0U9r".
Debug: Facter: fact "sshfp_rsa" has resolved to "SSHFP 1 1 0acab3944a75a99da7e7dbef15f513d107630d04
SSHFP 1 2 7b6628e58127fab77e5b8a9a093b069cb144b9450d715140a40a5b7070662560".
Debug: Facter: fact "sshecdsakey" has resolved to "AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBP8MisPno3++oyGSbjuWscG+sLz5G8g/VfqO72T3ELSsGUdGjg+5e6DHM5fhXr8dT/ye+D3/1Wx2lbjLS/4f4jo=".
Debug: Facter: fact "sshfp_ecdsa" has resolved to "SSHFP 3 1 c9b6fc601597a56337d9c99c08e47e3979957223
SSHFP 3 2 59aeee742b0019fe21c5f4e572ded4c4fbeafeb157f502bc2b80252cc99eb555".
Debug: Facter: fact "sshed25519key" has resolved to "AAAAC3NzaC1lZDI1NTE5AAAAIGTpsLzD+CP+9tfByZpNO/vFiy+iAI4RzJUFdi7Tu6h0".
Debug: Facter: fact "sshfp_ed25519" has resolved to "SSHFP 4 1 4ae731677951a00d2c8945deedb722dc1c8c65b1
SSHFP 4 2 169dad3c187936103b4f166c4151e7f074f7f12fecc13672f624e59a9096d236".
Debug: Facter: fact "ssh" has resolved to {
  ecdsa => {
    fingerprints => {
      sha1 => "SSHFP 3 1 c9b6fc601597a56337d9c99c08e47e3979957223",
      sha256 => "SSHFP 3 2 59aeee742b0019fe21c5f4e572ded4c4fbeafeb157f502bc2b80252cc99eb555"
    },
    key => "AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBP8MisPno3++oyGSbjuWscG+sLz5G8g/VfqO72T3ELSsGUdGjg+5e6DHM5fhXr8dT/ye+D3/1Wx2lbjLS/4f4jo=",
    type => "ecdsa-sha2-nistp256"
  },
  ed25519 => {
    fingerprints => {
      sha1 => "SSHFP 4 1 4ae731677951a00d2c8945deedb722dc1c8c65b1",
      sha256 => "SSHFP 4 2 169dad3c187936103b4f166c4151e7f074f7f12fecc13672f624e59a9096d236"
    },
    key => "AAAAC3NzaC1lZDI1NTE5AAAAIGTpsLzD+CP+9tfByZpNO/vFiy+iAI4RzJUFdi7Tu6h0",
    type => "ssh-ed25519"
  },
  rsa => {
    fingerprints => {
      sha1 => "SSHFP 1 1 0acab3944a75a99da7e7dbef15f513d107630d04",
      sha256 => "SSHFP 1 2 7b6628e58127fab77e5b8a9a093b069cb144b9450d715140a40a5b7070662560"
    },
    key => "AAAAB3NzaC1yc2EAAAADAQABAAABAQDr/1KbriuigSA8fmYkWz3PHFTZTv1BfNimczSucDbjlAOXVvg/H18esgguYyBgvP1AgfzBxiA9nhN1zo8W2wVZj6KVrwITrRn2f4zdTNVRAd+136vtQoe+ibj8sfGVsLOGpVWQdqLmprzkO0KBCrRxPNni2h1GWq/l243zWQ7OTMb5cFAUKnSK6+ReLSGt7THKuCFp7Y9B/hU5wbEFw9z8uheDVR0ttYOu/cNyARLfD/paNrfG/+AXIoWNVhkIh0eok/DpUK9AuP6PpMRdIPB/LTSL9W7I96AcrUHeYg/U6dfp01nggF9LmTz3PWvX9I7Jym50irCwMOIr76Mb0U9r",
    type => "ssh-rsa"
  }
}.
Debug: Facter: resolving id facts.
Debug: Facter: fact "id" has resolved to "root".
Debug: Facter: fact "gid" has resolved to "root".
Debug: Facter: fact "identity" has resolved to {
  gid => 0,
  group => "root",
  privileged => true,
  uid => 0,
  user => "root"
}.
Debug: Facter: resolving timezone facts.
Debug: Facter: fact "timezone" has resolved to "UTC".
Debug: Facter: resolving file system facts.
Debug: Facter: fact "mountpoints" has resolved to {
  / => {
    available => "35.99 GiB",
    available_bytes =><PHONE_NUMBER>6,
    capacity => "9.97%",
    device => "/dev/sda1",
    filesystem => "xfs",
    options => [
      "rw",
      "seclabel",
      "relatime",
      "attr2",
      "inode64",
      "noquota"
    ],
    size => "39.98 GiB",
    size_bytes =><PHONE_NUMBER>0,
    used => "3.99 GiB",
    used_bytes =><PHONE_NUMBER>
  },
  /dev => {
    available => "235.77 MiB",
    available_bytes => 247222272,
    capacity => "0%",
    device => "devtmpfs",
    filesystem => "devtmpfs",
    options => [
      "rw",
      "seclabel",
      "nosuid",
      "size=241428k",
      "nr_inodes=60357",
      "mode=755"
    ],
    size => "235.77 MiB",
    size_bytes => 247222272,
    used => "0 bytes",
    used_bytes => 0
  },
  /dev/hugepages => {
    available => "0 bytes",
    available_bytes => 0,
    capacity => "100%",
    device => "hugetlbfs",
    filesystem => "hugetlbfs",
    options => [
      "rw",
      "seclabel",
      "relatime"
    ],
    size => "0 bytes",
    size_bytes => 0,
    used => "0 bytes",
    used_bytes => 0
  },
  /dev/mqueue => {
    available => "0 bytes",
    available_bytes => 0,
    capacity => "100%",
    device => "mqueue",
    filesystem => "mqueue",
    options => [
      "rw",
      "seclabel",
      "relatime"
    ],
    size => "0 bytes",
    size_bytes => 0,
    used => "0 bytes",
    used_bytes => 0
  },
  /dev/pts => {
    available => "0 bytes",
    available_bytes => 0,
    capacity => "100%",
    device => "devpts",
    filesystem => "devpts",
    options => [
      "rw",
      "seclabel",
      "nosuid",
      "noexec",
      "relatime",
      "gid=5",
      "mode=620",
      "ptmxmode=000"
    ],
    size => "0 bytes",
    size_bytes => 0,
    used => "0 bytes",
    used_bytes => 0
  },
  /dev/shm => {
    available => "243.60 MiB",
    available_bytes => 255430656,
    capacity => "0%",
    device => "tmpfs",
    filesystem => "tmpfs",
    options => [
      "rw",
      "seclabel",
      "nosuid",
      "nodev"
    ],
    size => "243.60 MiB",
    size_bytes => 255430656,
    used => "0 bytes",
    used_bytes => 0
  },
  /run => {
    available => "239.05 MiB",
    available_bytes => 250662912,
    capacity => "1.87%",
    device => "tmpfs",
    filesystem => "tmpfs",
    options => [
      "rw",
      "seclabel",
      "nosuid",
      "nodev",
      "mode=755"
    ],
    size => "243.60 MiB",
    size_bytes => 255430656,
    used => "4.55 MiB",
    used_bytes => 4767744
  },
  /run/user/0 => {
    available => "48.72 MiB",
    available_bytes => 51089408,
    capacity => "0%",
    device => "tmpfs",
    filesystem => "tmpfs",
    options => [
      "rw",
      "seclabel",
      "nosuid",
      "nodev",
      "relatime",
      "size=49892k",
      "mode=700"
    ],
    size => "48.72 MiB",
    size_bytes => 51089408,
    used => "0 bytes",
    used_bytes => 0
  },
  /run/user/1000 => {
    available => "48.72 MiB",
    available_bytes => 51089408,
    capacity => "0%",
    device => "tmpfs",
    filesystem => "tmpfs",
    options => [
      "rw",
      "seclabel",
      "nosuid",
      "nodev",
      "relatime",
      "size=49892k",
      "mode=700",
      "uid=1000",
      "gid=1000"
    ],
    size => "48.72 MiB",
    size_bytes => 51089408,
    used => "0 bytes",
    used_bytes => 0
  },
  /sys/fs/cgroup => {
    available => "243.60 MiB",
    available_bytes => 255430656,
    capacity => "0%",
    device => "tmpfs",
    filesystem => "tmpfs",
    options => [
      "ro",
      "seclabel",
      "nosuid",
      "nodev",
      "noexec",
      "mode=755"
    ],
    size => "243.60 MiB",
    size_bytes => 255430656,
    used => "0 bytes",
    used_bytes => 0
  },
  /var/lib/nfs/rpc_pipefs => {
    available => "0 bytes",
    available_bytes => 0,
    capacity => "100%",
    device => "sunrpc",
    filesystem => "rpc_pipefs",
    options => [
      "rw",
      "relatime"
    ],
    size => "0 bytes",
    size_bytes => 0,
    used => "0 bytes",
    used_bytes => 0
  }
}.
Debug: Facter: fact "filesystems" has resolved to "iso9660,xfs".
Debug: Facter: fact "partitions" has resolved to {
  /dev/sda1 => {
    filesystem => "xfs",
    mount => "/",
    size => "40.00 GiB",
    size_bytes =><PHONE_NUMBER>4,
    uuid => "8ac075e3-1124-4bb6-bef7-a6811bf8b870"
  }
}.
Debug: Facter: resolving memory facts.
Debug: Facter: fact "memoryfree" has resolved to "232.25 MiB".
Debug: Facter: fact "memoryfree_mb" has resolved to 232.246.
Debug: Facter: fact "memorysize" has resolved to "487.20 MiB".
Debug: Facter: fact "memorysize_mb" has resolved to 487.195.
Debug: Facter: fact "swapfree" has resolved to "2.00 GiB".
Debug: Facter: fact "swapfree_mb" has resolved to 2044.72.
Debug: Facter: fact "swapsize" has resolved to "2.00 GiB".
Debug: Facter: fact "swapsize_mb" has resolved to 2048.
Debug: Facter: fact "memory" has resolved to {
  swap => {
    available => "2.00 GiB",
    available_bytes =><PHONE_NUMBER>,
    capacity => "0.16%",
    total => "2.00 GiB",
    total_bytes =><PHONE_NUMBER>,
    used => "3.27 MiB",
    used_bytes => 3432448
  },
  system => {
    available => "232.25 MiB",
    available_bytes => 243527680,
    capacity => "52.33%",
    total => "487.20 MiB",
    total_bytes => 510861312,
    used => "254.95 MiB",
    used_bytes => 267333632
  }
}.
Debug: Facter: resolving load_average facts.
Debug: Facter: fact "load_averages" has resolved to {
  15m => 0.12,
  1m => 0.29,
  5m => 0.08
}.
Debug: Facter: resolving Xen facts.
Debug: Facter: resolving fips facts.
Debug: Facter: fact "fips_enabled" has resolved to false.
Debug: Reset text domain to :production
Notice: Compiled catalog for localhost.localdomain in environment production in 0.01 seconds
Debug: Creating default schedules
Debug: Loaded state in 0.00 seconds
Debug: Loaded state in 0.00 seconds
Info: Applying configuration version '1576106203'
Debug: /Stage[main]/Main/User[fake]: Nothing to manage: no ensure and the resource doesn't exist
Debug: Executing: '/bin/gpasswd -a real real'
Debug: Success: /bin/gpasswd -a real real
Debug: Executing: '/bin/gpasswd -a fake real'
Debug: Success: /bin/gpasswd -a fake real
Notice: /Stage[main]/Main/Group[real]/members: members changed 'real' to ['fake', 'real']
Debug: /Stage[main]/Main/Group[real]: The container Class[Main] will propagate my refresh event
Debug: Class[Main]: The container Stage[main] will propagate my refresh event
Debug: Finishing transaction 38397540
Debug: Storing state
Debug: Pruned old state cache entries in 0.00 seconds
Debug: Stored state in 0.00 seconds
Notice: Applied catalog in 0.04 seconds
Debug: Applying settings catalog for sections reporting, metrics
Debug: /File[/etc/puppetlabs/code/environments/production]/seluser: Found seluser default 'system_u' for /etc/puppetlabs/code/environments/production
Debug: /File[/etc/puppetlabs/code/environments/production]/selrole: Found selrole default 'object_r' for /etc/puppetlabs/code/environments/production
Debug: /File[/etc/puppetlabs/code/environments/production]/seltype: Found seltype default 'puppet_etc_t' for /etc/puppetlabs/code/environments/production
Debug: /File[/etc/puppetlabs/code/environments/production]/selrange: Found selrange default 's0' for /etc/puppetlabs/code/environments/production
Debug: Finishing transaction 37543140
Debug: Received report to process from localhost.localdomain
Debug: Processing report from localhost.localdomain with processor Puppet::Reports::Store

The gpasswd command works as expected,
$ sudo /bin/gpasswd -a fake real
gpasswd: user 'fake' does not exist

$ echo $?
3

The gpasswd module reports incorrectly,
Debug: Executing: '/bin/gpasswd -a fake real'
Debug: Success: /bin/gpasswd -a fake real

Should this "exitstatus ==3" check happen after execute, even if the execute function was successful?
https://github.com/onyxpoint/puppet-gpasswd/blob/e01b9974faeb5e04d37ae24e2e623b17c406472b/lib/puppet/provider/group/gpasswd.rb#L131

@cheyngoodman Thanks for this, it really helps narrow down a repeater!

@cheyngoodman Can you see if the referenced PR fixes your issue?

Using getpwnam and getpwuid results in valid ldap users being filtered out. Which makes this group enhancement only work with local users.


No module named Cryptodome.PublicKey

I get this error when starting kodi with the plugin installed.
Any idea how to fix it?
20:31:34.362 T:2461196704   ERROR: EXCEPTION Thrown (PythonToCppException) : -->Python callback/script returned the following error<--                                              - NOTE: IGNORING THIS CAN LEAD TO MEMORY LEAKS!                                             Error Type: <type 'exceptions.ImportError'>                                             Error Contents: No module named Cryptodome.PublicKey                                             Traceback (most recent call last):                                               File "/home/odroid/.kodi/addons/plugin.video.netflix/service.py", line 11, in <module>                                                 from resources.lib.MSLHttpRequestHandler import MSLHttpRequestHandler                                               File "/home/odroid/.kodi/addons/plugin.video.netflix/resources/lib/MSLHttpRequestHandler.py", line 9, in <module>                                                 from MSL import MSL                                               File "/home/odroid/.kodi/addons/plugin.video.netflix/resources/lib/MSL.py", line 17, in <module>                                                 from Cryptodome.PublicKey import RSA                                             ImportError: No module named Cryptodome.PublicKey                                             -->End of Python script error report<--

Try with pip install pycryptodome

Requirement already satisfied: pycryptodome in /usr/local/lib/python2.7/dist-packages

pip install pycryptodomex

For some reason, pycryptodome was installed in the Crypto folder, symlinking Cryptodome to Crypto in the above location worked.

pycryptodome always gets (per default) installed in the crypto folder.
Thats the reason why you need to install pycryptodomex

Use this Kodi version KodiSetup-20170809-67137d6348-master-x86.exe. It has a working cryptodomex library. The plugin is working great. All problems are related to Kodi nighty builds.
Check this step by step tutorial for windows:
https://domtik.com/index.php/2017/09/03/addon-netflix-kodi/

On linux Kodi it is not installed by default. please add pip install pycryptodomex to main readme.

Requirement already satisfied: pycryptodomex in /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages
You are using pip version 9.0.1, however version 10.0.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

To clarify the discussion from april 6th 2017;
pycryptodome and pycryptodomex are different packages;
pycryptodome installs many files in /usr/local/lib/py/thon2.7/dist-packages/Crypto
pycryptodomex installs many files in /usr/local/lib/python2.7/dist-packages/Cryptodome
At one point, kodi changed the dependency from pycryptodome to pycryptodomex.  O rmy distribution had the dependency wrong to begin with
I believe my distribution didn't accuratly update the 'depends' listing for kodi when this happened, so i ended up with pycryptodome installed, when kodi expected pycryptodomex... so kodi was looking in the wrong folder for crypto
When the problem first occured, making the noted symlink functionally worked;  would have also worked to manually install pycryptodomex
However the symlink later broke the installation of pycryptodomex when the kodi dependency was fixed (due to conflicting files in filesystem).  Removing the symlink fixed that problem.


Better error message if supported ABI's cannot be found inside the APK.

This PR adds a better error message if an ABI cannot be successfully located.
This is helpful as some app users are side-loading APKs outside the Play Store. If those apps have been built using App Bundle or APK Split, it could result in users loading an APK that doesn't support their device, which results in a rather unhelpful error message like com.getkeepsafe.relinker.MissingLibraryException: libtest.so. This isn't particularly helpful for an app developer tracking their crashes. Especially if they are using a 3rd party library that includes native code. In that case, it could look like it is a bug in the 3rd party library.
With this PR, the error message now tries to be more descriptive about what has been tried and what is actually supported by the device, so the error message will now look like this:
Could not find 'libtest.so'. Looking for: [armeabi-v7a], but only [x86, arm64-v8a] are supported.

Hi there,
Any idea when this PR will be merged/released?
It is apparently blocking the mentioned PR for Realm Java (https://github.com/realm/realm-java/issues/6673), which crashes the app for a significant percentage of users.
Cheers

Hi there,
Any idea when this PR will be merged/released?
It is apparently blocking the mentioned PR for Realm Java (realm/realm-java#6673), which crashes the app for a significant percentage of users.
Cheers

Please see: https://github.com/KeepSafe/ReLinker/pull/65#pullrequestreview-336893515

Ready for 2nd round @emarc-m

Ready for 2nd round @emarc-m

Thank you for addressing the comments.

@cmelchior (cc: @Tweener) version 1.4.0 has been released which includes these changes. Thank you for the contribution.

Awesome. Thanks 👏


Fix wrong system usage

About the PR
Fixes null exception made in #32455
Why / Balance

Technical details

Media

Requirements

[ ] I have read and am following the Pull Request and Changelog Guidelines.
[ ] I have added media to this PR or it does not require an ingame showcase.

Breaking changes

Changelog

Thanks for the quick fix! I'm renaming your PR title since this only needs to be merged into master, not into stable. We use the term hotfix for changes to stable outside the normal releases.

Got it


Kafka Source: add support for the Kubernetes resources spec,

Expected Behavior
in the CR file I am able to set values to Managing Compute Resources for Containers, like:

resources.limits.cpu
resources.limits.memory
resources.requests.cpu
resources.requests.memory

which would than delegate to the underlying k8s resources spec, as:

spec.containers[].resources.limits.cpu
spec.containers[].resources.limits.memory
spec.containers[].resources.requests.cpu
spec.containers[].resources.requests.memory

Actual Behavior
ATM, it is not possible directly in the CR file, that sets up a source.
However, you can already do the "resource limit" settings, but unfortunately not directly on the CR file, you need to edit the existing deployment - not hard, but also not super convenient
Same applies to livenessProbe and readinessProbe
Additional Info
As discussed on slack with @evankanderson I am going to prototype this on the KafkaSource and document the steps. so that is can be applied to other supported sources as well

/assign matzew

Code for Kafka lives here, for instance:
https://github.com/knative/eventing-sources/blob/master/contrib/kafka/pkg/reconciler/resources/receive_adapter.go#L58-L62

/assign @lberk

heh, well, despite the lack of formal prow-bot assignment, I've started looking into this issue! :)


SDP for new Sony Xperia 1 - 21:9 aspect ratio

@elhanan-mishraky  I knew SDP works respectively with SW ( Smallest Screen
width ). In my case with the new device Sony Xperia 1, the height is too tall. How to scale the views equally using SDP? Any workaround to support my use-case?
SW for this device is 411
Expected - Pixel

Unexpected - Sony Xperia 1

You can place a view below the 'Next' button with layout_weight=1 and layout_height=0. It will push it up.


Rerun Vizro Dashboard in Jupyter doesn't work

Description

ValidationError: 1 validation error for Graph
figure
Component with id=scatter_chart already exists and is mapped to dataset<PHONE_NUMBER>34896. Components must uniquely map to a dataset across the whole dashboard. If you are working from a Jupyter Notebook, please either restart the kernel, or use 'from vizro.managers import data_manager; data_manager._reset()`. (type=value_error)

'from vizro.managers import data_manager; data_manager._reset()`. After I follow the instruction and rerun the cell, I run into a new error.

DuplicateIDError: Model with id=scatter_chart already exists. Models must have a unique id across the whole dashboard. If you are working from a Jupyter Notebook, please either restart the kernel, or use 'from vizro.managers import model_manager; model_manager._reset()`.

After I run 'from vizro.managers import model_manager; model_manager._reset()`, no error is raised but it doesn't show the dashboard UI anymore.

Expected behavior
I expect the dashboard render properly. Workaround is restart the Kernel which work fine but is considerably slower.
vizro version
0.1.4
Python version
3.8.5
OS
MacOS
How to Reproduce
Follow the tutorial and run it in a notebook twice.
https://vizro.readthedocs.io/en/stable/pages/tutorials/first_dashboard/#4-explore-further
Output
No response
Code of Conduct

[X] I agree to follow the Code of Conduct.

Hey @noklam,
thanks so much for getting in touch :) I was able to reproduce this issue, and it is indeed a bug. We are working on a smoother Jupyter experience already (see https://github.com/mckinsey/vizro/issues/65), but it looks like that the short term solution described in this issue does not capture this case.
So in the short term we would recommend going via the approach of restarting the kernel, this is as you say slower, but the most reliable method. We will get back once there is a more comprehensive solution.

Reproducing this error works, although atm the error message does not show for me. Code can be found at: https://github.com/mckinsey/vizro/tree/bug/109
Observations:

page registries are different but not empty
comparing the global variable dash seems to suggest that only supplied_layout and layout are differing, and in that, only the IDs
resetting the managers, the dash.page_registry as well as choosing a new port does not fix the issue

I ran into this problem too. If you open up the browser dev tools, you can see in the console that the Dash renderer is throwing an error due to duplicate callbacks being registered. This is because Dash maintains some global state about registered callbacks, (which enables the dash.callback convenience decorator freeing you from having to thread a Dash instance throughout your code that app.callback requires. So this this global state in the dash module is persisting across re-runs of the Vizro app, causing a clash.
As already mentioned, there's also global state for Dash's pages feature, which should probably be reset too. I ran into that particular gotcha a while back when writing tests for Dash Pages, with this global state interfering with subsequent tests. So I added a fixture to clear that global state.
Here's a recipe for clearing (hopefully) everything, and which allows me to re-run the demo Vizro app when you call the function at the top of the cell:
import dash
from vizro.managers import data_manager, model_manager
def reset_state():
    data_manager._reset()
    model_manager._reset()
    dash._callback.GLOBAL_CALLBACK_LIST = []
    dash._callback.GLOBAL_CALLBACK_MAP = {}
    dash._pages.PAGE_REGISTRY.clear()
    dash._pages.CONFIG.clear()
    dash._pages.CONFIG.__dict__.clear()

I ran into this issue too. If you open up the browser dev tools, you'll see that the Dash renderer is throwing a duplicate callback issue. This is caused by some global state about registered callbacks that is shared across the entire dash module to enable the dash.callback convenience decorator, which saves you from having to thread your dash.Dash instance throughout different modules (ie app.callback()). Resetting  dash._callback.GLOBAL_CALLBACK_LIST and dash._callback.GLOBAL_CALLBACK_MAP before re-running the Vizro app fixes this issue.
As already mentioned, there's also some global state for Dash Page registry, and also for Page config. These should be reset too. I ran into this when adding tests for the Pages feature, where this global state was interfering with subsequent tests, so added this fixture to clear the global Pages state.
Putting it all together, here's a recipe for clearing (hopefully) everything, and which allows the demo app to be re-run when you call the function at the top of the cell containing the app:
import dash
from vizro.managers import data_manager, model_manager

def reset_state():
    data_manager._reset()
    model_manager._reset()
    dash._callback.GLOBAL_CALLBACK_LIST = []
    dash._callback.GLOBAL_CALLBACK_MAP = {}
    dash._pages.PAGE_REGISTRY.clear()
    dash._pages.CONFIG.clear()
    dash._pages.CONFIG.__dict__.clear()

Hello @ned2 and thank you very much for the tip! I've seen your name pop up a lot when I read the plotly forums and so it's amazing to see you here 😀 I'm just curious how you found out about vizro in the first place?
As you can see we've been on a similar journey trying to reset the dash page registry in a test fixture but couldn't find a way to clear the whole thing. Given what you recommend above I presume there's no way to do it with dash.page_registry directly and you have to go through the protected dash._pages instead?
Also in the clear_pages_state fixture you linked to is there any reason you do init_pages_state both before and after the yield? I would have thought that just clearing up after a test would be sufficient?
@huong-li-nguyen looks like what @ned2 above is the right way to do this test fixture 🎉
@maxschulz-COL I think we should rename _reset to _clear given that the interface for both data manager and model manager is similar to a dictionary, which uses .clear().

heya @antonymilne! I heard about vizro essentially by word of mouth. Someone shared it on the viz channel of a slack community I hangout in. Really love what y'all are working on here!!
Unfortunately there's not an interface for clearing any of the global state in the dash module. Understandbly, the Dash team are focusing on supporting ease of development for the overwhelming majority of Dash use-cases that never have more than a single Dash instance defined in a process. Using Dash as you are here falls into a bit more of a niche use-case. Though now that I think about it, have you looked into how Dash's builtin support for running in Jupyter notebooks works? From a user's perspective, they seem to have solved this problem.
Given that Dash is already implicitly making the assumption that users won' be creating multiple Dash instances within the same process, I think there's a strong argument to be made that Dash itself should lean into actively making the one instance-per-process assumption and remove this footgun by explicitly clearing all global state in the dash module within the  Dash.__init__().
Oh yes, the reason I cleared the state before and after the test contents are run. The tests I added were apparently the first tests sensitive to existing stale global Page state and I didn't want to assume that people would know to add this decorator to tests that mutated the registry. So essentially I was protecting my new tests  from being impacted by other tests. The initial call could be removed if you new that every other text was required to use the same fixture. Again, this would all be a non-issue if the Dash class itself cleared global state.

Thanks for all the comments @ned2 - it's super helpful. Given what you say I'd be tempted to add the code that resets the Dash globals to our own Vizro.__init__ which just calls Dash.__init__ (though our data_manager and model_manager couldn't be cleared there since they're needed later on). My hesitation would be that it's too brittle a solution since these hidden global variables are not part of the Dash API, so presumably a future version of Dash could remove/rename them without warning and leave our Vizro() broken.
Just to add to the above: we'll also need to clear GLOBAL_INLINE_SCRIPTS since we have some clientside callbacks. Since Dash exposes page_registry at top-level I guess we could do dash.page_registry.clear() rather than dash._pages.PAGE_REGISTRY.clear() but since we need to access the other stuff through _pages anyway it doesn't make much difference.
Great point about checking how JupyterDash works 👍 I don't see anything that clears global state there. There's something which is meant to kill an existing process so you can re-run on the same port (which has actually never worked for me and been on my long-term todo list to try to fix) but nothing else as far as I can see. So actually I wonder...

Where does the limitation that "Multi-page apps using Dash Pages are not supported in notebooks" come from? We are using Dash Pages in notebooks and it works fine (I think anyway?) so perhaps the limitation is just because they need to reset the page registry etc.
Why do they not need to reset callbacks? Maybe actually they should be doing so, just no one yet found a bug that resulted from not doing this

Why do they not need to reset callbacks? Maybe actually they should be doing so, just no one yet found a bug that resulted from not doing this

yeah that's a good question. I dug into this, and it looks like Dash itself clears the contents of GLOBAL_CALLBACK_LIST when the app receives it's first request. More specifically, this happens in _setup_routes() here, which is registered using Flask.before_request to run before every request, but the function returns immediately if it's not the first request the app sees.
So that seems to be how stale values in  GLOBAL_CALLBACK_LIST are avoided. And why multipage apps don't work I guess; there's nothing done to protect the registry from going stale.
As for why it's not working in Vizro. I poked around using a funky tool to observe when GLOBAL_CALLBACK_LIST is mutated, and I think I might have a handle on what's going on.
When using Dash Pages, the inside dash.enable_pages, the router function is registered with Flask to run on every request so that it can get the right layout fragment to insert into the main layout. If the page item fetched from the Pages registry is a callable, it needs to be called to get the layout object. It so happens that Page.build() calls Page._update_graph_theme, which registers the update_graph_theme callback. That means that a callback is being registered after the Dash server has started running. Ordinarily this would just result in a callback that doesn't work (hence why Dash docs mentions you can't do this), but the side-effect of this for us here is that GLOBAL_INLINE_SCRIPTS gets a new callback entry that won't be cleared by Dash, as it only does that before the first callback (as mentioned above).
So TLDR it sounds like the problem is that the Pages.build() class couples layout creation and callback registration together.

Implemented a _clear_state() function as a first step towards a smoother Jupyter experience.
Thanks again @ned2 for your valuable insights. We will make sure to build upon this for a solution that eventually may not even require a code-snippet at the top of a cell.

@ned9 That makes sense, thank you very much for digging into it! I hadn't seen watchpoints before and that looks like it will be very handy for this sort of thing.
Do you think that the Dash class itself should be clearing the dash._pages variables? Given that it takes responsibility for clearing the callbacks, it would feel like maybe that would ultimately also be the right place for the dash._pages clearing code to live also. This would presumably enable them to remove the restriction that multi-page apps don't work in Jupyter, although I guess in practice most multi-page apps would need to be structured quite differently from the conventional style so that they could work from a single notebook (rather than one Python file per page), so it's maybe not much of interest to Dash in general. If you think this is the right approach though then I will try to raise a PR on the Dash; otherwise we'll leave the code that does the clearing just in Vizro itself.
If we do move the _page clearing code to Dash itself then this would leave the Vizro clearing responsibility as:

objects that we're responsible for: data_manager and model_manager, which makes sense
things which we seem to have caused to malfunction a bit like the GLOBAL_CALLBACK_LIST you mention above, which we might not need to do if we restructure things

FYI @petar-qb what @ned9 says above about callback registration is very useful to know!

Reopen for visibility

Does anyone know anything about the error  <ContextVar name='callback_context' at 0x7f78465b2f90> when trying to run a dashboard in jupyterHub?

@LucaYoy this sounds like a separate issue to me so I've split it off into a new issue: #124. I'll follow up there 🙂