00:02 <ldir> jow: I thought I had - 0221b86032 odhcpd: Bump to latest commits

02:10 <owrt-images-builds> Build [#20](https://buildbot.staging.openwrt.org/images/#/builders/241/builds/20) of `openwrt-22.03_bcm27xx/bcm2709` completed successfully.

05:05 <owrt-images-builds> Build [#20](https://buildbot.staging.openwrt.org/images/#/builders/184/builds/20) of `openwrt-22.03_ipq806x/generic` completed successfully.

07:23 <jow> ldir: ah, sorry - missed that one!

07:29 <jow> ldir: is there any further change required to make use of the new hostsfile facility?

07:29 <jow> or will bumping the pacakge simply revert to the old behavor?

07:57 <ldir> bumping package reverts to old behaviour, with the new option of also outputting a hostsfile.

07:59 <ynezz> patrykk: can you pastebin somewhere the kernel oops? we can then probably point you to the proper issue tracker, or simply create it in https://github.com/openwrt/openwrt/issues/ and we might then move it

08:01 <ldir> I'm sorry for breaking it for a year. The 'funny' thing is that it wasn't that issue report that made me fix it... I had noticed the behaviour at home and with a 60 minute PD time all of my leases were very short hence could go expired very quickly.

08:22 <ldir> The hostsfile is intended for consumption by dnsmasq - and using its hostsdir option instead of addn-hosts, so dnsmasq scans for changes poked by 'inotify' - the next release of dnsmasq understands removal of hosts from hosts files and doesn't need 'sighupping' all the time.

08:28 <gladiac> I've been getting a lot of "nlbwmon[2334]: Unable to archive database: No such file or directory" errors. One every 30s. Turns out the default db directory "/var/lib/nlbwmon" did not exist. We should probably take care of creating the directory beforehand or on-demand if it does not exist.

08:34 <xback> Ansuel: Thanks for the ath10k-ct fixup :-)

08:39 <gladiac> OK I just saw that parse_config in nlbwmon's init already is supposed to create the directory. I will try to figure out why the directory was missing on my setup

09:03 <ynezz> would be nice to get rid of this "git HEAD" versioning and use something more usable, like the date 2023-11-03 or such

09:04 <ynezz> `git log --grep HEAD --pretty=oneline` makes it quite hard to follow

09:04 <ynezz> not mentioning cherry-picks to stable branches etc.

09:27 <owrt-images-builds> Build [#20](https://buildbot.staging.openwrt.org/images/#/builders/199/builds/20) of `openwrt-22.03_mediatek/mt7622` completed successfully.

09:28 <KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_tegra.html has been updated. (100.0% images and 99.9% packages reproducible in our current test framework.)

09:57 <mrkiko> patrykk: maybe have a look at already open issues at openwrt/mt76

09:57 <mrkiko> patrykk: seems a good place to start for WED related issues

11:19 <jow> ynezz: can you be more specific?

11:19 <jow> ynezz: you mean the "bump to latest Git HEAD" commits?

11:25 <Ansuel> xback btw news about the wifi card?

11:49 <owrt-images-builds> Build [#21](https://buildbot.staging.openwrt.org/images/#/builders/235/builds/21) of `openwrt-22.03_ath79/mikrotik` completed successfully.

11:49 <ynezz> jow: yep

11:53 <stintel> latest is kind of redundant in there. bump to git HEAD says enough. I propose to add the commit (not author) date in the end there. e.g. vallumd: bump to git HEAD (20231103)

11:54 <ynezz> that, or PKG_SOURCE_DATE or short Git SHA would make it more clear from the first sight what is it about

11:55 <jow> well I guess the simplest solution is adding a it bump script to maintainer-tools.git

11:55 <jow> *git bump

11:55 <jow> I'll use it

11:55 <ynezz> or manual github action, creating a PR out of the box :P

11:55 <jow> ./bump-git.sh package/foo [commitish]

11:56 <jow> creating a PR would be a superset of doing the commit in a format you deem sensible

12:07 <jow> I agree that a subject of "$(PKG_NAME): update to Git commit $(SHORT_HASH) ($(COMMIT_DATE))" would make sense

12:07 <jow> ideally the script would:

12:08 <jow> reset PKG_RELEASE to 1

12:08 <jow> - update git commit hash and sha256 sum

12:08 <jow> - include a shortlog (git log --reverse --no-merges --format '%h %s') in the commit body

12:08 <jow> - use the aforementioned commit subject

12:09 <jow> in most cases this would suffice, in exceptional cases the author can git commit --amend to add more stuff to the bump commit

12:09 <jow> ah right, PKG_SOURCE_DATE would need to be set to the date of the bumped commit as well

12:10 <jow> should not be more complex than a bunch of sed operations. if a Makefile is too nonstandard to be mangled this way, the maintainer has to adapt it to the common convention or do the work manually

12:11 <Ansuel> jow well we use the bump to latest GIT convention only for our packages so i think the "non standard makefile thing" wouldn't apply

12:13 <jow> Ansuel: yeah, that's what I was getting at

12:13 <jow> it's not meant to be a universal updater thing

12:26 <xback> Ansuel: will dig in this one further today (wifi card)

12:29 <hitech95> does initramfs images support DTS overlays?

12:58 <f00b4r0> https://github.com/openwrt/openwrt/issues/11650 <- this still seems to be an issue, are we aware of it? It's unclear from the comment if 23.05 is affected. Apparently bad enough that users are providing "workaround scripts"

12:59 <robimarko> Yes, and I have no clue why

12:59 <robimarko> Because, we are intenionally using assisted learning on the CPU port for this reason

13:00 <f00b4r0> i remember seeing something similar in 21.02 but my impression was that it was fixed in 5.15. Will retest.

13:00 <robimarko> Its the same issue probably

13:01 <robimarko> I suspect its an OpenWrt patch induced issue as I find it impossible that nobody else is hitting it with assisted learning

13:01 <f00b4r0> makes sense

13:02 <robimarko> Issue is that nobody even has a clue as to what might be the culprit

13:08 <hitech95> instead is there any know issue on flilologic and wifi <> anything communication that fails after couple of days? (Random)

13:09 <hitech95> any error messages on dmesg. I've tried restarting netifd, enabled and disabled the wifi interfaces. only solution is a reboot.

13:10 <robimarko> Maybe this?

13:10 <robimarko> https://github.com/openwrt/openwrt/pull/13858

13:11 <stintel> anyone else getting "spammed" by Sachin Purani ?

13:11 <stintel> "Request for guidance"

13:13 <stintel> > I have taken your email ID from OpenWRT

13:13 <stintel> yet he mailed me on an address I do not use for OSS

13:15 <f00b4r0> heh

13:15 <hitech95> stintel, fortunately not, but I have a couple of contributions.

13:16 <hitech95> robimarko, probably it is. The lack of errors make it hard to understand. on the ETH side all looks fine. its the wifi that just somehow die.

13:16 <stintel> well I'm tempted to reply with https://openwrt.org/contact but if they're lying about where they found my email they're probably full of shit

13:16 <stintel> so I better just ignore

13:17 <robimarko> stintel: Just ignore

13:17 <robimarko> I get hit with similar from time to time, they seem to grep the git log

13:18 <stintel> but this address is not in git log

13:18 <robimarko> It was never publicly posted somewhere?

13:19 <stintel> afaik no

13:28 <Ansuel> also received that

13:47 <jow> I've just pushed a number of fw4 fixes and improvments and could use some runtime testing help

13:47 <jow> it should break nothing but I'd like some extra confirmation before eventually bumping in 23.x

14:01 <xback> nbd: quick question, In a few hostapd patches from you, I notice you change nl80211_drv_msg to nl80211_bss_msg, as the write should be to the bss

14:02 <xback> but it looks like upstream used nl80211_cmd_msg for that? which is "more correct"? https://w1.fi/cgit/hostap/commit/src/drivers/driver_nl80211.c?id=f7f8ea0aaabbd6b3a9acf8084632362ee6d589a1

14:10 <nbd> no idea why both exist, it looks like nl80211_cmd_msg might make a difference for p2p interfaces, not sure why specific code was added for it though

14:10 <nbd> but for our purposes, the upstream version is fine

15:02 <jow> nbd: is the following approach acceptable to you: http://sprunge.us/EAkwrJ

15:02 <jow> nbd: intent is to allow configure "floating" routes without any specifically bound netdev

15:03 <jow> nbd: but due to netifd's object ownership model the routes need to belong somewhere, so they're tied to loopback

15:50 <mrkiko> regarding PR #13868 - is it me or it's not clear how one may install an unsigned openwrt image?

16:30 <ldir> anyone noticed a massive size increase in images, like 4x ?

16:32 <xback> Ansuel: I tested again

16:32 <xback> see PM

16:57 <xback> ldir: what did you do? :-p

17:01 <ldir> I've no idea :-) I'm now doing a manual bisect to see if I can get back to 'normal'

17:11 <Habbie> 4x? should take just two bisects

17:11 <Habbie> i'll be here all week

17:18 <ldir> Is that how it works? :-D

17:27 <Habbie> no :)

18:36 <ldir> Ahaaaaaa - it's all that mellanox stuff that got defaulted to Y, so I've turned it to N

18:37 <Habbie> good find

18:39 <ldir> and it turns out it was only 2.5 times the size

19:33 <ldir> jow: well I'm running your latest fw4 and nothing has noticeably exploded.

21:36 <jow> ldir: great, thanks for checking