Igor

Lets say it is desirable that someone from specific group checks the code, but in most cases this review should at least check for most obvious troubles any developer can spot, perhaps propose changing approaches in scripting, coding style. I don't expect Rockchip / Allwinner / * specialist will be able to see that some patch breaks some functionality. This is a job of automated test routines on hardware. Which is very much WIP but that's what we can afford ATM. If we engage more people to view the code before merge, we made a step forward. And that counts! It doesn't need to be a regular team member. Anyone with a Github account and some time and interest to help us code better is welcome to comment and slow the process of merging. I think we also need to create a protocol for emergency merge / corner cases.

As our projects grows in size and complexity it is getting more and more important to add additional measures to improve code quality. Code is added almost daily and therefore we have to do what is possible to improve chances that things doesn't break or have obvious bugs. Therefore I propose to enable additional conditions applied to the build framework master branch: - code must be submitted via a pull request - pull requests require at least one review and approval from another individual - all changes open requests resolved before merge. - in-line conversation on merge request has to be resolved before merge - commits pushed to master must have verified signatures, - conversation on merge request has to be resolved before merging. @private/contributor Most of the things we already use, so new thing is mandatory review - counts from anyone except from the one that is sending a pull request. Speak up if you find those measures too draconian. Also I would like to point out another change related to our label system. It seems too complicated, some tags were never used and not many people are using them. So limiting them down significantly - comments are welcome here https://armbian.atlassian.net/browse/AR-959

- workaround can be found in manual or by searching this forum. - solving this problem is an expense. Supported or not supported hardware. Its general problem, so ticket was opened: https://armbian.atlassian.net/browse/AR-1116 Look how many problems there are - which is one of main reasons why this board is not supported anymore: https://armbian.atlassian.net/jira/dashboards/10000

I can only tell you that Orange pi 3 LTS board is not supported in Armbian (or any other distro) yet. HW is different enough that it can't just work with the code for non LTS version. Certain things has to be ported to the modern kernel that we use. But that never starts without hardware on the desk and other necessities such as time. We need to get them to the lab (they has been sent out from China last week), redistribute to people that want to spent their precious time talking with users problems and whispering to the hardware.

workaround: download file from https://imola.armbian.com/beta/pool/main/l/ install with sudo dpkg -i FILE.deb and DTB package. Headers are optional - if you need to build modules.

Yes, until we don't find time to fix switching and then when life permits check why SPI doesn't work. Sadly we are not in a position (far away) to check if all functions doesn't break on upgrade ...

Fixed https://armbian.atlassian.net/browse/AR-1107

https://github.com/armbian/mirror dl.armbian.com and apt.armbian.com are picking them. Problem in this case is that TV boxes are unofficial hacked builds which might not work with all armbian tools. https://www.google.com/search?q=list+all+files+in+apt+repository

List is added at build time while your image was made before https://github.com/armbian/build/commit/bd3609b4d1d9c5402d111357b6e394025075cc98 yes

Fixing it ...

No, this is correct way. The problem was on (our) server side.

Fixed. (on this server works https://imola.armbian.com/apt elsewhere soon)

Some packages form 22.02 are present in the index, some not. I think its related to this: I have re-added those packages but dunno if it will help. Manual recreation of repository, as a known workaround, takes hours, which I can't possibly find just like that ...

something is wrong ... looking into.

https://github.com/armbian/build/blob/master/config/distributions/bionic/support Bionic has no more support status from our perspective. We don't test it anymore nor fix bugs. Focal is going to be old stable in 2 months after Jammy got out. We can't deal with that many options ...

That goes to beta.armbian.com ... stable repository needs few days to get in sync. First files are synced then after i think 48h index ...

There were some changes in the packaging process, but we didn't notice this kind of troubles. Can you provide more info - are you changing anything in the build process and what? How to reproduce this? @goingAny clues?

I don't know what is missing. Try to find out and we can add that for the future.

Choose ZSH at first login or change in armbian-config. And you will have the same shell.

All those people should have access to website. But if there are no images, or there is some problem in the system, they can't do much. Just filing a bug.

We have a small mess around those images. A few are missing, some needs to be removed ... if image is not there, use the one from archieve or build one. No other quick solution ATM.

yes. also stable images are ready. Uploading will take hours ... and I need to check with @TRS-80 if document is ready to go. Yes, but branch it for bugfix release. That shell go out from there.

Updated RC images. https://imola.armbian.com/dl/ -> $BOARD/rc

I'll make another RC in a couple of hours which can also be a release build. In case no major troubles are found ... @Heisath Anything else? In jira we have to move undone tasks further and release, release docs are also getting into close to done state.

@Kriston Someone with this HW and some know how + time would need to do something like this https://github.com/armbian/build/pull/3514