- Tested application and all is working Portage 2.0.51.22-r2 (default-linux/amd64/2005.1, gcc-3.4.3, glibc-2.3.5-r0, 2.6.12-gentoo-r8 x86_64) ================================================================= System uname: 2.6.12-gentoo-r8 x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.6.12 dev-lang/python: 2.3.5 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" ASFLAGS="" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-g -ggdb" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /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="-g -ggdb" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig buildpkg cvs debug distlocks keeptemp keepwork multilib-strict nostrip sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.blueyonder.co.uk" LDFLAGS="" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage-overlay" SYNC="rsync://rsync.uk.gentoo.org/gentoo-portage" USE="amd64 X alsa avi bash-completion berkdb bitmap-fonts crypt cups eds encode foomaticdb fortran gif gnome gpm gstreamer gtk gtk2 imlib ipv6 jpeg kde lzw lzw-tiff mp3 mpeg ncurses nls opengl pam pdflib perl png python qt quicktime readline sdl spell ssl tcpd tiff truetype-fonts type1-fonts usb userlocales xpm xv zlib userland_GNU kernel_linux elibc_glibc" Unset: CTARGET, LANG, LC_ALL, LINGUAS, MAKEOPTS
Uhm, upstream says "it does not work" (see http://sourceforge.net/mailarchive/forum.php?thread_id=23836054&forum_id=2697 first post, last paragraph). I would advise against adding ~amd64, especially since we are dealing with a file system driver here. Yes, this is experimental, everybody messing around with it should expect data loss, but adding ~ARCH while upstream explicitly says "doesn't work" sounds like a bad idea...
Well maybe not keyword it direct but use this bug as a tracker for issues ? No compile issues here and everything seems to work, and some stress testing probably wont go a miss, but completely ignoring that it does work seems a bit over the top and the devs only say they don't have the hardware but the code is fully amd64 compatible as far as compilation is concerned.
Szaka said that it does not work, because he had not tested it on AMD64. linux-ntfs team received a lot of reports that it working, feel free to add ~amd64
Okay ~amd64
