[1.12.0-rc2] something fishy with rshared mount propagation

Output of docker version:
Client:
 Version:      1.12.0-rc2
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   a7119de
 Built:        Fri Jun 17 22:09:20 2016
 OS/Arch:      linux/amd64
 Experimental: true

Server:
 Version:      1.12.0-rc2
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   a7119de
 Built:        Fri Jun 17 22:09:20 2016
 OS/Arch:      linux/amd64
 Experimental: true

Output of docker info:
Containers: 23
 Running: 0
 Paused: 0
 Stopped: 23
Images: 4
Server Version: 1.12.0-rc2
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 93
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: host null bridge overlay
Swarm: inactive
Runtimes: default
Default Runtime: default
Security Options: seccomp
Kernel Version: 4.4.13-moby
Operating System: Alpine Linux v3.4
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 1.954 GiB
Name: moby
ID: XK6W:FQXT:ZXUF:U5DL:KHL4:IQDT:EVTD:ZYDX:D6TL:GKGH:YW47:QFOK
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 21
 Goroutines: 28
 System Time: 2016-06-20T14:32:23.6998763Z
 EventsListeners: 1
No Proxy: *.local, 169.254/16
Registry: https://index.docker.io/v1/
Experimental: true
Insecure Registries:
 <IP_ADDRESS>/8

Additional environment details (AWS, VirtualBox, physical, etc.):
Docker for Mac
Steps to reproduce the issue:

mount --make-rshared /
docker run -v /:/rootfs:rw,rshared alpine /bin/true

Describe the results you received:
docker: Error response from daemon: oci runtime error: rootfs_linux.go:89: jailing process inside rootfs caused "pivot_root invalid argument".

Describe the results you expected:
No errors.
Additional information you deem important (e.g. issue happens only occasionally):
I have managed to reproduce this with runc.
mkdir -p test/rootfs
docker export $(docker create busybox) | tar -C test/rootfs -xv

Create test/config.json:
{
    "ociVersion": "1.0.0-rc1",
    "platform": {
        "os": "linux",
        "arch": "amd64"
    },
    "process": {
        "user": {
            "uid": 0,
            "gid": 0,
                        "additionalGids": [
                          0,
                          1,
                          2,
                          3,
                          4,
                          6,
                          10,
                          11,
                          20,
                          26,
                          27
                        ]
        },
        "args": [
            "/bin/true"
        ],
        "env": [
            "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
            "TERM=xterm"
        ],
        "cwd": "/",
                "capabilities": [
                  "CAP_CHOWN",
                  "CAP_DAC_OVERRIDE",
                  "CAP_FSETID",
                  "CAP_FOWNER",
                  "CAP_MKNOD",
                  "CAP_NET_RAW",
                  "CAP_SETGID",
                  "CAP_SETUID",
                  "CAP_SETFCAP",
                  "CAP_SETPCAP",
                  "CAP_NET_BIND_SERVICE",
                  "CAP_SYS_CHROOT",
                  "CAP_KILL",
                  "CAP_AUDIT_WRITE"
        ],
        "rlimits": [
            {
                "type": "RLIMIT_NOFILE",
                "hard": 1024,
                "soft": 1024
            }
        ],
        "noNewPrivileges": true
    },
    "root": {
        "path": "rootfs",
        "readonly": true
    },
    "hostname": "runc",
    "mounts": [
                {
                  "destination": "/rootfs",
                  "type": "bind",
                  "source": "/",
                  "options": [
                    "rbind",
                    "rshared"
                  ]
                },
        {
            "destination": "/proc",
            "type": "proc",
            "source": "proc"
        },
        {
            "destination": "/dev",
            "type": "tmpfs",
            "source": "tmpfs",
            "options": [
                "nosuid",
                "strictatime",
                "mode=755",
                "size=65536k"
            ]
        },
        {
            "destination": "/dev/pts",
            "type": "devpts",
            "source": "devpts",
            "options": [
                "nosuid",
                "noexec",
                "newinstance",
                "ptmxmode=0666",
                "mode=0620",
                "gid=5"
            ]
        },
        {
            "destination": "/dev/shm",
            "type": "tmpfs",
            "source": "shm",
            "options": [
                "nosuid",
                "noexec",
                "nodev",
                "mode=1777",
                "size=65536k"
            ]
        },
        {
            "destination": "/dev/mqueue",
            "type": "mqueue",
            "source": "mqueue",
            "options": [
                "nosuid",
                "noexec",
                "nodev"
            ]
        },
        {
            "destination": "/sys",
            "type": "sysfs",
            "source": "sysfs",
            "options": [
                "nosuid",
                "noexec",
                "nodev",
                "ro"
            ]
        },
        {
            "destination": "/sys/fs/cgroup",
            "type": "cgroup",
            "source": "cgroup",
            "options": [
                "nosuid",
                "noexec",
                "nodev",
                "relatime",
                "ro"
            ]
        }
    ],
    "hooks": {},
        "linux": {
          "resources": {
            "devices": [
              {
                "allow": false,
                "access": "rwm"
              },
              {
                "allow": true,
                "type": "c",
                "major": 1,
                "minor": 5,
                "access": "rwm"
              },
              {
                "allow": true,
                "type": "c",
                "major": 1,
                "minor": 3,
                "access": "rwm"
              },
              {
                "allow": true,
                "type": "c",
                "major": 1,
                "minor": 9,
                "access": "rwm"
              },
              {
                "allow": true,
                "type": "c",
                "major": 1,
                "minor": 8,
                "access": "rwm"
              },
              {
                "allow": true,
                "type": "c",
                "major": 5,
                "minor": 0,
                "access": "rwm"
              },
              {
                "allow": true,
                "type": "c",
                "major": 5,
                "minor": 1,
                "access": "rwm"
              },
              {
                "allow": false,
                "type": "c",
                "major": 10,
                "minor": 229,
                "access": "rwm"
              }
            ],
            "disableOOMKiller": false,
            "oomScoreAdj": 0,
            "memory": {
              "kernelTCP": null
            },
            "cpu": {},
            "pids": {
              "limit": 0
            },
            "blockIO": {
              "blkioWeight": 0
            }
          },
          "cgroupsPath": "/docker/a461783c34e1d86da146e9ed12095b5c0925b8109bee19134c8d4ede66291e44",
          "namespaces": [
            {
              "type": "mount"
            },
            {
              "type": "network"
            },
            {
              "type": "uts"
            },
            {
              "type": "pid"
            },
            {
              "type": "ipc"
            }
          ],
          "devices": [
            {
              "path": "/dev/fuse",
              "type": "c",
              "major": 10,
              "minor": 229,
              "fileMode": 438,
              "uid": 0,
              "gid": 0
            }
          ],
          "seccomp": {
            "defaultAction": "SCMP_ACT_ERRNO",
            "architectures": [
              "SCMP_ARCH_X86_64",
              "SCMP_ARCH_X86",
              "SCMP_ARCH_X32"
            ],
            "syscalls": [
              {
                "name": "accept",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "accept4",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "access",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "alarm",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "bind",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "brk",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "capget",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "capset",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "chdir",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "chmod",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "chown",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "chown32",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "clock_getres",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "clock_gettime",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "clock_nanosleep",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "close",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "connect",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "copy_file_range",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "creat",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "dup",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "dup2",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "dup3",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "epoll_create",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "epoll_create1",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "epoll_ctl",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "epoll_ctl_old",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "epoll_pwait",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "epoll_wait",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "epoll_wait_old",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "eventfd",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "eventfd2",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "execve",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "execveat",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "exit",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "exit_group",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "faccessat",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "fadvise64",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "fadvise64_64",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "fallocate",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "fanotify_mark",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "fchdir",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "fchmod",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "fchmodat",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "fchown",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "fchown32",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "fchownat",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "fcntl",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "fcntl64",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "fdatasync",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "fgetxattr",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "flistxattr",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "flock",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "fork",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "fremovexattr",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "fsetxattr",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "fstat",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "fstat64",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "fstatat64",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "fstatfs",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "fstatfs64",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "fsync",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "ftruncate",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "ftruncate64",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "futex",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "futimesat",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getcpu",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getcwd",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getdents",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getdents64",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getegid",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getegid32",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "geteuid",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "geteuid32",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getgid",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getgid32",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getgroups",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getgroups32",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getitimer",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getpeername",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getpgid",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getpgrp",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getpid",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getppid",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getpriority",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getrandom",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getresgid",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getresgid32",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getresuid",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getresuid32",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getrlimit",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "get_robust_list",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getrusage",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getsid",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getsockname",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getsockopt",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "get_thread_area",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "gettid",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "gettimeofday",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getuid",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getuid32",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "getxattr",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "inotify_add_watch",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "inotify_init",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "inotify_init1",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "inotify_rm_watch",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "io_cancel",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "ioctl",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "io_destroy",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "io_getevents",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "ioprio_get",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "ioprio_set",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "io_setup",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "io_submit",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "ipc",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "kill",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "lchown",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "lchown32",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "lgetxattr",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "link",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "linkat",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "listen",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "listxattr",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "llistxattr",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "_llseek",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "lremovexattr",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "lseek",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "lsetxattr",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "lstat",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "lstat64",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "madvise",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "memfd_create",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "mincore",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "mkdir",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "mkdirat",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "mknod",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "mknodat",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "mlock",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "mlock2",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "mlockall",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "mmap",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "mmap2",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "mprotect",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "mq_getsetattr",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "mq_notify",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "mq_open",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "mq_timedreceive",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "mq_timedsend",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "mq_unlink",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "mremap",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "msgctl",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "msgget",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "msgrcv",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "msgsnd",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "msync",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "munlock",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "munlockall",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "munmap",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "nanosleep",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "newfstatat",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "_newselect",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "open",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "openat",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "pause",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "personality",
                "action": "SCMP_ACT_ALLOW",
                "args": [
                  {
                    "index": 0,
                    "value": 0,
                    "valueTwo": 0,
                    "op": "SCMP_CMP_EQ"
                  }
                ]
              },
              {
                "name": "personality",
                "action": "SCMP_ACT_ALLOW",
                "args": [
                  {
                    "index": 0,
                    "value": 8,
                    "valueTwo": 0,
                    "op": "SCMP_CMP_EQ"
                  }
                ]
              },
              {
                "name": "personality",
                "action": "SCMP_ACT_ALLOW",
                "args": [
                  {
                    "index": 0,
                    "value":<PHONE_NUMBER>,
                    "valueTwo": 0,
                    "op": "SCMP_CMP_EQ"
                  }
                ]
              },
              {
                "name": "pipe",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "pipe2",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "poll",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "ppoll",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "prctl",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "pread64",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "preadv",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "prlimit64",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "pselect6",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "pwrite64",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "pwritev",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "read",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "readahead",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "readlink",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "readlinkat",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "readv",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "recv",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "recvfrom",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "recvmmsg",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "recvmsg",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "remap_file_pages",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "removexattr",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "rename",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "renameat",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "renameat2",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "restart_syscall",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "rmdir",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "rt_sigaction",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "rt_sigpending",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "rt_sigprocmask",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "rt_sigqueueinfo",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "rt_sigreturn",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "rt_sigsuspend",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "rt_sigtimedwait",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "rt_tgsigqueueinfo",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "sched_getaffinity",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "sched_getattr",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "sched_getparam",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "sched_get_priority_max",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "sched_get_priority_min",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "sched_getscheduler",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "sched_rr_get_interval",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "sched_setaffinity",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "sched_setattr",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "sched_setparam",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "sched_setscheduler",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "sched_yield",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "seccomp",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "select",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "semctl",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "semget",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "semop",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "semtimedop",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "send",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "sendfile",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "sendfile64",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "sendmmsg",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "sendmsg",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "sendto",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "setfsgid",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "setfsgid32",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "setfsuid",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "setfsuid32",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "setgid",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "setgid32",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "setgroups",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "setgroups32",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "setitimer",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "setpgid",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "setpriority",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "setregid",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "setregid32",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "setresgid",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "setresgid32",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "setresuid",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "setresuid32",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "setreuid",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "setreuid32",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "setrlimit",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "set_robust_list",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "setsid",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "setsockopt",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "set_thread_area",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "set_tid_address",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "setuid",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "setuid32",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "setxattr",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "shmat",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "shmctl",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "shmdt",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "shmget",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "shutdown",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "sigaltstack",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "signalfd",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "signalfd4",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "sigreturn",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "socket",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "socketcall",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "socketpair",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "splice",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "stat",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "stat64",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "statfs",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "statfs64",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "symlink",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "symlinkat",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "sync",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "sync_file_range",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "syncfs",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "sysinfo",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "syslog",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "tee",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "tgkill",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "time",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "timer_create",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "timer_delete",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "timerfd_create",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "timerfd_gettime",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "timerfd_settime",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "timer_getoverrun",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "timer_gettime",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "timer_settime",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "times",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "tkill",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "truncate",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "truncate64",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "ugetrlimit",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "umask",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "uname",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "unlink",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "unlinkat",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "utime",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "utimensat",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "utimes",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "vfork",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "vmsplice",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "wait4",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "waitid",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "waitpid",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "write",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "writev",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "arch_prctl",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "modify_ldt",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "chroot",
                "action": "SCMP_ACT_ALLOW"
              },
              {
                "name": "clone",
                "action": "SCMP_ACT_ALLOW",
                "args": [
                  {
                    "index": 0,
                    "value":<PHONE_NUMBER>,
                    "valueTwo": 0,
                    "op": "SCMP_CMP_MASKED_EQ"
                  }
                ]
              }
            ]
          },
          "rootfsPropagation": "shared",
          "maskedPaths": [
            "/proc/kcore",
            "/proc/latency_stats",
            "/proc/timer_stats",
            "/proc/sched_debug"
          ],
          "readonlyPaths": [
            "/proc/asound",
            "/proc/bus",
            "/proc/fs",
            "/proc/irq",
            "/proc/sys",
            "/proc/sysrq-trigger"
          ]
        }
}

And: cd test ; docker-runc --debug --log /dev/stdout run testc produces:
WARN[0000] exit status 1
ERRO[0000] rootfs_linux.go:89: jailing process inside rootfs caused "pivot_root invalid argument"
rootfs_linux.go:89: jailing process inside rootfs caused "pivot_root invalid argument"

/cc @cpuguy83

Also, while testing this, I had some flaky behaviour that I'm not able to document just yet.

I suspect it's not likely to be the mount propagation on the host bind, but rather making / shared.

@cpuguy83 I am just about to double check, but it looks like rootfsPropagation in the config is the culprit.

Ok, regarding flakiness, I've rebooted the machine and ran docker-runc part twice, then it got stuck on the third run:
moby:~/test# docker-runc --debug --log /dev/stdout run testc
WARN[0000] signal: killed
ERRO[0000] rootfs_linux.go:89: jailing process inside rootfs caused "pivot_root invalid argument"
rootfs_linux.go:89: jailing process inside rootfs caused "pivot_root invalid argument"
moby:~/test# docker-runc --debug --log /dev/stdout run testc
WARN[0000] exit status 1
ERRO[0000] rootfs_linux.go:89: jailing process inside rootfs caused "pivot_root invalid argument"
rootfs_linux.go:89: jailing process inside rootfs caused "pivot_root invalid argument"
moby:~/test# docker-runc --debug --log /dev/stdout run testc

^C^C^C^C^C

^C^C^C^Z^Z

...so I have to reboot again.

And, yes, removing rootfsPropagation make it happy again.

This also makes the engine irresponsive for me to the point of having to reboot the host.

@cpuguy83 is there something to be done on our side, or is this a configuration issue of the host?

This looks like a misconfiguration. We should probably just block shared propagation when the host side is /
@errordeveloper Curious if mounting something other than / with shared is causing you any problems.

I don't think disallowing / is a good idea. First of all, it introduces behaviour that will be incompatible with 1.10 and 1.11. Second, in our use-case we ultimately need to set shared propagation on /var/lib/kubelet and we don't have an ability to provide a dedicated mount point here, and the RSHARED flag can only be set at the mount-point level and not just somewhere in the tree.
@cpuguy83 what would be the reason for blocking it on root mount point?

cc @mikedanese

I'm also seeing this, is this something that used to work and now doesn't?

@errordeveloper mount --bind /var/lib/kublet /var/lib/kublet && mount --make-shared /var/lib/kublet ought to do it.
I'll have to run some tests to see what might have changed.

Luke, this used to work in 1.10 and 1.11.
Brian, regarding misconfiguration, I don't think it is a misconfiguration
as such. First of all I initially noticed it on Docker for Mac. I also
found the same behaviour on official Boot2Docker rc2 ISO, provisioned by
Docker Machine. Regarding a bind-mount trick, I though it could do, but why
should I have to do that as it previously worked without.
Additionally, the error message is extremely obscure and comes across like
a very buggy thing. Please look into why it gets system into unusable
state, as I demonstrated with runc.
On Tue, 28 Jun 2016, 13:45 Brian Goff<EMAIL_ADDRESS>wrote:

@errordeveloper https://github.com/errordeveloper mount --bind
/var/lib/kublet /var/lib/kublet && mount --make-shared /var/lib/kublet
ought to do it.
I'll have to run some tests to see what might have changed.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker/docker/issues/23767#issuecomment-229037658,
or mute the thread
https://github.com/notifications/unsubscribe/AAPWS84rAwrJevaXfpuc0PfYIN2egIA4ks5qQRdLgaJpZM4I5w9i
.

@errordeveloper My point is mounting / into the container with shared propagation is the misconfiguration.
Why should you do it the way I described? Because that is what you actually need, rather than exposing the whole system in a horrible way.
Again, I'll take a look to see what may have changed.

Why should you do it the way I described?

Yes, it's not undoable... I am just advocating for this being a breakage, and worried about that more surprises are to come around this feature in the following releases.

Bumping this to P2 while I investigate where/how this might have broke.

ping @cpuguy83 did you have time to look into this?

@errordeveloper Curious how you set the mount to shared with docker4mac.

You can just nsenter the host mount namespace and change it.
On 12 Jul 2016 8:11 p.m., "Brian Goff"<EMAIL_ADDRESS>wrote:

@errordeveloper https://github.com/errordeveloper Curious how you set
the mount to shared with docker4mac.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/docker/docker/issues/23767#issuecomment-232148687,
or mute the thread
https://github.com/notifications/unsubscribe/AAdcPO1lpuEo1Lxs_rOVFV1KCnhwVHMhks5qU-bRgaJpZM4I5w9i
.

I did repro this on a "dirty" VM (lots of stuff having been thrown at it, custom docker builds, etc).
On a fresh VM I cannot repro.
@errordeveloper Do you have any other changes to your linux VM?

@cpuguy83 I've used Docker for Mac.

Any updates on this?

"pivot_root invalid argument"

Always reproducible  on travis
https://api.travis-ci.org/jobs/147375844/log.txt?deansi=true

flaky hanging issue

Not reproducible on travis
Reproducible on n1-standard-1 (single CPU core) and n1-standard-4 (4 CPU cores) GCE, Ubuntu 16.04

$ docker-runc --version
runc version 1.0.0-rc1
commit: cc29e3dded8e27ba8f65738f40d251c885030a28
spec: 1.0.0-rc1
$ uname -a
Linux ws01 4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

I am still not able to look into the hanging issue because when I hit it I cannot do SSH operation.
But looking at GCE's serial console log, some processes are killed due to OOM.
I'll try other environments and newer runc later

Even reproducible on fresh CentOS7
Even reproducible with latest runc (opencontainers/runc@8033a839758ab9a4ed4fb590d1bb005a1c5a164e)
Before whole the system gets stuck, I somehow captured some stacktraces:

$ ps auxw
...
root     20206  0.0  0.1  55760  4028 pts/2    S+   06:19   0:00 sudo /home/suda/WORK/runc/runc --debug --log /dev/stdout run testc
root     20207  0.0  0.2<PHONE_NUMBER>4 pts/2    Sl+  06:19   0:00 /home/suda/WORK/runc/runc --debug --log /dev/stdout run testc
root     20218 94.5  0.2 107152  7672 ?        Rsl  06:19   0:44 /home/suda/WORK/runc/runc init
...

$ sudo cat /proc/20207/stack # this does not provide useful info
[<ffffffff811004a2>] futex_wait_queue_me+0xc2/0x120
[<ffffffff811007b6>] futex_wait+0x116/0x280
[<ffffffff81102fa0>] do_futex+0x120/0x540
[<ffffffff81103441>] SyS_futex+0x81/0x180
[<ffffffff8182db32>] entry_SYSCALL_64_fastpath+0x16/0x71
[<ffffffffffffffff>] 0xffffffffffffffff

$ sudo cat /proc/20218/stack
[<ffffffff811b1bf2>] pcpu_alloc+0x4b2/0x670
[<ffffffff811b1de5>] __alloc_percpu+0x15/0x20
[<ffffffff8122d00f>] alloc_vfsmnt+0xcf/0x220
[<ffffffff8122d2cf>] clone_mnt+0x2f/0x320
[<ffffffff8122f119>] copy_tree+0x169/0x360
[<ffffffff8123d79b>] propagate_one+0x8b/0x1d0
[<ffffffff8123dc78>] propagate_mnt+0x98/0x150
[<ffffffff8122ea17>] attach_recursive_mnt+0x147/0x230
[<ffffffff8122eb58>] graft_tree+0x58/0x90
[<ffffffff81230394>] do_mount+0xc64/0xe00
[<ffffffff8123085f>] SyS_mount+0x9f/0x100
[<ffffffff8182db32>] entry_SYSCALL_64_fastpath+0x16/0x71
[<ffffffffffffffff>] 0xffffffffffffffff

Probably infinite loop here?

@cpuguy83 I ran into this a few times.
Client:
Version:      1.12.1
API version:  1.24
Go version:   go1.6.3
Git commit:   23cf638
Built:        Thu Aug 18 05:33:38 2016
OS/Arch:      linux/amd64
Server:
Version:      1.12.1
API version:  1.24
Go version:   go1.6.3
Git commit:   23cf638
Built:        Thu Aug 18 05:33:38 2016
OS/Arch:      linux/amd64

+1 ran into this as well cc @cpuguy83
# docker version
Client:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:
 OS/Arch:      linux/amd64

# docker info
Containers: 87
 Running: 0
 Paused: 0
 Stopped: 87
Images: 0
Server Version: 1.12.1
Storage Driver: devicemapper
 Pool Name: docker-202:1-26515821-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: xfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 4.055 GB
 Data Space Total: 107.4 GB
 Data Space Available: 103.3 GB
 Metadata Space Used: 10.76 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.137 GB
 Thin Pool Minimum Free Space: 10.74 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 WARNING: Usage of loopback devices is strongly discouraged for production use. Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.107-RHEL7 (2016-06-09)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: host null overlay bridge
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 3.10.0-327.28.3.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.451 GiB
Name: ip-10-0-172-60
ID: DVFN:54JE:I4I7:MPV6:IXQS:S56A:EERX:GHSW:YUKJ:5ONJ:GK6N:KHVX
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled
Insecure Registries:
 <IP_ADDRESS>/8

hey @cpuguy83 i still see this, kind of randomly on Ubuntu 16.04 as well. commands seem to run fine, then all of the sudden I get the following.
docker: Error response from daemon: oci runtime error: rootfs_linux.go:89: jailing process inside rootfs caused "pivot_root invalid argument".

If it is a configuration error it would be nice if docker handled this more gracefully. This happens sometimes when launching my containers with compose and when it happens you end up with a container marked DEAD and compose will refuse to work as it can't remove it. Removing the shared mount allows one to recover but is not obvious.
How does one setup the bind in fstab? I have my mounts marked shared there, do I need to add a second entry marked bind before it in the file?

Going to re-open since this is clearly an issue.
I think ultimately what we need to do here is setup mount namespaces with a separate process and pass down the namespace to runc.
The idea here would be to ensure mounts do not leak between namespaces, which right now depending on how you bind mount stuff can happen all over the place.
Ideally, imho, dockerd wouldn't even see the container's mounted fs.

@cpuguy83 99% of the time i dont get this error and im using the same systems (16.04 and CentOS 7) which I thought didnt need any special mount bind or mount make shared/ rshared. We did have to on other systems like 14.04.
Sot another question is, is there something we should always be doing regardless in the current state? Im not sure how or why i only see this 1% of the time or what causes it.
R

@errordeveloper we do this (https://github.com/docker/docker/issues/23767#issuecomment-229037658) on some of our systems but not all. Did your tests resolve your issues? I have not been able to reproduce this well enough on my systems.

I haven't tested, but likely any volume driver that sets mounts on the host
will have this problem, including my own
On Tue, Jun 28, 2016 at 3:30 AM, Ilya Dmitrichenko<EMAIL_ADDRESS>
wrote:

I don't think disallowing / is a good idea. First of all, it introduces
behaviour that will be incompatible with 1.10 and 1.11. Second, in our
use-case we ultimately need to set shared propagation on /var/lib/kubelet
and we don't have an ability to provide a dedicated mount point here, and
the RSHARED flag can only be set at the mount-point level and not just
somewhere in the tree.
@cpuguy83 https://github.com/cpuguy83 what would be the reason for
blocking it on root mount point?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/docker/docker/issues/23767#issuecomment-229012159,
or mute the thread
https://github.com/notifications/unsubscribe/AABJ64s9A66ri8htspQv39blXqBHS06Hks5qQPergaJpZM4I5w9i
.


Spider: PA Liquor Control Board

Spider Name:
pa_liquorboard
Website:
https://www.lcb.pa.gov/About-Us/Board/Pages/Public-Meetings.aspx

I'd like to do this one!

Fulfilled by this pull request


wip: update to<EMAIL_ADDRESS>

closes #622
closes #591

Tests are passing on v1.11 and v1.10.

Thanks for doing this!


Tooltip should have position "auto" to make the content stay inside the viewport.

Summary

What is the change?
Add clrPosition="auto" or make sure the tooltip will be always visible inside the viewport

Why should it go in Clarity?
We often have the problem tooltip position and have to set them case by case based on our UX to make sure content is always visible inside the viewport

Does this change impact existing behaviors? If so how?
Should not, just make it better for developer.

If this change introduces a new behavior, is this behavior accessible?

Same request for Signposts

Hope we can have something like Bootstrap placement=auto
https://getbootstrap.com/docs/4.1/components/tooltips/#options

This is a known issue. Please subscribe to these issues for updates: #1262 and #2683.
Closing as a duplicate.


change status_format to return an existing string as-is

Description

Right now, if status_format is called with a value that's a str, then it will recurse forever.
The initial isinstance(value,Iterable) is true for the iterable string, and it calls itself recursively for each character, which is also an iterable string, which calls status_format ad infinitum.
status_format() takes value and returns a friendly formatted string, so the change here simply returns an incoming string as-is.
My personal rationale here is so that I can override get_value() in a layer and co-opt the status bar to display, for instance, detailed information about a point when the mouse hovers over it, rather than simply displaying a coordinate and an index of the point.
While my status line usage can certainly be a point of discussion, the change here boils down to fixing a bug where this function will never return.
Type of change

[X] Bug-fix (non-breaking change which fixes an issue)

References

How has this been tested?

[X] passes all tests on my system except cli, which even the release 0.4.4 fails

Final checklist:

[X] I have added tests that prove my fix is effective or that my feature works - added test_status.py to _tests

Left a couple extra comments on the test, thanks again for the bug fix!!

@jni @sofroniewn this is my first PR to Napari, so let me know the workflow.  This is good to go as far as I'm concerned - I've addressed the comments.

Tests look great now!! Thanks so much for updating them I'll merge this now :-)


Add device option in recognize_whisper

Thank you!! When I set it to device='auto', there was an error, so I will always use cuda, so I just set it to device='cuda'.

Use load_options={"device": ...}


Add interruption of ZipUnarchiver

The Resource used for the ZipEntry in ZipUnarchiver did not allow for interruption because the Async[F].blocking call to the underlying ZipInputStream.closeEntry() is not interruptible and will block until the Entry in the ZipInputStream is read to the end.
Unfortunately signalling an interrupt to the ZipInputStream via Async[F].interruptible or Async[F].interruptibleMany` doesn't work either.
As a workaround we simply forgo closing the ZipEntry in case the resource is released for any other reason than ExitCase.Succeeded
Solves: https://github.com/lhns/fs2-compress/issues/113 though I'm not sure if this is an acceptable workaround.
Not sure how to easily test this in an automated test 🤔 . I have tested it with the program provided in #113 🤷

I should clarify, the ZipUnarchiver.unarchive pipe can probably be interrupted. Just not in the middle of unarchive a ZipEntry.

Very good catch! I would love to be able to test different cancelation scenarios though. Maybe I can throw a few tests together next week.


Support multipart/x-mixed-replace responses

This is needed to implement an MJPEG stream. A typical multipart response looks something like this.
HTTP/1.1 200 OK
Content-Type: multipart/x-mixed-replace; boundary=myboundary

--myboundary
Content-Type: image/jpeg
Content-Length: 12345

[image 1 encoded jpeg data]

--myboundary
Content-Type: image/jpeg
Content-Length: 45678

[image 2 encoded jpeg data]

At the moment I can't implement this outside the library because the Content trait mandates that I provide a content_length() and I don't think there's any public way to create a (custom) Response without a Content-Length header.
So I guess this has to implemented inside the library similar to SSE and WebSockets?
I'm imagining something like the EventStream struct, A MixedReplace struct that takes two parameters, a boundary string and a ContentSource trait. The ContentSource trait just allows the user to write new Contents. (I'm not 100% sure if Content is the right trait for this, was just my first thought)
Side note: Firefox seems to not mind a Content-Length atm, so specifying a value like 1000000 allows me to workaround this issue while developing and I'm able to stream small JPEGs with this.
(This library is fantastic btw! Thanks for building it and sharing it!)

multipart/x-mixed-replace seems very different to regular HTTP requests and responses, even things like SSE and websockets, so I don't think that I want an implementation in picoserve itself.
Originally I decided to be relatively restrictive with what sorts of responses could be produced, hence Response having private fields, and Response::new requiring a body of Content, which requires a known length and MIME type, as opposed to the more general Body, with no such restrictions. This was both for developer ergonomics, in that it avoided footguns to do with forgetting to send the relevant headers, but also helped prevent me coding myself into a corner and having major breaking changes.
However, now that picoserve has been out for a while with a relatively stable structure, and that I've implemented support for automatically handing the "Connection" header and Keep-Alive, it seems a good time to provide functionality to create unusual responses that don't follow the standard pattern.
Thus, I introduce  the CustomBody trait and CustomResponse struct, similar to SSE, WebSockets, and Chunked Transfer Encoding. You should be able to implement multipart/x-mixed-replace on top of it.
It's currently in the development branch, let me know if it works for you!

Yes CustomBody and CustomResponse let me implement multipart/x-mixed-replace. I just tried it and it works like a charm.
Now that Connection is no longer a parameter of write_content, how can I tell when the connection is closed? I used to have some cleanup logic with wait_for_disconnect.

Ah sorry, I misrepresented my problem.
My clean up logic is sync but even if I implement Drop, when I cancel the stream in the browser, the server hangs and hits a write timeout. During this hang time I can't handle more requests.
Ideally I'd like the write to be cancelled immediately, which I was previously doing myself by calling connection.wait_for_disconnect().

So, it seems that the cause of the delay (and then Write timeout) is due to the socket shutdown routine. The CustomBody is dropped as soon as the client disconnects, but then the write half of the socket is always flushed, which caused the delay and write timeout. The problem is that according to embassy net, you can't just close a socket, as the frame with the FIN flag set has not been sent, and they advise always flushing the write half.
I'm investigating possible alternative shutdown logic (and being generally a little confused at TCP :P ).

Well, that was an adventure!
While poking about, I found an error in the published version of embassy_net (it's fixed in main), and possibly another bug, though I'm not sure about the second.
I've a workaround, but can't publish it due to a git dependency, which crates.io disallows. Until the upstream bugfix is published, it'll have to remain in the newly created smart_shutdown branch.
Have a look, and hope it works for you!

Thanks for looking into it. I'll try and give it a whirl this weekend

Apologies for the late response but that commit does work for me, cancelling from the browser now immediately closes the connection on the server side. I can immediately handle other requests or restart the same request.
(I had to use the released/published versions of embassy)
Let me know once you've released it. This issue can be closed then.

Oh it's already released, I missed that. Thanks for the implementation! :heart:

@Dominaezzz I've removed the workaround as it's fixed upstream in embassy-net, are you OK to test the development branch (specifically e949baac424f0e32d65e58894c7ed9e31e4ec55b) to see if the connection is closed immediately?
My tests work, but it never hurts to have a second look...

ack, I'll give it a spin

Yup the connection is still closed immediately on the develop branch. Thanks!


MIN_CONTOUR_AREA should at least match the new default value in frigate

Version of the custom_component
HEAD, commit 4ba816ddc71a6e9b9ec5e5cd5bec9e20230d8fe0 (Sun Oct 22 19:36:36 2023 -0700)
Describe the bug
new default for contour_area is 10, and MIN_CONTOUR_AREA is set to 15 meaning we can't change the param to something less than 15
https://github.com/blakeblackshear/frigate/blob/591b91194a1346a3f1cbcb8b6fb6e674091242be/frigate/config.py#L291
https://github.com/blakeblackshear/frigate-hass-integration/blob/4ba816ddc71a6e9b9ec5e5cd5bec9e20230d8fe0/custom_components/frigate/const.py#L66

This is already fixed in the beta integration, will be merged to master when it is stable.


Bluetooth: LC3: Fix prefer and streaming context macros

Fix the BT_CODEC_LC3_META (prefer context) and
BT_CODEC_LC3_CONFIG_META (streaming context) macros, as
they did not properly set the right values due to missing
parenthesis.
Also added casts to uint8_t to avoid compiler warnings on
e.g. GCC when assigning a non uint8_t value to a uint8_t array.
Signed-off-by: Emil Gydesen<EMAIL_ADDRESS>

What about other place like here:
https://github.com/zephyrproject-rtos/zephyr/blob/a703cbe9ce1315f2460d86de7ee8a55190cf7995/include/zephyr/bluetooth/audio/lc3.h#L259-L267

Hmm, for some reason these do not give the same warning error when building for some reason. Possible the cast to uint8_t is not needed then?

Hmm, for some reason these do not give the same warning error when building for some reason. Possible the cast to uint8_t is not needed then?

Indeed, I guess that fix for missing brackets would be sufficient

Hmm, for some reason these do not give the same warning error when building for some reason. Possible the cast to uint8_t is not needed then?

Indeed, I guess that fix for missing brackets would be sufficient

Indeed. I'll try to remove the cast from my fixes in this PR and see if just adding the parenthesis is enough.

Updated multiple macros to follow the same style and to ensure correctness.

These macros should be updated with the SYS_ENCODE macros from https://github.com/zephyrproject-rtos/zephyr/pull/49683 at some point as well


Hl 963 ps

Description :sparkles:
Submitting an application manually as a handler does not create rows into thebf_calculation_paysubsidytable in the database, because the JSON payload it submits has an empty pay_subsidies list evaluates to notNonewhich causes a branch in the calculation logic to skip the database insert.  This PR  fixes the issue by checking if the application is submitted by a handler and then makes sure that pay_subsidy_data is None and pay_subsidies is is not present in the validated_data dict.
Issues :bug:
Testing :alembic:
Pytest: pytest applications/tests/test_handler_application.py
Manually: create a new application as  a handler and then as a handler process the application.
Screenshots :camera_flash:
Additional notes :spiral_notepad:

APPLICANT branch is deployed to platta: https://helsinkilisa-ui-pr2281.dev.hel.ninja :rocket::rocket::rocket:

TestCafe result is success for https://helsinkilisa-ui-pr2281.dev.hel.ninja :laughing::tada::tada::tada:

API branch is deployed to platta: https://helsinkilisa-pr2281.api.dev.hel.ninja/healthz :rocket::rocket::rocket:

APPLICANT branch is deployed to platta: https://helsinkilisa-ui-pr2281.dev.hel.ninja :rocket::rocket::rocket:

HANDLER branch is deployed to platta: https://helsinkilisa-ui-handler-pr2281.dev.hel.ninja :rocket::rocket::rocket:

TestCafe result is success for https://helsinkilisa-ui-pr2281.dev.hel.ninja :laughing::tada::tada::tada:

API branch is deployed to platta: https://helsinkilisa-pr2281.api.dev.hel.ninja/healthz :rocket::rocket::rocket:

HANDLER branch is deployed to platta: https://helsinkilisa-ui-handler-pr2281.dev.hel.ninja :rocket::rocket::rocket:

APPLICANT branch is deployed to platta: https://helsinkilisa-ui-pr2281.dev.hel.ninja :rocket::rocket::rocket:

TestCafe result is success for https://helsinkilisa-ui-pr2281.dev.hel.ninja :laughing::tada::tada::tada:


Rename from ReactionsRouter to ReachRouter

I assume internally it was named ReactionsRouter but soon rebranded to Reach so this updates rollup config and readme to use the new branding.

No problem. 👍


Add note chatbot not working in current excersize

Note for users on Part 1.7 excersize 3 to go to https://svelte.dev/tutorial/update instead

thank you!


Handle Proxy field in image registry spec.

We don't have handlers for the fields Proxy.HTTP and Proxy.HTTPS.

Just needs to set the proxy value using the appropriate registry env var on the registry deployment.


How to change code highlight style to monokai?

And maybe add a dark background color to the code segment.

https://github.com/olOwOlo/hugo-theme-even/blob/fd1b8d7bc8dcb84d008486562732fbba6b12adad/src/css/_partial/_post/_code.scss#L210-L282
You need to modify the corresponding scss code, see also Generate Syntax Highlighter CSS


Rename header links

Renaming the header links:

Remove home

there are no other internal pages so there's no where to get home from
there are no other internal pages so no other link could be highlighted
the logo is also a home link

Changed Docs to Book as I personally thought Docs would take me to the rust docs
Changed API to Docs as at least in a rust context I think this is what folks are expecting.
Removed the Documentation link below the tagline as it points to the book which is linked above

I totally get that these are my assumptions and that others have other assumptions. Created issue #14 with these thoughts in it figured I'd put up an implementation to see what folks think.
Existing:

After this PR:

Thanks so much. Sorry for the very slow response. I like the feedback about Home and the naming of the Docs/API to Book/Docs. Some other things have moved so I'm just making these changes in a different PR, but I appreciate the input!


Accept options for the command

Some helpful options might be:

print full stacktrace
no colors
pessimistic (bail after first failure)

This could be done similarly to how the parser's CLI handles options
https://github.com/tapjs/tap-parser/blob/master/bin/cmd.js -- no extra dependencies


v0.6.0-rc4 - udevd inotify_add_watch errors when booting: /dev/sda No such file or directory

RancherOS Version: v0.6.0-rc4
Where are you running RancherOS? VMWare ESXi (5 ish), and VMWare Fusion (8.1.1)
As per attached screenshot

udevd[24]: inotify_add_watch(6, /dev/sda, 10) failed: No such file or directory
udevd[15]: inotify_add_watch(6, /dev/sda1, 10) failed: No such file or directory

I do not see this issue in 0.5.0.
I haven't yet seen any side effects of this, other than it taking longer to boot my VM.
This is a fairly clean install, installed with:
sudo ros install -d /dev/sda -f -t generic -c ./cloud-config.yml

Good catch! Should be fixed in the next RC.

Confirmed with v0.6.0-rc5 that this issue is no longer present.

Yep. No longer an issue 👍


Allow specifying BIP32 Xpriv for root secret when building fedimint-client

Currently, fedimint-client is built using a random root secret as observed here:
https://github.com/fedimint/fedimint/blob/14f44c0f7890694bfb52e945c7a1d8c1f91c39f3/fedimint-client/src/lib.rs#L1681
The consumer who is building the client can choose between either a PlainRootSecretStrategy (which is just random 64 bytes) or Bip39RootSecretStrategy (which uses rust-bip39 crate to generate a random 12-word mnemonic and convert it to bytes).
Since fedimint-client is designed to be composable by other apps, front-ends, CLIs, etc. there arises a very valid use case whereby the thing that's composing fedimint-client would like to have control over the root secret for the fedimint-client instance.  In such a case, the CLI app might want to have its own root BIP-39 seed that the user backs up once, and be able to initialize fedimint-client instances using m/44'/0'/i' xpriv derivations where i would the index that the CLI app maintains internally for each fedimint-client instance.
To address such use cases, we propose:

adding a new RootSecretStrategy that utilizes the Xpriv type as the Encoding associated type.
enhancing the builder API for fedimint-client to allow specifying an Xpriv from which to obtain the root secret.

BIP39 utilizes ECC to be able to asymmetrically derive pub and priv keys, and my understanding is that because of that it's not suitable for general-purpose secret derivation. Or something like that.
https://github.com/fedimint/fedimint/blob/14f44c0f7890694bfb52e945c7a1d8c1f91c39f3/crypto/derive-secret/src/lib.rs#L7
Having said that DerivableSecret::new_root could be initialized with about anything random, so it should be possible for the outer application to derive the secret how it sees fit and pass it to fedimint-client instance.
I don't remember the details of the Encoding thing ... let me look around.

Doesn't PlainRootSecretStrategy already allow it?

Thanks for the comments @dpc

Having said that DerivableSecret::new_root could be initialized with about anything random, so it should be possible for the outer application to derive the secret how it sees fit and pass it to fedimint-client instance.

This is accurate. So is your suggestion to just bypass the RootSecretStrategy trait altogether for the use case that I mentioned, and make fedimint-client be able to directly take a DerivableSecret?

Doesn't PlainRootSecretStrategy already allow it?

AFAICT, PlainRootSecretStrategy necessitates that the Encoding be 64 bytes. So if a composer of fedimint-client did want to use BIP-32 Xpriv's those would are 78 bytes (or anything else that's not 64 bytes for that matter).

approach ack

not sure if this makes sense or is too restrictive/cumbersome for the use case, but the DerivableSecret seems to follow a similar idea of derivation paths with the child_key pattern. Could there be a way to "map" the BIP32 derivation structure onto the DerivableSecret directly?
Your approach seems simple enough... but just wondering since the client is already capable of deriving child keys after the root secret is seeded with any random bytes (could be BIP39 mnemonic) maybe there's a way that they mesh together
For example a bitcoin wallet app that already uses BIP32 to derive keypairs could just seed the fedimint client with the same root entropy but then still be able to reason about which derivation paths are being used for each federation's ecash?
Almost seems like BIP39 was implemented directly into fedimint/crypto/derive-secret already but it's not 100% clear how to adapt it

after reading BIP32 + 43 + 44 more thoroughly, I think my musings above ^ are mostly irrelevant
but if you do go with a Bip32RootSecretStrategy, maybe it would be good to recommend in the code comments what derivation path a composer might use...
for example existing bitcoin HD wallets may wonder whether to use m/44'/0'/i' but if they are already using that convention for normal wallet accounting and don't want to expose the chain of secrets to another piece of software like fedimint, it might be more prudent to use a derivation space with a different BIP44 cointype like `m/44'/100000'/i'
or perhaps if BIP44 isn't relevant to how fedimint uses this secret maybe a different BIP43 purpose value should be used like m/54321'/0'/i'

So is your suggestion to just bypass the RootSecretStrategy trait altogether for the use case that I mentioned, and make fedimint-client be able to directly take a DerivableSecret?

I guess this isn't really doable with the current architecture because fedimint-client stores the secret material (what is represented by a RootSecretStrategy's Encoding), and not the DerivableSecret itself—and there wouldn't be a way to go backwards.

but if you do go with a Bip32RootSecretStrategy, maybe it would be good to recommend in the code comments what derivation path a composer might use...

Good point! Different purpose or cointype seems prudent.

I guess the problem is that right now fedimint-client stores the secret material from which the DerivableSecret is generated—not the DerivableSecret itself. So while DerivableSecret itself can be an arbitrary number of bytes, the secret material needs a corresponding RootSecretStrategy whereby the type of the secret material is strictly specified as an encoded type. So if we want to work with the current architecture, we'd either have to:

make a "bring your own secret material" compatible with PlainRootSecretStrategy which means the secret material must be 64 bytes
make a "bring your own secret material" compatible with Bip39RootSecretStrategy which means the secret material must be a 12-word mnemonic
write a new RootSecretStratgy that serves our purpose better

I do think HD derivation is the way to go as far as an external composer is concerned. So I'm tempted to play within those constraints. Xprivs are 78 bytes which doesn't work with option 1. But we could only take the first 64 bytes?
I don't see how option 2 would work.
Option 3 was my initial proposal but maybe it needs to be based on something else besides xprivs. If we make PlainRootSecretStrategy take a vec of bytes as the secret material maybe that would serve more use cases?

Discussed offline with @justinmoon

What if we had a Runtime secret strategy that doesn't store anything and just requires caller to pass in a DerivableSecret themselves?

Interesting.. so does that mean that every time fedimint-client is initialized, the DerivableSecret would need to be provided from outside? So we're fully absolving fedimint-client of secret storing/generation?

Yes. I think that makes most sense to me. If we want to generate and store 1 seed externally to fedimint-client, I don't think fedimint-client should retain any responsibities for generating and storing secrets in this usecase.

make a "bring your own secret material" compatible with PlainRootSecretStrategy which means the secret material must be 64 bytes

This is always easy by either trimming or stretching (hash, then trim it to size) the existing key material. Secret material need only to be deterministic. Reversability to the original form is not strictly required.

What if we had a Runtime secret strategy that doesn't store anything and just requires caller to pass in a DerivableSecret themselves?

I'm not sure about the details and it might need some refactoring, but yes. Fedimint client library handling persisting secrets should be an convenient options, but not a requirement.

@dpc and I had a long conversation where we decided on this approach:

make the ClientBuilder's build() methods take as input a DerivableSecret
provide an external function on ClientBuilder to store the input secret material as encoded bytes in the DB
provide an external function on ClientBuilder to load the decoded input secret material from the DB
The store/load functions are meant to be called before build()
Consumer of fedimint-client can decide whether it wishes to leverage fedimint-client's DB for the purpose of storing the encoding input secret material
In either case, the client is always built with DerivableSecret which gives consumers max flexibility
All the different RootSecretStrategies then become unnecessary. They may be moved to fedimint-cli as reference for consumers who may wish to use the encoding types specified by those strategies.

DPC identified that the heart of the issue lies in the fact that the client, when building itself, is also attempting to generate+save/load the input secret material from its DB. This results in the build() methods being generic over some S: RootSecretStrategy. So if we can provide saving/loading the input secret material as a side-API (and not as a side-effect of calling build), we can remove S bound from the build() methods and make them take in a DerivableSecret.


feat: is_allocated()

In addition: rename add() to allocate()
Closes: #25
Signed-off-by: Jarkko Sakkinen<EMAIL_ADDRESS>

Added unit tests.

@npmccallum, I need this for heap. Even if there is a proper find mechanism in place, this function benefits from its own implementation given that it does not care about order. This works for my use case perfectly.

@npmccallum issues resolved

Updated to use is_ok_or_err().

Updated to unwrap_or_else().

clean up. I think it is now quite polished. @npmccallum

Usage example:
    fn is_allocated(&self, index: usize) -> bool {
        self.is_allocated_range(index..index)
    }

    fn is_allocated_range(&self, range: core::ops::Range<usize>) -> bool {
        self.ledger.is_allocated(Region::new(
            Address::new(range.start * size_of::<Page>()),
            Address::new(range.end * size_of::<Page>()),
        ))
    }

@npmccallum now it is only is_allocated(), and also separate issue created.

just rebased to latest mainline

