golang April 2014

golang@lists.fedoraproject.org

7 participants
400 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 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 1090071] New: `docker start` doesn't fail on started container
by Red Hat Bugzilla 29 Jun '15

29 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 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 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 1033606] New: Failed to connect to network from Docker container
by Red Hat Bugzilla 17 Jun '15

17 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1033606 Bug ID: 1033606 Summary: Failed to connect to network from 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: Connecting to external network from Docker container fail due to firewalld. I guess you must have masquerade enabled, however this is not mentioned anywhere. I think docker-io should set the firewalld rules automatically, or tell users that they need to enable masquarade in firewalld. 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. $ yum install docker-io 2. $ systemctl enable docker.service 3. $ systemctl start docker.service 4. $ docker pull mattdm/fedora 5. $ docker run -i -t mattdm/fedora:latest /bin/bash 6. $ ping google.com ping: unknown host google.com When I stop firewalld on host (systemctl stop firewalld) and then restart the docker (systemctl restart docker), the ping works like a charm. Actual results: Unable to connect outside the Docker container with firewalld enabled. Expected results: Docker should configure firewalld automatically (during install?), or inform users to do so manually. Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 68

[Bug 1088259] New: "docker top all" doesn't show processes when --tty=false
by Red Hat Bugzilla 02 Jun '15

02 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1088259 Bug ID: 1088259 Summary: "docker top all" doesn't show processes when --tty=false 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, when I run docker with --tty=false, the `docker top $NAME all` doesn't show any processes (just headers). When using only `docker top $NAME` it shows them... Also the `ps` command inside container works, but `ps all` does not. Version-Release number of selected component (if applicable): docker-io-0.9.0-3.fc20.x86_64 How reproducible: always Steps to Reproduce: 1. docker run -i --tty=false fedora bash 2. docker logs $NAME Actual results: F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND Expected results: F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 1 0 24006 23954 20 0 11732 540 - R pts/14 0:00 bash -- You are receiving this mail because: You are on the CC list for the bug.

1 29

[Bug 1087700] New: lost signals when sending lots of signals using --sig-proxy to docker
by Red Hat Bugzilla 29 May '15

29 May '15

https://bugzilla.redhat.com/show_bug.cgi?id=1087700 Bug ID: 1087700 Summary: lost signals when sending lots of signals using --sig-proxy to docker 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 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-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.. -- You are receiving this mail because: You are on the CC list for the bug.

1 15

[Bug 1093000] New: Unable to save an image to a tar archive
by Red Hat Bugzilla 29 May '15

29 May '15

https://bugzilla.redhat.com/show_bug.cgi?id=1093000 Bug ID: 1093000 Summary: Unable to save an image to a tar archive Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: lslebodn(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: I tried to dump content of docker image to a tarball with command "docker save" It failed with error message "no space left on device" Version-Release number of selected component (if applicable): I was able to reproduce problem with docker-io from stable repository and with docker-io from updates-testing [root@vm-169 docker]# rpm -q docker-io docker-io-0.9.1-1.fc20.x86_64 or docker-io-0.10.0-2.fc20.x86_64 How reproducible: Allways Steps to Reproduce: 1. Create big docker image (e.g. 1.8 GiB) [root@vm-169 docker-freeipa]# docker images REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE big_image latest b366efe500de 57 minutes ago 1.778 GB fedora 20 b7de3133ff98 5 days ago 372.7 MB 2. save docker image to tarball [root@vm-169 docker]# docker save big_image > big_image.tar Actual results: [root@vm-169 docker]# docker save big_image > big_image.tar 2014/04/30 12:39:38 Error: write /docker-export-085323451/934d868afd0a79629df2cad704cbc1ed9344654625569263a630933d2785de57/layer.tar: no space left on device [root@vm-169 docker]# file big_image.tar big_image.tar: empty [root@vm-169 docker]# ls -l big_image.tar -rw-r--r--. 1 root root 0 Apr 30 13:41 big_image.tar Expected results: File big_image.tar should not be empty and should contain data from docker image with name big_image Additional info: Directory /tmp should be used for creating small temporary files, because it is mounted on tmpfs. I think it would be better to use /var/tmp in this case. -- You are receiving this mail because: You are on the CC list for the bug.

1 10

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang April 2014