Spec URL:http://renich.fedorapeople.org/SPECS/kupfer.spec SRPM URL: http://renich.fedorapeople.org/SRPMS/kupfer-v205-1.fc14.src.rpm Description: Kupfer is a program to change, speed up and make everything about files and programs more fun on your computer. Kupfer is heavily inspired by Quicksilver; you use it to summon an application or document quickly by typing the first parts of its name. It can also do more than getting at something quickly: there are different plug-ins for accessing more objects and running custom commands.
*** Bug 597681 has been marked as a duplicate of this bug. ***
Koji scratch build is here: http://koji.fedoraproject.org/koji/taskinfo?taskID=3029322 $ rpmlint -v * kupfer-debuginfo.i686: I: checking kupfer-debuginfo.i686: I: checking-url http://kaizer.se/wiki/kupfer/ (timeout 10 seconds) kupfer-debuginfo.i686: E: empty-debuginfo-package kupfer-plugins.i686: I: checking kupfer-plugins.i686: I: checking-url http://kaizer.se/wiki/kupfer/ (timeout 10 seconds) kupfer.spec: I: checking-url http://kaizer.se/publicfiles/kupfer/kupfer-v205.tar.gz (timeout 10 seconds) kupfer.src: I: checking kupfer.src: I: checking-url http://kaizer.se/wiki/kupfer/ (timeout 10 seconds) kupfer.src: E: unknown-key (MD5 kupfer.src: I: checking-url http://kaizer.se/publicfiles/kupfer/kupfer-v205.tar.gz (timeout 10 seconds) kupfer.i686: I: checking kupfer.i686: I: checking-url http://kaizer.se/wiki/kupfer/ (timeout 10 seconds) kupfer.i686: W: only-non-binary-in-usr-lib kupfer.i686: E: standard-dir-owned-by-package /usr/bin kupfer.i686: E: standard-dir-owned-by-package /usr/share/man/man1 kupfer.i686: E: standard-dir-owned-by-package /usr/share/icons 4 packages and 1 specfiles checked; 5 errors, 1 warnings. Thee last three lines are important. Your package owns folders which are already owned by other packages. The files sections should look like this: # main %files -f %{name}.lang %defattr(-,root,root,-) %doc COPYING GIT_VERSION NEWS README.rst %doc Documentation/* %{_bindir}/%{name} %{_bindir}/%{name}-exec %{_datadir}/applications/%{name}.desktop %{_datadir}/applications/%{name}-exec.desktop %{_datadir}/gnome/help/%{name}/* %{_datadir}/icons/hicolor/scalable/apps/%{name}.svg %{_datadir}/mime/packages/%{name}-mimetypes.xml %{_datadir}/%{name}/* %{_libdir}/nautilus/extensions-2.0/* %{_mandir}/man1/%{name}-exec.1.* %{_mandir}/man1/%{name}.1.* # plugins %files plugins %defattr(-,root,root,-) %doc COPYING %{_datadir}/%{name}/%{name}/plugin/* %dir %{_datadir}/%{name}/searchplugins %{_datadir}/%{name}/searchplugins/* It is not needed to list all the certain files explicitely, if the package owns their folders anyway. Kupfer behaves somewhat different from other python packages, which use %{python_sitelib}. Kupfer doesn't ship any architecture depending files, that's why add "BuildArch: noarch" to the header. That's the reason for the empty debug package. Koji scratch build with the changed file lists: http://koji.fedoraproject.org/koji/taskinfo?taskID=3029425 (still without "noarch" declaration)
(In reply to comment #2) > %{_datadir}/gnome/help/%{name}/* > %{_datadir}/%{name}/* Caution: When using asterisks, only the contents of the directory is added to the package. The directory itself stays unowned. Thus, don't use asterisks here. %{_datadir}/%{name}/ adds the directory and its contents recursively. Also have a look at http://fedoraproject.org/wiki/Packaging:Python how to package Python application properly. The license seems to be GLPv2 (according to COPYING). There are also some other licenses involved with the plug-ins. These must be listed in the License field of the plugins subpackage.
Kupfer's licence is GPLv3+ $ kupfer --version kupfer v206-53-g2985afe Kupfer: A free software (GPLv3+) launcher Copyright © 2007--2011 Ulrik Sverdrup with others http://kaizer.se/wiki/kupfer/ See also the main program file.. ./bin/kupfer.in in the source package, /usr/bin/kupfer when installed.
A minor thing, but you could you also consider basing the package description off the current webpage introduction. It goes something like this: --- Kupfer is an interface for quick and convenient access to applications and their documents. The most typical use is to find a specific application and launch it. We have tried to make Kupfer easy to extend with plugins so that this quick-access paradigm can be extended to many more objects than just applications. --- And it uses the additional short heading 'kupfer, a convenient command and access tool' The old description is fuzzy and confusing IMO. The new text only needs a slight edit to make sense for fedora. Thanks for considering this.
(In reply to comment #4) > Kupfer's licence is GPLv3+ Yes, sorry, I looked into the wrong COPYING (data/art/COPYING). BTW, extras/kupfer_provider.py also refers to GPLv2+ in its header. Anyway, we have a multiple licensing scenario here as several files with different licenses are packaged: - application: GPLv3+ - some images: GPLv2+ - some plugins: CC-BY-SA => base package: GPLv2+ and GPLv3+ => plugins-subpackage: GPLv3+ and CC-BY-SA
You can also check against Luca's work http://packages.debian.org/changelogs/pool/main/k/kupfer/kupfer_0+v206-1/kupfer.copyright looks like it has mostly the same view. I think the whole package is GPLv3+ compatible. If not, then there is some documentation and images that are CC-By-SA-3. Also this license information is just an annotation--for kupfer itself "GPLv2+ and GPLv3+" is nonsense, it's distributed using the terms of GPLv3 in reality.
(In reply to comment #7) > Also this license information is just an annotation--for kupfer itself "GPLv2+ > and GPLv3+" is nonsense, it's distributed using the terms of GPLv3 in reality. We have to check the licensing information provided by the tarball and take it seriously. object.svg seems to be derived from a file licensed under GPLv2 only, so object.svg is also under GPLv2 only. (GPLv2+ was a typo, sorry). The application itself is GPLv3+. However, the License field of the package must reflect the licenses of the files in the package. And as there is at least one separate file under GPLv2, we have to mention this as requested by the guidelines: http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#Multiple_Licensing_Scenarios
ah, that's unfortunate but that's what it says in the package. however, gnome-icon-theme has changed license without a clear event being found in their changelog. I am confident to use them under GPLv3+ since the icon set is nowadays LGPL IIUC. FWIW, the file in question is derived from gnome-icon-theme version 2.28 downloaded from Debian.
Ok, guys I took care of most (possibly all) of the observations you made. Please, take a look at: SRPM: http://renich.fedorapeople.org/SRPMS/kupfer-206-2.fc14.src.rpm SPEC: http://renich.fedorapeople.org/SPECS/kupfer.spec Help me make this package worthy! TODO: - separate needed plugins by main package and include them. (FIXME) - separate plugins package into several sub-packages
Another issue: Please don't mix $RPM_BUILD_ROOT and %{buildroot} in the same spec file. The help files for Gnome are not intended to be part of the docs in /usr/share/docs/pkg_name-version. Drop the line "%doc %{_datadir}/gnome/help/kupfer" from the files section and remove the hash from #%{_datadir}/gnome/help/kupfer.
(In reply to comment #11) > Another issue: Please don't mix $RPM_BUILD_ROOT and %{buildroot} in the same > spec file. > > The help files for Gnome are not intended to be part of the docs in > /usr/share/docs/pkg_name-version. Drop the line "%doc > %{_datadir}/gnome/help/kupfer" from the files section and remove the hash from > #%{_datadir}/gnome/help/kupfer. Thanks, Mario, for the feedback. Did everything you asked. Please, check it out here: SPEC: http://renich.fedorapeople.org/SPECS/kupfer.spec SRPM: http://renich.fedorapeople.org/SRPMS/kupfer-206-3.fc15.src.rpm
I would suggest removing those opportunistic runtime dependencies on nautilus. It would be great if I as a Xfce User don't have to install nautilus, with all its possible side-effects. I think desktop independence would be really great. Thanks!
> I would suggest removing those opportunistic runtime dependencies on nautilus. > It would be great if I as a Xfce User don't have to install nautilus, with all > its possible side-effects. I think desktop independence would be really great. > > Thanks! Done! ;) python-gdata installs nautilus as well? don't think so... but... SRPM: http://renich.fedorapeople.org/SRPMS/kupfer-206-4.fc15.src.rpm SPEC: http://renich.fedorapeople.org/SPECS/kupfer.spec(In reply to comment #13)
Created attachment 521579 [details] patch to fix non-opening preferences
I just ran into the following bug [1] and the proposed patch worked for me. Don't know if it's worth to be included. [1] https://bugs.launchpad.net/kupfer/+bug/841867?comments=all
(In reply to comment #16) > I just ran into the following bug [1] and the proposed patch worked for me. > Don't know if it's worth to be included. It seems harmless and adds a check. I will include it. SRPM: http://renich.fedorapeople.org/SRPMS/kupfer-206-5.fc15.src.rpm SPEC: http://renich.fedorapeople.org/SPECS/kupfer.spec
I think we need one more subpackage here. The file /usr/share/Thunar/sendto/kupfer.desktop depends on Thunar, which isn't anywhere in the "Requires" list. It is provided by the "Thunar" package. If you would leave it as is, the folder /usr/share/Thunar/sendto/ would stay unowned after you deinstall kupfer-plugins. Please move the file to a "kupfer-thunar-sendto" subpackage.
Koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=3397561 $ rpmlint -i -v * kupfer.src: I: checking kupfer.src: I: checking-url http://kaizer.se/wiki/kupfer/ (timeout 10 seconds) kupfer.src: W: patch-not-applied Patch0: %{name}-fix_non-opening_preferences.patch A patch is included in your package but was not applied. Refer to the patches documentation to see what's wrong. kupfer.src: I: checking-url http://kaizer.se/publicfiles/kupfer/kupfer-v206.tar.gz (timeout 10 seconds) kupfer.i686: I: checking kupfer.i686: I: checking-url http://kaizer.se/wiki/kupfer/ (timeout 10 seconds) kupfer.i686: E: no-binary The package should be of the noarch architecture because it doesn't contain any binaries. kupfer.i686: W: only-non-binary-in-usr-lib There are only non binary files in /usr/lib so they should be in /usr/share. kupfer.i686: E: standard-dir-owned-by-package /usr/bin This package owns a directory that is part of the standard hierarchy, which can lead to default directory permissions or ownerships being changed to something non-standard. kupfer.x86_64: I: checking kupfer.x86_64: I: checking-url http://kaizer.se/wiki/kupfer/ (timeout 10 seconds) kupfer.x86_64: E: no-binary The package should be of the noarch architecture because it doesn't contain any binaries. kupfer.x86_64: W: only-non-binary-in-usr-lib There are only non binary files in /usr/lib so they should be in /usr/share. kupfer.x86_64: E: standard-dir-owned-by-package /usr/bin This package owns a directory that is part of the standard hierarchy, which can lead to default directory permissions or ownerships being changed to something non-standard. kupfer-debuginfo.i686: I: checking kupfer-debuginfo.i686: I: checking-url http://kaizer.se/wiki/kupfer/ (timeout 10 seconds) kupfer-debuginfo.i686: E: empty-debuginfo-package This debuginfo package contains no files. This is often a sign of binaries being unexpectedly stripped too early during the build, rpmbuild not being able to strip the binaries, the package actually being a noarch one but erratically packaged as arch dependent, or something else. Verify what the case is, and if there's no way to produce useful debuginfo out of it, disable creation of the debuginfo package. kupfer-debuginfo.x86_64: I: checking kupfer-debuginfo.x86_64: I: checking-url http://kaizer.se/wiki/kupfer/ (timeout 10 seconds) kupfer-debuginfo.x86_64: E: empty-debuginfo-package This debuginfo package contains no files. This is often a sign of binaries being unexpectedly stripped too early during the build, rpmbuild not being able to strip the binaries, the package actually being a noarch one but erratically packaged as arch dependent, or something else. Verify what the case is, and if there's no way to produce useful debuginfo out of it, disable creation of the debuginfo package. kupfer-plugins.i686: I: checking kupfer-plugins.i686: I: checking-url http://kaizer.se/wiki/kupfer/ (timeout 10 seconds) kupfer-plugins.i686: W: dangling-relative-symlink /usr/share/Thunar/sendto/kupfer.desktop ../../applications/kupfer.desktop The target of the symbolic link does not exist within this package or its file based dependencies. Verify spelling of the link target and that the target is included in a package in this package's dependency chain. kupfer-plugins.x86_64: I: checking kupfer-plugins.x86_64: I: checking-url http://kaizer.se/wiki/kupfer/ (timeout 10 seconds) kupfer-plugins.x86_64: W: dangling-relative-symlink /usr/share/Thunar/sendto/kupfer.desktop ../../applications/kupfer.desktop The target of the symbolic link does not exist within this package or its file based dependencies. Verify spelling of the link target and that the target is included in a package in this package's dependency chain. kupfer.spec: W: patch-not-applied Patch0: %{name}-fix_non-opening_preferences.patch A patch is included in your package but was not applied. Refer to the patches documentation to see what's wrong. kupfer.spec: I: checking-url http://kaizer.se/publicfiles/kupfer/kupfer-v206.tar.gz (timeout 10 seconds) 7 packages and 1 specfiles checked; 6 errors, 6 warnings. Some more issues: The package should be noarch, because no binary file is present anywhere. This explains why the debuginfo packages are empty. The nautilus extension is in /usr/lib, that's OK so far, but it should also go into a subpackage. Please change %{_bindir} to %{_bindir}/* to let only the executable files be owned by your package, not the folder itself. You may remove the %defattr line from the file lists, unless you want to provide your package for EPEL <= 5. The Patch0 is nowhere applied. You have to apply it in the %prep section: %patch0 -p0 Please move the Thunar file into its own subpackage, as earlier mentioned.
Any progress here? I would to see this package soon in Fedora.
There is a new version of kupfer v207 available. But I think this Review is mostly dead. Perhaps we should open a new one and try to get the review done.
Well, for what is worth, here are the new SRPM and SPEC files: SRPM: http://renich.fedorapeople.org/SPECS/kupfer.spec SPEC: http://renich.fedorapeople.org/SPECS/kupfer.spec It builds...
In the meantime, a new version of Kupfer has been released: SRPM: http://mariobl.fedorapeople.org/Review/SRPMS/kupfer-208-1.fc17.src.rpm SPEC: http://mariobl.fedorapeople.org/Review/SPECS/kupfer.spec Koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=4204121 I've splitted the Thunar part into a new subpackage. Furthermore, the Nautilus extension could be dropped for now, because it seems to be designed for older versions (it installs into %{_libdir}/nautilus/extensions-2.0/). I'm unsure if it could be a noarch package, because we have actually no architecture-independent files. But the Nautilus extension goes into either /lib or /lib64 which could avoid the noarch declaration. Not fully tested yet, but it builds and works basically.
Any news from Renich (who initially requested the review)? Seems to be that this process has been almostly stopped. Some people are really interested in to see this package soon in Fedora.
(In reply to comment #24) > Any news from Renich (who initially requested the review)? Seems to be that > this process has been almostly stopped. Some people are really interested in > to see this package soon in Fedora. Hey Mario. I haven't had the time. Honestly, since I'm a fervent gnome3 user, I don't see much benefit in packaging it. If anybody wants to take over, please do.
(In reply to comment #25) > If anybody wants to take over, please do. I'll take it. Next days I will open a new review request and mark the current one as a duplicate. Anyway, many thanks for your previous work!
*** This bug has been marked as a duplicate of bug 842410 ***