**** BEGIN LOGGING AT Sun Dec 13 02:59:56 2020
Dec 13 06:40:17 <aparcar[m]> rsalvaterra: ping
Dec 13 06:42:28 <aparcar[m]> neoraider: can you rebase https://patchwork.ozlabs.org/project/openwrt/patch/0f48abf2ac872957d6a4a150ead39564053f2afc.1589716209.git.mschiffer@universe-factory.net/ ?
Dec 13 08:46:34 * aparcar[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/KszvMgLcdcZiqZTWkgZIUcLj/message.txt >
Dec 13 08:52:02 <PaulFertser> aparcar[m]: that's expected when you're trying to use kmods that were not build along with the kernel...
Dec 13 08:52:36 <PaulFertser> Or do you mean the kmod had wrong dep inside?
Dec 13 08:52:36 <aparcar[m]> PaulFertser: yea but opkg even download the package from the special kmod archive
Dec 13 08:52:57 <PaulFertser> aparcar[m]: btw, you hilighting jow didn't work as your long message was sent as a URL to a web site.
Dec 13 08:53:22 <aparcar[m]> oh bummer
Dec 13 08:54:37 <aparcar[m]> dangole: https://paste2.org/XNEGmeyy please check this opkg output
Dec 13 08:54:40 <PaulFertser> aparcar[m]: hah, Depends: kernel (=5.4.81-1-19448ecbdd32381bda1125c6da8fe07e) inside that kmod. So opkg is showing something else, weird.
Dec 13 08:54:42 <aparcar[m]> something is still bad
Dec 13 08:55:04 <PaulFertser> Did you download the file just recently?
Dec 13 08:55:10 <aparcar[m]> PaulFertser: I'm guessing it crashes at some point inside, the crash log sent to dango is related
Dec 13 08:55:20 <aparcar[m]> yea like 4 minutes ago
Dec 13 08:56:35 <PaulFertser> aparcar[m]: and what kernel version are you running there atm?
Dec 13 08:58:12 <aparcar[m]> the same as the arhcive
Dec 13 08:58:14 <aparcar[m]> *archive
Dec 13 08:58:42 <PaulFertser> aparcar[m]: I wonder where 5.4.82 can come from then, as I downloaded the ipk unpacked everything manually, and it's not inside.
Dec 13 08:59:31 <PaulFertser> Does "opkg info kernel" show 5.4.81 too?
Dec 13 09:01:33 <aparcar[m]> Version: 5.4.81-1-19448ecbdd32381bda1125c6da8fe07e
Dec 13 09:04:17 <PaulFertser> aparcar[m]: is it possible opkg is trying to install some other ipk, not the one it just downloaded?
Dec 13 09:04:52 <aparcar[m]> I thought the error would be fixed by a series of patches from dangole and me, but now it seem to come again in some corner cases
Dec 13 10:47:34 <rsalvaterra> aparcar[m]: pong, but I guess now it's a bit late for you. :/
Dec 13 13:38:14 <f00b4r0> stintel: testing lldpd on 19.07, it seems the "interface" section of the config doesn't work for me. On APs with a single ethernet (eth0) and a single "lan" device ("br-lan"), lldpd doesn't listen on lan. It only listens on lo. Expected?
Dec 13 13:41:31 <f00b4r0> oh. This looks like a race. Restarting the service "fixes" the issue
Dec 13 14:10:27 <dangole> olmari: any chance you can test ujail on the wdr4900 any time soon?
Dec 13 14:29:54 <dengqf6> https://lore.kernel.org/netdev/20201213140710.1198050-1-vladimir.oltean@nxp.com/T/#t
Dec 13 17:39:42 <owrt-snap-builds> build #752 of sunxi/cortexa53 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/sunxi%2Fcortexa53/builds/752
Dec 13 17:57:07 <owrt-snap-builds> build #549 of ath79/tiny is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Ftiny/builds/549
Dec 13 18:03:26 <owrt-snap-builds> build #543 of ipq40xx/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/ipq40xx%2Fgeneric/builds/543
Dec 13 18:40:46 <zorun> congrats on the new wiki look :)
Dec 13 18:53:14 <swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html
Dec 13 19:11:03 <aparcar[m]> rsalvaterra: ping2
Dec 13 19:11:52 <aparcar[m]> oh cool wiki
Dec 13 19:12:54 <rsalvaterra> aparcar[m]: 'morning! :)
Dec 13 19:13:19 <aparcar[m]> I remeber you had some kmod stuff that looked like it wouldn't be to hard to review
Dec 13 19:13:44 <aparcar[m]> 98581ec478 zram-swap: remove the compression streams settings
Dec 13 19:13:57 <aparcar[m]> this is entirely obsolete because it's done automatically in kernel?
Dec 13 19:14:25 <rsalvaterra> Exactly. The kernel uses per-CPU compression streams. That's a no-op.
Dec 13 19:14:48 <rsalvaterra> (There's a link to the relevant kernel commit in my patch explaining the whole deal.)
Dec 13 19:15:26 <aparcar[m]> okay sounds legit
Dec 13 19:20:04 <rsalvaterra> I also sent a patch adding the lzo-rle.ko to the kmod-lib-lzo package, because zram (and probably other crypto API users) expect it to be there. Upstream is a mess in that regard, I don't know if I'll be able to untangle it without breaking anything. At least I fixed the zram dependencies for 5.11, I think (i.e. linux-next hasn't screamed at me yet).
Dec 13 19:28:47 <aparcar[m]> do you have both patches at hand?
Dec 13 19:30:24 <rsalvaterra> Sure, they're both on Patchwork.
Dec 13 19:30:39 <rsalvaterra> https://patchwork.ozlabs.org/project/openwrt/patch/20201019182113.958966-1-rsalvaterra@gmail.com/
Dec 13 19:30:46 <rsalvaterra> https://patchwork.ozlabs.org/project/openwrt/patch/20201210132825.2342-1-rsalvaterra@gmail.com/
Dec 13 19:31:46 <aparcar[m]> okay I'm currently trying to fix an opkg issue but try to review it afterwards
Dec 13 19:32:26 <rsalvaterra> Ok, thanks!
Dec 13 19:32:51 <aparcar[m]> can't we go full on zstd instead of lzo?
Dec 13 19:33:47 <rsalvaterra> aparcar[m]: Not before Linux 5.11. ;)
Dec 13 19:34:32 <rsalvaterra> That's the dependency issue I fixed. Until Linux 5.11, zram will always have a hard dependency on lzo.
Dec 13 19:35:39 <rsalvaterra> But going full zstd (or as much as possible, at least) is my objective, yes.
Dec 13 19:38:17 <rsalvaterra> Well… Come to think of it, I could always backport the kernel patch to our tree, though…
Dec 13 19:39:43 <aparcar[m]> rsalvaterra: yea people tend to do quite some backporting...
Dec 13 19:40:26 <rsalvaterra> I guess this is simple enough, but I'll wait until we move to 5.10.
Dec 13 19:40:45 <aparcar[m]> rsalvaterra: change of plan. I go surf but will review your two patches afterwars ;)
Dec 13 19:41:15 <rsalvaterra> Ahahah! I would too, if I lived in Hawaii. XD
Dec 13 19:41:19 <rsalvaterra> Go for it! ;)
Dec 13 20:32:17 <zorun> just read that the Archer AX50 has a Intel CPU °°
Dec 13 20:33:19 <zorun> but actually, it does not look like x86
Dec 13 20:33:23 <zorun> https://deviwiki.com/wiki/TP-LINK_Archer_AX50
Dec 13 21:13:18 <Borromini> zorun: they bought lantiq
Dec 13 21:13:26 <Borromini> it's like lots of those Fritz!Boxes
Dec 13 21:14:08 <Borromini> Intel sold their Xscale, only to buy into the non-x86 space again a few years later. Money to burn eh.
Dec 13 21:15:00 <Borromini> apparently they sold it of this year again though
Dec 13 21:27:36 <rr123> website is revamped? https://openwrt.org/docs/techref/ubus has TRX vs TRX2 on top, strange
Dec 13 21:29:36 <rr123> so does : https://openwrt.org/docs/techref/filesystems.network, layout has some bug for sure
Dec 13 21:32:18 <zorun> all techref namespace seems to be affected
Dec 13 21:32:23 <zorun> already reported here apparently https://forum.openwrt.org/t/implementation-of-the-new-styling-on-openwrt-websites/81672/8
Dec 13 21:33:01 <Borromini> tabbing is broken as well
Dec 13 21:33:02 <zorun> Borromini: ah, they re-sold Lantiq?
Dec 13 21:33:07 <zorun> or did you mean Xscale?
Dec 13 21:33:56 <Borromini> zorun: no apparently lantiq got resold as well.
Dec 13 21:34:09 <Borromini> https://en.wikipedia.org/wiki/Lantiq
Dec 13 21:34:17 <Borromini> see last line of 'corporate history'
Dec 13 21:40:37 <zorun> oh well
Dec 13 21:40:54 <zorun> never even heard about MaxLinear
Dec 13 21:41:43 <rr123> i run daily master build, somethin went wrong as my new build did not come up at all
Dec 13 21:45:23 <rr123> ath79 target, i saw libubox, selinux, fstools and procd new changes added
Dec 13 21:48:49 <Borromini> zorun: me neither.
Dec 13 21:48:57 <Borromini> rr123: and if you roll them back?
Dec 13 21:49:47 <rr123> Borromini: reboot did not help, need get it near my PC to reset to factory then see which commit broke it
Dec 13 21:50:42 <rr123> a few weeks back similar brick-age happened due to procd changes
Dec 13 21:51:17 <Borromini> yes i remember stintel talking about that
Dec 13 22:00:58 <svanheule[m]> IIRC that had to do with procd no longer running as root, but with the new user missing in /etc/passwd
Dec 13 22:01:23 <svanheule[m]> caused me to have a brick too, after I restored an old config on a build that expected the new user
Dec 13 22:48:17 <stintel> svanheule[m]: indeed. I tried bisecting it, but as I was forced to write factory image after each attempt, it did not expose the bug as it was in sysupgrade
Dec 13 22:49:04 <stintel> I guess it's my own fault as I warned about users being created in packages not working with sysupgrade but never fixed it myself
Dec 14 02:35:37 <m4t> mangix: hey, does this look right to you? https://github.com/openwrt/packages/compare/master...tofurky:fwknop_gpgme_deps i saw you'd recently switched around the gpgme options which is why i ask. if so i can open a PR. thanks
Dec 14 02:49:36 <mangix> m4t: I don't remember touching gpgme. I would replace ln -sf with $(LN)
Dec 14 02:51:43 <mangix> m4t: both those packages also require PKG_RELEASE bumps
**** ENDING LOGGING AT Mon Dec 14 03:00:00 2020