[ubuntu 20.04][docker] build failure

Host Environment

OS: Ubuntu 20.04
Compiler: llvm 6.0

To Reproduce
git clone https://github.com/microsoft/vcpkg && ./vcpkg/bootstrap-vcpkg.sh
Failure logs
> [builder 5/7] RUN git clone https://github.com/microsoft/vcpkg && ./vcpkg/bootstrap-vcpkg.sh:
#19 0.218 Cloning into 'vcpkg'...
Updating files: 100% (7790/7790), done.90)
#19 35.42 Downloading vcpkg tool sources
#19 35.60   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
#19 35.61                                  Dload  Upload   Total   Spent    Left  Speed
100   173  100   173    0     0    308      0 --:--:-- --:--:-- --:--:--   319
100  494k  100  494k    0     0   383k      0  0:00:01  0:00:01 --:--:-- 1395k
#19 37.06 Building vcpkg-tool...
#19 38.12 CMake Error at /usr/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
#19 38.12   list sub-command REMOVE_ITEM requires two or more arguments.
#19 38.12 Call Stack (most recent call first):
#19 38.12   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
#19 38.12   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
#19 38.12   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
#19 38.12   /usr/share/cmake-3.16/Modules/CMakeDetermineCXXCompiler.cmake:111 (CMAKE_DETERMINE_COMPILER_ID)
#19 38.12   CMakeLists.txt:32 (project)
#19 38.12
#19 38.12
#19 38.70 CMake Error at /usr/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
#19 38.70   list sub-command REMOVE_ITEM requires two or more arguments.
#19 38.70 Call Stack (most recent call first):
#19 38.70   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
#19 38.70   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
#19 38.70   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
#19 38.70   /usr/share/cmake-3.16/Modules/CMakeDetermineCXXCompiler.cmake:111 (CMAKE_DETERMINE_COMPILER_ID)
#19 38.70   CMakeLists.txt:32 (project)
#19 38.70
#19 38.70
#19 39.22 CMake Error at /usr/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
#19 39.22   list sub-command REMOVE_ITEM requires two or more arguments.
#19 39.22 Call Stack (most recent call first):
#19 39.22   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
#19 39.22   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
#19 39.22   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
#19 39.22   /usr/share/cmake-3.16/Modules/CMakeDetermineCXXCompiler.cmake:111 (CMAKE_DETERMINE_COMPILER_ID)
#19 39.22   CMakeLists.txt:32 (project)
#19 39.22
#19 39.22
#19 39.32 CMake Error at /usr/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
#19 39.32   list sub-command REMOVE_ITEM requires two or more arguments.
#19 39.32 Call Stack (most recent call first):
#19 39.32   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
#19 39.32   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
#19 39.32   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
#19 39.32   /usr/share/cmake-3.16/Modules/CMakeDetermineCXXCompiler.cmake:111 (CMAKE_DETERMINE_COMPILER_ID)
#19 39.32   CMakeLists.txt:32 (project)
#19 39.32
#19 39.32
#19 39.41 CMake Error at /usr/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
#19 39.41   list sub-command REMOVE_ITEM requires two or more arguments.
#19 39.41 Call Stack (most recent call first):
#19 39.41   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
#19 39.41   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
#19 39.41   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
#19 39.41   /usr/share/cmake-3.16/Modules/CMakeDetermineCXXCompiler.cmake:111 (CMAKE_DETERMINE_COMPILER_ID)
#19 39.41   CMakeLists.txt:32 (project)
#19 39.41
#19 39.41
#19 39.57 CMake Error at /usr/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
#19 39.57   list sub-command REMOVE_ITEM requires two or more arguments.
#19 39.57 Call Stack (most recent call first):
#19 39.57   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
#19 39.57   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
#19 39.57   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
#19 39.57   /usr/share/cmake-3.16/Modules/CMakeDetermineCXXCompiler.cmake:111 (CMAKE_DETERMINE_COMPILER_ID)
#19 39.57   CMakeLists.txt:32 (project)
#19 39.57
#19 39.57
#19 40.10 CMake Error at /usr/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
#19 40.10   list sub-command REMOVE_ITEM requires two or more arguments.
#19 40.10 Call Stack (most recent call first):
#19 40.10   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
#19 40.10   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
#19 40.10   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
#19 40.10   /usr/share/cmake-3.16/Modules/CMakeDetermineCXXCompiler.cmake:111 (CMAKE_DETERMINE_COMPILER_ID)
#19 40.10   CMakeLists.txt:32 (project)
#19 40.10
#19 40.10
#19 40.64 CMake Error at /usr/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
#19 40.64   list sub-command REMOVE_ITEM requires two or more arguments.
#19 40.64 Call Stack (most recent call first):
#19 40.64   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
#19 40.64   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
#19 40.64   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
#19 40.64   /usr/share/cmake-3.16/Modules/CMakeDetermineCXXCompiler.cmake:111 (CMAKE_DETERMINE_COMPILER_ID)
#19 40.64   CMakeLists.txt:32 (project)
#19 40.64
#19 40.64
#19 40.74 CMake Error at /usr/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
#19 40.74   list sub-command REMOVE_ITEM requires two or more arguments.
#19 40.74 Call Stack (most recent call first):
#19 40.74   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
#19 40.74   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
#19 40.74   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
#19 40.74   /usr/share/cmake-3.16/Modules/CMakeDetermineCXXCompiler.cmake:111 (CMAKE_DETERMINE_COMPILER_ID)
#19 40.74   CMakeLists.txt:32 (project)
#19 40.74
#19 40.74
#19 40.84 CMake Error at /usr/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
#19 40.84   list sub-command REMOVE_ITEM requires two or more arguments.
#19 40.84 Call Stack (most recent call first):
#19 40.84   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
#19 40.84   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
#19 40.84   /usr/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
#19 40.84   /usr/share/cmake-3.16/Modules/CMakeDetermineCXXCompiler.cmake:111 (CMAKE_DETERMINE_COMPILER_ID)
#19 40.84   CMakeLists.txt:32 (project)
#19 40.84
#19 40.84
#19 41.15 -- The CXX compiler identification is unknown
#19 41.24 -- Check for working CXX compiler: /usr/bin/g++-9
#19 42.95 -- Check for working CXX compiler: /usr/bin/g++-9 -- works
#19 42.96 -- Detecting CXX compiler ABI info
#19 44.64 -- Detecting CXX compiler ABI info - done
#19 44.68 -- Detecting the C++ compiler in use
#19 44.68 CMake Error at cmake/utilities.cmake:43 (message):
#19 44.68   Unknown compiler:
#19 44.68 Call Stack (most recent call first):
#19 44.68   CMakeLists.txt:61 (vcpkg_detect_compiler)
#19 44.68
#19 44.68
#19 44.68 -- Configuring incomplete, errors occurred!
#19 44.68 See also "/home/rust/vcpkg/buildtrees/_vcpkg/build/CMakeFiles/CMakeOutput.log".
#19 44.68 See also "/home/rust/vcpkg/buildtrees/_vcpkg/build/CMakeFiles/CMakeError.log".

Dockerfile
FROM ubuntu:20.04 as base

# The Rust toolchain to use when building our image.  Set by `hooks/build`.
ARG TOOLCHAIN=stable

# The OpenSSL version to use. Here is the place to check for new releases:
#
# - https://www.openssl.org/source/
#
# ALSO UPDATE hooks/build!
ARG OPENSSL_VERSION=1.1.1i

# Versions for other dependencies. Here are the places to check for new
# releases:
#
# - https://github.com/rust-lang/mdBook/releases
# - https://github.com/EmbarkStudios/cargo-about/releases
# - https://github.com/EmbarkStudios/cargo-deny/releases
# - http://zlib.net/
# - https://ftp.postgresql.org/pub/source/
#
# We're stuck on PostgreSQL 11 until we figure out
# https://github.com/emk/rust-musl-builder/issues.
ARG MDBOOK_VERSION=0.4.6
ARG CARGO_ABOUT_VERSION=0.2.3
ARG CARGO_DENY_VERSION=0.8.5
ARG ZLIB_VERSION=1.2.11
ARG POSTGRESQL_VERSION=11.11

# Make sure we have basic dev tools for building C libraries.  Our goal here is
# to support the musl-libc builds and Cargo builds needed for a large selection
# of the most popular crates.
#
# We also set up a `rust` user by default. This user has sudo privileges if you
# need to install any more software.
#
# `mdbook` is the standard Rust tool for making searchable HTML manuals.

@JackBoosY Note that the errors is in building vcpkg-tool. It is fair to expect much lower versions of CMake to work for building the tool than for using the complete bootstrapped vcpkg. Or let bootstrapping download cmake first, and build the tool with that version.

@dg0yt make sence.

I started seeing this in the past three days in Actions workflow (run) w. Ubuntu 21.10, CMake 3.18 and WSL2:
john@Carbon:~/ws/wordle/vcpkg$ uname -a
Linux Carbon <IP_ADDRESS>-microsoft-standard-WSL2 #1 SMP Wed Aug 25 23:20:18 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
john@Carbon:~/ws/wordle/vcpkg$ cmake --version
cmake version 3.16.3

CMake suite maintained and supported by Kitware (kitware.com/cmake).

My build directory is /home/john/ws/wordle/vcpkg/ and so vcpkg is cloned as /home/john/ws/wordle/vcpkg/vcpkg/. The path passed to file(GLOB in /home/john/ws/wordle/vcpkg/vcpkg/scripts/buildsystems/vcpkg.cmake:531 is /home/john/ws/wordle/vcpkg/vcpkg/installed//tools/* which has a double slash and isn't a valid path. The only two tools in the repo are directories:

/home/john/ws/wordle/vcpkg/vcpkg/downloads/tools/
/home/john/ws/wordle/vcpkg/vcpkg/ports/chromium-base/res/tools/

Fixed by PR #23410


Add targets to manage Redis

/retest

Just a heads up that a redis target that uses a redis specific checkout and CR path to avoid interfering with other infra operator based services has been merged. See PR 748 and 762

closing since redis was removed in https://github.com/openstack-k8s-operators/install_yamls/pull/801


🐛 Bug Report: signals-backend ignores events for users that are about to connect

📜 Description
signals-backend receives events from the Event Broker and drops them if no appropriate connections are found. This is fine most of the time, but this is a problem when the user loads the page and quickly does something that should trigger a signal back to that user, because signals-backend has yet to acknowledge and store a new connection and its subscriptions.
👍 Expected behavior

send a REST request by pressing a button once the page is loaded
receive a signal

👎 Actual Behavior with Screenshots

send a REST request once the page is loaded
signal not received until the user tries again in a few seconds

(logging messages added to signals-backend)

👟 Reproduction steps
Difficult to reproduce consistently.

set up a router endpoint that triggers a signal event with the original sender as its recipient
trigger the endpoint within a few seconds after the page loads

📃 Provide the context for the Bug.
Our team is building a plugin that relies on signals to trigger updates on the front end. The client side sends a POST message to the backend, and the backend notifies relevant users (in our case, users belonging to a team) via signals of the change. The problem occurs when the user sends the request shortly after the page has loaded. This is less of a noticeable problem on a local machine, but in our production environment this WS connection window can be anywhere from 2 to 10 seconds long.
🖥 Your Environment
No response
👀 Have you spent some time to check if this bug has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
Yes I am willing to submit a PR!

The issue lies in the signals module's lack of knowledge about WS connections, which results in the loss of events when they are sent before the establishment of a WS connection.
Typically, when the user goes to Backstage, he/she doesn't wait for tens of seconds when everything will be established prior to clicking on something.
Can we introduce some indication that an event has to be sent after WS is established and keep it in the queue till WS is connected? I believe we can use the events module without WS.

I think piling the messages to signals backend until the receivers have connected could work BUT: the time the messages are held in memory waiting for the WS connection should be quite short. One way to do this would be to have, for example, an LRU cache (https://www.npmjs.com/package/lru-cache) that holds the messages for some period and once the user connects, it will send all messages that are still in the cache. This though might have some crazy effects when the same connects with two browser sessions.
Another option, I think, is to establish the WS connection as soon as the user opens the page. This could be done a couple of different ways; either by making the SignalClient auto-connect when it's first included in the App, or by having some global subscription to something (for example by the notifications side bar item).
Of course, it's possible to do both if necessary.

@drodil We currently do use a sidebar item but unfortunately there's still not quite enough time in some cases to fully establish a WS connection, but an LRU cache does sound like an interesting approach to solving this

I think establishing a WS connection is slow due to some network checks + VPN; I wouldn't rely on somehow tricking to have a connection faster, some stuff we can't control within Backstage.
What is the problem when 2 browsers are opened? We would need to keep this cache only for the moment till WS connection is established for the certain user. I didn't check the code, but i hope we have the way to count all active sessions, and hold events publishing till all connections are established, or publish it as many times as user has connections.


One user having issues viewing going live for mixer

I am a Sr. Admin of a decently sized discord server with almost 200 active members. Everyone can see who goes live in mixer except one person.
This is what he sees:
https://media.discordapp.net/attachments/298482814758944769/374318844413476864/Screenshot_20171029-174819.png?width=248&height=440
This is what everyone else sees:
https://media.discordapp.net/attachments/298482814758944769/374321095093911553/Screenshot_20171029-181727.png?width=247&height=440
It's really odd. I think that it may be his ISP but I'm just throwing out guesses at this point.

this has been resolved.


Please add a licence to the project

Just found your very useful tool and would like to make use of it in my own project.
However, since there's currently no license set I would really appreciate it if you could set a licence for it so any use would be legal.
Many thanks!

I am very new to github and stuffs so forgot about the license. I have set it to Unlicensed just like the main project this one is derived from.


manager-ui: CXL switch box smaller than VCS box

When the VCS gets larger, the CXL switch box doesn't scale together. Screenshot below.

I fixed it in https://github.com/opencxl/opencxl-manager-ui/commit/ce9ba0ee802484c9ce373c91f438e1294b2b1583 commit


Resource

Expect meshweb to have a bit more CPU during startup
Allow  pelias more memory to be used during startup, which is then freed during normal usage

Can you show data to back this change up?

Slack


ElasticSearch is broken on v1.1.0 - jackson classpath issue.

Somehow a dependency to jackson-dataformat-yaml (YAMLGenerator) is causing major issues.
This is included by the transport-client, which is about to be deprecated. We will update to HighLevelRestClient in core and pray that the issue is resolved.
We need the LITERAL_BLOCK feature introduced in jackson 2.9. The TransportClient includes 2.8.10...

Overwrite the transitive version and use 2.9 explicitly. Works for now.

Closing for now.


.github/workflows/rebase-staging.yml: rebase for multiple branches

Motivation for this change
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Leaving this as a draft but it's ready for review. I'll rename the action when merging.
@cdepillabout You may find this useful for PRs that need rebasing onto haskell-updates?
@mweinelt IIRC you asked about using it for release branches?

Leaving this as a draft but it's ready for review. I'll rename the action when merging.
@cdepillabout You may find this useful for PRs that need rebasing onto haskell-updates?
@mweinelt IIRC you asked about using it for release branches?

@zowoq Thanks for pinging me on this.  This does look like it would be helpful for rebasing stuff on haskell-updates.
Although I'm not very familiar with these / commands using GitHub actions.
Does the /rebase command actually rebase a branch in a user's repo (and not just change the base branch on GitHub)?
I  was under the impression that even people with the commit bit in a repo aren't able to rebase a branch in a user's repo (even if they checked the box allow maintainer to push to my branch or whatever).  So I'm somewhat surprised that this functionality is available as a / command.

Does the /rebase command actually rebase a branch in a user's repo (and not just change the base branch on GitHub)?

Yes. Base branch can be changed on the website but the two actions need to happen at once or you ping a lot of people.
I used it multiple times already and it mostly worked.

Once we've used this for a couple of weeks without any problems I'll see about getting a token added to the repo so we can drop the close/reopen hack.
I've added a check for Allow edits .. by maintainers / maintainer_can_modify as it seems like it might be a common error, some of the other failures look like problems with the gh tool itself or the runners environment.

I just triggered this by accident by commenting on a PR with Updated{slash}rebased on master, we may need to change it to use something a bit more specific.

I tried rebasing on the same branch and for some reason that is prohibited.

Can't rebase 20.09/microcodeIntel from release-20.09 onto release-20.09 (PR:113521 COMMITS:1)

Rebasing became necessary when an eval error hit release-20.09 and allowing rebase onto the same base would've been useful.

It's disabled it to simplify the action as the merge-base and change base API commands aren't needed in that case.
The action is intended to cover the more complicated cases that also require additional steps: an API call or manually changing the base branch.
TBH I don't think it's worthwhile having support for the same branch as the action only works for committers and it's simple (and quicker) to rebase a branch on HEAD as it only needs git commands.

The API calls could be conditional on whether the branches aren't the same, no?
I know this is an afterthought, but It would be an amazing convenience feature, allowing the bot to take care of rebasing to HEAD to let the CI reevaluate with fixes that are on the target branch.
The benefit of the command is that it is lazy, it can be issued when you see the necessity and you don't have to open a shell, fetch and checkout the relevant branch. I believe there is little harm in allowing this.
Granted the whole action is getting quite complex, but we're talking about incremental improvements here.

The confusion about how to "properly" rebase across branches without the CODEOWNER spam has generated many discussion and issues. Even the IRC bot has a programmed response. It's worthwhile having the action to simplify it.
I don't see rebasing on HEAD it as an incremental improvement, it's an increase in complexity to address a use case that is already uncomplicated.

I don't see rebasing on HEAD it as an incremental improvement, it's an increase in complexity to address a use case that is already uncomplicated.

While I agree that increasing complexity is definitely something to watch out for, it would be great to be able to do more directly through the github UI.
For instance, in https://github.com/NixOS/nixpkgs/pull/114418#issuecomment-786413882, I tried to use the /rebase command to do a rebase on the same branch, but it failed.  I had to do it through the CLI.
If this would work to do a rebase on the same base branch, then I could have merged in that PR without ever going to the CLI.  This would have been slightly easier for me.

Okay, there's been a few of requests now for rebasing on the same branch, let's add it.
Currently it doesn't work with the close/reopen hack, we won't be able to reopen the PR because of "branch was force pushed or recreated". If we change the action to use a different token we avoid the need for close/reopen hack so that seems to be the easier option. I'll try to see about organising that in the next couple of days.

... next couple of days.

Took a bit longer than I planned but I've opened a draft at #124560, also includes some other changes which will make the commands more reliable.

PR to remove: https://github.com/NixOS/nixpkgs/pull/126192


Update run_docker_build.sh

Checklist

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

@conda-forge/core Hi core, these token extraction attempts may be something to keep an eye on; has anyone seen this elsewhere? This may just be a research project, but the user provides no explanation.


wild world won't work

whenever i try to use my wild world save, this message pops up and doesn't load.
Unhandled exception has occurred in your application. If you click Continue, the application will ignore this error and attempt to continue. If you click Quit, the application will close immediately.
Index was outside the bounds of the array.
Details:
See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.
************** Exception Text **************
System.IndexOutOfRangeException: Index was outside the bounds of the array.
at ACSE.Pattern.GenerateNLPatternBitmap(Byte[] Import_Data, Boolean Decode)
at ACSE.Pattern.Read(Int32 Index)
at ACSE.Pattern..ctor(Int32 patternOffset, Int32 index, Save save)
at ACSE.NewPlayer..ctor(Int32 offset, Int32 idx, Save save)
at ACSE.NewMainForm.<>c__DisplayClass80_0.b__3()
at System.Threading.Tasks.Task.Execute()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
at ACSE.NewMainForm.d__80.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
at ACSE.NewMainForm.<openToolStripMenuItem_Click>d__168.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
************** Loaded Assemblies **************
mscorlib
Assembly Version: <IP_ADDRESS>
Win32 Version: 4.7.2558.0 built by: NET471REL1
CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/mscorlib.dll
ACSE
Assembly Version: <IP_ADDRESS>
Win32 Version: <IP_ADDRESS>
CodeBase: file:///C:/Users/Reshader/AppData/Local/Temp/Rar$EXa5660.15899/ACSE.exe
System.Windows.Forms
Assembly Version: <IP_ADDRESS>
Win32 Version: 4.7.2558.0 built by: NET471REL1
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_<IP_ADDRESS>__b77a5c561934e089/System.Windows.Forms.dll
System
Assembly Version: <IP_ADDRESS>
Win32 Version: 4.7.2558.0 built by: NET471REL1
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_<IP_ADDRESS>__b77a5c561934e089/System.dll
System.Drawing
Assembly Version: <IP_ADDRESS>
Win32 Version: 4.7.2558.0 built by: NET471REL1
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_<IP_ADDRESS>__b03f5f7f11d50a3a/System.Drawing.dll
System.Configuration
Assembly Version: <IP_ADDRESS>
Win32 Version: 4.7.2558.0 built by: NET471REL1
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_<IP_ADDRESS>__b03f5f7f11d50a3a/System.Configuration.dll
System.Core
Assembly Version: <IP_ADDRESS>
Win32 Version: 4.7.2563.0 built by: NET471REL1
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_<IP_ADDRESS>__b77a5c561934e089/System.Core.dll
System.Xml
Assembly Version: <IP_ADDRESS>
Win32 Version: 4.7.2612.0 built by: NET471REL1LAST_B
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_<IP_ADDRESS>__b77a5c561934e089/System.Xml.dll
************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.
For example:

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

There was an issue with certain save files dumped from Wild World where they are the same length as New Leaf save files. To fix it, I added an extra check. The fix will be in the next release, but if you want to use it in the meantime, you can build ACSE yourself and it'll work!


Handle an encrpyted logout token during OIDC federated idp initiated back-channel logout

Describe the improvement

WSO2 IS must have the capability to handle an encrypted logout token coming from a federated idp, if the OIDC federated idp initiated back channel logout is enabled.
If the id token encryption is negotiated during the registration, IS should decrypt the logout token using the specified key and algorithms during that registration. But, if the logout token is not encrypted even though the id token encryption is negotiated at the registration, IS should reject the logout token.

Part of Improvement identified in https://github.com/wso2/product-is/issues/9254
Additional context
In the OpenID Connect Specification, they state that upon receiving a logout request, as the first step, the RP (in this case, the WSO2 IS)  MUST validate the Logout Token as follows,

If the Logout Token is encrypted, decrypt it using the keys and algorithms that the Client specified during Registration that the OP was to use to encrypt ID Tokens. If ID Token encryption was negotiated with the OP at Registration time and the Logout Token is not encrypted, the RP SHOULD reject it.

OIDC Specification - https://openid.net/specs/openid-connect-backchannel-1_0.html

From the implementation PoV, we have to,

Support at option at the application configuration level to enable encrypted logout tokens
Support an option at the IDP configuration level to say that we will be receiving encrypted logout tokens from a federated IDP
Support issuing encrypted logout tokens during backchannel logout
Support handling encrypted logout tokens during federated IDP initiated logout

This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!


Implement OWL-ViT: Open-World Object Detection with Vision Transformers

Feature request
We wish to implement https://github.com/google-research/scenic/tree/main/scenic/projects/owl_vit
Motivation
google's version of SAM

https://colab.research.google.com/drive/1NVcfvtESDfHC-nXi7L-gTAM-MCpixrvs#scrollTo=99ilV_T2RyNT (copy of https://colab.research.google.com/github/google-research/scenic/blob/main/scenic/projects/owl_vit/notebooks/OWL_ViT_minimal_example.ipynb#scrollTo=99ilV_T2RyNT):


(#165) Add Java8 requirement in the UI

What is this PR doing?
It adds a help area for the image used to provision the worker machines from a GCE image. The texts are directly copied from the existing Home.md file.
Why is it important?
The existing Github docs warn the user about the fact of having Java8 installed in the chosen image, but the UI is not reflecting that information. For that reason I consider important to sync-up both of them to gather expectations.
Screenshots

Author's checklist

[x] Unit tests passing
[ ] Integration test executed
[x] HPI deployed to a running Jenkins instance (v2.190.3)

Hey @craigdbarber, I'm not accessing the CI link for this PR because I consider the permissions the CI asks for are too wide (i.e. R/W access for Public & Private repositories).
If possible, could you send me logs or anything relevant in order to identify the issue with this change?
Thanks in advance!

LGTM. Will defer to @stephenashank for the approve.

BTW, I just copied another HTML file, so I guess the source format (SF) process is not being applied to existing files 🤷♂
Maybe there is needed a PR updating all file endings and I'd suggest changing the date in header to a 2018-current or something, otherwise in less than 30 days there will be another SF party 😄
Thanks agains for reviewing this :)


Add a flatmap datapipe

🚀 The feature
Add a FlatMapDataPipe which simulataneously flattens nested IterDataPipes and applies a function to nested pipes.
Motivation, pitch
I have tarballs containing tarballs. When dealing with these types of recursive data, it's useful to have a mechanism to both flatten the structure and apply a function to it so I only need to consider the "inner-most" data.
Alternatives
Domain libraries can define their own impls.
Additional context
Migrating torchtext to datapipes via torchdata would benefit from this feature when dealing with IWSLT data.

Maybe another good analog would be flatten which does that same thing without the intermediate map (equivalent, flatmap with identity function)

We do have a plan to add flatmap but the behavior may be different than the proposal. We expect flatmap would expand the returned list from map_fn.
>>> def fn(data):
...     return [data, data*10]

>>> dp = IterableWrapper([0,1,2,3])
>>> dp = dp.flatmap(fn)
>>> list(dp)
[0, 0, 1, 10, 2, 20, 3, 30]

We do have a operator named unbatch, which behaves same as flatten

Hmm, I think maybe you're right and that my implementation is a concatmap. The difference is when the map happens (before for flatmap, after for concatmap). 🤔

Technical speaking, this flatmap can also be applied in your use case. The function becomes a generator yielding data..

Yes, the pseudocode I have in mind is basically
# [ 1.tgz, 2.tgz, ..., n.tgz]
inner_tars = outer_tar.read_from_tar()

# [ 1_1.txt, 1_2.txt, 3_1.txt, 3_2.txt, 5_1.txt, ...]
inner_inner_files = inner_tars.flatmap(lambda inner_tar: FileOpener(inner_tar).read_from_tar())

So the read_from_tar becomes the generator yielding data and flatmap flattens it into a IterableDataPipe.


tokens are not displaying

I'm on swift 2.3 and using version 2.5 of KSTokenView. The addToken method doesn't add tokens to the KSTokenView nor do the tokens get added when clicked from the UITableView. Doesn't seem like anyone else is reporting this issue?

@heatherSnepenger can you provide sample code how you are using it? You may look into "Programmatically" example. If you are still facing issue, you may re-open it.


update openfst to 1.6.7

It looks like the url for 1.6.3 no longer works:
http://www.openfst.org/twiki/pub/FST/FstDownload/openfst-1.6.3.tar.gz
https://github.com/parlance/ctcdecode/blob/746bffbe70a06d3cf4dfc6f6a04a104a51a551da/build.py#L21
Thank you kindly for ctcdecode

thanks man!


Rename Access Control Policy for MFA adapter

It should have the prefix 'ADFSTk:' not 'ADFS Toolkit - '

Solved by #147


Pidgin 2.12.0 can't connect to the server

Steps to reproduce issue:

Install Pidgin 2.12.0
In settings.env enable auth by setting DISABLE_AUTH to false
Start server
curl -d'{"screen_name":"asd123", "password":"asd123"}' http://localhost:8080/user
Add account in Pidgin
In Advanced change server and port to <IP_ADDRESS>:5190
Set Connection security to Don't use encryption
Set Authentication method to MD5-based
Login in Pidgin
Pidgin reports asd123 disconnected: Server closed the connection

Sever logs are here

Thanks for the detailed report. Can you copy the log contents here? Looks like that paste is going to expire in 2 days.

This is the error that causes disconnection:
time=2024-05-14T14:17:59.155+03:00 level=TRACE msg="client request" svc=BOS request.food_group=Locate request.sub_group=LocateSetInfo request.snac_frame="{FoodGroup:2 SubGroup:4 Flags:0 RequestID:15}" request.snac_payload="{TLVRestBlock:{TLVList:[{Tag:4 Value:[]}]}}" screenName=asd123 ip=<IP_ADDRESS>:55820
time=2024-05-14T14:17:59.155+03:00 level=ERROR msg="client request error" svc=BOS request.food_group=OService request.sub_group=OServiceSetUserInfoFields err="don't know what to do with status 268566528" screenName=asd123 ip=<IP_ADDRESS>:55820

It can be traced back to this block in the SetUserInfoFields SNAC handler:
if status, hasStatus := inBody.Uint32(wire.OServiceUserInfoStatus); hasStatus {
	switch status {
	case 0x0000:
		sess.SetInvisible(false)
		if err := broadcastArrival(ctx, sess, s.messageRelayer, s.feedbagManager, s.legacyBuddyListManager); err != nil {
			return wire.SNACMessage{}, err
		}
	case 0x0100:
		sess.SetInvisible(true)
		if err := broadcastDeparture(ctx, sess, s.messageRelayer, s.feedbagManager, s.legacyBuddyListManager); err != nil {
			return wire.SNACMessage{}, err
		}
	default:
		return wire.SNACMessage{}, fmt.Errorf("don't know what to do with status %d", status)
	}
}

The client receives a status value of 0x10020000, but they only two supported values are 0x0000 and 0x0100. The block should treat the status as a bitmask and check for the presence of flags rather than do a straight integer comparison.
I traced the origin of the flags set in 0x10020000 back to the corresponding client code in pidgin:
if (seticqstatus)
{
	aim_tlvlist_add_32(&tlvlist, 0x0006, icqstatus |
			AIM_ICQ_STATE_HIDEIP | AIM_ICQ_STATE_DIRECTREQUIREAUTH);
}

Both flags ORed together equal 0x10020000 (source):
#define AIM_ICQ_STATE_HIDEIP            0x00020000
//...
#define AIM_ICQ_STATE_DIRECTREQUIREAUTH 0x10000000

The set info handler should be able to process flags that it doesn't support without returning an error.
Here's how I would fix the bug:

Copy the status constants to wire/snacs.go.
Replace the above if statement with bitmask checks for each oservice status constant. Right now we only support visibile/invisible, but may support additional ones in the future. For unsupported constants, just log the presence of an unsupported constant and carry on.

if status, hasStatus := inBody.Uint32(wire.OServiceUserInfoStatus); hasStatus {
	if status&wire.OServiceStatusVisible == wire.OServiceStatusVisible {
		sess.SetInvisible(false)
		if err := broadcastArrival(ctx, sess, s.messageRelayer, s.feedbagManager, s.legacyBuddyListManager); err != nil {
			return wire.SNACMessage{}, err
		}
	}
	if status&wire.OServiceStatusInvisible == wire.OServiceStatusInvisible {
		sess.SetInvisible(true)
		if err := broadcastDeparture(ctx, sess, s.messageRelayer, s.feedbagManager, s.legacyBuddyListManager); err != nil {
			return wire.SNACMessage{}, err
		}
	}
	if status&wire.OServiceStatusRequireDirectAuth == wire.OServiceStatusRequireDirectAuth {
		s.Infof("got unsupported status %d", status)
	}
	/// ...
}

I'm going to leave this issue open for newcomers. I think the fix is pretty simple, even for those without go experience.


NullPointerException in DarkSteelController

http://pastebin.com/pvG8nXG0

see #2780

Seems that the nullpointer comes if i use the glider of my armor. At that moment all the player on the server that don't have an enderio armor get that error. I think it has something to do with the UUID.

This comes when there are clients logged in that don't know about your player. Ender IO sends a notification about your status change to all clients (so they can render your character correctly), but some of those don't know about you...and crash.
I believe the root cause is a difference between a vanilla/forge server and some of the other servers out there. Vanilla/forge always tells all clients about all players, the others only about other players within render distance.
However, as long as tterrag doesn't pull my proposed fix, we will never find out if I guessed correctly.

Then i will try build with your changes in it


Improve dead code branch detection

I'm submitting a feature request
Webpack version:
1.10.x and 2.x
Please tell us about your environment:
OSX 10.x
Current behavior:
Starting with React, it has become increasingly popular to check for a development env with an if clause like this:
if (process.env.NODE_ENV === "development") { ... }

In combination with the DefinePlugin, this statement is replaced with "development" === "development". Unfortunately, this code branch is not detected by webpack as dead code branch. Any dynamic imports (or require()) that happen to be inside the if-block are still included into the bundle.
With simple checks like
if (IS_DEVELOPMENT) { ... }

which is turned into
if (false) { ... }

webpack is already able to ignore the if-block.
Expected/desired behavior:
webpack should not include any modules that are required or dynamically imported within this if-block. It would also make sense to remove this code before tree-shaking.
What is the motivation / use case for changing the behavior?
Smaller bundles 🎉

It seems to work correctly. I added some test cases.


Time tracking not working

Discussed in https://github.com/ivan-lednev/obsidian-day-planner/discussions/646

Originally posted by pkelly102 November 25, 2024
I'm excited about the new Time Tracking feature, but it isn't working on my Obsidian. Here is a screenshot of the settings - there should be an active clock for "buy milk" like the example in the documentation. The plugin seems to be able to recognize it, as right clicking on the entry gives me the option to "clock out," but in the timeline view there is no "active clock" running.

Hello, @pkelly102, for now you should explicitly include your daily notes folder into the source filter. If your daily notes are at the top of the vault, you can mark tasks with clocks with #task and include #task into the filter.
This will change in a future release.

Worked perfectly!! Thanks so much for your help.


Finish "Implement depend-defaults"

edit by @ras0219-msft: Original PR at #295

@ras0219-msft Since https://github.com/microsoft/vcpkg-tool/pull/813 was merged I merged with main. I have changed the implementation so that a Dependency is still context free. The downsite is that the parser is now not context free anymore, but we have to decide if a Dependency xor the parser should be context free or not (I personally prefer to have a context free description of a Dependency). I can change the code so that it is the other way around my making the default_features member of the Dependency an Optional<bool>.

I have created https://github.com/microsoft/vcpkg-docs/pull/119 for documentation

So much effort invested in this and no reviews or merges, I would like to see this merged if the PR is correct and working with big packages like qtbase or qt5-base.

Dear stakeholders, any progress on that?
This issue with ignoring default-features:false is a major source of pain for the development due to frequent unnecessary rebuilds. Also vcpkg CI doesn't cover some platforms at all such as QNX; lots of ports are buggy there and having minimal builds are the must..

Also just ran into this issue, would be really good to have!


too few components

I used over 1200 meshes to train lsfm, however I got only 4 components. Over 50 persons with different expressions were used. Visualizations of landmarks seem OK. Any ideas about this?

Same issue here.

Same issue here.


Bugfix: Ensure all GPG key servers use SSL

GPG hangs indefindely when accessing these HTTP urls, which prevents Docker build from completing. And fetching these keys over an unprotected channel probably enables MIM attacks.
🚨 We are not accepting PRs for new Definitions/Templates or Features in this repository. 🚨
If you are an owner of a community Definition/Template or Feature and would like to have it removed from this repository (e.g., because you are now self-publishing), please create a PR here and let us know. Otherwise, note that the majority of the contents of this repository been migrated to the https://github.com/devcontainers org.

For new Dev Container Features, see https://github.com/devcontainers/feature-template to get started and add your Feature into the index.
For new Definitions/Templates, see https://github.com/devcontainers/template-starter To get started and add your Template into the index.
Create PRs related to mcr.microsoft.com/devcontainers or mcr.microsoft.com/vscode/devcontainers images at https://github.com/devcontainers/images
Create PRs related to existing Dev Container Features managed by the Dev Container spec maintainers at https://github.com/devcontainers/features
Create PRs related to existing Dev Container Templates managed by the Dev Container spec maintainers at https://github.com/devcontainers/templates

🚨 Other locations 🚨

VS Code Dev Containers extension: http://github.com/Microsoft/vscode-remote-release
GitHub Codespaces: https://github.com/github/feedback/discussions/categories/codespaces
The Dev Container CLI: https://gtihub.com/devcontainers/cli
VS Code OSS: http://github.com/Microsoft/vscode

Thanks for the PR!


Bugfix/75 deprecate openssl 1

Describe your changes
Removed code calls to Openssl 1.1. Updated CMAKE to have a minimum version of OpenSSL 3.
Closes: https://github.com/EVerest/libevse-security/issues/75 https://github.com/EVerest/libevse-security/issues/38
Issue ticket number and link
https://github.com/EVerest/libevse-security/issues/75
https://github.com/EVerest/libevse-security/issues/38
Checklist before requesting a review

[x] I have performed a self-review of my code
[ ] I have made corresponding changes to the documentation
[ ] I read the contribution documentation and made sure that my changes meet its requirements

Updated, all entries mentioning OpenSSL.

Nice, good for consistency and code clean-up.
I'd like to see some of the (global) Dockerfiles and build instructions updated. I failed to find libssl3, even as PPA, for Debian 11 and Ubuntu 20.

For Ubuntu 20 the only option is manual install (from sources). Will have to see for Debian.

There are still some references to detection of OpenSSL v3, more code which can be reduced:
$ git -C ../libevse-security/ grep -rFn USING_OPENSSL_3  origin/bugfix/75-deprecate-openssl-1
origin/bugfix/75-deprecate-openssl-1:lib/evse_security/crypto/openssl/openssl_tpm.cpp:8:#define USING_OPENSSL_3 (OPENSSL_VERSION_NUMBER >= 0x30000000L)
origin/bugfix/75-deprecate-openssl-1:lib/evse_security/crypto/openssl/openssl_tpm.cpp:10:#if USING_OPENSSL_3 && defined(USING_TPM2)
origin/bugfix/75-deprecate-openssl-1:lib/evse_security/crypto/openssl/openssl_tpm.cpp:17:#define USING_OPENSSL_3_TPM
origin/bugfix/75-deprecate-openssl-1:lib/evse_security/crypto/openssl/openssl_tpm.cpp:45:#ifdef USING_OPENSSL_3_TPM
origin/bugfix/75-deprecate-openssl-1:lib/evse_security/crypto/openssl/openssl_tpm.cpp:223:#else // USING_OPENSSL_3_TPM
origin/bugfix/75-deprecate-openssl-1:lib/evse_security/crypto/openssl/openssl_tpm.cpp:260:#endif // USING_OPENSSL_3_TPM
origin/bugfix/75-deprecate-openssl-1:tests/tests.cpp:20:#define USING_OPENSSL_3 (OPENSSL_VERSION_NUMBER >= 0x30000000L)
origin/bugfix/75-deprecate-openssl-1:tests/tests.cpp:22:#if USING_OPENSSL_3
origin/bugfix/75-deprecate-openssl-1:tests/tests.cpp:52:#endif // USING_OPENSSL_3
origin/bugfix/75-deprecate-openssl-1:tests/tests.cpp:72:#if USING_OPENSSL_3
origin/bugfix/75-deprecate-openssl-1:tests/tests.cpp:125:#endif // USING_OPENSSL_3

Extra dependencies removed.


Always use blending for basic fill layers

Compared with the legacy renderer, we should always be using alpha blending for simple fill layers. I'm unable to replicate #2217 at the moment, unsure if this change will also address that issue.
Replicate with FB style, GLFW platform, press 'O' to toggle off online connectivity to permit sustained overzoom of fill layers which do overzoom color interpolation.
Before:

After

Seems to be fixed!!


Latest version now showing up in menu

For Glyphs Version 2.3b (839)? I installed the one that doesn't have 'old' in it's name.

839 is not the latest version. What exactly is the problem?

I can't activate it, as it's not appearing in the menu.

On 5 Feb 2016, at 8:10 pm, mekka blue<EMAIL_ADDRESS>wrote:
839 is not the latest version. What exactly is the problem?
—
Reply to this email directly or view it on GitHub.

Works now in updated Glyphs app


Cleanup

getting ready for ec2 let me know if you have any feedback

@bregbromley looks good Breg. Left few comments in there


My workflow: Duplicates

Hi,
here's our workflow at home: My wife and I each own a smartphone. We also have several cameras that we both use. We don't edit these photos much, just need a smart way to store and backup them all in one place.
On a regular basis, we used to copy the cameras' storage media's contents to a laptop that runs f-spot, a Linux photo management program. We don't remove photos on the storage cards right away, since f-spot doesn't import duplicates to its collection and auto-groups the collection based on the exif shot date. But f-spot appears to be abandoned software (or at least it's fairly difficult to have it built for current Ubuntu).
Lychee looks nice, but it doesn't handle duplicates properly for us to work.
Reading #48, it appears that you consider duplicates in the collection either a deliberate choice or a user's mistake. That's not true in our case. We just expect the software to handle duplicates by not importing them.
However, would you a accept a patch to Lychee that will check for duplicates during upload and removes them automatically?

How about building a tiny script that checks the database for duplicates and removed them? Should be easy to do by using the checksum and id (= upload time) values. What do you think?
Another idea would be a new setting in the database. Something like skipDuplicates.

In work :)

Lychee 3.0.3 includes the ability to skip duplicates on upload: https://github.com/electerious/Lychee/blob/master/docs/Settings.md#skip-duplicates-on-upload

Thank you! I will give it a try.


Replacing lookup('k8s'... with k8s_info

Lookups always execute on the ansible control machine
We think this will allow us to run this when hosts: jumphost

test

test

test

This needs to be backported to 1.4 as well. The same lookup block appears on that branch. The lookup was added after 1.3 , so the backport doesn't need to go that far

On it

Backport: https://github.com/infrawatch/service-telemetry-operator/pull/346


Support for Streaming

As has been stated, server-client-bidiStream is needed, but, currently the plugin seems to be stopped supporting

This issue was closed because it has been inactive for 14 days since being marked as stale.


Slow parsing when mixing directives with link like syntax

Initial checklist

[X] I read the support docs
[X] I read the contributing guide
[X] I agree to follow the code of conduct
[X] I searched issues and couldn’t find anything (or linked relevant results below)

Affected packages and versions
2.0.0
Link to runnable example
https://stackblitz.com/edit/node-wh1r9s?file=index.js
Steps to reproduce
Run
import { micromark } from "micromark";
import { directive, directiveHtml } from "micromark-extension-directive";

const content = `::name
:name[
text:name[
]:name]:name:name`;

console.log(
  micromark(content, {
    extensions: [directive()],
    htmlExtensions: [directiveHtml],
  })
);

Expected behavior
HTML is printed in a few seconds or less
Actual behavior
5 minutes of processing and counting, no result.
It may eventually return a document, but hasn't yet.
Runtime
Node v16
Package manager
npm v7
OS
Linux
Build and bundle tools
No response

reducing the issue a bit further
:name[
:name[
]
]

this may be related to nesting directives rather than links

with debugging and dev conditions on
$ DEBUG="*" node --conditions development test.mjs
  micromark main: passing `58` to start +0ms
  micromark position: restore: `{"line":1,"column":1,"offset":0,"_index":0,"_bufferIndex":0}` +1ms
  micromark main: passing `58` to flowStart +0ms
  micromark enter: `chunkFlow` +1ms
  micromark consume: `58` +0ms
  micromark main: passing `110` to flowContinue +0ms
  micromark consume: `110` +0ms
  micromark main: passing `97` to flowContinue +0ms
  micromark consume: `97` +0ms
  micromark main: passing `109` to flowContinue +0ms
  micromark consume: `109` +0ms
  micromark main: passing `101` to flowContinue +0ms
  micromark consume: `101` +0ms
  micromark main: passing `91` to flowContinue +0ms
  micromark consume: `91` +0ms
  micromark main: passing `-4` to flowContinue +0ms
  micromark consume: `-4` +0ms
  micromark position: after eol: `{"line":2,"column":1,"offset":7,"_index":1,"_bufferIndex":-1}` +1ms
  micromark exit: `chunkFlow` +0ms
  micromark position: define skip: `{"line":1,"column":1,"offset":0,"_index":0,"_bufferIndex":-1}` +0ms
  micromark main: passing `58` to start +0ms
  micromark position: restore: `{"line":1,"column":1,"offset":0,"_index":0,"_bufferIndex":0}` +0ms
  micromark main: passing `58` to start +0ms
  micromark enter: `directiveContainer` +0ms
  micromark enter: `directiveContainerFence` +0ms
  micromark enter: `directiveContainerSequence` +0ms
  micromark consume: `58` +0ms
  micromark main: passing `110` to sequenceOpen +0ms
  micromark position: restore: `{"line":1,"column":1,"offset":0,"_index":0,"_bufferIndex":0}` +1ms
  micromark main: passing `58` to start +0ms
  micromark enter: `directiveLeaf` +0ms
  micromark enter: `directiveLeafSequence` +0ms
  micromark consume: `58` +0ms
  micromark main: passing `110` to inStart +0ms
  micromark position: restore: `{"line":1,"column":1,"offset":0,"_index":0,"_bufferIndex":0}` +0ms
  micromark main: passing `58` to start +0ms
  micromark enter: `content` +0ms
  micromark enter: `chunkContent` +0ms
  micromark consume: `58` +0ms
  micromark main: passing `110` to data +0ms
  micromark consume: `110` +0ms
  micromark main: passing `97` to data +0ms
  micromark consume: `97` +0ms
  micromark main: passing `109` to data +0ms
  micromark consume: `109` +0ms
  micromark main: passing `101` to data +0ms
  micromark consume: `101` +0ms
  micromark main: passing `91` to data +0ms
  micromark consume: `91` +0ms
  micromark main: passing `-4` to data +0ms
  micromark exit: `chunkContent` +0ms
  micromark enter: `lineEnding` +0ms
  micromark consume: `-4` +0ms
  micromark position: after eol: `{"line":2,"column":1,"offset":7,"_index":1,"_bufferIndex":-1}` +0ms
  micromark exit: `lineEnding` +0ms
  micromark main: passing `58` to start +0ms
  micromark position: restore: `{"line":2,"column":1,"offset":7,"_index":2,"_bufferIndex":0}` +1ms
  micromark main: passing `58` to thereIsNoNewContainer +0ms
  micromark enter: `chunkFlow` +0ms
  micromark consume: `58` +0ms
  micromark main: passing `110` to flowContinue +0ms
  micromark consume: `110` +0ms
  micromark main: passing `97` to flowContinue +0ms
  micromark consume: `97` +0ms
  micromark main: passing `109` to flowContinue +0ms
  micromark consume: `109` +0ms
  micromark main: passing `101` to flowContinue +0ms
  micromark consume: `101` +0ms
  micromark main: passing `91` to flowContinue +0ms
  micromark consume: `91` +0ms
  micromark main: passing `-4` to flowContinue +0ms
  micromark consume: `-4` +0ms
  micromark position: after eol: `{"line":3,"column":1,"offset":14,"_index":3,"_bufferIndex":-1}` +0ms
  micromark exit: `chunkFlow` +0ms
  micromark position: define skip: `{"line":2,"column":1,"offset":7,"_index":2,"_bufferIndex":-1}` +0ms
  micromark main: passing `58` to start +0ms
  micromark enter: `directiveContainer` +0ms
  micromark enter: `directiveContainerFence` +0ms
  micromark enter: `directiveContainerSequence` +0ms
  micromark consume: `58` +0ms
  micromark main: passing `110` to sequenceOpen +0ms
  micromark position: restore: `{"line":2,"column":1,"offset":7,"_index":2,"_bufferIndex":0}` +0ms
  micromark main: passing `58` to start +0ms
  micromark enter: `directiveLeaf` +0ms
  micromark enter: `directiveLeafSequence` +0ms
  micromark consume: `58` +0ms
  micromark main: passing `110` to inStart +0ms
  micromark position: restore: `{"line":2,"column":1,"offset":7,"_index":2,"_bufferIndex":0}` +0ms
  micromark main: passing `58` to ok +0ms
  micromark position: restore: `{"line":1,"column":7,"offset":6,"_index":1,"_bufferIndex":-1}` +1ms
  micromark main: passing `-4` to contentContinue +0ms
  micromark consume: `-4` +0ms
  micromark position: after eol: `{"line":2,"column":1,"offset":7,"_index":1,"_bufferIndex":-1}` +0ms
  micromark exit: `chunkContent` +0ms
  micromark enter: `chunkContent` +0ms
  micromark main: passing `58` to data +0ms
  micromark consume: `58` +0ms
  micromark main: passing `110` to data +0ms
  micromark consume: `110` +0ms
  micromark main: passing `97` to data +0ms
  micromark consume: `97` +0ms
  micromark main: passing `109` to data +0ms
  micromark consume: `109` +0ms
  micromark main: passing `101` to data +0ms
  micromark consume: `101` +0ms
  micromark main: passing `91` to data +0ms
  micromark consume: `91` +0ms
  micromark main: passing `-4` to data +0ms
  micromark exit: `chunkContent` +0ms
  micromark enter: `lineEnding` +0ms
  micromark consume: `-4` +0ms
  micromark position: after eol: `{"line":3,"column":1,"offset":14,"_index":3,"_bufferIndex":-1}` +0ms
  micromark exit: `lineEnding` +0ms
  micromark main: passing `93` to start +0ms
  micromark position: restore: `{"line":3,"column":1,"offset":14,"_index":4,"_bufferIndex":0}` +0ms
  micromark main: passing `93` to thereIsNoNewContainer +0ms
  micromark enter: `chunkFlow` +0ms
  micromark consume: `93` +0ms
  micromark main: passing `-4` to flowContinue +0ms
  micromark consume: `-4` +0ms
  micromark position: after eol: `{"line":4,"column":1,"offset":16,"_index":5,"_bufferIndex":-1}` +0ms
  micromark exit: `chunkFlow` +0ms
  micromark position: define skip: `{"line":3,"column":1,"offset":14,"_index":4,"_bufferIndex":-1}` +0ms
  micromark main: passing `93` to start +0ms
  micromark position: restore: `{"line":2,"column":7,"offset":13,"_index":3,"_bufferIndex":-1}` +0ms
  micromark main: passing `-4` to contentContinue +0ms
  micromark consume: `-4` +0ms
  micromark position: after eol: `{"line":3,"column":1,"offset":14,"_index":3,"_bufferIndex":-1}` +1ms
  micromark exit: `chunkContent` +0ms
  micromark enter: `chunkContent` +0ms
  micromark main: passing `93` to data +0ms
  micromark consume: `93` +0ms
  micromark main: passing `-4` to data +0ms
  micromark exit: `chunkContent` +0ms
  micromark enter: `lineEnding` +0ms
  micromark consume: `-4` +0ms
  micromark position: after eol: `{"line":4,"column":1,"offset":16,"_index":5,"_bufferIndex":-1}` +0ms
  micromark exit: `lineEnding` +0ms
  micromark main: passing `93` to start +0ms
  micromark position: restore: `{"line":4,"column":1,"offset":16,"_index":6,"_bufferIndex":0}` +0ms
  micromark main: passing `93` to thereIsNoNewContainer +0ms
  micromark enter: `chunkFlow` +0ms
  micromark consume: `93` +0ms
  micromark main: passing `null` to flowContinue +0ms
  micromark exit: `chunkFlow` +0ms
  micromark position: define skip: `{"line":4,"column":1,"offset":16,"_index":6,"_bufferIndex":-1}` +0ms
  micromark main: passing `93` to start +0ms
  micromark position: restore: `{"line":3,"column":2,"offset":15,"_index":5,"_bufferIndex":-1}` +0ms
  micromark main: passing `-4` to contentContinue +0ms
  micromark consume: `-4` +0ms
  micromark position: after eol: `{"line":4,"column":1,"offset":16,"_index":5,"_bufferIndex":-1}` +0ms
  micromark exit: `chunkContent` +0ms
  micromark enter: `chunkContent` +0ms
  micromark main: passing `93` to data +0ms
  micromark consume: `93` +0ms
  micromark main: passing `null` to data +0ms
  micromark exit: `chunkContent` +0ms
  micromark exit: `content` +0ms
  micromark main: passing `58` to start +1ms
  micromark enter: `paragraph` +0ms
  micromark enter: `chunkText` +0ms
  micromark consume: `58` +0ms
  micromark main: passing `110` to data +0ms
  micromark consume: `110` +0ms
  micromark main: passing `97` to data +0ms
  micromark consume: `97` +0ms
  micromark main: passing `109` to data +0ms
  micromark consume: `109` +0ms
  micromark main: passing `101` to data +0ms
  micromark consume: `101` +0ms
  micromark main: passing `91` to data +0ms
  micromark consume: `91` +0ms
  micromark main: passing `-4` to data +0ms
  micromark consume: `-4` +0ms
  micromark position: after eol: `{"line":2,"column":1,"offset":7,"_index":1,"_bufferIndex":-1}` +0ms
  micromark exit: `chunkText` +0ms
  micromark position: define skip: `{"line":2,"column":1,"offset":7,"_index":2,"_bufferIndex":-1}` +0ms
  micromark main: passing `58` to lineStart +0ms
  micromark enter: `chunkText` +0ms
  micromark consume: `58` +0ms
  micromark main: passing `110` to data +0ms
  micromark consume: `110` +0ms
  micromark main: passing `97` to data +0ms
  micromark consume: `97` +0ms
  micromark main: passing `109` to data +0ms
  micromark consume: `109` +0ms
  micromark main: passing `101` to data +0ms
  micromark consume: `101` +1ms
  micromark main: passing `91` to data +0ms
  micromark consume: `91` +0ms
  micromark main: passing `-4` to data +0ms
  micromark consume: `-4` +0ms
  micromark position: after eol: `{"line":3,"column":1,"offset":14,"_index":3,"_bufferIndex":-1}` +0ms
  micromark exit: `chunkText` +0ms
  micromark position: define skip: `{"line":3,"column":1,"offset":14,"_index":4,"_bufferIndex":-1}` +0ms
  micromark main: passing `93` to lineStart +0ms
  micromark enter: `chunkText` +1ms
  micromark consume: `93` +0ms
  micromark main: passing `-4` to data +0ms
  micromark consume: `-4` +0ms
  micromark position: after eol: `{"line":4,"column":1,"offset":16,"_index":5,"_bufferIndex":-1}` +0ms
  micromark exit: `chunkText` +0ms
  micromark position: define skip: `{"line":4,"column":1,"offset":16,"_index":6,"_bufferIndex":-1}` +0ms
  micromark main: passing `93` to lineStart +0ms
  micromark enter: `chunkText` +0ms
  micromark consume: `93` +0ms
  micromark main: passing `null` to data +0ms
  micromark exit: `chunkText` +0ms
  micromark exit: `paragraph` +0ms
  micromark consume: `null` +0ms
  micromark main: passing `null` to afterConstruct +0ms
  micromark consume: `null` +0ms
  micromark consume: `null` +0ms
  micromark main: passing `58` to start +0ms
  micromark enter: `directiveText` +0ms
  micromark enter: `directiveTextMarker` +0ms
  micromark consume: `58` +0ms
  micromark exit: `directiveTextMarker` +0ms
  micromark main: passing `110` to start +1ms
  micromark enter: `directiveTextName` +0ms
  micromark consume: `110` +0ms
  micromark main: passing `97` to name +0ms
  micromark consume: `97` +0ms
  micromark main: passing `109` to name +0ms
  micromark consume: `109` +0ms
  micromark main: passing `101` to name +0ms
  micromark consume: `101` +0ms
  micromark main: passing `91` to name +0ms
  micromark exit: `directiveTextName` +0ms
  micromark enter: `directiveTextLabel` +0ms
  micromark enter: `directiveTextLabelMarker` +0ms
  micromark consume: `91` +0ms
  micromark exit: `directiveTextLabelMarker` +0ms
  micromark main: passing `-4` to afterStart +0ms
  micromark enter: `directiveTextLabelString` +0ms
  micromark enter: `lineEnding` +0ms
  micromark consume: `-4` +0ms
  micromark position: after eol: `{"line":2,"column":1,"offset":7,"_index":1,"_bufferIndex":-1}` +0ms
  micromark exit: `lineEnding` +0ms
  micromark position: define skip: `{"line":2,"column":1,"offset":7,"_index":2,"_bufferIndex":-1}` +0ms
  micromark main: passing `58` to atBreak +0ms
  micromark enter: `chunkText` +0ms
  micromark consume: `58` +1ms
  micromark main: passing `110` to label +0ms
  micromark consume: `110` +0ms
  micromark main: passing `97` to label +0ms
  micromark consume: `97` +0ms
  micromark main: passing `109` to label +0ms
  micromark consume: `109` +0ms
  micromark main: passing `101` to label +0ms
  micromark consume: `101` +0ms
  micromark main: passing `91` to label +0ms
  micromark consume: `91` +0ms
  micromark main: passing `-4` to label +0ms
  micromark exit: `chunkText` +0ms
  micromark enter: `lineEnding` +0ms
  micromark consume: `-4` +0ms
  micromark position: after eol: `{"line":3,"column":1,"offset":14,"_index":3,"_bufferIndex":-1}` +0ms
  micromark exit: `lineEnding` +0ms
  micromark position: define skip: `{"line":3,"column":1,"offset":14,"_index":4,"_bufferIndex":-1}` +0ms
  micromark main: passing `93` to atBreak +0ms
  micromark enter: `chunkText` +0ms
node:internal/process/esm_loader:74
    internalBinding('errors').triggerUncaughtException(
                              ^

AssertionError [ERR_ASSERTION]: expected non-empty token (`chunkText`)
    at Object.exit (./node_modules/micromark/dev/lib/create-tokenizer.js:311:5)
    at label (.-fuzz/node_modules/micromark-extension-directive/dev/lib/factory-label.js:109:15)
    at atBreak (./node_modules/micromark-extension-directive/dev/lib/factory-label.js:87:12)
    at go (./node_modules/micromark/dev/lib/create-tokenizer.js:218:13)
    at main (./node_modules/micromark/dev/lib/create-tokenizer.js:198:11)
    at Object.write (./node_modules/micromark/dev/lib/create-tokenizer.js:124:5)
    at subcontent (./node_modules/micromark-util-subtokenize/dev/index.js:190:17)
    at subtokenize (./node_modules/micromark-util-subtokenize/dev/index.js:82:30)
    at postprocess (./node_modules/micromark/dev/lib/postprocess.js:12:11)
    at micromark (./node_modules/micromark/dev/index.js:37:9) {
  generatedMessage: false,
  code: 'ERR_ASSERTION',
  actual: false,
  expected: true,
  operator: '=='
}

There seems to be a problem with nested "empty" directives:
  t.equal(
    micromark(':a[\n]', options({'*': h})),
    '
\n
',
    'should not choke on a linebreak'
  )

✅ passes but
  t.equal(
    micromark(':a[b[\n]]', options({'*': h})),
    '
\n
',
    'should not choke on nested directive with linebreak'
  )

❌ fails with the above error

Going further into possible inputs i am not sure what even should happen in this cases:
  t.equal(
    micromark(':a[\\]', options({'*': h})),
    '
???
',
    'what should happen here?'
  )

❓ results in
[]
 and
  t.equal(
    micromark(':a[:b[\\\n]]', options({'*': h})),
    '???',
    'what should happen here?'
  )

❌results in the parse error

Maybe not directly related, but nesting seems to have a limit too:
  t.equal(
    micromark(':a[:b[:c[:d[Test]{x="2"}]]]{y="3"}', options({'*': h})),
    '
<c><d x="2">Test</d></c>
',
    'should support nesting level greater than 3'
  )

✅works fine but
  t.equal(
    micromark(':a[:b[:c[:d[:e[Test]{x="2"}]]]]{y="3"}', options({'*': h})),
    '
<c><d><e x="2">Test</e></d></c>
',
    'should support nesting level greater than 4'
  )

❌fails with:
    operator: equal
    expected: |-
      '
<c><d><e x="2">Test</e></d></c>
'
    actual: |-
      '
[<c><d><e x="2">Test</e></d></c>]{y="3"}
'

Thanks for the repros @chartinger.

':a[\n]' — works as expected
':a[:b[\n]]' — 🐞 yep, that’s a bug!
':a[\\]' — This is expected. You use a JavaScript escape in the string, to create a slash in markdown:  :a[\], which is a markdown escaped ], and as there’s no further ], it can’t be a label. It should yield
[]
, which it does, so it works as expected.
':a[:b[\\\n]]' — The first is an escaped slash in JavaScript, so markdown sees :a[:b[\␤]] (where ␤ represents a line feed), so that would be a hard break (in markdown,
 in HTML), will investigate 🔎
':a[:b[:c[:d[Test]{x="2"}]]]{y="3"}', and 6. — it’s unrelated indeed, but the good part is that the last one was just changed. It’s a security measure, but it was changed from 3 to 32: https://github.com/micromark/micromark/commit/5194939a2f2de3bbae06ec225e9a0c4272852a86.

Thanks all! Released!


Sync with latest code on decidim-liquidvoting

The client on liquidvotingio/decidim-liquidvoting has diverged from the repo, and we should update the latter once the current round of changes is done.
And package as a gem asap (#3)

The latest client code in that repo also has some issues being tracked here liquidvotingio/decidim-module-liquidvoting#32. I propose we both resync the code and fix those things here in this repo, where we have spec support.
So the workflow might be like this:

copy their current work https://github.com/liquidvotingio/decidim-module-liquidvoting/blob/emulate-original-vote-button/lib/decidim/liquidvoting/client.rb back here as liquid_voting_api.rb
fix specs if needed
drive the work in liquidvotingio/decidim-module-liquidvoting#32 here, using specs
copy the resulting liquid_voting_api.rb back to their repo as client.rb (or finish #3 and move that repo to use the gem instead of client.rb)

This should include normalizing the return value for the four mutators, both in the graphql query and the return value from the api client, as is being done in liquidvoting/decidim-module-liquidvoting - api_client.rb


Fix gpg prereq to be gnupg [Closes #1397]

Docs Build status updates of commit b8b603e:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-conceptual/install-azure-cli-apt.md
:white_check_mark:Succeeded
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)

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


Batches UI - Creates duplicate datasets

Creating a dataset through the UI ends up creating two (almost) identical dataset objects: one without the selected files and one with.
To reproduce:

Navigate to the create batches UI
Fill in the first step information (this isn't important here since we aren't actually going to create a batch)
Go to step two and fill in the dataset information. for example:
Title: Duplicate Dataset
Description: Dataset doubles!
Start/end: 3/22/2020 - 3/23/2020
Ingest Time
Click  Query Data Files, then Create Dataset
Navigate to /api/v6/datasets and look for your dataset. There will be two entries: one with files, one without.

Closed via #1882


poetry install --with test: Group(s) not found: test (via --with)

System Info
I am trying to setup the local development environment with poetry install --with test but I am running into the error Group(s) not found: test (via --with)
> origin/master:master via 🐍 v3.11.6
> 57% langchain ❯ poetry install --with test

Group(s) not found: test (via --with)

Could you advise on what might be happening here?
Who can help?
@eyurtsev, I think you might be able to advise here? 🙏🏼
Information

[ ] The official example notebooks/scripts
[ ] My own modified scripts

Related Components

[ ] LLMs/Chat Models
[ ] Embedding Models
[ ] Prompts / Prompt Templates / Prompt Selectors
[ ] Output Parsers
[ ] Document Loaders
[ ] Vector Stores / Retrievers
[ ] Memory
[ ] Agents / Agent Executors
[ ] Tools / Toolkits
[ ] Chains
[ ] Callbacks/Tracing
[ ] Async

Reproduction

Clone repository
With poetry installed, run poetry install --with test

Expected behavior
Local development setup works without an error.

choose the pyproject.toml that corresponds to the lib that you're working with:
cd: libs/langchain for langchain
or: libs/experimental for langchain_experimental
then use the poetry command

Thank you, @eyurtsev! That helped.


BUG: Schema possibly broken for ComponentsApi::getComponentDetails()

<EMAIL_ADDRESS>No error and the proper purls are being passed but the results are empty

I've been unable to reproduce this @maurycupitt - do you have a concrete example?

Not sure there is an actual issue here - just logging is confusing/not working as expected @maurycupitt


⚠ LPDM Handbook (hosted on Divio) has degraded performance

In c237673, LPDM Handbook (hosted on Divio) (https://repohubdev.tk) experienced degraded performance:

HTTP code: 500
Response time: 5376 ms

Resolved: LPDM Handbook (hosted on Divio) performance has improved in 50168a3.


CREATE A FORM COMPONENT FOR SETTING NEW GOALS

[ ] the form should show several fields required for creating a new goal
[ ] the form should show a submit button
[ ] the form should have a close button if the user wishes to opt-out

Cool, you description is top notch 😘

Testing link:
https://goals.zuri.chat/
Note: Click on the open modal button to view the create form modal. (The 'new goal' button is in a component that's not ready)

Nice work :+1:


6-move win for FUNKY

Hi! Just left a comment on your Medium article 😊. I think there might be a problem with your benchmark script? Or maybe a typo in reporting the results in your article. I've found that your solver gives a 6-move solution for FUNKY, using ROATE as the starting word:

Your article cited a maximum of 5 moves for ROATE. Do you know if there's an issue with the benchmarking script?
Thanks!

you guessed 2 starter words instead of just 1 of them

Got it -- thanks for the clarification!  Guess I misunderstood how to use the program.


[Doc] [StarRocks Sink] Lost base-url option in the document

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
From the code we know StarRocks Sink need a required option named base-url, but I am not found it in the document https://seatunnel.apache.org/docs/2.3.2/connector-v2/sink/StarRocks
Advanced
Since #4572 We have a new document format specification. Can you update StarRocks Sink document reference https://github.com/apache/seatunnel/issues/4544 and https://github.com/apache/incubator-seatunnel/blob/dev/docs/en/connector-v2/sink/Mysql.md?plain=1 ?
SeaTunnel Version
dev
SeaTunnel Config
*

Running Command
*

Error Exception
*

Flink or Spark Version
No response
Java or Scala Version
No response
Screenshots
No response
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

pls assign to me

pls assign to me

Already assigned to you.

@EricJoy2048  i find the document already has the base-url option.

https://github.com/apache/seatunnel/blob/dev/docs/en/connector-v2/sink/StarRocks.md?plain=1#L20

https://seatunnel.apache.org/docs/2.3.2/connector-v2/sink/StarRocks

Ok, Thanks. Do you want to help seatunnel improve the document of other connector? You can comment this issue https://github.com/apache/seatunnel/issues/4572 and let we know.


Revisit error/panic handling in Begin/End blocker

Follow up on https://github.com/confio/tgrade/pull/31#discussion_r616153388
See also:
https://github.com/confio/tgrade/pull/31#discussion_r616154009
Context:
Any unhandled panic would be stopping the node. But there may be no way to recover so that stopping the node is the right thing.

This is a question about robustness. Maybe we can have a compile-time flag for this.
On tests and testnets, I want this fail-fast behavior.
On mainnet, I would rather just log the error. We can continue with a semi-broken chain and perform a migration to fix it rather than halt the chain with no chance of recovery.
Can you add a compile-time flag around this behavior? (set var via the -X thing). Default is set, panic on error can be disabled when preparing mainnet binary

Hi @alpe can you explain the value of doing this for Mainnet MVP and what the estimation is?

Currently, if there is any error when running the staking contract, then the chain will halt.
This change would mean the chain would continue, log an error (which may or may not be seen), and just not update the validator set until we can upgrade the contract (which will still be possible as the chain will be live).
It would make upgrades on the most critical contracts safer, and is good to have. I am not sure how important it is for mainnet, but I also think it is relatively small to do, and would be nice to have if it doesn't blow up the scope much

I took another look at the current implementation:

begin block callback
error or panic -> logged only, state reverted
end block callback
error or panic -> logged only, state reverted
valset updater callback
error or panic will halt the node

I would change 3) now to also handle errors and panics to the logger.
Fail fast artifacts are bit more work though as we use the same artifacts currently. I


Permanently disable DHCP tests for debian-10 and debian-11

The tests need to be adjusted to the new guest-agent network manager interface implementation, all the exceptions must be addressed (i.e. not all systems will have dhclient processes for both primary and secondary nics).

/lgtm


Add callback for handling internal links

I think this is fine for now.  I wanted to see what happens if it can't find the file that matches the URL of the internal link.  In that case, it logs an error and the reader simply goes to the first resource of the book.

Ha, probably something to handle in go() to abort (and return false) if the link.href can't be found in the readingOrder. It's not directly related to this PR though, so not a blocking issue for the review. I guess the same would happen if a table of contents has a broken link.


v2 package-versions auto-complete endpoint should exclude deleted versions

Fixes #4092

@joelverhagen this is a production issue, so I'd suggest we get the fix in asap, and log another issue to track the need for testing/improving this particular piece of code.

Tracking issue for test-coverage/improvement https://github.com/NuGet/NuGetGallery/issues/4094


Add unionsWith?

This function doesn't currently exist, but I think it could, and would potentially be useful:
unionsWith :: forall f k v. (Foldable f, Ord k) => (v -> v -> v) -> f (Map k v) -> Map k v

It's probably very simple to define this using what's already exported, but I think it's still useful to have these sorts of things defined for you.

:+1:

@paf31 just trying to pick up a ticket to get started with contributing, is this being worked on?
I assume this would need the unionsWith function added then exposed and testes?

@Cmdv Yes, that's right, thanks!

@paf31 cool I'll give it a go 😄

unionWith is slightly different, it only combines two maps. unionsWith could be used to take the union of an array with any number of maps inside it, for example.

@hdgarrood just got pointed out to me on IRC by garyb as well!! I'll probably get stuck when it comes to testing but I'll crack on :)

For tests, one property to check off the top of my head: the keys of all the maps that were unioned should exist in the resulting map.

Also just to note, we can drop Ord from the signature with the very latest -maps release (it's about 10 minutes old):
unionsWith :: forall f k v. Foldable f => (v -> v -> v) -> f (Map k v) -> Map k v

@garyb how would that work??? 😕
With traverse it's fine as we're reconstructing a map in the same way we deconstruct it.  But here we're having to combine maps - which means we need to insert the keys in the right place relative to each other.

Uh, yeah, I'm talking nonsense 😆... disregard that.


s/should/SHOULD/ in a few spots, also a s/should/must/

The capslock changes speak for themselves. I tried to avoid situations where deliberately capitalizing SHOULD were too prescriptive.
As for the s/should/MUST/, I think it's appropriate here as there will never be a situation where aborting on invalid keys is a thing that is allowed. I hope you agree that this is an appropriate change.
Thanks!

LGTM overall, but the changes to config.md are really crying out for something like #492 to land, so we can clarify the image<->runtime relationship.

LGTM


Cannot change properties in mocked $window.navigator

When I'm running tests that have to do with changes in $window.navigator, I'm trying to simulate these changes by doing something such as $window.navigator.onLine = true;, but that has no effect as the property is still false. Understandably modifying readonly $window properties should not be possible in production when using AngularJS, but for testing purposes it seems necessary to be able to modify the mocked $window object to truly verify the functionality of the code interacting with these services.

Also, is it possible for this change to accordingly trigger the online and offline events if this is implemented?

@lgalfaso @petebacondarwin @gkalpak is this something that is already possible or does it need to be added into AngularJS's mock?

I don't think there is a mocked window object in AngularMock (it doesn't need to be), but you are free to mock it out as needed.
I don't think it is useful (or at all possible), to mock everything on window and it would be an unnecessary overhead for the majority of tests that don't need it. The current behaviour (allowing $window to be mocked) is lightweight and flexible enough to cover the needs.
(That's one of the major points about DI - being able to easily mock ddependencies out (be it for testing or elsewhere).)
Here is a simple demo, mocking out $window.navigator.

@davidlmiller21 There is a decent mock window object used in out $location tests if you want to use it as a starting point for mocks in your own applications: https://github.com/angular/angular.js/blob/master/test/ng/locationSpec.js#L2533-L2570

Thanks for the help.  Fixed it.


Noise problem

When I run your program, I noticed some artifacts on the screen. They looked like some noise.
Then I zoomed in on the picture on the project home page and found that you had the same problem.
Is it a bug? or a problem of DDGI?

Since the direct lighting only renders also have these artifacts, we can presume that these speckles are not an inherent issue in DDGI and could be the result of a few calculations:

shadow acne caused by incorrect offsetting (often too little) of the ray intersection point
floating point error when intersecting the ray against the implicit surfaces (either surface or light source or probe)

We would have to play with the intersection offset value, the sample rate / number of bounces, and the implicit surface intersection calculation to know for sure. Additionally, there is no de-noising or antialiasing applied to our path tracer. This project was more of a proof of concept done over the course of 4 weeks, so there's always places to improve ~~ For more bugs specifically related to DDGI, I would reference the paper and their official code since I'm sure they'd be able to provide more insight :)


fix(P-6319): fix types for join network, add observer wallet

Replaces - https://github.com/ar-io/ar-io-sdk/pull/78

Codecov Report
Attention: Patch coverage is 50.00000% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 80.86%. Comparing base (0320c23) to head (c2bac78).

Files
Patch %
Lines

src/common/ar-io.ts
50.00%
1 Missing :warning:

Additional details and impacted files
@@           Coverage Diff           @@
##            alpha      #83   +/-   ##
=======================================
  Coverage   80.86%   80.86%
=======================================
  Files          19       19
  Lines         465      465
  Branches       95       94    -1
=======================================
  Hits          376      376
- Misses         85       89    +4
+ Partials        4        0    -4

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


Retry policies should define what error codes are retryable.

The prototypes have hardcoded values for this.  This is related to #548, if we map the error codes then the policies just need to know which mapped error codes are retryable.

This was fixed by #752


feat(indyVdr): IndyVdrAnonCredsRegistry

This PR implements the IndyVdrAnonCredsRegistry without revocation.
Work funded by the Government of Ontario

Codecov Report

Merging #1270 (64fd350) into main (f1e4937) will increase coverage by 3.48%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1270      +/-   ##
==========================================
+ Coverage   75.08%   78.56%   +3.48%
==========================================
  Files         657      672      +15
  Lines       15896    16453     +557
  Branches     2698     2823     +125
==========================================
+ Hits        11935    12926     +991
+ Misses       3958     3523     -435
- Partials        3        4       +1

Impacted Files
Coverage Δ

.../src/ledger/error/IndySdkPoolNotConfiguredError.ts
100.00% <0.00%> (ø)

packages/indy-sdk/src/utils/assertIndySdkWallet.ts
50.00% <0.00%> (ø)

packages/indy-sdk/src/wallet/IndySdkWallet.ts
26.35% <0.00%> (ø)

...y-sdk/src/ledger/error/IndySdkPoolNotFoundError.ts
100.00% <0.00%> (ø)

packages/indy-sdk/src/error/IndySdkError.ts
40.00% <0.00%> (ø)

packages/indy-sdk/src/error/indyError.ts
66.66% <0.00%> (ø)

packages/indy-sdk/src/ledger/IndySdkPool.ts
17.64% <0.00%> (ø)

...ages/indy-sdk/src/ledger/error/IndySdkPoolError.ts
100.00% <0.00%> (ø)

packages/indy-sdk/src/utils/promises.ts
100.00% <0.00%> (ø)

packages/indy-sdk/src/ledger/IndySdkPoolService.ts
70.07% <0.00%> (ø)

... and 89 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Parameter fix

Fixed issues with -Before and -After Parameter

Hi @Evilcat182
Thanks for spotting and fixing these! The logic looks good to me, are you willing/able to remove the whitespace on L98 and fix the space on the if statement on L99 (for consistency)? I don't mind doing it myself post merge but I'd prefer to not immediately alter your changes!
Whichever you prefer, I'll try and get this out as 0.4.1 ASAP.

Hi @phlcrny
I've added a new commit with the requested formatting changes.

Thanks! Really appreciate the contribution.


update NextVersion.md with newly public classes

PRs upon which this one is dependent:
#1097
[...if you add to this PR please link the PR containing your changes here...]

I'll add ThematicDisplay.

i'll leave this PR open so others can add to it too.

i'll leave this PR open so others can add to it too.

Can you close it then so that it's not constantly rebuilding?

i'll leave this PR open so others can add to it too.

Can you close it then so that it's not constantly rebuilding?

I don't see any way to change a PR to draft. Instead of closing it, can you make a "request changes" comment (I don't seem to be able to do that on my own PR)?

I don't see any way to change a PR to draft. Instead of closing it, can you make a "request changes" comment (I don't seem to be able to do that on my own PR)?

That doesn't stop the constant rebuild cycle (@calebmshafer's PR to change that has not yet been merged).
You sure it's not simpler and less error-prone for people just to update NextVersion.md in the same PR that updates their release tags?

That doesn't stop the constant rebuild cycle (@calebmshafer's PR to change that has not yet been merged).
You sure it's not simpler and less error-prone for people just to update NextVersion.md in the same PR that updates their release tags?

I see "Merging is blocked" in red below. That means it will rebuild when someone actually pushes to this PR, but it won't get merged/rebuilt when another PR completes. Sounds right to me. But, I will complete it now (after a successful build).


[NDM] Add configs for enabling/disabling Cisco SD-WAN metrics collection

What does this PR do?
Add configs for enabling/disabling Cisco SD-WAN metrics collection
NDMII-2951

Motivation

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

/merge


Create resampler with dictionary of options

The libswresample resampler can be created with a dictionary of options. This pull request adds it to the rust-ffmpeg Context API with a new function Context::get_with modelled after Audio::open_with.
Context::get_with(
    sample_format_fltp(),
    ChannelLayout::MONO,
    source_sample_rate as u32,
    sample_format_fltp(),
    ChannelLayout::MONO,
    dest_sample_rate as u32,
    [("resampler", "soxr"), ("precision", "32")]
        .iter()
        .collect(),
)

I was under the impression that swr_alloc_set_opts is already an alternative to sw_alloc plus a bunch of av_opt_set_*, but admittedly I haven't used swresample much. May I ask what are some examples of options that are not already covered?
Also, I wonder if it's better to implement the util::options::Settable trait than adding a method like this.

There are a bunch of options that can be set but only before swr_init is called, which is why I made the implementation to hijack the path between swr_alloc_* and swr_init inside the get constructor instead of implementing Settable and adding an explicit init. Maybe a builder pattern would be even better?
Regarding these additional options, In my example above (first message of PR) I changed the parameters "resampler" to "soxr" and "precision" to "28". The swr_alloc_* APIs don't have the parameters to change the engine or precision of sample rate conversion.
You can have a look at the effect of these parameters here: https://src.infinitewave.ca/ by selecting "ffmpeg 4.2.2 (swr)" vs. "ffmpeg 4.2.2 (soxr)". The performance impact of changing to soxr is big enough that is should be left to the user to select what he wants.

Damn, focused on your diff and didn't see your example, sorry... Yeah, seems like a reasonable addition.

There are a bunch of options that can be set but only before swr_init is called

Yeah, I did realize that shortly after suggesting the Settable trait. Another option is to expose standalone swr_init separately. That would be slightly more generalized as it allows reconfiguration, but I think I'll go with yours until someone presents an actual use case.
Will merge shortly.

Merged in dc2a82f, and released v4.3.8. Thanks for the contribution.


Using ArrayList to instead of LinkedList

Please answer these questions before submitting pull request

Why submit this pull request?

[ ] Bug fix

[ ] New feature provided

[x] Improve performance

Related issues
#3064
#3021

New feature or improvement

Describe the details and related test reports.

According to #3064, we can learn ArrayList has ~3x faster than LinkedList.

Fix CI and test first


Spring cleanup

project layout change
CI cleanup

Codecov Report

Merging #80 into master will decrease coverage by 1.51%.
The diff coverage is 76.64%.

@@            Coverage Diff             @@
##           master      #80      +/-   ##
==========================================
- Coverage   77.22%   75.71%   -1.52%
==========================================
  Files           8        9       +1
  Lines        1471     1503      +32
==========================================
+ Hits         1136     1138       +2
- Misses        250      280      +30
  Partials       85       85

Impacted Files
Coverage Δ

pkg/container/mock.go
6.25% <ø> (ø)

pkg/container/util.go
100% <ø> (ø)

pkg/container/mockengine_responses.go
100% <ø> (ø)

pkg/container/http_client.go
0% <ø> (ø)

pkg/container/sort.go
90.9% <ø> (ø)

pkg/container/container.go
88.23% <ø> (ø)

pkg/container/client.go
73.8% <73.8%> (ø)

pkg/action/chaos.go
73.84% <73.84%> (ø)

cmd/main.go
78.91% <78.91%> (ø)

... and 3 more

Continue to review full report at Codecov.

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


re-enable hubot-letschat now templates are working again

re-enable hubot-letschat now templates are working again

Refer to this link for build results (access rights to CI server needed):
https://fabric8-ci.fusesource.com/job/fabric8-quickstarts-master-pullreq/401/
Test PASSed.


Allow use of custom HostnameVerifier on clients.

While the improvements to TLS configuration of HTTP clients in 1.0.0
(maybe prior) are awesome, as part of that process the ability to set a
custom HostnameVerifier easily on the HTTP client has been lost.
You used to be able to do e.g. as:
JerseyClientConfiguration myJerseyClientConfiguration = ;
HostnameVerifier verifier = new MyCustomHostnameVerifier();
JerseyClientBuilder clientBuilder = new JerseyClientBuilder(env);
clientBuilder.using(myJerseyClientConfiguration).using(verifier);
Client httpClient = clientBuilder.build();
Same is true for HttpClientBuilder too.
You can still do it by creating a custom Apache
Registry but you need to set up socket
factories for every scheme.
This change restores the ability to set a custom HostnameVerifier
for clients.
[Fixes #1663]

Also, I wasn't sure how to approach writing a unit test in HttpClientBuilderTest.java. Some guidance there would be appreciated.

Coverage decreased (-0.1%) to 82.093% when pulling 205a16ed543ac03ac3254504eb907bfbf89a77a1 on anonyome:tbartley/dw-client-custom-hostname-verifier into 0880fcdfd1c37e2343c362ba7b23b2d14ff09d8e on dropwizard:release/1.0.x.

Coverage decreased (-0.05%) to 82.153% when pulling bc5c482a720da6ae8b2805a4e6220d7ff252138a on anonyome:tbartley/dw-client-custom-hostname-verifier into 0880fcdfd1c37e2343c362ba7b23b2d14ff09d8e on dropwizard:release/1.0.x.

Also, I wasn't sure how to approach writing a unit test in HttpClientBuilderTest.java. Some guidance there would be appreciated.

I think you could mark the method createConfiguredRegistry as package protected and put the @VisibleForTesting annotation on it. Then you could invoke it in tests:
HostnameVerifier customVerifier = (s, sslSession) -> false;
Registry<ConnectionSocketFactory> configuredRegistry = builder
    .using(customVerifier)
    .createConfiguredRegistry();

Then we could retrieve the SSL socket factory from the registry and extract the verifier from it via reflection. Something like that:
SSLConnectionSocketFactory socketFactory =
(SSLConnectionSocketFactory) configuredRegistry.lookup("https");
final Field hostnameVerifierField =
    FieldUtils.getField(SSLConnectionSocketFactory.class, "hostnameVerifier", true);

Coverage decreased (-0.02%) to 82.185% when pulling e95b081a04b1c86f9d7c818a3dd52257f46bf792 on anonyome:tbartley/dw-client-custom-hostname-verifier into 0880fcdfd1c37e2343c362ba7b23b2d14ff09d8e on dropwizard:release/1.0.x.

Coverage decreased (-0.0006%) to 82.2% when pulling c5be7045992f09046f740fc7fbf81677d35bc3a3 on anonyome:tbartley/dw-client-custom-hostname-verifier into 0880fcdfd1c37e2343c362ba7b23b2d14ff09d8e on dropwizard:release/1.0.x.

Coverage increased (+0.03%) to 82.23% when pulling 04f19ad7945c5a1475e15b35431da41997dc7d67 on anonyome:tbartley/dw-client-custom-hostname-verifier into 0880fcdfd1c37e2343c362ba7b23b2d14ff09d8e on dropwizard:release/1.0.x.

Thanks for the feedback @arteam I've made your suggested changes and implemented additional unit test coverage following your suggested pattern.
I ummed and ahhed over the DropwizardSSLConnectionSocketFactory constructor unit test using reflection to check private field value but I liked using a getter for the verifier field on this class even less since it would imply getter for tlsConfiguration field for consistency which exposes that to internal modification which implies need for immutable TlsConfiguration .... Also, the getter would've needed to be public rather than package protected since unit test is in a different package.
I have also squashed my commits.

Coverage increased (+0.03%) to 82.23% when pulling 160502f5bad6027e50625fe084260eca9f6b270c on anonyome:tbartley/dw-client-custom-hostname-verifier into 0880fcdfd1c37e2343c362ba7b23b2d14ff09d8e on dropwizard:release/1.0.x.

Thank you very much for your contribution!

No problem at all. This software works so well for us. Thank you for the far greater contribution you make.