Bug 361701

I'm missing something here.  Where is the package to be reviewed?  Please
provide links to the specfile and source rpm, and if you can, links to a koji
scratch build and the output of rpmlint run over your source and binary packages.

I followed
http://fedoraproject.org/wiki/PackageReviewProcess
here is: '1. Put your spec file and SRPM somewhere on the Internet.' nothing
about koji.

Well, it helps if you tell us where.  So I'll say again: please post links to
your SRPM and your spec.

Koji and rpmlint are just a matter of courtesy.  If you don't want a speedy
review, well, then feel free to ignore courtesy.  I mean, you must have already
done those things, but a reviewer will have to spend time to do them.  There are
840 packages in the review queue.  I'll let you work out the implications.

Hups, I believe that I wrote a link :( Sorry

Here it is: http://mmaslano.fedorapeople.org/konserve/SRPMS/

This is a pre-review as part of my own quest for sponsorship, so feel free to 
ignore it.  Points are:

o  I've dug your .spec file out of the SRPM, but it's handy to have it 
available for separate download.

o  Your source RPM doesn't rebuild using mock ( mock 
konserve-0.10.3-1.fc8.src.rpm ).  It attempts to re-run autoconf, which isn't 
listed as a BuildRequires.  Might be a timestamp problem or a side effect of 
the perl processing of configure.

o  rpmlint konserve-0.10.3-1.fc8.src.rpm
konserve.src: W: mixed-use-of-spaces-and-tabs (spaces: line 54, tab: line 1)

o  rpmlint konserve-0.10.3-1.fc7.i386.rpm
konserve.i386: W: 
dangling-relative-symlink /usr/share/doc/HTML/en/konserve/common ../common
Looks like a problem in the HTML_DIR processing creating a symlink to symlink

o  Your source lists specifies the Kent mirror.  What about 
http://downloads.sourceforge.net/konserve/konserve-0.10.3.tar.gz instead?

o  Might as well use the %post and %postun from 
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets.  No need to call 
gtk-update-icon-cache for locolor.

o  Supply a vendor for the .desktop file, e.g. fedora.

o  There's lots of weirdness in the installed .desktop file.

o  Description: accidently instead of incidently?

o  Consider keeping timestamps, e.g. make DESTDIR=%{buildroot} 
INSTALL="install -p" CPPROG="cp -p" install

Apart from that, this package does build, install and run.

Thanks for pre-review. 

Everything fixed only these problems stay:
 - dangling-relative-symlink /usr/share/doc/HTML/en/konserve/common ../common
 I don't know if it could stay as it is.
 -  Consider keeping timestamps
 I used install -p, not sure if it's enough.

> dangling-relative-symlink /usr/share/doc/HTML/en/konserve/common ../common

Tis ok, the target (/usr/share/doc/HTML/en/common) is (should be!) owned by
kdelibs.  Most/all kde apps have this.

I'll offer some more suggestions/fixes in a bit.

Lots of little things, so I'll summarize by suggested updated specfile + changelog:

SPEC URL: http://kdeforge.unl.edu/apt/kde-redhat/SOURCES/konserve/konserve.spec

koji scratch build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=253062

%changelog
* Wed Nov 21 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 0.10.3-2
- fix icon scriptlets
- cleanup %%build (QTDIR handling)
- cleanup %%install (properly set/use INSTALL="install -p")
- cleanup d-f-i usage
- BR: gettext
- BR: automake libtool (some auto* breakage here still)
- omit "for KDE" from summary/description (is/should-be usable anywhere)

(still not sure if the 'install -p' thing is worth the extra hassle, but hey).

I'm not sure with: gtk-update-icon-cache. In packaging guideline is 'For KDE,
just 'touch'ing the top-level icon directory is enough.' So I'm not sure what's
correct.

I'm also not decided what to do with timestamps '-p option' in install.

And finally why we don't have fedora in vendor?

Ping, are we still interested in shipping it into F-9?

Why is this ticket set NEEDINFO?  Rex has not signed on to review it, although I
guess he or someone else might do so if you provided an updated package.

As for Vendor, why not read the packaging guidelines;
http://fedoraproject.org/wiki/Packaging/Guidelines says:
  The Vendor tag should not be used. It is set automatically by the build system.

Because I was asking about mentioned things in patch.

If anyone wants to review feel free to take it. 

http://mmaslano.fedorapeople.org/konserve/

Fwiw, 
1. re gtk-update-icon-cache, yes it *is*  needed.  The guidelines say that a kde
desktop doesn't need this, but installing/using in gnome without it would lead
to performance degredation due to the stale icon cache.

2.  re: install -p.  If it cannot be demonstrated to be required, don't use it.

3.  re: vendor.  Not sure what you're asking here.  desktop-file vendor?  See:
http://fedoraproject.org/wiki/Packaging/Guidelines#head-d559ee7363418a5840ce63090c608c991cd39ce6

Done.
http://mmaslano.fedorapeople.org/konserve/

This package needs some more work. Here are my notes:

* The license should be GPLv2+ and GFDL. The file doc/konserve/index.docbook claims GFDL license for the documentation of the software. But I can't find the text of GFDL inside the tarball. Can you contact upstream to ask for including the text of GFDL in the tarball?

* The files AUTHORS, COPYING and ChangeLog must be in %doc

* Can you name the patches konserve-xxx.patch ? Also an explanation in the SPEC file about what each of them does would be nice. The patches should also be submitted upstream (unless they are very Fedora specific) and the links from their bug tracking system should be put in the SPEC file.

* I don't think you need BR: libtool

* Fedora specific compilation flags are getting overridden. This needs fixed.

* --vendor="fedora" should be removed from new packages according to the new guidelines.

* You are already patching the desktop file. Why are you using an
   --add-category="System"
in the desktop-file-install and not do this in the patch?

* Please follow the guidelines at
   http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#GTK.2B_icon_cache
for installation of icons.

ping? are you still interested in packaging this?

Yes, I am.

If you're still interested in packaging this, perhaps you could produce an updated package addressing the observations Orcan made in comment #15.

No updated package after nearly four months.  I guess I'll close this soon if there's no further progress.

@Jason: There hasn't been a release since 2004[1] and upstream seems dead (no public repo on sf.net[2], nor one ont he webpage to be able to really tell). It's also KDE3-based which is unmaintained, so its future is bleak.

@Marcela: If you're still interested in packaging this, please respond.

[1]http://sourceforge.net/projects/konserve/files/
[2]http://konserve.cvs.sourceforge.net/konserve

It's been many months now with no response; I'm closing this out.