OpenWrt/LEDE Project

  • Status Unconfirmed
  • Percent Complete
    0%
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version openwrt-19.07
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Ilario Gelmetti - 10.11.2020

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

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:
https://github.com/libremesh/lime-web/issues/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!


Ilario Gelmetti commented on 11.11.2020 12:33

Additional scenario that makes this issue more annoying:

  1. open menuconfig
  2. select wpad-mesh-wolfssl and deselect wpad-basic
  3. close and save
  4. my .config is like this: http://sprunge.us/3fE1sU
  5. open menuconfig
  6. close and save
  7. 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.

Ilario Gelmetti commented on 17.11.2020 22:52

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.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing