I built the 21.02.0-rc-2 the other day with the image builder "openwrt-imagebuilder-21.02.0-rc2-mvebu-cortexa9.Linux-x86_64.tar.xz" for the WRT3200ACM and want to build it again today with a couple of changes but I got the following error:
Collected errors:
pkg_hash_fetch_best_installation_candidate: Packages for libiwinfo20210106 found, but incompatible with the architectures configured
satisfy_dependencies_for: Cannot satisfy the following dependencies for luci:
That may have invalidated the dependencies on normal userspace packages that depend on ubus & libubus. Or at least the packages built by the phase2 packages buildbot may produce different ones than those included in rc2, and the target-specific packages built by phase1 images buildbot may be out of sync.
Your best bet is probably to download the current 21.02 HEAD imagebuilder, instead of the week-old 21.02.0-rc2
Alternatively, you might wait 2-3 days and see if the buildbot produced packages are again in sync.
Ps.
I get a bit confused why you talk about WRT3200ACM but look at the IPQ806x related packages download dir arm_cortex-a15_neon-vfpv4. You did that just for example???
EDIT:
That is a weird dependency chain, as non-target specific ubus & libubus have been updated, but the target-related iwinfo & libiwinfo is taken from the old rc2 build and expectd a different version of ubus.
I will write to the developer mailing list and propose that ubus would be marked to be target-specific. This is not the first time when this issue hits users, but that usually happens in master, not in the release branches.
As far as I know releases are not rebuild so what is build is build, if something is wrong it is wrong to next release.
It is only the snapshots that are rebuild and updated more or less on a daily basis.
Only partially true.
Firmware images and target-specific packages for a release are fixed and are not rebuilt frequently, but the normal user-space shared packages are constantly rebuilt by the 21.02 buildbot. I was first hoping that the error might be among that kind of packages, and would correct itself in the next build round.
release targets have a dedicated directory (like /releases/21.02.0-rc2/targets/) and are fixed, but
release packages have a separate directory, which is common to all 21.02 releases (21.02.0-rc1, -rc2, final, ongoing 21.02 snapshots). Note the symlink from /releases/21.02.0-rc2/packages/ -> ../packages-21.02. There the normal packages are constantly updated and rebuilt, even during the release lifetime.
(and there are also the semi-hidden regularly updated 21.02-snapshot builds for images, not only packages)
If normal packages are updated, their mutual dependencies do get corrected in the next build rounds.
But as target-specific release rc2 packages are fixed and not rebuilt, they continue to depend on the outdated versions of normal packages if there is ABI specification in the normal package so that you want an exact version. That is the error now, and the rc2 imagebuilder will remain broken. (If the depdency would be to a non-ABI-versioned package, the dependency would not be tied to a specific version and things would be ok.)
My fix proposal attempts to prevent similar errors in future, by marking six "normal" ABI versioned packages as target specific, so that in future they are built together with the target specific packages. So the fixed release build will contain also them.
imagebuilder does seem to have picked up popularity over the last year or two due to 1G>cpu demand... chef/auc ... dynamism of landscape and higher need for 'master' (new devices, breaking support fixes etc.)
wondering what (if any) streamlining can be done at the buildbot level to better sync / snappify the stage1/2 process... (particularly upon release which you mention in the PR)
obviously... there are cost / competing demands on available resources and it's not a simple question...
As a frequent imagebuilder user, I have been wondering the same thing. It would be nice if shared packages were snapshotted together with the non-shared ones, but I can see how this would be costly on the mirrors.
As a user, I think the workable options are to either privately mirror packages around the time of releases, or abandon image builder and switch to full builds instead.
I'm not sure if the following would be practical, but for the sake of brainstorming:
Continue to have the builders rebuild every package (because it's hard not to with buildroot), but do not immediately upload the built packages
After packages have been rebuilt, do some filtering by comparing them against the current published versions. If there are meaningful differences (as identified by a new version number, or modified dependencies), upload the new package (to be published on openwrt.org and mirrors). Otherwise, discard it assuming any binary differences are just the result of non-reproducible builds. (I'm worried that this filtering step might be the weak point of this proposal....)
Due to the filtering of packages before upload, the rate of package changes would be greatly reduced - most packages wouldn't change from one minor release to the next - and it might become feasible to create package snapshots for every release (linking the unmodified packages to a common location, so that the actual package files do not have to be duplicated).
pleased to say for master at least... the situation has improved(considerably)... guessing phase2 worker allocation (3days->2max) and reversion of abi stuff (very few ib failures due to deps even when out of phase)