FS#3441 - Menuconfig misbehaviour: wpad-mesh-wolfssl disappears depending on wpad-basic state

[openwrt-bot]

ilario:

====Premise:====

I am on OpenWrt 19.07.4 and menuconfig is behaving weirdly in a case.
I was trying to document how to select wpad-mesh-wolfssl and deselect wpad-basic for LibreMesh compilation and found something that looks like a bug in some Config.in file used by menuconfig.
Original bug reported on LibreMesh issues list here:
libremesh/libremesh.github.io#125

====Getting there:====

Selecting at the same time wpad-basic and wpad-mesh-wolfssl causes a clash of files installation in the compilation process. For this reason the deselection of wpad-basic has been suggested in LibreMesh compilation instructions.

wpad-mesh-wolfssl can be selected in menuconfig and wpad-basic deselected, until here everything ok.

====Issue:====

Then when closing and opening again menuconfig, wpad-mesh-wolfssl is not visible.

Screenshot: https://user-images.githubusercontent.com/1329018/98670652-4877ca80-2353-11eb-9d7f-96b5c5d718fd.png

But when wpad-basic (or something else) is selected, wpad-mesh-wolfssl appears and is actually selected (as it should be).

Screenshot: https://user-images.githubusercontent.com/1329018/98670749-7230f180-2353-11eb-9d44-2d6a9bcb3c78.png

The wpad-mesh-wolfssl package is categorized as being inside wpad-mesh-openssl, which makes no sense.

Screenshot: https://user-images.githubusercontent.com/1329018/98670837-9b518200-2353-11eb-8cf0-f490182b4ee2.png

And all of this happens even if the definitions of wpad-basic, wpad-mesh-openssl and wpad-mesh-wolfssl are substantially identical (extracted from https://github.com/openwrt/openwrt/blob/openwrt-19.07/package/network/services/hostapd/Makefile ):

wpad-basic
[identical part removed]
VARIANT:=wpad-basic

wpad-mesh-openssl
[identical part removed]
DEPENDS+=@PACKAGE_kmod-cfg80211 @(!TARGET_uml||BROKEN)
PROVIDES+=wpa-supplicant-mesh wpad-mesh
DEPENDS+=+libopenssl
VARIANT:=wpad-mesh-openssl

wpad-mesh-wolfssl
[identical part removed]
DEPENDS+=@PACKAGE_kmod-cfg80211 @(!TARGET_uml||BROKEN)
PROVIDES+=wpa-supplicant-mesh wpad-mesh
DEPENDS+=+libwolfssl
VARIANT:=wpad-mesh-wolfssl

This looks like a bug in some of the Config.in files used by make menuconfig.
Just to support this, I exchanged the order in which wpad-mesh-openssl and wpad-mesh-wolfssl are defined in tmp/.config-package.in and now wpad-mesh-wolfssl and wpad-mesh-openssl are at the same hierarchical level. There's clearly a bug around.

Thanks!

[openwrt-bot]

ilario:

Additional scenario that makes this issue more annoying:

• open menuconfig
• select wpad-mesh-wolfssl and deselect wpad-basic
• close and save
• my .config is like this: http://sprunge.us/3fE1sU
• open menuconfig
• close and save
• my .config changed and wpad-mesh-wolfssl is not selected anymore, see it here: http://sprunge.us/FGQgeY

This means that every time I modify something in the menuconfig, I have to select again the wpad-mesh-wolfssl package.

[openwrt-bot]

ilario:

In order to understand something I did a traceback, I report it here more as a note to myself:

menuconfig uses mconf

mconf represents the data from "tmp/.config-package.in"
here there's in wpad-mesh-wolfssl a line that does not have an equivalent in wpad-mesh-openssl

depends on m || (PACKAGE_wpad-mesh-openssl != y)

"tmp/.configure-package.in" gets generated by "scripts/package-metadata.pl config"

"scripts/package-metadata.pl config" takes the info from "tmp/.packageinfo"

here the wpad-mesh-wolfssl has wpad-mesh-openssl mentioned between the conflicts, but the opposite does not happen

"tmp/.packageinfo" gets generated by "include/scan.mk"

"include/scan.mk" gets invokated by "include/toplevel.mk" with (in case it was useful for easing the troubleshooting):

TOPDIR=$(pwd) make -j1 -r -s -f include/scan.mk SCAN_TARGET="packageinfo" SCAN_DIR="package" SCAN_NAME="package" SCAN_DEPTH=5 SCAN_EXTRA=""

"include/scan.mk" merges many files from "tmp/info/", the interesting one is ".packageinfo-network_services_hostapd"
here the same aforementioned "Conflicts:" entry appears

the "tmp/info/.packageinfo-network_services_hostapd" is also generated by the scan.mk call

"include/scan.mk" calls make in plenty of directories, between which also "package/network/services/hostapd"

TOPDIR=$(pwd) INCLUDE_DIR=$(pwd)/include make V=ss --no-print-dir -r DUMP=1 FEED="" -C package/network/services/hostapd

and this creates the Conflicts list from the $CONFLICTS variable set inside "package/network/services/hostapd/Makefile" so that after a few hours of looking into the issue turns out that the issue was in the most logical place.

The lists

SUPPLICANT_PROVIDERS:=
HOSTAPD_PROVIDERS:=

gets populated as the things get defined across the Makefile, so that at the moment of defining wpad-mesh-openssl, these variables do not contain any wpad-mesh-*. At this point, wpad-mesh-openssl gets added there.
For this reason, when wpad-mesh-wolfssl gets defined these lists already contain wpad-mesh-openssl.

This means that each package has a non-complete conflicting packages list depending on when it gets defined inside the Makefile.

[openwrt-bot]

ilario:

And when running the menuconfig thereś also a funny message stating:

tmp/.config-package.in:139918:error: recursive dependency detected!
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
tmp/.config-package.in:139918: symbol PACKAGE_wpad-mesh-wolfssl is selected by PACKAGE_wpad-mesh-wolfssl

[ilario]

Thanks @openwrt-bot!
@aparcar do you know if this is fixed in 21.02?

[aparcar]

Inverting the order of openssl and wolfssl (aka wolfssl first) fixes the subcategory issues. Not sure what's the base for that.

Overall wired that we have wpad and wpad-basic but not wpad-mesh.

@nbd168 ideas for this?

[ilario]

With OpenWrt 22.03.0-rc4 is even worse as I cannot manage to deselect wpad-basic-wolfssl (even if in menuconfig it looks like I managed to deselect it, it is still active in .config),

[ilario]

I am still having problems with this on v22.03.3.
To reproduce:
create a .config file with only this line:

CONFIG_PACKAGE_wpad-openssl=y

run make defconfig

check the content of the .config file. You will find something like this:

$ grep -i wpad .config
CONFIG_DEFAULT_wpad-basic-wolfssl=y
# CONFIG_PACKAGE_wpad is not set
# CONFIG_PACKAGE_wpad-basic is not set
# CONFIG_PACKAGE_wpad-basic-openssl is not set
CONFIG_PACKAGE_wpad-basic-wolfssl=y
# CONFIG_PACKAGE_wpad-mesh-openssl is not set
# CONFIG_PACKAGE_wpad-mesh-wolfssl is not set
# CONFIG_PACKAGE_wpad-mini is not set
CONFIG_PACKAGE_wpad-openssl=m
# CONFIG_PACKAGE_wpad-wolfssl is not set

as you can see, wpad-openssl has been deselected and wpad-basic-wolfssl has been selected.

Is there a way for having the full wpad-openssl compiled in the firmware using the buildroot?

[ilario]

Selecting a package with a dependency from wpad-openssl (this package: https://github.com/libremesh/network-profiles/blob/master/calafou/outdoor-crypt/Makefile ) seems that managed to keep wpad-openssl selected.