**** BEGIN LOGGING AT Fri Dec 11 02:59:56 2020 Dec 11 06:55:31 stintel: I did extensive lldp testing Dec 11 06:55:45 I have 3 fixes for the init script and the 1.0.7 has issues Dec 11 06:56:02 with 1.0.7 remote machines can see the AP but the AP cannot see remote devices Dec 11 06:56:20 stintel: I'll revert the update for now if that is ok s.T. its functional in the release Dec 11 10:04:01 build #666 of ramips/rt288x is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt288x/builds/666 Dec 11 11:09:15 Is there any neat functions built into the openwrt ecosystem to keep processes running, in case it exits (crash or other reasons)? Dec 11 11:09:54 procd monitored services can be respawned Dec 11 11:10:30 is that different from /etc/init.d/ rc.common with start(), stop() ? Dec 11 11:10:36 build #590 of mpc85xx/p2020 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fp2020/builds/590 Dec 11 11:12:02 I mean "procd_set_param respawn" in the init scripts... Dec 11 11:13:01 thanks, Ill read https://openwrt.org/docs/guide-developer/procd-init-scripts and try to get it working Dec 11 11:16:52 it's not as full featured as some monitoring services, but it might be sufficient Dec 11 11:24:54 I tried procd, seems like when stopping a service it kills the original process it started but not any process childs Dec 11 11:25:58 correct Dec 11 11:27:15 can the behaviour be changed? I'm using procd to start a /usr/bin/monitor which runs, "ip -4 monitor dev br-lan neigh | while IFS= read -r line;" Dec 11 11:28:40 you can maybe change the way your process runs is easiest. Dec 11 11:36:59 Yeh, I'm trying to think of a way. I need to pipe each line of "ip monitor" into another bash script Dec 11 11:38:05 you might want to rethink your application architecture :) Dec 11 11:38:52 You want me to subscribe to netlin kto get the data instead ;) That's above my expertise Dec 11 11:39:06 no, but something that is a little more integrated Dec 11 11:39:09 like a lua script for example Dec 11 11:39:48 fd = io.popen("ip -4 monitor dev br-lan neigh"); while true do line = fd:read("*line") if not line then break end print("Got line: ", line) end Dec 11 11:40:26 however I don't see a reason why procd would fail to terminate the ip process and read subshell Dec 11 11:40:41 it will kill the parent process which should terminate the entire process group Dec 11 11:40:56 unless you did extra things to actually detach your childs (fork/exec etc.) Dec 11 11:41:09 let me try again Dec 11 11:41:28 maybe you could paste your init script Dec 11 11:41:41 if you actually start the process yourself in the script start action then procd will not control it Dec 11 11:42:02 instead of starting the process you need to instruct procd to start it for you (procd_set_param command ...) Dec 11 11:43:41 https://0bin.net/paste/Bski6Cjg#LlO+NwdWMnsV-1vsljMTT7WNTumx5vWJzMXRRoS9tHU Dec 11 11:45:34 barhom: line 14 is not actually part of the init script but added as heading by you for the paste? Dec 11 11:45:49 yes Dec 11 11:46:02 just for you to know what file it is Dec 11 11:46:06 right Dec 11 11:46:30 it kills /usr/bin/monitor, ip keeps running though Dec 11 11:46:42 so after /etc/init.d/monitor restart, what is reported by ubus call service list '{ "name": "monitor", "verbose": true }' ? Dec 11 11:49:14 https://0bin.net/paste/U7sZU5nf#WJy5NbdZ3rqCdhHALIOkl8FtKwUzsnbhKhTWsmSqKfB Dec 11 11:49:32 It restarts fine, but now I have 2x ip processes Dec 11 11:49:41 hmm. So luci-app-mosquitto supports both mosquitto-ssl and mosquitto-nossl, but requires libopenssl. Isn't that a bug? Dec 11 11:52:57 it's only meant to depend on the virtual package mosquitto? Dec 11 11:53:22 LUCI_DEPENDS:=+luci-compat +luci-mod-admin-full mosquitto Dec 11 11:53:38 thats even in 1907? Dec 11 11:54:18 karlp: and yet when I try to install it (on 19.07), with mosquitto-nossl installed, it wants to pull libopenssl and libwebsockets-openssl Dec 11 11:54:31 which kinda defeats the purpose of having -nossl installed :P Dec 11 11:54:34 try to install it how? Dec 11 11:54:43 via luci Dec 11 11:55:07 what does opkg install on the cli say? Dec 11 11:55:38 I mean, the luci app doesn't _really_ even need mosquitto, it just doesn't do anything without it, and it's what most other apps do Dec 11 11:56:04 I'd suggest it's a luci/opkg problem, rather than a mosquitto problem at least :) I'm on holidays today :) Dec 11 11:56:56 karlp: it would appear you are correct :) Dec 11 11:57:03 opkg install only installed the app Dec 11 11:57:09 where should I report this problem then? Dec 11 11:57:39 * karlp shrugs Dec 11 11:57:55 I would have thought luci's ui was just a very thin wrapper over opkg behind the scenese? Dec 11 11:58:02 it is Dec 11 11:58:03 i would have thought exactly the same Dec 11 11:58:08 which is why I'm puzzled Dec 11 12:00:03 https://github.com/openwrt/luci/blob/master/applications/luci-app-opkg/htdocs/luci-static/resources/view/opkg.js#L894 Dec 11 12:00:06 https://github.com/openwrt/luci/blob/master/applications/luci-app-opkg/root/usr/libexec/opkg-call#L16 Dec 11 12:00:41 no extra logic wrt. dependency resolution Dec 11 12:00:50 so this would make it an opkg (openwrt base) problem then Dec 11 12:01:11 https://pasteboard.co/JEqlCvt.jpg Dec 11 12:01:36 is what it showed me. I unfortunately snipped the bottom line but it said it was about to install 4 packages for 1.2MB Dec 11 12:01:49 thats a display bug Dec 11 12:02:21 including the number of packages to be installed and the size? Dec 11 12:02:30 the info you see there is indeed calculated by luci since calling opkg for that is prohibitively expensive Dec 11 12:02:37 but it might not match waht opkg will actually do Dec 11 12:02:42 yes Dec 11 12:02:45 including that Dec 11 12:03:10 hmm. That's extremely confusing then Dec 11 12:03:17 might as well not display anything Dec 11 12:03:18 for this corner-case, yes Dec 11 12:03:50 in the majority of other cases not involving alternatives it is useful Dec 11 12:05:40 I don't know how many ssl/nossl alternatives we have on the code base but I'd expect a few? Dec 11 12:08:03 blogic: what about reporting it upstream? I believe they're quite responsive, so we could have a fix before release Dec 11 12:09:19 karlp: happy holidays btw :) Dec 11 12:09:39 stintel: if I may ask, would you mind sharing your real-life usecases for LLPD? Dec 11 12:09:43 (I'm just curious) Dec 11 12:11:26 f00b4r0: just a few days off for some mental health catchup :) was going to be doing some home renovations, but the shelving units I was going to be installing are out of stock :) Dec 11 12:12:04 karlp: heh, sounds good! Dec 11 12:13:43 Question: mwlwifi with 802.11r just need the domain key thing? because mine keeps breaking after a few hours Dec 11 12:16:15 PaulFertser: it's super handy to find out which port a device is connected to. and other info. see some real-life (but IP/domain censored) output: https://www.linux-ipv6.be/OpenWrt/lldp.txt Dec 11 12:17:07 I'm very used to be able to get this info since my first hands-on experience with Cisco gear back in 2005 or so Dec 11 12:17:32 i concur Dec 11 12:17:32 lldp is a public implementation of cdp? or same purpose, different protocol? Dec 11 12:17:55 * f00b4r0 discovers lldp package in openwrt Dec 11 12:17:56 junos has their own too didn't they? Dec 11 12:18:13 karlp: there are some similar things, I believe LLDP was introduced to have a standard thing Dec 11 12:18:22 lldpd also supports cdp, for example Dec 11 12:19:07 i don't remember an enterprise-grade switch I came across that didn't support LLDP Dec 11 12:19:16 stintel: thank you! Dec 11 12:19:16 they all do nowadays Dec 11 12:19:24 PaulFertser: welcome :) Dec 11 12:19:58 also, observium nicely gathers the neighbor info from lldpd via snmp, if you configure lldpd as sub agent Dec 11 12:27:28 here you can see the other protocols that are supported by lldpd: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/network/services/lldpd/Config.in;h=ec6990a76c42ccd1ddf713d8fa62322f9a00b054;hb=HEAD Dec 11 12:29:40 well I'll sleep less of an idiot tonight: I didn't even know about lldpd Dec 11 12:30:54 f00b4r0: the package was missing from the repos for a long time due to some obscure bug that I or several others couldn't reproduce Dec 11 12:31:48 stintel: i see. I'm prep'ing my .5 upgrade on all my APs, it's going on the image ;) Dec 11 12:36:15 jow, are you thinking its a bug that "ip" does not die in my procd example? Dec 11 13:29:23 stintel: sure, can you Cc: me when you talk to them ? Dec 11 13:44:59 blogic: you said 1.0.6 worked fine right? Dec 11 13:47:29 correct Dec 11 13:47:54 alright, I'll try bisecting it via SRC_TREE_OVERRIDE Dec 11 14:01:32 blogic: I can't really reproduce it. I have a device where I'm not seeing neighbors, but it's the same with 1.0.6, and tcpdump doesn't even show any incoming lldp packets Dec 11 14:02:28 1.0.6 works for me Dec 11 14:02:37 what netdev are you running lldpd on ? Dec 11 14:03:15 configure system interface pattern lo,br-lan,eth0.30 Dec 11 14:03:25 br-lan is wrong for 1 Dec 11 14:03:37 that will only work for egress but not ingress Dec 11 14:03:52 replace br-lan with whatever the members are Dec 11 14:04:03 also reload_config wont work Dec 11 14:04:07 actually br-lan is not even connected to the switch Dec 11 14:04:11 you need to init.d restart the daemon Dec 11 14:04:16 oh ok Dec 11 14:04:44 lldpctl will then show no neighbors, right ? Dec 11 14:04:46 it's eth0.30 that is, I also added eth0 now Dec 11 14:04:59 and no neighbors Dec 11 14:05:18 is there a swtch on the board ? Dec 11 14:05:23 yes Dec 11 14:05:30 it might be dropping lldp frames Dec 11 14:05:37 which they are supposed to do Dec 11 14:06:09 but it doesn't drop the outgoing ones Dec 11 14:06:10 because lldp shall be ran on the switch ports not the cpu port Dec 11 14:06:16 that is also expected Dec 11 14:06:32 but lldp can't run on swconfig switchports now can it Dec 11 14:06:38 basically most switches will have trap registers Dec 11 14:06:47 it cannot Dec 11 14:06:57 unless the switch is setup correctly Dec 11 14:07:03 but even then it would be on the cpu port Dec 11 14:07:12 well with dsa it should be possible no ? Dec 11 14:07:16 yes Dec 11 14:07:21 that is how I am testing it Dec 11 14:07:23 1 more reason for dsa Dec 11 14:07:33 maybe explains why I cannot reproduce it Dec 11 14:07:42 with 1.0.6 i run on realtek and have the lldpd run on lan[1-8] Dec 11 14:07:52 but with 1.0.7 it breaks Dec 11 14:07:55 I have a DIR-860L Dec 11 14:08:01 should support DSA iirc Dec 11 14:08:16 so lets revert now, it'll be working for now and then we can bisect later Dec 11 14:08:34 I can spend cycles on this in january Dec 11 14:08:46 I plan to put some time into the daemon anyhow and add ubus Dec 11 14:08:54 I prefer then to find the breaking commit and revert that only otherwise I get spam that I need to update the package Dec 11 14:09:10 haha Dec 11 14:09:13 I'll spend some more time on it today Dec 11 14:09:15 who spams you ?! Dec 11 14:09:21 swalker Dec 11 14:09:21 ok Dec 11 14:09:50 where's that DIR-860L when you need it Dec 11 14:10:08 under the mountain of stuff Dec 11 14:11:15 there aren't that many commits between 1.0.6 and 1.0.7 Dec 11 14:11:22 should be easy to find Dec 11 14:11:36 let me clone the tree Dec 11 14:11:48 probably https://github.com/lldpd/lldpd/commit/8b50be7f61ad20ebae15372a509f7e778da2cc6f Dec 11 14:12:01 or https://github.com/lldpd/lldpd/commit/5d9226d140676b7246b26794b05916226e0b4caa Dec 11 14:14:17 wow that dir860l is running r8054 Dec 11 14:15:11 what are we on now Dec 11 14:15:17 like ~15k or summin Dec 11 14:16:56 yeah 15k+ Dec 11 14:22:21 so the ar8236 in my oc200 does not seem to drop those packets Dec 11 14:29:41 since removal of libcxx I'm getting a truckload of WARNING: Makefile 'package/feeds/packages/qemu/Makefile' has a dependency on 'libcxx', which does not exist Dec 11 14:29:59 for plenty packages... any clue how to silence those? Dec 11 14:30:33 if it was just moved somewhere else, you'll need to force re-install it, I think Dec 11 14:30:41 it's not really moved Dec 11 14:31:03 it is, but to packages-abandoned Dec 11 14:31:19 but then we shouldn't have dependencies left, should we? Dec 11 14:31:37 well maybe it's some caching thing Dec 11 14:31:47 * stintel removes tmp/ Dec 11 14:32:38 yeah that seems to fix it Dec 11 14:33:03 maybe we should rm -rf tmp/ automatically on every build just to reduce annoyances Dec 11 14:36:12 stintel: we don't all have 24 core, ramdisk backed build machines :P Dec 11 14:36:35 neither have I :P Dec 11 14:36:41 but tmp isn't that heavy, or is it ? Dec 11 14:38:56 hmm... tmp/ 3 items, 140kB Dec 11 14:39:52 I must be looking at the wrong tmp, cause I would be surprised if removing that solved package issues Dec 11 14:42:48 svanheule[m]: the buildroot tmp/ caches package metadata Dec 11 14:42:55 svanheule[m]: and dependencies Dec 11 14:43:09 see e.g. tmp/.packagedeps Dec 11 14:43:28 if that goes out of sync with the feed material you get the funning not existing depdency errors above Dec 11 14:43:35 *funny Dec 11 14:43:56 jow: thanks, hidden files indeed :-) Dec 11 14:43:58 (and for some reason we love to use hidden files in that tmp dir) Dec 11 14:44:31 first put them somewhere where nobody will look, then hide them to be extra sure :P Dec 11 14:44:45 :D Dec 11 14:44:55 we never see that on the buildbots because they start with a clean state right ? Dec 11 14:44:57 the hidden files amount to 50MB+ Dec 11 14:45:05 stintel: semi-clean Dec 11 14:45:28 stintel: http://builds.openwrt.org/master/images/builders/arc770%2Fgeneric/builds/729/steps/rmtmp Dec 11 14:45:48 heh :) Dec 11 14:46:34 so any reason we're not doing it by default, in buildroot ? Dec 11 14:46:42 I think the problem with removal of packages in base is a bit special Dec 11 14:46:54 usually some updated Makefile etc. should trigger a resync of the stuff in tmp/ Dec 11 14:46:58 it keeps po(o)pping up every now and then that this is the solution for problems reported here Dec 11 14:47:12 but with pacakges being removed entirely, there's no file left that could have an updated mtime Dec 11 14:47:29 it might make sense to factor in the mtime of the package/ directory itself for this Dec 11 14:48:06 nbd: do you think that this is feasible? Re-trigger prepare-tempinfo if the mtime of the package/ dir itself changes? Dec 11 14:48:17 to cover cases where packages are deleted Dec 11 14:48:32 the question is whether package removal is really expected to happen frequently enough to implement a mechanism for that ... Dec 11 14:49:16 adrianschmutzler: it affects feeds as well, but since there's more activity there, you usually have unrelated modifications elsewhere when pulling commits that remove packages Dec 11 14:49:38 so you almost never encounter it, but technically its a problem there as well Dec 11 14:49:44 I see Dec 11 14:50:10 and users shouldn't be required to know about implementation details (cached dependencies in hidden files within tmp/) to keep stuff updated and buildable Dec 11 14:51:16 I'd make it a little bit dependant on the complexity of the solution ... Dec 11 14:51:37 yeah Dec 11 14:52:12 but of course, I'm not at all against improving that mechanism Dec 11 14:52:19 mosquitto_ctrl.h:21:10: fatal error: cJSON.h: No such file or directory Dec 11 14:52:21 #include Dec 11 14:53:01 karlp: you were looking into this iirc. any solution? Dec 11 14:54:49 Installing package 'cjson' from packages Dec 11 14:54:51 might help Dec 11 15:04:20 jow: have you considered tying ajax refreshes to Document.visibilityState (perhaps for heavier pages) to reduce cpu load in the browser? Dec 11 15:06:26 https://developer.mozilla.org/en-US/docs/Web/API/Document/visibilityState Dec 11 15:09:16 the libcxx(removed packages) warning can not be fixed by feeds reinstall etc, what I did is to distclean and rebuild to get rid of them, was not aware of the tmp/ removal trick, it's nice if the build system can deal with that Dec 11 15:15:00 alright, DSA image flashing on the DIR-860L Dec 11 15:15:10 let's see if I'll be able to access it afterwards Dec 11 15:19:15 looks like it, cool Dec 11 15:32:40 blogic: both 1.0.6 and 1.0.7 work fine on my DIR-860L after upgrading it to DSA Dec 11 15:33:15 have this in /tmp/lldpd.conf: configure system interface pattern lo,lan1,lan2,lan3,lan4,wan Dec 11 15:34:03 it's connected to my switch with the wan port Dec 11 15:38:16 blogic: now connected it via lan1 and 1.0.7 is still working Dec 11 15:39:43 stintel: fixed? Dec 11 15:39:53 yes, installing the new dep is important... Dec 11 15:39:58 karlp: yeah :) Dec 11 15:52:21 blogic: the only way I can reproduce it is by setting interface lan in /etc/config/lldpd which translates to br-lan in /tmp/lldpd.conf Dec 11 15:52:29 but this should be fixable in the init script Dec 11 17:05:42 blogic: what about https://gist.github.com/22388f823adae0f06102507d6024693c ? Dec 11 17:39:53 stintel: fine Dec 11 17:47:31 stintel: in that case we would however need to add a network restart trigger aswell to the init.d script Dec 11 17:47:49 does 1.0.7 work for you with that patch ? Dec 11 17:48:02 for me 1.0.7 will still fail with a similar patch that i sent to the ML Dec 11 18:07:46 I'm not sure how we decided on adding minor kernel bumps yesterday Dec 11 18:08:05 Is this still good to go or already "frozen"? Dec 11 18:24:53 minor kernel bumps should be allowed even if frozen, no ? Dec 11 18:26:06 blogic: ah, totally didn't see that post to the ML yet Dec 11 18:27:49 blogic: but with https://gist.github.com/22388f823adae0f06102507d6024693c 1.0.7 works on my DIR-860L Dec 11 18:28:01 grep interface /tmp/lldpd.conf Dec 11 18:28:01 configure system interface pattern lo,lan1,lan2,lan3,lan4,wlan0,wlan1 Dec 11 18:28:06 what does that show for you ? Dec 11 18:33:28 Hello guys!! Dec 11 18:33:53 I am running openwrt on a 7530 ... all is well. But I should use a switch port (lan4) as wan. How do I do so? Dec 11 18:37:39 mrkiko: just split it in a different vlan and use that vlan for wan interface Dec 11 18:40:27 PaulFertser: I tried to do so but I am failing, my config is Dec 11 18:41:54 PaulFertser: http://ix.io/2HAt Dec 11 18:42:28 PaulFertser: but as you see, no eth0.1 or something I can use to talk to the device connected to wan Dec 11 18:43:34 would liketo use that to do pppoe on the ISP modem :D Dec 11 18:43:36 mrkiko: this config is completely misguided, sorry. Dec 11 18:43:44 mrkiko: what port number is the CPU port? Dec 11 18:44:19 mrkiko: you need to have two vlans, and your lan would be e.g. eth0.1 and wan would be eth0.2, and you need to have your CPU port tagged in _both_. Dec 11 18:45:32 so - this is the stock config http://ix.io/2HAy Dec 11 18:45:47 I don't know how to determine CPU port Dec 11 18:53:31 stintel: will test in the morning, just out the gym room and of to bed Dec 11 19:03:01 mrkiko: from /etc/board.json Dec 11 19:21:18 PaulFertser: http://ix.io/2HAI Dec 11 19:21:23 PaulFertser: no wan infact Dec 11 19:22:04 mrkiko: so port 0 is CPU, good. Dec 11 19:22:14 mrkiko: you need to include 0t in both vlan1 and vlan2 Dec 11 19:22:23 mrkiko: and use eth0.1 for lan and eth0.2 for wan. Dec 11 19:24:43 PaulFertser: something like this - http://ix.io/2HAK Dec 11 19:25:05 but now I miss the lan_dev and wan_dev definitions, right? Dec 11 19:25:28 if the router stops responding it'll be a real issue :D so I am trying to be cautious Dec 11 19:25:37 mrkiko: you have ifname eth0 in lan but I told you it should be eth0.1 Dec 11 19:25:48 PaulFertser: so actually you're helping a lot Dec 11 19:26:05 mrkiko: and also you need section to define wan with proto dhcp and ifname eth0.2 Dec 11 19:27:47 PaulFertser: should be ok - http://ix.io/2HAL Dec 11 19:31:08 mrkiko: this looks reasonable. If the router stops responding will you be able to do "generic reset" to it? Dec 11 19:31:43 yeah, it stopped responding actually. :) It will reboot itself in 3m or something like that Dec 11 19:33:11 mrkiko: the config looks good to me... Dec 11 19:33:41 don't know, maybe there was a reason not to enable them ? Dec 11 19:33:43 blocktrron: ?? Dec 11 19:34:19 I did something like (sleep 3m;mv network.standard network;reboot) & so in theory it should come up at some point Dec 11 19:34:30 mrkiko: is it remote? Dec 11 19:35:05 oh well, it's here in the house so in the worst case I'll have to go get it and take it here. But no serial port Dec 11 19:35:14 ok, it's coming up Dec 11 19:35:25 * mrkiko feels better now Dec 11 19:35:52 noahm: ping Dec 11 19:36:13 dangole: addressed your issues Dec 11 19:36:57 dangole: if you still have access to that system could you please add some rule to firewall.user then restart the firewall service and look for avc denials in dmsg? Dec 11 19:37:25 i think there might still be a know loose end there as well Dec 11 19:38:10 philipp64: pong Dec 11 19:38:36 can't easily produce the issue on my router since i build my policy with the load_policy tunable set to off , so i can't setenforce currently Dec 11 19:38:53 Had a chance to look at https://github.com/openwrt/packages/pull/14184? it’s fairly trivial... Dec 11 19:40:35 I haven't looked in detail yet. It's funny; I have rndc set up in my own bind configuration, and it didn't actually occur to me that it isn't enabled by default until you raised the issue. Dec 11 19:41:14 PaulFertser: I pinged blocktrron because he's the author of the port, just that reason Dec 11 19:44:33 mrkiko: I guessed just that Dec 11 19:51:11 grift: nice, will check now. there is one more thing which is needed to make things work in initramfs as well, i'll send it to you via email Dec 11 19:57:00 dangole: added patch Dec 11 20:00:58 dangole: by the way i think the package manifest needs a small fix as well Dec 11 20:02:55 Makefile adjustment: https://git.defensec.nl/?p=selinux-policy.git;a=commitdiff;h=7ea7abba5aff6983fd41ab7d3271d8dce1f40d51#patch9 Dec 11 20:05:07 grift: to install customizable_types, i see. maybe we can include that and bump the source as well. maybe you make a new tag for that? Dec 11 20:07:11 if you verify the rule adding to /etc/firewall.user && service firewall restart, then i guess after that i can bump the tag, theres some more work in my TODO but that can wait Dec 11 20:08:39 grift: i'll test that now Dec 11 20:09:16 probalbly some pipe rules missing Dec 11 20:22:18 noahm: hoping to have isc-dhcp pushing private Intranet DNS into bind soon… Dec 11 20:22:29 make it more “small business friendly”. Dec 11 20:22:49 oh, my honda is done being serviced… going offline to drive home. Dec 11 20:23:42 ack. I'll try to get to it today. Dec 11 20:28:25 mrkiko: it should work on 19.07.5, master still has the port seperation in place Dec 11 20:28:52 there's a revert in my staging tree, i didn't yet came around to test it Dec 12 00:21:21 If anyone wants to take pity on me.. I'm open to suggestions :) https://forum.openwrt.org/t/host-xxxx-in-package-doesnt-run-during-build/81866 Dec 12 00:37:48 Grommish: suricata doesn't have a host-build defined, hence HOST_BUILD_DEPENDS doesn't have any effect there. what you probably meant to do is adding PKG_BUILD_DEPENDS:=rust/host python3/host luajit/host Dec 12 00:53:58 grift: config restore after sysupgrade still fails (mv complains about "permission denied" moving file from /boot to /sysupgrade.tgz). and yes, we are using /boot on block-storage based systems to stash config to be restored after sysupgrade. Dec 12 00:56:56 grift: as firewall.user can be pretty much anything it's hard to contain. usually people do custom calls to ip{,6}tables and some put ebtables calls there (though not covered or flushed by fw3, hence not needed to be there), but in the wild, well, probably also tc, ip, ... Dec 12 01:21:06 mangix: ping Dec 12 01:26:05 dangole: I really REALLY hope your right.. :D Thanks! I'll check that Dec 12 02:22:54 aparcar[m]: pojg Dec 12 02:22:56 *pong Dec 12 02:30:49 patchwork seems down Dec 12 02:30:51 oh well Dec 12 02:38:34 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_ar71xx.html has been updated. (99.2% images and 97.1% packages reproducible in our current test framework.) **** ENDING LOGGING AT Sat Dec 12 02:59:56 2020