[Buildroot] Patch series

[Buildroot] Patch series

[Norbert Lange]

As is was suggested I pulled my patches in a series,
this should combine most of my open work.

It does *not* contain:

-   toolchain: support mismatched merged usr [1]
    recent enough

-   package/dbus-broker: new package [2]
    recent enough

-   package/openssh: improve integration for systemd [3]
    outdated, no time to fix it


Patch 1 and 2 set the runstatedir for CMake and Autotools (new patches)

Patch 3 and 4 are rebased and adopted to feedback.

Patch 5 contains a better commit message

Patch 6 and 7 are new


[PATCH v3 1/7] package/pkg-cmake.mk: use /run as runtime path
[PATCH v3 2/7] pkg-autotools: optimistically set runstatedir
[PATCH v3 3/7] package/systemd: use current tool for generating HWDB
[PATCH v3 4/7] package/systemd: remove hwdb-update service
[PATCH v3 5/7] Makefile: remove /usr/lib/rpm directory on target
[PATCH v3 6/7] package/zsh: Enable dynamic modules
[PATCH v3 7/7] package/zsh: enable static regex module

[1] - https://lists.buildroot.org/pipermail/buildroot/2022-February/637079.html
[2] - https://patchwork.ozlabs.org/project/buildroot/patch/20220109221650.777610-1-nolange79@gmail.com/
[3] - https://patchwork.ozlabs.org/project/buildroot/patch/20200611091407.12688-2-nolange79@gmail.com/

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v3 1/7] package/pkg-cmake.mk: use /run as runtime path

[Norbert Lange]

Buildroot prefers /run as runstate directory, make this the
default.

Signed-off-by: Norbert Lange <nolange79@gmail.com>
---
 package/pkg-cmake.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/pkg-cmake.mk b/package/pkg-cmake.mk
index 3b1db35fb6..081960b5bf 100644
--- a/package/pkg-cmake.mk
+++ b/package/pkg-cmake.mk
@@ -90,6 +90,7 @@ define $(2)_CONFIGURE_CMDS
 	$$($$(PKG)_CONF_ENV) $$(BR2_CMAKE) $$($$(PKG)_SRCDIR) \
 		-DCMAKE_TOOLCHAIN_FILE="$$(HOST_DIR)/share/buildroot/toolchainfile.cmake" \
 		-DCMAKE_INSTALL_PREFIX="/usr" \
+		-DCMAKE_INSTALL_RUNSTATEDIR="/run" \
 		-DCMAKE_COLOR_MAKEFILE=OFF \
 		-DBUILD_DOC=OFF \
 		-DBUILD_DOCS=OFF \
-- 
2.34.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v3 2/7] pkg-autotools: optimistically set runstatedir

[Norbert Lange]

since Autotools 2.70 there is an option to set the
runstatedir. To support configure scripts using older version,
the variable is set directly instead of using the --runstatedir
argument.

Signed-off-by: Norbert Lange <nolange79@gmail.com>
---
 package/pkg-autotools.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/pkg-autotools.mk b/package/pkg-autotools.mk
index 717ff81593..b6224b349d 100644
--- a/package/pkg-autotools.mk
+++ b/package/pkg-autotools.mk
@@ -187,6 +187,7 @@ define $(2)_CONFIGURE_CMDS
 		--exec-prefix=/usr \
 		--sysconfdir=/etc \
 		--localstatedir=/var \
+		runstatedir=/run \
 		--program-prefix="" \
 		--disable-gtk-doc \
 		--disable-gtk-doc-html \
-- 
2.34.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v3 2/7] pkg-autotools: optimistically set runstatedir

[Yann E. MORIN]

Norbert, All,

