text:
Can't free space for files used COPY or ADD in Dockerfile

When use COPY or ADD instruction in Dockerfile to copy files from host to images.  But when removed the copied file, it would not free the space.
I tested this in two ways:
1. do rm in Dockerfile

Dockerfile

FROM ubuntu:14.04

MAINTAINER gavincook <swbyzx@gmail.com>

COPY jdk.tar.gz test.tar.gz

RUN rm -f jdk.tar.gz

Comment: the jdk.tar.gz in my local is 154MB
Then i build image based on this Dockerfile, then the image size is: 349.3MB, while the ubuntu:14.04 image only 188.4MB. So it not free the space really when do rm operation.
2. do rm in interactive container

Dockerfile

FROM ubuntu:14.04

MAINTAINER gavincook <swbyzx@gmail.com>

COPY jdk.tar.gz jdk.tar.gz

build image in docker build -t test ., then run interactive container: docker run --rm -it test /bin/bash, i typed df -h in the interactive container, got:
Filesystem      Size  Used Avail Use% Mounted on
rootfs          9.8G  7.2G  2.1G  78% /
none            9.8G  7.2G  2.1G  78% /
tmpfs           3.9G     0  3.9G   0% /dev
shm              64M     0   64M   0% /dev/shm
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/xvdb1      9.8G  7.2G  2.1G  78% /etc/hosts
tmpfs           3.9G     0  3.9G   0% /proc/kcore
tmpfs           3.9G     0  3.9G   0% /proc/latency_stats
tmpfs           3.9G     0  3.9G   0% /proc/timer_stats

ls -Shall got:
-rw-r--r--   1 root root 154M Sep  2 10:43 jdk.tar.gz
drwxr-xr-x  34 root root 4.0K Nov 10 06:07 .
drwxr-xr-x  34 root root 4.0K Nov 10 06:07 ..
drwxr-xr-x   2 root root 4.0K Aug 14 08:34 bin
drwxr-xr-x   2 root root 4.0K Apr 10  2014 boot
drwxr-xr-x  64 root root 4.0K Nov 10 06:07 etc
drwxr-xr-x   2 root root 4.0K Apr 10  2014 home
drwxr-xr-x  12 root root 4.0K Aug 14 08:33 lib
drwxr-xr-x   2 root root 4.0K Aug 14 08:33 lib64
drwxr-xr-x   2 root root 4.0K Aug 14 08:32 media
drwxr-xr-x   2 root root 4.0K Apr 10  2014 mnt
drwxr-xr-x   2 root root 4.0K Aug 14 08:32 opt
drwx------   2 root root 4.0K Aug 14 08:34 root
drwxr-xr-x   7 root root 4.0K Aug 14 08:33 run
drwxr-xr-x   2 root root 4.0K Aug 20 20:21 sbin
drwxr-xr-x   2 root root 4.0K Aug 14 08:32 srv
drwxrwxrwt   2 root root 4.0K Aug 14 08:34 tmp
drwxr-xr-x  11 root root 4.0K Aug 20 20:21 usr
drwxr-xr-x  12 root root 4.0K Aug 20 20:21 var
drwxr-xr-x   5 root root  380 Nov 10 06:07 dev
-rwxr-xr-x   1 root root    0 Nov 10 06:07 .dockerenv
-rwxr-xr-x   1 root root    0 Nov 10 06:07 .dockerinit
dr-xr-xr-x 158 root root    0 Nov 10 06:07 proc
dr-xr-xr-x  13 root root    0 Nov 10 06:07 sys

Then use rm -f jdk.tar.gz to delete the jdk.tar.gz, use ls -Shall, got:
drwxr-xr-x  34 root root 4.0K Nov 10 06:10 .
drwxr-xr-x  34 root root 4.0K Nov 10 06:10 ..
drwxr-xr-x   2 root root 4.0K Aug 14 08:34 bin
drwxr-xr-x   2 root root 4.0K Apr 10  2014 boot
drwxr-xr-x  64 root root 4.0K Nov 10 06:07 etc
drwxr-xr-x   2 root root 4.0K Apr 10  2014 home
drwxr-xr-x  12 root root 4.0K Aug 14 08:33 lib
drwxr-xr-x   2 root root 4.0K Aug 14 08:33 lib64
drwxr-xr-x   2 root root 4.0K Aug 14 08:32 media
drwxr-xr-x   2 root root 4.0K Apr 10  2014 mnt
drwxr-xr-x   2 root root 4.0K Aug 14 08:32 opt
drwx------   2 root root 4.0K Aug 14 08:34 root
drwxr-xr-x   7 root root 4.0K Aug 14 08:33 run
drwxr-xr-x   2 root root 4.0K Aug 20 20:21 sbin
drwxr-xr-x   2 root root 4.0K Aug 14 08:32 srv
drwxrwxrwt   2 root root 4.0K Aug 14 08:34 tmp
drwxr-xr-x  11 root root 4.0K Aug 20 20:21 usr
drwxr-xr-x  12 root root 4.0K Aug 20 20:21 var
drwxr-xr-x   5 root root  380 Nov 10 06:07 dev
-rwxr-xr-x   1 root root    0 Nov 10 06:07 .dockerenv
-rwxr-xr-x   1 root root    0 Nov 10 06:07 .dockerinit
dr-xr-xr-x 158 root root    0 Nov 10 06:07 proc
dr-xr-xr-x  13 root root    0 Nov 10 06:07 sys

It seems the jdk.tar.gz already deleted, but when i use df -h, i got:
Filesystem      Size  Used Avail Use% Mounted on
rootfs          9.8G  7.2G  2.1G  78% /
none            9.8G  7.2G  2.1G  78% /
tmpfs           3.9G     0  3.9G   0% /dev
shm              64M     0   64M   0% /dev/shm
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/xvdb1      9.8G  7.2G  2.1G  78% /etc/hosts
tmpfs           3.9G     0  3.9G   0% /proc/kcore
tmpfs           3.9G     0  3.9G   0% /proc/latency_stats
tmpfs           3.9G     0  3.9G   0% /proc/timer_stats

The space status is same before we do rm jdk.tar.gz , Why the space for jdk.tar.gz file space not freed?
BTW, here are something about my enviroment:
docker version:
Client:
 Version:      1.8.1
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   d12ea79
 Built:        Thu Aug 13 02:35:49 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.1
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   d12ea79
 Built:        Thu Aug 13 02:35:49 UTC 2015
 OS/Arch:      linux/amd64

docker info:
Containers: 8
Images: 185
Storage Driver: aufs
 Root Dir: /mnt/docker/aufs
 Backing Filesystem: extfs
 Dirs: 201
 Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-32-generic
Operating System: Ubuntu 14.04.1 LTS
CPUs: 2
Total Memory: 7.797 GiB
Name: iZ238zkde0vZ
ID: PBCE:ENDQ:IBFB:IEN5:SEWL:44WY:NDTP:T7D6:I5MV:X2ZZ:DPEQ:HNFS
Username: gavincook
Registry: https://index.docker.io/v1/
WARNING: No swap limit support

uname -a:
Linux iZ238zkde0vZ 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

See https://docs.docker.com/engine/introduction/understanding-docker/#how-does-a-docker-image-work
Once an image layer is created, you can't modify it. Modifying the contents of the filesystem just creates a new layer on top of the old one.

Yes, this is expected behavior, but I understand it's confusing if you're unfamiliar with the way the layers work in Docker.
I'm closing this issue, because it's not a bug, but feel free to comment her after I've closed.

authors: gavincook phemmer thaJeztah

repo: docker/docker


text:
unexpected EOF on docker build

I ran into the issue on Docker 1.9.1
All issues related to this are from 2014, is the problem back ?
Ref https://github.com/docker/docker/issues/4117
Seems to be related to connexion lost with the hub, it's kind of weird.
I say this because I also have this problem, that I never had before.
docker login
Username (***):
Error response from daemon: 404 page not found

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

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

It was intermittent, but it seems the problem has gone away for now.

source: gharchive/issue

authors: GordonTheTurtle JnMik

license_type: permissive

license_source: github-api


text:
t

Output of docker version:
(paste your output here)

Output of docker info:
(paste your output here)

Additional environment details (AWS, VirtualBox, physical, etc.):
Steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Additional information you deem important (e.g. issue happens only occasionally):

seems like a typo

authors: duglin nktl


text:
Cannot mount symlink as volume unless owned by root

Output of docker version:
Client:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.7
 Git commit:   23cf638
 Built:        Fri Aug 19 02:03:02 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.7
 Git commit:   23cf638
 Built:        Fri Aug 19 02:03:02 2016
 OS/Arch:      linux/amd64

Output of docker info:
Containers: 17
 Running: 2
 Paused: 0
 Stopped: 15
Images: 42
Server Version: 1.12.1
Storage Driver: btrfs
 Build Version: Btrfs v4.7
 Library Version: 101
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: host bridge null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.7.2-1-ARCH
Operating System: Arch Linux
OSType: linux
Architecture: x86_64
CPUs: 6
Total Memory: 15.59 GiB
Name: bs
ID: Z7DX:2XOG:LKMA:JLP3:P3DJ:IKYS:T7LY:LFH4:G4G4:VOBX:HT6O:FQSN
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Insecure Registries:
 127.0.0.0/8

Additional environment details (AWS, VirtualBox, physical, etc.):
Archlinux desktop
Steps to reproduce the issue:
0. su user

ln -s /home/user /tmp/tmp
docker run -it -v /tmp/tmp:/home/user container

Describe the results you received:
docker: Error response from daemon: mkdir /tmp/tmp: file exists.
Describe the results you expected:
Running container.
Additional information you deem important (e.g. issue happens only occasionally):
Everything works fine as long as the symlink is create as a root. It stops working when it's created as a regular user.

sorry, duplicate of #21055


text:
Mounting FUSE should be possible with Docker Swarm Mode

Description
I'd like to mount filesystem using FUSE inside container when it starts, but this doesn't seem to be possible in Docker Swarm Mode.
In particular, I want to mount ceph-fuse.
Ideally, following should work (it actually works with version: '2' after scaling Ceph's nodes to 3+ instances):
# docker-compose.yml
version: '3.1'
services:
  consul:
    image: nazarpc/webserver:consul
    restart: always

  ceph-mon:
    image: nazarpc/webserver:ceph
    command: mon
    restart: always

  ceph-osd:
    image: nazarpc/webserver:ceph
    command: osd
    restart: always

  ceph-mds:
    image: nazarpc/webserver:ceph
    command: mds
    restart: always

  nginx:
    image: nazarpc/webserver:nginx
    restart: always
    environment:
      CEPHFS_MOUNT: 1
# In order to access FUSE
    devices:
      - /dev/fuse:/dev/fuse
# In order to mount CEPHFS
    cap_add:
      - SYS_ADMIN

However, both devices and cap_add are not allowed with v3 of docker-compose.yml file format, which in turn seems to be limited by Docker Engine itself.
Steps to reproduce the issue:

Mount ceph-fuse in container running with Docker Swarm Mode

Describe the results you received:
Mounting fails
Describe the results you expected:
Mounting should be possible somehow
Output of docker version:
Client:
 Version:      1.13.1
 API version:  1.26
 Go version:   go1.7.5
 Git commit:   092cba3
 Built:        Wed Feb  8 06:57:21 2017
 OS/Arch:      linux/amd64

Server:
 Version:      1.13.1
 API version:  1.26 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   092cba3
 Built:        Wed Feb  8 06:57:21 2017
 OS/Arch:      linux/amd64
 Experimental: false

Output of docker info:
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 28
Server Version: 1.13.1
Storage Driver: btrfs
 Build Version: Btrfs v4.7.3
 Library Version: 101
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: aa8187dbd3b7ad67d8e5e3a15115d3eef43a7ed1
runc version: 9df8b306d01f59d3a8029be411de015b7304dd8f
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.10.0-8-generic
Operating System: Ubuntu Zesty Zapus (development branch)
OSType: linux
Architecture: x86_64
CPUs: 12
Total Memory: 15.57 GiB
Name: nazar-pc
ID: 3RNU:FHWJ:O265:QXAO:Y276:CZXJ:Z3XR:LP6O:POQW:MRRC:PK44:BP2K
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Just to clarify a little bit on what I'm trying to achieve: the goal is to have distributed storage implemented inside of containers that doesn't need privileged access to Docker Engine and doesn't need basically any manual configuration in simplest cases besides generic declarative docker-compose.yml.
I've seen Infinit acquisition, but it is not integrated deeply and as easy to use as overlay for networking yet.

It might be easier to use a volume plugin, eg see the example sshfs fused based volume plugin here https://github.com/vieux/docker-volume-sshfs as an example, writing a ceph plugin should be fairly simple.
Adding device support is on the roadmap see the functionality parity issue for details https://github.com/docker/docker/issues/25303

It is not easier to use volume plugin, since Ceph needs to be configured upfront manually and is not a part of services declaration in contrast to simple docker-compose up -d.
Writing and maintaining custom plugin is not easy too, especially for someone who doesn't know the Go language.
Do you think this issue should be closed in favor of generic --devices and --cap_add service options support you've linked?

@nazar-pc I think you will find that writing a volume plugin is much easier. They do not need to be written in Go, they just communicate over a socket. This is exactly the use case they are designed for. You just need to do docker plugin install to install them and then your compose yaml file can just specify that you want to use the ceph volume driver.
If you use the method you suggest you are granting cap_sys_admin to all services, which is almost the same as --privileged.

Yes, let's close this in favor of https://github.com/docker/docker/issues/25885, and https://github.com/docker/docker/issues/25303, which are already tracking the requirements

authors: justincormack nazar-pc thaJeztah


text:
failed to register layer: Error processing tar file(exit status 1): Error cleaning up after pivot

I have a fresh docker install, when I run: docker run hello-world, the output is:
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
78445dd45222: Extracting [==================================================>]    971 B/971 B
docker: failed to register layer: Error processing tar file(exit status 1): Error cleaning up after pivot: remove /.pivot_root503620824: device or resource busy.
See 'docker run --help'.

I have installed docker from : docker docs
docer version:
Client:
 Version:      17.03.1-ce
 API version:  1.27
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Mon Mar 27 17:14:09 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.03.1-ce
 API version:  1.27 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Mon Mar 27 17:14:09 2017
 OS/Arch:      linux/amd64
 Experimental: false

docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 17.03.1-ce
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 0
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 4ab9917febca54791c5f071a9d1f404867857fcc
runc version: 54296cf40ad8143b62dbcaa1d90e520a2136ddfe
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.4.0-58-generic
Operating System: Ubuntu 16.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 15.58 GiB
Name: sinoohe
ID: H33D:AIOZ:ZCLG:HFYO:3AD6:TM7B:OLOP:6VE2:PCGH:FE4Q:GSOH:YE75
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Error comes from here; https://github.com/docker/docker/blob/da0ccf8e61e4d5d4005e19fcf0115372f09840bf/pkg/chrootarchive/chroot_linux.go#L62, but the "device or resource busy" sounds as if something is keeping it busy..
Was this a fresh install, or an upgrade of docker? Have you checked if the docker daemon logs (journalctl -x -u docker), and system logs, if they provide anything useful?
/cc @cpuguy83

That doesn't seem possible.
Can you make sure your kernel is up to date?

syslogs:
Mar 31 01:59:45 sinoohe dockerd[4599]: time="2017-03-31T01:59:45.988555301+04:30" level=error msg="Handler for POST /v1.27/containers/create returned error: No such image: hello-world:latest"
Mar 31 02:00:00 sinoohe dockerd[4599]: time="2017-03-31T02:00:00.202445119+04:30" level=error msg="Error trying v2 registry: failed to register layer: Error processing tar file(exit status 1): Error cleaning up after pivot: remove /.pivot_root822899776: device or resource busy"
Mar 31 02:00:00 sinoohe dockerd[4599]: time="2017-03-31T02:00:00.202556704+04:30" level=error msg="Attempting next endpoint for pull after error: failed to register layer: Error processing tar file(exit status 1): Error cleaning up after pivot: remove /.pivot_root822899776: device or resource busy"

journalctl -x -u docker:
Mar 31 01:59:45 sinoohe dockerd[4599]: time="2017-03-31T01:59:45.988555301+04:30" level=error msg="Handler for POST /v1.27/containers/create returned error: No such image: hello-world:latest"
Mar 31 02:00:00 sinoohe dockerd[4599]: time="2017-03-31T02:00:00.202445119+04:30" level=error msg="Error trying v2 registry: failed to register layer: Error processing tar file(exit status 1): Error cleaning up after pivot: remove /.pivot_root822899776: device or resource busy"
Mar 31 02:00:00 sinoohe dockerd[4599]: time="2017-03-31T02:00:00.202556704+04:30" level=error msg="Attempting next endpoint for pull after error:  failed to register layer: Error processing tar file(exit status 1): Error or cleaning up after pivot: remove /.pivot_root822899776: device or resource busy"

it was a fresh install.
kernal version:
Linux sinoohe 4.4.0-58-generic #79-Ubuntu SMP Tue Dec 20 12:12:35 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

@sinoohe I think there's newer kernel versions available.
It may not fix the issue, but it may just.

@cpuguy83 I restarted Linux, It seems that the problem is fixed, I don't know what was the real reason.

Thanks for the update! Let me go ahead and close this issue, but feel free to continue the conversation

authors: cpuguy83 sinoohe thaJeztah


text:
Fixes Issue 9677: Docker client errors out, when daemon flags are passed to docker subcommands

Fixes #9677

@duglin right now docker flag parsing relies on one hashmap to classify whether the incoming argument is a flag or not. That map includes both daemon and global flags. Unless we use two maps to store daemon and global args separately, I don't see a way to avoid this extra map.
N Separating IMHO would not be easy, it has dependencies everywhere.
For this error, we need some kind of data structure to look-up if the incoming argument is a daemon flag or not.
I will  reorder the entries according to the help menu. And also add the deprecated flags which I have not added.
Shishir

@shishir-a412ed sorry if I wasn't clear.  I wasn't talking about a map during parsing, I was talking about a map/struct during flag setup time.  For example, if you look at the InstallFlags() func, that is what will register all of our daemon-side flags.  And it does it via a list of flag.XXX calls. A hard coded list of calls.  So knowing when a new one (like perhaps "-log-driver" at the end) is added is hard to detect when you also want to have your new code work.   So, I was wondering if we could take all of the flag definitions from InstallFlags() and put them into a struct.  InstallFlags() would then look over that struct to make all of the appropriate flag.XXX calls.
But, and this is the point, your new code can then use that same struct to perform the checks you need to know if any of them were specified w/o the -d flag.  Then as new flags are added you won't need to update your code.  Does this make any sense?

@duglin
I think I get the central idea of what you are trying to achieve.
You are trying to have a common struct/map that can be used to set the flags in daemon/config.go InstallFlags() method. By iterating over that data structure and populating the flags rather than hard coding it.
N use the same struct/map to do the look-up for my use-case to identify if it's a daemon flag or not.
So that updates are made at one central location rather than at two different places.
Few open questions:

" So, I was wondering if we could take all of the flag definitions from InstallFlags() and put them into a struct. InstallFlags() would then look over that struct to make all of the appropriate flag.XXX calls."
Isn't that what we are doing right now ? flag.XXX call is using the daemon config struct to populate the flags. InstallFlags is a method typed to daemon config struct i.e. struct.InstallFlags()
Not sure how you would iterate over a struct and avoid the hard coding ?

Populating a flag needs a struct. I am not sure how a map would work here, as iterating over a map won't tell me which field I am getting back. Checking daemon flags would needs a map to do the lookup {struct won't work here}. I feel these are two different use cases requiring two different data structures.

Nways let other maintainers jump in, and see what they feel.
I ll be happy to change the code, if there is a mutual consensus on a solution.
Till that time, I ll clean up the code.
Shishir

@duglin I have reordered the flags according to the help menu.
And added support for deprecated flags.
ping @tiborvass
Shishir

@shishir-a412ed  to your questions:

no its not. Each call to flag.XXX is hand coded, not reading from a structure/array. This means that each time a new daemon flag is created people will need to not only add a new call to flag.XXX but also remember to update your Init() func - which I'm sure they'll forget. By having a single spot that is used to define the daemon flags (via a flag.XXX call) and setup your mapDaemonFlags structure, we avoid one being updated w/o the other.
wouldn't all daemon flags, except -d, be added to your mapDaemonFlags structure? If so, then we just need one if-statement to avoid adding it to your mapDaemonFlags.
But perhaps I'm missing something, or defining such a structure/array is more complicated than I'm thinking.

@duglin I have re-factored the code. Does this solve your concern ?

@icecrime Thanks, I have made the changes. Please check now.

@shishir-a412ed I'm afraid this also needs to be rebased. The code looks good to me except for a minor comment.

@calavera thanks ... I have rebased the PR and made changes for the comment.

cool, thanks!
:space_invader: LGTM :space_invader:

LGTM

@duglin @icecrime @tiborvass I ll go ahead and be ambitious here ! lol
But can we get this merged in docker 1.6.0 ?

LOL good one :-)

I think we can wait for 1.7

@shishir-a412ed this doesn't really solve any regression in the current RCs for 1.6.0. I'm afraid it'll probably have to wait until 1.7. But good try :grin:

@calavera @duglin @icecrime @tiborvass 1.7.0 it is :)
Let me add some testing code to the PR by then.

sorry needs rebase

@jfrazelle I have rebased the PR.

@calavera I have changed this HasDaemonFlag = MapDaemonFlags[name] back to my original code.
This has a small bug. If a daemon flag is followed by a global flag. At the end of the flag parsing flag.Parse()
HasDaemonFlag would be set to false eventhough it should have been true.

@shishir-a412ed it makes sense, thanks for fixing it. I think it would make sense to add a few tests to validate this behavior.
I was also wondering if it would make sense to have two completely different FlagSet lists, one for the daemon flags and another for the rest. That way we wouldn't need to modify the flag package. I don't know if that would work as expected though.

We are planning on a more extensive patch to break these flags apart.  But we need to do a lot of hacking for backwards compatibility.  Sadly if we could go back to original docker and just have
docker daemon ...
All of this would be unnecessary...

@calavera I ll add the test cases in 1-2 days. Thanks.

@calavera I have added the test cases.
ping @tiborvass

@shishir-a412ed Thanks for your work Shishir, I'll carry this PR and #10535 to get it in asap.

Where is this going to be carried?

Carried in #13771

source: gharchive/pull-request

authors: calavera duglin jfrazelle rhatdan shishir-a412ed tiborvass


text:
Update faq.md

Correct case for PostgreSQL.

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "patch-2" git@github.com:charleswhchan/docker.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

Ammending updates the existing PR. You DO NOT need to open a new one.

Replaced by https://github.com/docker/docker/pull/15004

authors: GordonTheTurtle charleswhchan thaJeztah


text:
Unexport VolumeDriver.

This is not a public interface and users are trying to use it.
We only use it to be able to generate the rpc protocol to talk with a plugin.
/cc @cpuguy83
Signed-off-by: David Calavera david.calavera@gmail.com

LGTM

LGTM

authors: abronan calavera cpuguy83


text:
Remove wait on start channel for systemd socket

Because Serve will be called after daemon creation
ping @runcom

Fixed! Thanks
LGTM

However I noticed that we don't use listenbuffer after #16539, because Serve now called after daemon creation and AcceptConnection called immediately after listeners created. If we want continue to use listenbuffer it will require more refactoring with logic similar to what it was before with AcceptConnections(d)

But maybe we don't need listenbuffer at all, I tested and seems like just net.Listen queue requests pretty good.

LGTM

should we remove the listenbuffer ?

@jessfraz yup, I'll remove it in next PR

cool then merging

authors: LK4D4 jfrazelle runcom


text:
Fixed broken links, and updated some to https

This PR fixes a couple of links and typos I noticed in the docs merge pr (sorry, was merged before I could comment).
ping @thaJeztah @moxiegirl @SvenDowideit
Signed-off-by: Christopher Jones tophj@linux.vnet.ibm.com

Thanks! LGTM
ping @moxiegirl for the merge

Yay https!

LGTM thank you @tophj-ibm for the contribution,

authors: MHBauer moxiegirl thaJeztah tophj-ibm


text:
add unknown_binary

fix #18948

ping @ewindisch

Didn't really fix it all the way for me, FYI.
Now I get different shared object denials.

can you show me logs? it fixed it for me :(

maybe we should not ship the profile... I am not exactly confident in it

/usr/bin/nodejs: error while loading shared libraries: libz.so.1: cannot open shared object file:  Permission denied -> hipache
chown: error while loading shared libraries: libc.so.6: cannot open shared object file: Permission denied -> redis
/bin/bash: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: Permission denied -> custom go http server
iptables: error while loading shared libraries: libip4tc.so.0: cannot open shared object file: Permission denied -> openvpn
stat: error while loading shared libraries: libselinux.so.1: cannot open shared object file: Permission denied -> ZNC
[ 4467.683288] type=1400 audit(1453135237.971:24014): apparmor="ALLOWED" operation="open" profile="/usr/bin/docker//null-310" name="/etc/ld.so.cache" pid=23946 comm="znc-shim" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 4467.683371] type=1400 audit(1453135237.971:24015): apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="/usr/bin/docker//null-310" name="var/lib/docker/aufs/diff/0d52d6d11e71f65d0aff70efc10d9cbfe97479b15bd2d57357d68bfc17df8ee1/etc/ld.so.cache" pid=23946 comm="znc-shim" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 4467.684643] type=1400 audit(1453135237.975:24016): apparmor="ALLOWED" operation="open" profile="/usr/bin/docker//null-310" name="/lib/x86_64-linux-gnu/libncurses.so.5.9" pid=23946 comm="znc-shim" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 4467.684663] type=1400 audit(1453135237.975:24017): apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="/usr/bin/docker//null-310" name="var/lib/docker/aufs/diff/36fd425d7d8a26bb092cf3ca8c52eb8e47170363f40a3f4e37c9cad401f0e9fe/lib/x86_64-linux-gnu/libncurses.so.5.9" pid=23946 comm="znc-shim" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

With this change, some of my stuff works, some of it doesn't :(

ugh ok i dont think we should ship the profile because honestly im in over
my apparmor knowledgee here
On Mon, Jan 18, 2016 at 11:55 AM, Brian Goff notifications@github.com
wrote:

/usr/bin/nodejs: error while loading shared libraries: libz.so.1: cannot
open shared object file:
Permission denied -> hipache
chown: error while loading shared libraries: libc.so.6: cannot open shared
object file: Permission denied -> redis
/bin/bash: error while loading shared libraries: libtinfo.so.5: cannot
open shared object file: Permission denied -> custom go http server
iptables: error while loading shared libraries: libip4tc.so.0: cannot open
shared object file: Permission denied -> openvpn
stat: error while loading shared libraries: libselinux.so.1: cannot open
shared object file: Permission denied -> ZNC
[ 4467.683288] type=1400 audit(1453135237.971:24014): apparmor="ALLOWED" operation="open" profile="/usr/bin/docker//null-310" name="/etc/ld.so.cache" pid=23946 comm="znc-shim" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 4467.683371] type=1400 audit(1453135237.971:24015): apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="/usr/bin/docker//null-310" name="var/lib/docker/aufs/diff/0d52d6d11e71f65d0aff70efc10d9cbfe97479b15bd2d57357d68bfc17df8ee1/etc/ld.so.cache" pid=23946 comm="znc-shim" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 4467.684643] type=1400 audit(1453135237.975:24016): apparmor="ALLOWED" operation="open" profile="/usr/bin/docker//null-310" name="/lib/x86_64-linux-gnu/libncurses.so.5.9" pid=23946 comm="znc-shim" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 4467.684663] type=1400 audit(1453135237.975:24017): apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="/usr/bin/docker//null-310" name="var/lib/docker/aufs/diff/36fd425d7d8a26bb092cf3ca8c52eb8e47170363f40a3f4e37c9cad401f0e9fe/lib/x86_64-linux-gnu/libncurses.so.5.9" pid=23946 comm="znc-shim" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
With this change, some of my stuff works, some of it doesn't :(
—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/19415#issuecomment-172634336.

ok i have added another commit which removes the docker-engine profile, i think we should do this for 1.10 because it should have been complain only and no enforced, but since that is not working i think we should wait til i can study TFM and get this working as intended :)

this way i can have less anxiety for the release about the profile not working as intended

SGTM, it was complain only anyway, so not losing much.

Maybe we can do that 2nd commit as a separate PR so we can disable and discuss the first change separately?

will do

I do think this fixes it tho, and in the case where it didnt i think it just needed to be restarted, because i can nolonger repro with hipache or redis

For me, it works on a full reboot... but if I restart docker it fails again.

closing im going to redo various things make 1 PR


text:
Clean dead code

It looks not meaningful annotation, feel free to close this PR if this is kept here for reference.
ping @tonistiigi @docker/maintainers
Signed-off-by: Zhang Wei zhangwei555@huawei.com

LGTM http://stackexchange.com/email/manage/8757/860930f330638a879dc5cdf1157e9f0289d022c0333a76392ce5ab6a908d133c

LGTM, but I also don't know if this was kept around for reference

authors: WeiZhang555 thaJeztah vdemeester


text:
make ErrSwarmLocked and ErrSwarmCertificatesExpired return status code 503

In code https://github.com/docker/docker/blob/master/api/server/httputils/errors.go#L65-L71, it validates the string this node to return status code of 503.
{"this node", http.StatusServiceUnavailable},

While the every error related to 503 should contain string this node.
I found that error ErrSwarmLocked and ErrSwarmCertificatesExpired do not contain "this node".This PR makes them contain "this node" and return status code of 503 to keep consistent.
Since error ErrSwarmLocked and ErrSwarmCertificatesExpired is added from version 1.13.x, and did not appear in dockerd 1.12.x, so this change will not change the API, but enhance api 1.25.

In addition, in code https://github.com/docker/docker/blob/master/daemon/cluster/cluster.go#L689, there is a substring of "this node" in the error message, then this error will return status code of 503, which is unreasonable, like the following pic:

- What I did

make error  ErrSwarmLocked and ErrSwarmCertificatesExpired contain substring "this node" and return 503;
make another error not contain substring "this node".

/cc @stevvooe
Signed-off-by: allencloud allen.sun@daocloud.io

After some thought, 503 is probably the right error code for these conditions.
It would be better to add a new match criteria, than change the error message to contain "this node".

Agreed, we do have helpers for wrapping errors with http status codes that the api layer handles.
Not 100% ideal, but better than string matching.

I agree to not use string match. Since string match will cause accidental mismatch sometimes.

Currently, in case that should return status code of 503, I wrap the errors there, like :
return apierrors.NewRequestServiceUnavailableError(ErrSwarmLocked)

While I think some other places which have substring this node by accident, we still should make it not contain this node.
As result, this PR did two parts:

use error wrapper to deal with errors which should be 503;
replace one error's substring this node to make it not return 503.

PTAL @stevvooe @cpuguy83

Not sure how to test expired, but maybe a test for the locked case would be in order?

While string matching isn't the best method, wrapping these errors could have unintended effects, especially in an rc release. IMHO, the apierrors package is a worse pattern than string matching, in practice, as it may unintentionally hide error values.
As I said above, please just add another match criteria. We can fix the error code mess in a later PR, outside of the release. If we really didn't want string matching, we need to be mindful to catch these anti-patterns (as well, as apierrors) during code review.

@stevvooe looks good to you ?

Hi, @vieux, @stevvooe hopes I could change another match criteria. Actually I have not done that yet.
In addition, I think in the long term, a better match criteria is very good, while currently I have no idea how to choose a proper one, since we hope that a better match could include every case, however it is not easy to achieve this.
So I keep the current implementation. And feel free to input more.

Any update ? @stevvooe @cpuguy83

@allencloud Please follow my feedback. Add a new matching case rather than change these strings.
@thaJeztah This needs to go into 1.13.0. What happened here?

Thanks for your feedback. I will try that.

@allencloud what's status here?

As I said above, please just add another match criteria

I am afraid that I still have no idea which match criteria is better than now. I have to say that some help is needed.

@allencloud These errors are mapped to status codes based on strings (unfortunately). Rather than change all the error messages, add a condition here or return a proper status code directly.

opened https://github.com/docker/docker/pull/31141 as a replacement

replacement was cherry-picked into 1.13.x / 17.03 through https://github.com/docker/docker/issues/31140

Thanks @thaJeztah  ^^

authors: LK4D4 allencloud cpuguy83 stevvooe thaJeztah vieux


text:
registry: Remove reference.go

This removes some very old vestigial code that really should have been removed during the content addressability transition. It implements something called "reference" but it behaves differently from the actual reference package. This was only used by client-side content trust code, and is relatively easy to extricate.
cc @dmcgowan @cyli @endophage

LGTM

LGTM

authors: aaronlehmann dmcgowan tonistiigi


text:
Update frozen images in Dockerfiles

This updates the versions of the frozen images used to their current
version. The original reason for updating these images was to make sure
they are not affected by CVE-2016-1252 / DSA-3733-1,
which is fixed in apt 1.0.9.8.4 and up.
Note that CVE-2016-1252 won't affect our test-suite, because no packages
are installed during out tests. It is just "good practice" to keep these
images up to date.
The debian:jessie, and buildpack-deps:jessie in  Dockerfile.s390x,
and Dockerfile.armhf have not been updated in this patch, because
those images have not yet been updated to contain apt 1.0.9.8.4.
While working on this, the busybox and hello-world were also updated
to their latest version.
Also removes a reference to hack/make/.ensure-frozen-images, which
was removed in ff91276d1f5beab5582d9ca582ee01af13198333.
/cc @tianon @vdemeester @tophj-ibm

CI failure seems real
00:18:11.350 INFO: Testing against a local daemon
00:18:11.439 --- FAIL: Test (0.09s)
00:18:11.439 	fixtures_linux_daemon_test.go:31: REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
00:18:11.440 		emptyfs             latest              11f64303f0f7        3 years ago         0 B
00:18:11.441 		%!(EXTRA int=0, <nil>)
00:18:11.441 	fixtures_linux_daemon_test.go:32: exit status 1: invalid target ID: null
00:18:11.442
00:18:11.472 		github.com/docker/docker/integration-cli/fixtures/load.loadFrozenImages
00:18:11.473 			/go/src/github.com/docker/docker/integration-cli/fixtures/load/frozen.go:96
00:18:11.509 		github.com/docker/docker/integration-cli/fixtures/load.FrozenImagesLinux
00:18:11.509 			/go/src/github.com/docker/docker/integration-cli/fixtures/load/frozen.go:59
00:18:11.510 		github.com/docker/docker/integration-cli.ensureFrozenImagesLinux
00:18:11.510 			/go/src/github.com/docker/docker/integration-cli/fixtures_linux_daemon_test.go:29
00:18:11.511 		github.com/docker/docker/integration-cli.Test
00:18:11.512 			/go/src/github.com/docker/docker/integration-cli/check_test.go:138
00:18:11.512 		testing.tRunner
00:18:11.512 			/usr/local/go/src/testing/testing.go:610
00:18:11.513 		runtime.goexit
00:18:11.513 			/usr/local/go/src/runtime/asm_amd64.s:2086
00:18:11.513 FAIL

https://jenkins.dockerproject.org/job/Docker-PRs-experimental/29021/console

@AkihiroSuda ah, hm, interesting, let me look into that

