nfs-utils-1.2.9-r3.ebuild : DEPEND -=- >=dev-libs/libevent-1.0b nfs-utils-1.2.9-r3.ebuild : RDEPEND -=- >=dev-libs/libevent-1.0b nfs-utils-1.3.1-r4.ebuild : DEPEND -=- <=dev-libs/libevent-2.1 nfs-utils-1.3.1-r4.ebuild : RDEPEND -=- <=dev-libs/libevent-2.1 nfs-utils-1.3.1-r5.ebuild : DEPEND -=- <=dev-libs/libevent-2.1 nfs-utils-1.3.1-r5.ebuild : RDEPEND -=- <=dev-libs/libevent-2.1 nfs-utils-1.3.2-r6.ebuild : DEPEND -=- dev-libs/libevent:= nfs-utils-1.3.2-r6.ebuild : RDEPEND -=- dev-libs/libevent:= nfs-utils-1.3.3.ebuild : DEPEND -=- dev-libs/libevent:= nfs-utils-1.3.3.ebuild : RDEPEND -=- dev-libs/libevent:= nfs-utils-1.3.4.ebuild : DEPEND -=- dev-libs/libevent:= nfs-utils-1.3.4.ebuild : RDEPEND -=- dev-libs/libevent:=
Please note that this bug blocks a security bug.
*** Bug 608860 has been marked as a duplicate of this bug. ***
Arches please test and mark stable =net-fs/nfs-utils-1.3.4 with target KEYWORDS: alpha amd64 arm ~arm64 hppa ia64 ~mips ppc ppc64 ~s390 ~sh sparc x86
Stopping stabilization, as we first need to get fixed bug #548208
Is there anything that can be done to stabilize this? Ever since libevent 2.1.8 has been stabilized 10 days ago everyone who uses both stable nfs-utils as well as stable libevent gets this blocker: dev-libs/libevent:0 (dev-libs/libevent-2.1.8:0/2.1-6::gentoo, ebuild scheduled for merge) conflicts with <=dev-libs/libevent-2.1 required by (net-fs/nfs-utils-1.3.1-r5:0/0::gentoo, installed) ^^ ^^^
(In reply to Lars Wendler (Polynomial-C) from comment #4) > Stopping stabilization, as we first need to get fixed bug #548208 AFAIK this is not a regression and current stable nfs-utils also has this bug.
*** Bug 609550 has been marked as a duplicate of this bug. ***
(In reply to Alexander Tsoy from comment #6) > (In reply to Lars Wendler (Polynomial-C) from comment #4) > > Stopping stabilization, as we first need to get fixed bug #548208 > > AFAIK this is not a regression and current stable nfs-utils also has this > bug. It does not, current stable works as it defaults to svcgssd on and later versions defaults to off. This breaks for current openrc users. It is not even hard to fix, just add $(use_enable kerberos svcgss) to nfs-utils so svcgssd is built. The you can focus on gss-proxy
I did my own version of nfs-utils-1.3.4 just to make sure I had a working one and then I got this: The following keyword changes are necessary to proceed: (see "package.accept_keywords" in the portage(5) man page for more details) # required by net-nds/rpcbind-0.2.4::gentoo # required by net-fs/nfs-utils-1.3.4-r1::transmode # required by @selected # required by @world (argument) =net-libs/libtirpc-1.0.1 ~amd64 # required by net-fs/nfs-utils-1.3.4-r1::transmode # required by @selected # required by @world (argument) =net-nds/rpcbind-0.2.4 ~amd64 So it seems =net-libs/libtirpc-1.0.1 and =net-nds/rpcbind-0.2.4 needs stabilization too?
I just tested to upgrade 1.3.4 and my NFSv4 mounts broke(hung). No idea why, back on 1.3.1-r6(with libevent patch)
(In reply to Joakim Tjernlund from comment #10) > No idea why, back on 1.3.1-r6(with libevent patch) Can you please share your ebuild and libevent patch. Do you mean that you made your own =dev-libs/libevent-2.0.22 fixed with your patch ? It's been several weeks that =dev-libs/libevent-2.1.8 was stabilized on several archs, and on various stable systems that use NFSv4 I'm unable to upgrade because of nfs-utils. Nothing seems to move. Nobody communicates. At this point it becomes ridiculous. Is There Anybody Out There? (©)
Created attachment 465796 [details, diff] Patch nfs-utils to build with newer libevent
Created attachment 465798 [details] nfs-utils-1.3.1-r6.ebuild with libevent patch
Thanks.
Patched nfs-utils builds and boots fine on ARM. Thanks!
arm stable
ppc ppc64 stable.
Stable for HPPA.
commit 1dfbfb794811d42b29d95dc15e454b6ffeaf52aa Author: Agostino Sarubbo <ago@gentoo.org> Date: Thu Feb 9 15:36:11 2017 +0100 dev-libs/libevent: amd64 stable wrt bug #608042 Package-Manager: portage-2.3.3 RepoMan-Options: --include-arches="amd64" Signed-off-by: Agostino Sarubbo <ago@gentoo.org> The AMD64 tree has been broken since then?
(In reply to Jeroen Roovers from comment #19) > The AMD64 tree has been broken since then? Yes, that looks about right. According to various emerge.logs and package.masks I have boxes where I removed nfs-utils just after that date, and other boxes where I've masked >libevent-2.0 just after that date.
alpha/ia64 stable
See comment #5 it is still relevant. I have been forced to change all my work stations from using tmux to screen because of this. Are there any intentions of getting nfs-utils up to speed with were everyone else has been for over a month now? (dev-libs/libevent-2.1.8:0/2.1-6::gentoo, binary scheduled for merge) pulled in by >=dev-libs/libevent-2.1.5-r4 required by (app-misc/tmux-2.2:0/0::gentoo, installed) ^^ ^^^^^^^^ (dev-libs/libevent-2.0.22:0/0::gentoo, installed) pulled in by <=dev-libs/libevent-2.1 required by (net-fs/nfs-utils-1.3.1-r5:0/0::gentoo, installed) ^^
Stable for AMD64 x86.
Can we have --enable-svcgss added to the configure stage of this ebuild net-nds/gss-proxy is currently unstable and using the configure switch will enable stable users to continue to mount nfsv4 with kerberos.
(In reply to Bill Prendergast from comment #24) > Can we have > --enable-svcgss > added to the configure stage of this ebuild > net-nds/gss-proxy is currently unstable and using the configure switch will > enable stable users to continue to mount nfsv4 with kerberos. You wanted to address this to bug #548208 I guess?
I hit the bug https://bugs.gentoo.org/show_bug.cgi?id=618544 emerging nfs-utils-1.3.4-r1 on my stable hardened amd64 box. See the comments under that bug.
net-fs/nfs-utils-1.3.4-r1 fails to compile. Flags set: [ebuild U ] net-fs/nfs-utils-1.3.4-r1::gentoo [1.3.4::gentoo] USE="ipv6 libmount nfsidmap nfsv4 nfsv41 tcpd uuid -caps -kerberos -nfsdcld (-selinux)" 0 KiB Error: checking for Kerberos v5... configure: error: Kerberos v5 with GSS support not found: consider --disable-gss or --with-krb5=
sparc was dropped to exp. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b5901d8f716555a1479f12313a2925fcadd177a9
seems that this version was stabilized finally
