error on thermostat accessory var update_char_iid = update_char["iid"];

Trying to test the thermostat_accessory and it gives me an error when I try and speak with Siri to adjust the temperature. This is what I get. I'm using the thermostat_accessory.js file as it was originally so I haven't modified it.
/root/HAP-NodeJS/AccessoryController.js:52
var update_char_iid = update_char["iid"];
^
TypeError: Cannot read property 'iid' of undefined
at Object.processCharacteristicsValueWrite (/root/HAP-NodeJS/AccessoryController.js:52:36)
at Object.responseCharacteristic (/root/HAP-NodeJS/Server.js:112:29)
at IncomingMessage. (/root/HAP-NodeJS/Server.js:53:17)
at IncomingMessage.emit (events.js:95:17)
at IncomingMessage. (stream_readable.js:764:14)
at IncomingMessage.emit (events.js:92:17)
at emitReadable (_stream_readable.js:426:10)
at emitReadable (_stream_readable.js:422:5)
at readableAddChunk (_stream_readable.js:165:9)
at IncomingMessage.Readable.push (_stream_readable.js:127:10)
If I manually go into the thermostat in the iOS app and click on the target temp field it lets me set the target temp and it works and shows up in the log.
Any ideas?
I tried searching but this error doesn't look like it's come up before, maybe a syntax problem or  one of my files have a typo?
Sorry to keep bothering you, I really appreciate all the help :)

Im having this issue as well but I don't think this solution is working for me.
Relevant part of the thermostat accessory:
    cType: types.TARGET_TEMPERATURE_CTYPE,
    onUpdate: function(value) { console.log("Change:",value); execute("Thermostat", "Target Temperature", value); },
    perms: ["pw","pr","ev"],
            format: "int",
            initialValue: 75,
            supportEvents: false,
            supportBonjour: false,
            manfDescription: "Target Temperature",
            designedMinValue: 68,
            designedMaxValue: 82,
            designedMinStep: 1,
            unit: "fahrenheit"
},{
    cType: types.TEMPERATURE_UNITS_CTYPE,
    onUpdate: function(value) { console.log("Change:",value); execute("Thermostat", "Unit", value); },
    perms: ["pr","ev"],
            format: "int",
            initialValue: 1,
            supportEvents: false,
            supportBonjour: false,
            manfDescription: "Unit",
}]

}]
}
When I change the value for target temperature from the accessory screen it works, but when I try and set it using a command from siri like "Set Thermostat to 78" or "Set Thermostat to 78 degrees Fahrenheit" I get the following error:
/var/HAP-Nodejs/AccessoryController.js:52
var update_char_iid = update_char["iid"];
^
TypeError: Cannot read property 'iid' of undefined
at Object.processCharacteristicsValueWrite (/var/HAP-Nodejs/AccessoryController.js:52:36)
at Object.responseCharacteristic (/var/HAP-Nodejs/Server.js:112:29)
at IncomingMessage. (/var/HAP-Nodejs/Server.js:53:17)
at IncomingMessage.EventEmitter.emit (events.js:95:17)
at IncomingMessage. (stream_readable.js:746:14)
at IncomingMessage.EventEmitter.emit (events.js:92:17)
at emitReadable (_stream_readable.js:408:10)
at emitReadable (_stream_readable.js:404:5)
at readableAddChunk (_stream_readable.js:165:9)
at IncomingMessage.Readable.push (_stream_readable.js:127:10)
I think I should have everything configured to be using fahrenheit (siri is set to US english, the unit type is set to 1, and the unit for target temp is set to fahrenheit). Anything I'm missing here?

The only way I was able to get it to work and respond properly with the fahrenheit commands is to have Celsius in there and Siri converts it automatically, so I can say set the thermostat to 70 degrees and she responds "setting the thermostat to 70 degrees"
My solution is a little different than yours but it works. Heres a sample of what I'm using.
I converted the values to Celsius and it took a while of trial and error but it works like this.
I'm in the US so I have my iPhone set to US English as well.
cType: types.CURRENT_TEMPERATURE_CTYPE,
	onUpdate: function(value) { console.log("Change:",value); execute("Thermostat", "Current Temperature", value); },
	perms: ["pr","ev"],
	format: "int",
	initialValue: 18.333,
	supportEvents: false,
	supportBonjour: false,
	manfDescription: "Current Temperature",
	unit: "celsius"
},{
	cType: types.TARGET_TEMPERATURE_CTYPE,
	onUpdate: function(value) {

target = "18.333";
if (value === 18.333) {target = "65";};
if (value === 18.888) {target = "66";};
if (value === 19.443) {target = "67";};
if (value === 19.998) {target = "68";};
if (value === 20.558) {target = "69";};
if (value === 21.113) {target = "70";};
if (value === 21.668) {target = "71";};
if (value === 22.223) {target = "72";};
if (value === 22.778) {target = "73";};
if (value === 23.333) {target = "74";};
if (value === 23.888) {target = "75";};

request("http://<IP_ADDRESS>/tenHsServer/Set%20temp%20to%20"+target); },
    perms: ["pw","pr","ev"],
	format: "int",
	initialValue: 18.333,
	supportEvents: false,
	supportBonjour: false,
	manfDescription: "Target Temperature",
	designedMinValue: 18.333,
	designedMaxValue: 23.888,
	designedMinStep: 0.005,
	unit: "celsius"

Thanks Tommy, I was able to get this working by converting from celsius to fahrenheit manually in the onUpdate function. Siri now sets the temperature correctly, however, this means that the temperature stored in the characteristic is in celsius which is a bit confusing when setting up action sets.
Is this a limitation of home kit or with the HAP-NodeJS server?

It seems like it's a  home kit thing, but maybe things will change as they update things.
KhaosT had stated this earlier in this post.
"This issue happens because Siri (at least under English) will think the unit of temperature you said is in Ferinheight but the accessory is asking for Celsius so Siri will try to convert Ferinheight to Celsius. However, after conversion, HomeKit will check the data validity before sending it to accessory which fails because 25 Fahrenheit is -3.89 Celsius. I have the lower boundary set to be 16 celsius which cause HomeKit reject to send this update request... Then a bug in HomeKit will cause sending an update command with nothing inside which causes the HAP Server crash."

I tried the HomeKit Accessory Simulator and it seems that thing also uses unit in celsius even if you state Temperature Units to be fahrenheit. Since I don't have access to "HomeKit Accessory Profiles", I think the spec defines the value of temperature characteristic always to be in celsius and the developer should do the conversion manually...


What to display for 'LAST TIME DEPARTED'?

Idea: On revisit, and if user never made changes, nice to use their last visit time as 'last time departed'.

Still not sure about initial visit.


virtualbox(-with-extension-pack)-np: failed to install because of missing executable

Bug Report
Package Name: virtualbox-np and virtualbox-with-extension-pack-np
Current Behaviour
Because corresponding build flag have been turned to "disable", virtualbox installation does not contain VBoxSDL.exe (an SDL based GUI) for 7.x release.
With this change, the installation stops with an error that cannot create a shim for VBoxSDL.
See the upstream changeset : https://www.virtualbox.org/changeset/95176/vbox
Expected Behaviour
Install succeed with no error reported
Additional context/output
Here is a terminal output of installation command on current master branch (d5eb9ae)
> sudo scoop install virtualbox-np
Installing 'virtualbox-np' (7.0.0) [64bit] from nonportable bucket
VirtualBox-7.0.0-153978-Win.exe (104.8 MB)
Linking C:\tools\scoop\apps\virtualbox-np\current => C:\tools\scoop\apps\virtualbox-np\7.0.0
Creating shim for 'VBoxBalloonCtrl'.
Creating shim for 'VBoxBugReport'.
Creating shim for 'VBoxDTrace'.
Creating shim for 'VBoxExtPackHelperApp'.
Creating shim for 'VBoxHeadless'.
Creating shim for 'vbox-img'.
Creating shim for 'VBoxManage'.
Creating shim for 'VBoxNetDHCP'.
Creating shim for 'VBoxNetNAT'.
Creating shim for 'VBoxSDL'.
Can't shim 'VBoxSDL.exe': File doesn't exist.

Possible Solution
Just remove VBoxSDL from shim target
System details
Windows version: 10
OS architecture: 64bit
PowerShell version: 7.2.6
Additional software: N/A
Scoop Configuration
{
  "lastupdate": "2022-10-12T12:44:39.0379003+09:00",
  "SCOOP_REPO": "https://github.com/lukesampson/scoop",
  "SCOOP_BRANCH": "master",
  "debug": true
}

I have already confirmed the solution works and ready to submit PR.

Will be fixed by #72 and #73 . Closing


Updated API Documentation

Lightbox w/ basic example
Modal w/ basic example
Actions function descriptions
ActionConst descriptions

Could you fix conflicts?

Sorry about that, conflicts resolved.

@mcabs3 Thanks! Could you please check mobx demo I've just prepared? Maybe you will find something new, your feedback is very important for me.

I can most certainly give it a go! Is it in master? Maybe we refactor the example project to be in a parent examples folder? I can make one for redux as well.

Is it in separate repo (fork of react-native-starter-app):
https://github.com/aksonov/react-native-starter-app

@mcabs3 Can you please do example for a Drawer as well?


nginx's sendfile() failed on kernel 5.10.10 and LXD 4.0.6

Required information

Distribution: Arch Linux
Distribution version: latest
The output of "lxc info" or if that fails:

$ lxc info
config:
  core.https_address: <IP_ADDRESS>:XXXX
  core.trust_password: true
  images.auto_update_interval: "0"
api_extensions:
- storage_zfs_remove_snapshots
- container_host_shutdown_timeout
- container_stop_priority
- container_syscall_filtering
- auth_pki
- container_last_used_at
- etag
- patch
- usb_devices
- https_allowed_credentials
- image_compression_algorithm
- directory_manipulation
- container_cpu_time
- storage_zfs_use_refquota
- storage_lvm_mount_options
- network
- profile_usedby
- container_push
- container_exec_recording
- certificate_update
- container_exec_signal_handling
- gpu_devices
- container_image_properties
- migration_progress
- id_map
- network_firewall_filtering
- network_routes
- storage
- file_delete
- file_append
- network_dhcp_expiry
- storage_lvm_vg_rename
- storage_lvm_thinpool_rename
- network_vlan
- image_create_aliases
- container_stateless_copy
- container_only_migration
- storage_zfs_clone_copy
- unix_device_rename
- storage_lvm_use_thinpool
- storage_rsync_bwlimit
- network_vxlan_interface
- storage_btrfs_mount_options
- entity_description
- image_force_refresh
- storage_lvm_lv_resizing
- id_map_base
- file_symlinks
- container_push_target
- network_vlan_physical
- storage_images_delete
- container_edit_metadata
- container_snapshot_stateful_migration
- storage_driver_ceph
- storage_ceph_user_name
- resource_limits
- storage_volatile_initial_source
- storage_ceph_force_osd_reuse
- storage_block_filesystem_btrfs
- resources
- kernel_limits
- storage_api_volume_rename
- macaroon_authentication
- network_sriov
- console
- restrict_devlxd
- migration_pre_copy
- infiniband
- maas_network
- devlxd_events
- proxy
- network_dhcp_gateway
- file_get_symlink
- network_leases
- unix_device_hotplug
- storage_api_local_volume_handling
- operation_description
- clustering
- event_lifecycle
- storage_api_remote_volume_handling
- nvidia_runtime
- container_mount_propagation
- container_backup
- devlxd_images
- container_local_cross_pool_handling
- proxy_unix
- proxy_udp
- clustering_join
- proxy_tcp_udp_multi_port_handling
- network_state
- proxy_unix_dac_properties
- container_protection_delete
- unix_priv_drop
- pprof_http
- proxy_haproxy_protocol
- network_hwaddr
- proxy_nat
- network_nat_order
- container_full
- candid_authentication
- backup_compression
- candid_config
- nvidia_runtime_config
- storage_api_volume_snapshots
- storage_unmapped
- projects
- candid_config_key
- network_vxlan_ttl
- container_incremental_copy
- usb_optional_vendorid
- snapshot_scheduling
- container_copy_project
- clustering_server_address
- clustering_image_replication
- container_protection_shift
- snapshot_expiry
- container_backup_override_pool
- snapshot_expiry_creation
- network_leases_location
- resources_cpu_socket
- resources_gpu
- resources_numa
- kernel_features
- id_map_current
- event_location
- storage_api_remote_volume_snapshots
- network_nat_address
- container_nic_routes
- rbac
- cluster_internal_copy
- seccomp_notify
- lxc_features
- container_nic_ipvlan
- network_vlan_sriov
- storage_cephfs
- container_nic_ipfilter
- resources_v2
- container_exec_user_group_cwd
- container_syscall_intercept
- container_disk_shift
- storage_shifted
- resources_infiniband
- daemon_storage
- instances
- image_types
- resources_disk_sata
- clustering_roles
- images_expiry
- resources_network_firmware
- backup_compression_algorithm
- ceph_data_pool_name
- container_syscall_intercept_mount
- compression_squashfs
- container_raw_mount
- container_nic_routed
- container_syscall_intercept_mount_fuse
- container_disk_ceph
- virtual-machines
- image_profiles
- clustering_architecture
- resources_disk_id
- storage_lvm_stripes
- vm_boot_priority
- unix_hotplug_devices
- api_filtering
- instance_nic_network
- clustering_sizing
- firewall_driver
- projects_limits
- container_syscall_intercept_hugetlbfs
- limits_hugepages
- container_nic_routed_gateway
- projects_restrictions
- custom_volume_snapshot_expiry
- volume_snapshot_scheduling
- trust_ca_certificates
- snapshot_disk_usage
- clustering_edit_roles
- container_nic_routed_host_address
- container_nic_ipvlan_gateway
- resources_usb_pci
- resources_cpu_threads_numa
- resources_cpu_core_die
- api_os
- container_nic_routed_host_table
- container_nic_ipvlan_host_table
- container_nic_ipvlan_mode
- resources_system
- images_push_relay
- network_dns_search
- container_nic_routed_limits
- instance_nic_bridged_vlan
- network_state_bond_bridge
- usedby_consistency
- custom_block_volumes
- clustering_failure_domains
- resources_gpu_mdev
- console_vga_type
- projects_limits_disk
- network_type_macvlan
- network_type_sriov
- container_syscall_intercept_bpf_devices
- network_type_ovn
- projects_networks
- projects_networks_restricted_uplinks
- custom_volume_backup
- backup_override_name
- storage_rsync_compression
- network_type_physical
- network_ovn_external_subnets
- network_ovn_nat
- network_ovn_external_routes_remove
- tpm_device_type
- storage_zfs_clone_copy_rebase
- gpu_mdev
- resources_pci_iommu
- resources_network_usb
- resources_disk_address
- network_physical_ovn_ingress_mode
- network_ovn_dhcp
- network_physical_routes_anycast
- projects_limits_instances
- network_state_vlan
- instance_nic_bridged_port_isolation
api_status: stable
api_version: "1.0"
auth: trusted
public: false
auth_methods:
- tls
environment:
  addresses:
  - <IP_ADDRESS>:XXXX
  - <IP_ADDRESS>:XXXX
  - ...
  architectures:
  - x86_64
  - i686
  certificate: |
    -----BEGIN CERTIFICATE-----
   ...
    -----END CERTIFICATE-----
  certificate_fingerprint: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  driver: lxc
  driver_version: 4.0.6
  firewall: xtables
  kernel: Linux
  kernel_architecture: x86_64
  kernel_features:
    netnsid_getifaddrs: "true"
    seccomp_listener: "true"
    seccomp_listener_continue: "true"
    shiftfs: "false"
    uevent_injection: "true"
    unpriv_fscaps: "true"
  kernel_version: 5.10.10-arch1-1
  lxc_features:
    cgroup2: "true"
    devpts_fd: "true"
    mount_injection_file: "true"
    network_gateway_device_route: "true"
    network_ipvlan: "true"
    network_l2proxy: "true"
    network_phys_macvlan_mtu: "true"
    network_veth_router: "true"
    pidfd: "true"
    seccomp_allow_deny_syntax: "true"
    seccomp_notify: "true"
    seccomp_proxy_send_notify_fd: "true"
  os_name: Arch Linux
  os_version: ""
  project: default
  server: lxd
  server_clustered: false
  server_name: frodo
  server_pid: 5391
  server_version: "4.10"
  storage: zfs
  storage_version: 2.0.0-1

Issue description
nginx fails inside newly created container with the following error - looks like sendfile() function is the root cause:
root@test1:~# curl localhost
curl: (18) transfer closed with 612 bytes remaining to read

nginx/error.log
2021/01/26 08:34:50 [alert] 509#509: *1 sendfile() failed (22: Invalid argument) while sending response to client, client: ::1, server: _, request: "GET / HTTP/1.1", host: "localhost"

strace:
root@test1:~# strace -e trace=network -p `pidof nginx | sed -e 's/ /,/g'`
strace: Process 115 attached
strace: Process 114 attached
strace: Process 113 attached
strace: Process 112 attached
strace: Process 111 attached
strace: Process 110 attached
strace: Process 109 attached
strace: Process 108 attached
strace: Process 107 attached
[pid   109] accept4(7, {sa_family=AF_INET6, sin6_port=htons(33352), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_scope_id=0}, [112->28], SOCK_NONBLOCK) = 17
[pid   109] recvfrom(17, "GET / HTTP/1.1\r\nHost: localhost\r"..., 1024, 0, NULL, NULL) = 73
[pid   109] setsockopt(17, SOL_TCP, TCP_CORK, [1], 4) = 0
[pid   109] sendfile(17, 18, [0], 612)  = -1 EINVAL (Invalid argument)

All works fine when running the same system and container on kernel 5.4.92-1-lts.
The above problem can easily be mitigated by disabling sendfile (sendfile off) in the nginx.conf file, but the question remains why default nginx setup breaks inside the container.
Also, same version of nginx installed on host, on kernel 5.10, works OK, no issues with sendfile(). Therefore I am leaning towards combination of kernel >5.4 and LXD. I have no precise information when it stopped working, it had to be last month, before that it had been working well w/o any issues.
At this point I am not sure what to try next to narrow down the root cause. Would appreciate some pointers.
Steps to reproduce

Create new container: lxc launch images:ubuntu/20.04 test1
Install nginx in the container: apt install nginx curl && systemctl restart nginx
Execute curl (can be inside the container or outside): curl localhost

Information to attach

[ ] Container log (lxc info NAME --show-log)

$ lxc info test1 --show-log
Name: test1
Location: none
Remote: unix://
Architecture: x86_64
Created: 2021/01/26 06:54 UTC
Status: Running
Type: container
Profiles: default
Pid: 41801
Ips:
  lo:	inet	<IP_ADDRESS>
  lo:	inet6	::1
  eth0:	inet	x.y.x.y	enoX.YYY
  eth0:	inet6	fe80::216:3eff:fe9b:9fd8	enoX.YYY
Resources:
  Processes: 26
  Disk usage:
    root: 101.30MB
  CPU usage:
    CPU usage (in seconds): 1
  Memory usage:
    Memory (current): 81.69MB
    Memory (peak): 85.66MB
  Network usage:
    eth0:
      Bytes received: 748B
      Bytes sent: 1.93kB
      Packets received: 3
      Packets sent: 19
    lo:
      Bytes received: 3.65kB
      Bytes sent: 3.65kB
      Packets received: 32
      Packets sent: 32

Log:

lxc test1<PHONE_NUMBER>3843.262 WARN     cgfsng - cgroups/cgfsng.c:mkdir_eexist_on_last:1152 - File exists - Failed to create directory "/sys/fs/cgroup/cpuset//lxc.monitor.test1"
lxc test1<PHONE_NUMBER>3843.264 WARN     cgfsng - cgroups/cgfsng.c:mkdir_eexist_on_last:1152 - File exists - Failed to create directory "/sys/fs/cgroup/cpuset//lxc.payload.test1"
lxc test1<PHONE_NUMBER>3843.287 WARN     cgfsng - cgroups/cgfsng.c:fchowmodat:1570 - No such file or directory - Failed to fchownat(17, memory.oom.group, 65536, 0, AT_EMPTY_PATH | AT_SYMLINK_NOFOLLOW )

[ ] Container configuration (lxc config show NAME --expanded)

$ lxc config show test1 --expanded
architecture: x86_64
config:
  image.architecture: amd64
  image.description: Ubuntu focal amd64 (20210125_14:59)
  image.os: Ubuntu
  image.release: focal
  image.serial: "20210125_14:59"
  image.type: squashfs
  image.variant: default
  raw.lxc: lxc.apparmor.profile=unconfined
  volatile.base_image: 6ed5f3aeb468e2a71367f70ff8057905e958f3f4790fdcda71767c70bedae688
  volatile.eth0.host_name: mac2b9bfcf4
  volatile.eth0.hwaddr: 00:16:3e:9b:9f:d8
  volatile.eth0.last_state.created: "false"
  volatile.idmap.base: "0"
  volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":65536}]'
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.power: RUNNING
  volatile.uuid: b753f24d-1835-48c2-969c-abdc50dc1211
devices:
  eth0:
    name: eth0
    nictype: macvlan
    parent: enoX.YYY
    type: nic
  root:
    path: /
    pool: lxd
    type: disk
ephemeral: false
profiles:
- default
stateful: false
description: ""

@brauner can you look into this one?

@brauner can you look into this one?

This is a kernel regression that is about to be fixed upstream. There's a few more similar to:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f8ad8187c3b536ee2b10502a8340c014204a1af0

This is a kernel regression that is about to be fixed upstream. There's a few more similar to:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f8ad8187c3b536ee2b10502a8340c014204a1af0

In other words, it's not our bug and I already worked around this in upstream LXC and I'm not happy about it. :)

In other words, it's not our bug and I already worked around this in upstream LXC and I'm not happy about it. :)

Thank you!

Thank you!


Ces 12338

Updated assign role to handle BOSS-2 disks enumeration
disabled overcloud image customization until workaround is in place for nested virtualization not supported with IceLake/Rhel 8.2

Looks good.


Can't fetch local sites

I was setting up a server up/down visual and notices all of my non-public servers were erroring out. I set up this super minimal test and still am unable to connect to locally hosted sites.
// My quickly thrown together server
const http = require('http');

const server = http.createServer((req, res) => {
  res.writeHead(200, { 'Content-Type': 'application/json' });
  const array = ['apple', 'banana', 'cherry'];
  res.end(JSON.stringify(array));
});

server.listen(
  3000,
  '<IP_ADDRESS>',
  () => {
    console.log(`Server running at http://${HOST}:${PORT}/`);
  }
);

// js/GetAPI.js
class GetAPI {
  GetAPI() { }

  async getData() {
    try {
      const response = await fetch(`http:/localhost:3000`)
      return response;
    } catch (error) {
      return error.message;
    }
  }
}

<!-- Welcome.md -->
\```dataviewjs
const {GetAPI} = await cJS()
dv.list(await GetAPI.getData())
\```

This should return:
- apple
- banana
- cherry

But actually returns:
- F
- a
- i
- l
- e
- d
... to fetch

Nevermind, this was just a CORS issue :P


[Task] Clarify id field restriction in StatusList2021

Description
StatusList2021 and RevocationList2020 mandate for the id field of credentialStatus:

It MUST NOT be the URL for the status list.

It's unclear why this is the case and we did not adopt this restriction for RevocationBitmap2022, so we should clarify why this is the case in those specs.
An issue was opened to ask for clarification.
Resources
https://github.com/iotaledger/identity.rs/pull/879#discussion_r895764087
https://github.com/iotaledger/identity.rs/pull/879#discussion_r900129500

The answer from the linked issue on StatusList2021Entry is that the id field should uniquely identify the credentialStatus property. This is useful if a larger graph of credentials is created where multiple credentialStatus properties exist, and they can be uniquely identified through id.
This means we can consider changing the id field to include the index to make it unique among credentials in the same revocation bitmap.
So for instance, now we have:
 "credentialStatus": {
    "id": "did:iota:EvaQhPXXsJsGgxSXGhZGMCvTt63KuAFtaGThx6a5nSpw#revocation",
    "type": "RevocationBitmap2022",
    "revocationBitmapIndex": "5"
  },

and we could change it to (much like what @cycraig suggested in one of the comments):
 "credentialStatus": {
    "id": "did:iota:EvaQhPXXsJsGgxSXGhZGMCvTt63KuAFtaGThx6a5nSpw?index=5#revocation",
    "revocationBitmapUrl": "did:iota:EvaQhPXXsJsGgxSXGhZGMCvTt63KuAFtaGThx6a5nSpw#revocation",
    "type": "RevocationBitmap2022",
    "revocationBitmapIndex": "5"
  },

However the VC spec also says this about identifiers:

The value of the id property MUST be a single URI. It is RECOMMENDED that the URI in the id be one which, if dereferenced, results in a document containing machine-readable information about the id.

Then again, StatusList2021Entry does it similarly, so I'm unsure how much this applies here.


Missing RTP Scheme-Handler

Is there any sample for creating Scheme-Handler like RTP ?

There are a number of samples which implement scheme handlers. The AssociationLaunching sample is a good start.


UPSTREAM: 98: Reformat code with go 1.19 again

Upstream PR #98 is not enough, we have an older version in OCP and more files need to be reformatted.
@openshift/storage

/lgtm

/label docs-approved
/label px-approved
/label qe-approved
This PR changes only one comment.


Inductive Infomax

Hi,
First of all, LOVE the pytorch geometric library.
[Summary of contribution]
The pytorch geometric library has an implementation of transductive Infomax (see examples/infomax.py) however there is no implementation of Inductive Infomax. I have added an example of an implementation of inductive infomax for the reddit dataset. The relevant paper is: "Deep Graph Infomax" https://arxiv.org/abs/1809.10341
[Performance]
The paper reports an accuracy of 94%, here we achieve an accuracy of 93.55%
[Tests and formatting]
All formatting tests (flake8 and pycodestyle) pass with no errors and python setup.py test returns no errors:

I couldn't see any tests for examples/ so didn't create any for Inductive_Infomax.py - is this okay?
[General Comments]

I only test classification accuracy at the end of training as the LogisticRegression func takes 20x the time it takes to train just one epoch.

Happy to implement any changes you propose.

Thank you very much. This looks excellent. I will have a closer look ASAP.

Thanks once again :)

No problem! I enjoyed using the great Library. That you for cleaning my code - still new to all of this. (1st year PhD student - thought that I should get my first contribution to open source code out of the way ahah)

Your code was awesome :) I only did some small changes (which are debatable :))

BTW: I reduced the number of epochs since it reaches 93.5 after only a few epochs. I did not see a reason to train that long (although the paper reports to use 150 epochs).

Haha thank you that's great to hear! Yeah I did see that - was going to leave that decision to you.


Marketing Experiment: 27th July - Twitter baseline ad

Experiment
Context
We haven't run a Twitter ad in several months. This is a test ad is really to just set a baseline for future work (and for me to go through the entire ad creation process end to end)
Experiment
Goal

To set a benchmark for Twitter Ads
To see how the copy compares with previous (albeit outdated) ads

Hypothesis
This experiment doesn't really have a hypothesis, we're just interested in the baseline results.
Campaign details

Audience
Twitter users with interests in:

Resources and timeline

2 weeks
$2k total (max $150/day)

Metrics
Tracking

Twitter dashboard
https://posthog.com?utm_source=twitter&utm_medium=tweet&utm_campaign=opensource

Primary
CTR
Pre-experiment baseline:
This will set the baseline

Results
What are the top learnings from this experiment?
We ran an experiment that was very costly from a CPC perspective, and had a very low CTR rate. I need to dig into SaaS benchmarks a bit more, but I think we significantly underperformed vs. general Twitter benchmarks.
What impact was there on the primary metric or any secondary metrics?
CTR = 0.16%
CPC = $4.24
What are the next steps based on the learnings of this experiment?
Share this baseline information with our PPC agency. I suspect that we will be de-prioritising Twitter ads while we prioritise Google Ads in the first instance.


Append additional use and reproduction statements instead of concatenating them

Builds on #3094.
A downstream feature request in purl is to separate multiple use and reproduction statements, so that a user-supplied one coming from h2 can be given special formatting and prominence (see mockup):

What would it take to have multiple distinct statements in the metadata (cocina, but also public XML, since purl currently doesn't use the cocina)? How would we indicate that one of the statements is a default, while the other is user-supplied?
Example item with user-supplied statement: https://purl.stanford.edu/fg611qq0508

@thatbudakguy I've discussed the headers with Hannah and we've agreed on what is in the design. We don't need anything further to distinguish default vs. user-supplied.

This would require a change in cocina and public xml, as the use and reproduction statements are stored in a single field. Making this change is feasible but medium LOE and medium risk, as it requires coordinated changes in H2, SDR API, Dor Services App, Dor Indexing App, and Purl.

There's also a question of what a new field will mean for Argo, which currently has edit access to every user-editable metadata field. Argo users won't normally need to use a field that's meant only for H2 deposits, but we'll need to consider what to do in situations where an object stops being managed by H2.

Based on storytime today we think we can take an approach similar to https://github.com/sul-dlss/mods_display/issues/78, where line breaks are preserved in the cocina and encoded as
 in the MODS XML.
https://github.com/sul-dlss/mods_display/issues/145 will ensure that the line breaks aren't stripped at display time.

We've decided not to add a new field or have a separate header, as in the decision shown.

Closed with #3127.


Multiple NIC support?

I've been using node-ssdp 2.2.1 as a client on Windows 8.1 and it has been working perfectly, thanks!
Recently I installed on another Windows 8.1 machine and found that everything went silent. I unfortunately don't have full-time access to that machine, but I did notice it has two network cards returned by os.networkInterfaces() as:
"network_interfaces": {
            "Ethernet": [
              {
                "family": "IPv6",
                "netmask": "ffff:ffff:ffff:ffff::",
                "mac": "xx:xx:xx:xx:xx:xx",
                "internal": false,
                "scopeid": 3,
                "address": "fe80::c570:b450:f38c:e02b"
              },
              {
                "mac": "xx:xx:xx:xx:xx:xx",
                "internal": false,
                "netmask": "<IP_ADDRESS>",
                "family": "IPv4",
                "address": "<IP_ADDRESS>"
              }
            ],
            "Ethernet_2": [
              {
                "family": "IPv6",
                "netmask": "ffff:ffff:ffff:ffff::",
                "mac": "yy:yy:yy:yy:yy:yy",
                "internal": false,
                "scopeid": 4,
                "address": "fe80::9864:ed9b:ea63:6506"
              },
              {
                "mac": "yy:yy:yy:yy:yy:yy",
                "internal": false,
                "netmask": "<IP_ADDRESS>",
                "family": "IPv4",
                "address": "<IP_ADDRESS>"
              }
            ],
            "Loopback_Pseudo-Interface_1": [
              {
                "family": "IPv6",
                "netmask": "ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff",
                "mac": "00:00:00:00:00:00",
                "internal": true,
                "scopeid": 0,
                "address": "::1"
              },
              {
                "mac": "00:00:00:00:00:00",
                "internal": true,
                "netmask": "<IP_ADDRESS>",
                "family": "IPv4",
                "address": "<IP_ADDRESS>"
              }
            ]
          }

Here Ethernet is connected to a single machine using <IP_ADDRESS>, while Ethernet_2 is connected to the wider internal network via <IP_ADDRESS>. I'm wondering how node-ssdp behaves in this scenario?
I noticed a similar issue here, and it looks like the relevant code actually creates a socket for each host IP address it finds.
I'm wondering if the simple solution is to create a new Client() for each IP address? Or if this scenario should be handled at a lower level? Thoughts?
Thanks!

I haven't ran into this issue myself so I can't speak from experience but I suppose that if the module you linked solved the same issue it could apply in this case as well. I'm going to look into that. Going to be a bit difficult to test, though. Would you be able to test a branch if I push one up?

Absolutely, I have periodic access to two machines that I can replicate the problem with. Anything in the short term you'd like to try?

I don't think there's anything; I'm working on this now, ran into an issue where server doesn't seem to receive multicast messages when bound to an address from os.networkInterfaces(). Binding to <IP_ADDRESS> (as it does currently) works. Might take some time to figure it out.

I tried this on another computer that has a similar dual NIC configuration today and it worked as expected. I noticed that the os.networkInterfaces() order was reversed, with the internet connected NIC coming first and the local NIC second:
"network_interfaces": {
  "Local_Area_Connection_2": [
    {
      "family": "IPv6",
      "netmask": "ffff:ffff:ffff:ffff::",
      "mac": "XX:XX:XX:XX:XX:XX",
      "internal": false,
      "scopeid": 14,
      "address": "fe80::2450:9825:159e:dd61"
    },
    {
      "mac": "XX:XX:XX:XX:XX:XX",
      "internal": false,
      "netmask": "<IP_ADDRESS>",
      "family": "IPv4",
      "address": "<IP_ADDRESS>"
    }
  ],
  "Local_Area_Connection": [
    {
      "family": "IPv6",
      "netmask": "ffff:ffff:ffff:ffff::",
      "mac": "XX:XX:XX:XX:XX:XX",
      "internal": false,
      "scopeid": 11,
      "address": "fe80::2065:45d4:1590:2af9"
    },
    {
      "mac": "XX:XX:XX:XX:XX:XX",
      "internal": false,
      "netmask": "<IP_ADDRESS>",
      "family": "IPv4",
      "address": "<IP_ADDRESS>"
    }
  ],
  "Loopback_Pseudo-Interface_1": [
    {
      "family": "IPv6",
      "netmask": "ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff",
      "mac": "00:00:00:00:00:00",
      "internal": true,
      "scopeid": 0,
      "address": "::1"
    },
    {
      "mac": "00:00:00:00:00:00",
      "internal": true,
      "netmask": "<IP_ADDRESS>",
      "family": "IPv4",
      "address": "<IP_ADDRESS>"
    }
  ]
}

This seems to confirm the theory that it is the NIC order affecting things.

I'm not sure if automatically creating sockets for every single interface is a good idea because user will have no control over which interface to use. I can see how it can be convenient but at the same time potentially problematic. What do you think?
I do think that a separate client per interface is a simple workaround for this (have you tried it?). Might be better to go with that rather than using all interfaces automatically.

I haven't tried the separate client per interface but can do later in the week. Will report back.

Iterating over each NIC and creating a client with the unicastHost option set, only generates responses for a single NIC, the second one remains silent. Using the following code I get this output:
[<IP_ADDRESS>] SSDP search started
[<IP_ADDRESS>] SSDP search started
[<IP_ADDRESS>] SSDP device found: uuid:6e1ba960-c47f-463b-8b9e-3ec54265e1a5, http:
//<IP_ADDRESS>:2869/upnphost/udhisapi.dll?content=uuid:6e1ba960-c47f-463b-8b9e-3ec
54265e1a5
...
[<IP_ADDRESS>] SSDP device found: urn:Microsoft Windows Peer Name Resolution Proto
col: V4:IPV6:LinkLocal, <IP_ADDRESS>
[<IP_ADDRESS>] SSDP timeout
[<IP_ADDRESS>] SSDP timeout

[<IP_ADDRESS>] is connected to the wider network, and [<IP_ADDRESS>] is a cross-over cable connection to a single machine:
> os.networkInterfaces()
{ 'Ethernet 2':
   [ { address: 'fe80::9864:ed9b:ea63:6506',
       netmask: 'ffff:ffff:ffff:ffff::',
       family: 'IPv6',
       mac: 'xx:xx:xx:xx:xx:xx',
       scopeid: 4,
       internal: false },
     { address: '<IP_ADDRESS>',
       netmask: '<IP_ADDRESS>',
       family: 'IPv4',
       mac: 'xx:xx:xx:xx:xx:xx',
       internal: false } ],
  Ethernet:
   [ { address: 'fe80::c570:b450:f38c:e02b',
       netmask: 'ffff:ffff:ffff:ffff::',
       family: 'IPv6',
       mac: 'xx:xx:xx:xx:xx:xx',
       scopeid: 3,
       internal: false },
     { address: '<IP_ADDRESS>',
       netmask: '<IP_ADDRESS>',
       family: 'IPv4',
       mac: 'xx:xx:xx:xx:xx:xx',
       internal: false } ],
  'Loopback Pseudo-Interface 1':
   [ { address: '::1',
       netmask: 'ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff',
       family: 'IPv6',
       mac: '00:00:00:00:00:00',
       scopeid: 0,
       internal: true },
     { address: '<IP_ADDRESS>',
       netmask: '<IP_ADDRESS>',
       family: 'IPv4',
       mac: '00:00:00:00:00:00',
       internal: true } ] }

Whats surprising is that the NIC connected to the wider network [<IP_ADDRESS>] actually appears first in the list and yet somehow only the second NIC [<IP_ADDRESS>] gets responses.
On another machine with multiple NICs I got the following output, this time with the [<IP_ADDRESS>] NIC connected to the wider network getting responses and the cross-over cable machine [<IP_ADDRESS>] not getting any responses:
[<IP_ADDRESS>] SSDP search started
[<IP_ADDRESS>] SSDP search started
[<IP_ADDRESS>] SSDP device found: urn:Microsoft Windows Peer Name Resolution P
rotocol: V4:IPV6:LinkLocal, <IP_ADDRESS>
...
[<IP_ADDRESS>] SSDP timeout
[<IP_ADDRESS>] SSDP timeout

NIC setup as follows:
> os.networkInterfaces()
{ 'Local Area Connection 2':
   [ { address: 'fe80::2450:9825:159e:dd61',
       netmask: 'ffff:ffff:ffff:ffff::',
       family: 'IPv6',
       mac: 'xx:xx:xx:xx:xx:xx',
       scopeid: 14,
       internal: false },
     { address: '<IP_ADDRESS>',
       netmask: '<IP_ADDRESS>',
       family: 'IPv4',
       mac: 'xx:xx:xx:xx:xx:xx',
       internal: false } ],
  'Local Area Connection':
   [ { address: 'fe80::2065:45d4:1590:2af9',
       netmask: 'ffff:ffff:ffff:ffff::',
       family: 'IPv6',
       mac: 'xx:xx:xx:xx:xx:xx',
       scopeid: 11,
       internal: false },
     { address: '<IP_ADDRESS>',
       netmask: '<IP_ADDRESS>',
       family: 'IPv4',
       mac: 'xx:xx:xx:xx:xx:xx',
       internal: false } ],
  'Loopback Pseudo-Interface 1':
   [ { address: '::1',
       netmask: 'ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff',
       family: 'IPv6',
       mac: '00:00:00:00:00:00',
       scopeid: 0,
       internal: true },
     { address: '<IP_ADDRESS>',
       netmask: '<IP_ADDRESS>',
       family: 'IPv4',
       mac: '00:00:00:00:00:00',
       internal: true } ] }

I also tried a single client that specified the unicastHost option and that saw the same result as the multiple client case each time. Likewise, not specifying the unicastHost option would only use one NIC. I'm not sure what the logic is to decide which NIC it uses.
Thoughts?

I can confirm this bug. Have multiple NICs. I create a client for each nic. I only get events on one (not the first one I registered though).

So, @karldd, what you see is you only able to get events from one NIC – no matter how you create the client, is that correct? Same for you, @ds82?
There is one thing that comes to mind – the multicast membership is currently added without specifying the interface on which to join the group; it works with one NIC because the OS will know which one to use but for multiple NICs – they might end up joining on a wrong interface.

Would one of you guys be able to run the feature/i34-multiple-nic-support-test-branch branch and see if that changes anything?

I may have to withdraw my bug report ... I had an active VPN connection on the interface that did not get any events. If I disconnect the VPN, I get events for both NICs (when creating a client for each NIC, what I think is ok). I think the VPN problem is by design and there's maybe nothing you could do about it, right?

Ah. Frankly, I don't know how VPN interferes with multicast, but I know for sure that I have weird issues on my machine with cURL when running VPN, so it's possible that multicast traffic gets affected as well.

I tested your branch.  Works well if I turn off the VPN (actually same behaviour like before).

Thanks, @ds82. So, at least it doesn't break it. I wonder if @karldd's setup includes VPN.

No VPN that I know of, but it isn't my personal machine so hard to say for sure. Hopefully I can test this tomorrow and report back.

So this doesn't look to make any difference. The behavior is quite odd.
For the one machine I tested here is what happens:

When I don't define a unicastHost I get results from the 10.x.x.x address.
When I set the unicastHost to the 10.x.x.x address I get no results.
When I set the unicastHost to the 192.x.x.x address I do get results.

It is weird. I'm gonna make a VM and try to test it out to see if I can spot an issue.

Thanks! Let me know if there is anything you want me to test out.

I'm seeing the same issue when trying out the server example. I have multiple NICs (I have 3 more, but they are disabled):
{ WiFi:
   [ { address: '<IP_ADDRESS>',
       netmask: '<IP_ADDRESS>',
       family: 'IPv4',
       mac: 'xx:xx:xx:xx:xx:xx',
       internal: false } ],
  'VirtualBox Host-Only Network':
   [ { address: '<IP_ADDRESS>',
       netmask: '<IP_ADDRESS>',
       family: 'IPv4',
       mac: 'xx:xx:xx:xx:xx:xx',
       internal: false } ],
  'Loopback Pseudo-Interface 1':
   [ { address: '::1',
       netmask: 'ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff',
       family: 'IPv6',
       mac: '00:00:00:00:00:00',
       scopeid: 0,
       internal: true },
     { address: '<IP_ADDRESS>',
       netmask: '<IP_ADDRESS>',
       family: 'IPv4',
       mac: '00:00:00:00:00:00',
       internal: true } ] }

Instead of sending NOTIFY through all of them (WiFi is my actual internet access), it tries to send it only through VirtualBox Host-Only Network which is connected to nothing (it's a fake NIC that virtual box creates when you install it). If I disable VirtualBox Host-Only Network and rerun the example, it starts sending the message using WiFi.
To test, if it's something in node, I tried to create an http server without providing a specific address (it defaults to <IP_ADDRESS> for IP4) and that worked well across all interfaces.
I'm using Windows 8.1 (64 bit) and node-ssdp v2.6.2.

The issue is probably with using a single socket (in the module itself). Since I'm calling addMembership with no interface as the second argument it binds to the interface of the OS choosing.
I was thinking that maybe user could specify the interface but that puts burden of dealing with interface discovery on the user and it's probably not what a typical user would want to do. So, I'm going to have to rewrite that part of the module to create and manage multiple sockets (which I tried to avoid but ¯_(ツ)_/¯ ).

I was thinking that maybe user could specify the interface but that puts burden of dealing with interface discovery on the user and it's probably not what a typical user would want to do

It would be nice if we have both options, but yes most users will probably just use the default option.

So, I'm going to have to rewrite that part of the module to create and manage multiple sockets

:+1:

Could someone with a working setup see if this 719526d makes a difference?

@diversario I gave the branch a try, I have an additional interface (tun0) when the VPN is connected.
> os.networkInterfaces()
{ lo:
   [ { address: '<IP_ADDRESS>',
       netmask: '<IP_ADDRESS>',
       family: 'IPv4',
       mac: '00:00:00:00:00:00',
       internal: true },
     { address: '::1',
       netmask: 'ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff',
       family: 'IPv6',
       mac: '00:00:00:00:00:00',
       scopeid: 0,
       internal: true } ],
  wlan0:
   [ { address: '<IP_ADDRESS>',
       netmask: '<IP_ADDRESS>',
       family: 'IPv4',
       mac: 'xx:xx:xx:xx:xx:xx',
       internal: false },
     { address: 'fe80::5627:1eff:feb6:5ac5',
       netmask: 'ffff:ffff:ffff:ffff::',
       family: 'IPv6',
       mac: 'xx:xx:xx:xx:xx:xx',
       scopeid: 2,
       internal: false } ],
  tun0:
   [ { address: '<IP_ADDRESS>',
       netmask: '<IP_ADDRESS>',
       family: 'IPv4',
       mac: '08:00:08:00:80:00',
       internal: false } ] }

tun0 information:
$ ip link show dev tun0
10: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 100
   link/none

The branch works fine without the tunnel being active:
kotlarz@laptop  /tmp/node-ssdp   feature/i34-multiple-nic-support-attempt-3  node example/client.js
{"name":"ssdp-client","hostname":"laptop","pid":11665,"level":30,"msg":"discovering all IPs from interface lo","time":"2016-01-24T21:48:01.392Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":126},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11665,"level":30,"msg":"discovering all IPs from interface wlan0","time":"2016-01-24T21:48:01.396Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":126},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11665,"level":30,"msg":"Will use interface wlan0","time":"2016-01-24T21:48:01.397Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":130},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11665,"level":30,"address":"http://<IP_ADDRESS>:1900","interface":"<IP_ADDRESS>","msg":"SSDP listening","time":"2016-01-24T21:48:01.403Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":199,"func":"onSocketListening"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11665,"level":10,"msg":"Sending an M-SEARCH request","time":"2016-01-24T21:48:01.404Z","src":{"file":"/tmp/node-ssdp/lib/client.js","line":54,"func":"search"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11665,"level":10,"message":"M-SEARCH * HTTP/1.1\r\nHOST: <IP_ADDRESS>:1900\r\nST: urn:schemas-upnp-org:service:ContentDirectory:1\r\nMAN: \"ssdp:discover\"\r\nMX: 3\r\n\r\n","msg":"Sent M-SEARCH request","time":"2016-01-24T21:48:01.405Z","src":{"file":"/tmp/node-ssdp/lib/client.js","line":59},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11665,"level":10,"ST":"urn:schemas-upnp-org:service:ContentDirectory:1","address":"<IP_ADDRESS>","port":1900,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:01.406Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11665,"level":30,"message":"HTTP/1.1 200 OK\r\nLocation: http://<IP_ADDRESS>:32469/DeviceDescription.xml\r\nCache-Control: max-age=1800\r\nServer: UPnP/1.0 DLNADOC/1.50 Platinum/<IP_ADDRESS>\r\nEXT: \r\nUSN: uuid:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx::urn:schemas-upnp-org:service:ContentDirectory:1\r\nST: urn:schemas-upnp-org:service:ContentDirectory:1\r\nDate: Sun, 24 Jan 2016 21:48:02 GMT\r\n\r\n","msg":"SSDP response","time":"2016-01-24T21:48:02.407Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":394,"func":"parseResponse"},"v":0}
Got a response to an m-search:
200
{
  "LOCATION": "http://<IP_ADDRESS>:32469/DeviceDescription.xml",
  "CACHE-CONTROL": "max-age=1800",
  "SERVER": "UPnP/1.0 DLNADOC/1.50 Platinum/<IP_ADDRESS>",
  "EXT": "",
  "USN": "uuid:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx::urn:schemas-upnp-org:service:ContentDirectory:1",
  "ST": "urn:schemas-upnp-org:service:ContentDirectory:1",
  "DATE": "Sun, 24 Jan 2016 21:48:02 GMT"
}
{
  "address": "<IP_ADDRESS>",
  "family": "IPv4",
  "port": 47794,
  "size": 352
}

But sadly does not work as expected with the VPN connected:
kotlarz@laptop  /tmp/node-ssdp   feature/i34-multiple-nic-support-attempt-3  node example/client.js
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":30,"msg":"discovering all IPs from interface lo","time":"2016-01-24T21:48:28.781Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":126},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":30,"msg":"discovering all IPs from interface wlan0","time":"2016-01-24T21:48:28.784Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":126},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":30,"msg":"Will use interface wlan0","time":"2016-01-24T21:48:28.785Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":130},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":30,"msg":"discovering all IPs from interface tun0","time":"2016-01-24T21:48:28.785Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":126},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":30,"msg":"Will use interface tun0","time":"2016-01-24T21:48:28.785Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":130},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":30,"address":"http://<IP_ADDRESS>:1900","interface":"<IP_ADDRESS>","msg":"SSDP listening","time":"2016-01-24T21:48:28.792Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":199,"func":"onSocketListening"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":30,"address":"http://<IP_ADDRESS>:1900","interface":"<IP_ADDRESS>","msg":"SSDP listening","time":"2016-01-24T21:48:28.793Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":199,"func":"onSocketListening"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"msg":"Sending an M-SEARCH request","time":"2016-01-24T21:48:28.793Z","src":{"file":"/tmp/node-ssdp/lib/client.js","line":54,"func":"search"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"message":"M-SEARCH * HTTP/1.1\r\nHOST: <IP_ADDRESS>:1900\r\nST: urn:schemas-upnp-org:service:ContentDirectory:1\r\nMAN: \"ssdp:discover\"\r\nMX: 3\r\n\r\n","msg":"Sent M-SEARCH request","time":"2016-01-24T21:48:28.795Z","src":{"file":"/tmp/node-ssdp/lib/client.js","line":59},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"urn:schemas-upnp-org:service:ContentDirectory:1","address":"<IP_ADDRESS>","port":1900,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:28.796Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"urn:schemas-upnp-org:service:ContentDirectory:1","address":"<IP_ADDRESS>","port":1900,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:28.797Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"urn:schemas-upnp-org:service:ContentDirectory:1","address":"<IP_ADDRESS>","port":1900,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:28.797Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"urn:schemas-upnp-org:service:ContentDirectory:1","address":"<IP_ADDRESS>","port":1900,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:28.797Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"urn:dial-multiscreen-org:service:dial:1","address":"<IP_ADDRESS>","port":58983,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:29.054Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"urn:dial-multiscreen-org:service:dial:1","address":"<IP_ADDRESS>","port":38122,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:29.055Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"urn:dial-multiscreen-org:service:dial:1","address":"<IP_ADDRESS>","port":58983,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:29.055Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"urn:dial-multiscreen-org:service:dial:1","address":"<IP_ADDRESS>","port":38122,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:29.056Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"urn:dial-multiscreen-org:service:dial:1","address":"<IP_ADDRESS>","port":58983,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:30.056Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"urn:dial-multiscreen-org:service:dial:1","address":"<IP_ADDRESS>","port":38122,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:30.056Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"urn:dial-multiscreen-org:service:dial:1","address":"<IP_ADDRESS>","port":58983,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:30.056Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"urn:dial-multiscreen-org:service:dial:1","address":"<IP_ADDRESS>","port":38122,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:30.057Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"urn:dial-multiscreen-org:service:dial:1","address":"<IP_ADDRESS>","port":58983,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:31.057Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"urn:dial-multiscreen-org:service:dial:1","address":"<IP_ADDRESS>","port":38122,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:31.058Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"urn:dial-multiscreen-org:service:dial:1","address":"<IP_ADDRESS>","port":58983,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:31.059Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"urn:dial-multiscreen-org:service:dial:1","address":"<IP_ADDRESS>","port":38122,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:31.060Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"ssdp:all","address":"<IP_ADDRESS>","port":51230,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:33.044Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"ssdp:all","address":"<IP_ADDRESS>","port":51230,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:33.045Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"upnp:rootdevice","address":"<IP_ADDRESS>","port":42993,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:33.201Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"upnp:rootdevice","address":"<IP_ADDRESS>","port":42993,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:33.202Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"upnp:rootdevice","address":"<IP_ADDRESS>","port":42993,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:33.203Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"upnp:rootdevice","address":"<IP_ADDRESS>","port":42993,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:33.203Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"upnp:rootdevice","address":"<IP_ADDRESS>","port":54229,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:33.516Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"upnp:rootdevice","address":"<IP_ADDRESS>","port":54229,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:33.516Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"upnp:rootdevice","address":"<IP_ADDRESS>","port":54229,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:33.518Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"upnp:rootdevice","address":"<IP_ADDRESS>","port":54229,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:33.518Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"msg":"Sending an M-SEARCH request","time":"2016-01-24T21:48:38.793Z","src":{"file":"/tmp/node-ssdp/lib/client.js","line":54,"func":"search"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"message":"M-SEARCH * HTTP/1.1\r\nHOST: <IP_ADDRESS>:1900\r\nST: ssdp:all\r\nMAN: \"ssdp:discover\"\r\nMX: 3\r\n\r\n","msg":"Sent M-SEARCH request","time":"2016-01-24T21:48:38.794Z","src":{"file":"/tmp/node-ssdp/lib/client.js","line":59},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"ssdp:all","address":"<IP_ADDRESS>","port":1900,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:38.794Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"ssdp:all","address":"<IP_ADDRESS>","port":1900,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:38.794Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"ssdp:all","address":"<IP_ADDRESS>","port":1900,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:38.795Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
{"name":"ssdp-client","hostname":"laptop","pid":11811,"level":10,"ST":"ssdp:all","address":"<IP_ADDRESS>","port":1900,"msg":"SSDP M-SEARCH event","time":"2016-01-24T21:48:38.795Z","src":{"file":"/tmp/node-ssdp/lib/index.js","line":307,"func":"SSDP._msearch"},"v":0}
...

I can confirm that npm install https://github.com/diversario/node-ssdp#feature/i34-multiple-nic-support-attempt-3 works now (DEBUG=node-ssdp:server doesn't spit out any info, but that's alright for now)
My test environment is having a MacBook Pro with wifi connected and the thunderbolt to ethernet adapter connected. Before the feature branch it wouldn't work at all unless I was down to 1 interface.
Seems to work ok now though, thanks so much for fixing it (well in my case anyways!)

@Kotlarz what breaks for you when you're connected to VPN?
@endoplasmic thank you very much for testing it out! This is progress. Now, I need to incorporate changes in master (DEBUG=... does not work because this branch was cut before the logging overhaul).

@diversario right on, I'll keep an eye out here for when they roll into master and I can update my package.json :)

FYI, branch feature/i34-multiple-nic-support-attempt-3 is now up to date with master. I haven't had a chance to test it at all and especially in the conditions it supposed to address, so, if anyone wants to give it a try it would be fantastic 🙏

Well I'm resurrecting this since I just ran into the same issue using this branch, I had to make a tiny change to make this work for me in lib/index.js:208 from
socket.bind(self._ssdpPort, next) // socket binds on <IP_ADDRESS>
to
socket.bind(self._ssdpPort, iface, next) // socket binds on <IP_ADDRESS>
I'm currently testing using a vmware machine so maybe theres something special making it need to bind to the specif ip address but it works for me :)

Interesting. So you have to bind explicitly in order for this to work? Kind of makes sense since otherwise they would all bind to <IP_ADDRESS>. In this system, how many NICs do you have, @almightyju ?

Ok, there's now<EMAIL_ADDRESS>on npm.

It's strange but yes I have to bind explicitly to each NIC, I have 2 physical and 2 vmware NIC's

Just updated to the beta and it's all working fab with the new option, thank you!

@endoplasmic care to try the v3 beta? :)

FYI neither the beta3 or attempt3 branch are working for me on multiple nics. Am on a Mac with wifi and ethernet connected with the nic service order set high up and the device for discovery is on the Wifi. Thanks.

For me, it actually works 👍  😁
I'm on a mac (10.10.5) with two ethernet connections and an active VPN connection.
Using ..
...
const client = new Client({explicitSocketBind: true});
...

..actually works! Well done! 😎

It doesn't seem to work for me.
I have many NIC(s) on the computer I am running this, it's a standard win10x64 install, firewall down (to exclude any issues with that) during the tests
I have edited client.js adding explicitSocketBind: true

NIC dump:
{
  "Ethernet 2": [
    {
      "address": "fe80::a956:9e97:c3df:948b",
      "netmask": "ffff:ffff:ffff:ffff::",
      "family": "IPv6",
      "mac": "0a:00:27:00:00:08",
      "scopeid": 8,
      "internal": false
    },
    {
      "address": "<IP_ADDRESS>",
      "netmask": "<IP_ADDRESS>",
      "family": "IPv4",
      "mac": "0a:00:27:00:00:08",
      "internal": false
    }
  ],
  "VirtualBox Host-Only Network #3": [
    {
      "address": "fe80::c087:cfa6:6581:5f9",
      "netmask": "ffff:ffff:ffff:ffff::",
      "family": "IPv6",
      "mac": "0a:00:27:00:00:0f",
      "scopeid": 15,
      "internal": false
    },
    {
      "address": "<IP_ADDRESS>",
      "netmask": "<IP_ADDRESS>",
      "family": "IPv4",
      "mac": "0a:00:27:00:00:0f",
      "internal": false
    }
  ],
  "VirtualBox Host-Only Network #4": [
    {
      "address": "fe80::9df5:9cf5:6f43:2ce5",
      "netmask": "ffff:ffff:ffff:ffff::",
      "family": "IPv6",
      "mac": "0a:00:27:00:00:0b",
      "scopeid": 11,
      "internal": false
    },
    {
      "address": "<IP_ADDRESS>",
      "netmask": "<IP_ADDRESS>",
      "family": "IPv4",
      "mac": "0a:00:27:00:00:0b",
      "internal": false
    }
  ],
  "Wi-Fi": [
    {
      "address": "fe80::2c9f:4019:a5ce:74cf",
      "netmask": "ffff:ffff:ffff:ffff::",
      "family": "IPv6",
      "mac": "6c:71:d9:78:b7:f0",
      "scopeid": 19,
      "internal": false
    },
    {
      "address": "<IP_ADDRESS>",
      "netmask": "<IP_ADDRESS>",
      "family": "IPv4",
      "mac": "6c:71:d9:78:b7:f0",
      "internal": false
    }
  ],
  "Loopback Pseudo-Interface 1": [
    {
      "address": "::1",
      "netmask": "ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff",
      "family": "IPv6",
      "mac": "00:00:00:00:00:00",
      "scopeid": 0,
      "internal": true
    },
    {
      "address": "<IP_ADDRESS>",
      "netmask": "<IP_ADDRESS>",
      "family": "IPv4",
      "mac": "00:00:00:00:00:00",
      "internal": true
    }
  ]
}

Since it's working at least for some I'll promote beta2 to release.
Frankly, I'm puzzled as to what the problem could be.
It's possible that UDP TTL is set too low (by default, it's 1 and I'm going to bump it to a default of 4). You could try passing ssdpTtl: 255 to the constructor to see if that makes any difference.

I am seeing a similar symptom as this bug, though I don't think it is due to multiple nics. I was able to narrow it down to something that changed between 2.7.1 and 2.7.2. When I run my script using node-ssdp 2.7.1, my script works. When I run using node-ssdp 2.7.2, it does not. My GitHub skills are not good enough to see what changed between those two releases.

Here's the diff between 2.7.1 and 2.7.2:
https://github.com/diversario/node-ssdp/compare/v2.7.1...v2.7.2
It looks like the issue is the change to lib/index.js:
https://github.com/diversario/node-ssdp/commit/149c6ea6e1bc0273ba4ebe552c1fb96f8f917eca#diff-6d186b954a58d5bb740f73d84fe39073
When I comment the unref() call, my script works again. I tried commenting out unref() in the lastest version 3.2.1, and my script works again. This may explain the issues others are seeing here.

Sorry for the spam. I finally figured out my issue, and its in my code. I was calling client.stop() a bit earlier than I should, which lead to my script prematurely ending. If anyone else stumbles across this issue, check where you are calling client.stop(). Here's how I fixed things in my code:
https://github.com/monsur/sonos-now-playing/commit/f4e93dad1593a83569aedacdc87d79a435e2b840

I found some info which might help in the future. The explicitSocketBind option fixes this on macOS 10.13.1 with two NICs(one with local wifi for ssdp and one WAN ethernet).
Basically if you do enable explicitSocketBind and you have multiple NICs, it will broadcast by sending out using the first NICs ip as the from address instead of broadcasting on both NICs separately.
Sending with explicitSocketBind
12:24:29.408088 IP (tos 0x0, ttl 4, id 27978, offset 0, flags [none], proto UDP (17), length 157, bad cksum 0 (->e0db)!)
    <IP_ADDRESS>.61876 > <IP_ADDRESS>.1900: [bad udp cksum 0x68c5 -> 0xaab6!] UDP, length 129
..^...8..?y...E...mJ.................l..h.M-SEARCH * HTTP/1.1
HOST: <IP_ADDRESS>:1900
ST: urn:schemas-sony-com:service:ScalarWebAPI:1
MAN: "ssdp:discover"
MX: 3

12:24:29.408134 IP (tos 0x0, ttl 4, id 12491, offset 0, flags [none], proto UDP (17), length 157)
    <IP_ADDRESS>.62582 > <IP_ADDRESS>.1900: [udp sum ok] UDP, length 129
..^...(.v0.N..E...0.....Z#..z......v.l....M-SEARCH * HTTP/1.1
HOST: <IP_ADDRESS>:1900
ST: urn:schemas-sony-com:service:ScalarWebAPI:1
MAN: "ssdp:discover"
MX: 3

With two NICs

sudo tcpdump -vv -A -s 0 -n 'port 1900 and host <IP_ADDRESS> and udp'
tcpdump: data link type PKTAP
tcpdump: listening on pktap, link-type PKTAP (Apple DLT_PKTAP), capture size 262144 bytes
12:19:54.500940 IP (tos 0x0, ttl 4, id 1710, offset 0, flags [none], proto UDP (17), length 157)
    <IP_ADDRESS>.53051 > <IP_ADDRESS>.1900: [udp sum ok] UDP, length 129
..^...(.v0.N..E..........@..z......;.l..	.M-SEARCH * HTTP/1.1
HOST: <IP_ADDRESS>:1900
ST: urn:schemas-sony-com:service:ScalarWebAPI:1
MAN: "ssdp:discover"
MX: 3

12:19:54.742525 IP (tos 0x0, ttl 255, id 26770, offset 0, flags [none], proto UDP (17), length 156, bad cksum 0 (->ea93)!)
    <IP_ADDRESS>.64801 > <IP_ADDRESS>.1900: [bad udp cksum 0x68c4 -> 0xd2b2!] UDP, length 128
..^...8..?y...E...h................!.l..h.M-SEARCH * HTTP/1.1
Host:<IP_ADDRESS>:1900
ST:urn:schemas-upnp-org:service:WANIPConnection:1
Man:"ssdp:discover"
MX:3

Notice it sends both with the first NIC address.
Client logs with two NICs
ssdp-client discovering all IPs from interface lo0 +0ms
  ssdp-client discovering all IPs from interface en0 +2ms
  ssdp-client discovering all IPs from interface en1 +0ms
  ssdp-client Will use interface en1 +0ms
  ssdp-client discovering all IPs from interface awdl0 +0ms
  ssdp-client discovering all IPs from interface utun0 +0ms
  ssdp-client discovering all IPs from interface utun1 +0ms
  ssdp-client discovering all IPs from interface utun2 +0ms
  ssdp-client discovering all IPs from interface utun3 +0ms
searching... sony
  ssdp-client SSDP listening: { address: 'http://<IP_ADDRESS>:53051', interface: '<IP_ADDRESS>' } +4ms
  ssdp-client Sending an M-SEARCH request +2ms
  ssdp-client Sent M-SEARCH request: { message: 'M-SEARCH * HTTP/1.1\r\nHOST: <IP_ADDRESS>:1900\r\nST: urn:schemas-sony-com:service:ScalarWebAPI:1\r\nMAN: "ssdp:discover"\r\nMX: 3\r\n\r\n' } +1ms
  ssdp-client SSDP response: { message: 'HTTP/1.1 200 OK\r\nCACHE-CONTROL: max-age=1800\r\nEXT: \r\nLOCATION: http://<IP_ADDRESS>:61000/scalarwebapi_dd.xml\r\nSERVER: UPnP/1.0 MINT-X/1.8.1\r\nST: urn:schemas-sony-com:service:ScalarWebAPI:1\r\nUSN: uuid:000000001000-1010-8000-BAD7AF000148::urn:schemas-sony-com:service:ScalarWebAPI:1\r\n\r\n' } +2s
Got a response to an m-search:
200
{
  "CACHE-CONTROL": "max-age=1800",
  "EXT": "",
  "LOCATION": "http://<IP_ADDRESS>:61000/scalarwebapi_dd.xml",
  "SERVER": "UPnP/1.0 MINT-X/1.8.1",
  "ST": "urn:schemas-sony-com:service:ScalarWebAPI:1",
  "USN": "uuid:000000001000-1010-8000-BAD7AF000148::urn:schemas-sony-com:service:ScalarWebAPI:1"
}
{
  "address": "<IP_ADDRESS>",
  "family": "IPv4",
  "port": 42413,
  "size": 285
}

Packet dump with one NIC. Notice it sends using the correct from ip.
12:17:26.160293 IP (tos 0x0, ttl 4, id 31667, offset 0, flags [none], proto UDP (17), length 157)
    <IP_ADDRESS>.50678 > <IP_ADDRESS>.1900: [udp sum ok] UDP, length 129
..^...(.v0.N..E...{......;..z........l...=M-SEARCH * HTTP/1.1
HOST: <IP_ADDRESS>:1900
ST: urn:schemas-sony-com:service:ScalarWebAPI:1
MAN: "ssdp:discover"
MX: 3

<IP_ADDRESS>.50678 > <IP_ADDRESS>.1900
Client logs with one NIC
DEBUG=* node upnp/search.js
  ssdp-client discovering all IPs from interface lo0 +0ms
  ssdp-client discovering all IPs from interface en1 +1ms
  ssdp-client Will use interface en1 +0ms
  ssdp-client discovering all IPs from interface awdl0 +0ms
  ssdp-client discovering all IPs from interface utun0 +0ms
  ssdp-client discovering all IPs from interface utun1 +0ms
  ssdp-client discovering all IPs from interface utun2 +0ms
  ssdp-client discovering all IPs from interface utun3 +1ms
searching... sony
  ssdp-client SSDP listening: { address: 'http://<IP_ADDRESS>:50678', interface: '<IP_ADDRESS>' } +4ms
  ssdp-client Sending an M-SEARCH request +1ms
  ssdp-client Sent M-SEARCH request: { message: 'M-SEARCH * HTTP/1.1\r\nHOST: <IP_ADDRESS>:1900\r\nST: urn:schemas-sony-com:service:ScalarWebAPI:1\r\nMAN: "ssdp:discover"\r\nMX: 3\r\n\r\n' } +1ms
  ssdp-client SSDP response: { message: 'HTTP/1.1 200 OK\r\nCACHE-CONTROL: max-age=1800\r\nEXT: \r\nLOCATION: http://<IP_ADDRESS>:61000/scalarwebapi_dd.xml\r\nSERVER: UPnP/1.0 MINT-X/1.8.1\r\nST: urn:schemas-sony-com:service:ScalarWebAPI:1\r\nUSN: uuid:000000001000-1010-8000-BAD7AF000148::urn:schemas-sony-com:service:ScalarWebAPI:1\r\n\r\n' } +2s
Got a response to an m-search:
200
{
  "CACHE-CONTROL": "max-age=1800",
  "EXT": "",
  "LOCATION": "http://<IP_ADDRESS>:61000/scalarwebapi_dd.xml",
  "SERVER": "UPnP/1.0 MINT-X/1.8.1",
  "ST": "urn:schemas-sony-com:service:ScalarWebAPI:1",
  "USN": "uuid:000000001000-1010-8000-BAD7AF000148::urn:schemas-sony-com:service:ScalarWebAPI:1"
}
{
  "address": "<IP_ADDRESS>",
  "family": "IPv4",
  "port": 42413,
  "size": 285
}

I still see issues with multiple NICs support. The issue is that ip.address() returns the ip of the first interface only (when constructing the location URL).  So I had to modify the code and instead of supplying location param I supply just locationPort and description params so that the URL for "LOCATION" is created on demand for each corresponding interface, see my solution here
It would be good if you could push the changes into this original project so that everyone can benefit from it ;-)

@LudekStoklasa I've added that to v3.3.0, see location config option in the README. Thanks for pointing out the issue!

Seems like this issue's been addresses (or mostly addressed?..). I'm going to close it.


perf(TransferHelper): remove unnecessary checks and use yul for native token transfer

Motivation
Removes an unnecessary check for balance before transferring native tokens (the call would return false if insufficient balance anyway).
Change Summary

Remove InsufficientFunds check
Transfer ETH with inline assembly (similar implementation as solmate/utils/SafeTransferLib.sol)

Merge Checklist
Choose all relevant options below by adding an x now or at any time before submitting for review

[x] The PR title adheres to the conventional commits standard
[x] The PR has been tagged with change type label(s) (i.e. documentation, feature, bugfix, or chore)
[x] The PR's changes adhere to all the requirements in the contribution guidelines
[x] This PR does not require changes to the Farcaster protocol

Additional Context
Not a complex change, but the code should function identical to solmate/utils/SafeTransferLib.sol, which is pretty well-tested.

PR-Codex overview
Focus of the PR:
The focus of this PR is to update the TransferHelper contract to use a different revert message when there are insufficient funds for a native token transfer.
Detailed summary:

Updated the revert message in the TransferHelper contract from InsufficientFunds to CallFailed.
Modified the sendNative function in the TransferHelper contract to use inline assembly for transferring the native token and storing the success status.
Removed the unused return value in the sendNative function.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

fyi forge snapshot --match-contract GasUsage yields no changes, but I think that's because TransferHelper.sendNative is never called in any of those gas usage tests


Fix typos

Thanks for your review. I have made changes according to your feedback. Is there anything else I need to do?

Codecov Report
Patch coverage has no change and project coverage change: -1.82 :warning:

Comparison is base (44868a5) 100.00% compared to head (94474ab) 98.18%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@             Coverage Diff             @@
##            master     #329      +/-   ##
===========================================
- Coverage   100.00%   98.18%   -1.82%
===========================================
  Files           21       21
  Lines         2184     2203      +19
===========================================
- Hits          2184     2163      -21
- Misses           0       40      +40

see 6 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

Thank you for your contribution!


Not loading Images in FiveM

Hey, So I tried out your template and saw that after adding a new file and Directory hierarchy "/assets/images/img.png" it is not displaying inside FiveM.
While using npm run watch, there is a new Folder created inside nui/images containing all the images used inside the projects, so I added them into fxmanifest.lua, but still no image is displaying inside FiveM.
I tried the same replication of this Vue app inside the browser on a fresh template and it works just fine displaying the image.
Do you know any solution to that? I tried other vue Boilerplates which managed to work prefectly but most of them are overloaded with typescript and other tools or are really outdated.

Well here is a screenshot of the Image not displaying inside FiveM.
This might have something to do with the way its built? But im not sure since I'm not an expert.
P.S.: Working with Image links from the web (copying the src link and pasting into the project) works fine
thanks in advance.

Hi, I just figured it out so I thought why not help people :)
Basically my structure looks something like this:
<resource>/nui/src/assets/image.png
then I added a simple <img src="assets/image.png" to the app.vue component. Then (the most important part actually) you have to edit webpack.mix.js and copy the contents of your assets folder (or whatever folder really) to the /dist folder in the root of the application. You can do it with either single files, or just copy the entire folder into the /dist folder. I copied the entire directory with:
.copyDirectory('src/assets', 'dist/assets') (add it to the file somewhere in between lines 41 and 46)
After that build the application with whatever (npm run dev/watch/prod) and most important: restart the server.  I was getting 404 GET responses because of this and was wondering what I was doing wrong. Hope you understand it and that it helps you :)


Allow adminstrator teams members to see other teams (#18918)

Backport #18918

@Gusted please ajust backport to be uptodate ... or just cherry-picke squashed commit and force push it here ...

@6543 done


Impl Cut Operator

https://github.com/ArkArk/d-prolog/issues/7

Codecov Report

Merging #53 into master will decrease coverage by 0.34%.
The diff coverage is 19.04%.

@@            Coverage Diff             @@
##           master      #53      +/-   ##
==========================================
- Coverage   67.43%   67.08%   -0.35%
==========================================
  Files          39       39
  Lines        1569     1580      +11
==========================================
+ Hits         1058     1060       +2
- Misses        511      520       +9


issue(#223): Tab name isn't updated after file renaming

@bulantsevajo please check this PR. After your tests I'll merge it.


cgo: TestGoPathShlibGccgo fails on Raspbian/arm32

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

$ go version
go version go1.7.4 linux/arm

Does this issue reproduce with the latest release?
Unknown.  I am trying to compile go1.11.2
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GOARCH="arm"
GOBIN=""
GOEXE=""
GOHOSTARCH="arm"
GOHOSTOS="linux"
GOOS="linux"
GOPATH=""
GORACE=""
GOROOT="/usr/lib/go-1.7"
GOTOOLDIR="/usr/lib/go-1.7/pkg/tool/linux_arm"
CC="gcc"
GOGCCFLAGS="-fPIC -marm -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build017079581=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"

What did you do?
git clone https://go.googlesource.com/go
git checkout go1.11.2
cd src
./all.bash

What did you expect to see?
All passing tests, as per the instructions.
What did you see instead?
all passing upto this point:
##### ../misc/cgo/testshared
--- FAIL: TestGoPathShlibGccgo (0.27s)
    shared_test.go:67: executing go install -installsuffix=5577006791947779410 -compiler=gccgo -buildmode=shared -linkshared depBase failed exit status 1:
        src/depBase/dep.go:8:2: cannot find package "os" in any of:
                /home/jim/golang/go/src/os (from $GOROOT)
                /tmp/testshared432156425/src/os (from $GOPATH)
        src/depBase/dep.go:9:2: cannot find package "reflect" in any of:
                /home/jim/golang/go/src/reflect (from $GOROOT)
                /tmp/testshared432156425/src/reflect (from $GOPATH)
--- FAIL: TestTwoGopathShlibsGccgo (0.05s)
    shared_test.go:67: executing go install -installsuffix=5577006791947779410 -compiler=gccgo -buildmode=shared -linkshared depBase failed exit status 1:
        src/depBase/dep.go:8:2: cannot find package "os" in any of:
                /home/jim/golang/go/src/os (from $GOROOT)
                /tmp/testshared432156425/src/os (from $GOPATH)
        src/depBase/dep.go:9:2: cannot find package "reflect" in any of:
                /home/jim/golang/go/src/reflect (from $GOROOT)
                /tmp/testshared432156425/src/reflect (from $GOPATH)
FAIL
exit status 1
FAIL    _/home/jim/golang/go/misc/cgo/testshared        159.391s
2018/11/21 22:22:53 Failed: exit status 1

##### ../misc/cgo/testplugin
PASS
something
1.5
2018/11/21 22:22:56 FAILED

@ianlancetaylor

It looks like you have gccgo installed but not the gccgo libraries.  Does it work to run go build -compiler=gccgo hello.go with some simple hello.go file?

I followed the instructions listed here and got a working setup installed.  I'm not entirely sure that I can obtain the information you are requesting without removing the working copy.

If it's working for you, that's fine, and there is nothing for us to do.  Thanks.


Create a release notes when detecting a new tag

When a new tag is detected, we should create a release notes (based on the accepted or closed issue ?) and update the release panel of Gitlab / Github

Based on https://github.com/github-tools/github-release-notes


fix: test feedback fixes

Description of changes

Issue #, if available

Description of how you validated changes
Checklist

[ ] PR description included
[ ] yarn test passes
[ ] Tests are changed or added
[ ] Relevant documentation is changed or added (and PR referenced)
[ ] New AWS SDK calls or CloudFormation actions have been added to relevant test and service IAM policies

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

Merging #8647 (f03e052) into extOverrides2 (67ecb2d) will decrease coverage by 0.05%.
The diff coverage is 50.00%.

@@                Coverage Diff                @@
##           extOverrides2    #8647      +/-   ##
=================================================
- Coverage          56.65%   56.60%   -0.06%
=================================================
  Files                801      804       +3
  Lines              45670    45921     +251
  Branches            9143     9194      +51
=================================================
+ Hits               25874    25992     +118
- Misses             18988    19120     +132
- Partials             808      809       +1

Impacted Files
Coverage Δ

...fy-appsync-simulator/src/schema/directives/auth.ts
18.42% <ø> (ø)

...ppsync-simulator/src/utils/auth-helpers/helpers.ts
80.95% <ø> (ø)

.../auth-config-to-app-sync-auth-type-bi-di-mapper.ts
90.00% <0.00%> (-10.00%)
:arrow_down:

...egory-api/src/provider-utils/supported-services.ts
100.00% <ø> (ø)

.../amplify-cli-core/src/state-manager/pathManager.ts
64.10% <ø> (ø)

...c-model-plugin/src/scalars/supported-directives.ts
100.00% <ø> (ø)

...-model-plugin/src/visitors/appsync-java-visitor.ts
92.28% <0.00%> (-0.72%)
:arrow_down:

...-graphql-auth-transformer/src/utils/definitions.ts
100.00% <ø> (ø)

...on-transformer/src/graphql-function-transformer.ts
93.54% <ø> (ø)

...amplify-graphql-index-transformer/src/resolvers.ts
99.57% <ø> (ø)

... and 43 more

Continue to review full report at Codecov.

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


Revert kernel-check CLI

This CLI is currently broken (Issue #14314). Let's remove it until we have it
working properly.

(if it's easier, we could alternatively just stop linking to it from the docs but if the CLI is there, folks will find and use it and it can still be a point of confusion for users).

Had to fix up the command reference documentation, just ran make -C Documentation/ update-cmdref and added the resulting changes.

I don't believe the command was tested anywhere in the CI, so we should be good to merge.


Is there any API documentation for this library?

I don't see any API documentation or example usage in the README or linked to in the description. API documentation would be helpful to use this library outside of a wapc context.

Yeah the documentation has been "forthcoming" for a while now. @pkedy may be able to provide better information on the roadmap and timeline for the AssemblyScript MessagePack library.

Is the library currently working? I can try and figure it out from inspecting source code but would be good to know if it's in a working state or not first.

It's working an in use both for waPC and for the waSCC AssemblyScript actor SDK , but the documentation for that is also mostly non-existent right now.

@wapc Are you open to accepting PRs to add documentation? I could get something whipped up with typedoc pretty quickly.

@wapc Are you open to accepting PRs to add documentation? I could get something whipped up with typedoc pretty quickly.

@chances Absolutely open to PRs!  Would love to see how typedoc would work here. At a minimum the README needs an example which could be derived from a waSCC/wasmCloud example or generated via the new CLI using our WIDL spec (which is also in need of documentation).

@chances Absolutely open to PRs!  Would love to see how typedoc would work here. At a minimum the README needs an example which could be derived from a waSCC/wasmCloud example or generated via the new CLI using our WIDL spec (which is also in need of documentation).

Can anyone please provide some example of how to use this library in a wasm module? do I need to add anything specific in the asc configuration to make it work? or is it just a matter of adding library in a package.json and importing it in the AS code?

I'm willing to figure out some docs and update this to v0.20.x of AS


stat/distuv: fix duplicated assignment

Signed-off-by: Iskander Sharipov<EMAIL_ADDRESS>

Please remove the sign-off when this is merged.


GPU Widget not shown for my dGPU

Dev Home version
<IP_ADDRESS>
Windows build number
10.0.22624.1755
Other software
OS Build Version: 10.0.22624.1755.amd64fre.ni_release.220506-1250
.NET Version: .NET 6.0.16
Steps to reproduce the bug
I wanted to add a GPU widget to my dashboard. I pressed 'next' until my GPU will be shown which is a NVIDIA GeForce RTX 3060 Laptop GPU. But the widget never shows stats.
Expected result
I expect that my GPU card statistics will be shown on the widget.
Actual result
Empty widget preview
Included System Information
CPU: 11th Gen Intel(R) Core(TM) i5-11400H @ 2.70GHz
Physical Memory: 15.78GB (2.92GB free)
Processor Architecture: x64
Included Extensions Information
Extensions:
Microsoft.Windows.DevHome_<IP_ADDRESS>_x64__8wekyb3d8bbwe
Microsoft.Windows.DevHomeGitHubExtension_<IP_ADDRESS>_x64__8wekyb3d8bbwe

Similar thing on a HP ZBook Power G7 Mobile Workstation
CPU is Intel Core i9-10885H CPU
GPU is NVIDIA Quadro T2000
Notably, the CPU has integrated Intel UHD Graphics, and somewhere under the OS/driver's hood both the iGPU and dGPU are somewhat unified. The combined utilization of iGPU+dGPU appears in the Dev Home GPU widget as "MirrorOp Virtual Graphics Adaptor", but the individual graphs for each of the iGPU and dGPU are empty.

(Related to #948) I've got a similar issue, with the widget showing GPU activity under the unused Parsec Virtual Display Adapter device, but nothing under Intel(R) UHD Graphics or NVIDIA GeForce RTX 4080 Laptop GPU.

Come from #1826 but the difference from above is my device is a desktop.
CPU is Intel Core i9-13900ks
GPU is NVIDIA RTX 4090
Physical Memory: 63.71GB (46.24GB free)
Processor Architecture: x64
OS Build Version: 10.0.22621.2506.amd64fre.ni_release.220506-1250
.NET Version: .NET 6.0.23


It is impossible to have two different parameters for one tile from TileMapLayer

Tested versions
Godot Engine v4.3.stable.official.77dcf97d8
System information
Linux
Issue description
To be honest, I don’t quite understand whether this is a bug or normal behavior of gdscript. However, before that, I spent quite a lot of time searching for a solution and did not find it. I'm working on a 2d project in which to create a landscape map I use 24x24px tiles via TileMapLayer and thereby build a large map from them accordingly. To smooth out the corners, I use Terrain Sets in which I placed one earth-water set. This way I can create rivers, curves and other terrain effects.

But although this works, the main problem is in the creation of biomes. I can create another map for environmental objects, there are many fewer of them, but the same cannot be said about the Land Map described above.

As you can see, the map of alternative tiles is very large, the solution would be if I could copy it in the right window and simply replace the texture, but this is not possible. Setting up a dozen of these alternative cards is suicide. Changing the map texture from the player's position is a bad idea for top-down games; it works well in Terraria, but not here.
In this case, I decided to use shaders, with their help you can change the color of an individual tile through the material. But this requires checking the tile position and the array of configured values in the code. Perhaps the solution is much simpler.
Steps to reproduce
So, having come to terms with the fact that I couldn't do any of the above, I decided to test my idea on a Domain Map to limit the territory of something on the map. To do this, I use 1 gray tile + shader to change its color. The shader works on the tile and makes it red. Next you can use the array and how-then make borders there in a primitive way by designating ownership through an int number.

However, when implementing the drawing function, I am faced with the main problem, it is that the variable for an already installed tile behaves as a reference to the tile map itself, which means that a change in this tile changes it in the TileMapLayer, which essentially should not happen.
func _input(event: InputEvent) -> void:
	# paint domain
	if event is InputEventMouseButton and event.pressed:
		var mousePos = get_global_mouse_position()
		var localMousePos = domain.to_local(mousePos)
		var cell = domain.local_to_map(localMousePos)
		paintDomain(cell, 0)

@onready var domain: TileMapLayer = get_node("domain")
func paintDomain(pos: Vector2, state: int) -> void:
	print(pos)
	domain.set_cell(Vector2i(pos.x, pos.y),0,Vector2i(0, 0))
	var tile: TileData = domain.get_cell_tile_data(Vector2i(pos.x, pos.y))
	tile.material = null

I tried to solve this by creating unique shaders, materials and who knows what else. And for me this is still a bug, since as a developer I am not obliged to create all these maps myself and in the future there may be many more objects that I cannot foresee. And I still don't understand why I just can't change things individually, or even better, without using all this in code, but simply through different input parameters for the same tile.

Minimal reproduction project (MRP)
N/A

This doesn't very clearly describe what you are having problems with, please provide clear reproduction steps and what the problem is
And I'd suggest first asking in the other channels to work out what you are needing and ways to do it, and only when you have clear steps to what you think is a bug should you make a bug report

@AThousandShips
The main problem: when you change a specific fragment, the entire map changes, not just a single fragment.
I'm not sure if this is intended behavior or a bug, but it does create problems when trying to apply unique shaders or materials to certain tiles. I can't fix this by not having a function to duplicate the current atlas, and I also can't know the exact number of possible Domain Map color combinations, so changing one tile is an extremely important task for me. However, as described above, I cannot apply several different parameters to 1 tile, I just can't even have 1 tile with 2 different colors.

You mean that you can't assign specific properties to individual tiles in the map? That's a limitation, you have to make the tiles in the TileSet specific, that's pretty much the basic idea of a tilemap format
So this isn't a bug, but you might be looking for a proposal like this one:

https://github.com/godotengine/godot-proposals/issues/6606

Closing as this is a limitation and not a bug, thank you for your report nonetheless

If anyone is interested, then the overlay of what I wrote above is possible as described through the shader, but this requires taking into account the camera position, map size, camera size and also a huge array of cells. In the case of biomes, it is necessary to apply another texture to such a square. But if it were possible to have different parameters for 1 tile, This would greatly simplify everything.


Changed for scheduling to static and fixed the number of threads for …

…color conversion

The following build command was required to achieve the desired camera performance:
cmake ../ -DCMAKE_BUILD_TYPE=Release -DBUILD_WITH_OPENMP=true -DBUILD_EXAMPLES=false


Nothing to boot: No such file or directory (http://ipxe.org/2d03e13b)

Once set drivers, Virtual machine doesn't start. I tried with different ISO but i have the same errors.
i have IOS 13.3.1
My output:
Boot failed: could not read the boot disk
Booting from Floppy. . .
Boot failed: could not read the boot disk
Booting from DVD/CD. . .
Boot failed: Could not read from CDROM (code 0003)
Booting from ROM. . .
iPXE (PCI 00:04.0) starting execution. . .ok
iPXE initialising devices. . . ok
iPXE 1.0.0+ (de45) -- Open Source Network Boot Firmware -- http://ipxe.org
Features: DSN HTTP iSCSI TFTP AoE ELF MBOOT PXE bzImage Menu PXEXT
net0: 52:54:00:12:34:56 using rt18139 on 0000:00:04.0 (open)
[Link:up, TX:0  TXE:0  RX:0  RXE:0]
Configuring (net0 52:54:00:12:34:56)=. . . . . . ok
net0: <IP_ADDRESS>/<IP_ADDRESS> gw <IP_ADDRESS>
Nothing to boot: No such file or directory (http://ipxe.org/2d03e13b)
No bootable device.

https://getutm.app/guide/#quick-start

https://getutm.app/guide/#quick-start
Thanks for replying,
I followed the procedure step by step but i still have the same problem.

You likely have an ISO that’s not bootable. You can confirm this by trying it with VMware or virtual box.

You likely have an ISO that’s not bootable. You can confirm this by trying it with VMware or virtual box.

Thanks a lot, i’ve found an error in ISO file (probably due to partial download). Now i’ve reinstalled ISO and it works!

Got the same problem

Once set drivers, Virtual machine doesn't start. I tried with different ISO but i have the same errors. i have IOS 13.3.1 My output:
Boot failed: could not read the boot disk
Booting from Floppy. . . Boot failed: could not read the boot disk
Booting from DVD/CD. . . Boot failed: Could not read from CDROM (code 0003)
Booting from ROM. . .
iPXE (PCI 00:04.0) starting execution. . .ok iPXE initialising devices. . . ok
iPXE 1.0.0+ (de45) -- Open Source Network Boot Firmware -- http://ipxe.org
Features: DSN HTTP iSCSI TFTP AoE ELF MBOOT PXE bzImage Menu PXEXT
net0: 52:54:00:12:34:56 using rt18139 on 0000:00:04.0 (open) [Link:up, TX:0 TXE:0 RX:0 RXE:0] Configuring (net0 52:54:00:12:34:56)=. . . . . . ok net0: <IP_ADDRESS>/<IP_ADDRESS> gw <IP_ADDRESS> Nothing to boot: No such file or directory (http://ipxe.org/2d03e13b)
No bootable device.

Try forcing PS/2 legacy. It worked for me in Windows 2000


fix: script in readme

#138  👈
master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @gneiru and the rest of your teammates on  Graphite


[Library Manager] Request to add new library

Dear Arduino Platform Community,
I would like to request to add my library to Arduino IDE
The Github Repository
https://github.com/GhassanYusuf/NewServo
Library Properties File
https://github.com/GhassanYusuf/NewServo/blob/main/library.properties

Hi @GhassanYusuf. We have a new system for submitting libraries. The instructions are here:
https://github.com/arduino/library-registry#adding-a-library-to-library-manager
Please let me know if you have any questions.
Regards, Per


Heroku Drywall mongoDB 3.2

There is a scheduled update to MongoDB upgrade. It is now 3.0.12 is the default for new mLab deployments and it will be changing to 3.2.
Recently I cloned and deployed drywall and I am getting a mongodb connection error (see below).  I am wondering if the issue has to do with the upgrade.
MongoError: failed to connect to server [localhost:27017] on first connect

Thanks for opening an issue. I haven't done the mLab Mongo 3.2 upgrade for http://drywall.herokuapp.com/ yet.

MongoError: failed to connect to server [localhost:27017] on first connect

At first I'm suspicious about that localhost:27017 host/port. Are you sure you're using the environment variable (in my case MONGOLAB_URI)?

Yes it runs perfectly when I link to an old mongodb. The issue arises when I create a new mongodb add on.
Sent from my iPad

On Aug 15, 2016, at 10:00 PM, Reza Akhavan<EMAIL_ADDRESS>wrote:
Thanks for opening an issue. I haven't done the mLab Mongo 3.2 upgrade for http://drywall.herokuapp.com/ yet.
MongoError: failed to connect to server [localhost:27017] on first connect
At first I'm suspicious about that localhost:27017 host/port. Are you sure you're using the environment variable (in my case MONGOLAB_URI)?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Drywall has been moved to Aqua. Closing this issue.


Has the NFL ever complained about this project?

Curious about if the NFL has ever contacted the maintainer of this project (@BurntSushi) for any reason.  If a person uses this technique to pull game data as the backing code for a web project, will the NFL care?

And a follow-up; is that why this project is now unmaintained?

Curious about if the NFL has ever contacted the maintainer of this project (@BurntSushi) for any reason.

No. I don't even know that they are aware of it, but I wouldn't be surprised if they are.

If a person uses this technique to pull game data as the backing code for a web project, will the NFL care?

This is not a question for me. It is a question for a lawyer. Certainly, others have built web sites using this project, but they've been small and mostly for personal use AFAIK. To some extent, you're limited in what you can do because the data is not 100% accurate.

And a follow-up; is that why this project is now unmaintained?

No. I just don't have time for it and no longer use the project myself. It is been unmaintained for years.