Armbian 20.02 (Chiru) Release Thread

Igor · February 17, 2020

3 hours ago, lanefu said:

I tried removing all patches and that didnt change the behavior.

I found a (tmp) workaround. 20.02.2 images for Lepotato are rebuilding with working (meson64) kernel 5.4.13 and the same kernel goes to the repository which will be updated right after that.

TonyMac32 · February 17, 2020

52 minutes ago, Igor said:

I found a (tmp) workaround. 20.02.2 images for Lepotato are rebuilding with working (meson64) kernel 5.4.13

So somewhere between 5.4.13 and 5.4.20 things broke? Or is there some other workaround going on?

Igor · February 17, 2020

2 minutes ago, TonyMac32 said:

So somewhere between 5.4.13 and 5.4.20 things broke? Or is there some other workaround going on?

Yes. And it seems not our fault. Its fixed with a workaround for now.

- images are released

- repository updated

Now hunting other nasty bugs. I already found one - no images for Orangepi 4

TonyMac32 · February 17, 2020

@Neil Armstrong looks like kernel troubles. I only see AXG and G12a changes in there, but I haven't dug in.

Sent from my Pixel using Tapatalk

lanefu · February 18, 2020

Hi... so good news.... it IS one of these patches thats the problem https://github.com/armbian/build/tree/master/patch/kernel/meson64-current . i built without patches and it booted

When I said i tested earlier.. i lied... ( I always get meson64 and mvebu64 mixed up) :wacko:

lanefu · February 18, 2020

looks like culprit is https://github.com/armbian/build/blob/master/patch/kernel/meson64-current/meson64_fclk_div3.patch

doing some more tests to confirm

lanefu · February 18, 2020

okay i disabled that patch in the v20.02 repo... was able to build a working le potato desktop.... Audio is overdriven, but i think thats a known issue... there are _other_ issues with building le potato in master. i'll start a seperate thread for that.

TLDR; we can build le potato from v20.02 now with kernel 5.4.20

Igor · February 18, 2020

3 hours ago, lanefu said:

TLDR; we can build le potato from v20.02 now with kernel 5.4.20

Nice!!

Since I already pushed a workaround this can wait ... Lets do a mini update in a two weeks since I am sure we will find more bugs.

guidol · February 18, 2020

16 hours ago, lanefu said:

check out the branch direclty and try what i said here

should we now use

git fetch
git checkout v20.02
sudo ./compile.sh FORCE_CHECKOUT=no

because on twitter #armbian did tell that v20.02 has been released today:

Quote

Armbian 20.02 Chiru released!
https://docs.armbian.com/Release_Changelog/ : 20.02.2 / 18.2.2020 Chiru

@cnxsoft @ElectromakerIO @nixcraft @latenightlinux

Heisath · February 18, 2020

I am confused now.

#armbian tells us that v20.02 has been released.

Where was the release date 28.02. defined? First post in this thread still says "Release Date: 2020-02-?? (will update thread)".

Is it always going to be ~1month after feature freeze? Probably.

How does work continue now? Does somebody port fixes from 20.02 to master?

I assume we will continue development on master so it would make sense, to get all fixes from 20.02 over to it.

What happens with rc0 and rc1 ? Just stale and delete at some point?

Regards,

count-doku

lanefu · February 18, 2020

1 hour ago, count-doku said:

armbian tells us that v20.02 has been released.

Where was the release date 28.02. defined? First post in this thread still says "Release Date: 2020-02-?? (will update thread)".

Is it always going to be ~1month after feature freeze? Probably

Surprise! About a month is what we're shooting for. Sorry for the poor communication. We're still learning how to manage this process. Ideally we will start a bit earlier and release closer to the beginning of the month

1 hour ago, count-doku said:

How does work continue now? Does somebody port fixes from 20.02 to master?

I assume we will continue development on master so it would make sense, to get all fixes from 20.02 over to it.

Master will continue on as a rolling release. You'll see that its version is already v20.05-trunk on master.

Relevant fixes applied to v20.02 going forward should be cherry-picked to master. Although so far we've actually been cherry-picking fixes from master to v20.02.

Going forward we'll update v20.02 for major bugs and stability issues until v20.05 is released.

rc0 and rc1 branches will be deleted. Rc1 ended up being a rolling branch this time. Not sure how we'll handle this next time. A lot will be on how manage publishing test images.

lanefu · February 18, 2020

3 hours ago, guidol said:

because on twitter #armbian did tell that v20.02 has been released today:

If you want to build a "stable" image from the same code as the images we publish use v20.02 branch.

If you want to build "unstable" image with latest and greatest us master branch.

guidol · February 18, 2020

1 hour ago, lanefu said:

If you want to build a "stable" image from the same code as the images we publish use v20.02 branch.

If you want to build "unstable" image with latest and greatest us master branch.

will try stable

but git switched to v20.02 only with the -b option (64bit Bionic armbian-build-system):
git checkout -b v20.02

without -b it gave me an error

(but should be working on newer git versions: https://stackify.com/git-checkout-remote-branch/ )

lanefu · February 18, 2020

13 minutes ago, guidol said:

but git switched to v20.02 only with the -b option (64bit Bionic armbian-build-system):
git checkout -b v20.02

without -b it gave me an error

(but should be working on newer git versions: https://stackify.com/git-checkout-remote-branch/ )

hmm... -b may have created a local branch named v20.02 instead of what you wanting..

did you do a get fetch?

may need to do git check out origin/v20.02

guidol · February 18, 2020

14 minutes ago, lanefu said:

did you do a get fetch?

yes I did...

root@core2duo(192.168.6.19):/home/guido/build# git fetch
root@core2duo(192.168.6.19):/home/guido/build# git checkout origin/v20.02
error: pathspec 'origin/v20.02' did not match any file(s) known to git.

lanefu · February 18, 2020

24 minutes ago, guidol said:

yes I did...

root@core2duo(192.168.6.19):/home/guido/build# git fetch
root@core2duo(192.168.6.19):/home/guido/build# git checkout origin/v20.02
error: pathspec 'origin/v20.02' did not match any file(s) known to git.

whats git branch -vva

say

Heisath · February 21, 2020

Suggestion for future releases: On the release date / once it's released make a topic in Announcements telling people of the new release. Or is Twitter now the main way to communicate such things?

guidol · February 21, 2020

On 2/18/2020 at 7:07 PM, lanefu said:

whats

git branch -vva

say

/home/guido/build# git branch -vva
* master                caf429b [origin/master] Add Orangepi 4 build targets
  origin/v20.02         caf429b Add Orangepi 4 build targets
  v20.02                caf429b Add Orangepi 4 build targets
  remotes/origin/HEAD   -> origin/master
  remotes/origin/master caf429b Add Orangepi 4 build targets

Icenowy · February 21, 2020

@Igor I found why anx6345 mainlined in 5.5 doesn't work on TERES-I.

https://github.com/Icenowy/linux/commit/e20b4f7fade6a7305599aa8e279c013c3144226b an overflow bug.

Igor · February 21, 2020

6 hours ago, count-doku said:

Or is Twitter now the main way to communicate such things?

I would say both at the same time? Whatever we are agreed upon, we are documenting here https://github.com/armbian/documentation/blob/master/docs/Process_Release-Model.md that we have a better process plan for next release.

41 minutes ago, Icenowy said:

I found why

Thanks, noted. BTW. It seems my Teres have some hardware issues

lanefu · February 21, 2020

FYI I am working to document things that went wrong / improvement areas... so please share those thoughts on this thread.

chwe · February 21, 2020

19 minutes ago, lanefu said:

I am working to document things that went wrong / improvement areas

the RCs should be 'somehow' predictable.. e.g. for the linux kernel you know it's monday morning (europe) when the next one drops in
how many RCs we have mostly depends on how smooth things go.. so it is possible that the releasedate is not always 100% clear.. I guess it's up to the release maintainer to decide when things are mature enough, but maybe we need a few 'must haves' and a few 'this will delay' defined (means if, it's important enough that it will delay a release)..
the images which are finally released should be somehow reproducible.. something like ./compile.sh $RANDOM_FANCY_VARIABLE=release_2002 and it fetches exactly the sources which were used to produce the release (either over the armbian repo/sources) or by commit hash (which can be problematic from time to time, ask @TonyMac32 and the story of rockchip). So that someone who wants to build a 'know working' (in case it was tested for the board in question) image can build and patch on top of the release..
except the commits which alternate the rc numbers in the buildscript rc's should IMO have no commits which are not available in master as well so that after the release we can go 'back to work' without a discussion what we've to cherry pick from the release to work on master, this also means if someone wants to bring up a fancy feature during rc this must imo kept 'on hold' until the release is here.. Otherwise we end in the same mess as we had between master and our 'development' branch and all other attempts to have a 'stable' branch..
for sure stuff I didn't thought about yet..

JMCC · February 21, 2020

3 hours ago, lanefu said:

please share those thoughts on this thread

Well, I don't want to point out something that went wrong, but on the contrary I want to emphasize all the things that went well. Having been disconnected from Armbian for some months, I can see a major improvement in the project's organization. Things like a predictable release cycle, tagged repo with all the releases, scheduling and coordinating, bug tracking... I can see a lot of work has been put into it, and IMO the results are excellent.

So a big congrats to everyone who took part on it! Great job! :thumbup:

lanefu · February 22, 2020

9 hours ago, guidol said:


/home/guido/build# git branch -vva
* master                caf429b [origin/master] Add Orangepi 4 build targets
  origin/v20.02         caf429b Add Orangepi 4 build targets
  v20.02                caf429b Add Orangepi 4 build targets
  remotes/origin/HEAD   -> origin/master
  remotes/origin/master caf429b Add Orangepi 4 build targets

Hey Sorry. @TonyMac32 and I came across this issue the other day.. There's a second step needed.... create a file in your build filed called .ignore_changes

I've updated the FORCE_CHECKOUT section of the documentation

touch .ignore_changes

lanefu · February 22, 2020

2 hours ago, JMCC said:

Well, I don't want to point out something that went wrong, but on the contrary I want to emphasize all the things that went well. Having been disconnected from Armbian for some months, I can see a major improvement in the project's organization. Things like a predictable release cycle, tagged repo with all the releases, scheduling and coordinating, bug tracking... I can see a lot of work has been put into it, and IMO the results are excellent.

Hey thanks for the positive feedback! It's super helpful to know what went well too. I'm really glad you were able to see so many improvements.

lanefu · February 22, 2020

4 hours ago, chwe said:

the RCs should be 'somehow' predictable.. e.g. for the linux kernel you know it's monday morning (europe) when the next one drops in

how many RCs we have mostly depends on how smooth things go.. so it is possible that the releasedate is not always 100% clear.. I guess it's up to the release maintainer to decide when things are mature enough, but maybe we need a few 'must haves' and a few 'this will delay' defined (means if, it's important enough that it will delay a release)..

