June 2014 - golang - Fedora mailing-lists

[Bug 1038683] New: golang appears to contain an ECC implementation
by Red Hat Bugzilla 17 Jun '16

17 Jun '16

https://bugzilla.redhat.com/show_bug.cgi?id=1038683 Bug ID: 1038683 Summary: golang appears to contain an ECC implementation Product: Fedora Version: 20 Component: golang Assignee: adam(a)spicenitz.org Reporter: notting(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, skottler(a)redhat.com, vbatts(a)redhat.com Blocks: 182235 (FE-Legal), 1019390 (ecc) Description of problem: At least, I would assume that's what is in go/src/pkg/crypto/elliptic/. In Fedora, we only ship certain reviewed curves. Version-Release number of selected component (if applicable): 1.2-1 How reproducible: 100% Steps to Reproduce: 1. look at golang's crypto code Actual results: Hey, that looks like ECC, and it appears to have been always included. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=182235 [Bug 182235] Fedora Legal Tracker https://bugzilla.redhat.com/show_bug.cgi?id=1019390 [Bug 1019390] [tracking bug] re-enable ECC/ECDHE/EC/ECDSA/elliptic curves in Fedora -- You are receiving this mail because: You are on the CC list for the bug.

1 19

[Bug 1046469] New: docker privileged mode with cmd /sbin/init - agetty & high cpu
by Red Hat Bugzilla 08 Jun '16

08 Jun '16

https://bugzilla.redhat.com/show_bug.cgi?id=1046469 Bug ID: 1046469 Summary: docker privileged mode with cmd /sbin/init - agetty & high cpu Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: fortuik(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, skottler(a)redhat.com, vbatts(a)redhat.com Description of problem: docker containers in privileged mode mess with the host agetty and produce very hicht cpu load Version-Release number of selected component (if applicable): Fedora 20 Docker 0.7.1, 0.7.2 How reproducible: docker run -privileged -d mattdm/fedora:latest /sbin/init Actual results: docker container runs cpu load is very high - agetty stopping the container & the docker daemon do not free the cpu resources one have to kill the agetty process Expected results: docker container runs Additional info: In my real case i run rhel containers with puppet & ssh daemons for a small puppet lab. The reason i met this bug is that running docker container with /sbin/init cmd under RHEL 6.5 require priviliged mode. -- You are receiving this mail because: You are on the CC list for the bug.

1 14

[Bug 1091538] New: golang crashing on ARMv7
by Red Hat Bugzilla 09 May '16

09 May '16

https://bugzilla.redhat.com/show_bug.cgi?id=1091538 Bug ID: 1091538 Summary: golang crashing on ARMv7 Product: Fedora Version: rawhide Component: golang Assignee: adam(a)spicenitz.org Reporter: pbrobinson(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 Blocks: 245418 (ARMTracker) We're getting an crash with go when I try and enable go support for ARM in the swig package. http://koji.fedoraproject.org/koji/taskinfo?taskID=6780663 It's currently just a scratch build as I obviously can't push it if it fails. checking Examples/go/callback checking Examples/go/class unexpected fault address 0x40440000 fatal error: fault [signal 0xb code=0x1 addr=0x40440000 pc=0x40440000] goroutine 1 [running]: runtime.throw(0x15691f) /usr/lib/golang/src/pkg/runtime/panic.c:464 +0x5c fp=0xb6ba5f7c runtime: unexpected return pc for runtime.sigpanic called from 0x40440000 runtime.sigpanic() /usr/lib/golang/src/pkg/runtime/os_linux.c:237 +0xa8 fp=0xb6ba5f88 goroutine 3 [syscall]: runtime.goexit() /usr/lib/golang/src/pkg/runtime/proc.c:1394 checking Examples/go/constants make[3]: *** [go_run] Error 2 make[2]: *** [check] Error 2 make[1]: *** [class.actionexample] Error 2 checking Examples/go/enum checking Examples/go/extend checking Examples/go/funcptr checking Examples/go/multimap checking Examples/go/pointer checking Examples/go/reference checking Examples/go/simple checking Examples/go/template checking Examples/go/variables Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=245418 [Bug 245418] Tracker for ARM support -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Bug 1100000] New: can't run iscsid in a docker container
by Red Hat Bugzilla 11 Apr '16

11 Apr '16

https://bugzilla.redhat.com/show_bug.cgi?id=1100000 Bug ID: 1100000 Summary: can't run iscsid in a docker container Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: jslagle(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com Created attachment 898086 --> https://bugzilla.redhat.com/attachment.cgi?id=898086&action=edit iscsid strace showing failure Description of problem: Can't start iscsid in a docker container Version-Release number of selected component (if applicable): # rpm -q docker-io docker-io-0.11.1-3.fc20.x86_64 How reproducible: always Steps to Reproduce: 1. use the published fedora image, docker pull fedora 2. start the container, docker run -t -i fedora /bin/bash 3. install iscsi-initiator-utils 4. try to start iscsid: bash-4.2# iscsid -f iscsid: can not bind NETLINK_ISCSI socket strace also attached -- You are receiving this mail because: You are on the CC list for the bug.

1 24

[Bug 1096273] New: repetition of signal 21 with --sig-proxy and SIGSTOP of docker
by Red Hat Bugzilla 05 Apr '16

05 Apr '16

https://bugzilla.redhat.com/show_bug.cgi?id=1096273 Bug ID: 1096273 Summary: repetition of signal 21 with --sig-proxy and SIGSTOP of docker Product: Red Hat Enterprise Linux 7 Version: 7.1 Component: docker Severity: low Assignee: lsm5(a)redhat.com Reporter: ldoktor(a)redhat.com QA Contact: virt-bugs(a)redhat.com CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, skottler(a)redhat.com, vbatts(a)redhat.com Depends On: 1087704 +++ This bug was initially created as a clone of Bug #1087704 +++ Description of problem: I noticed weird reaction to SIGSTOP signal. When you start container with --sig-proxy, ignore all signals in container and from OS use kill -SIGSTOP to the `docker run` process, it's put into background. (so far correct behavior) Than when you use kill -SIGCONT, it's resumed (still in background) and it's continuing to send signal 21 to the container (100% CPU utilization). This disappears once you attach the process with fg. Version-Release number of selected component (if applicable): docker-0.10.0-8.el7.x86_64 docker-io-0.9.1-1.fc21.x86_64 How reproducible: always Steps to Reproduce: 1. /usr/bin/docker -D run --tty=false --rm -i --name test_eoly localhost:5000/ldoktor/fedora:latest bash -c 'for NUM in `seq 1 64`; do trap "echo Received $NUM, ignoring..." $NUM; done; while :; do sleep 1; done' 2. ps ax |grep docker 3. kill -SIGSTOP $PID 4. kill -SIGCONT $PID Actual results: [1]+ Pozastavena /usr/bin/docker -D run --tty=false --rm -i --name test_eoly localhost:5000/ldoktor/fedora:latest bash -c 'for NUM in `seq 1 64`; do trap "echo Received $NUM, ignoring..." $NUM; done; while :; do sleep 1; done' [root@t530 ~]# Received 21, ignoring... Received 21, ignoring... Received 21, ignoring... Received 21, ignoring... Received 21, ignoring... Received 21, ignoring... ... (100% CPU utilization, when you use fg it stops and you can use the container again...) Expected results: [1]+ Pozastavena /usr/bin/docker -D run --tty=false --rm -i --name test_eoly localhost:5000/ldoktor/fedora:latest bash -c 'for NUM in `seq 1 64`; do trap "echo Received $NUM, ignoring..." $NUM; done; while :; do sleep 1; done' [root@t530 ~]# Received 21, ignoring... Additional info: I'm not definitely sure if this is really required as it's not a common usage. But as there is no way to detach the process apart from kill -SIGSTOP people might use it and get to this problem... --- Additional comment from Lukas Doktor on 2014-05-05 03:59:30 EDT --- I retested this with the upstream dc9c28f/0.10.0 with the same results. The daemon output is: ... [/home/medic/Work/Projekty/Docker/root|fa3816b6] -job kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, TTIN) = OK (0) 2014/05/05 09:58:13 POST /v1.10/containers/b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5/kill?signal=TTIN [/home/medic/Work/Projekty/Docker/root|fa3816b6] +job kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, TTIN) [/home/medic/Work/Projekty/Docker/root|fa3816b6] -job kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, TTIN) = OK (0) 2014/05/05 09:58:13 POST /v1.10/containers/b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5/kill?signal=TTIN [/home/medic/Work/Projekty/Docker/root|fa3816b6] +job kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, TTIN) [/home/medic/Work/Projekty/Docker/root|fa3816b6] -job kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, TTIN) = OK (0) 2014/05/05 09:58:13 POST /v1.10/containers/b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5/kill?signal=TTIN [/home/medic/Work/Projekty/Docker/root|fa3816b6] +job kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, TTIN) ... Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1087704 [Bug 1087704] repetition of signal 21 with --sig-proxy and SIGSTOP of docker -- You are receiving this mail because: You are on the CC list for the bug.

1 25

[Bug 1096296] New: man page inaccuracy about --sig-proxy and --tty
by Red Hat Bugzilla 07 Jan '16

07 Jan '16

https://bugzilla.redhat.com/show_bug.cgi?id=1096296 Bug ID: 1096296 Summary: man page inaccuracy about --sig-proxy and --tty Product: Red Hat Enterprise Linux 7 Version: 7.1 Component: docker Assignee: lsm5(a)redhat.com Reporter: ldoktor(a)redhat.com QA Contact: virt-bugs(a)redhat.com CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, skottler(a)redhat.com, vbatts(a)redhat.com, whenry(a)redhat.com Depends On: 1087697 +++ This bug was initially created as a clone of Bug #1087697 +++ Description of problem: Hi guys, the man page states: --sig-proxy=true: Proxify all received signal to the process (even in non-tty mode) But the real behavior is, that sig-proxy doesn't work when --tty=true. It should be mentioned in there, taht --sig-proxy is incompatible with --tty. Version-Release number of selected component (if applicable): docker-io-0.9.1-1.fc21.x86_64 How reproducible: always Steps to Reproduce: 1. man docker Actual results: man page says it works even in non-tty Expected results: man page warns that --tty can't be used with --sig-proxy How to verify: 1. docker run --tty=true -i --rm fedora bash -c 'for NUM in `seq 1 64`; do trap "echo Received $NUM, ignoring..." $NUM; done; while :; do sleep 1; done' 2. ps -ax | grep docker 3. kill -SIGUSR1 $PID 4. (with --tty=true no signals are received, when you try the same with --tty=false, signals are proxified and messages are displayed) --- Additional comment from Lokesh Mandvekar on 2014-04-15 02:11:48 EDT --- Copying William (he recently got per subcommand manpages merged upstream). this seems to be the case even in the latest manpage (I'm guessing this was inherited from the original manpage). William, was there any discussion about this in your PR? --- Additional comment from Lokesh Mandvekar on 2014-04-15 02:15:31 EDT --- btw, the 0.10 rpm includes the latest manpages (should be in yum soon) --- Additional comment from Lukas Doktor on 2014-04-15 04:45:55 EDT --- Thanks for a quick reply. I tried the docker-io-0.10.0-2.fc20.x86_64 which says: --sig-proxy=true|false: When set to true, proxify all received signals to the process (even in non-tty mode). The default is true. I'd really like to change it to "only in non-tty" with possible warning that --tty=true is incompatible with --sig-proxy. --- Additional comment from William Henry on 2014-04-30 15:54:25 EDT --- I go this text from upstream. I'll check. --- Additional comment from William Henry on 2014-04-30 16:02:22 EDT --- Lukas,according to the folks upstream, this is a bug in docker run and attach. It should be as the text suggests. Can you file a bug upstream with docker? Here: https://github.com/dotcloud/docker/issues Please just take the information you posted above and post it there. Thanks. Well spotted. Best, William --- Additional comment from Lukas Doktor on 2014-05-02 04:02:01 EDT --- Upstream tracer: https://github.com/dotcloud/docker/issues/5547 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1087697 [Bug 1087697] man page inaccuracy about --sig-proxy and --tty -- You are receiving this mail because: You are on the CC list for the bug.

1 21

[Bug 1096276] New: signal 27 (SIGPROF) not passed to container using --sig-proxy
by Red Hat Bugzilla 07 Jan '16

07 Jan '16

https://bugzilla.redhat.com/show_bug.cgi?id=1096276 Bug ID: 1096276 Summary: signal 27 (SIGPROF) not passed to container using --sig-proxy Product: Red Hat Enterprise Linux 7 Version: 7.1 Component: docker Assignee: lsm5(a)redhat.com Reporter: ldoktor(a)redhat.com QA Contact: virt-bugs(a)redhat.com CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, skottler(a)redhat.com, vbatts(a)redhat.com Depends On: 1087720 +++ This bug was initially created as a clone of Bug #1087720 +++ Description of problem: When I send signal 27 to the docker process, which is running with --sig-proxy=true, it's not forwarded. Other signals are... Version-Release number of selected component (if applicable): docker-0.10.0-8.el7.x86_64 docker-io-0.9.1-1.fc21.x86_64 upstream Docker version 0.10.0, build dc9c28f/0.10.0 How reproducible: always Steps to Reproduce: 1. /usr/bin/docker -D run --tty=false --rm -i --name test_eoly localhost:5000/ldoktor/fedora:latest bash -c 'for NUM in `seq 1 64`; do trap "echo Received $NUM, ignoring..." $NUM; done; while :; do sleep 1; done' 2. ps ax |grep docker 3. kill -27 $PID Actual results: nothing Expected results: Received 27, ignoring... Additional info: When you send any other signal (apart from 19 or 9) it works fine. --- Additional comment from Lukas Doktor on 2014-04-15 04:59:24 EDT --- The signal 17 is also ignored. --- Additional comment from Lukas Doktor on 2014-05-05 03:48:25 EDT --- The same bug is in upstream Docker version 0.10.0, build dc9c28f/0.10.0 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1087720 [Bug 1087720] signal 27 (SIGPROF) not passed to container using --sig-proxy -- You are receiving this mail because: You are on the CC list for the bug.

