**** BEGIN LOGGING AT Wed Feb 24 03:02:58 2021 Feb 24 03:27:40 fyi: xtables-addons build is failing for me Feb 24 03:28:32 ERROR: "crypto_alloc_shash" [/home/openwrt/src/lede/build_dir/target-mips_24kc_musl/linux-ath79_generic/xtables-addons-3.13/extensions/pknock/xt_pknock.ko] undefined! Feb 24 03:29:50 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_mediatek.html has been updated. (100.0% images and 98.3% packages reproducible in our current test framework.) Feb 24 03:34:59 lipnitsk: ping Feb 24 03:35:07 hey Feb 24 03:35:20 haven't quite gotten to that script yet, maybe in an hour or so? Feb 24 03:35:49 sure just wanted to make sure I did not miss the PR Feb 24 03:35:58 nope, was busy Feb 24 03:36:35 no stress Feb 24 05:11:19 aparcar: ping Feb 24 05:11:33 lipnitsk: pong Feb 24 05:11:40 https://github.com/openwrt/packages/pull/14882 Feb 24 05:11:44 ack Feb 24 05:11:50 still has a temp commit Feb 24 05:12:02 but take a look at the detection and see if you want to test another case Feb 24 05:12:14 once it's good I can dump the temp commit Feb 24 05:12:59 I'm working rn on the docker CI fixup but will check it afterwards Feb 24 05:13:02 thank you very much for the work! Feb 24 05:13:48 okay let me know or leave a message in the PR Feb 24 05:19:22 lipnitsk: download speed here is low so I got wait times, please check comments Feb 24 05:47:48 aparcar: i know the nested loop looks ugly, but seems to be a case of "it works well enough" Feb 24 05:48:03 not a bash/awk guru ;) Feb 24 05:48:05 agree Feb 24 05:48:39 I should test it on my treewide patch refresh commit LOL Feb 24 05:48:55 maybe I'll revert that and see how well it detects things Feb 24 05:51:20 fun Feb 24 05:51:27 keep me posted once you think it's ready Feb 24 05:51:47 aparcar: it took 6 seconds on that monster commit Feb 24 05:52:03 beautiful Feb 24 05:54:17 yea looks good Feb 24 05:54:32 please remove the debug commits and I'll merge it Feb 24 05:55:06 ok Feb 24 05:56:49 aparcar: done Feb 24 05:58:39 actually wait Feb 24 05:58:45 I want to fix shellcheck Feb 24 05:59:28 lipnitsk: jeffreyto wants that patch backported to 21.02. I don't think we should. Feb 24 06:01:09 mangix: why not? Feb 24 06:05:04 aparcar: okay, done for real now - please merge whenever Feb 24 06:06:18 mangix: that is completely your call... Sorry, don't think I can help much. I can see his point, but then again, running refresh before cherry-picking is not hard either... Feb 24 06:07:02 does the release branch see a lot of PRs typically? Feb 24 06:07:50 lipnitsk: non invasive patches, yes Feb 24 06:08:16 lipnitsk: isn't grep -v /src/ better? imagine a package is called `showsrc` or something Feb 24 06:08:23 cornercase Feb 24 06:08:57 let me think. Yeah I strip that other slash earlier, maybe that should be done later Feb 24 06:10:05 or better yet, move grep -v "/src/Makefile" to happen earlier Feb 24 06:15:54 aparcar: okay, fixed the cornercase Feb 24 06:17:14 BTW, just thought of a clever hack - do you guys enforce somehow that people base the PRs on a recent-ish tree? Otherwise somebody could base their work on an old tree without some CI features :) Feb 24 06:18:14 lipnitsk: not sure how GH handles this. Feb 24 06:18:25 if you developed a taste for CI, please check https://github.com/openwrt/packages/issues/14870 Feb 24 06:19:05 fun Feb 24 06:20:13 don't know if I like it that much :) Feb 24 06:21:03 how frequent is that issue? Feb 24 06:21:50 or rather, how often does it result in failures? Or does it cause CI to miss checks? Feb 24 06:24:02 lipnitsk: most people that backport PRs are the turris people. They're competent. Feb 24 06:24:29 Backporting is not something typically done. Feb 24 07:12:12 something in the xtables-addons package required kmod-crypto-hash, but it isn't configured in for some reason Feb 24 07:22:12 fudged by CONFIG_kmod-crypto-hash=m, this seems like a regression somewhere Feb 24 07:35:43 hmm I'm getting spam for some reason Feb 24 07:36:01 ? Feb 24 07:36:19 freenode spam? /mode russell-- +R Feb 24 07:38:59 nah. random freenode accounts messaging me with completely random messages Feb 24 07:50:52 Maybe they are trying to check if you are using screen and crash your instance like they are doing that for Minecraft servers? Feb 24 07:51:20 I mean this: https://lists.gnu.org/archive/html/screen-devel/2021-02/msg00000.html Feb 24 07:52:54 mangix: if you set the +R mode for your nick (like in my example) that apparently blocks unregistered people from /msg'ing you Feb 24 07:53:48 "Due to today's high wave of spam, you might want to set yourself +R to block PMs from unidentified users." Feb 24 07:56:20 they just msg:ed me some random words, anyone know what they're trying to do? Feb 24 08:07:39 Hauke: could you also apply the sg150x patch (773949c15) on 21.02? otherwise the R6800 and R6700v2 won't have working LEDs in the release Feb 24 08:30:28 'morning! Feb 24 08:30:40 'Morning Feb 24 09:06:59 Hmm… just registered a fw3 complaint: "Warning: Section @nat[0] does not specify a protocol, assuming all" Feb 24 09:08:16 I'm not sure I agree with this being a warning at all. The common case for NAT is doing it for every protocol (SNAT/DNAT/MASQUERADE), so why complain? :/ Feb 24 09:16:50 Likely because "all" _can_ be something not wanted Feb 24 09:17:22 and hence warn as it isn't failure, but potentially gives away more than is intended Feb 24 09:48:33 Is there a luCi app or mod that displays DHCP info with Hostname, IP, MAC, etc? Aside from the Dashboard, whcih doesn't show IP Feb 24 09:49:19 *sigh* Disregard ;p Feb 24 09:50:00 luci-app-ttyd can be used to display whatever you want Feb 24 09:52:48 Yeah, but I have console for that. I did find it however, at the bottom of the Status page Feb 24 09:52:52 I just never scroll down Feb 24 09:53:23 For some reason, one of the TV's is tryibg to use Google's DNS Feb 24 09:53:32 and I couldn't ID it Feb 24 10:23:09 rsalvaterra: no idea how to set the mode Feb 24 10:25:39 mangix: Set the mode? Sorry, I'm missing context. :) Feb 24 10:28:52 +R Feb 24 10:29:17 ah I meant russell-- Feb 24 10:29:47 Eheheh! Feb 24 10:30:14 /mode mangix +R Feb 24 10:31:02 Sweet Feb 24 10:32:41 jow: should the xtables-addons in the packages feed have a PKG_BUILD_DEPENDS on kmod-crypto-hash? Feb 24 10:32:55 hi, I wonder whether we can convince quilt to not cut the index lines Feb 24 10:33:23 anybody has an idea, since the manual is not really easy ... Feb 24 10:34:41 russell--: thanks for verifying iproute 5.11. Are you otherwise OK with https://github.com/openwrt/openwrt/pull/3904? Feb 24 10:35:39 guidosarducci: yes, looks fine to me Feb 24 10:36:26 Damn conspiracy theory spam... Feb 24 10:38:10 russell--: great, thanks. I'd like to see this as the baseline for 21.02 too, it should be clean. Feb 24 10:42:17 Ouch… iproute is getting really fat… Feb 24 10:45:27 rsalvaterra: most things just got skinnier due to dropped dependencies Feb 24 10:46:06 the default ip command comes from busybox iirc Feb 24 10:47:14 and the ip-tiny from iproute2 has been manually gutted to reduce size Feb 24 10:54:44 Yeah, I only use ip from BusyBox, ever since I fixed wireguard-tools to not depend on ip-tiny… but I need tc for sqm-scripts. :) Feb 24 10:55:54 rsalvaterra: and there's no "light" version of tc. What would you drop: filters, classes, or qdiscs? :-) Feb 24 10:56:39 looks good https://lore.kernel.org/linux-arm-kernel/595affb4-36e8-0a63-ebb3-a4fd0e3c243a@huawei.com/ Feb 24 10:57:00 (Re: 5.10 LTS Kernel: 2 or 6 years?) Feb 24 10:58:45 ynezz: Advice for moving to a testing kernel? I've mod'ed the kernel_versions.mk, but do I just copy the patches-/confg-5.4 to a 5.10 version? The patches, only 1 had to be removed, the rest were still clean Feb 24 10:59:13 But I'm not sure how to build the kernel config from scratch Feb 24 10:59:23 the actual .config file, I mean Feb 24 11:00:28 rsalvaterra: one other thing that grows footprint re: sqm implementations is the "kitchen sink" of kmod-sched modules. I've been meaning to reorganize things more like ipt-mod-*. Is there other interest in that? Feb 24 11:01:46 build #9 of lantiq/xway is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/lantiq%2Fxway/builds/9 blamelist: ?lvaro Fern?ndez Rojas , Daniel Gonz?lez Cabanelas Feb 24 11:02:25 True… I have sch-* stuff I don't use at all. Maybe split sqm-scripts into variants…? I mean, most people probably use fq_codel and/or cake… Feb 24 11:06:31 rsalvaterra: well, split kmod-sched up, and then other consumers like sqm-scripts, qos-scripts, nft-qos, can be updated to use what's installed. It's not difficult; I have a 3-year old sqm rewrite that could do this now... Feb 24 11:07:22 rsalvaterra: the glaring example is every standard shaping qdisc being bundled together when most people will just use one. Feb 24 11:08:20 I only use sqm-scripts, never tried anything else (isn't qos-scripts obsolete?)… Feb 24 11:11:28 Grommish: just look at the recent bumps that have been merged Feb 24 11:11:45 you can then just select the testing kernel via make menuconfig (in global options) Feb 24 11:11:54 That doesn't tell me how to generate the kernel .config Feb 24 11:11:57 Oh, Ive done that Feb 24 11:12:03 rsalvaterra: probably yes, but I was still asked to "fix" it when it broke from another change. :-) A few years ago I rewrote most of sqm-scripts for ease of use, maintainability, etc., mostly for friends/family I had to support. That's been my daily driver a long time. Feb 24 11:12:41 My issue is after copying patches-5.4 to 5.10, should I do the same thing with config-5.4.. Feb 24 11:12:53 guidosarducci: Oh, my…! This is crazy, indeed. https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/kernel/linux/modules/netsupport.mk;h=2c2fe82fa09ee9123353007aab6bb637e06bec42;hb=HEAD#l722 Feb 24 11:12:54 Grommish: you copy config from 5.4 to 5.10 and then refresh via make kernel_oldconfig Feb 24 11:12:56 a better question might be is there a kernel_defconfig type option Feb 24 11:13:34 the first patch in the series not just copies patches, but also config (both without change) Feb 24 11:15:05 I'm being ignorant adrianschmutzler, but I'll figure it out :) Feb 24 11:15:47 guidosarducci: You should see if tohojo accepts your sqm-scripts rewrite… :) Feb 24 11:15:58 rsalvaterra: yeah, many of those small "jelly-beans" belong in a core package, but hfsc, htb could be separate for example. I have notes mapping out a lot of changes, so will try to do it for current master. Feb 24 11:18:33 guidosarducci: Also this… https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/kernel/linux/modules/netsupport.mk;h=2c2fe82fa09ee9123353007aab6bb637e06bec42;hb=HEAD#l884 Feb 24 11:19:37 jow: test case, add CONFIG_PACKAGE_iptables-mod-condition=y to a vanilla config, the make target/linux/clean world ... my build is dying in the xtables-addons build due to missing kmod-crypto-hash dependency (only needed for some subpackages in addons, like kmod-ipt-sysrq) Feb 24 11:20:47 rsalvaterra: that ship has sailed! Tried back than, but faced pointless argumentativeness and outright obstruction, as a couple others also noticed and mentioned to me. Just never gotten around to widely sharing my version yet, but mean to soon ;-] Feb 24 11:20:57 build #774 of apm821xx/nand is complete: Failure [failed gcc] Build details are at http://buildbot.openwrt.org/master/images/builders/apm821xx%2Fnand/builds/774 blamelist: ?lvaro Fern?ndez Rojas Feb 24 11:21:53 rsalvaterra: yeah, there's lots of opportunity to clean up the netsupport modules... I'll ping you when I start the PR, probably a "WIP" type. Feb 24 11:21:58 Gah… is it sacred, or something? Why can't we improve things when they can be improved? :/ Feb 24 11:22:35 Sure, I could help you testing, at least, since you already have a head start. :) Feb 24 11:24:22 rsalvaterra: not sacred, but when getting a review/merge done can take 6-9 months one tends to prioritize one's efforts. Feb 24 11:25:00 rsalvaterra: I also thought 20.xx was coming too soon and didn't have time to fix all the dependent packages. I guess I was wrong! Feb 24 11:25:24 guidosarducci: I also understand the other side, reviewer bandwidth is scarce… I just keep pushing, since I'm quite patient… :P Feb 24 11:26:00 adrianschmutzler: thanks for looking at quilt. Feb 24 11:26:11 adrianschmutzler: one option would be dropping the requirement that refresh get run..... Feb 24 11:27:11 karlp: sorry, I don't get that Feb 24 11:27:29 and be aware that I'm looking at this for the first time, I just used it so far Feb 24 11:27:45 rsalvaterra: "pushy" helps too :-). But also, over the ~decade I've followed OWRT, reviewer bandwidth as well as attitudes go up and down. Things are certainly better than the bad old days. Feb 24 11:28:03 well, manginx and friends pushed on us this massive "trample all the patches to one uniform style!!!" commit Feb 24 11:28:27 which is ... yes, uniform.... and lets "refresh" run cleanly. Feb 24 11:28:41 but was fairly clearly noise and removed useful data and context from completely valid patches. Feb 24 11:28:55 karlp: reference? Feb 24 11:29:01 rsalvaterra: thanks, I'll make sure to ping you on the PR. Feb 24 11:29:15 apart from that, note that I generally like stuff like the index being removed etc. Feb 24 11:29:16 packages:treewide: refresh all patches... ? Feb 24 11:29:32 you're clearly seeing the same thing now, that you refer to in your devel mail. Feb 24 11:29:54 guidosarducci: Thanks! ;) Feb 24 11:31:44 well, my problem is not so much refreshing patches and removing unneeded stuff, I just think that particular issue I mentioned should be treated Feb 24 11:32:21 which would probably already remove 50 % of the lines in stuff like "refresh all patches" Feb 24 11:32:39 exactly, Feb 24 11:32:51 which is what I tried to raise on the PR, but.. well :) Feb 24 11:32:59 refresh all the patches! Feb 24 11:33:25 I don't know that there's a solution for the context lines. Feb 24 11:33:41 so the solution is to destroy all context in patches? Feb 24 11:33:52 ..... Feb 24 11:33:54 russell--: ah, I forgot to ask if you could add your "Checkmark" (or whatever it's called) to the iproute2 PR. Thanks very much for looking. Feb 24 11:34:04 take a nice perfectly formed upstream git patch file and just toss most of it out? to keep quilt happy? Feb 24 11:34:09 I'm talking about what adrian mentioned Feb 24 11:34:41 Patch description was not removed Feb 24 11:34:53 mangix: but this is actually done by quilt? Feb 24 11:34:53 guidosarducci: review is limited to people with write access which i don't have afaik Feb 24 11:35:40 cause I did not find any documentation on it (just want to make sure we don't just cut it ourselves somewhere) Feb 24 11:36:09 other stuff seems to have options, like --no-index etc. Feb 24 11:36:49 AFAIK, quilt uses GNU diff by default. Feb 24 11:37:17 russell--: oh, I was asking because you're listed as the maintainer. Just a comment would do as well I suppose. Feb 24 11:37:34 yes, it doesn't remove _all_ the description, it just reformats it.... for... whatever: https://github.com/openwrt/packages/commit/5d8d4fbbcb5c5de9370711c19bb3510210989a98#diff-44811c9cceabba20a57725690fc66e6aa429b3073cd06dec3cab6adf6cf02b64L12 Feb 24 11:37:54 the line truncation is the biggest source of wtf noise though Feb 24 11:38:15 probably I will have to look at the quilt source Feb 24 11:38:18 I can live witht he other mangling just fine Feb 24 11:38:36 but the line truncation genuinely makes the patches worse. Feb 24 11:39:17 I am not a fan of the truncation either. Feb 24 11:39:29 but you went ahead with it anyway? Feb 24 11:39:44 even with ones that didn't do any truncation, you removed irreelvant htings, with no refresh, in things like https://github.com/openwrt/packages/commit/5d8d4fbbcb5c5de9370711c19bb3510210989a98#diff-424aeb52001f2adea4b697d7ee2b37cebec68ac87936f1700c7bd8a3be2be5c1L12 Feb 24 11:40:13 _heaps_ of them had only that level of change. Feb 24 11:40:51 be aware that if we don't truncate, we will get similar diffs on _all_ kernel patches Feb 24 11:41:11 that will be a hell of a patch Feb 24 11:41:23 :) Feb 24 11:41:42 so what'ðs the goal, support patch files from upstream, or make refresh generate the smallest change sets? Feb 24 11:42:10 The goal is to remove fuzz and bad offsets Feb 24 11:42:11 wasnt line length extended in Linux Kernel recently - or at least "softened" Feb 24 11:43:17 I just remembered, now we've already branched 21.02, maybe it would be a good time to address the elephant in the room… the black sheep of mvebu, WRT1900AC v1/v2. :/ Feb 24 11:44:11 Welcome back Feb 24 11:45:54 Mamba/cobra are dumbing down the whole mvebu/cortexa9 subtarget, by being the only ones not supporting both NEON and VFPv3-D32. Feb 24 11:46:45 :P Feb 24 11:47:04 Anything else (Armada 38x) is basically castrated at birth. :/ Feb 24 11:47:04 Borromini: You still looking for octeon TZ wierdness? Feb 24 11:47:47 Grommish: yes, it's still on my list Feb 24 11:47:50 you bumped into something? Feb 24 11:48:00 I can confirm it at least Feb 24 11:48:04 Seems there's a cortex-a9 target Feb 24 11:48:15 Non NEON anor vfp Feb 24 11:48:17 Grommish: ok you only get UTC shown as well? Feb 24 11:48:20 I just put one of the Shields up as my live edge so I actually have acess to it Feb 24 11:48:22 Move it there? Feb 24 11:48:50 No, actually, I get UTC set to UTC-3.. I have to offset by -8 to get EST Feb 24 11:49:02 karlp: mangix: I will have a look at the quilt code later; but having to make the kernel patch diff lines longer again will probably kill any attempts eventually Feb 24 11:49:06 Grommish: all over the place it seems... Feb 24 11:49:24 I'm fully able to select TZs Feb 24 11:49:31 but it doesn't do a thing? Feb 24 11:49:47 It does on the Time Zone page in luCi Feb 24 11:49:50 Interesting Feb 24 11:49:54 mangix: We should move it somewhere, yes… Either that, or create yet another mvebu subtarget. Feb 24 11:50:09 I don't believe the latter will fly… Feb 24 11:50:33 It will not Feb 24 11:50:33 . Feb 24 11:50:39 Grommish: in the LuCI overview do you see EST or what the router prints on the CLI? Feb 24 11:50:56 because for me it's both UTC no matter what (should be on CET) Feb 24 11:50:58 Status Page shows "Local Time" in UTC. Feb 24 11:51:14 If you go into System/System Feb 24 11:51:37 You can show Local time change when you mess with the drop down Feb 24 11:52:50 Now, its just showing Local time, regardless of what i set :D Feb 24 11:53:16 Anyway, if you find somehing I can help with, lemme know Feb 24 11:53:32 mvebu neon subtarget has been tried several times and never met acclaim at committers Feb 24 11:55:09 Grommish: will do, thanks. i have no idea what to dig for for now, lots of people already suggested stuff but all those settings seem standard, and ironically it all works on all my non-octeon stuff (it's basically a custom uci defaults script presetting all the timezone stuff here) Feb 24 11:55:38 my /var/TZ files is correct Feb 24 11:55:45 EST5EDT,M3.2.0,M11.1.0 Feb 24 11:56:17 Hauke: would you mind backporting 773949c152, b5bc53813d and 06356f0020 to 21.02? Feb 24 11:56:35 adrianschmutzler: mangix what about what I suggested that refresh only be pushed on patches that result in fuzz being applied? Feb 24 11:56:39 Grommish: yeah string is fully correct here as well. Feb 24 11:56:41 rather than just blanket all patches? Feb 24 11:57:30 Borromini I'm going to give 5.10 a try to see what fails.. Aside from a wireguard error, nothing so far, so I'm hopeful Feb 24 11:57:55 I did a rebase to sweep up anything I missed Feb 24 11:58:57 Grommish: cool! you got octeon patches for 5.10 ready? Feb 24 11:59:27 Everything but 100-* moved over clean Feb 24 11:59:40 It had been upstreamed Feb 24 12:00:10 and it says it built Feb 24 12:07:41 :^) Feb 24 12:08:29 I almost want to test this ;p Feb 24 12:08:33 haha Feb 24 12:09:17 Says it built fine. I had wg-tools and it died on those because its' built in now.. and a few personal packages that don't work right now.. other than that,. it's clean Feb 24 12:10:15 But, it'll have to wait for the test machine. Only one I have access to from here is the edge router ... Feb 24 12:10:24 so tempting Feb 24 12:13:05 coward Feb 24 12:14:15 Very much so haha Feb 24 12:14:39 Of course, I can build Borromini an image ;p Feb 24 12:15:51 Grommish: With current master, you can get WireGuard working if you compile it in the kernel (and select the wireguard-tools package). Gross hack, while support for 5.10 isn't merged, but better than nothing. :) Feb 24 12:16:12 I mean, under 5.10, you have to remove the wg-tools Feb 24 12:16:40 Says it's un-needed since >5.6 Feb 24 12:17:29 Oh, unneeded? I missed that one… Feb 24 12:19:10 No, you still need wireguard-tools to configure the connections. Feb 24 12:19:29 lipnitsk: i pushed a bunch of changes Feb 24 12:21:05 rsalvaterra: gotcha.. Must have been in one of the comits I grabbed.. it was complaining wireguard-linux-compat is a no-no now Feb 24 12:21:11 zx2c4: The memory savings are nice, to say the least. ;) Feb 24 12:22:45 Grommish: You need to disable the kernel module compilation (kmod-wireguard), as it's still the compat version. Feb 24 12:23:32 Grommish: sorry wonky MT7613 radio :) Feb 24 12:23:34 timed out Feb 24 12:25:05 karlp: I actually like that uniform style Feb 24 12:25:32 however, due to that kernel patches problem, one might choose what you suggested eventually Feb 24 12:26:15 well, you're going to get "noise" on _every_ first refresh right now, but at least it's only on the first refresh? :) Feb 24 12:26:20 rsalvaterra: kmod_wireguard now has a KERNEL-5.4 requirement, so it must have been fixed by a commit I grabbed after the error :) Feb 24 12:27:48 Yes, that workaround was merged yesteday. :) Feb 24 12:27:54 *yesterday Feb 24 12:28:29 karlp: well, the optimal case of cause would be if patches are submitted already after a refresh has been run Feb 24 12:28:40 do I have to manuaky enable that kmod in kernel? Feb 24 12:29:01 that seems to be at odds witht he stated goal of making it easier to submit changes :) Feb 24 12:30:08 Grommish: Yes, but not as a module. Built-in. Feb 24 12:31:18 rsalvaterra: Gotcha. Thanks :) Feb 24 14:28:25 so, after several hours of trying to understand quilt, what have I found out? Feb 24 14:28:37 it's a diff bug Feb 24 14:28:53 diff -pu my/a.txt my/b.txt Feb 24 14:32:53 or not really a bug, rather they hardcode 40 characters max: Feb 24 14:32:55 https://git.savannah.gnu.org/cgit/diffutils.git/tree/src/context.c#n156 Feb 24 14:40:29 karlp: and that will probably mean that the are seen as different from quilt anyway, so filtering refresh on changed files won't help here either Feb 24 14:47:55 I was suggesting just to look in the logs for the "patch applied with fuzz" and only then consider any sort of patch refresh, rather than trying to automate it. Feb 24 14:59:15 ah, okay Feb 24 15:00:35 because that's the only time the patches actualyl _need_ anything, and it instantly eliminates any noise changes. Feb 24 15:01:26 so yes, flag/reject submissions that the PR builders find "fuzz applied" in the logs, but otherwise don't interfere. Feb 24 15:01:59 well, changing positions might also get a problem, just not so quickly Feb 24 15:02:18 and buildbots doing daily snapshots can even autofile bugs on fuzz applied if someone bypasses the premerge checks Feb 24 15:02:40 if it applies cleanly to the wrong place, refresh won't help anyway? Feb 24 15:02:57 these things typically change gradually Feb 24 15:03:13 you have a patched driver with offset 10 Feb 24 15:03:24 during next kernel refresh it's 50 Feb 24 15:03:25 right, but everytime they do, the daily buyildbots will have a fuzz line int he log Feb 24 15:03:26 then 100 Feb 24 15:03:33 and they can be addressed then. Feb 24 15:03:36 and suddenly it will be 150 and match to the wrong section Feb 24 15:03:43 I'm not sayign to ignore them, fix them as they come up, Feb 24 15:03:47 this might happen without any fuzz Feb 24 15:04:04 s/fuzz/with offset or fuzz/ then :) Feb 24 15:04:08 that's what I meant anywya :) Feb 24 15:04:35 but huge chunks of those refreshes were not even refreshing offset, just stripping the line endings and git index info Feb 24 16:03:06 linux 5.10 looks to work nicely on my wrt1900acs, dmesg looks ok theres 2 messages about how cpu hotplug and cpu idle are currently broken but otherwise looks normal Feb 24 16:04:03 grift: Awesome! B) Feb 24 16:04:34 thanks for that Feb 24 16:04:58 Yeah. Hotplug, idle and frequency scaling are basically broken. Hardware bugs, I guess. Feb 24 17:51:36 russell--: it's defined in linux-5.4.99/include/crypto/hash.h ... What kernel are you building? Feb 24 17:52:03 Worked on bluez-pulseaudio before. I don't think it works now. : [pulseaudio] ltdl-bind-now.c: Failed to open module module-bluetooth-discover.so: Error loading shared library module-bluetooth-discover.so: No such file or directory Feb 24 17:57:13 some pulseaudio modules might not be compiled or need extra package Feb 24 17:57:35 pulseaudio with bluetooth is kind of messy Feb 24 17:58:35 discover needs avahi Feb 24 17:58:39 probably Feb 24 17:59:18 russell--: did you get the chance to test 5.4.100 on your dir-860l? Feb 24 17:59:32 wondering if that instability issue is back. Feb 24 18:00:59 zx2c4: thanks, LGTM. I pushed a minor rename (duplicate 082-... patch in 5.10 backports) Feb 24 18:02:02 JMV2009, maybe try to recompile without -Dbluez5=false as build switch - it was added in update to 13.0 Feb 24 18:02:45 plntyk: probably Feb 24 18:07:22 lipnitsk: super Feb 24 18:11:58 lipnitsk: looking at the buildbots if we broke something Feb 24 18:12:27 Looks like p1010 is under the wheels now Feb 24 18:12:36 blocktrron: uh oh - the kmod PR? Feb 24 18:12:41 yup Feb 24 18:12:45 let me check Feb 24 18:13:04 do you have fail link? Feb 24 18:13:36 http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fp1010/builds/307/steps/images/logs/stdio Feb 24 18:13:57 WDR4900 failed due to missing space on the kernel partition Feb 24 18:14:36 oh so some stuff was added that pushed it over the limit? Feb 24 18:14:42 yes Feb 24 18:14:48 yeah, I didn't clause everything with LINUX_5_10 Feb 24 18:14:54 maybe that's the problem? Feb 24 18:14:55 But we were driving on tens of KB with that board anyway Feb 24 18:15:19 So this was set to happen with 5.10 anyways Feb 24 18:15:24 so it's fine Feb 24 18:15:28 ok Feb 24 18:15:41 I'll just push a patch to disable the wdr4900 Feb 24 18:16:07 okay, thanks, glad it's just a bloat fail (well, not really glad, but still) Feb 24 18:16:24 We've had the discussion around 2 years ago Feb 24 18:16:37 nobody cared to come up with a proper fix in the meantime Feb 24 18:16:51 So let's move forward Feb 24 18:18:12 btw is ipq80xx a DSA target? Feb 24 18:33:13 svanheule: Borromini I will backport the changes to 21.02, but I think b5bc53813d is not needed as we do not want to support the realtek target in 21.02 Feb 24 18:34:05 Hauke: i was keeping quiet since i wasn't sure if opinions had changed or not :^) Feb 24 18:36:07 enyc: I was not aware of this problem with the ath10k-ct firmware Feb 24 18:36:42 enyc: I do not have the time to debug this, but it would probably help to know since when this problem happens Feb 24 18:38:21 Hauke: we should decide about realtek at some point Feb 24 18:39:32 * Borromini is in favour of keeping it in 21.02 Feb 24 18:58:33 build #14 of ath25/generic is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/ath25%2Fgeneric/builds/14 blamelist: Daniel Golle Feb 24 19:04:16 anyone have a template .xml file for qemu/libvirt on CentOS to run an x86_64 UEFI guest? Feb 24 19:07:47 indeed, what about creating a directory in the repo and storing such information for testing, etc? Feb 24 19:16:20 probably separate repo is better - uefi guest requires OVMF firmware package installed Feb 24 19:18:26 philipp64, added uefi cmdline for qemu on https://openwrt.org/docs/guide-user/virtualization/qemu Feb 24 19:20:50 with libvirt you simply select uefi in virt-manager when creating new machine Feb 24 19:21:03 OVMF is usually part of the platform (host) packaging... Feb 24 19:22:06 why, have you gotten it to work? Feb 24 19:27:46 on archlinux host i am running several uefi-enabled guest images Feb 24 19:28:08 even some uefi-applications do work in qemu Feb 24 19:28:33 https://github.com/ohnx/nyan-load/ for example Feb 24 19:30:01 can you paste your XML? Feb 24 19:35:46 philipp64, https://paste.debian.net/1186804/ for example Feb 24 19:38:12 with cmdline qemu you can map a normal folder to a fat drive - dunno how syntax is in libvirt Feb 24 19:39:05 svanheule: Borromini backprot is done Feb 24 19:39:20 Hauke: thanks! Feb 24 19:44:54 Hauke: thanks a lot. Feb 24 19:52:18 Hauke: ok, how would I get back-versions of master or so to test? I have at least one older device... Feb 24 19:52:39 [which has jan-ish master on it, would need to check problem NOT happening there] Feb 24 19:52:47 then somehow 'work forwards' Feb 24 19:53:36 enyc: you could try to revert a commit updating the ath10k-ct firmware to just use a older version Feb 24 19:53:42 when did this work the last time? Feb 24 19:54:25 Hauke: i'm not yet a git-voodoo / bulding my own, have been using Master builds or 21.02SNAPSHOT builds as downloads.openwrt.org provides Feb 24 19:54:45 Hauke: I would need to check but I believe i wasn't having toruble with ~january-ish master build Feb 24 19:58:40 aparcar[m]: "build/json: generate json file for initramfs" broke mpc85xx-p1010, can you check that? Feb 24 20:00:41 enyc: are you good at Makefiles and Docker? Feb 24 20:01:39 If so, I have https://git.laboratoryb.org/hurricos/docker-builder that gives Makefile recipes to build a Docker image of the builder and then build a particular config at a particular commit Feb 24 20:01:52 hurricos: understand makefiles in principle and cound proabbly successuflly manage. Docker no, but happy to learn. Feb 24 20:01:59 it's got some hard-coded trees though Feb 24 20:02:00 ah, ok Feb 24 20:02:12 hurricos: used to chroots and dpkg-buildpackage and all of that Feb 24 20:02:14 s/trees/filesystem paths/ Feb 24 20:02:29 That bit I don't know about :^) Feb 24 20:02:32 hurricos: are you saying there isn't an archive of downloads snapshots builds I could just 'use' ? Feb 24 20:02:49 they get cleaned I expect? It's more than a few gigs of artefacts ... Feb 24 20:02:53 ok Feb 24 20:03:04 if you use that project above Feb 24 20:03:34 Well, actually, don't. It presupposes you know how to set up docker and possibly increase default volume size Feb 24 20:03:37 :Cc Feb 24 20:04:19 in any case, why all this commit fun, couldn't I just swap aut the ath10k-firmware opkg or at leath the underpinning /lib/firmware/ etc file? Feb 24 20:04:20 but other than that you could clone that down onto a fresh machine under /devel/docker and literally just do `make built/openwrt-builder-$commit.sentinel` Feb 24 20:04:34 enyc: Kernel vermagic changes if you breathe on it Feb 24 20:04:48 you could possibly do the latter Feb 24 20:05:14 opkg's are just compressed .tar's, I think vaguely similar to how debian does it Feb 24 20:05:32 you could similarly git log `linux-firmware` and find the versions of *ct fw Feb 24 20:05:46 and checkout those and then copy them where you need. Feb 24 20:05:59 problem is driver<->fw may not play nice together necessarily Feb 24 20:06:05 just for Jan probably fine. Feb 24 20:06:28 in any case, which firmware commit !?!?!?! Feb 24 20:06:43 Hauke: what about gcc version bump? :) Feb 24 20:06:45 Clone down linux-firmware tree from Torvdalds and git log the actual file you're looking at. Feb 24 20:07:03 it'll show you the commit that exist and approx when they endd up in OpenWrt. Probably. Feb 24 20:07:10 Hauke: I think, it's about time to switch Feb 24 20:07:10 there's ike 20 versions max Feb 24 20:07:26 ynezz: you folks love bleeding edge don't you :^) Feb 24 20:10:05 well gcc10 is more then year old, no edge anymore Feb 24 20:10:14 ynezz: Yes I would like to use GCC 10 in master Feb 24 20:10:23 and musl 1.2 Feb 24 20:10:40 so lets break it all at once or incrementaly? :p Feb 24 20:11:11 first gcc, then when dust settles bump musl? Feb 24 20:11:22 I would prefer to wait with gcc 10 till we have 21.02-rc1 or rc2 Feb 24 20:11:23 Borromini: got the ports to come up on my P2041 :D Feb 24 20:11:28 ynezz: kidding :^) it's good practice Feb 24 20:11:34 I like knowing when my things are going to be broken Feb 24 20:11:46 till then we could see some bugs in master Feb 24 20:12:04 and then about 3 weeks after the gcc 10 update do the musl 1.2 update Feb 24 20:12:04 and the only way to know is to be on newer gcc, of course Feb 24 20:12:14 Woohoo! Break^W Update it! \o/ Feb 24 20:12:20 thanks you all for keeping it up Feb 24 20:13:12 I don't know about musl, but gcc 10 is building all my images just fine. Feb 24 20:13:14 I think mangix prepared there some patches for gcc 10 and musl 1.2 Feb 24 20:13:35