sys-libs/efivar-0.20 fails in 'make test' both inside and outside of portage with or without sandboxing and user privilege. In the most permissive build as root without sandboxing or userpriv, it fails at testing efi_set_variable() with too many arguments FAIL: "one"(line 169) (-1) set test failed: Invalid argument As a non-root user, the same area fails with a permission issue. If it were just the permission issue, I wouldn't be as concerned, but it does appear to be failing even if the permission issue is worked around.
I wonder if we should just set RESTRICT=test. It seems like a bad idea for an ebuild to be setting EFI variables on a live system.
(In reply to Mike Gilbert from comment #1) > I wonder if we should just set RESTRICT=test. It seems like a bad idea for > an ebuild to be setting EFI variables on a live system. On the other hand, if such a feature were not working properly, I'd want to know before it were permanently in place. Having looked at the tests it does, it appears the unique key for an EFI variable consists of a GUID and a name. The GUID should be unused by anything else if generated correctly. So all tests happen with different names, but they all happen in the namespace of a GUID. Before testing, variables names under that GUID are cleared. After testing when successful, those names are cleared. After testing when not successful, those names are cleared. So as long as that testing arrangement remains the same, I'd want it to fail while testing instead of while 'live' manipulating non-test data. Only if the cleanup method isn't working would it leave something behind and so long as that failure is in efivar code and no in the actual EFI hardware, it can be cleaned up and indicates a problem with that efivar version before it got written to EFI and if it's a problem with the cleanup at the EFI level becomes something non-recoverable. Even then, it's under a test GUID namespace, so as long as nothing reads it in for another purpose, then I don't see these tests causing a problem.
