**** BEGIN LOGGING AT Thu Mar 26 03:04:32 2020
Mar 26 05:12:29 <aparcar> ynezz: when did you write this email regarding the online dev meeting?
Mar 26 08:24:40 <ynezz> aparcar: http://lists.infradead.org/pipermail/openwrt-devel/2020-March/022201.html
Mar 26 08:24:44 <ynezz> mangix: ok, thanks
Mar 26 08:28:45 <aparcar> ynezz: thanks
Mar 26 08:38:42 <aparcar> ynezz: ugh now you send a message 30 secs before I sent mine
Mar 26 08:40:55 <ynezz> yep, got a morning tea already so am faaster then matrix
Mar 26 08:41:25 <rubberduck> ynezz: its 9:41...
Mar 26 08:41:53 <ynezz> its tickless these days
Mar 26 08:42:21 <aparcar> ynezz: I'm running on plain IRC here. No handbreaks involved
Mar 26 08:42:31 <rubberduck> r u living in a window-free room?
Mar 26 08:42:48 <jow> basement!
Mar 26 08:45:10 <ynezz> aparcar: got a screenshot for you https://paste.ubuntu.com/p/DnhhvSVfZy/
Mar 26 09:09:22 * ldir ugh
Mar 26 09:10:56 * ldir apple breaks, fixes then breaks again
Mar 26 09:13:01 <ldir> xcode 11.4 needs export MACOSX_DEPLOYMENT_TARGET=10.14 - the initial release of xcode 11.3 needed that, then a few sub versions in they fixed it, now it's b0rked again
Mar 26 09:25:06 <f00b4r0> ldir: that's not so bad: my MBP upgraded last night and now my mouse cursor is disappearing :-§
Mar 26 09:26:39 <f00b4r0> but handoff appears to be working, for the first time since, well, ever. /me cringes
Mar 26 09:42:41 <aparcar> ynezz: what I don't understand the screenshot reference
Mar 26 09:43:37 <aparcar> ynezz: did you receive my response? it's like the mail was never sent... I can't find it any where
Mar 26 11:53:08 <ldir> Hauke: I hate PROVIDES handling too, it never seems to work how I hope
Mar 26 11:55:25 <ldir> Hauke: and throws unexpected dependency issues
Mar 26 11:55:40 * ldir also wishes he could re-subscribe to openwrt-devel
Mar 26 12:07:07 <karlp> well, PROVIDES is stil better than what we had, but yeah, it's still pretty pointy :|
Mar 26 12:13:48 <ynezz> wigyori: what about switching sunxi to 5.4?
Mar 26 12:14:20 <ynezz> Hauke: ^
Mar 26 12:39:33 <ldir> pointy - lol :-)
Mar 26 12:39:37 <Borromini> ynezz: hi. i just switched my master checkout to 5.4 for ipq40xx, to help testing
Mar 26 12:39:51 <Borromini> but i'm running into a weird dtb error concerning the EA6350v3
Mar 26 12:39:54 <Borromini> i'll pastebin it
Mar 26 12:41:37 <ynezz> it built fine week ago https://gitlab.com/ynezz/openwrt/-/jobs/472903658
Mar 26 12:44:06 <Borromini> i believe you, but except for a ramips 5.4 PR and the DIR-878 patch (also ramips) this tree has nothing special.
Mar 26 12:45:33 <ynezz> just kicked another built of the latest and greatest https://gitlab.com/ynezz/openwrt/-/jobs/486690727
Mar 26 13:40:07 <wigyori> ynezz: no objections against it, let me test it on the older boards i.e. a10, a13, a20
Mar 26 13:40:13 <wigyori> and then i think it's good to go
Mar 26 13:49:31 <ynezz> wigyori: binaries for a8 https://gitlab.com/ynezz/openwrt/-/jobs/485014798, a7 https://gitlab.com/ynezz/openwrt/-/jobs/485014798 and a53 https://gitlab.com/ynezz/openwrt/-/jobs/485014796
Mar 26 13:49:39 <ynezz> including the u-boot bump to 2020.01
Mar 26 14:00:47 <Borromini> ynezz: bah. maybe a config issue then.
Mar 26 14:01:02 <ynezz> Borromini: likely it builds just fine
Mar 26 14:01:09 <ynezz> and runs as well
Mar 26 14:01:17 <ynezz> well, on my device
Mar 26 14:13:53 <Borromini> ynezz: it's complaining the image is too big for the EA6350 v3, but i've added some packages. still, it's not like it's a flash starved devices afaik.
Mar 26 14:14:52 <ynezz> how are packages related to DTBs?
Mar 26 14:16:23 <Borromini> they're not, i misread. error is 'linksys_ea6350v3-fit-zImage.itb is too big'
Mar 26 14:16:26 <Borromini> https://hastebin.com/ipemacusen.coffeescript
Mar 26 14:16:45 <Borromini> i don't know what itb is but i suppose zImage is kernel related.
Mar 26 14:17:45 <ynezz> KERNEL_SIZE := 3072k
Mar 26 14:17:56 <Borromini> https://hastebin.com/gijoyaxafe.ini < that's my diffconfig
Mar 26 14:18:17 <ynezz> read that long comment in target/linux/ipq40xx/image/Makefile
Mar 26 14:19:42 <Borromini> for the nbg6617 you mean?
Mar 26 14:19:53 <Borromini> oh 6350
Mar 26 14:20:40 <Borromini> i'll see what a default config yields for the EA6350v3. great.
Mar 26 14:28:30 <ynezz> 5.4.28 bump available in my staging tree
Mar 26 14:55:14 <scde> Hi, I am running 19.07.2 which should have the 2.8.5-1 version of acme but its missing two commits from the master branch which were made before the 2.8.5-1 release. You can see compare https://github.com/openwrt/packages/commits/openwrt-19.07/net/acme and https://github.com/openwrt/packages/commits/master/net/acme and see commit c6b4d7f and 983cc99 is missing. Is this intended or should I open a ticket?
Mar 26 14:57:20 <karlp> well, the 2.8.5 is teh upstream version
Mar 26 14:59:05 <scde> Ok so are the two commits considered unstable? Will they be included in 20.07 first?
Mar 26 14:59:08 <zorun> scde: it looks like it was forgotten when backporting, you can open a ticket
Mar 26 14:59:18 <scde> Ok I will
Mar 26 14:59:24 <scde> ty
Mar 26 15:00:26 <zorun> these look like bug fixes, so it makes sense to backport them (but Toke is the maintainer and will decide ;) )
Mar 26 15:01:25 <scde> Ok I'll tag him in the issue and ask him (tohojo on GitHub right?).
Mar 26 15:02:50 <zorun> yes
Mar 26 16:35:53 <adrianschmutzler> I've ported a device from ar71xx to ath79 that has a button with undefined use, "BTN_1". A guy testing it reports that pressing this button triggers failsafe on ath79, while on ar71xx it does nothing. I have double-checked that I migrated the key config correctly, any idea how this can happen?
Mar 26 17:37:35 <adrianschmutzler> fblaese: hast du eine meinung zu "use dnsmasq" beim erx
Mar 26 18:13:44 <PaulFertser> adrianschmutzler: I think failsafe is triggered by any button that generates input events, both on ar71xx ath79.
Mar 26 18:16:20 <adrianschmutzler> button was pressed during normal operation, and then it rebooted into failsafe. but he couldn't reproduce, so it might be a memory/flash limitation issue, as it's a 4/32 device on master
Mar 26 18:16:41 <PaulFertser> Button pressed during normal operation doesn't trigger failsafe...
Mar 26 18:16:51 <adrianschmutzler> and sorry for posting in German up there, just missed the wrong channel
Mar 26 18:17:14 <adrianschmutzler> sounds wrong to me, too
Mar 26 18:17:15 <PaulFertser> Reset button pressed for more than 5 seconds triggers rootfs_data erasure and reboot.
Mar 26 18:17:49 <PaulFertser> But failsafe is only triggered during bootup, I do not think there's a way to schedule it anyhow.
Mar 26 18:18:17 <adrianschmutzler> yes, so it looks to me like an unrelated crash somehow
Mar 26 18:18:38 <PaulFertser> adrianschmutzler: is it possible the input is floating? In this case it can certainly happen that certain random boots will result in failsafe.
Mar 26 18:18:38 <adrianschmutzler> particularly since it couldn't be reproduced
Mar 26 18:19:11 <PaulFertser> Crash doesn't lead to failsafe entry, that's the thing.
Mar 26 18:19:27 <adrianschmutzler> Hmm ...
Mar 26 18:19:35 <adrianschmutzler> What I got from the guy: "When I pressed the ON/OFF button on ath79, the power LED started to flash and the device booted into failsafe mode."
Mar 26 18:20:34 <adrianschmutzler> Hmm, he doesn't explicitly say the device was on before. I'll ask again ...
Mar 26 18:20:43 <PaulFertser> adrianschmutzler: probably he just happened to press it during the 2-seconds failsafe entry interval?
Mar 26 18:21:23 <adrianschmutzler> that's what I think, however I do not see a reason to do that. But since that button is coincidentally named "ONOFF", maybe he did ...
Mar 26 18:21:40 <PaulFertser> Also, what if the person uses "failsafe" not in the "OpenWrt generic failsafe" sense?
Mar 26 18:22:53 <f00b4r0> routerboot hard_config sysfs driver working \o/
Mar 26 18:22:54 <adrianschmutzler> he uses "failsafe mode", I'd expect that to be correct
Mar 26 18:24:34 <adrianschmutzler> PaulFertser: Thanks for your hints, I'll ask and see what I get
Mar 26 18:26:25 <PaulFertser> adrianschmutzler: I'd also ask to check /sys/kernel/debug/gpio to see if the relevant gpio is not fluctuating on its own. That could happen if there is no external pull resistor and the DTS is not enabling internal to set stable state when button is depressed.
Mar 26 18:27:52 <adrianschmutzler> how would that manifest in /sys/kernel/debug/gpio ?
Mar 26 18:30:59 <PaulFertser> adrianschmutzler: by the value changing on its own, without pressing the buttons but due to RF interference
Mar 26 18:34:55 <adrianschmutzler> "The device was up and running."
Mar 26 18:37:34 <Borromini> ynezz: default config just works indeed for ipq40xx, thanks for confirming nonetheless.
Mar 26 18:39:22 <PaulFertser> adrianschmutzler: for how long after power up? And how exactly did he determine the failsafe mode, by seeing the banner after logging in with ssh?
Mar 26 18:45:47 <ldir> ynezz: slightly surprised your 5.4.28 bump doesn't cherry pick cleanly ?
Mar 26 18:52:10 <Risk64> I cannot compile gnutls on kernel 5.4/x64 anymore. curve448/eccdata.c:43:10: fatal error: gmp.h: No such file or directory. gmp is in build and staging dir. Any idea what's wrong?
Mar 26 18:54:20 <aparcar> ynezz: ping
Mar 26 18:55:34 <ldir> Risk64: have you done a make dirclean ?
Mar 26 18:56:02 <Risk64> ldir: Yes, started from scratch several times.
Mar 26 18:56:35 <ldir> ok, rules out the obvious then, sorry, can't help
Mar 26 18:58:25 <Risk64> I've put up more details here: https://forum.openwrt.org/t/gnutls-gmp-h-no-such-file-or-directory-5-4-testing-x64/58622
Mar 26 18:58:54 <Borromini> ldir: xback has a few bumps for all kernels. tried ynezz's on top of those but no dice either (he has a few other things in his tree i suppose)
Mar 26 18:59:27 <Borromini> Risk64: maybe some newer packages you're using? i saw you're on arch on the forum.
Mar 26 19:00:44 <Risk64> Borromini: At least not gmp or gnutls. They have the same version. But are host packages relevant at all? The openwrt toolchain should work on its own, doesn't it?
Mar 26 19:01:21 <Borromini> true, but it's compiled by your host system of course. haven't looked closely enough at your error to be sure whether it's host related or not
Mar 26 19:01:42 <Borromini> buildroot often breaks on bleeding edge like arch, because it's bleeding edge.
Mar 26 19:02:45 <Risk64> It looks like the include to staging_dir/host/include is missing.
Mar 26 19:21:36 <f00b4r0> adrianschmutzler: just curious: do you think the 3 small fixes I sent will be merged? I'm about to submit two fairly large proposals, one of which builds on top of the current pending patches
Mar 26 19:21:51 <f00b4r0> trying to get a sense of where I should base before submitting to m-l
Mar 26 19:23:21 <adrianschmutzler> f00b4r0: for the 1/2 I'm not really sure about the introduction of the nested partition scheme. art to hard_config change is fine for me.
Mar 26 19:23:38 <f00b4r0> it's not an introduction: this is how it's done on ramips
Mar 26 19:23:56 <adrianschmutzler> consequently, 2/2 looks good and is just waiting for my decision on 1/2.
Mar 26 19:24:07 <adrianschmutzler> okay, will have a look at ramips
Mar 26 19:24:23 <f00b4r0> adrianschmutzler: see http://git.openwrt.org/bbe2cf657c
Mar 26 19:24:45 <f00b4r0> adrianschmutzler: thanks. There's the small fix to the extract script too :)
Mar 26 19:25:05 <f00b4r0> hopefully my upcoming change will make it obsolete but in the meantime it's better to fix it
Mar 26 19:26:00 <adrianschmutzler> for the caldata, I haven't looked closely yet; I still have to compare it with the other extraction functions in base-files to judge whether that should be the way to go
Mar 26 19:26:43 <adrianschmutzler> particularly, since checking for the existence of the fwfile seems redundant to me, as this is done in the athXk_foo_extract scripts anyway IIRCE
Mar 26 19:26:50 <adrianschmutzler> *IIRC
Mar 26 19:27:25 <f00b4r0> yes. I was only addressing the case where that script could be used outside of the context of the other script
Mar 26 19:27:48 <f00b4r0> adding an extra check doesn't hurt. extracting a temporary file to flash and leaving it there certainly does
Mar 26 19:27:53 <f00b4r0> there's no functional change here
Mar 26 19:28:08 <adrianschmutzler> I won't have time to look at that today, but based on the ramips link you provided expect the patches 1/2 and 2/2 to be merged ...
Mar 26 19:28:15 <f00b4r0> ok cool, thanks
Mar 26 19:28:26 <adrianschmutzler> but still might take some days
Mar 26 19:28:44 <adrianschmutzler> For the caldata, I first have to make up my mind
Mar 26 19:29:01 <f00b4r0> ok, I'll just prep the next series with that assumption, I'm not ready to submit tomorrow anyway: I'm still waiting for more testing feedback from other users
Mar 26 19:29:31 <f00b4r0> adrianschmutzler: what is the issue?
Mar 26 19:29:36 <f00b4r0> the extra check?
Mar 26 19:29:47 <adrianschmutzler> and be aware that I probably won't be able to review that new series
Mar 26 19:30:29 <adrianschmutzler> for the caldata: I just haven't had a proper look at it, so I haven't decided anything
Mar 26 19:30:51 <adrianschmutzler> I won't review the patches right now, but you asked for a direction ;-)
Mar 26 19:31:11 <f00b4r0> yeah, that's good enough for me thanks!
Mar 26 19:37:21 <ldir> ynezz: ah, it's 6c03ae78a7 imx6: 5.4: apalis: dts: testing stuff
Mar 26 21:08:45 <Hauke> ldir: do you have an idea why the provides stuff is broken?
Mar 26 21:09:37 <Hauke> wigyori: ynezz I am fine with 5.4 for sunxi
Mar 26 21:09:42 <Hauke> but haven't tested it
Mar 26 21:10:10 <ldir> Hauke: No.  I was just adding a 'me too' - I've had 2 changes I've wanted to make that used 'provides' and had to abandon them.
Mar 26 21:10:33 <Hauke> I haven't looked into the code yet
Mar 26 21:10:39 <Hauke> or last time was many years ago
Mar 26 21:14:28 <ldir> I know when I'm beaten!
Mar 26 22:41:11 <ynezz> ldir: aye, sitting on pile of patches doesnt works quite well
**** ENDING LOGGING AT Fri Mar 27 02:59:57 2020