The proper location for rpm macros files in rpm >= 4.11 is %{_rpmconfigdir}/macros.d, please move them there from /etc/rpm. If this package's specfile targets Fedora and EL >= 7 only, the location for macro files can be simply changed from /etc/rpm to %{_rpmconfigdir}/macros.d. If it is intended to work on EL 5 and/or 6 as well, you can define a macros dir for example as follows (all on one line) and install the macros to %{macrosdir}: %global macrosdir %(d=%{_rpmconfigdir}/macros.d; [ -d $d ] || d=%{_sysconfdir}/rpm; echo $d)
Additionally, be sure to remove %config from macros files: https://fedorahosted.org/fpc/ticket/259
shogun-data-0.8.1-0.4.git20140303.6615cf0.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/shogun-data-0.8.1-0.4.git20140303.6615cf0.fc19
shogun-data-0.8.1-0.4.git20140303.6615cf0.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/shogun-data-0.8.1-0.4.git20140303.6615cf0.el6
shogun-data-0.8.1-0.4.git20140303.6615cf0.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/shogun-data-0.8.1-0.4.git20140303.6615cf0.fc20
shogun-data-0.8.1-0.4.git20140303.6615cf0.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/shogun-data-0.8.1-0.4.git20140303.6615cf0.el5
Package shogun-data-0.8.1-0.4.git20140303.6615cf0.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 shogun-data-0.8.1-0.4.git20140303.6615cf0.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-3844/shogun-data-0.8.1-0.4.git20140303.6615cf0.fc20 then log in and leave karma (feedback).
(In reply to Fedora Update System from comment #2) > shogun-data-0.8.1-0.4.git20140303.6615cf0.fc19 has been submitted as an > update for Fedora 19. > https://admin.fedoraproject.org/updates/shogun-data-0.8.1-0.4.git20140303. > 6615cf0.fc19 Hi, there was an error when I install shogun packages, which is shown below: # yum install shogun\* Loaded plugins: langpacks, refresh-packagekit rpmfusion-free-updates | 3.3 kB 00:00:00 rpmfusion-nonfree-updates | 3.3 kB 00:00:00 updates/19/x86_64/metalink | 5.2 kB 00:00:00 Package shogun-3.2.0-2.fc19.x86_64 already installed and latest version Package shogun-cli-3.2.0-2.fc19.x86_64 already installed and latest version Package shogun-devel-3.2.0-2.fc19.x86_64 already installed and latest version Resolving Dependencies --> Running transaction check ---> Package shogun-data.noarch 0:0.8.1-0.2.git20140303.6615cf0.fc19 will be installed ---> Package shogun-doc.noarch 0:3.2.0-2.fc19 will be installed --> Processing Dependency: shogun-data = 0.8 for package: shogun-doc-3.2.0-2.fc19.noarch --> Finished Dependency Resolution Error: Package: shogun-doc-3.2.0-2.fc19.noarch (updates) Requires: shogun-data = 0.8 Installing: shogun-data-0.8.1-0.2.git20140303.6615cf0.fc19.noarch (updates) shogun-data = 0.8.1-0.2.git20140303.6615cf0.fc19 You could try using --skip-broken to work around the problem ============================= FYI, I have these shogun packages installed on my Fedora 19 (x86-64) machine: shogun, shogun-cli, shogun-devel. Can you please repackage for convinience?
(In reply to Gahn Hye Nun from comment #7) > (In reply to Fedora Update System from comment #2) > > shogun-data-0.8.1-0.4.git20140303.6615cf0.fc19 has been submitted as an > > update for Fedora 19. > > https://admin.fedoraproject.org/updates/shogun-data-0.8.1-0.4.git20140303. > > 6615cf0.fc19 > > Hi, there was an error when I install shogun packages, which is shown below: > # yum install shogun\* > Loaded plugins: langpacks, refresh-packagekit > rpmfusion-free-updates > | 3.3 kB 00:00:00 > rpmfusion-nonfree-updates > | 3.3 kB 00:00:00 > updates/19/x86_64/metalink > | 5.2 kB 00:00:00 > Package shogun-3.2.0-2.fc19.x86_64 already installed and latest version > Package shogun-cli-3.2.0-2.fc19.x86_64 already installed and latest version > Package shogun-devel-3.2.0-2.fc19.x86_64 already installed and latest version > Resolving Dependencies > --> Running transaction check > ---> Package shogun-data.noarch 0:0.8.1-0.2.git20140303.6615cf0.fc19 will be > installed > ---> Package shogun-doc.noarch 0:3.2.0-2.fc19 will be installed > --> Processing Dependency: shogun-data = 0.8 for package: > shogun-doc-3.2.0-2.fc19.noarch > --> Finished Dependency Resolution > Error: Package: shogun-doc-3.2.0-2.fc19.noarch (updates) > Requires: shogun-data = 0.8 > Installing: shogun-data-0.8.1-0.2.git20140303.6615cf0.fc19.noarch > (updates) > shogun-data = 0.8.1-0.2.git20140303.6615cf0.fc19 > You could try using --skip-broken to work around the problem > ============================= > FYI, I have these shogun packages installed on my Fedora 19 (x86-64) > machine: shogun, shogun-cli, shogun-devel. > Can you please repackage for convinience? You can use the shogun-packages from the `updates-testing` repositories. Those are build against the newer shogun-data-package: `yum --enablerepo=*testing* update shogun*` Cheers, Björn
Generally, it is a bad idea to have a -doc subpackage depend on anything, if the documentation can be displayed with arbitrary browsers (e.g. HTML, PDF). The spec file doesn't comment on the dependency, but probably it has been added for the examples. It makes no sense to add it for the HTML docs.
shogun-data-0.8.1-0.4.git20140303.6615cf0.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
shogun-data-0.8.1-0.4.git20140303.6615cf0.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
shogun-data-0.8.1-0.4.git20140303.6615cf0.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
shogun-data-0.8.1-0.4.git20140303.6615cf0.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.