Reason: most importantly: openafs-kernel-1.4.1 doesn't build against a linux >= 2.6.18 Remark: net-fs/openafs-kernel-1.4.2 and net-fs/openafs-1.4.2 have gone through their 30 day waiting period. net-fs/openafs-kernel-1.4.2-r1 has not. The change in openafs-kernel-1.4.2-r1 is only incremental, to facilitate building on amd64 when CONFIG_KEYS is not enabled in the kernel. I have used this ebuild extensively on amd64 without problems, but it's of course up to the arch teams to decide what to do with this. Usefulness on: amd64: very, even 1.4.1 hasn't been stabled (and 1.4.0 doesn't work on recent kernels) ia64, ppc64, x86: gentoo-sources-2.6.18 is stable on these platforms alpha, ppc: not urgent, as there's no 2.6.18 kernel in stable, but still openafs-1.4.2 has useful bugfixes Thanks!
They seem to be doing fine on amd64, though i haven't run any long-time tests... Portage 2.1.1-r2 (default-linux/amd64/2006.1/desktop, gcc-4.1.1, glibc-2.4-r4, 2.6.18-suspend2-Dudebox-Edition x86_64) ================================================================= System uname: 2.6.18-suspend2-Dudebox-Edition x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.12.6 Last Sync: Wed, 22 Nov 2006 05:00:01 +0000 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.3 [enabled] app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.3 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r4 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -msse3 -Os -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/X11/xkb /usr/share/config /var/qmail/alias /var/qmail/control" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=k8 -msse3 -Os -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache collision-protect distcc distlocks metadata-transfer multilib-strict parallel-fetch sandbox sfperms strict test" GENTOO_MIRRORS="ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/" LDFLAGS="-Wl,-O1" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage_overlay" SYNC="rsync://server/gentoo-portage" USE="amd64 X alsa apache2 berkdb bitmap-fonts cairo cdr cli cracklib crypt cups dbus dlloader dri dvd dvdr eds elibc_glibc emboss encode esd fam firefox fortran gcj gdbm gif gpm gstreamer gtk gtk2 hal iconv imap input_devices_keyboard input_devices_mouse isdnlog jpeg kde kdeenablefinal kdehiddenvisibility kernel_linux libg++ mad mikmod mp3 mpeg mysql ncurses nls nptl nptlonly objc objc++ ogg oss pam pcre perl png ppds pppd python qt3 quicktime readline reflection sdl session spell spl sqlite ssl tcpd test truetype truetype-fonts type1-fonts udev unicode userland_GNU video_cards_radeon vorbis xml xorg xv zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS
let's risk it. amd64 stable.
x86 joins in
ppc64 stable
Works fine on alpha as well. Now stable on alpha.
Marked ppc stable.
Fails on IA-64... http://dev.gentoo.org/~wolf31o2/openafs-error.txt
(In reply to comment #7) > Fails on IA-64... http://dev.gentoo.org/~wolf31o2/openafs-error.txt > Is this an issue of non-PIC code inside a shared library? If so, isn't amd64 very similar to ia64 when it comes to PIC/non-PIC, or are there differences?
Hrm... I'm talking about 1.4.4: Using -D_USE_UCONTEXT in the CFLAGS, using the ebuild, it fails with the same error as Chris. *But*, if i build it using the tarball, it fails with the LWP thingy, like the ebuild. However, if i use the UCONTEXT thingy, it compiles cleanly. I think the ./regen.sh in the ebuild is what makes that error of Chris. But if you don't run ./regen.sh, it doesn't respect the CFLAGS. To make the CFLAGS in the tarball include the DUSE_UCONTEXT flag, i had to edit src/config/Makefile.config.
Since this doesn't work anymore on ia64, i dropped the keyword. Closing.
For the record, regen.sh triggers the building error, when it is omitted, it works (tested by armin76) regen.sh is required for applying patches cleanly, and in theory shouldn't trigger any of this, but as interest is probably low, and we don't see a solution right away, the keyword is dropped
