[ENG-5472] [ENG-5473] Add original_publication_citation to preprints model and serializer

Purpose
Add original_publication_citation to Preprints model and serializer
The expected value for original_publication_citation is to hold one customized citation that users have entered for their preprints. As show in the phase-2 mock-up.

In addition, Product team has confirmed that this field doesn't require the original_publication_date to be set.
Finally, this is a field without any FE or BE validation, similar to the custom_citation on projects.
Changes
N/A
QA Notes
N/A
Documentation
N/A
Side Effects
N/A
Ticket

https://openscience.atlassian.net/browse/ENG-5472
https://openscience.atlassian.net/browse/ENG-5473

@jwalz thanks for the review, PR description updated

Sweet. Does custom_publication_citation make more sense than original_publication_citation to be less ambiguous? From the name, I couldn't tell if this was a custom citation for this preprint or a manually encoded citation for a published version (i.e. something analogous to publication_doi)

Yes, I agree will make the change.
BE has artical_doi, original_publication_date and will have custom_publication_citation.
Product prefers Publication DOI, Publication Date and Publication Citation respectively for display on FE. I asked and the response is it's OK.

@jwalz PR ready for CR again


2018 Branch - Spawned objects disappear

Describe the bug
ServerStart. Monster1 is spawned.
ClientStart. Monster1 shows up breifly on screen then disappears. Does not show in Inspector.
Server spawns Player1 and Monster2.
Client can see Player1 and Monster2 now.
Client2 connects. It can never see Player1, Monster1, Monster2
Server spawned Player2 and Monster3
Client1 can now see Client2 and Monster2
Basicly. They only ever see what happens AFTER they join.
This all functions perfectly in 2017 master branch.
Repro project
https://github.com/uweenukr/Mirror2018SpawningIssue
To Reproduce
Steps to reproduce the behavior:

Use the listed Windows build for quick verifitcation.
Use the Tools>Build menu in Unity Editor.

Expected behavior
Spawning should show things before the player joined in 2018. Works in 2017.
Screenshots
https://youtu.be/4coimMtkLfs
Desktop (please complete the following information):

OS: Windows
Build target: Windows
Unity version: 2018.2
HLAPI CE branch: 2018 and 2018

After more research it appears to be an issue with NetworkManager.ServerChangeScene(). It may even he a UNET bug as many people have complained about it in 2016 with work arounds like adding DontDestroyOnLoad to all NetworkIdentities.
I also tried the suggestion of setting the connection NotReady before the scene change and Ready after its complete but it had no effect.
https://gamedev.stackexchange.com/questions/139293/why-doesnt-the-current-player-on-the-server-spawn-after-a-new-client-connects
https://stackoverflow.com/questions/41622124/respawn-player-on-scene-change
So this is not a 2018 branch issue. My previous test where 2017 branch worked must have been flawed somehow.

Closing this issue. The method ServerChangeScene() expects all players to be loaded in before its called. I tested it by connecting all clients first then using it. It works fine.
"You can also change Scenes while the game is active by calling NetworkManager.ServerChangeScene(). This makes all the currently connected clients change Scene too, and updates networkSceneName so that new clients also load the new Scene." -Source: https://docs.unity3d.com/Manual/UNetManager.html

Yes. You might also want to try Mirror 2017 version, because 2018 doesn't have that 'pause receiving while switching scenes' feature yet.

I did try it in 2017 and it does the same thing.
It seems designed to destroy everything from the old scene. So the way I was trying to use it would mean I need Don't destroy on everything. Since that could have unforseen consequences. I will just manually manage the scenes.
It would be nice to have a similar method that doesn't destroy everything but still notifies all the clients.


Hi, I really found interested in this DICOM-viewer project, is it possible to save annotations from the embedded version of OHIF-Viewer?

I was able to load the OHIF Viewer locally and connected with orthanac, I am wondering if is it possible to use the viewer to label and then to save the changes in the dicom file? I am using the embedded version, by the way and thank you so much for your time!

I am wondering if is it possible to use the viewer to label and then to save the changes in the dicom file

Possible? Yes. Our current implementation only supports saving very specific information, and in a way that's not as interoperable as I'd like. We're working to offer a cleaner extension/export point for persisting and restoring data like this; as well as updating our own code to more closely follow the recommendations around persisting with DICOM SR (structured reports).
With DICOM, there are a lot of ways to encode the information. Your requirements can drastically change the approach though, and you'll likely need to write a little bit of code either in a custom extension, or by submitting a PR to improve support.
If your application is a closed system, and you don't need to share the information in an interoperable way, I'd argue there's no harm in persisting/restoring by whatever method is most convenient for you.


Essential Security Requirements: MTD

This item does not feel well defined: "The SDN Controller shall provide a moving target defense mechanism (MTD) that protects the network from attacks by using dynamic network configuration."
I can imagine a number of features (VXLAN?) that would allow for this and would want to see this better defined as this is fleshed out.

NIST defines MTD as: "The concept of controlling change across multiple system dimensions in order to increase uncertainty and apparent complexity for attackers, reduce their window of opportunity, and increase the costs of their probing and attack efforts."
Suggest rewording this statement to reflect that it is the concept of MTD that is important, not any given implementation of it, which is likely not going to be durable over the long term. Suggest:

"The SDN Controller shall incorporate concepts of moving target defense mechanisms (MTD) which can help defend the network controller from attacks by using controlled change management."

I would be reluctant to give examples here becasue there is the risk that they will become the de facto standard and this is not the intent.

Thank you for rephrasing and for your deep thought about it, which helped us to think differently. Appreciate it. Implementing the MTD can be a very beneficial strategy for enhanced security but on the other hand, implementing could be very complex. I have included a few other ways to express your thoughts. Would like to hear from others what they think about it.
"The SDN Controller should integrate moving target defense (MTD) strategies, assisting in protecting the network  against attacks by applying managed change processes."
"The SDN Controller can be designed to employ moving target defense (MTD) techniques, which could be instrumental in shielding the network from potential attacks via systematic and controlled alterations in its configuration and operational environment"
"The SDN Controller may implement the principles of moving target defense (MTD) to enhance its security. By employing a strategy of controlled and deliberate changes, it aims to safeguard the network controller from adversarial actions"
"The SDN Controller can adopt moving target defense (MTD) methodologies. This approach will aid in fortifying the network controller against attacks through deliberate and regulated modification techniques"
"The SDN Controller can embrace moving target defense (MTD) tactics, effectively securing the network controller from cyber threats through the strategic implementation of change management protocols"

The programmability aspects of SDN are the mechanism by which a moving target defense would be implemented. However, I don't believe that the SDN controller itself is the correct component to be making decisions of this nature. Other security components which interface with the SDN controller via the northbound API are the appropriate place, and that'd be outside the scope of the PP.
My major issues with this requirement are:

I don't see that any enterprise environment with any sort of change management board or related processes/procedures is going to sign off on wide-spread reworking of the network during business hours, in an automated fashion. Many mature environments are going to be unhappy about changing basic firewall policies outside of well-defined change windows if they might potentially impact on-going operations. Not all, but those environments are out there
Because of that, I don't see that this is going to be a great want in the commercial space. Because the purpose of CC is to certify commercial solutions for deployment in government networks, not to create government-specific solutions, if there isn't an commercial benefit to creating a feature, there's going to be pushback from product and dev teams.
that can be mitigated by making it an optional or objective requirement, but even then it needs to be narrowly tailored in scope and made clearly testable. frankly, just being able to direct via an API call the SDN controller to put a specific port into a specific quarantine VLAN or something should be sufficient demonstration.

In summary, if we can make this extremely narrowly tailored and focus on the ability to support that policy, rather than having it be broadly worded in such a way that the SDN controller itself is fully responsible for this functionality, then it may be appropriate to leave it in, if and only if it's not a mandatory requirement. Otherwise, I'd want to remove this language. Failure to do so, in my opinion, will see a number of vendors forego this PP entirely if their product can be described in terms of an appliance that can be put through NDcPP, which would mean they miss out on the additional scrutiny of SDN-specific features like API security. That'd be counterproductive to the creation of an SDN-specific PP/module.

Comments from TC Meeting on Feb 8, 2024:
Make the MTD an optional requirement
o How will we keep pace with the evaluation activities
o If this is deployed in an operational environment, this would be more disruptive than remedial
o Not a necessary requirement bc the controller wouldn't be making the decision, just carrying out the action which is already a basic function

Thank you Dean for your detailed explanation.
I agree with Dean. I also propose to remove MTD from ESR, for now.


feat(wallet): Ledger Key Agent

Context
SDK needs to be able to support the hardware devices / wallets. LedgerKeyAgent will be responsible to do that.
Proposed Solution
Implement a KeyAgent to support the Ledger hardware devices
Important Changes Introduced

InMemoryLedgerKeyAgent added for handling device connection (transport).
ledger-live-common lib used to handle communication and exec commands on Ledger devices (Some Cardano methods are not implemented e.g getAddress so we will move-to / use ledgerjs-hw-app-cardano)
Web based communication with devices over @ledgerhq/hw-transport-webhid
Node based communication with devices over @ledgerhq/hw-transport-node-hid

TODO:

[X] Fix lib loading issues
[X] Consider using different library instead of ledger-live-common
[X] Refactor from ledger-live-common to ledgerjs-hw-app-cardano
[X] Web based communication with devices over @ledgerhq/hw-transport-webhid
[x] Add methods to check / recover Transport and DeviceConnection in general
[x] Allow end apps to use and manipulate with its own Transport
[ ] Add Bluetooth based communication with devices (it is not in the scope of basic implementation)
[x] Node based communication with devices over @ledgerhq/hw-transport-node-hid
[x] Add tests - NodeHid based only

@rhyslbw @mkazlauskas Thanks guys for the review.
Code is improved and NodeHid support + tests added!

@rhyslbw actually yarn lint:fix changed that.


ADMIN PR: Bump Ondatra version to 0.1.5

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 57.219%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1181

Relevant Lines:
2064

💛  - Coveralls

/gcbrun


volume path contain ~ or / is expanded to local windows path in git-bash

Description
volume path contain ~ or / is expanded to local windows path in git-bash, such as: ~/data will be converted to C:/Users/huangjoh/data, /data will be converted to C:/Dropbox/opt/Git/data
Steps to reproduce the issue:
I have Docker for Windows installed on my WIN 10 machine and I have git-for-windows installed under C:\Dropbox\opt\Git
Then I am using the git-bash.exe as the shell for Docker, following the commands below:
huangjoh@SHAH024F22 MINGW64 /
$ echo ~
/c/Users/huangjoh

huangjoh@SHAH024F22 MINGW64 /
$ docker run --name vol-test -v ~/data centos:7

huangjoh@SHAH024F22 MINGW64 /
$ docker inspect -f "{{json .Mounts}}" vol-test
[{"Type":"volume","Name":"bae1c3a56c2afe11778d9bcb1bb06b2c41757aa2c6bcdf67abe7fbdcb8946a6f","Source":"/var/lib/docker/volumes/bae1c3a56c2afe11778d9bcb1bb06b2c41757aa2c6bcdf67abe7fbdcb8946a6f/_data","Destination":"C:/Users/huangjoh/data","Driver":"local","Mode":"","RW":true,"Propagation":""}]

Describe the results you received:
volume path ~/data is converted to C:/Users/huangjoh/data ( if I set volume path to /data, it will also converted to C:/Dropbox/opt/Git/data)
Describe the results you expected:
expect ~/data as the volume path
Additional information you deem important (e.g. issue happens only occasionally):
Output of docker version:
$ docker version
Client:
 Version:      1.13.1
 API version:  1.26
 Go version:   go1.7.5
 Git commit:   092cba3
 Built:        Wed Feb  8 08:47:51 2017
 OS/Arch:      windows/amd64

Server:
 Version:      1.13.1
 API version:  1.26 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   092cba3
 Built:        Wed Feb  8 08:47:51 2017
 OS/Arch:      linux/amd64
 Experimental: true

Output of docker info:
$ docker info
Containers: 4
 Running: 0
 Paused: 0
 Stopped: 4
Images: 5
Server Version: 1.13.1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 13
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host ipvlan macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: aa8187dbd3b7ad67d8e5e3a15115d3eef43a7ed1
runc version: 9df8b306d01f59d3a8029be411de015b7304dd8f
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.9.8-moby
Operating System: Alpine Linux v3.5
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.769 GiB
Name: moby
ID: 7RV6:Z557:G6MX:XDR2:4G32:FVGA:VC6W:LBRN:L33A:2EVZ:5GQM:IZPH
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 13
 Goroutines: 22
 System Time: 2017-02-26T14:08:39.5027629Z
 EventsListeners: 0
Registry: https://index.docker.io/v1/
Experimental: true
Insecure Registries:
 <IP_ADDRESS>/8
Live Restore Enabled: false

I don't think it's Docker doing the expansion, it's MinGW/git-bash. This is clear from your example too:
$ echo ~
/c/Users/huangjoh

Can you detail what you're trying to achieve?

@friism : thanks, I was trying to setup a dedicated data volume containers with volume path under "/data" or "~/data" (without expanding).
unfortunately, it took me long time to know that, the volume path has been converted to "C:/Users/huangjoh/data" in the new container ( I am new to docker).
I am not able to achieve that in the git-bash (using powershell works fine), do you know how to fix this issue in the git-bash?

@ztou http://stackoverflow.com/a/34386471/2942

That's a known issue ("feature") of mingw. mingw is trying to be smart. See https://github.com/docker/docker/issues/13741#issuecomment-128893740, and http://www.mingw.org/wiki/Posix_path_conversion
you can also try using a double-slash for paths;  -v //foo/bar/
Note that the mount-path inside the container must be an absolute path, so using ~/ or ./ is not a valid format. You need to specify an absolute path inside the container (e.g. /home/foo/something).
I'll go ahead and close this issue, because this is not a bug in docker, but feel free to continue the conversation


CODEOWNERS: Acquire pom.xml

I'm proposing to add myself as CODEOWNER for pom.xml given ongoing work around build/dependencies.
Any objections? cc: @mandy-chessell

Added PR with this change

I approve


onnx-mlir compilation error: ‘transform’ is not a member of ‘std’

How do you build without running into the following error in shape_inference.h?
cmake --build . --target check-onnx-lit

[42/420] Building CXX object third_party/onnx/CMakeFiles/onnx.dir/onnx/defs/math/old.cc.o
FAILED: third_party/onnx/CMakeFiles/onnx.dir/onnx/defs/math/old.cc.o
In file included from onnx-mlir/third_party/onnx/onnx/defs/schema.h:25,
                 from onnx-mlir/third_party/onnx/onnx/defs/function.h:16,
                 from onnx-mlir/third_party/onnx/onnx/defs/math/old.cc:6:
onnx-mlir/third_party/onnx/onnx/defs/shape_inference.h: In function ‘void onnx::adjustNegativeAxes(Axes&, int)’:
onnx-mlir/third_party/onnx/onnx/defs/shape_inference.h:828:8: error: ‘transform’ is not a member of ‘std’
  828 |   std::transform(
      |        ^~~~~~~~~

It seems #include <algorithm> is missing in the header file.

I have not seen it, which machine are you using? I would recommend adding the header if that fixes your issue

Interesting... the problematic file is under third-party
onnx/defs/shape_inference.h. Let me check the author on that one. Thanks.
On Tue, Jun 20, 2023 at 7:40 AM Alexandre Eichenberger <
@.***> wrote:

I have not seen it, which machine are you using? I would recommend adding
the header if that fixes your issue
—
Reply to this email directly, view it on GitHub
https://github.com/onnx/onnx-mlir/issues/2327#issuecomment-1598924966,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEN4UGBCB74HE73SQXS4GGTXMGY65ANCNFSM6AAAAAAZMHKDME
.
You are receiving this because you authored the thread.Message ID:
@.***>

I filed https://github.com/onnx/onnx/issues/5346 to track.


Cloudflare:index:Record missing required argument

What happened?
I set up to use apiToken instead of the legacy way from api_key, email variant and I get the following error when trying to update the index record(s).
cloudflare:index:Record (ingress-stable-protected-iap-CNAME-chat.nakhoda.ai):
    error: Preview failed: could not validate provider configuration: 5 errors occurred:
        * Missing required argument: "email": all of `api_key,email` must be specified
        * Invalid combination of arguments: "api_user_service_key": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid combination of arguments: "api_key": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid combination of arguments: "api_token": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid or unknown key

  cloudflare:index:Record (ingress-stable-protected-iap-A-record):
    error: Preview failed: could not validate provider configuration: 5 errors occurred:
        * Missing required argument: "email": all of `api_key,email` must be specified
        * Invalid combination of arguments: "api_user_service_key": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid combination of arguments: "api_key": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid combination of arguments: "api_token": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid or unknown key

  cloudflare:index:Record (ingress-stable-protected-iap-CNAME-*.qa.g.nakhoda.ai):
    error: Preview failed: could not validate provider configuration: 5 errors occurred:
        * Missing required argument: "email": all of `api_key,email` must be specified
        * Invalid combination of arguments: "api_user_service_key": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid combination of arguments: "api_key": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid combination of arguments: "api_token": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid or unknown key

  cloudflare:index:Record (ingress-stable-protected-iap-CNAME-*.ci.g.nakhoda.ai):
    error: Preview failed: could not validate provider configuration: 5 errors occurred:
        * Missing required argument: "email": all of `api_key,email` must be specified
        * Invalid combination of arguments: "api_user_service_key": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid combination of arguments: "api_key": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid combination of arguments: "api_token": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid or unknown key

  cloudflare:index:Record (ingress-churn-protected-iap-A-record):
    error: Preview failed: could not validate provider configuration: 5 errors occurred:
        * Missing required argument: "email": all of `api_key,email` must be specified
        * Invalid combination of arguments: "api_user_service_key": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid combination of arguments: "api_key": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid combination of arguments: "api_token": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid or unknown key

  cloudflare:index:Record (ingress-stable-public-CNAME-*.sandbox.g.nakhoda.ai):
    error: Preview failed: could not validate provider configuration: 5 errors occurred:
        * Missing required argument: "email": all of `api_key,email` must be specified
        * Invalid combination of arguments: "api_user_service_key": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid combination of arguments: "api_key": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid combination of arguments: "api_token": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid or unknown key

  cloudflare:index:Record (ingress-stable-protected-iap-CNAME-*.rc.g.nakhoda.ai):
    error: Preview failed: could not validate provider configuration: 5 errors occurred:
        * Missing required argument: "email": all of `api_key,email` must be specified
        * Invalid combination of arguments: "api_user_service_key": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid combination of arguments: "api_key": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid combination of arguments: "api_token": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid or unknown key

  cloudflare:index:Record (ingress-stable-public-CNAME-*.g.nakhoda.ai):
    error: Preview failed: could not validate provider configuration: 5 errors occurred:
        * Missing required argument: "email": all of `api_key,email` must be specified
        * Invalid combination of arguments: "api_user_service_key": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid combination of arguments: "api_key": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid combination of arguments: "api_token": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid or unknown key

  cloudflare:index:Record (ingress-churn-protected-iap-CNAME-*.dev.g.nakhoda.ai):
    error: Preview failed: could not validate provider configuration: 5 errors occurred:
        * Missing required argument: "email": all of `api_key,email` must be specified
        * Invalid combination of arguments: "api_user_service_key": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid combination of arguments: "api_key": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid combination of arguments: "api_token": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid or unknown key

  cloudflare:index:Record (ingress-stable-protected-iap-CNAME-*.stag.g.nakhoda.ai):
    error: Preview failed: could not validate provider configuration: 5 errors occurred:
        * Missing required argument: "email": all of `api_key,email` must be specified
        * Invalid combination of arguments: "api_user_service_key": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid combination of arguments: "api_key": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid combination of arguments: "api_token": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid or unknown key

  cloudflare:index:Record (ingress-stable-protected-iap-CNAME-*.prod.g.nakhoda.ai):
    error: Preview failed: could not validate provider configuration: 5 errors occurred:
        * Missing required argument: "email": all of `api_key,email` must be specified
        * Invalid combination of arguments: "api_user_service_key": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid combination of arguments: "api_key": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid combination of arguments: "api_token": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid or unknown key

  cloudflare:index:Record (ingress-churn-public-A-record):
    error: Preview failed: could not validate provider configuration: 5 errors occurred:
        * Missing required argument: "email": all of `api_key,email` must be specified
        * Invalid combination of arguments: "api_user_service_key": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid combination of arguments: "api_key": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid combination of arguments: "api_token": one of `api_key,api_token,api_user_service_key` must be specified
        * Invalid or unknown key

I have setup cfConfig with the correct values:
cloudflare: {
                apiKey: cfConfig.requireSecret("apiToken"),
                email: "EMAIL"
            }

For CertManager or TLS certificates it goes through with no problems but it seems for the ingress controller it complains that is missing which is not since apiToken should contain all the information as described by the docs so it is that not updated properly for these type of resources?

Thanks for getting in touch @stefaneacsu147
Would you be able to provide a complete example of the code (excluding any personal details) which reproduces the errors you're seeing above so we can see how you're configuring the provider and the resource?

This same error is happening to me with project that previously deployed successfully 10 days ago and is now failing on preview.  `Diagnostics:
pulumi:pulumi:Stack (kong-post-qa-gcloud-us-east4):
W1202 02:30:30.845242     498 gcp.go:119] WARNING: the gcp auth plugin is deprecated in v1.22+, unavailable in v1.26+; use gcloud instead.
To learn more, consult https://cloud.google.com/blog/products/containers-kubernetes/kubectl-auth-changes-in-gke
warning: provider config warning: Use resource specific `account_id` attributes instead.
warning: provider config warning: Use resource specific `account_id` attributes instead.
error: Error: invocation of cloudflare:index/getZones:getZones returned an error: could not validate provider configuration: 4 errors occurred:
	* Invalid combination of arguments: "api_token": one of `api_key,api_token,api_user_service_key` must be specified
	* Missing required argument: "email": all of `api_key,email` must be specified
	* Invalid combination of arguments: "api_user_service_key": one of `api_key,api_token,api_user_service_key` must be specified
	* Invalid combination of arguments: "api_key": one of `api_key,api_token,api_user_service_key` must be specified

    at Object.callback (/home/circleci/project/node_modules/@pulumi/runtime/invoke.ts:159:33)
    at Object.onReceiveStatus (/home/circleci/project/node_modules/@grpc/grpc-js/src/client.ts:338:26)
    at Object.onReceiveStatus (/home/circleci/project/node_modules/@grpc/grpc-js/src/client-interceptors.ts:426:34)
    at Object.onReceiveStatus (/home/circleci/project/node_modules/@grpc/grpc-js/src/client-interceptors.ts:389:48)
    at /home/circleci/project/node_modules/@grpc/grpc-js/src/call-stream.ts:276:24
    at processTicksAndRejections (internal/process/task_queues.js:79:11)`

I am setting the following environment variables in my project CLOUDFLARE_ACCOUNT_ID=<redacted> CLOUDFLARE_EMAIL=<redacted> CLOUDFLARE_API_KEY=<redacted>
I am using the following in my typescript project
"dependencies": {
"@pulumi/aiven": "^4.2.1",
"@pulumi/aws": "^4.25.0",
"@pulumi/cloudflare": "^4.0.0",
"@pulumi/gcp": "^5.25.0",
"@pulumi/pulumi": "^3.16.0",
"axios": "^0.19.2"
}
I do believe a recently release here has caused this issue.  I'm likely going to try downgrading tomorrow.

According to the diff based on the last version upgrade, there's only a minor env validation change I could see: https://github.com/cloudflare/terraform-provider-cloudflare/compare/v3.24.0...v3.29.0#diff-58d6a027753b50994deb7e11e4a99dde423f35844986019bd9cea5e0c94aba22L105

According to the diff based on the last version upgrade, there's only a minor env validation change I could see<EMAIL_ADDRESS>If you're able to narrow down which was the last working version we should be able to isolate the associated change causing the issue.

I was able to get a successful pulumi preview by pinning the cloudflare provider to 4.12.1. So something about 4.13.0 definitely caused me to receive this error this week.  I almost forgot I was taking compatible version in my project.
An employee on my team suggested we might have picked up a regression from the terraform provider.  https://github.com/cloudflare/terraform-provider-cloudflare/issues/1919
That said, I at least wanted to report back that 4.12.1 works for me on my current settings.

@stefaneacsu147 I think you're not supposed to specify email when using an api token, I had this error and managed to get around it by defining API token only.

I got this error:
Diagnostics:
  pulumi:pulumi:Stack (devops-dev):
    error: update failed

  cloudflare:index:Record (record):
    error: 1 error occurred:
    	* failed to create DNS record: Authentication error (10000)

Info:
import pulumi
import pulumi_aws as aws
import pulumi_cloudflare as cloudflare

def create_certificate():
    """
    Create Certificate for primary domain and wild subdomain
    """
    certificate = aws.acm.Certificate(
        resource_name="cert",
        domain_name="example.com",
        validation_method="DNS",
        subject_alternative_names=["*.example.com"]
    )
    return certificate

def create_cloudflare(certificate):
    """
        Create a Cloudflare Record
    """
    record = cloudflare.Record(
        "record",
        type="CNAME",
        name=certificate.domain_validation_options[0].resource_record_name,
        value=certificate.domain_validation_options[0].resource_record_value,
        zone_id='***'
    )
    return record

pulumi up
export<EMAIL_ADDRESS>export CLOUDFLARE_API_KEY="***"
except CLOUDFLARE_ACCOUNT_ID="***"

Any help?

@omidraha see comment above

Thank you @mattfysh for the suggestion. Since nobody said it doesn't work, I'll go ahead and close this issue. Please report back if I'm wrong here.


fix(CalloutData): hide it from Storybook

Related Ticket(s)
Suppress CalloutData from main Storybook #3010
Description
Since it's a feature flag, should not appear in Storybook if the env variable DDS_CALLOUT_DATA is not set or it's set to false
Changelog
New

Added condition to hide from Storybook based on DDS_CALLOUT_DATA variable

@asudoh Could you please merge this one?


Issue

Getting this every time i run masterstock.py

Are you using a proxy? if so proxy is banned. If not, try installing this: pip install requests[security]

No proxy, no VPN. It used to work fine for me, i tried 3 different wifi (IP) that can access supreme website even my phone hotspot still same thing, i already have requests[security] installed.

Try updating OpenSSL http://stackoverflow.com/questions/15185661/update-openssl-on-os-x-with-homebrew


Add analytics attributes to links on install page

@jseldess @jess-edwards

This change is

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/b2c47016c6f010a12b89bfe2952c3125cfa9c21d/


BUG: All navigation link redirect on about#

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
All Navigation link redirect on about page

Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSoC'24 contributor
[X] I want to work on this issue

Thank you for providing me oppurnity @hereisSwapnil

Hey, allow me to work on this under GSSOC' 2024


Manually Handle/Store Exceptions

Is it possible to store an exception that has been handled in a begin/rescue block?  For example:
begin
  do_something_that_raises_an_exception
rescue => e
  RailsExceptionHandler::Handler.new(Rails.env, e).handle_exception
end

I tried calling handle_exception above and received this exception:
LoadError (Unable to autoload constant ErrorResponseController, expected /var/lib/gems/2.3.0/gems/rails_exception_handler-2.3.4/app/controllers/error_response_controller.rb to define it):

There's a method for that, see: https://github.com/Sharagoz/rails_exception_handler/wiki/Manual-exception-handling-outside-of-rack

Outstanding!  Thanks!


Show full PR body, wrapping at 80 characters

This will allow us to see it, without messing up the layout in CI.
Long text for demo:
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.

1 Error

:no_entry_sign:
Please include a CHANGELOG entry.
You can find it at CHANGELOG.md.

2 Warnings

:warning:
Author @jeroenvisser101 is not a contributor

:warning:
Tests were not updated

  Generated by :no_entry_sign: danger

:tada:

It does break in the middle of the word, but better than nothing, right? :tada:

@orta I noticed we use 'key.to_s' everywhere, except for the pr_body, should I rename it now?

:rocket:


Enable Instrumentation by APM for Deeper Traces

Is your feature request related to a problem? Please describe.
I am trying to understand deeper level use cases, and to do that often use an APM Tool to track performance of pieces of the code. I lack the ability to see how long certain pieces of this library are taking because we have no instrumentation on it, and just adding default APM configs don't see to enable it.
Describe the solution you'd like
Would like to see functions called reported to an APM solution so that I can see how long certain pieces of code are taking, and also track a request down to the functions being called.
Describe alternatives you've considered
The solution would be vendor agnostic ideally.
Additional context
NA

Thanks for the feature request, @mkkeffeler! I'm going to transfer this to the SDK parent project for consideration.


Exclude specific files/directory or even a custom .ignore like file/config?

Hello,
This isn't realy a bug but more a feature request.
I would really appriciate it if you could look into a file/directory
exclude option. Because right now I am using jQuery and what not. And they have a lot of TODO's I really am not intrested in seeing.

Yes, this is exactly what we need, can you add this feature, please?
Maybe somethings like negation ! operator?
So we can use .gitignore style:
path1/                           # ignore this directory and it's subdirectories
!path1/path2/important_stuff     # but include this one

Thank you!

Have you tried using an .imdoneignore file?

When I first installed it it didn't show me the readme, it was after I restarted my client I saw and read the readme. So yeah...
Using the .imdoneignore and the config file in .imdone folder you can do this.


PhiloGL does not appear to work on two canvases at the same time

Create a test example with two canvases and philogl using both of them.
The app object seems to be kept in state in across the code, modularize so that app is pulled out.

@wwwtyro I think you worked on this. Is there an example that shows this working? If so we can close.

Yes, but it was a silly example for testing it out. I'll make a better one right now. :)

https://github.com/philogb/philogl/pull/46


Upgrade to Android gradle plugin 4.x

Coverage remained the same at 33.799% when pulling 7a8e230e35f1d113d60b14ed2b817f853a441396 on kruton:android-gradle-4.0.1 into c6eb9e47b8bef35f78914a7632ce61a96b790351 on connectbot:main.


Preview binary test fails when filename contains lua string pattern special characters

NeoVim Version Info.
NVIM v0.7.0-dev+792-gc46f7caad

Build type: Release

LuaJIT 2.1.0-beta3

Problem
As title. I just tried the new option show_cwd_header=true mentioned in #281 . While I got an error as shown in the following pic:

And I'm pretty sure that this is because I recently wrote a very little plugin myself (followed your advice to learn lua). When I commented out my lines of the plugin, the error disappears.
I guess maybe adding one more condition like and vim.opt.filetype ~= "..." would solve it. But I don't know what to add.
Here is the code:
vim.cmd'au CursorHold * pwd'
vim.cmd'au BufEnter * call v:lua.change_cwd_to_grandparent()'
vim.api.nvim_set_keymap('n', '<Leader>prr', '<cmd>lua _G.reset_project_root(); print("Project Root Has Been Reset"); _G.change_cwd_to_grandparent()<CR>', NOREF_NOERR_TRUNC)
_G.__PROJECT_ROOT_CONST = {
  "GitHub",
  "GitHub%-2",
}
function _G.reset_project_root()
  for k in pairs(_G.__PROJECT_ROOT) do
    local found = false
    for kk in pairs(_G.__PROJECT_ROOT_CONST) do
      if k == kk then
        found = true
        break
      end
    end
    if not found then
      _G.__PROJECT_ROOT[k] = nil
    end
  end
end
vim.api.nvim_set_keymap('n', '<Leader>pra', '<cmd>lua table.insert(_G.__PROJECT_ROOT, vim.fn.input("Extend Project Root: ")); _G.change_cwd_to_grandparent()<CR>', NOREF_NOERR_TRUNC)
_G.__PROJECT_ROOT = {
  "GitHub",
  "GitHub%-2",
}
function _G.change_cwd_to_grandparent()
  if (
    -- Don't use `string.find` or you will match when `vim.bo.buftype` is `''` empty string!
    vim.bo.buftype ~= "terminal"
    and vim.opt.filetype ~= "dashboard"
    and vim.opt.filetype ~= "NvimTree"
  ) then
    local test_path = "%:p:h"
    local count = 0
    while (
      count+1 <= 2
      and string.len(vim.fn.expand(test_path .. ":h")) >= string.len(vim.fn.expand("$HOME"))
    ) do
      local found_root = false
      for idx = 1, #_G.__PROJECT_ROOT do
        local _, last = string.find(vim.fn.expand(test_path .. ":h"), _G.__PROJECT_ROOT[idx])
        if string.len(vim.fn.expand(test_path .. ":h")) == last then
            found_root = true
            break
        end
      end
      if found_root then break end
      test_path = test_path .. ":h"
      count = count + 1
    end
    vim.api.nvim_set_current_dir(vim.fn.expand(test_path))
  end
end

OK after some tests I just realized that it's the filename [1][98f3...].xml that causes the error. But I still don't know how to fix the bug.

I just tried the new option show_cwd_header=true

This bug is not related to the above option, the function that fails seems to be vim.fn.expand (utils.lua:148) which doesn't like the [] characters found in the filename (they are "special" in lua string patterns), I'll do some testing the fix might be as simple as lua-escaping the special characters [ -> %[ or ] -> %], already have a function for that:
https://github.com/ibhagwan/fzf-lua/blob/3eb5baa6e9beff2fdc51c6152707206a0ab80a26/lua/fzf-lua/utils.lua#L126-L133

I'm not sure if this is intended neovim behavior or not but it seems like a neovim bug, it has no issues with the hypeh symbol but when it's in between 2 digits it fails with Vim:E944: Reverse range in character class:
:lua print(vim.fn.expand("~/file[2-1].ext"))
-- Fails with:
E5108: Error executing lua Vim:E944: Reverse range in character class
stack traceback:
        [C]: in function 'expand'
        [string ":lua"]:1: in main chunk

But this works:
:lua print(vim.fn.expand("~/file[2\\-1].ext"))

In any event, the latest commit fixes this: https://github.com/ibhagwan/fzf-lua/commit/9a71718c1e359987f77d7e65331c076b3e622c2e


CLI tools for easier interface/peer creation

Hi, I've been following this project for a while out of interest (mainly since this is the only project like this which allows VPN's behind double-NAT's with dynamic IP's with no other servers needed) and I have a suggestion. Is it possible to create CLI tools to streamline the process? For example...
PEER A:
sudo hyrspace info
...peer-id: PEER-A-ID
sudo hyprspace create example.conf
...Generating random discovery key.
...Created peer <IP_ADDRESS> for peer-id PEER-A-ID.
...Enter the peer-id of another peer: [PEER-B-ID]
...Created peer <IP_ADDRESS> for peer-id PEER-B-ID.
...Enter the peer-id of another peer (Press enter to skip):
...Successfully created example.conf at ~/.hyprspace/example.conf
[Copy example.conf to other peer]
PEER B:
sudo hyprspace import ~/example.conf
...Reading peer list.
...Created peer <IP_ADDRESS> for peer-id PEER-A-ID.
...Created peer <IP_ADDRESS> for peer-id PEER-B-ID.
...Config successfully imported.
sudo hyprspace init hs0 [Both machines]
The stuff above just demonstrates functionality, you'd probably have a better idea for how a CLI would work, sorry in advance if this is a lot to ask.

@LynHyper no I think this is a great idea! It's definitely not too much! Since you can have multiple interfaces within Hyprspace we'd need some way of telling Hyprspace which interface to add the peer to. But I think some cli way of doing this would be a good addition for usability. What do you think about something like,
hyprspace peer add hs0 QmHictlsttxux.....

Or maybe it's worth it to mimic something like that rclone config interface to allow people to walk through a setup/modification of an interface.

Good point about per-interface stuff, hadn't though about that.
Maybe peers could be given a label so it's easier to tell which peer belongs to which device, it'd be nice to have the ability to establish a connection and then have CLI act on all connected peers; changing a label for a peer would be done for all peers connected to hs0 (don't know how complicated that would be).
I think borrowing from 'rclone config' would be a great direction!

Okay so let's properly start working on an implementation because I like some of these ideas. @LynHyper I'm thinking of breaking down the feature set you mentioned in the discussion post into a few additions.

A command line interface for creating/importing a peer.
A full cli configuration wizard? to allow you to setup and add peers on an init.
Functionality to save peers into groups and possibly sync between peers in an already connected group.

Let me know what you think/if I'm missing anything?

A configuration wizard would definitely be the way to go; I think there are too many CLI commands in my original discussion to be reasonable to fully implement so it makes sense why you want to go for an add-only method to simplify things.
I think you'll also need to have a way to create/import groups too; otherwise you'd need to modify the config manually to add groups and at that point you might as well add the peers to the config manually while you're there.
The original discussion sort of converts hyprspace into a public room system, where people can "login" as if it was a chat room (hence --allow-all), do you think this is inappropriate for how you want hyprspace to work?


Meilisearch silently crashes (presumably hitting memory limit) on Windows 11

Describe the bug
The Meilisearch Windows amd64 binary seems to constantly request more memory from the OS and crashes after 4 GB is allocated. No issues with the Linux binary with the exact same usage scenario; it runs without issues in a VM with 2 GB RAM and 1 GB swap, seemingly without paging.
When limiting to insertion of just 100 documents per run with delays of 5-10 minutes in-between, memory usage steadily grows with each new batch in the same way as when running insertions immediately one after another.
A typical document consists of a text string (usually below 100 characters), a language identifier, and a resource ID, altogether well below 500 bytes (so ≈50 kilobytes per chunk).
To Reproduce
Steps to reproduce the behavior:

Start the Meilisearch service
Attempt to insert several batches of 100 documents, waiting for each task's completion (I am using meilisearch-rust)
The API gives an error during wait_for_completion()
About 5-10 seconds later the Meilisearch server silently terminates. There are no messages related to the crash even with TRACE logging level — everything looks normal.

The code in question:
    for docs in store.chunks(100) {
        eprintln!("Inserting {} entries…", docs.len());
        let Ok(task) = dictionary.add_or_update(docs, Some("tid")).await else {
            eprintln!("Cannot queue documents.");
            return ExitCode::FAILURE;
        };

        let Ok(task) = task.wait_for_completion(&client, None, None).await else {
            eprintln!("Wait for completion failed.");
            return ExitCode::FAILURE;
        };

        if task.is_failure() {
            eprintln!("Insertion failed: {:?}.", task.unwrap_failure());
            return ExitCode::FAILURE;
        }
    }

runs without issues when using Meilisearch Linux binary.
Expected behavior
Insertion should finish and Meilisearch server process should not terminate silently.
Screenshots
N/A
Meilisearch version:
1.10.0 (this behaviour was present in 1.8.x as well)
Additional context
OS: Windows 11 Enterprise 23H2; the system has 32 GB RAM.

Hello @Yuubari,
By default, Meilisearch is allowed to allocate up to 2/3 of the available memory.
Before investigating deeper, could you try to reduce the max indexing memory using --max-indexing-memory or the MEILI_MAX_INDEXING_MEMORY environment variable, setting it to something like 2GB.
This should help in reducing the crashes, if you continue encountering this issue, let me know.

Thank you, that seems to have done the trick. I wonder why was it having issues with the default settings…


(PUP-6099) add additional autorequires for file/mount interactions

With this improvement, file resources will execute before their mount point is mounted and file resources will execute after their parent mount is mounted.
Continues #4824
After moving all the changes to the mount type, I am unsure how to get Puppet to traverse unknown child paths of a mount point, unless it is working from the file resources themselves and ascending to find mount points. I am sure the mimicked code I put in will not actually work correctly.
Changed up the spec test for everything being in mount, but still expecting the file resources to not be generated correctly.

CLA signed by all contributors.

I was ignoring the test issues because they are arising from high-level and not low-level problems. From a general design standpoint, like I mentioned above, I have no idea how a Mount resource is supposed to know what potential File resource child paths exist. The similar implementations of these autorequires involve ascending into known parents and not theoretical children, but I followed the suggestion of moving everything into the package resource, so now I am stuck from a high-level design/algorithm perspective.
If someone can point out how a Mount resource would be able to gather information about actual File resource child directories, then the implementation should go quickly afterwards. As it is, this is pretty much dead in the water.

It likely needs inverse behavior to File then; walk all File resources in the Catalog, and check if this mount is an ancestor of the File.

Would that not be very computationally inefficient?
It could be mitigated if, instead, I immediately filtered out all file resources with paths that did not match the mount resource name and then iterated over those remaining for ancestry checking. That also may be what you were suggesting anyway.
Do you know a code snippet to grab all the file resources in the catalog? I can go hunting myself if this is unfamiliar territory.

Hmm, it might be. You're switching from: for each file resource, traverse its ancestors and look for a matching mount resource with parents.find {|p| catalog.resource(:file, p.to_s)}; to: for each mount point, search for all file resources that are children of the mount point, which will end up iterating over all file resources for each mount point. So from O(<num files> * <average path depth>) (assuming constant-time lookup of a specific file resource) to O(<num mounts> * <num files>).
That's a hard trade-off to compare; number of mount points could vary wildly.
As far as implementation, the User type has an example of using catalog.resources.
/cc @joshcooper @branan for other ideas

Thanks for the snippet. I don't think I understand its use within user completely, because it seems to me you could just match the gid or the gid-->group without iterating. I can certainly make use of the catalog.resources.find though.
Regarding the efficiency tradeoff, I feel like in general there will be substantially fewer file resources than mount resources. That being said, I was comparing the efficiency of the sorting algorithms and not the file versus mount aspect. I will see what I can come up with to save time.

Put some morework into this. Starting to get ugly and complicated due to all of the constraints, but at least there seems to be some kind of path forward now.

There are certainly holes in testing; we continually try to fill them in and ensure new code doesn't introduce more holes. Some hope is definitely involved.

So does this look like it should work now? What should I do about the tests?

New push today. Looks like good news and bad news.
Good news seems to be that I figured out a way to do cross-resource autorequire/autobefore testing and that the autorequire is working. Bad news is that I did not do it perfectly as several other random tests seem to be failing. Also it seems that my autobefore code is not working based on the relevant test results.
Could this get passed around to other team members to suggest how to patch up the hole(s) in the way I created the file resource for testing within mount and to start creating tests for all the other cross resource autorequire tests in Puppet since they are not being tested?

New push today. With the new error being reported back from Travis and what is in the end of puppet/lib/puppet/face/catalog/select.rb, I am wondering if catalog.resources.each { |resource| resource.type } is a string and not a symbol.

Apologies for no new push in a while. I have been busy with other projects, including my own and those of others. I promise something new by end of day Thursday at the latest.

I definitely understand, thanks for being so responsive.

 I mean... yeah. This was a rough PR due to the new autobefore feature and the new cross-resource autodepedency spec test with my own insistence that I figure out how to do that to patch up the hole in Puppet testing.
Couple of notes:

Can you get the word out that it seems I figured out cross-resource autodependency testing so that it can get added to all the places in the spec tests where it is needed (i.e. user resource autorequire group resource that is a group it belongs to).

Why are ruby 1.9.3 and 2.0.0 part of the TravisCI if HEAD is ruby 2.1.x?

New push to resolve Josh's suggestions.

LGTM. Last call for review!
Btw @mschuchard re your questions:

Can you get the word out that it seems I figured out cross-resource autodependency testing so that it can get added to all the places in the spec tests where it is needed (i.e. user resource autorequire group resource that is a group it belongs to).

Do you mind filing a ticket sketching out what would be done here?

Why are ruby 1.9.3 and 2.0.0 part of the TravisCI if HEAD is ruby 2.1.x?

Although the puppet-agent packages include ruby 2.1, people also run puppet as a gem with a range of ruby versions.
We treat dropping a ruby version as a breaking change, so we won't drop support for older ruby versions until puppet 5. (Which, I know, seems a bit nuts since 1.9.3 is EOL, but we do have a variety of stakeholders with different operating environments.)

Thanks for the clarifications.
I will fill out a ticket sketching out the additional unit test gaps that could be satisfied now.
I did not consider people running Puppet as a gem within a different ruby ABI instead of the one packaged with Puppet in its distribution packages, so that definitely makes sense. We just use the ruby packaged with since we are PE customers.

Thanks for all the hard work on this one @mschuchard! This should be released in puppet 4.5.0.


Determinism in hash tables

Hello. I really like absl hash tables but non-determinism in the iteration order is not desirable for my purpose: simulations. Would you accept a patch that disables non-determinism with a compiler flag? I can imagine, it will also be useful for debugging a program.

This isn't something we'd accept.
Part of Abseil's philosophy is engineering at scale. In addition to making it harder to execute a hash flooding attack, another reason we randomize iteration order is that is makes it easier for use to change the underlying implementation if we need to. When we wanted to change our hash function (for example), we found thousands of unit tests that depended on iteration order. We could not just break these tests and say "sorry, you are violating Hyrum's Law" since we would have thousands of angry Google developers. So instead, we fixed the tests and implemented randomization so that next time we wanted to change something in the implementation, this would not be an issue. The need for iteration order determinism is relatively rare compared to the potential wins we get by being free to change the implementation (maybe to make the hash table faster, which could save millions of cycles at scale, for example). By giving users a knob to disable the randomness, we'd be in the same situation all over again.

Makes sense, thank you. I have another proposal then.
We could make a boolean constant in a separate file that when flipped would disable non-determinism. So, when a user needs to debug their program, they would still need to change the absl code but only one line.

I think that is a better suggestion, but there are costs to keeping superfluous code around, so we generally don't do it.

I understand.


Removing the mask from Input results in TypeError: Cannot read property 'dependencyLib' of undefined

After removing the mask on a input field programmatically and submitting the form results in the TypeError: Cannot read property 'dependencyLib' of undefined
I was able to reproduce the error in codesandbox [React] - https://codesandbox.io/s/inputmask-undefined-error-yqug4
In order to get the error you need to

Click on button 'Enable the Mask'
Then Click on button 'Remove the Mask'
Enter any value (you can even leave it blank)
Click on Submit.

You will be getting this error - Uncaught TypeError: Cannot read property 'dependencyLib' of undefined
Upon investigation, I found that without enabling the Mask, the Input element don't have the property inputmask. However after enabling the mask we have new property for the input with key inpuptmask
After clicking on Remove mask this property is set to undefined. inputmask: undefined
Which is getting evaluated on the code as undefined when we are submitting the form.
The below piece of code is producing error and its from node_modules/inputmask/dist/inputmask.js
   var EventRuler = {
            on: function on(input, eventName, eventHandler) {
                 var $ = input.inputmask.dependencyLib, ev = function ev(e) {
                    e.originalEvent && (e = e.originalEvent || e, arguments[0] = e);
                    var that = this, args, inputmask = that.inputmask, opts = inputmask ? inputmask.opts : void 0,
   {/*error line*/}  $ = inputmask.dependencyLib;
                 <...>
             }
 } }

I am not sure but undefined check on the inputmask could resolve this issue hopefully.

Below is the screenshot of error in dev tools.

Please let me know if you need any additional details.

Copy of https://github.com/RobinHerbots/Inputmask/issues/2369#issuecomment-701445070
OS: Mac & Windows
Browser : Chrome
Inputmask version : 5.0.5

Hi @payapula ,
The issue is fixed in verion 5.0.6-beta.19.
There was a problem with unbinding the submit event.  I also added an extra check in the dependencyLib.
Best regards,
Robin


octodns-compare: Prefix filtering and status code on on mismatch

Adding a non-zero error code when changes exist.  Also adding an --ignore-prefix option to filter out records from this comparison which are expected to mismatch.

Hi @ross , can we get this merged?


support reinstalling the project with --reinstall-package

i would like to be able make uv sync always reinstall the current project, because part of my build process involves generating some files that uv is unaware of. this means uv sync doesn't always fully install my project
unfortunately the --reinstall-package argument doesn't seem to allow this:
> uv sync --reinstall-package .
error: invalid value '.' for '--reinstall-package <REINSTALL_PACKAGE>': Not a valid package or extra name: ".". Names must start and end with a letter or digit and may only contain -, _, ., and alphanumeric characters

Since you're going to reinstall the entire project, doesn't the behavior of --reinstall not meet your expectations?

Can you provide a reproducible pyproject.toml? Since the project needs to be reinstalled, it seems that pyproject.toml should have a [build-system] section.
e.g.
[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

If there's a [build-system] section, then <REINSTALL_PACKAGE> is the name of the project.
e.g.
pyproject.toml
[project]
name = "bar"
...

uv sync --reinstall-package bar

I guess this should meet your needs. You can give it a try


keystone_api_local_check failes when v3 enabled

.//keystone_api_local_check.py   <IP_ADDRESS>
status error 7/dist-packages/keystoneclient/session.py", line 397, in request\n    raise exceptions.from_response(resp, method, url)\nUnauthorized: The request you have made requires authentication. (HTTP 401) (Request-ID: req-817c5f06-8d05-42ce-ac0e-82d1b05cb3e8)\n
Traceback (most recent call last):
File "./keystone_api_local_check.py", line 77, in
main(args)
File "./keystone_api_local_check.py", line 67, in main
check(args)
File "./keystone_api_local_check.py", line 51, in check
user_count = len(keystone.users.list())
File "/usr/local/lib/python2.7/dist-packages/keystoneclient/utils.py", line 318, in inner
return func(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/keystoneclient/v3/users.py", line 108, in list
**kwargs)
File "/usr/local/lib/python2.7/dist-packages/keystoneclient/base.py", line 73, in func
return f(*args, **new_kwargs)
File "/usr/local/lib/python2.7/dist-packages/keystoneclient/base.py", line 361, in list
self.collection_key)
File "/usr/local/lib/python2.7/dist-packages/keystoneclient/base.py", line 113, in _list
resp, body = self.client.get(url, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/keystoneclient/adapter.py", line 170, in get
return self.request(url, 'GET', **kwargs)
File "/usr/local/lib/python2.7/dist-packages/keystoneclient/adapter.py", line 206, in request
resp = super(LegacyJsonAdapter, self).request(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/keystoneclient/adapter.py", line 95, in request
return self.session.request(url, method, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/keystoneclient/utils.py", line 318, in inner
return func(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/keystoneclient/session.py", line 397, in request
raise exceptions.from_response(resp, method, url)
keystoneclient.openstack.common.apiclient.exceptions.Unauthorized: The request you have made requires authentication. (HTTP 401) (Request-ID: req-817c5f06-8d05-42ce-ac0e-82d1b05cb3e8)
This issue is present at RPC r11.0.0

Thanks @BjoernT

Tested this with LDAP and non LDAP setups.

Does this need to be backported?

No just kilo which we should cherry pick from here. Alternatively I can submit it for kilo

q

@BjoernT cherry-pick is fine

@BjoernT If you're caught up doing other things we can do the cherry pick.

Per Dave, we should be ok to cherry pick.

Cherry-pick is merged. Closing this issue.


A bit lost among the branches and releases!

Hi!
I was wondering if we could clarify which branches are meant to do what, and also which pymodaq releases are supposed to be the most stable or the developer versions.
Right now there is the 4.0.x releases, the 4.1.0b0 release and the pymodaq-dev version.
On our experiment we thought that we would stick to some stable version (4.0.x) and keep using it and debugging it in order to make sure it is bug free, but at the same time I see that some bugs are getting corrected on the pymodaq-dev branch.
For instance I was about to send a PR to fix some issues with the parent.title in DAQ_Move but then I saw that it had already been fixed in this commit https://github.com/PyMoDAQ/PyMoDAQ/commit/d5275af66f8e80fe6d5842b1557d36b00d4ba351 on the pymodaq-dev branch in pretty much the same way :-(
In this example, probably the bugfix should have been applied on the 4.0.x branch and made into a 4.0.12 release since it does break some functionalities (although admitedly not very common ones). But I image it would be quite the hassle to push commits on several branches and test stuff everytime someone finds a bug...
What do people think? Should we even try to keep some stable release (kind of bug free guaranteed) or forget it and develop only the pymodaq-dev branch, pulling changes into the main branch every couple of months?

You're right this should be highlighted in the developer documentation. It was not that well done so far and I propose this:
the branch 4.0.x is devoted to be the stable branch (copy of the main at the moment) while the pymodaq_dev is being used to prepare the future 4.1.x
If there is a bug, we patch it on the pymodaq_dev branch and if possible we cherry pick it on the 4.0.x branch. If not possible we do a PR specific for the 4.0.x branch and we publish a new patch version (4.0.11...) This 4.0.x branch will be maintained as long as the 4.1.0 version is not out. Then we will do the same between the 4.1.x branch and the pymodaq_dev that will prepare the 4.2.x and so on and so on.
The real question is when do we propose the 4.1.0? At the moment there is the 4.1.0b0 but I want to include in it all the functionalities developed recently so I will soon propose a 4.1.0b1 version.
Is that clear? Could you translate that into a nice figure for the documentation?

Sounds good. I can make a figure for that.
But perhaps we should take the chance to standardize naming schemes for branches? I like what's proposed here: https://dev.to/couchcamote/git-branching-name-convention-cch
We don't need all of what they suggest, but picking from this link we could decide on :
Code Flow Branches
These branches which we expect to be permanently available on the repository follow the flow of code changes starting from development until the production.

Development (dev)
All new features and bug fixes should be brought to the development branch. Resolving developer codes conflicts should be done as early as here.

Master (master)
The production branch, if the repository is published, this is the default branch being presented.

Temporary Branches
As the name implies, these are disposable branches that can be created and deleted by need of the developer or deployer.

Feature
Any code changes for a new module or use case should be done on a feature branch. This branch is created based on the current development branch. When all changes are Done, a Pull Request/Merge Request is needed to put all of these to the development branch.

feature/integrate-swagger
feature/JIRA-1234
feature/JIRA-1234_support-dark-theme

Bug Fix
If the code changes made from the feature branch were rejected after a release, sprint or demo, any necessary fixes after that should be done on the bugfix branch.

bugfix/more-gray-shades
bugfix/JIRA-1444_gray-on-blur-fix

Hot Fix
If there is a need to fix a blocker, do a temporary patch, apply a critical framework or configuration change that should be handled immediately, it should be created as a Hotfix. It does not follow the scheduled integration of code and could be merged directly to the production branch, then on the development branch later.

hotfix/disable-endpoint-zero-day-exploit
hotfix/increase-scaling-threshold

Experimental
Any new feature or idea that is not part of a release or a sprint. A branch for playing around.

experimental/dark-theme-support

Merging
A temporary branch for resolving merge conflicts, usually between the latest development and a feature or Hotfix branch. This can also be used if two branches of a feature being worked on by multiple developers need to be merged, verified and finalized.

merge/dev_lombok-refactoring
merge/combined-device-support

Hello!
I think that we should NOT give up on keeping the objective to propose some stable releases.
By looking at different open-source projects such as Symfony or django, it looks like they open a branch for every minor version: 4.0, 4.1,... It seems like Symfony does not even have a main branch.
I would propose something like this:
If we take the current status of Pymodaq as an example, the stable branch (the one that is released on PyPI and that is installed when we do a pip install) should be the 4.0. If there is a bug fix the PR should go to the 4.0 and be released on PyPI quickly.
In the case of a new feature, it should go to the 4.1.
At some point, it should be decided that the amount of new features is enough for the 4.1. Then a 4.2 branch would be opened to welcome the new features, and the 4.1 goes to beta test (not already a release on PyPI but receives only bug fixes from the testers). After a given period of time, we would consider that 4.1 is stable, end the beta test period, and release 4.1 as the new stable version, and so on and so on.

OK, seems like you agree with @seb5g 's answer then!
Regarding beta versions: Is there really a need for those beta 4.x.xbx releases? I feel like anyone wanting them is knowledgeable enough to install from the git branch directly, without needing a pypi release.
And regarding current status: the current pymodaq-dev actually seems to be in good shape. I vote that we merge it into the main branch (probably some conflicts to resolve) and release 4.1.0. Then we clean up the branches and keep going from there

Alright I mostly agree with what you said, except I'd like to keep a main, as it is clearer for a newcomer (it will only be a mirror of 4.0.x at the moment but still)

as for the 4.1.x , I'm preparing a relatively big modification on the data viewers side that I'd like to include in the 4.1.x but if you all push for it I can keep it for the 4.2.x Let me know

Alright I mostly agree with what you said, except I'd like to keep a main, as it is clearer for a newcomer (it will only be a mirror of 4.0.x at the moment but still)

Yes this is fine to me.
Just a precision. I did not explicit the thing but I think it is important that the 4.1 should be rebased (synchronized) on the 4.0 each time there is a fix on the 4.0. Otherwise, if someone fix a bug on the 4.0, then it will come back in the 4.1.

as for the 4.1.x , I'm preparing a relatively big modification on the data viewers side that I'd like to include in the 4.1.x but if you all push for it I can keep it for the 4.2.x Let me know

My opinion is not so relevant here since I did not follow precisely the new features of the 4.1. But knowing that you have a tendency to go quite fast ;) I would rather vote for putting other big changes in the 4.2. In general, if there is too much changes between releases, there is a risk that you loose the other maintainers or users. But I understand it can be frustrating for you too :P

For now, I am mostly working with the pymodaq_dev which seems fairly stable so I feel it is better to just push it to main either after or before the data viewer update and then move on from it.
By the way, I like the conventioning name introduced by @rgeneaux, it makes the branch/commit much more readable overall

To summarize everything:
We'll have a stable branch called: main
Then we'll have a current minor branch (at the moment 4.0.x) where we apply bugfixes/hotfixes (using temporary branches following the post cites by @rgeneaux ). We could name it 4.0.x_stable for better readability
We'll have the next minor branch considered for development: 4.1.x, we could name it 4.1.x_dev for better readability
Once we think the 4.1.x has enough new feature or enough time passed, we'll create the 4.2.x_dev from it and rename it 4.1.x_stable, we can then forget about the 4.0.x_stable one.
For all temporary branch, bugfix, features, ... follow @rgeneaux citation
@rgeneaux , could you summarize this into a markdown + figure in the developer documentation. By the way, the documentation should always be pushed onto the curretn dev branch (at the moment the pymodaq_dev and later the 4.1.x_dev or 4.2.x_dev).
@Ashwolaa , before applying this and merging the current dev branch into 4.1.x and create the first release, there is still work to be done on your two PR. Could you work on it?

Here is an other interesting article about Git branching.

Nice article, the current relationship between features and develop is the one that we currently use, it almost looks like good practice!
@seb5g By the way, we have both a main and master branch. Should we just delete the master as it seems redundant with the main?

yes master is just an old dinosaure...

I tried to summarize the above mentioned ideas in this graph:

does this look right to everyone?
Also, where in the doc should we put this? section 5.4 (tutorial/how to contribute) or 4.2 (developer's guide/contributing)?
cheers

I tried to summarize the above mentioned ideas in this graph:

does this look right to everyone?
Also, where in the doc should we put this? section 5.4 (tutorial/how to contribute) or 4.2 (developer's guide/contributing)?
cheers

This graph is wonderful! Thanks :)
I agree
I have a few questions though :P
* on the fix branches side: if i understand correctly, a branch name that start with "hotfix" is dedicated to the stable branch, and "bugfix" to the development branch? Maybe those names should appear just above the corresponding vertical grey line to be even clearer.

for me a hotfix would trigger the immediate release of a patched version... while a standard bugfix could wait a bit

* on the feature branches side: every of those branches should start from the development one, what about this isolated pink point on the right?

same question

* last but not least: I think this graph suggests that when a hotfix is merged in the stable branch, it should also be merged into the development one. I think the right procedure here would rather be to merge the hotfix in the stable branch (then go from 4.1.0 to 4.1.1), and then _rebase_ the development branch on the new version of the stable one. This can be done with the _Sync_ button on the GitHub page of the repository. So each time a hotfix is done, the develop branch should be rebased on the stable one. This way we are sure that a bug that has been fixed in the previous versions will stay fixed in the next ones. However, I have no idea how to represent that nicely on this graph! But I would remove the arrow from the blue to the yellow point.

I kind of agree but what if dev is no more directly able to be rebased on the stable?
There is a feature called cherrypick that allows to select a particular commit to be added to another branch. So if rebasing is complex, cherrypicking may be used!

For the second question, I would rather put it in the tutorial. It would be quite harsh on the contributing one, which does not introduce a lot. Some modifications of the text of the tutorial should be updated also.

I agree, maybe by adding some link from the developer guide

I kind of agree but what if dev is no more directly able to be rebased on the stable?

If this happen it is an issue, and we should prevent this situation. The 4.2.x should be an extension from the 4.1.x, and not diverge from it. That is why at each hotfix, the potential conflicts should be solved straight away. I think this is the safest way to include all the hotfixes in the following versions.

I added this to the doc (see PR mentioned right above this comment)
@seb5g A small thing I noticed: on the _dev branches, we need to make sure that VERSION is set correctly. this avoids pip being annoying (having to do --force-upgrade etc), and more importantly we can set plugin dependencies more accurately (if some are only compatible with the dev version, for instance)

yes you're right. It's done for 4.2.x_dev


The API server is down

I can't access the API or its companion website. Gutendex.com is not responding.

Thank you for letting me know. It is back up now. It might continue to go down periodically if there is a lot of traffic, though.