Hi, qemu 5.1 is coming closer, with freeze in a week and release in August. See https://wiki.qemu.org/Planning/5.1 We'll need a new seabios release for qemu 5.1, and the options we have are: (1) cherry-pick bugfixes (at least the cirrus vga fix, probably more) into 1.13-stable, tag a 1.13.1 stable release. (2) tag a 1.14 release from master branch. Given we have several useful changes in the master branch which I would not consider being bugfixes a 1.14 released would be nice. Freeze in a week and release in three weeks should work fine with the qemu release schedule. What do you think? take care, Gerd
On Tue, Jun 30, 2020 at 10:57:15AM +0200, Gerd Hoffmann wrote:
Hi,
qemu 5.1 is coming closer, with freeze in a week and release in August. See https://wiki.qemu.org/Planning/5.1
We'll need a new seabios release for qemu 5.1, and the options we have are:
(1) cherry-pick bugfixes (at least the cirrus vga fix, probably more) into 1.13-stable, tag a 1.13.1 stable release. (2) tag a 1.14 release from master branch.
Given we have several useful changes in the master branch which I would not consider being bugfixes a 1.14 released would be nice. Freeze in a week and release in three weeks should work fine with the qemu release schedule.
What do you think?
Hi Gerd, if you happen to go with (1), could you please also include a fix for PIT? (floppy issue on isapc) (2) would require to disable newly added CONFIG_ACPI_PARSE for 128k BIOS, otherwise it doesn't fit. I don't know what implications are to run without the option (but it worked fine for legacy guests). Thanks, Roman
On Tue, Jun 30, 2020 at 10:57:15AM +0200, Gerd Hoffmann wrote:
Hi,
qemu 5.1 is coming closer, with freeze in a week and release in August. See https://wiki.qemu.org/Planning/5.1
We'll need a new seabios release for qemu 5.1, and the options we have are:
(1) cherry-pick bugfixes (at least the cirrus vga fix, probably more) into 1.13-stable, tag a 1.13.1 stable release. (2) tag a 1.14 release from master branch.
Given we have several useful changes in the master branch which I would not consider being bugfixes a 1.14 released would be nice. Freeze in a week and release in three weeks should work fine with the qemu release schedule.
What do you think?
I'm fine with tagging a new release. I'm not sure we'll necessarily match QEMU's schedule though. How about we target July 24th for the release? -Kevin
On Thu, Jul 02, 2020 at 07:36:43AM -0400, Kevin O'Connor wrote:
On Tue, Jun 30, 2020 at 10:57:15AM +0200, Gerd Hoffmann wrote:
Hi,
qemu 5.1 is coming closer, with freeze in a week and release in August. See https://wiki.qemu.org/Planning/5.1
We'll need a new seabios release for qemu 5.1, and the options we have are:
(1) cherry-pick bugfixes (at least the cirrus vga fix, probably more) into 1.13-stable, tag a 1.13.1 stable release. (2) tag a 1.14 release from master branch.
Given we have several useful changes in the master branch which I would not consider being bugfixes a 1.14 released would be nice. Freeze in a week and release in three weeks should work fine with the qemu release schedule.
What do you think?
I'm fine with tagging a new release. I'm not sure we'll necessarily match QEMU's schedule though. How about we target July 24th for the release?
That'll be fine. Early enough for -rc2, if something goes wrong we have -rc3 as fallback. I'll go update seabios to a snapshot beforehand, so seabios will get more testing and also to keep the delta small when updating to the released version during the freeze. take care, Gerd
On Thu, Jul 02, 2020 at 01:56:15PM +0200, Gerd Hoffmann wrote:
On Thu, Jul 02, 2020 at 07:36:43AM -0400, Kevin O'Connor wrote:
On Tue, Jun 30, 2020 at 10:57:15AM +0200, Gerd Hoffmann wrote:
Hi,
qemu 5.1 is coming closer, with freeze in a week and release in August. See https://wiki.qemu.org/Planning/5.1
We'll need a new seabios release for qemu 5.1, and the options we have are:
(1) cherry-pick bugfixes (at least the cirrus vga fix, probably more) into 1.13-stable, tag a 1.13.1 stable release. (2) tag a 1.14 release from master branch.
Given we have several useful changes in the master branch which I would not consider being bugfixes a 1.14 released would be nice. Freeze in a week and release in three weeks should work fine with the qemu release schedule.
What do you think?
I'm fine with tagging a new release. I'm not sure we'll necessarily match QEMU's schedule though. How about we target July 24th for the release?
That'll be fine. Early enough for -rc2, if something goes wrong we have -rc3 as fallback.
I'll go update seabios to a snapshot beforehand, so seabios will get more testing and also to keep the delta small when updating to the released version during the freeze.
Hi Gerd, What's your thoughts on this release and the recent ld issue? We can change SeaBIOS to work around the upstream change to ld and push it into this release (likely with a delay) or we can go forward with the release as is. Thoughts? -Kevin
Hi,
I'm fine with tagging a new release. I'm not sure we'll necessarily match QEMU's schedule though. How about we target July 24th for the release?
That'll be fine. Early enough for -rc2, if something goes wrong we have -rc3 as fallback.
I'll go update seabios to a snapshot beforehand, so seabios will get more testing and also to keep the delta small when updating to the released version during the freeze.
Hi Gerd,
What's your thoughts on this release and the recent ld issue? We can change SeaBIOS to work around the upstream change to ld and push it into this release (likely with a delay) or we can go forward with the release as is.
What kind of workaround? The binary patching with dd? I don't like it much, but given that the linux kernel does the same already the risk that it'll break something should be low, so I think we can do it. Longer-term it probably makes sense to look at the .incbin idea for a less hacky way to solve the problem. But that surely isn't something we want do only days before a release ... take care, Gerd
On Tue, Jul 21, 2020 at 11:03:58PM +0200, Gerd Hoffmann wrote:
I'm fine with tagging a new release. I'm not sure we'll necessarily match QEMU's schedule though. How about we target July 24th for the release?
That'll be fine. Early enough for -rc2, if something goes wrong we have -rc3 as fallback.
I'll go update seabios to a snapshot beforehand, so seabios will get more testing and also to keep the delta small when updating to the released version during the freeze.
What's your thoughts on this release and the recent ld issue? We can change SeaBIOS to work around the upstream change to ld and push it into this release (likely with a delay) or we can go forward with the release as is.
What kind of workaround? The binary patching with dd? I don't like it much, but given that the linux kernel does the same already the risk that it'll break something should be low, so I think we can do it.
Yes, the binary patching approach, but I'd use a python script instead of printf/dd - I sent a patch to the list.
Longer-term it probably makes sense to look at the .incbin idea for a less hacky way to solve the problem. But that surely isn't something we want do only days before a release ...
Unfortunately, I'm not sure .incbin will make sense. As I understand it, using .incbin would require writing a script to find all sections in the given object file, run objdump on each section, auto-generate an asssembler file with .incbin for every section, and then compile that assembler file. The end result would be a .o file that matches the original .o file, but with the single flag cleared. It might make sense to update layoutrom.py to just manually generate the final binary. (That is, to avoid using ld at all.) That is a bunch of work though. In any case, I agree, it doesn't make sense to take that on just prior to a release. -Kevin
On Thu, Jul 02, 2020 at 01:56:15PM +0200, Gerd Hoffmann wrote:
On Thu, Jul 02, 2020 at 07:36:43AM -0400, Kevin O'Connor wrote:
On Tue, Jun 30, 2020 at 10:57:15AM +0200, Gerd Hoffmann wrote:
Hi,
qemu 5.1 is coming closer, with freeze in a week and release in August. See https://wiki.qemu.org/Planning/5.1
We'll need a new seabios release for qemu 5.1, and the options we have are:
(1) cherry-pick bugfixes (at least the cirrus vga fix, probably more) into 1.13-stable, tag a 1.13.1 stable release. (2) tag a 1.14 release from master branch.
Given we have several useful changes in the master branch which I would not consider being bugfixes a 1.14 released would be nice. Freeze in a week and release in three weeks should work fine with the qemu release schedule.
What do you think?
I'm fine with tagging a new release. I'm not sure we'll necessarily match QEMU's schedule though. How about we target July 24th for the release?
That'll be fine. Early enough for -rc2, if something goes wrong we have -rc3 as fallback.
I'll go update seabios to a snapshot beforehand, so seabios will get more testing and also to keep the delta small when updating to the released version during the freeze.
FYI, some fixes were applied to the tree today. Right now I'm thinking we delay the release to the end of next week (~Aug 6th). Let me know if there are any concerns. -Kevin
participants (3)
-
Gerd Hoffmann -
Kevin O'Connor -
Roman Bolshakov