Jump to content

Armbian 22.05 (Jade) Release Thread

Igor

By Igor
in Armbian Project Administration

 Share

Recommended Posts

Igor

Igor

Posted
Posted
  • Release Candidate Code Freeze Date: 2022-05-14
  • Release Planning Meeting Date:  2022-04-23 14:00 UTC+1 
  • Release Planning Meeting Location: Armbian IRC
  • Release Date: 2022-05-28
  • Release Coordinator: Igor

 

Board maintainers:

@Contributor/Maintainer

 

  • Open / close bugs related to your board  in Jira for your board and close them if they are resolved before release date.
  • Record also bugs that were closed but they were not recorded to Jira (to have this info in release documentation)
  • Bugs that are resolved change field "Fix versions" to "22.05". Optional select board and SOC.


Everyone with Jira access:

@private/contributor

 

  • claim ownership of closed tasks (Assignee)
  • close issues if they are done (change field "Fix versions" to "22.05")
  • move issues to next release cycle (this needs to be done) or backlog (one day)


Anyone that wants to join:

 

  • we are fairly good in maintain hardware, a little less in tweaking OS and desktops, ... We are good with infrastructure, except forums. Here we need help in moderating and reorganising. We also need help in leading projects. Like this release cycle and many small projects. If you wanna join coordinating release, read this ...

 

Meeting preface:

 

Spoiler

Board maintainers/development

 

In a past few months many new board maintainers joined our party. This improved our board support section. During a release process we hope on their involvement to get support status of particular device(s). To have that, one has to open or close bugs in Jira. Jira bugs or tasks has to be tagged with version in making (2022.05). Optionally we are discussing if any of bugs can be solved before release.


There are ongoing activities making another POC of armbian-config with Python. We welcome early tool designers to join, so we can move faster to coding phase. CI with automated deployment is already in place so development should go faster once we lift it off.
 

Build system

 

By the end of this month we want to merge https://github.com/armbian/build/tree/armbian-next in case it will produce working images. After the merge we are going directly into code freeze / bug fix only phase. https://docs.armbian.com/Process_Release-Model/#release-testing There are a lot of changes and this is the only sane way to integrate this big chunk of code.

 

Mandatory review on merge request

 

Many of us were sceptical on the choice but after almost two months it seems that this move was well accepted and is creating value. In term of quality and saved time. There are also more people contribution and people used to go to fast, seems to handle it well. Sometimes its difficult and pointless waiting for review, so we need to develop emergency review protocol.

 

Infrastructure

 

Beside board maintainers, Devops team also received help so we can finally improve our download re-director and start improving infrastructure related tasks https://armbian.atlassian.net/browse/AR-970

Testings

 

We are working on enabling Lava test framework within hardware lab.

 

There is ongoing long term goal to refactor forum structure since we are agreed it doesn’t keep up with the need. Top-level changes are needed to move old and deprecated low on forum, actual / hot on the top. Also we would like to improve regular users sections which is scattered around more forums and / or doesn’t get enough love & attention.


 


 

1
  • Igor pinned this topic
schwar3kat

schwar3kat

Posted
Posted
On 4/20/2022 at 5:44 AM, Igor said:

Release Planning Meeting Date:  2022-04-23 14:00 UTC+1

Please accept my apologies.  I'm not available at the meeting time.  I will review the IRC logs.
I'm maintaining 3 boards:
Orange Pi Zero H5
Orange Pi R1 H2
Orange Pi R1 Plus LTS RK3328
There are currently no open bugs or incomplete tasks that I am aware of in Jira for these boards.
I'm happy to help out in any way that I can, although it's not yet clear to me how or at what stage I should get involved in testing.

K

Igor

Igor

Posted
  • Author
Posted
32 minutes ago, schwar3kat said:

I'm not available at the meeting time.  I will review the IRC logs.


Its impossible to get all people together and this meeting was anyway on a short notice due to upcoming holidays and the fact we are late. 
 

32 minutes ago, schwar3kat said:

although it's not yet clear to me how or at what stage I should get involved in testing.


Anytime, at once - found something?, file a bug. Focus is CURRENT kernel, others are optional. Check once again in Jira if closed and on device, after code freeze. That would be ideal process for now. I hope we are going to bump automated testings on a better level soon, so not much manual intervention will be needed.

 

Other general things like bug in 1st run script or similar, should also be booked to Jira. Unless they are not already present. In case something else, not something from your field needs to be closed or moved ahead (to this version), help is welcome. Somebody has to do it ...

1
Igor

Igor

Posted
  • Author
Posted

Release is not just freezing the code and generating images. Its a time when we pull together stronger, agree and deal with common goals and ideas. Things we are dealing with are complicated. Linux is complex, our framework is getting there too and only together we can deal with all this.

 

I started on freezing the kernel version. There is also some breakage, some related to our patches, some not. But since we have to freeze it sooner or later, perhaps now its the right time.

 

This brings a few good things at once:

  • temporally release people that are working close with maintaining kernel code @going@jock@balbes150@amazingfate myself ...
  • this can bring more resources on trying to match with / merge armbian-next. @rpardiniworked for moths on this. Lets review the code and help sorting out bugs. Again. IMHO it is possible to merge, but if code remain unstable by the code freeze date (2022-05-14), we are merging after new images are generated.
  • asking @Contributor/Maintainer board maintainers to engage in images building and testing (currently still from master branch) and bug reporting as earlier as possible (once PR 3736 gets merged)
  • reproducible build framework in release branch. Which is most important long term consequence.

Additionally, we would like to finish u-boot upgrade on Rockchip and release major forum refactoring @TonyMac32 @piter75 @balbes150

 

Happy Workers' Day!

5
Igor

Igor

Posted
  • Author
Posted
On 4/19/2022 at 7:44 PM, Igor said:

Release Candidate Code Freeze Date: 2022-05-14

 

@Contributor/Maintainer If something has to be squeezed into the code ... I guess merging armbian-next has to be postponed. After Sunday, bugs bugs bugs. Solving, not generating new ones ;) 

1
rpardini

rpardini

Posted
Posted

Yes. I don't think it's even near being merge-able right now, small bugs but are showstoppers for most people, and I can't handle them all by myself in such timeframe, including handling all the Jammy fixes and a dozen rockchip kernels, extlinux, nand-sata-install, etc.

And once merged a whole slew of things will show up (extras buildpkgs, prebuilt, rootfs caching, repo publishing, git bundle stuff, most of the GHA stuff that normal developers hardly ever run).

The concepts behind armbian-next are almost fully realized, but the fruits still have to be collected. Otherwise it seems pointless...

I will keep it rebased as much as possible, so the effort lives on, only without pressure.

Before merge, documentation has to be written too, so that will take a while.

work continues!

 

 

2
TRS-80

TRS-80

Posted
Posted

Sorry could not make the meeting.  I just read the notes.

 

I am back to work now but locally (almost no travel) so I can have a little time here and there maybe to help with the release somehow.

 

I'll try to hang out in IRC.

3
Igor

Igor

Posted
  • Author
Posted
21 minutes ago, balbes150 said:

Do I understand correctly that this is a message from a script   lib/image-helpers.sh  ?

Only in it I found such a message

 

Found it, will make a PR at once.


Edit: yes, seems ok.

Igor

Igor

Posted
  • Author
Posted

@Contributor/Maintainer


"missed released will result in immediate forfeit of “Armbian Supported” status and demotion to CSC status unless Armbian team grants exemption

https://docs.armbian.com/User-Guide_Board-Support-Rules/
 

Probably board maintainers are not aware, status will be dropped to CSC in case they don't show up. 
@yang Can you send them a notice to help with testing? One RC images are out and new RC will go out probably this weekend.

1
schwar3kat

schwar3kat

Posted
Posted

RK3328 Orangepi r1plus lts seems to have reverted to broken LAN0 Ethernet behavior similar to before the commit
Enable rockchip64: XHCI HCD USB TRB ENT quirk for RK3328 #3763
I can't immediately see what the cause is.  The patch works and quirk is included in the dtb.
Same as before, it can be mitigated by disabling tx offload.
I've reset AR1172 to in progress,
 

1
Heisath

Heisath

Posted
Posted

I will run mvebu tests tomorrow. Sorry for not being available for the meeting, turns out, building a house is a pretty major thing...

2
ManoftheSea

ManoftheSea

Posted
Posted

22.05.1_espressobin_bullseye_current_5.15.35.img.xz - no issues on ebin v5

22.05.1_espressobin_jammy_edge_5.17.5.img.xz - no issues on ebin v5

