**** BEGIN LOGGING AT Tue Apr 13 02:59:56 2021 Apr 13 03:00:05 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_bcm47xx.html has been updated. (100.0% images and 98.3% packages reproducible in our current test framework.) Apr 13 06:32:50 jow: is there anything weird about .init scripts and how config_get works, etc.? I have a global called CONFIG_FAIL=0 set at the top of the script... a helper function sets it to 1 if there are failures... but by the time the script returns back to start_service() from where it called config_foreach, the variable is zero'd again. like the scope where it had been set to 1 disappeared. Apr 13 06:33:18 See https://github.com/openwrt/packages/pull/15406/files for an example of what I'm doing... Apr 13 08:35:22 Build [#47](https://buildbot.openwrt.org/master/images/#builders/17/builds/47) of `ramips/rt305x` completed successfully. Apr 13 08:46:03 philipp64_: parse_esp_proposal() for example is only invoked once from a subshell `local esp_proposal="$(parse_esp_proposal "$1")"` Apr 13 08:46:21 philipp64_: so whetever it (indirectly) exports will never end up in the global script scope Apr 13 08:46:38 philipp64_: you should restructure these functions to return values through export Apr 13 08:46:53 e.g. parse_esp_proposal esp_proposal "$1" Apr 13 08:46:59 and within parse_esp_proposal(): Apr 13 08:47:05 local dest_variable=$1 Apr 13 08:47:09 local proposal=$2 Apr 13 08:47:13 ... Apr 13 08:47:38 export -n "$dest_variable=whatever string value you want to return" Apr 13 08:48:01 then you can use $esp_proposal outside the function Apr 13 08:48:46 same for parse_ike_proposal Apr 13 09:01:15 Build [#51](https://buildbot.openwrt.org/master/images/#builders/6/builds/51) of `lantiq/xway` completed successfully. Apr 13 09:28:49 Build [#56](https://buildbot.openwrt.org/master/images/#builders/2/builds/56) of `layerscape/armv7` completed successfully. Apr 13 09:33:03 stintel: what do we really need crypto-hw-ccp for? Apr 13 09:33:34 stintel: it seems to be some driver for two hisilicon SoCs Apr 13 09:34:08 rmilecki: https://gist.github.com/stintel/4cec0cb9913fa75eb0d6836869a34758 Apr 13 09:34:18 rmilecki: it's used on AMD CPUs afaik Apr 13 09:35:17 stintel: does AMD has any ARM64 CPUs? Apr 13 09:36:08 stintel: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/crypto/hisilicon/Kconfig#n3 Apr 13 09:37:25 oh, sec, I pointed a different Kconfig symbol Apr 13 09:37:28 let me recheck that Apr 13 09:44:53 rmilecki: that gist is from an APU2 Apr 13 10:02:17 Build [#26](https://buildbot.openwrt.org/openwrt-21.02/images/#builders/13/builds/26) of `ramips/rt305x` failed. Apr 13 11:15:37 Build [#49](https://buildbot.openwrt.org/master/images/#builders/9/builds/49) of `lantiq/ase` failed. Apr 13 11:16:01 Build [#53](https://buildbot.openwrt.org/master/images/#builders/16/builds/53) of `ath79/mikrotik` failed. Apr 13 11:16:03 Build [#51](https://buildbot.openwrt.org/master/images/#builders/48/builds/51) of `bcm47xx/generic` failed. Apr 13 11:25:10 ynezz: i see some out of space issues with buildbot Apr 13 11:25:46 ynezz: i don't know if it's related, but we have problem with ath79 images for some device growing huge Apr 13 11:26:02 Re: firmware-utils: mkmylofw broken since 9. Apr 2021 Apr 13 11:26:39 http://lists.openwrt.org/pipermail/openwrt-devel/2021-April/034685.html Apr 13 11:27:57 so that may be my fault, I'm not sure how to solve that properly yet Apr 13 12:06:32 Build [#49](https://buildbot.openwrt.org/master/images/#builders/14/builds/49) of `bcm63xx/generic` completed successfully. Apr 13 12:23:39 aparcar[m]: can you check diskspace on sunshine builders? Apr 13 12:24:59 rmilecki: revert? :p Apr 13 12:25:15 ynezz: i prefer fix Apr 13 12:27:07 how is revert preventing you from fixing it properly? Apr 13 12:27:42 because my change is ok Apr 13 12:27:47 it should be there Apr 13 12:27:53 it exposed bug in another piece of code Apr 13 12:28:10 it also fixed warnings in 3 other files Apr 13 12:28:21 ok, but do you realize, that every ath79 build now results in 176GB of disk usage Apr 13 12:28:44 then this huge images are being transfered to downloads.openwrt.org Apr 13 12:28:56 then likely mirrored to mirrors Apr 13 12:29:01 https://buildbot.openwrt.org/master/images/#/builders/1/builds/61/steps/52/logs/stdio Apr 13 12:29:54 oh, it thought all ath79 generic will just fail Apr 13 12:31:27 yep, seems so, there is fortunately timeout "command timed out: 1200 seconds without output running [b'make', b'-j8', b'target/install', b'V=s'], attempting to kill" Apr 13 12:32:09 I would simply revert the offending commit and tried to fix it properly in the meantime Apr 13 12:32:31 it's broken since April 8th Apr 13 12:33:05 you sure about that date? Apr 13 12:33:09 i pushed that on 9th Apr 13 12:33:27 it takes some time to build all the targets Apr 13 12:33:49 so the latest build can be found here https://downloads.openwrt.org/snapshots/targets/ath79/generic/ Apr 13 12:34:05 ah, the latest success you mean Apr 13 12:34:30 curl https://downloads.openwrt.org/snapshots/targets/ath79/generic/version.buildinfo -> r16450-d92a9c97bf Apr 13 12:35:05 this was last successful build Apr 13 12:41:47 BTW those firmware-utils should be probably factored out into separate Git repository and guarded by CI, otherwise it's going to bitrot after some time Apr 13 12:42:53 we've started working on this with ldir some time ago https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=shortlog;h=refs/heads/wip/firmware-utils-fixes but as always got distracted :p Apr 13 12:44:54 ideally having some unit tests in place first, so the good/working output is captured and we can assure, that the fixes doesn't produce regressions Apr 13 12:45:01 a lot of work, I know :) Apr 13 12:49:26 ynezz: testing a fix Apr 13 12:49:47 ynezz: wow, i didn't know about that work on firmware-utils you did Apr 13 12:59:51 ynezz: I agree that firmware utils should be moved into a separate repo Apr 13 13:00:33 ynezz: and maybe reconsider on a case-by-case basis if a given image util really needs to be implemented in C or if it can be done equally well in Python or so Apr 13 14:28:40 Hi. I am trying to bring up an mt7622 and has managed to make some progress, but managed to get properly stuck and wondered if anyone can help Apr 13 14:29:47 The board can boot from an sdcard, so I am currently basing my work off of Banana Pi (just to see if I can get something working). The kernel loads, but the root device can't be found Apr 13 14:30:31 The list of available partitions is empty, which strikes me as a bit strange as uboot is able to see all the partitions on the sdcard Apr 13 14:30:55 Are there any typical rookie mistakes anyone is aware of that could be the cause of my problem? Apr 13 14:34:00 kristrev: Did you also look at the bananapi forum? http://forum.banana-pi.org/c/Banana-Pi-BPI-R2 Apr 13 14:35:39 Rene__: No, I will do that and see if anyone has encountered similar issues Apr 13 14:35:43 Thanks Apr 13 14:43:43 The board only came with a broken image, so no reference there either :) Apr 13 14:47:20 ah, I think the forum can help you to get a working image. Also Frank has an active kernel development with many branches on his github https://github.com/frank-w/BPI-R2-4.14/commits/5.10-hnat Apr 13 14:49:04 I will ask him. This is not the Bpi R64 btw, it is a different board. R64 only seemed like the easiest place to start :) Apr 13 15:46:00 stintel: are you ok with the [PATCH] kernel: limit crypto-hw-ccp to the x86 Apr 13 15:46:30 I'm getting 'no rule to make target' on both xtables-addons and mac80211, been trying to figure this out off and on for a couple weeks... does anyone have any clues for me? https://pastebin.com/BVQDQaKk Apr 13 15:52:58 rmilecki: sure. I would nit about making it one DEPENDS:= \ and then put each of them on a single line, in alphabetical order, so it's a bit cleaner Apr 13 15:53:16 stintel: sure, i can do that Apr 13 15:53:18 thanks Apr 13 15:53:23 Build [#47](https://buildbot.openwrt.org/master/images/#builders/64/builds/47) of `realtek/generic` failed. Apr 13 15:55:35 rmilecki: I was meaning to reply but got distracted with work again Apr 13 15:55:42 stintel: np :) Apr 13 15:59:04 rmilecki: and I would prefer that be 2 different commits too, so one cosmetic, and another one that adds the new dep Apr 13 16:00:38 stintel: ok Apr 13 16:34:39 netprince_: I guess it is related to libelf Apr 13 16:34:48 netprince_: and kernel stack protection Apr 13 16:35:57 netprince_: try package/mac80211/compile V=sc see if the gcc command lines are printed Apr 13 16:37:28 jow: thanks for the response... doing it now Apr 13 16:46:37 jow: https://pastebin.com/dwEfXYgx Apr 13 16:57:07 that output is even more confusing to me Apr 13 17:02:21 nbd: jow: i'm planning to push [PATCH uci] cli: add option for changing save path Apr 13 17:28:39 netprince_: hmm Apr 13 17:31:33 netprince_: can you repeat a make package/mac80211/{clean,compile} V=sc after running export KBUILD_VERBOSE=1 in the same shell? Apr 13 17:32:09 yes, will do Apr 13 17:59:14 jow: sorry for the delay: https://pastebin.com/ZFYhN4dM Apr 13 18:04:39 netprince_: hmm, still inconclusive unfortunately Apr 13 18:05:39 netprince_: the last time I encountered this, it turned out to be an issue with kbuild picking up a wrong libelf which then internally caused a failure cascade Apr 13 18:05:52 let me try to recall the details Apr 13 18:06:12 jow: my system details if that helps: Linux buildroot3 5.4.0-70-generic #78-Ubuntu SMP Fri Mar 19 13:29:52 Apr 13 18:10:24 netprince_: okay, so in my case it was this: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=f3ab336d7ceda929dc8dc4a8b09a9552dc6be0b1 Apr 13 18:10:44 netprince_: x86/64 kernel, had stack validation enabled, which in turn requires libelf at build time Apr 13 18:11:13 libelf in turn was taken from openwrt's tools/ but it produced preproprocessor warnings which caused kbuild to trip up due to -Wundef + -Werror Apr 13 18:11:22 I build for several other targets, I only have this trouble with x86/64, so perhaps you are right? Apr 13 18:11:58 hm wait, in the commit I linked I prepared our shipped libelf to be suitable for kernel building Apr 13 18:12:13 the root cause was openwrt kernel kbuild incorrectly picking up a host libelf Apr 13 18:12:37 which in turn was broken, failing the kernel build Apr 13 18:13:40 since tools/libelf was recently dropped with "bf4aa0c6a2 tools/libelf: remove unneeded host library" I guess the original regression crept back in Apr 13 18:14:11 kbuild now likely picks up broken system libelf again (the one exhibiting the CPP undefined macro warnings or another -Werror incompatible quirk) Apr 13 18:14:46 so to summarize: Apr 13 18:15:05 until recently we used or own tools/libelf and made sure that the kernel build uses it Apr 13 18:15:20 tools/libelf was recently dropped as "uneeded" Apr 13 18:15:56 now we rely on the host system to provide a sane libelf (it has been made a build prereq since then) Apr 13 18:16:17 if the host libelf does not happen to be "sane", x86/64 kernels with enable stack protector cannot be built anymore Apr 13 18:21:44 netprince_: could you pastebin your /usr/include/gelf.h ? Apr 13 18:22:38 there is no /usr/include/gelf.h on the build system Apr 13 18:23:53 find / -name "*gelf.h*" -print 2>/dev/null only shows a few matches in my build_dir Apr 13 18:24:08 netprince_: and /usr/include/libelf.h ? Apr 13 18:25:09 does not exist, search only finds a few matches in my build_dir Apr 13 18:25:46 maybe this is your issue then. COuld you try to install your Distro's equivalent of `libelf-dev` ? Apr 13 18:25:56 yes Apr 13 18:27:08 if you didn't already did it, a dirclean/clean might be in order as well to get rid of former shipped libelf stuff in staging_dir/host Apr 13 18:27:22 ok Apr 13 18:29:17 installed and building from scratch... Apr 13 18:29:29 I did run a 'make prereq' when I setup this system Apr 13 18:30:14 I might have lied about the prereq Apr 13 18:30:35 I assumed it was added as prereq but apparently not Apr 13 18:31:26 no problem, thanks for the help, I'll report in how it builds in a few minutes Apr 13 18:31:59 commit bf4aa0c6a2f57951f995b2ac6f394c45ac852b9d claimed that libelf is alredy a build system prereq Apr 13 18:32:08 but that was based on random wiki instructions Apr 13 18:32:20 seems it is not actually encoded in include/prereq-build.mk Apr 13 18:43:10 jow: doh! thanks!! Apr 13 18:55:21 jow: build complete, that fixed the issue, thats a big relief thanks again Apr 13 21:33:18 Build [#50](https://buildbot.openwrt.org/master/images/#builders/9/builds/50) of `lantiq/ase` completed successfully. Apr 13 22:07:25 Build [#62](https://buildbot.openwrt.org/master/images/#builders/1/builds/62) of `ath79/generic` completed successfully. Apr 13 22:40:25 blogic: can you please take care of this patch: https://patchwork.ozlabs.org/project/openwrt/patch/20210313165419.10713-1-bjorn@mork.no/ Apr 13 23:21:59 Build [#52](https://buildbot.openwrt.org/master/images/#builders/48/builds/52) of `bcm47xx/generic` completed successfully. Apr 13 23:25:44 Build [#53](https://buildbot.openwrt.org/master/images/#builders/22/builds/53) of `ipq40xx/generic` completed successfully. Apr 14 01:02:50 jow: a prereq check for host libelf-dev is part of PR https://github.com/openwrt/openwrt/pull/3855 and would catch the cryptic problem encountered by netprince_ . Apr 14 01:48:57 Build [#10](https://buildbot.openwrt.org/master/images/#builders/71/builds/10) of `bcm4908/generic` completed successfully. **** ENDING LOGGING AT Wed Apr 14 02:59:56 2021