**** BEGIN LOGGING AT Mon Mar 15 03:00:15 2021 Mar 15 05:03:59 i'm seeing this message on a particular network: daemon.notice netifd: wan (1568): udhcpc: bad packet, malformed option field Mar 15 05:04:26 that's coming from an upstream trendnet router to an openwrt router Mar 15 05:05:03 the "malformed option field" that is, the message appears in openwrt's logread output Mar 15 05:05:38 the result is no default gateway from dhcp Mar 15 05:05:51 and possibly no dns server Mar 15 05:09:01 it's the busybox udhcpc Mar 15 05:19:58 option 51 of the dhcp ack is 315360000s (or 3650 days), which seems large. Mar 15 08:47:57 So.. RTL8378RB switch seems to be enabled now on the ER10x :) Now I jiust need to figure out the rest.. https://forum.openwrt.org/t/ubiquiti-edgerouter-10x-er-10x/42980/37 Mar 15 08:49:14 err RTL8367RB Mar 15 08:49:34 Grommish: You did it? :) Mar 15 08:49:48 Dunno yet.. I've never used swconfig Mar 15 08:50:05 But I get an output thru swconfig dev switch0 show Mar 15 08:50:20 Ports don't seem to do anything yet though ;p Mar 15 08:50:33 But I'm guessing swconfig isn't setup properly Mar 15 08:51:10 The Shield has no switch chip, so I never had to deal with it Mar 15 08:52:42 Hmm… no DSA driver for the RTL8367RB yet? Mar 15 08:52:44 hey guys Mar 15 08:52:55 looks like you're making progress bit by bit Grommish :) Mar 15 08:53:20 rsalvaterra: Got me.. No idea about a DSA driver. I asked about if there was one, but Mar 15 08:54:23 Borromini: Trying anyway.. I'm going to throw Luci on it and see if I can figure something out graphically Mar 15 08:55:06 o Mar 15 08:55:08 * ok Mar 15 08:56:09 i tried my hand at an old Atheros SoC and been stuck on that AR8216 switch, if there's no 'sample' DTSes it can be pretty tough Mar 15 08:56:22 The upstream kernel has a DSA driver for the RTL8366RB, I have no idea how much it differs from the RTL8367RB. Mar 15 08:57:15 This top comment is interesting… https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/net/dsa/realtek-smi-core.c Mar 15 08:58:31 aha! acdc8eed89 (Martin Lewis 2020-06-23 15:25:08 -0500 280) /* So far no valid option with length 0 known. */ Mar 15 08:58:37 i found one, lol Mar 15 08:59:46 option 12 (Host Name), length: 0 Mar 15 09:09:59 Ah ha! I have switch connectivity on Port 6 now Mar 15 09:18:02 Grommish: CPU port? Mar 15 09:19:08 rsalvaterra: Yes, the DSA reg actually Mar 15 09:20:09 cool :) Mar 15 09:22:33 At least there's a leaked datasheet for the RTL8367RB, I just searched… :P Mar 15 09:23:18 I saw the Chinese language site, bur I didn't understsand the techinical aspects Mar 15 10:09:14 are patches for "travis" still relevant for packages? Mar 15 10:20:10 hrm, I guess it's still relevant, even though it's not really "travis" any more. Mar 15 10:21:16 Travis could be removed, though. Mar 15 10:21:35 well, this was more a patch file removing -Werror from a build, labeleld "travis fixes" Mar 15 10:21:51 so it's still a useful patch I guess, just misleading name now... Mar 15 10:35:01 Grommish nice going mate Mar 15 10:52:04 ynezz: any projection when the buildbot may ever build again targets which do not start with letter 'a'? Mar 15 11:05:29 dangole: it does right now? Mar 15 11:05:37 https://buildbot.openwrt.org/master/images/#/console Mar 15 11:05:45 bcm* building now Mar 15 11:07:02 I'm debugging it right now Mar 15 11:13:17 jow: seemed to start from letter 'a' each time a new commit has been made. Mar 15 11:14:04 ynezz: no rush, if you are aware of that and there will be a solution at some point that's fine for me Mar 15 11:23:51 make less commits :D Mar 15 11:24:21 I'm having a really strange problem with my LAN interface showing NO_DEVICE Mar 15 11:24:26 https://forum.openwrt.org/t/lan-interface-status-no-device-on-custom-snapshot-build/91257 Mar 15 11:25:21 jow: I was hoping you might be around, if you could offer any suggestions I'd really appreciate it, I do not understand my problem at all :/ Mar 15 11:25:36 something is going wrong during the interface bring up, but what I can't imagine Mar 15 11:25:58 I rebuilt everything with a fresh git clone in a new directory and can recreate the problem Mar 15 11:26:19 what's your /etc/config/network ? Mar 15 11:26:27 stock generated, just a moment Mar 15 11:27:09 rebooting out of failsafe Mar 15 11:27:11 maybe you omitted something crucial, like ip(-tiny), busybox readlink or kernel bridge support Mar 15 11:28:11 provide your ./scripts/diffconfig.sh output as well Mar 15 11:29:09 ok, I've updated the post with the config Mar 15 11:29:17 I've got ip-full built Mar 15 11:29:30 this is probably using ip-tiny though, I got rid of my imagebuilder customisations Mar 15 11:31:02 https://gist.github.com/johnfzc/f66eb6cfeaae39e0e37f644e1d205884 Mar 15 11:31:07 here's the diffconfig Mar 15 11:32:16 ah, interesting, the issue may be broken bridge support Mar 15 11:32:30 root@OpenWrt:/# brctl addbr test Mar 15 11:32:30 brctl: bridge test: No error information Mar 15 11:33:38 though, err, how I achieved that and how I can fix it are not at all clear to me :) Mar 15 11:35:25 jow: it is bridging, I can fix it if I comment out #option type 'bridge' Mar 15 11:35:43 however for other reasons I cannot do this Mar 15 11:35:57 I've got scripts that depend on br-lan being present Mar 15 11:37:51 I could imagine that the lack of IPv6 support is the cause Mar 15 11:38:03 some code somewhere not expecting ipv6 related operations to fail Mar 15 11:38:39 I do have kernel ipv6 support enabled Mar 15 11:38:52 nope Mar 15 11:38:57 # CONFIG_KERNEL_IPV6 is not set Mar 15 11:39:02 line 26 Mar 15 11:39:18 I see that, in make kernel_menuconfig, bridging is set to m Mar 15 11:39:29 hmm, it's enabled in kernel_menuconfig Mar 15 11:39:30 ah Mar 15 11:39:38 then you're probably missing kmod-bridge Mar 15 11:39:42 yes, I used kernel_menuconfig, I am a bad person Mar 15 11:39:43 if that even exists yet Mar 15 11:40:00 afair it was removed a while back since we expect bridge support to be always builtin Mar 15 11:40:03 but I might misremember Mar 15 11:40:26 so either make bridging =y or enable kmod-bridge if it still exists Mar 15 11:40:26 I have: 802.1d Ethernet Bridging Mar 15 11:40:41 (kmod-bridge in menuconfig, not kernel_menuconfig) Mar 15 11:41:03 ah, I think I see the nature of the problem Mar 15 11:41:14 this is built as a module as IPv6 is built as a module Mar 15 11:43:58 jow: I see that kernel_ipv6 exists in the config, but there's no way to access it from menuconfig, is that right? Mar 15 11:44:37 johnf: afaik not, no Mar 15 11:45:13 ok, and if I set it to =y Mar 15 11:45:18 and then run make menuconfig Mar 15 11:45:24 it appears to revert Mar 15 11:47:14 ok, I'm trying to turn ipv6 back on Mar 15 11:47:23 but it greatly increases kernel memory consumption Mar 15 11:47:26 you can use the slash (/) search to track the dependencies Mar 15 11:47:32 and then all my stuff OOMs Mar 15 11:47:51 I used the / search, the dependancies aren't clear, that one appears to have none Mar 15 11:47:56 KERNEL_IPV6 might be a hidden symbol toggled by other symbols Mar 15 11:48:04 this, I think, is possible Mar 15 11:48:22 I do see it referenced in ipv6 mutlicast routing Mar 15 11:48:27 but that setting isn't in the kernel build options Mar 15 11:48:59 where does kernel_menuconfig store it's settings? Mar 15 11:49:41 it actually modified target/linux/$platform/config-xxx Mar 15 11:49:45 see git diff Mar 15 11:50:56 ok, thanks Mar 15 11:51:05 I'm trying to build with IPv6 re-enabled Mar 15 11:51:11 to see what the resulting image looks like Mar 15 11:54:58 I usually state that disabled IPv6 is an unsupported configuration due to issues like that Mar 15 11:55:15 nobody actually tests this, or at least properly maintains the feature dependencies Mar 15 11:57:13 yeah, I understand Mar 15 11:57:36 I just really really need the 2MB Mar 15 12:18:13 interestingly I think it's the damage I did to the kernel config file that's the real problem, even with IPv6 enabled it's still not getting functional bridging Mar 15 12:23:49 I've updated the forum post, thanks very much for your help jow Mar 15 13:25:12 hmm, wireless config reload seems to be unreliable in master Mar 15 13:25:28 I've had several cases now where a manual wifi down/wifi up was required to apply new settings Mar 15 13:25:31 https://github.com/openwrt/openwrt/pull/3991#discussion_r593899951 Mar 15 13:25:32 this also impacts luci Mar 15 13:25:47 how can i fix this Mar 15 13:33:56 jow: any errors in logread? Mar 15 13:34:15 i've seen issues where i outright need to kill the hostapd instance before wireless will come up again Mar 15 13:36:58 jow: is possible to reproduce that state somehow? so i can check what's going wrong Mar 15 13:40:48 dangole: will try. Right now it happened when renaming the SSID of default_radio0 and enabling it via LuCI Mar 15 13:41:13 nothing happened, ubus call network.wireless status kept showing the old state Mar 15 13:41:24 wifi down / wifi up brought the wifi up as expected Mar 15 13:42:46 LuCI relies on config reload triggers behind the scenes, there's no explicit calls to /sbin/wifi or /etc/init.d/network Mar 15 14:05:44 jow: just tried exactly that on mt7622 hardware. enabled wifi in LuCI, comes up with default SSID, change SSID in LuCI to 'OpenWrt1', click apply, SSID changes in air as well as ubus call network.wireless. which hardware/driver are you trying this on? Mar 15 14:06:54 jow: I previously had problems testing changing parameters even just from within hostapd_cli when running on mac80211-hwsim... Mar 15 14:07:14 jow: (hence my question) Mar 15 14:07:26 dangole: tested on a Zbt wg2626 Mar 15 14:07:35 which is mt7621 afair Mar 15 14:07:47 jow: yes, mt7621+mt7612+mt7602, i know that hardware :) Mar 15 14:08:06 on hwsim I don't have issues atm Mar 15 14:08:22 on the zbt, the 5ghz radio was already active and configured since while Mar 15 14:08:45 I tried to enable the 2.4ghz radio to setup a management access Mar 15 14:09:13 this involved changing the sssid, setting a wpa key, creating a new network and assigning it to the lan zone Mar 15 14:09:36 will try to reproduce it later Mar 15 14:10:07 jow: i'll also play with it a bit more, switching modes, changes interfaces, ... Mar 15 14:10:10 my hunch is that this happens when the wireless status "structure" changes, that is new networks and/or radio phys come online Mar 15 14:11:40 jow: that could be indeed, i'll dig a bit there Mar 15 14:19:52 dangole: can't manage to reproduce it using hwsim, will try on the zbt later Mar 15 14:58:50 package makefile pros, what's the right invocation for calling the "default" with params? https://paste.jvnv.net/view/bjqRN Mar 15 14:59:08 I was tryign to call the "normal" install, and just add extra bits, instead of duping it Mar 15 15:43:33 ntp does things every 11 minutes right? Mar 15 15:45:03 every 11 minutes I get this on my master build... https://paste.jvnv.net/view/cvEyK Mar 15 15:51:47 ynezz: i could temporarily chip-in 16 Intel Xeon E312xx (Sandy Bridge) (family: 0x6, model: 0x2a, stepping: 0x1) cores to speed things up a bit. it's a VM in a datacentre in the US, well connected, 16 gigs of RAM. i usually use it for private test-builds and that hardware it's shared with other likeminded people (who i've just asked, and they are fine with offering this for OpenWrt) Mar 15 15:52:26 ynezz: currently runs debian buster, i got root. Mar 15 15:53:48 ynezz: the box got 32 cores and 96gb of ram total, i was just told we could bump my share of ram to a bit more, if needed Mar 15 16:27:21 karlp: does the hotplug.ntp get called properly via ubus? ie. can you do `ubus monitor` and see what's going on at the time you see this message? Mar 15 16:28:59 karlp: because this is probably the stdout/stderr of a script in /etc/hotplug.d/ntp Mar 15 16:35:40 karlp: i've seen this before being caused by /etc/hotplug.d/ntp/25-dnsmasqseq because initscript variable was unset and /lib/functions/procd.sh assumes it to be set. Mar 15 16:35:55 karlp: that's why i set it in commit aed95c4cb8d which fixed it for me Mar 15 16:46:59 hauke: can you try if `fw_setenv rootfs_data_max 0x1000000` has the desired effect on that device? it should limit the size of rootfs_data to 16MiB after the next sysupgrade to have the then free space available for additional user-defined UBI volumes (e.g. permanent logs/stats, container filesystems, ...) Mar 15 16:47:20 hauke: (talking about the WSR-2533DHP2) Mar 15 16:49:21 dangole: yeah, I had gotten as far as looking at all the hot plug scripts, (I have a couple of my own too) but couldn't see anything unexpected/visibly broken Mar 15 16:50:16 and I have the initscript= patch in this build. Mar 15 16:50:35 karlp: and not using unbound or other hooks in /etc/hotplug.d/ntp I assume, right? Mar 15 16:50:41 nope. Mar 15 16:50:59 have some of my own hooks to run services, but I'm running them again by hand and not seeing anything, and they're all disabled now. Mar 15 16:51:24 karlp: do you add anything to /etc/hotplug.d/ntp specificly? Mar 15 16:52:34 yes, but I've already removed them, and none of them call basename anyway. Mar 15 16:53:13 karlp: they may call basename indirectly by sourcing /lib/functions/procd.sh or things like that... Mar 15 16:53:35 karlp: anyway, if you removed them and it's only the dnsmasq script left, it got to be that then Mar 15 16:53:51 they do a . /lib/functions/procd.sh Mar 15 16:54:20 I was calling my scripts manually, envs different I guess. Mar 15 16:54:20 karlp: so in that case you got to set initscript=something just like i did in the dnsmasq script Mar 15 16:54:22 * karlp pokes it. Mar 15 16:56:14 I'm not even using any functions from procd, is shell expanding them all inside functions even if they're not called? Mar 15 16:56:30 I thought shell scripting just ran stuff when it was called? Mar 15 16:56:52 by sourcing /lib/functions/procd.sh that script is executed and it does more than just defining functions (that basename is outside of any function) Mar 15 16:57:13 oh, the bottom line calls it all, awesome, just got to the bottom of the file. Mar 15 16:57:40 it's procd_lock. Mar 15 16:57:54 karlp: maybe we should improve logging for the hotplug handlers, i admit it's not obvious where this is comming from right now (just spitting it to /dev/console) Mar 15 16:58:20 why couldn't procd_lock just use $0 instead of assuming "initscript" is available? Mar 15 16:58:33 we have to source the file anway... Mar 15 16:58:36 because of symlinks to init scripts Mar 15 16:59:35 could use realname of readlink instead, i guess. we should grep for existing users setting initscript= themselves (rather than /etc/rc.common doing that) Mar 15 17:00:28 dangole: ok I will try Mar 15 17:01:40 dangole: in The UGW for GRX500 we also create the overlay partition in UBI only with 32 instead of all the rest Mar 15 17:02:04 this way we have no problem when the kernel or rootfs partition increases in an update Mar 15 17:02:20 32MB Mar 15 17:02:40 Hauke: yes, makes for sense to have it for other things. for the linksys e8450/belkin rt3200 i also implemented it in U-Boot, doesn't matter if you flash through U-Boot or using sysupgrade, rootfs_data_max is always respected Mar 15 17:03:06 Hauke: size changes I solved by just making use of uImage.FIT properly :) Mar 15 17:03:22 ok, one of my scripts had the sourcing of procd functions, it didn't need it, I've just removed it. sorted. thanks dangole! Mar 15 17:03:23 Hauke: but for that U-Boot needs to be quite recent Mar 15 17:03:38 karlp: happy to help Mar 15 17:05:43 Hauke: but I like the result a lot now, kernel+squashfs is nicely structured image which my FIT partition parser can make sense of and map the squashfs partition for rootfs. and in case this running on GPT, there is a magic GUID for FIT which triggers parsing the sub-partitions. in that case (GPT on block device) the remaining space after the FIT image is used for rootfs_data. Mar 15 17:08:07 Hauke: that makes things work very much the same no matter if we are on block storage or UBI. i will also update the mtdsplit/fit.c to actually parse fit structure (rather than just the header) to get the total size, so the resulting mtdblock device holding the FIT can (just like ubiblock) then contain partitions incl. squashfs. needs 4k padding around squashfs, but that's worth it. Mar 15 17:08:21 Grommish: Ping. Still no hangs with my patch? :) Mar 15 17:09:38 dangole: will this also also work with an upstream U-Bot? Mar 15 17:19:18 Hauke: all features needed form U-Boot are already in place in U-Boot 2020.10 and later. what i added was the parser for uImage.FIT in target/linux/generic/files/block/partitions/fit.c as well as image generation and sysupgrade scripts Mar 15 17:19:39 dangole: good Mar 15 17:21:48 Hauke: i hope that this will be the future for all targets using recent U-Boot (ie. sunxi, rockchip, ...) and replace the IBM PC legacy boot imitation with FAT boot partition and all that, while gaining flexibility and robustness (because bootloader can make sure system will actually start, ie. hash of squashfs is checked before starting kernel) Mar 15 17:22:30 Hauke: and i built logic in fstools to handle config-restore from tar.gz written directly to partition, like we do on flash-based targets, so no need to stash config in the boot volume Mar 15 17:23:20 dangole: with the u-boot config option the overlay fs is smaller: overlayfs:/overlay 13.3M 48.0K 12.6M 0% / Mar 15 17:23:40 I am using the vendor u-boot Mar 15 17:24:17 Hauke: all needed for that is persistent U-Boot env. U-Boot itself doesn't need to handle that variable unless you are using U-Boot to flash OpenWrt Mar 15 17:25:06 Hauke: and beautiful to know it just works. you could create more (ubifs) volumes simply using `ubimkvol /dev/ubi0 -N foo -s 16M` Mar 15 17:26:20 Hauke: (and those volumes will survive sysupgrade) Mar 15 17:26:30 nicve Mar 15 17:28:06 Hauke: regarding parsing FIT with external data (ie. offsets stored in the FDT structure rather than the images itself) i guess the vendor loader will fail, being U-Boot 2014 afair... Mar 15 17:28:53 I would like to supprot the vendor u-boot, becasue this maeks it easy for users to install OpenWrt Mar 15 17:29:16 but having a good implementation too is nice so hopefully the vendors will switch at some point in time Mar 15 17:29:34 FIT images are now used by multiple vendors in production Mar 15 17:29:40 Hauke: installation doesn't need to be hard. see https://github.com/dangowrt/linksys-e8450-openwrt-installer Mar 15 17:30:23 you can install openwrt on the buffelo device over the web ui Mar 15 17:30:23 Hauke: I guess vendors will just go with what they find in $chipvendor SDK. and that should be quite up to date in case of MTK afaik. Mar 15 17:30:48 yes, if mtk uses the new U-bot by default many vendors will use that too Mar 15 17:31:31 Hauke: ie. there it's all already included, U-Boot can handle FIT generated using `mkimage -E` which will allow partition parser to work with them and map squashfs (and other nice things, like having localization squashfs as well well, or DT overlay blobs added) Mar 15 17:32:25 Hauke: since they now all support this "external data" FIT it finally starts to make sense. because you can actually parse it without paging around megabytes of image blob... Mar 15 17:34:16 Hauke: i still believe replacing the complete bootchain can be feasible in some cases (like that linksys/belkin device which really got it wrong), and installation can be just as easy, and even reverting back doesn't need to be hard (the installer makes a backup of relevant areas of the flash and writes that into files on a dedicated volume in the newly created UBI partition) Mar 15 17:37:57 ok Mar 15 17:39:43 Hauke: just the build system is not really in shape for that yet. ie. the installer generator now wraps the ImageBuilder to create custom initramfs images (which the IB by itself doesn't support yet). Mar 15 17:41:00 Hauke: I've added the basics, to support generating dedicated initrd image for inclusion in FIT instead of embedding it into the kernel. but all the Makefile jungle to allow doing that also in the IB is still waiting for me. Mar 15 17:49:31 Hauke: patch making U-Boot env writable looks good to me, push it now that buildbot hasn't made it beyond doing apm821xx/nand ;) Mar 15 19:06:34 rsalvaterra: No issues overnight with it, Mar 15 21:16:38 Grommish: Mind if I tentatively add your Tested-by? It would be nice get this patch in. :) Mar 15 21:27:05 Grommish, lipnitsk, let me know what you guys think: https://github.com/rsalvaterra/openwrt/commit/6a97c7e75d2838722d1e03a5973af144e8dc652b Mar 15 22:40:24 rsalvaterra: Added a comment for you Mar 15 22:41:15 rsalvaterra: Oh, it's a different commit.. I'll have to retest Mar 15 23:55:55 Grommish: Yeah, I rebased, sorry about that… I had to add the wall of text too… :) Mar 16 00:28:41 rsalvaterra: looks good to me. thanks for doing more due diligence - hope it gets merged. are you planning to email it or submit a PR soon? Mar 16 00:29:52 lipnitsk: Sure, I'll email it tomorrow. Now I'm off to bed. :) Mar 16 00:30:00 sound good Mar 16 00:53:27 lipnitsk: fewer patches is better Mar 16 00:54:01 I should probably ask upstream to merge the wrt3200acm patch... Mar 16 00:54:16 /s/merge/backport Mar 16 00:54:19 mangix: agreed Mar 16 01:01:57 I am very curious what this patch is about... https://github.com/openwrt/openwrt/blob/master/target/linux/mvebu/patches-5.10/304-revert_i2c_delay.patch Mar 16 01:02:12 Couldn't find much in git history Mar 16 01:12:16 oh hell no Mar 16 01:12:17 https://github.com/openwrt/openwrt/commit/7379f8bd3e7ee0722faa6ec8b2969081fbdc1e07 Mar 16 01:12:29 that kills debian 9 support AFAIK Mar 16 01:23:24 mangix: explain it to me like the idiot I am.. Why would someone want to run an OS that is already EOL and slated for EOL on even the LTS in less than a year? Mar 16 01:24:18 I mean, I get it that sometimes it isn't an option.. I worked for a large Fortune1000 company that used COBOL mainframes and flat files, but only on the backend Mar 16 01:26:08 but doesn't expanding the base of "compatible" build systems lead to other issues of compatability across ALL bases? Mar 16 01:27:21 I'm legit asking because I'm interested in the view.. When I installed Ubuntu, I went with 20.04LTS rather than 18.04, let alone 16.04 which that says is also going to be dropped Mar 16 01:28:47 Grommish: the large company aspect is the issue Mar 16 01:29:04 mangix: Yes, but openwrt isn't being built by large companies, is it? Mar 16 01:29:19 I assume netgear is a large company Mar 16 01:29:50 not that I wish to imply they do, but there are multiple large companies that use OpenWrt as a base Mar 16 01:29:51 From their firmware, I'd say not so much.. nor are they running a current version of OpenWrt Mar 16 01:30:13 They use a base of it, but I don't know of one that uses an official release? Mar 16 01:30:37 Grommish: I mean, there's nothing newer than 19.07 yet Mar 16 01:30:50 seems a lot of the newer SDKs use that Mar 16 01:31:16 *nod* Ok. Well, you'd think they'd update their build system to a supported version Mar 16 01:31:34 I'm not disagreeing or agreeing with either position btw Mar 16 01:31:56 I'm curious as to what line does it not become tenible to try and support everyone Mar 16 01:32:38 even MS gave up on XP eventually :D Mar 16 01:32:45 Grommish: I assume just keep support for everything LTS Mar 16 01:33:19 Fair enough.. Will Deb make a Python3.6 package if it's within their LTS timeline you think? Mar 16 01:33:42 Which they just list as "2022" Mar 16 01:33:46 https://wiki.debian.org/DebianReleases Mar 16 01:39:27 Grommish: nope Mar 16 01:39:44 then that's on them I guess Mar 16 01:40:33 if they can't be bothered, why jump through hoops on compat with it? Mar 16 01:41:02 of course, that just require 3.6, so I guess if they had it locally they'd be fine regardless Mar 16 01:41:11 no? Mar 16 01:41:39 I KNOW there are reasons for everything, I just want to understand it :) Mar 16 01:41:53 You and others don't complain just to complain Mar 16 01:46:42 Grommish: you would think you can build OpenWrt everywhere. Mar 16 01:46:59 Unfortunately, only GNU/Linux is really supported Mar 16 01:47:11 macOS kind of sort of. Mar 16 01:47:19 FreeBSD even less so Mar 16 01:47:22 Cygwin, forget it Mar 16 01:47:53 there's also clang Mar 16 01:48:20 in my branch, I have several build fixes for clang but I haven't sent since they'll just get rejected Mar 16 01:50:17 Meh, I don't like it when people say that.. If you've got it, make them reject it and give you a reason.. If it is't a good reason, then complain Mar 16 01:50:47 But just saying "Not sending it in because they might say no" *shrug* I dunno.. Mar 16 01:50:55 Grommish: been there done that Mar 16 01:50:59 If it works, send it.. make them justify not using it Mar 16 01:51:02 *nod* Gotcha Mar 16 01:51:03 and it's not might Mar 16 01:51:04 it's will Mar 16 01:51:18 Any idea why? Mar 16 01:51:56 Argument is that the bug is HOSTCC/HOSTCXX not being respected Mar 16 01:52:21 both are set to gcc and g++ respectively Mar 16 01:52:48 but even so, a one line patch still gets rejected Mar 16 01:53:48 there was a guy named Tom who no longer contributes that was complaining about his patches being rejected for no good reason Mar 16 01:56:36 He changed the submitter name and patches were applied instantly Mar 16 01:58:13 Grommish: https://github.com/neheb/openwrt/commit/29aa07407ee6e31ab88132d4999ac9b5151d863f and https://github.com/neheb/openwrt/commit/019ffd319b4021ecdc6f1c313da5f140c6f0141d if you're curious Mar 16 01:59:52 Was it done by the same person who rejected it the first time? Mar 16 02:00:18 if so, that's an issue that needs to be addressed Mar 16 02:00:23 in the case of Tom no Mar 16 02:00:37 if not, the question is why was it rejected vs accepted by two separate poeple Mar 16 02:01:25 I'm scanning gpio ports on the er10x and its at gpiochip448:470 and climbing Mar 16 02:01:35 I[m guessing that's not normally Mar 16 02:02:22 Grommish: grepping irclogs shows https://news.ycombinator.com/item?id=22019903 Mar 16 02:02:37 not what I was looking for but close Mar 16 02:04:40 I'd like to have seen the original patch submitted Mar 16 02:04:48 Which guy says was cludgy to begin with Mar 16 02:05:28 12:43 < ynezz> this https://news.ycombinator.com/item?id=22019903 is probably FS#2423 Mar 16 02:06:57 My issue with people who push push push for patches is they have no real idea of the wide-reaching consequences across all devices that get used for. the scope of OpenWrt is beyond a single device or tree (as you are well familar with) Mar 16 02:07:37 But, when I was doing active android rom dev, we told people if they wanted something we didnt offer, they could fork and do what they wanted with our base Mar 16 02:07:51 Very very few wanted to get their hands dirty enough to actually do it Mar 16 02:08:36 OpenWrt is not android. I also do not want to carry out of tree patches for no good reason. Mar 16 02:09:07 Right.. YOU know different :) Your active and respected (by me if no one else ;p) Mar 16 02:09:21 Even if I don't understand or agree with everything Mar 16 02:10:31 Don't get me wrong, I've dealt with my own ego and frustration with patches, but.. eh.. If it bothered me enough, I'd run my own Mar 16 02:10:40 oh perfect. this was flat out rejected: https://github.com/neheb/openwrt/commit/b3807a0022a8cd7e459f94ec5c823f921a185163 Mar 16 02:11:02 That clang patch happens to be an upstream backpprt/ Mar 16 02:11:29 The goal was to silently fix this on version update Mar 16 02:11:35 Do you hev the PR I can look at as to why rejected? Mar 16 02:11:54 I don't do the email list.. I get enough stuff inbound on a daily basis Mar 16 02:11:57 it was on patchwork. let me dig it up Mar 16 02:12:51 strange...no comments Mar 16 02:13:05 Just closed? Mar 16 02:13:15 is it possible they merged it under a different PR? Mar 16 02:13:36 They did that last time I send something in.. Instead of merging it, it was closed and merged under a different PR with my name attache Mar 16 02:13:38 no he explained in an email Mar 16 02:13:42 Ah Mar 16 02:13:51 Which seems.. wrong Mar 16 02:13:59 If there is an issue with a patch, it should be public Mar 16 02:14:07 unless it represents a security issue Mar 16 02:14:58 i don't see it in email Mar 16 02:15:03 must have been on IR Mar 16 02:15:04 C Mar 16 02:15:25 Which shouldn't be anything official Mar 16 02:15:46 I dunno sir.. Just don't give up :) Mar 16 02:16:06 Grommish: the "fix" was http://lists.openwrt.org/pipermail/openwrt-devel/2020-December/032471.html Mar 16 02:16:42 So it was merged? Mar 16 02:16:56 Just with a bunch of hoops to deal with? Mar 16 02:17:01 That one yes. But that pointless math patch remains Mar 16 02:17:48 It fixes a bug in GCC version old as hell. Mar 16 02:17:56 I'd send it.. request an answer as to why it is declined if it is Mar 16 02:18:04 It isn't like you are lacking on documentation Mar 16 02:18:19 I'll do it ;p Mar 16 02:18:55 not that it'll matter since I don't know what it actualky does.. Mar 16 02:19:15 or can test it.. I don't use clang afaik Mar 16 02:19:29 but if you are using it, someone else probably is too Mar 16 02:20:22 If nothing else, I can see about getting you to help me setup a test environment for the outlier cases Mar 16 02:20:37 I use it locally. Building with clang helps with some non-openwrt related stuff Mar 16 02:20:52 I have CC and CXX set to clang(++) Mar 16 02:21:44 I still need to attach numbers to https://github.com/neheb/openwrt/commit/79e2c1b0a7e130d649760027578842f83ee72cf6 Mar 16 02:24:07 Is ld.gold a toolchain specific linker? Mar 16 02:24:23 I don't have ld.gold on any of my toolchains or targets in staging_dir Mar 16 02:24:33 Or is it something tha thas to be enabled first? Mar 16 02:25:31 https://github.com/neheb/openwrt/commit/ab61443eb86c32d93c9d899e6b7274bce1c65319 Mar 16 02:25:33 :) Mar 16 02:25:59 Ooo.. Ok.. I can help quantify if you want Mar 16 02:26:02 speed wise, LLVM linker > GOLD > LD Mar 16 02:26:19 but we don't have LLVM in tree Mar 16 02:26:28 gold is the next best thing Mar 16 02:31:28 Gotcha.. few minutes :) Mar 16 02:32:47 I should probably get rid of https://github.com/neheb/openwrt/commit/3984b7ea495c438a1ec8460520d92f675cf2e650 . rsalvaterra handled this in his kernel 5.10 bump. Mar 16 02:51:49 mangix: In order to test this, I should remove staging_dir and build_dir between builds? Mar 16 02:51:54 or will make clean be enough? Mar 16 02:52:12 make clean should be enough Mar 16 02:52:28 ld.gold speeds up the linking stage, not necessarily compilation Mar 16 02:54:53 Ok.. I'm running it now then Mar 16 02:55:03 I'll have numbers in a few minutes Mar 16 02:56:39 mangix: Errored out Mar 16 02:57:11 mangix: let me make sure it in't omething I did stupid Mar 16 02:58:08 Grommish: these two patches require a toolchain rebuild btw Mar 16 02:58:35 So make clean isn't enough? hehe Mar 16 02:58:52 I'll just shitcan the entire build structure between runs. no biggie Mar 16 02:59:07 but i want to make sure it isn't an issue on something I forget to bring over first Mar 16 02:59:42 Grommish: so you can apply the patches and compile the toolchain. if you want to compare before and after, just undo the changes in the last patch Mar 16 02:59:49 I usuallt remove bin/ build_dir/ staging_dir/ tmp/ Mar 16 03:00:24 the first patch actually builds gold. the second switches OpenWrt to actually use it Mar 16 03:00:37 *nod* Mar 16 03:02:08 I'll remove .ccache as well just for giggles Mar 16 03:02:22 building out now :) Mar 16 03:03:11 (I don't think I use ccache to build with anymore, but eh.. can't hurt) **** ENDING LOGGING AT Tue Mar 16 03:03:12 2021