hm, ok, I think the issue will be around this;
cat /docker-frozen-images/repositories
{
	"buildpack-deps": { "jessie": "null" },
	"busybox": { "latest": "null" },
	"debian": { "jessie": "null" },
	"hello-world": { "latest": "null" }
}

Ok, looks like the frozen images can only work with old images. When running the script with the updated images;
./contrib/download-frozen-image-v2.sh /docker-frozen-images hello-world:latest@sha256:0256e8a36e2070f7bf2d0b0763dbabdd67798512411de4cdcf9431a1feb60fd9

The script gets this manifestJson;
{
   "schemaVersion": 2,
   "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
   "config": {
      "mediaType": "application/octet-stream",
      "size": 1473,
      "digest": "sha256:c54a2cc56cbb2f04003c1cd4507e118af7c0d340fe7e2720f70976c4b75237dc"
   },
   "layers": [
      {
         "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
         "size": 974,
         "digest": "sha256:c04b14da8d1441880ed3fe6106fb2cc6fa1c9661846ac0266b8a5ec8edf37b7c"
      }
   ]
}

But the old images:
./contrib/download-frozen-image-v2.sh /docker-frozen-images hello-world:latest@sha256:8be990ef2aeb16dbcb9271ddfe2610fa6658d13f6dfb8bc72074cc1ca36966a7
Produce this manifestJson:
{
   "schemaVersion": 1,
   "name": "library/hello-world",
   "tag": "latest",
   "architecture": "amd64",
   "fsLayers": [
      {
         "blobSum": "sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4"
      },
      {
         "blobSum": "sha256:03f4658f8b782e12230c1783426bd3bacce651ce582a4ffb6fbbfa2079428ecb"
      }
   ],
   "history": [
      {
         "v1Compatibility": "{\"id\":\"975b84d108f1024953937167506c2935a081c8c55ae9e9f7b7deee118605367f\",\"parent\":\"3f12c794407e68e515ba7f473a744e748ac8a827a2ea8b33855dec564238b2e5\",\"created\":\"2015-10-13T23:47:48.954129267Z\",\"container\":\"ea6a0578b48631dd3f3b70d7ea48e73ac0b0891433fad177872e74c35d82f56d\",\"container_config\":{\"Hostname\":\"5428b43b1a3e\",\"Domainname\":\"\",\"User\":\"\",\"AttachStdin\":false,\"AttachStdout\":false,\"AttachStderr\":false,\"Tty\":false,\"OpenStdin\":false,\"StdinOnce\":false,\"Env\":null,\"Cmd\":[\"/bin/sh\",\"-c\",\"#(nop) CMD [\\\"/hello\\\"]\"],\"Image\":\"3f12c794407e68e515ba7f473a744e748ac8a827a2ea8b33855dec564238b2e5\",\"Volumes\":null,\"WorkingDir\":\"\",\"Entrypoint\":null,\"OnBuild\":null,\"Labels\":null},\"docker_version\":\"1.8.2\",\"config\":{\"Hostname\":\"5428b43b1a3e\",\"Domainname\":\"\",\"User\":\"\",\"AttachStdin\":false,\"AttachStdout\":false,\"AttachStderr\":false,\"Tty\":false,\"OpenStdin\":false,\"StdinOnce\":false,\"Env\":null,\"Cmd\":[\"/hello\"],\"Image\":\"3f12c794407e68e515ba7f473a744e748ac8a827a2ea8b33855dec564238b2e5\",\"Volumes\":null,\"WorkingDir\":\"\",\"Entrypoint\":null,\"OnBuild\":null,\"Labels\":null},\"architecture\":\"amd64\",\"os\":\"linux\"}"
      },
      {
         "v1Compatibility": "{\"id\":\"3f12c794407e68e515ba7f473a744e748ac8a827a2ea8b33855dec564238b2e5\",\"created\":\"2015-10-13T23:47:48.522046233Z\",\"container\":\"5428b43b1a3ef166dd7447c7f4fd39168a12525458fc6320f3cc95bab9a7fe53\",\"container_config\":{\"Hostname\":\"5428b43b1a3e\",\"Domainname\":\"\",\"User\":\"\",\"AttachStdin\":false,\"AttachStdout\":false,\"AttachStderr\":false,\"Tty\":false,\"OpenStdin\":false,\"StdinOnce\":false,\"Env\":null,\"Cmd\":[\"/bin/sh\",\"-c\",\"#(nop) COPY file:1ad52e3eaf4327c8f846c76dfc7424152b2347bf7bed5959932fa309d7496afc in /\"],\"Image\":\"\",\"Volumes\":null,\"WorkingDir\":\"\",\"Entrypoint\":null,\"OnBuild\":null,\"Labels\":null},\"docker_version\":\"1.8.2\",\"config\":{\"Hostname\":\"5428b43b1a3e\",\"Domainname\":\"\",\"User\":\"\",\"AttachStdin\":false,\"AttachStdout\":false,\"AttachStderr\":false,\"Tty\":false,\"OpenStdin\":false,\"StdinOnce\":false,\"Env\":null,\"Cmd\":null,\"Image\":\"\",\"Volumes\":null,\"WorkingDir\":\"\",\"Entrypoint\":null,\"OnBuild\":null,\"Labels\":null},\"architecture\":\"amd64\",\"os\":\"linux\",\"Size\":960}"
      }
   ],
   "signatures": [
      {
         "header": {
            "jwk": {
               "crv": "P-256",
               "kid": "2XRW:M2RL:TMLP:32TF:F2EO:MY5N:W2YV:M4Q6:U6XG:YHDH:ZCDF:RCO3",
               "kty": "EC",
               "x": "V7kYEOQtaNwPbseasqAJLab0oLAeVnDsEhVHxIpsphg",
               "y": "8mE3KPNTpNI8inPqtkGxc7UjpAJvCG_Yp2KpJwuvcjg"
            },
            "alg": "ES256"
         },
         "signature": "7F16UYjy6oTd1QJbE7W_7vGzouRoBxZFvsapCfI5c7FvC0U-zaoMP4Qa4WiWhNds6NRdL8bHlKOf1sLlI777_Q",
         "protected": "eyJmb3JtYXRMZW5ndGgiOjI3NTAsImZvcm1hdFRhaWwiOiJDbjAiLCJ0aW1lIjoiMjAxNy0wMS0wMlQxMTozODowN1oifQ"
      }
   ]
}

ping @tonistiigi any idea if there's a way to re-construct the correct layout for docker load without using docker? I can pull the individual layers, and the image-config, but not sure how to do the other bits.

I can take a look at this script later today too -- I've written code that
does something similar in Perl, and I think doing so with just Bash+jq
should be reasonable (worth a try, anyhow).

@tianon thanks! I tried to get the information together, but only partially managed to get the correct format that is expected for docker load. But if you know how, that'd be awesome

@thaJeztah The format is covered in https://github.com/docker/docker/blob/master/image/spec/v1.2.md#combined-image-json--filesystem-changeset-format . You don't need the old style configs or repositories file. Only manifest.json that points to the layer and configuration files.

Got something worked out over in https://github.com/docker/docker/issues/29864. :+1:

@thaJeztah does this depends on #29864 ?

@LK4D4 yes, it does

@tianon the ppc64le and armhf debian:jessie's and buildpacks haven't been updated in a couple of months, and looking at the debian apt package, the version with the fix should be available. I'm not 100% sure how those builds work, but from reading you have a jenkins job from https://github.com/tianon/jenkins-groovy so maybe something is broken on p and arm? I'm not sure.
@ddingel it looks like the s390x debian:jessie and buildpack-deps:jessie have been updated recently, can you check that they have the right version of apt installed (1.0.9.8.4)?
@thaJeztah thanks for looking into this, it seemed to have fallen in my vacation folder 😭

@tophj-ibm was talking to @estesp about ppc64le just the other day -- I can't seem to connect to the server I've been using anymore, so it must've been terminated at some point and he was going to ask around to see if anyone knows what happened to it :confused:
As for armhf, they're built on a smaller ARMv8 VM I've got, so it probably filled up -- I'll go take a look and force at least debian and buildpack-deps to rebuild.

@tianon: just got a note from Srini that the machine was removed after there was some communication drop about a required update; we'll get you another one!

@estesp it wasn't my fault, I swear!!
Also, thanks for looking into it @tianon 🙏

@tophj-ibm you are right debian:jessie and buildpack-deps:jessie are on 1.0.9.8.4.

@thaJeztah you should be able to update the sha's for armhf, ppc64le and s390x now!

Updated, but still depends on https://github.com/docker/docker/issues/29864

#29864 was merged

Yes, I tried re-triggering CI, but I think Jenkins was temporarily out just around that time

@thaJeztah failure is real :(

ugh, thanks for the ping, i'll go and have a look

@thaJeztah that test is wrong, and a fix is in the go 1.8 pr. See https://github.com/docker/docker/pull/29030#issuecomment-268389298

ailing on both experimental and janky;
00:40:50
00:40:50 ----------------------------------------------------------------------
00:40:50 FAIL: docker_cli_by_digest_test.go:651: DockerSchema1RegistrySuite.TestPullFailsWithAlteredLayer
00:40:50
00:40:50 docker_cli_by_digest_test.go:685:
00:40:50     c.Assert(exitStatus, checker.Not(check.Equals), 0, check.Commentf("expected a non-zero exit status"))
00:40:50 ... obtained int = 0
00:40:50 ... expected int = 0
00:40:50 ... expected a non-zero exit status
00:40:50
00:40:51

failing on experimental;
00:19:33
00:19:33 ----------------------------------------------------------------------
00:19:33 FAIL: docker_cli_build_test.go:5549: DockerSuite.TestBuildSquashParent
00:19:33
00:19:33 docker_cli_build_test.go:5586:
00:19:33     c.Assert(strings.TrimSpace(out), checker.Equals, "3")
00:19:33 ... obtained string = "2"
00:19:33 ... expected string = "3"
00:19:33
00:19:33
00:19:33 ----------------------------------------------------------------------

@tophj-ibm oh, thanks! (Sorry missed your comment when I posted my last one)

Discussing with @tonistiigi; difference is that the old busybox image had two layers, and the new one has a single layer

Fixing the test in https://github.com/docker/docker/pull/31125

ping @thaJeztah

@LK4D4 thanks for the ping, updated the PR

@thaJeztah psst :)

Sorry for the delay, had to find some time to pull them all again :smile: refreshed them all again 👍

thanks @thaJeztah 😄

Ok, the "good news" is that a test, "formerly known as flaky" now consistently fails on all builds;
16:26:05 ----------------------------------------------------------------------
16:26:05 FAIL: docker_cli_push_test.go:608: DockerRegistryAuthTokenSuite.TestPushMisconfiguredTokenServiceResponseError
16:26:05
16:26:05 docker_cli_push_test.go:617:
16:26:05     c.Assert(out, checker.Not(checker.Contains), "Retrying in 15")
16:26:05 ... obtained string = "" +
16:26:05 ...     "The push refers to a repository [127.0.0.1:5000/busybox]\n" +
16:26:05 ...     "c0de73ac9968: Preparing\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 5 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 4 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 3 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 2 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 1 second\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 10 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 9 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 8 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 7 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 6 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 5 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 4 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 3 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 2 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 1 second\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 15 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 14 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 13 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 12 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 11 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 10 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 9 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 8 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 7 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 6 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 5 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 4 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 3 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 2 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 1 second\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 20 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 19 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 18 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 17 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 16 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 15 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 14 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 13 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 12 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 11 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 10 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 9 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 8 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 7 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 6 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 5 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 4 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 3 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 2 seconds\n" +
16:26:05 ...     "c0de73ac9968: Retrying in 1 second\n" +
16:26:05 ...     "toomanyrequests: out of tokens\n"
16:26:05 ... substring string = "Retrying in 15"
16:26:05

Discussing with @dmcgowan on Slack;

that switch from 3 to 10 looks like it is going to always cause it to fail since it checks that it doesn't grow the retry time to 15 which 10 will cause it to do, there has got to be a better way to test this, the current approach seems very broken

[thaJeztah] should we change it back to 3? Weird that it started consistently failing after updating the frozen images (but tbh, I haven't dived into the test)

3 should be enough, would have to dig into the original flakiness more possibly that check that it didn't retry after 15 seconds should be removed, the test might have been updated to ensure that it wasn't unnecessarily taking a long time

The "switch from 3 to 10" (actually "4 to 10") was done here to try and make it less flaky; https://github.com/docker/docker/pull/32058

Changed to 3 retries, let's see what it does now

boo; weird failure on s390x;
2:08:14 ----------------------------------------------------------------------
12:08:14 FAIL: docker_api_images_test.go:120: DockerSuite.TestAPIImagesImportBadSrc
12:08:14
12:08:14 docker_api_images_test.go:137:
12:08:14     c.Assert(res.StatusCode, checker.Equals, te.statusExp)
12:08:14 ... obtained int = 500
12:08:14 ... expected int = 404
12:08:14
12:08:15

And even more weird at PowerPC
12:01:37 ---> Making bundle: test-unit (in bundles/17.05.0-dev/test-unit)
12:01:37 Sat Apr  1 12:01:37 UTC 2017
12:01:50 ok  	github.com/docker/docker/api	0.086s	coverage: 87.3% of statements
12:01:51 ?   	github.com/docker/docker/api/errors	[no test files]
12:01:56 ok  	github.com/docker/docker/api/server	0.010s	coverage: 6.2% of statements
12:01:56 ok  	github.com/docker/docker/api/server/httputils	0.027s	coverage: 16.7% of statements
12:01:56 ok  	github.com/docker/docker/api/server/middleware	0.007s	coverage: 20.3% of statements
12:01:56 ?   	github.com/docker/docker/api/server/router	[no test files]
12:01:56 ?   	github.com/docker/docker/api/server/router/build	[no test files]
12:01:56 ?   	github.com/docker/docker/api/server/router/checkpoint	[no test files]
12:01:56 ?   	github.com/docker/docker/api/server/router/container	[no test files]
12:01:56 ?   	github.com/docker/docker/api/server/router/image	[no test files]
12:02:12 # github.com/docker/docker/vendor/github.com/google/certificate-transparency/go/client
12:02:12 sweep 0 4
12:02:12 fatal error: gc: unswept span
12:02:12
12:02:12 goroutine 5 [running]:
12:02:12 runtime.throw(0x65d2f1, 0x10)
12:02:12 	/usr/local/go/src/runtime/panic.go:566 +0x8c fp=0xc420025d58 sp=0xc420025d28
12:02:12 runtime.markrootSpans(0xc420019228, 0x0)
12:02:12 	/usr/local/go/src/runtime/mgcmark.go:345 +0x1fc fp=0xc420025e08 sp=0xc420025d58
12:02:12 runtime.markroot(0xc420019228, 0x5)
12:02:12 	/usr/local/go/src/runtime/mgcmark.go:190 +0x318 fp=0xc420025eb0 sp=0xc420025e08
12:02:12 runtime.gcDrain(0xc420019228, 0x6)
12:02:12 	/usr/local/go/src/runtime/mgcmark.go:969 +0x320 fp=0xc420025f10 sp=0xc420025eb0
12:02:12 runtime.gcBgMarkWorker(0xc420018000)
12:02:12 	/usr/local/go/src/runtime/mgc.go:1458 +0x2e0 fp=0xc420025f98 sp=0xc420025f10
12:02:12 runtime.goexit()
12:02:12 	/usr/local/go/src/runtime/asm_ppc64x.s:1095 +0x4 fp=0xc420025f98 sp=0xc420025f98
12:02:12 created by runtime.gcBgMarkStartWorkers
12:02:12 	/usr/local/go/src/runtime/mgc.go:1349 +0xa0
12:02:12
12:02:12 goroutine 1 [runnable]:
12:02:12 cmd/compile/internal/gc.Nod(0x1, 0x0, 0x0, 0xc42041c600)
12:02:12 	/usr/local/go/src/cmd/compile/internal/gc/subr.go:347 +0xf8
12:02:12 cmd/compile/internal/gc.newname(0xc420401180, 0xc4203f7230)
12:02:12 	/usr/local/go/src/cmd/compile/internal/gc/dcl.go:334 +0x74
12:02:12 cmd/compile/internal/gc.(*importer).param(0xc4204c48c0, 0x1, 0x2)
12:02:12 	/usr/local/go/src/cmd/compile/internal/gc/bimport.go:653 +0x1e0
12:02:12 cmd/compile/internal/gc.(*importer).paramList(0xc4204c48c0, 0x0, 0x0, 0x0)
12:02:12 	/usr/local/go/src/cmd/compile/internal/gc/bimport.go:623 +0xf4
12:02:12 cmd/compile/internal/gc.(*importer).typ(0xc4204c48c0, 0xffffffffffffff12)
12:02:12 	/usr/local/go/src/cmd/compile/internal/gc/bimport.go:435 +0xa24
12:02:12 cmd/compile/internal/gc.(*importer).typ(0xc4204c48c0, 0xa)
12:02:12 	/usr/local/go/src/cmd/compile/internal/gc/bimport.go:487 +0x520
12:02:12 cmd/compile/internal/gc.(*importer).param(0xc4204c48c0, 0x1, 0x2)
12:02:12 	/usr/local/go/src/cmd/compile/internal/gc/bimport.go:630 +0x30
12:02:12 cmd/compile/internal/gc.(*importer).paramList(0xc4204c48c0, 0x0, 0x0, 0x0)
12:02:12 	/usr/local/go/src/cmd/compile/internal/gc/bimport.go:623 +0xf4
12:02:12 cmd/compile/internal/gc.(*importer).obj(0xc4204c48c0, 0xfffffffffffffffb)
12:02:12 	/usr/local/go/src/cmd/compile/internal/gc/bimport.go:293 +0x7c
12:02:12 cmd/compile/internal/gc.Import(0xc420013560)
12:02:12 	/usr/local/go/src/cmd/compile/internal/gc/bimport.go:97 +0xd64
12:02:12 cmd/compile/internal/gc.importfile(0xc420a71910, 0x0, 0x0, 0x0)
12:02:12 	/usr/local/go/src/cmd/compile/internal/gc/main.go:843 +0x1240
12:02:12 cmd/compile/internal/gc.(*parser).importdcl(0xc420a718f0)
12:02:12 	/usr/local/go/src/cmd/compile/internal/gc/parser.go:341 +0x1f4
12:02:12 cmd/compile/internal/gc.(*parser).import_(0xc420a718f0)
12:02:12 	/usr/local/go/src/cmd/compile/internal/gc/parser.go:300 +0x9c
12:02:12 cmd/compile/internal/gc.(*parser).file(0xc420a718f0)
12:02:12 	/usr/local/go/src/cmd/compile/internal/gc/parser.go:268 +0x6c
12:02:12 cmd/compile/internal/gc.parse_file(0xc420013440)
12:02:12 	/usr/local/go/src/cmd/compile/internal/gc/parser.go:31 +0x4c
12:02:12 cmd/compile/internal/gc.Main()
12:02:12 	/usr/local/go/src/cmd/compile/internal/gc/main.go:334 +0x1a70
12:02:12 cmd/compile/internal/ppc64.Main()
12:02:12 	/usr/local/go/src/cmd/compile/internal/ppc64/galign.go:72 +0x348
12:02:12 main.main()
12:02:12 	/usr/local/go/src/cmd/compile/main.go:41 +0x4e8
12:02:17 FAIL	github.com/docker/docker/api/server/router/network [build failed]
12:02:17 ?   	github.com/docker/docker/api/server/router/plugin	[no test files]
12:02:17 ?   	github.com/docker/docker/api/server/router/swarm	[no test files]
12:03:32 Build step 'Execute shell' marked build as failure

@thaJeztah re: flaky test I should have bumped up the retry check number too, it almost makes less sense to me that it works without it...
z test isn't related #32267
power failure looks pretty serious, @laboger are you aware of any ppc64le garbage collector bugs? The above error looks like one to me. (invoked from go test)

I am not aware of a garbage collector issue specific to ppc64le.  I found an older issue with the same type of stacktrace from go 1.5.1 on another platform that was never resolved because it was not reproducible.

:tada: from above greenland!

authors: AkihiroSuda LK4D4 ddingel estesp laboger thaJeztah tianon tonistiigi tophj-ibm


text:
Check /etc/resolv.conf every time for 127.* content

A continuation of @rhatdan's PR #8455, closes #8425.

I think this is related here.
I just installed Ubuntu 14.04 trusty tahr and I can see this same issue on my system.
$ docker -d -D
Stripped log
DEBU[0126] [BUILDER] Command to be executed: [/bin/sh -c apt-get update -y   && DEBIAN_FRONTEND=noninteractive apt-get install -y git curl nginx php5-cli php5-common php5-curl php5-dev php5-fpm php5-gd php5-json php5-mcrypt php5-mysql redis-server mysql-server-5.5]
DEBU[0126] [BUILDER] Cache miss
INFO[0126] No non localhost DNS resolver found in resolv.conf and containers can't use it. Using default external servers : [8.8.8.8 8.8.4.4]
INFO[0126] +job allocate_interface(31bb57dc34f78fbd3611fc397948aa9c053b1d6c60645fda018a1e747d9cc427)
INFO[0126] -job allocate_interface(31bb57dc34f78fbd3611fc397948aa9c053b1d6c60645fda018a1e747d9cc427) = OK (0)
INFO[0126] +job log(start, 31bb57dc34f78fbd3611fc397948aa9c053b1d6c60645fda018a1e747d9cc427, 7408807dc248)
INFO[0126] -job log(start, 31bb57dc34f78fbd3611fc397948aa9c053b1d6c60645fda018a1e747d9cc427, 7408807dc248) = OK (0)
INFO[0126] +job logs(31bb57dc34f78fbd3611fc397948aa9c053b1d6c60645fda018a1e747d9cc427)
INFO[0206] +job log(die, 31bb57dc34f78fbd3611fc397948aa9c053b1d6c60645fda018a1e747d9cc427, 7408807dc248)
INFO[0206] -job log(die, 31bb57dc34f78fbd3611fc397948aa9c053b1d6c60645fda018a1e747d9cc427, 7408807dc248) = OK (0)
INFO[0206] +job release_interface(31bb57dc34f78fbd3611fc397948aa9c053b1d6c60645fda018a1e747d9cc427)
INFO[0206] -job release_interface(31bb57dc34f78fbd3611fc397948aa9c053b1d6c60645fda018a1e747d9cc427) = OK (0)
INFO[0206] -job logs(31bb57dc34f78fbd3611fc397948aa9c053b1d6c60645fda018a1e747d9cc427) = OK (0)
The command [/bin/sh -c apt-get update -y   && DEBIAN_FRONTEND=noninteractive apt-get install -y git curl nginx php5-cli php5-common php5-curl php5-dev php5-fpm php5-gd php5-json php5-mcrypt php5-mysql redis-server mysql-server-5.5] returned a non-zero code: 100

I'm running Docker version 1.4.1, build 5bc2ff8 on my system. The fallback to docker chosen nameservers does not work either. Manually adding 8.8.8.8 and 8.8.4.4 in /etc/resolve.conf does not show No non localhost DNS resolver found in resolv.conf and containers can't use it. info but it does not work again. I tried running with docker -d -D --ip-masq=true (which I think is the default behavior) but the same thing.
Below is the log for build:-
Step 8 : RUN apt-get update -y   && DEBIAN_FRONTEND=noninteractive apt-get install -y git curl nginx php5-cli php5-common php5-curl php5-dev php5-fpm php5-gd php5-json php5-mcrypt php5-mysql redis-server mysql-server-5.5
 ---> Running in 67622dda437f
Err http://archive.ubuntu.com trusty InRelease

Err http://archive.ubuntu.com trusty-updates InRelease

Err http://archive.ubuntu.com trusty-security InRelease

Err http://archive.ubuntu.com trusty-proposed InRelease

Err http://archive.ubuntu.com trusty Release.gpg
  Could not resolve 'archive.ubuntu.com'
Err http://archive.ubuntu.com trusty-updates Release.gpg
  Could not resolve 'archive.ubuntu.com'
Err http://archive.ubuntu.com trusty-security Release.gpg
  Could not resolve 'archive.ubuntu.com'
Err http://archive.ubuntu.com trusty-proposed Release.gpg
  Could not resolve 'archive.ubuntu.com'
Reading package lists...
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty/InRelease

W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty-updates/InRelease

W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty-security/InRelease

W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty-proposed/InRelease

W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty/Release.gpg  Could not resolve 'archive.ubuntu.com'

W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty-updates/Release.gpg  Could not resolve 'archive.ubuntu.com'

W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty-security/Release.gpg  Could not resolve 'archive.ubuntu.com'

W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty-proposed/Release.gpg  Could not resolve 'archive.ubuntu.com'

W: Some index files failed to download. They have been ignored, or old ones used instead.
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package git
E: Unable to locate package nginx
E: Unable to locate package php5-cli
E: Unable to locate package php5-common
E: Unable to locate package php5-curl
E: Unable to locate package php5-dev
E: Unable to locate package php5-fpm
E: Unable to locate package php5-gd
E: Unable to locate package php5-json
E: Unable to locate package php5-mcrypt
E: Unable to locate package php5-mysql
E: Unable to locate package redis-server
E: Unable to locate package mysql-server-5.5
E: Couldn't find any package by regex 'mysql-server-5.5'
INFO[0081] The command [/bin/sh -c apt-get update -y   && DEBIAN_FRONTEND=noninteractive apt-get install -y git curl nginx php5-cli php5-common php5-curl php5-dev php5-fpm php5-gd php5-json php5-mcrypt php5-mysql redis-server mysql-server-5.5] returned a non-zero code: 100

authors: jfrazelle techgaun


text:
Adds Docker Image v1 Spec Documention

Docker-DCO-1.1-Signed-off-by: Josh Hawn josh.hawn@docker.com (github: jlhawn)

lgtm. No doubt there are still nits to be picked, but this is a great step forward in unambiguously-described behavior. Thanks for your time and effort in compiling it.

lgtm. No doubt there are still nits to be picked, but this is a great step forward in unambiguously-described behavior. Thanks for your time and effort in compiling it.

@jlhawn Any more edits remaining?
There is no reason for shykes to look at this if you are just documenting the reality of the current system.

Correct, if we're documenting today's design don't feel obligated to wait for my +1

@crosbymichael I think I just need to add in the User field description from @tianon and we're set!

This is brilliant. Thanks @jlhawn. I'm really glad we're taking steps towards specifying how Docker works.
Perhaps we could this in for Docker 1.5 and shout about it a bit. ^_^

I don't know what we are waiting on @jlhawn

Maybe just a squash of commits?

@jfrazelle All squashed!

awesome!

Thanks @jlhawn!

I was talking to @shykes about this at the dockercon in amsterdam...great job guys!

authors: bfirsh crosbymichael jfrazelle jlhawn mmdriley odino shykes thaJeztah


text:
don't close the write connection on docker attach

I would ask that docker attach not closes the right side of the connection. This is a rather uncommon practice with makes it incredibly hard to implement API compatible services as not many libraries support this kind of behaviour.
To underline this point: hijack.go Line 83 copies out a function from the library it uses for SSL as not even the libraries used by docker itself implement this behavior.
// We need to copy Go's implementation of tls.Dial (pkg/cryptor/tls/tls.go) in
// order to return our custom tlsClientCon struct which holds both the tls.Conn
// object _and_ its underlying raw connection. The rationale for this is that
// we need to be able to close the write end of the connection when attaching,
// which tls.Conn does not provide.

https://github.com/docker/engine-api/blob/4290f40c056686fcaa5c9caf02eac1dde9315adf/client/hijack.go#L83

oops depricated repo

repo: docker/engine-api

license_source: bigquery


text:
Missing container for homeassistant's raspberrypi3

Information about the Issue
(HTTP code 404) unexpected - {"message":"manifest for homeassistant/raspberrypi3-homeassistant:latest not found"}
Steps to reproduce the behavior

query for the container in kitematic and select create
or, run the pull command specified by the author "docker pull homeassistant/raspberrypi3-homeassistant"

Go to https://hub.docker.com/r/homeassistant/raspberrypi3-homeassistant/tags/
Observe no latest tags were created for that image
Select a different tag in Kitematic (if one exists)
🎉  enjoy container running.

Ideally you open an issue with the repo owner to let them know how frustrating it is that they don't have a latest image tagged

Thanks for the quick reply.

On Apr 19, 2018, at 9:04 PM, French Ben notifications@github.com wrote:
Go to https://hub.docker.com/r/homeassistant/raspberrypi3-homeassistant/tags/
Observe no latest tags were created for that image
Select a different tag in Kitematic (if one exists)
🎉 enjoy container running.
Ideally you open an issue with the repo owner to let them know how frustrating it is that they don't have a latest image tagged
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

authors: FrenchBen pschatz

repo: docker/kitematic


text:
add unnessesary duplicate iptables rule(table: nat , chain: POSTROUTING)when use --live-restore

The dockerd is started with the --live-restore.  Then I run a container with the nginx image. The  container port 80 is mapped to the host.
So dockerd add a rule to the chain POSTROUTING  of  the nat table
Chain POSTROUTING (policy ACCEPT 2 packets, 656 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 MASQUERADE  all  --  *      !docker0  172.17.0.0/16        0.0.0.0/0
    0     0 MASQUERADE  all  --  *      !br-37930fd1fd54  172.18.0.0/16        0.0.0.0/0
    0     0 MASQUERADE  tcp  --  *      *       172.17.0.3           172.17.0.3           tcp dpt:80

Then  stop the dockerd. As the flag live-restore is set, the container is alive. Then start the dockerd.
Chain POSTROUTING (policy ACCEPT 2 packets, 656 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 MASQUERADE  all  --  *      !docker0  172.17.0.0/16        0.0.0.0/0
    0     0 MASQUERADE  all  --  *      !br-37930fd1fd54  172.18.0.0/16        0.0.0.0/0
    0     0 MASQUERADE  tcp  --  *      *       172.17.0.3           172.17.0.3           tcp dpt:80
    0     0 MASQUERADE  tcp  --  *      *       172.17.0.3           172.17.0.3           tcp dpt:80

every time I restart the dockerd，a duplicate rule will be added to the POSTROUTING chain
We use the live-restore flag， So the dockerd will not clean the iptables when stopping.  When we start the docker daemon agin, it will restore the containers including their network. So It will add the duplicate rule(https://github.com/docker/docker/blob/v1.12.0/vendor/src/github.com/docker/libnetwork/portmapper/mapper.go#L137-L138).
I think it should check the existence of the rule first.
this is a bug of libnetwork
root@ubuntu:~# docker version
Client:
 Version:      1.12.0
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   8eab29e
 Built:        Thu Jul 28 22:00:36 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.0
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   8eab29e
 Built:        Thu Jul 28 22:00:36 2016
 OS/Arch:      linux/amd64

root@ubuntu:~# docker info
Containers: 9
 Running: 2
 Paused: 0
 Stopped: 7
Images: 5
Server Version: 1.12.0
Storage Driver: overlay
 Backing Filesystem: extfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge null host overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: apparmor
Kernel Version: 4.2.0-27-generic
Operating System: Ubuntu 14.04.4 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 989.1 MiB
Name: ubuntu
ID: LPPS:CUI5:DASX:6AO2:WWPA:FFY7:NV6D:XGIR:ZKE2:MQ27:NXT5:TIUO
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 22
 Goroutines: 36
 System Time: 2016-09-30T04:41:11.752426019+08:00
 EventsListeners: 0
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Insecure Registries:
 127.0.0.0/8

What is your iptables version ?

root@ubuntu:~# iptables --version
iptables v1.4.21

Yes this is something we did not take care (given we were flushing the tables) and surfaced again when using --live-restore, as you explained.
Will take care of this.

authors: aboch shaloulcy

repo: docker/libnetwork


text:
Expose API to manage lifecycle of the cluster root CA material

During the lifecycle of a swarm it is desirable to be able to manage the root CA material to perform tasks such as explicit rotation or changing between internal CA and external CA .  The material would ideally be encrypted to prevent leakage of the root key.

We have root CA rotation now, which supports switching between internal and external CAs as well. Closing.

authors: aaronlehmann dhiltgen

repo: docker/swarmkit


text:
Can BBS+ signature be a delegatable credentials

I am new to zero-knowledge proofs and would like to ask how the contents of the delegatable_credentials/ directory can be combined with BBS+signatures. Can a BBS+ signature be a delegatable credential？

Signature schemes used in delegatable_credentials are different and BBS+ isn't compatible with those.

repo: docknetwork/crypto


text:
Added CouchDB configuration example

Added CouchDB configuration example with https://github.com/doctrine/couchdb-client reference (because still not at RC stability level).

:+1:

authors: EmanueleMinotto Ocramius

repo: doctrine/KeyValueStore

license: mit


text:
Memory leak in detach

Memory leak test:
<?php

require_once '../vendor/autoload.php';
require_once 'Doc.php';

use Doctrine\MongoDB\Connection;
use Doctrine\ODM\MongoDB\Configuration;
use Doctrine\ODM\MongoDB\DocumentManager;
use Doctrine\ODM\MongoDB\Mapping\Driver\AnnotationDriver;

AnnotationDriver::registerAnnotationClasses();

class Test
{
    const COUNT = 200;
    const ITERATIONS = 20;

    /**
     * @var DocumentManager
     */
    protected $dm;
    protected $inc = 1;

    public function test1()
    {
        $docs = [];
        for ($i = 0; $i < self::COUNT; $i++) {
            $doc = $this->createDoc();
            $this->dm->persist($doc);
            $docs[] = $doc;
        }
        $this->dm->flush();
        foreach ($docs as $doc) {
            $this->dm->detach($doc);
        }
    }

    public function test2()
    {
        for ($i = 0; $i < self::COUNT; $i++) {
            $doc = $this->createDoc();
            $this->dm->persist($doc);
        }
        $this->dm->flush();
        $this->dm->clear('Doc');
    }

    public function test3()
    {
        for ($i = 0; $i < self::COUNT; $i++) {
            $doc = $this->createDoc();
            $this->dm->persist($doc);
        }
        $this->dm->flush();
        $this->dm->clear();
    }

    protected function clear()
    {
        $config = new Configuration();
        $config->setProxyDir('/tmp/test');
        $config->setProxyNamespace('Proxies');
        $config->setHydratorDir('/tmp/test');
        $config->setHydratorNamespace('Hydrators');
        $config->setMetadataDriverImpl(AnnotationDriver::create(__DIR__));

        if ($this->dm) {
            $this->dm->close();
        }
        $this->dm = DocumentManager::create(new Connection(), $config);
        $this->dm->getDocumentCollection('Doc')->remove([]);
        $this->inc = 1;
    }

    public function run()
    {
        echo "Test1\n";
        $this->clear();
        for ($i = 0; $i < self::ITERATIONS; $i++) {
            $this->test1();
            $this->mem();
        }

        echo "\n\nTest2\n";
        $this->clear();
        for ($i = 0; $i < self::ITERATIONS; $i++) {
            $this->test2();
            $this->mem();
        }

        echo "\n\nTest3\n";
        $this->clear();
        for ($i = 0; $i < self::ITERATIONS; $i++) {
            $this->test3();
            $this->mem();
        }
    }

    private function createDoc()
    {
        $doc = new Doc();
        $doc->id = $this->inc++;
        $doc->name = str_repeat(md5($this->inc), 40);
        return $doc;
    }

    private function mem()
    {
        echo sprintf("%.2fM\n", memory_get_usage() / 1024 / 1024);
    }
}

$test = new Test();
$test->run();

test1 and test2 has memory leaks.
Test1
3.23M
3.55M
3.87M
4.19M
4.57M
4.90M
5.21M
5.53M
5.85M
6.17M
6.62M
6.94M
7.26M
7.58M
7.89M
8.21M
8.53M
8.85M
9.16M
9.48M

Test2
3.45M
3.77M
4.09M
4.40M
4.72M
5.05M
5.37M
5.68M
6.00M
6.32M
6.65M
6.97M
7.29M
7.61M
7.93M
8.25M
8.56M
8.88M
9.20M
9.52M

Test3
3.14M
3.14M
3.14M
3.14M
3.14M
3.14M
3.14M
3.14M
3.14M
3.14M
3.14M
3.14M
3.14M
3.14M
3.14M
3.14M
3.14M
3.14M
3.14M
3.14M

Upd: setting ODM\Id(strategy="NONE") fixes the leak

Spoke with @malarzm about this and he believes the leak is likely because we track the document with the integer ID you generate but later expect an ObjectId. A solution here might be to throw exceptions if you're using the AUTO strategy and aren't using ObjectIds.

@jmikola I think exception would be nice solution. Also exception should be thrown when id = null and strategy set to NONE (At this moment id generates implicitly)

Also exception should be thrown when id = null and strategy set to NONE (At this moment id generates implicitly)

For this I've created https://github.com/doctrine/mongodb-odm/issues/1183 recently, will do both things at a time :)

authors: jmikola malarzm sirian

repo: doctrine/mongodb-odm


text:
Getting 403 error when using scraper script

I tried running the script and was getting a 403 error. I ran it with headless: false and saw that the program was getting caught up on the Cloudflare captcha check, do you have any possible solutions for this? Is it still working on your end?

It looks like PCPP have increased their anti-VPN security measures. I tried modifying the script to give me time to solve the captcha, but when I do that it either closes the tab or the check fails. It works after disabling my VPN though. I can try to look into this a bit more but it looks like you're just going to have to wing it on your home WiFi for now.

It's working using PIA vpn for me.

authors: chrisowen2015 docyx guipace

repo: docyx/pc-part-dataset

license: MIT


text:
security: apply least-privilege by removing chown on binaries

I was triggered by the test shown in #33 because chowning files under /usr/local to be owned by a user is not a good practice.
It is not needed for dogecoin:dogecoin to have permissions on binaries installed in /usr/local/bin because we allow anyone to
execute these anyway through the chmod 4555. All the chown directive really does is give running processes like dogecoind access to these files, which the process then can chmod and subsequently overwrite.
Instead, let root own the files, but keep allowing execution by anyone, which will disallow a process spawned by the dogecoin user to change these files - this reduces potential impact of future / unknown remote code execution vulnerabilities in Dogecoin Core.
Before this PR, a process running as dogecoin:dogecoin inside the container could for example perform the equivalent of chmod 755 /usr/local/bin/dogecoin-cli && echo "#!/bin/bash\necho je suis un virus" > /usr/local/bin/dogecoin-cli. After this PR, it cannot.

Missed that setuid depends on this - doing more tests, reverting to draft.

Yes, the intent of this chown and setuid was for  docker exec commands. It allowed any users who will run a dogecoin executable to run it as dogecoin user (vs run as root otherwise) without using docker exec --user dogecoin.

executable to run it as dogecoin user

Which means that it always runs it as the kernel's 1001:1001 (of the HOST) right now, with no way to change it. So if I'm 1002:1002 on the host, I will give wallet access to 1001:1001... This is a big issue.

My main host user is uid 1000. I create a new user bob with uid 1001. bob start a container, has a bash as root, adduser inside the container. bob new user is now uid 1000 🤦.
I missed something with Docker permissions...

I'm closing this, will raise an issue.

authors: AbcSxyZ patricklodder

repo: dogecoin/docker


text:
fix react unknown prop warning

fixes react unknown prop warning, #42. use delete instead variable creating, #43.

reference for reasoning for this PR - https://github.com/JedWatson/react-tappable/blob/master/src/getComponent.js#L45

repo: dogfessional/react-swipeable


text:
[d3d9] The Witcher EE - missing clouds / sky textures

Related to #1399, regarding the missing sky textures when the in-game visibility range is set to "Far" (anything below will bring back the clouds).
The sun may be missing as well with dxvk considering the missing reflections/refraction in the water. All I have are cloudy weather saves (still better than negative thoughts), but if you think it's useful, I can dig a little and confirm this as well.
WineD3D will render everything correctly even on "Far":

Software information
The Witcher EE (GOG version, latest build).
System information

GPU: GeForce GTX 1070
Driver: 440.48.2
Wine version: 5.1 Staging
DXVK version: v1.5.3+87dd8f01

Apitrace file(s)
witcher.trace.tar.xz
Log files

d3d9.log: witcher_d3d9.log
d3d11.log: N/A
dxgi.log: N/A

... and the missing sun is confirmed by #1402 :)

Should be fixed with the PR mentioned above:

authors: WinterSnowfall doitsujin

repo: doitsujin/dxvk

license: Zlib


text:
Gentoo - can't compile, bunch of errors

I'm trying to compile dxvk from source, but I get these errors when running ninja (both 32&64 bit):
https://pastebin.com/q1C6uT87
I have these packages versions:
wine-vulkan 3.3 (from roderikc's git) compiled with vulkan and 64bit support
meson 0.44.1 (portage)
migw64 5.0.3-r1 (portage)
glslang 6.2.2596 (portage)
I need it to test Rotscha's workaround here #127, but I get the errors even with a clean source tree, any help is appreciated thanks

Your mingw build does not seem to have pthread support.

How do I check it? Is there a test I can do? I think I built it correctly with pthread support.

I don't know since I'm not running Gentoo, but apparently the mingw binaries with threading support have a -pthread suffix on Debian/Ubuntu systems, maybe it's the same for your setup.

or thread_dep = dependency('threads') from src/dxvk/meson.build don't work as expected.
For me it don't, despite description on http://mesonbuild.com/howtox.html#enable-threads and I have to use -lpthread instead but not with mingw. Can be meson notabug.

I'm using Gentoo as well. The instructions listed on https://bugs.gentoo.org/631460 help to work around the issue and let me compile dxvk.

Any Gentoo user with an ebuild yet? Also a Gentoo user here, not sure how to write an ebuild for a different toolchain. Probably something that shouldn't be done, but... :)

Be wary of using the crossdev toolchain. I've used the most recent testing[1] mingw toolchains installed by crossdev for 32 and 64 bit and they produced dlls that crashed Final Fantasy X HD without an error while the precompiled ones from https://haagch.frickel.club/files/dxvk/ do not (See #187). There seems to be something wrong with at least the 32-bit toolchain.
[1]:

binutils 2.30 (with the patch from https://github.com/gentoo/binutils-gdb/commit/810414c2470b2306d04413ec6ecfe8424bd58a28)
gcc 7.3.0
mingw64-runtime 5.0.3-r1

I have the same problem, ShadowsFriend. When compiled with crossdev toolchain (gcc 7.3.0), Witcher 3 crashes immediately when run. I may try the crossdev stable option to rule out problems with the more recent toolchain packages.

My builds just use the opensuse mingw build as described in https://haagch.frickel.club/files/dxvk/how_to_docker_build.txt
I have not updated that docker container for a while so the mingw used is maybe not the newest version.

I just tested it, and the stable crossdev toolchain (-S/--stable) fixes the problem. This is with gcc-6.4.0, binutils-2.29.1-r1, mingw64-runtime-5.0.3-r1.

That indeed works. Thank you very much, thirdeyefunction! I also did a quick test with the goal to determine whether it's gcc or binutils by trying different combinations (old gcc with new binutils and vice versa). Neither of those combinations worked, which means it's both together -- unless I made a mistake.

Ok, I think I have working MinGW GCC 8.1 on Gentoo now.
No problems so far.
$ eix -Ic cross-*/*
[I] cross-x86_64-w64-mingw32/binutils [1] (2.29.1-r1(2.29.1)@04.04.18 2.30-r2(2.30)@02.05.18): Tools necessary to build programs
[I] cross-x86_64-w64-mingw32/gcc [1] (6.4.0-r1(6.4.0)@04.04.18 8.1.0(8.1.0)@03.05.18): The GNU Compiler Collection
[I] cross-x86_64-w64-mingw32/mingw64-runtime [1] (5.0.3-r2@04.04.18): Free Win64 runtime and import library definitions

I'm building dxvk with GCC 7.3.0 on Gentoo, no problems. The only issue as compiling mingw with pthreads, had to modify gcc eclass.

I can actually confirm that the toolchains listed below do produce working binaries. The only reason for using mingw64-runtime-5.0.3-r1 instead of r2 for x86_64 is the issue described under [1].
[1] https://bugs.gentoo.org/653246
[I] cross-i686-w64-mingw32/binutils [2] (2.30-r2(2.30)@10.05.2018)
[I] cross-i686-w64-mingw32/gcc [2] (7.3.0-r1(7.3.0)@10.05.2018)
[I] cross-i686-w64-mingw32/mingw64-runtime [2] (5.0.3-r2@10.05.2018)

[I] cross-x86_64-w64-mingw32/binutils [2] (2.30-r2(2.30)@10.05.2018)
[I] cross-x86_64-w64-mingw32/gcc [2] (7.3.0-r1(7.3.0)@10.05.2018)
[I] cross-x86_64-w64-mingw32/mingw64-runtime [2] (5.0.3-r1@10.05.2018)

@ShadowsFriend How did you enable ptreahds support on crossdev mingw on Gentoo? I had to fork the toolchain eclass to do so.

I edited my previous post containing the answer to your question while you were posting it. Because I am uncertain if mentioning someone in an edit actually does notify the person, I decided to write this post to make sure my answer reaches you.

I was able to build dxvk without issues following instructions written down here, which include setting up the cross-gcc to use posix pthreads. Can anyone else confirm that it's a fix for them as well?

I've been building mine just fine for like months. This issue can be closed I guess.

I have skimmed over the instructions linked by you, Wesmania, and they seem to be a concise version of what I did to get it work. So I would say the link is a good source of information for fellow Gentoo users struggling to get the cross toolchain up for DXVK.

FYI: as an alternative you can try winelib builds ( #520 ). This don't require mingw but utilizes WINE's winegcc wrapper instead to compile sources via GCC.

I have created POC overlay for dxvk winelib builds.
+ support both 32 and 64 bit builds (0.70 patched to current git master)

+ each version have it's own slot, so multiple versions can be installed at the same time

+ hacked `setup_dxvk.sh` to use with multi-version, e.g.:
  dxvk-setup-0.70
  dxvk-setup-9999
  dxvk-setup-amd64-0.70
  dxvk-setup-amd64-9999
  dxvk-setup-x86-0.70
  dxvk-setup-x86-9999

- custom cflags not supported (due to meson.eclass simplicity and/or my incompetence)
  'release' build type used atm

- dirty hacks here and there in ebuild code

- own custom setup script / verb needed, existing ones are very dll/mingw specific

- not tested

This will emerge DXVK using winegcc and setup symlinks/overrides for your wine prefix:
# emerge -1 games-util/dxvk:0.70 games-util/dxvk:9999 -q

$ WINEPREFIX=/path/to/prefix dxvk-setup-9999

@pchome Great stuff.
~ $ WINEPREFIX=/mnt/storage/wine/64 dxvk-setup-9999
wine: configuration in '/mnt/storage/wine/64' has been updated.
[1/5] dxgi:
    [1/2] Creating override... The operation completed successfully.
    [2/2] Creating link to dxgi.dll.so... Done.
(...)
[5/5] d3d11:
    [1/2] Creating override... The operation completed successfully.
    [2/2] Creating link to d3d11.dll.so... Done.

And it's running well. But how about the git tag "g4c8bf44"? I don't find the commit in the dxvk repository.
info:  DXVK: v0.70-5-g4c8bf44
warn:  OpenVR: Failed to locate module
info:  Enabled instance extensions:
info:    VK_KHR_get_physical_device_properties2
info:    VK_KHR_surface
info:    VK_KHR_win32_surface
info:  AMD RADV POLARIS10 (LLVM 8.0.0):
info:    Driver: 18.2.99
info:    Vulkan: 1.1.70

@edmondo

But how about the git tag "g4c8bf44"? I don't find the commit in the dxvk repository.

It's 4c8bf44 I guess. But I don't know what 5-g mean, some kind of patched version indicator.
I'm using patch from #575 for both 0.70 and 9999 for now.

Ah, now I slowly get it :)
It's just the output of git describe

We really should be able to build with wineg++ rather than mingw. However, there seems to be a regression in wine that causes it to try to link the 64-bit libwinecrt0.a into the 32-bit binary. Trying to do wineg++ -m32 hello.c for example will fail:
x86_64-pc-linux-gnu-ld: Relocatable linking with relocations from format elf64-x86-64 (/usr/lib64/wine-staging-3.9/wine/libwinecrt0.a(exe_entry.o)) to format elf32-i386 (a.E9mdEC.o) is not supported
winebuild: x86_64-pc-linux-gnu-ld failed with status 1
winegcc: winebuild failed

As for a 64-bit build, we hit the following:
wineg++  -o src/dxgi/dxgi.dll.so 'src/dxgi/src@dxgi@@dxgi.dll@sha/dxgi_adapter.cpp.o' 'src/dxgi/src@dxgi@@dxgi.dll@sha/dxgi_device.cpp.o' 'src/dxgi/src@dxgi@@dxgi.dll@sha/dxgi_enums.cpp.o' 'src/dxgi/src@dxgi@@dxgi.dll@sha/dxgi_factory.cpp.o' 'src/dxgi/src@dxgi@@dxgi.dll@sha/dxgi_format.cpp.o' 'src/dxgi/src@dxgi@@dxgi.dll@sha/dxgi_main.cpp.o' 'src/dxgi/src@dxgi@@dxgi.dll@sha/dxgi_options.cpp.o' 'src/dxgi/src@dxgi@@dxgi.dll@sha/dxgi_output.cpp.o' 'src/dxgi/src@dxgi@@dxgi.dll@sha/dxgi_presenter.cpp.o' 'src/dxgi/src@dxgi@@dxgi.dll@sha/dxgi_swapchain.cpp.o' ../src/dxgi/dxgi.spec -Wl,--no-undefined -Wl,--as-needed -Wl,-O1 -shared -fPIC -Wl,--start-group -Wl,-soname,dxgi.dll.so src/util/libutil.a src/dxvk/libdxvk.a src/spirv/libspirv.a -lwinevulkan -Wl,--end-group -m64 -mwindows
src/dxvk/libdxvk.a(vulkan_dxvk_vulkan_loader.cpp.o): In function `dxvk::vk::DeviceLoader::DeviceLoader(VkInstance_T*, VkDevice_T*)':
dxvk_vulkan_loader.cpp:(.text+0x4d): undefined reference to `native_vkGetInstanceProcAddrWINE'
src/dxvk/libdxvk.a(vulkan_dxvk_vulkan_loader.cpp.o): In function `dxvk::vk::LibraryLoader::sym(char const*) const':
dxvk_vulkan_loader.cpp:(.text+0x3): undefined reference to `native_vkGetInstanceProcAddrWINE'
src/dxvk/libdxvk.a(vulkan_dxvk_vulkan_loader.cpp.o): In function `dxvk::vk::InstanceLoader::sym(char const*) const':
dxvk_vulkan_loader.cpp:(.text+0x25): undefined reference to `native_vkGetInstanceProcAddrWINE'
collect2: error: ld returned 1 exit status
winegcc: x86_64-pc-linux-gnu-g++ failed

This patch will address both of them. However, it relies on a path that is dependent on the version of wine that you have installed to get the 32-bit version to build, so it isn't appropriate to merge:
diff --git a/build-wine32.txt b/build-wine32.txt
index 75c4f30..a0aeac6 100644
--- a/build-wine32.txt
+++ b/build-wine32.txt
@@ -9,8 +9,8 @@ needs_exe_wrapper = true
 winelib = true

 c_args=['-m32']
-cpp_args=['-m32', '--no-gnu-unique', '-Wno-attributes']
-cpp_link_args=['-m32', '-mwindows']
+cpp_args=['-m32', '--no-gnu-unique', '-Wno-attributes', '-Dnative_vkGetInstanceProcAddrWINE=wine_vkGetInstanceProcAddr']
+cpp_link_args=['-m32', '-mwindows', '/usr/lib32/wine-staging-3.9/wine/libwinecrt0.a', '-L/usr/lib32/wine-staging-3.9']

 [host_machine]
 system = 'linux'
diff --git a/build-wine64.txt b/build-wine64.txt
index f4a69cd..316b306 100644
--- a/build-wine64.txt
+++ b/build-wine64.txt
@@ -9,7 +9,7 @@ needs_exe_wrapper = true
 winelib = true

 c_args=['-m64']
-cpp_args=['-m64', '--no-gnu-unique', '-Wno-attributes']
+cpp_args=['-m64', '--no-gnu-unique', '-Wno-attributes', '-Dnative_vkGetInstanceProcAddrWINE=wine_vkGetInstanceProcAddr']
 cpp_link_args=['-m64', '-mwindows']

 [host_machine]

Then building the 32-bit and 64-bit versions just requires the following:
meson --cross-file build-wine64.txt --prefix /tmp/dxvk64 build.w64
cd build.w64
meson configure -Dbuildtype=release
ninja
ninja install

meson --cross-file build-wine32.txt --prefix /tmp/dxvk32 build.w32
cd build.w32
meson configure -Dbuildtype=release
ninja
ninja install

I have not actually tested these to see if they work, but I have no reason to think otherwise.

@zolfone Did you consider at any point filing a Gentoo bug report about this or pinging one of the Gentoo developers involved with either wine or crossover downstream maintenance? If you had pinged me for instance, I probably would have helped. ;)
@doitsujin How does this even build for you? I could understand you having a version of wine installed that doesn't have the -m32 regression, but I see no way to make this build without modifying your build-wine{32,64}.txt files to change the symbol for native_vkGetInstanceProcAddrWINE.

@ryao

native_vkGetInstanceProcAddrWINE

At the moment, I am still perplexed by how the thing even compiles for people because it references native_vkGetInstanceProcAddrWINE, which does not exist. I had to pass -Dnative_vkGetInstanceProcAddrWINE=wine_vkGetInstanceProcAddr to the preprocessor to make it happy.

Some clarifications:

#583
wine-3.14 or simply grab corresponding commit(s) from WINE git for older WINE versions
or you hacking build system and forgot to add -lwinevulkan dependency

Is this still an issue by the way or can this be closed?

authors: ChristophHaag ShadowsFriend Wesmania doitsujin edmondo pchome ryao saboya thirdeyefunction zolfone


text:
[sozo] support constructor arguments during deployment

Is your feature request related to a problem? Please describe.
currently we deploy base contract and replace class hash for actual contract so we cannot use constructor directly.
Describe the solution you'd like
use new initializer function that will act as a constructor
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
arguments of constructor will be given in overlays file and support some kind of variable for contract class hash and contract addresses

assign me this will love to work on this

@ebukizy1 this feature will be bit involved so will require some architecture changes, so it would be better if someone from team works on this

repo: dojoengine/dojo


text:
feat: [mqtt/vernemq/v2k-bridge] add v2k-bridge service

Please check if the PR fulfills these requirements

[x] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
feature

What is the current behavior? (You can also link to an open issue here)

What is the new behavior (if this is a feature change)?
Adds an initial version of the v2k-bridge connector and a GitHub action to run it's unit tests.
Build a payload with all received messages from a broker then produce this payload to Kafka.

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

Is there any issue related to this PR in another repository? (such as dojot/dojot)

#1330

Other information:

@thiagodpf
The scripts inside the connector/mqtt/vernemq/v2k-brigde/bin/scripts_tls/*  were made by me, I know they are not good, I didnt improve because they will probably die.

I left some comments just as a note, I believe there is no need to change the code, but I made suggestions on how I would approach the script

@thiagodpf
The scripts inside the connector/mqtt/vernemq/v2k-brigde/bin/scripts_tls/* were made by me, I know they are not good, I didnt improve because they will probably die.

authors: jonaphael mprevide

repo: dojot/dojot


text:
🛑 introdex.io is down

In 6984f62, introdex.io (https://introdex.io) was down:

HTTP code: 456
Response time: 644 ms

Resolved: introdex.io is back up in b831e06 after 15 minutes.

repo: dokazhi/dkz-uptime


text:
wip: feat: build support for dockerignore

Still have some additional work to do, but the intent is to resolve https://github.com/dollarshaveclub/furan/issues/84
Since we never write the tar to disk, it doesn't seem like we can use the exact same methodology as the docker cli: https://github.com/docker/cli/blob/f019bdcace678c71690a99f6c5f30303c33534bc/cli/command/image/build.go#L288.
However, we can use some of the exposed methods the docker/docker pkgs provide in order to match the behavior.

Nice. LGTM so far.

authors: bkeroackdsc mikeykhalil

repo: dollarshaveclub/furan


text:
[auto-bump] dependency by reltuk

:coffee: An Automated Dependency Version Bump PR :crown:
Initial Changes
The initial changes contained in this PR were produced by go geting the dependency.
$ cd ./go
$ go get github.com/dolthub/<dependency>/go@<commit>
$ go mod tidy

Before Merging
This PR must have passing CI and a review before merging.
After Merging
An automatic PR will be opened against the LD repo that bumps the bounties version there.

This PR has been superseded by https://github.com/dolthub/bounties/pull/1263

repo: dolthub/bounties


text:
Trigger view errors don't prevent writes on database with preexisting trigger views

PR https://github.com/dolthub/go-mysql-server/pull/2034 made it so that we can not DDL triggers on views. But past versions of Dolt permitted creating those triggers. After this change, databases with a trigger view will be have all writes blocked with the trigger view error. We should probably not try to parse and bind all triggers for every write, but as long as we do this adds a warning rather than an error for a non-DDL trigger parse.

thanks for the reviews, sending

repo: dolthub/go-mysql-server


text:
Use comparandExprs as keyExprs for indexed joins

Fix #479

I don't fully understand why the code deleted in the PR was written the way it was in the first place. The necessary expressions (in my understanding) seem to already have been collected in the join index. All I had to do was use them. This doesn't break any tests so I assume this is a safe change, but I could be mistaken. If anyone sees anyone reason why it shouldn't be done this way, please let me know.

Since this does seem to be breaking tests I will take a look at the failures when I get a chance.

The reason this doesn't work is that you have to match the order of the comparands to the order of the index expressions, that's what the loop is doing

Alright, I'll take another look at that loop.

authors: andremarianiello zachmu


text:
Installing Nuget package in VS 2017

When trying to install nuget package in Visual Studio 2017 for ASP.Net core 1.1.
Get error Unable to load package 'Swashbuckle.AspNetCore.SwaggerUI'.
More info...
Failed to download package 'Swashbuckle.AspNetCore.Swagger.1.0.0-rc3' from 'https://www.myget.org/F/domaindrivendev/api/v3/flatcontainer/swashbuckle.aspnetcore.swagger/1.0.0-rc3/swashbuckle.aspnetcore.swagger.1.0.0-rc3.nupkg'.
An error occurred while sending the request.
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
The remote certificate is invalid according to the validation procedure.

I was able to install it from the nuget.org feed just fine a few seconds ago. and as of right now the myget ssl looks ok to me. you should try it again or switch to the nuget.org feed

I'm also unable to repro this issue. I'm going to close for now but please feel free to re-open if you have more details and can provide a consistent set of repro steps

authors: Riaanvdw domaindrivendev erendrake