00:09 <hauke> The build problem in apm821xx should be fixed

11:05 <FLD> is there a way to get a dependency tree for a certain package in the build? for example, to figure out why is the library "gettext-full" being built with a certain config

12:11 <hauke> nick[m]12345: Some people complain that Ethernet TX does not work on Netgear WNDAP360, see https://github.com/openwrt/openwrt/issues/11025

12:11 <hauke> Do you have this device and could you have a look at this problem please

12:41 <hauke> FLD: you can check the help text in make menuconfig

12:41 <hauke> it will show the packages which depend on gettext-full when you look at the gettext-full help message in make menuconfig

13:14 <vulpes2[m]> Hi everyone, I'm trying to port a device that's basically identical to one that is already supported by OpenWrt, and I'm wondering what would be the best practice to handle minor differences such as LED colors? Would it be acceptable if I simply override the LED labels in my dts, or should I refactor the dtsi and move the LEDs into the respective dts files instead?

13:14 <vulpes2[m]> Device in question is this: https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/dts/mt7620a_edimax_ew-747x.dtsi

13:19 <vulpes2[m]> It needs to be introduced as a new device because despite having the same PCB, the bootloader and stock fw expects a different CSYS header.

13:56 <nick[m]12345> hauke: yes, but Not acessible Right nie

13:57 <nick[m]12345> But i will Try fetch ohne

14:05 <FLD> hauke: i did not find gettext-full in menuconfig

14:06 <FLD> yet its being tried to build during make

15:24 <hauke> FLD: the OpenWrt package of gettext-full is named libintl-full, search for libintl-full in menuconfig

15:24 <hauke> nick[m]12345: thanks

15:26 <hauke> vulpes2[m]: Your new device should get a new dts file which includes mt7620a_edimax_ew-747x.dtsi if the hardware is very similar

15:26 <hauke> you can move some of LED definitions which are difefernt on your device from the mt7620a_edimax_ew-747x.dtsi file to the two which currently include it

15:26 <hauke> and then add a difefernt definition in your new one

15:27 <hauke> so that the mt7620a_edimax_ew-747x.dtsi file will contain the common parts between the 3 devices later on and not only the 2 which it currently does

15:28 <vulpes2[m]> I understand, my question was whether I should refactor that dtsi or just override the LED labels in my dts. So far the devices that includes that dtsi have identical LED colors, but that is not the case for this new device I'm trying to introduce.

15:29 <hauke> you can also overwrite the definitions from the common dtsi file in your dts file, that should also be fine.

15:29 <hauke> I do not like the code which removes nodes from dts files

15:29 <hauke> and try to avoid that

15:31 <vulpes2[m]> Yeah that is going to be problematic, this hardware also lacks a slider switch that the supported board has, so should I move those two gpio-keys nodes into the dts files?

15:31 <vulpes2[m]> https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/dts/mt7620a_edimax_ew-747x.dtsi#L28-L40

15:39 <FLD> hauke: thanks. it was the msmtp-mta requiring the libintl-full which then tries to build gettext-full which FTBFS for ipq40xx

15:40 <FLD> with './libgnuintl.h:527:5: error: token "@" is not valid in preprocessor expressions'

15:46 <hauke> vulpes2[m]: I would prefer to move it to the two dts files

15:46 <vulpes2[m]> Got it, I'll do that, thanks.

15:46 <FLD> hauke: do you know if something else requires the gettext-full, it's still trying to be built after i unselected libintl-full

15:46 <hauke> FLD: got gettext broken by this upgrade: https://git.openwrt.org/b6d850317bb9ef8af61eb26e34d5f24ee053a362

15:47 <hauke> FLD: someone could have a build dependency to libintl-full

15:47 <hauke> OpenWrt normally builds all depdencies which could get seletced

15:48 <FLD> hauke: even if make menuconfig says [=n]?

15:48 <hauke> yes

15:48 <hauke> it does not get packaged in such a case

15:48 <FLD> ouch, well it's gonna be hard figuring out a build that can be done without gettext-full

15:51 <FLD> guess i can revert the upgrade and see if it builds

17:43 <ecraven> a question about ubus.. why does "ubus call network.wireless status" have a *stations* key, but it is always empty, even if there *are* stations connected (according to the ui and to hostapd.wlan0/wlan1)? is that intended behaviour?

18:26 <nick[m]12345> anyone can help me in finding the daemon/function/utility that is periodically calling "get_survey" on an ath10k radio? probably hostapd? but why?

20:25 <vulpes2[m]> could anyone provide an example on how to disable ethernet ports that are not wired up on the device in a mt7620 soc?

20:26 <vulpes2[m]> https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/dts/mt7620a_edimax_ew-747x.dtsi#L168-L199

20:26 <vulpes2[m]> This does not seem to have any effect and these ports are still showing up in the switch config menu in luci

20:31 <vulpes2[m]> I've noticed this dt doesn't have `mediatek,portmap` set for the ethernet phandle, could this be the reason?

21:10 <vulpes2[m]> also found `mediatek,portdisable` but this does not seem to be applicable to the builtin switch in the mt7620

21:16 <xdarklight> vulpes2[m]: what you're highlighting are the PHYs. the ports (at least port 5) seems to be right above: https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/dts/mt7620a_edimax_ew-747x.dtsi#L162-L166

21:18 <vulpes2[m]> this device only has one gigabit ethernet port hooked up via an external PHY, and I'm trying to disable all 5 ports on the builtin switch

21:21 <xdarklight> oh I just noticed that the MT7520 switch driver does not use DSA. then I don't know how to handle this

21:22 <vulpes2[m]> yeah, otherwise portdisable would do the job I think

21:25 <vulpes2[m]> this is a device with the same soc and also has just one ethernet port, I can't seem to find anything that can deal with the ethernet port config other than `mediatek,portmap`: https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/dts/mt7620a_dlink_dir-510l.dts

21:26 <vulpes2[m]> the switch config page in luci correctly displays only a single ethernet port on this device

21:49 <jow> hmm, do ujailed processes have access to /dev/urandom ?

22:50 <dangole> jow: yes, by default ujailed processes do have access to /dev/urandom, see https://git.openwrt.org/?p=project/procd.git;a=blob;f=jail/jail.c;hb=HEAD#l574

22:57 <jow> dangole: great, thanks for confirming