AttributeError: 'str' object has no attribute 'keys' during execution

Hello,
I really liked your work and would like to test the network !
Thank you for making it available.
I had a small problem which I think might be a bug, everything loads fine at the beginning, then it crashes saying that some string, isn't a dictionnary.
Here is an output from my terminal.
I have one more question, where are the test files stored ? If I want to imput my own picture, where do I put it, and where do I tell you algorithm the path to it ?
Thank you very much in advance for your answers !
Best regards,
python main.py --cfg configs/epipolar/keypoint_h36m_resnet152_384_pretrained_8gpu.yaml DOTRAIN False WEIGHTS outs/pose_resnet_4.5_pixels_human36m.pth
2020-06-01 01:04:41,493 kp INFO: Namespace(cfg='configs/epipolar/keypoint_h36m_resnet152_384_pretrained_8gpu.yaml', opts=['DOTRAIN', 'False', 'WEIGHTS', 'outs/pose_resnet_4.5_pixels_human36m.pth'])
2020-06-01 01:04:41,493 kp INFO: Loaded configuration file configs/epipolar/keypoint_h36m_resnet152_384_pretrained_8gpu.yaml
2020-06-01 01:04:41,493 kp INFO:
DATASETS:
    TRAIN: ('multiview_h36m_train',)
    #TRAIN: ('h36m_val',)
    TEST: ('multiview_h36m_val', )
    TASK: multiview_keypoint
    DATA_FORMAT: jpg
    IMAGE_SIZE: (384, 384)
    IMAGE_RESIZE: 1. #3.90625 #1000. / 256
    PREDICT_RESIZE: 1.
    H36M:
        TRAIN_SAMPLE: 0
        MAPPING: False
DATALOADER:
    NUM_WORKERS: 20
BACKBONE:
    ENABLED: True
    BODY: epipolarposeR-152
    PRETRAINED: True
    PRETRAINED_WEIGHTS: datasets/pose_resnet_4.5_pixels_human36m.pth
    DOWNSAMPLE: 4
    SYNC_BN: True
SOLVER:
    OPTIMIZER: adam
    BASE_LR: 0.001
    STEPS: (2, 3)
    MAX_EPOCHS: 4
    IMS_PER_BATCH: 32
    CHECKPOINT_PERIOD: 1
EPIPOLAR:
    TOPK: 1
    MERGE: late
    SHARE_WEIGHTS: True
    ATTENTION: avg
    PARAMETERIZED: ('z',)
    PRETRAINED: False
    ZRESIDUAL: True
    SAMPLESIZE: 64
    USE_CORRECT_NORMALIZE: True
TEST:
    IMS_PER_BATCH: 1
KEYPOINT:
    HEATMAP_SIZE: (96, 96)
    SIGMA: 12.
    NUM_PTS: 17
    TRIANGULATION: epipolar
    CONF_THRES: .85
    RANSAC_THRES: 35
    LOSS: joint
    LOSS_PER_JOINT: False
VIS:
    MULTIVIEW: True
OUTPUT_DIR: outs/epipolar/dgx/keypoint_h36m_resnet152_384_8gpu
EVAL_FREQ: 1

2020-06-01 01:04:41,493 kp INFO: Running with config:
BACKBONE:
  BN_MOMENTUM: 0.1
  BODY: epipolarposeR-152
  DOWNSAMPLE: 4
  ENABLED: True
  PRETRAINED: True
  PRETRAINED_WEIGHTS: datasets/pose_resnet_4.5_pixels_human36m.pth
  SYNC_BN: True
DATALOADER:
  BENCHMARK: False
  NUM_WORKERS: 20
  PIN_MEMORY: True
DATASETS:
  CAMERAS: ()
  COMPLETENESS: 1.0
  CROP_AFTER_RESIZE: False
  CROP_SIZE: (512, 320)
  DATA_FORMAT: jpg
  H36M:
    FILTER_DAMAGE: True
    MAPPING: False
    REAL3D: True
    TEST_SAMPLE: 64
    TRAIN_SAMPLE: 0
  IMAGE_RESIZE: 1.0
  IMAGE_SIZE: (384, 384)
  INCLUDE_GREY_IMGS: True
  PREDICT_RESIZE: 1.0
  ROT_FACTOR: 0
  SCALE_FACTOR: 0.0
  TASK: multiview_keypoint
  TEST: ('multiview_h36m_val',)
  TRAIN: ('multiview_h36m_train',)
  WRIST_COORD: False
DEVICE: cuda
DOTEST: True
DOTRAIN: False
EPIPOLAR:
  ATTENTION: avg
  BOTTLENECK: 1
  FIND_CORR: feature
  MERGE: late
  MULTITEST: False
  OTHER_GRAD: ('other1', 'other2')
  OTHER_ONLY: False
  PARAMETERIZED: ('z',)
  POOLING: False
  PRETRAINED: False
  PRIOR: False
  PRIORMUL: False
  REPROJECT_LOSS_WEIGHT: 0.0
  SAMPLESIZE: 64
  SHARE_WEIGHTS: True
  SIMILARITY: dot
  SIM_LOSS_WEIGHT: 0.0
  SOFTMAXBETA: True
  SOFTMAXSCALE: 0.125
  SOFTMAX_ENABLED: True
  TOPK: 1
  TOPK_RANGE: (1, 2)
  USE_CORRECT_NORMALIZE: True
  VIS: False
  WARPEDHEATMAP: False
  ZRESIDUAL: True
EVAL_FREQ: 1
FOLDER_NAME: outs/epipolar/dgx/keypoint_h36m_resnet152_384_8gpu/01-Jun-at-01-04-41
KEYPOINT:
  CONF_THRES: 0.85
  ENABLED: False
  HEATMAP_SIZE: (96, 96)
  LOSS: joint
  LOSS_PER_JOINT: False
  NFEATS: 256
  NUM_CAM: 0
  NUM_PTS: 17
  RANSAC_THRES: 35
  ROOTIDX: 0
  SIGMA: 12.0
  TRIANGULATION: epipolar
LIFTING:
  AVELOSS_KP: False
  CROP_SIZE: 256
  ENABLED: False
  FLIP_ON: False
  IMAGE_SIZE: 320
  MULTIVIEW_MEDIUM: True
  MULTIVIEW_UPPERBOUND: False
  VIEW_ON: False
LOG_FREQ: 100
OUTPUT_DIR: outs/epipolar/dgx/keypoint_h36m_resnet152_384_8gpu
PICT_STRUCT:
  DEBUG: False
  FIRST_NBINS: 16
  GRID_SIZE: 2000
  LIMB_LENGTH_TOLERANCE: 150
  PAIRWISE_FILE: datasets/h36m/pairwise.pkl
  RECUR_DEPTH: 10
  RECUR_NBINS: 2
  SHOW_CROPIMG: False
  SHOW_HEATIMG: False
  SHOW_ORIIMG: False
  TEST_PAIRWISE: False
SEED: 0
SOLVER:
  BASE_LR: 0.001
  BATCH_MUL: 1
  CHECKPOINT_PERIOD: 1
  FINETUNE: False
  FINETUNE_FREEZE: True
  GAMMA: 0.1
  IMS_PER_BATCH: 32
  MAX_EPOCHS: 4
  MOMENTUM: 0.9
  OPTIMIZER: adam
  SCHEDULER: multistep
  STEPS: (2, 3)
  WEIGHT_DECAY: 0.0
TENSORBOARD:
  COMMENT:
  USE: True
TEST:
  EPEMEAN_MAX_DIST: 150
  IMS_PER_BATCH: 1
  MAX_TH: 20
  PCK: True
  RECOMPUTE_BN: False
  THRESHOLDS: (1, 2, 5, 10, 20, 30, 40, 50, 60, 80, 100)
  TRAIN_BN: False
VIS:
  AUC: False
  CURSOR: False
  DOVIS: True
  EPIPOLAR_LINE: False
  FLOPS: False
  H36M: False
  MULTIVIEW: True
  MULTIVIEWH36M: False
  POINTCLOUD: False
  SAVE_PRED: False
  SAVE_PRED_FREQ: 100
  SAVE_PRED_LIMIT: -1
  SAVE_PRED_NAME: predictions.pth
  VIDEO: False
  VIDEO_GT: False
