https://bugzilla.redhat.com/show_bug.cgi?id=771252 --- Comment #52 from leigh scott <leigh123linux@xxxxxxxxxxxxxx> --- (In reply to comment #51) > I haven't checked everything yet, but here are a few things reported by > fedora-review: > > > [!]: MUST Development (unversioned) .so files in -devel subpackage, if > present. > Note: cinnamon-1.4.0-2.UP1.fc18.i686.rpm : > /usr/lib/cinnamon/libcinnamon.so Sorry but this is wrong, the unversioned .so belongs in the main package. [leigh@main-pc f17]$ rpm -ql cinnamon |grep lib /usr/lib64/cinnamon /usr/lib64/cinnamon/Cinnamon-0.1.typelib /usr/lib64/cinnamon/Gvc-1.0.typelib /usr/lib64/cinnamon/St-1.0.typelib /usr/lib64/cinnamon/libcinnamon.so /usr/libexec/cinnamon-calendar-server /usr/libexec/cinnamon-hotplug-sniffer /usr/libexec/cinnamon-perf-helper /usr/share/glib-2.0/schemas/org.cinnamon.gschema.xml [leigh@main-pc f17]$ rpm -ql gnome-shell |grep lib /usr/lib64/gnome-shell /usr/lib64/gnome-shell/Gvc-1.0.typelib /usr/lib64/gnome-shell/Shell-0.1.typelib /usr/lib64/gnome-shell/St-1.0.typelib /usr/lib64/gnome-shell/libgnome-shell.la /usr/lib64/gnome-shell/libgnome-shell.so /usr/lib64/mozilla/plugins/libgnome-shell-browser-plugin.so /usr/libexec/gnome-shell-calendar-server /usr/libexec/gnome-shell-hotplug-sniffer /usr/libexec/gnome-shell-perf-helper /usr/share/glib-2.0/schemas/org.gnome.shell.gschema.xml [leigh@main-pc f17]$ gnome-shell has the unversioned .so as well! > > [!]: MUST %config files are marked noreplace or the reason is justified. > Note: %config %{_sysconfdir}/gconf/schemas/cinnamon.schemas%config > %{_sysconfdir}/xdg/menus/cinnamon-applications.menu%config > %{_sysconfdir}/xdg/menus/cinnamon-settings.menu > Wrong, these files aren't meant to be configured by the user so don't need the %config flag. gnome-shell and gnome-menus don't have the %config flag either > [!]: MUST Package does not contain duplicates in %files. > Note: warning: File listed twice: > /usr/share/cinnamon/locale/ar/LC_MESSAGES/cinnamon.mo > I will fix this > rpmlint gives many incorrect-fsf-address errors. I think Fedora policy is > to ask upstream to fix that. > > cinnamon.i686: E: explicit-lib-dependency librsvg2(x86-32) > > cinnamon.i686: E: backup-file-in-package > /usr/share/cinnamon-settings/cinnamon-settings.py.orig Are you reviewing the latest srpm? because that file doesn't exist! [leigh@main-pc f17]$ rpm -q cinnamon cinnamon-1.4.0-2.UP1.fc16.x86_64 [leigh@main-pc f17]$ rpm -ql cinnamon |grep cinnamon-settings.py.orig [leigh@main-pc f17]$ > > cinnamon.i686: W: dangerous-command-in-%pre rm > cinnamon.i686: W: dangerous-command-in-%post rm > > [!]: SHOULD SourceX / PatchY prefixed with %{name}. > Note: Source0: cinnamon-%{version}.UP1.tar.gz > (cinnamon-%{version}.UP1.tar.gz) Source1: cinnamon.desktop > (cinnamon.desktop) Source2: cinnamon.session (cinnamon.session) Source3: > menu.png (menu.png) Patch0: cinnamon-favourite-apps-firefox.patch > (cinnamon-favourite-apps-firefox.patch) Patch1: menu.patch (menu.patch) > Patch2: logout_theme.patch (logout_theme.patch) Patch3: > cinnamon_bluetooth.patch (cinnamon_bluetooth.patch) Patch4: > settings.patch (settings.patch) > > That's not required, but I strongly suggest going beyond that and naming > patches starting not just with %{name}-, but %[name}-%{version}-. I've > found that makes maintenance of the package easier. You might also find > adding a "-b .briefdescription" to the %patch command line handy, as it > prepares for the use of gendiff when you want to create updated patches. > I will version the patches, as for using the -b flag, no it causes crap like this cinnamon.i686: E: backup-file-in-package /usr/share/cinnamon-settings/cinnamon-settings.py.orig > [!]: SHOULD Spec use %global instead of %define. > Note: %define clutter_version 1.4.0 %define > gobject_introspection_version > 0.10.1 %define muffin_version 1.0.2 %define eds_version 2.91.6 %define > json_glib_version 0.13.2 > I will change the %define to %global > cinnamon.src: W: invalid-url Source0: cinnamon-1.4.0.UP1.tar.gz > > Note that it is possible to construct URLs to extract tarballs with a chosen > name. See the "GitHub is a terrible upstream" thread on the devel list. In > particular, Orion Poplawski pointed out recently: > > It wasn't obvious at first to me but this works with tags not > just commit hashes. So if a project tags there version numbers > you can do something like: > > https://github.com/enthought/mayavi/tarball/4.2.0/Mayavi-4.2.0.tar.gz > > The contents are still in a directory named user-app-hash -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review