GPU Resources arent made available after Updated to newest intel-basekitpackages

Describe the bug
After i updated the newest intel-basekit packages that are on debian (2025.0.1-45) its currently for me not possible to schedule pods to GPU's because  Allocate failed due to requested number of devices unavailable for gpu.intel.com/i915. Requested: 1, Available: 0, which is unexpected
System (please complete the following information):

OS version: Debian 12.8
Kernel version: Linux 6.8.12-5-pve # 1 SMP PREEMPT_DYNAMIC PMX 6.8.12-5 (2024-12-03T10:26Z) x86_64 GNU/Linux
Device plugins version: intel/intel-gpu-plugin:0.31.1
Hardware info:
CPU: Intel(R) Core(TM) i7-4790
GPU: Intel Arc A770

Additional context
The Node itself has in its status a Capacity and allocatable numbers for gpu.intel.com/i915 as i configured the sharedDevNum.
The intel-gpu-plugin Pod also sets them.
Here is a log ouput with Loglevel 5
I1223 03:27:06.949113       1 gpu_plugin.go:799] GPU device plugin started with none preferred allocation policy
I1223 03:27:06.949917       1 gpu_plugin_resource_manager.go:174] GPU device plugin resource manager enabled
I1223 03:27:06.950005       1 gpu_plugin_resource_manager.go:311] Requesting pods from kubelet (https://<IP_ADDRESS>:10250/pods)
W1223 03:27:06.959157       1 gpu_plugin_resource_manager.go:315] Failed to read pods from kubelet API: Get "https://<IP_ADDRESS>:10250/pods": tls: failed to verify certificate: x509: certificate signed by unknown authority
I1223 03:27:06.959191       1 gpu_plugin_resource_manager.go:180] Not using Kubelet API
I1223 03:27:06.959250       1 gpu_plugin.go:835] NFD feature file location: /etc/kubernetes/node-feature-discovery/features.d/intel-gpu-resources.txt
I1223 03:27:06.959282       1 gpu_plugin.go:518] GPU (i915/xe) resource share count = 120
I1223 03:27:06.959450       1 gpu_plugin.go:565] Not compatible device: card0-DP-1
I1223 03:27:06.959463       1 gpu_plugin.go:565] Not compatible device: card0-DP-2
I1223 03:27:06.959471       1 gpu_plugin.go:565] Not compatible device: card0-DP-3
I1223 03:27:06.959478       1 gpu_plugin.go:565] Not compatible device: card0-HDMI-A-2
I1223 03:27:06.959485       1 gpu_plugin.go:565] Not compatible device: card0-HDMI-A-3
I1223 03:27:06.959491       1 gpu_plugin.go:565] Not compatible device: card0-HDMI-A-4
I1223 03:27:06.959498       1 gpu_plugin.go:565] Not compatible device: card0-HDMI-A-5
I1223 03:27:06.959564       1 gpu_plugin.go:565] Not compatible device: card1-HDMI-A-1
I1223 03:27:06.959574       1 gpu_plugin.go:565] Not compatible device: card1-VGA-1
I1223 03:27:06.959579       1 gpu_plugin.go:565] Not compatible device: renderD128
I1223 03:27:06.959584       1 gpu_plugin.go:565] Not compatible device: renderD129
I1223 03:27:06.959583       1 labeler.go:480] Starting GPU labeler
I1223 03:27:06.959591       1 gpu_plugin.go:565] Not compatible device: version
I1223 03:27:06.959724       1 labeler.go:219] tile files found:[/sys/class/drm/card0/gt/gt0]
I1223 03:27:06.959792       1 gpu_plugin.go:636] Adding /dev/dri/card0 to GPU card0
I1223 03:27:06.959804       1 gpu_plugin.go:636] Adding /dev/dri/renderD129 to GPU card0
I1223 03:27:06.960346       1 gpu_plugin.go:726] For i915_monitoring/all, adding nodes: [{ContainerPath:/dev/dri/card0 HostPath:/dev/dri/card0 Permissions:rw XXX_NoUnkeyedLiteral:{} XXX_sizecache:0} {ContainerPath:/dev/dri/renderD129 HostPath:/dev/dri/renderD129 Permissions:rw XXX_NoUnkeyedLiteral:{} XXX_sizecache:0}]
I1223 03:27:06.960483       1 labeler.go:219] tile files found:[/sys/class/drm/card1/gt/gt0]
I1223 03:27:06.960532       1 gpu_plugin.go:636] Adding /dev/dri/card1 to GPU card1
I1223 03:27:06.960546       1 gpu_plugin.go:636] Adding /dev/dri/renderD128 to GPU card1
I1223 03:27:06.960977       1 gpu_plugin.go:726] For i915_monitoring/all, adding nodes: [{ContainerPath:/dev/dri/card1 HostPath:/dev/dri/card1 Permissions:rw XXX_NoUnkeyedLiteral:{} XXX_sizecache:0} {ContainerPath:/dev/dri/renderD128 HostPath:/dev/dri/renderD128 Permissions:rw XXX_NoUnkeyedLiteral:{} XXX_sizecache:0}]
I1223 03:27:07.047963       1 gpu_plugin.go:540] GPU scan update: 0->240 'i915' resources found
I1223 03:27:07.047976       1 gpu_plugin.go:540] GPU scan update: 0->1 'i915_monitoring' resources found
I1223 03:27:07.047993       1 labeler.go:495] Ext resources scanning
I1223 03:27:07.048130       1 labeler.go:122] Not compatible devicecard0-DP-1
I1223 03:27:07.048140       1 labeler.go:122] Not compatible devicecard0-DP-2
I1223 03:27:07.048146       1 labeler.go:122] Not compatible devicecard0-DP-3
I1223 03:27:07.048153       1 labeler.go:122] Not compatible devicecard0-HDMI-A-2
I1223 03:27:07.048159       1 labeler.go:122] Not compatible devicecard0-HDMI-A-3
I1223 03:27:07.048165       1 labeler.go:122] Not compatible devicecard0-HDMI-A-4
I1223 03:27:07.048171       1 labeler.go:122] Not compatible devicecard0-HDMI-A-5
I1223 03:27:07.048250       1 labeler.go:122] Not compatible devicecard1-HDMI-A-1
I1223 03:27:07.048259       1 labeler.go:122] Not compatible devicecard1-VGA-1
I1223 03:27:07.048264       1 labeler.go:122] Not compatible devicerenderD128
I1223 03:27:07.048270       1 labeler.go:122] Not compatible devicerenderD129
I1223 03:27:07.048276       1 labeler.go:122] Not compatible deviceversion
I1223 03:27:07.048442       1 labeler.go:219] tile files found:[/sys/class/drm/card0/gt/gt0]
W1223 03:27:07.048482       1 labeler.go:176] Can't read file: open /sys/class/drm/card0/lmem_total_bytes: no such file or directory
I1223 03:27:07.048693       1 labeler.go:219] tile files found:[/sys/class/drm/card1/gt/gt0]
W1223 03:27:07.048728       1 labeler.go:176] Can't read file: open /sys/class/drm/card1/lmem_total_bytes: no such file or directory
I1223 03:27:07.048797       1 labeler.go:505] Writing labels
I1223 03:27:07.048013       1 manager.go:115] Received dev updates:{map[i ..  (shortened due to maximum charactrs) ... ]}
I1223 03:27:08.148626       1 server.go:285] Start server for i915 at: /var/lib/kubelet/device-plugins/gpu.intel.com-i915.sock
I1223 03:27:08.148633       1 server.go:285] Start server for i915_monitoring at: /var/lib/kubelet/device-plugins/gpu.intel.com-i915_monitoring.sock
I1223 03:27:08.159803       1 server.go:128] Started ListAndWatch fori915
I1223 03:27:08.159822       1 server.go:117] Sending to kubelet[]
I1223 03:27:08.159909       1 server.go:303] Device plugin for i915 registered
I1223 03:27:08.160059       1 server.go:117] Sending to kubelet[&Device{ID:card1-33,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-46,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-62,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-72,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-51,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-116,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-41,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-63,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-115,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-61,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-31,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-75,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-33,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-39,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-73,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-108,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-5,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-77,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-101,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-19,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-29,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-22,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-71,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-106,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-6,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-40,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-62,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-80,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-83,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-17,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-96,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-110,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-30,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-111,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-113,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-14,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-59,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-78,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-95,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-44,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-109,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-3,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-100,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-81,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-26,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-68,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-119,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-10,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-24,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-42,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-105,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-46,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-53,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-117,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-10,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-51,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-114,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-30,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-54,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-111,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-49,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-72,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-49,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-119,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-98,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-2,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-4,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-13,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-99,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-84,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-89,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-91,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-16,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-84,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-89,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-45,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-64,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-27,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-96,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-117,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-17,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-94,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-103,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-95,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-45,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-54,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-55,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-70,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-43,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-58,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-78,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-91,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-32,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-57,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-61,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-74,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-109,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-7,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-22,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-56,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-43,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-56,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-25,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-19,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-21,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-40,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-35,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-93,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-0,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-69,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-38,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-71,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-79,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-85,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-15,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-87,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-101,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-23,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-47,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-53,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-65,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-118,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-12,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-31,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-76,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-98,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-65,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-42,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-50,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-20,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-67,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-108,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-118,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-8,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-81,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-9,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-0,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-74,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-93,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-8,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-59,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-63,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-82,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-104,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-14,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-24,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-48,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-67,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-64,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-90,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-102,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-104,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-6,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-50,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-102,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-1,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-38,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-94,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-52,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-37,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-86,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-7,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-69,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-87,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-66,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-75,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-107,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-83,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-28,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-36,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-11,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-57,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-82,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-58,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-60,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-100,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-32,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-86,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-88,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-79,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-26,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-44,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-52,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-97,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-97,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-1,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-16,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-80,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-73,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-9,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-23,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-55,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-116,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-34,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-112,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-92,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-68,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-48,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-66,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-70,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-13,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-47,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-18,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-112,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-12,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-37,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-115,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-18,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-34,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-5,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-90,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-4,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-21,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-113,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-103,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-85,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-2,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-36,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-29,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-35,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-76,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-105,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-107,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-41,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-106,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-15,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-28,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-20,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-114,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-25,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-60,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-110,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-77,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-88,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-3,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-11,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card1-39,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-27,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-92,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},} &Device{ID:card0-99,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},}]
I1223 03:27:08.248821       1 server.go:303] Device plugin for i915_monitoring registered
I1223 03:27:08.248987       1 server.go:128] Started ListAndWatch fori915_monitoring
I1223 03:27:08.248997       1 server.go:117] Sending to kubelet[]
I1223 03:27:08.249032       1 server.go:117] Sending to kubelet[&Device{ID:all,Health:Healthy,Topology:&TopologyInfo{Nodes:[]*NUMANode{},},}]
I1223 03:27:11.949496       1 gpu_plugin.go:565] Not compatible device: card0-DP-1

