On Tue, Jul 21, 2020 at 11:03:58PM +0200, Gerd Hoffmann wrote:
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
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.