1 26

[Bug 1108349] New: remove golang-github-syndtr-gocapability from epel7
by Red Hat Bugzilla 03 Jul '15

03 Jul '15

https://bugzilla.redhat.com/show_bug.cgi?id=1108349 Bug ID: 1108349 Summary: remove golang-github-syndtr-gocapability from epel7 Product: Fedora EPEL Version: epel7 Component: golang-github-syndtr-gocapability Assignee: vbatts(a)redhat.com Reporter: lsm5(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, vbatts(a)redhat.com Description of problem: remove this package from epel7 as it's now available in rhel7 proper. Version-Release number of selected component (if applicable): golang-github-syndtr-gocapability-0-0.5.git3454319.el7 Additional info: retired from dist-git: http://pkgs.fedoraproject.org/cgit/golang-github-syndtr-gocapability.git/tr… For pkgdb, Vincent could you run this for the epel7 branch (I'm not an admin for this one): pkgdb-cli orphan --retire golang-github-syndtr-gocapability epel7 -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1108337] New: remove golang-googlecode-sqlite from epel7
by Red Hat Bugzilla 03 Jul '15

03 Jul '15

https://bugzilla.redhat.com/show_bug.cgi?id=1108337 Bug ID: 1108337 Summary: remove golang-googlecode-sqlite from epel7 Product: Fedora EPEL Version: epel7 Component: golang-googlecode-sqlite Assignee: lsm5(a)redhat.com Reporter: lsm5(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, vbatts(a)redhat.com Description of problem: this package should be removed from epel7 as it's now available in rhel7 proper Version-Release number of selected component (if applicable): golang-googlecode-sqlite-0-0.9.hg74691fb6f837.el7 Additional info: retired from dist-git: http://pkgs.fedoraproject.org/cgit/golang-googlecode-sqlite.git/tree/?h=epe… orphaned in pkgdb: https://admin.fedoraproject.org/pkgdb/package/golang-googlecode-sqlite/ -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1108270] New: remove golang-googlecode-net from epel7
by Red Hat Bugzilla 03 Jul '15

03 Jul '15

https://bugzilla.redhat.com/show_bug.cgi?id=1108270 Bug ID: 1108270 Summary: remove golang-googlecode-net from epel7 Product: Fedora EPEL Version: epel7 Component: golang-googlecode-net Assignee: lsm5(a)redhat.com Reporter: lsm5(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, vbatts(a)redhat.com Description of problem: this package should be removed from epel7 as it's available in rhel7 proper Version-Release number of selected component (if applicable): golang-googlecode-net-0-0.13.hg84a4013f96e0.el7 Additional info: epel7 orphaned: https://admin.fedoraproject.org/pkgdb/package/golang-googlecode-net/ retired from dist-git: http://pkgs.fedoraproject.org/cgit/golang-googlecode-net.git/tree/?h=epel7 -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1108249] New: remove golang-github-gorilla-mux from epel7
by Red Hat Bugzilla 03 Jul '15

03 Jul '15

https://bugzilla.redhat.com/show_bug.cgi?id=1108249 Bug ID: 1108249 Summary: remove golang-github-gorilla-mux from epel7 Product: Fedora EPEL Version: epel7 Component: golang-github-gorilla-mux Assignee: lsm5(a)redhat.com Reporter: lsm5(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, vbatts(a)redhat.com Description of problem: remove this package from epel7 as it exists in rhel7 proper Version-Release number of selected component (if applicable): golang-github-gorilla-mux-0-0.13.git136d54f.el7 Additional info: retired from dist-git: http://pkgs.fedoraproject.org/cgit/golang-github-gorilla-mux.git/tree/?h=ep… orphaned in pkgdb: https://admin.fedoraproject.org/pkgdb/package/golang-github-gorilla-mux/ -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1108248] New: remove golang-github-gorilla-context from epel7
by Red Hat Bugzilla 03 Jul '15

03 Jul '15

https://bugzilla.redhat.com/show_bug.cgi?id=1108248 Bug ID: 1108248 Summary: remove golang-github-gorilla-context from epel7 Product: Fedora EPEL Version: epel7 Component: golang-github-gorilla-context Assignee: lsm5(a)redhat.com Reporter: lsm5(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com Description of problem: this package should be removed from epel7 as it exists in RHEL7 proper Version-Release number of selected component (if applicable): golang-github-gorilla-context-0-0.23.gitb06ed15.el7 Additional info: retired from dist-git: http://pkgs.fedoraproject.org/cgit/golang-github-gorilla-context.git/tree/?… orphaned in pkgdb: https://admin.fedoraproject.org/pkgdb/package/golang-github-gorilla-context/ -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1108244] New: remove golang-github-kr-pty from epel7
by Red Hat Bugzilla 03 Jul '15

03 Jul '15

https://bugzilla.redhat.com/show_bug.cgi?id=1108244 Bug ID: 1108244 Summary: remove golang-github-kr-pty from epel7 Product: Fedora EPEL Version: epel7 Component: golang-github-kr-pty Assignee: lsm5(a)redhat.com Reporter: lsm5(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com Description of problem: Remove this package from epel7 as exists in RHEL7 proper Version-Release number of selected component (if applicable): golang-github-kr-pty-0-0.19.git67e2db2.el7 Additional info: retired from dist-git http://pkgs.fedoraproject.org/cgit/golang-github-kr-pty.git/tree/?h=epel7 and orphaned from pkgdb https://admin.fedoraproject.org/pkgdb/package/golang-github-kr-pty/ -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1100502] New: golang-1.2.2-2 update breaks GOROOT path
by Red Hat Bugzilla 30 Jun '15

30 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1100502 Bug ID: 1100502 Summary: golang-1.2.2-2 update breaks GOROOT path Product: Fedora Version: 20 Component: golang Assignee: adam(a)spicenitz.org Reporter: porjo38(a)yahoo.com.au 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 Since updating to golang-1.2.2-2, I get error "go: cannot find GOROOT directory: /usr/lib64/golang" when trying to run a go program e.g. "go run main.go" Adding a symbolic link fixes the issue: ln -s /usr/lib/golang/ /usr/lib64/golang -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1099732] New: go install fails if cgo is used
by Red Hat Bugzilla 30 Jun '15

30 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1099732 Bug ID: 1099732 Summary: go install fails if cgo is used Product: Fedora Version: 20 Component: golang Assignee: adam(a)spicenitz.org Reporter: davidb(a)davidb.org 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 Created attachment 897821 --> https://bugzilla.redhat.com/attachment.cgi?id=897821&action=edit Example program to provoke bug Description of problem: 'go install' tries to compile runtime/cgo.a and install it in /usr/lib when the source makes use of Cgo. Version-Release number of selected component (if applicable): golang-src-1.2.2-2.fc20.noarch golang-1.2.2-2.fc20.x86_64 golang-pkg-linux-amd64-1.2.2-2.fc20.noarch golang-pkg-bin-linux-amd64-1.2.2-2.fc20.x86_64 How reproducible: Always Steps to Reproduce: 1. Create directory with src/bug1/hello.go containing the attached file. 2. GOPATH=$(PWD) /usr/bin/go install bug1 Actual results: go install runtime/cgo: open /usr/lib/golang/pkg/linux_amd64/runtime/cgo.a: permission denied Expected results: Produces bin/bug1, which when run prints hello world. This worked fine with 1.2.1 (before today's update). Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1096293] New: `docker start` doesn't fail on started container
by Red Hat Bugzilla 30 Jun '15

30 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1096293 Bug ID: 1096293 Summary: `docker start` doesn't fail on started container Product: Red Hat Enterprise Linux 7 Version: 7.1 Component: docker Assignee: lsm5(a)redhat.com Reporter: ldoktor(a)redhat.com QA Contact: virt-bugs(a)redhat.com CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com Depends On: 1090071 +++ This bug was initially created as a clone of Bug #1090071 +++ Description of problem: On older (0.9) docker, the `docker start $running_container` failed. The new 0.10.2 version just prints the container name and proceeds. Version-Release number of selected component (if applicable): docker-0.10.0-8.el7.x86_64 docker-io-0.10.0-2.fc20.x86_64 How reproducible: Always Steps to Reproduce: 1. docker run -i -t -name test fedora bash 2. docker start test Actual results: [root@t530 ~]# docker start test test [root@t530 ~]# echo &? 0 Expected results: [root@t530 ~]# docker start test Error: Cannot start container test: The container 429d709bc86c037b09e9f74dfab40aa33dc19bcf3109daf3f5b2fbbd3c6df297 is already running. 2014/04/22 15:29:28 Error: failed to start one or more containers [root@t530 ~]# echo &? 1 --- Additional comment from Lukas Doktor on 2014-05-05 03:38:57 EDT --- Upstream Docker version 0.10.0, build dc9c28f/0.10.0 has the same issue (silently passes even thought the container was already running) Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1090071 [Bug 1090071] `docker start` doesn't fail on started container -- You are receiving this mail because: You are on the CC list for the bug.

1 15

[Bug 1090071] New: `docker start` doesn't fail on started container
by Red Hat Bugzilla 30 Jun '15

30 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1090071 Bug ID: 1090071 Summary: `docker start` doesn't fail on started container Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: ldoktor(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com Description of problem: On older (0.9) docker, the `docker start $running_container` failed. The new 0.10.2 version just prints the container name and proceeds. Version-Release number of selected component (if applicable): docker-io-0.10.0-2.fc20.x86_64 How reproducible: Always Steps to Reproduce: 1. docker run -i -t -name test fedora bash 2. docker start test Actual results: [root@t530 ~]# docker start test test [root@t530 ~]# echo &? 0 Expected results: [root@t530 ~]# docker start test Error: Cannot start container test: The container 429d709bc86c037b09e9f74dfab40aa33dc19bcf3109daf3f5b2fbbd3c6df297 is already running. 2014/04/22 15:29:28 Error: failed to start one or more containers [root@t530 ~]# echo &? 1 -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 1096269] New: lost signals when sending lots of signals using --sig-proxy to docker
by Red Hat Bugzilla 30 Jun '15

30 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1096269 Bug ID: 1096269 Summary: lost signals when sending lots of signals using --sig-proxy to docker Product: Red Hat Enterprise Linux 7 Version: 7.1 Component: docker Assignee: lsm5(a)redhat.com Reporter: ldoktor(a)redhat.com QA Contact: virt-bugs(a)redhat.com CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, skottler(a)redhat.com, vbatts(a)redhat.com Depends On: 1087700 +++ This bug was initially created as a clone of Bug #1087700 +++ Description of problem: When I send lots of signals to the running docker with --sig-proxy (actual kill signals, not `docker kill`), most of them got lost. Version-Release number of selected component (if applicable): docker-0.10.0-8.el7.x86_64 docker-io-0.9.1-1.fc21.x86_64 How reproducible: always Steps to Reproduce: 1. /usr/bin/docker -D run --tty=false --rm -i --name test_eoly localhost:5000/ldoktor/fedora:latest bash -c 'for NUM in `seq 1 64`; do trap "echo Received $NUM, ignoring..." $NUM; done; while :; do sleep 1; done' 2. ps ax |grep docker 3. for AAA in `seq 1 32`; do [ $AAA -ne 9 ] && [ $AAA -ne 20 ] && [ $AAA -ne 19 ] && kill -s $AAA $PID; done Actual results: Output of the docker is: Received 1, ignoring... Received 2, ignoring... Expected results: Messages for all of the `Received $NUM, ignoring...` printed (order doesn't matter) Additional info: Skipping 9, 19, 20 as they are a bit too special.. --- Additional comment from Lukas Doktor on 2014-05-05 04:10:09 EDT --- The same results with upstream docker dc9c28f/0.10.0: Output: Received 1, ignoring... [debug] stdcopy.go:111 framesize: 24 Received 2, ignoring... Daemon output: 2014/05/05 10:08:45 POST /v1.10/containers/b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5/kill?signal=HUP [/home/medic/Work/Projekty/Docker/root|fa3816b6] +job kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, HUP) [/home/medic/Work/Projekty/Docker/root|fa3816b6] -job kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, HUP) = OK (0) 2014/05/05 10:08:45 POST /v1.10/containers/b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5/kill?signal=INT [/home/medic/Work/Projekty/Docker/root|fa3816b6] +job kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, INT) [/home/medic/Work/Projekty/Docker/root|fa3816b6] -job kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, INT) = OK (0) Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1087700 [Bug 1087700] lost signals when sending lots of signals using --sig-proxy to docker -- You are receiving this mail because: You are on the CC list for the bug.

1 22

[Bug 1087697] New: man page inaccuracy about --sig-proxy and --tty
by Red Hat Bugzilla 30 Jun '15

