Unable to establish Gossip syncer with CLN channel peer, causing a loop of disconnections

Background
For 7 days, my node can't establish a healthy connection to a peer running CLN (presumably).

lncli getchaninfo<PHONE_NUMBER>94384392 shows that my node has an outdated "last_update" flag from Wed Jun 15 12:18:17 CEST 2022
LND log shows a continuing error with Gossip syncer for peer=0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c not found, which results in two issues
My node assumes the channel to me is disabled
The channel never stays established, since every 4 minutes a reconnection is initiated, resulting in the same error

Your environment

version of lnd: v0.15.0-beta.rc5
which operating system (uname -a on *Nix): Linux debian-nuc 5.10.0-14-amd64 1 SMP Debian 5.10.113-1 (2022-04-29) x86_64 GNU/Linux
version of btcd, bitcoind, or other backend: Bitcoin v23.0.0
any other relevant environment details:

I have the outdated channel-state with a few peers, since a reboot 2 days ago. It started with 20 peers / 117 with a stale last_update flag, and plenty of reboots or lncli reconnects with the peer didn't help. 26hrs later, 50% of channels got back. Now, 40hrs later, I have
peers disabling to me:    6
left with an old channel-state.
What's worth mentioning: I changed locale globally 2 weeks before, and this reboot was the first restart since that change. I'm unsure if the local change could have caused a timestamp issue for gossip, but to be seen. First, suggest focusing on one channel.
Steps to reproduce

Compare my command with the same one on your node on mainnet, and see if the last_update flag of peer2 is as outdated as mine is

admin ~ ฿ lncli getchaninfo<PHONE_NUMBER>94384392
{
    "channel_id": "812312593594384392",
    "chan_point": "c6a6ee11cf5c8e2271de900613d9d570f26e66e2471ae5ca1d375d5706db9f4e:8",
    "last_update":<PHONE_NUMBER>,
    "node1_pub": "037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3",
    "node2_pub": "0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c",
    "capacity": "5000000",
    "node1_policy": {
        "time_lock_delta": 40,
        "min_htlc": "1000",
        "fee_base_msat": "0",
        "fee_rate_milli_msat": "180",
        "disabled": false,
        "max_htlc_msat": "4950000",
        "last_update":<PHONE_NUMBER>
    },
    "node2_policy": {
        "time_lock_delta": 34,
        "min_htlc": "1",
        "fee_base_msat": "0",
        "fee_rate_milli_msat": "0",
        "disabled": true,
        "max_htlc_msat": "4950000000",
        "last_update":<PHONE_NUMBER>
    }
}
admin ~ ฿ date -d @1655288297
Wed Jun 15 12:18:17 CEST 2022
admin ~ ฿ date -d @1655814213
Tue Jun 21 14:23:33 CEST 2022

Logfiles excerpt, this is going on forever this way. Notable is
2022-06-22 08:30:56.100 [INF] PEER: unable to read message from 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c@<IP_ADDRESS>:9736: read tcp <IP_ADDRESS>:60428-><IP_ADDRESS>:9736: use of closed network connection

2022-06-22 08:27:46.539 [INF] SRVR: Disconnecting from 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c@<IP_ADDRESS>:9736
2022-06-22 08:27:46.539 [INF] PEER: disconnecting 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c@<IP_ADDRESS>:9736, reason: server: disconnecting peer 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c@<IP_ADDRESS>:9736
2022-06-22 08:27:46.539 [INF] PEER: unable to read message from 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c@<IP_ADDRESS>:9736: read tcp <IP_ADDRESS>:58784-><IP_ADDRESS>:9736: use of closed network connection
2022-06-22 08:27:46.647 [INF] SRVR: Established connection to: 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c@<IP_ADDRESS>:9736
2022-06-22 08:27:46.647 [INF] SRVR: Finalizing connection to 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c@<IP_ADDRESS>:9736, inbound=false
2022-06-22 08:27:46.689 [INF] PEER: NodeKey(0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c) loading ChannelPoint(c6a6ee11cf5c8e2271de900613d9d570f26e66e2471ae5ca1d375d5706db9f4e:8)
2022-06-22 08:27:46.689 [INF] PEER: Negotiated chan series queries with 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c
2022-06-22 08:27:46.740 [INF] DISC: Removing GossipSyncer for peer=0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c
2022-06-22 08:27:46.851 [WRN] DISC: Gossip syncer for peer=0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c not found
2022-06-22 08:27:47.152 [INF] SRVR: Disconnecting from 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c@<IP_ADDRESS>:9736
2022-06-22 08:27:47.152 [INF] PEER: disconnecting 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c@<IP_ADDRESS>:9736, reason: server: disconnecting peer 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c@<IP_ADDRESS>:9736
2022-06-22 08:27:47.152 [INF] PEER: unable to read message from 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c@<IP_ADDRESS>:9736: read tcp <IP_ADDRESS>:60410-><IP_ADDRESS>:9736: use of closed network connection
2022-06-22 08:27:47.240 [INF] SRVR: Established connection to: 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c@<IP_ADDRESS>:9736
2022-06-22 08:27:47.240 [INF] SRVR: Finalizing connection to 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c@<IP_ADDRESS>:9736, inbound=false
2022-06-22 08:27:47.285 [INF] PEER: NodeKey(0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c) loading ChannelPoint(c6a6ee11cf5c8e2271de900613d9d570f26e66e2471ae5ca1d375d5706db9f4e:8)
2022-06-22 08:27:47.285 [INF] PEER: Negotiated chan series queries with 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c
2022-06-22 08:27:47.285 [INF] DISC: Creating new GossipSyncer for peer=0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c
2022-06-22 08:27:47.453 [INF] DISC: Removing GossipSyncer for peer=0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c
2022-06-22 08:28:07.674 [WRN] RPCS: Gossip syncer for peer=0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c not found
2022-06-22 08:28:28.649 [WRN] RPCS: Gossip syncer for peer=0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c not found
2022-06-22 08:28:49.660 [WRN] RPCS: Gossip syncer for peer=0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c not found
2022-06-22 08:29:10.657 [WRN] RPCS: Gossip syncer for peer=0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c not found
2022-06-22 08:29:31.657 [WRN] RPCS: Gossip syncer for peer=0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c not found
2022-06-22 08:29:52.689 [WRN] RPCS: Gossip syncer for peer=0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c not found
2022-06-22 08:30:13.666 [WRN] RPCS: Gossip syncer for peer=0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c not found
2022-06-22 08:30:34.646 [WRN] RPCS: Gossip syncer for peer=0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c not found
2022-06-22 08:30:55.664 [WRN] RPCS: Gossip syncer for peer=0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c not found
2022-06-22 08:30:56.100 [INF] SRVR: Disconnecting from 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c@<IP_ADDRESS>:9736
2022-06-22 08:30:56.100 [INF] PEER: disconnecting 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c@<IP_ADDRESS>:9736, reason: server: disconnecting peer 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c@<IP_ADDRESS>:9736
2022-06-22 08:30:56.100 [INF] PEER: unable to read message from 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c@<IP_ADDRESS>:9736: read tcp <IP_ADDRESS>:60428-><IP_ADDRESS>:9736: use of closed network connection
2022-06-22 08:30:56.195 [INF] SRVR: Established connection to: 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c@<IP_ADDRESS>:9736
2022-06-22 08:30:56.195 [INF] SRVR: Finalizing connection to 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c@<IP_ADDRESS>:9736, inbound=false
2022-06-22 08:30:56.235 [INF] PEER: NodeKey(0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c) loading ChannelPoint(c6a6ee11cf5c8e2271de900613d9d570f26e66e2471ae5ca1d375d5706db9f4e:8)
2022-06-22 08:30:56.235 [INF] PEER: Negotiated chan series queries with 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c
2022-06-22 08:30:56.235 [INF] DISC: Creating new GossipSyncer for peer=0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c
2022-06-22 08:30:56.301 [INF] DISC: Removing GossipSyncer for peer=0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c
2022-06-22 08:30:56.402 [WRN] DISC: Gossip syncer for peer=0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c not found

Expected behaviour
The channel, Gossip syncer is staying connected and more recent.
Actual behaviour
The channel is  unhealthy, continuing reconnections, and hence unusable
2022-06-22 06:37:13.110 ⛔ disconnected from noserver4u | CLN 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c

2022-06-22 06:37:13.202 💚 connected to noserver4u | CLN 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c

2022-06-22 06:40:22.086 ⛔ disconnected from noserver4u | CLN 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c

2022-06-22 06:40:22.170 💚 connected to noserver4u | CLN 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c

2022-06-22 06:43:31.125 ⛔ disconnected from noserver4u | CLN 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c

2022-06-22 06:43:31.215 💚 connected to noserver4u | CLN 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c

2022-06-22 06:46:40.127 ⛔ disconnected from noserver4u | CLN 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c

2022-06-22 06:46:40.225 💚 connected to noserver4u | CLN 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c

2022-06-22 06:47:52.726 📣 local update for peer noserver4u | CLN 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c (online)
    is_disabled: 0 -> 1
    updated_at: 2022-06-21T12:23:33.000Z -> 2022-06-22T06:47:52.469Z

2022-06-22 06:49:48.088 ⛔ disconnected from noserver4u | CLN 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c

2022-06-22 06:49:48.172 💚 connected to noserver4u | CLN 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c

Conclusion
While I could just close the channel and reopen, since I know other peers with that node don't have that issue, I wonder if that is a

locale issue I created, but unlikely, since this channel is outdated already for a week (reboot and hence lnd-restart was 2 days ago)
a connection error b/w LND & CLN, but specific to my node
anything RC5 related

Adding some interesting facts. The channel state is outdated for other nodes, too.
This might be a CLN / LND gossip syncer connection issue?
To verify, call these two commands from your mainnet node:

lncli getchaninfo<PHONE_NUMBER>94384392 which is my LND node channel with the CLN peer
lncli getchaninfo<PHONE_NUMBER>06446604 which is another LND node channel with the very same CLN peer

The latter shows an delay in update to the gossip of > 2 days, the former / mine > 7 days.

Hi, it's me the cln 0.11.1, bitcoind v23, debian bullseye node.
lightning-cli listchannels 738794x965x8
{
   "channels": [
      {
         "source": "037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3",
         "destination": "0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c",
         "short_channel_id": "738794x965x8",
         "public": true,
         "satoshis": 5000000,
         "amount_msat": "5000000000msat",
         "message_flags": 1,
         "channel_flags": 0,
         "active": true,
         "last_update":<PHONE_NUMBER>,
         "base_fee_millisatoshi": 0,
         "fee_per_millionth": 180,
         "delay": 40,
         "htlc_minimum_msat": "1000msat",
         "htlc_maximum_msat": "4950000msat",
         "features": ""
      },
      {
         "source": "0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c",
         "destination": "037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3",
         "short_channel_id": "738794x965x8",
         "public": true,
         "satoshis": 5000000,
         "amount_msat": "5000000000msat",
         "message_flags": 1,
         "channel_flags": 1,
         "active": true,
         "last_update":<PHONE_NUMBER>,
         "base_fee_millisatoshi": 0,
         "fee_per_millionth": 0,
         "delay": 34,
         "htlc_minimum_msat": "1msat",
         "htlc_maximum_msat": "4950000000msat",
         "features": ""
      }
   ]
}

2022-06-22T08:14:49.299Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-connectd: destroy_subd: 1 subds, to_peer conn (nil), read_to_die = 0
2022-06-22T08:14:49.299Z INFO    037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-channeld-chan#50: Peer connection lost
2022-06-22T08:14:49.299Z INFO    037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-chan#50: Peer transient failure in CHANNELD_NORMAL: channeld: Owning subdaemon channeld died (62208)
2022-06-22T08:14:49.299Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-lightningd: Will try reconnect in 1 seconds
2022-06-22T08:14:49.300Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-connectd: disconnect
2022-06-22T08:14:49.300Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-connectd: peer_conn_closed
2022-06-22T08:14:49.300Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-lightningd: peer_disconnect_done
2022-06-22T08:14:49.300Z DEBUG   plugin-funder: Cleaning up inflights for peer id 037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3
2022-06-22T08:14:49.332Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-connectd: Connect IN
2022-06-22T08:14:49.485Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-connectd: peer_out WIRE_INIT
2022-06-22T08:14:49.485Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-connectd: peer_in WIRE_INIT
2022-06-22T08:14:49.485Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-gossipd: seeker: starting gossip
2022-06-22T08:14:49.486Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-chan#50: Peer has reconnected, state CHANNELD_NORMAL: telling connectd to make active
2022-06-22T08:14:49.486Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-connectd: Handed peer, entering loop
2022-06-22T08:14:49.486Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-connectd: Activating for message WIRE_CHANNEL_REESTABLISH
2022-06-22T08:14:49.490Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-channeld-chan#50: pid 3942791, msgfd 123
2022-06-22T08:14:49.490Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-chan#50: Already have funding locked in (and ready to announce)
2022-06-22T08:14:49.491Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-chan#50: attempting update blockheight 4e9fdb06575d371dcae51a47e2666ef270d5d9130690de71228e5ccf11eea6ce
2022-06-22T08:14:49.491Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-connectd: peer_out WIRE_GOSSIP_TIMESTAMP_FILTER
2022-06-22T08:14:49.492Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-channeld-chan#50: option_static_remotekey = 1, option_anchor_outputs = 0
2022-06-22T08:14:49.492Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-channeld-chan#50: init LOCAL: remote_per_commit = 035e370014d7717fe959119ac7a520c8bf153e7a8a43a4f9cdb5d44bfbd930d2dd, old_remote_per_commit = 03cc7a6e4f704ce302b0f524c66563fa15c8f03f49ad47f313e1875563609144d6 next_idx_local = 77074 next_idx_remote = 77098 revocations_received = 77096 feerates { SENT_ADD_COMMIT:503 SENT_ADD_ACK_REVOCATION:582 } range 253-37583 blockheights { SENT_ADD_ACK_REVOCATION:0 }, our current 741831
2022-06-22T08:14:49.492Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-hsmd: Got WIRE_HSMD_GET_PER_COMMITMENT_POINT
2022-06-22T08:14:49.492Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-hsmd: Got WIRE_HSMD_GET_PER_COMMITMENT_POINT
2022-06-22T08:14:49.493Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-channeld-chan#50: peer_out WIRE_CHANNEL_REESTABLISH
2022-06-22T08:14:49.493Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-hsmd: Got WIRE_HSMD_GET_PER_COMMITMENT_POINT
2022-06-22T08:14:49.493Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-channeld-chan#50: billboard: Sent reestablish, waiting for theirs
2022-06-22T08:14:49.493Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-channeld-chan#50: peer_in WIRE_CHANNEL_REESTABLISH
2022-06-22T08:14:49.493Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-channeld-chan#50: Got reestablish commit=77097 revoke=77073
2022-06-22T08:14:49.494Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-channeld-chan#50: next_revocation_number = 77073
2022-06-22T08:14:49.494Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-hsmd: Got WIRE_HSMD_SIGN_REMOTE_COMMITMENT_TX
2022-06-22T08:14:49.494Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-channeld-chan#50: option_static_remotekey: fields are correct
2022-06-22T08:14:49.494Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-channeld-chan#50: Retransmitting commitment, feerate LOCAL=582 REMOTE=503, blockheight LOCAL=0 REMOTE=0
2022-06-22T08:14:49.494Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-hsmd: Got WIRE_HSMD_CANNOUNCEMENT_SIG_REQ
2022-06-22T08:14:49.494Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-channeld-chan#50: peer_out WIRE_UPDATE_FEE
2022-06-22T08:14:49.494Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-channeld-chan#50: Creating commit_sig signature 77097 304402204fa038b66fd88ce9fa27bf0d983e6d2c33e383514e7d23229259cf4dfcd53ad10220741ced8c119da70c547cc7dc1c12bda4685aa1761ab2bcdaf92a672a103f0e5501 for tx<PHONE_NUMBER>4e9fdb06575d371dcae51a47e2666ef270d5d9130690de71228e5ccf11eea6c60800000000d80c848002fb20030000000000220020df9c12a59f339339a00bd5d4813b4df73d3714430e53517fa205d320f2071ab9d828490000000000160014aa78656d6f085dc0196b05adafdfe72c0d841ec10b4b5b20 wscript 522102127b9da18851feaedcc2d5f030394696ef4a80260c0621722ee078324266286321038fd64f9ed8c65d00d66ac40400320e7b0aa3552d1e05d2a213e9e8221957c53e52ae key 02127b9da18851feaedcc2d5f030394696ef4a80260c0621722ee0783242662863
2022-06-22T08:14:49.495Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-channeld-chan#50: peer_out WIRE_COMMITMENT_SIGNED
2022-06-22T08:14:49.495Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-channeld-chan#50: billboard perm: Reconnected, and reestablished.
2022-06-22T08:14:49.495Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-channeld-chan#50: Exchanging announcement signatures.
2022-06-22T08:14:49.495Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-channeld-chan#50: peer_out WIRE_ANNOUNCEMENT_SIGNATURES
2022-06-22T08:14:49.495Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-channeld-chan#50: billboard: Funding transaction locked. Channel announced.
2022-06-22T08:14:49.525Z DEBUG   037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3-channeld-chan#50: billboard: Funding transaction locked. Channel announced.

Thanks @Roasbeef coming back to us.
We'll consider the next two steps available (close / reopen or wait and apply the upcoming CLN release) and report back here, for the benefit of others.

Looks like it stabilized now over time. Clearnet connections now established.
2022-06-26 00:25:44.322 [INF] PEER: unable to read message from 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c@<IP_ADDRESS>:9736: EOF
2022-06-26 00:25:44.322 [INF] PEER: disconnecting 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c@<IP_ADDRESS>:9736, reason: read handler closed
2022-06-26 00:25:44.525 [INF] DISC: Removing GossipSyncer for peer=0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c
2022-06-26 00:25:47.074 [WRN] SRVR: Already have 1 persistent connection requests for 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c@<IP_ADDRESS>:9736, connecting anyway.
2022-06-26 00:28:06.285 [INF] SRVR: Established connection to: 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c@<IP_ADDRESS>:9736
2022-06-26 00:28:06.285 [INF] SRVR: Finalizing connection to 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c@<IP_ADDRESS>:9736, inbound=false
2022-06-26 00:28:06.771 [INF] PEER: NodeKey(0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c) loading ChannelPoint(c6a6ee11cf5c8e2271de900613d9d570f26e66e2471ae5ca1d375d5706db9f4e:8)
2022-06-26 00:28:06.773 [INF] PEER: Negotiated chan series queries with 0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c
2022-06-26 00:28:06.773 [INF] DISC: Creating new GossipSyncer for peer=0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c
2022-06-26 06:40:52.517 [INF] DISC: GossipSyncer(0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c): fetching chan anns for 128 chans
2022-06-26 06:45:52.848 [INF] DISC: GossipSyncer(0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c): fetching chan anns for 128 chans
2022-06-26 07:51:57.049 [INF] DISC: GossipSyncer(0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c): filtering chan range: start_height=704308, num_blocks=1024
2022-06-26 07:51:57.050 [INF] DISC: GossipSyncer(0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c): sending final chan range chunk, size=900
2022-06-26 11:35:53.147 [INF] DISC: GossipSyncer(0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c): fetching chan anns for 3942 chans
2022-06-26 11:40:53.604 [INF] DISC: GossipSyncer(0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c): fetching chan anns for 128 chans
2022-06-26 11:58:53.106 [INF] DISC: GossipSyncer(0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c): fetching chan anns for 31 chans
2022-06-26 17:59:17.109 [INF] DISC: GossipSyncer(0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c): applying gossipFilter(start=2022-06-26 17:59:17.10929713 +0200 CEST m=+205256.731936658, end=2158-08-03 00:27:32.10929713 +0200 CEST)
2022-06-26 18:39:17.109 [INF] DISC: GossipSyncer(0380ef0209ff1b46c38a37cd40f613d1dae3eba481a909459d6c1434a0e56e5d8c): applying gossipFilter(start=0001-01-01 00:00:00 +0000 UTC, end=0001-01-01 00:00:00 +0000 UTC)

Closing this for now, but will keep an eye and see if it's happening again.


Introduce SharedCollidableComponent

PR Details
Bepu Physics was missing a feature: the ability to reuse shapes to avoid unnecessary allocations.
Related Issue
Potential performance impact resulting in lower FPS.
Types of Changes

[ ] Docs change / refactoring / dependency upgrade
[ ] Bug fix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

[X] My change requires documentation updates.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests have passed.
[X] I have built and run the editor to verify this change.

@Eideren I let you review my nonsense and maybe test it a little more in depth, but it was working on my side!

Hey @Nicogo1705 thanks a bunch for looking into this one, do you think it would be possible to automate this process instead ? This sounds like it would be kind of a pain when you want to optimize for cases where you have arbitrary prefabs being spawned in.
Maybe checking the shape parameters for a shape we're about to create against a dictionary of those that already exists might work, similar idea to what we already have for the hulls actually:
https://github.com/stride3d/stride/blob/b59fbc5dfa875895600e58bbddfa7da0517b00c8/sources/engine/Stride.BepuPhysics/Stride.BepuPhysics/Definitions/Colliders/ConvexHullCollider.cs#L43-L71

@Eideren I can definitely add that as an additional feature. The approach I’m using offers some advantages over yours. For example, if you edit just the SharedCollider, all colliders on all associated bodies or static objects are automatically updated. By contrast, with your approach, editing one of the shared colliders creates a new shape in the pool, leaving the others to continue using the original shape.

@Nicogo1705 the bullet implementation had a similar idea were users could refer to a specific collider shape asset instead of an inline collider definition, issue is that that feature is just a less useful version of our prefab inheritance system - the only cases it doesn't cover would be for two distinct object sharing the same shape, which in itself is not recommended as it is fragile; since they are distinct objects, you have to double check that they still fit the shape every time you edit it.
I can't think of any case at runtime where it would be useful to edit multiple shapes at once ?

@Eideren,
I see your point. Avoiding the “ref” might indeed simplify things in some scenarios.
But it some case, e.g a door, you could open/close a door without rebuilding/checking a collider (Body.Collider = ClosedDoorSharedCollider or Body.Collider = OpenedDoorSharedCollider).
I’ve added automatic sharing —please take a look and let me know what you think. I haven’t tested it yet, but I’ll try tomorrow.


fee handler java translation

fee handler java translation and unit tests

@simusud If want some help with evaluating the test you can add jacoo test coverage, so you can see what code you cover int the unit tests. you can see it in the loansContract rewrite or on the bnusd pull request i showed how to add it.

Initial review looks good, some mostly minor changes 💪 . Also make sure the rebase on main and use the dependency structure in place there.
Still need to look at the testing, will do that a little later.
Edit: I do not see a gradle file commited for you contract, did you forget to add it? Will pause review until that is resolved so i can run the code.

sorry about that , i have just uploaded the gradle file and rebased the branched to main.

Made the requested changes .  Please have a look once .

Look at how nightowl use static mock to replace the need to mock normal contracts.
https://github.com/balancednetwork/balanced-java-contracts/pull/54#discussion_r837346066
You can look there to see how you can probably remove the need for a governance mock

Developing now is like constantly developing against a moving target, sorry about that. But if you can please rebase on master, and add a interface to you contract in score-lib, which you then implement in your contract. You can check how it is done for example rebalancing.

@AntonAndell feehandler is ready for merge


0.1.40 release request

Hi. Please release 0.1.40 that would work with GHC 8.6.5.
Thank you!

Seconded (or sixthed); I can't complete installation of haskero because I'm a noob.

https://github.com/chrisdone/intero/pull/619 does the bump

Pushed 0.1.40 with GHC 8.6.5 bound.


Allow cross zone creation of keyvault cert requests from dns registra…

This PR allows to decouple the creation of keyvault cert request from the dns domain name registration resource blocks

hi @hantonelli thanks for the PR.
when trying to run example 103, I get the following error:
Error: Error in function call
│
│   on ../modules/security/keyvault_certificate_request/module.tf line 35, in resource "azurerm_key_vault_certificate" "csr":
│   35:         subject            = try(x509_certificate_properties.value.subject, "CN=${try("${x509_certificate_properties.value.domain_name_registration.subdomain}.", "")}${var.domain_name_registrations[try(x509_certificate_properties.value.domain_name_registration.lz_key, var.client_config.landingzone_key)][x509_certificate_properties.value.domain_name_registration.key].dns_domain_registration_name}")
│     ├────────────────
│     │ var.client_config.landingzone_key is "examples"
│     │ var.domain_name_registrations is object with 1 attribute "examples"
│     │ x509_certificate_properties.value is object with 4 attributes
│     │ x509_certificate_properties.value.domain_name_registration.key is "domain1"
│     │ x509_certificate_properties.value.domain_name_registration.lz_key is "example-domain-lz-key"
│     │ x509_certificate_properties.value.domain_name_registration.subdomain is "*"
│
│ Call to function "try" failed: no expression succeeded:
│ - Unsupported attribute (at ../modules/security/keyvault_certificate_request/module.tf:35,67-75)
│   This object does not have an attribute named "subject".
│ - Invalid index (at ../modules/security/keyvault_certificate_request/module.tf:35,198-305)
│   The given key does not identify an element in this collection value.
│
│ At least one expression must produce a successful result.
╵
Terraform plan return code: 1
Error on or near line 391: Error running terraform plan; exiting with status 1

Hi @arnaudlh, I updated the example. It show how to create a keyvault_certificate_requests using a domain_name_registration  created in the same landing zone. The example has the lz_key commented out as the examples are designed to run on a single landing zone. I had added a README.md with relevant comments, I hope that helps.

Hi @arnaudlh, I updated the example and added a README.md . The example show how to create a keyvault_certificate_requests using a domain_name_registrations, created in the same landing zone. The example has the  lz_key property commented out, as the examples are designed to run in a single landing zone, but is an example of how to use that property. I hope that the update example and new README.md help. Thank you for testing this PR.


Using new cosmwasm_schema

I try to implement what's in #81.
Remaining issues:

In cw2981-royalites, QueryMsg<Cw2981QueryMsg> is used. As in cw721-base generates an empty response for Extension, there is no response generated for Cw2981QueryMsg. I haven't found a solution for this.
In cw721-non-transferable, most of QueryMsg enums are redefined. I want a more robust solution than copy lines from cw721-base.

@shanev @larry0x
Can you help me check why circle ci didn't run?

For some strange reason, no CircleCI build is started. I don't know why. I'll set a reminder to check again tomorrow.

We are getting builds now :)

It was because I asked Circle ci to check my fork... really sad!

Strange because fork builds are enabled and they worked for other PRs here before. I see the build in https://app.circleci.com/pipelines/github/CosmWasm/cw-nfts now.


xcode update

Xcode update ton of errors

+1

+1

It looks like #274 is a duplicate of this. But I'll add my +1. As mentioned earlier, I'd love to help but have no clue where to start since it's literally throwing hundreds of errors when attempting to load in this library

Which Xcode version?

XCode 7 beta for me

It was because of Xcode version upgrade,
Right now, the master is using Xcode7.
If you have to use Xcode6 and Swift1.2, tryout version 2.2.1 or below.
:beers:


Avoid fetching of previous messages while bot is down

Is there a way to prevent the bot from reading or making it disregard past messages sent while bot is down?

This is just a nice to have, not an issue at all.

Telepot does not have that feature at this moment. You will have to check the message time yourself, or ignore the first batch of messages on startup :relaxed:

You could fetch the last updates with no specified offset and once again using the last updateid from the received updates.
async: await bot.getUpdates(offset=(await bot.getUpdates())[-1]['update_id'])
synced: bot.getUpdates(offset=(bot.getUpdates())[-1]['update_id'])
This code requires previous updates that are not confirmed to be received. So I would wrap this into a try/except block.

Thanks @nickoala!
Interesting workaround @das7pad I'll try that out, thank you!
I'll mark this as closed.


homebrew: add optional support for installing content shell

See https://github.com/kevmoo/homebrew-kevmoo/blob/master/dart-editor.rb
Suggestion: make the sym link use the name content_shell so we have the same name as on linux

The --with-dartium and --with-content-shell options have been added to the homebrew dart formula.
Content shell on android is no longer built or distributed.  Closing the issue.


scripts do not compile in docker after update of nasher

With the new nasher version most scripts do not compile:
Warning: The following executable scripts do not have matching .ncs files
<long list of .nss files>

https://gist.github.com/Kaikas/ac74e9d8b6bb798b0f75032f27d82b12
If i run
docker run --rm -it -v "$(pwd):/tmp" nwneetools/nwnsc

the scripts are compiled just fine.

Hmm... Doesn't look like nwnsc is even running in your gist.
This is with 0.16.3?

Yes.

I set the version in the Dockerfile to 0.15.01 and had the same issue:
https://gist.github.com/Kaikas/7974c65b21fbb8fcfb73f40ce9d92676

I installed nasher natively without docker for now and it works. So it must be something with docker.

@Kaikas, are you still having this issue?

Closing for now. Can re-open later if this is still happening.


upgrade ClickHouse-Go dependencies to V2.0.15

Codecov Report

Merging #1904 (10e1fa4) into master (7d5ab1f) will decrease coverage by 0.09%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1904      +/-   ##
==========================================
- Coverage   73.81%   73.71%   -0.10%
==========================================
  Files         510      509       -1
  Lines       46179    45944     -235
==========================================
- Hits        34085    33867     -218
+ Misses      10032    10025       -7
+ Partials     2062     2052      -10

Flag
Coverage Δ

go-1.15-386
73.71% <ø> (+<0.01%)
:arrow_up:

go-1.15-amd64
?

go-1.16-386
?

go-1.16-amd64
?

go-1.17-386
?

go-1.17-amd64
?

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

Impacted Files
Coverage Δ

os/gspath/gspath_cache.go
84.21% <0.00%> (-10.53%)
:arrow_down:

os/gfsnotify/gfsnotify_watcher_loop.go
78.15% <0.00%> (-5.05%)
:arrow_down:

net/gtcp/gtcp_pool.go
71.59% <0.00%> (-3.41%)
:arrow_down:

os/glog/glog_logger_rotate.go
65.85% <0.00%> (-1.47%)
:arrow_down:

os/gcmd/gcmd_parser.go
92.19% <0.00%> (-0.71%)
:arrow_down:

net/ghttp/ghttp_server.go
61.94% <0.00%> (-0.67%)
:arrow_down:

container/gtree/gtree_avltree.go
95.78% <0.00%> (-0.20%)
:arrow_down:

contrib/drivers/oracle/oracle.go

os/gfsnotify/gfsnotify_watcher.go
84.03% <0.00%> (+2.52%)
:arrow_up:

Continue to review full report at Codecov.

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


Fallback to x86 if missing arm64 version

We should be ok to run amd64 binaries with rosetta when missing arm64 support, such as old versions of terraform.
$ asdf install
Downloading terraform version 0.14.11 from https://releases.hashicorp.com/terraform/0.14.11/terraform_0.14.11_darwin_arm.zip
M1 was detected, but there is no version available. Downloading the amd64 version to run with rosetta!
Downloading terraform version 0.14.11 from https://releases.hashicorp.com/terraform/0.14.11/terraform_0.14.11_darwin_amd64.zip
Verifying signatures and checksums
gpg: keybox '/var/folders/14/9h539rxx1zv_j1vv1327d5040000gp/T/asdf_terraform_XXXXXX.vR5YVKOf/pubring.kbx' created
gpg: /var/folders/14/9h539rxx1zv_j1vv1327d5040000gp/T/asdf_terraform_XXXXXX.vR5YVKOf/trustdb.gpg: trustdb created
gpg: key 34365D9472D7468F: public key "HashiCorp Security (hashicorp.com/security<EMAIL_ADDRESS>imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg: Signature made Tue Apr 19 04:34:35 2022 -03
gpg:                using RSA key 374EC75B485913604A831CC7C820C6D5CD27AB87
gpg: Good signature from "HashiCorp Security (hashicorp.com/security<EMAIL_ADDRESS>[unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: C874 011F 0AB4 0511 0D02  1055 3436 5D94 72D7 468F
     Subkey fingerprint: 374E C75B 4859 1360 4A83  1CC7 C820 C6D5 CD27 AB87
terraform_0.14.11_darwin_amd64.zip: OK
Cleaning terraform previous binaries
Creating terraform bin directory
Extracting terraform archive

There are already options for overriding the arch being used. Does that not handle this problem?

@DustinChaloupka that is true, but this way, we make it transparent to the user.
Alternatively, We can print the suggested workaround Install using ASDF_HASHICORP_OVERWRITE_ARCH_FALLBACK=amd64.

OW, I see what you mean. We don't need another switch var; we can set the override and make fewer changes to the code. I will check for it.

Maybe this is a question of how "dumb" these kinds of install tools should be. IMO, the error that is output about the specific install not being found with the arch/os should be good enough as opposed to adding in cases to handle every edge case that might pop up in the future.

Gotcha! But I still believe a better message could fit here to cover a more general audience.
Suggestion, add the repo link so users, or who will end up supporting them, can follow. I.E.
Error: terraform version 0.14.11 not found
Check documentation for alternatives https://github.com/asdf-community/asdf-hashicorp#usage

To give a little context, we have bootstrap automation for a broader audience. I liked your idea of keeping the code simple, but I prefer to at least link resources to self-serving than getting more support needed in any eventual issue. I'm good either way to implement that suggestion on my automation, as #55 did.

Cool, created #61 . Closing this one.


[CURATED PROJECT] Project #296

Project Title: Flux
Project ID: 296
Artist Channel ID:<PHONE_NUMBER>60616233

PR for this issue https://github.com/ArtBlocks/artbot/pull/259


Errors compiling with Visual Studio 2019 and Win 10 SDK 10.0.19041.0

Repro:

I opened the solution with Visual Studio 2019 version 16.9.4.
It prompted to Retarget Projects to Windows SDK 10.0.19041.0 and Platform Toolset v142.  I clicked ok to let it.
Changed cpu to x64
Set Packaging project as startup
Pressed F5 and got lots of errors starting with:
WindowsStore\WindowsStoreImpl.h(24,56): error C2039: 'Store': is not a member of 'Windows::Services'
WindowsStore\WindowsStoreImpl.h(24,56): error C3083: 'Store': the symbol to the left of a '::' must be a type
WindowsStore\WindowsStoreImpl.h(24,63): error C2039: 'StoreContext': is not a member of 'Windows::Services'

See build.log for more errors and warnings.
build.log
I'm looking for a complete example of a Desktop Bridge application accessing the Windows Store API using C++/WinRT

@Gromph I pushed the fix for building with 10941


fix doc

Hi
On this page, just fix code
https://ngx-translate.org/getting-started/installation/
from
  provideTranslateService({
     defaultLanguage: 'en'
    ])

to
     defaultLanguage: 'en'
    })

] -> }
thanks!

Fixed. Thanks for reporting this issue!


Track Cadre Per Diems & Payments

Add GSA rates to Payments table,
initialize GSA rate for all Paid invoices
and start tracking the info
Upload historical data from Zac

Set the rate columns in [Cadre].[PerDiemsUpdateInvoiceFlags] when @IsInvoiceReadyForPayment is = 1.

New sproc:
Cadre.EventCadreInvoicesInsert

The effect of these changes is that now all GSA information is actually stored in Event Manager. In cases where payment doesn't actually include the GSA, it can be entered and stored in Event Manager. SO now Event Manager can figure out exactly the amount paid for every invoice.


Bridge Server compatibility with Ganache and JS-IPFS (used by origin-js)

Origin-js uses the IPFS node module to instantiate a local ipfs.
When integrating bridge server and ipfs using the above library,
the python IPFS library does a version check when connecting to the daemon (https://github.com/ipfs/py-ipfs-api/blob/master/ipfsapi/client.py#L19) however, the node module versioning is different (https://github.com/ipfs/js-ipfs/blob/master/package.json#L3). When the bridge server tries to connect to JS-IPFS, it encounters an exception:
ipfsapi.exceptions.Error: Unsupported daemon version '[0, 28, 2]' (not in range: [0, 4, 3] – [0, 5, 0])

via https://github.com/OriginProtocol/bridge-server/pull/78


Update to revision v25.0

Android Support Library, revision 25.0.0 (October 2016) has been released: https://developer.android.com/topic/libraries/support-library/revisions.html

@Redth Can we have a preview of this on Nuget?

Sorry, this one's taken awhile since we are moving to a new mechanism for working with the actual .aar files at app compile time.  We have v25.0.1-rc1 out on NuGet now.

Closing this as 25.1.0-beta2 is on track to go stable at this point.


Add --markdown for .md and .markdown

From https://github.com/petdance/ack2/issues/593

Done 519a577


Support cluster data source

What problem does this PR solve?
close #23
close #24

Support clusters data source.
unify data struct in clusters data source and cluster resource
use random id in list datasource
alter datasource name

Test

[x] test manually

And seems there still exists some wrong references. For example:

The tidbcloud_project datasource is not right and the link also seems wrong.


Mic stop working

Hello, Microphone stop working on the last version of the app.

@grishka

Yeah you totally had to mention me as if all these issues coming in incessantly aren't obnoxious enough.


Add contributing.md

Add instructions for beginner contributors.

Can you assign this issue to me?

I have created a PR request of adding the CONTRIBUTING.md file. Please have a look


BUG: Generalize options

Generalize using specific classes for each level

[ ] Closes #xxxx (Replace xxxx with the Github issue number)
[ ] Tests added: Please use assert_type() to assert the type of any return value

Not 100% about this.  Basically facing the class structure to be more specific.


Explicitly add CREAD to c_cflag

CREAD flag is disabled after system boot for some tty devices.
This affects probably less than 1% of all devices.
For instance, this is a case for /dev/ttyS? managed by 8250_omap linux kernel driver.
The flag must be set if we want to read from the device, so lets set it explicitly even when it is already set.

Hello, anybody here?

Sorry! I dropped the ball. Thanks for the patch! Merging.


How do I use my [AMD] GPU

Hello!
Im having a blast training the AI!  :D
Im running the training on win11 right now. It works, but my CPU is so much worse than my GPU...
What do I have to do to run it on my 7900xtx?
I followed the win guide to setup the project.
Help is much appreciated^^ :)
Thanks!

Hi!
Generally ML frameworks like pytorch (which stable baselines and therefore this repo uses) don't have great support for non-nvidia gpus.
I'm not sure if using an amd gpu with pytorch on windows as possible at all. You might be able to get it to work by using windows subsystem for linux (WSL) and installing the ROCm version of pytorch, but it might be a bit of a process and I have not tested it myself.
Hope that's helpful! Do report back if you end up trying it :)

Hey thanks for answering!
I got  pytorch 2.1.2+rocm6.1.3 working on WSL.
how do I use GPU instead of CPU?

For others seeing this issue, following these instructions seemed to do the trick
https://rocm.docs.amd.com/projects/radeon/en/latest/docs/install/wsl/howto_wsl.html
if this is installed correctly the gpu should be used automatically


Fix exported vars not changing on script change

When changing the script of a node, the exported vars wouldn't update in the editor inspector until the node was reloaded or saved.
Added a check when editing a property for the script name, and calls _edit_set with update all set to true
Fixes #24845

Superseded by 61b41d600.


HTMLElement.shadowRoot is deprecated.

The contents of atom-text-editor elements are no longer encapsulated
within a shadow DOM boundary. Please, stop using shadowRoot and access
the editor contents directly instead.
HTMLElement.shadowRoot (/Applications/Atom.app/Contents/Resources/app/src/text-editor-element.js:13:10)
MarkdownScrlSync.getVisTopHgtBot (/Users/victor/.atom/packages/markdown-scroll-sync/lib/utils.coffee:20:33)
MarkdownScrlSync.setMap (/Users/victor/.atom/packages/markdown-scroll-sync/lib/map.coffee:25:14)
MarkdownScrlSync.startTracking (/Users/victor/.atom/packages/markdown-scroll-sync/lib/main.coffee:75:12)
<unknown> (/Users/victor/.atom/packages/markdown-scroll-sync/lib/main.coffee:58:23)
Function.module.exports.Emitter.simpleDispatch (<embedded>:64210:20)

Duplicate of #65


docs: replace redirection with tee command with sudo for file creation

This pull request addresses an issue where using sudo-prefixed echo does not grant elevated permissions for the subsequent redirection operation, resulting in a failure to write files under /etc/apt.
By replacing the redirection with a sudo-prefixed tee command, this change ensures that files are written with root privileges, effectively resolving the permission issue. This modification is essential for operations requiring write access to protected directories.

Thanks, @vostok92!


Build issue on Apple M1/M2

Click to expand!
Issue Type
Build/Install
Source
source
Tensorflow Version
2.9.1, 2.8.2, 2.7.3, 2.7.0
Custom Code
No
OS Platform and Distribution
macOS 12.4 (Apple M1 Pro)
Mobile device
No response
Python version
3.9.13
Bazel version
5.2.0, 4.2.2
GCC/Compiler version
Apple Clang 13.1.6
CUDA/cuDNN version
N/A
GPU model and memory
N/A
Current Behaviour?
I'm trying to update our Spack build recipe with the latest versions of TensorFlow but I'm unable to get anything to build. I've tried multiple versions of both TF and Bazel.
With TensorFlow 2.9.1 and Bazel 5.2.0 I get:
ERROR: /private/var/folders/j1/68dlgpr91vlgs26vty2c8xk80000gn/T/ajstewart/spack-stage/spack-stage-py-tensorflow-2.9.1-oljb6pzisjhfdevgnogv3hwizwhgj2rs/spack-src/tensorflow/tools/pip_package/BUILD:72:10: While resolving toolchains for target //tensorflow/tools/pip_package:simple_console: No matching toolchains found for types @bazel_tools//tools/cpp:toolchain_type. Maybe --incompatible_use_cc_configure_from_rules_cc has been flipped and there is no default C++ toolchain added in the WORKSPACE file? See https://github.com/bazelbuild/bazel/issues/10134 for details and migration instructions.

With TensorFlow 2.9.1 and Bazel 4.2.2 I get:
ERROR: /private/var/folders/j1/68dlgpr91vlgs26vty2c8xk80000gn/T/spackqkjcmrsf/08f21de77d854b22a26da21255c81581/external/build_bazel_rules_swift/swift/internal/swift_protoc_gen_aspect.bzl:457:13: 'lambda' not supported, declare a function instead

With TensorFlow 2.8.2/2.7.3/2.7.0 and Bazel 4.2.2 I get:
bazel-out/darwin_arm64-opt/bin/tensorflow/core/protobuf/error_codes.pb.h:10:10: fatal error: 'google/protobuf/port_def.inc' file not found
#include <google/protobuf/port_def.inc>
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

Multiple users have reported this last build issue: https://github.com/spack/spack/issues/31229.
Standalone code to reproduce the issue
https://github.com/spack/spack/pull/31615 is the PR where I'm working on our build recipe. This issue can be reproduced by first cloning my PR branch:
$ git clone https://github.com/adamjstewart/spack.git
$ cd spack
$ git switch packages/py-tensorflow
$ . share/spack/setup-env.sh

Then, try to install TF using one of the following commands:
$ spack install py-tensorflow
$ spack install<EMAIL_ADDRESS><EMAIL_ADDRESS>$ spack install<EMAIL_ADDRESS><EMAIL_ADDRESS>$ spack install<EMAIL_ADDRESS><EMAIL_ADDRESS>...

Unfortunately, all of these fail at the moment. You don't have to try my PR branch, the develop branch also fails. But the develop branch hasn't been updated since 2.7.0 since none of our developers have managed to get newer versions of TF to build on any system, let alone M1. Would any TF developers be interested in helping maintain this build recipe?
You can see the full build recipe and patches we currently require by running spack edit py-tensorflow or by looking at the above PR.
Relevant log output
TensorFlow 2.9.1 and Bazel 5.2.0:

build log
build env

TensorFlow 2.9.1 and Bazel 4.2.2:

build log
build env

TensorFlow 2.8.2 and Bazel 4.2.2:

build log
build env

Hi @adamjstewart, Could you try the workaround mentioned on the similar thread here. Thank you!

Thanks @gadagashwini, specifying --macos_sdk_version slightly changes the error message:
ERROR: /private/var/folders/j1/68dlgpr91vlgs26vty2c8xk80000gn/T/ajstewart/spack-stage/spack-stage-py-tensorflow-2.9.1-d4x6cs6ykcgwfw4voyejssw3z25hiuvb/spack-src/tensorflow/lite/python/BUILD:68:10: While resolving toolchains for target //tensorflow/lite/python:tflite_convert: No matching toolchains found for types @bazel_tools//tools/cpp:toolchain_type. Maybe --incompatible_use_cc_configure_from_rules_cc has been flipped and there is no default C++ toolchain added in the WORKSPACE file? See https://github.com/bazelbuild/bazel/issues/10134 for details and migration instructions.

Full logs:

build log
build env

Any idea where to go next?

Also, specifying --macos_sdk_version actually breaks TF 2.8.2/Bazel 4.2.2:
xcodebuild: error: SDK "macosx12.4" cannot be located.

Hi @adamjstewart, Isn’t  binary Tensorflow installation helpful.
python3 -m venv ~/tensorflow-metal
source ~/tensorflow-metal/bin/activate
python -m pip install -U pip
python -m pip install tensorflow-macos
python -m pip install tensorflow-metal

@gadagashwini unfortunately not. Spack is a from-source package manager. We try to build all of our software from source whenever possible. Many of our users are at HPC centers building for esoteric supercomputer architectures like aarch64 and power9 or for the Cray programming environment. Even if binaries are available, they won't be optimized for the hardware users are running on. Spack automatically detects the microarchitecture users are building on and injects optimization flags based on compiler version. This results in significant speedups compared to the unoptimized binaries provided by pip or conda.

Facing the same issue
     1469432        TF2_BEHAVIOR=1 \
     1469433        TF_SYSTEM_LIBS=com_google_protobuf \
     1469434      external/local_config_cc/cc_wrapper.sh @bazel-out/darwin_arm64-opt/bin/tensorflow/python/framework/_python_memory_checker_helper.so-2.params)
     1469435    # Configuration: 4d3375ea8b6c316a64c2fdbe102496311ca50841593a0f0f52a1cb185ed9b8c2
     1469436    # Execution platform: @local_execution_config_platform//:platform
     1469437    ld: malformed trie, node past end file 'bazel-out/darwin_arm64-opt/bin/_solib_darwin_arm64/_U_S_Stensorflow_Spython_C_Upywrap_Utensorflow_Uinternal_Umacos___Utensorflow_Spython/lib_pywrap_tensorflow_internal.dylib'
  >> 1469438    clang: error: linker command failed with exit code 1 (use -v to see invocation)
     1469439    Target //tensorflow/tools/pip_package:build_pip_package failed to build
     1469440    INFO: Elapsed time: 2126.523s, Critical Path: 168.95s
     1469441    INFO: 18958 processes: 7117 internal, 11841 local.
  >> 1469442    FAILED: Build did NOT complete successfully
  >> 1469443    FAILED: Build did NOT complete successfully

Just wanted to update this and say that I'm still having issues, this time with:

TensorFlow 2.12.0
macOS 13.2.1 (Apple M2 Pro)
Python 3.10.10
Bazel 5.3.0
Apple Clang 14.0.0
Protobuf 3.17.3

New error message:
WARNING: Download from https://storage.googleapis.com/mirror.tensorflow.org/github.com/llvm/llvm-project/archive/10939d1d580b9d3c9c2f3539c6bdb39f408179c0.tar.gz failed: class java.io.FileNotFoundException GET returned 404 Not Found
Analyzing: target //tensorflow/tools/pip_package:build_pip_package (1 packages loaded, 0 targets configured)
ERROR: /private/var/folders/jv/cgkfvslj6nq1l7cw0c8c_8gm0000gn/T/Adam/spack-stage/spack-stage-py-tensorflow-2.12.0-zswuf5jb4ste57vmh2vzpqdrgwx7gz6l/spack-src/tensorflow/core/profiler/BUILD:84:17: no such target '@com_google_protobuf//:well_known_types_py_pb2_genproto': target 'well_known_types_py_pb2_genproto' not declared in package '' defined by /private/var/folders/jv/cgkfvslj6nq1l7cw0c8c_8gm0000gn/T/spacknuem8b8t/a696d5d978fc36c0476072a38a140488/external/com_google_protobuf/BUILD.bazel and referenced by '//tensorflow/core/profiler:protos_all_py_genproto'

Hi, Could you please try with the protobuf 3.20.3 or higher since that is the minimum version requirement for Tensorflow 2.12.
You can check any version from below.
'protobuf>=3.20.3,<5.0.0dev,!=4.21.0,!=4.21.1,!=4.21.2,!=4.21.3,!=4.21.4,!=4.21.5'.

Thanks, I think https://github.com/spack/spack/pull/36263 is correct now. Unfortunately we're having other concretization problems now due to conflicting gast requirements between TF and scipy. Still trying to see if we can solve that, will report back here if we ever get that working. @aweits is also working on this with me, he may report back sooner.

Okay, using protobuf 4.21.7, I still see exactly the same issue:
ERROR: /private/var/folders/jv/cgkfvslj6nq1l7cw0c8c_8gm0000gn/T/Adam/spack-stage/spack-stage-py-tensorflow-2.12.0-utem3antrvreeqsrtb7f4aszv7ayhs4v/spack-src/tensorflow/python/tpu/BUILD:752:17: no such target '@com_google_protobuf//:well_known_types_py_pb2_genproto': target 'well_known_types_py_pb2_genproto' not declared in package '' defined by /private/var/folders/jv/cgkfvslj6nq1l7cw0c8c_8gm0000gn/T/spackzlw44jee/73416f5c6b515a686e32ac2e3981f9d3/external/com_google_protobuf/BUILD.bazel and referenced by '//tensorflow/python/tpu:tensor_tracer_proto_py_genproto'

Full dependency graph:

Click to expand
py-tensorflow<EMAIL_ADDRESS>build_system=generic patches=2017b3e arch=darwin-ventura-m2
    ^bazel<EMAIL_ADDRESS>build_system=generic patches=0f6940d,3e6448a,604423c,dbbf38b arch=darwin-ventura-m2
        ^openjdk<EMAIL_ADDRESS>build_system=generic arch=darwin-ventura-m2
    ^hdf5<EMAIL_ADDRESS>api=default build_system=cmake build_type=RelWithDebInfo generator=make arch=darwin-ventura-m2
        ^cmake<EMAIL_ADDRESS>build_system=generic build_type=Release arch=darwin-ventura-m2
        ^gmake<EMAIL_ADDRESS>build_system=autotools arch=darwin-ventura-m2
        ^pkgconf<EMAIL_ADDRESS>build_system=autotools arch=darwin-ventura-m2
        ^zlib<EMAIL_ADDRESS>build_system=makefile arch=darwin-ventura-m2
    ^protobuf<EMAIL_ADDRESS>build_system=cmake build_type=Release generator=make arch=darwin-ventura-m2
    ^py-absl-py<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
        ^py-setuptools<EMAIL_ADDRESS>build_system=generic arch=darwin-ventura-m2
    ^py-astunparse<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
    ^py-flatbuffers<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
    ^py-gast<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
    ^py-google-pasta<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
    ^py-grpcio<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
        ^c-ares<EMAIL_ADDRESS>build_system=cmake build_type=RelWithDebInfo arch=darwin-ventura-m2
        ^openssl<EMAIL_ADDRESS>build_system=generic certs=mozilla arch=darwin-ventura-m2
            ^ca-certificates-mozilla<EMAIL_ADDRESS>build_system=generic arch=darwin-ventura-m2
            ^perl<EMAIL_ADDRESS>build_system=generic arch=darwin-ventura-m2
                ^berkeley-db<EMAIL_ADDRESS>build_system=autotools patches=26090f4,b231fcc arch=darwin-ventura-m2
        ^py-cython<EMAIL_ADDRESS>build_system=python_pip patches=71de066 arch=darwin-ventura-m2
        ^re2<EMAIL_ADDRESS>build_system=cmake build_type=RelWithDebInfo arch=darwin-ventura-m2
    ^py-h5py<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
        ^py-pkgconfig<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
            ^py-poetry-core<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
    ^py-jax<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
        ^py-jaxlib<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
        ^py-scipy<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
            ^py-build<EMAIL_ADDRESS>build_system=python_pip patches=9a151ac arch=darwin-ventura-m2
                ^py-pep517<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
                ^py-tomli<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
            ^py-meson-python<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
                ^meson<EMAIL_ADDRESS>build_system=python_pip patches=0f0b1bd arch=darwin-ventura-m2
                ^py-pyproject-metadata<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
            ^py-pybind11<EMAIL_ADDRESS>build_system=cmake build_type=RelWithDebInfo generator=ninja arch=darwin-ventura-m2
            ^py-pythran<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
                ^llvm-openmp<EMAIL_ADDRESS>build_system=cmake build_type=RelWithDebInfo generator=make arch=darwin-ventura-m2
                ^py-beniget<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
                ^py-ply<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
    ^py-libclang<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
        ^llvm<EMAIL_ADDRESS>build_system=cmake build_type=Release generator=ninja patches=6379168,d85ef51,f920173 shlib_symbol_version=none targets=none version_suffix=none arch=darwin-ventura-m2
            ^hwloc<EMAIL_ADDRESS>build_system=autotools libs=shared,static arch=darwin-ventura-m2
            ^libedit<EMAIL_ADDRESS>build_system=autotools arch=darwin-ventura-m2
            ^ninja<EMAIL_ADDRESS>build_system=generic arch=darwin-ventura-m2
                ^re2c<EMAIL_ADDRESS>build_system=generic arch=darwin-ventura-m2
            ^perl-data-dumper<EMAIL_ADDRESS>build_system=perl arch=darwin-ventura-m2
    ^py-numpy<EMAIL_ADDRESS>build_system=python_pip patches=873745d arch=darwin-ventura-m2
        ^openblas<EMAIL_ADDRESS>build_system=makefile patches=114f95f,d3d9b15 symbol_suffix=none threads=none arch=darwin-ventura-m2
    ^py-opt-einsum<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
    ^py-packaging<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
        ^py-flit-core<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
    ^py-pip<EMAIL_ADDRESS>build_system=generic arch=darwin-ventura-m2
    ^py-protobuf<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
    ^py-requests<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
        ^py-certifi<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
        ^py-charset-normalizer<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
        ^py-idna<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
        ^py-urllib3<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
    ^py-setuptools<EMAIL_ADDRESS>build_system=generic arch=darwin-ventura-m2
    ^py-six<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
    ^py-tensorboard<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
        ^py-google-auth<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
            ^py-cachetools<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
            ^py-pyasn1-modules<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
                ^py-pyasn1<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
            ^py-rsa<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
        ^py-google-auth-oauthlib<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
            ^py-requests-oauthlib<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
                ^py-oauthlib<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
        ^py-markdown<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
        ^py-tensorboard-data-server<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
            ^rust<EMAIL_ADDRESS>build_system=generic extra_targets=none arch=darwin-ventura-m2
                ^libgit2<EMAIL_ADDRESS>build_system=cmake build_type=RelWithDebInfo https=system arch=darwin-ventura-m2
                    ^pcre<EMAIL_ADDRESS>build_system=autotools arch=darwin-ventura-m2
                ^libssh2<EMAIL_ADDRESS>build_system=cmake build_type=RelWithDebInfo crypto=openssl arch=darwin-ventura-m2
        ^py-tensorboard-plugin-wit<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
        ^py-werkzeug<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
            ^py-markupsafe<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
    ^py-termcolor<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
    ^py-typing-extensions<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
    ^py-wheel<EMAIL_ADDRESS>build_system=generic arch=darwin-ventura-m2
    ^py-wrapt<EMAIL_ADDRESS>build_system=python_pip arch=darwin-ventura-m2
    ^python<EMAIL_ADDRESS>build_system=generic patches=0d98e93,7d40923,f2fd060 arch=darwin-ventura-m2
        ^apple-libuuid<EMAIL_ADDRESS>build_system=bundle arch=darwin-ventura-m2
        ^bzip2<EMAIL_ADDRESS>build_system=generic arch=darwin-ventura-m2
            ^diffutils<EMAIL_ADDRESS>build_system=autotools arch=darwin-ventura-m2
        ^expat<EMAIL_ADDRESS>build_system=autotools arch=darwin-ventura-m2
        ^gdbm<EMAIL_ADDRESS>build_system=autotools arch=darwin-ventura-m2
        ^gettext<EMAIL_ADDRESS>build_system=autotools arch=darwin-ventura-m2
            ^libiconv<EMAIL_ADDRESS>build_system=autotools libs=shared,static arch=darwin-ventura-m2
            ^libxml2<EMAIL_ADDRESS>build_system=autotools arch=darwin-ventura-m2
            ^tar<EMAIL_ADDRESS>build_system=autotools zip=pigz arch=darwin-ventura-m2
                ^pigz<EMAIL_ADDRESS>build_system=makefile arch=darwin-ventura-m2
                ^zstd<EMAIL_ADDRESS>build_system=makefile compression=none libs=shared,static arch=darwin-ventura-m2
        ^libffi<EMAIL_ADDRESS>build_system=autotools arch=darwin-ventura-m2
        ^libxcrypt<EMAIL_ADDRESS>build_system=autotools arch=darwin-ventura-m2
        ^ncurses<EMAIL_ADDRESS>abi=none build_system=autotools arch=darwin-ventura-m2
        ^readline<EMAIL_ADDRESS>build_system=autotools patches=bbf97f1 arch=darwin-ventura-m2
        ^sqlite<EMAIL_ADDRESS>build_system=autotools arch=darwin-ventura-m2
        ^xz<EMAIL_ADDRESS>build_system=autotools libs=shared,static arch=darwin-ventura-m2
    ^swig<EMAIL_ADDRESS>build_system=autotools arch=darwin-ventura-m2
        ^automake<EMAIL_ADDRESS>build_system=autotools arch=darwin-ventura-m2
            ^autoconf<EMAIL_ADDRESS>build_system=autotools patches=35c4492,7793209,a49dd5b arch=darwin-ventura-m2
                ^m4<EMAIL_ADDRESS>build_system=autotools patches=9dc5fbd,bfdffa7 arch=darwin-ventura-m2
                    ^libsigsegv<EMAIL_ADDRESS>build_system=autotools arch=darwin-ventura-m2
        ^gnuconfig<EMAIL_ADDRESS>build_system=generic arch=darwin-ventura-m2
        ^pcre2<EMAIL_ADDRESS>build_system=autotools arch=darwin-ventura-m2

Build logs:

spack-build-out.txt
spack-build-env-mods.txt

@aweits is also reporting the above protobuf issue on Linux, so that specific issue isn't specific to Apple Silicon. But once we solve that, I imagine we'll be back to the original Apple Silicon issue.
P.S. The specific line of code giving us trouble was added by @vam-google in https://github.com/tensorflow/tensorflow/commit/84f40925e929d05e72ab9234e53c729224e3af38, maybe they can comment.

Can you please verify that the actual used protobuf version in bazel is 3.21.x? Note, protobuf has many different occurrences in the build and has a confusing versioning model (it is a very long story why).
Basically, protoc (protobuf compiler) used for build is 3.21.9, which corresponds to protobuf runtime (pip python package) 4.21.9. Note, there is no 4.x version for protoc, so  you using protobuf 4.21.7 suggests me that it points to the pip package. The error message you see (no such target '@com_google_protobuf//:well_known_types_py_pb2_genproto') is comming from protoc part, and the fact that this target is missing should mean that you are depending on an older version.
The simples way to check the actually resolved version of protoc in your build would be:
bazel run @com_google_protobuf//:protoc -- --version

Running:
$ bazel run @com_google_protobuf//:protoc -- --version

gives:
libprotoc 3.21.12

This matches the protobuf 3.21.12 (C++) and 4.21.7 (Python) libraries I was expecting.

Nit: Ideally the major and incremental versions should match (3.21.12 coresponds to 4.21.12). I don't think that causes your problem though.
In that case can you build just @com_google_protobuf//:well_known_types_py_pb2_genproto?
bazel build @com_google_protobuf//:well_known_types_py_pb2_genproto

It must exist, and your error message says it does not. For what it worth, TF builds uses 3.21.9 but again, I do not anticipate differences like that between 3.21.9 and 3.21.12.
Also, can you please check what's inside /private/var/folders/jv/cgkfvslj6nq1l7cw0c8c_8gm0000gn/T/spackzlw44jee/73416f5c6b515a686e32ac2e3981f9d3/external/com_google_protobuf/version.json? (the actual path may be different if you rebuilt your project (different hashes for the cache path).
For example in my build the file looks like the following:
{
    "21.x": {
        "protoc_version": "21.9",
        "lts": false,
        "date": "2022-10-26",
        "languages": {
            "cpp": "3.21.9",
            "csharp": "3.21.9",
            "java": "3.21.9",
            "javascript": "3.21.9",
            "objectivec": "3.21.9",
            "php": "3.21.9",
            "python": "4.21.9",
            "ruby": "3.21.9"
        }
    }
}

Built with protobuf 4.21.9 (Python) and 3.21.9 (C++). Running:
$ bazel build @com_google_protobuf//:well_known_types_py_pb2_genproto

gives the same error:
WARNING: Download from https://storage.googleapis.com/mirror.tensorflow.org/github.com/tensorflow/runtime/archive/91d765cad5599f9710973d3e34d4dc22583e2e79.tar.gz failed: class java.io.FileNotFoundException GET returned 404 Not Found
WARNING: Download from https://storage.googleapis.com/mirror.tensorflow.org/github.com/llvm/llvm-project/archive/10939d1d580b9d3c9c2f3539c6bdb39f408179c0.tar.gz failed: class java.io.FileNotFoundException GET returned 404 Not Found
ERROR: Skipping '@com_google_protobuf//:well_known_types_py_pb2_genproto': no such target '@com_google_protobuf//:well_known_types_py_pb2_genproto': target 'well_known_types_py_pb2_genproto' not declared in package '' defined by /private/var/folders/jv/cgkfvslj6nq1l7cw0c8c_8gm0000gn/T/spackugzi7i1y/_bazel_Adam/f4163c14beee47247db8eb86c7c4a797/external/com_google_protobuf/BUILD.bazel
WARNING: Target pattern parsing failed.
ERROR: no such target '@com_google_protobuf//:well_known_types_py_pb2_genproto': target 'well_known_types_py_pb2_genproto' not declared in package '' defined by /private/var/folders/jv/cgkfvslj6nq1l7cw0c8c_8gm0000gn/T/spackugzi7i1y/_bazel_Adam/f4163c14beee47247db8eb86c7c4a797/external/com_google_protobuf/BUILD.bazel

I could not find any version.info file anywhere recursively in /private/var/folders/jv/cgkfvslj6nq1l7cw0c8c_8gm0000gn/T/spackugzi7i1y/_bazel_Adam/f4163c14beee47247db8eb86c7c4a797.

version.info or version.json?

version.json file should be in the same directory as the external/com_google_protobuf/BUILD.bazel build file it complains about in the error message

Sorry, I meant version.json. The directory in question does not contain this file:
$ ls -l /private/var/folders/jv/cgkfvslj6nq1l7cw0c8c_8gm0000gn/T/spackugzi7i1y/_bazel_Adam/f4163c14beee47247db8eb86c7c4a797/external/com_google_protobuf
total 8
lrwxrwxr-x  1 Adam  staff  187 Mar 30 15:56 BUILD.bazel -> /private/var/folders/jv/cgkfvslj6nq1l7cw0c8c_8gm0000gn/T/Adam/spack-stage/spack-stage-py-tensorflow-2.12.0-heku6ahgdh774vbppjo7vwidgaeszuax/spack-src/third_party/systemlibs/protobuf.BUILD
-rw-rw-r--  1 Adam  staff  120 Mar 30 15:56 WORKSPACE
lrwxrwxr-x  1 Adam  staff  185 Mar 30 15:56 protobuf.bzl -> /private/var/folders/jv/cgkfvslj6nq1l7cw0c8c_8gm0000gn/T/Adam/spack-stage/spack-stage-py-tensorflow-2.12.0-heku6ahgdh774vbppjo7vwidgaeszuax/spack-src/third_party/systemlibs/protobuf.bzl
lrwxrwxr-x  1 Adam  staff  190 Mar 30 15:56 protobuf_deps.bzl -> /private/var/folders/jv/cgkfvslj6nq1l7cw0c8c_8gm0000gn/T/Adam/spack-stage/spack-stage-py-tensorflow-2.12.0-heku6ahgdh774vbppjo7vwidgaeszuax/spack-src/third_party/systemlibs/protobuf_deps.bzl

At the moment, I'm just installing the auto-generated tarball from GitHub. Should I instead be checking out the repo and any submodules with git, or does that not matter?

It should be pulled similarly to how TF itself does it: https://github.com/tensorflow/tensorflow/blob/master/tensorflow/workspace2.bzl#L455
The patch applied is for python 3.11 support (so it should work on 3.10 python without the patch. tf_http_archive is just a wrapper around http_archive() with a tf mirror for dependencies, so is also optional. system_build_file - that is a legacy irrelevant thing (so does not matter here).

I tried letting bazel download and install its own protobuf during the TF install but that didn't work either. Same error msg as before.

Bazel does not install protobuf python runtime dependency (if we are talking about protobuf pip package, and which is the one which is supposed to be >= 3.20.3, e.g. this one: https://pypi.org/project/protobuf/4.21.9/). The build just assumes that it is already installed. Our CI makes sure that all the python packages are-preinstalled in the build environment before the build even starts.
On the other hand, bazel is responsible for downloading protoc (i.e. generaiton-time dependency on protobuf). That one must come from bazel (the way I described in my previous comment). The build does not really have a chance to work otherwise. So i'm confused.
What exactly is your build environment? How exactly is protoc and protobuf pypi package are supplied to your build environment? If inside your bazel cache directory (external/com_google_protobuf) there are only a few files, then something is fundamentally wrong with your setup. This is how that cached dir supposed to look like:
/.cache/bazel/_bazel_vam/820373883812497f5045034c381b61a5/external/com_google_protobuf$ ls
appveyor.bat                     conformance                   java                  Protobuf-C++.podspec  SECURITY.md
appveyor.yml                     CONTRIBUTING.md               kokoro                protobuf_deps.bzl     src
autogen.sh                       CONTRIBUTORS.txt              LICENSE               protobuf-lite.pc.in   tests.sh
benchmarks                       csharp                        m4                    protobuf.pc.in        third_party
BUILD.bazel                      docs                          Makefile.am           Protobuf.podspec      toolchain
build_defs                       editors                       maven_install.json    protobuf_release.bzl  update_compatibility_version.py
build_files_updated_unittest.sh  examples                      objectivec            protobuf_version.bzl  update_file_lists.sh
CHANGES.txt                      fix_permissions.sh            php                   protoc-artifacts      update_version.py
cmake                            generate_changelog.py         pkg                   python                util
CMakeLists.txt                   generate_descriptor_proto.sh  post_process_dist.sh  README.md             version.json
configure.ac                     global.json                   protobuf.bzl          ruby                  WORKSPACE

Please do not try to build it by providing protoc in some custom way, as it will most likely give you a lot of frustration, and even if you manage to build it that way, it will super likely break again on any significant update on TF/proto side anyways.

Progress! I started removing components from our build system one by one and discovered a:
export TF_SYSTEM_LIBS=com_google_protobuf

environment variable that was the culprit! This was introduced way back in https://github.com/spack/spack/pull/16258 in order to allow us to build against externally installed protobuf to solve a different issue with horovod. Removing it probably breaks horovod, but let's ignore that for now. This gets me to a new error:
clang++: error: the clang compiler does not support '-mcpu=vortex'
Error in child process '/usr/bin/xcrun'. 1
ERROR: /private/var/folders/jv/cgkfvslj6nq1l7cw0c8c_8gm0000gn/T/spacka37ntez7/b3f2104ee17a1c25dcbbad690f324b3a/external/flatbuffers/src/BUILD.bazel:53:11: Compiling src/bfbs_gen_lua.cpp failed: (Aborted): wrapped_clang_pp failed: error executing command

Full build log: spack-build-out.txt

What exactly is your build environment?

I'm a developer for the Spack package manager. We have a rather complex build recipe for TF and its dependencies. In https://github.com/spack/spack/pull/36263, I'm attempting to update this build recipe with the latest versions of TF. That's when we encountered this issue.
I realize that your team might not be interested in supporting "yet another package manager", but Spack is pretty much the de facto package manager in use at every national lab and HPC center around the world. We have a lot of unique needs (aarch64 and ppc64le support, air-gapped networks that prevent downloading dependencies, security requirements, etc.) that make our build recipes quite complex. If anyone from the build team would be willing to help us maintain these recipes we would be eternally grateful.

This bug needs to change its name. It is formulated as a generic build issue on Apple M1/M2 architecture, when it turns out to be a build issue in a completely custom environment for an independent (Spack) product. To be completely honest, this bug needs to be in Spack's repository, not TF repository.
I do understand and can relate to the importance of Spack and you trying to make new TF work there. It is also beneficial to TF as a project to be available in as many places as possible, so thank you for doing it. The problem for us is that we don't have enough resources to properly support even the platforms that Google officially declares to support.
For the current clang error you have - the message seems to be quite self explanatory (not the case for most build errors we get here...). I don't know where exactly that option comes from, but I would search for it in both TF and your custom env. Also please make sure that the version of clang  you are using is a correct one. Unfortunately I can't suggest much here as Mac is literally the platform I know the least about (never even owned a single Apple product in my entire life).

@alalazo is -mcpu=vortex something Spack's compiler wrappers might be injecting? I see no mention of vortex in either TF or in our build recipe.
I was hoping to frame this issue in a generic "I'm having trouble building TF from source" kind of way. If there is documentation for the recommended way to build TF from source on macOS I'm happy to follow that outside of Spack and see if I hit the same issue. I can handle any of the intricacies of Spack if I can manage to get TF to build from source outside of Spack.

Hey! Also interested in this issue. It turns out that no pre-built wheel is available for macos with arm64 right now on PyPI: https://pypi.org/project/tensorflow/#files
Do you know if the CI for macos under arm64 is running?

@adamjstewart Yes, unfortunately. This is going to change soon, but to give some context:

We added the flag here https://github.com/archspec/archspec-json/pull/55#issuecomment-1276552320, when adding initial support for M2
The flag as been reported wrong later, see https://github.com/spack/spack/issues/36481
This will be fixed soon in archspec and ported to Spack in develop and v0.19.3

It seems that people reporting -mcpu=vortex and -mcpu=cyclone etc. are using clang from homebrew, while latest Apple-Clang is moving towards the "saner" -mcpu=apple-m2.

Also, this issue should be specific with Apple M2. For Apple M1 the flag has been stable since a while -mcpu=apple-m1.

Thanks for the fix @alalazo!
This gets me further through the build before a new failure:
ERROR: /private/var/folders/jv/cgkfvslj6nq1l7cw0c8c_8gm0000gn/T/Adam/spack-stage/spack-stage-py-tensorflow-2.12.0-xbepxtkd5esfwlvls5mddyunn2idudky/spack-src/tensorflow/compiler/xla/BUILD:92:17: Action tensorflow/compiler/xla/xla.grpc.pb.h failed: (Exit 1): protoc failed: error executing command
...
google/protobuf/any.proto: File not found.
tensorflow/compiler/xla/xla.proto:20:1: Import "google/protobuf/any.proto" was not found or had errors.
tensorflow/compiler/xla/xla.proto:26:12: "google.protobuf.Any" is not defined.
Target //tensorflow/tools/pip_package:build_pip_package failed to build
ERROR: /private/var/folders/jv/cgkfvslj6nq1l7cw0c8c_8gm0000gn/T/Adam/spack-stage/spack-stage-py-tensorflow-2.12.0-xbepxtkd5esfwlvls5mddyunn2idudky/spack-src/tensorflow/compiler/xla/BUILD:92:17 Middleman _middlemen/_S_Stensorflow_Scompiler_Sxla_Cxla_Ucc_Ugrpc_Uproto-BazelCppSemantics_build_arch_darwin_arm64-opt failed: (Exit 1): protoc failed: error executing command

Full build log is too large to upload here.

We managed to make it through the protobuf issues, but now I'm back to the issue from #57631:
ERROR: /private/var/folders/jv/cgkfvslj6nq1l7cw0c8c_8gm0000gn/T/spacklc4h4zma/90fe4a2f1b4fd535211654a91d17d5e2/external/llvm-project/llvm/BUILD.bazel:593:11: Compiling llvm/utils/TableGen/RegisterInfoEmitter.cpp failed: Exec failed due to IOException: xcrun failed with code 1.
This most likely indicates that SDK version [13.3.1] for platform [MacOSX] is unsupported for the target version of xcode.
Process exited with status 1
stdout: stderr: 2023-04-19 10:39:59.917 xcodebuild[14810:362667] Writing error result bundle to /var/folders/jv/cgkfvslj6nq1l7cw0c8c_8gm0000gn/T/ResultBundle_2023-19-04_10-39-0059.xcresult
xcodebuild: error: SDK "macosx13.3.1" cannot be located.
2023-04-19 10:40:01.387 xcodebuild[14922:362903] Writing error result bundle to /var/folders/jv/cgkfvslj6nq1l7cw0c8c_8gm0000gn/T/ResultBundle_2023-19-04_10-40-0001.xcresult
xcodebuild: error: SDK "macosx13.3.1" cannot be located.
xcrun: error: Failed to open property list '/private/var/folders/jv/cgkfvslj6nq1l7cw0c8c_8gm0000gn/T/Adam/spack-stage/spack-stage-py-tensorflow-2.12.0-hkcif5grjoyeoreujte6znlz3so5ysj5/spack-src/macosx13.3.1/SDKSettings.plist'
2023-04-19 10:40:02.854 xcodebuild[14923:362916] Writing error result bundle to /var/folders/jv/cgkfvslj6nq1l7cw0c8c_8gm0000gn/T/ResultBundle_2023-19-04_10-40-0002.xcresult
xcodebuild: error: SDK "macosx13.3.1" cannot be located.
xcrun: error: unable to lookup item 'Path' in SDK 'macosx13.3.1'

Not sure if this is relevant, but I have the following set:
export MACOSX_DEPLOYMENT_TARGET=13.0

Managed to get 2.13.0 to build from source with the help of https://github.com/tensorflow/tensorflow/issues/60179#issuecomment-1491238631. I'll try to get the Spack recipe working, but this is no longer a TF issue. Thanks for the help everyone!


connectivity/check: bump connectivity check images for arm64 support

Follows cilium/cilium#15894
Also define the image name/version in package defaults.

being addressed in https://github.com/cilium/cilium-cli/pull/193

Oops, didn't noticed #193 which already does this. Closing.


Set type on issue template

sideport of https://github.com/jenkinsci/.github/pull/141
Testing done

Submitter checklist

[ ] Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
[ ] Ensure that the pull request title represents the desired changelog entry
[ ] Please describe what you did
[ ] Link to relevant issues in GitHub or Jira
[ ] Link to relevant pull requests, esp. upstream and downstream changes
[ ] Ensure you have provided tests - that demonstrates feature works or fixes the issue

Could you also copy the feature request form?
There were no forms at all, so org-level ones were used. The bug form didn't make sense because of too many Jenkins details, which are not applicable to the IntelliJ plugin. The community contributed a simplified bug form, but that meant all the other forms were gone. I though I quickly add a feature request one myself, but I never did 😅


Add nodeSelector to Trivy deployment

The Trivy deployment template within the kube-enforcer templates lacks a nodeSelector field. This poses a problem, as we're not able to specify which node the trivy-operator should be scheduled on.
This can be fixed by adding the following:
 kube-enforcer/values.yaml
trivy:
  nodeSelector: {}

kube-enforcer/templates/trivy-deployment.yaml
{{- with .Values.trivy.nodeSelector }}
nodeSelector:
    {{ toYaml . | nindent 8 }}
{{- end }}

Opened PR: #786

Rendering the template locally confirmed the nodeSelector being set as expected.


Trouble pairing

Here's my test program directly following the README:
import btcpay.crypto
from btcpay import BTCPayClient

URL = "https://test.buidlbootcamp.com"

privkey = btcpay.crypto.generate_privkey()
client = BTCPayClient(
    host=URL,
    pem=privkey,
)

pairing_code = "SECRET!!!"
tokens = client.pair_client(pairing_code)

print(client.get_rates())

I encounter this exception:
$ python script.py
Traceback (most recent call last):
  File "script.py", line 13, in <module>
    tokens = client.pair_client(pairing_code)
  File "/home/justin/dev/buidl-treasury/venv/lib/python3.7/site-packages/btcpay/client.py", line 97, in pair_client
    data = self._unsigned_request('/tokens', payload)
  File "/home/justin/dev/buidl-treasury/venv/lib/python3.7/site-packages/btcpay/client.py", line 65, in _unsigned_request
    r.raise_for_status()
  File "/home/justin/dev/buidl-treasury/venv/lib/python3.7/site-packages/requests/models.py", line 939, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 400 Client Error: Bad Request for url: https://test.buidlbootcamp.com/tokens

This server is on testnet FWIW

Now I generated a new pairing code and it looks like the pairing succeeded, but get_rates() failed ...
Traceback (most recent call last):
  File "script.py", line 15, in <module>
    print(client.get_rates())
  File "/home/justin/dev/buidl-treasury/venv/lib/python3.7/site-packages/btcpay/client.py", line 74, in get_rates
    return self._signed_get_request('/rates/', params=params)
  File "/home/justin/dev/buidl-treasury/venv/lib/python3.7/site-packages/btcpay/client.py", line 37, in _signed_get_request
    token = token or list(self.tokens.values())[0]
IndexError: list index out of range

I see the problem

ah for the get_rates it is a bug I fixed tomorrow, can test.buidlbootcamp.com update their BTCPay?

Yes it can. I just set it up today and can change anything.

OK I did a successful pairing. I didn't understand and was trying to re-pair every time the script ran. Now I just have the {'merchant': '...'} tokens dictionary hard-coded into my script.

I successfully executed BTCPayClient.get_rates and BTCPayClient.create_invoice.
My issue was just that I didn't understand the pairing model -- that the private key we were generating was to correspond with the "pairing code" generated on the BTCPayServer instance ...
Sorry to bother you!


Applicability beyond underwater scenarios

In principle, it looks like the plume simulator should be applicable to also for simulation of plumes in air and with air and ground robots carrying sensors. Are there any blockers for such scenarios or should this work out of the box with some parameter changes?

Hi, sorry for the long delay. I think the box parameter should be enough, but I have not tried it yet. I can check if I hard coded the upper surface somewhere.


proposal: x/term: Interruptable ReadLine

Proposal Details
Reading a line from a terminal can only be interrupted by the user pressing CTRL+D or CTRL+C. API does not allow the reading to be interrupted via other means. This creates an impossible scenario if other goroutine should be the source of interrupt.
Closing an underlying file (os.Stdin) does not work as expected. A user is still required to touch at least a single key for the closure be detected. And, of course, closing stdin in itself is problematic in more complex programs.
I would like to propose adding a new method Terminal.Close which would terminate blocking ReadLine call, or adding ReadLineWithContext to achieve the same just using context.Context.
package main

import (
	"fmt"
	xterm "golang.org/x/term"
	"io"
	"os"
	"time"
)

var fd = int(os.Stdin.Fd())

func main() {
	origState, err := xterm.GetState(fd)
	if err != nil {
		panic(err)
	}
	defer xterm.Restore(fd, origState)

	term := xterm.NewTerminal(os.Stdin, "> ")

	go func(){
		<-time.After(10*time.Second)
		// Terminate ReadLine here...
	}()

	for {
		oldState, err := xterm.MakeRaw(fd)
		if err != nil {
			panic(err)
		}

		line, err := term.ReadLine()
		if err != nil {
			if err != io.EOF {
				panic(err)
			}
			return
		}

		err = xterm.Restore(fd, oldState)
		if err != nil {
			panic(err)
		}

		fmt.Printf("%q\n", line)
	}
}

Related Issues and Documentation

x/term: ReadKey() interface #13299
proposal: os: (*File).SetReadDeadline and (*File).SetWriteDeadline /case: serial interface/ #22100 (closed)
x/term: Cannot differentiate a CTRL+C from CTRL+D #62385

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

I don't think this is possible by default, as the function would still be blocked on the read without a way to interrupt it properly. see #24842 and #26579 for related workarounds.


es6 stage?

I'm getting the following:
Error in ./common/form
Module build failed: SyntaxError: Unexpected token, expected { (1:7)

> 1 | export Input from './Input';
    |        ^
  2 | export InputGroupButton from './InputGroupButton';
  3 | export Select from './Select';
  4 | export Select2 from './Select2';

I'm wondering if this has something to do with the default es6 stage next.js uses.  Is there a way for us to change this?  Or am I way off?  Thanks in advance.

For future posterity:
Turns out you can simply add a custom .babelrc file at the root of the project.
Here is what worked for me:
{
  "presets": ["es2015", "stage-0", "react"],
  "plugins": [
    "transform-async-to-generator",
    "transform-object-rest-spread",
    "transform-class-properties",
    "transform-runtime"
  ]
}

@webular did you have to install those extra dependencies yourself? I assume that NextJS already has some of those presets.

@adrianmcli you need to include the next/babel preset too. Otherwise functionality might break.

@adrianmcli Yes I did.
npm install --save-dev babel-preset-stage-0

update - use this instead:
{
  "presets": [
    "next/babel",
    "stage-0"
  ]
}