golang December 2014

golang@lists.fedoraproject.org

9 participants
334 discussions

[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 1140398] New: Catastrophic failure saving large images
by Red Hat Bugzilla 30 Jun '15

30 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1140398 Bug ID: 1140398 Summary: Catastrophic failure saving large images Product: Fedora Version: 20 Component: docker-io Severity: medium Assignee: lsm5(a)fedoraproject.org Reporter: briemers(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, jperrin(a)centos.org, lsm5(a)fedoraproject.org, mattdm(a)redhat.com, mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com Description of problem: Large docker images are saved written first to temp. As such when one does a "docker save" for a large image the save process will error out with a disk full error. Afterwards, there will be mounting error if attempting to save the image again after resizing tmp. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Create an image much larger than your /tmp space 2. Attempt to save 3. Actual results: [briemers@briemersw staging]$ docker save -o /data/oracle-xe-prod.dimg oracle-xe-prod 2014/09/10 16:41:23 Error: write /tmp/docker-export-336322967/dd28f4e8cb55517c4a97560a6adc9d2032b9fdfe4fb744857648067f66125a38/layer.tar: no space left on device [briemers@briemersw staging]$ sudo mount -o remount,size=20g /tmp [sudo] password for briemers: [briemers@briemersw staging]$ docker save -o /data/oracle-xe-prod.dimg oracle-xe-prod 2014/09/10 16:43:25 Error: Error mounting '/dev/mapper/docker-253:2-2097434-dd28f4e8cb55517c4a97560a6adc9d2032b9fdfe4fb744857648067f66125a38' on '/var/lib/docker/devicemapper/mnt/dd28f4e8cb55517c4a97560a6adc9d2032b9fdfe4fb744857648067f66125a38': device or resource busy [briemers@briemersw staging]$ sudo service docker restart Redirecting to /bin/systemctl restart docker.service [briemers@briemersw staging]$ docker save -o /data/oracle-xe-prod.dimg oracle-xe-prod 2014/09/10 16:43:52 Error: Error mounting '/dev/mapper/docker-253:2-2097434-dd28f4e8cb55517c4a97560a6adc9d2032b9fdfe4fb744857648067f66125a38' on '/var/lib/docker/devicemapper/mnt/dd28f4e8cb55517c4a97560a6adc9d2032b9fdfe4fb744857648067f66125a38': device or resource busy Expected results: I would not expect the process to need massive amounts of /tmp space, if so it should have an option to specify where the tmp files are written. Also, the process needs to clean-up it's locks so subsiquent commands don't fail. Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[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 1140405] New: systemctl start docker fails because systemd continuously restarts the daemon
by Red Hat Bugzilla 30 Jun '15

30 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1140405 Bug ID: 1140405 Summary: systemctl start docker fails because systemd continuously restarts the daemon Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)fedoraproject.org Reporter: a.badger(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, hushan.jia(a)gmail.com, jperrin(a)centos.org, lsm5(a)fedoraproject.org, mattdm(a)redhat.com, mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com Description of problem: I've installed docker for the first time and tried to start it with "systemctl start docker". The systemctl command returns successfully but then trying to run docker client commands against the daemon timed out. After some poking around I discovered that systemd was starting docker. Docker was taking quite a while to do various initialization tasks including invoking mkfs. systemd decided that docker was unresponsive and terminated it and then restarted it. Because mkfs hadn't finished, docker had to try running mkfs again. This cycle kept continuing and would probably have prevented docker from fully starting up forever. I worked around the problem by telling systemd not to start docker, running the docker daemon manually from a shell, waiting until the mkfs had completed, then shutting down my daemon and rerunning systemctl start docker. After that, the docker service runs fine. Version-Release number of selected component (if applicable): docker-io-1.2.0-2.fc20.x86_64 How reproducible: Everytime for me until after I ran docker as a daemon manually. I don't know how to reproduce once docker has initialized (Probably removing some file or volume but I don't know what it would be). Steps to Reproduce: 1. On a system that hasn't had docker running before 2. yum install docker-io 3. systemctl start docker 4. watch the output of systemctl status docker -l Actual results: systemctl status docker -l will report that docker is in state Activating for several minutes, then show that systemd decided docker wasn't responding, terminate it, and restart. The -l output will also show that docker is running mkfs for most of that time and is still running it when docker is terminated. Expected results: systemctl status docker -l will show that the state has gone to active (running) Additional info: * My filesystem is ext4. The docker initialization is running mkfs.ext4 * I'm using a 4-5 year old laptop with platter HDs. A faster machine or SSD drives might run mkfs quickly enough to not see this issue. * This might be "fixed" by adding some documentation that says to perform certain steps to initialize docker before running systemctl start docker rather than changing docker code to finish initialization sooner. -- You are receiving this mail because: You are on the CC list for the bug.

1 15

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang December 2014