As in the title, emerge fails near the end of the install phase, with: chmod: cannot access '/var/tmp/portage/sys-fs/zfs-2.0.0_rc1-r1/image/etc/conf.d/zfs': No such file or directory The file does not in fact exist. Reproducible: Always
Created attachment 657090 [details] build.log
do you by chance define INSTALL_MASK to avoid /etc/conf.d files installation?
please attach `emerge --info`
In build log: checking os distribution... redhat checking default package type... rpm checking default init directory... /etc/init.d checking default init script type and shell... redhat:/bin/sh checking default nfs server init script... nfs checking default init config directory... /etc/sysconfig In config/zfs-build.m4: AC_DEFUN([ZFS_AC_DEFAULT_PACKAGE], [ AC_MSG_CHECKING([os distribution]) if test -f /etc/toss-release ; then VENDOR=toss ; elif test -f /etc/fedora-release ; then VENDOR=fedora ; elif test -f /etc/redhat-release ; then VENDOR=redhat ; elif test -f /etc/gentoo-release ; then VENDOR=gentoo ; elif test -f /etc/arch-release ; then VENDOR=arch ; ... AC_MSG_CHECKING([default init config directory]) case "$VENDOR" in alpine) initconfdir=/etc/conf.d ;; gentoo) initconfdir=/etc/conf.d ;; toss) initconfdir=/etc/sysconfig ;; redhat) initconfdir=/etc/sysconfig ;; fedora) initconfdir=/etc/sysconfig ;; sles) initconfdir=/etc/sysconfig ;; ubuntu) initconfdir=/etc/default ;; debian) initconfdir=/etc/default ;; freebsd) initconfdir=$sysconfdir/rc.conf.d;; *) initconfdir=/etc/default ;; esac AC_MSG_RESULT([$initconfdir]) AC_SUBST(initconfdir) Why /etc/redhat-release exists for you? Which package owns this file?
we had similar bug before https://bugs.gentoo.org/712902 user created those files manually. I probably should add a early fail into ebuild if it detects this file.
If somebody cares about working with upstream, the code could be improved by checking e.g. ${ZFS_VENDOR} variable before checking all of those files. Then ebuild could set this variable before calling econf: local -x ZFS_VENDOR="gentoo"
Ah right, this because of the redhat-release file (I haven't modified INSTALL_MASK). I have that file as a workaround for some very broken closed software (Xilinx Vivado), which behaves better when it thinks it's on redhat. Temporarily renaming it fixes the ebuild, thanks.
Created attachment 657192 [details] emerge --info -v Attaching for completeness.
I've opened pull request to add explicit `--with-vendor=gentoo` configure flag, since you are not the first person to hit it. it's better than crashing.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b87f490d0b7e66e51cc2c9d159ebee1e238db9f1 commit b87f490d0b7e66e51cc2c9d159ebee1e238db9f1 Author: Georgy Yakovlev <gyakovlev@gentoo.org> AuthorDate: 2020-08-28 19:15:36 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2020-08-28 19:52:13 +0000 sys-fs/zfs: update live ebuild, pass --with-vendor=gentoo Upstream PR: https://github.com/openzfs/zfs/pull/10835 Bug: https://bugs.gentoo.org/712902 Bug: https://bugs.gentoo.org/739234 Package-Manager: Portage-3.0.4, Repoman-3.0.1 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> sys-fs/zfs/zfs-9999.ebuild | 1 + 1 file changed, 1 insertion(+)
ok closing, all current 2.* ebuilds pass --with-vendor, 0.8.* still remains affected by this though.
