Cannot run a Calculator sample

Environment

yarn - 1.9.4

node - 12.17.0

npm - 6.14.5

"react": "16.9.0",

"react-native": "0.61.5",

"react-native-windows": "^0.61.0-0"

Building configuration

Target Platform Version(s): 10.0.18362.0
Target Device(s): Desktop
Visual Studio Version: Visual Studio 2019, Visual Studio 2017
Build Configuration: Debug

Little bit of description
There was an exact same issue. But I tried the same steps to fix it and it didn't help. By the way, a problem with the path too long(260 character limit) still there. I don't know if that only reproduces for me. But unlike @ngducnghia I don't have a problem with a temporary certificate if that helps :grimacing:
Steps to Reproduce

Cloned repository
Installed dependencies
Tried to run it in Visual Studio 2019

Actual Behaviour

react-native run-windows --logging
Searching for MSBuild version 16.0
Found MSBuild v16.0 at C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin (16.5.29920.165)
√ Found MSBuild v16.0 at C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin (16.5.29920.165)
Searching for MSBuild version 15.0
Found MSBuild v15.0 at C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin (15.9.28307.1064)
√ Found MSBuild v15.0 at C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin (15.9.28307.1064)
Searching for MSBuild version 14.0
Searching for MSBuild version 12.0
Searching for MSBuild version 4.0
Restoring NuGets
C:\Users\pak\AppData\Local\Temp\nuget.4.9.2.exe
MSBuild auto-detection: using msbuild version '<IP_ADDRESS>03' from 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\bin'.
All packages listed in packages.config are already installed.
√ Restoring NuGets
Searching for MSBuild version 16.0
Found MSBuild v16.0 at C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin (16.5.29920.165)
√ Found MSBuild v16.0 at C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin (16.5.29920.165)
Searching for MSBuild version 15.0
Found MSBuild v15.0 at C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin (15.9.28307.1064)
√ Found MSBuild v15.0 at C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin (15.9.28307.1064)
Searching for MSBuild version 14.0
Searching for MSBuild version 12.0
Searching for MSBuild version 4.0
Found Solution: C:/Users/pak/Documents/react-native-windows-samples/samples/Calculator/windows/Calculator.sln
√ Found Solution: C:/Users/pak/Documents/react-native-windows-samples/samples/Calculator/windows/Calculator.sln
Build configuration: Debug
i Build configuration: Debug
Build platform: x86
i Build platform: x86
Running MSBuild with args /clp:NoSummary;NoItemAndPropertyList;Verbosity=normal /nologo /p:Configuration=Debug /p:Platform=x86 /p:AppxBundle=Never /p:PlatformToolset=v141 /p:VisualStudioVersion=16.0 /bl
- Building Solution
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\msbuild.exe /nologo /bl /clp:NoSummary;NoItemAndPropertyList;Verbosity=normal /p:Configuration=Debug /p:Platform=x86 /p:AppxBundle=Never /p:PlatformToolset=v141 /p:VisualStudioVersion=16.0 C:/Users/pak/Documents/react-native-windows-samples/samples/Calculator/windows/Calculator.sln
Building the projects in this solution one at a time. To enable parallel build, please add the "-m" switch.
Build started 5/28/2020 5:12:55 PM.
Project "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\windows\Calculator.sln" on node 1 (default targets).
ValidateSolutionConfiguration:
  Building solution configuration "Debug|x86".
Project "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\windows\Calculator.sln" (1) is building "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\windows\Calculator\Calculator.vcxproj.metaproj" (2) on node 1 (default targets).
Project "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\windows\Calculator\Calculator.vcxproj.metaproj" (2) is building "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Microsoft.ReactNative\Microsoft.ReactNative.vcxproj" (3) on node 1 (default targets).
Project "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Microsoft.ReactNative\Microsoft.ReactNative.vcxproj" (3) is building "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Common\Common.vcxproj" (4) on node 1 (default targets).
GetInstalledSDKLocations:
  Searching for SDKs targeting "UAP, 10.0.18362.0".
  Searching for SDKs targeting "Windows, 8.1".
ResolveSDKReferences:
    Reading SDK manifest file "C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs\14.0\SDKManifest.xml".
    Targeted configuration and architecture "Debug|x86"
    Could not find "FrameworkIdentity" attribute "FrameworkIdentity-Debug-x86" in the SDK manifest.
    Found "FrameworkIdentity" attribute "Name = Microsoft.VCLibs.140.00.Debug, MinVersion = 14.0.27810.0, Publisher = 'CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US'" in the SDK manifest.
    Found "APPX" location attribute "AppX-Debug-x86=.\AppX\Debug\x86\Microsoft.VCLibs.x86.Debug.14.00.appx" in the SDK manifest.
    Found "APPX" location attribute "AppX-Debug-x64=.\AppX\Debug\x64\Microsoft.VCLibs.x64.Debug.14.00.appx" in the SDK manifest.
    Found "APPX" location attribute "AppX-Debug-ARM=.\AppX\Debug\ARM\Microsoft.VCLibs.ARM.Debug.14.00.appx" in the SDK manifest.
    Found "APPX" location attribute "AppX-Debug-ARM64=.\AppX\Debug\ARM64\Microsoft.VCLibs.ARM64.Debug.14.00.appx" in the SDK manifest.
ExpandSDKReferences:
  Enumerating SDK Reference "Microsoft.VCLibs, Version=14.0" from "C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs\14.0\".
InitializeBuildStatus:
  Creating "build\x86\Debug\Common\Common.tlog\unsuccessfulbuild" because "AlwaysCreate" was specified.
ClCompile:
  All outputs are up-to-date.
Lib:
  All outputs are up-to-date.
  Common.vcxproj -> C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Common\target\x86\Debug\Common\Common.lib
ComputeProcessXamlFiles:
  (Out) ProcessedXamlFiles ==
CustomOutputGroupForPackaging:
  (Out) Project='Common' ProcessedXamlFiles ==
  (Out) XamlPackagingRootFolder == build\x86\Debug\Common\Generated Files\
  (Out) ProcessedXamlFilesFullPath ==
  (Out) Project='Common' CustomOutputGroupForPackagingOutput ==
GetPackagingOutputs:
  Common : Common.ProjectPriFile : C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Common\target\x86\Debug\Common\Common.pri -> Common.pri
  Common : Common.GetResolvedSDKReferences : C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs\14.0\ ->
  Common : Common._GetProjectArchitecture : x86 ->
_GenerateProjectPriConfigurationFiles:
  Common -> build\x86\Debug\Common\priconfig.xml
  Common -> build\x86\Debug\Common\unfiltered.layout.resfiles
  Common -> build\x86\Debug\Common\filtered.layout.resfiles
  Common -> build\x86\Debug\Common\excluded.layout.resfiles
  Common -> build\x86\Debug\Common\resources.resfiles
  Common -> build\x86\Debug\Common\pri.resfiles
  Common ->
  Common -> build\x86\Debug\Common\embed\embed.resfiles
_GenerateProjectPriFileCore:
Skipping target "_GenerateProjectPriFileCore" because all output files are up-to-date with respect to the input files.
FinalizeBuildStatus:
  Deleting file "build\x86\Debug\Common\Common.tlog\unsuccessfulbuild".
  Touching "build\x86\Debug\Common\Common.tlog\Common.lastbuildstate".
Done Building Project "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Common\Common.vcxproj" (default targets).
Project "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Microsoft.ReactNative\Microsoft.ReactNative.vcxproj" (3) is building "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Folly\Folly.vcxproj" (5) on node 1 (default targets).
GetInstalledSDKLocations:
  Searching for SDKs targeting "UAP, 10.0.18362.0".
  Searching for SDKs targeting "Windows, 8.1".
ResolveSDKReferences:
    Reading SDK manifest file "C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs\14.0\SDKManifest.xml".
    Targeted configuration and architecture "Debug|x86"
    Could not find "FrameworkIdentity" attribute "FrameworkIdentity-Debug-x86" in the SDK manifest.
    Found "FrameworkIdentity" attribute "Name = Microsoft.VCLibs.140.00.Debug, MinVersion = 14.0.27810.0, Publisher = 'CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US'" in the SDK manifest.
    Found "APPX" location attribute "AppX-Debug-x86=.\AppX\Debug\x86\Microsoft.VCLibs.x86.Debug.14.00.appx" in the SDK manifest.
    Found "APPX" location attribute "AppX-Debug-x64=.\AppX\Debug\x64\Microsoft.VCLibs.x64.Debug.14.00.appx" in the SDK manifest.
    Found "APPX" location attribute "AppX-Debug-ARM=.\AppX\Debug\ARM\Microsoft.VCLibs.ARM.Debug.14.00.appx" in the SDK manifest.
    Found "APPX" location attribute "AppX-Debug-ARM64=.\AppX\Debug\ARM64\Microsoft.VCLibs.ARM64.Debug.14.00.appx" in the SDK manifest.
ExpandSDKReferences:
  Enumerating SDK Reference "Microsoft.VCLibs, Version=14.0" from "C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs\14.0\".
InitializeBuildStatus:
  Creating "build\x86\Debug\Folly\Folly.tlog\unsuccessfulbuild" because "AlwaysCreate" was specified.
ClCompile:
  All outputs are up-to-date.
  All outputs are up-to-date.
Lib:
  All outputs are up-to-date.
  Folly.vcxproj -> C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Folly\target\x86\Debug\Folly\Folly.lib
ComputeProcessXamlFiles:
  (Out) ProcessedXamlFiles ==
CustomOutputGroupForPackaging:
  (Out) Project='Folly' ProcessedXamlFiles ==
  (Out) XamlPackagingRootFolder == build\x86\Debug\Folly\Generated Files\
  (Out) ProcessedXamlFilesFullPath ==
  (Out) Project='Folly' CustomOutputGroupForPackagingOutput ==
GetPackagingOutputs:
  Folly : Folly.ProjectPriFile : C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Folly\target\x86\Debug\Folly\Folly.pri -> Folly.pri
  Folly : Folly.GetResolvedSDKReferences : C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs\14.0\ ->
  Folly : Folly._GetProjectArchitecture : x86 ->
_GenerateProjectPriConfigurationFiles:
  Folly -> build\x86\Debug\Folly\priconfig.xml
  Folly -> build\x86\Debug\Folly\unfiltered.layout.resfiles
  Folly -> build\x86\Debug\Folly\filtered.layout.resfiles
  Folly -> build\x86\Debug\Folly\excluded.layout.resfiles
  Folly -> build\x86\Debug\Folly\resources.resfiles
  Folly -> build\x86\Debug\Folly\pri.resfiles
  Folly ->
  Folly -> build\x86\Debug\Folly\embed\embed.resfiles
_GenerateProjectPriFileCore:
Skipping target "_GenerateProjectPriFileCore" because all output files are up-to-date with respect to the input files.
FinalizeBuildStatus:
  Deleting file "build\x86\Debug\Folly\Folly.tlog\unsuccessfulbuild".
  Touching "build\x86\Debug\Folly\Folly.tlog\Folly.lastbuildstate".
Done Building Project "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Folly\Folly.vcxproj" (default targets).
Project "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Microsoft.ReactNative\Microsoft.ReactNative.vcxproj" (3) is building "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\JSI\Universal\JSI.Universal.vcxproj" (6) on node 1 (default targets).
GetInstalledSDKLocations:
  Searching for SDKs targeting "UAP, 10.0.18362.0".
  Searching for SDKs targeting "Windows, 8.1".
ResolveSDKReferences:
    Reading SDK manifest file "C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs\14.0\SDKManifest.xml".
    Targeted configuration and architecture "Debug|x86"
    Could not find "FrameworkIdentity" attribute "FrameworkIdentity-Debug-x86" in the SDK manifest.
    Found "FrameworkIdentity" attribute "Name = Microsoft.VCLibs.140.00.Debug, MinVersion = 14.0.27810.0, Publisher = 'CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US'" in the SDK manifest.
    Found "APPX" location attribute "AppX-Debug-x86=.\AppX\Debug\x86\Microsoft.VCLibs.x86.Debug.14.00.appx" in the SDK manifest.
    Found "APPX" location attribute "AppX-Debug-x64=.\AppX\Debug\x64\Microsoft.VCLibs.x64.Debug.14.00.appx" in the SDK manifest.
    Found "APPX" location attribute "AppX-Debug-ARM=.\AppX\Debug\ARM\Microsoft.VCLibs.ARM.Debug.14.00.appx" in the SDK manifest.
    Found "APPX" location attribute "AppX-Debug-ARM64=.\AppX\Debug\ARM64\Microsoft.VCLibs.ARM64.Debug.14.00.appx" in the SDK manifest.
ExpandSDKReferences:
  Enumerating SDK Reference "Microsoft.VCLibs, Version=14.0" from "C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs\14.0\".
InitializeBuildStatus:
  Creating "build\x86\Debug\JSI.Universal\JSI.Universal.tlog\unsuccessfulbuild" because "AlwaysCreate" was specified.
ClCompile:
  All outputs are up-to-date.
Lib:
  All outputs are up-to-date.
 ...
C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\PropertySheets\ReactPatches.targets(35,5): error MSB3021: Unable to copy file "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native\ReactCommon\turbomodule\samples\platform\ios\SampleTurboCxxModuleLegacyImpl.h" to "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Microsoft.ReactNative\build\x86\Debug\Microsoft.ReactNative\react-native-patched\\ReactCommon\\turbomodule\samples\platform\ios\SampleTurboCxxModuleLegacyImpl.h". Could not find a part of the path 'C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Microsoft.ReactNative\build\x86\Debug\Microsoft.ReactNative\react-native-patched\\ReactCommon\\turbomodule\samples\platform\ios\SampleTurboCxxModuleLegacyImpl.h'. [C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Microsoft.ReactNative\Microsoft.ReactNative.vcxproj]
Done Building Project "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Microsoft.ReactNative\Microsoft.ReactNative.vcxproj" (default targets) -- FAILED.
Done Building Project "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\windows\Calculator\Calculator.vcxproj.metaproj" (default targets) -- FAILED.
Done Building Project "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\windows\Calculator.sln" (default targets) -- FAILED.

