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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
