[Bug 1038683] New: golang appears to contain an ECC implementation
by Red Hat Bugzilla
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.
7 years, 10 months
[Bug 1046469] New: docker privileged mode with cmd /sbin/init - agetty & high cpu
by Red Hat Bugzilla
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.
7 years, 10 months
[Bug 1091538] New: golang crashing on ARMv7
by Red Hat Bugzilla
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.
7 years, 11 months
[Bug 1100000] New: can't run iscsid in a docker container
by Red Hat Bugzilla
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.
8 years
[Bug 1096273] New: repetition of signal 21 with --sig-proxy and SIGSTOP of docker
by Red Hat Bugzilla
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.
8 years
[Bug 1145659] New: [PATCH] Support /etc/sysconfig/docker-storage
by Red Hat Bugzilla
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.
8 years, 3 months
[Bug 1096296] New: man page inaccuracy about --sig-proxy and --tty
by Red Hat Bugzilla
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.
8 years, 3 months
[Bug 1096276] New: signal 27 (SIGPROF) not passed to container using --sig-proxy
by Red Hat Bugzilla
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.
8 years, 3 months
[Bug 1135152] New: user: Current not implemented on linux/amd64
by Red Hat Bugzilla
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-...
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.
8 years, 4 months
[Bug 1166611] New: Extend golang %files section with golang.org/x directory ownership
by Red Hat Bugzilla
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.
8 years, 6 months