**** BEGIN LOGGING AT Tue Jun 25 03:00:38 2019
Jun 25 03:34:57 <gch981213> mangix: eth0/eth1 got swapped in https://git.openwrt.org/32817580e79bb
Jun 25 06:49:43 <sheldor_the_conq> Hi, I'm using latest openwrt 18.06.2 on TP LINK 8990, yesterday cron's update seems to be failed during netifd_2019-06-15-9932ed02-1_mips_24kc.ipk update
Jun 25 06:49:48 <sheldor_the_conq> Full log https://paste.debian.net/plainh/f787a4f1
Jun 25 06:50:47 <sheldor_the_conq> I've done actually hard reset and upload latest config file which permit me to use my tplink
Jun 25 06:55:45 <pkgadd> don't do that anyways
Jun 25 06:56:26 <pkgadd> (not that you could actually upgrade muliple packages on a 8 MB flash device)
Jun 25 07:15:27 <sheldor_the_conq> pkgadd: what's the good option ?
Jun 25 07:16:19 <mangix> gch981213: so I add the switch-phy-swap section under eth1?
Jun 25 07:18:50 <gch981213> mangix: You can just swap eth0 and eth1 in /etc/board.d/02_network
Jun 25 07:20:11 <mangix> My device has only one ethernet port
Jun 25 07:20:35 <mangix> https://github.com/neheb/source/commit/e8af0613a155503385cc960676d2a3fdffac8a2a
Jun 25 07:22:46 <gch981213> mangix: Then just add 'compatible = "syscon", "simple-mfd";' under eth1 node. This will disable the second gmac and you'll only see eth0 in system.
Jun 25 07:23:58 <mangix> hmmm ok I will try
Jun 25 09:27:28 <xback> ldir: ping
Jun 25 09:28:28 <xback> ldir: I just tried the wave1 fw that greearb__ has sent over.  It doesn't crash anymore.  Could you also give it a spin?
Jun 25 09:49:47 <ldir> xback: I'm not at home for the week so it's difficult for me to give a definitive test - sorry.
Jun 25 09:50:23 <ldir> I also couldn't make the buggy firmware crash 'at will' so testing was a bit erratic.... even more so if I'm not actually there :-)
Jun 25 09:54:25 <xback> ldir: ok, thnx for the reply :)
Jun 25 10:59:45 <xback> new day .. new bumps ..  pushed to staging
Jun 25 11:07:21 <ldir> it's a bit mad isn't it :-)
Jun 25 11:46:47 <ldir> xback: have 2 Archer c7 running on your kernel bumps - they booted at least :-)
Jun 25 11:47:17 <xback> ldir: your testing is highly appreciated as always :)
Jun 25 14:40:27 * mangix is happy he broke nothing :)
Jun 25 14:41:21 <jow> there's a nasty bug in buildbot which caused havoc in our repos
Jun 25 14:41:23 <jow> http://release-builds.lede-project.org/18.06/images/builders/x86%2Flegacy/builds/31/steps/gitfresh/logs/stdio
Jun 25 14:41:39 <jow> error: refname refs/heads/HEAD not found
Jun 25 14:41:40 <jow> fatal: Branch rename failed
Jun 25 14:42:10 <jow> this is what was causing all the troubles (despite infrastructure failures, unrelated bugs, generall ill timing of things falling apart at the same time)
Jun 25 15:05:22 <gch981213> It seems that gpio interrupt is broken on mt7621? gpio-keys doesn't work there.
Jun 25 15:14:32 <gladiac1337> CircleCI is unhappy
Jun 25 15:17:44 <gch981213> Fixed. GPIO IRQ definition is missing.
Jun 25 15:48:22 <mangix> gch981213: interrupts got fixed upstream. i'm guessing this was backported here?
Jun 25 16:13:21 <gch981213> mangix: The only backported upstream work is SPI driver, I guess.
Jun 25 16:24:07 <ynezz> gch981213: hi, do you've some plan to work on upstream ag71xx support for more devices?
Jun 25 16:28:00 <mangix> gch981213: so the mt7621 GPIO driver has been upstreamed with interrupt fixes and whatnot. It also requires DTS changes.
Jun 25 16:29:26 <mangix> gch981213: basic example: https://github.com/neheb/source/commit/625f051ee70bbd184ba3f59a4e217b64aa3e4f8d note the GPIO changes
Jun 25 16:30:17 <gch981213> ynezz: I'll decide whether to do that next month (during my summer vacation :D) I don't have all my ath79 routers with me now.
Jun 25 16:32:25 <mangix> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/staging/mt7621-gpio?h=linux-4.18.y not sure which commit fixes interrupts
Jun 25 16:40:23 <gch981213> mangix: In my case it's just a missing device tree property: https://git.openwrt.org/906b0aed3ec1a
Jun 25 16:41:15 <gch981213> mangix: Those driver fixes upstream seems to be fixing device-tree based GPIO IRQ usage.
Jun 25 16:48:10 <gch981213> mangix: and part of your example is incorrect: Upstream driver merged 3 gpio banks into one gpiochip and only &gpio0 in our dts can be directly replaced with &gpio . <&gpio1 x GPIO_ACTIVE_LOW> should be replaced with <&gpio x+32 GPIO_ACTIVE_LOW>. <&gpio2 x GPIO_ACTIVE_LOW> should be <&gpio x+64 GPIO_ACTIVE_LOW>
Jun 25 16:54:14 <mangix> oh interesting
Jun 25 16:54:56 <mangix> I was basing the interrupts thing on this: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/staging/mt7621-dts?h=next-20190625&id=1112b5b1c1936b69e801b42e8a22a79eac836ba8
Jun 25 16:58:48 * mangix is happy when he doesn't have to carry local patches
Jun 25 18:53:46 <jeffsf> Has anyone on dealt with the weirdness in sysupgrade where a sh function doesn't return to what called it? nand_upgrade_tar() returning to its calling case-statement in nand_do_upgrade(), in particular
Jun 25 18:54:54 <jeffsf> It ends up returning to do_upgrade_stage2() (which calls nand_do_upgrade() by way of platform_do_upgrade())
Jun 25 20:26:51 <ldir> well this is fun dd if=README of=README.new bs=1M conv=sync works on linux but not macos, dd if=README of=README.new bs=1m conv=sync works on macOS but not linux.
Jun 25 20:28:24 <ldir> I mention this because of  $(call Image/pad-to,$(KDIR)/root.squashfs,$(if $(1),$(1),$(CONFIG_TARGET_ROOTFS_PARTSIZE)M) in include/image.mk
Jun 25 20:29:43 <jeffsf> Yeah, I ran into that with an image.mk -- one of the "piped" commands was OK with M, the other needed m (though "k" was accepted by both)
Jun 25 20:29:51 <jeffsf> (on Debian)
Jun 25 20:30:07 <ldir> wonders how to make the suffix case change based on host OS
Jun 25 20:30:32 <jeffsf> It seems "M" vs. "m" is inconsistent even on Debian
Jun 25 20:31:03 <ldir> err, brilliant
Jun 25 20:31:57 <jeffsf> "design by committee"
Jun 25 20:33:31 <angelsl> are there any currently supported devices that have their MAC address stored in ascii a la this monstrosity? https://github.com/LeonPoon/openwrt/commit/bca78239d2fc34104ca25e3a86ef020513f23aa9
Jun 25 20:34:20 <jeffsf> Look at /lib/functions/system.sh:mtd_get_mac_ascii()
Jun 25 20:34:27 <micmac1> dlink dir-825-c1 has it stored in ascii for instance
Jun 25 20:34:32 <micmac1> I guess there are more
Jun 25 20:35:24 <jeffsf> (used 72 times)
Jun 25 20:35:49 <angelsl> ah, cool
Jun 25 20:36:12 <angelsl> thanks, i guess i can not use that kernel patch, lol
Jun 25 20:43:05 <pkgadd> ZyXEL NBG6817 is another example, taking the base MAC from ubootenv (in ASCII)
Jun 25 20:47:53 <angelsl> yeah, i just grepped, it seems pretty common
Jun 25 20:48:10 <angelsl> i guess the original author of ^ didn't know
Jun 25 20:48:22 <micmac1> I read that something went wrong with 18.06 "base" package list. But on an 18.06 device after "opkg update" opkg now suggests to upgrade openssl to 1.1.x. Did something else go wrong?
Jun 25 20:49:09 <KanjiMonster> micmac1: that is exactly what went wrong
Jun 25 20:49:17 <micmac1> OK, I'll shut up then
Jun 25 20:49:20 <micmac1> Thanks ;-)
Jun 25 20:49:49 <KanjiMonster> base was build based on tru^Wmaster, so chaos
Jun 25 20:50:50 <micmac1> Well, stuff sometimes goes belly-up.
Jun 25 21:27:09 <Pepes> Guys are you sure that this issue https://bugs.openwrt.org/index.php?do=details&task_id=2304 is corrected closed? Because I see that the reported version is OpenWrt 18.06.
Jun 25 21:27:11 <Pepes> The reporter said that there is still version 0.0.20190123 in OpenWrt 18.06 and it still the same. See https://github.com/openwrt/openwrt/blob/openwrt-18.06/package/network/services/wireguard/Makefile
Jun 25 21:27:15 <Pepes> correctly*
Jun 25 22:27:52 <mattsm_banned20> does anyone see this error:  * opkg_download: Failed to download http://downloads.openwrt.org/releases/18.06.2/packages/mips_24kc/base/Packages.gz, wget returned 8.
Jun 25 22:27:59 <mattsm_banned20> after running opkg update
Jun 25 22:37:45 <mattsm_banned20> it's just specific files failing
Jun 25 22:37:49 <mattsm_banned20> on opkg update
Jun 25 22:46:39 <DonkeyHotei> considering what time it is in europe, i doubt that will be fixed tonight; try again tomorrow
Jun 25 23:24:29 <mattsm_banned20> DonkeyHotei: are you seeing the same thing? who runs this can I drop them a message on IRC?
Jun 25 23:36:00 <DonkeyHotei> mattsm_banned20: i am seeing a 403 error
Jun 25 23:36:10 <mattsm_banned20> DonkeyHotei k thanks
Jun 25 23:36:14 <DonkeyHotei> and i think it's a known issue atm
Jun 25 23:36:18 <mattsm_banned20> i can't seem to drop a note on openwrt-adm
Jun 25 23:36:20 <mattsm_banned20> ok
Jun 25 23:36:22 <mattsm_banned20> thanks
**** ENDING LOGGING AT Wed Jun 26 02:59:57 2019