**** BEGIN LOGGING AT Thu Mar 12 02:59:57 2020 Mar 12 10:16:47 build #251 of armvirt/64 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/armvirt%2F64/builds/251 Mar 12 12:45:42 karlp: I don't. Mar 12 12:56:31 I'm told dns-sd -B _blah._tcp should work, but don't have anything to try it out with :) Mar 12 13:27:16 dns-sd -B finds my laser printer, inkjet & NAS box Mar 12 13:28:33 does it show the IP address with -B or just lists them? (and did you have to install it, or was it just there?) Mar 12 13:33:12 it was just there - https://paste.ubuntu.com/p/T7gnMnxfKs/ Mar 12 13:35:00 karlp: come to the mac side - mwahahaha ha haaaa!!! :-) Mar 12 13:35:49 oh neat, it defaulted to _http._tcp when nothing was specified :) Mar 12 13:36:35 so to get the ip of the printer, you'r emeant to do dns-sd -L "Laser - HP Color LaserJet M254dw (414C8E)" yuk. Mar 12 13:44:24 errr I dunno - it doesn't appear to work Mar 12 13:51:30 "dsn-sd -G v4v6 Waldorf" ? Mar 12 14:20:46 yeah that works Mar 12 14:33:31 thanks Mar 12 14:50:19 there is some problem with the build variants and provides in iw Mar 12 14:50:31 it looks strange in the generated files Mar 12 14:51:09 I am trying to build OpenWrt with adress sanitizer and run into some problems with the build variants of iw Mar 12 14:53:31 I see this "depends on !(PACKAGE_iw-full for PACKAGE_kmod-rtl8192cu Mar 12 15:35:28 how do I activate logging in procd, I activated the address sanitizer for some libs and procd is crashing now Mar 12 15:35:42 I hope it is happening after the UARTs are set up Mar 12 15:57:20 -append "root=/dev/vda console=ttyS0 rootwait init_debug=5" Mar 12 15:57:29 init_debug Mar 12 16:18:35 hm, has someone an opinion on the dm-verity stuff? Mar 12 16:18:53 to me it looks like yet another obscure feature not used by openwrt itself, so it'll likely rot like glibc Mar 12 16:20:09 if it weren't for all the extra tools it introduces I'd even be inclined to merge it, but I'm afraid it will silently break eventually and simply bitrot Mar 12 16:22:47 I haven't followed it closely, but I have a similar opinion Mar 12 16:23:35 The impact is too big for something few people seem to care about Mar 12 16:24:33 apparently its mostly upstream stuff and a few config tweaks Mar 12 16:24:57 I'd be fine with accepting the config tweaks and simply relying on host tools for those who care about that feature Mar 12 16:25:09 means not packaging lvm etc. Mar 12 16:25:43 but on the other hand it'll likely be a precedcent for others to not package required stuff anymore Mar 12 16:26:41 indeed, I'd go either for a full yes or a full no Mar 12 17:09:28 well, it can be deleted if it bitrots :) Mar 12 17:11:59 I've never used dm-verity myself, so don't know how useful (or weak) is it, but it could be certainly seen as a nice to have security feature, IIRC Android uses (or used?) it Mar 12 17:12:29 that patch series is already obsolete, I would aim for update with 5.4 support Mar 12 17:12:44 but that's hard as mvebu is not on 5.4 yet Mar 12 17:13:58 ynezz: I agree that it can be deleted, my thoughts were more related to the overall maintainability of the code base. Mar 12 17:14:18 yeah, but thats not the author's problem :) Mar 12 17:14:56 I remember the discussion here about libjson-c Mar 12 17:14:57 by accepting a feature we're claiming to support it Mar 12 17:15:16 correct Mar 12 17:15:19 if we're unable to understand/fix/forward port it, we shouldn't accept it Mar 12 17:15:39 (or willing to do so) Mar 12 17:16:02 I see it as experimental feature which should be disabled by default, but readily available for interested people Mar 12 17:16:12 right, or we need to eventually thinkg about establishing multiple feature tiers Mar 12 17:16:26 like marking things in menuconfig as community sponsored and unsupported Mar 12 17:16:39 aka staging as in upstream Mar 12 17:16:45 I mean kernel Mar 12 17:16:54 kind of incubator Mar 12 17:17:00 well Mar 12 17:17:20 I guess I understand where you're going but when looking at arc... Mar 12 17:17:41 it was also kind of staging and readily available for interested people Mar 12 17:17:47 yet its stuck with uclibc Mar 12 17:17:54 never polished Mar 12 17:17:57 because they failed to market it? Mar 12 17:18:09 has never taken off Mar 12 17:18:46 another experimental feature disabled by defualt is glibc Mar 12 17:18:50 or external kernel tree Mar 12 17:18:54 or external toolchain Mar 12 17:18:59 all more or less broken Mar 12 17:19:30 we also dragged iso images along for years which also were broken for years iirc Mar 12 17:20:15 if we decide that such things are fine then I have no objections to merge dm-verity, as long as it does not break the normal featureset Mar 12 17:20:28 but I expect the extraneous host tools to cause grief Mar 12 17:20:40 thats expected, yes Mar 12 17:20:51 I dislike this part as well Mar 12 17:22:09 but you're right, that its about time to make the decision, patches are lingering on the list since 11/2019 Mar 12 17:23:33 ideally I'd like to reach a rough consensus on features in general that we do not care about / not actively use / mot require for our baseline builds Mar 12 17:23:50 yep, project goals Mar 12 17:24:05 like 1) always reject them because we can't / won't maintain them 2) always accept them as long as they don't break things Mar 12 17:24:22 2) = kitchen sink Mar 12 17:24:25 :) Mar 12 17:24:36 so I would lean towards 1 Mar 12 17:24:47 yes, and feature creep, code bloating, combination hell Mar 12 17:25:30 or allow doing such core stuff in the feeds (or layer or whatever) Mar 12 17:26:00 like you can do that in the OE Mar 12 17:26:51 IIRC there was such need for toolchains anyway Mar 12 17:30:40 What's the "OE"? Mar 12 17:30:48 OpenEmbedded Mar 12 17:31:03 aka yocto Mar 12 17:41:34 yea, I'm lagged :) Mar 12 17:51:44 jow: external kernel tree is useful for bisecting the kernel (for targets close to upstream) Mar 12 18:01:57 I am using the external kernel for kernel development Mar 12 18:03:04 I want to use glibc to run our tools with the sanitizers Mar 12 18:03:09 on the target Mar 12 18:03:30 I think the dm-verify is only usefull for secure boot systems Mar 12 18:03:56 where you want to prevent that someone with access to the hardware can change the software Mar 12 18:06:34 tmn505: do you have a layerscape board? Mar 12 18:14:44 yes Mar 12 18:23:13 tmn505: which one? Mar 12 18:23:20 how much is it? Mar 12 18:24:41 frdm ls1012a Mar 12 18:26:19 have to check the exact price Mar 12 18:27:14 it was around 50 euros on mouser Mar 12 18:28:08 nice Mar 12 18:28:46 BTW this board is eol, so no new batches. There are still some left here and there Mar 12 18:29:30 Hauke: Since you switched to using the in-tree ag71xx driver for 5.4, I was wondering if you might be able to have a look at https://bugs.openwrt.org/index.php?do=details&task_id=2889 or at least let me know what I might do to collect more data about the problem. Mar 12 18:29:56 mamarley: there are a lot of problems with the in kernel driver Mar 12 18:30:56 Hauke: if You have some spare buck there is LS1046A-RDB floating on ebay, looks good but is out of my range. Mar 12 18:33:37 Why are we using it then? Mar 12 19:19:14 mamarley: it probably takes some time to get the upstream driver working on all boards Mar 12 19:19:26 I think ww should switch back to our driver Mar 12 19:19:51 That sounds like a good idea. Mar 12 19:42:52 tmn505: can you give the patch a test I created for x86? it is basically a rebase of your previous patch to use image.mk in x86 Mar 12 19:46:52 aparcar[m]: I'll try to test it this weekend. Mar 12 19:47:30 awesome thank you! Mar 12 20:07:22 Hauke: I was able to build 5.4 with the OpenWRT ag71xx driver successfully. I will try to run it when I get home a bit later. Mar 12 20:22:52 ynezz: if you have a minute I really need some Makefile advise, I'm running in circles here Mar 12 20:32:16 tmn505: looks like still stock at mouser Mar 12 20:32:55 love the arduino headers Mar 12 20:35:47 decent board for the money though. Mar 12 20:36:31 hrm, only single core Mar 12 21:09:01 mamarley: it seems to work okay on the tplink wdr3600 Mar 12 22:23:36 russell--: Yeah, it seems to be hit-or-miss. Mar 12 22:32:45 russell--: there were a commit which added necessary nodes to DTS files for ar934x i believe. Mar 12 22:33:22 however, upstream ag71xx currently does not support setting ethernet clocks as well as gmac configuration (internal delays) Mar 12 22:33:51 I've prepared a patch which switches over to the OpenWrt one, will submit it shortly Mar 12 22:48:24 mamarley: my current work in progress patches for the upstream ag71xx driver are here: https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/ath79-2 Mar 12 22:54:33 Hauke: Thanks! I just tried my own patch reverting to the out-of-tree driver and it worked. Now I will try your tree. Mar 12 23:13:40 Hauke: With your tree, it says "[ 0.565351] ag71xx 19000000.eth: invalid resource\n[ 0.570185] ag71xx: probe of 19000000.eth failed with error -22". Mar 12 23:13:56 It also doesn't find the ethernet switch. Mar 12 23:33:24 mamarley: we probably have to modify every device tree file Mar 12 23:33:54 therfore I think it is easier to switch back to our driver and prepare this in parallel for the next kernel version upgrade Mar 13 00:19:53 OK. Mar 13 01:00:29 blocktrron: Thanks! Your patch works fine on my UAP-LR, but my UAP-AC-PRO is still bootlooping for an unrelated reason. Mar 13 01:15:19 * mamarley is tired of debricking routers. Mar 13 01:34:58 mamarley: just don't brick them in the first place :) Mar 13 01:36:00 forehead Mar 13 01:43:57 serial consoles++ Mar 13 01:46:27 i recovered the three or four devices i saw the probe failure on by switching a radio interface to station mode and fetching the 4.19 image over that Mar 13 01:52:31 I set up serial on my UAP-LR, but the UAP-AC-PROs appear to be glued shut and are still under warranty, so I can't really screw around with them to find out what is causing the loop. Mar 13 01:55:56 Luckily both devices are easy to recover with TFTP though, just hold down the reset button on start and TFTP the image. The UAP-LR will even take an OpenWRT factory image directly, but the UAP-AC-PRO requires to be flashed with the stock firmware first. Mar 13 02:48:15 mamarley: breed bootloader Mar 13 02:48:32 ? Mar 13 02:48:48 you said you're tired of debricking routers **** ENDING LOGGING AT Fri Mar 13 03:00:43 2020