apt-get update because date/time not set correctly

I used the new v1.11.0-rc3 image on RPi 3 B+ and the new RPi 4 B and they work but with a glitch.
I use the following (slightly minimised) version of my cloud-init yml file:
$ cat akka-pi-os-min.yml
#cloud-config
# vim: syntax=yaml
#

# Set your hostname here, the manage_etc_hosts will update the hosts file entries as well
hostname: static
manage_etc_hosts: false
# don't write debian.org into apt mirrors
apt_preserve_sources_list: true

# You could modify this for your own user information
users:
  - name: akkapi
    gecos: "Akka Cluster Pi User"
    sudo: ALL=(ALL) NOPASSWD:ALL
    shell: /bin/bash
    groups: users,docker,video
    plain_text_passwd: xxxx
    lock_passwd: false
    ssh_pwauth: true
    chpasswd: { expire: false }

package_update: false
package_upgrade: false
package_reboot_if_required: true

locale: "en_US.UTF-8"
timezone: "Europe/Amsterdam"

# Static IP address
write_files:
  - content: |
      persistent
      # Generate Stable Private IPv6 Addresses instead of hardware based ones
      slaac private

      # static IP configuration:
      interface eth0
      static ip_address=<IP_ADDRESS>/24
      # static ip6_address=fd51:42f8:caae:d92e::ff/64
      static routers=<IP_ADDRESS>
      static domain_name_servers=<IP_ADDRESS> <IP_ADDRESS>
    path: /etc/dhcpcd.conf

  - content: |
      # Cluster #0
      <IP_ADDRESS> node-0
      <IP_ADDRESS> node-1
      <IP_ADDRESS> node-2
      <IP_ADDRESS> node-3
      <IP_ADDRESS> node-4
    path: /etc/cluster-hosts

# These commands will be ran once on first boot only
runcmd:
  # Add cluster hosts to /etc/hosts
  - 'cat /etc/cluster-hosts >> /etc/hosts'
  - 'rm /etc/cluster-hosts'

  # Pickup the hostname changes
  - 'systemctl restart avahi-daemon'
  - date -s '24 Jul 2019 10:29'

  # Install a few extra packages - this could be done in the package section,
  # but if we do it here, the installation progress tracker will start earlier.
  - apt-get update --allow-releaseinfo-change
  - apt-get -y install unzip
  - apt-get -y install tmux
  - apt-get -y install file
  - apt-get -y install jq
  - apt-get -y install dnsutils
  - apt-get -y apt-install transport-https

  # Install OpenJDK 8
  - apt-get install -y galternatives openjdk-8-jdk

Notice the date -s '24 Jul 2019 10:29' command run in the runcmd phase.
When this line is omitted, apt-get update fails because the date and time is set approximately 3 days earlier than the actual date.
If I run the date command right before setting the current time, it outputs the following:
Sun 21 Jul 2019 04:47:52 PM CEST (to be complete: this is during a first boot at around 4:39 PM CET on July 24th).
I may be missing something obvious, but I have no clue what it could be.
This used to work flawlessly with older Hypriot images (e.g. version 1.10.0).

This might be a problem of all services starting in parallel. The Raspberry Pi has no battery powered clock, it uses a fake clock with a time stamp of the last shutdown AFAIK.
Maybe the boot order has change a little bit in Buster. Maybe there is a command to trigger ntp to sync current date.

Maybe the boot sequence can be adapted to work with a modified NTP config that allows for faster convergence and which is switched to the default one after some time (before any user stuff as in runcmd is run).
I can look into it but I have no experience with the inner workings of buster/cloud-init.
If I would have some good pointers on how to get started, I can take a stab at it.

Op 25 jul. 2019 om 08:25 heeft Stefan Scherer<EMAIL_ADDRESS>het volgende geschreven:
This might be a problem of all services starting in parallel. The Raspberry Pi has no battery powered clock, it uses a fake clock with a time stamp of the last shutdown AFAIK.
Maybe the boot order has change a little bit in Buster. Maybe there is a command to trigger ntp to sync current date.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@eloots Yes, please try it. Would be great to get this resolved.

@DieterReuter @StefanScherer
Here's an intermediate update - I haven't looked at modifying the boot sequence [yet], but I've run a number of experiments to observe behaviour and have come to the following conclusions.

The initial date that is set is somehow linked to the time the image was built. Can't tell for sure; but it's set to July 21. It would explain why testing the new image shortly after it was created worked: the clock difference on the Pi with the actual time was small enough to make apt-get update work.

From /var/log/bootstrap.log:
Current default time zone: 'Etc/UTC'
Local time is now:      Sun Jul 21 09:35:00 UTC 2019.
Universal Time is now:  Sun Jul 21 09:35:00 UTC 2019.
Run 'dpkg-reconfigure tzdata' if you wish to change it.

First experiment
I changed the runcmd sequence to print the date/time at 10s intervals and observed that the time is updated correctly at about 40s into the runcmd run. So, as a poor man's solution, one could insert a sleep 50 before running apt-get update. Not optimal obviously...
Second experiment
From one of the runs, here's the time when ntpd is started (taken from /var/log/syslog)
Jul 21 14:47:32 node-1 ntpd[387]: ntpd<EMAIL_ADDRESS>(1): Starting
Jul 21 14:47:32 node-1 dhcpcd-run-hooks[405]: wlan0: not interacting with wpa_supplicant(8)
Jul 21 14:47:32 node-1 ntpd[387]: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 104:111
Jul 21 14:47:32 node-1 systemd[1]: Started Network Time Service.

ntpd has a min. poll interval of 64s which will grow to max 1024s in case it cannot reach any time server. From the logs, it can be seen that ntpd is started before a network address is acquired (on eth0 which is connected to a router). Hence, when the runcmd sequence starts, ntpd may actually not poll any time server, even though, in the mean time, eth0 has come up. That explains the behaviour seen in experiment 1.
I changed my runcmd phase to look as follows:
runcmd:
  - echo 'kill ntpd'
  - pkill ntpd
  - sleep 1

  # Add cluster hosts to /etc/hosts
  - 'cat /etc/cluster-hosts >> /etc/hosts'
  - 'rm /etc/cluster-hosts'

  # Pickup the hostname changes
  - echo '     '
  - echo 'Pickup the hostname changes'
  - echo '     '

  - 'systemctl restart avahi-daemon'

  - echo 'starting ntpd'
  - /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 104:111
  - pgrep -l -f ntp
  - date
  - sleep 1
  - date
  - sleep 1
  - date
  - sleep 1
  - date
  - sleep 1
  - date
  - sleep 1
  - date
  - sleep 1
  - date
  - sleep 1
  - date
  - sleep 1
  - date
  - sleep 1
  - date
  - sleep 1
  - date
<elided>

