Amazon Linux 2 GPU-optimized AMI - nvidia-persistenced.service fails to start and logs error "NVRM: API mismatch", breaking the ECS-agent

Summary
The "amazon-linux-2/kernel-5.10/gpu" image encounters errors in the NVidia driver on startup, causing the ECS agent to fail.
[  145.441350] cloud-init[3620]: Jun 11 08:11:03 ip-10-0-19-159.ec2.internal systemd[1]: Unit nvidia-persistenced.service entered failed state.
[  145.441505] cloud-init[3620]: Jun 11 08:11:03 ip-10-0-19-159.ec2.internal systemd[1]: nvidia-persistenced.service failed.
[  145.441660] cloud-init[3620]: Jun 11 08:11:03 ip-10-0-19-159.ec2.internal kernel: NVRM: API mismatch: the client has the version 535.183.01, but
[  145.441820] cloud-init[3620]: NVRM: this kernel module has the version 535.161.07.  Please
[  145.441978] cloud-init[3620]: NVRM: make sure that this kernel module and all NVIDIA driver
[  145.442130] cloud-init[3620]: NVRM: components have the same version.

Description
I'm running ECS on EC2 with g4dn instances. I use amazon-linux-2/kernel-5.10/gpu/recommended which is deployed using cdk.
At the of writing, this resolved to kernel 5.10.217-205.860.amzn2.x86_64 (see docker stats below for more details)
    const amiId = ssm.StringParameter.valueForStringParameter(this,
      '/aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/gpu/recommended/image_id');
    const machineImage = ec2.MachineImage.genericLinux({
      'us-east-1': amiId,
    });

    // ECS service with EC2 capacity provider and AutoScalingGroup

On 11 June 2024. ~7am UTC I deployed a new version of my app. This deploy terminated existing instances and replaced them with new ones (intended). However, the new EC2 instances are show nvidia errors in the System log that didn't appear before, causing the ECS agent to fail. Meaning the agent does not register itself with ECS, and does not launch containers.
It's clear from the logs that the error is related to the NVidia drivers. The last working deploy was at 1 day earlier, 10 June 2024 ~8am UTC.
I also run a userdata script on instance startup, though the error seems to occur before this script runs. And I'm not modifying the NVidia drivers, at least not intentionally. The lines above "install aws-cli" were added automatically by cdk.
#!/bin/bash
echo ECS_CLUSTER=<redacted> >> /etc/ecs/ecs.config
sudo iptables --insert FORWARD 1 --in-interface docker+ --destination <IP_ADDRESS>/32 --jump DROP
sudo service iptables save
echo ECS_AWSVPC_BLOCK_IMDS=true >> /etc/ecs/ecs.config

# install aws-cli
yum update -y && yum install -y aws-cli

echo ECS_ENABLE_CONTAINER_METADATA=true >> /etc/ecs/ecs.config
echo ECS_RESERVED_MEMORY=256 >> /etc/ecs/ecs.config

# make nvidia runtime available to all containers by default
sed -i 's/^OPTIONS="/OPTIONS="--default-runtime nvidia /' /etc/sysconfig/docker

# print docker settings
echo "---docker settings:\n\n"
cat /etc/sysconfig/docker
echo "\n\n end of docker settings---"

# apply settings
systemctl restart docker
echo "docker OK"

Expected Behavior
The instance launches without driver errors.
Observed Behavior
The instance logs errors related to the NVidia driver, and the ECS-agent doesn't function normally.
Environment Details
Kernel module versions

$ cat /proc/driver/nvidia/version
NVRM version: NVIDIA UNIX x86_64 Kernel Module  535.161.07  Sat Feb 17 22:55:48 UTC 2024
GCC version:  gcc version 10.5.0 20230707 (Red Hat 10.5.0-1) (GCC)

$ cat /sys/module/nvidia/version
535.161.07

$ dkms status
nvidia, 535.183.01: added

docker info
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.0.0+unknown)

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 0
 Server Version: 20.10.25
 Storage Driver: overlay2
  Backing Filesystem: xfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux nvidia runc
 Default Runtime: nvidia
 Init Binary: docker-init
 containerd version: 64b8a811b07ba6288238eefc14d898ee0b5b99ba
 runc version: 4bccb38cc9cf198d52bebf2b3a90cd14e7af8c06
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 5.10.217-205.860.amzn2.x86_64
 Operating System: Amazon Linux 2
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 30.89GiB
 Name: ip-10-0-19-159.ec2.internal
 ID: JYX3:CPYG:DNMS:CABR:ASOG:EQXO:WWQ6:5UWL:4MVO:77EB:42ZT:JU7Z
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  <IP_ADDRESS>/8
 Live Restore Enabled: false

Supporting Log Snippets
[  145.441350] cloud-init[3620]: Jun 11 08:11:03 ip-10-0-19-159.ec2.internal systemd[1]: Unit nvidia-persistenced.service entered failed state.
[  145.441505] cloud-init[3620]: Jun 11 08:11:03 ip-10-0-19-159.ec2.internal systemd[1]: nvidia-persistenced.service failed.
[  145.441660] cloud-init[3620]: Jun 11 08:11:03 ip-10-0-19-159.ec2.internal kernel: NVRM: API mismatch: the client has the version 535.183.01, but
[  145.441820] cloud-init[3620]: NVRM: this kernel module has the version 535.161.07.  Please
[  145.441978] cloud-init[3620]: NVRM: make sure that this kernel module and all NVIDIA driver
[  145.442130] cloud-init[3620]: NVRM: components have the same version.
[  145.442286] cloud-init[3620]: Jun 11 08:11:03 ip-10-0-19-159.ec2.internal cloud-init[3620]: Cleanup    : 3:nvidia-persistenced-latest-dkms-535.161.07-1.el7.x86_6   24/32
[  145.442442] cloud-init[3620]: Jun 11 08:11:03 ip-10-0-19-159.ec2.internal cloud-init[3620]: Cleanup    : 3:nvidia-driver-latest-dkms-cuda-535.161.07-1.el7.x86_64   25/32
[  145.480428] cloud-init[3620]: Jun 11 08:11:03 ip-10-0-19-159.ec2.internal cloud-init[3620]: Cleanup    : 3:nvidia-driver-latest-dkms-cuda-libs-535.161.07-1.el7.x   26/32
[  145.480573] cloud-init[3620]: Jun 11 08:11:03 ip-10-0-19-159.ec2.internal cloud-init[3620]: Cleanup    : 3:nvidia-modprobe-latest-dkms-535.161.07-1.el7.x86_64      27/32
[  145.480723] cloud-init[3620]: Jun 11 08:11:03 ip-10-0-19-159.ec2.internal cloud-init[3620]: Cleanup    : 3:nvidia-xconfig-latest-dkms-535.161.07-1.el7.x86_64       28/32
[  145.480889] cloud-init[3620]: Jun 11 08:11:03 ip-10-0-19-159.ec2.internal cloud-init[3620]: Cleanup    : 3:nvidia-driver-latest-dkms-535.161.07-1.el7.x86_64        29/32
[  145.481041] cloud-init[3620]: Jun 11 08:11:03 ip-10-0-19-159.ec2.internal cloud-init[3620]: Cleanup    : 3:nvidia-driver-latest-dkms-devel-535.161.07-1.el7.x86_6   30/32
[  145.481219] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Cleanup    : 3:nvidia-driver-latest-dkms-libs-535.161.07-1.el7.x86_64   31/32
[  145.481352] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Cleanup    : nvidia-fabric-manager-535.161.07-1.x86_64                  32/32
[  145.481511] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: nvidia-persistenced.service holdoff time over, scheduling restart.
[  145.481668] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: Stopped NVIDIA Persistence Daemon.
[  145.481827] cloud-init[3620]: -- Subject: Unit nvidia-persistenced.service has finished shutting down
[  145.481990] cloud-init[3620]: -- Defined-By: systemd
[  145.482144] cloud-init[3620]: -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[  145.482300] cloud-init[3620]: --
[  145.482458] cloud-init[3620]: -- Unit nvidia-persistenced.service has finished shutting down.
[  145.482627] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: Starting NVIDIA Persistence Daemon...
[  145.482780] cloud-init[3620]: -- Subject: Unit nvidia-persistenced.service has begun start-up
[  145.482945] cloud-init[3620]: -- Defined-By: systemd
[  145.483104] cloud-init[3620]: -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[  145.483266] cloud-init[3620]: --
[  145.483424] cloud-init[3620]: -- Unit nvidia-persistenced.service has begun starting up.
[  145.483582] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: Stopped Dynamically Generate Message Of The Day.
[  145.483753] cloud-init[3620]: -- Subject: Unit update-motd.service has finished shutting down
[  145.483909] cloud-init[3620]: -- Defined-By: systemd
[  145.484221] cloud-init[3620]: -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[  145.484386] cloud-init[3620]: --
[  145.484547] cloud-init[3620]: -- Unit update-motd.service has finished shutting down.
[  145.484712] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25461]: Verbose syslog connection opened
[  145.484867] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: Stopping Dynamically Generate Message Of The Day...
[  145.485023] cloud-init[3620]: -- Subject: Unit update-motd.service has begun shutting down
[  145.485177] cloud-init[3620]: -- Defined-By: systemd
[  145.485338] cloud-init[3620]: -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[  145.485487] cloud-init[3620]: --
[  145.485644] cloud-init[3620]: -- Unit update-motd.service has begun shutting down.
[  145.485800] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25461]: Started (25461)
[  145.485955] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: Starting Dynamically Generate Message Of The Day...
[  145.486108] cloud-init[3620]: -- Subject: Unit update-motd.service has begun start-up
[  145.486283] cloud-init[3620]: -- Defined-By: systemd
[  145.486419] cloud-init[3620]: -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[  145.486578] cloud-init[3620]: --
[  145.486735] cloud-init[3620]: -- Unit update-motd.service has begun starting up.
[  145.486894] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:nvidia-driver-latest-dkms-devel-535.183.01-1.el7.x86_6    1/32
[  145.487048] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25461]: Failed to query NVIDIA devices. Please ensure that the NVIDIA device files (/dev/nvidia*) exist, and that user 0 has read and write permissions for those files.
[FAILED] Failed to start Amazon Elastic Container Service - container agent.
[  145.525034] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: nvidia-persistenced.service: control process exited, code=exited status=1
[  145.525160] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25460]: nvidia-persistenced failed to initialize. Check syslog for more details.
See 'systemctl status ecs.service' for details.
[  145.525315] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25461]: PID file unlocked.
[  145.525470] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25461]: PID file closed.
[  145.525624] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25461]: Shutdown (25461)
[  145.525785] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: Failed to start NVIDIA Persistence Daemon.
[  145.525938] cloud-init[3620]: -- Subject: Unit nvidia-persistenced.service has failed
[  145.526091] cloud-init[3620]: -- Defined-By: systemd
[  145.526255] cloud-init[3620]: -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[  145.526406] cloud-init[3620]: --
[  145.526566] cloud-init[3620]: -- Unit nvidia-persistenced.service has failed.
[  145.526727] cloud-init[3620]: --
[  145.526887] cloud-init[3620]: -- The result is failed.
[  145.527040] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: Unit nvidia-persistenced.service entered failed state.
[  145.527202] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: nvidia-persistenced.service failed.
[  145.527358] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal kernel: NVRM: API mismatch: the client has the version 535.183.01, but
[  145.527517] cloud-init[3620]: NVRM: this kernel module has the version 535.161.07.  Please
[  145.527668] cloud-init[3620]: NVRM: make sure that this kernel module and all NVIDIA driver
[  145.527833] cloud-init[3620]: NVRM: components have the same version.
[  145.528251] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : cuda-drivers-535.183.01-1.x86_64                            2/32
[  145.528459] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:nvidia-driver-latest-dkms-535.183.01-1.el7.x86_64         3/32
[  145.528613] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:kmod-nvidia-latest-dkms-535.183.01-1.el7.x86_64           4/32
[  145.528770] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:nvidia-modprobe-latest-dkms-535.183.01-1.el7.x86_64       5/32
[  145.528928] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:nvidia-settings-535.183.01-2.el7.x86_64                   6/32
[  145.529081] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:nvidia-libXNVCtrl-535.183.01-2.el7.x86_64                 7/32
[  145.529249] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:nvidia-driver-latest-dkms-cuda-535.183.01-1.el7.x86_64    8/32
[  145.529420] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:nvidia-driver-latest-dkms-libs-535.183.01-1.el7.x86_64    9/32
[  145.529574] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:nvidia-xconfig-latest-dkms-535.183.01-1.el7.x86_64       10/32
[  145.529727] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:nvidia-driver-latest-dkms-NVML-535.183.01-1.el7.x86_64   11/32
[  145.529883] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:nvidia-libXNVCtrl-devel-535.183.01-2.el7.x86_64          12/32
[  145.530039] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:nvidia-persistenced-latest-dkms-535.183.01-1.el7.x86_6   13/32
[  145.568060] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : nvidia-fabric-manager-535.183.01-1.x86_64                  14/32
[  145.568202] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:nvidia-driver-latest-dkms-cuda-libs-535.183.01-1.el7.x   15/32
[  145.568539] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:nvidia-driver-latest-dkms-NvFBCOpenGL-535.183.01-1.el7   16/32
[  145.568670] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:nvidia-settings-535.161.07-1.el7.x86_64                  17/32
[  145.568830] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : nvidia-fabric-manager-535.161.07-1.x86_64                  18/32
[  145.568979] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:nvidia-persistenced-latest-dkms-535.161.07-1.el7.x86_6   19/32
[  145.569135] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:kmod-nvidia-latest-dkms-535.161.07-1.el7.x86_64          20/32
[  145.569314] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:nvidia-xconfig-latest-dkms-535.161.07-1.el7.x86_64       21/32
[  145.569468] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:nvidia-modprobe-latest-dkms-535.161.07-1.el7.x86_64      22/32
[  145.569622] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:nvidia-libXNVCtrl-devel-535.161.07-1.el7.x86_64          23/32
[  145.569776] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : cuda-drivers-535.161.07-1.x86_64                           24/32
[  145.569938] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:nvidia-driver-latest-dkms-cuda-535.161.07-1.el7.x86_64   25/32
[  145.570088] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:nvidia-driver-latest-dkms-devel-535.161.07-1.el7.x86_6   26/32
[  145.570248] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:nvidia-libXNVCtrl-535.161.07-1.el7.x86_64                27/32
[  145.570411] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:nvidia-driver-latest-dkms-535.161.07-1.el7.x86_64        28/32
[  145.570561] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:nvidia-driver-latest-dkms-libs-535.161.07-1.el7.x86_64   29/32
[  145.570883] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:nvidia-driver-latest-dkms-NvFBCOpenGL-535.161.07-1.el7   30/32
[  145.571034] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:nvidia-driver-latest-dkms-cuda-libs-535.161.07-1.el7.x   31/32
[  145.571185] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Verifying  : 3:nvidia-driver-latest-dkms-NVML-535.161.07-1.el7.x86_64   32/32
[  145.571345] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Installed:
[  145.571499] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: nvidia-libXNVCtrl.x86_64 3:535.183.01-2.el7
[  145.571652] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: nvidia-libXNVCtrl-devel.x86_64 3:535.183.01-2.el7
[  145.571809] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: nvidia-settings.x86_64 3:535.183.01-2.el7
[  145.571972] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Updated:
[  145.572280] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: cuda-drivers.x86_64 0:535.183.01-1
[  145.572437] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: kmod-nvidia-latest-dkms.x86_64 3:535.183.01-1.el7
[  145.572593] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: nvidia-driver-latest-dkms.x86_64 3:535.183.01-1.el7
[  145.610418] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: nvidia-driver-latest-dkms-NVML.x86_64 3:535.183.01-1.el7
[  145.610573] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: nvidia-driver-latest-dkms-NvFBCOpenGL.x86_64 3:535.183.01-1.el7
[  145.610726] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: nvidia-driver-latest-dkms-cuda.x86_64 3:535.183.01-1.el7
[  145.610882] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: nvidia-driver-latest-dkms-cuda-libs.x86_64 3:535.183.01-1.el7
[  145.611042] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: nvidia-driver-latest-dkms-devel.x86_64 3:535.183.01-1.el7
[  145.611200] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: nvidia-driver-latest-dkms-libs.x86_64 3:535.183.01-1.el7
[  145.611355] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: nvidia-fabric-manager.x86_64 0:535.183.01-1
[  145.611533] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: nvidia-modprobe-latest-dkms.x86_64 3:535.183.01-1.el7
[  145.611664] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: nvidia-persistenced-latest-dkms.x86_64 3:535.183.01-1.el7
[  145.611819] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: nvidia-xconfig-latest-dkms.x86_64 3:535.183.01-1.el7
[  145.611974] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Replaced:
[  145.612292] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: nvidia-libXNVCtrl.x86_64 3:535.161.07-1.el7
[  145.612445] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: nvidia-libXNVCtrl-devel.x86_64 3:535.161.07-1.el7
[  145.612604] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: nvidia-settings.x86_64 3:535.161.07-1.el7
[  145.612764] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Complete!
[  145.612916] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: nvidia-persistenced.service holdoff time over, scheduling restart.
[  145.613076] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: Stopped NVIDIA Persistence Daemon.
[  145.613226] cloud-init[3620]: -- Subject: Unit nvidia-persistenced.service has finished shutting down
[  145.613386] cloud-init[3620]: -- Defined-By: systemd
[  145.613539] cloud-init[3620]: -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[  145.613697] cloud-init[3620]: --
[  145.613851] cloud-init[3620]: -- Unit nvidia-persistenced.service has finished shutting down.
[  145.614009] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: Starting NVIDIA Persistence Daemon...
[  145.614164] cloud-init[3620]: -- Subject: Unit nvidia-persistenced.service has begun start-up
[  145.614323] cloud-init[3620]: -- Defined-By: systemd
[  145.614489] cloud-init[3620]: -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[  145.614650] cloud-init[3620]: --
[  145.614800] cloud-init[3620]: -- Unit nvidia-persistenced.service has begun starting up.
[  145.614961] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25495]: Verbose syslog connection opened
[  145.615115] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25495]: Started (25495)
[  145.615274] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25495]: Failed to query NVIDIA devices. Please ensure that the NVIDIA device files (/dev/nvidia*) exist, and that user 0 has read and write permissions for those files.
[  145.615450] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25495]: PID file unlocked.
[  145.615585] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25494]: nvidia-persistenced failed to initialize. Check syslog for more details.
[  145.615740] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal kernel: NVRM: API mismatch: the client has the version 535.183.01, but
[  145.615895] cloud-init[3620]: NVRM: this kernel module has the version 535.161.07.  Please
[  145.654035] cloud-init[3620]: NVRM: make sure that this kernel module and all NVIDIA driver
[  145.654191] cloud-init[3620]: NVRM: components have the same version.
[  145.654343] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25495]: PID file closed.
[  145.654511] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: nvidia-persistenced.service: control process exited, code=exited status=1
[  145.654664] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25495]: Shutdown (25495)
[  145.654822] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: Failed to start NVIDIA Persistence Daemon.
[  145.654980] cloud-init[3620]: -- Subject: Unit nvidia-persistenced.service has failed
[  145.655134] cloud-init[3620]: -- Defined-By: systemd
[  145.655294] cloud-init[3620]: -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[  145.655449] cloud-init[3620]: --
[  145.655609] cloud-init[3620]: -- Unit nvidia-persistenced.service has failed.
[  145.655769] cloud-init[3620]: --
[  145.655924] cloud-init[3620]: -- The result is failed.
[  145.656235] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: Unit nvidia-persistenced.service entered failed state.
[  145.656394] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: nvidia-persistenced.service failed.
[  145.656554] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: Loaded plugins: dkms-build-requires, nvidia, priorities, update-motd, upgrade-
[  145.656707] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal cloud-init[3620]: : helper, versionlock
[  145.656862] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: nvidia-persistenced.service holdoff time over, scheduling restart.
[  145.657020] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: Stopped NVIDIA Persistence Daemon.
[  145.657177] cloud-init[3620]: -- Subject: Unit nvidia-persistenced.service has finished shutting down
[  145.657331] cloud-init[3620]: -- Defined-By: systemd
[  145.657515] cloud-init[3620]: -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[  145.657647] cloud-init[3620]: --
[  145.657802] cloud-init[3620]: -- Unit nvidia-persistenced.service has finished shutting down.
[  145.657956] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: Starting NVIDIA Persistence Daemon...
[  145.658114] cloud-init[3620]: -- Subject: Unit nvidia-persistenced.service has begun start-up
[  145.658270] cloud-init[3620]: -- Defined-By: systemd
[  145.658426] cloud-init[3620]: -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[  145.658595] cloud-init[3620]: --
[  145.658749] cloud-init[3620]: -- Unit nvidia-persistenced.service has begun starting up.
[  145.658902] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25501]: Verbose syslog connection opened
[  145.659065] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25501]: Started (25501)
[  145.659219] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25501]: Failed to query NVIDIA devices. Please ensure that the NVIDIA device files (/dev/nvidia*) exist, and that user 0 has read and write permissions for those files.
[  145.659375] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25501]: PID file unlocked.
[  145.659530] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25500]: nvidia-persistenced failed to initialize. Check syslog for more details.
[  145.659685] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25501]: PID file closed.
[  145.659840] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25501]: Shutdown (25501)
[  145.660012] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: nvidia-persistenced.service: control process exited, code=exited status=1
[  145.660156] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: Failed to start NVIDIA Persistence Daemon.
[  145.660309] cloud-init[3620]: -- Subject: Unit nvidia-persistenced.service has failed
[  145.660465] cloud-init[3620]: -- Defined-By: systemd
[  145.660626] cloud-init[3620]: -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[  145.698713] cloud-init[3620]: --
[  145.698863] cloud-init[3620]: -- Unit nvidia-persistenced.service has failed.
[  145.699023] cloud-init[3620]: --
[  145.699179] cloud-init[3620]: -- The result is failed.
[  145.699337] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal kernel: NVRM: API mismatch: the client has the version 535.183.01, but
[  145.699497] cloud-init[3620]: NVRM: this kernel module has the version 535.161.07.  Please
[  145.699678] cloud-init[3620]: NVRM: make sure that this kernel module and all NVIDIA driver
[  145.699813] cloud-init[3620]: NVRM: components have the same version.
[  145.699972] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: Unit nvidia-persistenced.service entered failed state.
[  145.700292] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: nvidia-persistenced.service failed.
[  145.700448] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: nvidia-persistenced.service holdoff time over, scheduling restart.
[  145.700603] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: Stopped NVIDIA Persistence Daemon.
[  145.700768] cloud-init[3620]: -- Subject: Unit nvidia-persistenced.service has finished shutting down
[  145.700918] cloud-init[3620]: -- Defined-By: systemd
[  145.701076] cloud-init[3620]: -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[  145.701232] cloud-init[3620]: --
[  145.701393] cloud-init[3620]: -- Unit nvidia-persistenced.service has finished shutting down.
[  145.701551] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: Starting NVIDIA Persistence Daemon...
[  145.701709] cloud-init[3620]: -- Subject: Unit nvidia-persistenced.service has begun start-up
[  145.701876] cloud-init[3620]: -- Defined-By: systemd
[  145.702035] cloud-init[3620]: -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[  145.702192] cloud-init[3620]: --
[  145.702346] cloud-init[3620]: -- Unit nvidia-persistenced.service has begun starting up.
[  145.702527] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25515]: Verbose syslog connection opened
[  145.702693] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25515]: Started (25515)
[  145.702859] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25515]: Failed to query NVIDIA devices. Please ensure that the NVIDIA device files (/dev/nvidia*) exist, and that user 0 has read and write permissions for those files.
[  145.703021] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25515]: PID file unlocked.
[  145.703185] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25514]: nvidia-persistenced failed to initialize. Check syslog for more details.
[  145.703347] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25515]: PID file closed.
[  145.703543] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: nvidia-persistenced.service: control process exited, code=exited status=1
[  145.703688] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal nvidia-persistenced[25515]: Shutdown (25515)
[  145.703848] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: Failed to start NVIDIA Persistence Daemon.
[  145.704022] cloud-init[3620]: -- Subject: Unit nvidia-persistenced.service has failed
[  145.704180] cloud-init[3620]: -- Defined-By: systemd
[  145.704337] cloud-init[3620]: -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[  145.704502] cloud-init[3620]: --
[  145.704666] cloud-init[3620]: -- Unit nvidia-persistenced.service has failed.
[  145.704852] cloud-init[3620]: --
[  145.704980] cloud-init[3620]: -- The result is failed.
[  145.705142] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal kernel: NVRM: API mismatch: the client has the version 535.183.01, but
[  145.705295] cloud-init[3620]: NVRM: this kernel module has the version 535.161.07.  Please
[  145.705454] cloud-init[3620]: NVRM: make sure that this kernel module and all NVIDIA driver
[  145.705612] cloud-init[3620]: NVRM: components have the same version.
[  145.705770] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: Unit nvidia-persistenced.service entered failed state.
[  145.705931] cloud-init[3620]: Jun 11 08:11:04 ip-10-0-19-159.ec2.internal systemd[1]: nvidia-persistenced.service failed.
[  145.743869] cloud-init[3620]: Jun 11 08:11:05 ip-10-0-19-159.ec2.internal systemd[1]: nvidia-persistenced.service holdoff time over, scheduling restart.
[  145.744039] cloud-init[3620]: Jun 11 08:11:05 ip-10-0-19-159.ec2.internal systemd[1]: Stopped NVIDIA Persistence Daemon.
[  145.744179] cloud-init[3620]: -- Subject: Unit nvidia-persistenced.service has finished shutting down
[  145.744340] cloud-init[3620]: -- Defined-By: systemd
[  145.744501] cloud-init[3620]: -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[  145.744658] cloud-init[3620]: --
[  145.744809] cloud-init[3620]: -- Unit nvidia-persistenced.service has finished shutting down.
[  145.744968] cloud-init[3620]: Jun 11 08:11:05 ip-10-0-19-159.ec2.internal systemd[1]: start request repeated too quickly for nvidia-persistenced.service
[  145.745123] cloud-init[3620]: Jun 11 08:11:05 ip-10-0-19-159.ec2.internal systemd[1]: Failed to start NVIDIA Persistence Daemon.
[  145.745284] cloud-init[3620]: -- Subject: Unit nvidia-persistenced.service has failed
[  145.745438] cloud-init[3620]: -- Defined-By: systemd
[  145.745595] cloud-init[3620]: -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[  145.745751] cloud-init[3620]: --
[  145.745932] cloud-init[3620]: -- Unit nvidia-persistenced.service has failed.
[  145.746072] cloud-init[3620]: --
[  145.746224] cloud-init[3620]: -- The result is failed.
[  145.746379] cloud-init[3620]: Jun 11 08:11:05 ip-10-0-19-159.ec2.internal systemd[1]: Unit nvidia-persistenced.service entered failed state.
[  145.746541] cloud-init[3620]: Jun 11 08:11:05 ip-10-0-19-159.ec2.internal systemd[1]: nvidia-persistenced.service failed.

...
(some logs related to user-startup omitted because they contain sensitive information)
...

[  146.047052] cloud-init[3620]: invalid_payloadCloud-init v. 19.3-46.amzn2.0.2 finished at Tue, 11 Jun 2024 08:11:11 +0000. Datasource DataSourceEc2.  Up 144.29 seconds
[  OK  ] Started Dynamically Generate Message Of The Day.
[  OK  ] Reached target Multi-User System.
[  OK  ] Reached target Cloud-init target.
[  OK  ] Reached target Graphical Interface.
         Starting Update UTMP about System Runlevel Changes...
[  OK  ] Started Update UTMP about System Runlevel Changes.

[  156.380043] NVRM: API mismatch: the client has the version 535.183.01, but
[  156.380043] NVRM: this kernel module has the version 535.161.07.  Please
[  156.380043] NVRM: make sure that this kernel module and all NVIDIA driver
[  156.380043] NVRM: components have the same version.
[  166.624266] NVRM: API mismatch: the client has the version 535.183.01, but
[  166.624266] NVRM: this kernel module has the version 535.161.07.  Please
[  166.624266] NVRM: make sure that this kernel module and all NVIDIA driver
[  166.624266] NVRM: components have the same version.
[  176.872003] NVRM: API mismatch: the client has the version 535.183.01, but
[  176.872003] NVRM: this kernel module has the version 535.161.07.  Please
[  176.872003] NVRM: make sure that this kernel module and all NVIDIA driver
[  176.872003] NVRM: components have the same version.
[  187.128036] NVRM: API mismatch: the client has the version 535.183.01, but
[  187.128036] NVRM: this kernel module has the version 535.161.07.  Please
[  187.128036] NVRM: make sure that this kernel module and all NVIDIA driver
[  187.128036] NVRM: components have the same version.
[  197.380133] NVRM: API mismatch: the client has the version 535.183.01, but
[  197.380133] NVRM: this kernel module has the version 535.161.07.  Please
[  197.380133] NVRM: make sure that this kernel module and all NVIDIA driver
[  197.380133] NVRM: components have the same version.
[  207.628066] NVRM: API mismatch: the client has the version 535.183.01, but
[  207.628066] NVRM: this kernel module has the version 535.161.07.  Please
[  207.628066] NVRM: make sure that this kernel module and all NVIDIA driver
[  207.628066] NVRM: components have the same version.
[  217.879910] NVRM: API mismatch: the client has the version 535.183.01, but
[  217.879910] NVRM: this kernel module has the version 535.161.07.  Please
[  217.879910] NVRM: make sure that this kernel module and all NVIDIA driver
[  217.879910] NVRM: components have the same version.
[  228.124050] NVRM: API mismatch: the client has the version 535.183.01, but
[  228.124050] NVRM: this kernel module has the version 535.161.07.  Please
[  228.124050] NVRM: make sure that this kernel module and all NVIDIA driver
[  228.124050] NVRM: components have the same version.
[  238.376258] NVRM: API mismatch: the client has the version 535.183.01, but
[  238.376258] NVRM: this kernel module has the version 535.161.07.  Please
[  238.376258] NVRM: make sure that this kernel module and all NVIDIA driver
[  238.376258] NVRM: components have the same version.
[  248.628033] NVRM: API mismatch: the client has the version 535.183.01, but
[  248.628033] NVRM: this kernel module has the version 535.161.07.  Please
[  248.628033] NVRM: make sure that this kernel module and all NVIDIA driver
[  248.628033] NVRM: components have the same version.
[  258.876087] NVRM: API mismatch: the client has the version 535.183.01, but
[  258.876087] NVRM: this kernel module has the version 535.161.07.  Please
[  258.876087] NVRM: make sure that this kernel module and all NVIDIA driver
[  258.876087] NVRM: components have the same version.
[  269.128070] NVRM: API mismatch: the client has the version 535.183.01, but
[  269.128070] NVRM: this kernel module has the version 535.161.07.  Please
[  269.128070] NVRM: make sure that this kernel module and all NVIDIA driver
[  269.128070] NVRM: components have the same version.
[  279.380126] NVRM: API mismatch: the client has the version 535.183.01, but
[  279.380126] NVRM: this kernel module has the version 535.161.07.  Please
[  279.380126] NVRM: make sure that this kernel module and all NVIDIA driver
[  279.380126] NVRM: components have the same version.
[  289.624215] NVRM: API mismatch: the client has the version 535.183.01, but
[  289.624215] NVRM: this kernel module has the version 535.161.07.  Please
[  289.624215] NVRM: make sure that this kernel module and all NVIDIA driver
[  289.624215] NVRM: components have the same version.
[  299.880090] NVRM: API mismatch: the client has the version 535.183.01, but
[  299.880090] NVRM: this kernel module has the version 535.161.07.  Please
[  299.880090] NVRM: make sure that this kernel module and all NVIDIA driver
[  299.880090] NVRM: components have the same version.
[  310.124053] NVRM: API mismatch: the client has the version 535.183.01, but
[  310.124053] NVRM: this kernel module has the version 535.161.07.  Please
[  310.124053] NVRM: make sure that this kernel module and all NVIDIA driver
[  310.124053] NVRM: components have the same version.
[  320.380096] NVRM: API mismatch: the client has the version 535.183.01, but
[  320.380096] NVRM: this kernel module has the version 535.161.07.  Please
[  320.380096] NVRM: make sure that this kernel module and all NVIDIA driver
[  320.380096] NVRM: components have the same version.
[  330.628039] NVRM: API mismatch: the client has the version 535.183.01, but
[  330.628039] NVRM: this kernel module has the version 535.161.07.  Please
[  330.628039] NVRM: make sure that this kernel module and all NVIDIA driver
[  330.628039] NVRM: components have the same version.
[  340.880010] NVRM: API mismatch: the client has the version 535.183.01, but
[  340.880010] NVRM: this kernel module has the version 535.161.07.  Please
[  340.880010] NVRM: make sure that this kernel module and all NVIDIA driver
[  340.880010] NVRM: components have the same version.
[  351.124126] NVRM: API mismatch: the client has the version 535.183.01, but
[  351.124126] NVRM: this kernel module has the version 535.161.07.  Please
[  351.124126] NVRM: make sure that this kernel module and all NVIDIA driver
[  351.124126] NVRM: components have the same version.

Please let me know if there's anything I can do to prevent this issue from happening in the future.

Hi @truenorth8 , thanks for reporting the issue. May I know what AMI is being used by your deployment? As a verification, I just ran some sanity tests with 20240610 Kernel 5.10 GPU AMI, and the agent and GPUs seem to work OK. Could you verify that you have this AMI in your deployment?
Also, normally ECS AMIs should not be seeing version mismatch between drivers and client and these should not be updated during instance launches. So I do not expect nvidia driver related logs in cloud-init-output. Could you verify if you might have nvidia updates enabled? We recommend you have them disabled (these are disabled in base Amazon Linux AMIs and ECS AMIs) as upstream Amazon Linux updates might trigger failures

@prateekchaudhry yum update -y was the culprit, removing it caused the issue to go away


Broader support for latest contracts

Account for recent contract changes,
Implements support for the star release contracts, Linear and Conditional.

There are no tests for the release contracts yet.  Putting this PR up in the mean time so it can start getting reviewed, and used by Bridge whenever it starts being needed.

:+1: :+1: LGTM.  Hulking it!
One thing I had previously thought about re: testing is that it would be good to break the tests up a bit and make them each rely less on previous state.  This is somewhat annoying since the underlying chain state is persistent, of course, but still -- we could just use more addresses/ships, say, rather than keep using the same addresses, and relying so much on what we previously did with them way down in the test suite.
Another thing that I thought of previously was that it might be nice down the line is to replace the { error: true }; if (predicate) { error: false, reason: foo } pattern with an error type like that found in data.either.  I've used data.maybe a bit and it's great, as far as a maybe type in JS goes. 😄
(Neither comment relevant to this PR, just general thoughts I'd previously had.)

We could definitely to with improving the testing method here in general. Let's sit down today (invite sent!) and see if we can come up with something that's not a gigantic pain.

Something else I'm not quite pleased with in this PR is the naming of the check functions for these contracts? Their functions have identical names, but different logic, and checks.js doesn't currently namespace. Do we want to make it namespaced (ie checks.constitution.canSpawn rather than checks.canSpawn), or are we fine with weird function names?
adds another point for the scoreboard for keeping checks separated by contract

@Fang- Do you want to merge this bad boy?  I got the tests working with HEAD on constitution, which is good enough for me for the time being. 😁

I'm fine with merging this as-is, without the lockup contract tests. Not to make light of the importance of these pieces of software, but this particular part is definitely difficult to mess up. If it works, it works. Writing the remaining tests here is so far down my queue that we'd be waiting another month on it, so let's just merge.


Fixes #351 issue with KeyFile  not working with 'auto' in some situations

Fixes #351

 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.You have signed the CLA already but the status is still pending? Let us recheck it.


min/max data missing for FusedBatchNorm op

Please make sure that this is a bug. As per our GitHub Policy, we only address code/doc bugs, performance issues, feature requests and build/installation issues on GitHub. tag:bug_template
System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): No
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Ubuntu 18.04
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device: N/A
TensorFlow installed from (source or binary): binary
TensorFlow version (use command below): r1.13
Python version: 3.6
Bazel version (if compiling from source):
GCC/Compiler version (if compiling from source):
CUDA/cuDNN version: 10
GPU model and memory: GeForce 2080Ti

You can collect some of this information using our environment capture
script
You can also obtain the TensorFlow version with: 1. TF 1.0: python -c "import tensorflow as tf; print(tf.GIT_VERSION, tf.VERSION)" 2. TF 2.0: python -c "import tensorflow as tf; print(tf.version.GIT_VERSION, tf.version.VERSION)"
Describe the current behavior
I'm trying to use contrib/quantize module to perform quantize aware training and convert the trained model to quantize TFlite model. When run converter.convert(), the following error will be raised:
tensorflow/lite/toco/tooling_util.cc:1702] Array conv0/batch_normalization_v1/FusedBatchNorm, which is an input to the Conv operator producing the output array conv1/re_lu/Relu, is lacking min/max data, which is necessary for quantization. If accuracy matters, either target a non-quantized output format, or run quantized training with your model from a floating point checkpoint to change the input graph to contain min/max information. If you don't care about accuracy, you can pass --default_ranges_min= and --default_ranges_max= for easy experimentation.
Aborted (core dumped)

When adding ReLU op after the BN, it will be converted without the error massage. But in the tensorboard graph, I cannot see any differences on the FusedBatchNorm part with and without ReLU.
Describe the expected behavior
Convert to TFLite without error
Code to reproduce the issue
import tensorflow as tf
import os
os.environ["CUDA_DEVICE_ORDER"] = "PCI_BUS_ID"
os.environ['CUDA_VISIBLE_DEVICES'] = ''

def build_model(input):
    '''build the model'''
    with tf.name_scope('conv0'):
        x = tf.keras.layers.Conv2D(24, kernel_size=(3, 3), padding='same', use_bias=False)(input)
        x = tf.keras.layers.BatchNormalization(fused=True)(x)
        #x = tf.keras.layers.ReLU()(x)
    with tf.name_scope('conv1'):
        x = tf.keras.layers.Conv2D(48, kernel_size=(3, 3), padding='same', use_bias=False)(x)
        x = tf.keras.layers.BatchNormalization(fused=True)(x)
        x = tf.keras.layers.ReLU()(x)
    x = tf.concat((input, x), axis=-1)
    with tf.name_scope('conv_out'):
        x = tf.keras.layers.Conv2D(10, kernel_size=(1, 1), padding='same', use_bias=True)(x)
        x = tf.keras.layers.ReLU()(x)
    return x

# build model
tf.keras.backend.set_learning_phase(1)
input = tf.placeholder(tf.float32, shape=(None, None, None, 3))
x = build_model(input)

# quantize
graph = tf.get_default_graph()
tf.contrib.quantize.create_training_graph(input_graph=graph, quant_delay=0)

# save
saver = tf.train.Saver()
with tf.Session(graph=graph) as sess:
    sess.run(tf.global_variables_initializer())
    saver.save(sess, './tmp/simple/model.ckpt')
    writer = tf.summary.FileWriter('./tmp/simple/train/', sess.graph)
    writer.flush()
    writer.close()

# eval
tf.reset_default_graph()
tf.keras.backend.set_learning_phase(0)
input = tf.placeholder(tf.float32, shape=(1, 32, 32, 3), name='input')
x = build_model(input)
x = tf.identity(x, 'output')

# quantize
graph = tf.get_default_graph()
init_min=-6, init_max=6)
tf.contrib.quantize.create_eval_graph(graph)
saver = tf.train.Saver()
with tf.Session(graph=graph) as sess:
    sess.run(tf.global_variables_initializer())
    saver.restore(sess, tf.train.latest_checkpoint('./tmp/simple'))
    writer = tf.summary.FileWriter('./tmp/simple/eval/', graph)
    writer.flush()
    writer.close()

    # freeze graph
    graph_def = graph.as_graph_def()
    froze_graph = tf.graph_util.convert_variables_to_constants(sess, graph_def, ['output'])
    tf.io.write_graph(froze_graph, './tmp/simple/', 'freeze_graph.pb')

# convert to TFLite
graph_def_file = './tmp/simple/freeze_graph.pb'
input_array = ["input"]
converter = tf.lite.TFLiteConverter.from_frozen_graph(graph_def_file, input_array, ['output'],
                                                      input_shapes={"input": [1, 32, 32, 3]})
converter.allow_custom_ops = True
converter.inference_type = tf.lite.constants.QUANTIZED_UINT8
converter.inference_input_type = tf.lite.constants.QUANTIZED_UINT8
converter.quantized_input_stats = {"input": (0., 255.)}
tfmodel = converter.convert()
open("./tmp/simple/converted_model.tflite", "wb").write(tfmodel)

