On Mon, 17 Aug 2026 at 16:48, Mathieu Dubois-Briand <[email protected]> wrote:
> I can't really do a clean build without the sstate cache, sorry. Or at > least not just by myself. Cleaning the cache on the autobuilder, will > fix the build on the autobuilder, but not for any other user that will > have the previous objects in the cache. So it means we could be breaking > the build for some users. > > What I could do is, as for last week, forcefully increase PR on a bunch > of recipes, to force a rebuild. This can be used to tests that > everything works fine on the autobuilder when everything is rebuilt from > scratch, but probably could bot be merged as-is. > > Weekly maintenance will happen soon, so I can't do that right now, but I > will try to launch such a build tomorrow. I have tried a local build of core-image-sato-sdk on qemux86-64. It did succeed. I then checked the log.do_package_write_rpm for the packages involved in this error seen on the AB: Problem 1: conflicting requests - nothing provides pkgconfig(gstreamer-1.0) >= 1.28.0 needed by gstreamer1.0-plugins-base-dev-1.28.5-r0.x86_64_v3 from oe-repo - nothing provides pkgconfig(gstreamer-base-1.0) >= 1.28.0 needed by gstreamer1.0-plugins-base-dev-1.28.5-r0.x86_64_v3 from oe-repo Locally, the packages made by gstreamer1.0 recipe do have the needed provides: Processing files: gstreamer1.0-dev-1.28.5-r0.x86_64_v3 ... Provides: gstreamer1.0-dev = 1.28.5-r0 gstreamer1.0-dev(x86-64) = 1.28.5-r0 pkgconfig(gstreamer-1.0) = 1.28.5 pkgconfig(gstreamer-base-1.0) = 1.28.5 pkgconfig(gstreamer-check-1.0) = 1.28.5 pkgconfig(gstreamer-controller-1.0) = 1.28.5 pkgconfig(gstreamer-net-1.0) = 1.28.5 But gstreamer1.0-plugins-base-dev-1.28.5-r0.x86_64_v3 does not even require them, so the error does not arise: Processing files: gstreamer1.0-plugins-base-dev-1.28.5-r0.x86_64_v3 ... (no mention of pkgconfig requires) So this successful local build seems to contradict the above AB error twice, on both ends. The AB error happened with both packages coming from sstate, so it's difficult to tell when and how they were created. I suspect there might be a non-reproducibility specific to particular host distributions, e.g. something causes rpm to be built differently (and then behave differently), or something on a particular host where rpm runs contaminates its behavior. There's a bunch of changes landed in master, including a new gcc version, so we could probably rebase on that, and re-run a-full. More data points, and especially when there's no sstate (it is difficult to trace its origin), would be useful. I don't have any other ideas right this moment, but maybe later something will pop. Alex
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#243639): https://lists.openembedded.org/g/openembedded-core/message/243639 Mute This Topic: https://lists.openembedded.org/mt/120783174/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
