Re: help? efivar 0.20-3 fails to build on arm64
On Thu, Jun 25, 2015 at 03:44:16PM +0800, Paul Wise wrote:
> On Thu, Jun 25, 2015 at 10:16 AM, D. Jared Dominguez wrote:
>
> > The moral of the story is that I uploaded efivar 0.20-4, which disables
> > dh_auto_test, and it should stay that way.
>
> Build-time tests should never affect the build system, I would suggest
> talking upstream into splitting tests of the build system firmware out
> of `make test` and into `make test-build-system-firmware` or the like.
> There are probably some tests that don't interact with the build
> system firmware?
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.
> 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
to orchestrate it with Jenkins (which we're using for other things here)
using OVMF/AAVMF, along with test suites for a bunch of the other UEFI
utilities we maintain. I've got some local work in progress towards
that for shim, fwupdate, and efibootmgr; when I'm a bit farther along
it'll be very easy to add efivar to that. That work is on hold right
now while we do a product release, but it should ramp up pretty strongly
in a couple of weeks.
The hard part will be making the Jenkins results public, because the
machines it'll actually run on are internal here. That's a problem we
have for other projects as well :/ . That said, I'll definitely push
all the actual code for it to a public repo, so others can easily
reproduce the results etc., so we can use them with LUV and similar.
--
Peter
Reply to: