Bug 1025071

Upstream patch to do "b": https://bugs.launchpad.net/qemu/+bug/1243287

*** Bug 1038792 has been marked as a duplicate of this bug. ***

"b" won't work either, given the issue is not on runtime, but during dependency resolution.

mator suggested on IRC:
c) we could use virt-what: http://people.redhat.com/~rjones/virt-what/


It seems a better solution than requiring dmidecode explicitly and it is available on Fedora for all arches.

(In reply to Gustavo Luiz Duarte from comment #3)
> "b" won't work either, given the issue is not on runtime, but during
> dependency resolution.

Sure it will. I mean, there are some implicit packaging changes implied, but I don't see a big deal. Simply either make cloud-init archful and make the Requires conditional on arch, or don't hard-require dmidecode at all and just make sure it is in the package set on architectures where it is useful.

virt-what just adds a layer of indirection to the problem, because it's just a shell script which uses dmidecode as well. (And which already fails gracefully.)

In fact, from the virt-what specfile:

# virt-what script uses dmidecode and getopt (from util-linux).
# RPM cannot detect this so make the dependencies explicit here.
%ifarch %{ix86} x86_64
Requires:       dmidecode
%endif

(In reply to Matthew Miller from comment #4)
> Sure it will. I mean, there are some implicit packaging changes implied, but
> I don't see a big deal. Simply either make cloud-init archful and make the
> Requires conditional on arch, or don't hard-require dmidecode at all and
> just make sure it is in the package set on architectures where it is useful.

Right. I was just assuming that the cloud-init maintainer doesn't want to make it archful based on https://bugzilla.redhat.com/show_bug.cgi?id=1038792#c1
(only now I checked it and figured you are also a maintainer, so nevermind ;) )

Using virt-what does add a layer of indirection but also has better support for other hypervisors and avoids code duplication. Anyway, I'm fine with either solution as long we get cloud-init available for all arches.

What we need here? Writing a patch doesn't seem too much effort. If you want I can try to write a patch to implement "b".

Upstream fix:

https://bugs.launchpad.net/cloud-init/+bug/1285686

Can we pull this into Fedora then?

Could we please make cloud-init archful, as Matthew suggested on comment 4 ?

Here is a patch to do that:

diff --git a/cloud-init.spec b/cloud-init.spec
index 24a8b21..b6701fe 100644
--- a/cloud-init.spec
+++ b/cloud-init.spec
@@ -20,13 +20,14 @@ Patch0:         cloud-init-0.7.5-fedora.patch
 Patch1:         cloud-init-0.7.5-rsyslog-programname.patch
 
 
-BuildArch:      noarch
 BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
 BuildRequires:  python-devel
 BuildRequires:  python-setuptools-devel
 BuildRequires:  systemd-units
+%ifarch %{ix86} x86_64 ia64
 Requires:       dmidecode
+%endif
 Requires:       e2fsprogs
 Requires:       iproute
 Requires:       libselinux-python

cloud-init-0.7.2-10.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/cloud-init-0.7.2-10.fc20

cloud-init-0.7.2-10.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/cloud-init-0.7.2-10.fc19

Package cloud-init-0.7.2-10.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing cloud-init-0.7.2-10.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-7238/cloud-init-0.7.2-10.fc19
then log in and leave karma (feedback).

cloud-init-0.7.2-10.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

cloud-init-0.7.2-10.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.