-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: Maintenance builds don't create corresponding packages for the apt repo #6937
Comments
Jira ticket: AR-2417 |
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.
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 ... ProcedureLast week I have changed this repo management to this:
This is the status in short. |
Yes, it can. That's exactly what happens. What's the logic here? |
WIP documentation: 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:
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
The text was updated successfully, but these errors were encountered: