Re: snort3 (at least) not building in 23.05

[Hannu Nyman]

Source code is your friend...

My two cents are on the backport of the HAS_LUAJIT_ARCH dependency to snort3.

Main/master shows that symbol definition:
```
.config - OpenWrt Configuration
 > Search (LUAJIT) 
  ┌ Search Results ─┐
  │ Symbol: HAS_LUAJIT_ARCH [=y]    │
  │ Type  : bool    │
  │ Defined at tmp/.config-package.in:26439 │
```

But 23.05 has no idea about that:
```
.config - OpenWrt Configuration
 > Search (LUAJIT) 
───

  ┌── Search Results ──┐
│ │
  │ Symbol: HAS_LUAJIT_ARCH 
[=HAS_LUAJIT_ARCH] │

  │ Type  : unknown │
```

And that symbol is a hard dependency of snort3 since this commit in master:
https://github.com/openwrt/packages/commit/5c1bcb61336b2b32788568d3dafa221b586dd430

That requirement in snort3 has been recently backported into 23.05 by this 
commit
https://github.com/openwrt/packages/pull/23532

Probably @ansuel @bkpepe know more about HAS_LUAJIT_ARCH, plus John Audia who 
did that snort3 backport ?




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

Unbalanced prioritization in the images buildbot? (main branch deprioritized too much)

[Hannu Nyman]

Looks like the release branches might have a too strong priority in the 
combined image buildbot, so that release branches get always built before the 
development main/master.


Recently there has been a steady flow of mostly small/unessential 
fixes/improvements for 22.03 and 23.05, so buildbot has been focused on 
building 22.03-SNAPSHOT and 23.05-SNAPSHOT (and the ongoing 23.05.1 build), 
and the main branch builds do lag really badly.


There was a bug in netifd WLAN device / hotplug handling that Felix fixed 
already 3 days ago, but we are still offering faulty downloads for half of 
the targets in main, as buildbot is prioritising  22.03 and 23.05 due to new 
commits in them. Oldest (and faulty) main build downloads are currently from 
Wed 8th = 5 days ago. That affects the imagebuilder/auc/attendedsysupgrade 
users, too.


The combined queue for images looks nice in principle, but can apparently 
lead into discrimination of main/master, if there are steadily new commits to 
the dormant stable branches.


There should maybe be some sanity check that each target gets built at least 
after X days since the last build, even if there are newer commits in the 
prioritized release branches. The "time since last build" should have a 
growing weight.




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

Re: netifd issue

[Hannu Nyman]

Felix Fietkau kirjoitti 10.11.2023 klo 16.38:

On 10.11.23 15:21, e9hack wrote:
Too fast. I did reboot with the old version again. The patched version 
does work.


Fix pushed, thanks for testing!

- Felix



Thanks,

I tested the current netifd with the fix, and it seems to work ok, again.

Please remember to backport the fixed netifd to 23.05, as currently 23.05 has 
the faulty version.



Hannu



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

Re: netifd issue

[Hannu Nyman]

e9hack kirjoitti 9.11.2023 klo 17.32:
I face a strange behaviour since commit 
516ab774cc16d4b04b3b17a067cbf2649f1adaeb (system-linux: fix race condition 
on bringing up wireless devices). After a reboot or a full restart of 
hostapd via 'wifi down; sleep 30; killall hostapd; sleep 5; wifi', only the 
first of 3 5G AP's is join to the configured bridge. The two faulty AP's 
are up and connecting is possible, but there is no real network connection. 
If I change one parameter of the faulty AP's in the config file and do a 
'wifi reload', than the 2 AP's are join to the bridges.


...

If I change the sequence of the 5G AP's in the config file, the behaviour 
after reboot doesn't change. Only phy1-ap0 does join to the bridge, either 
to br-lan or to br-tor. The previous netifd commit 
40ed7363caf2b22b6e29ed9d9948189c2bc4c8f3 (device: fix build error on 32 bit 
systems) doesn't have this issue.



I see the same error.
Some APs do not initially join the bridge, but after making a small pointless 
edit to the AP's config in /etc/config/wireless and reloading wifi, the AP 
then joins the bridge.



 OpenWrt SNAPSHOT, r24331-168beef1dd
 -
root@router4:~# brctl show
bridge name bridge id   STP enabled interfaces
br-lan  7fff.c4411ef8a51f   no  lan4
    lan2
    hn5wpa3
    lan3
    lan1
root@router4:~# nano /etc/config/wireless
root@router4:~# wifi reload
root@router4:~# brctl show
bridge name bridge id   STP enabled interfaces
br-lan  7fff.c4411ef8a51f   no  lan4
    hn5wpa2r
    lan2
    hn5wpa3
    lan3
    lan1



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

Re: [PATCH] ubox: logread add option to filter priority (log level)

[Hannu Nyman]

Paul D kirjoitti 24.7.2023 klo 13.19:

For those executing this at the command line, how does one 'repeat'?

-v 1 -v 2, or -v1 -v2 or -v123 or -v 1,2,3?

I had to think for a bit since it wasn't immediately obvious.

Perhaps a hint string with "(repeatable eg -v 1 -v 2)"?



On 2023-07-22 14:40, Legale Legale wrote:

 From 071cfc2853dd7a4f9fb59a1650de8d5c874ce4f2 Mon Sep 17 00:00:00 2001
From:
Date: Sat, 22 Jul 2023 01:28:05 +0300
Subject: [PATCH] logread: add option to filter priority (log level)

This adds an ability to filter log messages priority:
 -v   handle only messages with given log
level (0-7), repeatable
 -V   ignore messages with given log level
(0-7), repeatable



I think that a more normal approach would be same as with kernel log:
defining the minimum seriousness (max level), and printing the items more 
serious than that.


https://www.kernel.org/doc/html/next/core-api/printk-basics.html

> The log level specifies the importance of a message. The kernel decides 
whether to show the message immediately (printing it to the current console) 
depending on its log level and the current console_loglevel (a kernel 
variable). If the message priority is higher (lower log level value) than the 
console_loglevel the message will be printed to the console.


Simiilar approach of "show log items at least as serious as X" (=loglevel 
0-X) would look more natural to me.


There might be also filtering by individual level (with repeatable options), 
but the use case is not that obvious.




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

Re: Packages buildbot is erratic, both master and 23.05 packages fail often

[Hannu Nyman]

Petr Štetiar kirjoitti 2.6.2023 klo 22.07:

So having following in buildbot log:

  2023-06-01 23:53:12+ [-] command timed out: 3600 seconds without output 
running [b'make', b'-j7', b'IGNORE_ERRORS=n m y', b'BUILD_LOG=1', 
b'CONFIG_AUTOREMOVE=y', b'CONFIG_SIGNED_PACKAGES='], attempting to kill
  2023-06-01 23:53:12+ [-] trying to kill process group 1528179

I've looked at the system logs around that time and found following:

  Jun 01 22:23:19 audit[3844576]: AVC apparmor="DENIED" operation="mkdir" 
info="Failed name lookup - name too long"
  error=-36 profile="docker-default"
 
name="/shared-workdir/build/sdk/build_dir/hostpkg/gettext-0.21.1/gettext-tools/confdir3/confdir3/confdir3/confdir3...[snip
 very long repeating pattern]...
 confdir3/confdir3/confdir3/confdir3/confdir3" pid=3844576 comm="conftest" 
requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
  Jun 01 22:23:45 kernel: conftest[3855174]: segfault at 0 ip 7fe9581067e7 
sp 7ffd94ca2118 error 4 in libc-2.31.so[7fe958085000+159000]
  ...

Since the host is shared with other 3 build workers I can't be sure, that it
originated from that timeouted build.



Looking at that observation about gettext and recursive "confdir3/", it is 
plausible that gettext has problem that manifests in some builds, or trouble 
with parallelism on some occasions.


Gettext was heavily reorganised in May, near the same time as the buildbot 
code was revamped. So, this might quite well be related to the gettext 
package and not the new buildbot code.



Looking at one failing build log, (4030 lines long):

https://buildbot.staging.openwrt.org/master/packages/#/builders/14/builds/16/steps/24/logs/stdio

* gettext-full host build starts on line 1102 and completes on 1675

*gettext-full normal compile starts on line 1676 and never completes



1102 make[3] -C feeds/base/package/libs/gettext-full host-compile
...

1675 make[3] -C feeds/base/package/libs/gettext-full clean-build
1676 make[3] -C feeds/base/package/libs/gettext-full compile
...
4025 make[3] -C feeds/packages/admin/zabbix compile
4026
4027 command timed out: 3600 seconds without output running [b'make', b'-j7', 
b'IGNORE_ERRORS=n m y', b'BUILD_LOG=1', b'CONFIG_AUTOREMOVE=y', 
b'CONFIG_SIGNED_PACKAGES='], attempting to kill

4028 process killed by signal 9
4029 program finished with exit code -1
4030 elapsedTime=49718.148698

No gettext completion before the final timeout error.  Hunderds of other 
packages were compiled in the time when gettext was was being recursively 
compiled?



Context for Christian and Michael:


Hannu Nyman kirjoitti 1.6.2023 klo 19.11:
Looks like the new buildbot code and new instances (also for 23.05) are not 
yet quite stable...


Packages of some popular architectures like aarch64_cortex-a53 for mt7622 
and ipq807x have not been built for a week in master.


There has been many timeouts of "3600 seconds without output" in master, 
and quite too many "out of space" errors in the 23.05 packages buildbot.


...

Much too many buildbot-specifc errors compared to proper build failures due 
to source code...

Something strange/unstabilized in the buildbot ?
Or just some newly updated problematic packages causing havoc?

...

https://buildbot.staging.openwrt.org/master/packages/#/builders




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

Packages buildbot is erratic, both master and 23.05 packages fail often

[Hannu Nyman]

Looks like the new buildbot code and new instances (also for 23.05) are not 
yet quite stable...


Packages of some popular architectures like aarch64_cortex-a53 for mt7622 and 
ipq807x have not been built for a week in master.


There has been many timeouts of "3600 seconds without output" in master, and 
quite too many "out of space" errors in the 23.05 packages buildbot.


* zabbix x13 (and borgbackup plus other python packages before it) seem to be 
the typical last lines before he timeout failures...  Random failures or 
something due to recent changes ???


* with 23.05 the main problem seems to be "No space left on device"...

Much too many buildbot-specifc errors compared to proper build failures due 
to source code...

Something strange/unstabilized in the buildbot ?
Or just some newly updated problematic packages causing havoc?


https://buildbot.staging.openwrt.org/openwrt-23.05/packages/#/

https://buildbot.staging.openwrt.org/master/packages/#/builders


Downloads

https://downloads.openwrt.org/releases/23.05-SNAPSHOT/packages/

https://downloads.openwrt.org/snapshots/packages/




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

git.openwrt.org gives lots of timeout errors

[Hannu Nyman]

git.openwrt.org seems to give intermittently lots of timeouts, both with the 
actual git access and with the web interface. Results are either 500 or 504.



perus@ub2304:/Openwrt/DL-WRX36/feeds/packages$ git pull
fatal: unable to access 'https://git.openwrt.org/feed/packages.git/': The 
requested URL returned error: 500



Browser:

500 Internal Server Error
nginx/1.18.0

504 Gateway Time-out
The server didn't respond in time.



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

Re: Buildbot worker balancing between master and 22.03 ?

[Hannu Nyman]

I am repeating myself, but it looks strange that we have only 3 build workers 
on packages for the active master branch, while the almost dormant 22.03 has 
currently 10 active workers (and concurrent builds).


The packages build cycle in master is currently uncomfortably long.

Hannu


Hi,

it seems to me that the buildbot's worker amounts are not in balance with the 
commit frequency and actual workload of the various branches.

The phase1 images buildbot has only 3 active workers for master (which has 
regularly new commits), while the stable 22.03 has 8 workers.

The same is with the phase2 packages buildbot:
stable 22.03 has 9 workers,  while the active master has only 3.

To me it looks like 22.03 is over-resourced compared to the master, making 
build frequency in master rather slow.

To my knowledge, no release builds are currently being compiled, so could a few 
workers be re-assigned from 22.03 to master in order to shorten the build 
frequency there, both regarding images and packages.




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

Buildbot worker balancing between master and 22.03 ?

[Hannu Nyman]

Hi,

it seems to me that the buildbot's worker amounts are not in balance with the 
commit frequency and actual workload of the various branches.


The phase1 images buildbot has only 3 active workers for master (which has 
regularly new commits), while the stable 22.03 has 8 workers.


The same is with the phase2 packages buildbot:
stable 22.03 has 9 workers,  while the active master has only 3.

To me it looks like 22.03 is over-resourced compared to the master, making 
build frequency in master rather slow.


To my knowledge, no release builds are currently being compiled, so could a 
few workers be re-assigned from 22.03 to master in order to shorten the build 
frequency there, both regarding images and packages.




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

Buildbot needs configuration? powerpc_8540 is now powerpc_8548 ?

[Hannu Nyman]

Apparently the mpc85xx CPU type was changed from 8540 to 8548 on 29 Dec 2022, 
causing the package architecture to be powerpc_8548 instead of powerpc_8540, 
but noboby informed the packages buildbot, so it is still trying to churn 
powerpc_8540 and naturally fails :-(


PR:   https://github.com/openwrt/openwrt/pull/11629
commit: 
https://github.com/openwrt/openwrt/commit/2cad88b99fdae9766de84e6c1cb56f111eb53748


Buildbot status for powerpc_8540: 
https://buildbot.openwrt.org/master/packages/#/builders/14


Forum discussion: 
https://forum.openwrt.org/t/opkg-update-fails-with-wget-error-8-repository-folder-missing-powerpc-8548/148425



Visible also at the master snapsts packages download site:

https://downloads.openwrt.org/snapshots/packages/

mipsel_mips32/    -    Fri Jan 13 08:44:11 2023
powerpc_464fp/    -    Sat Jan 14 02:22:42 2023
powerpc_8540/    -    Fri Dec 30 06:18:13 2022
x86_64/    -    Sun Jan 15 11:44:24 2023



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

Re: [RFC] dropping of $(AUTORELEASE) feature

[Hannu Nyman]

Paul Spooren kirjoitti 6.11.2022 klo 18.15:

While I initially thought that $(AUTORELEASE) would be a nice feature to avoid 
the standard review comment “Please bump the PKG_RELEASE”, it turned into a 
massive increase of bandwidth usage: Every checkout of openwrt.git and package 
feeds needs to be a full clone instead of a shallow one to have all commits in 
place.

I’m suggesting dropping that feature and instead implement a (GitHub) CI 
workflow which fails if the commit did not bump the PKG_RELEASE.

It wasn’t a fully thought through idea and I think it’s time to revert it - 
sorry for the inconvenience.

Other thoughts?



The AUTORELEASE has been a nice feature from the package PR maintenance 
perspective.


Earlier there was constant trouble with concurrent PRs for the same package 
having the same PKG_RELEASE bump, or the maintainer doing a small change with 
a bump while there was an open PR with the same bump. The led to trivial 
conflicts and rebase needs for PRs. AUTORELEASE has tackled that nicely.




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

Re: OpenWrt 22.0X release plan (22.03)

[Hannu Nyman]

On 2022-04-04 11:58, claudiu.bez...@microchip.com wrote:

On 04.04.2022 11:11, Claudiu Beznea - M18063 wrote:

On 03.04.2022 10:23, Hannu Nyman wrote:

All targets are steadily green (with
the exception of at91/sama7 and its packages arm_cortex-a7_vfpv4 ).


I'll have a look on this.


The failure is on master branch according to buildbot:
repository: https://git.openwrt.org/openwrt/openwrt.git
revision: bf6002e74b4f2bdf98857d11acd62e8781db2569

I just checked openwrt-22.03 and all good in there.



Note sure what you mean by that "all good".

All red in 22.03 for at91/sama7 like I said
https://buildbot.openwrt.org/openwrt-22.03/images/#/builders/63


At the end of the build log:

rstrip.sh: 
/builder/shared-workdir/build/build_dir/target-arm_cortex-a7+vfpv4_musl_eabi/linux-at91_sama7/packages/ipkg-arm_cortex-a7_vfpv4/kmod-ipt-extra/lib/modules/5.10.108/xt_owner.ko: 
relocatable
Packaged contents of 
/builder/shared-workdir/build/build_dir/target-arm_cortex-a7+vfpv4_musl_eabi/linux-at91_sama7/packages/ipkg-arm_cortex-a7_vfpv4/kmod-ipt-extra 
into 
/builder/shared-workdir/build/bin/targets/at91/sama7/packages/kmod-ipt-extra_5.10.108-1_arm_cortex-a7_vfpv4.ipk
Package kmod-br-netfilter is missing dependencies for the following 
libraries:

bridge.ko
make[2]: *** [modules/netfilter.mk:908: 
/builder/shared-workdir/build/bin/targets/at91/sama7/packages/kmod-br-netfilter_5.10.108-1_arm_cortex-a7_vfpv4.ipk] 
Error 1
make[2]: Leaving directory 
'/builder/shared-workdir/build/package/kernel/linux'

time: package/kernel/linux/compile#52.83#38.05#473.89
ERROR: package/kernel/linux failed to build.
make[1]: *** [package/Makefile:116: package/kernel/linux/compile] Error 
1



Not sure if that is the actual error, and why that would affect only 
this target.



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

Re: OpenWrt 22.0X release plan (22.03)

[Hannu Nyman]

On 2/20/22 23:57, Hauke Mehrtens wrote:

> We would like to branch off OpenWrt 22.03 as openwrt-21.03 tomorrow.
> We would also like to create branches on the default feeds too.
>
> Petr will set up the new build bot instance together with Paul and we 
would like to do an 22.03.0-rc1 soon when the build bot infrastructure is 
working fine.


Hi,

is the 22.03.0-rc1 going be tagged and built soon? It is now almost two weeks 
since the 22.03 branching, and also the 22.03 buildbot has been hapily 
crunching build for over a week by now. All targets are steadily green (with 
the exception of at91/sama7 and its packages arm_cortex-a7_vfpv4 ).


To get more real-life feedback (e.g. regarding firewall4), we should get the 
rc1 out soon, so that there would be an official stable build for the general 
populace.


(Based on the recent commit activity, the developer interest is quickly 
moving toward kernel 5.15 etc. new stuff, so likely not much 22.03-specific 
polishing is happening. Same story as with earlier releases.)




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

Re: Custom thread names not working in htop anymore

[Hannu Nyman]

Koen Vandeputte wrote at Tue Jan 11 02:03:33 PST 2022:

> I noticed that custom thread names don't seem to work anymore these days.
> Htop got bumped recently but the issue still isn't fixed.
>
> This feature was very useful to check which thread consumes a lot of cpu
> during debugging applications.
>
> I think this got broken with the bump to a newer musl version as this is
> the only delta I haven't tested yet.
>
> Someone any idea?


Might be related to this upstream issue?


https://github.com/htop-dev/htop/issues/915



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

Should hostapd 802.11r defaults be tweaked? (reassociation deadline, FT over ds/air)

[Hannu Nyman]

Based on forum discussion, I tested 802.11r with my routers and noticed that 
the current OpenWrt defaults (reassociation deadline 1000 ms and "FT over 
DS") do not really work. I was unable to get my Android devices to realiably 
roam with those values.


Switching to FT over Air and lengthening the reassociation deadline to 2 
(20 seconds) made the devices to roam well.


There has been corroborating forum discussion that "FT over air" and reassoc 
2 generally works.


I wonder if we should change our defaults.


Does anybody have qualified opinions/experience on the matter?


Source:

https://github.com/openwrt/openwrt/blob/master/package/network/services/hostapd/files/hostapd.sh#L810-L811


Bug discussing this: https://bugs.openwrt.org/index.php?do=details_id=3159

Forum references:

* 
https://forum.openwrt.org/t/802-11r-fast-transition-how-to-understand-that-ft-works/110920


* 
https://forum.openwrt.org/t/rekeying-issue-driver-can-t-safely-do-that/106579/18


*https://forum.openwrt.org/t/when-does-802-11r-ft-over-ds-make-sense-to-use/88893


Commits introduced the default values without much reasoning, as the main 
thing was the 802.11r key automatics:


https://github.com/openwrt/openwrt/commit/3cc56a5534b8b49a7e9ba57edf9878ec32bdd27a
https://github.com/lede-project/source/pull/1382

The commit picked the smallest value 1000 of the allowed time range of 
1000-65335.

E.g. Cisco seems to recommend 2 = 20 seconds.


And regarding FT over DS, the commit introduced the feature and immediately 
switched the default to be it:


https://github.com/openwrt/openwrt/commit/b0d2c4ac417d54d18d0c5ab0a106f05657138ae0



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

Ubuntu 21.10 fails to compile OpenWrt 21.02 hosts tools (m4)

[Hannu Nyman]

I updated my buildhost to Ubuntu 21.10 and noticed that while it compiles 
master ok, the OpenWrt 21.02 build fails already at the tools build stage.


m4 is the failing tool.  Error log below.


I noticed that Rosen has recently updated m4 in master to 1.4.19, so I tested 
cherry-picking the 1.4.19 version update to openwrt-21.02, and it helps. m4 
again compiles  ;-)


Apparently the m4 version 1.4.19 in master contains some fixes for host gcc 
11, or something similar?




make[6]: Entering directory '/Openwrt/r7800-2102/build_dir/host/m4-1.4.18/lib'
depbase=`echo gl_avltree_oset.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc  -I.   -I/Openwrt/r7800-2102/staging_dir/host/include   -O2 
-I/Openwrt/r7800-2102/staging_dir/host/include  -MT gl_avltree_oset.o -MD -MP 
-MF $depbase.Tpo -c -o gl_avltree_oset.o gl_avltree_oset.c &&\

mv -f $depbase.Tpo $depbase.Po
depbase=`echo binary-io.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc  -I.   -I/Openwrt/r7800-2102/staging_dir/host/include   -O2 
-I/Openwrt/r7800-2102/staging_dir/host/include  -MT binary-io.o -MD -MP -MF 
$depbase.Tpo -c -o binary-io.o binary-io.c &&\

mv -f $depbase.Tpo $depbase.Po
depbase=`echo c-ctype.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc  -I.   -I/Openwrt/r7800-2102/staging_dir/host/include   -O2 
-I/Openwrt/r7800-2102/staging_dir/host/include  -MT c-ctype.o -MD -MP -MF 
$depbase.Tpo -c -o c-ctype.o c-ctype.c &&\

mv -f $depbase.Tpo $depbase.Po
depbase=`echo c-stack.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc  -I.   -I/Openwrt/r7800-2102/staging_dir/host/include   -O2 
-I/Openwrt/r7800-2102/staging_dir/host/include  -MT c-stack.o -MD -MP -MF 
$depbase.Tpo -c -o c-stack.o c-stack.c &&\

mv -f $depbase.Tpo $depbase.Po
In file included from /usr/include/signal.h:328,
 from ./signal.h:52,
 from c-stack.c:49:
c-stack.c:55:26: error: missing binary operator before token "("
   55 | #elif HAVE_LIBSIGSEGV && SIGSTKSZ < 16384
  |  ^~~~
make[6]: *** [Makefile:1910: c-stack.o] Error 1
make[6]: Leaving directory '/Openwrt/r7800-2102/build_dir/host/m4-1.4.18/lib'
make[5]: *** [Makefile:1674: all] Error 2



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

Possible difficulties at openwrt.org sites due to Letsencrypt root certificate expiration today...

[Hannu Nyman]

Heads up:

Forum has several reports that downloads.openwrt.org now fails in 21.02.0 and 
master due to invalid certificate.


Possibly related to the letsencrypt's old root certificate expiring today 

Or wolfssl not liking the remaining root cert?


https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/

See

https://forum.openwrt.org/t/2hrs-ago-all-openwrt-agents-stopped-cert-verify-failed-badcert-expired/107889/6

https://forum.openwrt.org/t/opkg-update-problem-invalid-ssl-certificate/107895

https://forum.openwrt.org/t/opkg-uclient-fetch-cant-download-from-https-site-invalid-ssl-certificate/107891



(For me, downloads from master with openssl-based wget seem to work normally)


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

Re: Wifi bug

[Hannu Nyman]

Felix Fietkau kirjoitti 27.9.2021 klo 19.17:

On 2021-09-27 17:45, Hannu Nyman wrote:

Felix Fietkau kirjoitti 27.9.2021 klo 13.59:

On a crash, it should drop a .core file to /tmp. Please copy that to
your build host and use ./scripts/remote-gdb to obtain a backtrace from
it. I'd like to know, which line of code in netifd it crashes on, so I
can fix it. So far the bug has not shown up in my own tests...

- Felix


This is probably what you are looking for...
To me it looks like it might actually be a list handling bug in libubox.



Can you please try this netifd patch?


At the first glance, the impact looks ok to me:
  wifi goes down with "with down", netifd stays alive and wifi remains down.  
:-)

Hannu



Thanks,

- Felix

---
diff --git a/alias.c b/alias.c
index 951e046bb3f1..98d54100fef9 100644
--- a/alias.c
+++ b/alias.c
@@ -178,13 +178,9 @@ alias_notify_device(const char *name, struct device *dev)
  {
struct alias_device *alias;
  
-	device_lock();

-
alias = avl_find_element(, name, alias, avl);
if (alias)
alias_set_device(alias, dev);
-
-   device_unlock();
  }
  
  struct device *

diff --git a/bonding.c b/bonding.c
index 0bf4f9a331ef..457fe5159899 100644
--- a/bonding.c
+++ b/bonding.c
@@ -566,8 +566,6 @@ bonding_free_port(struct bonding_port *bp)
  
  	bonding_remove_port(bp);
  
-	device_lock();

-
device_remove_user(>dev);
  
  	/*

@@ -582,8 +580,6 @@ bonding_free_port(struct bonding_port *bp)
device_set_present(dev, true);
}
  
-	device_unlock();

-
free(bp);
  }
  
diff --git a/bridge.c b/bridge.c

index 2ce5c2b11b49..7e61b9df8326 100644
--- a/bridge.c
+++ b/bridge.c
@@ -512,8 +512,6 @@ restart:
goto restart;
}
  
-	device_lock();

-
device_remove_user(>dev);
uloop_timeout_cancel(>check_timer);
  
@@ -529,8 +527,6 @@ restart:

device_set_present(dev, true);
}
  
-	device_unlock();

-
free(bm);
  }
  
diff --git a/config.c b/config.c

index d83ea9cb6b6c..9bbda39d3fb5 100644
--- a/config.c
+++ b/config.c
@@ -762,7 +762,6 @@ config_init_all(void)
  
  	vlist_update();

config_init = true;
-   device_lock();
  
  	device_reset_config();

config_init_devices(true);
@@ -775,12 +774,10 @@ config_init_all(void)
config_init_wireless();
  
  	config_init = false;

-   device_unlock();
  
  	device_reset_old();

device_init_pending();
vlist_flush();
-   device_free_unused(NULL);
interface_refresh_assignments(false);
interface_start_pending();
wireless_start_pending();
diff --git a/device.c b/device.c
index bb39ea7f8d71..b3d0e85f8550 100644
--- a/device.c
+++ b/device.c
@@ -99,18 +99,6 @@ device_type_get(const char *tname)
return NULL;
  }
  
-void device_lock(void)

-{
-   __devlock++;
-}
-
-void device_unlock(void)
-{
-   __devlock--;
-   if (!__devlock)
-   device_free_unused(NULL);
-}
-
  static int device_vlan_len(struct kvlist *kv, const void *data)
  {
return sizeof(unsigned int);
@@ -895,14 +883,27 @@ device_free(struct device *dev)
  }
  
  static void

-__device_free_unused(struct device *dev)
+__device_free_unused(struct uloop_timeout *timeout)
  {
-   if (!safe_list_empty(>users) ||
-   !safe_list_empty(>aliases) ||
-   dev->current_config || __devlock)
-   return;
+   struct device *dev, *tmp;
+
+   avl_for_each_element_safe(, dev, avl, tmp) {
+   if (!safe_list_empty(>users) ||
+   !safe_list_empty(>aliases) ||
+   dev->current_config)
+   continue;
+
+   device_free(dev);
+   }
+}
+
+void device_free_unused(void)
+{
+   static struct uloop_timeout free_timer = {
+   .cb = __device_free_unused,
+   };
  
-	device_free(dev);

+   uloop_timeout_set(_timer, 1);
  }
  
  void device_remove_user(struct device_user *dep)

@@ -919,19 +920,7 @@ void device_remove_user(struct device_user *dep)
safe_list_del(>list);
dep->dev = NULL;
D(DEVICE, "Remove user for device '%s', refcount=%d\n", dev->ifname, 
device_refcount(dev));
-   __device_free_unused(dev);
-}
-
-void
-device_free_unused(struct device *dev)
-{
-   struct device *tmp;
-
-   if (dev)
-   return __device_free_unused(dev);
-
-   avl_for_each_element_safe(, dev, avl, tmp)
-   __device_free_unused(dev);
+   device_free_unused();
  }
  
  void

diff --git a/device.h b/device.h
index 0496e893cbc9..37f8c37c58a3 100644
--- a/device.h
+++ b/device.h
@@ -300,9 +300,6 @@ extern const struct uci_blob_param_list device_attr_list;
  extern struct device_type simple_device_type;
  extern struct device_type tunnel_device_type;
  
-void device_lock(void);

-void device_unlock(void);
-
  void de

Re: Wifi bug

[Hannu Nyman]

Felix Fietkau kirjoitti 27.9.2021 klo 13.59:

On a crash, it should drop a .core file to /tmp. Please copy that to
your build host and use ./scripts/remote-gdb to obtain a backtrace from
it. I'd like to know, which line of code in netifd it crashes on, so I
can fix it. So far the bug has not shown up in my own tests...

- Felix



This is probably what you are looking for...
To me it looks like it might actually be a list handling bug in libubox.


perus@ub2104:/Openwrt/r7800$ 
./build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-11.2.0_musl_eabi/gdb-10.1/gdb/gdb 
./staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/root-ipq806x/sbin/netifd 
netifd.1632756907.1577.11.core

GNU gdb (GDB) 10.1
Copyright (C) 2020 Free Software Foundation, Inc.
...
Type "apropos word" to search for commands related to "word"...
Reading symbols from 
./staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/root-ipq806x/sbin/netifd...


warning: Can't open file /sbin/netifd during file-backed mapping note processing
...
warning: Can't open file /lib/libc.so during file-backed mapping note processing
[New LWP 1577]

warning: Could not load shared library symbols for 8 libraries, e.g. 
/lib/libubox.so.20210819.

Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
Core was generated by `/sbin/netifd'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xb6ea058c in ?? ()
(gdb) bt
#0  0xb6ea058c in ?? ()
#1  0x0001edc0 in device_broadcast_cb (ctx=, list=)
    at 
/Openwrt/r7800/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/netifd-2021-09-21-08e954e1/device.c:497

#2  0xb6f2f228 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) set solib-search-path 
./staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/

host/ packages/ pkginfo/  root-ipq806x/ stamp/    usr/
(gdb) set solib-search-path 
./staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/usr/lib/
Reading symbols from 
/Openwrt/r7800/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/usr/lib/libubox.so.20210819...
Reading symbols from 
/Openwrt/r7800/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/usr/lib/libubus.so.20210630...
Reading symbols from 
/Openwrt/r7800/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/usr/lib/libuci.so...
Reading symbols from 
/Openwrt/r7800/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/usr/lib/libjson-c.so.5.1.0...
Reading symbols from 
/Openwrt/r7800/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/usr/lib/libblobmsg_json.so.20210819...
Reading symbols from 
/Openwrt/r7800/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/usr/lib/libnl-tiny.so...

(gdb) bt
#0  0xb6ea058c in __safe_list_del_iterator (i=0xbee1ed0c)
    at 
/Openwrt/r7800/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/libubox-2021-08-19-d716ac4b/safe_list.c:49

#1  __safe_list_move_iterator (i=0xbee1ed0c, list=0xb6f2f220)
    at 
/Openwrt/r7800/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/libubox-2021-08-19-d716ac4b/safe_list.c:58
#2  safe_list_for_each (head=head@entry=0xb6f2f220, cb=cb@entry=0x1ed94 
, ctx=0xbee1ed3c,

    ctx@entry=0xbee1ed34)
    at 
/Openwrt/r7800/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/libubox-2021-08-19-d716ac4b/safe_list.c:73

#3  0x000210d0 in device_broadcast_event (dev=0xb6f2f200, ev=)
    at 
/Openwrt/r7800/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/netifd-2021-09-21-08e954e1/device.c:506

#4  0x000289a4 in handle_hotplug_msg (size=, data=)
    at 
/Openwrt/r7800/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/netifd-2021-09-21-08e954e1/system-linux.c:777

#5  handle_hotplug_event (u=0x46ea4 , events=)
    at 
/Openwrt/r7800/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/netifd-2021-09-21-08e954e1/system-linux.c:793

#6  0xb6e9e9f4 in uloop_run_events (timeout=)
    at 
/Openwrt/r7800/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/libubox-2021-08-19-d716ac4b/uloop.c:198

#7  uloop_run_timeout (timeout=timeout@entry=-1)
    at 
/Openwrt/r7800/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/libubox-2021-08-19-d716ac4b/uloop.c:555

#8  0x00013ae8 in uloop_run ()
    at 
/Openwrt/r7800/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/usr/include/libubox/uloop.h:111

#9  main (argc=1, argv=)
    at 
/Openwrt/r7800/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/netifd-2021-09-21-08e954e1/main.c:339

(gdb)



There is also a few seconds' gap in the system log, when netifd starts again:


Mon Sep 27 18:35:06 2021 kern.warn kernel: [  178.272585] ath10k_pci 
:01:00.0: peer-unmap-event: unknown peer id 0
Mon Sep 27 18:35:06 2021 kern.warn kernel: [  178.272647] ath10k_pci 
:01:00.0: peer-unmap-event: unknown peer id 0
Mon Sep 27 18:35:07 2021 daemon.notice netifd: Network device 'wlan0' link is 
down

Mon Sep 27 18:35:12 2021 user.notice : Added device handler type: bonding
Mon Sep 27 18:35:12 2021 

Re: Wifi bug

[Hannu Nyman]

e9hack kirjoitti 27.9.2021 klo 16.39:

Am 27.09.2021 um 14:01 schrieb Felix Fietkau:

Normally it should be active by default. Is CONFIG_KERNEL_ELF_CORE set
in your .config?


It was not activated, but the output from gdb looks not so helpful:

hb@vbox-linux6:~/src/openwrt/LEDE/archer-C7-ath79-5.10.x-dsa/build_dir/target-mips_74kc_musl/netifd-2021-09-21-08e954e1> 
../../../scripts/remote-gdb netifd.1632747166.9335.11.core netifd

Choose target:
  1) mips_74kc (musl )
GNU gdb (GDB) 10.1
...
Reading symbols from netifd...
[New LWP 9335]
Core was generated by `/sbin/netifd'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x77d79ed5 in ?? (warning: GDB can't find the start of the function at 
0x77d79ed5.


    GDB is unable to find the start of the function at 0x77d79ed5
and thus can't determine the size of that function's stack frame. 



Did you remember to provide it with a unstripped "netifd" binary from the 
staging_dir ?
(or did you try with the stripped final binary in build_dir or router? which 
will fail unless you have disabled stripping and have the full binary intact)




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

Re: Wifi bug

[Hannu Nyman]

e9hack kirjoitti 26.9.2021 klo 15.48:

Am 26.09.2021 um 12:54 schrieb Hannu Nyman:

e9hack kirjoitti 26.9.2021 klo 10.02:

Am 24.09.2021 um 22:04 schrieb e9hack:
In the past (a few days ago), it was possible to disable or shut-down 
wifi by introduce the command 'wifi down'. This doesn't work currently. 
After some seconds, wifi is start again.


It may be related to a page fault of netifd. Netifd is restart afterwards:

[  236.658379] do_page_fault(): sending SIGSEGV to netifd for invalid 
write access to 77cdd048

[  236.666942] epc = 77d7ded5 in libubox.so.20210819[77d78000+18000]
[  236.673212] ra  = 77d7dec9 in libubox.so.20210819[77d78000+18000]

This occurs after 'wifi down'.



Wifi coming up again happens also with R7800 (ipq806x, ath10k), master 
build from two days ago.



System log shoes wifi goes down, then the whole network stack gets 
restarted (?), and finally wifi comes back up.



  OpenWrt SNAPSHOT, r17581-2c9a07ed28
  -
root@router1:~# wifi down; logread -f
Sun Sep 26 13:42:39 2021 daemon.notice hostapd: Remove interface 'wlan0'
Sun Sep 26 13:42:39 2021 daemon.notice hostapd: wlan0: interface state 
ENABLED->DISABLED


Do you see a page fault from netifd in the log? If it does crash, it is 
restarted by procd. This does restart the network stack.



I do not see any crash in the logs.

But I do see netifd PID first disappearing from the proccess list and then 
re-appearing with a changed PID, so apparently netifd closes/crashes/whatever 
and restarts:


root@router1:~# pgrep netifd
8773
root@router1:~# wifi down
root@router1:~# pgrep netifd
root@router1:~# pgrep netifd
root@router1:~# pgrep netifd
18139



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

Re: Wifi bug

[Hannu Nyman]

e9hack kirjoitti 26.9.2021 klo 10.02:

Am 24.09.2021 um 22:04 schrieb e9hack:
In the past (a few days ago), it was possible to disable or shut-down wifi 
by introduce the command 'wifi down'. This doesn't work currently. After 
some seconds, wifi is start again.


It may be related to a page fault of netifd. Netifd is restart afterwards:

[  236.658379] do_page_fault(): sending SIGSEGV to netifd for invalid write 
access to 77cdd048

[  236.666942] epc = 77d7ded5 in libubox.so.20210819[77d78000+18000]
[  236.673212] ra  = 77d7dec9 in libubox.so.20210819[77d78000+18000]

This occurs after 'wifi down'.



Wifi coming up again happens also with R7800 (ipq806x, ath10k), master build 
from two days ago.



System log shoes wifi goes down, then the whole network stack gets restarted 
(?), and finally wifi comes back up.



 OpenWrt SNAPSHOT, r17581-2c9a07ed28
 -
root@router1:~# wifi down; logread -f
Sun Sep 26 13:42:39 2021 daemon.notice hostapd: Remove interface 'wlan0'
Sun Sep 26 13:42:39 2021 daemon.notice hostapd: wlan0: interface state 
ENABLED->DISABLED
Sun Sep 26 13:42:39 2021 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 
ac:57:75:56:c1:e0
Sun Sep 26 13:42:39 2021 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 
e0:c3:77:ae:0a:30

Sun Sep 26 13:42:39 2021 daemon.notice hostapd: wlan0: AP-DISABLED
Sun Sep 26 13:42:39 2021 daemon.notice hostapd: wlan0: CTRL-EVENT-TERMINATING
Sun Sep 26 13:42:39 2021 daemon.notice hostapd: nl80211: deinit ifname=wlan0 
disabled_11b_rates=0
Sun Sep 26 13:42:39 2021 kern.info kernel: [96769.105006] device wlan0 left 
promiscuous mode
Sun Sep 26 13:42:39 2021 kern.info kernel: [96769.105082] br-lan: port 
2(wlan0) entered disabled state
Sun Sep 26 13:42:39 2021 daemon.notice netifd: Network device 'wlan0' link is 
down
Sun Sep 26 13:42:39 2021 kern.info kernel: [96769.128708] ath10k_pci 
:01:00.0: mac flush null vif, drop 0 queues 0x
Sun Sep 26 13:42:39 2021 kern.warn kernel: [96769.130466] ath10k_pci 
:01:00.0: peer-unmap-event: unknown peer id 0
Sun Sep 26 13:42:39 2021 kern.warn kernel: [96769.134851] ath10k_pci 
:01:00.0: peer-unmap-event: unknown peer id 0
Sun Sep 26 13:42:39 2021 kern.warn kernel: [96769.141696] ath10k_pci 
:01:00.0: peer-unmap-event: unknown peer id 0

Sun Sep 26 13:42:39 2021 daemon.notice hostapd: Remove interface 'wlan1'
Sun Sep 26 13:42:39 2021 daemon.notice hostapd: wlan1: interface state 
ENABLED->DISABLED
Sun Sep 26 13:42:39 2021 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 
30:cd:a7:b3:33:5d

Sun Sep 26 13:42:39 2021 daemon.notice hostapd: wlan1: AP-DISABLED
Sun Sep 26 13:42:39 2021 daemon.notice hostapd: wlan1: CTRL-EVENT-TERMINATING
Sun Sep 26 13:42:39 2021 daemon.notice hostapd: nl80211: deinit ifname=wlan1 
disabled_11b_rates=0
Sun Sep 26 13:42:39 2021 kern.info kernel: [96769.328057] device wlan1 left 
promiscuous mode
Sun Sep 26 13:42:39 2021 kern.info kernel: [96769.328145] br-lan: port 
3(wlan1) entered disabled state
Sun Sep 26 13:42:39 2021 kern.info kernel: [96769.378176] ath10k_pci 
0001:01:00.0: mac flush null vif, drop 0 queues 0x
Sun Sep 26 13:42:39 2021 kern.warn kernel: [96769.379365] ath10k_pci 
0001:01:00.0: peer-unmap-event: unknown peer id 0
Sun Sep 26 13:42:39 2021 kern.warn kernel: [96769.384347] ath10k_pci 
0001:01:00.0: peer-unmap-event: unknown peer id 0
Sun Sep 26 13:42:39 2021 kern.warn kernel: [96769.391288] ath10k_pci 
0001:01:00.0: peer-unmap-event: unknown peer id 0
Sun Sep 26 13:42:39 2021 daemon.notice netifd: Network device 'wlan1' link is 
down

Sun Sep 26 13:42:44 2021 user.notice : Added device handler type: bonding
Sun Sep 26 13:42:44 2021 user.notice : Added device handler type: 8021ad
Sun Sep 26 13:42:44 2021 user.notice : Added device handler type: 8021q
Sun Sep 26 13:42:44 2021 user.notice : Added device handler type: macvlan
Sun Sep 26 13:42:44 2021 user.notice : Added device handler type: veth
Sun Sep 26 13:42:44 2021 user.notice : Added device handler type: bridge
Sun Sep 26 13:42:44 2021 user.notice : Added device handler type: Network device
Sun Sep 26 13:42:44 2021 user.notice : Added device handler type: tunnel
Sun Sep 26 13:42:45 2021 kern.info kernel: [96775.307649] br-lan: port 
1(eth1.1) entered disabled state
Sun Sep 26 13:42:45 2021 user.notice odhcpd: *** ODHCPD triggers DNSMASQ 
reload ***
Sun Sep 26 13:42:45 2021 kern.info kernel: [96775.319347] device eth1.1 left 
promiscuous mode
Sun Sep 26 13:42:45 2021 kern.info kernel: [96775.319372] device eth1 left 
promiscuous mode
Sun Sep 26 13:42:45 2021 kern.info kernel: [96775.322799] br-lan: port 
1(eth1.1) entered disabled state

Sun Sep 26 13:42:45 2021 daemon.info dnsmasq[5668]: read /etc/hosts - 4 
addresses
Sun Sep 26 13:42:45 2021 daemon.info dnsmasq[5668]: read 
/tmp/hosts/dhcp.cfg01411c - 3 addresses
Sun Sep 26 13:42:45 2021 daemon.info dnsmasq[5668]: read /tmp/hosts/odhcpd - 
0 addresses
Sun Sep 26 13:42:45 2021 daemon.info dnsmasq-dhcp[5668]: 

Re: Kernel 5.10: Current targets' state

[Hannu Nyman]

Adrian Schmutzler wrote at Tue Aug 24 05:50:42 PDT 2021:
( https://lists.openwrt.org/pipermail/openwrt-devel/2021-August/036159.html )

> I just created an overview of current 5.4->5.10 conversion state. Sharing 
it FYI below.

>
> Note that targets which are not converted or that nobody cares for always 
have the risk of being dropped. We probably also won't ask a hundred times 
like last time before doing so.

>
> Kernel 5.10 (only):
>  bmips
>
> Kernel 5.10 (5.4 still present):
>  bcm27xx gemini
>
> Testing 5.10:
>  apm821xx
>  armvirt
>  ath79
>  bcm53xx
>  bcm63xx
>  imx6
>  ipq806x
>  kirkwood
>  lantiq
>  malta
>  mpc85xx
>  mvebu
>  mxs
>  octeon
>  oxnas
>  ramips
>  rockchip
>  tegra
>  x86
> ...


Now when 21.02 is safely out, would be time to finally progress with the 
kernel 5.10 transition?


Like Adrian listed in his message, there are almost 20 targets where 5.10 is 
a testing kernel. Some of those targets like ipq806x have been ready for months.


Waiting for the 5.10 transition may also hold up other needed bumps, for 
example the DSA for ipq806x.





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

Re: OpenWrt 21.02.0 - First Stable Release

[Hannu Nyman]

Hauke Mehrtens wrote on Sat Sep 4 16:16:04 PDT 2021:
> Hi,
>
> The OpenWrt community is proud to announce the first stable release of the 
OpenWrt 21.02 stable version series.

> ...

Who could edit the download server's front page?

https://downloads.openwrt.org/ still calls 21.02 as "Upcoming", "currently in 
the release candidate phase" and advertises rc4.




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

Re: OpenWrt 21.02 status

[Hannu Nyman]

Hauke Mehrtens wrote at Sun Aug 29 02:53:47 PDT 2021:

> Should we just release with this as a known problem?
>
> Other than this problem I am not aware of any other critical problem.

We should.

It is annoying that 21.02 was branched more than 6 months ago, but no final 
release has happened by now. Due to the prolonged release process lots of 
"new" stuff has already been backported (unlike originally intended) causing 
potential new problems, and that will accumulate more the further we wait for 
the final release.


As we depend to a large part also on upstream developments (on kernel and 
packages), we will never get perfect releases.


The 21.02 release is also keeping the kernel 5.10 bump for many targets 
hostage (which is then preventing DSA bump, e.g. ipq806x), so that we can 
keep testing 5.4 in master for the benefit of 21.02.
(reference to the kernel list at 
https://lists.openwrt.org/pipermail/openwrt-devel/2021-August/036159.html


Looking back at the history, this 21.02 starts to be the longest period 
between major releases (especially if we calculate 15.05.1 as a major release).


Lets get this 20.01, 20.07, 20.12, 21.02 finally out before it turns to be 
22.xx in practice...


I think that the original (LEDE) release process goal was relatively 
frequently branched releases and then doing the final releases quickly after 
branching.  We have now reverted back to the old "let's wait long for 
branching and then wait even longer for the actual release".


The reality is the same than earlier: almost all devs and enthusiasts are 
already with master where interesting new stuff happens, so 21.02 rots 
quietly waiting for the release. The prolonged wait serves nobody :-(




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

[PATCH] treewide: add missing config symbols

[Hannu Nyman]

Add the next bunch of new config symbols found after
eaa9c94c7 exposed their existence.

Signed-off-by: Hannu Nyman 

---
Buildbot is currently broken on those targets due to the missing
symbols.

(I didn't yet touch CONFIG_USB_XHCI_TEGRA as I am not sure if
 it should be added enabled for Tegra.)

 target/linux/bcm4908/config-5.4  | 1 +
 target/linux/mediatek/mt7623/config-5.10 | 1 +
 target/linux/mediatek/mt7629/config-5.4  | 1 +
 target/linux/rockchip/armv8/config-5.4   | 1 +
 4 files changed, 4 insertions(+)

diff --git a/target/linux/bcm4908/config-5.4 b/target/linux/bcm4908/config-5.4
index 6f43a822c8..cc3b88cb76 100644
--- a/target/linux/bcm4908/config-5.4
+++ b/target/linux/bcm4908/config-5.4
@@ -39,6 +39,7 @@ CONFIG_B53=y
 # CONFIG_B53_MDIO_DRIVER is not set
 # CONFIG_B53_MMAP_DRIVER is not set
 # CONFIG_B53_SERDES is not set
+# CONFIG_B53_SPI_DRIVER is not set
 # CONFIG_B53_SRAB_DRIVER is not set
 CONFIG_BCM4908_ENET=y
 CONFIG_BCM7XXX_PHY=y
diff --git a/target/linux/mediatek/mt7623/config-5.10 
b/target/linux/mediatek/mt7623/config-5.10
index 9cbee56643..1bb0c2b692 100644
--- a/target/linux/mediatek/mt7623/config-5.10
+++ b/target/linux/mediatek/mt7623/config-5.10
@@ -166,6 +166,7 @@ CONFIG_DRM_MEDIATEK=y
 CONFIG_DRM_MEDIATEK_HDMI=y
 CONFIG_DRM_MIPI_DSI=y
 CONFIG_DRM_PANEL=y
+# CONFIG_DRM_PANEL_ASUS_Z00T_TM5P5_NT35596 is not set
 CONFIG_DRM_PANEL_BRIDGE=y
 CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=y
 CONFIG_DRM_SCHED=y
diff --git a/target/linux/mediatek/mt7629/config-5.4 
b/target/linux/mediatek/mt7629/config-5.4
index ca27a4f62c..1e5c0fc609 100644
--- a/target/linux/mediatek/mt7629/config-5.4
+++ b/target/linux/mediatek/mt7629/config-5.4
@@ -321,6 +321,7 @@ CONFIG_REGMAP_MMIO=y
 CONFIG_RESET_CONTROLLER=y
 CONFIG_RFS_ACCEL=y
 CONFIG_RPS=y
+# CONFIG_RTL8367S_GSW is not set
 CONFIG_RWSEM_SPIN_ON_OWNER=y
 CONFIG_SCSI=y
 CONFIG_SERIAL_8250_FSL=y
diff --git a/target/linux/rockchip/armv8/config-5.4 
b/target/linux/rockchip/armv8/config-5.4
index ee6a0021b5..84ab2c2107 100644
--- a/target/linux/rockchip/armv8/config-5.4
+++ b/target/linux/rockchip/armv8/config-5.4
@@ -175,6 +175,7 @@ CONFIG_DMA_REMAP=y
 CONFIG_DMA_SHARED_BUFFER=y
 CONFIG_DNOTIFY=y
 CONFIG_DRM_RCAR_WRITEBACK=y
+# CONFIG_DRM_ROCKCHIP is not set
 CONFIG_DTC=y
 CONFIG_DT_IDLE_STATES=y
 CONFIG_DUMMY_CONSOLE=y
-- 
2.30.2


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

Re: Broken 21.02 rc3 imagebuilder [Was: Re: Should ubus be marked as target-specific "nonshared"? (broken 21.02 rc2 imagebuilder)]

[Hannu Nyman]

Petr Štetiar kirjoitti 2.7.2021 klo 16.11:

Hannu Nyman  [2021-06-05 13:40:21]:

Hi,


Based on forum discussion, we have currently a broken 21.02.0-rc2
imagebuilder, as libiwinfo can't find the correct libubus version.

seems like there is broken 21.02.0-rc3 imagebuilder as well:

  openwrt-imagebuilder-21.02.0-rc3-ipq40xx-generic.Linux-x86_64$ make image 
PROFILE=avm_fritzbox-7530 PACKAGES=luci-ssl-openssl
  ...
  Collected errors:
...

It seems like that currently any package that depends on nonshared package
needs to be treated as nonshared as well, otherwise such issues would happen.

-- ynezz



My solution attempt aimed just to mitigate the "nonshared static packages 
depend on ABI revisioned shared packages" case, so that at least the 
nonshared package set would remain coherent in releases. iwinfo was one such 
package and apprently @jow- fixed that now separately (by changing it to shared).


Similar common packages are still e.g. mtd, block-mount and blockd, which are 
nonshared but depend on ABI revisioned shared packages like libubox, libubus 
etc., so they can be broken by version bumps. See analysis in 
https://lists.openwrt.org/pipermail/openwrt-devel/2021-June/035442.html


Regarding the generic case, the combination of ABI revisioning and 
shared/nonshared build difference (volatile/fixed) is the killer here. There 
is no real solution.


The easiest mitigation might be to backport changes into these key ABI 
revisioned shared packages in the release branches just shortly before next 
rc or dot releases, so that the imagebuilder remains broken only for a short 
time.




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

Re: Buildbot stuck? No new packages builds since Tuesday 22nd

[Hannu Nyman]

Hi,
Looks like the workers have got stuck again. All fsf-dock workers. Only 
the two different workers that were just started are still alive.


The same seems to concern also the 21.02 packages buildbot. All fsf-dock 
workers seem stuck.


Hannu

Ps. the 21.02 buildbot looks severely under-resourced compared to the 
half-dormant 19.07 branch. I would think that the current RC release 
should already have the priority for build resources.





On 2021-06-26 13:59, Hauke Mehrtens wrote:

On 6/26/21 10:15 AM, Hannu Nyman wrote:
Looks like the packages buildbot is somehow stuck. No new builds has 
been uploaded since Tuesday 22nd.

https://downloads.openwrt.org/snapshots/packages/

Buildbot status shows only janitor activity for the last four days.
https://buildbot.openwrt.org/master/packages/#/waterfall


Hi Hannu,

Thanks for reporting this problem, Baptiste fixed it by restarting the
build bots.

Hauke


zorun | there are connection failures in the log on 22/06, and then
regulary since then: [Broker (TLSMemoryBIOProtocol),client]
Master replied to keepalive, everything's fine
zorun | so the workers are connected to the master and are waiting for 
a

job, but the master doesn't send anything
zorun | it looks like a synchronisation bug in buildbot :/
zorun | ynezz: if you want to have a look, I have left fsf-dock-24 in
this "stuck" state
zorun | I have restarted all other workers and they are now building


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

Buildbot stuck? No new packages builds since Tuesday 22nd

[Hannu Nyman]

Looks like the packages buildbot is somehow stuck. No new builds has 
been uploaded since Tuesday 22nd.

https://downloads.openwrt.org/snapshots/packages/

Buildbot status shows only janitor activity for the last four days.
https://buildbot.openwrt.org/master/packages/#/waterfall

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

Re: Should ubus be marked as target-specific "nonshared"? (broken 21.02 rc2 imagebuilder)

[Hannu Nyman]

Hannu Nyman kirjoitti 6.6.2021 klo 10.56:

Paul Spooren kirjoitti 5.6.2021 klo 22.49:

Sounds good to me. Do you mind investigate what other packages are affected



I went through the ~60 instances of "nonshared" packages in the main 
OpenWrt repo, and found that toggling six packages to nonshared would solve 
the common problems:


libubox, ubus, uci, lua, libjson-c, libnl-tiny


I made a PR for changing those six packages:

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



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

Re: Should ubus be marked as target-specific "nonshared"? (broken 21.02 rc2 imagebuilder)

[Hannu Nyman]

Paul Spooren kirjoitti 5.6.2021 klo 22.49:

Sounds good to me. Do you mind investigate what other packages are affected



I went through the ~60 instances of "nonshared" packages in the main OpenWrt 
repo, and found that toggling six packages to nonshared would solve the 
common problems:


libubox, ubus, uci, lua, libjson-c, libnl-tiny


Additionally also elfutils (libelf, libdw)  could be toggled to nonshared, 
but as that is only needed for the non-default "perf" package, I do not find 
it that important.


(I left iptables aside from the analysis as iptables modules have lots of 
internal dependencies.)



Analysis:

Nonshared packages having a dependency to an ABI revisioned normal package:

libiwinfo    --> +PACKAGE_kmod-cfg80211:libnl-tiny +libuci +libubus,
libiwinfo-lua --> +libiwinfo +liblua,
umbim    --> +libubox +kmod-usb-net +kmod-usb-net-cdc-mbim +wwan,
uqmi --> +libubox +libblobmsg-json +kmod-usb-net 
+kmod-usb-net-qmi-wwan +wwan,

mtd  --> +libubox,
block-mount  --> +ubox +libubox +libuci +libblobmsg-json +libjson-c,
blockd    --> +block-mount +fstools +libubus +kmod-fs-autofs4 
+libblobmsg-json +libjson-c,
ltq-vdsl-app --> @TARGET_lantiq_xrx200 +libpthread +librt +ltq-dsl-base 
+libubox +libubus,
ltq-adsl-app --> 
@(TARGET_lantiq_xway||TARGET_lantiq_xway_legacy||TARGET_lantiq_ase) 
+libpthread +ltq-dsl-base +libubox +libubus,


perf  --> +libelf +libdw +PACKAGE_libunwind:libunwind +libpthread +librt 
+objdump @!IN_SDK @!TARGET_arc770 @KERNEL_PERF_EVENTS



Solving the above ABI dependencies by toggling these to nonshared:

libubox (libubox, libubox-lua, libblobmsg-json),
ubus (libubus),
uci (libuci),
lua (liblua),
libjson-c,
libnl-tiny,

elfutils (libelf, libdw)


Nonshared packages having a harmless dependency to normal packages (excluding 
packages with dependencies to just kmods or target):


fstools  --> +ubox +USE_GLIBC:librt +NAND_SUPPORT:ubi-utils
dropbear  --> +DROPBEAR_ZLIB:zlib
comgt --> +chat
comgt-ncm --> +comgt +wwan +kmod-usb-serial-option +kmod-usb-net-huawei-cdc-ncm
comgt-directip --> +comgt +wwan +kmod-usb-serial-option 
+kmod-usb-net-huawei-cdc-ncm
dsl-vrx200-firmware-xdsl-a-patch --> @TARGET_lantiq_xrx200 
+dsl-vrx200-firmware-xdsl-b +bspatch

ltq-dsl-base --> @TARGET_lantiq +jshn
base-files --> +netifd +libc +jsonfilter +SIGNED_PACKAGES:usign 
+SIGNED_PACKAGES:openwrt-keyring +NAND_SUPPORT:ubi-utils +fstools +fwtool



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

Should ubus be marked as target-specific "nonshared"? (broken 21.02 rc2 imagebuilder)

[Hannu Nyman]

I think that it might be wise to mark ubus as target-specific "nonshared" 
(PKG_FLAGS:=nonshared)


Based on forum discussion, we have currently a broken 21.02.0-rc2 
imagebuilder, as libiwinfo can't find the correct libubus version.


https://forum.openwrt.org/t/21-02-0-rc2-build-error-on-libubus20210215/98373


My reasoning:

* ubus is a normal (shared) package in the packages/ downloads dir

* the nonshared libiwinfo depends on libubus with ABI specification.

* ubus has been updated since rc2, so new ubus and libubus versions are now 
offered for download


* The nonshared libiwinfo is located in the target/ download directory of 
rc2, and it still depends on the older libubus with the old ABI version. And 
that old libubus version has already been replaced by the newer libubus 
version in the normal packages download dir.



The libubus dependency difference is visible in the libiwinfo package metadata:


libiwinfo from 21.02-SNAPSHOT:
   Package: libiwinfo20210106
   Version: 2021-01-31-4a32b33e-1
   Depends: libc, libnl-tiny1, libuci20130104, libubus20210603

From rc2:
   Package: libiwinfo20210106
   Version: 2021-01-31-4a32b33e-1
   Depends: libc, libnl-tiny1, libuci20130104, libubus20210215


I propose that ubus is marked to be nonshared, as it is an ABI versioned 
dependency of some nonshared packages.


This is not the first time when we have seen the iwinfo/libubus version 
syncing problems for users when ubus versions change. The problem usually 
hits master, but this time it is visible in the release branch, which 
highlights the issue.



We should consider doing the same for other ABI versioned packages that are 
dependencies of nonshared packages (like iwinfo).


I haven't investigated what other packages currently have similar nonshared 
target package --> shared generic ABI package dependencies, but I am sure 
that there are some others. (ubox/libubox and uci/libuci might be two 
obvious ABI versioned core packages that might be changed)




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

Re: opkg fails to install manually downloaded packages

[Hannu Nyman]

Sven Roederer kirjoitti 1.5.2021 klo 21.52:

Am Samstag, 1. Mai 2021, 15:14:35 CEST schrieb Hannu Nyman:

Sven Roederer kirjoitti 30.4.2021 klo 22.43:

...
Digging further I found installing online pulled librt in. Restarting from
scratch ...
Downloading librt and wall via wget and running `opkg *.ipk` - packages
have been installed successfully.

So the issue is obviously caused by resolving the dependencies which
triggers the faulty message:

Collected errors:
   * pkg_hash_fetch_best_installation_candidate: Packages for wall found,
   but

incompatible with the architectures configured"

Previous opkg-version gave a correct indication about missing
dependencies.

Yeah, I think that the changes in last November(?) caused several different
errors to be grouped under that error message.


I made a build reverting opkg to "2020-08-31.cf44c2feb606" which restored the
known behavior.

* satisfy_dependencies_for: Cannot satisfy the following dependencies for

jupp-data:

*  jupp

Which makes quite clear that some depending package is missing.

Example opkg (v2020-08-31.cf44c2feb606 on openwrt-21.02.0-rc1)

root@Ahof-Frieden05:~# opkg install -V2 /tmp/jupp-data_3.1.40-1_all.ipk
opkg_conf_parse_file: Loading conf file /etc/opkg.conf.
opkg_conf_parse_file: Loading conf file /etc/opkg/customfeeds.conf.
opkg_conf_parse_file: Loading conf file /etc/opkg/distfeeds.conf.
pkg_hash_load_feeds:
pkg_hash_load_feeds:
pkg_hash_load_status_files:
pkg_info_preinstall_check: Updating file owner list.
Installing jupp-data (3.1.40-1) to root...
satisfy_dependencies_for: This could mean that your package list is out of
date or that the packages
mentioned above do not yet exist (try 'opkg update'). To proceed in spite
of this problem try again with the '-force-depends' option.
opkg_configure_packages: Configuring unpacked packages.
opkg_configure_packages: Reordering packages before configuring them...
Collected errors:
  * satisfy_dependencies_for: Cannot satisfy the following dependencies for
jupp-data:
  *  jupp
  * opkg_install_cmd: Cannot install package jupp-data.
root@Ahof-Frieden05:~#



Sounds like a bug, but it should be named something like "Misleading opkg 
catch-all error message 'incompatible architecture' "


Those opkg commits in October-November 2020 by Paul, Daniel & Baptiste made 
lots of changes to the opkg dependency logic, and apparently the 
"incompatible architecture" is now some kind of catch-all, which 
catches/displays all kinds of errors too easily. At least:


* actual kernel version hash incompatibility plus temporary images/packages 
buildbot mis-sync after package ABI version bumps (like iwinfo now in master)
* missing dependences due to missing package lists (due to "opkg update" not 
done)



Earlier there actually was an "incompatible architecture" message that got 
displayed if you tried mvebu package to x86 etc.. Apparently now that message 
surfaces too easily.




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

Re: opkg fails to install manually downloaded packages

[Hannu Nyman]

Sven Roederer kirjoitti 30.4.2021 klo 22.43:

...
Digging further I found installing online pulled librt in. Restarting from
scratch ...
Downloading librt and wall via wget and running `opkg *.ipk` - packages have
been installed successfully.

So the issue is obviously caused by resolving the dependencies which triggers
the faulty message:

Collected errors:
  * pkg_hash_fetch_best_installation_candidate: Packages for wall found, but
incompatible with the architectures configured"

Previous opkg-version gave a correct indication about missing dependencies.



Yeah, I think that the changes in last November(?) caused several different 
errors to be grouped under that error message.




@Hannu: can you reproduce the issue by installing a package that is
definitively missing a dependency?

Sven



It still works for me. Below is log of installing a local jupp-data.ipk, 
which causes quite properly the jupp.ipk to be downloaded.


Note that both packages are from the packages download repo. I imagined that 
there might be some corner cases where the missing package is from the 
.../target/... packages repo, and would have been built by the phase1 
buildbot (like librt actually is). So I test also with protobuf, which pulls 
libatomic from .../target/... and even that dowloads properly and succeeds.


Can you please show more details about your error, with opkg more verbose (V2 
or V3). So that we could see, what actually fails for you.



Hannu


Example: jupp-data

root@router1:/tmp# opkg install -V2 /tmp/jupp-data_3.1.40-1_all.ipk
opkg_conf_parse_file: Loading conf file /etc/opkg.conf.
opkg_conf_parse_file: Loading conf file /etc/opkg/customfeeds.conf.
opkg_conf_parse_file: Loading conf file /etc/opkg/distfeeds.conf.
pkg_hash_load_feeds:
pkg_hash_load_feeds:
pkg_hash_load_feeds:
pkg_hash_load_feeds:
pkg_hash_load_status_files:
pkg_info_preinstall_check: Updating file owner list.
pkg_hash_fetch_best_installation_candidate: Using latest matching jupp 3.1.40 
arm_cortex-a15_neon-vfpv4.

Installing jupp-data (3.1.40-1) to root...
pkg_hash_fetch_best_installation_candidate: Using latest matching jupp 3.1.40 
arm_cortex-a15_neon-vfpv4.

Installing jupp (3.1.40-1) to root...
Downloading 
https://downloads.openwrt.org/releases/21.02-SNAPSHOT/packages/arm_cortex-a15_neon-vfpv4/packages/jupp_3.1.40-1_arm_cortex-a15_neon-vfpv4.ipk

pkg_run_script: Running script /tmp/opkg-DehkKF/jupp-hndleK/preinst.
opkg_install_pkg: Installing maintainer scripts.
opkg_install_pkg: Installing data files for jupp.
install_data_files: Extracting data files to /.
pkg_write_filelist: Creating //usr/lib/opkg/info/jupp.list file for pkg jupp.
opkg_install_pkg: Resolving conf files for jupp
pkg_run_script: Running script /tmp/opkg-DehkKF/jupp-data-pNIIIk/preinst.
opkg_install_pkg: Installing maintainer scripts.
opkg_install_pkg: Installing data files for jupp-data.
install_data_files: Extracting data files to /.
pkg_write_filelist: Creating //usr/lib/opkg/info/jupp-data.list file for pkg 
jupp-data.

opkg_install_pkg: Resolving conf files for jupp-data
opkg_configure_packages: Configuring unpacked packages.
opkg_configure_packages: Reordering packages before configuring them...
Configuring jupp.
pkg_run_script: Running script //usr/lib/opkg/info/jupp.postinst.
Configuring jupp-data.
pkg_run_script: Running script //usr/lib/opkg/info/jupp-data.postinst.
write_status_files_if_changed: Writing status file.
pkg_write_changed_filelists: Saving changed filelists.


Example: protobuf


root@router1:/tmp# opkg install -V2 
/tmp/protobuf_3.15.6-1_arm_cortex-a15_neon-vfpv4.ipk

opkg_conf_parse_file: Loading conf file /etc/opkg.conf.
opkg_conf_parse_file: Loading conf file /etc/opkg/customfeeds.conf.
opkg_conf_parse_file: Loading conf file /etc/opkg/distfeeds.conf.
pkg_hash_load_feeds:
pkg_hash_load_feeds:
pkg_hash_load_feeds:
pkg_hash_load_feeds:
pkg_hash_load_status_files:
pkg_info_preinstall_check: Updating file owner list.
pkg_hash_fetch_best_installation_candidate: Using held package libatomic1.
pkg_hash_fetch_best_installation_candidate: Using held package libstdcpp6.
pkg_hash_fetch_best_installation_candidate: Using held package libatomic1.
pkg_hash_fetch_best_installation_candidate: Using held package libstdcpp6.
pkg_hash_fetch_best_installation_candidate: Using latest matching 
protobuf-lite 3.14.0 arm_cortex-a15_neon-vfpv4.

Installing protobuf (3.15.6-1) to root...
pkg_hash_fetch_best_installation_candidate: Using held package libatomic1.
pkg_hash_fetch_best_installation_candidate: Using held package libstdcpp6.
pkg_hash_fetch_best_installation_candidate: Using latest matching 
protobuf-lite 3.14.0 arm_cortex-a15_neon-vfpv4.

pkg_hash_fetch_best_installation_candidate: Using held package libatomic1.
pkg_hash_fetch_best_installation_candidate: Using held package libstdcpp6.
Installing libatomic1 (8.4.0-3) to root...
Downloading 

Re: opkg fails to install manually downloaded packages

[Hannu Nyman]

Sven Roederer kirjoitti 30.4.2021 klo 1.44:

Am Donnerstag, 29. April 2021, 01:54:34 CEST schrieb Sven Roederer:

Using a freshly installed OpenWrt 21.02 fails to install a package that has
been downloaded manually. I had seen this initially when using my own image
where a package was missing. To fix I copied over with scp and wanted to
install with 'opkg '. It failed, complaining about incompatible
arch. rebuilding my image via Imagebuilder made my image work.

Initially thought of some faulty config on my board, but was just testing
with official build from downloads.openwrt.org and could confirm.

Here my console log (taken on TPLink WDR-3600):

-
OpenWrt 21.02.0-rc1, r16046-59980f7aaf
-
root@OpenWrt:~# cd /tmp
root@OpenWrt:/tmp# wget
https://downloads.openwrt.org/releases/21.02.0-rc1/

packages/mips_24kc/base/wall_2.36.1-2_mips_24kc.ipk


Downloading 'https://downloads.openwrt.org/releases/21.02.0-rc1/packages/

mips_24kc/base/wall_2.36.1-2_mips_24kc.ipk'


Connecting to 168.119.138.211:443
Writing to 'wall_2.36.1-2_mips_24kc.ipk'
wall_2.36.1-2_mips_2 100% |***| 10770
0:00:00

ETA


Download completed (10770 bytes)
root@OpenWrt:/tmp# opkg install /tmp/wall_2.36.1-2_mips_24kc.ipk
Unknown package 'wall'.

Collected errors:
  * pkg_hash_fetch_best_installation_candidate: Packages for wall found,
  but

incompatible with the architectures configured


  * opkg_install_cmd: Cannot install package wall.

As far as I can see opkd config looks fine ...


root@OpenWrt:/tmp# opkg print-architecture
arch all 1
arch noarch 1
arch mips_24kc 10

Any ideas?
I did not check on master yet, but I think it's a blocker for 21.02 release.


Just did a check on master, which shows the same behavior.




I wonder if your error is somehow specific to your settings, or some specific 
conditions.


I tested, and I can install downloaded buildbot package .ipks just fine to my 
R7800, both with 21.02 and master, my own builds.



WNDR3700v2 master:

OpenWrt SNAPSHOT, r16599-43dad22025

 -
root@router2:~# cd /tmp
root@router2:/tmp# 
wgethttps://downloads.openwrt.org/snapshots/packages/mips_24kc/base/wall_2.36.1-2_mips_24kc.ipk
Downloading 
'https://downloads.openwrt.org/snapshots/packages/mips_24kc/base/wall_2.36.1-2_mips_24kc.ipk'
Connecting to 2a01:4f8:251:321::2:443
Writing to 'wall_2.36.1-2_mips_24kc.ipk'
wall_2.36.1-2_mips_2 100% |***| 10770   0:00:00 ETA
Download completed (10770 bytes)
root@router2:/tmp# opkg install /tmp/wall_2.36.1-2_mips_24kc.ipk
Installing wall (2.36.1-2) to root...
Configuring wall.


R7800 with 21.02 build:

 OpenWrt 21.02-SNAPSHOT, r16053-f066ee2ad5
 -
root@router1:~# opkg install /tmp/wall_2.36.1-2_arm_cortex-a15_neon-vfpv4.ipk
Installing wall (2.36.1-2) to root...
Configuring wall.



___
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

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: 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: 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: 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

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_id=3655=id=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 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

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: 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: [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

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: [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

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 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: [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: [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] 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: 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

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: 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

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: [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: [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 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: [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 confi

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 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 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]

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=grep=Only+clear+gotsigchld



___
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 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]

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 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: 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: 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]

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
    prompt "Kern

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

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_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: [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

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: [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: [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

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

[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

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

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: [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: 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

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: 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

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: time zone isn't set

[Hannu Nyman]

Hannu Nyman kirjoitti 19.10.2020 klo 19.01:


Could it be that the zoneinfo format has changed so that musl is not 
compatible any more?


I suspect this:

http://mm.icann.org/pipermail/tz-announce/2020-October/59.html

   Changes to build procedure

 The Makefile now defaults POSIXRULES to '-', so the posixrules
 feature (obsolete as of 2019b) is no longer installed by default.


The last zoneinfo version bump was really simple (like always), but 
possibly the internal format has changed so that musl libc isn't able to 
read it any more.


Possibly musl uses that posixrules item to read zoneinfo?



I tested compiling both 2020a and 2020b, and noticed that the data files from 
2020b were really short.


I compared Europe/Helsinki from 2020a and 2020b, and noticed a large size 
difference:

481 bytes (2020b) vs 1900 bytes (2020a).

See differences in 
https://github.com/openwrt/packages/pull/13644#issuecomment-712312797 
<https://github.com/openwrt/packages/pull/13644#issuecomment-712312797>


Looks like 2020b is missing 3/4 of the earlier contents, and apparently musl 
needs to removed deprecated data/functionality.



Helsinki timezone was applied ok with 2020a, while with 2020b "date" shows 
just GMT/UTC time:


root@router1:~# opkg install --force-downgrade --force-reinstall 
/tmp/zoneinfo-europe_2020b-1_arm_cortex-a15_neon-vfpv4.ipk

Removing package zoneinfo-europe from root...
Installing zoneinfo-europe (2020b-1) to root...
Configuring zoneinfo-europe.
root@router1:~# date
Mon Oct 19 17:50:17  2020    (--> wrong, just UTC)

root@router1:~# opkg install --force-downgrade --force-reinstall 
/tmp/zoneinfo-europe_2020a-1_arm_cortex-a15_neon-vfpv4.ipk

Removing package zoneinfo-europe from root...
Installing zoneinfo-europe (2020a-1) to root...
Configuring zoneinfo-europe.
root@router1:~# date
Mon Oct 19 20:50:25 EEST 2020   (--> correct UTC+3)


I have reverted the zoneinfo 2020b version bump in the packages repo for now. 
There is now the old 2020a.




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

Re: time zone isn't set

[Hannu Nyman]

e9hack kirjoitti 19.10.2020 klo 18.28:

after commit 1f5f599d0ea434820e06fd540ecbc9c7f15399b4 (zoneinfo: Updated to the 
latest release) time zone isn't set.
Before this commit:
root@openwrt:~# date +"%Z %z"
CEST +0200

After this commit:
root@openwrt:~# date +"%Z %z"
  +

The localtime link is set properly:
root@openwrt:~# ls -l /tmp/localtime
lrwxrwxrwx1 root root33 Oct 19 06:37 /tmp/localtime -> 
/usr/share/zoneinfo/Europe/Berlin



Could it be that the zoneinfo format has changed so that musl is not 
compatible any more?


I suspect this:

http://mm.icann.org/pipermail/tz-announce/2020-October/59.html

   Changes to build procedure

 The Makefile now defaults POSIXRULES to '-', so the posixrules
 feature (obsolete as of 2019b) is no longer installed by default.


The last zoneinfo version bump was really simple (like always), but possibly 
the internal format has changed so that musl libc isn't able to read it any more.


Possibly musl uses that posixrules item to read zoneinfo?


Reference also to discussions at

https://forum.openwrt.org/t/timezone-etc-tz-not-updated-correctly/77002

and

https://github.com/openwrt/packages/pull/13644



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

Heads up: Fakeroot package catastrophe has removed most of master snapshot package downloads

[Hannu Nyman]

Heads up, the usage of the new fakeroot package has failed in a major way in 
buildbot, and the phase2 packages buildbot has failed to build any package 
for 1-2 days.


That has caused ALL master snapshot downloadable packages to be removed from 
the download server for most package archs. The download dirs currently 
contain just the empty indices.


That will likely cause a flood of bug reports, forum discussions etc., as no 
casual user can download add-on packages for master until buildbot has 
rebuilt the packages and uploaded them to the server, package arch by arch. 
That will likely take several days until the last arch is done.  I noticed 
this after there were forum complaints away missing LuCI downloads with opkg.



As of now, I am not sure if the problem has been fixed. The most recent 
phase2 builds still show empty download directories. But that is possibly due 
to package builds made with faulty SDKs from the phase1 images buildbot.  
(And nbd just committed a MacOS fix a few minutes ago, so there are 
apparently effects also for private build envs...)



The havoc has been most likely caused by commit "build: ipkg-build use 
fakeroot with PKG_FILE_MODES"


https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=353ce2e521f57318c502c862457dc859d8d181a6;hp=2bd55d0a2b22e5923a433edd9f90be8ea2997bde


Fix attempts were made by

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

and

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

but those have effect in the phase2 packages build only after the build 
happens with the fixed/updated SDK from phase1, which fix is still waiting to 
be built for many targets.



Hopefully things have been fixed, but the rebuild of the packages will really 
take several days, maybe up to a week.



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

Re: [OpenWrt-Devel] Is 18.06 packages buildbot intentionally offline?

[Hannu Nyman]

Petr Štetiar kirjoitti 17.5.2020 klo 16.58:

Hannu Nyman  [2020-05-16 11:46:55]:

Hi,


Apparently the openwrt-18.06 packages buildbot has been offline three weeks,
since 22 April 2020:

http://buildbot.openwrt.org/openwrt-18.06/packages/one_line_per_build

Is that intentional?

yep, because somewhere at that time we've suddenly lost 16 OSUOSL buildslaves
and I've moved those two buildslaves to 19.07 packages and master images as
there wasnt any buildslave active at that time.



Thanks for info.



There has been some talk about 18.06.3 it seems strange that the packages
buildbt would be intentionally offline for several weeks.

AFAIK release means firmware images, packages can be upgraded anytime, so the
release tagging doesn't have any influence on the packages.



Sure, no direct connection to the release compilation. But as users will 
likely reinstall packages after flashing a new maintenance release, it would 
be great to have the updated packages there for them. There have been some 
changes during the last weeks even in the mainly static 18.06 package feeds 
(although to not that many packages).




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

[OpenWrt-Devel] Is 18.06 packages buildbot intentionally offline?

[Hannu Nyman]

Apparently the openwrt-18.06 packages buildbot has been offline three weeks, 
since 22 April 2020:


http://buildbot.openwrt.org/openwrt-18.06/packages/one_line_per_build

Is that intentional?

There has been some talk about 18.06.3  
(http://lists.infradead.org/pipermail/openwrt-devel/2020-May/023226.html ), 
so it seems strange that the packages buildbt would be intentionally offline 
for several weeks.


Looks like the two buildslaves from truecz were switched off at Wed Apr 22 
11:57:32 2020 and removed from the buildbot config, and the third defined 
buildslave from nomosphere has never(?) done a build.



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

Re: [OpenWrt-Devel] Uncompress image: trailing garbage ignored

[Hannu Nyman]

W. Michael Petullo kirjoitti 23.4.2020 klo 19.50:

I have started to notice a gunzip warning when decompressing the
OpenWrt images I build. This is with master df27e949:

gunzip  openwrt/bin/targets/x86/64/openwrt-x86-64-generic-ext4-
combined.img.gz -c >/dev/null
gzip: openwrt-aquinas-git/bin/targets/x86/64/openwrt-x86-64-generic-
ext4-combined.img.gz: decompression OK, trailing garbage ignored

Aside from the warning, gunzip exits with a code of 2. The gunzip man
page indicates that an exit code of 2 indicates a warning.

Is this a result of an intended change? Should I expect this to
continue? Are we sneaking a hash or signature in there? If so, I
suppose I will adjust some of the scripts I use to account for the
non-zero exit code.



Likely we are attaching a signature since commit f81412160 a week ago:

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



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

Re: [OpenWrt-Devel] Can't build x86_64 because of ntf_reject_ipv4.ko missing

[Hannu Nyman]

Philip Prindeville wrote at Mon Apr 20 19:36:14 PDT 2020:

> Collected errors:
>  * check_data_file_clashes: Package kmod-ipt-nat6 wants to install file 
/home/philipp/lede/build_dir/target-x86_64_musl/root-x86/lib/modules/5.4.33/xt_MASQUERADE.ko

>     But that file is already provided by package  * kmod-ipt-nat
>  * opkg_install_cmd: Cannot install package kmod-ipt-nat6.
> ...
> philipp at ubuntu16:~/lede$ grep -r xt_MASQUERADE config Config.in include 
package/ rules.mk Makefile target/
> include/netfilter.mk:$(eval $(if $(NF_KMOD),$(call 
nf_add,IPT_NAT6,CONFIG_IP6_NF_TARGET_MASQUERADE, $(P_XT)xt_MASQUERADE, ge 5.2),))
> include/netfilter.mk:$(eval $(call 
nf_add,IPT_NAT,CONFIG_IP_NF_TARGET_MASQUERADE, $(P_XT)xt_MASQUERADE, ge 5.2))

> philipp at ubuntu16:~/lede$
>
> Why is it part of both packages?  And why is does it add different flags 
when it’s built?



Regarding IPv6 NAT, you stumbled into a kernel 5.4 issue originally reported 
in http://lists.infradead.org/pipermail/openwrt-devel/2020-February/021929.html


Bug report: https://bugs.openwrt.org/index.php?do=details_id=2924

That should have been fixed yesterday by
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=29a458b0cae3435bce41136ee3b4132b4103ffae

Have you updated your source repo?

(That issue was not detected by the buildbot, as it was a file clash at 
package installation, not an actual compilation error of the package itself.)



But no idea why that ipv6 NAT thing would have caused your original item of 
"ntf_reject_ipv4.ko missing"...




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

Re: [OpenWrt-Devel] Phase2 packages buildbot has failed since the kconfig changes

[Hannu Nyman]

Hannu Nyman kirjoitti 11.4.2020 klo 17.07:


But most errors seem to be related to recursive errors inside the rather 
complex mac80211 wifi driver collection. I have a hunch that for buildbot 
the "treat recursive dependencies as warnings instead of errors" option 
(from 3204430e3 ) should be activated in the config binary, or 
alternatively some major work for re-organising the mac80211 submodule 
dependencies needs to be done.




One interesting aspect:

The kmod related errors surface in the phase2 buildbot that uses SDK to 
compile non-kernel packages. The kernel and related packages are built by the 
phase1 images buildbot that also builds the SDK, so this phase2 packages 
buildbot should not even touch the kmods. But still the recursive config 
error realted to them apparently break the buildbot run.


That makes me wonder if the current settings have wider impact on SDK usage. 
Possibly the SDK reacts badly to the current config logic. (Personally I only 
compile with the full toolchain, so I have no experience with the SDK.)




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

[OpenWrt-Devel] Phase2 packages buildbot has failed since the kconfig changes

[Hannu Nyman]

Looks like the recent kconfig changes broke the whole packages buildbot.

(For some weird reason, the arc targets succeed, but all others fail 
miserably...  )



http://buildbot.openwrt.org/master/packages/grid

http://buildbot.openwrt.org/master/packages/one_line_per_build


Some of errors in the logs are possibly related to the TARGET_MULTI_PROFILE 
error preventing some default packages, and for that bug there is already a 
proposed patch.


But most errors seem to be related to recursive errors inside the rather 
complex mac80211 wifi driver collection. I have a hunch that for buildbot the 
"treat recursive dependencies as warnings instead of errors" option (from 
3204430e3 ) should be activated in the config binary, or alternatively some 
major work for re-organising the mac80211 submodule dependencies needs to be 
done.


Example:

http://buildbot.openwrt.org/master/packages/builders/mips_24kc/builds/219/steps/compile/logs/stdio



Config-build.in:10377:error: recursive dependency detected! 
Config-build.in:10377: symbol PACKAGE_kmod-cfg80211 depends on 
PACKAGE_kmod-cfg80211 For a resolution refer to 
Documentation/kbuild/kconfig-language.rst subsection "Kconfig recursive 
dependency limitations" Config-build.in:10273:error: recursive dependency 
detected! Config-build.in:10273: symbol PACKAGE_kmod-b43 depends on 
PACKAGE_kmod-b43 For a resolution refer to 
Documentation/kbuild/kconfig-language.rst subsection "Kconfig recursive 
dependency limitations" tmp/.config-package.in:10656:error: recursive 
dependency detected! tmp/.config-package.in:10656: symbol 
PACKAGE_kmod-acx-mac80211 depends on PACKAGE_kmod-acx-mac80211 For a 
resolution refer to Documentation/kbuild/kconfig-language.rst subsection 
"Kconfig recursive dependency limitations" Config-build.in:10665:error: 
recursive dependency detected! Config-build.in:10665: symbol 
PACKAGE_kmod-wl18xx depends on PACKAGE_kmod-wl18xx For a resolution refer to 
Documentation/kbuild/kconfig-language.rst subsection "Kconfig recursive 
dependency limitations" tmp/.config-package.in:11992:error: recursive 
dependency detected! tmp/.config-package.in:11992: symbol 
PACKAGE_kmod-mwlwifi depends on PACKAGE_kmod-mwlwifi For a resolution refer 
to Documentation/kbuild/kconfig-language.rst subsection "Kconfig recursive 
dependency limitations" Config-build.in:8941:error: recursive dependency 
detected! Config-build.in:8941: symbol PACKAGE_kmod-batman-adv depends on 
PACKAGE_kmod-batman-adv For a resolution refer to 
Documentation/kbuild/kconfig-language.rst subsection "Kconfig recursive 
dependency limitations" Config-build.in:10501:error: recursive dependency 
detected! Config-build.in:10501: symbol PACKAGE_kmod-mwifiex-sdio depends on 
PACKAGE_kmod-mwifiex-sdio For a resolution refer to 
Documentation/kbuild/kconfig-language.rst subsection "Kconfig recursive 
dependency limitations" Config-build.in:10545:error: recursive dependency 
detected! Config-build.in:10545: symbol PACKAGE_kmod-rt2400-pci depends on 
PACKAGE_kmod-rt2400-pci For a resolution refer to 
Documentation/kbuild/kconfig-language.rst subsection "Kconfig recursive 
dependency limitations" Config-build.in:10425:error: recursive dependency 
detected! Config-build.in:10425: symbol PACKAGE_kmod-mac80211 depends on 
PACKAGE_kmod-mac80211 For a resolution refer to 
Documentation/kbuild/kconfig-language.rst subsection "Kconfig recursive 
dependency limitations" Config-build.in:10229:error: recursive dependency 
detected! Config-build.in:10229: symbol PACKAGE_kmod-ath10k-ct-smallbuffers 
depends on PACKAGE_kmod-ath10k-ct-smallbuffers For a resolution refer to 
Documentation/kbuild/kconfig-language.rst subsection "Kconfig recursive 
dependency limitations" Config-build.in:10269:error: recursive dependency 
detected! Config-build.in:10269: symbol PACKAGE_kmod-ath9k-htc depends on 
PACKAGE_kmod-ath9k-htc For a resolution refer to 
Documentation/kbuild/kconfig-language.rst subsection "Kconfig recursive 
dependency limitations"


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

Re: [OpenWrt-Devel] [PATCH] build: config: allow bool to select a module pkg

[Hannu Nyman]

Petr Štetiar kirjoitti 11.4.2020 klo 12.43:

Hannu Nyman  [2020-04-11 09:00:11]:

Hi,


Applying the patch propsed here helped to fix my ath79 multi-device build.

So can this be interpreted as your `Tested-by:` ? Thanks.

-- ynezz



Yes, it can.

Hannu



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

Re: [OpenWrt-Devel] [PATCH] build: config: allow bool to select a module pkg

[Hannu Nyman]

Eneas U de Queiroz wrote at Thu Apr 9 17:39:17 PDT 2020:
> This was reported to me here:
> 
https://github.com/openwrt/openwrt/commit/dcf3e63a35d05e7e5103819c0f17195bfafe9baa#commitcomment-38390450
> The update to kconfig-v5.6 broke TARGET_MULTI_PROFILE because it would not 
accept bool TARGET_DEVICE_ to select MODULE_DEFAULT_ because 
MODULE_DEFAULT_ 'depends on m'--should only have a 'n' or 'm' value.  A 
'y' value would imply an unmet direct dependency (depends on m).

>
> My first thought was OK, if it wants to be a 'y', get rid of the 'depends 
on m' line; that did not work, because MODULE_DEFAULT_ selects 
PACKAGE_pkg, then  would be forced to be built-in.
> So, unless someone has a better idea, let's revert to the old behavior, 
and tolerate some 'unmet dependencies' once again.


Hopefully this gets fixed soon, as I have a hunch that this broke pretty much 
all TARGET_MULTI_PROFILE builds that have varying key components (like wifi 
firmware). Possibly also buildbot snapshots, as e.g. in ipq806x the included 
wifi firmware file varies by device.


I noticed a problem with my own multi-device builds, and there is now forum 
dicsussion about an issue, which I think is related to this:

https://forum.openwrt.org/t/wireless-fails-on-snapshot-r12900-kernel-5-4-on-c2600-ipq806x/60155/1

Applying the patch propsed here helped to fix my ath79 multi-device build.



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

Re: [OpenWrt-Devel] Is it possible to create two images for the same device with a different set of DEVICE_PACKAGES?

[Hannu Nyman]

I do not think that there is a nice clean solution, as I do not remember 
seeing a solution of different packages for iniramfs, factory and sysupgrade 
images.


I would approach that with a two-step build process, using two .config recipes:

* First a build with a smaller .config recipe without that large Quantenna 
firmware. This creates the initramfs image, (which you copy to a safe place 
before the second build)


* Then a second build from a recipe including the Quantenna firmware. No need 
to do "make clean", so the second build is rather quick. That produces the 
full sysupgrade image.


In your build automation scripts, those two builds could be run 
consequtively, with a copy step between them.


That will be much easier than trying to code a logic into the actual OpenWrt 
build Makefiles.




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

Re: [OpenWrt-Devel] [PATCH] ath79: switch to kernel 5.4

[Hannu Nyman]

David Bauer write at Thu Apr 2 12:53:59 PDT 2020:

> -KERNEL_PATCHVER:=4.19
> +KERNEL_PATCHVER:=5.4
>  KERNEL_TESTING_PATCHVER:=5.4


Please remove the KERNEL_TESTING_PATCHVER line at the same time.
It has no purpose after the same version has been adopted as the default kernel.



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

Re: [OpenWrt-Devel] Ath10k: How is the interface mac address set?

[Hannu Nyman]

Kevin Mahoney wrote at Wed Apr 1 20:15:21 PDT 2020:

> I'm working with an IPQ8065 based board with dual QCA9984s. I have it up 
and running but the wireless interfaces mac address is garbage.
> "00:03:7f:12:34:56" to be exact. I haven't been able to find the magic 
that reads and sets the proper address from non-volatile memory. Any pointers?



The mac addresses are set in the firmware load hotplug script. See here for 
IPQ8065 based R7800 with QCA9984:


https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata;h=bb505d642fee300f5c1cab40df9919d7a453345c;hb=HEAD#l26




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