[ptxdist] [PATCH] vim: allow vim to be installed alongside busybox vi and xxd
Commit ad2eb34a07ed ("vim: prevent file name conflicts with busybox")
prevented vim being selected if busybox vi is selected. However, the vim
package does not currently install /usr/bin/vi, so the only conflict is
between vim's xxd and busybox's xxd.
Allow vim to be installed alongside busybox vi. Also add a configuration
option to allow installation of a /usr/bin/vi symbolic link to
/usr/bin/vim, but only allow it to be selected if busybox vi is not
selected.
Move the auto-selections of LIBC_DL, LIBC_M, GCCLIBS_GCC_S, and NCURSES
from VIM to VIM_VIM because VIM_XXD does not appear to require them.
Signed-off-by: Ian Abbott
---
rules/vim.in | 24
rules/vim.make | 4
2 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/rules/vim.in b/rules/vim.in
index c4c9d14e6..2f7eba993 100644
--- a/rules/vim.in
+++ b/rules/vim.in
@@ -1,15 +1,7 @@
## SECTION=editors
-comment "BusyBox' vi and xxd is selected!"
- depends on BUSYBOX_VI && BUSYBOX_XXD
-
menuconfig VIM
tristate
- depends on !(BUSYBOX_VI && BUSYBOX_XXD)
- select LIBC_DL
- select LIBC_M
- select GCCLIBS_GCC_S
- select NCURSES
prompt "vim "
help
Vim is an advanced text editor that seeks to provide the
@@ -18,12 +10,20 @@ menuconfig VIM
if VIM
-comment "BusyBox' vi is selected!"
- depends on BUSYBOX_VI
-
config VIM_VIM
- depends on !BUSYBOX_VI
bool "Vim Editor"
+ select LIBC_DL
+ select LIBC_M
+ select GCCLIBS_GCC_S
+ select NCURSES
+
+comment "BusyBox' vi is selected!"
+ depends on VIM_VIM && BUSYBOX_VI
+
+config VIM_VI_SYMLINK
+ depends on VIM_VIM && !BUSYBOX_VI
+ bool "install symbolic link /usr/bin/vi"
+ default y
comment "BusyBox' xxd is selected!"
depends on BUSYBOX_XXD
diff --git a/rules/vim.make b/rules/vim.make
index b03778e53..8700b70bd 100644
--- a/rules/vim.make
+++ b/rules/vim.make
@@ -103,6 +103,10 @@ VIM_INSTALL_OPT := \
VIM_LINKS := ex rview rvim view vimdiff
+ifdef PTXCONF_VIM_VI_SYMLINK
+VIM_LINKS += vi
+endif
+
$(STATEDIR)/vim.targetinstall:
@$(call targetinfo)
--
2.43.0
Re: [ptxdist] [PATCH 2/2] beep: version bump 1.3 -> 1.4.12
On Thu, May 02, 2024 at 11:38:14AM +0200, Michael Olbrich wrote: > On Wed, Apr 24, 2024 at 05:33:22PM +0200, Ladislav Michl wrote: > > On Tue, Apr 23, 2024 at 07:36:52AM +0200, Ladislav Michl wrote: > > > Move package to a new upstream at https://github.com/spkr-beep/beep/ > > > > For v5te I needed to add LDFLAGS=-latomic to satisfy undefined reference: > > arm-v5te-linux-gnueabi-gcc -Wl,-Map=beep.map,--cref > > -fasynchronous-unwind-tables -fanalyzer -fstack-protector-strong > > -fstack-clash-protection -fsanitize=undefined -save-temps=obj -O2 -g > > -std=gnu99 -pedantic -Wall -Wextra -Werror -Wno-padded > > -Wno-format-nonliteral -o beep beep-log.o beep-main.o beep-library.o > > beep-usage.o beep-drivers.o beep-driver-console.o beep-driver-evdev.o > > /opt/OSELAS.Toolchain-2023.07.1/arm-v5te-linux-gnueabi/gcc-13.2.1-glibc-2.37-binutils-2.40-kernel-6.3.6-sanitized/lib/gcc/arm-v5te-linux-gnueabi/13.2.1/../../../../arm-v5te-linux-gnueabi/bin/ld: > > > > /opt/OSELAS.Toolchain-2023.07.1/arm-v5te-linux-gnueabi/gcc-13.2.1-glibc-2.37-binutils-2.40-kernel-6.3.6-sanitized/lib/gcc/arm-v5te-linux-gnueabi/13.2.1/../../../../arm-v5te-linux-gnueabi/lib/libubsan.so: > > undefined reference to `__atomic_compare_exchange_8' > > /opt/OSELAS.Toolchain-2023.07.1/arm-v5te-linux-gnueabi/gcc-13.2.1-glibc-2.37-binutils-2.40-kernel-6.3.6-sanitized/lib/gcc/arm-v5te-linux-gnueabi/13.2.1/../../../../arm-v5te-linux-gnueabi/bin/ld: > > > > /opt/OSELAS.Toolchain-2023.07.1/arm-v5te-linux-gnueabi/gcc-13.2.1-glibc-2.37-binutils-2.40-kernel-6.3.6-sanitized/lib/gcc/arm-v5te-linux-gnueabi/13.2.1/../../../../arm-v5te-linux-gnueabi/lib/libubsan.so: > > undefined reference to `__atomic_load_8' > > collect2: error: ld returned 1 exit status > > > > I can see haproxy and dhcp packages are adding target flags based on > > selected architecture. Is it to way to follow here? > > Yes, please handle it like that. If it's missing for other architectures > (ppc is a possibility here), I'll fix it when it fails in my tests. I already sent v2 with different approach. Problems boils down to beep's GNUMakefile trying to figure out whenever compiler supports various sanitizers flags, but fails to figure out, that it comes at price linking with sanitizer libraries on some architectures. V2 solves that by removing all those checks, so external libraries are no longer needed. ladis
Re: [ptxdist] [PATCH v6 3/5] scripts: add helper to inject files into a source directory
On Fri, Apr 19, 2024 at 11:48:51AM +0200, Alexander Dahl wrote: > sorry for digging up this old discussion, but I kind of want to use this > approach and … see below. > > Am Samstag, 29. Januar 2022, 08:03:28 CEST schrieb Michael Riesch: > > Some packages may require certain files that are maintained > > or generated outside of their source repository. For example, > > binary firmware blobs could be excluded from the sources due > > to licensing issues. Add a helper that allows to inject certain > > files into the source directory (usually in the prepare stage). > > Currently trying to build recent U-Boot for i.MX8 and i.MX9 based boards > which > require additional firmware. However I still want to build OOT to keep my > source tree clean, especially when building with an external tree (after > `ptxdist local-src u-boot $HOME/src/u-boot`). > > Now U-Boot needs those binaries in the build tree, it does not work using > this > nice inject mechanism putting it in the source tree. > > > > > Signed-off-by: Michael Riesch > > --- > > > > Notes: > > v6: > > - replaced 'break' with 'return' > > > > rules/post/ptxd_make_world_inject.make | 19 > > scripts/lib/ptxd_make_world_inject.sh | 42 ++ > > 2 files changed, 61 insertions(+) > > create mode 100644 rules/post/ptxd_make_world_inject.make > > create mode 100644 scripts/lib/ptxd_make_world_inject.sh > > > > diff --git a/rules/post/ptxd_make_world_inject.make > > b/rules/post/ptxd_make_world_inject.make new file mode 100644 > > index 0..b7d28e92f > > --- /dev/null > > +++ b/rules/post/ptxd_make_world_inject.make > > @@ -0,0 +1,19 @@ > > +# -*-makefile-*- > > +# > > +# Copyright (C) 2021 by Michael Riesch > > +# > > +# For further information about the PTXdist project and license conditions > > +# see the README file. > > +# > > + > > +world/inject/env = \ > > + $(call world/env, $(1)) \ > > + pkg_inject_path="$($(1)_INJECT_PATH)" \ > > + pkg_inject_files="$($(1)_INJECT_FILES)" \ > > + pkg_source="$($(1)_DIR)" > > Here _DIR is assigned to pkg_source which makes the source dir the > target > folder. > > Did anyone already think of how to extend this approach to be more flexible > for the target folder? Maybe even without damaging existing use cases? > > Maybe adding a new optional variable _INJECT_DEST which defaults to > _DIR and can be overridden? Makes sense to me. I would have named it _INJECT_DIR but either is fine with me. And if it's empty, set it to pkg_dir in ptxd_make_world_inject() Regards, Michael -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [ptxdist] [PATCH 2/2] beep: version bump 1.3 -> 1.4.12
On Wed, Apr 24, 2024 at 05:33:22PM +0200, Ladislav Michl wrote: > On Tue, Apr 23, 2024 at 07:36:52AM +0200, Ladislav Michl wrote: > > Move package to a new upstream at https://github.com/spkr-beep/beep/ > > For v5te I needed to add LDFLAGS=-latomic to satisfy undefined reference: > arm-v5te-linux-gnueabi-gcc -Wl,-Map=beep.map,--cref > -fasynchronous-unwind-tables -fanalyzer -fstack-protector-strong > -fstack-clash-protection -fsanitize=undefined -save-temps=obj -O2 -g > -std=gnu99 -pedantic -Wall -Wextra -Werror -Wno-padded -Wno-format-nonliteral > -o beep beep-log.o beep-main.o beep-library.o beep-usage.o beep-drivers.o > beep-driver-console.o beep-driver-evdev.o > /opt/OSELAS.Toolchain-2023.07.1/arm-v5te-linux-gnueabi/gcc-13.2.1-glibc-2.37-binutils-2.40-kernel-6.3.6-sanitized/lib/gcc/arm-v5te-linux-gnueabi/13.2.1/../../../../arm-v5te-linux-gnueabi/bin/ld: > > /opt/OSELAS.Toolchain-2023.07.1/arm-v5te-linux-gnueabi/gcc-13.2.1-glibc-2.37-binutils-2.40-kernel-6.3.6-sanitized/lib/gcc/arm-v5te-linux-gnueabi/13.2.1/../../../../arm-v5te-linux-gnueabi/lib/libubsan.so: > undefined reference to `__atomic_compare_exchange_8' > /opt/OSELAS.Toolchain-2023.07.1/arm-v5te-linux-gnueabi/gcc-13.2.1-glibc-2.37-binutils-2.40-kernel-6.3.6-sanitized/lib/gcc/arm-v5te-linux-gnueabi/13.2.1/../../../../arm-v5te-linux-gnueabi/bin/ld: > > /opt/OSELAS.Toolchain-2023.07.1/arm-v5te-linux-gnueabi/gcc-13.2.1-glibc-2.37-binutils-2.40-kernel-6.3.6-sanitized/lib/gcc/arm-v5te-linux-gnueabi/13.2.1/../../../../arm-v5te-linux-gnueabi/lib/libubsan.so: > undefined reference to `__atomic_load_8' > collect2: error: ld returned 1 exit status > > I can see haproxy and dhcp packages are adding target flags based on > selected architecture. Is it to way to follow here? Yes, please handle it like that. If it's missing for other architectures (ppc is a possibility here), I'll fix it when it fails in my tests. Regards, Michael -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
