Run R CMD check on v3.6, v4.0 and release

Close #986
Thank you for your Pull Request! We have developed this task checklist from the Development Process Guide to help with the final steps of the process. Completing the below tasks helps to ensure our reviewers can maximize their time on your code as well as making sure the admiral codebase remains robust and consistent.
Please check off each taskbox as an acknowledgment that you completed the task or check off that it is not relevant to your Pull Request. This checklist is part of the Github Action workflows and the Pull Request will not be merged into the devel branch until you have checked off each task.

[x] Code is formatted according to the tidyverse style guide
[x] Updated relevant unit tests or have written new unit tests - See Unit Test Guide
[x] If you removed/replaced any function and/or function parameters, did you fully follow the deprecation guidance?
[x] Update to all relevant roxygen headers and examples
[x] Run devtools::document() so all .Rd files in the man folder and the NAMESPACE file in the project root are updated appropriately
[x] Address any updates needed for vignettes and/or templates
[x] Update NEWS.md
[x] Build admiral site pkgdown::build_site() and check that all affected examples are displayed correctly and that all new functions occur on the "Reference" page.
[x] Address or fix all lintr warnings and errors - lintr::lint_package()
[x] Run R CMD check locally and address all errors and warnings - devtools::check()
[x] Link the issue so that it closes after successful merging.
[x] Address all merge conflicts and resolve appropriately
[x] Pat yourself on the back for a job well done!  Much love to your accomplishment!

@pharmaverse/admiral I finally managed to get the R CMD check working on 3.6, 4.0 and 4.1. I need someone to approve such that we can merge this. Once done we can finally get rid of workarounds we used in order to support v3.5.

Yes, all related to getting the checks passed on all versions.


Can only add new line using shift + enter

This plugin causes my enter to not work

same :<

Any updates?

There's an option to install an earlier version. That worked for me.
I'm using VSCodium, this extension works properly for me in VSCode, but I'm getting the above error in VSCodium.

@gho

There's an option to install an earlier version. That worked for me.
I'm using VSCodium, this extension works properly for me in VSCode, but I'm getting the above error in VSCodium.

Thanks! Same conditions, and previous version works for me too!


Update OracleDatabase/README.md

Fix for issue #469 with minimum requirements for building Oracle Database image for Docker.

Unfortunately those requirements aren't generally applicable.
The swap space is only required for the 11g XE image and it will remain to be the only build for which this remains true.
The storage requirements are also version depending:

11g XE needs 400MB
12.1 needs 12GB
12.2 needs 15GB
With the 17.03 release on Oracle Linux we now have the sqash experimental available which may drives the requirement even further down but tests are still pending for that.

The only right (and manageable over time) approach to me is to check all the requirements within the Docker build itself. The space check already exists but seems to not catch every case, so we strive to improve to make that solid proof.
The swap space check for 11g XE is not there today but the error message is sufficient enough IMO. I'd rather work on mocking the swap space if possible as it isn't really needed anymore on modern hardware.

Well it doesn't heart to set minimum requirements to the large values (1GB swap, 15GB storage). It wil surely reduce the amount of issues asking for help

I highly doubt that. If people cannot even read
Error: The container doesn't have enough memory allocated.
A database XE container needs at least 1 GB of shared memory (/dev/shm).
You currently only have 64 MB allocated to the container.

from the build output then I don't think it makes them read the ReadMe either; same with the space check.
Furthermore, the swap space is just wrong information, you don't have to have it unless you want XE. And let's not forget that most modern systems don't even have swap anymore.

How damaging will it be to have generalized minimum requirements?

If we tell everybody that they now need 1GB swap space which they don't have configured and don't need... Probably quite a bit. Maybe we can address it in a table rather than just bullet points.

I think a table of requirements sounds like a good idea.

I'm going to close this. If @gvenzl feels the docs need to be updated, he can submit a new PR.


[FEATURE] longhorn-manager webook admission health check parameter

I know that longhorn reached version 1.5.0, which brought changes to the operator.
Previously, we could adjust the value of the timeout entry in the curl command by modifying the argument value in the chart, but now it's hardcoded and can no longer be changed.
I would suggest creating that option and making it available to set.

Which chart value/curl command do you mean...? In v1.5.0, webhook services are merged into longhorn-manager pods.

Your right. I need this to parameterize.
https://github.com/longhorn/longhorn-manager/blob/16895efa30532755539b70ceee9c82073dfb36fd/app/webhook.go#L52

Hmm... This health check client is for probing the local webhook service, is it necessary to make it tunable...?
cc @derekbit

Hmm... This health check client is for probing the local webhook service, is it necessary to make it tunable...? cc @derekbit

I'm not sure.
@wolfdate25 Can you elaborate more on the issues when using a fixed timeout value?

Distance between nodes in my cluster is at the continental level.
It's hard to get a response in just a second.
Of course, I know that my cluster is not an ideal situation.
I already use openebs' jiva as an alternative, but I like longhorn's interface.
I hope you'll consider my comments.

Here, the destination of the client is https://localhost:/v1/healthz. Will the requests for this URL be forwarded to other nodes...?

In the new implementation, it should not be. Right?

Interestingly, the result is different than when we tried it before.
The issue I was experiencing with instance manager or longhorn manager not running on certain nodes seems to have been resolved. Based on 1.4.0, I thought the issue was related to request timeout.
There are no issues at this time, so we're closing the issue. Thank you for your attention.


Refactor buttons/icons into react-common

Refactoring buttons and icons in the skillmap into react-common. This will eventually be done in the main webapp as well.

Not going to track as a bug.


nixos/switch-to-configuration: Mount improvements and a lot more test cases

Description of changes
Adds way more test cases, mostly about command line handling and fstab handling.
Also fixes #242737 by adding an explicit exclusion as a double safeguard.

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

@ofborg test switchTest


[CI] Add the cache action to the CI

Current Behavior

Every time needs to redownload the dependencies for building.
Desired Behavior

The action allows caching dependencies and builds outputs to improve workflow execution time.
Resources

Alternatives / Additional Context

Adding to today's CI Working Group meeting agenda.

Fixed by #972


Chromium : No update available !

The latest build is 44.0.2389.0 !

Thanks for the report.
This issue is already tracked in https://github.com/chocolatey/chocolatey-coreteampackages/issues/52


gradle bootBuildImage fails due to paketo-buildpacks/bellsoft-liberica

We are using the Gradle target bootBuildImage by Spring Boot 3 to build Docker images for our app. Since yesterday (so since your release of 10.1), this fails. We changed nothing on our side.
Expected Behavior
It works :)
Those are logs from a successful old run on Github:
2023-04-11T11:26:16.3849915Z  > Running creator
2023-04-11T11:26:17.3887204Z     [creator]     ===> ANALYZING
2023-04-11T11:26:17.4845334Z     [creator]     Image with name "ghcr.io/genspectrum/lapis-v2:simpleVariantQuery" not found
2023-04-11T11:26:17.4846074Z     [creator]     ===> DETECTING
2023-04-11T11:26:18.1845855Z     [creator]     6 of 26 buildpacks participating
2023-04-11T11:26:18.1846918Z     [creator]     paketo-buildpacks/ca-certificates   3.6.0
2023-04-11T11:26:18.1954923Z     [creator]     paketo-buildpacks/bellsoft-liberica 10.0.0
2023-04-11T11:26:18.1955490Z     [creator]     paketo-buildpacks/syft              1.26.0
2023-04-11T11:26:18.1957145Z     [creator]     paketo-buildpacks/executable-jar    6.6.2
2023-04-11T11:26:18.1957602Z     [creator]     paketo-buildpacks/dist-zip          5.5.2
2023-04-11T11:26:18.1958012Z     [creator]     paketo-buildpacks/spring-boot       5.23.0
2023-04-11T11:26:18.1958325Z     [creator]     ===> RESTORING
2023-04-11T11:26:18.1958599Z     [creator]     ===> BUILDING
2023-04-11T11:26:18.1958842Z     [creator]
2023-04-11T11:26:18.1959165Z     [creator]     Paketo Buildpack for CA Certificates 3.6.0
2023-04-11T11:26:18.1959641Z     [creator]       https://github.com/paketo-buildpacks/ca-certificates
2023-04-11T11:26:18.1960015Z     [creator]       Launch Helper: Contributing to layer
2023-04-11T11:26:18.1960554Z     [creator]         Creating /layers/paketo-buildpacks_ca-certificates/helper/exec.d/ca-certificates-helper
2023-04-11T11:26:18.1961097Z     [creator]
2023-04-11T11:26:18.1961442Z     [creator]     Paketo Buildpack for BellSoft Liberica 10.0.0
2023-04-11T11:26:18.1961983Z     [creator]       https://github.com/paketo-buildpacks/bellsoft-liberica
2023-04-11T11:26:18.1962381Z     [creator]       Build Configuration:
2023-04-11T11:26:18.1963095Z     [creator]         $BP_JVM_JLINK_ARGS           --no-manpages --no-header-files --strip-debug --compress=1  configure custom link arguments (--output must be omitted)
2023-04-11T11:26:18.1964270Z     [creator]         $BP_JVM_JLINK_ENABLED        false                                                        enables running jlink tool to generate custom JRE
2023-04-11T11:26:18.1964980Z     [creator]         $BP_JVM_TYPE                 JRE                                                          the JVM type - JDK or JRE
2023-04-11T11:26:18.1965464Z     [creator]         $BP_JVM_VERSION              17                                                           the Java version
2023-04-11T11:26:18.1965878Z     [creator]       Launch Configuration:
2023-04-11T11:26:18.1966343Z     [creator]         $BPL_DEBUG_ENABLED           false                                                        enables Java remote debugging support
2023-04-11T11:26:18.1966897Z     [creator]         $BPL_DEBUG_PORT              8000                                                         configure the remote debugging port
2023-04-11T11:26:18.1967483Z     [creator]         $BPL_DEBUG_SUSPEND           false                                                        configure whether to suspend execution until a debugger has attached
2023-04-11T11:26:18.1968077Z     [creator]         $BPL_HEAP_DUMP_PATH                                                                       write heap dumps on error to this path
2023-04-11T11:26:18.1968640Z     [creator]         $BPL_JAVA_NMT_ENABLED        true                                                         enables Java Native Memory Tracking (NMT)
2023-04-11T11:26:18.1969194Z     [creator]         $BPL_JAVA_NMT_LEVEL          summary                                                      configure level of NMT, summary or detail
2023-04-11T11:26:18.1969773Z     [creator]         $BPL_JFR_ARGS                                                                             configure custom Java Flight Recording (JFR) arguments
2023-04-11T11:26:18.1970322Z     [creator]         $BPL_JFR_ENABLED             false                                                        enables Java Flight Recording (JFR)
2023-04-11T11:26:18.1971537Z     [creator]         $BPL_JMX_ENABLED             false                                                        enables Java Management Extensions (JMX)
2023-04-11T11:26:18.1974604Z     [creator]         $BPL_JMX_PORT                5000                                                         configure the JMX port
2023-04-11T11:26:18.1975112Z     [creator]         $BPL_JVM_HEAD_ROOM           0                                                            the headroom in memory calculation
2023-04-11T11:26:18.1975691Z     [creator]         $BPL_JVM_LOADED_CLASS_COUNT  35% of classes                                               the number of loaded classes in memory calculation
2023-04-11T11:26:18.1976267Z     [creator]         $BPL_JVM_THREAD_COUNT        250                                                          the number of threads in memory calculation
2023-04-11T11:26:18.1976776Z     [creator]         $JAVA_TOOL_OPTIONS                                                                        the JVM launch flags
2023-04-11T11:26:18.1977265Z     [creator]         Using Java version 19 extracted from MANIFEST.MF
2023-04-11T11:26:18.1977714Z     [creator]       BellSoft Liberica JRE 19.0.2: Contributing to layer
2023-04-11T11:26:18.1978518Z     [creator]         Downloading from https://github.com/bell-sw/Liberica/releases/download/19.0.2+9/bellsoft-jre19.0.2+9-linux-amd64.tar.gz
2023-04-11T11:26:19.0853453Z     [creator]         Verifying checksum
2023-04-11T11:26:19.1848130Z     [creator]         Expanding to /layers/paketo-buildpacks_bellsoft-liberica/jre
2023-04-11T11:26:20.8846295Z     [creator]         Warning: The JVM cacerts entries cannot be loaded with Java 18+, for more information see: https://github.com/paketo-buildpacks/libjvm/issues/158
2023-04-11T11:26:21.5866055Z     [creator]         Writing env.launch/BPI_APPLICATION_PATH.default
2023-04-11T11:26:21.5866608Z     [creator]         Writing env.launch/BPI_JVM_CACERTS.default
2023-04-11T11:26:21.5869577Z     [creator]         Writing env.launch/BPI_JVM_CLASS_COUNT.default
2023-04-11T11:26:21.5870570Z     [creator]         Writing env.launch/BPI_JVM_SECURITY_PROVIDERS.default
2023-04-11T11:26:21.5871258Z     [creator]         Writing env.launch/JAVA_HOME.default
2023-04-11T11:26:21.5871697Z     [creator]         Writing env.launch/JAVA_TOOL_OPTIONS.append
2023-04-11T11:26:21.5872179Z     [creator]         Writing env.launch/JAVA_TOOL_OPTIONS.delim
2023-04-11T11:26:21.5872608Z     [creator]         Writing env.launch/MALLOC_ARENA_MAX.default
2023-04-11T11:26:21.5873023Z     [creator]       Launch Helper: Contributing to layer
2023-04-11T11:26:21.5873921Z     [creator]         Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/active-processor-count
2023-04-11T11:26:21.5874721Z     [creator]         Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/java-opts
2023-04-11T11:26:21.5875370Z     [creator]         Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/jvm-heap
2023-04-11T11:26:21.5876040Z     [creator]         Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/link-local-dns
2023-04-11T11:26:21.5876702Z     [creator]         Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/memory-calculator
2023-04-11T11:26:21.5877426Z     [creator]         Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/security-providers-configurer
2023-04-11T11:26:21.5878082Z     [creator]         Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/jmx
2023-04-11T11:26:21.5878680Z     [creator]         Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/jfr
2023-04-11T11:26:21.5879387Z     [creator]         Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/security-providers-classpath-9
2023-04-11T11:26:21.5880056Z     [creator]         Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/debug-9
2023-04-11T11:26:21.5880660Z     [creator]         Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/nmt
2023-04-11T11:26:21.5881341Z     [creator]       Java Security Properties: Contributing to layer
2023-04-11T11:26:21.5881785Z     [creator]         Writing env.launch/JAVA_SECURITY_PROPERTIES.default
2023-04-11T11:26:21.5882211Z     [creator]         Writing env.launch/JAVA_TOOL_OPTIONS.append
2023-04-11T11:26:21.5882632Z     [creator]         Writing env.launch/JAVA_TOOL_OPTIONS.delim

Current Behavior
./gradlew bootBuildImage fails:
 ./gradlew bootBuildImage

> Task :bootBuildImage
Building image 'ghcr.io/genspectrum/lapis-v2:latest'

 > Pulling builder image 'docker.io/paketobuildpacks/builder:base' ..................................................
 > Pulled builder image 'paketobuildpacks/builder@sha256:f7f3d91740b51154bdde7d534145e21e37387320cc21e34092edc66c35203311'
 > Pulling run image 'docker.io/paketobuildpacks/run:base-cnb' ..................................................
 > Pulled run image 'paketobuildpacks/run@sha256:41443690a2dc36118112db2c4790dc2bc8189926dae9ff91992b78675d0cac39'
 > Executing lifecycle version v0.16.1
 > Using build cache volume 'pack-cache-0ebb606ef682.build'

 > Running creator
    [creator]     ===> ANALYZING
    [creator]     Restoring data for SBOM from previous image
    [creator]     ===> DETECTING
    [creator]     6 of 26 buildpacks participating
    [creator]     paketo-buildpacks/ca-certificates   3.6.1
    [creator]     paketo-buildpacks/bellsoft-liberica 10.1.0
    [creator]     paketo-buildpacks/syft              1.27.0
    [creator]     paketo-buildpacks/executable-jar    6.6.3
    [creator]     paketo-buildpacks/dist-zip          5.5.2
    [creator]     paketo-buildpacks/spring-boot       5.23.0
    [creator]     ===> RESTORING
    [creator]     Restoring metadata for "paketo-buildpacks/ca-certificates:helper" from app image
    [creator]     Restoring metadata for "paketo-buildpacks/bellsoft-liberica:helper" from app image
    [creator]     Restoring metadata for "paketo-buildpacks/bellsoft-liberica:java-security-properties" from app image
    [creator]     Restoring metadata for "paketo-buildpacks/bellsoft-liberica:jre" from app image
    [creator]     Restoring metadata for "paketo-buildpacks/syft:syft" from cache
    [creator]     Restoring metadata for "paketo-buildpacks/spring-boot:spring-cloud-bindings" from app image
    [creator]     Restoring metadata for "paketo-buildpacks/spring-boot:web-application-type" from app image
    [creator]     Restoring metadata for "paketo-buildpacks/spring-boot:helper" from app image
    [creator]     Restoring data for "paketo-buildpacks/syft:syft" from cache
    [creator]     Restoring data for SBOM from cache
    [creator]     ===> BUILDING
    [creator]
    [creator]     Paketo Buildpack for CA Certificates 3.6.1
    [creator]       https://github.com/paketo-buildpacks/ca-certificates
    [creator]       Launch Helper: Contributing to layer
    [creator]         Creating /layers/paketo-buildpacks_ca-certificates/helper/exec.d/ca-certificates-helper
    [creator]
    [creator]     Paketo Buildpack for BellSoft Liberica 10.1.0
    [creator]       https://github.com/paketo-buildpacks/bellsoft-liberica
    [creator]       Build Configuration:
    [creator]         $BP_JVM_JLINK_ARGS           --no-man-pages --no-header-files --strip-debug --compress=1  configure custom link arguments (--output must be omitted)
    [creator]         $BP_JVM_JLINK_ENABLED        false                                                        enables running jlink tool to generate custom JRE
    [creator]         $BP_JVM_TYPE                 JRE                                                          the JVM type - JDK or JRE
    [creator]         $BP_JVM_VERSION              17                                                           the Java version
    [creator]       Launch Configuration:
    [creator]         $BPL_DEBUG_ENABLED           false                                                        enables Java remote debugging support
    [creator]         $BPL_DEBUG_PORT              8000                                                         configure the remote debugging port
    [creator]         $BPL_DEBUG_SUSPEND           false                                                        configure whether to suspend execution until a debugger has attached
    [creator]         $BPL_HEAP_DUMP_PATH                                                                       write heap dumps on error to this path
    [creator]         $BPL_JAVA_NMT_ENABLED        true                                                         enables Java Native Memory Tracking (NMT)
    [creator]         $BPL_JAVA_NMT_LEVEL          summary                                                      configure level of NMT, summary or detail
    [creator]         $BPL_JFR_ARGS                                                                             configure custom Java Flight Recording (JFR) arguments
    [creator]         $BPL_JFR_ENABLED             false                                                        enables Java Flight Recording (JFR)
    [creator]         $BPL_JMX_ENABLED             false                                                        enables Java Management Extensions (JMX)
    [creator]         $BPL_JMX_PORT                5000                                                         configure the JMX port
    [creator]         $BPL_JVM_HEAD_ROOM           0                                                            the headroom in memory calculation
    [creator]         $BPL_JVM_LOADED_CLASS_COUNT  35% of classes                                               the number of loaded classes in memory calculation
    [creator]         $BPL_JVM_THREAD_COUNT        250                                                          the number of threads in memory calculation
    [creator]         $JAVA_TOOL_OPTIONS                                                                        the JVM launch flags
    [creator]         Using Java version 19 extracted from MANIFEST.MF
    [creator]       No valid JRE available, providing matching JDK instead. Using a JDK at runtime has security implications.
    [creator]        : Contributing to layer
    [creator]       Warning: Dependency has no SHA256. Skipping cache.
    [creator]         Downloading from
    [creator]     unable to invoke layer creator
    [creator]     unable to get dependency
    [creator]     unable to download
    [creator]     unable to request
    [creator]     Get "": unsupported protocol scheme ""
    [creator]     ERROR: failed to build: exit status 1

> Task :bootBuildImage FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':bootBuildImage'.
> Builder lifecycle 'creator' failed with status code 51

In case it helps:
$  java -version
openjdk version "19.0.2" 2023-01-17
OpenJDK Runtime Environment (build 19.0.2+7-Ubuntu-0ubuntu322.04)
OpenJDK 64-Bit Server VM (build 19.0.2+7-Ubuntu-0ubuntu322.04, mixed mode, sharing)

Our build.gradle.
Steps to Reproduce
Should be obvious from above.

This might have been introduced by https://github.com/paketo-buildpacks/bellsoft-liberica/pull/383, but why wasn't the upgrade labelled a new major version, if that is the case?

Java 19 was removed because it is not an LTS release and is no longer supported. We cannot continue shipping upstream dependencies that are EOL and not receiving updates so they are removed. Because it is non-LTS we do not do a major version bump.
Options forward:

Update to Java 20.
Fix your buildpacks on https://github.com/paketo-buildpacks/java/releases/tag/v9.1.0. That is the last release that will ship Java 19. See here for an example.

this did the trick for me:
in gradle.build:
tasks.named("bootBuildImage") {
    buildpacks = ["gcr.io/paketo-buildpacks/java@sha256:fb6c227be942aadb9d14c6c640dbb350082b4ad0228246a1062328e08b3096d7"]
    }


Update Kafka.md

The parameter in sink should be topics, not topic

Purpose of this pull request

Check list

[ ] Code changed are covered with tests, or it does not need tests for reason:
[ ] If any new Jar binary package adding in your PR, please add License Notice according
New License Guide
[x] If necessary, please update the documentation to describe the new feature. https://github.com/apache/incubator-seatunnel/tree/dev/docs

Conflict with your another PR #2866


ProduceReferenceAssembly

This article should mention that the /refout switch can be set with the MSBuild property ProduceReferenceAssembly - see https://docs.microsoft.com/en-us/visualstudio/msbuild/common-msbuild-project-properties

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 19cfe451-fe25-39c9-cf32-f5a434008a01
Version Independent ID: 03a35576-ad5f-1c32-c158-cd710b47df9c
Content: -refout (C# Compiler Options)
Content Source: docs/csharp/language-reference/compiler-options/refout-compiler-option.md
Product: dotnet-csharp
GitHub Login: @BillWagner
Microsoft Alias: wiwagn

@BillWagner I'll take on this update

Thanks @jwwicks.
It's yours.


Adds deployment target configs based on provided platform_type & minimum_os_version

This PR adds the suggested patch from @segiddins that allows platform and minimum deployment target to be passed through to target configuration option settings in Xcode.
If the platform is iOS, it will add IPHONEOS_DEPLOYMENT_TARGET with the corresponding minimum version.
If the platform is macOS, it will add MACOSX_DEPLOYMENT_TARGET with the corresponding minimum version (and set the SDKROOT to macosx if needed).

@segiddins f6aec9a updates the min os version to 11 in an attempt to see if that corrects the build failures when the deployment target is set (and it's < iOS 11).
Any idea what additional configs we might need to specify to get it working again with iOS 10?


bluetooth: request APIs to notify application that pairing is complete or not

Bluetooth pairing provides the way for authentication and security practice, thus the application should be notified if the pairing with a specific device was successful or not. The current zephyr Bluetooth stack doesn't have one which can meet this requirement. So, it is better to add a new API to cover this requirement.  Thank you!

More discussions about this request can be referred here: https://lists.zephyrproject.org/g/devel/topic/22117716#4763


Add filtering for extensions with max version

-Docs are generated using the latest CLI version. This may cause an extension to not be compatible.
-Filtering out for now to pass CI
-Will talk to docs team about our plans for these extensions.

Merging to unblock CI


Suggestion for commands

Nowadays, most Linux distros use systemd. And its tools have similar commands.
For example, instead of using brightness -g a user familiar with systemd tools might try get-brightness first. Or monitorctl brightness without any value, to get the value without changing it, similar to hostnamectl location.
I really like the shortcuts and would not suggest removing them. But personally, i think they can be improved. Both in terms of characters typed, and how natural the word order feels. For example, instead of b -i i suggest ib for "increase brightness".  But of course this comes down to personal preference.

I should include this in the help message but, the tool already support flags for subcommands.
so the following commands work.
monitorctl -bg
monitorctl -bi
monitorctl -bd

However, the reverse is not true. the following commands dont work.
monitorctl -ib
monitorctl -db
monitorctl -dg

I can try to make it so that the opposite order works as well.
Also, making monitorctl b and other equivalents to default to getting brightness seems like a good idea. Will work on it when I have time. But first, I need to handle support for laptops and make sure if something goes wrong the program doesn't panic.


KNOX-2343 - Enhanced API services' display on the Knox Home page

What changes were proposed in this pull request?
I added samples into API-type service.xml files' metadata section (wherever applicable) and modified the underlying Java code to:

interpret the new XML elements
make samples available through the metadata API
have them displayed on the Home page: instead of simply listing the Knox access of a particular service it now looks very similar to how we display the UI services. When clicking on the API service icon a new modal window gets opened with the selected API service details, including the newly added samples

How was this patch tested?
Tested manually:

Thanks, @moresandeep for your review comments, nice job spotting them out :) I fixed them all.

Thanks, @risdenk for your review comments. I fixed them all.


pkg> test GLMakie errors

After adding GLMakie, the first example in the Makie tutorial would open the Makie window but not add any plot features for the sin function and axes.
Running the >pkg test GLMakie resulted in an error,  :
....
Pick a plot element or plot elements inside a rectangle: Error During Test at /home/andrew/.julia/packages/GLMakie/rcykA/test/unit_tests.jl:27
Got exception outside of a @test
MethodError: Cannot convert an object of type Vector{Char} to an object of type Char
Closest candidates are:
convert(::Type{T}, ::Number) where T<:AbstractChar at char.jl:179
convert(::Type{T}, ::T) where T<:AbstractChar at char.jl:182
convert(::Type{T}, ::AbstractChar) where T<:AbstractChar at char.jl:181
...
Stacktrace:
[1] setproperty!(x::AbstractPlotting.PriorityObservable{Char}, f::Symbol, v::Vector{Char})
@ Base ./Base.jl:34
...
Test Summary:                                             | Pass  Error  Total
unit tests                                                |    1      2      3
Window handling                                         |    1      1      2
Pick a plot element or plot elements inside a rectangle |           1      1
ERROR: LoadError: LoadError: Some tests did not pass: 1 passed, 0 failed, 2 errored, 0 broken.
in expression starting at /home/andrew/.julia/packages/GLMakie/rcykA/test/unit_tests.jl:9
in expression starting at /home/andrew/.julia/packages/GLMakie/rcykA/test/runtests.jl:14
ERROR: Package GLMakie errored during testing

Fixed by: https://github.com/JuliaPlots/Makie.jl/pull/1190

Oh, or so I thought :D Not sure what you're running into here, but CI passes just fine..
Make sure you're on the same versions as in the docs: http://makie.juliaplots.org/stable/#First-Steps
Not sure how you display things, but e.g. when you're in the VSCode plotpane, you'll need to redisplay the figure

I should clarify: This test was running on an Nvidia Jetson Nano. Currently their Jetpack version 4.5 only supports CUDA 10.
"JetPack 5.0 will be the next major release, and will include an upgrade to LTS Kernel 5.10 and Ubuntu 20.04. Other noteworthy changes include support for UEFI (replacing CBoot), support for OP-TEE (replacing Trusty as the trusted execution environment), and an upgraded compute stack including CUDA 11. The Developer Preview of JetPack 5.0 is planned for Q1-2022 and the production release is planned for 2H-2022."

As long as the Jetson has OpenGL it should work...
But the error doesn't look platform related at all, so I'd check if you're on these versions first:
http://makie.juliaplots.org/stable/#First-Steps


Fix meta.yaml logic for autotick-bot compatibility

This PR changes the definition of the version variable to match the format used in the tags, i.e. 4_4.1.0, so that the autotick-bot (that extracts the version information from git tags by stripping all the characters till the first digit) works fine. The version in 4.1.0 format is now contained in the version_package variable (see https://github.com/conda-forge/libignition-msgs1-feedstock/issues/50 and https://github.com/conda-forge/libignition-msgs1-feedstock/issues/53 ).
Checklist

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

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe:

Jinja2 variable references are suggested to take a {{<one space><variable name><one space>}} form. See lines [57].

@conda-forge-admin, please rerender

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


kernel log spam after setting enable_depth= false

Before opening a new issue, we wanted to provide you with some useful suggestions (Click "Preview" above for a better view):

Consider checking out SDK examples.
Have you looked in our documentations?
Is you question a frequently asked one?
Try searching our GitHub Issues (open and closed) for a similar issue.

All users are welcomed to report bugs, ask questions, suggest or request enhancements and generally feel free to open new issue, even if they haven't followed any of the suggestions above :)

Required Info

Camera Model
D435

Firmware Version
<IP_ADDRESS>

Operating System & Version
Linux (Debian 4.19.152-1)

Kernel Version (Linux Only)
4.19.0-12-rt-amd64

Platform
PC

SDK Version
2.50.0

Language

Segment
Robot

Issue Description
Hello,
my kernel.log is flooded with the following messages:
input: Intel(R) RealSense(TM) Depth Ca as /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.3/2-3.3.2/2-3.3.2:1.0/input/input490
uvcvideo: Unknown video format 00000050-0000-0010-8000-00aa00389b71
uvcvideo: Found UVC 1.50 device Intel(R) RealSense(TM) Depth Camera 435  (8086:0b07)
uvcvideo: Unable to create debugfs 2-12 directory.
uvcvideo 2-3.3.2:1.0: Entity type for entity Intel(R) RealSense(TM) Depth Ca was not initialized!
uvcvideo 2-3.3.2:1.0: Entity type for entity Processing 2 was not initialized!
uvcvideo 2-3.3.2:1.0: Entity type for entity Camera 1 was not initialized!
The repetition rate is 2Hz.
I noticed that this behaviour only occurs when I set the option enable_depth = false.
In rare cases it happens that my system freezes and the following message is stored in the kernel:
BUG: unable to handle kernel paging request at fffff23aa82f1224
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 3 PID: 23636 Comm: nodelet Tainted: G           OE     4.19.0-12-rt-amd64 #1 Debian 4.19.152-1
Hardware name: CINCOZE DI-1000/DI-1000, BIOS 5.11 01/19/2019
RIP: 0010:__kmalloc_track_caller+0xa5/0x250
How can this behaviour be explained?

Hi @gc-91 I note that you are using kernel 4.19.  The librealsense SDK does not have official support for 4.19.

Whilst librealsense can work with kernels that are not officially supported, there may be unpredictable consequences in regard to stability.
If librealsense is built from source code with CMake using the RSUSB backend installation method then you should be able to continue using 4.19, as an RSUSB-based librealsense build is not dependent on Linux versions or kernel versions and does not require patching.  Instructions for building librealsense with the RSUSB method can be found at https://github.com/IntelRealSense/librealsense/issues/9931#issuecomment-964289692

Alternatively, if ROS works correctly for you already so long as depth is True then a simpler workaround may be to allow depth to be published by having it set to True but configure it to a low setting such as 424x240 at 15 FPS so that it adds a minimal burden to overall processing.

Hello MartyG,
Thanks for your message.
I had already built the librealsense from source, including RSUSB backend option.
You are right, I use the camera in ROS. So I will implement your low-setting suggestion.
However, I am still concerned that the system can freeze.
Can you deduce anything from the kernel message that was dropped just before the freeze?

In the freeze log, the 4th line says "Comm: nodelt...".
I use nodelt exclusively for the operation of the Realsense.
Furthermore, you can see in the call trace that the modules usbcore and uvcvideo are involved. Therefore, I believe that there must be a connection to Realsense.
After a bit of research, I came across the following article:
https://googleprojectzero.blogspot.com/2021/10/how-simple-linux-kernel-memory.html
The ioctl system call also appears frequently in my call trace.

If librealsense is built with the RSUSB backend that bypasses video4linux and and communicates with the device using generic USB driver then it should not be experiencing kernel related conflicts.
usbcore and uvcvideo are general Linux kernel modules and not specific to RealSense.
Can you confirm please that you did not patch the kernel before building librealsense from source code with RSUSB, since - unlike a non-RSUSB source code build - kernel patching is not required with this method.

Hello,
thank you for your message.
In the meantime, I have checked the installation.
However, in order to be able to perform a build as described by you under #9931, I have to install the following packages beforehand:

libusb-1.0-0-dev
libglu1-mesa-dev
glfw
Otherwise the code cannot be compiled. Otherwise,
I have not installed any kernel patches.

I did try and compile the code with RSUSB-backend = false, the D435 still worked.
If I understand your last message correctly, video4linux is now used or?
How can I find out which kernel modules the camera uses? I have already checked with lsmod all modules for a connection with the Realsense, unfortunately without result.
For your information, I only use my system via the cli, so I cannot use applications such as the realsense viewer.

If  DFORCE_RSUSB_BACKEND=OFF is used in the CMake build instruction then the V4L2 backend (which will make use of video4linux) will be used in the librealsense build.
If you go to https://github.com/IntelRealSense/librealsense/issues/5212#issuecomment-552184604 and scroll down through the linked-to comment to the section headed What are the advantages and disadvantages of using libuvc vs patched kernel modules then there is a comparison of the advantages and disadvantages of RSUSB backend (formerly known as libuvc backend) versus a patched-kernel build.
Regarding the precise kernel modules that the camera uses, I am uncertain about this question (I am not an SDK developer) but the list of module 'inserts' in the SDK's patch script may be a useful reference.
https://github.com/IntelRealSense/librealsense/blob/master/scripts/patch-realsense-ubuntu-lts.sh#L292-L311

Hello Marty,
thanks for the information now I have a better understanding about the RSUSB_BACKEND flag.
I have now freshly set up my system, I have installed the librealsense according to your instructions (#9931). Before that, of course, I provided the necessary packages (libusb-1.0-0-dev, libglu1-mesa-dev, gffw). The compile flag RSUSB_BACKEND is ON.
I also adjusted the configuration and set enable_depth = true, including the lower resolution (424x240) and 15 fps.
Furthermore, I managed to clean up the tainted kernel, it was due to the aufs storage driver of docker. After switching to overlay2, the kernel is no longer tainted.
Nevertheless, I had a system freeze this morning when I started the realsense ROS node with Nodelt. Here is an excerpt from /var/log/messages:

uvcvideo: Unknown video format 00000050-0000-0010-8000-00aa00389b71
uvcvideo: Found UVC 1.50 device Intel(R) RealSense(TM) Depth Camera 435  (8086:0b07)
uvcvideo: Unable to create debugfs 2-18 directory.
uvcvideo 2-4.3.3:1.0: Entity type for entity Intel(R) RealSense(TM) Depth Ca was not initialized!
uvcvideo 2-4.3.3:1.0: Entity type for entity Processing 2 was not initialized!
uvcvideo 2-4.3.3:1.0: Entity type for entity Camera 1 was not initialized!
input: Intel(R) RealSense(TM) Depth Ca as /devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.3/2-4.3.3/2-4.3.3:1.0/input/input773
uvcvideo: Unknown video format 00000050-0000-0010-8000-00aa00389b71
uvcvideo: Found UVC 1.50 device Intel(R) RealSense(TM) Depth Camera 435  (8086:0b07)
uvcvideo: Unable to create debugfs 2-18 directory.
uvcvideo 2-4.3.3:1.0: Entity type for entity Intel(R) RealSense(TM) Depth Ca was not initialized!
uvcvideo 2-4.3.3:1.0: Entity type for entity Processing 2 was not initialized!
uvcvideo 2-4.3.3:1.0: Entity type for entity Camera 1 was not initialized!
input: Intel(R) RealSense(TM) Depth Ca as /devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.3/2-4.3.3/2-4.3.3:1.0/input/input774
uvcvideo: Unknown video format 00000050-0000-0010-8000-00aa00389b71
uvcvideo: Found UVC 1.50 device Intel(R) RealSense(TM) Depth Camera 435  (8086:0b07)
uvcvideo: Unable to create debugfs 2-18 directory.
uvcvideo 2-4.3.3:1.0: Entity type for entity Intel(R) RealSense(TM) Depth Ca was not initialized!
uvcvideo 2-4.3.3:1.0: Entity type for entity Processing 2 was not initialized!
uvcvideo 2-4.3.3:1.0: Entity type for entity Camera 1 was not initialized!
input: Intel(R) RealSense(TM) Depth Ca as /devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.3/2-4.3.3/2-4.3.3:1.0/input/input775
uvcvideo: Unknown video format 00000050-0000-0010-8000-00aa00389b71
uvcvideo: Found UVC 1.50 device Intel(R) RealSense(TM) Depth Camera 435  (8086:0b07)
uvcvideo: Unable to create debugfs 2-18 directory.
uvcvideo 2-4.3.3:1.0: Entity type for entity Intel(R) RealSense(TM) Depth Ca was not initialized!
uvcvideo 2-4.3.3:1.0: Entity type for entity Processing 2 was not initialized!
uvcvideo 2-4.3.3:1.0: Entity type for entity Camera 1 was not initialized!
input: Intel(R) RealSense(TM) Depth Ca as /devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.3/2-4.3.3/2-4.3.3:1.0/input/input776
uvcvideo: Unknown video format 00000050-0000-0010-8000-00aa00389b71
uvcvideo: Found UVC 1.50 device Intel(R) RealSense(TM) Depth Camera 435  (8086:0b07)
uvcvideo: Unable to create debugfs 2-18 directory.
uvcvideo 2-4.3.3:1.0: Entity type for entity Intel(R) RealSense(TM) Depth Ca was not initialized!
uvcvideo 2-4.3.3:1.0: Entity type for entity Processing 2 was not initialized!
uvcvideo 2-4.3.3:1.0: Entity type for entity Camera 1 was not initialized!
input: Intel(R) RealSense(TM) Depth Ca as /devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.3/2-4.3.3/2-4.3.3:1.0/input/input777
uvcvideo: Unknown video format 00000050-0000-0010-8000-00aa00389b71
uvcvideo: Found UVC 1.50 device Intel(R) RealSense(TM) Depth Camera 435  (8086:0b07)
uvcvideo: Unable to create debugfs 2-18 directory.
uvcvideo 2-4.3.3:1.0: Entity type for entity Intel(R) RealSense(TM) Depth Ca was not initialized!
uvcvideo 2-4.3.3:1.0: Entity type for entity Processing 2 was not initialized!
uvcvideo 2-4.3.3:1.0: Entity type for entity Camera 1 was not initialized!
input: Intel(R) RealSense(TM) Depth Ca as /devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.3/2-4.3.3/2-4.3.3:1.0/input/input778
uvcvideo: Unknown video format 00000050-0000-0010-8000-00aa00389b71
uvcvideo: Found UVC 1.50 device Intel(R) RealSense(TM) Depth Camera 435  (8086:0b07)
general protection fault: 0000 [#1] PREEMPT SMP PTI
CPU: 2 PID: 7515 Comm: nodelet Not tainted 4.19.0-12-rt-amd64 #1 Debian 4.19.152-1
Hardware name: CINCOZE DI-1000/DI-1000, BIOS 5.11 01/19/2019
RIP: 0010:__kmalloc+0xaa/0x250
Code: 48 8b 70 08 48 39 f2 75 e7 48 83 78 10 00 48 8b 28 0f 84 3d 01 00 00 48 85 ed 0f 84 34 01 00 00 41 8b 47 20 49 8b 3f 48 01 e8 <48> 8b 18 48 89 c1 49 33 9f 30 01 00 00 48 89 e8 48 0f c9 48 31 cb
RSP: 0018:ffffa567421afad0 EFLAGS: 00010286
RAX: ffff6af652604e87 RBX:<PHONE_NUMBER>000000 RCX:<PHONE_NUMBER>026660
RDX: 00000000bec69802 RSI: 00000000bec69802 RDI:<PHONE_NUMBER>026660
RBP: ffff6af652604e87 R08: ffffffffc04cddc0 R09: ffff9474db578ea0
R10: ffff94755e863b94 R11:<PHONE_NUMBER>000001 R12:<PHONE_NUMBER>6080c0
R13:<PHONE_NUMBER>00000d R14: ffff947565403b00 R15: ffff947565403b00
FS:  00007f0993fff700(0000) GS:ffff947565b00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0:<PHONE_NUMBER>050033
CR2: 000055fb8cf5f280 CR3: 00000001fe590001 CR4:<PHONE_NUMBER>3606e0
DR0:<PHONE_NUMBER>000000 DR1:<PHONE_NUMBER>000000 DR2:<PHONE_NUMBER>000000
DR3:<PHONE_NUMBER>000000 DR6: 00000000fffe0ff0 DR7:<PHONE_NUMBER>000400
Call Trace:
? uvc_ctrl_add_info+0x57/0xa0 [uvcvideo]
uvc_ctrl_add_info+0x57/0xa0 [uvcvideo]
uvc_ctrl_init_device+0x2c0/0x360 [uvcvideo]
uvc_probe.cold.18+0x198/0xc59 [uvcvideo]
? usb_probe_interface+0xea/0x300 [usbcore]
? uvc_register_video_device+0x120/0x120 [uvcvideo]
usb_probe_interface+0xea/0x300 [usbcore]
really_probe+0x20a/0x3b0
? __driver_attach+0x110/0x110
driver_probe_device+0xb3/0xf0
? __driver_attach+0x110/0x110
bus_for_each_drv+0x79/0xc0
__device_attach+0xe5/0x160
proc_ioctl+0x1b6/0x230 [usbcore]
usbdev_do_ioctl+0x270/0x1110 [usbcore]
? hrtimer_try_to_cancel+0x29/0x150
? hrtimer_cancel+0x1b/0x30
? do_nanosleep+0x42/0x160
usbdev_ioctl+0xa/0x10 [usbcore]
do_vfs_ioctl+0xa4/0x630
? __hrtimer_init_sleeper+0x60/0x60
ksys_ioctl+0x60/0x90
__x64_sys_ioctl+0x16/0x20
do_syscall_64+0x53/0x110
entry_SYSCALL_64_after_hwframe+0x44/0xa9

The messages:

input: Intel(R) RealSense(TM) Depth Ca as /devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.3/2-4.3.3/2-4.3.3:1.0/input/input776
uvcvideo: Unknown video format 00000050-0000-0010-8000-00aa00389b71
uvcvideo: Found UVC 1.50 device Intel(R) RealSense(TM) Depth Camera 435  (8086:0b07)
uvcvideo: Unable to create debugfs 2-18 directory.
uvcvideo 2-4.3.3:1.0: Entity type for entity Intel(R) RealSense(TM) Depth Ca was not initialized!
uvcvideo 2-4.3.3:1.0: Entity type for entity Processing 2 was not initialized!
uvcvideo 2-4.3.3:1.0: Entity type for entity Camera 1 was not initialized!

Are no longer permanently written to the system logs at 2Hz after switching from enable_depth= false to enable_depth = true, but only during the startup process of the realsense node.
I suspect that something is wrong while the logs are being written, and it can therefore lead to a freeze in rare cases.
Since the number of messages has now been reduced by the above-mentioned parameter adjustment, the probability of a freeze also decreases. However, since it can still lead to a freeze, I would like to know exactly what the logs say.  Can you send me more information on this?

You could test the theory about whether logging causes the freeze by disabling all ROS logging using the information in the link below.
http://wiki.ros.org/rosconsole#Disable_all_logging
Have you previously built librealsense from packages instead of source code on the same computer?  If you have then I wonder whether there may be multiple udev rules installed on your computer that are causing a conflict.  A warning message about multiple udev rules would normally be displayed in the RealSense Viewer, but you are not using the Viewer because of your CLI environment.
If there is an udev rule present on your computer at the location /etc/udev/rules.d/ then deleting it from your computer automatically corrects the multiple udev rules conflict without you needing to check in the RealSense Viewer.

Hi Marty,
thanks for the suggestion to disable the ROS logs, however I wanted to know what is the cause of the posted kernel logs.
I have NOT installed librealsense from the packages before, but built it directly from source. Nevertheless, I found udev-rules in both places (/etc.. and /lib/..). However, the one under /lib/... is called 60-ros-noetic-realsense2-camera.rules.
I load the Realsense-ROS-Node from the packages, could this be the cause?
I removed the udev-rule from /etc/... and received a freeze immediately after the reboot and start the realsense2_rgb.launch, but this time with a different error pattern in the kernel logs:

general protection fault: 0000 [#1] PREEMPT SMP PTI
CPU: 2 PID: 2614 Comm: systemd-udevd Not tainted 4.19.0-12-rt-amd64 #1 Debian 4.19.152-1
Hardware name: CINCOZE DI-1000/DI-1000, BIOS 5.11 01/19/2019
RIP: 0010:__kmalloc_track_caller+0xa5/0x250

After a repeated reboot, the system ran without the udev-rule under /etc/..

The RealSense ROS packages in the wrapper's Method 1 instructions install both librealsense and the ROS wrapper together.  So if you installed librealsense from source code and then afterwards installed the wrapper from packages with Method 1 then you could end up with a potentially conflicting setup of two librealsense versions on the same computer that were built with different methods (source code and packages).
You could deal with the conflict by uninstalling all RealSense related packages on your computer using the instruction below.
dpkg -l | grep "realsense" | cut -d " " -f 3 | xargs sudo dpkg --purge
This instruction would only affect packages, so the source-code build of librealsense should be left in place afterwards.
If installing the ROS wrapper from the Method 1 packages is the most familiar and comfortable installation method for you, then you could try the following procedure.

Delete the librealsense source-code build by going to the build directory of the librealsense folder and running the CMake command below: to uninstall librealsense and clean the CMake cache

sudo make uninstall && make clean

Install librealsense and the ROS wrapper together from packages with Method 1.

Thanks for the tip, I was not aware that librealsense is also installed from the packages when installing the ROS wrapper from the packages.
I have now rebuilt my system and built both librealsense and the ROS wrapper from source. (Since my kernel version is not supported, I'm not allowed to use method 1, am I?).
The startup process of the wrapper is now much faster, but when I exit the wrapper and restart, I still get the following entries in the kernel log:

WARNING: CPU: 3 PID: 1246 at drivers/media/v4l2-core/v4l2-ioctl.c:1342 v4l_enum_fmt+0xfd5/0x13a0 [videodev]
Modules linked in: can_bcm can xt_conntrack ipt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo nft_counter xt_addrtype nft_compat nft_chain_nat_ipv4 nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c nf_tables nfnetlink br_netfilter bridge stp llc sr_mod cdrom overlay cpufreq_userspace cpufreq_conservative cpufreq_powersave snd_hda_codec_hdmi uas usb_storage snd_hda_codec_realtek intel_rapl snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp ftdi_sio usbserial coretemp kvm_intel snd_soc_skl snd_soc_skl_ipc kvm snd_soc_sst_ipc snd_soc_sst_dsp irqbypass snd_hda_ext_core crct10dif_pclmul snd_soc_acpi_intel_match crc32_pclmul snd_soc_acpi ghash_clmulni_intel snd_soc_core intel_cstate snd_compress snd_hda_intel intel_uncore snd_hda_codec snd_hda_core intel_rapl_perf
snd_hwdep snd_pcm snd_timer iTCO_wdt pcspkr i915 snd mei_wdt iTCO_vendor_support soundcore idma64 uvcvideo peak_pci sg videobuf2_vmalloc sja1000 drm_kms_helper videobuf2_memops evdev can_dev videobuf2_v4l2 mei_me videobuf2_common drm mei intel_pch_thermal videodev media pcc_cpufreq video wmi acpi_pad button ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb sd_mod crc32c_intel xhci_pci ahci xhci_hcd libahci aesni_intel igb aes_x86_64 crypto_simd libata intel_lpss_pci i2c_algo_bit cryptd usbcore intel_lpss glue_helper dca e1000e i2c_i801 scsi_mod fan mfd_core usb_common thermal
CPU: 3 PID: 1246 Comm: nodelet Not tainted 4.19.0-12-rt-amd64 #1 Debian 4.19.152-1
Hardware name: CINCOZE DI-1000/DI-1000, BIOS 5.11 01/19/2019
RIP: 0010:v4l_enum_fmt+0xfd5/0x13a0 [videodev]

This entry is output 16 times in a row and is followed by the following message, which appears about 100 times in a row:

input: Intel(R) RealSense(TM) Depth Ca as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.3/1-1.3.3/1-1.3.3:1.0/input/input13
uvcvideo: Unknown video format 00000050-0000-0010-8000-00aa00389b71
uvcvideo: Found UVC 1.50 device Intel(R) RealSense(TM) Depth Camera 435  (8086:0b07)
uvcvideo: Unable to create debugfs 1-7 directory.
uvcvideo 1-1.3.3:1.0: Entity type for entity Intel(R) RealSense(TM) Depth Ca was not initialized!
uvcvideo 1-1.3.3:1.0: Entity type for entity Processing 2 was not initialized!
uvcvideo 1-1.3.3:1.0: Entity type for entity Camera 1 was not initialized!

Therefore, I suspect that I can expect a freeze again after a few reboots.
The ROS wrapper also writes the following warnings during the start-up process and during operation:

(messenger-libusb.cpp:42) control_transfer returned error, index: 768, error: Resource temporarily unavailable, number: 11

Correct, kernel 4.19 is not listed as an officially supported kernel as mentioned earlier in this discussion at https://github.com/IntelRealSense/librealsense/issues/10158#issuecomment-1014712023
The messages look to me likethey might be caused by an unpatched kernel.  When you built librealsense from source code this time, did you build using the RSUSB backend method in order to make the build non-dependent on the kernel version?

Yes I built it with RSUSB-BACKEND = ON, just like you described it here #9931 (comment).

Hello I have tested the 2.50.0 with the wrapper 2.3.2 further, almost every 3 start of the wrapper my system freezes.
I have the same behaviour with librealsense 2.48.0 and 2.3.1.
The behaviour is always the same, during the start process the following log is written cyclically 91 times:

input: Intel(R) RealSense(TM) Depth Ca as /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1.3/2-1.3.3/2-1.3.3:1.0/input/input91
uvcvideo: Unknown video format 00000050-0000-0010-8000-00aa00389b71
uvcvideo: Found UVC 1.50 device Intel(R) RealSense(TM) Depth Camera 435  (8086:0b07)
uvcvideo: Unable to create debugfs 2-8 directory.
uvcvideo 2-1.3.3:1.0: Entity type for entity Intel(R) RealSense(TM) Depth Ca was not initialized!
uvcvideo 2-1.3.3:1.0: Entity type for entity Processing 2 was not initialized!
uvcvideo 2-1.3.3:1.0: Entity type for entity Camera 1 was not initialized!

Can you please give me hints about these logs? Is it usual that these messages occur? Is it also usual that they occur so frequently? What exactly do the messages say?
After that I can receive pictures from the camera.
Sometimes the start does not succeed and the system freezes. The last thing in the log are numerous RIP messages. The first one looks like this:

general protection fault: 0000 [#1] PREEMPT SMP PTI
CPU: 0 PID: 3807 Comm: nodelet Not tainted 4.19.0-12-rt-amd64 #1 Debian 4.19.152-1
Hardware name: CINCOZE DI-1000/DI-1000, BIOS 5.11 01/19/2019
RIP: 0010:__kmalloc_node_track_caller+0x1ca/0x2f0

Do you see any improvement if you reload the udev rules by entering the commands below into your Ubuntu terminal?
sudo udevadm control --reload-rules
sudo udevadm trigger

Hello, no unfortunately the commands do not help.

If you have tried most other possible fixes without success, a complete wipe and reinstall of the computer (including the OS) may sometimes clear a problem with a RealSense installation without finding out what was causing the problem.

Hi Marty,
since I use the librealsense and ros-wrapper inside a Docker container, I have tested each of your suggestions in a fresh build container.
For info, my container is running with the options privileged: true and network_mode: host
Unfortunately you didn't address the question about kernel logs in my penultimate post, could you please answer my questions?

It is difficult to provide an answer about the meaning of the 'entity type' kernel messages, since their cause tends to be vague and if they are corrected then you may never find out for sure what caused them in the first place.  I enquired to Intel about them in 2020 and received the following explanation.

The message “Entity camera * not initialized" is related to UVC topology defined in the firmware descriptor for USB device.
Those are protocol-specific messages and are apparently stemmed from firmware, but since there are no observed misbehaviors reported and we have them from day 1 with D400, it is likely to remain that way for a while.

Hi @gc-91  Do you require further assistance with this case, please?  Thanks!

Hi Marty,
In the meantime I have carried out further tests on my system and have been able to locate the reason for my freezes.
Basically, it is as you had already suspected, namely that several variants / versions of librealsense had been installed on my system. The reason for the multiple installations was the use of rosdep install.
I had used rosdep install because the wrapper needs additional dependencies to build from source. Unfortunately, rosdep install cannot detect that librealsense already built from source is installed on the system and simply installs the latest version from the packages to it.
Therefore, I can recommend either installing the necessary dependencies for the ros-wrapper manually or adapting rosdep install and excluding librealsense.
Then the previously installed librealsense will also be used and there will be no spam in the kernel and consequently no system freeze.

It's excellent to hear that you found an answer.  Thanks very much for the update and for sharing the details with the RealSense community  :)


Support composition of arbitrarily many CallCredentials objects

Thanks much for the PR. LGTM for the API (please address the comments on documentation though).

Thank you for the careful reading; fixed all and fixed the commit message typo too. Back to you.

lgtm


runtime: Windows service timeout during system startup

What version of Go are you using (go version)?
go version go1.9.2 windows/amd64
Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (go env)?
set GOARCH=amd64
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Users\XXXXX\d\go
set GORACE=
set GOROOT=C:\Go
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\XXXXX\AppData\Local\Temp\go-build933228923=/tmp/go-build -gno-record-gcc-switches
set CXX=g++
set CGO_ENABLED=1
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config

What did you do?
Configured our Go language application to start as a Windows Service, with start type of 'Automatic'. The service is expected to start when the system boots up. Sometimes the service process will not be running after the system has booted up and the 'Windows Logs / 'System' logs in Event Viewer show two logs:
Event ID: 7009
Level: Error
Text:
A timeout was reached (30000 milliseconds) while waiting for the <service name> service to connect.

Event ID: 7000
Level: Error
Text:
The <service name> service failed to start due to the following error:
The service did not respond to the start or control request in a timely fashion.

These events do not appear in the logs when the service successfully starts.
It appears that Windows terminates the service process when the service fails to respond to the Windows Service start event within the 30 s time frame. Our application contains the Windows Service code based on the sample code from sys/windows/svc/example.
This timeout issue occurs both with 64-bit and 32-bit versions of our executable.
What did you expect to see?
The Go language Windows service start reliably every time the system boots up.
What did you see instead?
The Go language service does not start reliably on some systems on boot-up.
Some observations from systems where the service often fails to start during boot-up:

Manually starting the service once the system is up and running has never failed to start correctly. Timestamps from the logs show the process starting quickly (no more than a few seconds).
Setting the service's start type to 'Automatic (Delayed Start)', where Windows starts the service 120 s after the 'Automatic' services, works without fail. The user is able to login to the desktop well before the service has been started. It is possible to change this global Windows setting to a lower value (eg 60 s) to make it less noticeable to the user, but because it will affect all delayed start services, it is not an acceptable solution. Some search results claim a per-service delay value can be specified, but we were not able to make this work.
Changing the 30000 ms (30 s) Windows service timeout value to larger values (60 s or 90 s) allowed the service to startup. However, this is a global Windows setting and it is not possible to set the timeout per-service. Again, this is not an acceptable solution.
We experimented with using the Windows Service "Recovery" settings to restart our service in an attempt to mitigate this problem. However, it appears that these recovery settings have no effect for services that fail to start in time.
We instrumented our service with timestamped logs when the first imported package is initialized and when main() starts. We found that main() was often not reached when the timeout occurred. Sometimes even the first imported package's initialization was not reached.
A stripped-down Windows service that just logged would often fail to start, but it was less likely to happen compared to our full-fledged service.
Using a simple C++ Windows Service (code here) modified to launch our executable (running as a 'normal' application, not as a Windows Service) always launched without fail (no timeouts) during boot-up. Logs within our executable, as well as in the C++ service (just prior to the CreateProcess() call that started our executable) often showed large time deltas. The logs indicated it often took a long time for the Go executable to get launched, and also to reach the main().

While we have some systems (VirtualBox VMs) that reliably show these startup problems, the issue is harder to reproduce on other systems. We have VirtualBox VMs where the problem occurs only occasionally and we have yet to see the timeout occur on non-virtual Windows 10 installations. Timestamp-instrumented loads on those systems sometimes show time deltas of up to 10 s during startup. While this is not long enough to trigger the 30 s timeout on a powerful real system, the concern is that in virtualized environments and/or slower systems the timeout will be reached and the service will not start.
Sample Programs
Sample code can be found in this GitHub repository, including instructions for building and installing (README.md).
Both the launchserv.exe and winserv.exe programs contain the Go Windows Service code (again, based one the sample code). The Go Windows Service sample code was combined into a single file in both cases in order to 'flatten' the main package for tracking imported package initialization.
It is intended that only one of the two should run as a Windows Service. The recommended configuration is to install launchserv.exe as a Windows Service ("my service"), and it will in turn launch winserv.exe as a child process (winserv.exe will run as a 'normal' program, not a service). launchserv.exe writes a timestamped log just prior to starting winserv.exe, which allows measuring the time it takes for winserv.exe to start.
winserv.exe contains a large number of standard package imports, to mimic a real program. These imports are marked as 'unused' and as such only their initializations run (variable initialization and init()).
The VirtualBox version of the Win10 MSEdge test VM can be downloaded from Microsoft here to run these test programs. The following changes may help to increase the likelihood of seeing the issue with this, or other systems:

Increase the number of CPU cores from 1 (to say 2 or 4). This might increase the concurrent activity when the system is starting up.
Install the Guest Additions.
Install other software that starts services when the system boots. For example, one VM that shows the issue very reliably has two VNC server packages, OpenVPN client and an SSL VPN client (Array Networks) (as well as other software) installed.

Multiple boot-ups of the system may be required to see the problem. In many cases, a VM may sometimes demonstrate the problem, but then not do so at other times. YMMV.
When delays are seen, the two most common places are:

Launching winserv.exe; that is, between the last launchserv.exe log and the first winserv.exe log. Time deltas as high as 26 s have been seen (and as low as less than 400 ms) have been seen on an Win10/MSEdge VM.
The 'lots of imports' in winserv.exe main.go, between the 'b' and 'c' logs. These are the large number of unused standard package imports. Times as high as 9 s (and less than 100 ms on the low end) have been seen on the same Win10/MSEdge VM.

This service is an important component of our product; we are adding more functionality all the time. As the amount of code increases, it seems even more likely that this problem will occur. If there is anything else we can do to help resolve this issue (experiments, measurements, debugging, etc), please let us know.

I instrumented the earlier runtime initialization calls, with more focus on the middle of schedinit as some preliminary runs pointed to there. Since calls to println didn't work in the earlier calls, all of the timestamps up to and including those in schedinit are output together at the end of that function (after the schedinit exit timestamp is recorded). The 'schedinit() print time' captures how long it takes for these 15 println calls, in case that introduced any significant delay.
The results are in the second tab of the Google Sheets spreadsheet. Six of the boot-ups had significant times in the newly instrumented code:

boot 5: osinit, schedinit/mcommoninit, & schedinit/itabsinit
boot 6: schedinit/itabsinit
boot 18: schedinit after gcinit (until end of function)
boot 23: schedinit/itabsinit
boot 31: schedinit/mcommoninit
boot 35: schedinit/mcommoninit, schedinit/modulesinit, & schedinit/itabsinit

Other boot-ups either had delays elsewhere, or none of significance.
Seems similar to the previous results, with there being locations in the code where delays are more likely to happen than others, but they don't happen in these places all the time.

Seems similar to the previous results

Indeed.
I have nothing else that helps you. Sorry.
Alex

Does your binary use cgo? If so, can you try commenting out anything that depends on cgo and see if you still those random delays? Also, if that's not the case, you can still try dropping parts of your binary (like, entire packages commenting out functionalities) and see if you can bisect what causes the initial delay as side effect. I'm assuming this is something specific to your binary and not all Windows go binaries of course.
Which DLLs your binary depend on? You can use a tool like DependencyWalker to see a complete list of dependencies.

Which DLLs your binary depend on? You can use a tool like DependencyWalker to see a complete list of dependencies.
That's good question - if your service executable is depending on anything network related then you might experience such delays (because of complexities how TCP-stack is getting up'n'running). Either mark your service as "Delayed start" or remove TCP-related code from the stages which send Windows control service signal that it's up.

Our actual application does not use CGo. Nor does the sample winserv program I have put on GitHub (basic Windows service with a lot of unused imports and some timestamped logging).
Using DependencyWalker on winserv takes almost 2 minutes to analyze the binary and shows a large tree with three top-level DLLS: WINMM.DLL, WS2_32.DLL, & KERNEL32.DLL. Feeding it a simple Go Hello World (just fmt.Println()) gives a similar result, at least time terms of analysis time, top-level DLLs, and functions listed. There are also a number of errors reported for both executables, including being unable to open many DLL files and the following (this is from the gohello.exe, but is the same for winserv.exe):
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
Error: A circular dependency was detected.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

Is there anything specific in the DependencyWalker results I should be looking for?
When I use dumpbin /imports (VS2015) for those two executables, it shows the same three top-level DLLs and functions as DependencyWalker. The output for the two programs is the same, except for the addresses:
Copyright (C) Microsoft Corporation.  All rights reserved.

Dump of file c:\Users\liveqos\d\gohello\gohello.exe

File Type: EXECUTABLE IMAGE

  Section contains the following imports:

    winmm.dll
                52A000 Import Address Table
                5DD2E6 Import Name Table
                     0 time date stamp
                     0 Index of first forwarder reference

                           0 timeEndPeriod
                           0 timeBeginPeriod

    ws2_32.dll
                52A018 Import Address Table
                5DD2FE Import Name Table
                     0 time date stamp
                     0 Index of first forwarder reference

                           0 WSAGetOverlappedResult

    kernel32.dll
                52A028 Import Address Table
                5DD30E Import Name Table
                     0 time date stamp
                     0 Index of first forwarder reference

                           0 WriteFile
                           0 WriteConsoleW
                           0 WaitForSingleObject
                           0 VirtualFree
                           0 VirtualAlloc
                           0 SwitchToThread
                           0 SetWaitableTimer
                           0 SetUnhandledExceptionFilter
                           0 SetProcessPriorityBoost
                           0 SetEvent
                           0 SetErrorMode
                           0 SetConsoleCtrlHandler
                           0 LoadLibraryA
                           0 LoadLibraryW
                           0 GetSystemInfo
                           0 GetStdHandle
                           0 GetQueuedCompletionStatus
                           0 GetProcessAffinityMask
                           0 GetProcAddress
                           0 GetEnvironmentStringsW
                           0 GetConsoleMode
                           0 FreeEnvironmentStringsW
                           0 ExitProcess
                           0 DuplicateHandle
                           0 CreateThread
                           0 CreateIoCompletionPort
                           0 CreateEventA
                           0 CloseHandle
                           0 AddVectoredExceptionHandler

  Summary

       32000 .data
        1000 .debug_abbrev
        1000 .debug_aranges
       13000 .debug_frame
        1000 .debug_gdb_scripts
       47000 .debug_info
       11000 .debug_line
        A000 .debug_pubnames
        9000 .debug_pubtypes
        1000 .idata
       23000 .symtab
      129000 .text

I am having the exact same problem using Go to generate a windows service.
I can reproduce the problem at will; and, in fact, since my executable can be run as a service or standard console application, I have some additional findings

Delay appears only in the first execution.  After that, whatever is the bottleneck appears to be cached?  2nd through Nth execution, application intializes/runs in ~1sec
Delay appears while disk is being heavily used.  If I just wait for the machine to boot, and then wait a few minutes for the disk activity to die away, and then attempt the first execution, it runs fine
starting immediately results in a variable delay of between 45 sec and 2 minutes.
same result building in release mode.

I assume 'debug' and 'release' refer to with and without debug symbols (go build -ldflags "-s -w" for the latter). If that is the case, then all Go binaries I was building were with debug symbols.
I rebuilt our application with those link flags, which resulted in a Windows executable that was about 1/3 smaller. However, it behaved the same as before, timing out when starting as a normal Windows service at boot-up.

I think the correct way to solve this would be to build the service support into the runtime.
A Windows service can be pending starting without be cancelled after sending a SERVICE_START_PENDING message:

A ServiceMain function first calls the RegisterServiceCtrlHandlerEx function to get the service's SERVICE_STATUS_HANDLE. Then it immediately calls the SetServiceStatus function to notify the service control manager that its status is SERVICE_START_PENDING. During initialization, the service can provide updated status to indicate that it is making progress but it needs more time. ... see reference

The next step could be to write a proposal for this. However having these kind of changes is probably hard getting approved and it won't release before Feb 2019.
On the other hand, there a quite a lot good service wrappers out there.

Part of the problem won't be solved by building service support into the runtime, at least not without some very specific modifications.
Since, in Go, each package can have an init function which is called prior to main, if the init functions take long enough, then Windows will give up before the application could ever send SERVICE_START_PENDING.

@derekwbrown I think the point here would be to hook into the service manager before firing up the runtime... before "runtime/proc.go main()" but inside the system's entry point (main/WinMain).

@fkollmann I understand that; however, even if your service hooked into the service manager during its own init, the fact that any vendored dependencies inits can run for an arbitrary amount of time makes it problematic.
Unless you're talking about changing the language to have a service-init() that occurs before init()...

As far as I know, This problem should be fixed by calling SetServiceStatus on regular intervals. And the interval can be changed on registory.

I think it should be implemented directly into the OS main() function. You need specific functions anyway (see servicemain()).
I would suggest the following steps:

Accept the constrain for SERVICE_WIN32_OWN_PROCESS services, only (no SERVICE_WIN32_SHARE_PROCESS  support, which is barely used and I think not even fully supported by current Go/x)

Connect to service manager during main() by calling StartServiceCtrlDispatcher() and set status to SERVICE_START_PENDING for 2 minutes by calling  SetServiceStatus()

If the program is not running as a service, StartServiceCtrlDispatcher() will return ERROR_FAILED_SERVICE_CONTROLLER_CONNECT

All status updates will be tracked in a global variable during that time (basically a service cannot receive any updates during startup, anyway)

Update status to SERVICE_START_PENDING for 5 minutes by calling SetServiceStatus() before runtime/package initialization

Have the developer call the service Run() code and pick-up the starting start and replace the handler (the change should be easy to make)

If the developer does not call service Run(), Windows will kill the process after 5 minutes

The service won't be receiving any device events before calling service Run()

@mattn I don't think that is a good idea. Microsoft explicitly discourages from doing this as it can keep the service stuck forever. I also think it's not required, as this is no heartbeat mechanism. You simply have to set an appropriate timeout.

@kneden @derekwbrown can you try https://golang.org/cl/110160 to see if it helps with your problem. Thank you.
Alex

I have not had a chance to try that; however, I read through the change.  I don't see how it would affect the fact that various init()s are called before the ServiceMain()

My logic here is, that if sArgv is garbage, then argv in service.run is slice of pointers to garbage. And argv is used to build args from garbage pointers. It is looking for utf16 0 at the end of utf16 string, and maybe it is not finding it. ...
But my fix would not affect 386.
Alex

Any new findings here? Im running in that same error.
One of my vendor packages loads windows dlls and therefore run in a timeout.
Any solutions so far? the only thing that i can do is so remove this one package who needs the dlls, but that is not an option.
what can i do? :(

Maybe its possible to build the go app "with" those dll?
so that windows do not need to load them "external"

When the delay issues occur during Windows start-up, it doesn't seem to make much difference whether the Go executable is running as the service itself, or launched by the another service.

Thank you for explaining.
Just an idea - I believe Docker is running as a Windows service. If that service executable is written in Go, how come they don't have problems like yours?
Alex

I am seeing exactly this issue(A timeout was reached (90000ms) while waiting for the Docker Engine service to connect) for docker on our machines now and then, and the timeout in our case is 90s.
I tried to enable docker debug mode whenever this issue happens, but nothing found from docker and it seems docker main hasn't been hit at all.
We built a docker monitor to help mitigate this issue whenever it happens, but ideally the root cause should be identified and fixed.

@alexbrainman, this issue only appears to show up (for me) if you are heavily disk I/O constrained.

this issue only appears to show up (for me) if you are heavily disk I/O constrained.

@adjackura
Do you have any suggestions on how I can reproduce it? What version of Go do you use? What is your program?
Grasping for straws.
Thank you.
Alex

From this thread it looks like even the simplest program will exhibit this, currently I am trying to repro myself from scratch in GCE. I have a repo (I didn't build the image though so not sure what was done) so I know its related to disk speed, but vanilla images don't have the issue. I think additional services need to be installed to slow boot down.

currently I am trying to repro myself from scratch in GCE.

That would be nice, if you can repro on GCE. What version of Go is your service built with?

I think additional services need to be installed to slow boot down.

What is your environment where this error happen to you? Does the error happens consistently?
Alex

I was unable to repro the timeout, but I was able to see the issue using Windows Performance Recorder and measuring boot performance. One a really low specced system (1CPU, really low IO limit) my service took 27s for container init time. One a system with higher specs it was only 1s. I also installed lots of random windows server features to further slow down the boot process.
Here is a link that talks about further digging into why service start is slow:
https://famellee.wordpress.com/2013/05/10/use-windows-performance-toolkit-to-trackdown-slow-service-start-problem/

I just submitted https://golang.org/cl/246317 change that can possibly fix this bug. Please, check, if you still can reproduce this bug after CL 246317 ?
Thank you.
Alex

Since no one replied to my comment last week, I will assume that
https://golang.org/cl/246317
fixes this. So I will close this issue.
Please, let me know, if I am wrong.
Thank you.
Alex

This issue is frustrating and I've seen it on busy Windows Server Core machines. One workaround for this issue is to edit the ServicesPipeTimeout timeout in Windows registry.
Another option for services is to change the startup type to Automatic (Delayed).

@alexbrainman can we reopen this issue?

@Jonathan727 , @Sigurthorb , have you been able to test with Alex's CL 246317?

Yes, we are seeing this issue even with Alex's CL 246317 fix in our vendor-ed sys package

Thanks. Reopening.

We're facing the same issue in our environment, could share a permanent workaround.

I encountered this problem, putting all DLL related initialization actions into init method solves my problem.

thinks https://github.com/shirou/gopsutil/issues/570


Why is this being converted to Base64

Hey, curious as to why updates are stored in Base64? Is it like a compression optimization?
Or maybe, this is initializing an array. Wasn't sure what the B property was
https://github.com/gaberogan/y-websocket-api/blob/53cff338dfce95e180b1b99d0fdddd72292c3e90/server/db/aws.js#L102

Oh, I think the B was just the DynamoDB attribute type of ByteArray.
Still messing around, I assume the updates might be coming in a B64 array?

Oh I think I understand more now.
Data from Yjs is encoded into an buffer array, and that's serialized into a B64 string, I assume to make the data transmission piece lighter.
encoding.toUint8Array(encoder)

@gaberogan  - I've been trying to add the update, but it keeps throwing an Integer out of Range exception. Weirdly, everytime I check the DB, all I see are AAEE==.
Instead of storing the binary type, I figured I'd just save the the string value of B64 string. But they all seem the same? Any ideas as to what I'm missing.
How should the updates attribute look like?
const updates = dbDoc.Updates.map(update => new Uint8Array(Buffer.from(update, 'base64')))

        console.log(updates);

        const ydoc = new Y.Doc()

        for(const update of updates){
            try{
                Y.applyUpdate(ydoc, update)
            }catch(ex){
                console.log("Something went wrong with applying the update!")
            }

        }

Found my mistake. Dumb 3 AM thing. I was passing the encoder as the serialized string, instead of the message array.


API based Recipe Website

API based Recipe Finder Website

This is my first ever PR for HacktoberFest2021. Please do help me out and accept it I am a beginner at open source. But still, I want to contribute so please do let me know about your take on my contribution

Please create a new directory called Web Projects and move ur project into that.


Server can't send sources to client

The file needs to be split up in smaller chunks and sent one part at a time.

Fixed.


Test against same version of Ruby that GitHub Pages uses

Tests are failing because we are trying to test with Ruby 1.9
/cc #133

@jekyllbot: merge +dev

@jekyllbot: merge +dev

@jekyllbot: merge

@jekyllbot: merge


Accessor: factorize metric name sanitation

Coverage decreased (-0.02%) to 81.563% when pulling e1bf2595fa7c1bbef3ee989fa3754703c6da008b on adericbourg:accessor_sanitize_name into 318781199e0dd0f997c6bb893e2211010bbb5c89 on criteo:master.


[pytorch-directml] As run a GNN model, meet "Segmentation fault".

This is the second time of this issue: https://github.com/microsoft/DirectML/issues/334
And you told me to try a lastest version to find whether the error will happen.
Then I have use the last version "torch-directml 0.1.13.dev221216", and errors still appear. But it changes.
My repositories is https://github.com/Looong01/Circuit-GNN-PyDml/blob/main/model.py.
The datatype is a kind of pickle object. Shapes of batch_norm is multilayer's nn.BatchNorm1d(512).
More details about datatype please see https://github.com/Looong01/Circuit-GNN-PyDml/blob/main/dataset.py
More details about batch_norm parameters please see https://github.com/Looong01/Circuit-GNN-PyDml/blob/main/model.py
The error info and more details shapes of batch_norm parameters are as follow:
Error info:
args
Namespace(exp='exp_1', data_root='..\data_root', use_gpu=True, len_hidden=400, len_hidden_predictor=512, len_node_attr=11, len_edge_attr=20, gnn_layers=4, dropout=0, num_workers=1, batch_size=256, lr=0.0002, resume_epoch=-1, epoch=501, num_resonator=4, circuit_type=2, phase='test', exp_folder='.\dump\exp_1', ckpt_folder='.\dump\exp_1\ckpt', train_folder='.\dump\exp_1\train', log_path='.\dump\exp_1\train.log')
model #params: 10713490
Train samples: [120000, 180000]
Valid samples: [15000, 22500]
0% (0 of 1173) |                                                               | Elapsed Time: 0:00:00 ETA:  --:--:--Traceback (most recent call last):
File "D:\Code\circuit-gnn\DirectML\train.py", line 240, in
train_loss, train_db = train(epoch)
File "D:\Code\circuit-gnn\DirectML\train.py", line 114, in train
pred = model(input=(node_attr, edge_attr, adj))
File "C:\Users\lizel\miniconda3\envs\Pydml\lib\site-packages\torch\nn\modules\module.py", line 1194, in _call_impl
return forward_call(*input, **kwargs)
File "D:\Code\circuit-gnn\DirectML\model.py", line 239, in forward
pred = self.predictor((gnn_code, gnn_code))
File "C:\Users\lizel\miniconda3\envs\Pydml\lib\site-packages\torch\nn\modules\module.py", line 1194, in _call_impl
return forward_call(*input, **kwargs)
File "D:\Code\circuit-gnn\DirectML\model.py", line 70, in forward
complex_apply(self.fc2_bn,
File "D:\Code\circuit-gnn\DirectML\model.py", line 19, in complex_apply
return (layer0,
File "C:\Users\lizel\miniconda3\envs\Pydml\lib\site-packages\torch\nn\modules\module.py", line 1194, in _call_impl
return forward_call(*input, **kwargs)
File "C:\Users\lizel\miniconda3\envs\Pydml\lib\site-packages\torch\nn\modules\batchnorm.py", line 171, in forward
return F.batch_norm(
File "C:\Users\lizel\miniconda3\envs\Pydml\lib\site-packages\torch\nn\functional.py", line 2450, in batch_norm
return torch.batch_norm(
RuntimeError
Batch_norm parameters:
class ComplexNet(nn.Module):
def init(self,
nin=5,
nh=512,
dropout=0):
super(ComplexNet, self).init()
self.nh = nh
self.n_input = nin
    self.fc1 = (nn.Linear(nin, nh), nn.Linear(nin, nh))
    self.fc2 = (nn.Linear(nh, nh), nn.Linear(nh, nh))
    self.fc22 = (nn.Linear(nh, nh), nn.Linear(nh, nh))
    self.fc2_bn = (nn.BatchNorm1d(nh), nn.BatchNorm1d(nh))
    self.fc22_bn = (nn.BatchNorm1d(nh), nn.BatchNorm1d(nh))
    self.fc3 = (nn.Linear(nh, nh), nn.Linear(nh, nh))
    self.fc32 = (nn.Linear(nh, nh), nn.Linear(nh, nh))
    self.fc3_bn = (nn.BatchNorm1d(nh), nn.BatchNorm1d(nh))
    self.fc32_bn = (nn.BatchNorm1d(nh), nn.BatchNorm1d(nh))
    self.fc4 = (nn.Linear(nh, 5001), nn.Linear(nh, 5001))

    self.fc1_r, self.fc1_i = self.fc1
    self.fc2_r, self.fc2_i = self.fc2
    self.fc22_r, self.fc22_i = self.fc22
    self.fc2_bn_r, self.fc2_bn_i = self.fc2_bn
    self.fc22_bn_r, self.fc22_bn_i = self.fc22_bn
    self.fc3_r, self.fc3_i = self.fc3
    self.fc32_r, self.fc32_i = self.fc32
    self.fc3_bn_r, self.fc3_bn_i = self.fc3_bn
    self.fc32_bn_r, self.fc32_bn_i = self.fc32_bn
    self.fc4_r, self.fc4_i = self.fc4

    if dropout > 0:
        self.dropout_2 = (nn.Dropout(dropout), nn.Dropout(dropout))
        self.dropout_3 = (nn.Dropout(dropout), nn.Dropout(dropout))
    else:
        self.dropout_2, self.dropout_3 = None, None

def forward(self, x):
    x1 = complex_linear(self.fc1, x)
    x1 = (F.leaky_relu(x1[0], 0.2),
          F.leaky_relu(x1[1], 0.2))
    x = complex_apply((F.relu, F.relu),
                      complex_apply(self.fc2_bn,
                                    complex_linear(self.fc2, x1)))
    x2 = complex_apply((F.relu, F.relu),
                       complex_apply(self.fc22_bn,
                                     complex_add(x1,
                                                 complex_linear(self.fc22, x))))

    if self.dropout_2 is not None: complex_apply(self.dropout_2, x2)

    x = complex_apply((F.relu, F.relu),
                      complex_apply(self.fc3_bn,
                                    complex_linear(self.fc3, x2)))
    x3 = complex_apply((F.relu, F.relu),
                       complex_apply(self.fc32_bn,
                                     complex_add(x2,
                                                 complex_linear(self.fc32, x))))

    if self.dropout_3 is not None: complex_apply(self.dropout_3, x3)

    x = complex_linear(self.fc4, x3)

    return x

Same problem here with
x = self.dropout1(F.leaky_relu(self.bn1(self.fc1(input))))
params:
self.bn1 = BatchNorm1d(512, eps=1e-05, momentum=0.1, affine=True, track_running_stats=True)
self.fc1 = Linear(in_features=117, out_features=512, bias=True)
input.shape is torch.Size([32, 117])

I also run it on WSL (Ubuntu 22.04), and it returns full error information.
It's "Segmentation fault".
Like these:
args
Namespace(exp='exp_512_2', data_root='/mnt/c/Users/48696/Codes/circuit-gnn/data_root', use_gpu=True, len_hidden=400, len_hidden_predictor=512, len_node_attr=11, len_edge_attr=20, gnn_layers=4, dropout=0, num_workers=3, batch_size=512, lr=0.0002, resume_epoch=-1, epoch=501, num_resonator=4, circuit_type=2, phase='test', exp_folder='./dump/exp_512_2', ckpt_folder='./dump/exp_512_2/ckpt', train_folder='./dump/exp_512_2/train', log_path='./dump/exp_512_2/train.log')
model #params: 10713490
Train samples: [120000, 180000]
Valid samples: [15000, 22500]
0% (0 of 587) |                                                                                | Elapsed Time: 0:00:00 ETA:  --:--:--./Run.sh: line 3:  4317 Segmentation fault      python train.py --exp exp_512_2 --data_root "/mnt/c/Users/48696/Codes/circuit-gnn/data_root" --batch_size 512 --num_workers 3

Sorry for the late response, BatchNorm1D should have been fixed in the latest release.

Thanks for the detailed report, BatchNorm1D is fixed in the latest release.

While, it returns a new error now:
Traceback (most recent call last):
  File "D:\Codes\circuit-gnn\dml\train.py", line 238, in <module>
    train_loss, train_db = train(epoch)
  File "D:\Codes\circuit-gnn\dml\train.py", line 142, in train
    total_loss.backward()
  File "C:\Users\lizel\miniconda3\envs\PyDml\lib\site-packages\torch\_tensor.py", line 488, in backward
    torch.autograd.backward(
  File "C:\Users\lizel\miniconda3\envs\PyDml\lib\site-packages\torch\autograd\__init__.py", line 197, in backward
    Variable._execution_engine.run_backward(  # Calls into the C++ engine to run the backward pass
RuntimeError
100% (587 of 587) |##############################################################| Elapsed Time: 0:00:00 Time:  0:00:00

BatchNorm1D is not supported yet, we will fix it in the next release.


netlify-cli: 17.37.2 -> 17.38.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for netlify-cli is: Netlify command line tool
meta.homepage for netlify-cli is: https://github.com/netlify/cli
meta.changelog for netlify-cli is: https://github.com/netlify/cli/blob/v17.38.0/CHANGELOG.md
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 17.38.0 with grep in /nix/store/x5pyjq9ww3xq75r09qscfc02gvi3ssl9-netlify-cli-17.38.0
found 17.38.0 in filename of file in /nix/store/x5pyjq9ww3xq75r09qscfc02gvi3ssl9-netlify-cli-17.38.0

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

netlify-cli

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/x5pyjq9ww3xq75r09qscfc02gvi3ssl9-netlify-cli-17.38.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A netlify-cli https://github.com/r-ryantm/nixpkgs/archive/6464ba0796eb0aa94f2401ed20959d3fbdde5a58.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/6464ba0796eb0aa94f2401ed20959d3fbdde5a58#netlify-cli

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/x5pyjq9ww3xq75r09qscfc02gvi3ssl9-netlify-cli-17.38.0
ls -la /nix/store/x5pyjq9ww3xq75r09qscfc02gvi3ssl9-netlify-cli-17.38.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review

x86_64-linux

:white_check_mark: 1 package built:

netlify-cli

Maintainer pings
cc @roberth for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 364953

x86_64-linux

:x: 1 package failed to build:

netlify-cli


[Algorithm] Selection Sort in Java

Can I work on this?
Information about my new algorithm

Algorithm Name: Selection Sort

Programming Language: Java

Time complexity: O(n2)

The Selection sort algo in Java is already added. Try opening some other issue.

Please see my new issue about Heap Sort in Java. Thanks!


cannot run demo

Expected Behavior

when i run demo step by step like video is doing, there is nothing in RViz. In the video, you can see map and many things in RViz. By the way, i can run other demo correctly like Detection with Euclidean Clustering, so i think i install autoware correctly. maybe the problem of map rosbag?
Actual Behavior

Specifications

Ubuntu version: 16.04
ROS Version: kinetic
Autoware branch:

changed your fixed frame to world.


there is not any info about mpadded tag

https://developer.mozilla.org/en-US/docs/Web/MathML/Element/mpadded

The MathML <mpadded> element is used to add extra padding and to set the general adjustment of position and size of enclosed contents.

Covered by https://caniuse.com/#feat=mathml?
Finding mathmal when searching mpadded could be consideration though.


How do I install dlls compiled by vcpkg using cmake install() function ?

I was wondering how I can instruct CMake to install the dlls compiled by vcpkg next to my executables using the install() command (on Windows, with Visual Studio 2019 generator for CMake). Here is more explanations:
The CMakeLists of the project I'm playing with is this one: https://gitlab.com/c2ba_sandbox/c_cpp/exploring-unit-tests-in-c/-/blob/master/CMakeLists.txt
I'm linking my test_hello_world executable to the library cmocka which have been built with vcpkg (as shared library). When I compile my project, the cmocka.dll ends up correctly next to test_hello_world.exe in my build hierarchy, so it executes fine (I don't really know how it works behind the scene, but I guess the vcpkg CMake toolchain file is responsible in some way for copying the dll).
But when I run the install target (cmake --build build/ --target install/ --config Release), the cmocka.dll is not copied in the installation folder that I've set with CMAKE_PREFIX_PATH.
So is there any way I can instruct CMake to copy the dlls where they should be ? I know I could do that by copying the vcpkg/installed/bin/*.dll files, but I would prefer a "CMake way".
If this ends up being possible, I think it would be great to add an example to https://github.com/microsoft/vcpkg/blob/master/docs/examples/installing-and-using-packages.md

You don't copy dlls copied by vcpkg.....
Instead you use the cmake to do it:
https://cmake.org/cmake/help/latest/command/file.html#get-runtime-dependencies
because otherwise your buildscript has a hard dependency on vcpkg.
vcpkg does something similar as GET_RUNTIME_DEPENDENCIES just at build time. You also could do that with CMake but it requires setting up an additional custom target.

Interesting, it seems to be what I need, thanks for the link and the explanation, I'll give it a try !


add iOS unit tests to CI

Hi @andrewheard, just wondering if this is sufficient to prevent accidental breaking changes.
cc @rlazo @davidmotson


⚠ ClamAV has degraded performance

In 04a47c3, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 71 ms

Resolved: ClamAV performance has improved in cdcf860.


Energetic Daffodil Coyote

Hotspot Name
Energetic Daffodil Coyote
Hotspot b58 Address
112XEUFxbBkYSSxZTdBZj1J4De1H731fmt7L2LsDWEPjGJZZ9Ew9
Discord Handle
No response
Hotspot Manufacturer
PantherX
Removal Reason
Real deployment node, don't know why on the rejection list  . The deployed host is blacklisted and requests to be removed from the blacklist真实部署的主机被拉入了黑名单，请求解除黑名单
Modifications
Yes
Extra forwarders
No
Extra antennas
Yes
Additional Information

Real deployment node, don't know why on the rejection list.
Please help to remove the real node from the rejected list as soon as possible, thank you

We have taken into account this removal request in the next iteration of the denylist. It may take some time before it's processed. This is an automated comment due to the volume of addition and removal requests. A future tool is in the works to provide more insight into the analysis approach made by the Helium team and community members that maintain this list.


Added awesome fontconfig for next icons

see #107

Great! Thank you, @V1rgul!!

Just for the record: This is the interim-solution from #97
Thank you very much @V1rgul


Adding an option for changing the first day of the week

A feature to change what is the first day of the week from Monday to Sunday (as it is in some non Christiaan cultures.

Available in 0.25.0.


Does this line contain a typo or is it coded as intended?

Branch: Master
Reference: app/assets/javascripts/funds/directives/accounts_directives.js.coffee#L18
Should this line read:

$scope.currecny = @selectedCurrency

Or is it really:

$scope.currency = @selectedCurrency

I'm reviewing a change I made to switch CNY with USD as the primary fiat currency for our test exchange and noticed that the line referenced above was picked up while searching across the project for occurrences of cny.

A related file that probably would potentially need to be looked at if the answer to the question above is, "it's a typo":
https://github.com/peatio/peatio/blob/master/db/migrate/20131208012814_fix_payment_address_currecny.rb

class FixPaymentAddressCurrecny < ActiveRecord::Migration

@brossi :+1: Thank you for your report, fixed at 4c28ed978a0cdd9292b675ed9c825d1d01ac5f5e and dcb7ceec3c62a3598d8361e62f4689c106488f9f

Thank you, @lgn21st