Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 361701 - Review Request: konserve - System tray application that performs periodic backups
Summary: Review Request: konserve - System tray application that performs periodic bac...
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-11-01 13:14 UTC by Marcela Mašláňová
Modified: 2009-08-20 21:59 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-08-20 21:59:10 UTC

Attachments (Terms of Use)

Description Marcela Mašláňová 2007-11-01 13:14:44 UTC
Description of problem:
Package review for new package is needed.

Version-Release number of selected component (if applicable):

How reproducible:

Rpmlint: 'symlinks is dangling' lost after installation

Comment 1 Jason Tibbitts 2007-11-03 19:09:36 UTC
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.

Comment 2 Marcela Mašláňová 2007-11-05 08:10:15 UTC
I followed
here is: '1. Put your spec file and SRPM somewhere on the Internet.' nothing
about koji.

Comment 3 Jason Tibbitts 2007-11-05 15:32:11 UTC
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.

Comment 4 Marcela Mašláňová 2007-11-05 15:38:47 UTC
Hups, I believe that I wrote a link :( Sorry

Here it is:

Comment 5 Andy Southgate 2007-11-21 01:17:35 UTC
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 instead?

o  Might as well use the %post and %postun from  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.

Comment 6 Marcela Mašláňová 2007-11-21 09:53:33 UTC
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.

Comment 7 Rex Dieter 2007-11-21 17:05:49 UTC
> 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.

Comment 8 Rex Dieter 2007-11-21 17:14:52 UTC
Lots of little things, so I'll summarize by suggested updated specfile + changelog:


koji scratch build:

* Wed Nov 21 2007 Rex Dieter <rdieter[AT]> - 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).

Comment 9 Marcela Mašláňová 2007-11-22 07:57:50 UTC
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

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

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

Comment 10 Marcela Mašláňová 2008-01-22 11:55:46 UTC
Ping, are we still interested in shipping it into F-9?

Comment 11 Jason Tibbitts 2008-03-02 22:57:06 UTC
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; says:
  The Vendor tag should not be used. It is set automatically by the build system.

Comment 12 Marcela Mašláňová 2008-03-04 13:03:33 UTC
Because I was asking about mentioned things in patch.

If anyone wants to review feel free to take it.

Comment 13 Rex Dieter 2008-03-04 14:51:17 UTC
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:

Comment 14 Marcela Mašláňová 2008-03-26 15:43:02 UTC

Comment 15 Orcan Ogetbil 2008-10-31 21:59:47 UTC
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
in the desktop-file-install and not do this in the patch?

* Please follow the guidelines at
for installation of icons.

Comment 16 Orcan Ogetbil 2009-01-31 06:05:41 UTC
ping? are you still interested in packaging this?

Comment 17 Marcela Mašláňová 2009-02-02 07:07:00 UTC
Yes, I am.

Comment 18 Jason Tibbitts 2009-03-25 20:33:41 UTC
If you're still interested in packaging this, perhaps you could produce an updated package addressing the observations Orcan made in comment #15.

Comment 19 Jason Tibbitts 2009-07-17 22:51:09 UTC
No updated package after nearly four months.  I guess I'll close this soon if there's no further progress.

Comment 20 Ben Boeckel 2009-08-10 05:06:51 UTC
@Jason: There hasn't been a release since 2004[1] and upstream seems dead (no public repo on[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.


Comment 21 Jason Tibbitts 2009-08-20 21:59:10 UTC
It's been many months now with no response; I'm closing this out.

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