# load the TFLite
interpreter = tf.lite.Interpreter(model_path="./tmp/simple/converted_model.tflite")
interpreter.allocate_tensors()
print("TFLite model loadded!!")

Other info / logs
Include any logs or source code that would be helpful to diagnose the problem. If including tracebacks, please include the full traceback. Large logs and files should be attached.

Looks like we have come across similar issue. Please have a look on #27952. Let us know if it is not the same. You can also have a look on #21725. Thanks!

Automatically closing due to lack of recent activity. Please update the issue when new information becomes available, and we will reopen the issue. Thanks!

anyone can help? facing the same issue?

@achandraa
Recently I tried to do quantization aware training and do Toco converter to Tflite model with a network having batch_norm layers. but I got the error below.
"TOCO failed. See console for info.\n%s\n%s\n" % (stdout, stderr)) tensorflow.lite.python.convert.ConverterError: TOCO failed. See console for info. 2019-08-23 09:53:37.518330: I tensorflow/lite/toco/graph_transformations/graph_transformations.cc:39] Before Removing unused ops: 83 operators, 127 arrays (0 quantized) 2019-08-23 09:53:37.518848: I tensorflow/lite/toco/graph_transformations/graph_transformations.cc:39] Before general graph transformations: 83 operators, 127 arrays (0 quantized) 2019-08-23 09:53:37.520599: I tensorflow/lite/toco/graph_transformations/graph_transformations.cc:39] After general graph transformations pass 1: 22 operators, 39 arrays (1 quantized) 2019-08-23 09:53:37.521044: I tensorflow/lite/toco/graph_transformations/graph_transformations.cc:39] After general graph transformations pass 2: 21 operators, 38 arrays (1 quantized) 2019-08-23 09:53:37.521219: I tensorflow/lite/toco/graph_transformations/graph_transformations.cc:39] After general graph transformations pass 3: 20 operators, 36 arrays (1 quantized) 2019-08-23 09:53:37.521377: I tensorflow/lite/toco/graph_transformations/graph_transformations.cc:39] Before pre-quantization graph transformations: 20 operators, 36 arrays (1 quantized) 2019-08-23 09:53:37.521443: I tensorflow/lite/toco/graph_transformations/graph_transformations.cc:39] After pre-quantization graph transformations pass 1: 14 operators, 30 arrays (1 quantized) 2019-08-23 09:53:37.521516: I tensorflow/lite/toco/graph_transformations/graph_transformations.cc:39] Before Group bidirectional sequence lstm/rnn: 14 operators, 30 arrays (1 quantized) 2019-08-23 09:53:37.521583: F tensorflow/lite/toco/tooling_util.cc:1709] Array layer_1/batch_normalization/FusedBatchNorm_mul_0, which is an input to the Add operator producing the output array layer_1/conv1, is lacking min/max data, which is necessary for quantization. If accuracy matters, either target a non-quantized output format, or run quantized training with your model from a floating point checkpoint to change the input graph to contain min/max information. If you don't care about accuracy, you can pass --default_ranges_min= and --default_ranges_max= for easy experimentation. Fatal Python error: Aborted
In this case I need to remain the accuracy of my model. So I think set default_ranges_min/max shouln not be used. Can you or anyone can help me to solve this?


Clear out old irrelevent pkgpanda docs

These were never relevant or are now incorrect

@orsenthil @lingmann can I get a second :ship: on this?


Fix scoreboard in STVs

Boxes

There appears to be no STV control flags (such as if_mvm). If there was one, I'm just not aware of it.


[BUG] Uncaught Exception when starting Kingdom Scan

Receive this error anytime I'm running a kingdom scan no matter the scanner settings:
2024-03-11 00:36:50 kingdom_scanner_ui CRITICAL Uncaught exception
Traceback (most recent call last):
  File "PIL\ImageFile.py", line 515, in _save
io.UnsupportedOperation: fileno

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "threading.py", line 1045, in _bootstrap_inner
  File "threading.py", line 982, in run
  File "kingdom_scanner_ui.py", line 607, in launch_scanner
  File "roktracker\kingdom\scanner.py", line 513, in start_scan
  File "roktracker\kingdom\scanner.py", line 207, in scan_governor
  File "tesserocr.pyx", line 1679, in tesserocr._tesserocr.PyTessBaseAPI.SetImage
  File "tesserocr.pyx", line 331, in tesserocr._tesserocr._image_buffer
  File "tesserocr.pyx", line 335, in tesserocr._tesserocr._image_buffer
  File "PIL\Image.py", line 2438, in save
  File "PIL\BmpImagePlugin.py", line 449, in _save
  File "PIL\ImageFile.py", line 519, in _save
  File "PIL\ImageFile.py", line 530, in _encode_tile
SystemError: tile cannot extend outside image

STR:

Open Kingdom Scanner (GUI).exe
Click Start Scan
Wait about 20 seconds
Error Occurs

Thanks for the report, I will look into it.

This seems to be related to issue #81 indirectly. But the main problem seems to be that tesseract gets an empty image when the wrong instance is used (and then the image is cut to 0 pixels). Further investigation is needed.


palette items didn't appear with npm install

when i installed this library using npm (inside the .node-red dir) the palette notes didn't appear.  when i went to manage palette, the UI would not allow me to enable the nodes.  however, by installing via the 'install' tab in manage palette, the nodes appeared as expected.
i was using v0.2.11, other version info below
29 Nov 12:03:08 - [info] Node-RED version: v0.15.2
29 Nov 12:03:08 - [info] Node.js  version: v4.5.0
29 Nov 12:03:08 - [info] Linux 4.4.0-24-generic x64 LE

i believe this problem (and others) are caused by using an earlier version of node.  switching to 6.9.x and the problems go away - i think because your library depends on selenium-webdriver, which specifies the node version in package.json
  "engines": {
    "node": ">= 6.9.0"
  },

Thank you for your analyzing, I will put the required node version into the package setting.

I found another version issue with is-reachable.  version 2.x of this
module only supports promises.  I will make a pull request, or you can lock
it to 1.x
On Nov 29, 2016 6:20 PM, "Duong Dinh Cuong"<EMAIL_ADDRESS>wrote:

Thank you for your analyzing, I will put the required node version into
the package setting.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/cuongquay/node-red-contrib-selenium-webdriver/issues/3#issuecomment-263763559,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA6lUUdrS9OHnB4husFzoVfEqnacsYkEks5rDN1zgaJpZM4K_a7b
.

I would appreciate if you can make a pull request on any issue :+1:

no problem.  PR submitted.  the is-reachable issue had me stumped for ages (because the code crashed silently).  perhaps there is a better way to run node-red with more debug info/exception catching?  i am very new to node-red, so i found the bug by adding lots of console.log to see where it was dying.

fixed by https://github.com/cuongquay/node-red-contrib-selenium-webdriver/commit/0baf9fb3008afff0a6bce32cb559ceac60ff7178


npm run dev works great. Generate is deleting components from DOM after the page loads?

I have my static site temporarily hosted here to show the issue:
https://vibrant-hamilton-ce6e1c.netlify.com/blog/
My project: https://github.com/KyleTryon/VidFireBlog
my default.vue layout file looks like this, very simple.
<template>
  <div id="app-container">
    <vf-header/>
    <vf-nav/>
    <nuxt/>
    <vf-footer/>
  </div>
</template>

Everything works as expected on the dev server. However you can see if you visit the url above, the Header and Nav render and then delete themselves immediately.
There are no errors in console, and in the inspector, you can see the dom elements are actually completely removed.

If you disable javascript, the CSS is a little messed up but the elements stay on the page.

I solve it with disable Cloudflare's minify but i dont know you have use it or not

@hanjeahwan the issue happens locally. It doesnt seem like the generated files are actually static as they should be.

I'm still having this issue as of v1.4.x. Is there any way to easily identify what components are causing the problem? Everything renders absolutely fine using the local server (nuxt / npm run dev)


Wrapping observable.set within startTransition breaks atomic updates

Hi! legend-state is fantastic, and I love it!
I've been playing with your demo on codesandbox and found that wrapping count.set(...) in startTransition(means enabling concurrent mode) breaks atomic updates:  link.
https://user-images.githubusercontent.com/61194245/194503391-f4c2ab29-cb09-4d56-a491-fc7a36af9fb3.mp4
I attached a video showing that components rerender four times each time the count updates.
Is it intended? Any plans for supporting concurrent rendering?
Thanks!

Oh very interesting! Thank you for a good repro. We absolutely should support concurrent rendering so I will take a look at fixing it this weekend.

@jmeistrich

startTransition runs a useState under the hood, calling setPending(true) and then setPending(false)

This 👆 is 🤯. New information for me. Thank you for the investigation!


Playerdata corruption involving the paralysis effect

If you have a weapon with pinning 2 and throw it into a creeper, giving it the paralysis effect, and said creeper explodes, it leaves an AOE cloud of the paralysis effect. If you walk into the cloud, you will get paralysis indefinitely and upon attempting to relog, having the paralysis effect without a weapon stuck in you corrupts your playerdata.

Interesting, I dont have pinned II detailed in my mod but it still being possible to get from Sindri. This should be fixed when i next update the mod. Thank you for reporting.


Location marker does not show on Google maps in IOS

Is this a known issue? It seems to work fine on default map but when using Google map as provider the location marker does not show.
Code is as follow:
<MapView
              style={{...StyleSheet.absoluteFillObject,}}
              provider="google"
              showsUserLocation={true}
              cacheEnabled={true}
              showsTraffic={false}
              showsIndoors={false}
              loadingEnabled={true}
              showsBuildings={false}
              region={{
                  latitude: location.latitude,
                  longitude: location.longitude,
                  latitudeDelta: location.latitudeDelta,
                  longitudeDelta: location.longitudeDelta,
                }}
              >

              {businesses.length > 0 ? businesses.map(marker => (
                  <MapView.Marker
                    coordinate={this.getCoordinates(marker)}
                    key={marker.id}
                    flat={true}
                    image={typeof marker.image_url !== 'undefined'  ? marker.image_url : marker.icon}
                  >
                  </MapView.Marker>
              )) : <View />}
            </MapView>

XCode 8

The functionality has been merged in version 0.10.4: https://github.com/airbnb/react-native-maps/blob/master/CHANGELOG.md#0104-october-31-2016

Was there a possible regression in 0.11? I'm using GoogleMaps on iOS and I'm not able to get this to work on simulator or the iPhone 5s that I'm using for testing.
<MapView 				provider={"google"} 				style={styles.map} 				region={props.region} 				onRegionChangeComplete={props.handleRegionChange} 				loadingEnabled={true} 				showsUserLocation={true} 				showsPointsOfInterest={false}>

Yes and no lol
In fact the 0.11 doesn't seem to have everything that's inside the 0.10.4
0.10.4 is out since 31st October but the 0.11 is around since the 16th... https://github.com/airbnb/react-native-maps/blob/master/CHANGELOG.md#0104-october-31-2016

I opened an issue: https://github.com/airbnb/react-native-maps/issues/851

Yeah it's a bit confusing because we have been maintaining 0.10.x releases separately for use at airbnb until we can upgrade to<EMAIL_ADDRESS>It's good to know that upgrading would introduce a regression for us.

@macnube A new version has been released containing every thing that was missing from the 0.11

Please let us know if this is still the case. Thank you.
Closing as it's an old issue.


cmd/go: go get fails with git version 1.7.1 on CentOS 6.9

What version of Go are you using (go version)?

$ go version
go version go1.11.1 linux/amd64

What did you do?
Just go get something with the Modules mode
What happened?
go: unknown revision xxxxxxxx
go: error loading module requirements

Root cause
git command below is what go get -x shows.
$ git -c log.showsignature=false log -n1 '--format=format:%H %ct %D' xxxxxxxx
Unknown option: -c
usage: git [--version] [--exec-path[=GIT_EXEC_PATH]] [--html-path]
           [-p|--paginate|--no-pager] [--no-replace-objects]
           [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE]
           [--help] COMMAND [ARGS]

$ git version
git version 1.7.1

$ cat /etc/*issue
CentOS release 6.9 (Final)

Actually, we added the -c log.showsignature=false to support git versions lower than 2.10. https://github.com/golang/go/commit/90066bf06a9b10b3b222a289934b93723bb788d6
Most recent systems have 2.7.4. Git 1.7 seems to have been released on 2010. Not sure how far back are we willing to go to support git versions. Perhaps it goes back to @bcmills' comment here to explicitly specify a minimum git version.
/cc @bcmills @rsc

#26746 tracks defining a minimum support version of git (or perhaps instead a set of supported distro versions).
One comment from there:

The table at https://en.wikipedia.org/wiki/Git#Release says that Git 2.12 and older are themselves no longer maintained.

1.7 is pretty old.
@adam8157 are you able to upgrade your version of git?

FWIW, git -c was added in git 1.7.2:
https://github.com/git/git/commit/8b1fa778676ae94f7a6d4113fa90947b548154dd

According to the table at https://wiki.centos.org/About/Product, CentOS6 is currently on version 6.10. Any idea whether that comes with a newer Git?

Looks like it is still git 1.7.1.
Since CentOS is intended to be long term stable, they are unlikely to update anything except to fix bugs.,

This happens on my testing env which is the same as my deployment env, it's OK to upgrade. However, I guess CentOS/RHEL 6 is still a big player, especially as the production OS, in the Linux world.

As a workaround, note that you can set GOPROXY=https://proxy.golang.org to fetch using HTTPS instead of Git.

I believe this can be closed with CentOS 6 having reached EOL on 2020-11-30
Current policy is at https://github.com/golang/go/issues/26746#issuecomment-1169102174


Forge tests fails with "No target contract" message

Component
Forge
Have you ensured that all of these are up to date?

[X] Foundry
[X] Foundryup

What version of Foundry are you on?
forge 0.2.0 (a279d2e 2022-04-04T00:03:20.128570951+00:00)
What command(s) is the bug in?
forge test --optimize --optimize-runs 1000000 -v
Operating System
Linux
Describe the bug
Both CI pipeline (using https://github.com/onbjerg/foundry-toolchain) and local forge tests started to fail since updating to latest nightly build, see output below
The application panicked (crashed).
Message:  No target contract
Location: utils/src/lib.rs:217
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1: __libc_start_main
at :

it works fine if building without https://github.com/gakonst/foundry/commit/5827745d5d938b9c757a6ee943290481cf7426ee

My findings too, on Telegram (with a reproducible example):

it was broken in https://github.com/gakonst/foundry/pull/978
cc @mattsse: running forge test before #978 was merged works fine, but as soon as #978 is merged then running forge test in https://github.com/FrenchyPeanut/NFT-with-Foundry/tree/master/packages/hardhat panics:
The application panicked (crashed).
Message:  No target contract
Location: utils/src/lib.rs:217
Backtrace omitted.
Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.
fish: Job 1, 'forge test' terminated by signal SIGABRT (Abort)

so debugging some more it looks like the source contracts are not built together with forge test, doing forge build && forge test worked for me ...

Are you using libraries, or just normal contracts?

should be resolved since we reverted sparse mode #1189
and root issue fixed here https://github.com/gakonst/ethers-rs/pull/1107

I can still reproduce the issue with the latest version (forge 0.2.0 (bab38d6 2022-05-06T00:07:49.001076+00:00) at the time I'm writing this) but only if I try to debug a test case.
I made a minimal example project that demonstrates the issue:
https://github.com/danielattilasimon/foundry-bug
I just did forge init and added a dummy library, which I'm importing from only from within tests (though I don't know if that matters or not).
forge test works fine:
❯ forge test
[⠒] Compiling...
No files changed, compilation skipped

Running 1 test for test/Contract.t.sol:ContractTest
[PASS] testExample() (gas: 3262)
Test result: ok. 1 passed; 0 failed; finished in 6.25ms

If I try to debug a test case, it fails:
❯ forge test --debug testExample
[⠔] Compiling...
No files changed, compilation skipped
[⠢] Compiling...
[⠰] Compiling 7 files with 0.8.13
[⠒] Solc 0.8.13 finished in 2.16s
Compiler run successful
The application panicked (crashed).
Message:  No target contract
Location: utils/src/lib.rs:218

Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.
fish: Job 1, 'forge test --debug testExample' terminated by signal SIGABRT (Abort)


csproj validation rules

Hi, I want to use your code to validate my new (and old) csproj file.
It includes rules like validating 'Company' value, paths absolute to the solution and so.
Can you suggest a way to handle it?

When you say validating, do you mean assuring that it has a certain value for example as part of a CI process?
The difficulty is that is can be in 2 places now, either as an assembly attribute or in the project file. And finding out if it is an assembly attribute means either applying heuristics regarding the path or compiling the project and reading the outputted binary.

Yes, like CI pipeline.
So let's leave the old csproj and assembly, and focus just on new csproj, validating that in all new csproj we write the "Company" tag, for example.
What will be the best way to do this?

No, that's for the job.
But you are right, there is MSBuild /validate option to achieve that.
Thank you!🙏
On Wed, 14 Nov 2018, 5:22 Hans van Bakel<EMAIL_ADDRESS>wrote:

So I looked at your bio and it says you’re a student. I’m assuming this is
something you need to do as part of an assignment? In that case, what have
you tried? Especially in the new setup this should be trivial, doing it as
part of a CI pipeline then just becomes figuring out what your pipeline is.
You probably should be looking at msbuild.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hvanbakel/CsprojToVs2017/issues/214#issuecomment-438524007,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQ3hX7DQWWeStAruPSLWm6okMxEIgTaZks5uu4xwgaJpZM4YbSQX
.


Move Repository To rust-lang

Hello, the current rust-lang-nursery organisation is considered deprecated, and the Rust Programming Language organisation is trying to consolidate managing Rust's GitHub organisations, as such we'd like you to consider moving your repository to the main rust-lang organisation instead.
How Do I Move To rust-lang?
You most likely won't be able to transfer your repository directly, if so you'll need to transfer your repository to @Mark-Simulacrum, who will then move your repository to the rust-lang organisation.
Deprecating
If you no longer intend to maintain this repository, please let us know and we will take of deprecating the project.

This repository doesn't have an official maintainer per se, it's sort of defactor been me and @sfackler from @rust-lang/libs. I don't think many of us are too thrilled to maintain this crate much more, and use of it is largely focused on socket2 now at this point.
I think this is a good opportunity to take to deprecate the project personally. If someone would like to step up and maintain this, though, they're more than welcome to!

👍 on deprecating

As a consumer of this, then socket2, I agree. Deprecate.

Marked as deprecated and under sustaining maintenance only.


feat(twirl): Adding in examples of using twirl templating. #423.

This is a pretty barebones contrived example that shows off some of what you can do with twirl. Thanks for putting together such an awesome project!

Thanks @brbrown25, I have pulled your changes in #482

Thanks @brbrown25, I have pulled your changes in #482

Thanks!


Retune SITL model typhoon h480

Describe problem solved by this pull request
This Fixes #13163 where the typhoon_480 was showing oscillations is forward flight in SITL
Describe your solution
These are the retuned values of the typhoon h480 coming from the suggestion of @dayjaby
Test data / coverage
Log: https://review.px4.io/plot_app?log=7d5eae16-1c0e-4c42-8912-b9176f4d27e6

It is MC_PITCH_P and MC_ROLL_P, not MC_PITCH and MC_ROLL!


SwitchCraft autocomplete support

SwitchCraft 3 uses a system to autocomplete any krist transaction targets that are displayed on a ComputerCraft screen. It can recognise<EMAIL_ADDRESS>to autocomplete it. Kristify currently does not show the string<EMAIL_ADDRESS>concatenated in full, but shows the name and the item name seperately.
Could we use un-used screen space to render as much strings as possible for all items, with the background and foreground colour the same, so that it is not visible on the screen, but it would be picked up by autocomplete?
Would make shops much more convenient! Awesome!

Hey, thank you for your contribution here!
If you click on a item, it shows the full name with metaname on the bottom left corner normally.
But I like your idea too! We are currently working on theme support anyways, so I might add that to the two default ones!
I will keep that open until this happened.


TypeError: stat: path should be string, bytes, os.PathLike or integer, not NoneType

Traceback (most recent call last):
File "C:\Users\fengxiaohu\Downloads\Compressed\FSL\Prompt\CaFo-main\main.py", line 276, in
main()
File "C:\Users\fengxiaohu\Downloads\Compressed\FSL\Prompt\CaFo-main\main.py", line 175, in main
assert (os.path.exists(args.config))
File "C:\Users\fengxiaohu\Anaconda3\envs\Anaconda3\lib\genericpath.py", line 19, in exists
os.stat(path)
TypeError: stat: path should be string, bytes, os.PathLike or integer, not NoneType
如何解决呢？感谢回复

you have to run python file with --config value while running i.e in repo there are various config files in cofigs folder, pass it as an cofig argument while running main file like below
python main.py --config config_name.yaml

you have to run python file with --config value while running i.e in repo there are various config files in cofigs folder, pass it as an cofig argument while running main file like below python main.py --config config_name.yaml

I'd like to ask about how to download the ImageNet dataset. The ImageNet dataset I downloaded is causing errors when I run it. Is it possible for you to share with me a pre-downloaded ImageNet dataset? I would be very grateful. And the errors is "RuntimeError: The archive ILSVRC2012_devkit_t12.tar.gz is not present in the root directory or is corrupted. You need to download it externally and place it in DATA/imagenet/images."


Runtime parameter cpufreq change failure on Pixel 6 (root access, Android 13)

I've been trying to control the cpu frequency before each run without much success. I've mostly been using this CPUFreq explanation to set the frequencies for my agenda.
For the basic config I have enabled cpufreq like so
config:
   device_config:
      modules: ['cpufreq']

And I've tried the many different methods:
sections:
-   id: all_max
    runtime_parameters:
        cpu0_frequency: 1803000
        cpu1_frequency: 1803000
        cpu2_frequency: 1803000
        cpu3_frequency: 1803000
        cpu4_frequency: 2253000
        cpu5_frequency: 2253000
        cpu6_frequency: 2802000
        cpu7_frequency: 2802000

The method above says gets an error says ERROR    Cannot set "frequency" for core "1"; Parameter for CPU0 has already been set
Next I tried <core_name>_frequency: 180300 where core_names were a55, A55, and policy0, which have all failed saying Unknown runtime parameter: a55_frequency.
I also tried:
sections:
-   id: all_max
    runtime_parameters:
        sysfile_values:
            /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq: 300000
            /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq: 300000
            /sys/devices/system/cpu/cpufreq/policy4/scaling_min_freq: 400000
            /sys/devices/system/cpu/cpufreq/policy4/scaling_max_freq: 400000
            /sys/devices/system/cpu/cpufreq/policy6/scaling_min_freq: 500000
            /sys/devices/system/cpu/cpufreq/policy6/scaling_max_freq: 500000

Except the error message seems to imply that it successfully changed policy0 and 4, but failing at 6.
ERROR        Could not write "500000" to /sys/devices/system/cpu/cpufreq/policy6/scaling_max_freq:
INFO         Completing job all_max-wk1
ERROR    Job all_max-wk1 iteration 1 completed with status FAILED. retrying...
INFO     Running job all_max-wk1
INFO         Configuring augmentations
INFO         Configuring target for job all_max-wk1 (dhrystone) [1]
ERROR        Could not write "500000" to /sys/devices/system/cpu/cpufreq/policy6/scaling_max_freq:
INFO         Completing job all_max-wk1
ERROR    Job all_max-wk1 iteration 1 completed with status FAILED. Max retries exceeded.

Finally, I tried:
sections:
-   id: all_max
    runtime_parameters:
        sysfile_values:
            # A55
            /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq: 1803000
            /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: 1803000
            /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq: 1803000
            /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq: 1803000
            /sys/devices/system/cpu/cpu2/cpufreq/scaling_min_freq: 1803000
            /sys/devices/system/cpu/cpu2/cpufreq/scaling_max_freq: 1803000
            /sys/devices/system/cpu/cpu3/cpufreq/scaling_min_freq: 1803000
            /sys/devices/system/cpu/cpu3/cpufreq/scaling_max_freq: 1803000
            # A76
            /sys/devices/system/cpu/cpu4/cpufreq/scaling_min_freq: 2253000
            /sys/devices/system/cpu/cpu4/cpufreq/scaling_max_freq: 2253000
            /sys/devices/system/cpu/cpu5/cpufreq/scaling_min_freq: 2253000
            /sys/devices/system/cpu/cpu5/cpufreq/scaling_max_freq: 2253000
            # X1
            /sys/devices/system/cpu/cpu6/cpufreq/scaling_min_freq: 2802000
            /sys/devices/system/cpu/cpu6/cpufreq/scaling_max_freq: 2802000
            /sys/devices/system/cpu/cpu7/cpufreq/scaling_min_freq: 2802000
            /sys/devices/system/cpu/cpu7/cpufreq/scaling_max_freq: 2802000

Also getting an error message:
INFO         Configuring target for job all_max-wk1 (dhrystone) [1]
ERROR        Could not set the value of /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq to "1803000" (read "300000
ERROR        ")
INFO         Completing job all_max-wk1
ERROR    Job all_max-wk1 iteration 1 completed with status FAILED. retrying...
INFO     Running job all_max-wk1
INFO         Configuring augmentations
INFO         Configuring target for job all_max-wk1 (dhrystone) [1]
ERROR        Could not set the value of /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq to "1803000" (read "300000
ERROR        ")
INFO         Completing job all_max-wk1
ERROR    Job all_max-wk1 iteration 1 completed with status FAILED. retrying...
INFO     Running job all_max-wk1
INFO         Configuring augmentations
INFO         Configuring target for job all_max-wk1 (dhrystone) [1]
ERROR        Could not set the value of /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq to "1803000" (read "300000
ERROR        ")
INFO         Completing job all_max-wk1
ERROR    Job all_max-wk1 iteration 1 completed with status FAILED. Max retries exceeded.

I guess I just want to know how I can fix this issue, or would I have to change the values myself through adb shell outside of wa? Also the Pixel 6 doesn't have userspace governor, but the documentation says that it'll automatically attempt max/min so these are all that I've tried.

how I can fix this issue, or would I have to change the values myself through adb shell outside of wa?

This is absolutely something that WA should be able to handle. I have a few thoughts.

Finally, I tried: (sysfile_values)
ERROR        Could not set the value of /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq to "1803000" (read "300000

One thing to note when setting the sysfiles is that WA will try to set them in the exact order they are listed in the agenda as these are order specific. For example if the current values of min_freq and max_freq at set to 300000, and the first instruction is to set the minimum frequency to 1803000, this is larger than max_freq and the device will reject/ignore the request as it is invalid and I suspect could be the cause of your errors. This is something that using the runtime parameters methods should handle automatically.

Next I tried <core_name>_frequency: 180300 where core_names were a55, A55, and policy0, which have all failed saying Unknown runtime parameter: a55_frequency

This will happen if devlib/WA cannot automatically detect the core names (these are the ones that devlib currently knows about [1]). However, these can be specified manually so you could add something like the following line into your agenda.
device_config:
    core_names: ['A55', 'A55', 'A55', 'A55', 'A76', 'A76', 'X1', 'X1']

This should then allow you to use the format:
sections:
-   id: all_max
    runtime_parameters:
        a55_frequency: 1803000
        a76_frequency: 1803000
        x1_frequency: 1803000

Finally, for your original attempt
sections:
-   id: all_max
    runtime_parameters:
        cpu0_frequency: 1803000
        cpu1_frequency: 1803000
        cpu2_frequency: 1803000
        cpu3_frequency: 1803000
        cpu4_frequency: 2253000
        cpu5_frequency: 2253000
        cpu6_frequency: 2802000
        cpu7_frequency: 2802000

As part of setting the cpu frequencies WA will detect other cpus that are affected by a given parameter to prevent any conflicts. In this case the values are the same, so thinking about it it might make more sense to not to thrown an error here, however in this instance I suspect the error is being thrown because WA is receiving values for multiple (all) cpus that overlap with other cpus on the same frequency domain.
Could you try modifying this to only include unique domains? For example something like:
sections:
-   id: all_max
    runtime_parameters:
        cpu0_frequency: 1803000
        cpu4_frequency: 2253000
        cpu6_frequency: 2802000

Please let me know if any of above helps and if so, we can look into trying to make this a bit more user friendly to understand.
[1] https://github.com/ARM-software/devlib/blob/111aa327ce0e9555a5905bd16831a157a0e0cdf5/devlib/utils/misc.py#L65

Hmmm okay so I tried the method of only unique domains and manually including core_names. which definitely helped WA to avoid duplicate changes to domains and finding the correct cores. Now the only error is getting to the changes.
ERROR        Could not write "1803000" to /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:
INFO         Completing job all_max-wk1
ERROR    Job all_max-wk1 iteration 1 completed with status FAILED. retrying...
INFO     Running job all_max-wk1
INFO         Configuring augmentations
INFO         Configuring target for job all_max-wk1 (dhrystone) [1]
ERROR        Could not write "1803000" to /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:

It's able to find the correct files to write, but the above error still appears.
As for the sysfile_values method:
sections:
-   id: all_max
    runtime_parameters:
        sysfile_values:
            # A55
            /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: 1803000
            /sys/devices/system/cpu/cpu0/cpufreq/scaling_main_freq: 1803000
            # A76
            /sys/devices/system/cpu/cpu4/cpufreq/scaling_max_freq: 2253000
            /sys/devices/system/cpu/cpu4/cpufreq/scaling_min_freq: 2253000
            # X1
            /sys/devices/system/cpu/cpu6/cpufreq/scaling_max_freq: 2802000
            /sys/devices/system/cpu/cpu6/cpufreq/scaling_min_freq: 2802000

I only selected one from each domain, since I'm guessing the clusters will change together, but it still fails:
ERROR        Could not write "1803000" to /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:
INFO         Completing job all_max-wk1
ERROR    Job all_max-wk1 iteration 1 completed with status FAILED. retrying...
INFO     Running job all_max-wk1
INFO         Configuring augmentations
INFO         Configuring target for job all_max-wk1 (dhrystone) [1]
ERROR        Could not write "1803000" to /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:
INFO         Completing job all_max-wk1
ERROR    Job all_max-wk1 iteration 1 completed with status FAILED. retrying...
INFO     Running job all_max-wk1
INFO         Configuring augmentations
INFO         Configuring target for job all_max-wk1 (dhrystone) [1]
ERROR        Could not write "1803000" to /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:
INFO         Completing job all_max-wk1
ERROR    Job all_max-wk1 iteration 1 completed with status FAILED. Max retries exceeded

Hmm.. Just to ask the obvious questions...
If you cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies are the relevant cpu frequencies reported correctly for the specific cores?
Also are you able to set the values manually via ABD?

Well, after checking through all the permissions for each of the files, it turns out policy0/scaling_max_freq was set to read only.
Sorry for wasting your time with my mistake! Still glad to know how to label the core_names to properly use though. Thanks!


global search

fix conflicts

just came across an issue, if you search for a particular movie and scroll to the bottom of the site, the movie engine automatically try loading more movies which in turn result in an empty search data.
we will have to find better ways of displaying our search results, possibly a search page should work fine for us.

Okay

just came across an issue, if you search for a particular movie and scroll to the bottom of the site, the movie engine automatically try loading more movies which in turn result in an empty search data.
we will have to find better ways of displaying our search results, possibly a search page should work fine for us.

Actually there is one engine that actually has paginated results... and that is the series engine
The rest only return one page.... so when making the global search @SLKhadeeja , whenever someone scrolls to the bottom of the page, it should only try to search page 2, 3, 4,e.t.c of the series engine

Okay


Introduce SslContextOption which can be used for "optional" features …

…in SslContext implementations
Motivation:
Some of the features we want to support can only be supported by some of the SslContext implementations. We should allow to configure these in a consistent way the same way as we do it with Channel / ChannelOption
Modifications:

Add SslContextOption and add builder methods that take these
Add OpenSslContextOption and define two options there which are specific to openssl

Result:
More flexible configuration and implementation of SslContext

This fixes https://github.com/netty/netty/issues/10978

This fixes https://github.com/netty/netty/issues/10978


Avoid macro invocation in examples

Alpine defines macros 'major' & 'minor', so the functions modified are
parsed as macro invocations. The rename avoids this collision.

Sorry for the long delay on reviewing this PR.  We're going through the PR backlog now.

Yay! Thanks.


Configure additionalProperties validation strategy

Hi, I would like to provide stricter validation by forcing additionalProperties to false in all schemas without requiring its presence. My current project has a large specification (hundreds of endpoints and even more schemas) and I need to thoroughly validate API contract and gradually adjust OpenAPI specification.
I can submit a PR, can you advise on what would be a good approach here? I see that Properties class has $additionalProperties constructor parameter which is then used exactly the way I need when its false. From what I see Properties::validate() is called only once in SchemaValidator line 136 and the value comes directly from the schema. Unfortunately, BodyValidator and other validators are created as ValidatorChain directly in RequestValidator and ResponseValidator which rules out customization through injecting custom options. SchemaValidator is created directly in BodyValidator as well.
What would be a good way to inject custom behaviour into these classes?

Hey @thunderer!

I would like to provide stricter validation by forcing additionalProperties to false in all schemas without requiring its presence.

This is possible, but it is against OpenApi spec:

additionalProperties - Value can be boolean or object. Inline or referenced schema MUST be of a Schema Object and not a standard JSON Schema. Consistent with JSON Schema, additionalProperties defaults to true.

If I had to do that I would fork this repo and changed this file src/Schema/Keywords/Properties.php on line 91.

Hi @lezhnev74! Thanks for your awesome work that led to this library!
I am fully aware that this can be against the specification, that's why I'm asking for a configurable option that defaults to what's compliant. Sorry if that was not clear from my first post. I see three strategies that could be applied here:

respect specification value (default, compliant with OpenAPI),
apply additionalProperties only when not specified (stricter, IMO still "compliant" as it just changes default),
force additionalProperties everywhere (strictest, not compliant as it overrides explicit values).

Currently my code is roughly equivalent to:
$openapi = (new ValidatorBuilder())->fromJsonFile($path);
$openApiRequest = $openapi->getRequestValidator();
$openApiResponse = $openapi->getResponseValidator();
// later
$openApiRequest->validate($request);
$address = new OperationAddress($request->getPathInfo(), strtolower($request->getMethod()));
$openApiResponse->validate($address, $response);

I would like to be able to access the SchemaValidator in the ValidatorChain -> BodyValidator -> UnipartValidator chain and add the ability to configure its additionalProperties strategy. It could be done better (proper strategy implementations with interface), but just to illustrate a simplest approach:
$strategy = fn($value) => $value ?: null; // default compliant
$strategy = fn($value) => $value ?: false; // stricter
$strategy = fn() => false; // strictest

$openApiRequest->getBodyValidator()->replaceAdditionalPropertiesStrategy($strategy);
$openApiResponse->getBodyValidator()->replaceAdditionalPropertiesStrategy($strategy);

My first impression is you need some kind of pre-processor for you schema. You can build schema from file and then process it to configure all additionalProperties to be false if not set explicitly to match schmea you want to check instead of schema you have

@scaytrase I don't think such a tool exists, and building one from scratch is not feasible in my current situation. What do you think about the possible solutions I described above? I would be glad to discuss the preferred approach and provide a PR.

I think different interpretations of schema should be done by changing schema itself. If we step on the way of variating validation for custom rules interpretation or overrides then will be at some moment in a situation with a dozens of custom logic overrides in code.
I can imaging a lot of customization which could be useful on adoption stage, like make all fields non-required or normalize all object field names keeping originals, etc. Each of this, including your one, could be achieved by properly processing input schema and without touching the logic (multiplying the complexity).
I don't think building schema processor is too complicated to consume much time. In a nutshell it should be just a recursive tree traverse which apply modifications for each object param

@scaytrase @lezhnev74 This discussion seems to revolve more around our design principles than my initial issue, so let me rephrase the question a bit.
From what I see your goal is to make this library the reference implementation of OpenAPI standard. I support that goal, that's why all of us are here. My initial suggestion was to make certain internal behaviour configurable with compliant defaults, but I can understand if that's not what you want as maintainers.
There are other ways to achieve my goal that I think would benefit the library as well. As noted above, most of the dependencies are created directly rather than being injected. Making these dependencies explicit would benefit the overall design and allow users to provide their own instances without any effort from your side or need for support. Then I could replace only the parts I need on my side. We could, for example, inject the validators separately in the constructor, but since sometimes there are so many of them, we could also introduce a registry which other classes would receive in the constructor and fetch necessary instances. If you have better ideas, I'm all ears. What do you think?

...most of the dependencies are created directly rather than being injected. Making these dependencies explicit would benefit the overall design and allow users to provide their own instances without any effort from your side or need for support

In general, this makes sense and indeed makes the package much more extensible. Any part of it can be extended with custom logic, while we can provide a default implementation.

From what I see your goal is to make this library the reference implementation of OpenAPI standard

Yes, the goal of this library is to validate PSR-7 messages against OpenAPI specs. We do our best to support all OpenAPI current features (still not nearly there). This package's interfaces have limited external dependencies because all this library needs to achieve the above purpose can be inferred from OpenAPI specification. Customization is only supposed to be within the OpenAPI specification language.
We followed UNIX philosophy - one tool should do one job only, but do it well. If we need to provide some complex behaviour we combine tools, rather than making a single one. In your case, "preprocessing step | this tool" ;
I'd love to continue this conversation, so please feel free to provide references to a similar design so we can review and understand deeper your suggestions and how it benefits other packages in PHP ecosystem.

Making these dependencies explicit would benefit the overall design and allow users to provide their own instances without any effort from your side or need for support.

Yea, this is possible, but this requires pretty big refactoring to the way how the validators are being instantiated now. But since we have the factories for it this may be hidden for end user. This idea sounds better then implementing strategies in each place we want logic override, so I'll be glad to see your ideas in PR


Copy Resource Contact Information to Creator and Metadata Provider

Did we lose the ability to copy from the resource contact in the basic metadata section? It now seems like we can only copy from another existing resource?

I like this new functionality but I also used the "Copy from Resource Contact" functionality from before because frequently the Contact, Creator, and Metadata provider are all the same person and it's nice not to have to retype all that information 3 times.
Alternatively this suggestion would also resolve this issue.

Thank you for contacting us @albenson-usgs
It is possible to copy if you save the resource contact. Then it'll be available in the list. But it requires more actions from the user. Let's add a link to the modal window which will replicate previous functionality.
About that suggestion, I already mentioned somewhere that it doesn't really work with the current IPT and EML implementation. Those are different entities under the hood in the EML xml, so it would be a bit complicated to split it up/aggregate every time

Ok thanks!

There are issues with search

Fixed https://github.com/gbif/ipt/commit/c68134f5a76a40c0de37da7f367d0b42904f69d7

@albenson-usgs There will be a search option, I thought that would be enough?

Oh yes that seems like it would solve the problem. Thanks!

Hi Mike- I'm trying to use this functionality right now and I don't know how to accomplish "It is possible to copy if you save the resource contact." I have two completely new people (meaning they are not saved in any other resource) and I input their information into the Resource Contacts section and what I would like to be able to do is not have to write again all that information in the Resource Creator section. I don't see a way to "save the resource contact" because when I try to do that I get an error message that states "At least one creator is required". How do I save a resource contact that I need the information for in the resource creator and they are not part of any other resource?

Ah I see, I'm going to leave my comment but left to work on something else for a bit and when I came back to it the new resource- the contact information is saved and I can search for this new resource in the dialog box to select it for the creator. Thank you for all your hard work!

@albenson-usgs Thank you for suggesting improvements! I'm glad you sorted it out. Otherwise I'm here to help


Merge Develop into Django-OSF

@icereval Here's a PR that just merges develop into django-osf. Merge when you're happy with it. I'm going to work on a PR getting my doc changes on top of this.

Purpose

Changes

Side effects

Ticket

It was backwards...


feat(csharp/src/Drivers/Apache/Spark): Add support for username and password authentication

Adds support for username and password in the Spark ADBC driver
Validates that connection properties are correctly provided.
A follow up PR (for issue #2015) will add integration tests for connecting to a data source that supports username and password.
Closes #2013

Note: Just tried a negative test on an invalid password and the connection and tests still succeed. I don't have confirmation that this solution is working correctly. Marking it a Draft until I get correct test behavior on an invalid password.


Error handling

Currently there are a number of points where an error is caught through a try-except statement, and a custom error message is issued.  This needs to be rewritten following the discussion in #208.
Example:
try:
    code!
except AttributeError as err:
    raise AttributeError(' '.join((str(err), '\n', custom_error_message)))

Closing with merge of #228