Patch series
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/[email protected]/
[3] - https://patchwork.ozlabs.org/project/buildroot/patch/[email protected]/
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH v3 1/7 package/pkg-cmake.mk: use /run as runtime path
Buildroot prefers /run as runstate directory, make this the default.
--- package/pkg-cmake.mk | 1 + 1 file changed, 1 insertion(+)
package/pkg-cmake.mk +1 -0
@@ -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 \
Signature · 6 lines
2.34.1 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH v3 2/7 pkg-autotools: optimistically set runstatedir
In reply to Norbert Langesince 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.
--- package/pkg-autotools.mk | 1 + 1 file changed, 1 insertion(+)
package/pkg-autotools.mk +1 -0
@@ -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 \
Signature · 6 lines
2.34.1 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Re: [Buildroot] [PATCH v3 2/7] pkg-autotools: optimistically set runstatedir
Norbert, All,
On 2022-02-22 11:22 +0100, Norbert Lange spake thusly:
Quoted 15 lines
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 <[email protected]>--- package/pkg-autotools.mk | 1 + 1 file changed, 1 insertion(+)package/pkg-autotools.mk +0
-0
package/pkg-autotools.mk define $(2)_CONFIGURE_CMDS · line 190
Quoted 4 lines
package/pkg-autotools.mk +1
-0@@ -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.
Quoted 10 lines
package/pkg-autotools.mk +0
-0--program-prefix="" \ --disable-gtk-doc \ --disable-gtk-doc-html \Signature · 6 lines
2.34.1 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Signature · 10 lines
.-----------------.--------------------.------------------.--------------------. | 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 [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH v3 3/7 package/systemd: use current tool for generating HWDB
In reply to Norbert Langeudevadm 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
---
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(-)
package/systemd/systemd.mk +7 -6
@@ -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 \
Signature · 6 lines
2.34.1 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Re: [Buildroot] [PATCH v3 3/7] package/systemd: use current tool for generating HWDB
Quoted 6 lines · 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.
This is one thing.
Quoted 4 lines
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
Quoted 47 lines
Signed-off-by Norbert Lange <[email protected]>---
v1 -> v2
- fix removal of service
v2 -> v3(quoted diff) +0
-6- 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(-)package/systemd/systemd.mk +6
-5@@ -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 \
package/systemd/systemd.mk HOST_SYSTEMD_CONF_OPTS = \ · line 821
Quoted 8 lines
package/systemd/systemd.mk +1
-1@@ -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
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH v3 4/7 package/systemd: remove hwdb-update service
In reply to Norbert Langesince 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.
--- package/systemd/systemd.mk | 6 ++++++ 1 file changed, 6 insertions(+)
package/systemd/systemd.mk +6 -0
@@ -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
Signature · 6 lines
2.34.1 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH v3 5/7 Makefile: remove /usr/lib/rpm directory on target
In reply to Norbert Langethis 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.
---
v1 -> v2
- see https://lists.buildroot.org/pipermail/buildroot/2020-June/284213.html
- improved commit message
--- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Makefile +1 -1
@@ -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
Signature · 6 lines
2.34.1 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH v3 6/7 package/zsh: Enable dynamic modules
In reply to Norbert LangeThe 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.
---
v1:
- so far only tested with glibc
--- package/zsh/zsh.mk | 8 ++++++++ 1 file changed, 8 insertions(+)
package/zsh/zsh.mk +8 -0
@@ -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
Signature · 6 lines
2.34.1 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Re: [Buildroot] [PATCH v3 6/7] package/zsh: Enable dynamic modules
Quoted 9 lines · 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.
While reviewing this, I noticed that there are many more things that zsh usesTRY_RUN for, so I'll send a patch with more cache variable overrides.
Quoted 6 lines
Signed-off-by Norbert Lange <[email protected]>---
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
Quoted 13 lines
--- package/zsh/zsh.mk | 8 ++++++++ 1 file changed, 8 insertions(+)package/zsh/zsh.mk +1
-0@@ -36,6 +36,14 @@ else ZSH_CONF_OPTS += --disable-pcre endif +ifneq ($(BR2_STATIC_LIBS),y)
package/zsh/zsh.mk else · line 49
Quoted 10 lines
package/zsh/zsh.mk +7
-0+# 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
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH v3 7/7 package/zsh: enable static regex module
In reply to Norbert Langethe builtin string =~ regexp operator needs to load the regex module. This operator is readily used in zsh scripts, so always enable it.
--- package/zsh/zsh.mk | 6 ++++++ 1 file changed, 6 insertions(+)
package/zsh/zsh.mk +6 -0
@@ -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
Signature · 6 lines
2.34.1 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Re: [Buildroot] [PATCH v3 7/7] package/zsh: enable static regex module
Quoted 3 lines · 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.
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
Quoted 13 lines
Signed-off-by Norbert Lange <[email protected]>--- package/zsh/zsh.mk | 6 ++++++ 1 file changed, 6 insertions(+)package/zsh/zsh.mk +0
-0@@ -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
package/zsh/zsh.mk ZSH_CONF_OPTS += zsh_cv_shared_environ=yes zsh_cv_shared_tgetent=yes \ · line 55
Quoted 10 lines
package/zsh/zsh.mk +6
-0+# 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
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot
Quoted 24 lines · 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:
(quoted diff) +0
-3- 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 itPatch 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
Quoted 7 lines
[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/rpmdirectory 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
Quoted 9 lines
[1] - https://lists.buildroot.org/pipermail/buildroot/2022-February/637079.html
[2] - https://patchwork.ozlabs.org/project/buildroot/patch/[email protected]/
[3] - https://patchwork.ozlabs.org/project/buildroot/patch/[email protected]/_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot
Am Do., 28. Juli 2022 um 21:05 Uhr schrieb Arnout Vandecappelle <[email protected]>:
Quoted 38 lines · Norbert Lange
Quoted 24 lines
As is was suggested I pulled my patches in a series, this should combine most of my open work.
It does *not* contain:
(quoted diff) +0
-3- 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 itPatch 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
Quoted 7 lines
[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/rpmdirectory on target [PATCH v3 6/7] package/zsh: Enable dynamic modules
[PATCH v3 7/7] package/zsh: enable static regex moduleSeries applied to master, thanks.
Quoted 18 lines
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,
ArnoutQuoted 9 lines
[1] - https://lists.buildroot.org/pipermail/buildroot/2022-February/637079.html
[2] - https://patchwork.ozlabs.org/project/buildroot/patch/[email protected]/
[3] - https://patchwork.ozlabs.org/project/buildroot/patch/[email protected]/_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot
Thanks, closer to the day i can just use upstream BR ;)
Norbert
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot