**** BEGIN LOGGING AT Mon Apr 12 02:59:56 2021 Apr 12 06:25:21 Nah, I have 112 ;) Apr 12 07:46:35 jow: https://github.com/openwrt/packages/issues/14897 Apr 12 07:59:30 Great, just wasted more of my time trying to test 21.02 using IB, and traced it to dnsmasq-full builds failing for ath79 in 21.02-SNAPSHOT. Looks like someone was playing with $(FPIC) and broke the libnfnetlink dependency. Apr 12 08:00:43 Seems related to multiple, coordinated FPIC changes in master, with only some being backported (e.g. https://github.com/openwrt/openwrt/commit/dc31191ec3e5c). My guess is this at least also needs backporting: https://github.com/openwrt/openwrt/commit/7fae64cc0657. Hauke or ldir, help? Apr 12 08:24:51 guidosarducci: please fix bpftools. thanks.https://gist.github.com/neheb/02f42d32eda541be1ce3794f76bb4a3f Apr 12 08:38:02 mangix: fix what exactly? You've provided zero context for reproducing, and a gist that could be a compiler/build system issue... Apr 12 08:40:55 want a .config? Apr 12 08:44:20 mangix: how about start with what what troubleshooting you've done so far? Apr 12 08:45:20 mangix: This seems rather strange: gcc: error: unrecognized argument in option '-mabi=64' Apr 12 08:45:38 not really Apr 12 08:46:01 it's using gcc instead of TARGET_CC somewhere Apr 12 08:56:29 rmilecki: FYI https://buildbot.openwrt.org/master/images/#/builders/71 :) Apr 12 08:57:06 ynezz: i saw that, thanks Apr 12 08:57:10 rmilecki: you should build with CONFIG_BUILDBOT=y in order to reproduce the failures locally Apr 12 08:57:18 ynezz: first I had problem finding error in that long log Apr 12 08:57:21 but got it finally Apr 12 08:57:54 ynezz: do you think it would make sense to build using "make -j $FOO V=s|| make V=s" ? Apr 12 08:58:13 ynezz: so after failing build with multiple threads, a next attempt it made with single thread Apr 12 08:58:19 and so error is easy to find Apr 12 08:58:34 IIRC we've discussed this already, it makes sense, patches are welcome :) Apr 12 08:58:50 ynezz: possibly, i could forget Apr 12 08:58:53 ok, thanks Apr 12 08:59:15 FWIW: ERROR: module '/builder/shared-workdir/build/build_dir/target-aarch64_cortex-a53_musl/linux-bcm4908_generic/linux-5.4.109/drivers/crypto/ccp/ccp-crypto.ko' is missing. Apr 12 09:01:52 while at it, it might probably make sense to use similar approach as in phase2/packages, thus build with BUILD_LOG=y and do `make -jMAX || make -j1 V=s` Apr 12 09:30:53 mangix: Huh? You're expecting that error? Based on what analysis? And why do you think it's an issue with bpftools package and not your build system, or your latest test GCC? Can you be more forthcoming and clear? Otherwise I doubt I can help you. Post your analysis, troubleshooting, steps to reproduce, etc somewhere and I'll try to look later, but need to run now. Apr 12 10:10:01 jow: hey, i'm looking for a way to use "uci" cli in 2 isolated contexts Apr 12 10:10:20 jow: both -p and -P seem to *add* new delta path Apr 12 10:11:06 jow: so if my old app code uses /tmp/.uci and new one uses "uci -P /tmp/.foo" i still have that one look in /tmp/uci Apr 12 10:11:54 jow: should (and could) I add uci cli option for using exclusive delta path? Apr 12 10:30:16 wb9688: how do you even keep track of that many? are most of them just every private message ever? Apr 12 10:54:05 ldir: Your 5.10.29 bump is running great here. Apr 12 10:56:37 what's up with this new target which always fails? Apr 12 10:57:45 rmilecki: does it build now? Apr 12 10:58:02 aparcar[m]: i didn't fix anything yet Apr 12 10:58:29 okay... I'm just receiving all these sad docker emails since the build fails... Apr 12 10:59:12 i'll check that fails after I manage to understand UCI cli :| Apr 12 10:59:32 rmilecki: maybe I can help out, what's the problem? Apr 12 10:59:54 aparcar[m]: i don't understand -p and -P options Apr 12 11:00:14 i wanted to have one bash script do uci changes without affecting any other uci cli user Apr 12 11:00:36 so I wanted my app to do things like uci -[pP] /tmp/.foo uci set foo.bar=qwe Apr 12 11:00:59 but -p and -P seem to *add* delta dir path to existing list Apr 12 11:01:12 so it seems uci still looks in /tmp/.uci I guess Apr 12 11:01:36 and I don't understand that -P adds CLI_FLAG_NOCOMMIT Apr 12 11:02:21 it seems I can't do uci -P /tmp/.foo uci set foo.bar=qwe; uci -P /tmp/.foo uci commit because of CLI_FLAG_NOCOMMIT Apr 12 11:02:49 can you point me to the code where you need that function? Apr 12 11:03:12 it's a set of my own bash scripts Apr 12 11:03:15 no upstream code Apr 12 11:03:32 i have UI doing all sort of "uci" cli calls Apr 12 11:03:48 and I want my other bash script to change something in uci *without* interferencing with my UI Apr 12 11:04:01 so I wanted a totally separated UCI cli context for my bash script Apr 12 11:06:05 and that's needed to fix the new target? Apr 12 11:06:55 I'm not sure if that was clear enough? example just in case: Apr 12 11:06:57 1. UI app does: "uci set system.hostname="foo" Apr 12 11:06:58 2. Bash script does: "uci set system.timezone=UTC; uci commit system" Apr 12 11:07:00 I don't want bash script to commit UI changes Apr 12 11:07:20 aparcar[m]: absolutely not :D I'm just busy with this uci problem right now Apr 12 11:07:47 aparcar[m]: i'm focused on it, once I get it done, I'll focus on broken bcm4908 target Apr 12 11:09:53 can't you just tell the bash script to copy current files into /tmp/.special_tmp/ and then use the -c option? Apr 12 11:29:07 aparcar[m]: uh, copying all config files sounds a bit hacky Apr 12 11:29:14 well, not all Apr 12 11:29:19 but still sounds a bit hacky Apr 12 11:41:29 nbd: can you tell me, why do we do that? https://git.openwrt.org/?p=project/uci.git;a=commitdiff;h=cd2883daece34b501ef5e8f5c764fbb162f3aef4 ("cli: don't commit, if the savedir was overwritten") Apr 12 11:43:37 rmilecki: because the savedir override is for overlays Apr 12 11:43:41 that should not be commited into the main config Apr 12 11:44:30 nbd: does it mean i shouldn't use -P for my case? can you see my description up in IRC log? Apr 12 11:49:12 i guess uci will need to be changed Apr 12 11:49:39 nbd: can I use deltas for that though? Apr 12 11:50:13 i guess i still don't fully understand your use case Apr 12 11:50:29 so you want a separate confdir and a separate savedir that behaves like normal uci, but does not touch /etc/config at all? Apr 12 11:50:38 no separated confdir Apr 12 11:50:48 I want 2 apps to operate on the same /etc/config/ set of files Apr 12 11:50:56 both apps use uci CLI tool Apr 12 11:51:04 but once you commit to /etc/config, it'll be visible to the other one as well Apr 12 11:51:08 i want each of app to stash their changes independently Apr 12 11:51:23 right, that's expected Apr 12 11:52:29 so i guess you need to change uci to add a flag like -P which does not set the nocommit flag Apr 12 11:52:38 1. UI app does "uci set system.hostname=foo" *without* commiting - let'ssay that change is *not* ready to be commited Apr 12 11:52:39 2. Bash script does "uci set system.timezone=UTC; uci commit system" - that will commit changes of UI app Apr 12 11:53:00 nbd: yes -P without CLI_FLAG_NOCOMMIT woud work for me I beleive Apr 12 11:53:35 (i don't want bash app to accidentally commit UI *pending* changes) Apr 12 12:53:14 Hi. I got my hands on an mt7622 board that I would like to try to port OpenWrt to. I am not very familiary with the platform, are there any recomended places to start or resources to look at? Apr 12 12:53:53 I have found and looked at Daniel Golles work for E8450, so I have a rough idea of where to start Apr 12 12:57:07 Tha board is running a really old version of u-boot, so my goal includes replacing the bootloader Apr 12 13:01:57 kristrev: you should create dts file and add your dev to 02_network Apr 12 13:02:09 and in .mk Apr 12 13:02:48 this is minimal things to do to get working openwrt on device Apr 12 13:04:51 not best, but example https://github.com/openwrt/openwrt/pull/4070/files Apr 12 13:06:21 Thanks. I have added support for a couple of other boards, so I am aware of that step. I am not so familiar with mt7622 or arm, so I would like to try to do some research before I head too far in the wrong direction :) Apr 12 13:55:41 Build [#45](https://buildbot.openwrt.org/master/images/#builders/17/builds/45) of `ramips/rt305x` failed. Apr 12 13:56:10 Build [#44](https://buildbot.openwrt.org/master/images/#builders/13/builds/44) of `lantiq/xway_legacy` failed. Apr 12 13:58:33 * enyc meows Apr 12 14:00:04 hrrm .. at least one of my Lantiq xrx20 HHv5a OpenWRT is rebooting itself ..... Apr 12 14:00:12 intermittent problem with candelatech firmware, maybe Apr 12 14:00:46 I'm going to have to get the router I have TTL serial debug attached to, back in service, test older Master build, test updated 21.02SNAPSHOT, monitor ........ Apr 12 14:08:56 rmilecki: Unsure how to proceed with this bcm5862x platform issue re: https://github.com/openwrt/openwrt/pull/3996 Apr 12 14:14:01 Basically it is working nicely as is incl VLAN with DSA drivers. Apart from name and using the different DT to the 5301x platform, the b53 swconfig driver isn't 58xx or Serdes compatible which is needed. ar8216 would also need modified to work with b53 vlans even if both the former were fixed. Apr 12 14:36:27 clayface: it's on my list to look at it Apr 12 14:36:34 clayface: right after uci & failing bcm4908 Apr 12 14:59:12 rmilecki: Thanks! Apr 12 16:09:57 rmilecki: nice work on the uci save patch Apr 12 16:10:16 rmilecki: or rather a very good idea Apr 12 16:10:35 jow: "work" is too much for a 3 lines diff ;) Apr 12 16:10:38 but thank you Apr 12 16:10:48 too big word i mea Apr 12 16:11:28 I wonder if it could be even made default Apr 12 16:12:45 jow: without manually specifying -t directory? how? Apr 12 16:13:01 some per-pid directory? Apr 12 16:13:21 can bash get pid of caller? i don't think so Apr 12 16:14:42 PPID? Apr 12 16:16:47 rmilecki: sorry got distracted by a call, yes like PaulFertser suggested Apr 12 16:17:08 using some getppid() dervied save directory by default Apr 12 16:17:49 that could probably break some esotheric code invoking some uci calls in a subshell and some not Apr 12 16:18:06 jow: sounds good, but I still would like to have -t for usages where a single context has different "uci" callers Apr 12 16:18:12 but it'd make the commit operations somewhat safe by default Apr 12 16:18:24 jow: right, for such cases I'd like to have -t still there Apr 12 16:18:26 sure, one could keep -t but also modify the default Apr 12 16:18:37 sounds good to me Apr 12 16:19:09 hmm, potential problem could be leftover garbage though Apr 12 16:19:31 if some broken scripts leave hundreds of uncommitted temporary save dirs lying around Apr 12 16:19:47 oh, right Apr 12 16:20:23 so maybe forget about that braindump of mine Apr 12 16:20:41 your patch is useful as-is Apr 12 16:20:45 ok Apr 12 17:11:41 Happy Monday!!!!! Apr 12 17:12:44 I am looking for a caritative soul to enable back my access to modify the wiki, I think I lost my access due to the hack Apr 12 17:37:27 mgiganto: please tell me your existing nickname and e-mail Apr 12 17:45:48 Thank you PaulFertser, all working now :D Apr 12 18:31:52 looks like a fairly important quoting mishap in openwrt-21.02 https://dpaste.com/C3MZT95JR Apr 12 18:33:02 for the lt_prog_compiler variable in libnfnetlink (I'm guessing) Apr 12 18:39:04 Build [#45](https://buildbot.openwrt.org/master/images/#builders/64/builds/45) of `realtek/generic` completed successfully. Apr 12 18:46:12 the fix for my issue turned out very simple, I hit another issue which I bet is the same. I'll fix the other similar issues and post a patch in a few Apr 12 18:46:25 it's just quotes on the right line of the makefile Apr 12 18:49:16 nevermind, new issue is different Apr 12 18:49:17 Package iptables-nft is missing dependencies for the following libraries: Apr 12 18:49:17 libiptext6.so Apr 12 18:49:55 jow: can you please fix this in master and openwrt-21.02? https://dpaste.com/HYT9FCZUS Apr 12 20:04:52 Zero_Chaos: guidosarducci: libnfnetlink is fixed again Apr 12 20:12:55 Hauke: thanks! Apr 12 21:08:43 xdarklight: should we wait till the next 5.4 stable release to merge the DSA changes? Apr 12 21:41:52 Hauke: I think yes, we should wait. mkresin has patches for 5.10 (as testing kernel version) in his tree already. that way I don't need to duplicate the backports but we simply wait for the next stable release Apr 12 21:54:33 xdarklight: are the problems still seen xrx300 related? Apr 12 21:57:11 Hauke: yes no and maybe. there's this crash log from Aleksander from xRX200: https://pastebin.com/A01Hj6aY (I have never seen this before) Apr 12 21:57:52 Hauke: then there's some people reporting problems with the FritzBox 5490 (xRX200) - I have no idea there yet, I didn't speak with the owner of that device yet Apr 12 21:58:29 Hauke: and then there's various xRX300 issues on which you have commented Apr 12 22:00:02 hmm the crash log from Aleksander loks strange Apr 12 22:13:29 Hauke: just out of curiosity: is the GPHY firmware executed in-place? meaning: we need to have a dedicated chunk of DDR memory for each GPHY instance (like we do have right now) or is only the code in RAM but the "work area" is somewhere in internal SRAM? Apr 12 22:29:18 I think it is executed in place Apr 12 22:40:02 Hauke: makes sense, I think that's the straight forward way to implement it Apr 12 22:43:40 Hauke: this is the PHY11G (and PHY22F) initialization code from AVM: https://pastebin.com/dYbN1S9B - note line 267 and following. they're using a 200ms delay after asserting the reset line and also a 200ms delay after deasserting it. also they re-try multiple times if the PHY shows up on the MDIO bus Apr 12 22:46:27 Hauke: compared to that we're currently missing the 200ms delay after asserting the reset line in the lantiq_gswip.c driver. our deassert delay is 300ms so we should be fine there. also we don't implement any retry logic, but I'd avoid that if possible... Apr 12 22:47:55 Hauke: I also found some file in UGW which also uses a 200ms delay: ifxmips_vr9_gphy.c Apr 12 23:16:47 xdarklight: it looks AVM uses 500ms before and after releasing the reset Apr 12 23:18:16 Hauke: funky, they use different delays in the same driver... Apr 12 23:22:35 looks like they wrere experimenting and at some time it worked ;-) Apr 12 23:24:52 Build [#50](https://buildbot.openwrt.org/master/images/#builders/6/builds/50) of `lantiq/xway` failed. Apr 12 23:25:18 Hauke: so from that guy on the pull request with my 200ms delay patch: "This seems to have at least fixed the first problem! After about 15 router reboots, I haven't seen the inicialization error once" Apr 12 23:33:51 Build [#55](https://buildbot.openwrt.org/master/images/#builders/2/builds/55) of `layerscape/armv7` failed. Apr 13 00:23:22 Build [#45](https://buildbot.openwrt.org/master/images/#builders/13/builds/45) of `lantiq/xway_legacy` completed successfully. Apr 13 00:32:03 Hauke: Appreciate the quick turnaround. Could you also please take a look at https://github.com/openwrt/openwrt/pull/4068? This is similar to a fix you previously made for sunxi, and also needed for 21.02. Thanks. Apr 13 01:56:53 Build [#48](https://buildbot.openwrt.org/master/images/#builders/14/builds/48) of `bcm63xx/generic` failed. **** ENDING LOGGING AT Tue Apr 13 02:59:56 2021