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
On 7 March 2013 23:56, Gerd Hoffmann kraxel@redhat.com wrote:
Peter Maydell wrote:
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.
Earlier in this thread it's been stated that this often produces subtly broken blobs...
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.
You could put the sources for the binary blobs in their own git repo, and then have the blobs in that git repo rather than qemu mainline.
-- PMM
On Thu, 2013-03-07 at 16:56 +0100, Gerd Hoffmann wrote:
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.
FWIW I find the binaries in git to be a PITA. I submitted a patch in January to fix the VGA BIOS but it's still broken in git. The one installed in /usr/share/qemu is fine, but whenever I build qemu from git I have to remember to *remove* the one in the git tree or it uses that instead...
Il 07/03/2013 21:24, David Woodhouse ha scritto:
On Thu, 2013-03-07 at 16:56 +0100, Gerd Hoffmann wrote:
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.
FWIW I find the binaries in git to be a PITA. I submitted a patch in January to fix the VGA BIOS but it's still broken in git. The one installed in /usr/share/qemu is fine, but whenever I build qemu from git I have to remember to *remove* the one in the git tree or it uses that instead...
Wasn't that a fix for the SeaBIOS VGA BIOS? The one in qemu.git is still built from the Bochs VGA BIOS.
Last year, malc blocked the switch on the lack of protected mode interface in SeaVGABIOS.
Paolo
On Fri, 2013-03-08 at 08:47 +0100, Paolo Bonzini wrote:
Wasn't that a fix for the SeaBIOS VGA BIOS? The one in qemu.git is still built from the Bochs VGA BIOS.
No, it was for Bochs VGA BIOS.
http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg03650.html
On 03/08/13 08:47, Paolo Bonzini wrote:
FWIW I find the binaries in git to be a PITA. I submitted a patch in January to fix the VGA BIOS but it's still broken in git. The one installed in /usr/share/qemu is fine, but whenever I build qemu from git I have to remember to *remove* the one in the git tree or it uses that instead...
Wasn't that a fix for the SeaBIOS VGA BIOS? The one in qemu.git is still built from the Bochs VGA BIOS.
Last year, malc blocked the switch on the lack of protected mode interface in SeaVGABIOS.
Fedora switched though, so the distro binaries in /usr/share/qemu are the seavgabios ones.
"make -C roms seavgabios" in the qemu source tree will upgrade the blobs in pc-bios/.
cheers, Gerd
Il 08/03/2013 09:20, Gerd Hoffmann ha scritto:
On 03/08/13 08:47, Paolo Bonzini wrote:
FWIW I find the binaries in git to be a PITA. I submitted a patch in January to fix the VGA BIOS but it's still broken in git. The one installed in /usr/share/qemu is fine, but whenever I build qemu from git I have to remember to *remove* the one in the git tree or it uses that instead...
Wasn't that a fix for the SeaBIOS VGA BIOS? The one in qemu.git is still built from the Bochs VGA BIOS.
Last year, malc blocked the switch on the lack of protected mode interface in SeaVGABIOS.
Fedora switched though, so the distro binaries in /usr/share/qemu are the seavgabios ones.
Did it? This is F18:
$ rpm -q --requires qemu-system-x86|grep bios seabios-bin >= 0.6.0-2 sgabios-bin vgabios >= 0.6c-2
$ rpm -q vgabios vgabios-0.6c-5.fc18.noarch
$ rpm -ql seabios-bin /usr/share/seabios /usr/share/seabios/bios.bin
$ rpm -qf /usr/share/vgabios/ vgabios-0.6c-5.fc18.noarch
Paolo
"make -C roms seavgabios" in the qemu source tree will upgrade the blobs in pc-bios/.
cheers, Gerd
Did it? This is F18:
$ rpm -q --requires qemu-system-x86|grep bios seabios-bin >= 0.6.0-2 sgabios-bin vgabios >= 0.6c-2
Oops.
There is a seavgabios-bin package too, and I through cole switched qemu over, but apparently this didn't happen (or maybe in rawhide only) ...
cheers, Gerd
-
David Woodhouse -
Gerd Hoffmann -
Paolo Bonzini -
Peter Maydell