[Bug 1100502] New: golang-1.2.2-2 update breaks GOROOT path
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1100502
Bug ID: 1100502
Summary: golang-1.2.2-2 update breaks GOROOT path
Product: Fedora
Version: 20
Component: golang
Assignee: adam(a)spicenitz.org
Reporter: porjo38(a)yahoo.com.au
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
Since updating to golang-1.2.2-2, I get error "go: cannot find GOROOT
directory: /usr/lib64/golang" when trying to run a go program e.g. "go run
main.go"
Adding a symbolic link fixes the issue:
ln -s /usr/lib/golang/ /usr/lib64/golang
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months
[Bug 1099732] New: go install fails if cgo is used
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1099732
Bug ID: 1099732
Summary: go install fails if cgo is used
Product: Fedora
Version: 20
Component: golang
Assignee: adam(a)spicenitz.org
Reporter: davidb(a)davidb.org
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
Created attachment 897821
--> https://bugzilla.redhat.com/attachment.cgi?id=897821&action=edit
Example program to provoke bug
Description of problem:
'go install' tries to compile runtime/cgo.a and install it in /usr/lib when the
source makes use of Cgo.
Version-Release number of selected component (if applicable):
golang-src-1.2.2-2.fc20.noarch
golang-1.2.2-2.fc20.x86_64
golang-pkg-linux-amd64-1.2.2-2.fc20.noarch
golang-pkg-bin-linux-amd64-1.2.2-2.fc20.x86_64
How reproducible:
Always
Steps to Reproduce:
1. Create directory with src/bug1/hello.go containing the attached file.
2. GOPATH=$(PWD) /usr/bin/go install bug1
Actual results:
go install runtime/cgo: open /usr/lib/golang/pkg/linux_amd64/runtime/cgo.a:
permission denied
Expected results:
Produces bin/bug1, which when run prints hello world. This worked fine with
1.2.1 (before today's update).
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months
[Bug 1096293] New: `docker start` doesn't fail on started container
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1096293
Bug ID: 1096293
Summary: `docker start` doesn't fail on started container
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, s(a)shk.io, vbatts(a)redhat.com
Depends On: 1090071
+++ This bug was initially created as a clone of Bug #1090071 +++
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-0.10.0-8.el7.x86_64
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
--- Additional comment from Lukas Doktor on 2014-05-05 03:38:57 EDT ---
Upstream Docker version 0.10.0, build dc9c28f/0.10.0 has the same issue
(silently passes even thought the container was already running)
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1090071
[Bug 1090071] `docker start` doesn't fail on started container
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months
[Bug 1090071] New: `docker start` doesn't fail on started container
by Red Hat Bugzilla
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.
8 years, 10 months
[Bug 1096269] New: lost signals when sending lots of signals using --sig-proxy to docker
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1096269
Bug ID: 1096269
Summary: lost signals when sending lots of signals using
--sig-proxy to docker
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: 1087700
+++ This bug was initially created as a clone of Bug #1087700 +++
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-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. 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..
--- Additional comment from Lukas Doktor on 2014-05-05 04:10:09 EDT ---
The same results with upstream docker dc9c28f/0.10.0:
Output:
Received 1, ignoring...
[debug] stdcopy.go:111 framesize: 24
Received 2, ignoring...
Daemon output:
2014/05/05 10:08:45 POST
/v1.10/containers/b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5/kill?signal=HUP
[/home/medic/Work/Projekty/Docker/root|fa3816b6] +job
kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, HUP)
[/home/medic/Work/Projekty/Docker/root|fa3816b6] -job
kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, HUP) =
OK (0)
2014/05/05 10:08:45 POST
/v1.10/containers/b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5/kill?signal=INT
[/home/medic/Work/Projekty/Docker/root|fa3816b6] +job
kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, INT)
[/home/medic/Work/Projekty/Docker/root|fa3816b6] -job
kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, INT) =
OK (0)
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1087700
[Bug 1087700] lost signals when sending lots of signals using --sig-proxy
to docker
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months
[Bug 1087697] New: man page inaccuracy about --sig-proxy and --tty
by Red Hat Bugzilla
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.
8 years, 10 months
[Bug 1075232] New: 0.9.0 Adds virtual interface, NetworkManager attempts to assign dhcp address to it
by Red Hat Bugzilla
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.
8 years, 10 months