| Message ID | 20230107074945.2140362-6-computersforpeace@gmail.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Petr Štetiar |
| Headers | show |
| Series | None | expand |
On Fri, Jan 06, 2023 at 11:49:44PM -0800, Brian Norris wrote: > I need to express a per-target dependency on the 'base64' utility, and > that's seemingly impossible to do for busybox. Pull in coreutils to make > that easier. > > Signed-off-by: Brian Norris <computersforpeace@gmail.com> We still need to think of a correct solution for this... coreutils is an option but wonder if a better one is openssl... Actually we have a small tool to handle specific decryption of some stuff... Wonder if that can be expanded for this task and just use wolfssl or openssl api to decode base64 stuff? Would love some feedback about this from others since it's not so trivial. > --- > * New in v2 > > > (no changes since v1) > > package/utils/coreutils/Makefile | 153 ++++++++++++++++++ > .../patches/001-no_docs_man_tests.patch | 93 +++++++++++ > 2 files changed, 246 insertions(+) > create mode 100644 package/utils/coreutils/Makefile > create mode 100644 package/utils/coreutils/patches/001-no_docs_man_tests.patch > > diff --git a/package/utils/coreutils/Makefile b/package/utils/coreutils/Makefile > new file mode 100644 > index 000000000000..d1af3ce962f1 > --- /dev/null > +++ b/package/utils/coreutils/Makefile > @@ -0,0 +1,153 @@ > +# > +# Copyright (C) 2008-2014 OpenWrt.org > +# > +# This is free software, licensed under the GNU General Public License v2. > +# See /LICENSE for more information. > +# > + > +include $(TOPDIR)/rules.mk > + > +PKG_NAME:=coreutils > +PKG_VERSION:=9.1 > +PKG_RELEASE:=1 > + > +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz > +PKG_SOURCE_URL:=@GNU/coreutils > +PKG_HASH:=61a1f410d78ba7e7f37a5a4f50e6d1320aca33375484a3255eddf17a38580423 > + > +PKG_MAINTAINER:=Jo-Philipp Wich <jo@mein.io> > +PKG_LICENSE:=GPL-3.0-or-later > +PKG_LICENSE_FILES:=COPYING > +PKG_CPE_ID:=cpe:/a:gnu:coreutils > + > +PKG_INSTALL:=1 > +PKG_BUILD_PARALLEL:=1 > + > +include $(INCLUDE_DIR)/package.mk > + > +COREUTILS_APPLETS := \ > + base32 base64 basename basenc b2sum cat chcon chgrp chmod chown chroot \ > + cksum comm cp csplit cut date dd df dir dircolors dirname du echo env \ > + expand expr factor false fmt fold groups head hostid id install join \ > + kill link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl \ > + nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd \ > + readlink realpath rm rmdir runcon seq sha1sum sha224sum sha256sum \ > + sha384sum sha512sum shred shuf sleep sort split stat stdbuf stty sum \ > + sync tac tail tee test timeout touch tr true truncate tsort tty uname \ > + unexpand uniq unlink uptime users vdir wc who whoami yes > + > +DIR_BIN := \ > + base64 cat chgrp chmod chown cp date dd df echo false kill link ln ls \ > + mkdir mknod mktemp mv nice printenv pwd rm rmdir sleep stat stty sync \ > + touch true uname > + > +DIR_USR_BIN := \ > + basename chcon cksum comm cut dirname du env expand expr factor fold \ > + groups head hostid id install logname md5sum mkfifo nl nohup nproc od \ > + paste printf readlink realpath runcon seq sha1sum sha256sum sha512sum \ > + shred shuf sort split sum tac tail tee test timeout tr truncate tty \ > + unexpand uniq unlink uptime users wc who whoami yes > + > +DIR_USR_SBIN := \ > + chroot > + > +# BusyBox does not provide these yet > +DIR_OTHERS := \ > + base32 b2sum basenc csplit dir dircolors fmt join numfmt pathchk pinky \ > + pr ptx sha224sum sha384sum stdbuf tsort vdir > + > +$(eval $(foreach a,$(DIR_BIN),ALTS_$(a):=300:/bin/$(a):/usr/libexec/$(a)-coreutils$(newline))) > +$(eval $(foreach a,$(DIR_USR_BIN),ALTS_$(a):=300:/usr/bin/$(a):/usr/libexec/$(a)-coreutils$(newline))) > +$(eval $(foreach a,$(DIR_USR_SBIN),ALTS_$(a):=300:/usr/sbin/$(a):/usr/libexec/$(a)-coreutils$(newline))) > + > +DEPENDS_sort = +libpthread > +DEPENDS_timeout = +librt > +DEPENDS_expr = +libgmp > +DEPENDS_factor = +libgmp > +DEPENDS_cp = +libacl > +DEPENDS_dir = +libacl +libcap > +DEPENDS_install = +libacl > +DEPENDS_ls = +libacl +libcap > +DEPENDS_mv = +libacl > +DEPENDS_vdir = +libacl +libcap > + > +FILES_stdbuf := usr/lib/coreutils/libstdbuf.so > + > +define Package/coreutils/Default > + SECTION:=utils > + CATEGORY:=Utilities > + TITLE:=The GNU core utilities > + URL:=http://www.gnu.org/software/coreutils/ > +endef > + > +define Package/coreutils > + $(call Package/coreutils/Default) > + TITLE:=The GNU core utilities > + MENU:=1 > +endef > + > +define Package/coreutils/description > + Full versions of standard GNU utilities. If an equivalent Busybox applet is > + available, you should consider compiling that instead as Busybox applets are > + usually smaller, at the expense of reduced functionality. > +endef > + > +define GenPlugin > + define Package/$(1) > + $(call Package/coreutils/Default) > + DEPENDS:=coreutils $(DEPENDS_$(2)) > + TITLE:=Utility $(2) from the GNU core utilities > + ALTERNATIVES:=$(ALTS_$(2)) > + endef > + > + define Package/$(1)/description > + Full version of standard GNU $(2) utility. > + endef > +endef > + > +$(foreach a,$(COREUTILS_APPLETS),$(eval $(call GenPlugin,coreutils-$(a),$(a)))) > + > +CONFIGURE_VARS += \ > + gl_cv_func_mbrtowc_incomplete_state=yes \ > + gl_cv_func_mbrtowc_retval=yes \ > + gl_cv_func_wcrtomb_retval=yes \ > + ac_cv_header_selinux_context_h=no \ > + ac_cv_header_selinux_flash_h=no \ > + ac_cv_header_selinux_selinux_h=no \ > + ac_cv_search_setfilecon=no > + > +CONFIGURE_ARGS += \ > + --disable-xattr \ > + --enable-install-program=su \ > + --enable-threads=posix \ > + --enable-acl \ > + --disable-assert \ > + --disable-rpath \ > + --disable-libsmack \ > + --enable-libcap \ > + --without-linux-crypto \ > + --without-openssl \ > + --$(if $(CONFIG_USE_MUSL),with,without)-included-regex \ > + --without-selinux \ > + --with-gmp > + > +define Package/coreutils/install > + true > +endef > + > +define BuildPlugin > + define Package/$(1)/install > + $(INSTALL_DIR) $$(1)/usr/$(if $(ALTS_$(2)),libexec,bin) > + $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/$(2) $$(1)/usr/$(if $(ALTS_$(2)),libexec/$(2)-coreutils,bin/$(2)) > + $(foreach f,$(FILES_$(2)), > + $(INSTALL_DIR) $$(1)/$(dir $(f)) > + $(INSTALL_BIN) $(PKG_INSTALL_DIR)/$(f) $$(1)/$(f) > + ) > + endef > + > + $$(eval $$(call BuildPackage,$(1))) > +endef > + > +$(eval $(call BuildPackage,coreutils)) > + > +$(foreach a,$(COREUTILS_APPLETS),$(eval $(call BuildPlugin,coreutils-$(a),$(a)))) > diff --git a/package/utils/coreutils/patches/001-no_docs_man_tests.patch b/package/utils/coreutils/patches/001-no_docs_man_tests.patch > new file mode 100644 > index 000000000000..e4feaf5cd9a4 > --- /dev/null > +++ b/package/utils/coreutils/patches/001-no_docs_man_tests.patch > @@ -0,0 +1,93 @@ > +--- a/Makefile.am > ++++ b/Makefile.am > +@@ -17,7 +17,7 @@ > + > + ALL_RECURSIVE_TARGETS = > + > +-SUBDIRS = po . gnulib-tests > ++SUBDIRS = po > + > + EXTRA_DIST = \ > + .mailmap \ > +@@ -210,6 +210,3 @@ AM_CPPFLAGS = -Ilib -I$(top_srcdir)/lib > + > + include $(top_srcdir)/lib/local.mk > + include $(top_srcdir)/src/local.mk > +-include $(top_srcdir)/doc/local.mk > +-include $(top_srcdir)/man/local.mk > +-include $(top_srcdir)/tests/local.mk > +--- a/Makefile.in > ++++ b/Makefile.in > +@@ -4115,11 +4115,7 @@ RECURSIVE_TARGETS = all-recursive check- > + install-ps-recursive install-recursive installcheck-recursive \ > + installdirs-recursive pdf-recursive ps-recursive \ > + tags-recursive uninstall-recursive > +-am__can_run_installinfo = \ > +- case $$AM_UPDATE_INFO_DIR in \ > +- n|no|NO) false;; \ > +- *) (install-info --version) >/dev/null 2>&1;; \ > +- esac > ++am__can_run_installinfo = false > + am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`; > + am__vpath_adj = case $$p in \ > + $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \ > +@@ -4369,10 +4365,10 @@ am__DIST_COMMON = $(doc_coreutils_TEXINF > + $(top_srcdir)/build-aux/missing \ > + $(top_srcdir)/build-aux/test-driver \ > + $(top_srcdir)/build-aux/texinfo.tex \ > +- $(top_srcdir)/build-aux/ylwrap $(top_srcdir)/doc/local.mk \ > +- $(top_srcdir)/lib/alloca.c $(top_srcdir)/lib/config.hin \ > +- $(top_srcdir)/lib/local.mk $(top_srcdir)/man/local.mk \ > +- $(top_srcdir)/src/local.mk $(top_srcdir)/src/single-binary.mk \ > ++ $(top_srcdir)/build-aux/ylwrap \ > ++ $(top_srcdir)/lib/alloca.c \ > ++ $(top_srcdir)/lib/local.mk \ > ++ $(top_srcdir)/src/local.mk \ > + $(top_srcdir)/tests/local.mk ABOUT-NLS AUTHORS COPYING \ > + ChangeLog INSTALL NEWS README THANKS TODO build-aux/compile \ > + build-aux/config.guess build-aux/config.rpath \ > +@@ -4479,7 +4475,7 @@ EOVERFLOW_VALUE = @EOVERFLOW_VALUE@ > + ERRNO_H = @ERRNO_H@ > + ETAGS = @ETAGS@ > + EXEEXT = @EXEEXT@ > +-EXTRA_MANS = @EXTRA_MANS@ > ++EXTRA_MANS = > + FLOAT_H = @FLOAT_H@ > + FNMATCH_H = @FNMATCH_H@ > + GETADDRINFO_LIB = @GETADDRINFO_LIB@ > +@@ -6057,7 +6053,7 @@ libexecdir = @libexecdir@ > + lispdir = @lispdir@ > + localedir = @localedir@ > + localstatedir = @localstatedir@ > +-man1_MANS = @man1_MANS@ > ++man1_MANS = > + mandir = @mandir@ > + mkdir_p = @mkdir_p@ > + oldincludedir = @oldincludedir@ > +@@ -6080,7 +6076,7 @@ top_build_prefix = @top_build_prefix@ > + top_builddir = @top_builddir@ > + top_srcdir = @top_srcdir@ > + ALL_RECURSIVE_TARGETS = distcheck-hook check-root > +-SUBDIRS = po . gnulib-tests > ++SUBDIRS = po > + > + #if GNU_MAKE > + # [nicer features that work only with GNU Make] > +@@ -8272,7 +8268,7 @@ all: $(BUILT_SOURCES) > + .SUFFIXES: .1 .c .dvi .log .o .obj .pl .pl$(EXEEXT) .ps .sh .sh$(EXEEXT) .trs .x .xpl .xpl$(EXEEXT) .y > + am--refresh: Makefile > + @: > +-$(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(top_srcdir)/lib/local.mk $(srcdir)/lib/gnulib.mk $(top_srcdir)/src/local.mk $(srcdir)/src/cu-progs.mk $(top_srcdir)/src/single-binary.mk $(top_srcdir)/doc/local.mk $(top_srcdir)/man/local.mk $(top_srcdir)/tests/local.mk $(am__configure_deps) > ++$(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(top_srcdir)/lib/local.mk $(srcdir)/lib/gnulib.mk $(top_srcdir)/src/local.mk $(srcdir)/src/cu-progs.mk $(top_srcdir)/src/single-binary.mk $(am__configure_deps) > + @for dep in $?; do \ > + case '$(am__configure_deps)' in \ > + *$$dep*) \ > +@@ -8294,7 +8290,7 @@ Makefile: $(srcdir)/Makefile.in $(top_bu > + echo ' cd $(top_builddir) && $(SHELL) ./config.status $@ $(am__maybe_remake_depfiles)'; \ > + cd $(top_builddir) && $(SHELL) ./config.status $@ $(am__maybe_remake_depfiles);; \ > + esac; > +-$(top_srcdir)/lib/local.mk $(srcdir)/lib/gnulib.mk $(top_srcdir)/src/local.mk $(srcdir)/src/cu-progs.mk $(top_srcdir)/src/single-binary.mk $(top_srcdir)/doc/local.mk $(top_srcdir)/man/local.mk $(top_srcdir)/tests/local.mk $(am__empty): > ++$(top_srcdir)/lib/local.mk $(srcdir)/lib/gnulib.mk $(top_srcdir)/src/local.mk $(srcdir)/src/cu-progs.mk $(top_srcdir)/src/single-binary.mk $(am__empty): > + > + $(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES) > + $(SHELL) ./config.status --recheck > -- > 2.39.0 > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> Le 7 janv. 2023 à 15:06, Christian Marangi <ansuelsmth@gmail.com> a écrit : > > On Fri, Jan 06, 2023 at 11:49:44PM -0800, Brian Norris wrote: >> I need to express a per-target dependency on the 'base64' utility, and >> that's seemingly impossible to do for busybox. Pull in coreutils to make >> that easier. >> >> Signed-off-by: Brian Norris <computersforpeace@gmail.com> > > We still need to think of a correct solution for this... coreutils is an > option but wonder if a better one is openssl... Actually we have a small > tool to handle specific decryption of some stuff... Wonder if that can > be expanded for this task and just use wolfssl or openssl api to decode > base64 stuff? Using one or the other would impose (i.e. (en)force) that SSL library on this particular target. Do we want this, especially considering the ongoing conversation about mbedTLS? Also pulling an entire SSL implementation just to decode base64 seems a tad overkill too. HTH
On Sat, 7 Jan 2023 at 16:26, Thibaut VARÈNE <varenet@zigoo.net> wrote: > > > > > Le 7 janv. 2023 à 15:06, Christian Marangi <ansuelsmth@gmail.com> a écrit : > > > > On Fri, Jan 06, 2023 at 11:49:44PM -0800, Brian Norris wrote: > >> I need to express a per-target dependency on the 'base64' utility, and > >> that's seemingly impossible to do for busybox. Pull in coreutils to make > >> that easier. > >> > >> Signed-off-by: Brian Norris <computersforpeace@gmail.com> > > > > We still need to think of a correct solution for this... coreutils is an > > option but wonder if a better one is openssl... Actually we have a small > > tool to handle specific decryption of some stuff... Wonder if that can > > be expanded for this task and just use wolfssl or openssl api to decode > > base64 stuff? > > Using one or the other would impose (i.e. (en)force) that SSL library on this particular target. Do we want this, especially considering the ongoing conversation about mbedTLS? > > Also pulling an entire SSL implementation just to decode base64 seems a tad overkill too. I agree on this one, forcing usage of OpenSSL isn't ideal, coreutils is a better option for sure. Regards, Robert > > HTH > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> Le 7 janv. 2023 à 22:41, Robert Marko <robimarko@gmail.com> a écrit : > > On Sat, 7 Jan 2023 at 16:26, Thibaut VARÈNE <varenet@zigoo.net> wrote: >> >> >> >>> Le 7 janv. 2023 à 15:06, Christian Marangi <ansuelsmth@gmail.com> a écrit : >>> >>> On Fri, Jan 06, 2023 at 11:49:44PM -0800, Brian Norris wrote: >>>> I need to express a per-target dependency on the 'base64' utility, and >>>> that's seemingly impossible to do for busybox. Pull in coreutils to make >>>> that easier. >>>> >>>> Signed-off-by: Brian Norris <computersforpeace@gmail.com> >>> >>> We still need to think of a correct solution for this... coreutils is an >>> option but wonder if a better one is openssl... Actually we have a small >>> tool to handle specific decryption of some stuff... Wonder if that can >>> be expanded for this task and just use wolfssl or openssl api to decode >>> base64 stuff? >> >> Using one or the other would impose (i.e. (en)force) that SSL library on this particular target. Do we want this, especially considering the ongoing conversation about mbedTLS? >> >> Also pulling an entire SSL implementation just to decode base64 seems a tad overkill too. > > I agree on this one, forcing usage of OpenSSL isn't ideal, coreutils > is a better option for sure. There might be an even easier/lighter way (short of enabling base64 in busybox), AWK to the rescue: https://github.com/shane-kerr/AWK-base64decode The code is clean and judging by the comment line 97, works with busybox awk. HTH T
On 08.01.2023 00:02, Thibaut wrote: > > >> Le 7 janv. 2023 à 22:41, Robert Marko <robimarko@gmail.com> a écrit : >> >> On Sat, 7 Jan 2023 at 16:26, Thibaut VARÈNE <varenet@zigoo.net> wrote: >>> >>> >>> >>>> Le 7 janv. 2023 à 15:06, Christian Marangi <ansuelsmth@gmail.com> a écrit : >>>> >>>> On Fri, Jan 06, 2023 at 11:49:44PM -0800, Brian Norris wrote: >>>>> I need to express a per-target dependency on the 'base64' utility, and >>>>> that's seemingly impossible to do for busybox. Pull in coreutils to make >>>>> that easier. >>>>> >>>>> Signed-off-by: Brian Norris <computersforpeace@gmail.com> >>>> >>>> We still need to think of a correct solution for this... coreutils is an >>>> option but wonder if a better one is openssl... Actually we have a small >>>> tool to handle specific decryption of some stuff... Wonder if that can >>>> be expanded for this task and just use wolfssl or openssl api to decode >>>> base64 stuff? >>> >>> Using one or the other would impose (i.e. (en)force) that SSL library on this particular target. Do we want this, especially considering the ongoing conversation about mbedTLS? >>> >>> Also pulling an entire SSL implementation just to decode base64 seems a tad overkill too. >> >> I agree on this one, forcing usage of OpenSSL isn't ideal, coreutils >> is a better option for sure. > > There might be an even easier/lighter way (short of enabling base64 in busybox), AWK to the rescue: > https://github.com/shane-kerr/AWK-base64decode > > The code is clean and judging by the comment line 97, works with busybox awk. how is luci doing base64 en/decoding? that should be available in default images. if it's using lua, that should be available in every image even without web-interface or? ..ede
Brian Norris <computersforpeace@gmail.com> [2023-01-06 23:49:44]: Hi Brian, > I need to express a per-target dependency on the 'base64' utility, and > that's seemingly impossible to do for busybox. --- a/target/linux/ipq806x/Makefile +++ b/target/linux/ipq806x/Makefile @@ -15,6 +15,11 @@ KERNEL_PATCHVER:=5.15 KERNELNAME:=zImage Image dtbs include $(INCLUDE_DIR)/target.mk + +DEPENDS:= \ + +@BUSYBOX_DEFAULT_BASE64 + Cheers, Petr
On Sun, Jan 08, 2023 at 09:00:58PM +0100, Petr Štetiar wrote: > Brian Norris <computersforpeace@gmail.com> [2023-01-06 23:49:44]: > > Hi Brian, > > > I need to express a per-target dependency on the 'base64' utility, and > > that's seemingly impossible to do for busybox. > > --- a/target/linux/ipq806x/Makefile > +++ b/target/linux/ipq806x/Makefile > @@ -15,6 +15,11 @@ KERNEL_PATCHVER:=5.15 > KERNELNAME:=zImage Image dtbs > > include $(INCLUDE_DIR)/target.mk > + > +DEPENDS:= \ > + +@BUSYBOX_DEFAULT_BASE64 > + > Is this already used for other target? Wonder if this special thing would cause some problem for packages of this target? Like discrepancy with stage2 and final image? Anyway this looks to be the best solution for the problem.
> Le 8 janv. 2023 à 21:53, Christian Marangi <ansuelsmth@gmail.com> a écrit : > > On Sun, Jan 08, 2023 at 09:00:58PM +0100, Petr Štetiar wrote: >> Brian Norris <computersforpeace@gmail.com> [2023-01-06 23:49:44]: >> >> Hi Brian, >> >>> I need to express a per-target dependency on the 'base64' utility, and >>> that's seemingly impossible to do for busybox. >> >> --- a/target/linux/ipq806x/Makefile >> +++ b/target/linux/ipq806x/Makefile >> @@ -15,6 +15,11 @@ KERNEL_PATCHVER:=5.15 >> KERNELNAME:=zImage Image dtbs >> >> include $(INCLUDE_DIR)/target.mk >> + >> +DEPENDS:= \ >> + +@BUSYBOX_DEFAULT_BASE64 >> + >> > > Is this already used for other target? Wonder if this special thing > would cause some problem for packages of this target? Like discrepancy > with stage2 and final image? AFAICT this isn’t used anywhere so far (at least according to a quick git grep). > Anyway this looks to be the best solution for the problem. I wonder if it’s such a good idea to have discrepancies in busybox features between targets? T
On Sun, Jan 8, 2023 at 1:37 PM Thibaut <hacks@slashdirt.org> wrote: > > Le 8 janv. 2023 à 21:53, Christian Marangi <ansuelsmth@gmail.com> a écrit : > > > > On Sun, Jan 08, 2023 at 09:00:58PM +0100, Petr Štetiar wrote: > >> Brian Norris <computersforpeace@gmail.com> [2023-01-06 23:49:44]: > >> > >> Hi Brian, > >> > >>> I need to express a per-target dependency on the 'base64' utility, and > >>> that's seemingly impossible to do for busybox. > >> > >> --- a/target/linux/ipq806x/Makefile > >> +++ b/target/linux/ipq806x/Makefile > >> @@ -15,6 +15,11 @@ KERNEL_PATCHVER:=5.15 > >> KERNELNAME:=zImage Image dtbs > >> > >> include $(INCLUDE_DIR)/target.mk > >> + > >> +DEPENDS:= \ > >> + +@BUSYBOX_DEFAULT_BASE64 > >> + Thanks! That does indeed work for me. And I might just throw it into target/linux/ipq806x/chromium/target.mk instead, since the generic target won't be using base64. > > Is this already used for other target? Wonder if this special thing > > would cause some problem for packages of this target? Like discrepancy > > with stage2 and final image? stage2 as in sysupgrade? I don't immediately see how that would be a problem, but maybe I'm not understanding well enough. > AFAICT this isn’t used anywhere so far (at least according to a quick git grep). Right, I couldn't find any other target tweaking BUSYBOX_DEFAULT_* in the current tree or in the git history. And I can't even find anyone doing a bare 'DEPENDS:=' in their Makefile under target/linux/ at all. All usages are as part of packages (modules), not device/target specifications. > > Anyway this looks to be the best solution for the problem. > > I wonder if it’s such a good idea to have discrepancies in busybox features between targets? I don't think I know enough about OpenWrt development yet to have a good answer on this, so I'll let you all try to answer this. But if I don't hear some specific negatives or some other consensus within a day or few, I'll try BUSYBOX_DEFAULT_BASE64 for a v3. Of course, I can also hold off sending if people were actively looking at the other parts of this series still. Brian
> Le 9 janv. 2023 à 04:09, Brian Norris <computersforpeace@gmail.com> a écrit : > > On Sun, Jan 8, 2023 at 1:37 PM Thibaut <hacks@slashdirt.org> wrote: >>> Le 8 janv. 2023 à 21:53, Christian Marangi <ansuelsmth@gmail.com> a écrit : >>> >>> On Sun, Jan 08, 2023 at 09:00:58PM +0100, Petr Štetiar wrote: […] >>>> include $(INCLUDE_DIR)/target.mk >>>> + >>>> +DEPENDS:= \ >>>> + +@BUSYBOX_DEFAULT_BASE64 >>>> + > > Thanks! That does indeed work for me. And I might just throw it into > target/linux/ipq806x/chromium/target.mk instead, since the generic > target won't be using base64. I believe that won’t work, see below. >>> Is this already used for other target? Wonder if this special thing >>> would cause some problem for packages of this target? Like discrepancy >>> with stage2 and final image? > > stage2 as in sysupgrade? I don't immediately see how that would be a > problem, but maybe I'm not understanding well enough. Packages are built on architecture-basis by a separate set of builders (« phase2 »). For ipq806x, that’s arm_cortex-a15_neon-vfpv4. While adjusting this tunable will have an effect on phase1 builds (images) and local builds from source, my understanding is it won’t affect the global architecture setting, meaning that the busybox package that’s built by the « phase2 » builders will not have this knob enabled. Thus, anyone building from imagebuilder or updating busybox from the package repo will get a version without base64, and this will break. >> AFAICT this isn’t used anywhere so far (at least according to a quick git grep). > > Right, I couldn't find any other target tweaking BUSYBOX_DEFAULT_* in > the current tree or in the git history. > > And I can't even find anyone doing a bare 'DEPENDS:=' in their > Makefile under target/linux/ at all. All usages are as part of > packages (modules), not device/target specifications. Most likely because of the above, which is why I’m not convinced it’s such a good idea to « set this precedent ». >>> Anyway this looks to be the best solution for the problem. >> >> I wonder if it’s such a good idea to have discrepancies in busybox features between targets? > > I don't think I know enough about OpenWrt development yet to have a > good answer on this, so I'll let you all try to answer this. Regardless of the above, I think these types of features (core utils that are typically used in scripts) should be enabled/disabled tree wide: otherwise, a user building a script which uses any of these features will have the « surprise » that it doesn’t work consistently on all devices, and that IMHO is bad. My 2c. T
Petr Štetiar <ynezz@true.cz> [2023-01-09 11:50:37]: Hi, > BTW ucode has `b64dec()`[1] so perhaps another viable option. > > 1. https://github.com/jow-/ucode#663-b64decstr wanted to refresh my ucode brain cells, so I've explored feasibility of that suggestion and it seems to work just fine: #!/usr/bin/ucode import { stdin, open, error } from 'fs'; if (length(ARGV) == 0 && stdin.isatty()) { warn("usage: b64decode [stdin|path]\n"); exit(1); } let fp = stdin; let source = ARGV[0]; if (source) { fp = open(source); if (!fp) { warn(`b64decode: unable to open ${source}: ${error()}\n`); exit(1); } } print(b64dec(fp.read("all"))); fp.close(); exit(0); BTW it needs recent ucode with fs.stdin.isatty() support[1]. Thanks Jo for helping me making above script more idiomatic. IMO it looks more human readable, portable and maintanable then that awk based solution. 1. https://github.com/jow-/ucode/commit/be30472bfdbbb410e8934b48a56d26c5c630d0f1 Cheers, Petr
On Mon, Jan 09, 2023 at 03:35:56PM +0100, Petr Štetiar wrote: > Petr Štetiar <ynezz@true.cz> [2023-01-09 11:50:37]: > > Hi, > > > BTW ucode has `b64dec()`[1] so perhaps another viable option. > > > > 1. https://github.com/jow-/ucode#663-b64decstr > > wanted to refresh my ucode brain cells, so I've explored feasibility of that > suggestion and it seems to work just fine: > > #!/usr/bin/ucode > > import { stdin, open, error } from 'fs'; > > if (length(ARGV) == 0 && stdin.isatty()) { > warn("usage: b64decode [stdin|path]\n"); > exit(1); > } > > let fp = stdin; > let source = ARGV[0]; > > if (source) { > fp = open(source); > if (!fp) { > warn(`b64decode: unable to open ${source}: ${error()}\n`); > exit(1); > } > } > > print(b64dec(fp.read("all"))); > fp.close(); > exit(0); > > BTW it needs recent ucode with fs.stdin.isatty() support[1]. > > Thanks Jo for helping me making above script more idiomatic. IMO it looks more > human readable, portable and maintanable then that awk based solution. > > 1. https://github.com/jow-/ucode/commit/be30472bfdbbb410e8934b48a56d26c5c630d0f1 > Thanks for helping with this. I really like the ucode way. Just a few question: 1. How this should be handled? A script that the target will provide? Part of a common function? 2. Ucode is part of the core packages? Or an optional dependency for luci and fw4? In theory it should be always present or as a safe thing we should add ucode in the required packages for this target?
On Mon, Jan 9, 2023 at 11:21 AM Christian Marangi <ansuelsmth@gmail.com> wrote: > > On Mon, Jan 09, 2023 at 03:35:56PM +0100, Petr Štetiar wrote: > > Petr Štetiar <ynezz@true.cz> [2023-01-09 11:50:37]: > > > > Hi, > > > > > BTW ucode has `b64dec()`[1] so perhaps another viable option. > > > > > > 1. https://github.com/jow-/ucode#663-b64decstr > > > > wanted to refresh my ucode brain cells, so I've explored feasibility of that > > suggestion and it seems to work just fine: > > > > #!/usr/bin/ucode > > > > import { stdin, open, error } from 'fs'; > > > > if (length(ARGV) == 0 && stdin.isatty()) { > > warn("usage: b64decode [stdin|path]\n"); > > exit(1); > > } > > > > let fp = stdin; > > let source = ARGV[0]; > > > > if (source) { > > fp = open(source); > > if (!fp) { > > warn(`b64decode: unable to open ${source}: ${error()}\n`); > > exit(1); > > } > > } > > > > print(b64dec(fp.read("all"))); > > fp.close(); > > exit(0); > > > > BTW it needs recent ucode with fs.stdin.isatty() support[1]. > > > > Thanks Jo for helping me making above script more idiomatic. IMO it looks more > > human readable, portable and maintanable then that awk based solution. > > > > 1. https://github.com/jow-/ucode/commit/be30472bfdbbb410e8934b48a56d26c5c630d0f1 I sidestepped the isatty() stuff (below), and this works for me too. > Thanks for helping with this. I really like the ucode way. Just a few > question: > 1. How this should be handled? A script that the target will provide? > Part of a common function? For my use, it feels like a simplified form (which only needs to be a stdin/stdout pipeline) would be pretty easy to inline into the caldata/firmware-loader script: ucode -e 'import { stdin } from "fs"; print(b64dec(stdin.read("all")));' > 2. Ucode is part of the core packages? Or an optional dependency for > luci and fw4? In theory it should be always present or as a safe thing > we should add ucode in the required packages for this target? So far I don't find it as a strict core dependency, but just happens to be available by default due to dependencies. I guess similar questions to the busybox, coreutils, etc., stuff -- whether we're OK with forcing 'ucode' as a per-target dependency / DEVICE_PACKAGES. Brian
On Mon, Jan 09, 2023 at 11:51:53AM -0800, Brian Norris wrote: > On Mon, Jan 9, 2023 at 11:21 AM Christian Marangi <ansuelsmth@gmail.com> wrote: > > > > On Mon, Jan 09, 2023 at 03:35:56PM +0100, Petr Štetiar wrote: > > > Petr Štetiar <ynezz@true.cz> [2023-01-09 11:50:37]: > > > > > > Hi, > > > > > > > BTW ucode has `b64dec()`[1] so perhaps another viable option. > > > > > > > > 1. https://github.com/jow-/ucode#663-b64decstr > > > > > > wanted to refresh my ucode brain cells, so I've explored feasibility of that > > > suggestion and it seems to work just fine: > > > > > > #!/usr/bin/ucode > > > > > > import { stdin, open, error } from 'fs'; > > > > > > if (length(ARGV) == 0 && stdin.isatty()) { > > > warn("usage: b64decode [stdin|path]\n"); > > > exit(1); > > > } > > > > > > let fp = stdin; > > > let source = ARGV[0]; > > > > > > if (source) { > > > fp = open(source); > > > if (!fp) { > > > warn(`b64decode: unable to open ${source}: ${error()}\n`); > > > exit(1); > > > } > > > } > > > > > > print(b64dec(fp.read("all"))); > > > fp.close(); > > > exit(0); > > > > > > BTW it needs recent ucode with fs.stdin.isatty() support[1]. > > > > > > Thanks Jo for helping me making above script more idiomatic. IMO it looks more > > > human readable, portable and maintanable then that awk based solution. > > > > > > 1. https://github.com/jow-/ucode/commit/be30472bfdbbb410e8934b48a56d26c5c630d0f1 > > I sidestepped the isatty() stuff (below), and this works for me too. > > > Thanks for helping with this. I really like the ucode way. Just a few > > question: > > 1. How this should be handled? A script that the target will provide? > > Part of a common function? > > For my use, it feels like a simplified form (which only needs to be a > stdin/stdout pipeline) would be pretty easy to inline into the > caldata/firmware-loader script: > > ucode -e 'import { stdin } from "fs"; print(b64dec(stdin.read("all")));' > Ok a single line solution will be ideal and easy to include in the hotplug script. > > 2. Ucode is part of the core packages? Or an optional dependency for > > luci and fw4? In theory it should be always present or as a safe thing > > we should add ucode in the required packages for this target? > > So far I don't find it as a strict core dependency, but just happens > to be available by default due to dependencies. I guess similar > questions to the busybox, coreutils, etc., stuff -- whether we're OK > with forcing 'ucode' as a per-target dependency / DEVICE_PACKAGES. > If it's not a strict core dependency I would just put ucode as a dependency for the needed devices and be done with it. It's not a low space target and ucode is not that big and for sure smaller than lua, openssl and easier to implement than moving coreutils from feeds to core. Think with v3 and this implemented the series is ready.
On Mon, Jan 9, 2023 at 11:56 AM Christian Marangi <ansuelsmth@gmail.com> wrote: > On Mon, Jan 09, 2023 at 11:51:53AM -0800, Brian Norris wrote: > > For my use, it feels like a simplified form (which only needs to be a > > stdin/stdout pipeline) would be pretty easy to inline into the > > caldata/firmware-loader script: > > > > ucode -e 'import { stdin } from "fs"; print(b64dec(stdin.read("all")));' > > > > Ok a single line solution will be ideal and easy to include in the > hotplug script. Sounds good. > > > 2. Ucode is part of the core packages? Or an optional dependency for > > > luci and fw4? In theory it should be always present or as a safe thing > > > we should add ucode in the required packages for this target? > > > > So far I don't find it as a strict core dependency, but just happens > > to be available by default due to dependencies. I guess similar > > questions to the busybox, coreutils, etc., stuff -- whether we're OK > > with forcing 'ucode' as a per-target dependency / DEVICE_PACKAGES. > > > > If it's not a strict core dependency I would just put ucode as a > dependency for the needed devices and be done with it. It's not a low > space target and ucode is not that big and for sure smaller than lua, > openssl and easier to implement than moving coreutils from feeds to > core. Sounds good to me. Thanks all for the help. > Think with v3 and this implemented the series is ready. Great! Unfortunately, I'm still dependent on an outstanding patch for the fstools project: https://patchwork.ozlabs.org/project/openwrt/patch/20230107020424.1703752-1-computersforpeace@gmail.com/ See also patch 7's notes. I guess I could revert to the 2-partition layout (which does not depend on the fstools change) for the time being, so snapshots would work. I'm still trying to figure out what the best partitioning and syupgrade strategy is best for disk space flexibility and for reliability (e.g., not clobbering rootfs_data when it's appended to rootfs) on block devices... Brian
On Mon, Jan 09, 2023 at 12:23:25PM -0800, Brian Norris wrote: > On Mon, Jan 9, 2023 at 11:56 AM Christian Marangi <ansuelsmth@gmail.com> wrote: > > On Mon, Jan 09, 2023 at 11:51:53AM -0800, Brian Norris wrote: > > > For my use, it feels like a simplified form (which only needs to be a > > > stdin/stdout pipeline) would be pretty easy to inline into the > > > caldata/firmware-loader script: > > > > > > ucode -e 'import { stdin } from "fs"; print(b64dec(stdin.read("all")));' > > > > > > > Ok a single line solution will be ideal and easy to include in the > > hotplug script. > > Sounds good. > > > > > 2. Ucode is part of the core packages? Or an optional dependency for > > > > luci and fw4? In theory it should be always present or as a safe thing > > > > we should add ucode in the required packages for this target? > > > > > > So far I don't find it as a strict core dependency, but just happens > > > to be available by default due to dependencies. I guess similar > > > questions to the busybox, coreutils, etc., stuff -- whether we're OK > > > with forcing 'ucode' as a per-target dependency / DEVICE_PACKAGES. > > > > > > > If it's not a strict core dependency I would just put ucode as a > > dependency for the needed devices and be done with it. It's not a low > > space target and ucode is not that big and for sure smaller than lua, > > openssl and easier to implement than moving coreutils from feeds to > > core. > > Sounds good to me. > > Thanks all for the help. > > > Think with v3 and this implemented the series is ready. > > Great! Unfortunately, I'm still dependent on an outstanding patch for > the fstools project: > https://patchwork.ozlabs.org/project/openwrt/patch/20230107020424.1703752-1-computersforpeace@gmail.com/ > See also patch 7's notes. > > I guess I could revert to the 2-partition layout (which does not > depend on the fstools change) for the time being, so snapshots would > work. I'm still trying to figure out what the best partitioning and > syupgrade strategy is best for disk space flexibility and for > reliability (e.g., not clobbering rootfs_data when it's appended to > rootfs) on block devices... > We have way to make old image not compatible with partition change and stuff so migrating to a new implementation in the future won't be that problematic. But it would be good if we can sort it out before... Need to check that fstool patch better and see if something can be done.
Brian Norris <computersforpeace@gmail.com> [2023-01-09 11:51:53]: > For my use, it feels like a simplified form (which only needs to be a > stdin/stdout pipeline) would be pretty easy to inline into the > caldata/firmware-loader script: > > ucode -e 'import { stdin } from "fs"; print(b64dec(stdin.read("all")));' from my past experience, such oneliners usually endup in a hard to maintain copy&pasta mess between targets/scripts, thus my initial idea was to simply ship it for the start as target/linux/ipq806x/base-files/usr/bin/b64decode.uc, thus allowing following usage: - base64 -d "$source" > "$target_dir/data" + b64decode.uc "$source" > "$target_dir/data" Once such decoding is needed in other parts/targets, we would simply just move the script into target/linux/generic/base-files/usr/bin/b64decode.uc and call it a day. Cheers, Petr
On Tue, 10 Jan 2023, Petr Štetiar wrote: > Date: Tue, 10 Jan 2023 10:08:51 > From: Petr Štetiar <ynezz@true.cz> > To: Brian Norris <computersforpeace@gmail.com> > Cc: Christian Marangi <ansuelsmth@gmail.com>, Thibaut <hacks@slashdirt.org>, > Robert Marko <robimarko@gmail.com>, openwrt-devel@lists.openwrt.org, > Jo-Philipp Wich <jo@mein.io> > Subject: Re: [PATCH v2 6/7] coreutils: Import from packages feed > > Brian Norris <computersforpeace@gmail.com> [2023-01-09 11:51:53]: > >> For my use, it feels like a simplified form (which only needs to be a >> stdin/stdout pipeline) would be pretty easy to inline into the >> caldata/firmware-loader script: >> >> ucode -e 'import { stdin } from "fs"; print(b64dec(stdin.read("all")));' > > from my past experience, such oneliners usually endup in a hard to maintain > copy&pasta mess between targets/scripts, thus my initial idea was to simply > ship it for the start as target/linux/ipq806x/base-files/usr/bin/b64decode.uc, > thus allowing following usage: > > - base64 -d "$source" > "$target_dir/data" > + b64decode.uc "$source" > "$target_dir/data" > > Once such decoding is needed in other parts/targets, we would simply just move > the script into target/linux/generic/base-files/usr/bin/b64decode.uc and call > it a day. +1 Enrico > > Cheers, > > Petr > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel >
diff --git a/package/utils/coreutils/Makefile b/package/utils/coreutils/Makefile new file mode 100644 index 000000000000..d1af3ce962f1 --- /dev/null +++ b/package/utils/coreutils/Makefile @@ -0,0 +1,153 @@ +# +# Copyright (C) 2008-2014 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +include $(TOPDIR)/rules.mk + +PKG_NAME:=coreutils +PKG_VERSION:=9.1 +PKG_RELEASE:=1 + +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz +PKG_SOURCE_URL:=@GNU/coreutils +PKG_HASH:=61a1f410d78ba7e7f37a5a4f50e6d1320aca33375484a3255eddf17a38580423 + +PKG_MAINTAINER:=Jo-Philipp Wich <jo@mein.io> +PKG_LICENSE:=GPL-3.0-or-later +PKG_LICENSE_FILES:=COPYING +PKG_CPE_ID:=cpe:/a:gnu:coreutils + +PKG_INSTALL:=1 +PKG_BUILD_PARALLEL:=1 + +include $(INCLUDE_DIR)/package.mk + +COREUTILS_APPLETS := \ + base32 base64 basename basenc b2sum cat chcon chgrp chmod chown chroot \ + cksum comm cp csplit cut date dd df dir dircolors dirname du echo env \ + expand expr factor false fmt fold groups head hostid id install join \ + kill link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl \ + nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd \ + readlink realpath rm rmdir runcon seq sha1sum sha224sum sha256sum \ + sha384sum sha512sum shred shuf sleep sort split stat stdbuf stty sum \ + sync tac tail tee test timeout touch tr true truncate tsort tty uname \ + unexpand uniq unlink uptime users vdir wc who whoami yes + +DIR_BIN := \ + base64 cat chgrp chmod chown cp date dd df echo false kill link ln ls \ + mkdir mknod mktemp mv nice printenv pwd rm rmdir sleep stat stty sync \ + touch true uname + +DIR_USR_BIN := \ + basename chcon cksum comm cut dirname du env expand expr factor fold \ + groups head hostid id install logname md5sum mkfifo nl nohup nproc od \ + paste printf readlink realpath runcon seq sha1sum sha256sum sha512sum \ + shred shuf sort split sum tac tail tee test timeout tr truncate tty \ + unexpand uniq unlink uptime users wc who whoami yes + +DIR_USR_SBIN := \ + chroot + +# BusyBox does not provide these yet +DIR_OTHERS := \ + base32 b2sum basenc csplit dir dircolors fmt join numfmt pathchk pinky \ + pr ptx sha224sum sha384sum stdbuf tsort vdir + +$(eval $(foreach a,$(DIR_BIN),ALTS_$(a):=300:/bin/$(a):/usr/libexec/$(a)-coreutils$(newline))) +$(eval $(foreach a,$(DIR_USR_BIN),ALTS_$(a):=300:/usr/bin/$(a):/usr/libexec/$(a)-coreutils$(newline))) +$(eval $(foreach a,$(DIR_USR_SBIN),ALTS_$(a):=300:/usr/sbin/$(a):/usr/libexec/$(a)-coreutils$(newline))) + +DEPENDS_sort = +libpthread +DEPENDS_timeout = +librt +DEPENDS_expr = +libgmp +DEPENDS_factor = +libgmp +DEPENDS_cp = +libacl +DEPENDS_dir = +libacl +libcap +DEPENDS_install = +libacl +DEPENDS_ls = +libacl +libcap +DEPENDS_mv = +libacl +DEPENDS_vdir = +libacl +libcap + +FILES_stdbuf := usr/lib/coreutils/libstdbuf.so + +define Package/coreutils/Default + SECTION:=utils + CATEGORY:=Utilities + TITLE:=The GNU core utilities + URL:=http://www.gnu.org/software/coreutils/ +endef + +define Package/coreutils + $(call Package/coreutils/Default) + TITLE:=The GNU core utilities + MENU:=1 +endef + +define Package/coreutils/description + Full versions of standard GNU utilities. If an equivalent Busybox applet is + available, you should consider compiling that instead as Busybox applets are + usually smaller, at the expense of reduced functionality. +endef + +define GenPlugin + define Package/$(1) + $(call Package/coreutils/Default) + DEPENDS:=coreutils $(DEPENDS_$(2)) + TITLE:=Utility $(2) from the GNU core utilities + ALTERNATIVES:=$(ALTS_$(2)) + endef + + define Package/$(1)/description + Full version of standard GNU $(2) utility. + endef +endef + +$(foreach a,$(COREUTILS_APPLETS),$(eval $(call GenPlugin,coreutils-$(a),$(a)))) + +CONFIGURE_VARS += \ + gl_cv_func_mbrtowc_incomplete_state=yes \ + gl_cv_func_mbrtowc_retval=yes \ + gl_cv_func_wcrtomb_retval=yes \ + ac_cv_header_selinux_context_h=no \ + ac_cv_header_selinux_flash_h=no \ + ac_cv_header_selinux_selinux_h=no \ + ac_cv_search_setfilecon=no + +CONFIGURE_ARGS += \ + --disable-xattr \ + --enable-install-program=su \ + --enable-threads=posix \ + --enable-acl \ + --disable-assert \ + --disable-rpath \ + --disable-libsmack \ + --enable-libcap \ + --without-linux-crypto \ + --without-openssl \ + --$(if $(CONFIG_USE_MUSL),with,without)-included-regex \ + --without-selinux \ + --with-gmp + +define Package/coreutils/install + true +endef + +define BuildPlugin + define Package/$(1)/install + $(INSTALL_DIR) $$(1)/usr/$(if $(ALTS_$(2)),libexec,bin) + $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/$(2) $$(1)/usr/$(if $(ALTS_$(2)),libexec/$(2)-coreutils,bin/$(2)) + $(foreach f,$(FILES_$(2)), + $(INSTALL_DIR) $$(1)/$(dir $(f)) + $(INSTALL_BIN) $(PKG_INSTALL_DIR)/$(f) $$(1)/$(f) + ) + endef + + $$(eval $$(call BuildPackage,$(1))) +endef + +$(eval $(call BuildPackage,coreutils)) + +$(foreach a,$(COREUTILS_APPLETS),$(eval $(call BuildPlugin,coreutils-$(a),$(a)))) diff --git a/package/utils/coreutils/patches/001-no_docs_man_tests.patch b/package/utils/coreutils/patches/001-no_docs_man_tests.patch new file mode 100644 index 000000000000..e4feaf5cd9a4 --- /dev/null +++ b/package/utils/coreutils/patches/001-no_docs_man_tests.patch @@ -0,0 +1,93 @@ +--- a/Makefile.am ++++ b/Makefile.am +@@ -17,7 +17,7 @@ + + ALL_RECURSIVE_TARGETS = + +-SUBDIRS = po . gnulib-tests ++SUBDIRS = po + + EXTRA_DIST = \ + .mailmap \ +@@ -210,6 +210,3 @@ AM_CPPFLAGS = -Ilib -I$(top_srcdir)/lib + + include $(top_srcdir)/lib/local.mk + include $(top_srcdir)/src/local.mk +-include $(top_srcdir)/doc/local.mk +-include $(top_srcdir)/man/local.mk +-include $(top_srcdir)/tests/local.mk +--- a/Makefile.in ++++ b/Makefile.in +@@ -4115,11 +4115,7 @@ RECURSIVE_TARGETS = all-recursive check- + install-ps-recursive install-recursive installcheck-recursive \ + installdirs-recursive pdf-recursive ps-recursive \ + tags-recursive uninstall-recursive +-am__can_run_installinfo = \ +- case $$AM_UPDATE_INFO_DIR in \ +- n|no|NO) false;; \ +- *) (install-info --version) >/dev/null 2>&1;; \ +- esac ++am__can_run_installinfo = false + am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`; + am__vpath_adj = case $$p in \ + $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \ +@@ -4369,10 +4365,10 @@ am__DIST_COMMON = $(doc_coreutils_TEXINF + $(top_srcdir)/build-aux/missing \ + $(top_srcdir)/build-aux/test-driver \ + $(top_srcdir)/build-aux/texinfo.tex \ +- $(top_srcdir)/build-aux/ylwrap $(top_srcdir)/doc/local.mk \ +- $(top_srcdir)/lib/alloca.c $(top_srcdir)/lib/config.hin \ +- $(top_srcdir)/lib/local.mk $(top_srcdir)/man/local.mk \ +- $(top_srcdir)/src/local.mk $(top_srcdir)/src/single-binary.mk \ ++ $(top_srcdir)/build-aux/ylwrap \ ++ $(top_srcdir)/lib/alloca.c \ ++ $(top_srcdir)/lib/local.mk \ ++ $(top_srcdir)/src/local.mk \ + $(top_srcdir)/tests/local.mk ABOUT-NLS AUTHORS COPYING \ + ChangeLog INSTALL NEWS README THANKS TODO build-aux/compile \ + build-aux/config.guess build-aux/config.rpath \ +@@ -4479,7 +4475,7 @@ EOVERFLOW_VALUE = @EOVERFLOW_VALUE@ + ERRNO_H = @ERRNO_H@ + ETAGS = @ETAGS@ + EXEEXT = @EXEEXT@ +-EXTRA_MANS = @EXTRA_MANS@ ++EXTRA_MANS = + FLOAT_H = @FLOAT_H@ + FNMATCH_H = @FNMATCH_H@ + GETADDRINFO_LIB = @GETADDRINFO_LIB@ +@@ -6057,7 +6053,7 @@ libexecdir = @libexecdir@ + lispdir = @lispdir@ + localedir = @localedir@ + localstatedir = @localstatedir@ +-man1_MANS = @man1_MANS@ ++man1_MANS = + mandir = @mandir@ + mkdir_p = @mkdir_p@ + oldincludedir = @oldincludedir@ +@@ -6080,7 +6076,7 @@ top_build_prefix = @top_build_prefix@ + top_builddir = @top_builddir@ + top_srcdir = @top_srcdir@ + ALL_RECURSIVE_TARGETS = distcheck-hook check-root +-SUBDIRS = po . gnulib-tests ++SUBDIRS = po + + #if GNU_MAKE + # [nicer features that work only with GNU Make] +@@ -8272,7 +8268,7 @@ all: $(BUILT_SOURCES) + .SUFFIXES: .1 .c .dvi .log .o .obj .pl .pl$(EXEEXT) .ps .sh .sh$(EXEEXT) .trs .x .xpl .xpl$(EXEEXT) .y + am--refresh: Makefile + @: +-$(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(top_srcdir)/lib/local.mk $(srcdir)/lib/gnulib.mk $(top_srcdir)/src/local.mk $(srcdir)/src/cu-progs.mk $(top_srcdir)/src/single-binary.mk $(top_srcdir)/doc/local.mk $(top_srcdir)/man/local.mk $(top_srcdir)/tests/local.mk $(am__configure_deps) ++$(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(top_srcdir)/lib/local.mk $(srcdir)/lib/gnulib.mk $(top_srcdir)/src/local.mk $(srcdir)/src/cu-progs.mk $(top_srcdir)/src/single-binary.mk $(am__configure_deps) + @for dep in $?; do \ + case '$(am__configure_deps)' in \ + *$$dep*) \ +@@ -8294,7 +8290,7 @@ Makefile: $(srcdir)/Makefile.in $(top_bu + echo ' cd $(top_builddir) && $(SHELL) ./config.status $@ $(am__maybe_remake_depfiles)'; \ + cd $(top_builddir) && $(SHELL) ./config.status $@ $(am__maybe_remake_depfiles);; \ + esac; +-$(top_srcdir)/lib/local.mk $(srcdir)/lib/gnulib.mk $(top_srcdir)/src/local.mk $(srcdir)/src/cu-progs.mk $(top_srcdir)/src/single-binary.mk $(top_srcdir)/doc/local.mk $(top_srcdir)/man/local.mk $(top_srcdir)/tests/local.mk $(am__empty): ++$(top_srcdir)/lib/local.mk $(srcdir)/lib/gnulib.mk $(top_srcdir)/src/local.mk $(srcdir)/src/cu-progs.mk $(top_srcdir)/src/single-binary.mk $(am__empty): + + $(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES) + $(SHELL) ./config.status --recheck
I need to express a per-target dependency on the 'base64' utility, and that's seemingly impossible to do for busybox. Pull in coreutils to make that easier. Signed-off-by: Brian Norris <computersforpeace@gmail.com> --- * New in v2 (no changes since v1) package/utils/coreutils/Makefile | 153 ++++++++++++++++++ .../patches/001-no_docs_man_tests.patch | 93 +++++++++++ 2 files changed, 246 insertions(+) create mode 100644 package/utils/coreutils/Makefile create mode 100644 package/utils/coreutils/patches/001-no_docs_man_tests.patch