Detailed Build Summary
============================== Build Hierarchy (IDs represent configurations) =====================================================
Id                  : Exclusive Time   Total Time   Path (Targets)
 | 1                 : 0.007s           32.881s       C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\windows\Calculator\Calculator.vcxproj.metaproj ()
 | . 4               : 30.513s           32.874s       C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Microsoft.ReactNative\Microsoft.ReactNative.vcxproj ()
 | | | 5             : 0.551s           0.551s       C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Common\Common.vcxproj ()
 | | | 6             : 0.385s           0.385s       C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Folly\Folly.vcxproj ()
 | | | 7             : 0.305s           0.342s       C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\JSI\Universal\JSI.Universal.vcxproj ()
 | | | | 10          : 0.021s           0.021s       C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Common\Common.vcxproj (GetNativeManifest)
 | | | . 11          : 0.016s           0.016s       C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Common\Common.vcxproj (GetResolvedLinkLibs)
 | | | 8             : 0.426s           0.456s       C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\ReactCommon\ReactCommon.vcxproj ()
 | | | . 12          : 0.030s           0.030s       C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Folly\Folly.vcxproj (GetNativeManifest)
 | | | 9             : 0.463s           0.568s       C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\ReactWindowsCore\ReactWindowsCore.vcxproj ()
 | | | | 13          : 0.041s           0.041s       C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\ReactCommon\ReactCommon.vcxproj (GetNativeManifest)
 | | | | 14          : 0.026s           0.026s       C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Folly\Folly.vcxproj (GetResolvedLinkLibs)
 | | | . 15          : 0.039s           0.039s       C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\ReactCommon\ReactCommon.vcxproj (GetResolvedLinkLibs)
 | | | 16            : 0.018s           0.018s       C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\JSI\Universal\JSI.Universal.vcxproj (GetNativeManifest)
 | | . 17            : 0.040s           0.040s       C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\ReactWindowsCore\ReactWindowsCore.vcxproj (GetNativeManifest)
 | 2                 : 0.003s           0.003s       C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\windows\..\node_modules\react-native-windows\ReactCommon\ReactCommon.vcxproj.metaproj ()
 . 3                 : 0.004s           0.004s       C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\windows\..\node_modules\react-native-windows\ReactWindowsCore\ReactWindowsCore.vcxproj.metaproj ()```

 ============================== Node Utilization (IDs represent configurations) ====================================================
 Timestamp:            1        Duration   Cumulative
 -----------------------------------------------------------------------------------------------------------------------------------
<PHONE_NUMBER>60500079:   0        0.048s     0.048s
<PHONE_NUMBER>60978705:   1        0.006s     0.054s
<PHONE_NUMBER>61038811:   4        0.255s     0.309s .....
<PHONE_NUMBER>63587452:   5        0.551s     0.860s ...........
<PHONE_NUMBER>69097975:   6        0.385s     1.245s .......
<PHONE_NUMBER>72948847:   7        0.063s     1.308s .
<PHONE_NUMBER>73577311:   10       0.021s     1.329s
<PHONE_NUMBER>73786614:   7        0.181s     1.509s ...
<PHONE_NUMBER>75592032:   11       0.016s     1.525s
<PHONE_NUMBER>75751611:   7        0.062s     1.587s .
<PHONE_NUMBER>76369667:   8        0.069s     1.656s .
<PHONE_NUMBER>77057838:   12       0.030s     1.686s
<PHONE_NUMBER>77357035:   8        0.357s     2.043s .......
<PHONE_NUMBER>80927458:   9        0.073s     2.116s .
<PHONE_NUMBER>81655765:   13       0.041s     2.156s
<PHONE_NUMBER>82064404:   9        0.260s     2.417s .....
<PHONE_NUMBER>84667422:   14       0.026s     2.443s
<PHONE_NUMBER>84926767:   15       0.039s     2.482s
<PHONE_NUMBER>85315682:   9        0.130s     2.611s ..
<PHONE_NUMBER>86612205:   4        0.003s     2.614s
<PHONE_NUMBER>86642117:   16       0.018s     2.632s
<PHONE_NUMBER>86821658:   17       0.040s     2.672s
<PHONE_NUMBER>87220567:   4        30.256s     32.928s ++++++ (scale 1:100)
<PHONE_NUMBER>89776469:   1        0.001s     32.929s
<PHONE_NUMBER>89786434:   2        0.003s     32.932s
<PHONE_NUMBER>89816349:   3        0.004s     32.936s
<PHONE_NUMBER>89816349:   0        0.004s     32.940s
 -----------------------------------------------------------------------------------------------------------------------------------
 Utilization:          100.0    Average Utilization: 100.0
× Building Solution
Build failed with message undefined. Check your build configuration.
× Build failed with message undefined. Check your build configuration.

@lexprom   looks like you're running an older version of RNW. Can you update package.json like so:
    "react-native": "0.62.2",
    "react-native-windows": "^0.62.0-preview.11"

make sure you're running VS 2019

@asklar I tried updating the package.json as you suggested. The app builds but fails to start/install. I'm getting the same error on every sample in the repo.
Start-Locally : Faulting application name: Calculator.exe, version: <IP_ADDRESS>, time stamp: 0x5edf7514
Faulting module name: Calculator.exe, version: <IP_ADDRESS>, time stamp: 0x5edf7514
Exception code: 0xc0000005
Fault offset: 0x000eb6cc
Faulting process id: 0x17104
Faulting application start time: 0x01d63e536323e9a4
Faulting application path:
D:\dev\react-native-windows-samples\samples\Calculator\windows\Debug\Calculator\Calculator.exe
Faulting module path:
D:\dev\react-native-windows-samples\samples\Calculator\windows\Debug\Calculator\Calculator.exe
Report Id: d5d723f1-028b-4747-81f9-c8294520dec7
Faulting package full name: 35d79556-a169-4a2c-81eb-296f32ffb465_<IP_ADDRESS>_x86__ha4szp75kcxjr
Faulting package-relative application ID: App
At line:1 char:166
+ ... Utils.ps1"; Start-Locally 35d79556-a169-4a2c-81eb-296f32ffb465 --remo ...
    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Start-Locally

and in the other window
> react-native start

error Invalid regular expression: /(D:[\\\]dev[\\\]react-native-windows-samples[\\\]samples[\\\]Calculator[\\\]node_modules[\\\]react-native[\\\].*|D:[\\\]dev[\\\]react-native-windows-samples[\\\]samples[\\\]Calculator[\\\]windows.*|node_modules\\react\\dist\\.*|website\\node_modules\\.*|heapCapture\\bundle\.js|.*\\__tests__\\.*)$/: Range out of order in character class. Run CLI with --verbose flag for more details.
SyntaxError: Invalid regular expression: /(D:[\\\]dev[\\\]react-native-windows-samples[\\\]samples[\\\]Calculator[\\\]node_modules[\\\]react-native[\\\].*|D:[\\\]dev[\\\]react-native-windows-samples[\\\]samples[\\\]Calculator[\\\]windows.*|node_modules\\react\\dist\\.*|website\\node_modules\\.*|heapCapture\\bundle\.js|.*\\__tests__\\.*)$/: Range out of order in character class
    at new RegExp (<anonymous>)
    at blacklist (D:\dev\react-native-windows-samples\samples\Calculator\node_modules\metro-config\src\defaults\blacklist.js:34:10)
    at Object.<anonymous> (D:\dev\react-native-windows-samples\samples\Calculator\metro.config.js:30:18)
    at Module._compile (internal/modules/cjs/loader.js:1156:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1176:10)
    at Module.load (internal/modules/cjs/loader.js:1000:32)
    at Function.Module._load (internal/modules/cjs/loader.js:899:14)
    at Module.require (internal/modules/cjs/loader.js:1042:19)
    at require (internal/modules/cjs/helpers.js:77:18)
    at module.exports (D:\dev\react-native-windows-samples\samples\Calculator\node_modules\import-fresh\index.js:28:9)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>start: `react-native start`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

@asklar I tried that, now getting the same error as @0xbs0d when running react-native start or yarn start. In VS2019:

@lexprom @0xbs0d
I've updated the sample app to work against 0.62 and added it to the repo's CI build.
https://github.com/microsoft/react-native-windows-samples/pull/138
Please try again and let us know if you hit any issues still.

@asklar hi, I cloned a new version and did everything from scratch.
Now on npx react-native run-windows:

Tried to launch it in VS2019 still the same problems 😔
First command with --logging:

It works for me now.
I deleted the local files, pulled the repo from github. Then i did yarn install and npx react-native run-windows and it all went smoothly.
Thank you @asklar

@asklar hi, I cloned a new version and did everything from scratch.
Now on npx react-native run-windows:

Tried to launch it in VS2019 still the same problems 😔
First command with --logging:
C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\PropertySheets
\ReactPatches.targets(35,5): error MSB3027: Could not copy "C:\Users\pak\Documents\react-native-windows-samples\samples
\Calculator\node_modules\react-native\ReactCommon\fabric\components\legacyviewmanagerinterop\LegacyViewManagerInteropVi
ewEventEmitter.h" to "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-
windows\build\x86\Debug\Microsoft.ReactNative\\react-native-patched\\ReactCommon\\fabric\components\legacyviewmanagerin
terop\LegacyViewManagerInteropViewEventEmitter.h". Exceeded retry count of 10. Failed.  [C:\Users\pak\Documents\react-n
ative-windows-samples\samples\Calculator\node_modules\react-native-windows\Microsoft.ReactNative\Microsoft.ReactNative.
vcxproj]
C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\PropertySheets
\ReactPatches.targets(35,5): error MSB3021: Unable to copy file "C:\Users\pak\Documents\react-native-windows-samples\sa
mples\Calculator\node_modules\react-native\ReactCommon\fabric\components\legacyviewmanagerinterop\LegacyViewManagerInte
ropViewEventEmitter.h" to "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-na
tive-windows\build\x86\Debug\Microsoft.ReactNative\\react-native-patched\\ReactCommon\\fabric\components\legacyviewmana
gerinterop\LegacyViewManagerInteropViewEventEmitter.h". Could not find a part of the path 'C:\Users\pak\Documents\react
-native-windows-samples\samples\Calculator\node_modules\react-native-windows\build\x86\Debug\Microsoft.ReactNative\\rea
ct-native-patched\\ReactCommon\\fabric\components\legacyviewmanagerinterop\LegacyViewManagerInteropViewEventEmitter.h'.
 [C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Microsoft.Re
actNative\Microsoft.ReactNative.vcxproj]
C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\PropertySheets
\ReactPatches.targets(35,5): error MSB3027: Could not copy "C:\Users\pak\Documents\react-native-windows-samples\samples
\Calculator\node_modules\react-native\ReactCommon\fabric\components\legacyviewmanagerinterop\LegacyViewManagerInteropCo
mponentDescriptor.h" to "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-nati
ve-windows\build\x86\Debug\Microsoft.ReactNative\\react-native-patched\\ReactCommon\\fabric\components\legacyviewmanage
rinterop\LegacyViewManagerInteropComponentDescriptor.h". Exceeded retry count of 10. Failed.  [C:\Users\pak\Documents\r
eact-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Microsoft.ReactNative\Microsoft.ReactN
ative.vcxproj]
C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\PropertySheets
\ReactPatches.targets(35,5): error MSB3021: Unable to copy file "C:\Users\pak\Documents\react-native-windows-samples\sa
mples\Calculator\node_modules\react-native\ReactCommon\fabric\components\legacyviewmanagerinterop\LegacyViewManagerInte
ropComponentDescriptor.h" to "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react
-native-windows\build\x86\Debug\Microsoft.ReactNative\\react-native-patched\\ReactCommon\\fabric\components\legacyviewm
anagerinterop\LegacyViewManagerInteropComponentDescriptor.h". Could not find a part of the path 'C:\Users\pak\Documents
\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\build\x86\Debug\Microsoft.ReactNativ
e\\react-native-patched\\ReactCommon\\fabric\components\legacyviewmanagerinterop\LegacyViewManagerInteropComponentDescr
iptor.h'. [C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Mic
rosoft.ReactNative\Microsoft.ReactNative.vcxproj]
C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\PropertySheets
\ReactPatches.targets(35,5): error MSB3027: Could not copy "C:\Users\pak\Documents\react-native-windows-samples\samples
\Calculator\node_modules\react-native\ReactCommon\fabric\components\legacyviewmanagerinterop\LegacyViewManagerInteropVi
ewEventEmitter.cpp" to "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-nativ
e-windows\build\x86\Debug\Microsoft.ReactNative\\react-native-patched\\ReactCommon\\fabric\components\legacyviewmanager
interop\LegacyViewManagerInteropViewEventEmitter.cpp". Exceeded retry count of 10. Failed.  [C:\Users\pak\Documents\rea
ct-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Microsoft.ReactNative\Microsoft.ReactNat
ive.vcxproj]
C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\PropertySheets
\ReactPatches.targets(35,5): error MSB3021: Unable to copy file "C:\Users\pak\Documents\react-native-windows-samples\sa
mples\Calculator\node_modules\react-native\ReactCommon\fabric\components\legacyviewmanagerinterop\LegacyViewManagerInte
ropViewEventEmitter.cpp" to "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-
native-windows\build\x86\Debug\Microsoft.ReactNative\\react-native-patched\\ReactCommon\\fabric\components\legacyviewma
nagerinterop\LegacyViewManagerInteropViewEventEmitter.cpp". Could not find a part of the path 'C:\Users\pak\Documents\r
eact-native-windows-samples\samples\Calculator\node_modules\react-native-windows\build\x86\Debug\Microsoft.ReactNative\
\react-native-patched\\ReactCommon\\fabric\components\legacyviewmanagerinterop\LegacyViewManagerInteropViewEventEmitter
.cpp'. [C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native-windows\Micros
oft.ReactNative\Microsoft.ReactNative.vcxproj]

Done Building Project "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\node_modules\react-native
-windows\Microsoft.ReactNative\Microsoft.ReactNative.vcxproj" (default targets) -- FAILED.

Done Building Project "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\windows\Calculator\Calcul
ator.vcxproj.metaproj" (default targets) -- FAILED.

Done Building Project "C:\Users\pak\Documents\react-native-windows-samples\samples\Calculator\windows\Calculator.sln" (
default targets) -- FAILED.

@lexprom hmm looks like you run into problems trying to copy some files... the only thing that comes to mind is maybe you forgot to run yarn ? You can see the calculator app building in the CI, maybe you can follow the steps in the pipeline (see .github/workflows/samples-CI.yml)


How to get dense visualization about process_your_own_data.py?

Thanks for your excellent work!
I used the data that you supplied for gt_generation_template, and ran process_your_own_data.py to generate the occ_gt_semantic files. The shape of these .npy files is (num_points, 3). I used visual.py to visualize the occupancy, but found that the visualization is sparse. I want to know how to get the visualization to be more dense?

Hi, what's voxel size of your occupancy prediction? You should change the voxel_size in visual.py as yours.

If you visualize the occupancy groundtruth, you should set voxel size as 1 in visual.py since the distance between neighbored voxels is 1.

I understand. Thank you for your reply!

@weiyithu @Xpangz Hi there, why is the distance between neighboring voxels in the ground truth set to 1? Considering that the voxel_size is 0.5 during both the training and inference phases, does this imply that one ground truth label will be duplicated four times during the model training process?


Only able to backup one table in the database

Laravel-backup only seems to be able to make a mysql-dump of one of my nine database tables. I'm running Laravel 5 with MySQL (InnoDB) on Homestead. All other files appear to be backed up just fine

This issue should be fixed in version 2.2.1.
Update your version and the problem should be resolved.
If this doesn't work let me know!

Happy to confirm this is fixed. Thanks


Styling

I am using your datepicker and autocomplete parts side by side with no formatting.

  <datepicker v-model="endDate" :monday-first="true" input-class="input" placeholder="Selecteer..." v-on:selected="doSelection()"></datepicker>

  <autocomplete is-size-1 :source="vehicleItems" v-on:selected="vehicleSelected($event)">
  </autocomplete>

Resulting in this

How can I style the autocomplete same as datepicker?

The component offers only basic css formatting so as to attempt to be less opinionated - this is left to the user to style how they see fit.
Closing as this is a css question - not really related to the component.

OK, understand that, let me phrase otherwise:
Why is the styling of your datepicker and autocomplete parts different?
Could you either style it identical, or remove all styling? Then at least they would look the same, and the user can style them as he want to.


Enable tabs by default

After talking to @egamma we both think that tabs should be enabled by default (currently they are not). Erich rationale is that tabs is a flag ship feature that resolves a serious adoption blocker and my reasoning is that the editor stacks model is harder to understand if tabs are disabled and more natural if tabs are enabled.
@Microsoft/vscode please speak up if someone has a valid reason why we should not do that.

I don't like it, but I know how to configure the tool ;-). I just wonder what existing users that like no tabs (do those outside our team exist) thing of it?

Currently giving tabs a shot, but will probably stay with no-tabs, just works better for me.
I'd guess the majority is used to tabs from other editors, so probably sensible to enable it by default, fine with me as long as no-tabs doesn't disappear completely one day.


usm: http2: tests: Cut 9m from TestRawTraffic

What does this PR do?
The PR reuses the same USM instance, and just clears the http2 maps in between the runs, to have a clean state in the next test.
Now each instance of TestRawTraffic (CO-RE, RC, prebuilt) x (TLS, without TLS) takes 20s each (prebuilt TLS is not supported), instead of 100-168s before
Motivation
Faster CI for system-probe teams

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

/merge


Delete active/delayed jobs based on data

Hi,
It would be nice if I could remove one or several jobs based on its data. Example job data:
{
  "id": 123,
  "data": {
    "userId": "001",
    "email"<EMAIL_ADDRESS>  }
}

I can delete the job (active/delayed) using:
$ curl -X DELETE http://local:3000/job/userId/001
or
$ curl -X DELETE<EMAIL_ADDRESS>or any other similar approach.

If you are turning indexes on, you can search on your data by Kue, find job Ids and simply remove them
If you are not using search indexes, store jobIds with your meaningful logic data in your app (r.g. on redis) then lookup job ids in your cache and remove them :)

Thanks a lot! @behrad


Clean up the broken Class and Function links in docstrings

What type of change is this?

[x] Bug fix in a backwards-compatible manner.
[ ] New feature in a backwards-compatible manner.
[ ] Breaking change: bug fix or new feature that involve incompatible API changes.
[x] Other (e.g. doc update, configuration, etc)

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[ ] I added a line to the CHANGELOG.md file in the Unreleased section under the most fitting heading (e.g. Added, Changed, Removed).
[ ] I ran all tests on my computer and it's all green (i.e. invoke test).
[ ] I ran lint on my computer and there are no errors (i.e. invoke lint).
[ ] I added new functions/classes and made them available on a second-level import, e.g. compas_fab.robots.CollisionMesh.
[ ] I have added tests that prove my fix is effective or that my feature works.
[ ] I have added necessary documentation (if appropriate)

@gonzalocasas Fixed all your comments, we need to discuss only one thing. Whether to use the ~ for external links that points to compas_robots


Y U NO ActiveModel?

I'm talking in sake of supporting other database libraries such as Mongoid

Hmmm I don't think that just using ActiveModel would make it database agnostic. That is not what ActiveModel is for. But if we would use this and some ORM adapater (for example: https://github.com/ianwhite/orm_adapter) then yeah - that would make sense. And yeah - I think that supporting something except ActiveRecord would be awesome idea and target for 0.4/0.5.

I am also interested with getting this to work with mongoid.

In favor of this too (Re:Mongoid)

It seems like it's possible to use Mongoid with doorkeeper by pulling https://github.com/epicagency/doorkeeper/commit/f0a5f8b76b7c483b3d23e69d2b8f9d8ba10faf5e
into your branch.
Be warned though. You will lose SQL database support. The code needs to be refactored to work with both ActiveRecord and Mongoid.
Check it out!

Working on this: https://github.com/applicake/doorkeeper/tree/mongoid-support
Run specs with: rake DOORKEEPER_ORM=mongoid
Completely experimental support for now

very cool man. can't wait to try it out.


CNF-11502: Handle invalid stage transition condition

add xvalidation rule to reject invalid stage transition based on the status.validNextStages list
update the internal validation check(function validateStageTransition) to leverage the same logic to validate transition
clear any invalid transition condition if exist when moving to the valid stage
add the annotation "lca.openshift.io/triggerReconcile" to provide a backdoor for LCA reconcile if unexpected xvalidation rejects any spec changes
doc updates

/cc @jc-rh @donpenney @browsell

/retest

/lgtm

/approve


Don't create secret when I sync

Hello,
Thanks for this tool, it is very useful for me to synchronize ConfigMaps.
I have a problem when I try to synchronize a secret, the ConfigMaps are created for me, but the secrets cannot be created.
Have there been any changes to the Kopf API lately that break this?
Thanks

This is the log we received, everything seems to be fine but the secret has not been created.

I don't know why the "not enough permissions to watch for resources" warning appears, it has the permissions.

What is the Kubernetes version?

1.20

Hi @TheYkk ,
Is the reason for the failure of the application or is it mine?
Thank you very much for your assistance.

Hi is there a solution to this problem? @TheYkk

I think kubernetes changed many things in the last updates. When I was using this tool there was only kubernetes 1.18. It's been 8 big releases. Someone needs to probably first try upgrade the framework version and test it in newer kubernetes version. I don't have much time to do that. But feel free to test it out.

@TheYkk The problem occurs when pods annotated with synator/reload become up and running before the synator pods.  it was resolved with a waiter in Kubernetes 1.26.  Thanks for the reply.

Thanks for investigating the issue.


Update version to 0.2.26

Pull request abandoned due to postponement of designer updates for the next couple weeks.


Look for  french page how to translate web page title DON T invent your world

We van change CMS because it was given by thé customer


feat(api): gripper pickup from lifted thermocycler position

Overview
This PR changes the gripper behavior to pick up plates from a "lifted" position from the Thermocycler Gen2. This PR also removes the "gripper wiggle" functionality for dislodging plates, because the lifted position provides a much better experience by increasing the reliability of TC2 plate transfers.
The thermocycler_plate_lifter is changed to a context manager to be able to safely open and close the thermocycler lid during a gripper movement. Specifically, the behavior is the following:

The TC2 performs the plate lift movement (which is a command that will push the plate up off the surface and then drop it back down)
The TC2 moves the lid back up to the maximum point, presenting the plate for the gripper
The gripper picks up the plate from the elevated position
Once the plate has been moved to a new location, the thermocycler lid is returned to the normal "open" position

An important note: THE PICKUP OFFSET FOR THE TC2 MUST HAVE AN EXTRA z=3.5 INCREASE. This is NOT baked into the protocol engine right now, it must be added in the protocols. I discussed this with the hardware team and we believe it makes more sense to enforce changing the offsets in protocols instead of hard coding an extra offset in the code, since we will eventually move all of the offsets into shared-data.
Test Plan
Ran a script that moves a plate from a TC2 to another deck slot with the gripper. The TC2 now opens the lid to present the plate, and moves the lid back down after the plate is moved.
Changelog

Added TC driver code to "jog" the lid using a debugging gcode (already supported in all released TC2 firmware)
Changed thermocycler plate lifter to a context manager, added jogging up/down to present the plate

Review requests
Risk assessment
The biggest risk is the fact that the pickup offset for TC2 plate transfers has to change in all protocols.

I'm also not super into the idea about putting the z offset in the protocols. If we're intending on later loading that offset into the protocol engine directly, then that will make the protocols incorrect. Meanwhile, we already have this load_experimental_offset function that is where we'd fold in that value from config anyway, so I really don't see the benefit in not putting the number there in practice.

AFAIK, all of the offsets are in protocols right now, using the pickUpOffset and dropOffset parameters to the MoveLabware command (which ends up being in experimental_offset_data). So the thinking was that the pickUpOffset should get bumped by 3.5mm, and when RLAB-295 is implemented then the pickup offset would live there.

AFAIK, all of the offsets are in protocols right now, using the pickUpOffset and dropOffset parameters to the MoveLabware command (which ends up being in experimental_offset_data). So the thinking was that the pickUpOffset should get bumped by 3.5mm, and when RLAB-295 is implemented then the pickup offset would live there.

Yep, this is correct.
But, like @sfoster1 said, I wonder if it would actually be better to add this 3.5mm to the pickupOffset inside get_experimental_labware_movement_offset_vector at this point. If we push this responsibility to protocols, all science/testing teams will need to update their protocols. Then once we merge in RLAB-295 (which is slated for next week's release), everyone will have to update their protocols again. So even though it feels weird to have some offsets in protocol and some in engine, it might be an acceptable, non-breaking way to implement this. Or is there anything else in offset calculations I'm missing?
If you do decide to add the 3.5 in engine itself, I'm fine hard-coding it in get_experimental_labware_movement_offset_vector. We'll take care of including it in the contextual offsets calculation when handling RLAB-295.

Alrighty @sanni-t @sfoster1 , updated the implementation to automatically bump the Z offset by 3.5mm when picking up from a TC2. Updated the PR description to match. Definitely feels like a less-annoying approach for anybody running protocols.


navbar: Add navigate to home view tooltip to the organization logo.

The organization logo in the upper left navigates to the user's home view. We add a tooltip to make this easier to discover.
We show Esc as the keyboard shortcut here, unless the user has disabled it, in which case we show the alt shortcut Ctrl + [.
Fixes: #29185.

Screenshots and screen captures:
When ` Escape key navigates to home view` is disabled

When ` Escape key navigates to home view` is enabled

Self-review checklist

[x] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[x] Explains differences from previous plans (e.g., issue description).
[x] Highlights technical choices and bugs encountered.
[x] Calls out remaining decisions and concerns.
[x] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[x] Visual appearance of the changes.
[x] Responsiveness and internationalization.
[x] Strings and tooltips.
[x] End-to-end functionality of buttons, interactions and flows.
[x] Corner cases, error conditions, and easily imagined bugs.

Works for me in manual testing!
Note that the tooltip might wrap in other languages, but I think that's fine.

Merged, thanks @sayamsamal!


Greenkeeper/eslint config prettier 3.1.0

:tada: This PR is included in version 3.1.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


SARAALERT-767 Ability to delete/retire close contacts from the list

# Description
Jira Ticket: SARAALERT-767
Adds the ability for users to delete close contact records from patients.
(Feature) Demo/Screenshots

Important Changes
app/controllers/close_contacts_controller.rb

adds the delete method, with some very basic authentication.
app/javascript/components/patient/close_contact/CloseContact.js
adds front-end functionality to delete close contacts from the patient view, with a warning prompt.
app/config/routes.rb
adds a route for the delete method in the controller so the front-end can interact with the db.

Checklists
Submitter:

[ ] This PR describes why these changes were made.
[ ] This PR is into the correct branch.
[ ] This PR includes the correct JIRA ticket reference.
[ ] Code diff has been reviewed (it does not contain: additional white space, not applicable code changes, debug statements, etc.)
[ ] If UI changes have been made, Chrome Dev Tools Lighthouse accessibility test has been executed to ensure no 508 issues were introduced.
[ ] Tests are included and test edge cases
[ ] Tests have been run locally and pass (remember to update Gemfile when applicable)
[ ] Test fixtures updated and documented as necessary

@ :

[ ] Code is maintainable and reusable, reuses existing code and infrastructure where appropriate, and accomplishes the task’s purpose
[ ] The tests appropriately test the new code, including edge cases
[ ] You have tried to break the code
[ ] If applicable, you have tested changes against a large database, and considered possible performance regressions

@ :

[ ] Code is maintainable and reusable, reuses existing code and infrastructure where appropriate, and accomplishes the task’s purpose
[ ] The tests appropriately test the new code, including edge cases
[ ] You have tried to break the code
[ ] If applicable, you have tested changes against a large database, and considered possible performance regressions

@ :

[ ] Code is maintainable and reusable, reuses existing code and infrastructure where appropriate, and accomplishes the task’s purpose
[ ] The tests appropriately test the new code, including edge cases
[ ] You have tried to break the code
[ ] If applicable, you have tested changes against a large database, and considered possible performance regressions

@holmesie this will conflict with the changes @DPC15038 is making here.  Not sure which you'd rather get in first, but either way I think someone will have to redo some work

this needs a rebase

I noticed that there is a discrepancy in how we are "deleting" for labs and close contacts, when they should be the same.  For labs (see here), we are fully deleting the item and creating a history in case we need a paper trail in the future, where as for close contacts here we are just flagging it.  These behaviors should be the same.  I confirmed with the PO team we should be doing a straight delete, so take a look at @mayerm94's PR and model it after that

please rebase

@tstrass should this include adding a close_contact controller test suite? could be easily modeled off the labs one


Ctrl + f does not get to shell, despite having added exception to keyboard shortcuts

Issue Type: Bug
Reproduce

Follow the documentation https://code.visualstudio.com/docs/editor/integrated-terminal#_find and add the following to the keyboard shortcut settings (that's what I assume where the setting should go, the docs don't specify):

// Windows/Linux
{ "key": "ctrl+f", "command": "-workbench.action.terminal.focusFind",
                      "when": "terminalFocus" },
// macOS
{ "key": "cmd+f",  "command": "-workbench.action.terminal.focusFind",
                      "when": "terminalFocus" },

Open integrated terminal.

Press ctrl+f and observe results.

Expected results: ctrl+f gets sent to shell
Actual results: ctrl+f triggers Find in terminal.
Thoughts
It could be that I misunderstand the documentation, and should add the snippet in a different place. But in that case the documentation is bad and should be changed.

System details
VS Code version: Code 1.58.2 (c3f126316369cd610563c75b1b1725e0679adfb3, 2021-07-14T22:30:16.440Z)
OS version: Linux x64 5.8.0-59-generic
Restricted Mode: No

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz (8 x 1648)

GPU Status
2d_canvas: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: disabled_offopengl: enabled_onrasterization: disabled_softwareskia_renderer: enabled_onvideo_decode: disabled_softwarevulkan: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
1, 1, 1

Memory (System)
15.52GB (7.87GB free)

Process Argv
--unity-launch --crash-reporter-id 56d17e75-4070-4535-8292-5cdd09c86224

Screen Reader
no

VM
0%

DESKTOP_SESSION
ubuntu

XDG_CURRENT_DESKTOP
Unity

XDG_SESSION_DESKTOP
ubuntu

XDG_SESSION_TYPE
x11

Extensions: none
A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383:30185418
pythonvspyt602:30300191
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyt639:30300192
pythontb:30283811
pythonvspyt551cf:30311713
vspre833:30321513
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscoreces:30322571
pythondataviewer:30285071
vscus158:30321503
pythonvsuse255:30335481
vscod805cf:30301675
pythonvspyt200:30331937
vscextlangct:30333562
binariesv615:30325510
bridge0708:30335490

I see the same thing you do.  However, if you go to the KeyBoard Shortcuts and disable the workbench.action.terminal.focusFind it generates this deletion in your keybindings.json:
{
  "key": "ctrl+f",
  "command": "-workbench.action.terminal.focusFind",
  "when": "terminalFindFocused && terminalProcessSupported || terminalFocus && terminalProcessSupported"
},

which works for me.  And the entire when clause seems to be required.  So the documentation is bad and should reflect the working version above.

You can set terminal.integrated.sendKeybindingsToShell to send ctrl f to the shell


Add support for HTTPQueryParamMatch in Gateway API Translator

Description:
Add support for translating HTTPQueryParamMatch into the XDS IR field in the Gateway API translator

@arkodg I would like to take this one if no one else is currently working on it.


Better warning from locale tests about languages directory

Maybe a better approach would be to temporarily rename the existing application/languages directory...


Chroma or alpha on videos?

I've been playing around with the library to try to get some video blending going on. Specifically, I'm trying to take one layer of video (an effect, say) and layer it on top of user-shot video. After much fiddling, i was able to get things working using a chroma key blend filter.
In playing around with the video itself, though, I was interested in trying out a different way of getting an alpha channel into a video and using it with layering. I have videos that are split so that there's a separate, white alpha channel video. In other words, the alpha channel is split out into a separate video. The reason is that this way I don't have to worry about the key color in the effect video; I (supposedly) can just somehow merge the effect video with its alpha channel and get (supposedly) something I can layer over top of full video. Same idea as with a chroma key except I'm not depending on the chroma key color to tell me what's transparent. I have a separate video that can do that.
Any ideas on how a solution like this might work? Would it require a custom filter? I've tried removing a color on the alpha (pure black and white) video and then doing an alpha blend on the other, and then trying to blend that with the user video, but without much luck. Thoughts?
(and thanks so much for a great library)

Hi there, I will be more than interested in this custom filter ! Could you tell me how to download a copy of it, I think it's far more complex for me to write this custom script from scratch.. thanks a lot in advance for you help on this!


imgpkg copy from/into the same registry with different creds fails authentication

What steps did you take:
Create two projects in a harbor registry.
imgpkg push to the first project
Create a read-only robot in the first project
Create a read-write robot in the second project
Try to imgpkg copy from one project to the other, providing both sets of robot credentials (following https://carvel.dev/imgpkg/docs/latest/auth/#via-environment-variables)
What happened:
imgpkg fails to pull with an authentication failure
What did you expect:
imgpkg copy to determine which credentials go with which project (or allow me to specify)
Anything else you would like to add:
When multiple creds are passed to imgpkg copy the hostnames (IMGPKG_REGISTRY_HOSTNAME_0 and IMGPKG_REGISTRY_HOSTNAME_1) are used to determine when to use each credential.
In this example, the hostname is the same.
Harbor robots are project-scoped, so copying between projects in CI requires two robots.
Workaround:
imgpkg copy -b --to-tar && imgpkg copy --tar --to-repo
Environment:

imgpkg version (use imgpkg --version): 0.17.0
Docker registry used (e.g. Docker HUB): Harbor v2.1.3-b6de84c5
OS (e.g. from /etc/os-release): Debian 11 (container based on golang:latest)

Vote on this request
This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.
👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"
We are also happy to receive and review Pull Requests if you want to help working on this issue.

@xtreme-conor-nosal thanks for creating this issue
This is a great improvement for the tool, since auth between the same registry with different creds has security benefits.
I'm curious to hear your thoughts on how to incorporate allowing multiple creds for the same registry.
Here's a couple of ideas:

Introduce an IMGPKG_REGISTRY_REPOSITORY_0 env variable. This will scope the set of IMGPKG_REGISTRY_*_0 credentials to a specific repository.
Increase the scope of IMGPKG_REGISTRY_HOSTNAME allowing wildcards and repository in this env variable.

I'm going to carvel accept this issue, meaning we plan on working on it :-)

In the simple case (where the bundle and all referenced images are in one project / accessible with one set of creds) it would be nice to specify _SOURCE and _DESTINATION creds explicitly, rather than making imgpkg figure out when to use _0 and when to use _1, but that wouldn't scale to the cases where referenced images are in different registries.
Renaming HOSTNAME so it can include a repo path would be simpler I think (fewer env vars to set), but adding REPOSITORY would be more backwards-compatible I assume.

We expect that https://github.com/vmware-tanzu/carvel-imgpkg/pull/245 will address this issue. We'll keep this open until the other work lands and this workflow is validated.

Closing this as it was implemented and released in https://github.com/vmware-tanzu/carvel-imgpkg/releases/tag/v0.18.0


.center-block content should have a fixed width

should closed #18596

Tackled as part of #19102.


Insecure /tmp usage with static path (use mktemp instead or not shared /tmp)

Files / Folders are used in /tmp with static/predictable names, which is bad practice and in general as it's vulnerable to malicious usage from other users on the system (it's worth to fix even if it's not problematic in the specific case as it's still bad code)
examples are: /tmp/bwt.tar.gz /tmp/bitcoin.tar.gz
https://github.com/ez-org/eznode/blob/392290b45ebd1d5887a4194ab60a514b474bb9b9/bwt/install#L12-L18
https://github.com/ez-org/eznode/blob/392290b45ebd1d5887a4194ab60a514b474bb9b9/bitcoind/install#L4-L8
Using mktemp to generate the tmp file is better, also creating a temporary directory with mktemp -d and working with static names in it is ok (or creating temp dir for each usage by mktemp -d --suffix='-some-related-suffix'), also not using shared /tmp/ but another location like /home/user/tmp/ is also a fix.
There more /tmp/ usage instances in this codebase which should be fixed.

What are the disadvantages you see for this, given that this is running in an isolated predictable environment and there's no chance of naming collisions?

it's bad practice + bad code.
code reuse of this pattern may result in worse outcome (such as someone using this code as base for installation on bare linux not in container, etc..)
there's might be small chance of collisions either by coincidence or attack to pass security boundary (other users / processes with different MAC/sandboxes [selinux/apparmor] profiles) for this kind of tmp usage.

it's better to fix it as explained above (mktemp usage).


[bug](random distribution) fix data loss and incorrect in random distribution table

Proposed changes
This is a master fix for a issue found in branch-2.0: #33920

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run p0

run p0

run p0

run p0


Better str array and dtype ?

Currently, str arrays in numpy feels quite unintuitive and always require some special cases.
I feel it would be simpler if str arrays were matching TensorFlow tf.string array behavior more closely. More specifically, tf.string tensors are similar to dtype=object, but only have str / bytes values rather than arbitrary object.
For example:

Currently, how str dtype works is quite confusing:
x = np.array(['aaaaa', 'b'], dtype=np.str_)
assert x.dtype == np.str_  # <<< Raise an error. What ?

There's no obvious way to check that the array is a str array. Only weird hacks like: a.dtype.char == 'U'

A new dype('<U11') is generated using the longest string in the array. This waste a LOT of space as all str are padded to the longest one.

In 99% of case, this behavior just makes things much harder to use str array.
Proposal
Have 2 dtypes np.str and np.bytes. Internally, those would act similarly to dtype=object but only accept respectively str / bytes values.
x = np.array(['aaaaa', 'b'], dtype=np.str)
assert x.dtype  == np.str  # No more padding / dynamic type

This is how TF currently works (with tf.string would be similar to np.bytes).
x = tf.constant([b'aaaaa', b'b'], dtype=tf.string)
assert x.dtype  == tf.string

Hi @Conchylicultor, string dtypes are out of scope for this standard, because they're not implemented by most array libraries. We don't cover those at all. That said, I completely agree with your assessment of the NumPy string dtypes being not so great. At the moment a bunch of work is happening in https://github.com/numpy/numpy-user-dtypes to create a new variable-length string NumPy dtype that will work a lot more smoothly. It already is in a working state, and initial integration with Pandas worked well. You may want to check in there.

Hi @Conchylicultor, I think the question has been answered and since this is out of scope for the array API standard, I'll close the issue. Happy to discuss more though if needed.


Add locale pt-br. I can help with translation.

Thank you for reporting an issue, suggesting an enhancement, or asking a question. We appreciate your feedback - to help the team understand your
needs please complete the below template to ensure we have the details to help. Thanks!
Please check out the documentation to see if your question is already addressed there. This will help us ensure our documentation is up to date.
Category
[X ] Enhancement
[ ] Bug
[ ] Question
Version
Please specify what version of the library you are using: [  2.0.0   ]
If you are not using the latest release, please update and see if the issue is resolved before submitting an issue.
Expected / Desired Behavior / Question
If you are reporting an issue please describe the expected behavior. If you are suggesting an enhancement please
describe thoroughly the enhancement, how it can be achieved, and expected benefit. If you are asking a question, ask away!
Observed Behavior
If you are reporting an issue please describe the behavior you expected to occur when performing the action. If you are making a
suggestion or asking a question delete this section.
Steps to Reproduce
If you are reporting an issue please describe the steps to reproduce the bug in sufficient detail to allow testing. If you are making
a suggestion or asking a question delete this section.
Submission Guidelines
Delete this section after reading

All suggestions, questions and issues are welcome, please let us know what's on your mind.
Remember to include sufficient details and context.
If you have multiple suggestions, questions, or bugs please submit them in separate issues so we can track resolution.

Thanks!

@joaoworkhub sounds like a great idea. Would you be able to submit a PR with the changes?

@joelfmrodrigues  and @joaoworkhub I have created a PR for the same
I have taken help from google translate so can you please verify once :)

@joaoworkhub this was just added to the dev-v2 branch and will be included in the next release.
If you have the chance, it would be great if you could double-check the file and submit a PR with any improvements:
https://github.com/pnp/sp-dev-fx-controls-react/blob/v2-dev/src/loc/pt-br.ts
Thanks for the suggestion.


Uncaught Error: Cannot open spellchecker.node

Thanks a lot for this library!
I works great on the server, but I get the following error on the client:

Uncaught Error: Cannot open /Users/mmoroshko/chalice/node_modules/spellchecker/build/Release/spellchecker.node: TypeError: process.dlopen is not a function

Is that possible to use the spellchecker on a client?

What do you mean by saying 'get the following error on the client'?
Is it about the Electron preload script?
What operation system are you running?


Lack of space between input box and "continue" button

It doesn't look good with button and text box touching without any space.
I am willing to make a PR.
@dartpain Please assign me this.

i want to work onn this

i would like to work on this.please assign this to me.
#hackoctoberfest

Sorry this is not the open source version of docsgpt, this is the cloud version. Furthermore this UI is done by clerk


Allow to pass Lens admin password via envs

This PR makes it possible to pass LENS_ADMIN_PASSWORD to pharos up command and use the given password as admin password.

@jakolehm WDYT?
Todo: docs


refactor(DataList): remove custom breakpoint

fix #1583

Deploy preview for pf-next ready!
Built with commit 09665a3656221a92d48f47003187f8881f35e8b4
https://deploy-preview-1651--pf-next.netlify.com

Closing this issue in favor of #1658


install: cannot stat 'sysusers.d.5': No such file or directory

Build failure with 0.4.1 and 0.4.2
build command : 	make PREFIX="/usr" DESTDIR="$pkgdir" install
install -d /home/panoramix/Documents/WIP/pkgbuilds/opensysusers/pkg/opensysusers/usr/bin
install -m 0755 sysusers systemd-sysusers /home/panoramix/Documents/WIP/pkgbuilds/opensysusers/pkg/opensysusers/usr/bin
install -d /home/panoramix/Documents/WIP/pkgbuilds/opensysusers/pkg/opensysusers/usr/lib/opensysusers
install -m 0755 common.sh /home/panoramix/Documents/WIP/pkgbuilds/opensysusers/pkg/opensysusers/usr/lib/opensysusers
for prog in sysusers systemd-sysusers; do sed -e "s|@BINDIR@|/usr/bin|" -i /home/panoramix/Documents/WIP/pkgbuilds/opensysusers/pkg/opensysusers/usr/bin/$prog; done
for prog in sysusers systemd-sysusers; do sed -e "s|@LIBDIR@|/usr/lib|" -i /home/panoramix/Documents/WIP/pkgbuilds/opensysusers/pkg/opensysusers/usr/bin/$prog; done
make INSTALL=install DOCMODE=0644 MANDIR=/share/man DOCDIR=/share/doc/opensysusers PREFIX=/usr DESTDIR=/home/panoramix/Documents/WIP/pkgbuilds/opensysusers/pkg/opensysusers -C man install
make[1]: Entering directory '/home/panoramix/Documents/WIP/pkgbuilds/opensysusers/src/opensysusers-0.4.2/man'
install -d /home/panoramix/Documents/WIP/pkgbuilds/opensysusers/pkg/opensysusers/usr/share/man/man{5,8}
install -m 0644 sysusers.d.5 /home/panoramix/Documents/WIP/pkgbuilds/opensysusers/pkg/opensysusers/usr/share/man/man5
install: cannot stat 'sysusers.d.5': No such file or directory
make[1]: *** [Makefile:27: install] Error 1
make[1]: Leaving directory '/home/panoramix/Documents/WIP/pkgbuilds/opensysusers/src/opensysusers-0.4.2/man'
make: *** [Makefile:29: install] Error 2
==> ERROR:(B A failure occurred in package().(B
    Aborting...(B

There is a big change, you now need to do a make PREFIX="/usr" in build() in PKGBUILD. This will build the docs and man pages.

Also I am about to push 0.4.4 in another few minutes just in case.

0.4.4 gives another error message during build()
make PREFIX="/usr"
[ "FALSE" != 'FALSE' ] && sed -e "s|@BINFILE@|FALSE|" openrc/opensysusers.initd.in | tee openrc/opensysusers.initd
make: *** [Makefile:24: all] Error 1

I just pushed 0.4.5, see if that fixes your issue.

build() now works, but i have to repeat settings for pacakge() else make uses default ones, not the ones set in build() .
build() {
    cd $pkgname-$pkgver
    make PREFIX="/usr" SYSTEMDCOMPAT=FALSE
}

package() {
	cd $pkgname-$pkgver
	make PREFIX="/usr" SYSTEMDCOMPAT=FALSE DESTDIR="$pkgdir" install

https://github.com/artix-linux/opensysusers/commit/9bb04e3d5718a7a9f2045d259ba9f7776d0a1bcb

build() now works, but i have to repeat settings for pacakge() else make uses default ones, not the ones set in build() .

That is because our build system is very basic. We are not using autotools, meson, or cmake for this, so naturally it will have to be defined in both build and package steps.
I am going to close this. If there are any further issues feel free to reopen this or open a new issue.


FileGraphLibrary no longer works with FederatedStore

Describe the bug
You can no longer use a FileGraphLibrary with a FederatedStore. If you add a graph and restart the store, it will crash.
This may be due to changes with how getSchema works. When the FederatedStore is started, a file in the library is made with its empty schema. When a graph is added, the getSchema changes now mean that it will return the merged schema. When the FederatedStore is restarted, this schema now conflicts with the empty schema file, causing a crash.
To Reproduce
Steps to reproduce the behaviour:

Create a FederatedStore that uses FileGraphLibrary and a persistent cache
Add a graph to it
Turn off the FederatedStore
Turn it back on again, it will crash on startup

Expected behaviour
This behaviour should be possible and worked in Gaffer 1.
Additional context
I think this problem not being caught indicates we need better tests for turning the FederatedStore on and off, and how this interacts with persistent caches and the FileGraphLibrary.
Also, why isn't there a way to use the cache for the graph library? A file does not seem like the best way top store the graph library.

I've had a look at this and can reproduce it with a simple test within Gaffer which attempts to create a second store instead of restarting. Debugging reveals this is indeed caused by the getSchema changes.
When creating a new Graph with the builder, there's a call on line 841 which leads to line 997; where if the schema is null or empty it is replaced with a schema fetched from the store with getSchema(). This is the cause of the problem in this issue, because for the Federated Store the schema returned is no longer an empty schema. The builder then calls the GraphLibrary checkExisting method which compares the blank schema from the FileGraphLibrary file with the schema returned by the Federated Store (which is not blank), this causes the below exception:
uk.gov.gchq.gaffer.commonutil.exception.OverwritingException: GraphId federatedGraph already exists with a different schema:
existing schema:
{"types":{}}
new schema:
{....

This could be fixed in various ways.

A change relating to line 977: This check is not ideal for the Federated Store, because setting the internal schema field isn't useful for Stores which don't have a schema of their own. On the other hand, it's harmless. To change this, Graph would need to become aware of Stores which don't have a schema of their own, or it could call a different method in Store which could be overridden to return empty for schemaless Stores.
A change to GraphLibrary method at line 273: This is where the exception comes from. It could be changed to have awareness of schemaless Stores and handle them differently. This could work for a quick fix but it's probably better to make a change to Graph or Store instead.

Overall, I'd recommend refactoring Store to better accommodate schemaless stores and then make a small change to Graph to avoid the problem on line 977. E.g. adding a flag to indicate if a store used internal schema, this could then be checked by Graph on 977.

@GCHQDeveloper314
https://github.com/gchq/Gaffer/blob/b000f72defda0861e86cb70ab89aaaece98711d0/core/graph/src/main/java/uk/gov/gchq/gaffer/graph/Graph.java#L997
Could this be changed to getSchema() == null?

Could this be changed to getSchema() == null?

No, it is used to set the schema if none was supplied and that call uses getSchema(). This change would mean always setting schema to null only if the store had a null schema which doesn't make sense to me. If you mean just changing the second part, then I would question why we are looking at the groups at all. It was introduced in this PR and feels like an afterthought. If you wanted to use the schema from the store you wouldn't pass in an empty schema when you could pass in null or use a method that doesn't ask for a schema at all.

The fix for this issue was to only get the Schema from the Store if it is null. Previously this would also be done if it were empty, this is a problem for the Federated Store because it has a dynamic schema which starts empty and then changes to include graphs added to the store.
The crash happened because when the store was restarted the schema from the FileGraphLibrary schema file (empty) would be compared with a schema from the store (not empty) and this would cause a conflict when checked. This check doesn't make sense for Federated Stores because it is normal for their schemas to change and not an error.
A workaround was to delete the schema file created by FileGraphLibrary before restarting (which recreates the Federated Store), this ensured the failing check passed as there was then no existing empty schema to compare against. This means the FileGraphLibrary schema file will then contain the Federated Store's schema as of the time of restarting (a non-empty schema if graphs had been added previously). As this file would no longer be an empty schema further restarts would work correctly as the failing check only occurred if the file did not exist or had an empty schema.
As Federated Stores do not have schemas in the usual sense, it doesn't make sense to be checking or fetching them at all. To better accommodate this in future, I would suggest changing Graph.java/Store.java/GraphLibrary to better manage Stores which don't have a schema of their own. For example by adding a field which flags this and allows various schema checks to be skipped for these stores.


⚠ Bofrost.be has degraded performance

In 78b9ea6, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 2149 ms

Resolved: Bofrost.be performance has improved in 07414d6.


Feature Request: Add support for configuring administrator permissions in the network resource

According to the documentation, configuring administrator permissions for a network is currently not supported.
The Central API seems to support this.
Please consider implementing this functionality in the terraform provider.

@someara


[SM-4352]: Fix server cannot start when using activation-api-1.2.1, b…

Fix server (karaf) cannot start when using activation-api-1.2.1, because MimeType.isSpecial doesn't exist.
The change was also preventing before sending emails from karaf container using java mail api.
Spec was also not compiling before the change.

I also ran into this error. These changes fixed it for me

Hi! I have the same problem. Is any ide when to merge this PR?

I'm on it and I will cut the release. Sorry for the delay.

@jbonofre Do I have to do anything more in order to merge this Pull Request?

@kh4mell No, it's OK, I will merge it quickly (just have to complete couple of fixes in Karaf).


Mac installation does not list required packages

Can you update documentation to properly describe installation process for Mac OS.
Namely, add dependency on either conda, or protobuf, or brew.
Currently documentation relies on conda 'conda install -c conda-forge protobuf'. It is not clear if conda a requirement (which is a proprietary software) or does it just rely on protobuf that can also be installed with brew, avoiding conda installation.

Thanks for the comment @yselivonchyk
Would be great if you go ahead and file a PR with your proposed improvement.

@yselivonchyk The protobuf requirement comes upstream from ONNX. I recommend that you use conda to install protobuf. You might find you need to pin a specific version and/or remove previous installations of protobuf to get things to work properly.
You can refer to the ONNX instructions which state conda is the primary route, but you can also build from source if you don't want to use conda.
Brew is not mentioned in their docs nor ours, and I believe this is because you can really tangle up your protobuf install with brew. But if you're a brew master, then please let us know how you solved it with brew.

@yselivonchyk, could you please update this issue with the outcome that worked for you? If it didn't work - could you please comment on what concerns would you have with @aaronmarkham's proposal above?


Add instructions for authorizing sheet2linkml on Google Drive

This PR adds a section to the README describing how to authorize sheet2linkml to access Google Drive. It also adds a check for the google_api_credentials.json file, so that it can point you to this error rather than raising a FileNotFound exception.

RuntimeError: Error accessing TCCM Terminology Service: <Response [404]>

I guess there are already some PRs to address this, so I will approve this PR.