Jump to content

Weekly developers meetup

Community Calendar

Event details

This week meeting topics:


1. Progress of CI support

2. Mechanism for rebuilding packages from sources 

3. Misc



General goal of weekly meetings:


  • To discuss the three (3) issues of the week
  • Discussions will be documented to respective Jira tickets so they can be tracked
  • Three (3) new issues will be selected from Jira for the next meeting


The purpose of a weekly developers meeting is to coordinate development of the build engine, continuous integration, operating system features and low level support. Meetings are hosted located on Zoom (Video) and IRC and Discord (Text). While  we would prefer you attend on Zoom when possibly, we  will also monitor text chat during the call for those unable to join Zoom.  Please RSVP either way.


Do you want to participate or help in some way?

Meetings are focused in developers top level topics and its expected that understand embedded software development, software testings or operating system management. In term of programming languages, knowledge of at least BASH & Python is expected.

Since meetings are held in public, any registered community member can join and listen. If you want to suggest issues for the next week, you have to be recognized Armbian contributor. If you want to become one, resolve at least one intermediate level issue and tell us something about you. This is needed to efficiently communicate and to give you access to our organisation infrastructure Jira, Github, hardware lab and servers.



Recommended Comments

The developers of Armbian abandoned the old mechanism, why?

What is the main reason?

It worked well and is working today for me.

It will be very interesting for me to look at the new algorithm in a descriptive way before it is implemented programmatically.

Link to comment
On 4/6/2023 at 10:28 AM, going said:

The developers of Armbian abandoned the old mechanism, why?

Can't say it was abandoned. Just its not used much and mechanism was not transferred to Armbian NEXT due to that fact that it was not mandatory and as it represent additional work.

Those paths needs to be discussed:

- moving to armbian next
- keeping as a standalone functionality

- something else

Link to comment
5 часов назад, Igor сказал:

something else


Before the mechanism is implemented and moves to the assembly system, it is necessary to ask a question, and who needs it and why.
If only to collect a small collection of packages for internal consumption by Armbian as the organization that distributes these packages, then this is one option. This option existed before.
If we plan to give the user the opportunity to build any package in a chroot environment or natively, then this is another goal. And it involves assembling several packages for internal consumption. But as part of a more general capability.


5 часов назад, Igor сказал:

Just its not used much


It was little used because it was hard coded to build multiple packages using configuration files. And it was always the same version of the package.


Igor, you know that I have redone it a little, and it is now in the master branch collecting packages in a clean environment every time.
Why is this the case? Because all the distributions I know do exactly that.
The build system, by its very nature, should provide some customization options and tools for the developer's work.

If this is not the case, the developer will find an alternative or redo the algorithm of the build script.


5 часов назад, Igor сказал:

keeping as a standalone functionality

There will always be poorly or not very well functioning packages that can be fixed.
And for this , there must be a  mechanism for building in the chroot environment.


I am developing it and it is becoming more functional.

Link to comment
14 hours ago, going said:

there must be a  mechanism for building in the chroot environment


http://mini-buildd.installiert.net/ would _more_ than fulfill our needs, and follows Debian standards. This takes *source* Debian packages, builds in chroots (cross-arch), and manages and deploys a repository. It would have to be _hosted_ somewhere.

This would produce some "armbian-bookworm-extra" repository (per $RELEASE, of course) with what I think should be mostly userspace things (although zfs-dkms is a special case).

The armbian/build managed repos would still exist, one global for all releases ("armbian-global", u-boot, kernels, ...) and then one per-release ("armbian-bookworm", with bsps, desktops, etc).



Link to comment
15 hours ago, going said:

there must be a  mechanism for building in the chroot environment


Another good option is the OpenSUSE original Open Build Service https://openbuildservice.org/, which has been adapted to work with Debian/Ubuntu by Collabora. 


Same applies, but this goes out of its way to simplify building packages "for all releases and all arches" from a single source.


Link to comment
1 час назад, rpardini сказал:

Another good option is the OpenSUSE

Hi Ricardo. This is my favorite service.
Do you suggest making a package in it for Armbian?

Link to comment

Probably OBS is best maintained, but overkill and complicated ?. Mini builds sounds nice but never seen it ...


What we need is: patch, recompile and host several packages per distribution. Starting with things like https://packages.ubuntu.com/jammy/base-files 

Repository management we have, so if this system throws out a deb we only make a translation to our schema ... 

Link to comment
3 часа назад, Igor сказал:

Probably OBS is best maintained, but overkill and complicated ?

The first problem is to make the source package and this must be done in the OS build environment.

When there is a properly working source package, and for debian these are several files, we can send them to any service for assembly. It does not matter in principle.
No one will do the manual work for us.


I am talking about providing the user with tools to work on creating source packages and then assembling them in the native environment, i.e. in the OS in which the binary package will be installed.



We are talking about the process of developing a package from source texts, and not about which service to build it on.



11.04.2023 в 18:50, Igor сказал:

keeping as a standalone functionality

this mechanism can exist completely independently, and can be invoked independently. The build system can use some parts of it for its tasks, but not vice versa.


Can we start discussing the algorithm?
I'm already doing something and I've done something.

Link to comment
6 hours ago, going said:

Hi Ricardo. This is my favorite service.
Do you suggest making a package in it for Armbian?


Dunno how well it translates to Russian, but might be worth watching https://youtu.be/aSMw_hvBYnw

OBS itself is already packaged in Debian: 

apt show obs-worker obs-server



2 hours ago, going said:

We are talking about the process of developing a package from source texts


Yes, but consider that that process is one-per-release. So we'd need to maintain 6+ packages/branches which is beyond our capacity and makes no sense. So we have to go "beyond" source packaging.

OBS has debtransform which can help with that. other option is git-buildpackage. there are others.

Also _most_ of what we'd need is or has _already_ a Debian source package in one way or another (openzfs, mesa, etc, or even just "adopting" ubuntu/debian packages from upstream and changing small things), so the real question here is the workflow and the tooling.



Link to comment
13.04.2023 в 00:59, rpardini сказал:

OBS itself is already packaged in Debian:

The most interesting thing about this is that the Armbian build system (what is in the lib folder) becomes unnecessary.

Only settings and patch folders are needed.
If I have OBS, then I need filling in the working directory to build packages.

And only this:


build> tree packages/deb-build/
├── htop
│   └── debian
│       ├── changelog
│       ├── control
│       ├── copyright
│       ├── docs
│       ├── install
│       ├── rules
│       ├── source
│       │   └── format
│       ├── upstream
│       │   └── metadata
│       └── watch
└── README.md

The "watch" file contains all the necessary information to download the source code archive.
One line of code is needed and the source package is ready in its expanded form.

One more line of code to collect the entire collection of binary and debian source packages.
Ricardo thanks for the tip.

Link to comment
3 hours ago, going said:

One line of code is needed and the source package is ready in its expanded form.



Yes, but keep in mind, if you wanna build the same package (say, htop) for _both_ bullseye _and_ jammy, you'll have possibly different build-dependencies (libraries etc), and different compilers, so you end up having to maintain one-package-per-distro which is what we're trying to avoid.

Some kind of generator / patcher / manager is needed to account for the (usually very small) differences between releases.

OBS has a bunch of tricks up its sleeve to do this.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Add a comment...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines