Bugzilla Bug 185899

Heimdal version 1.0 is out.  0.7.2 is the latest in the tree.  This update is
important because it adds support for NTLM, SPNEGO stuff, and PKINIT (great for
smartcard users).  KCM is also a nice feature.

Reproducible: Always

Created an attachment (id=125369) [details]
heimdal-1.0.ebuild

Ebuild, tested on x86 - note that this DOESN'T address any of the
heimdal-prefix-changing stuff going on in other bugs.  I agree that symlinks in
/usr/include need to be altered or heimdal should be moved to a new prefix, but
this ebuild works for me (although cyrus-sasl won't build against it unless
you're clever with those symlinks - hint: try ln -s heimdal/gssapi gssapi and
ln -s gssapi/gssapi.h gssapi.h, then link the things it complains about).

*** Bug 152460 has been marked as a duplicate of this bug. ***

Created an attachment (id=125370) [details]
heimdal-1.0-gentoo-patches-0.1.tar.bz2

Some patches were included/fixed upstream, and this adds a heimdal-kcm init
script.  By the way, the ebuild gets rid of the sample password checker as it's
broken.

Thanks!

I had some trouble switching from mit-krb5 to heimdal-1.0 using this ebuild.
It seems that app-crypt/libgssapi conflict with heimdal. What I had to do was
emerge -C mit-krb5 and libgssapi, emerge heimdal, then revdep-rebuild (which
recompiled samba, openssh, gnome-vfs and other things).

please add a !app-crypt/libgssapi to the DEPEND to specify that it conflicts.

I haven't actually USED it yet :) but it compiled and seems to work except for
nfs-utils which I had to set USE=-kerberos for to make even compile... Now
that's not a big problem for me since I don't use nfs here but I guess it's a
showstopper for many..

(In reply to comment #4)
> Thanks!
> 
> I had some trouble switching from mit-krb5 to heimdal-1.0 using this ebuild.
> It seems that app-crypt/libgssapi conflict with heimdal. What I had to do was
> emerge -C mit-krb5 and libgssapi, emerge heimdal, then revdep-rebuild (which
> recompiled samba, openssh, gnome-vfs and other things).
> 
> please add a !app-crypt/libgssapi to the DEPEND to specify that it conflicts.
> 
> I haven't actually USED it yet :) but it compiled and seems to work except for
> nfs-utils which I had to set USE=-kerberos for to make even compile... Now
> that's not a big problem for me since I don't use nfs here but I guess it's a
> showstopper for many..
> 

On my portage tree, nfs-utils is marked as explicitly depending on mit-krb5 and
libgssapi when USE=kerberos.  So unless you explicitly edited the ebuild, you
shouldn't have been able to get a compile-time failure.

I'll take a look at compiling nfs-utils against Heimdal 1.0; I never used
kerberized NFS because I use OpenAFS instead.

Thanks for the heads-up on libgssapi conflicts - Heimdal doesn't need that
library as it has all its functionality and more integrated already (NTLM
support, etc).

(In reply to comment #5)
> On my portage tree, nfs-utils is marked as explicitly depending on mit-krb5
> and libgssapi when USE=kerberos.  So unless you explicitly edited the ebuild,
> you shouldn't have been able to get a compile-time failure.

nfs-utils depends on mit-krb5, but libgssapi doesn't, so you can still break
your system by simply emerging libgssapi for any reason like e.g. trying to
compile nsf-utils manually, using other gssapi mechanisms, because of switched
kerberos implementation, or whatever.

> I'll take a look at compiling nfs-utils against Heimdal 1.0; I never used
> kerberized NFS because I use OpenAFS instead.

Cross reference: bug 134064 comment 15 and following

> Thanks for the heads-up on libgssapi conflicts - Heimdal doesn't need that
> library as it has all its functionality and more integrated already (NTLM
> support, etc).

The libgssapi conflict is not new, I reported bug 168509 for it. It has
implications on nss_ldap using gssapi as well, so it's not only nfs affected.

If Heimdal doesn't need this library, what does this mean for programs that
currently link against the libgssapi from heimdal? Should they link against
some other library from the heimdal installation, or should depend on and link
against the libgssapi used for nfs?

(In reply to comment #6)

I was wrong - nfs-utils does require libgssapi's libgssapi.so.2.  I'm pretty
sure that the functionality it uses is present in Heimdal too, but the code
isn't written to make use of it.

I've just thrown together a Heimdal 1.0 build that installs libs to
/usr/heimdal/lib and includes to /usr/heimdal/include (as well as setting
prefix to /usr so krb5-config --prefix works).  I was able to build cyrus-sasl
and openssh against the newly located Heimdal without trouble after adding
/etc/env.d/heimdal with an extra line for /etc/ld.so.conf.

It seems that nfs-utils' check for Kerberos versions is actually broken -
something's wrong with aclocal/kerberos5.m4 which I couldn't figure out.  But
I've got a patch that hacks around it.  But that doesn't solve the problem of
needing to use /usr/lib/libgssapi.so.2 for nfs-utils and
/usr/heimdal/lib/libgssapi.so.2 for everything else, while still letting
nfs-utils make use of Heimdal's other libraries.

Maybe we should compile nfs statically?  Is that too extreme?

(In reply to comment #7)

Oh, so the heimdal libgssapi.so changed version number from 4 to 2. That's even
worse than before, where a simple change of a symlink was enough to fix many
issues.

http://www.mail-archive.com/heimdal-discuss@sics.se/msg00392.html seems
important. It states that
1. libgssapi.so should support multiple GSSAPI mechanisms, not only Kerberos
2. app-crypt/libgssapi does so, and can link against libgssapi.so from heimdal

If the libgssapi.so from heimdal-1.0 supports other methods as well, it should
be possible to use that as a replacement for app-crypt/libgssapi and also link
nfs-utils against it. As you say this was not possible, I assume the heimdal
libgssapi.so does not provide support for other mechanisms.

I would assume the best solution should be to have all applications linked
against app-crypt/libgssapi and to have that use the heimdal implementation if
the kerberos method of gssapi is requested.

I guess in that case we'd have to make the new heimdal ebuild depend on
app-crypt/libgssapi in some way, probably PDEPEND. That way there will always
be a libgssapi.so available for other programs to link against. Or we could add
that dependency to all ebuilds currently depending on heimdal. Of course some
checks would be needed to find out whether all kerberized programs accept this
version of the library, or whether some require heimdal-specific stuff.

(In reply to comment #8)
> (In reply to comment #7)
> 
> Oh, so the heimdal libgssapi.so changed version number from 4 to 2. That's even
> worse than before, where a simple change of a symlink was enough to fix many
> issues.
> 
> http://www.mail-archive.com/heimdal-discuss@sics.se/msg00392.html seems
> important. It states that
> 1. libgssapi.so should support multiple GSSAPI mechanisms, not only Kerberos
> 2. app-crypt/libgssapi does so, and can link against libgssapi.so from heimdal
> 
> If the libgssapi.so from heimdal-1.0 supports other methods as well, it should
> be possible to use that as a replacement for app-crypt/libgssapi and also link
> nfs-utils against it. As you say this was not possible, I assume the heimdal
> libgssapi.so does not provide support for other mechanisms.
> 
> I would assume the best solution should be to have all applications linked
> against app-crypt/libgssapi and to have that use the heimdal implementation if
> the kerberos method of gssapi is requested.
> 
> I guess in that case we'd have to make the new heimdal ebuild depend on
> app-crypt/libgssapi in some way, probably PDEPEND. That way there will always
> be a libgssapi.so available for other programs to link against. Or we could add
> that dependency to all ebuilds currently depending on heimdal. Of course some
> checks would be needed to find out whether all kerberized programs accept this
> version of the library, or whether some require heimdal-specific stuff.
> 

No, Heimdal DOES implement three mechanisms: spnego, krb5, and ntlm.

libgssapi itself does nothing except call the appropriate sub-library.  But
nfs-utils uses symbols which are present in libgssapi and not in heimdal,
precluding linking it directly against heimdal.

The issue is that, having two libgssapi.so.2 libraries installer, I don't know
a way to have programs linked against libssapi in /usr/lib and the rest of
heimdal in /usr/heimdal/lib.  /usr/lib is one of the "trusted" directories in
LDPATH and so always comes after the things in ld.so.conf.  Also, I'm not sure
apps currently linked against Heimdal will work if libgssapi comes first in
their library search path.

I think the solution may be to pull libgssapi into the nfs-utils ebuild and
statically link the one NFS binary that depends on it.  That was nfs-utils can
contain its custom gssapi stuff and there will be only one libgssapi.so.2.

Created an attachment (id=125797) [details]
heimdal-1.0.ebuild

New Heimdal ebuild - harder better faster stronger.

Created an attachment (id=125799) [details]
force_inclusion_by_path.patch

Makes a minor change to gssapi.h to prevent weirdness when building nfs-utils
against CITI libgssapi and heimdal.

Created an attachment (id=125865) [details]
Alternative heimdal-1.0.ebuild

Before finding this bug, I've successfully installed heimdal-1.0.ebuild adapted
from those of Harald Barth
http://www.pdc.kth.se/~haba/gentoo-stuff/portage/app-crypt/heimdal/ (see Bug
#134064). It does not require so many patches -- any suggestion of tests to
check my installation if it actually works?

(In reply to comment #12)
Harald Barth's practice is to install heimdal into a directory separate from
the main system tree. Information needed to compile all the dependend packages
is provided by krb5-config script, a standard part of the heimdal distribution.
If packages using kerberos do not use that script in their configure scripts,
their ebuilds have to be adapted to use it.

I've added the patch for the net-mail/fetchmail-6.3.8 ebuild to Bug #185652

(In reply to comment #12)
Patch for gnome-extra/evolution-data-server-1.10.2 ebuild filed as Bug #186509

(In reply to comment #10)
I've noticed two issues for this build, because ebuilds don't use krb5-config
and thus don't find the needed kerberos headers.

dev-db/postgresql-8.2.4-r1:
configure: error: header file <krb5.h> is required for Kerberos 5

sys-auth/nss_ldap-254: (looks like bug 165638 but it is a different cause here)
ldap-nss.c:1891: error: ‘GSS_S_COMPLETE’ undeclared (first use in this
function)

There are probably more ebuilds. Is there some systematic check going on or
planned, or should I continue to report issues as I experience them?

(In reply to comment #15)
> (In reply to comment #10)
> I've noticed two issues for this build, because ebuilds don't use krb5-config
> and thus don't find the needed kerberos headers.
> 
> dev-db/postgresql-8.2.4-r1:
> configure: error: header file <krb5.h> is required for Kerberos 5
> 
> sys-auth/nss_ldap-254: (looks like bug 165638 but it is a different cause here)
> ldap-nss.c:1891: error: ‘GSS_S_COMPLETE’ undeclared (first use in this
> function)
> 
> There are probably more ebuilds. Is there some systematic check going on or
> planned, or should I continue to report issues as I experience them?
> 

vapier feels strongly that pkg-config is superior to krb5-config (and I agree
with him).  Heimdal is moving to pkg-config.

I fixed nss_ldap on my end by adding --with-gssapi-dir=foo.

Created an attachment (id=126059) [details]
heimdal-1.0-1.0.1_rc1.ebuild.diff

Basically the heimdal-1.0.ebuild by Bryan Jacobs (needs renaming the tar.bz2
patchset from 1.0 version to 1.0.1_rc1).

Several commented out lines removed. Hacky simlinks for SASL checks commented
out in favor of changing of problematic ebuilds to use krb5-config. Install
dirs manipulated to avoid, hopefully, clashes with other packages like
app-crypt/libgssapi (in case having the GSSAPI wrapper library around proves to
be useful).

Creation of .pc files for pkg-config attempted, but all the packages using
hardcoded kerberos path will have to be modified anyway.

(In reply to comment #16)

I've started modifying all the ebuilds I install to use krb5-config and
reporting appropriate bugs for such changes. Of course it's far from a
systematic check of the whole portage tree. I just try installing what I want,
and if it fails complaining about some kerberos header or library not found, I
try to introduce krb5-config into its configuration.

At the Bug #185509 I've been scolded heavily for using krb5-config, which is
inferior to pkg-config. That's why I've tried to modify the heimdal ebuild to
create .pc files for pkg-config; but now I'm not sure not only of their
correctness, but even less of the proper way to introduce pkg-config usage into
the dependent ebuilds.

(In reply to comment #18)
> At the Bug #185509 

Not Bug #185509, but Bug #186509 -- excuse, please, my typo.

Created an attachment (id=126114) [details]
heimdal-1.0-0.8.1-r1.ebuild.diff

Bryan Jacobs' 1.0 ebuild changed to install into /usr/heimdal. bin and sbin
directories contents symlinked into the system /usr/bin and /usr/sbin; name
changes (telnet->ktelnet etc.) done only to the symlinks (in case some package
looks for the binaries inside the heimdal subtree under the original names).
Creation of .pc files for pkg-config attempted.

The patchset slightly modified for 0.8.1: 010_all_heimdal-system-libss.patch
adapted to the elder lib/sl/Makefile.am and inside 012_all_heimdal-berkdb.patch
changed the location of ndbm_wrap.c to the elder path lib/otp/ndbm_wrap.c.
Otherwise the ebuild applies to newer heimdal versions as well; release
candidates require

 HOMEPAGE="http://www.pdc.kth.se/heimdal/"
-SRC_URI="ftp://ftp.pdc.kth.se/pub/heimdal/src/${P/_rc/rc}.tar.gz
+SRC_URI="ftp://ftp.pdc.kth.se/pub/heimdal/src/snapshots/${P/_rc/rc}.tar.gz
     http://dev.gentoo.org/~seemant/distfiles/${PATCH_P}.tar.bz2

The _rc to rc change in the release version is an artefact I've been too lazy
to edit out.

From 0.9 series of release candidates, Bryan Jacobs' patchset seems to be
applicable without modification.

With 0.8.1 release in a separate installation directory I have easily installed
app-crypt/libgssapi, net-libs/librpcsecgss and net-fs/nfs-utils, having just
changed the net-fs/nfs-utils dependency from app-crypt/mit-krb5 to
virtual/krb5. With newer versions of heimdal I've run into problems installing
net-fs/nfs-utils. For now I've tried several heimdal versions and found one
that works with nfs-utils without further work. As soon as I feel like playing
with that again I'm going to submit a detailed report of my compilation
problems as well as anything I eventually find; since the nfs-utils developers
seem to support heimdal, chances are that my problems either are results of my
wrong setup or will go off in the next nfs-utils version.

Created an attachment (id=126115) [details]
heimdal-0.8.1-gentoo-patches-0.1.tar.bz2

(In reply to comment #20)
> 
> With 0.8.1 release in a separate installation directory I have easily installed
> app-crypt/libgssapi, net-libs/librpcsecgss and net-fs/nfs-utils, having just
> changed the net-fs/nfs-utils dependency from app-crypt/mit-krb5 to
> virtual/krb5. With newer versions of heimdal I've run into problems installing
> net-fs/nfs-utils. For now I've tried several heimdal versions and found one
> that works with nfs-utils without further work. As soon as I feel like playing
> with that again I'm going to submit a detailed report of my compilation
> problems as well as anything I eventually find; since the nfs-utils developers
> seem to support heimdal, chances are that my problems either are results of my
> wrong setup or will go off in the next nfs-utils version.
> 

Even if you manage to compile nfs-utils with Heimdal 1.0 installed, you will
not be able to run rpc.gssd nor rpc.svcgssd.

libgssapi and Heimdal 1.0 by default install "libgssapi.so.2".  You must change
the library version of one or the other in order for the dynamic linker to
function properly with both in the LDPATH (as they both must be for nfs-utils).

(In reply to comment #22)
> Even if you manage to compile nfs-utils with Heimdal 1.0 installed, you will
> not be able to run rpc.gssd nor rpc.svcgssd.

Verified :-(

Switched to the newest Heimdal (1.0.1_rc1) again, removed app-crypt/libgssapi.

Instead of modifying net-libs/librpcsecgss acording to Bug #186392 libgssapi.pc
created by heimdal ebuild: changing the dependencies of librpcsecgss ebuild was
enough then.

net-fs/nfs-utils ebuild modified to use your patch from the Bug #134064 (more
discussion there). Everything compiled well, but rpc.svcgssd still does not
start (and does not say why). May be I would need some specific kernel
configuration, or even kernel patch? (Not that I actually need kerberised NFS
running.)

Created an attachment (id=126185) [details]
heimdal-1.0-1.0.1_rc1.ebuild.diff

Patch to Bryan Jacobs' 1.0 ebuild to install the current release candidate, use
a separate installation directory and create .pc files for pkg-config (mainly
libgssapi.pc used by net-libs/librpcsecgss). Uses Bryan Jacobs' patchset, just
renamed to reflect the version.

(In reply to comment #23)
> net-fs/nfs-utils ebuild modified to use your patch from the Bug #134064 (more
> discussion there). Everything compiled well, but rpc.svcgssd still does not
> start (and does not say why). May be I would need some specific kernel
> configuration, or even kernel patch? (Not that I actually need kerberised NFS
> running.)
> 
In order to use Kerberized NFS, you must have rpcsec_gss support in the kernel
(modprobe appropriate stuff if necessary).  This means you need to enable NFSv4
server support and the krb5 mechanism in your kernel config.

Try to run rpc.gssd or rpc.svcgssd with the -f -vvv options.  Check syslogs
too.  They'll complain about missing stuff in /proc or /var if you don't have
appropriate modules loaded or the nfs filesystem mounted.

Created an attachment (id=128519) [details]
app-crypt/heimdal/heimdal-1.0.1.ebuild

Symlinks fixup.

Created an attachment (id=128521) [details]
app-crypt/heimdal/files/1.0.1/001_all_heimdal-no_libedit.patch

Created an attachment (id=128523) [details]
app-crypt/heimdal/files/1.0.1/002_all_heimal-fPIC.patch

Created an attachment (id=128524) [details]
app-crypt/heimdal/files/1.0.1/003_all_heimdal-rxapps.patch

Created an attachment (id=128526) [details]
app-crypt/heimdal/files/1.0.1/005_all_heimdal-suid_fix.patch

Created an attachment (id=128528) [details]
app-crypt/heimdal/files/1.0.1/010_all_heimdal-system-libss.patch

Created an attachment (id=128529) [details]
app-crypt/heimdal/files/1.0.1/012_all_heimdal-berkdb.patch

Created an attachment (id=128531) [details]
app-crypt/heimdal/files/1.0.1/013_all_heimdal-pthread-lib.patch

Created an attachment (id=128533) [details]
app-crypt/heimdal/files/1.0.1/014_all_heimdal-path.patch

Created an attachment (id=128534) [details]
app-crypt/heimdal/files/1.0.1/015_all_heimdal-fixit.patch

Created an attachment (id=128536) [details]
app-crypt/heimdal/files/1.0.1/100_all_force_inclusion_by_path.patch

Created an attachment (id=128537) [details]
app-crypt/heimdal/files/configs/heimdal-kadmind

Created an attachment (id=128539) [details]
app-crypt/heimdal/files/configs/heimdal-kcm

Created an attachment (id=128540) [details]
app-crypt/heimdal/files/configs/heimdal-kdc

Created an attachment (id=128541) [details]
app-crypt/heimdal/files/configs/heimdal-kpasswdd

Created an attachment (id=128543) [details]
app-crypt/heimdal/files/configs/krb5.conf

Created an attachment (id=128544) [details]
app-crypt/heimdal/files/configs/krb5-kdc.schema

Thanks a lot, your ebuild worked for me. Where did the heimdal maintainer go?
The last ebuild in the tree is extremely old...

Created an attachment (id=131346) [details]
heimdal-1.0.1-r1.ebuild

Dmitry S. Kulyabov's 1.0.1 ebuild had built well for me, but then I ran into
problems with dependent packages.

Unfortunately I didn't report the problem immediately neither made notes, and
by now I've forgotten which ebuild crashed then during compilation and what was
the error report. In case nobody else obtains such information I'll have to
find time for further experiments and reproduce the error once again.

For now, I use this ebuild, heavily based on Bryan Jacobs's work (my few
additions, derived mostly from Harald Barth's work, actually converging further
to Bryan Jacobs's 1.0 ebuild). It uses Bryan Jacobs's 1.0 patchset, just
renamed to heimdal-1.0.1-gentoo-patches-0.1.tar.bz2 Until now it seems to work
for me -- that is everything I've tried to upgrade or recompile has built well.
(I guess that unmodified Bryan Jacobs's 1.0 ebuild, just renamed to 1.0.1,
would work as well.)

Unfortunately I don't understand programming much and kerberos at all, so I'm
unable to actually compare Bryan Jacobs's and Dmitry S. Kulyabov's works, not
to speak of combining the best of both worlds into something ready to push into
the portage tree (which needs upgrade desperately).

Yeah look, we need heimdal maintainers.  There are none.  I used to maintain
this, but I have no boxes with it on anymore, nor do I have the knowledge. 
And, I'm retiring soon, anyway.  So, if someone would like to step up, I'll
happily mentor that person before my departure.


Email me off-bug.

Created an attachment (id=135345) [details]
patch for -Wl,--as-needed

To add my two cent: one more patch is needed to build it with -Wl,--as-needed.

I tried to build it without inclusion-by-path patch. Everything that I had what
depended on libgssapi seemed to rebuild OK, however I may simply lack does
packages that would brake.
I have following packages installed:
net-libs/libgsasl-0.2.10
dev-libs/cyrus-sasl-2.1.22-r2
dev-util/cvs-1.12.12-r4
net-misc/openssh-4.7_p1-r1
dev-lang/php-5.2.4_p20070914-r2
gnome-base/gnome-vfs-2.20.0
dev-perl/GSSAPI-0.24
net-analyzer/net-snmp-5.4
net-mail/dovecot-1.0.7
net-mail/fetchmail-6.3.8-r1
net-fs/samba-3.0.26a

samba is yet to be rebuilt but the rest seemed fine. fetchmail builds with
heimdal after applying a little patch I dropped into bugzilla awhile ago.

Created an attachment (id=138341) [details]
Patch for cyrus-sasl to compile against heimdal

tested against heimdal-1.0.1

Created an attachment (id=138343) [details]
php4_4-sapi.eclass patch to compile against heimdal-1.0.1

php ebuild is correct you have to patch some eclass, namely
php4_4-sapi.eclass
php5_0-sapi.eclass
php5_1-sapi.eclass
php5_2-sapi.eclass

patch will follow.

Created an attachment (id=138344) [details]
php5_0-sapi.eclass patch to compile against heimdal-1.0.1

Created an attachment (id=138345) [details]
php5_1-sapi.eclass patch to compile against heimdal-1.0.1

Created an attachment (id=138347) [details]
php5_2-sapi.eclass patch to compile against heimdal-1.0.1

Created an attachment (id=138349) [details]
patch for postgresql library to compile against heimdal 1.0.1

Created an attachment (id=138350) [details]
patch for postgresql to compile against heimdal 1.0.1

Created an attachment (id=138352) [details]
patch for dovecot to compile against heimdal 1.0.1

should work with dovecot-1.0.5 not tested

Created an attachment (id=138354) [details]
patch for openldap to compile against heimdal 1.0.1

should be also ok for openldap-2.3.38.ebuild not tested

Created an attachment (id=138355) [details]
New ebuild for pam_krb5 which work with heimdal 1.0.1

don't know if this implementation work with MIT-Kerberos

Created an attachment (id=138356) [details]
New ebuild for Apache Module mod_auth_kerb which work with heimdal 1.0.1

don't know if this works with MIT-Kerberos implementation

(In reply to comment #56)
> New ebuild for pam_krb5 which work with heimdal 1.0.1

As the revbump request from bug 163840 seems to be in portage now, we have a
pam_krb5-3.9 in portage which is more recent than this version 3.5 you propose
here. Some of the things in your ebuild seem a bit more elaborate than what the
3.9 ebuild currently in portage does. If you have special reasons for some of
this, you might want to comment on bug 163840, but I see no need to have this
ebuild discussed here, as it is not immediately related to heimdal 1.

(From update of attachment 138355 [details])
see comment 58 and use the described Version there

Created an attachment (id=142119) [details]
heimdal-1.1-gentoo-patches-0.1.tar.bz2

The patchset as used by Bryan Jacobs, slightly adapted to the version 1.1

Created an attachment (id=142121) [details]
app-crypt/heimdal-1.1.ebuild

Ebuild for heimdal 1.1. Once again back to Bryan Jacobs's work. I've taken back
all my former tweaks as messy, including my attempt on pkg-config files for
heimdal -- the current heimdal uses pkg-config on itself, at least for
heimdal-gssapi.

Compared to the original heimdal-1.0.ebuild by Bryan Jacobs, several commented
out lines are deleted and the web address of heimdal is updated to the current
www.h5l.org. I've also reduced the keywords to just "~x86 ~amd64" since I
compile just on these two architectures and know nothing of any other.

Created an attachment (id=142122) [details]
heimdal-1.0-1.1.ebuild.diff

Diff from app-crypt/heimdal-1.0.ebuild to app-crypt/heimdal-1.1.ebuild

Created an attachment (id=142123) [details]
gentoo-patches-heimdal-1.0-1.1.diff

Diff from uncompressed heimdal-1.0-gentoo-patches-0.1.tar.bz2 to uncompressed
heimdal-1.1-gentoo-patches-0.1.tar.bz2

I have troubles without symlinks in the includes directory. Some packages
(openldap, cyrus-sasl, ...) won't compile without it.

(In reply to comment #64)
> I have troubles without symlinks in the includes directory. Some packages
> (openldap, cyrus-sasl, ...) won't compile without it.

Mea culpa.

Removing all the useless changes I've made to the ebuild by Bryan Jacobs, I've
accidentally returned in place the request to install the headers into
/usr/include/heimdal. Bryan Jacobs incorporated that configuration option to
accommodate heimdal alongside app-crypt/libgssapi for net-fs/nfsutils (refer to
the discussion above). Not only he afterwards succeeded in patching
net-fs/nfsutils to compile against heimdal without libgssapi, but by now even
app-crypt/libgssapi has ceased from the portage tree. Thus no exotic place for
heimdal headers is needed anymore.

With headers under /usr/include/heimdal, either symlinks or patches for
configuration of various packages would be needed. I'm not sure why I haven't
realized the problem before myself.

Corrected ebuild follows.

Created an attachment (id=147692) [details]
heimdal-1.1.ebuild

Corrected version of heimdal-1.1.ebuild, not installing headers into any place
exotic.

Created an attachment (id=147693) [details]
heimdal-1.0-1.1.ebuild.diff

Diff version of the above.

(In reply to comment #66)
> Created an attachment (id=147692) [edit] [details]
> heimdal-1.1.ebuild

I've just tried to compile heimdal-1.1.ebuild with USE="ldap kerberos" in
/etc/make.conf. Because of the DEPEND of heimdal on openldap and openldap on
kerberos we do have a circular dependency. Both dependencies do have an
eligibility. I am using mit-krb5 (which can also use ldap as backend) which
does not have a ldap USE nor dependency. IMHO it's neither advisable nor common
to use ldap as backend for kerberos, so my suggestion would be to disable the
ldap support in heimdal, as I am not a heimdal specialist I do not know what
the exact impact of this action would be. Discussion start ....

(In reply to comment #68)
> (In reply to comment #66)
> > Created an attachment (id=147692) [edit] [details]
> > heimdal-1.1.ebuild
> 
> I've just tried to compile heimdal-1.1.ebuild with USE="ldap kerberos" in
> /etc/make.conf. Because of the DEPEND of heimdal on openldap and openldap on
> kerberos we do have a circular dependency. Both dependencies do have an
> eligibility. I am using mit-krb5 (which can also use ldap as backend) which
> does not have a ldap USE nor dependency. IMHO it's neither advisable nor common
> to use ldap as backend for kerberos, so my suggestion would be to disable the
> ldap support in heimdal, as I am not a heimdal specialist I do not know what
> the exact impact of this action would be. Discussion start ....
> 

As an example of using LDAP as a Kerberos backend, look to every single Windows
2003 domain in existence.  Or, alternately, Samba 4.

This support is necessary.  Don't disable it.  If you want to break the
dependency cycle, just compile either LDAP w/o Kerberos support, or Kerberos
w/o LDAP support, build the second package, and then rebuild the first with the
USE flags you like.

How does MIT kerberos has support for using LDAP as a database without
depending on LDAP libraries?  Does it have internal copies?

(In reply to comment #69)
> This support is necessary.  Don't disable it.  If you want to break the
> dependency cycle, just compile either LDAP w/o Kerberos support, or Kerberos
> w/o LDAP support, build the second package, and then rebuild the first with the
> USE flags you like.

ACK - resolving the problem is not the problem. But a global USE situation as
described above is not unusual and it would be nice to have a situation where
no special user interaction is required. Of course ... here the answer is not
easy to find.

> How does MIT kerberos has support for using LDAP as a database without
> depending on LDAP libraries?  Does it have internal copies?

It simply doesn't have support for it in gentoo ... of course it's not possible
to compile kerberos without ldap headers and run it without the libraries. I
know the examples of using LDAP as backend - the question is if you would build
a linux configuration like that? AFAIK ldap in kerberos means really to store
the principals in a ldap database. That does not mean that you aren't able to
use ldap for libnss and all the other tasks.

Remark: cite from the heimdal HP:
"Note that before attempting to configure such an installation, you should be
aware of the implications of storing private information (such as users' keys)
in a directory service primarily designed for public information."

g, mueli

(In reply to comment #70)
> But a global USE situation as
> described above is not unusual and it would be nice to have a situation where
> no special user interaction is required.

  Then you should probably file a portage enhancement bug to solve circular
dependencies automatically. No more USE="-doc -X -java" and other manual
adjustments when installing on a new machine would be nice, but rather that
then having unconditionally disabled features that are supported upstream.
After all, isn't Gentoo about choice in the first place? For ease of
installation, there is (at least) Ubuntu, for choices made by others, there is
Windows.

  (Well, please, excuse if I'm being rude. I'm just upgrading, and solving
problems with packages being mutually exclusive or hardmasked. Some choices to
make, some problems to solve manually, and, unfortunately, likely some choices
made by others to undo too.)

  BTW, there just was some discussion of LDAP support in heimdal going at
heimdal-discuss@sics.se -- see
http://list.sics.se/sympa/arc/heimdal-discuss/2008-04/msg00002.html and related
mails.

(In reply to comment #71)
>   Then you should probably file a portage enhancement bug to solve circular
> dependencies automatically.

How should that work? You can't simply resolve circular dependencies as it is
the character of a circle not having an end or a beginning - so where do you
want to break the circle? You have to decide it manually.

> After all, isn't Gentoo about choice in the first place? For ease of
> installation, there is (at least) Ubuntu, for choices made by others, there is
> Windows.

ACK - But despite free choice we also want to deliver a usable
(meta)distribution which can be used in a (more or less) "automatic" way
without to much user interaction. Therefore I would support a feature
restriction to provide a more homogeneous system at all. At least we should
find an acceptable solution before adding heimdal-1.1 to the tree - IMHO it's
not acceptable to add an ebuild with known circular dependencies.

g, mueli

as a suggestion:

why not preparing everything in the heimdal ebuild for ldap deps, then comment
it out and elog in pkg_setup that the user has to copy that ebuild to a local
overlay and re-enable it if he really wants it?

(In reply to comment #71)
> >   Then you should probably file a portage enhancement bug to solve circular
> > dependencies automatically.
> 
> How should that work? ... You have to decide it manually.

  Well, I don't think what I do manually is much creative or based on
inttuitive in-depth knowledge. I am quite sure it could be formalised into an
algorithm and programmed -- if it were worth the effort.
  But this discussion is heading quite off-topic.

> ... Therefore I would support a feature
> restriction to provide a more homogeneous system at all.

  Not only I am of different opinion, I even think Gentoo already has a better
solution. In package.use under /usr/portage/profiles default use flags for
individual packages on various architectures can be and are specified. (I
personally like also the fact that after reading about them in portage.5
manpage I had to use find to actually see an example -- the default package.use
files exist for a handful of architectures only and are quite short, the
feature being used sporadically and with caution.)

> At least we should
> find an acceptable solution before adding heimdal-1.1 to the tree - IMHO it's
> not acceptable to add an ebuild with known circular dependencies.

  Like media-libs/libsdl and media-libs/DirectFB?

  In fact what heimdal-1.x needs to get into the portage tree is an ebuild
maintainer. I personally don't feel being the right person for the lack of
time, skill, competence etc. -- see comments #63 through #65 for just one
example of my faults. So I maintain the package in my local portage overlay
using the work of others as much as possible, struggle with such annoyances as
Bug #215558, have subscribed several heimdal mailing lists, and hope someone
more competent takes over this package before I feel necessary to do it myself
anyway.

(In reply to comment #74)
>   Well, I don't think what I do manually is much creative [...]

... creative enough ;) If you implement such an algorithm to "automatically"
brake circular dependencies it really has to work on _all_ situations ... not
only on the ones you know ;)

> [...] In package.use under /usr/portage/profiles default use flags for
> individual packages on various architectures can be and are specified.

It would be possible to define a portage.use.mask entry for heimdal. Haven't
thought about that. Don't know how easy it is to do so ... @jokey: Does the
council decide about such a mask file? If we do so, it has to be in the root
profile or at least in the default-linux profile - that's a rather huge thing I
would say. On the other hand it would (as far as I can see) only affect heimdal
and no other projects.

>   In fact what heimdal-1.x needs to get into the portage tree is an ebuild
> maintainer.

Of course - as far as I can say we are already working on that ;)

> [...] struggle with such annoyances as
> Bug #215558, have subscribed several heimdal mailing lists, and hope someone
> more competent takes over this package before I feel necessary to do it myself
> anyway.

We are going to solve the issue - be more confident. Of course that's a problem
we have to solve too before adding heimdal to portage. Except committing you
are already helping to maintain the ebuild by committing your experience and
helping to stabilize it. There is always work in progress ... software is never
finished.

ebuild maintainers decide on use.mask'ing something though might be actually an
option here

heimdal-1.1 ebuild does not compile here on x86_64

(In reply to comment #77)
> heimdal-1.1 ebuild does not compile here on x86_64

I have it compiled on my amd64 box, so the architecture itself will not be the
cause.

Which part of compilation fails? Is there any helpful information in the error
messages? And, of course, what is your configuration?

BTW: One wild guess of the ``Have you plugged it in?'' type -- have you
downloaded  heimdal-1.1-gentoo-patches-0.1.tar.bz2 and put it into your
/usr/portage/distfiles/ directory?

(In reply to comment #78)
> BTW: One wild guess of the ``Have you plugged it in?'' type -- have you
> downloaded  heimdal-1.1-gentoo-patches-0.1.tar.bz2 and put it into your
> /usr/portage/distfiles/ directory?

Yes.

With gcc-4.3.0
=================================================== 
removing executable bit: usr/lib64/windc.la
^G
 ^[[33;01m*^[[0m QA Notice: Package has poor programming practices which may
compile
 ^[[33;01m*^[[0m            fine but exhibit random runtime failures.
 ^[[33;01m*^[[0m hdb-ldap.c:313: warning: implicit declaration of function
‘ldap_get_values’
hdb-ldap.c:325: warning: implicit declaration of function ‘ldap_value_free’
hdb-ldap.c:403: warning: implicit declaration of function
‘ldap_count_values’
hdb-ldap.c:740: warning: implicit declaration of function ‘ldap_search_s’
hdb-ldap.c:1358: warning: implicit declaration of function ‘ldap_abandon’
hdb-ldap.c:1405: warning: implicit declaration of function ‘ldap_search’
hdb-ldap.c:1580: warning: implicit declaration of function ‘ldap_add_s’
hdb-ldap.c:1584: warning: implicit declaration of function ‘ldap_modify_s’
hdb-ldap.c:1644: warning: implicit declaration of function ‘ldap_delete_s’
^G
^G
 ^[[33;01m*^[[0m QA Notice: Package has poor programming practices which may
compile
 ^[[33;01m*^[[0m            but will almost certainly crash on 64bit
architectures.
 ^[[33;01m*^[[0m Function `ldap_get_values' implicitly converted to pointer at
hdb-ldap.c:313
^G
 ^[[31;01m*^[[0m
 ^[[31;01m*^[[0m ERROR: app-crypt/heimdal-1.1 failed.
 ^[[31;01m*^[[0m Call stack:
 ^[[31;01m*^[[0m       misc-functions.sh, line 621:  Called install_qa_check
 ^[[31;01m*^[[0m       misc-functions.sh, line 317:  Called die
 ^[[31;01m*^[[0m The specific snippet of code:
 ^[[31;01m*^[[0m                               
alpha*|ia64*|powerpc64*|mips64*|sparc64*|x86_64*) die
 "this code is not 64bit clean";;
 ^[[31;01m*^[[0m  The die message:
 ^[[31;01m*^[[0m   this code is not 64bit clean
=================================================== 

With gcc-4.2.3
=================================================== 
creating libroken.la
(cd .libs && rm -f libroken.la && ln -s ../libroken.la libroken.la)
/bin/sh ../../libtool --mode=link x86_64-pc-linux-gnu-gcc  -Wall
-Wmissing-prototypes -Wpointer-arith -Wbad-function-cast -Wmissing-declarations
-Wnested-externs  -march=native -O2 -fomit-frame-pointer -pipe  -Wl,--as-needed
-o snprintf-test  snprintf_test-snprintf-test.o libtest.la libroken.la -lcrypt
-lresolv -lpthread
/bin/sh ../../libtool --mode=link x86_64-pc-linux-gnu-gcc  -Wall
-Wmissing-prototypes -Wpointer-arith -Wbad-function-cast -Wmissing-declarations
-Wnested-externs  -march=native -O2 -fomit-frame-pointer -pipe  -Wl,--as-needed
-o resolve-test  resolve-test.o libroken.la -lcrypt -lresolv -lpthread
x86_64-pc-linux-gnu-gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wbad-function-cast -Wmissing-declarations -Wnested-externs -march=native -O2
-fomit-frame-pointer -pipe -Wl,--as-needed -o .libs/resolve-test resolve-test.o
 ./.libs/libroken.so -lcrypt -lresolv -lpthread
./.libs/libroken.so: undefined reference to `crypt'
=================================================== 

(In reply to comment #79)
I've recompiled my heimdal-1.1 with gcc-4.2.3 (and sys-libs/glibc-2.7-r2 and
sys-apps/portage-2.1.4.4), having USE="X berkdb ipv6 ldap ssl",successfully.

Your gcc-4.2.3 case looks queer -- perhaps unmerging the installed version of
heimdal (if you have one) to prevent accidental linking to some installed old
library instead of a freshly compiled code might help. Or re-emerging of glibc
(which libcrypt belongs to) with the same gcc version.

Nevertheless it might not help you in the end.

I haven't yet upgraded to gcc-4.3 -- and perhaps to other versions of various
other packages that are similarly fresh. Probably portage is the important one.
Your error report looks to me like you have actually compiled heimdal-1.1
successfully, but your emerge, unlike mine, not only reported ``poor
programming practices'' which may ``almost certainly crash on 64bit systems'',
but so certain it was of that crash that to prevent you from crashing your
system it committed seppuku.

Probably a patch to the reported poor programming practices (and a message
upstream) will solve this best. If you cannot wait for the patch neither write
it yourself, you may try compiling with USE='-ldap'. If it does not help or if
you want heimdal with ldap support, and if you think that your emerge is too
clever and overprotective, you might downgrade portage (and file a bug for
portage).

As soon as I feel having enough time I'll try patching.

(In reply to comment #80)
> (In reply to comment #79)
> I've recompiled my heimdal-1.1 with gcc-4.2.3 (and sys-libs/glibc-2.7-r2 and
<snip>
> As soon as I feel having enough time I'll try patching.

No rush. I just wanted to experiment with kerberos and it seems the heimdal
package is quite highly regarded. I did get installed on my x86 box but it was
turning into a bit of a pain due to the other ebuilds depending upon mit
instead of a virtual/kerberos, so for now looking at the mit version.
Would be nice to see this package in portage and maintained with a supporting
virtuals package.
Thanks again.

Never put off till tomorrow what has been done by others since the day before
yesterday :-)

The QA issues, especially the 64-bit critical one, have been discovered and
dealt with in Debian, see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463410 The heimdal svn trunk
deals with the problems
http://loka.it.su.se/fisheye/browse/heimdal/trunk/heimdal/lib/hdb/hdb-ldap.c?r1=22586&r2=22588

I've applied a corresponding patch to heimdal-1.1 -- a few of the QA warning
last, but at least the critical one is gone:

 * QA Notice: Package has poor programming practices which may compile
 *            fine but exhibit random runtime failures.
 * hdb-ldap.c:749: warning: implicit declaration of function
‘ldap_search_s’
hdb-ldap.c:1369: warning: implicit declaration of function ‘ldap_abandon’
hdb-ldap.c:1416: warning: implicit declaration of function ‘ldap_search’
hdb-ldap.c:1591: warning: implicit declaration of function ‘ldap_add_s’
hdb-ldap.c:1595: warning: implicit declaration of function ‘ldap_modify_s’
hdb-ldap.c:1655: warning: implicit declaration of function ‘ldap_delete_s’

According to http://en.opensuse.org/OpenLDAP_2.3_libldap_upgrade_howto there is
then still some work for tomorrow, but for now that hopefully can be put off.

The ebuild and patch follow.

Created an attachment (id=149248) [details]
heimdal-1.1-r1.ebuild

The ebuild for heimdal-1.1 applying the new patch.

Created an attachment (id=149249) [details]
heimdal-1.1-ldapQA.patch

The patch for the QA issues with hdb-ldap (due to new libldap API).

Created an attachment (id=149519) [details]
heimdal-1.1-r2.ebuild

New heimdal-1.1 ebuild with all the LDAP related QA warnings removed. Now if
only there were somebody able to test if the LDAP support actually works.

Created an attachment (id=149521) [details]
heimdal-1.1-ldapQAplus.patch

The heimdal-1.1 QA warnings patch, episode 2. Kept apart from the episode 1 to
distinguish what is just upgraded to the current SVN trunk version, and what
has been tweaked by me.

Created an attachment (id=150352) [details]
heimdal-1.2_rc1-gentoo-patches-0.1.tar.bz2

Patches collection for heimdal-1.2_rc1. The patch to update obsolete openldap
API calls is included.

Created an attachment (id=150353) [details]
heimdal-1.2_rc1.ebuild

Ebuild for testing the 1.2 release candidate 1. Depends on
>=sys-devel/autoconf-2.62 and >=sys-devel/libtool-2.2 -- autoconf-2.61, pulled
in by "WANT_AUTOCONF=latest", is not enough, and =sys-devel/libtool-2.2* must
be package-unmasked (see bug #212763).

If you wish to compile with <=sys-devel/libtool-1.5.26, try commenting out the
dependency and uncommenting the sed-ECHO-libtool hack: Old sys-devel/libtool
seems to create a libtool script that defines ECHO and uses $echo, downcasing
the definition apparently makes the package compile well.

There are new QA Notices, I haven't tried to solve them yet:

 * QA Notice: Package has poor programming practices which may compile
 *            fine but exhibit random runtime failures.
 * stringprep.c:102: warning: implicit declaration of function ‘memcpy’
sel-lex.l:90: warning: implicit declaration of function ‘vasprintf’


 * QA Notice: Package has poor programming practices which may compile
 *            fine but exhibit random runtime failures.
 * stringprep.c:102: warning: incompatible implicit declaration of built-in
function ‘memcpy’

Created an attachment (id=151392) [details]
heimdal-1.2_rc2.ebuild

Next step upstream towards 1.2 release.
heimdal-1.2_rc1-gentoo-patches-0.1.tar.bz2 is to be renamed or copied to
heimdal-1.2_rc2-gentoo-patches-0.1.tar.bz2. Compiles on x86 and amd64 for me,
only ``sel-lex.l:94: warning: implicit declaration of function
‘vasprintf’'' reported now.

The ebuild uses sed -e's/ECHO/echo/' hack to build with <libtool-2.2 and avoid
problems of other packages with >=libtool-2.2.

Everything seems to compile against heimdal-1.2 release candidates except
nfs-utils where the headers of gssglue get in the way of the ones of heimdal
(/usr/include/gssglue/gssapi/gssapi.h takes precedence over
/usr/include/gssapi/gssapi.h).

Looking at the ever growing list of attachments here, I would assume it would
make sense to start a public overlay for them, so that heimdal-1* can get some
more testing from users enabling this overlay via layman, without first reading
all the comments here to know which files are needed and where each one should
go. This public overlay should of course not be a substitute for heimdal-1
entering the main portage tree as soon as it's stable enough.

I don't know who would be responsible for setting up and maintaining such an
overlay. http://www.gentoo.org/proj/en/metastructure/herds/herds.xml#doc_chap59
looks like the kerberos herd, to which this bug here is assigned, is empty. Are
there any Gentoo devs working on kerberos without being part of that herd? Or
any willing to provide infrastructure so that contributors like the ones
originating above attachments can help out?

ACK - an overlay for testing would be a great idea. So we can centralize the
great work of you all and provide a way for better testing. There is an ongoing
effort to establish a working dev herd again. We've made some kind of fire
brigade for the MIT implementation (thx jokey). The reason therefore is the
explicit dependency of some code on MIT kerberos. A few issues are solved or
can be solved in a simple way but there is still a long way to go to have a
virtual/kerberos where you're really able to switch between heimdal and MIT and
IMHO that _must_ be the aim!

g, mueli

I'm willing to do the dev-side part for you such as (re)forming that herd,
creating the herd overlay and keeping an eye on what's going on with these bugs
here, ping back if you feel like contributing more and making this worth it :)

Though good work so far already :)

Thx for the offer jokey! Of course it's worth making an overlay and
reactivating the kerberos herd. As already discussed, there is no active
maintaining of kerberos in gentoo apart from the work you (and a bit me) did in
the past weeks. I would be glad to inherit a great part of your dev work in
this herd in near future ... ;)

g, mueli

Created an attachment (id=151695) [details]
librpcsecgss-0.18-config_in.patch

Some more material for the overlay. Might go better to the bug #134064 weren't
that one shut down as NEEDINFO until heimdal-1.x gets into the portage tree.

This patch makes librpcsecgss test for heimdal-gssapi as an alternative to
libgssglue and compile against heimdal instead of net-libs/libgssglue. Needed
for net-fs/nfs-utils.

The diff to modify the librpcsecgss ebuild follows.

Created an attachment (id=151696) [details]
librpcsecgss-0.18.ebuild-heimdal.diff

Diff for net-libs/librpcsecgss-0.18.ebuild to apply the patch for accepting
heimdal-gssapi as an alternative to libgssglue.

Created an attachment (id=151698) [details]
nfs-utils-1.1.2-pkgconfig_ac.patch

A patch for net-fs/nfsutils-1.1.2 to use pkg-config properly and accept
heimdal-gssapi as an alternative to libgssglue.

One more patch and the diff for the ebuild follow.

Created an attachment (id=151699) [details]
nfs-utils-1.1.2-no_libgssapi.patch

Bryan Jacobs's patch for net-fs/nfs-utils returns.

Compared to the original I've just removed the part modifying configure.ac;
that file I've dealt with in the patch above.

This patch allows net-fs/nfs-utils-1.1.2 to compile against heimdal-1.x and not
to use net-libs/libgssglue.

Created an attachment (id=151701) [details]
nfs-utils-1.1.2.ebuild-heimdal.diff

A diff for the net-fs/nfs-utils-1.1.2.ebuild to use the two patches above and
compile against app-crypt/heimdal-1.x without net-libs/libgssglue (which does
not play well with heimdal).

Created an attachment (id=154219) [details]
heimdal-1.2.ebuild

Heimdal 1.2 is out.

Wants libtool at least 2.2 that is still masked in portage, so the ebuild,
rather than demanding that, tests libtool version and employs a quick and dirty
hack if libtool is elder.

Created an attachment (id=154221) [details]
heimdal-1.2-gentoo-patches-0.1.tar.bz2

The patchset updated for the 1.2 release.

Thanks to the development upstream, adding a patch for LDAP API no longer
needed, and 010_all_heimdal-system-libss.patch could be removed as well.

Created an attachment (id=154223) [details]
nfs-utils-1.1.2-r1.ebuild-heimdal.diff

In portage, there is net-fs/nfs-utils-1.1.2-r1 now, adding one more patch to
net-fs/nfs-utils-1.1.2. This diff adapts the new ebuild to heimdal again.

Thx for your great work Honza! I've created a git overlay for all the stuff
related to kerberos. I've already commited heimdal-1.2 and it should be usable
but it has still a few issues before we can push it into the tree.

As this bug is getting really long and the topic is no longer related to the
content I'd suggest to close this bug and to open a new one for all the issues
which may come up due to the overlay. If you're familiar with git we can make
the workflow with the help of patches you create and post in the bug reports.

@nfs-utils: I'd say it doesn't make much sense to host the patch here in this
bug. If you're really interested in getting this patch into the nfs-utils
you'll have to open a new bug which should be assigned to the net-fs herd.

Here is the repository url:

url = git://git.overlays.gentoo.org/proj/kerberos.git

You can access the repo through gitweb also on
http://git.overlays.gentoo.org/gitweb/.

Do you accept this proceeding? If so, would you please close the bug? If you
file a new one please assign it to kerberos@gentoo.org.

So far and thx for all the fish, mueli

(In reply to comment #102)
Please, consider all those questions and proposals forwarded to Bryan Jacobs by
this remark.

He is the reporter of this bug, as well as the creator of the ebuilds and
patches that I maintain for my personal needs as the upstream versions
progress.

I definitely welcome the overlay. Unfortunately I am not familiar with git, but
it isn't so much of a problem. Not only there are others, especially Bryan
Jacobs, who will be more important and useful to the overlay, but even I can
learn what's needed for the use of git too.

I doubt closing the bug, because closed bugs are invisible in the quick search.
While that cannot stop experienced users of the bugzilla, newcomers who have
problems with heimdal or contributions to its use in Gentoo might get confused
and discouraged. Perhaps closing this bug may be accompanied by creating a new
one that will direct to the overlay.

The invisibility of closed bugs concerns nfs-utils -- they have their own bug
#134064 where Bryan Jacobs has reported his patch, but the bug is closed as
needinfo until heimdal-1.x gets into the portage tree. Creating a new bug for
the same issue would look to me like waging war on those who closed the one;
luckily I think that the overlay (as opposed to this bug) is the right place
for all the patches to heimdal dependant packages.

(In reply to comment #103)

I agree that closing bugs which are the only sources of "how to make things
work" information is a bad idea.

I'm still following this, Honza has just been beating me to the punch posting
ebuilds :-).  My systems, at least, don't get broken when I continue to use the
Heimdal-1.x series krb5 implementation.

I have not yet tried that overlay, but I surely will in the near future.

The big advantage of an overlay is the possibility to combine experience. It's
a good thing if your ebuild is working for you - it would be even better if a
lot of others can use it ;)

By the way - I've to thank you both Bryan and Honza for the work you've done. I
am pretty sure that we have soon stable heimdal ebuilds in an actual usable
state ;)

So long, g mueli

@bug closing: it's ok for me to follow up this bug - it was more some kind of
suggestion. It would be really easy to search for bugs assigned to
kerberos@gentoo.org in bugzilla. But once more I'd like to ask you if you find
bugs related to a special ebuild to file a new bug ...

(In reply to comment #102)
> Here is the repository url:
> 
> url = git://git.overlays.gentoo.org/proj/kerberos.git
> 
> You can access the repo through gitweb also on
> http://git.overlays.gentoo.org/gitweb/.

The layout of this repository, with the portage overlay in a "repo"
subdirectory, seems to make things difficult for layman. I'm no wizard with
either git or layman, but it would help testing if people could use layman for
overlay management. So either restructure the git tree or request an
enhancement of layman, so that one can have subdirectories added to layman's
make.conf.

I am not using layman, therefor I didn't have your problems. But I fixed it and
moved the overlay root from ./repo into the ./ of the repository. Now it should
be ok to use the overlay with layman. Feel free to comment here if not ...

The next step (before pushing heimdal-1.1 into tree) is to test the reverse
dependencies. I've listed my testing state below.

[   ] ... not tested
[ m ] ... depends direct on mit-krb5
[ n ] ... does not compile
[-c-] ... compiles (that's nearly ok for me - if the API is compatible than
          it should work IMHO)
[---] ... compiles and functionality tested

$ equery d virtual/krb5
[ Searching for packages depending on virtual/krb5... ]
[ n ] app-crypt/kstart-3.12 (virtual/krb5)
[---] app-editors/emacs-22.2-r2 (kerberos? virtual/krb5)
[ n ] dev-libs/openssl-0.9.8g (kerberos? app-crypt/mit-krb5)
[-c-] dev-util/cvs-1.12.12-r4 (kerberos? virtual/krb5)
[   ] gnome-base/gnome-vfs-2.20.1-r1 (kerberos? virtual/krb5)
[   ] kde-base/kdelibs-3.5.9-r4 (kerberos? virtual/krb5)
[   ] net-fs/nfs-utils-1.1.0-r1 (kerberos? app-crypt/mit-krb5)
[   ] net-fs/openafs-1.4.7 (kerberos? virtual/krb5)
[ n ] net-misc/curl-7.17.1 (kerberos? virtual/krb5)
[-c-] net-misc/neon-0.26.4 (kerberos? virtual/krb5)
[-c-] net-misc/openssh-4.7_p1-r6 (kerberos? virtual/krb5)
[-c-] net-nds/openldap-2.3.41 (!minimal & kerberos? virtual/krb5)
[   ] net-print/cups-1.3.7-r1 (kerberos? virtual/krb5)
[-c-] sys-auth/nss_ldap-258 (kerberos? virtual/krb5)
[   ] sys-auth/pam-afs-session-1.6 (virtual/krb5)
[---] sys-auth/pam_krb5-3.10 (virtual/krb5)

As you can see there is a lot of work to do ;) Any help on testing would be
appreciated.

g, mueli

(In reply to comment #107)
OpenAFS 1.4.7 tested+works on amd64 with Heimdal 1.2.

(In reply to comment #107)

Again on amd64 semi-stable with Heimdal 1.2:
- kdelibs compiles
- openldap works (GSSAPI via cyrus-sasl, which should be on the list, AND
smbkrb5passwd overlay) BUT will not build unless the kpasswd module is turned
off
- nfs-utils compiles WITH the patch on this list
- cups compiles
- ipsec-tools, not on the list, compiles (I've never gotten GSSAPI-based IPSec
to work ever, even with MIT krb5)
- app-crypt/kstart compiles when you change its version to 3.13 (released
yesterday)

add new state to list:

[-p-] ... need patch to compile

actual list - thx to Bryan! (btw - revision bump for kstart is done)

[-c-] app-crypt/kstart-3.12 (virtual/krb5)
[---] app-editors/emacs-22.2-r2 (kerberos? virtual/krb5)
[ n ] dev-libs/openssl-0.9.8g (kerberos? app-crypt/mit-krb5)
[-c-] dev-util/cvs-1.12.12-r4 (kerberos? virtual/krb5)
[   ] gnome-base/gnome-vfs-2.20.1-r1 (kerberos? virtual/krb5)
[-c-] kde-base/kdelibs-3.5.9-r4 (kerberos? virtual/krb5)
[-p-] net-fs/nfs-utils-1.1.0-r1 (kerberos? app-crypt/mit-krb5)
[   ] net-fs/openafs-1.4.7 (kerberos? virtual/krb5)
[ n ] net-misc/curl-7.17.1 (kerberos? virtual/krb5)
[-c-] net-misc/neon-0.26.4 (kerberos? virtual/krb5)
[-c-] net-misc/openssh-4.7_p1-r6 (kerberos? virtual/krb5)
[-c-] net-nds/openldap-2.3.41 (!minimal & kerberos? virtual/krb5)
[-c-] net-print/cups-1.3.7-r1 (kerberos? virtual/krb5)
[-c-] sys-auth/nss_ldap-258 (kerberos? virtual/krb5)
[   ] sys-auth/pam-afs-session-1.6 (virtual/krb5)
[---] sys-auth/pam_krb5-3.10 (virtual/krb5)
[-c-] net-firewall/ipsec-tool

I am going to push the nfs-utils into overlay with the patch included ... as
soon as I've time for it ;)

ATM I can't say anything to the openldap problem you described ... I am going
to test it.

@heimdal-1.2 : I don't know what you're doing right - On my machines it fails
to compile with:

./.libs/libkrb5.so: undefined reference to `pthread_create'
./.libs/libkrb5.so: undefined reference to `pthread_mutexattr_destroy'
./.libs/libkrb5.so: undefined reference to `pthread_mutexattr_settype'
./.libs/libkrb5.so: undefined reference to `pthread_mutexattr_init'
./.libs/libkrb5.so: undefined reference to `pthread_mutex_trylock'
./.libs/libkrb5.so: undefined reference to `pthread_join'

because -pthread is missing in the linker call. Have you fixed that issue or
does the problem not occur for you?

g, mueli

(In reply to comment #110)
I can add to the list following packages that I have installed:

[-c-] dev-lang/php-5.2.6-r1
[-c-] dev-libs/cyrus-sasl-2.1.22-r2
[-c-] dev-perl/GSSAPI-0.24
[-c-] gnome-base/gnome-vfs-2.22.0
[-c-] gnome-extra/evolution-data-server-2.22.1.1
[-c-] mail-client/evolution-2.22.1.1
[-p-] net-libs/librpcsecgss-0.18
[-c-] net-analyzer/wireshark-1.0.0
[-p-] net-mail/fetchmail-6.3.8-r1

The patch for net-mail/fetchmail I use is actually a patch to the ebuild only,
see the bug #185652 -- changing the dependency from app-crypt/mit-krb5 to
virtual/krb5 is actually all that is needed (so the unpatched ebuild is [ m ]).

> @heimdal-1.2 : I don't know what you're doing right - On my machines it fails
> to compile with:
> 
> ./.libs/libkrb5.so: undefined reference to `pthread_create'
> ./.libs/libkrb5.so: undefined reference to `pthread_mutexattr_destroy'
> ./.libs/libkrb5.so: undefined reference to `pthread_mutexattr_settype'
> ./.libs/libkrb5.so: undefined reference to `pthread_mutexattr_init'
> ./.libs/libkrb5.so: undefined reference to `pthread_mutex_trylock'
> ./.libs/libkrb5.so: undefined reference to `pthread_join'
> 
> because -pthread is missing in the linker call. Have you fixed that issue or
> does the problem not occur for you?

Do you have USE="threads"? 

I've thought that when .configure has among its options
--enable-pthread-support, the use of threads can be turned on or off at he will
of the user, but I've tested only the USE="threads" case. With USE="-threads" I
can reproduce your error -- but I haven't even actually tried to deal with it.
Can it be caused by usage of some library compiled with threads support?

Another possible pitfall of such nature may be USE="pkinit": I've added that
flag having noticed the .configure option --enable-pk-init, but with
USE="-pkinit" I get:

lib/krb5/.libs/libkrb5.so: undefined reference to `wind_ucs2utf8'
lib/krb5/.libs/libkrb5.so: undefined reference to `wind_ucs2read'
lib/krb5/.libs/libkrb5.so: undefined reference to `wind_ucs2utf8_length'

I think I've noticed some changes of header includes in wind.h at the heimdal
mailing lists, so with a bit of luck in 1.2.1 this problem might cease.

The simplest ``solution'' of course is to set pkinit and threads always on and
not make them USE flags. I unfortunately lack the insight needed to decide if
it is actually correct or how to make the package compile without pkinit and/or
threads support.

It looks like my patch from comment 46 is still required for  heimdal 1.2.
BTW, which packages need force_inclusion_by_path.patch, cause
I built heimdal without it, but despite having a rather minimal overlay,
when it concerns kerberos dependent packages, all of them built fine.

(In reply to comment #112)
> It looks like my patch from comment 46 is still required for  heimdal 1.2.
> BTW, which packages need force_inclusion_by_path.patch, cause
> I built heimdal without it, but despite having a rather minimal overlay,
> when it concerns kerberos dependent packages, all of them built fine.

force_inclusion_by_path.patch is no longer necessary.  It was only for early
Heimdal-1.0 RCs to make them be able to find their own headers :-).

@Honza:  the ebuild I'm using is yours from this thread.  Do you have
USE="threads" enabled?

Created an attachment (id=155083) [details]
heimdal-1.2.1_rc1.ebuild

An ebuild to test heimdal-1.2.1_rc1. force_inclusion_by_path.patch dropped.
heimdal-1.0-as-needed.patch by Rafał Mużyło added to the patchset (sorted
under almost ranom number 022).

I can compile the package well with pkinit and threads on, but not without.
USE="-pkinit" (--disable-pk-init option to the configure script) somehow hides
some unicode support functions defined under libs/wind; so far I don't
understand it at all. The problems with USE="-threads"
(--disable-pthread-support option) arise from the internal copy of sqlite --
that appears to always compile threadsafe, thus requiring -lpthread whenever
linked with anything. So far I haven't tried enough to make its configuration
respect the global threads settings, not to speak of making heimdal use the
system sqlite.

Since I like having as much choice as possible, I still keep the pkinit and
threads USE flags, but not being actually able to support real choice here I've
added error messages if the flags are turned off.

Created an attachment (id=155085) [details]
heimdal-1.2.1_rc1-gentoo-patches-0.1.tar.bz2

The patchset for heimdal-1.2.1_rc1.

Created an attachment (id=155319) [details]
heimdal-1.2.1_rc1-r1.ebuild

Two current heimdal source changes (r23238 and r23235) solve the problem of
wind_ucs2 functions when pkinit support is off. One additional small patch is
needed for USE="-pkinit" to link hx509 library into kdc anyway, since it's
apparently still needed.

Still compiles with threads support on only.

Created an attachment (id=155321) [details]
heimdal-r23235-kb5-libwind_la.patch

Created an attachment (id=155323) [details]
heimdal-r23238-kb5_locl_h-wind_h.patch

Created an attachment (id=155325) [details]
heimdal-kdc-sans_pkinit.patch

Created an attachment (id=155335) [details]
Layman config for kerberos overlay

(In reply to comment #107)
> I am not using layman, therefor I didn't have your problems. But I fixed it
> and moved the overlay root from ./repo into the ./ of the repository.
> Now it should be ok to use the overlay with layman.

It does work. If others want to try out the overlay with layman:
layman -f -o <URL of this attachment> -a kerberos
One day this overlay should get included in the official list of overlays:
http://www.gentoo.org/proj/en/overlays/layman-global.txt

Created an attachment (id=155973) [details]
heimdal-1.2.1_rc1-r2.ebuild

One more patch introduced to use dev-db/sqlite instead of the internal copy.
I've tried to design the patch to use pkg-config, and set the ebuild to depend
on >=dev-db/sqlite-3.5.7, because that is the version of sqlite inside the
heimdal sources.

Should compile without pkinit as well as without threads support now.

Created an attachment (id=155975) [details]
heimdal-system_sqlite.patch

Patch to use system sqlite. Allows heimdal to compile without threads support.

Thx a lot for your work Honza, I really appreciate it!

The patches work quite well in my environments. I've just pushed the 1.2.1_rc1
into the overlay. I am going to test the ebuild on two more environments
tomorrow than I am going to commit it into the tree with ~x86 ~amd64 but
without ldap support.

It would be nice to discuss the ldap issue once again. ATM I am building
heimdal without ldap support. Apart from the fact that I can't advice to use
LDAP as backend for kerberos I am willing to add the use if we find an
acceptable way to brake the circular dependency if global USE="ldap kerberos"
is set.

discussion is open and welcome ...

JFYI: I've changed to naming rule of the patchset to
${PN}-gentoo-patches-${PATCHVER} than it's not necessary to rename the patchset
with each release bump.

There is a big problem left which makes heimdal almost blocking for stable. You
can't compile openssl with kerberos USE if heimdal is installed. :( I am atm
testing with "dev-libs/openssl -kerberos".

Latest state on testing:

[ n ] dev-libs/openssl-0.9.8g (kerberos? app-crypt/mit-krb5)
[-p-] net-fs/nfs-utils-1.1.0-r1 (kerberos? app-crypt/mit-krb5)
[-p-] net-libs/librpcsecgss-0.18
[-p-] net-mail/fetchmail-6.3.8-r1

[-c-] app-crypt/kstart-3.12 (virtual/krb5)
[---] app-editors/emacs-22.2-r2 (kerberos? virtual/krb5)
[-c-] dev-util/cvs-1.12.12-r4 (kerberos? virtual/krb5)
[   ] gnome-base/gnome-vfs-2.20.1-r1 (kerberos? virtual/krb5)
[-c-] kde-base/kdelibs-3.5.9-r4 (kerberos? virtual/krb5)
[-c-] net-fs/openafs-1.4.7 (kerberos? virtual/krb5)
[-c-] net-misc/curl-7.18.2 (kerberos? virtual/krb5)
[-c-] net-misc/neon-0.26.4 (kerberos? virtual/krb5)
[-c-] net-misc/openssh-4.7_p1-r6 (kerberos? virtual/krb5)
[-c-] net-nds/openldap-2.3.41 (!minimal & kerberos? virtual/krb5)
[-c-] net-print/cups-1.3.7-r1 (kerberos? virtual/krb5)
[-c-] sys-auth/nss_ldap-258 (kerberos? virtual/krb5)
[   ] sys-auth/pam-afs-session-1.6 (virtual/krb5)
[---] sys-auth/pam_krb5-3.10 (virtual/krb5)
[-c-] net-firewall/ipsec-tool
[-c-] dev-lang/php-5.2.6-r1
[-c-] dev-libs/cyrus-sasl-2.1.22-r2
[-c-] dev-perl/GSSAPI-0.24
[-c-] gnome-base/gnome-vfs-2.22.0
[-c-] gnome-extra/evolution-data-server-2.22.1.1
[-c-] mail-client/evolution-2.22.1.1
[-c-] net-analyzer/wireshark-1.0.0

Looks quite good so far ...

heimdal-1.2.1_rc1 commited into tree.

heimdal should be split up in at least four packages:
- common libs (should provide virtual/krb5)
- client apps (kinit, kdestroy, kpasswd, ...)
- server apps (kdc, kpasswdd)
- heimdal meta build for people who don't want to think a lot :-)

support for the kerberized applications should be removed at all or put in
different ebuilds. today people should use openssh with kerberos support and
not rsh. ftpd with kerberos can be replaced by proftpd with it's kerberos
support. su and login should be replaced with the shadow's implementations and
pam_krb5. and so on. maybe you should think about that. maybe heimdal at all
should think about that. all alternative application support kerberos but have
a whole bunch of other feature that the heimdal ones don't have.

one advantage is, that split ebuilds would eliminate the circular dependency
with ldap, as ldap would only require heimdal common libs and heimdal-server
would depend on ldap.

you could use the internal sqlite without thread support if you added
use threads || append-flags -DSQLITE_THREADSAFE=0
before econf.

and i guess there an as-needed bug (at least there is one for my ebuilds):
libroken needs to be linked to -lcrypt but isn't by the upstream makefiles.

as soon as gentoo has changed the ssl to the openssl use flag, this should be
used here. people may be confused with an ssl use flag, although heimdal does
never use ssl. it uses libcrypto from the openssl package.

(In reply to comment #127)
> heimdal should be split up in at least four packages:
> - common libs (should provide virtual/krb5)
> - client apps (kinit, kdestroy, kpasswd, ...)
> - server apps (kdc, kpasswdd)
> - heimdal meta build for people who don't want to think a lot :-)
> 
> support for the kerberized applications should be removed at all or put...

Doesn't this part reach somewhat too far? Not only is it more suitable for
upstream, perhaps http://list.sics.se/sympa/arc/heimdal-discuss -- it even
addresses features common to heimdal and mit-krb5.

Definitely splitting up heimdal and leaving mit-krb5 alone makes no sense. In
my opinion, the split-up should be suggested directly upstream, to both
developer teams. Unless such an improvement is really necessary and the
upstream developers really stubborn, I'm against keeping such changes at Gentoo
level.

(In reply to comment #127)
> heimdal should be split up in at least four packages:
> - common libs (should provide virtual/krb5)
> - client apps (kinit, kdestroy, kpasswd, ...)
> - server apps (kdc, kpasswdd)
> - heimdal meta build for people who don't want to think a lot :-)

Makes me think of the way binary distributions like Debian use single source
packages to build multiple binary packages from them.

While I agree that from a user point of view it would be nice to have all these
things in different packages and only install what you need, from the
perspecitve of the sources and build process I guess it would be rather
difficult to split them. If it can be done easily, though, without too much
repeated work, and does even solve the ldpa cyclic dependency problem, then I
as a Gentoo user would like to see it split.

in the case of heimdal, it is very easy to split those parts. eautoreconf and
configure need to run each time, a split packages is built.

one big advantage of gentoo is, that it is possible to only install what you
really want and need. and i don't want kdc on my clients.

additionally it should be easier to install updates, because in that case only
parts of heimdal need to be re-built. the libs do not need to be re-compiled on
client system only because of a bug in the kdc code, that does not even run on
that systems.

As long as we have no USE depend it might be dangerous to split it. Just think
of the case that you set per package USE in the client apps and install the
server parts afterwards. Then you'd have to set the USE manually or client and
server may be incompatible. (a problem which won't occur on binary
distributions)

Nevertheless I've already looked at the way debian is handling this issue and
the feature request isn't dropped - it's just moved a bit downwards on the
priority list. The highest priority for me is to fix all the reverse
dependencies (like nfs-utils) and to save enable the ldap support (although I
don't like it ;) ).

Now it's time to test and to hang out the ebuild ... As this bug thread
clarifies the gentoo community has lost a bit on experience because of the long
time heimdal not being updated.

Created an attachment (id=156553) [details]
new version for patch librpcsecgss-0.18-config_in.patch

i slightly changed the patch librpcsecgss-0.18-config_in.patch. i hope you like
it.

Created an attachment (id=156555) [details]
patch for nfs-utils's way to detect the kerberos libs.

maybe this patch can be send upstream.

Thx mastamind!

The librpcsecgss-0.18-heimdal.patch is included in the kerberos overlay atm. I
am going to file a bug and hopefully the maintainer of librpcsecgss will
include it in the tree.

the cracklib dependency is currently useless because the ebuild does not
compile the cracklib plugin for kpasswdd. either compile the plugin or remove
the cracklib dependency. the best solution would be to add a cracklib use flag.

another idea would be to add an otp use flag. people who don't use otp may be
able to disable is that way.

hi. i managed to mount an export via nfs4 but i get the following error message
on server and client:

ERROR: GSS-API: error in gss_krb5_export_lucid_sec_context():  Miscellaneous
failure (see text) - unknown mech-code 0 for mech 1 2 840 113554 1 2 2

i search on google, but didn't find any useful information. i guess, we are
just one step before heimdal + nfs4.

You are fully right in both. I've removed the cracklib dependency because of

"Code for a password quality checking function that uses the cracklib library
can be found in lib/kadm5/sample_password_check.c in the source code
distribution. It requires that the cracklib library be built with the patch
available at ftp://ftp.pdc.kth.se/pub/krb/src/cracklib.patch."

and I don't want to patch cracklib atm. I'll see it as feature request for the
future.

The otp USE makes sense indeed. I've added it and I'll push it into tree as
-r1.

g, mueli

If I am honest - I haven't managed to compile the nfs-utils against heimdal yet
because I've only tried it once with your patches. I've to investigate the
problem as soon I find the time for it ;)

But it sounds really promising!

If anybody is interested:
it seems that dovecot can be built with heimdal,
if that version check is removed from configure.in (it's probably invalid for
heimdal).

Should have specified: Iwas talking about 
app-crypt/heimdal-1.2 and
net-mail/dovecot-1.1.1

thx for that information. i am using dovecot as well as cyrus-imapd/cyrus-sasl
with heimdal 1.2.1_rc1. works perfectly. do you have other applications
(servers or clients) using heimdal?

it would also be a good idea to meet on irc as soon as possible to discuss the
next steps. probably at least on of the maintainers of the nfs packages should
attend that meeting too.

if we have dicussed our steps, we may probably send some or all of our patches
upstream so that other distributions can use them as well and we do not have to
maintain a lot gentoo-specific patches.

maybe as some kind of compromise we can create a "server" use flag that will
disable the built and installation of the server applications. that way we do
not need to split the ebuilds. it sould not be a big problem to patch configure
to provide a --disable-server option.

heimdal-1.2.1_rc2 pushed into overlay. Please test it ;)

Once again an update on the actual support state of heimdal in the kerberos
overlay:

[ n ] dev-libs/openssl-0.9.8g (kerberos? app-crypt/mit-krb5)

[-c-] app-crypt/kstart-3.12 (virtual/krb5)
[---] app-editors/emacs-22.2-r2 (kerberos? virtual/krb5)
[-c-] dev-util/cvs-1.12.12-r4 (kerberos? virtual/krb5)
[   ] gnome-base/gnome-vfs-2.20.1-r1 (kerberos? virtual/krb5)
[-c-] kde-base/kdelibs-3.5.9-r4 (kerberos? virtual/krb5)
[-c-] net-fs/openafs-1.4.7 (kerberos? virtual/krb5)
[-c-] net-misc/curl-7.18.2 (kerberos? virtual/krb5)
[-c-] net-misc/neon-0.26.4 (kerberos? virtual/krb5)
[-c-] net-misc/openssh-4.7_p1-r6 (kerberos? virtual/krb5)
[-c-] net-nds/openldap-2.3.41 (!minimal & kerberos? virtual/krb5)
[-c-] net-print/cups-1.3.7-r1 (kerberos? virtual/krb5)
[-c-] sys-auth/nss_ldap-258 (kerberos? virtual/krb5)
[   ] sys-auth/pam-afs-session-1.6 (virtual/krb5)
[---] sys-auth/pam_krb5-3.10 (virtual/krb5)
[-c-] net-firewall/ipsec-tool
[-c-] dev-lang/php-5.2.6-r1
[-c-] dev-libs/cyrus-sasl-2.1.22-r2
[-c-] dev-perl/GSSAPI-0.24
[-c-] gnome-base/gnome-vfs-2.22.0
[-c-] gnome-extra/evolution-data-server-2.22.1.1
[-c-] mail-client/evolution-2.22.1.1
[-c-] net-analyzer/wireshark-1.0.0
[-c-] net-fs/nfs-utils-1.1.0-r1 (kerberos? app-crypt/mit-krb5)
[-c-] net-libs/librpcsecgss-0.18
[-c-] net-mail/fetchmail-6.3.8-r1

time to push it into tree?? ;)

g, mueli

little mistakes in last post - gnome-vfs and pam-afs-session now also tested to
compile ;)

[ n ] dev-libs/openssl-0.9.8g (kerberos? app-crypt/mit-krb5)

[-c-] app-crypt/kstart-3.12 (virtual/krb5)
[---] app-editors/emacs-22.2-r2 (kerberos? virtual/krb5)
[-c-] dev-util/cvs-1.12.12-r4 (kerberos? virtual/krb5)
[-c-] gnome-base/gnome-vfs-2.20.1-r1 (kerberos? virtual/krb5)
[-c-] kde-base/kdelibs-3.5.9-r4 (kerberos? virtual/krb5)
[-c-] net-fs/openafs-1.4.7 (kerberos? virtual/krb5)
[-c-] net-misc/curl-7.18.2 (kerberos? virtual/krb5)
[-c-] net-misc/neon-0.26.4 (kerberos? virtual/krb5)
[-c-] net-misc/openssh-4.7_p1-r6 (kerberos? virtual/krb5)
[-c-] net-nds/openldap-2.3.41 (!minimal & kerberos? virtual/krb5)
[-c-] net-print/cups-1.3.7-r1 (kerberos? virtual/krb5)
[-c-] sys-auth/nss_ldap-258 (kerberos? virtual/krb5)
[-c-] sys-auth/pam-afs-session-1.6 (virtual/krb5)
[---] sys-auth/pam_krb5-3.10 (virtual/krb5)
[-c-] net-firewall/ipsec-tool
[-c-] dev-lang/php-5.2.6-r1
[-c-] dev-libs/cyrus-sasl-2.1.22-r2
[-c-] dev-perl/GSSAPI-0.24
[-c-] gnome-base/gnome-vfs-2.22.0
[-c-] gnome-extra/evolution-data-server-2.22.1.1
[-c-] mail-client/evolution-2.22.1.1
[-c-] net-analyzer/wireshark-1.0.0
[-c-] net-fs/nfs-utils-1.1.2-r2
[-c-] net-libs/librpcsecgss-0.18
[-c-] net-mail/fetchmail-6.3.8-r3

... I can see the light at the end of the tunnel ...

A small question first:
about fetchmail:
maybe it's just me, cause I've got '-Wl,--as-needed'
or maybe it's just me, cause I've got only heimdal installed,
but bug 185652 is still valid for me.
Fetchmail still fails to build with heimdal,
due to reasons stated there and builds with the patch I've attached there,
though by now only needed part of the patch is the block,
that changes ' AC_CHECK_LIB(ssl, MD5_Init, [],' to
'AC_CHECK_LIB(crypto, MD5_Init, [],'.

And wouldn't it be a good idea to drop krb4 for fetchmail,
upstream has officially stated that krb4 can be no longer treated as 
any security.

Created an attachment (id=160062) [details]
patch for fetchmail configure.ac to remove the check for MD5_Init.

the patch works with "kerberos ssl", "kerberos -ssl" and of course "-kerberos
ssl".

Created an attachment (id=160064) [details]
updated ebuild patch for fetchmail

It's really hard for me to keep overview if all packages are inside this bug.
I'd really appreciate if you could visit the corresponding bugs for each
package:

- nfs-utils : #231396
- fetchmail : #231400
- librpcsecgss : #231395

It'd would make my job easier ;) Once again a great thanks to all of you!

g, mueli

just open one bug per package and have those block this bug
makes tracking stuff a lot easier

Ack. Have added all the blockers and deps. Now it should be really clear to all
of us ... even me ;)

While trying to figure out why my kftpd does not work, I ran it in the
foreground:

# /usr/sbin/kftpd -i -a plain
kftpd: socket af = 10: Address family not supported by protocol

It seems like it tries to run IPV6 on my system with USE lacking "ipv6". Still
would believe IPV4-only is the default.



>>> Emerging (1 of 1) app-crypt/heimdal-1.2.1_rc1-r1 to /
 * heimdal-gentoo-patches-0.2.tar.bz2 RMD160 SHA1 SHA256 size ;-) ...          
                                                                               
                                                                [ ok ]
 * heimdal-1.2.1rc1.tar.gz RMD160 SHA1 SHA256 size ;-) ...                     
                                                                               
                                                                [ ok ]
 * checking ebuild checksums ;-) ...                                           
                                                                               
                                                                [ ok ]
 * checking auxfile checksums ;-) ...                                          
                                                                               
                                                                [ ok ]
 * checking miscfile checksums ;-) ...                                         
                                                                               
                                                                [ ok ]
 * checking heimdal-1.2.1rc1.tar.gz ;-) ...                                    
                                                                               
                                                                [ ok ]
 * checking heimdal-gentoo-patches-0.2.tar.bz2 ;-) ...                         
                                                                               
                                                                [ ok ]
>>> Unpacking source...
>>> Unpacking heimdal-1.2.1rc1.tar.gz to /var/tmp/portage/app-crypt/heimdal-1.2.1_rc1-r1/work
>>> Unpacking heimdal-gentoo-patches-0.2.tar.bz2 to /var/tmp/portage/app-crypt/heimdal-1.2.1_rc1-r1/work
 * Applying various patches (bugfixes/updates) ...
 *   001_all_heimdal-no_libedit.patch ...                                      
                                                                               
                                                                [ ok ]
 *   002_all_heimal-fPIC.patch ...                                             
                                                                               
                                                                [ ok ]
 *   003_all_heimdal-rxapps.patch ...                                          
                                                                               
                                                                [ ok ]
 *   005_all_heimdal-suid_fix.patch ...                                        
                                                                               
                                                                [ ok ]
 *   012_all_heimdal-berkdb.patch ...                                          
                                                                               
                                                                [ ok ]
 *   013_all_heimdal-pthread-lib.patch ...                                     
                                                                               
                                                                [ ok ]
 *   014_all_heimdal-path.patch ...                                            
                                                                               
                                                                [ ok ]
 *   022_all_heimdal-as-needed.patch ...                                       
                                                                               
                                                                [ ok ]
 * Done with patching
 * Applying heimdal-r23238-kb5_locl_h-wind_h.patch ...                         
                                                                               
                                                                [ ok ]
 * Applying heimdal-r23235-kb5-libwind_la.patch ...                            
                                                                               
                                                                [ ok ]
 * Applying heimdal-kdc-sans_pkinit.patch ...                                  
                                                                               
                                                                [ ok ]
 * Applying heimdal-system_sqlite.patch ...                                    
                                                                               
                                                                [ ok ]
 * Running eautoreconf in
'/var/tmp/portage/app-crypt/heimdal-1.2.1_rc1-r1/work/heimdal-1.2.1rc1' ...
 * Running aclocal -I cf -I cf ...                                             
                                                                               
                                                                [ ok ]
 * Running libtoolize --copy --force --install --automake ...                  
                                                                               
                                                                [ ok ]
 * Running aclocal -I cf -I cf ...                                             
                                                                               
                                                                [ ok ]
 * Running autoconf ...                                                        
                                                                               
                                                                [ ok ]
 * Running autoheader ...                                                      
                                                                               
                                                                [ ok ]
 * Running automake --add-missing --copy --foreign ...                         
                                                                               
                                                                [ ok ]
 * Running elibtoolize in: heimdal-1.2.1rc1
 *   Applying sed-1.5.6.patch ...
>>> Source unpacked.
>>> Compiling source in /var/tmp/portage/app-crypt/heimdal-1.2.1_rc1-r1/work/heimdal-1.2.1rc1 ...
 * econf: updating heimdal-1.2.1rc1/config.guess with
/usr/share/gnuconfig/config.guess
 * econf: updating heimdal-1.2.1rc1/config.sub with
/usr/share/gnuconfig/config.sub
./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib --without-ipv6 --enable-berkeley-db --disable-pk-init
--with-openssl --with-x --enable-pthread-support --disable-otp --enable-kcm
--enable-shared --enable-netinfo --prefix=/usr --libexecdir=/usr/sbin
--build=i686-pc-linux-gnu
...
checking for IPv6 stack type... 
checking for IPv6... 
checking for in6addr_loopback... 
...
^z
# grep IPV
/var/tmp/portage/app-crypt/heimdal-1.2.1_rc1-r1/work/heimdal-1.2.1rc1/config.status 
D["HAVE_IPV6"]=" 1"


config.log says:

configure:19299: checking for IPv6 stack type
conftest.c:89:45: error: /usr/local/v6/include/sys/types.h: No such file or
directory
configure:19441: result: 
configure:19444: checking for IPv6
configure:19494: i686-pc-linux-gnu-gcc  -o conftest -O2 -march=pentium4 -mmmx
-msse -msse2 -fomit-frame-pointer -pipe  -D_LARGE_FILES= -D_FILE_OFFSET_BITS=64
 conftest.c -lpthread  >&5
configure:19501: $? = 0
configure:19521: result: 
configure:19535: checking for in6addr_loopback
configure:19577: i686-pc-linux-gnu-gcc  -o conftest -O2 -march=pentium4 -mmmx
-msse -msse2 -fomit-frame-pointer -pipe  -D_LARGE_FILES= -D_FILE_OFFSET_BITS=64
 conftest.c -lpthread  >&5
configure:19584: $? = 0
configure:19604: result: 

Created an attachment (id=160721) [details]
disable ipv6 autodetection (proposed fix for #152)

I hope this patch will solve your problem. We will add this patch and the
sysmlinked manpages patch (#168591) as soon as possible to the ebuild.

(In reply to comment #153)
> Created an attachment (id=160721) [edit] [details]
> disable ipv6 autodetection (proposed fix for #152)
> 
> I hope this patch will solve your problem. We will add this patch and the
> sysmlinked manpages patch (#168591) as soon as possible to the ebuild.
> 

creating include/version.h
/var/tmp/portage/app-crypt/heimdal-1.2.1_rc1-r1/temp/environment: line 2850: [:
too many arguments
/var/tmp/portage/app-crypt/heimdal-1.2.1_rc1-r1/temp/environment: line 2850: [:
too many arguments
Making all in include


It does not help either. I do not see the variable defined anymore in
config.status. How about rather forcing it set to 0 (aka unset it)? Otherwise
someone should walk the sources and figure out why omitting it from defines
does not help.

Created an attachment (id=160772) [details]
updated version

The problem is a call to getaddrinfo in mini_inetd() in file
lib/roken/mini_inetd.c. It returns AF_INET6 although the kernel does not
support it. I think this is a glibc bug. getattrinfo should not return
unsupported network layer protocols.

(In reply to comment #154)

> It does not help either. I do not see the variable defined anymore in
> config.status. How about rather forcing it set to 0 (aka unset it)? Otherwise
> someone should walk the sources and figure out why omitting it from defines
> does not help.

I've just reviewed and commited the patch of mastamind into overlay. Could you
please test it?

Thx for your help,

mueli

(In reply to comment #155)
> Created an attachment (id=160772) [edit] [details]
> updated version

The patch makes it work. Thanks.

(In reply to comment #144)

pam-krb5 works correctly on x86 and amd64.

mastamind has reported the patch to upstream (thx for your big help) which Love
has included in his way. I've now backported the changes and created and
commited the new (but very similar) patch into overlay - feel free to test ;)

g, mueli

(In reply to comment #102)
> Do you accept this proceeding? If so, would you please close the bug? If you
> file a new one please assign it to kerberos@gentoo.org.
> 
> So far and thx for all the fish, mueli
> 

I was holding off on closing this bug until I had tested all of the software I
use with the new Heimdal version.  Once a bug is closed it becomes very
difficult to find, and I wanted people searching for "Heimdal" to have this
come up as one of the results.

I'm now satisfied that this bug has been fixed.  I even have NFSv4 working with
krb5 security thanks to #231395 and #231396 .  Thank you all for your great
work on this.

The only outstanding problem that bugs me is that I have to patch the overlay
to re-enable LDAP support since my principals are stored in LDAP.  I don't mind
building Heimdal twice (once with USE="-ldap") on my KDCs.  But that's a matter
for another bug.  (by the way, I think the solution is to use a new USE flag
for Heimdal, maybe called "hdb-ldap", so that people won't be able to produce
the circular dependency unless they explicitly opt for a special feature)

Now I am a bit annoying and reopen the bug ;) - just because of the dependency
tree and I am ATM using this bug as tracker for 1.2.x heimdal in gentoo.

BTW: I really like your suggestion with the new ldap USE called "hdb-ldap".
Does this solution anyone else bother? (I pushing it that way into overlay)

g, mueli

With the today's invention of sys-libs/e2fsprogs-libs,
ebuild of heimdal needs to be updated.

BTW, something may be wrong with configuration of gentoo gitweb for heimdal.
When I click on the ebuild of heimdal and then choose "raw",
I'm getting following address:
http://git.overlays.gentoo.org/gitweb/?p=proj/kerberos.git;a=blob_plain;f=app-crypt/heimdal/heimdal-1.2.1.ebuild;h=HEAD;hb=HEAD
but to see the file in the browser, it needs to be:
http://git.overlays.gentoo.org/gitweb/?p=proj/kerberos.git;a=blob_plain;f=app-crypt/heimdal/heimdal-1.2.1.ebuild;hb=HEAD
.

Created an attachment (id=163190) [details]
Allow for e2fsprogs-libs

(In reply to comment #162)
> With the today's invention of sys-libs/e2fsprogs-libs,
> ebuild of heimdal needs to be updated.

This patch to the git overlay should fix that issue, by allowing e2fsprogs-libs
instead of com_err or ss. As an alternative to applying this patch, you can
also execute these commands in the heimdal directory of the overlay:

sed -i \
 's:sys-libs/\(com_err\|ss\):|| ( sys-libs/\1 sys-libs/e2fsprogs-libs ):' \
 *.ebuild
for i in *.ebuild; do ebuild $i digest; done

(From update of attachment 155335 [details])
As the kerberos overlay is now included in the master list of layman overlays,
a separate config file is no longer needed. Simply type "layman -a kerberos" to
add the overlay.

I'd say it's time to close this bug. heimdal-1.2 is in tree. Stabilization
shouldn't be part of this bug here.

g, mueli