**** BEGIN LOGGING AT Thu Nov 29 02:59:59 2018 Nov 29 07:54:47 hmmm Nov 29 07:54:58 my kernel foobar'ed last night Nov 29 07:55:06 uptime 158 days Nov 29 07:55:19 first i noticed, that audio was not working as pulseaudio died Nov 29 07:55:31 then wifi started to drop out Nov 29 07:55:41 and now [3050144.157708] e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang: Nov 29 07:55:48 guess its time to coldboot :-) Nov 29 08:03:13 blogic: Only 158 days? Poor show :( Nov 29 08:22:54 blogic: So clearly we're looking in the right place, would you mind asking if he can disclose everything related to padconf? Nov 29 09:36:16 sure Nov 29 09:36:26 padconf seems to the the analogue part to pinmux Nov 29 09:36:36 'lo Nov 29 09:36:58 jow: hey there Nov 29 10:02:44 dedeckeh: I'd be fine with building pppd from latest git Nov 29 10:02:54 dedeckeh: maybe we can lower our patch stack a bit then Nov 29 10:03:25 jow: just tried calling you Nov 29 10:03:31 did you not hear it or bad timing Nov 29 10:04:20 I indeed didn't hear it can you retry? Nov 29 10:44:43 nbd: ping Nov 29 10:45:17 nbd: is 5ffacceb7beb208dfaa8d53a71a1d503dc884b1c ("mac80211: fix reordering of buffered broadcast packets") a candidate for 18.06 or related to the mac80211 bump in master? Nov 29 10:51:04 it's a candidate for 18.06 as well Nov 29 10:52:53 My, you have been busy. Any of the mt76 changes relevant to my pet bug? Nov 29 11:09:19 no Nov 29 11:09:22 i will ask mediatek about it Nov 29 11:10:13 nbd: https://github.com/openwrt/openwrt/pull/658 - a clear NAK I guess? Nov 29 11:11:35 on MT7621, when one does -j FLOWOFFLOAD how are packet egress queued? Are the offloaded packets of lower, same or higher priority than the CPU routed packets? Nov 29 11:12:41 blogic: https://github.com/openwrt/openwrt/pull/955/files - ok after I fix the bad "!= mtd*" conditional? Nov 29 11:13:06 jow: right Nov 29 11:24:08 Hauke: I am looking at the openssl pr now Nov 29 11:24:25 Hauke: iirc we wanted to discuss the pacakge abi implications Nov 29 11:25:46 build #334 of x86/geode is complete: Failure [failed checkarch] Build details are at http://release-builds.lede-project.org/17.01/images/builders/x86%2Fgeode/builds/334 blamelist: Tony Ambardar , Karl Vogel , Jo-Philipp Wich Nov 29 11:26:51 build #364 of gemini/raidsonic is complete: Failure [failed checkarch] Build details are at http://release-builds.lede-project.org/17.01/images/builders/gemini%2Fraidsonic/builds/364 blamelist: Tony Ambardar , Karl Vogel , Jo-Philipp Wich Nov 29 11:27:56 build #361 of ramips/rt288x is complete: Failure [failed checkarch] Build details are at http://release-builds.lede-project.org/17.01/images/builders/ramips%2Frt288x/builds/361 blamelist: Tony Ambardar , Karl Vogel , Jo-Philipp Wich Nov 29 11:29:51 make[2]: *** No rule to make target '-m4755', needed by 'INSTALL_SUID'. Stop. Nov 29 11:31:33 yep, my bad Nov 29 11:31:38 fixing it in a second Nov 29 11:32:13 build #178 of brcm63xx/generic is complete: Failure [failed checkarch] Build details are at http://release-builds.openwrt.org/18.06/images/builders/brcm63xx%2Fgeneric/builds/178 blamelist: Tony Ambardar , Karl Vogel , Jo-Philipp Wich Nov 29 11:32:13 build #178 of octeontx/generic is complete: Failure [failed checkarch] Build details are at http://release-builds.openwrt.org/18.06/images/builders/octeontx%2Fgeneric/builds/178 blamelist: Tony Ambardar , Karl Vogel , Jo-Philipp Wich Nov 29 11:32:25 missing = looks like Nov 29 11:32:45 build #174 of sunxi/cortexa53 is complete: Failure [failed checkarch] Build details are at http://release-builds.openwrt.org/18.06/images/builders/sunxi%2Fcortexa53/builds/174 blamelist: Tony Ambardar , Karl Vogel , Jo-Philipp Wich Nov 29 11:32:46 build #123 of oxnas/ox820 is complete: Failure [failed checkarch] Build details are at http://release-builds.openwrt.org/18.06/images/builders/oxnas%2Fox820/builds/123 blamelist: Tony Ambardar , Karl Vogel , Jo-Philipp Wich Nov 29 11:33:14 build #168 of lantiq/ase is complete: Failure [failed checkarch] Build details are at http://release-builds.openwrt.org/18.06/images/builders/lantiq%2Fase/builds/168 blamelist: Tony Ambardar , Karl Vogel , Jo-Philipp Wich Nov 29 11:33:15 build #172 of x86/64 is complete: Failure [failed checkarch] Build details are at http://release-builds.openwrt.org/18.06/images/builders/x86%2F64/builds/172 blamelist: Tony Ambardar , Karl Vogel , Jo-Philipp Wich Nov 29 11:33:42 build #170 of ar7/ac49x is complete: Failure [failed checkarch] Build details are at http://release-builds.openwrt.org/18.06/images/builders/ar7%2Fac49x/builds/170 blamelist: Tony Ambardar , Karl Vogel , Jo-Philipp Wich Nov 29 11:33:43 build #169 of brcm47xx/mips74k is complete: Failure [failed checkarch] Build details are at http://release-builds.openwrt.org/18.06/images/builders/brcm47xx%2Fmips74k/builds/169 blamelist: Tony Ambardar , Karl Vogel , Jo-Philipp Wich Nov 29 11:34:10 build #177 of arc770/generic is complete: Failure [failed checkarch] Build details are at http://release-builds.openwrt.org/18.06/images/builders/arc770%2Fgeneric/builds/177 blamelist: Tony Ambardar , Karl Vogel , Jo-Philipp Wich Nov 29 11:34:10 build #174 of ath25/generic is complete: Failure [failed checkarch] Build details are at http://release-builds.openwrt.org/18.06/images/builders/ath25%2Fgeneric/builds/174 blamelist: Tony Ambardar , Karl Vogel , Jo-Philipp Wich Nov 29 11:38:52 build #163 of apm821xx/sata is complete: Failure [failed checkarch] Build details are at http://release-builds.openwrt.org/18.06/images/builders/apm821xx%2Fsata/builds/163 blamelist: Tony Ambardar , Karl Vogel , Jo-Philipp Wich Nov 29 11:38:52 build #154 of ar71xx/generic is complete: Failure [failed checkarch] Build details are at http://release-builds.openwrt.org/18.06/images/builders/ar71xx%2Fgeneric/builds/154 blamelist: Tony Ambardar , Karl Vogel , Jo-Philipp Wich Nov 29 11:39:30 build #179 of at91/legacy is complete: Failure [failed checkarch] Build details are at http://release-builds.openwrt.org/18.06/images/builders/at91%2Flegacy/builds/179 blamelist: Tony Ambardar , Karl Vogel , Jo-Philipp Wich Nov 29 11:39:31 build #177 of malta/be is complete: Failure [failed checkarch] Build details are at http://release-builds.openwrt.org/18.06/images/builders/malta%2Fbe/builds/177 blamelist: Tony Ambardar , Karl Vogel , Jo-Philipp Wich Nov 29 11:50:24 dedeckeh: ping Nov 29 11:54:38 jow: ack Nov 29 11:54:54 rmilecki: http://lists.openwrt.org/pipermail/openwrt-devel/2016-September/002562.html that resulted in this https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eea2fb4851e9dcbab6b991aaf47e2e024f1f55a0 Nov 29 11:54:58 right ? Nov 29 11:57:13 blogic: oh my, I don't remember... Nov 29 11:58:03 rmilecki: :-) Nov 29 11:58:09 still checking Nov 29 11:58:18 i have a feeling it did Nov 29 11:59:37 blogic: http://lists.openwrt.org/pipermail/openwrt-devel/2016-September/002564.html Nov 29 11:59:53 from Miklos: "Fixed in 4.8-rc5 by Nov 29 11:59:55 eea2fb4851e9 ("ovl: proper cleanup of workdir")" Nov 29 11:59:58 so I think you're correct Nov 29 12:00:00 oki Nov 29 12:00:03 hero Nov 29 12:03:21 urgh... latest pppd requires openssl Nov 29 12:03:29 and is not cross compile safe Nov 29 12:03:38 did they not enough bugs of their own ? Nov 29 12:03:42 https://github.com/paulusmack/ppp/commit/3c7b86229f7bd2600d74db14b1fe5b3896be3875 Nov 29 12:04:03 how do we handle adding tags like Acked-by with GitHub? https://github.com/openwrt/openwrt/pull/1582 Nov 29 12:04:21 rmilecki: unsurprisingly it is not possible Nov 29 12:04:27 jow: Clearly openssl should be used everywhere. Nov 29 12:04:35 Why resist? :) Nov 29 12:04:37 just edit the code with the browser like all serious contributors Nov 29 12:06:50 jow:pong Nov 29 12:07:58 dedeckeh: there's been an interesting bug report in the forum. Someone claimed that sometime since d157a76c67bcb821d3ec8dcd4312390ef129a95a the wireguard interfaces get shut down by "wifi down" Nov 29 12:08:09 jow: can mkresin edit commit message in another user's pull request? Nov 29 12:08:53 dedeckeh: while skimming over the commit log since then I've noticed two netifd bumps, one which was reworkign the dynamic interface handling Nov 29 12:08:59 dedeckeh: I wonder if it could be related Nov 29 12:09:11 rmilecki: no, I don't think so Nov 29 12:09:16 great Nov 29 12:09:33 i've noticed some peculiarities where sometimes wifi doesn't come up on first boot, but does on second boot Nov 29 12:12:06 rmilecki: I can't really think of a solution apart from cloning/forking the pr branch, amending it in your own clone, push it somewhere public and make your clone somehow supersede the other open pr Nov 29 12:12:19 hooray Nov 29 12:12:23 sounds great, thanks jow Nov 29 12:12:33 which would most likely imply opening another pr, closing the existing one with a link to the new one etc. Nov 29 12:12:55 rmilecki: I will take care of the PR and push it on my own. should be enough acknowledgement Nov 29 12:13:40 the other way would be coming up with a kind of convention, people write their "ACK" into the PR discussion comments and the final committer adds the "Acked-by: " manually Nov 29 12:13:58 I've done this occasionally since I need to edit most PR commits anyway in one way or another Nov 29 12:14:07 s/edit/amend/ Nov 29 12:14:10 mkresin: ah, sorry, I already pushed ath79 ones Nov 29 12:14:46 mkresin: i'll really appreciate if you take care of the ramips commit Nov 29 12:14:54 jow:these changes should only affect dynamic interfaces created via ubus call network add_dynamic Nov 29 12:15:02 if it is desired I can extend our "pr.sh" to automatically gather "Acked-by", "Tested-by" and similar tags from the pr comments Nov 29 12:15:33 jow: not sure if that's worth it, probably it was just a single case Nov 29 12:15:39 dedeckeh: hmm, right. I somehow assumed wg does this but I now noticed that it is a proper proto handler with real netdevs Nov 29 12:15:48 jow:which is not the case for wireguard interfaces Nov 29 12:15:51 mkresin: if that's OK, I'll still suggest you to add your Acked-by when commiting Nov 29 12:15:59 rmilecki: in this case its easiest to ask the committer to please add an "Acked-by" on your behalf Nov 29 12:16:22 I just asked mkresin :) cool Nov 29 12:16:39 oh ,you mean commited, not a pusher Nov 29 12:16:41 blah Nov 29 12:16:53 rmilecki: well committer~pusher Nov 29 12:16:55 i'll leave it to mkresin at this point ;) Nov 29 12:16:59 whoever puts it into openwrt.git Nov 29 12:17:20 jow:what's your opinion about switching ppp package to latest github commit ? Nov 29 12:17:33 dedeckeh: maybe the bug reports wifi is the default route which would explain wg going down (due to the host dependency) Nov 29 12:18:02 jow:ah that could be as it installs a host dependency Nov 29 12:18:02 dedeckeh: I am fine with switching pppd to git but the very latest commit there seems troublesome (switch to openssl, hardcoded /usr/include/openssl) Nov 29 12:18:20 dedeckeh: which would already require one further patch (instead of reducing some) Nov 29 12:18:59 hmmm right Nov 29 12:19:33 although further backporting patches also increases the number of patches Nov 29 12:19:53 yeah, moving to Git head is worth it Nov 29 12:19:57 I am fine with that Nov 29 12:20:22 it seems there is vary little change apart from that Nov 29 12:20:29 *very Nov 29 12:21:41 hmm. this seems wrong. Nov 29 12:21:46 apparently the openssl thing is optional yet, so it seems fine Nov 29 12:21:52 ath79 seems to be forced on a defconfig Nov 29 12:22:36 russell--: could be that the previous rules.mk bug trashed your .config Nov 29 12:22:55 jow:you're referring to https://github.com/paulusmack/ppp/commit/3c7b86229f7bd2600d74db14b1fe5b3896be3875 as the troublesome commit ? Nov 29 12:22:56 it caused the kconfig code to lack the target selection, writing .config without any target selection symbols Nov 29 12:23:10 CONFIG_TARGET_ramips=y Nov 29 12:23:11 CONFIG_TARGET_ramips_mt76x8=y Nov 29 12:23:11 CONFIG_TARGET_ramips_mt76x8_DEVICE_LinkIt7688=y Nov 29 12:23:14 russell--: running defconfig after git pull would simply set the default ath79 then Nov 29 12:23:16 and a make defconfig Nov 29 12:23:30 ah, thats odd then Nov 29 12:23:34 indeed Nov 29 12:23:37 dedeckeh: correct, yes Nov 29 12:24:05 doing another git pull Nov 29 12:26:16 that and blowing away $TOPDIR/tmp maybe helped, all better now Nov 29 12:27:56 build #1126 of omap/generic is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/omap%2Fgeneric/builds/1126 Nov 29 12:29:48 build #1137 of brcm2708/bcm2710 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/brcm2708%2Fbcm2710/builds/1137 Nov 29 12:33:29 blogic: https://git.openwrt.org/?p=openwrt/staging/jow.git;a=commit;h=87a477606d6b1d20f7be70bdfa73cd3065c61622 Nov 29 12:33:48 blogic: every single line in this commit was wrong, as well as the commit message and the author of the commit Nov 29 12:34:10 however the variant in the staging tree should work now Nov 29 12:35:10 when looking at it now I wonder why we can't simply fold it in the existing 10-mount Nov 29 13:04:08 nbd: kernel panic on mt7688 linkit in station mode: https://pastebin.com/BqnXF5vi Nov 29 13:09:46 mkresin: was there a discussion anywhere about the desirability of renaming ubi images from .tar to .bin? Nov 29 13:17:23 jow: i now recall that i back then thought it should worl without Nov 29 13:17:27 jow: just nuke it Nov 29 13:17:34 jow: i'll test it on a real HW later Nov 29 13:21:11 russell--: is that while unloading the module while it's running? Nov 29 13:27:03 russell--: yes a long time ago. main reason, user tried to extract the tar and fiddled with the inlcuded binaries Nov 29 13:37:03 build #1110 of ar71xx/mikrotik is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/ar71xx%2Fmikrotik/builds/1110 Nov 29 16:39:32 hrm, /me needs to try that block mount auto detect stuff, Nov 29 16:39:43 last I tried using the kernel polling it was a complete failure Nov 29 18:18:40 what does ubox actually do? I know libubox is a useful API for general Linux file, events & process handling. But what does the ubox command do? The wiki doesn't really explain it Nov 29 18:20:21 Interesting it appears to handle syslog. I've been meaning to research this area recently Nov 29 18:23:15 build #1072 of octeon/generic is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/octeon%2Fgeneric/builds/1072 Nov 29 18:32:43 Neighbor11111117: presumably muc like "busybox" teh binary isn't very interesting, but it does different things based on how it's invoked... Nov 29 18:33:10 cool makes sense karlp Nov 29 18:35:32 (i'venot looked, but it's how busybox/toybox works....) Nov 29 19:37:13 so uh Nov 29 19:37:16 I can't figure this out Nov 29 19:37:37 can anyone see why procd isn't killing bird Nov 29 19:37:46 or, how can I enable some sort of debug on procd? Nov 29 20:22:42 ah wait, is it because it's forked I wonder Nov 29 20:23:09 build #449 of ar71xx/tiny is complete: Failure [failed targetupload] Build details are at http://phase1.builds.lede-project.org/builders/ar71xx%2Ftiny/builds/449 blamelist: Tony Ambardar , Mathias Kresin , INAGAKI Hiroshi , Petr ?tetiar , Felix Fietkau , Karl Vogel Nov 29 20:23:09 , Jo-Philipp Wich Nov 29 20:27:35 3498 root 2044 S /usr/sbin/bird -c /etc/bird.conf -P /var/run/bird.pid Nov 29 20:27:39 cat /var/run/bird.pid Nov 29 20:27:39 3498 Nov 29 20:27:41 guess so Nov 29 20:27:55 pid looks fine but doesn't send term Nov 29 20:54:45 nbd: it happened while i was running a script the indeed rmmod'd Nov 29 20:55:22 s/the /that / Nov 29 21:04:51 jow: yes I would like to get openssl 1.1.1 in soon, but the ABI changed compared to 1.0.1 we currently use Nov 29 21:05:14 this change will be a one time change, then it should stay compatible for the next few years Nov 29 21:19:08 build #179 of octeontx/generic is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/octeontx%2Fgeneric/builds/179 Nov 29 21:21:19 build #179 of brcm63xx/generic is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/brcm63xx%2Fgeneric/builds/179 Nov 29 21:49:20 rmilecki: would you mind to do a quick review of the parser bindings in https://github.com/openwrt/openwrt/pull/1587 Nov 29 21:49:48 build #124 of oxnas/ox820 is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/oxnas%2Fox820/builds/124 Nov 29 21:49:55 build #175 of sunxi/cortexa53 is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/sunxi%2Fcortexa53/builds/175 Nov 29 22:10:31 mkresin: thanks for pinging me Nov 29 22:10:33 looks good! Nov 29 22:12:23 rmilecki: only six ramips boards left without firmware compatible Nov 29 22:12:34 nice! Nov 29 22:17:48 jwh: you cajn run some of the commands under "Cubus service" iirc to dump the info that procd has wrt your service. Nov 29 22:18:09 if it doesn' tmatch, ie, shows a pid one lower, that sort of thing, it's failed to handle forking and that sort ofthing. Nov 29 22:18:20 hm Nov 29 22:20:48 what magic args do I need for it? Nov 29 22:21:09 not at my desk now sorry, ubus call service list with a few -vs or somethign?+ Nov 29 22:21:22 there's one tha tdumps a whole pile of json about every service. Nov 29 22:21:35 build #939 of armvirt/64 is complete: Failure [failed targetupload] Build details are at http://phase1.builds.lede-project.org/builders/armvirt%2F64/builds/939 blamelist: Tony Ambardar , Mathias Kresin , Hans Dedecker , INAGAKI Hiroshi , Petr ?tetiar , Jo- Nov 29 22:21:35 Philipp Wich Nov 29 22:21:40 aahhhh yes Nov 29 22:21:42 (unfortunately, it's not actually the complete view that procd has, it's just what was chosen to be exposed via ubus) Nov 29 22:21:42 thansk Nov 29 22:21:47 thanks* Nov 29 22:22:09 it has no pid :D Nov 29 22:22:09 ynezz: thanks for taking care of that lua path thing. Nov 29 22:22:20 guessing it has no child process tracking Nov 29 22:22:26 so it needs the pid... right? Nov 29 22:22:36 ynezz: I was thinking, would it be perhaps better to jsut kill that attempt at running lua on the host to try and work out paths outright? Nov 29 22:22:45 it's ~_never_ going to be right. Nov 29 22:22:52 and it's misleading to have it there Nov 29 22:22:59 jwh: make your app run in the foreground :) Nov 29 22:23:06 oh it broke, nm Nov 29 22:23:09 its not my app Nov 29 22:23:20 this is a package in the official tree that hasn't worked since it got committed Nov 29 22:23:23 :D Nov 29 22:23:27 well, does it have an option to "stay in teh foreground/debug mode" ? Nov 29 22:23:31 no Nov 29 22:23:44 and I really wouldn't want my routing daemon to be foregrounded by procd either Nov 29 22:23:52 no, you do. Nov 29 22:24:11 however, the old version worked fine Nov 29 22:24:14 procd manages thigns by keeping them alive, not having everything fork off and assume it is it's own little daemon Nov 29 22:24:15 only that didn't use procd Nov 29 22:24:24 umm Nov 29 22:24:37 I don't think I want procd trying to suck up 1000s of messages/second Nov 29 22:24:45 and it crashing and bringing down my entire network wirth it Nov 29 22:24:46 with* Nov 29 22:26:14 umm Nov 29 22:26:54 it doesn't even appear to be built as a package, at least not for 18.06.1 Nov 29 22:27:17 um, "running in the foreground" doesn't mean that Nov 29 22:27:27 build #169 of lantiq/ase is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/lantiq%2Fase/builds/169 Nov 29 22:27:34 it just means that when procd runs it, it has "easy" paths for holding the state of that process. Nov 29 22:27:35 it does because thats what the application does, its not meant to be attached Nov 29 22:27:42 build #173 of x86/64 is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/x86%2F64/builds/173 Nov 29 22:27:43 its either debug or daemon Nov 29 22:28:19 just saying, the general idea of having procd monitor your ting is, "stay in foreground, don't fork away and be your own daemon" Nov 29 22:28:53 look at https://github.com/openwrt/packages/blob/master/admin/monit/files/monit.init#L13 for instane... Nov 29 22:29:01 yeah Nov 29 22:29:06 but there is no way thats acceptable for this service Nov 29 22:29:27 but more importantly, why isn't it pacaged Nov 29 22:29:29 packaged* Nov 29 22:30:02 don't the official builders build all packages? Nov 29 22:30:10 thought they did Nov 29 22:31:05 look for log failures? Nov 29 22:31:11 it might be borked? Nov 29 22:31:23 jwh: why is it "not acceptable" to run in the foregroudn? Nov 29 22:31:44 you seem to have this weird (and untrue) association that "runnign in the foreground" means that if bird dies, it kills procd with it. Nov 29 22:31:47 that is... wrong. Nov 29 22:31:56 oh my bad, must not have made it into 18.06.1 Nov 29 22:32:02 karlp: no, if *procd* dies, it takes bird with it Nov 29 22:32:12 potentially Nov 29 22:32:17 if procd dies, you're already so fucked it doesn't matter Nov 29 22:32:30 well there you go Nov 29 22:32:33 remember, it's pid1. Nov 29 22:32:40 oh true Nov 29 22:32:42 what do you want to happen if innit dies on a classic system Nov 29 22:32:47 so I'd rather not flood it with crap Nov 29 22:32:50 no.... Nov 29 22:32:54 you're still not thinking right. Nov 29 22:32:56 nor do I want to enable debug mode Nov 29 22:33:05 "staying in the foreground" doesn't mean "becomes part of the same proces" Nov 29 22:33:22 and if "debug mode" jsut actually means "don't fork" then yes, that's exactly what you watn to do Nov 29 22:33:28 I guess as long as stderr and friends are handled its ok Nov 29 22:33:33 they are. Nov 29 22:33:54 but that still doesn't explain why it doesn't even send a TERM Nov 29 22:33:55 (they can be controlled via more procd options at least, which is the ~same thing) Nov 29 22:34:02 you said it had no pid listed. Nov 29 22:34:06 so it had nothign to send a pid tooo. Nov 29 22:34:07 thats coz I broke it :d Nov 29 22:34:16 because the one it started, forked and exited. Nov 29 22:34:24 so... stay in the foreground :) Nov 29 22:34:40 I need to find a snapshot box to test, I've lost the screen window with the box I was checking it on Nov 29 22:34:43 need less screens... Nov 29 22:35:35 alright I found it, yeah no pid because its forked, but hm Nov 29 22:35:42 can't i just tell it where the pidfile is? Nov 29 22:35:47 not sure sorry, Nov 29 22:35:55 there's actually a reason people stopped using pidfiles. Nov 29 22:35:57 they're racy Nov 29 22:36:16 you can get procd to write a pidfile, so that other process monitoring can watch things (procd doesn't do everyting) Nov 29 22:36:21 if it wasn't deciding where to forward multiple gbps worth of traffic I wouldn't mind it being in debug mode lol Nov 29 22:36:26 but I don't know whether procd can just get told a pid file to watch... Nov 29 22:36:44 (I use procd+monit myself, they overlap in different areas) Nov 29 22:36:50 hmmm Nov 29 22:36:57 seriously, check what "debug mode" actually means Nov 29 22:37:07 build #4 of ath79/nand is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/ath79%2Fnand/builds/4 Nov 29 22:37:08 for a lot of packages, that actually means "don't detach" Nov 29 22:37:19 hm it does have foreground actually, but bleh Nov 29 22:37:26 and logging and other "debug" shit is separate. Nov 29 22:37:28 and more importantly why didn't whoever committed it do that Nov 29 22:37:30 "but bleh" ? Nov 29 22:37:48 I can't answer history, Iðm only tryin gto help the here and now :) Nov 29 22:38:29 tbf it also missing some other stuff that would be nice but.... can someone just add -f to the cmd args for now Nov 29 22:38:32 :D Nov 29 22:39:21 I'm not sending any more git emails after the last fiasco Nov 29 22:39:37 you're overblowing it. Nov 29 22:39:50 a new email is better than losing a contributor, by _FAR_ (IMO) Nov 29 22:40:31 the legacy requirement for linus formatted mails has the collateral damage of a few (too many) wasted emails, but they'e all still better than not being involved. Nov 29 22:40:37 heh Nov 29 22:40:51 github prs are so much easier... I can't fuck it up as easily Nov 29 22:41:11 what went wrong with git-send-email? it's hard to fuck that up.... Nov 29 22:41:24 I don't remember any "fiasco" from the mailing list. Nov 29 22:41:50 it's not hard at all Nov 29 22:42:07 and you can't undo Nov 29 22:42:15 its just a pain in the ass, have to generate, edit, make sure i get the right commit (got it wrong last time and broken code got committed) Nov 29 22:43:31 it took me like 3 dry run attempts sending to myself to even get the format right Nov 29 22:45:46 you git clone,you edit, you git commit,you git send-email? I'm missing something :) Nov 29 22:45:49 anyway, keep at it! Nov 29 22:46:02 my biggest problems with git-send-email have been mail server relatd, not git related. Nov 29 22:46:15 indeed Nov 29 22:46:43 if e-mail could be removed from the equation, it would go a lot smoother Nov 29 22:46:54 not doing it, I decided last time unless its on github I'm just not gonna bother Nov 29 22:47:04 or gitlab, or similar Nov 29 22:47:23 jwh: thankfully, github is a supported/allowed method for submitting patches :) Nov 29 22:47:36 karlp: correct, but only the packages feed is on there Nov 29 22:47:55 jwh: no, you're allowed to submit owrt source prs there too, just be aware they're treated as second class citizens :) Nov 29 22:48:00 oh and telephony, but not routing Nov 29 22:48:21 wel yeah thats fine, doesn't really matter to me lol Nov 29 22:48:39 but I'd rather get it fixed upstream for others too Nov 29 22:49:04 well, gotta get it working first right? :) Nov 29 22:49:24 -f does the trick, so thats all it needs :d Nov 29 22:50:15 since I use the project its only fair I contribute some back... and I probably need to anyway if its covered by the GPL Nov 29 22:52:03 no, not at all, only if you distribute, and only if someone tried claiming that an init scvript was gpl, and could't be rewritten "independently" Nov 29 22:52:10 (still a "good thing to do"....) Nov 29 22:52:50 well I don't "distribute" but its included on managed devices, not sure if it counts but I'd rather contribute it anyway... others can use it and it means less local patches :D Nov 29 22:53:18 I can't be the only one using it on commercial networks Nov 29 22:55:01 just for my own interest, what do you with bird? Nov 29 22:55:23 BGP, BFD and OSPF Nov 29 22:55:31 transit, peering, some customer stuff Nov 29 22:55:57 bit of flowspec but I haven't finished the openwrt packaging for that yet because its go Nov 29 22:55:59 why is it desirable for all of them to be inside "bird" instead of as sepate things? Nov 29 22:56:07 thats just the way its designed Nov 29 22:56:15 I though bgp/ospf at least had separate services for years already? Nov 29 22:56:21 (this is nto my field) Nov 29 22:56:23 for quagga they're seperate daemons yeah Nov 29 22:56:51 build #170 of brcm47xx/mips74k is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/brcm47xx%2Fmips74k/builds/170 Nov 29 22:57:21 I was actually going to use FRR originally (quagga but maintained, working MPLS etc), but theres way too many libc hassles and I haven't got round to it Nov 29 22:57:22 build #171 of ar7/ac49x is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/ar7%2Fac49x/builds/171 Nov 29 22:57:43 plus bird was/is growing working VRF support so hopefully it'll be able to do the same at some point Nov 29 22:58:30 and honestly automation is easier with bird... write config, call birdc conf and it'll reload instances that need to be Nov 29 22:58:40 quagga is harder as it behaves like IOS Nov 29 22:59:11 that is, need to pipe (or send via telnet) config and hope its not in an order that will break connectivity before its finished sending it) Nov 29 22:59:33 * karlp hasn't looked at ospf/bgp/rip for ~15years or so Nov 29 22:59:56 I resisted bird for ages, but its actually a much more sensible way of doing things Nov 29 23:00:13 heh Nov 29 23:00:48 1.x was kinda meh, seperate daemons for v4 and v6... 2 is combined though finally Nov 29 23:01:11 plus 2 understands vpnv4 (and v6 I think), plus flowspec Nov 29 23:04:14 build #4 of ath79/tiny is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/ath79%2Ftiny/builds/4 Nov 29 23:11:28 build #1176 of ar7/ac49x is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/ar7%2Fac49x/builds/1176 Nov 29 23:35:38 can anyone tell me why i would want RGMII? Nov 29 23:35:49 because less pins Nov 29 23:38:39