[PATCH] binutils: fix build after upgrade to 2.34
From: "W. Michael Petullo" Building the binutils package produced the following error: Package binutils is missing dependencies for the following libraries: libctf-nobfd.so.0 This changes the glob for the libctf subpackage so that it catches libctf-nobfd.so.0. Signed-off-by: W. Michael Petullo --- package/devel/binutils/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/devel/binutils/Makefile b/package/devel/binutils/Makefile index 6ad326efa0..fada8009be 100644 --- a/package/devel/binutils/Makefile +++ b/package/devel/binutils/Makefile @@ -106,7 +106,7 @@ endef define Package/libctf/install $(INSTALL_DIR) $(1)/usr/lib - $(CP) $(PKG_INSTALL_DIR)/usr/lib/libctf.so* $(1)/usr/lib/ + $(CP) $(PKG_INSTALL_DIR)/usr/lib/libctf*.so* $(1)/usr/lib/ endef define Package/libopcodes/install -- 2.26.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC] Policy for PKG_RELEASE bumps
Hi, On 08.08.20 22:40, Sander Vanheule wrote: Hi Paul, Following our brief discussion on IRC, here are my remarks again, so others can also comment on them. I'm still pretty new to this packaging stuff, so some arguments may already have been made in the past. On Fri, 2020-08-07 at 12:32 -1000, Paul Spooren wrote: Hi team, currently exist two different ideas on when to raise the PKG_RELEASE of a package. * When functional things change For example, a OpenWrt specific patch is added * When anything inside the packages ipk file changes Includes patch and so called "cosmetic" changes outside the Makefile, e.g. replace tabs with spaces. While one could argue that following the first approach lowers the number of non functional updates via `opkg`, it results in packages with different checksums. To keep track of what is reproducible and what not, it is very helpful to see changes in PKG_RELEASE. If not, two seemingly same packages (version/release) have different checksums. Looking at other distros (Debian [1], Fedora [2]), it appears to be common to reset the equivalent of PGK_RELEASE for every upstream version bump. In OpenWrt it appears to mean [3] "our version since the dawn of times" instead of "our version of this upstream release". I feel that having to bump PKG_RELEASE for each and every commit on a package, wouldn't be a good idea: * It adds an 'unrelated' change to the patch. PGK_RELEASE should be for keeping track of package versions, not so much for keeping track of source versions. We have PKG_VERSION to keep track of package versions, and PKG_RELEASE to keep track of our modifications. From what I remember we discussed on IRC an automatic PKG_RELEASE bump similar to how LuCI sets PKG_VERSIONS, which uses git as a counter[1]. I don't see of a PKG_RELEASE bump is unrelated to the patch. [1]: https://github.com/openwrt/luci/blob/master/luci.mk#L72 * It will probably require maintainers to ask people to bump PGK_RELEASE in their patches over and over again. If we keep the Debian style with resetting to PKG_RELEASE:=1 on every PKG_VERSION change, I'll just add a check to our tba CI - it's the same issue with a SoB lines. The frequent package updates are likely to happen only when using snapshots, which receives a new firmware on a daily basis anyway. Could snapshot builds use automatic package versioning? This would make sure that not every single patch needs to bump PGK_RELEASE. For example: 1.2.0-1.snapshotXYZ To make sure that version numbers only ever increase, the snapshot version XYZ could be a source timestamp (for that package), or the number of commits in that package. One argument against the latter, is that the package version number would then be related to a commit in a non-obvious way. Fedora for example, uses a DATE.REVISION format for snapshot versions. So their snapshot packages (for that day) may not sort correctly, but will in any case point to a specific commit. If the commit history between a release build and snapshot build is the same, you may want both to have the same package version. So that might be a special case where you don't add a snapshot version tag. Unless you don't mind two package versions pointing to the same code version. The latter would, in my opinion, be less of an issue than a single package version being used for multiple source versions. Jow was thinking to improve the ABI handling of packages to allow incremental (instead of full) package rebuilds. Maybe within that work some package-renaming happens. My key point here is however that I want to simplify the work of people working on reproducibility. From my experience it's easier to compare things when both the unique package identification is possible (via PKG_VERSION+PKG_RELEASE) and the build system revision is known[2]. By sticking to my proposed policy, we solve the former :) [2]: https://patchwork.ozlabs.org/project/openwrt/list/?series=191059 Please share your thoughts. If there are no strong arguments against bumping the PKG_RELEASE on anything that changes the resulting package content, I'd like to make that a policy. [1] https://readme.phys.ethz.ch/documentation/debian_version_numbers/ [2] https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/ [3] commit 9c170cb92f4fbb316592c11567a080eb3f6a1fc3 -- Best, Paul ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] toolchain: binutils: Fix typo in patch for MIPS64
On Mon, 10 Aug 2020 at 00:01, Hauke Mehrtens wrote:
>
> There was a typo in the patch which breaks compiling binutils on
> MIPS63EL.
> make[7]: *** No rule to make target 'elf64ltsmip.o', needed by 'ld-new'.
> Stop.
>
> Fixes: FS#3276
> Fixes: 53470bdf3212 ("toolchain/binutils: Add binutils 2.34")
> Signed-off-by: Hauke Mehrtens
Acked-by: Yousong Zhou
Regards,
yousong
> ---
> .../2.34/500-Change-default-emulation-for-mips64-linux.patch| 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
> a/toolchain/binutils/patches/2.34/500-Change-default-emulation-for-mips64-linux.patch
>
> b/toolchain/binutils/patches/2.34/500-Change-default-emulation-for-mips64-linux.patch
> index 24c2afb8be51..455ac0001dd4 100644
> ---
> a/toolchain/binutils/patches/2.34/500-Change-default-emulation-for-mips64-linux.patch
> +++
> b/toolchain/binutils/patches/2.34/500-Change-default-emulation-for-mips64-linux.patch
> @@ -25,7 +25,7 @@
> ;;
> -mips64*el-*-linux-*) targ_emul=elf32ltsmipn32
> - targ_extra_emuls="elf32btsmipn32 elf32ltsmip
> elf32btsmip elf64ltsmip elf64btsmip"
> -+mips64*el-*-linux-*) targ_emul=lf64ltsmip
> ++mips64*el-*-linux-*) targ_emul=elf64ltsmip
> + targ_extra_emuls="elf32btsmipn32 elf32ltsmipn32
> elf32ltsmip elf32btsmip elf64btsmip"
> targ_extra_libpath=$targ_extra_emuls
> ;;
> --
> 2.20.1
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] malta: Refresh kernel configuration
On Mon, 10 Aug 2020 at 00:17, Hauke Mehrtens wrote: > > This refreshes the kernel configuration on top of kernel 5.4. > It now builds without asking to select some kernel options on all 4 > subtargets. > It still does not boot up, there is a different problem. malta/be boots fine with this applied, so I guess this line is about mips64. > > Signed-off-by: Hauke Mehrtens Tested-By: Yousong Zhou Acked-By: Yousong Zhou Regards, yousong > --- > target/linux/malta/be/config-default | 8 > target/linux/malta/be64/config-default | 7 +-- > target/linux/malta/config-5.4 | 9 + > target/linux/malta/le/config-default | 9 - > target/linux/malta/le64/config-default | 8 +--- > 5 files changed, 23 insertions(+), 18 deletions(-) > > diff --git a/target/linux/malta/be/config-default > b/target/linux/malta/be/config-default > index 5586be6b7c46..735296f5b3f3 100644 > --- a/target/linux/malta/be/config-default > +++ b/target/linux/malta/be/config-default > @@ -1,4 +1,12 @@ > CONFIG_CPU_BIG_ENDIAN=y > +CONFIG_CPU_HAS_RIXI=y > # CONFIG_CPU_LITTLE_ENDIAN is not set > CONFIG_CPU_MIPS32_R2=y > +CONFIG_CPU_MIPSR2=y > +CONFIG_CPU_SUPPORTS_MSA=y > +CONFIG_HAVE_CBPF_JIT=y > +CONFIG_HAVE_KVM=y > CONFIG_HIGHMEM=y > +CONFIG_MIPS_CBPF_JIT=y > +CONFIG_MIPS_SPRAM=y > +CONFIG_TARGET_ISA_REV=2 > diff --git a/target/linux/malta/be64/config-default > b/target/linux/malta/be64/config-default > index 3792b7fce831..8edef1a8579e 100644 > --- a/target/linux/malta/be64/config-default > +++ b/target/linux/malta/be64/config-default > @@ -9,20 +9,15 @@ CONFIG_CPU_BIG_ENDIAN=y > # CONFIG_CPU_LITTLE_ENDIAN is not set > CONFIG_CPU_MIPS64=y > CONFIG_CPU_MIPS64_R1=y > -CONFIG_CPU_MIPSR1=y > CONFIG_CPU_SUPPORTS_64BIT_KERNEL=y > CONFIG_CPU_SUPPORTS_HUGEPAGES=y > -CONFIG_HAVE_64BIT_ALIGNED_ACCESS=y > CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y > -CONFIG_HAVE_EBPF_JIT=y > CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y > -# CONFIG_HUGETLBFS is not set > +# CONFIG_IONIC is not set > # CONFIG_MIPS32_N32 is not set > # CONFIG_MIPS32_O32 is not set > -CONFIG_MIPS_EBPF_JIT=y > # CONFIG_MIPS_VA_BITS_48 is not set > CONFIG_MODULES_USE_ELF_RELA=y > -CONFIG_PCI_BUS_ADDR_T_64BIT=y > CONFIG_PGTABLE_LEVELS=3 > CONFIG_PHYS_ADDR_T_64BIT=y > CONFIG_SYS_SUPPORTS_HUGETLBFS=y > diff --git a/target/linux/malta/config-5.4 b/target/linux/malta/config-5.4 > index 865be850cbd6..10ad79548056 100644 > --- a/target/linux/malta/config-5.4 > +++ b/target/linux/malta/config-5.4 > @@ -43,6 +43,7 @@ CONFIG_BOUNCE=y > CONFIG_BUILTIN_DTB=y > CONFIG_CDROM=y > CONFIG_CEVT_R4K=y > +# CONFIG_CGROUPS is not set > CONFIG_CLKBLD_I8253=y > CONFIG_CLKDEV_LOOKUP=y > CONFIG_CLKEVT_I8253=y > @@ -61,7 +62,7 @@ CONFIG_CPU_HAS_SYNC=y > # CONFIG_CPU_MICROMIPS is not set > CONFIG_CPU_MIPS32=y > # CONFIG_CPU_MIPS32_3_5_FEATURES is not set > -CONFIG_CPU_MIPS32_R1=y > +# CONFIG_CPU_MIPS32_R1 is not set > # CONFIG_CPU_MIPS32_R2 is not set > # CONFIG_CPU_MIPS32_R6 is not set > # CONFIG_CPU_MIPS64_R1 is not set > @@ -99,9 +100,7 @@ CONFIG_DUMMY_CONSOLE=y > CONFIG_EFI_EARLYCON=y > CONFIG_ENABLE_MUST_CHECK=y > CONFIG_EXT4_FS=y > -# CONFIG_F2FS_CHECK_FS is not set > CONFIG_F2FS_FS=y > -# CONFIG_F2FS_FS_SECURITY is not set > CONFIG_F2FS_FS_XATTR=y > CONFIG_F2FS_STAT_FS=y > CONFIG_FONT_8x16=y > @@ -173,6 +172,8 @@ CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y > CONFIG_HAVE_RSEQ=y > CONFIG_HAVE_SYSCALL_TRACEPOINTS=y > CONFIG_HW_CONSOLE=y > +CONFIG_HZ=250 > +CONFIG_HZ_250=y > CONFIG_I8253=y > CONFIG_I8253_LOCK=y > CONFIG_I8259=y > @@ -243,7 +244,6 @@ CONFIG_NO_HZ_COMMON=y > CONFIG_NO_HZ_IDLE=y > CONFIG_NR_CPUS=2 > CONFIG_NVMEM=y > -# CONFIG_NVMEM_REBOOT_MODE is not set > CONFIG_OF=y > CONFIG_OF_ADDRESS=y > CONFIG_OF_EARLY_FLATTREE=y > @@ -285,6 +285,7 @@ CONFIG_RFS_ACCEL=y > CONFIG_RPS=y > CONFIG_RTC_CLASS=y > # CONFIG_RTC_DRV_JZ4740 is not set > +CONFIG_RTC_MC146818_LIB=y > CONFIG_SCSI=y > CONFIG_SECCOMP=y > CONFIG_SECCOMP_FILTER=y > diff --git a/target/linux/malta/le/config-default > b/target/linux/malta/le/config-default > index 2b42a6b5b2bf..2c6148195e10 100644 > --- a/target/linux/malta/le/config-default > +++ b/target/linux/malta/le/config-default > @@ -1,4 +1,11 @@ > -# CONFIG_CPU_BIG_ENDIAN is not set > +CONFIG_CPU_HAS_RIXI=y > CONFIG_CPU_LITTLE_ENDIAN=y > CONFIG_CPU_MIPS32_R2=y > +CONFIG_CPU_MIPSR2=y > +CONFIG_CPU_SUPPORTS_MSA=y > +CONFIG_HAVE_CBPF_JIT=y > +CONFIG_HAVE_KVM=y > CONFIG_HIGHMEM=y > +CONFIG_MIPS_CBPF_JIT=y > +CONFIG_MIPS_SPRAM=y > +CONFIG_TARGET_ISA_REV=2 > diff --git a/target/linux/malta/le64/config-default > b/target/linux/malta/le64/config-default > index ff4496382dd1..fd4019c7b38f 100644 > --- a/target/linux/malta/le64/config-default > +++ b/target/linux/malta/le64/config-default > @@ -5,24 +5,18 @@ CONFIG_ARCH_MMAP_RND_BITS=12 > CONFIG_ARCH_MMAP_RND_BITS_MAX=18 > CONFIG_ARCH_MMAP_RND_BITS_MIN=12 > CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y > -# CONFIG_CPU_BIG_ENDIAN is not set >
Re: [PATCH] kernel: Move CONFIG_IONIC to generic kernel config
On Mon, 10 Aug 2020 at 00:17, Hauke Mehrtens wrote: > > It is deactivated everywhere, just set this in the generic config. > > Signed-off-by: Hauke Mehrtens Acked-by: Yousong Zhou Regards, yousong ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH procd] initd/init: add minimal SELinux policy loading support
[...] > This is part of a bigger PR on GitHub[1], however this patch should be > added directly to `procd` rather than as a patch in openwrt.git. [...] I will update the GitHub pull request once this is merged. Thank you, Paul! -- Mike :wq ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] treewide: replace `which` with `command -v`
Fix shellcheck SC2230
> which is non-standard. Use builtin 'command -v' instead.
Using `command -v` is POSIX compliant while `which` is not. Also to
mention, `command -v` is a shell builtin whereas `which` is a separate
busybox applet.
Once applied to everything concerning OpenWrt we can disable the busybox
feature `which` and save 3.8kB.
Acked-by: Stijn Tintel
Signed-off-by: Paul Spooren
---
include/rootfs.mk| 6 +++---
package/base-files/files/lib/upgrade/stage2 | 2 +-
.../kernel/broadcom-wl/files/lib/wifi/broadcom.sh| 2 +-
scripts/ipkg-build | 12 ++--
4 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/include/rootfs.mk b/include/rootfs.mk
index b6775c7e15..18ada3cd43 100644
--- a/include/rootfs.mk
+++ b/include/rootfs.mk
@@ -69,7 +69,7 @@ define prepare_rootfs
@( \
cd $(1); \
for script in ./usr/lib/opkg/info/*.postinst; do \
- IPKG_INSTROOT=$(1) $$(which bash) $$script; \
+ IPKG_INSTROOT=$(1) $$(command -v bash) $$script; \
ret=$$?; \
if [ $$ret -ne 0 ]; then \
echo "postinst script $$script has failed with
exit code $$ret" >&2; \
@@ -79,10 +79,10 @@ define prepare_rootfs
for script in ./etc/init.d/*; do \
grep '#!/bin/sh /etc/rc.common' $$script >/dev/null ||
continue; \
if ! echo " $(3) " | grep -q " $$(basename $$script) ";
then \
- IPKG_INSTROOT=$(1) $$(which bash)
./etc/rc.common $$script enable; \
+ IPKG_INSTROOT=$(1) $$(command -v bash)
./etc/rc.common $$script enable; \
echo "Enabling" $$(basename $$script); \
else \
- IPKG_INSTROOT=$(1) $$(which bash)
./etc/rc.common $$script disable; \
+ IPKG_INSTROOT=$(1) $$(command -v bash)
./etc/rc.common $$script disable; \
echo "Disabling" $$(basename $$script); \
fi; \
done || true \
diff --git a/package/base-files/files/lib/upgrade/stage2
b/package/base-files/files/lib/upgrade/stage2
index dbb33e8958..a4fef42134 100755
--- a/package/base-files/files/lib/upgrade/stage2
+++ b/package/base-files/files/lib/upgrade/stage2
@@ -45,7 +45,7 @@ switch_to_ramfs() {
snapshot snapshot_tool \
$RAMFS_COPY_BIN
do
- local file="$(which "$binary" 2>/dev/null)"
+ local file="$(command -v "$binary" 2>/dev/null)"
[ -n "$file" ] && install_bin "$file"
done
install_file /etc/resolv.conf /lib/*.sh /lib/functions/*.sh
/lib/upgrade/*.sh /lib/upgrade/do_stage2 /usr/share/libubox/jshn.sh
$RAMFS_COPY_DATA
diff --git a/package/kernel/broadcom-wl/files/lib/wifi/broadcom.sh
b/package/kernel/broadcom-wl/files/lib/wifi/broadcom.sh
index 33447341b2..352c365f27 100644
--- a/package/kernel/broadcom-wl/files/lib/wifi/broadcom.sh
+++ b/package/kernel/broadcom-wl/files/lib/wifi/broadcom.sh
@@ -223,7 +223,7 @@ enable_broadcom() {
}
local _c=0
- local nas="$(which nas)"
+ local nas="$(command -v nas)"
local if_pre_up if_up nas_cmd
local vif vif_pre_up vif_post_up vif_do_up vif_txpower
local bssmax=$(wlc ifname "$device" bssmax)
diff --git a/scripts/ipkg-build b/scripts/ipkg-build
index 21127f3391..6e027bc546 100755
--- a/scripts/ipkg-build
+++ b/scripts/ipkg-build
@@ -10,10 +10,10 @@
set -e
version=1.0
-FIND="$(which find)"
-FIND="${FIND:-$(which gfind)}"
-TAR="${TAR:-$(which tar)}"
-GZIP="$(which gzip)"
+FIND="$(command -v find)"
+FIND="${FIND:-$(command -v gfind)}"
+TAR="${TAR:-$(command -v tar)}"
+GZIP="$(command -v gzip)"
# try to use fixed source epoch
if [ -n "$SOURCE_DATE_EPOCH" ]; then
@@ -21,10 +21,10 @@ if [ -n "$SOURCE_DATE_EPOCH" ]; then
# look up date of last commit
elif [ -d "$TOPDIR/.git" ]; then
- GIT="$(which git)"
+ GIT="$(command -v git)"
TIMESTAMP=$(cd $TOPDIR; $GIT log -1 -s --format=%ci)
elif [ -d "$TOPDIR/.svn" ]; then
- SVN="$(which svn)"
+ SVN="$(command -v svn)"
TIMESTAMP=$($SVN info "$TOPDIR" | sed -n "s/^Last Changed Date:
\(.*\)/\1/p")
else
TIMESTAMP=$(date)
--
2.25.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH procd] initd/init: add minimal SELinux policy loading support
From: Thomas Petazzoni
In order to support SELinux in OpenWrt, this commit introduces minimal
support for loading the SELinux policy in the init code. The logic is
very much inspired from what Busybox is doing: call
selinux_init_load_policy() from libselinux, and then re-execute init
so that it runs with the SELinux policy in place and enforced.
Signed-off-by: Thomas Petazzoni
[fix spelling of OpenWrt]
Signed-off-by: Paul Spooren
---
This is part of a bigger PR on GitHub[1], however this patch should be
added directly to `procd` rather than as a patch in openwrt.git.
As some core devs avoid GitHubs heavy frontend, I send this particular
patch here again.
I've tested the patch series and it compiles and runs as (I) expected.
[1]: https://github.com/openwrt/openwrt/pull/3207
CMakeLists.txt | 9 -
initd/init.c | 38 ++
2 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index c7adfa3..d20e57b 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -46,6 +46,12 @@ IF(ZRAM_TMPFS)
SET(SOURCES_ZRAM initd/zram.c)
ENDIF()
+IF(SELINUX)
+ include(FindPkgConfig)
+ pkg_search_module(SELINUX REQUIRED libselinux)
+ add_compile_definitions(WITH_SELINUX)
+ENDIF()
+
add_subdirectory(upgraded)
ADD_EXECUTABLE(procd ${SOURCES})
@@ -62,7 +68,8 @@ ADD_DEFINITIONS(-DDISABLE_INIT)
ELSE()
ADD_EXECUTABLE(init initd/init.c initd/early.c initd/preinit.c initd/mkdev.c
sysupgrade.c watchdog.c
utils/utils.c ${SOURCES_ZRAM})
-TARGET_LINK_LIBRARIES(init ${LIBS})
+TARGET_INCLUDE_DIRECTORIES(init PUBLIC ${SELINUX_INCLUDE_DIRS})
+TARGET_LINK_LIBRARIES(init ${LIBS} ${SELINUX_LIBRARIES})
INSTALL(TARGETS init
RUNTIME DESTINATION ${CMAKE_INSTALL_SBINDIR}
)
diff --git a/initd/init.c b/initd/init.c
index 9b47826..2eb6ead 100644
--- a/initd/init.c
+++ b/initd/init.c
@@ -29,6 +29,10 @@
#include
#include
+#if defined(WITH_SELINUX)
+#include
+#endif
+
#include "../utils/utils.h"
#include "init.h"
#include "../watchdog.h"
@@ -67,6 +71,38 @@ cmdline(void)
}
}
+#if defined(WITH_SELINUX)
+static int
+selinux(char **argv)
+{
+ int enforce = 0;
+ int ret;
+
+ /* SELinux already initialized */
+ if (getenv("SELINUX_INIT"))
+ return 0;
+
+ putenv("SELINUX_INIT=1");
+
+ ret = selinux_init_load_policy();
+ if (ret == 0)
+ execv(argv[0], argv);
+
+ if (enforce > 0) {
+ fprintf(stderr, "Cannot load SELinux policy, but system in
enforcing mode. Halting.\n");
+ return 1;
+ }
+
+ return 0;
+}
+#else
+static int
+selinux(char **argv)
+{
+ return 0;
+}
+#endif
+
int
main(int argc, char **argv)
{
@@ -79,6 +115,8 @@ main(int argc, char **argv)
sigaction(SIGUSR2, _shutdown, NULL);
sigaction(SIGPWR, _shutdown, NULL);
+ if (selinux(argv))
+ exit(-1);
early();
cmdline();
watchdog_init(1);
--
2.25.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] busybox: Disable `which` command
The `which` command returns the first found path to a binary specified. It's behaviour is identical to the shell built in `command -v`. Shellcheck even prints a warning if `which` is used (SC2230). Once neither `openwrt.git` nor related repositories make use of `which`, the command should be disabled for busybox, freeing roughly 4kB. Signed-off-by: Paul Spooren --- This patch depends on the following three patches: openwrt.git: https://patchwork.ozlabs.org/project/openwrt/list/?series=194732 packages.git: https://github.com/openwrt/packages/pull/13059 luci.git: https://github.com/openwrt/luci/pull/4342 package/utils/busybox/Config-defaults.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/utils/busybox/Config-defaults.in b/package/utils/busybox/Config-defaults.in index 29724041f4..2944369a69 100644 --- a/package/utils/busybox/Config-defaults.in +++ b/package/utils/busybox/Config-defaults.in @@ -997,7 +997,7 @@ config BUSYBOX_DEFAULT_FEATURE_START_STOP_DAEMON_FANCY default n config BUSYBOX_DEFAULT_WHICH bool - default y + default n config BUSYBOX_DEFAULT_MINIPS bool default n -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] treewide: replace `which` with `command -v`
On Sun, Aug 9, 2020 at 4:33 PM Stijn Tintel wrote:
>
> On 8/08/2020 01:54, Paul Spooren wrote:
> > Fix shellcheck SC2230
> >> which is non-standard. Use builtin 'command -v' instead.
> > Once applied to everything concerning OpenWrt we can disable the busybox
> > feature `which` and save 3.8kB.
>
> Maybe mention `command -v` is POSIX compliant, and `which` is not, in
> the commit message.
Maybe also mention that command is builtin whereas which is a separate
binary (or applet in busybox terms).
root@OpenWrt:~# busybox which
BusyBox v1.31.1 () multi-call binary.
Usage: which [COMMAND]...
Locate a COMMAND
root@OpenWrt:~# busybox command
command: applet not found
>
> Acked-by: Stijn Tintel
> >
> > Signed-off-by: Paul Spooren
> > ---
> > include/rootfs.mk| 6 +++---
> > package/base-files/files/lib/upgrade/stage2 | 2 +-
> > .../kernel/broadcom-wl/files/lib/wifi/broadcom.sh| 2 +-
> > scripts/ipkg-build | 12 ++--
> > 4 files changed, 11 insertions(+), 11 deletions(-)
> >
> > diff --git a/include/rootfs.mk b/include/rootfs.mk
> > index b6775c7e15..18ada3cd43 100644
> > --- a/include/rootfs.mk
> > +++ b/include/rootfs.mk
> > @@ -69,7 +69,7 @@ define prepare_rootfs
> > @( \
> > cd $(1); \
> > for script in ./usr/lib/opkg/info/*.postinst; do \
> > - IPKG_INSTROOT=$(1) $$(which bash) $$script; \
> > + IPKG_INSTROOT=$(1) $$(command -v bash) $$script; \
> > ret=$$?; \
> > if [ $$ret -ne 0 ]; then \
> > echo "postinst script $$script has failed
> > with exit code $$ret" >&2; \
> > @@ -79,10 +79,10 @@ define prepare_rootfs
> > for script in ./etc/init.d/*; do \
> > grep '#!/bin/sh /etc/rc.common' $$script >/dev/null
> > || continue; \
> > if ! echo " $(3) " | grep -q " $$(basename $$script)
> > "; then \
> > - IPKG_INSTROOT=$(1) $$(which bash)
> > ./etc/rc.common $$script enable; \
> > + IPKG_INSTROOT=$(1) $$(command -v bash)
> > ./etc/rc.common $$script enable; \
> > echo "Enabling" $$(basename $$script); \
> > else \
> > - IPKG_INSTROOT=$(1) $$(which bash)
> > ./etc/rc.common $$script disable; \
> > + IPKG_INSTROOT=$(1) $$(command -v bash)
> > ./etc/rc.common $$script disable; \
> > echo "Disabling" $$(basename $$script); \
> > fi; \
> > done || true \
> > diff --git a/package/base-files/files/lib/upgrade/stage2
> > b/package/base-files/files/lib/upgrade/stage2
> > index dbb33e8958..a4fef42134 100755
> > --- a/package/base-files/files/lib/upgrade/stage2
> > +++ b/package/base-files/files/lib/upgrade/stage2
> > @@ -45,7 +45,7 @@ switch_to_ramfs() {
> > snapshot snapshot_tool \
> > $RAMFS_COPY_BIN
> > do
> > - local file="$(which "$binary" 2>/dev/null)"
> > + local file="$(command -v "$binary" 2>/dev/null)"
> > [ -n "$file" ] && install_bin "$file"
> > done
> > install_file /etc/resolv.conf /lib/*.sh /lib/functions/*.sh
> > /lib/upgrade/*.sh /lib/upgrade/do_stage2 /usr/share/libubox/jshn.sh
> > $RAMFS_COPY_DATA
> > diff --git a/package/kernel/broadcom-wl/files/lib/wifi/broadcom.sh
> > b/package/kernel/broadcom-wl/files/lib/wifi/broadcom.sh
> > index 33447341b2..352c365f27 100644
> > --- a/package/kernel/broadcom-wl/files/lib/wifi/broadcom.sh
> > +++ b/package/kernel/broadcom-wl/files/lib/wifi/broadcom.sh
> > @@ -223,7 +223,7 @@ enable_broadcom() {
> > }
> >
> > local _c=0
> > - local nas="$(which nas)"
> > + local nas="$(command -v nas)"
> > local if_pre_up if_up nas_cmd
> > local vif vif_pre_up vif_post_up vif_do_up vif_txpower
> > local bssmax=$(wlc ifname "$device" bssmax)
> > diff --git a/scripts/ipkg-build b/scripts/ipkg-build
> > index 21127f3391..6e027bc546 100755
> > --- a/scripts/ipkg-build
> > +++ b/scripts/ipkg-build
> > @@ -10,10 +10,10 @@
> > set -e
> >
> > version=1.0
> > -FIND="$(which find)"
> > -FIND="${FIND:-$(which gfind)}"
> > -TAR="${TAR:-$(which tar)}"
> > -GZIP="$(which gzip)"
> > +FIND="$(command -v find)"
> > +FIND="${FIND:-$(command -v gfind)}"
> > +TAR="${TAR:-$(command -v tar)}"
> > +GZIP="$(command -v gzip)"
> >
> > # try to use fixed source epoch
> > if [ -n "$SOURCE_DATE_EPOCH" ]; then
> > @@ -21,10 +21,10 @@ if [ -n "$SOURCE_DATE_EPOCH" ]; then
> >
> > # look up date of last commit
> > elif [ -d "$TOPDIR/.git" ]; then
> > - GIT="$(which git)"
> > + GIT="$(command -v git)"
> > TIMESTAMP=$(cd $TOPDIR; $GIT log -1 -s --format=%ci)
> > elif [ -d "$TOPDIR/.svn" ]; then
> > -
Re: [PATCH] treewide: replace `which` with `command -v`
On 8/08/2020 01:54, Paul Spooren wrote:
> Fix shellcheck SC2230
>> which is non-standard. Use builtin 'command -v' instead.
> Once applied to everything concerning OpenWrt we can disable the busybox
> feature `which` and save 3.8kB.
Maybe mention `command -v` is POSIX compliant, and `which` is not, in
the commit message.
Acked-by: Stijn Tintel
>
> Signed-off-by: Paul Spooren
> ---
> include/rootfs.mk| 6 +++---
> package/base-files/files/lib/upgrade/stage2 | 2 +-
> .../kernel/broadcom-wl/files/lib/wifi/broadcom.sh| 2 +-
> scripts/ipkg-build | 12 ++--
> 4 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/include/rootfs.mk b/include/rootfs.mk
> index b6775c7e15..18ada3cd43 100644
> --- a/include/rootfs.mk
> +++ b/include/rootfs.mk
> @@ -69,7 +69,7 @@ define prepare_rootfs
> @( \
> cd $(1); \
> for script in ./usr/lib/opkg/info/*.postinst; do \
> - IPKG_INSTROOT=$(1) $$(which bash) $$script; \
> + IPKG_INSTROOT=$(1) $$(command -v bash) $$script; \
> ret=$$?; \
> if [ $$ret -ne 0 ]; then \
> echo "postinst script $$script has failed with
> exit code $$ret" >&2; \
> @@ -79,10 +79,10 @@ define prepare_rootfs
> for script in ./etc/init.d/*; do \
> grep '#!/bin/sh /etc/rc.common' $$script >/dev/null ||
> continue; \
> if ! echo " $(3) " | grep -q " $$(basename $$script) ";
> then \
> - IPKG_INSTROOT=$(1) $$(which bash)
> ./etc/rc.common $$script enable; \
> + IPKG_INSTROOT=$(1) $$(command -v bash)
> ./etc/rc.common $$script enable; \
> echo "Enabling" $$(basename $$script); \
> else \
> - IPKG_INSTROOT=$(1) $$(which bash)
> ./etc/rc.common $$script disable; \
> + IPKG_INSTROOT=$(1) $$(command -v bash)
> ./etc/rc.common $$script disable; \
> echo "Disabling" $$(basename $$script); \
> fi; \
> done || true \
> diff --git a/package/base-files/files/lib/upgrade/stage2
> b/package/base-files/files/lib/upgrade/stage2
> index dbb33e8958..a4fef42134 100755
> --- a/package/base-files/files/lib/upgrade/stage2
> +++ b/package/base-files/files/lib/upgrade/stage2
> @@ -45,7 +45,7 @@ switch_to_ramfs() {
> snapshot snapshot_tool \
> $RAMFS_COPY_BIN
> do
> - local file="$(which "$binary" 2>/dev/null)"
> + local file="$(command -v "$binary" 2>/dev/null)"
> [ -n "$file" ] && install_bin "$file"
> done
> install_file /etc/resolv.conf /lib/*.sh /lib/functions/*.sh
> /lib/upgrade/*.sh /lib/upgrade/do_stage2 /usr/share/libubox/jshn.sh
> $RAMFS_COPY_DATA
> diff --git a/package/kernel/broadcom-wl/files/lib/wifi/broadcom.sh
> b/package/kernel/broadcom-wl/files/lib/wifi/broadcom.sh
> index 33447341b2..352c365f27 100644
> --- a/package/kernel/broadcom-wl/files/lib/wifi/broadcom.sh
> +++ b/package/kernel/broadcom-wl/files/lib/wifi/broadcom.sh
> @@ -223,7 +223,7 @@ enable_broadcom() {
> }
>
> local _c=0
> - local nas="$(which nas)"
> + local nas="$(command -v nas)"
> local if_pre_up if_up nas_cmd
> local vif vif_pre_up vif_post_up vif_do_up vif_txpower
> local bssmax=$(wlc ifname "$device" bssmax)
> diff --git a/scripts/ipkg-build b/scripts/ipkg-build
> index 21127f3391..6e027bc546 100755
> --- a/scripts/ipkg-build
> +++ b/scripts/ipkg-build
> @@ -10,10 +10,10 @@
> set -e
>
> version=1.0
> -FIND="$(which find)"
> -FIND="${FIND:-$(which gfind)}"
> -TAR="${TAR:-$(which tar)}"
> -GZIP="$(which gzip)"
> +FIND="$(command -v find)"
> +FIND="${FIND:-$(command -v gfind)}"
> +TAR="${TAR:-$(command -v tar)}"
> +GZIP="$(command -v gzip)"
>
> # try to use fixed source epoch
> if [ -n "$SOURCE_DATE_EPOCH" ]; then
> @@ -21,10 +21,10 @@ if [ -n "$SOURCE_DATE_EPOCH" ]; then
>
> # look up date of last commit
> elif [ -d "$TOPDIR/.git" ]; then
> - GIT="$(which git)"
> + GIT="$(command -v git)"
> TIMESTAMP=$(cd $TOPDIR; $GIT log -1 -s --format=%ci)
> elif [ -d "$TOPDIR/.svn" ]; then
> - SVN="$(which svn)"
> + SVN="$(command -v svn)"
> TIMESTAMP=$($SVN info "$TOPDIR" | sed -n "s/^Last Changed Date:
> \(.*\)/\1/p")
> else
> TIMESTAMP=$(date)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/4] tools: add fakeroot
On 07.08.20 20:18, Felix Fietkau wrote: On 2020-08-07 23:12, Paul Spooren wrote: From: Thomas Petazzoni SELinux support requires setting the appropriate SELinux security context to files and directories, which needs to happen at build time in order to support read-only root filesystem scenarios. In order to create these security contexts, we will have to run some SELinux-specific tools on the host machine, but that requires root access. This adds support for fakeroot, which the build process will use to run the SELinux security context creation and the image creation. Signed-off-by: Thomas Petazzoni Apply to current master, and adjust commit message Thomas' original work is available at http://lists.infradead.org/pipermail/openwrt-devel/2019-November/025976.html. Signed-off-by: W. Michael Petullo [add rules.mk FAKEROOT variable] Signed-off-by: Paul Spooren --- --- /dev/null +++ b/tools/fakeroot/Makefile @@ -0,0 +1,20 @@ +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# +include $(TOPDIR)/rules.mk + +PKG_NAME:=fakeroot +PKG_VERSION:=1.20.2 This version is rather ancient and also breaks on macOS. I've updated it, fixed macOS support and pushed the result to my staging tree at https://git.openwrt.org/?p=openwrt/staging/nbd.git;a=summary Feel free to pick my version from there if you respin or merge the series. When you do, please test it on a Linux machine again to make sure I didn't break anything with my fixes :) - Felix Your latest version compiles fine on Linux and MacOS. The initial patch here is thereby obsolete. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 4/4] build: remove INSTALL_SUID
On 07.08.20 11:13, Paul Spooren wrote: Instead of INSTALL_SUID the PKG_FILE_MODES variable should be used Signed-off-by: Paul Spooren --- rules.mk | 1 - 1 file changed, 1 deletion(-) diff --git a/rules.mk b/rules.mk index 45d96d6be4..d535e57266 100644 --- a/rules.mk +++ b/rules.mk @@ -281,7 +281,6 @@ PATCH:=patch PYTHON:=python INSTALL_BIN:=install -m0755 -INSTALL_SUID:=install -m4755 INSTALL_DIR:=install -d -m0755 INSTALL_DATA:=install -m0644 INSTALL_CONF:=install -m0600 I just checked packages.git and they still use it for multiple binaries. Therefore this shouldn't be merged at once, but only as a follow up once the packages in packages.git are updated. user@dawn:~/src/openwrt/packages$ rg INSTALL_SUID admin/schroot/Makefile 70: $(INSTALL_SUID) $(PKG_INSTALL_DIR)/usr/bin/schroot $(1)/usr/bin/ utils/mariadb/Makefile 556: $(INSTALL_SUID) \ net/iputils/Makefile 67: $(INSTALL_SUID) $(MESON_BUILD_DIR)/ping $(1)/usr/bin/ net/fping/Makefile 49: $(INSTALL_SUID) $(PKG_INSTALL_DIR)/usr/sbin/fping $(1)/usr/bin/ net/apache/Makefile 331: $(INSTALL_SUID) $(PKG_INSTALL_DIR)/usr/sbin/suexec \ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[sdwalker/sdwalker.github.io] f5a1c4: This week's update
Branch: refs/heads/master Home: https://github.com/sdwalker/sdwalker.github.io Commit: f5a1c4a53482e1c68a2b73c049d723df1a786a40 https://github.com/sdwalker/sdwalker.github.io/commit/f5a1c4a53482e1c68a2b73c049d723df1a786a40 Author: Stephen Walker Date: 2020-08-09 (Sun, 09 Aug 2020) Changed paths: M uscan/index-18.06.html M uscan/index-19.07.html M uscan/index.html Log Message: --- This week's update ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Policy on BUILD_PATENTED
On Sun, Aug 9, 2020 at 6:09 AM Sam Kuper wrote: > > On Sun, Aug 09, 2020 at 10:55:37AM +0100, Sam Kuper wrote: > > On Mon, Aug 03, 2020 at 07:11:13PM +0300, Etienne Champetier wrote: > >> Le lun. 3 août 2020 à 00:04, Rosen Penev a écrit : > >>> Whenever discussion about patents arise, I usually point to Fedora > >>> whose parent company is Red Hat, which is based in the US. There are > >>> many things that they do not distribute that OpenWrt does for legal > >>> reasons. Should Fedora's practices be mirrored or should a more > >>> liberal policy regarding patented functionality be taken? > > > > For OpenWRT at least, might Debian be a more appropriate exemplar than > > Fedora? Unlike Fedora AFAIK, but like OpenWRT, Debian is represented > > in some sense by SPI: https://www.spi-inc.org/projects/debian/ . > > > > The debian-legal mailing list archives can be searched for the > > decisions taken by the debian-legal team, and the reasoning behind > > those decisions: https://lists.debian.org/debian-legal/ . > > Here is an example of discussion on that list, that is on a similar > topic to the original question in this thread: patent-encumbered > software. It also speaks to differences between the Debian and Red Hat > policies. > > (The example is 15 years old, so perhaps not representative of current > policy. I'm just giving it as an example.) > > [The] reason Debian continues to include the mp3 decoder library is > that this patent, like so many other software patents, does not > appear to be actively enforced. This is the standard Debian uses in > deciding whether to distribute the software; Red Hat evidently uses > a different standard. Yep. And this is the issue. Which standard is to be followed, Red Hat's or Debian? In the packages feed, I've already pushed several changes that irritate people. Stuff like crippling libfaad2 and fdk-aac to strip out patented stuff, removing ffmpeg support from several packages (or making them dependent on BUILD_PATENTED), etc... I've had to tell an mpd user that I will not be fixing MPD to support HE-AAC (which some radio stations use for some bizarre reason). I'd like a decision on this issue. Debian to my knowledge does not sell anything whereas Red Hat is the most profitable Linux company out there, which makes sense as to why they would want to shield themselves from litigation. One problem with Red Hat's approach is that it would get rid of minidlna by default, which many people seem to use. Red Hat and Fedora do not distribute minidlna. I added a replacement for minidlna that does not rely on ffmpeg and overall works better but there's a massive size increase with it (it uses C++17 with several C++ libraries). I've tried to use static linking to keep the size down but it can only be slimmed so much. > > Source: https://lists.debian.org/debian-legal/2005/07/msg00082.html As a sidenote, Fedora now includes mp3 support as all the patents have expired. Same with mpeg2 support. > > -- > A: When it messes up the order in which people normally read text. > Q: When is top-posting a bad thing? > > () ASCII ribbon campaign. Please avoid HTML emails & proprietary > /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you. > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: missing email header
Hi, please keep the current configuration. The Subject header ist typcially configured to be included in dkim signatures. Therefore mangling the subject breaks the signature, which might lead to rejected mails or higher spam scores. Best regards, Fabian On 09.08.20 02:36, Brian Norris wrote: > Hi, > > On Wed, Aug 5, 2020 at 2:21 AM Moritz Warning wrote: >> somehow the titles of the emails from openwrt-devel@ do not contain a title >> prefix anymore. >> They appear to address me personally at first glance, which is a bit >> unsettling. > > FWIW, I see very few other mailing lists mangle the Subject field the > way openwrt-devel used to do it. I have no say in these things, but I > personally prefer it this way. > >> Is this a temporary thing? > > I can't speak for any of that, but it does seem like the change > started around June 21, which happens to be the same weekend when the > machine that hosts the mailing list seems to have gone down with disk > failure: > http://lists.infradead.org/pipermail/linux-mtd/2020-June/081081.html > > I expect the mailing list configuration must have been reset too. > > So in other words, the change may simply be an accident? > > Regards, > Brian > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] malta: Refresh kernel configuration
This refreshes the kernel configuration on top of kernel 5.4. It now builds without asking to select some kernel options on all 4 subtargets. It still does not boot up, there is a different problem. Signed-off-by: Hauke Mehrtens --- target/linux/malta/be/config-default | 8 target/linux/malta/be64/config-default | 7 +-- target/linux/malta/config-5.4 | 9 + target/linux/malta/le/config-default | 9 - target/linux/malta/le64/config-default | 8 +--- 5 files changed, 23 insertions(+), 18 deletions(-) diff --git a/target/linux/malta/be/config-default b/target/linux/malta/be/config-default index 5586be6b7c46..735296f5b3f3 100644 --- a/target/linux/malta/be/config-default +++ b/target/linux/malta/be/config-default @@ -1,4 +1,12 @@ CONFIG_CPU_BIG_ENDIAN=y +CONFIG_CPU_HAS_RIXI=y # CONFIG_CPU_LITTLE_ENDIAN is not set CONFIG_CPU_MIPS32_R2=y +CONFIG_CPU_MIPSR2=y +CONFIG_CPU_SUPPORTS_MSA=y +CONFIG_HAVE_CBPF_JIT=y +CONFIG_HAVE_KVM=y CONFIG_HIGHMEM=y +CONFIG_MIPS_CBPF_JIT=y +CONFIG_MIPS_SPRAM=y +CONFIG_TARGET_ISA_REV=2 diff --git a/target/linux/malta/be64/config-default b/target/linux/malta/be64/config-default index 3792b7fce831..8edef1a8579e 100644 --- a/target/linux/malta/be64/config-default +++ b/target/linux/malta/be64/config-default @@ -9,20 +9,15 @@ CONFIG_CPU_BIG_ENDIAN=y # CONFIG_CPU_LITTLE_ENDIAN is not set CONFIG_CPU_MIPS64=y CONFIG_CPU_MIPS64_R1=y -CONFIG_CPU_MIPSR1=y CONFIG_CPU_SUPPORTS_64BIT_KERNEL=y CONFIG_CPU_SUPPORTS_HUGEPAGES=y -CONFIG_HAVE_64BIT_ALIGNED_ACCESS=y CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y -CONFIG_HAVE_EBPF_JIT=y CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y -# CONFIG_HUGETLBFS is not set +# CONFIG_IONIC is not set # CONFIG_MIPS32_N32 is not set # CONFIG_MIPS32_O32 is not set -CONFIG_MIPS_EBPF_JIT=y # CONFIG_MIPS_VA_BITS_48 is not set CONFIG_MODULES_USE_ELF_RELA=y -CONFIG_PCI_BUS_ADDR_T_64BIT=y CONFIG_PGTABLE_LEVELS=3 CONFIG_PHYS_ADDR_T_64BIT=y CONFIG_SYS_SUPPORTS_HUGETLBFS=y diff --git a/target/linux/malta/config-5.4 b/target/linux/malta/config-5.4 index 865be850cbd6..10ad79548056 100644 --- a/target/linux/malta/config-5.4 +++ b/target/linux/malta/config-5.4 @@ -43,6 +43,7 @@ CONFIG_BOUNCE=y CONFIG_BUILTIN_DTB=y CONFIG_CDROM=y CONFIG_CEVT_R4K=y +# CONFIG_CGROUPS is not set CONFIG_CLKBLD_I8253=y CONFIG_CLKDEV_LOOKUP=y CONFIG_CLKEVT_I8253=y @@ -61,7 +62,7 @@ CONFIG_CPU_HAS_SYNC=y # CONFIG_CPU_MICROMIPS is not set CONFIG_CPU_MIPS32=y # CONFIG_CPU_MIPS32_3_5_FEATURES is not set -CONFIG_CPU_MIPS32_R1=y +# CONFIG_CPU_MIPS32_R1 is not set # CONFIG_CPU_MIPS32_R2 is not set # CONFIG_CPU_MIPS32_R6 is not set # CONFIG_CPU_MIPS64_R1 is not set @@ -99,9 +100,7 @@ CONFIG_DUMMY_CONSOLE=y CONFIG_EFI_EARLYCON=y CONFIG_ENABLE_MUST_CHECK=y CONFIG_EXT4_FS=y -# CONFIG_F2FS_CHECK_FS is not set CONFIG_F2FS_FS=y -# CONFIG_F2FS_FS_SECURITY is not set CONFIG_F2FS_FS_XATTR=y CONFIG_F2FS_STAT_FS=y CONFIG_FONT_8x16=y @@ -173,6 +172,8 @@ CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y CONFIG_HAVE_RSEQ=y CONFIG_HAVE_SYSCALL_TRACEPOINTS=y CONFIG_HW_CONSOLE=y +CONFIG_HZ=250 +CONFIG_HZ_250=y CONFIG_I8253=y CONFIG_I8253_LOCK=y CONFIG_I8259=y @@ -243,7 +244,6 @@ CONFIG_NO_HZ_COMMON=y CONFIG_NO_HZ_IDLE=y CONFIG_NR_CPUS=2 CONFIG_NVMEM=y -# CONFIG_NVMEM_REBOOT_MODE is not set CONFIG_OF=y CONFIG_OF_ADDRESS=y CONFIG_OF_EARLY_FLATTREE=y @@ -285,6 +285,7 @@ CONFIG_RFS_ACCEL=y CONFIG_RPS=y CONFIG_RTC_CLASS=y # CONFIG_RTC_DRV_JZ4740 is not set +CONFIG_RTC_MC146818_LIB=y CONFIG_SCSI=y CONFIG_SECCOMP=y CONFIG_SECCOMP_FILTER=y diff --git a/target/linux/malta/le/config-default b/target/linux/malta/le/config-default index 2b42a6b5b2bf..2c6148195e10 100644 --- a/target/linux/malta/le/config-default +++ b/target/linux/malta/le/config-default @@ -1,4 +1,11 @@ -# CONFIG_CPU_BIG_ENDIAN is not set +CONFIG_CPU_HAS_RIXI=y CONFIG_CPU_LITTLE_ENDIAN=y CONFIG_CPU_MIPS32_R2=y +CONFIG_CPU_MIPSR2=y +CONFIG_CPU_SUPPORTS_MSA=y +CONFIG_HAVE_CBPF_JIT=y +CONFIG_HAVE_KVM=y CONFIG_HIGHMEM=y +CONFIG_MIPS_CBPF_JIT=y +CONFIG_MIPS_SPRAM=y +CONFIG_TARGET_ISA_REV=2 diff --git a/target/linux/malta/le64/config-default b/target/linux/malta/le64/config-default index ff4496382dd1..fd4019c7b38f 100644 --- a/target/linux/malta/le64/config-default +++ b/target/linux/malta/le64/config-default @@ -5,24 +5,18 @@ CONFIG_ARCH_MMAP_RND_BITS=12 CONFIG_ARCH_MMAP_RND_BITS_MAX=18 CONFIG_ARCH_MMAP_RND_BITS_MIN=12 CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y -# CONFIG_CPU_BIG_ENDIAN is not set CONFIG_CPU_LITTLE_ENDIAN=y CONFIG_CPU_MIPS64=y CONFIG_CPU_MIPS64_R1=y -CONFIG_CPU_MIPSR1=y CONFIG_CPU_SUPPORTS_64BIT_KERNEL=y CONFIG_CPU_SUPPORTS_HUGEPAGES=y -CONFIG_HAVE_64BIT_ALIGNED_ACCESS=y CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y -CONFIG_HAVE_EBPF_JIT=y CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y -# CONFIG_HUGETLBFS is not set +# CONFIG_IONIC is not set # CONFIG_MIPS32_N32 is not set # CONFIG_MIPS32_O32 is not set -CONFIG_MIPS_EBPF_JIT=y # CONFIG_MIPS_VA_BITS_48 is not set
[PATCH] kernel: Move CONFIG_IONIC to generic kernel config
It is deactivated everywhere, just set this in the generic config. Signed-off-by: Hauke Mehrtens --- target/linux/armvirt/64/config-5.4 | 1 - target/linux/bcm27xx/bcm2710/config-5.4 | 1 - target/linux/bcm27xx/bcm2711/config-5.4 | 1 - target/linux/generic/config-5.4 | 1 + target/linux/layerscape/armv8_64b/config-5.4 | 1 - target/linux/malta/be64/config-default | 1 - target/linux/malta/le64/config-default | 1 - target/linux/mediatek/mt7622/config-5.4 | 1 - target/linux/mvebu/cortexa53/config-5.4 | 1 - target/linux/octeon/config-5.4 | 1 - target/linux/octeontx/config-5.4 | 1 - target/linux/rockchip/armv8/config-5.4 | 1 - target/linux/x86/64/config-5.4 | 1 - 13 files changed, 1 insertion(+), 12 deletions(-) diff --git a/target/linux/armvirt/64/config-5.4 b/target/linux/armvirt/64/config-5.4 index c69ad8943f59..44d792025bbf 100644 --- a/target/linux/armvirt/64/config-5.4 +++ b/target/linux/armvirt/64/config-5.4 @@ -210,7 +210,6 @@ CONFIG_INLINE_WRITE_LOCK_IRQ=y CONFIG_INLINE_WRITE_LOCK_IRQSAVE=y CONFIG_INLINE_WRITE_UNLOCK_BH=y CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE=y -# CONFIG_IONIC is not set CONFIG_LCD_CLASS_DEVICE=m # CONFIG_LCD_PLATFORM is not set # CONFIG_MEMORY_HOTPLUG is not set diff --git a/target/linux/bcm27xx/bcm2710/config-5.4 b/target/linux/bcm27xx/bcm2710/config-5.4 index b1923da34715..a0dcc9bb46ae 100644 --- a/target/linux/bcm27xx/bcm2710/config-5.4 +++ b/target/linux/bcm27xx/bcm2710/config-5.4 @@ -406,7 +406,6 @@ CONFIG_INPUT_MOUSEDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 -# CONFIG_IONIC is not set CONFIG_IRQCHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y diff --git a/target/linux/bcm27xx/bcm2711/config-5.4 b/target/linux/bcm27xx/bcm2711/config-5.4 index 9c09fb02afca..abaaef5549c1 100644 --- a/target/linux/bcm27xx/bcm2711/config-5.4 +++ b/target/linux/bcm27xx/bcm2711/config-5.4 @@ -412,7 +412,6 @@ CONFIG_INPUT_MOUSEDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 -# CONFIG_IONIC is not set CONFIG_IRQCHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y diff --git a/target/linux/generic/config-5.4 b/target/linux/generic/config-5.4 index 5a00e9eae36b..254429ae5082 100644 --- a/target/linux/generic/config-5.4 +++ b/target/linux/generic/config-5.4 @@ -2344,6 +2344,7 @@ CONFIG_INPUT_MISC=y # CONFIG_INV_MPU6050_IIO is not set # CONFIG_INV_MPU6050_SPI is not set # CONFIG_IOMMU_SUPPORT is not set +# CONFIG_IONIC is not set # CONFIG_IOSCHED_BFQ is not set # CONFIG_IOSCHED_CFQ is not set CONFIG_IOSCHED_DEADLINE=y diff --git a/target/linux/layerscape/armv8_64b/config-5.4 b/target/linux/layerscape/armv8_64b/config-5.4 index 40bf4a9c5c5c..11d88cafe8ce 100644 --- a/target/linux/layerscape/armv8_64b/config-5.4 +++ b/target/linux/layerscape/armv8_64b/config-5.4 @@ -552,7 +552,6 @@ CONFIG_IOMMU_IO_PGTABLE=y CONFIG_IOMMU_IO_PGTABLE_LPAE=y # CONFIG_IOMMU_IO_PGTABLE_LPAE_SELFTEST is not set CONFIG_IOMMU_SUPPORT=y -# CONFIG_IONIC is not set CONFIG_IPC_NS=y # CONFIG_IPMB_DEVICE_INTERFACE is not set # CONFIG_IP_ADVANCED_ROUTER is not set diff --git a/target/linux/malta/be64/config-default b/target/linux/malta/be64/config-default index 8edef1a8579e..e7352e68ee62 100644 --- a/target/linux/malta/be64/config-default +++ b/target/linux/malta/be64/config-default @@ -13,7 +13,6 @@ CONFIG_CPU_SUPPORTS_64BIT_KERNEL=y CONFIG_CPU_SUPPORTS_HUGEPAGES=y CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y -# CONFIG_IONIC is not set # CONFIG_MIPS32_N32 is not set # CONFIG_MIPS32_O32 is not set # CONFIG_MIPS_VA_BITS_48 is not set diff --git a/target/linux/malta/le64/config-default b/target/linux/malta/le64/config-default index fd4019c7b38f..23e838aaba41 100644 --- a/target/linux/malta/le64/config-default +++ b/target/linux/malta/le64/config-default @@ -12,7 +12,6 @@ CONFIG_CPU_SUPPORTS_64BIT_KERNEL=y CONFIG_CPU_SUPPORTS_HUGEPAGES=y CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y -# CONFIG_IONIC is not set # CONFIG_MIPS32_N32 is not set # CONFIG_MIPS32_O32 is not set # CONFIG_MIPS_VA_BITS_48 is not set diff --git a/target/linux/mediatek/mt7622/config-5.4 b/target/linux/mediatek/mt7622/config-5.4 index 92da879a826f..71c5a9588fc3 100755 --- a/target/linux/mediatek/mt7622/config-5.4 +++ b/target/linux/mediatek/mt7622/config-5.4 @@ -374,7 +374,6 @@ CONFIG_INLINE_WRITE_LOCK_IRQ=y CONFIG_INLINE_WRITE_LOCK_IRQSAVE=y CONFIG_INLINE_WRITE_UNLOCK_BH=y CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE=y -# CONFIG_IONIC is not set CONFIG_IO_URING=y CONFIG_IRQCHIP=y CONFIG_IRQ_DOMAIN=y diff --git a/target/linux/mvebu/cortexa53/config-5.4 b/target/linux/mvebu/cortexa53/config-5.4 index c2c55161f66f..cc44f997da90 100644 --- a/target/linux/mvebu/cortexa53/config-5.4 +++
[PATCH] bintuils: Pack libctf-nobfd.so in addition
readelf is linked against this library on MIPS64BE
This fixes a build problem on MIPS64BE.
In addition also explicitly activate it in the configure command.
Fixes: 60f595daab45 ("binutils: update to version 2.34")
Signed-off-by: Hauke Mehrtens
---
package/devel/binutils/Makefile | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/package/devel/binutils/Makefile b/package/devel/binutils/Makefile
index 6ad326efa039..9f7a0724f4f0 100644
--- a/package/devel/binutils/Makefile
+++ b/package/devel/binutils/Makefile
@@ -84,7 +84,8 @@ CONFIGURE_ARGS += \
--target=$(REAL_GNU_TARGET_NAME) \
--enable-shared \
--enable-install-libiberty \
- --enable-install-libbfd
+ --enable-install-libbfd \
+ --enable-install-libctf
define Build/Install
$(call Build/Install/Default)
@@ -106,7 +107,7 @@ endef
define Package/libctf/install
$(INSTALL_DIR) $(1)/usr/lib
- $(CP) $(PKG_INSTALL_DIR)/usr/lib/libctf.so* $(1)/usr/lib/
+ $(CP) $(PKG_INSTALL_DIR)/usr/lib/libctf*.so* $(1)/usr/lib/
endef
define Package/libopcodes/install
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] toolchain: binutils: Fix typo in patch for MIPS64
There was a typo in the patch which breaks compiling binutils on
MIPS63EL.
make[7]: *** No rule to make target 'elf64ltsmip.o', needed by 'ld-new'. Stop.
Fixes: FS#3276
Fixes: 53470bdf3212 ("toolchain/binutils: Add binutils 2.34")
Signed-off-by: Hauke Mehrtens
---
.../2.34/500-Change-default-emulation-for-mips64-linux.patch| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/toolchain/binutils/patches/2.34/500-Change-default-emulation-for-mips64-linux.patch
b/toolchain/binutils/patches/2.34/500-Change-default-emulation-for-mips64-linux.patch
index 24c2afb8be51..455ac0001dd4 100644
---
a/toolchain/binutils/patches/2.34/500-Change-default-emulation-for-mips64-linux.patch
+++
b/toolchain/binutils/patches/2.34/500-Change-default-emulation-for-mips64-linux.patch
@@ -25,7 +25,7 @@
;;
-mips64*el-*-linux-*) targ_emul=elf32ltsmipn32
- targ_extra_emuls="elf32btsmipn32 elf32ltsmip
elf32btsmip elf64ltsmip elf64btsmip"
-+mips64*el-*-linux-*) targ_emul=lf64ltsmip
++mips64*el-*-linux-*) targ_emul=elf64ltsmip
+ targ_extra_emuls="elf32btsmipn32 elf32ltsmipn32
elf32ltsmip elf32btsmip elf64btsmip"
targ_extra_libpath=$targ_extra_emuls
;;
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Policy on BUILD_PATENTED
On Sun, Aug 09, 2020 at 10:55:37AM +0100, Sam Kuper wrote: > On Mon, Aug 03, 2020 at 07:11:13PM +0300, Etienne Champetier wrote: >> Le lun. 3 août 2020 à 00:04, Rosen Penev a écrit : >>> Whenever discussion about patents arise, I usually point to Fedora >>> whose parent company is Red Hat, which is based in the US. There are >>> many things that they do not distribute that OpenWrt does for legal >>> reasons. Should Fedora's practices be mirrored or should a more >>> liberal policy regarding patented functionality be taken? > > For OpenWRT at least, might Debian be a more appropriate exemplar than > Fedora? Unlike Fedora AFAIK, but like OpenWRT, Debian is represented > in some sense by SPI: https://www.spi-inc.org/projects/debian/ . > > The debian-legal mailing list archives can be searched for the > decisions taken by the debian-legal team, and the reasoning behind > those decisions: https://lists.debian.org/debian-legal/ . Here is an example of discussion on that list, that is on a similar topic to the original question in this thread: patent-encumbered software. It also speaks to differences between the Debian and Red Hat policies. (The example is 15 years old, so perhaps not representative of current policy. I'm just giving it as an example.) [The] reason Debian continues to include the mp3 decoder library is that this patent, like so many other software patents, does not appear to be actively enforced. This is the standard Debian uses in deciding whether to distribute the software; Red Hat evidently uses a different standard. Source: https://lists.debian.org/debian-legal/2005/07/msg00082.html -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt's 'procd' now speaks containers
On Fri, Aug 07, 2020 at 02:57:54PM -1000, Paul Spooren wrote:
> On 07.08.20 09:47, Daniel Golle wrote:
> > Dear community,
> >
> > in the past couple of months I've been working on implementing the
> > Open Container Initiative Runtime Specification [1] in procd by
> > extending the already existing support for slim containers ('ujail').
> > As a result, there is now a new CLI tool called 'uxc' which handles
> > the basic operations on containers as defined by the spec [2].
> > This allows to use it as a drop-in replacement for Docker's 'runc'
> > (or 'crun') on OpenWrt hosts with a significantly reduced footprint.
>
> Great news! Thank you very much your work! Due to the high traffic on
> OpenWrt I'm sure a lot of people will miss that email. I'd like to see a
> first usage[1] of openwrt-annouce and also a news bit on the website.
>
> [1]: https://lists.openwrt.org/pipermail/openwrt-announce/
>
> > Examples usage:
> >
> > # install packages
> > opkg install kmod-veth uxc ujail-console
> >
> > # create veth pair for container
> > uci batch < > set network.veth0=device
> > set network.veth0.type='veth'
> > set network.veth0.name='vhost0'
> > set network.veth0.peer_name='virt0'
> > add_list network.lan.ifname='vhost0'
> > set network.virt0=interface
> > set network.virt0.ifname='virt0'
> > set network.virt0.proto='none'
> > # set proto='none' assuming DHCP client inside container
> > # use 'static' otherwise and also set ipaddr, gateway and dns
> > set network.virt0.jail='container1'
> > set network.virt0.jail_ifname='host0'
> > commit network
> > EOF
> >
> > # assuming OCI run-time bundle with config.json in /mnt/sda3/debian
> > uxc create container1 /mnt/sda3/debian true
> > uxc start container1
> >
> > uxc list
> > uxc state container1
> >
> > If the container uses a stdio console, you can attach it using
> > ujail-console -c container1
> > (there is no buffer, so if you like to see the complete bootlog of
> > a container, make sure to attach a console after the 'create' call
> > but before starting it)
> >
> > Roundabout 95% of the OCI run-time spec are supported which should
> > be enough to already make some use or experiments with it and try
> > running common containers (eg. using docker, podman or umoci to
> > prepare an OCI run-time bundle on another host and launch it on
> > OpenWrt).
> >
> >
> > As the OCI spec defines JSON representations of capabilities as well
> > as seccomp filter, my plan is to make use of those (more expressive)
> > formats instead of our current approach to handle capabilities and
> > seccomp filter in 'classic' ujail slim-containers.
> >
> > The conversion from OpenWrt's ujail's vendor
> > JSON schema into the OCI schema is possible easily for both
> > capabilities and seccomp and would have several advantages:
> > * having only one parser
> > * using a well documented specification
> > * having more expressive power (all capability sets can be edited
> > rather than just the boundinng set, seccomp filters can be
> > defined for groups of syscalls with user defined action rather
> > than just having a simple list of allowed calls).
> >
> > If there is everyone agrees, I'd start converting things.
> I've never used it, but I'm all for not brewing our own stew but use what's
> already there.
> > It'd be great to get some feedback and learn about potential needs and
> > use-cases.
>
> I'll give it a test within a qemu VM (doh!).
>
> How complex is a minimal repository client which automatically downloads
> images (layers) from hub.docker.com or registry.gitlab.com?
You would have to implemet the OCI Image Specification as well as
OCI Distribution Specification or port existing tools to OpenWrt
(eg. podman).
Note that OCI Run-Time bundle != OCI Image. So tool needs to fetch
layers from registry (usually using SPDY, but classic 'HTTP' should
work as well afaik), convert AUFS-style whiteouts to overlayfs-style
and generte the OCI Run-Time configuration.
So either we use the existing tooling (mostly written in Go and not
exactly small) or we re-implement also that part using libubox,
blobmsg-json, libuclient, ...
For now, I'd be glad if some of the folks more familiar with Go would
port podman as that would allow people to test and use 'uxc' more
easily.
Cheers
Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Policy on BUILD_PATENTED
Mauro Mozzarelli writes: > On 09/08/2020 03:35, Henrique de Moraes Holschuh wrote: > >> I believe OpenWrt should not even *consider* placing its umbrella >> organization(s) -- which are based on the U.S. -- in legal risk >> without at least contacting them first and getting their approval. >> >> Has anyone asked SPI about it yet? > > Who/What are these "umbrella" organizations? What is their > relationship with OpenWrt? This is answered by the FAQ: https://openwrt.org/faq/general > And what is the "legal risk"? I guess that's the question you should ask the SPI. This is not a technical or a political discussion. It's about not putting your friends at unnecessary risk, even if they happen to live under some regime you don't like or respect. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Policy on BUILD_PATENTED
On 09/08/2020 03:35, Henrique de Moraes Holschuh wrote: On 08/08/2020 17:56, Rosen Penev wrote: On Sat, Aug 8, 2020 at 1:37 PM Mauro Mozzarelli wrote: Since OpenWrt is NOT US Based and in fact it appears to be mostly supported with EU contributions, we should be following the more liberal EU policies. Personally I am against software patents and I campaigned for the decision that the EU parliament took to ban them despite significant lobby from US corporations that would have wanted to limit and monopolize software development. As we know US companies even patent human genome, which is absurd. I happen to agree but IANAL. I am proud of the EU decision and I believe that OpenWrt should be aligned with that spirit. Do you believe that BUILD_PATENTED should be turned on by default? https://github.com/openwrt/openwrt/blob/master/config/Config-build.in#L64 I believe OpenWrt should not even *consider* placing its umbrella organization(s) -- which are based on the U.S. -- in legal risk without at least contacting them first and getting their approval. Has anyone asked SPI about it yet? Who/What are these "umbrella" organizations? What is their relationship with OpenWrt? And what is the "legal risk"? Again, OpenWrt is NOT a US based project. US legislation should not and must not apply. We have already seen what US corporations do to open source software. Nothing good can come out of them. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Policy on BUILD_PATENTED
On Mon, Aug 03, 2020 at 07:11:13PM +0300, Etienne Champetier wrote: > Le lun. 3 août 2020 à 00:04, Rosen Penev a écrit : >> The remerged OpenWrt project is legally represented by the Software >> in the Public Interest (SPI) - an US 501(c)(3) non-profit >> organization which is managing our OpenWrt trademark, handling our >> donations and helping us with legal problems. > > Software Freedom Conservancy (future replacement of SPI) is also US > based > >> Whenever discussion about patents arise, I usually point to Fedora >> whose parent company is Red Hat, which is based in the US. There are >> many things that they do not distribute that OpenWrt does for legal >> reasons. Should Fedora's practices be mirrored or should a more >> liberal policy regarding patented functionality be taken? For OpenWRT at least, might Debian be a more appropriate exemplar than Fedora? Unlike Fedora AFAIK, but like OpenWRT, Debian is represented in some sense by SPI: https://www.spi-inc.org/projects/debian/ . The debian-legal mailing list archives can be searched for the decisions taken by the debian-legal team, and the reasoning behind those decisions: https://lists.debian.org/debian-legal/ . In cases where doubt still remains, OpenWRT devs should probably consult with staff of the SPI (currently, the project liaisons are listed as John Crispin and Imre Kaloz: https://www.spi-inc.org/projects/openwrt/ ) and/or with staff of the Software Freedom Conservancy. IMO, this should be done via a publicly archived mailing list, for transparency. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] package: use PKG_VERSION only for upstream packages
Op 24 feb. 2020, om 17:08 heeft Adrian Schmutzler het volgende geschreven: > > In the package guidelines, PKG_VERSION is supposed to be used > as "The upstream version number that we're downloading", while > PKG_RELEASE is referred to as "The version of this package Makefile". > Thus, the variables in a strict interpretation provide a clear > distinction between "their" (upstream) version in PKG_VERSION and > "our" (local OpenWrt trunk) version in PKG_RELEASE. As still some discussion exists about how to use PKG_VERSION and PKG_RELEASE, currently around local projects, a thought of some time ago might be worth consideration. The wiki states that PKG_RELEASE must be reset to 1 whenever PKG_VERSION is updated [1], which makes it subordinate to the upstream version of the package. Would just keep incrementing PKG_RELEASE not be less entangled (of orthogonal purposes) ? Also, might it be an idea to rename PKG_VERSION to PKG_UPSTREAM_VERSION ? (or something alike but more concise) That would make its meaning much more obvious. [1] https://openwrt.org/docs/guide-developer/package-policies ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC] Policy for PKG_RELEASE bumps
Hi Paul, Following our brief discussion on IRC, here are my remarks again, so others can also comment on them. I'm still pretty new to this packaging stuff, so some arguments may already have been made in the past. On Fri, 2020-08-07 at 12:32 -1000, Paul Spooren wrote: > Hi team, > > currently exist two different ideas on when to raise the PKG_RELEASE > of a package. > > * When functional things change > For example, a OpenWrt specific patch is added > > * When anything inside the packages ipk file changes > Includes patch and so called "cosmetic" changes outside the > Makefile, e.g. replace tabs with spaces. > > While one could argue that following the first approach lowers the > number of non functional updates via `opkg`, it results in packages > with different checksums. To keep track of what is reproducible and > what not, it is very helpful to see changes in PKG_RELEASE. If not, > two seemingly same packages (version/release) have different > checksums. Looking at other distros (Debian [1], Fedora [2]), it appears to be common to reset the equivalent of PGK_RELEASE for every upstream version bump. In OpenWrt it appears to mean [3] "our version since the dawn of times" instead of "our version of this upstream release". I feel that having to bump PKG_RELEASE for each and every commit on a package, wouldn't be a good idea: * It adds an 'unrelated' change to the patch. PGK_RELEASE should be for keeping track of package versions, not so much for keeping track of source versions. * It will probably require maintainers to ask people to bump PGK_RELEASE in their patches over and over again. > The frequent package updates are likely to happen only when using > snapshots, which receives a new firmware on a daily basis anyway. Could snapshot builds use automatic package versioning? This would make sure that not every single patch needs to bump PGK_RELEASE. For example: 1.2.0-1.snapshotXYZ To make sure that version numbers only ever increase, the snapshot version XYZ could be a source timestamp (for that package), or the number of commits in that package. One argument against the latter, is that the package version number would then be related to a commit in a non-obvious way. Fedora for example, uses a DATE.REVISION format for snapshot versions. So their snapshot packages (for that day) may not sort correctly, but will in any case point to a specific commit. If the commit history between a release build and snapshot build is the same, you may want both to have the same package version. So that might be a special case where you don't add a snapshot version tag. Unless you don't mind two package versions pointing to the same code version. The latter would, in my opinion, be less of an issue than a single package version being used for multiple source versions. > Please share your thoughts. If there are no strong arguments against > bumping the PKG_RELEASE on anything that changes the resulting > package content, I'd like to make that a policy. [1] https://readme.phys.ethz.ch/documentation/debian_version_numbers/ [2] https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/ [3] commit 9c170cb92f4fbb316592c11567a080eb3f6a1fc3 -- Best, Sander ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
