Control: tags -1 moreinfo Hi, On 16-03-2023 00:16, Christian Kastner wrote:
On 2023-03-13 18:28, Christian Kastner wrote:[ Impact ] The new versions are in far better shape: they've catched missing dependencies, added patches, improved the build process, etc.Apologies, I was only thinking of the more recent releases. Revision -2 fixed an RC bug in January, but never got the chance to migrate because of an RC bug in a dependency. Revision -6 fixed another RC bug. All releases after -2 were incremental improvements that basically never got the chance to migrate because of a dependency not migrating.
For next time, can you please contact us earlier? We could have solved the earlier problems in testing-proposed-updates (in January), then we would now be in a better position.
+ * Reduce arch to amd64, arm64, ppc64elBut it fails on ppc64el; so why this selection? Also, as the other architectures FTBFS, we prefer in Debian to *not* limit the architectures, but just let them fail [1]. This eases porter efforts. If the packages really don't make sense on some architectures, consider using some of the "properties" provided by bin:architecture-properties in your Build-Depends.
By the way, I checked, but none of the ci.d.n host will run any of your tests, as none of them has an amdgpu (is that a thing you could expect on non-amd architectures by the way?).
One thing I spotted along the way; the (Build-)Depends on llvm related packages use the *versioned* ones. Is there a reason not to use the unversioned ones from src:llvm-defaults? That would make llvm transitions a bit easier.
Overall, the diff is a bit long (and has some irrelevant stuff), so I'm hesitant to offer t-p-u now (to avoid waiting for llvm-toolchain-15).
Paul[1] https://lists.debian.org/debian-devel/2022/09/msg00105.html and follow-up
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature