golang January 2015

golang@lists.fedoraproject.org

10 participants
512 discussions

[Bug 1187494] New: golang-googlecode-goprotobuf breaks dependencies
by Red Hat Bugzilla 23 Feb '15

23 Feb '15

https://bugzilla.redhat.com/show_bug.cgi?id=1187494 Bug ID: 1187494 Summary: golang-googlecode-goprotobuf breaks dependencies Product: Fedora EPEL Version: el6 Component: golang-github-influxdb-influxdb Severity: medium Assignee: jchaloup(a)redhat.com Reporter: tis(a)foobar.fi QA Contact: extras-qa(a)fedoraproject.org CC: golang(a)lists.fedoraproject.org, jchaloup(a)redhat.com, lsm5(a)redhat.com, vbatts(a)redhat.com Description of problem: package: golang-github-influxdb-influxdb-datastore-0.8.5-0.1.git9485e99.el6.x86_64 from epel-6-64 unresolved deps: golang(code.google.com/p/goprotobuf/proto) package: golang-github-influxdb-influxdb-devel-0.8.5-0.1.git9485e99.el6.x86_64 from epel-6-64 unresolved deps: golang(code.google.com/p/goprotobuf/proto) golang-googlecode-goprotobuf-0-0.10.git7f07925.el6 which is on epel6 testing doesn't provide this any more. -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 1187495] New: new version breaks dependencies on epel6
by Red Hat Bugzilla 23 Feb '15

23 Feb '15

https://bugzilla.redhat.com/show_bug.cgi?id=1187495 Bug ID: 1187495 Summary: new version breaks dependencies on epel6 Product: Fedora EPEL Version: el6 Component: golang-googlecode-goprotobuf Assignee: tdawson(a)redhat.com Reporter: tis(a)foobar.fi QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, tdawson(a)redhat.com, vbatts(a)redhat.com Description of problem: Update golang-googlecode-goprotobuf-devel-0-0.10.git7f07925.el6 beaks following dependencies on epel6: package: golang-github-goraft-raft-devel-0-0.3.gite138889.el6.i686 from epel-6-64 unresolved deps: golang(code.google.com/p/goprotobuf) package: golang-github-goraft-raft-devel-0-0.3.gite138889.el6.x86_64 from epel-6-64 unresolved deps: golang(code.google.com/p/goprotobuf) package: golang-github-influxdb-influxdb-datastore-0.8.5-0.1.git9485e99.el6.x86_64 from epel-6-64 unresolved deps: golang(code.google.com/p/goprotobuf/proto) package: golang-github-influxdb-influxdb-devel-0.8.5-0.1.git9485e99.el6.i686 from epel-6-64 unresolved deps: golang(code.google.com/p/goprotobuf/proto) package: golang-github-influxdb-influxdb-devel-0.8.5-0.1.git9485e99.el6.x86_64 from epel-6-64 unresolved deps: golang(code.google.com/p/goprotobuf/proto) -- You are receiving this mail because: You are on the CC list for the bug.

1 15

[Bug 1187491] New: golang-googlecode-goprotobuf breaks dependencies
by Red Hat Bugzilla 23 Feb '15

23 Feb '15

https://bugzilla.redhat.com/show_bug.cgi?id=1187491 Bug ID: 1187491 Summary: golang-googlecode-goprotobuf breaks dependencies Product: Fedora EPEL Version: el6 Component: golang-github-goraft-raft Severity: medium Assignee: tdawson(a)redhat.com Reporter: tis(a)foobar.fi QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, tdawson(a)redhat.com Description of problem: package: golang-github-goraft-raft-devel-0-0.3.gite138889.el6.x86_64 from epel-6-64 unresolved deps: golang(code.google.com/p/goprotobuf) This dependency is not available on new version golang-googlecode-goprotobuf 0-0.10.git7f07925.el6 which is on epel6 testing -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 1173550] New: Docker load fails to load xz-compressed image
by Red Hat Bugzilla 20 Feb '15

20 Feb '15

https://bugzilla.redhat.com/show_bug.cgi?id=1173550 Bug ID: 1173550 Summary: Docker load fails to load xz-compressed image Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: masanari_iida(a)hp.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, hushan.jia(a)gmail.com, jchaloup(a)redhat.com, jperrin(a)centos.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, miminar(a)redhat.com, s(a)shk.io, thrcka(a)redhat.com, vbatts(a)redhat.com Description of problem: Docker load fails to load xz-compressed image Version-Release number of selected component (if applicable): docker-io-1.3.2-4.fc20.x86_64 How reproducible: Always Steps to Reproduce: cat my-image.tar.xz | docker import - (This image was created with "supermin --format chroot" option.) Actual results: Error: ApplyLayer exit status 1 exec: "xz": executable file not in $PATH Expected results: Docker import image file without problem. Additional info: This is known problem which was introduced in docker-1.3.2 https://github.com/docker/docker/issues/9327 Fix https://github.com/docker/docker/commit/001ac15b54686761960352103ebf4ff2c6e… Workaround: Downgrade to 1.3.1 -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1180145] New: Docker container image timezone is wrong
by Red Hat Bugzilla 20 Feb '15

20 Feb '15

https://bugzilla.redhat.com/show_bug.cgi?id=1180145 Bug ID: 1180145 Summary: Docker container image timezone is wrong Product: Fedora Version: 21 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: jablonskis(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: adimania(a)gmail.com, admiller(a)redhat.com, golang(a)lists.fedoraproject.org, hushan.jia(a)gmail.com, jchaloup(a)redhat.com, jperrin(a)centos.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, miminar(a)redhat.com, s(a)shk.io, thrcka(a)redhat.com, vbatts(a)redhat.com Apologies if I am reporting this issue against wrong component. Please correct me. Description of problem: Fedora 21 latest docker container image time zone is set to America/New_York, which is wrong. Version-Release number of selected component (if applicable): Image id on docker hub: 834629358fe214f210b0ed606fba2c17827d7a46dd74bd3309afc2a103ad0e89 How reproducible: Always. Steps to Reproduce: > docker run -ti fedora:latest /usr/bin/date Thu Jan 8 08:35:21 EST 2015 > docker run -ti fedora:latest /usr/bin/ls -l /etc/localtime lrwxrwxrwx 1 root root 38 Dec 3 00:58 /etc/localtime -> ../usr/share/zoneinfo/America/New_York Actual results: Time zone is set to America/New_York Expected results: Time zone is set to Etc/UTC Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1029587] New: upgrade to go1.2 (once it is available)
by Red Hat Bugzilla 19 Feb '15

19 Feb '15

https://bugzilla.redhat.com/show_bug.cgi?id=1029587 Bug ID: 1029587 Summary: upgrade to go1.2 (once it is available) Product: Fedora Version: rawhide Component: golang Severity: low Assignee: adam(a)spicenitz.org Reporter: vbatts(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: adam(a)spicenitz.org, admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lemenkov(a)gmail.com, lsm5(a)redhat.com, renich(a)woralelandia.com, vbatts(a)redhat.com What steps will reproduce the problem? If possible, include a link to a program on play.golang.org. 1. export GOPATH=$(mktemp -d) 2. go get code.google.com/p/go.tools/cmd/oracle 3. What is the expected output? What do you see instead? /tmp/tmp.cjYFzAeLWC/src/code.google.com/p/go.tools/importer/source.go:434: n.Lparen undefined (type *ast.TypeAssertExpr has no field or method Lparen) /tmp/tmp.cjYFzAeLWC/src/code.google.com/p/go.tools/importer/source.go:435: n.Lparen undefined (type *ast.TypeAssertExpr has no field or method Lparen) /tmp/tmp.cjYFzAeLWC/src/code.google.com/p/go.tools/importer/source.go:436: n.Rparen undefined (type *ast.TypeAssertExpr has no field or method Rparen) Which compiler are you using (5g, 6g, 8g, gccgo)? 6g Which operating system are you using? Red Hat Enterprise Linux Workstation release 6.4 (Santiago) Which version are you using? go version go1.1.2 linux/amd64 (golang-1.1.2-4.el6.x86_64) Please provide any additional information below. I tested against the tip of their repo (future version 1.2) (go version devel +39c724dd7f25 Tue Nov 12 09:28:07 2013 +1100 linux/amd64) and code.google.com/p/go.tools/cmd/oracle and code.google.com/p/go.tools/cmd/ssadump build just fine -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1099074] New: Processing Dependency: golang-docs = 1.1-2.fc19 for package: golang-godoc-1.1-2.fc19.x86_64
by Red Hat Bugzilla 17 Feb '15

17 Feb '15

https://bugzilla.redhat.com/show_bug.cgi?id=1099074 Bug ID: 1099074 Summary: Processing Dependency: golang-docs = 1.1-2.fc19 for package: golang-godoc-1.1-2.fc19.x86_64 Product: Fedora Version: 19 Component: golang Severity: high Assignee: adam(a)spicenitz.org Reporter: dridi.boukelmoune(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: adam(a)spicenitz.org, admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lemenkov(a)gmail.com, lsm5(a)redhat.com, renich(a)woralelandia.com, s(a)shk.io, vbatts(a)redhat.com Description of problem: I'm trying to install the golang-godoc package but it fails. It's looking for golang-docs which is provided by golang, but the required version doesn't match. Version-Release number of selected component (if applicable): golang-1.2.1-1.fc19.x86_64 golang-godoc-1.1-2.fc19.x86_64 How reproducible: always Steps to Reproduce: 1. sudo yum install golang 2. sudo yum install golang-godoc Actual results: Resolving Dependencies --> Running transaction check ---> Package golang-godoc.x86_64 0:1.1-2.fc19 will be installed --> Processing Dependency: golang-docs = 1.1-2.fc19 for package: golang-godoc-1.1-2.fc19.x86_64 Package golang-docs-1.1-2.fc19.noarch is obsoleted by golang-1.2.1-1.fc19.x86_64 which is already installed --> Processing Dependency: golang(x86-64) = 1.1-2.fc19 for package: golang-godoc-1.1-2.fc19.x86_64 --> Finished Dependency Resolution Error: Package: golang-godoc-1.1-2.fc19.x86_64 (fedora) Requires: golang(x86-64) = 1.1-2.fc19 Installed: golang-1.2.1-1.fc19.x86_64 (@updates) golang(x86-64) = 1.2.1-1.fc19 Available: golang-1.1-2.fc19.x86_64 (fedora) golang(x86-64) = 1.1-2.fc19 Error: Package: golang-godoc-1.1-2.fc19.x86_64 (fedora) Requires: golang-docs = 1.1-2.fc19 Available: golang-docs-1.1-2.fc19.noarch (fedora) golang-docs = 1.1-2.fc19 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Expected results: Is this ok [y/d/N]: Additional info: I couldn't find golang-godoc in pkgdb2, so I'm filing against golang. -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1128208] New: docker io not using proper DNS
by Red Hat Bugzilla 06 Feb '15

06 Feb '15

https://bugzilla.redhat.com/show_bug.cgi?id=1128208 Bug ID: 1128208 Summary: docker io not using proper DNS Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)fedoraproject.org Reporter: briemers(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, dgoodwin(a)redhat.com, eparis(a)redhat.com, extras-qa(a)fedoraproject.org, gansalmon(a)Gmail.com, golang(a)lists.fedoraproject.org, hushan.jia(a)gmail.com, itamar(a)ispbrasil.com.br, jeder(a)redhat.com, jonathan(a)jonmasters.org, jpazdziora(a)redhat.com, jperrin(a)centos.org, kernel-maint(a)redhat.com, lars(a)redhat.com, lsm5(a)fedoraproject.org, madhu.chinakonda(a)gmail.com, mattdm(a)redhat.com, mchehab(a)infradead.org, mgoldman(a)redhat.com, pmoore(a)redhat.com, rbriggs(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com Depends On: 1119849 The resolution for Bug #1119849 introduced a new problem. I have a dockerfile that uses the command: git clone http://gitolite.corp.redhat.com/cgit/it-sales/sfjavasuite.git/ Up until the most recent update the dockerfile worked expected. Now it fails with a hostname not found. It seems part of the update is docker will now try and use fixed DNS values of 8.8.8.8 and 8.8.4.4. Which is of course in appropriate for anyone inside a private network. In some cases it is even considered a security risk to have DNS lookups leak to a public DNS server, as it gives outside user information about the private network. It is possible to update the docker options to work around the problem. But of course the DNS servers obtained by DHCP, so it would require restarting docker-io with new settings everytime a new network connection is established... Likewise another workaround is a set if iptable rules to override all DNS lookups but again this introduces it's own set of problems. And of course, I don't want to assume everyone who will use my Dockerfile has updated their workstations and servers with whatever hack solution I use... Reproduce steps: 1. docker run fedora cat /etc/resolv.conf Expected results: The DNS settings equivalent to the host, which in my case are: $ cat /etc/resolv.conf # Generated by NetworkManager domain docbill.info search docbill.info nameserver 127.0.0.1 nameserver 172.31.253.1 nameserver 172.31.252.1 # NOTE: the libc resolver may not support more than 3 nameservers. # The nameservers listed below may not be recognized. nameserver 10.11.255.155 nameserver 10.11.255.156 nameserver 10.5.26.21 nameserver 10.7.142.20 nameserver fe80::beae:c5ff:fee8:b5e%em1 nameserver fe80::4216:7eff:feea:a5b8%em1 nameserver 2001:470:1d:8a2::1 Actual results: $ docker run fedora cat /etc/resolv.conf nameserver 8.8.8.8 nameserver 8.8.4.4 search docbill.info Note: I'm not sure how the previous docker-io version got the 127.0.0.1 correct. But somehow it figured out that was an instruction to use the dnsmasq instance on my laptop. Bill Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1119849 [Bug 1119849] su - postgres Results in System Error inside Fedora 20/rawhide containers -- You are receiving this mail because: You are on the CC list for the bug.

1 23

[Bug 1185423] New: MountFlags=private in docker.service prevents admin from exposing new storage to docker
by Red Hat Bugzilla 04 Feb '15

04 Feb '15

https://bugzilla.redhat.com/show_bug.cgi?id=1185423 Bug ID: 1185423 Summary: MountFlags=private in docker.service prevents admin from exposing new storage to docker Product: Fedora Version: 21 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: lars(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: adimania(a)gmail.com, admiller(a)redhat.com, golang(a)lists.fedoraproject.org, hushan.jia(a)gmail.com, jchaloup(a)redhat.com, jperrin(a)centos.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, miminar(a)redhat.com, s(a)shk.io, thrcka(a)redhat.com, vbatts(a)redhat.com Setting MountFlags=private in docker.service means that any storage mounted on the host after starting Docker will be unavailable for docker containers. For example, I wanted to expose a directory from a remote server to a Docker container: mkdir /data/content mount remote-server:/vol/content /data/content docker run -v /data/content:/content larsks/thttpd -d /content This fails because Docker does not see the mount onto /data/content. It only sees the content of the underlying directory, not the mounted filesystem. I think we want MountFlags=slave instead, which would prevent mounts inside the Docker mount namespace from propagating to the global namespace while still allowing global mounts to be available to docker containers. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1184266] New: missing debug info
by Red Hat Bugzilla 03 Feb '15

03 Feb '15

https://bugzilla.redhat.com/show_bug.cgi?id=1184266 Bug ID: 1184266 Summary: missing debug info Product: Fedora Version: rawhide Component: docker-io Assignee: lsm5(a)redhat.com Reporter: jan.kratochvil(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: adimania(a)gmail.com, admiller(a)redhat.com, golang(a)lists.fedoraproject.org, hushan.jia(a)gmail.com, jchaloup(a)redhat.com, jperrin(a)centos.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, miminar(a)redhat.com, s(a)shk.io, thrcka(a)redhat.com, vbatts(a)redhat.com Created attachment 982069 --> https://bugzilla.redhat.com/attachment.cgi?id=982069&action=edit docker-io.spec patch Description of problem: Current docker-io.rpm is not debuggable at all. With the patch below the debugging gets significantly improved. Further fixes will be needed. Version-Release number of selected component (if applicable): docker-io-1.4.1-7.fc22 How reproducible: Always. Steps to Reproduce: gdb -ex 'catch fork' -ex r -ex 'thread apply all bt' --args docker -d Actual results: ------------------------------------------------------------------------------ Catchpoint 1 (forked process 8419), 0x00000000005eb5c5 in syscall.RawSyscall6 () Thread 4 (Thread 0x7fffeffff700 (LWP 8418)): #0 0x0000000000448b23 in runtime.futex () #1 0x0000000000438f67 in runtime.futexsleep () #2 0x000000c208020b58 in ?? () #3 0x0000000000000000 in ?? () Thread 3 (Thread 0x7ffff4f32700 (LWP 8417)): #0 0x0000000000448b23 in runtime.futex () #1 0x0000000000438f67 in runtime.futexsleep () #2 0x0000000001100900 in ?? () #3 0x0000000000000000 in ?? () Thread 2 (Thread 0x7ffff5733700 (LWP 8416)): #0 0x000000000044885d in runtime.usleep () #1 0x0000000000000000 in ?? () Thread 1 (Thread 0x7ffff7fbb800 (LWP 8412)): #0 0x00000000005eb5c5 in syscall.RawSyscall6 () #1 0x00000000005dd7ee in syscall.forkAndExecInChild () #2 0x0000000000000038 in ?? () #3 0x0000000000000011 in ?? () #4 0x0000000000000000 in ?? () ------------------------------------------------------------------------------ Expected results: ------------------------------------------------------------------------------ Catchpoint 1 (forked process 8389), syscall.RawSyscall6 () at /usr/lib/golang/src/syscall/asm_linux_amd64.s:101 101 CMPQ AX, $0xfffffffffffff001 Thread 5 (Thread 0x7fffef7fe700 (LWP 8388)): #0 runtime.futex () at /usr/lib/golang/src/runtime/sys_linux_amd64.s:278 #1 0x0000000000438f67 in runtime.futexsleep () at /usr/lib/golang/src/runtime/os_linux.c:49 #2 0x0000000000415ede in runtime.notesleep (n=0xc208020ed8) at /usr/lib/golang/src/runtime/lock_futex.go:145 #3 0x000000000043c439 in stopm () at /usr/lib/golang/src/runtime/proc.c:1178 #4 0x000000000043cb38 in startlockedm () at /usr/lib/golang/src/runtime/proc.c:1329 #5 0x000000000043d67a in schedule () at /usr/lib/golang/src/runtime/proc.c:1582 #6 0x000000000043db3e in goexit0 () at /usr/lib/golang/src/runtime/proc.c:1717 #7 0x0000000000445d2a in runtime.mcall () at /usr/lib/golang/src/runtime/asm_amd64.s:186 #8 0x000000c208012000 in ?? () #9 0x000000000043bbd4 in runtime.mstart () at /usr/lib/golang/src/runtime/proc.c:836 #10 0x0000000000404533 in crosscall_amd64 () at /builddir/build/BUILD/go/src/runtime/cgo/gcc_amd64.S:35 #11 0x0000000000000010 in ?? () #12 0x00007fffef7fe9c0 in ?? () #13 0x00007fffffffdc3f in ?? () #14 0x0000000000000001 in ?? () #15 0x000000c2080a27e0 in ?? () #16 0x000000000043bb30 in runtime.starttheworld () at /usr/lib/golang/src/runtime/proc.c:761 #17 0x00007fffef7fe700 in ?? () #18 0xe1840af9c5b45b6d in ?? () #19 0x0000000000000001 in ?? () #20 0x00007fffffffdc3f in ?? () #21 0x00007fffef7fe9c0 in ?? () #22 0x0000000000000010 in ?? () #23 0x1e7bd40679745b6d in ?? () #24 0x1e7be5e649ee5b6d in ?? () #25 0x0000000000000000 in ?? () Thread 4 (Thread 0x7fffeffff700 (LWP 8387)): #0 runtime.futex () at /usr/lib/golang/src/runtime/sys_linux_amd64.s:278 #1 0x0000000000438f67 in runtime.futexsleep () at /usr/lib/golang/src/runtime/os_linux.c:49 #2 0x0000000000415ede in runtime.notesleep (n=0xc208020b58) at /usr/lib/golang/src/runtime/lock_futex.go:145 #3 0x000000000043c439 in stopm () at /usr/lib/golang/src/runtime/proc.c:1178 #4 0x000000000043cb38 in startlockedm () at /usr/lib/golang/src/runtime/proc.c:1329 #5 0x000000000043d67a in schedule () at /usr/lib/golang/src/runtime/proc.c:1582 #6 0x000000000043d8d3 in runtime.park_m () at /usr/lib/golang/src/runtime/proc.c:1654 #7 0x0000000000445d2a in runtime.mcall () at /usr/lib/golang/src/runtime/asm_amd64.s:186 #8 0x000000c208012000 in ?? () #9 0x000000000043bbd4 in runtime.mstart () at /usr/lib/golang/src/runtime/proc.c:836 #10 0x0000000000404533 in crosscall_amd64 () at /builddir/build/BUILD/go/src/runtime/cgo/gcc_amd64.S:35 #11 0x0000000000000000 in ?? () Thread 3 (Thread 0x7ffff4f32700 (LWP 8386)): #0 runtime.futex () at /usr/lib/golang/src/runtime/sys_linux_amd64.s:278 #1 0x0000000000438f67 in runtime.futexsleep () at /usr/lib/golang/src/runtime/os_linux.c:49 #2 0x0000000000415f8d in runtime.notetsleep_internal (n=0x1102900 <runtime.sig>, ns=-1, ~r2=false) at /usr/lib/golang/src/runtime/lock_futex.go:157 #3 0x00000000004161da in runtime.notetsleepg (n=0x1102900 <runtime.sig>, ns=-1, ~r2=true) at /usr/lib/golang/src/runtime/lock_futex.go:202 #4 0x0000000000422f25 in runtime.signal_recv (~r0=0) at /usr/lib/golang/src/runtime/sigqueue.go:109 #5 0x00000000007a363f in os/signal.loop () at /usr/lib/golang/src/os/signal/signal_unix.go:21 #6 0x0000000000448231 in runtime.goexit () at /usr/lib/golang/src/runtime/asm_amd64.s:2232 #7 0x0000000000000000 in ?? () Thread 2 (Thread 0x7ffff5733700 (LWP 8385)): #0 runtime.usleep () at /usr/lib/golang/src/runtime/sys_linux_amd64.s:82 #1 0x000000000044056b in sysmon () at /usr/lib/golang/src/runtime/proc.c:2892 #2 0x000000000043bcc1 in mstart () at /usr/lib/golang/src/runtime/proc.c:859 #3 0x000000000043bbd4 in runtime.mstart () at /usr/lib/golang/src/runtime/proc.c:836 #4 0x0000000000404533 in crosscall_amd64 () at /builddir/build/BUILD/go/src/runtime/cgo/gcc_amd64.S:35 #5 0x0000000000000000 in ?? () Thread 1 (Thread 0x7ffff7fbb800 (LWP 8381)): #0 syscall.RawSyscall6 () at /usr/lib/golang/src/syscall/asm_linux_amd64.s:101 #1 0x00000000005dd7ee in syscall.forkAndExecInChild (argv0=0xc20810e500 "/usr/sbin/iptables", argv=..., envv=..., chroot=0x0, dir=0x0, attr=0xc2080e7b40, sys=0x10f81c0 <syscall.zeroSysProcAttr>, pipe=7, pid=216172782113783818, err=...) at /usr/lib/golang/src/syscall/exec_linux.go:85 #2 0x00000000005df474 in syscall.forkExec (argv0=..., argv=..., attr=0xc2080e7b40, pid=10011360, err=...) at /usr/lib/golang/src/syscall/exec_unix.go:191 #3 0x00000000005df842 in syscall.StartProcess (argv0=..., argv=..., attr=0xc2080e7b40, pid=2, handle=4, err=...) at /usr/lib/golang/src/syscall/exec_unix.go:238 #4 0x0000000000542ddb in os.startProcess (name=..., argv=..., attr=0xc20802fc70, p=0xace2c0, err=...) at /usr/lib/golang/src/os/exec_posix.go:45 #5 0x00000000005415f2 in os.StartProcess (name=..., argv=..., attr=0xc20802fc70, ~r3=0x2, ~r4=...) at /usr/lib/golang/src/os/doc.go:24 #6 0x000000000066db0e in os/exec.(*Cmd).Start (~r0=...) at /usr/lib/golang/src/os/exec/exec.go:316 #7 0x000000000066d18a in os/exec.(*Cmd).Run (c=0xc208081680, ~r0=...) at /usr/lib/golang/src/os/exec/exec.go:243 #8 0x0000000000892da2 in github.com/docker/docker/pkg/iptables.init·1 () at /home/jkratoch/redhat/fedora/docker-io/master/docker-1.4.1/_build/src/github.com/docker/docker/pkg/iptables/iptables.go:43 #9 0x0000000000895b35 in github.com/docker/docker/pkg/iptables.init () at /home/jkratoch/redhat/fedora/docker-io/master/docker-1.4.1/_build/src/github.com/docker/docker/pkg/iptables/iptables.go:201 #10 0x00000000006b81d9 in github.com/docker/docker/daemon/networkdriver/bridge.init () at /home/jkratoch/redhat/fedora/docker-io/master/docker-1.4.1/_build/src/github.com/docker/docker/daemon/networkdriver/bridge/driver.go:536 #11 0x00000000004a2bd2 in github.com/docker/docker/daemon.init () at /home/jkratoch/redhat/fedora/docker-io/master/docker-1.4.1/_build/src/github.com/docker/docker/daemon/wait.go:20 #12 0x000000000040935e in main.init () at /home/jkratoch/redhat/fedora/docker-io/master/docker-1.4.1/docker/log.go:12 #13 0x000000000041ec94 in runtime.main () at /usr/lib/golang/src/runtime/proc.go:58 #14 0x0000000000448231 in runtime.goexit () at /usr/lib/golang/src/runtime/asm_amd64.s:2232 #15 0x0000000000000000 in ?? () ------------------------------------------------------------------------------ Additional info: There was Bug 1017186 Comment 3 but I do not see it would not be working: # This also adds -w, to disable building with debugging in the executable which isn't working with debuginfo anyway. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

← Newer
1
...
4
5
6
7
8
9
10
...
52
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang January 2015