**** BEGIN LOGGING AT Sat Jul 13 02:59:57 2019 Jul 13 07:26:16 Anyone that knows if there is a known MTU issue with QCA988X on ath10k for ath79? I can not observe any traffic on receiving end if interfaces are configured above 1514. Same setup works with ath9k driver/interface up to 2304. Jul 13 09:43:06 mt7621 master does not build anymore on master Jul 13 09:43:38 ssn: maybe the ramips reshuffle broke some things? Jul 13 09:43:46 let me try running an mt7621 build myself Jul 13 09:46:13 both erx and wg3526 won't build for me Jul 13 09:46:31 (erx has no wifi) Jul 13 09:55:43 you're running a single build for mt7621 i assume? Jul 13 09:55:53 with 'multiple devices' enabled in your config? Jul 13 09:57:08 wg3526 image generation fails with these: mkchkimg: Cannot open openwrt-ramips-mt7621-netgear_ex6150-squashfs-factory.chk Jul 13 09:57:15 wg3526 is not a netgear router Jul 13 09:57:50 nor is ex6150 the model you're looking for Jul 13 09:58:09 are you making images for *all* models under the mt7621 subtarget? Jul 13 10:01:00 ssn: rebuild with make -j1 V=s and check the log Jul 13 10:02:31 Borromini: no, I just build for the individual router Jul 13 10:02:50 so in this case wg3526 Jul 13 10:04:06 weird that you're getting messages about others then Jul 13 10:05:24 It fails with the message above Jul 13 10:06:55 pastebin please Jul 13 10:07:03 you did use -j1 V=s right? Jul 13 10:07:52 yes Jul 13 10:09:00 one sec Jul 13 10:30:16 ssn: ? Jul 13 10:58:03 blocktrron: ping Jul 13 11:10:20 Borromini: hmm? Jul 13 11:11:08 blocktrron: hi. was wondering if your rt-ac57u master commit could be backported to 19.07 still? Jul 13 11:13:15 Hmm, as I'm fairly new to the party, this is not a question i can / would like to answer immediatly. When i was asking for backports of devices, it was no problem for the maintainers to do so. Jul 13 11:13:48 I can prepare it and if nobody yells at me, add it to 19.07. Jul 13 11:14:47 that would be great. I used your v2 patch on 19.07 myself so i'm good, but it would be neat if it could be part of the 19.07 release Jul 13 11:41:40 I'm still stuck with the ssb bus of my BCM53312. So I'm looking for hints at the ecos sources. It appears like the device configuration is here: https://github.com/fvollmer/ecos-2.0-GS108Tv2/blob/master/mips_raptor_netgear.ecc#L26 . The ssb bus related stuff seems to be in "CYGPKG_HAL_MIPS_BCM953710". The entry point seems to be "hal_platform_init( Jul 13 11:41:40 )" at "plf_misc.c" which calls "sb_kattach" and then "sb_doattach" at "sbutils.c" (https://github.com/fvollmer/ecos-2.0-GS108Tv2/blob/master/packages/hal/mips/bcm953710/v2_0/src/sbutils.c ). I couldn't see anything interesting regarding initialization there. Any ideas? Jul 13 11:44:17 Maybe I should try to build the ecos source and see if my own build boots. Then I could play around with this to figure out where the difference is Jul 13 12:01:25 mangix: what's the new lua5.3 issue? :/ Jul 13 12:13:19 feeds/management/libnetconf/Config.in:6:warning: ignoring unsupported character '@' Jul 13 12:18:17 russell--: try make -C scripts/config clean Jul 13 12:39:18 Hello! I'm setting CONFIG_DOWNLOAD_FOLDER but it doesn't seem to change anything. Is it being continiously tested somehow or acn anyone vouch for it not being broken? Jul 13 12:40:44 ldir: thanks, been bumping into that too here with master. Jul 13 12:47:28 MOZGIII:works for me. Jul 13 12:47:33 I kinda rely heavily on it Jul 13 12:47:41 haven't seen breakage in that since... ever Jul 13 12:47:53 Maybe I'm using it wrong... Jul 13 12:48:33 CONFIG_DEVEL=y Jul 13 12:48:33 and CONFIG_DOWNLOAD_FOLDER=../dl Jul 13 12:48:42 Does it look right? Jul 13 12:50:21 I think it's not picked up by `make defconfig` Jul 13 12:59:54 Borromini: glad my experience has paid off for someone else Jul 13 13:03:13 ldir: thought about just wiping everything in build_dir and staging_dir, but figured in time that wouldn't be the cause of ncurses looking wonky. of course that didn't mean i did know what was :-P Jul 13 13:46:59 ynezz: ping Jul 13 13:56:24 jow: ping Jul 13 13:56:29 please please have a look at https://github.com/openwrt/openwrt/pull/2192 Jul 13 14:24:48 aparcar[m]: the scripts should be named json_add.sh and json_merge.sh Jul 13 14:24:59 or even device_json_*.sh Jul 13 14:25:16 and the resulting files should go into the bin folder similar to the manifest files Jul 13 14:25:38 and you might want to consider adding the packages and licenses aswell Jul 13 14:29:48 blogic: thanks for checking, Are you okay with having all files in a single folder? Jul 13 14:30:08 because sorting them to target/subtarget/ etc becomes a bit of a mess Jul 13 14:30:50 well Jul 13 14:31:04 they should be next to the images really Jul 13 14:32:38 having a bit aggregate file will make it go stale quickly Jul 13 14:35:46 but thats would bloat the aggreagate file as it needs to contain the target as well... Jul 13 14:35:50 what do you think Jul 13 15:51:30 jow: did your GPT partition table efforts for x86/64 ever merged? Jul 13 15:58:04 I'd so love GPT variant at some point :) (well both GPT partitioning and then EFI booting, separately good things) Jul 13 15:58:40 olmari: https://git.openwrt.org/?p=openwrt/staging/jow.git;a=commit;h=6667eef07563a029d0236a3a71e73a82c62f677b Jul 13 16:00:17 Dang! Jul 13 16:00:19 Cool Jul 13 16:07:10 hopefully padding/alignment is better with the efi images Jul 13 16:07:39 as the MBR ones are crafted manually and don't fit well into/onto non-512 sectore volumes Jul 13 16:11:07 Mm, AFAIK that is general problem with any mbr stuff, non-512 sector stuff that is Jul 13 16:12:16 true, but you could still align partitions onto non-512 boundaries, e.g. by skipping a couple of KB before the first partition starts Jul 13 16:12:56 that's what current OS installers do, hence the annoying "Free Space" blocks at the beginning/end Jul 13 16:15:21 Well that is usually the "1M boundary" for devices.. relates but not exactly "mbr can't boot from non512 sector device" Jul 13 18:08:26 hello, anyone have issues compiling 19? Jul 13 20:30:42 nbd: ping Jul 13 20:31:27 KanjiMonster: ping (alternatively) :) Jul 13 20:45:59 blogic: please review the patch again https://github.com/openwrt/openwrt/pull/2192 Jul 14 00:15:58 rmilecki: https://downloads.openwrt.org/snapshots/faillogs/arc_arc700/packages/elektra/compile.txt Jul 14 00:16:38 rmilecki: https://downloads.openwrt.org/snapshots/faillogs/arc_arc700/telephony/asterisk-16.x/compile.txt Jul 14 00:29:22 I assume those packages can safely be migrated to Lua5.3 Jul 14 00:35:26 mangix: but why should they do anything? Jul 14 00:35:45 people using eleketra (and others) probably want to keep using it with 5.1 like they have been. Jul 14 00:36:33 if they're failing because they're now detecting 5.3 first or something, that's something that needs to be handled, sure, but "porting elektra to 5.3" seems... at the least like the wrong way of framing it, it's not an elektra problem Jul 14 00:36:52 elektra just says "+lua" Jul 14 00:37:38 from elektra's point of view (speaking as not-elektra, but as someone else who has lua dependent pacakges) if I say "+lua" I mean I need "a lua" and I don't really care which, Jul 14 00:47:04 karlp: it's a mess either way. Jul 14 00:48:31 All I know is Lua 5.1 is unsupported. Luna 5.3 is Jul 14 00:48:36 *Lua **** ENDING LOGGING AT Sun Jul 14 03:00:21 2019