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.
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.
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.
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.
https://bugzilla.redhat.com/show_bug.cgi?id=1033604
Bug ID: 1033604
Summary: Unable to start systemd service in 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:
Using Dockerfile like this:
FROM mattdm/fedora:latest
RUN yum update -y
RUN yum install -y redis
RUN systemctl enable redis.service
RUN systemctl start redis.service
EXPOSE 6379
ENTRYPOINT ["/usr/bin/redis-cli"]
The step 'systemctl start redis.service' failed with this error message:
Failed to get D-Bus connection: No connection to service manager.
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. Save the above Dockerfile
2. Run: docker build -t test/redis .
3. The build fill faile on systemctl start.
Actual results:
The service failed to start due to D-BUS connection.
Expected results:
The service should be started?
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1046717
Bug ID: 1046717
Summary: Cancel run or pull operation doesn't actually stop the
ongoing task
Product: Fedora
Version: 20
Component: docker-io
Severity: medium
Assignee: lsm5(a)redhat.com
Reporter: baptiste.millemathias(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:
I've downloaded a docker image using "docker pull bradrydzewski/mongodb:2.4"
and when I wanted to run it I did a "docker run bradrydzewski/mongodb" as the
image name was named like that, and I saw docker pulling another image (the
size was different), so I hit Ctrl+C thinking to going kill the operation.
However a ps fax showed me dockerd was still downloading something, certainly
image bradrydzewski/mongodb
Version-Release number of selected component (if applicable):
docker-io-0.7.0-14.fc20.x86_64
How reproducible:
100 %
Steps to Reproduce:
1. docker pull bradrydzewski/mongodb:2.4 (let the complete operation happens)
2. docker run bradrydzewski/mongodb, and hit ctrl+c after few seconds
Actual results:
Dockerd still download image
Expected results:
docker client should ask Dockerd to cancel the download of the image
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1029587
Bug ID: 1029587
Summary: upgrade to go1.2 (once it is available)
Product: Fedora
Version: rawhide
Component: golang
Severity: low
Assignee: adam(a)spicenitz.org
Reporter: vbatts(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,
vbatts(a)redhat.com
What steps will reproduce the problem?
If possible, include a link to a program on play.golang.org.
1. export GOPATH=$(mktemp -d)
2. go get code.google.com/p/go.tools/cmd/oracle
3.
What is the expected output?
What do you see instead?
/tmp/tmp.cjYFzAeLWC/src/code.google.com/p/go.tools/importer/source.go:434:
n.Lparen undefined (type *ast.TypeAssertExpr has no field or method Lparen)
/tmp/tmp.cjYFzAeLWC/src/code.google.com/p/go.tools/importer/source.go:435:
n.Lparen undefined (type *ast.TypeAssertExpr has no field or method Lparen)
/tmp/tmp.cjYFzAeLWC/src/code.google.com/p/go.tools/importer/source.go:436:
n.Rparen undefined (type *ast.TypeAssertExpr has no field or method Rparen)
Which compiler are you using (5g, 6g, 8g, gccgo)?
6g
Which operating system are you using?
Red Hat Enterprise Linux Workstation release 6.4 (Santiago)
Which version are you using?
go version go1.1.2 linux/amd64 (golang-1.1.2-4.el6.x86_64)
Please provide any additional information below.
I tested against the tip of their repo (future version 1.2) (go version devel
+39c724dd7f25 Tue Nov 12 09:28:07 2013 +1100 linux/amd64)
and code.google.com/p/go.tools/cmd/oracle and
code.google.com/p/go.tools/cmd/ssadump build just fine
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1056185
Bug ID: 1056185
Summary: go test code.google.com/p/go.net/ipv6 test fails
Product: Fedora EPEL
Version: el6
Component: golang-googlecode-net
Assignee: lsm5(a)redhat.com
Reporter: tis(a)foobar.fi
QA Contact: extras-qa(a)fedoraproject.org
CC: golang(a)lists.fedoraproject.org, lsm5(a)redhat.com,
mattdm(a)redhat.com, vbatts(a)redhat.com
Description of problem:
%check fails if machine you build this package on has ipv6 connectivity.
+ go test code.google.com/p/go.net/ipv6
--- FAIL: TestConnInitiatorPathMTU (0.00 seconds)
sockopt_test.go:58: ipv6.Conn.PathMTU failed: getsockopt: protocol not
available
--- FAIL: TestConnResponderPathMTU (0.00 seconds)
sockopt_test.go:91: ipv6.Conn.PathMTU failed: getsockopt: protocol not
available
--- FAIL: TestPacketConnReadWriteUnicastUDP (0.00 seconds)
unicast_test.go:120: ipv6.PacketConn.SetControlMessage failed:
setsockopt: protocol not available
FAIL
FAIL code.google.com/p/go.net/ipv6 0.041s
RPM build errors:
error: Bad exit status from /var/tmp/rpm-tmp.DbihRB (%check)
I guess package is broken for ipv6.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1047194
Bug ID: 1047194
Summary: etcd-0.2.0 is available
Product: Fedora
Version: rawhide
Component: etcd
Keywords: FutureFeature, Triaged
Assignee: lacypret(a)gmail.com
Reporter: upstream-release-monitoring(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: golang(a)lists.fedoraproject.org, lacypret(a)gmail.com,
lemenkov(a)gmail.com, lsm5(a)redhat.com
Latest upstream release: 0.2.0
Current version/release in Fedora Rawhide: 0.1.2-5.fc21
URL: https://api.github.com/repos/coreos/etcd/tags
Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy
More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1069718
Bug ID: 1069718
Summary: Kernel container scalability issue in docker - VFS and
mount path consuming too much CPU
Product: Red Hat Enterprise Linux 7
Version: 7.0
Component: systemd
Severity: urgent
Priority: urgent
Assignee: systemd-maint(a)redhat.com
Reporter: sct(a)redhat.com
QA Contact: qe-baseos-daemons(a)redhat.com
CC: agk(a)redhat.com, alexl(a)redhat.com, fs-maint(a)redhat.com,
fweimer(a)redhat.com, golang(a)lists.fedoraproject.org,
ikent(a)redhat.com, jeder(a)redhat.com,
jpoimboe(a)redhat.com, lsm5(a)redhat.com,
lvm-team(a)redhat.com, mattdm(a)redhat.com,
mgoldman(a)redhat.com, mjenner(a)redhat.com,
perfbz(a)redhat.com, rwheeler(a)redhat.com,
skottler(a)redhat.com, vbatts(a)redhat.com
Depends On: 1061359, 1064929
Group: private
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1061359
[Bug 1061359] improve docker devicemapper backend scalability
https://bugzilla.redhat.com/show_bug.cgi?id=1064929
[Bug 1064929] Kernel container scalability issue in docker - VFS and mount
path consuming too much CPU
--
You are receiving this mail because:
You are on the CC list for the bug.