From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:49760)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1UDdBb-0008Vr-6g
	for qemu-devel@nongnu.org; Thu, 07 Mar 2013 10:56:53 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1UDdBZ-0001l3-PN
	for qemu-devel@nongnu.org; Thu, 07 Mar 2013 10:56:51 -0500
Message-ID: <5138B8B3.8070200@redhat.com>
Date: Thu, 07 Mar 2013 16:56:35 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
References: <24E144B8C0207547AD09C467A8259F7557B2BE14@lisa.maurer-it.com>
	<20130306231208.GA17594@ohm.aurel32.net>
	<20130307005351.GA19296@morn.localdomain>
	<5137ED49.3030204@redhat.com> <20130307015844.26170.qmail@stuge.se>
	<CAFWqQMRTC9Zg=XcY30ZxwaXgz-wOcKa4zszDoZKJj7f7zSUNHg@mail.gmail.com>
	<51383F0B.8050704@msgid.tls.msk.ru> <51388079.3010707@redhat.com>
	<CAFEAcA9YYHsBrSOpDqt1Da7UQosGxT2DVX1j50iuzNDTXCAfbg@mail.gmail.com>
In-Reply-To: <CAFEAcA9YYHsBrSOpDqt1Da7UQosGxT2DVX1j50iuzNDTXCAfbg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [Qemu-stable] [SeaBIOS] problems with freeBSD
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Anthony Liguori <aliguori@us.ibm.com>, Doug Goldstein <cardoe@gentoo.org>, seabios@seabios.org, Michael Tokarev <mjt@tls.msk.ru>, qemu-stable@nongnu.org, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, Kevin O'Connor <kevin@koconnor.net>, Laszlo Ersek <lersek@redhat.com>, Dietmar Maurer <dietmar@proxmox.com>, Aurelien Jarno <aurelien@aurel32.net>

  Hi,

> In general having blobs in our allegedly source tarball is pretty
> ugly. Either it's a source release or it isn't. We can do a
> release-of-blobs tarball too if we want, but it doesn't need
> to be in the source tarball

This is easily doable, just an update to scripts/make-release to spew
two tarballs (one source, one blobs).

We probably want update the build process to build the blobs by default
(if the compilers needed are installed).  Blueswirl started that already
for sparc firmware I think.

> and it doesn't need to be in git
> either IMHO.

That one is a bit more tricky.  The big advantage git has here is that
the update of a blob is not different from other updates.  It is just a
pull request.  Keeping source+binaries in sync is easy too: we can
update submodule hash + blobs with a single git commit.

The process needs to stay simple, otherwise we'll risk that the blobs we
provide will bitrot ...

cheers,
  Gerd