not a priority, I can do this internally for enarx for now (and not aligned what I said of not adding seek's before enarx is done).


cloud map error

Source map error: request failed with status 404 Resource URL: https://uicdn.toast.com/tui-calendar/latest/tui-calendar.js

We don't provide map files yet. Do you need the map for debugging? I suggest that use minified file or use a npm package.


Suggestion: ability to define return type based on property of an interface

One of the common idioms in JavaScript is using a getter function that takes string of a property name of an object and returns the value of the property. For example:
var obj = {a: 1, b: '2'};
var model = new Backbone.Model(obj);
var a = mode.get('a'); // a is number

Right now, the get function can only be defined as returning any, because we can't annotate it with anything better. It would be nice to be to define the return type based on the properties of an interface for example:
declare interface Model {
  a: number;
  b: string;
}
declare function get<T as Model[keyArg]>(keyArg: string): T; // syntax is for conveying idea only

get('a'); // number
get('b'); // string
get('c'); // any

declare function get2<T, T2 as T[keyArg]>(keyArg: string): T2; // generic version

get2<Window>('setTimeout'); // function
get2<Window>('nonsense'); // any

declare function get3<T as Model[keyArg]>(keyArg: any): T; // compile error, only support string and maybe number.

declare function set<T as Model[keyArg]>(keyArg: string, value: T): void; // set syntax for the same thing

This would allow better definitions a lot of functions in common libraries like Lodash/Underscore, Immutable.js, Backbone.

Currently TypeScript supports specialized overload signature. For example
declare function get(key: string): any;
declare function get(key: 'key'): string;

The suggestion above can already be partially implemented at application level by using specialized overload signature with code generator. The suggestion would allow this to be implemented more generally (especially for libraries).

Potential implementation may also be used to refine  { [key: string]: someType }, but that might be more complex as it requires self referencing.

I think something like function get(keyArg: string): typeof Model[keyArg];  is a better syntax. I support this suggestion.

Duplicate #1295?

Yes it is. Closing


Seems like the implementation of the ap is incorrect

Hello!
I was playing around with the Task type and I have discovered that there's something wrong with the implementation of ap. Here is my snippet:
var Task = require('data.task');

var readToTask = (delay, resData) => new Task((rej, res) => isNaN(delay) ? res(resData) : setTimeout(res, delay, resData));

var lift2 = (f, m1, m2) => m1.ap(m2.map(f));

var join = s1 => s2 => s1 + ' : ' + s2;

var program = () =>
    lift2(join, readToTask(1000, 'm1'), readToTask(NaN, 'm2'))

var program2 = () =>
    readToTask(1000, 'm1').chain(p1 =>
        readToTask(NaN, 'm2').map(p2 =>
            join(p1)(p2)
        )
    )

var program3 = () =>
    readToTask(1000, 'm1').ap(readToTask(NaN, 'm2').map(join))

program().fork(console.error, console.log); // func is not a function
program2().fork(console.error, console.log); // works
program3().fork(console.error, console.log); // func is not a function

It could be that I am doing something wrong since there was a major release. I can't check it with 2.x versions as npm can't find any. Unfortunately, I haven't had a chance to dig into the implementation.

Ah, I can see why this would be confusing.
Fantasy Land 0.x had the interface:
interface Applicative<F>
  <A, B> ap(this: F<A => B>, F<A>): F<B>

So you'd write it using:
Task.of(a => b => a + ' : ' + b).ap(Task.of('x')).ap(Task.of('y'));

data.task only implements this interface, which was the only one at the time.
Later in the 0.x branch, Fantasy Land changed the type of the Applicative interface like this:
interface Applicative<F>
  <A, B> ap(this: F<A>, F<A => B>): F<B>

Which gives you:
Task.of('x').ap(Task.of('y').ap(f))

This was a breaking change, but then Fantasy Land 1.x was released with prefixed names:
interface Applicative<F>
  <A, B> "fantasy-land/ap"(this: F<A>, F<A => B>): F<B>

The new Folktale Task implements both, so you have:
Task.ap :: <A, B>(this: Task<A => B>, Task<A>): Task<B>
Task['fantasy-land/ap'] :: <A, B>(this: Task<A>, Task<A => B>): Task<B>

This article describes how to migrate from data.task to the new folktale library http://folktale.origamitower.com/docs/v2.0.0/migrating/from-data.task/

thank you @robotlolita I'll definitely give it a try!

Well, I ended up using ramda's lift as it uses prefixed names. It works rather good! Thank you!


Removing semicolons

Woops, looks like I accidentally re-inserted the semicolons in the code snippets that MJ had already removed earlier today. My bad.

thanks!


Nothing working…

Bug description
Pure garbage. I tried to load 3 different models on 2 different machines (linux, mac) and not a single one worked out of the box…issues with litdata, Nonetype bla bla bla. Annoying as hell.
What operating system are you using?
Unknown
LitGPT Version

Hello @degen2
It would be nice if you could provide examples of commands that you tried to run and what error messages did you get (with a full stack trace).
Meanwhile, are you sure that the problem is not on your side, i.e. did you use a clean virtual environment to install LitGPT?
One of the options is to use a fresh Studios, or you can even reuse this Studio template.
If you want to use your local machine, please check this tutorial and make sure that you've done all the steps from it.


part value types

When I write
<button @click=${e => console.log(e.detail.value)} />
obviously, TypeScript doesn't know about the type of the callback. I'm not sure whether here or on the TypeScript issue tracker is a good place to discuss this, but can we somehow make this happen? If someone has a good pointer for me how to achieve this, I'll gladly make a proof of concept repo.

lit-html template is basically a string, so it is impossible to get any types from it until Typescript adds support for lit-html. However, due to the string nature of HTML and all tricks hidden under the hood of the web components, I hardly believe they're going to do it eventually.
You can try in Typescript issue tracker though. Please provide a link to your issue, I would like to follow it as well.

Personally, I'm going to use simple typing like following:
<button @click=${(e: CustomEvent<EventDetailType>) => console.log(e.detail.value)} />

shouldn't it be possible to infer Type just by knowing that it's an event handler though? Can TypeScript plugins interpret surrounding strings?

See this discussion in the TypeScript repo: https://github.com/Microsoft/TypeScript/issues/29432
We have designs to allow type checking, but it's going to require collaboration between the teams.
Going to close this as we need tsc feature first, but I'll open a design issue for type-checking soon.


Extend the margin between OCF and FNF logos in the homepage footer

Summary
It's a bit too narrow for both OCF and FNF logos in the homepage footer
Proposed solution
Extend the margin to 30px between two logos.

Desktop: increase gap between two logos to 30px
Mobile increase gap to top&bottom to 10px and gap between to 20px


[DataPipe] Ensures Prefetcher shuts down properly

Stack from ghstack:

-> #1166

Differential Revision: D45967152

@nivekt has imported this pull request.  If you are a Meta employee, you can view this diff on Phabricator.

@nivekt has imported this pull request.  If you are a Meta employee, you can view this diff on Phabricator.

@nivekt has imported this pull request.  If you are a Meta employee, you can view this diff on Phabricator.

@nivekt has imported this pull request.  If you are a Meta employee, you can view this diff on Phabricator.

@nivekt has imported this pull request.  If you are a Meta employee, you can view this diff on Phabricator.

@nivekt has imported this pull request.  If you are a Meta employee, you can view this diff on Phabricator.

@nivekt has imported this pull request.  If you are a Meta employee, you can view this diff on Phabricator.


defmt-print: remove supported version from help output

As mentioned by @japaric in https://github.com/knurling-rs/probe-run/pull/133 , https://github.com/knurling-rs/probe-run/issues/131 applies to defmt-print too.
Modification should probably take place in https://github.com/knurling-rs/defmt/blob/574f77f05f0d72f905c8955cb7a652fb4f91726e/print/src/main.rs#L95
Opening this as another issue so we don't forget.

PR #352 will fix this

PR #352 will fix this

oh whoops

oh whoops

#352 was merged

#352 was merged


Next.js middleware sometimes doesn't have a user session after signin

Bug report
Describe the bug
So I have a Next.js app with middleware to protect certain routes.
This is what the middleware looks like:
import { createMiddlewareSupabaseClient } from '@supabase/auth-helpers-nextjs';
import { NextRequest, NextResponse } from 'next/server';

export async function middleware(req: NextRequest) {
  const res = NextResponse.next();
  const supabase = createMiddlewareSupabaseClient({ req, res });

  const {
    data: { session },
  } = await supabase.auth.getSession();

  if (!session) {
    const redirectUrl = req.nextUrl.clone();
    redirectUrl.pathname = '/auth/signin';
    redirectUrl.searchParams.set(`redirectedFrom`, req.nextUrl.pathname);
    return NextResponse.redirect(redirectUrl);
  }

  return res;
}

export const config = {
  matcher: ['/app/:path*'],
};

On my signin page I have an effect to redirect the user after successful signin:
useEffect(() => {
    const {
      data: { subscription },
    } = supabaseClient.auth.onAuthStateChange((event) => {
      if (event === 'SIGNED_IN') router.replace(redirectAfterSignin);
    });

    return () => subscription.unsubscribe();
  }, [supabaseClient, redirectAfterSignin]);

For some reason (and sorry not being able to define this more concrete) sometimes the middleware redirects back to signin even though the user was signed in successfully before. It seems like the token is maybe not set yet or not sent correctly. But I don't really know.
This app is being deployed on Vercel and the error only occur on production deployment.

Before the calling router.replace in your useEffect, try clearing the Next.js client-side cache:
https://github.com/clerkinc/javascript/blob/712c8ea792693a335d9bf39c28e550216cb71bcb/packages/nextjs/src/client/invalidateNextRouterCache.ts

Seems like this really fixed the issue! Thanks so much for your tip, Colin!
Maybe we should mention this somewhere in the docs ?

@colinclerk how would this work on a <Link> instead of programmatically? I found that I had to change my <Link> to a <a> instead to get this to work but if there is a more nextjs kind of way I would love to learn that way.

You want to run the cache-busting snippet any time the user signs in or signs out. I think if you can identify those moments in time using onAuthStateChange per Jonathan's snippet above


Compute release 2024-10-29

we need to merge several fixes before release.
i will open another release PR, when they are ready


Open T&C etc. in a new tab and set a page/category instead of the layout

Description
It would be nice to not just allow T&Cs etc. to be used using a modal but also allow it to open a full page. This, however, would require a category to be assigned instead of just the layout and it should be optional.

Hello,
Within our company roadmap and work capacity, we try to address each bug or improvement request but admit that not each one will be resolved. To continue our culture of honesty and openness, we are closing this issue to focus on our roadmap on behalf of all Shopware users.
If you feel like this issue is still impacting you, please create a new issue and let us know.
Thank you again for your valuable feedback.


[Installer] use bootstraped installer to continue bootstrap

What does this PR do?

Make the bootstraped installer load systemd
Only load systemd installer units without starting

Motivation

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

/merge


Query: GroupBy aggregate failure when key property is also part of Elementselector

        [ConditionalFact]
        public virtual void GroupBy_Key_element_clash()
        {
            AssertQuery<Order>(
                os => os.GroupBy(o => o.OrderID, o => new { o.OrderID, o.OrderDate })
                        .Select(g => new
                        {
                            g.Key,
                            Avg = g.Average(e => e.OrderID),
                            Max = g.Max(o => o.OrderDate)
                        }));
        }

@smitpatel @anpete @maumar Let's discuss this one again in triage tomorrow with specific focus on risk for patching. /cc @divega

Re-triage: We are not going to patch this because there is some risk in the fix and there is a good workaround: remove the o => new { o.OrderID, o.OrderDate } projection, since with translation to the server it will result in the same query being generated and the same data being returned.
[ConditionalFact]
        public virtual void GroupBy_Key_element_clash()
        {
            AssertQuery<Order>(
                os => os.GroupBy(o => o.OrderID)
                        .Select(g => new
                        {
                            g.Key,
                            Avg = g.Average(e => e.OrderID),
                            Max = g.Max(o => o.OrderDate)
                        }));
        }


Report fix

Codecov Report
Attention: 68 lines in your changes are missing coverage. Please review.

Comparison is base (3e1f9d1) 55.41% compared to head (d7eef43) 55.20%.

Files
Patch %
Lines

...llig/teststep/processor/http/model/HttpTestStep.kt
0.00%
9 Missing :warning:

...er/junit/report/model/TestScenarioReportDetails.kt
27.27%
5 Missing and 3 partials :warning:

...ellig/teststep/processing/model/DefaultTestStep.kt
14.28%
0 Missing and 6 partials :warning:

...llig/runner/junit/report/SkelligReportGenerator.kt
80.00%
2 Missing and 3 partials :warning:

...runner/junit/report/model/TestStepReportDetails.kt
73.68%
2 Missing and 3 partials :warning:

...ig/teststep/processing/util/PropertyFormatUtils.kt
54.54%
1 Missing and 4 partials :warning:

...ig/teststep/processor/ibmmq/model/IbmMqTestStep.kt
0.00%
4 Missing :warning:

...kellig/teststep/processor/rmq/model/RmqTestStep.kt
0.00%
4 Missing :warning:

...kellig/teststep/processor/tcp/model/TcpTestStep.kt
0.00%
4 Missing :warning:

.../runner/junit/report/model/FeatureReportDetails.kt
0.00%
0 Missing and 2 partials :warning:

... and 9 more

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff              @@
##             master      #54      +/-   ##
============================================
- Coverage     55.41%   55.20%   -0.22%
- Complexity     1290     1301      +11
============================================
  Files           248      249       +1
  Lines          7079     7146      +67
  Branches        927      957      +30
============================================
+ Hits           3923     3945      +22
- Misses         2760     2790      +30
- Partials        396      411      +15

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


feat: support skipCollectors in advanced mode blueprint

Summary
Add support for skipCollectors in Advanced mode blueprint
draft PR for demo and discussion
Does this close any open issues?
Closes #6088
Screenshots
Include any relevant screenshots here.
Other Information
Any other information that is important to this PR.

@leric Is this done? It’s still draft

will be resoloved by other pr.