Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

openwrt-bot opened this issue Nov 10, 2020 · 5 comments


Copy link

@openwrt-bot openwrt-bot commented Nov 10, 2020



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 file used by menuconfig.
Original bug reported on LibreMesh issues list here:

====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.


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


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


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


And all of this happens even if the definitions of wpad-basic, wpad-mesh-openssl and wpad-mesh-wolfssl are substantially identical (extracted from ):

[identical part removed]

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

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

This looks like a bug in some of the 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/ and now wpad-mesh-wolfssl and wpad-mesh-openssl are at the same hierarchical level. There's clearly a bug around.


Copy link

@openwrt-bot openwrt-bot commented Nov 11, 2020


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:
  • open menuconfig
  • close and save
  • my .config changed and wpad-mesh-wolfssl is not selected anymore, see it here:

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

Copy link

@openwrt-bot openwrt-bot commented Nov 17, 2020


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/"
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/" gets generated by "scripts/ config"

"scripts/ 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/"

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

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

"include/" 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 call

"include/" 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


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.

Copy link

@openwrt-bot openwrt-bot commented Nov 24, 2020


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

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

@aparcar aparcar added the release/19.07 label Feb 22, 2022
Copy link

@ilario ilario commented Mar 7, 2022

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

Copy link

@aparcar aparcar commented Mar 7, 2022

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?

@aparcar aparcar removed the release/19.07 label Mar 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

3 participants