Bugzilla Bug 140775

- 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