**** BEGIN LOGGING AT Thu Sep 05 03:00:58 2019 Sep 05 05:38:58 _lore_: ouch Sep 05 05:39:07 _lore_: patch is welcome :-D Sep 05 06:02:14 blogic: can you please have a look at my latest procd patch? Sep 05 06:02:22 <_lore_> blogic: ack...anyway it still complains about malformed calibration data Sep 05 06:32:23 Hauke: ath9k and ath10k. Chip of my phone is probably Atheros. Who knows. OpenWrt was a snapshot build at the time. Sep 05 06:33:04 Hauke: iOS 13 announced WPA3 support. I'm still on 12. It'll probably work with 13 Sep 05 06:34:09 mamarley: Busybox ash falls in between dash and bash. But no. Arrays are not supported. Sep 05 06:34:59 bah I meant rmilecki Sep 05 06:35:01 exit Sep 05 06:35:06 quit Sep 05 06:35:23 ;) Sep 05 07:02:53 rmilecki: could you have a look at this? https://patchwork.ozlabs.org/patch/1152044/ I remember you approved the othre Generic patch Sep 05 07:12:52 Anyone have a moment to help me resolve an error that's flooding my logs? Sep 05 07:15:04 device: Netgear r7500v1 Sep 05 07:16:07 error found in dmesg / logread:: cpu cpu1: _set_opp_voltage: failed to set voltage (995000 995000 995000 mV): -22 Sep 05 07:23:34 Hundreds of these messages. Occurring every 5-10 seconds. How can I tell the kernel to stop trying to change the voltage? Sep 05 07:37:36 When building the log is showing some Sep 05 07:37:36 *Kconfig error: recursive dependency detected!*, e.g. Sep 05 07:37:36 "tmp/.config-package.in:96187: symbol PACKAGE_nfs-kernel-server depends on NFS_KERNEL_SERVER_V4 Sep 05 07:37:36 For a resolution refer to Documentation/kbuild/kconfig-language.txt Sep 05 07:37:36 subsection "Kconfig recursive dependency limitations" Sep 05 07:37:36 feeds/packages/net/nfs-kernel-server/Config.in:4: symbol NFS_KERNEL_SERVER_V4 depends on PACKAGE_nfs-kernel-server Sep 05 07:37:36 tmp/.config-package.in:13691:error: recursive dependency detected! Sep 05 07:37:37 For a resolution refer to Documentation/kbuild/kconfig-language.txt" Sep 05 07:37:51 what are those are about and how to resolve? Sep 05 07:44:28 unconfirmed temp fix = echo performance > /sys/devices/system/cpu/cpufreq/policy1/scaling_governor Sep 05 07:45:29 Off to bed, will follow up with bug report in the future Sep 05 08:31:38 Hi, how can I have multiple wireguard clients on openwrt? Sep 05 08:32:07 by having multip "config wireguard_wg0" sections? Sep 05 08:34:26 shalzz: using the luci app simplifies the setup Sep 05 08:34:38 or do you want to do it by uci? Sep 05 08:35:14 aparcar: I'd doing it via ssh Sep 05 08:36:24 aparcar: I have two "config wireguard_wg0" sections but only the last section client is able to connect Sep 05 08:37:55 Wait I think I have two "config wireguard_wg0 'wgclient'" sections. Change wgclient to be different for each? Sep 05 08:39:44 shalzz: I have multiple clients and it always starts with `config wireguard_wg0` Sep 05 08:39:54 so I think that should work Sep 05 08:41:30 Does the AllowdedIPs scope clients even if the public key doesn't match Sep 05 08:47:04 I think one or the other solved my problem Sep 05 08:58:34 gmail thinks http://lists.infradead.org/pipermail/lede-commits/2019-September/012501.html is a fishing attempt ... Sep 05 09:01:14 rmilecki: some coverletter explaining what your goal is for the sysupgrade.tgz filenname patches would be nice Sep 05 09:04:40 KanjiMonster: the point is to 1) avoid harcoded sysupgrade.tgz path so you can point any backup file and it doesn't even has to be copied Sep 05 09:04:56 2) make sysupgrade ubus method usable for not just a /sbin/sysupgrade Sep 05 09:05:39 i want to make "sysupgrade" ubus method to be reasonabe for normal use Sep 05 09:06:04 right now you have to *know* that /tmp/sysupgrade.tgz is some magic path where you have to put your backup before calling ubus method Sep 05 09:19:31 I see Sep 05 09:22:52 (so.... cover letter? ) Sep 05 09:26:45 karlp: in your case you could include a From: Karl Persson <...> line as the first line of the commit log; that would make git use that instead of the value from the email headers - not sure yet how to make git format-patch/send-email generate that automatically Sep 05 09:27:19 Palsson* Sep 05 09:27:21 sry Sep 05 09:28:55 yeah, it used to not do it, the git log itself is ok, but I was convinced to use git-send-email via outlook 365 because the mailing is substantially better way of getting patches accepted, but when _email breaks the patch_ I could also just use a github PR, which will have the _actual_ git commit in it :) Sep 05 09:30:45 does it need a perhaps Author: instead? From: is clearly what's being rewritten by outlook365's mail server. Sep 05 09:31:37 git log --raw: https://zerobin.net/?985476500ff87a5c#Nif4yMLR6PSuFAYdvo1MxiH0PJq92k1wfDtEAyk6Obo= Sep 05 09:32:34 KanjiMonster: in git-send-email edit mode, it already has "From: Karl Palsson " ? Sep 05 09:32:52 karlp: I'm talking of something like this: https://lkml.org/lkml/2019/9/4/586 Sep 05 09:33:28 the "From: ..." in the text of the email overrides the "From:" from the headers of the email Sep 05 09:35:45 like this? https://imgur.com/a/wXHF6CJ just again after the Subject: ? (that's edit mode in git-send-email Sep 05 09:36:04 yeah Sep 05 09:36:58 * karlp tries again. Sep 05 09:37:00 what might work as a workaround is to have a dedicated "send-from" git where you have your identity set to what outlook does (or something else), so git then will automatically add the From: line when generating patches Sep 05 09:37:22 (since it doesn't matche the author of the patch anymore) Sep 05 09:38:15 you don't want to do that in your actual development git, since it will mess up your commits and sign-offs, unless you remember to override them Sep 05 09:38:20 I'd say the real problem is that mail is an inappropriate method of transferring these things, but that's tilting at windmills... Sep 05 09:38:55 well, looking closer at the mr24 uboot env problem, it seems that despite claiming to have redundant u-boot-env partitions, and despite aligning the data as if it were redundant (i.e. with an extra 1-byte flag), the first partition (/dev/mtd1) is all 0xff, initially. Sep 05 09:39:09 karlp: using outlook is an inappropriate way of sending emails ;-) Sep 05 09:40:13 I think both arguments has merits (: Sep 05 09:41:24 russell--: I'm not. Sep 05 09:41:33 I'm using my organizations outbound mail server Sep 05 09:41:50 which is rewriting messages based on the authentication I used to sign in. Sep 05 09:41:57 karlp: ah, git format-patch --from="Foo bar " will generate the patches with the From: line, so maybe wrap your format-patch in a script adding that automatically, and your patches should then have a matching author and sob when applying with git Sep 05 09:42:40 KanjiMonster:I'll try that sending to myself, but I'd expect git to "ignore the duplicate" given that it alreayd matches the _local_ git authorship, it's only when it gets to the mailserver that it changes. Sep 05 09:43:15 that is, u-boot itself seems to only write to /dev/mtd2, but from openwrt, fw_setenv writes /dev/mtd1, but not /dev/mtd2 (at least on the first try) Sep 05 09:43:55 or at least in a way that's not strictly intuitive Sep 05 09:44:36 yeah, KanjiMonster it just ignores that as it's already in the commit. Sep 05 09:45:15 manual insertion seems to have worked at least, or looks like it did. Sep 05 09:45:16 * karlp cheers for KanjiMonster Sep 05 09:45:37 karlp: I don't quite follow - doesn't git add it autmatically if you use e.g. "git format-patch -1 --from="Karl Pálsson " ? Sep 05 09:45:51 (assuming its your top commit) Sep 05 09:46:22 I don't want Karl Pálsson. locally, in git config, in SoB, in Author, it's all without á. the á only appears after it reaches the mailserver and gets sent on. Sep 05 09:46:31 the point is to have --from to something *different*, so git thinks it isn't "your" patch and it needs to add the From line to the commit log ;) Sep 05 09:47:07 so you don't have to manually add it Sep 05 09:47:57 if your email server rewrites the From: line to the accented one anyways, then it shouldn't do any harm setting the email-from to that Sep 05 09:48:06 right yeah, that seems to work, ish. kinda feels worse to tell it the name I don't want to use though, for the frequency of commits I have. Sep 05 09:48:39 you only need to do it when generating patches Sep 05 09:49:40 and I suggest adding a simple alias or wrapper script for that that adds the argument, so you don't have to remember to do it Sep 05 09:51:20 something like format-patch -> "git format-patch --from=... $@" Sep 05 09:51:39 aha FLAG_INCREMENTAL, u-boot and fw_printenv are agreeing now that i don't try to overthink things. happiness reigns. Sep 05 09:51:51 \o/ Sep 05 09:52:35 flag_incremental? Sep 05 09:54:15 the partition name u-boot-env-redundant is kind of misleading Sep 05 09:54:52 if there are two environments, there is an extra flag byte before the data Sep 05 09:55:25 and, at least empirically, that flag value increments on each environment write Sep 05 09:55:47 and is written to alternating environment partitions Sep 05 09:58:21 karlp: KanjiMonster: i do that all the time, I have "user.name" and "user.email" set to the preferred values and when I do "git format-patch" (without any extra magic) I get a patch with a nice "From:" line Sep 05 09:58:22 karlp: KanjiMonster: i send patches using: git send-email --from "name " Sep 05 09:58:44 git send-email notices that patch has different From line and it includes that different From line in the e-mail body Sep 05 09:58:47 rmilecki: I don't have "another@email.com" Sep 05 09:59:15 rmilecki: ah, if that also works, that's nice Sep 05 09:59:25 making up another name that outlook will change it to works, but it's not quite the same thing. Sep 05 09:59:29 karlp: it should also work for a different name Sep 05 09:59:50 karlp: use --from "outlook name " Sep 05 10:00:21 yes, that works, but it's , IMO, absolutely horrific and worse than than just adding a second From: manually. Sep 05 10:00:32 karlp: ok, whatever you prefer :) Sep 05 10:00:55 anyway, I have it sent now, as far as I can tell, and anything further is just going to get me more wound up over details that either don't matter, or can't be changed :) Sep 05 10:02:58 for me it would be automatable > horribleness, but you do what works best for you ;) Sep 05 10:14:59 rmilecki: https://patchwork.ozlabs.org/patch/1157797/ - was it intentional you dropped the sysupgrade.tgz instead of replacing it with $BACKUP_FILE in platform_copy_config_linksys ? Sep 05 10:15:40 i've to thin Sep 05 10:16:51 KanjiMonster: see https://patchwork.ozlabs.org/patch/1157800/ - that one properly adds $BACKUP_FILE there Sep 05 10:17:17 KanjiMonster: so 1/2 didn't break anything, it just dropped path that wasn't needed Sep 05 10:17:23 2/2 make it look really correct Sep 05 10:17:56 it's probably a matter of taste if that was done the best way, but it doesn't break anything and 2/2 makes it the way it was meant to be Sep 05 10:18:42 1/2 is OK as $CONF_TAR is guaranteed that that point to point to the sysupgrade.tgz Sep 05 10:18:51 (is OK = doesn't break anything) Sep 05 10:27:05 https://patchwork.ozlabs.org/patch/1158243/ - have you considered setting CONF_TAR to the contents of UGRADE_BACKUP ? would reduce the amount of code to change, and could be used to prevent the (unstated) dependency on the procd patch being applied first (at a first glance it seems this would break with an unpatched procd) Sep 05 10:38:32 KanjiMonster: we already have $UPGRADE_* for options, so I wanted to be consistent Sep 05 10:38:46 KanjiMonster: that true though that I have to update procd properly Sep 05 10:39:12 KanjiMonster: we can't avoid that with some changes, see also https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=7290963d0992b9aa412e0066dcf721857fbd40f7 Sep 05 10:39:25 and related https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=b71962da16c2e2b93d633d7bde1436b3da2bf740 Sep 05 10:39:51 KanjiMonster: i'll make sure to specify such dependencies in all commits Sep 05 10:40:25 rmilecki: below the tear-off line (or in the cover-letter, if you have one) is enough Sep 05 10:40:54 i put that in commit, in case someone ever starts thinkin about picking such commit for stable branches Sep 05 10:41:12 it's easy to forget such dependencies after few months Sep 05 10:41:17 I guess my concern is making it harder to backport fixes/device support that touches these files Sep 05 10:41:20 and it probably doesn't hurt much ;) Sep 05 10:41:50 well changing all that makes it potentially harder, not that I *want* it to be harder ;) Sep 05 10:42:08 i'm fully aware of this Sep 05 10:42:18 we'll have to careful when picking any fixes Sep 05 10:43:04 KanjiMonster: maybe we could try making sysupgrade C-based and don't depend so much on files from base-files Sep 05 10:43:13 KanjiMonster: but not everone was happy about it Sep 05 10:43:36 KanjiMonster: e.g. jow wanted to be able to easily fix sysupgrade scripts when sth goes wrong Sep 05 10:43:45 (on a running device) Sep 05 10:43:50 right, and I agree with that Sep 05 10:43:55 OK Sep 05 10:44:06 i don't have opinion, just agreed with that decision Sep 05 10:44:20 so we keep scripts, but we just have to be careful about dependencies Sep 05 10:45:33 a netifd proto handler like approach might work, where we have common c code that calls different shell files for steps Sep 05 11:27:06 is there a dedicated file to introduce iptable rules into a firmware image? Sep 05 11:38:53 guess i found it at /etc/firewall.user Sep 05 14:54:28 any recent regressions in ath10k-ct wrt speed? downloading on my laptop (intel 8265) is fine (>200Mbps), upload only ~40Mbps Sep 05 14:55:18 laptop says: tx bitrate: 650.0 MBit/s VHT-MCS 7 80MHz short GI VHT-NSS 2 Sep 05 16:48:42 Greetings Sep 05 16:54:04 I build an openwrt image for an ipq4019 and i cant fathom how my fit kernel, crash while my fit-uImage is fine. It s a fork from commit d3e832d6fda8a39e7ec262994f75dac67353dcae, with very few modification ( basically the MTD layout ). openwrt-ipq40xx-ipq-hd53-initramfs-fit-uImage.itb and the initramfs one have the same date and all, one boot ok the Sep 05 16:54:04 other crash dump : Sep 05 16:54:42 [ 1.032721] 0x000000580000-0x000001b80000 : "rootfs" Sep 05 16:54:43 libphy: ipq40xx_mdio: probed Sep 05 19:25:39 Trying to build on a host where there is no /home/${user} directory which then fails with /ccache: error: Failed to create directory /home/devel/.ccache/tmp: Permission denied/ Sep 05 19:25:39 Is a home dir mandatory for the build process, there is nothing mentioned about it though in _https://openwrt.org/docs/guide-developer/build-system/use-buildsystem_? Sep 05 19:25:39 Having set /CCACHE_HOST_DIR="/path/to"/ && /CCACHE_TARGET_DIR="/path/to" did not remedy the matter. Sep 05 19:25:39 How then build without //home/${user}/ in attendance? Sep 05 20:24:12 greearb_: what you doing with AX that you need scan foo ? Sep 05 21:09:39 any idea why I wasn't getting those errors when compiling procd for master or 19.07? Sep 05 21:09:40 https://git.openwrt.org/?p=project/procd.git;a=commitdiff;h=0bcbbbf1abf76bf3aa8af5657308cac61f7de602 Sep 05 21:09:52 i noticed errors only after my experimental update of procd in the 18.06 Sep 05 21:51:57 blogic, I want to show /AX APs as such, by looking at the scan dump Sep 05 21:52:27 I'm working with the Intel AX200 in STA mode, seems to work pretty good so far Sep 05 22:21:10 buildbots don't support C++17 Sep 05 22:21:12 AGH Sep 05 22:22:35 gresource-tool.c:32:20: fatal error: libelf.h: No such file or directory #include Sep 05 22:22:58 looks like elfutils needs a host build **** ENDING LOGGING AT Fri Sep 06 03:00:56 2019