[Bug 1114098] New: fedora 20: etcd broken on install, very out of date, and misconfigured.
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1114098
Bug ID: 1114098
Summary: fedora 20: etcd broken on install, very out of date,
and misconfigured.
Product: Fedora
Version: 20
Component: etcd
Assignee: lacypret(a)gmail.com
Reporter: bugs(a)jameskyle.org
QA Contact: extras-qa(a)fedoraproject.org
CC: golang(a)lists.fedoraproject.org, lacypret(a)gmail.com,
lemenkov(a)gmail.com
Description of problem:
etcd service on fedora 20 only returns 404 page not found for all queries.
Version-Release number of selected component (if applicable):
Fedora 20, etcd 0.1.3
How reproducible:
100%
Steps to Reproduce:
1. yum install etcd
2. systemctl start etcd
3. curl http://127.0.0.1:4001/v2/keys/foo -d "Bar"
Actual results:
404 page not found
Expected results:
{"action":"set","node":{"key":"/message","value":"Hello","modifiedIndex":5,"createdIndex":5}}
Additional info:
The service was configured to use a systemd socket service, but (from the
systemd debs) "etcd doesn't have socket activation".
Even if I disabled the socket service and ran etcd 0.1.3 in the foreground with
defaults, the same behavior was manifest.
Installing the current 0.4.4 version of etcd produced the expected/desired
behavior.
--
You are receiving this mail because:
You are on the CC list for the bug.
9 years, 4 months
[Bug 1121100] New: allow docker run --net=none --hostname=....
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1121100
Bug ID: 1121100
Summary: allow docker run --net=none --hostname=....
Product: Fedora EPEL
Version: el6
Component: docker-io
Severity: medium
Assignee: lsm5(a)fedoraproject.org
Reporter: gilles.gouaillardet(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(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, vbatts(a)redhat.com
Currently, docker run will fail if both --net=none and --hostname=... options
are used.
This has been fixed in the docker git repository :
https://github.com/ggouaillardet/docker/commit/f411f8bfc5d04aed6499dfc90e...
could you please backport this fix to docker-io for epel-6 ?
Thanks and regards,
Gilles
--
You are receiving this mail because:
You are on the CC list for the bug.
9 years, 5 months
[Bug 1113601] New: When kernel is installed as a dependency of autofs, various errors are shown
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1113601
Bug ID: 1113601
Summary: When kernel is installed as a dependency of autofs,
various errors are shown
Product: Fedora
Version: 20
Component: docker-io
Assignee: lsm5(a)switzerlandmail.ch
Reporter: jpazdziora(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
hushan.jia(a)gmail.com, lsm5(a)switzerlandmail.ch,
mattdm(a)redhat.com, mgoldman(a)redhat.com, s(a)shk.io,
vbatts(a)redhat.com
Description of problem:
When kernel is installed as a dependency of autofs, various errors concerning
/var are shown in posttrans.
Version-Release number of selected component (if applicable):
docker-io-1.0.0-4.fc20.x86_64
fedora:20 image as of today: 3f2fed40e4b0
How reproducible:
Deterministic.
Steps to Reproduce:
1. Have Dockerfile:
FROM fedora:20
RUN yum install -y autofs
2. Run docker build -t autofs-test .
Actual results:
# docker build -t autofs-test .
Sending build context to Docker daemon 2.56 kB
Sending build context to Docker daemon
Step 0 : FROM fedora:20
---> 3f2fed40e4b0
Step 1 : RUN yum install -y autofs
---> Running in 9b0bbf2f654d
http://mirrors.zimcom.net/pub/fedora/linux/updates/20/x86_64/repodata/rep...:
[Errno 14] curl#7 - "Failed to connect to 2607:f550:100:33::23: Network is
unreachable"
Trying other mirror.
Resolving Dependencies
--> Running transaction check
---> Package autofs.x86_64 1:5.0.7-40.fc20 will be installed
--> Processing Dependency: kernel >= 2.6.17 for package:
1:autofs-5.0.7-40.fc20.x86_64
--> Processing Dependency: libtirpc.so.1()(64bit) for package:
1:autofs-5.0.7-40.fc20.x86_64
--> Processing Dependency: libhesiod.so.0()(64bit) for package:
1:autofs-5.0.7-40.fc20.x86_64
--> Running transaction check
---> Package hesiod.x86_64 0:3.2.1-2.fc20 will be installed
---> Package kernel.x86_64 0:3.14.8-200.fc20 will be installed
--> Processing Dependency: linux-firmware >= 20130724-29.git31f6b30 for
package: kernel-3.14.8-200.fc20.x86_64
---> Package libtirpc.x86_64 0:0.2.4-3.0.fc20 will be installed
--> Running transaction check
---> Package linux-firmware.noarch 0:20140605-38.gita4f3bc03.fc20 will be
installed
--> Finished Dependency Resolution
Dependencies Resolved
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
autofs x86_64 1:5.0.7-40.fc20 updates 524 k
Installing for dependencies:
hesiod x86_64 3.2.1-2.fc20 fedora 29 k
kernel x86_64 3.14.8-200.fc20 updates 32 M
libtirpc x86_64 0.2.4-3.0.fc20 updates 83 k
linux-firmware noarch 20140605-38.gita4f3bc03.fc20 updates 21 M
Transaction Summary
================================================================================
Install 1 Package (+4 Dependent packages)
Total download size: 53 M
Installed size: 192 M
Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
warning:
/var/cache/yum/x86_64/20/fedora/packages/hesiod-3.2.1-2.fc20.x86_64.rpm: Header
V3 RSA/SHA256 Signature, key ID 246110c1: NOKEY
Public key for hesiod-3.2.1-2.fc20.x86_64.rpm is not installed
Public key for autofs-5.0.7-40.fc20.x86_64.rpm is not installed
--------------------------------------------------------------------------------
Total 4.0 MB/s | 53 MB 00:13
Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-x86_64
Importing GPG key 0x246110C1:
Userid : "Fedora (20) <fedora(a)fedoraproject.org>"
Fingerprint: c7c9 a9c8 9153 f201 83ce 7cba 2eb1 61fa 2461 10c1
Package : fedora-release-20-3.noarch (@fedora-updates/$releasever)
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-x86_64
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : hesiod-3.2.1-2.fc20.x86_64 1/5
Installing : libtirpc-0.2.4-3.0.fc20.x86_64 2/5
Installing : linux-firmware-20140605-38.gita4f3bc03.fc20.noarch 3/5
Installing : kernel-3.14.8-200.fc20.x86_64 4/5
Installing : 1:autofs-5.0.7-40.fc20.x86_64 5/5
No '/dev/log' or 'logger' included for syslog logging
mknod: '/var/tmp/initramfs.aD5A0T/dev/null': Operation not permitted
mknod: '/var/tmp/initramfs.aD5A0T/dev/kmsg': Operation not permitted
mknod: '/var/tmp/initramfs.aD5A0T/dev/console': Operation not permitted
No '/dev/log' or 'logger' included for syslog logging
mknod: '/var/tmp/initramfs.XRmzzi/dev/null': Operation not permitted
mknod: '/var/tmp/initramfs.XRmzzi/dev/kmsg': Operation not permitted
mknod: '/var/tmp/initramfs.XRmzzi/dev/console': Operation not permitted
/usr/lib/kernel/install.d/51-dracut-rescue.install: line 59:
/boot/loader/entries/5b2a1f96231d4de69964798a33d2add8-0-rescue.conf: No such
file or directory
warning: %posttrans(kernel-3.14.8-200.fc20.x86_64) scriptlet failed, exit
status 1
Non-fatal POSTTRANS scriptlet failure in rpm package
kernel-3.14.8-200.fc20.x86_64
Verifying : 1:autofs-5.0.7-40.fc20.x86_64 1/5
Verifying : linux-firmware-20140605-38.gita4f3bc03.fc20.noarch 2/5
Verifying : libtirpc-0.2.4-3.0.fc20.x86_64 3/5
Verifying : hesiod-3.2.1-2.fc20.x86_64 4/5
Verifying : kernel-3.14.8-200.fc20.x86_64 5/5
Installed:
autofs.x86_64 1:5.0.7-40.fc20
Dependency Installed:
hesiod.x86_64 0:3.2.1-2.fc20
kernel.x86_64 0:3.14.8-200.fc20
libtirpc.x86_64 0:0.2.4-3.0.fc20
linux-firmware.noarch 0:20140605-38.gita4f3bc03.fc20
Complete!
---> e11ccfbfb8a0
Removing intermediate container 9b0bbf2f654d
Successfully built e11ccfbfb8a0
Expected results:
Either kernel not pulled in, or no (or less) errors from posttrans.
Additional info:
Using docker-io component as a start of discussion about supporting autofs in
Docker containers and if something can be changed in packaging of autofs or
kernel or in the fedora:20 image to lower the posttrans noise.
--
You are receiving this mail because:
You are on the CC list for the bug.
9 years, 5 months
[Bug 1099206] New: timestamps of libraries and artifacts out of sync
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1099206
Bug ID: 1099206
Summary: timestamps of libraries and artifacts out of sync
Product: Fedora
Version: rawhide
Component: golang
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, s(a)shk.io,
vbatts(a)redhat.com
Description of problem:
https://gist.github.com/ncdc/1a6bcb988a700d52dfec
Version-Release number of selected component (if applicable):
1.2.2-2
How reproducible:
consisten
Steps to Reproduce:
1. build something that uses stdlib
2.
3.
Actual results:
agoldste@localhost:~/go/src/github.com/openshift/docker-source-to-images/go/sti
(master) go install
go install runtime/cgo: open /usr/lib/golang/pkg/linux_amd64/runtime/cgo.a:
permission denied
Expected results:
successful compile
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
9 years, 6 months
[Bug 1096816] New: useradd within EL6 container fails: failure while writing changes to /etc/passwd
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1096816
Bug ID: 1096816
Summary: useradd within EL6 container fails: failure while
writing changes to /etc/passwd
Product: Red Hat Enterprise Linux 6
Version: 6.5
Component: libselinux
Assignee: dwalsh(a)redhat.com
Reporter: dwalsh(a)redhat.com
QA Contact: qe-baseos-security(a)redhat.com
CC: admiller(a)redhat.com, dcleal(a)redhat.com,
dwalsh(a)redhat.com, golang(a)lists.fedoraproject.org,
jpazdziora(a)redhat.com, jumanjiman(a)gmail.com,
lsm5(a)redhat.com, mattdm(a)redhat.com,
mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com
Depends On: 1096123
+++ This bug was initially created as a clone of Bug #1096123 +++
Description of problem:
Between docker-io-0.10.0-2.fc20 and docker-io-0.11.1-1.fc20, the following has
started failing:
$ docker run -t centos /usr/sbin/useradd test
useradd: failure while writing changes to /etc/passwd
'centos' is the official CentOS 6 image (0b443ba03958).
The Fedora 20 host has SELinux enforcing, and the same issue occurs when set to
permissive. No AVCs are seen.
Version-Release number of selected component (if applicable):
docker-io-0.11.1-1.fc20.x86_64
kernel-3.14.2-200.fc20.x86_64
How reproducible:
Always
Steps to Reproduce:
1. docker pull centos
2. docker run -t centos /usr/sbin/useradd test
Actual results:
useradd: failure while writing changes to /etc/passwd
Expected results:
no output
Additional info:
On 0.10.0, an strace of useradd shows:
open("/etc/group", O_RDONLY|O_CLOEXEC) = 11
fstat(11, {st_mode=S_IFREG|0644, st_size=379, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7feb5efe5000
read(11, "root:x:0:\nbin:x:1:bin,daemon\ndae"..., 4096) = 379
close(11) = 0
munmap(0x7feb5efe5000, 4096) = 0
fchown(10, 500, 12) = 0
fchmod(10, 0660) = 0
fsync(10) = 0
close(10) = 0
fstat(6, {st_mode=S_IFREG|0644, st_size=670, ...}) = 0
gettid() = 14
open("/proc/self/task/14/attr/fscreate", O_RDONLY) = 10
read(10, "", 4095) = 0
close(10) = 0
gettid() = 14
open("/proc/self/task/14/attr/fscreate", O_RDWR) = 10
write(10, "system_u:object_r:file_t:s0\0", 28) = 28
close(10) = 0
fstat(6, {st_mode=S_IFREG|0644, st_size=670, ...}) = 0
umask(077) = 022
open("/etc/passwd-", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 10
umask(022) = 077
lseek(6, 0, SEEK_SET) = 0
read(6, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 670
fstat(10, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7feb5efe5000
read(6, "", 4096) = 0
write(10, "root:x:0:0:root:/root:/bin/bash\n"..., 670) = 670
While on 0.11.1, strace shows:
open("/etc/group", O_RDONLY|O_CLOEXEC) = 10
fstat(10, {st_mode=S_IFREG|0644, st_size=379, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f2905a38000
read(10, "root:x:0:\nbin:x:1:bin,daemon\ndae"..., 4096) = 379
close(10) = 0
munmap(0x7f2905a38000, 4096) = 0
fchown(9, 500, 12) = 0
fchmod(9, 0660) = 0
fsync(9) = 0
close(9) = 0
fstat(5, {st_mode=S_IFREG|0644, st_size=675, ...}) = 0
gettid() = 30
open("/proc/self/task/30/attr/fscreate", O_RDONLY) = 9
read(9, "", 4095) = 0
close(9) = 0
gettid() = 30
open("/proc/self/task/30/attr/fscreate", O_RDWR) = -1 EROFS (Read-only file
system)
write(2, "useradd: failure while writing c"..., 54useradd: failure while
writing changes to /etc/passwd
) = 54
--- Additional comment from Dominic Cleal on 2014-05-09 07:13:07 EDT ---
useradd is just calling libselinux's setfscreatecon, which is being blocked.
On 0.11.1, this library call fails, on 0.10.0/0.9 it works.
--- Additional comment from Paul Morgan on 2014-05-09 09:55:15 EDT ---
when selinux=disabled, i cannot reproduce the bug.
when selinux is enabled (permissive), the bug is always reproducible.
i reproduced using two docker service configs:
* first, use default systemd unit
* second, add `--selinux-enabled` as described at
http://blog.docker.io/2014/05/docker-0-11-release-candidate-for-1-0/
override default systemd unit...
# cp /usr/lib/systemd/system/docker.service /etc/systemd/system/
# vim /etc/systemd/system/docker.service
# cat !$
[Unit]
Description=Docker Application Container Engine
Documentation=http://docs.docker.io
After=network.target
[Service]
ExecStart=/usr/bin/docker -d --selinux-enabled
Restart=on-failure
LimitNOFILE=1048576
LimitNPROC=1048576
[Install]
WantedBy=multi-user.target
# systemctl restart docker.service
# systemctl status docker.service
docker.service - Docker Application Container Engine
Loaded: loaded (/etc/systemd/system/docker.service; enabled)
Active: active (running) since Fri 2014-05-09 09:52:25 EDT; 4s ago
Docs: http://docs.docker.io
Main PID: 997 (docker)
CGroup: /system.slice/docker.service
└─997 /usr/bin/docker -d --selinux-enabled
other system info:
$ rpm -q selinux-policy-targeted
selinux-policy-targeted-3.12.1-158.fc20.noarch
$ uname -a
Linux f20-01.example.com 3.13.9-200.fc20.x86_64 #1 SMP Fri Apr 4 12:13:05 UTC
2014 x86_64 x86_64 x86_64 GNU/Linux
$ rpm -q docker-io
docker-io-0.11.1-1.fc20.x86_64
$ docker version
Client version: 0.11.1
Client API version: 1.11
Go version (client): go1.2.1
Git commit (client): fb99f99/0.11.1
Server version: 0.11.1
Server API version: 1.11
Git commit (server): fb99f99/0.11.1
Go version (server): go1.2.1
Last stable version: 0.11.1
$ docker images | grep '^centos'
centos centos6 0b443ba03958 3 weeks ago
297.6 MB
centos latest 0b443ba03958 3 weeks ago
297.6 MB
centos 6.4 539c0211cd76 13 months ago
300.6 MB
--- Additional comment from Lokesh Mandvekar on 2014-05-09 13:41:51 EDT ---
I have a new scratch build
http://kojipkgs.fedoraproject.org//work/tasks/2230/6832230/docker-io-0.11...
with this build, this error doesn't occur with fedora:20, but still does with
centos
dwalsh, comments?
--- Additional comment from Dominic Cleal on 2014-05-09 13:45:57 EDT ---
Comparing the straces between el6 and fedora:20, I don't see any of the same
accesses to attr/fscreate on f20 that are in the bug description. The source
of shadow-utils between el6 & f20 looks very different too, I can't see any
setfscreatecon calls in the useradd code path.
--- Additional comment from Daniel Walsh on 2014-05-09 16:51:06 EDT ---
The problem is inside the container it sees SELinux as being enabled, which is
the bug.
If you do id -Z, does it complain inside the container?
docker run --rm -t -i fedora sh
sh-4.2# id -Z
id: --context (-Z) works only on an SELinux-enabled kernel
sh-4.2# mount | grep /sys
sysfs on /sys type sysfs (ro,relatime,seclabel)
SELinux sees the container as being disabled since /sys/fs/selinux is mounted
as read/only, this will tell useradd NOT to try to do any SELinux stuff while
in the container.
--- Additional comment from Fedora Update System on 2014-05-10 00:04:23 EDT ---
docker-io-0.11.1-3.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/docker-io-0.11.1-3.fc20
--- Additional comment from Dominic Cleal on 2014-05-10 08:01:14 EDT ---
(In reply to Daniel Walsh from comment #5)
> The problem is inside the container it sees SELinux as being enabled, which
> is the bug.
>
> If you do id -Z, does it complain inside the container?
No, it runs and reports a context.
> docker run --rm -t -i fedora sh
> sh-4.2# id -Z
> id: --context (-Z) works only on an SELinux-enabled kernel
> sh-4.2# mount | grep /sys
> sysfs on /sys type sysfs (ro,relatime,seclabel)
$ rpm -q docker-io
docker-io-0.9.1-1.fc20.x86_64
$ docker run -i -t centos /bin/bash
bash-4.1# id -Z
system_u:system_r:docker_t:s0
bash-4.1# mount | grep sys
sysfs on /sys type sysfs (rw,seclabel,nosuid,nodev,noexec,relatime)
$ rpm -q docker-io
docker-io-0.11.1-3.fc20.x86_64
$ docker run -i -t centos /bin/bash
bash-4.1# id -Z
system_u:system_r:svirt_lxc_net_t:s0:c231,c400
bash-4.1# mount | grep /sys
sysfs on /sys type sysfs (ro,seclabel,relatime)
> SELinux sees the container as being disabled since /sys/fs/selinux is
> mounted as read/only, this will tell useradd NOT to try to do any SELinux
> stuff while in the container.
/sys is correctly read-only as you expected, but it seems useradd's still doing
SELinux stuff then. These packages are installed inside the EL6 container:
libselinux-2.0.94-5.3.el6_4.1.x86_64
libselinux-utils-2.0.94-5.3.el6_4.1.x86_64
shadow-utils-4.1.4.2-13.el6.x86_64
Calling is_selinux_enabled() on Fedora is returning 0, while on EL6 it's
returning 1. Another difference - on Fedora, getenforce returns "Disabled" but
on EL6 it prints:
# getenforce
getenforce: getenforce() failedbash-4.1#
/selinux exists within the container, but nothing is actually mounted there.
It appears to be simply a directory on the root filesystem (/selinux/booleans
exists as an empty dir). No other SELinux mounts are visible.
Looking at libselinux-2.0.94, I think it's seeing selinuxfs listed in
/proc/filesystems and assuming SELinux is enabled because of this.
libselinux-2.2.1 on F20 doesn't seem to have this code.
libselinux-2.0.94/src/enabled.c:
/* Drop back to detecting it the long way. */
fp = fopen("/proc/filesystems", "r");
if (!fp)
return -1;
__fsetlocking(fp, FSETLOCKING_BYCALLER);
while ((num = getline(&buf, &len, fp)) != -1) {
if (strstr(buf, "selinuxfs")) {
enabled = 1;
break;
}
}
# grep selinux /proc/filesystems
nodev selinuxfs
(All the above was tested with docker-io-0.11.1-3.fc20)
--- Additional comment from Fedora Update System on 2014-05-12 01:28:00 EDT ---
Package docker-io-0.11.1-3.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing docker-io-0.11.1-3.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-6281/docker-io-0.11.1...
then log in and leave karma (feedback).
--- Additional comment from Dominic Cleal on 2014-05-12 06:34:11 EDT ---
(In reply to Dominic Cleal from comment #7)
> Looking at libselinux-2.0.94, I think it's seeing selinuxfs listed in
> /proc/filesystems and assuming SELinux is enabled because of this.
> libselinux-2.2.1 on F20 doesn't seem to have this code.
Bug #835146 (against EL6) seems to confirm this, suggesting a backport of the
patch that removes the /proc/filesystems based check.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1096123
[Bug 1096123] useradd within EL6 container fails: failure while writing
changes to /etc/passwd
--
You are receiving this mail because:
You are on the CC list for the bug.
9 years, 6 months
[Bug 1124065] New: /usr/bin/gear from geard conflicts with rubygem-openshift-origin-node
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1124065
Bug ID: 1124065
Summary: /usr/bin/gear from geard conflicts with
rubygem-openshift-origin-node
Product: Fedora
Version: 20
Component: geard
Severity: medium
Assignee: lsm5(a)fedoraproject.org
Reporter: tdawson(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
lsm5(a)fedoraproject.org
Description of problem:
/usr/bin/gear from geard conflicts with the same file in
rubygem-openshift-origin-node
Version-Release number of selected component (if applicable):
geard-0-0.14.git06df437
rubygem-openshift-origin-node-1.18.0.1-2
How reproducible:
100%
Steps to Reproduce:
1. yum install geard rubygem-openshift-origin-node
2.
3.
Actual results:
...
Running transaction check
Running transaction test
Transaction check error:
file /usr/bin/gear conflicts between attempted installs of
geard-0-0.3.gitb31df16.fc20.x86_64 and
rubygem-openshift-origin-node-1.18.0.1-1.fc20.noarch
Expected results:
Both packages should be installed.
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
9 years, 6 months