golang July 2014

golang@lists.fedoraproject.org

8 participants
308 discussions

[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 29 Jun '15

29 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 29 Jun '15

29 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 29 Jun '15

29 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 29 Jun '15

29 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 29 Jun '15

29 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 29 Jun '15

29 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang July 2014