Implement boulder problem variants

Some boulder problems have variants, but they were not displayed on the topo's bottom sheet. This commit adds a variant selector in the upper right corner of the topo's bottom sheet.
https://github.com/boolder-org/boolder-android/assets/8343416/613e1890-3ffc-4ca8-a7b2-68860aef6dea
The design of the variant menu follows the material design implementation, I just added a rounded background around the variant's grade to make it more visually appealing.
Resolves #20

You rock!

The design of the variant menu follows the material design implementation, I just added a rounded background around the variant's grade to make it more visually appealing.

You're right, the grade can be made more visible.
However the rounded black background make it seem like it belongs to a black circuit => It's a bit confusing in my opinion.
Is there a way to highlight the grade more subtly? For example we could align the grade on the right side (and keep the problem name on the left side).
What do you think?

Also, I just made a tiny improvement to the iPhone app.
I added a chevron to the variants button to make it clear that it can be tapped.
What do you think?

Also, I just made a tiny improvement to the iPhone app.
I added a chevron to the variants button to make it clear that it can be tapped.
What do you think?

Great idea! 👍 I added a down chevron as well 😉

Is there a way to highlight the grade more subtly? For example we could align the grade on the right side (and keep the problem name on the left side).

I updated the alignments of the grades ✅
In order to remove any circuit color association, I propose to remove the background of the grade and just keep an outline, this should be neutral enough. I avoided using the circuit color as a background, because it would be confusing with the problem number. What do you think about it?

All right, I like it!


Search interface quick change: advanced options only upon unfold

The options are "advanced" and rarely used, and make that we need to scroll to see search results. Show these advanced options only upon unfold (clicking on a pseudo-link "Show advanced options" or something similar).

@davidzbiral So everything excluding label should be hidden?

@Ptrhnk Yes.


BG: EXPECTEDSCHEMAVALIDATION

