**** BEGIN LOGGING AT Thu Dec 26 02:59:57 2019 **** BEGIN LOGGING AT Thu Dec 26 07:30:56 2019 **** BEGIN LOGGING AT Thu Dec 26 07:43:32 2019 Dec 26 09:58:44 what does it take to get a draft 802.11ax document? Dec 26 10:05:03 looks like i could buy draft D6.0 from november for $400 Dec 26 11:40:07 build #235 of lantiq/ase is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fase/builds/235 Dec 26 12:05:56 jow: I'm getting a compile error related to luci which other people are also reporting in the forums: https://pastebin.com/XyC2QCEg Dec 26 12:06:48 build #235 of sunxi/cortexa53 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/sunxi%2Fcortexa53/builds/235 Dec 26 12:06:51 jow: possible culprit can be found in this forum topic: https://forum.openwrt.org/t/feeds-luci-modules-luci-base-host-compile-error/51158 Dec 26 12:16:39 russell--: normally the ieee documents are published for free 6 months after the final was accnounced, but I think ax is not yet final. Dec 26 12:19:28 build #236 of at91/sam9x is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/at91%2Fsam9x/builds/236 Dec 26 12:20:38 ynezz: thanks for pushing the libubox changes, will you also push the fixes to 19.07 and 18.06? Dec 26 12:20:54 should we just update to the most recent versions for 19.07? Dec 26 12:21:12 for 18.06 I would prefer smaller patches Dec 26 12:24:08 Hauke: I'm just waiting for some feedback on master, then I plan to cherry-pick those fixes to 19.07, I've no plan/time for 18.06 Dec 26 12:25:21 ok Dec 26 12:45:15 build #232 of brcm47xx/mips74k is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/brcm47xx%2Fmips74k/builds/232 Dec 26 13:07:03 Hm, just updated to master and building without luci I get successfull touching build_dir/hostpkg/luci-base-git-19.359.63125-8362ab8/.prepared9d0ed3ba96712e4bf454955e221fe150_6664517399ebbbc92a37c5bb081b5c53 and then touch build_dir/hostpkg/luci-base/.configured fails right away because luci-base dir doesn't exist. Dec 26 13:57:51 Hi !I'm trying to build a python3 package with the SDK (using docker SDK image from https://hub.docker.com/r/openwrtorg/sdk/tags?page=1&name=ipq40xx-generic-18.06.5) Dec 26 13:57:54 Compilation is failing while building python3 ( "make[3]: *** [Makefile:302: /home/build/openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/Python-3.6.9/.built] Killed"). Dec 26 13:57:58 (Whenever I build my package it wants to also build (27) dependents packages, among which 'python3') Dec 26 13:58:01 Questions: 1) Is it necessary to rebuild all dependent packages (with the SDK) ; or is there another way that have all the (binaries, libraries, build artefacts...) present so that I can "just" build my package, and not other (already built by the buildbots) packages ? Dec 26 13:58:05 2) Anybody having this error during 'python3' build ? (ipq40xx-generic-18.06.5) ( "make[3]: *** [Makefile:302: /home/build/openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/Python-3.6.9/.built] Killed") Dec 26 13:58:28 not enough RAM? Dec 26 13:59:10 Could be (I have 4GB), is there a known requirement somewhere ? Dec 26 14:00:10 If it's killed by oom you'd see it in dmesg. Dec 26 14:01:24 I need to check that (do not have access to my Docker host at the moment), but it's always stopping the compilation at the same place... with OOM would it be always reproducible at the same point in compilation ? Dec 26 14:01:38 It might be so. Dec 26 14:03:13 Regarding question (1) : is there a SDK-like environment available, but with all the binary artefacts already in place ? (would be huge size I'm sure, but wanted to ask) Dec 26 14:03:33 ynezz: thanks for the CI explanation Dec 26 14:03:42 I will try to reproduce it loally in the next few days Dec 26 14:08:21 llange: answer is no Dec 26 14:12:03 ynezz: thx ! Dec 26 14:20:13 Hm, if my target has 4K sectors is it necessary for it to have BLOCKSIZE:=4k for sysupgrade to be able to save config files? Dec 26 14:44:57 * check_data_file_clashes: Package libubox20170601 wants to install file /lib/libubox.so But that file is already provided by package * libubox20191226 * opkg_install_cmd: Cannot install package luci-ssl. Dec 26 14:46:16 This is on snapshot. What to do? Dec 26 14:46:33 Cisco E2000/WRT320N Dec 26 14:52:16 PaulFertser: no; just going from 4k disabled to 4k enabled or vice versa will most likely fail to save config files; the latter might even break the overlay (not sure if it even breaks boot) Dec 26 14:52:17 jmv200: probably remove build_dir/target* and staging_dir/target* to force it using all current versions. Dec 26 14:53:44 PaulFertser: Didn't compile this. Just downloaded and tried to use snapshot. Dec 26 14:54:01 Should I wait for the packages to update? Dec 26 14:54:08 KanjiMonster: is sysupgrade config restore code looking at just the beginning of rootfs_data or through it all? Because if it's just the beginning, and sysupgrade image during the build is automatically padded to 64k sectors and then the tar with config is appended it'll end up in the "middle" of rootfs_data. Dec 26 14:54:26 I haven't fully checked that yet. But somehow it fails sysupgrading on my board atm. Dec 26 14:57:36 PaulFertser: sysupgrade on the old system creates a single-file jffs2 at the expected beginning of rootfs data, replacing the deadc0de marker (aligned to erase block sector size), new system will then mount the already pre-created jffs2 Dec 26 14:59:08 so if the old system thinks erase blocks are 64k then it will write it to a 64k aligned offset, which will be at a wrong offset if the new system uses 4k blocks (unless the first usable 4k happens to also be a 64k aligned offset) Dec 26 14:59:20 KanjiMonster: if build code for my board has "pad-rootfs" then the sysupgrade file will end past the autodetected (on the next boot) beginning of rootfs_data. Dec 26 15:01:52 As pad-rootfs uses BLOCKSIZE build-time variable and the kernel is using the sector size from the m25p80 table in the driver based on jedec id. Dec 26 15:25:17 KanjiMonster: it seems that I now must go through all the ath79-tiny targets one-by-one to check specific flash IC used and add BLOCKSIZE for those that have 4K_SECTORS flag in the driver table? Dec 26 15:26:24 Don't need help here now. Dec 26 15:28:55 jmv200: `rm -fr bin` should be enough Dec 26 15:29:45 ynezz: that Dec 26 15:29:56 's prank, or that's for the clash Dec 26 15:29:59 ? Dec 26 15:30:23 you need to remove the old version of libraries Dec 26 15:31:07 Is something getting updated so it doesn't happen anymore Dec 26 15:31:09 ? Dec 26 15:31:15 When would that be ready? Dec 26 15:32:17 ah, this is opkg ? Dec 26 15:32:25 Yes. Dec 26 15:32:31 I've thought, that you're building it yourself Dec 26 15:33:50 not using opkg so don't know how to solve this Dec 26 15:33:57 Let me try to build myself, so what happens. Dec 26 15:58:37 maybe you just need to wait for a build of newer version of luci-ssl which would depend on the fixed version of libubox Dec 26 15:58:37 * ynezz afk **** BEGIN LOGGING AT Thu Dec 26 15:58:54 2019 Dec 26 17:08:29 I wonder if "logread" is not working for me due to one those libubus patches merged recently. Dec 26 17:57:39 KanjiMonster: I'd like to hear the answer of someone who knows for sure because finding all the affected ath79-tiny boards would be a tedious task, I'd rather not do that unless really necessary. Dec 26 20:47:15 blogic: i need to ask... is autofs code in fstools totally untested? Dec 26 20:50:34 uh, i thought I saw some bug, but maybe it's not a bug after all Dec 26 20:50:43 just something not working in my case? Dec 26 20:55:11 cccccchdgggnkvikfretbbfffhiigevvctkkhggbcedf Dec 26 20:55:19 oops Dec 26 20:59:25 PaulFertser: I'm looking at this hiccup now Dec 26 20:59:36 Thank you! Dec 26 21:01:29 lately I've been getting this, ant ideas? if i touch the file manually it builds no problem, https://paste.ubuntu.com/p/Cg2xbqHq9K/ Dec 26 21:01:56 Slimey: I have the same issue since today. Dec 26 21:03:52 i have to Dec 26 21:03:56 mkdir /home/briang/openwrt/build_dir/hostpkg/luci-base/ Dec 26 21:04:08 touch /home/briang/openwrt/build_dir/hostpkg/luci-base/.configured Dec 26 21:05:12 Slimey: for me mkdir was enough Dec 26 21:05:31 ah Dec 26 21:37:01 PaulFertser: if it writes the backup to the wrong offset if additional eof-markers are present then that sounds like a bug in mtd Dec 26 21:38:29 KanjiMonster: sorry, I'm kinda not following. My idea is that the generated sysupgrade image is too big because it's padded to 64k during the build time. So whatever is appended to it during the sysupgrade process will end up being not at the start of rootfs_data. Dec 26 21:42:02 PaulFertser: ah, I missed ath79 sets the block size to 64k; in that case yes, you have to set it to 4k for all devices with 4k erase blocks (-> https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/image/Makefile#L62 ) Dec 26 21:44:35 KanjiMonster: hm, that kinda sucks. Real erase size is determined on runtime when the kernel probes the memory, and it would be nice for sysupgrade to follow. Probably it can do the same as kernel rootfs/rootfs_data splitting code does? Dec 26 21:48:03 PaulFertser: the issue is that the sysupgrade code uses the EOF marker to know when to write the jff2'd backup file, and BLOCKSIZE is used to determine where to write it in the image at build time; so if blocksize is 64k, the EOF marker is written at an 64k aligned offset Dec 26 21:51:24 KanjiMonster: ok, and my new question is whether it should probably be improved. I guess nobody's going to do that so I'll have to track down all ath79-tiny devices which actually have 4k sectors and change the BLOCKSIZE for them... Dec 26 21:52:56 PaulFertser: improving it is a non-trivial task - you need to implement all the firmware parsing code into the sysupgrade code to dynamically find out where the correct offset it. currently it doesn't need to know that, and just writes in erase block sized chuncks, and if the block to write happens to start with the EOF marker it instead writes the backup Dec 26 21:53:22 KanjiMonster: I understand Dec 26 22:26:58 PaulFertser: that logread issue is caused by following https://git.openwrt.org/5d7ca8309d0a1614d829df9ecd72553bcd6b5ec6 **** ENDING LOGGING AT Fri Dec 27 02:59:57 2019