1 |
Am 29.01.2011 19:30, schrieb Pacho Ramos: |
2 |
> El sáb, 29-01-2011 a las 13:10 -0500, Nathan Phillip Brink escribió: |
3 |
>> On Sat, Jan 29, 2011 at 06:03:10PM +0100, Pacho Ramos wrote: |
4 |
>>> |
5 |
>>> Hello |
6 |
>>> |
7 |
>>> I would like to know what is "blocking" this from landing main tree in |
8 |
>>> the "near" future, as I reviewed: |
9 |
>>> |
10 |
>>> http://www.mail-archive.com/gentoo-dev@l.g.o/msg41737.html |
11 |
>>> |
12 |
>>> and looks like there wasn't major problems (at least commented in this |
13 |
>>> thread) |
14 |
>> |
15 |
>> There are still a number of known build failures, tracked in |
16 |
>> https://bugs.gentoo.org/alias/portage-multilib . There are probably |
17 |
>> many more portage-multilib-related build failures which haven't been |
18 |
>> encountered yet nor reported. Also, even these reported bugs are not |
19 |
>> necessarily fixed first because they only affect us the minority ;-). |
20 |
> |
21 |
> OK, thanks. Maybe bug 306835 should block bug 145737 instead of |
22 |
> depending on it, not? |
23 |
|
24 |
I think, they are mostly dublicates, bug 145737 was the original multilib-portage idea of kanaka, |
25 |
but he discontinued it. The version of today (bug 306835) does partly base on his work and partly on |
26 |
the work with the native-multilib eclass from some Gentoo users with some additional changes from me. |
27 |
|
28 |
> |
29 |
>> |
30 |
>> Most everything is easy to debug and as simple as replacing calls to |
31 |
>> $(LD) in poorly-written Makefileswith with calls to $(CC), fixing |
32 |
>> packages which ignore CFLAGS (where we store our -m32) or LDFLAGS |
33 |
>> (where we now also store -m32 since one's not allowed to require |
34 |
>> buildsystems to call $(CC) with $(CFLAGS) when objects are being |
35 |
>> linked into an executable or library). |
36 |
>> |
37 |
>> However, packages which use qmake or cmake macros installed by KDE are |
38 |
>> more difficult to debug and there are other funny issues such as |
39 |
>> CFLAGS being stored by a library's buildsystem and stored into |
40 |
>> /usr/share instead of an ABI-dependent directory, breaking packages |
41 |
>> which use that library... ;-) |
42 |
>> |
43 |
>> Also, there are still some decisions/changes to portage-multilib which |
44 |
>> might be made The most recent idea discussed was: should ${ARCH} |
45 |
>> useflags (like SRC_URI="x86? ( http://host/my-binari-x86.tar.bz2 )") |
46 |
>> be replaced with ${ABI} useflags or should we rewrite a bunch of |
47 |
>> ebuilds in the tree to be multilib-aware? For example: |
48 |
>> |
49 |
>> Say we have |
50 |
>> ABI=x86 |
51 |
>> ARCH=amd64 |
52 |
>> |
53 |
>> Does ``use x86'' return true or do we need to use ``use multilib_abi_x86''? |
54 |
>> Do detect the true arch, do we need ``use arch_amd64'' or does ``use amd64'' still return true? |
55 |
>> |
56 |
> |
57 |
> Where do you discuss things like this? IRC channel? Mailing-list? |
58 |
> Thanks :-) |
59 |
|
60 |
Most communication is done in #gentoo-multilib-overlay on freenode IRC. I have also created a mail |
61 |
alias (multilib@g.o), but it is only used for some bugzilla assignments at the moment. |
62 |
|
63 |
|
64 |
-- |
65 |
Thomas Sachau |
66 |
|
67 |
Gentoo Linux Developer |