Summary: | kdelibs/kdebase/kdepim/kdemultimedia dependency cleanup | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Gregorio Guidi (RETIRED) <greg_g> |
Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | g1gsw |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
kde3.3-deps.patch
Proposed patch to allow optional jack compilation as a dep |
Description
Gregorio Guidi (RETIRED)
2004-07-28 03:31:00 UTC
Created attachment 36312 [details, diff]
kde3.3-deps.patch
reference patch for the above changes
ok, i've implemented some of these in the beta2 ebuilds now so we get some testing done on them. i've bumped kdepim to a new version, the rest stayed the same. going to leave this open until we get all of them resolved. Caleb, just a quick note on kdepim-3.3.0_beta2-r1.ebuild: gpgme should forced to a version >=0.4.5, otherwise the configure check will fail, and GPGME_CONFIG should be set in src_compile() to let kdepim find the right version (0.4 and not 0.3) (see the patch) I also thought whether the dep should be 'gpgme' or '|| (gpgme, gnupg)'. Since gpgme is used in any case (either statically from a private copy or linking the installed one), it makes sense to force gpgme in all cases, and one could even make gpgme a non-conditional dep (removing the crypt use flag). Stricly speaking, it is not 'bloat' as removing the dep on gpgme causes the increase of the size of the kdepim binaries of the amount of the static library. So my suggestion is DEPEND="... >=app-crypt/gpgme-0.4.5" without the crypt use flag. also, from configure.in: "You are missing gpgme 0.4.5 or higher." "Gpgme will be built statically from libkdenetwork/libgpgme-copy." "If you are a packager, we most strongly recommend to build against" "the system's shared gpgme." "Consider downloading gpgme >= 0.4.5 from ftp://ftp.gnupg.org/gcrypt/alpha/gpgme" "or use the --with-gpgme-prefix=/path/where/gpgme/is/installed option." Also I have read the latest gnupg is required 1.9.x or the newly released stable 1.2.5. Don't know precisely... gnupg should come as a dependency of gpgme, and from what I gathered the gpgme ebuild should depend on >=gnupg-1.9 if support for s/mime is requested, or on >=gnupg-1.2 if s/mime is not requested. At the moment the gpgme ebuild does not do that though, I wrote in bug 50681 because of this. Also, in kdepim/configure.in there's NEED_GPG_VERSION=1.2.2 NEED_GPGSM_VERSION=1.9.3 but I don't know what the effect is. GpgMe won't build with gnupg support if you don't: ln -s /usr/bin/gpg2 /usr/bin/gpg after you install >=gnupg-1.9 which results in Kmail not working correctly with some security features. I know this isn't directly related to this bug but it will cause some problems for trying to get this working. bug 56937 mentions this. Another thing I just found. checking for gpgme-config... /usr/bin/gpgme-config checking for GPGME - version >= 0.4.5... no, will use local libgpgme-copy gpgme >= 0.4.5 doesn't install gpg-config, it installs gpg4-config. My gpg-config version here is 0.3.14 and gpg4-config version is 0.4.7, I'm not sure if this affects the build in anyway. Also gpgme-0.9.0 has been released but isn't in portage yet. A lot of infos here: http://bugs.kde.org/show_bug.cgi?id=85009 and here: http://bugs.kde.org/show_bug.cgi?id=83086 so, gnupg should be >= 1.2.5 to avoid a grave bug (thus dep should go in the gpgme ebuild, I think) I've added an ebuild for gpgme-0.9.0 - a copy of 0.4.7 (masked as "-*"). I changed the dep requirement to >=gnupg-1.2.2 (as listed in the package). I added "--with-gpg=/usr/bin/gpg2" so it finds gpg2 if it exists (per comment #6). There seems to be a bug in gpgme-0.9.0 that only looks for the hardcoded "gpg" binary in the mkdemodirs script - it will either need to be "sed'd" or get fixed upstream. I tried filing a bug report upstream but the web site just spit out http errors when i clicked "Submit" I've put in a request with the developer in charge of gnupg to lift the package mask so that we can have gpgme and gnupg install properly, and I can then set it as a kdepim dependency. If someone can put in a bug-request for gnupg-1.2.5 that may be helpful too. Modified kdepim-3.3.0_beta2-r1.ebuild to reflect these latest changes. Will probably push out an -r2 if we get the gnupg/gpgme things fixed before the next kde version rolls out. kdelibs_rc1 now has tiff package use flagged also, removed the runtime python dependency kdebase_rc1 has motif dep removed added a local cdparanoia use flag since it's listed as optional changed multimedia-3.3.0_rc1 to: oggvorbis? ( media-sound/vorbis-tools ) as the tools are required for some functionality, and that pulls in the necessary libogg and libvorbis deps. Thanks for your work Caleb! Final quirks: in kdebase remove `use_with motif` and `use_with encode lame` in kdemultimedia add "use xine || DO_NOT_COMPILE="$DO_NOT_COMPILE xine_artsplugin" somewhere and "`use_with cdparanoia`", too. and there's something new: in rc1 the dependency on trm (and musicbrainz), needed for tagging support in juk, has been changed to libtunepimp (and musicbrainz) ( http://www.musicbrainz.org/products/tunepimp/ ) see here: http://cvs-digest.org/index.php?comment&diff&comment&file=kdemultimedia/juk/trackpickerdialogbase.ui,v&comment&version=1.5 Removed trm dep from kdemultimedia. Will have to look at libtunepimp dep a little later. I noticed this when compiling kdepim: libgnokii (http://www.gnokii.org) is missing. The KDE Addressbook mobile phone import/export filter will not be available. You're missing the pisock library for kpilot. KPILOT: MAL headers or library not found. AvantGo conduit will not be compiled. KPILOT: Download libmal>=0.20 from http://jasonday.home.att.net/code/libmal/ So it looks like we may need some more deps here as well. Just added tunepimp library -> media-libs/tunepimp This will need to become an (optional) dep of kdemultimedia; needs some more testing first though. Thanks for adding tunepimp, a quick review: license should be GPL-2; there should be a block on "media-sound/trm", and media-sound/trm should block media-libs/tunepimp (they both provide /usr/bin/trm); dependency on musicbrainz should be forced to >=2.1.0; and description and homepage should be something like that: DESCRIPTION="Client library to create MusicBrainz enabled tagging applications." HOMEPAGE="http://www.musicbrainz.org/products/tunepimp/" I have another missing kdebase dependency for you, Caleb. ksysguardd depends on lm-sensors, a version bump to libsensors.so.X+1 gives a "Connection to localhost has been lost!" message when opening ksysguard, because ksysguardd segfaults then. workaround: symlink so.X+1 so.X Caleb, thanks a bunch for the great things you are doing for KDE/Gentoo. Just want to let you know that krfb (kdenetwork) now depends on a patched version of rdesktop for remote control of rdp-clients. See http://bugs.gentoo.org/show_bug.cgi?id=58312 for more information. I think this change below will allow all ebuilds using the kde.eclass to now support --with(out)-arts, EXCEPT the 3.2 version of kde itself. -# $Header: /var/cvsroot/gentoo-x86/eclass/kde.eclass,v 1.101 2004/07/27 15:52:25 caleb Exp $ +# $Header: /var/cvsroot/gentoo-x86/eclass/kde.eclass,v 1.102 2004/08/18 18:07:14 caleb Exp $ # # Author Dan Armak <danarmak@gentoo.org> # @@ -88,7 +88,7 @@ kde_src_compile() { else myconf="$myconf --disable-debug --without-debug" fi - [ "$KDEMINORVER" -ge 3 ] && myconf="$myconf `use_with arts`" + [ "$KDEMINORVER" -ne 2 ] && myconf="$myconf `use_with arts`" kde.eclass fix for arts: - [ "$KDEMINORVER" -ne 2 ] && myconf="$myconf `use_with arts`" + [ -z "$KDEBASE" ] && myconf="$myconf $(use_with arts)" + [ -n "$KDEBASE" -a "$KDEMINORVER" -ge 3 ] && myconf="$myconf $(use_with arts)" Created attachment 38257 [details, diff]
Proposed patch to allow optional jack compilation as a dep
This patch allows one to use --disable-jack to turn off jack checking in arts.
Please comment, as I plan to submit it upstream.
Added this patch to portage, with the optional jack use flag. I think everything here was taken into account. Closing. |