ogc-arch-repo

The ogc Arch Linux pacman repository — a live, PGP-signed home for packages from OpenGamingCollective source repos. Updated hourly.

ogc is the central pacman repository for OpenGamingCollective software. It doesn't build anything; it ingests prebuilt *.pkg.tar.zst packages from source repos' GitHub releases and OCI registries, signs them with a single PGP key, merges them into one shared database, and publishes the result to an S3-backed bucket that pacman reads directly.

What's in the repo

• asusctl — ASUS ROG laptop control daemon
• rog-control-center — GUI for asusctl
• cardwire — GPU Manager that uses eBPF LSM hooks to block GPUs
• linux-ogc — OGC kernel builds
• linux-unstable-ogc — OGC unstable kernel for testing and development b>

This list is maintained by hand. The source of truth for which repos are polled is packages.toml; the list above reflects which package names those sources currently publish.

Using the repo

Add the repo to /etc/pacman.conf:

[ogc]
Server = https://pacman.opengamingcollective.org

Import the signing key so pacman can verify packages and the database:

sudo pacman-key --recv-keys F79100EF8C802DAB81C323BB8EEA5962FE510E19
sudo pacman-key --lsign-key F79100EF8C802DAB81C323BB8EEA5962FE510E19

Install as usual:

sudo pacman -Syu ogc/asusctl

The key fingerprint is F79100EF8C802DAB81C323BB8EEA5962FE510E19, and the public key is published as ogc.asc in this repo.

How it works

A single workflow — .github/workflows/collect.yml — runs hourly on a cron (with a manual dispatch fallback). It reads packages.toml, fetches the existing ogc.db.tar.gz from the bucket, then runs three ingestion passes:

1. Release assets — for each [[packages]] entry, polls the source repo's latest GitHub release and downloads any *.pkg.tar.zst assets not already in the database.
2. Pre-release assets — for each [[package_prerelease]] entry, polls the source repo's latest pre-release (releases flagged pre-release on GitHub) and downloads any *.pkg.tar.zst assets matching the required name_filter that are not already in the database.
3. OCI/ORAS — for each [[images]] entry, resolves the newest build tag that has an image in the OCI registry (walking back through up to the 10 latest git tags until one has a build), pulls the image with ORAS, extracts its *.pkg.tar.zst files, and keeps those not already in the database.

New packages from any pass are GPG-signed, merged into the database via repo-add, and uploaded back to the bucket along with the updated database. The workflow is idempotent — the database itself is the source of truth for what has been ingested, so re-running it changes nothing when there's nothing new.

flowchart LR
    RA["Release-asset sources<br/>(GitHub releases)"] -->|"*.pkg.tar.zst"| WF
    PRE["Pre-release sources<br/>(GitHub pre-releases)"] -->|"*.pkg.tar.zst"| WF
    OCI["OCI/ORAS sources<br/>(OCI artifacts)"] -->|"*.pkg.tar.zst"| WF

    subgraph WF["collect.yml (hourly cron)"]
        direction TB
        W1["Collect & deduplicate"] --> W2["GPG-sign & merge DB"] --> W3["Upload to S3"]
    end

    WF --> S3["S3 bucket<br/>ogc.db.tar.gz<br/>*.pkg.tar.zst"]

Loading

One key signs everything. A single PGP key pair signs every package (gpg --detach-sign) and the database itself (repo-add --sign). Users trust this one key regardless of how many source repos contribute packages or which ingestion path they use. The private key lives only in this repo as the PGP_SIGNING_KEY secret.

Single writer. Only this workflow writes to ogc.db.tar.gz. Source repos never touch the database or the bucket. A concurrency group prevents overlapping runs, so no S3-level locking is needed.

For the full behavioral spec — triggers, concurrency, step-by-step behavior, the dedup/merge pseudocode, and failure-mode recovery — see OPERATIONS.md.

Adding a package

Adding a source is the one thing a contributor does here. No edits to any source repo are required beyond its own normal release process (tag a release, attach *.pkg.tar.zst assets).

Release-asset sources

If the source repo attaches *.pkg.tar.zst files to its GitHub releases:

1. Confirm the source repo's release process attaches *.pkg.tar.zst assets. How it builds them is its own concern.
2. Append a [[packages]] block to packages.toml:

   [[packages]]
   repo = "OpenGamingCollective/<new-package>"
   asset_glob = "*.pkg.tar.zst"

3. Commit and push to the default branch.
4. The next hourly cron run ingests the latest release assets and publishes them. To ingest immediately, run the workflow manually with the repo input set to the new source (see OPERATIONS.md).

Pre-release sources

If the source repo also attaches *.pkg.tar.zst files to its pre-releases (GitHub releases flagged "pre-release", e.g. v0.13.0-alpha.1), and those packages should be published for opt-in consumers, add a [[package_prerelease]] block. This is a separate entry on purpose: a [[packages]] entry never ingests pre-release assets, so consumers of the full releases never auto-update to a pre-release package. The pre-release entry may point at the same repo as a [[packages]] entry or at a different one.

1. Append a [[package_prerelease]] block to packages.toml:

   [[package_prerelease]]
   repo        = "OpenGamingCollective/cardwire"
   asset_glob  = "*.pkg.tar.zst"
   name_filter = "cardwire-*"

   name_filter is required and applies to the asset filename — use it to take only the intended package(s) from a pre-release that may carry extra artifacts.
2. Commit and push to the default branch.
3. The next hourly cron run ingests the latest pre-release's matching assets. To ingest immediately, run the workflow manually with the repo input set to the source (see OPERATIONS.md).

Warning

Keep pre-releases out of stable installs. Everything in this repo shares one package database, so a pre-release package that carries the same name as its release counterpart would silently replace it on the next pacman -Syu — pulling a user who chose the stable package onto testing software they never asked for. It is the package maintainer's job to make sure that can't happen: give pre-release packages their own name (e.g. cardwire-git alongside cardwire) or otherwise version them so pacman never treats them as an upgrade of the release package. Consumers who haven't explicitly installed a pre-release package should never have one appear on their system.

OCI-based sources

For sources that publish *.pkg.tar.zst files as OCI artifacts (built with ORAS, pushed to an OCI registry such as GHCR), use an [[images]] block instead. The source repo must tag its OCI builds as <version>.<build_num> (where <version> is the git tag with the leading v stripped), plus :latest and any content-hash tags. This is what the kernel-packages build workflow does.

1. Confirm the source repo publishes OCI artifacts to a registry this workflow can reach (public GHCR images are pulled anonymously).
2. Append an [[images]] block to packages.toml:

   [[images]]
   source_repo = "OpenGamingCollective/<new-source>"
   image       = "ghcr.io/opengamingcollective/<new-source>-arch"
   asset_glob  = "*.pkg.tar.zst"

   Optionally set tag = "..." to pin a specific build.
3. Commit and push to the default branch.
4. The next hourly cron run resolves the newest build tag that has an image (walking back through up to the 10 latest git tags until one has a build), pulls the image with ORAS, extracts the *.pkg.tar.zst files, and ingests any not already in the database. To run immediately, trigger the workflow manually with the repo input set to the new source_repo (see OPERATIONS.md).

packages.toml spec

This file is the registry of all ingestion sources. It contains three kinds of entries: [[packages]] for sources that attach *.pkg.tar.zst files to full GitHub releases, [[package_prerelease]] for sources that attach *.pkg.tar.zst files to pre-release GitHub releases, and [[images]] for sources that publish *.pkg.tar.zst files as OCI artifacts (pulled with ORAS). Adding a source means appending a block and committing — the next hourly cron ingests it.

[[packages]] fields

Field	Type	Required	Description
[[packages]]	table	yes	Marks the start of a release-asset ingestion entry. One per source repo.
repo	string	yes	GitHub repository in owner/name form, e.g. OpenGamingCollective/asusctl. The latest release's assets are polled.
asset_glob	string	yes	Glob pattern matching the release assets to fetch. Almost always *.pkg.tar.zst.

[[package_prerelease]] fields

Field	Type	Required	Description
[[package_prerelease]]	table	yes	Marks the start of a pre-release ingestion entry. Standalone — its repo may duplicate a [[packages]] repo or point elsewhere.
repo	string	yes	GitHub repository in owner/name form. The latest release flagged pre-release on GitHub (drafts excluded) is polled.
asset_glob	string	yes	Glob pattern matching the release assets to fetch. Almost always *.pkg.tar.zst.
name_filter	string	yes	Required glob applied to the asset filename; only assets matching both asset_glob and name_filter are ingested. Scopes which packages a pre-release contributes.

[[images]] fields

Field	Type	Required	Description
[[images]]	table	yes	Marks the start of an OCI/ORAS ingestion entry. One per OCI image.
source_repo	string	yes	GitHub repository in owner/name form whose latest git tag is used to resolve which OCI tag to pull, e.g. OpenGamingCollective/kernel-packages.
image	string	yes	OCI image ref to pull from, e.g. ghcr.io/opengamingcollective/kernel-packages-arch.
asset_glob	string	yes	Glob pattern matching the extracted files to ingest. Almost always *.pkg.tar.zst.
tag	string	no	Explicit OCI tag to pull. If set, tag resolution is skipped and this tag is used verbatim. If unset, the workflow reads source_repo's latest git tag (e.g. v7.1.3-ogc3.2), strips the leading v, and picks the numerically highest build tag matching <version>.<N> from the OCI registry (e.g. 7.1.3-ogc3.2.5).

Example

# Registry of ingestion sources for ogc.db.tar.gz.
# To add a release-asset source:     append a [[packages]] block and commit. The hourly cron will pick it up.
# To add a pre-release asset source: append a [[package_prerelease]] block and commit. The hourly cron will pick it up.
# To add an OCI/ORAS source:        append an [[images]] block and commit. The hourly cron will pick it up.

[[packages]]
repo = "OpenGamingCollective/asusctl"
asset_glob = "*.pkg.tar.zst"

[[package_prerelease]]
repo        = "OpenGamingCollective/cardwire"
asset_glob  = "*.pkg.tar.zst"
name_filter = "cardwire-*"

[[images]]
source_repo = "OpenGamingCollective/kernel-packages"
image       = "ghcr.io/opengamingcollective/kernel-packages-arch"
asset_glob  = "*.pkg.tar.zst"

Every merge request runs a schema check on packages.toml (scripts/validate_packages_toml.py, via .github/workflows/validate-toml.yml) — invalid blocks (missing fields, unknown keys, a missing name_filter on a pre-release entry) fail the MR before merge. The same check runs at the start of every collect run.

Limitations

• x86_64 only. Whatever architectures the source repos attach is what gets served. If aarch64 or others are added later, the dedup logic must account for the -<arch> suffix in filenames to avoid cross-arch collisions.
• No pruning. When a new version of a package is ingested, repo-add updates the database entry to point at the new file, but the old .pkg.tar.zst and .sig files are not deleted from S3. Old versions remain reachable via their direct URL, enabling manual rollback or pinning. The bucket grows over time — this is accepted.
• Hourly polling only. There is no real-time ingestion. Expected lag between a source repo publishing a release and the package appearing in ogc is under an two hours (GitHub scheduled runs can be delayed during busy periods).