Re: [gentoo-amd64] Several problems with Gentoo AMD64
Jason Harmening <[EMAIL PROTECTED]> wrote: > Quoting Luke-Jr <[EMAIL PROTECTED]>: > > > On Thursday 10 February 2005 19:42, Jason Harmening wrote: > > > 1. app-text/ghostscript (espgs) segfaults on about half the postscript > > > files that are given to it. dmesg output is as follows: > > > > WFM > > It works fine for text files, but generally fails with anything involving > graphics (e.g. webpages). This has nothing to do with my printer, as even a > simple "gs print.ps" will generate the segfault. It's worth noting that, for > my testing, all the failing ps files have been generated by konqueror, as I > haven't gotten around to emerging mozilla (or many other apps for that > matter). I don't remember what trouble I had with ESP Ghostscript, but I have had better luck after switching back to AFPL Ghostscript, which was what I used in my pre-Gentoo days. There was a bug in the ebuild, causing some libraries used by gimp-print to be left out, but I describe somewhere in Bugzilla a cheap and dirty workaround. -- [EMAIL PROTECTED]http://www.chemoelectric.org "I have directed that in the future I sign each letter." -- Rumsfeld pgpeIiaz3cgKa.pgp Description: PGP signature
Re: [gentoo-amd64] Several problems with Gentoo AMD64
Quoting Luke-Jr <[EMAIL PROTECTED]>: > On Thursday 10 February 2005 19:42, Jason Harmening wrote: > > 1. app-text/ghostscript (espgs) segfaults on about half the postscript > > files that are given to it. dmesg output is as follows: > > WFM It works fine for text files, but generally fails with anything involving graphics (e.g. webpages). This has nothing to do with my printer, as even a simple "gs print.ps" will generate the segfault. It's worth noting that, for my testing, all the failing ps files have been generated by konqueror, as I haven't gotten around to emerging mozilla (or many other apps for that matter). > > > 2. After doing an "ACCEPT_KEYWORDS=~amd64 emerge -u world" earlier this > > week, > > ~amd64 isn't guaranteed to be stable. I don't see any reason to use it for an > entire system... Point well taken (and learned the hard way). Coming from freebsd, I'm not entirely used to the richer feature set offered by portage. > > > But now when I try to emerge arts, I get an error indicating that simple > C++ > > files cannot be compiled. Here are the relevant contents of > > Would this be a problem with the gcc/g++ installation, or with the arts > > configuration? Arts (the same version) had previously built fine for me > > with gcc 3.4.2, but I need to remerge it in order to link it with > > libogg/libvorbis. > > Not related to the problem you are having, but don't expect to be able to > compile KDE with the more recent Gentoo revisions of GCC. They enable a > broken backport of the visibility stuff which breaks KDE. That sux. But I have a feeling the problem may be somehow related to my botched gcc installation, though I'm not quite sure how. I'll downgrade to 3.4.3-r1 and see if that helps. > -- > Luke-Jr > Developer, Utopios > http://utopios.org/ > > -- > gentoo-amd64@gentoo.org mailing list > > -- -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Several problems with Gentoo AMD64
On Thursday 10 February 2005 09:31 pm, Luke-Jr wrote: > On Friday 11 February 2005 01:04, Mark Constable wrote: > > Luke-Jr wrote: > > > ... > > > Not related to the problem you are having, but don't expect to be able > > > to compile KDE with the more recent Gentoo revisions of GCC. They > > > enable a broken backport of the visibility stuff which breaks KDE. > > > > What might be the best CFLAGS and ACCEPT_KEYWORDS, or any > > other options, to ease this situation ? > > No keywords or CFLAGS will fix the problem. KDE components will error > during compile as long as GCC contains the broken visibility code. In general you just want to ACCEPT_KEYWORDS = amd64 unless you don't mind being bleeding edge. Granted, you already are to some degree on this platform, but gentoo works fairly well when you don't accept ~amd64 for everything. CFLAGS usually isn't a problem as long as you are mainstream. -O2/3/s -fweb -march=k8 -fomit-frame-pointer and -frename-registers haven't broken anything in my experience. I usually use -fstack-protector, but that does occasionally break something. You'll usually want to accept ~amd64 for your favorite apps so that you stay more current, but unless you enjoy testing you might want to be judicious with it. I use it for quite a few apps, but unless I'm actually using a feature in a newer version of a package I just bide my time. pgp1RdnEdbrSP.pgp Description: PGP signature
Re: [gentoo-amd64] Several problems with Gentoo AMD64
On Friday 11 February 2005 01:04, Mark Constable wrote: > Luke-Jr wrote: > > ... > > Not related to the problem you are having, but don't expect to be able to > > compile KDE with the more recent Gentoo revisions of GCC. They enable a > > broken backport of the visibility stuff which breaks KDE. > > What might be the best CFLAGS and ACCEPT_KEYWORDS, or any > other options, to ease this situation ? No keywords or CFLAGS will fix the problem. KDE components will error during compile as long as GCC contains the broken visibility code. -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] K3b emerge failed
Mike Melanson wrote: emerge of K3b (KDE CD/DVD burning app) failed: ... k3baudioplayer.h:26:34: arts/kartsdispatcher.h: No such file or directory Perhaps try a reinstall of kdelibs, and make sure "arts" is in your USE flags. # qpkg -l kdelibs | grep kartsdispatcher.h /usr/kde/3.3/include/arts/kartsdispatcher.h /usr/kde/3.4/include/arts/kartsdispatcher.h --markc -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Several problems with Gentoo AMD64
Luke-Jr wrote: ... Not related to the problem you are having, but don't expect to be able to compile KDE with the more recent Gentoo revisions of GCC. They enable a broken backport of the visibility stuff which breaks KDE. What might be the best CFLAGS and ACCEPT_KEYWORDS, or any other options, to ease this situation ? --markc -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] K3b emerge failed
Hi, emerge of K3b (KDE CD/DVD burning app) failed: g++ -DHAVE_CONFIG_H -I. -I. -I.. -I./tools -I./core -I./device -I./projects -I./projects/datacd -I./projects/datadvd -I./projects/audiocd -I./projects/videocd-I./projects/mixedcd -I./projects/movixcd -I./device -I./plugin -I/usr/kde/3.3/include -I/usr/qt/3/include -I/usr/X11R6/include -DQT_THREAD_SUPPORT -D_REENTRANT -I/usr/kde/3.3/include -I/usr/qt/3/include -I/usr/X11R6/include -Wnon-virtual-dtor -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -DNDEBUG -DNO_DEBUG -O2 -O2 -Wformat-security -Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -c -o k3bprojecttabbar.o `test -f 'k3bprojecttabbar.cpp' || echo './'`k3bprojecttabbar.cpp In file included from k3baudioplayer.cpp:17: k3baudioplayer.h:26:34: arts/kartsdispatcher.h: No such file or directory In file included from k3baudioplayer.cpp:17: k3baudioplayer.h:178: error: `KArtsDispatcher' does not name a type k3baudioplayer.cpp: In member function `virtual QDragObject* K3bPlayListView::dragObject()': k3baudioplayer.cpp:154: warning: `newDrag' is deprecated (declared at /usr/kde/3.3/include/kurldrag.h:76) g++ -DHAVE_CONFIG_H -I. -I. -I.. -I./tools -I./core -I./device -I./projects -I./projects/datacd -I./projects/datadvd -I./projects/audiocd -I./projects/videocd-I./projects/mixedcd -I./projects/movixcd -I./device -I./plugin -I/usr/kde/3.3/include -I/usr/qt/3/include -I/usr/X11R6/include -DQT_THREAD_SUPPORT -D_REENTRANT -I/usr/kde/3.3/include -I/usr/qt/3/include -I/usr/X11R6/include -Wnon-virtual-dtor -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -DNDEBUG -DNO_DEBUG -O2 -O2 -Wformat-security -Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -c -o k3bprojecttabwidget.o `test -f 'k3bprojecttabwidget.cpp' || echo './'`k3bprojecttabwidget.cpp make[3]: *** [k3baudioplayer.o] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory `/var/tmp/portage/k3b-0.11.17/work/k3b-0.11.17/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/k3b-0.11.17/work/k3b-0.11.17/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/k3b-0.11.17/work/k3b-0.11.17' make: *** [all] Error 2 !!! ERROR: app-cdr/k3b-0.11.17 failed. !!! Function kde_src_compile, Line 142, Exitcode 2 !!! died running emake, kde_src_compile:make !!! If you need support, post the topmost build error, NOT this status message. -- -Mike Melanson -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Re: KDE 3.4.0_beta1
If anyone was wondering, I just found experimentally that "use amd64" in an ebuild is not affected by changing ACCEPT_KEYWORDS to ~x86. If a package was ready out of the box for building on amd64, it should build from an ebuild, too. pgpqQH9Ccw36r.pgp Description: PGP signature
Re: [gentoo-amd64] Re: Re: KDE 3.4.0_beta1
Duncan <[EMAIL PROTECTED]> wrote: > Often when the x86 test adds stuff, it's 32-bit > specific binary-only media libraries (like the MS codecs) and the like, > which may draw in new dependencies that don't work, but hopefully won't > kill the emerge. However, it can /also/ be x86_32-specific assembly code > enabled by that x86 conditional. Try putting that in the middle of a > 64-bit binary, and you *WILL* have problems. Likewise with the amd64 > tests, except those conditionals are likely more important because they > wouldn't have been added without a reason, and skipping them is likely to > cause /all/ /sorts/ of "interesting" problems, from applying 32-bit > assembly to the middle of a 64-bit binary, to screwing up where any shared > objects go, putting them in lib instead of lib64 dirs. At present, that > last one isn't a huge problem since the lib dir is generally a symlink to > lib64 anyway, but that WILL change one of these days, probably with the > 2005.1 profile. I haven't investigate how $(get_libdir) works, but if it is decided by a keyword then that should be fixed. For example, what if I say ACCEPT_KEYWORDS="amd64 x86"? Should it create a new directory called "lib0.5x(64+32)" ? Portage would have to do _something_, Most often the job of configuring is passed along to autoconf, to which is fed a CHOST value, although I'm not sure it wouldn't be better to leave even that out (except for cross-compiling). Normally, if you were installing in /usr/local, you would let configure discover the architecture (except for cross-compiling). -- [EMAIL PROTECTED]http://www.chemoelectric.org "I have directed that in the future I sign each letter." -- Rumsfeld pgp5n3hsDVVl0.pgp Description: PGP signature
Re: [gentoo-amd64] Several problems with Gentoo AMD64
On Thursday 10 February 2005 19:42, Jason Harmening wrote: > 1. app-text/ghostscript (espgs) segfaults on about half the postscript > files that are given to it. dmesg output is as follows: WFM > 2. After doing an "ACCEPT_KEYWORDS=~amd64 emerge -u world" earlier this > week, ~amd64 isn't guaranteed to be stable. I don't see any reason to use it for an entire system... > But now when I try to emerge arts, I get an error indicating that simple C++ > files cannot be compiled. Here are the relevant contents of > Would this be a problem with the gcc/g++ installation, or with the arts > configuration? Arts (the same version) had previously built fine for me > with gcc 3.4.2, but I need to remerge it in order to link it with > libogg/libvorbis. Not related to the problem you are having, but don't expect to be able to compile KDE with the more recent Gentoo revisions of GCC. They enable a broken backport of the visibility stuff which breaks KDE. -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] Several problems with Gentoo AMD64
Hi all,
I just built an Athlon64-based system and chose Gentoo because, as I
understand it, it is pretty much the most mature OS for AMD64 right now. But
I am having several problems--here are the two biggest:
1. app-text/ghostscript (espgs) segfaults on about half the postscript files
that are given to it. dmesg output is as follows:
gs[21205]: segfault at 0008 rip 005b6ea0 rsp
007fbfffdcc8 error 4
I have had this problems with ghostscript 7.07.1-r6, -r7, and -r8 (haven't
tried anything earlier than -r6). I am running kernel 2.6.10-gentoo-r7, with
portage sync'ed up weekly. I believe there is already a BUG entry for this
problem, but the number escapes me.
2. After doing an "ACCEPT_KEYWORDS=~amd64 emerge -u world" earlier this
week,
gcc was upgraded to 3.4.3.20050110, which totally broke it. Initially, I
couldn't compile anything because gcc could not find its binutils executables
('as', 'ld', etc.). I fixed that by adding a PATH entry
to /etc/env.d/05binutils. But now when I try to emerge arts, I get an error
indicating that simple C++ files cannot be compiled. Here are the relevant
contents of /var/tmp/portage/arts-1.3.2/work/arts-1.3.2/config.log:
configure:29109: checking if C++ programs can be compiled
configure:29138: x86_64-pc-linux-gnu-g++ -c -Wnon-virtual-dtor -Wno-long-long
-W
undef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion
-Wchar-s
ubscripts -Wall -W -Wpointer-arith -Wwrite-strings -DNDEBUG -DNO_DEBUG -O2
-marc
h=athlon64 -O2 -pipe -fomit-frame-pointer -Wformat-security
-Wmissing-format-att
ribute -fno-check-new -fno-common conftest.cc >&5
conftest.cc:61:18: string: No such file or directory
conftest.cc: In function `int main()':
conftest.cc:68: error: `string' undeclared (first use this function)
conftest.cc:68: error: (Each undeclared identifier is reported only once for
eac
h function it appears in.)
conftest.cc:68: error: expected `;' before "astring"
conftest.cc:69: error: `astring' undeclared (first use this function)
configure:29144: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE "arts"
| #define VERSION "1.3.2"
| #ifdef __cplusplus
| extern "C" void std::exit (int) throw (); using std::exit;
| #endif
| #define KDELIBSUFF ""
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_DLFCN_H 1
| #define LTDL_SHLIBPATH_VAR "LD_LIBRARY_PATH"
| #define LTDL_SYSSEARCHPATH "/lib64:/usr/lib64"
| #define LTDL_OBJDIR ".libs/"
| #define HAVE_PRELOADED_SYMBOLS 1
| #define HAVE_LIBDL 1
| #define HAVE_DLERROR 1
| #define HAVE_MALLOC_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STDIO_H 1
| #define HAVE_CTYPE_H 1
| #define HAVE_DLFCN_H 1
| #define HAVE_STRING_H 1
| #define HAVE_STRCHR 1
| #define HAVE_STRRCHR 1
| #define HAVE_MEMCPY 1
| #define HAVE_STRCMP 1
| #define HAVE_CRYPT 1
| #define kde_socklen_t socklen_t
| #define ksize_t socklen_t
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_SYS_BITYPES_H 1
| #define HAVE_RES_INIT 1
| #define HAVE_RES_INIT 1
| #define HAVE_RES_INIT_PROTO 1
| #define SIZEOF_INT 4
| #define SIZEOF_SHORT 2
| #define SIZEOF_LONG 8
| #define SIZEOF_CHAR_P 8
| #define SIZEOF_SIZE_T 8
| #define SIZEOF_UNSIGNED_LONG 8
| #define HAVE_VSNPRINTF 1
| #define HAVE_SNPRINTF 1
| /* end confdefs.h. */
|
| #include
| using namespace std;
|
| int
| main ()
| {
|
| string astring="Hallo Welt.";
| astring.erase(0, 6); // now astring is "Welt"
| return 0;
|
| ;
| return 0;
| }
configure:29171: result: no
configure:29184: error: Your Installation isn't able to compile simple C++
progr
ams.
Check config.log for details - if you're using a Linux distribution you might
mi
ss
a package named similiar to libstd++-dev.
Would this be a problem with the gcc/g++ installation, or with the arts
configuration? Arts (the same version) had previously built fine for me with
gcc 3.4.2, but I need to remerge it in order to link it with
libogg/libvorbis.
Thanks,
Jason Harmening
--
--
gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Re: KDE 3.4.0_beta1
On Thursday 10 February 2005 09:45, Duncan wrote:
> Luke-Jr posted <[EMAIL PROTECTED]>, excerpted below,
>
> on Thu, 10 Feb 2005 03:41:33 +:
> > on PPC...
> >
> > mkdir -p /etc/portage
> > for d in /usr/portage/kde-base/*; do
> > pkg="${d/\/usr\/portage\//}";
> > echo "${pkg} ~x86 x86" >> /etc/portage/package.keywords echo "${pkg}"
> >
> > >> /etc/portage/package.unmask
> >
> > done
> >
> > That should work on any arch, though it will make a technically invalid
> > package.keywords file. It will work perfectly fine, though. :)
>
> OK, that will /normally/ work fine, and might work fine on all current KDE
> 3.4.0 betas, but as you say, it's technically incorrect (because it's
> telling portage to treat your arch like x86, which it isn't, and that
> can cause "interesting" complications, see below), and it /will/ cause
> problems with some packages, which is why the technotes say don't do it.
Only packages that won't work on your platform.
>
> Here's the deal. Certain ebuilds conditionally build in or compile
> certain features based on the keywords.
Based on USE flags.
> One example I know of, altho it's keyworded amd64 so there'd be no reason to
> use package.keywords to hack things, is xorg.
Nope. It uses USE flags to determine what arch.
> Others would be both mplayer and xinelib.
Those are checking USE flags also...
> Even more commonly, amd64 specific patches are conditionally applied based
> on keywords.
s/keywords/USE flags
> If you tell portage to use x86 (in either form), these tests will be screwed
> up.
If portage is changing my USE flags based on package.keywords, then portage is
screwed up.
> Thus, what one /really/ should be doing before they go trying x86 (in
> either form) in the keywords is verifying that the ebuild doesn't have any
> of these specific tests in it, or at minimum, that if it does, they aren't
> serious issues (an example being the lib/lib64 issue, presently).
As far as I am aware, ebuilds are not supposed to go checking KEYWORDS
themselves.
--
Luke-Jr
Developer, Utopios
http://utopios.org/
--
gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Re: KDE 3.4.0_beta1
Duncan wrote: ... Thanking you for that explanation. Anyway, beta2 was announced yesterday (Wed), which means the tarballs should be available. The ebuilds were already in portage, so that should mean it's accessible now. I haven't done anything with it yet, however. Seems there's a small matter of a script I might want to think about whipping up, first. . /etc/make.conf cp -a /usr/portage/kde-base $PORTDIR_OVERLAY/kde-base cd $PORTDIR_OVERLAY/kde-base for e in */*-3.4.0_beta2.ebuild; do sed 's/~x86/~amd64/' $e > $e.new mv $e.new $e done All my ebuilds now have KEYWORDS="~amd64" but I'm still getting the original... !!! All ebuilds that could satisfy "=kde-base/kde-meta-3.4.0_beta2" have been masked. - kde-base/kde-meta-3.4.0_beta2 (masked by: package.mask) The only thing I have running at the moment are FF and TB on a very fragile desktop that I dare not shutdown :-) --markc -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] Re: Re: KDE 3.4.0_beta1
Luke-Jr posted <[EMAIL PROTECTED]>, excerpted below,
on Thu, 10 Feb 2005 03:41:33 +:
> on PPC...
>
> mkdir -p /etc/portage
> for d in /usr/portage/kde-base/*; do
> pkg="${d/\/usr\/portage\//}";
> echo "${pkg} ~x86 x86" >> /etc/portage/package.keywords echo "${pkg}"
> >> /etc/portage/package.unmask
> done
>
> That should work on any arch, though it will make a technically invalid
> package.keywords file. It will work perfectly fine, though. :)
OK, that will /normally/ work fine, and might work fine on all current KDE
3.4.0 betas, but as you say, it's technically incorrect (because it's
telling portage to treat your arch like x86, which it isn't, and that
can cause "interesting" complications, see below), and it /will/ cause
problems with some packages, which is why the technotes say don't do it.
Here's the deal. Certain ebuilds conditionally build in or compile
certain features based on the keywords. One example I know of, altho it's
keyworded amd64 so there'd be no reason to use package.keywords to hack
things, is xorg. Others would be both mplayer and xinelib. Even more
commonly, amd64 specific patches are conditionally applied based on
keywords. If you tell portage to use x86 (in either form), these tests
will be screwed up. Often when the x86 test adds stuff, it's 32-bit
specific binary-only media libraries (like the MS codecs) and the like,
which may draw in new dependencies that don't work, but hopefully won't
kill the emerge. However, it can /also/ be x86_32-specific assembly code
enabled by that x86 conditional. Try putting that in the middle of a
64-bit binary, and you *WILL* have problems. Likewise with the amd64
tests, except those conditionals are likely more important because they
wouldn't have been added without a reason, and skipping them is likely to
cause /all/ /sorts/ of "interesting" problems, from applying 32-bit
assembly to the middle of a 64-bit binary, to screwing up where any shared
objects go, putting them in lib instead of lib64 dirs. At present, that
last one isn't a huge problem since the lib dir is generally a symlink to
lib64 anyway, but that WILL change one of these days, probably with the
2005.1 profile.
Thus, what one /really/ should be doing before they go trying x86 (in
either form) in the keywords is verifying that the ebuild doesn't have any
of these specific tests in it, or at minimum, that if it does, they aren't
serious issues (an example being the lib/lib64 issue, presently).
Pragmatically, of course, that defeats the advantage of being able to use
package.keywords for this sort of thing, so most so inclined will probably
just try it and do the emerge, and go back afterward and figure out why,
if it doesn't work. At minimum, however, a user doing this should realize
the potential issues and be willing to try the long way around, below,
before filing exotic bugs that may simply be due to trying to emerge with
x86 instead of amd64 in their keywords.
So, x86 into package.keywords will often work, but as the saying goes, "If
it breaks, you get to keep the pieces!" What's the other, more "proper",
alternative?
Simple. Edit the ebuild and add the appropriate keywords, then ebuild
digest it so portage can use it again, and try the emerge. Of course,
one will presumably want to copy the ebuild to their overlay before
editing it, so the changes aren't deleted at the next sync, resulting in
Portage wanting to unmerge the ebuild because it's no longer keyworded,
but for a quick emerge test, you can do it in place and wait until you
know it works to move it to the overlay.
Of course, this is significantly more work than simply adding a package
and ~x86 to package.keywords, but it /does/ preserve portage's test
conditionals, avoiding the issues above.
Unfortunately, with a whole slew of packages, particularly if we are
talking all or most of the unbundled kde packages, it's a HUGE bit of
work, done manually. With something this big it's likely worth whipping
up a script for, to include a bit of grep and sed work, adding ~amd64 to
the existing keywords in the ebuild itself, after copying it to the
overlay but before ebuild digesting it again, of course. I wonder if any
of the arch dev teams already have such a tool available?
...
Anyway, beta2 was announced yesterday (Wed), which means the tarballs
should be available. The ebuilds were already in portage, so that should
mean it's accessible now. I haven't done anything with it yet, however.
Seems there's a small matter of a script I might want to think about
whipping up, first.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html
--
gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] Re: Re: +multilib
Jeremy Huddleston posted <[EMAIL PROTECTED]>, excerpted below, on Wed, 09 Feb 2005 15:51:00 -0800: > Yeah, ideally signing would be great, and easier to implement, but nobody > seems to be working on that... there's been discussion on -dev, but nobody > seems to want to make patches, and I know nothing about xml, so I'll > continue my multilib work. Well, I certainly can't complain... I just pray that Gentoo doesn't suddenly find new urgency and motivation for signing, rather not by choice, as was the case with Debian and Gnome. Still, one works where their talent is, and if yours lends itself to multilib better than signing... Looking forward to it (well, both ) in any case! -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-amd64@gentoo.org mailing list
