Download server is down?

[Hannu Nyman]

Looks like the download server is down, or at least has major trouble (with 
the backend?).


There are several forum discussions about errors like

504 Gateway Time-out

502 Bad Gateway


https://downloads.openwrt.org/releases/



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: RE: Upcoming 19.07.4 and 18.07.9 stable releases

[Hannu Nyman]

I wonder why there seems to be practically no discussion about preparations 
for the 20.0x release (or actually 20.1x now...).


I think that last time it was mentioned in August:

http://lists.openwrt.org/pipermail/openwrt-adm/2020-August/001639.html


Is there any hope for a release, or will 2020 be a lost year?



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Lots of packages fail in buildbot (cryptodev-linux, hostapd, openssl, ...)

[Hannu Nyman]

Notified by forum discussion, I noticed that lots of packages seem to fail to 
build in buildbot.


Faillogs e.g. in

* 
https://downloads.openwrt.org/snapshots/faillogs/arm_cortex-a15_neon-vfpv4/packages/

* https://downloads.openwrt.org/snapshots/faillogs/mipsel_24kc/packages/
* https://downloads.openwrt.org/snapshots/faillogs/mipsel_24kc/base/
* 
https://downloads.openwrt.org/snapshots/faillogs/arm_cortex-a9_vfpv3-d16/packages/

* https://downloads.openwrt.org/snapshots/faillogs/x86_64/base/

The problem seems not to be tied to a specific architecture, as there are 
major failures in x86, arm and mips.


Due to the large number of failures it is hard to find what is the ultimate 
culprit in the dependency chain, but cryptodev-linux failure leads into 
openssl and hostapd failing, cascading to lots of packages.


Nothing obvious jumps from the commits logs, but there have been several 
build system targeting patches from @nbd in the last 1-2 days.




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Lots of packages fail in buildbot (cryptodev-linux, hostapd, openssl, ...)

[Hannu Nyman]

Rosen Penev kirjoitti 15.11.2020 klo 12.21:

On Sun, Nov 15, 2020 at 2:15 AM Hannu Nyman  wrote:

Notified by forum discussion, I noticed that lots of packages seem to fail to
build in buildbot.

Faillogs e.g. in

*
https://downloads.openwrt.org/snapshots/faillogs/arm_cortex-a15_neon-vfpv4/packages/
* https://downloads.openwrt.org/snapshots/faillogs/mipsel_24kc/packages/
* https://downloads.openwrt.org/snapshots/faillogs/mipsel_24kc/base/
*
https://downloads.openwrt.org/snapshots/faillogs/arm_cortex-a9_vfpv3-d16/packages/
* https://downloads.openwrt.org/snapshots/faillogs/x86_64/base/

The problem seems not to be tied to a specific architecture, as there are
major failures in x86, arm and mips.

Due to the large number of failures it is hard to find what is the ultimate
culprit in the dependency chain, but cryptodev-linux failure leads into
openssl and hostapd failing, cascading to lots of packages.

Nothing obvious jumps from the commits logs, but there have been several
build system targeting patches from @nbd in the last 1-2 days.

It's all kmods that fail.



Might be related to symvers handling by:

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=5d7606562940b52206712bb4bc274ad39521c3e1

E.g. cryptodev-linux fails like:  `cryptodev-linux.symvers: No such file or 
directory`



make[4]: Leaving directory 
'/builder/shared-workdir/build/sdk/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-armvirt_32/cryptodev-linux-cryptodev-linux-1.10'
mv: cannot move 
'/builder/shared-workdir/build/sdk/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-armvirt_32/cryptodev-linux-cryptodev-linux-1.10/Module.symvers' 
to 
'/builder/shared-workdir/build/sdk/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-armvirt_32/symvers/cryptodev-linux.symvers': 
No such file or directory
Makefile:58: recipe for target 
'/builder/shared-workdir/build/sdk/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-armvirt_32/cryptodev-linux-cryptodev-linux-1.10/.built' 
failed



And exfat fails:

mv: cannot move 
'/builder/shared-workdir/build/sdk/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-armvirt_32/exfat-5.8.7/Module.symvers'
 to 
'/builder/shared-workdir/build/sdk/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-armvirt_32/symvers/exfat.symvers':
 No such file or directory
Makefile:47: recipe for target 
'/builder/shared-workdir/build/sdk/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-armvirt_32/exfat-5.8.7/.built'
 failed


That commit moved the `mkdir -p $(PKG_SYMVERS_DIR)` step and removed 
Module.symvers creation.


Possibly in a way that buildbot does not like  (although the build may 
succeed on a unified build process in a local buildhost).





___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] build: create $(PKG_SYMVERS_DIR) if non-existent

[Hannu Nyman]

Paul Spooren wrote at Tue Nov 17 16:53:29 EST 2020:
> Could you please provide an example when that fails? E.g. what package
> makes the SDK copy things there?

Pretty much all kernel related packages, like I already disgnosed a few days 
ago in

http://lists.openwrt.org/pipermail/openwrt-devel/2020-November/032115.html

Examples that I used then were cryptodev-linux and exfat.

Buildbot has been broken regarding the kernel packages for the last 3-4 days.

Kernel packages failing cause then carnage with other packages

https://downloads.openwrt.org/snapshots/faillogs/x86_64/base/
https://downloads.openwrt.org/snapshots/faillogs/x86_64/packages/



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v4] build: create $(PKG_SYMVERS_DIR) if non-existent

[Hannu Nyman]

Sebastian Kemper kirjoitti 18.11.2020 klo 23.58:

Commit 5d76065 moved the creation of the symvers directory to
include/kernel-build.mk. This is fine when building from scratch. But
when unpacking an SDK the directory doesn't exist and because the kernel
won't be built (again) this directory will not be created by the build
system, causing build failure if make tries to copy files into it.

This moves the creation of the symvers directory back into
include/kernel.mk so that the directory is created in any case.


Hopefully somebody with commit rights soon merges a version of the patch, as 
popular packages like openvpn and openssl have now been unavailable for 
almost a week (since last Friday) for users who try to install them with opkg 
or use them in imagebuilder.




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: running custom commands during sysupgrade -

[Hannu Nyman]

Adrian Schmutzler wrote at Fri Oct 16 19:15:38 EDT 2020:

> Fortunately, and I don't fully understand why, we were able to drive this 
to effectively zero by simply running

> echo 3 > /proc/sys/vm/drop_caches
> directly before sysupgrade. Out of a few hundred upgrades since then, I 
haven't had a single soft-brick. I do occasionally have the situation that 
the device reboots into the old firmware again (i.e. upgrade failed in an 
early stage), but for some reason the soft-bricks were completely gone.


I have stumbled into similar "boot to the old firmware" symptom with my old 
WNDR3700v2 with 64 MB RAM.
I have not been able to reproduce the problem in WNDR3800 that has 128 MB RAM 
but it otherwise identical, (and has serial cable connected).


Sysupgrade in WNDR3700v2 used to regularly
* fail, if sysupgrade was run after the router had been running a few days
* succeed with the same image, when sysupgrade was re-run right after the 
first failure (and automatic reboot)


To avoid failure I have patched the sysupgrade script components itself, and 
I have not seen the problem any more. Patched files are 
/lib/upgrade/common.sh and /lib/upgrade/stage2


I am not sure if those insertion locations are quite optimal, but so far the 
approach has worked



--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -297,6 +297,7 @@ indicate_upgrade() {
 # $(2): (optional) pipe command to extract firmware, e.g. dd bs=n skip=m
 default_do_upgrade() {
 sync
+    echo 3 > /proc/sys/vm/drop_caches
 if [ -n "$UPGRADE_BACKUP" ]; then
     get_image "$1" "$2" | mtd $MTD_ARGS $MTD_CONFIG_ARGS -j 
"$UPGRADE_BACKUP" write - "${PART_NAME:-image}"

 else
--- a/package/base-files/files/lib/upgrade/stage2
+++ b/package/base-files/files/lib/upgrade/stage2
@@ -123,6 +123,7 @@ kill_remaining KILL 1

 sleep 1

+echo 3 > /proc/sys/vm/drop_caches

 if [ -n "$IMAGE" ] && type 'platform_pre_upgrade' >/dev/null 2>/dev/null; then
 platform_pre_upgrade "$IMAGE"


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] base-files: flush kernel memory cache during sysupgrade

[Hannu Nyman]

Flush kernel memory caches during sysupgrade in order
to mitigate the impact from memory consumption spikes
in low-RAM devices.

This may help to prevent sysupgrade causing a reboot
before the actual flashing starts.

Signed-off-by: Hannu Nyman 
---

I have noticed this to help in 64 MB WNDR3700v2, where sysupgrade
typically has failed when the router has been running some time,
but succeeded when sysupgrade is done right after a reboot.

The cache flushing is non-destructive and as the router is going
to sysupgrade, there aren't "long-term" performance issues.

Reference to mailing list discussion in 
http://lists.openwrt.org/pipermail/openwrt-devel/2020-November/032266.html

Kernel documentation:
https://www.kernel.org/doc/Documentation/sysctl/vm.txt


 package/base-files/files/lib/upgrade/common.sh | 1 +
 package/base-files/files/lib/upgrade/stage2| 1 +
 2 files changed, 2 insertions(+)

diff --git a/package/base-files/files/lib/upgrade/common.sh 
b/package/base-files/files/lib/upgrade/common.sh
index a5c27dc2fb..b44a5998f4 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -297,6 +297,7 @@ indicate_upgrade() {
 # $(2): (optional) pipe command to extract firmware, e.g. dd bs=n skip=m
 default_do_upgrade() {
sync
+   echo 3 > /proc/sys/vm/drop_caches
if [ -n "$UPGRADE_BACKUP" ]; then
get_image "$1" "$2" | mtd $MTD_ARGS $MTD_CONFIG_ARGS -j 
"$UPGRADE_BACKUP" write - "${PART_NAME:-image}"
else
diff --git a/package/base-files/files/lib/upgrade/stage2 
b/package/base-files/files/lib/upgrade/stage2
index c7629c383f..23d356a447 100755
--- a/package/base-files/files/lib/upgrade/stage2
+++ b/package/base-files/files/lib/upgrade/stage2
@@ -123,6 +123,7 @@ kill_remaining KILL 1
 
 sleep 1
 
+echo 3 > /proc/sys/vm/drop_caches
 
 if [ -n "$IMAGE" ] && type 'platform_pre_upgrade' >/dev/null 2>/dev/null; then
platform_pre_upgrade "$IMAGE"
-- 
2.27.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

What happened to 18.06.9? (Re: Upcoming 19.07.4 and 18.07.9 stable releases

[Hannu Nyman]

*Hauke Mehrtens* wrote on /Tue Nov 10 18:58:52 EST 2020:
/

/> /Currently 18.06 looks good for me and I would really like to do the final 
release and call it then officially end of life. I would wait for the build 
bot results and then do it at the weekend.



What happened to 18.06.9?
It was tagged and built over two weeks ago, but was never officially released?
(no trace of it in either forum, mailing list or 
https://downloads.openwrt.org/*  )*



Ps. Is 18.06 now EoL ?



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] tools: zlib: fix broken compile with ccache enabled

[Hannu Nyman]

Rosen Penev kirjoitti 18.12.2020 klo 3.25:

On Thu, Dec 17, 2020 at 5:15 PM  wrote:

On Thu, Dec 17, 2020 at 4:13 PM  wrote:




-Messaggio originale-
Da: Ansuel Smith 
Inviato: venerdì 18 dicembre 2020 00:59
A: OpenWrt Development List 
Cc: Ansuel Smith 
Oggetto: [PATCH] tools: zlib: fix broken compile with ccache enabled

If ccache is enabled with an empty buildroot the compilation fails. Fix
this by using the NOCACHE compiler as it's done by other tools package.

Signed-off-by: Ansuel Smith 
---
  tools/zlib/Makefile | 1 +
  1 file changed, 1 insertion(+)

diff --git a/tools/zlib/Makefile b/tools/zlib/Makefile
index 279851f..5dc311d 100644
--- a/tools/zlib/Makefile
+++ b/tools/zlib/Makefile
@@ -22,6 +22,7 @@ PKG_CPE_ID:=cpe:/a:gnu:zlib
  include $(INCLUDE_DIR)/host-build.mk
  include $(INCLUDE_DIR)/cmake.mk

+CMAKE_HOST_C_COMPILER:=$(HOSTCC_NOCACHE)
  HOST_CFLAGS +=-fPIC

  define Host/Install
--
2.29.2

Ignore, it seems it cause other problem with cmake?

You're missing -D and CMAKE_HOST_OPTIONS.

I submitted a patch that fixes this. Tested on Fedora 33.

I'm testing this with the other package. I could be very wrong but it
seems that ccache is just broken with cmake. My current implementation
is a variable CMAKE_NOCCACHE that disable the use of ccache for that
package. For now I found that this is needed for both the host build and the
pkg build. (libubox, opkg, libjson-c affected) Can you check if you can
compile that package with not problem with your implementation. Just
to make sure I'm not making things wrong.

Looks like this is not right either.

That cmake bump is what broke ccache.

More info: 
https://github.com/openwrt/openwrt/commit/bfc433efd4a0c6875a92981d1bd2a5e3e60c61c6#commitcomment-45228331



Note that we are also using an outdated version of ccache.

ccache has last been updated to version 3.7.11 in August 2020 (by me).

There is now already version 4.1 of ccache available.
That might possibly help with zlib.

Release notes of ccache 4.0 an 4.1 contain some cmake references.
https://ccache.dev/releasenotes.html#_ccache_4_1



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] ath10k-ct-firmware: update to 022

[Hannu Nyman]

DENG Qingfang wrote at Wed Nov 25 22:36:26 EST 2020:


Signed-off-by: DENG Qingfang https://lists.openwrt.org/mailman/listinfo/openwrt-devel>>
---
  package/firmware/ath10k-ct-firmware/Makefile | 68 ++--
  1 file changed, 34 insertions(+), 34 deletions(-)

diff --git a/package/firmware/ath10k-ct-firmware/Makefile 
b/package/firmware/ath10k-ct-firmware/Makefile
index cdfd3fb940..1733f53a5b 100644
--- a/package/firmware/ath10k-ct-firmware/Makefile
+++ b/package/firmware/ath10k-ct-firmware/Makefile
@@ -1,8 +1,8 @@
  include $(TOPDIR)/rules.mk
  
  PKG_NAME:=ath10k-ct-firmware

-PKG_VERSION:=2020-07-02
-PKG_RELEASE:=2
+PKG_VERSION:=2020-11-08
+PKG_RELEASE:=1
  
  include $(INCLUDE_DIR)/package.mk
  
@@ -95,120 +95,120 @@ define Download/ct-firmware-htt

URL_FILE:=$($(1)_FIRMWARE_FILE_CT_HTT)
  endef



I briefly tested your ath10k-ct firmware blob version bump and the new 
version 022 seems to work ok in ipq806x/R7800 with QCA9984.


However, as the ath10k-ct-firmware Makefile has changed in the meanwhile due 
to commit 655091ec45 by noltari, your patch does not apply cleanly any more. 
You should perhaps rebase it.




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCHv3] ccache: update to 4.1

[Hannu Nyman]

Rosen Penev kirjoitti 23.12.2020 klo 8.33:

Upstream switched to building with CMake. Adjust accordingly.

Reapplied patch as upstream changed the file format.

Added HOST_BUILD_PARALLEL for faster compilation.

Added cmake tool dependency.

Adjusted dependent tools to use NOCACHE as they are needed to build
ccache.

Signed-off-by: Rosen Penev 
---
  v3: zstd was missing in the commit for some reason
  v2: fix compilation issues without OS tools.
  tools/Makefile  |  1 +
  tools/ccache/Makefile   | 17 +
  tools/ccache/patches/100-honour-copts.patch | 20 ++--
  tools/libressl/Makefile |  1 +
  tools/pkgconf/Makefile  |  2 ++
  tools/zstd/Makefile |  1 +
  6 files changed, 24 insertions(+), 18 deletions(-)

diff --git a/tools/Makefile b/tools/Makefile
index c66d4fb991..316ffb5ea6 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -82,6 +82,7 @@ endif
  ifneq ($(CONFIG_CCACHE)$(CONFIG_SDK),)
  $(foreach tool, $(filter-out xz patch,$(tools-y)), $(eval 
$(curdir)/$(tool)/compile += $(curdir)/ccache/compile))
  tools-y += ccache
+$(curdir)/ccache/compile := $(curdir)/cmake/compile $(curdir)/zstd/compile
  endif
  
  # in case there is no patch tool on the host we need to make patch tool a




I am not sure if that is right. The v3 patch may create a circular dependency.

* First, on line 83 all tools except xz and patch (and flock, sed and tar 
that are later handled separately) are marked to depend on ccache. This 
includes cmake.


* Then the new addition to the next line makes ccache to depend on cmake.

Sounds circular to me.


Maybe we need to filter out also cmake on line 83 (in addition to xz and patch).



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCHv3] ccache: update to 4.1

[Hannu Nyman]

Rosen Penev kirjoitti 23.12.2020 klo 10.14:

On Tue, Dec 22, 2020 at 11:53 PM Hannu Nyman  wrote:

Rosen Penev kirjoitti 23.12.2020 klo 8.33:

Upstream switched to building with CMake. Adjust accordingly.

Reapplied patch as upstream changed the file format.

Added HOST_BUILD_PARALLEL for faster compilation.

Added cmake tool dependency.

Adjusted dependent tools to use NOCACHE as they are needed to build
ccache.

Signed-off-by: Rosen Penev 
---
   v3: zstd was missing in the commit for some reason
   v2: fix compilation issues without OS tools.
   tools/Makefile  |  1 +
   tools/ccache/Makefile   | 17 +
   tools/ccache/patches/100-honour-copts.patch | 20 ++--
   tools/libressl/Makefile |  1 +
   tools/pkgconf/Makefile  |  2 ++
   tools/zstd/Makefile |  1 +
   6 files changed, 24 insertions(+), 18 deletions(-)

diff --git a/tools/Makefile b/tools/Makefile
index c66d4fb991..316ffb5ea6 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -82,6 +82,7 @@ endif
   ifneq ($(CONFIG_CCACHE)$(CONFIG_SDK),)
   $(foreach tool, $(filter-out xz patch,$(tools-y)), $(eval 
$(curdir)/$(tool)/compile += $(curdir)/ccache/compile))
   tools-y += ccache
+$(curdir)/ccache/compile := $(curdir)/cmake/compile $(curdir)/zstd/compile
   endif

   # in case there is no patch tool on the host we need to make patch tool a


I am not sure if that is right. The v3 patch may create a circular dependency.

That doesn't seem to be the case.

make tools/ccache/compile works perfectly fine with build/staging_dir removed.



Did you also test after make dirclean? So that there are no tools.




Without that addition, ccache will not compile. Removing that line and
moving the tool names up to line 83 also does not compile.



Hmm... "tool names" ???

I proposed (below) adding cmake to this filter list "$(filter-out xz 
patch,$(tools-y))".


That would make cmake not to depend on ccache. And then you can quite nicely 
set ccache to depend on cmake on the next line





* First, on line 83 all tools except xz and patch (and flock, sed and tar
that are later handled separately) are marked to depend on ccache. This
includes cmake.

* Then the new addition to the next line makes ccache to depend on cmake.

Sounds circular to me.


Maybe we need to filter out also cmake on line 83 (in addition to xz and patch).




Something like this (I also added zstd in the exclusion list, as ccache now 
depends on it):



  $(foreach tool, $(filter-out xz patch cmake zstd,$(tools-y)), $(eval 
$(curdir)/$(tool)/compile += $(curdir)/ccache/compile))
  tools-y += ccache
+$(curdir)/ccache/compile := $(curdir)/cmake/compile $(curdir)/zstd/compile


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Please revert 98b86296e6 as it breaks several ipq806x devices

[Hannu Nyman]

Please revert commit 98b86296e6 "ipq806x: add support for ASRock G10" as it 
breaks several popular ipq806x devices.


98b86296e6 adds a new kernel config symbol CONFIG_CMDLINE_OVERRIDE for 
ipq806x and enables it for all ipq806x devices.


Based on forum discussion and my own experience, that new symbol apparently 
changes the kernel command line and breaks several ipq806x devices. Either 
the devices do not boot or there are other symptoms.



Symptoms in my own R7800:

* serial console is disabled. It works during u-boot but is silent after 
kernel takes over  (as console gets assigned to wrong tty)


* sysupgrade FROM builds with commit 98b86296e6 included does not work. 
Debugging that is not feasible, as serial console is broken...




Bug report in:

https://bugs.openwrt.org/index.php?do=details&task_id=3540

and in

https://github.com/openwrt/openwrt/commit/98b86296e67dd2b467212fe1a577656e6d3725da#commitcomment-45455875


Things get fixed by reverting the kernel symbol part from 98b86296e6:


|--- a/target/linux/ipq806x/config-5.4 +++ b/target/linux/ipq806x/config-5.4 
@@ -78,7 +78,7 @@ CONFIG_CC_HAS_KASAN_GENERIC=y CONFIG_CLKDEV_LOOKUP=y 
CONFIG_CLKSRC_QCOM=y CONFIG_CLONE_BACKWARDS=y -CONFIG_CMDLINE_OVERRIDE=y +# 
CONFIG_CMDLINE_OVERRIDE is not set CONFIG_COMMON_CLK=y 
CONFIG_COMMON_CLK_QCOM=y CONFIG_COMPAT_32BIT_TIME=y|





___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Please revert 98b86296e6 as it breaks several ipq806x devices

[Hannu Nyman]

Christian Lamparter kirjoitti 28.12.2020 klo 16.59:

On 28/12/2020 15:27, Adrian Schmutzler wrote:

-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
On Behalf Of Hannu Nyman
Sent: Montag, 28. Dezember 2020 10:12
To: OpenWrt Development List 
Cc: Petr Štetiar ; Christian Lamparter

Subject: Please revert 98b86296e6 as it breaks several ipq806x devices


https://github.com/openwrt/openwrt/commit/57e4cc8261ca6f0b32e4da6922a8f52ef82c4dc6 



This is meant as an emergency measure (thus no "Fixes"), and should be 
properly addressed at some point.




hmm, the R7800 must have some crazy bootargs-overrides when these
impact sysupgrade as well. Let's hope there isn't an issue with
the platform.sh + asrock.sh changes.

@hannu: can you please post your R7800's /proc/device-tree/chosen/ files 
(name + content)

for reference?

Cheers
Christian



There aren't that many files (like Adrian already said).

This is the contents in r15359-2160a9d597 with that offending kernel symbol 
disabled:


root@router1:~# ls -l /proc/device-tree/chosen/
-r--r--r--    1 root root 1 Dec 28 17:05 bootargs
-r--r--r--    1 root root    25 Dec 28 17:05 bootloader-args
-r--r--r--    1 root root 7 Dec 28 17:05 name
-r--r--r--    1 root root    17 Dec 28 17:05 stdout-path

root@router1:~# cat /proc/device-tree/chosen/bootargs

root@router1:~# cat /proc/device-tree/chosen/bootloader-args
console=ttyHSL1,115200n8

root@router1:~# cat /proc/device-tree/chosen/name
chosen

root@router1:~# cat /proc/device-tree/chosen/stdout-path
serial0:115200n8


Also the cmdline in /proc is empty

root@router1:~# cat /proc/cmdline



Note that in the "normal" situation, the bootlog says that the 
bootloader-args get ignored:


[    0.00] Bootloader command line (ignored): console=ttyHSL1,115200n8

Apparently the introduction and enabling of CONFIG_CMDLINE_OVERRIDE causes 
that faulty(?) line from bootloader-args to get applied, while it gets 
normally ignored.


No detailed idea why sysupgrade failed, but I suspect that it may somehow tie 
to the console tty being wrong.


I got first notified about that sysupgrade problem in forum discussion, and 
then yesterday I tested it by myself.

A few messages at https://forum.openwrt.org/t/build-for-netgear-r7800/316/2753

I would need to reflash a faulty build to see the problem again more 
closely...  (But that would only make sense if you have good ideas how/what 
to debug without serial console)




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Please revert 98b86296e6 as it breaks several ipq806x devices

[Hannu Nyman]

Christian Lamparter kirjoitti 28.12.2020 klo 16.59:

