**** BEGIN LOGGING AT Mon Jun 03 02:59:57 2019 Jun 03 07:59:26 kill me now - the donald has landed in this country Jun 03 08:03:38 oh no Jun 03 09:21:37 it's your country, don't let him ruin your day Jun 03 09:47:22 hm, what I'm doing wrong, in order to take a look at FS#2283 I've downloaded http://downloads.openwrt.org/snapshots/targets/ramips/mt76x8/kernel-debug.tar.bz2 Jun 03 09:48:18 I would like to see the details about the stacktrace, so I've loaded that debug/modules/mt7603e.ko in gdb Jun 03 09:48:42 but it seems like it doesn't contain the debugging symbols `Reading symbols from debug/modules/mt7603e.ko...(no debugging symbols found)...done. Jun 03 09:49:20 any other way how to resolve `[592590.084214] [<830f73ac>] 0x830f73ac [mt7603e@830f0000+0x87a0]` into line number in C file ? Jun 03 09:52:19 maybe this `$(FIND) $(KERNEL_BUILD_DIR)/debug -type f | $(XARGS) $(KERNEL_CROSS)strip --only-keep-debug` doesn't work anymore ? Jun 03 09:53:26 debug/modules/mt7603e.ko: ELF 32-bit LSB relocatable, MIPS, MIPS32 rel2 version 1 (SYSV), BuildID[sha1]=37b419568e40c7b6570a4a84d19fed42e735bfb6, not stripped Jun 03 09:53:34 strange Jun 03 09:59:31 can confirm with brcm63xx; the kernel itself is fine, but the modules seem to be without any debug symbols Jun 03 10:00:21 yes, kernel is fine Jun 03 11:01:13 hm, it's either hack-4.14/202-reduce_module_size.patch or hack-4.14/220-gc_sections.patch Jun 03 11:01:29 making kernel-debug.tar.bz2 useless Jun 03 11:07:56 hack-4.14/202-reduce_module_size.patch is the winner Jun 03 12:56:52 jow: (or any translation person) what's the "right" way of handling embedded markup like and stuff? https://zerobin.net/?5fecd3f36fa0871e#y6KlL4CexZL2OxbXMOLEsjjMZgAkt+peOBt7Xc+ery0= Jun 03 13:23:48 ynezz: I'm 99.9% sure the patch is safe to drop; I just did builds with and without, and the kmod packages (and their included .kos) didn't change sizes except for a few bytes, if at all Jun 03 13:24:58 KanjiMonster: is that your Acked-by ? :) Jun 03 13:26:37 I just wanted to ask for a runtest before that, but I don't think there is a way we strip more/different things after that, only less for the normally packed modules Jun 03 13:27:00 so yeah, let's say that's an ack ;) Jun 03 13:27:11 I'll run test it, don't worry Jun 03 13:28:39 BTW I would really like to move forward with urngd in order to get more testing before the 19.y release, but since it touches all platforms and possibly some parts related to security, I would like to get at least one Acked-by as well Jun 03 13:28:44 any volunteer? :) Jun 03 13:29:01 or should I simply ask for that in the email? Jun 03 13:58:03 ynezz: i have no idea what a "urngd", send a PATCH maybe :) Jun 03 13:58:39 rmilecki: https://patchwork.ozlabs.org/cover/1105971/ Jun 03 13:59:02 :+1: Jun 03 14:00:06 rmilecki: previous RFC discussion https://patchwork.ozlabs.org/cover/1102114/ Jun 03 14:00:16 ynezz: thanks, I'll try to test that tomorrow Jun 03 14:00:25 cool, thanks Jun 03 14:15:16 kristrev: hi, I've tweaked your https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=commit;h=6aaa8b99853316957dadf0cec95039b6deb6991c (ath79: Add support for ZBT-WD323) little bit, could you please check it? Jun 03 14:16:19 ynezz: Thanks! Will check it tonight or tomorrow morning Jun 03 14:18:20 Btw, which platforms would you like someone to check urngd on? I am not qualified to have any opinions on the security-part of the solution, but I can at least test and make sure it doesn't break anything on my devices :) I have ath79 and mt7620 (which it seems you have already tested), mt7621 (which has a hardware rng) and an x86 board without any hardware rng Jun 03 14:20:09 I can at least test urngd on the latter. I read your email with the haveged references, so removing haveged is desirable :) Jun 03 14:21:44 it would be nice if you could provide times for `random: crng init done` with and without urngd for all your platforms Jun 03 14:22:05 ath79/x86 is quite broad family Jun 03 14:22:50 ok, I will do that then Jun 03 14:22:54 thanks Jun 03 14:24:25 target/linux/gemini/patches-4.14/0014-ARM-dts-Flags-D-Link-DIR-685-I2C-bus-gpios.patch 105 19,18-31 All Jun 03 14:24:32 err, sorry Jun 03 14:25:05 anyway, it makes me wonder how this could work Jun 03 14:33:32 ah, 4.14 supports both Jun 03 14:34:21 ynezz: I only see 1,3,4/4 for https://patchwork.ozlabs.org/project/openwrt/list/?series=110196 -- is that correct? Jun 03 14:35:23 jeffsf: good point, probably some patchwork hiccup 2/4 is https://patchwork.ozlabs.org/patch/1105970/ Jun 03 14:37:43 That explains the "no getrandom" problem I was seeing Jun 03 14:51:23 ynezz: AR300M (NAND), ath79 WIP, Linux 4.19: [ 19.105253] urngd: v1.0.0 started. [ 19.646120] random: crng init done Jun 03 14:51:26 vs. [ 129.708776] random: crng init done Jun 03 14:51:45 ynezz: that happened because 2/4 landed before 0/4 on the maling list, and thus patchwork (so there was no series to attach the patch to yet) -> https://pastebin.com/Qyp2B3a8 Jun 03 14:51:53 *mailing Jun 03 14:52:35 qca9531 Jun 03 14:53:45 KanjiMonster: yeah, patchwork hiccup Jun 03 14:53:51 it should handle this better :) Jun 03 14:54:40 patchwork should handle it better, but it was infradead that sent out the emails in the "wrong" order ;) Jun 03 15:02:41 karlp: use <%_ ... %> instead of <%: ... %> Jun 03 15:12:58 directly %_ not %= _ to use the built in lua one? Jun 03 15:13:25 should I add this to https://github.com/openwrt/luci/wiki/Templates or to https://github.com/openwrt/luci/wiki/i18n ? (which are both slim on this sort of thign) Jun 03 15:15:05 jeffsf: good, thanks Jun 03 15:16:55 karlp: yes, %_, not %: Jun 03 15:17:02 or %= _ Jun 03 15:17:20 I saw also while I was poking the i18n-scan.pl that it is looking in js files? Jun 03 15:17:36 how does that work? what can the js files do to magically reach into the lmo files? Jun 03 15:17:56 or what magic do I tell uhttpd to process them ahead of time? and how does the browser caching work with that? Jun 03 15:18:18 karlp: current luci master exposes lmo catalogs as .js files Jun 03 15:19:01 is there an app I can copy from that uses that? Jun 03 15:19:50 I don't think I have any text in js right now anyway, (hopefulyl) but woudl be a nice example to look at :) Jun 03 15:24:51 https://github.com/openwrt/luci/commit/c916b5ed875675749c3a04c7b95340a5d4443722#diff-57ca943fe505302cec46986303d4ce43 + https://github.com/openwrt/luci/commit/ab405edfb63c589204fed7d54748f2d1e8108d18#diff-57ca943fe505302cec46986303d4ce43 + https://github.com/openwrt/luci/commit/31bce2455fdeacefbb837d6abb95584df66c36a2#diff-57ca943fe505302cec46986303d4ce43 Jun 03 15:25:21 plus a bunch of fixes in later commits Jun 03 15:25:45 there were some corner cases in the JS hash function implementation Jun 03 15:26:02 oh boi, yo moved the entire cbi over too, it's not "_also_ as a js file" it's "only as a js file" Jun 03 15:27:01 well, no. but ok, neat thanks. Jun 03 15:27:06 hm? cbi.js was always there, its badly named and contains varius luci helpers Jun 03 15:27:32 I do have a cmplete client side implementation of cbi in a private branch, but its not in luci master yet Jun 03 15:27:50 if I've selected a language explicitly in luci then, my own js files can just start using _() stuff then? (as long as my theme includes cbi.js, which it has to anyway) Jun 03 15:28:57 assuming a somewhat recent LuCI master, then yes Jun 03 15:29:23 and to make it degrade gracefully on older versions you could provide a _() stub function simply returning its input in case it is not defined Jun 03 15:29:56 ok. I'm still on 18.06 now, and I don't need js stuff yet, just want to be ready for what comes down the road. Jun 03 15:30:06 hopgin to move to 19.?? when it comes around Jun 03 15:30:19 do you still have a lot of action in luci you want to land before then? Jun 03 15:30:34 18.06 -> master has lots of luci changes already. Jun 03 15:31:06 depends on how much 19.x will be delayed Jun 03 15:31:15 good answer :) Jun 03 15:31:23 maybe I'll merge the client side stuff before, maybe not Jun 03 15:52:39 jow: is there anything like <%_ for lua code? like in cbis where the last parameter to the Map becomes all the intro text? Jun 03 15:55:00 cbi.lua only seems to have translate and translatef, so I'm guessing not. Jun 03 16:06:45 karlp: you mean to allow interpolating HTML ? Jun 03 16:09:50 karlp: the title and description arguments to Map() are rendered as-is by the map.html template, so a simple translate("foo") should work Jun 03 16:10:13 karlp: <%_ ... %> is only really needed in templates as <%: ... %> by default HTML-escapes its output Jun 03 16:11:04 Lua translate() output is usually rendered using <%= ... %> in templates so no special handling is needed Jun 03 16:13:28 I will recheck my cbi maps, I found that they needed translate() not _() and might have split things up there too, Jun 03 16:13:59 been having fun making a language file with xxxxx as the translation for everything (of the right length) to visibly find missing strings Jun 03 18:07:23 ynezz: Everything seems to work fine after your changes, with the exception of the button. However, I think that might be related to the issue that I have seen discussed here & on the mailing list. Behavior is at least consistent with the description from kyli Jun 03 18:09:41 I see that on the branch I used for adding support for the WD323, I do not have the gpio-button-hotplug-commits Jun 03 19:14:05 ynezz: I put the result of my urngd-tests here: https://pastebin.com/S7F9dWEZ Jun 03 19:21:11 Amazing how cleanly code compiles when, err, it isn't compiled Jun 03 19:21:49 kristrev: nice, thanks! Jun 03 19:40:39 You there?? Jun 03 21:00:14 kyli, kristrev: that gpio button behaves same here even with that afc056d7d ("gpio-button-hotplug: support interrupt properties") reverted Jun 03 22:12:54 kyli, kristrev: probably a fix https://git.openwrt.org/d6e92c0af3 ? Jun 04 00:21:48 Where might one find schematics of the AR7161 BGA pinout? I know it's a rabbithole, but ... Jun 04 00:36:07 ~. Jun 04 00:36:09 ~. Jun 04 00:36:48 ~.~ Zzzzzz Jun 04 00:38:02 wsa trying to exit ssh :) Jun 04 01:32:36 q Jun 04 01:32:41 bah Jun 04 02:02:42 * gch981213 sent a link to hurricos via PM **** ENDING LOGGING AT Tue Jun 04 03:00:18 2019