On 2022-02-22 11:22 +0100, Norbert Lange spake thusly:
> since Autotools 2.70 there is an option to set the
> runstatedir. To support configure scripts using older version,
> the variable is set directly instead of using the --runstatedir
> argument.
> 
> Signed-off-by: Norbert Lange <nolange79@gmail.com>
> ---
>  package/pkg-autotools.mk | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/package/pkg-autotools.mk b/package/pkg-autotools.mk
> index 717ff81593..b6224b349d 100644
> --- a/package/pkg-autotools.mk
> +++ b/package/pkg-autotools.mk
> @@ -187,6 +187,7 @@ define $(2)_CONFIGURE_CMDS
>  		--exec-prefix=/usr \
>  		--sysconfdir=/etc \
>  		--localstatedir=/var \
> +		runstatedir=/run \

We have unfortunately had to revert this change as well as all the
various hacke we tried to fix it, for various reasons (list below
serving as a memo for the futur):

 1. --runstatedir only appeared in autotools 2.69b, and we still have
    packages that were autoconf-ed with previous versions, and thus
    do not support the option;

So we tried with passing it as a variable assignment, but...

 2. passing runstatedir=/path as a variable assignment on the command
    line actually breaks packages with very old autotools versions, like
    2.13, which get confused as they believe this is specifying the
    host;

So we got back to an option, but only if we could grep it in the
configure script; yet...

 3. packages that do recognise --runstatedir in their top-level
    configure script, may still break with configure scripts in
    sub-directories, written with older autoconf vrsions, so back to
    square one.

Given that we are nearing the release, given that FHS 3.15 does
acknowledge that /var/run can continue to exist for backward
compatibility, and that it suggests individual programs (not whole
systems!) to only use one or the other, we should just continue to
support /var/run (if at least for binary-only cruft that may still be
lying around and need /var/run anyway).

As a consequence, not having a generic solution to pass --runstatedir
(or an equivalent) is not a blocker, and is not a regression either.

Sure, having it would be better, but we can't make it work reasonably
well for now.

So, here is a brain-dmup of some thoughts about that (stil just thinking
about autotools here):

  - packages that actually want to access runstatedir will have a way to
    specify it, be it the option or the variable assignment, or even
    something else;

  - packages that have neither the option nor the variable, would most
    probably not need to access runstatedir at all.

As a consequence, what are the odds that a package needs runstatedir?
Are they legion, or are they few? If they are relatively few, then we
can just add the applicable solution (option or variable) on a
per-package basis.

And I think this is most probably the simplest and most efficient
solution, as we can't have a generic one.

Unless we can come with a much clever solution...

Speaking of cleverness: Peter suggested checking for --runstatedir
recursively in all configure scripts, and only pass it if they all
suport it.

However, I think this might be incorrect: the top-level configure script
could support it, and the package needs it, but sub-configures may not
support it (or there is a file named configure in a sub-dir, which is
not an actual configure script (or is not needed), in which case we
would miss the opportunity for the generic solution, and we'd be back on
a per-package _CONF_OPTS...

So, I'm still thinking the per-package _CONF_OPTS is way better
overall...

Untill we can get a better solution, or all upstream packages have been
fixed and bumped in Buildroot... :-]

Thanks for the initial patch! We tried, it did not work, we reverted.

Regards,
Yann E. MORIN.

>  		--program-prefix="" \
>  		--disable-gtk-doc \
>  		--disable-gtk-doc-html \
> -- 
> 2.34.1
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v3 3/7] package/systemd: use current tool for generating HWDB

[Norbert Lange]

udevadm has been deprecated for a while (for building the DB),
systemd-hwdb should be used in its place.

this tool further has a switch to generate the database in
/usr which is a better place for a one-time created file
than the default /etc/udev.

The HWDB source files have drop-in directories, which means
even if disabled in this package, other packages or users
could drop in stuff. So always delete those

Signed-off-by: Norbert Lange <nolange79@gmail.com>

---
v1 -> v2
-   fix removal of service
v2 -> v3
-   see https://lists.buildroot.org/pipermail/buildroot/2020-July/286310.html
-   use systemd-hwdb with --strict option
-   split removal of service in separate patch
-   improve commit message
-   always delete de HWDB source directories
---
 package/systemd/systemd.mk | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
index b07fac27d4..d2c28b5b60 100644
--- a/package/systemd/systemd.mk
+++ b/package/systemd/systemd.mk
@@ -307,13 +307,9 @@ endif
 ifeq ($(BR2_PACKAGE_SYSTEMD_HWDB),y)
 SYSTEMD_CONF_OPTS += -Dhwdb=true
 define SYSTEMD_BUILD_HWDB
-	$(HOST_DIR)/bin/udevadm hwdb --update --root $(TARGET_DIR)
+	$(HOST_DIR)/bin/systemd-hwdb update --root $(TARGET_DIR) --strict --usr
 endef
 SYSTEMD_TARGET_FINALIZE_HOOKS += SYSTEMD_BUILD_HWDB
-define SYSTEMD_RM_HWDB_SRV
-	rm -rf $(TARGET_DIR)/$(HOST_EUDEV_SYSCONFDIR)/udev/hwdb.d/
-endef
-SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SYSTEMD_RM_HWDB_SRV
 else
 SYSTEMD_CONF_OPTS += -Dhwdb=false
 endif
@@ -725,6 +721,11 @@ endef
 SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SYSTEMD_UPDATE_CATALOGS
 endif
 
+define SYSTEMD_RM_HWDB_DATA
+	rm -rf $(TARGET_DIR)/usr/lib/udev/hwdb.d/ $(TARGET_DIR)/etc/udev/hwdb.d/
+endef
+SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SYSTEMD_RM_HWDB_DATA
+
 define SYSTEMD_RM_CATALOG_UPDATE_SERVICE
 	rm -rf $(TARGET_DIR)/usr/lib/systemd/catalog \
 		$(TARGET_DIR)/usr/lib/systemd/system/systemd-journal-catalog-update.service \
@@ -814,7 +815,7 @@ HOST_SYSTEMD_CONF_OPTS = \
 	-Dsysusers=false \
 	-Dtmpfiles=true \
 	-Dimportd=false \
-	-Dhwdb=false \
+	-Dhwdb=true \
 	-Drfkill=false \
 	-Dman=false \
 	-Dhtml=false \
-- 
2.34.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v3 3/7] package/systemd: use current tool for generating HWDB

[Arnout Vandecappelle]

On 22/02/2022 11:22, Norbert Lange wrote:
> udevadm has been deprecated for a while (for building the DB),
> systemd-hwdb should be used in its place.
> 
> this tool further has a switch to generate the database in
> /usr which is a better place for a one-time created file
> than the default /etc/udev.

  This is one thing.

> 
> The HWDB source files have drop-in directories, which means
> even if disabled in this package, other packages or users
> could drop in stuff. So always delete those

  And this is something else. So I split the patch in two.

  It also lead us to observe that:

- there's some leftover code in eudev.mk that can be removed;
- we should do the same in eudev (i.e. also delete /usr/lib/udev/hwdb.d) - or 
rather, we should do the same regardless of the device manager used.

  I'm going to send separate patches for those. Especially the second I'm not 
100% sure of, but it seems weird to not delete them if there's no hwdb.


  Regards,
  Arnout


> Signed-off-by: Norbert Lange <nolange79@gmail.com>
> 
> ---
> v1 -> v2
> -   fix removal of service
> v2 -> v3
> -   see https://lists.buildroot.org/pipermail/buildroot/2020-July/286310.html
> -   use systemd-hwdb with --strict option
> -   split removal of service in separate patch
> -   improve commit message
> -   always delete de HWDB source directories
> ---
>   package/systemd/systemd.mk | 13 +++++++------
>   1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> index b07fac27d4..d2c28b5b60 100644
> --- a/package/systemd/systemd.mk
> +++ b/package/systemd/systemd.mk
> @@ -307,13 +307,9 @@ endif
>   ifeq ($(BR2_PACKAGE_SYSTEMD_HWDB),y)
>   SYSTEMD_CONF_OPTS += -Dhwdb=true
>   define SYSTEMD_BUILD_HWDB
> -	$(HOST_DIR)/bin/udevadm hwdb --update --root $(TARGET_DIR)
> +	$(HOST_DIR)/bin/systemd-hwdb update --root $(TARGET_DIR) --strict --usr
>   endef
>   SYSTEMD_TARGET_FINALIZE_HOOKS += SYSTEMD_BUILD_HWDB
> -define SYSTEMD_RM_HWDB_SRV
> -	rm -rf $(TARGET_DIR)/$(HOST_EUDEV_SYSCONFDIR)/udev/hwdb.d/
> -endef
> -SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SYSTEMD_RM_HWDB_SRV
>   else
>   SYSTEMD_CONF_OPTS += -Dhwdb=false
>   endif
> @@ -725,6 +721,11 @@ endef
>   SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SYSTEMD_UPDATE_CATALOGS
>   endif
>   
> +define SYSTEMD_RM_HWDB_DATA
> +	rm -rf $(TARGET_DIR)/usr/lib/udev/hwdb.d/ $(TARGET_DIR)/etc/udev/hwdb.d/
> +endef
> +SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SYSTEMD_RM_HWDB_DATA
> +
>   define SYSTEMD_RM_CATALOG_UPDATE_SERVICE
>   	rm -rf $(TARGET_DIR)/usr/lib/systemd/catalog \
>   		$(TARGET_DIR)/usr/lib/systemd/system/systemd-journal-catalog-update.service \
> @@ -814,7 +815,7 @@ HOST_SYSTEMD_CONF_OPTS = \
>   	-Dsysusers=false \
>   	-Dtmpfiles=true \
>   	-Dimportd=false \
> -	-Dhwdb=false \
> +	-Dhwdb=true \
>   	-Drfkill=false \
>   	-Dman=false \
>   	-Dhtml=false \
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v3 4/7] package/systemd: remove hwdb-update service

[Norbert Lange]

since the source HWDB files are already removed from the target
system, it makes little sense to keep the service around.
If accidently triggered it could create an empty database.

The service is installed in both staging and host directory,
so a user could craft his own solutions if its necessary to
update the database.

Signed-off-by: Norbert Lange <nolange79@gmail.com>
---
 package/systemd/systemd.mk | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
index d2c28b5b60..44297875f6 100644
--- a/package/systemd/systemd.mk
+++ b/package/systemd/systemd.mk
@@ -310,6 +310,12 @@ define SYSTEMD_BUILD_HWDB
 	$(HOST_DIR)/bin/systemd-hwdb update --root $(TARGET_DIR) --strict --usr
 endef
 SYSTEMD_TARGET_FINALIZE_HOOKS += SYSTEMD_BUILD_HWDB
