Spec URL: http://beta.glwb.info/kdirstat/kdirstat.spec SRPM URL: http://beta.glwb.info/kdirstat/kdirstat-2.5.3-1.src.rpm Description: KDirStat (KDE Directory Statistics) is a utility program that sums up disk usage for directory trees - very much like the Unix 'du' command. It can also help you clean up used space.
chitlesh(i386)[0]$rpmlint -i kdirstat-2.5.3-1.i386.rpm W: kdirstat symlink-should-be-relative /usr/share/doc/HTML/en/kdirstat/common /usr/share/doc/HTML/en/common I don't know exactly what should be done here. chitlesh(i386)[0]$rpmlint -I symlink-should-be-relative symlink-should-be-relative : No output. Ive filed a bug against rpmlint https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196008
Chitlesh, It seems that you misunderstand the sponsoring process. You've already been sponsored by me for knetstats and you only need to be sponsored once. So now this is a regular review request which can be done by any FE packager. Resetting the blocker bug to FE-NEW. I'll get back to you on your rpmlint issues when I find the time. You'll probably have to find someone else todo the review though I'm rather busy at the moment.
(In reply to comment #1) > chitlesh(i386)[0]$rpmlint -i kdirstat-2.5.3-1.i386.rpm > W: kdirstat symlink-should-be-relative /usr/share/doc/HTML/en/kdirstat/common > /usr/share/doc/HTML/en/common > > I don't know exactly what should be done here. The error message is fairly self-explanatory. You have a symlink that points to an absolute location (/usr/share/doc/HTML/en/common) rather than a relative one (../common). Absolute symlinks should be avoided as they don't work as intended in chroot-ed environments such as the anaconda installer. You can fix it in %install at some point after doing "make install": # Fix absolute symlink rm -f $RPM_BUILD_ROOT%{_docdir}/HTML/en/kdirstat/common ln -s ../common $RPM_BUILD_ROOT%{_docdir}/HTML/en/kdirstat/common
Thanks Paul, Updated: Spec URL: http://beta.glwb.info/kdirstat/kdirstat.spec SRPM URL: http://beta.glwb.info/kdirstat/kdirstat-2.5.3-2.src.rpm
Regarding absolute vs relative symlinks, see http://rpmlint.zarb.org/cgi-bin/trac.cgi/ticket/25 (and feel free to comment on it to bug 196008 too)
I don't like your dependency on /usr/share/doc/HTML/en/common; it might not work the way you expect. Your library dependencies will pull in kdelibs, which will provide that directory, so there's no need to depend on it. Technically you don't need to own /usr/share/apps/kconf_update either, because kdelibs owns it, but most kde applications seem to own that directory so I don't see a problem with it. You have post and postun requirements for desktop-file-utils but you don't call desktop-file-install either in %post or %postun. You should just remove them. So two blockers that I see. Review: * package meets naming and packaging guidelines. * specfile is properly named, is cleanly written and uses macros consistently. * dist tag is present. * build root is correct. * license field matches the actual license. * license is open source-compatible. License text included in package. * source files match upstream: 58dd06602bed70936ece233bd8c32f2a kdirstat-2.5.3.tar.bz2 * latest version is being packaged. * BuildRequires are proper. * package builds in mock (development, x86_64). * rpmlint is silent. X final provides and requires are sane: kdirstat = 2.5.3-2.fc6 = /bin/sh /usr/bin/perl X /usr/share/doc/HTML/en/common desktop-file-utils libDCOP.so.4()(64bit) libICE.so.6()(64bit) libSM.so.6()(64bit) libX11.so.6()(64bit) libXext.so.6()(64bit) libXrender.so.1()(64bit) libacl.so.1()(64bit) libart_lgpl_2.so.2()(64bit) libattr.so.1()(64bit) libfam.so.0()(64bit) libidn.so.11()(64bit) libkdecore.so.4()(64bit) libkdefx.so.4()(64bit) libkdesu.so.4()(64bit) libkdeui.so.4()(64bit) libkio.so.4()(64bit) libkwalletclient.so.1()(64bit) libpng12.so.0()(64bit) libqt-mt.so.3()(64bit) libutil.so.1()(64bit) libz.so.1()(64bit) perl(Encode) perl(English) perl(Fcntl) perl(Getopt::Std) perl(URI::Escape) perl(strict) perl(vars) no shared libraries are present. * package is not relocatable. * owns the directories it creates. * doesn't own any directories it shouldn't. * no duplicates in %files. * file permissions are appropriate. * %clean is present. * %check is not present; no test suite upstream. * scriptlets present are OK (gtk-update-icon-cache) * code, not content. * documentation is small, so no -docs subpackage is necessary. * %docs are not necessary for the proper functioning of the package. * no headers. * no pkgconfig files. * no libtool .la droppings. * GUI app; .desktop file looks OK and is installed properly.
(In reply to comment #6) > I don't like your dependency on /usr/share/doc/HTML/en/common; it might not work the way you expect. Your library dependencies will pull in kdelibs, which will provide that directory, so there's no need to depend on it. I did that to solve a dangling-symlink: W: kdirstat dangling-relative-symlink /usr/share/doc/HTML/en/kdirstat/common ../common The relative symbolic link points nowhere And I was just following a similar issue i've encountered before, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193929#c15 Do you have a better solution for this ? > Technically you don't need to own /usr/share/apps/kconf_update either, because > kdelibs owns it, but most kde applications seem to own that directory so I don't see a problem with it. > here kconf_update contains fix_move_to_trash_bin.pl and kdirstat.upd perharps I should rather do %{_datadir}/apps/kconf_update/* instead of %{_datadir}/apps/kconf_update > You have post and postun requirements for desktop-file-utils but you don't call > desktop-file-install either in %post or %postun. You should just remove them. > I've dropped them.
Dangling symlinks to files in packages which you depend on are fine (as long as they're relative symlinks, of course). As for the kconf_update directory, I think not owning it is cleaner but this doesn't seem to be a blocker as there is a long tradition of applications owning this directory.
> As for the kconf_update directory, I think not owning it is cleaner but this > doesn't seem to be a blocker as there is a long tradition of applications owning > this directory. IMO, apps shouldn't own this dir (including kdirstat), only core kde pkgs (and probably only kdelibs at that). If anything else does own it, it's a bug.
Updated: Spec URL: http://beta.glwb.info/kdirstat/kdirstat.spec SRPM URL: http://beta.glwb.info/kdirstat/kdirstat-2.5.3-3.src.rpm I ignored the warning: chitlesh(i386)[0]$rpmlint -i kdirstat-2.5.3-3.i386.rpm W: kdirstat dangling-relative-symlink /usr/share/doc/HTML/en/kdirstat/common ../common The relative symbolic link points nowhere.
The issues I saw are fixed: %_docdir/HTML/en/kdirstat/common is no longer a dependency. %{_datadir}/apps/kconf_update/ is no longer owned. The two errant Requires(*) are gone. The new rpmlint warning is safe to ignore; %_docdir/HTML/en/common is owned by kdelibs, which is a dependency (via libkdecore.so.4). APPROVED
This has been in the repo for several days now; any reason this bug hasn't been closed?