From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1EB8RV-0001Ct-Aa for garchives@archives.gentoo.org; Fri, 02 Sep 2005 10:06:41 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j82A3KmG028654; Fri, 2 Sep 2005 10:03:20 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j82A10lZ017169 for ; Fri, 2 Sep 2005 10:01:00 GMT Received: from sls-ce5p321.hostitnow.com ([72.9.236.50]) by smtp.gentoo.org with esmtp (Exim 4.43) id 1EB8OV-0004aP-Vs for gentoo-dev@lists.gentoo.org; Fri, 02 Sep 2005 10:03:36 +0000 Received: from c-67-181-55-15.hsd1.ca.comcast.net ([67.181.55.15] helo=[192.168.0.106]) by sls-ce5p321.hostitnow.com with esmtpa (Exim 4.52) id 1EB8OO-0003Gg-IL for gentoo-dev@gentoo.org; Fri, 02 Sep 2005 05:03:28 -0500 From: Chris White To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] [summary] combining x86 and amd64 Date: Fri, 2 Sep 2005 18:32:38 +0900 User-Agent: KMail/1.8.2 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509021832.38406.chriswhite@gentoo.org> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sls-ce5p321.hostitnow.com X-AntiAbuse: Original Domain - gentoo.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gentoo.org X-Source: X-Source-Args: X-Source-Dir: X-Archives-Salt: 36fd5b69-36aa-4c8f-bc1b-a9f674cd3085 X-Archives-Hash: ee45dc9f7fe6cd24a1b8bf3cd9adf162 Ok, say yah, this thread is tooooo long, so I decided, "Hey, let's make a summary of the main important points". That way everyone doesn't have to read threads that are longer than the combined code of portage. So, let's get started First off, this great guy named Grant decided it was a good idea for us to have a merger of the x86 and amd64 arch teams, but requested a glep for it. Not having a glep around, he suggested someone else bring one up for it. http://article.gmane.org/gmane.linux.gentoo.devel/26749/match=glep+++++amd64 was suggested for quick reading by blubb, who didn't like the idea. Flameeyes then came in noting the impossibilities due to binary incompatibility, ie., some things Just Work(tm) on x86 only. Some comments were brought in about amd64 profile level masking, but blubb said he didn't like that, and noted the importance of ~amd64 keywording, as well as the issues of things ready for x86 stable being held back by amd64 keywording. Also a small note was made about the differences between sparc32/sparc64 and x86/amd64 (userland/kernel magic). After this a short battle occured, and ferringb request that the main pros/cons be laid out. more small exchanges go here, mentioning of mips as an example (one keyword for both 32 and 64 bit systems). some points were brought up about 32 bit emulated libs under amd64 to which Flameeyes explained that there are too many differences to consider them true 32 bit. Complaints were made about not wanting multi-lib amd64 in some cases. However, explanations were made about a non-multi-lib profile as well as praise for the current multi-lib system. Ok, some comments were made about the previous keywording arguments being untrue, and comments were made about current ebuilds in the tree utilizing systems to help prevent against such incompatibilities. Notes were made about using profile archs and use_expand as a solution. bit of flames wolf gets tired of flames, says to make an x86 arch team already and be done with it. bit more misc stuff geoman mentions that the reasoning for this is x86 is not "officially" supported and is hurting tree QA. wolf mentions that we have an x86 security team, which can be considered to be a somewhat official x86 arch team. ok, we're starting to think along the lines of x86 arch team creation. This brings up the x86 security alias members, as well as: "The people maintaining the x86 kernel should also join, as well as the release maintainer (chris, is that you?), the grub/lilo maintainers, etc... That would be a good start. We should also try to recruit one or two x86 arch testers, hparker has offered to help." People start agreeing that x86 arch team creation is a Good Idea(tm) More misc talk The end! Ok, that should sum it up, and currently there's another thread about x86 arch team creation which seems to be going well. Hopefully this makes the longggggggggggggg thread a bit more readable. Chris White -- gentoo-dev@gentoo.org mailing list