golang June 2015

golang@lists.fedoraproject.org

2 participants
110 discussions

[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

[Bug 1140405] New: systemctl start docker fails because systemd continuously restarts the daemon
by Red Hat Bugzilla 29 Jun '15

29 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

[Bug 1123057] New: warning: file /usr/bin/gofmt: remove failed: No such file or directory while removing golang packages
by Red Hat Bugzilla 29 Jun '15

29 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1123057 Bug ID: 1123057 Summary: warning: file /usr/bin/gofmt: remove failed: No such file or directory while removing golang packages Product: Fedora Version: 20 Component: golang Assignee: vbatts(a)redhat.com Reporter: dominik(a)greysector.net QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lemenkov(a)gmail.com, lsm5(a)fedoraproject.org, renich(a)woralelandia.com, s(a)shk.io, vbatts(a)redhat.com Description of problem: There are two warnings while removing golang-pkg-bin-linux-amd64 package: warning: file /usr/bin/gofmt: remove failed: No such file or directory warning: file /usr/bin/go: remove failed: No such file or directory Version-Release number of selected component (if applicable): 1.2.2-7.fc20 How reproducible: Always Steps to Reproduce: 1. yum install golang 2. yum remove golang\* Actual Results: # yum remove golang\* Loaded plugins: changelog, langpacks Resolving Dependencies --> Running transaction check ---> Package golang.x86_64 0:1.2.2-7.fc20 will be erased ---> Package golang-pkg-bin-linux-amd64.x86_64 0:1.2.2-7.fc20 will be erased ---> Package golang-pkg-linux-amd64.noarch 0:1.2.2-7.fc20 will be erased ---> Package golang-src.noarch 0:1.2.2-7.fc20 will be erased --> Finished Dependency Resolution [...] Running transaction (shutdown inhibited) Erasing : golang-pkg-linux-amd64-1.2.2-7.fc20.noarch 1/4 Erasing : golang-pkg-bin-linux-amd64-1.2.2-7.fc20.x86_64 2/4 warning: file /usr/bin/gofmt: remove failed: No such file or directory warning: file /usr/bin/go: remove failed: No such file or directory Erasing : golang-1.2.2-7.fc20.x86_64 3/4 Erasing : golang-src-1.2.2-7.fc20.noarch 4/4 Verifying : golang-src-1.2.2-7.fc20.noarch 1/4 Verifying : golang-1.2.2-7.fc20.x86_64 2/4 Verifying : golang-pkg-bin-linux-amd64-1.2.2-7.fc20.x86_64 3/4 Verifying : golang-pkg-linux-amd64-1.2.2-7.fc20.noarch 4/4 Removed: golang.x86_64 0:1.2.2-7.fc20 golang-pkg-bin-linux-amd64.x86_64 0:1.2.2-7.fc20 golang-pkg-linux-amd64.noarch 0:1.2.2-7.fc20 golang-src.noarch 0:1.2.2-7.fc20 Expected Results: no warning about missing files Additional Information: It looks like the links maintained by update-alternatives are not marked as %ghost in the spec file: [...] ifarch x86_64 %files pkg-bin-linux-amd64 %{goroot}/bin/linux_amd64/ # binary executables %{_bindir}/go %{_bindir}/gofmt [...] This is required by the Alternatives guideline: https://fedoraproject.org/wiki/Packaging:Alternatives . -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[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 1010369] golang test suite fails on mssing zoneinfo.zip file
by Red Hat Bugzilla 29 Jun '15

29 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1010369 Fedora End Of Life <endoflife(a)fedoraproject.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution|--- |EOL Last Closed| |2015-06-29 08:25:15 --- Comment #2 from Fedora End Of Life <endoflife(a)fedoraproject.org> --- Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

Broken dependencies: docker-io
by Fedora Koji Build System 27 Jun '15

27 Jun '15

docker-io has broken dependencies in the epel-6 tree: On x86_64: docker-io-devel-1.6.2-1.el6.x86_64 requires /sbin/runscript Please resolve this as soon as possible.

1 0

[Bug 1230658] New: Tracker for golang-github-docker-libcontainer
by Red Hat Bugzilla 24 Jun '15

24 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1230658 Bug ID: 1230658 Summary: Tracker for golang-github-docker-libcontainer Product: Fedora Version: rawhide Component: golang-github-docker-libcontainer Severity: low Priority: low Assignee: lsm5(a)redhat.com Reporter: jchaloup(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: eparis(a)redhat.com, extras-qa(a)fedoraproject.org, golang(a)lists.fedoraproject.org, jchaloup(a)redhat.com, lsm5(a)redhat.com, vbatts(a)redhat.com Tracker for async updates of golang-github-docker-libcontainer for rawhide and other fedora distribution. As golang devel packages are used only as a build-time dependency at the moment, this tracker keeps updates and other information about this package, e.g. broken dependencies, exceptions, important pieces of information and other issues. -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 1232322] New: gofed review doesn't copy paches
by Red Hat Bugzilla 23 Jun '15

23 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1232322 Bug ID: 1232322 Summary: gofed review doesn't copy paches Product: Fedora Version: rawhide Component: gofed Assignee: jchaloup(a)redhat.com Reporter: mskalick(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: golang(a)lists.fedoraproject.org, jchaloup(a)redhat.com Description of problem: Gofed review command doesn't copy patches to rpmbuild SOURCES directory. Version-Release number of selected component (if applicable): ofed-0.0.4-1.fc23.x86_64 How reproducible: Steps to Reproduce: 1. Install gofed-0.0.4-1.fc23.x86_64 2. Do a review of golang-github-10gen-openssl package (srpm location: https://mskalick.fedorapeople.org/reviews/golang-github-10gen-openssl/golan…) 3. Actual results: Parsing golang-github-10gen-openssl.spec file Provides: github Repo: openssl Commit: 4c6dbafa5ec35b3ffc6a1b1e1fe29c3eba2053ec Name: golang-github-10gen-openssl Summary: OpenSSL bindings for Go (forked from github.com/spacemonkeygo/openssl) Copying tarball openssl-4c6dbaf.tar.gz to /home/mskalick/rpmbuild/SOURCES Building spec file using rpmbuild Build failed. Check build.log. Error: chyba: Špatný zdrojový soubor: /home/mskalick/rpmbuild/SOURCES/change-import-path-prefix.patch: Adresář nebo soubor neexistuje Expected results: ... Copying tarball openssl-4c6dbaf.tar.gz to /home/mskalick/rpmbuild/SOURCES Copying patch change-import-path-prefix.patch to /home/mskalick/rpmbuild/SOURCES Copying patch use-system-openssl.patch to /home/mskalick/rpmbuild/SOURCES ... Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1232336] New: gofed review failing with czech language
by Red Hat Bugzilla 23 Jun '15

23 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1232336 Bug ID: 1232336 Summary: gofed review failing with czech language Product: Fedora Version: rawhide Component: gofed Assignee: jchaloup(a)redhat.com Reporter: mskalick(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: golang(a)lists.fedoraproject.org, jchaloup(a)redhat.com Description of problem: With system language set to Czech, gofed review command is failing with this error. After changing system language setting to English, everything works fine. Version-Release number of selected component (if applicable): gofed-0.0.4-1.fc23.x86_64 How reproducible: Steps to Reproduce: 1. Do a review of golang-github-go-tomb-tomb (srpm: https://mskalick.fedorapeople.org/reviews/golang-github-go-tomb-tomb/golang…) 2. 3. Actual results: Parsing golang-github-go-tomb-tomb.spec file Provides: github Repo: tomb Commit: 14b3d72120e8d10ea6e6b7f87f7175734b1faab8 Name: golang-github-go-tomb-tomb Summary: Helps with clean goroutine termination in the Go language Copying tarball tomb-14b3d72.tar.gz to /home/mskalick/rpmbuild/SOURCES Building spec file using rpmbuild Traceback (most recent call last): File "/usr/share/gofed/prepareReview.py", line 102, in <module> srpm = filter(lambda l: l.endswith("src.rpm"), builds)[0] Expected results: rpmbuild may pass. Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1221688] New: Docker fails mounting a volume as readonly on files located under /usr
by Red Hat Bugzilla 23 Jun '15

23 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1221688 Bug ID: 1221688 Summary: Docker fails mounting a volume as readonly on files located under /usr Product: Red Hat Enterprise Linux 7 Version: 7.1 Component: docker Severity: high Priority: high Assignee: dwalsh(a)redhat.com Reporter: jhunsaker(a)redhat.com QA Contact: lsu(a)redhat.com CC: adimania(a)gmail.com, admiller(a)redhat.com, bugzilla.redhat.com(a)trancecode.co.uk, dustymabe(a)redhat.com, extras-qa(a)fedoraproject.org, golang(a)lists.fedoraproject.org, hushan.jia(a)gmail.com, ichavero(a)redhat.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, yann.robert(a)anantaplex.fr Depends On: 1216151 Group: redhat +++ This bug was initially created as a clone of Bug #1216151 +++ Description of problem: Docker fails to run a container with a volume on files located under /usr (or on symbolic link to files located under /usr) if the ":ro" specification is used to mount it as readonly Version-Release number of selected component (if applicable): docker-io-1.6.0-2.git3eac457.fc21.x86_64 How reproducible: 100% Steps to Reproduce: 1. install docker package docker-io-1.6.0-2.git3eac457.fc21.x86_64 2. restart the docker service 3. run the following command docker run -ti -v /etc/localtime:/etc/localtime:ro busybox echo hello Actual results: get exit code 1 and message FATA[0000] Error response from daemon: Cannot start container 4bb87515e4eb828b295eb4718a7159c958a1154ed839b29fd213a597b91a200e: [8] System error: Relabeling content in /usr is not allowed. Expected results: get exit code 0 and message "hello" Additional info: please refer to initial bug report on docker repository at github https://github.com/docker/docker/issues/12811 --- Additional comment from colin on 2015-05-12 17:48:40 EDT --- I see this also on F22 [root@kvm124 ~]# rpm -q docker docker-1.6.0-3.git9d26a07.fc22.x86_64 This no longer works docker run -d --sig-proxy --name $CT_name --net=none \ -v /etc/localtime:/etc/localtime:ro \ Editing out the :ro stops the Failure docker run -d --sig-proxy --name $CT_name --net=none \ -v /etc/localtime:/etc/localtime \ FATA[0000] Error response from daemon: Cannot start container 925387bd2b2988b1a10ff87e68e188f3a579e68d3d5fc1f31d40a648cd9cb6d2: [8] System error: Relabeling content in /usr is not allowed. ------------------------------------------- Cloning this to RHEL as I didn't see a RHEL BZ for this. This also affects RHEL Atomic Host 7.1.2. Version: docker-1.6.0-11.el7.x86_64 How reproducible: 100% Steps to reproduce: 1. Use the :ro parameter when volume mounting something like /etc/localtime to a container Actual results: # docker run --rm -ti -v /etc/localtime:/etc/localtime:ro rhel7 /bin/bash Timestamp: 2015-05-14 09:24:34.832162133 -0400 EDT Code: System error Message: Relabeling content in /usr is not allowed. Frames: --- 0: setupRootfs Package: github.com/docker/libcontainer File: rootfs_linux.go@34 --- 1: Init Package: github.com/docker/libcontainer.(*linuxStandardInit) File: standard_init_linux.go@52 --- 2: StartInitialization Package: github.com/docker/libcontainer.(*LinuxFactory) File: factory_linux.go@223 --- 3: initializer Package: FATA[0002] Error response from daemon: Cannot start container 7be2ae04a120232345b5edbf18e487965b5418bb1ee9354e406d7b9f675c6091: [8] System error: Relabeling content in /usr is not allowed. Excepted results: Container should start normally Additional notes: As mentioned in the Fedora bug, removing the :ro will allow the container to start, however this is not desirable for things like /etc/localtime as we don't want the container to be able to change that. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1216151 [Bug 1216151] Docker fails mounting a volume as readonly on files located under /usr -- You are receiving this mail because: You are on the CC list for the bug.

1 7

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang June 2015