golang April 2014

golang@lists.fedoraproject.org

7 participants
400 discussions

[Bug 1033604] New: Unable to start systemd service in Docker container
by Red Hat Bugzilla 19 May '15

19 May '15

https://bugzilla.redhat.com/show_bug.cgi?id=1033604 Bug ID: 1033604 Summary: Unable to start systemd service in 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: Using Dockerfile like this: FROM mattdm/fedora:latest RUN yum update -y RUN yum install -y redis RUN systemctl enable redis.service RUN systemctl start redis.service EXPOSE 6379 ENTRYPOINT ["/usr/bin/redis-cli"] The step 'systemctl start redis.service' failed with this error message: Failed to get D-Bus connection: No connection to service manager. 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. Save the above Dockerfile 2. Run: docker build -t test/redis . 3. The build fill faile on systemctl start. Actual results: The service failed to start due to D-BUS connection. Expected results: The service should be started? Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 33

[Bug 1092136] New: Docker commands pause streaming audio
by Red Hat Bugzilla 28 Apr '15

28 Apr '15

https://bugzilla.redhat.com/show_bug.cgi?id=1092136 Bug ID: 1092136 Summary: Docker commands pause streaming audio Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: mdavis(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: Execution of docker commands cause streaming audio to pause briefly (3-4 seconds) Version-Release number of selected component (if applicable): [root@dhcp81-173 ~]# rpm -q docker-io firefox flash-plugin docker-io-0.9.1-1.fc20.x86_64 firefox-28.0-3.fc20.x86_64 flash-plugin-11.2.202.350-release.x86_64 [root@dhcp81-173 ~]# uname -s -r -v -m Linux 3.13.10-200.fc20.x86_64 #1 SMP Mon Apr 14 20:34:16 UTC 2014 x86_64 How reproducible: Nearly every docker command does this. Steps to Reproduce: 1. Start up firefox and start listening to a streaming audio service (I reproduced it on spotify.com, using the spotify web player) 2. Run a docker command. For example... [root@dhcp81-173 ~]# docker images REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE 10.3.76.138:5000/rhel6-base latest 60f3b7e9ba33 6 weeks ago 1.437 GB rhel6-base latest 60f3b7e9ba33 6 weeks ago 1.437 GB 10.3.76.138:5000/rhel7b-base latest b96a0bc033bb 8 weeks ago 827.9 MB fedora rawhide 0d20aec6529d 12 weeks ago 387 MB fedora 20 58394af37342 12 weeks ago 385.5 MB fedora heisenbug 58394af37342 12 weeks ago 385.5 MB fedora latest 58394af37342 12 weeks ago 385.5 MB busybox latest 769b9341d937 12 weeks ago 2.489 MB [root@dhcp81-173 ~]# docker run 0d2 id uid=0(root) gid=0(root) groups=0(root) [root@dhcp81-173 ~]# Actual results: Currently playing audio paused for 3 seconds after running the 'id' command. Expected results: Uninterrupted audio playing Additional info: I'm running Fedora 20 XFCE build. -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 1046717] New: Cancel run or pull operation doesn't actually stop the ongoing task
by Red Hat Bugzilla 15 Apr '15

15 Apr '15

https://bugzilla.redhat.com/show_bug.cgi?id=1046717 Bug ID: 1046717 Summary: Cancel run or pull operation doesn't actually stop the ongoing task Product: Fedora Version: 20 Component: docker-io Severity: medium Assignee: lsm5(a)redhat.com Reporter: baptiste.millemathias(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: I've downloaded a docker image using "docker pull bradrydzewski/mongodb:2.4" and when I wanted to run it I did a "docker run bradrydzewski/mongodb" as the image name was named like that, and I saw docker pulling another image (the size was different), so I hit Ctrl+C thinking to going kill the operation. However a ps fax showed me dockerd was still downloading something, certainly image bradrydzewski/mongodb Version-Release number of selected component (if applicable): docker-io-0.7.0-14.fc20.x86_64 How reproducible: 100 % Steps to Reproduce: 1. docker pull bradrydzewski/mongodb:2.4 (let the complete operation happens) 2. docker run bradrydzewski/mongodb, and hit ctrl+c after few seconds Actual results: Dockerd still download image Expected results: docker client should ask Dockerd to cancel the download of the image -- You are receiving this mail because: You are on the CC list for the bug.

1 9

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

15 Apr '15

https://bugzilla.redhat.com/show_bug.cgi?id=1087704 Bug ID: 1087704 Summary: repetition of signal 21 with --sig-proxy and SIGSTOP of docker Product: Fedora Version: 20 Component: docker-io Severity: low 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: 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-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... -- You are receiving this mail because: You are on the CC list for the bug.

1 13

[Bug 1087720] New: signal 27 (SIGPROF) not passed to container using --sig-proxy
by Red Hat Bugzilla 15 Apr '15

15 Apr '15

https://bugzilla.redhat.com/show_bug.cgi?id=1087720 Bug ID: 1087720 Summary: signal 27 (SIGPROF) not passed to container using --sig-proxy 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: 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-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 -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. -- You are receiving this mail because: You are on the CC list for the bug.

1 17

[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 1056185] New: go test code.google.com/p/go.net/ipv6 test fails
by Red Hat Bugzilla 26 Jan '15

26 Jan '15

https://bugzilla.redhat.com/show_bug.cgi?id=1056185 Bug ID: 1056185 Summary: go test code.google.com/p/go.net/ipv6 test fails Product: Fedora EPEL Version: el6 Component: golang-googlecode-net Assignee: lsm5(a)redhat.com Reporter: tis(a)foobar.fi 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: %check fails if machine you build this package on has ipv6 connectivity. + go test code.google.com/p/go.net/ipv6 --- FAIL: TestConnInitiatorPathMTU (0.00 seconds) sockopt_test.go:58: ipv6.Conn.PathMTU failed: getsockopt: protocol not available --- FAIL: TestConnResponderPathMTU (0.00 seconds) sockopt_test.go:91: ipv6.Conn.PathMTU failed: getsockopt: protocol not available --- FAIL: TestPacketConnReadWriteUnicastUDP (0.00 seconds) unicast_test.go:120: ipv6.PacketConn.SetControlMessage failed: setsockopt: protocol not available FAIL FAIL code.google.com/p/go.net/ipv6 0.041s RPM build errors: error: Bad exit status from /var/tmp/rpm-tmp.DbihRB (%check) I guess package is broken for ipv6. -- You are receiving this mail because: You are on the CC list for the bug.

1 34

[Bug 1047194] New: etcd-0.2.0 is available
by Red Hat Bugzilla 01 Nov '14

01 Nov '14

https://bugzilla.redhat.com/show_bug.cgi?id=1047194 Bug ID: 1047194 Summary: etcd-0.2.0 is available Product: Fedora Version: rawhide Component: etcd Keywords: FutureFeature, Triaged Assignee: lacypret(a)gmail.com Reporter: upstream-release-monitoring(a)fedoraproject.org QA Contact: extras-qa(a)fedoraproject.org CC: golang(a)lists.fedoraproject.org, lacypret(a)gmail.com, lemenkov(a)gmail.com, lsm5(a)redhat.com Latest upstream release: 0.2.0 Current version/release in Fedora Rawhide: 0.1.2-5.fc21 URL: https://api.github.com/repos/coreos/etcd/tags Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug.

1 32

[Bug 1069718] New: Kernel container scalability issue in docker - VFS and mount path consuming too much CPU
by Red Hat Bugzilla 15 Sep '14

15 Sep '14

https://bugzilla.redhat.com/show_bug.cgi?id=1069718 Bug ID: 1069718 Summary: Kernel container scalability issue in docker - VFS and mount path consuming too much CPU Product: Red Hat Enterprise Linux 7 Version: 7.0 Component: systemd Severity: urgent Priority: urgent Assignee: systemd-maint(a)redhat.com Reporter: sct(a)redhat.com QA Contact: qe-baseos-daemons(a)redhat.com CC: agk(a)redhat.com, alexl(a)redhat.com, fs-maint(a)redhat.com, fweimer(a)redhat.com, golang(a)lists.fedoraproject.org, ikent(a)redhat.com, jeder(a)redhat.com, jpoimboe(a)redhat.com, lsm5(a)redhat.com, lvm-team(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, mjenner(a)redhat.com, perfbz(a)redhat.com, rwheeler(a)redhat.com, skottler(a)redhat.com, vbatts(a)redhat.com Depends On: 1061359, 1064929 Group: private Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1061359 [Bug 1061359] improve docker devicemapper backend scalability https://bugzilla.redhat.com/show_bug.cgi?id=1064929 [Bug 1064929] Kernel container scalability issue in docker - VFS and mount path consuming too much CPU -- You are receiving this mail because: You are on the CC list for the bug.

1 27

[Bug 1064929] New: Kernel container scalability issue in docker devicemapper backend
by Red Hat Bugzilla 15 Sep '14

15 Sep '14

https://bugzilla.redhat.com/show_bug.cgi?id=1064929 Bug ID: 1064929 Summary: Kernel container scalability issue in docker devicemapper backend Product: Red Hat Enterprise Linux 7 Version: 7.0 Component: kernel Severity: high Assignee: kernel-mgr(a)redhat.com Reporter: sct(a)redhat.com QA Contact: kernel-qe(a)redhat.com CC: agk(a)redhat.com, alexl(a)redhat.com, golang(a)lists.fedoraproject.org, jeder(a)redhat.com, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, skottler(a)redhat.com, vbatts(a)redhat.com Depends On: 1061359 Blocks: 1064012 Group: private Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1061359 [Bug 1061359] improve docker devicemapper backend scalability https://bugzilla.redhat.com/show_bug.cgi?id=1064012 [Bug 1064012] improve docker devicemapper backend scalability -- You are receiving this mail because: You are on the CC list for the bug.

1 22

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang April 2014