+define SYSTEMD_RM_HWBD_UPDATE_SERVICE
+	rm -rf $(TARGET_DIR)/usr/lib/systemd/system/systemd-hwdb-update.service \
+		$(TARGET_DIR)/usr/lib/systemd/system/*/systemd-hwdb-update.service \
+		$(TARGET_DIR)/usr/bin/systemd-hwdb
+endef
+SYSTEMD_POST_INSTALL_TARGET_HOOKS += SYSTEMD_RM_HWBD_UPDATE_SERVICE
 else
 SYSTEMD_CONF_OPTS += -Dhwdb=false
 endif
-- 
2.34.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v3 5/7] Makefile: remove /usr/lib/rpm directory on target

[Norbert Lange]

this directory is used by the rpm package manager, and packages
like systemd will install "macros" for this system.

It should be deleted just like the similar
/usr/share/aclocal directory from Autoconf.

Signed-off-by: Norbert Lange <nolange79@gmail.com>
---
v1 -> v2
-   see https://lists.buildroot.org/pipermail/buildroot/2020-June/284213.html
-   improved commit message

Signed-off-by: Norbert Lange <nolange79@gmail.com>
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index d92438166f..4953b382ca 100644
--- a/Makefile
+++ b/Makefile
@@ -734,7 +734,7 @@ target-finalize: $(PACKAGES) $(TARGET_DIR) host-finalize
 	rm -rf $(TARGET_DIR)/usr/include $(TARGET_DIR)/usr/share/aclocal \
 		$(TARGET_DIR)/usr/lib/pkgconfig $(TARGET_DIR)/usr/share/pkgconfig \
 		$(TARGET_DIR)/usr/lib/cmake $(TARGET_DIR)/usr/share/cmake \
-		$(TARGET_DIR)/usr/doc
+		$(TARGET_DIR)/usr/lib/rpm $(TARGET_DIR)/usr/doc
 	find $(TARGET_DIR)/usr/{lib,share}/ -name '*.cmake' -print0 | xargs -0 rm -f
 	find $(TARGET_DIR)/lib/ $(TARGET_DIR)/usr/lib/ $(TARGET_DIR)/usr/libexec/ \
 		\( -name '*.a' -o -name '*.la' -o -name '*.prl' \) -print0 | xargs -0 rm -f
-- 
2.34.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v3 6/7] package/zsh: Enable dynamic modules

[Norbert Lange]

The autoconf scripts seem to assume that no dynamic loader
is available if crosscompiling.
This results in only a small set of modules being enabled
and linked statically.

For comparison, debian patches the fallback to enable
dynamic modules (unconditionally).

This commit enables modules if shared libraries are enabled.

Signed-off-by: Norbert Lange <nolange79@gmail.com>

---
v1:
-   so far only tested with glibc
---
 package/zsh/zsh.mk | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/package/zsh/zsh.mk b/package/zsh/zsh.mk
index c5ab7c2fae..c26a00c430 100644
--- a/package/zsh/zsh.mk
+++ b/package/zsh/zsh.mk
@@ -36,6 +36,14 @@ else
 ZSH_CONF_OPTS += --disable-pcre
 endif
 
+ifneq ($(BR2_STATIC_LIBS),y)
+# zsh assumes shared libs to be not available when crosscompiling
+ZSH_CONF_OPTS += zsh_cv_shared_environ=yes zsh_cv_shared_tgetent=yes \
+	zsh_cv_shared_tigetstr=yes zsh_cv_sys_dynamic_clash_ok=yes \
+	zsh_cv_sys_dynamic_rtld_global=yes zsh_cv_sys_dynamic_execsyms=yes \
+	zsh_cv_sys_dynamic_strip_exe=yes zsh_cv_sys_dynamic_strip_lib=yes
+endif
+
 # Add /bin/zsh to /etc/shells otherwise some login tools like dropbear
 # can reject the user connection. See man shells.
 define ZSH_ADD_ZSH_TO_SHELLS
-- 
2.34.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v3 6/7] package/zsh: Enable dynamic modules

[Arnout Vandecappelle]

On 22/02/2022 11:22, Norbert Lange wrote:
> The autoconf scripts seem to assume that no dynamic loader
> is available if crosscompiling.
> This results in only a small set of modules being enabled
> and linked statically.
> 
> For comparison, debian patches the fallback to enable
> dynamic modules (unconditionally).
> 
> This commit enables modules if shared libraries are enabled.

  While reviewing this, I noticed that there are many more things that zsh uses 
TRY_RUN for, so I'll send a patch with more cache variable overrides.

> 
> Signed-off-by: Norbert Lange <nolange79@gmail.com>
> 
> ---
> v1:
> -   so far only tested with glibc

  Perhaps we need a runtime test? I'm not actually worried about non-glibc 
libraries (though I would make the runtime test with uclibc). It would however 
be useful to have a runtime test that checks 32 and 64 bit targets - the patch 
that I'm sending is mainly about that. Currently it always assumes 32 bit (which 
I guess is mostly OK anyway).

  Regards,
  Arnout

> ---
>   package/zsh/zsh.mk | 8 ++++++++
>   1 file changed, 8 insertions(+)
> 
> diff --git a/package/zsh/zsh.mk b/package/zsh/zsh.mk
> index c5ab7c2fae..c26a00c430 100644
> --- a/package/zsh/zsh.mk
> +++ b/package/zsh/zsh.mk
> @@ -36,6 +36,14 @@ else
>   ZSH_CONF_OPTS += --disable-pcre
>   endif
>   
> +ifneq ($(BR2_STATIC_LIBS),y)
> +# zsh assumes shared libs to be not available when crosscompiling
> +ZSH_CONF_OPTS += zsh_cv_shared_environ=yes zsh_cv_shared_tgetent=yes \
> +	zsh_cv_shared_tigetstr=yes zsh_cv_sys_dynamic_clash_ok=yes \
> +	zsh_cv_sys_dynamic_rtld_global=yes zsh_cv_sys_dynamic_execsyms=yes \
> +	zsh_cv_sys_dynamic_strip_exe=yes zsh_cv_sys_dynamic_strip_lib=yes
> +endif
> +
>   # Add /bin/zsh to /etc/shells otherwise some login tools like dropbear
>   # can reject the user connection. See man shells.
>   define ZSH_ADD_ZSH_TO_SHELLS
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v3 7/7] package/zsh: enable static regex module

[Norbert Lange]

the builtin string =~ regexp operator needs to load the regex
module. This operator is readily used in zsh scripts,
so always enable it.

Signed-off-by: Norbert Lange <nolange79@gmail.com>
---
 package/zsh/zsh.mk | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/package/zsh/zsh.mk b/package/zsh/zsh.mk
index c26a00c430..85c214372a 100644
--- a/package/zsh/zsh.mk
+++ b/package/zsh/zsh.mk
@@ -44,6 +44,12 @@ ZSH_CONF_OPTS += zsh_cv_shared_environ=yes zsh_cv_shared_tgetent=yes \
 	zsh_cv_sys_dynamic_strip_exe=yes zsh_cv_sys_dynamic_strip_lib=yes
 endif
 
+# regex is commonly used by completion scripts, link it statically
+define ZSH_USE_STATIC_REGEX_MODULE
+	$(SED) 's,echo dynamic,echo static,' $(@D)/Src/Modules/regex.mdd
+endef
+ZSH_POST_PATCH_HOOKS += ZSH_USE_STATIC_REGEX_MODULE
+
 # Add /bin/zsh to /etc/shells otherwise some login tools like dropbear
 # can reject the user connection. See man shells.
 define ZSH_ADD_ZSH_TO_SHELLS
-- 
2.34.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v3 7/7] package/zsh: enable static regex module

[Arnout Vandecappelle]

On 22/02/2022 11:22, Norbert Lange wrote:
> the builtin string =~ regexp operator needs to load the regex
> module. This operator is readily used in zsh scripts,
> so always enable it.

  I wasn't so sure about this one - but then again, there's little reason to 
have any dynamic modules in a shell to begin with. I trust your judgement on that.


  Regards,
  Arnout


>
> Signed-off-by: Norbert Lange <nolange79@gmail.com>
> ---
>   package/zsh/zsh.mk | 6 ++++++
>   1 file changed, 6 insertions(+)
>
> diff --git a/package/zsh/zsh.mk b/package/zsh/zsh.mk
> index c26a00c430..85c214372a 100644
> --- a/package/zsh/zsh.mk
> +++ b/package/zsh/zsh.mk
> @@ -44,6 +44,12 @@ ZSH_CONF_OPTS += zsh_cv_shared_environ=yes zsh_cv_shared_tgetent=yes \
>   	zsh_cv_sys_dynamic_strip_exe=yes zsh_cv_sys_dynamic_strip_lib=yes
>   endif
>   
> +# regex is commonly used by completion scripts, link it statically
> +define ZSH_USE_STATIC_REGEX_MODULE
> +	$(SED) 's,echo dynamic,echo static,' $(@D)/Src/Modules/regex.mdd
> +endef
> +ZSH_POST_PATCH_HOOKS += ZSH_USE_STATIC_REGEX_MODULE
> +
>   # Add /bin/zsh to /etc/shells otherwise some login tools like dropbear
>   # can reject the user connection. See man shells.
>   define ZSH_ADD_ZSH_TO_SHELLS
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] Patch series

[Arnout Vandecappelle]

On 22/02/2022 11:22, Norbert Lange wrote:
> As is was suggested I pulled my patches in a series,
> this should combine most of my open work.
> 
> It does *not* contain:
> 
> -   toolchain: support mismatched merged usr [1]
>      recent enough
> 
> -   package/dbus-broker: new package [2]
>      recent enough
> 
> -   package/openssh: improve integration for systemd [3]
>      outdated, no time to fix it
> 
> 
> Patch 1 and 2 set the runstatedir for CMake and Autotools (new patches)
> 
> Patch 3 and 4 are rebased and adopted to feedback.
> 
> Patch 5 contains a better commit message
> 
> Patch 6 and 7 are new
> 
> 
> [PATCH v3 1/7] package/pkg-cmake.mk: use /run as runtime path
> [PATCH v3 2/7] pkg-autotools: optimistically set runstatedir
> [PATCH v3 3/7] package/systemd: use current tool for generating HWDB
> [PATCH v3 4/7] package/systemd: remove hwdb-update service
> [PATCH v3 5/7] Makefile: remove /usr/lib/rpm directory on target
> [PATCH v3 6/7] package/zsh: Enable dynamic modules
> [PATCH v3 7/7] package/zsh: enable static regex module

  Series applied to master, thanks.

  I updated the commit messages in almost all of them. They were already pretty 
good, but writing it down myself helps in understanding everything.

  I have a few more comments in individual patches.

  Regards,
  Arnout


> 
> [1] - https://lists.buildroot.org/pipermail/buildroot/2022-February/637079.html
> [2] - https://patchwork.ozlabs.org/project/buildroot/patch/20220109221650.777610-1-nolange79@gmail.com/
> [3] - https://patchwork.ozlabs.org/project/buildroot/patch/20200611091407.12688-2-nolange79@gmail.com/
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] Patch series

[Norbert Lange]

Am Do., 28. Juli 2022 um 21:05 Uhr schrieb Arnout Vandecappelle
<arnout@mind.be>:
>
>
>
> On 22/02/2022 11:22, Norbert Lange wrote:
> > As is was suggested I pulled my patches in a series,
> > this should combine most of my open work.
> >
> > It does *not* contain:
> >
> > -   toolchain: support mismatched merged usr [1]
> >      recent enough
> >
> > -   package/dbus-broker: new package [2]
> >      recent enough
> >
> > -   package/openssh: improve integration for systemd [3]
> >      outdated, no time to fix it
> >
> >
> > Patch 1 and 2 set the runstatedir for CMake and Autotools (new patches)
> >
> > Patch 3 and 4 are rebased and adopted to feedback.
> >
> > Patch 5 contains a better commit message
> >
> > Patch 6 and 7 are new
> >
> >
> > [PATCH v3 1/7] package/pkg-cmake.mk: use /run as runtime path
> > [PATCH v3 2/7] pkg-autotools: optimistically set runstatedir
> > [PATCH v3 3/7] package/systemd: use current tool for generating HWDB
> > [PATCH v3 4/7] package/systemd: remove hwdb-update service
> > [PATCH v3 5/7] Makefile: remove /usr/lib/rpm directory on target
> > [PATCH v3 6/7] package/zsh: Enable dynamic modules
> > [PATCH v3 7/7] package/zsh: enable static regex module
>
>   Series applied to master, thanks.
>
>   I updated the commit messages in almost all of them. They were already pretty
> good, but writing it down myself helps in understanding everything.
>
>   I have a few more comments in individual patches.
>
>   Regards,
>   Arnout
>
>
> >
> > [1] - https://lists.buildroot.org/pipermail/buildroot/2022-February/637079.html
> > [2] - https://patchwork.ozlabs.org/project/buildroot/patch/20220109221650.777610-1-nolange79@gmail.com/
> > [3] - https://patchwork.ozlabs.org/project/buildroot/patch/20200611091407.12688-2-nolange79@gmail.com/
> >
> > _______________________________________________
> > buildroot mailing list
> > buildroot@buildroot.org
> > https://lists.buildroot.org/mailman/listinfo/buildroot

Thanks, closer to the day i can just use upstream BR ;)

Norbert
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot