golang March 2015

golang@lists.fedoraproject.org

8 participants
437 discussions

[Bug 1038683] New: golang appears to contain an ECC implementation
by Red Hat Bugzilla 17 Jun '16

17 Jun '16

https://bugzilla.redhat.com/show_bug.cgi?id=1038683 Bug ID: 1038683 Summary: golang appears to contain an ECC implementation Product: Fedora Version: 20 Component: golang Assignee: adam(a)spicenitz.org Reporter: notting(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, skottler(a)redhat.com, vbatts(a)redhat.com Blocks: 182235 (FE-Legal), 1019390 (ecc) Description of problem: At least, I would assume that's what is in go/src/pkg/crypto/elliptic/. In Fedora, we only ship certain reviewed curves. Version-Release number of selected component (if applicable): 1.2-1 How reproducible: 100% Steps to Reproduce: 1. look at golang's crypto code Actual results: Hey, that looks like ECC, and it appears to have been always included. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=182235 [Bug 182235] Fedora Legal Tracker https://bugzilla.redhat.com/show_bug.cgi?id=1019390 [Bug 1019390] [tracking bug] re-enable ECC/ECDHE/EC/ECDSA/elliptic curves in Fedora -- You are receiving this mail because: You are on the CC list for the bug.

1 19

[Bug 1046469] New: docker privileged mode with cmd /sbin/init - agetty & high cpu
by Red Hat Bugzilla 08 Jun '16

08 Jun '16

https://bugzilla.redhat.com/show_bug.cgi?id=1046469 Bug ID: 1046469 Summary: docker privileged mode with cmd /sbin/init - agetty & high cpu Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: fortuik(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: docker containers in privileged mode mess with the host agetty and produce very hicht cpu load Version-Release number of selected component (if applicable): Fedora 20 Docker 0.7.1, 0.7.2 How reproducible: docker run -privileged -d mattdm/fedora:latest /sbin/init Actual results: docker container runs cpu load is very high - agetty stopping the container & the docker daemon do not free the cpu resources one have to kill the agetty process Expected results: docker container runs Additional info: In my real case i run rhel containers with puppet & ssh daemons for a small puppet lab. The reason i met this bug is that running docker container with /sbin/init cmd under RHEL 6.5 require priviliged mode. -- You are receiving this mail because: You are on the CC list for the bug.

1 14

[Bug 1192081] New: Modify base image Dockerfile to enable systemd to run smoothly
by Red Hat Bugzilla 08 Jun '16

08 Jun '16

https://bugzilla.redhat.com/show_bug.cgi?id=1192081 Bug ID: 1192081 Summary: Modify base image Dockerfile to enable systemd to run smoothly Product: Fedora Version: rawhide Component: docker-io Assignee: lsm5(a)redhat.com Reporter: vpavlin(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 Description of problem: systemd requires container=docker set in env and /run, /tmp to be mountpoints start successfully. In my opinion, we should add ENV container=docker VOLUME ['/run', '/tmp'] to the base image Dockerfile. Command docker run --it --rm -v /sys/fs/cgroup:/sys/fs/cgroup:ro fedora:rawhide /usr/sbin/init would then be all an user would need to "boot" systemd in a container. I've already made some changes in KS file - remove fstab and machine-id, mask mount units... which make the boot sequence smooth. More changes to boot sequence will probably come later (f.e. switch from graphical.target to multi-user target) I'd also like to suggest new Rawhide build to be pushed to registry. This one works for me quite well: http://koji.fedoraproject.org/koji/taskinfo?taskID=8883309 -- You are receiving this mail because: You are on the CC list for the bug.

1 16

[Bug 1192848] New: docker no longer supports socket-activation
by Red Hat Bugzilla 03 Jun '16

03 Jun '16

https://bugzilla.redhat.com/show_bug.cgi?id=1192848 Bug ID: 1192848 Summary: docker no longer supports socket-activation Product: Fedora Version: 21 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: tim(a)gfxmonk.net 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 Version-Release number of selected component (if applicable): docker-io-1.4.1-8.fc21.x86_64 How reproducible: Always Steps to Reproduce: $ docker ps Actual results: FATA[0000] Cannot connect to the Docker daemon. Is 'docker -d' running on this host? Expected results: /var/run/docker.sock should automatically start `docker.service` via socket activation. This was the case on fedora 20. Additional info: I looked in the package history, and it looks like it was disabled by: commit aecb9bfe55824e2c9c7be4afce3ac8dd7e3395f5 Author: Lokesh Mandvekar <lsm5(a)fedoraproject.org> Date: Fri Jan 16 17:06:40 2015 +0000 docker group and socket activation not used NVR: docker-io-1.4.1-7 - sysconfig file updates Signed-off-by: Lokesh Mandvekar <lsm5(a)fedoraproject.org> I assume there's a reason for this, but there's no bugzilla or other issue reference, and no description of why the functionality should be removed. The removal of socket activation is pretty annoying, so it would be great if it could be re-enabled. If it can't be enabled, it would be good to document why. -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 1091538] New: golang crashing on ARMv7
by Red Hat Bugzilla 09 May '16

09 May '16

https://bugzilla.redhat.com/show_bug.cgi?id=1091538 Bug ID: 1091538 Summary: golang crashing on ARMv7 Product: Fedora Version: rawhide Component: golang Assignee: adam(a)spicenitz.org Reporter: pbrobinson(a)gmail.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, s(a)shk.io, vbatts(a)redhat.com Blocks: 245418 (ARMTracker) We're getting an crash with go when I try and enable go support for ARM in the swig package. http://koji.fedoraproject.org/koji/taskinfo?taskID=6780663 It's currently just a scratch build as I obviously can't push it if it fails. checking Examples/go/callback checking Examples/go/class unexpected fault address 0x40440000 fatal error: fault [signal 0xb code=0x1 addr=0x40440000 pc=0x40440000] goroutine 1 [running]: runtime.throw(0x15691f) /usr/lib/golang/src/pkg/runtime/panic.c:464 +0x5c fp=0xb6ba5f7c runtime: unexpected return pc for runtime.sigpanic called from 0x40440000 runtime.sigpanic() /usr/lib/golang/src/pkg/runtime/os_linux.c:237 +0xa8 fp=0xb6ba5f88 goroutine 3 [syscall]: runtime.goexit() /usr/lib/golang/src/pkg/runtime/proc.c:1394 checking Examples/go/constants make[3]: *** [go_run] Error 2 make[2]: *** [check] Error 2 make[1]: *** [class.actionexample] Error 2 checking Examples/go/enum checking Examples/go/extend checking Examples/go/funcptr checking Examples/go/multimap checking Examples/go/pointer checking Examples/go/reference checking Examples/go/simple checking Examples/go/template checking Examples/go/variables Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=245418 [Bug 245418] Tracker for ARM support -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Bug 1200612] New: Package rocksdb binary for Fedora
by Red Hat Bugzilla 03 May '16

03 May '16

https://bugzilla.redhat.com/show_bug.cgi?id=1200612 Bug ID: 1200612 Summary: Package rocksdb binary for Fedora Product: Fedora Version: rawhide Component: golang-github-influxdb-rocksdb Assignee: jchaloup(a)redhat.com Reporter: ggillies(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: golang(a)lists.fedoraproject.org, jchaloup(a)redhat.com, lsm5(a)redhat.com Hi, With influxdb version 0.9 moving to completely utilise rocksdb, we probably want to look at expanding this package to fully provide a rocksdb compiled binary. That is, a rocksdb package that has /usr/bin/rocksdb, as well as the devel package with the raw go code for deps (which this package currently provides) Regards, Graeme -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 1100000] New: can't run iscsid in a docker container
by Red Hat Bugzilla 11 Apr '16

11 Apr '16

https://bugzilla.redhat.com/show_bug.cgi?id=1100000 Bug ID: 1100000 Summary: can't run iscsid in a docker container Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: jslagle(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 Created attachment 898086 --> https://bugzilla.redhat.com/attachment.cgi?id=898086&action=edit iscsid strace showing failure Description of problem: Can't start iscsid in a docker container Version-Release number of selected component (if applicable): # rpm -q docker-io docker-io-0.11.1-3.fc20.x86_64 How reproducible: always Steps to Reproduce: 1. use the published fedora image, docker pull fedora 2. start the container, docker run -t -i fedora /bin/bash 3. install iscsi-initiator-utils 4. try to start iscsid: bash-4.2# iscsid -f iscsid: can not bind NETLINK_ISCSI socket strace also attached -- You are receiving this mail because: You are on the CC list for the bug.

1 24

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

05 Apr '16

https://bugzilla.redhat.com/show_bug.cgi?id=1096273 Bug ID: 1096273 Summary: repetition of signal 21 with --sig-proxy and SIGSTOP of docker Product: Red Hat Enterprise Linux 7 Version: 7.1 Component: docker Severity: low 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: 1087704 +++ This bug was initially created as a clone of Bug #1087704 +++ 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-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. 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... --- Additional comment from Lukas Doktor on 2014-05-05 03:59:30 EDT --- I retested this with the upstream dc9c28f/0.10.0 with the same results. The daemon output is: ... [/home/medic/Work/Projekty/Docker/root|fa3816b6] -job kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, TTIN) = OK (0) 2014/05/05 09:58:13 POST /v1.10/containers/b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5/kill?signal=TTIN [/home/medic/Work/Projekty/Docker/root|fa3816b6] +job kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, TTIN) [/home/medic/Work/Projekty/Docker/root|fa3816b6] -job kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, TTIN) = OK (0) 2014/05/05 09:58:13 POST /v1.10/containers/b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5/kill?signal=TTIN [/home/medic/Work/Projekty/Docker/root|fa3816b6] +job kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, TTIN) [/home/medic/Work/Projekty/Docker/root|fa3816b6] -job kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, TTIN) = OK (0) 2014/05/05 09:58:13 POST /v1.10/containers/b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5/kill?signal=TTIN [/home/medic/Work/Projekty/Docker/root|fa3816b6] +job kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, TTIN) ... Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1087704 [Bug 1087704] repetition of signal 21 with --sig-proxy and SIGSTOP of docker -- You are receiving this mail because: You are on the CC list for the bug.

1 25

[Bug 1202517] New: docker fd leak
by Red Hat Bugzilla 02 Apr '16

02 Apr '16

https://bugzilla.redhat.com/show_bug.cgi?id=1202517 Bug ID: 1202517 Summary: docker fd leak Product: Red Hat Enterprise Linux 7 Version: 7.2 Component: docker Assignee: dwalsh(a)redhat.com Reporter: dwalsh(a)redhat.com QA Contact: virt-bugs(a)redhat.com CC: adimania(a)gmail.com, admiller(a)redhat.com, arozansk(a)redhat.com, b(a)wtnb.mydns.jp, dwalsh(a)redhat.com, extras-qa(a)fedoraproject.org, golang(a)lists.fedoraproject.org, hushan.jia(a)gmail.com, jchaloup(a)redhat.com, jeder(a)redhat.com, jmario(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, srao(a)redhat.com, thrcka(a)redhat.com, tstclair(a)redhat.com, vbatts(a)redhat.com, vgoyal(a)redhat.com Depends On: 1189028 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1189028 [Bug 1189028] docker fd leak -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1189028] New: docker 1.4.1-3.el6 fd leak
by Red Hat Bugzilla 02 Apr '16

02 Apr '16

https://bugzilla.redhat.com/show_bug.cgi?id=1189028 Bug ID: 1189028 Summary: docker 1.4.1-3.el6 fd leak Product: Fedora EPEL Version: el6 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: b(a)wtnb.mydns.jp 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: docker daemon doesn't close file descriptor. Version-Release number of selected component (if applicable): docker-io-1.4.1-3.el6.x86_64 How reproducible: Steps to Reproduce: 1. while true; do docker run -t -i --rm busybox /bin/true ; done 2. (in other terminal) DEBUG=1 docker info 3. check values at Fds: and Goroutines: lines Actual results: Fds and Goroutines values are increased forever Expected results: Additional info: - It doesn't happen on RHEL7 + docker 1.4.1 - It doesn't happen on RHEL6 + docker-io-1.3.2-2.el6.x86_64 # lsof -p $(pidof docker) <snip> docker 7771 root 14u REG 0,9 0 3791 [eventfd] docker 7771 root 15u REG 0,9 0 3791 [eventfd] docker 7771 root 16r REG 0,21 0 20709 /cgroup/memory/docker/98b529e398bec4568c58ea96088aef1535eca504bed6453bab8f6f7803d31cfb/memory.oom_control (deleted) docker 7771 root 17u REG 0,9 0 3791 [eventfd] docker 7771 root 18r REG 0,21 0 21176 /cgroup/memory/docker/bc213d3e80815021780064874665fe80801c5a1010d1c0bc4bd5b118ca45d11f/memory.oom_control (deleted) docker 7771 root 19u REG 0,9 0 3791 [eventfd] docker 7771 root 20r REG 0,21 0 21626 /cgroup/memory/docker/7b8d59ec4f23c14e2732726594460ccf89fe31c06e60fabbdc4e358f794af102/memory.oom_control (deleted) docker 7771 root 21w REG 0,9 0 3791 [eventfd] docker 7771 root 22r REG 0,21 0 22112 /cgroup/memory/docker/99ac44fcb18a3e1aea00a5e7cfb040942f2c4f2c673c291105c367788e49d0f2/memory.oom_control (deleted) docker 7771 root 24r REG 0,21 0 22672 /cgroup/memory/docker/b1804ae48289df81d3a5c54167baf729612e12c552ef98917df90d8645d235ad/memory.oom_control (deleted) <snip> # ps $(pidof docker) m PID TTY STAT TIME COMMAND 7771 pts/0 - 0:09 /usr/bin/docker -d - - Sl 0:02 - - - Sl 0:00 - - - Sl 0:00 - - - Sl 0:00 - - - Sl 0:00 - - - Sl 0:00 - - - Sl 0:00 - - - Sl 0:01 - - - Sl 0:00 - <snip> -- You are receiving this mail because: You are on the CC list for the bug.

1 18

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang March 2015