Bug 696249 - Review Request: kupfer - an interface for quick and convenient access to applications and their documents.
Summary: Review Request: kupfer - an interface for quick and convenient access to appl...
Keywords:
Status: CLOSED DUPLICATE of bug 842410
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mario Blättermann
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 597681 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-13 17:00 UTC by Renich Bon Ciric
Modified: 2012-07-23 19:33 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-07-23 19:33:40 UTC
Type: ---
mario.blaettermann: fedora-review?


Attachments (Terms of Use)
patch to fix non-opening preferences (504 bytes, text/plain)
2011-09-06 06:23 UTC, hannes
no flags Details

Description Renich Bon Ciric 2011-04-13 17:00:16 UTC
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.

Comment 1 Renich Bon Ciric 2011-04-13 17:01:45 UTC
*** Bug 597681 has been marked as a duplicate of this bug. ***

Comment 2 Mario Blättermann 2011-04-27 10:55:24 UTC
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)

Comment 3 Martin Gieseking 2011-04-27 11:45:30 UTC
(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.

Comment 4 Ulrik 2011-04-27 12:44:51 UTC
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.

Comment 5 Ulrik 2011-04-27 12:54:37 UTC
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.

Comment 6 Martin Gieseking 2011-04-27 13:13:57 UTC
(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

Comment 7 Ulrik 2011-04-27 13:25:20 UTC
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.

Comment 8 Martin Gieseking 2011-04-27 14:04:46 UTC
(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

Comment 9 Ulrik 2011-04-27 14:15:02 UTC
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.

Comment 10 Renich Bon Ciric 2011-05-17 07:13:18 UTC
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

Comment 11 Mario Blättermann 2011-08-10 19:19:28 UTC
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.

Comment 12 Renich Bon Ciric 2011-08-13 07:13:35 UTC
(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

Comment 13 hannes 2011-09-01 06:13:41 UTC
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!

Comment 14 Renich Bon Ciric 2011-09-05 11:35:00 UTC
> 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)

Comment 15 hannes 2011-09-06 06:23:33 UTC
Created attachment 521579 [details]
patch to fix non-opening preferences

Comment 16 hannes 2011-09-06 06:24:24 UTC
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

Comment 17 Renich Bon Ciric 2011-09-07 07:14:11 UTC
(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

Comment 18 Mario Blättermann 2011-10-02 18:15:03 UTC
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.

Comment 19 Mario Blättermann 2011-10-02 18:50:31 UTC
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.

Comment 20 Mario Blättermann 2011-11-26 22:31:21 UTC
Any progress here? I would to see this package soon in Fedora.

Comment 21 hannes 2012-04-15 06:40:25 UTC
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.

Comment 22 Renich Bon Ciric 2012-05-06 10:37:27 UTC
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...

Comment 23 Mario Blättermann 2012-06-28 09:59:04 UTC
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.

Comment 24 Mario Blättermann 2012-07-20 20:59:16 UTC
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.

Comment 25 Renich Bon Ciric 2012-07-23 02:56:10 UTC
(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.

Comment 26 Mario Blättermann 2012-07-23 19:25:05 UTC
(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!

Comment 27 Mario Blättermann 2012-07-23 19:33:40 UTC

*** This bug has been marked as a duplicate of bug 842410 ***


Note You need to log in before you can comment on or make changes to this bug.