schwar3kat

Thanks Werner, I initially misread it. Corrected it already.

You want to join Armbian chat rooms, but hate Discord and would prefer something more modern than IRC?
 
We got you! Join the closed beta of our own Matrix chat!
With this test we want to get an idea about the public interest in this and also check the load on infra this generates so we can scale accordingly.
 
Available (and bridged to IRC and Discord) channels:
#armbian-announcements:matrix.armbian.com
#armbian:matrix.armbian.com
More channels will be added on demand.
 
Invitation for the Armbian space: https://matrix.to/#/#armbian-space:matrix.armbian.com
 
While the announcements channels is open and join-able for everyone already, for the latter an invitation is necessary.
To get one simply ping @lanefu or me in this topic or via private message or via chat... doesn't matter
Or simply use Matrix directly: https://matrix.to/#/@werner:matrix.armbian.com
Once in feel free to invite other by yourself.
 
Registering accounts is not possible at this time. However we may grant such to our contributors on request.
 
 
 

Actions:
 
updating template for building standard support images. Keeping Jammy CLI and Jammy XFCE desktop, upgrade other Jammy to Noble. Keeping old stable user-land with more recent kernel is actually a perfect combination.  download pages were adjusted to current status. branching to 24.5 freezing sources merging all board status changes making RC builds updating application builds lists updating 3rd party packages import regenerating repository with Ubuntu oracular switching nightly build targets to Ubuntu oracular generating RC images for application deployments returning armhf to Noble / Trixie  
RC0 RC1 (is in making) for testing:

HomeAssistant, OpenHab, Security (Kali)
https://github.com/armbian/distribution/releases/tag/24.5.RC0 

Nightly images
https://github.com/armbian/os/releases/tag/24.5.0-trunk.580 
 
Stable builds (RC)
https://k-space.ee.armbian.com/incoming/ https://fi.mirror.armbian.de/incoming/  
Automated testings
https://github.com/armbian/os?tab=readme-ov-file#latest-smoke-tests-results
 
Report:
- problems

Suggest:
- images that needs to be added, changed status
 
@Contributor/Maintainer

https://fi.mirror.armbian.de/.meeting/devmeeting_2023-09-06T17_46_27.885Z-subbed.mp4

There are and they are stored here unless it is forgotten to record: https://fi.mirror.armbian.de/.meeting
 
Once you RSVP the link will direct to the meeting. No further instructions needed.

Thank you very much for this info schwar3kat!

@schwar3katI'm using kernel 5.10.160-rk35xx kernel now. And I can see wideviine is detected on website https://bitmovin.com/demos/drm by chromium.
From chrome://components/ I can see widevine is enabled.
I haven't tried kodi.

Having used YOCTO for a couple of years at work I assumed that creating my own Armbian image was going to be difficult. However to my suprise I was able to create a Bullseye image for the Orange Pi R1+ LTS in less than 1 hour. And, .... it actually runs correctly on the target board. That is pretty good.

- Orange Pi PC
- Pine64
Images boot (xfce_desktop), network connection functions (iperf3). USB ports function, HDMI video and audio work.

I couldn't reproduce the problem, after deleting `cache/tools/oras`, even with CLEAN_LEVEL=debs ARTIFACT_IGNORE_CACHE=yes.
I deleted the whole cache and was able to reproduce it.
EDIT:  deleting cache/tools/oras. does reproduce the error.  Not sure why I didn't get the same result earlier.

https://github.com/armbian/build/issues/4889

https://github.com/armbian/build/issues/4879

@rpardini
Next/main. Creating patches.
 
When I create a patch with armbian/build master (deprecated) using  CREATE_PATCHES=yes, I get a patch in the output/patch folder in mbox format.
When I create a patch with armbian/build main using  CREATE_PATCHES=yes ARTIFACT_IGNORE_CACHE=yes, I only get a diff file in the output/patch folder.

Is this intentional, a bug, or have I perhaps not set something up?  Can I get a mbox patch?

