Error: Failed to staple your application with code: 64 when notarizing on MacOS 13.0 Dev 2

I am trying to notarize the MacOS distributions of my application using the afterSign field for electron-builder, and have been receiving the following error:
Error: Failed to staple your application with code: 64

Usage: stapler staple [-q] [-v] path
        Retrieves a ticket and attaches it to the supported file
        format at path.

Usage: stapler validate [-q] [-v] path
        Validates an existing stapled ticket.

Supported file formats are: UDIF disk images, code-signed executable
bundles, and signed "flat" installer packages.

    at Object.<anonymous> (/Users/rohin/GitHub/parallel2/app/node_modules/electron-notarize/src/staple.ts:16:11)
    at Generator.next (<anonymous>)
    at fulfilled (/Users/rohin/GitHub/parallel2/app/node_modules/electron-notarize/lib/staple.js:4:58)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)

The code I am running in my notarization script is:
const value = await notarize({
    tool: "notarytool",
    appPath: "./dist/mac-arm64/{appName}.app",
    appleId: process.env.APPLE_ID,
    appleIdPassword: process.env.APPLE_ID_PASSWORD,
    teamId: process.env.APPLE_TEAM_ID,
});

The dependency versions are:
"devDependencies": {
    "electron": "^19.0.4",
    "electron-builder": "^23.0.3",
    "electron-notarize": "^1.2.1"
  },

I am running MacOS Ventura 13.0 Developer Beta 2 which could have something to do with it.
Thank you for your help!

i've got same problem

Same problem here

The accepted answer here might explain it (builds made on a beta version of MacOS aren't accepted) https://developer.apple.com/forums/thread/682597

Stapling works just fine if you skip '-v' arg for 'xcrun stapler staple' that is used within notarize() as last step, as there's no option to skip stapling I just added a catch for quick workaround:
try {
  await electronNotarize.notarize({ ... })
} catch (error) {
  if (error.message?.includes('Failed to staple')) {
    spawn(`xcrun`, ['stapler', 'staple', appPath])
  } else {
    throw error
  }
}

Thanks @ragauskl and the final build after notarization and stapling works fine on Monterey and earlier?

Worked for me on Monterey (built on laptop with Ventura and tested on different computer with Monterey), but haven't tested anything older than that.
My guess would be that it should not cause issues as problem is more likely on beta OS with the validation logic/recognising .app file as a valid file format for stapling, and not a problem with stapling itself

Worked for me too! Here's my approach with spawnSync and status-checking and output:
    if (error.message?.includes('Failed to staple')) {
      console.log('RETRY staple as per https://github.com/electron/electron-notarize/issues/109#issuecomment-1213359106');

      const result = spawnSync('xcrun', ['stapler', 'staple', appPath]);
      console.log('STDOUT: ', result.stdout.toString());
      console.log('STDERR: ', result.stderr.toString());

      if (result.status !== 0) {
        throw new Error(
          `RETRY: Failed to staple your application with return status: ${result.status}`,
        );
      }

      console.log('RETRY: staple succeeded');
    } else {
      throw error;
    }

Duplicate of #31

Not working for me
electron-builder 24.6.3
electron 25.0.1
error thown
CloudKit query for hrms.app (2/ab4c9d44868c551e173029342b41d4b38ad024f2) failed due to "Record not found". Could not find base64 encoded ticket in response for 2/ab4c9d44868c551e173029342b41d4b38ad024f2 The staple and validate action failed! Error 65.

JSON Response is: {
records =     (
{
reason = "Record not found";
recordName = "2/2/081ef50fe92295985a30a12db7dd0acc5d0fe377";
serverErrorCode = "NOT_FOUND";
}
);
}
CloudKit query for xyz.app (2/081ef50fe...) failed due to "Record not found".
Could not find base64 encoded ticket in response for 2/081ef50...
The staple and validate action failed! Error 65.
failedTask=build stackTrace=Error: Failed to staple your application with code: 65
`require('dotenv').config();
const { notarize } = require('@electron/notarize');
exports.default = async function notarizing(context) {
const { electronPlatformName, appOutDir } = context;
if (electronPlatformName !== 'darwin') {
return;
}
const appName = context.packager.appInfo.productFilename;
return await notarize({
appBundleId: 'com.bundleId',
appPath: ${appOutDir}/${appName}.app,
appleId: appid,
appleIdPassword: abc,
teamId: 123
});
};`


Add brief clarification on scenario compatibility

What?
This PR adds a brief line explaining what it means if the scenario version is different from the current model version.
Why?
To make the user aware of the possible implications of older scenario versions.
How?
See changes.
Closes #4145

Two points of feedback:

The Dutch translation seems to be missing
I'm not sure this solves #4145, as I see it, this PR only adds a more extensive explanation. What the issue describes is that users do not know if their scenario is being kept up to date or not. I feel the goal of the issue would be to make clear to the user if keep_compatible is on or off. Do you agree @noracato?

To expand on 2. I think that the we have the following options, that we want to clarify to our users:

Keep_compatible is set to false and there has been a Deploy: the scenario is not changed, but there is a risk that it is broken
Keep_compatible is set to true and there has been a Deploy: the scenario may be changed, but there is no risk that it is borken


[NEW ALGORITHM] Anagram Check under String Algorithms

Issue will be closed if:

You mention more than one algorithm. You can create a separate issue for each algorithm once the current one is completed.
You propose an algorithm that is already present or has been mentioned in a previous issue.
You create a new issue without completing your previous issue.

Note: These actions will be taken seriously. Failure to follow the guidelines may result in the immediate closure of your issue.

Name:
Anagram Check
About:
It checks if two strings are anagrams, i.e. if they contain the same characters in the same frequency but in a different order.

Labels:
new algorithm, gssoc-ext, hacktoberfest, level1

Assignees:

[X] Contributor in GSSoC-ext
[X] Want to work on it

assigned


How to get file size?

I think this package https://github.com/johanneslumpe/react-native-fs could help you

or react-native-fetch-blob maybe


[VeriblePreProcessor][2]: Positional arguments to pass defines and inclusion directories.

NOTE: This is a part of the sequentially splitted PRs from PR #1360.
Description:
This PR implements a class that handles positional arguments for the preprocessor tool.
Any of the following positional argument can be passed one or more times.

Argument
Description

<file.sv>
Specifies a SV file to be preprocessed.

+define+<foo>[=<text>]
Defines one or more macros same as  `define foo text

+incdir+<dir>
Specifies the directory to search for files included with  `include "file_name"

Here the first start would of course to rebase to current head.
But since there are a lot of changes that you essentially have to integrate, and this one is a somewhat independent (just the commandline changes), it might be easier if you start a fresh pull request: you just copy over the verilog_project.h, verilog_project.cc and verilog_project_test.cc as well as relevant BUILD rules over from here into a fresh fork from head and create a fresh pull request from that (and abandon this)
Up to you.

That would be easier, I am on it.


[Snyk] Security upgrade ubuntu from rolling to 22.10

This PR was automatically created by Snyk using the credentials of a real user.Keeping your Docker base image up-to-date means you’ll benefit from security fixes in the latest version of your chosen image.
Changes included in this PR

pipeline/Dockerfile

We recommend upgrading to ubuntu:22.10, as this image has only 7 known vulnerabilities. To do this, merge this pull request, then verify your application still works as expected.
Some of the most important vulnerabilities in your base image include:

Severity
Priority Score / 1000
Issue
Exploit Maturity

300
Information Exposure SNYK-UBUNTU2210-GNUTLS28-3319585
No Known Exploit

300
Resource Exhaustion SNYK-UBUNTU2210-SYSTEMD-3148007
No Known Exploit

300
Resource Exhaustion SNYK-UBUNTU2210-SYSTEMD-3148007
No Known Exploit

300
CVE-2022-4415 SNYK-UBUNTU2210-SYSTEMD-3180315
No Known Exploit

514
Out-of-bounds Read SNYK-UBUNTU2210-TAR-3261142
No Known Exploit

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
🛠 Adjust project settings

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Resource Exhaustion

Hello @jakubkrzywda, any reason why it triggers twice? https://github.com/elastisys/compliantkubernetes-apps/pull/1527 :eyes:


quarkus-cxf quickstart

Add codestart for the Quarkus-CXF extension as documented here:
https://quarkus.io/guides/extension-codestart#writing-an-extension-codestart-in-the-quarkiverse-or-standalone

Hi @gastaldi - are you aware of any Quarkiverse extension leveraging this at the moment?
I tried searching but not sure if I'm using the right keywords, so just wanted to check with you.

Thanks George, will try out the codestart to see how it works - I came to the conclusion that no other Quarkiverse projects are using it yet.  Will keep you both posted in case of any issues.

There is not Quarkiverse extension with Codestart yet but it's possible. To add a codestart the first thing is to start from an empty code.quarkus.io project and add the code you would like to see as codestart. It should be really simple and made to help developer start coding (It shouldn't contain much example just stubbing).

Gotcha, thanks @ia3andy.  Unfortunately, even the most minimal starter code for this extension will need a fair number of supporting example classes.  We'll likely also need a plugin (like this) defined in the starter pom.xml ... I didn't see any way to integrate that into a codestart.  Given these factors, I am going to skip creating a codestart for the extension and give some thought to alternative options.
Also just wanted to check with you both, we recently introduced a modular structure in the project, so we will have multiple maven modules getting published for the next release - I would like to ensure that only one (the core module) gets published to code.quarkus.io, and remaining supporting modules get skipped ... please advise on how I can ensure that; is it possible?

You need to make sure they are unlisted: true in the metadata. example:
https://github.com/quarkusio/quarkus/blob/main/extensions/arc/runtime/src/main/resources/META-INF/quarkus-extension.yaml#L15

Regarding the example code,
@gastaldi @gsmet do we have a quickstart equivalent for the Quarkiverse?
else, I would suggest creating a quickstart example app in the repository and reference it from the doc. We could even consider creating a github action to generate it automatically using the codestarts system on new versions (which in this case would allow editing the pom.xml and use example code).
cc @maxandersen

Ah - one downside is to not be able to have the QuickStart refer main.
@gastaldi maybe we should opt for making a quickstart repo per extension that wants it ?

@maxandersen we could also add it as a release item from GH actions which gets generated on release using codestarts.

Generated ? To where ?

As a versioned zip? I guess that could work.

Thanks so much all, greatly appreciate your inputs and feedback.  I will explore the quickstart route for now.
@gastaldi Please let us know in case you have anything in mind for a Quarkiverse level quickstart, otherwise if it makes more sense, I will try to include it in the extension repository itself.

@gastaldi Please let us know in case you have anything in mind for a Quarkiverse level quickstart, otherwise if it makes more sense, I will try to include it in the extension repository itself.

I don't know what a Quarkiverse level quickstart means, but I'd recommend you to include in the extension repository itself 😉

Apologies, I meant to say Quarkiverse level quickstart repo, I meant something like this:
https://github.com/quarkusio/quarkus-quickstarts
Will include in the extension for now!  Thanks @gastaldi.

On further thought, I don't see a clean way to have a quickstart as part of the extension repo, as @maxandersen already pointed out previously.  I may just end up creating a quickstart repo under my personal account, just to keep things clean.  Closing this issue for now, thanks once again all.

I may be missing something, but isn't a quickstart/codestart another Maven module?

The issue as I see it, is that the extension leverages this BOM dependency:
https://github.com/quarkiverse/quarkus-cxf/blob/master/pom.xml#L76-L82
A regular Quarkus app / quickstart will have slightly different coordinates for its BOM import, so it'll have to live as an independent project, and not a Maven submodule like docs, core, or any of the others in the extension.

Sorry, but I am still not following. AFAIR a codestart only declares a set of instructions of what needs to be changed in a project in order to end up with a working application. I'd appreciate if we could discuss that further to understand why a maven submodule wouldn't work.
Last but not least Quickstart (a fully working application) != Codestart so I am assuming you mean the latter

So, the original intent for this issue was to do a codestart.  After gathering some feedback, I explained here, that a codestart won't work for this extension.  A quickstart was suggested here, so that's what I've been exploring and trying to discuss in my comments today.

In this case I'd suggest making it available in https://github.com/quarkusio/quarkus-quickstarts, as it seems to be the central place for all quickstarts.
I personally don't like to come up with a quarkiverse-quickstarts as it would be another repository to version and maintain, but we can always discuss that.
Any thoughts @quarkiverse/quarkiverse-owners?

-1.
It is not a good idea to put all quarkiverse QuickStarts into the central QuickStarts. Since that repo is used for quarkus core platform release and if it can't upgrade we are stuck.
Better options is imo independent QuickStart module in quarkiverse repos or qucikstart per quarkiverse repo in the org.
A main point of quarkiverse is they should be possible to release independently thus just like docs the QuickStarts should not end up in a central repo imo.

Better options is imo independent QuickStart module in quarkiverse repos or qucikstart per quarkiverse repo in the org.

Not sure what you mean with Quickstart per quarkiverse repo x independent Quickstart module in the quarkiverse repository, they look the same to me, but I'm still on vacation so my brain may be somewhere else 😉

A main point of quarkiverse is they should be possible to release independently thus just like docs the QuickStarts should not end up in a central repo imo.

Right, in this case an independent quickstart module in the extension repository is a better idea IMHO

@gastaldi Hope you are enjoying your vacation, and sorry for the interruptions!
I believe we're in agreement that an independent quickstart module in the extension repository itself is the best way forward, ie. the quickstart module won't be a submodule like docs or core as already explained previously.
If we do take this approach, would it be possible to update the release process to create a zip artifact containing the quickstart and publish it as a release asset?  Maybe we can use a generic quickstarts folder name, just like docs, so that any Quarkiverse extension developer can leverage it?  Just a thought, that I believe @ia3andy expressed as well.

I created an issue for this: https://github.com/quarkusio/quarkus/issues/24870

Good day everyone! Why this issue has still opened ? I think Quarkus-CXF has comprehension documentation now.
There is no problem to start from scratch of it.

this isn't about documentation per-say its about having a quarkus-cxf include a quickstart to get started even easier. like resteasy extension  setup a hello endpoint when you use code quarkus or the cli; similar quarkus-cxf could provide the initial setup for a hello endpoint based on cxf.

updated title to reflect the actual ask.


See update conflicts from home page

See the story in the release criteria.

Tested with Success!

Tested with Success!

let's knock the font-size from 16 to 14px and take the padding down from 2px10px to 2px7px.


Cuda-segmentation: NvMapReserveOp failed on Jetson Xavier 32gb

Hello.
Thank you for efforts in providing CUDA-optimized PCL algorithms.
With the Cuda-segmentation demo, I get an CUDA error on the cudaExtractCluster part, while the cudaSegmentation part runs fine.
Other demos such as cuda-filter runs fine.
NvMapReserveOp 0x80000003 failed [22]
NvMapReserveOp 0x80000001 failed [22]
NvMapReserveOp 0x80000000 failed [22]
Do you know why this happens?
And can you help me use the Cuda-segmentation?
Thank you!
Jetson AGX Xavier Developer Kit
PCL 1.8
CUDA 10.2

Here is the .pcd file:
https://www.filemail.com/d/hkuwxjclxsdcbmu
Please let me know if the link has expired, then I'll upload it again.


[NEW ALGORITHM] Matrix Determinant

Name:  Determinant of a square matrix
About:
This issue proposes adding an algorithm to compute the determinant of a square matrix. The algorithm will handle n x n matrices and will use a recursive approach for cofactor expansion. This feature can help in solving matrix-related problems such as finding matrix inverses or solving systems of linear equations
The determinant of a matrix is a scalar value that is computed from the elements of a square matrix and has important properties in linear algebra, particularly related to the invertibility of matrices and the solutions of systems of linear equations.
Key Points:
Square Matrices Only: The determinant is defined only for square matrices (i.e., matrices with the same number of rows and columns).

Labels:
new algorithm, gssoc-ext, hacktoberfest, level1

Assignees:

[x] Contributor in GSSoC-ext
[x] Want to work on it

@PrasanBora I would like to contribute to this repo. Please assign me this issue. Thanks

@pankaj-bind Done u can merge


Find-PSResource should tell what platforms a resource supports

Summary of the new feature / enhancement
Find-PSResource should tell what platforms a resource supports.

Windows only?
Unix only?

Could a module work on MacOS but not Linux?

All platforms that PowerShell supports?

There does not seem to be a standardized way to tell if an object obtained with Find-PSResource can be installed and used on Unix.
The PSEdition visible in PowerShell Gallery seems to be present in the tags:

PSEdition is set with tags PSEdition_<edition>, example PSEdition_Core and PSEdition_Desktop with Az.Accounts.

(Find-PSResource -Type 'Module' -Repository 'PSGallery' -Name 'Az.Accounts' -ErrorAction 'SilentlyContinue').Tags.Where{$_.StartsWith('PSEdition_')}
https://www.powershellgallery.com/packages/az.accounts

If PSEdition_Core is present it does not neccessarily mean it supports Unix, right?
Current info from Find-PSResource
Here's the output of:
Find-PSResource -Type 'Module' -Name 'Az.Accounts' -Repository 'PSGallery' | ConvertTo-Json -Depth 10 | clip

Click to view
{
  "AdditionalMetadata": {
    "NormalizedVersion": "2.15.1"
  },
  "Author": "Microsoft Corporation",
  "CompanyName": "Microsoft Corporation",
  "Copyright": "Microsoft Corporation. All rights reserved.",
  "Dependencies": [],
  "Description": "Microsoft Azure PowerShell - Accounts credential management cmdlets for Azure Resource Manager in Windows PowerShell and PowerShell Core.\r\n\r\nFor more information on account credential management, please visit the following: https://learn.microsoft.com/powershell/azure/authenticate-azureps",
  "IconUri": null,
  "Includes": {
    "Cmdlet": [
      "Disable-AzDataCollection",
      "Disable-AzContextAutosave",
      "Enable-AzDataCollection",
      "Enable-AzContextAutosave",
      "Remove-AzEnvironment",
      "Get-AzEnvironment",
      "Set-AzEnvironment",
      "Add-AzEnvironment",
      "Get-AzSubscription",
      "Connect-AzAccount",
      "Get-AzContext",
      "Set-AzContext",
      "Import-AzContext",
      "Save-AzContext",
      "Get-AzTenant",
      "Send-Feedback",
      "Resolve-AzError",
      "Select-AzContext",
      "Rename-AzContext",
      "Remove-AzContext",
      "Clear-AzContext",
      "Disconnect-AzAccount",
      "Get-AzContextAutosaveSetting",
      "Set-AzDefault",
      "Get-AzDefault",
      "Clear-AzDefault",
      "Register-AzModule",
      "Enable-AzureRmAlias",
      "Disable-AzureRmAlias",
      "Uninstall-AzureRm",
      "Invoke-AzRestMethod",
      "Get-AzAccessToken",
      "Open-AzSurveyLink",
      "Get-AzConfig",
      "Update-AzConfig",
      "Clear-AzConfig",
      "Export-AzConfig",
      "Import-AzConfig"
    ],
    "Command": [
      "Disable-AzDataCollection",
      "Disable-AzContextAutosave",
      "Enable-AzDataCollection",
      "Enable-AzContextAutosave",
      "Remove-AzEnvironment",
      "Get-AzEnvironment",
      "Set-AzEnvironment",
      "Add-AzEnvironment",
      "Get-AzSubscription",
      "Connect-AzAccount",
      "Get-AzContext",
      "Set-AzContext",
      "Import-AzContext",
      "Save-AzContext",
      "Get-AzTenant",
      "Send-Feedback",
      "Resolve-AzError",
      "Select-AzContext",
      "Rename-AzContext",
      "Remove-AzContext",
      "Clear-AzContext",
      "Disconnect-AzAccount",
      "Get-AzContextAutosaveSetting",
      "Set-AzDefault",
      "Get-AzDefault",
      "Clear-AzDefault",
      "Register-AzModule",
      "Enable-AzureRmAlias",
      "Disable-AzureRmAlias",
      "Uninstall-AzureRm",
      "Invoke-AzRestMethod",
      "Get-AzAccessToken",
      "Open-AzSurveyLink",
      "Get-AzConfig",
      "Update-AzConfig",
      "Clear-AzConfig",
      "Export-AzConfig",
      "Import-AzConfig"
    ],
    "DscResource": [],
    "Function": null,
    "RoleCapability": null,
    "Workflow": null
  },
  "InstalledDate": null,
  "InstalledLocation": "",
  "IsPrerelease": false,
  "LicenseUri": "https://aka.ms/azps-license",
  "Name": "Az.Accounts",
  "Prerelease": "",
  "ProjectUri": "https://github.com/Azure/azure-powershell",
  "PublishedDate": "2024-02-06T01:38:46.463",
  "ReleaseNotes": "* Upgraded the reference of Azure PowerShell Common to 1.3.90-preview.\r\n* Upgraded Azure.Identity to 1.10.3 [#23018].\r\n  - Renamed token cache from 'msal.cache' to 'msal.cache.cae' or 'masl.cache.nocae'.\r\n* Enabled Continue Access Evaluation (CAE) for all Service Principals login methods.\r\n* Supported signing in with Microsoft Account (MSA) via Web Account Manager (WAM). Enable it by 'Set-AzConfig -EnableLoginByWam True'.\r\n* Adjusted output format to be more user-friendly for 'Get-AzContext/Tenant/Subscription' and 'Invoke-AzRestMethod'.\r\n* Fixed the multiple 'x-ms-unique-id' values issue.",
  "Repository": "PSGallery",
  "RepositorySourceLocation": "https://www.powershellgallery.com/api/v2",
  "Tags": [
    "Azure",
    "ResourceManager",
    "ARM",
    "Accounts",
    "Authentication",
    "Environment",
    "Subscription",
    "PSModule",
    "PSEdition_Core",
    "PSEdition_Desktop",
    "PSCmdlet_Disable-AzDataCollection",
    "PSCommand_Disable-AzDataCollection",
    "PSCmdlet_Disable-AzContextAutosave",
    "PSCommand_Disable-AzContextAutosave",
    "PSCmdlet_Enable-AzDataCollection",
    "PSCommand_Enable-AzDataCollection",
    "PSCmdlet_Enable-AzContextAutosave",
    "PSCommand_Enable-AzContextAutosave",
    "PSCmdlet_Remove-AzEnvironment",
    "PSCommand_Remove-AzEnvironment",
    "PSCmdlet_Get-AzEnvironment",
    "PSCommand_Get-AzEnvironment",
    "PSCmdlet_Set-AzEnvironment",
    "PSCommand_Set-AzEnvironment",
    "PSCmdlet_Add-AzEnvironment",
    "PSCommand_Add-AzEnvironment",
    "PSCmdlet_Get-AzSubscription",
    "PSCommand_Get-AzSubscription",
    "PSCmdlet_Connect-AzAccount",
    "PSCommand_Connect-AzAccount",
    "PSCmdlet_Get-AzContext",
    "PSCommand_Get-AzContext",
    "PSCmdlet_Set-AzContext",
    "PSCommand_Set-AzContext",
    "PSCmdlet_Import-AzContext",
    "PSCommand_Import-AzContext",
    "PSCmdlet_Save-AzContext",
    "PSCommand_Save-AzContext",
    "PSCmdlet_Get-AzTenant",
    "PSCommand_Get-AzTenant",
    "PSCmdlet_Send-Feedback",
    "PSCommand_Send-Feedback",
    "PSCmdlet_Resolve-AzError",
    "PSCommand_Resolve-AzError",
    "PSCmdlet_Select-AzContext",
    "PSCommand_Select-AzContext",
    "PSCmdlet_Rename-AzContext",
    "PSCommand_Rename-AzContext",
    "PSCmdlet_Remove-AzContext",
    "PSCommand_Remove-AzContext",
    "PSCmdlet_Clear-AzContext",
    "PSCommand_Clear-AzContext",
    "PSCmdlet_Disconnect-AzAccount",
    "PSCommand_Disconnect-AzAccount",
    "PSCmdlet_Get-AzContextAutosaveSetting",
    "PSCommand_Get-AzContextAutosaveSetting",
    "PSCmdlet_Set-AzDefault",
    "PSCommand_Set-AzDefault",
    "PSCmdlet_Get-AzDefault",
    "PSCommand_Get-AzDefault",
    "PSCmdlet_Clear-AzDefault",
    "PSCommand_Clear-AzDefault",
    "PSCmdlet_Register-AzModule",
    "PSCommand_Register-AzModule",
    "PSCmdlet_Enable-AzureRmAlias",
    "PSCommand_Enable-AzureRmAlias",
    "PSCmdlet_Disable-AzureRmAlias",
    "PSCommand_Disable-AzureRmAlias",
    "PSCmdlet_Uninstall-AzureRm",
    "PSCommand_Uninstall-AzureRm",
    "PSCmdlet_Invoke-AzRestMethod",
    "PSCommand_Invoke-AzRestMethod",
    "PSCmdlet_Get-AzAccessToken",
    "PSCommand_Get-AzAccessToken",
    "PSCmdlet_Open-AzSurveyLink",
    "PSCommand_Open-AzSurveyLink",
    "PSCmdlet_Get-AzConfig",
    "PSCommand_Get-AzConfig",
    "PSCmdlet_Update-AzConfig",
    "PSCommand_Update-AzConfig",
    "PSCmdlet_Clear-AzConfig",
    "PSCommand_Clear-AzConfig",
    "PSCmdlet_Export-AzConfig",
    "PSCommand_Export-AzConfig",
    "PSCmdlet_Import-AzConfig",
    "PSCommand_Import-AzConfig",
    "PSIncludes_Cmdlet"
  ],
  "Type": 1,
  "UpdatedDate": null,
  "Version": {
    "Major": 2,
    "Minor": 15,
    "Build": 1,
    "Revision": -1,
    "MajorRevision": -1,
    "MinorRevision": -1
  }
}

Proposed technical implementation details (optional)
No response

It's a fair point that just because a module is written for PSCore doesn't mean it supports all platforms. For instance, a module might be a wrapper to a windows-only or linux-only binary.
The tricky thing is how to make this extensible for future platforms that we don't even know exist yet.


Update circleci mysql key

This is finally passing circle ci. I'd consider this a trivial change, so only adding one reviewer (@ximinez)

Closing this, we no longer use circle ci.


confinement: fix assert for serviceConfig.ProtectSystem

Motivation for this change
serviceConfig.ProtectSystem is usually a string so if set, the assert
itself would error out leaving no useable trace
(I had this error upgrading to 20.09, good luck finding what service changed!)
  # nixos-rebuild switch --show-trace
  building Nix...
  building the system configuration...
  error: while evaluating the attribute 'config.system.build.toplevel' at /nix/var/nix/profiles/per-user/root/channels/nixos/nixos/modules/system/activation/top-level.nix:293:5:
  while evaluating 'foldr' at /nix/var/nix/profiles/per-user/root/channels/nixos/lib/lists.nix:52:20, called from /nix/var/nix/profiles/per-user/root/channels/nixos/nixos/modules/system/activation/top-level.nix:128:12:
  while evaluating 'fold'' at /nix/var/nix/profiles/per-user/root/channels/nixos/lib/lists.nix:55:15, called from /nix/var/nix/profiles/per-user/root/channels/nixos/lib/lists.nix:59:8:
  while evaluating anonymous function at /nix/var/nix/profiles/per-user/root/channels/nixos/nixos/modules/system/activation/top-level.nix:121:50, called from undefined position:
  while evaluating the attribute 'assertion' at /nix/var/nix/profiles/per-user/root/channels/nixos/nixos/modules/security/systemd-confinement.nix:163:7:
  value is a string while a Boolean was expected

Things done
Fix the check to give a sensible assert message instead; the attribute
should either be not set or false bool to pass.

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

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

cc @aszlig @flokli

Can you please rebase/squash the commits?

Sorry, wasn't sure what you'd want from that -- done.
Thanks for the explanation!


Update README.md

Thanks, good idea to document it! One small question before I merge. :)

You were right. I don't use global packages myself, so I just assumed it works. I also had a look at the jest documentation and noticed they suggest to install jest locally, so I changed the example to reflect that.
I tested both the jest and mocha commands out and they work now.

Thanks!


[1.2] I want to make chip-tool as an OTA provider. But I am facing error related to ACL.

Reproduction steps
For generating chip-tool as a OTA provider I have enabled OTA-provider cluster as a server from ZAP tool. So the process would be like below
(1) Commission OTA requestor from chip-tool
(2) Announce OTA provider(chip-tool) for presence. For this step I knew chip-tool node ID would be 112233.
(3) According to my knowledge if only chip-tool and ota requestor are involved, there would be no role of access control list(ACL) , what should be ACL cluster in chip-tool(client/server/both)?
Now I am facing only one error here in the function ProcessCommandDataIB (/src/app/CommandHandler.cpp). Here I am getting error log like this "acl err code is src/access/AccessControl.cpp:314: CHIP Error 0x00000003: Incorrect state"
  {        ChipLogDetail(DataManagement,"cluster %x and endpoint %d\n",concretePath.mClusterId,concretePath.mEndpointId);     Access::SubjectDescriptor subjectDescriptor = GetSubjectDescriptor();     Access::RequestPath requestPath{ .cluster = concretePath.mClusterId, .endpoint = concretePath.mEndpointId };     Access::Privilege requestPrivilege = RequiredPrivilege::ForInvokeCommand(concretePath);     err                                = Access::GetAccessControl().Check(subjectDescriptor, requestPath, requestPrivilege);     ChipLogError(DataManagement, "acl err code is %" CHIP_ERROR_FORMAT, err.Format());     if (err != CHIP_NO_ERROR)     {         if (err != CHIP_ERROR_ACCESS_DENIED)         {            // ChipLogDetail(DataManagement,"[MS::: failed concrete path %s] \n",concretePath);             return FallibleAddStatus(concretePath, Status::Failure) != CHIP_NO_ERROR ? Status::Failure : Status::Success;         }          ChipLogDetail(DataManagement,"TODO wildcard\n");         // TODO: when wildcard invokes are supported, handle them to discard rather than fail with status         return FallibleAddStatus(concretePath, Status::UnsupportedAccess) != CHIP_NO_ERROR ? Status::Failure : Status::Success;     }  }
why this is showing incorrect state, as we are as a matter root node so it has all the privilege?
Bug prevalence
none
GitHub hash of the SDK that was being used
https://github.com/project-chip/connectedhomeip/tree/v<IP_ADDRESS>
Platform
IMX8
Platform Version(s)
No response
Type
Test Improvement
Anything else?
No response

According to my knowledge if only chip-tool and ota requestor are involved, there would be no role of access control list

That's not correct.  ACLs are always enforced for server clusters.  For chip-tool there is no useful access control implementation set up, apparently, so the access control checks error out and "fail closed" (that is, no access allowed if there is an error checking access).
If you want chip-tool to support server clusters, you will need to fix it to provide an access control implementation.

./chip-tool accesscontrol write acl '[{"fabricIndex": 1, "privilege": 5, "authMode": 2, "subjects": [112233], "targets": null}, {"fabricIndex": 1, "privilege": 3, "authMode": 2, "subjects": null, "targets": [{"cluster": 41, "endpoint": null, "deviceType": null}]}]'  0
I want to assign privileges to the chip-tool in my case(chip-tool+ota-provider) 112233. How can I do that?

"write acl" will write ACLs to the other device.  You are trying to set up ACLs on chip-tool.  It does not have a way to do that right now; you will need code changes for that.


Remove old getResources API

This won't happen for a few months. Just bookmarking it for v3

Closing. v3 won't be for some time. 2.5 is the new hotness!


DNS servers are not displayed and parsed correctly if more than one is defined

Hello!
I found a bug: the DNS servers are not displayed correctly if there are more than one defined on the Settings page. It is also impossible to save them.
Workaround: put a new line between the servers and save.
Steps to reproduce:

Put more than one correct DNS server onto Settings -> General page.
Save the edits.
Log out and log back in.
Go to Settings -> General page and observe the issue: the servers are displayed in one line without any separators. It is also impossible to save this configuration until you put a new like between them.

All done


Double clicking on an unsaved signal, does not open script

Godot version:
3.1
OS/device including version:
OS X, High Sierra
Issue description:
Does not open a nodes, Signal script if you double click on newly created method. You need to save the script first.
Steps to reproduce:

Add a Button to a Scene and a new Script. Save.
Add a a new Signal, e.g. _on_Button_pressed(), to the Button which will open the Script and show the new method.
Click on 2D to hide the Script
Now go back to the Button Signal list and double click on the newly created signal  _on_Button_pressed() name.
This will not open the Script and show the _on_pressed method as it should. You need to save it first it seems.

Still valid in 3.2.2 rc2

Not valid in 3.5 and 4.0 alpha. Should I close it.

If it's really fixed then yes.


Whatsapp and facebook on ios 8

Hi Eddy,
We use your plugin in our app and it works perfectly on android. But on ios8 we only get the default options like mail and ibooks. Do you know of this problem and by change do you know a solution to this problem?
So in short we are looking for a way to share to (mainly) whatsapp and facebook on IOS8.
Thanks in advance

Dupe of #255


[Android Agent] Incorrect last sync time

Android agent showing incorrect last synced time when open up the agent though background sync done correctly. Correct time is showing after next polling.

Fixed with PR https://github.com/wso2/cdmf-agent-android/pull/84


waitUntil function throwing error in Firefox

Welcome! Please use this template for reporting bugs or requesting features. For questions about using Workbox, the best place to ask is Stack Overflow, tagged with [workbox]: https://stackoverflow.com/questions/ask?tags=workbox
Library Affected:
workbox-precaching
Browser & Platform:
Works in:

Chrome 70.0 in MacOS
Safari 12.0

Fails in:

Firefox 63.0.1 (64-bit) in MacOS
Firefox Developer Edition (latest actual version)  in MacOS

Issue or Feature Request Description:
When registering a service worker in Firefox, it fails with error InvalidStateError: An attempt was made to use an object that is not, or is no longer, usable.
It seems to fail in line 1018 in workbox-precaching.dev.js, in the waitUntil method:
self.addEventListener('activate', event => {
      event.waitUntil(precacheController.activate({
        event,
        plugins
      }));
    });

I thought that the issue would be the local testing env, but in a production ready system with https and everything setup fails in the same place.
Seems to be some kind of different logic with the waitUntil function in Firefox. I also tried to do some research on this kind of issue but I haven't been able to find anything.
I was able to reproduce with just these lines of code (even though my real logic is a bit more complex):
self.addEventListener('activate', event => {
  const test = async () => {
    return true;
  }
  event.waitUntil(test());
});

Also, I thought it could had been related to the piece of code I added in my service worker to handle updates, and some other custom logic, but I commented it out and seems to keep on failing just with the previous lines. However, it runs in all browsers but Firefox for some reason... I'm not sure though if this is an error in Firefox or it's just in workbox.
My guess is that there is a conflict is triggering the waitUntil in different parts of the code at the same time (though not sure).
Note that this code is inspired in the example given by Mozilla in their documentation about the waitUntil function: https://developer.mozilla.org/en-US/docs/Web/API/ExtendableEvent/waitUntil
Also, this bug can be reproduced in https://dashboardv2.bitphy.es (in this public reproduction, note that there is some extra code, but, I was able to reproduce it just with the lines given before)

Apologies that you're running into this issue.
I can reproduce it when visiting https://dashboardv2.bitphy.es using the current Firefox Nightly 65.0a1, but I have not been able to reproduce the same error when visiting other web apps that also use Workbox's precaching (e.g. https://so-pwa.firebaseapp.com, https://jeffy.info).
I also have not been able to reproduce the issue when using your simple reproduction steps:
self.addEventListener('activate', event => {
  const test = async () => {
    return true;
  }
  event.waitUntil(test());
});

(Deployed live at https://glamorous-snowflake.glitch.me/)
So... I understand that the issue is real, but it is not clear that is a widespread issue, vs.  a smaller issue in Firefox due to something particular about your service worker's logic.
I really do want to get as close to a simplified reproduction step as possible, and I'm curious whether you can modify your initial reproduction example by "remix"ing https://glitch.com/edit/#!/glamorous-snowflake?path=public/sw.js:6:3 and get something that exhibits the error deployed.

I'm closing this given the lack of updates.
If this remains a problem for you, could you please follow the suggestions mentioned in the previous response and let us know?


@material-ui/styles RTL support

Does the new ThemeProvider have full RTL support?

[x] This is not a v0.x issue.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior 🤔
With RTL enabled TextFileds, including labels and placeholders, should be right aligned.
Current Behavior 😯
TextFileds seem left aligned

Steps to Reproduce 🕹
https://codesandbox.io/s/wq787oxnml
Your Environment 🌎

Tech
Version

Material-UI
v3.9.0

Material-UI styles
3.0.0-alpha.8

React
16.8.0-alpha.1

@mbrevda Yes, it does:
import "./bootstrap.js";
import React from "react";
import ReactDOM from "react-dom";
import { createMuiTheme } from "@material-ui/core/styles";
import { StylesProvider, ThemeProvider } from "@material-ui/styles";
import { create } from "jss";
import rtl from "jss-rtl";
import { jssPreset } from "@material-ui/core/styles";
import Demo from "./demo";

const jss = create({ plugins: [...jssPreset().plugins, rtl()] });
const theme = createMuiTheme({
  typography: { useNextVariants: true },
  direction: "rtl"
});

ReactDOM.render(
  <StylesProvider jss={jss}>
    <ThemeProvider theme={theme}>
      <Demo />
    </ThemeProvider>
  </StylesProvider>,
  document.querySelector("#root")
);

https://codesandbox.io/s/kwowy9278v

We will have to upgrade the RTL guide documentation with v4.

Hi @oliviertassinari, can you test this example again? It seems not working now.
Thanks.

@TrueMoein I have updated my original comment to reflect how it should be done with v4, latest.

Hi @oliviertassinari did you test your solution with typescript cause i get this error:
Argument of type '{ plugins: (Plugin | { onProcessStyle(style: any, rule: any, sheet: any): any; })[]; }' is not assignable to parameter of type 'Partial'.
Types of property 'plugins' are incompatible.
Type '(Plugin | { onProcessStyle(style: any, rule: any, sheet: any): any; })[]' is not assignable to type 'readonly JSSPlugin[]'.
Type 'Plugin | { onProcessStyle(style: any, rule: any, sheet: any): any; }' is not assignable to type 'JSSPlugin'.
Type 'Plugin' is not assignable to type 'JSSPlugin'.
Index signature is missing in type 'Plugin'
when i try to declare jss const. thanks

You saved my life!!!!

if you don't want to make the whole project right to left and you want to be able to change the direction dynamically, I have made a component to wrap your elements with it and make them direction sensitive, you can find it here:
https://github.com/sadeghesfahani/direction-sensitive-material-ui


[Synapse monitoring] Upgrade rollup to v3

Packages impacted by this PR
@azure/synapse-monitoring
Issues associated with this PR
https://github.com/Azure/azure-sdk-for-js/pull/27285
Describe the problem that is addressed by this PR
Upgrading rollup to v3 and fixing compilation, bundling, and testing issues.
What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?
N/A
Are there test cases added in this PR? (If not, why?)
N/A
Provide a list of related PRs (if any)
N/A
Command used to generate this PR:**(Applicable only to SDK release request PRs)
Checklists

[x] Added impacted package name to the issue description
[ ] Does this PR needs any fixes in the SDK Generator?** (If so, create an Issue in the Autorest/typescript repository and link it here)
[ ] Added a changelog (if necessary)

Does it have existing recordings? Not seeing deletions in this PR.

Good point, deleted in https://github.com/Azure/azure-sdk-for-js/pull/27372/commits/604086502573811d3bdd3d610a7d36ee08affe79

The source looks generated by @joheredi. Not sure if we want to format them.

I was on the fence but I guess no harm in not formatting, reverted in https://github.com/Azure/azure-sdk-for-js/pull/27372/commits/ba758d7d8c9af6be82ee0c8f6c9814f9c5dc38a2

API change check
API changes are not detected in this pull request.


Exception when def size is greater than Integer.MAX_VALUE

When a def has a size larger than that of a max integer, an exception is thrown during parsing of the data. An example test which triggers this can be found here.
It was a bit unexpected, with the knowledge that Metal is lazy, and the fact that we never read the resulting data but only use the slice offset and length. The reason is that the ByteStreamSource implementation always converts the BigInteger length to an int using intValueExact. It is of course related with the fact that the reading part of the Source API returns a byte array (as do parts within Metal, all the way back to Value).

It looks like the actual BigInteger conversion can be pushed further down so that it's more lazy and a scenario such as this can be made to work.


More WDS to use vtprotobuf

Similar to envoy types, use vtprotobuf for WDS which we frequently marshal on the hotpath.
old-equals  794.6 ns/op
vt-equals   16.25 ns/op

old-marshal 1014 ns/op
vt-marshal  318.2 ns/op

@howardjohn: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

gencheck_istio
efbf1ea69f9e379ea6630b79cfaee562cf6dc3bd
link
true
/test gencheck

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

/retest

@howardjohn: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

gencheck_istio
efbf1ea69f9e379ea6630b79cfaee562cf6dc3bd
link
true
/test gencheck

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

@howardjohn: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

gencheck_istio
efbf1ea69f9e379ea6630b79cfaee562cf6dc3bd
link
true
/test gencheck

integ-ambient_istio
efbf1ea69f9e379ea6630b79cfaee562cf6dc3bd
link
true
/test integ-ambient

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

+1 to this, but want to try and make sure we don't run into another instance of #53807

A fuzz test can reduce the poitential issue

what exactly do you suggest we fuzz? The virtual service issue was about creating an invalid proto struct - I am not sure how you could fuzz that.
The virtual service issue cannot happen at all anyways as there are no optional oneof types in the workload proto - that was the cause of the issue (by Istio code incorrectly setting the one of field - not due to a bug in vtprotobuf).
I can fuzz just marshaling a random workload if you want but there are already fuzz tests in vtproto itself and we are already using it for every xds type so it feels a bit wasteful

I mean fuzz workload

@howardjohn: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-ambient_istio
efbf1ea69f9e379ea6630b79cfaee562cf6dc3bd
link
true
/test integ-ambient

gencheck_istio
c8f3d30768cbc394bedfc523e0f8c90397b375ec
link
true
/test gencheck

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

OK I added a fuzzer and ran it 7337209 times locally without issues

@howardjohn: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-ambient_istio
c460301442d24e8d5637652e282e62b8d39297c4
link
true
/test integ-ambient

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

@howardjohn: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-ambient_istio
c460301442d24e8d5637652e282e62b8d39297c4
link
true
/test integ-ambient

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.