miss  ipv6 address when passt interface

according to the document https://kubevirt.io/user-guide/virtual_machines/interfaces_and_networks/#passt , the passt supports IPv6 out of the box , and no need to configuring IPv6 manually.
but in my cluster with kubevirt v1.0.0 and dual-stack CNI, the VM with passt interface does not assign the ipv6 address
cat <<EOF | kubectl apply -f -
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: vm-passthrough
spec:
  running: true
  template:
    spec:
      domain:
        devices:
          disks:
          - disk:
              bus: virtio
            name: containerdisk
          - disk:
              bus: virtio
            name: cloudinitdisk
          interfaces:
          - passt: {}
            name: red
          rng: {}
        resources:
          requests:
            memory: 1024M
      networks:
      - name: red
        pod: {}
      terminationGracePeriodSeconds: 0
      volumes:
      - containerDisk:
          image: kubevirt/fedora-with-test-tooling-container-disk:devel
        name: containerdisk
      - name: cloudinitdisk
        cloudInitNoCloud:
          userData: |-
            #!/bin/bash
            echo "fedora" |passwd fedora --stdin
EOF

in the VM , just got ipv4 address (<IP_ADDRESS>/16)
~# virtctl console vm-passthrough-macvlan1
Successfully connected to vm-passthrough-macvlan1 console. The escape sequence is ^]
[fedora@vm-passthrough-macvlan1 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    altname enp3s0
    inet <IP_ADDRESS>/16 brd <IP_ADDRESS> scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe12:3456/64 scope link
       valid_lft forever preferred_lft forever

the corresponding launcher pod , there is ipv4(<IP_ADDRESS>/16) and ipv6(fc00:f853:ccd:e793::140/64) address assinged by the CNI.
$ virt-launcher-vm-passthrough-macvlan1-5bkwn bashr-vm-passthrough-macvlan1-5bkwn
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
bash-5.1$
bash-5.1$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/ipip <IP_ADDRESS> brd <IP_ADDRESS>
3: eth0@if13: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 7a:64:93:ee:de:a3 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet <IP_ADDRESS>/16 brd <IP_ADDRESS> scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fc00:f853:ccd:e793::140/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::7864:93ff:feee:dea3/64 scope link
       valid_lft forever preferred_lft forever
4: veth0@if21: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether be:ee:2d:a7:37:01 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::bcee:2dff:fea7:3701/64 scope link
       valid_lft forever preferred_lft forever

I tested it with calico and underlay CNI , the result is same.
according to my understanding, if the CNI assigns dual-stack IP to the launcher pod,  the ipv6 address of launcher pod will be copied to the VM interface ?

/sig network
@EdDev @AlonaKaplan

@weizhoublue thanks for the bug report. Can you please attach the virt-launcher compute container log?

{"component":"virt-launcher","level":"info","msg":"Collected all requested hook sidecar sockets","pos":"manager.go:86","timestamp":"2023-08-04T12:36:07.331922Z"}
{"component":"virt-launcher","level":"info","msg":"Sorted all collected sidecar sockets per hook point based on their priority and name: map[]","pos":"manager.go:89","timestamp":"2023-08-04T12:36:07.331975Z"}
{"component":"virt-launcher","level":"info","msg":"Connecting to libvirt daemon: qemu+unix:///session?socket=/var/run/libvirt/virtqemud-sock","pos":"libvirt.go:524","timestamp":"2023-08-04T12:36:07.332572Z"}
{"component":"virt-launcher","level":"info","msg":"Connecting to libvirt daemon failed: virError(Code=38, Domain=7, Message='Failed to connect socket to '/var/run/libvirt/virtqemud-sock': No such file or directory')","pos":"libvirt.go:532","timestamp":"2023-08-04T12:36:07.334882Z"}
{"component":"virt-launcher","level":"info","msg":"libvirt version: 9.0.0, package: 3.el9<EMAIL_ADDRESS>2023-02-01-12:58:56, )","subcomponent":"libvirt","thread":"52","timestamp":"2023-08-04T12:36:07.356000Z"}
{"component":"virt-launcher","level":"info","msg":"hostname: vm-passthrough-macvlan1","subcomponent":"libvirt","thread":"52","timestamp":"2023-08-04T12:36:07.356000Z"}
{"component":"virt-launcher","level":"error","msg":"Unable to open /dev/kvm: Permission denied","pos":"virHostCPUGetCPUID:1422","subcomponent":"libvirt","thread":"52","timestamp":"2023-08-04T12:36:07.356000Z"}
{"component":"virt-launcher","level":"error","msg":"internal error: Unable to get session bus connection: Cannot spawn a message bus without a machine-id: Unable to load /var/lib/dbus/machine-id or /etc/machine-id: Failed to open file “/var/lib/dbus/machine-id”: No such file or directory","pos":"virGDBusGetSessionBus:126","subcomponent":"libvirt","thread":"52","timestamp":"2023-08-04T12:36:07.357000Z"}
{"component":"virt-launcher","level":"error","msg":"internal error: Unable to get system bus connection: Could not connect: No such file or directory","pos":"virGDBusGetSystemBus:99","subcomponent":"libvirt","thread":"52","timestamp":"2023-08-04T12:36:07.357000Z"}
{"component":"virt-launcher","level":"info","msg":"Connected to libvirt daemon","pos":"libvirt.go:540","timestamp":"2023-08-04T12:36:07.838540Z"}
{"component":"virt-launcher","level":"info","msg":"Registered libvirt event notify callback","pos":"client.go:539","timestamp":"2023-08-04T12:36:07.843717Z"}
{"component":"virt-launcher","level":"info","msg":"Marked as ready","pos":"virt-launcher.go:75","timestamp":"2023-08-04T12:36:07.844186Z"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Executing PreStartHook on VMI pod environment","name":"vm-passthrough-macvlan1","namespace":"default","pos":"manager.go:623","timestamp":"2023-08-04T12:36:22.314763Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Starting PreCloudInitIso hook","name":"vm-passthrough-macvlan1","namespace":"default","pos":"manager.go:644","timestamp":"2023-08-04T12:36:22.314851Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 36 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.078376Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Outbound interface (IPv4): eth0","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.078471Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 36 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.078497Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Outbound interface (IPv6): eth0","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.078518Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 9 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.078538Z"}
{"component":"virt-launcher","level":"info","msg":"passt: MAC:","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.078564Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 32 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.078584Z"}
{"component":"virt-launcher","level":"info","msg":"passt:     host: 7a:64:93:ee:de:a3","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.078604Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 10 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.078626Z"}
{"component":"virt-launcher","level":"info","msg":"passt: DHCP:","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.078667Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 29 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.078687Z"}
{"component":"virt-launcher","level":"info","msg":"passt:     assign: <IP_ADDRESS>","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.078709Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 26 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.078732Z"}
{"component":"virt-launcher","level":"info","msg":"passt:     mask: <IP_ADDRESS>","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.078753Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 27 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.078772Z"}
{"component":"virt-launcher","level":"info","msg":"passt:     router: <IP_ADDRESS>","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.078796Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 9 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.078814Z"}
{"component":"virt-launcher","level":"info","msg":"passt: DNS:","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.078834Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 20 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.078854Z"}
{"component":"virt-launcher","level":"info","msg":"passt:     <IP_ADDRESS>","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.078873Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 21 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.078894Z"}
{"component":"virt-launcher","level":"info","msg":"passt: DNS search list:","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.078921Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 34 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.078939Z"}
{"component":"virt-launcher","level":"info","msg":"passt:     default.svc.cluster.local","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.078959Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 26 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.078980Z"}
{"component":"virt-launcher","level":"info","msg":"passt:     svc.cluster.local","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.079000Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 22 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.079023Z"}
{"component":"virt-launcher","level":"info","msg":"passt:     cluster.local","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.079041Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 16 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.079061Z"}
{"component":"virt-launcher","level":"info","msg":"passt: NDP/DHCPv6:","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.079082Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 40 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.079102Z"}
{"component":"virt-launcher","level":"info","msg":"passt:     assign: fc00:f853:ccd:e793::140","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.079126Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 38 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.079145Z"}
{"component":"virt-launcher","level":"info","msg":"passt:     router: fc00:f853:ccd:e793::3","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.079166Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 50 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.079190Z"}
{"component":"virt-launcher","level":"info","msg":"passt:     our link-local: fe80::7864:93ff:feee:dea3","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.079210Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 21 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.079236Z"}
{"component":"virt-launcher","level":"info","msg":"passt: DNS search list:","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.079258Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 34 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.079302Z"}
{"component":"virt-launcher","level":"info","msg":"passt:     default.svc.cluster.local","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.079327Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 26 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.079347Z"}
{"component":"virt-launcher","level":"info","msg":"passt:     svc.cluster.local","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.079379Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 22 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.079399Z"}
{"component":"virt-launcher","level":"info","msg":"passt:     cluster.local","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.079418Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 53 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.081012Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 63 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.081046Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 124 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.081067Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 40 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.081100Z"}
{"component":"virt-launcher","level":"info","msg":"passt: Failed to send 64 bytes to syslog","pos":"generators.go:340","timestamp":"2023-08-04T12:36:23.081120Z"}
{"component":"virt-launcher","level":"info","msg":"Driver cache mode for /var/run/kubevirt-ephemeral-disks/disk-data/containerdisk/disk.qcow2 set to none","pos":"converter.go:468","timestamp":"2023-08-04T12:36:23.158348Z"}
{"component":"virt-launcher","level":"info","msg":"Driver cache mode for /var/run/kubevirt-ephemeral-disks/cloud-init-data/default/vm-passthrough-macvlan1/noCloud.iso set to none","pos":"converter.go:468","timestamp":"2023-08-04T12:36:23.167638Z"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Domain XML generated. Base64 dump [encoded data, 4584 characters]","name":"vm-passthrough-macvlan1","namespace":"default","pos":"libvirt_helper.go:133","timestamp":"2023-08-04T12:36:23.177880Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher-monitor","level":"info","msg":"Reaped pid 74 with status 0","pos":"virt-launcher-monitor.go:125","timestamp":"2023-08-04T12:36:23.220698Z"}
{"component":"virt-launcher-monitor","level":"info","msg":"Reaped pid 76 with status 0","pos":"virt-launcher-monitor.go:125","timestamp":"2023-08-04T12:36:23.421993Z"}
{"component":"virt-launcher-monitor","level":"info","msg":"Reaped pid 82 with status 0","pos":"virt-launcher-monitor.go:125","timestamp":"2023-08-04T12:36:23.645657Z"}
{"component":"virt-launcher-monitor","level":"info","msg":"Reaped pid 84 with status 0","pos":"virt-launcher-monitor.go:125","timestamp":"2023-08-04T12:36:23.695315Z"}
{"component":"virt-launcher","level":"info","msg":"DomainLifecycle event Domain event=\"defined\" detail=\"added\" with event id 0 reason 0 received","pos":"client.go:465","timestamp":"2023-08-04T12:36:24.042234Z"}
{"component":"virt-launcher","level":"info","msg":"kubevirt domain status: Shutoff(5):Unknown(0)","pos":"client.go:296","timestamp":"2023-08-04T12:36:24.045837Z"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Domain XML generated. Base64 dump [encoded data, 7336 characters]","name":"vm-passthrough-macvlan1","namespace":"default","pos":"libvirt_helper.go:133","timestamp":"2023-08-04T12:36:24.046411Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","level":"info","msg":"Successfully connected to domain notify socket at /var/run/kubevirt/domain-notify-pipe.sock","pos":"client.go:170","timestamp":"2023-08-04T12:36:24.050864Z"}
{"component":"virt-launcher","level":"info","msg":"Domain name event: default_vm-passthrough-macvlan1","pos":"client.go:423","timestamp":"2023-08-04T12:36:24.054348Z"}
{"component":"virt-launcher","level":"info","msg":"Monitoring loop: rate 1s start timeout 5m8s","pos":"monitor.go:181","timestamp":"2023-08-04T12:36:24.056727Z"}
{"component":"virt-launcher","level":"info","msg":"DomainLifecycle event Domain event=\"defined\" detail=\"updated\" with event id 0 reason 1 received","pos":"client.go:465","timestamp":"2023-08-04T12:36:24.128765Z"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Domain defined.","name":"vm-passthrough-macvlan1","namespace":"default","pos":"manager.go:1002","timestamp":"2023-08-04T12:36:24.128814Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","level":"info","msg":"kubevirt domain status: Shutoff(5):Unknown(0)","pos":"client.go:296","timestamp":"2023-08-04T12:36:24.131943Z"}
{"component":"virt-launcher","level":"info","msg":"Domain name event: default_vm-passthrough-macvlan1","pos":"client.go:423","timestamp":"2023-08-04T12:36:24.133653Z"}
{"component":"virt-launcher","level":"info","msg":"generated nocloud iso file /var/run/kubevirt-ephemeral-disks/cloud-init-data/default/vm-passthrough-macvlan1/noCloud.iso","pos":"cloud-init.go:674","timestamp":"2023-08-04T12:36:24.240504Z"}
{"component":"virt-launcher","level":"info","msg":"GuestAgentLifecycle event state 2 with reason 1 received","pos":"client.go:522","timestamp":"2023-08-04T12:36:24.381029Z"}
{"component":"virt-launcher","level":"info","msg":"kubevirt domain status: Paused(3):StartingUp(11)","pos":"client.go:296","timestamp":"2023-08-04T12:36:24.384856Z"}
{"component":"virt-launcher","level":"info","msg":"Domain name event: default_vm-passthrough-macvlan1","pos":"client.go:423","timestamp":"2023-08-04T12:36:24.386958Z"}
{"component":"virt-launcher","level":"info","msg":"DomainLifecycle event Domain event=\"resumed\" detail=\"unpaused\" with event id 4 reason 0 received","pos":"client.go:465","timestamp":"2023-08-04T12:36:24.681911Z"}
{"component":"virt-launcher","level":"info","msg":"DomainLifecycle event Domain event=\"started\" detail=\"booted\" with event id 2 reason 0 received","pos":"client.go:465","timestamp":"2023-08-04T12:36:24.684412Z"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Domain started.","name":"vm-passthrough-macvlan1","namespace":"default","pos":"manager.go:1030","timestamp":"2023-08-04T12:36:24.685836Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T12:36:24.688710Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","level":"info","msg":"kubevirt domain status: Running(1):Unknown(1)","pos":"client.go:296","timestamp":"2023-08-04T12:36:24.690294Z"}
{"component":"virt-launcher","level":"info","msg":"Domain name event: default_vm-passthrough-macvlan1","pos":"client.go:423","timestamp":"2023-08-04T12:36:24.693309Z"}
{"component":"virt-launcher","level":"info","msg":"kubevirt domain status: Running(1):Unknown(1)","pos":"client.go:296","timestamp":"2023-08-04T12:36:24.696483Z"}
{"component":"virt-launcher","level":"info","msg":"Domain name event: default_vm-passthrough-macvlan1","pos":"client.go:423","timestamp":"2023-08-04T12:36:24.698654Z"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T12:36:24.799457Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T12:36:24.853487Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T12:36:24.917678Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","level":"info","msg":"Found PID for default_vm-passthrough-macvlan1: 93","pos":"monitor.go:142","timestamp":"2023-08-04T12:36:25.057612Z"}
{"component":"virt-launcher","level":"warning","msg":"missing device in NIC_RX_FILTER_CHANGED event","pos":"qemuMonitorJSONHandleNicRxFilterChanged:1030","subcomponent":"libvirt","thread":"94","timestamp":"2023-08-04T12:36:37.610000Z"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T12:39:06.182484Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T12:44:06.187412Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T12:49:06.185799Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T12:54:06.186802Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T12:59:06.187434Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T13:04:06.184750Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T13:09:06.185483Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T13:14:06.185874Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T13:19:06.182951Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T13:24:06.186014Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T13:29:06.188629Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T13:34:06.185950Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T13:39:06.184654Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T13:44:06.187778Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T13:49:06.184362Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T13:54:06.184869Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T13:59:06.186311Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T14:04:06.184909Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T14:09:06.188028Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T14:14:06.185656Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T14:19:06.185628Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T14:24:06.186052Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T14:29:06.186850Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T14:34:06.187949Z","uid":"ee262987-0517-45e4-898e-152d32782922"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm-passthrough-macvlan1","namespace":"default","pos":"server.go:208","timestamp":"2023-08-04T14:39:06.188679Z","uid":"ee262987-0517-45e4-898e-152d32782922"}

Thanks! Please also share ip -6 route and journalctl of the guest. Is there a chance dhcp6 client is not running on the guest?

do you mean it depand on the dhcp of the guest os ?
[fedora@vm-passthrough]$ ip -6 r
::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium

[fedora@vm-passthrough]$ systemctl status
● vm-passthrough
    State: degraded
     Jobs: 0 queued
   Failed: 1 units
    Since: Fri 2023-08-04 12:36:31 UTC; 4 days ago
   CGroup: /
           ├─user.slice
           │ └─user-1000.slice
           │<EMAIL_ADDRESS>           │   │ └─init.scope
           │   │   ├─752 /usr/lib/systemd/systemd --user
           │   │   └─754 (sd-pam)
           │   └─session-1.scope
           │     ├─ 704 login -- fedora
           │     ├─ 760 -bash
           │     ├─6239 systemctl status
           │     └─6240 less
           ├─init.scope
           │ └─1 /usr/lib/systemd/systemd --switched-root --system --deserializ>
           └─system.slice
             ├─systemd-udevd.service
             │ └─512 /usr/lib/systemd/systemd-udevd
             ├─dbus-broker.service
             │ ├─571 /usr/bin/dbus-broker-launch --scope system --audit
             │ └─575 dbus-broker --log 4 --controller 9 --machine-id 080962bf82>
             ├─systemd-homed.service
             │ └─548 /usr/lib/systemd/systemd-homed
             ├─chronyd.service
             │ └─551 /usr/sbin/chronyd
             ├─auditd.service
             │ └─517 /sbin/auditd
             ├─systemd-journald.service
             │ └─501 /usr/lib/systemd/systemd-journald
             ├─sshd.service
             │ └─721 /usr/sbin/sshd -D -oCiphers=aes256-gcm@openssh.com,chacha2>
             ├─NetworkManager.service
             │ └─625 /usr/sbin/NetworkManager --no-daemon
             ├─systemd-userdbd.service
             │ ├─ 747 /usr/lib/systemd/systemd-userdbd
             │ ├─6236 systemd-userwork
             │ ├─6237 systemd-userwork
             │ └─6238 systemd-userwork
             ├─sssd.service
             │ ├─547 /usr/sbin/sssd -i --logger=files
             │ ├─556 /usr/libexec/sssd/sssd_be --domain implicit_files --uid 0 >
             │ └─557 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files
             ├─system-getty.slice
             │<EMAIL_ADDRESS>             │   └─703 /sbin/agetty -o -p -- \u --noclear tty1 linux
             └─systemd-logind.service
               └─558 /usr/lib/systemd/systemd-logind

[fedora@vm-passthrough-macvlan1 ~]$ nmcli con show
NAME         UUID                                  TYPE      DEVICE
System eth0  5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03  ethernet  eth0

[fedora@vm-passthrough-]$ nmcli con show 'System eth0'
connection.id:                          System eth0
connection.uuid:                        5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03
connection.stable-id:                   --
connection.type:                        802-3-ethernet
connection.interface-name:              eth0
connection.autoconnect:                 yes
connection.autoconnect-priority:        0
connection.autoconnect-retries:         -1 (default)
connection.multi-connect:               0 (default)
connection.auth-retries:                -1
connection.timestamp:<PHONE_NUMBER>
connection.read-only:                   no
connection.permissions:                 --
connection.zone:                        --
connection.master:                      --
connection.slave-type:                  --
connection.autoconnect-slaves:          -1 (default)
connection.secondaries:                 --
connection.gateway-ping-timeout:        0
connection.metered:                     unknown
connection.lldp:                        default
connection.mdns:                        -1 (default)
connection.llmnr:                       -1 (default)
connection.wait-device-timeout:         -1
802-3-ethernet.port:                    --
802-3-ethernet.speed:                   0
802-3-ethernet.duplex:                  --
802-3-ethernet.auto-negotiate:          no
802-3-ethernet.mac-address:             52:54:00:12:34:56
802-3-ethernet.cloned-mac-address:      --
802-3-ethernet.generate-mac-address-mask:--
802-3-ethernet.mac-address-blacklist:   --
802-3-ethernet.mtu:                     auto
802-3-ethernet.s390-subchannels:        --
802-3-ethernet.s390-nettype:            --
802-3-ethernet.s390-options:            --
802-3-ethernet.wake-on-lan:             default
802-3-ethernet.wake-on-lan-password:    --
ipv4.method:                            auto
ipv4.dns:                               --
ipv4.dns-search:                        --
ipv4.dns-options:                       --
ipv4.dns-priority:                      0
ipv4.addresses:                         --
ipv4.gateway:                           --
ipv4.routes:                            --
ipv4.route-metric:                      -1
ipv4.route-table:                       0 (unspec)
ipv4.routing-rules:                     --
ipv4.ignore-auto-routes:                no
ipv4.ignore-auto-dns:                   no
ipv4.dhcp-client-id:                    --
ipv4.dhcp-iaid:                         --
ipv4.dhcp-timeout:                      0 (default)
ipv4.dhcp-send-hostname:                yes
ipv4.dhcp-hostname:                     --
ipv4.dhcp-fqdn:                         --
ipv4.dhcp-hostname-flags:               0x0 (none)
ipv4.never-default:                     no
ipv4.may-fail:                          yes
ipv4.dad-timeout:                       -1 (default)
ipv6.method:                            ignore
ipv6.dns:                               --
ipv6.dns-search:                        --
ipv6.dns-options:                       --
ipv6.dns-priority:                      0
ipv6.addresses:                         --
ipv6.gateway:                           --
ipv6.routes:                            --
ipv6.route-metric:                      -1
ipv6.route-table:                       0 (unspec)
ipv6.routing-rules:                     --
ipv6.ignore-auto-routes:                no
ipv6.ignore-auto-dns:                   no
ipv6.never-default:                     no
ipv6.may-fail:                          yes
ipv6.ip6-privacy:                       -1 (unknown)
ipv6.addr-gen-mode:                     stable-privacy
ipv6.ra-timeout:                        0 (default)
ipv6.dhcp-duid:                         --
ipv6.dhcp-iaid:                         --
ipv6.dhcp-timeout:                      0 (default)
ipv6.dhcp-send-hostname:                yes
ipv6.dhcp-hostname:                     --
ipv6.dhcp-hostname-flags:               0x0 (none)
ipv6.token:                             --
proxy.method:                           none
proxy.browser-only:                     no
proxy.pac-url:                          --
proxy.pac-script:                       --
GENERAL.NAME:                           System eth0
GENERAL.UUID:                           5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03
GENERAL.DEVICES:                        eth0
GENERAL.IP-IFACE:                       eth0
GENERAL.STATE:                          activated
GENERAL.DEFAULT:                        yes
GENERAL.DEFAULT6:                       yes
GENERAL.SPEC-OBJECT:                    --
GENERAL.VPN:                            no
GENERAL.DBUS-PATH:                      /org/freedesktop/NetworkManager/ActiveC>
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/Setting>
GENERAL.ZONE:                           --
GENERAL.MASTER-PATH:                    --
IP4.ADDRESS[1]:                         <IP_ADDRESS>/16
IP4.GATEWAY:                            <IP_ADDRESS>
IP4.ROUTE[1]:                           dst = <IP_ADDRESS>/0, nh = <IP_ADDRESS>, mt = >
IP4.ROUTE[2]:                           dst = <IP_ADDRESS>/16, nh = <IP_ADDRESS>, mt =>
IP4.DNS[1]:                             <IP_ADDRESS>
DHCP4.OPTION[1]:                        dhcp_lease_time =<PHONE_NUMBER>
DHCP4.OPTION[2]:                        domain_name_servers = <IP_ADDRESS>
DHCP4.OPTION[3]:                        domain_search = default.svc.cluster.loc>
DHCP4.OPTION[4]:                        interface_mtu = 65520
DHCP4.OPTION[5]:                        ip_address = <IP_ADDRESS>
DHCP4.OPTION[6]:                        requested_broadcast_address = 1
DHCP4.OPTION[7]:                        requested_domain_name = 1
DHCP4.OPTION[8]:                        requested_domain_name_servers = 1
DHCP4.OPTION[9]:                        requested_domain_search = 1
DHCP4.OPTION[10]:                       requested_host_name = 1
DHCP4.OPTION[11]:                       requested_interface_mtu = 1
DHCP4.OPTION[12]:                       requested_ms_classless_static_routes = 1
DHCP4.OPTION[13]:                       requested_nis_domain = 1
DHCP4.OPTION[14]:                       requested_nis_servers = 1
DHCP4.OPTION[15]:                       requested_ntp_servers = 1
DHCP4.OPTION[16]:                       requested_rfc3442_classless_static_rout>
DHCP4.OPTION[17]:                       requested_root_path = 1
DHCP4.OPTION[18]:                       requested_routers = 1
DHCP4.OPTION[19]:                       requested_static_routes = 1
DHCP4.OPTION[20]:                       requested_subnet_mask = 1
DHCP4.OPTION[21]:                       requested_time_offset = 1
DHCP4.OPTION[22]:                       requested_wpad = 1
DHCP4.OPTION[23]:                       routers = <IP_ADDRESS>
DHCP4.OPTION[24]:                       subnet_mask = <IP_ADDRESS>
IP6.ADDRESS[1]:                         fe80::5054:ff:fe12:3456/64
IP6.GATEWAY:                            --
IP6.ROUTE[1]:                           dst = fe80::/64, nh = ::, mt = 256
IP6.ROUTE[2]:                           dst = ff00::/8, nh = ::, mt = 256, tabl>

the default connection set ipv6.method to be ignore.
does it need to turn of dhcp for the connection ?
I turn on the  dhcp and the interface got wrong CIDR length , fc00:f853:ccd:e793::140/128 compared with virt-launcher  pod ( fc00:f853:ccd:e793::140/64 ) , and miss ipv6 default route in the VM

[fedora@vm-passthrough-macvlan1 ~]$ nmcli con show
NAME         UUID                                  TYPE      DEVICE
System eth0  5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03  ethernet  eth0

[fedora@vm-passthrough-macvlan1 ~]$ sudo nmcli con mod 5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03  ipv6.method dhcp       ip a

[fedora@vm-passthrough-macvlan1 ~]$ sudo nmcli con up 5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03

[fedora@vm-passthrough-macvlan1 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    altname enp3s0
    inet <IP_ADDRESS>/16 brd <IP_ADDRESS> scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fc00:f853:ccd:e793::140/128 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 fe80::8ed1:79b8:1ae6:ded/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

in virt launch pod
bash-5.1$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/ipip <IP_ADDRESS> brd <IP_ADDRESS>
3: eth0@if13: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 7a:64:93:ee:de:a3 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet <IP_ADDRESS>/16 brd <IP_ADDRESS> scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fc00:f853:ccd:e793::140/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::7864:93ff:feee:dea3/64 scope link
       valid_lft forever preferred_lft forever
4: veth0@if21: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether be:ee:2d:a7:37:01 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::bcee:2dff:fea7:3701/64 scope link
       valid_lft forever preferred_lft forever

bash-5.1$ ip -6 r
fc00:f853:ccd:e793::2 dev veth0 metric 1024 pref medium
fc00:f853:ccd:e793::/64 dev eth0 proto kernel metric 256 pref medium
fd33::5ef8:8f6e:729b:2fc0 dev veth0 metric 1024 pref medium
fd33::/64 via fc00:f853:ccd:e793::2 dev veth0 metric 1024 pref medium
fd41::/108 via fc00:f853:ccd:e793::2 dev veth0 metric 1024 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev veth0 proto kernel metric 256 pref medium
default via fc00:f853:ccd:e793::3 dev eth0 metric 1024 pref medium

It seems that the RA was ignored by the client for some reason.
Can you please attach the journal of the guest.

the previous VM has been restarted , I attach information of another VMI with same issue
launcher pod details
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/ipip <IP_ADDRESS> brd <IP_ADDRESS>
3: eth0@if13: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 26:ac:ad:91:76:96 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet <IP_ADDRESS>/16 brd <IP_ADDRESS> scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fc00:f853:ccd:e793::12f/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::24ac:adff:fe91:7696/64 scope link
       valid_lft forever preferred_lft forever
4: veth0@if22: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 5a:8c:8e:85:2e:b0 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::588c:8eff:fe85:2eb0/64 scope link
       valid_lft forever preferred_lft forever

VM details
[fedora@vm-passthrough-macvlan2 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    altname enp3s0
    inet <IP_ADDRESS>/16 brd <IP_ADDRESS> scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe12:3456/64 scope link
       valid_lft forever preferred_lft forever
[fedora@vm-passthrough-macvlan2 ~]$
[fedora@vm-passthrough-macvlan2 ~]$ ip -6 r
::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium

here is journctl log of guest vm : log.txt
BTW, I found another detail:
at the first minutes after VM is ready, the VM could get the right IPv6 address, but after a moment , it will disappear
[fedora@vm-passthrough-macvlan2 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    altname enp3s0
    inet <IP_ADDRESS>/16 brd <IP_ADDRESS> scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fc00:f853:ccd:e793:5054:ff:fe12:3456/64 scope global dynamic mngtmpaddr
       valid_lft 3453sec preferred_lft 3453sec
    inet6 fe80::5054:ff:fe12:3456/64 scope link
       valid_lft forever preferred_lft forever

[fedora@vm-passthrough-macvlan1 ~]$ sudo NetworkManager --version
1.22.10-1.fc32

[fedora@vm-passthrough-macvlan1 ~]$ nmcli  device show eth0
GENERAL.DEVICE:                         eth0
GENERAL.TYPE:                           ethernet
GENERAL.HWADDR:                         52:54:00:12:34:56
GENERAL.MTU:                            65520
GENERAL.STATE:                          100 (connected)
GENERAL.CONNECTION:                     System eth0
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/ActiveC>
WIRED-PROPERTIES.CARRIER:               on
IP4.ADDRESS[1]:                         <IP_ADDRESS>/16
IP4.GATEWAY:                            <IP_ADDRESS>
IP4.ROUTE[1]:                           dst = <IP_ADDRESS>/0, nh = <IP_ADDRESS>, mt = >
IP4.ROUTE[2]:                           dst = <IP_ADDRESS>/16, nh = <IP_ADDRESS>, mt =>
IP4.DNS[1]:                             <IP_ADDRESS>
IP6.ADDRESS[1]:                         fc00:f853:ccd:e793:5054:ff:fe12:3456/64
IP6.ADDRESS[2]:                         fe80::5054:ff:fe12:3456/64
IP6.GATEWAY:                            fe80::58e6:c3ff:fecb:eea8
IP6.ROUTE[1]:                           dst = ff00::/8, nh = ::, mt = 256, tabl>
IP6.ROUTE[2]:                           dst = fe80::/64, nh = ::, mt = 256
IP6.ROUTE[3]:                           dst = ::/0, nh = fe80::58e6:c3ff:fecb:e>
IP6.ROUTE[4]:                           dst = fc00:f853:ccd:e793::/64, nh = ::,>

the valid_lft of ipv4 address is forever, but the the valid_lft of ipv6 address is 3453sec. When valid_lft comes to 0 , the ipv6 address will  disappear and never show up again
ipv6.method of the connection is 'ignore' by default. if i set ipv6.method=auto , it will get a forever ipv6 address with 128 subnet length
[fedora@vm-passthrough-macvlan2 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    altname enp3s0
    inet <IP_ADDRESS>/16 brd <IP_ADDRESS> scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fc00:f853:ccd:e793::118/128 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 fc00:f853:ccd:e793:4936:93d1:8025:c348/64 scope global dynamic noprefixroute
       valid_lft 3588sec preferred_lft 3588sec
    inet6 fe80::1bad:9ebb:1b37:b970/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

/assign @AlonaKaplan

@sbrivio-rh shouldn't passt resend the routing info after the ttl expires?

but in my cluster with kubevirt v1.0.0 and dual-stack CNI, the VM with passt interface does not assign the ipv6 address
[...]
the default connection set ipv6.method to be ignore.

This is expected -- ignore configures NetworkManager to ignore router advertisements.

does it need to turn on dhcp for the connection ?

Not necessarily, you should set it to auto to get routes and an address with the same prefix as the one from the host via SLAAC.

I turn on the dhcp and the interface got wrong CIDR length , fc00:f853:ccd:e793::140/128

passt always assigns /128 addresses via DHCPv6, that's expected: we don't do prefix delegation, so we should assign exactly that address, and it needs to have priority over addresses assigned via SLAAC (which you can enable with auto instead).

@sbrivio-rh shouldn't passt resend the routing info after the ttl expires?

passt will send routing information via NDP on router solicitations, but if NetworkManager is not configured to accept them, this information will be ignored.

that sounds not reasonable.
firstly, the subnet length of pod interface is assigned by CNI plugin, why passt case modify ipv6 subnet length it to 128, that is not passthough effect. However, it just keep the ipv4 subnet length not modified. there is difference between ipv4 and ipv6
sencodly, when lauching the vm, the ipv6.method=ignore, why the interface could get an IPv6 address fc00:f853:ccd:e793::140/64 same with pod interface, but the later dhcp renew get fc00:f853:ccd:e793::140/128

passt will send routing information via NDP on router solicitations, but if NetworkManager is not configured to accept them, this information will be ignored.

Isn't the kernel reacting to these messages by default? NM runs its own implementation if enabled to do so (not in ignore mode).

the subnet length of pod interface is assigned by CNI plugin, why passt case modify ipv6 subnet length it to 128, that is not passthough effect.

If the guest learns about the gateway through RA, it will always have 128 as the subnet.
If the guest learns about the gateway through DHCPv6, it may set it to fit the address allocation information which has a subnet.

when lauching the vm, the ipv6.method=ignore, strangely , the interface could get an 64-length IPv6 address

You see this on the guest or on the VMI status?
If there is no DHCPv6 client, there is no way to know about the subnet per what I know.

firstly, the subnet length of pod interface is assigned by CNI plugin, passt case make ipv6 subnet length to be 128

That's unrelated to passt -- it's how DHCPv6 works (see RFC 8415).
In particular, note that the "Identity Association for Non-temporary Addresses Option" (section 21.4) has no field or suboption describing the prefix length: a DHCPv6 server assigns a specific address, and a DHCPv6 client will configure that address with 128 bits of prefix length, because it's a single address that's being assigned.
Sure, one could do prefix delegation with DHCPv6 (see section 21.21) but that's a different functionality. See also e.g. https://serverfault.com/questions/918472/why-is-a-128-ipv6-address-assigned-via-dhcpv6-in-ubuntu

However, it just keep the ipv4 subnet length not modified. there is difference between ipv4 and ipv6.

Indeed, DHCP has a subnet option (RFC 2132, section 3.3) but there's no equivalent in DHCPv6, for a simple reason: with IPv6, a subnet (not to be confused with a prefix length) is always identified by 64 bits.

This ipv6 behavior makes VM fail to directly access the underlay nework when underlay CNI such as antrea kube-ovn macvlan

Indeed, because DHCPv6 doesn't carry routing information -- you need NDP for that. Again, the NetworkManager method setting you want is auto. See also the discussion around this issue.

secocdly, when lauching the vm, the ipv6.method=ignore, strangely , the interface could get an 64-length IPv6 address

You get fe80::5054:ff:fe12:3456/64 which is a link-local address (and not fc00:f853:ccd:e793::140/64 as you wrote in the previous version of this comment -- that would be surprising!).

passt will send routing information via NDP on router solicitations, but if NetworkManager is not configured to accept them, this information will be ignored.

Isn't the kernel reacting to these messages by default? NM runs its own implementation if enabled to do so (not in ignore mode).

By default, yes, but NetworkManager will set the accept_ra sysctl parameter to 0 for a specific interface if method is set to ignore. If you don't want NetworkManager to interfere with the interface at all and let the kernel handle it, the interface needs to be added to the unmanaged-devices set (this is different from ignore).

If the guest learns about the gateway through RA, it will always have 128 as the subnet.

Not really, NDP allows specifying a prefix length (RFC 4861, section 4.6.2) and that's what the NDP implementation in passt does -- it will inherit the prefix length from the corresponding address on the host.

If the guest learns about the gateway through DHCPv6, it may set it to fit the address allocation information which has a subnet.

That only applies to Prefix Delegation (but then you would need to configure NetworkManager accordingly, and passt doesn't support the feature anyway).

You see this on the guest or on the VMI status? If there is no DHCPv6 client, there is no way to know about the subnet per what I know.

By the way, IPv6 (not v4-mapped) subnets are always described by 64 bits, see RFC 5375, section 3.

Also have a look at: https://networkmanager.pages.freedesktop.org/NetworkManager/NetworkManager/nm-settings-nmcli.html#nm-settings-nmcli.property.ipv6.method -- I hope this helps.

firstly, the subnet length of pod interface is assigned by CNI plugin, passt case make ipv6 subnet length to be 128

That's unrelated to passt -- it's how DHCPv6 works (see RFC 8415).
In particular, note that the "Identity Association for Non-temporary Addresses Option" (section 21.4) has no field or suboption describing the prefix length: a DHCPv6 server assigns a specific address, and a DHCPv6 client will configure that address with 128 bits of prefix length, because it's a single address that's being assigned.
Sure, one could do prefix delegation with DHCPv6 (see section 21.21) but that's a different functionality. See also e.g. https://serverfault.com/questions/918472/why-is-a-128-ipv6-address-assigned-via-dhcpv6-in-ubuntu

However, it just keep the ipv4 subnet length not modified. there is difference between ipv4 and ipv6.

Indeed, DHCP has a subnet option (RFC 2132, section 3.3) but there's no equivalent in DHCPv6, for a simple reason: with IPv6, a subnet (not to be confused with a prefix length) is always identified by 64 bits.

This ipv6 behavior makes VM fail to directly access the underlay nework when underlay CNI such as antrea kube-ovn macvlan

Indeed, because DHCPv6 doesn't carry routing information -- you need NDP for that. Again, the NetworkManager method setting you want is auto. See also the discussion around this issue.

secocdly, when lauching the vm, the ipv6.method=ignore, strangely , the interface could get an 64-length IPv6 address

You get fe80::5054:ff:fe12:3456/64 which is a link-local address (and not fc00:f853:ccd:e793::140/64 as you wrote in the previous version of this comment -- that would be surprising!).

passt will send routing information via NDP on router solicitations, but if NetworkManager is not configured to accept them, this information will be ignored.

Isn't the kernel reacting to these messages by default? NM runs its own implementation if enabled to do so (not in ignore mode).

By default, yes, but NetworkManager will set the accept_ra sysctl parameter to 0 for a specific interface if method is set to ignore. If you don't want NetworkManager to interfere with the interface at all and let the kernel handle it, the interface needs to be added to the unmanaged-devices set (this is different from ignore).

If the guest learns about the gateway through RA, it will always have 128 as the subnet.

Not really, NDP allows specifying a prefix length (RFC 4861, section 4.6.2) and that's what the NDP implementation in passt does -- it will inherit the prefix length from the corresponding address on the host.

If the guest learns about the gateway through DHCPv6, it may set it to fit the address allocation information which has a subnet.

That only applies to Prefix Delegation (but then you would need to configure NetworkManager accordingly, and passt doesn't support the feature anyway).

that is great, and easy to understand the detail
many thanks

If there is no further statement, I will close the issue


nuttx olimex-stm32-h407 Build using serial protocol

Hi,
I cannot build it for olimex-stm32-h407.
https://micro-ros.github.io/docs/tutorials/advanced/nuttx/add_microros_config/
Error is shown below;

The error is due to following settings.
Application Configuration > micro-ROS > Transport > Serial Transport
Application Configuration > Examples > microROS Publisher

How can I solve the issue?
Please advise me.
Thank you.
Regards,
Thiha Kyaw

Dear Pablo,
Thank you assigning person to help me. If you want me to test, let me know. I will quickly test it and give you results.
If you want to know how I test. I can give you the detailed test procedure also.
I would like to make the system work for my project as well.
Regards,
Thiha Kyaw

Dear All,
I retest using olimex-stm32-e407 board with serial protocol. I got the same kind of error. Therefore I assume the the serial protocol setting inside Nuttx  does have problem. Thank you.

In olimex-stm32-e407, the serial port is used for testing while transport setting is UDP protocol. If I want to use Ethernet connection for testing, please advise me how to set Ethernet for communication.
Thanks.
Regards,
Thiha Kyaw

@thihakyawjob Hi! Thank you for your interest in micro-ROS. Notice that we’ll discuss the recent contributions and developments in the next Embedded WG meeting. You’re invited to bring your micro-ROS related issue to this platform. We’ll be very happy to have you join us and discuss your questions with the community.

@thihakyawjob Hi! Thank you for your interest in micro-ROS. Notice that we’ll discuss the recent contributions and developments in the next Embedded WG meeting. You’re invited to bring your micro-ROS related issue to this platform. We’ll be very happy to have you join us and discuss your questions with the community.

Dear FranFin,
I will join the meeting.
Thanks.
Regards,
Thiha Kyaw

Good morning @thihakyawjob,
Good news! We fixed this issue during the release process of micro-ROS Foxy. You can find further information about the actual fix in this commit.
Remember to switch to branch foxy before testing, as it is not the default branch yet.
At the precise moment of writing this message, the micro-ros-build repository migration process to Foxy has not been completed yet, due to some errors for Raspbian build system which we are still fixing. Please check this pull-request and, if it has not been merged yet, switch to branch feature/foxy_migration instead.
Thanks!


create-kpt-functions does not work on M1

Hi 👋 I wasn't sure whether to mark this as a bug or a feature request, but given the increasing prevalence of M1 I opted for bug.
Expected behavior
The npm module create-kpt-functions should be usable on macOS arm64 architecture.
Actual behavior
The npm module create-kpt-functions isn't usable on macOS arm64 architecture (M1) because the precompiled typegen binary is not available for darwin_arm64.
Information
https://storage.googleapis.com/kpt-functions/v0.17.0/typegen_darwin_amd64.tar.gz is available, https://storage.googleapis.com/kpt-functions/v0.17.0/typegen_darwin_arm64.tar.gz is not. This leads to the following output when trying to run npm install in a project that has "create-kpt-functions": "^0.19.0" as a dependency:
npm ERR! code 1
npm ERR! path [..]/node_modules/create-kpt-functions
npm ERR! command failed
npm ERR! command sh -c go-npm install
npm ERR! Installation is not supported for this architecture: arm64
npm ERR! Invalid inputs

Since we're only using it as a dev dependency I can at least run npm install after removing the dev dependency – but I'm still locked out of any workflows relying on the binary.
Steps to reproduce the behavior

Use an M1 Mac
Run npm install in a folder with this package.json:{
  "name": "test",
  "version": "1.0.0",
  "devDependencies": {
    "create-kpt-functions": "^0.19.0"
  }
}

/cc @mengqiy @yuwenma

This is part of efforts in https://github.com/GoogleContainerTools/kpt/issues/2874

I took a look at it.
We need to restore something we removed in https://github.com/GoogleContainerTools/kpt-functions-sdk/pull/514. To be more concrete, we need to:

Restore the typegen related packages go/cmd/typegen and go/pkg/swagger. They should make typegen have its own module.
Restore the typegen release workflow release-typegen.yaml. Note that publish-bins.sh has been moved to ts/scripts/publish-bins.sh, so the last step needs to be updated.
Restore the build targets in go/Makefile and also add GOARCH=arm64.


sorbet: Update RBI files.

Autogenerated by the sorbet workflow.

@Bo98 hmm, something weird going on here, any ideas?

@Bo98 @MikeMcQuaid I think sorbet doesn't like the use of stub_const that was introduced in https://github.com/Homebrew/brew/pull/14418/files#diff-15f572e6ca51666d8e2c7be27c665e0e685a95e8028a295beea217f9151dcb16
Marking Library/Homebrew/test/patching_spec.rb as typed: ignore would work as an immediate band-aid (though it would be the only such file in the repo), as would reverting the PR. It might also be possible to convert the stub_consts into let statements instead. I can take a look when I have a bit more bandwidth available.

@dduugg Good catch, missed that, too many other PRs floating around in my head just now 😅. Reverting in https://github.com/Homebrew/brew/pull/14432 for now; we/you can test regenerating RBI files and running brew typecheck on whatever the new solution is. May just be worth using rubocop:disable there instead 🤷🏻

I think sorbet doesn't like the use of stub_const that was introduced in https://github.com/Homebrew/brew/pull/14418/files#diff-15f572e6ca51666d8e2c7be27c665e0e685a95e8028a295beea217f9151dcb16

Seems what Sorbet is complaining about is correct tbh. stub_const doesn't really make sense for something that's not actually stubbing an existing constant. Looks like it's defining something new which should be a let instead?


Maya/150460 status tags

Summary

What: Add status tags for phylo trees
Ticket: [sc150460]
Env: https://statustags-frontend.dev.genepi.czi.technology

Testing

Open trees pages
Ensure each tree has a status tag next to it representing the status of the build
Three types available: Complete, failed, and started

Demos

Checklist

[x] I merged latest feat/filtering
[x] I manually verified the change
[x] I added labels to my PR
[ ] I tested in multiple browsers
[ ] I added relevant unit tests
[ ] I have notified others of changes they need to make locally (migrations, jobs, package updates, etc)

@mmmmmmaya Looks great! Only comment is on the tag names:

"completed" --> "complete" (consistent with sample statuses)
"started" --> "in-progress" (unless you've heard otherwise, since i think the ticket noted the label as TBD)

Thanks!!


MiniKeys sequencial bruteforce hash an ERR

I try to run MiniKeys mode with base key
example : S7AfhgDK111111111111
the program is working well until
program run through   S7AfhgDK11111111zzzz
it never change next position to number 2
it loop to  S7AfhgDK111111111zzz again
i try many use case , sometime it pass to position 6 and then loop

can you share the full comant that you use?


Bump Jörmungandr to v0.8.5-alpha1

Issue Number

Overview
Like #1213 :

[x] I have bumped Jörmungandr to ~0.8.4~ 0.8.5-alpha1
[x] I have re-generated arbitrary blocks
[x] I have updated the README compat matrix

Comments

bors try

bors r+


Fix tree building when using specific countries

A fix for the problem specified in #46.
The tree was being rebuilt for every country so it only had the data of the last country in the list.
This change will aggregate the data from all of the countries using async.parallel
and build the tree once after the files finished downloading and parsing.
I increased the minimum Node.js version (and appropriate NPM version) because of the use of .flat()

Sure :)


Ensure all preview features are always spelled in purely lowercase letter

Based on this internal convo:

For example, nApi should always be spelled as napi.

Never mind 😌


Add exclude-limit option

Rubocop has an --exclude-limit option to limit how many individual files --auto-gen-config can list in Exclude parameters, default is 15. We have just introduced the 15 limit and it would be nice to allow people to set the value as they prefer.
This is probably not a priority, but something nice to have. :wink:

I agree that it is valuable; this is a Rubocop config option we use to prevent new files from being allowed to inherit old bad practices, without having to change all old files. With the new behavior, whenever we regenerate the .haml-lint_todo.yml file, we have to do a lot more work to restore it to a more restrictive setting.

For anyone looking for a workaround:
You can run bundle open haml_lint, then edit lib/haml_lint/reporter/disabled_config_reporter.rb to change the limit from 15 to a higher value.

--auto-gen-exclude-limit, in haml-lint 0.36.0, worked for me.
haml-lint --auto-gen-config --auto-gen-exclude-limit 500

Perhaps this can be closed?

Good call out—thanks for noticing!


[UA-7637] Restrict length of URL params

We're not capturing full length URLs in the data platform (or at the very least, we should not be). Some URLs passed to us contain crypto blocks of thousands of characters, others contain base64'd information. All of this adds to a significant amount of storage. We've decided to limit maximum URL length to 128 characters for now. If this is not enough, upping this value will be trivial.
This change amends an a existing processing step to truncate URLs if they are longer than 128 characters on known events. Tests were added to both analytics.spec.ts (for classic) and simpleanalytics.spec.ts. This will not impact events other than view, click, search, custom or collect (dl,dp,dr).
Extra additions:

Typescript type fixes
Adding version to package name, so it's easier to identify which package is deploying in Spinnaker.

Truncating the URLs mean that some events will be rejected on UA (because on Collect we validate that fields are valid URLs). Are we okay with that?

Truncating the URLs mean that some events will be rejected on UA (because on Collect we validate that fields are valid URLs). Are we okay with that?

I'm going to take a bit of a guess, but I don't think it's possible to truncate a valid URL and have it not be a valid URL, unless you start clipping into the schema.

Truncating the URLs mean that some events will be rejected on UA (because on Collect we validate that fields are valid URLs). Are we okay with that?

I'm going to take a bit of a guess, but I don't think it's possible to truncate a valid URL and have it not be a valid URL, unless you start clipping into the schema. Even a . at the end of a host is valid apparently.

OK so effectively instead of validation errors we would have HTTP 400s instead? We're okay with this?

Truncating the URLs mean that some events will be rejected on UA (because on Collect we validate that fields are valid URLs). Are we okay with that?

I'm going to take a bit of a guess, but I don't think it's possible to truncate a valid URL and have it not be a valid URL, unless you start clipping into the schema. Even a . at the end of a host is valid apparently.

You could in theory validate client side that the truncated value is still a valid URL using this: https://developer.mozilla.org/en-US/docs/Web/API/URL
ie:
try {
   new URL(truncatedValue)
} catch (e) {
    // I'm not sure what kind of recovery we'd want to do here.
    // Just an error message informing the user that they'll never be able to see those events in our platform ?
}


Spin-polarised projected bands not possible

when using:
sumo-bandplot --project
for a spin-polarised system, you can't get the spin-up and spin-down components plotted separately unless using --spin 1 or --spin -1 to get 2 separate plots.
I think it could be nice to have the linestyle plotted as solid and dashed lines respectively.
This is also the case with the --dos option which only returns the spin-up or down and not both or combined into one as it does with the band structure.
illustrations:
with sumo-bandplot --project Fe.d,Cl.p --dos ./vasprun.xml

with just sumo-bandplot --dos ./vasprun.xml

actually on closer inspection in sumo.bs_plotter.SBSPlotter.get_projected_plot it seems that in line 609 that the option is there:
ls = "-" if spin == Spin.up else "--"
and then applies that to LineCollection however it doesn't seem to end up in the final plot


fix: app version

:tada: This PR is included in version 1.4.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


⚠ SceneTime has degraded performance

In 66a24a1, SceneTime ($ST) experienced degraded performance:

HTTP code: 200
Response time: 1586 ms

Resolved: SceneTime performance has improved in c20c41e after 6 minutes.


[DEPR]: Shifting edX-app-ios to openedx-unsupported + Updated documentation

Proposal Date
2023-10-02
Target Ticket Acceptance Date
2024-02-01
Earliest Open edX Named Release Without This Functionality
Redwood - 2024-04
Rationale
This ticket is a result of OEP-64, where we ratified the adoption of new code bases for both the iOS and Android mobile applications.This DEPR ticket kicks off a conversation with all involved parties to ensure all mobile app repository documentation/readme details make clear the support level for this repository.
After this change, we hope new open edx community members will be encouraged to contribute to the new mobile repositories.
Removal
This codebase is shifting to no longer be the primary Open edX iOS mobile app, starting with the Redwood named release is our target. The organization of this repo will shift from openedx to openedx-unsupported when this ticket is resolved.
Replacement
The new iOS repositoriy is located here: https://github.com/openedx/openedx-app-ios
Deprecation
1 - Updated documentation / readme details to be coordinated with @openedx/edx-mobile-admin regarding this shift
2 - Eventual github org shift (presumably to be handled by Axim github admins) for this repo to the openedx-unsupported github organizaiton.
Migration
We will be looking at migration path for interested community members via - https://github.com/openedx/openedx-app-ios/issues/99
Additional Info
Please feel free to ask questions about this here or in #wg-product-mobile on slack!

@moiz994 - I will try to take a pass next at identifying some tasks for this ticket regarding this DEPR ticket, and once we feel like we have the right list of things we can echo this in the Android ticket as well after you've had time to review

@marcotuts I moved this back into Proposed so that we could get a more official deprecation announcement to let people know this is happening. Could you follow the steps listed in the deprecation OEP? https://open-edx-proposals.readthedocs.io/en/latest/processes/oep-0021-proc-deprecation.html#communicated

Thanks for flagging @dianakhuang  - I will make sure to review the process in more detail, I'm not sure what happened last time I read this document, but I cannot find the discourse post. fixing asap.

Discourse post announcing deprecation: https://discuss.openedx.org/t/deprecation-removal-edx-mobile-ios-edx-mobile-android-https-github-com-openedx-edx-app-ios-issues-1804-1804/12430


Package version mismatch on npm and github

I have an issue with source code
when I download it from npm it shows different code and when i clone from github it shows different code

npm contains the code after build (dist path)
example https://github.com/Jamaks/ng-fullcalendar/tree/1.4.4-local-fix-fullCalendar-not-found/dist


New horizons branch issue: vocabulary tag names unnecessarily use _

I realize you changed this recently and now I realize why it caused headache.
But maybe there's an easier way of doing this. The problem is that we're using these as variables (e.g., voc.foo.one_entry) when we really should be treating them all as data, e.g., voc["foo"]["one-entry"].

Moved back to the native "-" based names. Works now.


fix: the vite template does not has npm script for production

Types of changes

[ ] New feature
[x] Bug fix
[ ] Documentation change
[ ] Coding style change
[ ] Refactoring
[ ] Performance improvement
[ ] Test cases
[ ] Continuous integration
[ ] Typescript definition change
[ ] Breaking change

Background and context

Solution
Close: #45

How is the change tested?

Changelog

Changelog(CN)
Changelog(EN)
Related issues

Checklist:

[ ] Provide changelog for relevant changes (e.g. bug fixes and new features) if applicable.
[ ] Changes are submitted to the appropriate branch (e.g. features should be submitted to feature branch and others should be submitted to master branch)

Other information

感觉就是个kpi项目。自己搭起了后台管理框架，看到了arco pro 结果.......一言难尽


Deprecation warnings in React 15.5

React 15.5 will now issue deprecation warnings on using createClass and proptypes. These are now available as standalone packages here:
https://www.npmjs.com/package/prop-types
https://www.npmjs.com/package/create-react-class
More details from the React blog: https://facebook.github.io/react/blog/2017/04/07/react-v15.5.0.html
The upgrade looks to be really straightforward, I can make a pull request for this if that would be preferable :)

@samelliottdlt you can make pull request.


Use floor temperature if temperature measurement is floor sensor (Support Elko Super TF Thermostat)

Issue
Hi! Thank you for a wonderful plugin.
I was wondering if you could add support for reporting temperature using floor temperature if the temperature measurement is done using the floor sensor for the Elko Super RF Thermostat.
Here is an example of the sensor information as reported by the deCONZ REST-API:
{
"config": {
"heatsetpoint": 2500,
"locked": false,
"mode": null,
"offset": 0,
"on": true,
"reachable": true,
"temperaturemeasurement": "floor sensor"
},
"ep": 1,
"etag": "31921b7fe84c562bbee8074187212d28",
"lastseen": "2021-08-04T18:07Z",
"manufacturername": "ELKO",
"modelid": "Super TR",
"name": "Thermostat",
"state": {
"floortemperature": 2550,
"heating": false,
"lastupdated": "2021-08-04T18:07:24.190",
"on": true,
"temperature": 2290
},
"type": "ZHAThermostat",
"uniqueid": "00:0d:6f:00:0f:41:4e:3d-01-0201"
}
Basically I want Characteristic.CurrentTemperature to be mapped from state.floortemperature if config.temperaturemeasurement is "floor sensor" or else from state.temperature. This may be exclusive logic for the given combination of manufacture name and model id.
Obviously it would be best if the mapping is dynamically updated in accordance with an updated type of temperature measurement, i.e. be mapped from either floor temperature or temperature when this is updated on the thermostat. But I am more than happy if the type of floor measurement is only evaluated when starting the plugin.

Shouldn't that be handled by deCONZ?

I guess you can make that argument.
My understanding from the discussion of extending the support for the thermostat in the rest-api, was that they deliberately decided against it because of compatibility with other home automation systems.
From a HomeKit perspective my opinion is that the currentTemperature characteristic should use temperature from the sensor that is actively deciding if the thermostat should be heating. Of course this could also be a separate characteristic (which I believe was the compatibility need for other home automation system to keep this separate in the api), but this would not be available in the Apple Home App since that is adhering strictly to the characteristics of a thermostat per the HAP-specification.

From a HomeKit perspective my opinion is that the currentTemperature characteristic should use temperature from the sensor that is actively deciding if the thermostat should be heating.

But that has nothing to do with HomeKit.  You want state.temperature to reflect the temperature used by the thermostat.

Of course this could also be a separate characteristic (which I believe was the compatibility need for other home automation system to keep this separate in the api), but this would not be available in the Apple Home App since that is adhering strictly to the characteristics of a thermostat per the HAP-specification.

The proper way to expose this in HomeKit would be a separate Temperature Sensor service for state.floortemperature.  It would need to be exposed on a separate accessory, or Eve history would break.  I’m not sure if I can get Homebridge Hue to expose two different services/accessories from the same resource, though.

My understanding from the discussion of extending the support for the thermostat in the rest-api, was that they deliberately decided against it because of compatibility with other home automation systems.

What’s the deCONZ issue for this discussion?

Initial support for the Elko Super TR thermostat was added following issue 1291. Support for the floor sensor was added following issue 3123. If you see comment 699442563 from arnerek, he is basically proposing handling this directly in the API (which you and I also would have preferred), but then after some consideration they seem to land on exposing different sensors in the API as seen in comment 699691385 by SwoopX.
My view is that the temperature reported in the thermostat service should be mapped to the sensor deciding the boolean state of the heating. So since this is not handled in the API (which I agree it should), I hope that we can amend this in the "Homebridge-layer".

I hope that we can amend this in the "Homebridge-layer".

I really don't want to maintain a Homebridge "layer" with functionality.  In my view, Homebridge plugins should expose devices to HomeKit, mapping native attributes and commands to their HomeKit equivalents.  Any special functionality should be handled in the device or in HomeKit automations.
As you indicate, the mapping of the reported temperature to the sensor, based on the state of the heating, is a generic device feature, not specific to HomeKit.

I created issue 5208 in the deconz-rest-plugin repository to follow up this. Thank you for your clear stance on this in the discussion of issue [3123] (https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3123).

Closeing this for now.  Please re-open or create a new issue when deCONZ has been updated.


[DCOS-54125] Add configs to enable secure JMX for Cassandra

What changes are proposed in this PR?
Resolves DCOS-54125
Add configs to enable secure JMX for Cassandra

@zmalik not sure why com.sun.management.jmxremote.ssl.config.file is not working, i had to directly put config values in cassandra-env.sh, i will remove that part from jmx-ssl-properties.sh.


Update OSX install instructions.

It wasn't specified what this file was supposed to be edited to. And it had already been used to install, so this would be too late to do it. And it works without it.

Good to know. I haven't been using OSX for some time now. Thanks!


Add advanced pane

Can select gpu state with no checks
Dump full state of current gpu
Manually input gpu state values to see what it spits out.

added


pip install issue

Pip install issue as my existing pyYAML is 5.1.2 and your reqs require ==5.1

fixed by deinstalling pyyaml the time of install


Metrics Definitions @id formats need to be corrected to use format:uri

What are the schemas that are affected by the issue
data/{metricDefinitions*}
What are examples of products that are impacted by the issue
none
Metrics Definitions @id formats need to be corrected to use format:uri. They currently do not.

@lrosenthol - This is to track correcting the metric definition schemas to have the correct @id formats.


static vs. dynamic memory allocation

Because the openiolink library is used for hardware a big part of the relations between the objects are static by nature. These objects are created once (at the "beginning" of the software) and then live until the software is terminated (or simply the power is turned off). This allows us to reduce the use of dynamic memory allocation or even avoid it at all!
Also refer to #19 .

Keep in mind that case an user wants to start the IO-Link master from within a thread in his/her software (and not from main()), he/she must give it enough stack space (for all those"static" objects).


Artifact the protodata- prefix to published artifacts

This PR updates the publishing settings to add protodata- to the names of the published artifacts (addressing #54).

Got build failure on CI, while locally it passed. Going to look into this later today.


Implement Linear Systems and Control Subpackage

I'd like to implement some techniques from classical linear control for learning and reference. This issue should only be concerned with SISO systems—MIMO systems and nonlinear extensions can be left to additional exploration. Of primary interest are

[ ] State space simulation using RK4Integrator
[ ] Laplace Transform into frequency response (continuous time)
[ ] Z Transform into frequency response (discrete time)
[ ] Bode plots
[ ] Root Locus plots
[ ] Pole placement control design
[ ] PID control design

Aside from physical textbooks that I have lying around, see https://lpsa.swarthmore.edu/

Still need to implement timing on Signals/Blocks, notion of sample times in some simulator running things.


Using of 𐑼 in 'library' 𐑤𐑲𐑚𐑮𐑼𐑦 and 'dictionary' 𐑛𐑦𐑒𐑖𐑩𐑯𐑼𐑦

Its using totally corresponds with the pronunciation, but I find it unnatural to use 𐑼 here.
The word naturally splits into syllables, in this case 'laɪ-brə-ri' and 'dɪk-ʃə-nə-ri'. When we spell word like 𐑤𐑲𐑚𐑮𐑼𐑦 instead of 𐑤𐑲𐑚𐑮𐑩𐑮𐑦 and 𐑛𐑦𐑒𐑖𐑩𐑯𐑼𐑦 instead of 𐑛𐑦𐑒𐑖𐑩𐑯𐑩𐑮𐑦, it breaks this logic and we cannot split the word up into syllables anymore, because they are now merged together in this letter.
The similar issue is already mentioned in an 'affix rule', but I suggest it to be extended to 'syllable rule'.
I suspect that it would require much effort to fix and it likely affects much more words than these two (and other compound letters). And maybe it's the matter of taste, so I just raise a question to discuss.

Yes, and one more thing, compound letter were created to avoid the spelling differences for speakers of rhotic and non-rhotic accents. So a compound letter implies an optional /r/-sound that can be omitted in RP and other non-rhotic accents. In case I mentioned, this /r/ can't be omitted and it's meaningful, so I feel that we should use 2 letters instead of a compound one.

I want to neither oppose nor support your proposal, but

So a compound letter implies an optional /r/-sound that can be omitted in RP

You are mistaken here. When I first learned about Shavian I also thought this is the case, but it is not. Despite being sometimes called separate letters by Kingsley and others (and mistakenly being encoded as such in Unicode), all the r-compounds are used like purely typographic ligatures orthographically equivalent to the sequences of their constituent parts. Consider for example 𐑓𐑹𐑩𐑥 forum or 𐑜𐑤𐑹𐑦 glory which were spelled this way in Androcles, or even the keyword 𐑼𐑱 array itself. Choice of which letters have ligatures was clearly driven by dialectical differences, but that's about it. It seems to be true that, at least statistically, if the 𐑮 is dropped, then it is a part of a ligature, but converse is demonstrably false. Ligature is always used no matter whether or not the 𐑮 is pronounced in non-rhotic dialects.
Of course, this doesn't preclude having typographic rules about when to use and when to refrain from using ligatures. The rule used in practice is similar to the one used in Fraktur. Avoiding ligatures across certain morpheme boundaries makes a word with a suffix look like a word with a suffix, which is nice. I think it also helps with hyphenation across line breaks.
As for syllables, consider that there is a lot of disagreement how to properly divide English words. The most commonly followed maximal onset principle puts a syllable break right in the middle of the 𐑼 ligature in the word 𐑼𐑱 (𐑩.𐑮𐑱) which was the keyword given in Androcles' tables for that ligature. American dictionaries don't follow this principle and say the syllables are lī-brĕr-ē and dĭk-shə-nĕr-ē (in AHD respelling) so neither of those 𐑼 in library and dictionary is at syllable break according to them.
Additionally, the word dictionary has just three syllables in RP. Cambridge 17th ed. gives it as a second pronunciation: ˈdɪk.ʃᵊn.ᵊr.i, -ʃᵊn.ri. Note how all these schwas are marked optional so even in pronunciation with 4 syllables that 𐑩 might just be there to mark syllabic 𐑮 rather than an actual schwa sound. Orthographic lawyering aside, it surely makes sense to join it into single 𐑼 compound then, right?

I can't really put it any better than @mwgamera. The disagreement between dialects about where syllable breaks actually are is the clincher for me; rhotic speakers and non-rhotic speakers tend to have very different instincts about this.
It would therefore further increase the memorisation requirements to make the distinction on a syllable-by-syllable basis. I developed the affix rule because this seemed to reflect what Kingsley Read did in practice (although I haven't found anywhere where he described it), and because there were a few edge cases where the absurdity was obvious, like 𐑦𐑯𐑓𐑮𐑼𐑧𐑛, versus 𐑦𐑯𐑓𐑮𐑩𐑮𐑧𐑛.


Swift 4.2

Please update to swift 4.2, we have the same dependcy. we need to update our app to swift 4.2, but having dependancy with this library. So please do the needful

Would also be nice to have a 5.x release of swift 4.2


bug: running through https://docs.kubestellar.io/main/direct/examples/ yields several errors and issues

Describe the bug

according to instructions at https://docs.kubestellar.io/main/direct/examples/ - I ran init

(first error) then, according to instructions, I installed add-ons - command line does not copy and paste correctly on a Mac...

instructions have
kubectl apply -f https://raw.githubusercontent.com/kubestellar/kubestellar/v${KUBESTELLAR_VERSION}/config/postcreate-hooks/kubestellar.yaml
kubectl apply -f https://raw.githubusercontent.com/kubestellar/kubestellar/v${KUBESTELLAR_VERSION}/config/postcreate-hooks/ocm.yaml

when pasting this to a Mac terminal session with .zsh as shell...
kubectl apply -f https://raw.githubusercontent.com/kubestellar/kubestellar/v$\{KUBESTELLAR_VERSION\}/config/postcreate-hooks/kubestellar.yaml
kubectl apply -f https://raw.githubusercontent.com/kubestellar/kubestellar/v$\{KUBESTELLAR_VERSION\}/config/postcreate-hooks/ocm.yaml

note the \ escape character added on copy to the terminal from webpage

(2nd error) - When running next step in instructions 'kflex create its1 --type vcluster -p ocm' I get "Error getting client: error building kubeconfig: invalid configuration: [context was not found for specified context: kubeflex, cluster has no server defined]"

I looked at the kflex help and I see an option to 'delete' but I do not see an option to list what control planes exist so that I can delete one.

(3rd issue) - why isn't the list of instructions for kind listed under the link for "KubeStellar on Kind"?
(4th issue) - why isn't the list of "KubeStellar on..." listed as links/next steps in the bottom of the page for "Setting up KubeStellar" - this turns into a dead end for users.
(5th issue) - common commands for operations are different on the example page as they are for the k3d page.... Example: kubectl --context its1 api-resources | grep managedclusteraddons || true is on the example page and in the kid page it is an inline command with a shell prefix:
". Install OCM status addon First wait until managedclusteraddons resource shows up on its1 using: shell kubectl --context its1 api-resources | grep managedclusteraddons then install status addon:"

there should be consistency between instruction sets.
Steps To Reproduce
see above
Expected Behavior
I would like to get KubeStellar installed on a kind cluster.
Additional Context
No response

@clubanderson : FYI, https://github.com/kubestellar/kubeflex/issues/159

I just tried cut-and-paste from step 5 of https://docs.kubestellar.io/main/direct/examples/#common-setup, viewed with Firefox 125.0.1, into a Terminal window running zsh on my MacOS 14.4.1 MacBook. I clicked on the copy icon in the source window. I then pasted into my Terminal window and hit return. It worked, no spurious escaping. I then demonstrated which shell I am using. It looks as shown below.

@clubanderson: I am not sure what you are saying you did after the first error. Did you simply proceed without any recovery? I tried running through the setup instructions skipping step 5 (to simulate your first problem), and step 6 succeeded. OTOH, I also started from scratch and skipped directly to step 6 (omitting creation of the kubeflex hosting cluster), and that produced the error message that you showed above. But I do not see how a user forllowing the instructions would do that.

@clubanderson, regarding your 4th issue: can you please elaborate on what you mean by 'the page for "Setting up KubeStellar" '? I am having trouble finding such a page. I can find a non-leaf node of that name in the navigation tree, and its children seem to be what you are asking for (see the screen snip below). So I am a bit confused.

@clubanderson, regarding your 3rd issue, and maybe your 4th: there is some incomplete editing of the website in progress. In fact, I think we do not even have a consensus on what the result should look like. The last change anticipated distinct setup and distinct cleanup instructions for each kind of hosting environment, but some of us think that this would be bad because it obscures the underlying unity and does make it clear how the user adapts to yet another hosting environment.

@clubanderson: I suspect that #2074 may have contributed to the difficulty here, by making problems cascade in a non-obvious manner.

all I am pointing out here is that a) the instructions should be consistent for things like checking or applying, etc., and b) there should be a top-level intro to install that links to the other pages, not just relying on the tree itself. I also think there is an issue with copy (from safari) and paste (to zsh) on Mac for parameters in the docs.

"setting up kubestellar" is what people click on. No content is shown, just a tree of pages appears.

With a wide window, Firefox 125.0.2 on MacOS: clicking on the "Setting up KubeStellar" vertex in the navigation pane on the left side of the web page exposes or hides the list of its child vertices --- in the navigation pane. Such clicks make no change in what is displayed in the main content part of the web page.
As far as I can tell, this is ordinary behavior for the navigation pane. I see it for the "Contact us" and "Partners" vertices (under "Community") as well.


Adapting this implementation of PPO for DeepMimic

Hello,
I wanted to ask if you think it would be feasible to adapt this implementation of PPO using stable_baselines to DeepMimic. If so, which are the main differences in the learning algorithm?
By reading both papers, it didn't look like there were major differences in the PPO implementation, apart from the reward functions.
Is there any specific reason why you decided to use PPO1 instead of PPO2?

This implementation is using stable baselines.


PFM-1352:: Hindi Input UI Validations

@Ramkrishna-egov  Commit   should have a specific  message.


Source corrupted

one texture is corrupted 7zip and rar is not working to extract.

Hey.
Which texture exactly is corrupted and which archive?

If archive is Bomber build from release page, you can find it has 2 parts, so both of them have to be downloaded first, then extracting .zip.001 will automatically extract zip.002 as well. I just did it it and was able to run extracted build with no issues:

if archive is repo downloaded from GitHub as zip, then download it from git terminal instead through SSH (read readme and Issue).

I just recorded a video showing the downloading, extracting and running the game. Please see it here: video
If the issue still occurs on your side, feel free to reach out to me on Telegram (t.me/JanSeliv), and I will give you the key on Steam from our private page.

i'm not downloading the client the Source code un ziping the source code (zip) second screenshot mark with red
I now the client works

Source code (zip) is something that GitHub automatically adds to each Release. As developer, I don't have this archive included as well as I can't remove it from there.
I suspect, it attempts to download the whole repository but fails on limit of zip size, so you have archived corrupted.
Any Release page is designed to provide builds (clients) to other developers. While the source (project itself) you have to download in normal way: from git clone command as mentioned in readme


[BUG]: Remove mutex locks from interceptors on method calls

Bug Description
The mutex locks in interceptors on method calls are stale and should be removed to improve performance.
Logs
The mutex locks in interceptors on method calls are stale and should be removed to improve performance.
https://github.com/dell/csi-powerscale/blob/15e14791d2f076902c204b1c8d4304d6be15d7b3/service/interceptor/interceptor.go#L150
Screenshots
No response
Additional Environment Information
No response
Steps to Reproduce
https://github.com/dell/csi-powerscale/blob/15e14791d2f076902c204b1c8d4304d6be15d7b3/service/interceptor/interceptor.go#L150
Expected Behavior
mutex calls should be removed if they are stale from the method calls
CSM Driver(s)
csi-powerscale
Installation Type
No response
Container Storage Modules Enabled
No response
Container Orchestrator
k8s
Operating System
RHEL

We can close this issue as the fixes has been merged.


DisableAutoCompaction Bug - Entry compacted error

Dragonboat gives an option to DisableAutoCompaction.
In my setup running I am running with 1 nodehost which manages 2 shards. Data is committed to one shard and I am using Nodehost GetLogReader function to read the  logs and propose to second shard.
I have disabled auto snapshotting and compaction by setting Snapshot entries value as 0and DisableAutoCompaction as true.
I am creating manual snapshots by using RequestSnapshot of nodehost
Additionally I am keeping track of how many entries I have read from log in one variable. The problem here is even if I have disabled auto compaction by setting the field compaction is triggered when the nodes gets restarted , and If I still haven't read some entries from log, program throws "Entry Compacted" error.
Dragonboat version -- 4.0
Expected behavior
Since AutoCompaction is disabled, compaction should not occur
Actual behavior
Entries are getting compacted from log during node restart
Steps to reproduce the behavior

Run a 3 node cluster
Set config described above
Set DisableAutoCompaction to true
Send some entries
Create manual snapshot using RequestSnapshot - eg after 5 minutes and 100 entries are there in snapshot with compactionIndex as 10 , OverrideCompactionOverhead as true
Try to read entries from logreader entries before 10

The problem here is even if I have disabled auto compaction by setting the field compaction is triggered when the nodes gets restarted

This is expected. dragonboat manages its own log, it determines when it is okay and safe to delete them. As clearly explained by the docs, DisableAutoCompaction is used to request dragonboat not to perform automatic compaction immediate after taking a snapshot. This is to allow users to pick more suitable times to run compactions for performance reasons only.  It doesn't imply anything on whether dragonboat is still allowed run compactions - the library owns & manages its own log, it is always allowed to make compactions.
Another big problem is the GetLogReader method - I have the feeling that allowing direct access to the log might be a little bit immature, there are just corner cases when GetLogReader is used. DisableAutoCompaction and GetLogReader probably give you the false feeling that there is a way to get full control on the logs. Sorry, but that is never the plan.
I'd like to know why you need to use GetLogReader in the first place. Thanks.

Ok, Thanks for clarification.
So my understanding was that leader log reader also holds the committed entries and is guaranteed to be present in state machine ( I am using IOnDiskStateMachine) . So we can get these entries from leader's  logreader also. Is this correct?

So we can get these entries from leader's logreader also. Is this correct?

As a part of the ongoing efforts to get v4 released, I am planning to remove the log reader. Directly exposing the internal log to the application is very bad idea. I shouldn't have accept that PR for adding that in the first place.
For your application, if you need to somehow get repeated or random access to the log, you can always sequentially record all those log entries whenever your Update method is called. You can then have full control of the copy you maintain.

This is expected. dragonboat manages its own log, it determines when it is okay and safe to delete them. As clearly explained by the docs, DisableAutoCompaction is used to request dragonboat not to perform automatic compaction immediate after taking a snapshot. This is to allow users to pick more suitable times to run compactions for performance reasons only. It doesn't imply anything on whether dragonboat is still allowed run compactions - the library owns & manages its own log, it is always allowed to make compactions.

So it's safe to assume that the option, CompactionOverhead, doesn't prevent dragonboat from compressing, it simply doesn't compress immediately upon saving the snapshot right?