On 28/12/2020 15:27, Adrian Schmutzler wrote:

-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
On Behalf Of Hannu Nyman
Sent: Montag, 28. Dezember 2020 10:12
To: OpenWrt Development List 
Cc: Petr Štetiar ; Christian Lamparter

Subject: Please revert 98b86296e6 as it breaks several ipq806x devices


https://github.com/openwrt/openwrt/commit/57e4cc8261ca6f0b32e4da6922a8f52ef82c4dc6 



This is meant as an emergency measure (thus no "Fixes"), and should be 
properly addressed at some point.




hmm, the R7800 must have some crazy bootargs-overrides when these
impact sysupgrade as well. Let's hope there isn't an issue with
the platform.sh + asrock.sh changes.

@hannu: can you please post your R7800's /proc/device-tree/chosen/ files 
(name + content)

for reference?

Cheers
Christian



I did some further debugging, and noticed something.

In short: Possibly the definition of CONFIG_CMDLINE_OVERRIDE has been placed 
into a slightly wrong place in arch/arm/Kconfig.



I compared the kernel build log with the working code (without 
CONFIG_CMDLINE_OVERRIDE=y) to log with the faulty code, and there is only a 
small difference:


In the faulty version, there is a one-line warning:
  warning: override: CMDLINE_OVERRIDE changes choice state

context:

  HOSTCC  scripts/kconfig/symbol.o
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf  --syncconfig Kconfig
net/sched/Kconfig:45: warning: menuconfig statement without prompt
.config:987:warning: override: CMDLINE_OVERRIDE changes choice state
  HOSTCC  scripts/dtc/dtc.o


So, the new option changes something else.

I looked at 
build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/linux-5.4.85/arch/arm/Kconfig 
and noticed that the new definition of CONFIG_CMDLINE_OVERRIDE has been 
placed into end of a multi-option choice block. Enabling this option may now 
change the selected value of the choice of ARM_ATAG_DTB_COMPAT_CMDLINE... 
options.




choice
    prompt "Kernel command line type" if ARM_ATAG_DTB_COMPAT
    default ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER

config ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER
    bool "Use bootloader kernel arguments if available"
    help
  Uses the command-line options passed by the boot loader instead of
  the device tree bootargs property. If the boot loader doesn't provide
  any, the device tree bootargs property will be used.

config ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND
    bool "Extend with bootloader kernel arguments"
    help
  The command-line arguments provided by the boot loader will be
  appended to the the device tree bootargs property.

config ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE
    bool "Append rootblock parsing bootloader's kernel arguments"
    help
  The command-line arguments provided by the boot loader will be
  appended to a new device tree property: bootloader-args.
  If there is a property "append-rootblock" in DT under /chosen
  and a root= option in bootloaders command line it will be parsed
  and added to DT bootargs with the form: XX.
  Only command line ATAG will be processed, the rest of the ATAGs
  sent by bootloader will be ignored.

config CMDLINE_OVERRIDE
    bool "Use alternative cmdline from device tree"
    help
  Some bootloaders may have uneditable bootargs. While CMDLINE_FORCE can
  be used, this is not a good option for kernels that are shared across
  devices. This setting enables using "chosen/cmdline-override" as the
  cmdline if it exists in the device tree.

endchoice

config CMDLINE
    string "Default kernel command string"
    default ""
    help
  On some architectures (EBSA110 and CATS), there is currently no way


Apparently the new selected option inside the ARM_ATAG_DTB_COMPAT_CMDLINE... 
choice block changes the selection of the existing options, causing bugs to 
devices depending on those selections. Asrock router apparently is not 
affected by that change, so it works ok.


Possibly the new definition should be after the "endchoice" line, so that 
ARM_ATAG_DTB_COMPAT_CMDLINE things do not change.


Or possibly it should be inside the next choice block about CMDLINE:


config CMDLINE
    string "Default kernel command string"
    default ""
    help
  On some architectures (EBSA110 and CATS), there is currently no way
  for the boot loader to pass arguments to the kernel. For these
  architectures, you should supply some command-line options at build
  time by entering them here. As a minimum, you should specify the
  memory size and the root device (e.g., mem=64M root=/dev/nfs).

choice

Re: Please revert 98b86296e6 as it breaks several ipq806x devices

[Hannu Nyman]

Hannu Nyman kirjoitti 31.12.2020 klo 14.32:

...

I did some further debugging, and noticed something.

In short: Possibly the definition of CONFIG_CMDLINE_OVERRIDE has been 
placed into a slightly wrong place in arch/arm/Kconfig.



I compared the kernel build log with the working code (without 
CONFIG_CMDLINE_OVERRIDE=y) to log with the faulty code, and there is only a 
small difference:


In the faulty version, there is a one-line warning:
  warning: override: CMDLINE_OVERRIDE changes choice state

context:

  HOSTCC  scripts/kconfig/symbol.o
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf  --syncconfig Kconfig
net/sched/Kconfig:45: warning: menuconfig statement without prompt
.config:987:warning: override: CMDLINE_OVERRIDE changes choice state
  HOSTCC  scripts/dtc/dtc.o


So, the new option changes something else.

I looked at 
build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/linux-5.4.85/arch/arm/Kconfig 
and noticed that the new definition of CONFIG_CMDLINE_OVERRIDE has been 
placed into end of a multi-option choice block. Enabling this option may 
now change the selected value of the choice of 
ARM_ATAG_DTB_COMPAT_CMDLINE... options.

...

Possibly the new definition should be after the "endchoice" line, so that 
ARM_ATAG_DTB_COMPAT_CMDLINE things do not change.


Or possibly it should be inside the next choice block about CMDLINE



One more observation: The faulty Asrock commit's commit messages says:

 - 900-arm-add-cmdline-override.patch was copied from 
102-powerpc-add-cmdline-override.patch from powerpc target.


But looking at

https://github.com/openwrt/openwrt/blob/master/target/linux/mpc85xx/patches-5.4/102-powerpc-add-cmdline-override.patch

shows that there the code there is apparently placed outside any choice 
block, just before "config EXTRA_TARGETS"



So, looks like the author has accidentally placed the block into inside a 
choice block and it has worked for him.



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Please revert 98b86296e6 as it breaks several ipq806x devices

[Hannu Nyman]

Paweł Dembicki kirjoitti 31.12.2020 klo 23.42:


Thanks Hannu for the inspection. It was a great job. Kconfig entry was
misplaced after rebase in the early stage of my work.

I moved it to the proper place. Patches are placed on my github fork:
https://github.com/CHKDSK88/openwrt-1/tree/asrock_g10

Could You check if everything is ok?

Best regards,
Pawel Dembicki



I compiled a new version for R7800 with your two patches, and it worked ok:
Serial console worked normally and sysupgrading from the build was possible.

So, I think that you patches are ok.
I can't verify that for the other affected devices, but I see no reason to 
believe that this would not fix them, too.



Patches used:

https://github.com/CHKDSK88/openwrt-1/commit/5dc46ebfd98760c73480e9e9f37bc11c34f5dfb7 



https://github.com/CHKDSK88/openwrt-1/commit/acd06bbba9982430bd750682d83d892fae0dfd8a


One style issue:

Your added definition block in 5dc46ebf uses spaces for indentation, while 
the normal way is to use tab for the first level indentation and then add 2 
spaces for the help text. This leads to visible difference in Kconfig. No 
functional problem, but deviation from the expected style.



Ps.

As further proof that your patch is ok, here is a comparison of the failing 
kernel config to a working one (with your original changes but the override 
symbol disabled). Note that in addition to the override option, also 
CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE changes, which led to problems with 
other ipq806x devices:


perus@ub2010:/Openwrt/r7800$ diff -u okbuild/.config wrongpatch/.config
--- okbuild/.config    2021-01-01 11:48:20.064981146 +0200
+++ wrongpatch/.config    2021-01-01 12:10:41.099499307 +0200
@@ -460,8 +460,8 @@
 CONFIG_ARM_ATAG_DTB_COMPAT=y
 # CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER is not set
 # CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
-CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE=y
-# CONFIG_CMDLINE_OVERRIDE is not set
+# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE is not set
+CONFIG_CMDLINE_OVERRIDE=y
 CONFIG_CMDLINE=""
 CONFIG_CRASH_DUMP=y
 # CONFIG_AUTO_ZRELADDR is not set


After applying your new fixes only the override symbol gets toggled, but no 
ATAG option change any more:


perus@ub2010:/Openwrt/r7800$ diff -u okbuild/.config testpatch/.config
--- okbuild/.config    2021-01-01 11:48:20.064981146 +0200
+++ testpatch/.config    2021-01-01 11:58:05.689147939 +0200
@@ -461,7 +461,7 @@
 # CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER is not set
 # CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
 CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE=y
-# CONFIG_CMDLINE_OVERRIDE is not set
+CONFIG_CMDLINE_OVERRIDE=y
 CONFIG_CMDLINE=""
 CONFIG_CRASH_DUMP=y
 # CONFIG_AUTO_ZRELADDR is not set



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 2/2] base-files: replace PKG_RELEASE with findrev

[Hannu Nyman]

Paul Spooren kirjoitti 2.1.2021 klo 2.22:

The newly added `findrev` function does automatic versioning based on
Git commits of the package. Replace tedious to bump and merge conflict
causing `PKG_RELEASE` and replace it with `findrev`.



Sounds reasonable for me.

The PKG_RELEASE in base-files has too often been forgotten to be changed. In 
years 2019-2020 the base-files package was changed by 150 commits, while the 
PKG_RELEASE version was bumped only 45 times (from 196 to 244). There is a 
REVISION suffix added, which provides some versioning, but it is still bad 
practice that the main release number is usually forgotten. Better to replace 
version with automatics, as the base-files release number is not meaningful 
in any case.


The automatic commit date based versioning has worked well in LuCI, where 
this 'findrev' function is being copied from.




CC: Adrian Schmutzler 

Signed-off-by: Paul Spooren 
---
  package/base-files/Makefile | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/package/base-files/Makefile b/package/base-files/Makefile
index da3976424f..8342dd2f20 100644
--- a/package/base-files/Makefile
+++ b/package/base-files/Makefile
@@ -12,7 +12,6 @@ include $(INCLUDE_DIR)/version.mk
  include $(INCLUDE_DIR)/feeds.mk
  
  PKG_NAME:=base-files

-PKG_RELEASE:=244
  PKG_FLAGS:=nonshared
  
  PKG_FILE_DEPENDS:=$(PLATFORM_DIR)/ $(GENERIC_PLATFORM_DIR)/base-files/

@@ -40,7 +39,7 @@ define Package/base-files
DEPENDS:=+netifd +libc +jsonfilter +SIGNED_PACKAGES:usign 
+SIGNED_PACKAGES:openwrt-keyring +NAND_SUPPORT:ubi-utils +fstools +fwtool
TITLE:=Base filesystem for OpenWrt
URL:=http://openwrt.org/
-  VERSION:=$(PKG_RELEASE)-$(REVISION)
+  VERSION:=$(call findrev)
  endef
  
  define Package/base-files/conffiles




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCHv2 2/3] busybox: update to 1.33

[Hannu Nyman]

Rosen Penev kirjoitti 4.1.2021 klo 5.32:

Remove stime backport.

Remove static libgcc patch as upstream fixed it with
BUSYBOX_DEFAULT_STATIC_LIBGCC which defauls to off.

Remove date -k patch as it no longer applies. It's also pointless as
busybox' hwclock utility can do the same thing.

Remove ntpd patch as that seems to have been applied upstream.

Add smalll patch fixing compilation with SELinux. Upstream commit
2496616b0a8d1c80cd1416b73a4847b59b9f969a renamed the variable without
renaming it in the SELinux path.

Refresh config and patches.

...

@@ -2170,8 +2184,7 @@ config BUSYBOX_DEFAULT_WATCHDOG
default n
  config BUSYBOX_DEFAULT_FEATURE_IPV6
bool
-   default y if IPV6
-   default n
+   default y
  config BUSYBOX_DEFAULT_FEATURE_UNIX_LOCAL
bool
default n



Rosen,

Looks like you are here accidentally eliminating the OpenWrt specific logic 
for IPv6 flag. (I specifically mentioned that in the commit message that 
Hauke referenced to you, so that it would be noticed in future busybox 
upgrades. IPV6 config flag is not part of the native busybox logic, so the 
defaults generation script misfires regarding it.)


Please remove the patch section that removes the global IPV6 option's impact. 
If you remove the IPV6 logic, busybox will be compiled with IPv6 although the 
user has disabled it in OpenWrt menuconfig.



Hannu



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] libpcap: update to 1.10.0

[Hannu Nyman]

Rosen Penev kirjoitti 4.1.2021 klo 10.31:

On Sun, Jan 3, 2021 at 11:35 PM Bjørn Mork  wrote:

Rosen Penev  writes:


...

@@ -48,11 +47,15 @@ endef
  CMAKE_OPTIONS += \
   -DBUILD_SHARED_LIBS=ON \
   -DBUILD_WITH_LIBNL=OFF \
+ -DINET6=O$(if $(CONFIG_IPV6),N,FF)

  # grep 'option(DISABLE_' CMakeLists.txt | cut -f2 -d'(' | cut -f1 -d' ' | 
sort --unique
  CMAKE_OPTIONS += \
+ -DDISABLE_BLUETOOTH=O$(if $(CONFIG_PCAP_HAS_BT),FF,N) \
   -DDISABLE_DAG=ON \
   -DDISABLE_DBUS=ON \
+ -DDISABLE_DPDK=ON \
+ -DDISABLE_LINUX_USBMON=O$(if $(CONFIG_PCAP_HAS_USB),FF,N) \
   -DDISABLE_NETMAP=ON \
   -DDISABLE_RDMA=ON \
   -DDISABLE_SEPTEL=ON \
@@ -64,12 +67,6 @@ CMAKE_OPTIONS += \
   -DBDEBUG=OFF \
   -DYYDEBUG=OFF \

-CMAKE_OPTIONS += $(if $(CONFIG_PCAP_HAS_USB)   ,,-DDISABLE_USB=ON)
-CMAKE_OPTIONS += $(if $(CONFIG_PCAP_HAS_BT),,-DDISABLE_BLUETOOTH=ON)
-CMAKE_OPTIONS += $(if $(CONFIG_PCAP_HAS_NETFILTER) 
,,-DPCAP_SUPPORT_NETFILTER=OFF)
-
-CMAKE_OPTIONS += $(if $(CONFIG_IPV6),-DINET6=ON,-DINET6=OFF)
-
  define Build/InstallDev
   $(call Build/InstallDev/cmake,$(1))
   $(SED) \



And where did CONFIG_PCAP_HAS_NETFILTER go?

Oversight. Will add.



Could at the same also remove the unncessary obfuscation of O(N/FF):

+ -DDISABLE_BLUETOOTH=O$(if $(CONFIG_PCAP_HAS_BT),FF,N) \

That ON/OFF optimization for making Makefile one character smaller, makes it 
much harder&cryptic to read.


It would be much easier as

+ -DDISABLE_BLUETOOTH=$(if $(CONFIG_PCAP_HAS_BT),OFF,ON) \

or the original

-CMAKE_OPTIONS += $(if $(CONFIG_PCAP_HAS_BT),,-DDISABLE_BLUETOOTH=ON)



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCHv2 2/3] busybox: update to 1.33

[Hannu Nyman]

Petr Štetiar wrote at Mon Jan 4 09:20:57 EST 2021:

> what's the status of the ash deadlock regression[1] introduced likely in 1.32?


I think that is was already mentioned in Hauke's earlier message regarding 
the v1 patch:


http://lists.openwrt.org/pipermail/openwrt-devel/2021-January/033084.html

> > Petr send a update of busybox to version 1.32.0 in August, but did not 
apply it because of a reported bug:

> > https://lists.openwrt.org/pipermail/openwrt-devel/2020-August/030730.html
> >
> > It looks like the problem was fixed in 1.32.1 and 1.33.0 here:


The faulty commit and two fixes backported from upstream dash are listed here:

https://git.busybox.net/busybox/log/?h=1_33_stable&qt=grep&q=Only+clear+gotsigchld



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCHv2 2/3] busybox: update to 1.33

[Hannu Nyman]

Rosen Penev kirjoitti 5.1.2021 klo 0.29:

On Sun, Jan 3, 2021 at 10:14 PM Hannu Nyman  wrote:

Rosen Penev kirjoitti 4.1.2021 klo 5.32:

Remove stime backport.

Remove static libgcc patch as upstream fixed it with
BUSYBOX_DEFAULT_STATIC_LIBGCC which defauls to off.

Remove date -k patch as it no longer applies. It's also pointless as
busybox' hwclock utility can do the same thing.

Remove ntpd patch as that seems to have been applied upstream.

Add smalll patch fixing compilation with SELinux. Upstream commit
2496616b0a8d1c80cd1416b73a4847b59b9f969a renamed the variable without
renaming it in the SELinux path.

Refresh config and patches.

...

@@ -2170,8 +2184,7 @@ config BUSYBOX_DEFAULT_WATCHDOG
   default n
   config BUSYBOX_DEFAULT_FEATURE_IPV6
   bool
- default y if IPV6
- default n
+ default y
   config BUSYBOX_DEFAULT_FEATURE_UNIX_LOCAL
   bool
   default n


Rosen,

Looks like you are here accidentally eliminating the OpenWrt specific logic
for IPv6 flag. (I specifically mentioned that in the commit message that
Hauke referenced to you, so that it would be noticed in future busybox
upgrades. IPV6 config flag is not part of the native busybox logic, so the
defaults generation script misfires regarding it.)

Please remove the patch section that removes the global IPV6 option's impact.
If you remove the IPV6 logic, busybox will be compiled with IPv6 although the
user has disabled it in OpenWrt menuconfig.

It seems the config section is not refreshed either in this patch.
That is, the other Config.in files. No idea how to update those.



I am not sure what you mean. I simply requested that you remove the erroneous 
modification of the IPV6 option from your patch, so that the IPV6 feature 
default is left as it is. Like here:


https://github.com/openwrt/openwrt/blob/master/package/utils/busybox/Config-defaults.in#L2171-L2174


The defaults refreshing script erroneously sets also that option to built-in 
busybox default, as busybox sources do not know about the downstream OpenWrt 
IPV6 config option.


Just remove manually the section

@@ -2170,8 +2184,7 @@ config BUSYBOX_DEFAULT_WATCHDOG
  default n
  config BUSYBOX_DEFAULT_FEATURE_IPV6
  bool
- default y if IPV6
- default n
+ default y
  config BUSYBOX_DEFAULT_FEATURE_UNIX_LOCAL
  bool
  default n


Or do you think that there is something else wrong reagrding the other defaults 
in Config-defaults.in in your patch?
To me your patch looks sensible otherwise, except this IPV6 change.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCHv2 2/3] busybox: update to 1.33

[Hannu Nyman]

Hannu Nyman kirjoitti 5.1.2021 klo 16.34:

Rosen Penev kirjoitti 5.1.2021 klo 0.29:

On Sun, Jan 3, 2021 at 10:14 PM Hannu Nyman  wrote:

...

Please remove the patch section that removes the global IPV6 option's 
impact.
If you remove the IPV6 logic, busybox will be compiled with IPv6 although 
the

user has disabled it in OpenWrt menuconfig.

It seems the config section is not refreshed either in this patch.
That is, the other Config.in files. No idea how to update those.


...

Or do you think that there is something else wrong reagrding the other 
defaults in Config-defaults.in in your patch?

To me your patch looks sensible otherwise, except this IPV6 change.



Yeah, now I got what you meant. I tried your patch set, and then I also run 
the "refresh config " scripts.


Your patch set is missing all the updates to the sourced Config.in files, 
which changes become visible once you run the config refreshing commands.


I got them refreshed after the first ath79 build with

  cd package/utils/busybox/config/
  ../convert_menuconfig.pl 
../../../../build_dir/target-mips_24kc_musl/busybox-default/busybox-1.33.0

  cd ..
  ./convert_defaults.pl < 
../../../build_dir/target-mips_24kc_musl/busybox-default/busybox-1.33.0/.config 
> Config-defaults.in



And then I edited by hand the IPv6 option in Config-defaults.in to get back 
the OpenWrt speciality that deviates from busybox defaults.

I also manually added the needed quotes to source lines that the scripts 
removed.

I added your commits and my fix to my Github fork, so it is easier to see and 
compare.

https://github.com/hnyman/openwrt/commits/bb1330fix

I think that you should add the following fixes to your v2 patch series:
https://github.com/hnyman/openwrt/commit/95f54c3f4d9501a42eda7be4e3bd971a1887f8ac

That is meant to be squashed into your main patch.


I will compile that into a firmware and test it.






___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCHv2 2/3] busybox: update to 1.33

[Hannu Nyman]

Rosen Penev kirjoitti 6.1.2021 klo 0.49:

On Tue, Jan 5, 2021 at 12:20 PM Hannu Nyman  wrote:

Hannu Nyman kirjoitti 5.1.2021 klo 16.34:

Rosen Penev kirjoitti 5.1.2021 klo 0.29:

It seems the config section is not refreshed either in this patch.
That is, the other Config.in files. No idea how to update those.

...

Or do you think that there is something else wrong reagrding the other
defaults in Config-defaults.in in your patch?
To me your patch looks sensible otherwise, except this IPV6 change.


Yeah, now I got what you meant. I tried your patch set, and then I also run
the "refresh config " scripts.

Your patch set is missing all the updates to the sourced Config.in files,
which changes become visible once you run the config refreshing commands.

I got them refreshed after the first ath79 build with

cd package/utils/busybox/config/
../convert_menuconfig.pl
../../../../build_dir/target-mips_24kc_musl/busybox-default/busybox-1.33.0
cd ..
./convert_defaults.pl <
../../../build_dir/target-mips_24kc_musl/busybox-default/busybox-1.33.0/.config
  > Config-defaults.in

That's only for one of the config files, not the others.



Worked ok for all relevant ones, I think.

Or what is your worry here?

(that is the way it has been done with the past 7 version bumps, to my 
knowledge.)






And then I edited by hand the IPv6 option in Config-defaults.in to get back
the OpenWrt speciality that deviates from busybox defaults.
I also manually added the needed quotes to source lines that the scripts 
removed.

I added your commits and my fix to my Github fork, so it is easier to see and
compare.
https://github.com/hnyman/openwrt/commits/bb1330fix

I think that you should add the following fixes to your v2 patch series:
https://github.com/hnyman/openwrt/commit/95f54c3f4d9501a42eda7be4e3bd971a1887f8ac

That is meant to be squashed into your main patch.

Latest 
patch:https://github.com/neheb/openwrt/commit/139dc12498db287660bfad27b94e137afa4de9fa

I think that should be fine.

I will compile that into a firmware and test it.


I have good news and bad news:

Good news is that your new patch is identical as the outcome of (your old 
patch + my fix).

I compiled it yesterday for ath79/WNDR3700 and it worked ok. Good so far.


Bad news is that something has changed between 1.31 and 1.33 regarding shell 
options, and booting ipq806x/R7800 fails with 1.33.0.


I get an error in serial console in preinit phase and the R7800 router never 
boots properly.


[ 5.711407] kmodloader: done loading kernel modules from /etc/modules-boot.d/*
[ 5.721717] init: - preinit -
/etc/preinit: /lib/functions.sh: line 29: syntax error: support for 
$((arith)) is disabled

[ 6.107332] procd: - early -
[ 6.107390] procd: - watchdog -


I think that I have narrowed is down to config options changes regarding ash 
shell, and the enabling of arithmetics via BUSYBOX_CONFIG_FEATURE_SH_MATH.


I suspect that reason for failure is that BUSYBOX_CONFIG_SHELL_ASH is hidden in 
:

config BUSYBOX_CONFIG_SHELL_ASH
    bool #hidden option


That leads our script to parse it wrongly and the section about common 
options remains empty/unselectable in menuconfig, as there is SHELL_ASH 
instead of BUSYBOX_CONFIG_SHELL_ASH in shell/Config.in file. So this section 
remain hidden/disabled:


 comment "Options common to all shells"
-if ASH || BUSYBOX_CONFIG_HUSH || BUSYBOX_CONFIG_SH_IS_ASH || 
BUSYBOX_CONFIG_BASH_IS_ASH || BUSYBOX_CONFIG_SH_IS_HUSH || 
BUSYBOX_CONFIG_BASH_IS_HUSH

+if SHELL_ASH || BUSYBOX_CONFIG_SHELL_HUSH

That leads into missed dependency here, where the syntax has changed:

config BUSYBOX_CONFIG_FEATURE_SH_MATH
    bool "POSIX math support"
    default BUSYBOX_DEFAULT_FEATURE_SH_MATH
-    depends on BUSYBOX_CONFIG_ASH || BUSYBOX_CONFIG_HUSH || 
BUSYBOX_CONFIG_SH_IS_ASH || BUSYBOX_CONFIG_BASH_IS_ASH || 
BUSYBOX_CONFIG_SH_IS_HUSH || BUSYBOX_CONFIG_BASH_IS_HUSH

+    depends on BUSYBOX_CONFIG_SHELL_ASH || BUSYBOX_CONFIG_SHELL_HUSH
    help
    Enable math support in the shell via $((...)) syntax.


So, some changes are still needed.

I will test and come back.



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCHv2 2/3] busybox: update to 1.33

[Hannu Nyman]

Hannu Nyman kirjoitti 6.1.2021 klo 12.08:

Rosen Penev kirjoitti 6.1.2021 klo 0.49:

On Tue, Jan 5, 2021 at 12:20 PM Hannu Nyman  wrote:

Hannu Nyman kirjoitti 5.1.2021 klo 16.34:

Rosen Penev kirjoitti 5.1.2021 klo 0.29:

It seems the config section is not refreshed either in this patch.
That is, the other Config.in files. No idea how to update those.

...

Or do you think that there is something else wrong reagrding the other
defaults in Config-defaults.in in your patch?
To me your patch looks sensible otherwise, except this IPV6 change.


Yeah, now I got what you meant. I tried your patch set, and then I also run
the "refresh config " scripts.

Your patch set is missing all the updates to the sourced Config.in files,
which changes become visible once you run the config refreshing commands.

I got them refreshed after the first ath79 build with

    cd package/utils/busybox/config/
    ../convert_menuconfig.pl
../../../../build_dir/target-mips_24kc_musl/busybox-default/busybox-1.33.0
    cd ..
    ./convert_defaults.pl <
../../../build_dir/target-mips_24kc_musl/busybox-default/busybox-1.33.0/.config 


  > Config-defaults.in

That's only for one of the config files, not the others.



Worked ok for all relevant ones, I think.

Or what is your worry here?

(that is the way it has been done with the past 7 version bumps, to my 
knowledge.)






And then I edited by hand the IPv6 option in Config-defaults.in to get back
the OpenWrt speciality that deviates from busybox defaults.
I also manually added the needed quotes to source lines that the scripts 
removed.


I added your commits and my fix to my Github fork, so it is easier to see 
and

compare.
https://github.com/hnyman/openwrt/commits/bb1330fix

I think that you should add the following fixes to your v2 patch series:
https://github.com/hnyman/openwrt/commit/95f54c3f4d9501a42eda7be4e3bd971a1887f8ac 



That is meant to be squashed into your main patch.
Latest 
patch:https://github.com/neheb/openwrt/commit/139dc12498db287660bfad27b94e137afa4de9fa


I think that should be fine.

I will compile that into a firmware and test it.


I have good news and bad news:

Good news is that your new patch is identical as the outcome of (your old 
patch + my fix).

I compiled it yesterday for ath79/WNDR3700 and it worked ok. Good so far.


Bad news is that something has changed between 1.31 and 1.33 regarding 
shell options, and booting ipq806x/R7800 fails with 1.33.0.


I get an error in serial console in preinit phase and the R7800 router 
never boots properly.


[ 5.711407] kmodloader: done loading kernel modules from /etc/modules-boot.d/*
[ 5.721717] init: - preinit -
/etc/preinit: /lib/functions.sh: line 29: syntax error: support for 
$((arith)) is disabled

[ 6.107332] procd: - early -
[ 6.107390] procd: - watchdog -


I think that I have narrowed is down to config options changes regarding 
ash shell, and the enabling of arithmetics via BUSYBOX_CONFIG_FEATURE_SH_MATH.


I suspect that reason for failure is that BUSYBOX_CONFIG_SHELL_ASH is 
hidden in :


config BUSYBOX_CONFIG_SHELL_ASH
    bool #hidden option


That leads our script to parse it wrongly and the section about common 
options remains empty/unselectable in menuconfig, as there is SHELL_ASH 
instead of BUSYBOX_CONFIG_SHELL_ASH in shell/Config.in file. So this 
section remain hidden/disabled:


 comment "Options common to all shells"
-if ASH || BUSYBOX_CONFIG_HUSH || BUSYBOX_CONFIG_SH_IS_ASH || 
BUSYBOX_CONFIG_BASH_IS_ASH || BUSYBOX_CONFIG_SH_IS_HUSH || 
BUSYBOX_CONFIG_BASH_IS_HUSH

+if SHELL_ASH || BUSYBOX_CONFIG_SHELL_HUSH

That leads into missed dependency here, where the syntax has changed:

config BUSYBOX_CONFIG_FEATURE_SH_MATH
    bool "POSIX math support"
    default BUSYBOX_DEFAULT_FEATURE_SH_MATH
-    depends on BUSYBOX_CONFIG_ASH || BUSYBOX_CONFIG_HUSH || 
BUSYBOX_CONFIG_SH_IS_ASH || BUSYBOX_CONFIG_BASH_IS_ASH || 
BUSYBOX_CONFIG_SH_IS_HUSH || BUSYBOX_CONFIG_BASH_IS_HUSH

+    depends on BUSYBOX_CONFIG_SHELL_ASH || BUSYBOX_CONFIG_SHELL_HUSH
    help
    Enable math support in the shell via $((...)) syntax.


So, some changes are still needed.

I will test and come back.




I added two more commits to

https://github.com/hnyman/openwrt/commits/bb1330fix


The first one addresses the shell math problem. Editing shell/Config.in helps 
menuconfig and defconfig to interprete the config correctly. I solved it for 
now, but the logic might easily get accidentally changed again at the next 
version bump and config file refresh. It might be better in the long run to 
change the underlying symbol definition by removing the hidden attribute from 
BUSYBOX_CONFIG_SHELL_ASH in shell/Config.in, but I have not tested it yet.


https://github.com/hnyman/openwrt/commit/4fde43b539777e644e667c67bde74a9306bfd6cc

That made R7800 to boot again normally.


The second one is a fix for accidentally deleting two new OpenWrt specific 
conditional logic items in the con

Re: [PATCHv3 2/3] busybox: update to 1.33

[Hannu Nyman]

Rosen Penev kirjoitti 8.1.2021 klo 5.30:

...

Refresh config and patches.

Signed-off-by: Rosen Penev 
---
  v3: more complete config refresh.
  v2: refreshed config and slight rewording.



I have applied and tested the v3 patch series in my builds for 
ath79/WNDR3700v2, ipq806x/R7800 and mvebu/WRT3200ACM. Looks ok to me.


(The code is identical to the v2 patches plus the fixes that I communicated 
via the mailing list)


My only suggestion is that it might be good to document in the commit message 
the config refresh commands and the five manual edits that need to be made 
after the scripted config update. I did that with the 1.31.0 version bump, so 
Hauke was now able to quote that as example to Rosen.


The refresh scripts remove three OpenWrt logic additions, do not see one 
hidden option leading to omission of shell arithmetics and do not add quotes 
to sourced Config.in files like currently required.



Config refresh:

Refresh commands, run after busybox is first built once:

  cd package/utils/busybox/config/
  ../convert_menuconfig.pl 
../../../../build_dir/target-mips_24kc_musl/busybox-default/busybox-1.33.0

  cd ..
  ./convert_defaults.pl < 
../../../build_dir/target-mips_24kc_musl/busybox-default/busybox-1.33.0/.config 
> Config-defaults.in



Manual edits needed afterward:

* Config-defaults.in:  OpenWrt config symbol IPV6 logic applied to 
BUSYBOX_DEFAULT_FEATURE_IPV6
* Config-defaults.in:  OpenWrt configTARGET_bcm53xx logic applied to 
BUSYBOX_DEFAULT_TRUNCATE (commit 547f1ec)
* editors/Config.in: Add USE_GLIBC dependency to 
BUSYBOX_CONFIG_FEATURE_VI_REGEX_SEARCH (commit f141090)
* shell/Config.in : change at "Options common to all shells"  the symbol 
SHELL_ASH  -->  BUSYBOX_CONFIG_SHELL_ASH
   (discussion in 
http://lists.openwrt.org/pipermail/openwrt-devel/2021-January/033140.html
 Apparently our script does not see the hidden option while prepending 
config options with "BUSYBOX_CONFIG_" which leads to a missed dependency when 
the options are later evaluated.)
* Edit Config.in files by adding quotes to sourced items in config/Config.in, 
networking/Config.in and util-linux/Config.in (commit 1da014f)



In the long run it might be better to

* un-hide (BUSYBOX_CONFIG_)SHELL_ASH so that the script would fiind the 
dependency for it

* edit the refresh script to add the quotes to the sourced lines, if possible

but those two improvements can be investigated after the version bump.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCHv3 1/3] base-files: use hwclock --systz

[Hannu Nyman]

Rosen Penev kirjoitti 8.1.2021 klo 5.30:

The date -k patch is non standard and will be removed in the next
commit.

...

--- a/package/base-files/files/etc/init.d/system
+++ b/package/base-files/files/etc/init.d/system
@@ -27,7 +27,7 @@ system_config() {
ln -sf "/usr/share/zoneinfo/$zonename" /tmp/localtime && rm -f 
/tmp/TZ
  
  	# apply timezone to kernel

-   busybox date -k
+   hwclock --systz
  }
  
  reload_service() {



I suspect that this proposed modification causes a noticeable difference to 
the previous way:
After reboot, the early part of the log seems to be in UTC instead of the 
local timezone, as earlier. (Likely sysfixtime has understood the timestamp 
of the last file in /etc wrongly)


Here is a extract from system log of the router with busybox 1.33 in a simple 
reboot. I touched a file in /etc just before reboot, so sysfixtime should set 
roughly correct time early in the boot process. There should be just approx. 
one minute jump when NTP corrects time (from the most-recent-file based boot 
time as set by sysfixtime), instead of two hours + 1 minute.


Sun Jan 10 16:37:50 2021 daemon.info procd: - init complete -
Sun Jan 10 16:37:52 2021 user.notice nlbwmon: Reloading nlbwmon due to ifup 
of lan6 (br-lan)
Sun Jan 10 18:38:56 2021 user.notice ntpd: Time set, stratum=16 interval=32 
offset=7262.868194



Something has prevented the normal timezone handling there.


Doing the same reboot with a 2 Jan 2021 build without buysybox 1.33 makes the 
time shift jump look again normal. There is just the expected one minute jump:


Sun Jan 10 19:04:01 2021 daemon.info procd: - init complete -
Sun Jan 10 19:05:03 2021 user.notice ntpd: Time set, stratum=16 interval=32 
offset=60.906955
Sun Jan 10 19:05:05 2021 user.notice nlbwmon: Reloading nlbwmon due to ifup 
of lan6 (br-lan)



It is of course possible that this might be due to some change in base-files 
or kernel last week, but that is hard to believe.


I suspect that the "hwclock --systz" does something slightly different than 
our "date -k", at least on routers without a real RTC.


My proposal would be to revert your removal of the date-k patch and continue 
using it the previous way.


(I will try to test with date-k reverted if things then work ok with 1.33. 
Might be that this is something different.)



Ps. Let's just focus to the Busybox version upgrade, without doing these 
"let's remove OpenWrt-specific patches" cleanup at the same time. This clock 
handling change is quite separate from the 1.31 --> 1.33 version bump (unless 
1.33 really prevents the previous way).



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCHv3 1/3] base-files: use hwclock --systz

[Hannu Nyman]

Hannu Nyman kirjoitti 10.1.2021 klo 19.25:

Rosen Penev kirjoitti 8.1.2021 klo 5.30:

The date -k patch is non standard and will be removed in the next
commit.

...

--- a/package/base-files/files/etc/init.d/system
+++ b/package/base-files/files/etc/init.d/system
@@ -27,7 +27,7 @@ system_config() {
  ln -sf "/usr/share/zoneinfo/$zonename" /tmp/localtime && rm -f 
/tmp/TZ

    # apply timezone to kernel
-    busybox date -k
+    hwclock --systz
  }
    reload_service() {



I suspect that this proposed modification causes a noticeable difference to 
the previous way:
After reboot, the early part of the log seems to be in UTC instead of the 
local timezone, as earlier. (Likely sysfixtime has understood the timestamp 
of the last file in /etc wrongly)


Here is a extract from system log of the router with busybox 1.33 in a 
simple reboot. I touched a file in /etc just before reboot, so sysfixtime 
should set roughly correct time early in the boot process. There should be 
just approx. one minute jump when NTP corrects time (from the 
most-recent-file based boot time as set by sysfixtime), instead of two 
hours + 1 minute.


Sun Jan 10 16:37:50 2021 daemon.info procd: - init complete -
Sun Jan 10 16:37:52 2021 user.notice nlbwmon: Reloading nlbwmon due to ifup 
of lan6 (br-lan)
Sun Jan 10 18:38:56 2021 user.notice ntpd: Time set, stratum=16 interval=32 
offset=7262.868194



Something has prevented the normal timezone handling there.


Doing the same reboot with a 2 Jan 2021 build without buysybox 1.33 makes 
the time shift jump look again normal. There is just the expected one 
minute jump:


Sun Jan 10 19:04:01 2021 daemon.info procd: - init complete -
Sun Jan 10 19:05:03 2021 user.notice ntpd: Time set, stratum=16 interval=32 
offset=60.906955
Sun Jan 10 19:05:05 2021 user.notice nlbwmon: Reloading nlbwmon due to ifup 
of lan6 (br-lan)



It is of course possible that this might be due to some change in 
base-files or kernel last week, but that is hard to believe.


I suspect that the "hwclock --systz" does something slightly different than 
our "date -k", at least on routers without a real RTC.


My proposal would be to revert your removal of the date-k patch and 
continue using it the previous way.


(I will try to test with date-k reverted if things then work ok with 1.33. 
Might be that this is something different.)


I compiled the same up-to-date master with busybox 1.33 but with the date-k 
removal reveerted and refreshed, and the timestamps in the system log again 
behave normally:



After flash of r15469 with busybox 1.33 with date-k changed reverted (and 
refreshed).

Normal time shift, roughly the difference of build & flashing

Sun Jan 10 19:44:59 2021 user.notice nlbwmon: Reloading nlbwmon due to ifup 
of loopback (lo)

Sun Jan 10 19:45:02 2021 daemon.info procd: - init complete -
Sun Jan 10 19:45:02 2021 daemon.info urandom_seed[4597]: Seed saved 
(/etc/urandom.seed)
Sun Jan 10 20:25:06 2021 user.notice ntpd: Time set, stratum=16 interval=32 
offset=2403.398106
Sun Jan 10 20:25:06 2021 user.notice nlbwmon: Reloading nlbwmon due to ifup 
of lan6 (br-lan)



After a normal boot, again a normal 1 minute leap when NTP kicks in:

Sun Jan 10 20:39:24 2021 daemon.err uhttpd[2934]: luci: accepted login on 
/admin/status/overview for root from 192.168.1.180

Sun Jan 10 20:39:25 2021 daemon.info procd: - init complete -
Sun Jan 10 20:40:45 2021 user.notice ntpd: Time set, stratum=16 interval=32 
offset=79.663960
Sun Jan 10 20:40:46 2021 user.notice ntpd: Stratum change, stratum=4 
interval=32 offset=0.001017
Sun Jan 10 20:40:48 2021 user.notice nlbwmon: Reloading nlbwmon due to ifup 
of lan6 (br-lan)


I think that the proposed date-k removal and /etc/init.d/system change should 
be removed from the version bump.



The patch 250-date-k-flag.patch needs to be refreshed. This is the original 
compared to the refreshed-for-1.33.0



diff --git a/package/utils/busybox/patches/250-date-k-flag.patch 
b/package/utils/busybox/patches/250-date-k-flag.patch

index 5aadbb233c..3a666c581d 100644
--- a/package/utils/busybox/patches/250-date-k-flag.patch
+++ b/package/utils/busybox/patches/250-date-k-flag.patch
@@ -1,14 +1,14 @@
 --- a/coreutils/date.c
 +++ b/coreutils/date.c
-@@ -123,6 +123,7 @@
- //usage:    IF_FEATURE_DATE_ISOFMT(
- //usage: "\n    -D FMT        Use FMT (strptime format) for -d TIME 
conversion"

+@@ -109,6 +109,7 @@
+ //usage: "\n    -I[SPEC]    Output ISO-8601 date"
+ //usage: "\n            SPEC=date (default), hours, minutes, seconds or 
ns"
  //usage:    )
 +//usage: "\n    -k        Set Kernel timezone from localtime and exit"
  //usage: "\n"
  //usage: "\nRecognized TIME formats:"
- //usage: "\n    hh:mm[:ss]"
-@@ -139,9 +140,8 @@
+ //usage: "\n    @seconds_since_1970"
+@@ -126,9 +127,8 @@

  #include "libbb.

Re: [PATCH v2] base-files: restore status of system-services after sysupgrade

[Hannu Nyman]

Martin Schiller kirjoitti 12.1.2021 klo 9.25:

On 2021-01-11 23:07, Sven Roederer wrote:

Restore the status of the system-services after sysupgrade.
Create a file with the status of all known services and keep it during
upgrade. After upgrade run a uci-default script to restore every
single service.


Doing the restore in an uci-default script is to late, because then you
are already in the procd rcS helper "loop" and new added init links
won't get called.

Also, have you thought about a backup/restore of the configuration?
The whole thing should/must work there as well.

I would do the restore at the end of the pre-init stage.

Martin



My two cents to the discussion:

* I assume that a small minority of users actually disable services, or at 
least disable several services, so defaulting to "lets by default always 
store status of all services" sounds like overkill.


* Backuping always info that the dozens of standard services are enabled 
sounds unncessary. As services are installed by default as "enabled" to the 
image, it might make sense to store only info about "disabled" services and 
disable those when restoring the backup in sysupgrade.  (Re-enabling the 
already enabled services is unnecessary.)  That would also help to keep the 
amount of new backup info small.


* make clear in sysupgrade script help texts and documentation that 
saving/restoring service status depends on "keep settings". If settings are 
not kept, the service status can not be copied in sysupugrade as there is no 
sysupgrade.tar.gz to be passed. (And naturally it would not even make sense 
to e.g. revert network settings to defaults but keep selected network 
services disabled. Easy to cause soft-bricks that way.)




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: base-files: flush kernel memory cache during sysupgrade

[Hannu Nyman]

Stijn Segers kirjoitti 13.1.2021 klo 0.48:
Have tested this on a few low-RAM devices, among which a TL-WR841N v7 (32 
MiB) and a WNDR3700 v2 (64 MiB).


No idea if this is still necessary/wanted but would be nice to see this end 
up in master (and trickle down to 21.xx :-D ).


Tested-by: Stijn Segers 


Hi Stijn,

this has been merged already in December as commit 3d12b4798:

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=3d12b47985fc1983849925d2dc23430f55210c80



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Dnsmasq 2.83 causes log spam

[Hannu Nyman]

Looks like the new dnsmasq 2.83 (and the patched 2.80 in 19.07) cause massive 
log spam, in style of:



Fri Jan 22 06:30:09 2021 daemon.err dnsmasq[14996]: failed to send packet: 
Network unreachable
Fri Jan 22 06:30:14 2021 daemon.err dnsmasq[14996]: failed to send packet: 
Network unreachable
Fri Jan 22 06:30:23 2021 daemon.err dnsmasq[14996]: failed to send packet: 
Network unreachable
Fri Jan 22 06:30:25 2021 daemon.err dnsmasq[14996]: failed to send packet: 
Address family not supported by protocol
Fri Jan 22 06:30:25 2021 daemon.err dnsmasq[14996]: failed to send packet: 
Address family not supported by protocol
Fri Jan 22 06:30:28 2021 daemon.err dnsmasq[14996]: failed to send packet: 
Address family not supported by protocol
Fri Jan 22 06:30:28 2021 daemon.err dnsmasq[14996]: failed to send packet: 
Address family not supported by protocol



Based on forum discussion and my own experience, this is apparently mainly 
related to Windows PCs and Macs that have ipv6.



This is being extensively discussed in the forum, starting from:

https://forum.openwrt.org/t/security-advisory-2021-01-19-1-dnsmasq-multiple-vulnerabilities/85903/22




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Dnsmasq 2.83 causes log spam

[Hannu Nyman]

Jo-Philipp Wich kirjoitti 22.1.2021 klo 12.37:
> unfortunately we lack a reliable reproducer so far.
>
> A packet capture would be most helpful, another option would be a bisect of
> the intermediate dnsmasq Git revisions.


I bisected the dnsmasq upstream commits, and looks like it is caused by this:

15b60ddf935a531269bb8c68198de012a4967156  FAIL
824461192ca5098043f9ca4ddeba7df1f65b30ba  Ok ?

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=15b60ddf935a531269bb8c68198de012a4967156

"Handle multiple identical near simultaneous DNS queries better."


Dnsmasq built from earlier commits seem to avoid the error/warning messages, 
while builds with 15b60ddf cause log spam flood.

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=shortlog


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] dnsmasq: backport fixes

[Hannu Nyman]

Hauke Mehrtens kirjoitti 24.1.2021 klo 13.44:

This should fix some error messages shown in the log like this one:
dnsmasq[5246]: failed to send packet: Network unreachable

Fixes: e87c0d934c54 ("dnsmasq: Update to version 2.83")
Signed-off-by: Hauke Mehrtens 
---
  package/network/services/dnsmasq/Makefile |  2 +-
  ...c_src-fixes-15b60ddf935a531269bb8c68.patch | 57 +++
  ...f0aec33e58ef5b8d4d107d821c215a52827c.patch | 19 +++
  ...2b171de0d678d98583e2190789e50e02.patch | 20 +++
  ...00-remove-old-runtime-kernel-support.patch |  4 +-
  5 files changed, 99 insertions(+), 3 deletions(-)
  create mode 100644 
package/network/services/dnsmasq/patches/0120-Move-fd-into-frec_src-fixes-15b60ddf935a531269bb8c68.patch
  create mode 100644 
package/network/services/dnsmasq/patches/0121-Fix-to-75e2f0aec33e58ef5b8d4d107d821c215a52827c.patch
  create mode 100644 
package/network/services/dnsmasq/patches/0123-Fix-for-12af2b171de0d678d98583e2190789e50e02.patch



I think that it is easier to use the upstream test release for master, and 
not to backport individual patches.



Kevin already has patches for both master and 19.07 in his staging repo. 
(mine and openwrt-19.07 branches)




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] treewide: unify OpenWrt hosted source URL

[Hannu Nyman]

Paul Spooren kirjoitti 30.1.2021 klo 23.54:

Multiple sources are hosted on OpenWrts source server only. The source
URLs to point to the server vary based on different epochs in OpenWrts
history. Unify them to use always the new source CDN and HTTPS.

If the CDN fails, sources.o.o is used as a fallback via downloads.pl.

Signed-off-by: Paul Spooren 
---
  package/boot/fconfig/Makefile | 2 +-
  package/firmware/b43legacy-firmware/Makefile  | 2 +-
  package/firmware/lantiq/dsl-vrx200-firmware-xdsl/Makefile | 2 +-
  package/kernel/broadcom-wl/Makefile   | 2 +-
  package/kernel/lantiq/ltq-adsl/Makefile   | 2 +-
  package/kernel/lantiq/ltq-tapi/Makefile   | 2 +-
  package/kernel/lantiq/ltq-vdsl-mei/Makefile   | 2 +-
  package/kernel/lantiq/ltq-vdsl/Makefile   | 2 +-
  package/kernel/lantiq/ltq-vmmc/Makefile   | 2 +-
  package/kernel/mac80211/broadcom.mk   | 6 +++---
  package/network/config/ltq-adsl-app/Makefile  | 2 +-
  package/network/config/ltq-vdsl-app/Makefile  | 2 +-
  tools/lzma-old/Makefile   | 2 +-
  tools/lzma/Makefile   | 2 +-
  14 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/package/boot/fconfig/Makefile b/package/boot/fconfig/Makefile
index 9b806fe97c..31986e6942 100644
--- a/package/boot/fconfig/Makefile
+++ b/package/boot/fconfig/Makefile
@@ -12,7 +12,7 @@ PKG_VERSION:=20080329
  PKG_RELEASE:=1
  
  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz

-PKG_SOURCE_URL:=https://downloads.openwrt.org/sources
+PKG_SOURCE_URL:=https://sources.cdn.openwrt.org



Would it make sense to define a similar @OPENWRT alias in scripts/download.pl 
as we have done for SF, APACHE, GITHUB, GNU, SAVANNAH, KERNEL and GNOME ?


https://github.com/openwrt/openwrt/blob/master/scripts/download.pl#L192-L255

Then we could in future change those download locations centrally in 
download.pl, instead of changing it every single Makefile where it is used. 
The Makefiles could just contain PKG_SOURCE_URL:=@OPENWRT


(One afterthought: the pushed contents might actually be empty, as the actual 
download locations are pushed on lines 261-263 to the same trial queue. Not 
quite sure about the pushing order logic, but might work.)



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] treewide: unify OpenWrt hosted source URL

[Hannu Nyman]

Paul Spooren kirjoitti 31.1.2021 klo 11.19:



On Sun, Jan 31, 2021 at 10:08, Hannu Nyman  wrote:

Paul Spooren kirjoitti 30.1.2021 klo 23.54:

Multiple sources are hosted on OpenWrts source server only. The source
URLs to point to the server vary based on different epochs in OpenWrts
history. Unify them to use always the new source CDN and HTTPS.

If the CDN fails, sources.o.o is used as a fallback via downloads.pl.

Signed-off-by: Paul Spooren 
---
...
    PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
-PKG_SOURCE_URL:=https://downloads.openwrt.org/sources
+PKG_SOURCE_URL:=https://sources.cdn.openwrt.org



Would it make sense to define a similar @OPENWRT alias in 
scripts/download.pl as we have done for SF, APACHE, GITHUB, GNU, SAVANNAH, 
KERNEL and GNOME ?


I had the same idea but thought it's awkward to define a variable which is 
then empty. I'll give it a try and see how it looks. We could then decide 
for either solution.



Just an elsif block with a comment about the actual sites being added at the 
end as deafult fallback sites in any case. (and possibly a no-op line like 
sleep(1), if the elsif block needs some actual contents. (not sure about perl)).


Or possibly an elsif block containing the same cdn line, so that it gets 
added twice (once here, once as fallback). Seems extraflous, but would look tidy.







https://github.com/openwrt/openwrt/blob/master/scripts/download.pl#L192-L255

Then we could in future change those download locations centrally in 
download.pl, instead of changing it every single Makefile where it is 
used. The Makefiles could just contain PKG_SOURCE_URL:=@OPENWRT


(One afterthought: the pushed contents might actually be empty, as the 
actual download locations are pushed on lines 261-263 to the same trial 
queue. Not quite sure about the pushing order logic, but might work.)








___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCHv3 1/3] base-files: use hwclock --systz

[Hannu Nyman]

Rosen Penev kirjoitti 1.2.2021 klo 2.15:

The date -k patch is non standard and will be removed in the next
commit.

...
--- a/package/base-files/files/etc/init.d/system
+++ b/package/base-files/files/etc/init.d/system
@@ -27,7 +27,7 @@ system_config() {
ln -sf "/usr/share/zoneinfo/$zonename" /tmp/localtime && rm -f 
/tmp/TZ
  
  	# apply timezone to kernel

-   busybox date -k
+   hwclock -u --systz



As discussed in connection of the musl update PR ( starting from 
https://github.com/openwrt/openwrt/pull/3004#issuecomment-764479005 ), the 
addition of "-u" to the hwclock options seems to fix the strange timestamps 
in early boot system logs that I noticed earlier.


I think that in the current form the busybox update to 1.33.0 works ok. I 
have been using it in my own builds since early January for ath79/WNDR3700, 
ipq806x/R7800 and mvebu/WRT3200ACM.


Would be great to have it in the tree before the 21.0x branching.


PS. this patch series is already actually v4, as patch v3 was sent on 7 Jan 
2021.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCHv3 2/3] busybox: update to 1.33

[Hannu Nyman]

Hauke Mehrtens kirjoitti 4.2.2021 klo 1.55:

On 2/1/21 1:15 AM, Rosen Penev wrote:

Remove stime backport.

Remove static libgcc patch as upstream fixed it with
BUSYBOX_DEFAULT_STATIC_LIBGCC which defauls to off.

Remove date -k patch as it no longer applies. It's also pointless as
busybox' hwclock utility can do the same thing.

Remove ntpd patch as that seems to have been applied upstream.

Add smalll patch fixing compilation with SELinux. Upstream commit
2496616b0a8d1c80cd1416b73a4847b59b9f969a renamed the variable without
renaming it in the SELinux path.

Refresh config and patches.

Signed-off-by: Rosen Penev 
---
...


Do we want to merge this into OpenWrt master before the 21.X branch is 
created?
As 21.X is delayed again I would prefer to merge this now, then we have a 
more recent base for potential security updates later.



I think that we should merge it. Better to get the new version into the new 
stable release, especially if the branching is not today or tomorrow :-(





The commit message should probably extended with some content Hannu suggested.



That would help a lot at the next version bump. I have done most the busybox 
version bumps in the last few years (and the actual config refresh also this 
time), and even with that history it is still hard to remember the extra 
changes to be done manually. Better to document them in the main commit message.


I listed the needed edits in my earlier response, so Rosen might either edit 
the commit message, or maybe it is easier if Hauke just adds them (when you 
take the commits into your staging tree).


http://lists.openwrt.org/pipermail/openwrt-devel/2021-January/033218.html



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCHv3 2/3] busybox: update to 1.33

[Hannu Nyman]

Hauke Mehrtens kirjoitti 14.2.2021 klo 16.39:

On 2/4/21 5:02 PM, Hannu Nyman wrote:

Hauke Mehrtens kirjoitti 4.2.2021 klo 1.55:
...



The commit message should probably extended with some content Hannu 
suggested.



That would help a lot at the next version bump. I have done most the 
busybox version bumps in the last few years (and the actual config refresh 
also this time), and even with that history it is still hard to remember 
the extra changes to be done manually. Better to document them in the main 
commit message.


I listed the needed edits in my earlier response, so Rosen might either 
edit the commit message, or maybe it is easier if Hauke just adds them 
(when you take the commits into your staging tree).


http://lists.openwrt.org/pipermail/openwrt-devel/2021-January/033218.html


Hi Rosen and Hannu,

Is this change of the commit message looking good to you:
https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=commitdiff;h=0275ee5dde7c36c925396779dd23d4f470ab40e1 



Hauke



Looks good to me.  Including the explanatory comments will help with the 
next version bump.



Hannu




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

LICENSE move to LICENSES/ by 882e3014 causes buildbot breakage

[Hannu Nyman]

Looks like the LICENSE file move to LICENSES/ by 882e3014 causes buildbot 
breakage.


The SDK Makefile still expects to find LICENSE file as |$(TOPDIR)/LICENSE|
https://github.com/openwrt/openwrt/blob/master/target/sdk/Makefile#L133 



    $(CP) -L \
    $(TOPDIR)/LICENSE \

In addition to the SDK Makefile, the |$(TOPDIR)/LICENSE| is also mentioned here:

https://github.com/openwrt/openwrt/blob/master/target/toolchain/Makefile#L36 


||

|$(CP) $(TOPDIR)/LICENSE ./files/README.TOOLCHAIN \|

|
|

All stage1 builds with this commit 882e301461 are failing.
http://buildbot.openwrt.org/master/images/one_line_per_build 



Example error log:
http://buildbot.openwrt.org/master/images/builders/zynq%2Fgeneric/builds/713/steps/images/logs/stdio 



|./convert-config.pl /builder/shared-workdir/build/.config > 
/builder/shared-workdir/build/build_dir/target-arm_cortex-a9+neon_musl_eabi/openwrt-sdk-zynq_gcc-8.4.0_musl_eabi.Linux-x86_64/Config-build.in 
cp -fpR -L \ /builder/shared-workdir/build/LICENSE \ 
/builder/shared-workdir/build/rules.mk \ ./files/Config.in \ ./files/Makefile 
\ ./files/include/prepare.mk \ ./files/README.SDK \ 
/builder/shared-workdir/build/build_dir/target-arm_cortex-a9+neon_musl_eabi/openwrt-sdk-zynq_gcc-8.4.0_musl_eabi.Linux-x86_64/ 
cp: cannot stat '/builder/shared-workdir/build/LICENSE': No such file or 
directory Makefile:88: recipe for target 
'/builder/shared-workdir/build/bin/targets/zynq/generic/openwrt-sdk-zynq_gcc-8.4.0_musl_eabi.Linux-x86_64.tar.xz' 
failed make[2]: Leaving directory '/builder/shared-workdir/build/target/sdk' |



Buildbot still built ok ce4cb8e 
, 
but fails all builds since 36bb119 
 
which is only a few commits later (including this one). This commit looks 
like the probable culprit in that commit range.




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] wireguard-tools: Add dependency on kmod-wireguard

[Hannu Nyman]

Ilya Lipnitskiy kirjoitti 18.2.2021 klo 19.48:

Hi,

On Thu, Feb 18, 2021 at 9:21 AM Adrian Schmutzler
 wrote:

I don't really get the point of this justification. Either wireguard-tools depends on 
kmod-wireguard, or it doesn't. In the first case, and only then, it should be 
"fixed" (with a proper justification describing that).

Are wireguard-tools useful without the underlying kernel module? It
didn't seem like it to me, although maybe Jason should chime in here,
as maintainer and developer of Wireguard.



As historical reference, please see the discussion in LuCI PR #855 in 2016, 
when that aspect was discussed:


https://github.com/openwrt/luci/issues/855





The idea is to enable in-tree wireguard kernel modules on Linux 5.10
with a plan to phase out the out-of-tree module when 5.4 is taken out.
Reducing cross-repository dependencies makes it easier to accomplish.



It can be cumbersome to make a user-space package depend on alternative 
kernel package variants depending on the kernel version, as  we have some 
package targets where the user-space package build SDK kernel version might 
differ from the target SDK kernel. There were major difficulties with SQM & 
cake a year ago.


See https://github.com/openwrt/packages/issues/12072

There the solution was an additional virtual kernel package, which could then 
handle the kernel mainline / oot dependency difference inside the target.


https://github.com/openwrt/openwrt/pull/3039



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt 21.02 branch

[Hannu Nyman]

I built my first OpenWrt 21.02 test build and noticed that opkg is unable to 
download any package lists. When I try to update package list with 21.02, 
opkg gives error about signature file download errors.



 OpenWrt 21.02-SNAPSHOT, r15841-60823c67cb
 -
root@router1:~# opkg update
Downloading 
https://downloads.openwrt.org/releases/21.02-SNAPSHOT/targets/ipq806x/generic/packages/Packages.gz

Updated list of available packages in /var/opkg-lists/openwrt_core
Downloading 
https://downloads.openwrt.org/releases/21.02-SNAPSHOT/targets/ipq806x/generic/packages/Packages.sig

Signature file download failed.
Remove wrong Signature file.

Looking at the 21.02 download directories, the package dirs are indeed 
missing the normal .sig signature files.


There should likely be a 21.02 release key, which should be added both to the 
keyring and to the 21.02 buildbot config (?). So far the newest key in the 
keyring is the 19.07 release key.


https://git.openwrt.org/?p=keyring.git;a=summary


The 21.02 buildbots are already running and end-users are eagerly waiting to 
test 21.02, so there are already forum discussions about 21.02 opkg.

E.g.� https://forum.openwrt.org/t/21-02-snapshot-error-opkg-update/89054


jow has added the release keys for 17,01, 18.06 and 19.07, but I am unsure 
who should do it now, so I am spamming this to some possible suspects.



Hannu




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt 21.02 branch

[Hannu Nyman]

Petr Štetiar kirjoitti 20.2.2021 klo 16.30:

Hannu Nyman  [2021-02-20 12:40:27]:

Hi,


There should likely be a 21.02 release key, which should be added both to
the keyring and to the 21.02 buildbot config (?). So far the newest key in
the keyring is the 19.07 release key.

https://git.openwrt.org/?p=keyring.git;a=summary

The 21.02 buildbots are already running and end-users are eagerly waiting to
test 21.02, so there are already forum discussions about 21.02 opkg.
E.g.? https://forum.openwrt.org/t/21-02-snapshot-error-opkg-update/89054

it's my fault, I've forget about this step when preparing the 21.02 build
infra and I've added the missing keys right now so it is going to take some
time until that propagates to downloads.

Cheers,

Petr



You liekly need to also update the openwrt-keyring package itself in the 
source repo, so that private builders (like me) also get the updated new 
keys. (at least in 21.02 and master)


Like jow did in 2019:

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=e9216b3336f7a774be7021dd663a433d9ec5edc7


https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/system/openwrt-keyring/Makefile;hb=HEAD


Hannu



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Installation error for libncursesw6

[Hannu Nyman]

Philip Prindeville philipp_subx at redfish-solutions.com wrote at Mon Mar 1 
02:11:20 EST 2021:

> Is there a workaround to force an install?

* Build a new up-to-date version with the current packages data. Update opkg 
lists.

* Download a .ipk manually and install it with opkg.

To my knowledge the bug has been already fixed in master, but you may still 
have the broken old firmware.




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Please consider reverting autoconf-lean from toolchain

[Hannu Nyman]

Apparently autoconf-lean, merged into the toolchain during last weekend, 
causes problems with various packages at buildbot.


I am not sure if that is due to underlying problems in the specific failing 
packages, or due to a wrong site config from autoconf-lean, but buildbot is 
gradually hitting the problems as packages are built with faulty SDKs.


I suggest that the new autoconf-lean stuff is reverted until the failures are 
understood better.


I have filed bug FS#3655 and earlieralso a packages issue as that was how I 
found the issue in my own build.


There are several buildbot failure logs examples in the bug FS#3655.

At least ntfs-3g, rsync, nedata, and possibly also mac80211 and mwlwifi are 
failing for some targets.

(not sure about mac80211 and mwlwifi failures' relation)

I reverted autoconf-lean from my buildhost and I was again able to build 
ntfs-3g.


Extract from bug FS#3655:

https://bugs.openwrt.org/index.php?do=details&task_id=3655&order=id&sort=desc

---

autoconf-lean stuff from Felix was merged by Daniel a few days ago to master 
with commits
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=32c664ff02910bf39a3fbd5a5a4a8bff3191dd03Â 
and

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=f439e291304a93b982e912dc91b80ca950a594f3

That seems to cause buildhost-specific variation in the generated site config 
files, and causes variating breakage from some packages.


I stumbled upon this on weekend with ntfs-3g, which suddenly does not compile 
in my Ubuntu 20.10 in Virtualbox. I filed a bug about ntfs-3g to packages 
feed, but this is more generic:

https://github.com/openwrt/packages/issues/14940


The same buildhost builds 21.02 without problems (and that is still pretty 
identical to master regarding packages)


Reverting autoconf-lean commits fixes things for me.

There are now others with the same symptoms, based on responses to the 
packages feed bug.


Buildbot is now meeting the same problem. At least ntfs-3g, rsync, nedata, 
and possibly also mac80211 and mwlwifi are failing for some targets with some 
buildhosts (with the new SDK).


E.g.
https://downloads.openwrt.org/snapshots/faillogs/aarch64_cortex-a72/packages/ntfs-3g/compile.txt


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Installation error for libncursesw6

[Hannu Nyman]

Philip Prindeville kirjoitti 2.3.2021 klo 0.37:

On Mar 1, 2021, at 7:00 AM, Hannu Nyman  wrote:

Philip Prindeville philipp_subx at redfish-solutions.com wrote at Mon Mar 1 
02:11:20 EST 2021:

Is there a workaround to force an install?

* Build a new up-to-date version with the current packages data. Update opkg 
lists.
* Download a .ipk manually and install it with opkg.

To my knowledge the bug has been already fixed in master, but you may still 
have the broken old firmware.


When you say "update opkg lists", are you talking about the 
/usr/lib/opkg/status file or something else?

Because it seems to me that that's what's lingering that might be damaged.  Is there a 
way to update "opkg" itself and resynthesize this file?  Or a script I can run 
to recreate it from scratch?


Buildbot builds the packages ok, and so do I.

Package: libncurses6
Version: 6.2-1
Depends: libc, terminfo
Provides: libncursesw, libncurses, libncursesw6

So, this is likely something related to your buildroot. Somehow stale or dirty?

I suspect that you have not fully cleaned your build system. As the package 
metadata parsing was buggy two weeks ago, you should have re-created all 
package metadata from scratch after it was fixed. The package metadata is 
semi-hidden in tmp/.package* files, which are not touched by make clean.  
You should rm tmp/ from buildroot and let all package data get re-created.


perus@ub2010:/Openwrt/r7800$ ls  tmp/.package*
tmp/.packageauxvars  tmp/.packagedeps  tmp/.packageinfo� tmp/.packageusergroup


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Buildbot infrastructure upgrade

[Hannu Nyman]

Petr Štetiar kirjoitti 18.3.2021 klo 12.12:


I'm still not that happy with the round-robin scheduler[1], but it's better 
then the previous state, so I'm going to deploy it soon to all masters.


...

1. https://github.com/buildbot/buildbot/issues/4592#issuecomment-801163587

Cheers,

Petr



I noticed that the master packages buildbot just started a new 
mips64_octeonplus build, but only removed one of the pending build requests 
(9 hours old) from the queue. The newer buildrequest 1344 that is 41 minutes 
old, is still in the queue.


https://buildbot.openwrt.org/master/packages/#/builders/4
https://buildbot.openwrt.org/master/packages/#/pendingbuildrequests


The same seems to have happened to i386_pentium-mmx (while I was writing this).

So, a started build for a target does not always clear the build request 
queue, as intended.




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Buildbot infrastructure upgrade

[Hannu Nyman]

Petr Štetiar kirjoitti 19.3.2021 klo 8.39:

Hannu Nyman  [2021-03-18 19:52:18]:


Petr Štetiar kirjoitti 18.3.2021 klo 12.12:

I'm still not that happy with the round-robin scheduler[1], but it's
better then the previous state, so I'm going to deploy it soon to all
masters.

...

1. https://github.com/buildbot/buildbot/issues/4592#issuecomment-801163587

I noticed that the master packages buildbot just started a new
mips64_octeonplus build, but only removed one of the pending build requests
(9 hours old) from the queue. The newer buildrequest 1344 that is 41 minutes
old, is still in the queue.

https://buildbot.openwrt.org/master/packages/#/builders/4
https://buildbot.openwrt.org/master/packages/#/pendingbuildrequests

The same seems to have happened to i386_pentium-mmx (while I was writing this).

So, a started build for a target does not always clear the build request
queue, as intended.

it looks like the issue in the scheduler/database update I've referenced and 
reported:

  2021-03-18 17:32:12+ [-] prioritizeBuilders:mips64_octeonplus 
complete_at: 2021-03-16 12:50:30+00:00
  2021-03-18 17:32:13+ [-] starting build  using worker 
  2021-03-18 17:32:18+ [-] starting build .. pinging the worker 
  2021-03-18 17:56:30+ [-] prioritizeBuilders:mips64_octeonplus 
complete_at: 2021-03-16 12:50:30+00:00
  2021-03-19 00:23:21+ [-]  : build finished

here previous build finishes, so the next complete_at should return time of
00:23:21, but it actually still returns the old timestamp:

  2021-03-19 00:23:22+ [-] prioritizeBuilders:mips64_octeonplus 
complete_at: 2021-03-16 12:50:30+00:00

so the build is considered oldest and scheduled for build:

  2021-03-19 00:23:24+ [-] starting build  using worker 
  2021-03-19 00:23:31+ [-] starting build .. pinging the worker 

Cheers,

Petr



I think that this might the problem that rjarry tried to overcome with 
"cooldown_seconds" defined and set to 4 seconds in the discussion in the 
upstream buildbot issue you referenced. I think that he made the queue 
evaluation to wait for 4 seconds before actually starting, so that all 
asynchronous updates would have been written first.  (I didn't look into 
logic too deeply, but that was my impression at the first glance.)


We might try something similar, even set a bit longer waiting time.




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt 21.02-rc1

[Hannu Nyman]

Hauke Mehrtens kirjoitti 7.4.2021 klo 1.29:

Hi,

How do we want to go forward with OpenWrt 21.02-rc1?

* I think the base system is ok.
* The http (original wolfssl) problem reported by jow is fixed
* LuCI in the 21.02 branch still misses DSA support, this was merged into 
master some time ago as far as I understood.


...

In would like to get 21.02-rc1 soon, so more users start testing it and we 
get more bug reports.


How should we continue?
1. Tag 21.02-rc1 and do the release in the next days with the current
  state.

2. Merge the LuCI DSA changes from master to 21.02 branch now and do
  21.02-rc1 ~3 days to see if some big problems come up.



Option 2 of merging the LuCI DSA changes and then making the first 21.02-rc 
sounds good to me.
Also the option 1 of doing the rc now would likely be ok, as the only a few 
targets actually use DSA, so the absence of LuCI support for DSA does not 
concern that many users.



I would prefer if we merge the LuCI DSA changes from master to 21.02 branch 
now and do 21.02-rc1 soon. We should list the problems as known problems.


It would be nice if someone else could also look into these problems and 
propose fixes.



Like with previous releases, the developers interest mainly stays on the 
master, and not much happens in the new release branch...


It is now 50 days since the 21.02 was branched in February, so a high time to 
get the rc out.





___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Luci / Custom Commands

[Hannu Nyman]

e9hack kirjoitti 16.4.2021 klo 8.37:

Hi,

I want like to add the following command to Luci/Custom Commands:

echo "/" > /proc/net/xt_recent/SSH_BLOCK

But I can only add:

echo "> /proc/net/xt_recent/SSH_BLOCK"

How can I do it?



I thought that easiest might be yo manually edit the uci config file, but I 
experience no difficulty even in LuCI with 21.02, when I test your example 
from GUI. It is visible in GUI, and gets in right format into /etc/config/luci


Also execution seems to go (I will send the screenshot separately as it might 
not get into).


So I am not sure what is the exact difficulty???   If the difficulty is in 
exeution, it might be about parsing uci / javascript with special chars like 
">" and "/" plus passing them to the shell combo.



One easy solution might to manually edit a script file with that required 
command  into /etc and then using LuCI only to execute that script.  The 
LuCI commands feature is not meant for really complex things.




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] mtd: correct/change warning text about partition split / read-only status

[Hannu Nyman]

Since the kernel/rootfs split handling was modified 2 years ago by r37283 ( 
https://dev.openwrt.org/changeset/37283 ) and by the subsequent checkins, 
users have seen rather scary mtd errors in the log at every boot. The message 
ends "-- forcing read-only", which looks a bit error-like. That error has 
been mentioned in some forum threads, when users have noticed this message 
instead of some actual error.


[2.94] 0x0007-0x00ff : "firmware"
[2.97] 2 netgear-fw partitions found on MTD device firmware
[2.97] 0x0007-0x00188440 : "kernel"
[2.98] mtd: partition "kernel" must either start or end on erase 
block boundary or be smaller than an erase block -- forcing read-only

[2.99] 0x00188440-0x00ff : "rootfs"
[2.99] mtd: partition "rootfs" must either start or end on erase 
block boundary or be smaller than an erase block -- forcing read-only

[3.01] mtd: device 4 (rootfs) set to be root filesystem
[3.01] 1 squashfs-split partitions found on MTD device rootfs
[3.02] 0x0066-0x00ff : "rootfs_data"

The error text 'mtd: partition "kernel" must either start or end on erase 
block boundary or be smaller than an erase block -- forcing read-only' 
originates from 6 years ago, when nbd checked in r17658 to kernel 2.6.30.

https://dev.openwrt.org/changeset/17658
https://dev.openwrt.org/browser/trunk/target/linux/generic-2.6/patches-2.6.30/222-partial_eraseblock_write.patch?rev=17658

At that time, this message was rarely shown, as it was normal to have padding 
after kernel, so that rootfs started at the next block boundary. Currently 
many platforms have kernel & rootfs tightly packed without padding in 
between, so the message is shown quite frequently.


Additionally, I think that the original warning message has a logical fault: 
the first "or" should be "and". It should say "must either start AND end on 
erase block boundary or be smaller than an erase block".  (otherwise 'kernel' 
should not cause the warning message as it starts at a boundary...). The 
logic in 411-mtd-partial_eraseblock_write.patch is pretty hard to follow, but 
that is my reading about the correct reasoning.
https://dev.openwrt.org/browser/trunk/target/linux/generic/patches-3.18/411-mtd-partial_eraseblock_write.patch 



I propose that the message class is changed from a kernel warning to a kernel 
info message and the text is changed to be less scary: 'partition "kernel" is 
read-only: it does not start and end at erase block boundary and is larger 
than a single block'


[2.97] 2 netgear-fw partitions found on MTD device firmware
[2.97] 0x0007-0x00188440 : "kernel"
[2.98] mtd: partition "kernel" is read-only: it does not start and 
end at erase block boundary and is larger than a single block

[2.99] 0x00188440-0x00ff : "rootfs"
[2.99] mtd: partition "rootfs" is read-only: it does not start and 
end at erase block boundary and is larger than a single block



I would prefer to shorten the message even more, but I didn't invent a 
suitable short but informative wording. (Althoug as this is currently most 
often just an informative notice, I am not quite sure if the logic needs to 
be explained quite that closely in the message.)


Signed-off-by: Hannu Nyman 

--- target/linux/generic/patches-3.18/411-mtd-partial_eraseblock_write.patch
+++ target/linux/generic/patches-3.18/411-mtd-partial_eraseblock_write.patch
@@ -126,7 +126,7 @@
 +  slave->mtd.erasesize = slave->mtd.size;
}
 +  if ((slave->mtd.flags & (MTD_ERASE_PARTIAL|MTD_WRITEABLE)) == 
MTD_ERASE_PARTIAL)
-+  printk(KERN_WARNING"mtd: partition \"%s\" must either start or 
end on erase block boundary or be smaller than an erase block -- forcing 
read-only\n",
++  printk(KERN_INFO"mtd: partition \"%s\" is read-only: it does 
not start and end at erase block boundary and is larger than a single block\n",
 +  part->name);
  
slave->mtd.ecclayout = master->ecclayout;
--- target/linux/generic/patches-4.0/411-mtd-partial_eraseblock_write.patch
+++ target/linux/generic/patches-4.0/411-mtd-partial_eraseblock_write.patch
@@ -126,7 +126,7 @@
 +  slave->mtd.erasesize = slave->mtd.size;
}
 +  if ((slave->mtd.flags & (MTD_ERASE_PARTIAL|MTD_WRITEABLE)) == 
MTD_ERASE_PARTIAL)
-+  printk(KERN_WARNING"mtd: partition \"%s\" must either start or 
end on erase block boundary or be smaller than an erase block -- forcing 
read-only\n",
++  printk(KERN_INFO"mtd: partiti

Re: [OpenWrt-Devel] [PATCH] luci:miniupnpd Fix enabled/disabled behaviour on first boot/upgrade

[Hannu Nyman]

> miniupnpd service was always disabled after firmware upgrade. Original 
luci default logic was 'enable miniupnpd and if that succeeds, stop and then 
disable the service'.  It should be 'enable miniupnpd and if that fails, stop 
& disable the service'.


You got the original script's logic wrong, as you mixed "enable" and "enabled".
"enable" activates the service, while "enabled" is just a query if the 
service is active.

/etc/rc.common defines both of them.

The logic is: query if miniupnpd is active, and if yes, then stop and disable 
it.

The feature has originally been added as a security feature to luci-app-upnp. 
But why it is set in luci, not in the actual miniupnpd package in the routing 
repo?


It originates from 2008: 
https://github.com/openwrt/luci/commit/66fa0eb0e8e206d26e16615941c60b22b5004649
modified in 2011: 
https://github.com/openwrt/luci/commit/6811edb3d9fe289190fbc7337d372027a655daf8

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ustream-ssl: correct year in PKG_VERSION string

[Hannu Nyman]

ustream-ssl: correct the year in the PKG_VERSION string, as both r45157 and 
r45441 left the old year 2014 there. For a casual user it may seem that the 
current code is from April 2014, although 
a4ca61527236e89eb9efb782fd9bfd04796144e3 is from April 2015.


http://nbd.name/gitweb.cgi?p=ustream-ssl.git;a=commit;h=a4ca61527236e89eb9efb782fd9bfd04796144e3
https://dev.openwrt.org/changeset/45441/
https://dev.openwrt.org/changeset/45157/

signed-off-by: Hannu Nyman 

Index: package/libs/ustream-ssl/Makefile
===
--- package/libs/ustream-ssl/Makefile   (revision 45590)
+++ package/libs/ustream-ssl/Makefile   (working copy)
@@ -1,7 +1,7 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=ustream-ssl
-PKG_VERSION:=2014-04-14
+PKG_VERSION:=2015-04-14
 PKG_RELEASE=$(PKG_SOURCE_VERSION)
 
 PKG_SOURCE_PROTO:=git
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] mtd: correct/change warning text about partition split / read-only status

[Hannu Nyman]

mtd: remove the warning about read-only caused by size vs. block boundary 
mismatch


patch version 2 as requested by nbd.

Since the kernel/rootfs split handling was modified 2 years ago by r37283 ( 
https://dev.openwrt.org/changeset/37283 ) and by the subsequent checkins, 
users have seen rather scary mtd errors in the log at every boot. The message 
ends "-- forcing read-only", which looks a bit error-like. That error has 
been mentioned in some forum threads, when users have noticed this message 
instead of some actual error.


[2.94] 0x0007-0x00ff : "firmware"
[2.97] 2 netgear-fw partitions found on MTD device firmware
[2.97] 0x0007-0x00188440 : "kernel"
[2.98] mtd: partition "kernel" must either start or end on erase 
block boundary or be smaller than an erase block -- forcing read-only

[2.99] 0x00188440-0x00ff : "rootfs"

The patch removes the rather useless warning message.

signed-off-by: Hannu Nyman 
---

On 10.5.2015 14:39, Felix Fietkau wrote:

I think this message is quite pointless anyway, so I'd prefer to simply
have it removed instead of changing it.

- Felix



Index: target/linux/generic/patches-3.18/411-mtd-partial_eraseblock_write.patch
===
--- target/linux/generic/patches-3.18/411-mtd-partial_eraseblock_write.patch
(revision 45667)
+++ target/linux/generic/patches-3.18/411-mtd-partial_eraseblock_write.patch
(working copy)
@@ -97,7 +97,7 @@
if (instr->fail_addr != MTD_FAIL_ADDR_UNKNOWN)
instr->fail_addr -= part->offset;
instr->addr -= part->offset;
-@@ -514,18 +582,24 @@ static struct mtd_part *allocate_partiti
+@@ -514,18 +582,21 @@ static struct mtd_part *allocate_partiti
if ((slave->mtd.flags & MTD_WRITEABLE) &&
mtd_mod_by_eb(slave->offset, &slave->mtd)) {
/* Doesn't start on a boundary of major erase size */
@@ -125,9 +125,6 @@
 +  else
 +  slave->mtd.erasesize = slave->mtd.size;
}
-+  if ((slave->mtd.flags & (MTD_ERASE_PARTIAL|MTD_WRITEABLE)) == 
MTD_ERASE_PARTIAL)
-+  printk(KERN_WARNING"mtd: partition \"%s\" must either start or 
end on erase block boundary or be smaller than an erase block -- forcing 
read-only\n",
-+  part->name);
  
slave->mtd.ecclayout = master->ecclayout;
slave->mtd.ecc_step_size = master->ecc_step_size;
Index: target/linux/generic/patches-4.0/411-mtd-partial_eraseblock_write.patch
===
--- target/linux/generic/patches-4.0/411-mtd-partial_eraseblock_write.patch 
(revision 45667)
+++ target/linux/generic/patches-4.0/411-mtd-partial_eraseblock_write.patch 
(working copy)
@@ -97,7 +97,7 @@
if (instr->fail_addr != MTD_FAIL_ADDR_UNKNOWN)
instr->fail_addr -= part->offset;
instr->addr -= part->offset;
-@@ -513,18 +581,24 @@ static struct mtd_part *allocate_partiti
+@@ -513,18 +581,21 @@ static struct mtd_part *allocate_partiti
if ((slave->mtd.flags & MTD_WRITEABLE) &&
mtd_mod_by_eb(slave->offset, &slave->mtd)) {
/* Doesn't start on a boundary of major erase size */
@@ -125,9 +125,6 @@
 +  else
 +  slave->mtd.erasesize = slave->mtd.size;
}
-+  if ((slave->mtd.flags & (MTD_ERASE_PARTIAL|MTD_WRITEABLE)) == 
MTD_ERASE_PARTIAL)
-+  printk(KERN_WARNING"mtd: partition \"%s\" must either start or 
end on erase block boundary or be smaller than an erase block -- forcing 
read-only\n",
-+  part->name);
  
slave->mtd.ecclayout = master->ecclayout;
slave->mtd.ecc_step_size = master->ecc_step_size;
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] Makefile: remove non-existent STAGING_DIR_TOOLCHAIN from dirclean

[Hannu Nyman]

Makefile: remove non-existent STAGING_DIR_TOOLCHAIN from dirclean

Openwrt's top level Makefile uses STAGING_DIR_TOOLCHAIN in the make dirclean 
statement.

https://dev.openwrt.org/browser/trunk/Makefile#L55
   rm -rf $(STAGING_DIR) $(STAGING_DIR_HOST) $(STAGING_DIR_TOOLCHAIN) 
$(TOOLCHAIN_DIR) $(BUILD_DIR_HOST) $(BUILD_DIR_TOOLCHAIN)


As far as I can determine, no such variable has been defined. I made a search 
in Openwrt source repository and the one line in Makefile's dirclean command 
is the only place where that variable exists.


The item has been introduced to Makefile by r8362, but even at that time 
neither Makefile nor rules.mk defined such a variable. Most likely the goal 
has been to set both staging_dir/toolchain and build_dir/toolchain to be 
cleaned, but one of the variables has been erroneous. The correct variable 
for build_dir/toolchain has been then added by r13494.


References:
https://dev.openwrt.org/changeset/8362/
https://dev.openwrt.org/browser/trunk/Makefile?rev=8362
https://dev.openwrt.org/browser/trunk/rules.mk?rev=8362
https://lists.openwrt.org/pipermail/openwrt-devel/2007-August/001159.html
https://dev.openwrt.org/changeset/13494

In current code,
   TOOLCHAIN_DIR = $(TOPDIR)/staging_dir/$(TOOLCHAIN_DIR_NAME)
   BUILD_DIR_TOOLCHAIN = $(TOPDIR)/build_dir/$(TOOLCHAIN_DIR_NAME)
so the item STAGING_DIR_TOOLCHAIN in the rm command is unnecessary.

signed-off-by: Hannu Nyman 

Index: Makefile
===
--- Makefile(revision 45669)
+++ Makefile(working copy)
@@ -53,7 +53,7 @@
rm -rf $(BUILD_DIR) $(BIN_DIR) $(BUILD_LOG_DIR)
 
 dirclean: clean
-   rm -rf $(STAGING_DIR) $(STAGING_DIR_HOST) $(STAGING_DIR_TOOLCHAIN) 
$(TOOLCHAIN_DIR) $(BUILD_DIR_HOST) $(BUILD_DIR_TOOLCHAIN)
+   rm -rf $(STAGING_DIR) $(STAGING_DIR_HOST) $(TOOLCHAIN_DIR) 
$(BUILD_DIR_HOST) $(BUILD_DIR_TOOLCHAIN)
rm -rf $(TMP_DIR)
 
 ifndef DUMP_TARGET_DB
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [BB 14.07] No automatic buildbot anymore ???

[Hannu Nyman]

To my knowledge theer has never been automatic building for the relase 
branches. Developers have selectively built core packages (like openssl) 
after security updates, but otherwise the updated package sources have been 
compiled only for the .1 maintenance releases (like 10.03.1). But so far 
there has been no .1 release BB14.07. (and most likely none will be ever 
released, as the CC15.05 release will get the focus)


People building private BB14.07 builds do get the updates, naturally.


On 17.5.2015 15:51, Christian Schoenebeck wrote:

Hi,
I fixed some LuCI language files about 3 weeks ago, but downloads.openwrt.org 
is still on 29.09.2014.
Are there no updates build for BB 14.07 ?
Christian


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] scripts/feeds: Return non-zero return code if updating of a feed failed.

[Hannu Nyman]

I tested the patch in my build system and it seems to work ok.

Having a proper error code from the feeds updating would enable better 
control flow in a build script, so hopefully this gets accepted.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] scripts/feeds: Return non-zero return code if updating of a feed failed.

[Hannu Nyman]

John Crispin wrote:
> also i am not sure if we want the script to abort if one of the feeds has 
failed


The typical scenario for somone building regularly private builds is that 
updating fails due to conflicting local modifications. The user might have a 
"daily" build script that updates the sources and then continues with the 
build. Having the build script to stop after a feed update failure is 
practical. You generally want to fix the conflict instead of just charging 
blindly ahead and building from partially stale sources.


For example, my build environment contains this proposed patch and the daily 
build script includes check for update failure:

  ./scripts/feeds update -a
  [ "$?" -ne 0 ] && echo "Updating the feeds failed." && exit 1


If you feel that the "break after one feed fails to update" is to strict, one 
solution could be to continue updating other feeds despite the failure, but 
still return the error code in any case just to indicate that one feed 
failed. That would enable the user to select, if he wants to check for that 
error code.


Currently the error code is lost. There is no feedback of a possible failure.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] Makefile: move cleaning of staging_dir/target* to clean instead of dirclean

[Hannu Nyman]

Makefile: move the cleaning of staging_dir/target* from dirclean to clean

Currently "make clean" only clears the build_dir/target*, but leaves 
staging_dir/target* intact. "make clean" should also clean the 
staging_dir/target* directories, as in the current situation some old 
packages or libraries may be linked into the firmware from staging_dir 
despite a "make clean".


The patch reorganises clean / dirclean functionality so that
* "make clean" also clears the staging_dir/target* in addition to 
build_dir/target*.
* "make dirclean" clears toolchain and host(=tools) directories from both 
build_dir and staging_dir


signed-off-by: Hannu Nyman 
---
This patch is continuation to r45736.  ( 
https://dev.openwrt.org/changeset/45736 )


The behaviour, where "make clean" does not clear staging_dir/target* can 
leave into problems when some package version gets bumped and some filenames 
change etc. It is possible that duplicated binaries can be found in 
staging_dir despite the user having run "make clean".


I have been burned by that in the past few months, but luckily both jow and 
arokh have pointed me to right direction.


Below are the directory definitions clarifying the variables and also an 
example that shows how staging_dir/target* contains quite many files after a 
make clean.


Directory definitions:
https://dev.openwrt.org/browser/trunk/rules.mk

BUILD_DIR_BASE:=$(TOPDIR)/build_dir

BUILD_DIR:=$(BUILD_DIR_BASE)/$(TARGET_DIR_NAME)
STAGING_DIR:=$(TOPDIR)/staging_dir/$(TARGET_DIR_NAME)

STAGING_DIR_HOST:=$(TOPDIR)/staging_dir/host
TOOLCHAIN_DIR:=$(TOPDIR)/staging_dir/$(TOOLCHAIN_DIR_NAME)
BUILD_DIR_HOST:=$(BUILD_DIR_BASE)/host
BUILD_DIR_TOOLCHAIN:=$(BUILD_DIR_BASE)/$(TOOLCHAIN_DIR_NAME)


Example:


perus@vb1504:/Openwrt/trunk$ make clean
 make[1] clean

perus@vb1504:/Openwrt/trunk$ ls build_dir/
host
toolchain-mips_34kc_gcc-4.8-linaro_uClibc-0.9.33.2

perus@vb1504:/Openwrt/trunk$ ls staging_dir/
host
target-mips_34kc_uClibc-0.9.33.2
toolchain-mips_34kc_gcc-4.8-linaro_uClibc-0.9.33.2

perus@vb1504:/Openwrt/trunk$ du -d1 
staging_dir/target-mips_34kc_uClibc-0.9.33.2/
1604staging_dir/target-mips_34kc_uClibc-0.9.33.2/pkginfo
26432staging_dir/target-mips_34kc_uClibc-0.9.33.2/usr
4staging_dir/target-mips_34kc_uClibc-0.9.33.2/include
180staging_dir/target-mips_34kc_uClibc-0.9.33.2/packages
2396staging_dir/target-mips_34kc_uClibc-0.9.33.2/host
4staging_dir/target-mips_34kc_uClibc-0.9.33.2/bin
4staging_dir/target-mips_34kc_uClibc-0.9.33.2/stamp
51688staging_dir/target-mips_34kc_uClibc-0.9.33.2/root-ar71xx
4staging_dir/target-mips_34kc_uClibc-0.9.33.2/lib
82320staging_dir/target-mips_34kc_uClibc-0.9.33.2/


Index: Makefile
===
--- Makefile(revision 45741)
+++ Makefile(working copy)
@@ -50,10 +50,10 @@
 prepare: $(target/stamp-compile)
 
 clean: FORCE
-   rm -rf $(BUILD_DIR) $(BIN_DIR) $(BUILD_LOG_DIR)
+   rm -rf $(BUILD_DIR) $(STAGING_DIR) $(BIN_DIR) $(BUILD_LOG_DIR)
 
 dirclean: clean
-   rm -rf $(STAGING_DIR) $(STAGING_DIR_HOST) $(TOOLCHAIN_DIR) 
$(BUILD_DIR_HOST) $(BUILD_DIR_TOOLCHAIN)
+   rm -rf $(STAGING_DIR_HOST) $(TOOLCHAIN_DIR) $(BUILD_DIR_HOST) 
$(BUILD_DIR_TOOLCHAIN)
rm -rf $(TMP_DIR)
 
 ifndef DUMP_TARGET_DB
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] scripts/feeds: return error status from feed updating (alternative approach)

[Hannu Nyman]

scripts/feeds: return error status from feed update

This patch is a modified version of the patch being discussed at here:
https://patchwork.ozlabs.org/patch/471303/from Martin Strbacka 



My version modifies scripts/feeds so that an error with one of the feeds just 
raises the error flag, but script continues and tries to update the other 
feeds. After all feeds have been updated, the script returns 1 if at least 
one feed failed, and 0 on success with all feeds. The user can then utilise 
the status in his build script, if he wants.


signed-off-by: Hannu Nyman 

Index: scripts/feeds
===
--- scripts/feeds   (revision 45743)
+++ scripts/feeds   (working copy)
@@ -687,6 +687,7 @@
my %opts;
my $feed_name;
my $perform_update=1;
+   my $failed=0;
 
$ENV{SCAN_COOKIE} = $$;
$ENV{OPENWRT_VERBOSE} = 's';
@@ -711,8 +712,7 @@
if ( ($#ARGV == -1) or $opts{a}) {
foreach my $feed (@feeds) {
my ($type, $name, $src) = @$feed;
-   next unless update_feed($type, $name, $src, 
$perform_update) == 1;
-   last;
+   update_feed($type, $name, $src, $perform_update) == 0 
or $failed=1;
}
} else {
while ($feed_name = shift @ARGV) {
@@ -721,7 +721,7 @@
if($feed_name ne $name) {
next;
}
-   update_feed($type, $name, $src, 
$perform_update);
+   update_feed($type, $name, $src, 
$perform_update) == 0 or $failed=1;
}
}
}
@@ -728,7 +728,7 @@
 
refresh_config();
 
-   return 0;
+   return $failed;
 }
 
 sub feed_config() {
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] scripts/feeds: Return non-zero return code if updating of a feed failed.

[Hannu Nyman]

On 22.5.2015 16:59, John Crispin wrote:

also i am not sure if we want the script to abort if one of the feeds
has failed



I have submitted an alternative version that simplifies the code and just 
returns the error information, but tries to update all feeds despite failure 
at one of them.


https://patchwork.ozlabs.org/patch/475985/
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] bc: add download mirrors

[Hannu Nyman]

bc: add download mirrors

Add three download mirrors for 'bc', as the Makefile currently defines only 
one download location.


@GNU can not be used, as the most recent version of 'bc' is not available at 
the general GNU mirrors,

and can only be found at the "gnu-alpha" mirrors.

Signed-off-by: Hannu Nyman 
---

A forum discussion brought 'bc' download problems into my attention:
https://forum.openwrt.org/viewtopic.php?id=57803

The package Makefile defines only a single download server that was down, and 
the file is not available at the Openwrt mirrors.


The most recent 'bc' is not available in most of the GNU mirrors, so I 
searched a bit and found three mirrors of "GNU alpha", which I added to the 
Makefile.


Index: tools/bc/Makefile
===
--- tools/bc/Makefile   (revision 45907)
+++ tools/bc/Makefile   (working copy)
@@ -10,7 +10,11 @@
 PKG_VERSION:=1.06.95
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
-PKG_SOURCE_URL:=http://alpha.gnu.org/gnu/bc
+PKG_SOURCE_URL:=http://alpha.gnu.org/gnu/bc \
+   http://gnualpha.uib.no/bc/ \
+   http://mirrors.fe.up.pt/pub/gnu-alpha/bc/ \
+   http://www.nic.funet.fi/pub/gnu/alpha/gnu/bc/ 
+   
 PKG_MD5SUM:=5126a721b73f97d715bb72c13c889035
 
 include $(INCLUDE_DIR)/host-build.mk
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] bc: add download mirrors

[Hannu Nyman]

bc: add download mirrors

Add three download mirrors for 'bc', as the Makefile currently defines only 
one download location.


@GNU can not be used, as the most recent version of 'bc' is not available at 
the general GNU mirrors, and can only be found at the "gnu-alpha" mirrors.


Signed-off-by: Hannu Nyman 
---
Patch v2 corrects whitespace in the Makefile.

A forum discussion brought 'bc' download problems into my attention:
https://forum.openwrt.org/viewtopic.php?id=57803

The package Makefile defines only a single download server and the file is 
not available at the Openwrt mirrors.


The most recent 'bc' is not available in most of the GNU mirrors, so @GNU is 
unusable. I searched a bit and found three mirrors of "GNU alpha", which I 
added to the Makefile.


Index: tools/bc/Makefile
===
--- tools/bc/Makefile   (revision 45907)
+++ tools/bc/Makefile   (working copy)
@@ -10,7 +10,10 @@
 PKG_VERSION:=1.06.95
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
-PKG_SOURCE_URL:=http://alpha.gnu.org/gnu/bc
+PKG_SOURCE_URL:=http://alpha.gnu.org/gnu/bc \
+   http://gnualpha.uib.no/bc/ \
+   http://mirrors.fe.up.pt/pub/gnu-alpha/bc/ \
+   http://www.nic.funet.fi/pub/gnu/alpha/gnu/bc/
 PKG_MD5SUM:=5126a721b73f97d715bb72c13c889035
 
 include $(INCLUDE_DIR)/host-build.mk
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] grub: add download mirrors

[Hannu Nyman]

grub: add download mirrors

Add three download mirrors for 'grub', as the Makefile currently defines only 
one download location.


@GNU can not be used, as the most recent version of 'grub' is not available 
at the general GNU mirrors, and can only be found at the "gnu-alpha" mirrors.


Signed-off-by: Hannu Nyman 
---

A forum discussion brought 'bc' download problems into my attention:
https://forum.openwrt.org/viewtopic.php?id=57803

I sent a patch about bc and then searched Openwrt sources for other similar 
packages. In the core packages only grub has the same alpha.gnu.org download 
location definition. The most recent version of grub is also not available at 
the Openwrt download mirrors. So I submit also a patch regarding grub.


Index: package/boot/grub2/Makefile
===
--- package/boot/grub2/Makefile (revision 45907)
+++ package/boot/grub2/Makefile (working copy)
@@ -1,5 +1,5 @@
 #
-# Copyright (C) 2006-2010 OpenWrt.org
+# Copyright (C) 2006-2015 OpenWrt.org
 #
 # This is free software, licensed under the GNU General Public License v2.
 # See /LICENSE for more information.
@@ -13,7 +13,10 @@
 PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
-PKG_SOURCE_URL:=http://alpha.gnu.org/gnu/grub
+PKG_SOURCE_URL:=http://alpha.gnu.org/gnu/grub \
+   http://gnualpha.uib.no/grub/ \
+   http://mirrors.fe.up.pt/pub/gnu-alpha/grub/ \
+   http://www.nic.funet.fi/pub/gnu/alpha/gnu/grub/
 PKG_MD5SUM:=be62932eade308a364ea4bbc91295930
 
 HOST_BUILD_PARALLEL:=1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] openssl: bump to 1.0.2c

[Hannu Nyman]

Openssl has received a version bump from one-day old 1.0.2b to 1.0.2c...

https://mta.openssl.org/pipermail/openssl-announce/2015-June/35.html
http://www.openssl.org/news/openssl-1.0.2-notes.html
Changes between 1.0.2b and 1.0.2c [12 Jun 2015]
 Fix HMAC ABI incompatibility. The previous version introduced an ABI
 incompatibility in the handling of HMAC. The previous ABI has now been
 restored.

signed-off-by: Hannu Nyman 

Index: package/libs/openssl/Makefile
===
--- package/libs/openssl/Makefile   (revision 45949)
+++ package/libs/openssl/Makefile   (working copy)
@@ -8,7 +8,7 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=openssl
-PKG_VERSION:=1.0.2b
+PKG_VERSION:=1.0.2c
 PKG_RELEASE:=1
 PKG_USE_MIPS16:=0
 
@@ -18,7 +18,7 @@
 PKG_SOURCE_URL:=http://www.openssl.org/source/ \
ftp://ftp.funet.fi/pub/crypt/mirrors/ftp.openssl.org/source \
ftp://ftp.sunet.se/pub/security/tools/net/openssl/source/
-PKG_MD5SUM:=7729b259e2dea7d60b32fc3934d6984b
+PKG_MD5SUM:=8c8d81a9ae7005276e486702edbcd4b6
 
 PKG_LICENSE:=OpenSSL
 PKG_LICENSE_FILES:=LICENSE
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Package list signing keys: Does the release build system use different keys than snapshots?

[Hannu Nyman]

I created my first build from the brand-new CC15.05 chaos_calmer branch. I 
patched include/version.mk to get the version right, but no other changes 
were needed.


The build is otherwise ok, but opkg does not accept package list signatures 
from the 15.05-rc2 directory. When I try opkg update, I get this:


>> Downloading 
http://downloads.openwrt.org/chaos_calmer/15.05-rc2/ar71xx/generic/packages/base/Packages.gz.

>> Updated list of available packages in /var/opkg-lists/chaos_calmer_base.
>> Downloading 
http://downloads.openwrt.org/chaos_calmer/15.05-rc2/ar71xx/generic/packages/base/Packages.sig.

>> Signature check failed.
>> Remove wrong Signature file.

Have the rc2 binaries been created with a different key than the snapshots?

r45905 added the snapshot key to the base-files, which enables private builds 
to fetch snapshot package lists from the snapshots. 
https://dev.openwrt.org/changeset/45905/


Probably something similar needs to be done for the release build keys. Right?

I propose that developers add the release build signing keys to base-files, 
at least in the chaos_calmer branch, but probably also into trunk so that the 
next branches will avoid the problem.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Renaming trunk to Dxx Dxx ?

[Hannu Nyman]

Please rename trunk to Dxxx Dxxx something.

It is a bit confusing when both trunk and CC15.05 claim to be Chaos Calmer. 
The clear identification of the two got more important now when trunk has 
started to use musl, and trunk and CC start to deviate further.


I considered patching trunk's include/toplevel.mk and etc/banner in my own 
build to something imaginary, but it would much better if the official new 
name gets assigned (or should I say designated?) soon.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] opkg.conf as preserved config file in sysupgrade is creating problems (especially after package signing)

[Hannu Nyman]

/etc/opkg.conf has been declared a config file and is thus preserved in an 
sysupgrade.

https://dev.openwrt.org/browser/trunk/package/system/opkg/Makefile#L65

After the package list signing has been enabled, that is really hurting with 
upgrading: the old opkg.conf gets preseverd and points to the old version's 
repo. If user doesn't realise that and the build's signing key has changed, 
the user gets practically locked out of "opkg update", as package list 
signature check will fail.


Apparently 15.05-rc2 did not include luci (at least not all the platforms), 
so there are severeal forum discussions & bugs about "rc2 without luci  + 
unability to install luci". For example:

https://forum.openwrt.org/viewtopic.php?pid=280016#p280016
https://forum.openwrt.org/viewtopic.php?id=58016
https://dev.openwrt.org/ticket/19853

Earlier the problem has been more hidden, as e.g. Luci from rc1 does not 
differ that much from rc2, and installing the old version has not hurt. Now 
the signature check removes that possibility, especially when switching 
between release to snapshot builds, (or possibly between difeerent releases 
if different keys are used).


My proposal to developers is to remove the config file status from opkg.conf.
Then a new opkg.conf would be installed along a new firmware and it would 
point to the correct binary repo for the current firmware. That would improve 
the user experience of an average user, who doesn't really care about deeper 
system innards.


Overwriting the user's opkg.conf may hurt some users, but probably a small 
minority of experienced users, so I would


Other possibility could be divide opkg.conf into two: a build-specific 
default download repo list (to be overwritten in sysupgrade) and a 
user-specific config file with config options and possible additional 
download locations (to be preserved).


Any opinions?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] How to keep disabled services disabled after sysupgrade

[Hannu Nyman]

I first looked into this 4 years ago and finally figured it out 2 years ago ;-)
https://forum.openwrt.org/viewtopic.php?pid=189700#p189700

There is no built-in way to keep those services installed but disabled.
But there is a go-around that is used e.g. by luci-app-miniupnpd for miniupnpd:
https://github.com/openwrt/luci/blob/master/applications/luci-app-upnp/root/etc/uci-defaults/luci-upnp

Create an uci-defaults script in /etc/uci-defaults and disable the unwanted 
services there.
Include that script as a custom file in the firmware flash, in 
/files/etc/uci-defaults


uci-defaults scripts are run early in the first boot after flash, so the 
script will disable the services early.
Normally uci-defaults scripts are deleted after a succesful run, but by 
setting a non-zero return value you can preserve the scripts even for further 
boots to maintain the disabling behaviour even if the user enables the 
service and reboots.


uci-defaults scripts are difficult to see in a live system as the directory 
/etc/uci-defaults is empty, but you can find the scripts in 
/rom/etc/uci-defaults:

root@OpenWrt:~# ls /etc/uci-defaults/
root@OpenWrt:~# ls /rom/etc/uci-defaults/
00_uhttpd_ubus10-fstab luci-ddns
01_leds   10_migrate-shadow luci-sqm
...

Docs at: http://wiki.openwrt.org/doc/uci#defaults



On 18.6.2015 14:28, Stefan Tomanek wrote:

Can anyone supply any different ideas or provide some feedback?


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] px5g-standalone: fix compilation after fortify-headers

[Hannu Nyman]

px5g-standalone: fix compilation after fortify-headers

New fortify-headers functionality (default after r46117) is apparently 
conflicting with gcc "-pedantic" option. The package px5g-standalone fails to 
compile due to "error: #include_next is a GCC extension" errors. See 
https://dev.openwrt.org/ticket/19975


Fix the compilation of px5g-standalone by removing the "-pedantic" gcc option.

Signed-off-by: Hannu Nyman 

Index: package/utils/px5g-standalone/src/Makefile
===
--- package/utils/px5g-standalone/src/Makefile  (revision 46117)
+++ package/utils/px5g-standalone/src/Makefile  (working copy)
@@ -1,7 +1,7 @@
 CFLAGS?=-O2
 CFLAGS+=
 SFLAGS:=--std=gnu99
-WFLAGS:=-Wall -Werror -pedantic
+WFLAGS:=-Wall -Werror
 LDFLAGS?=
 BINARY:=px5g
 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] opkg: Extend 'opkg list' command to optionally display package size

[Hannu Nyman]

'opkg list' command only displays the available packages' name, version and 
description.

It would be useful to also see the approximate size of the available package.

This patch extends "opkg list" command with "--size" to optionally show also 
the *.ipk size in the listing.
* Default behaviour is to print the list of available packages as earlier: 
"name - version - description"

* with "--size" the output of is "name - version - size - description".

All current functionality should continue working without any change. Luci 
might be extended to utilize the new options to e.g. answer 
https://github.com/openwrt/luci/issues/19


Signed-off-by: Hannu Nyman < hannu.ny...@iki.fi>

---

Tested with ar71xx / WNDR3700:

opkg package size increase is minimal:

root@OpenWrt2:~# ls -l /bin/opkg
-rwxr-xr-x1 root root101532 Aug 29 23:05 /bin/opkg

root@OpenWrt2:~# opkg install 
/tmp/opkg_9c97d5ecd795709c8584e972bfdf3aee3a5b846d-9_ar71xx.ipk
Upgrading opkg on root from 9c97d5ecd795709c8584e972bfdf3aee3a5b846d-8 to 
9c97d5ecd795709c8584e972bfdf3aee3a5b846d-9...

Configuring opkg.

root@OpenWrt2:~# ls -l /bin/opkg
-rwxr-xr-x1 root root101548 Aug 29 23:05 /bin/opkg

--size works as expected:
(packages not from "packages" feed have been removed for clarity)

root@OpenWrt2:/tmp# opkg list j*
jansson - 2.7-1 - Jansson is a C library for encoding, decoding and 
manipulating JSON data

joe - 4.0-4 - Joe is world-famous Wordstar like text editor, that also features
 Emacs and Pico emulation
jpeg-tools - 9a-1 - The Independent JPEG Group's JPEG manipulation tools
json4lua - 0.9.53-1 - JSON and JSONRPC for Lua

root@OpenWrt2:/tmp# opkg list --size j*
jansson - 2.7-1 - 19182 - Jansson is a C library for encoding, decoding and 
manipulating JSON data
joe - 4.0-4 - 173911 - Joe is world-famous Wordstar like text editor, that 
also features

 Emacs and Pico emulation
jpeg-tools - 9a-1 - 31188 - The Independent JPEG Group's JPEG manipulation tools
json4lua - 0.9.53-1 - 7205 - JSON and JSONRPC for Lua

-
https://downloads.openwrt.org/snapshots/trunk/ar71xx/generic/packages/packages/

jansson_2.7-1_ar71xx.ipk   26-Aug-2015 
05:20   19182
joe_4.0-4_ar71xx.ipk   26-Aug-2015 
05:20  173911
jpeg-tools_9a-1_ar71xx.ipk 26-Aug-2015 
00:04   31188
json4lua_0.9.53-1_ar71xx.ipk   26-Aug-2015 
05:217205




Index: package/system/opkg/Makefile
===
--- package/system/opkg/Makefile(revision 46751)
+++ package/system/opkg/Makefile(working copy)
@@ -1,5 +1,5 @@
 #
-# Copyright (C) 2006-2014 OpenWrt.org
+# Copyright (C) 2006-2015 OpenWrt.org
 #
 # This is free software, licensed under the GNU General Public License v2.
 # See /LICENSE for more information.
@@ -12,7 +12,7 @@
 PKG_NAME:=opkg
 PKG_REV:=9c97d5ecd795709c8584e972bfdf3aee3a5b846d
 PKG_VERSION:=$(PKG_REV)
-PKG_RELEASE:=8
+PKG_RELEASE:=9
 
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_VERSION:=$(PKG_REV)
Index: package/system/opkg/patches/250-add-print-package-size.patch
===
--- package/system/opkg/patches/250-add-print-package-size.patch
(revision 0)
+++ package/system/opkg/patches/250-add-print-package-size.patch
(working copy)
@@ -0,0 +1,74 @@
+--- a/libopkg/opkg_conf.c
 b/libopkg/opkg_conf.c
+@@ -69,6 +69,7 @@ opkg_option_t options[] = {
+ { "proxy_passwd", OPKG_OPT_TYPE_STRING, &_conf.proxy_passwd },
+ { "proxy_user", OPKG_OPT_TYPE_STRING, &_conf.proxy_user },
+ { "query-all", OPKG_OPT_TYPE_BOOL, &_conf.query_all },
++{ "size", OPKG_OPT_TYPE_BOOL, &_conf.size },
+ { "tmp_dir", OPKG_OPT_TYPE_STRING, &_conf.tmp_dir },
+ { "verbosity", OPKG_OPT_TYPE_INT, &_conf.verbosity },
+ #if defined(HAVE_OPENSSL)
+--- a/libopkg/opkg_conf.h
 b/libopkg/opkg_conf.h
+@@ -88,6 +88,7 @@ struct opkg_conf
+  int query_all;
+  int verbosity;
+  int noaction;
++ int size;
+  int download_only;
+  char *cache;
+ 
+--- a/src/opkg-cl.c
 b/src/opkg-cl.c
+@@ -52,6 +52,7 @@ enum {
+   ARGS_OPT_AUTOREMOVE,
+   ARGS_OPT_CACHE,
+   ARGS_OPT_FORCE_SIGNATURE,
++  ARGS_OPT_SIZE,
+ };
+ 
+ static struct option long_options[] = {
+@@ -98,6 +99,7 @@ static struct option long_options[] = {
+   {"offline-root", 1, 0, 'o'},
+   {"add-arch", 1, 0, ARGS_OPT_ADD_ARCH},
+   {"add-dest", 1, 0, ARGS_OPT_ADD_DEST},
++  {"size", 0, 0, ARGS_OPT_SIZE},
+   {"test", 0, 0, ARGS_OPT_NOACTION},
+   {"tmp-dir", 1, 0, 't'},
+

Re: [OpenWrt-Devel] [PATCH] opkg: Extend 'opkg list' command to optionally display package size

[Hannu Nyman]

I created a Luci implementation that utilises this opkg change to show the 
.ipk size to the user in GUI:

https://github.com/openwrt/luci/issues/19#issuecomment-136397807


On 30.8.2015 17:37, Hannu Nyman wrote:
... Luci might be extended to utilize the new options to e.g. answer 
https://github.com/openwrt/luci/issues/19



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] Add 'traceroute6' to busybox default features

[Hannu Nyman]

This patch adds 'traceroute6' to the default features of Busybox.

Signed-off-by: Hannu Nyman 
---

Reference to earlier discussion:
https://lists.openwrt.org/pipermail/openwrt-devel/2015-August/034828.html

On Sat Aug 1 16:47:02 CEST 2015 Felix Fietkau wrote:
> On 2015-08-01 13:04, Bastian Bittorf wrote:
> > i build it for ar71xx, and these are the numbers [bytes]:
> >
> > before:
> > 359736 build_dir/target-mips_34kc_musl-1.1.10/busybox-1.23.2/busybox
> > 208071 bin/ar71xx/packages/base/busybox_1.23.2-1_ar71xx.ipk
> >
> > after:
> > 359884 build_dir/target-mips_34kc_musl-1.1.10/busybox-1.23.2/busybox
> > 209115 bin/ar71xx/packages/base/busybox_1.23.2-1_ar71xx.ipk
> >
> > so it adds ~1k to the image. (strange that uncompressed ~148 bytes)
> > it's as simple as adding CONFIG_BUSYBOX_CONFIG_TRACEROUTE6=y
> > what do you think?
> Feel free to send a patch.
>
> - Felix

Index: package/utils/busybox/Config-defaults.in
===
--- package/utils/busybox/Config-defaults.in(revision 46773)
+++ package/utils/busybox/Config-defaults.in(working copy)
@@ -2229,7 +2229,7 @@
default y
 config BUSYBOX_DEFAULT_TRACEROUTE6
bool
-   default n
+   default y
 config BUSYBOX_DEFAULT_FEATURE_TRACEROUTE_VERBOSE
bool
default y
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] Restore 640-bridge_no_eap_forward.patch to its original form

[Hannu Nyman]

> Please state the svn revision and/or the commit subject in () to make > it 
easier to find the offending commit.


The "offending commit" seems to be r38528 , the introduction of Linux 3.12.

https://dev.openwrt.org/changeset/38528
https://dev.openwrt.org/changeset/38528#file55

http://git.openwrt.org/?p=openwrt.git;a=commit;h=62a2176cb1446f865b58299f080493f26ce53573 
___

openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Removing Telnet

[Hannu Nyman]

Steven Barth wrote at Wed Sep 9 08:10:18 CEST 2015:
> Lack of entropy doesn't seem to be too much of an issue here, in fact in 
failsafe mode we generate a 1024 bit RSA-key on demand which takes <2s on my 
old Buffalo here. Granted its only 1024-bit but still. Now the regular keys 
are 2048-bit which takes about a minute which could be seen as problematic.


That time seems to vary by router. I tested yesterday with my ar71xx/WNDR3700 
r46803:
removing the RSA-key before reboot (and thus forcing the dropbear init script 
to generate a new key before launching the actual dropbear process) will 
delay the launch of the dropbear process by some 15 seconds. That can be 
easily seen from the system log by comparing the timestamps and the position 
of dropbear startup message in the log. The 15 second delay was consistent on 
several reboots with r46803.


Running the dropbear key generation manually from console takes only 2-3 
seconds, but then the router is already fully up and has generated more entropy.



Interestingly, right now with r46832, the recent ip/ifconfig changes have 
apparently caused some additional lag to the key generation in a normal boot, 
as the dropbear startup delay with key generation is now 39 seconds. Below 
are two log excerpts showing the impact.
* If RSA key exists, the dropbear startup is consistently at the same place 
right after mtdblock handling.
* If the key needs to be generated, dropbear starts 39 secs later. (log shows 
the sysfixtime clock jump for clarity)


I briefly tested the failsafe mode, and there dropbear ssh seems to be 
reachable some 15-20 seconds after the failsafe mode has been selected (led 
blinks rapidly). That is consistent with the yesterday's observations about 
the key generation at startup.


Reboot, normal, RSA key exists
=
Tue Sep  8 22:40:01 2015 kern.info kernel: [   18.152072] ieee80211 phy1: 
Atheros AR9280 Rev:2 mem=0xb001, irq=41
Tue Sep  8 22:40:03 2015 user.emerg : this file has been obsoleted. please 
call "/sbin/block mount" directly
Tue Sep  8 22:40:04 2015 daemon.err block: mounting /dev/mtdblock4 (squashfs) 
as /mnt/mtdblock4 failed (-1) - No error information

Tue Sep  8 22:40:04 2015 daemon.err block: /dev/mtdblock5 is already mounted
Tue Sep  8 22:40:05 2015 authpriv.warn dropbear[1251]: Failed loading 
/etc/dropbear/dropbear_ecdsa_host_key

Tue Sep  8 22:40:05 2015 authpriv.info dropbear[1251]: Not backgrounding
Tue Sep  8 22:40:06 2015 daemon.err insmod: module is already loaded - 
xt_multiport

Tue Sep  8 22:40:06 2015 daemon.err insmod: module is already loaded - 
xt_comment
Tue Sep  8 22:40:06 2015 daemon.err insmod: module is already loaded - xt_length
Tue Sep  8 22:40:07 2015 daemon.err insmod: module is already loaded - 
xt_multiport
Tue Sep  8 22:40:07 2015 kern.debug kernel: [   26.527131] ar71xx: pll_reg 
0xb8050010: 0x



Reboot, RSA key deleted before reboot
=
Tue Sep  8 22:40:04 2015 daemon.err block: mounting /dev/mtdblock4 (squashfs) 
as /mnt/mtdblock4 failed (-1) - No error information

Tue Sep  8 22:40:04 2015 daemon.err block: /dev/mtdblock5 is already mounted
Tue Sep  8 22:40:06 2015 daemon.err insmod: module is already loaded - 
xt_multiport

Tue Sep  8 22:40:06 2015 daemon.err insmod: module is already loaded - 
xt_comment
Tue Sep  8 22:40:06 2015 daemon.err insmod: module is already loaded - xt_length
...
Tue Sep  8 22:40:36 2015 user.notice SQM: cur_target: auto cur_bandwidth: 1
Wed Sep  9 10:57:12 2015 user.notice SQM: get_target defaulting to auto.
...
Wed Sep  9 10:57:21 2015 authpriv.warn dropbear[3625]: Failed loading 
/etc/dropbear/dropbear_ecdsa_host_key

Wed Sep  9 10:57:21 2015 authpriv.info dropbear[3625]: Not backgrounding
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Renaming trunk to Dxx Dxx ?

[Hannu Nyman]

I repeat my earlier wish that trunk should be renamed as soon as possible.

There has been several changes during the summer that have made trunk to 
significantly deviate from the CC branch. Some of the changes are under the 
hood (like musl vs. uClibc), but especially the recent telnet removal is 
rather prominent change for users. From documentation / advice / forum 
discussion perspective it is rather frustrating that both trunk and 15.05 are 
still referenced as "Chaos Calmer".


Having trunk renamed to something Dxxx Dxxx would clarify things.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Renaming trunk to Dxx Dxx ? Or seperate name for Trunk?

[Hannu Nyman]

Tobias Welz wrote at Wed Sep 9 17:24:14 CEST 2015:
> So I absolutely vote for some clear consistent naming of the trunk and 
seperate names for the releases. (What about some Cocktail with a letter from 
the end of the alphabet like Z Z or X X in case there exists one)


On that idea, the possible permanent name for the trunk could be something 
Txx Trunk. There are over 20 releases until TT is reached, so not for soon. I 
didn't find any really suitable drink names, but below are some ideas:

Trekking Trunk
Tasty Trunk
Tricky Trunk
Tempting Trunk
Twisty Trunk
Trunk Thrill
Thrilling Trunk

But until that, renaming trunk to something Dxxx Dxxx would be enough to 
decrease confusion.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Renaming trunk to Dxx Dxx ? Or seperate name for Trunk?

[Hannu Nyman]

John Crispin wrote at Fri Sep 11 08:59:01 CEST 2015:
> yes, once all the stuff required for doing so is resolved :) as you may 
have noticed CC-final is already uploaded to the dl server. we did basic 
testing already and all seems well. only missing bit is that the folder 
currently shows a 403 and we are waiting on someone that has access to the 
machine to figure out why. once that is done we will announce CC and change 
trunk to DD :)


Sounds great!

One additional wish: please make sure to tag and "release" the v15.05 in the 
main feeds at Github, (at least Packages and Luci). I guess that actually all 
the feeds enabled by default should have "release" versions. That will make 
life easier for those who want to later build exactly the "released" versions.


(v14.07 'packages' was tagged and released at Github, but not the main 
Openwrt svn source or 'luci' at Github.)


Ps. what were the final version's svn & git hashes?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] Complete the trunk rename from Chaos Calmer to Designated Driver

[Hannu Nyman]

Complete the trunk rename from Chaos Calmer to Designated Driver.
r46846 changed /etc/banner to reflect Designated Driver, but did not change 
the actual version definition in include/toplevel.mk.

https://dev.openwrt.org/changeset/46846

signed-off-by: Hannu Nyman 

Index: include/toplevel.mk
===
--- include/toplevel.mk (revision 46894)
+++ include/toplevel.mk (working copy)
@@ -6,7 +6,7 @@
 # See /LICENSE for more information.
 #
 
-RELEASE:=Chaos Calmer
+RELEASE:=Designated Driver
 PREP_MK= OPENWRT_BUILD= QUIET=0
 
 export IS_TTY=$(shell tty -s && echo 1 || echo 0)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] Complete the trunk rename from Chaos Calmer to Designated Driver

[Hannu Nyman]

Sorry, but what is the problem?
ozlabs patchwork list shows the properly recognised patch:
https://patchwork.ozlabs.org/patch/517209/

But in any case, inline below.

Hannu

Index: include/toplevel.mk
===
--- include/toplevel.mk(revision 46894)
+++ include/toplevel.mk(working copy)
@@ -6,7 +6,7 @@
 # See /LICENSE for more information.
 #

-RELEASE:=Chaos Calmer
+RELEASE:=Designated Driver
 PREP_MK= OPENWRT_BUILD= QUIET=0

 export IS_TTY=$(shell tty -s && echo 1 || echo 0)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] opkg: Extend 'opkg list' command to optionally display package size

[Hannu Nyman]

'opkg list' command only displays the available packages' name, version and 
description. It would be useful to also see the approximate size of the
available package.

This patch extends "opkg list" command with "--size" to optionally show also 
the *.ipk size.
* Default behaviour is to list the available packages as earlier: 
  "name - version - description"
* with "--size" the output of is "name - version - size - description".

Signed-off-by: Hannu Nyman 

---
Patch v2: bump opkg PKG_RELEASE and rebase

This patch superseeds https://patchwork.ozlabs.org/patch/512231/

Example:
root@OpenWrt:~# opkg list kr*
krb5-client - 1.13.1-1 - Kerberos 5 Client
krb5-libs - 1.13.1-1 - Kerberos 5 Shared Libraries
krb5-server - 1.13.1-1 - Kerberos 5 Server

root@OpenWrt:~# opkg list --size kr*
krb5-client - 1.13.1-1 - 37297 - Kerberos 5 Client
krb5-libs - 1.13.1-1 - 667427 - Kerberos 5 Shared Libraries
krb5-server - 1.13.1-1 - 122460 - Kerberos 5 Server

Example implementation that utilises this opkg change to show the 
.ipk size to the user in GUI:
https://github.com/openwrt/luci/issues/19#issuecomment-136397807



Index: package/system/opkg/Makefile
===
--- package/system/opkg/Makefile(revision 46946)
+++ package/system/opkg/Makefile(working copy)
@@ -12,7 +12,7 @@
 PKG_NAME:=opkg
 PKG_REV:=9c97d5ecd795709c8584e972bfdf3aee3a5b846d
 PKG_VERSION:=$(PKG_REV)
-PKG_RELEASE:=9
+PKG_RELEASE:=10
 
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_VERSION:=$(PKG_REV)
Index: package/system/opkg/patches/250-add-print-package-size.patch
===
--- package/system/opkg/patches/250-add-print-package-size.patch
(revision 0)
+++ package/system/opkg/patches/250-add-print-package-size.patch
(working copy)
@@ -0,0 +1,74 @@
+--- a/libopkg/opkg_conf.c
 b/libopkg/opkg_conf.c
