**** BEGIN LOGGING AT Tue Jul 23 02:59:57 2019 **** BEGIN LOGGING AT Tue Jul 23 06:45:28 2019 Jul 23 08:50:51 Does anyone happen to know why tools/cmake has a dependency on libressl? It appears to build ok for me without the dep so... curious. Was that an older cmake requirement ? Jul 23 09:19:11 aparcar[m]: Re: GitHub 500 errors -> not that bad, actually a good reason to go into the bed sooner :) Jul 23 09:23:03 anyway, it seems like they're slowly converting GitHub into GitPlex (CodePlex) Jul 23 09:23:32 'Upload an image to customize your repository’s social media preview.' :) Jul 23 09:30:30 ldir: git blame says https://git.openwrt.org/a0993dda5f4c7f69748d527e255522c0e5afeb81 Jul 23 09:37:04 from 2016 - my own build suggests it's no longer a requirement - https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commitdiff;h=29e6a5fdecbb087c87adb1fbbd516bc3996bbbc0 Jul 23 09:37:37 which means libressl could be switched to cmake Jul 23 09:37:40 maybe Jul 23 09:38:38 ldir: from felix's commit message, it seems just "one of cmake's utilities" uses libressl Jul 23 09:38:52 so presumably it's just not built (or built without support) is libressl is not there Jul 23 09:39:58 it would have been helpful if the utility/ies in question was noted. Jul 23 09:40:17 yes :) Jul 23 09:41:18 also, software (dependencies) changes over time Jul 23 09:48:46 when I grep for openssl in the cmake build I have a lot of matches Jul 23 09:50:17 I think we added this dependecy to not depend on a locally instaled openssl library Jul 23 09:50:21 and development headers Jul 23 09:50:37 http://git.openwrt.org/a0993dda5f4c7f69748d527e255522c0e5afeb81 Jul 23 09:50:40 ah, ok Jul 23 09:53:15 as previously said it's not the most informative of commit messages Jul 23 09:55:34 good, now I understand when those headers are being populated Jul 23 09:58:17 yes nbd should do bettrr commit messags Jul 23 10:00:22 I can see what you did..... WHY?!!!!!!! Jul 23 10:01:04 :-) Jul 23 10:10:30 hm, service_running in package/network/config/netifd/files/etc/init.d/network looks quite strange, does anyone have an idea what is going on there? Jul 23 10:12:33 /etc/init.d/network stop; service network running && echo "yes" || e Jul 23 10:12:45 Command failed: Request timed out Jul 23 10:12:48 yes Jul 23 10:18:45 do we still need that USE_PROCD ? Jul 23 10:40:46 so USE_PROCD is needed as there are 76 init scripts in the packages feed still not using procd for service management Jul 23 10:41:40 maybe we could make USE_PROCD default and modify those 76 init scripts Jul 23 10:42:03 announce it on the ML and make it a pinned thing on github too that as of now USE_PROCD is default Jul 23 10:42:14 also, hi from Amalfi coast :) Jul 23 10:43:04 heh, enjoy :) Jul 23 10:44:30 announce = send patches to the mailing list = enough, right? Jul 23 10:44:50 trying, but working 8h/day, just remotely not from home this week :) Jul 23 10:45:19 maybe announce that we want to do it, there are other feeds too possibly we need to take into account Jul 23 10:45:38 and pin a date in the near future that we will switch Jul 23 10:45:50 on packages feed someone could do a treewide PR to handle it Jul 23 10:46:22 list of the packages if someone is interested http://paste.ubuntu.com/p/4yGBgX6Df5/ Jul 23 10:49:30 gonna be fun to read git log when I get back home Jul 23 10:50:07 and hope to get khadas vim3 and librecomputing la frite soonish so I can finally finalize mesongx target Jul 23 10:50:28 and then I can pick up kodi again Jul 23 10:50:29 fun times Jul 23 12:07:06 ynezz: converting to procd is going to be interesting for ddns scripts Jul 23 12:08:45 has there been any news related to extending eol for 4.14? It was mentioned on the mailing list in a discussiong related to 19.07, but I can't find any comments from upstream maintainers Jul 23 12:13:56 ldir: I'm not going to force anything, I'm just going to send patches the standard way, so you (and anyone else) can of course NACK it if desired :) Jul 23 12:15:24 I simply think, that it's good time for such changes as we could iron out all potential issues before next release Jul 23 12:15:25 I think it's a great idea, and it prompted me to look at the stuff I use. There won't be a nack from me. Jul 23 12:16:04 I'll gladly ACK it - if I look at my mailbox in time :P Jul 23 12:18:57 ddns_scripts in essence implements its own procd Jul 23 12:35:56 my assumption is that kernel 4.14 will also be used extended to 5 years, I understood that all LTS kernels will now be supported for 5 years. Jul 23 12:36:34 4.14 is also used in android, but I do not know if it is already used in any phone Jul 23 12:38:34 Hauke_work: Thanks for letting me know Jul 23 13:49:39 cotequeiroz: hi, I've just noticed your omcproxy patch for 18.06, are you using omcproxy? Are you aware about this issue https://github.com/openwrt/openwrt/pull/2234 ? Jul 23 13:53:18 ynezz: It was just a trivial fix, I'm not using omcproxy. Jul 23 13:54:04 ok, thanks Jul 23 14:41:20 mangix: what exactly? Jul 23 14:41:28 Hauke_work: which old toolchains? Jul 23 14:44:36 jow: I think they are gone now Jul 23 14:44:56 jow: but we still have faillogs for the: https://downloads.openwrt.org/snapshots/faillogs/ Jul 23 14:45:05 like aarch64_armv8-a/ Jul 23 14:51:50 Hauke_work: well the problem are the frequent random target changes Jul 23 14:53:30 yes I know Jul 23 15:33:28 I'm very frustrated with procd. what on earth is rc_procd ? Jul 23 15:35:16 https://openwrt.org/docs/guide-developer/procd-init-scripts makes no mention of it. Jul 23 15:41:02 it's used extensively in adblock init - and err what eh? Jul 23 15:43:24 ldir: i think its fietkauism Jul 23 15:44:25 its some subshell wrapper magic if i recall Jul 23 15:47:57 The documentation on procd and writing start/stop scripts for it could do with some improvement. Jul 23 15:49:08 I retyped that at least 10 times before I'd managed to remove all the swearing. Jul 23 15:51:47 yeah, systemd ftw! Jul 23 15:52:49 lol Jul 23 15:52:56 is there any documentation at all? Jul 23 15:53:30 seems so, and looks quite good Jul 23 15:54:04 I would say, that it's a fate of wikis, always outdated Jul 23 15:54:47 ldir: there is documentation? ;p Jul 23 15:55:53 Sorry I'm so angry the sense of humour is broken. Jul 23 15:59:00 So it's yet another thing I've tried to have a look at and help out and ultimately end up frustrated. And I'm not sure if it's because I'm an idiot/inexperienced/confused by available options/confused by lack of documentation etc - you get the picture. Jul 23 16:07:51 rc_procd is a wrapper shell procedure which calls procd_open_service(), then the user supplied arguments, then procd_close_service() Jul 23 16:08:13 "user code" as in init scripts should never need to interact with it directly Jul 23 16:09:07 so it's asking procd to run a 'script/executable' Jul 23 16:09:24 no Jul 23 16:09:50 it will prepare a json structure internally which is then sent as service description to procd via ubus Jul 23 16:10:28 procd in turn will then decide what to do (e.g. start in case the instance didn't exist before, restart in case the instance existed but had different args or nothing if requested state and current runtime state are identical) Jul 23 16:11:25 dnsmasq.init does it. Jul 23 16:11:42 adblock.init does a LOT of it. Jul 23 16:12:32 rc_procd you mean? Jul 23 16:12:35 yep Jul 23 16:13:27 * ldir goes back to cleaning up firmware-utils - my C is better than shell script/procd....and that's saying something! Jul 23 16:17:24 okay. Basically you can think of rc_procd() as "open a service dict", "run user supplied function", "close the service dict and send it to procd" Jul 23 16:17:37 so in the case of dnsmasq it does rc_procd dnsmasq_start Jul 23 16:18:08 means open a service description, run dnsmasq_start() which will eventually do things like procd_set_param command ... Jul 23 16:18:17 then close the service description and send to procd Jul 23 16:18:47 if you run PROCD_DEBUG=1 /etc/init.d/dnsmasq restart you can see the json it assembles internally Jul 23 16:19:45 the problem is that the shell api is poorly thought out, especially the inconsistent callback styles Jul 23 16:20:59 on the other hand I do not understand why dnsmasq reload needs to both send a signal and update the service state Jul 23 16:21:28 probably to support starting further / stopping extraneous instances on reload Jul 23 16:25:33 * ldir goes for a reboot of both himself and his router Jul 23 16:33:02 jow: people arr complaining about missing packages: https://github.com/openwrt/packages/issues/9509 Jul 23 16:37:49 mangix: yeah, but thats not a buildbot problem Jul 23 16:38:20 mangix: the SDK is broken for this arch Jul 23 16:38:27 it cannot build cryptodev Jul 23 16:38:37 openssl now depends on cryptodev so it fails to build as well Jul 23 16:38:50 then everything on openssl fails too Jul 23 16:38:58 *everything depending Jul 23 16:42:55 got it. at least 19.07 is in good shape Jul 23 16:43:41 i am curious why the spidev_test package fails on all targets though Jul 23 16:43:45 x86/64 broke for me as well a few months back Jul 23 16:43:53 also does not build in the sdk anymore Jul 23 16:44:35 spidev_test fails because it attempts to build kernel sources which are not bundled with the SDK Jul 23 16:46:06 needs a fix similar to https://git.openwrt.org/ d0e0b7049f88774e67c3d5ad6b573f7070e5f900 Jul 23 16:46:14 https://git.openwrt.org/d0e0b7049f88774e67c3d5ad6b573f7070e5f900 Jul 23 16:47:13 mangix: btw, https://bugzilla.redhat.com/show_bug.cgi?id=1531182 Jul 23 16:47:29 seems others have similar issues Jul 23 16:47:59 we probably need to start shipping module.lds as well with the sdk Jul 23 16:56:20 ynezz: time to start placing USE_PROCD=0 Jul 23 17:02:23 Hi all, I'm one of the developers of OpenConnect (specifically, of the new support for the GlobalProtect VPN protocol, merged in v8.0) Jul 23 17:02:43 Hello :) Jul 23 17:02:49 I've been getting a steady trickle of questions about when OpenConnect v8.0+ will be available for OpenWRT (e.g. https://github.com/dlenski/openconnect/issues/21#issuecomment-514295140) Jul 23 17:03:19 It doesn't have any new dependencies at all, though a lot of new features most importantly the new protocol Jul 23 17:04:07 This isn't exactly a bug, so I didn't want to file it on the bug tracker, but just thought you guys might want to know it seems like a lot of OpenWRT users would appreciate a new build incorporating the latest upstream OpenConnect :) Jul 23 17:05:10 well current maintainer in openwrt is indeed "Nikos Mavrogiannopoulos" for that package... Basically he should take care of such things, but like life allways, he might not be around anymore, IF so, then we would need someone new to take care... or some variation of these Jul 23 17:05:21 Ah, didn't realize nmav is the maintainer… Jul 23 17:06:01 Thanks. I'll ping him about it. He's the main developer of ocserv and GnuTLS, seems he has his hand in everything VPN-related :) Jul 23 17:06:07 according to github link, which links to owrt wiki (: Jul 23 17:06:26 dlenski: wht version are we on right now ? Jul 23 17:06:42 @blogic, currently on v7.08 (released ~2017). Jul 23 17:07:08 should the update be straight forward or any caveate to expect ? Jul 23 17:07:11 There are lots and lots of bugfixes and performance improvements — some of which will surely benefit embedded environments like owrt — in v8.03 as well. Jul 23 17:07:39 @blogic, at this point it should be pretty much as simply as pull and make, I hope. Jul 23 17:07:56 i'll throw it on my todo list Jul 23 17:08:02 short question .... Jul 23 17:08:05 There were a few build issues in terms of headers and macros around the v8.0 release, but those should be ironed out by now. Jul 23 17:08:07 Thanks, @blogic. Jul 23 17:08:21 what effort would be involved to make openconnect support web based mfa such as okta ? Jul 23 17:09:59 That is certainly an active topic. The short answer is we haven't exactly settled on the appropriate way for SAML/OKTA to interact with the OpenConnect back-end. Jul 23 17:10:18 There are a lot of protocol- or provider-specific scripts floating around Jul 23 17:10:51 ok, i have one vpn that still requires okta, hoping to get a yubikey soon though Jul 23 17:10:52 E.g. https://github.com/arthepsy/pan-globalprotect-okta for openconnect + GP + OKTA Jul 23 17:10:58 so i can ditch anyconnect Jul 23 17:11:08 oh Jul 23 17:11:09 thx ! Jul 23 17:11:42 Yeah. Do take a look at those scripts. I didn't write them, and they're a little stylistically messy, but a pretty good solution for doing CLI-based login to Okta (including RSA or OATH based 2FA, such as Yubikey) Jul 23 17:12:08 5 Jul 23 17:12:21 dlenski: made a note to update openconnect anyhow Jul 23 17:12:24 I gotta dash off but will take a peek at any replies here, and I'll ping nmav about any help he can give on building OpenConnect v8.0+ for wrt Jul 23 17:12:31 Thanks! Jul 23 17:12:44 i'll create a PR and build test it Jul 23 17:12:56 6 Jul 23 17:13:23 sorry for the spam. i cant type Jul 23 17:15:27 ynezz: since you mentioned the omcproxy patch (maginx requested a backport), it should be a straight cherry-pick cb4d00d1841ef6269114f2bd3880800dbdfba3b1 Jul 23 17:15:37 *mangix Jul 23 17:23:28 cotequeiroz: in order to understand it better, you're requesting backport of this fix as the build of the omcproxy fails now in 18.06? Jul 23 17:25:41 cotequeiroz: I would simply like to add more details in the backport commit, do you've some fail log perhaps? Jul 23 17:26:46 At the time the patch was applied to master, the package was the same as 18.06 currently is, so it is technically not a backport, but a cherry-pick. Jul 23 17:27:04 mangix was the one who requested it, but I will pick one up for you. Jul 23 17:29:20 He mentioned this one: https://downloads.openwrt.org/releases/faillogs-18.06/arm_cortex-a9_vfpv3/base/omcproxy/compile.txt Jul 23 17:29:46 ok, thanks! Jul 23 18:33:58 jow: re: spidev_test it has @!IN_SDK so why it's being built in SDK? Jul 23 18:34:17 it's like perf, which would fail in SDK as well Jul 23 18:39:05 ynezz: maybe because @IN_SDK broke as well along the way Jul 23 19:24:59 Does anyone know how to specify **both** ipv4 and ipv6 addresses for a RADIUS server in /etc/config/wireless? From my quick look at /lib/netifd/hostapd.sh, it looks like multiple addresses cannot be specified for auth_server, but of course I may be mistaken about it. Jul 23 20:01:28 I am confused by this error Jul 23 20:01:31 src/dgn3500sum.c:156:23: error: '%04X' directive writing between 4 and 8 bytes into a region of size between 1 and 5 [-Werror=format-overflow=] Jul 23 20:01:31 sprintf(sumbuf,"%04X%04X",sum1,sum); Jul 23 20:02:11 what is the size of sumbuf? Jul 23 20:03:24 no idea - that's not what bothers me. %04X Jul 23 20:03:43 does that not mean print 4 capital HEX chars ? Jul 23 20:03:52 char sumbuf[9]; Jul 23 20:04:09 Yes, A-F rather than a-f (%04x) Jul 23 20:04:26 it means a _minimum_ of 4 Jul 23 20:04:36 ldir: what's the type of sum1/sum? Jul 23 20:04:48 unsigned short sum = 0, sum1 = 0; Jul 23 20:04:52 ah, there's no upper limit beyond that of the source type Jul 23 20:05:20 so the type needs to be uint16 Jul 23 20:05:50 or cast to it Jul 23 20:06:58 I honestly thought %04X was 'print up to 4 hex chars with leading zeroes if required' Jul 23 20:07:00 unsigned short is C89 for uint16 Jul 23 20:35:07 if (((struct auh_header *)tmp_buf)->header_checksum == (uint16_t) ~jboot_checksum(0, (uint16_t *) tmp_buf, AUH_SIZE - 2)) { Jul 23 20:35:24 yummy Jul 23 20:36:23 Makes APL seem totally comprehensible **** ENDING LOGGING AT Wed Jul 24 02:59:57 2019