From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43099) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rcj8c-0006BF-8g for qemu-devel@nongnu.org; Mon, 19 Dec 2011 14:44:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rcj8b-0002IT-35 for qemu-devel@nongnu.org; Mon, 19 Dec 2011 14:44:42 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:63945) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rcj8a-0002IC-Ut for qemu-devel@nongnu.org; Mon, 19 Dec 2011 14:44:41 -0500 Received: by iagj37 with SMTP id j37so10170400iag.4 for ; Mon, 19 Dec 2011 11:44:39 -0800 (PST) Message-ID: <4EEF9421.40708@codemonkey.ws> Date: Mon, 19 Dec 2011 13:44:33 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4EECB3C5.6060608@codemonkey.ws> <20111217152514.GM2520@amd.home.annexia.org> <4EECC227.4060904@codemonkey.ws> <20111217164956.GA16848@morn.localdomain> <20111219103101.GB27938@redhat.com> <4EEF7595.7060301@codemonkey.ws> <20111219174307.GB2558@redhat.com> <4EEF7C53.6050800@codemonkey.ws> <20111219190454.GD2909@amd.home.annexia.org> <20111219191602.GA3425@redhat.com> <20111219194005.GE2909@amd.home.annexia.org> In-Reply-To: <20111219194005.GE2909@amd.home.annexia.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] insmod virtio-blk is broken in qemu 1.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" Cc: "seabios@seabios.org" , qemu-devel@nongnu.org, Max Filippov , Kevin O'Connor , Avi Kivity , Amit Shah , jforbes@fedoraproject.org, Gerd Hoffmann On 12/19/2011 01:40 PM, Richard W.M. Jones wrote: > On Mon, Dec 19, 2011 at 07:16:02PM +0000, Daniel P. Berrange wrote: >> On Mon, Dec 19, 2011 at 07:04:54PM +0000, Richard W.M. Jones wrote: >>> On Mon, Dec 19, 2011 at 12:02:59PM -0600, Anthony Liguori wrote: >>>> I would like to point out that August -> October is a pretty long >>>> time period for a regression like this to exist. I think that >>>> really indicates that the primary problem is testing, not frequency >>>> of SeaBIOS updates. >>> >>> Fair point. >>> >>> My understanding is we're going to switch to having qemu.git in Fedora >>> Rawhide, which means that libguestfs will always be testing the >>> 'perfect storm' of qemu + kernel + glibc from git (once glibc get >>> their act together anyhow, just qemu + kernel at first). >>> >>> We usually do a build and a comprehensive test at least once a week, >>> often a few times a week, so we would have picked this up much sooner. >> >> That wouldn't actually catch this problem, because when we build >> QEMU in Fedora, we never use the SeaBIOS that QEMU includes in >> GIT. Fedora always ships the newest SeaBIOS release available >> from upstream, regardless of what QEMU includes. > > Ah yes indeed, I forgot about this. > > Nevertheless, it'll at least improve other aspects of our > qemu testing :-) > > In reply to Anthony: the reason Fedora does this is because > binary blobs aren't permitted, no matter what the origin. We > have to build SeaBIOS from source, and the choice is made to > build from the upstream SeaBIOS source, not from the source > release indirectly pointed to by qemu. FWIW, we ship SeaBIOS source directly in our release tarballs. There's nothing indirect about it. Fedora could have a seabios-qemu RPM that was built from the qemu SRPM. Since it ultimately is going to live in /usr/share/qemu, that seems like a nicer thing to do AFAICT. You could have an alternatives mechanism if people really wanted to use upstream SeaBIOS... Regards, Anthony Liguori > > Rich. >