lanefu

I got a pack of these:  https://www.aliexpress.com/item/2031287967.html
USD 2.99.- (8 pieces/lot) back in 2017
 

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  

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

I'd like a fixed with font inside the spoiler.
 
Ugly inside spoiler
 
Pretty fixed width font in code block
 
 

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! 

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

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? 
 

Wow, you managed to solve it, can't wait to see your fix merged. Also, your suggestion to rollback the kernel works, now i have sound again while waiting your patch.
Thanks a lot for your blazing fast support and the effort employed to solve these problems. I would also like to contribute to development but i have not yet reached the necessary skill level.... for now :-)

I trying to use LUKS on an 5.5 Kernel on an H3 SOC with armbian. The  default cipher of luks currently is aes-xts-plain64 which is fine from a security point of view but as far as i understand the datasheet is not supported by allwinners CE.
I'm struggling to find a the correct cipher name for a aes-cbc mode that will be accepted by the luks and is supported by the kernel.
looking at the cryptsetup benchmark it seems non of the ciphers uses hardware acceleration or at least it is very slow. 
 

I've started the work of switching SUNXI-DEV to 5.6.y, as usual, few DT duplicates and fixes ...
But I've faced also a big change related to 'file_operations' been changed to 'proc_ops' in all places over the kernel, which cause that all our EXTRAWIFI needs to be fixed.
I hope to get it done by the end of this evening ...
 

My bad I found what was wrong in my case. I was using image for "Orange Pi +2E" but my board is "Orange Pi+ 2". Just tried correct image and now I see USB devices and problem with "armbian-config -> system -> hardware" has gone also.
 
I'm so sorry for the false alarm

thank you for the tip you gave me about the docker container.
I have successfully run the controller through Docker and it works perfectly.
The best thing about the Docker solution, I can quickly delete or renew the "installation".
 
docks@OrangePi:/opt/docker$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES dc14b6ce9fa3 linuxserver/unifi-controller "/init" 20 minutes ago Up 3 minutes 0.0.0.0:6789->6789/tcp, 0.0.0.0:8080->8080/tcp, 0.0.0.0:8443->8443/tcp, 0.0.0.0:8843->8843/tcp, 0.0.0.0:3478->3478/udp, 0.0.0.0:10001->10001/udp, 0.0.0.0:8880->8880/tcp, 8081/tcp unifi docks@OrangePi:/opt/docker$  

Being rude does not solve issues faster. However there ARE ways to accomplish this. Please consider studying the "Support" section here: https://github.com/armbian/build#support

https://oversun.jp/?p=55

apt install docker.io
 
then read some of the documentation here https://docs.linuxserver.io/general/containers-101

the OS mongo packages are usually super outdated, not surprised they don't work.
 
Consider this container.  the linuxserver.io project builds multiarch containers for arm32, arm64, and x86.

https://hub.docker.com/r/linuxserver/unifi-controller

Echoing what Lanefu said, thanks for the info, and sorry about the rough edges!  A new set of sound patches have been submitted upstream, I will take a look at them and see if they can be used as a means of cleaning up our current implementation (targeted originally for 4.19).  
 
The memory limit seems to be a potential u-boot issue.  For the display, the Amlogic clock framework has been an ongoing project for mainline, with a lot of changes.  I will spend some quality time with everyone's favorite S905X board and get back to you.  🙂

Ok just upgraded to the new release of armbian.. thanks guys!!
 
I have done limited testing but so far this appears to works well (5.4.20) with no line droping, so great news!
 
Again thanks for producing Armbian.
JB

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.

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

That is fascinating.  Let me look over this stuff.
 
https://github.com/ARM-software/u-boot/blob/master/common/image.c#L1076
 
I think it's unrelated to the packaging of U-boot, probably more the packaging of the kernel.  Or I could be totally wrong, it's late
 

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.

Some bill printer device

check out the branch direclty and try what i said here
 
 

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

Ill take a look at kernel config again, but it seemed like it hasnt changed since we switched to mainline