armbian-next development

[balbes150]

I'm shocked at what the build system is turning into. Due to the very poor work of logging, the load on the input/output system jumped by 40%  (this is an idiotic recording of useless information in a bunch of files), while important information was no longer displayed on the screen (the process of applying kernel patches, u-boot, etc.). If you don't know how best to keep logs, completely disable them in the default state (when the system is cloned by a regular user and runs a simple build). Logs are enabled exclusively and only through a variable that needs to be changed manually or added to the build command line. Again , a bunch of useless junk is being dragged - a compiler for riscv . cross compilers (with native build), shit with pete (DEV stuff that is not needed at all for the build system, standard BASH is enough).

[Igor]

1 hour ago, balbes150 said:

while important information was no longer displayed on the screen (the process of applying kernel patches, u-boot, etc.)

Agree, I already opened a ticket:

https://armbian.atlassian.net/browse/AR-1454

 

1 hour ago, balbes150 said:

Logs are enabled exclusively and only through a variable that needs to be changed manually or added to the build command line.

 

Current state of logging is terrible on the other end while if something breaks, logs can help to diagnose - the more the better. Perhaps we could introduce better levels of logging? Dunno how hard this is from current perspective?

 

1 hour ago, balbes150 said:

a compiler for riscv . cross compilers (with native build), shit with pete (DEV stuff that is not needed at all for the build system, standard BASH is enough).

Cross compilation is one of the core tool advantages - removing would be a mistake. The rest I can't comment as I didn't study enough yet.

[balbes150]

1 час назад, Igor сказал:

Agree, I already opened a ticket:

I suggest by default (without manual activation) - direct all the activity of the build system to the screen (to the build console \ SSH) . Only the basic steps should be recorded in the log (approximately as it is done now to control the overall assembly process). This will significantly relieve the input/output system from useless resource consumption (recording time, media resources, etc.). I compared the assembly process of the same on the Master and NEXT versions. The device is the same (4OZU\32eMMC), the system is the same clean installation). The difference reaches 20-30% in time. I think the reason is that NEXT devours a lot of resources for logging (with small RAM, intensive swap of all operations). The funny thing is that the user does not see any progress on the screen (by the way, this may cause a feeling that the system is frozen), but there is an active write / read inside. Logs should be included as a separate option and preferably with a depth level setting (approximately, as it is set at the start of the kernel, the degree of intensity of data output to the log).

 

1 час назад, Igor сказал:

Cross compilation is one of the core tool advantages - removing would be a mistake.

It's about the correct setup, what to install (which tools) and not to clog the system with junk unrelated to this option assembly. Now this is implemented in MASTER, do not load cross compilers if the native assembly is running. Install compiler packages strictly for the architecture on which the process is running for the version that is being built.  

For example, I have now started building only the kernel for P2. The system is 3.3 GB, a clean system, only cloned GIT NEXT, before starting the build process. After completion, 16 GB is occupied. Even taking into account the source code of the kernel and u-boot (and compiled objects) - too much for the simplest build system, almost 12 GB only for "servicing" libraries and compilers.

[going]

It looks like this discussion is starting to resemble a discussion of the basic algorithm of the build system?

 

In that case, I will express my opinion.
What does an ordinary Linux OS user do when he needs to rebuild a package with his fixes?

It downloads the source package. It updates the original source code to a newer one and applies its own fixes.

He collects packages. With this build procedure, it only needs dependencies for this package.

I hope you understand me.

[balbes150]

I decided to look at the log, on the subject of how patches were applied, how the kernel assembly went. Wow ... I haven't seen such shit yet, an absolutely useless log. By the way, one file, the size of megabytes, and to find something in it, you need to spend a lot of time. At the same time, some of the patches did not even apply, but the build system reported to me with cheerful green lines that everything was fine, the core was assembled as needed.

[going]

Today we don't know how to build source packages.
The one that exists for the kernel is not valid.

[Igor]

12 minutes ago, balbes150 said:

It's about the correct setup, what to install

Yes of course. I can say that current focus is optimisation for running as stable as possible and running within CI. We need to have this phase in near to perfect state before heading to optimising it for low resource systems. There are bugs that needs to be discovered and fixed before we proceed. I would suggest that for those ideas simply simply open a ticket. 

 

2 minutes ago, going said:

It downloads the source package. It updates the original source code to a newer one and applies its own fixes.

 

Our build system contains configurations, build lists, helper tools, speak multi arch, speak multi branches, supports different underlying packages assemblies, can be assembled on different arch, have many levels of caching ... acts like a giant compiler and linker. Perhaps a bit philosophical

[going]

2 минуты назад, Igor сказал:

I would suggest that for those ideas simply simply open a ticket. 

We need to describe the basic algorithm that we should approach. Then individual developers will not move in different directions.

 

 

[Igor]

1 minute ago, going said:

We need to describe the basic algorithm that we should approach. Then individual developers will not move in different directions.

1. Feature implementation is different and you don't like it - propose changes (if its questionable, we vote), task if small, story if big

2. Something doesn't work - bug ticket

3. Feature is missing - describe what you are missing (task if small, story if big)

 

You mean this?

[going]

6 минут назад, Igor сказал:

Our build system contains configurations, build lists, helper tools, speak multi arch, speak multi branches, supports different underlying packages assemblies, can be assembled on different arch, have many levels of caching ... acts like a giant compiler and linker. Perhaps a bit philosophical

The target for all these features should be the source package. Next, we simply send it to a pre-deployed clean build environment and assemble binary packages.

 

 

6 минут назад, Igor сказал:

1. Feature implementation is different and you don't like it - propose changes (if its questionable, we vote), task if small, story if big

2. Something doesn't work - bug ticket

3. Feature is missing - describe what you are missing (task if small, story if big)

 

You mean this?

These are the details. I mean a more complex process.
For example, we discuss and then describe in the documentation how the process of creating a log file and displaying it on the screen should look like. The developer who implements the new function reads this file and writes the code in such a way that the log looks as required in the documentation. Even if something is done in a completely different way in existing functions.

[Igor]

34 minutes ago, going said:

we discuss and then describe in the documentation how the process of creating a log file and displaying it on the screen should look like.

Aha you mean like having a proper "software design" phase ...

 

Currently we have "I have an idea and will work on" and we want to have some process: idea -> discussion / developers meetings / comment on that / co-design -> Jira story (or a plain document). And repeating those cycles until we are happy. Then coding. Yes, that would be ideal. The problem is that all this planning require a lot of resources we don't have. Ideally we would have a dedicated manager of software development. I am now doing this, running a business, doing paperwork. I am forced to improvise, make things on a "best effort" way.

 

I hope that we will implement design mechanism into developers meeting and after. But at this stage we have a large branch of a build system that was not designed together, but is based on common design.

[rpardini]

On 1/8/2023 at 8:34 AM, going said:

I do not approve of the presence of any script automating the patch conversion process in the build system itself. This can only be as an additional utility designed exclusively for manual use.

 

Yes. It is a process that requires human. What I automated is the boring part, so the human only has to use the eye at the end of it. At least for trivial rebases.

It is part of the Python patching system, but only used if invoked manually by a developer. Don't worry.

 

[going]

1 час назад, Igor сказал:

The problem is that all this planning require a lot of resources we don't have.

The problem is that these two people @rpardini, @going develop and implement some algorithms, each in their own sandbox.

And this work is not coordinated in any way. When it comes time to show it to the whole community, problems begin.

Agree Igor, the time has already been spent. And we have to rework the code. And this is time again.

It takes less time to discuss and write documentation.

[rpardini]

2 hours ago, balbes150 said:

I haven't seen such shit yet,

 

Great, very mature. Congratulations. Keep adding value by doing this, instead of writing 2-3 lines of text contributing something. 

 

 

[rpardini]

2 hours ago, going said:

The target for all these features should be the source package

 

Hmm. Yes. This is how buildd / debuild / Launchpad works.

You create a source package (a .dsc, .changes file) including the pristine source in a .tar, then the "debian" packaging source.

Then you build it with "debuild" or "dpkg-buildpackage".

This would be great, but is very different from what we do now, won't support cross-compilation, and thus requiring native iron to build any package.

It also requires release-specific packages, even for thing that aren't really release-specific (say, firmware).

So yes, this is maybe for 2024.

[rpardini]

14 hours ago, schwar3kat said:

Summary of actions that were required to prevent errors from aborting the build:

 

Awesome. I just pushed `8a2f30f4a1d648c4e15df5944241e80847bc8f78` with:

 

14 hours ago, schwar3kat said:

This behaves like current armbian-build and ignores errors caused by ntpd using the port.

 

Fixed; I check if the pidfile for ntpd is there, and if so, skip it completely, saving us 2 seconds. Even if not skipped, I added the "|| true" so it won't fail for any reason. https://github.com/armbian/build/commit/d42d340f48848126abb571b389b65d68a1732da4

 

14 hours ago, schwar3kat said:

freespace

 

Fixed (hopefully), I just added "|| true" -- there's work going on in master to avoid the double-mount and other bugs that might appear here, I'll wait for them. https://github.com/armbian/build/commit/e84d32785f8de4eab4763c120bd4c367d4ee6741

 

14 hours ago, schwar3kat said:

commit.gpgsign false

 

Added as a command-line option to the "git ... commit" invocation at that stage, so shouldn't fail anymore even if you have it enabled globally. https://github.com/armbian/build/commit/96926fbf4f8a1cb96dc18e4a4411f9fc3c594bec

 

14 hours ago, schwar3kat said:

a problem with something cached causing makefile corruption.  

 

This was due to a borked merge coming from master, was up for a few hours, sorry about this. (ref extrawifi)

 

8 hours ago, schwar3kat said:

I tried building with BUILD_DESKTOP=yes.
I expected a dialog to select which desktop and base config, but it aborted with an error.

 

Fixed. Another case of "let's ask the user" in the middle of configuration -- I had forgotten this. https://github.com/armbian/build/commit/1e53ac23a84c9135394dead7a0bf5ca8f8dfbf58

Please notice there's a known issue with desktop rootfs caching I am investigating.

 

Super thanks @schwar3kat for all the feedback and patience. 

[rpardini]

3 hours ago, balbes150 said:

Now this is implemented in MASTER, do not load cross compilers if the native assembly is running

 

You are delusional. `master` downloads & extracts 9gb of multiple different versions of Linaro etc toolchains before it eats any breakfast.

[going]

15 минут назад, rpardini сказал:

`master` downloads & extracts 9gb of multiple different versions of Linaro

lib/functions/host/prepare-host.sh

[rpardini]

55 minutes ago, going said:

ib/functions/host/prepare-host.sh

 

Yes, only if amd64. Oleg is about "only arm64".
I will thus stop all development and start endlessly bitching about "junk" and being useless.

[Igor]

2 hours ago, going said:

And this work is not coordinated in any way

I agree. I am trying to enforce needed coordination and structure by at least organising meetings, shuffling Jira tickets (this should be done by more people) provide tooling and am available for anyone from the team at any moment. At the same time I am trying to recognise / define our limits and scale it into the frame that is controllable. As too small resources provoke stress.

 

1 hour ago, rpardini said:

`master` downloads & extracts 9gb of multiple different versions of Linaro etc toolchains before it eats any breakfast.

 

Oleg builds his things on arm64, but we have to cover more, perhaps some stupid things for legacy reasons. We can't cut off blindly. I am totally aware that we are dragging 3/4 of those without any point, but someone has to remove them and be sure nothing is broken ... but since this falls off with the NEXT, why wasting time dealing with that?

 

Lets focus into seeking for solutions. And compromises. I am sure we will need to make some - our common goal is have the tool maintainable and modernised. And this is not a fixed thing - when better ways are found and if most of us agree that something can be removed, we remove. If not, its better to stay. There are people out there, that are using this build framework. We don't want to cause stress to them.

[rpardini]

1 minute ago, Igor said:

Oleg builds his things on arm64, but we have to cover more, perhaps some stupid things for legacy reasons. We can't cut off blindly. I am totally aware that we are dragging 3/4 of those without any point, but someone has to remove them and be sure nothing is broken ... but since this falls off with the NEXT, why wasting time dealing with that?

 

Lets focus into seeking for solutions. And compromises. I am sure we will need to make some - our common goal is have the tool maintainable and modernised. And this is not a fixed thing - when better ways are found and if most of us agree that something can be removed, we remove. If not, its better to stay. There are people out there, that are using this build framework. We don't want to cause stress to them.

 

I see. Let's then focus 100% energy of the whole team to cater to Oleg's specific wishes and needs until he is satisfied.

Also, let's give him his own family, let him arbitrary fuck up and duplicate code for no reason, enable Tegra on Rockchip family, etc etc,  and then in the end complain. When does it stop?

 

 

[Igor]

3 minutes ago, rpardini said:

I see. Let's then focus 100% energy of the whole team to cater to Oleg's specific wishes and needs until he is satisfied.

We have to leave personal preferences and grunches behind. The tool should be developed into the direction that this doesn't represent a problem. Since this tool was developed "as it goes", naturally, it has many design flaws. Which resulted in strange decisions. Lets remember that compromises were made out of necessity, lack of time, ...

We have to be constructive, improve communication, planning & coordination, ...

 

@balbes150 If a major redesign is needed on top of NEXT, we might need to deal with it later as otherwise we can't bring this in. If a design problem is recognised, open a Jira ticket and describe why you think this or that implementation is bad. If its a small change and if we are united, we will rework it at once, otherwise this will be put into back log.

Someone has a better idea?

[rpardini]

2 minutes ago, Igor said:

Someone has a better idea?

 

Yes, I have already started work on `armbian-oleg` -- it only builds media, only on arm64, and does not log anything.

[schwar3kat]

3 hours ago, rpardini said:

Fixed; I check if the pidfile for ntpd is there, and if so, skip it completely, saving us 2 seconds.

Works: skips it completely.
 

3 hours ago, rpardini said:

Fixed (hopefully), I just added "|| true" -- there's work going on in master to avoid the double-mount

Works.
 

3 hours ago, rpardini said:

Added as a command-line option to the "git ... commit" invocation at that stage, so shouldn't fail anymore even if you have it enabled

 

Works.

 

3 hours ago, rpardini said:

Fixed. Another case of "let's ask the user" in the middle of configuration

 

Works.

 

[schwar3kat]

On 1/7/2023 at 2:43 PM, rpardini said:

The gold standard (conveniently written in Python) previously known as "get-lore-mbox", now b4: https://b4.docs.kernel.org/

 

I have been thinking about this, and i acknowledge that I'm late to the conversation and very ignorant... 
It seems that this "gold standard" is aimed at creating and maintaining patches in a workflow that relies on distribution lists for code contributions and review.
And... yes, good well formatted and well described mbox patches would be fantastic in this context.

But it seems to me that this is not what we are dealing with. 
The build process is consuming already created patches from many developers, and what is required for a build is clean diff's.
I haven't been a part of the conversation, so maybe I'm missing something...  

From my admittedly very limited perspective.  
The build process should strip out the diff's and process them.  
There should be no checking of mbox formats at this point because the builder is not responsible for all other developers patches.

If we want to clean up mbox patches or verify patches before PR then this should possibly be a separate process that would not stop a build using existing patches.

In the build, perhaps something simple... like discard or ignore all content in the patch prior to the first diff, and then process.   Is this wishful thinking?

 

[rpardini]

2 hours ago, schwar3kat said:

The build process should strip out the diff's and process them.  
There should be no checking of mbox formats at this point because the builder is not responsible for all other developers patches.

 

Take a look at `patching.py` if you can muster, for context.

 

I am trying to strike a difficult balance: if the file passes a few tests (matching magic markers, unidiff well-formed, others) then I handle it as an mbox, and split them.

In certain conditions, as you mentioned, this fails, as is the case with heavily-mangled files, and the build refuses to continue, as an indication of "the bar has been raised, and xxxx patch doesn't pass".

 

In any case, the actual patches are being applied using the `patch` utility like always (so allow for fuzzy/offset, etc), and if it turns out half-decent patches is "impossible" (it isn't...) the code can be made to not split, and will then behave just like before.

We could do that per-family, especially for legacy stuff no-one wants to or will fix.

 

So let's strive to clean -- it's really not that hard (or what am I missing?). 

Later, we can add GitHub PR-level automatic checks for well-formed patches, thus "keeping" it clean for the future.

 

[schwar3kat]

1 hour ago, rpardini said:

So let's strive to clean -- it's really not that hard (or what am I missing?). 

 I agree that someone/we should strive to clean.  No argument with that.
Maybe during the armbian-next development period that is okay, but even then, it potentially drains resources from working on or testing armbian-next functionality.

My concern is that unless someone goes through every build possibility and cleans up associated patches even for the community, unsupported and legacy stuff for all archived versions, amateur builders could hit issues that they may not be able to deal with, and that could discourage them.

How about a compromise... a build option to override and allow the old way in case of patch issues (maybe with warning messages in case of bad patches)?

Another thought, how about a dialog when there is a bad patch, with the option to continue at your own risk or abort?

[Igor]

4 hours ago, schwar3kat said:

amateur builders could hit issues that they may not be able to deal with, and that could discourage them.

I also see this concern. Proceeding too strict could backfire in this regard. Build framework (master) is already too advanced for average Joe. Default build process has to remain looking simple. Also regarding patches - we have to expect users will throw in all sorts of garbage patches (exclude sanity check from /userpatches perhaps?) and we have to accept even not formed completely in order. Only we and pro users needs that we are reminded patches are not formed well, others not. Something that should be behind "EXPERT=yes"?

[balbes150]

16 часов назад, going сказал:

Today we don't know how to build source packages.

We are talking about the kernel (DEB package with the kernel), which is installed in the image during build. Or do you propose to build only ROOTFS in this system ?

 

16 часов назад, going сказал:

The target for all these features should be the source package. Next, we simply send it to a pre-deployed clean build environment and assemble binary packages.

 

IMHO this is the wrong approach. We are not building a source package, we are building a ready-made kernel and packaging it correctly in DEB.

 

 

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

open a Jira ticket

Sorry, I can't get into jira, if it suits me, I can create a question in GIT.

 

11 часов назад, rpardini сказал:

Yes, I have already started work on `armbian-oleg` -- it only builds media, only on arm64, and does not log anything.

 

It suits me (joke). Again, forget about my messages, I no longer comment on my tests with NEXT, I will solve everything necessary myself.

 

 

 

 

[going]

56 минут назад, balbes150 сказал:

17 часов назад, going сказал:

Today we don't know how to build source packages.

We are talking about the kernel (DEB package with the kernel), which is installed in the image during build. Or do you propose to build only ROOTFS in this system ?

 

17 часов назад, going сказал:

The target for all these features should be the source package. Next, we simply send it to a pre-deployed clean build environment and assemble binary packages.

 

IMHO this is the wrong approach. We are not building a source package, we are building a ready-made kernel and packaging it correctly in DEB.

 

Here we are talking about all the packages that we collect and then send them to the repository.

For a binary package, there must be a source package. And it should be in the repository.

And if necessary, it can be uploaded to the native environment on the device or to the native environment that the developer can afford.

For example, in a QEMU-based chroot.