Weekly developers meetup

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.

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

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.

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

 

 

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. 

https://en.opensuse.org/openSUSE:Build_Service_Debian_builds

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

 

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?

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

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.

 

@rpardini

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.

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.

 

 

Also: if Launchpad PPAs supported Debian this discussion would not exist, so yeah, it's all about the tooling.

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

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.