**** BEGIN LOGGING AT Wed Mar 03 03:00:25 2021
Mar 03 03:48:17 <rr123> jow: does uhttpd support gzipped content? i hope it does
Mar 03 03:54:27 <rr123> i read the list and yes squashfs compressed it anyways, but for slow network gzip still helps
Mar 03 07:48:05 <ynezz> meh, any idea how to have gcc 8,9,10 on Debian? I was using testing on CI for quite a long time, but they've removed gcc-8 from testing, so I've tried to use backports, but that doesn't work due to some clashes in libgcc
Mar 03 07:54:31 <jow> rr123: no, it does not
Mar 03 08:09:02 <enyc> ynezz: humm.. many versions at once may not really be supporteh but .....
Mar 03 08:10:18 <enyc> ynezz: on a strictly *testing* system its' possible to  have  debian bullseye  (you could make this into a chroot or so!) ....   and add the sources.list extra entries for older debian buster and even stretch    *below*  bullseye in /etc/apt/sources.list
Mar 03 08:10:45 <enyc> ynezz: this is NOT a supported config but you generally can  add packages for older debian on current debian
Mar 03 08:10:51 <ynezz> I've tried that
Mar 03 08:10:59 <enyc> ynezz: then you can have gcc-10 gcc-9 gcc-8 gcc-7  pkgs installed
Mar 03 08:11:25 <ynezz> I can have either gcc-8 or gcc-9 and gcc-10, not all three
Mar 03 08:11:49 <enyc> ynezz: hrrrrrrrrrrm ok so package dependencies changed, I've had about 3 gens installed previously...)
Mar 03 08:12:38 <enyc> ynezz: what happens ??!?   conflicting file error?
Mar 03 08:16:55 <ynezz> libc6-dev : Breaks: libgcc-8-dev (< 8.4.0-2~) but 8.3.0-6 is to be installed
Mar 03 08:21:28 <ynezz> ah, fixed via --no-install-recommends, so `apt-get --no-install-recommends gcc-8 gcc-9 gcc-10` works, cool
Mar 03 08:26:17 <rsalvaterra> guidosarducci: Reviewing… ;)
Mar 03 08:27:14 <ynezz> rmilecki: do you plan to finish that mtd mac-address upstream effort? :)
Mar 03 08:27:25 <rmilecki> ynezz: doing it now ;)
Mar 03 08:27:31 <ynezz> cool
Mar 03 08:27:51 <ynezz> even that ascii cases?
Mar 03 08:28:08 <rmilecki> no :P
Mar 03 08:28:14 <rmilecki> i'll bring that later
Mar 03 08:28:43 <ynezz> nice, thanks!
Mar 03 08:31:59 <rmilecki> ynezz: the nest step is getting this: https://patchwork.ozlabs.org/project/linux-mtd/list/?series=229768
Mar 03 08:32:11 <rmilecki> ynezz: 1/3 is wrong, I sent correct solution already
Mar 03 08:32:16 <rmilecki> ynezz: 2/3 works perfect
Mar 03 08:32:23 <rmilecki> 3/3 is something i'm going to comment on tright now
Mar 03 08:35:44 <ynezz> well, can't comment, since I've already forget what was the issue with the nvmem maintainer :)
Mar 03 08:36:14 <ynezz> anywya, nice to see, that the works goes on
Mar 03 09:00:15 <mangix> ynezz: is that on buster?
Mar 03 09:01:01 <ynezz> testing is bullseye
Mar 03 09:01:58 <mangix> OK
Mar 03 09:02:43 <ynezz> so I've following Docker image for CI testing http://sprunge.us/ntMOzg
Mar 03 09:03:09 <ynezz> and it currently fails to build with `gcc-8 : Depends: libgcc-8-dev (= 8.3.0-6) but it is not installable`
Mar 03 09:03:47 <mangix> GCC11 seems to introduce build failures :)
Mar 03 09:04:10 <ynezz> here is the build log http://sprunge.us/kVH7oZ
Mar 03 09:04:36 <ynezz> I didn't tested gcc-11 yet
Mar 03 09:13:13 <ynezz> I've added reproducer to https://gitlab.com/ynezz/openwrt-ci/-/issues/3
Mar 03 09:13:28 <ynezz> so if anyone has an idea how to fix that, I would be grateful :)
Mar 03 09:14:42 <mangix> why do you need GCC8?
Mar 03 09:16:06 <ynezz> that's what is used in Debian 10, current stable
Mar 03 09:17:15 <ynezz> so I think, that it's good to test against that version
Mar 03 09:18:40 <ynezz> once we bump buildbot version to 2.10.y we're going to switch from Debian 9 (gcc-6) to Debian 10 (gcc-8)
Mar 03 09:19:11 <ynezz> for the buildworker, so build host, if that's more clear
Mar 03 11:39:52 <russell--> guidosarducci: did you consider using https://github.com/libbpf/libbpf instead of a kernel?
Mar 03 12:52:11 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_sunxi.html has been updated. (0% images and 98.2% packages reproducible in our current test framework.)
Mar 03 13:37:30 <rr123> jow: moving luci to client side could increase js/png/etc size esp when SPA is tried, I played with vuejs and the old juci both can be quite large(>1MB) for initial loading, wish uhttpd can have a gzip option these days.
Mar 03 14:00:07 <rsalvaterra> guidosarducci: No joy, tc-full isn't building here. What's your toolchain? I'm on GCC 10.2.0 and Binutils 2.35.1.
Mar 03 14:00:22 <rsalvaterra> guidosarducci: It's the same error I pasted yesterday.
Mar 03 14:06:27 <dwmw2_gone> mailing lists should be running again; restored from backup on a different box.
Mar 03 14:06:33 <dwmw2_gone> Yay! This time I had backups.
Mar 03 14:09:12 <lynxis> dwmw2_gone: thanks!
Mar 03 14:09:31 <rsalvaterra> dwmw2_gone: Nice! The archives are still down, it seems.
Mar 03 14:10:32 <dwmw2_gone> https://desiato.infradead.org/pipermail/openwrt-devel/
Mar 03 14:10:39 <dwmw2_gone> Until DNS for lists.openwrt.org is updated.
Mar 03 16:59:13 <rsalvaterra> Guys, has anyone thought about creating a make target behaving halfway between clean and dirclean? It'd be really nice if we had a type of dirclean that would work on the current target only.
Mar 03 16:59:57 <rsalvaterra> (Being "current target" the one specified in the current .config, of course.)
Mar 03 17:32:21 <lipnitsk> rsalvaterra: poor man's solution is to clone multiple repos and use one for each target
Mar 03 17:38:12 <rsalvaterra> lipnitsk: The poor man may not have that much hard drive space, though… ;)
Mar 03 17:43:11 <guidosarducci> rsalvaterra: I use the default OWRT toolchain for most test/dev: GCC 8.4.0 and binutils 2.34.
Mar 03 17:43:29 <guidosarducci> lipnitsk: that's the crazy man's solution!
Mar 03 17:44:28 <guidosarducci> rsalvaterra: can you define what this make target should do? I've thought the same but usually more complicated with host/target artifacts in play...
Mar 03 17:47:46 <rsalvaterra> guidosarducci: Hmm… could that be the problem? Anyway, I'm doing a build directly from master with only your two patches applied.
Mar 03 17:50:44 <guidosarducci> russell--: I would have preferred to use an upstream source for all bpf, but that one is only libbpf and so not usable. Reason is bpftool is not a libbpf client, but instead THE libbpf CLI, and uses non-public libbpf entries. That's why bpftool is statically linked and needs to come from the same sources as libbpf.
Mar 03 17:52:48 <guidosarducci> russell--: if enough people convinced that upstream project to also include bpftool, most packagers would switch. I'm meaning to talk to them, but not for 21.02. Andrii is pretty helpful, and worked with me to fix some cross-compilation problems. So we'll see.
Mar 03 17:53:06 <rsalvaterra> guidosarducci: Well, this target do the same as clean, and in addition delete ./{build,staging}_dir/{target,toolchain}-<current target>. The host part could remain.
Mar 03 17:57:56 <guidosarducci> rsalvaterra: are there not make targets that do those (in pieces anyway)?
Mar 03 17:58:02 <rsalvaterra> guidosarducci: It's just that sometimes we're testing on one target… If for some reason we need to rebuild the toolchain (right now, for example, I'd need to go back to GCC 8.4.0 and Binutils 2.34 to try and reproduce your success) and do a dirclean, we lose everything for every target we ever built.
Mar 03 17:59:09 <rsalvaterra> guidosarducci: If there are, they aren't documented. I also grepped around a bit, but haven't found anything conclusive.
Mar 03 17:59:12 <guidosarducci> rsalvaterra: yeah, understood. I do lots of cross-arch testing and have ~10 toolchains in my repo.
Mar 03 18:00:43 <rsalvaterra> guidosarducci: Care to go for ~11, with GCC 10.2.0 and Binutils 2.35.1? ;)
Mar 03 18:01:32 <rsalvaterra> If this build fails, I'll go back to the default GCC/Binutils, but it will take long on this machine.
Mar 03 18:02:04 <guidosarducci> rsalvaterra: that make target is probably worthwhile, I just recommend defining very clearly the use and what it does to get buy in.
Mar 03 18:03:54 <guidosarducci> rsalvaterra: MAX_PATH is from POSIX, and usually comes from #include <limits.h>  -- try adding that.
Mar 03 18:05:53 <rsalvaterra> guidosarducci: I also noticed another thing (I know pretty much nothing about BPF yet, so this might be a stupid question)… Is it alright to build bpftools from Linux 5.11 when our kernel is 5.4 (or 5.10)?
Mar 03 18:07:08 <guidosarducci> rsalvaterra: yes, there are no LTS branches for bpf. The latest version are all supposed to be backward compatible, and otherwise considered a bug.
Mar 03 18:07:29 <guidosarducci> rsalvaterra: ^^^ I'm talking about libbpf and bpftool of course.
Mar 03 18:08:01 <rsalvaterra> guidosarducci: Sure, thanks for clearing that for me. :)
Mar 03 18:10:14 <guidosarducci> rsalvaterra: I *really* want to get my current bpftools/iproute PR's merged, and then backport for 21.02. Fingers crossed, and only possible because iproute2/bpftools are backwards compat.
Mar 03 18:10:53 <rsalvaterra> And speaking of BPF… I don't know if you're aware, but MIPS32 is probably the only major arch which doesn't yet have an eBPF JIT. :/
Mar 03 18:12:41 <rsalvaterra> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/mips/net?id=36366e367ee93ced84fddb8fae6675e12985f5a4
Mar 03 18:13:18 <rsalvaterra> guidosarducci: Oh, I just noticed you're on the cc!
Mar 03 18:13:26 <jow> Hauke: did you see https://bugs.openwrt.org/index.php?do=details&task_id=3657 ?
Mar 03 18:13:31 <jow> Hauke: looks annoying to debug
Mar 03 18:14:24 <guidosarducci> rsalvaterra: uh, yes, I tried to backport the MIPS32 to OWRT 4.19 kernel but found huge bugs. Then they ripped it out. My fault! :-)
Mar 03 18:14:44 <guidosarducci> rsalvaterra: try https://pastebin.com/dl/B6shfncW for your compile...
Mar 03 18:17:10 <rsalvaterra> guidosarducci: If it weren't for you, the bugs would probably go unnoticed for quite a while, so that's good. :)
Mar 03 18:17:32 <rsalvaterra> guidosarducci: Yeah, I'll try that, if the build fails again.
Mar 03 18:19:10 <guidosarducci> rsalvaterra: reality is that embedded systems and cross-compilation and not main focus of mainline Linux development and testing. So projects like OWRT add *huge* quality coverage for upstream Linux. IMO.
Mar 03 18:19:13 <rsalvaterra> Anyway, I find it a bit odd a MIPS32 eBPF JIT not being a priority, when there are so many MIPS32-based routers…
Mar 03 18:20:06 <jow> the many MIPS32 based routers are stuck on ancient toolchains
Mar 03 18:20:31 <jow> it'll be a decade before vendors start looking into a post-iptables solution
Mar 03 18:20:36 <jow> mips32 will be dead by then
Mar 03 18:20:37 <Hauke> jow: I saw a similar report here: https://github.com/ppp-project/ppp/pull/257#issuecomment-787489682
Mar 03 18:20:59 <guidosarducci> rsalvaterra: yes, that's my concern too. The original author said he'd follow up but nothing yet. I would look myself, but getting decent BPF support on OWRT is first.
Mar 03 18:21:46 <guidosarducci> jow: mips32 will probably be kicking somewhere when all our grandchildren and post-apocalypse zombies...
Mar 03 18:22:00 <guidosarducci> ^^ "are"
Mar 03 18:22:55 <rsalvaterra> Yeah, the internet will keep running on old WRT54G routers. :P
Mar 03 18:23:23 <jow> Hauke: so pppd starts messing with the routing table? maybe we should simply add nodefaultroute(6) to the ppp.sh proto scrupt
Mar 03 18:24:53 <jow> Hauke: nvm, misread the report. so defaultroute6 / nodefaultroute6 are unrelated
Mar 03 18:25:19 <jow> sigh, I hate debugging pppoe, setting up a server is always such a pain
Mar 03 18:32:41 <rsalvaterra> guidosarducci: That diff you pasted is against what?
Mar 03 18:32:59 <rsalvaterra> Gah… and the build just failed again.
Mar 03 18:33:49 <rsalvaterra> Nevermind, iproute2, found it.
Mar 03 18:51:27 <rsalvaterra> guidosarducci: My life is now playing #include <limits.h> whack-a-mole. :P
Mar 03 18:57:41 <grift> i reported that pppd issue upstream, not sure what exactly happens but i just noticed it started to write the routing table, because selinux blocked it (i had to add the rules to allow it):
Mar 03 18:57:46 <grift> https://git.defensec.nl/?p=selinux-policy.git;a=blobdiff;f=src/agent/pppd.cil;h=0289d3a4e2f9ccdad41ba7f34ae329d5cd1792ea;hp=ca5bdf56dac367dac9100686b17e654a0ba84bbe;hb=4dc6bc2264cf4cd325849b729969852c418d347d;hpb=254ff43b0786525a09575c1eb296a4da885ccb50
Mar 03 18:58:37 <grift> for me no other visible issues, everything seems to work fine and i had to add these rules anyway sooner or later since there are scenarios where you may want to have it write it
Mar 03 18:58:54 <grift> but i dont use dnsmasq
Mar 03 19:56:49 <rsalvaterra> guidosarducci: Would you like some news?
Mar 03 20:06:23 <Grommish> rsalvaterra: Ooo.. News?
Mar 03 20:06:50 <Grommish> rsalvaterra: BTW, WSL2 took a dump on me and refuses to start now >_<
Mar 03 20:07:23 <rsalvaterra> Grommish: How about replacing that crap with the real deal? ;)
Mar 03 20:07:46 <Grommish> I've got a build machine, but I liked being flexible :)
Mar 03 20:08:02 <Grommish> and Ive got this laptop wit a 2tb spinning rust drive
Mar 03 20:08:49 <Grommish> besides, it was running Ubuntu 20.04 LTS flawlessly
Mar 03 20:09:00 <Grommish> Not sure why it just up and stopped haha
Mar 03 20:25:30 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_omap.html has been updated. (0% images and 94.5% packages reproducible in our current test framework.)
Mar 03 21:30:26 <guidosarducci> rsalvaterra: what was the news? Oh, and your failed compile: curious what musl version?
Mar 03 21:31:00 <rsalvaterra> guidosarducci: In-tree musl, still waiting for mangix pull to land. :)
Mar 03 21:31:29 <rsalvaterra> guidosarducci: https://github.com/openwrt/openwrt/pull/3961
Mar 03 21:32:55 <rsalvaterra> Also, did you receive my email? I cc'd you on the patch I sent to fix iproute2.
Mar 03 21:36:56 <guidosarducci> rsalvaterra: ok, thanks, will take a look at PR. Not checked mail but glad you sent a patch, saved me sending mine: https://github.com/guidosarducci/iproute2/commit/23e1c05b3395928ca2780d6d83829b360ef3537e..
Mar 03 21:37:52 <rsalvaterra> guidosarducci: Thanks, but that's half a patch, unfortunately. Like I said, whack-a-mole. :)
Mar 03 21:41:25 <guidosarducci> rsalvaterra: sure, if your config is triggering them then better you sort it out. Do you understand why not seen before?
Mar 03 21:42:46 <rsalvaterra> guidosarducci: No idea yet. My C is still a work-in-progress, very superficial, at the moment.
Mar 03 21:59:29 <guidosarducci> rsalvaterra: ok, saw your mail. Thought you were sending to netdev to fix upstream, not OWRT. Were there multiple patches? I though so with the whack-a-mole comment before.
Mar 03 22:02:14 <rsalvaterra> guidosarducci: To be honest, I'm not sure if it makes sense sending them upstream. I have to build here and see if I have the same problem. Yes, I had to irc://chat.freenode.net:6697/#include <limits.h> in both bpf_glue.c and bpf_libbpf.c.
Mar 03 22:10:05 <guidosarducci> rsalvaterra: I think it's definitely a problem, and those are the only two files using PATH_MAX which don't include limits.h. Are you able to confirm GCC 10 is the problem per your email? If you like, I can send upstream with your "Reported-by:".
Mar 03 22:54:25 <rsalvaterra> I… have no idea what happened with my last message.
Mar 03 22:55:02 <rsalvaterra> guidosarducci: Sure, I can give it a try tomorrow, but now it's a bit late to compile a new toolchain. :)
Mar 03 23:18:42 <mangix> rsalvaterra: `you're not the only one waiting
Mar 03 23:19:22 <rsalvaterra> mangix: You know it… :P
Mar 03 23:20:24 <mangix>  it's basically ready. compiles with all packages
Mar 03 23:21:00 <rsalvaterra> mangix: So… what else is needed?
Mar 03 23:22:39 <mangix> nothing
Mar 03 23:23:52 <mangix> 2 or 3 of the commits in that PR are actually GCC10 fixes, not necessarily musl.
Mar 03 23:24:18 <mangix> I compiled all packages with GCC10 + musl
Mar 03 23:24:37 <rsalvaterra> Nice. Binutils 2.35.1 too?
Mar 03 23:25:15 <mangix> yes
Mar 03 23:26:18 <rsalvaterra> In that case, I don't see why I shouldn't shove it in my tree. ;)
Mar 03 23:26:32 <mangix> I just rebased FWIW
Mar 03 23:27:44 <mangix> let me spin up a new build since the broken autoconf-lean stuff was reverted
Mar 03 23:28:27 <rsalvaterra> Ok, if it's all good, I'll throw it in the pile.
Mar 03 23:33:23 <rsalvaterra> And Linux 5.10.18 running on the Archer C6. Three down, two to go… B)
Mar 04 00:11:03 <owrt-snap-builds> build #791 of mediatek/mt7622 is complete: Failure [failed pkgbuild]  Build details are at http://buildbot.openwrt.org/master/images/builders/mediatek%2Fmt7622/builds/791  blamelist: Petr ?tetiar <ynezz@true.cz>, Felix Fietkau <nbd@nbd.name>, Perry Melange <isprotejesvalkata@gmail.com>, Clemens Fruhwirth <clemens@endorphin.org>
Mar 04 00:27:04 <owrt-snap-builds> build #669 of layerscape/armv7 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv7/builds/669
Mar 04 01:07:18 <guidosarducci> rsalvaterra: just so you know, I was able to build everything with gcc 10.2.0 for ppc *without* any of those iproute2 patches, so I'm doubtful the gcc version was the culprit. Plus that problem didn't show up on buildbots IIRC. Perhaps one of the local changes in your tree...
**** ENDING LOGGING AT Thu Mar 04 02:59:56 2021