Igor

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.

Those are developers preview builds, where you can check what works and at some point it will be good enough for some uses cases. In a couple of years, it will be functional on the level of kernel 5.10.y. Download is possible from CI pipeline: https://github.com/armbian/build/releases Boot log: This board is looking for maintainer(s) and (this) forum moderator (contact @Werner).

https://www.armbian.com/radxa-zero2/

https://www.armbian.com/odroid-m1/ - kernel 6.1.y LTS

Just a reminder, if someone wants to fix it.

https://www.armbian.com/rock-5b/

Many of us are using Armbian not just on ARM single board computers but also on servers (bare metal & virtual). We use our builds since we trust it more then Debian, Ubuntu, not to mention other distributions that are recklessly updating and one ends up as an OS tester and not OS user. Personally I use Armbian Jammy on Ryzen 9 workstation with great success. My primary use case is development / productivity. For the road I used to have 13" Dell notebook which recently suddenly died. It was out of warranty so I had to get something new. After some testings of various devices I settled with 12th Gen Intel i5-1240P powered Lenovo. Then I tried many general purpose distros to see how well they work and all had some (minor) troubles ... We are having UEFI images (common image) since some time, but UEFI nor desktops were fine tuned nor ready for such performance daily driver desktop usage. We were close, but not close enough to just run it. Past two weeks we have been lifting general UEFI support, fixed many bugs and what came out is "Armbian ultimate developers desktop build". - improved support in GRUB (armbian wallpaper) & HiDPI GRUB support - all preinstalled applications are normal apt packages - current 5.15.y kernel, Jammy userland (5.19.y has some strange issues) - snapd is not installed (user can install it) - HiDPI support (automated adjustments on big screen resolutions) - NVIDIA graphics acceleration with proprietary driver (x86 only) - Intel graphics acceleration also works out of the box - preinstalled Google Chrome (x86 only) - preinstalled Microsoft Visual Studio Code (x86 only) - ZFS 2.1.5 ready (apt install zfsutils-linux zfs-dkms) - face unlock works perfectly fine on this laptop - installation to SSD drive to dual boot with Windows 10/11 is supported Armbian classical way by transferring actual live image to the prepared partition via nand-sata-install. All you need to do is prepare spare space on your drive, Windows 10/11 or Linux, UEFI support (most if not all hardware for past 10 years has it). I have tweaked images (XFCE, Gnome, Cinnamon) a bit to my personal needs, but making changes is welcome. Nice to have: disk encryption within nand-sata-install, small bug fixing, additional DEs. Currently we have CLI, XFCE, Gnome and Cinnamon. Others are too buggy. https://www.armbian.com/uefi-x86/ https://www.armbian.com/uefi-arm64/ Please report where it works and how (well)!

Preparation Supported build environment is Ubuntu Focal 20.04 x64 (minimal iso image). a guest inside a VirtualBox or other virtualization software, a guest managed by Vagrant . This uses Virtualbox (as above) but does so in an easily repeatable way. Please check the Armbian with Vagrant README for a quick start HOWTO, inside a Docker , systemd-nspawn or other container environments (example), running natively on a dedicated PC or a server (not recommended), 20GB disk space or more and 2GB RAM or more available for the VM, container or native OS, superuser rights (configured sudo or root access). Execution apt-get -y install git git clone https://github.com/armbian/build cd build ./compile.sh This will download all necessary sources, execute compilation and/or build a boot-able image. Most of things will be cached so next run will be extremely faster! Real time examples: Documentation