14:57:22 <Werner> #startmeeting Armbian Release planning 23.05
14:57:22 <ArmbianHelper> Meeting started Sat Apr  1 14:57:22 2023 UTC.  The chair is Werner. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:57:22 <ArmbianHelper> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:57:27 <Werner> #topic check-in
15:00:34 <rpardini> hey good afternoon
15:01:41 <DC-IRC> <adeepv> hi!
15:01:48 <joshaspinall> afternoon folks
15:02:54 <IgorPec> hi
15:04:12 <DC-IRC> <SteeMan> Hello
15:04:30 <IgorPec> # topic late topics
15:04:37 <Werner> #topic late topics
15:04:53 <IgorPec> Agenda: https://docs.lane-fu.com/jsxcggG9RqGdoTVNIXhfqA?edit
15:05:00 <IgorPec> Focus on making a list of supported boards and jump into bug fixing mode ASAP so release is possible by the end of May.
15:05:23 <IgorPec> - focus in quality - less supported count and better (open download pages and forum so we are all seeing the same)
15:05:28 <IgorPec> - focus in stabilizing build framework / CI (build fwrk team)
15:05:35 <IgorPec> - introduce “Retired family” - working configurations (mvebu family, which else?)
15:05:38 <Werner> If you want to have something noticeable you want to highlight out in the summary later feel free to use one of those "commands for everyone" explained here: https://wiki.debian.org/MeetBot
15:06:30 <IgorPec> #topic FYI
15:06:36 <Werner> #topic FYI
15:06:38 <IgorPec> Stuff to know beforehand - MC presents meeting relevant news and rules of engagement:
15:06:45 <IgorPec> note 1: IRC translator: If your English is poor, simply write in your native language. Start your sentence with -- at the beginning.
15:06:54 <IgorPec> rule 1: When you get a voice, please be quick and concise (1-2 min) and make it clear when you stop. (“No more, I’m done”)
15:07:06 <IgorPec> rule 2: If meeting is going out of desired agenda, MC will use “STOP STOP STOP”, wait to get attention and then proceed with the meeting agenda. Please stop chatting and listen.
15:07:15 <IgorPec> rule 3: Please highlight important information appropriately by putting a keyword in front of your message: #info #action #idea #help check tips below.
15:07:41 <IgorPec> #topic board maintainers
15:07:49 <Werner> #topic board maintainers
15:08:09 <IgorPec> MC is calling out on by forum section, starting with Allwinner. Open page: https://forum.armbian.com/forum/64-maintained-hardware/ and https://www.armbian.com/authors/ (sections maintainers)
15:08:37 <IgorPec> #action what to move down to unsupported, what to keep
15:09:07 <IgorPec> #topic Allwinner
15:09:17 <IgorPec> schwar3kat via email "orangepi-r1, orangepi-r1plus-lts, orangepizeroplus All stable images were good when I last tested."
15:09:18 <Werner> #topic board maintainers - Allwinner
15:09:27 <IgorPec> #info schwar3kat via email "orangepi-r1, orangepi-r1plus-lts, orangepizeroplus All stable images were good when I last tested."
15:09:45 <IgorPec> Nanopim1, Bananapim3, Bananapim64, Orangepizero2 (legacy doesn’t build), Bananapi, Orangepizeroplus, Tritium-h3, Tritium-h5, PINE A64-LTS, Nanopi Duo, Duo2 (doesn’t boot),  Orangepi R1, Banana Pi Pro, Nanopi Neo Plus2, Orangepipc are in theory supported
15:10:00 <IgorPec> do we have any Allwinner person around to tell us more about status?
15:10:33 <Werner> OPi02 legacy would be critical due to lack of mainline stuff iirc
15:10:57 <rpardini> No, but I'm generally worried about armhf -- due to zImage hacks/de-hacks/etc
15:11:15 <IgorPec> here we don't get to linux yet
15:11:32 <IgorPec> its something related to assembling boot loader which is propriatery in this case
15:11:39 <IgorPec> it worked at old system, fails at new
15:12:09 <IgorPec> #action fix opizero2
15:12:53 <IgorPec> and second thing - retire complete 32b allwinner?
15:12:57 <IgorPec> is that too soon?
15:13:07 <IgorPec> retire = fix sources
15:13:36 <rpardini> not sure I understand
15:13:45 <IgorPec> do not upgrade kernels anymore
15:14:00 <Werner> Boards like Opi0 are still widely used
15:14:12 <Werner> I think it would be fine not to put any more effort into edge but keep them on lts
15:14:40 <IgorPec> heisath said for mvebu to stop changing kernels
15:14:50 <IgorPec> and keep it at 6.1.y
15:15:19 <rpardini> I'd keep current = 6.1.y for the foreseeable future anyway for all families if possible. it's LTS.
15:15:32 <tonymac32> yes
15:15:35 <Werner> Hm I guess keeping on 6.1 is fine since it is supported until end of 2026
15:15:45 <rpardini> gotta have a grotesquely good reason to bump current up from 6.1.y on any family
15:16:11 <tonymac32> I can't imagine any reason to
15:16:13 <IgorPec> ok
15:16:35 <IgorPec> then this is clear, we do nothing in this regard, keeping CURRENT at 6.1 lts
15:16:40 <DC-IRC> <FakeShell> #info nanopim1 has working images for both ubuntu and debian bookworm without any major issues
15:16:49 <Werner> #agreed stop bumping armhf kernels further than 6.1.y
15:17:13 <rpardini> I'd say stop bumping _all_ 'current' kernels further than 6.1.y
15:17:22 <IgorPec> ok. other thing is - pretty much unknown state on half of organges and nanopis 32bit
15:17:41 <Werner> @rpardini until next LTS kernel?
15:17:47 <adeepv> rpardini: +1
15:17:53 <brentr> +1
15:17:59 <IgorPec> Orange pi One ... it probably works, but don't have maintainer
15:17:59 <tonymac32> +1
15:18:25 <Werner> It does, for server tasks at least since I have one running
15:18:52 <rpardini> #agreed  Stop bumping _all_ 'current' kernels further than 6.1.y (at least during 2023)
15:19:22 <IgorPec> ok
15:19:32 <brentr> What would be the benefit of bumping further than 6.1.y on these little systems?
15:19:45 <IgorPec> currently none
15:20:14 <Werner> Having new kernel features that are not directly linked to hw like optimizations in various code or whatever
15:20:18 <rpardini> #idea Stop calling any and all vendor kernel "current" - case in point: odroidxu4.
15:20:20 <rpardini> #idea Rename "legacy" kernels which are actually "vendor" kernels to BRANCH=vendor (case in point rk3588-legacy)
15:20:23 <Werner> I guess close do nobody needs those
15:20:40 <IgorPec> #idea changing terminology of “Maintained Hardware” vs “Unmaintained (CSC/EOL/TVB) / Other” into “Armbian maintained” vs “Community maintained” or similar.
15:21:06 <tonymac32> rpardini agreed
15:21:22 <IgorPec> this makes it easier to solve the problem of Orangepi One, which probably works, but we don't know status
15:21:30 <IgorPec> so it will go below
15:21:35 <adeepv> rpardini with "vendor" kernels we need a more families
15:21:37 <Werner> Where it fits.  Legacy armhf kernel is no vendor kernel for example
15:21:48 <Werner> More like old-current ^^
15:22:08 <tonymac32> legacy armhf rk3288 is vendor kernel
15:22:12 <rpardini> to me "vendor" is any kernel that we can't rebase on top of mainline and get less than 1000 commit patches
15:22:23 <Werner> *armhf aw kernel
15:22:25 <Werner> Sorry for mixeup
15:22:42 <tonymac32> ;) I forgot the current focus family, apologies
15:22:49 <IgorPec> any other saga around Allwinner except we need to get more help to cleanup patch mess
15:22:51 <TRS-80> IgorPec: To clarify, you are proposing dropping the (CSC/EOL/TVB) setails and simplifying down to either "Armbian" or "Community" Maintained?
15:22:59 <TRS-80> s/setails/details.
15:22:59 <ArmbianHelper> TRS-80 meant to say: IgorPec: To clarify, you are proposing dropping the (CSC/EOL/TVB) details. and simplifying down to either "Armbian" or "Community" Maintained?
15:23:25 <IgorPec> TRS-80 Renaming complicated definition "Unmaintained (CSC/EOL/TVB) / Other" into "Community maintained"
15:23:52 <TRS-80> Simplification sounds good.
15:24:03 <rpardini> adeepv: I see. Amlogic will have 2 "vendor" kernels possibly (4.x and 5.4.y)
15:24:25 <IgorPec> and "Maintained Hardware" -> "Maintained with Armbiab help" or similar
15:24:30 <adeepv> rpardini for s4 family for example out vendor kernel different from khadas vendor kernel...
15:24:33 <Werner> agree. However "community maintained" still implies some sort of maintainership which might not be true. Therefore "status unknown" might be more realistic in some cases...
15:24:36 <adeepv> *our
15:24:54 <IgorPec> Werner yes, but that maintainership is outside our domain and control
15:25:05 <IgorPec> we don't know if its maintained or not, status unknown
15:25:12 <IgorPec> but can be fully ok or completly broken
15:25:17 <rpardini> adeepv: I see no problem in "vendor-jethub" BRANCH, which is only enabled for jethub boards.
15:25:26 <IgorPec> # topic Amlogic
15:25:32 <tonymac32> rpardini amlogic should have no vendor kernels for anything older than s4
15:25:36 <Werner> #topic board maintainers - amlogic
15:25:54 <adeepv> rpardini problem with deb-pkgs which builds for family and future updates
15:26:00 <rpardini> Okie so not much work from my side on amlogic the last few months, mostly reacting to Neil
15:26:38 <rpardini> current=6.1.y should be relatively stable
15:26:58 <rpardini> edge=6.2.y also decent, even more so sometimes
15:27:03 <IgorPec> and most board should be ok with minor issues
15:27:09 <adeepv> #agree with current=6.1
15:27:19 <tonymac32> why do we have a khadas kernel and an s4 kernel.  And what about anything living in the media kernel (I thought there was some khadas in there)
15:27:19 <rpardini> there's a bit of mess with u-boot
15:27:50 <IgorPec> s4 kernel ?
15:28:10 <rpardini> s4 is upcoming still ppl
15:28:24 <rpardini> we're future-planning ;-)
15:28:41 <tonymac32> ok.  give it it's own family if it's not on the mainline amlogic train
15:28:42 <adeepv> rpardini u-boot after 2022.04 has some bug with efi code which cause boot-loop with some amlogic boards
15:28:52 <rpardini> we gonna need some s4 kernel for VIM4/VIM1S.... and adeepv's gonna need some s4 kernel for his new stuff
15:29:14 <IgorPec> #info possible another legacy kernel to support VIM4
15:29:19 <adeepv> tonymac32 amlogic has 4.9 and 5.4 kernels. all chipset from 4.9 are working in mainline kernel (as I know)
15:29:22 <rpardini> adeepv: true, 22.04+ and low-RAM (<1gb?) boards have some snafu
15:29:30 <tonymac32> adeepv correct
15:29:43 <IgorPec> just some exotic features are problem
15:30:09 <adeepv> rpardini i disabled all efi stuff in board configs for new versions of u-boot
15:30:26 <rpardini> yeah the main contention point in meson64 is the clock-phase conundrum
15:30:42 <rpardini> I'd say for current=6.1.y we keep as is, but keep moving with mainline for edge/6.2+
15:31:06 <adeepv> tonymac32 But for the new s4 family each vendor will have its own fork of the amlogic 5.4 kernel
15:31:50 <rpardini> anyway I'd say we only plan for s4 for 23.08+ release
15:32:02 <IgorPec> we might cooperate with khadas and in that case their kernel gets in
15:32:06 <rpardini> 23.05 might have something, but not "regulated"
15:32:15 <adeepv> rpardini I looked at uboot 2019 code from amlogic, it turns out they use the same method I did for phase shifting: the phases are specified in dts
15:32:15 <tonymac32> #idea split meson64 into gx, g12, and s4 families
15:32:22 <rpardini> I'd for sure call it BRANCH=vendor-<something> and not "legacy"
15:32:32 <IgorPec> yes, it can be called whatever
15:33:03 <IgorPec> we just need to adjust scripting to follow the logic
15:33:08 <rpardini> tonymac32: that split does not cure any pain with the clock phase though, which is between different boards in SM1 family
15:33:55 <IgorPec> any other Amlogic realated
15:33:58 <tonymac32> yes but we're getting a lot of special cases on more recent boards, while older boards are just along for the ride and nearly maintenance free
15:34:18 <rpardini> oh Neil added the CM4 Amlogic module
15:34:35 <rpardini> just commemorating, no action needed.
15:34:54 <IgorPec> action = at least maintainer that would boot it up
15:35:11 <rpardini> yeah, action = get samples from vendor and assign full maintainer
15:35:23 <rpardini> Neil did literally all himself, uboot, kernel, and Armbian stuff
15:35:24 <IgorPec> this is in motion. waiting for reply
15:36:01 <IgorPec> so in case someone listening and have a desire for BPI CM4 with a mother board ... PM
15:36:13 * rpardini raises hand "PM"
15:36:34 <IgorPec> in case nothing other in the land of Meson ?
15:36:37 <IgorPec> #topic development Marvell
15:36:45 <Werner> #topic board maintainers - Marvell
15:37:19 <rpardini> Well, my 2c: I severely broke Marvell build with armbian-next. Should be fixed, with help from ManOfTheSea. Thanks for patience
15:37:20 <IgorPec> me and Manofthesee are trying to give life to Ebin v42 ... callled Ultra
15:37:41 <IgorPec> its broken without your breakage ;)
15:37:53 <IgorPec> anyway. here we also have 32bit
15:38:01 <rpardini> yeah -- it might still be broken, but patch-wise and such, not build system.
15:38:21 <IgorPec> where Heisath had an idea to formally retire a board
15:38:32 <IgorPec> as there is nothing going on hw wise
15:38:41 <IgorPec> no changes for months
15:39:06 <IgorPec> its an old machine, things works and they will only break down with upgrade.
15:40:00 <rpardini> yeah but we'll wanna bump the family kernel and end up frakking up the stable board, won't we?
15:40:00 <IgorPec> no other hardware in section #marvell
15:40:38 <IgorPec> whole family is covering two devices
15:40:54 <IgorPec> armada a380 in router and nas variant
15:41:00 <rpardini> well... yeah in this case some BIG COMMENTS in family file are enough
15:41:22 <IgorPec> only we can break this hw ... is the point
15:41:46 <rpardini> yeah. if we stick current to 6.1.y for the next 12 months we should have a year of peace there
15:42:06 <rpardini> if/when 6.1.y is "too old" we move it to legacy, sans-current, and be done with it
15:42:11 <IgorPec> the point is that nobody will be checking this anymore
15:42:35 <brentr> Can we agree, in general, not to bump kernels on unmaintained hardware?
15:42:38 <IgorPec> and in lets say 6 months someone will shop up crying "id doesn't" boot, fail after upgrade
15:42:54 <IgorPec> it has to be entire family. in this case its possible
15:43:07 <rpardini> well lets then downgrade it to whatever we call "maintained on best effort community basis"
15:43:08 <IgorPec> as both devices we want to retire
15:43:28 <rpardini> or EOS or whatever. Naming things == hell
15:43:36 <IgorPec> what i am talking about here is. Kernel = 6.1.20 ... goodbye
15:43:57 <IgorPec> frozen, kernels are not produced anymore. is this viable?
15:44:00 <rpardini> oh you mean KERNELBRANCH='tag:v6.1..20` ?
15:44:04 <IgorPec> yes
15:44:10 <rpardini> no problem for me
15:44:14 <rpardini> +1
15:45:02 <IgorPec> se we know what is the status ... build system can throw out some warning
15:45:04 <rpardini> eventual interested user/semi-developer can go, bump it manually, fix patches if needed and send PR if wants 6.1.329 in 12 years
15:45:12 <IgorPec> yes, something like that
15:45:19 <brentr> +1
15:45:39 <IgorPec> so we get off from responsibility to KNOW its status at any time
15:45:50 <IgorPec> #action froze mvebu 32 bit
15:45:59 <IgorPec> #action froze mvebu 32 bit
15:46:06 <IgorPec> #topic Rockchip
15:46:09 <Werner> #topic board maintainers - Rockchip
15:46:14 <IgorPec> Rockpi-s (i2s), Nanopi-r4s(network sometimes fails), Rock-5b (powering, mainline?), Rockpi 4a (not all models are covered), Rock64, Rockpi E(does not boot), Rock 3(?), Orangepi-r1, Renegade, RockPro64, Tinkerboard2(does not boot), Nanopineo3
15:46:15 <tonymac32> 32-bit rockchip
15:46:21 <tonymac32> or 64 bit
15:46:26 <IgorPec> 32b start
15:46:54 <Werner> Nanopi-r4s is unstable for me but since nobody else reports I guess its just my board
15:46:59 <rpardini> armhf rockchip is _also_ subject to my worry ref. zImage and such
15:47:32 <IgorPec> rapardini: but this will be fixed soon, right?
15:47:57 <rpardini> #iforgot in Amlogic, there's algo armhf meson, which is in "unknown" state.
15:48:11 <rpardini> so we merged a PR "to see how it goes"
15:48:19 <rpardini> it needs... _seeing_
15:48:21 <IgorPec> hzyitc keep it updated
15:48:37 <rpardini> I mean, I can't _see_ it myself cos I don't have armhf boards
15:48:59 <rpardini> tl-dr: every board that boots zImage or uImage needs testing, period.
15:49:17 <IgorPec> ok. like i said, lets focus to bugs hunting from today on
15:49:21 <tonymac32> it is only tinkerboard 1 and tv box for rockchip.  I believe I tested after we talked about the boot issue
15:49:29 <IgorPec> not from next month on
15:49:36 <rpardini> if broken, fix we shall, and fast, but still needs testing...
15:50:01 <IgorPec> yes, testing testing testing ... we need earlier due many changes in build assemly process
15:50:03 <rpardini> tonymac32: that was the 1st cycle of zImage problems, which I fixed with a hammer. @ hzyitc did further work
15:50:47 <rpardini> #idea send rpardini some armhf boards
15:51:06 <rpardini> not too many, mind you
15:51:21 <IgorPec> rpardini can send you one allwinner
15:51:29 <IgorPec> lets move on #rockchip
15:51:50 <rpardini> ok. 64bit but say 3399 only for now?
15:51:54 <IgorPec> Jock is keeping 32b in good shape i would say
15:52:04 <rpardini> Paolo rocks
15:52:19 <IgorPec> for 64bit ... speak up
15:52:37 <IgorPec> TRS-80 how is adventure with PBPRO going?
15:52:39 <rpardini> well there has been progress with rockchip64 patches cleanup
15:52:50 <rpardini> but still, we have _evil_ patches in there
15:52:50 <tonymac32> boards affected by switch of source configs to board configs need tested
15:53:29 <tonymac32> I need to retract a few that got into non-rockchip64 boards because I was tired and got into a rythm
15:53:53 <rpardini> I think at least 2 "overwriting" patches, helios64 and smth else, and also bad/terrible patching of pinebookpro
15:54:29 <tonymac32> I haven't gotten a replacement for my helios64 yet, so it is still production.  no testing until the replacement arrives
15:54:57 <rpardini> lets look at family file super quick
15:55:19 <IgorPec> anyone has radxa e25
15:55:24 <tonymac32> TB2 not booting is new info to me, but it is also a csc
15:55:33 <rpardini> rockchip64: current = 5.15.y  // edge = 6.1.y
15:55:42 <tonymac32> that needs bumped
15:55:44 <IgorPec> i saw that too, tb2 was working for me
15:55:50 <tonymac32> current should be 6.1.y
15:55:53 <rpardini> tb2 works indeed
15:56:02 <IgorPec> last time, but haven't tested after rpardini messed up the system ;)
15:56:10 <tonymac32> pffft
15:56:30 <rpardini> well I wouldn't bump before we decide on those evil patches
15:56:39 <rpardini> not saying that 5.15.y is in good state, no
15:57:05 <IgorPec> #action rockchip needs further patch cleaning
15:57:12 <rpardini> 3399 specially I think
15:57:25 <tonymac32> hmm, IIRC 5.15 has more issues than 6.1, we've been exclusively tuning on 6.1
15:57:37 <rpardini> also in 3399 territory: BRANCH=legacy is completely abandoned 4.x ?
15:57:46 <IgorPec> oh, yes
15:57:51 <IgorPec> that is in terrible state
15:57:54 <rpardini> tonymac32: that might very well be true. when I said tb2=works is on 6.1y
15:58:09 <tonymac32> same, I ahven't built a 5.15 in forever
15:58:16 <IgorPec> one solution would be to move to 5.10.y legacy
15:58:16 <TRS-80> IgorPec: Apologies I was summoned to breakfast.  PBP is working on recent images I tried, I can test more if needed, now that I have PBP onto eMMC.
15:58:47 <IgorPec> TRS-80: can you update instructions on what are best ways to get it working on PBP download pages?
15:59:14 <TRS-80> IgorPec: I can, but my recommentation would be 'install tow-boot to SPI' are you OK with that?
15:59:22 <IgorPec> yes, i am ok with it
15:59:27 <TRS-80> will do then
15:59:29 <IgorPec> whatever works
15:59:31 <Werner> #action TRS-80 adjusts setup instructions for pbp on download page
15:59:34 <rpardini> #idea lets have instructions for board on a Markdown heredoc _inside the board file_
15:59:49 <tonymac32> ew
16:00:05 <IgorPec> keeping this updated is ...
16:00:13 <IgorPec> ok
16:00:26 <IgorPec> so no volonteer for sorting out legacy 3399 ? :)
16:00:31 <IgorPec> if not, removing?
16:00:32 <tonymac32> rpardini not a bad idea  trs-80 tow-boot?  really?
16:00:35 <rpardini> TRS-80: "install towboot to SPI" seems to be the generally accepted community solution, does nit?
16:00:56 <TRS-80> rpardini: Yes, that's where I got the idea in fact.
16:01:06 <IgorPec> this is good enough solution for PBP as nobody doesn't want to do it better
16:01:26 * tonymac32 shrugs it's knock-off u-boot with some cheap chrome paint so why not
16:01:32 <TRS-80> In fact apparently you can even boot generic UEFI image this way on PBP(!).
16:01:44 <tonymac32> just like with u-boot
16:01:52 <rpardini> Exactly. And that thing could even move pbp to arm64 generic image (plus some acpi=off and grub dtb injection)
16:01:53 <TRS-80> tonymac32: They are trying to solve same problem we are just in a different way.
16:01:54 <IgorPec> alternativly - if we know which u-boot works, then that
16:02:07 <tonymac32> I can test it
16:02:25 <IgorPec> pbp is also one of those - lets patch it up and forget about
16:02:26 <tonymac32> tow-boot offeres 0 extra functionality of u-boot, just an interface
16:02:38 <rpardini> s/that thing/towboot, or some decent EFI capable bootloader in SPI/
16:02:38 <ArmbianHelper> rpardini meant to say: Exactly. And towboot, or some decent EFI capable bootloader in SPI could even move pbp to arm64 generic image (plus some acpi=off and grub dtb injection)
16:02:53 <tonymac32> but, if the vendor is blessing tow-boot, then it should be preferred and we then ignore bootloaders for the thing
16:02:57 <IgorPec> pbp is not worth the time. that's the problem
16:03:14 <IgorPec> i would rather see we enable Apple M1 and Snapdraggon
16:03:14 <TRS-80> The problem on PBP is not 'which u-boot' but rather they stopped putting anything on SPI.  And ex factory (Manjaro) image does not look as SD card.  So 'anything on SPI' I think should work.  I am willing to test.
16:03:16 <rpardini> yes and everyone I know how has it, has towboot in SPI.
16:03:37 <TRS-80> It's worth my time because it's the only modern laptop/netbook I own.  :)
16:03:51 <rpardini> it's a bit like Armbian's mainline uboot for Amlogic. I wish we had time/ppl to supply said towboot build, but we don't, so we go with the vendor
16:04:02 <IgorPec> well, there are different hw revisions of Pinebooks and quality issues
16:04:06 <IgorPec> which is impossible to fix
16:04:09 <tonymac32> yeah
16:04:22 <rpardini> well yeah, I'd say write that in the Markdown board docs
16:04:30 <rpardini> ;-)
16:04:33 <tonymac32> and again, towboot *is* u-boot.  They seem to avoid that fact as much as possible in marketting
16:04:43 <IgorPec> fixing dtb injection for Snapdraggon is better investment than 100+ fixing of PBP
16:04:54 <tonymac32> lol yeah
16:05:02 <rpardini> dtb injection for Snapdraggon == gimme
16:05:05 <TRS-80> So I can babysit on my own time, as I already been doing.  Which I am going to keep doing regardless.  Might as well try and bring what I learn to more people via Armbain.
16:05:18 <TRS-80> if you guys wil laccept the patches
16:05:41 <rpardini> TRS-80: definitely do. I'd start by removing stuff we have that breaks stuff, instead of adding more, though.
16:05:45 <IgorPec> TRS-80: we accept patches, but have to understand how much time was lost for this sh* and its still takin time
16:05:46 <tonymac32> the tow-boot thing is purely "download from and flash to" instructions, yes?
16:05:58 <IgorPec> ok, lets move on
16:06:19 <DC-IRC> <Jason123> well I had manjaro without anything flashed onto the spi and it booted micro sd card
16:06:39 <IgorPec> #info wet wish to sort out 3399 legacy  and bump it to 5.10.y
16:06:52 <TRS-80> @Jason123 Talk to me after please, I would like more info.
16:06:56 <IgorPec> if no more rockchip
16:06:57 <IgorPec> #topic others
16:07:05 <rpardini> Jason123: great, go into Manjaro source's, find the towboot build, port it to Armbian, test it, submit PR
16:07:06 <Werner> #topic board maintainers - others
16:07:09 <TRS-80> tonymac32: I will FLUP with you as well.
16:07:12 <TRS-80> (After)
16:07:27 <IgorPec> Odroid XU4
16:07:34 <IgorPec> works, its old
16:07:47 <IgorPec> anything else? except a bunch of RISCV
16:07:51 <rpardini> ok, xu4: rename "BRANCH=current" to BRANCH="vendor"
16:07:52 <DC-IRC> <Jason123> manjaro uses uboot though
16:08:04 <rpardini> otherwise it looks like xu4 has a mainline kernel
16:08:09 <tonymac32> right
16:08:27 <IgorPec> what about upgrade?
16:08:30 <rpardini> Jason123: yeah whatever it is. steal it and PR and we'll think about it
16:08:32 <IgorPec> it will fail
16:09:00 <IgorPec> until we don't have a mechanism for easy upgrade and switching, changing the name = +troubles, no gain
16:09:02 <rpardini> it shouldn't fail, just not-upgrade
16:09:15 <IgorPec> so, we better not touch
16:09:19 <TRS-80> I can test ODROID-XU4, I still have one in production.  I even have a spare in this case.
16:09:25 <IgorPec> as its die out hw
16:09:32 <IgorPec> xu4 works
16:09:43 <rpardini> yeah I just don't like the "current" there. I think its the only family where current is not really mainline-ish
16:09:44 <IgorPec> this is hw from 2015
16:10:07 <DC-IRC> <Jason123> is the issue with the pinebook pro with armbian on emmc not booting into micro sd card?
16:10:11 <IgorPec> i would agree on change once we would have automation behind
16:10:16 <DC-IRC> <Jason123> the odroid xu4 is not mainline?
16:10:17 <tonymac32> I have a stack of XUF/MC1's
16:10:34 <IgorPec> xu4 is mainline, just our kernel is not
16:10:41 <IgorPec> as its attached to hardkernel branch
16:10:45 <IgorPec> its close to
16:10:46 <TRS-80> @Jason123 I can talk to you re: PBP after meeting, but now we are on to other topics.
16:11:02 <DC-IRC> <Jason123> this is a meeting?
16:11:03 <tonymac32> right, we had some stability difficulties a couple years ago
16:11:15 <TRS-80> @Jason123 yes
16:11:19 <IgorPec> #action change branch when upgrade mechnism works
16:11:23 <rpardini> yeah, it's a vendor kernel. it's not "legacy" and it's not a mainline "current". it's a "vendor" kernel.
16:11:46 <DC-IRC> <Jason123> honestly did not know what I expected just thought this was a regular talk
16:11:48 <IgorPec> killing upgrade is not an option here
16:11:56 <IgorPec> rename = kill
16:12:09 <rpardini> I'd do this together with others, like rk3588, and yes we will have a kill upgrade, but we will in peace with our souls.
16:12:23 <IgorPec> i would do when this is automagical
16:12:47 <rpardini> oh, automagical as in, rpardini automagically coded it into the system? :-D
16:13:09 <IgorPec> as i agree with you that name is not appropriate, but this is old 32b kernel which we might perhaps rather retire
16:13:13 <IgorPec> then code automagic
16:13:21 <IgorPec> what about riscv stuff?
16:13:31 <IgorPec> which goes under "others"
16:13:35 <rpardini> exactly my point. if I was suggesting to rename "current" to "actual" I'd agree we need automagical
16:13:36 <tonymac32> make new kernel family available in the armbian-config somehow, users can switch or just never get new kernel updates if they don't choose
16:13:52 <rpardini> but no, I am suggesting DEMOTING a "current" to "vendor", so no automagic needed here IMHO
16:13:59 <IgorPec> armbian-config is in terrible state due to lack of maint :(
16:14:38 <rpardini> I have checked with psychologist, and I've orders to not touch armbian-config, armbian-install, or any dialog-driven bash stuff for the next 10 years.
16:14:49 <IgorPec> damn
16:14:56 <tonymac32> :D
16:14:58 <DC-IRC> <Jason123> could change rk3588 to "vendor"when mainline becomes usable
16:15:14 <tonymac32> todo for 2028
16:15:46 <IgorPec> #info riscv sparks little interest. leave as is
16:15:59 <IgorPec> rpi4 and uefi?
16:16:08 <IgorPec> uefi with dtb injection
16:16:13 <IgorPec> for 8cx
16:16:29 <IgorPec> what can be done here?
16:16:35 <rpardini> rpi: we had fixes for esp flag in rpi3b (tested), and missing DTB since 6.1.y (fixed)
16:17:15 <rpardini> rpi: current = 6.1.y / edge = 6.2.y, both foundation kernels (I'd also change those to "vendor" to say the truth).
16:17:17 <IgorPec> so rpi is fully functional? it would be nice to have - overlay support within armbian-config
16:17:46 <IgorPec> #action also rpi kernel naming adjustement proposed
16:17:47 <DC-IRC> <Jason123> pi3b is supported by mainline?
16:17:56 <rpardini> rpi4b overlays need bigger treatment, I'd say in a larger "ovelays in general" effort
16:18:13 <IgorPec> what is the prime issue here?
16:18:18 <rpardini> jason123: this is the Release meeting yes?
16:18:22 <IgorPec> in overlay handling
16:18:32 <rpardini> it's inconsistent all around
16:18:46 <rpardini> each family does its own thing, prefixes, fixups, Makefile patching
16:19:19 <IgorPec> understand. isn't overlay just adding a txt to config.txt or whatever that files is at rpi?
16:19:57 <DC-IRC> <Jason123> did not know this was a release meeting
16:19:59 <tonymac32> #idea  overlays stored in folder and copied to kernel sources for compilation instead of patched in.
16:20:01 <rpardini> yes with rpi overlays are prebuilt by foundation kernels and loaded magically together with dtb by rpi's bootloader
16:20:21 <Werner> Now you know :)
16:20:25 <tonymac32> yeah, and the txt file method doesn't work with extlinux, efi, etc
16:20:35 <IgorPec> as i understand we "just" need to inplement mechanism specifically for rpi?
16:20:55 <IgorPec> as no existing works
16:20:58 <rpardini> I refuse to do any work that is rpi-specific, though.
16:21:04 <IgorPec> ok
16:21:04 <rpardini> rather do 20x more work, but useful for all.
16:21:13 <IgorPec> i am just trying to understand
16:21:15 <TRS-80> <3 rpardini
16:21:29 <IgorPec> ok, what about Snapdraggon, apple'
16:21:34 <IgorPec> what we can do here
16:21:42 <tonymac32> separate overlay building from image building is an option, then have a package.  in the case of rpi we don't need to build them, but could pacakge them
16:22:09 <tonymac32> apple is a black hole, interesting but not valuable IMHO
16:22:11 <IgorPec> overlays are packed with the image on rpi AFAIK
16:22:37 <IgorPec> apple is ... well
16:22:41 <rpardini> I am extremely interested in both Snapdragon and Apple M1/M2. Send them to me and I will make them bend to the power of my `acpi=off` magic
16:23:03 <tonymac32> it's the hardware version of ReactOS
16:23:04 <IgorPec> #action get some apples and oranges to Richardo
16:23:25 <IgorPec> alright
16:23:31 <tonymac32> snapdragon is a good place to spend some time
16:23:49 * TRS-80 wanted to do #fruit but didn't want it recognized as a keyword
16:23:54 <rpardini> I've MSM8998 trauma, but yes, the new ones seem worth looking into
16:24:02 <IgorPec> ok, will try to get one and sent it RIchardo
16:24:05 <IgorPec> # topic Infrastructure
16:24:12 <Werner> #topic infrastructure
16:24:21 <IgorPec> CI after merging with Armbian Next is getting up at: https://github.com/armbian/os
16:24:29 <IgorPec> this is pretty much WIP
16:24:37 <IgorPec> just some informations whats going on
16:24:47 <IgorPec> this repo is
16:24:59 <rpardini> ok Infra wise, we've circa 1 month to deliver code, test it and produce a working RC
16:25:17 <IgorPec> i'll just sum up what works now
16:25:17 <rpardini> there's _much_ code to be written if we wanna have release that is consistent
16:25:33 <rpardini> a big part of it is repository management
16:25:34 <IgorPec> apt.armbian.com and nightly beta.armbian.com packages repository are updading daily
16:25:46 <IgorPec> this was off for about one month
16:25:51 <IgorPec> now its in action
16:26:04 <IgorPec> stable and nightly images are producable
16:26:09 <adeepv> I have a question about versioning: we should revert to semver-like version numbers for nightly kernel/os images
16:26:33 <IgorPec> 3rd party applications with Armbian repositories, Chromium is now inside our repo, synched daily
16:26:44 <rpardini> yeah but we'll probably need some more radical changes in repo organization (one-common-to-all, one-per-release) right
16:26:53 <adeepv> hash in the version number is cool, but leads to strange effects when trying to update)
16:27:11 <IgorPec> what problems are here?
16:27:31 <rpardini> adeepv: tl-dr: bump the REVISION ("VERSION" file) to get consistent updates, there's no other way around it.
16:27:37 <adeepv> The hash of the new version is not always larger than the hash of the old version
16:27:42 <IgorPec> aha, yes
16:27:48 <IgorPec> that's expected
16:28:02 <IgorPec> version has to bump
16:28:18 <TRS-80> That name though ('os'), is this permanent or temporary?  I thought we were trying to convince people it's actually a build system (which just so happen to publist the artifacts of said system for convenience)?
16:28:40 <rpardini> adeepv: the hashes are just that, hashes, they don't have any sorting properties. I tried to have kernels and uboots with (Makefile) version in front, but that does not always help.
16:28:41 <IgorPec> TRS-80: perhaps the name is not fully the best for this, yes
16:29:17 <TRS-80> IgorPec: If this is output of CI, or the CI itself maybe it call it 'CI' or 'artifacts' or whatever more appropriate.
16:29:18 <IgorPec> We are not joking about and also are producing an OS.
16:29:48 <IgorPec> #action switching the name of current OS repisotiry
16:29:53 <rpardini> I'd say "armbian/os" repo is essentially "the default userpatches"
16:30:03 <IgorPec> yes, it has that too
16:30:03 <rpardini> and soon the "targets.conf" repo
16:30:26 <IgorPec> repo management should perhaps be placed somewhere else
16:30:34 <adeepv> rpardini I'm talking specifically about nightly builds of packages and images, they should have an incrementing part with semver-like version
16:30:34 <rpardini> say armbian/os is what makes armbian.com images, using the Armbian.org build system ;-)
16:31:04 <TRS-80> So, build will remain as is?
16:31:15 <IgorPec> yes, build won't change
16:31:19 <rpardini> adeepv: oh, yes. for nightlies we need to bump the "VERSION" file in a consistent manner and that will also work.
16:31:35 <IgorPec> adeepv: 23.02.0-trunk-gfdgdfsg4345fgds-gfdg45334tg -> 23.02.0-666-gfdgdfsg4345fgds-gfdg45334tg
16:31:37 <IgorPec> ?
16:31:54 <TRS-80> So armbian/os is CI pipeline and produced images / artifacts?
16:32:08 <IgorPec> yes. but also contains some OS defaults
16:32:08 <adeepv> IgorPec: Yeah, it's like this
16:32:49 <adeepv> and for kernel/bsp/etc packages also
16:33:09 <TRS-80> IgorPec: OK, as it would need those to feed into 'build' to produce the images.  I think I begin to understand.
16:33:44 <rpardini> yeah its a bit "userpatches" + "what to build" + "how to build"
16:34:03 <TRS-80> Or maybe you mean like our cutomizations, too.  Deviations from vanilla Debian?
16:34:31 <IgorPec> customizations of armbian build system
16:34:42 <rpardini> anyway in my view, infra/CI/versioning/repository/matrix is the main focus of work
16:34:46 <rpardini> for the whole of April
16:34:52 <IgorPec> yes
16:35:15 <rpardini> I'll refrain from family/board/pkg work in favor of this by default
16:35:19 <IgorPec> #info help in CI is most welcome
16:35:33 <IgorPec> its more important than hw specific at this stage
16:35:54 <IgorPec> this is true Arbmian problem, while HW support is still pretty common
16:36:14 <IgorPec> ok
16:36:19 <IgorPec> lets wrap this up
16:36:23 <Werner> regarding infra. what's the current status of armbian paste?
16:36:36 <TRS-80> I like this new split.  Correct me if I am wrong but this means if someone wanted a more 'vanilla' Debian (not that we add much) but it should be easier to do so going forward just by submitting the appropriate arguments to the build script.  Amirite?
16:36:41 <IgorPec> Werner: it was fixed, but we need to try
16:36:47 <rpardini> #weforgot rk3566 / 3568 / 3588
16:36:52 <rpardini> #weforgot UEFI
16:37:09 <IgorPec> UEFI we didn't. i was asking before in #others
16:37:16 <Werner> Indeed
16:37:29 <rpardini> oh ok.
16:37:29 <IgorPec> #topic misc
16:37:33 <Werner> #topic misc
16:37:34 <IgorPec> what we forgot
16:37:48 <joshaspinall> couple of quick Q's from me if I may?
16:37:55 <rpardini> uefi: current = 6.1.y / edge = 6.2.y -- I'd say both in good state, arm64 has patches for Phytium D2000 which is working good.
16:37:55 <IgorPec> shoot
16:38:16 <rpardini> rk3588-legacy with amazingfate effort, kedge2 in media, etc.
16:38:20 <joshaspinall> the Pine A64-LTS is in the meeting notes, but not on the linked forum post; I assume as it missed the last release?
16:38:30 <joshaspinall> Also, to confirm that this also covers the SOPine module (same board, different package)?
16:38:48 <IgorPec> AFAIK those two are the same HW wise
16:39:01 <IgorPec> can boot same image
16:39:06 <Werner> What about discussion of board status? demote to csc, promote to support and so son
16:39:17 <joshaspinall> just for clarity I guess, same image different board package
16:39:27 <joshaspinall> If anyone has a SOPine carrier board, or the A64-LTS SBC board from previous maintainership, please get in touch!  Am currently running the Clusterboard.
16:39:36 <joshaspinall> And finally, apologies if I should have chipped in earlier with these, first meeting, thanks!!
16:39:49 <TRS-80> Welcome, joshaspinall.
16:40:02 <IgorPec> Joshua: no problem. If you have access to website - you are welcome to edit info
16:40:07 <IgorPec> if not PM
16:40:16 <rpardini> joshaspinall: what family are those boards...?
16:40:22 <IgorPec> allwinner
16:40:28 <joshaspinall> A64
16:40:29 <DC-IRC> <FakeShell> i don't know if anyone noticed my first message about allwinner but nanopi m1 is working fine with nightlies and basically all images
16:40:35 <Werner> a64 is sunxi64
16:40:55 <IgorPec> everyone: https://docs.lane-fu.com/m7y93QBHQ9G15QoasxDl0Q?both
16:41:23 <IgorPec> this is the list of supported ...
16:41:26 <joshaspinall> got to shoot for dinnertime, thanks all.  Will check my website access later
16:43:23 <IgorPec> Werner: demote and promote , perhaps editing this document
16:43:51 <IgorPec> its a snapshot of what is supported and have maintainers, which is not the same as forums
16:44:04 <Werner> Yeah, I'm on
16:44:42 <IgorPec> otherwise we can close down the meeting
16:44:55 <IgorPec> this list is going to be making there
16:44:59 <IgorPec> anything else?
16:45:06 <Werner> Yeah I guess so. Anyone wanna add something? Last chance
16:45:09 <TRS-80> Do you want me to add pinebookpro here now on HedgeDoc or submit patch later putting myself as Maintainer?
16:45:14 <TRS-80> or both?
16:45:32 * rpardini stops showing off his mad markdown skilllzzz
16:45:46 <DC-IRC> <FakeShell> x to remove? what if its working?
16:46:06 <IgorPec> Fakeshell: if you know its working is already "supported" kind of
16:46:28 <IgorPec> the case here is that if there are no active people behind, we don't really know
16:46:51 <IgorPec> there is around 50 boards in auto testing facilit
16:47:12 <Werner> #endmeeting