From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33165) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRw9J-0000ii-9G for qemu-devel@nongnu.org; Tue, 08 May 2012 21:57:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SRw9H-0003we-C6 for qemu-devel@nongnu.org; Tue, 08 May 2012 21:57:04 -0400 Received: from fe01x03-cgp.akado.ru ([77.232.31.164]:62281 helo=akado.ru) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRw9H-0003wG-4k for qemu-devel@nongnu.org; Tue, 08 May 2012 21:57:03 -0400 Date: Wed, 9 May 2012 05:56:56 +0400 (MSK) From: malc In-Reply-To: <4FA9CDD1.4050105@us.ibm.com> Message-ID: References: <4FA9CDD1.4050105@us.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [Qemu-devel] qemu-1.0-rc1 delayed (need fix for PPC32 build) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Blue Swirl , qemu-devel , =?ISO-8859-15?Q?Andreas_F=E4rber?= , Alexander Graf On Tue, 8 May 2012, Anthony Liguori wrote: > Hi, > > I was hoping we'd have a solution by now but it looks like we don't. I'm > going to delay the qemu-1.0-rc1 release until tomorrow. I'd like to propose a > couple paths forward. Here's my understanding of the situation: > > 1) TCG changes were made for the Sparc/Alpha targets that use AREG0 > > 2) AREG0 never worked properly on ppc32 hosts > > 3) Until recently, this caused a runtime failure of the Sparc/Alpha targets on > ppc32. However, malc recently changed this to a build time failure. > > I don't feel comfortable shipping a release candidate with a known failing > build. Here are the options: > > a) Revert malc's change. I don't think this is much better than shipping a > broken build. > > b) Disable sparc/alpha targets in default_target_list on ppc32 hosts. I think > is probably the best short term approach. > > c) Wait for Andreas' patches (I believe Alex detected a problem in the current > version). > > Unless anyone strongly objects, I'm going to implement (b) tomorrow morning so > we can keep the -rc cycle moving. I would hope that we'll have something > worked out for (c) by -rc2. > I have no probelm with this, apart from rather shady definition of tomorow. -- mailto:av1474@comtv.ru