Hi @Serverfrog and thanks for a detailed issue report! Logs seem to indicate plugin working correctly with no errors that would cause things to fail.
Installing user space libraries to host shouldn't cause things to fail in containers. Unless intel-basekit also installs some misbehaving kernel drivers. But in your case the plugin detects the GPUs correctly.
I assume things were working before you upgraded the packages? I would also make sure the Pod doesn't set nodeSelector etc. and force the Pod to a node without the resources.
@eero-t any ideas?
fyi, unless you also run GAS (GPU Aware Scheduling) in your cluster, there's not much benefit on enabling resource manager in GPU plugin.

@Serverfrog Could you paste here:

pod spec, at least following sections: nodename/nodeSelector, securityContext (both for pod & container), resources?
node k8s GPU info: kubectl describe node YOUR_NODE_NAME | grep gpu
node GPU files info: ls -l /dev/dri/ && head /sys/class/drm/card[0-9]/device/uevent

(Most people are on holidays this week, so definitive answer may go to next week.)

@tkatila GAS was enabled as a test from me, after it was already not working, that it maybe that. For example it worked shortly for one pod with using i915_monitoring, but only till that one pod was killed/node restartet.
@eero-t Sure! I'm thinking you mean the pod('s) that wont get the CPU Right?

...
  nodeName: proxfrog2
  securityContext: {}
  containers:
    - name: app
    ...
      resources:
        limits:
          gpu.intel.com/i915: '1'
          gpu.intel.com/millicores: '10'
          memory: 1536Mi
        requests:
          cpu: 100m
          gpu.intel.com/i915: '1'
          gpu.intel.com/millicores: '10'
          memory: 512Mi
      securityContext:
        privileged: true

privileged: true was added afterwards to test if it could maybe that, but that also didn't worked
❯ kubectl describe node proxfrog2 | grep gpu
                    gas-prefer-gpu=card0
                    gpu.intel.com/device-id.0300-0412.count=2
                    gpu.intel.com/device-id.0300-0412.present=true
                    gpu.intel.com/device-id.0300-56a0.present=true
                    gpu.intel.com/family=A_Series
                    intel.feature.node.kubernetes.io/gpu=true
                    nfd.node.kubernetes.io/extended-resources: gpu.intel.com/memory.max,gpu.intel.com/millicores,gpu.intel.com/tiles
                      gpu.intel.com/device-id.0300-0412.count,gpu.intel.com/device-id.0300-0412.present,gpu.intel.com/device-id.0300-56a0.present,gpu.intel.com/...
  gpu.intel.com/i915:             240
  gpu.intel.com/i915_monitoring:  1
  gpu.intel.com/memory.max:       0
  gpu.intel.com/millicores:       2k
  gpu.intel.com/tiles:            2
  gpu.intel.com/i915:             240
  gpu.intel.com/i915_monitoring:  1
  gpu.intel.com/memory.max:       0
  gpu.intel.com/millicores:       2k
  gpu.intel.com/tiles:            2
  kube-system                 intel-gpu-exporter-wwf72                                  100m (1%)     0 (0%)      100Mi (0%)       500Mi (1%)     6h31m
  kube-system                 intel-gpu-plugin-intel-gpu-plugin-wmkkd                   40m (0%)      100m (1%)   45Mi (0%)        90Mi (0%)      6h34m
  gpu.intel.com/i915             3                 3
  gpu.intel.com/i915_monitoring  1                 1
  gpu.intel.com/memory.max       0                 0
  gpu.intel.com/millicores       40                40
  gpu.intel.com/tiles            0                 0

 ⚡ root@proxfrog2  ~  ls -l /dev/dri/ && head /sys/class/drm/card[0-9]/device/uevent
total 0
drwxr-xr-x 2 root root        120 Dec 22 17:34 by-path
crw-rw---- 1 root video  226,   0 Dec 22 17:34 card0
crw-rw---- 1 root video  226,   1 Dec 22 17:34 card1
crw-rw---- 1 root render 226, 128 Dec 22 17:34 renderD128
crw-rw---- 1 root render 226, 129 Dec 22 17:34 renderD129
==> /sys/class/drm/card0/device/uevent <==
DRIVER=i915
PCI_CLASS=30000
PCI_ID=8086:56A0
PCI_SUBSYS_ID=172F:3937
PCI_SLOT_NAME=0000:03:00.0
MODALIAS=pci:v00008086d000056A0sv0000172Fsd00003937bc03sc00i00

==> /sys/class/drm/card1/device/uevent <==
DRIVER=i915
PCI_CLASS=30000
PCI_ID=8086:0412
PCI_SUBSYS_ID=1043:8534
PCI_SLOT_NAME=0000:00:02.0
MODALIAS=pci:v00008086d00000412sv00001043sd00008534bc03sc00i00

@tkatila GAS was enabled as a test from me, after it was already not working, that it maybe that. For example it worked shortly for one pod with using i915_monitoring, but only till that one pod was killed/node restartet.

Monitoring resource bypasses other GPU related constraints.  It's intended for monitoring all GPUs, not for using them.

privileged: true was added afterwards to test if it could maybe that, but that also didn't worked

The whole point of device plugins is NOT needing this (as it basically breaks security and is therefore disallowed in many clusters).    It has impact only when container is successfully scheduled and actually running on the node, i.e. not related to this.

                gpu.intel.com/device-id.0300-0412.count=2
                gpu.intel.com/device-id.0300-0412.present=true
                gpu.intel.com/device-id.0300-56a0.present=true

Note: neither GAS nor GPU plugin supports heterogeneous GPU nodes [1], ones where are multiple types of GPUs, that's why GPU labeler has labeled the node as having 2x Haswell iGPUs, although it has iGPU & dGPU.
That does not explain this problem, but it would be better to disable iGPU to avoid jobs intended for dGPU ending on the slow iGPU, that lacks lot of dGPU features.
[1] Intel DRA GPU driver supports such configs, and does not need GAS, but you would need k8s v1.32 to use it, and it's resource requests are a bit more complex to use: https://github.com/intel/intel-resource-drivers-for-kubernetes/

gpu.intel.com/i915:             240
gpu.intel.com/i915_monitoring:  1
gpu.intel.com/memory.max:       0
gpu.intel.com/millicores:       2k
gpu.intel.com/tiles:            2
gpu.intel.com/i915:             240
gpu.intel.com/i915_monitoring:  1
gpu.intel.com/memory.max:       0
gpu.intel.com/millicores:       2k
gpu.intel.com/tiles:            2

Ok, there should be enough GPU & millicore resources available, you're not requesting GPU memory, so it should be fine...
I guess that node is not e.g. tainted?

kube-system                 intel-gpu-exporter-wwf72                                  100m (1%)     0 (0%)      100Mi (0%)       500Mi (1%)     6h31m

Tuomas, what's this?
@Serverfrog does GPU scheduling work if you:

drop GAS and disable resource management support from plugin, and/or
disable the iGPU
?

Weird.. everything seems fine from resource point of view.
Can you drop GAS so that it doesn't interfere with the scheduling decisions? Make sure to remove the scheduler config part in /etc/kubernetes/manifests/kube-scheduler.yaml. Before removing GAS, you could check if there's anything funny in GAS' logs.

kube-system                 intel-gpu-exporter-wwf72                                  100m (1%)     0 (0%)      100Mi (0%)       500Mi (1%)     6h31m

Tuomas, what's this?

Probably this: https://github.com/onedr0p/intel-gpu-exporter

Monitoring resource bypasses other GPU related constraints. It's intended for monitoring all GPUs, not for using them.

kube-system intel-gpu-exporter-wwf72 100m (1%) 0 (0%) 100Mi (0%) 500Mi (1%) 6h31m
Tuomas, what's this?
Probably this: https://github.com/onedr0p/intel-gpu-exporter

Exactly, and thats why i changed exactly that pod (it wasn't working before i tried i951_monitoring) with the Monitoring resource.

privileged: true was added afterwards to test if it could maybe that, but that also didn't worked

The whole point of device plugins is NOT needing this (as it basically breaks security and is therefore disallowed in many clusters). It has impact only when container is successfully scheduled and actually running on the node, i.e. not related to this.

Yhea, i know. But i wanted to try if maybe with this i kinda workaroundish get it to work
I just Disabled the iGPU (i hate old BIOS, as you can only set the "Primary GPU", not "Disable iGPU"... if there is a primary, there can also be a secondary, and if my dGPU is the Primary, then i would think the iGPU would not be disabled but the secondary one...)
I also Removed the Lables and Annotations related to GAS, the resourceManager part and every millicores. Also removed the privileged as this tests did not worked.
It seems that disabling the iGPU kinda worked. I mean it makes sense, specially if it says that there are 2x the Haswell iGPU, which is blantly wrong. Which also explained why, in privileged mode where always on the iGPU (but it could also be that i could not configured ffmpeg through that interface correctly to use card0 instead card1... why ever it should use card1 over card0)
But the i915_monitoring still throws the same error, i think i will revert it back to the normal one, but still, later i kinda wanted to use the xpumanager to export that way the stats. But i as far is read up, there i should/could use the i915_monitoring Resource

As the GPU plugin officially only supports one type of GPU per node, the labeling rules do not work with multiple types of GPUs. For example in the count label:

gpu.intel.com/device-id.0300-0412.count=2

The 0300-0412 part is taken from the first (I think) PCI device it processes. The rules do not create multiple entries as it would multiply the number of rules needed (or a custom labeling binary). So even though the labels indicate that there were two 0412 devices, it's actually the 0412 + 56a0. The label name itself is just wrong.
@Serverfrog to summarize, your workload now works with the i915 resource, but the a pod requesting 915_monitor fails?

Which also explained why, in privileged mode where always on the iGPU (but it could also be that i could not configured ffmpeg through that interface correctly to use card0 instead card1... why ever it should use card1 over card0)

Legacy media APIs are kind of stupid compared to compute & 3D APIs, see: https://github.com/intel/intel-device-plugins-for-kubernetes/blob/main/cmd/gpu_plugin/README.md#issues-with-media-workloads-on-multi-gpu-setups

But the i915_monitoring still throws the same error, i think i will revert it back to the normal one, but still, later i kinda wanted to use the xpumanager to export that way the stats. But i as far is read up, there i should/could use the i915_monitoring Resource

There's only single monitoring resource per node.  Make sure that no other pod is already consuming it.

Edit: i think it was most likely the iGPU, as this was card0 and renderD128 before the reboot and the card0 and renderD128, which most likely confused things up

GPU plugin is not confused by that, it matches card & renderD nodes correctly (based on info from sysfs).
However, your media application can be confused.  See above link for a workaround.


getting a flash error

I am testing the esp-idf to run the Blink code on a Sparkfun esp32 thing board, but I am unable to flash the board. I am on Windows 7 enterprise and followed the Windows installation of the IDF. make menuconfig and make app work but fails to flash. I have also tried pressing both rst and gpio0 buttons in various combinations. The mingw32 output is below.
HIDA-4069519+student@HIDA-4069519 MINGW32 ~/esp-idf/blink
$ make flash
/bin/sh: -c: line 0: syntax error near unexpected token (' /bin/sh: -c: line 0: echo "Flashing binaries to serial port "USB Serial Port(COM21)" (app at offset 0x10000)..."'
make: *** [/home/student/esp-idf/components/esptool_py/Makefile.projbuild:54: flash] Error 1

Just an update. Hopefully this will help other folks. Just selecting the correct port in menuconfig  does not seem to work. make flash ESPPORT=COM21 and then pressing GPIO0 button when it shows connecting..... works for flashing.
While writing this update I was testing another one of the examples and I am suspecting the problem may have been the way the serial port was entered in the menuconfig. In device manager in windows the port is listed as USB Serial Port(COM21), so that was how I entered it. I believe mingw32 does not like spaces and that may have been the issue. Perhaps another developer can confirm.

Just COM21


Flutter style guide conflicst with Dart Style guide.

The Flutter style and the Dart style guide appear to conflict on some cases, like:
Flutter:
// GOOD:
if (notReady)
  return;

Dart:
// BAD
if (overflowChars != other.overflowChars)
  return overflowChars < other.overflowChars;

Maybe the Flutter style guide should mention this at the introduction?
I am probably being pedantic, but beginners might find this conflicting and get confused on what to follow.

There was some discussion about this in https://github.com/flutter/flutter/issues/31448.
This is a request for doc clarification though, not a style change.
@Hixie

I think there other stances where the two style guides differ, so it would be nice to discuss it in general.

updated https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#overview


XmlPullParser error when packaging project to .jar

I am trying to package my project to .jar file using JarSplice, however, when I try to run the generated .jar file, I get the following error:

Obviously, the file in Manifest/services does not exist after packaging, but how do I go about this?

This doesn't appear to be a Nifty issue. Would you agree @mkaring ?


feat(@ngtools/webpack): add support for multiple entry modules

When the webpack config is building two different apps from two
entry points, one of the apps will not work because metadatas are not
generated. The commit add a new property (entryModules) in
AngularCompilerPluginOptions that permit to regsiter multiple entry
modules.
Fix #861

npm run test-large failed for unknown reason. Can a maintainer help sorting this out ?

npm run test-large failed for unknown reason. Can a maintainer help sorting this out ?

Please see my response on https://github.com/angular/devkit/issues/861#issuecomment-391797538 as to why we do not want to add this right now.


PDF only shows the first page

I wanted to enable PDF by adding import { NotionRenderer, Equation, Pdf, Code, Collection, CollectionRow } from 'react-notion-x' and  pdf: Pdf,. It seems that it works. But it only shows the first page while the PDF has 31 pages! What's wrong with it?

the original notion page

Hey @yanyanlongxia, thanks for the bug report.
I just fixed this in react-notion-x. You can use 34d650c65da34f888335dbd3ddd141dc as a test page or use your own test page.
Just upgrade react-notion-x and you should be all set.

Thank you, it works now.


fixed minor typos

Hi @BethanyL ! Thank you for the commits, I am waiting before merging the pull request because this repo is currently a mirror repo of a gitlab repo... So I am thinking about how to configure these things...


Support material for Hangul filler

This piece is a feedback for Hangul filler section. This was originally posted at Reddit but I guess you can alter the wording to incoporate the following:

U+3164 HANGUL FILLER is one of the stupidest choices made by character sets. Hangul is noted for its algorithmic construction and Hangul charsets should ideally be following that. Unfortunately, the predominant method for multibyte encoding was ISO 2022 and EUC and both required a rather small repetoire of 94 × 94 = 8,836 characters [1] which are much less than required 19 × 21 × 28 = 11,172 modern syllables.
The initial KS X 1001 charset, therefore, only contained 2,350 frequent syllables (plus 4,888 Chinese characters with some duplicates, themselves becoming another Unicode headache). Notwithstanding the fact that remaining syllables are NOT supported, this resulted in a significant complexity burden for every Hangul-supporting software and there were confusion and contention between KS X 1001 and less interoperable "compositional" (johab) encodings before Unicode. The standardization committee has later acknowledged the charset's shortcoming, but only by adding four-letter (thus eight-byte) ad-hoc combinations for all remaining syllables! The Hangul filler is a designator for such combinations, e.g. <fliler>ㄱㅏ<filler> denotes 가 and <filler>ㅂㅞㄺ denotes 뷁 (not in KS X 1001 per se).
Hangul filler was too late in the scene that it had virtually no support from software industry. Sadly, the filler was there and Unicode had to accept it; technically it can be used to designate a letter (even though Unicode does not support the combinations) so the filler itself should be considered as a letter as well. What, the, hell.
[1] It is technically possible to use 94 × 94 × 94 = 830,584 characters with three-byte encoding, but as far as I know there is no known example of such charset designed (thus no real support too).

(Feel free to ask me about Hangul and more generally CJK support in Unicode.)

This was really insightful! Thanks so much.  I left CJK out because I personally have zero understanding of anything CJK- despite reading the reports, CodePoints.net, and Wikipedia.
Awesome-Unicode deserves a dedicated section on CJK in addition to an explanation about why the Hangul Filler is a thing ( which you've done quite well).
Would be able to contribute a section in CJK?

@jagracey I think I'm a terrible writer :P (even in my native tongue). I can list some interesting bits about CJK and Unicode, however:

Han unification, a large-scale merger of historically equivalent variants of Chinese characters. The problem was that the historical equivalence does not mean the actual equivalence; some names are, for example, always written in a particular variant. I think (hasn't verified so far) this has something to do with the limited size of BMP (they are among the first characters ever encoded in Unicode, when it was still confined to 16 bits). Of course there are tons of exemptions, mainly because many such characters were not unified in the source charsets, and also subsequent un-unifications as well. It is believed that variation selectors and the Ideographic Variation Database will finally solve this long-standing problem, though the implementation (both fonts and softwares) is not yet widespread enough.

Hangul filler being an invisible "ordinary" letter, explained above.

Duplicate Chinese characters.

Chinese characters of unknown origin. Most significantly, those from JIS X 0208. One of them (彁) is doubly unknown that how it got scrambled is also unknown.

Compatibility symbols. Very, very, very useful for optimizing tweets because CJK charsets traditionally had lots of "squared" letters (e.g. U+3392 encodes "MHz" in one character). Obviously there are also mistakes; Ken Lunde has described one particular example where the squared unit or abbreviation symbol does not correspond to anything in use due to a typo.

Normalization fail. Hangul syllables have two canonical forms in Unicode, one composed (e.g. U+AC00 가) and one decomposed (e.g. U+1100 ㄱ + U+1161 ㅏ). They are equivalent to each other after the normalization, but there is a significant error in the algorithm that the ancient Hangul syllable with no single combined letter is partially composed (e.g. U+1103 U+1172 U+11F0 듀ᇰ is ancient due to the final component, and the first two components are combined into U+B4C0 듀 resulting in two letters). As the Unicode algorithm cannot be corrected now, the result is a separate Hangul-friendly normalization algorithm (KS X 1026-1) for the domestic use.

"Korean mess" (yes, it has its own term): Hangul is the only script in the entire Unicode history that has been moved. Hangul was not compositionally encoded before Unicode 2.0, and was located at U+3400..4DFF. As it became increasingly clear that the entirety of modern Hangul will be eventually encoded, in no particular order, there has been lengthy discussions and eventually Hangul get relocated to U+AC00..D7FF, this time with the algorithmic mapping. This is also why the primary CJK ideograph block starts at U+4E00, right after the original Hangul blocks. (The historical note. According to multiple accounts the entire process was almost the split vote and confusing enough.)

We are missing Vietnam from the name "CJK (unified) ideograph", even though Vietnam had used Chinese characters in the past. Yes, we cannot change that now.

Did you know that a Chinese character encoding GB 18030 is actually a pan-Unicode encoding similar to UTF-8? (Designed to be compatible to the legacy encoding GBK, of course.)

And of course, Emoji is of the Japanese origin. It is all fault of three Japanese carriers---blame them.

Probably more, but I cannot recall others right now.

@lifthrasiir so, how many methods available are there to type hangul? I only know two: precomposed syllables vs jamos.

@nexusanphans You cannot directly write precomposed syllables (there are 11,172 modern ones), there should be multiple keystrokes to complete one syllable. Hangul is simple enough to not require a dictionary-based complex IME necessary for Japanese or Chinese, but is complex enough to allow many clever ideas to optimize for. I'm aware of at least 30+, and most popular ones include:

A bipartite (두벌식) method, standardized as KS X 5002, has two sets of jamos (consonants and vowels) and compose a syllable as much as possible (e.g. "ㄷㅜㅂㅓㄹㅅㅣㄱ" -> "ㄷㅜ/ㅂㅓㄹ/ㅅㅣㄱ" -> "두벌식"). It is possible that a consonant is temporarily placed in a wrong syllable (so-called jack-o'-lantern symptom [도깨비불 현상]). A variant of this keyboard to reduce the number of required keys is also in use in mobile phones.
Tripartite methods have three sets of jamos (initial, medial and final) and guarantee a syllable is completed as the final jamo is typed. It is slightly more complex because you now need to assign about 50% more keys, but can be alleviated by moving infrequent jamos to inconvenient places (the first row, or require shifting). There are multiple incarnations of tripartite methods, and essentially all modern OS supports 3-91 (also called tripartite final "세벌식 최종") and 3-90 by default.
There are multiple competing mobile keyboards originated from the 3 by 4 keypad layout. Most make use of the fact that Hangul jamos were designed in a group (ㄱ -> ㅋ, ㄴ -> ㄷ -> ㅌ or ㄹ, etc.). Among them Cheonjiin (천지인) and Naratgeul (나랏글) were ad hoc standardized by requiring a mandatory cross-licensing in 2000s.

@lifthrasiir Thank you for your detailed answer, although what I meant to inquire was  low-level (i.e. at the level of Unicode codepoints) method, for which I only know two: precomposed syllables vs jamos (initial, medial, and final). The former uses the Hangul Syllables block (AC00–D7A3), while the latter uses Hangul Jamo block along with two extended blocks. Precomposed syllables encode the whole syllables, while jamos are analogous to Latin letters, but with separate initial vs final version to allow precise syllable breaking.
There is another block, however, that of Hangul Compatibility Jamo (3130–318F). Looking at this Wikipedia page, it seems to be used only for compatibility purpose with another, older encoding system (Unicode is too concerned with backward compatibility, IMO). It is supposed to behave like jamos but with no separation of initial vs final consonants, which may complicate things since such arrangement can form ambiguous syllables.

Looking at this Wikipedia page, it seems to be used only for compatibility purpose with another, older encoding system (Unicode is too concerned with backward compatibility, IMO).

That was an intention, but practically compatibility jamos are used everywhere. In the other words, modern Korean IMEs do operate at the combining jamo level before the commit, but the candidate text is materialized as compatibility jamos when they can't combine with each other.
The motivating example would be a Korean equivalent to "lol" and "*sob*": "ㅋㅋㅋㅋㅋㅋㅋㅋㅋ" and "ㅠㅠ". They are not intended to compose, so "ㅋㅋㅋㅋ" followed by "ㅠㅠ", once written, should not compose into "ㅋㅋㅋ큐ㅠ" like combining jamos. You can often see that composed form though because people often don't signal that fact (by explicitly committing the text) to the IME.


Upgrade to JsonPath 2.7.0

By default, when a JSON path doesn't match a document, the JSONPath library throws an exception, but this can be disabled with configuration. These exceptions can be quite costly during ingestion and are worth avoiding:

The JsonScalarExtractTransformFunction already uses this configuration.

It turns out there's a bug in the library which prevents this configuration from being respected in all cases, which I have fixed in a PR to the library. Converting to draft until it's been released.

Codecov Report

Merging #7819 (d9368d0) into master (cce4932) will decrease coverage by 57.17%.
The diff coverage is 0.00%.

:exclamation: Current head d9368d0 differs from pull request most recent head eae796c. Consider uploading reports for the commit eae796c to get more accurate results

@@              Coverage Diff              @@
##             master    #7819       +/-   ##
=============================================
- Coverage     71.73%   14.55%   -57.18%
+ Complexity     4087       80     -4007
=============================================
  Files          1579     1534       -45
  Lines         80788    78923     -1865
  Branches      12002    11803      -199
=============================================
- Hits          57953    11488    -46465
- Misses        18954    66593    +47639
+ Partials       3881      842     -3039

Flag
Coverage Δ

integration1
?

integration2
?

unittests1
?

unittests2
14.55% <0.00%> (-0.03%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cce4932...eae796c. Read the comment docs.

Thanks for contributing the fix to the json-path library!
In JsonFunctions.java I can still see some method throwing JsonProcessingException. Should it be eliminated completely?

No, the values may not be valid json, or it may not be possible to stringify. The exceptions not thrown now were thrown  because a jsonpath didn’t match the document.


Make fillchars a local setting

Is your feature request related something that is currently hard to do? Please describe.
It would be great to make fillchars a window-local setting to make it possible for plugins like https://github.com/liuchengxu/vista.vim to declare custom folding style via fold.
Describe the solution you'd like
Ability to call setlocal fillchars=... (similar to neovim solution).
Describe alternatives you've considered
Additional window-local variables for each setting (stl, stnc, vert, fold and diff).

I wonder if it makes sense to have 'fillchars' option being local to a window. That might cause inconsistencies in the display of several window (borders and such) and actually I would even say, a plugin shouldn't mess with my local configured fillchars setting. Either it sets it globally (and then affects all windows) or it just shouldn't modify it at all.

This is already mentioned in the todo list, but with some question marks:
Should make 'listchars' global-local.  Local to window or to buffer?
Probably window.
Add something like 'fillchars' local to window, but allow for specifying a
highlight name.  Esp. for the statusline.
And "extends" and "precedes" are also useful without 'list' set.  Also in
'fillchars' or another option?

I am not so sure, it is a good idea to make the whole fillchars setting local to window. For one, which windows vert suboption of the fillchar setting will then be used for drawing windows? fold, stl and diff might make sense, not sure (thought it might cause inconsistent display of folds and diff lines), stlnc probably doesn't (again it is not easily possible to guess, for which windows this would be in effect, since other windows could have their own stl suboptions.
For listchars, extends, precedes makes sense yes.

This todo item is no longer relevant:

Should make 'listchars' global-local.  Local to window or to buffer?
Probably window.  #5206

The topic is about "Make fillchars a local setting" but the closing commit makes 'listchars' global-local...

On 2021-03-04, Maxim Kim wrote:

The topic is about "Make fillchars a local setting" but the
closing commit makes 'listchars' global-local...

That's correct.  The subject was meant to imply--in few words--that
the setting should be made local in addition to it already being
global.  Are you suggesting that 'listchars' be only local, or did
you just misunderstand the subject?
Regards,
Gary

Are you suggesting that 'listchars' be only local, or did you just misunderstand the subject?

I mean listchars are not fillchars.

On 2021-03-04, Maxim Kim wrote:

Are you suggesting that 'listchars' be only local, or did you just
misunderstand the subject?

I mean listchars are not fillchars.

Oops.  I must read more carefully.
Regards,
Gary


fix fix that delete bitmap calculation error when clone tablet

Proposed changes
Issue Number: close #xxx
Problem summary
F0516 14:24:15.818387 1727197 compaction.cpp:528] Check failed: false cumulative compaction: the merged rows(1826) is not equal to missed rows(0) in rowid conversion, tablet_id: 1766259, table_id:1766015
*** Check failure stack trace: ***
    @     0x5651b82e6f0d  google::LogMessage::Fail()
    @     0x5651b82e9449  google::LogMessage::SendToLog()
    @     0x5651b82e6a76  google::LogMessage::Flush()
    @     0x5651b82e9ab9  google::LogMessageFatal::~LogMessageFatal()
    @     0x5651993b14e2  doris::Compaction::modify_rowsets()
    @     0x5651993aa2d8  doris::Compaction::do_compaction_impl()
    @     0x5651993a4ed9  doris::Compaction::do_compaction()
    @     0x56519aa0bd7b  doris::CumulativeCompaction::execute_compact_impl()
    @     0x5651993a44eb  doris::Compaction::execute_compact()
    @     0x56519aacd46b  doris::Tablet::execute_compaction()
    @     0x565199289cd6  doris::StorageEngine::_submit_compaction_task()::$_0::operator()()

The rowset_ids_to_add parameter passed in to the calc_delete_bitmap function is null, resulting in the delete bitmap of previous rowset not being calculated.
This problem was introduced by: #17542
Checklist(Required)

[ ] Does it affect the original behavior
[ ] Has unit tests been added
[ ] Has document been added or modified
[ ] Does it need to update dependencies
[ ] Is this PR support rollback (If NO, please explain WHY)

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

run buildall

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 34.15 seconds
stream load tsv:          433 seconds loaded<PHONE_NUMBER>9 Bytes, about 164 MB/s
stream load json:         26 seconds loaded<PHONE_NUMBER> Bytes, about 86 MB/s
stream load orc:          61 seconds loaded<PHONE_NUMBER> Bytes, about 17 MB/s
stream load parquet:          30 seconds loaded 861443392 Bytes, about 27 MB/s
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20230516134250_clickbench_pr_144730.html

run buildall


docs: methodology

Great stuff! I'm considering to reuse your data via some API for my dashboard Pandemic Estimator but I wish it had a better documentation on methodology. I'm using JHU directly and I know what chaos it is, the most blatant example being that they provide "cumulative data" that's not cumulative quite often in practice. And the whole change of file formats, etc.
Can you please describe methodology how you deal with it? How do you deal with inconsistencies between data sources? What has been omitted, what has been "adjusted" and how? Thank you!

Oh yeah, so you can check our report.json to see which data was been omitted.
ABSOLUTELY NOTHING has been adjusted. We're not in the business of forecasting or fudging. We pass along what our sources report, and we cite our sources. Corrections and adjustments are outside the scope of our project.

I think that answer would be best served by being somewhere visible on website, e.g. https://coronadatascraper.com/#sources
On the other side I've seen firsthand many problems with JHU source but not in your data, therefore this reply doesn't really answer my curiosity of what happened to those problems.

Hi @Akuukis, I'm getting into some documentation soon.  Can you give an example where JHU has a data issue, but this project doesn't?  Regards, jz

@jzohrab Hi! It has been a while, but here's what I remember:
Example No.1 is France. It was "France, " at the start, then it bacame "France, France" with other "France, " along it. Then Mar 23 is missing data, and afterwards it became "France, " again but "France, " still was there. (or other way around, I may have forgotten). This raises the following questions:

What exactly is rolled up at country level, with emphasis on how we can be sure that something's not counted twice or excluded?
How gaps are back-filled?

Example No.2 I don't remember exactly, but there was few locations where cumulative amount was decreasing at some points.
I wrote some tests for JHU data in fact. See them at this commit before I migrated to Corona Data Scraper. Once cloned, do make install and make update to see a lot errors and warnings. Let me know if you have questions on that

Thanks for responding @Akuukis.

We're working with several data sources.  Sometimes countries and states both report, and they're inconsistent.  We de-dupe our sources, and use source "ratings" to break ties.  The code for this is src/events/processor/dedupe-locations/.  Unfortunately, due to our dependence on source data, it's very hard to guarantee that we're not excluding anything, but recently we have moved to standardized country/state data which will perhaps help with that.

When we scrape data for a given location, we cache the files for each date (recently changed to caching for each date-time, to allow for multiple scrapes).  Currently we do have gaps in these files, as sources change their reporting or move the sources.  The best we can do at this point would be to use the latest possible file to fill any gap, i.e. if we have a file for Monday and for Wednesday, but not Tuesday, we'd use Monday's data to fill in Tuesday.

fyi - I tried building that commit, but it failed (I'm on a Mac):
.... [SNIP] ...
../src/weakref.cc:168:75: error: too few arguments to function call, single argument 'context' was not specified
  Local<Object> proxy = Nan::New<ObjectTemplate>(proxyClass)->NewInstance();
                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
... [other errors]

make[1]: *** [Release/obj.target/weakref/src/weakref.o] Error 1
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/local/Cellar/node@12/12.16.1/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:194:23)
gyp ERR! stack     at ChildProcess.emit (events.js:311:20)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:275:12)
gyp ERR! System Darwin 18.7.0
gyp ERR! command<EMAIL_ADDRESS><EMAIL_ADDRESS>"rebuild"
gyp ERR! cwd /Users/jeff/Documents/Projects/pandemic-estimator/node_modules/weak

If you do see data issues, we'd appreciate it if you opened a new Data Issue and reference the spot!
Cheers, jz

Hi,
I think we misunderstood each other. I dont see any data issues with your data, or at least haven't searched for them carefully enough, but I saw a lot of issues with JHU. What's I mean by this issue "docs: methodology" is a plain-english big-picture explanation of what what's going on inside dedupe-locations and elsewhere.
Regarding the errors, let's just skip the JS dependencies because you don't need them. In such case please run (in Bash)
pip3 install -r requirements.txt --user
./scripts/fetch_raw_data.py
./scripts/export.py

Ah, got it.  Yes, we have a data scientist who is working on various data documentation.  I don't have a timeline on that.
re your code: I ran into errors.  Can you make sure that this project runs on a clean install, to a new directory, without any preconditions/assumptions about state?
# error one:
MacBook-Air:pandemic-estimator jeff$ ./scripts/fetch_raw_data.py
Traceback (most recent call last):
  File "./scripts/fetch_raw_data.py", line 52, in <module>
    urllib.request.urlretrieve(url_template.format(current_date.month, current_date.day), filepath)
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/urllib/request.py", line 257, in urlretrieve
    tfp = open(filename, 'wb')
FileNotFoundError: [Errno 2] No such file or directory: 'tmp/2020-01-23.csv'

# hack
MacBook-Air:pandemic-estimator jeff$ mkdir tmp
MacBook-Air:pandemic-estimator jeff$ touch tmp/2020-01-23.csv

# works up to a point
MacBook-Air:pandemic-estimator jeff$ ./scripts/fetch_raw_data.py
Cached tmp/2020-01-24.csv
Cached tmp/2020-01-25.csv
...
Traceback (most recent call last):
  File "./scripts/fetch_raw_data.py", line 76, in <module>
    records.append(parser(row, current_date))
  File "./scripts/fetch_raw_data.py", line 34, in parseVersion1
    return (row[0], row[1], date, normalize_zero(row[3]), normalize_zero(row[4]), normalize_zero(row[5]))
  File "./scripts/fetch_raw_data.py", line 19, in normalize_zero
    return int(something)
ValueError: invalid literal for int() with base 10: 'US'

Or optionally, please just give me the list of what you're looking at.  Thanks! jz

Sorry, I guess my report would too outdated to be relavant. Here's a recent problem, that cumulative is not cumulative: https://github.com/CSSEGISandData/COVID-19/issues/1250#issuecomment-613856442

Closing this issue as the reports generated from Li use a different method for report data: the data is reported by "priority".  In future, we'll include rollups, and also simply export all existing data.  If further questions arise, we'll deal with it in the new project.  cheers! jz


Broken links to Slides and Poster

I would love to see the slides and poster. Any way to get the links back up?

Dear Thomas,
Sorry for the very late response. It is a bit complicated to get the links back up at the moment for me, but you may find the slides and the poster in the following archive: https://we.tl/t-1hYpSuQpvT


Reverse Mode Simultaneous Directional Inputs

Reverse Causing Simultaneal DP Inputs And LS RS Inputs in respective stick modes.
To recreate this issue - Enable Reverse mode in webcofig, restart in controller mode, change the Stick mode to LS or RS. This makes Both DP and LS RS enter inputs at the same time.

We took a brief look into this, it is a conflict caused by the two addons being enabled at the same time due to how they are implemented.
We are discussing the overall issue of conflicting addons as they are independently made and compatibility among all all other addons will become more challenging as more are rolled out.
For this one specifically we will see if there is a quick fix, otherwise it may just be listed as 'not compatible with the LS/DP/RS' setting.

This was fixed via combination of code cleanup and addressing some oddities.  Thank you for the report @troytroy22 and for the fix @arntsonl


⚠ GitLab Server has degraded performance

In c627fbe, GitLab Server (https://gitlab01.its-telekom.eu) experienced degraded performance:

HTTP code: 200
Response time: 11021 ms

Resolved: GitLab Server performance has improved in a1dfcb3.


fixed index reset op

list_buffer_index_reset_op was not initialized as tensor, hence created problem while indexing.

Thanks!


Embed AP instead of *AP

From @chewxy on August 30, 2017 23:31
Was doing an allocation analysis to improve the package in general. Things can be improved very slightly by embedding AP instead of *AP in *CS and *Dense
Copied from original issue: chewxy/gorgonia#145

I'm looking at this issue.

I'm looking at this issue.

mind accepting the invite so I can actually list you as the assignee? Github is weird af

Ok, accepted.


feat: v4 重大更新

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Add Loggly supported timestamp field

Thanks for contributing to Logstash! If you haven't already signed our CLA, here's a handy link: https://www.elastic.co/contributor-agreement/
In order for Loggly to parse timestamps for a given log event the
timestamp data must be contained in a timestamp field - not @timestamp.
This change replaces the default @timestamp field of an event with a
timestamp field before posting to Loggly; Addressing Github Issue #12

Hi @nywilken, we have found your signature in our records, but it seems like you have signed with a different e-mail than the one used in yout Git commit. Can you please add both of these e-mails into your Github profile (they can be hidden), so we can match your e-mails to your Github profile?

Hi @karmi thanks for the prompt comment. I went ahead and updated my Github profile and submitted a fix for a rspec bug I introduced in my last commit. The PR is ready for review.

@nywilken rebase please?

Thanks for your contribution and sorry for the enormous delay in getting to this.
This fix was implemented differently in #28, and was released as v5.0.0.


thumbnails / images not displayed

I use the forge for my game hosting requirements, I have uploaded images into the moulinette folders in the forge and indexed them.  (As per the video demo provided by Baileywiki). No thumbnails are shown and I am unable to drag and drop anything onto my canvas
Attached are 2 images, one showing the images in my assets folder on the forge, the other showing a search in foundry using moulinette - as can be seen the assets are there but they are not shown on the search. the default 'free' ones are there and able to be placed but all of the others without thumbnails cannot be placed.
looking at the console the error message is the same for all the images without a thumbnail:-
moulinette/images/custom/FA%20Assets/Mapmaking/Artificial/Temporary_and_Mobile_Structures/Vehicles/Water/Boat_Mast_Wood_Ashen_A1_5x6.webp:1 Failed to load resource: the server responded with a status of 404 ()
when an image without a thumbnail is placed on the canvas the following error message is displayed:-
foundry.js:36256 Failed to load texture moulinette/images/custom/FA Assets/Mapmaking/Artificial/Decor/Clutter/Kitchenware/_Old_Kitchenware/Campfire_Pan.webp: Invalid URL
loadTexture @ foundry.js:36256
moulinette-tiles.js:426 Uncaught (in promise) TypeError: Cannot read property 'baseTexture' of null
at Function.createTile (moulinette-tiles.js:426)
its worth noting the asset it is trying to load has a url of :
https://assets.forge-vtt.com/602fc8a62cfc1cba3ed90ab5/moulinette/images/custom/Forgotten_Adventures/Artificial/Decor/Clutter/Kitchenware/_Old_Kitchenware/Campfire_Pan.webp

I'm planning to do some testing on Forge this week-end.

for info - i have logged on this morning and it is now working fine, As no changes have been made to the module I'm guessing it is a forge quirk with taking time to index the files etc, despite them being uploaded. Happy to provide any other information if it helps

I'm closing now that issue because I think that the last bugs related to Forge have been fixed. Feel free to re-open it (or submit another) if this is not the case.


Add support for mixpanel .register

So that we can set super properties that pass to mixpanel on every subsequent event..

Hi @adamt19, since this is a server-side library which will typically be used to send events for multiple users, you'll need to keep track of superproperties in your application code, probably tied in some way to your user/session scheme. For a previous discussion see https://github.com/mixpanel/mixpanel-node/issues/48. Drop us a line at<EMAIL_ADDRESS>if you need help with this, thanks!


Accommodate separate set of credentials to access DynamoDB

Description
When using an S3 compatible storage other than AWS S3, one has a set of access and secret key for the storage and another set for the DynamoDB. In this case, we need an option to provide separate credentials for DynamoDB access.
Use Case
Concurrent writes to an S3 compatible storage that does not share the credentials as DynamoDB.
Related Issue(s)

Which S3 compatible store are you using, most of them shouldn't need DynamoDb as they support conditional writes natively

Which S3 compatible store are you using, most of them shouldn't need DynamoDb as they support conditional writes natively

Hi @tustvold, I'm using Linode Object Storage (which has strong consistency).

So strong consistency is a necessary but insufficient condition here, to not need locking you would need support for conditional writes. I have not been able to ascertain if it supports this.

I experimented with AWS_S3_ALLOW_UNSAFE_RENAME='true' and observed that concurrent writes overwrite the json files and the later one wins the race condition.
We need to provide the DynamoDB credentials to enable concurrent writes and the object storage & DynamoDB require separate pairs of secret & access keys.
Can we consider adding optional parameters (under DeltaTable storage_options) to take DynamoDB credentials in case they differ from S3 credentials?

I need this also. I am using AWS S3 and DynamoDB. Both are are accessed using temporary tokens which I get by assuming a role. However S3 and dynamodb are in different regions and the tokens are scoped to the specific region. So I need to pass a separate set of credentials to both of them. I supply the S3 region with aws_region and the DynamoDB region indirectly with aws_endpoint_url_dynamodb.
Would there be another way to solve this?

I've opened a PR that should solve this :)


Makefile: add origin-release target

DOCKER_ORG=sttts make origin-release

/lgtm
@sttts mind setting up the other repos?
@ironcladlou our solution

/retest


[ZEPPELIN-2388] Improve the keyboard shortcuts dialog

What is this PR for?
This PR is for Improving the keyboard shortcuts dialog form and here is what i improve.

change to table shape
add scrollbar
fixed that text is misaligned when resizing windows

What type of PR is it?
[Bug fix | Improvement]
What is the Jira issue?

ZEPPELIN-2388; Prettify Keyboard Shortcut Dialog

How should this be tested?

Click `Keyboard Shortcuts' icon in a paragraph.
Check Keyboard Shortcuts shape.
Check resizing windows.

Screenshots (if appropriate)
[Before - 1. default]

[Before  - 2. text is misaligned when resizing windows]

[Before - 3. not scrollbar]

[After - 1. default]

[After - 2. resizing windows (my image is a little broken.)]

Questions:

Does the licenses files need update? No
Is there breaking changes for older versions? No
Does this needs documentation? No

@kun @Leemoonsoo Could you guys review this PR, please?

really great improvement! let me test and comment soon!

awesome!

Thank you @1ambda @felixcheung for seeing this!
Yeah, I like @1ambda's opinions! Let me update those as @1ambda's comments.

Cool! Significantly better than before 😄

Thanks @tae-jun for seeing :slightly_smiling_face:
And, @1ambda I updated this as your comments!

Could you review again, please?

LGTM!!!

great - just my preference - I actually like the tighter spacing and without line separator look better...

@felixcheung Thanks for your opinion :+1:
Let me update this like your describe!

I updated as @felixcheung suggestion such as the following screenshot!
Could @felixcheung  check it again, please?

Awesome! I like the new spacing and layout

very nice! LGTM

need to be rebased to make CI green.

@1ambda Thanks, I did.

CI failed but irrelevant.
Tests in error:
  SecurityRestApiTest.testGetUserList:69 » JsonSyntax java.lang.IllegalStateExce...
  SecurityRestApiTest.testTicket:55 » JsonSyntax java.lang.IllegalStateException...

LGTM.

Ping!
And this CI fail is irrelevant this PR.
Tests in error:
  SecurityRestApiTest.testGetUserList:69 » JsonSyntax java.lang.IllegalStateExce...
  SecurityRestApiTest.testTicket:55 » JsonSyntax java.lang.IllegalStateException...
Tests run: 58, Failures: 5, Errors: 2, Skipped: 1

LGTM and merge to master if no further comments


x/tools/gopls: warn about standard library API usage based on Go version

With 1.18 (which adds types.Config.GoVersion), we'd like to better support a workflow that uses gopls built at a recent version of Go to develop projects that target running at an older version of Go.
#50688 is necessary but not sufficient: setting types.Config.GoVersion will not catch usage of standard library APIs that were added in later Go versions. We need to add additional diagnostics to gopls.
The right way to do this is probably via an analyzer that has a flag configuring its target language version. This makes it easier for users to eventually leverage this functionality outside of gopls, or turn it of/on within gopls.
High level idea:

Add a new analyzer (initially in x/tools/internal/lsp/analysis) that reports usage of standard library APIs that do not exist at a target language version. It can read from GOROOT/api to build the list of accepted APIs.
Either infer the target language version for a package from go.mod, or (more likely) expose a setting to configure it.  Unlike for types.Config.GoVersion, reading go.mod is probably not good enough here, because IIRC the Go command does not enforce restrictions on standard library API use, so we would disagree. Perhaps we should not have a gopls`-specific configuration option, but rather expose a more general pattern for configuring analyzer flags.

Compare #46136, which proposes a similar warning for cmd/vet.

I think we don't need to do this. The correct solution is to use the correct version go command.
Moving to our unplanned milestone.


Confusion Helpdesk Administrator vs. Service Support Administrator regarding creation of service/support request in M365

Hello,
Overall it's not clear if the Helpdesk Administrator can only manage service requests or if this role can also create service requests.
As per https://docs.microsoft.com/en-us/azure/active-directory/roles/permissions-reference#helpdesk-administrator there are contradictory statements..first "can manage"...then "create and manage Microsoft 365 service requests"..
thanks for clarifying.
BR
Domenico

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

ID: 0767aac4-fcd9-eaac-2c30-8f17d8eadd92
Version Independent ID: a380a828-03f9-e037-3a62-e4165fda7cb6
Content: Azure AD built-in roles - Azure Active Directory
Content Source: articles/active-directory/roles/permissions-reference.md
Service: active-directory
Sub-service: roles
GitHub Login: @rolyon
Microsoft Alias: rolyon

@dferraiolo
Thanks for your feedback! I've assigned this issue to the author who will investigate and update as appropriate.

Hi @dferraiolo
Thanks for your feedback. We updated the Helpdesk Administrator description. Hopefully it is a little more clear.
https://docs.microsoft.com/en-us/azure/active-directory/roles/permissions-reference#helpdesk-administrator
Let us know if you have any additional feedback.
thanks

#please-close

#please-close


create mdanderson.txt

University of Texas - MDAnderson Cancer Center

@ktmcmo Pull request merged. Thank you!


Add authenticated repository

Would it possible to specify an authenticated maven repository ? I couldn't find a mention for it
thanks!

Any update on this? Thanks!

This worked for for me
<EMAIL_ADDRESS>

With the latest version you can add authenticated repositories:
https://github.com/alexarchambault/ammonium/pull/82/files#diff-cae375689c89089aa609103bd132b4b1R209
There is though an issue with spark, see https://github.com/alexarchambault/jupyter-scala/pull/152

This now works as in Ammonite, look for "authentication" on this page.


Cannot import modules under directory "dist/locale/" directly, in browser

Describe the bug
Cannot import modules under directory "dist/locale/" directly in browser.
To Reproduce
Steps to reproduce the behavior:

I want to import momentjs lib and one of its locale directly in browser
<script type="module">
import moment from '/node_modules/moment/dist/moment.js';
let lang='zh-cn';
import('/node_modules/moment/dist/locale/'+lang+'.js');
// ...
</script>

Actual result
404 Not Found /node_modules/moment/dist/moment
The request is initiated by this line
http://localhost:8080/node_modules/moment/dist/locale/zh-cn.js:7
import moment from '../moment';
Expected behavior
Use momentjs directly in browser without any compiler / transformer / bundler.
Possible solutions

for project maintainers: ensure the .js extension present in files under 'dist/locale/', say import moment from '../moment.js';
for momentjs users : configure your web server to try .js extension, like Nginx try_files $uri $uri.js; as a workaround

Additional context

Browser: any
Version 2.29.1

If you're playing around importing packages from a CDN like unpkg, you can omit the .js extension:
<script type="module">
  import moment from<EMAIL_ADDRESS>  import<EMAIL_ADDRESS>  console.log(moment.version, moment.locales()) // 2.29.1, ['en', 'zh-cn']
</script>

This doesn't work without the @version present in the URL as unpkg responds with a redirect, which causes a mismatch between the explicit import for moment vs import used inside the locale file:
<script type="module">
  /* First import gets redirected to
   *<EMAIL_ADDRESS>   * then<EMAIL_ADDRESS>   */
  import moment from "https://unpkg.com/moment/dist/moment";

  /* Second import gets redirected to
   *<EMAIL_ADDRESS>   * then<EMAIL_ADDRESS>   */
  import "https://unpkg.com/moment/dist/locale/zh-cn";

  /*
   * The locale file imported moment using a relative path:
   * import '../moment'
   * which resolved to<EMAIL_ADDRESS>   * and was redirects to<EMAIL_ADDRESS>   *
   * Because<EMAIL_ADDRESS>!== "https://unpkg.com/moment/dist/moment"
   * the browser treats these as separate modules, so the locale augments
   * an inaccessible second copy of the moment module that we don't have
   * access to.
   *
   * This means the moment does not get enhanced with the loaded locale:
   */
  console.log(moment.version, moment.locales()) // 2.29.1, ['en']
</script>


feat(cron): support nodeselector, affinity and toleration capabilities

This PR enable users to configure  nodeselector, tolerations and affinity capabilities for each cron job in the datahub-ingestion-cron helm chart.
Checklist

[ ] The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
[ ] Links to related issues (if applicable)
[ ] Tests for the changes have been added/updated (if applicable)
[ ] Docs related to the changes have been added/updated (if applicable)

Thank you!


Implements transformations for angular velocity quaternions correctly.

Thanks for this! the logic makes sense - I'm working on pulling it in, removing workarounds, etc. now.

So my only test mechanism here is using RenderManager and adjusting the client-side prediction interval to something big-ish and trying to figure out if what I see is what I expect.
I've put all my config files for doing this here: https://gist.github.com/rpavlik/fc743b6a2dd655fce47f75c30fcba955
My two cases are:

running with osvr_server_config.basic.clientside.json - directly using the IMU/prediction
running with osvr_server_config.clientside.json (but with no IR cam plugged in) - this is close to the default config (uses the IMU fusion plugin) which takes the velocity apart, puts it back together, and now, sends it along (and all workarounds have been removed from that path).

(the render manager config goes into sample-configs to run this)
Ideally, they'd both behave the same, and they'd both behave as expected - which I think is overrotating in the direction of rotation. That's not what appears to be happening - on my unit, the first (simplest) case, I appear to get some pitching what I try to just yaw...
Would appreciate a second look, and/or a correction of my expectations before merging.

This works for me in an orientation-only test using client-side prediction on RenderManager with an HDK 1.3 when I sit the HDK on a table top; when I rotate in one axis at a time, I get overcompensation in one eye for my config file that has one eye predict 500ms into the future and the other 16ms.  Did not have the camera plugged in or the fusion tracker running.
This also works for me when I disable client-side prediction and use the info from the DeadReckoningRotationFilter.sample.json to increase the prediction on the server side.  I get both eyes predicting ahead in my one-axis-at-a-time test.
So I think this is working.


Adjust cost calc. when pruning contracts with old hosts.

This PR fixes a pruning error I ran into on my node (2 hosts actually) where we would not transfer sufficient funds to the host when pruning the contract. The numbers didn't make sense, because calculating backwards I would have to be dealing with 40TiB contracts to arrive at the expected cost. I then realised we probably updated the logic at one point and found we did in host v0.2.1... So we're just dealing with very old hosts.
The fix is to simply retry and use the old cost calc. method, it's however slightly annoying to do because the host blows up the transport on error, and we need to run into the error once because hosts didn't have a release field... I tested this manually on the integrity node.

@ChrisSchinnerl mind taking a look at this DRAFT if this is reasonable as a fix for pre v0.2.1 hosts?


Not able to download using json file

Though it is showing me in cmd that download has been completed and corresponding file folders are also generating,but all those folders are empty.

@ragna211 can you post me the complete query that you have used?

closing due to inactivity.


chore(main): release 2.5.0

:robot: I have created a release beep boop
2.5.0 (2024-11-08)
Features

Support for large file uploads (refs #57) (68dcde7)

Bug Fixes

Update release-please (fd3d469)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v2.5.0
:sunflower:


Update .wordlist.txt

🚀 Deployed on https://667b23f9d951da6935f5fb89--cozy-fox-0defec.netlify.app


Fix Coverity issue

os.data wasn't initialized, could be random on some path.
Found by coverity scan.

This actually looks like yet an other false positive?

This has actually been fixed, the day after the last coverity scan, by using a return instead of goto.

cool.


bug: dropdown menu in drawer aside not show up correctly

What version of daisyUI are you using?
v2.51.5
Describe your issue
The dropdown menu is cut off on the edge of drawer aside, have tried different ways to fix it. I learned about stacking context, but it seems it's not the case. I have added overflow-visible to all it's parent element, still not working. I am getting more and more curious what could cause this behavior?
What browsers are you seeing the problem on?
Edge
Reproduction URL (optional)
https://play.tailwindcss.com/rHeawCuNRD

By default drawer-side has overflow-x: hidden and overflow-y: auto because we don't want horizontal scroll and we want vertical scroll when the content is longer than screen. Unfortunately the way CSS overflow works is when we use overflow-y: auto, we can not make horizontal overflow visible. I couldn't find a workaround for it yet but if you are sure you won't want a vertical scroll, you can add !overflow-visible to drawer-side and force it to show the overflow items.
Example: https://play.tailwindcss.com/cxYX4g1Vyu?size=1074x582
Good news is, daisyUI 3.0 will be released this month and it will provide collapsible menu items.
Let me know if you have any questions.


NetInfoState type none when i used cellular

Environment
React Native Environment Info:
System:
OS: macOS High Sierra 10.13.6
CPU: (4) x64 Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz
Memory: 4.50 GB / 24.00 GB
Shell: 3.2.57 - /bin/bash
Binaries:
Node: 11.10.0 - /usr/local/bin/node
Yarn: 1.13.0 - /usr/local/bin/yarn
npm: 6.7.0 - /usr/local/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
SDKs:
iOS SDK:
Platforms: iOS 12.1, macOS 10.14, tvOS 12.1, watchOS 5.1
Android SDK:
API Levels: 23, 24, 25, 26, 27, 28
Build Tools: 23.0.1, 25.0.0, 25.0.2, 25.0.3, 26.0.0, 26.0.1, 26.0.2, 26.0.3, 27.0.0, 27.0.1, 27.0.2, 27.0.3, 28.0.3
System Images: android-23 | Google APIs Intel x86 Atom, android-24 | Google APIs Intel x86 Atom, android-25 | Google APIs ARM EABI v7a, android-25 | Google APIs Intel x86 Atom, android-25 | Google APIs Intel x86 Atom_64, android-27 | Google APIs Intel x86 Atom
IDEs:
Android Studio: 3.4 AI-183.6<IP_ADDRESS>22156
Xcode: 10.1/10B61 - /usr/bin/xcodebuild
npmPackages:
react: 16.8.6 => 16.8.6
react-native: 0.59.9 => 0.59.9
npmGlobalPackages:
react-native-cli: 2.0.1
Platforms
iOS
Versions

iOS:12.1.3
react-native-netinfo:4.0.0
react-native: 0.59.9
react:16.8.6

Description
NetInfoState return type 'none' when i used cellular
Reproducible Demo
NetInfo.addEventListener((result) => {
alert(result.type)
}

"@react-native-community/netinfo": "4.0.0"

Can you confirm that it always stays as none. If you have just a console.log(result.type) in the listener handler you will be able to see if it starts as none and then moves to something else.

This might actually be related to the mobile network being LTE and assigning an ipv6 address. This is addressed in #146.
Once that is merged in, can you test again using the new version and see if that fixes the issue?

Hello
I am not sure if this is something else or related but on android we are getting a handful of crashes with
java.lang.NullPointerExceptionConnectivityReceiver.java:102
Attempt to read from field 'java.lang.String com.reactnativecommunity.netinfo.types.CellularGeneration.label' on a null object reference

I can send out the full stack if needed

@nonotest That crash was fixed here https://github.com/react-native-community/react-native-netinfo/pull/143

Sorry thanks !
On Tue, 23 Jul 2019 at 7:58 pm, Matt Oakes<EMAIL_ADDRESS>wrote:

@nonotest https://github.com/nonotest That crash was fixed here #143
https://github.com/react-native-community/react-native-netinfo/pull/143
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/react-native-community/react-native-netinfo/issues/145?email_source=notifications&email_token=AATO4LJS4DWMRSBZMQEXHXTQA3W6XA5CNFSM4IEQUD5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2S4CFQ#issuecomment-514179350,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AATO4LMKRT7BDYCGTLTXHLDQA3W6XANCNFSM4IEQUD5A
.

This might actually be related to the mobile network being LTE and assigning an ipv6 address. This is addressed in #146.
Once that is merged in, can you test again using the new version and see if that fixes the issue?

Yes, i use LTE

Можете ли вы подтвердить, что он _всегда _остается none. Если у вас есть только console.log(result.type)в обработчике слушателя, вы сможете увидеть, начинается ли он какnone, а затем переходит к чему-то еще.

Always none. Changes do not occur. The same problem with bluetooth

Closing due to inactivity. If this is still an issue, please open a new issue, filling in the provided template and referencing this issue number as #145.


Control the order of annotations

Is your feature request related to a problem? Please describe.
Annotations are a great way to display information about an ongoing build. The information rendered can have different levels of importance ranging from minor suggestions to calls to action which can drastically improve developer productivity, e.g., "this test is failing, here are the logs so you can fix it before waiting 1hr for the build to finish". However, annotations are rendered in the order they are created with new ones appearing at the top. This can cause important annotations to get buried and require lots of scrolling to see.
Describe the solution you'd like
The ability to control the order of created annotations.
Describe alternatives you've considered
An additional idea is to group annotations by their job affinity.

Hi @kormide we've raised this as a feature request with our Product Management Team. I'm going to close the issue here, as it's not directly related to the agent, but I've let them know to email you when there's progress.

Just wanted to add a note here incase anyone come across this thread when searching for similar functionality.
It is now possible to set the order of annotations using the priority option detailed in the Buildkite Documentation

Awesome! Thanks for following up.
On Tue, 16 Jul 2024 at 19:09, Liam P Clancy @.***>
wrote:

Just wanted to add a note here incase anyone come across this thread when
searching for similar functionality.
It is now possible to set the order of annotations using the priority
option detailed in the Buildkite Documentation
https://buildkite.com/docs/agent/v3/cli-annotate#priority
—
Reply to this email directly, view it on GitHub
https://github.com/buildkite/agent/issues/2600#issuecomment-2232205623,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABFYGGPP3KJNMCFUKGZZWFDZMXG4VAVCNFSM6AAAAABCK7U5UWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZSGIYDKNRSGM
.
You are receiving this because you were mentioned.Message ID:
@.***>


How to use Zeno

I would like to ask how to correctly use the script for uploading to Zeno. I use the same example as https://github.com/EleutherAI/lm-evaluation-harness/blob/main/examples/visualize-zeno.ipynb
accelerate launch -m lm_eval \
    --model hf \
    --model_args pretrained=google/gemma-1.1-2b-it \
    --tasks imdb \
    --batch_size 32 \
    --device cuda \
    --log_samples \
    --output_path outputs/gemma-1.1-2b-it \
    --limit 10

python scripts/zeno_visualize.py --data_path outputs --project_name "Zeno test"

Traceback (most recent call last):
  File "/raid/data/david/lm-evaluation-harness/scripts/zeno_visualize.py", line 219, in <module>
    main()
  File "/raid/data/david/lm-evaluation-harness/scripts/zeno_visualize.py", line 48, in main
    tasks = set(tasks_for_model(models[0], args.data_path))
  File "/raid/data/david/lm-evaluation-harness/scripts/zeno_visualize.py", line 130, in tasks_for_model
    json.load(open(Path(dir_path, "results.json"), encoding="utf-8"))["configs"],
FileNotFoundError: [Errno 2] No such file or directory: 'outputs/gemma-1.1-2b-it/results.json'

The error seems weird to me because this is the directory structure:
outputs
└── gemma-1.1-2b-it
    └── google__gemma-1.1-2b-it
        ├── results_2024-05-14T17-07-12.477774.json
        └── samples_imdb_2024-05-14T17-07-12.477774.json

I created more outputs, renamed some files and folders, and got this error message:
FileNotFoundError: [Errno 2] No such file or directory: 'output/imdb_gemma_2b_it/google__gemma-1.1-2b-it/pretrained=google__gemma-1.1-2b-it,parallelize=True,load_in_4bit=True_imdb.jsonl'

Can anyone please suggest how to use those scripts correctly?

Hi @DavidAdamczyk!
I fixed the filename problem in #1926 - now the script will use the most recent result files for comparison. However, I'm not sure if the rest of the script is correct, there may have been other breaking changes introduced in the meantime. I fixed loading the data, but it still gives me errors later in the generate_dataset() function, so I suspect that part was broken before by changing the structure of the samples results files.
In the current version of the library, you no longer need to specify the model name in the output path, just use --output_path outputs and it will be created automatically. Then, when using the Zeno script, you just need to point to the outputs dir instead of a specific model.


Explicitly import the lazy_static macro.

Summary of changes
Changes introduced in this pull request:
Reference issue to close (if applicable)

Closes #1868
Other information and links

There's one more extern crate lazy_static in vm/interpreter/src/lib.rs.


Lint the project

We should add a make target for linting the project and also add this to CI to improve the code quality.

Done.


[CA-1410] Add lots of aria labels to cloud environment page

<!--
Hello, friend!
Remember to mention what sort of testing/verification you performed in the course of building this PR, i.e. checking functionality in the browser locally.
Thanks!
--!>

Closed, because on inspection of @andrewmarcus's comment, all the inputs had a label with htmlFor


New App: Trimet Stops

Shows you the next two arrivals of a given trimet stop. Uses estimated arrival times when available, otherwise looks at scheduled times. Uses beautiful Trimet imagery.
Description
This shows you the next two estimated (or scheduled) arrivals at a given stop. It works for all bus lines, and light rail.
Copilot

🤖 Generated by Copilot at 787b4d0
Summary
🚉📄🐍

This pull request adds a new app called trimet-stops, which shows the next two arrivals at a Trimet stop. The app consists of a manifest file apps/trimetstops/manifest.yaml and a code file apps/trimetstops/trimet_stops.star. The code file uses Starlark to create the app layout and logic, and defines the app configuration schema.

trimet-stops app
Starlark code and manifest
Autumn leaves on bus

Walkthrough

Create a new app called trimet-stops that shows the next two arrivals at a given stop for the Trimet public transportation system in Portland, Oregon (link, link)
Define the app metadata, such as id, name, summary, description, author, file name, and package name, in manifest.yaml (link)
Write the main app logic in trimet_stops.star, using Starlark, a dialect of Python (link)
Import modules for rendering, schema, requests, and json in trimet_stops.star (link)
Define constants for the Trimet API base URL, the app icon, and the colors in trimet_stops.star (link)
Implement the main function that takes a config object and returns a render.Root object with the app layout and logic in trimet_stops.star (link)
Use requests.get to fetch the arrival data from the Trimet API, using the config fields for the app id and the stop id in trimet_stops.star (link)
Parse the response as json and extract the relevant fields, such as the stop name, the route number, the destination, and the arrival time, in trimet_stops.star (link)

I have read the CLA Document and I hereby sign the CLA


Addons/cookies/settings lost

portable browser with --single-process --in-process-gpu --process-per-site
and several month it works well
before update on 122.0.6261.85 all installed addons suddenly disappeared
after update to 122.0.6261.152
i turn on
chrome://flags/#disable-encryption
chrome://flags/#disable-machine-id
chrome://flags/#ungoogled-supermium
chrome://flags/#compact-ui
chrome://flags/#disable-alternate-ds
at least 3 times every one
bcz new settings resets every browser close
after i noticed that cookies not saving more
(authorisation not saving on several sites)
WTF? o_O

#disable-encryption and #disable-machine-id were known to cause these issues on ungoogled builds for Windows (see ungoogled-software/ungoogled-chromium-windows#246 ungoogled-software/ungoogled-chromium-windows#334 ); you should only enable them before actually switching machines. And it seems to break authorization on certain sites anyway.

but it's only 1/3 of glitches

#disable-encryption and #disable-machine-id were known to cause these issues on ungoogled builds for Windows (see ungoogled-software/ungoogled-chromium-windows#246 ungoogled-software/ungoogled-chromium-windows#334 ); you should only enable them before actually switching machines. And it seems to break authorization on certain sites anyway.

but i lost all addons and cookies before
without turn on any #disable-encryption #disable-machine-id

also with --single-process --in-process-gpu
supermium ask about restore previous session every time (from the first)

The big downside with that pathc is if you accidentally run without the cli parameter, it'll wipe the settings