React 18 types compatibility

Is it possible to improve the compatibility with React 18?
Here is the output while adding @mdxeditor/editor
dependencies:
+ @mdxeditor/editor 3.0.5

 WARN  Issues with peer dependencies found
.
└─┬ @mdxeditor/editor 3.0.5
  ├─┬ @radix-ui/react-dialog 1.0.5
  │ ├─┬ @radix-ui/react-compose-refs 1.0.1
  │ │ └── ✕ unmet peer<EMAIL_ADDRESS>found 18.2.74
  │ ├─┬ @radix-ui/react-dismissable-layer 1.0.5
  │ │ ├── ✕ unmet peer<EMAIL_ADDRESS>found 18.2.74
  │ │ └─┬ @radix-ui/react-primitive 1.0.3
  │ │   └── ✕ unmet peer<EMAIL_ADDRESS>found 18.2.74
  │ ├─┬ @radix-ui/react-focus-guards 1.0.1
  │ │ └── ✕ unmet peer<EMAIL_ADDRESS>found 18.2.74
  │ └─┬ @radix-ui/react-focus-scope 1.0.4
  │   └── ✕ unmet peer<EMAIL_ADDRESS>found 18.2.74
  ├─┬ @radix-ui/react-popover 1.0.7
  │ └─┬ @radix-ui/react-popper 1.1.3
  │   └── ✕ unmet peer<EMAIL_ADDRESS>found 18.2.74
  └─┬ @radix-ui/react-select 2.0.0
    └─┬ @radix-ui/react-visually-hidden 1.0.3
      └── ✕ unmet peer<EMAIL_ADDRESS>found 18.2.74

Done in 1m 32.5s

Should be possible, I think - do you want to help out with this? Need to check if the dependencies have an up-to-date versions with the correct references.

I'm not sure how you're getting the output above. Using NPM in the dev project results in something like this:
<EMAIL_ADDRESS>/Users/petyo/w/mdx/editor
├─┬<EMAIL_ADDRESS>│ └─┬<EMAIL_ADDRESS>│   └──<EMAIL_ADDRESS>deduped
├─┬<EMAIL_ADDRESS>│ ├─┬<EMAIL_ADDRESS>│ │ └──<EMAIL_ADDRESS>deduped

And the react-compose-refs has @types/react: *.
If you provide more details, I can reopen this.


Update faulty qubit filtering

Summary
This PR is followup of #603 . The another PR has a bug in filtering mechanism and introduced performance regression due to Qiskit BackendProperty model instantiation.
This PR

fd03d283e24773913c568c4d1832d157ba6eee7c

Details and comments
fd03d283e24773913c568c4d1832d157ba6eee7c

Faulty instruction entries still exist. Since all entries are initialized with None according to the gate configuration, avoiding (continue) registration of instruction property doesn't remove faulty entries.
https://github.com/Qiskit/qiskit-ibm-provider/blob/952b599ecc0beac57809fc6cd91628ee4bb64a71/qiskit_ibm_provider/utils/json_decoder.py#L163-L168
This initialization is convenient, because gate coupling map is usually ascending order in qubit index, while properties["gates"] are random ordering (especially two qubit entries).

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

1 of 26 (3.85%)  changed or added relevant lines in 2 files are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.08%) to 50.058%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit_ibm_provider/ibm_qubit_properties.py
0
1
0.0%

qiskit_ibm_provider/utils/json_decoder.py
1
25
4.0%

Files with Coverage Reduction
New Missed Lines
%

qiskit_ibm_provider/utils/json_decoder.py
2
18.09%

Totals

Change from base Build<PHONE_NUMBER>:
-0.08%

Covered Lines:
3014

Relevant Lines:
6021

💛  - Coveralls


Could you add or send the file for translation.

Hey there would love to translate the app to Danish.

Hello there o/
Very well. There's a couple ways to go about it, but generally there's nothing preventing you from doing so already. It all depends on how tech-savvy you are with being able to run this project from source, in order to be able to test your translation efficiently. Otherwise, you can just do a blind translation, where I can send you the current template file, and you can send back the translation.
Here's some instructions on running the project from source: https://github.com/DevilXD/TwitchDropsMiner/wiki/Setting-up-the-environment,-building-and-running  Once you do so, it should generate an English.json translation file in the lang folder. Then it's just a matter of making a copy of it, giving the new copy a relevant name, then opening it and performing the translation. You can then launch the application from source and simply select your new language to test the translation. Once done, you can PR it to this project if you know how, or simply upload it here or anywhere else, and I'll introduce it into the project under your name.


Order>search ordered items returns HTTP Status 500

Details:
error- http://primefaces.org/ui, but no tag was defined for name: exporter

It should be dataexporter
On Tue, 15 Nov 2022 at 07:42, Prabha Gamage @.***>
wrote:

Details:
error- http://primefaces.org/ui, but no tag was defined for name: exporter
—
Reply to this email directly, view it on GitHub
https://github.com/lk-gov-health-hiu/clims/issues/37, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJLRQQRFFSWCHAF73TRBSDWILWQFANCNFSM6AAAAAASAN6FT4
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

corrected


Please change to a more permissive license

Hi, any change that you can release this under BSD-3 or MIT? Or at least Apache 2 like Sausage?

I'd like to second this. I'm playing around with it right now but my efforts will go to waste if the license stays as is.

Done. Hope that helps (have no time anymore for this project).

As a result of the less permissive license previously, this project sprung up: https://github.com/neam/codeception-saucelabs-metadata

great news. Thanks


Fixed Bug Crash

I have changed the original if statement from a 2 integer to an INFINITY integer. I also created a nodeCounter in case that is something you would like to keep track of.

@QDaily117  fixed this bug https://github.com/Jaysmito101/TerraForge3D/pull/24

Thanks for your contribution to TerraForge3D!
This issue has already been solved by #24


[BEAM-5376] Support nullability on all Row types

Plumbs through everything as an object and expands some test cases.

Follow this checklist to help us incorporate your contribution quickly and easily:

[X] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[X] If this contribution is large, please file an Apache Individual Contributor License Agreement.

It will help us expedite review of your Pull Request if you tag someone (e.g. @username) to look at it.


Darkmode on/off switch in storefront

We should add a DarkMode-toggle in the storefront to demonstrate that we use our own functionality. This reinforces our flexibility for different user preferences, and aligns with modern accessibility and usability expectations. It will also make it easier for us to test that dark mode works in various cases.
### Tasks
- [ ] Create a simple dark mode switch.
- [ ] Ensure the design works well in both light and dark modes.
- [ ] Adapt all illustrations, icons, and visual elements to ensure they display correctly in dark mode without losing clarity or accessibility.

This is blocked by the reason we removed it: #29189
We would either have to wait, or downgrade storybook.

@Barsnes I meant storefront, not storybook :)

We do already use dark mode on the storefront, just not for the whole page.
We use it in the footer, and some codeblocks

A switch between dark and light mode for the whole page should still exist. :)


How to list and get new tabs/targets?

What versions are you running?
Not using modules, but I'm using:
- chromedp @v0.2.0

$ chromium --version
Chromium 73.0.3683.86 Built on Ubuntu , running on Ubuntu 18.04

$ go version
go version go1.11.5 linux/amd64

What did you do?
I looked through the documentation to try to find a way to list and get a reference to existing tabs/Targets in the browser. I see that the API has transitioned from having a chromedp.CDP object to individual tabs/targets being handled by a chromedp.Context.
For my use case, I need to perform actions through the lower-level cdproto library, for example by passing a *Target to a .Do() method. There used to be a way to get targets by ID from the deprecated chromedp.CDP's methods so that they can be used in .Do(). Is there any way to achieve this in post-v0.2.0 versions? This is important because I need to know when a new tab is created (e.g. if a link is clicked, and it opens a new tab or window,) and then I will need to be able to retrieve it and .Do() actions with it.
What did you expect to see?
Some way to get the list of available tabs and to get access to the tabs.
What did you see instead?
It looks like there is no method in the library that returns a *Target

You can obtain a target from a context via just FromContext(ctx).Target. Note that in master, it's no longer needed to specify the executor when running actions.

If it is the chromedp.Context wrapped in the context.Context now that is going to be used, as you mentioned is now in master, then is there a way to get the contexts of other tabs that have been created not through chromedp but rather by clicking a link? I'm basically looking for something like:
func (x *type) GetTarget(id target.SessionID) context.Context
// or
func (x *type) GetTarget(id string) chromedp.Context

or something to that effect

Yes, listing the info for all current targets is possible. No, we currently don't support talking to targets (tabs) that weren't opened by the user. We'll probably add that for the next major version.

The simplest form of this would be a way to obtain a chromedp context from just *target.Info. However, you'd have to wait for the new tab to appear manually, such as polling every 10ms. We can have this kind of API available soon.
A better way would be event-based or wait-based, similar to what's discussed in https://github.com/GoogleChrome/puppeteer/issues/3718#issuecomment-452928154.

Amazing, thanks for the quick turnaround


Remove the mention of ofy in most places

There are still some mentions of ofy after this PR, but mostly in places
that would need to be modified later anyway.

This change is

Reviewable status: 0 of 10 files reviewed, 1 unresolved discussion (waiting on @jianglai)

core/src/main/java/google/registry/config/files/nomulus-config-unittest.yaml line 14 at r1 (raw file):

datastore:
  eppResourceIndexBucketsNum: 3

I think the version in nomulus-internal also has this block and needs update too.
Code quote:
datastore:
  eppResourceIndexBucketsNum: 3
  baseOfyRetryMillis: 0

I checked and there's no override in the internal repo.


Allow postmark-griddler to access headers through the array it returns rather than a hash

Can you add a test?

Thanks! You can ignore the single/double quote warnings (we really gotta fix that :smile:), but the rest of Hound's recommendations are valid.

@seanscal If you can fix Travis we can get this merged. I am slightly less concerned about Hound while I get caught up with PRs but feel free to fix whatever warnings you want.

@wingrunr21 should be fixed

Thanks, mind rebasing while you are at it?

Note that I will be rebasing/merging these changes myself this weekend. Just an FYI if you care about how the commits look on GitHub.

This has been rebased and merged.


OS X -> macOS

Thanks but given that OS X is so popular, I would leave the name as-is for now. We can revisit this again.

You should tag the repo so it's more easily searchable!
macos
security
ios-security
osx-security
macos-security


Api Coverage

Please describe the changes this PR makes and why it should be merged:
This Pr contains all the new features and changes to achieve full api coverage
Context:

This PR changes the library's interface (methods or parameters added)
This PR includes breaking changes (methods removed or renamed, parameters moved or removed)
This PR includes non-code changes, like changes to documentation, README, etc.

<!--
    This was inspired from the Discord.js repository
>

See #23 for more info


fix(meow): update to version 5.0.0

Pull request (PR)
Update meow to version 5.0.0.

Version 5.0.0 just got published.
Update to this version instead 🚀

Commits
The new version differs by 3 commits.

