You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Measured facts only. Each table gives its date and its source. A row that comes from documentation says so. Times are UTC unless a table says otherwise.
pacman
Source: pacman v7.1.0 (commit 5683f847), read from source. Also pacman 7.1.0.r9.g54d9411-2, run in archlinux:base under podman with no network, with an XferCommand that logs each call. Date: 2026-10-14.
behaviour
measured
downloads under an XferCommand
one file at a time, in order; 2 packages with ParallelDownloads = 5 were fetched back to back
ParallelDownloads, server error limit
not used under an XferCommand
after a failed XferCommand call
sleep(2), also for an optional .sig; 4 failing servers took 8.28 s
SigLevel = Required DatabaseOptional, no .db.sig on the server
2.16 s for -Sy
SigLevel = Required DatabaseNever
no .db.sig request; 0.10 s for -Sy
%o, %u
replaced only when they are a whole argument
the XferCommand process
a direct child of the pacman main process; pacman waits only on its pid
the XferCommand under DownloadUser
uid switch and NO_NEW_PRIVS only; no Landlock, no seccomp; CapEff 0
what it can write under DownloadUser
its download-XXXXXX directory (mode 0700) and /tmp; not the cache or sync directory
download-XXXXXX
one per operation: -Syu makes two
cleanup of download-XXXXXX
payload files and their .sig are moved out; other regular files are unlinked; a subdirectory makes the cleanup fail and the directory stays
a zero-byte %o under the sandbox
unlinked; the old file is kept; pacman exits 0
a zero-byte %o with no sandbox
replaces the database; pacman exits 0
DownloadUser with both sandbox parts off
the XferCommand runs as the download user in a root-owned directory: permission denied
-Syy with no DownloadUser
the database is deleted before the XferCommand runs
a database under an XferCommand
downloaded again on every -Sy: no If-Modified-Since
pacman -Sp
takes no lock and needs no root; -Syp needs root
--print-format
%l the first Server or file:// when cached, %h sha256, %s download size (0 when cached), %g base64 %PGPSIG%
print mode
never prompts; takes the first provider
a cached package with required signatures and no cached .sig
the package and its .sig are downloaded again
native downloader, redirects
follows a 302 or 307 to another host; at most 10 redirects; file:// refused
native downloader, 404 on an optional .db.sig
no error line and no pause (0.04 s)
native downloader, Range on resume
sent again to the redirect target; 206 completed the file
native DownloadUser sandbox in podman on WSL2, no CAP_SYS_ADMIN
fails: Landlock ruleset not applied
behaviour
date
source
pacman on x86_64 with Architecture = <arch> downloads and checks another arch's packages
2026-10-14
scripts/verify-batch in archlinux:base
pacman 7.1 checks a package against %PGPSIG%, and still asks for its .sig and stores it unread
2026-10-14
pacman against the promoted x86_64 core
pacman 7.1 takes an expired primary key for a missing key: it asks a keyserver, then says "required key missing from keyring"
2026-10-14
the integration suite and loong64 extra
pacman 7.1 under an XferCommand names no file when a package's .sig cannot be served: only "failed to retrieve some files"
2026-10-14
the integration suite
GnuPG 2.4.9 in archlinux:base, after pacman-key --init and the keyserver hkp://127.0.0.1:9: gpg --locate-external-keys eworm@archlinux.org reads the key by WKD in 1.3 s. With auto-key-locate clear,local, or clear,nodefault, in gpg.conf and disable-http, disable-ldap in dirmngr.conf, it still does. With disable-dirmngr in gpg.conf it fails in 0.01 s ("No dirmngr"), and so does --recv-keys
2026-10-15
podman in the WSL VM, default network
GHCR
fact
date
source
Authorization: Bearer QQ== gives 200 on a public manifest and blob
2026-10-13
curl against ghcr.io
no Authorization header gives 401 with a WWW-Authenticate header
2026-10-14
curl against ghcr.io
an unknown bearer gives 403 with no WWW-Authenticate header
2026-10-13
curl against ghcr.io
Bearer QQ== for a repository that does not exist gives 404 MANIFEST_UNKNOWN
2026-10-14
curl against ghcr.io
the token endpoint with no credential, service=ghcr.io and a pull scope: 200 and {"token": ...} for a public repository, and that token reads its manifest and blob; 403 DENIED for a repository that does not exist
2026-10-15
curl 8.21.0 against ghcr.io
a blob GET gives 307 to a signed URL on pkg-containers.githubusercontent.com; that URL needs no Authorization
2026-10-13
curl against ghcr.io
a Range request on a blob gives 206; a resumed download was byte-identical
2026-10-14
curl against ghcr.io, a 199 MiB blob
blobs are scoped per repository: another repository's blob gives 404
2026-10-13
curl against ghcr.io
tags resolve with no regard to case: latest, LATEST and Latest name one manifest
2026-10-13
curl against ghcr.io
a reference of 129 characters gives 303 to an HTML page on github.com
2026-10-14
curl against ghcr.io
30 manifest GETs at once all gave 200
2026-10-14
curl --parallel against ghcr.io
a 200 carries no RateLimit or Retry-After header
2026-10-14
curl against ghcr.io
tag list: 100 per page by default; n is capped at 1000
2026-10-14
curl against ghcr.io
a package that GITHUB_TOKEN creates from this public repository reads anonymously
2026-10-14
curl against ghcr.io
299 of 299 pushes read back right on the first try
2026-10-13
the first sync of x86_64 core
10 GB per layer and a 10-minute upload limit (documented); no rate limit documented
2026-10-14
GitHub docs, container registry
no REST endpoint changes a package's visibility (documented)
2026-10-13
GitHub REST API docs
oras 1.3.4 keeps the created annotation it is given: two writers pushed manifests of one digest, 3 of 3
2026-10-14
the integration suite
pushes from runners got 429 toomanyrequests with "allowed: 2000/minute"; 4 targets x 3 shards x 6 pushes ran at once on one workflow token
2026-10-14
run 38570044665
that limit bounds a seed to about 200 files a minute per token, whatever the parallelism
2026-10-14
run 38570044665
GHCR latency from one host. Host: Windows, Git Bash, curl 8.21.0 over HTTP/1.1, residential network in Nepal; GHCR answered from edge centralindia. Date: 2026-10-14.
request
median
manifest GET, new connection (n=20)
0.410 s
manifest GET, reused connection
0.267 s
blob GET to the 307 only (n=10)
0.392 s
blob GET, following the redirect (n=10)
0.722 s
blob GET, reused connection
0.569 s
20 manifests with --parallel
1.003 s in all
GitHub Actions and Pages
Source: GitHub's own REST API documentation, and gh api reads of the organisation. Date: 2026-10-14.
fact
value
organisation plan
Free; 619 public repositories
concurrent jobs, shared by every repository of the organisation
20
jobs per matrix
256
time per job on a GitHub-hosted runner
6 hours
REST requests of GITHUB_TOKEN
1000 per hour per repository
artifact retention in a public repository
1 to 90 days; at most 500 artifacts per job
ubuntu-24.04-arm
free for public repositories: 4 vCPU, 16 GB RAM, 14 GB SSD
enabling Pages
needs an admin token; GITHUB_TOKEN has no administration permission
Pages limits
1 GB per site, 10 minutes per deployment, 100 GB per month soft bandwidth
fact
date
source
a job that calls a reusable workflow takes no timeout-minutes
2026-10-14
actionlint 1.7.12
a dispatch input reaches an expression as a string; max-parallel refused it: "Unexpected value '4'"
2026-10-14
run 38569214434
keyring_image with create and cp only, for linux/loong64 and linux/arm64, worked on an amd64 runner
2026-10-14
run 38570044665
a public-repository ubuntu-24.04 runner starts with about 87 GB free on /; GitHub guarantees 14 GB
2026-10-13
runner image documentation
scripts/debloat-runner removed 12 of 12 directories in 45 s: 85 GiB free became 120 GiB
2026-10-13
a CI run on a runner
the Actions cache removes an entry that no run used for 7 days; a restore key that is a prefix takes the newest entry it matches (documented)
2026-10-16
GitHub docs, dependency caching
actions/cache v6.1.0 is commit 55cc8345863c7cc4c66a329aec7e433d2d1c52a9, a lightweight tag; restore and save run on node24
2026-10-16
gh api repos/actions/cache/releases/latest and .../git/ref/tags/v6.1.0
$5 per month per account, 10 million requests included, then $0.30 per million
CPU
30 million CPU-ms included, then $0.02 per million CPU-ms
subrequests, egress
not billed
Cache API
per data centre, not replicated; objects up to 512 MB
limits.cpu_ms
a cap per invocation, enforced on Cloudflare only
The Worker run locally. Source: npx wrangler@4.150.0 dev --local (workerd) against live GHCR, from the host in Nepal. Date: 2026-10-14.
request
measured
core.db, cold
0.53 to 0.88 s
core.db, repeat (one cache lookup)
4 to 6 ms
a package, cold
0.29 to 0.79 s (manifest about 260 ms, blob about 250 to 310 ms)
a package, repeat
3 to 5 ms
a .sig asked 2 s after its package
3 to 4 ms
a .sig asked about 50 ms after its package
0.25 to 0.29 s: the prewarm lost the race by about 5 ms
wrangler deploy --dry-run
14.08 KiB, gzip 4.69 KiB, no warnings
fact
date
source
the deployed version 1 answered core.db with 302 in 1.05 to 1.33 s
2026-10-14
curl from the host in Nepal
16 of 16 Worker probes passed; median 0.41 s
2026-10-14
scripts/status-collect, live
the GHCR latest manifest, read anonymously: median 0.43 s
2026-10-14
scripts/status-collect, live
Upstream
Source: each database downloaded from a db_server and read with scripts/lib.shdb_records and db_validate. The x86_64 core row comes from scripts/status-collect, live. Date: 2026-10-14.
target
packages
total %CSIZE% (bytes)
GiB
largest file (bytes)
%PGPSIG%
x86_64-core
299
1981090710
1.85
not measured
299 of 299
x86_64-extra
15041
115541940123
107.61
3290190315
15041 of 15041
x86_64-multilib
182
371948848
0.35
121321827
182 of 182
aarch64-core
313
1576463280
1.47
172772972
313 of 313
aarch64-extra
12994 readable of 12995
56935118832
53.02
3405583252
12994 of 12994
aarch64-alarm
75
142390596
0.13
35327900
75 of 75
aarch64-aur
12
10992812
0.01
6974820
12 of 12
armv7h-core
326
1622069404
1.51
172776152
326 of 326
armv7h-extra
12555
45784791156
42.64
3405570792
12555 of 12555
armv7h-alarm
125
190947120
0.18
35377156
125 of 125
armv7h-aur
11
10670656
0.01
6563988
11 of 11
loong64-core
295
1904375301
1.77
208134504
263 of 295; the other 32 have a detached .sig
loong64-extra
14184
78262056692
72.89
3064267589
12965 of 14184; 1218 have a detached .sig, 1 has none
no target publishes <repo>.db.sig or <repo>.files.sig: 404 on every server tried
2026-10-14
curl on each db_server
loongarchlinux.lcpu.dev, the one db_server of both loong64 targets, answers core.db with 200, Server: cloudflare and a CF-RAY header
2026-10-15
curl -I from the Windows host in Nepal
curl 8.21 writes %header{cf-mitigated} empty when the answer has no such header
2026-10-15
curl --write-out against a Cloudflare host
98 of 98 db_server and server URLs answered 200 for <repo>.db
2026-10-14
curl on each URL
aarch64 extra findnewest-0.3-4/desc: a GNU sparse member of 1271 NUL bytes; pacman lists it with every field None and cannot download it
2026-10-14
the database on every mirror; pacman 7.1 in the aarch64 image
riscv64 extra ntk-1.3.1001-4/desc: a GNU sparse member of 576 NUL bytes, on every current mirror
2026-10-14
the database on each mirror
Arch Linux ARM aarch64 aur.files leaves out localepurge-0.7.3.4-1, which aur.db names
2026-10-14
scripts/plan on the upstream databases
Arch Linux ARM aarch64 alarm.files leaves out dkms-mt7601, macspoof and sprunge, which alarm.db names
2026-10-14
Sync run 38591019319, plan
Arch Linux ARM aarch64 extra.files names qemu-system-cris-9.1.2-1 (dropped from extra.db) and findnewest-0.3-4 (its extra.db desc is NUL bytes), on fl.us, ca.us and de3
2026-10-15
Sync run 38606900677, plan; comm of the two record lists
Arch Linux RISC-V extra.files leaves out 934 of the 14716 packages of extra.db (no other file, no other sha256); both regenerated at 00:46 UTC. A drift limit of 1% held riscv64 extra on run 38656876449
2026-10-15
comm of the two record lists
Seed of 15 targets, run 38606900677: 12 promoted in one run; armv7h extra held by 3 files upstream rebuilt during the run, loong64 extra by 1 file of a shard that reached its 120 min limit, aarch64 extra by its extra.files
2026-10-14
latest manifests on GHCR
loong64 extra: pacman refuses compiler-rt18-18.1.8-1, x11-ssh-askpass-1.2.4.1-8 and yt6801-dkms-1.0.28-3 (keys expired) and python-xarray-2026.07.0-1 (no signature anywhere)
2026-10-14
pacman 7.1 in archlinux:base, Architecture = loong64
loong64 extra: 16 packages are signed by a subkey that expires on 2026-12-31
2026-10-14
the signature issuers
Arch Linux ARM: one key, 68B3537F39A313B3E574D06777193F152BDBE6A6, made every signature of the 8 targets
2026-10-14
the signature issuers
Arch Linux RISC-V: every signature is by B5971F2C5C10A9A08C60030F786C63F330D7CB92, which is in archlinux.gpg
2026-10-14
the signature issuers
about 44000 filenames across nine databases, all [A-Za-z0-9@._+:-]; the longest is 92 characters
2026-10-13
the databases
x86_64 extra: 12 filenames have upper case and map to fn- tags; 15041 unique tags; the longest tag is 91 characters
2026-10-14
client/pacman-oci --tags
%PGPSIG%, base64 decoded, is byte-identical to the detached .sig
2026-10-13
the x86_64 core database
the newest %BUILDDATE% of a database is not monotonic: archived core of 10-02 and 10-03 share it, and so do 10-10 and 10-11
2026-10-13
the Arch Linux archive
over eleven pairs of consecutive days (10-01 to 10-12), the newer core never had an older package
2026-10-13
the Arch Linux archive
a superseded file is gone from every Arch mirror within a day, in os/ and pool/
2026-10-13
the mirrors
a HEAD of core.db answers 200 with ETag, Last-Modified and Content-Length on geo.mirror.pkgbuild.com, fastly.mirror.pkgbuild.com, fl.us.mirror.archlinuxarm.org, riscv.mirror.pkgbuild.com, archriscv.felixc.at and loongarchlinux.lcpu.dev; the two hosts of x86_64 and of riscv64 gave the same three values
2026-10-16
curl --head --location from the Windows host in Nepal
scripts/upstream-watch, two ticks a few minutes apart: 36 URLs; 34 answered in each tick, and the 32 that answered in both gave the same values; de3.mirror.archlinuxarm.org did not connect within 10 s for 2 URLs in each tick, other URLs each time
2026-10-16
WATCH_DRY_RUN=1 scripts/upstream-watch from the Windows host in Nepal
between two status runs, the file count or the bytes of upstream's database changed: x86_64 extra 27 times, riscv64 extra 25, aarch64 extra 5, armv7h extra, riscv64 core and x86_64 core 3 each, x86_64 multilib 2, aarch64 core, loong64 core and loong64 extra 1 each, the four alarm and aur targets and armv7h core 0; 71 in all, in 33 hours
2026-10-14T17:31Z to 2026-10-16T02:32Z
the 39 lines of history.jsonl on branch status
ArchPOWER (the PowerPC targets)
Source: fetchers/fetcher.sh and curl against
https://repo.archlinuxpower.org from a residential network, 2026-10-15,
unless the row says otherwise.
fact
date
source
one host, https://repo.archlinuxpower.org
2026-10-15
the directory index at /
[base] at base/<arch> for powerpc64le, powerpc64 and powerpc, and [base-any] at base/any; testing/ also exists
2026-10-15
the directory indexes at /base/ and /testing/
every <repo>.db.sig answers 200, for base of all three arches and for base-any
2026-10-15
fetchers/fetcher.sh --expect sig on each URL
the databases are zstd (magic 28 b5 2f fd), not gzip
the largest package is ruby-docs-3.4.8-2 728 MB in each arch, and texlive-doc-2025.2-2 3.35 GB in base-any
2026-10-15
%CSIZE% of each desc member
base.db sizes: powerpc64le 724416 B, powerpc64 684273 B, powerpc 741171 B, base-any 504891 B; each passes the db check; each .db.sig is 119 B and passes the sig check
2026-10-15
fetchers/fetcher.sh
the keyring package is archpower-keyring (20260408-1), in base-any
2026-10-15
the package list of base-any
ghcr.io/pkgforge-dev/archlinux:ppc64le, :ppc64 and :ppc exist; newest dated tags 2026-09-05
2026-10-15
GHCR
The pipeline
fact
date
source
first sync of x86_64 core: plan 25 s; 4 shards of 74 to 75 files, 53 s to 3 min 10 s; stage 35 s; verify 6.5 min
2026-10-13
the first run, on a branch
a single push ran at up to 34 MB/s
2026-10-13
the first run
the four upstream servers gave 75, 75, 75 and 74 files
2026-10-13
the first run
a sync with nothing new: every file present; shards took 12 to 17 s
2026-10-13
the second run
Sync run 38490975315: 8 min 40 s in all; plan script 2.7 s; mirror shards 6.56 to 12.80 s; stage 3.25 s; verify 426.3 s for 299 packages and 1888.10 MiB; promote 6.0 s
2026-10-14
the run's logs
the same verify step took 333 s and 443 s in two other runs
2026-10-14
runs 38435488665 and 38440550631
a wrapper call in verify cost at most 0.56 s: 333 s for 598 calls, the image pull included
2026-10-14
run 38435488665
verify jobs: loong64-core 82 s for 295 packages and 1.8 GB, its batch phase 24 s through the wrapper's prefetch; aarch64-aur 36 s; riscv64-core 67 s; x86_64-multilib 39 s
2026-10-14
run 38570044665, on GitHub runners
mirror time per file, first seed: 3.19 s plus 0.0328 s per MiB (n=299, PARALLEL=4)
2026-10-14
the first seed's results
batch_count on the x86_64 extra seed (15041 files, 115541940123 bytes): it wants 54 batches and grows the limits to 572 files and 3057647619 bytes, for 38 batches
2026-10-14
scripts/lib.shbatch_count
the plan artifact of x86_64 core: 2,451,850 bytes; a simulated x86_64 extra seed: 122.4 MB
2026-10-14
run 38490975315 and a simulation
history.jsonl: 1261 bytes per line for 15 targets, about 2.5 MB at 2000 lines
2026-10-14
scripts/status-collect, live
The wrapper
fact
date
source
40 small packages through pacman, median of 8 runs, from Nepal: 3.8 s with 8 jobs, 7.8 s with 16, 3.0 s with 24, 2.7 s with 32
2026-10-14
the comment above PACMAN_OCI_JOBS in client/pacman-oci
a connection to the blob host can stall: 150 small blobs on one HTTP/2 connection took 425 s and 440 s, and 4 to 6 s on a new connection
2026-10-14
a WSL2 VM in Nepal; the comment above deadline in client/pacman-oci
one 208 MB blob ran at 330 KB/s for 625 s
2026-10-14
the same
about 1 run in 4 of 40 small blobs sent at a few KB/s for 10 s or more; a normal run takes 1 to 2 s
2026-10-14
the same
a 3 s transfer limit, not 10 s, took a run of 40 small packages with a stall from 11 to 17 s down to 6.5 to 9 s
2026-10-14
the comment above slice in client/pacman-oci
one limit of 3 s plus 1 MiB/s for the whole file: 3 large packages (540 MB) took 238 s, where the official mirror took 40 s
2026-10-14
the same
version 1, 40 files driven directly: 75.1 s with 1 job, 20.1 s with 4, 17.1 s with 8, 13.8 s with 16
2026-10-14
the Windows host in Nepal
the decoded %PGPSIG% equalled the served .sig for 20 of 20 packages
2026-10-14
x86_64 core
version 1 against a registry that does not answer: a file failed after 35.35 s (three 10 s connect timeouts)
2026-10-14
a blackholed address
version 1 with PACMAN_OCI_NO_DUMMY=1: 4 requests per file (manifest 401, token, manifest 200, blob), 3.0 s
2026-10-14
the Windows host in Nepal
version 1, the first promoted core as the only Server, from a residential network: pacman -Sy 4.0 s, pacman -S nano 5.1 s
2026-10-14
a stock Arch pacman
Bench
Source: scripts/bench-consumer, with client/pacman-oci version 2. Host: "Ajam (Linux x86_64), in archlinux:base through podman". pacman 7.1.0.r9.g54d9411-2. Date: 2026-10-14T12:38:28Z.
Each case uses ParallelDownloads = 5 and SigLevel = Required DatabaseNever. sy is pacman -Sy into an empty database path. sw-small is pacman -Swdd of the 40 smallest core packages, and sw-large of the 3 largest. The file counts include the signatures. Seconds is the median of 3 rounds.
path
op
seconds
rounds
files
bytes
ok
official
sy
0.727
0.539, 0.743, 0.727
1
130359
yes
official
sw-small
4.853
6.442, 2.639, 4.853
80
665107
yes
official
sw-large
55.077
55.077, 42.611, 63.287
6
539912381
yes
worker
sy
2.238
3.502, 1.484, 2.238
1
130359
yes
worker
sw-small
10.552
14.476, 8.622, 10.552
80
665107
yes
worker
sw-large
49.173
261.048, 49.173, 35.617
6
539912381
no
oci
sy
1.615
2.016, 1.615, 1.596
1
130359
yes
oci
sw-small
2.735
2.735, 6.756, 2.592
80
665107
yes
oci
sw-large
72.612
72.612, 77.378, 38.745
6
539912381
yes
oci-serial
sy
1.574
2.056, 1.153, 1.574
1
130359
yes
oci-serial
sw-small
126.064
142.665, 121.073, 126.064
80
665107
yes
oci-serial
sw-large
348.617
71.521, 860.701, 348.617
6
539912381
yes
official is geo.mirror.pkgbuild.com with pacman's downloader. worker is the Worker with pacman's downloader. oci is the wrapper with its prefetch, and oci-serial the wrapper with PACMAN_OCI_PREFETCH=0. ok is no when a round failed or downloaded another number of files.
Tools and images
fact
date
source
oras 1.3.4: the sha256 of each archive, from the release's checksums.txt
curl 8.22.0 (stunnel/static-curl), musl static: the GitHub asset digest, the release notes and SHA256SUMS agreed
2026-10-14
scripts/install-test-tools
bash 5.2.21-2ubuntu4 (Ubuntu noble bash-static, release pocket): the Packages index and Launchpad agreed
2026-10-14
scripts/install-test-tools
the verify image archlinux:base@sha256:3c64b538...47a0 pulled by its digest for linux/amd64 from mirror.gcr.io/library/archlinux (8 s) and from public.ecr.aws/docker/library/archlinux: both image ID 5a30b4acc83f, pacman 7.1.0 and the three archlinux keyring files inside
2026-10-15
podman 5.8.6 in the WSL VM, a storage of its own
Docker Hub documents a limit of 100 anonymous pulls per 6 hours per IPv4 address or IPv6 /64, and no exemption for GitHub-hosted runners
2026-10-15
docs.docker.com/docker-hub/usage (documented)
docker.io/library/node:24-alpine is lts-alpine, digest sha256:ebfe2f90462722a7a4de65e91990e97fe0d401c70e0e762c5b53302f905ec1c1, node v24.21.0
2026-10-14
Docker Hub
node --test worker/test/ fails on node 26.7.0; the quoted glob works on node 22, 24 and 26
2026-10-14
node in containers
the integration suite 10-pipeline.sh: 98 of 98 in 314 to 490 s, in a 10-vCPU WSL VM with podman
2026-10-14
tests/run.sh integration
the static suite: about 40 s in a container
2026-10-14
tests/run.sh static
ArchPOWER
Source: curl and fetchers/fetcher.sh against
https://repo.archlinuxpower.org, 2026-10-15.
fact
date
source
repo.archlinuxpower.org answers 200 from here, with the databases
2026-10-15
fetchers/fetcher.sh --expect db
the databases are zstd, not gzip: the first four bytes are 28 b5 2f fd on all three arches and on base-any, which is four databases
2026-10-15
od -An -tx1 -N4 on the fetched files
GNU tar 1.35 reads a zstd database whole, with the zstd program on PATH; without it tar ends non-zero with tar (child): zstd: Cannot exec
2026-10-15
tar -tf on base/powerpc64le/base.db
base/$arch/base.db is 724416 (powerpc64le), 684273 (powerpc64) and 741171 (powerpc) bytes
2026-10-15
curl, with --write-out '%{size_download}'
base/$arch/base.files is 9762704 (powerpc64le), 8926204 (powerpc64) and 9049853 (powerpc) bytes, all 200
2026-10-15
curl on the db_server of each *-base.conf, with $repo/$arch expanded
plain curl fetched all four databases with HTTP 200 from a residential address, with its own user agent (curl/8.14.1) and with a HeadlessChrome/140.0.0.0 user agent: 724416 bytes each time
2026-10-15
curl against https://repo.archlinuxpower.org/base/powerpc64le/base.db
base-any.db is 504891 bytes and base-any.files 5746652, both with a 119-byte .sig answering 200
2026-10-15
curl on base/any/
powerpc64le base.db holds 3735 records and base.files 4280; base-any.db holds 2200
2026-10-15
zstd -dc | tar -tf - | grep -c '/desc$'
every .db.sig and .files.sig is 119 bytes and answers 200, for all three arches and for base-any
2026-10-15
curl
base/any/base-any.db answered 404, and the directory index named no database at all; the same path answered 200 with 504891 bytes a few minutes later
2026-10-15
two curls, same network, same day
archpower-keyring-20260408-1-any.pkg.tar.zst is 28621 bytes in base/any, with a 119-byte signature, and its /usr/share/pacman/keyrings/archpower.gpg verifies base.db.sig
2026-10-15
tar -xf then gpgv --keyring
a database cut to half its bytes gave 136 records and exit 0 from db_records before the fix in db_tar
2026-10-15
tests/unit/40-lib.sh, seen-to-fail
local resets PIPESTATUS, so capturing it into an array declared on the line before gives [0] for every input
2026-10-15
bash -c 'false | true; local -a a=(); read -ra a <<< "${PIPESTATUS[*]}"; echo ${a[0]}'
the three keyring_image digests in targets/powerpc*-base.conf resolve, and each image's /usr/share/pacman/keyrings holds the same three files: archpower.gpg, archpower-trusted, archpower-revoked
2026-10-15
oras copy --platform linux/<tag> --to-oci-layout, then the layer listing
the nine ppc lines in targets/keyrings.sha256 are byte-identical to what scripts/keyring-files computes from those three images; changing one hex digit makes them differ
2026-10-15
diff of the computed lines against the file, then the same with one digit changed
the Worker answers 200 for / and 404 for every PowerPC file, the same as for a path that cannot exist; at the registry below it, x86_64/core and aarch64/core list 100 tags and powerpc64le/base gives NAME_UNKNOWN
2026-10-15
WORKER_LIVE=1 bash tests/worker/live.sh with WORKER_ARCH per arch, and ghcr.io/v2/pkgforge-dev/mirror-archlinux/<arch>/<repo>/tags/list
tests/worker/live.sh fails core.db unpacks with tar in a sandbox with CapEff 0 and no uid 1035; tar --no-same-owner -xf extracts all 299 entries of the same file
2026-10-15
the unmodified run, then the same with a tar wrapper adding only that flag
The dependency versions fetchers/drift.sh resolved
Resolved 2026-10-15 and read back the same day. The registry column is what
drift_sources in fetchers/drift.sh reads for each key.
tool
newest
registry
playwright
1.64.1
registry.npmjs.org/playwright/latest
cloak-browser
0.6.3
registry.npmjs.org/cloakbrowser/latest
invisible-playwright
v0.35.9
GitHub releases, feder-cr/invisible_playwright
curl-impersonate
v2.2.3
GitHub releases, lexiforest/curl-impersonate
⚠ The two release keys are read from the repository's latest release, not from
the package index the installer uses. For invisible-playwright the installer
installs from PyPI, so a release tag and a published wheel can disagree; the tag
is the number a maintainer chooses, and the wheel is what npm or pip resolves.
Where the two differ, the installer's own answer is the one that decides what
runs.