golang March 2015

golang@lists.fedoraproject.org

8 participants
437 discussions

[Bug 1204620] New: container stays around wihtout any processes in it
by Red Hat Bugzilla 17 Feb '16

17 Feb '16

https://bugzilla.redhat.com/show_bug.cgi?id=1204620 Bug ID: 1204620 Summary: container stays around wihtout any processes in it Product: Fedora Version: 22 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: mvollmer(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: adimania(a)gmail.com, admiller(a)redhat.com, golang(a)lists.fedoraproject.org, hushan.jia(a)gmail.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 Created attachment 1005245 --> https://bugzilla.redhat.com/attachment.cgi?id=1005245&action=edit Setup script for reproducing Description of problem: When running a specific custom image (see attachement), docker fails to notice when the single process exits. The container stays around, and attempts to stop or remove it result in errors. Doing the same with a slightly older version of docker shows expected behavior. Version-Release number of selected component (if applicable): docker-io-1.5.0-19.git5d7adce.fc22.x86_64 How reproducible: Always. Steps to Reproduce: 1. Run the attached SETUP script in an empty directory 2. Run the resulting image # docker run --name=probe cp /bin/container-probe 3. After wrestling control back from the hanging "docker run", try to stop or remove the container. # docker stop probe # docker rm -f probe Actual results: The expected output of container-probe is shown, but "docker run ..." does not return to the command line prompt. In fact, job control doesn't work anymore either (C-c, C-z, C-\). Stopping and removing leads to these errors: # docker stop probe Error response from daemon: Cannot stop container probe: active container for c492b7203b3d465c778935f97a12b3bf8a4c442731c7fd25cee6f50798ac4f65 does not exist FATA[0000] Error: failed to stop one or more containers # docker rm -f probe Error response from daemon: Could not kill running container, cannot remove - active container for c492b7203b3d465c778935f97a12b3bf8a4c442731c7fd25cee6f50798ac4f65 does not exist FATA[0000] Error: failed to remove one or more containers Expected results: The output is shown and "docker run" terminates successfully, the container is show as "exited" and can be removed. Additional info: docker-io-1.5.0-1.fc21.x86_64 shows the expected behavior. "docker run -i" return control to the shell, but the resulting container can't be stopped or removed either. "systemctl restart docker" puts the "probe" container into a state where it can be removed. -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1145659] New: [PATCH] Support /etc/sysconfig/docker-storage
by Red Hat Bugzilla 07 Jan '16

07 Jan '16

https://bugzilla.redhat.com/show_bug.cgi?id=1145659 Bug ID: 1145659 Summary: [PATCH] Support /etc/sysconfig/docker-storage Product: Fedora Version: rawhide Component: docker-io Assignee: lsm5(a)fedoraproject.org Reporter: walters(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, dwalsh(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, thrcka(a)redhat.com, vbatts(a)redhat.com, virt-bugs(a)redhat.com Depends On: 1144206 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1144206 [Bug 1144206] [PATCH] Support /etc/sysconfig/docker-storage -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[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 1174354] New: Missing Requires: cadvisor
by Red Hat Bugzilla 02 Dec '15

02 Dec '15

https://bugzilla.redhat.com/show_bug.cgi?id=1174354 Bug ID: 1174354 Summary: Missing Requires: cadvisor Product: Fedora Version: 21 Component: kubernetes Assignee: jchaloup(a)redhat.com Reporter: tstclair(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: eparis(a)redhat.com, golang(a)lists.fedoraproject.org, jchaloup(a)redhat.com, lsm5(a)redhat.com, nhorman(a)redhat.com, vbatts(a)redhat.com Description of problem: k8's has a missing run-time dependency on cadvisor that is not installed when k8's is installed. Version-Release number of selected component (if applicable): 0.6-4.0.git993ef88.fc21 How reproducible: 100% Steps to Reproduce: 1. yum install kubernetes 2. check installation list Actual results: no cadvisor Expected results: install cadvisor -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1135152] New: user: Current not implemented on linux/amd64
by Red Hat Bugzilla 01 Dec '15

01 Dec '15

https://bugzilla.redhat.com/show_bug.cgi?id=1135152 Bug ID: 1135152 Summary: user: Current not implemented on linux/amd64 Product: Fedora Version: 20 Component: golang Assignee: vbatts(a)redhat.com Reporter: adam(a)spicenitz.org 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: golang seems to be using some cross-compiled components which are causing problems. Specifically, Fedora has exactly the problem described here: http://stackoverflow.com/questions/20609415/cross-compiling-user-current-no… Here is the sample code from that page: package main import ( "fmt" "os/user" ) func main() { fmt.Println(user.Current()) } You can build the sample code and see the problem directly: $ go build ./current.go $ ./current <nil> user: Current not implemented on linux/amd64 Version-Release number of selected component (if applicable): golang-1.2.2-22.fc20.x86_64 How reproducible: Always -- You are receiving this mail because: You are on the CC list for the bug.

1 18

[Bug 1206751] New: Docker with overlay cannot run bash(prevented by SELinx)
by Red Hat Bugzilla 06 Nov '15

06 Nov '15

https://bugzilla.redhat.com/show_bug.cgi?id=1206751 Bug ID: 1206751 Summary: Docker with overlay cannot run bash(prevented by SELinx) Product: Fedora Version: 21 Component: docker-io Severity: high Assignee: ichavero(a)redhat.com Reporter: robberphex(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: adimania(a)gmail.com, admiller(a)redhat.com, 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 Description of problem: the container cannot read .so file in overlay, and cannot relabel the file system. How reproducible: Steps to Reproduce: 1. Add "DOCKER_STORAGE_OPTIONS= --storage-driver=overlay" to /etc/sysconfig/docker-storage, and restart docker service. 2. repull the image(in my case, pull debian:jessie) 3. Run container(sudo docker run -it debian:jessie /bin/bash) Actual results: /bin/bash: error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory (preventing by SELinx) Expected results: bash prompt in container Additional info: There is 4 SeLinux Alert: ----1---- SELinux is preventing docker from mount access on the filesystem /. ***** Plugin file (47.5 confidence) suggests ****************************** If you think this is caused by a badly mislabeled machine. Then you need to fully relabel. Do touch /.autorelabel; reboot ***** Plugin file (47.5 confidence) suggests ****************************** If you think this is caused by a badly mislabeled machine. Then you need to fully relabel. Do touch /.autorelabel; reboot ***** Plugin catchall (6.38 confidence) suggests ************************** If you believe that docker should be allowed mount access on the filesystem by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep docker /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:docker_t:s0 Target Context system_u:object_r:unlabeled_t:s0 Target Objects / [ filesystem ] Source docker Source Path docker Port <Unknown> Host rp.fedora Source RPM Packages Target RPM Packages filesystem-3.2-28.fc21.x86_64 Policy RPM selinux-policy-3.13.1-105.6.fc21.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name rp.fedora Platform Linux rp.fedora 3.19.1-201.fc21.x86_64 #1 SMP Wed Mar 18 04:29:24 UTC 2015 x86_64 x86_64 Alert Count 1 First Seen 2015-03-28 09:08:17 CST Last Seen 2015-03-28 09:08:17 CST Local ID fcd44130-63b9-4680-9975-4dc6a416b566 Raw Audit Messages type=AVC msg=audit(1427504897.987:739): avc: denied { mount } for pid=1337 comm="docker" name="/" dev="overlay" ino=65132 scontext=system_u:system_r:docker_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem permissive=1 Hash: docker,docker_t,unlabeled_t,filesystem,mount ----2---- SELinux is preventing docker from unmount access on the filesystem . ***** Plugin file (47.5 confidence) suggests ****************************** If you think this is caused by a badly mislabeled machine. Then you need to fully relabel. Do touch /.autorelabel; reboot ***** Plugin file (47.5 confidence) suggests ****************************** If you think this is caused by a badly mislabeled machine. Then you need to fully relabel. Do touch /.autorelabel; reboot ***** Plugin catchall (6.38 confidence) suggests ************************** If you believe that docker should be allowed unmount access on the filesystem by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep docker /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:docker_t:s0 Target Context system_u:object_r:unlabeled_t:s0 Target Objects [ filesystem ] Source docker Source Path docker Port <Unknown> Host rp.fedora Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-105.6.fc21.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name rp.fedora Platform Linux rp.fedora 3.19.1-201.fc21.x86_64 #1 SMP Wed Mar 18 04:29:24 UTC 2015 x86_64 x86_64 Alert Count 1 First Seen 2015-03-28 09:08:17 CST Last Seen 2015-03-28 09:08:17 CST Local ID c4a57cd0-ae92-4521-ad81-40a5e30a5627 Raw Audit Messages type=AVC msg=audit(1427504897.990:740): avc: denied { unmount } for pid=1337 comm="docker" scontext=system_u:system_r:docker_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem permissive=1 Hash: docker,docker_t,unlabeled_t,filesystem,unmount ----3---- SELinux is preventing docker from relabelfrom access on the filesystem . ***** Plugin file (47.5 confidence) suggests ****************************** If you think this is caused by a badly mislabeled machine. Then you need to fully relabel. Do touch /.autorelabel; reboot ***** Plugin file (47.5 confidence) suggests ****************************** If you think this is caused by a badly mislabeled machine. Then you need to fully relabel. Do touch /.autorelabel; reboot ***** Plugin catchall (6.38 confidence) suggests ************************** If you believe that docker should be allowed relabelfrom access on the filesystem by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep docker /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:docker_t:s0 Target Context system_u:object_r:unlabeled_t:s0 Target Objects [ filesystem ] Source docker Source Path docker Port <Unknown> Host rp.fedora Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-105.6.fc21.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name rp.fedora Platform Linux rp.fedora 3.19.1-201.fc21.x86_64 #1 SMP Wed Mar 18 04:29:24 UTC 2015 x86_64 x86_64 Alert Count 1 First Seen 2015-03-28 09:08:17 CST Last Seen 2015-03-28 09:08:17 CST Local ID ad86497a-be89-4611-8686-7aa67e73f523 Raw Audit Messages type=AVC msg=audit(1427504897.998:741): avc: denied { relabelfrom } for pid=1337 comm="docker" scontext=system_u:system_r:docker_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem permissive=1 Hash: docker,docker_t,unlabeled_t,filesystem,relabelfrom ----4---- SELinux is preventing bash from read access on the file /var/lib/docker/overlay/1cbc0c1b2084b5f3c8fdc283032c124f6fb461242cc5b82fb183095a414869b9/root/lib/x86_64-linux-gnu/libncurses.so.5.9. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that bash should be allowed read access on the libncurses.so.5.9 file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep bash /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:svirt_lxc_net_t:s0:c156,c1000 Target Context system_u:object_r:docker_var_lib_t:s0 Target Objects /var/lib/docker/overlay/1cbc0c1b2084b5f3c8fdc28303 2c124f6fb461242cc5b82fb183095a414869b9/root/lib/x8 6_64-linux-gnu/libncurses.so.5.9 [ file ] Source bash Source Path bash Port <Unknown> Host rp.fedora Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-105.6.fc21.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name rp.fedora Platform Linux rp.fedora 3.19.1-201.fc21.x86_64 #1 SMP Wed Mar 18 04:29:24 UTC 2015 x86_64 x86_64 Alert Count 1 First Seen 2015-03-28 09:08:18 CST Last Seen 2015-03-28 09:08:18 CST Local ID 2a5fbf0f-dc4e-489b-a9ca-2541bb55209e Raw Audit Messages type=AVC msg=audit(1427504898.269:754): avc: denied { read } for pid=10156 comm="bash" name="libncurses.so.5.9" dev="dm-0" ino=2100260 scontext=system_u:system_r:svirt_lxc_net_t:s0:c156,c1000 tcontext=system_u:object_r:docker_var_lib_t:s0 tclass=file permissive=0 Hash: bash,svirt_lxc_net_t,docker_var_lib_t,file,read ----end---- -- You are receiving this mail because: You are on the CC list for the bug.

1 25

[Bug 1195525] New: Docker socket permissions prevent Cockpit integration
by Red Hat Bugzilla 14 Oct '15

14 Oct '15

https://bugzilla.redhat.com/show_bug.cgi?id=1195525 Bug ID: 1195525 Summary: Docker socket permissions prevent Cockpit integration Product: Fedora Version: 21 Component: docker-io Severity: medium Assignee: lsm5(a)redhat.com Reporter: Benjamin(a)BGRoberts.id.au QA Contact: extras-qa(a)fedoraproject.org CC: adimania(a)gmail.com, admiller(a)redhat.com, golang(a)lists.fedoraproject.org, hushan.jia(a)gmail.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 Description of problem: The removal of docker.socket and the docker user/group mean that docker cannot be used as part of the cockpit console anymore (using non-root accounts). This is because, although users can be added to the dockerroot group, the permissions of the sockets are reset upon docker restart. Version-Release number of selected component (if applicable): docker-io-1.5.0-1.fc21.x86_64 cockpit-0.27-3.fc21.x86_64 / cockpit-head Steps to Reproduce: 1. Add user to dockerroot 2. chown docker socket to root:dockerroot 3. Call a docker command from user (succeeds from CLI and cockpit) 4. restart docker 5. Call a docker command from user (fails from CLI and cockpit) Actual results: Ownership of docker socket are reset to root:root Expected results: Ownership of docker socket should be configurable and compatible with cockpit Additional info: related to https://bugzilla.redhat.com/show_bug.cgi?id=1192848 Relevant change in the rpm spec: "* Fri Jan 16 2015 Lokesh Mandvekar <lsm5(a)fedoraproject.org> - 1.4.1-7 - docker group no longer used or created - no socket activation - config file updates to include info about docker_transition_unconfined boolean" -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 1166611] New: Extend golang %files section with golang.org/x directory ownership
by Red Hat Bugzilla 01 Oct '15

01 Oct '15

https://bugzilla.redhat.com/show_bug.cgi?id=1166611 Bug ID: 1166611 Summary: Extend golang %files section with golang.org/x directory ownership Product: Fedora Version: rawhide Component: golang Assignee: vbatts(a)redhat.com Reporter: jchaloup(a)redhat.com 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: https://groups.google.com/forum/#!topic/golang-nuts/eD8dh3T9yyA First post: ... This list shows the current base import paths, and their new equivalents. code.google.com/p/go.benchmarks -> golang.org/x/benchmarks code.google.com/p/go.blog -> golang.org/x/blog code.google.com/p/go.crypto -> golang.org/x/crypto code.google.com/p/go.exp -> golang.org/x/exp code.google.com/p/go.image -> golang.org/x/image code.google.com/p/go.mobile -> golang.org/x/mobile code.google.com/p/go.net -> golang.org/x/net code.google.com/p/go.sys -> golang.org/x/sys code.google.com/p/go.talks -> golang.org/x/talks code.google.com/p/go.text -> golang.org/x/text code.google.com/p/go.tools -> golang.org/x/tools ... import paths are being extended for new equivalents starting with "golang.org/x/..." Version-Release number of selected component (if applicable): golang-1.3.99-2.1.4rc1.fc22 How reproducible: Always Steps to Reproduce: 1. rpm -q --provides golang | grep golang.org Actual results: Empty result Expected results: /usr/share/gocode/src/golang.org /usr/share/gocode/src/golang.org/x Additional info: Extend ownership for all branches (at least el6, f20,f21,master) -- You are receiving this mail because: You are on the CC list for the bug.

1 21

[Bug 1187077] New: Fedora:latest docker image yum won't update
by Red Hat Bugzilla 16 Sep '15

16 Sep '15

https://bugzilla.redhat.com/show_bug.cgi?id=1187077 Bug ID: 1187077 Summary: Fedora:latest docker image yum won't update Product: Fedora Version: 21 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: cyborg101010(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: adimania(a)gmail.com, admiller(a)redhat.com, golang(a)lists.fedoraproject.org, hushan.jia(a)gmail.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 Description of problem: I cannot install from or update yum inside Docker. RUN yum install make automake gcc gcc-c++ kernel-devel tar wget ---> Running in 04cdfe47b7ac One of the configured repositories failed (Fedora 21 - x86_64), and yum doesn't have enough cached data to continue. At this point the only safe thing yum can do is fail. There are a few ways to work "fix" this: 1. Contact the upstream for the repository and get them to fix the problem. 2. Reconfigure the baseurl/etc. for the repository, to point to a working upstream. This is most often useful if you are using a newer distribution release than is supported by the repository (and the packages for the previous distribution release still work). 3. Disable the repository, so yum won't use it by default. Yum will then just ignore the repository until you permanently enable it again or use --enablerepo for temporary usage: yum-config-manager --disable fedora 4. Configure the failing repository to be skipped, if it is unavailable. Note that yum will try to contact the repo. when it runs most commands, so will have to try and fail each time (and thus. yum will be be much slower). If it is a very temporary problem though, this is often a nice compromise: yum-config-manager --save --setopt=fedora.skip_if_unavailable=true Cannot retrieve metalink for repository: fedora/21/x86_64. Please verify its path and try again Version-Release number of selected component (if applicable): Docker 1.4.1 Fedora:latest How reproducible: Seems rare, but I can find others with the issue (e.g. https://registry.hub.docker.com/_/fedora/ see comment from crackcomm) Steps to Reproduce: 1. Take any examples https://github.com/fedora-cloud/Fedora-Dockerfiles 2. docker build an example 3. Wait for yum update / install Actual results: Yum errors and exits. Expected results: Yum update / install -- You are receiving this mail because: You are on the CC list for the bug.

1 9

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang March 2015