I have set up this tracker bug to deal with issues arising from the new 2005.0 amd64 profile. I have installed from a stage 3 tarball from the 2004.3-r1 release, and upgraded as detailed in the 2005.0 README file. openmotif compilation failed due to -D__i386__, this has been fixed by eradicator, and verified to now work. app-doc/doxygen-1.3.8 fails if the qt USE flag is set as it checks for the existence of /usr/qt/3/lib, temporarily fixed by symlinking to /usr/qt/3/lib64 - this needs fixing properly. net-nds/portmap-5b-r8 - enewuser fails with syntax warnings from useradd. I haven't had time to determine the cause as everything looks fine in the eclass and using the equivalent command line by hand worked - possibly due to the IFS problem below though. All KDE apps failed repoman scan in local CVS repository, and failed to compile or even configure. I have tracked this down to a problem in profiles/default-linux/amd64/2005.0/profile.bashrc with IFS being unset and not restored (I think). Simply removing all the lines referring to IFS has remedied the problem, although the function should be rewritten - I cannot find where save/restore_IFS come from. sys-devel/libperl-5.8.5 and dev-lang/perl-5.8.5-r2 would not compile, but this has also been resolved by correcting the above profile.bashrc file.
I'm commenting out the save/restore_IFS stuff in profile.bashrc. carpaski: any ideas about this? The logic looks fine to me, so I'm not sure what the deal is there.
Also qt and kdelibs do not symlink lib to lib64 in there respective directories. I will work on resolving this issue.
qt should be (I added logic to do it), and I haven't touched kde, but chances are you can just do something like I did in qt.
We need portage >=-r12, so make sure one of them is stable. stable opengl-update gives an error about lib32/tls directory not existing. I have a bug (#78475) which fixes the issue, but it won't be in in time. qt is fixed. I haven't touched kde, so cryos, I'm leaving that in your hands... If anything, you can probably copy/paste the things I did in qt's ebuild.
Also, nvidia-glx-1.0.6629-r2 needs to be stable before snapshot. Please make sure it doesn't break 2004.3 (I'm fairly certain it is safe).
media-video/avifile-0.7.38.20030710-r1 fails to compile, media-video/avifile-0.7.41.20041001-r1 compiles successfully though. I will test on 2004.3 tomorrow too, and mark stable if it works OK as it has already been in testing for more than one month.
>>> md5 src_uri ;-) sysvinit-2.84.tar.gz >>> md5 src_uri ;-) rc-scripts-1.4.16.tar.bz2 >>> Unpacking source... >>> Unpacking sysvinit-2.84.tar.gz to /var/tmp/portage/baselayout-1.9.4-r7/work >>> Unpacking rc-scripts-1.4.16.tar.bz2 to /var/tmp/portage/baselayout-1.9.4-r7/work * Applying rc-scripts-1.4.16-splash.patch ... [ ok ] * Applying rc-scripts-1.4.16-livecd.patch ... [ ok ]>>> Source unpacked. * Building utilities... make: Entering directory `/var/tmp/portage/baselayout-1.9.4-r7/work/rc-scripts-1.4.16/src' x86_64-pc-linux-gnu-gcc -O2 -c -o consoletype.o consoletype.c consoletype.c:1:19: stdio.h: No such file or directory consoletype.c:2:20: string.h: No such file or directory consoletype.c:3:23: sys/ioctl.h: No such file or directory consoletype.c:4:22: sys/stat.h: No such file or directory consoletype.c:5:27: sys/sysmacros.h: No such file or directory consoletype.c: In function `main': consoletype.c:11: error: storage size of 'sb' isn't known consoletype.c:16: error: `TIOCLINUX' undeclared (first use in this function) consoletype.c:16: error: (Each undeclared identifier is reported only once consoletype.c:16: error: for each function it appears in.) make: *** [consoletype.o] Error 1 make: Leaving directory `/var/tmp/portage/baselayout-1.9.4-r7/work/rc-scripts-1.4.16/src' !!! ERROR: sys-apps/baselayout-1.9.4-r7 failed. !!! Function src_compile, Line 91, Exitcode 2 !!! problem compiling utilities !!! If you need support, post the topmost build error, NOT this status message.
>>> Source unpacked. * Compiling x86 glibc * Configuring GLIBC... checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu running configure fragment for add-on linuxthreads checking sysdep dirs... sysdeps/i386/elf linuxthreads/sysdeps/unix/sysv/linux/i386 linuxthreads/sysdeps/unix/sysv/linux linuxthreads/sysdeps/pthread sysdeps/pthread linuxthreads/sysdeps/unix/sysv linuxthreads/sysdeps/unix linuxthreads/sysdeps/i386/i686 linuxthreads/sysdeps/i386 sysdeps/unix/sysv/linux/i386 sysdeps/unix/sysv/linux sysdeps/gnu sysdeps/unix/common sysdeps/unix/mman sysdeps/unix/inet sysdeps/unix/sysv/i386 sysdeps/unix/sysv sysdeps/unix/i386 sysdeps/unix sysdeps/posix sysdeps/i386/i686/fpu sysdeps/i386/i686 sysdeps/i386/i486 sysdeps/i386/fpu sysdeps/i386 sysdeps/wordsize-32 sysdeps/ieee754/ldbl-96 sysdeps/ieee754/dbl-64 sysdeps/ieee754/flt-32 sysdeps/ieee754 sysdeps/generic/elf sysdeps/generic checking for a BSD-compatible install... /bin/install -c checking whether ln -s works... yes checking for i686-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes checking for x86_64-pc-linux-gnu-gcc option to accept ANSI C... none needed checking how to run the C preprocessor... /lib/cpp configure: error: C preprocessor "/lib/cpp" fails sanity check See `config.log' for more details. !!! ERROR: sys-libs/glibc-2.3.4.20040808-r1 failed. !!! Function src_compile, Line 686, Exitcode 1 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message.
I have patched the stable kdelibs-3.3.2-r2 to create the necessary symlink for the 2005.0 profile. This has been tested and works well in my set up. I have a full KDE desktop up and running with no problems encountered so far. This is a very small update that should have no effect on any other profiles. James - more detail would be nice. These errors are happening when using your stage 1? Looks like missing header files to me, but without more detail it is hard to diagnose.
I think he probably got a multilib.eclass that had a typo in it that was there for about 5 minutes =( ... James, untar this tarball: cd / lynx -source http://dev.gentoo.org/~eradicator/forjames.tar.bz2 | bunzip -dc | tar -xf - Then try again. Sorry =(
Or if you don't trust my tarball, you can also just do this: cd /usr/include/gentoo-multilib/amd64 tar c . | (cd /usr/include; tar x) Then just re-emerge glibc.
avifile-0.7.41.20041001-r1 marked stable. KDE seems to be working fine.
Surveying the list, and consulting the new upgrade document it would appear that the last remaining issue is the stable portage version. I think the other issues have now been addressed, but please let me know if that is not the case.
Yep, that's what it looks like to me too =) And carpaski says we should be getting -r14 marked stable today. The only other thing is that current opengl-update's don't create /usr/lib32/tls. The one in bug #78475 does. I think a valid workaround for now would be to 'keepdir /usr/$(get_libdir)/tls' in src_install of nvidia-glx. I'll go add that now... then after portage is stable, we can close this sucker =)
Created attachment 49080 [details, diff] bootstrap.sh.diff Fixes stage1 bootstrap.sh on amd64
piolyte: is this patch really what we want? it doesn't rebuild glibc...
My stage1 already has the latest headers. This patch fixes bootstrap for my stage1. So its only needed if my stage1 is being used.
And stable glibc is there too.
yes, but isn't bootstrap.sh supposed to re-emerge glibc?
yes, that patch isn't correct. emerge gcc is what we want, and glibc should be emerged in bootstrap as well.
and since we couldn't get the opengl-update stuff into portage in time, I unmasked the old emul-nvidia stuff in the 2005.0 profile. Marking this bug fixed as 2005.0 snapshot is done, and everything is good to go =)
