**** BEGIN LOGGING AT Fri Feb 12 02:59:57 2021
Feb 12 03:27:14 <owrt-snap-builds> build #745 of malta/be is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/malta%2Fbe/builds/745
Feb 12 04:52:45 <owrt-1907-builds> build #262 of sunxi/cortexa53 is complete: Failure [failed pkgbuild]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/sunxi%2Fcortexa53/builds/262  blamelist: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Feb 12 07:26:45 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_bcm47xx.html has been updated. (100.0% images and 95.3% packages reproducible in our current test framework.)
Feb 12 08:28:51 <rmilecki> Tapper: hey, i'm looking at the LuCI issue you reported: #4801 add missing btn class to buttons
Feb 12 08:29:39 <rmilecki> Tapper: do screenreaders actually handle class "btn" in some special way? or is it some CSS related to the "btn" that applies and matters?
Feb 12 08:33:37 <Tapper> rmilecki Hi just got out of bed so bbair with me.
Feb 12 08:34:33 <Tapper> It does help screen readers I will find you a link what says it better than I can.
Feb 12 08:34:49 <rmilecki> Tapper: great, thanks
Feb 12 08:35:47 <rmilecki> Tapper: i find that "btn" class something fragile, I don't believe HTML / CSS specification treates "btn" name in any specific way
Feb 12 08:35:54 <Tapper> https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/button_role
Feb 12 08:35:58 <rmilecki> Tapper: i was wondering if there is some better way of achieving the same
Feb 12 08:36:03 <rmilecki> Tapper: like ARIA or similar :)
Feb 12 08:36:07 <rmilecki> Tapper: let me check that
Feb 12 08:36:43 <rmilecki> Tapper: oh, that role="button" looks way more "stable"
Feb 12 08:36:59 <rmilecki> Tapper: that seems to be more explicit
Feb 12 08:37:24 <rmilecki> Tapper: could you verify if we can replace class="btn" with role="button" and have a nice screenreader support still?
Feb 12 08:37:38 <Tapper> When you don't have the btn class some times your screen reader does not fokes on the button so you cant click on it.
Feb 12 08:38:00 <Tapper> Yeah I will have a look.
Feb 12 08:38:17 <rmilecki> Tapper: thanks
Feb 12 08:41:06 <Tapper> rmilecki I am not shure on the exact difrence between btn class and btn role. sorry.
Feb 12 08:41:30 <rmilecki> Tapper: well, if there isn't obvious difference, I vote for using role "button"
Feb 12 08:41:52 <rmilecki> Tapper: that way it says explicitly what's the link purpose
Feb 12 08:41:54 <Tapper> OK as long as it works.
Feb 12 08:41:56 <Tapper> lol
Feb 12 08:42:00 <rmilecki> :)
Feb 12 08:42:06 <Tapper> thanks for looking.
Feb 12 08:42:16 <rmilecki> Tapper: thank you :)
Feb 12 09:00:36 <jow> I think if at all, the .btn CSS class triggers some screen reader heuristics
Feb 12 09:02:06 <jow> and it should be redundant for <button> elements
Feb 12 09:02:42 <jow> I guess it helps in cases where non-<button>, non-<input> elements are styled like buttons, e.g. <a> or <div> tags
Feb 12 09:02:56 <jow> but iirc that isn't done anywhere in base LuCI
Feb 12 09:06:14 <rmilecki> jow: i thought the same (heuristics)
Feb 12 09:06:42 <rmilecki> jow: let me check example pointed by Tapper
Feb 12 09:07:32 <rmilecki> Tapper: i'm looking at the commit you pointed out: https://github.com/openwrt/luci/commit/34417400893d8513f92c4e4ba3a1b8c9207a5392 luci-app-advanced-reboot: add missing btn class to buttons
Feb 12 09:07:57 <rmilecki> Tapper: that commit adds "btn" class to the <button> elements
Feb 12 09:08:28 <rmilecki> Tapper: that should be redundant, i would expect every screen reader to treat <button> as button obviously
Feb 12 09:08:38 <rmilecki> Tapper: even if <button> does not have "btn" class
Feb 12 09:11:38 <Tapper> I am not shure on the exact code used. I know that buttons work as they should when the are dun proper. My issue is that in luci > firewall the buttons labled Save and Reset work as they should. the Save & Apply one does not and some times the screen reader does not let me click on the buttons as it should.
Feb 12 09:12:28 <Tapper> Even the Save Reset ones some times do not let me press them I have to tab back and then tab foreword  again.
Feb 12 09:14:46 <Tapper> Some times the button labeled Save & Apply just says out of list  ▾
Feb 12 09:14:46 <Tapper> blank
Feb 12 09:15:46 <rmilecki> Tapper: thanks for examples, i'll check them
Feb 12 09:15:54 <Tapper> NP thanks
Feb 12 09:26:49 <Borromini> blogic: ping
Feb 12 09:30:44 <jow> the save & apply button is actually a dropdown
Feb 12 09:30:55 <jow> for that one, an aria-role=button actually makes sense
Feb 12 09:32:10 <Tapper> jow It does not work. Not with a screen reader any way.
Feb 12 09:32:32 <Tapper> I didn't even know it was a drop down.
Feb 12 09:32:58 <Tapper> There is a lot more to buttons than I thought.
Feb 12 09:32:59 <Tapper> There is more to buttons than I thought.
Feb 12 09:33:06 <Tapper> https://www.deque.com/blog/accessible-aria-buttons/
Feb 12 09:38:04 <jow> Tapper: yeah, I figured
Feb 12 09:42:08 <blogic> Borromini: hi
Feb 12 09:42:21 <Borromini> blogic: hi!
Feb 12 09:43:44 <Borromini> would you merging this patch? https://patchwork.ozlabs.org/project/openwrt/patch/20210204144914.293546-1-sander@svanheule.net/
Feb 12 09:44:33 <Borromini> or there's a few MT7621 devices that need this for their switch to be reset
Feb 12 09:44:58 <Borromini> s/or //
Feb 12 09:47:45 <blogic> ok
Feb 12 09:47:51 <blogic> will do when I am back on my pc
Feb 12 09:48:46 <Borromini> thanks a lot =)
Feb 12 09:49:19 <svanheule> Borromini, blogic: thanks!
Feb 12 11:10:16 <mwalle> hi, I was just looking at support for openwrt for our layerscape based board (aarch64). It has upstream support since 5.9. It appears that the layerscape/arm64 boards are using 5.4. Are there any plans to bump that version in the near future (next LTS kernel?)
Feb 12 11:11:12 <Borromini> mwalle: after 21.02 gets branched
Feb 12 11:11:28 <Borromini> there's 5.10 patches for a few targets already
Feb 12 11:11:36 <Borromini> but not layerscape afaik.
Feb 12 11:12:28 <mwalle> Borromini: ah nice, i have a quick look at the layerscape patches for the 5.4 kernel. it looks like most are backports
Feb 12 11:13:24 <Borromini> plan seems to be to branch 21.02 next week, but i have no idea how quickly 5.10 patches will move into master after that
Feb 12 11:14:25 <Borromini> https://git.openwrt.org/?p=openwrt/staging/nbd.git;a=summary < there's preliminary 5.10 support in this tree e.g.
Feb 12 11:15:27 <Borromini> this is just general treewide, targets often need further work to be fully functional
Feb 12 11:15:49 <mwalle> Borromini: sorry, I haven't done any development in openwrt for now, so this might be a stupid question: how do the bumps to a new kernel version look like?
Feb 12 11:16:21 <mwalle> eg. https://git.openwrt.org/?p=openwrt/staging/nbd.git;a=tree;f=target/linux/layerscape/armv8_64b;h=abc1e4fb6a9b83eec71f76351603240e49b65693;hb=HEAD, there is still the 5.4
Feb 12 11:16:25 <Borromini> mwalle: like this https://git.openwrt.org/?p=openwrt/staging/nbd.git;a=commitdiff;h=3b27b5ad1a42426420dfa46ebb932dd1fc704fbf
Feb 12 11:16:48 <Borromini> and to bring up a target to that new kernel, like this e.g.: https://github.com/openwrt/openwrt/pull/3693
Feb 12 11:17:14 <Borromini> so a generic treewide part and a target specific part
Feb 12 11:17:54 <mwalle> Borromini: ahh thanks for the pointers! So there is really just one kernel version for all targets (or most?)
Feb 12 11:18:31 <Borromini> yes, 19.07 was a mixed release but 21.02 should be all 5.4
Feb 12 11:19:14 <Borromini> to lower maintenance burden there can be a testing kernel (5.10 in case for ramips, e.g.) and a 'stable' kernel (5.4)
Feb 12 11:19:37 <Borromini> but once the overall tree has moved to a new default kernel older ones tend to be stripped
Feb 12 11:21:19 <mwalle> Borromini: ok, so the "for-next" is https://git.openwrt.org/?p=openwrt/staging/nbd.git? ie. i should take that as a starting point
Feb 12 11:30:13 <Borromini> mwalle: yes, those 5.10 patches might very well move to master
Feb 12 11:30:25 <Borromini> see the ramips PR from github i linked, that's based on those patches as well
Feb 12 11:53:33 <mwalle> Borromini: thanks!
Feb 12 11:58:35 <joaohcca> @Hauke I see, maybe a conflict between software and hardaware watchdog ? It is something that I should fix on my code?
Feb 12 11:59:51 <Borromini> mwalle: happy to help. good luck.
Feb 12 12:53:47 <mwalle> ha, here is another one. uboot-layerscape, I take that "layerscape" is a generic name, i.e. my board should be "layerscape" but it has both upstream linux and upstream uboot support. thus uboot-layerscape is really just an "uboot-layerscape-nxp-only-evalboars". Hum
Feb 12 12:54:56 <mwalle> and there seems to be no vanilla uboot package. are there no boards which use an unmodfied uboot? ;)
Feb 12 13:31:34 <ynezz> mwalle: imx6
Feb 12 13:31:59 <ynezz> or you mean from layerscape?
Feb 12 13:33:09 <mwalle> ynezz: no in general, I was just asking myself where I should put the bootloader for my board
Feb 12 13:33:27 <mwalle> uboot-layerscape isn't suitable, because its the nxp branch
Feb 12 13:34:48 <mwalle> (or even tree)
Feb 12 13:37:35 <ynezz> what board is that?
Feb 12 13:44:17 <ynezz> naming is hard, but if IIUC and you've some board which is supported by the upstream uboot, then perhaps the current directory should be renamed to uboot-layerscape-lsdk
Feb 12 13:44:53 <ynezz> (if that would be possible)
Feb 12 13:48:55 <mwalle> ynezz: the board name is kontron_sl28 (dunno if that will help you much ;) but its based on a LS1028A SoC
Feb 12 13:49:23 <mwalle> ynezz: and yes, that would be a better name, although the upstream name is uboot-qoriq
Feb 12 13:50:15 <mwalle> which has the same problem, so yeah, the -lsdk suffix would be correct
Feb 12 14:40:48 <mwalle> doh. even the target/linux/layerscape is really a layerscape-lsdk :( because it imports all the lsdk patches on top of the 5.4 kernel
Feb 12 14:44:12 <mwalle> so this might be a bit unpopular: what do you think about renaming the whole layerscape cruft to layerscape-lsdk ? and create a new layerscape which uses the vanilla kernel and stuff
Feb 12 16:27:53 <rmilecki> adrianschmutzler: hey, don't we need to add SOC to the list of variables?
Feb 12 16:28:25 <rmilecki> adrianschmutzler: i'll test your patch this weekend I hope
Feb 12 16:29:15 <adrianschmutzler> rmilecki: it's in image.mk I think
Feb 12 16:29:36 <rmilecki> include/image.mk:  DEVICE_DTS_CONFIG DEVICE_DTS_DIR DEVICE_FDT_NUM SOC BOARD_NAME \
Feb 12 16:29:39 <rmilecki> thanks adrianschmutzler
Feb 12 16:29:44 <rmilecki> i'll test it
Feb 12 16:30:06 <adrianschmutzler> exactly, that was part of my unification efforts
Feb 12 16:30:31 <adrianschmutzler> so, we have that on ath79, ramips, lantiq, ...
Feb 12 16:54:14 <ynezz> mwalle: I would prefer to get rid of this LSDK crap and just use upstream kernel/uboot
Feb 12 16:54:40 <ynezz> mwalle: and thus force NXP to upstream
Feb 12 16:55:46 <ynezz> mwalle: I would keep it in this release 21.02, but switch to upstream sources for next, add current layerscape boards based on LSDK to the list of targets for removal
Feb 12 16:56:53 <ynezz> I don't like it since beginning, it's impossible to review this LSDK code bombs etc.
Feb 12 16:58:51 <ynezz> I assume we don't want to have layerscape/layerscape-lsdk targets :p
Feb 12 17:00:35 <ynezz> d'oh, scratch that, that's actually nonsense
Feb 12 17:01:05 <ynezz> actually I don't know how to handle this, probably need to sleep over it
Feb 12 17:25:25 <adrianschmutzler> so I can stop reviewing that layerscape device additions PR :-)
Feb 12 17:49:40 <mwalle> ynezz: hum? well I certainly don't have anything about removing the lsdk stuff (or at least for the kernel part) ;)
Feb 12 17:49:49 <mwalle> *against
Feb 12 17:50:30 <mwalle> the bootloader might make sense to have
Feb 12 17:51:02 <mwalle> ynezz: did you see my mail on the list?
Feb 12 18:19:05 <grift> dangole, i am expecting SELinux 3.2 next week might want to start thinking about coordinating a package update
Feb 12 18:21:41 <grift> should be some nice improvements with Linux 5.10
Feb 12 18:22:24 <dangole> grift: oh nice, another incoming 5.10 benefit
Feb 12 18:23:04 <dangole> grift: i already see everybody abandonning 21.02 release once it's out because mainline will be so much more fancy just days after
Feb 12 18:23:35 <grift> ues exciting
Feb 12 19:02:17 <grift> i just hope there wont be any significant issues with busybox selinux code, but i guess we'll see
Feb 12 19:04:25 <grift> i should send a beg e-mail to the original author of the busybox selinux patch Kaigai see if i can get him to modernize it
Feb 12 19:15:18 <eduardas> hello, any people here who bought the Mango DVK from 8devices and are playing around with it?
Feb 12 19:16:02 <eduardas> https://www.8devices.com/products/mango
Feb 12 20:34:06 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_tegra.html has been updated. (0% images and 98.2% packages reproducible in our current test framework.)
Feb 12 20:53:36 <pkgadd> Borromini: pong
Feb 12 20:55:14 <pkgadd> rmilecki: adding the btn class to luci-advanced-reboot was only done to fix the button rendering with the openwrt2020 luci theme, not because of any (unknown, at that time) screenreader heuristics in mind
Feb 12 21:51:10 <Borromini> pkgadd: hi. was about to ask something about the u-boot thing but forgot >_>. will get back to you when i remember
Feb 12 21:52:27 <pkgadd> Borromini: https://github.com/openwrt/openwrt/pull/3860/commits/d78078d370aa77ecca631cdd55c9191e0aabb2f9#diff-3b87ce92c70f9b47215c6c7e7e0afbbe39c95e62b815935e95220dd12b124ca4L14  you probably need to add your devices there as well
Feb 12 21:53:28 <pkgadd> it would surprise me if the gs1900-8hp v1/ v2 boards wouldn't need the smaller erase block size as well
Feb 12 21:56:10 <pkgadd> you can steal /etc/fw_env.config from the gs1900-10hp for testing, it probably fails to decode ubootenv as-is, and starts working if you overwrite /etc/fw_env.config with the correct gs1900-10hp file
Feb 12 21:56:29 <Borromini> pkgadd: yeah had some help from bmork there, will check, thank
Feb 12 21:56:30 <Borromini> * thanks
Feb 12 21:56:31 <Borromini> brb
Feb 12 22:02:28 <Borromini> guys, i'm using kermit to transfer an openwrt image over (tftp is wonky and keeps resetting)
Feb 12 22:02:51 <Borromini> instructions are for an image to be written, and use loadb $memory_address
Feb 12 22:03:21 <Borromini> can i do the same with an initramfs image or do i need another command for that? (remember i cannot tftboot since tft is wonky)
Feb 12 22:04:34 <Borromini> ok seems it does not matter, i can still use loadb
Feb 13 01:14:20 <mangix> Grommish: ping
**** ENDING LOGGING AT Sat Feb 13 03:02:54 2021