**** BEGIN LOGGING AT Sat Feb 27 03:00:25 2021 Feb 27 03:01:21 Im basically asleep right now but Feb 27 03:01:25 lipnitsk: Feb 27 03:01:26 select CRYPTO_POLY1305_MIPS if CPU_MIPS32 || (CPU_MIPS64 && 64BIT) Feb 27 03:01:48 How is it possible that the octeonplus doesnt hit that? Feb 27 03:03:52 zx2c4: that CPU is a nightmare Feb 27 03:03:58 somehow it doesn't set CPU_MIPS64? Feb 27 03:04:39 zx2c4: target/linux/octeon/config-5.4 Feb 27 03:05:30 https://github.com/boostorg/fiber/pull/270 Feb 27 03:07:05 if it is MIPS, but doesn't set CPU_MIPS32 or CPU_MIPS64, then what the hell is it? It sets CONFIG_CPU_MIPSR2=y, though Feb 27 03:07:07 go figure Feb 27 03:08:53 hmmm fedora's nano doesn't work right through ssh Feb 27 03:08:57 have to use nvim Feb 27 03:10:45 lipnitsk: that seems like an... Error Feb 27 03:10:53 It should set cpu mips64 Feb 27 03:11:03 I wonder how it's possible it gets neither Feb 27 03:11:46 Digging through history "gitk target/linux/octeon/config\*", nothing yet. maybe it was just never set Feb 27 03:12:04 err, gitk target/linux/octeon/config\* Feb 27 03:12:22 any reason why octeon may not support poly1305-mips? Feb 27 03:12:37 check the generated config file in target-octeon/linux-x/.config Feb 27 03:12:57 lipnitsk: no, it def supports it Feb 27 03:13:16 Im on my phone. If you see a gend config, mind paste binning? Feb 27 03:13:35 mangix: you mean tmp/.kconfig-octeon ? Feb 27 03:13:41 no Feb 27 03:14:10 build_dir/target-mips64-xxx/linux_xxx/linux-xxx/.config Feb 27 03:14:28 that's the final linux config Feb 27 03:14:46 zx2c4: let me get that Feb 27 03:15:55 https://github.com/torvalds/linux/blob/3fb6d0e00efc958d01c2f109c8453033a2d96796/arch/mips/Kconfig#L2110 Feb 27 03:17:28 building.... let me pastebin the less final one from tmp/ Feb 27 03:17:48 I found the issue Feb 27 03:17:57 It's a mips kconfig problem Feb 27 03:18:59 i find it interesting that issues can be found on a phone :) Feb 27 03:19:06 missing a case? Feb 27 03:19:06 Needs CPU_CAVIUM_OCTEON Feb 27 03:19:17 In that link i pasted above Feb 27 03:19:27 Im so tired i cam barely keep my eyes open Feb 27 03:19:35 Ill play with a patch tomorrow Feb 27 03:19:43 default y if CPU_MIPS64_R1 || CPU_MIPS64_R2 || CPU_MIPS64_R5 || CPU_MIPS64_R6 || CPU_CAVIUM_OCTEON ? Feb 27 03:19:51 zx2c4: go to bed Feb 27 03:25:45 /usr/bin/install: cannot stat '.libs/libffi.so.7.1.0': No such file or directory Feb 27 03:25:54 what the hell is wrong with glibc... Feb 27 03:30:36 package/feeds/base/ca-certificates failed to build. Feb 27 03:30:39 incredible Feb 27 03:31:15 no download method available? Feb 27 03:34:57 blocktrron: ^^ Feb 27 03:45:20 zx2c4: https://pastebin.com/adFZAAPX when you wake up - that's the octeon .config from linux Feb 27 04:01:22 why is sane-backends compiling for three hours? Feb 27 04:17:59 patch sent Feb 27 04:18:03 let's see what happens Feb 27 05:19:44 build #626 of bcm47xx/generic is complete: Failure [failed pkgbuild] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm47xx%2Fgeneric/builds/626 blamelist: Ilya Lipnitskiy , David Bauer , Daniel Gonz?lez Cabanelas , Jason A. Donenfeld Feb 27 05:36:18 rr123: luci is being refactored to javascript in place, so the lua dependency will disappear altogether (although that might take time), large parts of luci don't even use it at all anymore (and lua-compat merely serves as bridge between old- and new). keep in mind that this refactoring /also/ side-steps updating luci to lua >=5.3, which is rather non-trivial as well Feb 27 05:57:20 build #575 of bcm63xx/smp is complete: Failure [failed pkgbuild] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm63xx%2Fsmp/builds/575 blamelist: Ilya Lipnitskiy , David Bauer , Daniel Gonz?lez Cabanelas , Jason A. Donenfeld Feb 27 06:59:16 Evening/Morning all. How is everyone? I can finally turn my attention back to the bricked Shield :D Feb 27 07:34:51 mangix: I'll have a look Feb 27 07:37:31 do you have a faillog? Works here Feb 27 07:43:01 lipnitsk: where should this emailed patch be? Feb 27 07:49:42 blocktrron: openwrt devel list Feb 27 07:50:02 It fixes everything except for octeon Feb 27 07:50:23 zx2x4 will look at octeon today Feb 27 07:50:42 blocktrron: using the SDK Feb 27 08:00:06 mangix: https://gist.github.com/blocktrron/bb425bcf0f72ec7f3f03d4937872957f Feb 27 08:00:22 Seems to work Feb 27 08:00:36 lipnitsk: found it. Feb 27 08:00:49 Will to a build test for ath25 + ath79 and push afterwards Feb 27 08:00:59 ping me once you have a strategy for octeon Feb 27 08:02:26 Will do Feb 27 09:10:57 Oops.. kernel panic on this test 5.10 build. damex lemmi could you look at the PR for the log? Feb 27 09:13:04 but, i'm now in a position to actually recover from testing easily, so.. Feb 27 10:26:53 Grommish: kernel panic on malta or device? Feb 27 10:27:10 mangix: device Feb 27 11:25:03 Grommish: so 5.10 is breaking your shield right? Feb 27 11:25:10 will give it a shot on my erlite. Feb 27 11:25:34 Borromini: yes, I'm going to try another version for testing Feb 27 11:26:35 different from adrian's PR? Feb 27 11:28:22 note that there might be essentially three causes: 1. 5.4 refresh, 2. the erpro symbol added back, 3. the 5.10 bump Feb 27 11:29:26 :P Feb 27 11:29:42 adrianschmutzler: and these are all three bundled in your pr? Feb 27 11:29:52 i saw a separate pr for that erpro symbol, so probably no Feb 27 11:30:09 I made the 5.10 first, and then got confronted with the erpro situation again Feb 27 11:30:26 ok Feb 27 11:30:47 but since I looked closer now, I came to a different conclusion when I realized that this was removed in 4.19 bump due to a mistake Feb 27 11:31:31 so, I created the erpro commit and then came to the conclusion that the diff for 5.10 might be much simpler when we put the 5.4 refresh in front of it Feb 27 11:31:54 and the erpro fix has higher priority for me anyway, since I want to fix support for that also in 21.02 Feb 27 11:32:00 I need to go thru the 5.10 kernel and see what is missing Feb 27 11:32:12 Grommish: I just read ehci everywhere Feb 27 11:32:21 Yeah Feb 27 11:32:45 I was testing if it was missing, but I was in a bad place recovery wise on it Feb 27 11:32:56 That has been fixed at least Feb 27 12:27:35 lipnitsk: just sent a patch to lkml Feb 27 12:27:42 waiting for it to show up on the archives now to give you a link Feb 27 12:43:04 blocktrron: lipnitsk: sent patch to openwrt-devel, CC'd ya Feb 27 12:43:16 upstream is https://lore.kernel.org/linux-mips/20210227122605.2680138-1-Jason@zx2c4.com/ Feb 27 12:43:35 zx2c4: Feb 27 12:43:37 thanks Feb 27 12:43:40 downstream is http://lists.openwrt.org/pipermail/openwrt-devel/2021-February/034052.html Feb 27 12:44:05 I havent tested this with octeonplus yet but i'm 90% sure it'll work... Feb 27 12:44:08 kicking off a build now Feb 27 13:06:30 guys can somebody tell me what secsize represents in uboot-envtools? Feb 27 13:07:17 i'm looking at the gs108t v3 and it has slightly different namings for its u-boot/system settings partitions, but i'm only getting the u-boot one to work with fw_printenv, fw_printsys doesn't work for the system settings one Feb 27 13:23:07 Borromini, tech spec - see sector size mt25q_qlkt_u_512_abb_0.pdf (google that filename /datasheet) Feb 27 13:24:58 in u-boot it might be possible to just dd if=/dev/mtd | strings Feb 27 13:25:10 for u-boot firmware environtment Feb 27 13:43:31 build #627 of bcm47xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm47xx%2Fgeneric/builds/627 Feb 27 14:26:37 since recently pppd writes the routing table, so i was looking for that change upstream and i stumbled upon this: https://github.com/ppp-project/ppp/commit/c3120199a30977a4da12fd031c1df4a95dec417a Feb 27 14:28:33 hmm i guess that even though nodefaultroute6 should be set, nodefaultroute is still unset Feb 27 14:37:12 build #576 of bcm63xx/smp is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm63xx%2Fsmp/builds/576 Feb 27 14:38:20 confusing ... i guess eventhough nodefaultroute6 should be the default, it seems to not be others why set it explicitly in the sample config, and then makes me wonder whether openwrt should add this explicitly to its ppp config file Feb 27 16:21:10 blocktrron: it works Feb 27 16:21:15 (tested) Feb 27 16:24:17 zx2c4: are there any loongson64 targets in openwrt? Feb 27 16:45:50 for IPv6, it'd be better to follow the guidance in the pppd commit. The default should not be to blindingly install an ipv6 default route to the ipv6 interface. It's fine to keep the option in case the user needs it, but it shouldn't be the default. Feb 27 16:46:07 to the ppp interface, I mean Feb 27 16:47:29 the standard according to RFC7084 is for the ISP upstream to send an RA Feb 27 16:50:41 SwedeMike, yes its probably not related to the change in behavior ive been seeing either Feb 27 16:51:04 not sure what changed in the latest pppd release and if that is an issue Feb 27 16:51:33 but yes thing i noticed after updating pppd is that it started to write the routing table Feb 27 17:46:13 build #558 of bcm47xx/legacy is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm47xx%2Flegacy/builds/558 Feb 27 18:06:39 lipnitsk: no. Richard Stallman uses a loongson laptop though! Feb 27 18:11:01 zx2c4: now he can use accelerated WireGuard! Feb 27 18:14:55 zx2c4: done Feb 27 18:15:40 ldir: ping Feb 27 18:17:21 Is anyone working on updating x86_64 to 5.10? Feb 27 18:17:45 Are you running into libelf issues? Feb 27 18:29:59 build #550 of bcm63xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm63xx%2Fgeneric/builds/550 Feb 27 19:41:48 build #852 of ath25/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ath25%2Fgeneric/builds/852 Feb 27 19:41:59 Hi does it matter that the /etc/rc.common has an out of date Copyright line? Feb 27 19:41:59 For OpenWrt not my router. Feb 27 19:45:03 Tapper: no, it should reflect when it was last (significantly) changed, you don't just bump it because Feb 27 19:45:16 OK Feb 27 19:45:49 It was just somthing I spotted and wanted to ask about. Feb 27 21:21:29 guidosarducci: why include/iproute2/ instead of just include/ ? Feb 27 21:25:01 russell--: because that's the standard include path used in the upstream software, and also in packaging that I've seen e.g. Ubuntu 20 LTS. Feb 27 21:27:11 russell--: so I imagine users normally include "iproute2" from CLI includes. Feb 27 21:29:50 plntyk: ok, thanks Feb 27 21:31:51 russell--: I just saw Hauke was asking too.. Feb 27 21:32:15 yeah, i'm following up on Hauke's question Feb 27 21:33:04 the iproute2 makefile uses that path in HDRDIR Feb 27 21:33:22 HDRDIR?=$(PREFIX)/include/iproute2 Feb 27 21:48:28 russell--: right, I saw that too. And since it's in some distro packaging as well (Ubuntu/Alpine/Arch), it should be OK for users to expect it there, no? Feb 27 22:02:04 build #685 of octeon/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/octeon%2Fgeneric/builds/685 Feb 27 22:39:53 guidosarducci: what else uses that header? Feb 27 22:42:03 russell--: what do you mean? it's only for BPF programs loaded with iproute2 (and so compiled with clang). Feb 27 22:42:23 i mean, what other packages rely on it? Feb 27 22:44:09 russell--: no current packages use it, otherwise they'd have been broken before. But any new packages that compiled BPF programs could use it. Feb 27 22:44:55 russell--: since we don't include clang as a prerequisite, those would probably just be local packages. Feb 27 22:45:25 * Below ELF section names and bpf_elf_map structure definition Feb 27 22:45:25 * are not (!) kernel ABI. It's rather a "contract" between the Feb 27 22:45:25 * application and the BPF loader in tc. For compatibility, the Feb 27 22:47:30 explaining all that to the commenters on the pull request will probably expedite merging Feb 27 22:51:43 russell--: well, I'll try... not sure in the current TL;DR society however.. :) Let me re-check the PR to see what happened. Feb 27 22:53:02 russell--: was your concern it may be unneeded, or could be in the wrong place? Feb 27 22:53:33 when people ask questions, they want reassuring, reliable answers where they don't need to exhaustively re-solve the problem Feb 27 22:54:01 the patch made it look like you were moving the include directory, that was my reading (after Hauke asked) Feb 27 22:55:12 i can't speak for him, but i wondered "what else is using whatever headers were installed before and did moving it break them?" Feb 27 22:58:52 russell--: oh, you're talking about the change to $(INSTALL_DIR)? That doesn't move anything, just creates the extra subdir, so I didn't follow you. Feb 27 23:01:27 russell--: I'll clarify that too for clarity, thanks. Feb 27 23:04:35 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_mediatek.html has been updated. (53.8% images and 98.4% packages reproducible in our current test framework.) Feb 27 23:38:09 build #791 of lantiq/ase is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fase/builds/791 Feb 28 00:05:28 guidosarducci: this looked like a move or something like this and there was nothing about this in the commit message Feb 28 00:05:36 it is fine Feb 28 00:05:53 if most distributions do it the same we should aslo use this folder Feb 28 00:10:52 Hauke: ok, great. I added a comment to the iproute2 PR in case as well. Did I answer your bpftools related questions too? Feb 28 01:27:58 Hello. I don't know if this is a right place to ask, but I'm trying to make openwrt work on my router, but it seems to have problems unpacking lzma compressed kernel. Is there a way to make an lzo compressed uImage instead of lzma? Feb 28 01:31:43 Hmmm, looks like we just got a new openwrt/main branch. Huh? Feb 28 01:48:42 guidosarducci: probably dangole pushed to the wrong remote :P Feb 28 01:49:45 lipnitsk: didn't want to finger point but well, since you started... :) Feb 28 01:54:05 guidosarducci: upstream git renamed the default branch to main Feb 28 01:54:24 because master = slavery connotation or something Feb 28 01:54:42 i don't get it Feb 28 01:55:00 I get the master-slave thing, but never thought of git master as inappropriate Feb 28 01:55:28 first time i've heard master-slave is in the context of PATA cables, so there's that :) Feb 28 01:55:43 i2c still has it, well probably others too Feb 28 01:56:11 i assume openwrt will be following suit shortly Feb 28 01:56:24 buildbot too ^_^ Feb 28 01:58:02 buildbot upstream looks to be using "workers" already Feb 28 01:59:06 yeah it seems to be stretch, but probably not worth fighting over. main, master, whatever. people will get used to it Feb 28 01:59:32 mangix: same thing with blacklist and whitelist, next up red-black trees Feb 28 01:59:35 can use "trunk" too, though maybe that's evil because SVN Feb 28 01:59:55 lipnitsk: or ivory poaching? Feb 28 02:00:54 guidosarducci: let me guess. red = native americans... Feb 28 02:00:57 so will the master branch be removed? Feb 28 02:01:41 I don't cair what it's called I just want to know which one to build from? Feb 28 02:02:01 origin/main is not it yet for sure. just use master until you hear something official, IMO Feb 28 02:02:01 there's no official announcement Feb 28 02:02:11 * Tapper nods Feb 28 02:02:13 mangix: master and main aren't the same, so don't see how there was a rename Feb 28 02:04:12 i'm talking about git upstream, not what dango pushed Feb 28 02:04:31 good to clarify that :) **** ENDING LOGGING AT Sun Feb 28 02:59:57 2021