e047605 5.0.0
4ab22b1 Require Node.js 6
09f7ef0 Do not define unset boolean args (#77)

See the full diff

Associated issue(s)
Closes #26

[ ] 1.  The acceptance criteria for all associated issues have been completed, tested, and validated.
[ ] 2.  The README either reflects my changes or does not require updates.
[ ] 3.  The CONTRIBUTING document either reflects my changes or does not require updates.

Souce code analysis

Code quality summary

Measure
Scores

Quality gate

Complexity

Duplications

Issues

Maintainability

Reliability

Security

Test coverage

Code quality, vulnerability, and standards compliance tools

Code Style
Linters
Test frameworks

Standard JS user guide
ESlint user guide
Jest user guide

How to format, lint, and test your changes
Open a Terminal, go to the root directory for readme-inspector, and run:
$ npm test

 Completed tasks are not required to open a PR, and may be addressed while the PR is open.
 All tasks must be completed and verified before a PR may be merged into master, however.

Coverage remained the same at 100.0% when pulling 3bfd97af6c4e7b35c9b0b1b1312efa27604d423e on greenkeeper/meow-5.0.0 into d7fa19ec7c35afe8ad2788bf5cde06c17ba917f3 on master.

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[excel] (Styles) Updating *Style setName text

Fixes #186

Docs Build status updates of commit 69493a6:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/docs-ref-autogen/excel/excelscript/excelscript.pivottablestyle.yml
:white_check_mark:Succeeded
View (office-scripts)

docs/docs-ref-autogen/excel/excelscript/excelscript.slicerstyle.yml
:white_check_mark:Succeeded
View (office-scripts)

docs/docs-ref-autogen/excel/excelscript/excelscript.tablestyle.yml
:white_check_mark:Succeeded
View (office-scripts)

docs/docs-ref-autogen/excel/excelscript/excelscript.timelinestyle.yml
:white_check_mark:Succeeded
View (office-scripts)

generate-docs/api-extractor-inputs-excel/excel.d.ts
:white_check_mark:Succeeded

generate-docs/json/excel/ExcelScript.api.json
:white_check_mark:Succeeded

generate-docs/script-inputs/excel.d.ts
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


add end2end testing

document for us internally the key metrics for some of the standard tasks (e.g. titanic), and test those by hand before/after changes which could affect it. can be done by human, does not need to be automated.
this is important in addition to the unit tests.

test accuracy for training alone
test accuracy for 2 clients, with the same dataset strictly partitioned between the two

no code needed for now but clear values needed and file splits and documentation of expected results in a readme etc (or on the task)
ideally we'd also have these 2 models tested on a completely separate holdout set, removed from the training set before given to disco.
will make a new issue to support validation on separate set

done in #380 and some subsequent PRs like #404


support for storage pools

https://github.com/longhorn/longhorn/issues/311

[ ] Edit disks changes to Edit node and disks
[ ] Move tags in the Edit node and disks to below the path.
[ ] Configure Node Schedudling to Node Scheduling
[ ] Configure Node Tags to Node Tags
[ ] Show node and disk tags in the node overview.


feat: don't show saved search for only sort filter

The type of this PR is: Feature

This PR resolves FX-3003
Description
As an admin with the saved search feature flag enabled
When I visit the artworks tab for an artist
I do not see the saved search banner
And when I apply only sort filter
I don’t see the saved search banner
When I apply other set of filters
I see the saved search banner
Demo
https://user-images.githubusercontent.com/3513494/121387487-60e4ad80-c953-11eb-80bf-594d3dd3ab6f.mp4

PR Checklist (tick all before merging)

[x] I have included screenshots or videos to illustrate my changes, or I have not changed anything that impacts the UI.
[x] I have tested my changes on iOS and Android.
[x] I have added tests for my changes, or my changes don't require testing, or I have included a link to a separate Jira ticket covering the tests.
[x] I have added a feature flag, or my changes don't require a feature flag. (How do I add one?)
[x] I have documented any follow-up work that this PR will require, or it does not require any.
[x] I have added an app state migration, or my changes do not require one. (What are migrations?)
[x] I have added a CHANGELOG.yml entry or my changes do not require one.

#squashonmerge


A0-372: Add bootstrap-node command

Add bootstrap-node command, which for a single node generates:

a pair of aura keys,
a pair of aleph keys, and
an account id.

The private keys are saved in the specified keystore, while the public keys together with account id are printed to stdout as a json.
Example usage:
./target/release/aleph-node bootstrap-node --base-path docker/data --chain-id dev --authority filip

Output:
{
  "account_id": "5G44HpxcMg69hT2JCvDNicimDAVyiyy7svLaZz8FnddUf1aZ",
  "aura_key": "5DwPVrCU8dtQDo5PNVj7jyzMyvWgYXwgZstnBA27395FatUJ",
  "aleph_key": "5CU2zVXi7H1aV3XvhzQumAEvEhcJ5c3yTLvFCfvudrTo8iBv"
}

I pushed a PR with a merge comit and a few small changes that make it consistent with the behavior of the bigger bootstrap-chain command (use AccountId type):
User can pass a authority (becomes a seed) that will generate an AccountId or an id for command-line parsing itself:
./target/release/aleph-node bootstrap-node --base-path docker/data --chain-id a0dnet1 --authority filip

./target/release/aleph-node bootstrap-node --base-path docker/data --chain-id a0dnet1 --account-id 5G44HpxcMg69hT2JCvDNicimDAVyiyy7svLaZz8FnddUf1aZ


Changelog for the Javascript client

Hello,
I am upgrading from version 3.1.7 of the javascript client to version 5.0.7. I would like to know what breaking changes were introduced in version 4 and version 5 of the library and ideally some instructions on how to migrate from the older version of the library.
Is there any resource like this available?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 3cf283c9-5cd2-a9ff-b8c8-372d8a04356d
Version Independent ID: 729fddcf-24e4-b563-4952-a8045b231868
Content: ASP.NET Core SignalR JavaScript client
Content Source: aspnetcore/signalr/javascript-client.md
Product: aspnet-core
Technology: aspnetcore-signalr
GitHub Login: @bradygaster
Microsoft Alias: bradyg

Hello @Tiberriver256 ...
We keep any relevant migration info in the Migration node. For this version jump, check ...
https://docs.microsoft.com/aspnet/core/migration/31-to-50
You can also check the announcements to see if anything was put up there ...
https://github.com/aspnet/Announcements/issues?q=is%3Aopen+is%3Aissue+label%3A5.0.0
You can also look at the product unit release notes for each release. For example for 5.0 ......
https://github.com/dotnet/core/blob/main/release-notes/5.0/5.0.0/5.0.0.md
... and then there are similar readme files for each of the patches for 5.0 (5.0.1, etc.).

Thanks @guardrex! Good to know. I had seen those pages but they all seemed specific to the .NET stuff without mentioning the javascript libraries. It makes sense though if nothing has really changed.

Ok ... I'll close this. If you discover a delta that we need to call out, please open a new issue from the This page feedback button at the bottom of the topic as you did for this issue.


Can add code while the code block is minimized

 Issue by yasassri
Thursday Oct 19, 2017 at 11:28 GMT
Originally opened as https://github.com/ballerina-lang/composer/issues/3995

Fixed in 0.970.0


Transfering projects from Hedera to Hiero

This issue is the epic for the project transfer. A matrix of the current state can be found at https://github.com/LFDT-Hiero/hiero/blob/main/transition.md
For each repository that should be transfered to Hiero (independent if it is coming from Hedera or any other org) a custom issue must be created in the tsc repo. The following list shows all issues for the transfer of the Hedera repos to Hiero:

https://github.com/LFDT-Hiero/tsc/issues/2
https://github.com/LFDT-Hiero/tsc/issues/3
https://github.com/LFDT-Hiero/tsc/issues/4
https://github.com/LFDT-Hiero/tsc/issues/6
https://github.com/LFDT-Hiero/tsc/issues/7
https://github.com/LFDT-Hiero/tsc/issues/8
https://github.com/LFDT-Hiero/tsc/issues/9
https://github.com/LFDT-Hiero/tsc/issues/10
https://github.com/LFDT-Hiero/tsc/issues/11
https://github.com/LFDT-Hiero/tsc/issues/12
https://github.com/LFDT-Hiero/tsc/issues/13
https://github.com/LFDT-Hiero/tsc/issues/14
https://github.com/LFDT-Hiero/tsc/issues/15
https://github.com/LFDT-Hiero/tsc/issues/16
https://github.com/LFDT-Hiero/tsc/issues/17
https://github.com/LFDT-Hiero/tsc/issues/18
https://github.com/LFDT-Hiero/tsc/issues/19
https://github.com/LFDT-Hiero/tsc/issues/20
https://github.com/LFDT-Hiero/tsc/issues/21
https://github.com/LFDT-Hiero/tsc/issues/22

Licences we need to check if they can be used by LFDT:

CC0-1.0 license as used by https://github.com/anonyco/FastestSmallestTextEncoderDecoder needed for https://github.com/LFDT-Hiero/tsc/issues/20
MPL-2.0 license as used by https://www.npmjs.com/package/@ethereumjs/util needed for https://github.com/LFDT-Hiero/tsc/issues/15
CC-BY-4.0 license as used by https://github.com/FortAwesome/Font-Awesome needed for https://github.com/LFDT-Hiero/tsc/issues/15
0BSD license as used by https://www.npmjs.com/package/pony-cause needed for https://github.com/LFDT-Hiero/tsc/issues/15
BlueOak-1.0.0 license as used by https://www.npmjs.com/package/jackspeak needed for https://github.com/LFDT-Hiero/tsc/issues/11


fix(examples): inject react runtime for ui package

What has been changed?

Update build and dev command for kitchen-sink examples ui package to support components that don't explicitly import React.

Why?
Starting from React 17, React shipped with the new JSX Transform, allowing components to include JSX without React being in scope (For example, the Button component included below). Because of this, it is now very common to write react components without explicitly importing React at all.
However, in the current kitchen-sink example, doing this will break, and throw:
ReferenceError: React is not defined.
How?
In order to support this common use case, we need to instruct tsup to inject the react runtime into the build. Because tsup uses esbuild, we can leverage --inject to automatically replace a global variable with an import from another file. tsup has supported this argument (although poorly documented) since 5.3.0 (commit)
Other

The esbuild docs cover the exact scenario this PR is fixing for this example!
An issue was raised against tsup to support the inject flag to solve this problem as well

Fixing this will hopefully avoid frustration from new users who want to use an example as a starting point, with minimal changes to the build configuration.

@jaredpalmer good call, updated with your suggestions! Thanks!


Why is yargs a dependency instead of devDependency?

Why is yargs a dependency instead of devDependency (or better yet, an optional peer dependency)?
It should not be shipped in an app build, it's used only to execute the scripts in the bin/ folder to generate assets (I think) and only be developers (not end-users of the app).
Can we move it out?
It bugs me out because other react-native packages requires the react-native-vector-icons library (different versions, which also give vulnerabilities reports with npm audit see #918 ) and it also resolves yargs as a dependency (whereas other packages that use yargs directly only have it as a devDependency).
Also could we make it a less restrictive version of devDependency?
I was thinking something like this:
"peerDependencies": {
    "yargs": ">= 0.8.2" // you tell me what's the minimum required version to make it work (not the minimum version without vulnerabilities)
}

We’ve just released a major new version with significant changes and improvements. If you’re still experiencing this issue after upgrading, please open a new issue with updated details. We're closing all the very old issues to get on top of things. Thanks for your patience!


Make things work on systems defaulting to python3

There is a significant fraction of systems running with python symlinked to python3. To aid portability to these systems, use explicit python2 instead of generic python. I hope I did not forget or break anything. At least the build now runs on my system (archlinux).

For portability the most important thing that needs to work is util/make_dist.py: does that work for you (before the change) if you execute it as follows (other parts of the Makefile are not really cross platform)?
$ python2 util/make_dist.py

Is "python2" universally available on systems which only have Python 2 installed?

I guess python2 make_dist.py would fail because it executes further Python scripts and assumes "python" is the interpreter to use.

python2 util/make_dist.py works with my patch applied, but not without due to hardcoded python invocations somewhere.
The python2 symlink is standardized, see https://www.python.org/dev/peps/pep-0394/ . It is supported at least on debian, ubuntu, fedora, arch and cygwin.

Ok, sounds like assuming "python2" is a good approach (especially since Cygwin provides it too). Any systems missing it will be relatively old I guess.

My OS X install doesn't seem to have "python2", it does have "python2.7".

Would it be possible to default to "python2" and then if that's not found use "python"?

Sure, there are just quite a lot of places where the 'python' (or 'python2' in this branch) appear literally, and all would need to be changed like that.

The other option I've considered is making all the scripts python2 and python3 compatible. I tried that quickly a while ago and it turned out to be much messier than I had hoped.

@fatcerberus That kind of logic would not be possible as this is used in all the shebang lines (and these can only contain one hard-coded name). To which distribution of python on Windows are you referring? As mentioned, cygwin provides the python2 symlink.
@svaarala Are you sure that the absence of python2 is not due to some packaging snafu? Otherwise this would be pretty weird. Unrelated to this PR you might want to give a heads-up to your upstream about that.
As far as porting goes, YES, that would be the better solution. 2to3 could probably do many things, also there is a bunch of support libs for just that use case. Just changing the shebangs was just my lazy way to (for now) achieve the same result.

dtgo

My OS X install is just out of the box, with Brew installed.

@jaseg I was referring to the native Windows build, not Cygwin.  Given that this build is maintained by Python themselves, that surprised me, since they're the ones championing the python2 command.
Either way the point is moot since Windows can't run the shell scripts; it was just a curiosity I wanted to mention that Windows Python doesn't have python2.

If "python2" is not available, that'll be a problem even when running the Python utilities, as they launch python using a fixed command name now ("python" in master, and "python2" in this pull).

You mean Python doesn't have a built-in facility to fork a new interpreter?  That's a bit surprising.

@fatcerberus It's probably clearest if you look at the diff in this pull. Things can be changed but the diff shows what the current issues are.

The main issue (besides the shebangs) looks to be make_dist.py, which calls Python directly at several points (the makefile isn't as big a problem since it can just use a variable--and does in this pull).  That's why I wondered if there's a way to fork a new interpreter instance directly rather than invoking the python command.
The python 2/3 split really is a hassle...

@fatcerberus In make_dist.py, you could probably use Python's sys.executable to get the running python interpreter's path.

Ok, I just updated the PR with that.

make_dist.py works in native Windows using sys.executable.  So now the only potential issue is the shebang lines on Linux systems without a "python2" command.

The most critical thing to work is make_dist.py - other stuff is not even guaranteed to be portable to OS X or Cygwin. With more automatic testing in place I'll most likely prune the top level Makefile because most of the targets there are to make development-time testing easier.

Yeah, I was referring to the shebangs in the Python scripts.  On Windows these are a moot point, but on Linux they can still be an issue if the platform doesn't provide a python2 command.  Might be worth looking into that before merging this pull if there are any interesting Linux distros where that command isn't available.

@jaseg Could you rebase this pull so it can be merged without conflict? Also please add yourself to AUTHORS (see CONTRIBUTING.md).
Just to recap, the situation after this merge would be:

Executing python util/make_dist.py will work as long as "python" is Python2.
Executing python2 util/make_dist.py on systems where "python" is Python3.
util/make_dist.py will use /usr/bin/env python2 which won't work on some systems, but you can run make_dist.py with explicit Python interpreter command. This is not easily fixable because of shebang limitations.
Saying make dist will assume "python2" exists; if it doesn't, you can run make_dist.py manually.

The Makefile fix could maybe be improved to say:
which python2 python

That way if the system only has "python" which is Python2, it'd work without manual disting.
@markand is working on a CMake top level Makefile which would be applied on top of this pull. The core dist tools would remain the same so CMake wouldn't be needed to run the raw dist step.

@svaarala I have updated and rebased the commit, also including the "which python2 python" hack.
Your observations should be correct.

@jaseg Thanks, merged :)


Keep intermediate temp folder by default

Requirements

[x] Is there a issue open describing the motivation for this pull request ?
[x] Does the pull request need an update of the documentation ?
[x] Does the pull request need additional test(s) ?
[x] Clean up the warnings generated by the style guide

Description of the Change
By default, intermediate temporary folders (which are located inside the parent temp folder) are erased, which makes it difficult for debugging each registration step. Better to keep them in default behaviour.
Applicable Issues
Fixes #1693

on https://github.com/neuropoly/spinalcordtoolbox/pull/1694#pullrequestreview-115268527: you're right @zougloub. I've now made removetempfile=0 by default in the parent function, since nowadays the temp files are located in /private/var/... i guess this is not an issue and it will enable users to access their processed files if they were not aware about the -r flag.

While I approve the code changes, I don't think defaulting to keeping "temporary" files is the best.


OS X Building Error

I followed the building instructions, and after obtaining an SDL include error, I followed the instructions from Issue #203 to fix it. But now, another error has popped up, and I am not sure what is causing it:
--- stderr
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "Failed to run `\"pkg-config\" \"--libs\" \"--cflags\" \"sdl\"`: No such file or directory (os error 2)"', ../src/libcore/result.rs:837
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Do you have any idea what might be causing this issue?

Looks like you might not have pkg-config installed.
Try running pkg-config on its own in your terminal. If it isn't there, you should be able to install it with Homebrew:
brew install pkg-config

After that (or if you already have it) try to run this directly:
pkg-config --libs --cflags sdl

It should succeed and print out something like this:
-D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/SDL -lSDL -lpthread

(I'm on Linux now so your output will not be exactly the same)
If that fails, can you make sure you have SDL installed?
brew install sdl

Thank you for the assistance, it was pkg-config that was missing.

Sorry for the complication. I don't own a Mac so I hadn't realised pkg-config isn't installed by default until you hit it. I've created a pull request that adds it to the readme.


Revert "WIP Dashboard diaper drive number addition"

Reverts rubyforgood/diaper#381

Fixes Aaron's premature merge.


API Key Authentication - Repurpose p

Derived from https://gist.github.com/kgarner7/33a6ab836528837b7ece44409ceb2d95, with numerous suggestions from @deluan and @jeffvli and discussion in Navidrome Discord.
In short:

Proposes redefining the meaning of p to be API Key, instead of password. Provides guidance for servers on providing these keys, as well as one new endpoint for client benefits for documentation.
Recommends deprecating token/salt-based auth.
Recommends a new endpoint/authentication scheme, Media API key, which uses temporary tokens generated by the server. While I believe this would be a benefit for both clients and servers (especially for things like rpc), I'd be fine backing out this change.

Ultimately, this proposal isn't anything revolutionary (like using OAUTH2, refresh tokens/etc).
The primary goal is to provide a way for clients/servers to authenticate without either party having to store the user's passwords in a reversible fashion.
By repurposing p for this, clients require no functional changes (although some UX to note API key and point to URL), and server changes should hopefully be minimal.
I also recognize other parts of the page should probably be updated with the new auth scheme (if accepted). This is a draft, after all.

Why do all the discussion outside of this forum where all the involved parties can interact?
Anyway the repurpose of p to be an API key is 100% agnostic to the clients, supporting an header that also requires the username as a query param does not really makes sense from a security pov on the contrary.
So there's no need for an API extension to expose this and servers can already do that.
An extension would be needed if we replaced the auth for an API token that does change the API surface and that contains the information about the user and the perms.
That also brings the question of the getopensubsonicextensions that we may need to make non authenticated so clients can know about new auth support. (But with the risk of exposing more attack surfaces with anyone knowing about all new endpoints, small as they can scan them anyway).
The other issue is the media key, while the need is real, it's a breaking change, as to use them we would need to not pass the actual auth to the endpoints. (And support should be for all endpoints, users can use stream to download, and will require the lyrics and ... should not lead to random results depending on the server).
And IMO they should be tied to specific media and not a generic key, 90% of the servers use incremental number ids so once you have 1 url with the key you have access to everything.
And as a reminder: OS API must not have should on API endpoint support or parameters or anything API surface related. It's either must, or there's an API endpoint that allows for clients to list what is supported and what is not. Let's keep the main purpose of OS: Clients must be able to have something deterministic when they use the OS API.

The last time the auth issue was updated is multiple months ago. Given the considerable inactivity (and the discussions being quiet as a whole) I wanted to work in a forum where I could get rapid feedback and get something out to force the issue again.
2 Redefining p (and deprecating salt/token auth) is at the very minimum a clarification.
Especially with an endpoint (keyUrl) to get metadata about the keys, it is a change clients would need to know. Even if this is the only thing of this that survives, I would still insist that this should be an extension. Specifically because there would be need for client UX to reflect that this is an API key, not a password. Some servers may already do this, while others may not which already leads to client differences. Explicitly forcing servers to have separate client authentication from password is the ultimate goal. (I guess technically there isn't a reason to deprecate salt auth either, as that can also be API key)
I would personally love for the token and username to both be part of header (or just require token and no username). Dropped token in header and username in query is also fine
Are you saying media keys (or something similar) would need to be item-specific? I don't know how it is breaking for clients as-is, because it's a new parameter. I understand the "should"s being annoying there, and I would also be fine just having it for just coverArt and stream. Or not at all and dropping this portion entirely.
As for the other should (around scoping), this is because I have very little faith it would be possible to agree on a set of api endpoints for various scopes. I would love to codify a set of endpoints per different scopes and return that (and allowed music folders) in some endpoint which validates a token, but I don't want to discount servers having their own ability to scope and was worried it would be too complicated server-side.
I suppose related, but yes, I would say that getOpensubsonicExtensions should be unauthenticated, as that is the only way a client would be able to know what authentication the server supports. At least, it would be necessary with this extension as it is specifically related to authentication unless clients have to rely on checking for the presence of a generic keyUrl endpoint.

The whole problem is that if nothing is properly codified then it's the return of the mess on the client side.
Refactor of p:

The keyURL does not bring anything or anyknowledge to the client, it's just an url for the user to read things, the client can't deduce anything, specially if you want that call to be not authenticated, the client does not know if the p is a password or an apikey for that user, and in all cases it absolutely does not matter for the client.
If the server want's to enforce apiKey, then the proper solution is to add a new error code when the user tries to use the API with it's password, error 42 for example with the message being that url so the client is aware and can properly know when to redirect the user to it. (Or eventually add a new field helpUrl to the error messages, to support both a specific error message and an url for the user).
If the API key can have specific permissions that are different from the normal Subsonic behavior, then it should be codified and a new endpoint must be added so the client can know what it can call. Having calls erroring very deep in client codes without even a way to know that it's because the API key is restricted is not a proper way for clients to deal with and warn users. Clients having a call to know what they can do and warn the user before doing things that the API key is restricted is the proper way. (Specially if you want the API key to limit to some music directory too)

TL;DR; there's no need for an apiExtension to refactor p to be an API key if the server wants, just a new auth error. Even older clients, will see an error and show an error to the user making them go to the server GUI to check.
If you want to do more then a proper global solution is needed, new param apiKey that replace u/p/t ..., endpoint to know what the apiKey have access to, and eventually other information like a duration, limited to a media, ...
mediaKeys:
Imo they need to be per media for security purpose. A key might be requested for a long duration and give access to everything via the known ids.
And if you want them you need to support them in all the endpoints related to playing those media including download, lyrics and everything. Why would an user be able to play a media but not access the lyrics when using those when it would work with another key.
And if we add support for apiKey for the auth then we can reuse it for the media access by generating temporary apiKey limited to 1 media. That simplify things and is in line with a proper simple auth scoped API.
But to resume, the very most important part will always be: No should and if there's scoping then the scoping needs to be codified for clients to know and warn the user properly. We do not want to return to random behavior between server with what we add, this break the most important contract of OS.
TL;DR:
Choice 1) allow server to enforce apiKeys as P by adding a new error code and an url for the user to create / manage them.
Choice 2) really implement scoped apiKeys that replace auth, have an end point to know the associated permissions and details.
Choice 3) same as 2, but add an endpoint to request temporary apiKeys scoped to readonly for a single media.
Remaining question about "mediaKeys" what about scrobling ?
Personal opinion, since oauth2 would probably be too much work for most servers / clients anyway, I think apiKeys as already suggested in the other threads is an acceptable auth system for apps and so think 2 or 3 are a nice solution as long term permission improvement and would solve a lot of current issues.

By repurposing p and renaming authentication labels on clients, does this mean we have to officially drop forward authentications using LDAP, PAM, etc.?

No, such repurpose as explained in point 1 would be server side only with a new error code and fully optional as it would not change anything at all from client side.
Client could optionally support the new error code to update it's interface to say it requires an API key.
Forcing changes to p is a breaking change and not compatible with OS.

I am not sure to understand. With a given p value, how does the server can know it is an API key or a regular password to instruct the client via an error code?

Well the obvious way is that if the server want to force apiKeys in p it check if the key exist and return the error?
It's internal to how the server want to deal with this if we choose this simple change that have 0 impacts on clients.

Just to add my 5 cents, using the p argument for a generated API key is what the Subsonic backend on the Nextcloud Music has been doing from the day one, so that's definitely already possible as @Tolriq has been telling. We have never supported passing the actual user password to the Subsonic API. If the given p is not a valid API key, then we just give the error code 40 with message "Invalid login". Having a dedicated error code in case the p is actually the password of the user could of course improve the UX on the client.
What would actually improve the security, would be to have the concept of user session in the Subsonic API with a temporary session token. This way, the actual permanent API key (or password if you will) would be used only on one handshake message and most of the API communication would happen using a temporary token obtained as a result of the handshake. This would fix (or at least improve the situation with) what I see as the main problem of the current system: Quite often the users post their log files online with their bug reports, without detracting the p from the list of the URL arguments. I suspect that this happens more easily in case the client uses the enc: format to pass the p argument because that makes it less obvious that the password is there in fully readable format.

One of the problems with expiring tokens that has been discussed is clients often rely on semi-permanent URLs for streaming tracks (and sometimes fetching images) - for example if the user has loaded up a play queue on a client, and they pause the app for weeks or months at a time, and then return to it, the playback URLs for the tracks in the queue should still be valid (unless explicitly revoked by the user) or else playback may fail.

Just to add my 5 cents, using the p argument for a generated API key is what the Subsonic backend on the Nextcloud Music has been doing from the day one, so that's definitely already possible as @Tolriq has been telling.

I would actually make the argument that that is not compatible with the current spec, since the current spec implies all logins are password-based, so clients will ask users for their "password" not "API key", which could potentially lead to a confusing UX. I suppose if Nextcloud music makes it very clear in the docs or when creating a key that it should be used instead of password for all Subsonic clients, that may clarify things a bit, but it would still be nice if the spec is designed such that the client knows when to ask for an "API key" vs "password"

for example if the user has loaded up a play queue on a client, and they pause the app for weeks or months at a time, and then return to it, the playback URLs for the tracks in the queue should still be valid (unless explicitly revoked by the user) or else playback may fail.

Why would the client store the playback URL of all the tracks on the queue? The URL may be formed based on the song ID the moment the playback starts (or is resumed). If then playing the URL (or any other API call) would fail with "session expired", then the client would need to start a new session and retry the operation. Of course that would require adding a small bit of extra logic but there are no free lunches.

for example if the user has loaded up a play queue on a client, and they pause the app for weeks or months at a time, and then return to it, the playback URLs for the tracks in the queue should still be valid (unless explicitly revoked by the user) or else playback may fail.

Why would the client store the playback URL of all the tracks on the queue? The URL may be formed based on the song ID the moment the playback starts (or is resumed). If then playing the URL (or any other API call) would fail with "session expired", then the client would need to start a new session and retry the operation. Of course that would require adding a small bit of extra logic but there are no free lunches.

Many (most?) clients don't handle streaming the audio data themselves but pass the stream URL off to a 3rd party framework for playback (libmpv, etc). Clients that play gaplessly must at a minimum have the next-up URL loaded by the playback library ahead of time. So if a users pauses a play queue for a long time, both the current and next playback URLs should remain valid in order to avoid playback errors. Also, with 3rd party playback engines it may not be possible to detect and handle a specific auth error differently than a generic "playback failed for some reason" error

I think that mediaKey should be added as an extension of the user instead of a separated into an endpoint.

The user in Ampache has:

password
ApiKey (used for password auth in Subsonic)
StreamToken (Ampache version of mediaKey)

The streaming token can only stream media and all streaming URLs are generated using this token when it exists. Adding it to the user allows a client to build their own URL's with the token

If i extended this to Subsonic I don't need to make any changes to the Subsonic API outside of:

Add the StreamToken to user responses.
Allow user access to stream, download and scrobble methods using this key
Allow user reset of this mediaKey in updateUser or separate method

This would all be transparent to older clients without the need for new endpoints.
In regards to removing / deprecating / changing auth parameters a new error message to say "deprecated/removed" and then as a server I can allow or deny access to this auth method with a config option on the server.
A blocked by default approach means people can still open their servers up and we can push people towards different methods.
To extend though; I still think the simplest path is to move these parameters out of the URL and into headers, Ampache uses a Bearer token and supports all types of auth. This would allow a server to block auth from the URL (optionally) and require header auth instead.
If you recommend header auth, implement a streaming mediaKey and allow block auth-related URL parameters on the server you've solved most of the problems of having reversible / plaintext auth in the URL.

Quite often the users post their log files online with their bug reports, without detracting the p from the list of the URL arguments.

This is the server job to hide those usually, most tools either directly hide them or have a download redacted logs button.

I would actually make the argument that that is not compatible with the current spec, since the current spec implies all logins are password-based, so clients will ask users for their "password" not "API key", which could potentially lead to a confusing UX

This is not breaking in sense of API, from API pov a password or an API key does not change anything. With a new error we improve user feedback. (But in all cases I still think that a new auth with apiKey that replace u + p is better globally)

I still think the simplest path is to move these parameters out of the URL and into headers,

This was explained a lot of time already that this is not possible due to casting and some renderer limitations, it is not possible to have upnp devices send headers for example.
If we start to mix a new enforced auth via headers and another one via keys for some endpoints, this becomes really messy and we should directly rewrite new endpoints.

So @kgarner7 what do you prefer?

Just the error code to allow quick solution server side only.
New apiKey auth system that replace current system (So without different permission level handlingà
New apiKey auth system with support for scoping (Access points, library, media)

So @kgarner7 what do you prefer?
* Just the error code to allow quick solution server side only.

* New apiKey auth system that replace current system (So without different permission level handlingà

* New apiKey auth system with support for scoping (Access points, library, media)

Sorry for the delay. I think the best (and simplest) way to move forward would be starting with option 2, an api key auth (just API key in header, or k/something similar for query parameter). I would love to have expiring tokens/scopes, but that might be best as a v2?

Ok so :
Quick proposal to actually write :) It's a quick global view as busy right now.
Generic:

extend error message with an optional helpUrl field that can help for a few cases.

Version 1

new error code 42: Password authentification disabled, use api keys.
getOpenSubsonicExtensions no more requires auth to access (But needs proper docs as the general doc says auth is always mandatory)
new extension apikey version 1
new query param k=XXXX for auth everywhere. (Name TBD maybe token or apiKey to be more explicit, no need to be a single char)

Version 2 (extension to V1) (so extension apikey version 2)

All from version 1 +
new error code 51: apiKey does not have access to this resource
new error code 52: key validity duration requested exceed maximum allowed value
new endpoint getApiKeyPermissions -> describe the scope and perm of that key TBD with a proper schema
new endpoint requestApiKeyForMedia (param: songId + duration) return key + expiry or error 52 or 70 (returns an api that have access to everything related to the media, stream, download if the server allows download, lyrics, ... in all cases clients can use the stream endpoint to download.

If that works for you and have time to actually build the PR.
I think this is more in line with the spirit of OS in regard to API definition, retro compatibility, predictability and everything

Since I suspect scopes (if they even make it in) would take quite a while, I'll probably advocate for something more like:

V1 (as is)
V2 (or also v1) temporary token for explicitly denoted endpoints
V3 (if it happens) scope.

 Thanks!

Unfortunately IMO in the way OS API is supposed to be build, to be able to have temporary token we need a way to know the limits of that token and so the scoping.
I do not think it makes sense to have 2 different end points for the scoping data specially if from a key we can't guess it's type and from the needs exposed I do not think there's a need to have different keyType with different parameters to achieve the same purpose.
BTW I forget but maybe also add an error 43 or whatever Invalid apiKey to differentiate from invalid login/password ?

Thanks.
@kgarner7 a few quick notes:

If you want the keyUrl tied to the extension then the extension page doc must say that that endpoint is part of the extension and needed so that the extension page covers all the new endpoints.
Same for mediaKey
For mediaKey I still think that support for download and getlyrics is mandatory for clients to be able to really use all the media related functions.
I would add an error 44 Invalid apiKey
depending on how servers would store the mediaKey I think that an error 45 Expired apiKey could make sense, but if servers quickly purge the temporary keys then they won't be able to return it.
? new error code 51: apiKey does not have access to this resource
? new error code 52: key validity duration requested exceed maximum allowed value

All those are mostly details, but I think there's one thing that needs discussion / validation by more clients / servers:

Expiration, in seconds. Minimum value of 60, maximum of 86400 (1 day)

Any reason / arguments on those specific values?

...I actually meant to remove key url and other parts

Lol sorry some merge error then :) Will wait before commenting again :)

Nah, that's just my bad for not paying attention for commit. Anyway, I've removed any reference of the v2 temporary key stuff (and keyUrl is redundant with changes to error)

Ok so still the question about "an error 44 Invalid apiKey" to differentiate from the 40 invalid login/password. Else change the message / description of 40 to also cover apiKey ?
And api-reference still talk about passing the Authorization header. If this is wanted it should be documented in the extension too.
With a clear both must be supported as having the header optional would be hard to detect for the clients.

Optional question but could there be a case in your needs for v2 where a key could not be tied to an user and we should define a default value? (Probably not but just checking)

Optional question but could there be a case in your needs for v2 where a key could not be tied to an user and we should define a default value? (Probably not but just checking)

If we are allowing API keys to exist that are separate from users (e.g. system account, say for just Jukebox/images), then I think for something like that it would make sense for the username to be possibly null.

null is not valid, so if would be empty if not a well know value. For the if that's the question, I can't think of a reason but maybe some were evoked during the initial talk of this hence wanting to confirm.
If not, then let's merge this. In the worst case we can amend with a comment the empty state that would not change the API surface unlike a well know value that could be already used by a server as username and we"d need to protect somehow.

null is not valid, so if would be empty if not a well know value. For the if that's the question, I can't think of a reason but maybe some were evoked during the initial talk of this hence wanting to confirm.
If not, then let's merge this. In the worst case we can amend with a comment the empty state that would not change the API surface unlike a well know value that could be already used by a server as username and we"d need to protect somehow.

Unless a server maintainer thinks (for v1 or v2) that they would return no user (please chime in here), I think requiring it for is correct. Could always make it optional in v2 if necessary

Yes requiring is ok. But no we can't make a required field optional later this is breaking change for any client that enforce the schema or is not prepared for a missing field that was marked required.
That's why I talked about empty vs / well known value.
But let's merge, we can amend later that empty is valid that is not a breaking change. Unlike a well known value that some servers may have decided to allow as user name and could then be a conflict.

@opensubsonic/servers please review.
Please note the change to the Get extension being public now. Even if you do not support this endpoint in the future making that change for get extension would help clients.

Hello!
Just started to implement this on LMS.
Auth tokens are often considered as a "weak" authentication, and changing passwords usually require a "strong" authentication.
I am actually referring to https://opensubsonic.netlify.app/docs/endpoints/changepassword/
For this new auth mechanism, what would be do for this endpoint? Ignore? Error? Update the auth token?

Hello! Just started to implement this on LMS. Auth tokens are often considered as a "weak" authentication, and changing passwords usually require a "strong" authentication. I am actually referring to https://opensubsonic.netlify.app/docs/endpoints/changepassword/ For this new auth mechanism, what would be do for this endpoint? Ignore? Error? Update the auth token?

I'll be honest, I wasn't aware there were servers which supported Subsonic username/password changing. Did you settle on a choice there?
As written, I would say, yes, changePassword should also accept an API key, but that doesn't really make sense to me.
Are there any clients that use this endpoint?

In dsub there is an admin section that you have to renter your password manually to enter. You can edit users from the admin panel after login

Hello! Just started to implement this on LMS. Auth tokens are often considered as a "weak" authentication, and changing passwords usually require a "strong" authentication. I am actually referring to https://opensubsonic.netlify.app/docs/endpoints/changepassword/ For this new auth mechanism, what would be do for this endpoint? Ignore? Error? Update the auth token?

I'll be honest, I wasn't aware there were servers which supported Subsonic username/password changing. Did you settle on a choice there? As written, I would say, yes, changePassword should also accept an API key, but that doesn't really make sense to me.
Are there any clients that use this endpoint?

Not yet, I had to pause this subject. I think I will likely remove these endpoint implementations and think seriously about them if someone complains...
About this in the doc:
Servers which implement this extension must provide some mechanism for viewing active API key(s) and allow for revoking API keys. Note that these API keys do not expire; as long as they are not revoked by the user, they are assumed to be valid.

Actually nothing prevents the server from storing the API key salted and hashed? A user could enter/generate their API key in the server interface, and then enter the same key on their clients. The user could then only revoke/recreate an API key in the server interface, but for me it is actually just a server implementation detail, not sure it should be an API enforcement?

Yes it's internal server details.

@kgarner7 I have a question about legacy clients.
For a server that implements the new extension, is there no change to the user/password authentication method, or do you expect the provided password to actually be the authentication token (to make legacy clients work with the new tokens)?

@kgarner7 I have a question about legacy clients. For a server that implements the new extension, is there no change to the user/password authentication method, or do you expect the provided password to actually be the authentication token (to make legacy clients work with the new tokens)?

Up to the server, ultimately. Having Subsonic credentials separate from the server login in general is good (and honestly, it'd be nice for an option to only do api key auth). Having apiKey as the password as a fallback (at least for v1) is a reasonable alternative.

Hmm, okay. I'll seriously consider adding an option for the legacy user/method authentication, either to disable it or to fall back to checking the password as an authentication token for the provided user (with the latter being the default behavior).
This approach would also drop PAM/LDAP authentication from the Subsonic API for LMS. However, we now have a well-defined API key for that, and I believe this is still better than passing user passwords in plain text in requests, server logs, and so on.

In the Subsonic backend of Nextcloud Music, I have always used API key for authentication, and the users have just been entering it as "password". I have now added the support also for the apiKey argument (will be released later in v2.1.0) to match this new extension, but that will of course change nothing for the old clients.
My server doesn't implement the changepassword endpoint, but if any server does, then I would highly recommend them not to allow changing the user's actual login password when authenticated just by an API key. As I see it, one of the major benefits of using an API key is to be able to give some client just a limited access to your server, and limit the potential damage if the key is leaked. But if anyone knowing the API key can hijack your account, then that kind of defies the point.

Hello,
I have implemented this new extension in LMS (currently, it is available only on a branch). A public demo instance is set up here: https://lms-demo-os.poupon.dev/.
On the settings page, you will find the API key required for the Subsonic API.
Feel free to test it out and report any issues!

Symfonium will have basic support for apiKey auth in next release too.


Add instant search results.

Show search results as they come up from the index, depending on what the user is typing.

⚠ Idea migrated from UserVoice
Created By: Den Delimarsky
Created On: 2016/11/01 20:02:38 +0000
Votes at Migration: 9
Supporters at Migration: 8

@botcrane  thank you for the feedback. Just to clarify my understanding first - do you expect something like returning search results instantly when the user is typing? Yes, we have that idea internally and had lots of discussion on it. We have that kind of behavior in API browser. This gives you instant results when you are typing namespace, type, and member name. But in search page, users have chance to organize the search query within more terms before hitting the search button, this is more like a search engine behavior. It will be very helpful for us to know if there has any specific scenario in search page can help you if we convert to the instant search behavior. Thanks!

Love the idea of showing search results instantly when user is typing. This has been discussed internally several times whether or not to enable that behavior. Searching from entire documents in Docs every time when user is typing or deleting a single character is challenge to search engine and user experience won't be that good. This can be doable if having a smaller documents set and will have much better user experience. At current phase, we focus on improving search relevance and the experience of presenting the search results. We continue investigating the possibility of enabling instant search results behavior. But it is lower priority than the work of improving the search core.

Created a customer suggestion work item to track this suggestion.

Search suggestions are displayed when the user is attempting to find content from the header.


Update Existing Automation

We renamed the repository to align with the new branding from iDaaS-Connect to IntegrationFramework-HDF. We now need to go ahead and update all the automation to ensure the assets deploy properly.

we need to add this to the right repo


Use the k8s context's username & password to connect to the cluster

We've had issues using the template-tester on some of our clusters. Pass the kube context username & password along to connect to the cluster.

Thanks!


Discover Control Tower deployment does not seem to be picking up environment modifications

Followed the deployment guide for Falcon Discover with Control Tower (https://github.com/CrowdStrike/Cloud-AWS/blob/master/Control-Tower/README.md).  CloudFormation run in Master Account and LogArchive account, then StackSet manually pushed to existing accounts.
Accounts were registered in API...EC2, EBS, and VPC data picked up and reported after registration...but then subsequent changes (i.e. termination of a test EC2 instance) were never reflected in the CrowdStrike console (been approximately 5 days now).
Assistance would be appreciated.  Please let me know what other information would help.  Thank you!

Thanks for reporting this @syn7ack!
Bump to @jhseceng , who authored much of this code.

Hello.   From your description it sounds like the configuration of the log archive account is somehow incorrect.   If you are seeing instances ok that would imply that the stacksets are successfully being applied to accounts in the org.    Would you check that you successfully applied the CFT to the log archive account and that the s3 bucket is setup to send the sns notifications to our sns topic.
A description of how the service operates can be found here.
https://github.com/CrowdStrike/Cloud-AWS/tree/master/Discover-for-Cloud-Templates/AWS#how-crowdstrike-discover-works
Here is a script that you can use to query our API to check the configuration of your log archive account.
https://github.com/CrowdStrike/Cloud-AWS/tree/master/Discover-for-Cloud-Templates/AWS/troubleshooting/scripts
(The script uses FalconPy) https://github.com/CrowdStrike/falconpy#installation--removal
python3 fd_accounts.py -f CLIENT_ID -s CLIENT_SECRET -c check -l
Example
$ python3 fd_accounts.py -f CLIENT_ID -s CLIENT_SECRET -c check -l
Our support teams will also be able to assist you checking your configuration.

Awesome!  Thank you, @jhseceng!  I will run through these things, and let you know.  Appreciate the quick responses.
Also, just FYI, I do have a ticket out with CS Support, and was hoping to jump on a quick WebEx, but they just relayed me here.

Ok you can contact me at @.*** if you are still having problems
Get Outlook for iOShttps://aka.ms/o0ukef

From: syn7ack @.>
Sent: Friday, May 28, 2021 7:02:00 PM
To: CrowdStrike/Cloud-AWS @.>
Cc: jhseceng @.>; Mention @.>
Subject: Re: [CrowdStrike/Cloud-AWS] Discover Control Tower deployment does not seem to be picking up environment modifications (#80)
Awesome! Thank you, @jhsecenghttps://github.com/jhseceng! I will run through these things, and let you know. Appreciate the quick responses.
Also, just FYI, I do have a ticket out with CS Support, and was hoping to jump on a quick WebEx, but they just relayed me here.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/CrowdStrike/Cloud-AWS/issues/80#issuecomment-850581438, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AODNMEDUZS5H63T5VTICWY3TP7LBRANCNFSM45U6OU2Q.

Good morning, @jhseceng.  I checked in our Master account, LogArchive account, and another account, and I am not able to find any SNS topics that match the format specified in that link you sent.  I'm also struggling to get FalconPy installed because of some "SSL: Certificate_Verify_Failed" errors from pip.
Your email address just came through as<EMAIL_ADDRESS>so I am unable to reach out.  The ticket I've currently been working on with CS Support is 00517406.  Not sure if you are able to initiate contact through that?

Ok that makes sense.  You will need to load the log archive account cloudformation template that will set that up for you.   https://github.com/CrowdStrike/Cloud-AWS/blob/master/Control-Tower/documentation/implementation-guide.md#step-2-configuration-solution-to-deploy
Step 3.
Let me know if that works ok for you.
Get Outlook for iOShttps://aka.ms/o0ukef

From: syn7ack @.>
Sent: Tuesday, June 1, 2021 1:45:44 PM
To: CrowdStrike/Cloud-AWS @.>
Cc: jhseceng @.>; Mention @.>
Subject: Re: [CrowdStrike/Cloud-AWS] Discover Control Tower deployment does not seem to be picking up environment modifications (#80)
Good morning, @jhsecenghttps://github.com/jhseceng. I checked in our Master account, LogArchive account, and another account, and I am not able to find any SNS topics that match the format specified in that link you sent. I'm also struggling to get FalconPy installed because of some "SSL: Certificate_Verify_Failed" errors from pip.
Your email address just came through as @.******", so I am unable to reach out. The ticket I've currently been working on with CS Support is 00517406. Not sure if you are able to initiate contact through that?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/CrowdStrike/Cloud-AWS/issues/80#issuecomment-852094751, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AODNMEGN3RLDDPBI3LPJBF3TQTI7RANCNFSM45U6OU2Q.

@jhseceng, so that was run back on 5/21 when I was initially setting this up.
I did find the configured S3 bucket notification that references that SNS topic, so it appears to have set everything up correctly.  Not sure why these environment changes are not reflecting, in that case.

Next check the IAM role is in place and the external ID. You can then ask via the support ticket that our support team check the settings for the log archive account.
Get Outlook for iOShttps://aka.ms/o0ukef

From: syn7ack @.>
Sent: Tuesday, June 1, 2021 2:52:54 PM
To: CrowdStrike/Cloud-AWS @.>
Cc: jhseceng @.>; Mention @.>
Subject: Re: [CrowdStrike/Cloud-AWS] Discover Control Tower deployment does not seem to be picking up environment modifications (#80)
@jhsecenghttps://github.com/jhseceng, so that was run back on 5/21 when I was initially setting this up.
I did find the configured S3 bucket notification that references that SNS topic, so it appears to have set everything up correctly. Not sure why these environment changes are not reflecting, in that case.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/CrowdStrike/Cloud-AWS/issues/80#issuecomment-852143280, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AODNMEBMU6Z4RVQUVIXOSRTTQTQ3NANCNFSM45U6OU2Q.

The IAM role from the CloudFormation template does exist, and the external ID in that role matches the registered account info in the CS API.
New CS Case opened: 00526699

Ok thanks.  We will work with you via the case number
Get Outlook for iOShttps://aka.ms/o0ukef

From: syn7ack @.>
Sent: Tuesday, June 1, 2021 3:32:37 PM
To: CrowdStrike/Cloud-AWS @.>
Cc: jhseceng @.>; Mention @.>
Subject: Re: [CrowdStrike/Cloud-AWS] Discover Control Tower deployment does not seem to be picking up environment modifications (#80)
The IAM role from the CloudFormation template does exist, and the external ID in that role matches the registered account info in the CS API.
New CS Case opened: 00526699
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/CrowdStrike/Cloud-AWS/issues/80#issuecomment-852175087, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AODNMEB3KBAQH4PJIXBSXE3TQTVQLANCNFSM45U6OU2Q.

Closing as stale.


Typing problems in groupby method

Bug description
For <Proposal>.groupBy method, the _count value has a invalid type, it should only be a boolean as we can see in the doc :

https://www.prisma.io/docs/reference/api-reference/prisma-client-reference#groupby

This error let the developer make this type of code:

Witch let thinking that it would only return the count of elements which is in accord with the object definition (only merged proposals).
How to reproduce

Use <Model>.groupBy method with _count property

Expected behavior
Only have the optional typing as written in the doc (which make more sense)
Prisma information
generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model Proposal {
  id            Int           @id @default(autoincrement())
  merged        Boolean       @default(false)

  // table content removed

  @@map("proposals")
}

Environment & setup

OS: Docker Node Image based on Ubuntu
Database: PostgreSQL
Node.js version: latest

Prisma Version
prisma                  : 3.7.0
@prisma/client          : 3.7.0
Current platform        : debian-openssl-1.1.x
Query Engine (Node-API) : libquery-engine 8746e055198f517658c08a0c426c7eec87f5a85f (at<EMAIL_ADDRESS>Migration Engine        : migration-engine-cli 8746e055198f517658c08a0c426c7eec87f5a85f (at<EMAIL_ADDRESS>Introspection Engine    : introspection-core 8746e055198f517658c08a0c426c7eec87f5a85f (at<EMAIL_ADDRESS>Format Binary           : prisma-fmt 8746e055198f517658c08a0c426c7eec87f5a85f (at<EMAIL_ADDRESS>Default Engines Hash    : 8746e055198f517658c08a0c426c7eec87f5a85f
Studio                  : 0.445.0

Hi @DraftProducts and thank you for taking your time to prepare the report and the linked PR!
As far as I can see, there's no bug and the type is actually correct, but the documentation could be improved here. You may, in fact, pass an object to the _count argument of groupBy, similar to how it works in the standalone count operation: https://www.prisma.io/docs/concepts/components/prisma-client/aggregation-grouping-summarizing#count-non-null-field-values
Now where the confusion comes from is since your field is a boolean one, _count: { merged: true } might read like it means "count all records where merged is true", but that's not what happens. What this actually means is that Prisma will count the records where merged is not NULL. You can also pass _all in that object to count all records in addition to counting instances of non-null fields.
In other words, if you make the merged field optional in your example and run this:
  await prisma.user.create({
    data: {
      proposals: {
        createMany: {
          data: [
            { merged: true },
            { merged: false },
            { merged: null }
          ]
        }
      }
    }
  })

  const proposals = await prisma.proposal.groupBy({
    by: ['userId'],
    having: {
      userId: {
        not: null
      }
    },
    _count: {
      merged: true,
      _all: true
    }
  })

You will get this as the result:
[ { _count: { merged: 2, _all: 3 }, userId: 3 } ]

I'll go ahead and close this issue, feel free to reopen it if I missed anything.

Sure, thx for the review and the time that you invest in Prisma, it's really fantastic!


spec v2.0 and configuration file

I just wanted to say that the v2.0 of the spec is out and that I relaunched the discussion about having a standardized configuration file across all clients (and platforms).

Thanks, @noraj.
I will read the thread to getting some context.


bug: handle subpixel values in viewport dims

Rounds the dimensions on the DOMRect of the in-viewport element since
jQuery.innerWidth() (or height) return integers.
Element.getBoundingClientRect() can return subpixels (as floating
point numbers) that if not handled will result in elements not being
considered in the viewport by the is-in-viewport helper (even though
they are).
This is particularly important when the user has zoomed the window,
in which case the browser may scale the size of the viewport, resulting
in the dimensions having fractional parts, e.g., the width might be
1451.1112060546875.
Closes #96
Details
Rounds the right and bottom properties on the DOMRect returned from Element.getBoundingClientRect() on the element being checked to integers.
Functional Testing
I have tested by npm linking this change against this repo and verifying that the viewport detection works correctly.
I have personally tested in recent versions the following browsers on OS X El Capitan using the above method:

Firefox
Safari
Chrome

cc @offirgolan

@les2 thanks again for seeing this issue through. The change makes sense and looks good to me but it seems as though tests are failing.

Will not support IE<=8 because the width/height properties are not available. Do we care about that?
There may be other problems with IE<=8 --- I don't even have an IE testing VM around anymore!

I think we should fallback to the default implementation using jQuery innerWidth and innerHeight if getBoundingClientRect isnt there. That way this fix is backwards compatible for people still wanting to support IE<=8

will update shortly.
i think i forgot to rebase away a failing test i added which does not apply
to my implementation.
On Sun, Dec 4, 2016, 6:09 PM Offir Golan<EMAIL_ADDRESS>wrote:

Will not support IE<=8 because the width/height properties are not
available. Do we care about that?
There may be other problems with IE<=8 --- I don't even have an IE testing
VM around anymore!
I think we should fallback to the default implementation using jQuery
innerWidth and innerHeight if getBoundingClientRect isnt there. That way
this fix is backwards compatible for people still wanting to support IE<=8
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/DockYard/ember-in-viewport/pull/97#issuecomment-264739347,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABBEYBbUSniTUQfc8NwCf9-z2-8tveUKks5rE0gUgaJpZM4LDpi6
.

Not sure what's going on with tests.

on master branch, acceptance test hangs for me
on this PR branch, PhantomJS hangs but Chrome passes (only Chrome is run in CI)

How do you ask travis to run the tests again?

@offirgolan @poteto All checks passing / all feedback received so far is addressed. Please let me know if there's something further I can clean up.

@kellyselden thoughts on this one? pinging you since you are the second most active contrib. here next to @poteto

OOOPS! Just found a huge bug! I'll fix shortly. It got added when the if-else was added for fallback behavior! cc @offirgolan

Okay - fixed bug! ready for review again.

Tests are failing, can you fix please?

will take a look when i get to a computer.
On Tue, Dec 13, 2016, 2:24 PM Lauren Tan<EMAIL_ADDRESS>wrote:

Tests are failing, can you fix please?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/DockYard/ember-in-viewport/pull/97#issuecomment-266835636,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABBEYGTHjUr5Pd4ueN4afGNHsUXWJ9qjks5rHvDigaJpZM4LDpi6
.

It doesn't look like this addon is targeting Ember 1.x, and since IE 8 was dropped in Ember 2.x, should we not include IE8 compat code in here?

It doesn't look like this addon is targeting Ember 1.x, and since IE 8 was dropped in Ember 2.x, should we not include IE8 compat code in here?

I don't disagree.

@kellyselden Although this addon doesnt target Ember 1.x it doesnt mean that there aren't apps and addons using Ember 1.x with this addon.
If this addon doesnt support Ember 1.x, then publishing this change would have to result in a major release and state that this addon no longer supports Ember 1.x.
The implemented IE8 fallback is literally 2 lines of code so I honestly dont think it should cause much headache. I guess the call here is on the DockYard team to decide what they would perfer.

@offirgolan @kellyselden @poteto I have changed the implementation (mainly to get the tests to pass) and the following is different:

it doesn't change the browser compatibility (it doesn't touch that code)
these new changes are testable and i include some unit tests

I have updated the commit message / PR description to match.
Please review again when you can.

ping @poteto.

Happy New Year, @poteto .
anything you want to see changed? I've deployed a patch for this in production for work and have seen no problems.
would like for other users of this addon and ELT to enjoy this bug fix, too.
I'm happy to make any updates folks think are necessary.

LGTM Thanks for all the work. @les2 @offirgolan

Released in v2.1.1


experiment() test

This function should be tested for two reasons
1 - it will most likely always be used when using this library
2 - it breaks often :)
Just needs to be setup with any agent and any env and run to the end of the experiment.

Done - added tests for Battery, Flex and Cartpole envs


[FIX] Handle Route53 rate limit error

Following the discussion on https://github.com/sky-uk/clusterverse/pull/111 I'm submitting this PR. This change handles the Timeout waiting for resource records changes to be applied: Waiter ResourceRecordSetsChanged failed: Rate exceeded errors introducing a rescue task which, in case of failure, resubmits all the records missed at first glance in synchronous fashion.
This has been extensively tested with 30+ nodes clusters:

tested cluster creation
tested cluster redeploy
tested clean

That's a smart solution @dipiazzg  - nice.


Landing Page List Content

💡 Description
Page content that employs listed entities under common categories, includes the optional ability to expand a list item and display additional content.  Could be featured on any of the landing page types but is only utilized on Investigation and Instrument pages.

See Airtable for additional design notes.
⚔ Parent Epic / Related Tickets
No response

Tasks:

[x] OpenSearch Query for instrument information
[x] Populate list of instruments, grouped by type
[x] Create Instrument List component
[ ] Implement content expansion element


ci: add sbom generation

@j4k4 mind a review?

We've internally discussed this and came to the conclusion that it makes more sense to create sboms for go apps (and libraries which are only distributed as binary), so we are closing this one.


Error in parsing aggregated response

I'm currently working on a big query containing aggregated values. I'm only interested in aggregations.1.value, which in this case would be 396.
The following is the response I get after running the query in ES (v7.3.0)
{
  "took" : 17509,
  "timed_out" : false,
  "_shards" : {
    "total" : 304,
    "successful" : 304,
    "skipped" : 290,
    "failed" : 0
  },
  "_clusters" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0
  },
  "hits" : {
    "total" : {
      "value" : 10000,
      "relation" : "gte"
    },
    "max_score" : null,
    "hits" : [ ]
  },
  "aggregations" : {
    "1" : {
      "value" : 396
    }
  }
}

Here is the error message I am getting in return
Traceback (most recent call last):
  File "/usr/src/app/prometheus_es_exporter/__init__.py", line 117, in run_query
    metrics = parse_response(response, [name])
  File "/usr/src/app/prometheus_es_exporter/parser.py", line 86, in parse_response
    total = response['hits']['total']
KeyError: 'total'

Thanks for getting back!

Hi @puthrichard, sorry you're having issues.
I can't immediately see how the code would produce that key error with that response. My best guess is that the exporter is getting a different response for some reason - possibly some kind of error that's not being handled.
Are you able to run the exporter locally, and add a logging line to the code? If so, please modify the run_query() function in prometheus_es_exporter/__init__.py as follows:
def run_query(es_client, name, indices, query, timeout):
    try:
        response = es_client.search(index=indices, body=query, request_timeout=timeout)

        logging.info('Received response %s', response)  # Add this line

        metrics = parse_response(response, [name])
...

That should log the full response from Elasticsearch. If you could then send me the log output for the response that causes the failure, hopefully I can isolate the issue!


修复http方法typo

这个单测竟然没跪吗。。。

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.ThanksSirAlex seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

@JacksonTian RPCclient 的单测跪了，不是这次引入的问题，有时间可以看一下


fix(error): set params called twice for dynamic imports

Since bodymovin is quite large, we dynamically import the module to avoid heavier bundle sizes.
import animationJSON from './animations/animation.json'
...
  componentDidMount() {
    import('bodymovin')
      .then(bodymovin => {
          bodymovin
            .loadAnimation({
              container: document.getElementById('animation'),
              renderer: 'svg',
              loop: false,
              autoplay: true,
              animationData: animationJSON,
            })
            .setSpeed(0.7)
      })
      .catch(err => console.log(err))
  }

The animation would run correctly, but as it was finishing, I get this error in the browser.

Upon inspection, I discovered that setParams is called twice.

So this adds a check to prevent parsing a parsed or non-existent JSON.

@bodymovin can you take a peek at this, please? we, unfortunately, had to drop bodymovin as a dependency because of this error but would love to reimplement in the future when this is supported!

Hi @trevorwhealy Can you create a small demo of the issue so I can diagnose what is going on?
I'm not sure how is that happening. Even if setParams is getting called more than once, that error seems related to passing an incorrect json object.

Looked into this more and it has to do with the check ready interval in module.js. The check eventually calls this line which calls:
registerAnimation(animElem /* css-class bodymovin */, animationData /* undefined */)

which then tries to load /animation/data.json via XHR. This call results in a 404 HTML page being sent to JSON.parse.
Fixed that error showing by removing the bodymovin css-class right after we call bodymovin.loadAnimation({...}).

@bodymovin ^^

when the document is ready, the player searches on the DOM any element with a class of "bodymovin" assuming that it was intended in order to load an animation in that element.
It's a simple way to load animations in a site without needing any code.
I can add a validation in case the element doesn't have the rest of the needed attributes to load.