**** BEGIN LOGGING AT Fri Nov 13 02:59:57 2020
Nov 13 04:29:28 <FirstTime_NoTime> I got feedback to use DT trigger instead of set_wifi_led "$boardname:white:wifi"
Nov 13 04:29:41 <FirstTime_NoTime> What is that one referring to?
Nov 13 05:38:22 <rr123> checked out master this morning worked well, just did a git pull and on my tp-link c7 eth0.2 is gone
Nov 13 05:49:24 <FirstTime_NoTime> @rr123: Looking at the log there doesn't seem to be anything that should have affected it, judging by the descriptions... could have been an effect of flashing the firmware a second time?
Nov 13 05:51:28 <rr123> yes reflashed it, power cycle it, I could not do : ip link set eth0.2 up, also, dmesg|grep eth0 only showed eth0.1
Nov 13 05:51:54 <rr123> i normally do two builds of master, one in the morning one at night, this is the first non-working build I had for weeks
Nov 13 05:52:29 <rr123> i'm 'make distclean' and rebuild the whole thing now
Nov 13 05:53:07 <rr123> Cannot find device "eth0.2"
Nov 13 05:54:45 <FirstTime_NoTime> "generic: platform/mikrotik: implement multi caldata" <- that should not have any impact on eth0.2
Nov 13 05:56:09 <FirstTime_NoTime> But looking at the datasheet, that should all be the same driver
Nov 13 05:56:15 <FirstTime_NoTime> (*module)
Nov 13 05:57:36 <PaulFertser> FirstTime_NoTime: DT trigger means that you can configure wifi led in the DTS of the board
Nov 13 05:58:26 <PaulFertser> rr123: check your switch config, eth0.2 would be vlan2 on eth0.
Nov 13 06:00:02 <rr123> PaulFertser: don't understand, how to check switch-config
Nov 13 06:04:16 <FirstTime_NoTime> PaulFertser: Would you know if I can drop aliases
Nov 13 06:05:49 <FirstTime_NoTime> I can see that other DTS files still have that section for the LEDs. I will keep it for now
Nov 13 06:06:22 <FirstTime_NoTime> @rr123: You should be able to check it in LUCI (web interface)
Nov 13 06:06:49 <FirstTime_NoTime> rr123: Should be system -> switch and should give you a drop down menu
Nov 13 06:08:50 <FirstTime_NoTime> Oh, I have another (stupid) question.. if my device has 2 separate Ethernet chips (same model though). Should they come up as eth0 and eth1 or eth0.1 and eth0.2?
Nov 13 06:10:41 <olmari> Usually eth0 and eth1
Nov 13 06:11:50 <olmari> "major" number points to actual device, be it yot
Nov 13 06:12:13 <FirstTime_NoTime> Got disconnected
Nov 13 06:12:59 <olmari> "major" number points to actual device, be it your traditional NIC or "switch device" like oftentimes in OpenWrt scope
Nov 13 06:13:36 <olmari> So eth0 and eth1
Nov 13 06:14:06 <FirstTime_NoTime> That's what I expected.. the stock FW uses eth0.1 and eth0.2
Nov 13 06:14:29 <olmari> Obviously at driver level there could be any form of "mapping" anyhow
Nov 13 06:14:36 <FirstTime_NoTime> I thought it was an openWRT convention
Nov 13 06:15:26 <olmari> well I don't know how would one then use any VLANs with that, so sounds weird
Nov 13 06:16:52 <FirstTime_NoTime> It did confuse me
Nov 13 06:16:54 <FirstTime_NoTime> ralink_soc_eth 10100000.ethernet: connected port 4 to PHY at mdio-bus:04
Nov 13 06:16:59 <FirstTime_NoTime> ralink_soc_eth 10100000.ethernet: connected port 5 to PHY at mdio-bus:05
Nov 13 06:17:17 <FirstTime_NoTime> Maybe I don't understand the way the whole thing is wired up internally
Nov 13 06:17:23 <olmari> I also know some of switch devices has 2 "cpu ports", having the opposite possible and single device being capable offering eth0 and eth1 (and VLANS to them)
Nov 13 06:17:45 <FirstTime_NoTime> It definitely has two RTL8211F (from memory) chips on it.
Nov 13 06:17:53 <FirstTime_NoTime> One at the back offering PoE and one at the front
Nov 13 06:18:05 <olmari> you sure there are 2 actual NICs or "just" physical tranceivers etc?
Nov 13 06:18:49 <FirstTime_NoTime> Probably the later
Nov 13 06:19:04 <FirstTime_NoTime> So the distinction escapes me
Nov 13 06:19:16 <FirstTime_NoTime> ralink_soc_eth 10100000.ethernet: connected port 4 to PHY at mdio-bus:04 [uid=001cc916, driver=Generic PHY]
Nov 13 06:19:21 <FirstTime_NoTime> ralink_soc_eth 10100000.ethernet: connected port 5 to PHY at mdio-bus:05 [uid=001cc916, driver=Generic PHY]
Nov 13 06:19:26 <FirstTime_NoTime> They share the same uid
Nov 13 06:20:28 <FirstTime_NoTime> I have got to go... seems like I will have to look into this some more
Nov 13 06:20:38 <FirstTime_NoTime> thank you
Nov 13 06:35:43 <aparcar[m]> rsalvaterra1: yea we'd need the -z I guess
Nov 13 06:50:41 <PaulFertser> rr123: switch config is in /etc/config/network , as usual. Board description file is /etc/board.json.
Nov 13 06:51:19 <aparcar[m]> there is something wired with https://firmware-selector.openwrt.org/ and https://firmware-selector.staging.openwrt.org/. The latter works fine, however even if I manually copy files from staging to production, production loads the wrong files
Nov 13 06:51:37 <aparcar[m]> ynezz: can you please see the nginx/apache configs?
Nov 13 07:08:21 <ynezz> aparcar[m]: you can deploy 95% of the production site from CI, the collect.py is decoupled and needs to be reviewed and updated via ansible
Nov 13 07:08:44 <aparcar[m]> oh fun
Nov 13 07:08:51 <aparcar[m]> could you please do that? I have no ansible access
Nov 13 07:09:30 <ynezz> well, if it needs to run as cronjob on the infra server, I see no other option
Nov 13 07:11:40 <ynezz> if this script is going to be changed often, then we should probably rethink this part
Nov 13 07:12:17 <ynezz> like run scheduled CI job hourly and rsync just the updated JSONs
Nov 13 07:13:43 <mangix> ynezz: what's the motivation here? https://patchwork.ozlabs.org/project/openwrt/patch/20191112200129.19396-1-ynezz@true.cz/
Nov 13 07:14:04 <ynezz> mangix: it's in commit description
Nov 13 07:14:16 <ynezz> and I plan to push it once we branch 21.yy
Nov 13 07:14:28 <mangix> people still build on CentOS 7
Nov 13 07:14:40 <aparcar[m]> ynezz: I'd be fine with a hourly scheduled CI job. that seems secure enough
Nov 13 07:14:45 <ynezz> mangix: yeah, they can update gcc
Nov 13 07:14:54 <mangix> Hmm?
Nov 13 07:15:03 <mangix> CentOS 7 uses GCC 4.8.2
Nov 13 07:15:05 <aparcar[m]> how will people with this new apple m1 chip compile openwrt...
Nov 13 07:15:25 <mangix> aparcar[m]: oh compiling on an ARM host actually works
Nov 13 07:15:38 <ynezz> mangix: that is default, it has package manager, you can update to something newer
Nov 13 07:16:19 <aparcar[m]> ynezz: can you please remove the collect.py script corn job and I build a hourly CI?
Nov 13 07:16:58 <mangix> weird. last i looked there was no newer GCC available
Nov 13 07:17:39 <mangix> maybe needs some 3rd party repo
Nov 13 07:18:20 <mangix> mostly my question is what does killing support for GCC 4 and 5 bring?
Nov 13 07:28:04 <ynezz> mangix: less issues
Nov 13 07:28:40 <ynezz> there was a thread about it in v1
Nov 13 07:29:08 <mangix> Besides some host packages that need C++-14, CentOS 7 can build all packages with GCC 4.8.2
Nov 13 07:29:15 <mangix> sorry, C++17
Nov 13 07:29:33 <mangix> although that's also a problem with GCC 6...
Nov 13 07:30:57 <ynezz> the main issue is CI/QA, if you want to support such older compilers, you need to test the changes on those compilers as well
Nov 13 07:31:54 <ynezz> otherwise you risk bug reports from people using such old compilers
Nov 13 07:32:05 <ynezz> buildbots wont catch those either
Nov 13 07:32:54 <mangix> The host GCC is only used to compile the toolchain and host packages. Why would the host GCC be relevant when a newer toolchain GCC is used?
Nov 13 07:36:15 <ynezz> it's still quite big set of packages
Nov 13 07:37:09 <ynezz> if we don't test against such old compiler, why to support it officially?
Nov 13 07:38:17 <ynezz> if you're going to triage that bug/patch/PR, you're likely going to spin up that affected distro in Docker and verify it
Nov 13 07:41:11 <mangix> I'm asking as I compile all packages in my CentOS 7 VM to see if anything broke. Everything that breaks specifically with CentOS 7 is a host package failure
Nov 13 07:41:33 <mangix> any other failure breaks everywhere else
Nov 13 07:48:58 <aparcar[m]> ynezz: firmware selector does seem to work now, did you do anything?
Nov 13 07:49:51 <ynezz> aparcar[m]: I've deployed the new collect.py and changed the commandline in the cron job
Nov 13 07:49:58 <ynezz> didn't verified it yet
Nov 13 07:50:18 <ynezz> that ansible part was done hour ago
Nov 13 07:50:43 <ynezz> mangix: https://github.com/openwrt/openwrt/commit/4ba8f7b1ef1e4c0607185a41c06b51928c625d8b
Nov 13 07:52:21 <ynezz> mangix: https://patchwork.ozlabs.org/project/openwrt/patch/20191112081625.27695-1-ynezz@true.cz/
Nov 13 07:52:34 <aparcar[m]> ynezz: ok thanks
Nov 13 08:20:27 <mangix> that is just strange...
Nov 13 08:21:09 <mangix> {} and memset 0 should be equivalent
Nov 13 08:22:37 <mangix> Although the former is a GCC extension and not standard C.
Nov 13 08:30:34 <rsalvaterra> 'morning!
Nov 13 08:31:31 <rsalvaterra> aparcar[m]: Alright, I'll send it as a follow-up, or include it in a v2 if changes are needed.
Nov 13 08:32:19 <Grommish> Morning rsalvaterra
Nov 13 08:33:10 <rsalvaterra> (I swear, my ISP gateway must be running a cron job to reboot it every day at 4:30 in the morning.)
Nov 13 08:34:16 <aparcar[m]> rsalvaterra: they do have that kind of cronjob usually
Nov 13 08:34:20 <SwedeMike> I know ISPs who bounce the PPPoE session at the same time every day
Nov 13 08:34:57 <SwedeMike> ... and thus forcing IP address change
Nov 13 08:35:56 <rsalvaterra> SwedeMike: Yeah, but I have a (Euro)DOCSIS connection, so it's bridged.
Nov 13 08:51:45 <rsalvaterra> rr123: Master is broken. The netifd changes need to be reverted.
Nov 13 08:51:56 <rsalvaterra> I already wrote this yesterday…
Nov 13 08:53:18 <rsalvaterra> Either reverted or fixed. But I'm sure they weren't thoroughly tested, at least on switchdev and/or one-armed routers.
Nov 13 08:56:23 <Grommish> How do I call defined functions to build?  I've got a define Host/InstallBinaries but if I do make -j1 V=sc package/feeds/packages/rust/host/installbinaries it tells me it valid
Nov 13 08:56:38 <Grommish> err tells me its not valid
Nov 13 08:59:19 <rsalvaterra> So, would someone with commit access please revert a0be58576cfc25f93f10aabf45908f6056d9f848 for the time being…?
Nov 13 10:38:27 <BUguser> please fix it *** Failed to download the package list from https://downloads.openwrt.org/snapshots/targets/ramips/mt7621/kmods/5.4.75-1-878d1c290479417154653dd2ca7e6dbd/Packages.gz
Nov 13 10:38:49 <BUguser> no kmods for 5.4.75
Nov 13 10:40:28 <nbd> rsalvaterra: sorry, i missed what you wrote on irc. i'll get started on fixing the issue as soon as i get your /etc/config/network
Nov 13 10:42:58 <rsalvaterra> nbd: No worries, sorry for nagging, but this one is a biggie. :) Full config sent.
Nov 13 10:49:47 <f00b4r0> mangix: iirc it's '{ 0 }', and not just empty brackets
Nov 13 11:11:28 <nbd> rsalvaterra: i can reproduce the issue. will attempt to bisect now
Nov 13 11:14:26 <rsalvaterra> Thanks!
Nov 13 11:32:28 <nbd> successfully bisected it, but need to figure out why it fails
Nov 13 11:32:30 <nbd> this is a weird one
Nov 13 11:37:26 <nbd> i think i figured it out
Nov 13 11:37:33 <nbd> will have a fix soon with a bit of luck
Nov 13 11:43:10 <nbd> rsalvaterra: seems that the commits that i made are fine, they just uncovered a pre-existing bug that has been there for a long time
Nov 13 11:43:46 <rsalvaterra> Oh, wow.
Nov 13 11:44:14 <rsalvaterra> That's the kind of commit we like. :)
Nov 13 11:47:12 <f00b4r0> rsalvaterra: would the issue you're talking about have anything to do with this https://github.com/openwrt/openwrt/pull/3037#issuecomment-726710846 ?
Nov 13 11:48:11 <nbd> pushed a fix to netifd.git, will update netifd in openwrt next
Nov 13 11:49:48 <nbd> rsalvaterra: done. should work now
Nov 13 11:49:59 <rsalvaterra> f00b4r0: I don't think so, because VLAN 1 came up, just not VLAN 2. It was weird, indeed.
Nov 13 11:50:22 <nbd> the problem was this:
Nov 13 11:50:59 <nbd> one of my commits moved some checks to a later point in time for vlan devices by setting dev->config_pending = true
Nov 13 11:51:38 <nbd> when dev->config_pending is set, the core calls device_check_state later
Nov 13 11:51:45 <rsalvaterra> nbd: Let me guess: commit 3a2b21001c3c93dbe8502a8df465e415f18a84b1?
Nov 13 11:52:10 <nbd> no, that's just dummy code
Nov 13 11:52:45 <rsalvaterra> Ah, well.
Nov 13 11:52:47 <nbd> the commit that triggered the bug was a3016c4512487a9673d13a4b09ba05e774df1e73
Nov 13 11:53:51 <nbd> the real bug was the fact that system_if_check checks device present state for all device types
Nov 13 11:53:57 <rsalvaterra> I see now.
Nov 13 11:54:25 <nbd> so the vlan code would set present=true, but before it would be brought up, system_if_check would set it to false again because it couldn't find the linux netdevice with that name
Nov 13 11:54:37 <nbd> before the vlan commit, the order was the other way around
Nov 13 11:55:00 <nbd> that's why it worked before
Nov 13 11:56:30 <rsalvaterra> Alright, I'm going to take it for a spin here, thanks a lot for the quick turnaround, nbd!
Nov 13 11:57:06 <nbd> sure, thanks for reporting it
Nov 13 13:17:47 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_mediatek.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)
Nov 13 13:50:36 <rsalvaterra> nbd: Lunch time here, just tested a new build and it's perfect.
Nov 13 13:51:47 <nbd> great
Nov 13 13:52:12 <jow> nbd: is that fix applying to macvlan devices as well?
Nov 13 13:52:35 <jow> didn't have time to look into your fix yet but seen a macvlan regression report today related to the netifd bump
Nov 13 13:53:15 <mrkiko> Hello all!!
Nov 13 13:54:12 <nbd> jow: no idea how my changes would have broken macvlan (based on a quick look, i'd expect it to have been broken before as well)
Nov 13 13:54:29 <nbd> jow: but my change might fix it as well
Nov 13 13:54:56 <mrkiko> gch981213969: hello! I am trying to figure out the mips boot process, for curiosity and maybe do some writings, who knows. I was using R6220 as reference. Of course I am faced with the MT7621 stage1 code, which seems closed and proprietary. Why do some devices use it and some not? And - I replaced the bootloader with breed on some of my r6220s, so probably my CPU isn't executing this code anymore.
Nov 13 13:55:02 <mrkiko> why does all work well ?
Nov 13 13:55:59 <mrkiko> gch981213969: i.e.: I guess my GnuBee PC1 doesn't use that code?
Nov 13 13:57:45 <mrkiko> gch981213969: then, I am faced with mt7621_stage_L2.bin as well :)
Nov 13 14:00:33 <mrkiko> gch981213969: or, better - as I understand it, calibration code is still present in the U-boot git repo, but can't determine for sure if it's used or not
Nov 13 14:38:56 <rr123> the netifd fix brought eth0.2 back, cool.
Nov 13 15:04:16 <mrkiko> gch981213969: ok, sorry, even GB-PC1 uses it. For breed, don't know - the binary appears somewhat compressed
Nov 13 15:49:40 <adrianschmutzler> hi, is there a policy where to put a backported kernel patch on DTS files that touches more than one target?
Nov 13 15:49:47 <adrianschmutzler> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.8&id=8b99dc0922618062a1589ebd74df6108b4f9ac22
Nov 13 15:50:10 <adrianschmutzler> We currently have that one twice in ipq40xx and ipq806x (cut down to the relevant file)
Nov 13 15:50:40 <adrianschmutzler> Personally, I'd put that in generic/backport, but it appears to there are no DTS patches residing there so far
Nov 13 15:51:07 <adrianschmutzler> which made me wonder whether that's discouraged
Nov 13 16:27:51 <ReDaLeRt> Hello.
Nov 13 16:27:59 <ReDaLeRt> I'm getting errors on opkg update:
Nov 13 16:28:26 <ReDaLeRt> *** Failed to download the package list from https://downloads.openwrt.org/snapshots/targets/ipq806x/generic/kmods/5.4.75-1-9b987752517786d6b21d331f275da699/Packages.gzon snapshot r14927-c4600e6261
Nov 13 16:28:35 <ReDaLeRt> This file is not available, giving 404 error.
Nov 13 16:29:32 <ReDaLeRt> The last 3 snapshots all give errors about this this kernel repository. :S
Nov 13 16:30:10 <ReDaLeRt> Since the November 9th, it's difficult to get a fully functional router.
Nov 13 16:30:18 <ReDaLeRt> How can I solve this, please? :)
Nov 13 16:46:02 <jow> you can't, apart from building your own image
Nov 13 16:46:19 <jow> the kmod repo should return sometime within the next 48 hours
Nov 13 16:55:17 <rsalvaterra> I wonder if mklibs is actually doing *something*… I just did two builds (with/without) and the image size is exactly the same.
Nov 13 16:55:33 <rsalvaterra> I remember it made quite a difference in 19.07…
Nov 13 17:05:40 <ReDaLeRt> jow, I'm compiling it, straight from the github repo. Let's see.
Nov 13 17:06:22 <ReDaLeRt> It's a painstaking process, almost 60 minutes, with parallel processing :S
Nov 13 17:44:10 <ReDaLeRt> jow, no luck, even compiling the github directly, r14927-c4600e6261
Nov 13 17:44:29 <ReDaLeRt> jesus, almost 6 days with bin files non fully working. :/
Nov 13 18:06:06 <aparcar[m]> jow: what was the kmod issue, why weren't they built?
Nov 13 18:25:37 <jow> logic flaw
Nov 13 18:47:59 <aparcar[m]> jow: did you read https://forum.openwrt.org/t/buildbot-kmods-not-uploaded-opkg-download-failed-to-download/79041/6?u=aparcar ?
Nov 13 18:50:17 <aparcar[m]> tl;dc remove "kmod_feed adding" entirely from buildbot and add kmod feeds via openwrt.git release independent
Nov 13 19:49:47 <adrianschmutzler> has the netifd vlan problem been fixed in the meantime?
Nov 13 19:56:41 <Grommish_> adrianschmutzler: nbd and rsalvaterra were talking about it ealier I believe
Nov 13 19:57:08 <adrianschmutzler> I just want to provide a tree in staging for testing ...
Nov 13 19:57:20 <adrianschmutzler> Maybe I just revert the commits to be sure for now ...
Nov 13 20:21:50 <f00b4r0> adrianschmutzler: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c4600e62611ad91ead03b378192605b135593460
Nov 13 20:28:24 <adrianschmutzler> f00b4r0: so that's actually a fix for the earlier issue?
Nov 13 20:28:40 <f00b4r0> AIUI yes
Nov 13 20:31:28 <nbd> yes, it fixes the issue
Nov 13 20:31:46 <adrianschmutzler> perfect, thanks.
Nov 13 20:31:50 <nbd> the vlan commits were fine, except for the fact that they exposed an old bug
Nov 13 20:31:53 <nbd> that is fixed with the above commit
Nov 13 21:13:38 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)
Nov 13 23:09:41 <aparcar[m]> adrianschmutzler: thanks for the email
Nov 13 23:10:03 <aparcar[m]> actually dangole sneaked david and me as developers ;)
Nov 13 23:26:22 <mangix> f00b4r0: { 0 } is standard C. {} is a GNU extension. {} is part of C++
Nov 13 23:27:24 <f00b4r0> mangix: I see. Noted. Looks like bad coding style to me anyway :^)
Nov 13 23:28:11 <mangix> although I assume { 0 } would have the same issue with GCC 4.8.5
Nov 13 23:29:26 <f00b4r0> likely. ISTR it's a "recent" introduction to the standard (C11 maybe?)
Nov 13 23:29:52 <mangix> { 0 } is C99 I believe
Nov 13 23:30:09 <mangix> clang warns on {} saying it's a GNU extension
Nov 13 23:30:39 <mangix> in any case, { 0 } is bad syntax and {} is buggy on old GCC
Nov 13 23:50:33 <rsalvaterra> adrianschmutzler: Yeah, it's fixed. Old bug exposed by the new changes.
Nov 14 00:53:44 <Grommish> rsalvaterra: https://github.com/openwrt/packages/pull/13916  <- Now the real work starts
Nov 14 00:58:04 <mangix> config RUST_USE_LIBCXX caught my attention
Nov 14 00:59:39 <mangix> include $(INCLUDE_DIR)/download.mk what the...
Nov 14 01:00:55 <Grommish> Drink it all in deep haha
Nov 14 01:01:31 <Grommish> Though I can drop the download.mk since I ju7st moved gen_sha256sum over
Nov 14 01:02:50 <Grommish> It works BTW. I just can't get it to bail on the rest of the Makefile if the binary archive is present and correct
Nov 14 01:03:47 <Grommish> if it's not there, it builds.. it its there but corrupt, it builds.. if its there, it installs from the binary archive, but then rebuilds everything
Nov 14 01:03:54 <Grommish> which kinda defeats the purpiose
Nov 14 01:04:12 <Grommish> hell, it even uninstalls itself if you call host/clean ;p
Nov 14 01:04:48 <mangix> I'm somewhat annoyed that this language stuff has to be in packages, but w/e
Nov 14 01:05:00 <Grommish> It's a host only package
Nov 14 01:05:03 <Grommish> so gimme a better way to do it
Nov 14 01:05:22 <Grommish> There isn't a single thing in this package that goes into the final image or on the device at the point
Nov 14 01:05:26 <mangix> that was a generic comment, not specific to rust
Nov 14 01:05:30 <Grommish> *nod* I know
Nov 14 01:05:43 <Grommish> but it still stands :) I am not committed to any of this
Nov 14 01:05:48 <Grommish> other than it mostly works
Nov 14 01:06:19 <mangix> I'm going to assume jeffreyto and the turris people have something to say
Nov 14 01:07:01 <Grommish> Oh, it's certaintly going to be meat to the wolves
Nov 14 01:07:23 <Grommish> We both know it's amazing I get anything to work correct ;p
Nov 14 01:07:39 <Grommish> and it certainly isn't done correctly or with style.. but.. *shrug* They can fix that
**** ENDING LOGGING AT Sat Nov 14 02:59:56 2020