WEIGHTS: outs/pose_resnet_4.5_pixels_human36m.pth
WEIGHTS_ALLOW_DIFF_PREFIX: False
WEIGHTS_LOAD_OPT: True
WEIGHTS_PREFIX: module.
WEIGHTS_PREFIX_REPLACE:
2020-06-01 01:04:41,847 resnet INFO: => loading pretrained model from web
2020-06-01 01:04:41,847 resnet INFO: => init deconv weights from normal distribution
2020-06-01 01:04:41,848 resnet INFO: => init 0.weight as normal(0, 0.001)
2020-06-01 01:04:41,848 resnet INFO: => init 0.bias as 0
2020-06-01 01:04:41,894 resnet INFO: => init 1.weight as 1
2020-06-01 01:04:41,894 resnet INFO: => init 1.bias as 0
2020-06-01 01:04:41,894 resnet INFO: => init 3.weight as normal(0, 0.001)
2020-06-01 01:04:41,894 resnet INFO: => init 3.bias as 0
2020-06-01 01:04:41,900 resnet INFO: => init 4.weight as 1
2020-06-01 01:04:41,900 resnet INFO: => init 4.bias as 0
2020-06-01 01:04:41,900 resnet INFO: => init 6.weight as normal(0, 0.001)
2020-06-01 01:04:41,900 resnet INFO: => init 6.bias as 0
2020-06-01 01:04:41,906 resnet INFO: => init 7.weight as 1
2020-06-01 01:04:41,906 resnet INFO: => init 7.bias as 0
2020-06-01 01:04:41,906 resnet INFO: => init final conv weights from normal distribution
2020-06-01 01:04:41,906 resnet INFO: => init 8.weight as normal(0, 0.001)
2020-06-01 01:04:41,906 resnet INFO: => init 8.bias as 0
Traceback (most recent call last):
  File "main.py", line 75, in <module>
    main()
  File "main.py", line 68, in main
    test(cfg)
  File "/home/USER/Bureau/posEstimation/epipolar-transformers/engine/tester.py", line 31, in test
    model = Modelbuilder(cfg)
  File "/home/USER/Bureau/posEstimation/epipolar-transformers/modeling/model.py", line 34, in __init__
    self.reference = registry.BACKBONES[cfg.BACKBONE.BODY](cfg)
  File "/home/USER/Bureau/posEstimation/epipolar-transformers/modeling/backbones/resnet.py", line 515, in get_pose_net
    model.init_weights(cfg.BACKBONE.PRETRAINED_WEIGHTS)
  File "/home/USER/Bureau/posEstimation/epipolar-transformers/modeling/backbones/resnet.py", line 471, in init_weights
    load_state_dict(self, pretrained_state_dict, strict=False, ignored_layers=['final_layer.bias', 'final_layer.weight'], prefix=cfg.WEIGHTS_PREFIX, prefix_replace=cfg.WEIGHTS_PREFIX_REPLACE)
  File "/home/USER/Bureau/posEstimation/epipolar-transformers/utils/model_serialization.py", line 80, in load_state_dict
    if 'model' in loaded_state_dict.keys():
AttributeError: 'str' object has no attribute 'keys'

```

Could you confirm datasets/pose_resnet_4.5_pixels_human36m.pth exist? I don't have a machine to debug right now. Will get back to you later

For testing, you need to create a customized dataset and modify DATASETS.TEST in the cfg. After running the test, a output.pkl will be stored for visualization. Have a look at the visualization ipython notebook https://github.com/yihui-he/epipolar-transformers#epipolar-transformers-visualization


Update ExternalTimeBatchWindowTestCase

Purpose

Addresses #1387

Codecov Report

Merging #1390 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##             master   #1390      +/-   ##
===========================================
- Coverage     60.51%   60.5%   -0.01%
  Complexity       37      37
===========================================
  Files           632     632
  Lines         26497   26500       +3
  Branches       4190    4190
===========================================
  Hits          16034   16034
  Misses         9082    9082
- Partials       1381    1384       +3

Impacted Files
Coverage Δ
Complexity Δ

...c/main/java/io/siddhi/core/util/ThreadBarrier.java
80% <0%> (-20%)
0% <0%> (ø)

...java/io/siddhi/core/stream/input/InputHandler.java
77.41% <0%> (-3.23%)
0% <0%> (ø)

...ut/stream/state/AbsentStreamPreStateProcessor.java
85.21% <0%> (-1.41%)
0% <0%> (ø)

...o/siddhi/core/aggregation/IncrementalExecutor.java
80.31% <0%> (-0.79%)
0% <0%> (ø)

.../siddhi/core/table/record/AbstractRecordTable.java
4.76% <0%> (-0.1%)
0% <0%> (ø)

...ore/table/record/AbstractQueryableRecordTable.java
0% <0%> (ø)
0% <0%> (ø)
:arrow_down:

...e/src/main/java/io/siddhi/core/util/Scheduler.java
82.16% <0%> (+1.27%)
0% <0%> (ø)
:arrow_down:

...re/src/main/java/io/siddhi/core/SiddhiManager.java
50.79% <0%> (+7.93%)
0% <0%> (ø)
:arrow_down:

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 6c0e972...886f7f9. Read the comment docs.


Files no longer persisting

My files aren't persisting in local storage between refreshes. But the very first note I made, is still there. So there's a regression somewhere.

Didn't realize autosave had been turned off.


Miss the Online Demo

For non-coders, the online demo was very unique and useful. There's nothing else like it online.

@JamesJosephFinn I created a docker container a while ago https://hub.docker.com/r/palo/gdom
maybe that helps you to spin up your private server.

@mrVanDalo I'll give it a go. Thanks man!


python311Packages.bleak-esphome: 0.2.0 -> 0.3.0

Diff: https://github.com/bluetooth-devices/bleak-esphome/compare/refs/tags/v0.2.0...v0.3.0
Changelog: https://github.com/bluetooth-devices/bleak-esphome/blob/0.3.0/CHANGELOG.md
Description of changes

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

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

Result of nixpkgs-review pr 274671 run on x86_64-linux 1

4 packages built:

python310Packages.bleak-esphome
python310Packages.bleak-esphome.dist
python311Packages.bleak-esphome
python311Packages.bleak-esphome.dist


✨[Feature Request]: A message display "we will connect you soon "  when someone fills contact form

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
A message display "we will connect you soon "  when someone fills contact form
Use Case
giving user info that message has been sent
Benefits
A message display "we will connect you soon "  when someone fills contact form
Add ScreenShots
https://github.com/user-attachments/assets/7ef753a4-7c47-4afe-b614-2cce2f668c9a
Priority
High
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[X] I have starred the repository

@varshith257 please assign me this issue

@varshith257 @Anishkagupta04 please assign me this issue

@varshith257 please assign me this issue

@varshith257 please let me know should i work on it or close this issue

@ANKeshri Go ahead!


use a status subresource on the registry operator resource

I thought we'd already done this..is there a reason the registry resource doesn't define and use a Status subresource?

/cc @coreydaley @legionus @dmage

The problem was with the "modified" flag, it was hard to understand what was updated: Spec or Status. Today it should be pretty straightforward.


Glycosight file uploads are live on AWS servers

Tested in all environments except production (with requests coming from https://playbook-workflow-builder.cloud), so there may be some lingering CORS bugs to nip after this goes live.

I would like to pull this PR from open requests, pending refactor. Resolution of drs targets in local development will require pushing files to the compute nodes directly.


How do I retrieve BCH from my pre-august Bitpay wallet?

Hey guys,
I had my Bitpay wallet with a few BTC before august and I want to retrieve the bitcoin cash. I can't seem to find a way to do so.
https://blog.bitpay.com/bitcoin-cash-wallet-beta/
This page shows a 'Show my Bitcoin cash' button, but there isn't one in my Bitpay macOS app. It wasn't there with 3.6.2, and isn't available in 3.7.3 either. It isn't available in Copay latest version either, when I import my old wallet and it doesn't show in the Bitpay iOS app.
I also copied my 12-word phrase to BTC.com and tried to use their import tool and it said "No positive bitcoin cash balance found". Oddly enough, there was about 5 BTC in my Bitpay wallet..
So how do I retrieve my BCH?

you need to signup for the Beta. Please note this repo is for wallet-service, not for the wallet itself (https://github.com/bitpay/copay).


Move files between s3 and local (copy and paste)?

Describe the bug
Copy s3 file and paste in local folder is not working, and vice versa.
To Reproduce

Copy file in s3 bucket (cmd+C)
Move to local folder in file browser.
Cmd+V
Nothing happen.

Expected behavior
S3 file is copied to local folder (or "downloaded").
Screenshots
Desktop (please complete the following information):

OS: macOS 12.5
Browser: Chrome
Version of jupyterlab-s3-browser extension: 0.12.0

Additional context
Currently I can only use aws s3 cp to move files between s3 and local under CLI, which is a little bit tedious.

local file also cannot upload to s3 via browser

Hey @Alwin4Zhang , in 0.11.1 this is working.

Hey @Alwin4Zhang @cgjosephlee , in 0.11.1 this is working.

hi @octavd, I have installed 0.11.1. It is not working for me. Is there any configuration or some action I need to do to make it work?
Otherwise, hopefully the newer versions can fix this bug.


Day One (feat. Big L, A.G., Lord Finesse, & O.C.) by Diamond D unsupported.

Check if issue with swaglyrics or whether song lyrics unavailable on Genius.

stripper -> Diamond-D-Day-One
version -> 0.2.7

done


Note the Generations of the Lagent

I cannot know the version of lagent that agentlego support. At least the newest is not work well for agentlego. In requirements, I can't find infomation about which version lagent is supported. May you add it in readme please? Thanks a lot.
More infomation, the problem is that parser of to_lagent is not adjusted to new Lagent, so that it cannot be load in new version Lagent.

Can you tell me your agentlego and lagent version and the error you meet? the latest agentlego should always support the latest lagent.


[Accessibility] Remove redundant 4-5 blank lines from the terminal a11y buffer

CC @meganrogge

Note: the following issue is only found in cmd Command Prompt terminal profile. Other shells may or may not have the same issue.

Reproducible Steps

Load NVDA.

Run Terminal: Create New Terminal (With Profile).

Choose cmd Command Prompt.

Type the following in the cmd.exe and hit enter:

echo hello

Press Shift+Tab to focus in the a11y terminal buffer.

Press Ctrl+End key to go to the bottom of the buffer.

Current Behavior
After the last terminal content, redundant 4-5 blank lines are added so users will have to press UpArrow keys multiple times to reach the last content.
Expected Behavior
The redundant blanks need to be removed.
System Info
Version: 1.76.0-insider (system setup)
Commit: 96a795cc0b1cd62f9ff66c347637f917c6dde3da
Date: 2023-02-17T22:22:55.538Z
Electron: 19.1.9
Chromium: 102.0.5005.194
Node.js: 16.14.2
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.22621
Sandboxed: Yes

I have noticed that there are more blank lines produced when you use Terminal: Create New Terminal in Editor Area. I assume that this is because the a11y buffer size reflects Monaco editor size and pressing Ctrl+End key thus puts your cursor at the end of the editor buffer. This makes sense, but it would be nice if we could trim out the blank lines after the actual terminal content.

On macOS, end and cmd+end does nothing, while ctrl+end or alt+end both focus the vscode window rather than anything in the terminal (or, when screencast mode is on, they focus the screencast hint)

@connor4312 this is just an issue about not having empty lines in the accessible terminal buffer.

👍  no empty lines to be seen


billing: Clean up sponsorship form helper text.

Change to match proposed hero text.
Fix incorrect statement about event sponsorship; commercial
events should not be sponsored.

Testing plan:
I tried to test, but the helper text doesn't show up on dev and the whole form is different, so I'm not sure what's happening.
GIFs or screenshots:

@eeshangarg perhaps the regression causing the helper text not to show up on the page is related to your PR adding new org types to the sponsorship form? We should fix it and add helper text for the org types we didn't have before.

I added a batch of commits that should fix the following issues:

Split the education options to have for-profit and non-profit suboptions.
The help text now appears and uses the "other" text for all organization types without a special plan.
The organization type is prefilled with what you entered during realm creation (if any).
I edited the help text to clarify a few details that we want on this page, especially for the "other" categories.


[MCW] Tensor Parallel (TP) implementation of Decoder sub-module of Llama3.1_8b on n300

Implement TP implementation of Decoder sub-module, taking reference from Llama3.1_8b

[ ]  Implement Decoder sub-module using Tensor Parallelism.
- Implementing Tensor Parallel Decoder submodule is in progress.
- Facing shape mismatch error at linear of MLP submodule.
- Experimented on changing the input shards, gives shape mismatch at RMS submodule.
- Debugging further to resolve the issue.
[ ]  Compare the performance of the sub-module, with TP and without TP on n300.
[ ]  Look for improvements if there is a scope to improve performance via TP.

N300 supported now in main. Check PR https://github.com/tenstorrent/tt-metal/pull/13160 for more details


Contains features and ideas identical to  / directly from Electric w/o credit / mention

From what I have seen, Novus uses a lot of ideas that seem to be copied heavily inspired / directly copied from Electric.
Here are a few examples:
1. Package Name Autocorrection

vs

2. Auto Elevating the User

vs

3. Temp Directory Folder Structure

vs

Although it is natural to copy features from direct competitors, it is unethical not to credit or at the least, point out that these features are inspired by Electric. Hope this can be addressed soon 👍.

Um, yes. Giving credit/mention is the least that can be done

I completely agree with you. The Novus website seems heavily inspired by https://hydralite.io and https://covisource.in as well, two projects I worked/am working on. As an open-source project, I understand how this may seem alright to do, however, it's unethical in the face of software development. Please attend to this whenever possible, and at least credit the platforms you were inspired by.

Most features seem to be very similar - too similar.
Credit should be given at the very least

I have looked at this issue, and I have given credits to Electric and Chocolatey as it inspired me to build Novus. I have also mentioned hydralite as an inspiration for the website theme
There always might be some similarities in products trying to solve similar problems. For example, atom and sublime text, gimp and photoshop, google docs and ms word, etc will all have similar features.
With this in mind, I assure you that the Novus codebase was developed independently.

@ZaphodElevated thanks for looking into this - would appreciate if you could link the CREDITS.md to the readme under a credits heading, most people end up going through the README instead of casually browsing code files.


Add support for upcoming Ubuntu 22.04

We need to make sure that we support Ubuntu 22.04 before it's released in April 2022. This work should be done so that we have a released build of 16/17 out before Ubuntu 22.04 is released.

Hey @tas50, from what I can see at https://www.chef.io/downloads/tools/infra-client?os=ubuntu, it looks like there still isn't a chef-client for Ubuntu 22.04 available and this GitHub issue is the first result on Google on the topic.
Is it correct that chef-client won't run on Ubuntu 22.04 LTS ?

Also interested in this topic. @tas50 is there any update on this?

@axl89 If you follow the link I posted above you can see that Chef 18 has now been released for Ubuntu 22.04
When I added my comment 2½ months ago, only Ubuntu 20.04 was supported.


21 | Merge Two Sorted Lists | Python

Leetcode Question no. - 21
Problem name - Merge Two Sorted Lists
Instructions

Create a new folder for your script and file/folder name should be appropriate.
Create a README.md in your folder for program Instructions
add requirements.txt if needed

Programming Language

[x] Python

Happy Coding

Hey @pawangeek . I would like to contribute. Can you assign this issue to me?

Can you assign this to me?


x/build/cmd/gopherbot: remove NeedsDecision on proposals

Per @golang/proposal-review, the bot should remove NeedsDecision on proposals. It's redundant and messes with searches.

The Needs labels are added by humans. The Proposal label is added by bots.
The NeedsDecision label indicates that a proposal has been triaged by humans, which is a useful signal for whether the proposal is ready for a more in-depth review by the other humans who own the package(s) in question.

...unless the idea is for the proposal committee to be the ones to loop in the humans? But that seems like it adds needless overhead for the proposal committee and needless delay in getting feedback from owners.

Every proposal needs a decision.  It doesn't seem to help to add the NeedsDecision label to a proposal.
You suggest a possible meaning for NeedsDecision on proposals, but in fact the proposal review team doesn't use that label, and doesn't have a need for it.
(For Go 2 proposals, on the other hand, we do use NeedsDecision, to mean that the proposal seems ready and we just need to decide whether or not to adopt it.)

The NeedsDecision label is more of a cue for folks triaging issues than for the proposal committee: some proposals clearly need more information, or clearly need feedback from specific owners, or are duplicates of existing proposals, so it's useful for folks to have some signal about whether that first-pass check has been completed.
The Proposal label does not capture that first-pass check, since Gopherbot applies it automatically based on the issue title.
Currently, the NeedsDecision label does, since it is not automatic.
As an alternative, I suppose we could change Goptherbot to stop adding the Proposal label. Then that label itself could serve as an indicator of triage status.

Sounds like we are using NeedsDecision for two different unrelated purposes.

The triage rotation does not need to triage Proposal issues. It would help the proposal reviewers if the proposals did not say NeedsDecision. @bradfitz says the triage github search shortcut says -label:proposal anyway.
Can we agree that Proposals can drop the NeedsDecision label automatically?

/cc @julieqiu FYI, since you were considering changes to the triage search link.

If y'all really don't want any first-level triage on proposals, then I guess it's fine to drop the NeedsDecision label from those issues.

Yes, we don't need any first-level triage on proposals. Thanks.


Fail ComplexTypeModelBinder after CanCreateModel(...) in some cases

#4802
also reduces the impact of incorrect metadata as in #4939 and #6616

/cc @pranavkm

Bump @rynowak


Follow SemVer for package version

First of all thank you for your awesome package! We are using it in our projects and we are very pleased with it.
Although, I see there's some space for improvements in terms of versioning. What do you think about following Semantic Versioning to make world a better place? That would really help with dependencies resolution, automation like CI/CD and quality assurance in general.
Some useful resources:

http://semver.org/
https://github.com/semantic-release/semantic-release

https://github.com/grevory/angular-local-storage/issues/289

@0x2206 thank you for your input. Yes we are following semver but with our last release I underestimate the impact of the changes. I will pay more attention in the future to avoid this kind of situations. :+1:


Add notification alert on receiving message from anyone.

Hello contributors, this project already uses react-hot-toast, someone just have to trigger it on receiving any message, If you have any doubt you can ask me.

I want to work on this issue, can you assign me?

sure @PratikMbade,
I have assigned you the issue, you may start working on it


Add meshoptimizer

@jaremieromer Are there potential problems with animation here due to vertex reordering (or deduping)? I suspected they would get wonky, but both skelington and ogre animations seemed normal after optimizing. If so, I can turn off optimizations for animated meshes.

@jaremieromer Are there potential problems with animation here due to vertex reordering (or deduping)? I suspected they would get wonky, but both skelington and ogre animations seemed normal after optimizing. If so, I can turn off optimizations for animated meshes.

No, this was my concern leading up to the MR, but refreshing my memory of the animation code and process addressed my worries.
I had two concerns, initially:

What if the data store of vertex to bone gets out of sync with the animated bones data store?
What if we cull the only vertex that was influenced by bones?

For 1:
Not a concern. We grab the data of which vertex is mapped to which bones in GeometryConverter and store those bones' IDs in the Vertex before we cull vertices. Then, animation is all done at the bone level, and we're not culling bones/bone keyframe data. We pass a buffer of animated bone transforms and a mapping between bone ID and bone transform to the shader. The individual vertices already have this boneID as part of VertexData.
For 2:
It could be a concern if we abuse weight painting to make the error occur - but in our workflow I don't think we'd ever run into it:
Animation roughly works like:
Each vertex has the four closest bones' weights (influences) painted on to it in 3d modeling software. This is done by locality to the bone.
We then get the animated transform for the bone each frame, and in the vertex shader the vertex then calculates it's transform per frame based on its four bones' transforms (more or less).
Because our vertex weight painting workflow is done by locality to the bone - we don't have to worry about a scenario where we culled our only vertex with bone influences - because  meshoptimizer isn't going to cull a lone vertex (I'm thinking a really long and thin spike pyramid thingy) because it would be so significant it would not meet the exclusion criteria, and even if it was culled it'd be a wonky mesh from the get-go because that bone should also be influencing the four vertices on the base of the pyramid.
TLDR: I really don't think we're going to hit this case because of interpolation and the nature of weight painting meaning that similar vertices generally are influenced by similar bones at a similar weight.


Calculate color scales without importing chroma.js completely

Currently chroma.js is used to calculate color scales in the LCh color space dynamically. However, chroma.js does not support tree shaking so even though only a small subset of functionality is needed the whole library ends up in the bundle. One possibility would be to extract the required functionality and copy it to this project to reduce bundle size.
On the other hand, other tree shakable libraries might exist that offer the same functionality. colorjs.io looks promising.
Related issue: https://github.com/grubersjoe/react-activity-calendar/issues/34

Turns out CSS is capable of mixing colors in various color spaces natively now :). Currently working on a branch to remove the JS dependency for that completely.

Implemented in https://github.com/grubersjoe/react-activity-calendar/commit/e1ce0795f18cab31912d8c55366243b678bfe8f8


bgp: extract exportPodCIDRReconciler logic into a generic function

This commit extracts most of the exportPodCIDRReconciler logic into a
more generic function, exportAdvertisementsReconciler, so that it can be
reused by other subsystems which only need to advertise a set of IPNets.

/test

/test

/test-1.16-4.19


listen node Problem

I can't get the "listen" node to work, it doesn't receive any events.
This mqtt setup works:
I've a working mqtt Env:
UT0311-L0x.223195309.address = <IP_ADDRESS>:60000
UT0311-L0x.223195309.door.1 = Front Door
UT0311-L0x.223195309.door.2 = Side Door
the listener is set to <IP_ADDRESS>:60001
When I open the door, I get an event.
Node red setup:
it runs on the same "machine"/docker.
the listener is set to <IP_ADDRESS>:60002
I choose another port, so that there is no port collision. I also tried it with 60001.
When I open the door, I dont receive an event via the listen node.
I looked at your example. All the other "api" node like get-listener, set-listener work, get-status...
i.e i did set the listener via node.
my door config:

Do a have an error in the config?
I dont get an "error" trace in the debug console, like "cannot bind adress". The listen node also doesnt show an "red error" below the node.
Can I provide some debug output somehow (the controller config is set to debug)?
thxs alot for your help!!!

Hi,
If I've understood it correctly:

223195309 is your real controller
uhppoted-mqtt is running on a Docker instance, listening for events on port 60001
node-red is running on the same Docker instance as uhppoted-mqtt, listening for events on port 60002

Is that correct?
The first step in debugging this is to confirm that the events are getting sent to where you expect them:

Can you confirm (using Wireshark or tcpdump or the uhppote-cli listen command) that you are receiving events on port 60002 on the machine that is hosting the Docker instance ? (if you're using uhppote-cli you'll have to do it without the Docker instance running)
Can you confirm (using Wireshark or tcpdump or the uhppote-cli listen command) that you are receiving events on port 60002 on the Docker instance ?

Hi,
Quick addendum - if you are running NodeRED in a Docker container, have you forwarded UDP port 60002?
docker run -it -p 1880:1880 -p 60002:60002/udp --name uhppoted nodered/node-red

You may also need to set your listen address to:
<IP_ADDRESS>:60002

which is the simplest way of making sure the container is listen service is bound to the internal container network address.

Nodered runs in host network mode, but I tried adding the ports:
-p 60002:60002/udp
Also tried to add tcp too...
--> no difference
I changed the listen address to:
<IP_ADDRESS>:60002
--> no difference
Tcpdump:
tcpdump -i any -nn | grep <IP_ADDRESS>
Controller ip is: <IP_ADDRESS>
Docker machine ip: <IP_ADDRESS>
Listener Port: 60002
outside docker on the host machine:
16:49:20.931568 IP <IP_ADDRESS>.60000 > <IP_ADDRESS>.60002: UDP, length 64
Inside the docker container:
17:59:00.330065 IP <IP_ADDRESS>.60000 > <IP_ADDRESS>.60002: UDP, length 64
For me the traces look ok still, the "listen" node doesnt output anything. :(
I did setup a nodered instance on my local machine, not within docker. same I dont get any events :(

Hmm ... there may be a problem with Docker receiving UDP multicast packets in host networking mode (https://groups.google.com/g/node-red/c/g5ZSzr7iNI8) but I'm going to have to dig into it to figure if that's actually the case.
Unfortunately host networking mode doesn't work on a Mac and I don't have a RaspberryPi to hand so it's going to take a little time to get set up. Some things to try while I do that:

Try a "normal" container with bridged networking (this worked out of the box for me):

docker run -it -p 1880:1880 -p 60001:60001/udp --name uhppoted nodered/node-red

Try uhppote-cli --debug listen

Can you also please post your Dockerfile and the command you use to run it.

Ok I simplified my setup, to remove any error regarding docker.
I created a local node-red installation on my mac (<IP_ADDRESS>).

uhppote-cli --debug listen
Works, I get the events.

Add the listen node and configured it

quit uhppote-cli
--> No events received, I get no message from the listen node.
I used this configuration on my mac:

I honestly don't know whats wrong.

Have to admit I'm fairly baffled as well - there are definitely networking complexities around docker, IPv4/IPv6 and the more recent Linux releases and I'm still digging into those.
But .. I was able to get node-red receiving events from my local development controller on a remote (vultr) Ubuntu 20.10 VPS  without doing anything at all special.  These were the steps I followed:

Configure firewall and startup scripts so allow TCP port 1880 and UDP port 60001 from my development system public IP
Start Ubuntu 20.10 instance
Login via ssh
apt-get update
apt-get install npm
npm install -g --unsafe-perm node-red
 node-red
Open the VPS node-red page in a browser
Install node-red-contrib-uhppoted to the palette
Create a flow with a listen node connected to debug node (with the listen address configured as <IP_ADDRESS>:60001)

On my development system:

./bin/uhppote-cli --debug set-listener <serial#> <VPS address>:60001
Swipe card

The swipe event appears in the debug pane of the node-red page. You could try this just to establish a baseline working system as starting point for further debugging - or if you can let me have your public IP address am happy to temporarily set up a system that you can access.
One other thing:
uhppote-cli is the original application and I remember struggling to get it to work correctly with both WiFi and LAN enabled on my Mac, as a result of which it has a somewhat more complex default address detection algorithm i.e. there's a possibility uhppote-cli --debug listen may not be binding to <IP_ADDRESS>.
Some more things to try:

uhppote-cli --debug listen and use netstat or lsof to see what address:port it is bound to
uhppote-cli --listen <IP_ADDRESS>:60001 --debug listen, to explicity bind to the same listen address:port as node-red
Disable WiFi entirely and see if that allows node-red to receive events

Hi,
Having experimented some more with a Ubuntu 20.10 VPS I'm able to receive events using NodeRED in a docker container in both host networking mode and normal networking mode without doing anything special.
The only setting that seemed critical was that listen address in the the config node, which must be set to <IP_ADDRESS>:60001.
The command lines used to start NodeRED in a docker container were:

interactive, host network mode:

docker run --interactive --net=host nodered/node-red

detached, host network mode:

docker run --detach --net=host nodered/node-red

interactive, docker proxy (normal):

docker run --interactive --publish 1880:1880 --publish 60001:60001/udp nodered/node-red

detached, docker proxy (normal):

docker run --detach --publish 1880:1880 --publish 60001:60001/udp nodered/node-red

Almost forgot - if you're expecting to receive door relay and push button events, then please be aware of Door open or closed event not generated.
The CLI has an update that allows you to enable door and push button event recording.

Hi,
I'm going to close this issue - NodeRED flows on Ubuntu (both in and outside of Docker containers) were able to receive events without a problem in all configurations I tried. The only critical points to note were:

The firewall should be configured to allow UDP events on the listen port e.g.:
ufw allow from <address> to any port 60000 proto udp

door open, door close  and door button events are only generated if enabled via record-special-events. Support for this function has been added in v0.6.7.

The listen address in the config should be '<IP_ADDRESS>:'

Please feel free to reopen if/when you have any more information to add.

Hi,
I'm going to close this issue - NodeRED flows on Ubuntu (both in and outside of Docker containers) were able to receive events without a problem in all configurations I tried. The only critical points to note were:

The firewall should be configured to allow UDP events on the listen port e.g.:
ufw allow from <address> to any port 60000 proto udp

door open, door close  and door button events are only generated if enabled via record-special-events. Support for this function has been added in v0.6.7.

The listen address in the config should be '<IP_ADDRESS>:'

Please feel free to reopen if/when you have any more information to add.

I'll try 0.6.7 again.
Yes sure, I've tried all variants you described but was not able to listen to message from the controller.
Thanks alot for your help and your great work! :)

I'll try 0.6.7 again.
Yes sure, I've tried all variants you described but was not able to listen to message from the controller.
Thanks alot for your help and your great work! :)

Hmm, I don't think 0.6.7 will make any difference - it only really adds the record-special-events node.
I'm really puzzled because this 'just works' for me - can you maybe upload some Wireshark captures? Maybe I can figure out something from the actual messages..

Hmm, I don't think 0.6.7 will make any difference - it only really adds the record-special-events node.
I'm really puzzled because this 'just works' for me - can you maybe upload some Wireshark captures? Maybe I can figure out something from the actual messages..

I traced it on my mac not in docker.
Mac ip: <IP_ADDRESS>
Controller id: <IP_ADDRESS>
Capture filter applied:
ip.src == <IP_ADDRESS>
I opened the web interface on my mac and opened the door --> thats the tcp, http pakets
Then the controller sends a udp message to the Mac.
Trace:
trace.pcapng.zip
Configuration:

I traced it on my mac not in docker.
Mac ip: <IP_ADDRESS>
Controller id: <IP_ADDRESS>
Capture filter applied:
ip.src == <IP_ADDRESS>
I opened the web interface on my mac and opened the door --> thats the tcp, http pakets
Then the controller sends a udp message to the Mac.
Trace:
trace.pcapng.zip
Configuration:

Thanks! That made it easy - the message bytes are:
   0000   19 20 00 00 ad b0 4d 0d 35 03 00 00 02 01 01 01
   0010   8e 01 a8 c0 20 21 01 04 11 07 08 2c 01 01 00 00
   0020   00 00 00 00 00 11 07 08 00 00 00 00 00 00 00 00
   0030   00 01 00 21 01 04 00 00 00 00 00 00 00 00 00 00

Normally messages start with a 0x17 and that's what the NodeRED codec expects. However, I have seen this before on an older controller and there is a patch for it in the Go code:
// PATCH: accommodates undocumented but seemingly valid 'listen' events that start with 0x19
if (bytes[0] != 0x17) && (bytes[0] != 0x19 || bytes[1] != 0x20) {
    return errors.New(fmt.Sprintf("Invalid start of message - expected 0x17, received 0x%02x", bytes[0]))
}

Which I had forgotten about and missed when doing the port to NodeRED :-(. Apologies .. I should have a fix out in the next day or so.
Out of curiosity - what version is the firmware on your controller?

Thanks! That made it easy - the message bytes are:
   0000   19 20 00 00 ad b0 4d 0d 35 03 00 00 02 01 01 01
   0010   8e 01 a8 c0 20 21 01 04 11 07 08 2c 01 01 00 00
   0020   00 00 00 00 00 11 07 08 00 00 00 00 00 00 00 00
   0030   00 01 00 21 01 04 00 00 00 00 00 00 00 00 00 00

Normally messages start with a 0x17 and that's what the NodeRED codec expects. However, I have seen this before on an older controller and there is a patch for it in the Go code:
// PATCH: accommodates undocumented but seemingly valid 'listen' events that start with 0x19
if (bytes[0] != 0x17) && (bytes[0] != 0x19 || bytes[1] != 0x20) {
    return errors.New(fmt.Sprintf("Invalid start of message - expected 0x17, received 0x%02x", bytes[0]))
}

Which I had forgotten about and missed when doing the port to NodeRED :-(. Apologies .. I should have a fix out in the next day or so.
Out of curiosity - what version is the firmware on your controller?

Oh that is great 😊  thank you!
I don't see a "firmware version" but a "driver version" in the web interface, that is: V6.62.51215

Oh that is great 😊  thank you!
I don't see a "firmware version" but a "driver version" in the web interface, that is: V6.62.51215

Yup, v6.62 was the firmware version on the controller that patch was made for - suspect it was something that got overlooked when they were updating the protocol because it was fixed in later versions.
I'll make a note of it in the README.

Yup, v6.62 was the firmware version on the controller that patch was made for - suspect it was something that got overlooked when they were updating the protocol because it was fixed in later versions.
I'll make a note of it in the README.

Hi,
I've pushed and update to the node-red-contrib-uhppoted repo to handle the v6.62 events and also updated the implementation in uhppote-core and uhppote-simulator.
I'm going to hold off on releasing it for a couple of days though, in the hope that NodeRED will release an update for a security issue in one of their dependencies.
If you want to try out the fix, please use the version in the master branch - otherwise I'll publish a new version early next week.

Hi,
I've pushed and update to the node-red-contrib-uhppoted repo to handle the v6.62 events and also updated the implementation in uhppote-core and uhppote-simulator.
I'm going to hold off on releasing it for a couple of days though, in the hope that NodeRED will release an update for a security issue in one of their dependencies.
If you want to try out the fix, please use the version in the master branch - otherwise I'll publish a new version early next week.

Sure just take your time, I'll wait for the deployment.

Sure just take your time, I'll wait for the deployment.

Hi,
I've release v0.6.8 with the fix for the listen events and published it to NPM and NodeRED.
Can you give it a try and see if you now receive events?

Hi,
I've release v0.6.8 with the fix for the listen events and published it to NPM and NodeRED.
Can you give it a try and see if you now receive events?

@uhppoted
Yes it works :heart:
This is really cool, the node red integration is so clean and nicely done :)
Thanks alot.

@uhppoted
Yes it works :heart:
This is really cool, the node red integration is so clean and nicely done :)
Thanks alot.

Oh, that's great! Thanks for trying it out .. and thanks for your patience while we got to the bottom of the problem!
Am very glad you're finding the node red integration straightforward - I feel like it just opens up a world of possibilities :-).

Oh, that's great! Thanks for trying it out .. and thanks for your patience while we got to the bottom of the problem!
Am very glad you're finding the node red integration straightforward - I feel like it just opens up a world of possibilities :-).


Redirect all non-vpn traffic on port 8132 of istio ingress gateway to https port.

How to categorize this PR?

/area networking
/area security
/kind enhancement
What this PR does / why we need it:
Redirect all non-vpn traffic on port 8132 of istio ingress gateway to https port.
Previously, port 8132 of the istio ingress gateway acted as an ordinary http server answering queries for all resources with 404 resource not found. To make probing more expensive and less convenient for potential attackers, this change now redirects requests to the https port. The effect is that potential attackers need to invest more cpu (for TLS) and do not get a proper response unless they set a correct SNI header.
Which issue(s) this PR fixes:
None.
Special notes for your reviewer:
/cc @DockToFuture @axel7born
Release note:

Port 8132 of istio ingress gateway will respond to all ordinary http requests with a redirect (301) to the https port

/approve


Vagrant Up DC keeps automatically destroying itself after installing VCredist and running cleanup tasks for reload

Operating System Version: Windows 10
Deploying via (VirtualBox/VMWare/AWS/Azure/ESXi): Vbox
Vagrant Version (if applicable): 2.3.2

Using latest branch (10/22/22)
Description of the issue:
While running Vagrant Up DC to build DC VM, it will take it upon itself to self destruct.
In the log below I have provided a bit of excess as context before the issue actually occurs so it is apparent when exactly it happens in the initial process. Please let me know if the excess is necessary or not. Additionally I have included errors after.
dc: Installation of Invoke-AtomicRedTeam is complete. You can now use the Invoke-AtomicTest function
    dc: See Wiki at https://github.com/redcanaryco/invoke-atomicredteam/wiki for complete details
    dc: [19:29] Updating Profile.ps1 to import the Invoke-AtomicRedTeam module...
    dc:
    dc: PSPath            : Microsoft.PowerShell.Core\FileSystem::C:\Tools\PurpleSharp
    dc: PSParentPath      : Microsoft.PowerShell.Core\FileSystem::C:\Tools
    dc: PSChildName       : PurpleSharp
    dc: PSDrive           : C
    dc: PSProvider        : Microsoft.PowerShell.Core\FileSystem
    dc: PSIsContainer     : True
    dc: Name              : PurpleSharp
    dc: FullName          : C:\Tools\PurpleSharp
    dc: Parent            : Tools
    dc: Exists            : True
    dc: Root              : C:\
    dc: Extension         :
    dc: CreationTime      : 10/27/2022 7:29:28 PM
    dc: CreationTimeUtc   : 10/27/2022 7:29:28 PM
    dc: LastAccessTime    : 10/27/2022 7:29:28 PM
    dc: LastAccessTimeUtc : 10/27/2022 7:29:28 PM
    dc: LastWriteTime     : 10/27/2022 7:29:28 PM
    dc: LastWriteTimeUtc  : 10/27/2022 7:29:28 PM
    dc: Attributes        : Directory
    dc: Mode              : d-----
    dc: BaseName          : PurpleSharp
    dc: Target            : {}
    dc: LinkType          :
    dc:
    dc: [19:29] Determining latest release of Purplesharp...
    dc: [19:29] Red Team tooling installation complete!
    dc:
    dc:
==> dc: Running provisioner: shell...
    dc: Running: scripts/install-choco-extras.ps1 as C:\tmp\vagrant-shell.ps1
    dc: [19:29] Installing additional Choco packages...
    dc: [19:29] Chocolatey is already installed.
    dc: [19:29] Installing Chocolatey extras...
    dc: Installing the following packages:
    dc: wireshark;winpcap
    dc: By installing, you accept licenses for the packages.
    dc:
    dc: chocolatey-windowsupdate.extension v1.0.5 [Approved]
    dc: chocolatey-windowsupdate.extension package files install completed. Performing other installation steps.
    dc:  Installed/updated chocolatey-windowsupdate extensions.
    dc:  The install of chocolatey-windowsupdate.extension was successful.
    dc:   Software installed to 'C:\ProgramData\chocolatey\extensions\chocolatey-windowsupdate'
    dc:
    dc: KB3035131 v1.0.3 [Approved]
    dc: kb3035131 package files install completed. Performing other installation steps.
    dc: Skipping installation because update KB3035131 does not apply to this operating system (Microsoft Windows Server 2016 Standard Evaluation).
    dc:  The install of kb3035131 was successful.
    dc:   Software install location not explicitly set, it could be in package or
    dc:   default install location of installer.
    dc:
    dc: KB3033929 v1.0.5 [Approved]
    dc: kb3033929 package files install completed. Performing other installation steps.
    dc: Skipping installation because update KB3033929 does not apply to this operating system (Microsoft Windows Server 2016 Standard Evaluation).
    dc:  The install of kb3033929 was successful.
    dc:   Software install location not explicitly set, it could be in package or
    dc:   default install location of installer.
    dc:
    dc: KB2919442 v1.0.20160915 [Approved]
    dc: kb2919442 package files install completed. Performing other installation steps.
    dc: Skipping installation because this hotfix only applies to Windows 8.1 and Windows Server 2012 R2.
    dc:  The install of kb2919442 was successful.
    dc:   Software install location not explicitly set, it could be in package or
    dc:   default install location of installer.
    dc:
    dc: KB2919355 v1.0.20160915 [Approved]
    dc: kb2919355 package files install completed. Performing other installation steps.
    dc: Skipping installation because this hotfix only applies to Windows 8.1 and Windows Server 2012 R2.
    dc:  The install of kb2919355 was successful.
    dc:   Software install location not explicitly set, it could be in package or
    dc:   default install location of installer.
    dc:
    dc: KB2999226 v1.0.20181019 [Approved] - Possibly broken
    dc: kb2999226 package files install completed. Performing other installation steps.
    dc: Skipping installation because update KB2999226 does not apply to this operating system (Microsoft Windows Server 2016 Standard Evaluation).
    dc:  The install of kb2999226 was successful.
    dc:   Software install location not explicitly set, it could be in package or
    dc:   default install location of installer.
    dc:
    dc: vcredist140 v14.32.31332 [Approved]
    dc: vcredist140 package files install completed. Performing other installation steps.
    dc: Downloading vcredist140-x86
    dc:   from 'https://download.visualstudio.microsoft.com/download/pr/ed95ef9e-da02-4735-9064-bd1f7f69b6ed/CF92A10C62FFAB83B4A2168F5F9A05E5588023890B5C0CC7BA89ED71DA527B0F/VC_redist.x86.exe'
    dc:
    dc: Download of VC_redist.x86.exe (13.09 MB) completed.
    dc: Hashes match.
    dc: Installing vcredist140-x86...
    dc: vcredist140-x86 has been installed.
    dc: Downloading vcredist140-x64 64 bit
    dc:   from 'https://download.visualstudio.microsoft.com/download/pr/ed95ef9e-da02-4735-9064-bd1f7f69b6ed/CE6593A1520591E7DEA2B93FD03116E3FC3B3821A0525322B0A430FAA6B3C0B4/VC_redist.x64.exe'
    dc:
    dc: Download of VC_redist.x64.exe (24.07 MB) completed.
    dc: Hashes match.
    dc: Installing vcredist140-x64...
==> dc: Running cleanup tasks for 'reload' provisioner...
==> dc: Destroying VM and associated drives...
Traceback (most recent call last):
        141: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/logging-2.3.1/lib/logging/diagnostic_context.rb:474:in `block in create_with_logging_context'
        140: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/batch_action.rb:86:in `block (2 levels) in run'
        139: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/machine.rb:203:in `action'
        138: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/machine.rb:203:in `call'
        137: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/environment.rb:631:in `lock'
        136: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/machine.rb:217:in `block in action'
        135: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/machine.rb:248:in `action_raw'
        134: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/runner.rb:101:in `run'
        133: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/util/busy.rb:19:in `busy'
        132: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/runner.rb:101:in `block in run'
        131: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/builder.rb:180:in `call'
        130: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
        129: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/plugins/providers/virtualbox/action/check_virtualbox.rb:26:in `call'
        128: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
        127: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/builtin/call.rb:53:in `call'
        126: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/runner.rb:101:in `run'
        125: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/util/busy.rb:19:in `busy'
        124: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/runner.rb:101:in `block in run'
        123: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/builder.rb:180:in `call'
        122: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
        121: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
        120: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
        119: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/builtin/handle_box.rb:56:in `call'
        118: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
        117: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
        116: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
        115: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
        114: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
        113: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/builtin/call.rb:53:in `call'
        112: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/runner.rb:101:in `run'
        111: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/util/busy.rb:19:in `busy'
        110: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/runner.rb:101:in `block in run'
        109: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/builder.rb:180:in `call'
        108: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
        107: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
        106: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
        105: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/plugins/providers/virtualbox/action/check_accessible.rb:18:in `call'
        104: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
        103: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/plugins/providers/virtualbox/action/customize.rb:40:in `call'
        102: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
        101: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/builtin/prepare_clone.rb:15:in `call'
        100: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
         99: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/plugins/providers/virtualbox/action/prepare_clone_snapshot.rb:17:in `call'
         98: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
         97: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/plugins/providers/virtualbox/action/import.rb:13:in `call'
         96: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/plugins/providers/virtualbox/action/import.rb:78:in `import'
         95: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
         94: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/plugins/providers/virtualbox/action/discard_state.rb:15:in `call'
         93: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
         92: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/plugins/providers/virtualbox/action/match_mac_address.rb:22:in `call'
         91: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
         90: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
         89: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
         88: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/builtin/env_set.rb:19:in `call'
         87: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
         86: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/plugins/providers/virtualbox/action/check_virtualbox.rb:26:in `call'
         85: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
         84: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
         83: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
         82: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/builtin/box_check_outdated.rb:93:in `call'
         81: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
         80: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/builtin/call.rb:53:in `call'
         79: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/runner.rb:101:in `run'
         78: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/util/busy.rb:19:in `busy'
         77: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/runner.rb:101:in `block in run'
         76: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/builder.rb:180:in `call'
         75: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
         74: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
         73: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
         72: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/builtin/call.rb:53:in `call'
         71: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/runner.rb:101:in `run'
         70: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/util/busy.rb:19:in `busy'
         69: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/runner.rb:101:in `block in run'
         68: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/builder.rb:180:in `call'
         67: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
         66: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
         65: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
         64: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/builtin/call.rb:53:in `call'
         63: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/runner.rb:101:in `run'
         62: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/util/busy.rb:19:in `busy'
         61: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/runner.rb:101:in `block in run'
         60: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/builder.rb:180:in `call'
         59: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
         58: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
         57: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
         56: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/plugins/providers/virtualbox/action/check_accessible.rb:18:in `call'
         55: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
         54: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/plugins/providers/virtualbox/action/clean_machine_folder.rb:26:in `call'
         53: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
         52: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/plugins/providers/virtualbox/action/set_name.rb:50:in `call'
         51: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
         50: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/plugins/providers/virtualbox/action/clear_forwarded_ports.rb:15:in `call'
         49: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
         48: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/builtin/provision.rb:103:in `call'
         47: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/builtin/provision.rb:103:in `each'
         46: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/builtin/provision.rb:126:in `block in call'
         45: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/builtin/provision.rb:126:in `call'
         44: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/environment.rb:543:in `hook'
         43: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/runner.rb:101:in `run'
         42: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/util/busy.rb:19:in `busy'
         41: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/runner.rb:101:in `block in run'
         40: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/builder.rb:180:in `call'
         39: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:48:in `call'
         38: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
         37: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/warden.rb:127:in `call'
         36: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/lib/vagrant/action/builtin/provision.rb:138:in `run_provisioner'
         35: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/plugins/provisioners/shell/provisioner.rb:32:in `provision'
         34: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/plugins/provisioners/shell/provisioner.rb:212:in `provision_winrm'
         33: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/plugins/provisioners/shell/provisioner.rb:357:in `with_script_file'
         32: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/plugins/provisioners/shell/provisioner.rb:213:in `block in provision_winrm'
         31: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/plugins/provisioners/shell/provisioner.rb:213:in `tap'
         30: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/plugins/provisioners/shell/provisioner.rb:265:in `block (2 levels) in provision_winrm'
         29: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/plugins/communicators/winrm/communicator.rb:152:in `execute'
         28: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/plugins/communicators/winrm/shell.rb:62:in `powershell'
         27: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/winrm-2.3.6/lib/winrm/connection.rb:42:in `shell'
         26: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/plugins/communicators/winrm/shell.rb:63:in `block in powershell'
         25: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/plugins/communicators/winrm/shell.rb:138:in `execute_with_rescue'
         24: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/vagrant-2.3.2/plugins/communicators/winrm/shell.rb:144:in `handle_output'
         23: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/winrm-2.3.6/lib/winrm/shells/base.rb:79:in `run'
         22: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/winrm-2.3.6/lib/winrm/shells/base.rb:131:in `with_command_shell'
         21: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/winrm-2.3.6/lib/winrm/shells/base.rb:80:in `block in run'
         20: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/winrm-2.3.6/lib/winrm/psrp/receive_response_reader.rb:58:in `read_output'
         19: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/winrm-2.3.6/lib/winrm/wsmv/receive_response_reader.rb:73:in `with_output'
         18: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/winrm-2.3.6/lib/winrm/psrp/receive_response_reader.rb:59:in `block in read_output'
         17: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/winrm-2.3.6/lib/winrm/psrp/receive_response_reader.rb:39:in `read_message'
         16: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/winrm-2.3.6/lib/winrm/wsmv/receive_response_reader.rb:61:in `read_response'
         15: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/winrm-2.3.6/lib/winrm/wsmv/receive_response_reader.rb:93:in `send_get_output_message'
         14: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/winrm-2.3.6/lib/winrm/http/transport.rb:48:in `send_request'
         13: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/httpclient-2.8.3/lib/httpclient.rb:765:in `post'
         12: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/httpclient-2.8.3/lib/httpclient.rb:856:in `request'
         11: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/httpclient-2.8.3/lib/httpclient.rb:1014:in `do_request'
         10: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/httpclient-2.8.3/lib/httpclient.rb:1133:in `protect_keep_alive_disconnected'
          9: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/httpclient-2.8.3/lib/httpclient.rb:1019:in `block in do_request'
          8: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/httpclient-2.8.3/lib/httpclient.rb:1245:in `do_get_block'
          7: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/httpclient-2.8.3/lib/httpclient.rb:1299:in `do_get_header'
          6: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/httpclient-2.8.3/lib/httpclient/session.rb:561:in `get_header'
          5: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/httpclient-2.8.3/lib/httpclient/session.rb:784:in `read_header'
          4: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/httpclient-2.8.3/lib/httpclient/session.rb:801:in `parse_header'
          3: from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.7.0/timeout.rb:105:in `timeout'
          2: from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.7.0/timeout.rb:95:in `block in timeout'
          1: from C:/HashiCorp/Vagrant/embedded/gems/2.3.2/gems/httpclient-2.8.3/lib/httpclient/session.rb:805:in `block in parse_header'

Link to Gist for full errors:
Gist

Hello, I am having this exact problem trying to provision on virtualbox

Hello, I am having this exact problem trying to provision on virtualbox

Hi. I still do not know exactly what causes this issue but I seem to have been able to make it past. By chance were you installing DetectionLab to a different drive than C: ?
If so then what I did was uninstall Vagrant and Virtualbox and reinstall them to E: (the drive I'm putting DL on.) rather than installing them on C: . I'm guessing they may all have to share the same drive. Not completely sure but this is what stopped this error for me so I hope it helps. I will leave this open though just in case it doesn't work for you and other people who may run across this issue so someone can maybe provide another fix.

Hello, I am having this exact problem trying to provision on virtualbox

Hi. I still do not know exactly what causes this issue but I seem to have been able to make it past. By chance were you installing DetectionLab to a different drive than C: ?
If so then what I did was uninstall Vagrant and Virtualbox and reinstall them to E: (the drive I'm putting DL on.) rather than installing them on C: . I'm guessing they may all have to share the same drive. Not completely sure but this is what stopped this error for me so I hope it helps. I will leave this open though just in case it doesn't work for you and other people who may run across this issue so someone can maybe provide another fix.

That help the solution by tsunamifi

I am having the same issue


migration issue

I just did a fresh install on the new VM config.... and I got:
"SQLSTATE[42S22]: Column not found: 1054 Unknown column 'imageUrl' in 'field list'"
I don't see a migration for the profile image stuff

Which page did you see it on? We added an imageUrl field that is generated from a github URL so we don't store it, so obviously we don't want to store it in the DB.


chore: update issue template

Checklist

[x] npm test passes
[x] tests and/or benchmarks are included
[x] commit message follows commit guidelines

Description of change

Use new issue template from https://antv-issue-helper.surge.sh

Merged into master branch in #1486.


[WTD] Azure App Supportability Inclusion Articles

In support of #31413, here is a list of articles with line numbers of where non gender neutral language is present.

[ ]   create-manage-support-requests-using-access-control.md Line   #64
[ ]   create-manage-support-requests-using-access-control.md Line   #84
[ ]   create-manage-support-requests-using-access-control.md Line   #101
[ ]   create-manage-support-requests-using-access-control.md Line   #105

Working on this.

PR for all items complete.


Fix validator tests

I ended up having to rework the internal machinery due, in part, to the existing implementation relying on the fact that it always wrapped the method with @classmethod internally and thus had a new object to monkey patch onto every time it was called.
The new implementation returns an explicit descriptor object instead of monkey patching classmethod. I feel that this also had the advantage of cleaning up the implementation a bit, making it more strongly typed and easier to follow, but that may be just my personal bias.


Linting For OpenAPI

Motivation
Add example for the job that validates API for correctness
Context
http://api.appservices.tech/ defines OpenAPI standards that your team can follow to build Managed Services Control Plane APIs. We use spectral ruleset to check those rules. We will add validation into github actions once we get initial API validated and onboarded into sdk.
Example of objects and OpenAPI annotations to use to meet standards
This API meets all our standards
https://github.com/bf2fc6cc711aee1a0c2a/kafka-admin-api/pull/200
Some of the changes that were made can be copy pasted to your project etc.
Another good example of the Java/Quarkus project that follows the standard would be SRS fleet manager:
https://github.com/bf2fc6cc711aee1a0c2a/srs-fleet-manager/blob/main/core/src/main/resources/srs-fleet-manager.json#L546-L583
How I can run this locally
http://api.appservices.tech/spectral/

@r00ta Example of annotations that can be used from the PR mentioned above:
https://github.com/MikeEdgar/kafka-admin-api/blob/2e4b258e222d9bd54971dad0e3afca00062910df/kafka-admin/src/main/java/org/bf2/admin/kafka/admin/handlers/OperationsHandler.java#L34-L104
We need proper operationId, responseTypes and handling defined.
In current form openapi file is not usable (it does require series of manual updates to pass standard openapi validation)
Let me know if we can help more on this. It would be matter of adding more annotations or changing existing ones

Thank you @wtrocki for your contribution


Add withSyncano HOC

Codecov Report

Merging #218 into master will increase coverage by 6.44%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master     #218      +/-   ##
==========================================
+ Coverage   28.15%   34.59%   +6.44%
==========================================
  Files         103      120      +17
  Lines        2863     4714    +1851
==========================================
+ Hits          806     1631     +825
- Misses       2057     3083    +1026


Update version to 1.608.0

Missing in the DirectX-Headers-1.608.0 tag/release.

@microsoft-github-policy-service agree [company="{your company}"]

@microsoft-github-policy-service agree [company="default"]

@microsoft-github-policy-service agree

The latest release 1.608.2 now has a correctly updated/matching version again, closing this PR.


Document the use of allow.http flag in ingress

When certificate reference is present in ingress resource, we automatically configure http and https port on corresponding rancher LB. There is a way to disable http port by explicitly setting:
allow.http=false

in ingress annotations. We should document this fact.
https://github.com/rancher/rancher/issues/4968

Already added in 1.6 doc


support rendering of errors if a file is only partially encoded in UTF-8

I want to support the use case that a file contains both utf-8 encoded commands and binary data, such that if an error occures, it is only important that the text selected via labels is valid utf-8, but doesn't require that the whole file is utf-8. As line numbers and such don't make much sense in that scenario, it would be good to print the raw byte positions instead of line numbers. An optional interaction with the bstr crate (the bstr::BStr struct has a nice Debug implementation) might be useful. If the text selected via labels contains invalid utf-8, it should be printed as hex or something similiar, at least, it shouldn't fail.

 Might be easier for me to visualise that way.

I think there are multiple possibilities:

(a) only support printing if the snippet does only contain utf-8 (probably easier, but less useful)
(b) escape non-utf8 characters (more difficult, because the calculation of arrows and such gets more difficult)

I currently don't really know how the output should look like, but it should at least provide the following informations:

file name
line number / column if applicable (e.g. no non-utf8 stuff before the labels)
raw byte position / span (always if the given slice contains non-UTF8 data)
error messages
the corresponding snippet including arrows/label pointers...


IPVLAN Static IP Allocation Not Working

Hi,
Please I am trying to assign static IP to a pod with ipvlan plugin.
My network attachment definition:
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: ipvlan-multus-static-without-addresses
spec:
  config: '{
      "cniVersion": "0.3.1",
      "type": "ipvlan",
      "master": "eth1",
      "mode": "l3",
      "ipam": {
        "type": "static"
      }
    }'

POD:
apiVersion: v1
kind: Pod
metadata:
  name: test-4
  annotations:
          k8s.v1.cni.cncf.io/networks: '[ { "name": "ipvlan-multus-static-without-addresses",
                                             "interface": "net1",
                                              "ips: "<IP_ADDRESS>/24" } ]'
spec:
  containers:
  - name: test
    command: ["/bin/bash", "-c", "trap : TERM INT; sleep infinity & wait"]
    image: praqma/network-multitool

Output of the POD interfaces:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
3: eth0@if23: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc noqueue state UP group default
    link/ether b2:a6:fa:97:1b:3d brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet <IP_ADDRESS>/32 scope global eth0
       valid_lft forever preferred_lft forever

Any idea why the second interface is not been created?

Need 'capability' config in ipvlan as following:
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: ipvlan-multus-static-without-addresses
spec:
  config: '{
      "cniVersion": "0.3.1",
      "type": "ipvlan",
      "capabilities": { "ips": true },
      "master": "eth1",
      "mode": "l3",
      "ipam": {
        "type": "static"
      }
    }'

See https://github.com/containernetworking/cni/blob/master/CONVENTIONS.md#dynamic-plugin-specific-fields-capabilities--runtime-configuration for capability config.

Hi @s1061123 I tried that but it's still not working.
I even tried to add the IP address instead true , it also did not work.

In my environment,  k8s v1.19.4 with multus v3.6, following configuration creates pod with ipvlan, hence it might not be multus issue. I guess that your environment may have some issue (e.g. missing static CNI plugin or ipvlan cannot be created due to missing module).
---
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: centos-runtimeconfig-def
spec:
  config: '{
            "cniVersion": "0.3.1",
            "type": "ipvlan",
            "capabilities": { "ips": true },
            "master": "eth1",
            "mode": "l3",
            "ipam": {
                "type": "static"
            }
        }'
---
apiVersion: v1
kind: Pod
metadata:
  name: centos-runtimeconfig
  annotations:
    k8s.v1.cni.cncf.io/networks: '[
            { "name": "centos-runtimeconfig-def",
              "ips": [ "<IP_ADDRESS>/24" ],
              "mac": "c2:b0:57:49:47:f1" }
    ]'
spec:
  containers:
  - name: centos-runtimeconfig
    image: docker.io/centos/tools:latest
    command:
    - /sbin/init
    securityContext:
      privileged: true

[centos@kube-master1 ~]$ kubectl exec -it centos-runtimeconfig -- ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
3: eth0@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default
    link/ether ca:4e:39:5e:6a:de brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet <IP_ADDRESS>/24 brd <IP_ADDRESS> scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::c84e:39ff:fe5e:6ade/64 scope link
       valid_lft forever preferred_lft forever
4: net1@eth0: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/ether 52:54:00:c0:5a:86 brd ff:ff:ff:ff:ff:ff
    inet <IP_ADDRESS>/24 brd <IP_ADDRESS> scope global net1
       valid_lft forever preferred_lft forever
    inet6 fe80::5254:0:1c0:5a86/64 scope link
       valid_lft forever preferred_lft forever

Thanks for confirming that it works at least. I have checked the worker node and the CNI binaries are present:
[ec2-user@ip-172-32-4-151 ~]$ ls -ltrh /opt/cni/bin/
total 122M
-rwxr-xr-x 1 root root 5.7M May 13  2020 firewall
-rwxr-xr-x 1 root root 3.0M May 13  2020 flannel
-rwxr-xr-x 1 root root 3.3M May 13  2020 sbr
-rwxr-xr-x 1 root root 3.3M May 13  2020 tuning
-rwxr-xr-x 1 root root 4.5M May 13  2020 bridge
-rwxr-xr-x 1 root root 4.0M May 13  2020 host-device
-rwxr-xr-x 1 root root 4.2M May 13  2020 ipvlan
-rwxr-xr-x 1 root root 4.2M May 13  2020 macvlan
-rwxr-xr-x 1 root root 4.4M May 13  2020 ptp
-rwxr-xr-x 1 root root 4.2M May 13  2020 vlan
-rwxr-xr-x 1 root root  12M May 13  2020 dhcp
-rwxr-xr-x 1 root root 2.8M May 13  2020 static
-rwxr-xr-x 1 root root 3.5M May 13  2020 host-local
-rwxr-xr-x 1 root root 3.1M Nov 26 17:04 loopback
-rwxr-xr-x 1 root root 3.8M Nov 26 17:04 portmap
-rwxr-xr-x 1 root root 4.0M Nov 26 17:04 bandwidth
-rwxr-xr-x 1 root root  16K Nov 26 17:04 aws-cni-support.sh
-rwxr-xr-x 1 root root  18M Nov 26 17:04 aws-cni
-rwxr-xr-x 1 root root  35M Dec  2 16:42 multus

Which specific ipvlan plugin might be needed? Also which logs can I check to see where the failure is happening?
N.B - host-local works

                                              "ips: "<IP_ADDRESS>/24" } ]'

should be
                                              "ips:[ "<IP_ADDRESS>/24" ] } ]'


Create Search component

Here is the original one: https://semantic-ui.com/modules/search.html.
Please have a look at contributing.md for instructions on how to contribute and submit a PR.

Do you have any plans to add this component?
If yes, then when do you plan to do it?

I just started creating this component :) I'm new in this project so be patient!


build error

make[3]: Leaving directory /usr/local/pinpoint-c-agent/thirdparty/thrift/compiler/cpp' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory /usr/local/pinpoint-c-agent/thirdparty/thrift/compiler/cpp'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/pinpoint-c-agent/thirdparty/thrift'
make: *** [all] Error 2

It seems thrift installed failed.
You can try Option2. Install from source code.


Update URLs to repos

+5 👍🏻

Thank you 😁

Look at that happy face from Alex 😁

😂 2nd Ark PR to be merged. 1st for desktop! 😁


[Bug] "citrix_scvmm_hypervisor_resource_pool" Unable to Resolve Hosts or Host Groups

Hi,
When attempting to create a citrix_scvmm_hypervisor_resource_pool resource with the Citrix Terraform Provider, the process fails because the specified host or host group cannot be resolved. It seems that the host parameter does not correctly interpret the values provided, even though they match the SCVMM configuration.
Steps to Reproduce:
Terraform configuration:
resource "citrix_scvmm_hypervisor_resource_pool" "main" {
  name       = "VLAN123"
  hypervisor = citrix_scvmm_hypervisor.main.id
  host       = "HOSTGROUP\\mgtphyp07.company.com" # Example value, several formats tested
  networks   = ["VLAN123"]

  storage = [
    {
      storage_name = "Local storage on mgtphyp07.company.com"
      superseded   = false
    }
  ]

  temporary_storage = [
    {
      storage_name = "Local storage on mgtphyp07.company.com"
      superseded   = false
    }
  ]

  use_local_storage_caching = false
}

Tested multiple variants of the host parameter, including:
Hostname only: mgtphyp07
Host FQDN: mgtphyp07.company.com
Host group and host: HOSTGROUP\\mgtphyp07
SCVMM path: All Hosts\\HOSTGROUP\\mgtphyp07.company.com
DaaS internal path: HOSTGROUP.hostgroup/mgtphyp07.host

Error message:
    Error: Error creating Hypervisor Resource Pool for SCVMM

    TransactionId: <ID>
    Failed to resolve resource HOSTGROUP\mgtphyp07, error: could not find resource

Additional Information:
Creating the connection and resource pool manually in Citrix DaaS works without issue.
The DaaS PowerShell and API logs show that hosts are internally referenced using paths like HOSTGROUP.hostgroup/mgtphyp07.host. However, this format is not accepted by the Terraform Provider.
The host is confirmed to exist in SCVMM and works in other configurations.
PowerShell commands confirm correct host, host group, and network names:
Get-SCVMHost | Select Name, ID
Get-SCVMHostGroup | Select Name
Get-SCVMNetwork | Select Name
Example output:
Host: mgtphyp07.company.com
Host group: HOSTGROUP
Network: VLAN123

API log of a successful manual creation in DaaS:
{
  "ConnectionType": "SCVMM",
  "Name": "VMs_APC-VLAN3531",
  "RootPath": "HOSTGROUP.hostgroup/mgtphyp07.host",
  "Networks": ["HOSTGROUP.hostgroup/mgtphyp07.host/VLAN123.network"],
  "UseLocalStorageCaching": false,
  "Storage": ["XDHyp:\\Connections\\HYPERVISOR123\\HOSTGROUP.hostgroup\\mgtphyp07.host\\Local storage on mgtphyp07.company.com.storage"],
  "TemporaryStorage": ["XDHyp:\\Connections\\HYPERVISOR123\\HOSTGROUP.hostgroup\\mgtphyp07.host\\Local storage on mgtphyp07.company.com.storage"]
}

Environment:
Terraform Version: 1.0.8
CitrixIssueId: 59626

@xinghengl-citrix  @AlanCitrix
Could you please check and let us know if we need any logs etc information?
Please note that we are using Hyper-V Local Storage

Yes will let you know. You have provided a lot of details in the bug, we will look into this.


Musig2: add new MuSig2 RPC methods to signrpc

Depends on https://github.com/btcsuite/btcd/pull/1820.
Adds a new MuSig2 API for cooperatively producing Schnorr signatures that can be used either for Taproot internal keys or for OP_CHECKSIG signatures within a tap script tree.

@guggero, remember to re-request review from reviewers when ready

What needs to be done to take this out of the draft stage? Merging of the upstream btcd PR?

What needs to be done to take this out of the draft stage? Merging of the upstream btcd PR?

Mostly adding the MuSig2 methods to the signer interface so they can also be forwarded to the remote signer. And cleaning up some user input validation TODOs. So not a big diff, working on it today.

Took the PR out of draft state. Everything works now, including remote signing!
While working on remote signing support for MuSig2 I noticed that the standalone Taproot functionality does not work in remote mode. Turns out we need https://github.com/lightningnetwork/lnd/issues/6268 to enable that.
I'm going to work on that in a separate PR, commented out the failing remote mode itests for now.

@roasbeef: review reminder

I added a convenience RPC called MuSig2CombineKeys to make it possible to just get the combined key and Taproot public key without creating a session.
I also went ahead and added a short doc explaining the current MuSig2 implementation and examples.

I updated to the latest version of https://github.com/btcsuite/btcd/pull/1820 and added an itest for using a MuSig2 combined key in a tap leaf with a simple OP_CHECKSIG script.
I also found a small bug in the helper function TapscriptPartialReveal that is used for the fee calculation. A proof for a tree with just a single leaf can be empty, so the inclusion proof can be variable size.

The btcd PR has been merged, so this can be rebased!

A proof for a tree with just a single leaf can be empty, so the inclusion proof can be variable size.

Yes in this case, the verifier just takes the leaf, computes one level of tapLeaf hashing and uses that directly. You can see this interaction here if you pretend the loop below doesn't actually exist: https://github.com/btcsuite/btcd/blob/master/txscript/taproot.go#L155-L177

The new btcec tag: https://github.com/btcsuite/btcd/releases/tag/btcec%2Fv2.2.0


export plugin data to injection

Run tests with -u flag to update snapshots. Check that the snapshots were changed as expected

Can you do that? It won't run on my machine. I'll need to set it up the wsl...

I've rebased a bit the branch and squashed the commits.
Just add some documentation here and here


Fix patches & line-endings

Using the same procedure as Ray originally, and documented by Isuru (though that README hasn't been merged yet from the 3.10 PR)

Done in https://github.com/conda-forge/python-feedstock/pull/501/commits/63e4dd7bdf519efaf23d77a67b21676755be1667