Yes. We definitely need to figure out when to cut a release, when to increment, what a RC version number means, etc. -rc1 was really a rolling release branch this time. AR-176

4 hours ago, chwe said:

the images which are finally released should be somehow reproducible.. something like ./compile.sh $RANDOM_FANCY_VARIABLE=release_2002 and it fetches exactly the sources which were used to produce the release (either over the armbian repo/sources) or by commit hash (which can be problematic from time to time, ask @TonyMac32 and the story of rockchip). So that someone who wants to build a 'know working' (in case it was tested for the board in question) image can build and patch on top of the release..

I really see that as 2 parts.

* Make building alternate armbian build branches easier.

* Make upstream dependencies consistent.

Both are important, I think the first is a higher priority. AR-176

4 hours ago, chwe said:

except the commits which alternate the rc numbers in the buildscript rc's should IMO have no commits which are not available in master as well so that after the release we can go 'back to work' without a discussion what we've to cherry pick from the release to work on master, this also means if someone wants to bring up a fancy feature during rc this must imo kept 'on hold' until the release is here.. Otherwise we end in the same mess as we had between master and our 'development' branch and all other attempts to have a 'stable' branch..

I partially agree with this. All features in an RC should exist in master--first. Bug fixes no. If a bug fix obviously will improve master, then yes it can be cherry-picked, But the primary purpose of bugfix is to assure the stability of the release. Simple Example.. we add a patch to a release on 5.4 kernel... master has moves to 5.5... may not make sense.

In practice---during this release we ended up cherry-picking most fixes from master and into the RC branch.

Heisath · February 22, 2020

5 hours ago, lanefu said:

* Make building alternate armbian build branches easier.

Is this not easily possible by using LIBTAG parameter? Or does it not work anymore?

Apart from the final release confusion I'd also totally agree with JMCC this release process was way better than older ones.

guidol · February 22, 2020

2 hours ago, count-doku said:

Is this not easily possible by using LIBTAG parameter? Or does it not work anymore?

I did try LIB_TAG="v20.02-rc1"

but also did get a compiled v20.05-trunk

lanefu · February 25, 2020

@Igor https://github.com/armbian/build/blob/v20.02/VERSION still shows v20.02.0. Do you need to push up some of your local updates to v20.02?

Igor · February 25, 2020

5 hours ago, lanefu said:

Do you need to push up some of your local updates to v20.02?

Yes, forgot. https://github.com/armbian/build/commit/24013582eba4ad3300d0996cf9afa3dde8513327

Sign In

Armbian 20.02 (Chiru) Release Thread

Recommended Posts

Igor

TonyMac32

Igor

TonyMac32

lanefu

lanefu

lanefu

Igor

guidol

Heisath

lanefu

lanefu

guidol

lanefu

guidol

lanefu

Heisath

guidol

Icenowy

Igor

lanefu

chwe

JMCC

lanefu

lanefu

lanefu

Heisath

guidol

lanefu

Igor

Forums

My Activity Streams

Download

Store

Important Information