Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 171268
Summary: | Review Request: kdissert | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Konstantin Ryabitsev <icon> | ||||
Component: | Package Review | Assignee: | Adrian Reber <adrian> | ||||
Status: | CLOSED NEXTRELEASE | QA Contact: | David Lawrence <dkl> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | CC: | fedora-extras-list | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
URL: | http://freehackers.org/~tnagy/kdissert/ | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2005-10-29 16:19:49 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 163779 | ||||||
Attachments: |
|
Description
Konstantin Ryabitsev
2005-10-20 06:49:37 UTC
Any special reason for installing the .desktop file into the kde sub-directory of .../applications? I have not seen this in any other FE package. I don't really care just wanted to know if there is a special reason for this? Created attachment 120184 [details]
Spec changes
The icon does not have to be copied to the pixmap directory if it is only for
the menu entry. To see the icon I have added the gtk-update-icon-cache to the
scripts and as the desktop file has a mime type entry the desktop database is
also updated in the scriptlets.
I just saw that the patch has to be applied with -R. Sorry. Hi, Adrian: The .desktop file is where the upstream installs it. I've checked with the stuff in core, and there's quite a few KDE-related .desktop files in the kde subdir or applications, so it seems it's a common thing. It doesn't interfere with the way the application works, so I have left the way it is. Thanks for the patch, it's been applied. See: http://linux.duke.edu/~icon/misc/fe/kdissert.spec http://linux.duke.edu/~icon/misc/fe/kdissert-1.0.5-0.2.fc4.src.rpm rpmlint complains about rpath. Can be removed with sed -i -e "/env.KDEuse(\"environ rpath\")/d" SConstruct before calling scons Nice. Done! Same place: http://linux.duke.edu/~icon/misc/fe/ md5sum of the tarball in the SRPM and the upstream tarball do not match. According to diff the content seems to be same. md5sum downloaded: 18ff5d04d633cf3b4e3fbf869c18dd2f kdissert-1.0.5.tar.bz2 md5sum from SRPM: c0a4ff4de929bfcc9bf80f7f58c5b4fe kdissert-1.0.5.tar.bz2 Could you make a new version of the SRPM with the new tarball? Hmm... This is odd. I recall distinctly checking the md5sum of the tarball before packaging it. It's on my packaging checklist. I'll email the maintainers to see what's up. From the author: -- Checksum should be 18ff5d04d633cf3b4e3fbf869c18dd2f There was a mistake in the archive (documentation installation) so the tarball was updated some time after. -- I've updated the SRPM to contain the matching tarball. See: http://linux.duke.edu/~icon/misc/fe/ - MUST: Packages must NOT contain any .la libtool archives, these should be removed in the spec. $ rpm -ql kdissert | grep la$ /usr/lib/kde3/libkdissOOOdoc.la /usr/lib/kde3/libkdissOOOimpress.la /usr/lib/kde3/libkdissapplet.la /usr/lib/kde3/libkdissasciidoc.la /usr/lib/kde3/libkdissbeamerslides.la /usr/lib/kde3/libkdisshtmldoc.la /usr/lib/kde3/libkdisspdflatexarticle.la /usr/lib/kde3/libkdisspdflatexbook.la /usr/lib/kde3/libkdissprosperslides.la /usr/lib/kde3/libkdissstx.la Seeing the .la discussions all the time you should probably remove these files. It doesn't work without them. Try it. When .la files are removed, exporting tools break. Yes, after further investigation, making it not require .la files for exporting plugins would require patching and be generally counter-productive, since it would diverge from upstream. I think the opposition to .la files is only when they are included as part of -devel packages (and thus never used), not when they are required for program functioning during runtime. * rpmlint is happy * builds in mock * clean installation and removal * spec looks good * scripts are sane * works as expected * source matches upstream * the .la files are required during runtime and therefore no blocker APPROVED > It doesn't work without them. Try it. When .la files are removed, exporting
> tools break.
Is this true of FC5 too?
I'm pretty sure. I've tried playing around to patch the requirement for .la files out, but opening .so files didn't work, potentially because of a bug in KDE (i.e. when you tell it to dlopen "libfoo", it will look for libfoo.la, and ignore libfoo.so. If you specifically instruct to open "libfoo.so", it will fail because it will tell that "init_libfoo.so not found", though it should have been trying to find "init_libfoo" in the .so file as well. It's possible that I'm just dumb. I'm not a C++/KDE programmer). Thanks, Adrian! |