03:26 <KGB-1> https://tests.reproducible-builds.org/openwrt/openwrt_lantiq.html has been updated. (96.2% images and 100.0% packages reproducible in our current test framework.)

09:28 <oliv3r[m]> funnily enough; the rust maintainer in the linux kernel wouldn't budge on switching the rust indentation to tabs 'but rust defacto default is 4 spaces, so we should stick with that' even though there's a formatter config file, that lets you happily set it to 8 spaced tabs :)

09:28 <oliv3r[m]> choice but no choice :p

09:28 <oliv3r[m]> so soon, we'll have tabs and spaces mixed in the kernel :)

09:29 <robimarko> Ugh, I am alergice to spaces as indentaion

09:31 <f00b4r0> oliv3r[m]: wouldn't checkpatch fail such submissions though

09:31 <oliv3r[m]> nope, because I'm sure they've a) added a rule to not check .rs files; and b) they'll run everything through rustfmt to ensure you will follow whatever the rust maitainer wants

09:32 <oliv3r[m]> it's kind of similar tot he same stupidity of saying 'kernel multi line comment styles is "/*\n * bla\n */" but then say "except in the networking infratstructure. so now, if you write a patch that touches both for some reason, you have to be extra precious there. It's just dumb as fuck

09:33 <f00b4r0> it's opensource ;P

09:34 <oliv3r[m]> but the world is moving to space indentation, it's a lost cause. Even though; it should be so obvious :( (preaching to the choir here, but) tab indicates a level of indentation. Space is used to align things nicely within that level of indentation. Don't understand why this is so hard to grasp. But then I see code bases where things get mixed on single lines, tailing white spaces, missing eol; people don't give a fuck 'it compiles don't

09:34 <oliv3r[m]> it'

09:34 <oliv3r[m]> or, the most obvious one indeed 'but 2/3/4/7 space just looks better to me' not realizing that you can set the display width of a tab, keeping alignment and indentation identical :(

09:35 <f00b4r0> yeah that.

09:35 <oliv3r[m]> f00b4r0: haha, I sent a patch; but it was ignored, because the rust maintainer also didn't see the benefit and was very adement about 'but all rust code in the world will be written with 4 space indentation!! I promise' (it won't be of course once it gets picked up)

09:36 <f00b4r0> that sounds fairly retarded indeed

09:36 <oliv3r[m]> besides, dislectic people, people with reading disabilities strongly favor tabs, and vengfully hate spaces; but even that argument 'meh, they'll just have to deal or not contribute'

09:36 <f00b4r0> further illustrating the openmindedness of spaces worshipers ;^P

09:37 <oliv3r[m]> you can see the duscission on the lkml :D found it too : https://lkml.org/lkml/2022/7/18/109

09:37 <oliv3r[m]> I hoped greg or linus would at some point chime in; but sadly, either they didn't see, or didn't care :(

09:38 <oliv3r[m]> would be fun if this would bounce back ina few months with a 'wtf where you guys thinking' :D

09:40 <f00b4r0> well I'm willing to bet that come the first rust-written driver formatted with silly rules, either of them will go something like "fuck no" ;)

09:41 <oliv3r[m]> though I must admit, the kernel style even has something weird too (not documented, but enforced only via checkpatch) where they prefer to use tabs to align stuff if a function declaration spans multiple lines. 'use tabs as much as you can, then space'; which is really weird

09:41 <f00b4r0> (Although Greg is usually less graphic in his replies)

09:41 <oliv3r[m]> i bet the rust maintainer will be responsible for reviewing all that

09:42 <oliv3r[m]> there was talk about a first uvc/camera rust driver already; so who knows

09:42 <oliv3r[m]> but tabs/spaces is not something easily spotted during a review; except of course when it's 4 spaces deep, and the maintainer is like 'why is this so ...tight'

09:46 <owrt-snap-builds> Build [#842](https://buildbot.openwrt.org/master/images/#builders/52/builds/842) of `x86/legacy` failed.

10:31 <rmilecki> ping Alexandru Gagniuc

10:31 <rmilecki> do we have Alex on IRC?

10:31 <rmilecki> looking for a help with Netgear WAX218 (ipq807x)

10:34 <robimarko> rmilecki: What do you need for WAX218?

10:36 <rmilecki> robimarko: understand what it "boot loop" caused by when firmware gets flashed incorrectly

10:36 <rmilecki> it's mentioned in the https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=7801161c4bb2413817b3dfd01695050e2da27bf3 ("ipq807x: add support for Netgear WAX218")

10:37 <robimarko> rmilecki: Ok, that seems rather specific

10:37 <rmilecki> right

10:37 <robimarko> You can find Alexandru on IRC under mrnuke

10:39 <rmilecki> oh, thanks

10:39 <rmilecki> mrnuke: can you let me know what is that boot loop related to?

13:44 <mrnuke> rmilecki: We can't tell if we're booting from mtd12 or mtd14, so we assume mtd12. If we're on mtd14, we're looking for rootfs/rootfs_data on mtd12, and we won't find it

13:54 <rmilecki> mrnuke: i'm like to look into improving that flashing procedure

13:55 <rmilecki> so user can just flash OpenWrt using vendor's UI without bothering about current rootfs partition or ssh tricks or initramfs image

14:01 <rmilecki> mrnuke: i'm getting "ERROR:phy_addr 0 phydev is NULL" errors from kernel

14:01 <rmilecki> someone else reported that too: https://forum.openwrt.org/t/openwrt-support-for-wax218/136060/39

14:01 <rmilecki> any idea about that?

14:01 <rmilecki> robimarko

14:01 <rmilecki> ?

14:01 <rmilecki> those appear over and over every second

14:06 <rmilecki> robimarko: here someone says those errors went away after applying some patches on top of your branch: https://forum.openwrt.org/t/adding-openwrt-support-for-netgear-rax120-nighthawk-ax12/75592/118

14:13 <mrnuke> rmilecki: Regarding the phydev is NULL spam, does this work for you: https://github.com/kirdesde/openwrt_robi/commit/61e6b34e0bfe2883ca5a1a0a850ea23ba596d95c ?

14:14 <rmilecki> oh, that's an interesting solution ;)

14:20 <mrnuke> Re the flashing procesure, the only way I know to find out the correct mtd with the rootfs is the partition table that the bootloader patches under the nand controller node. But that's not where the partition table is, or where linux looks for it

14:43 <rmilecki> mrnuke: robimarko: so many questions... another one if I may:

14:43 <rmilecki> i have 2 wireless PHYs in WAX218

14:43 <rmilecki> but I can see only 1 wifi controller defined in .dts file

14:43 <rmilecki> also this board has no PCIe devices connected

14:44 <rmilecki> is that a single wireless controller with 2 radios then?

14:51 <mrnuke> I think ath11k takes care of both radios. One node under devicetree. Not sure if there are separate chips on the board

15:03 <rmilecki> mrnuke: ok, confirmed, one wifi controller can have multiple radios

15:03 <rmilecki> they are discovered in the ath11k_wmi_tlv_ext_soc_hal_reg_caps_parse() https://elixir.bootlin.com/linux/latest/source/drivers/net/wireless/ath/ath11k/wmi.c#L4577

15:26 <Ansuel> oliv3r just read the thing... Can totally say it's a timebomb we can just LOL. At the right time and see the chaos...

15:31 <robimarko> rmilecki: Those NULL phy are spam as for some reason SSDK will always try to look at 0x0 - 0x4 for PHY-s even if they are not defined in DTS

15:31 <robimarko> As far as wireless PHY-s go ath11k takes care of that based on FW message as you can have up to 3 PHY-s on IPQ8074

18:06 <philipp64> what's the make target to rebuild tools, hostpkg's, etc? I tried to rebuild package/libubox/{clean,compile} but that only rebuild the target version, not the host version...

18:07 <philipp64> No mention of it here: https://openwrt.org/docs/guide-developer/toolchain/single.package

18:23 <tmn505> it's package/libubox/host/{clean,compile}

18:27 <tmn505> and for tools it's tools/automake/{clean,compile}

18:43 <philipp64> Ah, thanks... I'll update the Wiki.

19:07 <oliv3r[m]> Ansuel: yeah I hope so too; because it's a bit frustrating and annoying to see happening. But who knows, maybe linus saw the 'space' light too :)

19:13 <owrt-snap-builds> Build [#845](https://buildbot.openwrt.org/master/images/#builders/42/builds/845) of `ramips/mt76x8` completed successfully.

20:29 <Borromini> robimarko: f00b4r0: sorry, thought you both had commit rights

20:41 <aparcar[m]> https://github.com/openwrt/openwrt/releases/tag/v22.03.4 released

20:59 <aparcar[m]> https://github.com/openwrt/openwrt/releases/tag/v21.02.6 released

21:54 <schmars[m]> very nice

21:59 <hurricos> mrnuke: one of the newer ZyXEL switches does in the 1900 series

22:00 <jakllsch> (does what?)

23:16 <hurricos> jakllsch: uses I2C in place of UART for communicating to the PSE hardware :^)

23:19 <schmars[m]> it's going to take a while longer before 21.02.6 buildbot is finished eh?

23:22 <aparcar[m]> schmars: yea it's terrible

23:23 <schmars[m]> :-)