The init script fails to start the server. start-stop-daemon does not find XMail executable, looks like it is not looking in the chroot folder but in the root folder (instead of executing /chroot/xmail/var/MailRoot/bin/XMail it wants to execute /var/MailRoot/bin/XMail). Reproducible: Always Steps to Reproduce: 1. unmask xmail 2. emerge xmail 3. start xmail init script Actual Results: * Starting XMail ... start-stop-daemon: Unable to start /var/MailRoot/bin/XMail: No such file or directory Expected Results: The xmail server should start Portage 2.0.51.22-r2 (default-linux/amd64/2005.1, gcc-3.4.3, glibc-2.3.5-r0, 2.6.14-gentoo-r2 x86_64) ================================================================= System uname: 2.6.14-gentoo-r2 x86_64 AMD Sempron(tm) Processor 3000+ Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5-r2 sys-apps/sandbox: 1.2.11 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -pipe -O2" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=k8 -pipe -O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo " MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="amd64 X alsa avi berkdb bitmap-fonts bzip2 cdr crypt cups dvd eds emboss encode expat fam foomaticdb fortran gif gpm gstreamer gtk gtk2 idn imlib ipv6 jpeg kde lcms libwww lzw lzw-tiff mhash mng mp3 mpeg mysql ncurses nls opengl pam pcre pdflib perl png python qt quicktime readline sdl spell ssl tcpd tiff truetype truetype-fonts type1-fonts udev usb userlocales xml2 xpm xv zlib video_cards_via userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
Did you run xmailwizard after emerge?
(In reply to comment #1) > Did you run xmailwizard after emerge? I tried it now, but xmailwizard also attempts to start xmail and produces a same error.
Is your /etc/conf.d/xmail set up properly for the chroot?
(In reply to comment #3) > Is your /etc/conf.d/xmail set up properly for the chroot? I didn' modify that file but I think it is correct. # all files are relative to this folder CHROOT="/chroot/xmail" MAIL_ROOT=/var/MailRoot export CHROOT MAIL_ROOT
I have resolved this bug myself. The problem is that the xmail binary in /chroot/xmail/var/MailRoot/bin/XMail was linked to the dynamic linker /lib64/ld-linux-x86-64.so.2, but there was no 'lib64' in /chroot/xmail, only 'lib'. I solved the problem by linking lib64 to lib. I hope you change the ebuild now.
(In reply to comment #5) > I have resolved this bug myself. Please, don't close bugs until they are fixed in portage... ;) > > The problem is that the xmail binary in /chroot/xmail/var/MailRoot/bin/XMail > was linked to the dynamic linker /lib64/ld-linux-x86-64.so.2, but there was no > 'lib64' in /chroot/xmail, only 'lib'. I solved the problem by linking lib64 to > lib. Ah... Well, this is not keyworded for amd64 at all, seems that it works w/ this little fix. CCing amd64.
I'm reporting an additional problem and a fix for amd64: DNS resolving doesn't work. To solve this problem /lib/libnss_dns-2.3.5.so must be copied to /chroot/xmail/lib and libnss_dns.so.2 linked to it, AND /etc/resolv.conf must be copied to /chroot/xmail/etc/resolv.conf.
is this a keywording request? If yes, please provide a patch to make it running. If no, I'm sorry, but we can't support packages that aren't keyworded amd64, we have to concentrate on those that are already keyworded but broken. Feel free to reopen anytime you have a patch, though.