30 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1087697 Bug ID: 1087697 Summary: man page inaccuracy about --sig-proxy and --tty Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: ldoktor(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, skottler(a)redhat.com, vbatts(a)redhat.com Description of problem: Hi guys, the man page states: --sig-proxy=true: Proxify all received signal to the process (even in non-tty mode) But the real behavior is, that sig-proxy doesn't work when --tty=true. It should be mentioned in there, taht --sig-proxy is incompatible with --tty. Version-Release number of selected component (if applicable): docker-io-0.9.1-1.fc21.x86_64 How reproducible: always Steps to Reproduce: 1. man docker Actual results: man page says it works even in non-tty Expected results: man page warns that --tty can't be used with --sig-proxy How to verify: 1. docker run --tty=true -i --rm fedora bash -c 'for NUM in `seq 1 64`; do trap "echo Received $NUM, ignoring..." $NUM; done; while :; do sleep 1; done' 2. ps -ax | grep docker 3. kill -SIGUSR1 $PID 4. (with --tty=true no signals are received, when you try the same with --tty=false, signals are proxified and messages are displayed) -- You are receiving this mail because: You are on the CC list for the bug.

1 21

[Bug 1075232] New: 0.9.0 Adds virtual interface, NetworkManager attempts to assign dhcp address to it
by Red Hat Bugzilla 29 Jun '15

29 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1075232 Bug ID: 1075232 Summary: 0.9.0 Adds virtual interface, NetworkManager attempts to assign dhcp address to it Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: admiller(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, skottler(a)redhat.com, vbatts(a)redhat.com Created attachment 873221 --> https://bugzilla.redhat.com/attachment.cgi?id=873221&action=edit snippet from /var/log/messages for my laptop around the virtual interface events Description of problem: When you install docker-io-0.9.0 on Fedora 20, it creates a new virtual interface 13: vethf3e3: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master docker0 state UP group default qlen 1000 link/ether 1a:9c:40:61:1e:8b brd ff:ff:ff:ff:ff:ff inet6 fe80::189c:40ff:fe61:1e8b/64 scope link valid_lft forever preferred_lft forever Something (I'm thinking dbus or udev) causes NetworkManager to launch dhclient for the new interface, and if you're running with a Desktop Environment this causes a visual change to the NM applet which can be confusing. It doesn't ever do anything, NM eventually times out and gives up and this doesn't appear to impact docker's functionality at all (or at least not yet in my tests have I found an issue, networking works fine). Version-Release number of selected component (if applicable): docker-io-0.9.0-2.fc20.x86_64 How reproducible: Always Steps to Reproduce: 1. yum install docker-io #on a machine with a GUI/DE up and running with NetworkManager Actual results: NetworkManager attempts to get a dhcp lease on the new virtual interface. Expected results: NetworkManager probably shouldn't attempt to get a dhcp lease on the new virtual interface, this seems odd. Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1033606] New: Failed to connect to network from Docker container
by Red Hat Bugzilla 17 Jun '15

17 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1033606 Bug ID: 1033606 Summary: Failed to connect to network from Docker container Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: mfojtik(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, vbatts(a)redhat.com Description of problem: Connecting to external network from Docker container fail due to firewalld. I guess you must have masquerade enabled, however this is not mentioned anywhere. I think docker-io should set the firewalld rules automatically, or tell users that they need to enable masquarade in firewalld. Version-Release number of selected component (if applicable): Name : docker-io Arch : x86_64 Version : 0.7 Release : 0.17.rc6.fc20 Steps to Reproduce: 1. $ yum install docker-io 2. $ systemctl enable docker.service 3. $ systemctl start docker.service 4. $ docker pull mattdm/fedora 5. $ docker run -i -t mattdm/fedora:latest /bin/bash 6. $ ping google.com ping: unknown host google.com When I stop firewalld on host (systemctl stop firewalld) and then restart the docker (systemctl restart docker), the ping works like a charm. Actual results: Unable to connect outside the Docker container with firewalld enabled. Expected results: Docker should configure firewalld automatically (during install?), or inform users to do so manually. Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 68

[Bug 1096286] New: "docker top all" doesn't show processes when --tty=false
by Red Hat Bugzilla 02 Jun '15

02 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1096286 Bug ID: 1096286 Summary: "docker top all" doesn't show processes when --tty=false Product: Red Hat Enterprise Linux 7 Version: 7.1 Component: docker Assignee: lsm5(a)redhat.com Reporter: ldoktor(a)redhat.com QA Contact: virt-bugs(a)redhat.com CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, skottler(a)redhat.com, vbatts(a)redhat.com Depends On: 1088259 +++ This bug was initially created as a clone of Bug #1088259 +++ After using the same magic required for the upstream docker 0.10 this behaves the same on RHEL docker-0.10.0-8.el7.x86_64 Description of problem: Hi guys, when I run docker with --tty=false, the `docker top $NAME all` doesn't show any processes (just headers). When using only `docker top $NAME` it shows them... Also the `ps` command inside container works, but `ps all` does not. Version-Release number of selected component (if applicable): docker-0.10.0-8.el7.x86_64 docker-io-0.9.0-3.fc20.x86_64 How reproducible: always Steps to Reproduce: 1. docker run -i --tty=false fedora bash 2. docker logs $NAME Actual results: F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND Expected results: F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 1 0 24006 23954 20 0 11732 540 - R pts/14 0:00 bash --- Additional comment from Lukas Doktor on 2014-05-05 03:41:35 EDT --- Can't reproduce with the upstream Docker version 0.10.0, build dc9c28f/0.10.0 top doesn't work at all (due of https://bugzilla.redhat.com/show_bug.cgi?id=1088125 ) --- Additional comment from Lukas Doktor on 2014-05-05 03:46:07 EDT --- OK I moved it to the old cgroup location and the results are the same. So booth, fedora docker-io-0.9.0-3.fc20.x86_64 and upstream dc9c28f/0.10.0 are unable to list processes using `all` argument in non-tty mode. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1088259 [Bug 1088259] "docker top all" doesn't show processes when --tty=false -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1088259] New: "docker top all" doesn't show processes when --tty=false
by Red Hat Bugzilla 02 Jun '15

02 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1088259 Bug ID: 1088259 Summary: "docker top all" doesn't show processes when --tty=false Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: ldoktor(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, skottler(a)redhat.com, vbatts(a)redhat.com Description of problem: Hi guys, when I run docker with --tty=false, the `docker top $NAME all` doesn't show any processes (just headers). When using only `docker top $NAME` it shows them... Also the `ps` command inside container works, but `ps all` does not. Version-Release number of selected component (if applicable): docker-io-0.9.0-3.fc20.x86_64 How reproducible: always Steps to Reproduce: 1. docker run -i --tty=false fedora bash 2. docker logs $NAME Actual results: F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND Expected results: F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 1 0 24006 23954 20 0 11732 540 - R pts/14 0:00 bash -- You are receiving this mail because: You are on the CC list for the bug.

1 29

[Bug 1111189] New: yumBackend started with each `docker start`
by Red Hat Bugzilla 29 May '15

29 May '15

https://bugzilla.redhat.com/show_bug.cgi?id=1111189 Bug ID: 1111189 Summary: yumBackend started with each `docker start` Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: ldoktor(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, hushan.jia(a)gmail.com, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com Description of problem: Hello guys, today I noticed 100% utilization followed by each `docker run` or `docker start`. It wasn't caused by the docker itself, but with each instance, yumBackend is executed. It never happened with older version. 4806 ? RN 0:00 /usr/bin/python /usr/share/PackageKit/helpers/yum/yuBackend.py get-updates none Version-Release number of selected component (if applicable): docker-io-1.0.0-1.fc20.x86_64 How reproducible: always Steps to Reproduce: 1. docker run -t -i fedora bash 2. top 3. ps ax |grep yum Actual results: yumBackend is started and takes couple of secconds in 100% utilization 4806 ? RN 0:00 /usr/bin/python /usr/share/PackageKit/helpers/yum/yuBackend.py get-updates none Expected results: Apart from container no other processes should be started. (I can run `docker run -t -i fedora bash -c exit` which finishes immediately and the only process using cpu is the yumBackend process) Additional info: I tried executing `busybox sh`, `bash -c exit`, .... I even rebooted the machine but the results are the same. -- You are receiving this mail because: You are on the CC list for the bug.

1 16

[Bug 1102751] New: Got "Error running removeDevice" after kill -9 docker
by Red Hat Bugzilla 29 May '15

29 May '15

https://bugzilla.redhat.com/show_bug.cgi?id=1102751 Bug ID: 1102751 Summary: Got "Error running removeDevice" after kill -9 docker Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: mfojtik(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com Description of problem: While I was playing with Docker today, I found interesting behavior: When you 'kill -9' the 'docker -d' process, then this happens: 1. The 'docker -d' process gets killed ;-) 2. All containers gets killed 3. The 'docker -d' restarts, because of Restart=on-failure Now, while all this is expected and OK, I get this when I tried to 'restart' the container that was killed in 2): May 29 13:24:56 ip-10-146-193-102 systemd[1]: Starting Container origin-db-1... May 29 13:24:56 ip-10-146-193-102 sh[19731]: Reusing b80104263de02f39bbc6d742c977ddadecb0660f5c50386eaf1cf645f3515b9c May 29 13:25:07 ip-10-146-193-102 docker[19739]: Error: Cannot destroy container origin-db-1: Driver devicemapper failed to remove root filesystem e536cf328e0083e2414c750434deb1127517d00399fddac84903825d6f003787: Error running removeDevice May 29 13:25:07 ip-10-146-193-102 docker[19739]: 2014/05/29 13:25:07 Error: failed to remove one or more containers May 29 13:25:07 ip-10-146-193-102 gear[21193]: user: unknown user ctr-origin-db-1 May 29 13:25:09 ip-10-146-193-102 docker[21192]: 2014/05/29 13:25:09 Error: Cannot start container bd1a88a35e84ef6d71fa3e1df0b4e2998318dfed6d60fd3ae381567fff2ac2a3: Cannot find child for /origin-db-1 May 29 13:25:09 ip-10-146-193-102 systemd[1]: ctr-origin-db-1.service: main process exited, code=exited, status=1/FAILURE Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Start up some containers 2. kill -9 (the 'docker -d' process pid) 3. Try to start the dead container again 4. Get the error above. Actual results: Expected results: Containers should be successfully started back. Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 5

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang June 2014