1
schwar3kat

schwar3kat

Posted
Posted

orangepi-r1 - no issues observed.

Tested:
Armbian_22.05.1_Orangepi-r1plus-lts_bullseye_current_5.15.35
Armbian_22.05.1_Orangepi-r1_focal_current_5.15.35
Armbian_22.05.1_Orangepi-r1_jammy_edge_5.17.5

iperf on wifi and both Ethernet interfaces produced expected results.

1
schwar3kat

schwar3kat

Posted
Posted

orangepizeroplus - no issues observed.

Tested:

Armbian_22.05.1_Orangepizeroplus_bullseye_current_5.15.35

Armbian_22.05.1_Orangepizeroplus_focal_current_5.15.35

Armbian_22.05.1_Orangepizeroplus_jammy_edge_5.17.5

 

iperf on wifi and Ethernet interfaces produced expected results.

1
schwar3kat

schwar3kat

Posted
Posted
19 hours ago, schwar3kat said:

RK3328 Orangepi r1plus lts seems to have reverted to broken LAN0 Ethernet behavior

Can someone please advise me.
I tried to clone the RC branch to try and diagnose the issue.  I'm not sure if this is correct:
git clone -b v22.05 --single-branch  https://github.com/armbian/build

It cloned, but the image that I built worked, unlike the one I downloaded, so I suspect that this clone might not be correct.

Werner

Werner

Posted
Posted

Simply doing git clone on the repository and then using "git checkout v22.05" should do the trick. With git branch you can then check on which branch you are.

1
Igor

Igor

Posted
  • Author
Posted
3 hours ago, schwar3kat said:

Can someone please advise me.


When RC builds are out, we need to test them. CI ads some troubles and this way we can fix that too. I already find and fix many issues with CI. Practically lost a week just on stabilising that.

schwar3kat

schwar3kat

Posted
Posted
24 minutes ago, Igor said:

CI ads some troubles

All three of the orangepi-r1plus-lts images in the RC folder are bad, they have the USB3 Ethernet receive bug.
When I build the v22.05 branch locally, the images work correctly
Affected images are:
Armbian_22.05.1_Orangepi-r1plus-lts_bullseye_current_5.15.35.img.xz
Armbian_22.05.1_Orangepi-r1plus-lts_focal_current_5.15.35.img.xz
Armbian_22.05.1_Orangepi-r1plus-lts_jammy_edge_5.17.5.img.xz

If I understand you correctly, then this is probably a CI issue.
Is there anything that I can I do to help resolve this.

Igor

Igor

Posted
  • Author
Posted
16 minutes ago, schwar3kat said:

If I understand you correctly, then this is probably a CI issue.


Let me explain how CI should build images. I am generating packages with a regular build train:
https://github.com/armbian/build/actions/runs/2360625136
 

It generates all kernel packages, firmwares, desktops and all u-boot + board bsp. Then i put packages to the nightly build repository which currently contain (should contain) latest packages made from v22.05 branch and labelled this way too. Next I use a script "Build images" and choose extra parameters:
- build RC images (stable is identical, just they are placed to /archive instead of /rc)
- which runners will be used (not relevant build performance tweak)

- which is the source branch (v22.05 in this case)

 

Now there are all sorts of problems possible:
- error reporting is not the best and we can easily have false positive build. Corruption can happen if some runners goes out of memory or space. Happens from time to time.

- yesterday i have deleted repository by mistake and i need to recreate it (no technology in place at that storage)

- i have many troubles with local lan due to failed attempt of refactoring

- NAS often timeouts and build has to be re-done

- Github is unstable when providing Docker images, when starting Runners, CI because of that is not 100% reliable

- all this process is still half manual 

 

27 minutes ago, schwar3kat said:

Is there anything that I can I do to help resolve this.

 

In short term, no. Long term - start learning Github actions. We need to cleanup the code and have more people that can jump up and fix troubles if they arise. Code complexity is going up and most of the code there is completely without any proper commenting or history. It was ad-hoc on ad-hoc on ad-hoc ... its time to get things in some order.

1
jock

jock

Posted
Posted

ASUS Tinkerboard-S, briefly tested and perfectly working:

 

  • Kernel 5.15 - CLI - Debian Bullseye
  • Kernel 5.15 - XFCE Desktop - Ubuntu Focal
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept