Re: help? efivar 0.20-3 fails to build on arm64
On Thu, Jun 25, 2015 at 12:21:25AM +0100, Steve McIntyre wrote:
> On Wed, Jun 24, 2015 at 05:50:26PM -0500, D. Jared Dominguez wrote:
> >Hi Wookey!
> >
> >>Given that this package is correctly skipping the test on the non-UEFI
> >>machine, the correct fix would seem to be to fix the test on the UEFI
> >>machine.
> >
> >Yes, though Peter Jones told me after I sent the initial email: "I would
> >recommend not running it during a normal build." He's got some open issues
> >with the test suite that he's concluded are due to broken firmware, not
> >efivar being broken. I disabled dh_auto_test. I'll enable it again once Peter
> >deems it more ready, though he noted that he thinks it makes more sense to
> >rig up the tests in jenkins, which is on his to-do list.
Just to be clear there are a couple of problems with the test suite that
are probably legitimately my problem as well :/ .
> I'd be worried about running tests on a buildd that may actually
> permanently affect the hardware of the buildd! Simple read-only tests
> that verify some of the behaviour of efivar might make sense as part
> of the build verification, but nothing that attempts to write, imho.
>
> Unless there's an emulation layer that could be used to test efivar
> behaviour in a test harness, that would be lovely. And lots of work, I
> know!
Well, my plan is to set up a jenkins instance that runs the tests under
OVMF/AAVMF. So they'd just be being backed to a file, not to a flash
part.
> How does this work on the x86 buildds? I'm not sure what the state of
> those is wrt UEFI either...
All hardware is terrible, but the confluence of bugs in the test suite
and bugs in the firmware seems to be stronger on aarch64 at the moment -
part of this is that the code has simply been used on x86_64 much more,
and part of it is that machines like Mustang have had a lot less
validation - real world or otherwise - than the commercially available
x86_64 UEFI machines. And part of it is that you're running some of the
builds on non-UEFI machines, and on those machines the test suite just
returns success.
But I wouldn't run the test suite during the build in any case, because
it does often cause machines to be unusable without some physical
intervention - but usually these days that's just a reboot so the
firmware will do a GC cycle on the flash, sometimes it means manually
removing some variables and rebooting a second time, etc. (Not every
vendor has Samsung's quality control department.)
--
Peter
Reply to: