Jump to content

Armbian 20.02 (Chiru) Release Thread

lanefu

By lanefu
in Armbian build framework

 Share

Recommended Posts

Igor

Igor

Posted
Posted
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.

1
Link to comment
Share on other sites
TonyMac32

TonyMac32

Posted
Posted
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?

Link to comment
Share on other sites
Igor

Igor

Posted
Posted
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 :)

Link to comment
Share on other sites
lanefu

lanefu

Posted
  • Author
Posted

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

Link to comment
Share on other sites
Igor

Igor

Posted
Posted
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.

Link to comment
Share on other sites
guidol

guidol

Posted
Posted
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

 

 

Link to comment
Share on other sites
Heisath

Heisath

Posted
Posted

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

 

 

Link to comment
Share on other sites
lanefu

lanefu

Posted
  • Author
Posted
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.

1
Link to comment
Share on other sites
lanefu

lanefu

Posted
  • Author
Posted
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.

1
Link to comment
Share on other sites
guidol

guidol

Posted
Posted
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/ )

Link to comment
Share on other sites
lanefu

lanefu

Posted
  • Author
Posted
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

Link to comment
Share on other sites
guidol

guidol

Posted
Posted
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.
 

Link to comment
Share on other sites
lanefu

lanefu

Posted
  • Author
Posted
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

Link to comment
Share on other sites
  • lanefu unfeatured this topic
guidol

guidol

Posted
Posted
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

 

Link to comment
Share on other sites
Igor

Igor

Posted
Posted
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 :(

Link to comment
Share on other sites
chwe

chwe

Posted
Posted
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..
1
Link to comment
Share on other sites
JMCC

JMCC

Posted
Posted
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:

2
Link to comment
Share on other sites
lanefu

lanefu

Posted
  • Author
Posted
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

 

1
Link to comment
Share on other sites
lanefu

lanefu

Posted
  • Author
Posted
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.

Link to comment
Share on other sites
lanefu

lanefu

Posted
  • Author
Posted
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.

1
Link to comment
Share on other sites
Heisath

Heisath

Posted
Posted
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. 

1
Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept