Summary: | app-crypt/kth-krb-1.2.2-r2 won't compile | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Michael Cramer <portage> |
Component: | [OLD] Library | Assignee: | Gentoo Kerberos Maintainers <kerberos> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | jakub, jesse, mmokrejs, paluszak, tim |
Priority: | Highest | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 173354 |
Description
Michael Cramer
2005-12-23 02:39:49 UTC
I believe that is because somebody should finally push in kth-krb-1.3 version eithe rthe snapshot or directly from cvs. The development is stopped, but most importantly, branch 1.3 added support for openssl-0.9.7. kth-krb-1.2.2 may coexist only with openssl-0.9.6 or older. Signore Giaquinta, please do have a look at these bugs. Bump! Openssl-0.9.7 got unmasked and kth-krb-1.2.2 (the only one kth-krb unmasked) does not compile. Hmm... bug opened in December of 2005, and this problem still exists? I'm getting bitten by this - can we get a version bump to STABLE, please? Thanks. FYI, kth-krb4-1.3 is still only as a release candidate. But I think actually a CVS dump of that branch would be the best choice. The development of krb4 has been stopped. And, don't expect xscreensaver to accept your krb4 password unless you provide a patch to fix the possibly simple issue. Upstream has dropped that from support and Gentoo package maintainers stick to that. See some of the closed bugreports on this if you are interested. Although I am not arguing that kth-krb-1.3-cvs or -rc should be in portage you should probably soon convert to heimdal, which offers the krb4 servces in addition to krb5 interface. As I can see from the heimdal ebuild, krb4 support is only provided when compiled against kth-krb... So how can I get rid of kth-krb by switching to heimdal??? Any suggestions? 1. Migrate the passwords: http://www.pdc.kth.se/heimdal/heimdal.html#Migration This might not be trivial so read posts in the archives of krb4@sics.se and heimdal-discuss@sics.se from people who did the same. If you have few users, maybe rather create the password database from scratch. ;) 2. Shutdown kth-krb4 3. Recompile your apps to use heimdal (use the "kerberos" USE flag) 3. If things work, remove the the "krb4" USE flag and 'emerge -uN world'. *** Bug 148168 has been marked as a duplicate of this bug. *** So, does 1.3_rc1 work for people here, or? The current stable ebuild is completely useless. I tried 1.3_rc1, but ran into file collision like in bug #117209. So in my opinion this ebuild is not a choice as well... At the moment, I try to switch to heimdal like proposed by Martin in comment #7. If it is possible to get rid of kth-krb, then do so. Just my few cents... The only sane choice is to upgrade to a krb5 system; every krb4 implementation is now unsupported by the corresponding upstream. We are the only one afaik to provide kth-krb. Every ebuild in the tree with a krb4 use flag has also a kerberos one (with the exception of xscreensaver), so the application support is not a blocker (if there is a problem open a bug please). My plan is to deprecate the krb4 use flag and after an adeguate period of time remove this app from the tree. For more information read here: http://web.mit.edu/Kerberos/krb4-end-of-life.html Still, the 1.3-rc candidate should be made available, even at the cost of no manapges being installed. (In reply to comment #12) > Still, the 1.3-rc candidate should be made available, even at the cost of no > manapges being installed. It's already in the tree, don't see what you mean here... I've switched successfully to heimdal and don't need this package anymore. I am outta here, thanks for your help, guys :) Sorry, I did not have a look for that. I tried to emerge it and it complied successfully against
# openssl
OpenSSL> version
OpenSSL 0.9.8c 05 Sep 2006
OpenSSL> quit
I have seen the following message, but the chmod go-r seems to be correct to me.
The suggested step to recompile again ... I don't know what does that really say. Anyway, I use heimdal so it is not an issue for me.
QA Notice: the following files are setXid, dyn linked, and using lazy bindings
This combination is generally discouraged. Try re-emerging the package:
LDFLAGS='-Wl,-z,now' emerge kth-krb
LAZY usr/athena/bin/rsh
LAZY usr/athena/bin/rcp
LAZY usr/athena/bin/rlogin
LAZY usr/athena/bin/su
LAZY usr/athena/bin/otp
>>> Merging app-crypt/kth-krb-1.3_rc1 to /
* >>> SetUID: [chmod go-r] /var/tmp/portage/kth-krb-1.3_rc1/image//usr/athena/bin/rsh ... [ ok ]
* >>> SetUID: [chmod go-r] /var/tmp/portage/kth-krb-1.3_rc1/image//usr/athena/bin/rcp ... [ ok ]
* >>> SetUID: [chmod go-r] /var/tmp/portage/kth-krb-1.3_rc1/image//usr/athena/bin/rlogin ... [ ok ]
* >>> SetUID: [chmod go-r] /var/tmp/portage/kth-krb-1.3_rc1/image//usr/athena/bin/su ... [ ok ]
* >>> SetUID: [chmod go-r] /var/tmp/portage/kth-krb-1.3_rc1/image//usr/athena/bin/otp ... [ ok ]
(In reply to comment #11) > The only sane choice is to upgrade to a krb5 system; every krb4 implementation > is now unsupported by the corresponding upstream. We are the only one afaik to > provide kth-krb. Don't forget that Heimdal seems to need kth-krb to construct the proper AFS stubs for transparent AFS support in Heimdal. Without it pam_krb5+afs fails to aquire AFS tokens. Though this is likely a failure on pam_krb5's part in assuming the need for krb4 support. (In reply to comment #16) > Don't forget that Heimdal seems to need kth-krb to construct the proper AFS > stubs for transparent AFS support in Heimdal. Without it pam_krb5+afs fails to > aquire AFS tokens. Though this is likely a failure on pam_krb5's part in > assuming the need for krb4 support. Correction, this is a failure of the pam_krb5 version number conflict. pam_krb5-2.2.6 works correctly with heimdal w/out kth-krb. Unfortunately there exists a pam_krb5-2003* ebuild that takes priority over 2.2.6 even though it is for a completely different package and requires kth-krb. Pushing pam_krb5-2.2.6 as stable resolves the pam_krb5 dependancy on kth-krb. krb4 masked on sparc, it's time to move on. (In reply to comment #18) > krb4 masked on sparc, it's time to move on. > I think the USE flag for krb4 should be removed for x86 since it won't compile against the latest packages anyways. I made the simple mistake of adding it to my USE flags and it prevented me from compiling packages. removed from portage |