Affected Country: BG
@stamo , @SchulzeStTSI and @daniel-eder - FYI.
Issue Description
Payload does not comply with Schema.
Ref:
BG/2DCode/raw/1.json
BG/2DCode/raw/2.json
>           raise error
E           jsonschema.exceptions.ValidationError: None is not of type 'array'
E
E           Failed validating 'type' in schema['properties']['v']:
E               {'description': 'Vaccination Group',
E                'items': {'description': 'Vaccination Entry',
E                          'properties': {'ci': {'description': 'Certificate '
E                                                               'Identifier, format as '

Proposed Solution
Removing these NULL values should resolve the issue.
    "r": null,
    "t": null,

Thanks a lot we are aware of that, that's why we issued 3 and 4 which are correct. The problem is that we have issued approximately 1000000 certificates in production with these null objects and we are asking everyone to make schema validation a little bit softer, to accept these QR codes

@bhavin-qryptal Sorry for the confusion. There is an exception currently for BG which should ignore nulls for arrays and a different format for DOB. Can you relax the schema f.e. like if(countryCode=="BG") then the type of r is not array, but ["null","array"]. DOB should be as well allowed for T00:00:00. We wait for the final decision tomorrow.

@bhavin-qryptal Let's see how we handle this. I would like to copy the schema into the script(folder) instead of loading it live. Then we can relax it easily. The official schema should not be touched.

@SchulzeStTSI , Are you suggesting to modify the schema before it is used for validation by test script? In that case, wouldn't such code fail validation when real life apps and services try to validate such codes?

@bhavin-qryptal Currently is the discussion about, if the verifier should do a mandatory validation of the schema. The most of the people cite Postal's Law, which means that the issuer should be very strict, but the verifier must be so flexible as possible. Under this assumptions the verifier schema can be relaxed, but the issuer must still following the strict one. Currently we have some apps outside which do a very strict validation, and some which are validate nothing. I think the golden way is somewhere in the middle. Let's see what the todays discussion outcome is.

@SchulzeStTSI ,  Thank you for explanation, it is useful. For now, validation script is marking such tests as XFAIL. Test script could be updated after today's discussion. It MIGHT be a good idea to have two sets of schema, One for issuer and other for validator.

@bhavin-qryptal Let's relax the schema here for the codes. What do you think where should place in the best case the schema copy?

@SchulzeStTSI , Please help me with few basic queries.

Who would author the schema to use for validation?
How would this new set of validation only schema be controlled and how would it remain in sync with schema use for generation?
Likewise https://id.uvci.eu/DGC.schema.json, could we have new set of schema available at some public URL (e.g. https://id.uvci.eu/DGC.validation.schema.json)? Also this new validation schema set should be maintained under GitHub repository.

Looking forward to have your thoughts and comments.

In the future, this should be discussed first. Before we merge such a pull request. Right now all pull requests are merged even if the checks are failing. If the schema should be relaxed, this github checks should be relaxed as well so we don't have problems when other countries create a new pull request.

@vanlooverenkoen Yes you are absolutley right. This was an quick merge, just to highlight the current situation with the productive codes.
@bhavin-qryptal Regarding your questions:

The schema is created within this repo: https://github.com/ehn-dcc-development/ehn-dcc-schema in multiple versions. We should create under "tests" a  folder with the different version 1.0,1.1,1.2 etc and copy them into it. This schemas must be relaxed regarding the array handling for r,t,v (["null","array"]) and the dob(https://github.com/eu-digital-green-certificates/dgca-app-core-android/blob/main/decoder/src/main/java/dgca/verifier/app/decoder/JsonSchema.kt#L54 )
The sync should be manually. All issuers and verifiers use the schema which are currently offically released. But this is for issuing. Verifiers can have a different behaviour (or no validation). This is still under discussion.
We are working on the public URL. Still under discussion. Currently all verifier apps which are doing a validation integrate it hardcoded.

3. We are working on the public URL. Still under discussion. Currently all verifier apps which are doing a validation integrate it hardcoded.

Verifier apps and wallet apps .
Adjustments to the schemas made in the past two weeks and problems with implementations on issuer's side are already causing problems with wallet apps and verifier apps, where (previous) schemas and validation rules are hardcoded, see issue mentioned above @SchulzeStTSI 's reply.
Are developers of wallet and verifier apps are informed pro-actively from your side to take account of changes? Or are they forced to regularly track changes here by themselves?
In this view, does it even make sense that wallet apps and verifier apps already have gone live, when they can't handle all adjustments from the past weeks?
Thank you in advance for your reply.

The sync should be manually. All issuers and verifiers use the schema which are currently offically released. But this is for issuing. Verifiers can have a different behaviour (or no validation). This is still under discussion.

Purpose if the validation script is to ensure that all the codes issues / submitted by member state complies with the standards. Actual validator app could have liberal implementation but the validation script should have stricter checks to ensure good compliance (e.g. schema compliance). Otherwise, we would miss capturing important compatibility issues upfront.

@vanlooverenkoen We announce all changes in our regular meetings. This kind of changes were announced last week, after the report from bulgaria at monday.
@bhavin-qryptal OK agreed. We should keep this repo as it is to ensure more compliance. I will contact stamo and then we move the codes to another repo for "in field" compatibility/versioning checks.  Thank you. I let you know when we have setup it.


Sequence names not being downloaded

After installing #120, I grabbed all of the test_get_oeis_values  sequences from numberscope.colorado.edu/api to make sure positive, zero, and negative offsets were working. I got back correct values fine, but even a half hour later, the sequence names have not been filled in. We chose these sequences to have very little metadata, so they should surely have finished grabbing the metadata. Seems to be a bug, and seems to be relatively new, as most of the sequences in the database do have their names filled in.
There's nothing in the log, either, so apparently no failed requests.
I personally think this should definitely be investigated prior to the start of the Delft team's  work; what do @Vectornaut and @katestange  think?

Strongly agree!

Is it possible the database got messed up previously?  Or are you sure these were new to the database at the time?

I am sure they were just added. You can try it  by picking any sequence not on the following list, especially one with light metadata, then grabbing some values, then waiting 10 minutes, and grabbing a different number of values (to be sure your browser isn't using cached results). If it still says the sequence name has not been loaded, you are seeing the bug in action.
Known IDs:
A000521, A001358, A001378, A000305, A100000, A000040, A006769, A000111, A123456, A000300, A095102, A001000, A005150, A007814, A099802, A070939, A000045, A000290, A005101, A000720, A000041, A000796, A000034, A057716, A000032, A000060, A000124, A000010, A000105, A000079, A000011, A002858, A000030, A074902, A000002, A189227, A290508, A005171, A219956, A045864, A005207, A248930, A000055, A400000, A078302, A321580, A153080, A000000

Yes, this I agree this is high priority.

I can check this out when I start on #69.

OK. If it's not clearly related to #69, let me know, because every other remaining item on the Backscope list is assigned to you: #69 and its satellites #33 and #104; and #118 because you just did the logging. So if you'd like to/need to split up the effort, the one that would seem easiest to shift to me is this one, unless it appears that it is tightly bound to #69.

That's fine for now. Ultimately, we need tests that leave the server running long enough -- maybe for sequences with just a little data, this is just a few seconds -- for them to get all of the background data and verify it's there.


MRU useTabSwitcher prevents switching to tabs in left/right order

Description of the new feature/enhancement
I was excited for the MRU tab switching in 1.5, but it looks like the way it was designed there's no way to make it behave like Visual Studio (and other text editors) and support both MRU switching and next/prev (rather: left/right) switching at the same time.  What I'm attempting:

"ctrl+tab": switch to previous tab in MRU order
"ctrl+shift+tab": switch to next tab in MRU order
"ctrl+pgup": switch to the tab to the left
"ctrl+pgdn": switch to the tab to the right

The current behavior with useTabSwitcher set to "disabled" or "inOrder" is:

"ctrl+shift+tab": switch to tab to the left
"ctrl+tab": switch to tab to the right

With useTabSwitcher set to "MRU" it's:

"ctrl+tab": switch to previous tab in MRU order
"ctrl+shift+tab": switch to next tab in MRU order

And in both cases, the "useTabSwitcher" setting changes the meaning of what the "nextTab" and "prevTab" commands actually do.  This causes two undesirable effects:

To get MRU ordering, you have to enable the tab switcher UI
If you get MRU ordering, that's all you get (you lose the ability to navigate to tabs to the left/right)

Proposed technical implementation details (optional)
To fix, you could expose either four new commands:

"leftTab"
"rightTab"
"mruNextTab"
"mruPrevTab"

...or four new "direction" types to the "switchToTab" action:

{ "command": { "action": "switchToTab", "direction": "left" }, "keys": "ctrl+pgup" },
{ "command": { "action": "switchToTab", "direction": "right" }, "keys": "ctrl+pgdn" },
{ "command": { "action": "switchToTab", "direction": "mruPrev" }, "keys": "ctrl+tab" },
{ "command": { "action": "switchToTab", "direction": "mruNext" }, "keys": "ctrl+shift+tab" },

...which do exactly what they describe, and accomplishes the goal outlined above.  None of these commands should be influenced by the "useTabSwitcher" setting (and the "nextTab/prevTab" commands would continue to be influenced to keep existing behavior).

You know, there was another thread around here where we were discussing the same exact thing, the same exact design, but I've lost it now. This is now the "I want to be able to use both MRU and in-order tab switching on different keys" thread.
Thanks!

Chiming in second this. Glad to see MRU on ctrl+tab finally being available but having my ctrl+pgup and ctrl+pgdn also emit MRU instead of left/right behavior is incredibly confusing.

I'm not sure which ticket to respond to, so I'll stick with this one for now?  Doing this:

{ "action": "nextTab", "tabSwitchOrder": "inOrder/MRU", "useTabSwitcher": true/false },

...doesn't look horrible, but including "useTabSwitcher" in this action definition still feels like combining two things that shouldn't be combined.  I'm guessing this is because the existing "tabSwitcherMode" exists, and you are trying to override it?
Separately, I'd lean towards renaming "tabSwitchOrder" to something like "direction" or "order" instead (it took me a beat to recognize "tabSwitchOrder" had nothing to do with the tab switcher UI).

After some hesitation, as I am not sure when I get to #9390, I decided to use the following format:
{ "command": { "action": "prevTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f1"}
{ "command": { "action": "nextTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f2"}

or
{"command": { "action": "prevTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f1"}
{ "command": { "action": "nextTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f2"}

if you don't want tab switcher to show up.
It is actually aligned with the global setting. If we decide to add MRU mode with no tab switcher, we can simply add the new value to the enum (aka "disabledMRU"), and this will work for both commands and the settings.

tbh this setup feels... bizarre.  But I guess that's the price of backwards
compatibility?  The "if we add MRU support without tab switcher" is also a
slight cause for concern.  Also wondering about the kinda-not-standard key
bindings as well?
On Mon, Mar 15, 2021 at 11:41 AM Don-Vito @.***> wrote:

After some hesitation, as I am not sure when I get to #9390
https://github.com/microsoft/terminal/issues/9390, I decided to use the
following format:
{ "command": { "action": "prevTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f1"}
{ "command": { "action": "nextTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f2"}
or
{"command": { "action": "prevTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f1"}
{ "command": { "action": "nextTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f2"}
if you don't want tab switcher to show up.
It is actually aligned with the global setting. If we decide to add MRU
mode with no tab switcher, we can simply add the new value to the enum (aka
"disabledMRU"), and this will work for both commands and the settings.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/terminal/issues/9330#issuecomment-799659008,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHG6DYI32P5BMQ3ZJICTNLTDZIG5ANCNFSM4YOMBW4Q
.

Also wondering about the kinda-not-standard key bindings as well?

We're not going to be binding this by default - those keys listed are mostly as examples ☺

tbh this setup feels... bizarre. But I guess that's the price of backwards compatibility? The "if we add MRU support without tab switcher" is also a slight cause for concern. Also wondering about the kinda-not-standard key bindings as well?

Yes.. this is a price of backward-compatibility between the settings and the commands parameters. I tried to do what we discussed earlier and it was confusing as hell :blush: I mean in the global settings you would have an enum, and here you will have two flags, and the entire resolution logic (aka what happens if default is TabSwitcherMode=Disabled, and here useTabSwitcher=True) would be very non-intuitive.
With this solution it is relatively simple: if you have enum defined in param - it will be used, default otherwise.
Regarding the samples, as Mike said, we are not going to bind them, I put the ones I was using for testing, as an example.

This doesn't seem to be working in 1.8.1444.0.  See below for repro steps, but it doesn't seem possible to make a config that does this:

"ctrl+pgdn" always goes to the right (with wrapping)
"ctrl+pgup" always goes to the left (with wrapping)
"ctrl+tab" always goes to the previously selected tab in MRU order
"ctrl+shift+tab" always goes to the next selected tab in MRU order

Steps:
Put this in your config:
{
    "useTabSwitcher": true,
    "actions":
    [
        { "command": "nextTab", "tabSwitcherMode": "inOrder", "keys": "ctrl+pgdn" },
        { "command": "prevTab", "tabSwitcherMode": "inOrder", "keys": "ctrl+pgup" },
        { "command": "nextTab", "tabSwitcherMode": "mru", "keys": "ctrl+tab" },
        { "command": "prevTab", "tabSwitcherMode": "mru", "keys": "ctrl+shift+tab" }
    ]
}

Open a terminal
Create a tab and rename it "A"
Create a tab and rename it "B"
Create a tab and rename it "C"
Hit "ctrl+pgdn" but don't release "ctrl"

I'd expect to have switched to the next right-most tab from "C" (which is "A" at this point), but instead it switches to "B"
Looking at the tab switcher list (because "ctrl" is still being held), you can see why: Terminal thinks the tab order is "C", "B", "A" for some reason.

Release "ctrl"
Hit "ctrl+pgup" and don't release "ctrl" again

I'd expect to go to "A" (and you do!), but note the tab switcher order is listed as "B", "C", "A"

Release "ctrl"
Hit "ctrl+pgdn" and before releasing "ctrl", note the tab switcher order is "A", "B", "C"

You should be on tab "B" at this point with no tab switcher.

Hit "ctrl+pgdn" and release "ctrl"

You go to tab "A" instead of "C".  Repeating step 10 makes you bounce back and forth between "A" and "B" forever.
Given how all this is currently implemented it seems like the only way to hit the original request would be to either introduce an "adjacent" or "leftright" mode for "tabSwitcherMode", or to consider the current "inOrder" behavior a bug, and change it.

Huh, you're totally right. No matter what mode is set in the action, it still uses the switcher... even if it's disabled. That's way wrong.

Wait a moment...
We may have fallen prey to legacy command support.
Take two of these ("and call me in the morning"):
        { "command": { "action": "nextTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+pgdn" },
        { "command": { "action": "prevTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+pgup" },

Yep, that was it exactly - I didn't realize legacy command support was a thing even.  Thanks for the catch!


pilot.token should be able to be fetched from a secret

Feature
What did you expect to see?
The pilot.token value should be able to be stored in a secret in k8s. Not everyone is able to hide the entire contents of their helm configuration.

Duplicate of #3853


BROKEN: SWS/S&M: Set all FX (except X) offline for selected tracks

Hey team,
These 8 actions are not currently working. REAPER x64 v6.32+dev0715 and SWS v<IP_ADDRESS> featured build (February 6, 2021).
Cheers,
Dax.

Actually, it looks like all of the SWS actions that set plugins to offline are not working reliably. The REAPER native actions seem to work fine and the SWS FX online actions seem to be okay. Some FX offline actions work after running the native actions.

Hey Christian! Thanks for checking this.
I just checked in 6.40+dev??? and it's working again. Perhaps there was a change that got un-changed? Either way, it's good.
Cheers,
-Dax.


added chess_game

PR Description 📜
Added Chess Game. Chess is a board game for two players. It is a board game played between two opponents on opposite sides of a board containing 64 squares of alternating colors. The goal of the game is to checkmate the opponent's king.
Fixes #2379

Mark the task you have completed ✅

[x] I follow CONTRIBUTING GUIDELINE & CODE OF CONDUCT of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I have followed proper naming convention showed in CONTRIBUTING GUIDELINE
[x] I have added screenshot for website preview in assets/images
[x] I have added entries for my game in main README.md
[x] I have added README.md in my folder
[ ] I have added working video of the game in README.md (optional)
[x] I have specified the respective issue number for which I have requested the new game.

Add your screenshots(Optional) 📸

Thank you soo much for contributing to our repository 💗

Thank you @mahendraDew ,for creating the PR and contributing to our GameZone 💗
Review team will review the PR and will reach out to you soon! 😇
Make sure that you have marked all the tasks that you are done with ✅.
Thank you for your patience! 😀

Thank you  @mahendraDew , for your valuable time and contribution in our GameZone 💗.
It’s our GameZone, so Let’s build this GameZone altogether !!🤝
Hoping to see you soon with another PR again 😇
Wishing you all the best for your journey into Open Source🚀


COCO annotation export is missing the annotations

Describe the bug
I have uploaded a few images from a local source to test the labeling tool. I finish labeling and can see them visually as well as in the task source. However, when exporting to COCO format, the annotations are missing entirely. What could be the reason for this?
Expected behavior
I fully expect there to be the same annotations as in the task source.
Screenshots
{
"images": [
{
"width": 2448,
"height": 2048,
"id": 0,
"file_name": "images/23082be9-0A9LCRZ1DR.jpg"
},
{
"width": 2448,
"height": 2048,
"id": 1,
"file_name": "images/bc267355-0A9ZTH01Q3.jpg"
},
{
"width": 2448,
"height": 2048,
"id": 2,
"file_name": "images/826e681f-0A0WG84517.jpg"
}
],
"categories": [
{
"id": 0,
"name": "Test1"
},
{
"id": 1,
"name": Test2
},
{
"id": 2,
"name": Test3 Test3"
}
],
"annotations": [],
"info": {
"year": 2023,
"version": "1.0",
"description": "",
"contributor": "Label Studio",
"url": "",
"date_created": "2023-07-05 15:31:46.280794"
}
}
Environment (please complete the following information):

OS: Ubuntu 20
Label Studio Version 1.8

Additional context
Add any other context about the problem here.

Hey @coelho-k — thank you so much for reaching out for help!
Reading through your issue, I have a hunch that it might be your labeling configuration.
Can you please share with us your labeling configuration so we can help you out best?


[KARAF-6535] in bin/client script JAVA_OPTS are never populated to de…

…fault values

Generally agree, let me just do a full pass.

retest this please


fix: comma-separated splitting of image url in table col of type image

Description

fix for the comma-separated splitting of image url in table col of type image

Fixes #4365
Type of change

Bugfix (non-breaking change which fixes an issue)

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ]  I have commented on my code, particularly in hard-to-understand areas
[ ]  I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x]  I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes

Test coverage results :test_tube:
:green_circle: Total coverage has increased
// Code coverage diff between base branch:release and head branch: bug/tablewidget-image-url-spliting

Status
File
% Stmts
% Branch
% Funcs
% Lines

:green_circle:
total
51.6 (0.03)
32.77 (0.05)
29.68 (0.03)
52.1 (0.04)

:green_circle:
app/client/src/components/designSystems/appsmith/TableComponent/TableUtilities.tsx
37.86 (9.7)
23.21 (12.5)
7.41 (7.41)
36.46 (10.42)

/ok-to-test sha=1b9aa28

/ok-to-test sha=8aa33da

/ok-to-test sha=9cb1b38

/ok-to-test sha=d57937e

@techbhavin some jest tests are failing here, Please check.

/ok-to-test sha=0437078

/ok-to-test sha=cb2e90b

/ok-to-test sha=b8f8b7e

@yatinappsmith  @NandanAnantharamu test failing requires a global fix.

/ok-to-test sha=562a28a

@yatinappsmith @NandanAnantharamu these tests have failed again after a release merge

@yatinappsmith @NandanAnantharamu these tests have failed again after a release merge

This was also fixed last week, please merge release and rerun

/ok-to-test sha=0b3c910

@yatinappsmith @NandanAnantharamu these tests have failed again after a release merge

/ok-to-test sha=af1c07c

/ok-to-test sha=e41ac8c

Re-running jobs flaky tests failing

/ok-to-test sha=d56ebf8


document how to verify tekton pipelines release

Changes
Adding detailed documentation on how to verify Tekton Pipelines release. Tekton pipelines started signing the release since v0.27.1. A step-by-step process to verify the release includes:

collecting the digest of the release
searching the transparency logs for that digest
requesting provenance of the release
using cosign to verify each artifact

/kind documentation
Submitter Checklist
As the author of this PR, please check off the items in this checklist:

[x] Docs included if any changes are user facing
[ ] Tests included if any functionality added or changed
[x] Follows the commit message standard
[x] Meets the Tekton contributor standards (including
functionality, content, code)
[x] Release notes block below has been filled in or deleted (only if no user facing changes)

Release Notes
Document step-by-step process of how to verify Tekton Pipelines release.

/test pull-tekton-pipeline-alpha-integration-tests

/test check-pr-has-kind-label


Accessibility: MAC: Color Contrast: MAS1.4.3: Selected Project text in Left pane is not having 4.5:1 color contrast ratio .

Steps to Reproduce

Launch Xamrin Workbook application.
2.Create a new workbook and observe the colour contrast ratio of Selected Project in left pane using colour contrast analyser

Expected Behavior
Colour contrast ratio should be minimum 4.5:1
Actual Behavior
Colour contrast ratio is lesser than 4.5:1 (i.e., 3.8:1)
as shown in the attached screen-shots.
User Impact:
Low vision user will feel difficulty in seeing the text.
Environment
MAC: macOS High Sierra [10.13.4]
Workbook - 1.4 (master/b3f92f9)
Log File

Please add the following labels to this bug:
A11yMAS
Accessibility
MAS1.4.3
Xamarin-Workbook-MAC
Wipro

This is a stock macOS control. We do not influence or control the rendering of this control. The system-wide "Graphite" appearance may exhibit 4.5:1 contrast. Regardless, this is not something we can or should address in our code as it comes from macOS itself.

Exemption Approved - 1831


Updated GatewaySku types for the VPN Gateway

VPN Gateways do not have an ultraperformance sku (https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-skus-legacy)
The new VpnGwX skus are compatible with coexistance as well as the legacy Standard and HighPerformance skus.

@JackStromberg : Thanks for your contribution! The author, @charwen, has been notified to review your proposed change.

@KumudD FYI

#sign-off


System.Exception: Unable to read beyond the end of the stream on Azure Ubuntu Pipeline Agent

Description

Hello, I'm facing a problem during the Integration Tests Job on the Azure CI/CD pipeline, project is the .NET Core 6 application.

The jobs are being run by a pool of the Build agents that are Linux Ubuntu machines, version 20.04. The confusing part is that tests (Xunit) are all green when they have been run on the local Windows machine, but for some reason, execution pipeline has been broken on Linux Ubuntu with very generic message ->
Test Run Aborted with error System.Exception: One or more errors occurred.  ---> System.Exception: Unable to read beyond the end of the stream.    at System.IO.BinaryReader.Read7BitEncodedInt()    at System.IO.BinaryReader.ReadString()    at Microsoft.VisualStudio.TestPlatform.CommunicationUtilities.LengthPrefixCommunicationChannel.NotifyDataAvailable()    at Microsoft.VisualStudio.TestPlatform.CommunicationUtilities.TcpClientExtensions.MessageLoopAsync(TcpClient client, ICommunicationChannel channel, Action 1 errorHandler, CancellationToken cancellationToken)    --- End of inner exception stack trace ---.
Is there any way to make the given message more verbose, containing more details about the error?
Steps to reproduce

Pipeline task definition:  - task: DotNetCoreCLI@2
displayName: Integration tests
inputs:
command: test
projects: '**/Tms.Tests.Integration/.csproj'
arguments: -v=normal --logger:"console;verbosity=normal" --blame --no-build --configuration $(BuildConfiguration)
publishTestResults: false.

Expected behavior

Test project is not aborted regardless of the results.

Actual behavior

Test project is aborted without any concrete message.

Environment

OS: Linux Ubuntu, 20.04
Xunit testing framework - 2.4.2
Microsoft.AspNetCore.TestHost - 6.0.11

You can enable verbose logging using the --diag argument like in the sample https://github.com/Microsoft/vstest-docs/blob/main/docs/troubleshooting.md#dotnetcorecli2-task
The sample explain how to take a dump of the host process too.


Various fixes and enhacements to kyverno plugin script

This PR fixes #
Checklist

[x] I have signed the CLA
[x] I have updated/added any relevant documentation

Description

Fix log message when checking for clusterreports: this was printing the current namespace which is not applicable to cluster-wide reports
Include policy/clusterpolicy title and description in report: for some reason the category and message are part of results in policyreports, but not title and description
bash refactoring

Example output
{
  "policyReports": [
    {
      "apiVersion": "wgpolicyk8s.io/v1alpha2",
      "kind": "PolicyReport",
      "metadata": {
        "creationTimestamp": "2023-07-05T21:21:41Z",
        "generation": 133,
        "labels": {
          "app.kubernetes.io/managed-by": "kyverno",
          "cpol.kyverno.io/require-labels": "1098961"
        },
        "name": "cpol-require-labels",
        "namespace": "cert-manager",
        "resourceVersion": "1176394",
        "uid": "137179d0-d182-48ca-b5c9-9d50d222394c"
      },
      "results": [
        {
          "message": "validation error: label 'team' is required. rule check-team failed at path /metadata/labels/team/",
          "policy": "require-labels",
          "resources": [
            {
              "apiVersion": "v1",
              "kind": "Pod",
              "name": "cert-manager-cainjector-56c499cdb8-w42sh",
              "namespace": "cert-manager",
              "uid": "fd47a610-ce2e-4ab6-93b7-c4ad7157c318"
            }
          ],
          "result": "fail",
          "rule": "check-team",
          "scored": true,
          "source": "kyverno",
          "timestamp": {
            "nanos": 0,
            "seconds":<PHONE_NUMBER>
          }
        }
      ],
      "summary": {
        "error": 0,
        "fail": 9,
        "pass": 0,
        "skip": 0,
        "warn": 0
      },
      "policyTitle": "",
      "policyDescription": ""
    },
    {
      "apiVersion": "wgpolicyk8s.io/v1alpha2",
      "kind": "PolicyReport",
      "metadata": {
        "creationTimestamp": "2023-07-12T14:25:10Z",
        "generation": 82,
        "labels": {
          "app.kubernetes.io/managed-by": "kyverno",
          "cpol.kyverno.io/require-labelsfoo": "1098962"
        },
        "name": "cpol-require-labelsfoo",
        "namespace": "cert-manager",
        "resourceVersion": "1176392",
        "uid": "a3ac179c-318a-4bd4-a9e6-daa5f2429e9a"
      },
      "results": [
        {
          "message": "validation error: label 'foo' is required. rule check-foo failed at path /metadata/labels/foo/",
          "policy": "require-labelsfoo",
          "resources": [
            {
              "apiVersion": "v1",
              "kind": "Pod",
              "name": "cert-manager-cainjector-56c499cdb8-w42sh",
              "namespace": "cert-manager",
              "uid": "fd47a610-ce2e-4ab6-93b7-c4ad7157c318"
            }
          ],
          "result": "fail",
          "rule": "check-foo",
          "scored": true,
          "source": "kyverno",
          "timestamp": {
            "nanos": 0,
            "seconds":<PHONE_NUMBER>
          }
        }
      ],
      "summary": {
        "error": 0,
        "fail": 9,
        "pass": 0,
        "skip": 0,
        "warn": 0
      },
      "policyTitle": "",
      "policyDescription": ""
    },
    {
      "apiVersion": "wgpolicyk8s.io/v1alpha2",
      "kind": "PolicyReport",
      "metadata": {
        "creationTimestamp": "2023-07-12T18:33:51Z",
        "generation": 78,
        "labels": {
          "app.kubernetes.io/managed-by": "kyverno",
          "cpol.kyverno.io/require-pod-probes": "1098965"
        },
        "name": "cpol-require-pod-probes",
        "namespace": "cert-manager",
        "resourceVersion": "1176393",
        "uid": "6875753a-d442-4ec5-be39-55a3ec9e1854"
      },
      "results": [
        {
          "category": "Best Practices, EKS Best Practices",
          "message": "validation failure: Liveness, readiness, or startup probes are required for all containers.",
          "policy": "require-pod-probes",
          "resources": [
            {
              "apiVersion": "v1",
              "kind": "Pod",
              "name": "cert-manager-cainjector-56c499cdb8-w42sh",
              "namespace": "cert-manager",
              "uid": "fd47a610-ce2e-4ab6-93b7-c4ad7157c318"
            }
          ],
          "result": "fail",
          "rule": "validate-probes",
          "scored": true,
          "severity": "medium",
          "source": "kyverno",
          "timestamp": {
            "nanos": 0,
            "seconds":<PHONE_NUMBER>
          }
        }
      ],
      "summary": {
        "error": 0,
        "fail": 4,
        "pass": 2,
        "skip": 0,
        "warn": 0
      },
      "policyTitle": "Require Pod Probes",
      "policyDescription": "Liveness and readiness probes need to be configured to correctly manage a Pod's lifecycle during deployments, restarts, and upgrades. For each Pod, a periodic `livenessProbe` is performed by the kubelet to determine if the Pod's containers are running or need to be restarted. A `readinessProbe` is used by Services and Deployments to determine if the Pod is ready to receive network traffic. This policy validates that all containers have one of livenessProbe, readinessProbe, or startupProbe defined.      "
    },
    {
      "apiVersion": "wgpolicyk8s.io/v1alpha2",
      "kind": "PolicyReport",
      "metadata": {
        "creationTimestamp": "2023-07-11T15:26:34Z",
        "generation": 104,
        "labels": {
          "app.kubernetes.io/managed-by": "kyverno",
          "cpol.kyverno.io/require-labels": "1098961"
        },
        "name": "cpol-require-labels",
        "namespace": "default",
        "resourceVersion": "1176396",
        "uid": "302270c2-f047-4c17-8c62-c72ce4cb644c"
      },
      "results": [
        {
          "message": "validation error: label 'team' is required. rule check-team failed at path /metadata/labels/team/",
          "policy": "require-labels",
          "resources": [
            {
              "apiVersion": "v1",
              "kind": "Pod",
              "name": "nginx-7c58f7c8c8-sq9cx",
              "namespace": "default",
              "uid": "a6b10716-f18d-4913-92ff-916e3346c7c5"
            }
          ],
          "result": "fail",
          "rule": "check-team",
          "scored": true,
          "source": "kyverno",
          "timestamp": {
            "nanos": 0,
            "seconds":<PHONE_NUMBER>
          }
        }
      ],
      "summary": {
        "error": 0,
        "fail": 5,
        "pass": 0,
        "skip": 0,
        "warn": 0
      },
      "policyTitle": "Require Pod Probes",
      "policyDescription": "Liveness and readiness probes need to be configured to correctly manage a Pod's lifecycle during deployments, restarts, and upgrades. For each Pod, a periodic `livenessProbe` is performed by the kubelet to determine if the Pod's containers are running or need to be restarted. A `readinessProbe` is used by Services and Deployments to determine if the Pod is ready to receive network traffic. This policy validates that all containers have one of livenessProbe, readinessProbe, or startupProbe defined.      "
    },
    {
      "apiVersion": "wgpolicyk8s.io/v1alpha2",
      "kind": "PolicyReport",
      "metadata": {
        "creationTimestamp": "2023-07-12T14:25:11Z",
        "generation": 91,
        "labels": {
          "app.kubernetes.io/managed-by": "kyverno",
          "cpol.kyverno.io/require-labelsfoo": "1098962"
        },
        "name": "cpol-require-labelsfoo",
        "namespace": "default",
        "resourceVersion": "1176397",
        "uid": "ddf7c22d-e0a0-4cd4-9ca7-39f1292e5a9f"
      },
      "results": [
        {
          "message": "validation rule 'check-foo' passed.",
          "policy": "require-labelsfoo",
          "resources": [
            {
              "apiVersion": "v1",
              "kind": "Pod",
              "name": "nginx-7c58f7c8c8-sq9cx",
              "namespace": "default",
              "uid": "a6b10716-f18d-4913-92ff-916e3346c7c5"
            }
          ],
          "result": "pass",
          "rule": "check-foo",
          "scored": true,
          "source": "kyverno",
          "timestamp": {
            "nanos": 0,
            "seconds":<PHONE_NUMBER>
          }
        }
      ],
      "summary": {
        "error": 0,
        "fail": 2,
        "pass": 3,
        "skip": 0,
        "warn": 0
      },
      "policyTitle": "Require Pod Probes",
      "policyDescription": "Liveness and readiness probes need to be configured to correctly manage a Pod's lifecycle during deployments, restarts, and upgrades. For each Pod, a periodic `livenessProbe` is performed by the kubelet to determine if the Pod's containers are running or need to be restarted. A `readinessProbe` is used by Services and Deployments to determine if the Pod is ready to receive network traffic. This policy validates that all containers have one of livenessProbe, readinessProbe, or startupProbe defined.      "
    },
    {
      "apiVersion": "wgpolicyk8s.io/v1alpha2",
      "kind": "PolicyReport",
      "metadata": {
        "creationTimestamp": "2023-07-12T18:33:51Z",
        "generation": 81,
        "labels": {
          "app.kubernetes.io/managed-by": "kyverno",
          "cpol.kyverno.io/require-pod-probes": "1098965"
        },
        "name": "cpol-require-pod-probes",
        "namespace": "default",
        "resourceVersion": "1176395",
        "uid": "9972df6a-4e08-440a-ba7e-c51e103110ed"
      },
      "results": [
        {
          "category": "Best Practices, EKS Best Practices",
          "message": "rule passed",
          "policy": "require-pod-probes",
          "resources": [
            {
              "apiVersion": "v1",
              "kind": "Pod",
              "name": "nginx-7c58f7c8c8-sq9cx",
              "namespace": "default",
              "uid": "a6b10716-f18d-4913-92ff-916e3346c7c5"
            }
          ],
          "result": "pass",
          "rule": "validate-probes",
          "scored": true,
          "severity": "medium",
          "source": "kyverno",
          "timestamp": {
            "nanos": 0,
            "seconds":<PHONE_NUMBER>
          }
        }
      ],
      "summary": {
        "error": 0,
        "fail": 0,
        "pass": 2,
        "skip": 0,
        "warn": 0
      },
      "policyTitle": "Require Pod Probes",
      "policyDescription": "Liveness and readiness probes need to be configured to correctly manage a Pod's lifecycle during deployments, restarts, and upgrades. For each Pod, a periodic `livenessProbe` is performed by the kubelet to determine if the Pod's containers are running or need to be restarted. A `readinessProbe` is used by Services and Deployments to determine if the Pod is ready to receive network traffic. This policy validates that all containers have one of livenessProbe, readinessProbe, or startupProbe defined.      "
    },
    {
      "apiVersion": "wgpolicyk8s.io/v1alpha2",
      "kind": "PolicyReport",
      "metadata": {
        "creationTimestamp": "2023-07-26T16:53:55Z",
        "generation": 16,
        "labels": {
          "app.kubernetes.io/managed-by": "kyverno",
          "cpol.kyverno.io/require-labels": "1098961"
        },
        "name": "cpol-require-labels",
        "namespace": "evil",
        "resourceVersion": "1175551",
        "uid": "0b4121b6-4b48-4968-98f2-131d4cfa1418"
      },
      "results": [
        {
          "message": "validation error: label 'team' is required. rule check-team failed at path /metadata/labels/team/",
          "policy": "require-labels",
          "resources": [
            {
              "apiVersion": "v1",
              "kind": "Pod",
              "name": "busybox",
              "namespace": "evil",
              "uid": "a4f44948-1cc7-446b-94c8-97e3031eb872"
            }
          ],
          "result": "fail",
          "rule": "check-team",
          "scored": true,
          "source": "kyverno",
          "timestamp": {
            "nanos": 0,
            "seconds":<PHONE_NUMBER>
          }
        }
      ],
      "summary": {
        "error": 0,
        "fail": 1,
        "pass": 0,
        "skip": 0,
        "warn": 0
      },
      "policyTitle": "Require Pod Probes",
      "policyDescription": "Liveness and readiness probes need to be configured to correctly manage a Pod's lifecycle during deployments, restarts, and upgrades. For each Pod, a periodic `livenessProbe` is performed by the kubelet to determine if the Pod's containers are running or need to be restarted. A `readinessProbe` is used by Services and Deployments to determine if the Pod is ready to receive network traffic. This policy validates that all containers have one of livenessProbe, readinessProbe, or startupProbe defined.      "
    },
    {
      "apiVersion": "wgpolicyk8s.io/v1alpha2",
      "kind": "PolicyReport",
      "metadata": {
        "creationTimestamp": "2023-07-26T16:53:55Z",
        "generation": 16,
        "labels": {
          "app.kubernetes.io/managed-by": "kyverno",
          "cpol.kyverno.io/require-labelsfoo": "1098962"
        },
        "name": "cpol-require-labelsfoo",
        "namespace": "evil",
        "resourceVersion": "1175552",
        "uid": "03644731-220a-41cc-9bad-889f6c13451d"
      },
      "results": [
        {
          "message": "validation error: label 'foo' is required. rule check-foo failed at path /metadata/labels/foo/",
          "policy": "require-labelsfoo",
          "resources": [
            {
              "apiVersion": "v1",
              "kind": "Pod",
              "name": "busybox",
              "namespace": "evil",
              "uid": "a4f44948-1cc7-446b-94c8-97e3031eb872"
            }
          ],
          "result": "fail",
          "rule": "check-foo",
          "scored": true,
          "source": "kyverno",
          "timestamp": {
            "nanos": 0,
            "seconds":<PHONE_NUMBER>
          }
        }
      ],
      "summary": {
        "error": 0,
        "fail": 1,
        "pass": 0,
        "skip": 0,
        "warn": 0
      },
      "policyTitle": "Require Pod Probes",
      "policyDescription": "Liveness and readiness probes need to be configured to correctly manage a Pod's lifecycle during deployments, restarts, and upgrades. For each Pod, a periodic `livenessProbe` is performed by the kubelet to determine if the Pod's containers are running or need to be restarted. A `readinessProbe` is used by Services and Deployments to determine if the Pod is ready to receive network traffic. This policy validates that all containers have one of livenessProbe, readinessProbe, or startupProbe defined.      "
    },
    {
      "apiVersion": "wgpolicyk8s.io/v1alpha2",
      "kind": "PolicyReport",
      "metadata": {
        "creationTimestamp": "2023-07-26T16:53:55Z",
        "generation": 16,
        "labels": {
          "app.kubernetes.io/managed-by": "kyverno",
          "cpol.kyverno.io/require-pod-probes": "1098965"
        },
        "name": "cpol-require-pod-probes",
        "namespace": "evil",
        "resourceVersion": "1175550",
        "uid": "581ee75e-5eea-4033-9d7d-8894096cf1a3"
      },
      "results": [
        {
          "category": "Best Practices, EKS Best Practices",
          "message": "validation failure: Liveness, readiness, or startup probes are required for all containers.",
          "policy": "require-pod-probes",
          "resources": [
            {
              "apiVersion": "v1",
              "kind": "Pod",
              "name": "busybox",
              "namespace": "evil",
              "uid": "a4f44948-1cc7-446b-94c8-97e3031eb872"
            }
          ],
          "result": "fail",
          "rule": "validate-probes",
          "scored": true,
          "severity": "medium",
          "source": "kyverno",
          "timestamp": {
            "nanos": 0,
            "seconds":<PHONE_NUMBER>
          }
        }
      ],
      "summary": {
        "error": 0,
        "fail": 1,
        "pass": 0,
        "skip": 0,
        "warn": 0
      },
      "policyTitle": "Require Pod Probes",
      "policyDescription": "Liveness and readiness probes need to be configured to correctly manage a Pod's lifecycle during deployments, restarts, and upgrades. For each Pod, a periodic `livenessProbe` is performed by the kubelet to determine if the Pod's containers are running or need to be restarted. A `readinessProbe` is used by Services and Deployments to determine if the Pod is ready to receive network traffic. This policy validates that all containers have one of livenessProbe, readinessProbe, or startupProbe defined.      "
    },
    {
      "apiVersion": "wgpolicyk8s.io/v1alpha2",
      "kind": "PolicyReport",
      "metadata": {
        "creationTimestamp": "2023-07-18T20:41:39Z",
        "generation": 969,
        "labels": {
          "app.kubernetes.io/managed-by": "kyverno",
          "cpol.kyverno.io/require-labels": "1098961"
        },
        "name": "cpol-require-labels",
        "namespace": "insights-agent",
        "resourceVersion": "1188939",
        "uid": "f7cf36ac-20cb-4783-bb09-42977dc25c95"
      },
      "results": [
        {
          "message": "validation error: label 'team' is required. rule check-team failed at path /metadata/labels/team/",
          "policy": "require-labels",
          "resources": [
            {
              "apiVersion": "v1",
              "kind": "Pod",
              "name": "kyverno-28174744-qg4h9",
              "namespace": "insights-agent",
              "uid": "d823ba8f-7169-46b1-b758-ff1b4b4f175b"
            }
          ],
          "result": "fail",
          "rule": "check-team",
          "scored": true,
          "source": "kyverno",
          "timestamp": {
            "nanos": 0,
            "seconds":<PHONE_NUMBER>
          }
        }
      ],
      "summary": {
        "error": 0,
        "fail": 30,
        "pass": 0,
        "skip": 0,
        "warn": 0
      },
      "policyTitle": "Require Pod Probes",
      "policyDescription": "Liveness and readiness probes need to be configured to correctly manage a Pod's lifecycle during deployments, restarts, and upgrades. For each Pod, a periodic `livenessProbe` is performed by the kubelet to determine if the Pod's containers are running or need to be restarted. A `readinessProbe` is used by Services and Deployments to determine if the Pod is ready to receive network traffic. This policy validates that all containers have one of livenessProbe, readinessProbe, or startupProbe defined.      "
    },
    {
      "apiVersion": "wgpolicyk8s.io/v1alpha2",
      "kind": "PolicyReport",
      "metadata": {
        "creationTimestamp": "2023-07-18T20:41:39Z",
        "generation": 969,
        "labels": {
          "app.kubernetes.io/managed-by": "kyverno",
          "cpol.kyverno.io/require-labelsfoo": "1098962"
        },
        "name": "cpol-require-labelsfoo",
        "namespace": "insights-agent",
        "resourceVersion": "1188938",
        "uid": "71ef5e47-c7cd-412d-a7e3-16af34890560"
      },
      "results": [
        {
          "message": "validation error: label 'foo' is required. rule check-foo failed at path /metadata/labels/foo/",
          "policy": "require-labelsfoo",
          "resources": [
            {
              "apiVersion": "v1",
              "kind": "Pod",
              "name": "kyverno-28174744-qg4h9",
              "namespace": "insights-agent",
              "uid": "d823ba8f-7169-46b1-b758-ff1b4b4f175b"
            }
          ],
          "result": "fail",
          "rule": "check-foo",
          "scored": true,
          "source": "kyverno",
          "timestamp": {
            "nanos": 0,
            "seconds":<PHONE_NUMBER>
          }
        }
      ],
      "summary": {
        "error": 0,
        "fail": 30,
        "pass": 0,
        "skip": 0,
        "warn": 0
      },
      "policyTitle": "Require Pod Probes",
      "policyDescription": "Liveness and readiness probes need to be configured to correctly manage a Pod's lifecycle during deployments, restarts, and upgrades. For each Pod, a periodic `livenessProbe` is performed by the kubelet to determine if the Pod's containers are running or need to be restarted. A `readinessProbe` is used by Services and Deployments to determine if the Pod is ready to receive network traffic. This policy validates that all containers have one of livenessProbe, readinessProbe, or startupProbe defined.      "
    },
    {
      "apiVersion": "wgpolicyk8s.io/v1alpha2",
      "kind": "PolicyReport",
      "metadata": {
        "creationTimestamp": "2023-07-25T14:50:22Z",
        "generation": 597,
        "labels": {
          "app.kubernetes.io/managed-by": "kyverno",
          "cpol.kyverno.io/require-pod-probes": "1098965"
        },
        "name": "cpol-require-pod-probes",
        "namespace": "insights-agent",
        "resourceVersion": "1188940",
        "uid": "76f84f34-f399-416d-a413-cbedc4eadc85"
      },
      "results": [
        {
          "category": "Best Practices, EKS Best Practices",
          "message": "validation failure: Liveness, readiness, or startup probes are required for all containers.",
          "policy": "require-pod-probes",
          "resources": [
            {
              "apiVersion": "v1",
              "kind": "Pod",
              "name": "kyverno-28174744-qg4h9",
              "namespace": "insights-agent",
              "uid": "d823ba8f-7169-46b1-b758-ff1b4b4f175b"
            }
          ],
          "result": "fail",
          "rule": "validate-probes",
          "scored": true,
          "severity": "medium",
          "source": "kyverno",
          "timestamp": {
            "nanos": 0,
            "seconds":<PHONE_NUMBER>
          }
        }
      ],
      "summary": {
        "error": 0,
        "fail": 13,
        "pass": 0,
        "skip": 0,
        "warn": 0
      },
      "policyTitle": "Require Pod Probes",
      "policyDescription": "Liveness and readiness probes need to be configured to correctly manage a Pod's lifecycle during deployments, restarts, and upgrades. For each Pod, a periodic `livenessProbe` is performed by the kubelet to determine if the Pod's containers are running or need to be restarted. A `readinessProbe` is used by Services and Deployments to determine if the Pod is ready to receive network traffic. This policy validates that all containers have one of livenessProbe, readinessProbe, or startupProbe defined.      "
    },
    {
      "apiVersion": "wgpolicyk8s.io/v1alpha2",
      "kind": "PolicyReport",
      "metadata": {
        "creationTimestamp": "2023-07-05T21:21:41Z",
        "generation": 133,
        "labels": {
          "app.kubernetes.io/managed-by": "kyverno",
          "cpol.kyverno.io/require-labels": "1098961"
        },
        "name": "cpol-require-labels",
        "namespace": "kube-system",
        "resourceVersion": "1176391",
        "uid": "2c6fbb13-0ad6-4b26-9995-4d40dbd611e8"
      },
      "results": [
        {
          "message": "validation error: label 'team' is required. rule check-team failed at path /metadata/labels/team/",
          "policy": "require-labels",
          "resources": [
            {
              "apiVersion": "v1",
              "kind": "Pod",
              "name": "coredns-5d78c9869d-925lv",
              "namespace": "kube-system",
              "uid": "b4cc3981-9806-4dbb-b770-bc85778c1bec"
            }
          ],
          "result": "fail",
          "rule": "check-team",
          "scored": true,
          "source": "kyverno",
          "timestamp": {
            "nanos": 0,
            "seconds":<PHONE_NUMBER>
          }
        }
      ],
      "summary": {
        "error": 0,
        "fail": 12,
        "pass": 0,
        "skip": 0,
        "warn": 0
      },
      "policyTitle": "Require Pod Probes",
      "policyDescription": "Liveness and readiness probes need to be configured to correctly manage a Pod's lifecycle during deployments, restarts, and upgrades. For each Pod, a periodic `livenessProbe` is performed by the kubelet to determine if the Pod's containers are running or need to be restarted. A `readinessProbe` is used by Services and Deployments to determine if the Pod is ready to receive network traffic. This policy validates that all containers have one of livenessProbe, readinessProbe, or startupProbe defined.      "
    },
    {
      "apiVersion": "wgpolicyk8s.io/v1alpha2",
      "kind": "PolicyReport",
      "metadata": {
        "creationTimestamp": "2023-07-12T14:25:11Z",
        "generation": 82,
        "labels": {
          "app.kubernetes.io/managed-by": "kyverno",
          "cpol.kyverno.io/require-labelsfoo": "1098962"
        },
        "name": "cpol-require-labelsfoo",
        "namespace": "kube-system",
        "resourceVersion": "1176389",
        "uid": "9c6f861d-bf45-47d7-a93c-04a88f11a1d3"
      },
      "results": [
        {
          "message": "validation error: label 'foo' is required. rule check-foo failed at path /metadata/labels/foo/",
          "policy": "require-labelsfoo",
          "resources": [
            {
              "apiVersion": "v1",
              "kind": "Pod",
              "name": "coredns-5d78c9869d-925lv",
              "namespace": "kube-system",
              "uid": "b4cc3981-9806-4dbb-b770-bc85778c1bec"
            }
          ],
          "result": "fail",
          "rule": "check-foo",
          "scored": true,
          "source": "kyverno",
          "timestamp": {
            "nanos": 0,
            "seconds":<PHONE_NUMBER>
          }
        }
      ],
      "summary": {
        "error": 0,
        "fail": 12,
        "pass": 0,
        "skip": 0,
        "warn": 0
      },
      "policyTitle": "Require Pod Probes",
      "policyDescription": "Liveness and readiness probes need to be configured to correctly manage a Pod's lifecycle during deployments, restarts, and upgrades. For each Pod, a periodic `livenessProbe` is performed by the kubelet to determine if the Pod's containers are running or need to be restarted. A `readinessProbe` is used by Services and Deployments to determine if the Pod is ready to receive network traffic. This policy validates that all containers have one of livenessProbe, readinessProbe, or startupProbe defined.      "
    },
    {
      "apiVersion": "wgpolicyk8s.io/v1alpha2",
      "kind": "PolicyReport",
      "metadata": {
        "creationTimestamp": "2023-07-12T18:33:51Z",
        "generation": 78,
        "labels": {
          "app.kubernetes.io/managed-by": "kyverno",
          "cpol.kyverno.io/require-pod-probes": "1098965"
        },
        "name": "cpol-require-pod-probes",
        "namespace": "kube-system",
        "resourceVersion": "1176390",
        "uid": "abd6b7e3-49c2-4c4c-85ea-06ab1c8f7a6f"
      },
      "results": [
        {
          "category": "Best Practices, EKS Best Practices",
          "message": "rule passed",
          "policy": "require-pod-probes",
          "resources": [
            {
              "apiVersion": "v1",
              "kind": "Pod",
              "name": "coredns-5d78c9869d-925lv",
              "namespace": "kube-system",
              "uid": "b4cc3981-9806-4dbb-b770-bc85778c1bec"
            }
          ],
          "result": "pass",
          "rule": "validate-probes",
          "scored": true,
          "severity": "medium",
          "source": "kyverno",
          "timestamp": {
            "nanos": 0,
            "seconds":<PHONE_NUMBER>
          }
        }
      ],
      "summary": {
        "error": 0,
        "fail": 4,
        "pass": 7,
        "skip": 0,
        "warn": 0
      },
      "policyTitle": "Require Pod Probes",
      "policyDescription": "Liveness and readiness probes need to be configured to correctly manage a Pod's lifecycle during deployments, restarts, and upgrades. For each Pod, a periodic `livenessProbe` is performed by the kubelet to determine if the Pod's containers are running or need to be restarted. A `readinessProbe` is used by Services and Deployments to determine if the Pod is ready to receive network traffic. This policy validates that all containers have one of livenessProbe, readinessProbe, or startupProbe defined.      "
    },
    {
      "apiVersion": "wgpolicyk8s.io/v1alpha2",
      "kind": "PolicyReport",
      "metadata": {
        "creationTimestamp": "2023-07-05T21:21:41Z",
        "generation": 698,
        "labels": {
          "app.kubernetes.io/managed-by": "kyverno",
          "cpol.kyverno.io/require-labels": "1098961"
        },
        "name": "cpol-require-labels",
        "namespace": "kyverno",
        "resourceVersion": "1187418",
        "uid": "9d4e95e2-6710-4c6a-be40-36e2a0d9a35c"
      },
      "results": [
        {
          "message": "validation error: label 'team' is required. rule check-team failed at path /metadata/labels/team/",
          "policy": "require-labels",
          "resources": [
            {
              "apiVersion": "v1",
              "kind": "Pod",
              "name": "kyverno-background-controller-bf686c789-hp2vl",
              "namespace": "kyverno",
              "uid": "d9db4109-a6da-40e1-bacb-f7b70e096c69"
            }
          ],
          "result": "fail",
          "rule": "check-team",
          "scored": true,
          "source": "kyverno",
          "timestamp": {
            "nanos": 0,
            "seconds":<PHONE_NUMBER>
          }
        }
      ],
      "summary": {
        "error": 0,
        "fail": 18,
        "pass": 0,
        "skip": 0,
        "warn": 0
      },
      "policyTitle": "Require Pod Probes",
      "policyDescription": "Liveness and readiness probes need to be configured to correctly manage a Pod's lifecycle during deployments, restarts, and upgrades. For each Pod, a periodic `livenessProbe` is performed by the kubelet to determine if the Pod's containers are running or need to be restarted. A `readinessProbe` is used by Services and Deployments to determine if the Pod is ready to receive network traffic. This policy validates that all containers have one of livenessProbe, readinessProbe, or startupProbe defined.      "
    },
    {
      "apiVersion": "wgpolicyk8s.io/v1alpha2",
      "kind": "PolicyReport",
      "metadata": {
        "creationTimestamp": "2023-07-12T14:25:11Z",
        "generation": 467,
        "labels": {
          "app.kubernetes.io/managed-by": "kyverno",
          "cpol.kyverno.io/require-labelsfoo": "1098962"
        },
        "name": "cpol-require-labelsfoo",
        "namespace": "kyverno",
        "resourceVersion": "1187419",
        "uid": "90b44587-e137-45b0-865b-721f31c11047"
      },
      "results": [
        {
          "message": "validation error: label 'foo' is required. rule check-foo failed at path /metadata/labels/foo/",
          "policy": "require-labelsfoo",
          "resources": [
            {
              "apiVersion": "v1",
              "kind": "Pod",
              "name": "kyverno-background-controller-bf686c789-hp2vl",
              "namespace": "kyverno",
              "uid": "d9db4109-a6da-40e1-bacb-f7b70e096c69"
            }
          ],
          "result": "fail",
          "rule": "check-foo",
          "scored": true,
          "source": "kyverno",
          "timestamp": {
            "nanos": 0,
            "seconds":<PHONE_NUMBER>
          }
        }
      ],
      "summary": {
        "error": 0,
        "fail": 18,
        "pass": 0,
        "skip": 0,
        "warn": 0
      },
      "policyTitle": "Require Pod Probes",
      "policyDescription": "Liveness and readiness probes need to be configured to correctly manage a Pod's lifecycle during deployments, restarts, and upgrades. For each Pod, a periodic `livenessProbe` is performed by the kubelet to determine if the Pod's containers are running or need to be restarted. A `readinessProbe` is used by Services and Deployments to determine if the Pod is ready to receive network traffic. This policy validates that all containers have one of livenessProbe, readinessProbe, or startupProbe defined.      "
    },
    {
      "apiVersion": "wgpolicyk8s.io/v1alpha2",
      "kind": "PolicyReport",
      "metadata": {
        "creationTimestamp": "2023-07-12T18:33:51Z",
        "generation": 441,
        "labels": {
          "app.kubernetes.io/managed-by": "kyverno",
          "cpol.kyverno.io/require-pod-probes": "1098965"
        },
        "name": "cpol-require-pod-probes",
        "namespace": "kyverno",
        "resourceVersion": "1187420",
        "uid": "470a46ee-c319-4e41-bc95-0263b2490105"
      },
      "results": [
        {
          "category": "Best Practices, EKS Best Practices",
          "message": "validation failure: Liveness, readiness, or startup probes are required for all containers.",
          "policy": "require-pod-probes",
          "resources": [
            {
              "apiVersion": "v1",
              "kind": "Pod",
              "name": "kyverno-background-controller-bf686c789-hp2vl",
              "namespace": "kyverno",
              "uid": "d9db4109-a6da-40e1-bacb-f7b70e096c69"
            }
          ],
          "result": "fail",
          "rule": "validate-probes",
          "scored": true,
          "severity": "medium",
          "source": "kyverno",
          "timestamp": {
            "nanos": 0,
            "seconds":<PHONE_NUMBER>
          }
        }
      ],
      "summary": {
        "error": 0,
        "fail": 6,
        "pass": 4,
        "skip": 0,
        "warn": 0
      },
      "policyTitle": "Require Pod Probes",
      "policyDescription": "Liveness and readiness probes need to be configured to correctly manage a Pod's lifecycle during deployments, restarts, and upgrades. For each Pod, a periodic `livenessProbe` is performed by the kubelet to determine if the Pod's containers are running or need to be restarted. A `readinessProbe` is used by Services and Deployments to determine if the Pod is ready to receive network traffic. This policy validates that all containers have one of livenessProbe, readinessProbe, or startupProbe defined.      "
    },
    {
      "apiVersion": "wgpolicyk8s.io/v1alpha2",
      "kind": "PolicyReport",
      "metadata": {
        "creationTimestamp": "2023-07-05T21:21:41Z",
        "generation": 133,
        "labels": {
          "app.kubernetes.io/managed-by": "kyverno",
          "cpol.kyverno.io/require-labels": "1098961"
        },
        "name": "cpol-require-labels",
        "namespace": "local-path-storage",
        "resourceVersion": "1176399",
        "uid": "9a7882d2-6e83-461d-8c12-820b39462b2c"
      },
      "results": [
        {
          "message": "validation error: label 'team' is required. rule check-team failed at path /metadata/labels/team/",
          "policy": "require-labels",
          "resources": [
            {
              "apiVersion": "v1",
              "kind": "Pod",
              "name": "local-path-provisioner-6bc4bddd6b-5jhpl",
              "namespace": "local-path-storage",
              "uid": "4d9f134a-7410-49f2-98db-bd5efa2b78b0"
            }
          ],
          "result": "fail",
          "rule": "check-team",
          "scored": true,
          "source": "kyverno",
          "timestamp": {
            "nanos": 0,
            "seconds":<PHONE_NUMBER>
          }
        }
      ],
      "summary": {
        "error": 0,
        "fail": 3,
        "pass": 0,
        "skip": 0,
        "warn": 0
      },
      "policyTitle": "Require Pod Probes",
      "policyDescription": "Liveness and readiness probes need to be configured to correctly manage a Pod's lifecycle during deployments, restarts, and upgrades. For each Pod, a periodic `livenessProbe` is performed by the kubelet to determine if the Pod's containers are running or need to be restarted. A `readinessProbe` is used by Services and Deployments to determine if the Pod is ready to receive network traffic. This policy validates that all containers have one of livenessProbe, readinessProbe, or startupProbe defined.      "
    },
    {
      "apiVersion": "wgpolicyk8s.io/v1alpha2",
      "kind": "PolicyReport",
      "metadata": {
        "creationTimestamp": "2023-07-12T14:25:11Z",
        "generation": 81,
        "labels": {
          "app.kubernetes.io/managed-by": "kyverno",
          "cpol.kyverno.io/require-labelsfoo": "1098962"
        },
        "name": "cpol-require-labelsfoo",
        "namespace": "local-path-storage",
        "resourceVersion": "1176400",
        "uid": "d4ce22e4-a0c2-4031-a3bb-48c226f44599"
      },
      "results": [
        {
          "message": "validation error: label 'foo' is required. rule check-foo failed at path /metadata/labels/foo/",
          "policy": "require-labelsfoo",
          "resources": [
            {
              "apiVersion": "v1",
              "kind": "Pod",
              "name": "local-path-provisioner-6bc4bddd6b-5jhpl",
              "namespace": "local-path-storage",
              "uid": "4d9f134a-7410-49f2-98db-bd5efa2b78b0"
            }
          ],
          "result": "fail",
          "rule": "check-foo",
          "scored": true,
          "source": "kyverno",
          "timestamp": {
            "nanos": 0,
            "seconds":<PHONE_NUMBER>
          }
        }
      ],
      "summary": {
        "error": 0,
        "fail": 3,
        "pass": 0,
        "skip": 0,
        "warn": 0
      },
      "policyTitle": "Require Pod Probes",
      "policyDescription": "Liveness and readiness probes need to be configured to correctly manage a Pod's lifecycle during deployments, restarts, and upgrades. For each Pod, a periodic `livenessProbe` is performed by the kubelet to determine if the Pod's containers are running or need to be restarted. A `readinessProbe` is used by Services and Deployments to determine if the Pod is ready to receive network traffic. This policy validates that all containers have one of livenessProbe, readinessProbe, or startupProbe defined.      "
    },
    {
      "apiVersion": "wgpolicyk8s.io/v1alpha2",
      "kind": "PolicyReport",
      "metadata": {
        "creationTimestamp": "2023-07-12T18:33:51Z",
        "generation": 77,
        "labels": {
          "app.kubernetes.io/managed-by": "kyverno",
          "cpol.kyverno.io/require-pod-probes": "1098965"
        },
        "name": "cpol-require-pod-probes",
        "namespace": "local-path-storage",
        "resourceVersion": "1176398",
        "uid": "b1cdae66-64de-4b65-9ec9-8564e7b09911"
      },
      "results": [
        {
          "category": "Best Practices, EKS Best Practices",
          "message": "validation failure: Liveness, readiness, or startup probes are required for all containers.",
          "policy": "require-pod-probes",
          "resources": [
            {
              "apiVersion": "v1",
              "kind": "Pod",
              "name": "local-path-provisioner-6bc4bddd6b-5jhpl",
              "namespace": "local-path-storage",
              "uid": "4d9f134a-7410-49f2-98db-bd5efa2b78b0"
            }
          ],
          "result": "fail",
          "rule": "validate-probes",
          "scored": true,
          "severity": "medium",
          "source": "kyverno",
          "timestamp": {
            "nanos": 0,
            "seconds":<PHONE_NUMBER>
          }
        }
      ],
      "summary": {
        "error": 0,
        "fail": 2,
        "pass": 0,
        "skip": 0,
        "warn": 0
      },
      "policyTitle": "Require Pod Probes",
      "policyDescription": "Liveness and readiness probes need to be configured to correctly manage a Pod's lifecycle during deployments, restarts, and upgrades. For each Pod, a periodic `livenessProbe` is performed by the kubelet to determine if the Pod's containers are running or need to be restarted. A `readinessProbe` is used by Services and Deployments to determine if the Pod is ready to receive network traffic. This policy validates that all containers have one of livenessProbe, readinessProbe, or startupProbe defined.      "
    }
  ],
  "clusterPolicyReports": [
    {
      "apiVersion": "wgpolicyk8s.io/v1alpha2",
      "kind": "ClusterPolicyReport",
      "metadata": {
        "creationTimestamp": "2023-07-25T22:34:50Z",
        "generation": 30,
        "labels": {
          "app.kubernetes.io/managed-by": "kyverno",
          "cpol.kyverno.io/require-ns-labels": "1186060"
        },
        "name": "cpol-require-ns-labels",
        "resourceVersion": "1186279",
        "uid": "1a9cf969-c117-4b24-b394-4e8a8fd36bc9"
      },
      "results": [
        {
          "message": "validation error: The label `thisshouldntexist` is required. rule check-for-labels-on-namespace failed at path /metadata/labels/thisshouldntexist/",
          "policy": "require-ns-labels",
          "resources": [
            {
              "apiVersion": "v1",
              "kind": "Namespace",
              "name": "default",
              "uid": "eb3fc0dd-db73-442b-a151-d724b6bf31df"
            }
          ],
          "result": "fail",
          "rule": "check-for-labels-on-namespace",
          "scored": true,
          "source": "kyverno",
          "timestamp": {
            "nanos": 0,
            "seconds":<PHONE_NUMBER>
          }
        }
      ],
      "summary": {
        "error": 0,
        "fail": 9,
        "pass": 0,
        "skip": 0,
        "warn": 0
      },
      "policyTitle": "Bogus label on namespace",
      "policyDescription": "Lorem ipsum dolor sit amet"
    }
  ]
}

What's the goal of this PR?
What changes did you make?
What alternative solution should we consider, if any?

title and description fields are not required by Kyverno, so they can be blank. Not sure how we'd like to handle this on the insights side
As discussed, on the backend we will accept [efficiency, reliability, security] as categories. If none of these are provided, we will fall back on security
severities will be mapped 1-1: critical, high, medium, low, none we will fall back to none if what's provided is not one of these

I'd fall back to the policy title being the check ID (i.e. metadata.name)


Synchronous emitter.emit

Currently emitter.emit only works in asynchronous environments. However, making it work for synchronous listeners only shouldn't be too difficult, and would allow this lib to be used by a wider range of projects.
Only requirement I have is that asynchronous listeners (Coroutines, ...) should be ignored when calling this synchronous version of emitter.emit, and that it must have a distinctive name, and not be an extra parameter of emitter.emit. IMHO I recommend something along the lines of emitter.sync.emit, but I am open to other ideas.

Changed my mind and end up implementing as an extra parameter of emitter.emit :stuck_out_tongue_closed_eyes:


setup-buttons-usb-encoder.sh broken after commit 3d7c7cf

Hi,
the setup of the buttons usb encoder broke last week in the development branch. I was able to pin it down to one commit 3d7c7cf
On previous commit the installer seems to work fine.
git diff 91dc192..3d7c7cf -- ./components
~/RPi-Jukebox-RFID $ git checkout 3d7c7cf ./components
~/RPi-Jukebox-RFID $ git clean -fd components/
sudo components/controls/buttons_usb_encoder/setup-buttons-usb-encoder.sh
Than is no mapping possible following message appears:
During the next step you can map your buttons to one of the following available functions:
[]
Ready to continue? (y/n)

gpio_control was refactored to a class.
This needs to be considered here
https://github.com/MiczFlor/RPi-Jukebox-RFID/blob/5be26c528f7731cd4fd1d4ba23913e5f2622d8fa/components/controls/buttons_usb_encoder/map_buttons_usb_encoder.py#L9
and here
https://github.com/MiczFlor/RPi-Jukebox-RFID/blob/5be26c528f7731cd4fd1d4ba23913e5f2622d8fa/components/controls/buttons_usb_encoder/buttons_usb_encoder.py#L9
@arne123 could you have a look?

I Just had a look,
is my understanding correct, that either the USB Buttons or the GPIO Control are used?
The common point are just the function calls?

Yes and yes :)

PR #1323 is merged, issue should be fixed.


Run server and client with same command.

Adding concurrently for running server and client with a single command.
cd backed && npm run dev

Added the commit and merged with master https://github.com/SiddharthSham/cssify/commit/5061c6b91cd330894642dec56ea37f862a177cdd


[no-inline-styles] ternary style gets mistakenly reported

I get a warning on this inline style:
<View
  style={[
    styles.safeAreaTransparent,
    { height: props.insetsTop ? insets.top : 0, },  // <---- eslint(react-native/no-inline-styles)
  ]}
/>

Does this behaviour work as expected?
If so, how should we change these?
I think it should not report as a warning though ...

Yeah, all conditional expressions by default are considered invalid here. I think plugin should accept some pattern config to apply only certain validations and skip others.

I think it should be configureable, so that if there are variables in it, it should not report at all. Because it makes the code much more complicated with little benefit. If I am already using an inline style because of a conditional, I don't want to goo to the style definition and look up what style will be applied in the else case for example. But it totally makes sense for disabling  inline styles in general for other cases

I think the plugin should accept conditional expressions etc.


Build failure of netCDF daily snapshot and HDF5 1.8.17

Building on vanilla fedora box. Using mpich 3.2. Built HDF5 with:
CC=mpicc ./configure --with-zlib=/usr/local --prefix=/usr/local --with-szlib=/usr/local --enable-parallel
I cloned netCDF-c from github, but this also happened on 4.4.1:
CC=mpicc ./configure --with-zlib=/usr/local --prefix=/usr/local --with-szlib=/usr/local --with-hdf5=/usr/local --enable-pnetcdf --enable-parallel-tests --enable-logging
The test h5_test/tst_h_vars fails on this line:
  if (filter != H5Z_FILTER_DEFLATE || cd_nelems != 1 ||
  cd_values[0] != DEFLATE_LEVEL || strcmp(name, DEFLATE_NAME)) ERR;

I'm unable to duplicate this on my end, but I don't have access to a fedora box.  Are you able to duplicate this in a different environment, assuming there is one handy?

Do you have the same version of MPICH and HDF5?
This has happened to me on two different fedora systems today. One was a
clean build from scratch of fedora 23, with everything totally up to date.
The other was my laptop, running a several month old fedora.
Thanks,
Ed
On Tue, Aug 9, 2016 at 3:13 PM, Ward Fisher<EMAIL_ADDRESS>wrote:

I'm unable to duplicate this on my end, but I don't have access to a
fedora box. Are you able to duplicate this in a different environment,
assuming there is one handy?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Unidata/netcdf-c/issues/303#issuecomment-238693344,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEUr3O8bAFRCm3NSe81DZH_r8MSwALucks5qeO1hgaJpZM4JghVU
.

I'm at the HPC symposium right now so I will double check the version of mpich bundled in the docker environment when I have a chance; whatever version it is, it's the default version for Ubuntu 14.04. I'll follow up here when I can investigate.

Current version of mpich in the docker image is 3.0.4; I'll set up a VM and investigate 3.2 when I have some time and decent bandwidth.

I've just tested this on Ubuntu 16.04 with mpich 3.2 without error, but my system doesn't have szlib on it yet.  I will install szip shortly for completeness sake; I'd like to sort out this issue if I can just replicate it.

Out of curiosity, @edhartnett, and unrelated to this issue.  Can you tell offhand what the default version of cmake is provided by your fedora system? It will help inform #307.

cmake version 3.5.2
On Wed, Aug 24, 2016 at 2:50 PM, Ward Fisher<EMAIL_ADDRESS>wrote:

Out of curiosity, @edhartnett https://github.com/edhartnett, and
unrelated to this issue. Can you tell offhand what the default version of
cmake is provided by your fedora system? It will help inform #307
https://github.com/Unidata/netcdf-c/issues/307.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Unidata/netcdf-c/issues/303#issuecomment-242203695,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEUr3BeVV6-JketieDSY_wAzH2v46m16ks5qjK6mgaJpZM4JghVU
.

I am going to go ahead and close this ticket that I opened. The current HEAD is building well with the latest HDF5 with parallel IO, and that's good enough for me. ;-)

Sounds good! When you say latest version, do you mean the 1.8.x or 1.10.x branch?

I mean 1.10.1.


Add onStatusUpdate callback prop

Relates to #47
This PR adds an onStatusUpdate callback prop that receives the service status from the place API after each prediction. The full list of service statuses can be found [here].(https://developers.google.com/maps/documentation/javascript/reference/places-service#PlacesServiceStatus)
This is an example of what an onStatusUpdate prop might look like. Let me know if the name and functionality is consistent with the purpose of this library.

Codecov Report

Merging #48 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master    #48   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           5      5
  Lines          48     48
  Branches       12     12
=====================================
  Hits           48     48

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 3556d4b...da32fff. Read the comment docs.

Thank you @brpratt. v3.8.0 published


docker-machine upgrade fails with permission denied

Expected behavior
docker-machine upgrade default
server api gets updated to latest version
Actual behavior
docker-machine upgrade default
I get this:
Downloading /Users/reneval/.docker/machine/cache/boot2docker.iso from https://github.com/boot2docker/boot2docker/releases/download/v1.12.0-rc2/boot2docker.iso...
open /Users/reneval/.docker/machine/cache/boot2docker.iso.tmp619339182: permission denied
Information about the Issue
I tried changing the permissions and ~/.docker owner to user:staff. Same issue
Steps to reproduce the behavior

Use docker for mac
docker create default --driver xhyve
docker-machine env default
eval $(docker-machine env default)
docker ps
You will get: Error response from daemon: client is newer than server (client API version: 1.24, server API version: 1.23)
docker-machine upgrade default
Ends with open /Users/reneval/.docker/machine/cache/boot2docker.iso.tmp193116981: permission denied

Can you open this against github.com/docker/machine?
Thanks!

Will do, thanks!


Add support for choosing en-US for Google voice

Will be great to have ability to choose US voice for Google. Like this:
https://github.com/AwesomeTTS/awesometts-anki-addon/blob/a6bb2fc61bdd6bc2285f3874f41594cda0172bcd/awesometts/service/google.py

cloud-ssl-datasheet.pdf

You can edit the binary (as a superuser if necessary) to support American English TTS via the Google API.
Use which trans to find the file to edit.
Then change:
    function googleTTSUrl(text, tl) {
    return HttpProtocol HttpHost "/translate_tts?ie=UTF-8&client=gtx"\
    "&tl=" tl "&q=" preprocessByDump(text)
    }

... to:
    function googleTTSUrl(text, tl) {
    if (tl == "en") tl = tl "-US"
    return HttpProtocol HttpHost "/translate_tts?ie=UTF-8&client=gtx"\
    "&tl=" tl "&q=" preprocessByDump(text)
    }

In short, you want to specify en-US as the target language (variable tl in that script) without messing up other input languages. I think my proposed change accomplishes this without ill side-effects but cannot be overridden if you want an English pronunciation with a non-American accent.
(On a side note, if you use Google Translate's website in a region which defaults to non-American pronunciation, you can force American pronunciation by using translate.google.as, which is the American Samoa suffix.)

Maybe better solution will be add the separate us language type? Especially for audio, pronunciation of US English and British English is very different for some words, eg schedule.


fetch is not defined

Steps to Reproduce Issue
fetch is not defined
/node_modules/@mysten/sui.js/src/rpc/client.ts:71:31
e.g.

Call function .
Use return value and call .

System Information

OS:
Compiler:

/node_modules/@mysten/sui.js/src/rpc/client.ts:71:31
look this, fetch cannot import

You either need to use node >= 18 (which defines fetch globally), or polyfill it.


refactor: rename profiling files to have same casing as rest

Description
Making profiling files have the same Pascal casing as rest of the repo.
Type of change
Please delete options that are not relevant.

[x] Internal change (a change which is not visible to the package consumers)

Checklist:

[ ] Unit tests have been added/updated
[ ] Documentation has been updated
[ ] Change file has been generated (npm run change:new)
[ ] Delete this branch (after the PR is merged)

Codecov Report

Merging #480 (83af047) into main (499f54f) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main     #480   +/-   ##
=======================================
  Coverage   77.94%   77.94%
=======================================
  Files          25       25
  Lines         730      730
  Branches      169      169
=======================================
  Hits          569      569
  Misses        161      161

Impacted Files
Coverage Δ

src/profiling/DebugExporter.ts
30.00% <ø> (ø)

src/profiling/OTLPProfilingExporter.ts
19.44% <ø> (ø)

src/profiling/ProfilingContextManager.ts
16.00% <ø> (ø)

src/profiling/index.ts
19.11% <100.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 499f54f...83af047. Read the comment docs.


[RELEASE-1.12] GO-2024-2611: Bump google.golang.org/protobuf to v1.33.0

What this PR does / why we need it:

https://pkg.go.dev/vuln/GO-2024-2611

Which issue(s) this PR fixes:
JIRA: https://issues.redhat.com/browse/SRVCOM-2997
Does this PR needs for other branches:
No, 1.14 and up are fine.
Does this PR (patch) needs to update/drop in the future?:
No

/assign @matzew
/assign @mgencur


Add query string value mine for current user's prisons

This adds a new special value mine to the list of allowed choices for the query param prison in search forms V2.
The value is then automatically expanded into the current user's prisons when making API calls.

Superseded by #412


Not working properly with ReactJs

What is problem here ? not working with react js
import EXIF from "exif-js";

getImageDetails = () => {
        var file = document.getElementById("initial_stage");
        EXIF.getData(file, function() {
            var exifData = EXIF.getAllTags(this);
            if (exifData) {
                console.log('exifData: ', JSON.stringify(exifData));
            } else {
                console.log("No EXIF data found in image '" + file + "'.");
            }
        });
    };

<img
  onClick={this.getImageDetails}
  id="initial_stage"
  src={`/storage/${this.state.details.initial_stage}`}
/>;

"laravel": 5.8
"react": "^16.2.0",
"exif-js": "^2.3.0",

Problem solved. It is laravel voyager admin image uploading issue
Solution: Store image with file input . Now metadata is not corrupted it is ok. But when store images with image input then metadata corrupted. Maybe helpful to others

Problem solved. It is laravel voyager admin image uploading issue
Solution: Store image with file input . Now metadata is not corrupted it is ok. But when store images with image input then metadata corrupted. Maybe helpful to others

Can you post an example of your fixed code?

Problem solved. It is laravel voyager admin image uploading issue
Solution: Store image with file input . Now metadata is not corrupted it is ok. But when store images with image input then metadata corrupted. Maybe helpful to others

Can you post an example of your fixed code?

İ already posted code. Problem with admin panel. I used laravel voyager admin panel. for example i have projects and project photo. Before project photo input type was image picker (from voyager admin bread) after i changed input type to file now photo stored original format


Can set rsync flags

Added ability to change the rsync flags.

I think the default $flags value would actually be '-az --no-p'.  -i should stay.  It's just setting up the itemized output, which we're going to be using to make the output much more readable and also more structured so we can include a summary of changes pushed in notifications.  escapeshellarg() quotes values for command-line flags, not the flags themselves, so your current page would result in -'az', which is obviously not what is intended.

This capability is now in the rsync step.


Stuck on splashscreen becuase CORS issue again

It was fine when using xcode 10.1 and recently to upgrade my iOS app on app store, per apple's request, I have to upgrade to xcode to 11, and after that I fixed a few compile problems by upgrading cordova to 8.1.2 and some library ref issue.
The app then can be compiled, installed successfully, but running on either my phone or emulator failed, it was stuch on the splashscreen. By attach it to safari dev tool, I can see below error, localhost:8080 was blocked.

I did add allow-navigation in the config file when upgrade from UIWebView to WKWebView two years ago, and it works fine all the way until now

ionic info followed
Ionic:
ionic (Ionic CLI)  : 4.10.3 (/usr/local/lib/node_modules/ionic)
Ionic Framework    : ionic-angular 3.9.2
@ionic/app-scripts : 3.2.0
Cordova:
cordova (Cordova CLI) : 8.1.2<EMAIL_ADDRESS>Cordova Platforms     : android 6.4.0, ios 5.1.1
Cordova Plugins       : cordova-plugin-ionic-keyboard 2.1.2, cordova-plugin-ionic-webview 1.2.1, (and 14 other plugins)
System:
Android SDK Tools : 26.1.1
ios-deploy        : 1.9.2
NodeJS            : v8.16.0 (/usr/local/bin/node)
npm               : 6.4.1
OS                : macOS Mojave
Xcode             : Xcode 11.3.1 Build version 11C505
full npm outdated info

that url doesn't look good, you are doing something wrong


Not Able to install Data Explorer

Hi,
I am not able to install data explorer, can you please help me?
I am getting below errors and my machine is of windows 64 bit.
PLATFORM VERSION INFO
Windows 			: 6.1.7601.65536 (Win32NT)
Common Language Runtime 	: 4.0.30319.1
System.Deployment.dll 		: 4.0.30319.1 (RTMRel.030319-0100)
clr.dll 			: 4.0.30319.1 (RTMRel.030319-0100)
dfdll.dll 			: 4.0.30319.1 (RTMRel.030319-0100)
dfshim.dll 			: 4.0.31106.0 (Main.031106-0000)
SOURCES
Deployment url			: file:///C:/Users/ADMIN/Downloads/DataExplorer%20(2).application
ERROR SUMMARY
Below is a summary of the errors, details of these errors are listed later in the log.
* Activation of C:\Users\ADMIN\Downloads\DataExplorer (2).application resulted in exception. Following failure messages were detected:
+ Exception reading manifest from file:///C:/Users/ADMIN/Downloads/DataExplorer%20(2).application: the manifest may not be valid or the file could not be opened.
+ Manifest XML signature is not valid.
+ SignatureDescription could not be created for the signature algorithm supplied.
COMPONENT STORE TRANSACTION FAILURE SUMMARY
No transaction error was detected.
WARNINGS
There were no warnings during this operation.
OPERATION PROGRESS STATUS
* [2/3/2017 6:08:52 PM] : Activation of C:\Users\ADMIN\Downloads\DataExplorer (2).application has started.
ERROR DETAILS
Following errors were detected during this operation.
* [2/3/2017 6:08:53 PM] System.Deployment.Application.InvalidDeploymentException (ManifestParse)
- Exception reading manifest from file:///C:/Users/ADMIN/Downloads/DataExplorer%20(2).application: the manifest may not be valid or the file could not be opened.
- Source: System.Deployment
- Stack trace:
at System.Deployment.Application.ManifestReader.FromDocument(String localPath, ManifestType manifestType, Uri sourceUri)
at System.Deployment.Application.DownloadManager.DownloadDeploymentManifestDirectBypass(SubscriptionStore subStore, Uri& sourceUri, TempFile& tempFile, SubscriptionState& subState, IDownloadNotification notification, DownloadOptions options, ServerInformation& serverInformation)
at System.Deployment.Application.DownloadManager.DownloadDeploymentManifestBypass(SubscriptionStore subStore, Uri& sourceUri, TempFile& tempFile, SubscriptionState& subState, IDownloadNotification notification, DownloadOptions options)
at System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation(Uri activationUri, Boolean isShortcut, String textualSubId, String deploymentProviderUrlFromExtension, BrowserSettings browserSettings, String& errorPageUrl)
at System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object state)
--- Inner Exception ---
System.Deployment.Application.InvalidDeploymentException (SignatureValidation)
- Manifest XML signature is not valid.
- Source: System.Deployment
- Stack trace:
at System.Deployment.Application.Manifest.AssemblyManifest.ValidateSignature(Stream s)
at System.Deployment.Application.ManifestReader.FromDocument(String localPath, ManifestType manifestType, Uri sourceUri)
--- Inner Exception ---
System.Security.Cryptography.CryptographicException
- SignatureDescription could not be created for the signature algorithm supplied.
- Source: System.Security
- Stack trace:
at System.Security.Cryptography.Xml.SignedXml.CheckSignedInfo(AsymmetricAlgorithm key)
at System.Security.Cryptography.Xml.SignedXml.CheckSignature(AsymmetricAlgorithm key)
at System.Security.Cryptography.Xml.SignedXml.CheckSignatureReturningKey(AsymmetricAlgorithm& signingKey)
at System.Deployment.Internal.CodeSigning.SignedCmiManifest.Verify(CmiManifestVerifyFlags verifyFlags)
at System.Deployment.Application.Manifest.AssemblyManifest.ValidateSignature(Stream s)
COMPONENT STORE TRANSACTION DETAILS
No transaction information is available.

@Bhanupodila
It looks like there is an issue with the ClickOnce installer.
As a workaround, here is a link to a zip file containing all of the files that get installed on your machine by the installer:
https://dl.dropboxusercontent.com/u/31704806/Data Explorer v0.2.0.zip
You should be able to unzip these files and run "DataExplorer.exe" by double clicking on the file.
I hope this helps!