**** BEGIN LOGGING AT Fri May 14 02:59:56 2021 May 14 04:10:48 Build [#99](https://buildbot.openwrt.org/master/images/#builders/26/builds/99) of `apm821xx/sata` completed successfully. May 14 06:20:08 netprince: thanks, that makes sense. can you send me a dump of your 'factory' mtd partition? May 14 09:09:11 (in case anyone responded, my network dropped due to VPN connection so I didn't see anything come back) May 14 09:59:19 ldir: 5.10.37 released. Bumping. May 14 10:03:48 rsalvaterra: oh exciting! I realised somehow I lost my own .36 bump during some other stuff I was fiddling with - doh! May 14 10:04:27 ldir: I was also wondering why you hadn't pushed it yet. :) May 14 10:04:56 Anyway, please take a look at the .36 pull, it seems sane to me, at least. May 14 10:05:34 I can retrieve from my reflog, but I saw you post something about mac80211 fuzz, so I'm going to start from scratch & re-do it. May 14 10:05:40 Oh I'll take a look May 14 10:07:00 I concur there was a resultant empty patch, I remember that May 14 10:07:49 soo most of my OpenWrt devices are running gcc 10.3 built image, but I ran into an issue with my rpi3a, wifi doesn't associate to my main ssid, it does to my iot ssid May 14 10:08:02 I've seen this before when I tried to enable 802.11w on them I believe May 14 10:08:21 but it was like 4 in the morning so I gave up on debugging May 14 10:08:58 stintel: you need .... https://archive.org/details/apple_ii_library_4am May 14 10:10:07 let's see if I can figure it out soon, because my ads-b feeder is currently offline due to it May 14 10:10:29 I guess this might also explain why it had an image built in february 2020 May 14 10:10:41 and I no longer have it in my backups :P May 14 10:10:45 so I'll have to figure it out May 14 10:12:22 (Hmm I see my first question simply never made it to the IRC) May 14 10:12:23 Long story short. How do you guys go about, finding suitable hardware? May 14 10:12:23 I'm guessing you don't buy stuff which "has support already", but how do you ensure you have a 64/8 device. They seem hard to find in the 802.11n segment. May 14 10:13:28 ldir: Good to know! I'll squash the bumps if the .36 isn't merged before. :) May 14 10:24:26 J-L: depends .. at some point I bought a D-Link DAP-2695 because it was ar71xx (ath79) based so in theory easily supportable. took me 1.5y to get it properly working + committed. if you want something that works better take something that is supported already May 14 10:24:49 J-L: there are some threads about this subject in the forum I believe May 14 10:25:29 I got the DAP-2695 because it's PoE-PD and comes with a console port, so no need to open it up to solder headers etc May 14 10:26:18 if anyone knows of a Mtk-based 11ax device that's PoE-PD and has a console port, and preferably >1Gbps uplink (2.5, 5 or 10), please let know :P May 14 10:28:19 stintel: What kind of MediaTek? MIPS or ARM? May 14 10:28:35 don't care, as long as the wifi is mtk May 14 10:29:00 stintel: I believe the UniFi 6 LR matches your requirements, dangole has been working on it, I think. May 14 10:29:24 it's 1Gbps uplink only and no console port afaik May 14 10:29:46 stintel: dangole told me it's 2.5 GbE, actually. Don't know about the console port. May 14 10:29:51 oh? May 14 10:30:39 last I checked was 1Gbps. https://store.ui.com/products/unifi-6-long-range-access-point says 1Gbps May 14 10:31:12 stintel: Yes, I also double-checked. But I tend to trust an OpenWrt developer more than the vendor… :) May 14 10:31:19 But I'd talk to him, just in case. May 14 10:31:23 anyway I need to fix my rpi3a first May 14 10:31:48 getting FT: invalid key management type (2) but that should not be fatal, afaik May 14 10:34:01 stintel: IIRC, there was an issue with the PHY driver/firmware which is why it's stuck at 1 GbE for the time being. But it's 2.5 GbE capable, for sure. May 14 10:34:12 cool, that's good to know May 14 10:35:57 stintel: However, don't just rush to order one, ask dangole for more details. :P May 14 10:36:17 (I'm planning on getting one myself for my flat, in the next few months.) May 14 10:37:04 well blogic recommended it to me already - problem is availability May 14 10:38:11 but as greearb responded to my ticket yesterday that it's unlikely he'll be able to fix those kind of firmware bugs, I decided it's time to replace my qca-based APs May 14 10:38:31 so I'm looking into proper alternatives again May 14 10:41:35 stintel: QCA is terrible. After my experience with ath10k, to me, Atheros died at ath9k. May 14 10:42:26 rmilecki: I will have time to work on the Meraki MX64/MX65 PR this weekend. Would the best way forward be to move everything to a bcm5862x (or DSA?) subtarget in bcm53xx? May 14 10:42:45 I have a QCA9377 which I never worked. I have a better experience with RTL8821AE(!!). May 14 10:42:56 clayface: what about just bcm53xx generic target? May 14 10:43:32 rsalvaterra: yeah my ath10k were dying all the time, until I tried ath10k-ct, that finally made things stable. unfortunately it's still not 100% May 14 10:43:38 clayface: that would only require a trick to enable DSA for bcm53xx generic target without affecting existing (swconfig ) devices May 14 10:43:56 rsalvaterra: and I remember QCA6174. holy crap May 14 10:44:12 clayface: i think it may be worth a single change to avoid another subtarget if there aren't big kernel differences May 14 10:44:21 I got it to replace intel 7265 iirc, damn what a disappointment May 14 10:47:23 rmilecki: Was thinking it may affect devices with smaller flash. Will try this and let you know if there are any issues. Hopefully it can work. May 14 10:47:47 clayface: i don't think there are any bcm53xx devices with tine flashes May 14 10:54:56 clayface: trx-serial is used for Luxul XAP-1610 (16 MiB) SmartRG SR400ac (32 MiB) & Tenda AC9 (8 MiB) May 14 10:55:13 if that's a too big deal, we can disable AC9 by defualt May 14 10:56:47 rsalvaterra: mind reviewing my busybox patch :)? May 14 11:00:29 aparcar[m]: Already did, looks sane to me. ;) May 14 11:00:39 (I'm not subscribed to the list anymore, though. :P) May 14 11:02:12 rsalvaterra: thanks! May 14 11:02:36 And the Alpine people are also happy with it, it seems. May 14 11:17:37 rmilecki: Just remembered the MX65 needs 5.10. It will work with 5.4 but no VLAN on the QCA switches. May 14 11:18:29 clayface: it's a good time to switch bcm53xx to the 5.10 :) May 14 11:18:48 pffft, now I even lost config during sysupgrade May 14 11:18:49 wtf May 14 11:19:13 rsalvaterra: the gmtime function turns partly out as GMT (built locally) or as UTC (built within buildsystem) May 14 11:19:23 stintel: how? May 14 11:19:47 root@sdrpi3a:~# sysupgrade /tmp/openwrt-bcm27xx-bcm2709-rpi-2-squashfs-sysupgrade.img.gz May 14 11:19:58 came back with default config May 14 11:22:29 wtf I reboot it and again config is gone May 14 11:23:32 failed to mount -t f2fs /dev/loop0 /tmp/overlay: No such file or directory May 14 11:24:35 stintel: the 6 LR has a 2,5 Gbps port apparently. just limited to 1 Gbps. I think I saw blocktrr1 say something about that May 14 11:34:40 ldir: Thanks! I'm going to run-test 5.10.37 before sending the pull request. May 14 11:35:37 rsalvaterra: have applied .36 - if we have the opportunity to split 36 & 37 then I think worth doing just for bisect purposes. May 14 11:35:59 ldir: Can't argue with facts! :) May 14 11:37:09 is .37 plain sailing or are there interruptions more than 'reverse-applied' ? May 14 11:38:54 starts a .37 bump & takes dog for a walk - hopes it runs for a while May 14 11:46:49 ldir: There's a patch to be edited, but it's otherwise smooth. May 14 11:50:59 so it appears it wasn't sysupgrade but my f2fs used for the overlay is bust May 14 11:51:23 it didn't die after sysupgrade, it died after the first reboot after sysupgrade May 14 11:51:30 I believe I've had something like this before, on rpi May 14 11:51:38 guess I'll blame it on SD card? May 14 11:51:49 ldir: https://github.com/openwrt/openwrt/pull/4173 :) May 14 11:54:57 stintel: You'd love this "yoloSSD" I'm using. Six SD cards in RAID-0 in a SATA adapter. :P May 14 11:55:44 wtf :P May 14 11:58:15 stintel: It's where I do my OpenWrt development, at the moment… xD May 14 11:58:19 * rsalvaterra runs May 14 11:59:16 not sure if trolling or serious :P May 14 11:59:42 stintel: Serious, actually. :) May 14 12:00:24 ahh well I'm running production stuff on bcachefs ... guess we're equally crazy :P May 14 12:01:05 stintel: Of course, this SSD isn't the machine's boot drive. Not even my /home. ;) May 14 12:02:12 However, with the right cards (A1), it's surprisingly usable. Certainly better than spinning rust. May 14 12:02:23 A1? May 14 12:03:26 A1, Application Class 1. It enforces a minimum number of IOPS. May 14 12:04:01 1500 IOPS for A1, 4000 IOPS for A2 (I haven't found A2 cards yet). May 14 12:05:09 500 IOPS (A1) and 2000 IOPS (A2) for random writes. May 14 12:09:28 cool May 14 12:16:01 ynezz: do you have a comment for https://gitlab.com/openwrt/docker/-/merge_requests/47 ? disabling meaningless services for docker containers May 14 12:20:16 rsalvaterra: i started hating SD cards after having so many fail wit RPi May 14 12:20:28 aparcar[m]: funny, I'm playing with openwrt/docker today May 14 12:20:43 Build [#92](https://buildbot.openwrt.org/master/images/#builders/64/builds/92) of `realtek/generic` failed. May 14 12:20:45 aparcar[m]: no service is actually started when running a container, right? May 14 12:21:56 rmilecki: Indeed. Note they're not inherently safer in this "SSD". I've had minor data loss, sometimes it immediately remounts ro and I notice because things stop working and I have a look at the dmesg. May 14 12:22:27 But it only happened a couple of times, and I've already been using it for about three months. :) May 14 12:22:59 With fsck and git fsck, I'm not too worried. May 14 12:23:02 3 months and few failures? May 14 12:23:04 no thanks ;) May 14 12:23:26 i really don't know how ppl use RPi with SD cards May 14 12:23:33 rmilecki: I'm crazy, for sure. :) May 14 12:23:40 it was relief to have USB booting support in RPi recently May 14 12:23:43 rsalvaterra: :D May 14 12:24:00 (Not bcachefs-in-production-crazy like stintel, though… :P) May 14 12:24:07 :P May 14 12:24:55 Oh, it's Friday! LineageOS update day… May 14 12:26:31 does anyone know of any issues with Raspberri Pi 3(a) wifi? May 14 12:27:24 AP log shows this: https://gist.github.com/stintel/c34303fa550ed181aa5c1aa10bf41acb May 14 12:27:33 but the PSK is correct, 100% sure of it May 14 12:27:53 stintel: What adapter is that…? May 14 12:28:10 (I only have a 1B, though.) May 14 12:28:12 I vaguely recall having a similar issue when I switched my AP to psk3-mixed May 14 12:28:19 but the AP is psk2 May 14 12:28:41 also my Zero W's all associate fine to the same AP :/ May 14 12:28:53 stintel: psk2 with or without 802.11w? May 14 12:29:11 802.11w is optional May 14 12:29:46 I've tried disabling it in the wpa_supplicant cofnig, I even restored the DRIVER_11W_SUPPORT and disabled it and rebuilt, still the same May 14 12:31:09 goddamnit this is driving me nuts May 14 12:31:40 stintel: What Wi-Fi hardware is it? It's USB, right? May 14 12:32:44 rsalvaterra: no it's attached to the MMC bus May 14 12:32:56 Oh, SDIO? May 14 12:33:21 Hm… I have no experience at all with any of those devices. May 14 12:33:23 great, I disabled 802.11w on the AP and now it connects May 14 12:33:31 so it *is* related to 11w May 14 12:33:38 stintel: See? MFP is usually the culprit… :P May 14 12:34:04 yeah but it makes no sense, it was optional on the AP May 14 12:34:09 and hard disabled in the client May 14 12:34:09 Sure, it's optional… but I believe your RPi is a bit… overconfident. ;) May 14 12:35:15 wtf May 14 12:35:27 if I enable it explicitly in the client it works May 14 12:36:19 oh well good enough May 14 12:38:09 It has a hard time choosing, I see… :P May 14 12:41:34 zorun: sorry I had a call. That's somewhat the question, since OpenWrt without ubus isn't much fun May 14 12:42:05 anyway, talking to dangole_ the idea would be to provide a slim container only and the user have to mount use case specific e.g. a ubus socket, run uhttpd or whatever else May 14 12:42:31 right now you start the docker container and it comes with all the basics, uhttpd, ubusd, dropbear, etc May 14 12:42:38 zorun: what would you do? May 14 12:42:43 does it? May 14 12:43:13 oh I see, I always simply run a container with /bin/sh when I want to test stuff May 14 12:43:22 I think I never tried to start procd May 14 12:43:43 zorun: it does work, but you have to stop /etc/init.d/network since it's in a loop May 14 12:45:28 rsalvaterra: you got commit access? May 14 12:47:29 aparcar[m]: sorry, I don't really have openwrt/docker use-cases besides quick testing May 14 12:48:19 but yeah I just tried and it doesn't work well: https://paste.debian.net/hidden/c4301c4d/ May 14 12:48:22 I don't even get a shell May 14 12:50:42 ldir: are you planning to push that grub patch ? May 14 12:51:53 not quickly no May 14 12:52:09 if it works for you then feel free. May 14 12:52:51 is it me or is snort just hideously obtuse & complicated May 14 12:53:00 I'll poke jow about the autohell hell I encountered May 14 12:55:24 stintel: oh he'll love you for that :-) May 14 12:56:01 and yes you're right we have python3 as a build dep anyway. May 14 12:56:22 jow: grub doesn't build with GCC 10. reported here: https://bugs.openwrt.org/index.php?do=details&task_id=3790 - the fix accepted by upstream causes automake 1.15.0 vs 1.15.1 mismatch. adding PKG_FIXUP:=autoreconf works around that, but then I get some "#if \n" in the generated wchar.h, due to May 14 12:56:22 https://gist.github.com/stintel/f33216a6505bf1debebcc3b4de8349bb#file-logspackagebootgrub2host-compile-txt-L1190 May 14 12:56:39 how can a boot loader have python as a build dep? FFS May 14 12:57:02 jow: so for some reason that GNULIB_OVERRIDES_WINT_T is not set. I've tried a truckload of things already to fix it but no luck May 14 12:57:15 ldir: because the kids forgot how to write shell scripts May 14 12:58:45 stintel: either the upstream tarball shipped some m4 macros which we've blown away with the autpreconf or our m4-macros archive is too old May 14 12:59:34 ... or too new May 14 12:59:36 http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-support/gnutls/libtasn1/0001-stdint.m4-reintroduce-GNULIB_OVERRIDES_WINT_T-check.patch?h=sumo May 14 13:00:39 zorun: sorry another call 😛 uhm so you have to modify the inittab file May 14 13:00:46 jow: I tried replacing the wint_t.m4 file, amongst other things May 14 13:00:58 zorun: https://gitlab.com/openwrt/docker/-/blob/master/rootfs/etc/inittab May 14 13:01:03 the extra line at the end is needed May 14 13:01:37 jow: I'll have a look at that patch May 14 13:01:51 jow: thanks May 14 13:06:09 stintel: thanks for your response I'll have a look at the forum May 14 13:06:10 I guess the first toy project is the tl-wr841n-v14 build to work. I have no urgencies at the moment, I just got lucky with  the tl-wa801n-v5. I tend to prefer having more control over my luck and being prepared for next time. May 14 13:06:18 aparcar[m]: No, not at all! It's something broken in the way patches are being applied. :/ May 14 13:06:54 rsalvaterra: strange... May 14 13:07:01 how was the patch applied? May 14 13:07:28 aparcar[m]: You need to ask ldir about that, I think. :) May 14 13:07:58 ldir: ping? May 14 13:08:00 I think he used the github-apply.sh script. May 14 13:08:09 i see May 14 13:09:02 oh you already came up with yet another... May 14 13:09:37 zorun: so I'd go for the slim container version, that would also allow to become an official container so people can run `docker run -it openwrt` May 14 13:10:04 stintel: there is also https://lists.gnu.org/archive/html/bug-gnulib/2017-01/msg00142.html May 14 13:12:19 stintel: I think staging_dir/hostpkg/share/aclocal/wint_t.m4 is the culprit May 14 13:12:27 which is staged by gettext May 14 13:14:12 autoreconf is too stupid to prever grub2's m4/wint_t.m4 (serial 7) over the system wide one (serial 5) May 14 13:14:16 *prefer May 14 13:17:13 there is a staging_dir/hostpkg/share/aclocal/wint_t.m4 and it seems suspiciously small :) May 14 13:17:21 I've deleted it and am rebuilding again May 14 13:18:40 still failing May 14 13:19:13 and seeing a load of these: configure.ac:493: warning: gt_TYPE_WINT_T is m4_require'd but not m4_defun'd May 14 13:21:05 right, the problematic one ist not the one in staging_dir/hostpkg May 14 13:21:11 but in staging_dir/host May 14 13:21:21 I suppose it is staged by the host gettext May 14 13:21:54 aha, I removed my other changes and now it seems to continue May 14 13:22:20 so you're absolutely right, that staging_dir/hostpkg/share/aclocal/wint_t.m4 May 14 13:22:25 is the culprot May 14 13:22:30 lol May 14 13:22:41 prot = dutch for fart, was that a freudian typo May 14 13:26:17 I guess the easiest fix would be patching host gettext to stage a newer wint_t.m4 May 14 13:29:53 ah and now I have the same problem with non-host build May 14 13:30:52 so I removed staging_dir/target-x86_64_musl/usr/share/aclocal/wint_t.m4 - let's see May 14 13:32:39 worked here at least May 14 13:32:49 looks like it May 14 13:32:57 any any case you'd need to apply something like the OE patch to gettext host and target May 14 13:32:58 what a horrible mess :/ May 14 13:33:18 you misspelled GNU autoconfig May 14 13:33:21 ;) May 14 13:39:34 mehh! May 14 13:39:42 all has been for nothing! May 14 13:39:43 /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/bin/grub-mkimage: error: Decompressor is too big. May 14 13:39:52 so we're not running the python thingy I guess May 14 13:50:13 aparcar[m]: no opinion, I'm not a docker expert May 14 13:55:07 Build [#50](https://buildbot.openwrt.org/openwrt-21.02/images/#builders/8/builds/50) of `mpc85xx/p1020` failed. May 14 14:04:08 yes, parse the commit log in order to gather emails to spam May 14 14:04:24 that'll yield non-hostile responses, clearly May 14 14:06:20 lipnitsk: ping May 14 14:07:15 nbd: yes I can send you that, is email ok? May 14 14:07:32 lipnitsk: Am I safe to assert https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y&id=149e1986ff6ae45ef63ef3eb819cbe2b808fa590 makes ramips/patches-5.10/330-fix-pci-init-mt7620.patch obsolete? May 14 14:19:57 no luck with grub May 14 14:20:04 but at least my adsb feeder is back May 14 14:20:05 https://flightaware.com/adsb/stats/user/stintel#stats-114174 May 14 14:31:15 aparcar[m]: pong May 14 14:31:57 aparcar[m]: github_apply PRnum - is that the wrong thing to do? May 14 14:33:11 ldir: i guess there is something wrong with the commit name, not the author name May 14 14:33:21 It's kinda nice to see who committed something May 14 14:33:34 ????? May 14 14:33:45 I think I've missed part of a conversation May 14 14:34:16 aparcar[m]: I agree, it's important to have both author and commiter. May 14 14:34:42 * ldir is really confused May 14 14:34:48 ldir: Guess what? aparcar[m] asked me if I have commit access. :P May 14 14:35:13 ldir: Because of this: https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commitdiff;h=6a57e1fbfc39a47e8a2dbe243953c7fc5e3fa4dc May 14 14:35:45 It's the thing I told you about, there's something fishy in the way the GitHub script works, since it loses commiter information. May 14 14:36:04 ahhh! May 14 14:39:39 maybe I'm using the script rong - May 14 14:42:06 rsalvaterra: he he he you did the same thing with 330-fix-pci-init-mt7620.patch in the end :-) May 14 14:43:10 ldir: Yeah, the upstream fix was a bit different and quilt isn't smart enough to undestand semantics… :) May 14 14:45:51 so I've used github-apply 4173 and then hit ctrl-c to NOT close the PR. How can I check the committer details May 14 14:47:50 ah git log --pretty=full does enough May 14 14:48:24 and that shows rui as author & committer - hmm. May 14 14:51:18 ldir: trying yet another approach for grub / gcc10: https://gist.github.com/stintel/70bb3819f4c44d74ea32eebe5d330455 May 14 14:51:58 * ldir dares not look - suspects it involves goat sacrifice May 14 14:52:15 actually no, it's rather lazy :D May 14 14:52:58 * ldir ROFL - brilliant May 14 14:55:10 rsalvaterra: ok, I know what's going on, not how to fix. May 14 14:56:06 rsalvaterra: it looks like github-apply simply grabs the commit from github, which of course has you as the author and the committer - you wrote it and committed it, it's correct. May 14 14:57:20 it grabs the commit and places it on the head of my master branch. if I push at that point it goes into upstream/master as you. May 14 14:58:07 what I now do is github-apply to a staging branch, and then cherry-pick the commit into my master push branch. the cherry-pick is inherently a commit re-write operation, so you authored, but I committed. May 14 14:58:20 * ldir appends 'i think' to all the above May 14 14:58:32 =) May 14 14:58:42 why imagine that, it might just work May 14 14:59:06 stintel: except nothing boots ;-) May 14 14:59:17 I will test it in a local test VM first ;) May 14 14:59:27 chicken! May 14 14:59:33 ldir: but I'm sure it works, Gentoo does it the same :) May 14 14:59:56 and this idea came after starting daydrinking May 14 15:00:00 maybe I should do that more often 😂 May 14 15:00:01 it's a very simple solution and I like it May 14 15:00:53 if it works for me I'll push it to my staging tree and link to that in the bug report May 14 15:01:21 and if I can get some {ack,test}ed-by I'll just push it May 14 15:01:30 rsalvaterra: correct, that patch is now obsolete May 14 15:02:50 stintel: and I can check if it still builds under macos May 14 15:02:57 good idea May 14 15:04:15 * ldir wonders if there's a way to nuke bob from huixiasupply.com May 14 15:04:36 :D May 14 15:05:40 * ldir preferably from orbit as I want to be sure May 14 15:08:32 stintel: someone has done it for You https://github.com/openwrt/openwrt/pull/4047 May 14 15:10:02 you got to be kidding May 14 15:12:15 the motive was different although May 14 15:14:01 ldir: tmn505: https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=commit;h=3bc522aab6734451ec8ccd6b63533e038acdd8f1 May 14 15:14:09 would that be acceptable to attribute him like that ? May 14 15:15:31 lipnitsk: Great, thanks! May 14 15:16:27 ldir: I see, makes sense. :) May 14 15:16:35 I asked him in the PR May 14 15:16:56 stintel: I would say add his SoB, but others may have different opinion May 14 15:17:26 SoB should only ever be added after requesting explictly May 14 15:17:28 and ad in [] what You changed May 14 15:17:52 I didn't change anything, my work isn't based on his work, I just did exactly the same May 14 15:18:15 also a bit of a bummer that this was done via PR May 14 15:18:24 if that had been sent to the ML I'd have known about it May 14 15:18:30 and I wouldn't have wasted half a day May 14 15:18:35 stintel: good idea - if it were me I'd put something a little stronger credit wise 'turns out at least 3 of us were working on the same problem but from different directions, see the PR'. but what do I know May 14 15:19:17 stintel: I've taken his PR commit and am building under macos May 14 15:19:41 that's alway my issue when i stumble uppon a problem, first check ML and if I remember check GH May 14 15:20:02 we should really find a solution for that May 14 15:20:13 stintel: well, if you done sth on your own, just put your S-o-B there and you're good May 14 15:20:13 right now there is ML, FS, GH, GL, ... May 14 15:21:22 stintel: LOL! https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=commitdiff;h=3bc522aab6734451ec8ccd6b63533e038acdd8f1 May 14 15:21:42 "Let's just avoid the whole debacle by bumping the version." :D May 14 15:23:21 And I completely missed you had already linked it above. :) May 14 15:34:59 rmilecki: yeah I know, just a bit silly that this guy's PR was sitting there for a month and nobody knew about it May 14 15:36:06 i know, i agree, we may sorry that guy, we don't have manpower to review all incoming changes :( May 14 15:36:24 if only all contributions would be centralized May 14 15:37:10 but the old guard doesn't like github, the new kids can't figure out git send-email and work with web-based mailboxes like gmail that are imho absolutely antiproductive .. May 14 15:37:52 weren't we going to move to gitlab and translate PRs to the ML or translate patches sent to the ML to PRs? May 14 15:39:41 plyntk hangs around here usually, you can ping him when he's online May 14 15:47:41 ldir: rsalvaterra: did you run into https://gist.github.com/f76ab216daa41dd295e773c242fb4f73 ? May 14 15:49:02 stintel: Not specifically, but that certainly looks like something doesn't support being built with MIPS16. May 14 15:49:20 stintel: not yet May 14 15:50:14 I'm actually doing a make clean to build a new image, let's see what happens… May 14 15:50:30 That's BusyBox, right? May 14 15:55:08 yeah May 14 15:55:22 but I suspect it's because I have CONFIG_PKG_ASLR_PIE_ALL=y May 14 15:56:06 rsalvaterra: ldir: since you're both building with GCC 10 already, iirc, kindly test https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=commit;h=923a52e5a5c9d853c8773879554c2e4905f821d4 ? May 14 15:57:07 stintel: That's weird, I've never hit those errors… :/ May 14 15:57:16 I reliably do :D May 14 15:58:47 ahh drama May 14 15:58:51 https://news.ycombinator.com/item?id=27153338 May 14 15:59:18 jow: nbd: quick question - could we have "config device " and drop "option name " ? i see two advantages: May 14 15:59:21 1. it would not allow duplicated names May 14 15:59:22 2. referencing devices from "config interface" would be more natural May 14 16:00:00 stintel: I grabbed your commit last night and built without problem - curiously I've never hit the umdns issue either. May 14 16:06:32 rmilecki: uci section names have restrictions on what characters are allowed May 14 16:09:40 nbd: right, thanks May 14 16:10:15 ah yes, the babeld uci integration used to do this (interface name in section name), but we had to drop it May 14 16:14:34 ah right I need to build mvebu first, otherwise my commit message contains a lie :D May 14 16:20:31 stintel: grub2 builds under macos - I've rebased on your latest master tree, and done a 'dirclean' - when I arrive at work I'll set a build going May 14 16:21:43 stintel: No build issues at all, here… :/ May 14 16:22:40 was there some CI setup already that can build from our staging trees? May 14 16:23:16 or is there another place I can push my staging tree, so that it will be tested automatically ? May 14 16:24:18 * ldir ^^^ would also like that May 14 16:34:35 Habbie: thanks for those dnsdist improvements btw - I kept wondering why the heck ruby was being built but never spent time on figuring out the reason May 14 17:27:54 netprince: do you have time to test a patch? May 14 17:28:53 nbd: I am not near the AP now, but I may be able to run a quick test in a few hours May 14 17:29:15 nbd: I have remote access if you need anything from it May 14 17:29:34 i may have a fix for the issue May 14 17:29:58 sounds good to me, let me know what to do and I'll try it later today May 14 17:31:26 http://nbd.name/mt76-precal.patch May 14 17:31:41 just apply that on the latest mt76 master in the build dir May 14 17:32:02 ok will do May 14 17:32:45 thanks May 14 17:42:55 nbd: thanks you May 14 17:43:05 thank you I mean May 14 17:44:13 netprince: which issue were you seeing? May 14 17:45:07 The wifi appears to drop most packets, just a fraction of them get through May 14 17:45:19 ok and you were on master? May 14 17:45:26 stintel, hah, good to hear. you're welcome :) May 14 17:45:49 on my phone (android) it throughput is just really poor, but on my laptop (windows and intel wifi) wifi connects but does not work May 14 17:46:22 Borromini, yeah May 14 17:47:07 Borromini, https://pastebin.com/pdm7CxWh May 14 17:53:02 netprince: ok, thanks. i have seen frequent timeouts, first i thought it were my Realtek switches (they run OpenWrt too) May 14 17:53:43 I've been watching the realtek switch support, really interesting May 14 17:53:56 but things seem to have noticeably improved since i bumped to e5b19336c58e170ca3c55a96f8de018961b2fc2f (mt76 2021-04-29) May 14 17:54:42 the issue that netprince is facing only affects a subset of devices with mt7915 May 14 17:54:44 yes, very much so. i own a ZyXEL GS1900-10HP, it powers a Netgear GS108T v3 and my EAP235-Walls May 14 17:54:52 nbd: oh, nevermind me then. May 14 17:54:57 it's specific to devices that have pre-calibration data stored in flash May 14 17:55:05 i don't have a such a device myself May 14 21:37:00 I've mentioned that everytime I upgrade thousands of routers with sysupgrade -n remotely I loose about 1% because they do not call back home saying they've successfully upgraded. So what I did next was to reflash my own router in a loop until it stopped calling home. What I figured out was that when the router boots after the sysupgrade, the wifi and internet does work but it is always in a "bad state" showing lots of squashfs errors May 14 21:37:00 in dmesg. At one point crontab wasnt running (crucial for me) and another time everytime I ran a script that we use (php) I got I/O error. Rebooting the router when its in this 'bad state' fixes it. May 14 21:37:51 uh oh, my apu2 hasn't come back after the grub2 bump May 14 21:38:13 So now I'm thinking of trying to have some kind of monitor that would reboot the router if there is a squashfs error. But there must be something else that's causing the underlying issue? May 14 21:46:55 barhom: something like logread -f | grep -q squashfserror && echo b > /proc/sysrq-trigger ? May 14 21:47:52 barhom: I wonder if you tried the same test but without sysupgrade, just rebooting it few thousand times? May 14 21:48:25 barhom: do you have 4mb devices? May 14 21:48:47 barhom: what I meant, do you have lowmem devices (32mb?)? May 14 21:50:00 But reboot fixes it... May 14 21:51:04 oh wait. it's not a flash problem, it's a memory problem? I've the problem that sometimes sysupgrade fails to write the firmware to the flash. May 14 22:20:26 nbd: I dont have much time to test your patch, but a quick test shows uploads work great, downloads are working now but only getting 50mbit when I should get about 350mbit. I can test it more on monday... thanks May 14 23:32:08 Is it intented that the openwrt 21.02-rc1 images are not really signed? They contain a cert with this comment: "# fake certificate" **** ENDING LOGGING AT Sat May 15 02:59:58 2021