Igor

This was most likely solved by now, but don't have a device to test. @monkaBlyat @Yakov

Armbian 22.11 Bullseye / Jammy Kernel 4.9.318 or 6.1.4 Release date: Jan 10, 2023 Legacy kernel has more or less full hardware support, while mainline lack functions such is wireless, HDMI, ... https://www.armbian.com/orange-pi-zero-2/ Looking for maintainer!

I forgot sorry. Then Git. For kernel sources it makes - as we make changes to it. Main distributions changes kernel a lot less then we do and they all provide source packages of that modified kernel. If we are talking about https://github.com/armbian/build/tree/master/packages/extras-buildpkgs then this is optional. I don't think anyone would seek source package for those few things we are building there.

I also see this concern. Proceeding too strict could backfire in this regard. Build framework (master) is already too advanced for average Joe. Default build process has to remain looking simple. Also regarding patches - we have to expect users will throw in all sorts of garbage patches (exclude sanity check from /userpatches perhaps?) and we have to accept even not formed completely in order. Only we and pro users needs that we are reminded patches are not formed well, others not. Something that should be behind "EXPERT=yes"?

Some people had troubles, indeed. Images were replaced today and they have been tested. Try. (download might be slow / not synced to all servers yet / use torrent or retry if you are going to try within next couple of hours)

We have to leave personal preferences and grunches behind. The tool should be developed into the direction that this doesn't represent a problem. Since this tool was developed "as it goes", naturally, it has many design flaws. Which resulted in strange decisions. Lets remember that compromises were made out of necessity, lack of time, ... We have to be constructive, improve communication, planning & coordination, ... @balbes150 If a major redesign is needed on top of NEXT, we might need to deal with it later as otherwise we can't bring this in. If a design problem is recognised, open a Jira ticket and describe why you think this or that implementation is bad. If its a small change and if we are united, we will rework it at once, otherwise this will be put into back log. Someone has a better idea?

I agree. I am trying to enforce needed coordination and structure by at least organising meetings, shuffling Jira tickets (this should be done by more people) provide tooling and am available for anyone from the team at any moment. At the same time I am trying to recognise / define our limits and scale it into the frame that is controllable. As too small resources provoke stress. Oleg builds his things on arm64, but we have to cover more, perhaps some stupid things for legacy reasons. We can't cut off blindly. I am totally aware that we are dragging 3/4 of those without any point, but someone has to remove them and be sure nothing is broken ... but since this falls off with the NEXT, why wasting time dealing with that? Lets focus into seeking for solutions. And compromises. I am sure we will need to make some - our common goal is have the tool maintainable and modernised. And this is not a fixed thing - when better ways are found and if most of us agree that something can be removed, we remove. If not, its better to stay. There are people out there, that are using this build framework. We don't want to cause stress to them.

Thank you! Impossible without help of: @Contributor/Maintainer @Moderators https://github.com/orgs/armbian/people https://github.com/armbian/build/graphs/contributors https://docs.armbian.com/Release_Board-Maintainers/ ...

Aha you mean like having a proper "software design" phase ... Currently we have "I have an idea and will work on" and we want to have some process: idea -> discussion / developers meetings / comment on that / co-design -> Jira story (or a plain document). And repeating those cycles until we are happy. Then coding. Yes, that would be ideal. The problem is that all this planning require a lot of resources we don't have. Ideally we would have a dedicated manager of software development. I am now doing this, running a business, doing paperwork. I am forced to improvise, make things on a "best effort" way. I hope that we will implement design mechanism into developers meeting and after. But at this stage we have a large branch of a build system that was not designed together, but is based on common design.

1. Feature implementation is different and you don't like it - propose changes (if its questionable, we vote), task if small, story if big 2. Something doesn't work - bug ticket 3. Feature is missing - describe what you are missing (task if small, story if big) You mean this?

Yes of course. I can say that current focus is optimisation for running as stable as possible and running within CI. We need to have this phase in near to perfect state before heading to optimising it for low resource systems. There are bugs that needs to be discovered and fixed before we proceed. I would suggest that for those ideas simply simply open a ticket. Our build system contains configurations, build lists, helper tools, speak multi arch, speak multi branches, supports different underlying packages assemblies, can be assembled on different arch, have many levels of caching ... acts like a giant compiler and linker. Perhaps a bit philosophical

Agree, I already opened a ticket: https://armbian.atlassian.net/browse/AR-1454 Current state of logging is terrible on the other end while if something breaks, logs can help to diagnose - the more the better. Perhaps we could introduce better levels of logging? Dunno how hard this is from current perspective? Cross compilation is one of the core tool advantages - removing would be a mistake. The rest I can't comment as I didn't study enough yet.

Looking for a volunteer to split kernel-drivers.sh into functions, for aufs/wireguard/kali/exfat https://armbian.atlassian.net/browse/AR-1478 If this is not ported, we will probably just drop it. But on the other hand, this is easy task and nice opportunity to understand armbian-next better and help.

Fix for packaging mechanism https://github.com/armbian/build/tree/master/packages/armbian won't be accepted as the problem is not there. This has to be solved with a kernel patch. Since this is a private kernel, it doesn't get most of common fixes. I remember lds problem was present some time ago in all kernels, but solution is long gone from my head.

Profit is that sweet deal when you cover costs. Community / amateurs rarely work on boring cases that last weeks or months to finish in exchange for absolutely nothing, not even satisfaction of helping people as nobody will notice or understand their sacrifice. You can bump into the people, this community is full of them, that will help you with extremely valuable advise or hint - most things are solved for free. By us, by community. But you also want that hard things are solved for free and here things stops, sometimes brutally. In most cases they don't progress as they are costly in technical and organisational sense. If you treat this project with 20 or 200 USD per week, while we need 5000 USD per day to match costs, we are very very far apart. Most used business model to profit in OSS is to steal from someone and sign below. Nobody will sue you as its too complicated and how a non-profit can allocate money for that? Certain % of people will fill sick, some will complain and point towards dirty players, while you / end users just want to have free fun. This seems to be pretty typical profile around here I could point myself close to that, except that I am using my experiences and skills to progress this project. Alongside with others.

You should create one in the 1st boot process. Otherwise: https://www.google.com/search?q=how+to+create+user+on+debian+system

Common to all modern kernel based Linux distributions that does not chain load with propriety kernel? Armbian is a build system that assembles and provide ready to run Debian like / based OS for single board computers. Yes of course, but open source boot loader is not done yet, dunno what is the status ATM, while we decide to not provide Armbian images with proprietary vendor (Petit)boot / kernel. I don't know if there is a solution. Only a workaround - that you use some other WiFi dongle.

Just keep it on community level - you are a peer at best, not a customer. If you want that someone do your homework, trade, provide a compensation. Keeping this project alive, without helping you, costs. Developers are fully aware of troubles, but the problem is that resources are 1/1000 of needed. We are shooting monsters with slingshots, while you remain blind and ignorant no matter what is sent your way. Your startup dug lets say 5M EUR of starting capital which you waste to develop software that anyone can download for free and you also support it for free until you ran out money? I am sure you were not that stupid. This is automated test report from a few days ago: It is called "smoke test". It power boards on, checks basic functions following by reboot and powers off when done. And record few things ... We can run this at any moment and the plan is that it runs automatically at every code change. If end users refuse to fund software development and you do, perhaps rather help where project is asking for help? We are also asking for help developing this test system, which saves us a lot of time, or armbian-configurator, which saves you a lot of time, for several years now. Nice way or with applying a pressure (as now). Nothing. Cash to code with pros? Nothing. At least for things you want and need (problem from this topic) and you can't just steal from someone / download for free? Nothing. Back to topic? Who will spent several weeks digging into this driver? Biggest frustration is that I can't give that person anything, not even a comfort: "Its a hard work, there is a big possibility of failure and you will get no compensation because users do not respect this work or you". While our competitors will tell: "Dear John, we are working hard to solve this problem for you. You are important to us. It will probably take several months", while they will be opening a bug to us and applying a constant pressure. Welcome to the dark side of the FOSS projects.

I usually start this way: https://www.google.com/search?q=wifi+recognized+as+cd+rom then integrate it into our kernel or share on forums. Its not a problem specific to M1 nor Armbian.

My test device is now pretty stable: ____ _ _ ____ | _ \ ___ ___| | ___ __ (_) / ___| | |_) / _ \ / __| |/ / '_ \| | \___ \ | _ < (_) | (__| <| |_) | | ___) | |_| \_\___/ \___|_|\_\ .__/|_| |____/ |_| Welcome to Armbian 23.02.0-trunk.0118 Jammy with Linux 5.15.86-rockchip64 No end-user support: untested automated build System load: 2% Up time: 48 min Memory usage: 23% of 473M IP: 10.0.30.152 CPU temp: 36°C Usage of /: 7% of 29G RX today: 100.7 KiB [ General system configuration (beta): armbian-config ] Last login: Sun Jan 1 14:03:19 2023 from 10.0.10.12

Elsewhere you won't get much. Boot loader waits 1 or 2 seconds for input. This you can disable. Other services all together are close to nothing ... you can get down by shrinking kernel to support your use case only and use busy-box https://busybox.net/ and completely shrink OS functions, but its some work - if you can afford according to your use case. DHCP will sadly remain bottleneck, its also dependant on DHCP server ... this doesn't look like a hobby project?

Setting fixed IP address might get you some savings.

Bulk is recommended 😎