**** BEGIN LOGGING AT Tue Nov 17 02:59:56 2020
Nov 17 03:33:53 <FirstTime_NoTime> I have spent days to work out why I cannot control that single LED this board has. It uses the builtin 2.4 Wifi and another 5ghz chip - MediaTek MT76x2E 802.11nac/MediaTek MT7620 802.11bgn. And it seems that the driver for  MT76x2E  is creating an LED entry, but the  MT7620  driver is not
Nov 17 03:34:14 <FirstTime_NoTime> Both seem to use the same code (mt76_led) for that task
Nov 17 03:38:43 <Tusker> heya guys, I have a single node ceph cluster which I use to do my openwrt builds locally, but I find the performance a bit on the slow side, given that I have ssd cache in front of the spinning drives etc, the rm -rf *linux* often takes ages to complete, so was wondering what the general opinion on filesystems for a openwrt build server ?
Nov 17 03:39:20 <mangix> rr123: in what way?
Nov 17 03:48:35 <Tusker> would bcachefs be a good option for it ?
Nov 17 04:11:35 <m4t> Tusker: maybe 'eatmydata' could help queue up all the small fs operations
Nov 17 04:11:53 <m4t> helps with apt on sd cards anyways
Nov 17 04:12:28 <m4t> ime small io size + network filesystems don't go well together
Nov 17 04:12:56 <Tusker> ok, will have a look at it.  what underlying filesystem is best ? RAID5 + btrfs + eatmydata ?
Nov 17 04:13:30 <m4t> Tusker: or try mounting the cephs with 'nowsync'
Nov 17 04:14:00 <m4t> supposedly that helps with unlink https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.7-Ceph-Performance
Nov 17 04:14:30 <Tusker> ah ok, maybe I don't have to rebuild my whole server if that's the case :)
Nov 17 04:14:32 <m4t> i use btrfs on nvme and don't run into issues. ext4 would be fine too.
Nov 17 04:18:29 <Tusker> actually, I will rebuild anyway... just for fun
Nov 17 04:31:54 <Tusker> the cpu usage of the ceph deamons go very high... nowsync won't likely help with the CPU issue
Nov 17 04:33:33 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_ar71xx.html has been updated. (99.1% images and 100.0% packages reproducible in our current test framework.)
Nov 17 05:22:33 <enyc> jow: overloaded by genuine use, or some sort of problem-bots/junk/etc?
Nov 17 05:23:26 <enyc> jow: At what point shuold openwrt move to wide distributed mirrors in similar style to linux distros I wonder!
Nov 17 06:30:14 <owrt-snap-builds> build #675 of ath79/nand is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Fnand/builds/675  blamelist: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Paul Fertser <fercerpav@gmail.com>, Adrian Schmutzler <freifunk@adrianschmutzler.de>
Nov 17 06:32:35 <owrt-snap-builds> build #419 of bcm27xx/bcm2710 is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/master/images/builders/bcm27xx%2Fbcm2710/builds/419  blamelist: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Nov 17 07:32:10 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_ath79.html has been updated. (99.1% images and 100.0% packages reproducible in our current test framework.)
Nov 17 08:36:00 <rsalvaterra> mangix: One thing that worries me about GCC 10.x is the inliner aggressiveness… -finline-functions is now enabled at -O{s,2,3}, and it makes the code noticeably larger (I can't fathom why they enabled it at -Os, doesn't make any sense). I don't know if the speed benefits outweigh the bloat, but this should be *thoroughly* tested before we bump GCC to 10.x, in order to decide whether or not we disable -finline-functions.
Nov 17 08:39:56 <mangix> i assume that will happen after the release
Nov 17 08:42:22 <rsalvaterra> mangix: You mean the testing, right? :)
Nov 17 08:43:00 <Borromini> somebody talking release? \o/
Nov 17 08:44:06 <mangix> I assume there will be done kind of release based on kernel 5.4
Nov 17 08:44:25 <rsalvaterra> Borromini: I'm talking about GCC 10.x being more (code) cache-hostile. :P
Nov 17 08:44:38 <mangix> rsalvaterra: I'm talking about switching to GCC10
Nov 17 08:44:49 <mangix> keep in mind that every GCC release increases compiled size
Nov 17 08:45:15 <Borromini> rsalvaterra: oh :P :(
Nov 17 08:45:42 <rsalvaterra> mangix: Yes, but this time the increase is more significant, from my experience.
Nov 17 08:46:13 <pkgadd> keep in mind, 'embedded' := as smartphone these days...
Nov 17 08:47:10 <rsalvaterra> pkgadd: My smartphone has *three* times more RAM than my laptop. I'm not sure I agree.
Nov 17 08:47:46 <pkgadd> hehe, well...
Nov 17 08:48:24 <mangix> my smartphone has three times more RAM than my NAS
Nov 17 08:48:56 <mangix> which is funny given that NAS typically uses a lot of RAM
Nov 17 08:48:56 <rsalvaterra> Sure, my laptop has 2 GiB of RAM, but it gets sh*t done. :P
Nov 17 08:49:12 <Borromini> and all your smartphone does is phone home :P
Nov 17 08:50:28 <Tapper> Borromini Is that not what phones are fore? /s
Nov 17 08:51:28 <Borromini> :P
Nov 17 08:51:56 <Tapper> My wife calls her phone her facebook. lol
Nov 17 08:52:11 <rsalvaterra> Borromini: Yeah… the price of convenience… :(
Nov 17 08:53:20 <Tapper> When I asked here about she said that is all the dam thing seems to do.
Nov 17 08:53:29 <Tapper> her*
Nov 17 08:54:36 <mangix> apple device i'm guessing
Nov 17 09:16:38 <Borromini> rsalvaterra: that's how they get us all :)
Nov 17 09:20:33 <rsalvaterra> I swear, every time I see someone suggesting echo 1 > drop_caches I just want to scream.
Nov 17 09:22:44 <karlp> in what context?
Nov 17 09:22:50 <rsalvaterra> Are you debugging the page cache? No? Then why the f**k are you messing with it?
Nov 17 09:23:42 <rsalvaterra> karlp: https://forum.openwrt.org/t/trunk-flush-used-memory/79475
Nov 17 09:27:42 <karlp> right, yeah, that's just garbage :)
Nov 17 09:27:55 <karlp> this is the whole "ram's being used! I don't want it to be used!" confusion
Nov 17 09:28:36 <Borromini> that's the real redmond legacy
Nov 17 09:29:12 <Borromini> until they fessed up and turned around, of course. 'oh no we'll start using that ram as well, don't mind us, we've been pointing fingers at unices all along, but hey, nevermind, all good!'
Nov 17 09:29:26 <Namidairo> im trying to think whether or not dropbear would tell the kernel to start ejecting stuff if I were to scp over a new image on those 4/32 devices
Nov 17 09:30:26 <rsalvaterra> People don't seem to understand kernels smartened up since KRNL386.EXE…
Nov 17 09:32:07 <karlp> smartened, aka, someone somewhere else decided it knew how to do things better and less predictably ;)
Nov 17 09:32:19 <rsalvaterra> Namidairo: On a 4/32 device you want to bring down non-essential services before flashing a new image, to make room for it.
Nov 17 09:33:40 <Borromini> karlp: the regular industry definition of 'smart' ;)
Nov 17 09:38:06 <rsalvaterra> And speaking of memory management, would someone please review/merge my procd patches, so we can end the "mount /tmp on zram" silliness once and for all…? :/
Nov 17 09:48:37 <nitroshift> rsalvaterra, o/
Nov 17 09:58:48 <rsalvaterra> nitroshift: o/
Nov 17 10:12:14 <mangix> rsalvaterra: there qas such a bug with mt7621
Nov 17 10:12:36 <mangix> i lost quite a bit od data that way...
Nov 17 10:13:50 <mangix> cache coherency bug that is
Nov 17 10:23:33 <rsalvaterra> mangix: Cache coherency bug? On MT7621?
Nov 17 10:45:24 <mangix> yeah. it's fixed now
Nov 17 10:46:15 <rsalvaterra> Good to know, since I got myself four Redmi AC2100 devices (one for me, three for friends of mine). :P
Nov 17 10:49:19 <rsalvaterra> I installed OpenWrt on one of them yesterday… the procedure described in the wiki is nuts, completely unnecessary with the 2.0.23 firmware version.
Nov 17 10:50:57 <rsalvaterra> They're even nice enough to include curl, so you can just directly download the OpenWrt images from the router itself. :P
Nov 17 10:54:54 <mangix> full thread if you're bored https://github.com/gnubee-git/GnuBee_Docs/issues/78
Nov 17 10:57:04 <Namidairo> I'm sorry.
Nov 17 10:57:20 <Namidairo> :P
Nov 17 10:58:50 <mangix> huh?
Nov 17 11:00:03 <Namidairo> rsalvaterra: are you saying 2.0.23 has one of those nice command injection bugs in the web interface
Nov 17 11:00:14 <rsalvaterra> Namidairo: Yes! ;)
Nov 17 11:01:10 <rsalvaterra> Namidairo: https://www.youtube.com/watch?v=d3km5n-d4io
Nov 17 11:02:10 <Namidairo> I did what I did when only the release firmware was around so meh
Nov 17 11:02:38 <rsalvaterra> And even that video is overly complicated, you don't need a local HTTP server to upload the images, you can just curl them down from the OpenWrt repository.
Nov 17 11:03:41 <Namidairo> just in case one didn't have a working internet connection for whatever reason
Nov 17 11:04:19 <rsalvaterra> Namidairo: In that case, you can use SCP or SSH directly. No HTTP server needed, again.
Nov 17 11:05:07 <rsalvaterra> mangix: Wonderful explanation. It's long fixed, fortunately.
Nov 17 11:05:53 <Namidairo> well feel free to write up a new process
Nov 17 11:06:13 <Namidairo> since you'll probably be flashing 4 of them soon :P
Nov 17 11:06:31 <rsalvaterra> One down, three to go. ;)
Nov 17 11:08:07 <rsalvaterra> Namidairo: I had a look inside the OEM firmware to see the firewall configuration and running services… it's terrifying.
Nov 17 11:08:13 <Namidairo> it was a janky process to begin with
Nov 17 11:11:17 <rsalvaterra> The damn thing boots up with completely open wifi, to which you can connect and do the basic configuration procedure. You're basically racing against your evil neighbour.
Nov 17 11:12:37 <Namidairo> that was part of the reason i didn't want to have mine hooked up to my network during setup
Nov 17 11:13:23 <Namidairo> did you see the lua as well
Nov 17 11:13:43 <Namidairo> all nice and scrambled
Nov 17 11:14:30 <rsalvaterra> I didn't look at the Lua scripts. I just looked at /etc/config/firewall and felt sorry for whoever bought this to use as-is (was?)…
Nov 17 11:15:36 <rsalvaterra> (And I'm sure it's been a lot of people, judging from how fast they were sold on AliExpress…)
Nov 17 11:16:14 <Namidairo> in fairness I think many of those sales may have happened after I published the poc
Nov 17 11:16:58 <rsalvaterra> Namidairo: I truly hope so!
Nov 17 11:25:35 <Hauke> any objections to tag and start the build of 18.06.9 today in the evning? In the release notes we should then decare it end of life and make this the final release.
Nov 17 11:25:45 <Hauke> *evening
Nov 17 11:26:19 <jow> fine with me
Nov 17 11:35:27 <ynezz> nice, so we're going to maintain one stable release from now on?
Nov 17 11:39:49 <jow> that is until 20.x comes out
Nov 17 11:39:53 <jow> or 21.x
Nov 17 11:40:27 <jow> 19.x will not receive heavy maintenance after that, but I'd prefer to keep it "open" for eventual security fixes
Nov 17 12:04:03 <rsalvaterra> Hmm… Is it safe to ignore this? Looks ominous enough…
Nov 17 12:04:03 <rsalvaterra> [    0.631956] nand: WARNING: mt7621-nand: the ECC used on your system is too weak compared to the one required by the NAND chip
Nov 17 12:06:33 <Namidairo> I don't have that
Nov 17 12:07:00 <rsalvaterra> Namidairo: Really? This is yesterday's snapshot.
Nov 17 12:07:19 <Namidairo> I haven't put a new snapshot on for a few weeks
Nov 17 12:09:19 <Namidairo> you also might have different nand chip to mine
Nov 17 12:09:49 <Namidairo> I think a few of the later units were shipping with toshiba (?)
Nov 17 12:10:11 <Namidairo> [    0.596975] nand: ESMT PSU1GA30DT
Nov 17 12:12:12 <rsalvaterra> Let me see…
Nov 17 12:13:02 <rsalvaterra> Quite…!
Nov 17 12:13:02 <rsalvaterra> [    0.613259] nand: Toshiba NAND 128MiB 3,3V 8-bit
Nov 17 13:04:53 <owrt-snap-builds> build #676 of ath79/nand is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Fnand/builds/676
Nov 17 14:01:14 <owrt-snap-builds> build #420 of bcm27xx/bcm2710 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/bcm27xx%2Fbcm2710/builds/420
Nov 17 17:41:08 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_lantiq.html has been updated. (98.2% images and 100.0% packages reproducible in our current test framework.)
Nov 17 18:39:35 <ReDaLeRt> Hello, guys! :)
Nov 17 18:41:50 <ReDaLeRt> the opkg package is getting me mad. Over almost 15 straight days, I can't get a minimally stable and usable snapshot bin, on my EA7500 v1!
Nov 17 18:41:55 <ReDaLeRt> Collected errors: * opkg_download: Failed to download https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/luci/Packages.gz, wget returned 4. * opkg_download: Check your network settings and connectivity.
Nov 17 18:42:16 <ReDaLeRt> Every single day I have errors regarding failures on the openwrt website. :/
Nov 17 18:43:08 <ReDaLeRt> This time, even luci is uncapable of being installed properly at all.
Nov 17 18:43:25 <Borromini> there's been buildbot issues and related repo issues.
Nov 17 18:44:02 <ReDaLeRt> Are them solved?
Nov 17 18:45:33 <Borromini> no idea. maybe someone else knows.
Nov 17 19:50:24 <Tapper> ReDaLeRt you need to fix your dns
Nov 17 19:50:58 <Tapper> returned 4. * opkg_download: Check your network settings and connectivity. is DNS
Nov 17 19:51:13 <aparcar[m]> rsalvaterra: ping
Nov 17 19:52:21 <aparcar[m]> the download server moved recently and there might be some dead DNS ends
Nov 17 19:57:19 <rsalvaterra> aparcar[m]: pong
Nov 17 19:57:32 <aparcar[m]> mind testing an imagebuilder for me?
Nov 17 19:57:56 <rsalvaterra> I think so. Where is it?
Nov 17 19:58:17 <aparcar[m]> https://github.com/aparcar/openwrt/actions/runs/367107739
Nov 17 19:58:34 <aparcar[m]> download the ath79-generic-selinux-supplementary artifact
Nov 17 19:58:38 <aparcar[m]> inside is the imagebuilder
Nov 17 19:58:49 <aparcar[m]> oh actually not the selinux one but the nls one please
Nov 17 19:58:59 <aparcar[m]> the selinux uses a different kernel hash
Nov 17 19:59:10 <aparcar[m]> but the nls one should be able to download the kmods from openwrt.org
Nov 17 19:59:22 <aparcar[m]> all using signatures
Nov 17 19:59:57 <rsalvaterra> ath79-generic-nls-supplementary downloading.
Nov 17 20:01:54 <rsalvaterra> I'm on macOS at the moment. Does the image builder work here? (Never tried.)
Nov 17 20:02:11 <aparcar[m]> no clue
Nov 17 20:03:01 <rsalvaterra> No problem, I'll SFTP to the Debian machine.
Nov 17 20:03:30 <aparcar[m]> thank you
Nov 17 20:06:47 <rsalvaterra> Extracting.
Nov 17 20:07:18 <rsalvaterra> Shall I make a specific image, or any will suffice?
Nov 17 20:08:05 <Grommish> I need to restrict a package to x86_64 arches only. Does this cover all of them?  DEPENDS:=@((x86_64)||(USE_GLIBC&&(i386)))
Nov 17 20:08:30 <Grommish> or is there an i686?
Nov 17 20:09:39 <aparcar[m]> rsalvaterra: anything is fine. It's mostly about the key generation
Nov 17 20:10:25 <rsalvaterra> Built fine. No unusual output.
Nov 17 20:15:13 <rsalvaterra> Now I have a question… When we make kernel_oldconfig CONFIG_TARGET=subtarget and a bunch of config symbols are removed, doesn't it mean the configuration should be refreshed (as the symbols are already part of the generic config)?
Nov 17 20:19:50 <aparcar[m]> I'm not a kernel refresh person sorry
Nov 17 20:20:08 <aparcar[m]> there are like two usual suspects that do all the kernel bumps, maybe ping them?
Nov 17 20:22:36 <rsalvaterra> I will, but not just yet, I still need to dig a bit more. :)
Nov 17 20:27:50 <ldir> hostnames with '-' in them are legal right? e.g. 'big-server'
Nov 17 20:29:24 <rsalvaterra> Good question. Intuitively, I'd say yes, but I don't know for sure.
Nov 17 20:29:51 <svanheule[m]> I use hostnames with dashes, and that works :-)
Nov 17 20:30:05 <rsalvaterra> Wait! IDN uses hyphens.
Nov 17 20:31:31 <ldir> ipset add Vid4  "big-server" timeout 0  results ipset v7.6: Syntax error: cannot parse big: resolving to IPv4 address failed
Nov 17 20:34:08 <rsalvaterra> WAT
Nov 17 20:34:51 <rsalvaterra> You can't put hostnames in ipsets.
Nov 17 20:35:24 <svanheule[m]> rsalvaterra: but ipset does appear to resolve them for you
Nov 17 20:35:52 <svanheule[m]> ldir: I get the same error on my machine, it appears ipset is splitting the hostname at the dash
Nov 17 20:35:54 <rsalvaterra> That's very strange… dnsmasq has a facility to fill ipsets at DNS resolution time.
Nov 17 20:36:03 <ldir> indeed ipset will try to resolv hostnames to an address.
Nov 17 20:36:08 <rsalvaterra> That's what I use for those situations.
Nov 17 20:36:33 <rsalvaterra> I was positive you couldn't put hostnames in ipsets, but I'd love to be wrong.
Nov 17 20:36:40 <ldir> I'm trying to force an entry into a set, as a permanent entry hence the timeout 0
Nov 17 20:37:24 <ldir> you can't put hostnames in, you can put addresses in - ipset 'helpfully' resolves names to addresses... except it appears to have problems with '-' characters in the hostname.
Nov 17 20:37:57 <stintel>        If host names or service names with dash in the name are used instead of IP addresses or service numbers, then the host name or service name must be enclosed in square brackets. Example:
Nov 17 20:38:00 <stintel>               ipset add foo [test-hostname],[ftp-data]
Nov 17 20:38:06 <stintel> man ipset # noobs ;)
Nov 17 20:38:32 <rsalvaterra> stintel: \o/
Nov 17 20:38:38 <ldir> stintel: thanks - I did look at the man page, not closely enough
Nov 17 20:39:38 <stintel> welcome
Nov 17 20:39:44 <rsalvaterra> I still believe the dnsmasq solution is more elegant, especially if you're dealing with CDNs.
Nov 17 20:41:03 <ldir> yes, but I want to add a couple of 'fixed' entries in at 'boot time' with a zero (permanent) timeout
Nov 17 20:41:21 <rsalvaterra> Fair enough. :)
Nov 17 20:41:27 <ldir> The set is added to dynamically by the dnsmasq ipset mechanism
Nov 17 20:41:47 <rsalvaterra> ldir: Well, since you're here, and you're also a kernel guy…
Nov 17 20:41:54 <ldir> I have some entries that must stick!
Nov 17 20:42:01 <rsalvaterra> … did you see my question? :P
Nov 17 20:43:00 <ldir> rsalvaterra: I saw the question, I'm not a kernel guy by any stretch of the imagination and no I have no idea
Nov 17 20:43:11 <rsalvaterra> Oh, and about the hyphens, I had totally forgot https://cm-sintra.pt/  *facepalm*.
Nov 17 20:43:55 <rsalvaterra> ldir: I see you do kernel updated from time to time, that's why I asked. :P
Nov 17 20:44:40 <ldir> there's a magic script that does the bumps, but when it comes to symbols...I put my head in the sand & hope
Nov 17 20:45:21 <ldir> I have never understood the kernel symbols & subtarget thing.  Sorry
Nov 17 20:46:29 <rsalvaterra> ldir: That much I understand. :)
Nov 17 22:52:51 <xback> Hauke: Just noticed this one:  https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=2a8279c161efeb243084d78d8077661c9122bb18
Nov 17 22:53:02 <xback> Hauke: Thanks for the fixup.  Apologies for the mistake :(
Nov 17 22:55:13 <Hauke> xback: no problem, I did an update of the kernel earlier but did not really test and pushed it
Nov 17 22:55:18 <Hauke> saw this in the comparision
Nov 17 22:56:35 <rsalvaterra> Hauke, xback, could one of you please tell me if my reasoning is correct, about the kernel symbols?
Nov 17 22:58:02 <rsalvaterra> This is what I asked: when we make kernel_oldconfig CONFIG_TARGET=subtarget and a bunch of config symbols are removed, doesn't it mean the configuration should be refreshed (as the symbols are already part of the generic config)?
Nov 17 23:16:11 <Hauke> rsalvaterra: yes
Nov 17 23:16:54 <rsalvaterra> Thanks, I thought so.
Nov 17 23:17:19 <rsalvaterra> I just noticed this on ramips/mt7621.
Nov 18 00:34:52 <aparcar[m]> adrianschmutzler: what is the policy for changing dts compatible strings? some devices are called 8dev while they're really 8devices. I'd unify that, thoughts?
Nov 18 01:04:15 <adrianschmutzler> aparcar[m]: https://openwrt.org/docs/guide-developer/device-support-policies#modeldevice_name
Nov 18 01:05:12 <adrianschmutzler> Note the link to the kernel list there. I unify stuff like that occasionally, but in some cases it might create more confusion than use.
**** ENDING LOGGING AT Wed Nov 18 03:02:03 2020