Package version from the build date, so testing accepts it

.github/scripts/track-build.sh

@@ -7,14 +7,18 @@
 #   ORG       GitHub organization the builder clones from, e.g. biglinux
 #   BRANCH    branch the build was requested for, e.g. main
 #   SINCE     ISO 8601 time the request was made (the "Build Package" run end)
-#   START_TIMEOUT, BUILD_TIMEOUT   seconds to wait for the job to appear / end
+#   START_TIMEOUT, BUILD_TIMEOUT, PUBLISH_TIMEOUT   seconds to wait for the
+#             job to appear / to end / for the package to be published
 #
-# Exits non-zero when no matching job starts, or when it does not succeed.
+# Exits non-zero when no matching job starts, when it does not succeed, or when
+# a testing/stable package does not reach https://repo.biglinux.com.br: the
+# server drops some uploads without any error in the job.
 set -euo pipefail
 
 : "${PACKAGE:?}" "${ORG:?}" "${BRANCH:?}" "${SINCE:?}"
 START_TIMEOUT=${START_TIMEOUT:-600}
 BUILD_TIMEOUT=${BUILD_TIMEOUT:-3600}
+PUBLISH_TIMEOUT=${PUBLISH_TIMEOUT:-3600}
 api=https://gitlab.bigib.org/api/v4/projects/builder%2Fpackagebuilder
 web=https://gitlab.bigib.org/builder/packagebuilder
 url="https://github.com/$ORG/$PACKAGE"
@@ -112,3 +116,23 @@ if [ "$status" != success ] || [ -z "$built" ] || [ -z "$uploaded" ]; then
     echo "::error::Builder job $web/-/jobs/$job ended '$status'"
     exit 1
 fi
+
+# 4. Wait for the repository to publish it. Only testing and stable are public.
+case "$repo" in
+testing | stable) ;;
+*) exit 0 ;;
+esac
+# Ask for the file itself: the directory page is cached by the CDN for days.
+published="https://repo.biglinux.com.br/$repo/x86_64/$(head -n1 <<<"$uploaded")"
+echo "Waiting for $published"
+deadline=$((SECONDS + PUBLISH_TIMEOUT))
+until curl -fsI --max-time 30 -o /dev/null "$published"; do
+    if [ "$SECONDS" -ge "$deadline" ]; then
+        echo "::error::Uploaded, but $published is still missing after ${PUBLISH_TIMEOUT}s: the repository server dropped it. See docs/ci-packaging.md."
+        printf '| Published in %s | **no**, dropped by the repository server |\n' "$repo" >>"$summary"
+        exit 1
+    fi
+    sleep 120
+done
+echo "Published: $published"
+printf '| Published in %s | [yes](%s) |\n' "$repo" "$published" >>"$summary"

.github/workflows/gitlab-status.yml

@@ -28,7 +28,7 @@ jobs:
       github.event_name == 'workflow_dispatch' ||
       (github.repository_owner == 'biglinux' && github.event.workflow_run.conclusion == 'success')
     runs-on: ubuntu-latest
-    timeout-minutes: 75
+    timeout-minutes: 150
     steps:
       - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
         with:

README.md

@@ -134,7 +134,7 @@ BIGLINUX_WELCOME_SRC="$(realpath ..)" makepkg -sif
 
 Run `makepkg` as a normal user, never as root. Only `usr/` is packaged; development caches are removed and `docs/` and `tests/` are not installed.
 
-The package version is `1:3.0.1-1`. The epoch makes it newer than the earlier date-based builds (for example `26.10.10-0348`), so existing installations upgrade normally.
+The package version is the build date (for example `26.10.11-1327`), as in the other BigLinux packages; the application version (3.0.1) is shown in About and by `--version`. Do not add an `epoch`: the BigLinux repository server drops testing packages whose version only wins because of it ([details](docs/ci-packaging.md#why-1301-1-never-reached-testing)).
 
 ### Running
 
@@ -263,7 +263,7 @@ The suite checks the page configuration, translations, version consistency and t
 |---|---|---|
 | Tests | pull requests, manual | tests, lint, translations, package build/install/remove |
 | Build Package | pushes to `main`, `testing-*`, `stable-*`, manual | the tests above, then the `build` job |
-| GitLab Status | after Build Package (biglinux only), manual | follows the builder job and fails if it fails |
+| GitLab Status | after Build Package (biglinux only), manual | follows the builder job; fails if it fails or if testing/stable never publish the file |
 
 The BigLinux builder ([packagebuilder](https://gitlab.bigib.org/builder/packagebuilder)) starts by itself when a **Build Package** run in `biglinux/biglinux-welcome` succeeds; no secret is needed. `main` is built for the unstable repository, a `testing-*` branch for testing and a `stable-*` branch for stable. Failed tests mean no build. Details, evidence and the release checklist: [docs/ci-packaging.md](docs/ci-packaging.md).
 

docs/ci-packaging.md

@@ -17,7 +17,9 @@ push to main / testing-* / stable-*          (biglinux/biglinux-welcome)
        └─ job "biglinux-welcome": clone url, checkout git_branch, rewrite PKGBUILD,
           chrootbuild (Manjaro stable, x86_64), sign, rsync to the repository server
   └─ GitLab Status workflow (workflow_run) follows that job through the public
-     GitLab API and fails if it does not start within 10 min or does not succeed
+     GitLab API and fails if it does not start within 10 min or does not succeed;
+     for testing/stable it then waits up to 1 h for
+     repo.biglinux.com.br/<repo>/x86_64/<file> and fails if it never appears
 ```
 
 Destination repository, decided by the builder from `git_branch`
@@ -90,10 +92,50 @@ becomes `('x86_64' 'aarch64')` and `git` is added to `makedepends`.
 - The builder builds the head of the branch when the job starts, not
   necessarily the commit of the run. The `concurrency` group cancels older
   runs on the same branch, so the last successful run is for the head.
-- `epoch=1` is required (earlier versions were dates like `26.10.03-0942`).
-  The builder renames `1:3.0.1` to `1-3.0.1` in the file name only.
+- The package version is the build date (`pkgver=$(date +%y.%m.%d)`,
+  `pkgrel=$(date +%H%M)`), like biglinux-settings. Never add an `epoch`:
+  see below.
 - `BIGLINUX_WELCOME_SRC` is unset on the builder, so it uses the git source.
 
+## Why 1:3.0.1-1 never reached testing
+
+Job [62182](https://gitlab.bigib.org/builder/packagebuilder/-/jobs/62182)
+(branch `testing-2026-10-10-2`) built `1:3.0.1-1` and uploaded it for testing
+without errors, but `repo.biglinux.com.br/testing/x86_64` never listed it,
+although its database was updated later (04:14 UTC, adding chatai-plasmoid,
+uploaded at 04:11 by the same user and the same builder steps).
+
+The server-side step that turns testing uploads into the repository is not
+public. What the repositories show (2026-10-11):
+
+- every package in both testing and stable has a date version, and the
+  testing one is newer;
+- packages with an epoch are accepted in stable (`biglinux-driver-manager
+  1:26.10.02-2252`, `tts-biglinux 1:4.1.0-3`) and in testing when stable has
+  no version (`portainer-bin 1:2.18.3-1`);
+- no package with an epoch is in testing while stable has an older version.
+  `biglinux-welcome 1:3.0.1-1` (stable: `26.06.18-0104`) was dropped;
+  `tts-biglinux 1:4.1.0-2`, after the same change from dates, went straight
+  to stable.
+- the same file name uploaded twice is not the cause: chatai-plasmoid
+  `1.0.1-1` was built from main twice before its testing build, and that
+  testing build was accepted.
+
+The directory page `https://repo.biglinux.com.br/testing/x86_64/` is not a
+reliable check: the CDN serves it from cache for days (on 2026-10-11 it showed
+the 2026-10-09 state, without chatai-plasmoid). Request the file itself, or
+run `pacman -Syl biglinux-testing`; GitLab Status requests the file.
+
+So the testing step drops a package that does not look newer than stable and
+reads `1:3.0.1-1` without its epoch (`3.0.1-1` < `26.06.18-0104`). Date
+versions, as biglinux-settings and the earlier biglinux-welcome use, are
+always newer. Confirming this needs access to the repository server.
+
+`1:3.0.1-1` is still in the unstable repository. A date version is lower than
+it for pacman, so unstable needs it removed (`repo-remove`) by whoever runs
+that server, and machines that installed it must run
+`sudo pacman -S biglinux-welcome` once.
+
 ## External configuration
 
 None is needed for builds. Recommended, by a `biglinux` admin:
@@ -107,12 +149,9 @@ None is needed for builds. Recommended, by a `biglinux` admin:
 
 ## Release checklist
 
-1. Bump `pkgver` (reset `pkgrel=1`) in `pkgbuild/PKGBUILD` and `APP_VERSION`;
-   `tests/test_release.py` checks they match. Never lower `epoch`.
-   Every successful run rebuilds the branch, also for CI- or docs-only
-   commits. Unlike the old date-based versions, the version does not change
-   by itself, so that rebuild replaces the file already uploaded with the same
-   version. Bump `pkgrel` when a packaging-only change must reach users.
+1. For a new application version, bump `APP_VERSION` in `utils.py` (shown in
+   About and `--version`). The package version is the build date and needs
+   no change; every build gets a new one.
 2. Open a pull request; **Tests** must pass (`tests` and `package`).
 3. Merge into `main` in `biglinux/biglinux-welcome` → unstable. Check that
    **GitLab Status** is green; its summary links the job and the file uploaded.

pkgbuild/PKGBUILD

@@ -3,11 +3,12 @@
 # Maintainer: Barnabé Di Kartola <barnabedikartola@gmail.com>
 
 pkgname=biglinux-welcome
-pkgver=3.0.1
-pkgrel=1
-# Earlier releases used date-based versions (e.g. 26.10.10); the epoch makes
-# 1:3.x newer than all of them, so existing installations upgrade.
-epoch=1
+# Build date, like the other BigLinux packages (the application version is
+# APP_VERSION in utils.py). The repository server drops a testing package that
+# does not look newer than the stable one, and it does not understand epochs:
+# 1:3.0.1-1 lost to 26.06.18-0104. Do not add an epoch.
+pkgver=$(date +%y.%m.%d)
+pkgrel=$(date +%H%M)
 arch=('any')
 license=('GPL-3.0-or-later')
 pkgdesc="Guided setup and feature discovery for BigLinux"

tests/test_release.py

@@ -4,6 +4,7 @@
 import re
 import subprocess
 import sys
+import time
 import unittest
 from pathlib import Path
 from typing import ClassVar
@@ -26,14 +27,16 @@ class TestVersion(unittest.TestCase):
     def test_version_is_3_0_1(self):
         self.assertEqual(APP_VERSION, "3.0.1")
 
-    def test_pkgbuild_matches_app(self):
-        self.assertEqual(pkgbuild_var("pkgver"), APP_VERSION)
-        self.assertEqual(pkgbuild_var("pkgrel"), "1")
+    def test_package_version_is_the_build_date(self):
+        # The repository server ignores epochs when it compares a testing
+        # package with the stable one, so the version must grow by itself
+        self.assertEqual(pkgbuild_var("pkgver"), "$(date +%y.%m.%d)")
+        self.assertEqual(pkgbuild_var("pkgrel"), "$(date +%H%M)")
+        self.assertNotRegex(PKGBUILD, re.compile(r"^\s*epoch=", re.MULTILINE))
 
-    def test_epoch_upgrades_date_based_versions(self):
-        epoch = pkgbuild_var("epoch")
-        new = f"{epoch}:{APP_VERSION}-1"
-        old = "26.10.10-0348"  # last date-based build
+    def test_date_version_upgrades_stable(self):
+        new = time.strftime("%y.%m.%d-%H%M")
+        old = "26.06.18-0104"  # in stable when 1:3.0.1-1 was dropped from testing
         try:
             result = subprocess.run(
                 ["vercmp", new, old], capture_output=True, text=True, check=False