This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------bnnICVNSlWuwgZd5m0AX5Dpd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 6/1/25 10:21 AM, Dr Rainer Woitok wrote:
Greetings,
since quite some time I have installed both packages, "dev-cpp/abseil-
cpp" and "dev-libs/protobuf" from the binhost. Now there is an upgrade
for "dev-cpp/abseil-cpp" which causes a rebuild for "dev-libs/protobuf"
that stubbornly requests rebuilding the latter from source:
$ emerge --pretend --oneshot --getbinpkg dev-libs/protobuf
Local copy of remote index is up-to-date and will be used.
[binary r U ] dev-cpp/abseil-cpp-20250127.1-1 [20240722.0-r1]
[binary rR ] media-libs/webrtc-audio-processing-1.3-r3-5
[ebuild R ] dev-libs/protobuf-28.0
[ebuild rR ] dev-util/android-tools-34.0.5
The following packages are causing rebuilds:
(dev-cpp/abseil-cpp-20250127.1-1:0/2501.1.0::gentoo, binary scheduled for merge) causes rebuilds for:
(media-libs/webrtc-audio-processing-1.3-r3-5:1/1::gentoo, binary scheduled for merge)
(dev-util/android-tools-34.0.5:0/0::gentoo, ebuild scheduled for merge)
(dev-libs/protobuf-28.0:0/28.0.0::gentoo, ebuild scheduled for merge)
$
However, when I exclude package "dev-cpp/abseil-cpp", package "dev-libs/ protobuf" would be rebuild from the binhost as expected:
$ emerge --pretend --oneshot --getbinpkg --exclude=dev-cpp/abseil-cpp dev-libs/protobuf
Local copy of remote index is up-to-date and will be used.
[binary R ] dev-libs/protobuf-28.0-1
$
Can anybody shed some light on this behaviour? Since my last ebuild of package "dev-libs/protobuf" took 12 minutes to complete, I'm hesitating
to just let this pass ... :-/
If merging one package on its own would use bins but with a triggered
SLOT rebuild it builds from source, this means the binhost doesn't have
a *rebuilt* protobuf compatible with abseil-cpp 2501.1.0`1
And checking the logs I see *both* packages rebuilt today. But protobuf
was one of the last packages.
The binhost incrementally uploads its results, under the theory, better
to show some bins rather than none. Some "way too big" updates take up
to a full day to build everything (e.g. dev-libs/icu triggers rebuilds
for libreoffice, firefox, thunderbird, qtwebengine, all at once), and we
don't want to leave users totally stranded.
The daily updates start at 5:11 am EST, it took about 4.5 hours to
finish today. Binpackages are uploaded from the build server to the
signing server in between builds if one hour passed since the last sync,
and the signing server processes recent uploads and sends them to the
mirrors once an hour IIRC, so, it could take until shortly after your
email for the last wave to appear.
Try syncing again, and note that getting into a habit of doing daily
updates around 12pm EST (7 hour delay) could result in more predictable
binary emerges.
--
Eli Schwartz
--------------bnnICVNSlWuwgZd5m0AX5Dpd--
-----BEGIN PGP SIGNATURE-----
wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCaDxw6QUDAAAAAAAKCRCEp9ErcA0vV03J AP4zpWoP5FAwg0/mZftdxL7MvH0+ZhfTmDiG0FQF2pzHxQEAq8f/X67ujHANpZZEmSn9wrLnnE/X O6T4uLXnyq2/+Ao=
=Z2vC
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)