Am 14.08.20 um 14:50 schrieb Neal Gompa:
On Fri, Aug 14, 2020 at 8:39 AM Aaron Puchert <aaronpuchert@alice-dsl.net> wrote:
Most devel projects have alternative arches, so I think you're going to at least have an eye on failures there. But it's hard to prevent breakages if you just look at individual packages, because dependency changes can also break a build. I'd love to see the stats here, because I'm pretty sure the overwhelming majority of devel projects do not.
Even with Staging you can end up breaking packages, because the Stagings don't consider the entire tree of >10,000 packages. So you'll have to rely on maintainers reacting on notifications that their package doesn't build anymore. This is what the staging workflow is for, and if the notifications aren't working, we need better communication. There are two kinds of stagings: the “letter” stagings for packages in
Granted, what I wrote was based on my limited experience. Looking at a few devel projects reveals some that only build on x86 (e.g. KDE, X11:Wayland), but many build at least for aarch64 and ppc64le as well (e.g. Base:System, X11:XOrg, devel:tools). My experience is probably biased because in devel:tools:compiler we have 10 different architectures (i586, x86_64, ppc, ppc64, ppc64le, aarch64, armv6l, armv7l, s390x, riscv64), although not all are equally supported of course. But the policy is pretty clear: if we decide to promote aarch64 it needs to be active in all development projects, and that shouldn't be hard to enforce. the base system build all 2,000–3,000 packages of the base system from scratch for every submit. They also do some openQA testing, although to my understanding it's less than we do for snapshots. So we'll find issues in the base system, but not in the remaining ~10,000 packages. The “number” (adi) stagings for the remaining packages only build the package being submitted and don't do any openQA testing, so you won't find out if this breaks other packages. (There is not much to see there that you don't see in the devel project—basically only the install checker to my knowledge.)
Then ultimately this comes back to enabling the community to be able to fix these things. In Fedora, packagers and developers have access to test machines of all less-available architectures that they can shell into, build, test, and refine for those architectures[2].
Admittedly, because of the data center move, those are all down right now, but the general point is that they are available so that people are able to fix problems for those architectures.
Solving that problem for openSUSE people should be equally easy: provide resources that the community can use for this purpose.
[2]: https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainer...
That's actually a nice idea. It's not often that I run into non-x86 issues that I can't debug from the logs, but sometimes I do, and then it would be good to have access to a native machine to debug that. Best regards, Aaron -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org