Open SteeManMI opened 2 months ago
Jira ticket: AR-2417
is that the desired changes should first be made and tested in mainline armbian/build and then backported to the release branch (24.5 in this case)
Agree. What to do before this will be possible? We don't have one device or one arch. Testing is very complex and expensive process even if there would be only one device. I can only rely on (primitive) automated testings. Which is also not flexible enough to test other things then stable / beta. And even that is not in good shape.
corresponding artifacts being pushed to the apt repo, a user should always be able to have access to the corresponding .debs for their image and be able to install anything needed
How this problem was addressed in the past? All images that are being produced are dropping their build artifacts somewhere to the repository server. And until recently, those artifacts needed manual intervention to be included into repository ...
Last week I have changed this repo management to this: which means that it goes like this:
This is the status in short.
I don't know if the current packaging versioning logic can handle that case, (i.e. can you have a 24.5.1 and a 24.5.3 version of the same kernel i.e. 6.6.36?)
Yes, it can. That's exactly what happens. I am building an image and ignoring all artifacts. I.e., I am collecting the current state on the local machine. version 24.5.1. Then I change the u-boot package two times and to distinguish three different builds, I change the version of the u-boot package 24.5.2, 24.5.3. I assemble an image each time for the test. I have not changed the kernel package, but different versions of the kernel will be installed in each image, although it is the same thing.
What's the logic here?
What's the logic here?
WIP documentation: https://github.com/armbian/documentation/pull/449
Need real-world testers.
What happened?
This isn't an issue with the build framework, explicitly, but an issue with the release management process overall.
A forum user reported a problem where they can't install the correct version of kernel headers for the version of the kernel they have installed (https://forum.armbian.com/topic/42376-helios64-kernel-headers-for-this-kernel-do-not-seem-to-be-installed/). This happens every release, and isn't a new issue.
From what I witness, this is what is happening: 1) Original release goes out (24.5.1) in this case, all images are built and the apt repository is populated with the corresponding packages and everything is in sync at that time. 2) Issues need to get addressed and maintenance images are produced (24.5.2, 24.5.3, etc) These images appear to be built off of current main branch of armbian/build (not a patched version of the 24.5 branch). So instead of picking up all the same versions of referenced code (that we pinned at the time we froze the original release), it picks up the current patch release level of the kernel (and other code as well). So these images built for a maintenance release (24.5.2, 24.5.3, etc) end up including newer versions of the kernel than 24.5.1 was released with. But these new kernel packages aren't also put in the apt repository. 3) So when a user goes to install an additional package (like the kernel headers) after installing 24.5.3, the version in the apt repo doesn't match the version of the kernel they have in their image. And thus you have the problem reported by the user.
From my perspective the correct way to produce maintenance releases is that the desired changes should first be made and tested in mainline armbian/build and then backported to the release branch (24.5 in this case). And then images should be produced from that branch, otherwise you can't really control what changes you are incorporating into a maintenance release. With the logic added this year to pin all dependencies, this should result in dependencies consistent with the original release. Of course any artifacts that change as a result of what was fixed in armbian/build (likely to be uboots, kernels, etc), should be also be versioned correctly and added to the apt repo. I don't know if the current packaging versioning logic can handle that case, (i.e. can you have a 24.5.1 and a 24.5.3 version of the same kernel i.e. 6.6.36?)
With consistent builds (coming from a mostly stable branch) and corresponding artifacts being pushed to the apt repo, a user should always be able to have access to the corresponding .debs for their image and be able to install anything needed (generally, kernel headers, but it could be for a minimal install other packages like armbian-config).
How to reproduce?
Described above.
Branch
main (main development branch)
On which host OS are you running the build script and observing this problem?
Ubuntu 24.04 Noble
Are you building on Windows WSL2?
Relevant log URL
No response
Code of Conduct