**** BEGIN LOGGING AT Thu Jun 20 03:00:00 2019 Jun 20 06:39:19 xback: yeah, they're nice, I wouldn't even bother to approach them, BTW I took the liberty and assigned that patch to you on the patchwork, hope you don't mind :) Jun 20 08:09:34 blogic: if you nicely ask dwmw2 Jun 20 08:14:34 sorry, that was meant to go into openwrt-adm in response to (can we create a openwrt-announcement list where we send mails for releases ?) Jun 20 08:35:21 will fixes for the TCP SACK vulns be available for 18.06.2? Jun 20 08:36:12 no, but for 18.06.3 (and 19.07.0) Jun 20 08:36:51 it requires an updated kernel, which can't be updated individually, without updating the whole image **** BEGIN LOGGING AT Thu Jun 20 08:45:56 2019 Jun 20 09:26:40 Hauke: the 17.01 kernel bumps appeared to have broken a few targets Jun 20 09:27:19 http://release-builds.lede-project.org/17.01/images/one_line_per_build Jun 20 09:36:13 New day .. new bumps .. pushed to staging Jun 20 09:40:33 jow: Hauke: already on it Jun 20 09:42:22 I am working on it Jun 20 09:43:31 Hauke: I have patches ready Jun 20 09:43:52 me too the layscape is still missing Jun 20 09:44:06 KanjiMonster: can you push them to your staging tree please Jun 20 09:44:43 Hauke: currently in the process of doing that Jun 20 09:44:51 oh, I'm also on it :P Jun 20 09:45:10 will wait for you guys then Jun 20 09:46:08 looks like a race condition to me .. ;-) Jun 20 09:46:09 I have two commits; fixing brcm2708's get_user_pages usage and adding CONFIG_RTC to generic/config-4.4 Jun 20 09:49:45 jow: Hauke: https://git.openwrt.org/?p=openwrt/staging/jogo.git;a=shortlog;h=refs/heads/lede-17.01-queue Jun 20 09:50:11 ah, second one isn't enough Jun 20 09:50:49 I also fixed the apm Jun 20 09:50:54 this is broken upstream Jun 20 09:50:58 ah Jun 20 09:51:22 Christian broke it ;-) Jun 20 09:51:49 KanjiMonster: jow: https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/lede-17.01 Jun 20 09:53:37 Hauke: you don't need to do "./scripts/kconfig.pl '+' target/linux/generic/config-4.4 /dev/null > target/linux/generic/config-4.4-new", you can just do "./scripts/kconfig.pl target/linux/generic/config-4.4 > target/linux/generic/config-4.4-new" Jun 20 09:53:54 KanjiMonster: CONFIG_RTC was not enough for me Jun 20 09:53:59 yes Jun 20 09:54:06 that what's I just said ;) Jun 20 09:54:09 CONFIG_GEN_RTC is also needed Jun 20 09:55:16 the brcm2708 patch looks the smae Jun 20 09:55:59 looks like you found and fixes the same issues in the generic config, just in a separate commit ("seta" and "it not set") Jun 20 09:57:33 Hello to everyone Jun 20 09:57:59 I have a question about current Mikrotik support and how to add new Mikrotik devices Jun 20 09:58:32 The seta was fixed automtically and the script removed the "it not set" Jun 20 09:58:34 According to my declined pull request, I have no idea how to do that Jun 20 09:58:35 https://github.com/openwrt/openwrt/pull/2150 Jun 20 09:58:36 Hauke: mail about deadline tomorrow sent Jun 20 09:59:08 I am currently travelling and do not have any devices with me, would be nice if someone could test lede 17.01 Jun 20 09:59:14 jow: tahnks for the mail Jun 20 09:59:46 KanjiMonster: I am currently looking into the layerscape problem Jun 20 09:59:53 on a semi related note, I found a few bytes we can shave off the kernel: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.4.y&id=a32c5331b462670093ec809ec063ad7d28f47126 Jun 20 10:00:57 are IO ports "different" to memory addresses on some platforms? Jun 20 10:01:17 yes Jun 20 10:01:23 IO ports tend to be memory addresses that are wired to physical interafces Jun 20 10:01:30 LPT ports for example Jun 20 10:01:34 or UARTs Jun 20 10:01:47 IIRC x86 has special instructions for accessing io ports Jun 20 10:01:47 right, but what does that dev/port give you over using dev/mem? for the same mem address? Jun 20 10:02:03 KanjiMonster:ok, right, different instructions for them. Jun 20 10:02:20 these io ports are AFAIK not memory mapped Jun 20 10:02:52 KanjiMonster: correct, they are directly wired normally Jun 20 10:17:21 hmm... something is wrong with package dependencies in master Jun 20 10:17:36 the packages in the snapshot repo lack a Depends: libjson-c Jun 20 10:19:45 jow: is it missing in the image? Jun 20 10:21:23 not sure yet but I can reproduce it locally Jun 20 10:21:37 there is just no dependency for json-c emitted in ipk metadata Jun 20 10:21:41 I've tested mt7620 this morning and it booted fine Jun 20 10:25:17 just downloaded x86/64 snapshot and it booted fine Jun 20 10:25:27 (in qemu) Jun 20 10:25:59 it's with that json-c update r10264-080ba31 Jun 20 10:26:02 strange Jun 20 10:28:46 false alarm Jun 20 10:28:58 I assumed that libubox would require a dep on libjson-c but its not the case Jun 20 10:29:11 libblobmsg-json has the dep on libjson-c and that is okay Jun 20 10:29:36 x86/generic booted fine as well Jun 20 10:30:52 ynezz: the problem is incremental builds (git pull; make) Jun 20 10:31:06 ahh, ok Jun 20 10:31:48 hmm, no Jun 20 10:31:55 I did incremental build on mt7620 also Jun 20 10:32:13 I certainly didn't build it from scratch this morning Jun 20 10:32:16 the problem I see is that for example procd does not directly depend on anything depending on libjson-c Jun 20 10:32:27 thats probably why the buildroot rebuild tracking fails Jun 20 10:32:45 procd depends on libjson-script but strangely libjson-script does not depend on libjson-c Jun 20 10:32:57 ok, that makes sense Jun 20 10:33:07 procd also depends on libubox but libubox itself does not depend on libjson-c either Jun 20 10:33:42 yet procd ends up linking libjson-c.so, probably through libjson-script.so Jun 20 10:34:42 Jun 20 09:00 build_dir/target-mipsel_24kc_musl/procd-2019-05-30-ade00ca5 Jun 20 10:35:03 something has obviously triggered rebuild of procd this morning Jun 20 10:36:31 maybe I was just lucky Jun 20 10:41:18 https://git.openwrt.org/?p=project/procd.git;a=blob;f=CMakeLists.txt;h=4b3eebd7c9e18d10b7489233e6f6cb536d6938dd;hb=ade00ca585a49c8478bf60eb24ce385676be37a4#l28 Jun 20 10:41:21 vs. Jun 20 10:41:41 https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/system/procd/Makefile;h=437751aadf8f92a904115f73c3cb9d64313d5827;hb=f528d771c424abe81859bcccd084bfe8430f568e#l46 Jun 20 10:43:05 the binary dependency checker in openwrt buildroot is satisfied due to procd -> ubus -> libblobmsg-json -> libjson-c Jun 20 10:43:26 but the ABI version rebuild tracker misses this transient dependency, or at least so I think Jun 20 10:43:53 neoraider ping Jun 20 10:46:14 KanjiMonster: I think I fixed now all build problems Jun 20 10:52:05 Hauke: nice Jun 20 10:52:26 yeah confirmed; https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=include/package.mk;h=569ad647d6db2392026f8300b951047b4f862220;hb=783e37502f5bceeeccde770782e81c0846179d96#l56 - this macro is the culprit since it does not recursively follow dependencies Jun 20 10:54:45 KanjiMonster: should I push my version? Jun 20 10:56:18 Hauke: looks good Jun 20 10:59:29 KanjiMonster: btw, shall I include your acked-by or signed-off-by in https://git.openwrt.org/56b22cf1a288ef82e2df0df19d6c3ce7afbdbaee https://git.openwrt.org/319a841cae98592a4e5a870d64374ec93f4d9b5b https://git.openwrt.org/76439533456dc64cff577289a766643448f6ccec ? Jun 20 11:03:45 jow: https://git.openwrt.org/?p=openwrt/staging/jow.git;a=commitdiff;h=56b22cf1a288ef82e2df0df19d6c3ce7afbdbaee is missing the fixes tag Jun 20 11:04:58 any reason you changed the author to you in https://git.openwrt.org/?p=openwrt/staging/jow.git;a=commit;h=10b8f09c7365f293e5555dcb834826d791a10287 ? Jun 20 11:06:37 https://git.openwrt.org/?p=openwrt/staging/jow.git;a=commitdiff;h=76439533456dc64cff577289a766643448f6ccec - you can drop the '(' ')' around the joined deps there is no precendence issue anymore (everything is &&'d) Jun 20 11:29:38 KanjiMonster: no particular reason, I simply redid the changes manually Jun 20 11:29:41 will change it to yours Jun 20 11:33:18 gotta go, bbl Jun 20 11:47:41 i'm trying to activate telnetd on a embedded device (no openwrt, sorry) but i cannot connect to telnet port. the busybox telnetd says: telnetd: open pty Jun 20 11:47:47 what might missing? Jun 20 11:49:35 First thing that comes in my head: why in earth? :) Jun 20 11:50:11 if telnet works i can think about dropbear but if even telnetd does not work why then think about a sshd? Jun 20 11:50:56 Also, I don't know is telnetd how included nowadays, as ssh is solely used on default installations, passwordless in first login and emergency situations Jun 20 11:51:24 olmari: i have a telnetd capable busybox - that is not the question Jun 20 11:53:02 We can't help you with your random device with random OS we know nothing Jun 20 11:54:05 i just want to know what device-nodes are necessary and so on Jun 20 11:57:43 rubberduck: https://git.busybox.net/busybox/plain/networking/telnetd.c Jun 20 11:57:51 the comment at the top lists the requirements Jun 20 11:59:42 if i had strace for the target architecture it might be easier... Jun 20 12:06:33 thx - 'login' was missing. Jun 20 12:07:21 i hope this is enough now Jun 20 12:27:37 Would it be possible to merge this PR https://github.com/openwrt/openwrt/pull/2093 to OpenWrt 18.06? Jun 20 12:45:59 klukonin: ar71xx is simply gone, we don't accept new devices to ar71xx for some time already, I've pointed you to some mail threads where we've discussed this already Jun 20 12:52:23 klukonin: regarding your ar71xx/mikrotik subtarget remark, I believe, that it's not necessary in ath79 Jun 20 12:54:06 klukonin: take my comments with grain of salt, as I don't own any Mikrotik devices, so I might be wrong :) Jun 20 12:56:03 I believe, that xback is going to explore this ground soon, he simply wont run 4.14 any longer on his Mikrotik stuff :p Jun 20 12:57:47 God I miss ar71xx already .. Jun 20 12:58:35 (but that's a strict personal opinion and does not reflect the official view of OpenWrt in any way) Jun 20 13:01:10 is it somehow possible to have two JSONs open in the same shell script? I've one JSON with device config and would like to fiddle with VLANs info stored in /etc/board.json Jun 20 13:09:47 ynezz: There is something called namespace I think? Jun 20 13:09:55 (use lua) Jun 20 13:10:38 I remember hackpascal used it for phicomm k2t support in ath79 Jun 20 13:12:58 ynezz: Found it: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ath79/base-files/lib/functions/k2t.sh;h=1158df818bb9be53569e7aa33d4bed4a462cee4b;hb=HEAD Jun 20 13:13:48 karlp: I probably need to support 4/32, so -ENOSPACE :) Jun 20 13:14:30 didn't we decided that 19.07 was 8+ only? or was that from master, now that 19.07 has branched? Jun 20 13:14:32 but sure, Jun 20 13:14:39 * karlp is just used to always having lua. Jun 20 13:15:51 hamburg summit> 19.07 will be the last release with support for 4/32 MB devices Jun 20 13:17:00 gch981213: thanks, it looks interesting Jun 20 13:17:12 ynezz: yes, https://git.openwrt.org/?p=project/libubox.git;a=commitdiff;h=e16fa068a57318fff073da4a0f8f0535a97fe208 Jun 20 13:18:34 `cat /etc/board.json | jsonfilter -e '@.switch.switch0.roles[0].ports` isn't that bad either Jun 20 13:18:46 ynezz: json_set_namespace $new_ns old_ns; ... do things ...; json_set_namespace $old_ns Jun 20 13:19:16 use -s for jsonfilter to avoid the extra fork/exec/cat Jun 20 13:19:31 sorry, -i Jun 20 13:19:47 jsonfilter -i /etc/board.json -e '@.switch.switch0.roles[0].ports' Jun 20 13:21:44 yikes tmp/.config-package.in invalid option / syntax error Jun 20 13:31:27 jow: great, thanks! Jun 20 13:49:04 ynezz: I have WAP LTE kit and ltAP mini Mikrotik devices. Both of them are MIPS based. So I can do some work and port them to ath79. Also I have LHG60 and WAP60G they are IPQ40xx based. But robimarko did all job before so they are ready for now, but not pushed yet. Jun 20 13:50:42 I suppose, that ipq40xx stuff is going to be handled by Christian (@chunkeey) Jun 20 13:52:32 klukonin: I've just received some Mikrotik IPQ40xx boards from my employer, so I'm also going to be working on those. probably by the end of next week i think .. Jun 20 13:54:17 ldir: try make -C scripts/config/ clean Jun 20 13:56:24 xback: Nice. Please let me know. May be I can test something Jun 20 13:58:24 ynezz: Is there any instructions for porting ar71xx to ath79 ? I found only this topic https://forum.openwrt.org/t/porting-guide-ar71xx-to-ath79/13013/917 But I also remember that is was a document. Jun 20 14:04:53 jow: sadly no dice. I wonder if this is an issue with the feeds ? Jun 20 14:05:58 ldir: can you pastebin more context? Jun 20 14:06:22 and maybe the offending lines of tmp/.config-package.in as well Jun 20 14:06:58 https://pastebin.com/37QsrPCp Jun 20 14:08:21 https://pastebin.com/jG6MFHM5 Jun 20 14:12:16 ldir: this is exactly what would happen before https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=972123f1e056e6d443be1e4a11db09b5d2ef53da Jun 20 14:18:14 ok, so after rm zconf.lex.c things are better - I had run make clean in that dir anyway Jun 20 14:19:22 build #371 of apm821xx/sata is complete: Success [build successful] Build details are at http://release-builds.lede-project.org/17.01/images/builders/apm821xx%2Fsata/builds/371 Jun 20 14:26:59 I trashed scripts/config completely and did a git reset --hard to get this right things back :-) Jun 20 14:27:57 ldir: hmm ... a make -C scripts/config/ clean (note the space) should solve it Jun 20 14:28:05 if not we might need to fix kconfigs Makefile Jun 20 14:29:07 checks command history "make -C scripts/config/ clean" note space. Jun 20 14:29:38 we've some hack in there which copies the *_shipped files to their resepctive proper names Jun 20 14:29:58 maybe this makefile logic fails to account for updated *_shipped files Jun 20 14:32:47 jow: IIRC our buildsystem doesn't track changes in scripts/config and doesn't rebuild at all; you always needed to do a manual clean there Jun 20 14:37:59 KanjiMonster: the problems seems to be the clean target Jun 20 14:38:01 it has a typo Jun 20 14:38:37 https://pastebin.com/g02ThRga Jun 20 14:38:59 the zconf.lex.c file initiall copied from zconf.lex.c_shipped is never reset Jun 20 14:39:12 ah Jun 20 14:39:13 even with make config-clean (or make -C scripts/config clean) Jun 20 14:39:49 and the target copying *.c_shipped to *.c has no prereq on %.c_shipped, hence it'll never rerun for updated files Jun 20 14:41:05 and we can't just drop the .c_shipped stuff, because one of the source files was never updated in the last sync (which is technically a GPL violation) Jun 20 14:52:43 jow: https://pastebin.com/mvrN1QS1 Jun 20 14:58:57 KanjiMonster: acked-by Jun 20 14:59:34 jow: should I just fold your change into it? Jun 20 15:00:27 * ldir falling into stuff so you don't have to (tm) Jun 20 15:00:41 KanjiMonster: yes, please Jun 20 15:01:32 ldir: if you are so used to having to do stuff manually (like the clean/rm files), then you stop registering certain behaviour as wrong/broken, so it's fine ;) Jun 20 15:02:50 * ldir grins Jun 20 15:11:57 I guess now the buildbots are stumbling over it .. Jun 20 15:14:32 ldir: jow: pushed Jun 20 15:16:34 thank you kind Sir Jun 20 15:18:52 Hi is that same cve from the forums? Jun 20 15:18:56 https://github.com/oreosES/exploits/tree/master/CVE-2019-12272 Jun 20 15:19:19 I just spotted that on twitter Jun 20 15:23:44 what? an authenticated user can run commands? Jun 20 15:23:58 ldir: shocking Jun 20 15:24:02 That's what I was thinking. Jun 20 15:24:22 I mean there is a legitimate bug and one can indeed inject shell commands Jun 20 15:24:39 the key word being *authenticated* Jun 20 15:24:42 but you can as well go to fireall -> custom rules or system -> locla startup, paste whatever you like in there and reboot Jun 20 15:25:50 you mean an authenticated user can *reboot* ? Jun 20 15:26:42 If you are a authenticated user you one the box anyway. Jun 20 15:26:50 own* Jun 20 15:27:12 jow: what if you have restricted the user through acls to only read the bandwidth status, does this still work to execute stuff? Jun 20 15:27:43 KanjiMonster: on versions that do have any kind of acl the bug does not exist anymore Jun 20 15:27:55 on versions which are vulnberable, there are no ACLs Jun 20 15:28:43 could be that third party mods like luci-multiuser are affected, but I am not sure if their implementation is secure to begin with Jun 20 15:38:41 Is there a sh-callable "sleep" already that accepts fractions of a second? Jun 20 15:40:27 (on running OpenWrt, default build) Jun 20 15:47:02 jeffsf: unfortunately no Jun 20 15:47:26 OK, thanks -- at least musl provides nanosleep and the "convenience" usleep Jun 20 15:53:34 you can do .... something similar, if all you really need is "something shortish" with... https://zerobin.net/?e54c22b577aff13c#IXl0AZX9pVe1EEqLSij1u3YL1cXgl4dUxpzsNLoPWBo= Jun 20 15:53:52 it's... kinda gross, (I use luaposix and call nanosleep myself) but you can do it with what's available :) Jun 20 15:56:51 karlp: Looking at it to be able to signal errors to the user via LED when sysupgrade fails after killall, so they at least know that there was a problem, and hopefully report an error number with N flashes, or the like Jun 20 15:57:32 A brief C program should do it, but would have been nice to reuse something, or a busybox applet (unchecked as of yet) Jun 20 15:58:43 there should be a led trigger for that Jun 20 15:58:45 Ah! Busybox has usleep! Jun 20 15:59:02 not unless you added it to your config... Jun 20 15:59:10 so that's not in your default build requirement... Jun 20 15:59:29 True, but looking at changing that, "the gods permitting" Jun 20 16:03:04 neoraider so do you think ram/flash in buildroot makes sense or is it bloat? I'm in favour for that but we could also put that in a second repo with metadata Jun 20 16:03:08 led pattern triggers? https://lwn.net/Articles/768159/ Jun 20 16:04:17 it's in 5.1 at least, probably not in anything we support yet :) Jun 20 16:23:01 Hauke: I started with your patches to update the lantiq target to 4.19. I guess that "my mileage will vary", did you test it and with what result? Jun 20 16:23:14 Is building for ath79 fix yet? Jun 20 16:23:34 Hauke: in my case PCI doesn't seem to detect anything at all and for PCIe I get: ath10k_pci 0000:01:00.0: failed to wake up device : -145 Jun 20 16:23:52 Hauke: I'm not complaining, I just want to know whether you got the same results so I can start debugging Jun 20 16:45:06 xdarklight: got stopped by the same issue quite some time ago Jun 20 16:45:45 xdarklight: as far as I remember the load order of the pci + pcie driver changed Jun 20 16:46:05 xdarklight: and guess what, the driver/system/someone expects a specific driver load order Jun 20 16:49:02 mkresin: nice to see you :). thanks for the hint, I wonder if I should start porting the lantiq PCIe driver to the mainline DesignWare PCIe driver instead of trying to fix that crappy ordering issue AGAIN (I believe we did that a few years ago and it hurt) Jun 20 16:50:05 xdarklight: found my old branch. I obviously tried to port a more recent driver from a recent ugw Jun 20 16:50:39 xdarklight: and there is even a new 4.9 based pci driver from ltq. but it doesn't include support for xrx200 anymore Jun 20 16:53:09 Hi I am getting a crash on boot with my wrt3200acm with build r10283 Jun 20 16:54:46 Any one else? Jun 20 16:55:03 getting a bootloop on vmebu Jun 20 16:55:47 any info on the bootloop? Jun 20 16:55:57 no logs sorry Jun 20 16:56:18 I booted back in to the older build on partion 2 Jun 20 16:56:33 partition* Jun 20 17:01:03 Tapper: you probably need a make dirclean Jun 20 17:01:29 jow why? Jun 20 17:03:15 because libjson-c was renamed from libjson-c.so.2 to libjson-c.so.4 and a number of services (including procd) need rebuilding Jun 20 17:03:26 due to other bugs in the build system, this does not happen automatically Jun 20 17:03:28 OK thanks Jun 20 17:51:04 mkresin: Hauke: FYI https://patchwork.kernel.org/patch/11007557/ Jun 20 18:09:54 mkresin: Hauke: uh, reverting https://github.com/torvalds/linux/commit/edb0b6a0b4490014924d56c4c7117c7c8fc608ca#diff-347c9303c74c8078530f19beb1bba1a5 fixes PCI and PCIe for me Jun 20 18:09:57 on 4.19 Jun 20 18:18:30 Why is libjson-c showing up as a dependency everywhere now? Jun 20 18:27:07 `master` seems to be having problems with `tmp/.config-package.in:60153:warning: ignoring unsupported character '@'` Jun 20 18:27:17 jeffsf: make config-clean Jun 20 18:27:21 thanks Jun 20 18:27:36 mangix: what do you mean? Jun 20 18:27:43 BLowing away tmp/ wasn't sufficient Jun 20 18:28:01 jeffsf: no, its kconfig that needs to be recompiled Jun 20 18:28:07 thanks! Jun 20 18:31:39 jow: had to add to fstools and ubusd. seems make clean got rid of it. Jun 20 18:31:41 mangix: it always has been a (indirect, transitive) dependency wherever it shows up now Jun 20 18:32:17 the version bump which caused the .so name change exposed several inefficienncies in buildroot Jun 20 18:32:35 most importantly, the abi version rebuild tracking does not handle transitive dependencies at all Jun 20 18:33:03 so if procd depends on libblobmsg-json which in turn depends on libjson-c, then libblobmsg-json will get rebuilt due to the libjson-c soname change Jun 20 18:33:13 but procd will not get rebuilt because libblobmsg-json didn't change Jun 20 18:33:27 ah Jun 20 18:33:57 adding libjson-c to the direct depends avoids this but its not a proper solution Jun 20 18:34:25 buildroot should be able to resolve indirect depends on libraries with abi version instead Jun 20 18:34:49 however while reviewing procd, uhttpd etc. I noticed that they actually link libjson-c directly, so the direct dependency makes sense Jun 20 18:35:24 basically whatever is in CmakeLists.txt TARGET_LINK_LIBRARIES() should be in DEPENDS:= as well Jun 20 18:47:18 xdarklight: do we have an additional patch which changes the order? Jun 20 18:48:36 xdarklight: yes I had the smae problems with PCI(e) with my lantiq 4.9 patches Jun 20 18:48:46 This is the only problem I am aware of Jun 20 18:51:06 xdarklight: I think the vr9 uses a special PCIe PHY Jun 20 18:51:50 did I smell lantiq? Jun 20 18:52:19 reminds me of a weird issue I have with openwrt's u-boot on the ARV7510PW22 Jun 20 19:05:16 neoraider: https://git.openwrt.org/?p=openwrt/staging/jow.git;a=commitdiff;h=2c840a18489e144101cc767c9b524e7bfc4005f2;hp=7ce73bfee7a0394a38fb524dde4fcc134150bb32 Jun 20 19:05:52 couldn't come up with a more clever way Jun 20 19:06:08 but the above appears to be reliably triggering rebuilds for anything related to json-c Jun 20 19:07:25 I wonder if we should just enforce adding explicit depends for everything that explicitly links a library through our missing dependency mechanism Jun 20 19:09:36 Such a rule might also make sense for other reasons, for example a package replacing another using PROVIDES that has different DEPENDS than the original package Jun 20 19:12:04 neoraider: I think it makes sense, yes Jun 20 19:12:13 but will require some serious refactoring Jun 20 19:12:40 I think a lot of the buildroot make code generation could be externalized to some scripting more up to the task Jun 20 19:13:22 essentially its make ... DUMP=1 which outputs things to stdout which are then put into tmp/.packageinfo Jun 20 19:13:42 then we have a mix and mash of shell, self generating make code and perl to generate make code out of tmp/.packageinfo Jun 20 19:13:52 which is then eval'd Jun 20 19:14:49 it probably would make sense to make that middle part a script (no I don't insist on Perl though I would be personally be fine with it) outputting make recipes according to template Jun 20 19:17:20 such a script could then also evaluate .config, evaluate the conditional dependency specs etc. and generate proper make recipes on demand that do not require further interpolation or interpretation of the dependency tree Jun 20 19:17:50 it could also take care of cleanly serializing the dependency graph in opkg metadata Jun 20 19:18:30 anyhow, back to the actual matter at hand Jun 20 19:18:43 neoraider: would appreciate if you could help testing that fix in my tree Jun 20 19:35:33 jow: I don't think I'll be able to do meaningful testing today, exhausted from work... Jun 20 20:05:11 well this isn't much fun Jun 20 20:05:25 i thought i'd try 4.19 Jun 20 20:05:46 took and edit or two and it just booted Jun 20 20:06:04 no bricking, no smoke, nutten Jun 20 20:06:12 it's just working Jun 20 20:10:02 mkresin: hiya Fritz! Great to see you :-) Jun 20 20:19:00 oh thats better, usb isn't working guess I edited incorrectly Jun 20 20:30:46 Kevin's idiot question of the day, something I've never quite grasped and it's really holding me back. What is the staging directory for? What do we mean by staging? Jun 20 20:33:36 I 'get' that the build_dir is where we appear to build stuff, certainly if I make package/foo/prepare all the magic happens in build_dir but.... Jun 20 20:34:54 * ldir finds this https://stackoverflow.com/questions/26030670/openwrt-buildroot-build-dir-and-staging-dir Jun 20 20:45:59 ldir: that's were all build artifacts are installed to Jun 20 20:47:01 ldir: or at least everything of a package that might be required by other packages as a dependency Jun 20 20:48:36 so it's a sort 'mini filesystem' or a location where you'll find all of the cross compiled components for your target packages. Jun 20 20:48:47 Ah, the stackoverflow link explains it nicely Jun 20 20:48:49 Yes Jun 20 20:50:52 ok, I need to absorb that into the brain :-) Jun 20 20:51:54 thank you Jun 20 21:13:06 ldir: tools/ are installed under staging_dir/host. host packages under staging_dir/hostpkg. For stuff that the host OS does not necessarily provide but should Jun 20 21:21:34 I wonder if there's an overview document of all this...and if there isn't, there should be. I guess I've just volunteered myself Jun 20 21:22:12 * ldir says it's time for sleep anyway - catch you on the flip side Jun 20 21:49:48 ldir: good idea Jun 21 02:52:29 build #323 of layerscape/32b is complete: Success [build successful] Build details are at http://release-builds.lede-project.org/17.01/images/builders/layerscape%2F32b/builds/323 **** ENDING LOGGING AT Fri Jun 21 02:59:57 2019