libicu: Bumping to 73.1

[xtkoba]

libicu is now bumping to 73.1. Revdeps are split into several pushes and are being rebuilt. Inconsistencies in bindist can happen but are expected to be resolved within few hours in the main bindist server. Please refrain from filing individual bugs for that. Those bug reports that do not mention this issue will be immedately closed as duplicates.

Also please refrain from pushing commits that modify bindist while CIs for libicu and revdeps are running, to avoid build failure in CI.

Sorry for your inconvenience and thanks for your understanding.

[landfillbaby]

shouldn't you have actually waited for libicu to finish building before pushing the separate revdeps? i think they're downloading the old one

[xtkoba]

@landfillbaby CI does not work that way. The new version of libicu is always built at first.

[landfillbaby]

oh so it's just being built 5 times then?

[xtkoba]

Exactly.

[landfillbaby]

ah you're right i just checked. still, waiting for it to build once before pushing the revdeps would have been better i think. for next time

[xtkoba]

That would increase the chance that the aforementioned incosistencies could happen. For example, thorough upgrading after libicu is built but before firefox would break firefox.

[xtkoba]

So I tried to synchronize the upload timing of revdeps as much as possible, preferebly within 30 minutes. Other maintainers are not expected to do that though. I'm aware it is kind of overkill.

[thunder-coding]

Also please refrain from pushing commits that modify bindist while CIs for libicu and revdeps are running, to avoid build failure in CI.

I assume that by "bindist" you mean aptly's apt repository on the server. And anyways, this is not a problem at all, we have been having parallel commits modifying various packages and having uploads, usually only the upload step of the CI fails that too only if by coincidence multiple upload jobs happen at same time (which is rare), which can be re-run, and things work as expected without any inconsistencies

[xtkoba]

@thunder-coding See what happened to arm build in https://github.com/termux/termux-packages/actions/runs/4709004821.

[xtkoba]

Excerpt from the build log:

2023-04-15T17:54:12.6473972Z termux - build of 'qt5-qtbase' done
2023-04-15T17:54:12.6999208Z termux - building qt5-qtdeclarative for arch arm...
2023-04-15T17:54:12.7115317Z Downloading https://packages-cf.termux.dev/apt/termux-main/dists/stable/Release
2023-04-15T17:54:12.7209008Z   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
2023-04-15T17:54:12.7209380Z                                  Dload  Upload   Total   Spent    Left  Speed
2023-04-15T17:54:12.7209944Z 
2023-04-15T17:54:12.8412723Z   0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
2023-04-15T17:54:12.8413418Z 100 13134  100 13134    0     0   106k      0 --:--:-- --:--:-- --:--:--  106k
2023-04-15T17:54:12.8481339Z Downloading https://packages-cf.termux.dev/apt/termux-main/dists/stable/Release.gpg
2023-04-15T17:54:12.8535560Z   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
2023-04-15T17:54:12.8536179Z                                  Dload  Upload   Total   Spent    Left  Speed
2023-04-15T17:54:12.8536375Z 
2023-04-15T17:54:13.1398028Z   0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
2023-04-15T17:54:13.1398482Z 100   833  100   833    0     0   2954      0 --:--:-- --:--:-- --:--:--  2964
2023-04-15T17:54:13.1464715Z gpg: Signature made Sat 15 Apr 2023 05:53:48 PM UTC
2023-04-15T17:54:13.1465345Z gpg:                using RSA key CC72CF8BA7DBFA0182877D045A897D96E57CF20C
2023-04-15T17:54:13.1471699Z gpg: BAD signature from "Termux Releases (Termux automatic builds) <contact@termux.dev>" [ultimate]
2023-04-15T17:54:13.1494540Z ERROR: failed to verify gpg signature of /home/builder/.termux-build/_cache/packages-cf.termux.dev-apt-termux-main-stable-Release
2023-04-15T17:54:13.2778668Z ##[error]Process completed with exit code 1.

We suffer from this from time to time.

[xtkoba]

As you see this "interference" by other pushes only happens when starting build of a package, and does not happen after the build of the last package in CI starts successfully, which now is the case with the CIs for libicu and revdeps mentioned here.

So maintainers are now safe to push commits, even though not all CIs are finished. Thanks.

[DarremMolko]

Hi. I was told to report this here (from the Telegram group):

Setting up nodejs-lts (18.14.1-1) ...
CANNOT LINK EXECUTABLE "node": library "libicui18n.so.73" not found
dpkg: error processing package nodejs-lts (--configure):
 installed nodejs-lts package post-installation script subprocess returned error exit status 1

It happens when trying to upgrade nodejs-lts.

[xtkoba]

@DarremMolko Yes, this is a typical instance of inconsistencies. Please wait for a while. Thanks.

[xtkoba]

CI has completed. Note that it will take some time for mirrors to reflect the change. Please use the main server (temporarily) if necessary. Thanks.

Keeping this open for a while.

[landfillbaby]

a way to avoid this issue in future would be a refactor to separate downloading in the builds to a separate job, and mess with the github actions concurrency so as well as the current way of only allowing one upload at a time, the uploads and downloads are mutually exclusive.
or somehow set the server itself to do a similar thing
no idea how to do either of those though. major refactor of the entire build system, or mess with the aptly api
update: aptly-dev/aptly#1125 might be the whole problem ???