I emerged nmh-1.3 on a system with no liblockfile package merged. The emerge was successful, many of the parts of nmh appeared to work properly. However, mail delivery via the slocal program fails with a "no such file" message about my mbox file. I created a simple test case to expose the failure. I then emerged liblockfile and re-emerged nmh-1.3. The test case then completed successfully. Reproducible: Always Steps to Reproduce: 1. Obtain a properly formed email message as delivered by a MTA. I used one from my previously existing inbox. 2. Save it in a convenient file 3 unmerge liblockfile if necessary 4.emerge =mail-client/nmh-1.3 5.as (ordinary) user fellows (substitute user as convenient) do the following. 6.mh_install # if not previously done 7.slocal -user fellows -verbose -debug -file /home/fellows/Mail/inbox/182 #(/home/fellows/Mail/inbox/182 is my convenient file from step 2) Actual Results: .forward file parsing information followed after a 60 second delay. delivering to file "/var/spool/mail/fellows" (mbox style), unable to open:No such file or directory (delivering to standard mail spool) delivering to file "/var/mail/fellows" (mbox style), unable to open:No such file or directory Expected Results: .forward parsing info followed without delay by delivering to file "/var/spool/mail/fellows" (mbox style), success. and the mail message is appended to /var/spool/mail/fellows My understanding is that nmh will use liblockfile preferentially if it is present and falls back to flock. Evidently the fallback is not without error. I have filed a bug against this upstream https://savannah.nongnu.org/bugs/index.php?25043 I have been using nmh-1.1 built from an overlay that adds --with-locking=lockf to the configure command for years. I am now of the opinion that using the services provided by liblockfile are more robust for general use. I would suggest that this bug be resolved by updating the nmh-1.3 ebuild to 1.3-r1 by adding net-libs/liblockfile to the DEPEND list. If upstream fixes it "properly" that's OK, if not it won't matter. emerge --info Portage 2.1.4.5 (default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.20-gentoo-r8 x86_64) ================================================================= System uname: 2.6.20-gentoo-r8 x86_64 AMD Opteron(tm) Processor 246 Timestamp of tree: Fri, 05 Dec 2008 02:36:01 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.4.4-r13, 2.5.2-r7 dev-python/pycrypto: 2.0.1-r6 dev-util/cmake: 2.4.6-r1 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r2 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php4/ext-active/ /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php4/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php4/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.mirrors.tera-byte.com/ http://gentoo.osuosl.org/ " MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl alsa amd64 berkdb cairo cli cracklib crypt cups dbus doc dri exif flac fortran gcj gdbm gnome gpm gtk guile iconv ipv6 isdnlog java jpeg lcms midi mmx mp3 mudflap ncurses nls nptl nptlonly nsplugin ogg opengl openmp pam pcre perl png pppd python readline reflection session spl sse sse2 ssl tcltk tcpd tiff truetype unicode vorbis xorg zlib" ALSA_CARDS="cmipci via82xx" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" CAMERAS="konica minolta" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="nv radeon vga fbdev vesa" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Yea, automagic deps are *not* ok. They cause more harm then good. Following your advice of adding liblockfile to DEPEND for now. If that upstream bug ever gets resolved please file a new Gentoo bug for it. Thanks.
For the record: I added --with-locking=lockf to my 1.3-r90 overlay ebuild, unmerged liblockfile and re-emerged nmh. comp, send, and slocal all worked fine. I then package.masked -r90, did emerge --sync followed by emerge -puv nmh Calculating dependencies... done! [ebuild N ] net-libs/liblockfile-1.06-r2 32 kB [ebuild UD] mail-client/nmh-1.3-r1 [1.3-r90] 0 kB Removed -p. and emerged. nmh-1.3-r1 passes all my tests. Thanks for the quick resolution
(In reply to comment #1) > Yea, automagic deps are *not* ok. They cause more harm then good. Following > your advice of adding liblockfile to DEPEND for now. If that upstream bug ever > gets resolved please file a new Gentoo bug for it. Thanks. > I'll try to remember. But I think using liblockfile is the better way to go anyway. It apparently handles NFS mounted mail directories better than the alternatives.