Orangepi-r1 tested success:
Armbian_23.02.1_Orangepi-r1_bullseye_current_5.15.93.img.xz
Armbian_23.02.1_Orangepi-r1_bullseye_current_5.15.93_minimal.img.xz
Armbian_23.02.1_Orangepi-r1_jammy_current_5.15.93.img.xz
 
All images tested and working as expected.
Iperf performance is as expected in both directions on both ethernet ports simultaneously.
Wifi works.
2 images listed on RC testing form (minimal build left off).

Orangepizeroplus tested success:
Armbian_23.02.1_Orangepizeroplus_bullseye_current_5.15.93.img.xz
Armbian_23.02.1_Orangepizeroplus_bullseye_current_5.15.93_minimal.img.xz
Armbian_23.02.1_Orangepizeroplus_jammy_current_5.15.93.img.xz
 
All images tested and working as expected.
Iperf performance is as expected in both directions on ethernet and wifi ports simultaneously.
2 images listed on RC testing form (minimal build left off).

Orangepi-r1plus-lts tested success:
Armbian_23.02.1_Orangepi-r1plus-lts_bullseye_current_5.15.93.img.xz
Armbian_23.02.1_Orangepi-r1plus-lts_bullseye_current_5.15.93_minimal.img.xz
Armbian_23.02.1_Orangepi-r1plus-lts_jammy_current_5.15.93.img.xz

All images tested and working as expected. 
Iperf performance is as expected in both directions on both ports simultaneously.
2 images listed on RC testing form (minimal build left off).

Yep, I worked on that a few months ago. We've something like `./compile.sh distccd` which starts a distcc daemon, complete with zeroconf etc, using the same toolchains Armbian would.
Something else (forget what) enables it to be used on a controller node. You do need a bigger controller machine, say 8-cores, to completely max out some two/three 4-core distccd's, due to the high preprocessing load.
The network between the machines has to be very good, too (gigabit+). All in all is a "fun" way to use all those SBCs laying around doing nothing, but don't expect something miraculous...
One day I'll finish / document this...
 

