Fix AWS IAM Roles for Service Accounts permission problem.

Amazon EKS supports IAM Roles for Service Accounts. It mounts tokens files to /var/run/secrets/eks.amazonaws.com/serviceaccount/token. Unfortunately, external-dns runs as 'nobody' so it cannot access this file. External DNS is then unable to make any AWS API calls to work:
time="2019-09-11T07:31:53Z" level=error msg="WebIdentityErr: unable to read file at /var/run/secrets/eks.amazonaws.com/serviceaccount/token\ncaused by: open /var/run/secrets/eks.amazonaws.com/serviceaccount/token: permission denied"

See: https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-technical-overview.html
Below are the file permissions mounted on External DNS pod:
~ $ ls -al /var/run/secrets/eks.amazonaws.com/serviceaccount/
total 0
drwxrwxrwt    3 root     root           100 Sep 11 06:40 .
drwxr-xr-x    3 root     root            28 Sep 11 06:40 ..
drwxr-xr-x    2 root     root            60 Sep 11 06:40 ..2019_09_11_06_40_49.865776187
lrwxrwxrwx    1 root     root            31 Sep 11 06:40 ..data -> ..2019_09_11_06_40_49.865776187
lrwxrwxrwx    1 root     root            12 Sep 11 06:40 token -> ..data/token
~ $ ls -al /var/run/secrets/eks.amazonaws.com/serviceaccount/..data/token
-rw-------    1 root     root          1028 Sep 11 06:40 /var/run/secrets/eks.amazonaws.com/serviceaccount/..data/token

Pinging @taharah for review.

Updated CLA account settings.

Interesting. Do you know how the file permissions are for the Kubernetes service account token? Because this is mounted in a similar way and works with the nobody user.

Kubernetes tokens seems to be o+r
/run/secrets/kubernetes.io/serviceaccount $ ls -al
total 0
drwxrwxrwt    3 root     root           140 Sep 11 07:31 .
drwxr-xr-x    3 root     root            28 Sep 11 07:31 ..
drwxr-xr-x    2 root     root           100 Sep 11 07:31 ..2019_09_11_07_31_49.116680770
lrwxrwxrwx    1 root     root            31 Sep 11 07:31 ..data -> ..2019_09_11_07_31_49.116680770
lrwxrwxrwx    1 root     root            13 Sep 11 07:31 ca.crt -> ..data/ca.crt
lrwxrwxrwx    1 root     root            16 Sep 11 07:31 namespace -> ..data/namespace
lrwxrwxrwx    1 root     root            12 Sep 11 07:31 token -> ..data/token
/run/secrets/kubernetes.io/serviceaccount $ ls -al ..data/
total 12
drwxr-xr-x    2 root     root           100 Sep 11 07:31 .
drwxrwxrwt    3 root     root           140 Sep 11 07:31 ..
-rw-r--r--    1 root     root          1025 Sep 11 07:31 ca.crt
-rw-r--r--    1 root     root            12 Sep 11 07:31 namespace
-rw-r--r--    1 root     root           875 Sep 11 07:31 token

Very interesting, this means containers must run as root to use this feature. I don't think this is intended and we should make at least AWS aware.

Comparing the two codes doesn't show any hints on why they differ in permissions:
https://github.com/aws/amazon-eks-pod-identity-webhook/blob/2fd4becd434f92edab01cecee30ea4b12af93ab7/pkg/handler/handler.go#L157-L177
https://github.com/kubernetes/kubernetes/blob/bad4d0ee963a71994636ebaaca52dab54820abe6/plugin/pkg/admission/serviceaccount/admission.go#L512-L555
Strange.

Reported to the amazon-eks-pod-identity-webhook repository.

Damn. But both code uses ServiceAccountToken. Maybe the code path is different?

No, this one is for projected service account tokens.

I was able to read a projected service account token with nobody by using securityContext.fsGroup:
      ...
      securityContext:
        fsGroup: 65534
      volumes:
      - name: token-vol
        projected:
          sources:
          - serviceAccountToken:
              path: token

$ whoami
nobody
$ ls -la /var/run/secrets/kubernetes.io/serviceaccount/..data/
-rw-r-----    1 root     nobody        1102 Sep 11 15:33 token

Any chances to get a timeline when this is going to be released?

I'd defer to @linki , but I think that if a change of configuration will allow to do that, I'd rather change the docs to mention this than change the dockerfile.

65534

https://stackoverflow.com/questions/34831861/can-i-assume-that-nobody-is-65534

You can't. nobody has had at least a few different IDs across distros and time:
Historically, the user “nobody” was assigned UID -2 by several operating systems, although other values such as 2^(15)−1 = 32,767 are also in use, such as by OpenBSD. For compatibility between 16-bit and 32-bit UIDs, many Linux distributions now set it to be 2^(16)−2 = 65,534; the Linux kernel defaults to returning this value when a 32-bit UID does not fit into the return value of the 16-bit system calls. An alternative convention assigns the last UID of the range statically allocated for system use (0-99) to nobody: 99.

Yeah, but the docker file already specifies 65534, so it doesn't really matter does it?
https://github.com/kubernetes-incubator/external-dns/blob/master/Dockerfile#L36

Can confirm workaround by using securityContext. I've changed the PR to update AWS tutorial instead of changing the Dockerfile. Should work fine with future k8s updates too.

/lgtm
/approve


Gradle java streams

Update gradle dependencies to match versions in the maven dependencies,
Add ./gradlew clean install to the travis build to ensure dependencies work on both build systems,
Use the stream made as a for each instead of collecting the results to loop through.

Failed maven build seems to be present in master, won't attempt to fix.


update readme to document passing a custom normalization function

As requested in #2

Thanks a lot! Will cut a new release around tomorrow.


macbook15-spi-driver: init at 0.1

Motivation for this change
This kernel-module is part of macbook pro 15+ hardware support NixOS/nixos-hardware#231
Things done
This module is fork of a fork https://github.com/roadrunner2/macbook12-spi-driver which includes a branch "mbp15" which as far as I know is the only way to get the touchbar working on macbooks 2018 and later (without which there aren't any F-keys available). The reason I forked it, is because I failed to be able to get the ambient light sensor nor keyboard backlight working, without using code from the contents from the "touchbar" branch (the main branch). So I merged together the changes on both branches to get all working. I'll make sure to maintain this module as changes come upstream.

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

[x] 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.

This has now a merge conflict.

Are you still working on this?

This has left my radar for now. Sadly linux isn't allowed where I'm working now. This kernel module was as far as I remember crucial to get things to work at the time I tested it. Feel free to take this PR over the finishing line, if I know myself, then I'll not be using this computer for another 3 months.

I cannot really test this. Kernel driver require regular maintenance as kernel upgrades will break them. Let's close this until we have a real user/maintainer.


Center on meta Nodes

When accessing the NodePropertyEditor:
If a node has children, then double click expands, but does not set/center on active node.

Partially addressed in https://github.com/scenerygraphics/sciview/pull/207

We need to verify this again. It might have been resolved now.


error in data configuration name creation

This seems to be happening even though the library should take care of this

https://community.sw.siemens.com/s/question/0D54O00006eK7pKSAS/error-while-configuring-agent-using-nodered


Add PR stats to open/closed pull request comment

Created new function to extract stats from pr.
Enhanced open and close pr comments with those stats.

Fixes #27

Ensure this projects runs was executed successfully, but the check seems that doesn't picked up the response.

Finally was able to run the test after upgrading my docker for mac:
act pull_request -e tests/events/pull_request_opened.json
[teamwork/Ensure this project runs] 🚀  Start image=node:12.6-buster-slim
[teamwork/Ensure this project runs]   🐳  docker run image=node:12.6-buster-slim entrypoint=["/usr/bin/tail" "-f" "/dev/null"] cmd=[]
[teamwork/Ensure this project runs]   🐳  docker cp src=/Users/marcnavarro/teamwork/github-sync/. dst=/github/workspace
[teamwork/Ensure this project runs] ⭐  Run actions/checkout@v1
[teamwork/Ensure this project runs]   ✅  Success - actions/checkout@v1
[teamwork/Ensure this project runs] ⭐  Run ./
[teamwork/Ensure this project runs]   🐳  docker build -t act-github-sync:latest /Users/marcnavarro/teamwork/github-sync
[teamwork/Ensure this project runs]   🐳  docker run image=act-github-sync:latest entrypoint=[] cmd=["" "localhost" "test_api_token"]
| --------------
| Running the process...
| --------------
| Event: pull_request - Action: opened
| --------------
| Task found with the id: 123
| --------------
| Test - Simulate request. Task ID: 123 - Comment:
|   **username** opened a PR: **This is an example of a title for the PR.**
|   [https://github.com/teamwork/github-sync/pull/1](https://github.com/teamwork/github-sync/pull/1)
|   ---
|   Stats: 1 commits, 4 files changed, +2, -3
|
| --------------
| Task found with the id: 456
| --------------
| Test - Simulate request. Task ID: 456 - Comment:
|   **username** opened a PR: **This is an example of a title for the PR.**
|   [https://github.com/teamwork/github-sync/pull/1](https://github.com/teamwork/github-sync/pull/1)
|   ---
|   Stats: 1 commits, 4 files changed, +2, -3
|
[teamwork/Ensure this project runs]   ✅  Success - ./

@toffentoffen updated some minor style for the comments and it is ready to be merged.
Thanks for the effort working on this one :)


Error searching for keys in the right range.

Gentlemen, I found something that I'm confused about.
When looking for challenge 10, it is in the 200:3ff range, but when using the command:
./keyhunt -m address -f tests/10.txt -b 10 -l compress -R -q -s 10 -t 11
the same is not found.

Now if I change to 9 bit. The range is wrong and you can find it.

How did you find an out of reach key? And why is it giving an error in the right lane?
Thanks.

Gentlemen, I found something that I'm confused about.
When looking for challenge 10, it is in the 200:3ff range, but when using the command: ./keyhunt -m address -f tests/10.txt -b 10 -l compress -R -q -s 10 -t 11
the same is not found.

Now if I change to 9 bit. The range is wrong and you can find it.

How did you find an out of reach key? And why is it giving an error in the right lane?
Thanks.

Well, even one processor thread captures a larger range than is specified for search! Would you also conduct experiments in the 5-bit range with a 96-core processor))

I believe I was confused. The number of bits would not be the challenge number, but rather how many bits are left to find? Example, in challenge 66 I would put how many bits? And how would you know the number of bits of the next challenges?

Default subrange thread is 0x100000000 so every thread start from your initial range to that value plus 32 bits.
Let's to said 0x100 to 0x100000100 -1 First thread
Second thread is from 0x100000100 to 0x200000100 - 1
Etc.....
Minimum sub range value is 0x400
This is -n 0x400 or -n 1024
Any value lower than it it's inefficient.
So in your case you should chose values larger than 32 bits or set your -n value to 0x400 and you minimum range from 0x100 to 0x500 and number of threads to 1
-t 1 or not -t at all defual thread number is 1.
About the -b 9 or -b 10  you should tell us what address you targeted to check if the range is 9 or 10 bits

Thank you my friend. Now I understand.
Congratulations on the project.


Sensor Naming Convention

It would be convenient for setting up cards and for a 'maybe' better searching experience.
Having generic names for Humidity, Temperature, etc makes it difficult (sometimes) to find a sensor from this integration.
I realize that this would require fixing all instances in ones HA to the corrected sensor name.
That said, I think a prefix for the sensor names such as "wf" would be helpful.  For example sensor.humidity would now be sensor.wf_humidity

Agree. I think the user base is still so small that it will not be a major issue. It will be a BREAKING CHANGE though

I have now released V2.0, where this is included. See the CHANGELOG.md for more info.


[Feat?]: add 'enter' keypress to Switch component

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Summary 💡
Current Checkbox is supporting using "enter" key but Switch component does not. In order to be consistent, we need to update Switch to use the same keypress functionality:
Checkbox code:
https://github.com/pluralsight/design-system/blob/master/packages/checkbox/src/react/index.tsx#L86
Examples 🌈
No response
Motivation 🔦
Improve a11y functionality and consistency.

In native elements, only space toggles a checkbox.  This is because when a form element has focus and enter is pressed, the form is submitted.
I think we should re-evaluate this approach, as well as our current checkbox in favor of removing toggle on enter functionality, knowing that there is a potentially negative impact to this.  Or perhaps controlling this behavior with a flag that defaults to true to preserve existing functionality?

No longer adding features to this project. Closing.


storedKeyIdentifiers() from crypto plugin is never called

Maybe part of the API refactoring, but it seems to me that storedKeyIdentifiers() plugin API is never called. Indeedm there is a storedKeyIdentifiersRequest object, but it is working on secret, listing the key already known in the database to secret.
Or did I miss something?

Not the case anymore after #47.


Create the tmp directory if it does not exist.

On a fresh git checkout the 'tmp' directory used for storing test output
images does not exist. This adds a line to the test_helper to create the
directory if necessary.

Thank you :)


multiple sheet in CSV using  angular for json

i need to create multiple dynamic sheets and data is in the JSON format and does anybody have idea how to achieve it.

actually  in CSV format we cant have multiple sheets so closing the issue


Create Documentation and Flow Diagrams

For overall and component pieces of the system.

In Progress

Need to create human_play.py flow diagram


Use art from @react-native-community/art instead of react native

React Native removed ART from the React Native project itself and now maintains it separately in a community library.
https://github.com/react-native-community/art

@tyler-whitman thank you!
I just also update the demo and some reps: https://github.com/rosskhanas/react-qr-code/commit/3bd08070ead3a0db31dcaec88810e8e20493f6eb


Implement TypedArray

Implement https://tc39.github.io/ecma262/#sec-typedarray-objects
test with node test/test262.mjs "built-ins/{TypedArray,TypedArrayConstructors}/**/*.js"

Everything is now all implemented :)


'Edit this page' link is broken in the init template

Have you read the Contributing Guidelines on issues?

[X] I have read the Contributing Guidelines on issues.

Prerequisites

[X] I'm using the latest version of Docusaurus.
[X] I have tried the npm run clear or yarn clear command.
[X] I have tried rm -rf node_modules yarn.lock package-lock.json and re-installing packages.
[X] I have tried creating a repro with https://new.docusaurus.io.
[ ] I have read the console error message carefully (if applicable).

Description
In https://tutorial.docusaurus.io/docs/intro  'Edit this page'  link is not redirecting to the GitHub repo.
In all the pages of docusaurus --> tutorial , the same issue exists.
Steps to reproduce
Step 1: GO to https://tutorial.docusaurus.io/docs/intro
Step 2: Click 'Edit this page'
Expected behavior
Should open the github repo for that page.
Actual behavior
404 Page not found error.
Your environment

Public source code:
Public site URL:
Docusaurus version used:
Environment name and version (e.g. Chrome 89, Node.js 16.4):
Operating system and version (e.g. Ubuntu 20.04.2 LTS):

Reproducible demo
No response
Self-service

[ ] I'd be willing to fix this bug myself.

Please don't assume that the init template is functional in any way. It's only meant for a demo and we have explicitly stated that // please change it to your own demo in the config file.
Could I know where you were pointed to this domain? AFAIK it's not advertised much and we mostly use this template for interactive playgrounds and create-docusaurus

The tutorial is browsable online.
It's based on examples/classic deployed to Netlify
Not sure what's the best:

find a way to use the create-docusaurus edit URLs?
find a way to disable this

Can be a post-step in the generate example script?

What about pointing to the create-docusaurus folder? This has the additional benefit that if the user sees anything she would like to update in the init template she can easily do so.

Yes, that makes sense to me, we could always link to create-docusaurus (online tutorial, init, codesandbox...) so that people would be less confused and be able to edit the tutorial in case of any problem/suggestion


Using browser back/foward navigation causes json strings to be displayed instead of documents.

Description
I've performed the following actions in the current online demo.

Open folder "My documents", double click.
Open the document in that folder, double click.
Use the browser back navigation.
User the browser forward navigation.

Expected

The document gets shown again.

Actual

Some json string is shown verbatim, instead of the page.

{"document": {"id": 4, "title": "brother_003961.pdf", "notes": "None", "created_at": "30.11.2020 17:49:30", "timestamp":<PHONE_NUMBER>.694929, "parent_id": 3, "ctype": "document", "pages": [{"id": 1, "number": 1, "kvstore": []}], "tags": [], "user_perms": {"read": true, "write": true, "delete": true, "change_perm": true, "take_ownership": true}}}

Info:

OS: Archlinux
Browser chromium
Papermerge Version 1.5.2

@jonaswinkler, thank you for opening this bug.
It is very interesting that it can be reproduced only on Chromium browser (I was unable to reproduce it on Firefox/Ubuntu).

Fix is now available in master and stable/1.5.x branches.


Merge pull request #1197 from microsoft/dev

5.9.0-preview1

Coverage increased (+0.04%) to 76.729% when pulling d92cc3d58d84f4bf6af22fe45de10170591e538b on master into 59791f89c557a868b280ba97a65375616c0152bc on dev.


[linux] Implement BLE discovery

Problem
Currently, BLE scanning and connection establishment code is missing on Linux. Consequently, implementation of the BleConnectionDelegate interface used by RendezvousSession is impossible.
Summary of Changes
Implement functions for BLE device discovery and filtering by CHIP UUID / discriminator
This is the first part needed for #2791. Connection establishment still needs to be implemented.

May i know how do you test this change?
Have you used btvirt for this testing?
connectedhomeip/third_party/bluez/repo$ sudo ./src/bluetoothd --experimental --debug
connectedhomeip/third_party/bluez/repo$ sudo ./emulator/btvirt -l2 -L
for virtual peripheral bringup
sudo ./out/debug/linux_x64_clang/tests/TestCHIPoBLEStackMgr 1
for virtual central
connectedhomeip$ sudo ./out/debug/linux_x64_clang/controller/python/chip-device-ctrl
Chip Device Controller Shell
chip-device-ctrl > ble-adapter-select 00:AA:01:01:00:24
chip-device-ctrl > ble-scan-connect -t 60 00:AA:01:00:00:23
2020-10-01 13:21:59,766 ChipBLEMgr   INFO     scanning started
2020-10-01 13:22:03,581 ChipBLEMgr   INFO     Name =    CHIP0001
2020-10-01 13:22:03,581 ChipBLEMgr   INFO     ID =      6280efe2-91c8-3242-9400-e025e0a27656
2020-10-01 13:22:03,581 ChipBLEMgr   INFO     RSSI =    127
2020-10-01 13:22:03,582 ChipBLEMgr   INFO     address = 00:AA:01:00:00:23
2020-10-01 13:22:03,583 ChipBLEMgr   INFO     ADV data: 0000feaf-0000-1000-8000-00805f9b34fb
2020-10-01 13:22:03,583 ChipBLEMgr   INFO
2020-10-01 13:22:03,586 ChipBLEMgr   INFO     scanning stopped
2020-10-01 13:22:03,587 ChipBLEMgr   INFO     trying to connect to 00:AA:01:00:00:23
2020-10-01 13:22:05,596 ChipBLEMgr   INFO     BLE connecting
2020-10-01 13:22:05,597 ChipBLEMgr   INFO     Discovering services
2020-10-01 13:22:05,706 ChipBLEMgr   INFO     Service discovering success
2020-10-01 13:22:05,719 ChipBLEMgr   INFO     connect success
chip-device-ctrl > btp-connect
CHIP:CTL: begin BTPConnect validation
CHIP:BLE: subscribe complete, ep = 0x7f42dca4cc58
CHIP:BLE: peripheral chose BTP version 3; central expected between 2 and 3
CHIP:BLE: using BTP fragment sizes rx 20 / tx 128.
CHIP:BLE: local and remote recv window size = 3
CHIP:CTL: ChipoBle con complete
BTP Connected
chip-device-ctrl > CHIP:BLE: Releasing end point's BLE connection back to application.

May i know how do you test this change?
Have you used btvirt for this testing?
connectedhomeip/third_party/bluez/repo$ sudo ./src/bluetoothd --experimental --debug
...
No I tested it on hardware:

I run the lock-app for nRF Connect running on nRF52 DK with default discriminator (3840)
I modified examples/chip-tool locally by adding "on-ble" and "off-ble" commands similar to "echo-ble" and made it wait for the connection (changes to be contributed soon).
I also set BLEManagerImpl::mIsCentral = true and rebuilt the chip-tool
I run ./chip-tool on-ble 3840 0123456 1
Then I verified in the logs that the lock is correctly recognized as CHIP device with discriminator 3840 and gets connected.

Could you let me know if what you're working on (controller/python) will share any code with Linux BLE layer of CHIP? We may synchronize so we don't interfere with each other :).

May i know how do you test this change?
Have you used btvirt for this testing?
connectedhomeip/third_party/bluez/repo$ sudo ./src/bluetoothd --experimental --debug
...
No I tested it on hardware:

I ran the lock-app for nRF Connect running on nRF52 DK with default discriminator (3840)
I modified examples/chip-tool locally by adding "on-ble" and "off-ble" commands similar to "echo-ble" and made it wait for the connection (changes to be contributed soon).
I also set BLEManagerImpl::mIsCentral = true and rebuilt the chip-tool
I run ./chip-tool on-ble 3840 0123456 1
Then I verified in the logs that the lock is correctly recognized as CHIP device with discriminator 3840 and gets connected.

Could you let me know how what you're working on (controller/python) will share code with Linux BLE layer of CHIP? We may synchronize so we don't interfere with each other :).

Bluez based DeviceController in controller/python would be compiled in Linux platform along with the code in src/platform/Linux/BLEManagerImpl , src/platform/Linux/BLEManagerImpl and Bluez based DeviceController would share src/ble, for example, in your refactor, BLE_CONNECTION_OBJECT has been broadly used as void *, in central Linux controller tool side, we use python bluez and
link it to Chip BTP, where BLE_CONNECTION_OBJECT cannot be chip::DeviceLayer::Internal::BluezConnection. I have slightly change it back in previous PR :)
The goal for python-based corebluetooth/bluez manager and device controller is to provide one general python chip device  manager tool(mobile/controller simulator) for regular dev use and automation framework integration, which would use same ChipDeviceController.cpp as JAVA or objectiveC mobile APP uses to interact with devices, then exercise device pairing(IP connection/BLE connection + thread/wifi provisioning + service provisioning + zcl cluster interactions). @erjiaqing would do further pairing example code integration on this next week #3010
I just complete python-based corebluetooth/bluez manager and device controller, and would do another component, and should not touch the bluez in the following weeks, and would be happy to synchronize with you.
Anyway, thanks for your effort on Bluez central integration in platform/linux, which would be helpful for thread over bluez central effort and linux ble testing.

These changes appear to break the build with #define CONFIG_NETWORK_LAYER_BLE 0.  Can there be an amendment that addresses this?

amendment

I don't think it's my changes that broke the build (according to build errors I see), but I can fix them easily. Could you file an issue for that?

Yes, of course.

FYI, issue filed here: https://github.com/project-chip/connectedhomeip/issues/3179


jsp page invalid in index.jsp

https://github.com/YUbuntu0109/SSM-SMS/blob/ce9a28398798ddbb34b09c1b1a3258c0801e5fde/sms/src/main/webapp/index.jsp#L9

it is my mistake

:heart: index.jsp is an important file to enter the controller !

you are right, just i didn't see the path in the controller.


On all pages, the header moves when scrolling

Code of Conduct

[x] I have read and agree to the GitHub Docs project's Code of Conduct

What article on docs.github.com is affected?
https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-profile/managing-contribution-graphs-on-your-profile/why-are-my-contributions-not-showing-up-on-my-profile
https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-email-preferences/adding-an-email-address-to-your-github-account

What changes are you suggesting?
Headers should be positioned at the top of the page
Additional information
No response

https://user-images.githubusercontent.com/82635946/164393469-c40e2d9b-c38d-448f-bc41-d66e0ad8f8ab.mp4

@jaypavasiya
Thanks so much for opening an issue! I'll triage this for the team to review :eyes:

Thanks for the report!  I'm unable to reproduce on the latest release Firefox and Chrome on macOS 11.6.5 -- can you share what browser and OS you're using?

Thanks for the report! I'm unable to reproduce on the latest release Firefox and Chrome on macOS 11.6.5 -- can you share what browser and OS you're using?

I'm using Version 102.0.4997.0 in Chrome Dev.

Thanks for the report! I'm unable to reproduce on the latest release Firefox and Chrome on macOS 11.6.5 -- can you share what browser and OS you're using?

closing this issue - The issue seems to be with Chrome's beta version; I switched to Chrome production's latest version, and now it works fine


Introduce data-flow analysis

Currently, the type inference mechanism is very simple in that in infers types for a variable based only on the last seen assignment to the variable. This has shortcomings for scenarios like the following, where the type may differ based on the branch taken.
x = ""

if y == 0:
    x = True

x # inferred as `Literal[True]`, should be `Literal[""] | True`

To make the type checker more accurate in these situations, this PR introduces a primitive form of data-flow analysis heavily based on Pyright and, by extension, the TypeScript compiler. This includes constructing a code-flow graph as an additional lowering step and using it to determine types as part of the type checker. While under active development, this functionality will be gated behind the --experimental_use_code_flow_analysis flag.
Tasks:

[ ] Support constructing a code-flow graph from the current HIR

[x] if statements
[ ] for loops
[x] List/dict comprehensions
[ ] Assignments for params

[ ] Use code-flow graph as part of type inference

[x] if statements
[ ] for loops

[ ] Caching mechanism data-flow analysis results

[ ] Effective type results
[x] Type of reference at specific flow nodes

[ ] Add --experimental_use_code_flow_analysis flag

ha


[Savage Worlds - Tabbed] Fighting starts as trained skill

By default characters in Savage Worlds (Adventure Edition) should be untrained in fighting so their default fighting stat should be 1d4 - 2. Not a flat 1d4.
I get that we can't eliminate the field by default because it's used to calculate Parry, but hopefully it shouldn't be too hard to default the field to have the minus 2.

Not difficult, but since it's a rare instance that a character doesn't take at least a d4 in Fighting this was done to save the majority of people the hassle of having to delete a -2 while putting that burden on the few characters that don't take any Fighting at all.
Hope that makes sense.

Yeah it makes sense and I see how it could save hassle, but I'd like to offer some pushback, if that's okay. When I'm GM'ing with new players I find it really nice to point them to your character sheet as a structured way to build their characters. The past game I hosted I had one player point this out to me and the other 2 players assumed they had just missed something in the rules and that they should start with Fighting 1d4. This is doubly confusing now that in Adventure Edition some skills really do start with 1d4.
Anyway, your call, just sharing what caused me to open the issue. Thanks for your awesome work on this! 😄

With the Official Savage Worlds character sheet, this is now an option. In Sheet settings you set it so Fighting starts a unskilled with the -2. You can also set that on each sheet individually, if you don't set it as a sheet setting when creating/modifying your game.


matchaddpos() show unwanted content in empty area

reproduce step
minivimrc
set nocompatible
set conceallevel=2
syntax on

`vim -u minivimrc minivimrc
:normal! gg
call matchaddpos('Conceal', [[2, 19,1]], 10, -1, {'conceal': 'f'})

you will see:

I can not understand why the content of first line will be shown after conceal cchar?

Hm, please check this patch:
diff --git a/src/screen.c b/src/screen.c
index 05853d442..ff568bccd 100644
--- a/src/screen.c
+++ b/src/screen.c
@@ -3007,6 +3007,7 @@ win_line(
     int                col = 0;                /* visual column on screen */
     unsigned   off;                    /* offset in ScreenLines/ScreenAttrs */
     int                c = 0;                  /* init for GCC */
+    int         at_eol = FALSE;         /* remember end of line */
     long       vcol = 0;               /* virtual column (for tabs) */
 #ifdef FEAT_LINEBREAK
     long       vcol_sbr = -1;          /* virtual column after showbreak */
@@ -4530,7 +4531,8 @@ win_line(

            }
 #endif
-           ++ptr;
+           if (*ptr != NUL)
+               ++ptr;

            if (extra_check)
            {
@@ -5118,6 +5120,8 @@ win_line(
                {
                    /* First time at this concealed item: display one
                     * character. */
+                   if (c == NUL)
+                       at_eol = TRUE;
                    if (match_conc)
                        c = match_conc;
                    else if (syn_get_sub_char() != NUL)
@@ -5285,7 +5289,7 @@ win_line(
        /*
         * At end of the text line or just after the last character.
         */
-       if (c == NUL
+       if (c == NUL || at_eol
 #if defined(LINE_ATTR)
                || did_line_attr == 1
 #endif
@@ -5425,7 +5429,7 @@ win_line(
        /*
         * At end of the text line.
         */
-       if (c == NUL)
+       if (c == NUL || at_eol)
        {
 #ifdef FEAT_SYN_HL
            if (eol_hl_off > 0 && vcol - eol_hl_off == (long)wp->w_virtcol

btw: you probably have a off by one error and you actually want
call matchaddpos('Conceal', [[2, 18,1]], 10, -1, {'conceal': 'f'}) (19 is beyond end of line, col starts with 1)
BTW: interesting observation:
call matchaddpos('Conceal', [[2, 0,1]], 10, -1, {'conceal': 'f'})
(conceals first character and hides the complete line. I think this is also a bug).

@chrisbra I will test this patch;
what I want  is to use conceal char to shou some info in the screen without replace the line, for example, shou error of point below current line:

@chrisbra with this patch, we can not set conceal after end of line.

with this patch, we can not set conceal after end of line.

Not sure this was ever supposed to be allowed. You can only conceal what is on the line not beyond it.

@chirsbra It was probably not intentional but why not keep it if it works? virtualedit is already a thing. The at_eol check could be done next time a non-concealed char should be shown, to avoid the invalid continuation.

@chrisbra I think we should be able add Conceal char after end of line, in current version of vim, we can do that, and the only issue is there are extra characters are show, and as I can see, the extra characters is come from line above that line.

@wsdjeg I'm working on a "safe" API for this feature here: https://github.com/neovim/neovim/pull/8180

wow，Thanks

@bfredl I found I can use vim script to avoid this issue, please see: these two pictures. just add an empty string before the string which need to be signatured. and the pr is
https://github.com/SpaceVim/SpaceVim/pull/1565

@wsdjeg Basic support is now available on neovim master (though you cannot "replace" a line, only append after EOL initially), see neovim/neovim#8180

@bfredl Thanks, I will update neovim, and have a try.


Feature: generate random time series

Hi @dorisyycai, your function has a larger dependence on my function's output, so I add you to be my reviewer.
let me know if you have any questions, thanks :)

Also, I misunderstood the parameter length as the length of the time range initially as discussed. May be considering to rename it to something else to avoid confusion (i.e. n_rows).

good catches @dorisyycai, appreciated
I've just made some suggested changes, could you please review whether they're okay?


Change the default generator output directory

Let's use the /client directory for client files rather than app/javascript

Change the default webpacker.yml file:
   source_path: app/javascript	   source_path: client/app
Put the sample files in client/app

Chose to stay with the rails/webpacker convention of app/javascript.


Using scripts to launch a background service renders blank error logs

Issue: The log files in /userdata/system/logs are empty when using ES scripts to run a background service.
Expected behaviour: For the logs to still function when using custom scripts.
Logs: Self-explanatory why they are not present here.
Additional info: One example is if you were to download and run the Pixelcade software: https://pixelcade.org/batocera/ but I'm also sure this would be applying to any scripts that launch a background service to be run continually.

Absolutely not related to ES in ny way.
No logs in /userdata/system/logs is related to EmulationStation.
These are batocera & configgen logs.

This is related to ES. It only occurs when using custom ES scripts, not when using Batocera custom scripts. Please try the reproduction method and you will see.
Sorry for not specifying that from the start.

What do you scripts do ?

Launches a curl request to a Java webservice.
I've found that if the curl command is replaced with one with the verbose tag, then the curl output becomes visible in the logs. So it seems like ES is using the output of its custom scripts as the last thing to be written to stderr and stdout.

mmm you're right, on linux the following code is used : https://github.com/batocera-linux/batocera-emulationstation/blob/master/es-core/src/platform.cpp#L129 ( I didn't remember that, this code was probably written before by someone else before )
As the scripts output are redirected to the log files (  "2>[..]" ), you can't redirect youself. I suppose you do that ( but I didn't see any script code... ).
Instead you have to output what you do to the console.
So in your scripts, you have to verbose your output instead of redirecting them.

That's what I said I did, not sure what difference that would make.
Incidentally I did try redirecting the script's output to a different tty, but that just resulted in the logs becoming blank again. The issue fundamentally seems to be with the way that the order of the output of the user's custom scripts are recorded.
If we could find the piece of code responsible, I imagine it would be as simple as changing ">" to ">>" or something similar.


TypeError: Class constructor BaseModel cannot be invoked without 'new'

Steps to reproduce
Using v2.0.0-pre.62 (for real this time 😎). I'm getting the error TypeError: Class constructor BaseModel cannot be invoked without 'new'. The error is being thrown at service-module.actions.ts#L277.
I put a break in at that line in the code and found that the fetch operation is successful. An array of objects has been returned by the API and the error happens when trying to convert them into model instances. This Stack Overflow post suggests that the issue may be caused by the Babel target preset. It indicates that this preset should be changed from es2015 to node, but TBH, I am not comfortable or familiar enough with how Babel works to know if this is really the issue.
Here are the snippets of my current setup. The full repo is available here.
My Feathers client setup:
// src/services/api.js
import feathers from '@feathersjs/feathers'
import auth from '@feathersjs/authentication-client'
import feathersVuex from 'feathers-vuex'
import socketio from '@feathersjs/socketio-client'
import io from 'socket.io-client'

const app = feathers()
const socket = io(process.env.VUE_APP_API_URL)
app.configure(socketio(socket))

const api = app

const {
  makeServicePlugin,
  BaseModel,
  models,
  clients,
  FeathersVuex
} = feathersVuex(app, { serverAlias: 'api' })

export {
  api,
  FeathersVuex,
  BaseModel,
  clients,
  makeServicePlugin,
  models
}

My model class setup:
// src/store/services/artifacts.js
import { api, makeServicePlugin, BaseModel } from '@/services/api'

class Artifact extends BaseModel {
  static modelName = 'Artifact'
  // eslint-disable-next-line
  constructor (data, options) {
    super(data, options)
  }
  static instanceDefaults = () => ({
    createdAt: null,
    name: null,
    narrative: null,
    notes: [],
    status: 'draft',
    tags: [],
    updatedAt: null,
    uri: null,
    userId: null
  })
}

const servicePath = 'artifacts'
const servicePlugin = makeServicePlugin({
  Model: Artifact,
  service: api.service(servicePath),
  servicePath
})

export default servicePlugin

Store setup:
import Vue from 'vue'
import Vuex from 'vuex'
import { FeathersVuex } from 'feathers-vuex'
import { api as appAPI } from '@/services/api'
import auth from '@/store/modules/auth'
import common from '@/store/modules/common'
import user from '@/store/modules/user'

// register Vue plugins
Vue.use(Vuex)
Vue.use(FeathersVuex)

// passthrough export of key objects
export const api = appAPI

// get the API service plugins
const requireModule = require.context('@/store/services', false, /.js$/)
const apiPlugins = requireModule.keys().map(path => requireModule(path).default)

export const store = new Vuex.Store({
  strict: process.env.NODE_ENV !== 'production',
  modules: {
    // artifacts,
    auth,
    common,
    user
  },
  plugins: [
    ...apiPlugins
  ]
})

Finally, some snippets from the component that's causing the error to be thrown (using <feathers-vuex-find>):
// src/components/pages/artifacts/TheArtifactsPage.vue
<template>
  ...
    <feathers-vuex-find
      :fetch-query="{ userId: $store.state.auth.apiId, $limit: -1 }"
      :query="query"
      service="artifacts"
    >
      <v-data-table
        slot-scope="{ items: artifacts }"
        :items="artifacts"
        item-key="_id"
      >
        ...
      </v-data-table>
    </feathers-vuex-find>
  ...
</template>

I'm hoping that I just have a configuration error somewhere. Changing the Babel config seems like it could have serious ripple effects.

[x] Tell us what broke. The more detailed the better.
[ ] If you can, please create a simple example that reproduces the issue and link to a gist, jsbin, repo, etc.

Expected behavior
The retrieved artifacts should be displayed
Actual behavior
TypeError: Class constructor BaseModel cannot be invoked without 'new'
System configuration
Tell us about the applicable parts of your setup.
Module versions (especially the part that's not working): v2.0.0-pre.62
NodeJS version: v10.15.3
Operating System: OSX 10.13.6 (High Sierra)
Browser Version: Chrome (mac) 75.0.3770.100
Module Loader: Vue v2.6.10, Vuex v3.1.1

Please look at the solutions that are discussed in the PR: https://github.com/feathers-plus/feathers-vuex/pull/216
I recommend looking at the comment by @t2t2, first.

Basically, you need to add feathers-vuex to the transpileDependencies key in the vue.config.js file.

This works! I tried adding just feathers-vuex but ended up having to add all 3 of the ones @t2t2 specified. I also added the sourceType: 'unambiguous' key to the babel config as well. I'm always amazed at how many things about the Vue ecosystem I still have to learn.
Thanks, as always, for the lightning fast response.

@marshallswain @morphatic
When I do this using NuxtJS and the latest version I get these warnings:
 WARN  in ./node_modules/feathers-vuex/dist/service-module/service-module.mutations.js

"export 'default' (imported as '_isObject') was not found in 'lodash/isObject'

 WARN  in ./node_modules/feathers-vuex/dist/utils.js

"export 'default' (imported as '_trim') was not found in 'lodash/trim'

Hmm =/

Can you confirm the exact version number of the feathers-vuex package you have installed?

Yes it is v2.0.0-pre.77

@marshallswain I solved it copying feathers-vuex in my libs folder and directly import it from there :)

For Quasar app transpileDependencies can be updated in quasar.conf.js under build as
transpileDependencies: ['feathers-vuex'],

Getting the below error on on adding transpileDependencies, while upgrade to 2.0.1
quasar dev

 Dev mode.......... spa
 Pkg quasar........ v1.2.4
 Pkg @quasar/app... v1.2.2
 Debugging......... enabled

 app:quasar-conf Reading quasar.conf.js +0ms
 app:dev Checking listening address availability (<IP_ADDRESS>:8001)... +6ms
 app:webpack Extending SPA Webpack config +420ms
 app:generator Generating Webpack entry point +5ms
 app:dev-server Booting up... +4ms

 SPA █████████████████████████ [100%] in ~18s

 WARNING  Compiled with 6 warnings                                                                   7:11:29 AM

 warning  in ./node_modules/feathers-vuex/dist/utils.js

"export 'default' (imported as '_isObject') was not found in 'lodash/isObject'

 warning  in ./node_modules/feathers-vuex/dist/utils.js

"export 'default' (imported as '_isObject') was not found in 'lodash/isObject'

 warning  in ./node_modules/feathers-vuex/dist/utils.js

"export 'default' (imported as '_isObject') was not found in 'lodash/isObject'

 warning  in ./node_modules/feathers-vuex/dist/service-module/service-module.mutations.js

"export 'default' (imported as '_isObject') was not found in 'lodash/isObject'

 warning  in ./node_modules/feathers-vuex/dist/service-module/service-module.mutations.js

"export 'default' (imported as '_isObject') was not found in 'lodash/isObject'

 warning  in ./node_modules/feathers-vuex/dist/utils.js

"export 'default' (imported as '_trim') was not found in 'lodash/trim'

Seems feathers-vuex was not installed properly or latest version. Removed it from package.json and did npm install --save and error went away.


Flushing Requests

How does the module handle or support the need to spontaneously send the batch?
For example, on unload we would like to send the most recent batch regardless of quota or time being hit.

Hi,
Currently, there is no way to achieve this however I think it is a good idea so I will add a flush method on the batcher that will flush all pending batches, I think as well if you pass an endpoint url into this function it will just flush that batch. I'll try and do it tonight and let you know.
Jon

Hi,
I've added the flush method as described - there is a little bit of documentation in the Readme.md file.
Let me know if this is what you wanted and if it works in a prod system.  I've added some unit tests and works locally.
Immediately flushing all pending requests
In some instances you might want to immediately send all pending request regardless of if the request quota or timeout limit has been reached.  To do this you can simply call the flush method on the httpBatchConfigProvider service and optionally pass in the url of the batch endpoint you want to flush (if no parameter is passed in all pending requests to all endpoints are flushed).
angular.module('myApp', ['jcs.angular-http-batch']);
   .run([
      'httpBatchConfigProvider',
          function (httpBatchConfigProvider) {
             httpBatchConfigProvider.flush();
         }
]);

Awesome!  Thank you!


WIP: Refactor common default based on ansible_os_family dict.

Intention behind this refactoring of common role defaults was to reduce input needed for Centos/RHOSP in all.yml

retest

retest

@zfeldstein can u please review as well.

retest


Race condition when initializing external clients using bootstrap

PR Checklist
Please check if your PR fulfills the following requirements:

[X] The commit message follows our guidelines: https://wiki.edgexfoundry.org/display/FA/Contributor's+Guide
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[X] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?
A race occurs during bootstrap external client initialization between the bootstrap handler and the bootstrap registry component. If the external client is initialized JIT, the registry variable will no longer contain valid data. On subsequent calls, the registry variable is updated and execution proceeds as normal.
Issue Number: Fixes #2421
What is the new behavior?
The external client is initialized before the bootstrap update code and the race does not occur.
Does this PR introduce a breaking change?

[ ] Yes
[X] No

Are there any specific instructions or things that should be known prior to reviewing?
To verify:
Repro the bug on master:
Run (in order) consul, redis, config-seed, core-data, core-metadata, core-command. Ensure the core services are configured for consul usage and not local configuration. Make the following curl command: curl http://localhost:48082/api/v1/device .
Checkout this PR code, follow the steps above, and ensure that device data is returned.
Other information
The system management agent contains code that is very similar to the problematic code identified in this PR in command and metadata. I do not have the familiarity with the SMA to say if it is going to be an issue there.

@michaelestrin We absolutely have, and it's a fair point, but then should we change core-data (which is set up like this already) to do JIT right now? I believe we should harmonize all the services to do JIT, but I think committing code that we know will fail black-box tests is irresponsible. To that end, I think the best course of action here is to merge this PR, acknowledge there is a race (but one we will always win) and work on rebuilding the registry client to work the same way the URL client does to address the underlying race. I do not think that leaving black box tests broken for any period of time (like we did for the URL client) should be the course of action here. I think the master branch should always be passing blackbox tests, even if it requires a bandaid that we need to replace with something permanent.

You're pushing code around and don't understand (or can't adequately describe) the root cause.  If you don't understand the root cause, you can't be sure you'll always win the race.
This appears to be a result of a shortcoming with recent registry client changes.  Maybe find the root cause and fix it?
I stand by my prior statement.

FWIW, I'm not attacking you @brandonforster nor am I advocating for irresponsibility and broken black box tests.  I'm not saying you caused the problem or are somehow responsible for the current state of the code.  I'm simply saying the underlying root cause should be identified and addressed to prevent future similar issues from cropping up.  There are places in the code -- specifically in the agent -- where JIT can't be avoided.

@michaelestrin I know you're not making a personal attack on me and I know you're not attacking my credentials or anything like that. You were correct about the best way to attack this problem from a root cause perspective on the URL client, and the code is now much better for it. All those points you made for the URL client apply 1:1 here and I have no doubt that undertaking that work you are pushing for would have the same dramatic improvement.
However, that work takes time I am just very concerned that we have not been passing black box tests on master since the bug that started the URL client work. After we added the URL client, there was a bug in the URL client code, and now there is this bug in registry that looks like a root cause solution could potentially be just as time consuming. I am not advocating for not doing the root cause work, au contraire, I would love to spearhead it. I just want the system to pass tests and not have these weird hiccups, and I don't think a //TODO redo this in service of passing our API tests is a bad thing.

I briefly looked into this and I think we should focus our efforts on finding the root cause and fixing it. To address @brandonforster concern regarding the time it would take to implement a long term fix, how about we start looking into correcting the issue in this PR and add new commits which address the long term issue. That way if we get to a point and we want the quick fix we can simply just take the original commit(s), and if we can come up with a long term fix within a reasonable time frame we can squash all the commits. This would require some additional organization on your part as the author.  Then for the following commits you can add to that and we can work from there once we need to make a decision as what to do. I think we can get this done within a reasonable time frame. Race conditions and concurrency problems are horrible to find and fix, if we have a handle on it now it would be nice to remove one more complex issue from the system. I hope that all makes sense.

Also, if you need any assistance with tracking down the issue and/or coming up with a solution please feel free to reach out. I am confident we can get this worked out.

@AnthonyMBonafide Sounds like a good approach. If the scope starts to look like the URL client refactor, we can reassess, but you're right to not worry about complexity we don't necessarily need yet.

Codecov Report

Merging #2450 into master will decrease coverage by 0.41%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master    #2450      +/-   ##
==========================================
- Coverage   38.14%   37.73%   -0.42%
==========================================
  Files         157      157
  Lines       12967    12851     -116
==========================================
- Hits         4946     4849      -97
+ Misses       7754     7740      -14
+ Partials      267      262       -5

Impacted Files
Coverage Δ

internal/core/command/init.go
0.00% <0.00%> (ø)

internal/core/metadata/init.go
0.00% <0.00%> (ø)

internal/security/proxy/service.go
73.31% <0.00%> (-7.21%)
:arrow_down:

internal/security/proxy/init.go
0.00% <0.00%> (ø)

internal/security/proxy/main.go
0.00% <0.00%> (ø)

Continue to review full report at Codecov.

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

 The registry client has to be initialized, the URL client has to be initialized, we have to wait for the first URL poll, and we have to fetch that URL update on a successful poll and report it back down, all while the request is still in flight.
I've found that the underlying problem here isn't with the registry client, the bootstrap, the URL client or any of our code, it's that all that code and work that has to be done takes too long to accomplish while the request is in flight, and the HTTPResponseWriter times out while it's waiting for it to finish. Observing the current function in the debugger, everything returns successfully and with valid device data, but the endpoint function falls over on the call to json.NewEncoder(w).Encode(devices) and returns the following error on my machine:
write tcp <IP_ADDRESS>:48082-><IP_ADDRESS>:52314: i/o timeout
This causes the empty response from server, which goes away after the first call because all the clients have already been initialized.
I believe that the best course of action is to remove lazy initialization of all clients, and take the time hit when it's least noticeable, during startup. This way, when a REST call is actually made, the HTTP stack is going to be the limiting factor in timing and not any of our business code, as it is today.
@michaelestrin, I'd really like your thoughts here since I know we were both pushing for lazy initialization.

Note that as part of the current changeset, I have renamed restDevice.go to rest_device.go to bring it in line with the other core service's naming of similar files.

I believe that the best course of action is to remove lazy initialization of all clients, and take the time hit when it's least noticeable, during startup.

As I said before, this may work with core and support services but will not work with the agent.  It's also limiting in that it prevents dynamic service discovery which will be a future issue when high-availability support is implemented (which seems to be gathering some steam).
@akramtexas ran into a similar issue recently with a new blackbox test he wrote taking longer than the socket timeout.  This was ultimately solved by a default configuration change to lengthen the timeout.  You might look into that as the long-term solution.  Not sure that a 5 second timeout lengthened to 6..9 seconds would be a big deal.
I also wonder if this is a universal problem or is being contributed to by the work being done by the use case you're invoking that invokes a client call.
Anyway, that's my 2 cents @brandonforster.

@michaelestrin, I think I may be missing some important piece here. With @brandonforster proposed solution, I am not seeing how this is will cause and issue for dynamic service discovery. As I see it he is suggesting that we still use the dependency injection container to pass around the pointer to the underlying client, which can still be updated in the background when a URL update happens within Consul. However, we would kickoff the lookup for the URL during startup of the application so we are not doing it at the last possible moment, which is responding to the first request which indirectly needs the client. To me that seems like something we would want to do anyway since getting the client(s) ready for use is something that should be taken care of before the service has started. I hope my understanding is correct.
As for system management agent, is there a reason we are not using the same initialization and update strategy as the other core-services?

Updated with changes @michaelestrin and @AnthonyMBonafide discussed on a call.

Sorry about all the pushes. I updated the timeout value to 45,000 ms, because I realized that the URLClient polling interval is currently defined as 15,000 ms, and we should allow for a few polling updates before timeout.


Failed last test case despite able to pass on jshell

Summary
I failed to pass the last test case despite getting the desired output on jshell. Can someone assist me on this issue please?
Description:
Clarifications or details with respect to the issue you are facing
Code Snippets
Attach code snippets (if any)
Screenshots

Did you use ? extends Log<....> for your flatMap's return type?

refer to issue #409

If im not wrong there is an issue with the generics in your flatmap?

Thanks everyone, I managed to solve it already!

@Cpkee you might want to close this issue yeah?


common itility to switch auction status

This change is

Pull Request Test Coverage Report for Build 2822

1 of 5 (20.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.1%) to 70.896%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/openprocurement/api/utils.py
1
5
20.0%

Totals

Change from base Build 2820:
-0.1%

Covered Lines:
1883

Relevant Lines:
2656

💛  - Coveralls


Add node to extract location offsets from models

Models have

given offset vectors (i.e. as local placement shift)
geometrically implied shifts (i.e. mean over all components, mean of disjoint regions, ...)

Requires a new geometry building node to analyse the model's geometry.


fix double evaluations

address known issues reported at https://securitylab.github.com/research/apache-struts-double-evaluation/

Coverage increased (+0.2%) to 47.541% when pulling 8d6e26e0feb8cb1669f45a66e458860534b94571 on fix/double_evaluations_2_5 into a96dd31be6bd16fd84ca3d683208cae8774d75b4 on struts-2-5-x.

I have a huge concern if such a big change should be introduced in a minor version like 2.5.27 - I'm ok with having it in 2.6 as this is natural to break backward comaptibility in a major version release. Users can be heavily impacted by this changes and won't be able update their apps.

Thanks @lukaszlenart I see. For me that has spent plenty of time on it, I remember it was obviously safe changes, but please let me double check, I'll let you know.
P.S. actually I like these changes for 2.5 because they improve Struts to behave better in currently publicly known double evaluation reports. It also contains small yet safe other improvements. Please consider it as an ordinary PR that somebody like to improve Struts. And please let me know any possibility of backward-compatibility issue.

@lukaszlenart I double checked and couldn't find any. Maybe to make it simpler just skip tests files review. Then you'll see obvious safe and nice changes. Test coverage is also increased 0.2%!

Tests are the most important in this change as changing existing tests means you probably introduced breaking changes as users can depend on the buggy implementation.

@lukaszlenart I double checked and host of them are additions or just java language improvements. Existing tests' functional changes are:
-assertEquals(bean.escape("hello!world"), "hello!world");
-assertEquals(bean.escape("hello!@#$%^&*()world"), "hello!@#$%^&*()world");
+assertEquals(bean.escape("hello!world"), "hello_world");
+assertEquals(bean.escape("hello!@#$%^&*()world"), "hello__________world");

which isn't a breaking changes because it's an Struts' internal change.
-tag.setId("cb.bc");
+tag.setId("cb['\".\"'] = bc(){};//");

and consequently
-mylabel:
+mylabel:
...
-function autoPopulate_cb_bc(targetElement) {
+function autoPopulate_cb__________bc_______(targetElement) {
-<input type="text" name="foo" value="hello" id="cb.bc"/>

-<select onChange="autoPopulate_cb_bc(this);">
+<input type="text" name="foo" value="hello" id="cb['"."']=bc(){};//"/>

+<select onChange="autoPopulate_cb__________bc_______(this);">

which isn't a breaking changes because it's an Struts' internal change.
-        <input type="radio" name="myMap['name']" id="myMap_'name'_"value=""/>
-        N/A
-        <input type="radio" name="myMap['name']" id="myMap_'name'_Opt." value="Opt."/>
-        Opt.
-        <input type="radio" name="myMap['name']" id="myMap_'name'_Std." checked="checked" value="Std."/>
-        Std.
+       <input type="radio" name="myMap['name']" id="myMap__name__"value=""/>
+       N/A
+       <input type="radio" name="myMap['name']" id="myMap__name__Opt." value="Opt."/>
+       Opt.
+       <input type="radio" name="myMap['name']" id="myMap__name__Std." checked="checked" value="Std."/>
+       Std.

which isn't a breaking changes because it's an Struts' internal change.
BTW can I merge at my own risk and responsibility? @apache/struts-committers

@yasserzamani me and @aleksandr-m expressed our concerns with introducing this change into the 2.5.x branch and you still ignore our votes and pushing your opinion. This not the the Apache way of collaborating.
I have a suggestion, we can release the current state of the 2.5.x branch as Struts 2.5.27 and then introduce your change and release 2.5.28 which will contain only your change. I think this is the safest option we have.

I think its philosophy is respectful, honest, technical-based interaction not concern-based and technically we haven't any reason I think.
But at bottom as per respectful OK 👍 I keep this PR open for the second next release :) thanks a lot for your contribution and comments!

My technical reason is very simply: this PR will be mixed in with other changes and if users start complain that something doesn't work after upgrade it can be very hard for us to figure out what's the core issue - this change or the other changes. If you want to you can prepare a strict security fix based on a STRUTS_2_5_26 tag and then release it separately. From my experience mixing security fixes with bug fixes isn't a good idea.

@yasserzamani Why dynamicAttributes type is changed?

@aleksandr-m thanks for asking! Now by merging upstream into this branch by me, a test of TextField has two dynamic parameters set (one added by Lukasz). Then I saw that tests are passing with jdk7 and are failing with jdk8 and newer. Then I realized that different JDKs return different order for HashMap.entrySet(). So I changed to LinkedHashMap which keeps order to avoid a workaround like click here. Furthermore I think it's nice to keep dynamic attributes order same as added by user. And at bottom, LinkedHashMap is also a Map so I think it shouldn't be a breaking change.

@aleksandr-m LinkedHashMap didn't help either. I just reverted it and instead I fixed (improved) the corresponding test to be able to verify against any of multiple possibilities.

LGTM 👍


RC5

You probably are already aware of the breaking changes in RC5 with modules. Any chance we can can a module made for these components.

Same problem here.  Can we get an update on when a new version will be ready?

I've updated the bootstrap 4 fork to use RC5 with modules: https://github.com/maxfisher05/ng2-bs4-modal/commit/968bc9c2c54a0b700985fb2d25b1b9b836ac0725
I don't think this commit could be directly merged back from fork but changes should be pretty similar.

I worked around this problem by creating a shared module like so...
import { NgModule }           from '@angular/core';
import { CommonModule }       from '@angular/common';
import { MODAL_DIRECTIVES } from 'ng2-bs3-modal/ng2-bs3-modal';
@NgModule({   imports: [ CommonModule ],   declarations: [ MODAL_DIRECTIVES ],   exports: [ MODAL_DIRECTIVES, CommonModule  ] }) export class SharedModule { }
Then I imported this module in AppModule (and any other module dependent on ng2-bs3-modal).
You may then remove any directives : [MODAL_DIRECTIVES] statements in those components that rely on ng2-bs3-modal.

Note that with RC6 just being released, there are changes that break the current ng2-bs3-modal.

@AHelper whats the breaking change, my wrapper module seems to still work after the upgrade?

Angular removed directives, in essence.

Should be good to go in v0.8.0.


Simplify the starting process

Right now, in order to start the storybook we need to run the app normally and start the storybook server separately.
This gets worst, when it's for Android.
We need to simplify this and simply use a single npm script to run start the whole process like this:
npm run storybook-ios

or
npm run storybook-android <device-id>

run-ios and run-android commands are already there. It will start storybook app on devices but the server needs to be started. Starting the storybook server separately can be useful when we view storybook on multiple devices at the same time.

Got it.


Update guidance for default data types

This PR

resolves https://github.com/data-apis/array-api/issues/319 by updating guidance for default data types. Namely, this PR  adds guidance for a default array index data type which can be specified independently of the default integer data type.

In it goes...


Add metrics to round status

This PR adds performance metrics obtained from collaborators, as well as aggregated ones, to the round_status dictionary.

Demo of the output using the MNIST Federation example:
current_round:
  assigned_collaborators:
  - collaborator1
  - collaborator2
  available_collaborators:
  - collaborator2
  - collaborator1
  collaborators_progress:
  - col_name: collaborator1
    start_time: 9.314050674438477
    tasks_end_time:
    - end_time: 10.506012916564941
      task_name: aggregated_model_validation
  - col_name: collaborator2
    start_time: 0.0
    tasks_end_time:
    - end_time: 0.5396029949188232
      task_name: aggregated_model_validation
    - end_time: 9.20370864868164
      task_name: train
    - end_time: 10.265809059143066
      task_name: locally_tuned_model_validation
  metrics:
  - metric_name: accuracy
    metric_origin: collaborator2
    metric_value: 0.9179835915565491
    round: 1
    task_name: aggregated_model_validation
  - metric_name: cross_entropy
    metric_origin: collaborator2
    metric_value: 0.24446219205856323
    round: 1
    task_name: train
  - metric_name: accuracy
    metric_origin: collaborator2
    metric_value: 0.9501900672912598
    round: 1
    task_name: locally_tuned_model_validation
  - metric_name: accuracy
    metric_origin: collaborator1
    metric_value: 0.9232000112533569
    round: 1
    task_name: aggregated_model_validation
  round: 1
  round_start:<PHONE_NUMBER>.712976
  stragglers: []
  to_add_next_round: []
  to_remove_next_round: []
previous_round:
  assigned_collaborators:
  - collaborator1
  - collaborator2
  available_collaborators:
  - collaborator1
  - collaborator2
  collaborators_progress:
  - col_name: collaborator1
    start_time: 0.0
    tasks_end_time:
    - end_time: 0.716804027557373
      task_name: aggregated_model_validation
    - end_time: 13.963298797607422
      task_name: train
    - end_time: 14.40356731414795
      task_name: locally_tuned_model_validation
  - col_name: collaborator2
    start_time: 1.1470530033111572
    tasks_end_time:
    - end_time: 1.7421810626983643
      task_name: aggregated_model_validation
    - end_time: 14.529108047485352
      task_name: train
    - end_time: 14.950443267822266
      task_name: locally_tuned_model_validation
  metrics:
  - metric_name: accuracy
    metric_origin: collaborator1
    metric_value: 0.0934000015258789
    round: 0
    task_name: aggregated_model_validation
  - metric_name: accuracy
    metric_origin: collaborator2
    metric_value: 0.10362072288990021
    round: 0
    task_name: aggregated_model_validation
  - metric_name: cross_entropy
    metric_origin: collaborator1
    metric_value: 0.9241900444030762
    round: 0
    task_name: train
  - metric_name: accuracy
    metric_origin: collaborator1
    metric_value: 0.9133999943733215
    round: 0
    task_name: locally_tuned_model_validation
  - metric_name: cross_entropy
    metric_origin: collaborator2
    metric_value: 1.1223785877227783
    round: 0
    task_name: train
  - metric_name: accuracy
    metric_origin: collaborator2
    metric_value: 0.9133826494216919
    round: 0
    task_name: locally_tuned_model_validation
  - metric_name: cross_entropy
    metric_origin: aggregator
    metric_value: 1.0232826471328735
    round: 0
    task_name: train
  - metric_name: accuracy
    metric_origin: aggregator
    metric_value: 0.9133913516998291
    round: 0
    task_name: locally_tuned_model_validation
  - metric_name: accuracy
    metric_origin: aggregator
    metric_value: 0.09850984811782837
    round: 0
    task_name: aggregated_model_validation
  round: 0
  round_start:<PHONE_NUMBER>.5843909
  stragglers: []
  to_add_next_round: []
  to_remove_next_round: []


show full date in desktop date picker

Prerequisites:

[ ] Unless it is a hotfix it should be merged against the dev branch
[ ] Branch is up-to-date with the branch to be merged with, i.e. dev
[ ] Build is successful
[ ] Code is cleaned up and formatted

Summary

Thanks. One comment is that at this now causes the left arrow for me to hide behind hte menu bar for picking the region. Not a full browser width, but at "typical" browser width. Maybe we can decrease the space around the arrows in the new version?
New version:

Old version:

tune the style a bit:


bug: Specific Japanese character could not be yanked/pasted (E353)

Did you check docs and existing issues?

[X] I have read all the vscode-neovim docs
[X] I have searched the existing issues of vscode-neovim
[x] I can reproduce the issue with an empty init.vim/init.lua and no other vscode extensions (when applicable)

Neovim version (nvim -v)
v0.9.4
Operating system/version
14.2.1(23C71)
Describe the bug
Description:
I am experiencing a paste error with Japanese characters in Neovim. When I try to paste a string that contains the Japanese character "フ" followed by a newline and another Japanese character "の", I receive the error message "E353: Nothing in register "".
The string is correctly saved in the register, as shown by the output of the :registers command:
Type  Name  Content
  l  ""   フ^J

However, when I try to paste the string, I receive the error message.
This behavior is not consistent. If I change the character after "フ" to "て", the paste works correctly.
I have also tried this in Warp (Terminal) and Windows-based Vscode-Neovim, but the problem does not occur in those environments.
Steps to reproduce:

Open a new file in Neovim.
Write "フの"　or "フ"(and create new line)
Do yyp

Steps To Reproduce

Open a new file in Neovim.
Write "フの"　or "フ"(and create new line)
Do yyp

Expected Behavior
yyp works correctly for the line which contains "フの"　Characters

Can't reproduce

Thank you for checking.
Hmm.. it's strange but can be my environment probrem.
https://github.com/vscode-neovim/vscode-neovim/assets/23501475/ee02eabd-1868-4d27-bab6-394e16861994

I think I found the cause.
I am using Japanese OS settings on my Mac, but I added the following code to set neovim to English.
$ vim.cmd('language en_US')$
When I deleted the code, the status display in neovim returned to Japanese, but pasting was possible.
Could you please confirm if this can be reproduced?

If this issue still exists, please let me know, and I'll reopen this issue.


improve stability

As one of the basic Go Proverbs states Don't Panic
$ grep panic\( -r . | wc -l
73

This can get rather annoying when there is a number of tasks to perform for which an indeterminate amount of items can fail (for example a migration). It would be better to continue on and output items missing from the original media store afterwards. Preferably in a machine-readable list.
Seeing how this is all over the runtime, consistency checks, importers, and routers, this should probably be addressed overall. Go doesn't have try-catch for a reason after all.

Panic is used to deliberately kill the application context if something unrecoverable is encountered - the application should not continue because the application state is unsafe. There are certainly some panics which may need refinement, but as a general concept there are recover() calls in places to localize the impact, such as the routers.
If you have a specific error message or panic you think shouldn't be fatal, please open an issue for those individually.


add git bisect aliases to git plugin

fixes #3751

Hi, and thanks for contributing.
I am majorly refactoring the git plugin in #2790, go and have a look. The best course of action is to include your changes on top of the refactoring.
Easiest way (for me) to do so would be: you submitting a PR to my branch. Remember that all aliases are now alphabetically sorted, and take the opportunity to check that you are not duplicating any.

Also, you should have used "fixes #3751" instead of "for #3751" in the PR description. That way, the corresponding issue will auto-close once the changes are merged.

Ok, I'll do that pull request soon. Thanks

@robbyrussell this should have been closed by #2790, sorry I missed it, please close.

and #3751 too

@ncanceill I suggest you add them to your hotfix PR #3990

Good idea, it is done.


Adding support of kube-ui

interested to add kube-ui ? :)

ok, done.

@remoe can you add instructions on how to enable this to README.md?

When done with it, please squash your commits into one and push so I can merge.


Spurious segmentation fault in flushMetricsToSinks -> MetricSnapshotImpl

Title: Spurious segmentation fault in flushMetricsToSinks -> MetricSnapshotImpl
Description:
Envoy occasionally crashes when flushing metrics, which is unexpected.
Repro steps:
Unsure how to reproduce. It is seen spuriously (usually <10 times per day in production fleet).
It has been observed in:

1.11.2 + https://github.com/envoyproxy/envoy/pull/9121 + internal patch
1.12.2 + https://github.com/envoyproxy/envoy/pull/9121 + https://github.com/envoyproxy/envoy/pull/9509

Config:
# stats configuration

stats_flush_interval: 30s
stats_sinks:
  - name: "envoy.dog_statsd"
    config:
      address:
        socket_address:
          address: "<IP_ADDRESS>"
          port_value: 8200
stats_config:
  stats_tags:
    - tag_name: "envoy_dst_zone"
      regex: 'cluster\.(?:[^.]+\.)?zone\.[-a-z0-9]+\.(([-a-z0-9]+)?\.)'
    - tag_name: "envoy_src_zone"
      regex: 'cluster\.(?:[^.]+\.)?zone\.(([-a-z0-9]+)?\.)'

Call Stack:
From the 1.12.2 build described above:
[2020-02-26 18:12:18.680][2563][critical][backtrace] [bazel-out/k8-opt/bin/external/envoy/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:83] Caught Segmentation fault, suspect faulting address 0x0
[2020-02-26 18:12:18.681][2563][critical][backtrace] [bazel-out/k8-opt/bin/external/envoy/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:70] Backtrace (use tools/stack_decode.py to get line numbers):
[2020-02-26 18:12:18.681][2563][critical][backtrace] [bazel-out/k8-opt/bin/external/envoy/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:71] Envoy version: c3c7d68a4844af3cb125330ec6527243571aa822/<IP_ADDRESS>/Clean/RELEASE/BoringSSL
[2020-02-26 18:12:18.682][2563][critical][backtrace] [bazel-out/k8-opt/bin/external/envoy/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:75] #0: __restore_rt [0x7f54b8ab6390]
[2020-02-26 18:12:18.688][2563][critical][backtrace] [bazel-out/k8-opt/bin/external/envoy/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:75] #1: Envoy::Server::MetricSnapshotImpl::MetricSnapshotImpl() [0x55fe11a57415]
[2020-02-26 18:12:18.690][2563][critical][backtrace] [bazel-out/k8-opt/bin/external/envoy/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:75] #2: Envoy::Server::InstanceUtil::flushMetricsToSinks() [0x55fe11a57b32]
[2020-02-26 18:12:18.693][2563][critical][backtrace] [bazel-out/k8-opt/bin/external/envoy/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:75] #3: Envoy::Server::InstanceImpl::flushStatsInternal() [0x55fe11a57d7f]
[2020-02-26 18:12:18.696][2563][critical][backtrace] [bazel-out/k8-opt/bin/external/envoy/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:75] #4: Envoy::Stats::ThreadLocalStoreImpl::mergeInternal() [0x55fe11ac41b5]
[2020-02-26 18:12:18.699][2563][critical][backtrace] [bazel-out/k8-opt/bin/external/envoy/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:75] #5: std::_Function_handler<>::_M_invoke() [0x55fe11ac422b]
[2020-02-26 18:12:18.702][2563][critical][backtrace] [bazel-out/k8-opt/bin/external/envoy/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:75] #6: Envoy::Event::DispatcherImpl::runPostCallbacks() [0x55fe11a9ae23]
[2020-02-26 18:12:18.705][2563][critical][backtrace] [bazel-out/k8-opt/bin/external/envoy/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:75] #7: event_process_active_single_queue.isra.33 [0x55fe11db34b0]
[2020-02-26 18:12:18.707][2563][critical][backtrace] [bazel-out/k8-opt/bin/external/envoy/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:75] #8: event_base_loop [0x55fe11db3b7f]
[2020-02-26 18:12:18.710][2563][critical][backtrace] [bazel-out/k8-opt/bin/external/envoy/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:75] #9: Envoy::Server::InstanceImpl::run() [0x55fe11a60eba]
[2020-02-26 18:12:18.713][2563][critical][backtrace] [bazel-out/k8-opt/bin/external/envoy/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:75] #10: Envoy::MainCommonBase::run() [0x55fe1144abfc]
[2020-02-26 18:12:18.716][2563][critical][backtrace] [bazel-out/k8-opt/bin/external/envoy/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:75] #11: main [0x55fe11412453]
[2020-02-26 18:12:18.716][2563][critical][backtrace] [bazel-out/k8-opt/bin/external/envoy/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:75] #12: __libc_start_main [0x7f54b86fb830]

cc @jmarantz @ramaraochavali there must be some timing issue in the histogram merging code?

I think it is not histogram merge code, If I am reading this correctly It is actually failing at completion callback https://github.com/envoyproxy/envoy/blob/master/source/server/server.cc#L182 which is flushStatsInternal. Are you thinking it could have been caused by some timing issue with  when the completion callback is called?

Yeah there must be some type of lifetime issue during the merge/update sequence. I haven't looked in detail though.

@mattklein123 and I were chatting earlier, and he made me aware of this issue. We are seeing a crash thanks to an assertion on HistogramStatisticsImpl::refresh https://github.com/lyft/envoy-mobile/issues/688.
@ramaraochavali let me know if you think these might be related. Given that most people deploying server-side compile assertions out, but we (envoy mobile) don't it might be the case that this issue would hit an assertion before segfaulting if assertions were compiled.
As I mentioned in https://github.com/lyft/envoy-mobile/issues/688#issuecomment-597747745 I can't quite reason why either of the two assertions on refresh would ever be hit. lmk if you have any thoughts.

@junr03 To me this one looks little different i.e. it seems to be happening after histogram merge is done and we actually flush the stats some where here https://github.com/envoyproxy/envoy/blob/master/source/server/server.cc#L167

As I mentioned in lyft/envoy-mobile#688 (comment) I can't quite reason why either of the two assertions on refresh would ever be hit. lmk if you have any thoughts.

Hmm..  AFAICT, this should not definitely happen for Quantiles. They are fixed and should be same always unless hist_approx_quantile is some how messing up with the data passed in,  during previous merge? At other places we always iterate by supported_quantiles so may not be creating issue? and was there an upgrade of libcircllhist in the recent past?

@ramaraochavali I am responding in https://github.com/lyft/envoy-mobile/issues/688 to not pollute this with Envoy Mobile details.


when load a glb error "file requires Draco mesh compression support"

I wonder how could I add Draco mesh compression support to gltfpack?
is there anyone to give me a hand?

gltfpack doesn't support files that are encoded with Draco. If you want to reoptimize these, I'd recommend using a tool like gltf-pipeline to convert a glTF file with Draco to one without. Note that gltfpack provides its own algorithm for compression as well when using -c option.

gltfpack doesn't support files that are encoded with Draco. If you want to reoptimize these, I'd recommend using a tool like gltf-pipeline to convert a glTF file with Draco to one without. Note that gltfpack provides its own algorithm for compression as well when using -c option.

yes,i got what you means;but i wonder how could I add draco(C++) lib into gltfpack ,i think it will be more practical；

You can try to integrate Google's Draco library and decode the meshes during glTF parsing in parsegltf.cpp. I want to note though that this is a rare case where a change like this would not be accepted as a contribution, because gltfpack strives to have a minimal set of dependencies, and Draco alone takes much more time to build and results in a larger binary than the rest of gltfpack.
I'd also note that using Draco and recompressing with gltfpack later will results in a larger quantization error, because the error induced by Draco will be magnified by gltfpack. Because of this it's recommended to use gltfpack to process source glTF files, and the suggested gltf-pipeline step is just a workaround for cases when you don't have access to the version of the file before compression.


Wikilinks cannot recognize Chinese anchors.

https://quartz.jzhao.xyz/features/wikilinks
When my heading is in English, [[Path to file#anchor|Anchor]] works fine, but it fails when it is changed to Chinese.

same as mine!

Is this exclusive to just anchors or does it affect regular page links too?

The problem is very simple, in line 35, link.href is the URL-encoded version.
https://github.com/jackyzha0/quartz/blob/5926d3f803606d86129ed658147e66986d15fba8/quartz/components/scripts/popover.inline.ts#L35-L36
Using its hash will cause querySelector to report an error:
Uncaught (in promise) DOMException: Element.querySelector: '#%E4%BB%B7%E5%80%BC%E5%87%BD%E6%95%B0' is not a valid selector

Where #%E4%BB%B7%E5%80%BC%E5%87%BD%E6%95%B0 should be Chinese #价值函数.
Therefore, a simple solution is to replace line 36 with:
const hash = decodeURIComponent(targetUrl.hash)

I will submit a PR soon.


Monitor of MirrorSes

Even if one MirrorS has implemented their own monitor mechanisms, global comparison between MirrorS is still wanted by users and mirror admins, hence a monitor of MirrorSes may be implemented.
In the List of current frontend, status of MirrorS are grouped by repo, not by MirrorS. This is not convenient if one wants to know the overall status of one particular MirrorS, Hence the above monitor should have one mechanism implemented by grouping by MirrorS.
Also in this monitor page some meta info of one mirror can be listed, like introduction, email, issue-tracker, etc.

Implemented with commit 2b45fff437580edc44d54827d716b6b8edd18b8c
Other more meta should be discuessed in the design of mirrorz.json format

Implemented with commit 2b45fff437580edc44d54827d716b6b8edd18b8c
Other more meta should be discuessed in the design of mirrorz.json format


how do i activate python environment?

how do i activate python environment? i don't know and all tutorials talk about vs code. I'm not using vs code

Update: got a solution for environment activation in powershell
instead of .bat as in the line below
venv\Scripts\activate.bat
us following
venv\Scripts\activate.ps1 and you will see the green venv line and you are ready to continue


HDDS-1153. Make tracing instrumentation configurable

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
35
Docker mode activated.

_ Prechecks _

+1
@author
0
The patch does not contain any @author tags.

-1
test4tests
0
The patch doesn't appear to include any new or modified tests.  Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

0
mvndep
93
Maven dependency ordering for branch

-1
mvninstall
1098
root in trunk failed.

+1
compile
1033
trunk passed

+1
checkstyle
190
trunk passed

+1
mvnsite
256
trunk passed

+1
shadedclient
1123
branch has no errors when building and testing our client artifacts.

+1
findbugs
312
trunk passed

+1
javadoc
204
trunk passed

_ Patch Compile Tests _

0
mvndep
25
Maven dependency ordering for patch

+1
mvninstall
190
the patch passed

+1
compile
949
the patch passed

+1
javac
949
the patch passed

+1
checkstyle
207
the patch passed

+1
mvnsite
225
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
xml
2
The patch has no ill-formed XML file.

+1
shadedclient
626
patch has no errors when building and testing our client artifacts.

+1
findbugs
399
the patch passed

+1
javadoc
227
the patch passed

_ Other Tests _

+1
unit
89
common in the patch passed.

+1
unit
35
tools in the patch passed.

+1
unit
40
client in the patch passed.

+1
unit
48
common in the patch passed.

+1
unit
40
objectstore-service in the patch passed.

+1
unit
55
ozone-manager in the patch passed.

+1
asflicense
49
The patch does not generate ASF License warnings.

7413

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/hadoop-multibranch/job/PR-673/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/673

Optional Tests
dupname  asflicense  compile  javac  javadoc  mvninstall  mvnsite  unit  shadedclient  findbugs  checkstyle  xml

uname
Linux 325e602832c1 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 8bfef21

maven
version: Apache Maven 3.3.9

Default Java
1.8.0_191

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-673/1/artifact/out/branch-mvninstall-root.txt

findbugs
v3.1.0-RC1

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-673/1/testReport/

Max. process+thread count
410 (vs. ulimit of 5500)

modules
C: hadoop-hdds/common hadoop-hdds/tools hadoop-ozone/client hadoop-ozone/common hadoop-ozone/objectstore-service hadoop-ozone/ozone-manager U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-673/1/console

Powered by
Apache Yetus 0.9.0 http://yetus.apache.org

This message was automatically generated.


Error creating room Error: no auth mechanism defined

Error creating room Error: no auth mechanism defined
I'm getting this error in console when I run the project; despite generating fresh API key and secret. Could you help me what could possibly be wrong here?

Where are you getting that error, at the browser or at the node console? Are you sure you set appropriately the .env file as specified in the README?


fix: add do token to atlantis

Ran Plan for dir: terraform/atlantis workspace: default
Plan Error
Show Output
running "/usr/local/bin/terraform init -input=false -no-color -upgrade" in "/root/.atlantis/repos/autotune/pritunl-k8s-tf-do/3/default/terraform/atlantis": exit status 1

Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Finding latest version of hashicorp/kubernetes...
- Finding latest version of hashicorp/digitalocean...
- Finding latest version of hashicorp/helm...
- Installing hashicorp/helm v2.4.1...
- Installed hashicorp/helm v2.4.1 (signed by HashiCorp)
- Installing hashicorp/kubernetes v2.8.0...
- Installed hashicorp/kubernetes v2.8.0 (signed by HashiCorp)

Error: Failed to query available provider packages

Could not retrieve the list of available versions for provider
hashicorp/digitalocean: provider registry registry.terraform.io does not have
a provider named registry.terraform.io/hashicorp/digitalocean

Did you intend to use digitalocean/digitalocean? If so, you must specify that
source address in each module which requires that provider. To see which
modules are currently depending on hashicorp/digitalocean, run the following
command:
    terraform providers

Ran Plan for dir: terraform/atlantis workspace: default
Plan Error
Show Output
running "/usr/local/bin/terraform plan -input=false -refresh -no-color -out \"/root/.atlantis/repos/autotune/pritunl-k8s-tf-do/3/default/terraform/atlantis/default.tfplan\"" in "/root/.atlantis/repos/autotune/pritunl-k8s-tf-do/3/default/terraform/atlantis": exit status 1

Warning: Version constraints inside provider configuration blocks are deprecated

  on providers.tf line 12, in provider "digitalocean":
  12:   version = ">=1.5.0"

Terraform 0.13 and earlier allowed provider version constraints inside the
provider configuration block, but that is now deprecated and will be removed
in a future version of Terraform. To silence this warning, move the provider
version constraint into the required_providers block.

Error: Reference to undeclared input variable

  on providers.tf line 11, in provider "digitalocean":
  11:   token   = var.do_token

An input variable with the name "do_token" has not been declared. This
variable can be declared with a variable "do_token" {} block.

Ran Plan for dir: terraform/atlantis workspace: default
Plan Error
Show Output
running "/usr/local/bin/terraform plan -input=false -refresh -no-color -out \"/root/.atlantis/repos/autotune/pritunl-k8s-tf-do/3/default/terraform/atlantis/default.tfplan\"" in "/root/.atlantis/repos/autotune/pritunl-k8s-tf-do/3/default/terraform/atlantis": exit status 1

Warning: Version constraints inside provider configuration blocks are deprecated

  on providers.tf line 12, in provider "digitalocean":
  12:   version = ">=1.5.0"

Terraform 0.13 and earlier allowed provider version constraints inside the
provider configuration block, but that is now deprecated and will be removed
in a future version of Terraform. To silence this warning, move the provider
version constraint into the required_providers block.

Error: No value for required variable

  on variables.tf line 7:
   7: variable "do_token" {

The root module input variable "do_token" is not set, and has no default
value. Use a -var or -var-file command line argument to provide a value for
this variable.

Ran Plan for dir: terraform/atlantis workspace: default
Plan Error
Show Output
running "/usr/local/bin/terraform plan -input=false -refresh -no-color -out \"/root/.atlantis/repos/autotune/pritunl-k8s-tf-do/3/default/terraform/atlantis/default.tfplan\"" in "/root/.atlantis/repos/autotune/pritunl-k8s-tf-do/3/default/terraform/atlantis": exit status 1

Warning: Version constraints inside provider configuration blocks are deprecated

  on providers.tf line 12, in provider "digitalocean":
  12:   version = ">=1.5.0"

Terraform 0.13 and earlier allowed provider version constraints inside the
provider configuration block, but that is now deprecated and will be removed
in a future version of Terraform. To silence this warning, move the provider
version constraint into the required_providers block.

Error: No value for required variable

  on variables.tf line 7:
   7: variable "do_token" {

The root module input variable "do_token" is not set, and has no default
value. Use a -var or -var-file command line argument to provide a value for
this variable.

Ran Plan for dir: terraform/atlantis workspace: default
Plan Error
Show Output
running "/usr/local/bin/terraform plan -input=false -refresh -no-color -out \"/root/.atlantis/repos/autotune/pritunl-k8s-tf-do/3/default/terraform/atlantis/default.tfplan\"" in "/root/.atlantis/repos/autotune/pritunl-k8s-tf-do/3/default/terraform/atlantis": exit status 1

Warning: Version constraints inside provider configuration blocks are deprecated

  on providers.tf line 12, in provider "digitalocean":
  12:   version = ">=1.5.0"

Terraform 0.13 and earlier allowed provider version constraints inside the
provider configuration block, but that is now deprecated and will be removed
in a future version of Terraform. To silence this warning, move the provider
version constraint into the required_providers block.

Error: No value for required variable

  on variables.tf line 7:
   7: variable "do_token" {

The root module input variable "do_token" is not set, and has no default
value. Use a -var or -var-file command line argument to provide a value for
this variable.


Convert release-tasks script from bash to using Rails runner

This should be faster than separately invoking various Rails commands.

Woops, my automated script merged this unintentionally before the GitHub checks had passed due to an oversight in the script's implementation.

Fortunately, the tests did pass, though.


Update README install instructions

q2-fmt engraftment fails due frictionless issues with 2022.11

Good catch, thanks for updating this @cherman2! Once CI passes this is good to merge.


Using CNAME records on DNS to map traffic to Istio ingress

We have a cluster running on GCP, with Istio ingress set up on it.
We are currently in a process of adding a DNS record to map from example.site2.com to example.site1.com. We have setup the gateway currently withe following config:
  Hosts:
      *.example.site1.com
    Port:
      Name:      https-wc
      Number:    443
      Protocol:  HTTPS
    Tls:
      Credential Name:  ingressgateway-wc-certs
      Mode:             SIMPLE
    Hosts:
      example.site1.com
    Port:
      Name:      https-base
      Number:    443
      Protocol:  HTTPS

We currently have an A record which is mapping *.example.site1.com to the ingress external IP address. Our intention is to map all traffic from example.site2.com to example.site1.com. Currently we get an NR (Not DestinationRule or VirtualService) error when visiting example.site2.com. Is this achievable?

*.example.site1.com doesn't match example.site2.com nor example.site1.com. not sure if that matches your real world usage though or just a mistake on example?
NR means either the request SNI or Host header isn't matching though, would be good to double check if the client were the host header to site1. I suspect most won't with a CNAME

*.example.site1.com doesn't match example.site2.com nor example.site1.com. not sure if that matches your real world usage though or just a mistake on example?
NR means either the request SNI or Host header isn't matching though, would be good to double check if the client were the host header to site1. I suspect most won't with a CNAME

@howardjohn No the current setup is the same as above with the wild cards and without the wild cards.  Not sure if this is possible at all with Istio? Basically using one domain to setup Istio and then using a CNAME record to map another domain to the original one (example.site1.com in our case).

The approach is fundamentally flawed. Its not an Istio issue.
Consider a dns record like so:
;; ANSWER SECTION:
cname.howardjohn.info.  29      IN      CNAME   blog.howardjohn.info.
blog.howardjohn.info.   59      IN      A       <IP_ADDRESS>

A client request:
$ curl https://cname.howardjohn.info -v
*   Trying <IP_ADDRESS>:443...
* Connected to cname.howardjohn.info (<IP_ADDRESS>) port 443 (#0)
curl: (60) SSL: no alternative certificate subject name matches target host name 'cname.howardjohn.info'
``

If we ignore the TLS error (maybe you have a wildcard cert, so it works for your case):

$ curl https://cname.howardjohn.info -vk

Trying <IP_ADDRESS>:443...
Connected to cname.howardjohn.info (<IP_ADDRESS>) port 443 (#0)

GET / HTTP/2
Host: cname.howardjohn.info
user-agent: curl/7.86.0
accept: /

You can see in the request, everything is "cname.howardjohn.info". The istio ingress will not see anything about "site1" in your case.

You need to actually match against the names that *clients will use*. This is fundamentally how HTTP and TLS work, not Istio specific.

Thanks for your explanation @howardjohn - I understand the behaviour and issue now
So I believe the only way to overcome this is to define a virtual service for example.site2.com which maps to the correct service on the cluster? (Assuming that example.site2.com has valid certs)

Yes
On Wed, Dec 14, 2022 at 11:49 AM Arshia Malekahmadi <
@.***> wrote:

Thanks for your explanation @howardjohn https://github.com/howardjohn -
I understand the behaviour and issue now
So I believe the only way to overcome this is to define a virtual service
for example.site2.com which maps to the correct service on the cluster?
(Assuming that example.site2.com has valid certs)
—
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/42434#issuecomment-1352059487, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXPNV7ZEV6NDWW5TOBTWNIQETANCNFSM6AAAAAAS5TVBS4
.
You are receiving this because you were mentioned.Message ID:
@.***>


use bitcoin-hpke to release bitcoin-ohttp

@spacebear21 I just want you to keep up to date with what's going on. This does a minimum change to support bitcoin-hpke without ripping out all of the stuff we don't use like nss (yet)