Re: [new] sysutils/efivar
On Wed, Apr 26, 2023 at 05:33:15PM +0100, Stuart Henderson wrote: > New tgz attached with tweaks: > > - we can't use -march=native in package builds > - shared lib versions must be under control of the SHARED_LIBS variable > - don't install shlib symlinks > - use category 'sysutils' not 'devel' > > ports-wise I'm happy with it, but I tried running 'efivar -l' as root > and hit a kernel panic but I am on a kernel from a couple of days ago > and there's a hackathon on, so that might not have been directly related > to efivar / /dev/efi and might have already been fixed, will retest on a > newer kernel sometime later or tomorrow. Thanks, tiny edit: added a comment for the new patch. Not sure about the kernel panic. Updated to the latest snapshot and everything seems to work well. If it won't go away, I can look into it if you provide a backtrace. efivar.tgz Description: application/tar-gz
Re: [new] sysutils/efivar
On Thu, Apr 27, 2023 at 11:34:11AM +, Klemens Nanni wrote: > As normal user, I'd expect EACCES or EPERM, the current warning misleads: > $ efivar -l > efivar: error listing variables: Function not implemented The code supports multiple backends and without root none of them is applicable. This leads to ENOSYS on calling any function that deals with efivars. Changing this can cause differences in behaviour of the library. > We point GH_* at the BSD fork and HOMEPAGE at Linux upstream. > Would it be better to drop HOMEAGE, i.e. stick with the fork and adjust > its description on GitHub so that actually becomes obvious from reading > the "homepage"? Updated HOMEPAGE. Also updated the repo to show `bsd` branch by default and mentioned the purpose of the fork in the description. > Are the spaces in SHARED_LIBS intended? Changed to tabs. efivar.tgz Description: application/tar-gz
Re: [new] sysutils/efivar
On Thu, Apr 27, 2023 at 04:00:51PM +0300, Sergii Dmytruk wrote: > On Thu, Apr 27, 2023 at 11:34:11AM +, Klemens Nanni wrote: > > As normal user, I'd expect EACCES or EPERM, the current warning misleads: > > $ efivar -l > > efivar: error listing variables: Function not implemented > > The code supports multiple backends and without root none of them is > applicable. This leads to ENOSYS on calling any function that deals > with efivars. Changing this can cause differences in behaviour of the > library. > > > We point GH_* at the BSD fork and HOMEPAGE at Linux upstream. > > Would it be better to drop HOMEAGE, i.e. stick with the fork and adjust > > its description on GitHub so that actually becomes obvious from reading > > the "homepage"? > > Updated HOMEPAGE. Also updated the repo to show `bsd` branch by default > and mentioned the purpose of the fork in the description. > > > Are the spaces in SHARED_LIBS intended? > > Changed to tabs. Snapshots from 28.04. and 03.05. no longer panic on my Intel T14g3, --list and --print work as expected. OK to import?
Re: [new] sysutils/efivar
On Wed, May 03, 2023 at 01:37:14PM +, Klemens Nanni wrote: > Snapshots from 28.04. and 03.05. no longer panic on my Intel T14g3, > --list and --print work as expected. Note quite :/ now I hit a kernel protection fault again on 'efivar -l' right after reboot. Can't tell if this is the port, /dev/efi, just my machine or something else... it locks up/DDB is unusable, so it'll take me some time to pin this down further.
Re: [new] sysutils/efivar
On Thu, Apr 27, 2023 at 04:00:51PM +0300, Sergii Dmytruk wrote:
> On Thu, Apr 27, 2023 at 11:34:11AM +, Klemens Nanni wrote:
> > As normal user, I'd expect EACCES or EPERM, the current warning misleads:
> > $ efivar -l
> > efivar: error listing variables: Function not implemented
>
> The code supports multiple backends and without root none of them is
> applicable. This leads to ENOSYS on calling any function that deals
> with efivars. Changing this can cause differences in behaviour of the
> library.
>
> > We point GH_* at the BSD fork and HOMEPAGE at Linux upstream.
> > Would it be better to drop HOMEAGE, i.e. stick with the fork and adjust
> > its description on GitHub so that actually becomes obvious from reading
> > the "homepage"?
>
> Updated HOMEPAGE. Also updated the repo to show `bsd` branch by default
> and mentioned the purpose of the fork in the description.
>
> > Are the spaces in SHARED_LIBS intended?
>
> Changed to tabs.
.so versioning was still wrong in this tarball.
Haven't made progress on the panics, but here's the polished port I'm
toying with.
Diff against yours to illustrate:
diff --git a/sysutils/efivar/Makefile b/sysutils/efivar/Makefile
index af873225a..165347318 100644
--- a/sysutils/efivar/Makefile
+++ b/sysutils/efivar/Makefile
@@ -28,13 +28,12 @@ PERMIT_PACKAGE =Yes
WANTLIB += c
USE_GMAKE =Yes
-MAKE_FLAGS = CC=${CC}
-MAKE_ENV = HOST_MARCH='' \
- LIBefivar_VERSION=${LIBefivar_VERSION} \
- LIBefiboot_VERSION=${LIBefiboot_VERSION} \
- LIBefisec_VERSION=${LIBefisec_VERSION}
-FAKE_FLAGS = PREFIX=${PREFIX} \
+MAKE_FLAGS = CC=${CC} \
MANDIR=${PREFIX}/man \
LIBDIR=${PREFIX}/lib
+MAKE_ENV = LIBefivar_VERSION=${LIBefivar_VERSION} \
+ LIBefiboot_VERSION=${LIBefiboot_VERSION} \
+ LIBefisec_VERSION=${LIBefisec_VERSION}
+FAKE_FLAGS = PREFIX=${PREFIX}
.include
diff --git a/sysutils/efivar/patches/patch-src_Makefile
b/sysutils/efivar/patches/patch-src_Makefile
index 4a5ea2061..a933d4469 100644
--- a/sysutils/efivar/patches/patch-src_Makefile
+++ b/sysutils/efivar/patches/patch-src_Makefile
@@ -1,17 +1,20 @@
-Fix .so versioning
Don't create symlinks for shared libraries.
Index: src/Makefile
--- src/Makefile.orig
+++ src/Makefile
-@@ -147,9 +147,7 @@ clean :
+@@ -146,11 +146,9 @@ clean :
+
install : all
$(INSTALL) -d -m 755 $(DESTDIR)$(LIBDIR)
- $(foreach x,$(LIBTARGETS), \
+- $(foreach x,$(LIBTARGETS), \
- $(INSTALL) -m 755 $(x) $(DESTDIR)$(LIBDIR)/$(x).1.$(VERSION) ;\
- ln -fs $(x).1.$(VERSION) $(DESTDIR)$(LIBDIR)/$(x).1 ;\
- ln -fs $(x).1.$(VERSION) $(DESTDIR)$(LIBDIR)/$(x) ;\
-+ $(INSTALL) -m 755 $(x) $(DESTDIR)$(LIBDIR)/$(x).$(LIB$(subst
lib,,$(x:%.so=%))_VERSION) ;\
- )
+- )
++ $(INSTALL) -m 755 libefivar.so
$(DESTDIR)$(LIBDIR)/libefivar.so.$(LIBefivar_VERSION)
++ $(INSTALL) -m 755 libefiboot.so
$(DESTDIR)$(LIBDIR)/libefiboot.so.$(LIBefiboot_VERSION)
++ $(INSTALL) -m 755 libefisec.so
$(DESTDIR)$(LIBDIR)/libefisec.so.$(LIBefisec_VERSION)
$(INSTALL) -d -m 755 $(DESTDIR)$(PCDIR)
$(foreach x, $(PCTARGETS), $(INSTALL) -m 644 $(x) $(DESTDIR)$(PCDIR) ;)
+ $(INSTALL) -d -m 755 $(DESTDIR)$(INCLUDEDIR)/efivar
diff --git a/sysutils/efivar/patches/patch-src_include_defaults_mk
b/sysutils/efivar/patches/patch-src_include_defaults_mk
index 3845881ba..7955b6fb2 100644
--- a/sysutils/efivar/patches/patch-src_include_defaults_mk
+++ b/sysutils/efivar/patches/patch-src_include_defaults_mk
@@ -1,4 +1,4 @@
-Fix .so versioning
+Don't hard-code soname into shared libraries
Packages can't be built with -march=native
Index: src/include/defaults.mk
@@ -9,7 +9,16 @@ Index: src/include/defaults.mk
override _SOFLAGS := $(SOFLAGS)
override SOFLAGS = $(_SOFLAGS) \
- -shared -Wl,-soname,$@.1 \
-+ -shared -Wl,-soname,$@.$(LIB$(subst
lib,,$(@:%.so=%))_VERSION) \
++ -shared \
-Wl,--version-script=$(MAP) \
$(call family,SOFLAGS)
+@@ -82,7 +82,7 @@ endif
+ HOST_CPPFLAGS ?= $(CPPFLAGS)
+ override _HOST_CPPFLAGS := $(HOST_CPPFLAGS)
+ override HOST_CPPFLAGS = $(_HOST_CPPFLAGS) \
+- -DEFIVAR_BUILD_ENVIRONMENT $(HOST_MARCH)
++ -DEFIVAR_BUILD_ENVIRONMENT
+ HOST_CFLAGS_GCC ?=
+ HOST_CFLAGS_CLANG ?=
+ HOST_CFLAGS ?= $(CFLAGS) $(call family,HOST_CFLAGS)
efivar.tgz
Description: application/tar-gz
Re: [new] sysutils/efivar
On Wed, Apr 26, 2023 at 08:13:39PM +0300, Sergii Dmytruk wrote: > On Wed, Apr 26, 2023 at 05:33:15PM +0100, Stuart Henderson wrote: > > New tgz attached with tweaks: > > > > - we can't use -march=native in package builds > > - shared lib versions must be under control of the SHARED_LIBS variable > > - don't install shlib symlinks > > - use category 'sysutils' not 'devel' > > > > ports-wise I'm happy with it, but I tried running 'efivar -l' as root > > and hit a kernel panic but I am on a kernel from a couple of days ago > > and there's a hackathon on, so that might not have been directly related > > to efivar / /dev/efi and might have already been fixed, will retest on a > > newer kernel sometime later or tomorrow. > > Thanks, tiny edit: added a comment for the new patch. > > Not sure about the kernel panic. Updated to the latest snapshot and > everything seems to work well. If it won't go away, I can look into it > if you provide a backtrace. With help from jasper we just tested it successfully on his machine and imported sysutils/efivar, thanks. It remains unhooked, that means it won't show up in binary packages and you have to build/install it yourself. Once we know more about these crashes and hpefully fixed them, the port will be hooked up as usual.
