**** BEGIN LOGGING AT Tue Mar 03 02:59:59 2020 Mar 03 04:10:14 trying to build 19.07.2, 'make', 'make -j2', 'make -j4' or whatever will immediately use up all my swap partitions and fork 20+ gcc tasks, make the build machine unusable, this never happened before even with 'make -j6', what am I doing wrong? Mar 03 04:42:55 jow: any tutorial on luci js api yet? Mar 03 04:44:20 * rr1231 still can't build 19.07.2 as 'make' will halt my PC, it uses all my cpu and swap even with 'make -j1'??? never saw this in old builds Mar 03 04:49:46 rr1231: have you tried master? Mar 03 04:52:11 not yet Mar 03 04:54:30 fwiw, i haven't noticed that behavior Mar 03 04:54:50 what kind of build system is it? Mar 03 04:55:22 ubuntu 18.04 64bit, used it to build 19.07 and 18.06 in the past, not sure what changed, will dig in tomorrow Mar 03 04:56:07 power cycled it 3 times due to the make Mar 03 04:56:56 i only build master, so no direct knowledge of release versions Mar 03 05:39:21 build #252 of mpc85xx/p1020 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fp1020/builds/252 Mar 03 07:04:18 morning uys Mar 03 07:04:22 *guys Mar 03 07:09:23 hello, i'm creating new package from c++14 sourcetree but cannot figure out if there's a workaround for failing check with std::weak_ptr std::move operator. added dependency on libstdcpp6 still no progress. need help Mar 03 07:45:21 ynezz: i'm working on that mtd regression, i just realized noone provided a single dmesg while complaining about that :/ Mar 03 07:45:44 ynezz: i commented with log request, as soon as I get one, I'll be back working on that Mar 03 08:11:47 rmilecki: no worries, really, I've just withdrawn that revert patch (which I've prepared as workaround as I couldn't reach you otherwise) Mar 03 08:44:54 jow: do you know by any change why are the image generation related errors being ignored via .IGNORE? Mar 03 08:45:01 s/change/chance/ Mar 03 08:45:57 its just some kind of workaround for some suboptimal target image generation? Mar 03 08:48:51 it was introduced in a1b725bba5346a3f10e5569b4f19ea51b7743b9d "build: ignore errors on copying firmware binaries from $(KDIR) to $(BIN_DIR)" Mar 03 08:48:59 but missing commit description :] Mar 03 08:52:51 hm, I probably see the reason, image generation code is being abused for artifacts, like DTBs Mar 03 08:53:06 IMAGE/dtb := install-dtb Mar 03 08:54:01 make[5]: [/imx6/generic/openwrt-imx6-ventana-squashfs-dtb] Error 1 (ignored) Mar 03 09:52:07 jow: re that weird js _ crash yesterday, got them to try it again in an incognito window, worked fine, so some caching somewhere that wasn't being flushed somehow :| Mar 03 10:07:10 karlp: hm okay, thanks for the info Mar 03 12:05:06 build #297 of pistachio/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/pistachio%2Fgeneric/builds/297 Mar 03 12:30:52 ynezz: ^^^^ so now it builds! Mar 03 12:41:10 ldir: finally! Mar 03 12:41:11 :) Mar 03 15:17:27 offtopic, but does anyone have experience with packet injection to an ar9271 (ath9k-htc)? Mar 03 15:18:24 * russell-- trying to figure out how to change transmit rates, but seems stuck on 1Mbps Mar 03 15:29:46 19.07.2 is definitely dead on 'make' as it uses all of my 32GB swap space in no time, something is terribly wrong Mar 03 15:30:35 rr1231: see if it also does that with master Mar 03 15:30:50 testing now Mar 03 15:41:06 rr1231: whats in ps? Mar 03 15:41:49 are you building with all packages enabled? Maybe random junk like nodejs is gobbling up ressources Mar 03 15:54:52 jow: no but I do have a few extra packages, I'm debugging, have not built since last Nov. top showed 30+ gcc sessions running even with -j1 Mar 03 15:55:22 it saturates the machine before it gets into packages Mar 03 16:33:13 here is the "fix": after 'make distclean' everything goes back to normal, don't know what is the root cause Mar 03 16:49:37 rr1231: had you tried a make dirclean ? Mar 03 16:51:42 ldir: nope... Mar 03 16:52:03 that's a slightly less destructive 1st step Mar 03 16:52:15 ie you get to keep your config Mar 03 16:52:33 yes, I do have script to keep config etc, distclean makes me less nervous Mar 03 16:53:22 the whole thing builds from scratch in 25 minutes so it's OK Mar 03 16:53:59 I've also had to do make -C scripts/config clean Mar 03 16:54:16 for me I never need to do that Mar 03 16:54:17 if a make dirclean didn't cure the wonkyness Mar 03 16:56:45 and by wonkyness doing something insane like getting a container based buildroot to build my normal tree.... and then forgetting that the resultant utilities will be built for a different OS :-) Mar 03 17:48:22 what's the difference between qos-scripts vs sqm-scripts, my 19.07.2 failed : satisfy_dependencies_for: Cannot satisfy the following dependencies for qos-scripts Mar 03 17:48:38 also satisfy_dependencies_for: Cannot satisfy the following dependencies for openvpn-openssl: libcap Mar 03 17:48:56 both complains about libcap Mar 03 17:50:23 hold on, might be my mistake, sorry Mar 03 17:51:01 i share luci/packages/etc between 19.07/18.06 build and likely 19.07 is mixed with 18.06 branches :( Mar 03 19:04:22 1907 was a big change over 18.06, especialyl in luci... Mar 03 19:05:05 yes after all switched to 19.07 branches it builds without issues, finally :) Mar 03 20:07:40 ynezz: as indicated in the PR, the rebased (919c286) ipq806x/ kernel-5.4 patchset now works fine on the nbg6817 (pulled into r12425-d83150e3fb) - Tested-by: Stefan Lippers-Hollmann [ipq8065/ nbg6817] Mar 03 20:32:27 pkgadd: ok, thanks Mar 03 20:37:03 ynezz: thanks for your response Mar 03 20:40:28 I relly wonder whats the JSON core problem, it always appears at different targets. If it's an issues with the Python JSON library it's a serious bug ☹︎ https://paste.debian.net/1133325/ Mar 03 20:55:20 aparcar[m]: https://cdn.openwrt.org/snapshots/targets/ramips/mt7620/openwrt-ramips-mt7620-netgear_ex6130.json has a trailing `HOT"\n}` Mar 03 20:55:29 how do you write those files? Mar 03 20:56:21 it looks a bit as if a shorter string is written into a slightly larger existing file Mar 03 20:56:37 withiut properly truncating or deleting the file before Mar 03 21:00:05 jow: thats what I though. It is using https://docs.python.org/3/library/json.html#json.dump However a) I'd think json.dump truncates files itself and b) the files should be deleted anyway Mar 03 21:00:18 open(..., "w") truncates **** BEGIN LOGGING AT Tue Mar 03 21:03:40 2020 Mar 03 21:03:43 I'd say make is invoking your json_add_image_info.py concurrently Mar 03 21:03:53 in openwrt.git/scripts/json_add_image_info.py Mar 03 21:03:56 and its not protected by flock Mar 03 21:04:05 or any other means to synchronize access Mar 03 21:04:10 however the script is currently rewritten which should already fix the problem Mar 03 21:04:23 it also calculates its destination json file internally, make is not aware of that Mar 03 21:04:44 the json dest file should probably be a proper make rule goal Mar 03 21:05:25 I think this is similar to what ynezz suggested, I'll try to implement that Mar 03 21:07:19 something like Mar 03 21:07:21 $(BIN_DIR)/$(IMAGE_PREFIX).json: $(KDIR)/tmp/$(call IMAGE_NAME,$(1),$(2)): Mar 03 21:07:38 [...] $(TOPDIR)/scripts/json_add_image_info.py $$@ Mar 03 21:07:51 and let json_add_image_info.py write to argv[1] Mar 03 21:08:05 why not to stdout? Mar 03 21:08:19 yeah, sure. stdout would work too Mar 03 21:08:29 [...] $(TOPDIR)/scripts/json_add_image_info.py > $$@ Mar 03 21:08:38 problem is that it is annoying to handle failure cases Mar 03 21:09:11 (leaving zero-byte junk behind if the .py crashes) Mar 03 21:10:32 hrm cmake + ninja is faster than cmake + makefiles. wonder if this should be added... Mar 03 21:10:45 so write to tmp and mv tmp $$@ Mar 03 21:10:47 so it should probably be something along the lines of [...] $(TOPDIR)/scripts/json_add_image_info.py > $$@.tmp && mv $$@.tmp $$@ || rm -f $$@.tmp Mar 03 21:11:16 and you need to propagate the filaure Mar 03 21:11:27 oh, yea, fun Mar 03 21:11:34 so [...] $(TOPDIR)/scripts/json_add_image_info.py > $$@.tmp && mv $$@.tmp $$@ Mar 03 21:11:51 || { rc=$?; rm -f $$@.tmp; exit $rc } Mar 03 21:11:59 or $$rc or $$$$rc Mar 03 21:12:13 I think its cleaner to let the python script write the file :) Mar 03 21:12:19 love it Mar 03 21:12:37 yep, agree Mar 03 21:13:19 but it still doesn't solve the .py crashes Mar 03 21:13:21 :) Mar 03 21:13:26 is it crashing? Mar 03 21:13:31 okay will do. Python also support "atomic" file operations via os.rename, so should I use a tempfile for that? If I understand the new make approach correct there won't be any parrallel file write? Mar 03 21:14:34 aparcar[m]: writing to a tempfile and atomically rename is always a good idea Mar 03 21:14:45 ack Mar 03 21:14:50 that avoids zero-byte-junk if the operation is interrupted Mar 03 21:15:11 thanks Mar 03 21:15:35 do you have an idea regarding the versions.json file? This is also relevant for the luci-app-attendedsysupgrade Mar 03 21:16:03 as for the parallel writes: yes, I think as soon as make is aware of the .json goal and its prereq, the dependencies should be properly serialized Mar 03 21:16:54 I didn't follow the version.json topic yet, have no opinion on it yet **** BEGIN LOGGING AT Tue Mar 03 22:17:31 2020 Mar 03 22:36:14 jow: still around? Mar 03 22:36:36 Makefile:84: warning: overriding recipe for target '/home/a/src/openwrt/openwrt/bin/targets/ath79/generic/openwrt-ath79-generic-adtran_bsap1800-v2.json' Mar 03 22:36:36 Makefile:84: warning: ignoring old recipe for target '/home/a/src/openwrt/openwrt/bin/targets/ath79/generic/openwrt-ath79-generic-adtran_bsap1800-v2.json' Mar 03 22:36:36 And the script isn't run at all. How do I actually trigger the script? **** BEGIN LOGGING AT Tue Mar 03 22:49:40 2020 Mar 04 02:47:35 hello Mar 04 02:48:08 I'm trying to install some packages with opkg : https://paste.debian.net/1133358/ Mar 04 02:49:13 but it seems that there are several packages included in http://downloads.openwrt.org/snapshots/packages/mipsel_24kc/luci/Packages but missing from the binary repo Mar 04 02:50:51 I also checked and the binaries are available for another archs like http://downloads.openwrt.org/snapshots/packages/x86_64/luci/luci-app-ddns_git-20.059.58326-516e032-1_all.ipk Mar 04 02:51:19 but http://downloads.openwrt.org/snapshots/packages/mipsel_24kc/luci/luci-app-ddns_git-20.060.72422-2c4ba6e-1_all.ipk throws a 404 Mar 04 02:53:32 btw why they are not at the same version ? **** ENDING LOGGING AT Wed Mar 04 02:59:57 2020