14:00:14 #startmeeting Jerboa release meeting 14:00:14 Meeting started Sat Apr 3 14:00:14 2021 UTC. The chair is Werner. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:14 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:00:20 #topic check-in 14:00:26 Hi everyone 14:00:37 hej 14:00:57 welcome to the release planning meeting for Armbian 21.05, please just say hi to check attendance 14:01:05 hi 14:01:10 Hello 14:01:14 hi 14:01:39 All have a coffee ready? Shall we wait a bit more, not many people here as of yet. 14:02:03 5 min can be officially late 14:02:19 * lanefu coffee equippred 14:02:34 * IgorPec will make one quick before all come together 14:02:54 --Nur zur Erinnerung: Der Übersetzer übersetzt so ziemlich jede Ausgangssprache ins Englische wenn -- voran gestellt wird. 14:03:01 Just as a reminder: the translator translates pretty much any source language into English if - is put in front. [de~>eng] 14:03:28 interesting that it looses one minus 14:03:32 yeah 14:03:37 ate it 14:05:22 I'll just ask already if there are any late topics you want to add to agenda: https://forum.armbian.com/topic/17216-armbian-v2105-jerboa-release-thread/?tab=comments#comment-121598 14:05:37 #topic late topics 14:07:07 late topic would be to decide for a date on business oriented meeting. to keep this one strictly technical 14:07:36 good idea 14:07:50 yeah great 14:08:05 late topic.. this is an easy one... add virtualization support for all arm64 boards.. (just kenrel config change) 14:08:08 there are things to discuss, but perhaps not putting into here. so just when and how 14:08:25 IgorPec: i think same model just pick another saturday 14:08:26 #action add virtualization support for all arm64 boards 14:08:54 #action pick a saturday for biz meeting 14:08:57 okay we waited 8 mins, so lets start. 14:09:13 Any FYI or skip to board families? 14:09:15 #topic FYI 14:09:20 #topic FYI 14:09:32 Igor, lanefu how is the desktop coming along? 14:09:54 I am not up to date how far we are with including it in the build system. 14:10:04 desktop is developed by Myy, so i can only pass second hand info 14:10:18 i havent been tracking Myy's stuff.. but it needs another deep-dive to unwind some stuff 14:10:32 there is on bug that needs to be resolved, but there is some refactoring invloved ... so a bit more work 14:10:37 is myy keeping status in Jira or anywhere? i saw a big dialog in irc a while back, but i lost it 14:10:51 Okay so desktop is open for 21.05. I'll check Jira 14:11:03 in short - AR-713 14:11:03 4AR-713 6[Bug] "Board specific desktop things are going into common desktop package" reported by 3Igor Pecovnik at 2021-04-03. Status: In Progress 14:11:22 this is the problem and it sgould be somehow be fixed by this weekend 14:11:37 so it should be done in 21.05 14:11:55 ahh okay.. yes i remember experiencing that early on.. I just added myself as a watcher to the ticket 14:12:05 great. I how does this affect other (non desktop) boards? 14:12:11 s/early on/earlier when working on pbp/ 14:12:11 lanefu meant to say: ahh okay.. yes i remember experiencing that earlier when working on pbp.. I just added myself as a watcher to the ticket 14:12:39 AR-596 is also related 14:12:39 4AR-596 6[Task] "Moving blobs and BSP to proper location" reported by 3Richard Neese at 2020-12-27. Status: To Do 14:13:01 when this bug is solved, we can do some cleanup and move blobs to designated place 14:13:20 documentation or at least how-to / example is planned 14:13:42 okay so for 21.05 we expect to be done with desktop and packaging changes? 14:13:45 Heisath: it's possible that there's overlap... historically there'd been a single BSP board deb file for customizations... so if its messed up enough a server imaeg build _could_ fail 14:14:06 heisath you mean with https://armbian.atlassian.net/browse/AR-671 14:14:06 4AR-671 6[Story] "Changing package namings" reported by 3Igor Pecovnik at 2021-03-12. Status: In Progress 14:14:28 those are not directly related, but both could be done, yeah 14:14:42 yeah I would count these as big changes for Armbian 21.05, something we can present. 14:15:12 Is this odroidC2 Ethernet issue a concern? https://forum.armbian.com/topic/17112-odroid-c2-no-eth0-with-latest-image/?do=findComment&comment=121848 14:15:23 i only hope we will have enought ime for testing, otherwise we postope 14:15:47 IgorPec: should a subtask be to actually define a test process? 14:16:06 lol liek this? https://armbian.atlassian.net/browse/AR-694 14:16:06 4AR-694 6[Story] "Create Jira-based checklist for Desktop Testing" reported by 3Lane Jennison at 2021-03-18. Status: To Do 14:16:18 yes we should develop what we should test 14:17:02 regarding desktop i don't have any other critical issues 14:17:12 K I've assigned 694 to me and put on high priority... feel free to add things to test in that list 14:17:19 i'm gonna try to turn that into a jira template thingy 14:17:44 great then we can go cycle through boards / teams 14:18:01 allwinner? 14:18:14 yes, lets do that 1st 14:18:15 suggestion / id... for high priority tickets and above.. we should assign due-dates tot hem 14:18:17 #topic development Allwinner 14:18:36 bugs on all winner: AR-712 14:18:36 4AR-712 6[Bug] "Broken framebuffer on A20" reported by 3Igor Pecovnik at 2021-04-03. Status: To Do 14:19:07 is this also for the normal bananapi? Or only pro? 14:19:21 AR-191 is fishy too but can't really reproduce 14:19:21 4AR-191 6[Bug] "SATA doesn't show up on Banana A20" reported by 3Igor Pecovnik at 2020-03-30. Status: Backlogged 14:20:04 and AR-706 14:20:04 4AR-706 6[Task] "Bump Allwinner u-boot to 2021.04" reported by 3Igor Pecovnik at 2021-03-28. Status: In Progress 14:20:38 Do we have enough Allwinner boards in testfarm to reliable test the uboot update? 14:21:09 that's hard to say, but we have quite some 14:21:27 I have 0, 1+ and PC free for testing 14:21:29 I have h2,h3,h5, h6 in farm 14:21:51 good, we can also uboot doesnt auto upgrade, so we can just tell people via Announcement to try the new images with upgraded uboot 14:22:05 s/we can also/also 14:22:05 Heisath meant to say: good, also uboot doesnt auto upgrade, so we can just tell people via Announcement to try the new images with upgraded uboot 14:22:44 i have 10-15 (don't know how to extract data from Netbox yet:) 14:23:04 #action put out some testing images with bumped u-boot for AW out 14:23:05 yeah, i would certainly vote for this upgrade 14:23:41 for other allwinner. dunno ... didn't do much. others? 14:24:12 I tried some newer ATF with H616 but had no success 14:24:25 Not supported yet anyways 14:24:37 h616 is still far. any other critical things on h6, h4, a64? 14:24:44 we solved pinebook display finally 14:24:53 nice 14:25:29 Amlogic next? 14:25:42 #topic development AML 14:25:49 AR-711 14:25:49 4AR-711 6[Bug] "Network troubles on Nanopi K2 / Odroids" reported by 3Igor Pecovnik at 2021-04-03. Status: To Do 14:26:08 i think this was resolved, but its back again 14:27:00 yeah its anoying... who has testers for C2? 14:27:21 i have one c2 and c4 in test rig 14:27:38 I have a C2 too 14:28:05 I will give it a try 14:28:37 we would need expand testing on more devices. my c2 doesn't have troubles 14:28:43 c4 does 14:28:56 k2+ has wrong network settings 14:30:01 #action expand network testing on AML/Odroid boards (AR-711) 14:30:01 4AR-711 6[Bug] "Network troubles on Nanopi K2 / Odroids" reported by 3Igor Pecovnik at 2021-04-03. Status: To Do 14:30:37 those are problems i see, desktop is unknown to me 14:30:43 is AML already on 2021 uboot? 14:30:44 3d and that stuff on 5.10.y 14:30:55 i think we moved to some RC ... 14:31:26 https://github.com/armbian/build/blob/master/config/sources/families/include/meson64_common.inc#L8 14:31:32 2021.01 14:31:40 so i would say action to move this up as well 14:31:43 can't be worse 14:31:51 yeah at least try on dev. 14:32:16 #action bump u-boot on AML 14:32:31 #action check status of 3D support on Amlogic platform 14:32:46 #action check status of 3D support on Amlogic platform 14:33:04 something else or move on to marvell? 14:33:10 should get us to marvell 14:33:14 #topic development Marvell 14:33:27 Aprayoga and Gauthier seem not to be here. 14:33:51 well there is little going on marvell i think 14:33:55 and Pali hates us, and is not interested in supporting ebin 14:34:05 No major issues on marvell from my side. Some Helios4 trouble with cesa popped up 14:34:06 https://forum.armbian.com/topic/8486-helios4-cryptographic-engines-and-security-accelerator-cesa-benchmarking/?tab=comments#comment-121856 14:34:21 and i think ZFS is also broken 14:34:24 Maybe move this topic to the helios4 club so the kobol guys check it out. 14:34:31 i'm hoping [TheBug] will chime in on that one since he's got a lot of CESA wisdom 14:34:35 but its due to userland librarires 14:34:35 good idea 14:34:56 #action check ZFS status 14:35:05 Dont know what Pali's problem is, but I'd suggest leaving him alone. Ebin is EOS anyway 14:35:31 true. in case someone decide to pick it up, we can support with ideas what to do 14:35:35 yeah I learned that lesson 14:35:46 otherwise no more ebin 14:35:48 I will once again try to get a more up to date uboot working, dont see much hope though 14:36:07 atleast Pali is pushing to mainline directly, so we benefit aswell 14:36:15 true 14:36:42 @IgorPec: Why do you thing ZFS is broken on marvell? 14:36:52 so ebin is already CSC... we can still leave it there right? 14:36:56 not just there, sorry 14:37:09 unrelated 14:37:32 yeas, leave ebin as is 14:37:57 something else or move on? little behind schedule ;) 14:38:02 move on 14:38:08 just move on, marvell is done 14:38:10 #topic development Rockchip 14:39:00 AR-593 14:39:00 4AR-593 6[Bug] "Rockpi S doesn't boot mainline kernel" reported by 3Igor Pecovnik at 2020-12-26. Status: To Do 14:39:18 yeah, here things are not moving anywhere 14:39:48 but i guess its doable since openwrt boots modern u-boot / kernel combo 14:40:13 helios64 does not seem to be stable but piter and kobol are working on that 14:40:49 yeah, i see some troubles. what about u-boot here? 14:41:37 re: u-boot.. long-term seems like we need to take a huge look at it? investigate extliux.conf style config etc. 14:41:57 extlinux support, absolutely 14:42:09 #action explore extlinux support 14:42:19 I'm trying v2021.01 and v2021.04 for rockchip 32 bit, no success yet (gcc issue above) 14:42:23 its for research. 14:43:18 32bit will be more and more problematic 14:43:23 For us nostalgics who still use legacy, we added support for all the display outs in NanoPC-T4: AR-651 14:43:23 4AR-651 6[Task] "NanoPC-T4 legacy: enable USB-C DisplayPort & eDP outs" reported by 3Juan at 2021-02-18. Status: In Progress 14:43:56 and AR-709 was resolved 14:43:56 4AR-709 6[Bug] "Tinkerboard AP crash on client connect" reported by 3Igor Pecovnik at 2021-03-29. Status: Done 14:43:56 Some testers are welcome, specially if some of you own a eDP display (unlikely) 14:44:05 #info display outs enabled for t4 14:44:41 for pinebookpro lanefu ? 14:44:50 any major "board" realted issues? 14:44:54 IgorPec: i've never tested it... i thikn i have an adapter now 14:45:28 re kernels.... are playing on sticking iwth 5.10 for current? 14:45:36 pbp seems fine. running 5.11 and nvme installed 14:45:38 s/playing/we planning/ 14:45:38 lanefu meant to say: re kernels.... are we planning on sticking iwth 5.10 for current? 14:45:38 yeah, any other idea? 14:45:53 edge will go with the flow ... so 14:45:53 nope.. happy to see us stablizing on a mainline LTS! 14:45:58 sure it could be worth to stick with LTS kernel for current with all boards 14:46:30 so to spin back a notch.. are we in a spot wher maybe allwinner-current can go straight to mainline? or do we still need all the megi patches 14:46:47 too complicated question 14:46:52 lol okay 14:47:01 maybe something to explore next release 14:47:06 yeah! 14:47:09 #action 14:47:10 I'd stick with it for now since it works well 14:47:31 ok, lets move on 14:47:37 #action explore option to switch from megis sources to mainline (AW) 14:47:39 #topic development others 14:47:49 Any remarks on other boards? 14:47:54 For info, I've been testing video HW acceleration in AW mainline, and we still need several patches if we want it to work fine and 14:48:53 odroid xu4 ? anyone have idea if 5.10.y could become next current (instead of 5.4.y) 14:49:16 IgorPec: thats exynos 5xxx ? 14:49:22 IgorPec: not quite yet IMHO 14:49:24 exynos something 14:49:27 Would that mean moving legacy to 5.4? 14:49:32 ok, then we do nothing here 14:49:37 i have 5.10.something (arch) on a exynos 5800 chromebook, works reaaaally well 14:49:40 5.4.y is odroid fork 14:49:43 i try to have 2 of htose running 1 iwth each kernel 14:49:59 the latest -dev kernel is finally good, but i wouldnt switch yet 14:50:02 buzz: you don't hav xu4 to explore this? 14:50:07 s/-dev/-edge 14:50:07 lanefu meant to say: the latest -edge kernel is finally good, but i wouldnt switch yet 14:50:07 no, sorry 14:50:19 5.4 is still not on par wit h4.19 in some feature, in spite of HK claiming they are dropping support for 4.19 14:50:22 IgorPec: i might get a HC1/2 soonish though 14:50:24 buZz: I can add more mcsolo's to a test farm if that helps you? 14:50:30 well action: to test if this is possible 14:50:50 I'd stay with legacy 4.19 for most boards. Diff between 4.19 and 5.4 is bigger than 5.4 and 5.10 14:50:53 afaik HC1/2/whatever the newer model is numbered at , are all XU4 hw? 14:51:02 #action check if bumping kernel to next LTS is possible for XU4 14:51:27 oh FYI if you didn't catch it, we had a kernel confi gthat was breaking docker on XU4.. i fixed that last week 14:51:29 and dropping support for T3/nanopi 3 14:51:55 there is nothing going on 14:52:44 lets move on 14:52:48 backlog? 14:52:59 buildsystem first 14:53:03 aight 14:53:08 #topic build system 14:53:15 in case anything wasnt covered in FYI at the beginning. 14:53:28 AR-671 14:53:28 4AR-671 6[Story] "Changing package namings" reported by 3Igor Pecovnik at 2021-03-12. Status: In Progress 14:53:43 #info dev branch renamed to edge 14:54:04 the-going is working on changing package names 14:54:45 what is the aim of that change? 14:55:17 renaming linux-image-current-meson64_21.05.0-trunk_arm64.deb to linux-image-5.10.19-meson64_21.02.0-trunk-7.0177_armhf.deb 14:55:37 Good health. 14:55:52 yeah I get that. But what does it accomplish? 14:56:15 it helps us follow proper versioning conventiosn for deb packages 14:56:33 changing from wrong to right 14:56:44 we do some irregular things that sometimes make it not graceful to upgrade, replace etc 14:56:56 ok 14:57:03 Just remember to add a "Provides" field to the Debian control file of the new packages 14:57:13 #protip 14:57:13 Providing the old package name 14:57:29 Wont contain current/edge then for boards which have the same kernel version in both right? 14:57:31 Just in case someone has a custom package depending on the old naming 14:57:43 correct heisath 14:57:48 The goal is to bring the package creation process as close to debian ubuntu as possible 14:58:40 i hope we will be able to push this inot 20.05 14:59:09 will it still be possible for armbian-config to distinguish between current and edge then? (in case same kernel is used) 14:59:19 1st part already is, renaming DEV into EDGE and patches are linked now https://github.com/armbian/build/tree/master/patch/kernel/archive 14:59:50 current and edge will become meta package - this is how i understand it 14:59:56 and legacy 15:00:24 yeah doesnt really matter, dont think we often have same kernel with different config between the versions. 15:00:34 exactly 15:00:55 it is good to keep easier track for kernels used and recreation of older version. 15:01:16 for build system is what we already discussed previously and its related more toward desktop AR-596 15:01:17 4AR-596 6[Task] "Moving blobs and BSP to proper location" reported by 3Richard Neese at 2020-12-27. Status: To Do 15:01:18 AR-175 how is that coming along? 15:01:18 4AR-175 6[Story] "Improve the recreation of "released" images" reported by 3Lane Jennison at 2020-02-22. Status: To Do 15:02:25 recreation of released images is not ready yet 15:02:53 not sure if we can count that for 20.05 15:02:57 ok we should keep that in mind if we plan to support 21.05 for a longer time (because desktop). If we do. 15:03:09 (btw it is 2021 already, igor) 15:03:15 :) 15:03:34 manual maintainace can be done for a few months, but that's not the goal 15:04:11 ok lets go to open issues / jira backlog 15:04:29 #topic jira backlog 15:05:26 AR-572 when the-going work is merged in 15:05:26 4AR-572 6[Task] "Improve kernel changing procedure" reported by 3Igor Pecovnik at 2020-12-10. Status: To Do 15:05:31 Anything you want to add here? I noticed there are a lot of 'need testing' PR and easy/'good first issues' issues on github. We might look into doing those ourselves if no one pops up. 15:07:26 call them "good 2nd issue" 15:07:55 here is difficult to discuss. we do what we can, but we can't close them all . never 15:08:19 IgorPec: at some point maybe we should just add a github bot, that autocloses aged out issues 15:08:25 most mature projects do this 15:08:31 or put out bounty for closing issue 15:08:36 yeah 15:08:55 Maybe add a flag for "not essential issues" that get closed automatically after some time? 15:09:03 at least poping things out, make them visible 15:09:30 the same goes for "(too) difficult issue" 15:09:54 both those ideas are good 15:10:05 "extensive research neeeded" 15:10:19 perhaps some more politically correct wording ... native speakers decided 15:10:27 And then put up bounty with auto list for both types. 15:10:39 yes, make an #action for this 15:10:44 it might help y bit 15:10:47 I see those issues dating back to 2017, with the good ol' partners that started the project, as pieces of museum 15:10:49 does "needs deep dive" translate, or is that too much slang 15:11:03 I like them there LOL 15:11:12 #action decide marking of difficult issues 15:11:14 I like that. "Not essential" and "Needs deep dive" 15:11:38 JMCC: i'm afraid to close the old ones and getting yelled at lol 15:12:14 Stuff like this is just strange: https://github.com/armbian/build/issues/2646 15:12:28 Who'd _want_ to do that? 15:13:11 I think that completes jira backlog & open issues. Go to #board support 15:13:27 #topic board support status 15:13:40 https://www.armbian.com/download/ 15:13:43 board support status - removing T3 and similar 15:13:46 Ebin is EOS, move to CSC or keep? 15:14:12 I'd say keep Ebin as CSC.. since literally the community is supporting itself 15:14:21 and solving problems 15:14:31 what about removing "EOS" label and have CSC everything that is not supported / WIP ? 15:14:37 #action move ebin to CSC, link to thread with Pali in description. 15:14:49 #action move ebin to CSC, link to thread with Pali in description. 15:14:54 yes. CSC and EOS are the same 15:15:03 ebin is already set to CSC :) 15:15:08 well 15:15:08 just adding confusion without any real value 15:15:13 https://www.armbian.com/download/?device_support=Support+ended+(EOS) 15:15:20 we build images for CSC hto, not EOS, right? 15:15:20 Is it though lane? 15:15:58 lane@billroyall:~/GIT/build/config/boards$ ls -l *e*bin* 15:16:00 -rw-r--r-- 1 lane megawheel 220 Mar 27 20:39 espressobin.csc 15:16:12 Ah so git and webpage differ 15:16:20 ok, synching /download and /config/boards 15:16:23 as action 15:16:41 are we O.K. with merging EOS into CSC ? 15:16:41 #action sync website download page and /config/boards 15:17:12 if we want to keep EOS and CSC do diff between we build images, and we dont, we should make sure it is documented. 15:17:27 s/CSC do/CSC to 15:17:27 Heisath meant to say: if we want to keep EOS and CSC to diff between we build images, and we dont, we should make sure it is documented. 15:17:59 It may not make a difference for us but maybe for users because on CSC somebody still may work on while on EOS probably nobody does 15:18:13 but we don't know for EOS 15:18:28 then lets keep both and move boards WIP->SUP->CSC->EOS 15:18:32 i thought EOS meant we just kept the config fiel in the repo, for those who want ot build on their own 15:18:45 yeah i think if anythig we should merge WIP and CSC 15:18:59 in term of support, EOS = CSC, none we deal with 15:19:05 officially 15:19:16 I think keeping some image for download for EOS makes sense. It can be the only way for some people to make their old board work 15:19:41 providing download or build option is something else 15:19:44 yeah we should not delete once working images for old boards 15:20:04 and we don't 15:20:12 *thumbs up* 15:20:15 just CSC support "we don't know" 15:20:25 if things works and how 15:20:42 CSC == ¯\_(ツ)_/¯ 15:20:44 EOS is the same. 15:20:49 we don't know 15:20:57 the diff is the we knew once ;) 15:21:09 but that doesn't help much in reality 15:21:28 EOS == ¯\_(ツ)_/¯ ┌∩┐(◣_◢)┌∩┐ 15:21:38 if we are unsure, let's leave it for next 15:21:44 not important issue 15:21:49 yeah need only to sync the state now 15:22:01 I think for the users it might make a difference. 15:22:10 ok, sync is the action here 15:22:22 Also for CSC boards, dont blame them if they ask support question in forum ;) 15:22:33 we can move on 15:22:40 Nobody blames, just marked those reports as invalid :) 15:22:59 Igor gets a bit overboard sometimes imho 15:23:00 #action don't yell at CSC questions 15:23:06 They should ask in the peer to peer subforum, not in the supported boards froum 15:23:10 #action don't yell at CSC questions 15:23:12 yeah 15:23:15 OK, then lets make this a bit more gently 15:23:29 Just move them to peer to peer or general chit chat 15:23:29 :P 15:23:30 not as an "invalid report" but something more plesent 15:23:52 Just leave CSC support request alone, move them to peer to peer. If somebody knows, he will respond. Otherwise not. 15:23:58 yeah... that needs to be friendlier... and our armbianmonitor -m message is still has a bit of a harsh tone 15:24:19 honestly. what if we have a "community support" label 15:24:25 action: make forum messages friendlier 15:24:40 Throw ideas here: https://forum.armbian.com/forum/39-armbian-project-administration/ 15:24:49 #action make forum messages friendlier 15:25:10 ok, lets move on 15:25:41 what's left? 15:25:47 #meeting officer 15:25:49 #arm64 15:25:55 #business meeting 15:25:55 infrastructure changes 15:26:05 yeah and that 15:26:06 #topic release officer 15:26:15 I remember when I was starting on my OPi+2e, some Spanish webpage told you to use Armbian, but stated "Be careful wehn you ask on their forum, or they will fry you with their geek arrogance" LOL 15:26:26 LOL 15:26:53 Werner: new forum topic created 15:27:00 https://forum.armbian.com/topic/17417-make-forum-messages-friendlier-2021-edition/ 15:27:09 marked as invalid...oh wait :P 15:27:16 JMCC that is hillarious 15:27:46 yeah and native english speakers are gettting senstive adn grandstanding that we're toixic 15:28:08 alright. lanefu: perhaps we can sum infrastructure changes quickly 15:28:08 It is things like this https://forum.armbian.com/topic/17148-random-rant/ that leads to that. Igor, no offense, but if somebody buys helios64 for lots of bucks, I understand they expect support from kobol guys. 15:28:29 #topic Infrastructure 15:29:04 AR-675 15:29:04 4AR-675 6[Story] "Armbian General Infrastructure Improvements (non-mirror)" reported by 3Lane Jennison at 2021-03-16. Status: In Progress 15:29:14 k FYI IMHO Mirrors are stable and working well.. still need to add health checks / validaiton 15:29:24 #topic infrastructure 15:29:39 pulling up ticket stand by 15:30:38 we added few new mirrors, some under our domain, some via fosshost 15:30:44 bwah can some one link me that ticket.. jira is being dumb 15:31:12 https://armbian.atlassian.net/browse/AR-675 15:31:12 4AR-675 6[Story] "Armbian General Infrastructure Improvements (non-mirror)" reported by 3Lane Jennison at 2021-03-16. Status: In Progress 15:31:26 THANKS! looking now 15:32:04 yeah i should prioritie github actions monitoring.. i feel like that's in a weird place 15:32:13 netbox.. Igor and I have been making good progress there 15:32:46 almost all our gear and DUT+s are in the system now 15:32:48 http-only repo i should probably prioritize as well... seems to be sensitive issue among some users who like to cache 15:33:31 devices for testing, network eq., servers, switches, power controllers, etc. and connections between them 15:33:40 oh btw the arbeitstier runner can be removed from the repo since it will go offline in a few days 15:34:09 #action remove arbeitstier runner from github 15:34:16 #action remove arbeitstier runner from github 15:34:37 do we need this runner as is? 15:34:54 nah we have more 15:34:59 mine is hardly ever getting used 15:35:03 was just a backup 15:35:07 main runner builds kernels in case things are changed 15:35:26 runner "build" 15:35:39 but it only runs on one machine. this is not good 15:35:56 IgorPec: okay let swork togther so that it can run on my box if needed 15:35:59 https://snipboard.io/ezJ9D5.jpg 15:36:09