+@@ -69,6 +69,7 @@ opkg_option_t options[] = {
+ { "proxy_passwd", OPKG_OPT_TYPE_STRING, &_conf.proxy_passwd },
+ { "proxy_user", OPKG_OPT_TYPE_STRING, &_conf.proxy_user },
+ { "query-all", OPKG_OPT_TYPE_BOOL, &_conf.query_all },
++{ "size", OPKG_OPT_TYPE_BOOL, &_conf.size },
+ { "tmp_dir", OPKG_OPT_TYPE_STRING, &_conf.tmp_dir },
+ { "verbosity", OPKG_OPT_TYPE_INT, &_conf.verbosity },
+ #if defined(HAVE_OPENSSL)
+--- a/libopkg/opkg_conf.h
 b/libopkg/opkg_conf.h
+@@ -88,6 +88,7 @@ struct opkg_conf
+  int query_all;
+  int verbosity;
+  int noaction;
++ int size;
+  int download_only;
+  char *cache;
+ 
+--- a/src/opkg-cl.c
 b/src/opkg-cl.c
+@@ -52,6 +52,7 @@ enum {
+   ARGS_OPT_AUTOREMOVE,
+   ARGS_OPT_CACHE,
+   ARGS_OPT_FORCE_SIGNATURE,
++  ARGS_OPT_SIZE,
+ };
+ 
+ static struct option long_options[] = {
+@@ -98,6 +99,7 @@ static struct option long_options[] = {
+   {"offline-root", 1, 0, 'o'},
+   {"add-arch", 1, 0, ARGS_OPT_ADD_ARCH},
+   {"add-dest", 1, 0, ARGS_OPT_ADD_DEST},
++  {"size", 0, 0, ARGS_OPT_SIZE},
+   {"test", 0, 0, ARGS_OPT_NOACTION},
+   {"tmp-dir", 1, 0, 't'},
+   {"tmp_dir", 1, 0, 't'},
+@@ -212,6 +214,9 @@ args_parse(int argc, char *argv[])
+   }
+   free(tuple);
+   break;
++  case ARGS_OPT_SIZE:
++  conf->size = 1;
++  break;
+   case ARGS_OPT_NOACTION:
+   conf->noaction = 1;
+   break;
+@@ -315,6 +320,7 @@ usage()
+   printf("\t--download-only   No action -- download only\n");
+   printf("\t--nodeps  Do not follow dependencies\n");
+   printf("\t--nocase  Perform case insensitive pattern 
matching\n");
++  printf("\t--sizePrint package size when listing 
available packages\n");
+   printf("\t--force-removal-of-dependent-packages\n");
+   printf("\t  Remove package and all dependencies\n");
+   printf("\t--autoremove  Remove packages that were installed\n");
+--- a/libopkg/opkg_cmd.c
 b/libopkg/opkg_cmd.c
+@@ -47,10 +47,12 @@ static void
+ print_pkg(pkg_t *pkg)
+ {
+   char *version = pkg_version_str_alloc(pkg);
++  printf("%s - %s", pkg->name, version);
++  if (conf->size)
++  printf(" - %lu", pkg->size);
+   if (pkg->description)
+-  printf("%s - %s - %s\n", pkg->name, version, pkg->description);
+-  else
+-  printf("%s - %s\n", pkg->name, version);
++  printf(" - %s", pkg->description);
++  printf("\n");
+   free(version);
+ }
+ 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v3] opkg: Extend 'opkg list' command to optionally display package size

[Hannu Nyman]

'opkg list' command only displays the available packages' name, version and 
description. It would be useful to also see the approximate size of the
available package.

This patch extends "opkg list" command with "--size" to optionally show also 
the *.ipk size.
* Default behaviour is to list the available packages as earlier: 
  "name - version - description"
* with "--size" the output of is "name - version - size - description".

Signed-off-by: Hannu Nyman 

---
Patch v2: bump opkg PKG_RELEASE and rebase
Patch v3: modify patch for the "git am" compatibility requirement

This patch superseeds https://patchwork.ozlabs.org/patch/512231/
and https://patchwork.ozlabs.org/patch/518287/


Example:
root@OpenWrt:~# opkg list kr*
krb5-client - 1.13.1-1 - Kerberos 5 Client
krb5-libs - 1.13.1-1 - Kerberos 5 Shared Libraries
krb5-server - 1.13.1-1 - Kerberos 5 Server

root@OpenWrt:~# opkg list --size kr*
krb5-client - 1.13.1-1 - 37297 - Kerberos 5 Client
krb5-libs - 1.13.1-1 - 667427 - Kerberos 5 Shared Libraries
krb5-server - 1.13.1-1 - 122460 - Kerberos 5 Server

Example implementation that utilises this opkg change to show the 
.ipk size to the user in GUI:
https://github.com/openwrt/luci/issues/19#issuecomment-136397807




Index: package/system/opkg/Makefile
===
--- a/package/system/opkg/Makefile
+++ b/package/system/opkg/Makefile
@@ -12,7 +12,7 @@
 PKG_NAME:=opkg
 PKG_REV:=9c97d5ecd795709c8584e972bfdf3aee3a5b846d
 PKG_VERSION:=$(PKG_REV)
-PKG_RELEASE:=9
+PKG_RELEASE:=10
 
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_VERSION:=$(PKG_REV)
Index: package/system/opkg/patches/260-add-print-package-size.patch
===
--- /dev/null
+++ b/package/system/opkg/patches/260-add-print-package-size.patch
@@ -0,0 +1,74 @@
+--- a/libopkg/opkg_conf.c
 b/libopkg/opkg_conf.c
+@@ -69,6 +69,7 @@ opkg_option_t options[] = {
+ { "proxy_passwd", OPKG_OPT_TYPE_STRING, &_conf.proxy_passwd },
+ { "proxy_user", OPKG_OPT_TYPE_STRING, &_conf.proxy_user },
+ { "query-all", OPKG_OPT_TYPE_BOOL, &_conf.query_all },
++{ "size", OPKG_OPT_TYPE_BOOL, &_conf.size },
+ { "tmp_dir", OPKG_OPT_TYPE_STRING, &_conf.tmp_dir },
+ { "verbosity", OPKG_OPT_TYPE_INT, &_conf.verbosity },
+ #if defined(HAVE_OPENSSL)
+--- a/libopkg/opkg_conf.h
 b/libopkg/opkg_conf.h
+@@ -88,6 +88,7 @@ struct opkg_conf
+  int query_all;
+  int verbosity;
+  int noaction;
++ int size;
+  int download_only;
+  char *cache;
+ 
+--- a/src/opkg-cl.c
 b/src/opkg-cl.c
+@@ -52,6 +52,7 @@ enum {
+   ARGS_OPT_AUTOREMOVE,
+   ARGS_OPT_CACHE,
+   ARGS_OPT_FORCE_SIGNATURE,
++  ARGS_OPT_SIZE,
+ };
+ 
+ static struct option long_options[] = {
+@@ -98,6 +99,7 @@ static struct option long_options[] = {
+   {"offline-root", 1, 0, 'o'},
+   {"add-arch", 1, 0, ARGS_OPT_ADD_ARCH},
+   {"add-dest", 1, 0, ARGS_OPT_ADD_DEST},
++  {"size", 0, 0, ARGS_OPT_SIZE},
+   {"test", 0, 0, ARGS_OPT_NOACTION},
+   {"tmp-dir", 1, 0, 't'},
+   {"tmp_dir", 1, 0, 't'},
+@@ -212,6 +214,9 @@ args_parse(int argc, char *argv[])
+   }
+   free(tuple);
+   break;
++  case ARGS_OPT_SIZE:
++  conf->size = 1;
++  break;
+   case ARGS_OPT_NOACTION:
+   conf->noaction = 1;
+   break;
+@@ -315,6 +320,7 @@ usage()
+   printf("\t--download-only   No action -- download only\n");
+   printf("\t--nodeps  Do not follow dependencies\n");
+   printf("\t--nocase  Perform case insensitive pattern 
matching\n");
++  printf("\t--sizePrint package size when listing 
available packages\n");
+   printf("\t--force-removal-of-dependent-packages\n");
+   printf("\t  Remove package and all dependencies\n");
+   printf("\t--autoremove  Remove packages that were installed\n");
+--- a/libopkg/opkg_cmd.c
 b/libopkg/opkg_cmd.c
+@@ -47,10 +47,12 @@ static void
+ print_pkg(pkg_t *pkg)
+ {
+   char *version = pkg_version_str_alloc(pkg);
++  printf("%s - %s", pkg->name, version);
++  if (conf->size)
++  printf(" - %lu", pkg->size);
+   if (pkg->description)
+-  printf("%s - %s - %s\n", pkg->name, version, pkg->description);
+-  else
+-  printf("%s - %s\n", pkg->name, version);
++  printf(" - %s", pkg->description);
++  printf("\n");
+   free(version);
+ }
+ 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] dropbear: use Openwrt default PATH also in dropbear

[Hannu Nyman]

Dropbear defines its own default PATH for new sessions.
When 500-set-default-path.patch was introduced by r32620,
the goal was to match /etc/profile.

Adjust 500-set-default-path.patch to match the current default PATH
as defined in https://dev.openwrt.org/changeset/47080/

   PATH=/usr/sbin:/usr/bin:/sbin:/bin

(In practice that PATH will be overridden by /etc/profile if that exists.)

Reference also to:
https://dev.openwrt.org/changeset/32620/
https://dev.openwrt.org/changeset/47590/
https://dev.openwrt.org/changeset/48235/  and
   
http://git.openwrt.org/?p=project/procd.git;a=commit;h=45cb04fd85d788a37367a5385e5e90dd98a0a991

Signed-off-by: Hannu Nyman 
---

(I am not bumping the PKG_REVISION as dropbear version was bumped up today.)

After yesterday's fix to procd, I noticed that one process still had
a different PATH. It took a while to realize that it was coming
from hardcoded defaults in dropbear.

Process 23582 has different PATH than other processes:

 root@OpenWrt:~# grep -r PATH /proc/*/environ
 /proc/1/environ:PATH=/usr/sbin:/usr/bin:/sbin:/bin
 /proc/1299/environ:PATH=/usr/sbin:/usr/bin:/sbin:/bin
 ...
 /proc/23582/environ:PATH=/bin:/sbin:/usr/bin:/usr/sbin
 /proc/2401/environ:PATH=/usr/sbin:/usr/bin:/sbin:/bin
 /proc/2415/environ:PATH=/usr/sbin:/usr/bin:/sbin:/bin
 ...
 /proc/516/environ:PATH=/usr/sbin:/usr/bin:/sbin:/bin
 /proc/self/environ:PATH=/usr/sbin:/usr/bin:/sbin:/bin
 /proc/thread-self/environ:PATH=/usr/sbin:/usr/bin:/sbin:/bin

 root@OpenWrt:~# ps | grep ash
   516 root   896 S/sbin/askfirst /bin/ash --login
 23582 root  1196 S-ash
 23591 root  1192 Sgrep ash

After this patch also the ash process has the same PATH as others:

 root@OpenWrt:~# grep -r PATH /proc/*/environ
 /proc/1/environ:PATH=/usr/sbin:/usr/bin:/sbin:/bin
 /proc/1288/environ:PATH=/usr/sbin:/usr/bin:/sbin:/bin
 ...
 /proc/4115/environ:PATH=/usr/sbin:/usr/bin:/sbin:/bin
 /proc/479/environ:PATH=/usr/sbin:/usr/bin:/sbin:/bin
 /proc/516/environ:PATH=/usr/sbin:/usr/bin:/sbin:/bin
 /proc/self/environ:PATH=/usr/sbin:/usr/bin:/sbin:/bin
 /proc/thread-self/environ:PATH=/usr/sbin:/usr/bin:/sbin:/bin

 root@OpenWrt:~# ps | grep ash
   516 root   896 S/sbin/askfirst /bin/ash --login
  4115 root  1196 S-ash
  4126 root  1192 Sgrep ash

 package/network/services/dropbear/patches/500-set-default-path.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/package/network/services/dropbear/patches/500-set-default-path.patch 
b/package/network/services/dropbear/patches/500-set-default-path.patch
index 648c391..7e8a4ff 100644
--- a/package/network/services/dropbear/patches/500-set-default-path.patch
+++ b/package/network/services/dropbear/patches/500-set-default-path.patch
@@ -5,7 +5,7 @@
  
  /* The default path. This will often get replaced by the shell */
 -#define DEFAULT_PATH "/usr/bin:/bin"
-+#define DEFAULT_PATH "/bin:/sbin:/usr/bin:/usr/sbin"
++#define DEFAULT_PATH "/usr/sbin:/usr/bin:/sbin:/bin"
  
  /* Some other defines (that mostly should be left alone) are defined
   * in sysoptions.h */
-- 
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] tools/cmake: update to 3.4.3

[Hannu Nyman]

Update cmake to 3.4.3.

Signed-off-by: Hannu Nyman 
---

Changes are rather minor:

 Changes in 3.4.3 since 3.4.2:
  VS: Do not fail on Windows 10 with VS 2015 if no SDK is available (#15929)

 Changes in 3.4.2 since 3.4.1:
  CMakeDetermineCompilerId: Fix VS Itanium platform name (#15889)
  VS: Do not select a partial Windows 10 SDK folder (#15831)
  VS: Fix VS 2015 .vcxproj file value for GenerateDebugInformation (#15894)
  cmSystemTools: Add VersionCompareEqual helper
  VS: Fix Windows 10 SDK version selection (#15831)
  FindJava: Fix typos in IdlJ and JarSigner component implementation
  AIX,HP-UX: Fix RPATH handling when CMP0065 is set to NEW

 tools/cmake/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/cmake/Makefile b/tools/cmake/Makefile
index aa80c97..d7a68ea 100644
--- a/tools/cmake/Makefile
+++ b/tools/cmake/Makefile
@@ -7,12 +7,12 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=cmake
-PKG_VERSION:=3.4.1
+PKG_VERSION:=3.4.3
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 PKG_SOURCE_URL:=https://cmake.org/files/v3.4/ \
https://fossies.org/linux/misc/
-PKG_MD5SUM:=73acda0d33be9b2729af99893d99a012
+PKG_MD5SUM:=4cb3ff35b2472aae70f542116d616e63
 
 HOST_BUILD_PARALLEL:=1
 HOST_CONFIGURE_PARALLEL:=1
-- 
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] tools/gmp: update to 6.1.0

[Hannu Nyman]

Update gmp to version 6.1.0, released in November 2015.

Signed-off-by: Hannu Nyman 
---

Links to release notes of 6.0.0 and 6.1.0:
https://gmplib.org/gmp6.1.html
https://gmplib.org/gmp6.0.html

 tools/gmp/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/gmp/Makefile b/tools/gmp/Makefile
index fac05e3..2067494 100644
--- a/tools/gmp/Makefile
+++ b/tools/gmp/Makefile
@@ -1,5 +1,5 @@
 #
-# Copyright (C) 2009-2013 OpenWrt.org
+# Copyright (C) 2009-2016 OpenWrt.org
 #
 # This is free software, licensed under the GNU General Public License v2.
 # See /LICENSE for more information.
@@ -7,11 +7,11 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=gmp
-PKG_VERSION:=5.1.3
+PKG_VERSION:=6.1.0
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=@GNU/gmp/
-PKG_MD5SUM:=e5fe367801ff067b923d1e6a126448aa
+PKG_MD5SUM:=a9868ef2556ad6a2909babcd1428f3c7
 
 HOST_FIXUP:=autoreconf
 
-- 
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] package/libs/gmp: update libgmp to 6.1.0

[Hannu Nyman]

Update also the library version of gmp to 6.1.0.
Switch download to use the GNU alias.

Signed-off-by: Hannu Nyman 
---
 package/libs/gmp/Makefile | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/package/libs/gmp/Makefile b/package/libs/gmp/Makefile
index 4578ec0..6143fd8 100644
--- a/package/libs/gmp/Makefile
+++ b/package/libs/gmp/Makefile
@@ -1,5 +1,5 @@
 #
-# Copyright (C) 2006-2014 OpenWrt.org
+# Copyright (C) 2006-2016 OpenWrt.org
 #
 # This is free software, licensed under the GNU General Public License v2.
 # See /LICENSE for more information.
@@ -8,13 +8,12 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=gmp
-PKG_VERSION:=6.0.0
-PKG_REVISION:=a
+PKG_VERSION:=6.1.0
 PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)$(PKG_REVISION).tar.xz
-PKG_SOURCE_URL:=http://gmplib.org/download/gmp/
-PKG_MD5SUM:=1e6da4e434553d2811437aa42c7f7c76
+PKG_SOURCE_URL:=@GNU/gmp/
+PKG_MD5SUM:=a9868ef2556ad6a2909babcd1428f3c7
 
 PKG_BUILD_PARALLEL:=1
 PKG_INSTALL:=1
-- 
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ISC-DHCP server removed from Chaos Calmer packages, why?

[Hannu Nyman]

Janne Cederberg wrote at Sun Feb 7 11:46:05 CET 2016
> I was curious to the reason why the ISC-DHCP server seems to have been 
removed from Chaos Calmer packages; tried to find info in mailing list 
archive and by general googling but was unable to.


That is the effect of the move to a new packages feeds repository two years ago.
https://lists.openwrt.org/pipermail/openwrt-devel/2014-June/025810.html
https://forum.openwrt.org/viewtopic.php?id=52219

Nobody has been willing to maintain the the isc-dhcp package, so it has been 
left at the "oldpackages" repo.

http://git.openwrt.org/?p=packages.git;a=summary
http://git.openwrt.org/?p=packages.git;a=blob;f=net/isc-dhcp/Makefile;hb=HEAD

"oldpackages" have not been compiled for CC15.05 (or for trunk snapshots), 
but you can enable the feed in your own build environment.


If you want the package imported to the current packages feed at Github, you 
could assume its maintainership and create a pull request at Github.

https://github.com/openwrt/packages
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/2] toolchain/gdb: update to 7.10.1

[Hannu Nyman]

Minor bugfix update, released in Dec 2015
https://www.gnu.org/software/gdb/news/

Signed-off-by: Hannu Nyman 
---

Release notes:
  December 5th, 2015: GDB 7.10.1 Released!

The latest version of GDB, version 7.10.1, is available for download.

This is a minor corrective release over GDB 7.10, fixing the following 
issues:

PR remote/18965 (new vforkdone stop reply should indicate parent 
process ID)
PR gdb/18957 (build failure in linux-namespaces.c due to setns static 
declaration)
PR gdb/19297 (Internal error on "record btrace": Unexpected branch 
trace format)
PR c++/16957 (gdb segfaults when loading symbols in C++11-enabled 
application)
PR c++/19306 (Incorrect demangling of symbols with ABI tags)
PR c++/19307 (Demangler bugs found with fuzz-testing)
PR c++/19308 (Demangle C++ Transactional Memory TS (N4514) symbols)

 toolchain/gdb/Makefile |  6 ++--
 .../gdb/patches/7.10.1/100-no_extern_inline.patch  | 32 ++
 .../gdb/patches/7.10.1/110-no_testsuite.patch  | 21 ++
 .../7.10.1/120-fix-compile-flag-mismatch.patch | 11 
 .../gdb/patches/7.10/100-no_extern_inline.patch| 32 --
 toolchain/gdb/patches/7.10/110-no_testsuite.patch  | 21 --
 .../7.10/120-fix-compile-flag-mismatch.patch   | 11 
 7 files changed, 67 insertions(+), 67 deletions(-)
 create mode 100644 toolchain/gdb/patches/7.10.1/100-no_extern_inline.patch
 create mode 100644 toolchain/gdb/patches/7.10.1/110-no_testsuite.patch
 create mode 100644 
toolchain/gdb/patches/7.10.1/120-fix-compile-flag-mismatch.patch
 delete mode 100644 toolchain/gdb/patches/7.10/100-no_extern_inline.patch
 delete mode 100644 toolchain/gdb/patches/7.10/110-no_testsuite.patch
 delete mode 100644 
toolchain/gdb/patches/7.10/120-fix-compile-flag-mismatch.patch

diff --git a/toolchain/gdb/Makefile b/toolchain/gdb/Makefile
index f74b64e..19f4931 100644
--- a/toolchain/gdb/Makefile
+++ b/toolchain/gdb/Makefile
@@ -1,5 +1,5 @@
 #
-# Copyright (C) 2006-2015 OpenWrt.org
+# Copyright (C) 2006-2016 OpenWrt.org
 #
 # This is free software, licensed under the GNU General Public License v2.
 # See /LICENSE for more information.
@@ -16,11 +16,11 @@ 
PKG_SOURCE_URL:=https://github.com/foss-for-synopsys-dwc-arc-processors/binutils
 PKG_MD5SUM:=d318829bfd2ed62714817f0d25706825
 GDB_DIR:=binutils-$(PKG_NAME)-$(PKG_VERSION)
 else
-PKG_VERSION:=7.10
+PKG_VERSION:=7.10.1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=@GNU/gdb
-PKG_MD5SUM:=2a35bac41fa8e10bf04f3a0dd7f7f363
+PKG_MD5SUM:=39e654460c9cdd80200a29ac020cfe11
 GDB_DIR:=$(PKG_NAME)-$(PKG_VERSION)
 endif
 
diff --git a/toolchain/gdb/patches/7.10.1/100-no_extern_inline.patch 
b/toolchain/gdb/patches/7.10.1/100-no_extern_inline.patch
new file mode 100644
index 000..8c18c6e
--- /dev/null
+++ b/toolchain/gdb/patches/7.10.1/100-no_extern_inline.patch
@@ -0,0 +1,32 @@
+--- a/sim/common/sim-arange.c
 b/sim/common/sim-arange.c
+@@ -280,11 +280,7 @@ sim_addr_range_delete (ADDR_RANGE *ar, a
+   build_search_tree (ar);
+ }
+ 
+-#endif /* DEFINE_NON_INLINE_P */
+-
+-#if DEFINE_INLINE_P
+-
+-SIM_ARANGE_INLINE int
++int
+ sim_addr_range_hit_p (ADDR_RANGE *ar, address_word addr)
+ {
+   ADDR_RANGE_TREE *t = ar->range_tree;
+@@ -301,4 +297,4 @@ sim_addr_range_hit_p (ADDR_RANGE *ar, ad
+   return 0;
+ }
+ 
+-#endif /* DEFINE_INLINE_P */
++#endif /* DEFINE_NON_INLINE_P */
+--- a/sim/common/sim-arange.h
 b/sim/common/sim-arange.h
+@@ -73,7 +73,7 @@ extern void sim_addr_range_delete (ADDR_
+ 
+ /* Return non-zero if ADDR is in range AR, traversing the entire tree.
+If no range is specified, that is defined to mean "everything".  */
+-SIM_ARANGE_INLINE int
++extern int
+ sim_addr_range_hit_p (ADDR_RANGE * /*ar*/, address_word /*addr*/);
+ #define ADDR_RANGE_HIT_P(ar, addr) \
+   ((ar)->range_tree == NULL || sim_addr_range_hit_p ((ar), (addr)))
diff --git a/toolchain/gdb/patches/7.10.1/110-no_testsuite.patch 
b/toolchain/gdb/patches/7.10.1/110-no_testsuite.patch
new file mode 100644
index 000..1b284ea
--- /dev/null
+++ b/toolchain/gdb/patches/7.10.1/110-no_testsuite.patch
@@ -0,0 +1,21 @@
+--- a/gdb/configure
 b/gdb/configure
+@@ -870,8 +870,7 @@ MAKEINFOFLAGS
+ YACC
+ YFLAGS
+ XMKMF'
+-ac_subdirs_all='testsuite
+-gdbtk
++ac_subdirs_all='gdbtk
+ multi-ice
+ gdbserver'
+ 
+@@ -5610,7 +5610,7 @@ $as_echo "$with_auto_load_safe_path" >&6
+ 
+ 
+ 
+-subdirs="$subdirs testsuite"
++subdirs="$subdirs"
+ 
+ 
+ # Check whether to support alternative target configurations
diff --git a/toolchain/gdb/patches/7.10.1/120-fix-compile-flag-mismatch.patch 
b/toolchain/gdb/patches/7.10.1/120-fix-compile-flag-mismatch.patch
new file mode 100644
index 000..c8b41f2
--- /dev/null
+++ b/toolchain/gdb/patches/7.10.1/120-fix-compile-flag-mismatch.patch
@@ -0,0 +1,11 @

[OpenWrt-Devel] [PATCH 2/2] package/devel/gdb: update to 7.10.1

[Hannu Nyman]

Minor bugfix update, released in Dec 2015
https://www.gnu.org/software/gdb/news/

Signed-off-by: Hannu Nyman 
---

Release notes:
  December 5th, 2015: GDB 7.10.1 Released!

The latest version of GDB, version 7.10.1, is available for download.

This is a minor corrective release over GDB 7.10, fixing the following iss$

PR remote/18965 (new vforkdone stop reply should indicate parent proce$
PR gdb/18957 (build failure in linux-namespaces.c due to setns static $
PR gdb/19297 (Internal error on "record btrace": Unexpected branch tra$
PR c++/16957 (gdb segfaults when loading symbols in C++11-enabled appl$
PR c++/19306 (Incorrect demangling of symbols with ABI tags)
PR c++/19307 (Demangler bugs found with fuzz-testing)
PR c++/19308 (Demangle C++ Transactional Memory TS (N4514) symbols)

 package/devel/gdb/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/package/devel/gdb/Makefile b/package/devel/gdb/Makefile
index a7ba205..91f6bfe 100644
--- a/package/devel/gdb/Makefile
+++ b/package/devel/gdb/Makefile
@@ -1,5 +1,5 @@
 #
-# Copyright (C) 2006-2015 OpenWrt.org
+# Copyright (C) 2006-2016 OpenWrt.org
 #
 # This is free software, licensed under the GNU General Public License v2.
 # See /LICENSE for more information.
@@ -8,12 +8,12 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=gdb
-PKG_VERSION:=7.10
+PKG_VERSION:=7.10.1
 PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=@GNU/gdb
-PKG_MD5SUM:=2a35bac41fa8e10bf04f3a0dd7f7f363
+PKG_MD5SUM:=39e654460c9cdd80200a29ac020cfe11
 
 PKG_BUILD_PARALLEL:=1
 PKG_INSTALL:=1
-- 
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Plans for CC 15.05.1 or DD 16.xx release?

[Hannu Nyman]

John Crispin wrote on 19/01/2016:
>
> there will be a delay. as usual 90% of tapi packages do not build aswell
> as the other usual suspects. i wont have time to fix these till early
> next week which will delay the 15.05.1 release by a few days. if anyone
> wants to dig into these before next week then feel free.

Any news on 15.05.1?
Or are the telephony packages still keeping the whole release hostage?
Hopefully not, as the telephony stuff is used by such a small minority of 
Openwrt users.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] dnsmasq: add host-specific lease time option for static hosts

[Hannu Nyman]

Enable setting a host-specific lease time for static hosts.
The new option is called "leasetime" and the format is similar
as for the default lease time: e.g. 12h, 3d, infinite

Default lease time is used for all hosts for which there is
no host-specific definition.

The option is added to /etc/config/dhcp for the selected hosts:
  config host
option name 'Nexus'
option mac 'd8:50:66:55:59:7c'
option ip '192.168.1.245'
option leasetime '2h'

It gets appended to /var/etc/dnsmasq.conf like this:
  dhcp-host=d8:50:66:55:59:7c,192.168.1.245,Nexus,2h

Signed-off-by: Hannu Nyman 
---

As requested, a rebased version of the patch.
Reference to discussion at https://patchwork.ozlabs.org/patch/563051/

I have included this option in my own build for the last 4 years.
(Ever since I tried to submit it via https://dev.openwrt.org/ticket/11227 )

I have also the Luci part ready.

 package/network/services/dnsmasq/Makefile   | 4 ++--
 package/network/services/dnsmasq/files/dnsmasq.init | 4 +++-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/package/network/services/dnsmasq/Makefile 
b/package/network/services/dnsmasq/Makefile
index 89799ee..a5c3740 100644
--- a/package/network/services/dnsmasq/Makefile
+++ b/package/network/services/dnsmasq/Makefile
@@ -1,5 +1,5 @@
 #
-# Copyright (C) 2006-2015 OpenWrt.org
+# Copyright (C) 2006-2016 OpenWrt.org
 #
 # This is free software, licensed under the GNU General Public License v2.
 # See /LICENSE for more information.
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=dnsmasq
 PKG_VERSION:=2.75
-PKG_RELEASE:=5
+PKG_RELEASE:=6
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=http://thekelleys.org.uk/dnsmasq
diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
b/package/network/services/dnsmasq/files/dnsmasq.init
index 0904503..61ded6a 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -342,7 +342,9 @@ dhcp_host_add() {
config_get_bool broadcast "$cfg" broadcast 0
[ "$broadcast" = "0" ] && broadcast=
 
-   xappend 
"--dhcp-host=$macs${networkid:+,net:$networkid}${broadcast:+,set:needs-broadcast}${tag:+,set:$tag}${ip:+,$ip}${name:+,$name}"
+   config_get leasetime "$cfg" leasetime
+
+   xappend 
"--dhcp-host=$macs${networkid:+,net:$networkid}${broadcast:+,set:needs-broadcast}${tag:+,set:$tag}${ip:+,$ip}${name:+,$name}${leasetime:+,$leasetime}"
 }
 
 dhcp_tag_add() {
-- 
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] dnsmasq: add host-specific lease time option for static hosts

[Hannu Nyman]

On 26.2.2016 10:33, John Crispin wrote:

Hi,

this does not apply anymore. mind to rebase and resend it please ?

John



Rebased patch v2 re-sent as https://patchwork.ozlabs.org/patch/588694/
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Any fix ETA or other info on the server hardware problems?

[Hannu Nyman]

The current server troubles have now continued for several weeks. Last 
buildbot run was three weeks ago. Mailing list archive server is also down.


Is there any news or information about the status of the server hardware 
upgrade project?


Any guess when the buildbot will be running again?

There was a short news item (from Zajec) in the News section of the forum, 
but that was removed for some reason a couple of days ago, and since then 
there is practically no info from the core team about the current situation, 
so the general user population is left in dark wondering what is happening. 
Thus there is a steady flow of new threads in the forum where people wonder 
from where to donwload packages etc.


The lack of any communication to the general users looks strange.

There should be some info about the situation at www.openwrt.org and at the 
forum.



Ps. the updated downloads.openwrt.org works only half of the time. Roughly 
every second time the page load fails (until yesterday with 503 error from 
nginx, today silently with empty page)

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Any fix ETA or other info on the server hardware problems?

[Hannu Nyman]

On 28.2.2016 19:10, Imre Kaloz wrote:

On Sun, 28 Feb 2016 11:35:42 +0100, Hannu Nyman  wrote:

Ps. the updated downloads.openwrt.org works only half of the time. Roughly 
every second time the page load fails (until yesterday with 503 error from 
nginx, today silently with empty page)


It works 100% of the time. You do 15+ concurrent connections, so you are 
getting throttled. Initially nginx replied with 503, it now replies with 
429 - your browser just doesn't handle that.


Thanks for the tip. Apparently the speculative link downloading automatics in 
Firefox was too aggressive. (Interesting that Firefox quietly fails instead 
of showing the 429 error.)


But is there any answer to my main question about the estimated schedule of 
fixing the hardware problems/upgrades?

And hopefully some info is published at the website & forum.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Proposal: change buildbot's build failure logic to be less restrictive regarding packages from feeds

[Hannu Nyman]

We have seen several times in the past few months that one non-essential 
package from feeds fails to build and stops the whole buildbot build. 
Yesterday it was python-cffi, but it has been ola, ltq-vmmc etc.


It seems strange to me that non-essential packages from feeds, which by 
definition are non-essential, can kill the whole buildbot build for a platform.


Normally a failing package gets marked "broken", but the build still 
continues. However, some packages seem to kill the whole build when they fail.


As far as I have been able to determine, if the failing package contains 
either a kernel module (kmod) or a "host section", then the failure of that 
package is considered so essential that the whole builbot build run is 
halted. The package is not just classified as "broken package", but the whole 
build is really stopped.


I understand that a host section breakage from a tool, toolchain component or 
a core package in the main Openwrt repo may be reason enough to halt the 
build. Same goes for a kmod needed for the device to operate.


But when that failure happens to a package from e.g. telephony feed or a 
python subpackage, I see no reason to stop the whole buildbot build run. The 
more we have packages maintained in Github by a large group of people, the 
more we will have this kind of accidental breakages by small non-essential 
packages.


I propose that devs would change the buildbot build failure logic so that the 
failing packages from the feeds would not kill the whole build. Failing 
packages from feeds should just be marked as broken. That might require 
splitting "package compilation" step to two different steps, one for packages 
from the Openwrt main repo, one for packages from feeds. (or alternatively, 
the essential packages should contain an ESSENTIAL definition on the 
Makefile, or something like that, and the failure logic should take that into 
account.)


This is a slightly reformatted version of my previous message about the same 
subject in January 2015.

The topic is still important, so hopefully developers could think about it.
https://lists.openwrt.org/pipermail/openwrt-devel/2015-January/030719.html
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Read-only mirror https://github.com/openwrt/openwrt is stuck since 12 days ago

[Hannu Nyman]

The read-only mirror for the main Openwrt sources at Github has been stuck 
since 12 days ago.


https://github.com/openwrt/openwrt

Both trunk and Chaos Calmer have got new commits since then...

Apparently the mirror has not returned to automatic updates after the 
network/hardware troubles.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] mm-macros: update to 0.9.10

[Hannu Nyman]

Bump mm-macros to 0.9.10

Signed-off-by: Hannu Nyman 
---
Release notes:
https://github.com/GNOME/mm-common/blob/master/NEWS

 tools/mm-macros/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/mm-macros/Makefile b/tools/mm-macros/Makefile
index cd675dc..3c457ef 100644
--- a/tools/mm-macros/Makefile
+++ b/tools/mm-macros/Makefile
@@ -1,5 +1,5 @@
 #
-# Copyright (C) 2010-2015 OpenWrt.org
+# Copyright (C) 2010-2016 OpenWrt.org
 #
 # This is free software, licensed under the GNU General Public License v2.
 # See /LICENSE for more information.
@@ -8,11 +8,11 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=mm-macros
-PKG_VERSION:=0.9.9
+PKG_VERSION:=0.9.10
 
 PKG_SOURCE_URL:=@GNOME/mm-common/0.9
 PKG_SOURCE:=mm-common-$(PKG_VERSION).tar.xz
-PKG_MD5SUM:=c9d8c016a99b639d66115cbe1d892402
+PKG_MD5SUM:=49dc47af8c89ce5b3c768306b9a0f922
 
 HOST_BUILD_DIR:=$(BUILD_DIR_HOST)/mm-common-$(PKG_VERSION)
 
-- 
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] pkg-config: Update to 0.29.1

[Hannu Nyman]

* Bump pkg-config version to 0.29.1
* Use https for the source download (http gets directed there)

Signed-off-by: Hannu Nyman 
---

Release notes:
https://lists.freedesktop.org/archives/pkg-config/2016-March/001043.html

 - Fixed a regression from 0.29 with unquoting values queried with
   --variable. In some cases, this would cause shell special characters
   to be escaped in ways they weren't before. Instead, the unquoting only
   occurs if the value appears to be quoted. (#93284)
 - Add support for building pkg-config with Microsoft Visual Studio.
   Thanks to Chun-wei Fan for the fix. (#92489)
 - Allow overriding pkg-config variables with environment variables. By
   setting an environment variable of the form
   PKG_CONFIG_$PACKAGE_$VARIABLE, a pkg-config variable can be set
   globally without always having to pass --define-variable. Thanks to
   Alex Larsson for the fix. (#90917)
 - Honor -Wl,-framework in addition to -framework so that multiple
   frameworks are handled on OSX. (#1278)
 - Fix the OSX build using --with-internal-glib. Thanks to Rudá Moura for
   the initial fix and Adam Mercer for testing the final patch. (#92902)


 tools/pkg-config/Makefile | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/pkg-config/Makefile b/tools/pkg-config/Makefile
index 40e6e08..c649b24 100644
--- a/tools/pkg-config/Makefile
+++ b/tools/pkg-config/Makefile
@@ -1,5 +1,5 @@
 # 
-# Copyright (C) 2006-2015 OpenWrt.org
+# Copyright (C) 2006-2016 OpenWrt.org
 #
 # This is free software, licensed under the GNU General Public License v2.
 # See /LICENSE for more information.
@@ -7,11 +7,11 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=pkg-config
-PKG_VERSION:=0.29
+PKG_VERSION:=0.29.1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
-PKG_SOURCE_URL:=http://pkgconfig.freedesktop.org/releases/
-PKG_MD5SUM:=77f27dce7ef88d0634d0d6f90e03a77f
+PKG_SOURCE_URL:=https://pkgconfig.freedesktop.org/releases/
+PKG_MD5SUM:=f739a28cae4e0ca291f82d1d41ef107d
 
 HOST_BUILD_PARALLEL:=1
 
-- 
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/2] package/devel/gdb: Update to 7.11

[Hannu Nyman]

Update gdb to version 7.11

Signed-off-by: Hannu Nyman 
---

Release notes:
https://lists.gnu.org/archive/html/info-gnu/2016-02/msg00010.html

GDB 7.11 brings new features and improvements, including:

* Per-inferior thread numbers (thread numbers are now per inferior instead
  of being global).

* GDB now allows users to specify breakpoint locations using a more
  explicit syntax (named "explicit location").  This feature is also
  available in GDB/MI.

* New convenience variables ($_gthread, $_inferior)

* When hitting a breakpoint or receiving a signal while debugging a
  multi-threaded program, the debugger now shows which thread triggered
  the event.

* Record btrace now supports non-stop mode.

* Various improvements on AArch64 GNU/Linux
  ** Multi-architecture debugging support
  ** displaced stepping
  ** tracepoint support added in GDBserver

* kernel-based threads support on FreeBSD.

* Support for reading/writing memory and extracting values on architectures
  whose memory is addressable in units of any integral multiple of 8 bits.

* In Ada, the overloads selection menu provides the parameter types and
  return types for the matching overloaded subprograms.

* Various remote protocol improvements, including several new packets
  which can be used to support features such as follow-exec-mode, exec
  catchpoints, syscall catchpoints, etc.

* Some minor improvements in the Python API for extending GDB.

* Support for various ROM monitors has been removed:
  target dbug   dBUG ROM monitor for Motorola ColdFire
  target picobugMotorola picobug monitor
  target dink32 DINK32 ROM monitor for PowerPC
  target m32r   Renesas M32R/D ROM monitor
  target mon2000mon2000 ROM monitor
  target ppcbug PPCBUG ROM monitor for PowerPC



 package/devel/gdb/Makefile   | 4 ++--
 package/devel/gdb/patches/100-musl_fix.patch | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/package/devel/gdb/Makefile b/package/devel/gdb/Makefile
index 91f6bfe..f6d5fec 100644
--- a/package/devel/gdb/Makefile
+++ b/package/devel/gdb/Makefile
@@ -8,12 +8,12 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=gdb
-PKG_VERSION:=7.10.1
+PKG_VERSION:=7.11
 PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=@GNU/gdb
-PKG_MD5SUM:=39e654460c9cdd80200a29ac020cfe11
+PKG_MD5SUM:=b5c784685e1cde65ba135feea86b6d75
 
 PKG_BUILD_PARALLEL:=1
 PKG_INSTALL:=1
diff --git a/package/devel/gdb/patches/100-musl_fix.patch 
b/package/devel/gdb/patches/100-musl_fix.patch
index afe9dc7..09146c5 100644
--- a/package/devel/gdb/patches/100-musl_fix.patch
+++ b/package/devel/gdb/patches/100-musl_fix.patch
@@ -8,7 +8,7 @@
  #include "defs.h"
  #include "inferior.h"
  #include "infrun.h"
-@@ -73,6 +74,10 @@
+@@ -71,6 +72,10 @@
  #define SPUFS_MAGIC 0x23c9b64e
  #endif
  
-- 
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/2] toolchain/gdb: Update to 7.11

[Hannu Nyman]

Update gdb to version 7.11

Signed-off-by: Hannu Nyman 
---

Release notes:
https://lists.gnu.org/archive/html/info-gnu/2016-02/msg00010.html

GDB 7.11 brings new features and improvements, including:

* Per-inferior thread numbers (thread numbers are now per inferior instead
  of being global).

* GDB now allows users to specify breakpoint locations using a more
  explicit syntax (named "explicit location").  This feature is also
  available in GDB/MI.

* New convenience variables ($_gthread, $_inferior)

* When hitting a breakpoint or receiving a signal while debugging a
  multi-threaded program, the debugger now shows which thread triggered
  the event.

* Record btrace now supports non-stop mode.

* Various improvements on AArch64 GNU/Linux
  ** Multi-architecture debugging support
  ** displaced stepping
  ** tracepoint support added in GDBserver

* kernel-based threads support on FreeBSD.

* Support for reading/writing memory and extracting values on architectures
  whose memory is addressable in units of any integral multiple of 8 bits.

* In Ada, the overloads selection menu provides the parameter types and
  return types for the matching overloaded subprograms.

* Various remote protocol improvements, including several new packets
  which can be used to support features such as follow-exec-mode, exec
  catchpoints, syscall catchpoints, etc.

* Some minor improvements in the Python API for extending GDB.

* Support for various ROM monitors has been removed:
  target dbug   dBUG ROM monitor for Motorola ColdFire
  target picobugMotorola picobug monitor
  target dink32 DINK32 ROM monitor for PowerPC
  target m32r   Renesas M32R/D ROM monitor
  target mon2000mon2000 ROM monitor
  target ppcbug PPCBUG ROM monitor for PowerPC


 toolchain/gdb/Makefile |  4 +--
 .../gdb/patches/7.10.1/100-no_extern_inline.patch  | 32 --
 .../gdb/patches/7.10.1/110-no_testsuite.patch  | 21 --
 .../7.10.1/120-fix-compile-flag-mismatch.patch | 11 
 .../gdb/patches/7.11/100-no_extern_inline.patch| 32 ++
 toolchain/gdb/patches/7.11/110-no_testsuite.patch  | 21 ++
 .../7.11/120-fix-compile-flag-mismatch.patch   | 11 
 7 files changed, 66 insertions(+), 66 deletions(-)
 delete mode 100644 toolchain/gdb/patches/7.10.1/100-no_extern_inline.patch
 delete mode 100644 toolchain/gdb/patches/7.10.1/110-no_testsuite.patch
 delete mode 100644 
toolchain/gdb/patches/7.10.1/120-fix-compile-flag-mismatch.patch
 create mode 100644 toolchain/gdb/patches/7.11/100-no_extern_inline.patch
 create mode 100644 toolchain/gdb/patches/7.11/110-no_testsuite.patch
 create mode 100644 
toolchain/gdb/patches/7.11/120-fix-compile-flag-mismatch.patch

diff --git a/toolchain/gdb/Makefile b/toolchain/gdb/Makefile
index 19f4931..0e1b0a2 100644
--- a/toolchain/gdb/Makefile
+++ b/toolchain/gdb/Makefile
@@ -16,11 +16,11 @@ 
PKG_SOURCE_URL:=https://github.com/foss-for-synopsys-dwc-arc-processors/binutils
 PKG_MD5SUM:=d318829bfd2ed62714817f0d25706825
 GDB_DIR:=binutils-$(PKG_NAME)-$(PKG_VERSION)
 else
-PKG_VERSION:=7.10.1
+PKG_VERSION:=7.11
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=@GNU/gdb
-PKG_MD5SUM:=39e654460c9cdd80200a29ac020cfe11
+PKG_MD5SUM:=b5c784685e1cde65ba135feea86b6d75
 GDB_DIR:=$(PKG_NAME)-$(PKG_VERSION)
 endif
 
diff --git a/toolchain/gdb/patches/7.10.1/100-no_extern_inline.patch 
b/toolchain/gdb/patches/7.10.1/100-no_extern_inline.patch
deleted file mode 100644
index 8c18c6e..000
--- a/toolchain/gdb/patches/7.10.1/100-no_extern_inline.patch
+++ /dev/null
@@ -1,32 +0,0 @@
 a/sim/common/sim-arange.c
-+++ b/sim/common/sim-arange.c
-@@ -280,11 +280,7 @@ sim_addr_range_delete (ADDR_RANGE *ar, a
-   build_search_tree (ar);
- }
- 
--#endif /* DEFINE_NON_INLINE_P */
--
--#if DEFINE_INLINE_P
--
--SIM_ARANGE_INLINE int
-+int
- sim_addr_range_hit_p (ADDR_RANGE *ar, address_word addr)
- {
-   ADDR_RANGE_TREE *t = ar->range_tree;
-@@ -301,4 +297,4 @@ sim_addr_range_hit_p (ADDR_RANGE *ar, ad
-   return 0;
- }
- 
--#endif /* DEFINE_INLINE_P */
-+#endif /* DEFINE_NON_INLINE_P */
 a/sim/common/sim-arange.h
-+++ b/sim/common/sim-arange.h
-@@ -73,7 +73,7 @@ extern void sim_addr_range_delete (ADDR_
- 
- /* Return non-zero if ADDR is in range AR, traversing the entire tree.
-If no range is specified, that is defined to mean "everything".  */
--SIM_ARANGE_INLINE int
-+extern int
- sim_addr_range_hit_p (ADDR_RANGE * /*ar*/, address_word /*addr*/);
- #define ADDR_RANGE_HIT_P(ar, addr) \
-   ((ar)->range_tree == NULL || sim_addr_range_hit_p ((ar), (addr)))
diff --git a/toolchain/gdb/patches/7.10.1/110-no_testsuite.patch 
b/toolchain/gdb/patches/7.10.1/110-no_testsuite.patch
deleted file mode 100644
index 1b284ea..000
--- a/toolchain/gdb/patches/7.10.1/110-no_testsuite.patch
+++ /dev/null
@@ -1,21 +0,0 @@
 a/gdb/configure
-+++