Re: help? efivar 0.20-3 fails to build on arm64
On Fri, Jun 26, 2015 at 11:46:38AM +0800, Paul Wise wrote:
> On Thu, 2015-06-25 at 11:05 -0400, Peter Jones wrote:
>
> > The thing is, *all* the library does is provide a C API for interactions
> > with firmware. So that's really what "make test" exercises, which is
> > why a) it's more useful for "did my changes break anything" during
> > development than anything else, b) it just shouldn't be run in a normal
> > package build, and c) it trips up on firmware interaction a lot when the
> > firmware isn't very mature.
>
> The best way to avoid b) is to rename it to something other than "test"
> or "check" since Debian and probably other distros automatically run
> those make targets.
>
> Some possible alternative options:
>
> make developer-tests
> make maybe-break-my-system-please ;)
>
*ahem*,
https://github.com/rhinstaller/efivar/commit/510b861012c111a362aa4c3da6ba408f2d78aaca
> > > It might also be interesting for edk2 (ovmf/qemu-efi) to run efivar to
> > > test themselves.
> >
> > Yeah, that's definitely a good idea. My plan for "make test" has been...
>
> Sounds good, thanks.
>
> OVMF/AAVMF is unfortunately non-free due to the FAT driver license.
> How are RedHat, Linaro etc dealing with that issue?
By not distributing it in Fedora, so far. We've been looking at
options, and it's worth noting that there *is* a Free-as-in-Freedom FAT
driver ( https://github.com/pbatard/efifs ), but it's derived from grub
code that's GPLv3, and that makes for some interesting legal questions
as well since in at least some of the ovmf/aavmf builds we want Secure
Boot enabled, and absent a whole lot of work that means linking openssl
in. I'm not even going to get in to thinking about which work is
derivative of which between linking those three trees together.
--
Peter
Reply to: