ArmbianHelper changed the topic of #armbian to: armbian - Linux for ARM development boards | www.armbian.com | Github: github.com/armbian | Commits: #armbian-commits | Developer talk: #armbian-devel | Forum/Twitter feed: #armbian-rss | Logs: -> irc.armbian.com
MoeIcenowy has quit [Read error: Connection reset by peer]
_whitelogger has joined #armbian
<Armbian-Discord> <r​pardini> Hello!
<Armbian-Discord> <T​onymac32> hello
<[TheBug]> Hey rpardini!
rpardini has joined #armbian
<[TheBug]> Hey teknoid_!
<rpardini> Also hello here
<Armbian-Discord> <a​deepv> here)
<Armbian-Discord> <M​anoftheSea> Does it read people in discord?
<rpardini> it does
<[TheBug]> yep there is bridge
<Armbian-Discord> <M​anoftheSea> Change from May?
<[TheBug]> Wait a few more minutes for straglers then @IgorPec can kick things off :)
<IgorPec> changes are always huge or a lot bigger than we can handle them
<IgorPec> but that is not the only problem we have
<Armbian-Discord> <T​onymac32> yep, we're changing to all vendor kernels
<Armbian-Discord> <T​onymac32> the older the better
<Armbian-Discord> <M​anoftheSea> I mean the bridge didn't read me in May
<[TheBug]> BTW Thanks to everyone who has taken time out of their weekend to be here and help support Armbian. I just want you to know that we appriciate you all and you time and dedication to Armbian!
<IgorPec> we have to think over the whole release model principle
<IgorPec> if we want to proceede with the same level (well tested release, well prepared release) ... the
<IgorPec> then this means serious work
<rpardini> I've just rebased 3-4 weeks of master onto -next. It's mostly moving edge's to 5.19, some new vendor-kernel-based boards
<IgorPec> yes, we have a lot of happening, but just a few days in total to do something.
<rpardini> lotsa rootfs cache changes, otherwise more of the same stuff. some board-side scripts might need a lot of testing
<rpardini> but I've a feeling we could focus testing on 1 or 2 boards per-family and have a good general indication
<IgorPec> well, from developers perspective we have "good stability"
<Werner> #topic release preparation and discussion
ArmbianHelper changed the topic of #armbian to: release preparation and discussion (Meeting topic: Release meeting 22.08)
<teknoid_> my two boards I support are in productive use - for me its hard to do full image testing 4 times per year as they are built into enclosures
<IgorPec> board count is under better control since last year, but board count solo doesn't help much
<teknoid_> testing kernel is no problem, but full image is a big problem
<IgorPec> for testing kernels we do have automation
<Heisath> teknoid get more boards then. Testing in production is shit.
<Armbian-Discord> <T​onymac32> uboot often brings challenges and must be tested fresh
<IgorPec> but is not well maintained
<IgorPec> yep, u-boot
<IgorPec> idea is to move many many boards to most recent u-boot
<teknoid_> these boards are out of production for years ;-)
<rpardini> I haven't seen meson64 u-boot changes. I guess ya'll mean rockchip's u-boot?
<IgorPec> just beeing sure that this goes as expected is complex job
<rpardini> (mostly... of course)
<Armbian-Discord> <T​onymac32> just in general. Testing a new image by just the kernel misses everything
<IgorPec> meson is pretty data i think
<rpardini> oh indeed
<Armbian-Discord> <T​onymac32> I've been guilty of that and got burned
<IgorPec> but we have allwinner and rockchip which is old
<IgorPec> also it would be sane to move to EFI in order to use some standard tools
<Armbian-Discord> <a​deepv> rpardini i think we can just move meson64 uboot to 2022.07
<Armbian-Discord> <T​onymac32> allwinner needs bumped, I can voich for GX/GXL, but the newer stuff is...
<Armbian-Discord> <T​onymac32> vouch*
<rpardini> adeepv: indeed. I've that feeling as well
<Armbian-Discord> <T​onymac32> amlgoic. #morecoffee
<IgorPec> yes, just the question is when and how to test?
<IgorPec> project "Regular release" has to be well prepared and lead. Neither me or TheBug can pick this up in "by the way"
<rpardini> yeah. I suppose when developers _also_ have to test we get bogged down very quickly
<IgorPec> are 4 full stream releases too much perhaps?
<IgorPec> testings is getting organised better, we do have more voolonteers for this job
<teknoid_> my proposal is to align releases with debian / ubuntu release cycle
<Armbian-Discord> <M​anoftheSea> Moving to EFI means u-boot supporting EFI, right? Seems beyond armbian control
<Armbian-Discord> <T​onymac32> u-boot does support EFI
<IgorPec> but again, someone needs to lead them. Currently Bug is trying to cover that to some degree
<[TheBug]> Yes, we have been looking for someone to take on this task, in fact we are discussing trying to come up with enough money for a stipend to give to the 'Release Manager' and maybe even try to keep a single manager for more than one release if they are good with the job. If this is something any of you would have an interest in specifically, please reach out to me directly after the meeting!
<Werner> Regarding the 4 release question from Igor: IMHO yes. Kernel is kind a rolling anyways and two month until next freeze...barely anything can be done within that time window
<Armbian-Discord> <a​deepv> IgorPec Maybe two releases per year would be better?
<Heisath> Agree. I second 2 releases.
<IgorPec> we heard many ideas, like 2 big, 2 small
<IgorPec> small = like no kernel bump
<rpardini> I think we need one release that makes things really stable first... then we can move to 2/year
<IgorPec> staying on the same version, just patch bump
<[TheBug]> Yes I am not sure we really came up with a schedule for 'minor releases' or what that actually means, but maybe if we can define this we could make more 'minor' releases and less 'major' releases?
<IgorPec> really stable can only be achived with massively improved testings . to at least know what is wrong
<rpardini> in the end the release cadence should be dictated by our testing frequency / trustworthiness
<IgorPec> but currently testings is - down to developers mainly
<[TheBug]> BTW https://www.armbian.com/rc-testing/ is our first attempt at being able to track testing -- if you guys find that there could be improvements here, please communicate them to me so I can see if I can continue to improve this form / process
<ArmbianHelper> ^ RC Testing – Armbian
<[TheBug]> This is also important because it will submit all of these testing into a single Jira ticeket which all can view including release manager: https://armbian.atlassian.net/browse/AR-1271
<ArmbianHelper> AR-1271 [Task] "RC Testing for August 2022 Release" reported by TheLinuxBug at 2022-07-27. Status: To Do
<ArmbianHelper> ^ [AR-1271] - Jira
<IgorPec> also there are ideas to have two repositories
<rpardini> very interesting TheBug. Maybe worth it to do a on-board script that reports stuff like armbianmonitor and the answers to test questions
<IgorPec> one rolling community, basically current trunk
<IgorPec> move everything there and have pro grade branch with a lot more testings
<rpardini> IgorPec: makes sense. since we have 0 testing capacity, nightly-only always-dirty releases are all we can afford
<[TheBug]> (please note the ticket number will change every release in case you were planning to bookmark that)
<[TheBug]> rpardini: if you would be interested in helping design that and come up with an easy method for submission of the information I am fully on board with that idea
<IgorPec> basic testing capacity is this https://github.com/armbian/scripts/actions/runs/2544689819
<ArmbianHelper> ^ Smoke tests · armbian/scripts@8942200 · GitHub
<rpardini> TheBug: yes. Count me in. (goes together with my build-log uploader, firstrun-rewrite, and other initiatives)
<[TheBug]> rpardini: excelent. We will discuss this more in the near future then.
<IgorPec> but before developing this further, I think "release manager" is quite a serious role here
<[TheBug]> indeed.
<rpardini> yeah, I've never been release manager, and have no idea what it really entails
<IgorPec> it means followint the agenda and talking to people
<IgorPec> we do have agenda, perhaps its not the best, but it gets us where we want
<[TheBug]> Also if you guys don't feel like any of you would have time, but know someone who could fit the role looking for some part-time work that would take it serious, please send them our way. It doesn't have to be one of y ou take on this but we do need someone who has enough skillsets to work with everyone and help to make the release happen.
<rpardini> what material do we have? agenda?
<ArmbianHelper> ^ Model - Armbian Documentation
<ArmbianHelper> ^ Model - Armbian Documentation
<IgorPec> it might need changes and improvements
<rpardini> Ok but that is already a very good start
<[TheBug]> And if someone wants to take on the role I will work along with them for the first release and we can work to improve documentation/procedures as that goes. SO you don't have to be concerned about being all alone
<rpardini> My question was more on the technical side. For example, the RC branch should have `tag:xx` instead of `branch:xxx` right?
<IgorPec> yes, "just" we do not have people that would cover that. but we have a lot of people that would want "stability"
<IgorPec> currently we branched whole build system and build from there
<rpardini> also, I've this in the back of my head, we need some heads-up/buy-in/agreement about the release from `media`, `sunxi` ppl (mostly in Russia I guess). How to communicate with them?
<IgorPec> and those branches stayed there. Since sources were frozen before, in theory, its possible to remake the same image later on.
<rpardini> being able to "freeze" what fetch_from_repo pulls, based on what is the RC/release branch, is a pending feature on my (build system) side
<IgorPec> "well, maintainers has to participate in the release process or board goes out"
<[TheBug]> rpardini: there was some conversation on this last night in fact between Tony, Igor and I, I know also jock has some of these concerns. I would tell you guys this should be first item in governance, but I think we may need to work on this before that can be implemented. As such we may want to setup a quick call together to discuss how that can done and invite Oleg as well so we can find
<[TheBug]> some comprimise.
<IgorPec> this is a bit light as we also can't provide what we would like
<IgorPec> but for release process, this is not that critical. Release is "hey folks, lets stabilize this huge system best way possible"
<IgorPec> this is common work per se, but has to be coordinated
<Armbian-Discord> <c​lee> works for me
<rpardini> yeah. again, in the end, most of the pain points can/should be addressed by features in build system. except, of course, getting actual reproducible tests and results done by people who know what they're doing.
<IgorPec> to get maximum outcome
<IgorPec> build system adds its own problems here, but for releasing a distribution, its "just" a tool. which will break down too :)
<rpardini> yep. repo management for example is something 100% out of my reach
<IgorPec> well, this is a complex system and its difficult to get things under any control
<rpardini> also, testing a regular user doing `apt update & apt dist-upgrade` is a much more complicated beast than testing `burn image to SD and it works`
<IgorPec> apt update and upgrade is automatised, but on a clean system
<rpardini> that could also be something to me moved into `community` vs `pro` releases. community would not assure apt-distupgrade upgradeability
<rpardini> while pro might
<Armbian-Discord> <T​onymac32> $$
<IgorPec> in general. levels of testing should greatly be improved. i am trying and trying but not much interest from general public to hold up into CI automation
<IgorPec> yes, certain things will be moved under pro versions which are interested that thins are in better shape
<rpardini> yeah. I need a decent SD-mux like thingy to work that
<rpardini> other solutions won't reproduce user's experience like switching SD cards would
<IgorPec> or if we would have ability to find sponsors for releases?
<IgorPec> time lost is simply too big if you want to do it right
<rpardini> (eg: I've u-boot based A/B switching working for most bootscript-based boards... but that won't test uboot itself, only from kernel down)
<[TheBug]> rpardini: I think one thing we need to do somewhere is start to document tools which would improve the development process for our developers and maintainers somewhere and as Armbian can fund it possibly try and help provide those things?
<IgorPec> we can setup a proper lava test system, but we are talking about a serious operation
<IgorPec> so to recap. what we can do with what we have?
<Armbian-Discord> <a​deepv> rpardini I am also thinking about how to automate testing for uboot, but I have no good ideas yet
<IgorPec> what is easy is = build images, test them for corruption, run apt upgrade on 50+ boards
<IgorPec> but this does not label release as "stable" nor "tested"
<Armbian-Discord> <a​deepv> @IgorPec There is another thing: there are changes between releases that are not available by simply updating packages
<Armbian-Discord> <I​gorPec> yes, i understand that. (automated) images testing would be perfect.
<Armbian-Discord> <I​gorPec> now, we have more voolonteers that can help testing, but that represent us even more burden
<Armbian-Discord> <I​gorPec> as someone has to talk with them, encorage them
<Armbian-Discord> <I​gorPec> and we need to thank them
<Armbian-Discord> <r​pardini> yep. I can propose to do myself 1 or at most 2 rounds of testing on N2, HC4, VIM3L
<Armbian-Discord> <r​pardini> but, only from new-image-to-SD-and-see-if-it-works-for-me style
<Armbian-Discord> <r​pardini> and that's only because I really wanna release 5.19 edge on meson64 😉
<[TheBug]> rpardini: as you have Vim3L maybe you can ping NicoD at some point this coming week and just chat with him on it, I know he is also maintaining and has been trying to help overcome some issues -- Tonymac32 and Tenkawa helped him a bit on previous weeks voice chat, but maybe you could check with him if there are any fixes you could help him get put in place for that board.
<Armbian-Discord> <T​onymac32> is 5.19 an LTS or not? It does bring in a lot of good stuff
<Armbian-Discord> <I​gorPec> 5.19.y as CURRENT?
<Armbian-Discord> <r​pardini> great question, dunno about LTS status of 5.19, or if 5.20 is coming or not
<Armbian-Discord> <a​deepv> 5.15 is LTS
<Armbian-Discord> <I​gorPec> probably 6.y is next
<Armbian-Discord> <r​pardini> I guess 5.18 is too early for current
<Armbian-Discord> <T​onymac32> I was part of the "Current should always be LTS" crowd
<rpardini> sorry, meant 5.19
<Armbian-Discord> <I​gorPec> hmm, but with meson64 we have 5.10 for CURRENT
<Armbian-Discord> <I​gorPec> which is not very goo
<Armbian-Discord> <r​pardini> yeah, but 5.19 edge is super-new
<Armbian-Discord> <T​onymac32> yeah that got missed, I think 5.15 was causing troubles with the newer boards
<Armbian-Discord> <M​anoftheSea> 5.20 is 6.0
<Armbian-Discord> <r​pardini> 5.15 meson64 is completely borked
<Armbian-Discord> <r​pardini> 5.11 - 5.18 meson64 is completely borked btw
<Armbian-Discord> <I​gorPec> than its better to move meson64-CURRENT directly to 5.19.y ?
<Armbian-Discord> <I​gorPec> right now
<teknoid_> I'll give 5.19 a try on my C2 next week
<Armbian-Discord> <r​pardini> could be, but is a risky move. 5.10's a mess organization wise, but is is stable-ish
<Armbian-Discord> <a​deepv> @rpardini what is broken in 5.18 but not in 5.19? 🙂
<Armbian-Discord> <M​anoftheSea> I'll try 5.19 on mvebu64
<Armbian-Discord> <r​pardini> oh wow adeepv literally everything we didn't fix in that PR 😉
<Armbian-Discord> <I​gorPec> 5.10.y has that LDS problem with headers
<Armbian-Discord> <I​gorPec> so DKMS fails
<Armbian-Discord> <a​deepv> @rpardini Yes, it turns out that all my devices works better on 5.16+ than on 5.10 anyway
<Armbian-Discord> <M​anoftheSea> Though ... Ebin works in Debian, too, and there are no armbian patches. I could see armbian dropping support
<Armbian-Discord> <r​pardini> adeepv: you're right. Khadas, Radxa, Jethub might work ok on 5.11-5.18 despite the shutdown revert caused by odroid. But odroid's themselves are severely borked
<IgorPec> teknoid_ i have around 40-50 boards in the rack just for testing purpose. But interface or options of using it are rather limited. If we could improve / expand that, it would be much easier
<Armbian-Discord> <T​onymac32> ahh, hardkernel troubles
<Armbian-Discord> <T​onymac32> mark unsupported, move on
<Armbian-Discord> <T​onymac32> 😉
<Armbian-Discord> <r​pardini> hardkernel troubles not only fuck themselves, but also other meson64's
<IgorPec> the idea behind is that anyone from the team could use those devices anytime
<Armbian-Discord> <r​pardini> yeah... I've similar ideas... so a power control, plus UART, plus SD-mux would make every board remotely useful for testing
<Armbian-Discord> <r​pardini> but is a lot of HW to enable testing
<Armbian-Discord> <I​gorPec> i have power control, some have uarts, sd mux never got to life but 😉
<Heisath> rpardini we have worked on all that.
<Armbian-Discord> <r​pardini> yeah, raise "wanted: SD-mux like solution for enabling testing" (dunno syntax for meeting script?)
<Heisath> But sd card muxing is just really hard.
<Armbian-Discord> <I​gorPec> at least we tried
<Werner> #help wanted: SD-mux like solution for enabling testing
<ArmbianHelper> ^ GitHub - armbian/mpads: Multiple power and data switch
<Armbian-Discord> <T​onymac32> lanefu found that single-SD card setup from Tizen via hackaday
<Heisath> I still have the boards around, if anybody wants to pick this up, I'd gladly share my experiences.
<Armbian-Discord> <T​onymac32> we just need the epic usb hub of doom
<Armbian-Discord> <I​gorPec> but regardless of this functionality - one step further would already be valuable
<Armbian-Discord> <I​gorPec> like to give access to anyone to any of those boards
<Armbian-Discord> <I​gorPec> so anyone can run manual update or whole CI
<Armbian-Discord> <I​gorPec> or just plug everything to the main CI and test every time
<teknoid_> at least for me some SD extenders like this : https://www.adafruit.com/product/3688
<Armbian-Discord> <a​deepv> @IgorPec Without the ability to automatically restore the system from scratch it is useless
<ArmbianHelper> ^ Micro SD Card Extender - 68cm (26 inch) long flex cable : ID 3688 : $6.95 : Adafruit Industries, Unique & fun DIY electronics and kits
<Armbian-Discord> <r​pardini> very nice Heisath I'm very much interested
<Armbian-Discord> <T​onymac32> I have the built boards from Olimex and could taka look at some of it, it seems clear enough we need to have something on each device, star pattern is going to be a mess
<Armbian-Discord> <I​gorPec> adeepv: well, we could boot from NFS and have rootfs there
<Armbian-Discord> <T​onymac32> SD is not a robust long distance signal path 🙂
<[TheBug]> Igor: should tell your son you will double owance if he will sit in the room swapping sdcard for us for some weekends ;) (joking)
<Armbian-Discord> <I​gorPec> so, its "just" boot loader that has to be tested manually
<[TheBug]> allowance*
<Armbian-Discord> <r​pardini> long flex cable for SD sounds like data loss waiting to happen, although I want it ♥️
<Armbian-Discord> <I​gorPec> Yeah, i will swap SD cards at will 😉
<Armbian-Discord> <a​deepv> @IgorPec I'm slowly deleting uboot, your move?)
<Armbian-Discord> <I​gorPec> heeh
<Armbian-Discord> <T​onymac32> yeah, do they have those in 10 CM or so?
<Heisath> Even uboot does not need sd card swapping. Just override out of running linux. It only needs manual attention, if next boot fails :)
<vpeter> USB-SD-Mux from Linux Automation is really great. Expensive but great :)
<Armbian-Discord> <I​gorPec> yes, i can buy one, but 40 is a bit too much 😉
<Armbian-Discord> <T​onymac32> ah GmbH means money
<Armbian-Discord> <T​onymac32> 😉
<Armbian-Discord> <T​onymac32> this looks like the Tizen device rotated 45 degrees for style points
<vpeter> I did some similar device myself. Not computer controlled but still great if you don't need swapping sd cards.
<Armbian-Discord> <M​anoftheSea> It's 111 euro. I dunno what that means in freedom bucks, but it's more than my next sbc fix
<Heisath> but 111 per piece is only a few thousand total. Given how much you waste on support it might be worth it.
<Heisath> dollar euro is pretty much 1:1 right now.
<Armbian-Discord> <T​onymac32> $140 unless the war continues, then maybe $50
<Armbian-Discord> <r​pardini> Heisath: true. It's what I am doing currently, A/B switching kernel/rootfs, but keep uboot in general. When going to test u-boot, have remote-hands at the ready for when it fails. Everything else is power control + UART
<Armbian-Discord> <r​pardini> Also USB-SD-Mux from Linux Automation is USB2-only, so very slow
<Armbian-Discord> <I​gorPec> if / where cash is behind, its not a problem to buy this
<Armbian-Discord> <T​onymac32> https://wiki.tizen.org/SDWire
<ArmbianHelper> ^ SDWire - Tizen Wiki
<Armbian-Discord> <I​gorPec> but for community targets, if community do the testings, we are good
<Armbian-Discord> <a​deepv> @rpardini amlogic can usb-flash-boot when no data on emmc/sdcard
<Heisath> pardini good luck getting sd card mux with usb3 :D
<Armbian-Discord> <T​onymac32> USB2 will be the best you get unless you design something yourself
<Armbian-Discord> <r​pardini> adeepv: true. also crazy HDMI i2c boot-chooser... (by Neil)
<Armbian-Discord> <T​onymac32> I need to build that
<Armbian-Discord> <T​onymac32> and this
<Armbian-Discord> <I​gorPec> well, this tool on a side. we need a test system
<Armbian-Discord> <I​gorPec> something better then current POC level
<Armbian-Discord> <r​pardini> yeah. getting test rig setup will be the key to stability -- I propose this needs its own comittee / initiative
<Armbian-Discord> <T​onymac32> agreed
<Armbian-Discord> <r​pardini> eg, be vendor-driven and sponsored
<Armbian-Discord> <I​gorPec> this is now under DevOps i think
<Armbian-Discord> <I​gorPec> buy agree, this should be a separate entity
<[TheBug]> actually if accessible to our partners that may be a very good addition to the 'Armbian Professional' as a good valued for our Partners (vendors)
<Armbian-Discord> <r​pardini> it's too important to be buried under DevOps I think
<Armbian-Discord> <I​gorPec> i tried to put it together, but with volunteers driving voolonteers ... its difficult
<Armbian-Discord> <r​pardini> yep, that actually adds a lot of value from vendor's perspective
<Armbian-Discord> <r​pardini> "actually tested releases on actual hardware"
<Armbian-Discord> <I​gorPec> ok, then we will setup this commeetee, but who to put in? 🙂
<teknoid_> I need to leave, bye... happy releasing ;-)
<Armbian-Discord> <I​gorPec> i can name people for R&D and devops easily, but not here
<[TheBug]> teknoid_: thanks for joining us
<Armbian-Discord> <r​pardini> lol, do all commitee's have all the same people (us) in them? hehe
<Armbian-Discord> <I​gorPec> tehnoid: thanks !
<[TheBug]> before you all leave
<[TheBug]> let me say a quick thing on that
<Armbian-Discord> <I​gorPec> we can divide people to devops and devs pretty well
<[TheBug]> hopefully the initially created committees and governance will start to be finalize over the next weeks
<Armbian-Discord> <I​gorPec> or developers / support
<[TheBug]> this will have us do a new presentation as it is finalized and we will start to do a call to action for committee members to join our committees
<[TheBug]> rpardini: to answer your question, at start it may be like that but my hope is if people get involved that won't be the case over time
<Armbian-Discord> <I​gorPec> but the key is what committee will be deciding upon, not who will be in or not
<Armbian-Discord> <I​gorPec> now all questions and decisions are too mixed
<[TheBug]> If any of you have time to be on the one of the committees and has an interest, please feel free to reach out to me directly on irc/forum/discord and let me know so I can contact you as things are organized.
<Armbian-Discord> <r​pardini> seems like we need moar ppl -- but again, adding more people needs more people, ad infinitum
<Armbian-Discord> <M​anoftheSea> I, too, need to go. Mvebu64 (ebin) has no new problems, I'll test on 5.19 and provide feedback to move stable to it.
<Armbian-Discord> <I​gorPec> and more complicated managemetn
<Armbian-Discord> <a​deepv> You can try to include me to DevOps. Maybe in half a year I'll have plenty of time 🙂
<[TheBug]> rpardini impressively we continue to add a few volunteers a week, even though it doesn't seem that way -- the bigger issue is attracting those who have more of the higher level developer skillsets and the time to volunteer. Please do invite any developers you know to get involved!
<Armbian-Discord> <I​gorPec> but more complicated management / introducing sections / comeetees should help.
<Armbian-Discord> <r​pardini> yeah. from my side, I still wanna do a few "lecture" style videos
<Armbian-Discord> <r​pardini> to help onboard ppl
<[TheBug]> rpardini: then the best people to talk with are indeed Werner and NicoD as they have been running the video projects for Armbian
<Armbian-Discord> <I​gorPec> i think we miss also the part - after they board
<Armbian-Discord> <r​pardini> "lets build Armbian 101" "lets add a board which is already mainlined 101"
<[TheBug]> rpardini: I would encourage you to seriously reach out to them as I know they will be interested in helping you get that done
<Armbian-Discord> <I​gorPec> how to answer "i want to help armbian" question and how to keep them motivated
<Werner> There are a couple of ideas already but nothing really pushed forward
<Armbian-Discord> <r​pardini> Yeah. I defninitely need to unload armbian-next, pff, what a fiasco
<Armbian-Discord> <r​pardini> really gotta cut the crap, remove what's not working, and release it
<Armbian-Discord> <I​gorPec> we can do quick overview on the situation if you got time?
<Armbian-Discord> <r​pardini> yeah I've still to consolidate a lot... but in the end that branch is 5-6 things in one or more
<Armbian-Discord> <I​gorPec> regarding releases - do we have some solid conclusions?
<Werner> Discussion armbian-next is probably out of scope of this meeting though since we overshot time heavily already
<[TheBug]> IgorPec: I think actually the better idea is a sub-committee under R&D -- that may be what we want there in the short time for that extra committee you were mentioning -- as the R&D committee is put together we can discuss producing that sub-comitte as one of it's first meetings if that is of interest.
<Armbian-Discord> <r​pardini> I'd say we should move in direction of a release freeze / bugs only
<Armbian-Discord> <I​gorPec> make a small and safe release
<Armbian-Discord> <r​pardini> well if 5.20 is 6.x... 5.19's release might be very important for many years
<Armbian-Discord> <I​gorPec> releases of images are by default made from apt.armbian.com
<Armbian-Discord> <I​gorPec> what its there, gets into the image
<Armbian-Discord> <I​gorPec> so, i can "cherrypick", add to repository and run "make"
<Armbian-Discord> <I​gorPec> just what to cherry pick, i have to get from you and maintainers
<Armbian-Discord> <I​gorPec> this means i can only upgrade a few kernels, no u-boot, or some u-boot
<Armbian-Discord> <r​pardini> wait, I'm a bit confused
<Armbian-Discord> <r​pardini> "normal" release cycle would be to freeze master (bug fixes only) for a while, then create RC branch, unfreeze master... fix RC branch... then do a big build of all uboots/bsps/kernels, publish to repo, then build images
<Armbian-Discord> <r​pardini> or am I wrong?
<Armbian-Discord> <r​pardini> dunno how that coordinates with BETA=yes etc
<Armbian-Discord> <I​gorPec> yes
<Armbian-Discord> <I​gorPec> beta=yes means it will be published to beta repositoryy
<Armbian-Discord> <r​pardini> but can images be build from beta repo?
<Armbian-Discord> <I​gorPec> beta=no main repo
<Armbian-Discord> <I​gorPec> also
<Armbian-Discord> <r​pardini> because to me it seems that once we publish to non-beta repo, apt upgrade users will be affected, images having worked or not
<Armbian-Discord> <r​pardini> so it would be ideal to hold off on main-repo updates until we have confirmation that images build & work
<Armbian-Discord> <I​gorPec> i did this last time. I build everything, pushed to beta and build stable images from beta repo
<Armbian-Discord> <I​gorPec> then once happy, updated main repio
<Armbian-Discord> <a​deepv> @rpardini freezing the code just allows you to first make a beta, test and then build the main
<ArmbianHelper> ^ [image/png] (29.9KiB)
<Armbian-Discord> <r​pardini> well I understand that driving that process is human-intensive
<Armbian-Discord> <I​gorPec> yes, this is why we have this meeting 🙂
<Armbian-Discord> <r​pardini> also... it ends up being your work IgorPec always, even if we had a Release Manager person
<Armbian-Discord> <r​pardini> or am I misunderstanding?
<Armbian-Discord> <I​gorPec> mainly it was my work, but i did get occasional help
<Armbian-Discord> <r​pardini> eg, suppose that builders might need manual cleaning, etc
<Armbian-Discord> <I​gorPec> when i was not leading, i was helping
<Armbian-Discord> <I​gorPec> many things has been automatized one the way, so most problematic is still testing and leading this whole process
<Armbian-Discord> <I​gorPec> each release starts at least 1 month priour executing those buttons
<Armbian-Discord> <r​pardini> yeah. I'm afraid if I try to help there, I'll end up wanting to code-change everything and not help at all 😳
<Armbian-Discord> <I​gorPec> haha
<Armbian-Discord> <I​gorPec> code change on the way is addictive
<Armbian-Discord> <r​pardini> Yeah. I dunno what to propose for this release (22.08?)
<[TheBug]> circling back, what is the short term decision here -- will we make a 'major' or 'minor' release at the end of month or will we hold off till next release period?
<Armbian-Discord> <r​pardini> we need a release manager (not Igor, not TheBug) before anything can happen right?
<Armbian-Discord> <I​gorPec> that would be ideal, yes
<Armbian-Discord> <r​pardini> also we need some kind of organized human testing too right?
<Armbian-Discord> <r​pardini> we could 30-day defer the release until we have atleast these 2 things
<[TheBug]> well good thing about that is I have been collecting contact information for all of the maintainers
<[TheBug]> so when we know we need testing we can reach out in a productive way and ask them to start the testing
<[TheBug]> and ask them to fill the forms
<Armbian-Discord> <I​gorPec> we can do a small release for 22.08
<Armbian-Discord> <I​gorPec> but it will only be tested via auto system
<Armbian-Discord> <I​gorPec> without u-boot changes from 22.05 it can't do much damages
<Armbian-Discord> <I​gorPec> image corruption test is automtic
<Armbian-Discord> <I​gorPec> that wasn't in 22.05
<Armbian-Discord> <T​heBug> @rpardini @Tonymac32 etc -- thoughts on minor release for 22.08 or questions? Do you disagree?
<Armbian-Discord> <r​pardini> image corruption test, is that the debsums MD5 check Igor?
<Armbian-Discord> <r​pardini> I'm not clear how a "minor release" is less work for Igor than a full release?
<Armbian-Discord> <I​gorPec> that and compressed image test unpack
<Werner> I'd say skip release entirey. No need to force something just to have something
<Armbian-Discord> <I​gorPec> we have OOMs in a few occasions
<Armbian-Discord> <r​pardini> I'd be sad not to release meson64's 5.19 as edge (at least)
<Armbian-Discord> <r​pardini> was a lot of work, and previous edge's were disappointing or borked
<Armbian-Discord> <I​gorPec> we can release without kernel changes where things are questionable
<Armbian-Discord> <I​gorPec> its like 22.08 "upgrade kernel for odroid xu4 and rockchip"
<Armbian-Discord> <I​gorPec> we can do that for example
<Armbian-Discord> <r​pardini> you mean... you'd fork the 22.05 release branch as 22.08, and then just cherry-pick a few things here and there from master?
<Armbian-Discord> <r​pardini> I'd be against that.
<Armbian-Discord> <I​gorPec> no
<Armbian-Discord> <I​gorPec> build system is 22.08
<Armbian-Discord> <I​gorPec> but repository is what it is
<Armbian-Discord> <I​gorPec> with updated only kernels which are sane to update
<Armbian-Discord> <I​gorPec> build from 22.08 of course
<Armbian-Discord> <I​gorPec> this is kind of mini release
<Armbian-Discord> <r​pardini> hmm, I thought build train would build all kernels
<Armbian-Discord> <I​gorPec> where most of the things remain the same
<Armbian-Discord> <I​gorPec> it will build all of them, but i don't need to use them all
<Armbian-Discord> <r​pardini> you mean, it would build all, but you would only publish to repo a few of them?
<Armbian-Discord> <I​gorPec> anyway this part is semi manual
<Armbian-Discord> <I​gorPec> yes
<Armbian-Discord> <I​gorPec> that
<Armbian-Discord> <r​pardini> ahn ok took me a while, sorry
<Armbian-Discord> <I​gorPec> this is some sane middle way to me
<Armbian-Discord> <I​gorPec> a compromise
<Armbian-Discord> <r​pardini> yeah. I'd say fire off the train, lets see what builds and what not. Also, what builds cleanly (all patches applying green/ok)
<Armbian-Discord> <I​gorPec> everything builds, that's not a question
<Armbian-Discord> <r​pardini> ahn. interesting.
<Armbian-Discord> <r​pardini> we'd need at least to fix/hardcoded the tag:xxx for every family in the release branch
<Armbian-Discord> <r​pardini> although sunxi's are already that way in master it looks like, others aren't
<Armbian-Discord> <r​pardini> also, might be a good rule of thumb for "minor releases" to NOT change any current kernel, only edge (except for bugfixes on current maybe)
<Armbian-Discord> <I​gorPec> yes, that is a lot more predicatble
<Armbian-Discord> <r​pardini> also that makes it easier for you: build train, then rm *current*, then publish 😉
<Armbian-Discord> <I​gorPec> something we can release with smoke tests only
<Armbian-Discord> <I​gorPec> that could be doable
<Armbian-Discord> <a​deepv> am I correct in assuming that minor releases allow you to change everything except kernel/uboot patches?
<Armbian-Discord> <I​gorPec> probably a great solution. we provide everything others do, but keep stability at least the same
<Armbian-Discord> <r​pardini> or maybe cat targets.conf | grep -v current
<Armbian-Discord> <I​gorPec> yes
<Armbian-Discord> <a​deepv> how and where to save changes for the kernel/uboot. are we not just going to wait a quarter for a minor release to make changes?
<Armbian-Discord> <I​gorPec> we will probably making a pro version with "update at anytime" support
<Armbian-Discord> <I​gorPec> this brings up too many problems
<Armbian-Discord> <r​pardini> yep. for pro version, we need some serious repository management abilities, maybe even a full repo per-version, not only main/beta
<Armbian-Discord> <r​pardini> eg: who knows the codename for 22.05? (I don't.)
<Armbian-Discord> <I​gorPec> regarding u-boot and updating, u-boot packages are still per branch so this is not a problem
<Armbian-Discord> <I​gorPec> if we skip CURRENT, others will still be update
<Armbian-Discord> <I​gorPec> 22.08 Yapok
<Armbian-Discord> <r​pardini> yeah. that sounds like a good compromise for now. I'll try: for 22.08, we're doing a minor release of edge stuff only. current (and legacy etc) will not be built or updated in this release
<Armbian-Discord> <I​gorPec> legacy actually can
<Armbian-Discord> <r​pardini> yeah, can, but I'd stick to edge to enforce the mainline / community aspect of it
<Armbian-Discord> <I​gorPec> ok, fine for me
<Armbian-Discord> <I​gorPec> then we don't need testers for this one 😉 Or lets say this is optional
<Armbian-Discord> <I​gorPec> as EDGE is anyway ... EDGE
<Armbian-Discord> <I​gorPec> and the same goes for 2nd next, 23.02 release
<Armbian-Discord> <r​pardini> well I'll test meson64 odroid stuff ofc I also have rockpro64, quartz64a, rpi4b available out of production to test
<Armbian-Discord> <r​pardini> and the damned tinkerboard-2 😉
<Werner> To cut a long story short (and come to an end of the half hour meeting ^^) there will be a release with minor stuff, correct?
<Armbian-Discord> <I​gorPec> yes,
<Heisath> Yeah we are running in circles.
<jock> the checklist here https://www.armbian.com/rc-testing/ requires to be filled anyway for this mini-release ? I think it is a good idea to do that anyway...
<ArmbianHelper> ^ RC Testing – Armbian
<Werner> #agreed Release yes. Minor changes only
<Heisath> Yes fill out checklist.
<Armbian-Discord> <I​gorPec> EDGE kernel upgrade only
<Werner> So anything left that should be included in the meeting protocol?
<Armbian-Discord> <I​gorPec> but full images rebuild from current build branch
<Armbian-Discord> <I​gorPec> that second next release will be the same, so two minor, two major releases per year
<Werner> #agreed <I​gorPec> that second next release will be the same, so two minor, two major releases per year
<Armbian-Discord> <I​gorPec> as far as release meeting topic, we are done. a bit over schedule as always 😉
<Werner> yup
<[TheBug]> #agreed Fill out rc-testing checklist as part of mini-release
<Armbian-Discord> <a​deepv> guys, can i skip filling in https://www.armbian.com/rc-testing/? jethome has its own path with test/use release.
<ArmbianHelper> ^ RC Testing – Armbian
<Werner> Aight
<Werner> #endmeeting
ArmbianHelper changed the topic of #armbian to: armbian - Linux for ARM development boards | www.armbian.com | Github: github.com/armbian | Commits: #armbian-commits | Developer talk: #armbian-devel | Forum/Twitter feed: #armbian-rss | Logs: -> irc.armbian.com
<ArmbianHelper> Meeting ended Sat Aug 13 15:51:57 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
<ArmbianHelper> Minutes: armbian/2022/armbian.2022-08-13-14.00.html
<ArmbianHelper> Log: armbian/2022/armbian.2022-08-13-14.00.log.html
<ArmbianHelper> Minutes (text): armbian/2022/armbian.2022-08-13-14.00.txt
<Armbian-Discord> <T​heBug> @adeepv if you read up at start of meeting there I described how that form is used -- it helps by having your testing available in that ticket and easy to track -- one of the improvements over time may be to allow you to submit multiple image tests in a single submission -- I realize this may be a bit inconvient in the imeediate future
<Armbian-Discord> <r​pardini> I shall fill in https://www.armbian.com/rc-testing/ with N2, HC4, VIM3L at least. Maybe RockPro64 and Quartz64a and RPi4b.
<ArmbianHelper> ^ RC Testing – Armbian
<Heisath> thanks for the meeting.
<Heisath> Have a great saturday/sunday.
<[TheBug]> Yes, Thank you to everyone who joined us!
<jock> thanks for the meeting
<Armbian-Discord> <I​gorPec> @Werner do you have a link for log?
<Armbian-Discord> <I​gorPec> thanks everyone!!!!
<Werner> Yeah will be there shortly
<Armbian-Discord> <S​teeMan> This may be the wrong place to ask, but will any boards be moved from supported to csc because their maintainers didn't do what they were supposed to for 22.05?
<Armbian-Discord> <S​teeMan> And also any boards moving from csc to eol?
<Armbian-Discord> <I​gorPec> we can't be very strict as our organisation part is not working well
<Armbian-Discord> <S​teeMan> Is that something that happens in the minor release or only in the majors?
<Armbian-Discord> <a​deepv> jethome community does not use images from armbian download at this moment. we build it itself and repack it to burnable images for emmc
<Armbian-Discord> <I​gorPec> i would say this goes only for major releases
<Armbian-Discord> <r​pardini> SteeMan: I think we just barely invented the minor releases so dunno, I'd vote not to deprecate anything on minor release-time
<ArmbianHelper> ^ #armbian: Release meeting 22.08
<Armbian-Discord> <I​gorPec> minimal should imo be just as little as possible. as we don't have time to focus on this
<Armbian-Discord> <r​pardini> that said, I've seen some board .eos being renamed on master
<Armbian-Discord> <a​deepv> minor releases are a good choice. i don't quite understand how critical the changes between releases are in other things except kernel/uboot stuff
<Armbian-Discord> <I​gorPec> otherwise, we can resolve this within PR https://github.com/armbian/build/pull/4063
<ArmbianHelper> ^ Deprecating build targets for 22.08 by igorpecovnik · Pull Request #4063 · armbian/build · GitHub
<Armbian-Discord> <S​teeMan> OK, just asking as I believe if we set up these processes we actually need to follow through on them eventually (and as I have expressed in the past, I still think there are too many supported boards that aren't really supported). So expect me to ask this again at the next release meeting in 3 months. 😀
<Armbian-Discord> <I​gorPec> > in other things except kernel/uboot stuff
<Armbian-Discord> <I​gorPec> isn't that enough ?:)
<Armbian-Discord> <I​gorPec> but then you have build engine and CI that builds images
<Armbian-Discord> <I​gorPec> and network issues while doing this
<Armbian-Discord> <I​gorPec> and some runners fails, you need to repeat and sometimes you have to start from scratch
<Armbian-Discord> <I​gorPec> and repository tooling has its own issues. it doesn't support zst yet
<Armbian-Discord> <I​gorPec> it needs to be patched
<Armbian-Discord> <a​deepv> periodically changes the list of installed packages, repositories, system configs (this, by the way, is about those things that are not updated with package updates). Maybe we could still introduce the ability to fully upgrade between versions by simply updating packages?
<Armbian-Discord> <I​gorPec> but, to get there, OS on repo machine is still Focal ...
<Armbian-Discord> <r​pardini> we've also things like root-resize script, and other board-side scripts that never run unless image is actually booted up and tested
<Armbian-Discord> <I​gorPec> yes, that too
<Armbian-Discord> <r​pardini> btw for minor release I'd drop all non-Jammy too
<Armbian-Discord> <I​gorPec> and recently there has been serious changes there
<Armbian-Discord> <r​pardini> (my BM's are 5 out 6 times still Impish, not Jammy, shame on me)
<Armbian-Discord> <I​gorPec> adeepv: upgrade via packages will anyway come with
<Armbian-Discord> <r​pardini> resize-script for example is in BSP package (as most are I think)
<Armbian-Discord> <I​gorPec> yes
<Armbian-Discord> <I​gorPec> those are coming
<Armbian-Discord> <r​pardini> 👍 I think is a good compromise
<Armbian-Discord> <I​gorPec> yep
Heisath has quit [Quit: Leaving]
<[TheBug]> SteeMan: as processes improve and we get a bit more organized we will start leveraging the documentation that has been created in a lot more detail -- right now we ware just starting to get this type of thing in place and get everyone informed so we can start to follow these more effectively. As things move forward if a board is not being maintained it will be moved CSC and follow the outlined
<[TheBug]> guidelines on support.
<ArmbianHelper> ^ Board Maintainers Procedures and Guidelines - Armbian Documentation
<jock> Leaving, see you guys, thanks for the meeting again and good evening/afternoon/whatever!
jock has quit [Quit: Leaving]
<Armbian-Discord> <l​anefu> No action items?
<ArmbianHelper> ^ [image/png] (362.3KiB)
<Armbian-Discord> <l​anefu> What's difference between major and minor release from a criteria perspective and a naming perspective?
<Armbian-Discord> <r​pardini> minor release = cat targets.conf | grep edge being pushed first to beta repo then to main
<Armbian-Discord> <r​pardini> thus current and legacy are NOT released
<Armbian-Discord> <r​pardini> allows us to field test u-boot, board side scripts, and edge kernels
<Armbian-Discord> <r​pardini> also no real testing required for release I guess... we'll do best-effort.
califax has quit [Remote host closed the connection]
califax has joined #armbian
<Armbian-Discord> <l​anefu> Kinda like an alpha? Concept is sane just need to communicate it clearly when published at large
califax has quit [Remote host closed the connection]
califax has joined #armbian
<montjoie> IgorPec: perhaps a bit late since your meeting discution, but I still plan to do a lava presentation, just holidays is a dangerous zone for my planning
<montjoie> and I have a usbsdmux from Linux automation so I could do a flashing demo with LAVA
califax has quit [Remote host closed the connection]
califax has joined #armbian
califax has quit [Remote host closed the connection]
califax has joined #armbian
alekksander has quit [Ping timeout: 255 seconds]
Liberate1Sheep has joined #armbian
indy has quit [Quit: ZNC 1.8.2 - https://znc.in]
rpardini has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rpardini has joined #armbian
indy has joined #armbian
<Armbian-Discord> <r​pardini> nice
<Armbian-Discord> <r​pardini> could one use a 2nd SBC, some flat connector cable, and somehow emulate an SD to the 1st SBC?
archetech has joined #armbian
<vpeter> no
<vpeter> I doubt there is any SD emulator. Maybe with FPGA.
<ArmbianHelper> ^ [image/jpeg] (177.3KiB)
xoan725454 has joined #armbian
xoan72545 has quit [Ping timeout: 268 seconds]
xoan725454 is now known as xoan72545
alekksander has joined #armbian
alekksander has quit [Read error: Connection reset by peer]
<montjoie> in theory, you dont need any sdmux, my first try to test if LAVA could test armbian was via a boot with simple kernel+initrd which dd the image on the sdcard. This setup rely that each "flash" give a working uboot for next boot
<montjoie> on the first bad image (breaking uboot), you need a manual operation
<montjoie> the only prerequisites, uboot need to have network and is interuptible
<Armbian-Discord> <r​pardini> yeah, I guess UMS mode in uboot helps a lot with that
<Armbian-Discord> <r​pardini> my problem is exactly testing very possibly broken uboot's...
<Armbian-Discord> <r​pardini> lane came up with a testing rig for a certain rockchip board... with eMMC and a jumper for maskrom, plus a recovery SD card. rig operation is power down, close maskrom, up, boot from SD with UMS mode uboot, then flash emmc; down, open maskrom, up and test.
oida has joined #armbian
<Armbian-Discord> <r​pardini> so that would work for board with both eMMC, SD, and an acessible/hookable maskrom
<Armbian-Discord> <l​anefu> So i did look into uboot a bit and it can read GPIO state.... so could do something similar with a custom uboot to trigger UMS mode..... but kind of is counter to "testing" uboot i guess
<Armbian-Discord> <r​pardini> well I'd say if in general "armbian u-boot builds" have sane ways to trigger UMS mode it's a win
<Armbian-Discord> <r​pardini> so in that case the testing-harness uboot would be the same as shipped to users... so perfectly valid
<Armbian-Discord> <r​pardini> actually... we have ways to trigger ums, given only power control & uart
<Armbian-Discord> <r​pardini> would involve "Hit any key to stop autoboot" and some nice uart timing... but could be done
<Armbian-Discord> <l​anefu> oh true.. that's my method for flashing radxa zero.. is to just manually interrupt uboot and trigger UMS
<Armbian-Discord> <r​pardini> (doing that right now btw)
<Armbian-Discord> <r​pardini> ums 0 mmc 2
<Armbian-Discord> <l​anefu> ums 1 1 on radxa zero (random trivia)
<Armbian-Discord> <M​icroLinux (Salva)> ums 2 2 on my radxa zero
<Armbian-Discord> <l​anefu> interesting
stipa_ has joined #armbian
xoan725455 has joined #armbian
stipa has quit [Ping timeout: 268 seconds]
stipa_ is now known as stipa
xoan72545 has quit [Ping timeout: 268 seconds]
xoan725455 is now known as xoan72545
<Armbian-Discord> <r​pardini> unfortunately requiring ums means (for test-rig purposes) we can't ever break u-boot... which is... unlikely
<Armbian-Discord> <l​anefu> well i'll call it a notch above in reliability to my ava maria curl | dd and power cycle method
samythemany has joined #armbian
samythemany1 has joined #armbian
samythemany has quit [Ping timeout: 268 seconds]
lemonzest has quit [Quit: WeeChat 3.5]
sheepman[m] has joined #armbian
<teknoid_> [ o.k. ] Done building [ /root/armbian-build/.tmp/image-c0c0a753-938b-4182-984a-aa44bfd4d92b/Armbian_22.08.0-trunk_Odroidc2_bullseye_edge_5.19.1_minimal.img ]
<teknoid_> test tomorrow
rpardini has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rpardini has joined #armbian