**** BEGIN LOGGING AT Wed Jun 03 02:59:57 2020 Jun 03 03:40:52 build #383 of mvebu/cortexa9 is complete: Failure [failed kmodconfig] Build details are at http://buildbot.openwrt.org/master/images/builders/mvebu%2Fcortexa9/builds/383 blamelist: Petr ?tetiar , ?lvaro Fern?ndez Rojas Jun 03 03:45:03 build #387 of x86/generic is complete: Failure [failed kmodconfig] Build details are at http://buildbot.openwrt.org/master/images/builders/x86%2Fgeneric/builds/387 blamelist: Petr ?tetiar , ?lvaro Fern?ndez Rojas Jun 03 04:44:10 build #337 of octeon/generic is complete: Failure [failed defconfig dltar] Build details are at http://buildbot.openwrt.org/master/images/builders/octeon%2Fgeneric/builds/337 blamelist: ?lvaro Fern?ndez Rojas Jun 03 04:45:24 build #333 of malta/be is complete: Failure [failed defconfig dltar] Build details are at http://buildbot.openwrt.org/master/images/builders/malta%2Fbe/builds/333 blamelist: ?lvaro Fern?ndez Rojas Jun 03 05:48:38 https://forum.openwrt.org/t/buildbot-multilib-support-node-for-32-bit-targets-on-next-major-release/65758 Jun 03 06:25:15 mangix: well, anyone can send patches against buildbot repo to the mailing list for review, we can merge it and deploy it later during next cluster wide update Jun 03 09:20:04 mangix: probably in here https://git.openwrt.org/?p=buildbot.git;a=blob_plain;f=docker/buildslave/Dockerfile Jun 03 09:26:42 just posting since it seems some people really want node Jun 03 09:26:59 node on a 32bit arm... pfft Jun 03 09:27:12 I'ts probably for the better that it isn't available :) Jun 03 09:27:48 haha. i remember running node on an 800mhz kirkwood device before. it was really slow Jun 03 09:28:25 looking back on it, i think RAM was the problem. Jun 03 09:28:59 128MB doesn't cut it. i wasn't using swap either. Jun 03 10:02:58 hm, what is the holdup on https://github.com/openwrt/packages/pull/12178 ? Jun 03 10:03:17 I see an outstanding request to "please fix the initial comment" but don't see specifically what's being asked. Jun 03 10:19:14 commit description Jun 03 10:19:20 GitHub :) Jun 03 10:19:52 Does anyone know if a) it is possible and b) how - to look up a conntrack entry from user space by conntrack ID ? Jun 03 10:22:31 It is not clear to me from libnetfilter-conntrack docs Jun 03 10:23:53 rmilecki: pling? Jun 03 10:25:27 ynezz: sure, but what is the poor contributor *actually* being asked to type there? Jun 03 10:25:52 this is a rhetorical question, partly. Of course *I* know what I'd like to see there. Jun 03 10:26:08 But if the submitter knew that, he'dprobably have done so in the first place. Jun 03 10:26:10 he's not going to do that anyway Jun 03 10:26:26 so someone has to take it over :) Jun 03 10:26:33 yeah, just doing a test build now Jun 03 10:26:42 great, thanks Jun 03 10:28:42 There is a line to be walked as a maintainer between being helpful and wanting the moon on a stick. Jun 03 10:30:14 dwmw2_gone: ynezz: isn't there some upstream Perl fix to the issue yet? Jun 03 10:30:23 would be simplest to simply pick that Jun 03 10:30:44 yeah, I have Jun 03 10:32:06 ah the proposed github commit actually is the upstream commit Jun 03 10:32:15 or rather its contents Jun 03 10:33:24 almost Jun 03 10:33:43 --[4567].*) case "$optimize$ccflags" in Jun 03 10:33:43 +-[456789].*) case "$optimize$ccflags" in Jun 03 10:33:49 https://github.com/openwrt/packages/pull/12391 Jun 03 10:50:13 wait, that would cause a build failure. Why did this even build here? Jun 03 10:50:15 * dwmw2_gone frowns Jun 03 11:00:02 better. Jun 03 11:05:04 I received an email that my patch is Superseded? what does this mean? Jun 03 11:05:22 nick[m]: was that https://github.com/openwrt/packages/pull/12391 ? Jun 03 11:05:27 nick[m]: which one? Jun 03 11:05:42 http://patchwork.ozlabs.org/project/openwrt/patch/20200322105640.13705-1-vincent@systemli.org/ Jun 03 11:06:08 make[4]: Entering directory '/home/dwmw2/git/lede/master/build_dir/hostpkg/perl/perl-5.28.1/relink' Jun 03 11:06:08 make[4]: *** No rule to make target 'clean'. Stop. Jun 03 11:06:15 * dwmw2_gone frowns Jun 03 11:06:24 nick[m]: I've checked that GitHub PR and it was merged by blocktrron Jun 03 11:06:39 ahhh, so the email is misleading? Jun 03 11:06:47 because it was "authored" Jun 03 11:06:47 no? Jun 03 11:07:30 superseded means something like rejected? Jun 03 11:07:31 that patch and PR have same content Jun 03 11:07:45 you can merge both Jun 03 11:07:51 s/can/can't/ Jun 03 11:08:03 so if the PR is merged how to mark the patch? Jun 03 11:08:05 the PR that blocktron merged was my Patch Jun 03 11:08:27 I'm puzzled Jun 03 11:08:52 merged = accepted Jun 03 11:09:24 PR merged/accepted = same patch marked as Superseded in patchwork Jun 03 11:09:42 Me, too. I received an email that my patch was superseded. merged != supserseded... I think the git PR process is not compatible to patchwork xD Jun 03 11:10:17 everything is fine! :) the patch is merged. I was just confused of this strange e-mail. Thank u! :) Jun 03 11:12:24 the patch was still waiting for review in https://patchwork.ozlabs.org/project/openwrt/list/ Jun 03 11:12:38 so it was cleanup Jun 03 11:16:27 mangix: please give me better commit description https://patchwork.ozlabs.org/project/openwrt/patch/20200220034331.472229-1-rosenp@gmail.com/ Jun 03 11:16:48 mangix: please give me commit description https://patchwork.ozlabs.org/project/openwrt/patch/20200220035627.490891-1-rosenp@gmail.com/ Jun 03 11:20:03 ynezz: thanks, I did not know that. Jun 03 13:51:35 Is there an example of a package which has multiple source tarballs, I can copy from? Jun 03 13:51:43 Domoticz just started using git submodules Jun 03 14:00:40 oh dear Jun 03 14:01:50 I've just made the package use dynamic libjsoncpp Jun 03 14:01:52 now it's just minizip Jun 03 14:03:54 I suppose I *could* package minizip separately Jun 03 14:03:57 I chose not to, before. Jun 03 14:04:08 Kind of pointless having shared libraries if *nobody* else is using them. Jun 03 14:04:16 that's how it starts :) Jun 03 14:04:33 I suppose so Jun 03 14:28:09 build #399 of ramips/rt3883 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt3883/builds/399 Jun 03 14:46:44 ynezz: merged accepted packages to packages feed. Jun 03 14:50:11 mangix: thanks, pushed as well Jun 03 14:51:27 is there a canonical way to build an initramfs on ath79 that uses a plain elf kernel (not lzma-compressed)? Jun 03 14:51:53 kernel-bin | append-dtb seems to not do what I want Jun 03 14:52:33 interesting...there's a helios 4 PR. Too bad I'm happy with armbian. Jun 03 15:02:29 build #390 of armvirt/32 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/armvirt%2F32/builds/390 Jun 03 15:04:46 build #394 of mediatek/mt7623 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/mediatek%2Fmt7623/builds/394 Jun 03 15:11:37 more "standards" in the works https://telecominfraproject.com/wifi/ ? :p Jun 03 15:14:20 https://cdn.brandfolder.io/D8DI15S7/as/q6ndd4-fj1bko-4jsa1i/TIP_Wi-Fi_System_Webinar_22520_-_Telecom_Infra_Project.pdf there is even OpenWrt logo at page 10 Jun 03 15:16:46 *sigh* i just can't find my way in the build system maze to create a simple elf-kernel initramfs :/ Jun 03 15:18:55 build #389 of cns3xxx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/cns3xxx%2Fgeneric/builds/389 Jun 03 15:22:02 build #388 of mediatek/mt7622 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/mediatek%2Fmt7622/builds/388 Jun 03 15:54:23 build #388 of x86/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/x86%2Fgeneric/builds/388 Jun 03 15:56:28 f00b4r0: take a look at lzma-loader/src/Makefile and you'll notice that it builds the final elf with a bin (loader.bin->loader2.o->loader.elf). Jun 03 15:56:45 f00b4r0: I think it's possible to do the same with kernel-bin but I have no idea if that's a proper way. Jun 03 16:03:27 gch981213: thanks. I was just expecting that somewhere in the build system there was a target to cram vmlinux.elf instead of using a processed/compressed version Jun 03 16:03:42 hm minizip is a static library only anyway. Jun 03 16:03:54 That really does make it fairly pointless to build it as a separate package Jun 03 16:04:07 But I've mostly done it now anyway. Is there any other example of a static-only library package? Jun 03 16:05:59 build #384 of mvebu/cortexa9 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/mvebu%2Fcortexa9/builds/384 Jun 03 16:15:59 after creating feeds/packages/libs/cereal/Makefile what magic do I have to do to make it actually appear? Jun 03 16:16:15 dwmw2_gone: nothing, it should just be there Jun 03 16:16:28 maybe your makefile lacks an /install section or a call BuildPackage ? Jun 03 16:16:53 [dwoodhou@i7 master]$ scripts/feeds install cereal Jun 03 16:16:53 WARNING: Makefile 'package/feeds/packages/domoticz/Makefile' has a build dependency on 'minizip-dev', which does not exist Jun 03 16:16:53 WARNING: No feed for package 'cereal' found Jun 03 16:17:21 Either fixing domoticz to depend on minizip not minizip-dev, *or* committing my new Makefile, has fixed it. Jun 03 16:18:08 now I can configure it on and fix its build Jun 03 16:19:19 xback: pling? Jun 03 17:18:42 noltari: ping? Jun 03 17:21:05 f00b4r0: pong Jun 03 17:22:07 noltari: quick question: did you take a look at lzma-loader's linking process? Reason I'm asking is I'm increasingly convinced that LZMA_TEXT_START is irrelevant by the final link Jun 03 17:22:23 which, tl;dr; would mean we are decompressing over ourselves Jun 03 17:22:36 (and yes, I fail to see how it could ever work, if I'm right) Jun 03 17:26:55 noltari: did I just lose you? :) Jun 03 17:27:14 actually I didn't take a look at it, I just fixed it for the elf loader Jun 03 17:30:03 noltari: ok. Basically when I look at the final binary (the loader.elf which eventually is the initramfs payload), everything is packed together at load address 0x80060000, which happens to also be the LA for the decompressed kernel (i.e. the address starting from which we write the decompressed kernel, if I read this right) Jun 03 17:30:25 I need someone with more ELF-fu than I have to tell me if I'm right or wrong Jun 03 17:50:56 build #338 of octeon/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/octeon%2Fgeneric/builds/338 Jun 03 17:55:55 build #334 of malta/be is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/malta%2Fbe/builds/334 Jun 03 18:02:53 bummer Jun 03 18:02:55 [ 4.534284] sh[1326]: illegal instruction (4) at 3fffbb538f1c nip 3fffbb538f1c lr 10045324 code 1 in libc.so[3fffbb4be000+89000] Jun 03 18:03:19 but at least kernel boots and is able to mount rootfs Jun 03 18:16:40 let's try newer GCC Jun 03 18:17:00 * enyc meows Jun 03 18:31:27 no joy :( Jun 03 18:40:34 is there any common reason for an IPQ based AP to loose its bootloader env? Jun 03 19:14:49 greearb: ? Jun 03 19:14:56 what you mean ? Jun 03 19:15:19 last i tested (2 days ago) uboot-env worked on a ipq40xx Jun 03 19:15:32 and i stressed it in my testcae Jun 03 19:15:38 *testcase Jun 03 19:29:29 I have a flakey AP, just brought up on OpenWrt, and sometimes it looses its env. I'm curious if there are common problems that cause this, including broken hardware, etc. Jun 03 19:31:20 like uboot-env gets nuked ? Jun 03 19:31:28 never heard of that happen on any HW Jun 03 19:39:25 it happens, but uboot let you know about it Jun 03 19:39:35 crc mismatch, using default or such Jun 03 19:54:31 i've seen that happen on a board that had a failling nor flash Jun 03 19:54:39 not ipq though Jun 03 19:54:57 failing* Jun 03 20:22:32 Seems the folks I got this from also saw a bad env situation...but OpenWrt has just been running on it for a few days, so maybe SW bugs. Jun 03 20:23:12 it also hard locks up the radio/firmware if you use ch 149 (but works fine on ch36), so it is strange, at least. Jun 03 22:29:53 quick question for anyone who can help...how does one update a patch that's been sent to the list and is on patchworks? Just mark the old patch as superseded and send a new patch to the list, or is there a cleaner way to do it? Jun 03 22:33:43 Hi people. Am I rite in thinking that with the changes to mvebu: you need to redo your configs after sysupgrading? Jun 03 22:33:57 The latest changes in master **** ENDING LOGGING AT Thu Jun 04 03:06:17 2020