Description of the Pull Request (PR):

First the umoci is upgrade to 0.4.6, a taged version which supports MacOS. Then the internal/pkg/build/sources/oci_unpack_darwin.go is removed.

However it can't be tested, since the MacOS build seems broken for a long time...

This fixes or addresses the following GitHub issues:

• Fixes #

Before submitting a PR, make sure you have done the following:

• Read the Guidelines for Contributing, and this PR conforms to the stated requirements.
• Added changes to the CHANGELOG if necessary according to the Contribution Guidelines
• Added tests to validate this PR and tested this PR locally with a make testall
• Based this PR against the appropriate branch according to the Contribution Guidelines
• Added myself as a contributor to the Contributors File

Attn: @singularity-maintainers

Description of the Pull Request (PR):

The exit code of os/exec.Command is easy to get, no need to import docker's system package.

This fixes or addresses the following GitHub issues:

• Fixes #

Before submitting a PR, make sure you have done the following:

• Read the Guidelines for Contributing, and this PR conforms to the stated requirements.
• Added changes to the CHANGELOG if necessary according to the Contribution Guidelines
• Added tests to validate this PR and tested this PR locally with a make testall
• Based this PR against the appropriate branch according to the Contribution Guidelines
• Added myself as a contributor to the Contributors File

Attn: @singularity-maintainers

TestConnectCALeaf_changingRootsBetweenBlockingCalls and TestConnectCALeaf_CSRRateLimiting failed, seems unrelated.

I didn't change the ephemeral_darwin.go since I don't have a mac. But it could be updated as well. Try strace -e file sysctl -n to see what file sysctl will read.

This drops the dependency of sysctl command

@zhsj I think, neither Debian nor Archlinux try builds in 1-core VMs. Only I do for openSUSE. As far as I know, they only vary -j $n to $n-1

the typical go variation for me looks like this then: https://rb.zq1.de/compare.factory-20201001/katacontainers-compare.out

in https://github.com/kubernetes/kubernetes/issues/70131#issuecomment-585603403 you said it was built with go1.13. However iirc the reproducible build for Go is improved in go1.14.

And have you opened issue for Go upstream? If -jN will affect the result, it really should be fixed in Go upstream.

As well as archlinux https://github.com/archlinux/svntogit-community/blob/packages/containerd/trunk/PKGBUILD just use -trimpath and is reproducible-build https://tests.reproducible-builds.org/archlinux/community/containerd/containerd-1.4.1-1-x86_64.pkg.tar.zst.html

As https://github.com/golang/go/issues/33772 is fixed in Go1.14. I'm curious why it is still problem for buildid?

And as show in https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/containerd.html it's reproducible on amd64 and i386. Though we don't use upstream Makefile, but we don't set buildid to null, just -trimpath.

1. What version of Delve are you using (dlv version)?

$ git log --oneline -1
9a3c9eba (HEAD -> master, origin/master, origin/HEAD) proc/*: add launch option to disable ASLR (#2202)

2. What version of Go are you using? (go version)?

$ go version
go version go1.15.2 linux/arm64

3. What operating system and processor architecture are you using?

$ cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux bullseye/sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

$ lscpu
Architecture:        aarch64
Byte Order:          Little Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):           1
NUMA node(s):        1
Vendor ID:           APM
Model:               1
Model name:          X-Gene
Stepping:            0x0
BogoMIPS:            100.00
NUMA node0 CPU(s):   0-3
Flags:               fp asimd evtstrm cpuid

4. What did you do?

I'm going to package delve for Debian. But the tests fail on arm64. https://buildd.debian.org/status/fetch.php?pkg=delve&arch=arm64&ver=1.5.0-4&stamp=1603213253&raw=0

It's also reproducible with master.

5. What did you expect to see?

The tests succeed.

6. What did you see instead?

(sid_arm64-dchroot)zhsj@amdahl:~/t/delve$ go test -mod=vendor -v ./service/test/ -run TestCgoEval                                                                          
=== RUN   TestCgoEval
    support.go:248: enabling recording for github.com/go-delve/delve/service/test_test.TestCgoEval                                                                         
    variables_test.go:68: Expected "\"a string\"" got "(unreadable could not read string at 0x8020080280200802 due to input/output error)" (for variable s)                
--- FAIL: TestCgoEval (1.71s)
FAIL
FAIL    github.com/go-delve/delve/service/test  1.738s
FAIL
(sid_arm64-dchroot)zhsj@amdahl:~/t/delve$ go test -mod=vendor -v ./pkg/proc -run TestCgoStacktrace                                                                          
=== RUN   TestCgoStacktrace
    proc_test.go:3347: iteration step 0
    proc_test.go:3211:  0x48ddf0 -0x90 -0xb8 main.main at main.go:13
    proc_test.go:3211:  0x430d7c -0x30 -0x13898 runtime.main at proc.go:204
    proc_test.go:3211:  0x45c574 -0x30 -0x4000044000 runtime.goexit at asm_arm64.s:1136
    proc_test.go:3347: iteration step 1
    proc_test.go:3211:  0x48e178 0xffffcd2f5660 0xffffcd2f5650 C.helloworld_pt2 at hello.c:15
    proc_test.go:3211:  0x48e1a8 0xffffcd2f5680 0xffffcd2f5670 C.helloworld at hello.c:19
    proc_test.go:3211:  0x48e130 0xffffcd2f56a0 0xffffcd2f5690 C._cgo_03f30c882f33_Cfunc_helloworld at cgo-gcc-prolog:50
    proc_test.go:3211:  0x45c33c -0x4000043f48 -0x4000044000 runtime.asmcgocall at asm_arm64.s:922
    proc_test.go:3211:  0x0 0x0 0x0 ? at .:0
    proc_test.go:3266: couldn't find frame 2 [C.helloworld_pt2 C.helloworld main.main]
    proc_test.go:3267: expected: [C.helloworld_pt2 C.helloworld main.main]
    proc_test.go:3392: see previous loglines
--- FAIL: TestCgoStacktrace (2.01s)
=== RUN   TestCgoStacktrace2
    proc_test.go:75: skipped on arm64: broken
--- SKIP: TestCgoStacktrace2 (0.00s)
FAIL
FAIL    github.com/go-delve/delve/pkg/proc      2.050s
FAIL

https://github.com/ustclug/mirrorrequest/issues/91 https://github.com/ustclug/discussions/issues/309 https://github.com/ustclug/mirrorrequest/issues/276

=== RUN   TestJWSWithCertificateChain
    jws_test.go:615: failed to verify certificate chain for test case 0: x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0
--- FAIL: TestJWSWithCertificateChain (0.00s)

Could you just use ctr run --rm -t private.registry/crictl-image:latest --some-options some-args ?

It seems objdump is not able to dump other architecture object.

llvm-objdump works.

on x86 system, it seems objdump can't dump arm64 as well.

$ cat a.c 
void main(){}
$ aarch64-linux-gnu-gcc a.c 
$ file a.out 
a.out: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=d65928b56beaf07019c6d04159c7e0ed28a7917f, for GNU/Linux 3.7.0, not stripped
$ /usr/bin/objdump --disassemble-all --demangle --no-show-raw-insn --line-numbers --start-address=0x0 --stop-address=0xffffffffffffffff a.out 

a.out:     file format elf64-little

/usr/bin/objdump: can't disassemble for architecture UNKNOWN!

$

$ objdump --version
GNU objdump (GNU Binutils for Debian) 2.35.1
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.

$ uname -a
Linux zhsj-debian 5.8.0-1-amd64 #1 SMP Debian 5.8.7-1 (2020-09-05) x86_64 GNU/Linux

I'm on arm.

$ uname -a
Linux abel 4.19.0-11-armmp-lpae #1 SMP Debian 4.19.146-1 (2020-09-17) armv7l GNU/Linux

$ objdump --version
GNU objdump (GNU Binutils for Debian) 2.35.1
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.

$ cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux bullseye/sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Not really fixed...

Still failing

=== RUN   TestDisasm
    binutils_test.go:205: Disasm: unexpected error [/usr/bin/objdump --disassemble-all --demangle --no-show-raw-insn --line-numbers --start-address=0x0 --stop-address=0xffffffffffffffff testdata/exe_linux_64]: exit status 1
--- FAIL: TestDisasm (0.04s)
=== RUN   TestDisasmIntelSyntax
    binutils_test.go:228: This test only works on x86_64 Linux or macOS as it tests Intel asm syntax
--- SKIP: TestDisasmIntelSyntax (0.00s)

/usr/bin/objdump: testdata/exe_linux_64: file format not recognized

It seems objdump is not able to dump other architecture object.

hmm, I'm not using master, it has been fixed.

It seems objdump is not able to dump other architecture object.

os.Executable is available since go1.8 https://github.com/kardianos/osext/blob/master/osext_go18.go

kardianos/osext is still in go.mod, because the old version of panicwrap needs this.

--- FAIL: TestNew (0.00s)
    circonus-gometrics_test.go:65: invalid config (none)
    circonus-gometrics_test.go:74: no API token, no submission URL
    circonus-gometrics_test.go:84: no API token, submission URL only
    circonus-gometrics_test.go:109: no Log, Debug = true
    circonus-gometrics_test.go:121: flush interval [good]
    circonus-gometrics_test.go:132: flush interval [bad]
    circonus-gometrics_test.go:143: Expected parsing flush interval: time: invalid duration thirty seconds got 'parsing flush interval: time: invalid duration "thirty seconds"'
FAIL

I find a machine which I can access, which has same CPU(Marvell Armada 370/XP CPU @ 1.6GHz on a Marvell MV78460 SoC Development Board (ARM v7)) https://db.debian.org/machines.cgi?host=abel But I can't reproduce the ICE.

=== RUN   TestJWSWithCertificateChain
    jws_test.go:615: failed to verify certificate chain for test case 0: x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0
--- FAIL: TestJWSWithCertificateChain (0.00s)

One test is failing with go1.15

    --- FAIL: Test_symmetric/map[test.stringKeyType]string (0.00s)

How repeatable is this error? Can you get it to happen on two different machines? It would be nice to eliminate the machine itself.

I don't have access to these builders. When I trigger a rebuild, it goes to another machine, which is an arm64 hardware.

The log is https://buildd.debian.org/status/logs.php?pkg=packer&ver=1.6.4%2Bdfsg-2&arch=armhf The failed machine is https://db.debian.org/machines.cgi?host=henze

I will try to see if I can get access to similar hardware.

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

What version of Go are you using (go version)?

<pre> $ go version 1.15.2 </pre>

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env

</pre></details>

What did you do?

When building packer on Debian armhf machines, we face an ICE. https://buildd.debian.org/status/fetch.php?pkg=packer&arch=armhf&ver=1.6.4%2Bdfsg-2&stamp=1601746051&raw=0

# net/http
/usr/lib/go-1.15/src/net/http/server.go:2318:14: internal compiler error: '(*ServeMux).shouldRedirectRLocked': panic during late deadcode while compiling (*ServeMux).shouldRedirectRLocked:

runtime error: makeslice: cap out of range

goroutine 39 [running]:
cmd/compile/internal/ssa.Compile.func1(0x342d71c, 0x558e300)
	/usr/lib/go-1.15/src/cmd/compile/internal/ssa/compile.go:48 +0x7c
panic(0x760ce8, 0x89eae0)
	/usr/lib/go-1.15/src/runtime/panic.go:969 +0x118
cmd/compile/internal/ssa.ReachableBlocks(0x558e300, 0xa6b000b8, 0x1, 0x3)
	/usr/lib/go-1.15/src/cmd/compile/internal/ssa/deadcode.go:23 +0x38
cmd/compile/internal/ssa.deadcode(0x558e300)
	/usr/lib/go-1.15/src/cmd/compile/internal/ssa/deadcode.go:181 +0x40
cmd/compile/internal/ssa.Compile(0x558e300)
	/usr/lib/go-1.15/src/cmd/compile/internal/ssa/compile.go:93 +0x98c
cmd/compile/internal/gc.buildssa(0x1f395f0, 0x3, 0x0)
	/usr/lib/go-1.15/src/cmd/compile/internal/gc/ssa.go:460 +0xbf4
cmd/compile/internal/gc.compileSSA(0x1f395f0, 0x3)
	/usr/lib/go-1.15/src/cmd/compile/internal/gc/pgen.go:317 +0x3c
cmd/compile/internal/gc.compileFunctions.func2(0x30171c0, 0x1ae2e50, 0x3)
	/usr/lib/go-1.15/src/cmd/compile/internal/gc/pgen.go:382 +0x38
created by cmd/compile/internal/gc.compileFunctions
	/usr/lib/go-1.15/src/cmd/compile/internal/gc/pgen.go:380 +0x100

It uses external link, other settings are standard.

GOFLAGS := -ldflags=-linkmode=external

We choose to use external link, because previously(when we still use go1.14) we meet link error, but it's another issue.

# armel/armhf fail to link:
# os/user(.text): direct call too far: .plt 87db4e

It's hard for me to reproduce locally and to write down a detailed issue, since it happens on an armhf machine, . But since it's an ICE, so I report here anyway, maybe you will know something from the trace.

What did you expect to see?

What did you see instead?

We only provide golang compiler installer or prebuild compiler. I'm not sure what kind of instructions we should provide...

Please be noted that we don't provide Go libraries proxy. You may need https://github.com/ustclug/mirrorrequest/issues/225 and many alternatives are listed in that issue.

https://cirrus-ci.org/guide/FreeBSD/ it supports freebsd, and free for public repos.

This PR adds power support on travis

Probably it's same as #41368

I just found someone is trying to build containerd with gollvm, then I double checked the gccgo build result. We build go packages with gccgo on ppc64 in Debian. https://buildd.debian.org/status/logs.php?pkg=containerd&arch=ppc64

What version of Go are you using (go version)?

go version go1.14.6 gccgo (Debian 10.2.0-7) 10.2.0 linux/amd64

and

go version go1.15rc2 gccgo (Debian 20200809-1) 11.0.0 20200809 (experimental) [master revision fb9e3f79464:8ad857c7881:94d4f4387de8264ee289cf71f692d59ca6ac36f8] linux/amd64

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env

</pre></details>

What did you do?

$ ls $GOPATH/src/golang.org/x/net/http/httpguts
guts.go  httplex.go  httplex_test.go

$ export GO111MODULE=off

$ cat test.go
package main

import (
        _ "golang.org/x/net/http/httpguts"
)

func main() {}

$ go run test.go

What did you expect to see?

go run test.go without error

What did you see instead?

go build golang.org/x/net/http/httpguts: no Go files in /usr/src/golang.org/x/net/http/httpguts

It happens with GOPATH, and GO111MODULE=off, and without vendor dir.

Hi,

Could this be backported to gcc10? It seems that Debian will use gcc10 for its next stable release.

https://github.com/golang/go/issues/41404 it says it's fixed in libgo.

It is same as https://github.com/rootless-containers/usernetes?

And maybe https://github.com/kubernetes/enhancements/pull/1371 should replace Kubernetes Node-Level User Namespaces Design Proposal

==> kustomization.yaml <==
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: demo

resources:
  - persistentvolume.yaml
  - persistentvolumeclaim.yaml

configurations:
  - kustomizeconfig.yaml

==> kustomizeconfig.yaml <==
namespace:
- kind: PersistentVolume
  path: spec/claimRef/namespace
  create: true

==> persistentvolumeclaim.yaml <==
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: demo-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  storageClassName: manual

==> persistentvolume.yaml <==
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: demo-pv
spec:
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 20Gi
  claimRef:
    name: demo-pvc
    namespace: default
  storageClassName: manual

kubectl kustomize result is:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: demo-pv
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 20Gi
  claimRef:
    name: demo-pvc
    namespace: default
  storageClassName: manual
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: demo-pvc
  namespace: demo
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  storageClassName: manual

But the expected result is:

...
  claimRef:
    name: demo-pvc
    namespace: demo
...

I think the pv resource is skiped in https://github.com/kubernetes-sigs/kustomize/blob/v2.0.3/pkg/transformers/namespace.go#L39

However the master version of kustomize seems ok.

https://github.com/ustclug/mirrorrequest/issues/276

理论上可以把每个 docker image 当成独立的软件、系统，按需镜像，而不是反代整个 docker hub 或者整个 gcr。目前 skopeo 等工具的出现，也让这个方法变得可行。

See libcap2 changes in 2.42

https://manpages.debian.org/unstable/libcap-dev/cap_to_text.3.en.html shows

$ ./a.out "cap_chown=p cap_chown+e" caps_to_text() returned "cap_chown=ep"

https://manpages.debian.org/buster/libcap-dev/cap_to_text.3.en.html shows

$ ./a.out "cap_chown=p cap_chown+e" caps_to_text() returned "= cap_chown+ep"

<!-- 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 https://github.com/moby/moby/blob/master/CONTRIBUTING.md#reporting-other-issues

GENERAL SUPPORT INFORMATION

The GitHub issue tracker is for bug reports and feature requests. General support for docker can be found at the following locations:

• Docker Support Forums - https://forums.docker.com
• Slack - community.docker.com #general channel
• Post a question on StackOverflow, using the Docker tag

General support for moby can be found at the following locations:

• Moby Project Forums - https://forums.mobyproject.org
• Slack - community.docker.com #moby-project channel
• Post a question on StackOverflow, using the Moby tag

BUG REPORT INFORMATION

Use the commands below to provide key information from your environment: You do NOT have to include this information if this is a FEATURE REQUEST -->

Description

<!-- Briefly describe the problem you are having in a few paragraphs. -->

TestTarUntarWithXattr failed

Steps to reproduce the issue:

1. sudo ./archive.test -test.v -test.run TestTarUntarWithXattr

Describe the results you received:

=== RUN   TestTarUntarWithXattr
    archive_unix_test.go:268: assertion failed: string "/tmp/docker-test-untar-origin160961326/2 cap_block_suspend=ep\n" does not contain "= cap_block_suspend+ep": untar should have kept the 'security.capability' xattr
    archive_unix_test.go:268: assertion failed: string "/tmp/docker-test-untar-origin160961326/2 cap_block_suspend=ep\n" does not contain "= cap_block_suspend+ep": untar should have kept the 'security.capability' xattr
--- FAIL: TestTarUntarWithXattr (0.01s)
FAIL

Describe the results you expected:

no failure

Additional information you deem important (e.g. issue happens only occasionally):

Kernel: Linux debian 5.7.0-2-amd64 #1 SMP Debian 5.7.10-1 (2020-07-26) x86_64 GNU/Linux libcap2: 2.43

Output of docker version:

(paste your output here)

Output of docker info:

(paste your output here)

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