SSH over OpenVPN connection fails when Docker Swarm is running

Description
Connection timed out when I ssh into my AWS instance through OpenVPN connection after docker swarm init.
Steps to reproduce the issue:

Launch and install Docker onto 2 AWS instances on the same network (<IP_ADDRESS> and <IP_ADDRESS>).
Run OpenVPN (https://github.com/kylemanna/docker-openvpn) on instance A (<IP_ADDRESS>).
Run docker swarm init on instance B (<IP_ADDRESS>).
Connect to AWS network through OpenVPN of instance A (<IP_ADDRESS>).
Run ssh -i ~/.ssh/key.pem<EMAIL_ADDRESS>from my local machine.

Describe the results you received:
ssh: connect to host <IP_ADDRESS> port 22: Operation timed out
Describe the results you expected:
I expected ssh through OpenVPN to login successfully into instance B (<IP_ADDRESS>).
Last login: Tue Mar 21 15:04:40 2017 from ip-10-0-0-1.ap-southeast-1.compute.internal
ubuntu@ip-10-0-0-2:~$

Additional information you deem important (e.g. issue happens only occasionally):
Issue occurs even after ports described in https://docs.docker.com/engine/swarm/swarm-tutorial/#open-protocols-and-ports-between-the-hosts are opened. Able to ssh through OpenVPN into instance B when Docker Swarm is not running on instance B. Able to ssh through AWS Internet Gateway (if configured) into instance B when Docker Swarm is running on instance B. Without OpenVPN, still unable to ssh (connection timed out) into instance B through instance A (ssh into instance A through Internet Gateway first) when Docker Swarm is running on instance B.
OpenVPN configuration (openvpn.conf):
server <IP_ADDRESS> <IP_ADDRESS>
verb 3
key /etc/openvpn/pki/private/<masked public IP>.key
ca /etc/openvpn/pki/ca.crt
cert /etc/openvpn/pki/issued/<masked public IP>.crt
dh /etc/openvpn/pki/dh.pem
tls-auth /etc/openvpn/pki/ta.key
key-direction 0
keepalive 10 60
persist-key
persist-tun

proto udp
# Rely on Docker to do port mapping, internally always 1194
port 1194
dev tun0
status /tmp/openvpn-status.log

user nobody
group nogroup

### Route Configurations Below
route <IP_ADDRESS> <IP_ADDRESS>

### Push Configurations Below
push block-outside-dns
push dhcp-option DNS <IP_ADDRESS>
push dhcp-option DNS <IP_ADDRESS>

### Extra Configurations Below

Output of docker version:
ubuntu@ip-10-0-0-2:~$ docker version
Client:
 Version:      17.03.0-ce
 API version:  1.26
 Go version:   go1.7.5
 Git commit:   60ccb22
 Built:        Thu Feb 23 10:57:47 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.03.0-ce
 API version:  1.26 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   60ccb22
 Built:        Thu Feb 23 10:57:47 2017
 OS/Arch:      linux/amd64
 Experimental: false

Output of docker info:
ubuntu@ip-10-0-0-2:~$ docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 17.03.0-ce
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 0
 Dirperm1 Supported: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: active
 NodeID: mcsklxrf8a1au6jpv1pk3z36e
 Is Manager: true
 ClusterID: iqwn12hqnuey6qs3uh2nkooyf
 Managers: 1
 Nodes: 1
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Number of Old Snapshots to Retain: 0
  Heartbeat Tick: 1
  Election Tick: 3
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
 Node Address: <IP_ADDRESS>
 Manager Addresses:
  <IP_ADDRESS>:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 977c511eda0925a723debdc94d09459af49d082a
runc version: a01dafd48bc1c7cc12bdb01206f9fea7dd6feb70
init version: 949e6fa
Security Options:
 apparmor
Kernel Version: 3.13.0-112-generic
Operating System: Ubuntu 14.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 3.676 GiB
Name: ip-10-254-161-137
ID: J7V7:TEXJ:USIZ:GYII:VFTL:5LKS:7YUM:LEZE:JLJK:FHNZ:QKXJ:2W6T
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Experimental: false
Insecure Registries:
 <IP_ADDRESS>/8
Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):
AWS environment.

Not sure how this is related to Swarm.
Might we be setting some overlay iptables rule, @mavenugo @sanimej @aboch?

Without OpenVPN, this issue (connection timed out) is still occurring when I ssh into instance B through instance A (ssh into instance A through Internet Gateway first) when Docker Swarm is running on instance B.

Hi @joelchen is your issue consistently reproducible?
I tried to reproduce with a couple of vms locally and the ssh for me works between the 2 vms. Is it possible that there is some AWS config that is not allowing the traffic?
Also if you have the issue reproduced, will you be able to run a tcpdump on the sender and receiver side so to confirm that the TCP handshake happens of in case which side is not responding?

@fcrisciani Are your VMs running Ubuntu 14.04? There are too many outputs from tcpdump, how do I spot the TCP handshake?
Here is out put of iptables before docker swarm init:
ubuntu@ip-10-0-0-2:~$ sudo iptables -nvL
Chain INPUT (policy ACCEPT 128 packets, 8239 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 332K   60M DOCKER-ISOLATION  all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0
    0     0 DOCKER-OVERLAY  all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0
    0     0 DOCKER     all  --  *      docker0  <IP_ADDRESS>/0            <IP_ADDRESS>/0
    0     0 ACCEPT     all  --  *      docker0  <IP_ADDRESS>/0            <IP_ADDRESS>/0            ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  docker0 !docker0  <IP_ADDRESS>/0            <IP_ADDRESS>/0
    0     0 ACCEPT     all  --  docker0 docker0  <IP_ADDRESS>/0            <IP_ADDRESS>/0

Chain OUTPUT (policy ACCEPT 92 packets, 9958 bytes)
 pkts bytes target     prot opt in     out     source               destination
89922 8019K DOCKER-OVERLAY  all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0

Chain DOCKER (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain DOCKER-ISOLATION (1 references)
 pkts bytes target     prot opt in     out     source               destination
3380K  613M RETURN     all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0

Chain DOCKER-OVERLAY (2 references)
 pkts bytes target     prot opt in     out     source               destination
 137K   13M RETURN     all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0

Here is out put of iptables after docker swarm init:
ubuntu@ip-10-0-0-2:~$ sudo iptables -nvL
Chain INPUT (policy ACCEPT 23 packets, 2011 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DOCKER-ISOLATION  all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0
    0     0 DOCKER     all  --  *      docker_gwbridge  <IP_ADDRESS>/0            <IP_ADDRESS>/0
    0     0 ACCEPT     all  --  *      docker_gwbridge  <IP_ADDRESS>/0            <IP_ADDRESS>/0            ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  docker_gwbridge !docker_gwbridge  <IP_ADDRESS>/0            <IP_ADDRESS>/0
    0     0 DOCKER-OVERLAY  all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0
    0     0 DOCKER     all  --  *      docker0  <IP_ADDRESS>/0            <IP_ADDRESS>/0
    0     0 ACCEPT     all  --  *      docker0  <IP_ADDRESS>/0            <IP_ADDRESS>/0            ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  docker0 !docker0  <IP_ADDRESS>/0            <IP_ADDRESS>/0
    0     0 ACCEPT     all  --  docker0 docker0  <IP_ADDRESS>/0            <IP_ADDRESS>/0
    0     0 DROP       all  --  docker_gwbridge docker_gwbridge  <IP_ADDRESS>/0            <IP_ADDRESS>/0

Chain OUTPUT (policy ACCEPT 18 packets, 1914 bytes)
 pkts bytes target     prot opt in     out     source               destination
   18  1914 DOCKER-OVERLAY  all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0

Chain 9zxr6jkl5b7g (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  ov-001000-9zxr6 *       <IP_ADDRESS>/0            <IP_ADDRESS>/0
    0     0 DROP       all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0

Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination

Chain DOCKER-ISOLATION (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  docker0 docker_gwbridge  <IP_ADDRESS>/0            <IP_ADDRESS>/0
    0     0 DROP       all  --  docker_gwbridge docker0  <IP_ADDRESS>/0            <IP_ADDRESS>/0
3380K  613M RETURN     all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0

Chain DOCKER-OVERLAY (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 9zxr6jkl5b7g  all  --  *      ov-001000-9zxr6  <IP_ADDRESS>/0            <IP_ADDRESS>/0
 137K   13M RETURN     all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0

Upgrading to latest Ubuntu 16.04, ssh through VPN or through another instance works and I am unable to reproduce this issue. Can Docker team fix this issue with Ubuntu 14.04?
Here is output of iptables on Ubuntu 16.04 before docker swarm init:
ubuntu@ip-10-0-0-2:~$ sudo iptables -nvL
Chain INPUT (policy ACCEPT 34 packets, 2319 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DOCKER-ISOLATION  all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0
    0     0 DOCKER     all  --  *      docker0  <IP_ADDRESS>/0            <IP_ADDRESS>/0
    0     0 ACCEPT     all  --  *      docker0  <IP_ADDRESS>/0            <IP_ADDRESS>/0            ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  docker0 !docker0  <IP_ADDRESS>/0            <IP_ADDRESS>/0
    0     0 ACCEPT     all  --  docker0 docker0  <IP_ADDRESS>/0            <IP_ADDRESS>/0

Chain OUTPUT (policy ACCEPT 27 packets, 2910 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain DOCKER (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain DOCKER-ISOLATION (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RETURN     all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0

Here is output of iptables on Ubuntu 16.04 after docker swarm init:
ubuntu@ip-10-0-0-2:~$ sudo iptables -nvL
Chain INPUT (policy ACCEPT 8 packets, 703 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DOCKER-ISOLATION  all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0
    0     0 DOCKER     all  --  *      docker_gwbridge  <IP_ADDRESS>/0            <IP_ADDRESS>/0
    0     0 ACCEPT     all  --  *      docker_gwbridge  <IP_ADDRESS>/0            <IP_ADDRESS>/0            ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  docker_gwbridge !docker_gwbridge  <IP_ADDRESS>/0            <IP_ADDRESS>/0
    0     0 DOCKER     all  --  *      docker0  <IP_ADDRESS>/0            <IP_ADDRESS>/0
    0     0 ACCEPT     all  --  *      docker0  <IP_ADDRESS>/0            <IP_ADDRESS>/0            ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  docker0 !docker0  <IP_ADDRESS>/0            <IP_ADDRESS>/0
    0     0 ACCEPT     all  --  docker0 docker0  <IP_ADDRESS>/0            <IP_ADDRESS>/0
    0     0 DROP       all  --  docker_gwbridge docker_gwbridge  <IP_ADDRESS>/0            <IP_ADDRESS>/0

Chain OUTPUT (policy ACCEPT 5 packets, 510 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination

Chain DOCKER-ISOLATION (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  docker0 docker_gwbridge  <IP_ADDRESS>/0            <IP_ADDRESS>/0
    0     0 DROP       all  --  docker_gwbridge docker0  <IP_ADDRESS>/0            <IP_ADDRESS>/0
    0     0 RETURN     all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0

@joelchen I tried to spawn an Ubuntu 14.04 on my laptop and after the docker swarm init looks like I'm still able to ssh to it.
Also the iptables output that you posted are looking good, don't see any DROP counter positive, meaning that right now there is no iptables rule preventing the ssh traffic.
Following I'm adding the tcpdump command to use to see if the packets are actually being sent and received on the interfaces.
for the tcpdump command you can use the following, launch both sides before attempting a new ssh connection. (consider that if you have one already active between the 2 vms the output will be pretty busy, so check that before starting the command is launch but no output is generated):
Source VM (machine that start the ssh command):
sudo tcpdump -eni <interface name, usually eth0> port 22 and host
The output that we want to see on this VM if the TCP connection is established is the following (these are the very first 3 lines printed by the command):
14:56:29.096662 08:00:27:f9:f6:b5 > 08:00:27:f9:f6:2f, ethertype IPv4 (0x0800), length 78: <IP_ADDRESS>.50826 > <IP_ADDRESS>.22: Flags [S], seq<PHONE_NUMBER>, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 402839027 ecr 0,sackOK,eol], length 0
14:56:29.096967 08:00:27:f9:f6:2f > 08:00:27:f9:f6:b5, ethertype IPv4 (0x0800), length 74: <IP_ADDRESS>.22 > <IP_ADDRESS>.50826: Flags [S.], seq 10832244, ack<PHONE_NUMBER>, win 28960, options [mss 1460,sackOK,TS val 247864 ecr 402839027,nop,wscale 7], length 0
14:56:29.097036 08:00:27:f9:f6:b5 > 08:00:27:f9:f6:2f, ethertype IPv4 (0x0800), length 66: <IP_ADDRESS>.50826 > <IP_ADDRESS>.22: Flags [.], ack 1, win 4117, options [nop,nop,TS val 402839027 ecr 247864], length 0
[...] lot of other stuff if the connection goes through, we can ignore them for the moment
Destination VM:
sudo tcpdump -eni <interface name, usually eth0> port 22 and host
Also here the expected output is:
15:05:01.476726 08:00:27:f9:f6:b5 > 08:00:27:f9:f6:2f, ethertype IPv4 (0x0800), length 78: <IP_ADDRESS>.50909 > <IP_ADDRESS>.22: Flags [S], seq 384006490, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 403348531 ecr 0,sackOK,eol], length 0
15:05:01.476807 08:00:27:f9:f6:2f > 08:00:27:f9:f6:b5, ethertype IPv4 (0x0800), length 74: <IP_ADDRESS>.22 > <IP_ADDRESS>.50909: Flags [S.], seq<PHONE_NUMBER>, ack 384006491, win 28960, options [mss 1460,sackOK,TS val 375966 ecr 403348531,nop,wscale 7], length 0
15:05:01.476948 08:00:27:f9:f6:b5 > 08:00:27:f9:f6:2f, ethertype IPv4 (0x0800), length 66: <IP_ADDRESS>.50909 > <IP_ADDRESS>.22: Flags [.], ack 1, win 4117, options [nop,nop,TS val 403348531 ecr 375966], length 0
[...] other lines that we can ignore

From instance B (Ubuntu 14.04) running Docker Swarm:
06:03:30.090998 IP <IP_ADDRESS>.41466 > <IP_ADDRESS>.22: Flags [S], seq 784855174, win 26883, options [mss 8961,sackOK,TS val 74728763 ecr 0,nop,wscale 7], length 0
06:03:32.095177 IP <IP_ADDRESS>.41466 > <IP_ADDRESS>.22: Flags [S], seq 784855174, win 26883, options [mss 8961,sackOK,TS val 74729264 ecr 0,nop,wscale 7], length 0
06:03:35.983839 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 42
06:03:35.983863 ARP, Reply <IP_ADDRESS> is-at 02:3d:5b:51:cb:ad, length 28

From instance A (Ubuntu 14.04/16.04) trying to ssh into instance B (Ubuntu 14.04):
05:56:07.117611 IP <IP_ADDRESS>.41464 > <IP_ADDRESS>.22: Flags [S], seq<PHONE_NUMBER>, win 26883, options [mss 8961,sackOK,TS val 74624038 ecr 0,nop,wscale 7], length 0
05:56:08.117461 IP <IP_ADDRESS>.41464 > <IP_ADDRESS>.22: Flags [S], seq<PHONE_NUMBER>, win 26883, options [mss 8961,sackOK,TS val 74624288 ecr 0,nop,wscale 7], length 0
05:56:08.248992 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 42
05:56:08.249011 ARP, Reply <IP_ADDRESS> is-at 02:85:9d:73:f7:f9, length 28

Hi @joelchen, in kernel 3.13.X, that you are currently using, there are some limitations where the overlay network vxlan interfaces are created in the host namespace.
In this case as you do the docker swarm init the network <IP_ADDRESS>/8 is starting being used by docker.
Try changing the host network that you are using in AWS so that your host interface of the vms that you are using are not anymore on the <IP_ADDRESS>/8. That should solve the problem for you in case of vms with old kernel versions.
Let me know if it works.

@fcrisciani It is actually an instance of VPC with subnet 10.254.XXX.XXX. I replaced it with 10.0.0.X for illustration. Unfortunately, it falls within <IP_ADDRESS>/8 CIDR, and I must use this network for my project.

@joelchen as @fcrisciani explained, the issue is with the 3.13 kernel and the overlapping subnet issue with an overlay network. In swarm-mode, we create a default overlay network named ingress with a subnet of 10.255.x.x/16 and that might interfere with your subnet.
FYI, we added an ability to remove the ingress network via https://github.com/docker/docker/pull/31714 and one can create the ingress network in any other non-conflicting subnet while running in the older kernels.
This feature will be available for 17.05 release and if you are interested in trying it out, pls try a master build.

@mavenugo Nice to know that there is a way to overcome this issue. Can the removal be performed before docker swarm init? If it can only be done after docker swarm init, what happens will be the same, I will be kicked out of the SSH session, and I have to find another way (attaching Internet Gateway) to access the instance to do docker network rm ingress without killing Docker Swarm. If it can be done before docker swarm init, please include it into the upcoming 17.04 release.

@joelchen no. this can be done only after docker swarm init. But once you do that once, it is remembered even after the daemon is restarted.

https://github.com/moby/moby/pull/31714 was merged, and released in 17.05, so I'll go ahead and close this issue.


Daemon memory leak in image load when called from go dockerclient

When using the samalba docker client, loading a large image can cause the daemon in 1.10 to become extremely large.  In my testing, using a 714M image (selenium/standalone-firefox:2.47.1 in my case, but any large image should do) and the following example program, 1.9 stays small (~50-60MB rss) but 1.10 grows to 1.8G
package main

import (
	"fmt"
	"os"
	"github.com/samalba/dockerclient"
)

func main() {
	c, err := dockerclient.NewDockerClient("unix:///var/run/docker.sock", nil)
	if err != nil {
		fmt.Fprintf(os.Stderr, "Failed to connect: %s\n", err)
		os.Exit(1)
	}
	if err := c.LoadImage(os.Stdin); err != nil {
		fmt.Fprintf(os.Stderr, "Failed to send image: %s\n", err)
		os.Exit(1)
	}
	fmt.Fprintf(os.Stderr, "finished the load\n")
}

Loading the same image with the docker CLI doesn't cause the massive memory growth (it stays in the 50-60MB range rss).

If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
For more information about reporting issues, see CONTRIBUTING.md.
You don't have to include this information if this is a feature request
(This is an automated, informational response)

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

hi @dhiltgen  Could you specify what docker CLI do you use to load that image ?
And for  samalba docker client, you got memory grow to 1.8G, How do you get that data ? from top or any linux commands ?

I was testing with a developer build from an engine tree built within the last couple days.
To see the size, top, or ps -eo pid,rss,vsz,sz,args

ping @aaronlehmann @tonistiigi could you have a look at this?

I can reproduce this. The requests look very similar except for some differences in the URI and headers:
Standard client:
POST /v1.22/images/load HTTP/1.1
Host: <IP_ADDRESS>:8080
User-Agent: Docker-Client/1.10.0-dev (linux)
Transfer-Encoding: chunked
Content-Type: text/plain
Accept-Encoding: gzip

samalba dockerclient:
POST /v1.15/images/load HTTP/1.1
Host: <IP_ADDRESS>:8080
User-Agent: Go-http-client/1.1
Transfer-Encoding: chunked
Content-Type: application/json
Accept-Encoding: gzip

I suspect this is related to #18878. Since github.com/samalba/dockerclient incorrectly sets the content type to application/json, the engine is trying to decode the tar stream as JSON.
ping @calavera

Indeed, changing the Content-Type header added by github.com/samalba/dockerclient seems to solve this. But I actually don't think it's #18878, because that's a client side change dealing with the responses from the load endpoint.

Regression should be at #17266 (ping @cpuguy83) . Not sure if there is any point to trying to fix this though because it clearly seems a client bug.

Oh yes, that's probably it.
If the content-type is application/json + debug is enabled we'll dump the body to the logs.

Also likely an issue with authz plugins as well, which forwards the request body to plugins if the content-type is text/plain or application/json.

@dhiltgen You ok with closing this?

Aren't there a lot of clients out there in the wild that use the samalba docker client library?  Clearly we should fix the library to send the expected header but until apps ship a new version, those apps can cause a pretty substantial leak in the daemon.  That seems to me like something we should harden for and fix.

...particularly since this is a regression in 1.10.

@cpuguy83 maybe we could detect the size of the Body and skip logging if it's too big. We wouldn't want to log it anyway if it is more than a couple of KB, even if it is JSON.

@tonistiigi How do you suppose we detect the size? I wouldn't want to rely on the http header since it's technically already wrong.
I'm thinking io.CopyAtLeast, set the size to some max size and if it finishes without getting EOF we don't dump the request.
We do need to handle this with authz plugins as well.

@cpuguy83 bufio.Peek should also work. I think authz isn't that important as this is a new feature that users must start using to be affected.

I can confirm that my test code no longer causes the memory leak with top-of-tree.  Thanks!

@dhiltgen yayyy! thanks for verifying!

@dhiltgen Thanks for finding this!

no prob :-)


remove draft notice

Seeking Brian Lee's permission to remove the draft notice and make this page official.

@leebrian check it out and let me know if you approve

This MR approval serves as division ADI approval for this initial draft. As you develop the project, please keep up with CDC and ID open source practices.


Possible to read from pdf using file.upload?

Is your feature request related to a problem? Please describe.
I would like to be able to upload a txt file or pdf then interact with chatgpt based on that txt or pdf.
Describe the solution you'd like
To be able to upload different file types that are not json.
Describe alternatives you've considered
https://chatpdf.com/
Additional context
It might be better to exit early
https://github.com/alexrudall/ruby-openai/blob/49c08f3fd0906e99ef51f6bbc2cac2c2fc2baa38/lib/openai/files.rb#L12
If the file is not a json or supported file type.

a lot of the lifting for this is copy/paste from
https://github.com/yohasebe/monadic-chat/blob/312c2ccf0de95ce874052879de87bd75846d72db/apps/pdf/pdf_app.rb#L4


list available resources

List available pokemon/items with --list, -l

Available items linked in --help message.


on click outside

when registering the click-outside to a child component:
onClickOutside needs to clean up (un-register from global) when:

the child unmounts
it is being replaced by another handler

that means the child has to have a willUnmount step, and a willReceiveProps state when it handles this kind of thing.
meaning, the subject is not a SFC.

https://github.com/wix/wix-react-tools/blob/master/docs/old/on-click-outside.md

@idoros was assigned after the question of what does "outside" really means arose:
Is it outside any of the children, one of the children, or the bounding box of all the children?

According to the "spec", the listener is checking the component root node against the onClick event target. if the target is not equal to the component root and not contained in it, it is considered "outside".
That means that a click on the actual root or any of its nested DOM is "inside", while the hit area between overflowed children is considered "outside".

is that what you need @giladgrush @tobich  ?

Let's postpone a bit. I don't have the pattern clearly in my mind yet. Will update as soon as I do.

@giladgrush perhaps there are two "forms" of this feature, one is for the root and the other should do something a bit different?
or in a different phrasing: can you think of a real pending use case for onClickOutside that applies on the root only? if so, I can start with that and make any other use-case a different, later issue.

this is a feature that is used by the parent - it adds an onClickOutside property to the component's props.
helpful tool can be a factory that creates handlers for  onClickOutside to put in several children, that only triggers when a click was outside all of them.

seems redundant by using global events directly with a utility

needs further discussion before it is ready for processing


After successfully creating Static Web App, workflow reports an error: "Platform 'dotnet' version '8.0' is unsupported."

Azure DevOps work item: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1885646
TESTCASES AFFECTED
Publish to Azure Static Web Apps
Platform

[x] Windows
[ ] Linux
[ ] Mac

INSTALL STEP

Clean machine: Win11 x64 22h2 ENU

Install Dev17.8 Preview 3, Preview channel

Web workload
Includes SDK 8.0.100-rc.1.23455.8

REPRO STEPS

File > New> Project > Blazor WebAssembly App > Next > .NET 8.0 > Create

Right click Solution > Create Git Repository > GitHub, Verify your GitHub account your GitHub > Create and Push

Right click project > Publish > Azure > Azure Static Web Apps > Click 'Create new', will open portal and then create a Static Web App as follow:

Repository select the repo just created and update the App location to the name of the project that was created

After successful creation, click Go to resource, clicking on the sentence below will open the GitHub

After a while, it will be displayed that the creation of workflow runs failed with error

Click on this workflow file, then click Build and Deploy Job

ACTUAL
It will be displayed that the creation of workflow runs failed with error:
Error: Platform 'dotnet' version '8.0' is unsupported. Supported versions: 3.1.10, 3.1.11, 3.1.12, 3.1.13, 3.1.15, 3.1.17, 3.1.18, 3.1.21, 3.1.23, 3.1.25, 3.1.26, 3.1.28, 3.1.29, 3.1.31, 3.1.32, 6.0.0-preview.1.21102.12, 6.0.0-preview.2.21154.6, 6.0.0-preview.3.21201.4, 6.0.0-preview.4.21253.7, 6.0.0-preview.5.21301.5, 6.0.0-preview.6.21352.12, 6.0.0-preview.7.21377.19, 6.0.0-rc.1.21451.13, 6.0.0-rc.2.21480.5, 6.0.0, 6.0.3, 6.0.5, 6.0.6, 6.0.8, 6.0.9, 6.0.11, 6.0.12, 6.0.13, 6.0.14, 6.0.15, 6.0.16, 6.0.18, 6.0.19, 6.0.20, 6.0.21, 7.0.0-preview.1.22076.8, 7.0.0-preview.5.22301.12, 7.0.0-preview.6.22324.4, 7.0.0-preview.7.22375.6, 7.0.0-rc.1.22426.10, 7.0.0-rc.2.22472.3, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.7, 7.0.8, 7.0.9, 7.0.10, 1.0.16
---End of Oryx build logs---
Oryx has found build steps, but identified unsupported platform versions. Failing build.

EXPECTED
Platform 'dotnet' version '8.0' is supported.

We now have a bug in VS to track this - Bug 1885646: [WebToolsE2E] [SWA] After successfully creating Static Web App, workflow reports an error: "Platform 'dotnet' version '8.0' is unsupported." and Antonio is following up with the Oryx team.

Verify this issue is fixed, so close it.


Fix E2E failure on branching phase

When checking out the project branch, use devel when the status is branch since the branch hasn't been created yet.
Fixes https://github.com/submariner-io/releases/issues/197

Let's close this in favor of #222


[FEATURE]: Implement Empty Test Files

Feature Summary
Implement empty test files.
Additonal tests can be created.
Create additional component tests.
Tests can be implemented one at a time.

Implemented Practice Race page test in #585


New version of grpc go client.

And new option in gRPC options to turn of FailFast.
The automation client can wait until context deadline.
@enisoc

LGTM


Failed to install node version '12.12.0'

[Sorry, I am sure if this is right repo to post this Netlify deployment issue]
- Do you want to request a feature or report a bug?
Bug
- What is the current behavior?
...
2:47:10 PM: Attempting node version '12.12.0' from .nvmrc
2:47:12 PM: Version '12.12.0' not found - try `nvm ls-remote` to browse available versions.
2:47:12 PM: Failed to install node version '12.12.0'
2:47:12 PM: failed during stage 'building site': Build script returned non-zero exit code: 1
2:47:12 PM: Error running command: Build script returned non-zero exit code: 1
2:47:12 PM: Failing build: Failed to build site
2:47:12 PM: Finished processing build request in 37.732633187s

- If the current behavior is a bug, please provide the steps to reproduce.
This is for https://github.com/Hongbo-Miao/hongbomiao.com/pull/271
The Netlify log is at https://app.netlify.com/sites/hongbomiao/deploys/5da0f8388e6a33bd2937901e
- What is the expected behavior?
Actually, if you try to run nvm ls-remote, node version '12.12.0' is in the list.

Close since it works now in Netlify.


Release 7.3.0 into main

194134c0 DF-696 Helpertext in date filters (#1161)
85190f5f UN-744 Re-instate card image links to the taborder (#1159)
8c8c7ca4 UN-795 Fix alt text for streamfield images and add TODO for heros (#1155)
5a3b8fd9 Fix horizontal scroll on focused article page (#1160)
abffe552 DF-723: FIX Tracking when a user selects a record Covering date filter (#1158)
ffa1a581 DF-746: Website search: Page type label tweaks (#1151)
8fde238b DF-767: Add 'prompt_text' back to the feedback submission listing (#1157)
4649eef2 UN-731 Fix font families for headings across the site (#1153)
d29ec964 UN-785: Topic and Time Period pages to have related Focused Articles (#1150)
e088075b DF-753: Surface website results on 'All results' page [BE] (#1136)
6db8037a UN-776 Topic and Time Period Explorer Pages zoom (#1149)
626e8385 UN 731 styling update to subheadings (#1102)
20436918 DF-590: Record opening date tracking update (#1146)
7cd091e7 DF-767: Allow management of feedback submissions within Wagtail (#1147)
9bc12686 UN-614 Fix for portrait images on mobile so they don't resize too small (#1148)
41cb3a2c UN-759: Unpublished pages still showing in Featured Article (#1119)
0881005e Fix/df 761 fix colours for feedback mechanism (#1144)
3f2117d6 [UN-787] Update component widths for focused articles (#1145)
Merging PR guidance
Follow docs\developer-guide\contributing.md
Deployment guidance
Follow docs\infra\environments.md

Closing due to last minute fix


Project-Platform folder name is truncated to 10 letters

For example creating a project named "MultiTerrain" is truncated to "MultiTerra-Windows" resulting in this error:
PrjCommandException: Error occurred during 'Updating custom solution': Error: Could not find unity-generated project when generating custom solution.  This is necessary so the custom solution can add things like unity defines and DLL references within the unity project.

I see this can be set in Projeny.yaml with the attribute MaxProjectNameLength.


Support for Cosmos SDK v0.50.x

Feature description
Support for Cosmos SDK v0.50.x
Implementation proposal

Update juno to v6 (see https://github.com/forbole/juno/pull/120, thanks @dadamu )
Update cosmos-sdk to v0.50.6

Hey, you can try this branch:
https://github.com/forbole/callisto/tree/cosmos/v0.50.x

Thanks man! That is just awesome! Thank you so much!

hi @jmastr
I try the 0.50.x version, but I found out the modules register does not execute.
func (r *Registrar) BuildModules(ctx registrar.Context) jmodules.Modules {
So I just see the block and txs in postgre.
Do you know how to enable the modules register.

I find out the parameter:
haha
type ChainConfig struct {
Bech32Prefix string   yaml:"bech32_prefix"
Modules      []string yaml:"modules"
}


Only send a resource update message if instances other than the agent instance are found

Proposed changes
This stops a createConnection message from being sent to the management plane if no NGINX instances are found.
Checklist
Before creating a PR, run through this checklist and mark each as complete.

[ ] I have read the CONTRIBUTING document
[ ] I have run make install-tools and have attached any dependency changes to this pull request
[ ] If applicable, I have added tests that prove my fix is effective or that my feature works
[ ] If applicable, I have checked that any relevant tests pass after adding my changes
[ ] If applicable, I have updated any relevant documentation (README.md)
[ ] If applicable, I have tested my cross-platform changes on Ubuntu 22, Redhat 8, SUSE 15 and FreeBSD 13

Closing PR as changes are already done in this PR https://github.com/nginx/agent/pull/699


RequestPattern should not match when there is a body pattern but no request body

This solves one of the issues I have seen as a result of #445

Closing this since I put my own fix in.


Mothballing Sprachanalyse-Werkzeugs

Hi Nic,
after 2 years the NS-Doku team are no longer taking submissions for the “Sprachanalyse-Werkzeugs”. Could you take the submit box offline for Franz Wagners page? Or is this something I could do in the backend?
Thanks
https://departure-neuaubing.nsdoku.de/projekte/mind-the-memory-gap#begriff=/begriffe/einsatz

@xcvy just checked this and I think the simplest way is to disable comments in WP for those specific posts.

Amazing thanks for looking. I will go through it.

Ah, problem: Disabling comments hides all comments. I think we are looking for no new comments…

ah. yes not optimal. I'll change that!

@xcvy actually this also applies to the 'Bietrag einreichen' thing right?

Yes, but only in the Begriffe / Sprachanalyse-Werkzeugs. I don't think for the image submissions.

OK, should be done


safe_urljoin not safe enough

Drops a trailing semicolon

import blobfile as bf

def main():
    path = "<path>/semicolon;"
    with bf.BlobFile(path, "w") as f:
        f.write("meow")
    print(list(bf.listdir("<path>")))
    dirpath = "<path>"
    print([bf.join(dirpath,filename) for filename in list(bf.listdir(dirpath))])
    print(bf.exists(path))
    with bf.BlobFile(path, "r") as f:
        assert f.read() == "meow"

if __name__ == "__main__":
    main()

Should check with both az:// and https://schemes.

Maybe just stop using urljoin since it's error prone


WIP 308 conditional delete integration editor

Changes:

Check and hide ability to delete if step is API provider or CBR
Move most logic to AddStepPage for ease of use with history

Outstanding:

Check for first and last step of integration flow, on confirmation of delete redirect the user to that position step select page. The check works fine, but the redirect does not. See comments below.

fix #308

PR Storybook available here

PR Storybook available here


Fix bugs in pre-bundled version

Change List

Merge experimental exports from core and aggregation-layers
Bump loaders.gl to fix Buffer is undefined error, see https://github.com/uber-web/loaders.gl/pull/422

Coverage increased (+2.7%) to 82.999% when pulling f849334033c7a7568b24f3a29541714b22327184 on x/bundle-fix into dbcfffa3894e763a85a36de69a0f5f041280081b on master.


Move community support to email

With the aim of keeping the issue tracker related to code issues,
and have a more control over specific request.
We are moving admin-only actionable request to email.
I found these places only, not sure if anything else is missing or if we are pointing to the correct email :)

There is also our build error warning that automatically opens an issue on GitHub. Do you think we want to change that as well?

@agjohnson I don't think that's convenient for the users or us. Why? If keeps the knowledge of how to fix x public or current problems. Also, we will have emails of the same error, when maybe there is an issue where users can search for the solution. Or when we break the builders, we will get a lot of emails, in an issue a user can just report the problem in the same thread.

I'm talking about the generic failure case, which should only be for unknown errors that are raised in the build process. It's almost always going to be a support request that involves us looking up information and the user can't really self remedy these errors.

Personally I think that half of those generic errors are because something is wrong from our side (like https://github.com/rtfd/readthedocs.org/issues/5653#issuecomment-488686271), and those should go in the issue tracker. We have some other issues related to memory consumption that can lead to the same problem (the other half).

They should end up as proper issues if there is something we want to fix, yeah.
But that doesn't necessarily mean that the support request needs to be an issue itself -- the issue you linked would be hard for anyone else to find or get value out of, and it effectively separates that request from the rest of our support requests.
Generic support suggestions like this could go to our support queue, and from there we decide if they are an issue we should be working on improving (open a linked github issue), or if they are not worth our time to develop a fix for (resolve and close the support request).

I feel like we are going to get flooded if we link from a general failure to email. Most of them are problems in our side, like not catching the appropriate error or raising a different error.
We could just test how it goes with the current support and then link from general failures to email.

I agree with Anthony on this: pointing the generic error to the issue tracker gives nothing useful to the next person with "the same problem". Those issues are usually on our side and they need to check sentry, logs, etc to debug a little --the user can take no action on these ones. Then, if it's something that needs to be fixed, we (the Core Team) can open an issue here.
I'd change that link to become a mailto: with subject and a body instead of an issue. This will help us to have all the support requests in the same place.
Besides, I think we can modify the GitHub issue template mentioning that support requests are managed by email.


As @alexweav mentioned, the frontend tests are failing (https://github.com/grafana/prometheus-alertmanager/pull/50#issuecomment-1783247904).


core: bump version to 1.7.0.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 87.87%. Comparing base (df72aac) to head (8443403).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #464   +/-   ##
=======================================
  Coverage   87.87%   87.87%
=======================================
  Files          60       60
  Lines        4296     4296
  Branches      448      448
=======================================
  Hits         3775     3775
  Misses        520      520
  Partials        1        1

Flag
Coverage Δ

unittests
87.87% <ø> (ø)

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


iroh: 0.21.0 -> 0.22.0

Description of changes
Please see the project release page for the details of what has changed.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

@cameronfyfe FYI

Please fix the commit message.

Sure, is there some format for the commit message that I should follow?

Please fix the commit message.

Sure, is there some format for the commit message that I should follow?

https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#commit-conventions

Please fix the commit message.

Sure, is there some format for the commit message that I should follow?

https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#commit-conventions

Fixed, thanks,

Superseded by https://github.com/NixOS/nixpkgs/pull/336439


use paketobuildpacks for custom builder validation

Cloud Run button supports supplying a custom builder, rather than using the default "gcr.io/buildpacks/builder".
The buildpacks-builder test was failing due to Heroku buildpacks no longer having a tagged latest (presumably this worked before), and have also have been deprecated, replaced with heroku/builder. However, both of these versions are not compatible with the version of pack being used (e.g.ERROR: failed to build: Builder 'heroku/builder:22' is incompatible with this version of pack)
So instead, replace the use of heroku with another buildpack. From the pack builder suggest output, paketobuildpacks/builder is an option. Using the :full image since the sample application used is PHP, and the :tiny version doesn't support this.

Thanks @glasnt! Can you see why the integration test is failing?  I don't have access to the GCP project for it.

I think the integration test is failing because it is fetching the master branch for the tests instead of the branch the PR is on:
Command './cloudshell_open --repo_url=https://github.com/GoogleCloudPlatform/cloud-run-button --git_branch=master --dir=tests/buildpacks-builder' returned 1

The actual error is:
ERROR: failed to build: failed to fetch builder image 'index.docker.io/heroku/buildpacks:latest': image 'index.docker.io/heroku/buildpacks:latest' does not exist on the daemon: not found

So I think this PR fixes things but just isn't being fetched to test the fix.  If that sounds right we can just merge this.

Correct: the integration test only works for non-testing related changes. I've setup a separate Cloud Build trigger to allow customisation of the branch where tests are sourced from (integration-tests-MANUAL).
You should have access to those test results to verify the change: https://github.com/GoogleCloudPlatform/cloud-run-button/pull/246/checks?check_run_id=19266836330

Awesome.  Thanks @glasnt!


feat: add following config for selection

Description
selection 中增加 following 配置，解决多选节点拖动时卡顿问题。
https://gw.alipayobjects.com/mdn/rms_43231b/afts/img/A*nt5KQqqZHDUAAAAAAAAAAAAAARQnAQ
Motivation and Context

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Enhancement (changes that improvement of current feature or performance)
[ ] Refactoring (changes that neither fixes a bug nor adds a feature)
[ ] Test Case (changes that add missing tests or correct existing tests)
[ ] Code style optimization (changes that do not affect the meaning of the code)
[ ] Docs (changes that only update documentation)
[ ] Chore (changes that don't modify src or test files)

Self Check before Merge

[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

添加following: false 配置后，多个不卡顿单个节点选中移动就会卡顿


Tips for correcting nanopore reads

I'm working with nanopore sequence data and I'm wondering if you have some tips for reparameterizing the config file to better suit the error profile of nanopore data. Can the scoring scheme of proovread bwa be modified much? I'm particularly interested in the fields for bwa-sr and bwa-sr-finish under mapper settings.
The HiSeq coverage is ~10-15X, though coverage is highly uneven throughout the genome.
Thanks!

Hi,
correcting nanopore with proovread is difficult. I have run some very preliminary tests, and even with  very high sensitivity, I did only get alignments to some very interspersed regions. It is especially difficult, if you only have  100bp HiSeq reads. Merged overlapping HiSeqs work a bit better, but useful results, you will only get from using longer MiSeq reads. Nanopore error rate is just to high for generating 100bp alignments with bwa.
Cheers
Thomas

Thanks, Thomas.

Any progress on this since recent improvements in nanopore accuracy?

To be honest, I haven't looked at it lately. It'll probably work better, but I'm not sure if proovread would be the right tool to use for that anyway. PacBio correction works particularly well because it's almost exclusively Indels, whereas homologous regions in the genomes at hand often mostly differ by substitutions - which gives a lot of discriminatory power. With nanopore, even with lower error rates, it's be harder to make a good decisions.


Make dialog region focusable via keyboard

Authors: Please fill out this form carefully and completely.
Reviewers: By approving this Pull Request you are approving the code change, as well as its deployment and mitigation plans.
Please read this description carefully. If you feel there is anything unclear or missing, please ask for updates.
What are you trying to accomplish?
This PR adds the ability to use the keyboard to navigate to a Dialog's scrollable body, which is currently inaccessible to keyboard users.
When a dialog body contains overflown content, the newly added <scrollable-region> element will automatically add the necessary HTML attributes to make the region focusable and screen-reader friendly.
This is a very similar approach that I used to fix the same issue in the React version of the Dialog component.
Screenshots

Integration

List the issues that this change affects.
Closes https://github.com/github/accessibility-audits/issues/5453 (GitHub staff only)
Additional context: https://github.com/github/primer/issues/2698 (GitHub staff only)
Risk Assessment

[x] Low risk the change is small, highly observable, and easily rolled back.
[ ] Medium risk changes that are isolated, reduced in scope or could impact few users. The change will not impact library availability.
[ ] High risk changes are those that could impact customers and SLOs, low or no test coverage, low observability, or slow to rollback.

What approach did you choose and why?

Anything you want to highlight for special attention from reviewers?

Accessibility

Fixes axe scan violation - This change fixes an existing axe scan violation.

Merge checklist

[ ] Added/updated tests
[ ] Added/updated documentation
[ ] Added/updated previews (Lookbook)
[x] Tested in Chrome
[x] Tested in Firefox
[x] Tested in Safari
[x] Tested in Edge

Take a look at the What we look for in reviews section of the contributing guidelines for more information on how we review PRs.

Looks good, would it be easy to add a system test to load the long_text preview?

@jonrohan & @camertron - thanks for the suggestion, I added that system test!
I decided to write a full test asserting the focus behavior, as it seemed better to me than just loading the preview and relying on the Axe scan to detect failures, but if you think this test could become too brittle or flakey (I don't love sending the tab key two times, for example), I'd be happy to just load the preview and let the Axe scan do its thing.
What do you think?

okay the system test is already failing in the CI suite, but was passing in my Codespace. Maybe it would be better to just run the preview and let Axe do the scanning.

Yeah I'm ok with that for now. We can always improve the system test later if there are any regressions.


Fix msvc build -- STRICT is a msvc macro name

Follow up https://github.com/syoyo/tinygltf/pull/445

MSVC CI build passes. https://github.com/syoyo/tinygltf/pull/445
What is the error message?

Sorry, it's actually the msys build which has issues with this name. See eg https://github.com/qgis/QGIS/actions/runs/6060705066/job/16445155328

I see. it'd be better to add msys2 + MinGW(ucrt) CI to tinygltf's Github Actions before merging this PR.

Ok, https://github.com/syoyo/tinygltf/pull/451 adds that. BUT it passes, and it turns out it's not part of the mingw build itself which is defining this macro.
It must be coming from one of the dependencies in the project. (There's some hefty ones there, like Qt and GDAL which have hundreds of dependencies themselves). A quick code scan on github shows a number of projects defining this macro: https://github.com/search?q="%23Define+strict+"&type=code&p=1
More details here: https://learn.microsoft.com/en-au/windows/win32/winprog/enabling-strict?redirectedfrom=MSDN

I see.
I think it'd be better to add suffix(or prefix) to enum identifier or only capitalize the first character to avoid potential conflict of any macro names.
  typedef enum {
    STRICTNESS_PERMISSIVE,
    STRICTNESS_STRICT,
  } ParseStrictness;

  // or

  typedef enum {
    Permissive,
    Strict,
  } ParseStrictness;

@syoyo

I think it'd be better to add suffix(or prefix) to enum identifier or only capitalize the first character to avoid potential conflict of any macro names. How do you think?

Ok, done. I've gone with the capitalization change to avoid any risk.

Brilliant! Thanks! Merged! > I've gone with the capitalization change to avoid any risk.


CVCalendarView days not matching CVMenuView upon screen rotation

[x] I have verified there are no duplicate active or recent bugs, questions, or requests
[x] I have verified that I am using the latest version of CVCalendar.
[x] I have given my issue a non-generic title.

Expected Behavior
When rotating screen CalendarView days should match the MenuView title days (mon, tues etc.)
Current Behavior
When rotating screen CalendarView days are not matching the MenuView title days (mon, tues etc.). Photo 1 shows CalendarView upon loading view controller, photo 2 shows CalendarView after rotation (days are not matching MenuView) and photo 3 shows calendarView after rotation back to portrait and days are not matching again. Photo 4 shows the layout within the view controller. This is not an issue in the demo project. Code and layout of views appears to be the same as the demo project.

Possible Solution

Steps to Reproduce (for bugs)

Load view controller and rotate screen.

Context

Your Environment

Version used (Cocoapods spec): 1.5.0
Device used i.e. iPhone 6S: All Devices
Physical device (y/n): y (iPhone 7, 5s, iPad mini 3)

@Fred-White This isn't an issue using the demo, it must be a problem on your end. Please provide a sample project if you weren't able to fix this by now.


Update README.md

Codecov Report

Merging #16 into master will decrease coverage by 6.52%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master      #16      +/-   ##
==========================================
- Coverage   96.77%   90.25%   -6.53%
==========================================
  Files          31       31
  Lines        1518     1518
  Branches      345      176     -169
==========================================
- Hits         1469     1370      -99
- Misses         49      148      +99

Impacted Files
Coverage Δ

...metry-exporter/src/utils/connectionStringParser.ts
72.05% <0.00%> (-20.59%)
:arrow_down:

...zure-opentelemetry-exporter/src/export/exporter.ts
76.82% <0.00%> (-15.90%)
:arrow_down:

...lemetry-exporter/src/platform/nodejs/httpSender.ts
87.14% <0.00%> (-12.86%)
:arrow_down:

...zure-opentelemetry-exporter/src/utils/spanUtils.ts
86.12% <0.00%> (-12.45%)
:arrow_down:

...r/src/platform/nodejs/persist/fileSystemPersist.ts
86.02% <0.00%> (-7.36%)
:arrow_down:

...ry-exporter/src/platform/nodejs/utils/httpUtils.ts
72.50% <0.00%> (-6.25%)
:arrow_down:

...ry-exporter/src/platform/nodejs/context/context.ts
94.00% <0.00%> (-6.00%)
:arrow_down:

...r/src/platform/nodejs/persist/fileSystemHelpers.ts
88.23% <0.00%> (-5.89%)
:arrow_down:

...re-opentelemetry-exporter/src/utils/breezeUtils.ts
97.56% <0.00%> (-2.44%)
:arrow_down:

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 fa16c46...dfe2102. Read the comment docs.


Date time picker not showing properly in android devices

I have using the framework 7 1.6.4 template for android & iOS application.
And i have also using the iOS template in android devices.
But the  iOS framework 7 template datetimepicker not showing properly in android devices.
I have attached the iOS & android date time picker image.

How to fix the datetimepicker properly in iOS & android devices?
Any possible?

Issue is closed because of outdated/irrelevant/not actual/needed more information/inactivity.
If this issue is still actual and reproducible for latest version of Framework7, please create new issue and fill the issue template correctly:

Clearly describe the issue including steps to reproduce when it is a bug.
Make sure you fill in the earliest version that you know has the issue.
Provide live link or JSFiddle/Codepen or website with issue


Horizontal and vertical scroll bars appear after dragging in an extension

Hello,I'm having the following problem using the TabCSS extension in Tableau 2022.2,When I drag the TabCSS into the dashboard, scroll bars appear both horizontally and vertically.

Then I try to add the worksheet and follow the instructions in the document, but the background position does not correspond to the result.

I don't know where is the problem,thank you for your help!

The scroll bar can't be clicked and the zoom-in extension scroll bar still exists

I have seen this error reported before during internal tests.
From my understanding, this appears to be related to certain Windows machines depending on screen resolutions and how Tableau renders the Extension frame.
I am trying to identify which specific Windows based machines cause this and ways to mitigate the issue.

Thank you for your answer, indeed, I'm using Windows 11 with a monitor resolution of 2520x1680 and a scaling of 150%, unfortunately I can't use this very useful extension now, thanks again. At the same time, I will continue to pay attention to the dynamics of this extension.^^

Apologies, this appears to be related to how Tableau renders the extension browser in Desktop. Hopefully it is something they can resolve quickly.
In the meantime, one workaround can be to safelist the extension on server, publish the workbook, and then use the extension in web edit mode. This workaround isn't the best, but does work

Some good news!
Another user reported a potential solution that appears to be working for them.
On a Windows PC, if you close Tableau, change your scaling to 100%, and then re-open Tableau this extension should properly render.

Some good news!
Another user reported a potential solution that appears to be working for them.
On a Windows PC, if you close Tableau, change your scaling to 100%, and then re-open Tableau this extension should properly render.

Really good news, changing the zoom to 100% did fix the problem, thanks a lot


Handle different methods of gff3, GTF

Ensembl produces a difficult to parse gff3 on their FTP.
Here is an example from Ensembl:
6	ensembl_havana	gene	125161715	125166467	.	-	.	ID=gene:ENSMUSG00000057666;Name=Gapdh;biotype=protein_coding;description=glyceraldehyde-3-phosphate dehydrogenase [Source:MGI Symbol%3BAcc:MGI:95640];gene_id=ENSMUSG00000057666;havana_gene=OTTMUSG00000027118;havana_version=9;logic_name=ensembl_havana_gene;version=18
6	ensembl_havana	transcript	125161853	125166467	.	-	.	ID=transcript:ENSMUST00000117757;Parent=gene:ENSMUSG00000057666;Name=Gapdh-003;biotype=protein_coding;ccdsid=CCDS80613.1;havana_transcript=OTTMUST00000067086;havana_version=3;tag=basic;transcript_id=ENSMUST00000117757;transcript_support_level=1 (assigned to previous version 7);version=8
6	havana	exon	125166394	125166467	.	-	.	Parent=transcript:ENSMUST00000117757;Name=ENSMUSE00001229467;constitutive=0;ensembl_end_phase=0;ensembl_phase=-1;exon_id=ENSMUSE00001229467;rank=1;version=1

And an example from Gencode:
chr6	HAVANA	gene	125161715	125166467	.	-	.	ID=ENSMUSG00000057666.18;gene_id=ENSMUSG00000057666.18;gene_type=protein_coding;gene_status=KNOWN;gene_name=Gapdh;level=2;havana_gene=OTTMUSG00000027118.9
chr6	HAVANA	transcript	125161853	125166467	.	-	.	ID=ENSMUST00000117757.8;Parent=ENSMUSG00000057666.18;gene_id=ENSMUSG00000057666.18;transcript_id=ENSMUST00000117757.8;gene_type=protein_coding;gene_status=KNOWN;gene_name=Gapdh;transcript_type=protein_coding;transcript_status=KNOWN;transcript_name=Gapdh-003;level=2;protein_id=ENSMUSP00000113942.2;transcript_support_level=1;tag=basic,CCDS;ccdsid=CCDS80613.1;havana_gene=OTTMUSG00000027118.9;havana_transcript=OTTMUST00000067086.3
chr6	HAVANA	exon	125166394	125166467	.	-	.	ID=exon:ENSMUST00000117757.8:1;Parent=ENSMUST00000117757.8;gene_id=ENSMUSG00000057666.18;transcript_id=ENSMUST00000117757.8;gene_type=protein_coding;gene_status=KNOWN;gene_name=Gapdh;transcript_type=protein_coding;transcript_status=KNOWN;transcript_name=Gapdh-003;exon_number=1;exon_id=ENSMUSE00001229467.1;level=2;protein_id=ENSMUSP00000113942.2;transcript_support_level=1;ccdsid=CCDS80613.1;havana_gene=OTTMUSG00000027118.9;havana_transcript=OTTMUST00000067086.3;tag=basic,CCDS

Gencode is not producing entirely proper gff3. They do not tag the first level ID for gene or transcript objects. This is actually easier for me, because it means I don't have to munge the output of gff3ToGenePred. I don't see an easy way to be able to seamlessly handle this without some sort of user input. I am tempted to stick with the GTF format instead of gff3 for input, because it is a more consistent format. My thought at this point is to only handle GTF input, and then provide the option for gff3 output (with my annotations). This will mean we cannot transfer important gff3 annotations like selenocysteine, however.

Even more annoying, Ensembl reports ENSMUSG IDs for the TR_V_gene biotype
>>> len(df2.index)
57051
>>> len([x for x in df2.index if x.startswith('ENSMUST')])
56907
>>> len([x for x in df2.index if x.startswith('ENSMUSG')])
144
>>> df3 = df2[df2['biotype'].isin(['TR_V_gene'])]
>>> len(df3)
144

I am now thinking that I should only accept gff3. It is relatively simple to fix the input genePred, in a way that will work for either input set. The TR_V_gene problem is relatively minor, especially since we rarely map over immune genes anyways.

See commit e963928. Still TODO: Filter the columns going in to the database. We don't really need the Parent column, for example. However, I am hesitant to hard code column names to include -- it may be better instead to hardcode those to exclude.

Fixed by commit 78c149c.


break combine-schedulers dependency

Hello,
the package "combine-schedulers" just release a new version 0.5.2 that breaks your MarkdownUI package. In your dependencies it appears:
    .package(url: "https://github.com/pointfreeco/combine-schedulers", from: "0.1.2"),

It will be great to update the "from:" to the version you think is the good one and release a new version.
Thanks!

Thanks for reporting this. It should be fixed in: https://github.com/gonzalezreal/MarkdownUI/releases/tag/0.5.2


Fixed typos

Updated description of scope paramater
Latest improvements:
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and have all been fixed in this PR.
[ ] The OpenAPI Hub was used for checking validation status and next steps.

ARM API Review Checklist

[ ] Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.
adding/removing APIs.
adding/removing properties.
adding/removing API-version.
adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

[ ] If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Please follow the link to find more details on API review process.

Automation for azure-sdk-for-python

Automation for azure-sdk-for-js

Automation for azure-sdk-for-ruby

Automation for azure-sdk-for-node

Automation for azure-sdk-for-go

Can one of the admins verify this patch?

@ajay-sainy Have you generated SDK's based off of this swagger and released them?

Automation for azure-sdk-for-net
A PR has been created for you:
https://github.com/azure/azure-sdk-for-net/pull/5543
.NET SDK Commits:
https://github.com/adxsdknet/azure-sdk-for-net/pull/5543/commits/ba2b54c4239767fd79c002ab21ca4451d46e83b1

Automation for azure-sdk-for-java


internal compiler error: bvbulkalloc too big

What version of Go are you using (go version)?
go version go1.11beta2 linux/amd64
Does this issue reproduce with the latest release?
using go version go1.10.3 linux/amd6 gets the same error.
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/chen/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/chen/git/go"
GOPROXY=""
GORACE=""
GOROOT="/opt/go"
GOTMPDIR=""
GOTOOLDIR="/opt/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build035443180=/tmp/go-build -gno-record-gcc-switches"

What did you do?
go run github.com/meilihao/pinyin/blob/master/example/case.go
What did you expect to see?
go run or go build can work.
What did you see instead?
# github.com/meilihao/pinyin
<autogenerated>:1: internal compiler error: bvbulkalloc too big: nbit=20900 count=877877 nword=654 size=574131558

Please file a bug report including a short program that triggers the error.
https://golang.org/issue/new

@randall77 Thanks for your answer, i put it into func init(), and it works for now.

@randall77 - Since OP has resolved the issue, do we want to track this separately or mark as dup of #26552 ?

Let's track this separately.  #26552 might fix it but I'm not sure.

This seems fixed at tip. CL 140301 helped, but even without that CL tip can compile the OP's code (which is now the commented-out initializer in that github repository, right?). So something else has helped also, not sure what.  It does still take ~4GB or so to compile, but the live variable map is not >2^31 any more.
I'm going to close this now.  #26552 might help some more, but we're ok for now.


Fix syntax error in dangling review app delete action

The 'Delete dangling review apps' GitHub action has been failing for the last five months. We have a few review apps which are no longer needed as a result.
It reports a syntax error e.g:
/home/runner/work/_temp/9aed070d-c2e6-4ab4-8235-fc5ab590262f.sh: line 5: [: too many arguments
This is due to an unquoted variable in a conditional. Presumably the variable is set to a weird or empty string in some race condition where the task is not yet returned by cf tasks, causing it to enter an infinite loop which can never be resolved, and takes 6 hours for the task to eventually be terminated.
Once merged I will rerun the action manually to ensure it has resolved the problem.

Codecov Report

Merging #1608 (096dc6d) into master (72c5fb2) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1608   +/-   ##
=======================================
  Coverage   89.74%   89.74%
=======================================
  Files         388      388
  Lines        8325     8325
  Branches     1218     1218
=======================================
  Hits         7471     7471
  Misses        679      679
  Partials      175      175

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 72c5fb2...096dc6d. Read the comment docs.


Stack overflow in 'HCI uart TX' when using 'hci_uart' sample on 'nucleo_wba55cg' board

Describe the bug
With latest Zephyr (08417b4d73d), the hci_uart sample on nucleo_wba55cg doesn't work as expected. Shortly after issuing btattach on host's side, the controller stops responding. Enabling console drivers and logging on lpuart1 shows stack overflow in HCI uart TX thread:
*** Booting Zephyr OS build v3.6.0-4764-g08417b4d73d5 ***
[00:00:00.031,000] <inf> bt_hci_raw: Bluetooth enabled in RAW mode
[00:00:17.806,000] <err> os: ***** USAGE FAULT *****
[00:00:17.806,000] <err> os:   Stack overflow (context area not valid)
[00:00:17.806,000] <err> os: r0/a1:  0x20007080  r1/a2:  0x2000717f  r2/a3:  0xffffffff
[00:00:17.806,000] <err> os: r3/a4:  0x00000000 r12/ip:  0x20007097 r14/lr:  0x0801c77b
[00:00:17.806,000] <err> os:  xpsr:  0x81000200
[00:00:17.806,000] <err> os: Faulting instruction address (r15/pc): 0x080386ba
[00:00:17.806,000] <err> os: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0
[00:00:17.806,000] <err> os: Current thread: 0x20006290 (HCI uart TX)
[00:00:17.865,000] <err> os: Halting system

To Reproduce
Steps to reproduce the behavior:

west update
west blobs fetch stm32
west build -b nucleo_wba55cg samples/bluetooth/hci_uart
west flash
btattach -B /dev/ttyACM0 -N -S 115200 (on host's side)

Environment (please complete the following information):

OS: Linux (kernel 6.8.10)
Toolchain: Zephyr SDK 0.16.6
BlueZ 5.75

Possible fix
Doubling BT HCI TX stack size (to 2048 from default 1024) seems to solve the problem. So a possible fix is to set below options for the board/SOC/sample (as I don't know root cause of the problem, I'm not entirely sure about the correct fix):
CONFIG_BT_HCI_TX_STACK_SIZE_WITH_PROMPT=y
CONFIG_BT_HCI_TX_STACK_SIZE=2048

@asm5878 ^^

We have already seen this overflow in BT TX stack in other samples.
Indeed the proposed solution is fixing the issue also for all other samples
We will investigate to understand if it's a real bug or a constraint coming from STM32WBA55 integration.

Closing as running out of stack for a given platform is not necessarily a bug we want to fix upstream as we may just then run out of RAM for another platform. Please just adjust the stack size for your platform.


ebpf_updates: issue 5

Fifth issue of the eBPF Updates, for ~March/April 2021
No “did you know” section this time, the issue is long enough like this already.

Thanks a lot Paul, everyone.
I'm going ahead and merging this now!


Overhaul indentation detection

Record level of indentation in indent tokens rather than number of characters of indentation
Support the first line of pipeless-text being indented (jadejs/jade#1588)
Fixed comments-in-case.jade to be a legitimate test case

This breaks compatibility since previously "valid" code like:
html
  body
   p Hello

is now regarded as invalid.

Ping. I really want someone to look at this before I merge it.

I do not feel confident that I fully understand this PR - but on the surface, it looks good.
Am I right in understanding that all children have to be indented by at least 2 spaces or 1 tab? I. e., 0 spaces -> sibling, 1 space -> invalid, 2+ spaces -> child?

Am I right in understanding that all children have to be indented by at least 2 spaces or 1 tab?

No, 1 space works as well.

Then what makes
html
  body
   p Hello

invalid? If I add another space before p it is valid again, right?

Yes. It catches inconsistent cases, not when it is consistently one space.

Do we have that information so that we could print that in the error message?
Something like "Inconsistent indentation, expect N spaces/tabs"?

The error message looks like this:
Error: Jade:3
    1| html
    2|   body
  > 3|    p Hello

Inconsistent indentation
    at makeError (/home/timothy_gu/jade-error/index.js:27:13)
    at Lexer.error (/home/timothy_gu/jade-lexer/index.js:59:15)
    at Lexer.indent (/home/timothy_gu/jade-lexer/index.js:925:14)
    at Lexer.advance (/home/timothy_gu/jade-lexer/index.js:1086:15)
    at Lexer.getTokens (/home/timothy_gu/jade-lexer/index.js:1102:12)
    at internalLex (/home/timothy_gu/jade-lexer/index.js:14:42)
    at lex (/home/timothy_gu/jade-lexer/index.js:10:10)
    at repl:1:13
    at REPLServer.defaultEval (repl.js:164:27)
    at bound (domain.js:250:14)

I guess I can add an "expected" but that would be a bit confusing as it would sound like "inconsistent indentation: got 3 spaces, expected multiples of 2 spaces"

In your case we could print "Inconsistent indentation, expected either 2 or 4 spaces".
Btw, are either of these valid?
html
  body
      p Hello

html
  body
      p Hello
    p World

"Inconsistent indentation, expected either 2 or 4 spaces".

0 spaces work too.

Btw, are either of these valid?

Good catch. They shouldn't be but they are accepted. A even more serious case is:
html
 body
     p Hello
   p World
 p from
p Timothy

which is interpreted as
html
 body
   p Hello
 p World
 p from
p Timothy

But this PR doesn't change the behavior, as the file was already broken.

Fair enough - but let's maybe think of adding this to some bug list somewhere ;)
Regarding the error message, I think an indentation of 3 clearly means you do not want 0, but either 2 or 4, i.e., the user added one space too little or too many.
In a world where the above cases are ruled out we could always print "Inconsistent indentation, expected either X or X+indent spaces", where X is Math.floor(number of spaces / indent) * indent. What do you think?
Also, what is the scope of this indent variable? File-wide? How does it interact with include's and extend's?

Also, what is the scope of this indent variable? File-wide?

Yes, this is the lexer.

Regarding the error message, I think an indentation of 3 clearly means you do not want 0, but either 2 or 4, i.e., the user added one space too little or too many.

I prefer not to guess what the user's intentions are.

How does it interact with include's and extend's?

It doesn't.
How about these:
Error: Jade:3
    1| html
    2|   body
  > 3|    p Hey

Inconsistent indentation. Expected multiples of 2 spaces/tabs, got 3 spaces/tabs.

Error: Jade:4
    1| html
    2|   body
  > 3|       p Hey

Inconsistent indentation. Expected 4 spaces/tabs, got 6 spaces/tabs.

Error: Jade:4
    2|   body
    3|     p.
  > 4|      a

Inconsistent indentation. Expected multiples of 2 spaces/tabs, got 5 spaces/tabs.

Like it a lot. From my code reading and the tests (old and new) it seems good, but maybe someone with better knowledge of the rest of the code wants to take a look as to how it was implemented?

I just finished #16, which achieves the same goals but without the indentation overhaul. The fact that #16 preserves compatibility is something to consider.

Closing in favor of #16.


Add Item is being called twice for when reading nodes/ edges from redux and local storage

        <Graph           graph={{             nodes: this.props.lineageReducer.nodesDisplayed,              edges: this.props.lineageReducer.edges,           }}           options={this.options}           events={{             select: (e) => this.expandNode(e),           }}         />
We read our nodes and edges from redux reducer like so. I have implemented a function that reads data from local storage and sets nodes and edges correctly, I've went into redux and verified it is valid. However, when running my code, an error appears saying that we are adding nodes edges with duplicate id. I debugged through the code and came to the conclusion the in the vis index.js, addNode and addEdge functions are being called twice. I attemted to modify the library code to make a check to prevent it calling again but now icons don't render their image defined by their group correctly. Is someone able to help with this?

sure,
please elaborate in more details and share sample snippets


Baidu Alternative

Dear authors,
Is it possible, to also upload your dataset on an alternative platform like google drive, to allow access to the non-chinese researchers?
Best regards,

Sorry for late reply. Google Drive is supported now.


Problems about streaming the video from the quadrotor to the /<robot_name>/mbzirc/target/stream/start

Hi!
After the simulation starts, we identify the target vessel through the sensor(slot0) of the quadrotor_1, and send the video stream & detection results to the operator. We receive the 'vessel_id_success' through ros2 topic.
Then we use another sensor(slot3) on the very same UAV to detect small object. After we identify the object, we stop the previous video stream and report a new video stream and detection results. We received 'finished', which means that our task failed.
These two video streams have different frame_id. I wonder if the video sources of vessel detection & object detection have to be the same sensor?
Best regards.

hi, currently it works with the same camera. I've extended the logic to support switching cameras for reporting targets in #195. The PR depends on core ignition library changes. We'll make a new release with this soon.


[contract] Capacity not enough when pillaging

happens if your capacity is already full before pillaging, should add a check in the client with tooltip indicating not enough cap


Change AddBlock to accept a VerifiedBlock.

Change the AddBlock type from bookkeeping.Block to ledgercore.ValidatedBlock.
Update effected code:

postgres package should be simplified, remove EvalForIndexer logic and supporting code.
Mocks
Tests

it's now part of #1009


Dependabot removing platform specific gems from Gemfile.lock

Package manager/ecosystem
ruby:bundler 2.2.3
Manifest contents prior to update
Gemfile
gem 'sorbet'
gem 'sorbet-runtime'

Gemfile.lock (snippet)
    sorbet (0.5.6034)
      sorbet-static (= 0.5.6034)
    sorbet-runtime (0.5.6034)
    sorbet-static (0.5.6034-universal-darwin-14)
    sorbet-static (0.5.6034-universal-darwin-15)
    sorbet-static (0.5.6034-universal-darwin-16)
    sorbet-static (0.5.6034-universal-darwin-17)
    sorbet-static (0.5.6034-universal-darwin-18)
    sorbet-static (0.5.6034-universal-darwin-19)
    sorbet-static (0.5.6034-universal-darwin-20)
    sorbet-static (0.5.6034-x86_64-linux)

Updated dependency
n/a
What you expected to see, versus what you actually saw
Dependabot is removing the dependencies, which were added as part of Bundler 2.2.3 (see rubygems/rubygems#4180). It should be left untouched, as the PR is for a different dependency and it works fine when using bundler 2.2.3 via the CLI.
Images of the diff or a link to the PR, issue or logs

I'm running into the same thing.

You can see this with nokogiri 1.11.0.rc4 as well, since it's now shipping as a pre-compiled gem.

It would be really great if you could specify platforms in the Ruby dependabot config. In our project we bundle ruby, x64-mingw32, and x86-mingw32 into a single Gemfile.lock we use to build our project on Linux/Mac/Windows. Dependabot just can't handle that kind of non-ruby platform situation.

It would be really great if you could specify platforms in the Ruby dependabot config. In our project we bundle ruby, x64-mingw32, and x86-mingw32 into a single Gemfile.lock we use to build our project on Linux/Mac/Windows. Dependabot just can't handle that kind of non-ruby platform situation.

@connorshea it didn't make a difference for us, as nokogiri doesn't ship with gems for each version of macOS.

@connorshea it didn't make a difference for us, as nokogiri doesn't ship with gems for each version of macOS.

Hey, yeah I think this happens because we don't fully support bundler v2 yet :( We're currently planning this work though, and hope to add support relatively soon.

Hey, yeah I think this happens because we don't fully support bundler v2 yet :( We're currently planning this work though, and hope to add support relatively soon.

In the meantime, we downgraded back to bundler 2.2.1 and added the platforms we use via bundle lock --add-platform -- Dependabot is too useful :slightly_smiling_face:

In the meantime, we downgraded back to bundler 2.2.1 and added the platforms we use via bundle lock --add-platform -- Dependabot is too useful :slightly_smiling_face:

@connorshea according to this comment by @feelepxyz support has been added for bundler v2. Does that mean this issue will not occur? We're still on an older bundler version because we thought this issue was still open :slightly_frowning_face:

I think it's fixed now, yeah.

Sounds like you can close this issue @jurre @feelepxyz


Bug on container creation

What happened
When we interrupt the create command (with a CTRL + C) while the Navio is downloading a new image, we enter a state of inconsistency. Only a part of the image is downloaded and the system breaks when execute a new container that use the inconsistent image.
example (How to reproduce it)

What you expected to happen:
The command should remove the inconsistent image and download it again

Fixed on https://github.com/viniciusbds/navio/commit/c772d794f2e463755f0633d9ef8c6555ef819be2


Include PCL4.6 reference assemblies

Corresponding targets files added to Mono in https://github.com/mono/mono/pull/2199

:+1:


Use default interface when encrypt-interface is not set

When IPSEC is enabled but Tunnel is disabled, encrypt-interface is required
However in some clusters the main interface name can vary according to instances (frequent on AWS with Ubuntu where c5 will use ens5 and i3 ens3 for instance). This PR uses the interface associated with the default IPV4 route as the encrypt-interface when the flag is not set.
Doing it there seemed to be the simplest solution but of course I can modify the PR if there is a better one

This change is

Coverage decreased (-0.06%) to 44.237% when pulling bfdb18f8ffbd9eedbd87d65c13128cff08e328b5 on DataDog:lbernail/auto-encrypt-if into 30ad6cb9fde07de42dade87c9637cd2820652f86 on cilium:master.

test-me-please

test-me-please

@lbernail also we should use the helper, NodeDeviceNameWithDefaultRoute() in ./pkg/datapath/linuxx/node.go

@lbernail I needed to pull this into my PR to add encrypt-node support to our CI. Would you like me to push it through that PR, keeping your author attribution of course? Either way is fine might save you some cycles though.

@jrfastab This is indeed much cleaner (sorry I did not about the helper)
Of course feel free to cherry-pick this change where you see fit

@lbernail can you rebase against master? it seems there's a conflicting file

superseded by https://github.com/cilium/cilium/pull/8711


Coverity 1022104 Dereference before null check

@zwoop a couple of additional suggestions

rename _s to something more meaningful
replace the 4 setXxx() member functions with a single init()

We can make it a release assert (although I'm hesitant to do that since it never happens so it's an additional, unnecessary check). The other suggestions, feel free to fix in subsequent PRs.


Failded to build libtensorflow_inference.so

Please Help,I try to build libtensorflow_inference.so ,but i get an error.  I guess the problem is my sytem ,I use window10, I don't know
bazel build -c opt //tensorflow/contrib/android:libtensorflow_inference.so --crosstool_top=//external:android/crosstool --host_crosstool_top=@bazel_tools//tools/cpp:toolchain  --cpu=armeabi-v7a
this is my error information:
INFO: Analysed target //tensorflow/contrib/android:libtensorflow_inference.so (0 packages loaded, 2701 targets configured).
INFO: Found 1 target...
ERROR: C:/users/cuiwanxin/_bazel_cuiwanxin/obpmm2rb/external/com_google_absl/absl/numeric/BUILD.bazel:25:1: C++ compilation of rule '@com_google_absl//absl/numeric:int128' failed (Exit -1). Note: Remote connection/protocol failed with: execution failed: false failed: error executing command
  cd C:/users/cuiwanxin/_bazel_cuiwanxin/obpmm2rb/execroot/org_tensorflow
  SET PATH=D:\mysy64\usr\bin\bash.exe;D:\mysy64\usr\share
    SET PWD=/proc/self/cwd
  /bin/false -MD -MF bazel-out/armeabi-v7a-opt/bin/external/com_google_absl/absl/numeric/_objs/int128/int128.pic.d -frandom-seed=bazel-out/armeabi-v7a-opt/bin/external/com_google_absl/absl/numeric/_objs/int128/int128.pic.o -fPIC -iquote external/com_google_absl -iquote bazel-out/armeabi-v7a-opt/genfiles/external/com_google_absl -iquote bazel-out/armeabi-v7a-opt/bin/external/com_google_absl -Wall -Wextra -Wcast-qual -Wconversion-null -Wmissing-declarations -Woverlength-strings -Wpointer-arith -Wunused-local-typedefs -Wunused-result -Wvarargs -Wvla -Wwrite-strings -Wno-sign-compare -c external/com_google_absl/absl/numeric/int128.cc -o bazel-out/armeabi-v7a-opt/bin/external/com_google_absl/absl/numeric/_objs/int128/int128.pic.o
Execution platform: @bazel_tools//platforms:host_platform
Action failed to execute: java.io.IOException: ERROR: src/main/native/windows/processes-jni.cc(383): CreateProcessW("C:\users\cuiwanxin\_bazel_cuiwanxin\obpmm2rb\execroot\org_tensorflow\bin\false" -MD -MF bazel-out/armeabi-v7a-opt/bin/external/com_google_absl/absl/numeric/_objs/int128/int128.pic.d -frandom-see(...)):
Target //tensorflow/contrib/android:libtensorflow_inference.so failed to build
INFO: Elapsed time: 11.720s, Critical Path: 0.07s
INFO: 0 processes.
FAILED: Build did NOT complete successfully

Closing due to lack of recent activity. Please update the issue when new information becomes available, and we will reopen the issue. Thanks!

Compiling TF v1.12.0 from sources with:
bazel build -c opt //tensorflow/contrib/android:libtensorflow_inference.so --crosstool_top=//external:android/crosstool --host_crosstool_top=@bazel_tools//tools/cpp:toolchain --cpu=armeabi-v7a --verbose_failures
Getting exactly same error.

@hokmund Could you try the solutions provided here that worked for someone. Thanks!


CDC upgrading has ERROR: [CDC:ErrInvalidEtcdKey]

What did you do?

Upgrade tidb cluster from v6.1.0 to nightly: tiup cluster upgrade avrotest nightly

What did you expect to see?
Reason log during upgrading.
What did you see instead?
[2022/07/18 11:47:15.897 +08:00] [ERROR] [server.go:152] ["run server"] [error="[CDC:ErrInvalidEtcdKey]invalid key: /backup/0/tidb/cdc/changefeed/info/kafka-avro\ngithub.com/pingcap/errors.AddStack\n\tgithub.com/pingcap/errors@v0.11.5-0.20211224045212-9687c2b0f87c/errors.go:174\ngithub.com/pingcap/errors.(*Error).GenWithStackByArgs\n\tgithub.com/pingcap/errors@v0.11.5-0.20211224045212-9687c2b0f87c/normalize.go:164\ngithub.com/pingcap/tiflow/pkg/etcd.(*CDCKey).Parse\n\tgithub.com/pingcap/tiflow/pkg/etcd/etcdkey.go:144\ngithub.com/pingcap/tiflow/pkg/orchestrator.(*GlobalReactorState).Update\n\tgithub.com/pingcap/tiflow/pkg/orchestrator/reactor_state.go:54\ngithub.com/pingcap/tiflow/pkg/orchestrator.(*EtcdWorker).syncRawState\n\tgithub.com/pingcap/tiflow/pkg/orchestrator/etcd_worker.go:332\ngithub.com/pingcap/tiflow/pkg/orchestrator.(*EtcdWorker).Run\n\tgithub.com/pingcap/tiflow/pkg/orchestrator/etcd_worker.go:126\ngithub.com/pingcap/tiflow/cdc/capture.(*Capture).runEtcdWorker\n\tgithub.com/pingcap/tiflow/cdc/capture/capture.go:419\ngithub.com/pingcap/tiflow/cdc/capture.(*Capture).campaignOwner\n\tgithub.com/pingcap/tiflow/cdc/capture/capture.go:392\ngithub.com/pingcap/tiflow/cdc/capture.(*Capture).run.func2\n\tgithub.com/pingcap/tiflow/cdc/capture/capture.go:272\nruntime.goexit\n\truntime/asm_amd64.s:1571\nowner exited with error"]
Versions of the cluster
Upstream TiDB cluster version (execute SELECT tidb_version(); in a MySQL client):
(paste TiDB cluster version here)

Upstream TiKV version (execute tikv-server --version):
(paste TiKV version here)

TiCDC version (execute cdc version):
(paste TiCDC version here)
Release Version: v6.2.0-alpha
Git Commit Hash: abc120caaf6bae9c64e9ed345618ecf303950409
Git Branch: heads/refs/tags/v6.2.0-alpha
UTC Build Time: 2022-07-17 14:25:40
Go Version: go version go1.18.2 linux/amd64
Failpoint Build: false

how many ticdc cluster nodes in your cluster?  if non-master cdc node print this log, it's normal case

2 cdc node
'Jianyuan Jiang' via Tools QA @.***> 于2022年7月18日周一 22:46写道：

how many ticdc cluster nodes in your cluster? if non-master cdc node print
this log, it's normal case
—
Reply to this email directly, view it on GitHub
https://github.com/pingcap/tiflow/issues/6318#issuecomment-1187591954,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AT3WYSYO3JWUMXRDY46GBGLVUVU2VANCNFSM5327HM4A
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

/assign @asddongmen

In the upgrading progress of a  multiple TiCDC nodes cluster, the first upgraed cdc node will write some new keys into etcd that old version cdc server doesn't recognize, so this error occurs, it is by design, and the upgrading will eventually successful.

It is not a bug.


File typ matching

Sometimes there is only value to change certain types. Lets say *.js files.
Would be very useful

This can be done via Language settings. Please see the Language notes in the README:
https://github.com/twolfson/sublime-hooks/tree/0.3.1#accessing-settings


Adjust mindful ad preview route with template/layout concepts & update core version with company name

This is now setup similar to the other template layout version of pages we uses.  This version will allow you to utiliz the standard global template with the three previews or you can override this template while utilize the orgs/sites version of nativeX block calls
the global version now says ${Advertisers’s Name} ad preview for the title & set preview titles as such.  Preview #1, Preview #2 & Preview #3.
This will hopefully remove any concern about naming of positions or allow the groups an easier way to override this route.
Loaded on example website base-cms:

Loaded on IEN:

 Add new global preview route for mindful native website ads


[4.2 EARLY] [Serialization] Mark decls that can never be cross-referenced

Explanation: Normally Swift ignores forward declarations of Objective-C classes, but SourceKit's module interface generation feature makes dummy ClassDecls for them instead. This can make a previously unambiguous reference to an Objective-C protocol ambiguous, resulting in a crash. (This crash has the same signature as one of the top SourceKit crashers; whether this particular issue is actually responsible for the bulk of those crashes is unknown.)

Scope: Affects forward-declared Objective-C classes only, which means only the modes of SourceKit that use dummy ClassDecls.

Issue: SR-4851

Risk: Low. This should not affect regular compilation at all, and should only improve things for SourceKit.

Testing: Added compiler regression tests, verified that the reproduction steps succeed.

Reviewed by: @DougGregor

@swift-ci Please test


[Doc] Examples for how to get the detected events

Documentation needs some example on how to do this.

done in 0fa90aa see http://samuroi.readthedocs.io/en/latest/examples.html


Enhancement of Follow us buttons

I would like to add hover effects to the social buttons of Follow us section.

Please assign me this issue under GSSoC24.


fcitx-qt5: 1.2.1 -> 1.2.3

Motivation for this change
Update fcitx-qt5 to the latest release.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

changes https://gitlab.com/fcitx/fcitx-qt5/compare/1.2.1...1.2.3
@GrahamcOfBorg build fcitx-qt5

Does this need to go into staging rather than master?

@ttuegel It was targeted for staging originally, but only one thing depends on this package.
Changing the base branch brought in those commits.

this fails on nixos-unstable with https://github.com/NixOS/nixpkgs/issues/65547


Version 0.4.0

Release notes coming in the next comment.

:warning: Breaking Changes!
ES6 client classes
The syntax for creating a client has changed. MonitoringServiceClient is now an ES6 class, and we expose it directly.
You now create a client with:
const monitoring = require('@google-cloud/monitoring');
let client = new monitoring.MetricServiceClient();

If you are migrating from a previous version of @google-cloud/monitoring, here  is the fundamental change you need to make:
const monitoring = require('@google-cloud/monitoring');

-let client = monitoring.metric();
+let client = new monitoring.MetricServiceClient();

Features
Uptime Check Service
The monitoring API has added a new service: the "uptime check" service. Accordingly, the client now has an UptimeCheckServiceClient.
You can learn more about using this client by consulting samples/uptime.js.
Runnable samples
There are now runnable samples in the samples/ directory. These samples demonstrate the use of this API and offer an additional resource for getting started. These also power the readme, and are automatically tested to ensure that they are up-to-date and correct.
Implementation Details

Change to a new linter (ESLint) and code style formatter (prettify).
Update docs to use JSDoc 3.
Migrate to the googleapis/nodejs-monitoring repository.

Going to sit on this for a little while to give @jmdobry a final sanity check. Will merge near the end of the day if he has not said anything.


fluent-bit: fix build on darwin

Motivation for this change
ZHF: #144627 (@NixOS/nixos-release-managers)
Things done

Update fix-luajit-darwin.patch to apply to the current version.

Add a patch to fix compilation of bundled cmetrics on darwin.

 [ 15%] Building C object lib/cmetrics/src/CMakeFiles/cmetrics-static.dir/cmt_gauge.c.o
 [ 15%] Building C object lib/cmetrics/src/CMakeFiles/cmetrics-static.dir/cmt_counter.c.o
 [ 16%] Building C object lib/cmetrics/src/CMakeFiles/cmetrics-static.dir/cmt_untyped.c.o
 [ 16%] Building C object lib/cmetrics/src/CMakeFiles/cmetrics-static.dir/cmt_metric.c.o
 [ 16%] Building C object lib/cmetrics/src/CMakeFiles/cmetrics-static.dir/cmt_map.c.o
 [ 16%] Building C object lib/cmetrics/src/CMakeFiles/cmetrics-static.dir/cmt_log.c.o
 [ 16%] Building C object lib/cmetrics/src/CMakeFiles/cmetrics-static.dir/cmt_opts.c.o
 [ 16%] Building C object lib/cmetrics/src/CMakeFiles/cmetrics-static.dir/cmt_time.c.o
 /tmp/nix-build-fluent-bit-1.8.9.drv-0/source/lib/cmetrics/src/cmt_time.c: In function 'cmt_time_now':
 /tmp/nix-build-fluent-bit-1.8.9.drv-0/source/lib/cmetrics/src/cmt_time.c:40:5: error: unknown type name 'clock_serv_t'
    40 |     clock_serv_t cclock;
       |     ^~~~~~~~~~~~
 /tmp/nix-build-fluent-bit-1.8.9.drv-0/source/lib/cmetrics/src/cmt_time.c:41:5: error: unknown type name 'mach_timespec_t'
    41 |     mach_timespec_t mts;
       |     ^~~~~~~~~~~~~~~
 /tmp/nix-build-fluent-bit-1.8.9.drv-0/source/lib/cmetrics/src/cmt_time.c:42:5: warning: implicit declaration of function 'host_get_clock_service' [8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wimplicit-function-declaration-Wimplicit-function-declaration8;;]
    42 |     host_get_clock_service(mach_host_self(), CALENDAR_CLOCK, &cclock);
       |     ^~~~~~~~~~~~~~~~~~~~~~
 /tmp/nix-build-fluent-bit-1.8.9.drv-0/source/lib/cmetrics/src/cmt_time.c:42:28: warning: implicit declaration of function 'mach_host_self' [8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wimplicit-function-declaration-Wimplicit-function-declaration8;;]
    42 |     host_get_clock_service(mach_host_self(), CALENDAR_CLOCK, &cclock);
       |                            ^~~~~~~~~~~~~~
 /tmp/nix-build-fluent-bit-1.8.9.drv-0/source/lib/cmetrics/src/cmt_time.c:42:46: error: 'CALENDAR_CLOCK' undeclared (first use in this function)
    42 |     host_get_clock_service(mach_host_self(), CALENDAR_CLOCK, &cclock);
       |                                              ^~~~~~~~~~~~~~
 /tmp/nix-build-fluent-bit-1.8.9.drv-0/source/lib/cmetrics/src/cmt_time.c:42:46: note: each undeclared identifier is reported only once for each function it appears in
 /tmp/nix-build-fluent-bit-1.8.9.drv-0/source/lib/cmetrics/src/cmt_time.c:43:5: warning: implicit declaration of function 'clock_get_time'; did you mean 'clock_gettime'? [8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wimplicit-function-declaration-Wimplicit-function-declaration8;;]
    43 |     clock_get_time(cclock, &mts);
       |     ^~~~~~~~~~~~~~
       |     clock_gettime
 /tmp/nix-build-fluent-bit-1.8.9.drv-0/source/lib/cmetrics/src/cmt_time.c:44:7: error: invalid type argument of '->' (have 'struct timespec')
    44 |     tm->tv_sec = mts.tv_sec;
       |       ^~
 /tmp/nix-build-fluent-bit-1.8.9.drv-0/source/lib/cmetrics/src/cmt_time.c:44:21: error: request for member 'tv_sec' in something not a structure or union
    44 |     tm->tv_sec = mts.tv_sec;
       |                     ^
 /tmp/nix-build-fluent-bit-1.8.9.drv-0/source/lib/cmetrics/src/cmt_time.c:45:7: error: invalid type argument of '->' (have 'struct timespec')
    45 |     tm->tv_nsec = mts.tv_nsec;
       |       ^~
 /tmp/nix-build-fluent-bit-1.8.9.drv-0/source/lib/cmetrics/src/cmt_time.c:45:22: error: request for member 'tv_nsec' in something not a structure or union
    45 |     tm->tv_nsec = mts.tv_nsec;
       |                      ^
 /tmp/nix-build-fluent-bit-1.8.9.drv-0/source/lib/cmetrics/src/cmt_time.c:46:5: warning: implicit declaration of function 'mach_port_deallocate' [8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wimplicit-function-declaration-Wimplicit-function-declaration8;;]
    46 |     mach_port_deallocate(mach_task_self(), cclock);
       |     ^~~~~~~~~~~~~~~~~~~~
 /tmp/nix-build-fluent-bit-1.8.9.drv-0/source/lib/cmetrics/src/cmt_time.c:46:26: warning: implicit declaration of function 'mach_task_self' [8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wimplicit-function-declaration-Wimplicit-function-declaration8;;]
    46 |     mach_port_deallocate(mach_task_self(), cclock);
       |                          ^~~~~~~~~~~~~~
 make[2]: *** [lib/cmetrics/src/CMakeFiles/cmetrics-static.dir/build.make:174: lib/cmetrics/src/CMakeFiles/cmetrics-static.dir/cmt_time.c.o] Error 1
 make[1]: *** [CMakeFiles/Makefile2:2741: lib/cmetrics/src/CMakeFiles/cmetrics-static.dir/all] Error 2

Use default stdenv instead of gccStdenv. The only requirement for GCC was the bundled luajit having DEFAULT_CC = gcc hardcoded, but it has been fixed with the updated fix-luajit-darwin.patch by adding DEFAULT_CC=cc to the luajit build command.

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[X] x86_64-darwin
[ ] aarch64-darwin

[X] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[X] Tested basic functionality of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 146832 run on x86_64-darwin 1

1 package built:

fluent-bit

Builds happily, macos 10.15