I would recommend that you first start with a pre-built image (https://www.armbian.com/orange-pi-pc) Then if you want use the armbian build system (https://docs.armbian.com/Developer-Guide_Build-Preparation/)
Then you might be able to track down why the Debos isn't working as you think it should. 

Hi Namexx
 
If you have anything plugged into the USB port, try it without.

There are some home  routers that only do IPv4 some are known to cause issues if IPv6 is enabled.
If you are on  network using IPv4 then you can try adding a line into /boot/armbianEnv.txt
extraargs="ipv6.disable=1"

I'm traveling at present, but when I get home, I will download an image and test on my board.  
Which image are you using, and how are you flashing it to SD card?

I tested the current build successfully when it was released, but it's always possible that something has gone wrong since then.

Edit:  I was very lucky and got an earlier flight.  I should be back home about one or two hours.

https://docs.armbian.com/User-Guide_Basic-Troubleshooting/

Yeah, parsing the patches includes being able to decode them.
Patches should match the encoding of the target patched source; In this case, it's UTF-8.
In my view, those patches are mangled (not just "in big5"): the original encoding was lost due to copy/pasting, and they're already (in master) putting frakked up characters in the source code.
So it can't get worse, but now I warn you about the error.
 
 

What I am observing here is not a lack of support for this particular armhf architecture.
This is an incorrectly constructed construction algorithm in the assembly system itself.
The analysis of the architecture that needs to be built and the architecture on which the build system started working looks pretty trivial and it already exists.
To do this analysis and upload only what is required for this task does not look like something complicated.

P.S. This also applies to the master.

@rpardini one of the actions on the slides: "testing on other architectures (armhf, riscv64)"

 😀 For a lark, I thought I would give it a try on armhf, seeing as I have access to an orangepi-pc running Armbian Jammy
I mounted an external drive on it.
Armbian-next build was not successful, and because I don't think that armhf is a significant option, I didn't try too hard but here are the results. 
I suspect that the gcc-riscv64-linux-gnu package could be excluded if not cross compiling to riskv64, but I didn't investigate further.

First, I tried the same method that  I used on Intel, and it failed:
[🌱] Preparing [ host ]
[🌿] Please read documentation to set up proper compilation environment
[🌿] https://www.armbian.com/using-armbian-tools/
[💥] error: Running this tool on non x86_64 or arm64 build host is not supported  [  in prepare_host() at /mnt/storage/armbian-build/armbian-next/build/lib/functions/host/prepare-host.sh:63 ]
[💥] Build terminating... wait for cleanups...

I added this into lib/functions/host/prepare-host.sh at line 60 to include armhf in the permitted architectures:
    elif [[ $(dpkg --print-architecture) == armhf ]]; then
        :

Native build failed again:
[👉]    Package gcc-riscv64-linux-gnu is not available, but is referred to by another package.
[👉]    This may mean that the package is missing, has been obsoleted, or
[👉]    is only available from another source
[👉]    E: Package 'gcc-riscv64-linux-gnu' has no installation candidate
[👉]    --> 🧽   28: 13096 - 13096 - 13096: hBE: trap: main_trap_handler [ ERR and 100 trap_manager_error_handled: short_stack:/mnt/storage/armbian-build/armbian-next/build/lib/functions/logging/runners.sh:186 ]

I installed docker:
Docker build failed for the same reason:
[👉]    Get:18 http://ports.ubuntu.com/ubuntu-ports jammy-security/universe armhf Packages [491 kB]
...
[👉]    Package gcc-riscv64-linux-gnu is not available, but is referred to by another package.
[👉]    This may mean that the package is missing, has been obsoleted, or
[👉]    is only available from another source
[👉]    E: Package 'gcc-riscv64-linux-gnu' has no installation candidate

@rpardini armbian-next - repeat build string at the end of the build process leaves out build options, BOARD=...
and NO_APT_CACHER=... (although armbian build master also leaves out NO_APT_CACHER ) and possibly others.

I would probably expect that all defined options would be included?

Original test build string (with desktop and base configuration selected through dialog):
./compile.sh BOARD=pine64 BRANCH=current RELEASE=jammy BUILD_MINIMAL=no BUILD_DESKTOP=yes KERNEL_CONFIGURE=no CREATE_PATCHES=no NO_APT_CACHER=yes
 
Repeat build string returned at the end of the build process ("BOARD=pine64" and "NO_APT_CACHER=yes" are missing):
[✨] Repeat Build Options [ ./compile.sh   BRANCH=current RELEASE=jammy BUILD_MINIMAL=no BUILD_DESKTOP=yes KERNEL_ONLY=no KERNEL_CONFIGURE=no DESKTOP_ENVIRONMENT=xfce DESKTOP_ENVIRONMENT_CONFIG_NAME=config_base DESKTOP_APPGROUPS_SELECTED="3dsupport browsers chat desktop_tools editors email internet multimedia office programming remote_desktop" COMPRESS_OUTPUTIMAGE=sha,gpg,img ]

I would also not expect COMPRESS_OUTPUTIMAGE=sha,gpg,img to be included (although no harm in including it).

@rpardini When a file has been changed in the local branch being built then master armbian-build provides a useful warning about not being able to update with a dialog to abort, continue or view changes before building.  

Personally I find this function to be a very useful reminder and would like to see it in armbian-next.

Hmm, I don't think I changed anything regarding this -- yet.
Currently the patches-hash and the real (6.1.3 etc) version of the kernel is not included in the deb filename/version. (it's static, "trunk123" or "23.02" etc).
And if the deb already exists, the build is skipped.
Hopefully soon we will include the patches-hash and the kernel version in the deb/filename, so the build detects the .deb is out of date and builds again.

Thanks for the effort Ricardo.
I'm not sure that accommodating is perhaps the best option. 
Just change supported versions should do the trick.
If the versions supported did not include una then users would know to upgrade.

I will test your changes but then I should probably upgrade to 21.1 vera.