El sáb, 29-01-2011 a las 19:56 +0100, Thomas Sachau escribió: > Am 29.01.2011 19:30, schrieb Pacho Ramos: > > El sáb, 29-01-2011 a las 13:10 -0500, Nathan Phillip Brink escribió: > >> On Sat, Jan 29, 2011 at 06:03:10PM +0100, Pacho Ramos wrote: > >>> > >>> Hello > >>> > >>> I would like to know what is "blocking" this from landing main tree in > >>> the "near" future, as I reviewed: > >>> > >>> http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg41737.html > >>> > >>> and looks like there wasn't major problems (at least commented in this > >>> thread) > >> > >> There are still a number of known build failures, tracked in > >> https://bugs.gentoo.org/alias/portage-multilib . There are probably > >> many more portage-multilib-related build failures which haven't been > >> encountered yet nor reported. Also, even these reported bugs are not > >> necessarily fixed first because they only affect us the minority ;-). > > > > OK, thanks. Maybe bug 306835 should block bug 145737 instead of > > depending on it, not? > > I think, they are mostly dublicates, bug 145737 was the original > multilib-portage idea of kanaka, > but he discontinued it. The version of today (bug 306835) does partly base on > his work and partly on > the work with the native-multilib eclass from some Gentoo users with some > additional changes from me. > > > > >> > >> Most everything is easy to debug and as simple as replacing calls to > >> $(LD) in poorly-written Makefileswith with calls to $(CC), fixing > >> packages which ignore CFLAGS (where we store our -m32) or LDFLAGS > >> (where we now also store -m32 since one's not allowed to require > >> buildsystems to call $(CC) with $(CFLAGS) when objects are being > >> linked into an executable or library). > >> > >> However, packages which use qmake or cmake macros installed by KDE are > >> more difficult to debug and there are other funny issues such as > >> CFLAGS being stored by a library's buildsystem and stored into > >> /usr/share instead of an ABI-dependent directory, breaking packages > >> which use that library... ;-) > >> > >> Also, there are still some decisions/changes to portage-multilib which > >> might be made The most recent idea discussed was: should ${ARCH} > >> useflags (like SRC_URI="x86? ( http://host/my-binari-x86.tar.bz2 )") > >> be replaced with ${ABI} useflags or should we rewrite a bunch of > >> ebuilds in the tree to be multilib-aware? For example: > >> > >> Say we have > >> ABI=x86 > >> ARCH=amd64 > >> > >> Does ``use x86'' return true or do we need to use ``use multilib_abi_x86''? > >> Do detect the true arch, do we need ``use arch_amd64'' or does ``use > >> amd64'' still return true? > >> > > > > Where do you discuss things like this? IRC channel? Mailing-list? > > Thanks :-) > > Most communication is done in #gentoo-multilib-overlay on freenode IRC. I > have also created a mail > alias (multilib@g.o), but it is only used for some bugzilla assignments at > the moment. > >
OK, thanks a lot
signature.asc
Description: This is a digitally signed message part
