Trying to emerge it with ldap use set results in: >>> Emerging (6 of 9) net-misc/openssh-5.4_p1 * openssh-5.4p1.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * CPV: net-misc/openssh-5.4_p1 * REPO: gentoo * USE: X amd64 elibc_glibc kernel_linux ldap multilib pam tcpd userland_GNU * Sorry, but this version does not yet support features * that you requested: ldap * Please mask openssh-5.4_p1 for now and check back later: * # echo '=net-misc/openssh-5.4_p1' >> /etc/portage/package.mask * ERROR: net-misc/openssh-5.4_p1 failed: * booooo * * Call stack: * ebuild.sh, line 54: Called pkg_setup * openssh-5.4_p1.ebuild, line 62: Called die * The specific snippet of code: * die "booooo" * * If you need support, post the output of 'emerge --info =net-misc/openssh-5.4_p1', * the complete build log and the output of 'emerge -pqv =net-misc/openssh-5.4_p1'. * The complete build log is located at '/var/tmp/portage/net-misc/openssh-5.4_p1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/net-misc/openssh-5.4_p1/temp/die.env'. * S: '/var/tmp/portage/net-misc/openssh-5.4_p1/work/openssh-5.4p1' Reproducible: Always
Please read the emerge output and - maybe - the ebuild. Someone (i think vapir who committed the ebuild - see $Header of ebuild) knows about this and apologizes for the problem and gives a workaround.
I did read the error log ;) And then I filed this bugreport because I think something's wrong ;) There's an easy workaround in emerging the ebuild without ldap for me but in general, if an ebuild recognizes a specific useflag and emerge doesn't complain "at the beginning" but then fails when the package is about to be emerged IMHO this warrants a bugreport. Or am I wrong here?
Ok. I see your point with the annoying runtime failure of the emerge process ans tested EMERGE_DEFAULT_OPTS --keep-going for a while. There's a possibility to mask the ldap use flag for this package in the default profile (/usr/portage/profiles/default/linux/package.use.mask. That would lead to an exclusion and "(ldap)" output with emerge --ask --verbose, which can be overseen. I would follow the ebuild writer with his "don't break remote access" policy and use this flag. Other packages like >gnome-base/gdm-2.26 had been hard masked for feature regressions. It's possible to handle this as blocker of a stabilization request, too. ... I've tested the patch from the 5.3 version (/usr/portage/distfiles/openssh-lpk-5.3p1-0.3.11.patch.gz) against the 5.4 WORKDIR and it succeeded mostly. The version numbers in the paths where wrong and the place of the additional ldapauth.o entry in the Makefile.in moved some lines down. I'll commit the changed patch.
Created attachment 225617 [details] changed Makefile.in hunk see http://svn.xmw.de/gentoo-overlay/net-misc/openssh/ for further info/files/layman ...
no, simply ignoring USE=ldap when the ldap patch is unavailable is unacceptable. we dont want to let people to silently emerge openssh on systems that use ldap and then make the machine unaccessible. so, this report is invalid unless a patch is provided. since i see one is, Robin can take a look at it.
my version of the patches have already been sent to upstream, and will be included soon, I'm just trying to work out some conflicts with other patches. The individual patches are available here: http://dev.gentoo.org/~robbat2/ssh-patches/
Revbump with HPN and LPK patches available again now. Ported and submitted to upstream authors. X509 now has more conflicts with HPN, future revisions may require selection of: x509 XOR (hpn OR lpk). The upstream LPK changes also started to touch version.h, so some mangling was required there since lots of patches touch that file now.