This results in the following output in /var/log/syslog
Jul 21 14:47:32 node-1 ntpd[387]: ntpd<EMAIL_ADDRESS>(1): Starting
Jul 21 14:47:32 node-1 dhcpcd-run-hooks[405]: wlan0: not interacting with wpa_supplicant(8)
Jul 21 14:47:32 node-1 ntpd[387]: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 104:111
Jul 21 14:47:32 node-1 systemd[1]: Started Network Time Service.
Jul 21 14:47:32 node-1 dhcpcd[377]: eth0: waiting for carrier
Jul 21 14:47:32 node-1 ntpd[414]: proto: precision = 0.815 usec (-20)
Jul 21 14:47:32 node-1 kernel: [   95.372024] bcmgenet fd580000.genet: configuring instance for external RGMII (no delay)
Jul 21 14:47:32 node-1 kernel: [   95.372274] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Jul 21 14:47:32 node-1 ntpd[414]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): good hash signature
Jul 21 14:47:32 node-1 ntpd[414]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): loaded, expire=2019-12-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37
Jul 21 14:47:32 node-1 ntpd[414]: Listen and drop on 0 v6wildcard [::]:123
Jul 21 14:47:32 node-1 ntpd[414]: Listen and drop on 1 v4wildcard <IP_ADDRESS>:123
Jul 21 14:47:32 node-1 dhcpcd[377]: wlan0: waiting for carrier
Jul 21 14:47:32 node-1 ntpd[414]: Listen normally on 2 lo <IP_ADDRESS>:123
Jul 21 14:47:32 node-1 ntpd[414]: Listen normally on 3 lo [::1]:123
Jul 21 14:47:32 node-1 ntpd[414]: Listening on routing socket on fd #20 for interface updates
Jul 21 14:47:32 node-1 ntpd[414]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Jul 21 14:47:32 node-1 kernel: [   95.406526] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Jul 21 14:47:32 node-1 kernel: [   95.406757] brcmfmac: power management disabled
Jul 21 14:47:32 node-1 ntpd[414]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Jul 21 14:47:32 node-1 dhcpcd[377]: wlan0: carrier acquired
Jul 21 14:47:32 node-1 systemd[1]: Started OpenBSD Secure Shell server.
Jul 21 14:47:32 node-1 dhcpcd[377]: DUID 00:01:00:01:24:c7:37:84:dc:a6:32:06:9f:7e
Jul 21 14:47:32 node-1 dhcpcd[377]: wlan0: IAID 32:06:9f:7e
Jul 21 14:47:32 node-1 dhcpcd[377]: wlan0: adding address fe80::1659:c918:f18e:abd8
Jul 21 14:47:32 node-1 dhcpcd[377]: wlan0: carrier lost
Jul 21 14:47:32 node-1 dhcpcd[377]: wlan0: deleting address fe80::1659:c918:f18e:abd8
Jul 21 14:47:33 node-1 ntpd[414]: error resolving pool 0.debian.pool.ntp.org: Temporary failure in name resolution (-3)
Jul 21 14:47:33 node-1 kernel: [   96.391831] bcmgenet fd580000.genet eth0: Link is Down
Jul 21 14:47:34 node-1 ntpd[414]: error resolving pool 1.debian.pool.ntp.org: Temporary failure in name resolution (-3)
Jul 21 14:47:35 node-1 kernel: [   97.853048] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
Jul 21 14:47:35 node-1 kernel: [   97.861438] Bridge firewalling registered
Jul 21 14:47:35 node-1 cloud-init[391]: Cloud-init v. 18.3 running 'modules:config' at Sun, 21 Jul 2019 14:47:33 +0000. Up 95.90 seconds.
Jul 21 14:47:35 node-1 systemd[1]: Started Apply the settings specified in cloud-config.
Jul 21 14:47:35 node-1 ntpd[414]: error resolving pool 2.debian.pool.ntp.org: Temporary failure in name resolution (-3)
Jul 21 14:47:36 node-1 ntpd[414]: error resolving pool 3.debian.pool.ntp.org: Temporary failure in name resolution (-3)
Jul 21 14:47:36 node-1 avahi-daemon[355]: Joining mDNS multicast group on interface docker0.IPv4 with address <IP_ADDRESS>.
Jul 21 14:47:37 node-1 dhcpcd[377]: eth0: carrier acquired
Jul 21 14:47:37 node-1 kernel: [  100.551944] bcmgenet fd580000.genet eth0: Link is Up - 1Gbps/Full - flow control off
Jul 21 14:47:37 node-1 kernel: [  100.552005] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Jul 21 14:47:37 node-1 dhcpcd[377]: eth0: IAID 32:06:9f:7d
Jul 21 14:47:37 node-1 dhcpcd[377]: eth0: adding address fe80::ed33:90d:fd0e:4f7d
Jul 21 14:47:37 node-1 dhcpcd[377]: eth0: probing address <IP_ADDRESS>/24
Jul 21 14:47:37 node-1 avahi-daemon[355]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::ed33:90d:fd0e:4f7d.
Jul 21 14:47:37 node-1 avahi-daemon[355]: New relevant interface eth0.IPv6 for mDNS.
Jul 21 14:47:37 node-1 avahi-daemon[355]: Registering new address record for fe80::ed33:90d:fd0e:4f7d on eth0.*.
Jul 21 14:47:38 node-1 dhcpcd[377]: eth0: soliciting an IPv6 router
Jul 21 14:47:40 node-1 ntpd[414]: Listen normally on 4 eth0 [fe80::ed33:90d:fd0e:4f7d%2]:123
Jul 21 14:47:40 node-1 ntpd[414]: new interface(s) found: waking up resolver
Jul 21 14:47:42 node-1 dhcpcd[377]: eth0: using static address <IP_ADDRESS>/24
Jul 21 14:47:42 node-1 avahi-daemon[355]: Joining mDNS multicast group on interface eth0.IPv4 with address <IP_ADDRESS>.
Jul 21 14:47:42 node-1 avahi-daemon[355]: New relevant interface eth0.IPv4 for mDNS.
Jul 21 14:47:42 node-1 dhcpcd[377]: eth0: adding route to <IP_ADDRESS>/24
Jul 21 14:47:42 node-1 avahi-daemon[355]: Registering new address record for <IP_ADDRESS> on eth0.IPv4.
Jul 21 14:47:42 node-1 dhcpcd[377]: eth0: adding default route via <IP_ADDRESS>
Jul 21 14:47:43 node-1 ntpd[414]: Listen normally on 5 eth0 <IP_ADDRESS>:123
Jul 21 14:47:43 node-1 ntpd[414]: new interface(s) found: waking up resolver
Jul 21 14:48:03 node-1 cloud-init[650]: Regenerating machine id
Jul 21 14:48:03 node-1 cloud-init[650]: kill ntpd
Jul 21 14:48:03 node-1 ntpd[414]: ntpd exiting on signal 15 (Terminated)
Jul 21 14:48:03 node-1 systemd[1]: ntp.service: Succeeded.
Jul 21 14:48:04 node-1 cloud-init[650]:
Jul 21 14:48:04 node-1 cloud-init[650]: Pickup the hostname changes
Jul 21 14:48:04 node-1 cloud-init[650]:
Jul 21 14:48:04 node-1 avahi-daemon[355]: Got SIGTERM, quitting.
Jul 21 14:48:04 node-1 avahi-daemon[355]: Leaving mDNS multicast group on interface docker0.IPv4 with address <IP_ADDRESS>.
Jul 21 14:48:04 node-1 systemd[1]: Stopping Avahi mDNS/DNS-SD Stack...
Jul 21 14:48:04 node-1 avahi-daemon[355]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::ed33:90d:fd0e:4f7d.
Jul 21 14:48:04 node-1 systemd[1]: avahi-daemon.service: Succeeded.
Jul 21 14:48:04 node-1 avahi-daemon[355]: Leaving mDNS multicast group on interface eth0.IPv4 with address <IP_ADDRESS>.
Jul 21 14:48:04 node-1 avahi-daemon[355]: avahi-daemon 0.7 exiting.
Jul 21 14:48:04 node-1 systemd[1]: Stopped Avahi mDNS/DNS-SD Stack.
Jul 21 14:48:04 node-1 systemd[1]: Starting Avahi mDNS/DNS-SD Stack...
Jul 21 14:48:04 node-1 avahi-daemon[668]: Process 355 died: No such process; trying to remove PID file. (/run/avahi-daemon//pid)
Jul 21 14:48:04 node-1 avahi-daemon[668]: Found user 'avahi' (UID 107) and group 'avahi' (GID 113).
Jul 21 14:48:04 node-1 avahi-daemon[668]: Successfully dropped root privileges.
Jul 21 14:48:04 node-1 avahi-daemon[668]: avahi-daemon 0.7 starting up.
Jul 21 14:48:04 node-1 avahi-daemon[668]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Jul 21 14:48:04 node-1 avahi-daemon[668]: Successfully called chroot().
Jul 21 14:48:04 node-1 avahi-daemon[668]: Successfully dropped remaining capabilities.
Jul 21 14:48:04 node-1 avahi-daemon[668]: No service file found in /etc/avahi/services.
Jul 21 14:48:04 node-1 avahi-daemon[668]: Joining mDNS multicast group on interface docker0.IPv4 with address <IP_ADDRESS>.
Jul 21 14:48:04 node-1 avahi-daemon[668]: New relevant interface docker0.IPv4 for mDNS.
Jul 21 14:48:04 node-1 avahi-daemon[668]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::ed33:90d:fd0e:4f7d.
Jul 21 14:48:04 node-1 avahi-daemon[668]: New relevant interface eth0.IPv6 for mDNS.
Jul 21 14:48:04 node-1 avahi-daemon[668]: Joining mDNS multicast group on interface eth0.IPv4 with address <IP_ADDRESS>.
Jul 21 14:48:04 node-1 avahi-daemon[668]: New relevant interface eth0.IPv4 for mDNS.
Jul 21 14:48:04 node-1 avahi-daemon[668]: Network interface enumeration completed.
Jul 21 14:48:04 node-1 avahi-daemon[668]: Registering new address record for <IP_ADDRESS> on docker0.IPv4.
Jul 21 14:48:04 node-1 avahi-daemon[668]: Registering new address record for fe80::ed33:90d:fd0e:4f7d on eth0.*.
Jul 21 14:48:04 node-1 avahi-daemon[668]: Registering new address record for <IP_ADDRESS> on eth0.IPv4.
Jul 21 14:48:04 node-1 cloud-init[650]: starting ntpd
Jul 21 14:48:04 node-1 ntpd[671]: ntpd<EMAIL_ADDRESS>(1): Starting
Jul 21 14:48:04 node-1 ntpd[671]: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 104:111
Jul 21 14:48:04 node-1 ntpd[673]: proto: precision = 0.797 usec (-20)
Jul 21 14:48:04 node-1 ntpd[673]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): good hash signature
Jul 21 14:48:04 node-1 ntpd[673]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): loaded, expire=2019-12-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37
Jul 21 14:48:04 node-1 ntpd[673]: Listen and drop on 0 v6wildcard [::]:123
Jul 21 14:48:04 node-1 ntpd[673]: Listen and drop on 1 v4wildcard <IP_ADDRESS>:123
Jul 21 14:48:04 node-1 ntpd[673]: Listen normally on 2 lo <IP_ADDRESS>:123
Jul 21 14:48:04 node-1 ntpd[673]: Listen normally on 3 eth0 <IP_ADDRESS>:123
Jul 21 14:48:04 node-1 ntpd[673]: Listen normally on 4 lo [::1]:123
Jul 21 14:48:04 node-1 ntpd[673]: Listen normally on 5 eth0 [fe80::ed33:90d:fd0e:4f7d%2]:123
Jul 21 14:48:04 node-1 ntpd[673]: Listening on routing socket on fd #22 for interface updates
Jul 21 14:48:04 node-1 ntpd[673]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Jul 21 14:48:04 node-1 ntpd[673]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Jul 21 14:48:04 node-1 cloud-init[650]: 673 ntpd
Jul 21 14:48:04 node-1 cloud-init[650]: Sun 21 Jul 2019 04:48:04 PM CEST
Jul 21 14:48:05 node-1 avahi-daemon[668]: Server startup complete. Host name is node-1.local. Local service cookie is<PHONE_NUMBER>.
Jul 21 14:48:05 node-1 ntpd[673]: Soliciting pool server <IP_ADDRESS>
Jul 21 14:48:06 node-1 ntpd[673]: Soliciting pool server <IP_ADDRESS>
Jul 21 14:48:06 node-1 cloud-init[650]: Sun 21 Jul 2019 04:48:06 PM CEST
Jul 21 14:48:07 node-1 ntpd[673]: Soliciting pool server <IP_ADDRESS>
Jul 21 14:48:07 node-1 ntpd[673]: Soliciting pool server <IP_ADDRESS>
Jul 21 14:48:07 node-1 cloud-init[650]: Sun 21 Jul 2019 04:48:07 PM CEST
Jul 21 14:48:08 node-1 ntpd[673]: Soliciting pool server <IP_ADDRESS>
Jul 21 14:48:08 node-1 ntpd[673]: Soliciting pool server <IP_ADDRESS>
Jul 21 14:48:08 node-1 ntpd[673]: Soliciting pool server <IP_ADDRESS>
Jul 21 14:48:08 node-1 cloud-init[650]: Sun 21 Jul 2019 04:48:08 PM CEST
Jul 21 14:48:09 node-1 ntpd[673]: Soliciting pool server <IP_ADDRESS>
Jul 21 14:48:09 node-1 ntpd[673]: Soliciting pool server <IP_ADDRESS>
Jul 21 14:48:09 node-1 cloud-init[650]: Sun 21 Jul 2019 04:48:09 PM CEST
Jul 21 14:48:10 node-1 ntpd[673]: Soliciting pool server <IP_ADDRESS>
Jul 21 14:48:10 node-1 ntpd[673]: Soliciting pool server 2a0e:f780::3
Jul 21 14:48:10 node-1 cloud-init[650]: Sun 21 Jul 2019 04:48:10 PM CEST
Jul 21 14:48:11 node-1 cloud-init[650]: Sun 21 Jul 2019 04:48:11 PM CEST
Jul 21 14:48:12 node-1 cloud-init[650]: Sun 21 Jul 2019 04:48:12 PM CEST
Jul 21 14:48:13 node-1 cloud-init[650]: Sun 21 Jul 2019 04:48:13 PM CEST
Jul 25 12:34:05 node-1 ntpd[673]: receive: Unexpected origin timestamp 0xe0def9ae.6ea976cf does not match aorg<PHONE_NUMBER>.00000000 from<EMAIL_ADDRESS>xmt 0xe0e4203d.464bd615
Jul 25 12:34:05 node-1 ntpd[673]: receive: Unexpected origin timestamp 0xe0def9ae.6eaeeaef does not match aorg<PHONE_NUMBER>.00000000 from<EMAIL_ADDRESS>xmt 0xe0e4203d.45d9925a
Jul 25 12:34:05 node-1 systemd[1]: Starting Daily man-db regeneration...
Jul 25 12:34:05 node-1 systemd[1]: Starting Rotate log files...
Jul 25 12:34:05 node-1 cloud-init[650]: Thu 25 Jul 2019 02:34:05 PM CEST
Jul 25 12:34:05 node-1 systemd[1]: logrotate.service: Succeeded.

The sequence of interesting events after the restart of ntpd:
Jul 21 14:48:04 node-1 cloud-init[650]: starting ntpd
Jul 21 14:48:04 node-1 ntpd[671]: ntpd<EMAIL_ADDRESS>(1): Starting
Jul 21 14:48:04 node-1 cloud-init[650]: 673 ntpd
Jul 21 14:48:04 node-1 cloud-init[650]: Sun 21 Jul 2019 04:48:04 PM CEST
Jul 21 14:48:06 node-1 cloud-init[650]: Sun 21 Jul 2019 04:48:06 PM CEST
Jul 21 14:48:07 node-1 cloud-init[650]: Sun 21 Jul 2019 04:48:07 PM CEST
Jul 21 14:48:08 node-1 cloud-init[650]: Sun 21 Jul 2019 04:48:08 PM CEST
Jul 21 14:48:09 node-1 cloud-init[650]: Sun 21 Jul 2019 04:48:09 PM CEST
Jul 21 14:48:10 node-1 cloud-init[650]: Sun 21 Jul 2019 04:48:10 PM CEST
Jul 21 14:48:11 node-1 cloud-init[650]: Sun 21 Jul 2019 04:48:11 PM CEST
Jul 21 14:48:12 node-1 cloud-init[650]: Sun 21 Jul 2019 04:48:12 PM CEST
Jul 21 14:48:13 node-1 cloud-init[650]: Sun 21 Jul 2019 04:48:13 PM CEST
Jul 25 12:34:05 node-1 ntpd[673]: receive: Unexpected origin timestamp 0xe0def9ae.6ea976cf does not match aorg<PHONE_NUMBER>.00000000 from<EMAIL_ADDRESS>xmt 0xe0e4203d.464bd615
Jul 25 12:34:05 node-1 ntpd[673]: receive: Unexpected origin timestamp 0xe0def9ae.6eaeeaef does not match aorg<PHONE_NUMBER>.00000000 from<EMAIL_ADDRESS>xmt 0xe0e4203d.45d9925a
Jul 25 12:34:05 node-1 systemd[1]: Starting Daily man-db regeneration...
Jul 25 12:34:05 node-1 systemd[1]: Starting Rotate log files...
Jul 25 12:34:05 node-1 cloud-init[650]: Thu 25 Jul 2019 02:34:05 PM CEST

This shows that the correct time is set by ntpd 9 to 10 seconds after it is restarted.
So, here's what I think is a correct solution to this problem: ntpd should only be started when eth0 is up. From the above log, eth0 is up at:
Jul 21 14:47:42 node-1 dhcpcd[377]: eth0: using static address <IP_ADDRESS>/24

This is 10s after ntpd is started.
Jul 21 14:47:32 node-1 ntpd[387]: ntpd<EMAIL_ADDRESS>(1): Starting

Other
There's a way to set the correct time from time servers using ntpdate:
$ sudo ntpdate -u -s 0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3..debian.pool.ntp.org`

That could be done as part of the runcmd sequence, but there's a catch 22: ntpdate isn't installed on buster by default. It can't be installed during the execution of runcmd as apt-get update needs to run first and that doesn't work because of the clock skew...
If the v1.11.0 image would be changed to also include ntpdate, that would enable a simple and fast fix.
WDYT?

This is the temp. workaround I have in my cloud-init build definition:
# Static IP address
write_files:
  - content: |
      persistent
      # Generate Stable Private IPv6 Addresses instead of hardware based ones
      slaac private

      # static IP configuration:
      interface eth0
      static ip_address=<IP_ADDRESS>/24
      # static ip6_address=fd51:42f8:caae:d92e::ff/64
      static routers=<IP_ADDRESS>
      static domain_name_servers=<IP_ADDRESS> <IP_ADDRESS>
    path: /etc/dhcpcd.conf
  # Pickup the hostname changes
  - 'systemctl restart avahi-daemon'

  # Workaround for Hypriot initial date/time setting
  - date
  - service ntp --full-restart
  - sleep 15
  - date

I'm using the packages: option of cloud-config to install packages on first boot. This worked with version 1.10.0 but with 1.11.1 it does not.
Example config:
package_update: true
package_upgrade: true
package_reboot_if_required: true

packages:
  - fail2ban
  - vim
  - unzip
  - tree
  - ssmtp
  - rsync
  - ntfs-3g
  - file
  - pv

the cloud-init-output.log contains:
Release file for http://raspbian.raspberrypi.org/raspbian/dists/buster/InRelease is not valid yet (invalid for another 4d 10h 10min 22s). Updates for this repository will not be applied.
...
2019-07-26 06:36:31,308 - util.py[WARNING]: Package update failed
...
2019-07-26 06:36:31,562 - util.py[WARNING]: Failed to install packages: ['fail2ban', 'vim', 'unzip', 'tree', 'ssmtp', 'rsync', 'ntfs-3g', 'file']

@Legion2 The problem you're seeing is the one described in this issue. What can be confusing is that 1.10.0 may have worked if you used it shortly after is was released (this is true for any version btw - see explanation in the comments above).
You can use the workaround I describe above (install packages in the runcmd phase & restart the ntp service + introduce a delay to allow for ntp to set the date/time correctly.
I don't know why this did worked with the previous version of Hypriot (<= 1.10.0) on all Raspberry Pi's up-to RPi 3 B+... I think that the problem actually existed in that case too, but it occurred only with a low frequency: I've seen this happen occasionally and I flashed quite a large number of cards (more than 200).
All in all, as Stefan said, the "root cause" is that the RPi doesn't have an RTC (Real Time Clock).

it uses a fake clock with a time stamp of the last shutdown AFAIK

I think I get away with editing /etc/fake-hwclock.data, i.e. virt-edit  -a ${IMAGE} --edit "s/.*/$(date '+%Y-%m-%d %X')/"  /etc/fake-hwclock.data

Maybe the fake-hwclock should be set by the flash tool. This will make the time offset only a few minutes, when you start the image after you flashed it on the sd card.

Great idea about setting passing the current date via the flashed image. A clock running behind in the order of minutes should be ok

Op 4 aug. 2019 om 10:43 heeft Leon Kiefer<EMAIL_ADDRESS>het volgende geschreven:
Maybe the fake-hwclock should be set by the flash tool. This will make the time offset only a few minutes, when you start the image after you flashed it on the sd card.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@StefanScherer @DieterReuter @Legion2
I went ahead and created a fix (or hack) that solves this problem in an easy manner by a small adaptation of the flash command. A PR is waiting for review in HypriotOS/flash.
In short, what it does is to add a date -s command as the first command in the runcmd section of cloud-init (and if such a section is not present, it adds it first at the end of the file).

I think this is now fixed with hypriot/flash#162 and released in v1.12.0 and version 2.5.0 of flash tool.

@Legion2 indeed. Closing

Would it not be better to fix this in the cloud-init start up than in the flash tool? I came across this issue after having imaged 2 SD cards already and had several more to go. Since the flash tool is only *nix compatible, it isn't a real universal solution.
Could we use something like cat </dev/tcp/time.nist.gov/13 to get the real date and use that to check if ntp has successfully updated yet? (as a personal hack, are while loops supported in runcmd?)

I usually resolve with a configuration script, written with cloud-init write_files.
If you want to use NTP (already installed with the last OS image)
# Write config files
write_files:
  - content: |
      #!/bin/bash
      # Force update time (NTP will be used instead of systemd-timesyncd). Ntp is installed by default on this image
      systemctl stop ntp
      ntpd -q -g
      systemctl start ntp
      # Wait for time update
      sleep 10
      # Start APT install
      apt-get update -y
      # Install packages
      apt-get install -y ...............................

    path: /scripts/init_config.sh
    permissions: 0777

If you want to use the default NTP client (systemd-timesyncd) usually used with ubuntu/debian/raspbian you have to uninstall ntp package because you can not use both systems
# Write config files
write_files:
  - content: |
      #!/bin/bash
      # Set NTP with default systemd-timesyncd (and remove ntp package, because you can not use both) and reboot the service to force update the time
      apt-get purge -y --auto-remove ntp
      timedatectl set-ntp true
      systemctl stop systemd-timesyncd
      systemctl start systemd-timesyncd
      # Wait for time update
      sleep 5
      # Start APT install
      apt-get update -y
      # Install packages
      apt-get install -y ...............................

    path: /scripts/init_config.sh
    permissions: 0777

I usually use the second way if I don't need a full ntp client/server.
Then you can run the script with cloud-init runcmd
# Execute commands to complete initialization
runcmd:
  # Pickup the hostname changes
  - 'systemctl restart avahi-daemon'
  # Activate WiFi interface (comment if you don't need it)
  - 'ifup wlan0'
  # Wait wifi connecting
  - 'sleep 15'
  # Execute the initial configuration
  - [ bash, -c, "cd /scripts && ./init_config.sh" ]

You can also put all your commands here if you like. I prefer separating the things putting them inside scripts, because I do also other configurations. If you want to install packages you need always to wait for the wifi coming up and then the time sync.
P.S. If you want to install and enable byobu for a target user (not working if you use the cloud-init module) you can use
apt install -y byobu
su target_user -c byobu-enable

Hope this help.


Finish Python 2 and 3 compat: metaclasses, builtins

Ran futurize stage2, see http://python-future.org/futurize_cheatsheet.html.
python-future appears to be the current choice (e.g., over six) for
helping to maintain a codebase that's Python 2 and Python 3 compatible.
eight is another option but it appears targeted at people starting from
a Python 3 codebase.
Note that you do need to use the Python 3 syntax for range,
filter, and zip (e.g., range now calls xrange under Python 2.)

There are a couple of tests that fail but I think they were failing before this (mostly import errors (ipdb and plt from matplotlib).

Awesome, thanks.
If you've got them handy, can you paste me those errors?

Sure. I just put them in #26.


[Virtual eFuse Logs] Add more logging for virtual efuses (IDFGH-9137)

I've long had these logs in my own code base and found them useful. Figured I should make a PR.

prepend logs related to virtual efuses with "Virtual eFuses:"
more logs for loading eFuses from flash
log the virtual fuses bytes when we update them, very useful.

Note: these logs only are compiled when CONFIG_EFUSE_VIRTUAL and/or CONFIG_EFUSE_VIRTUAL_KEEP_IN_FLASH is enabled.
Note2: Like all other virtual fuse logs, we use LOGW because virtual fuses are not the "normal flow of operation".

There is another point of view why we can not use these changes - the log component has esp_log_level_set(tag, log_level) API that helps to change the log level for a component by TAG. TAG depends on virtual efuse mode. So if we change the TAG for efuse then this functionality will not work need to update the given tag as well.
And one more thing is - we need to update from efuse to efuse (virtual) in entire the efuse component not just in utility files.

okay.
I'll go back to my original PR that just changed a few of the messages to indicate they were related to virtual efuse.

@KonstantinKondrashov , made some changes based on your feedback. Let me know your thoughts!

Hi @chipweinberger!

I would rather add it to esp_efuse_utility_burn_efuses() instead of into chip-specific files. The functionality that you added is not chip related. I have another idea, see below.
You can create a new API function that will print range_write_addr_blocks (it contains efuses only for burning). It will be called under your Kconfig option from esp_efuse_utility_burn_efuses() before the burning. For virt mode and for your needs (as I understand), you just want to print diff of blocks, it does not matter that we need to take blocks before and after the burn. See the code below.
Looks good to add esp_efuse_utility_debug_dump_single_block().

esp_err_t esp_efuse_utility_burn_efuses(void)
{
    ++s_burn_counter;
#if CONFIG_EFUSE_VIRTUAL_LOG_ALL_WRITES
    esp_efuse_utility_debug_dump_prepared_data();
#endif
    esp_err_t err = esp_efuse_utility_burn_chip();
    ++s_burn_counter;
    return err;
}

#if CONFIG_EFUSE_VIRTUAL_LOG_ALL_WRITES
esp_efuse_utility_debug_dump_prepared_data()
{
    for (int num_block = 0; num_block < EFUSE_BLK_MAX; num_block++) {
        int subblock = 0;
        for (uint32_t addr_wr_block = range_write_addr_blocks[num_block].start; addr_wr_block <= range_write_addr_blocks[num_block].end; addr_wr_block += 4) {
            if (virt_blocks[num_block][subblock++] != REG_READ(addr_wr_block)) {
                esp_efuse_utility_debug_dump_prepared_single_block(num_block );
                break;
            }
        }
    }
}
#endif

@KonstantinKondrashov
Yes, that looks more reasonable! Implemented!

Thank you for the update. I left some comments, LGTM!

@KonstantinKondrashov I think you forgot to
"submit" the comments!

Appreciate your effort as well!

@KonstantinKondrashov should we rename EFUSE_VIRTUAL_LOG_ALL_WRITES to EFUSE_LOG_ALL_WRITES ? It looks like it should work even when virtual fuses are not enabled now?
( or EFUSE_LOG_BURNS?)
also maybe the dump_pending function we added would be better named dump_pending_changes?


Default shared HttpClientTransport might not reflect DNS changes

Default shared HttpClientTransport is currently constructed as follows:
var httpClientHandler = new HttpClientHandler();
return new HttpClient(httpClientHandler);

in the https://github.com/Azure/azure-sdk-for-net/blob/f92de12bd669d9dd5f64dd1490be773de69b5dbb/sdk/core/Azure.Core/src/Pipeline/HttpClientTransport.cs#L128
.
The transport (and by extension the SDK clients) are encouraged to be used as singleton as described e.g. here
https://devblogs.microsoft.com/azure-sdk/lifetime-management-and-thread-safety-guarantees-of-azure-sdk-net-clients/ .
I think that this combination is subjected to the well known issue  of HttpClient that causes DNS changes not to be reflected.
Should the HttpClientTransport create its HttpClient with the newer SocketsHttpHandler to prevent the issue, as described e.g. here
https://www.stevejgordon.co.uk/httpclient-connection-pooling-in-dotnet-core
?
I have something like this on my mind:
var socketsHandler = new SocketsHttpHandler
{
    PooledConnectionLifetime = TimeSpan.FromMinutes(4),
    PooledConnectionIdleTimeout = TimeSpan.FromMinutes(4),
};

var httpClient= new HttpClient(socketsHandler);

Thank you for your feedback.  Tagging and routing to the team member best able to assist.

Yes, I think we want a shorter timeout than infinity. 4 minutes might be too short but I'll work on figuring out the correct one.

Looking at the code, it seems the issue was resolved for .net core 2.1+ (SocketsHttpHandler) and .net framework (HttpWebRequestTransport), but not resolved for .net standard 2.0?


LoadConstant nodes can't have OrderEdges

At present Nodes are only allowed one kind of other_port_kind. This seems like an artificial restriction, which good taste demands should be lifted, but "LoadConstant nodes can't have OrderEdges" does seem like a limitation.
In my mind LoadConstant is an operation with side effects. Memory side effects being obvious, but also LoadConstant of a Value::Function can be read as compiling that value. As such, users should be able to impose an order on two LoadConstant operations to control the order of their side effects.
Weaker arguments for nodes to have multiple other_port_kinds:

Case nodes in a conditional are interpreted with respect to their index into their parent. This is ugly, one could instead demand, or allow, that they have order edges which induce a total order, and use that total order to assign them an index.
DataFlowBlocks could get indices in the same was as Case above.

edges spec issue: https://github.com/CQCL/hugr/issues/848

Not an issue, demonstrated in https://github.com/CQCL/hugr/pull/1293


Possible to move calculations to host computer?

Hey there! Really nice work on this! I'm very interested in using this code; however, I'd like to see if the measurement speeds can be increased dramatically. What do you think the bottleneck is for the measurement speed?
I noticed you do a few MCU-side calculations. Would it be faster if you simply stream the IQ data to the host computer and have it perform the necessary calculations? Is this feasible?

@mbe9a are you talking about the library itself or one of the examples that use it?

Sorry not the library. The measureVNA.py example specifically is what I'm talking about.


Relicense to allow usage of source code without disclosure.

The MIT or Apache licences would be more appropriate than GPL.

I would really appreciate a license change. I need a neural net library for some games I'm writing and I don't want to open source my games but I would contribute new code and fixes for production use of this library if it was licensed under MIT or Apache.

I would really appreciate a license change. I need a neural net library for some games I'm writing and I don't want to open source my games but I would contribute new code and fixes for production use of this library if it was licensed under MIT or Apache.

Unfortunately, I don't think this library could be used in production. It lacks many features, and the only reason I created it in the first place was to learn the fundamentals of neural networks myself. 😅 Plus the fact that the available implementations weren't created with readability in mind as much as functionality.
Thanks for the comment, though! I completely forgot about following up on this issue. I'll get to it right away. 😄

Resolved in 37aa740.


Use Node as isDeleteTarget argument

Fixes: https://github.com/prestosql/presto/issues/6294
Replaces: https://github.com/prestosql/presto/pull/6288
As a followup we probably should pursue an approach to store Analysis.target as a NodeRef instead QualifiedObjectName. There is a chance that a single query contains a table that is a delete target more than once. We should not treat all those occurrences as delete target.

make sure all tests pass (I think complex delete is tested also in raptor)

@martint We probably want this one for 348 still.

make sure all tests pass (I think complex delete is tested also in raptor)

Sure.
Any proposals for extra coverage to be added are welcome.

DELERE FROM t that uses t in subquery as well
please add a test for that as well (i think there might have been no end-user visible effect of the bug ("innocent bug") though)

I don't think this is addressed as long as Analysis performs the check by QualifiedObjectName and not by NodeRef. That requires recording target by NodeRef, as @losipiuk suggested.

i think there might have been no end-user visible effect of the bug

The only effect so far of tagging a TableScanNode incorrectly as the delete target is that a certain optimization is disabled in that branch of plan (namely, the rewrite of filtering semi-join to inner). However, the flag forDelete was meant to be used to disable other optimizations that are not relevant in the context of delete (e.g. join flipping).
I think that not taking this flag into consideration is a more serious issue than setting it where it doesn't belong.

I think that not taking this flag into consideration is a more serious issue than setting it where it doesn't belong.

Today. But this could change in the future.
Would it be possible to have a validator that verifies the flag is properly set and retained during optimizations?
We could also verify it is not set for ineligible table scans.
(of course, the second check is only possible after the Analysis changes as proposed)
(i don't mean the validator should be part of this PR)

@losipiuk you mixed up commits from other PR

@losipiuk you mixed up commits from other PR

thanks :)


[apollo-datasource-rest] Feature request: expose cache status to callers

Hey folks 👋 We have an existing subclass of RESTDataSource that logs a variety of metrics for each call to fetch. We're trying to instrument our data sources to better understand how caching/memoization is used in production. However, RESTDataSource doesn't make it easy to figure out this information; the best we could do was manually querying the cache and memoizedResults to try to infer what's happening. However, in the end, we ended up forking RESTDataSource/HTTPCache to make cache status information first-class data in the return values from get/post/etc. We defined a new type, FetchResult that wraps the original response with cache metadata:
export interface FetchResult<TResult> {
  context: {
    cacheHit: boolean;
    memoized: boolean;
  };
  response: Promise<TResult>;
}

We then updated the get/post/etc. to return a FetchResult:
  protected async get<TResult = any>(
    path: string,
    params?: URLSearchParamsInit,
    init?: RequestInit
  ): Promise<FetchResult<TResult>> {
    return this.fetch<TResult>(
      Object.assign({ method: 'GET', path, params }, init)
    );
  }

Finally, we changed RESTDataSource#fetch and HTTPCache#fetch to return objects with that same context property. With this, we could update our subclass of RESTDataSource to automatically report whether particular requests were served by the cache or were memoized.
Here's our implementation in a Gist: https://gist.github.com/nwalters512/472b5fb7d4cc7d32c4cecaa69b21baf5. The important bits:

definition of FetchResult
updated get/etc.
returning cacheHit: false from HTTPCache#fetch
returning cacheHit: true from HTTPCache#fetch
returning cacheHit for revalidated cache data
consuming cache status from HTTPCache
returning memoized: true for memoized requests

While this works, it's less than ideal to have to fork RESTDataSource and HTTPCache, since that introduces additional maintenance burden on our team. Ideally, this could be provided by the apollo-datasource-rest package itself. Does Apollo have any interest in adding this functionality? It doesn't necessarily need to use the same FetchResult interface we invented, but we'd appreciate anything that would give us more insight into how the cache is used.

This is a good feature suggestion and we're partway there now:

There's a fetch method that returns more than just the parsed body (the methods like get are convenience wrappers that fill in the method and pluck off parsedBody
Its return type (DataSourceFetchResult) has a requestDeduplication field that gives information similar to the memoized concept described here
It also has an httpCache field which for now just has a cacheWritePromise (which is mostly intended for error handling and making tests deterministic but does tell you whether or not you wrote to the HTTP cache), which is a good place to put more stuff like cacheHit

We're not going to have time to implement the rest of this as part of the development spike we're doing right now, but if somebody else wanted to add more fields to httpCache it would be a great PR for us to review. I think you'd want to be able to learn if it was a cache hit, a cache miss but we wrote the value to the cache, a cache almost-hit where it was revalidated with a 304 response, etc. Would also be interesting to return the TTL if it's writing to the cache. This should be a backwards-compatible change.

Not sure if I need to put the PR in Draft status or not, but in any case I hope to get some feedback before adding the unit tests etc.


Add metafiles to .gitignore

Files that should not be tracked:

[ ] .classpath
[ ] .gradle/
[ ] .project
[ ] *.prefs

They are not tracked. But i added the gitignore to the gitignore, so these files are depending on user settings after cloning the repository. If they were tracked, they would be in the source.

The gitignore should not be excluded. If someone wants to contribute to the project and forks it pull requests might include unwanted files.
And the files mentioned are indeed being tracked, thats why i requested to add them to the .gitignore. You might have to delete them first to remove them from the repo and future commits


Added Responsiveness to Home Page

fixes #127
fixes #134
Description:

Fixed occurrence of blank space in the about section
Fixed overlapping of the union while loading of events
Added responsiveness to the home page for large resolution screen.

Checklist

[x] I've followed the Contributing guidelines provided in the repository.
[x] I've made the changes that were demanded in the linked issue.
[x] I've tested my code on a Chromium-based browser.
[x] I've tested my code on Mozilla Firefox.
[x] My code gave a clean console on debugging. (no warnings/errors)

Was removing the planet from smaller screens was intended? @hariom1625
The rest Looks good to me! 🎉

Was removing the planet from smaller screens was intended? @hariom1625
The rest Looks good to me! 🎉

That was intended but I think I screwed up something!
Thanks for pointing that out :-)

Still looks a bit messy.. 🤔

Still looks a bit messy.. 🤔

I have added media queries only for the large resolution screens as mentioned in the issue #134 .
I think a new issue can he opened for optimizing it for smaller resolutions.
Or I can fix this in my next commit :-)

Still looks a bit messy.. thinking

I have added media queries only for the large resolution screens as mentioned in the issue #134 .
I think a new issue can be opened for optimizing it for smaller resolutions.

Well, it would be great if you solve this here itself @hariom1625.

Still looks a bit messy.. thinking

I have added media queries only for the large resolution screens as mentioned in the issue #134 .
I think a new issue can be opened for optimizing it for smaller resolutions.
Or I can fix this in my next commit :-)

For displaying the events for resolutions varying between desktop and mobile,I think we will need to change the layout because if we will use this same layout it appears a lot messy as the left place is left all blank and on the right all of the events are stacked and we can't shift that vertical line as it is required for the line to go from between because of the community section present below event section.
Suggestions ?

For displaying the events for resolutions varying between desktop and mobile,I think we will need to change the layout because if we will use this same layout it appears a lot messy as the left place is left all blank and on the right all of the events are stacked and we can't shift that vertical line as it is required for the line to go from between because of the community section present below event section.
Suggestions ?

For this, we can modify the media queries to change the layout at a screensize where things start to look messy.

Have a look once again I have changed the layout a bit for (resolution <750px).

This is much better :+1:

squash the commits and push! and this is good to go

while pulling use git pull upstream front-end --rebase, this will not generate a merge commit


Refactors & Cleanup

Came across this awesome homebridge plugin and wanted to hack on top of it. Since the package already requires node >=4.2.3, I rewrote some code to exploit new language features like arrow functions, class syntax, and promises.
The only visible difference to end users should be the reformatted log messages.

@yungsters I apologize for just not getting to this. This is awesome. Honestly, I'm an iOS dev (Objective-C and now Swift who hadn't really messed with node before this project. You obviously have a much better understanding of the syntax, JS promises, etc. than I do. I'll merge this in, but you may have to answer syntactical questions from the community until I get up to speed.

@bryanbartow Certainly! Feel free to ask me any questions that you may have, too. And thanks again for making this plugin. I've already been using it everyday. :-)

@yungsters Glad to hear it.


nvim-tree: handle white separator on transparent sidebar

change NvimTreeVertSplit to NvimTreeWinSeparator since the former is deprecated.
https://github.com/kyazdani42/nvim-tree.lua/pull/1225
set NvimTreeWinSeparator to border if sidebar style is transparent

Thank you!


Space focusing does not work (Ventura 13.3.1(a), yabai v5.0.4)

I upgraded my macOS version to Ventura 13.3.1(a), and yabai to v5.0.4.
After doing so, I'm having a problem with space focusing.
All other commands and functionalities are working as usual.
But 'yabai -m space --focus ' command throws an error 'cannot focus space due to an error with the scripting-addition' when I type it into the terminal.
I also found out that creating and destroying a space are unable, too.
macOS Ventura 13.3.1 (a)
yabai v5.0.4 (HEAD)
skhd v0.3.7 (HEAD)
2021 M1 Pro 16-inch MacBook Pro

Can you try running sudo yabai --load-sa in your terminal? I got the error but fixed it after successfully enabling arm64e binaries not signed by Apple (don't forget to reboot your machine).

Can you try running sudo yabai --load-sa in your terminal? I got the error but fixed it after successfully enabling arm64e binaries not signed by Apple (don't forget to reboot your machine).

It worked! Appreciate your help :)


Implement setting of quickfix list for the ConfigHelper plugin (fixes #20)

Next step would be to implement a parser to extract the errors and warnings from the recompileNvimhs state.

The branch still uses an unmerged patch for neovim, I should work around that for now.


add source but not work

add https://ftp.sotirov-bg.net/pub/contrib/slackware/packages/slackware64-15.0/ slackpack to sources.list
run un-get update, I can see /tmp/un-get/filelist-slackpack file content is ok
run un-get search ncdu, return Found no packages matching your search 'ncdu'.

Thank you for the report, will look into this ASAP and report back.

@hcwhan I've now took a closer look at this, this is actually caused because the FILELIST.TXT doesn't follow the Slackware default (date and time is formatted wrong).
I will look into it if I can account for this in un-get

@ich777 ok

Please update the plugin to v0.18 or 2022.10.27 respectively to fix the issue with this repository.
If you have any further issues please feel free to re-open this issue again or open up a new issue.

2022.10.27 is ok, tks very much


Currently many classes are not mockable

Good day!
I am currently writing unit tests for everything inside osu-framework where possible.
While writing unit tests I faced a big problem: Most classes are not mockable.
Therefore I like to ask if could change not API related code in a way to make it mockable.
Example: class RNG
14: - private static readonly Random random = new Random();
14: +public IRandomProvider { set; private get; } = new RandomProvider(new Random());

You're welcome to make changes where required (please open one PR per class) and we can discuss there. I doubt there will be much contention, especially in cases such as above.


[BUG] A released helm chart tag is based on an incorrect commit

Describe the bug (🐛 if you encounter this issue)
https://github.com/longhorn/charts/tree/longhorn-1.4.3 is pointing to 1.5.0 instead of 1.4.3, even though the built artifact is correct with 1.4.3 content.
Need to fix the helm chart build github action to make the release tag to point to the right code commit.
Additional context
cc @yangchiu @longhorn/qa

This has been fixed in the 1.6.0 release.
https://github.com/longhorn/charts/commit/e6617975bf5f64cfb3f1cb288a425ec9c7f0c767


Remove TyphoonComponentFactory asAssembly and vice-versa methods

These work fine at runtime in Objective-C, but its not clear that they're not meant to work with non-activated assemblies.
TyphoonAssemblyActiviator should negate the need for this in any case.

Tested on current project:
Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'No component matching id 'TyphoonDefinition-Config_development.plist'.'


Discussion: Should the catalog repository use a pinned version?

https://github.com/apache/incubator-openwhisk/blob/master/ansible/group_vars/all#L257
When installing the catalog, the HEAD of the master branch is currently always pulled. While we take care to only merge stable changes, mistakes can happen and bugs could be introduced. Instead of always pulling from HEAD, we could pin this value to a specific tag or commit hash, which requires a separate update (presumably after integration testing is done) to pull in new versions.
Thoughts? @jasonpet @akrabat @rabbah

I think the catalog should be installed like the alarm, cloudant, and Kafka feeds: from their own repos. I don't install the catalog from this repo because for day to day developelent it's not needed. And when I do need to, I don't run post deploy/catalog playbook and instead run out of the catalg repo (which then allows for controlled deployment like you're suggesting).
I would package a post deploy playbook perhaps in an extras repository, and do the pinning there. My hestiation to pinning the catalog from this repo is we end up with lots of "bump" commits.
In general we are striving to have as few circular dependencies in this repo to dependent repos. So I would severe dependence on the catalog. With the exception of the swift tests, I think all tests in this repo are self contained.

I'm generally in favour of separation wherever possible.


how to compute the processing time (0.08s) of  an image of size 400×300

I had read many CVPR2017 paper related to saliency detection, your model and NLDF(Non-Local Deep Features for Salient Object Detection) all say the processing time == 0.08s, but the model and DL framwork(TF vs Caffe) are different, which should cause a bit different. This makes me confused.
Can you upload an simple ipynb file to explain how the 0.08s to be computed ? or just tell me your method if it's easy to implement.
Thank you very much.

Actually it is a approximate value. You can test your model on some dataset, say MSRA-B, and report the average time on each image. It seems the speed is not that important.

If you want an exact value, we can resize all the images of some dataset to size 300 * 400.


Install-Module Unable to resolve package source 'https://www.powershellgallery.com/api/v2'.

Steps to reproduce
[System.Net.WebRequest]::DefaultWebProxy = [System.Net.WebRequest]::GetSystemWebProxy()
[System.Net.WebRequest]::DefaultWebProxy.Credentials = [System.Net.CredentialCache]::DefaultNetworkCredentials
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Install-Module -Name PowerShellGet -Force -Verbose -Debug -Scope AllUsers

Expected behavior
Performing the operation "Install-Module" on target "Version '<IP_ADDRESS>' of module 'PowerShellGet'".

Actual behavior
DEBUG: 00:00:00.0000143 Trying provider assembly: C:\program files\powershell\7\Modules\PackageManagement\coreclr\netstandard2.0\Microsoft.PackageManagement.CoreProviders.dll
DEBUG: 00:00:00.0000221 Trying provider assembly: C:\program files\powershell\7\Modules\PackageManagement\coreclr\netstandard2.0\Microsoft.PackageManagement.NuGetProvider.dll
DEBUG: 00:00:00.0000094 Trying provider assembly: C:\program files\powershell\7\Modules\PackageManagement\coreclr\netstandard2.0\Microsoft.PackageManagement.MetaProvider.PowerShell.dll
DEBUG: 00:00:00.0000123 Trying provider assembly: C:\program files\powershell\7\Modules\PackageManagement\coreclr\netstandard2.0\Microsoft.PackageManagement.ArchiverProviders.dll
DEBUG: 00:00:00.0051011 Attempting loading of assembly: C:\program files\powershell\7\Modules\PackageManagement\coreclr\netstandard2.0\Microsoft.PackageManagement.CoreProviders.dll
DEBUG: 00:00:00.0052686 Attempting loading of assembly: C:\program files\powershell\7\Modules\PackageManagement\coreclr\netstandard2.0\Microsoft.PackageManagement.ArchiverProviders.dll
DEBUG: 00:00:00.0053708 Attempting loading of assembly: C:\program files\powershell\7\Modules\PackageManagement\coreclr\netstandard2.0\Microsoft.PackageManagement.MetaProvider.PowerShell.dll
DEBUG: 00:00:00.0056743 Attempting loading of assembly: C:\program files\powershell\7\Modules\PackageManagement\coreclr\netstandard2.0\Microsoft.PackageManagement.NuGetProvider.dll
VERBOSE: Acquiring providers for assembly: C:\program files\powershell\7\Modules\PackageManagement\coreclr\netstandard2.0\Microsoft.PackageManagement.NuGetProvider.dll
VERBOSE: Acquiring providers for assembly: C:\program files\powershell\7\Modules\PackageManagement\coreclr\netstandard2.0\Microsoft.PackageManagement.CoreProviders.dll
VERBOSE: Acquiring providers for assembly: C:\program files\powershell\7\Modules\PackageManagement\coreclr\netstandard2.0\Microsoft.PackageManagement.MetaProvider.PowerShell.dll
VERBOSE: Acquiring providers for assembly: C:\program files\powershell\7\Modules\PackageManagement\coreclr\netstandard2.0\Microsoft.PackageManagement.ArchiverProviders.dll
DEBUG: 00:00:00.1363038 Registering providers via metaproviders for assembly Microsoft.PackageManagement.MetaProvider.PowerShell.Internal.PowerShellMetaProvider
DEBUG: 00:00:00.4200363 Initializing provider 'Bootstrap'
DEBUG: 00:00:00.4200667 Initializing provider 'WebDownloader'
DEBUG: 00:00:00.4200699 Initializing provider 'zipfile'
DEBUG: 00:00:00.4205401 Initializing provider 'NuGet'
DEBUG: 00:00:00.4428452 Provider 'WebDownloader' Initialized
DEBUG: 00:00:00.4428551 Provider 'zipfile' Initialized
DEBUG: 00:00:00.4429310 Using Archiver Provider zipfile
DEBUG: 00:00:00.4429503 Using Downloader Provider WebDownloader
DEBUG: 00:00:00.4935293 Initialize Bootstrapper
DEBUG: 00:00:00.4941908 Provider 'Bootstrap' Initialized
DEBUG: 00:00:00.4942540 Using Package Provider Bootstrap
DEBUG: 00:00:00.4958023 Trying to register metaprovider
DEBUG: 00:00:00.5078662 Initializing PowerShell MetaProvider
DEBUG: 00:00:00.5267483 Calling 'NuGet'::'InitializeProvider'.
DEBUG: 00:00:00.5268792 Provider 'NuGet' Initialized
DEBUG: 00:00:00.5269195 Using Package Provider NuGet
DEBUG: 00:00:00.5329732 Calling 'zipfile::GetFeatures'
DEBUG: 00:00:00.5332536 Calling 'WebDownloader::GetFeatures'
DEBUG: 00:00:00.5335480 Calling 'Bootstrap::GetFeatures'
DEBUG: 00:00:00.5355467 The provider 'Bootstrap' is imported
DEBUG: 00:00:00.5363063 SUCCESS provider assembly: C:\program files\powershell\7\Modules\PackageManagement\coreclr\netstandard2.0\Microsoft.PackageManagement.ArchiverProviders.dll
DEBUG: 00:00:00.5364274 SUCCESS provider assembly: C:\program files\powershell\7\Modules\PackageManagement\coreclr\netstandard2.0\Microsoft.PackageManagement.CoreProviders.dll
DEBUG: 00:00:00.5406852 Calling 'NuGet'::'GetFeatures'.
DEBUG: 00:00:00.5426725 The provider 'NuGet' is imported
DEBUG: 00:00:00.5428006 SUCCESS provider assembly: C:\program files\powershell\7\Modules\PackageManagement\coreclr\netstandard2.0\Microsoft.PackageManagement.NuGetProvider.dll
DEBUG: 00:00:00.8184429 Attempting to load PowerShell Provider Module [C:\program files\powershell\7\Modules\PowerShellGet\PSModule.psm1]
DEBUG: 00:00:00.9807024 Loaded PowerShell package provider: '[C:\program files\powershell\7\Modules\PowerShellGet\PSModule.psm1]'.
DEBUG: 00:00:00.9911066 Loaded PowerShell Provider: PowerShellGet
DEBUG: 00:00:00.9939187 Initializing provider 'PowerShellGet'
DEBUG: 00:00:01.0039568 Calling New() : MethodName = 'InitializeProvider'
DEBUG: 00:00:01.0040467 WarningAction: SilentlyContinue
DEBUG: 00:00:01.0040800 ErrorAction: SilentlyContinue
DEBUG: 00:00:01.0102511 INVOKING PowerShell Fn Initialize-Provider with args  that has length 0
DEBUG: 00:00:01.0302229 In PowerShellGet Provider - 'Initialize-Provider'.
DEBUG: 00:00:01.0306527 PowerShell Script 'PSModule' Function 'Initialize-Provider' returns null.
DEBUG: 00:00:01.0335293 Done calling powershell «Initialize-Provider» «PSModule»
DEBUG: 00:00:01.0336307 Provider 'PowerShellGet' Initialized
DEBUG: 00:00:01.0336664 Using Package Provider PowerShellGet
DEBUG: 00:00:01.0746073 Calling New() : MethodName = 'GetFeatures'
DEBUG: 00:00:01.0746985 WarningAction: SilentlyContinue
DEBUG: 00:00:01.0747391 ErrorAction: SilentlyContinue
DEBUG: 00:00:01.0781786 INVOKING PowerShell Fn Get-Feature with args  that has length 0
DEBUG: 00:00:01.0840484 In PowerShellGet Provider - 'Get-Feature'.
DEBUG: 00:00:01.0932127 Done calling powershell «Get-Feature» «PSModule»
DEBUG: 00:00:01.0933945 The provider 'PowerShellGet' is imported
DEBUG: 00:00:01.0953112 SUCCESS provider assembly: C:\program files\powershell\7\Modules\PackageManagement\coreclr\netstandard2.0\Microsoft.PackageManagement.MetaProvider.PowerShell.dll
DEBUG: 00:00:00 Calling New() : MethodName = 'GetDynamicOptions'
DEBUG: 00:00:00.0002853 Debug: True
DEBUG: 00:00:00.0003416 Force: True
DEBUG: 00:00:00.0003802 Name: PowerShellGet
DEBUG: 00:00:00.0004159 Verbose: True
DEBUG: 00:00:00.0019474 INVOKING PowerShell Fn Get-DynamicOptions with args Provider that has length 1
DEBUG: 00:00:00.0152430 In PowerShellGet Provider - 'Get-DynamicOptions'.
DEBUG: 00:00:00.0299317 Done calling powershell «Get-DynamicOptions» «PSModule»
DEBUG: 00:00:00.0380298 Calling New() : MethodName = 'GetDynamicOptions'
DEBUG: 00:00:00.0380811 Debug: True
DEBUG: 00:00:00.0381184 Force: True
DEBUG: 00:00:00.0381509 Name: PowerShellGet
DEBUG: 00:00:00.0381862 Verbose: True
DEBUG: 00:00:00.0392710 INVOKING PowerShell Fn Get-DynamicOptions with args Source that has length 1
DEBUG: 00:00:00.0403524 In PowerShellGet Provider - 'Get-DynamicOptions'.
DEBUG: 00:00:00.0445158 Done calling powershell «Get-DynamicOptions» «PSModule»
DEBUG: 00:00:00.0508339 Calling New() : MethodName = 'GetDynamicOptions'
DEBUG: 00:00:00.0508803 Debug: True
DEBUG: 00:00:00.0509156 Force: True
DEBUG: 00:00:00.0509468 Name: PowerShellGet
DEBUG: 00:00:00.0509809 Verbose: True
DEBUG: 00:00:00.0520607 INVOKING PowerShell Fn Get-DynamicOptions with args Package that has length 1
DEBUG: 00:00:00.0530946 In PowerShellGet Provider - 'Get-DynamicOptions'.
DEBUG: 00:00:00.0668509 Done calling powershell «Get-DynamicOptions» «PSModule»
DEBUG: 00:00:00.0731982 Calling New() : MethodName = 'GetDynamicOptions'
DEBUG: 00:00:00.0732520 Debug: True
DEBUG: 00:00:00.0732902 Force: True
DEBUG: 00:00:00.0733218 Name: PowerShellGet
DEBUG: 00:00:00.0733567 Verbose: True
DEBUG: 00:00:00.0744295 INVOKING PowerShell Fn Get-DynamicOptions with args Install that has length 1
DEBUG: 00:00:00.0755159 In PowerShellGet Provider - 'Get-DynamicOptions'.
DEBUG: 00:00:00.0823136 Done calling powershell «Get-DynamicOptions» «PSModule»
DEBUG: 00:00:00.1874239 Calling SearchForPackages. Name='PowerShellGet'
VERBOSE: Using the provider 'PowerShellGet' for searching packages.
DEBUG: 00:00:00.1979879 PackageProvider::FindPackage with name PowerShellGet
DEBUG: 00:00:00.2110154 Calling SearchForPackages After Select 1
DEBUG: 00:00:00.2399815 Calling New() : MethodName = 'FindPackage'
DEBUG: 00:00:00.2452847 Scope: AllUsers
DEBUG: 00:00:00.2483062 Force: True
DEBUG: 00:00:00.2513400 ProviderName: PowerShellGet
DEBUG: 00:00:00.2539579 Type: Module
DEBUG: 00:00:00.2571038 Name: PowerShellGet
DEBUG: 00:00:00.2626899 MessageResolver: Microsoft.PowerShell.PackageManagement.Cmdlets.GetMessageString
DEBUG: 00:00:00.2654675 Verbose: True
DEBUG: 00:00:00.2688162 Debug: True
DEBUG: 00:00:00.2728244 INVOKING PowerShell Fn Find-Package with args System.String[], , ,  that has length 4
DEBUG: 00:00:00.3493746 In PowerShellGet Provider - 'Find-Package'.
DEBUG: 00:00:00.4165401 OPTION: Scope => AllUsers
DEBUG: 00:00:00.4216043 OPTION: Force => True
DEBUG: 00:00:00.4241356 OPTION: ProviderName => PowerShellGet
DEBUG: 00:00:00.4266673 OPTION: Type => Module
DEBUG: 00:00:00.4291373 OPTION: Name => PowerShellGet
DEBUG: 00:00:00.4339593 OPTION: MessageResolver => Microsoft.PowerShell.PackageManagement.Cmdlets.GetMessageString
DEBUG: 00:00:00.4365661 OPTION: Verbose => True
DEBUG: 00:00:00.4394238 OPTION: Debug => True
VERBOSE: The -Repository parameter was not specified.  PowerShellGet will use all of the registered repositories.
VERBOSE: Getting the provider object for the PackageManagement Provider 'NuGet'.
VERBOSE: The specified Location is 'https://www.powershellgallery.com/api/v2' and PackageManagementProvider is 'NuGet'.
DEBUG: 00:00:00.5212279 PackageProvider::FindPackage with name PowerShellGet
DEBUG: 00:00:00.5338506 Calling 'NuGet'::'FindPackage' - name='PowerShellGet', requiredVersion='',minimumVersion='', maximumVersion='''.
DEBUG: 00:00:00.6444907 Iterating 'PowerShellGet'.
DEBUG: 00:00:00.6617267 Calling 'NuGetRequest'::'RegisteredPackageSources', 'C:\Users\dburtsev\AppData\Roaming\NuGet\nuget.config'.
DEBUG: 00:00:00.6662694 Loading a configuration from file 'C:\Users\dburtsev\AppData\Roaming\NuGet\nuget.config'.
DEBUG: 00:00:00.6701618 Loaded a configuration from file 'C:\Users\dburtsev\AppData\Roaming\NuGet\nuget.config'.
DEBUG: 00:00:00.6743950 There are '1' registered sources in 'NuGet' provider.
DEBUG: 00:00:00.6772760 Source 'https://www.powershellgallery.com/api/v2' is not one of the registered sources in 'NuGet' provider.
VERBOSE: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
DEBUG: 00:00:22.4657120    at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.ConnectAsync(HttpRequestMessage request, Boolean allowHttp2, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.CreateHttp11ConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.GetHttpConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)
at System.Net.Http.AuthenticationHelper.SendWithAuthAsync(HttpRequestMessage request, Uri authUri, ICredentials credentials, Boolean preAuthenticate, Boolean isProxyAuth, Boolean doRequestAuth, HttpConnectionPool pool, CancellationToken cancellationToken)
at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.HttpClient.FinishSendAsyncBuffered(Task1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts) VERBOSE: Retry downloading 'https://www.powershellgallery.com/api/v2' for '2' more times VERBOSE: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. DEBUG: 00:00:43.5080596    at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)    at System.Net.Http.HttpConnectionPool.ConnectAsync(HttpRequestMessage request, Boolean allowHttp2, CancellationToken cancellationToken)    at System.Net.Http.HttpConnectionPool.CreateHttp11ConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)    at System.Net.Http.HttpConnectionPool.GetHttpConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)    at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)    at System.Net.Http.AuthenticationHelper.SendWithAuthAsync(HttpRequestMessage request, Uri authUri, ICredentials credentials, Boolean preAuthenticate, Boolean isProxyAuth, Boolean doRequestAuth, HttpConnectionPool pool, CancellationToken cancellationToken)    at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)    at System.Net.Http.HttpClient.FinishSendAsyncBuffered(Task1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts)
VERBOSE: Retry downloading 'https://www.powershellgallery.com/api/v2' for '1' more times
VERBOSE: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
DEBUG: 00:01:04.5969726    at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.ConnectAsync(HttpRequestMessage request, Boolean allowHttp2, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.CreateHttp11ConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.GetHttpConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)
at System.Net.Http.AuthenticationHelper.SendWithAuthAsync(HttpRequestMessage request, Uri authUri, ICredentials credentials, Boolean preAuthenticate, Boolean isProxyAuth, Boolean doRequestAuth, HttpConnectionPool pool, CancellationToken cancellationToken)
at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.HttpClient.FinishSendAsyncBuffered(Task`1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts)
VERBOSE: Retry downloading 'https://www.powershellgallery.com/api/v2' for '0' more times
WARNING: Unable to resolve package source 'https://www.powershellgallery.com/api/v2'.

Environment data

Name                           Value

PSVersion                      7.0.2
PSEdition                      Core
GitCommitId                    7.0.2
OS                             Microsoft Windows 10.0.14393
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Try this:
Run PowerShell as Administrator, and run the following command to force TLS1.2 protocol:
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::tls12

Bruab1, I already did.
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::tls12 doesn't work on some stand-alone servers in our network.

I am having this same issue. I tried to force it to use TLS 1.2 and it also did not fix the problem.

Any update on this please?

No updates

Forcing  TLS1.2  fixed my issue. Thanks to Bruab1

Forcing TLS1.2 did NOT fix my issue. Any updates?

@jrachwalski unfortunately the PowerShell gallery is currently experiencing an outage-- we are tracking the issue with https://github.com/PowerShell/PowerShellGallery/issues/135#issuecomment-719631351 and also posting updates to aka.ms/psgallerystatus

Closing as this should be resolved.

Not so quick, it's not resolved for PS5.1 on Win2008R2

Not so quick, it's not resolved for PS5.1 on Win2012RS

Not so quick, it's not resolved for PS5.1 on Win10

Any updates on this? It's not resolved on PS7 on Win2016RS

Probably a pretty obvious point, but for me running PowerShell as Administrator resolved this issue.


[BUG] Messages following undefined System Common/Realtime messages are corrupt.

Describe the bug
Sending undefined System Common/Realtime messages (0xF4, 0xF5, 0xF9, 0xFD) to the USB MIDI device which is working with the USB MIDI 1.0 driver (USBAUDIO.sys) corrupts following messages.
To Reproduce

Set the Roland UM-ONE mk2 to class-compliant mode and short INPUPT and OUTPUT to loop back messages.
Attach the UM-ONE to PC.
Make sure the device is working with the USB MIDI 1.0 driver (USBAUDIO.sys).
Open midi.exe in two windows.
From one, monitor UM-ONE.
From the other, send the attached "TestMT1.txt" to UM-ONE.
Received messages on the monitor are corrupt (received_messages.txt).

Expected behavior
All MT2 messages in the file are received as they are.
Screenshots
I have attached the captured USB log file (USBLog.zip).
It shows that USB packets sent to the device are already corrupt.

Installer Name or Version

Windows.MIDI.Services.In-Box.Service.-.Developer.Preview.<IP_ADDRESS>94.2233-x64.exe

Desktop (please complete the following information):

OS: Windows 11 24H2
OS Build:  26100.1150

Device information, if this is with an external MIDI device:

Roland UM-ONE mk2 (Any USB MIDI device compatible with the USB MIDI 1.0 driver.)
Driver: OS in-box USB MIDI 1.0 driver (USBAUDIO.sys)

Application Information

'midi.exe' console app.

Note that whatever change is made here to accommodate this must also be made in the USB MIDI 2 Driver @AmeNote-Michael

For the USB MIDI 2 Driver (usbmidi2.sys) it is actually not an issue cause in USB MIDI 1.0 it is a single 32bit word always regardless if message is defined or not. When an undefined message, then I just ignore rest of bytes in the 32 bit data.
For the UMP to BS or BS to UMP, should just pass the undefined byte I think when going from UMP to BS or in case of BS to UMP, should be a UMP message with just the one real time message byte, rest NULL.

Also discussing here:
https://github.com/midi2-dev/AM_MIDI2.0Lib/issues/16
We may need to decline this one, because these are undefined MIDI 1.0 messages. It pains me to see it mess up the entire stream of data, but no one should be using undefined MIDI 1.0 messages.
We're much more forgiving when it comes to MIDI messages that stay in UMP. But when translating to bytes, we're at the mercy of what devices do with that data.
My recommendation to Andrew for libmidi2 is to just drop these undefined messages when translating to MIDI 1.0 byte data format. But that may not be simple to do.

Update: Andrew is looking at options in libmidi2. Rejecting the status byte as well as any data bytes which come after the undefined message is looking to be a reasonable option. This is really about hardening the translator against bad data, because no one should be using these opcodes.

Decision: Michael and Andrew will change their code to drop these messages in both directions.

#397 related

Closed with release of DP7


Cut a new release?

Hey folks - I've noticed there's been more than a few PR's merged since the last release was cut in 2020.  Any chance that a new release can be published to the forge?  Thanks!

@raphink Hey! Any thoughts on migrating this repository to Vox?

+1 on a new release, there are some features that haven't been shipped to the Forge that we require. Kindly please consider updating the build, thanks!

@bastelfreak any chance we can get a release this year? 😞

@claviola we did a new forge release last year and that already contains all relevant changes. unreleased changes: https://github.com/voxpupuli/puppet-catalog_diff/compare/v3.0.0...voxpupuli:puppet-catalog_diff:master
We currently don't have any automation in place to publish/maintain the docker containers. Everyone can participate by creating PRs to the relevant repos. I'm more than happy to review them.


Client socket is not connected

Description
I'm not particularly sure if this is an issue, since I can perceive no meaningful effect on my pool.
Steps to Reproduce
Unknown, no major changes (if any at all were made).

Added 'check' to haproxy load balancer (no change when removed)

It just popped up this afternoon when I was checking my logs. It is possible that a user is doing something unauthorized? Or dropped off after the initial connection?
Expected behavior
Normal mining activity.
Actual behavior
Appears to still be normal mining activity, but with this accompanying log a few times a second.
[2018-03-09 12:24:06.0552] [E] [electroneum] [Pool] [0HLC5MPT4AOVH] Connection json error state: Unexpected character encountered while parsing value: P. Path '', line 0, position 0.
[2018-03-09 12:24:06.0552] [E] [electroneum] [Pool] [0HLC5MPT4AOVH] Connection json error state: MiningCore.Buffers.PooledArraySegment`1[System.Byte]
[2018-03-09 12:24:06.1769] [E] [electroneum] OnClientConnected NetUV.Core.Native.OperationException: ENOTCONN (ENOTCONN) : ENOTCONN : socket is not connected
   at NetUV.Core.Native.NativeMethods.ThrowOperationException(uv_err_code error)
   at NetUV.Core.Native.NativeMethods.TcpGetPeerName(IntPtr handle)
   at NetUV.Core.Handles.Tcp.GetPeerEndPoint()
   at MiningCore.Stratum.StratumServer.OnClientConnected(Tcp con, IPEndPoint endpointConfig, Loop loop)    at NetUV.Core.Native.NativeMethods.ThrowOperationException(uv_err_code error)
   at NetUV.Core.Native.NativeMethods.TcpGetPeerName(IntPtr handle)
   at NetUV.Core.Handles.Tcp.GetPeerEndPoint()
   at MiningCore.Stratum.StratumServer.OnClientConnected(Tcp con, IPEndPoint endpointConfig, Loop loop)
[2018-03-09 12:24:06.7688] [E] [electroneum] OnClientConnected NetUV.Core.Native.OperationException: ENOTCONN (ENOTCONN) : ENOTCONN : socket is not connected
   at NetUV.Core.Native.NativeMethods.ThrowOperationException(uv_err_code error)
   at NetUV.Core.Native.NativeMethods.TcpGetPeerName(IntPtr handle)
   at NetUV.Core.Handles.Tcp.GetPeerEndPoint()
   at MiningCore.Stratum.StratumServer.OnClientConnected(Tcp con, IPEndPoint endpointConfig, Loop loop)    at NetUV.Core.Native.NativeMethods.ThrowOperationException(uv_err_code error)
   at NetUV.Core.Native.NativeMethods.TcpGetPeerName(IntPtr handle)
   at NetUV.Core.Handles.Tcp.GetPeerEndPoint()
   at MiningCore.Stratum.StratumServer.OnClientConnected(Tcp con, IPEndPoint endpointConfig, Loop loop)

Reproduces how often
A few times every second. It appears to happen whenever a client connects.
Version
Release 0.19, Ubuntu 16.04
Additional Information
None

It means a client disconnected right when the stratum handled the connect.

Is the problem solved？


Nightly Demo deployment broken

Url: https://nightly-dot-shaka-player-demo.appspot.com/demo/#build=uncompiled

userAgent:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Safari/605.1.15

Commit 1076b784 changed our dependency on Google's Closure Library, and our appspot deployment script was not updated to reflect this.  The nightly is broken in all browsers.

The deployment of the nightly build has now been fixed.  Sorry for the inconvenience!

Thanks!


Lighter token reneval flow

Hi,
I'm a bit worried about the amount of HTTP requests being sent by this library in the automaticSilentRenew mode.
What do you think about adding a method like getAccessToken that would:

If it has expired, refresh it.
Return it.

This way, browsers won't need to constantly spam OPs with requests, they'd get sent only when the app really needs an access token.
By the way, it'd be nice to also have getIDToken, working in the same way, that could be used for user identification purposes when calling RP's own backend services.
That's the full flow I have in mind:

You can simply not use the automatic and just call it yourself when you need/want to.


typo readme DSL example

as s import wasn't working for me
import pprint

ty! was doing a bit too much refactoring


Support cache for prepared statements and parsed queries

Query.parse is a purely function obviously, so results which returned by this method can be cache for all connections. Of course, should isolate cache between connections created by different ConnectionFactorys, then parsed query cache will be one-to-one ConnectionFactory.
QueryFlow.execute for server-preparing execution will send a prepare message to server and server will return a  prepared statement ID, this ID can be cache for this connection until it has been closed. The prepared statement cache will be one-to-one Connection. (MySQL prepared statement does not across connections)

It is supported by PR and published to 0.8.3.BUILD-SNAPSHOT. Target version is 0.8.3.RELEASE.

If want to use snapshot versions, add Sonatype snapshots repository to Maven file, see also README


Simplify use of the Triplestore triples() and remove() methods

Closes #50
Changed arguments of the Triplestore triples() and remove() methods to make them easier to use.
Ensured backward compatibility.

Codecov Report
Base: 74.25% // Head: 74.12% // Decreases project coverage by -0.12% :warning:

Coverage data is based on head (4d77b23) compared to base (62b83f0).
Patch coverage: 75.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #51      +/-   ##
==========================================
- Coverage   74.25%   74.12%   -0.13%
==========================================
  Files          12       12
  Lines         703      715      +12
==========================================
+ Hits          522      530       +8
- Misses        181      185       +4

Impacted Files
Coverage Δ

tripper/triplestore.py
77.63% <75.00%> (-0.59%)
:arrow_down:

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 at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Make toYUYV() and toRGB() return a node Buffer

Previously these functions returned an array of numbers, which took
long time to construct. With this commit, we return a JavaScript
Buffer instead, backed by a C++ SlowBuffer.
On a Raspberry Pi device, before this change toRGB() took ~4200ms,
with this change it's down to 42ms. This relates to issue #9.
This change also adds the function getFrameData(), and toYUYV() is
(incorrectly) an alias to this function.

Thanks your patch to merged at ad1b1c94468e21c65ea49633325d935c665b3d1f
But I switch to use Uint8Array instead of Array for compatibility,
and the current node-4 Buffers backend become same ArrayBuffer, so it is not so slow as Array returned.


Environment variables?

Is it possible to access environment variables somehow within the Ember app, particularly environment.js?

@adambedford  Yes, you can access them in the environment.js. Every ENV variable is accessible in your environment.js.
Ex. You can access your RAILS env variables  using the process env.
module.exports = function(environment) {
  ...
   // could be any of the env variables you set in your rails app when running inside the Rails process.
   var ENV = {
       randomEnvVariable: process.env.RAILS_ENV
       ...
   }
  ...
   return ENV;
};

Best regards,
Daniel

Docs do state that RAILS_ENV is removed in the production build.

Hey @darylalexjohnson,
But the rest of the ENV VARIABLES are available, don't they?


Enabled Viewer user

Hi all,
I install Carto on local machine.
Can I enable Viewer users by terminal?
Can I enable Viewer users by web interface, "organization settings"?
Thanks!

Hi @hhryw, questions about how CARTO works, please post your doubts in this google group: https://groups.google.com/forum/#!forum/cartodb. We try to use this issues for problems found in the application.
Cheers!


Update Decorators.md

fix the "override constructor" example in 'Class decorators' section

Trying the given example, shows that bug.reportingURL holds the value given in the decorator ("http://...")
So what's the point in the last line. Is it an implicit return ?
This doesn't seem to be informative about how the type system isn't affected.

See above; this change doesn't look correct. I think the example is correct as-is.


ERROR: Invalid key

This started popping up on 04/02 on https://flyfrompti.com. Any idea how to fix?

UGH! Found this https://www.wunderground.com/weather/api/.
Looks like the free API's have been abandoned.

IBM pulled the plug on free lAPI  access.

On Apr 3, 2019, at 7:16 AM, KO<EMAIL_ADDRESS>wrote:
This started popping up on 04/02 on https://flyfrompti.com. Any idea how to fix?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.


cannot import name '_request_ctx_stack'

doesnt work
$ ./app.py
Traceback (most recent call last):
  File "./app.py", line 5, in <module>
    from flask_security import Security, SQLAlchemyUserDatastore, \
  File "/home/z/tmp/Flask-Admin-Dashboard/venv/lib/python3.8/site-packages/flask_security/__init__.py", line 13, in <module>
    from .core import Security, RoleMixin, UserMixin, AnonymousUser, current_user
  File "/home/z/tmp/Flask-Admin-Dashboard/venv/lib/python3.8/site-packages/flask_security/core.py", line 18, in <module>
    from flask_babelex import Domain
  File "/home/z/tmp/Flask-Admin-Dashboard/venv/lib/python3.8/site-packages/flask_babelex/__init__.py", line 20, in <module>
    from flask import _request_ctx_stack
ImportError: cannot import name '_request_ctx_stack' from 'flask' (/home/z/tmp/Flask-Admin-Dashboard/venv/lib/python3.8/site-packages/flask/__init__.py)

Here is my requirments.txt, and it runs good in Ubuntu22.04 LTS.
Flask==2.1.3
Flask-Admin==1.6.1
Flask-SQLAlchemy==2.5.1
Flask-Security>=1.7.5
enum34==1.1.6
email_validator
Werkzeug==2.0.3
WTForms==2.3.0
Flask-WTF==1.2.1
SQLAlchemy==1.4

I have tried many times and test many version packages. The following requirments runs well in Ubuntu22.04 LTS.


Link back to bookshelf for other embedded resources

This is my initial attempt to address issue #129 opened by @adamgreig
to have links back to the bookshelf added to the front page. I am
not sure if this is what you were looking for but I thought I would
give it a try. Let me know what you think.

bors r+


Runtime: correct the location of windows header inclusion

We would previously include a header inside the swift::impl namespace,
which would prevent the proper declaration of the functions and
enumerators.  This corrects the location of the header inclusion to fix
this issue.

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

@swift-ci please smoke test Linux platform


#21991 show default procedure parameters

Impact only on the procedure parameters reading. You can check it in different Firebird versions.

verified


what is mean <C-+>?

https://github.com/tenxsoydev/size-matters.nvim/blob/bc5ae8db3c31eec3b121f03d5de0444ab6a9a983/lua/size-matters/init.lua#L48
ctrl and + ?

Hey, sorry I didn't get a notification about an issue being opened.
Yes, it's Ctrl and +. Which usually is:
Ctrl+Shift+=


why complain about prototype not in roots?

What's the purpose / justification of this test?
https://github.com/Agoric/harden/blob/e29849c18e0cfbbd41db1e8765954d4bc51d5e4a/test/test.js#L14
This is the only test that fails when I implement harden using deep freezing from the moddable SDK:
export default function harden(root) {
  return Object.freeze(root, true);
}

https://github.com/dckc/harden/blob/deepFreeze-xs/src/deepFreeze.js
cc @erights @warner @phoddie

@erights writes in https://github.com/Moddable-OpenSource/moddable/issues/399#issuecomment-671625831

We should NOT use that hacky replacement for harden.

Well, ok...

We should use the harden from the SES-shim monorepo.

Really? This implementation seems to have a WeakSet of roughly all objects used in a program. That's not just a legacy work-around?

If for some reason it does not work out of the box, we need to fix it. Its semantics are different that the two argument Object.freeze in important way.

I guess I need to understand better what that way is. To re-iterate the above from December, "This test seems to be testing an implementation detail, not a feature."

I got to talk with @warner about this last night and I see the motivation for the test. More later...

This is a good time to re-raise this. Now that we got rid of the fringe, since harden is now post-lockdown only, we should reconsider whether we should go back to having it be transitive up the prototype chain as it used to be. It would certainly be easier to explain.

We intend to refactor harden such that this issue would go away. We would transitively freeze up the prototype chain.

(This relaxation is possible because we will continue to have harden throw if used before lockdown).

This work will imply necessary changes for inter-realm membranes, which will need to block harden from transitively freezing the other side’s primordials.

while tryinng to get XS snapshots (https://github.com/Agoric/agoric-sdk/issues/511) and vat workers (https://github.com/Agoric/agoric-sdk/issues/1845) to work on XS, I ran into:
next challenge:
throw new Error(
          `Cannot pass non-frozen objects like ${val}. Use harden()`,
        );

some notes from our discussion last Thu (cc @phoddie)
@kriskowal , Can we do makeHardener without the rest of the "patch all the legacy gorp" SES stuff?
kriskowal: You will have to. You should be able to use @agoric/make-hardener directly, so long as the fringe is already frozen when you use it. But, cc @erights who would know better.
dckc @warner where is the node part of build-xsnap getting harden from?
ah... build-node.js starts with import '@agoric/install-ses';
how do the new bits get from the SES-shim monorepo to the agoric-sdk monorepo? via npm? is the released make-hardener close enough?
@kriskowal : npm/yarn, yes.
There is a released @agoric/make-hardener that ses uses to make harden and put it in global scope.
For the current harden, you'll need to harden a layer at a time down the inheritance hierarchy. I plan to simplify harden so that this will stop being an issue.
Given that you start at Object and work your way down the inheritance hierarchy, it should work. But it is an untried experiment. Please let us know how it goes.
dckc not wonderfully. Segmentation fault. I didn't do any fringe setup, though
oh... maybe that was irrelevant. I think I skipped a step and loaded a bogus snapshot
now we're at exception: ?.complain: no function! which I think we earlier decoded to mean "you forgot to provide testLogger in your vat endowments"
it's a call to console.error. where are we building console? boy there's a lot to juggle here...
now this is more to be expected:
TypeError: prototype function  (){[native code]} of unknown is not already in the fringeSet

ok! I got the build.js and deliver-0.js steps to do the snapshot stuff.
Then deliver-1.js throws and then segfaults. hm.
ah... ok... got further:
---worker: doProcess: vat.promise[p+5] fulfilledToPresence failed: Error: unknown promiseID 'p+5'

I'm using the verboten Object.freeze(x, true) though
ideally, XS would have a hardened bit along with the frozen bit in its objects, right?
how does it do Object.frozen? let's see...
it checks XS_DONT_SET_FLAG and XS_DONT_DELETE_FLAG on each property (among other things). So it's not one bit on an object.
@erights : Object.freeze(x, true) has no chance of working. You need to get past the fringeset error so you can do a harden. Try first doing a harden([Object, Function, Array]), to get the super-most layer first. Then hardening of most other things should work because they inherit only from things hardened by the above expression.
@warner : also, if we replaced harden with a dummy version, I don't think anything in swingset would notice the difference
@mfig : Liveslots' marshal layer would notice.

Fixed by #541


JSON node: delete msg.schema before sending msg to avoid conflicts

[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)

Proposed changes
This deletes the msg.schema property before sending the msg to avoir conflicts with further JSON nodes.
Checklist

[x] I have read the contribution guidelines
[x] For non-bugfix PRs, I have discussed this change on the mailing list/slack team.
[x] I have run grunt to verify the unit tests pass
[x] I have added suitable unit tests to cover the new/changed functionality

Can we get a sentence added to https://github.com/node-red/node-red/blob/6201247875ade2f793b733434e5c9a3f2bfbd1ab/packages/node_modules/%40node-red/nodes/locales/en-US/parsers/70-JSON.html#L24 to say the property is deleted when it passes through?

Coverage increased (+0.008%) to 76.504% when pulling 6d771da9a9415ae87017600a8cd56dfe1ada087c on natcl:dev into<PHONE_NUMBER>ade2f793b733434e5c9a3f2bfbd1ab on node-red:dev.

Done !

@HiroyasuNishiyama this PR changes https://github.com/node-red/node-red/pull/1999/files#diff-ce311af19ab77dc39f4238d9e18c8add


Diacritics and symbols from soundcomp (Germanic)

[ ] As it stands, check_export.py considers all tokens containing vowel sequences ("aɪ", "aʊ", "iˑə", "uə", "äɪ", "iə", "øɛ" etc.) as �. This might be remedied by making the script check vowel symbols before segmentation, or by iterating over each vowel symbol in a vowel token and performing consistency checks only the individual symbols, but these are just suggestions.
[ ] A number of symbols/combinations of base symbols and diacritics are not recognized by CLTS yet and should be added
a.	Half length, e.g. nˑ mˑ
b.	retracted, e.g. s̠ θ̠  ç̠ (these are not affricates. these are fricatives with a slightly retracted place of articulation)
c.	advanced, e.g.  k̟
d.	uvularization, e.g. ʌʶ
e.	syllabicity 1, e.g. ŋ̣  ɫ̣ and syllabicity 2, e.g. r̝̩ (looking at Anderson et al. p. 7, it appears that the latter is the preferred way of representing syllabicity in CLTS, but it is not discussed explicitely)
f.	rounding, e.g. ɜ̹
g.	alveolar, e.g. θ͇
h.	laminal, e.g. s̻
i.	lowered, e.g. v̞
j.	raised, e.g. ɹ̝ ɾ̝

For some reason, the errors.md file in the repository gives a shorter list of errors than the error file created when I run the script on the same data on my laptop. I am attaching the error report here so you can compare. The main difference seems to be that in the attached file, all vowel sequence (even straightforward ones such as 'aɪ') are reported whereas in the errors.md in the repository, V sequences are not included.

I probably ran it before implementing the vowel_merge feature, or maybe I was tweaking with the command-line parameters. It is also possible that our source files are different, as I was using the one Paul had sent me by email.
I would trust more your results, in short. :wink:

For some reason, the errors.md file in the repository gives a shorter list of errors than the error file created when I run the script on the same data on my laptop. I am attaching the error report here so you can compare. The main difference seems to be that in the attached file, all vowel sequence (even straightforward ones such as 'aɪ') are reported whereas in the errors.md in the repository, V sequences are not included.
This is, by the way, again not related to CLTS, right? This is related to sound comparison...

Maybe - to prevent this kind of reproducibility problem - we should also have the data in a repository? There's already https://github.com/clld/soundcomparisons-data/ so maybe this would be a good place?

Indeed. And given that you can specify the TSV file from the command line, there is no need to change the code for that.

This is, by the way, again not related to CLTS, right? This is related to sound comparison...

Well, we do need to know if there is a general issue with the treatment of diphthongs or if something went wrong with running the script on our side...

Well, we do need to know if there is a general issue with the treatment of diphthongs or if something went wrong with running the script on our side...

From your message, it was not clear, so specify the detailed "failures" or discuss them on soundcomparisons.

To re-iterate the reproducibility argument: which script are we talking about? Should it be included in this repos?

this one. The SC team asked some time ago that @tresoldi helped them to do the lingpy analyses, as they want to have the alignments, so the script runs some checks on the data. In fact, we're waiting for @bibiko to actually look at the script and fix errors first on the SC side, as there are many problems with the transcriptions, so the general question resulting from using this script are in my opinion usually not general enough to be discussed here completely, specifically, since we loose the context (talking about a script that has nothing to do with clts).
So in this thread, only suggestions regarding potentially missing feature values in CLTS should be collected, and I'd hope that @cormacanderson finds time to evaluate them, also because I think that the IPA in SC is often too impressionistic, reflecting features that are barely found in the languages if one follows a broader phonetic transcription, and I'd even bet that the features are at times even due to misperception, or the perception of individual speaker variation as representing true phonetic variation, but that's another issue.

@LinguList If you can point at concrete examples of where transcriptions in soundcomparisons are wrong, misperceived, or the use of specific symbols or diacritics is otherwise unwarranted, we're happy to hear your input. From what I can tell, the majority of transcriptions was made by experts on the respective languages/dialects and that every phonetic detail is potentially valuable for linguistic comparisons. Why should we limit ourselves to a fixed set of phonetic symbols when there are so many phonetic features that could potentially be of interest, also considering that the number of varieties in soundcomp is constantly growing? But this is probably not the right place to discuss this here.
Coming back to the question of the diphthongs, I've added some of the rejected tokens to the original post. I hope you agree that they should not be treated as errors.

As the main crossover person between these two projects, i.e. SndCmp and CLTS, I feel it my responsibility to intervene here.
I don't see it as simple as the SndCmp team wanting the Edictor alignments. CLTS was assembled on the basis of data from a number of sources and we didn't get everything, it is quite clear. To improve the coverage of CLTS we need further data and SndCmp, with its narrow phonetic transcriptions, is ideal for this. Therefore, it's not one-directional. This is a win-win endeavour – SndCmp gets access to Edictor alignments, CLTS gets tested against an ideal dataset.
Pretty much all of what Ludger outlines there is straightforward IPA. CLTS should get it and if it doesn't, then we have to fix it. I will sit down with @tresoldi to try to add these diacritics to CLTS, along with other ones we have already identified. There is a further stimulus to do this given the news we have re the paper.
As for the concern re data quality @LinguList, I'm glad that you take this seriously. However, I've seen the data quality in CLICs, in bits of Lexibank, in the Concepticon, all with graver data quality problems than SndCmp in my book. It puzzles me that you focus on SndCmp in this regard. I also think that your suggestion of misperception or mistaking individual speaker variation for "true phonetic variation" (you mean "geographical variation" I presume?, as even intra-speaker variation is still true phonetic variation) is unfair to the people who did those transcriptions, who in most cases are really expert phoneticians who know these families really well. Individual errors of this sort there will surely be, but I don't think they are systematic. I second @LuPaschen in asking you to provide examples where you think there are mistakes – this is a collaborative project after all, we want people to help us find errors.
As for identifying features that don't occur in a broader transcription, well I think that's the point. We don't have other large resources like this of good narrow transcriptions that are machine readable (many of them are just languishing in the dialect atlases!). There are lots of things that we can't even begin to look at with broad transcriptions, but can with these. There's are all manner of questions about sound change that we can ask using narrow transcriptions that we can't ask with broader ones. I'll happily share examples with you in person if you wish.

Okay, I trust you, @cormacanderson to get the things done so that they can be implemented in CLTS. My job is not to question whether symbols are needed, but to make sure the code runs, as nobody was thinking of making this codable before. We'll launch the first version of clts end of November, when @xrotwang is here, and all data needs to be adjusted and ready by then.
We'll talk again about data consistency if we have the things mapped consistently to CLTS and also corrected the problems in SC data. And then we can count how many different segments we find there, and we can discuss how many are needed in theory, and to which degree the fact that limited language data is transcribed here leads to phonetic transcriptions that would be made otherwise by different transcribers. For the task of automatic language comparison, the data cannot be used, as it is too sparse and too narrow, so that no regular sound correspondences can be identified. I tested on Germanic and Romance and can share this. That means in fact that if you want to look into sound change, the major argument, the regularity, is lost due to over-narrow transcriptions. But we can discuss this again once all alignments are readily assembled.

Adding these updates to https://github.com/cldf/clts/issues/121. I will leave this thread open for reports of likely CLTS problems found in the SndCmp studies and will rename this to reflect that. After being reported here, I will assess them and move them to Adding these updates to https://github.com/cldf/clts/issues/121 when necessary.

Closing this issue as per https://github.com/cldf/clts/pull/123 ; once CLTS is released, we can rerun the analysis and check what is still pending (most of the problems should be fixed now).