**** BEGIN LOGGING AT Mon Oct 07 02:59:57 2019 Oct 07 03:35:06 mangix: except none of the dcwifi packages are building more than a single package per Makefile unlike lz4 and zstd Oct 07 03:40:10 true. macremapper and mrmctl belong in the same Makefile. I wasn't able to figure out a solution there. I'll thing about splitting up the packages into their respective directories. Oct 07 03:40:23 *think Oct 07 04:44:50 updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html Oct 07 08:01:16 jow: ping Oct 07 08:26:37 aparcar[m]: can you try this https://patchwork.ozlabs.org/patch/1172650/mbox/ ? Oct 07 08:29:31 aparcar[m]: pong Oct 07 08:30:19 jow: do you know why the json buildinfo files are not created? Oct 07 08:30:26 ynezz: thanks will do right now Oct 07 08:30:41 aparcar[m]: no, I have no idea about that Oct 07 08:31:25 jow: I tried it locally and it works just fine, is it possible the buildbots use an old python3 version? Oct 07 08:32:00 uhm, wait - we just switched to python3, there are too old versions of it already? Oct 07 08:32:53 root@e2ea05155c9e:/# python3 -V Oct 07 08:32:53 Python 3.5.3 Oct 07 08:33:02 jow: not sure, python3.7 introduces a lot of stuff and is standard on debian buster Oct 07 08:33:09 okay I'll see if the script works with 3.5.3 Oct 07 08:33:54 aparcar[m]: hi, sent a PM Oct 07 08:34:01 jow: however there is no error indicating all json files would fail, do you have any idea why the checksums don't contain the json files? Oct 07 08:34:17 blogic: ack will read it now Oct 07 08:34:40 .oO(perl -MJSON just works the same since about 15 years already) Oct 07 08:35:10 jow: yea I should learn perl and stick to that... Oct 07 08:35:14 :P Oct 07 08:35:31 I really have no idea about the buildinfo things and why they fail Oct 07 08:35:59 the best advice I can offer is to tun the exact same commands as buildbot Oct 07 08:36:03 buildinfo != json image info M) Oct 07 08:36:05 and see if you can reproduce it Oct 07 08:36:23 well I have no idea about neither Oct 07 08:36:53 jow: I tried (hopefully) that and it worked, however will do so again with the older python3 version, there are like 3 python fails in the buildlog Oct 07 08:37:05 jow: I'm introducing to much new stuff sorry :( Oct 07 08:37:22 https://git.openwrt.org/?p=buildbot.git;a=tree;f=docker/buildslave;h=93c8bd4e10691400aaa86a3e892990566794d24f;hb=cfd720304fb834c2d4981fb15ba8eaee1635458b Oct 07 08:37:27 thats the buildsalve docker file Oct 07 08:39:41 do you mind upgrading to debian 10 ;)? Oct 07 08:40:01 it's pretty much the same as debian 9 I guess Oct 07 08:47:12 I do not plan to Debian 10 just yet Oct 07 08:47:38 I suggest to use the docker image I linked together with the exact command sequence performed by buildbot Oct 07 08:47:46 https://pastebin.com/UitahcFa Oct 07 10:01:49 what is the purpose of the target Makefile field CPU_TYPE (and CPU_SUBTYPE)? Oct 07 10:02:21 Neighbor11111112: iirc it is translated into -mcpu and -march flags for the toolchain Oct 07 10:02:31 jow: ack will do Oct 07 10:02:37 Neighbor11111112: and it is used as architecture identification string for ipk packages Oct 07 10:02:58 jow, thanks yeah I saw that it is part of arch ID Oct 07 10:03:07 good to know about toolchain :) Oct 07 10:04:40 Neighbor11111112: see here for the translation matrix: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=include/target.mk;h=a813ba2d2d87de82b5c9762e8d6000ce424edba2;hb=273a6cb562b1b993666670f32350c6d7ef51b49b#l166 Oct 07 10:05:05 very cool, thanks jow! Oct 07 10:05:12 jow: ack will do Oct 07 10:05:14 jow: ack will do Oct 07 10:05:17 ynezz: patch seems to work, please merge Oct 07 10:05:26 ynezz: patch seems to work, please merge Oct 07 10:06:07 the toolchain will use $(CPU_CFLAGS_$(CPU_SUBTYPE)) as default optimization / target selection flags Oct 07 10:19:14 aparcar[m]: why was the metadata causing repro issues in the first place? Oct 07 10:20:20 karlp: is it causing issues? It's an issue itself that it doesn't do what it's supposed to do Oct 07 10:20:36 so apart from not working I'm not aware of problems Oct 07 10:21:18 the patch description from ynezz is to build factory images from scratch instead of from the sysupgrade images because the sysuprade imgs contain metadtaa causing repro failures. Oct 07 10:21:43 ... implaying that the json metadata at the end is not reproducible Oct 07 10:21:49 *implying Oct 07 10:22:14 is there some dynamic fields such as builder hostname or timestamps in the metadata? Oct 07 10:24:06 which is what should be fixed, not hcanging the order of building, perhaps... Oct 07 10:29:11 jow: now, the problem is you can't change the signature (not json metadata) anymore once the stockimage got some padding at the end as fwtool don't recognize it anymore. at least that's how I understand the error Oct 07 10:30:15 karlp: sorry I thought you've joined in on the python3 issue with json metadata Oct 07 10:30:37 karlp: so is it a problem "rebuilding" the factory image? Oct 07 10:30:42 I guess ynezz has to join in Oct 07 10:35:41 the diff is here https://rebuild.aparcar.org/SNAPSHOT/ath79/generic/openwrt-ath79-generic-ubnt_nanostation-ac-squashfs-factory.bin.html Oct 07 10:36:43 sysupgrade image itself was found reproducible Oct 07 10:36:54 you mean the offset at 00100170 ? Oct 07 10:39:00 this is probably related to the split image fu Oct 07 10:39:32 I mean in the diff I see that the signatures differ, which is execpted due to the use of different certs Oct 07 10:39:46 so that in itself is not a reproducibility issue Oct 07 10:40:39 so how this could happen, that sysupgrade image from the same build is reproducible and factory image based on that same sysupgrade image is not? Oct 07 10:42:51 jow: my current rebuild script builds with a "random" key and then uses fwtool re replace it with the origin signature Oct 07 10:43:06 this way the reproducible script keeps working once all openwrt images are actually signed Oct 07 10:43:15 but this fails for the padded factory image Oct 07 10:43:33 ah, thats the answer, ok Oct 07 10:43:39 therefore it appears to have a bad signature attached, which is in fact just a failed replacement Oct 07 10:43:53 okay, now I understand Oct 07 10:44:12 so the problem is that the replacement stumbles over padding? Oct 07 10:44:22 because the padding is added after the signature? Oct 07 10:44:44 [sysupgrade-img-contents][signature][factory-padding] Oct 07 10:45:34 probably fwtool would need to look further then just X bytes from the end of the file Oct 07 10:45:40 jow: this is how I understand the issues Oct 07 10:46:01 yeah, that sounds like fwtool needs a fix or better heuristics Oct 07 10:46:45 make it skip continuous 0xff or 0x00 byte sequences from the end of the file, then set the search window to look for a signature within Oct 07 10:46:53 fine for me, as long as inserting the origin signature with the final padding works Oct 07 10:47:07 right now it probably just looks within a fixed amount of bytes at the end of the file Oct 07 10:47:07 well, but it wont fix the image header at 0x00100170 as you've pointed out already Oct 07 10:47:37 the image header differs because it encodes the signature length? Oct 07 10:47:52 it's partition len I would guess, so yes Oct 07 10:48:10 hmm Oct 07 10:48:30 and the signature is part of the partition len to ensure that it is erased as well? Oct 07 10:49:16 to me it looks as if two distinct fixes are needed Oct 07 10:49:26 1) better fwtool signature search heuristics Oct 07 10:49:50 2) pad the signature before it is factored into the partition size calculation Oct 07 10:50:31 I don't know offhand how large a normal, non fake cert signature can become, maybe aparcar[m] cal look this up Oct 07 10:50:59 but I guess rounding it up to a multiple of 1024 byte or so will probably work Oct 07 10:51:03 jow: no clue... I'm not that familiar with ed25519 signatures Oct 07 10:51:21 aparcar[m]: these tend to be fixed in length Oct 07 10:51:47 aaand I need to sleep. Oct 07 10:51:48 but there are some variable parts such as the comments of the keys, and the revision identifier Oct 07 10:52:09 I'm off for now, cu "tonight" I guess Oct 07 10:52:14 #define METADATA_MAXLEN 30 * 1024 Oct 07 10:52:20 jow: I'll update you on the buildot issue Oct 07 10:52:25 #define SIGNATURE_MAXLEN 1 * 1024 Oct 07 10:52:36 FYI, fwtool will cut 16 bytes from image if output to stdoutis used and there is no metadata Oct 07 10:52:52 so a third bug :) Oct 07 10:52:58 seems we should look into fwtool Oct 07 10:59:13 good, this package is one of 60+ on my todo list, because it's having source in the tree (package/src) Oct 07 10:59:26 this is quite PITA for testing Oct 07 11:00:48 as one would need to clone openwrt tree, then shuffle with dir paths etc. Oct 07 11:01:29 so I'm wondering how to approach this Oct 07 11:02:57 ynezz: well in principle it should be no problem to move each src/ package to a separate project repo Oct 07 11:03:21 in practise I somehow like it that such tool sources are direct part of the tree Oct 07 11:03:37 especially if they're 100% openwrt specific Oct 07 11:04:19 given that some tools (fstool etc.) are external repos though, I'd say it makes sense to migrate the remaiining ones to external repos too, for consistency Oct 07 11:05:56 what's the difference between procd and fwtool ? Oct 07 11:07:09 I'm not strongly against single monorepo (which would make package bumps easier for example) Oct 07 11:09:49 on the other hand it's probably going to make it harder for downstream projects as well (packaging etc.) Oct 07 11:10:34 CI is going to be more complex as well Oct 07 11:12:15 ynezz: I guess the main difference is size and anticipated complexity Oct 07 11:12:48 if a tool is expected to remain simple and rarely touched, maybe even consiting of a sole .c file, then fetching it from an external repo intuitively feels like overkill Oct 07 11:13:06 fyi, kernel bumps pushed to staging Oct 07 11:15:03 jow: but once you would like to add CI testing for example? from the start with compile tests, static code analyzer, later some unit and run time test? Oct 07 11:15:42 ynezz: then the simple shortcut taken becomes a burden and things need to be migrated, which we're discussing now Oct 07 11:16:17 usually, at the time when these tools were introduced, the CI was buildbot. Static analyzers and unit tests were after-thoughts, if at all Oct 07 11:17:00 good, so I'll start and ask you kindly for libnl-tiny project Git repo as I would like to move it out from the tree Oct 07 11:18:42 odhcpd depends on it, I would like to focus first on the network facing stuff Oct 07 11:19:05 btw, when you extract the src/ contents into seaprate repos, can you try to retian the history? Oct 07 11:19:09 I've already factored it out https://gitlab.com/ynezz/openwrt-libnl-tiny Oct 07 11:19:34 ah great, finally someone who does it right :) Oct 07 11:20:58 ynezz: repo should be initialized Oct 07 11:21:13 that was fast, thanks! Oct 07 11:27:03 speaking about C unit tests, I haven't seen any in the current C projects, which makes me wonder how to approach them (would like to write some soon as well) Oct 07 11:27:51 should we simply stick to simple CTest and assert() stuff (which might work for most stuff) or start using some (simple) testing framework/tool Oct 07 12:45:01 jow: FATAL: R any projects/libnl-tiny ynezz DENIED by fallthru Oct 07 12:45:06 am I holding it wrong? Oct 07 12:49:42 ah, s/projects/project/ Oct 07 13:01:05 Are they any news about OpenWrt 19.07? Openssl support for 1.0.2 should be supported until the end of this year when we are talking about OpenWrt 18.06 Oct 07 13:01:52 Can be this commit backported to OpenWrt 18.06? https://github.com/openwrt/openwrt/commit/51c094e7032b45522cc7060858196881e161e615 It is in OpenWrt 19.07 and master. It make sense to have it also in stable release. Oct 07 13:22:04 any ideas if mt7621 devices works fine with 19.07 now? Oct 07 13:22:12 I would rebuild and update if so Oct 07 14:03:59 Noltari: btw, --html-dir is not a valid option for dump1090 Oct 07 14:04:07 it breaks the init script, at least for 3.7.2 Oct 07 15:15:23 nbd: Any idea where this issues could be originated? [18027.947643] ath: phy0: unsupported hw bitrate detected 0x1b using 1 Mbit Oct 07 15:15:51 I'm seeing these on a daily base on ar9220 and ar9530 chipsets (ath9k) Oct 07 15:16:00 at this point, the radio stops receiving most of the time Oct 07 15:16:13 rc_stats of all stations shows that rate control is stuck at MCS0 Oct 07 16:26:51 gweentea: any particular issue you have in mind? I have been running openwrt 19.07 on my7621 without any obvious issues Oct 07 16:27:10 okay, then ill be running it soon Oct 07 16:27:16 just want to see a heads up Oct 07 16:27:19 thank you Oct 07 16:29:44 np Oct 07 16:29:48 flow offloading even works again now Oct 07 19:41:53 blogic: ping Oct 07 19:45:46 hmm. recent HEAD has a kernel config problem for espressobin Oct 07 20:05:24 ynezz: ping Oct 08 01:39:11 Recently I encountered a issure: ubus_add_object failed, return UBUS_STATUS_INVALID_ARGUMENT, can only restart ubusd to recover, I can not confirm the reason, because only once, someone encountered such a issure? **** ENDING LOGGING AT Tue Oct 08 02:59:57 2019