sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: tauri
Issue: [bug] Building of the tonic crate (added as a dependency) fails the running cargo tauri dev due to failed to build archive: Operation not permitted
Labels: type: bug,help wanted,platform: macOS,status: needs triage

### Describe the bug

Using `cargo tauri dev` or `deno task tauri dev` fails to build [`tonic`](https://crates.io/crates/tonic) with:

```
Compiling tonic v0.12.3
 
error: failed to build archive: Operation not permitted

error: could not compile `tonic` (lib) due to 1 previous error
```

Building works with `cargo build` or `cargo tauri dev -- --release`.

### Reproduction

1. Create a new tauri 2.0 project
2. Add `tonic` as a dependency
3. run `cargo tauri dev`

### Expected behavior

The application builds in debug mode and runs.

### Full `tauri info` output

```text
[✔] Environment
    - OS: Mac OS 14.5.0 arm64 (X64)
    ✔ Xcode Command Line Tools: installed
    ✔ rustc: 1.81.0 (eeb90cda1 2024-09-04)
    ✔ cargo: 1.81.0 (2dbb1af80 2024-08-20)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-aarch64-apple-darwin (default)
    - node: 20.11.0
    - pnpm: 8.15.6
    - yarn: 1.22.19
    - npm: 10.2.4
    - deno: deno 2.1.2

[-] Packages
    - tauri 🦀: 2.1.1
    - tauri-build 🦀: 2.0.3
    - wry 🦀: 0.47.2
    - tao 🦀: 0.30.8
    - tauri-cli 🦀: 2.1.0
    - @tauri-apps/api : 2.1.1
    - @tauri-apps/cli : 2.1.0

[-] Plugins
    - tauri-plugin-shell 🦀: 2.0.2
    - @tauri-apps/plugin-shell : 2.0.1

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
    - framework: Vue.js
    - bundler: Vite
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: vscode
Issue: "This browser supports WebGPU but it appears to be disabled" on linux
Labels: feature-request,editor-gpu

Testing #234762

I thought i'd test on my Ubuntu 24.04 VM (virtualized on an ARM mac).  After enabling the setting and reloading I get this, presumably meaning my environment is incompatible?


![Image](https://github.com/user-attachments/assets/97baca51-0241-42c3-a32a-03ea8c6c34b1)

![Image](https://github.com/user-attachments/assets/a7f8dc95-5ae0-47eb-9b0d-e4525e076b7b)


When I click that button to revert back, I get this error (and nothing appears to happen behind the scenes):

![Image](https://github.com/user-attachments/assets/8c46cd4c-26fc-47e7-a27c-db2eef2a2d02)
Repository: deno
Issue: `js_unit_tests::serve_test` is flaky
Labels: flaky

Over and over:

```
[serve_test 003.21] error: AddrInUse: Address already in use (os error 48): Address already in use (os error 48)
[serve_test 003.21]     const server = Deno.serve(***
[serve_test 003.21]                         ^
[serve_test 003.21]     at listen (ext:deno_net/01_net.js:504:35)
[serve_test 003.21]     at Object.serve (ext:deno_http/00_serve.ts:555:16)
[serve_test 003.21]     at file:///Users/runner/work/deno/deno/tests/unit/serve_test.ts:1224:25
```

https://github.com/denoland/deno/actions/runs/12143020514/job/33858916873
Repository: ui
Issue: [bug]: Drawer component doesn't work properly when direction="top"
Labels: bug

### Describe the bug

When you set  `<Drawer direction="top">` the component doesn't work properly.

![image](https://github.com/user-attachments/assets/8371bbb1-5f29-4026-abbb-a50c61193e1c)


### Affected component/components

Drawer

### How to reproduce

On a new nextjs project install Drawer component and set `<Drawer direction="top">`

### Codesandbox/StackBlitz link

https://stackblitz.com/edit/nextjs-vq7fth?file=app%2Fpage.tsx

### Logs

_No response_

### System Info

```bash
Chrome
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: go
Issue: x/mobile: target maccatalyst cannot find OpenGLES header
Labels: help wanted,NeedsInvestigation,mobile

### Go version

go version go1.23.3 darwin/arm64

### Output of `go env` in your module/workspace:

```shell
GO111MODULE='auto'
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/brien/Library/Caches/go-build'
GOENV='/Users/brien/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/brien/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/brien/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.23.3'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/brien/Library/Application Support/go/telemetry'
GCCGO='gccgo'
GOARM64='v8.0'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD='/Users/brien/bringyour/sdk/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/r3/v_3z60rx2cxg0s1r9tl9fbmw0000gn/T/go-build1634776604=/tmp/go-build -gno-record-gcc-switches -fno-common'
```


### What did you do?

Create a xcframework using the following `gomobile bind` command:

```
gomobile bind \
	-ldflags "-X client.Version=$WARP_VERSION" \
	-target ios,iossimulator,macos,maccatalyst -iosversion 16.0 \
	-bundleid com.bringyour \
	-trimpath \
	-gcflags "-dwarf=true" \
	-ldflags "-X client.Version=$WARP_VERSION -compressdwarf=false -B gobuildid" \
	-o "build/$BUILD_DIR/URnetworkSdk.xcframework" \
	github.com/urnetwork/sdk;
```

The command ends with an error:

```
gomobile: maccatalyst/amd64: go build -gcflags -dwarf=true -ldflags -X client.Version=2024.12.3-outerwerld -compressdwarf=false -B gobuildid -trimpath -buildmode=c-archive -o /var/folders/r3/v_3z60rx2cxg0s1r9tl9fbmw0000gn/T/gomobile-work-3462168386/URnetworkSdk-maccatalyst-amd64.a ./gobind failed: exit status 1
# golang.org/x/mobile/gl
In file included from /Users/brien/go/pkg/mod/golang.org/x/mobile@v0.0.0-20241108191957-fa514ef75a0f/gl/work.go:25:
./work.h:18:10: fatal error: 'OpenGLES/ES2/glext.h' file not found
   18 | #include <OpenGLES/ES2/glext.h>
      |          ^~~~~~~~~~~~~~~~~~~~~~
1 error generated.
```

### What did you see happen?

`go build` cannot find header file.

```
In file included from /Users/brien/go/pkg/mod/golang.org/x/mobile@v0.0.0-20241108191957-fa514ef75a0f/gl/work.go:25:
./work.h:18:10: fatal error: 'OpenGLES/ES2/glext.h' file not found
   18 | #include <OpenGLES/ES2/glext.h>
      |          ^~~~~~~~~~~~~~~~~~~~~~
1 error generated.
```

### What did you expect to see?

The maccatalyst libraries should be included in the built xcframework without error.
Repository: rust
Issue: Tracking issue for release notes of #133811: [AIX] change AIX default codemodel=large
Labels: T-compiler,relnotes,O-aix,relnotes-tracking-issue


This issue tracks the release notes text for #133811.

### Steps

- [x] Proposed text is drafted by PR author (or team) making the noteworthy change.
- [ ] Issue is nominated for release team review of clarity for wider audience.
- [ ] Release team includes text in release notes/blog posts.

### Release notes text

The responsible team for the underlying change should edit this section to replace the automatically generated link with a succinct description of what changed, drawing upon text proposed by the author (either in discussion or through direct editing).

````markdown
# Compatibility Notes
- [Change `powerpc64-ibm-aix` default `codemodel` to large](https://github.com/rust-lang/rust/pull/133811)
````

> [!TIP]
> Use the [previous releases](https://doc.rust-lang.org/nightly/releases.html) categories to help choose which one(s) to use.
> The category will be de-duplicated with all the other ones by the release team.
>
> *More than one section can be included if needed.*

### Release blog section

If the change is notable enough for inclusion in the blog post, the responsible team should add content to this section.
*Otherwise leave it empty.*

````markdown
````

cc @mustartt, @jieyouxu -- origin issue/PR authors and assignees for starting to draft text
Repository: rust
Issue: compiletest: improve diagnostics for test suite default outcome expectation
Labels: C-enhancement,A-diagnostics,T-compiler,T-bootstrap,A-compiletest

> Remark (for myself): improve this diagnostics when I get to untangling the runtest logic to make it so that test suites explicitly declare their intended default behavior so that the diagnostics here can say e.g. "expected to check-fail, but this didn't fail" or whatever.

_Originally posted by @jieyouxu in https://github.com/rust-lang/rust/pull/133813#discussion_r1868302243_
            
E.g. `ui` tests by default are expected to "check-fail", compare that to the actual test outcome, etc.
Repository: go
Issue: x/tools/gopls: stubmethods: "could not find the enclosing function of the return statement" bug in GetIfaceStubInfo
Labels: NeedsInvestigation,gopls,Tools,gopls/telemetry-wins

```
#!stacks
("runtime.sigpanic" || "bug.Errorf") &&
  ("stubmethods.fromReturnStmt:+24" || "fromReturnStmt:+27") &&
  "GetIfaceStubInfo"
```
Issue created by [stacks](https://pkg.go.dev/golang.org/x/tools/gopls/internal/telemetry/cmd/stacks).

This stack `P5n9hA` was [reported by telemetry](https://storage.googleapis.com/prod-telemetry-merged/2024-12-01.json):

- `crash/crash`
- [`runtime.gopanic:+69`](https://cs.opensource.google/go/go/+/go1.23.3:src/runtime/panic.go;l=804)
- `runtime.panicmem:=262`
- [`runtime.sigpanic:+19`](https://cs.opensource.google/go/go/+/go1.23.3:src/runtime/signal_unix.go;l=917)
- [`golang.org/x/tools/gopls/internal/golang/stubmethods.fromReturnStmt:+24`](https://cs.opensource.google/go/x/tools/+/gopls/v0.17.0-pre.3:gopls/internal/golang/stubmethods/stubmethods.go;l=284)
- [`golang.org/x/tools/gopls/internal/golang/stubmethods.GetIfaceStubInfo:+10`](https://cs.opensource.google/go/x/tools/+/gopls/v0.17.0-pre.3:gopls/internal/golang/stubmethods/stubmethods.go;l=60)
- [`golang.org/x/tools/gopls/internal/golang.quickFix:+44`](https://cs.opensource.google/go/x/tools/+/gopls/v0.17.0-pre.3:gopls/internal/golang/codeaction.go;l=316)
- [`golang.org/x/tools/gopls/internal/golang.CodeActions:+65`](https://cs.opensource.google/go/x/tools/+/gopls/v0.17.0-pre.3:gopls/internal/golang/codeaction.go;l=108)
- [`golang.org/x/tools/gopls/internal/server.(*server).CodeAction:+154`](https://cs.opensource.google/go/x/tools/+/gopls/v0.17.0-pre.3:gopls/internal/server/code_action.go;l=178)
- [`golang.org/x/tools/gopls/internal/protocol.serverDispatch:+160`](https://cs.opensource.google/go/x/tools/+/gopls/v0.17.0-pre.3:gopls/internal/protocol/tsserver.go;l=330)
- [`golang.org/x/tools/gopls/internal/lsprpc.(*streamServer).ServeStream.ServerHandler.func3:+5`](https://cs.opensource.google/go/x/tools/+/gopls/v0.17.0-pre.3:gopls/internal/protocol/protocol.go;l=160)
- [`golang.org/x/tools/gopls/internal/lsprpc.(*streamServer).ServeStream.handshaker.func4:+52`](https://cs.opensource.google/go/x/tools/+/gopls/v0.17.0-pre.3:gopls/internal/lsprpc/lsprpc.go;l=509)
- [`golang.org/x/tools/gopls/internal/protocol.Handlers.MustReplyHandler.func1:+2`](https://cs.opensource.google/go/x/tools/+/gopls/v0.17.0-pre.3:internal/jsonrpc2/handler.go;l=35)
- [`golang.org/x/tools/gopls/internal/protocol.Handlers.AsyncHandler.func2.2:+3`](https://cs.opensource.google/go/x/tools/+/gopls/v0.17.0-pre.3:internal/jsonrpc2/handler.go;l=104)
- `runtime.goexit:+0`
```
golang.org/x/tools/gopls@v0.17.0-pre.3 go1.23.3 darwin/amd64 vscode (4)
```
Dups: fm8UdQ
Repository: vscode
Issue: Clear Search Results also clears the filter unexpectedly
Labels: bug,search

Clicking the button will clear the filter when there are no results:

![Image](https://github.com/user-attachments/assets/10958c54-f0b8-42d9-b525-35eca46d9510)

Note that the button is enabled when there is text in the box, but not without:

![Image](https://github.com/user-attachments/assets/d522ee91-0ae9-4f73-ab68-e6837a0eb6e6)
Repository: rust
Issue: enums with disjoint ranges should emit more precise `llvm.range` metadata
Labels: A-LLVM,I-slow,A-codegen,T-compiler,C-optimization

I tried this code:
https://godbolt.org/z/4KKGvWs8d
```rust
#[derive(Copy, Clone)]
pub enum Foo {
    Foo1 = 1,
    Foo2 = 2,
    Foo4 = 4,
    Foo8 = 8,
}

#[no_mangle]
pub fn load(foo: &Foo) -> u32 {
    *foo as u32
}
```

I expected to see this happen: The metadata attatched to the `load` should specify that the loaded value is either 1, 2, 4 or 8:
```llvm
define noundef range(i32 1, 8) i32 @load(ptr noalias nocapture noundef readonly align 1 dereferenceable(1) %foo) unnamed_addr #0 {
  %0 = load i8, ptr %foo, align 1, !range !2, !noundef !3
  %_0 = zext nneg i8 %0 to i32
  ret i32 %_0
}

!2 = !{
  i8 1, i8 3, ; 1 or 2
  i8 4, i8 5, ; 4
  i8 8, i8 9, ; 8
 }
```

Instead, this happened: the range metadata gives a still correct, but less accurate range of `[1,9)`:
```llvm
define noundef range(i32 1, 8) i32 @load(ptr noalias nocapture noundef readonly align 1 dereferenceable(1) %foo) unnamed_addr #0 {
  %0 = load i8, ptr %foo, align 1, !range !2, !noundef !3
  %_0 = zext nneg i8 %0 to i32
  ret i32 %_0
}

!2 = !{i8 1, i8 9}
```

Similarly, the `range` attribute for the return value of `load` (and the `range` attribute for a value of type `Foo` if it is passed by value) is also less precise than it could be. But it appears from reading the LLVM LangRef that `range` **attributes** can only specify a single range, rather than a union of disjoint ranges like `llvm.range` **metadata** can.

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.85.0-nightly (5e1440ae5 2024-12-01)
binary: rustc
commit-hash: 5e1440ae514d98ddfcbf1607acb64d41e07ef616
commit-date: 2024-12-01
host: x86_64-unknown-linux-gnu
release: 1.85.0-nightly
LLVM version: 19.1.4
```

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary>Backtrace</summary>
<p>

```
<backtrace>
```

</p>
</details>
Repository: pytorch
Issue: [export] Move pytree serialization into export serializer
Labels: oncall: pt2,oncall: export

### 🚀 The feature, motivation and pitch

Instead of giving pytree their own serialization mechanism ([code](https://github.com/pytorch/pytorch/blob/b4ea9139781dce66419961305d220baeda565969/torch/utils/_pytree.py#L1425-L1444)), a better design seems like for export to have its own pytree serialization mechanism. Maybe pytree can provide the utility of getting to a python schema, and export can handle the actual serialization to json. Then we can avoid changes like [this](https://github.com/pytorch/pytorch/pull/141525?fbclid=IwZXh0bgNhZW0CMTEAAR0PKY5KkViM1-2rBOJQFgoEPmmRZFQGqZV6DtuB5kzWstoJrKX3EJ0wIcA_aem_p-fuTzA43Yw42_6ZJOlHmA#discussion_r1866506916).

Note: We need to be careful when making this change as it is BC breaking.

### Alternatives

_No response_

### Additional context

_No response_

cc @chauhang @penguinwu @avikchaudhuri @gmagogsfm @zhxchen17 @tugsbayasgalan @suo @ydwu4
Repository: go
Issue: proposal: crypto/x509: support extracting X25519 public keys from certificates
Labels: Proposal,Proposal-Crypto

### Proposal Details

Even though X25519 key pairs (not to be confused with Ed25519 key pairs) can't be used to establish TLS connections, there are still cases in which you want to use them in combination with X.509 certificates. For example, if X25519 is used to perform public key authenticated encryption (e.g., [NaCl's crypto_box](https://nacl.cr.yp.to/box.html)), X.509 certificates may be used to authenticate the identity of the peer before encrypting/decrypting. RFC 8410 added the ability to embed X25519 public keys into X.509 certificates for such use cases.


Right now `x509.ParseCertificate()` completes successfully when presented with a certificate containing an X25519 public key. Unfortunately, it does end up discarding the public key, as `Certificate.PublicKeyAlgorithm` and `Certificate.PublicKey` will be set to `UnknownPublicKeyAlgorithm` and `nil`, respectively.

The proposal here is to actually let `x509.ParseCertificate()` extract the public key from the certificate and return it in the form of an `*ecdh.PublicKey`. The `PublicKeyAlgorithm` enumeration will be extended to include an additional element for this public key algorithm, which will simply be called `X25519`.

Code changes can be found here: https://go-review.googlesource.com/c/go/+/632875
Repository: go
Issue: proposal: x/mobile: better support for unrecovered panics
Labels: Proposal

### Proposal Details

Currently with gomobile, the following example would crash the entire app with a single error message and no stack trace.

```
func HelloWorld() {
  var x *SomeType
  x.Foo()
  // oh no, the application crashed
}
```

In mobile applications we typically don't want to crash the app, but instead capture and report unrecovered errors and then handle the unrecovered errors as part of error handling in the caller. I'd like to propose four improvement to gomobile:

1. Standard stack trace logging for all unrecovered errors.
2. A global unrecovered error callback that is called before propagating unrecovered errors. 
3. Instead of unrecovered errors crashing the application, the error should be converted to an unchecked exception/fatal error type in the caller code so that it can integrate with the native unhandled error flow. 
4. Support for propagating unrecovered errors to the caller as checked exceptions. In many cases a typical return will be a pair of value and error, which is correctly translated to the exception framework by gomobile. Unrecovered errors would more naturally be "thrown" to the caller with the correct stack trace than crashing the application.

Is there a process to vet improvements like this before working on a PR?
Repository: angular
Issue: FormControl events should include when ValidatorFn is added/removed
Labels: area: forms,forms: validators

### Which @angular/* package(s) are relevant/related to the feature request?

forms

### Description

I'd like to be able to show a required asterisk (`*`) when the `Validators.required` is added to the reactive forms control.

There doesn't seem to be a way to get this information in any rxjs event or signal way.

My only workaround is to subscribe to `formControl.events`, but this ends up with extra noise and is not immediately triggered if changing from one invalid reason to another, etc.

### Proposed solution

`AbstractControl<any, any>.events: Observable<ControlEvent<any>>` should be extended to include a `ValidatorsChangeEvent`

```ts
export declare class ValidatorsChangeEvent extends ControlEvent {
    readonly validators: ValidatorFn[];
    readonly source: AbstractControl;
    constructor(validators: ValidatorFn[], source: AbstractControl);
}
```

### Alternatives considered

The following doesn't work very well:

```ts
const sub = formControl.events
.pipe(
  takeUntilDestroyed(this.destroyRef),
  map((x) => formControl.hasValidator(Validators.required)),
  // only trigger when the value changes
  distinctUntilChanged(
    (a, b) => a === b,
    (x) => x,
  ),
)
.subscribe((isFormControlRequired) => {
```
Repository: TypeScript
Issue: [bug] Auto `accessor` fields are declared as regular properties in mixin abstract classes
Labels: Needs Investigation,Fix Available

### 🔎 Search Terms

abstract class mixin accessor field property declaration .d.ts ts(2611)

### 🕗 Version & Regression Information

- This changed between versions ______ and _______
- This changed in commit or PR _______
- This is the behavior in every version I tried, and I reviewed the FAQ for entries about _________
- I was unable to test this on prior versions because _______


### ⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.8.0-dev.20241203#code/PTAEAMEsDsBMFMAeA6WyAuBncpKdAObzTwBOAhuvLKAEYCeEWAxqALRvwC2k6AIvGYAbchXSQA9tADy0IfRwwIXemyGRaFUgoBQSAA4TS6UAmGj4ocrUzoKzE+cz4AQuUyWA3jtC+rzZnhnIysALlBoAFcuWjIAbh0AXz1EQ2NTQRFSSwAzSOgHSWhQHlhYIXgACgBlSP0yAH5w9Hp6iRzQNw8ASnDrW3sTEgB3UEru0ABeAD5Qbz8wiOjY0gTEhJBcLjSTTxLIMorQRNAc0gkuUAByFTUNLXorhIMjRxFnUAAxGHIhUCQqHB8KVylUJvM-OQAkFMCFyFNQAAmOK+TZYSqIgBsAEZsRMyOdSEkgA

### 💻 Code

```ts
// `index.d.ts` is generated by `tsc --emitDeclarationOnly` in `my-library`
declare abstract class Base {
    accessor a: number;
}
declare function middle(Super?: typeof Base): abstract new () => {
    a: number;
};
// import { middle } from 'my-library';
class Final extends middle() {
    accessor a = 2;  // ts(2611) error
}
```


### 🙁 Actual behavior

TS throws:

```text
'a' is defined as a property in class '{ a: number; }', but is overridden here in 'Final' as an accessor. ts(2611)
```

but the library source code is:

```ts
export abstract class Base {
    accessor a = 1;
}

export function middle(Super = Base) {
    abstract class Middle extends Super {
    }
    return Middle;
}
```

### 🙂 Expected behavior

It has no type error while overrides auto `accessor` fields in sub classes of abstract mixins from 3rd-party libraries.

### Additional information about the issue

This bug can be resolved if `tsc` generates `.d.ts` as shown below:

```diff
// `index.d.ts` is generated by `tsc --emitDeclarationOnly` in `my-library`
declare abstract class Base {
    accessor a: number;
}
declare function middle(Super?: typeof Base): abstract new () => {
-    a: number;
+    get a(): number;
+    set a(value: number);
};
// import { middle } from 'my-library';
class Final extends middle() {
    accessor a = 2;  // no error
}
```

https://www.typescriptlang.org/play/?ts=5.8.0-dev.20241203#code/PTAEAMEsDsBMFMAeA6WyAuBncpKdAObzTwBOAhuvLKAEYCeEWAxqALRvwC2k6AIvGYAbchXSQA9tADy0IfRwwIXemyGRaFUgoBQSAA4TS6UAmGj4ocrUzoKzE+cz4AQuUyWA3jtC+rzZnhnIysALlBoAFcuWjIAbh0AXz1EQ2NTQRFSSwAzSOgHSWhQHlhYIXgACgBlSP0yAH5w9Hp6iRzQNw8ASnDrW3sTEgB3UEru0ABeAD5Qbz9CeBNycfComPifPw9lyoA3ciFI+DXo2NJuhMSEkFwuNJNPEsgyitBE0BzSCS5QAHIVGoNFp6H8EgYjI4RM5QAAxGCHUBIKhwfClcpVCbzPzkAJBTAhchTUAAJjivluWEqJIAbABGOkTMjfUhJIA