**** BEGIN LOGGING AT Fri Dec 04 02:59:56 2020 Dec 04 03:33:55 what’s the easiest way to force a particular source address to use an explicit default route (next hop + interface) using UCI? Dec 04 03:34:26 my appletv needs to egress via the VPN to home or it won’t work from my hotel room when I travel... Dec 04 05:06:00 Hey :) Anything interesting I miss? Dec 04 06:06:03 I'm not sure why that happened, what was going on, or if I've actually fixed it (Hexchat, new install).. but I really apologize Dec 04 06:09:38 Grommish: try /set net_ping_timeout 300 or whatever value suits. Dec 04 06:11:53 I think Hexchat doesn't ever re-poll for an IP change. When i kicked over my router to enable IPv6, it went nuts with Disconnected (No such device or address) Dec 04 06:12:02 Seems to be a long-standing issue though Dec 04 06:12:24 quitting and recycling the adapter seems to have fixed it Dec 04 07:24:27 gch9812138860: heya, quick question for you, if you don't mind - https://github.com/openwrt/openwrt/pull/3380 - is the MAC swap for ARP expected on ath79, or is something wrong ? Dec 04 07:40:37 stintel: I use following script http://sprunge.us/Lj5i6P and publish to https://sensor.community Dec 04 07:41:06 stintel: I've bought the connector from tme.eu I guess Dec 04 07:48:28 stintel: https://www.tme.eu/cz/en/details/szh-200bk26/signalove-konektory-raster-1-50mm/jst/ and https://www.tme.eu/cz/en/details/zhr-5/raster-signal-connectors-1-50mm/jst/ Dec 04 08:01:45 ynezz: thanks! Dec 04 08:02:11 ok so you read the sysfs node Dec 04 08:02:25 I've been looking at iio/iiod but didn't figure that out yet Dec 04 08:06:04 I'm currently using an sds011, connecting to an esp8266 running esphome, gathering the data in home-assistant and home-assistant posts the data to sensor.community Dec 04 08:07:15 stintel: how accurate is it ? Dec 04 08:09:18 dunno Dec 04 08:20:32 you get what you pay for :) Dec 04 08:21:27 iio works http://sprunge.us/LTpnT0 Dec 04 08:21:59 thats the output of iio_info Dec 04 08:22:53 the values are moving somehow with the air polution, so I guess, that it works to some extent Dec 04 08:23:36 DonkeyHotei: I'd love it to happen, yes. Might not do it personally but could help and give pointers Dec 04 08:26:26 ynezz: yeah iio_info works here too, but I'd like to figure out how I can query iiod over the network Dec 04 08:41:02 stintel: using a custom application? Dec 04 08:42:14 if you just want to run iio_info against the remote server you can use `iio_info -n remote-ip` Dec 04 08:43:43 larsc: I'd actually like to be able to read that from home-assistant Dec 04 08:43:56 but that actuall helps, I guess I can just sniff the traffic when doing your proposed command Dec 04 09:07:39 mangix: should we do the openvpn move? Dec 04 09:37:32 go ahead Dec 04 09:47:22 ynezz: why tee -a? (in your luftdaten script) Dec 04 10:01:12 whoa Dec 04 10:01:17 there's a AC23 Dec 04 10:01:20 *C23 Dec 04 10:06:16 huh. https://git.musl-libc.org/cgit/musl/commit/?id=821083ac7b54eaa040d5a8ddc67c6206a175e0ca . i wonder why Dec 04 10:26:08 karlp: I don't want to delete the previous data? Dec 04 10:30:17 but that's the file you're posting? doesn't it just keep getting bigger and bigger? Dec 04 10:31:12 ah, I missed that you were passing $json directly to curl Dec 04 10:42:59 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_omap.html has been updated. (0% images and 97.2% packages reproducible in our current test framework.) Dec 04 11:11:33 Is there some easy way to do hotplug events. For example a new DHCP lease -> run some python script? Dec 04 11:12:15 barhom: sure Dec 04 11:14:00 barhom: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=b32689afd6a661339861086c669e15c936293cf8 Dec 04 11:14:27 barhom: so essentially place a script into /etc/hotplug.d/dhcp/ Dec 04 11:14:56 it will get invoked with env vars ACTION (add/remove/update), MACADDR, IPADDR and HOSTNAME for each DHCP lease state change Dec 04 11:15:18 not sure if you can place a python script in /etc/hotplug.d/dhcp/ directly, if not place a shell script there exec'ing the python one Dec 04 11:15:33 jow, awesome. I'll get crackin'. Shell scripts are fine Dec 04 11:15:52 you might need to restart dnsmasq after adding your hotplug script Dec 04 11:16:09 there's some optimization in the init script to skip setting up dhcp handlers if no hotplug scripts are installed Dec 04 11:16:22 I'm trying to find the best way to create some kind of full-list of "currently connected" and "previouosly connected" devices. Dec 04 11:16:42 One way is to listen to DHCP, the other is to check "ip -4 nei" Dec 04 11:18:19 jow, would be cool if that list, ADD/REMOVE/UPDATE would also contain the wifi-ifname so I know what wifi they are connected to Dec 04 11:20:03 I just saw that "ip -4 nei" can also be hotlpugged into /etc/hotplug.d/neigh/* - great stuff Dec 04 11:20:20 determining the wifi-ifname is not trivial Dec 04 11:20:36 usually the answer will be "it came from br-lan" Dec 04 11:21:42 jow, yeh I've noticed that. Using a lot of iptables physmod to see what interface packets are coming in for firewall rules Dec 04 11:22:26 The way I will be doing it will be to check assoclist in the wifis to see if I find a match - unless you know of any other good way Dec 04 11:22:28 you could try to cross-correlate with "iw dev wlanX station dump" Dec 04 11:22:34 yeh exactly Dec 04 11:22:41 no it is the only way, did something quite similar a while back fro some luci project Dec 04 11:22:54 even tried to figure out the lan port in case of wired clients Dec 04 11:23:08 thats even harder when the LAN ports are SoC bridged into eth0 Dec 04 11:23:09 and if the swconfig or dsa switch supported exposing the fdb Dec 04 11:23:20 which is not possible on all devices Dec 04 11:23:20 I think blogic had a project to collect all this kind of information and expose it in a unified way Dec 04 11:23:36 zorun, that would be nice in order to not reinvent the wheel Dec 04 11:23:39 right, blogic worked on something very similar as well Dec 04 11:24:06 I wanted to use it for this dashboard project, but in the end I think the code was not ready / available Dec 04 11:24:16 can't remember the name Dec 04 11:25:08 jow, did you find any good way to add something into swconfig in order to differentiate packets coming from port 4 vs 5? The reason is that I have another task to see if I can route port 4 differently from port 5. Both are eth0 bridged to br-lan. And it is a ipq4019 SoC Dec 04 11:25:09 not juci? Dec 04 11:25:25 (re dashboard project) Dec 04 11:25:36 no it's in luci (it was merged btw) Dec 04 11:26:39 luci-mod-dashboard Dec 04 11:27:00 luci-mod-dashboard, thats the thing blogic worked on? Ill check it out Dec 04 11:27:20 sorry, that wasn't clear: luci-mod-dashboard is the project I worked on with students Dec 04 11:27:35 and we wanted to use blogic's project (for which I can't remember the name) but in the end we didn't Dec 04 11:28:02 so the dashboard has the same kind of information as the luci status page IIRC Dec 04 11:36:14 barhom: depends on the switch ICs, some allow exposing the learning table and some swconfig drivers allow that via the userspace tool Dec 04 11:36:32 barhom: but in the end I decided against that, since DSA will likely provide that functionality in a generic manner Dec 04 11:58:35 bleh, what was the trick to fix "... has a dependency on curl, which does not exist" after things moved from core to packages? Dec 04 11:58:49 I've rm'd tmp, feeds clean'ed missing somethignn else? Dec 04 12:00:56 nvm, repeated it all enough, dance completed Dec 04 12:09:33 https://github.com/blogic/utopology ? Dec 04 12:42:56 zorun, jow, blogic replied that this is the project, https://github.com/blogic/udevmand Dec 04 12:43:59 ynezz, seems to be almost the same as the one you linked Dec 04 13:26:05 karlp: recently I was able to fix such warnings with scripts/feeds install -f Dec 04 14:23:13 stintel: ping Dec 04 14:23:28 stintel: does your lldp update from 5 days ago work for you ? Dec 04 14:23:57 for me neigh discover does not work and the log says its receiving short frames Dec 04 14:24:51 blogic: haven't noticed any issues Dec 04 14:25:31 blogic: but apparently it doesn't even build on the buildbots Dec 04 14:29:08 anyway I'm definitely seeing my OpenWrt hosts with lldpd 1.0.7 in my switch, and just tested the other way around, also seeing my switch on a random OpenWrt device running 1.0.7 Dec 04 14:49:10 hello, can anyone tell me whether OpenWrt's support for Qualcomm IPQ806X platforms includes hardware offload support via NSS? Dec 04 14:49:37 gdb seems to require PKG_ASLR_PIE:=0 on aarch64 with PKG_ASLR_PIE_ALL=y Dec 04 14:50:14 the feature discussed here specifically: https://www.youtube.com/watch?v=gci-pB9Fshk Dec 04 14:51:35 but it builds fine on x86/64, so PKG_ASLR_PIE:=0 unconditionally is probably not the way to go Dec 04 14:52:16 suggestions welcome :) Dec 04 15:01:23 re: gdb PKG_ASLR_PIE: would this be acceptable? https://gist.github.com/ff697f995bfd9846bee265defbe3465d Dec 04 15:07:10 should i be getting a bunch of sstrip usage information printed out? Dec 04 15:07:47 nvm my question, apparently doesn't work anyway Dec 04 15:09:07 I guess -fpic is already in TARGET_CFLAGS Dec 04 15:09:20 pic of PIC depending on target, iirc, but yeah Dec 04 15:10:39 yes, FPIC=-fpic on all but ppc Dec 04 15:11:03 sounds abotu right. Dec 04 15:11:23 but apparently on arm sparc and m68k there are limits that can cause this to fail Dec 04 15:11:31 gcc man says to recompile with -fPIC instead in this case Dec 04 15:11:41 I read that as only in this case though Dec 04 15:11:51 I think it's "just always use PIC on those targets" Dec 04 15:11:52 so using -fPIC by default on arm seems also not the way to go Dec 04 15:13:18 If the GOT size for the linked executable exceeds a machine-specific maximum size, you get an error message from the linker indicating that -fpic does not work; in that case, recompile with -fPIC instead. Dec 04 15:14:11 and the downside for using PIC all the time? Dec 04 15:14:24 because ~zero projects are interested in compiling twice Dec 04 15:14:39 and setting it per package manually sounds like a disaster as well. Dec 04 15:15:36 karlp: I have no clue, just going by what the manual says Dec 04 15:16:16 are you hoping to get a microopt on only using pic if the app is smaller enough, instead of PIC? Dec 04 15:16:35 have you got some measurements on how much you'd save, and how many packages would benefit?Ð Dec 04 15:17:11 I can try and get some of those probably Dec 04 15:17:43 again, I have no clue, just trying to fix a problem in the optimal way, going by what the man says Dec 04 15:18:12 well, "try it one way, and if it fails try it the other way" is pretty absurd for people to actually rely on on a large project Dec 04 15:18:32 you'll get package breakage on version updates for instance where the sizes cross unknown boundaries Dec 04 15:18:47 which is why I think it's "just use PIC on thos platforms where you might need it" Dec 04 15:21:19 my earlier paste works if it's set before include package.mk, but that's to go the fix per package route Dec 04 15:21:23 I'll do some size comparisons Dec 04 15:27:24 stintel: ok, my ubuntu can see the devices, but devices see nothing Dec 04 15:27:30 tried on 3 different units Dec 04 15:27:39 stintel: i'll do a local revert to verify Dec 04 15:27:47 blogic: some funky network setup? Dec 04 15:27:55 or maybe non-funky. I'm using vlan on all interfaces Dec 04 15:28:17 the tree worked 15 days ago Dec 04 15:28:24 did a pull, now its not working Dec 04 15:28:36 same config, same everything Dec 04 15:28:37 Hi people when will we be putting out the new stable release of 18.06.9? Dec 04 15:36:27 blogic: aside from your runtime problem, what distro are you building on? Dec 04 15:36:43 ubuntu 20.04 Dec 04 15:37:47 ok, so modern, as is my gentoo Dec 04 15:39:19 buildbot slave containers are Debian 10, I'll try reproduce it on a D10 VM Dec 04 15:46:13 how does a package get the staging_dir/target/usr/lib dir added to the library search path? I've got nothing special in my package, looks just like others, but it's failinnng to find a library? https://paste.jvnv.net/view/o9i3P Dec 04 15:46:22 I can't work out why this package would be any different? Dec 04 15:47:06 karlp: is cjson installed to the default include path ? Dec 04 15:47:21 i recall that we had problems and all the json libs get installed to a prefix Dec 04 15:47:25 the h files are, yeah, in installdev, I had that wrong earlier Dec 04 15:47:38 it's got it' son cJSON.h file though so shoulnd't conflict Dec 04 15:47:48 and the so is libcjson.so too Dec 04 15:47:58 and it's just not seeing it at all, not picking thr wrong one. Dec 04 15:48:54 I've already asked if upstream can use the standard instead of , so it matches what cjson doesn normally and waht we're doign with json-c and friends too. Dec 04 16:41:37 karlp: what do you say? https://git.openwrt.org/1c24ce1e Dec 04 16:44:45 I'll just send it to the ML Dec 04 16:59:32 stintel: Can you believe I actually spent about 5 minutes looking at that condition, trying to understand the difference between the two branches? Dec 04 16:59:53 I mean, -fpic vs -fPIC? Who names these things? O_o Dec 04 17:00:01 :P Dec 04 17:10:09 ERROR: toolchain/kernel-headers failed to build. Dec 04 17:10:10 lulz Dec 04 17:10:13 debian ¯\_(ツ)_/¯ Dec 04 17:11:26 stintel: I've seen "fun" stuff happening after a glibc update… Dec 04 17:11:32 Are you on Sid? Dec 04 17:11:57 rsalvaterra: this is a fresh git clone on a d10 Dec 04 17:12:46 Ah, nevermind, then. Dec 04 17:13:08 trying to reproduce lldpd build failure Dec 04 17:13:58 I maintain only packages that I use, and lldpd I'm using on x86/64, mips, mips64, arm, arm64, and it builds and works fine on all of those for me Dec 04 17:14:14 so imagine my surpise that it's been broken for a year or so on the buildbots Dec 04 17:14:21 stintel: looks fine to me, somewhat as expected that there's ~no savings on having it per package. Dec 04 17:14:58 karlp: thanks, I'll wait a short time for response on ML, probably commit it Sunday when no objections Dec 04 17:15:02 stintel: That's indeed perplexing. Dec 04 17:15:43 /bin/sh: 1: rsync: not found Dec 04 17:15:49 wut Dec 04 17:16:52 Heh… nowadays you can't even build the kernel (bindeb-pkg target, at least) without rsync. :P Dec 04 17:17:37 stintel: lldpd compiles for me in OpeNWrt on Debian 10 Dec 04 17:19:17 Hauke: well then I'm completely lost Dec 04 17:19:25 stintel@mirror-02:~$ find /home/mirror/downloads/snapshots/packages/ -name 'lldp*' -ls Dec 04 17:19:26 173474088 132 -rw-r--r-- 1 mirror nogroup 133069 Jan 29 2020 /home/mirror/downloads/snapshots/packages/armeb_xscale/base/lldpd_1.0.3-2_armeb_xscale.ipk Dec 04 17:19:26 173289704 136 -rw-r--r-- 1 mirror nogroup 137335 Mar 28 2020 /home/mirror/downloads/snapshots/packages/arm_cortex-a9_vfpv3/base/lldpd_1.0.5-1_arm_cortex-a9_vfpv3.ipk Dec 04 17:19:27 that's it Dec 04 17:19:33 and both of them are ancient Dec 04 17:21:10 stintel: We have no target for armeb_xscale and arm_cortex-a9_vfpv3 any more Dec 04 17:21:18 so they are not getting build at all any more Dec 04 17:21:49 stintel: here is the faillog: https://downloads.openwrt.org/snapshots/faillogs/arm_cortex-a9_vfpv3-d16/base/lldpd/compile.txt Dec 04 17:22:10 Hauke: I know, I wanted to point out lldpd is missing for everything Dec 04 17:23:03 karlp: according to your paste, the libcjson package did not properly stage an unversioned so symlink Dec 04 17:23:36 karlp: maybe a broken InstallDev macro (possibly copy-pasted from /install and forgot to adjust it to copy/install the unversioned symlink as well) Dec 04 17:24:09 karlp: so .../libcjson.so -> .../libcjson.so.1 is missing, that's why -lcjson can't find it Dec 04 17:25:15 ahhhh thank yous omcuh, have been tearing my hair hout :) Dec 04 17:25:52 stintel: error: READLINE_LIBS@: No such file or directory - looks like broken autoconf substitution Dec 04 17:27:18 * karlp cheers for jow Dec 04 17:29:05 stintel: the configure output in build bot and on my system is different Dec 04 17:29:13 I have "checking for mt... mt" Dec 04 17:35:06 trying to replicate that lldpd issue in docker here Dec 04 17:48:19 I cannot repro it on my d10 VM Dec 04 17:56:09 heh, the buildslave Dockerfile doesn't even build Dec 04 17:56:28 are these things not scheduled to rebuild automatically every now and then? Dec 04 17:56:45 libc6-dev : Breaks: libgcc-8-dev (< 8.4.0-2~) but 8.3.0-6 is to be installed Dec 04 17:57:43 oh, they're using testing sources Dec 04 17:57:52 jow: is that intentional? it would seem strange to me tbh Dec 04 17:59:13 stintel: hm? Dec 04 17:59:38 docker/buildslave/Dockerfile:RUN echo 'deb http://deb.debian.org/debian testing main' \ Dec 04 17:59:58 ah yes, that was for newer buildsalve iirc Dec 04 18:00:21 ok but testing is now something else Dec 04 18:00:29 so it's better to pin it to buster to avoid weirdness ? Dec 04 18:00:30 anyhow, the image we're using is openwrtorg/buildslave@sha256:e3ca2384275306c3e9caf975b4eacd54b6bb3ae08c962dea33382c99819e70b6 Dec 04 18:00:57 (I can't reproduce in there either btw Dec 04 18:01:11 gotta love heisenbugs Dec 04 18:01:25 so my hunch is that the issue is caused by the presence of something else Dec 04 18:01:42 another package being picked by autoconf or similar Dec 04 18:02:00 but I just noticed that I tested a full buildroot, will retest with the SDK within the container Dec 04 18:02:44 ah right, I also tested buildroot Dec 04 18:03:47 I've never used the SDK before Dec 04 18:09:41 builds in SDK too Dec 04 18:09:46 heisenbug indeed Dec 04 18:10:01 jow: regarding your 11b comment: Dec 04 18:10:11 luci has its own defaults? Dec 04 18:10:52 adrianschmutzler: yes, the form definition records whether a bool option defualts to true or false Dec 04 18:11:16 if an option defaults to true, then ticking the checkbox will remove the option Dec 04 18:11:27 unticking it will write option foo 0 Dec 04 18:11:47 and vice versa, if it is marked as default false then ticking the option will write option foo 1 and unticking it will remove option foo Dec 04 18:12:08 so, essentially all boolean options in uci that are represented in luci have "redundant" defaults? Dec 04 18:12:15 yes Dec 04 18:12:43 not just bools, some others with implicit defaults as well Dec 04 18:13:06 can you quickly provide a link to the definitions for luci in the code, just for one case Dec 04 18:13:15 we have various other options with implicit default values as well (e.g. grep set_default in the various wifi scripts) Dec 04 18:13:22 i.e. an example Dec 04 18:14:24 adrianschmutzler: https://github.com/openwrt/luci/blob/master/modules/luci-mod-network/htdocs/luci-static/resources/view/network/wireless.js#L898 Dec 04 18:14:44 grep -r '\.default = ' in the luci src tree Dec 04 18:15:14 Hi all, I don't know if it's the right place to bposte this, so sorry if not. is there someone who can talk with me about broadcom powerline ? Before starting playing with openwrt i would validate that it's possible even if open-plc-utils is only for atheros, qualcom. Dec 04 18:15:32 okay, thanks. I have almost never dealt with luci in code, so this might help me to get a better grip there Dec 04 18:16:25 so, the change you requested would be to change line 899 to o.default = o.disabled; ? Dec 04 18:16:47 (or probably remove that line) Dec 04 18:16:48 yes Dec 04 18:16:54 either will work Dec 04 18:16:57 I'm going to send something that removes the ine Dec 04 18:16:59 *line Dec 04 18:17:03 thanks Nick_Lowe Dec 04 18:17:11 Sorry for forgetting to bump the package, it's needed here Dec 04 18:17:12 just add a link to that other PR to the LuCI pr Dec 04 18:17:15 okay, perfect. thanks for enlightening me. Dec 04 18:17:16 Will do Dec 04 18:18:33 adrianschmutzler: in a perfect world we would have no default-enabled bools Dec 04 18:19:06 so instead of any foo (= 1) we should instead provide a nofoo (= 0) Dec 04 18:19:07 I'm far from any judgement, this fact was just entirely new to me Dec 04 18:19:26 but that ship has sailed long ago Dec 04 18:19:46 jow: so, you mean that variables should be built/designed so that they all have default=0? Dec 04 18:19:49 options are usually just added and named randomly without any curation or schema Dec 04 18:20:05 adrianschmutzler: yes Dec 04 18:20:48 if something happens to be usually enabled and we want to provide the facility to turn it off, we shouldn't have an `option enable_something` which is implicitely true, but instead there should be a `disable_foo` which defaults to false Dec 04 18:20:53 well, yes, once established you essentially can only create a new, additional "proper" variable, and that won't really help much ... Dec 04 18:21:10 however that is easier said than done, especially in cases such as legacy_rates where the efault eventually changes Dec 04 18:21:50 and even if that wasn't the problem, typically nobody cares about such stuff Dec 04 18:21:54 and given that we do not really have uci schemas one usually has to encode these things in various places Dec 04 18:22:10 init scripts, luci etc. Dec 04 18:25:12 hmm, well, on a second thought it's logical that luci needs this Dec 04 18:25:26 not for writing, but for reading Dec 04 18:25:54 and there really is not smart way out of this ... Dec 04 18:27:23 not in the short term Dec 04 18:27:40 long term it might be worthwhile to introduce JSON-schemas or similar, then derive parsing, validation etc. from it Dec 04 18:28:05 (e.g. have something taking uci config + json schema and exporting all values as shell variables instead of manual config_get, config_foreach etc. code) Dec 04 18:29:02 I wonder how much bloat those schemas would introduce Dec 04 18:29:10 imagining them for all packages ... Dec 04 18:30:12 they would add some, but overall I'd guess it evens out if the init script parsing code gets reduced to just two or three lines Dec 04 18:30:17 bloat = additional space requirement Dec 04 18:30:56 it would probably allows us dropping jshn as well Dec 04 18:31:12 would be worth doing it for that alone Dec 04 18:33:12 Anyway, eventually I assume the size would still be tiny compared to the actual code of the packages Dec 04 18:34:17 the biggest problem will probably be that it doesn't sound like fun to introduce such a thing Dec 04 18:42:41 yeah, it is a tedious task, but worth doing Dec 04 18:43:37 it also has so many advantages, less per-package config parsing code, ability to validate configs, ability to warn about unknown or mistyped options, ability to autogenerate uis to some extent etc. Dec 04 18:54:13 I don't think the writing will be the main problem, but the step-wise integration into the repo ... Dec 04 19:25:48 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_lantiq.html has been updated. (98.2% images and 97.4% packages reproducible in our current test framework.) Dec 04 20:03:52 would it be acceptable to add support for a device that requires overwriting an RSA private key in a SPI NOR flash with a clamp, or adding TTL header, a level shifter and bridging 4 lanes on the PCB to get serial console to be able to install via tftpboot/initramfs? Dec 04 20:03:55 or should I not even bother :P Dec 04 20:04:45 stintel: I think it would be ok Dec 04 20:05:12 oh, then I might do some cleanup and send an RFC series in the future Dec 04 20:05:47 I'm talking about https://www.tp-link.com/us/business-networking/omada-sdn-controller/oc200/ Dec 04 20:08:40 it's mvebu, dual core, 1GB RAM, 1MB SPI NOR (u-boot), 4GB eMMC, PoE-PD, 100x98x25mm in size. only 100Mbps but I don't tend to use it as a router Dec 04 20:09:03 but I'm thinking of a DNS/DHCP/radius cluster Dec 04 20:09:35 (making my HA network even more HA :P) Dec 04 20:15:04 stintel: how expensive? Dec 04 20:16:03 Hauke: ~EUR75 Dec 04 20:16:43 beats messing with an RPi + PoE HAT + finding a case that fits both Dec 04 20:16:47 not to mention sd cards suck Dec 04 21:16:03 People are mean on the internet :( https://forum.openwrt.org/t/online-imagebuilder-and-upgrade-server/18110/187 Dec 04 21:16:25 aparcar[m]: keyboard warriors :) Dec 04 21:20:49 how is the "Package mosquitto-ssl is missing dependencies for the following libraries:" calculated again? objdump -x on ever file installed in the package grep for NEEDED? Dec 04 21:21:09 I guess I need to add depends optionally Dec 04 21:21:54 oh that's been a while since I've seen that Dec 04 21:23:12 well, this is a new dep for the pacage Dec 04 21:23:17 and it's only in some portions ofit Dec 04 21:23:23 trying to unwind what I need where. Dec 04 21:23:36 I'm trying to find something in my irc logs Dec 04 21:23:38 but failing at m Dec 04 21:23:59 I used to replace a false with true or something somewhere to be able to build Dec 04 21:24:29 aha, https://github.com/openwrt/packages/issues/7794 Dec 04 21:24:49 ok it will require some deeper diving into the code Dec 04 21:25:05 if [ -f "$(PKG_INFO_DIR)/$(1).missing" ]; then \ Dec 04 21:25:22 ah no, it's higher up in that file Dec 04 21:25:28 I'm just going to make it a hard dep I think :) Dec 04 21:25:53 $(SCRIPT_DIR)/gen-dependencies.sh Dec 04 21:25:54 ok Dec 04 21:26:04 * stintel stops looking :) Dec 04 21:27:52 I actually think I did the right thing Dec 04 21:28:04 DEPENDS:= +MOSQUITTO_DYNAMIC_SECURITY:cjson Dec 04 21:28:18 and I already had that config for only installing that portion Dec 04 21:28:25 * stintel smells breakage on his next build :P Dec 04 21:28:28 but thanks, I'm curious to read gen-depsn anyway Dec 04 21:28:39 hope not,but mosquitto 2.0 is a major release :) Dec 04 21:28:46 it will at least work for my own usages! Dec 04 21:28:47 oh Dec 04 21:29:00 haven't been following much of anything lately Dec 04 21:29:15 only came out yesterday Dec 04 21:29:16 I wanted to release vallumd 1.2 Dec 04 21:29:47 but this guy who asked me to add EL8 support is MIA, and it was segfaulting for him :( Dec 04 21:30:24 EL8? Dec 04 21:30:50 Enterprise Linux 8, e.g. RHEL, CentOS, Scientific Linux, and Oracle Unbreakable Linux Dec 04 21:31:31 hrm, "WARNING: Makefile 'package/feeds/packages/mosquitto/Makefile' has a dependency on 'cjson', which does not exist Dec 04 21:31:34 no wonder :) Dec 04 21:31:41 pp[s Dec 04 21:31:46 oops* Dec 04 21:32:16 I'm think I'm going to regret attempting to use the canonincal "cJSON" naming, with mixed case.... :) Dec 04 21:41:11 karlp: there is always force push Dec 04 21:41:12 * stintel hides Dec 04 21:41:50 no, it's ok, still just hacking it all locally:) Dec 04 21:41:56 I'm not goign to change it once it's live Dec 04 21:42:17 the nerve, even suggesting push -f to a public repo :) Dec 04 21:42:30 hey you should know me a bit by now :P Dec 04 21:43:16 * karlp grins Dec 04 21:44:01 if I can get this mosquitto finished, it's time to get back to the _other_ long overdue project, sunxi on spi-nor... Dec 04 21:47:35 is anyone interested in a WatchGuard Firebox M200? it's based on Freescale T1042 CPU (PPC64), uses SD card for storage, 2GB RAM, 8xGbE port Dec 04 21:47:59 the only caveat is that its PSU is broken, but it's ATX compatible Dec 04 21:48:43 I'd be willing to ship it on my expense, if you'd be willing to try and get support for it in OpenWrt :) Dec 04 21:49:16 it's PPC64 without altivec, so even musl needs patching because they hardcoded altivec instructions in ASM Dec 04 21:49:33 so it's probably going to be a pain :) Dec 04 21:53:40 stintel: lldp does not compile for me in CentOS7 and Fedora 33. I agree with jow when he saya it's picking something else jp. Dec 04 21:54:42 mangix: builds fine in Gentoo, or a Debian 10 VM. or for blogic on Ubuntu 20.04. Dec 04 21:54:46 don't know what else I can tryt Dec 04 21:55:33 right. I assume it's picking up a host readline or something Dec 04 21:55:51 actually I do have CentOS 6, 7 and 8 handy Dec 04 21:55:57 so I can try to repro there too Dec 04 21:57:23 I don't know what dependencies lldp has. try to install thrm with thr package manager. Dec 04 22:25:04 jow: couldn’t get “config rule / option src 192.168.3.6 / option lookup 200”… What am I missing? Dec 04 22:25:18 * couldn’t get it working Dec 05 01:12:42 karlp: use mixed case for PKG_NAME but not for the package definition Dec 05 01:12:57 they don't have to be the same Dec 05 01:13:16 PKG_NAME is mostly used for downloading the tarball Dec 05 01:50:03 stintel: that thing looks massive Dec 05 01:50:36 what thing > Dec 05 01:50:44 firebox Dec 05 01:50:48 it is Dec 05 01:50:54 it's 1U rackmount Dec 05 01:50:55 want it ? Dec 05 01:51:57 how many arms for it? :) Dec 05 01:52:02 arms ? Dec 05 01:52:09 it's a joke Dec 05 01:52:12 and legs.. Dec 05 01:52:19 expensive stuff require an arm and a leg Dec 05 01:52:26 I wrote on my expense Dec 05 01:52:54 if you're in EU and it's feasible to send it without insane shipping costs and possible import taxes ... Dec 05 01:53:11 i'm not in EU unfortunately. Dec 05 01:53:36 are you interested? Dec 05 01:53:51 maybe sending it as gift will avoid those taxes Dec 05 01:54:02 and it wouldn't even be a lie Dec 05 01:54:34 I got it off ebay hoping I'd be able to get it done myself Dec 05 01:54:57 but I'm too dumb to get it to work, and I also lack the time Dec 05 01:55:28 you want openwrt on it? Dec 05 01:55:30 yes Dec 05 01:55:41 I have it, it boots, but network interfaces don't work Dec 05 01:55:56 what driver does it use? Dec 05 01:55:57 and I have the craziest crashes too Dec 05 01:56:38 huh. is that first port a serial port? Dec 05 01:56:47 yes Dec 05 01:57:08 neat. Dec 05 01:57:10 like almost all enterprise network hw, console is via RJ45 Dec 05 01:57:34 mangix: https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=shortlog;h=refs/heads/m200 Dec 05 01:57:37 it's a mess :P Dec 05 01:58:50 oh, that even includes the musl hack to disable altivec instructions Dec 05 01:59:20 I think it's fancy hardware, mostly supported by upstream kernel, which is why I decided to give it a go Dec 05 01:59:34 but I tend to get into things that are over my head Dec 05 02:02:10 that musl hack looks questionable Dec 05 02:02:25 of course Dec 05 02:02:32 I asked in #musl, still waiting for a proper fix Dec 05 02:02:35 because nobody knows Dec 05 02:02:40 it's the proper fix for this hardware Dec 05 02:02:50 because it simply doesn't do those instructions Dec 05 02:03:01 but it should be made conditional Dec 05 02:03:07 which I don't know how to do Dec 05 02:03:18 start to get why I want to donate the hardware? :) Dec 05 02:03:19 nobody knows meaning they didn't write the code? Dec 05 02:03:34 people asked around, if anybody knew how to properly fix it Dec 05 02:03:39 discussion died Dec 05 02:03:47 and half a year later it's still 'broken' Dec 05 02:04:38 that is amusing Dec 05 02:04:45 did you try glibc? Dec 05 02:04:53 I don't care about glibc Dec 05 02:05:08 OK Dec 05 02:05:15 * mangix wonders why it's in the tree Dec 05 02:05:25 because arc Dec 05 02:05:38 arc does not use glibc Dec 05 02:05:50 nothing does Dec 05 02:06:04 since when? Dec 05 02:06:10 if nothing does, it's time to nuke glibc Dec 05 02:06:19 arc uses uClibc-ng Dec 05 02:06:25 which felix wants to nuke Dec 05 02:06:35 and replace with glibc Dec 05 02:06:39 oh Dec 05 02:06:43 which will break almost every package Dec 05 02:06:50 I'm all in favor of nuking uClibc Dec 05 02:06:54 *and* glibc Dec 05 02:07:03 and anything that doesn't work with musl can fuck off Dec 05 02:07:21 ARC is the big problem there Dec 05 02:07:30 well they promised solutions Dec 05 02:07:32 years ago Dec 05 02:07:38 maybe it's time to tell them goodbye Dec 05 02:07:44 does anything even use that arch? Dec 05 02:07:55 no. just development boards. Dec 05 02:07:59 easy then Dec 05 02:08:05 nuke it and go on with life Dec 05 02:08:21 they can come back when they are musl compatible Dec 05 02:08:40 git grep \!arc | wc -l Dec 05 02:08:42 11 Dec 05 02:09:09 that's in the packages feed Dec 05 02:09:12 I mean, look at us, we didn't even manage to get a 20.* release yet Dec 05 02:09:29 holding on to crap like arc doesn't help at all Dec 05 02:09:46 we should just nuke arc, glibc, all those corner cases Dec 05 02:10:06 I agree Dec 05 02:10:36 although to be fair, arc isn't the (nor even 'a' reason) for the delays in 20.xy.0 - that doesn't imply that I'd care about arc, I don't Dec 05 02:11:00 just the fact we have anything other than musl takes away focus Dec 05 02:11:04 it should just be nuked Dec 05 02:11:27 feel free to send a patch series to nuke all that crap, I'll gladly ack it Dec 05 02:11:56 to be fair, synopsis does post kernel bumps and whatnot on the mailing list Dec 05 02:12:06 it will also take away discussions like "it build with glibc" or "i tested it with uclibc" Dec 05 02:12:09 no solutions for musl though Dec 05 02:12:26 kernel bumps are mostly automated, not good enough Dec 05 02:12:59 stintel: I don't think builds with x is a concern. there are a fair amount of packages that do not build Dec 05 02:13:13 until I started fixing them. Dec 05 02:15:41 wow this device has all ethernet ports as separate interfaces? Dec 05 02:18:25 that's what I hoped initially Dec 05 02:18:33 but it doesn't Dec 05 02:18:46 looks like 3 interfaces from reading the DTS Dec 05 02:18:49 or at least that's how I understand it Dec 05 02:19:56 speed = <2500>; Dec 05 02:20:05 uhhhh, 2.5gbps? Dec 05 02:20:23 yep Dec 05 02:20:30 soc -> switch = 2500 Mbps iirc Dec 05 02:21:14 how old is this device? Dec 05 02:21:18 ~5y ? Dec 05 02:21:59 ah just saw the year Dec 05 02:22:01 2014 Dec 05 02:23:38 I think before the 20.x branch I should get the multi cpu DSA patch in here. Dec 05 02:24:59 build #239 of mpc85xx/generic is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mpc85xx%2Fgeneric/builds/239 blamelist: Klaus Kudielka Dec 05 02:25:05 build #237 of layerscape/armv8_64b is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/layerscape%2Farmv8_64b/builds/237 blamelist: Klaus Kudielka Dec 05 02:25:07 build #196 of apm821xx/nand is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/apm821xx%2Fnand/builds/196 blamelist: Klaus Kudielka Dec 05 02:25:13 build #239 of ramips/rt3883 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ramips%2Frt3883/builds/239 blamelist: Klaus Kudielka Dec 05 02:25:14 build #238 of ar71xx/mikrotik is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ar71xx%2Fmikrotik/builds/238 blamelist: Klaus Kudielka Dec 05 02:25:21 build #242 of mvebu/cortexa72 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mvebu%2Fcortexa72/builds/242 blamelist: Klaus Kudielka Dec 05 02:25:22 build #242 of armvirt/32 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/armvirt%2F32/builds/242 blamelist: Klaus Kudielka Dec 05 02:25:28 build #235 of mediatek/mt7622 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mediatek%2Fmt7622/builds/235 blamelist: Klaus Kudielka Dec 05 02:25:30 build #230 of mediatek/mt7623 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mediatek%2Fmt7623/builds/230 blamelist: Klaus Kudielka Dec 05 02:25:36 build #228 of cns3xxx/generic is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/cns3xxx%2Fgeneric/builds/228 blamelist: Klaus Kudielka Dec 05 02:25:38 build #237 of mvebu/cortexa9 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mvebu%2Fcortexa9/builds/237 blamelist: Klaus Kudielka Dec 05 02:25:44 build #236 of mvebu/cortexa53 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mvebu%2Fcortexa53/builds/236 blamelist: Klaus Kudielka Dec 05 02:25:45 oh hmm. it requires DTS changes. That's gonna take some time to figure out. Dec 05 02:25:45 build #242 of archs38/generic is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/archs38%2Fgeneric/builds/242 blamelist: Klaus Kudielka Dec 05 02:25:52 build #234 of x86/geode is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/x86%2Fgeode/builds/234 blamelist: Klaus Kudielka Dec 05 02:25:53 build #229 of kirkwood/generic is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/kirkwood%2Fgeneric/builds/229 blamelist: Klaus Kudielka Dec 05 02:26:00 build #230 of ramips/rt288x is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ramips%2Frt288x/builds/230 blamelist: Klaus Kudielka Dec 05 02:26:00 build #225 of ath25/generic is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ath25%2Fgeneric/builds/225 blamelist: Klaus Kudielka Dec 05 02:26:08 build #179 of ath79/tiny is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ath79%2Ftiny/builds/179 blamelist: Klaus Kudielka Dec 05 02:26:08 build #186 of ipq40xx/generic is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ipq40xx%2Fgeneric/builds/186 blamelist: Klaus Kudielka Dec 05 02:26:11 mangix: so that takes you off the list of potential candidates for the m200 :P Dec 05 02:26:15 build #184 of lantiq/xway_legacy is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/lantiq%2Fxway_legacy/builds/184 blamelist: Klaus Kudielka Dec 05 02:26:16 build #184 of sunxi/cortexa8 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/sunxi%2Fcortexa8/builds/184 blamelist: Klaus Kudielka Dec 05 02:26:23 build #199 of x86/legacy is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/x86%2Flegacy/builds/199 blamelist: Klaus Kudielka Dec 05 02:26:24 build #202 of mxs/generic is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mxs%2Fgeneric/builds/202 blamelist: Klaus Kudielka Dec 05 02:26:31 build #200 of lantiq/xrx200 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/lantiq%2Fxrx200/builds/200 blamelist: Klaus Kudielka Dec 05 02:26:31 build #192 of brcm2708/bcm2709 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/brcm2708%2Fbcm2709/builds/192 blamelist: Klaus Kudielka Dec 05 02:26:39 build #201 of brcm2708/bcm2708 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/brcm2708%2Fbcm2708/builds/201 blamelist: Klaus Kudielka Dec 05 02:26:39 build #203 of octeon/generic is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/octeon%2Fgeneric/builds/203 blamelist: Klaus Kudielka Dec 05 02:26:46 build #185 of x86/generic is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/x86%2Fgeneric/builds/185 blamelist: Klaus Kudielka Dec 05 02:26:47 build #181 of at91/sama5 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/at91%2Fsama5/builds/181 blamelist: Klaus Kudielka Dec 05 02:26:54 build #184 of ath79/generic is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ath79%2Fgeneric/builds/184 blamelist: Klaus Kudielka Dec 05 02:26:54 build #184 of samsung/s5pv210 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/samsung%2Fs5pv210/builds/184 blamelist: Klaus Kudielka Dec 05 02:26:56 stintel: one issue is I have nowhere to store it Dec 05 02:27:01 build #180 of mpc85xx/p2020 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mpc85xx%2Fp2020/builds/180 blamelist: Klaus Kudielka Dec 05 02:27:02 build #184 of brcm63xx/smp is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/brcm63xx%2Fsmp/builds/184 blamelist: Klaus Kudielka Dec 05 02:27:05 it looks like a nice device though Dec 05 02:27:09 build #189 of ramips/mt7620 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ramips%2Fmt7620/builds/189 blamelist: Klaus Kudielka Dec 05 02:27:10 build #182 of ramips/mt7621 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ramips%2Fmt7621/builds/182 blamelist: Klaus Kudielka Dec 05 02:27:17 build #201 of layerscape/armv7 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/layerscape%2Farmv7/builds/201 blamelist: Klaus Kudielka Dec 05 02:27:18 build #199 of lantiq/falcon is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/lantiq%2Ffalcon/builds/199 blamelist: Klaus Kudielka Dec 05 02:27:25 build #198 of sunxi/cortexa7 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/sunxi%2Fcortexa7/builds/198 blamelist: Klaus Kudielka Dec 05 02:46:06 mangix: current casing _works_ if I make any changes, it will be to just lowercase it all. **** ENDING LOGGING AT Sat Dec 05 02:59:57 2020