DEV Community: Gouranga Das Samrat

From One Merged PR to a Repology Page: A Termux Maintainer Roundup

Gouranga Das Samrat — Wed, 26 Aug 2026 05:44:45 +0000

A few weeks ago, running pkg show on my own phone and seeing my name next to Maintainer: felt like a fluke. It wasn't a plan — it was one feature request for a password manager CLI that turned into weeks of build-system archaeology. Since then it hasn't really stopped.

I've written four posts about individual pieces of this so far. This one is the zoomed-out version — everything currently sitting across termux/termux-packages (the main repo) and termux/termux-user-repository (TUR), plus what's shipped since the last post that I haven't written up on its own yet. If you want the receipts instead of my word for it, my Repology maintainer page tracks every package live under my name in real time.

The story so far

In case you're coming in fresh, here's the series in order:

From a High School Termux User to a Package Maintainer — how proton-pass-cli became my first merge on the main repo, and the sqlcipher symlink bug it dragged along with it.
Rejected on Main, Accepted on TUR — nine Nerd Fonts packages that didn't fit the main repo's size policy, and my first merge on TUR instead.
From a 4-Year-Old Feature Request to pkg install bun — closing a four-year-old issue by moving bun from a rejected main-repo PR to a TUR merge.
The Day I Merged 6 Go Packages Into Termux Before Dinner — goimports, golangci-lint, air, gotests, goreleaser, and govulncheck, all merged in one sitting.

Everything below picks up right after that last post.

Main repo: cleanup, then a second wave

The six Go packages didn't land perfectly clean. Right after merge, each one still carried a build dependency it didn't actually need at runtime, so I went back through all six with individual fix PRs: goimports, golangci-lint, air, goreleaser, gotests, and govulncheck. Small, boring PRs — the kind that don't make for a good story on their own, but matter for anyone who installs these packages later. govulncheck also got bumped to 1.7.0 the same day.

With the toolkit's foundation cleaned up, I kept adding to it:

git-cliff — changelog generator driven by conventional commits.
git-absorb — automatically absorbs staged changes into the right earlier commits.
gtrash — a trash can for the CLI, so rm stops being permanent by accident.
sqlc — generates type-safe code straight from SQL.
golang-migrate — database migrations, CLI and library both.
gotestsum — a nicer go test output wrapper, pairs naturally with gotests from the earlier batch.

And proton-pass-cli, the package that started all of this, got bumped to 2.3.3 — still getting routine maintenance almost two weeks after the original merge.

Not everything from this stretch made it into the main repo, and that's expected at this point: PR #31157 (the original 9-font attempt) and PR #31115 (the prebuilt-binary bun attempt) both closed on policy grounds, and PR #31013 closed as a duplicate of a fix that landed first. All three have their full story in the earlier posts — I'm only listing them here so the trail is complete.

TUR: the fonts grow up

TUR has been quieter in terms of headline moments, but not idle. The eight Nerd Fonts packages from PR #2743 started out as eight independent ttf-*-nerd packages. In PR #2755 I refactored all eight into a single unified nerd-fonts parent/subpackage structure and bumped everything to v3.5.1 — one source package, eight subpackages, instead of eight nearly-identical build.sh files to keep in sync by hand. It hit the usual round of CI friction along the way (a missing cache directory variable, an overlength description, a license auto-detection miss, an array-vs-scalar source URL, a subpackage dependency value that needed correcting) — nothing dramatic, just the kind of thing that shows up once you actually run a consolidation through CI instead of just planning it.

Right after that, PR #2762 added a dependency on the main repo's pre-existing ttf-nerd-fonts-symbols package, to match how Arch handles the same font set — closing a small naming/parity gap that had been sitting there since the original PR.

bun also has a bump sitting as a draft — 1.4.0, not merged yet. And there's an early-stage docker-qemu package in draft too, at PR #2708.

Where things stand

Two repos, two different sets of rules, and by now a pattern I'm used to: try the main repo first, and if the policy genuinely doesn't fit — package count discipline, source-build requirements — TUR is where it goes instead, not a consolation prize.

The Repology maintainer page is the easiest way to see the live total, since PR merges don't always mean immediate publish. As of today it lists 15 distinct projects across both repos — 13 on Termux's main repo, 2 on TUR — every single one at 100% newest, with nothing outdated, problematic, or flagged as potentially vulnerable:

air-live-reload, bun, fonts:nerd-fonts, git-absorb, git-cliff, go:migrate, goimports, golangci-lint, goreleaser, gotests, gotestsum, govulncheck, gtrash, proton-pass-cli, sqlc

Two entries are worth a second look because the names don't match the PR titles: Repology tracks air under its upstream project name air-live-reload, and golang-migrate as go:migrate. The other one is fonts:nerd-fonts showing up as a single TUR project instead of eight — which is exactly what PR #2755 was for. The consolidation into one parent/subpackage structure didn't just clean up the build.sh files, it collapsed the whole set into one tracked project on Repology too.

The Day I Merged 6 Go Packages Into Termux Before Dinner 🐹

Gouranga Das Samrat — Mon, 24 Aug 2026 04:27:22 +0000

I didn't wake up planning to get six pull requests merged. I just wanted to add one missing Go tool to termux/termux-packages. Then I figured, while I'm in here, why not bring the rest of my Go toolkit along too? A few hours and six PRs later, all of them were sitting in main.

Here's how it went down — and what actually shipped.

What Landed

Termux users can now pkg install a proper Go developer toolkit, straight from the official repo:

goimports 0.49.0 — the tool that quietly fixes your import block, adding what's missing and trimming what isn't used anymore. Learn more →
golangci-lint 2.13.1 — dozens of Go linters bundled into one fast binary. At 45 MB installed, it's the heavyweight of the group, but worth every megabyte. Learn more →
air 1.67.4 — live reload for Go apps, so your binary rebuilds and restarts the second you save a file. Learn more →
gotests 1.9.0 — generates table-driven test scaffolding straight from your source, so you stop typing the same boilerplate. Learn more →
goreleaser 2.17.1 — packages and ships Go binaries in one command, cross-compilation included. Learn more →
govulncheck 1.1.4 — scans your code and dependencies for known vulnerabilities. Learn more →

Six packages, one theme: making Termux a real place to write Go.

The Curveball: A Last-Minute Rebase

Right as review was wrapping up, maintainer @robertkirkman asked for something I hadn't planned for: rebase and force-push all six PRs so they'd recompile against the just-released Go 1.27.0. You can see the ask in the goimports thread.

No arguing with that logic — better to ship on the latest compiler than patch it later. I rebased all six branches, force-pushed, and got a quick "Thank you!" in response. Not long after, the merges started coming in one by one.

Proof It's Real

Once everything landed, I ran the most satisfying command in the Termux workflow — pkg show — against all six:

Package: goimports        | 0.49.0  | https://pkg.go.dev/golang.org/x/tools/cmd/goimports
Package: golangci-lint    | 2.13.1  | https://golangci-lint.run/
Package: air              | 1.67.4  | https://github.com/air-verse/air
Package: gotests           | 1.9.0   | https://github.com/cweill/gotests
Package: goreleaser        | 2.17.1  | https://goreleaser.com
Package: govulncheck       | 1.1.4   | https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck

Six for six. All installable right now with:

pkg install goimports golangci-lint air gotests goreleaser govulncheck

What I'd Tell Someone Trying This Themselves

Batch related packages together. Reviewers can apply one piece of feedback — like a compiler bump — across the whole set instead of repeating themselves six times.

Move fast on review feedback. The gap between "please rebase" and "rebased and pushed" is often the difference between a PR that merges today and one that sits for a week.

Don't underestimate the boring packages. None of these tools are glamorous. Together, though, they turn a phone into a legitimate Go dev environment.

Thanks to @robertkirkman and the rest of the termux/termux-packages team for the fast, thorough reviews. More packages coming soon.

Working on a Go tool you think Termux is missing? Tell me about it in the comments — I'm always looking for the next PR.

HLD: Notification System

Gouranga Das Samrat — Sun, 23 Aug 2026 02:00:00 +0000

Design a notification system that sends push notifications, emails, and SMS to users based on events in the platform.

1️⃣ Clarify Requirements

Functional Requirements

Send notifications via: Push (iOS/Android), Email, SMS
Trigger types: real-time (someone liked your post) and scheduled (weekly digest)
Users can set preferences: opt-in/out per channel and notification type
Support for templated notifications (not hardcoded)
Delivery guarantee — important notifications must not be dropped

Non-Functional Requirements

High throughput — 10M notifications/day
Low latency for real-time notifications (< 5 seconds)
Reliability — retry on failure
Scalability — handle spikes (breaking news, product launches)
Observability — track delivered/failed/opened

2️⃣ Estimate Scale

Notifications/day: 10M
Notifications/sec: 10M / 86,400 ≈ 116/sec (avg)
Peak: 1,000/sec (event spikes)

Breakdown:
  Push: 60% → 6M/day
  Email: 30% → 3M/day
  SMS: 10% → 1M/day

Storage (notification log):
  1 record ≈ 500 bytes
  10M/day × 500B = 5 GB/day
  Retention: 90 days → 450 GB

3️⃣ API Design

# Send a notification (internal service call)
POST /notifications/send
Body: {
  "userId": "user_123",
  "type": "like_received",
  "channels": ["push", "email"],  // or leave empty → use user preferences
  "data": {
    "actorName": "Rahul",
    "postTitle": "My Design Notes"
  }
}

# User preference management
GET  /users/:userId/notification-preferences
PUT  /users/:userId/notification-preferences
Body: {
  "push": { "like_received": true, "new_follower": true, "marketing": false },
  "email": { "weekly_digest": true, "marketing": false }
}

# Scheduled notifications
POST /notifications/schedule
Body: {
  "templateId": "weekly_digest",
  "scheduledAt": "2024-01-15T09:00:00Z",
  "userSegment": "active_users"
}

4️⃣ High-Level Architecture

[Event Sources]
  - User Service ("user A liked post")
  - Order Service ("your order shipped")
  - Scheduler ("send weekly digest")
        │
        ▼
[Notification Service API]
        │
        ├─► Check User Preferences → skip if opted out
        ├─► Build notification from template
        ├─► Route to appropriate channels
        │
        ▼
[Message Queue (Kafka / SQS)]
  ├──► [Push Queue]
  ├──► [Email Queue]
  └──► [SMS Queue]
        │
        ▼
[Channel Workers]
  ├──► [Push Worker] → FCM (Android) / APNs (iOS)
  ├──► [Email Worker] → SendGrid / SES / Mailgun
  └──► [SMS Worker] → Twilio / SNS
        │
        ▼
[Delivery Log DB] ← track status per notification

5️⃣ Component Deep Dives

Preference Service

# User preferences (stored in DB, cached in Redis)
preferences = {
  "push": {
    "like_received": True,
    "new_follower": True,
    "marketing": False
  },
  "email": {
    "weekly_digest": True,
    "security_alert": True,
    "marketing": False
  },
  "sms": {
    "security_alert": True,
    "marketing": False
  }
}

def should_notify(userId, notifType, channel):
    prefs = redis.get(f"prefs:{userId}") or db.get(userId)
    return prefs.get(channel, {}).get(notifType, True)  # default: on

Template Service

// Template: "like_received"
{
  "templateId": "like_received",
  "push": {
    "title": "{{actorName}} liked your post",
    "body": "\"{{postTitle}}\" is getting attention!"
  },
  "email": {
    "subject": "{{actorName}} liked your post",
    "templateFile": "like-received.html"
  }
}

Render: inject actual values, produce final notification content.

Push Notification Worker

def send_push(notification):
    device_tokens = db.get_device_tokens(notification.userId)

    for token in device_tokens:
        if token.platform == "android":
            fcm.send({
                "token": token.value,
                "title": notification.title,
                "body": notification.body,
                "data": notification.data
            })
        elif token.platform == "ios":
            apns.send({
                "deviceToken": token.value,
                "aps": { "alert": { "title": notification.title, "body": notification.body } }
            })

Retry & Dead Letter

Worker fails to send → retry with exponential backoff
  Attempt 1: immediate
  Attempt 2: 30 seconds
  Attempt 3: 5 minutes
  Attempt 4: 30 minutes
  Attempt 5: DLQ (manual inspection or discard)

6️⃣ Database Schema

-- Notification log (Cassandra — write-heavy, time-series)
CREATE TABLE notifications (
  notification_id  UUID,
  user_id          BIGINT,
  type             VARCHAR(50),
  channel          VARCHAR(20),  -- push/email/sms
  status           VARCHAR(20),  -- pending/sent/failed/delivered/opened
  payload          JSONB,
  created_at       TIMESTAMP,
  sent_at          TIMESTAMP,
  PRIMARY KEY (user_id, created_at, notification_id)
) WITH CLUSTERING ORDER BY (created_at DESC);

-- User device tokens
CREATE TABLE device_tokens (
  user_id    BIGINT,
  token      TEXT,
  platform   VARCHAR(10),  -- ios/android/web
  created_at TIMESTAMP,
  PRIMARY KEY (user_id, token)
);

-- User preferences (PostgreSQL, read-heavy)
CREATE TABLE notification_preferences (
  user_id     BIGINT PRIMARY KEY,
  preferences JSONB,
  updated_at  TIMESTAMP
);

7️⃣ Handling Scale Spikes

Event: Product Launch → 10M users notified

Problem: Sudden flood of 10M notifications in seconds.

Solution: Rate limiting the outbound queue

Email: SendGrid allows 1000 emails/sec
→ Queue backs up → workers drain at 1000/sec → all 10M sent in ~3 hours
→ Users get it "within a few hours" → acceptable for marketing

Priority Queues

HIGH priority queue:   security alerts, OTPs → process immediately
MEDIUM priority queue: social notifications → within seconds
LOW priority queue:    marketing, digests → within hours

Workers check HIGH first, then MEDIUM, then LOW.

8️⃣ Observability

Track every notification:

Events to log:
  - notification_queued     (timestamp, userId, type, channel)
  - notification_sent       (timestamp, provider response)
  - notification_delivered  (timestamp, from FCM/APNs delivery receipt)
  - notification_opened     (timestamp, from SDK tracking)
  - notification_failed     (timestamp, error, retryCount)

Metrics:
  - Delivery rate per channel
  - Average send latency (queued → sent)
  - Failure rate per provider
  - Open rate per notification type

🎨 Diagram

The diagram shows:

Event sources → Notification Service → Kafka queues → channel workers → external providers
Preference check before queuing
Template rendering step
Retry with DLQ
Priority queue lanes (high/medium/low)
Delivery status tracking

✅ Trade-offs Summary

Decision	Choice	Rationale
Queue type	Kafka/SQS	Decouple events from delivery, absorb spikes
Priority	Multiple queues	Don't let marketing delay OTPs
Retry	Exponential backoff	Avoid hammering failed providers
Preference storage	Redis cache + DB	Fast reads on every notification
Delivery tracking	Cassandra	High-volume, time-series write pattern

HLD: URL Shortener (like bit.ly)

Gouranga Das Samrat — Sat, 22 Aug 2026 02:00:00 +0000

Design a system that takes a long URL and returns a short URL, and redirects short URLs to their originals.

1️⃣ Clarify Requirements

Functional Requirements

Given a long URL, generate a short URL
Given a short URL, redirect to the original long URL
(Optional) Custom aliases: short.ly/my-brand
(Optional) URL expiration
(Optional) Analytics: click count, referrer, location

Non-Functional Requirements

High availability — downtime = broken links everywhere
Low latency redirects — < 10ms (cached)
Durability — shortened URLs should work for years
Reads >> Writes (100:1 read-to-write ratio typical)

2️⃣ Estimate Scale

Write QPS:
  10M URLs shortened per day
  = 10M / 86,400 ≈ 115 writes/sec

Read QPS (100:1 ratio):
  100 × 115 = 11,500 reads/sec
  Peak: ~50,000 reads/sec

Storage:
  Each record: shortURL(7B) + longURL(200B) + metadata(100B) ≈ 307 bytes
  10M URLs/day × 10 years = 36.5B URLs
  36.5B × 307 bytes ≈ 11 TB (very manageable)

Cache:
  80% reads on 20% of URLs (Pareto principle)
  Cache 20% of daily URLs: 10M × 0.2 × 307B ≈ 600 MB/day

3️⃣ API Design

# Create short URL
POST /api/shorten
Body: { "longUrl": "https://...", "customAlias": "optional", "expiresAt": "optional" }
Response: { "shortUrl": "https://short.ly/abc1234" }

# Redirect
GET /:shortCode
Response: 301/302 Redirect to longUrl

# Analytics (optional)
GET /api/stats/:shortCode
Response: { clicks: 1000, topCountries: [...] }

301 vs 302:

301 Permanent → browser caches redirect → fewer server hits → can't update
302 Temporary → browser always checks server → can update/expire → use this for analytics

4️⃣ Short Code Generation

Option A: Hash + Truncate

MD5(longURL) = "1a79a4d60de6718e8e5b326e338ae533"
Take first 7 chars: "1a79a4d"
shortURL: short.ly/1a79a4d

Problem: Collisions — different URLs can produce same 7-char prefix.

Option B: Base62 Encoding (Recommended)

Character set: [0-9a-zA-Z] = 62 characters

7 characters × 62^7 = 3.5 trillion unique codes ✅

ID: 123456789
Base62(123456789) = "8M0kX"
shortURL: short.ly/8M0kX

Where does the ID come from?

Auto-increment DB ID — simple, but reveals volume/sequence
UUID — random, no collision, but long → truncate carefully
Snowflake ID — distributed, time-sortable, unique (Twitter's approach)

Option C: Counter Service

A dedicated service generates unique IDs:

Counter Service: ID = 1, 2, 3, ... (globally unique)
URL Service: Base62(ID) → short code

5️⃣ High-Level Design

                                    [Cache (Redis)]
                                          │
Client ──► [API Gateway + LB] ──► [URL Service] ──► [DB (PostgreSQL)]
                                          │
                                   [Analytics Queue]
                                          │
                                   [Analytics DB]

Redirect flow:
Client ──GET /abc1234──► [URL Service]
                              │
                    ┌─── Redis HIT → 302 Redirect ──► Client
                    │
                    └─── Redis MISS → DB query → cache → 302 Redirect

6️⃣ Database Schema

CREATE TABLE urls (
  id           BIGSERIAL PRIMARY KEY,
  short_code   VARCHAR(10) UNIQUE NOT NULL,
  long_url     TEXT NOT NULL,
  user_id      BIGINT,
  created_at   TIMESTAMP DEFAULT NOW(),
  expires_at   TIMESTAMP,
  click_count  BIGINT DEFAULT 0
);

CREATE INDEX idx_short_code ON urls(short_code);

-- Analytics table
CREATE TABLE clicks (
  id          BIGSERIAL PRIMARY KEY,
  short_code  VARCHAR(10),
  clicked_at  TIMESTAMP DEFAULT NOW(),
  country     VARCHAR(2),
  referrer    TEXT,
  user_agent  TEXT
);

7️⃣ Caching Strategy

Key:   short_code ("abc1234")
Value: long_url
TTL:   24 hours (refresh on hit if needed)

Cache-aside:
1. Check Redis for short_code
2. MISS → query PostgreSQL → store in Redis with TTL
3. HIT → return long_url immediately

Cache hit rate target: >95% (80/20 rule — most traffic on top URLs)

8️⃣ Scalability Deep Dive

Read Scaling

Redis cache handles ~95% of redirect traffic
Read replicas for the remaining DB reads
CDN for the redirect response itself (if 301)

Write Scaling

Writes (new URLs) are much rarer — primary DB + async replication is fine
If needed: hash short_code → route to shard

High Availability

Redis Sentinel or Cluster for cache HA
DB: Primary + read replicas + automated failover
Multiple URL service instances behind LB

9️⃣ Custom Aliases & Expiry

def shorten(long_url, custom_alias=None, expires_at=None):
    if custom_alias:
        if db.exists(custom_alias):
            raise ConflictError("Alias taken")
        short_code = custom_alias
    else:
        id = db.insert(long_url)
        short_code = base62_encode(id)

    db.store(short_code, long_url, expires_at)
    return f"https://short.ly/{short_code}"

def redirect(short_code):
    url_data = cache.get(short_code) or db.get(short_code)
    if not url_data:
        raise NotFoundError()
    if url_data.expires_at and url_data.expires_at < now():
        raise GoneError()  # 410 Gone
    return url_data.long_url

🎨 Diagram

The diagram shows:

Full system: Client → LB → URL Service → Redis → PostgreSQL
Shorten flow vs redirect flow (separate paths)
Cache hit vs miss paths
Analytics async flow via queue
DB schema with indexes highlighted

✅ Trade-offs Summary

Decision	Choice	Trade-off
301 vs 302	302	More server hits, but analytics & expiry work
ID generation	DB auto-increment + Base62	Simple but sequential — use Snowflake for privacy
Cache TTL	24hr	Stale entries for expired/deleted URLs
SQL vs NoSQL	PostgreSQL	Simple queries, ACID for uniqueness

From a 4-Year-Old Feature Request to `pkg install bun`: My Second Merge on the Termux User Repository

Gouranga Das Samrat — Fri, 21 Aug 2026 09:35:47 +0000

Last post i wrote was about getting turned away from the main repo over a policy disagreement and landing my first TUR merge instead with 8 Nerd Fonts packages.

This is the same shape of story again, except the "no" from the main repo wasn't about repo size this time — it was about something much harder to argue around: how Termux insists packages get built.

An issue older than some of the tools people used to work around it

Issue #11188 asking for bun in Termux goes back to July 2022, opened by @leap0x7b. Reading the whole thread back to front is basically a history of people improvising around a missing package for four straight years:

Early on, bun's Linux aarch64 build just didn't run on Android — npm install -g bun failed outright with an EBADPLATFORM error, because upstream hadn't shipped an Android target.
The workaround that kept surfacing was grun, a glibc compatibility shim, letting people run the Linux binary against a glibc environment layered on top of Termux's normal Bionic libc. It mostly worked, with recurring reports of install failures (AccessDenied errors from bun install trying to hardlink files) and one-off fixes like bun install --backend=copyfile.
A few people tried building bun from source directly. That hit its own wall: Bun's own docs state that Bun itself must be installed to compile Bun — you need an existing bun binary just to build a new one — plus a strict Zig version dependency that broke against whatever Termux had packaged at the time.
@TomJo2000 summed up the stall bluntly in mid-2025: nobody had written a build script, no other distro built it from source either, and it depended on a kernel version most Android devices didn't meet.

The turn came in April 2026, when @licy183 flagged that upstream had finally added an Android build target. @TomJo2000 noted the obvious next step — someone still had to actually write the build script. By mid-May, @Jobians confirmed Bun was running natively using the official Android ARM64 build. The pieces were finally there. I decided to be the one to write the script.

Round one: prebuilt binaries, meet main-repo policy

I opened termux-packages PR #31115 — addpkg(main/bun): 1.3.14 — built around the official prebuilt Android binaries that shipped in Bun v1.3.14. The binaries are Position-Independent Executables linked straight against standard Bionic libraries (libc.so, libm.so, libdl.so), so no glibc shim needed at all — a real fix for the grun workaround people had been leaning on for years. The only real limitation was architecture: upstream only builds Android targets for aarch64 and x86_64, so I set those two as excluded-safe and expected arm/i686 to just skip cleanly in CI.

@robertkirkman stopped that approach at the door: termux-packages requires compiling from source, so downloading upstream's prebuilt binaries wasn't going to fly. He floated a specific alternative — if Bun were published as an installable crate on crates.io, cargo-binstall could fetch upstream binaries in a way the main repo's tooling already sanctions. Worth checking, but it didn't pan out: Bun isn't a simple Rust crate at all. It's a monorepo built through its own CMake pipeline, linking against JavaScriptCore/WebKit and LLVM — nothing cargo build --release or cargo-binstall can touch.

There was a fun tangent buried in the same exchange — @robertkirkman noting Node.js is already built from source in Termux and reasoning Bun should in theory be possible too, then wondering out loud whether Bun is meaningfully faster than both Node and Deno (Deno also being a from-source build in Termux) — the kind of "is this actually a different tool or just a faster clone" curiosity that comes up naturally whenever a runtime like this gets proposed.

I went and actually tried the from-source route properly, then came back and closed the PR myself on August 20 with a detailed writeup of exactly where it broke down:

Bun's build system does have official Android cross-compile support (--abi=android, --android-ndk=<path>), confirmed against the pattern in its .buildkite/Dockerfile (NDK r27c, host-clang + sysroot).
WebKit doesn't need a from-source build for Android — a prebuilt tarball gets fetched automatically, so that wasn't the blocker I expected.
The actual wall was a statically, cross-compiled ICU for Android ($BUN_ANDROID_ICU_ROOT) with no public build recipe I could find anywhere — not in oven-sh/bun, not in oven-sh/bun-development-docker-image, not in the actual .buildkite/Dockerfile, despite a comment in webkit.ts pointing at a "Dockerfile.android" that doesn't seem to exist publicly.

Add a strictly pinned LLVM 21.1.8 and a pinned Rust nightly on top of that, and it was more toolchain archaeology than I could commit to finishing in one PR. So I closed it, thanked @robertkirkman for the guidance, and left the door open to revisit if upstream's Android/ICU story ever gets easier to build from source.

The TUR side already had its own long-running Bun request

There was already a parallel thread for this on TUR: tur issue #571, opened back in 2023 by @earningpoints. @licy183 had kept it open rather than closing it outright, citing two blockers at the time — Bun's kernel 5.1 requirement, which most Android devices didn't meet, and the fact that it didn't compile against non-glibc libcs like musl. @jothi-prasath tried getting it running via grun and shared a working build script, but @licy183 was clear about where TUR draws its own line: binaries in TUR packages need to link against Bionic libc, not GNU libc, with no plan to support a custom-loader GNU libc setup.

That distinction turned out to matter a lot for round two — because the whole reason the official Bun v1.3.14 Android binaries worked for Termux at all is that they're linked directly against Bionic. No grun, no glibc shim, no custom loader path. They fit TUR's actual requirement perfectly; they just didn't fit the main repo's from-source rule.

Round two: TUR PR #2746

I opened tur PR #2746 — same package, same version, same prebuilt-binary approach — explicitly closing both threads at once: Fixes termux/termux-packages#11188 #571, with a note that it was migrated from PR #31115 specifically because of the main repo's build-from-source policy. No repeat of the source-vs-prebuilt argument — TUR's policy is built for exactly this kind of package.

Review was quick and purely technical. @licy183 caught an inefficiency in build.sh: rather than my approach, the more common pattern is to download binaries for both aarch64 and x86_64 up front and only install the one matching the build architecture — pointing me at how pypy3's build script already does it. I made the change same day. A second review comment flagged that my binary-path handling was split oddly across build steps — it only needed to run in termux_step_make_install, while termux_step_post_get_source should just be fetching the LICENSE file. I moved the logic accordingly.

Then: a simple "Thanks!" from @licy183, and that was that.

What changed, twice over

The version string says 1.3.14, same as the PR I closed on the main repo, but what actually shipped is bigger than the number:

A four-year-old feature request that survived grun hacks, glibc shims, Zig version breakage, and a genuine "you need Bun to build Bun" chicken-and-egg problem, finally resolved with pkg install bun.
A real technical answer, on the record, for why termux-packages couldn't take it as-is: a from-source Android build is blocked on a static cross-compiled ICU with no public recipe — useful for whoever eventually revisits it.
Confirmation from TUR's side of exactly which binaries are acceptable there: Bionic-linked, no glibc shim required — which is exactly what upstream Bun now ships.

Two PRs in a row now where the front door said no for a real, defensible reason, and TUR turned out to be exactly the right back door. Different reasons each time — repo-size policy for the fonts, source-build policy for Bun — but the same shape of resolution. I'm starting to think that's just what TUR is for.

Get it

If you're on Termux and TUR isn't already added as a repo, three commands and bun is installed with no grun, no glibc shim, none of the workarounds from that four-year thread:

pkg install tur-repo
pkg update
pkg install bun

Proof it's live:

~ $ pkg show bun
Package: bun
Version: 1.3.14-1
Maintainer: Gouranga Das Samrat <gouranga.das.khulna@gmail.com>
Installed-Size: 89.8 MB
Homepage: https://bun.com
Download-Size: 22.8 MB
APT-Sources: https://tur.kcubeterm.com tur-packages/tur aarch64 Packages
Description: Incredibly fast JavaScript runtime, bundler, test runner, and package manager

The full trail:

Rejected on Main, Accepted on TUR: How 8 Nerd Fonts Became My First Merge on the Termux User Repository

Gouranga Das Samrat — Thu, 20 Aug 2026 16:57:28 +0000

I wrote before about the day proton-pass-cli merged into termux-packages — my first merge into the main repo, full stop. This post is about what happened right after: I tried to do it again with nine fonts, got talked out of it on the main repo, and ended up with my first merge on TUR instead — 8 packages, all in one shot.

Round one: nine fonts, one PR, the main repo

I opened termux-packages PR #31157 — addpkg(nerd-fonts): add 9 Nerd Fonts packages (v3.5.0). The plan: pull nine fonts from the v3.5.0 release of ryanoasis/nerd-fonts, package each as its own opt-in .deb following the same pattern as the existing ttf-jetbrains-mono, and ship only the plain Regular/Bold/Italic/BoldItalic styles to keep things lean.

@robertkirkman was first to comment, and it wasn't about the packages themselves — it was naming. Termux already had ttf-nerd-fonts-symbols, which mirrors Arch Linux's naming convention, so he asked me to rename all nine of mine to match it too. Fair catch — I'd shipped them as ttf-<font>-nerd-font, and I renamed everything to ttf-<font>-nerd the same day.

That turned out to be the easy part.

Round one, continued: the argument that actually mattered

Somewhere in review, @TomJo2000 raised a concern about repo size — enough that my next comment opened with thanking him for it directly, even though he hadn't posted publicly in the thread yet. I made the case for keeping all nine anyway: Homebrew and Arch both ship every Nerd Font as its own opt-in package, nothing else in Termux would depend on mine so there's zero cost to anyone who skips them, and ttf-jetbrains-mono already set the precedent. I even offered to trim styles further if size was the real issue.

@robertkirkman didn't disagree with the utility — he laid out why Termux draws the line differently than Homebrew or Arch in the first place. Termux sits at a little over 3,000 packages; those other ecosystems are past 10,000. The project's focus, as he put it, is packages that are otherwise inconvenient to get running on Android — not "niche, static cosmetic assets that never require patching to work directly copied and pasted into Termux, like wallpapers, fonts, themes and icon packs." He did concede the fonts had a genuinely high Repology score, and offered a condition: add them once at least one other person actually asks.

I pushed back on that condition specifically, because it's a trap by design — once a PR like mine is sitting open and visible, anyone who wants the package just watches the PR instead of filing a separate request, so the bar never gets cleared. I tried a subset compromise (trim the heaviest fonts, keep the rest), pointed to PR #29412 (OBS Studio) as a case where real demand never shows up as comments on an open PR, and floated moving everything to TUR if it stayed stuck.

@robertkirkman held the line on the condition, and also corrected my OBS comparison — that PR wasn't stalled from lack of interest, it was blocked on an unresolved Android 7 compatibility bug being discussed mostly on Discord, not GitHub. @TomJo2000 weighed in too, rejecting the "ship a subset" middle ground outright and pointing out that termux-styling has its own version of this exact problem already.

I tried one more angle — comparing font packages to -static libraries that already sit in the main repo with zero reverse dependencies — which pulled the thread into a genuinely interesting tangent about why Termux ships -static packages at all. @robertkirkman pointed to portaudio-static easing a real packaging headache for CDP8 and to PR #29787 as an example of the maintenance cost involved; @TomJo2000 admitted he wasn't even sure why they're split out in the first place, guessing it predates his time on the project. Somewhere in there I also brought up that sqlcipher itself had zero reverse dependencies in the main repo right up until I shipped proton-pass-cli #30987 — which @robertkirkman settled with a technical clarification: the no-reverse-dependency rule mainly targets packages that only drop files into lib, libexec, share, or opt. sqlcipher always shipped an executable in bin too, so it was never actually in violation.

None of that moved the font policy itself. So I closed the PR myself and did what I'd already floated: took it to TUR.

Round two: TUR PR #2743

TUR exists precisely for software that's useful and wanted but doesn't fit the main repo's policy — so I opened tur PR #2743, explicitly noting in the description that it was migrated from termux/termux-packages#31157 "to respect main repo's policies." Iosevka got dropped along the way, so this round shipped eight fonts, not nine — though the PR title, copy-pasted from the original, still says "9 Nerd Fonts packages" even with a table listing exactly eight underneath it. Nobody caught it, and honestly, neither did I until just now.

This time there was no policy fight — just infrastructure. @robertkirkman flagged that a GitHub race condition was currently blocking the creation of new package repos in TUR, so merging would have to wait. A couple hours later, @licy183 stepped in, offering to manually set up a nerd-fonts repository in tur-dists in the meantime, with a longer-term fix — retrying the upload script up to five times with a one-second sleep between attempts — planned for the following weekend.

It worked.

Proof it's real

~ $ pkg search '^ttf-.*nerd'
ttf-cascadia-code-nerd/tur-packages 3.5.0 all
  Cascadia Code patched with Nerd Fonts icons/glyphs (Font Awesome, Devicons, Octicons, Powerline, etc)

ttf-hack-nerd/tur-packages 3.5.0 all
  Hack patched with Nerd Fonts icons/glyphs (Font Awesome, Devicons, Octicons, Powerline, etc)

ttf-inconsolata-nerd/tur-packages 3.5.0 all
  Inconsolata patched with Nerd Fonts icons/glyphs (Font Awesome, Devicons, Octicons, Powerline, etc)

ttf-jetbrains-mono-nerd/tur-packages 3.5.0 all
  JetBrains Mono patched with Nerd Fonts icons/glyphs (Font Awesome, Devicons, Octicons, Powerline, etc)

ttf-meslo-nerd/tur-packages 3.5.0 all
  Meslo (MesloLGS) patched with Nerd Fonts icons/glyphs (Font Awesome, Devicons, Octicons, Powerline, etc), commonly used with Powerlevel10k

ttf-roboto-mono-nerd/tur-packages 3.5.0 all
  Roboto Mono patched with Nerd Fonts icons/glyphs (Font Awesome, Devicons, Octicons, Powerline, etc)

ttf-sourcecodepro-nerd/tur-packages 3.5.0 all
  Source Code Pro patched with Nerd Fonts icons/glyphs (Font Awesome, Devicons, Octicons, Powerline, etc)

ttf-victor-mono-nerd/tur-packages 3.5.0 all
  Victor Mono patched with Nerd Fonts icons/glyphs (Font Awesome, Devicons, Octicons, Powerline, etc)

Eight of those nine lines are mine — every one tagged tur-packages with my name on Maintainer:. The odd one out is ttf-nerd-fonts-symbols/stable, which just happens to match the same search pattern: it's the pre-existing package from the main repo, maintained by @termux, not by me. Easy to mix up in a grep, so worth saying plainly here.

~ $ pkg show ttf-cascadia-code-nerd
Package: ttf-cascadia-code-nerd
Version: 3.5.0
Maintainer: Gouranga Das Samrat <gouranga.das.khulna@gmail.com>
Installed-Size: 11.4 MB
Homepage: https://www.nerdfonts.com/
Download-Size: 1550 kB
APT-Sources: https://tur.kcubeterm.com tur-packages/tur aarch64 Packages
Description: Cascadia Code patched with Nerd Fonts icons/glyphs (Font Awesome, Devicons, Octicons, Powerline, etc)

Same story across all eight — ttf-hack-nerd, ttf-inconsolata-nerd, ttf-jetbrains-mono-nerd, ttf-meslo-nerd, ttf-roboto-mono-nerd, ttf-sourcecodepro-nerd, and ttf-victor-mono-nerd all show up with my Maintainer: line and tur.kcubeterm.com as the source. One PR, one merge, eight packages live at once — the biggest single contribution I've shipped to Termux so far, and my first time landing anything on TUR specifically.

What actually stuck with me

Getting held to a stricter bar on the main repo didn't feel great mid-thread — three-thousand-package discipline running headfirst into nine fonts I was sure people wanted. But @robertkirkman and @TomJo2000 weren't wrong to hold it, and the rejection wasn't a dead end so much as a redirect to the tool built for exactly this situation. proton-pass-cli taught me how to get something into termux-packages. This one taught me that knowing where a package doesn't belong — and having TUR as somewhere to actually put it — is just as much a part of contributing as the packaging itself.

If you're on Termux and tired of manually curling .ttf files into ~/.termux/font.ttf:

pkg install tur-repo
pkg update
pkg install ttf-jetbrains-mono-nerd

(swap in hack, cascadia-code, meslo, sourcecodepro, inconsolata, roboto-mono, or victor-mono for whichever prompt you're patching.)

The full trail:

The Bug I Shipped, Then Had to Fix Myself: Disabling proton-pass-cli's Keyring on Android

Gouranga Das Samrat — Thu, 20 Aug 2026 02:47:44 +0000

A little over a week after proton-pass-cli merged into termux-packages, I was still riding the high of seeing my name next to Maintainer:. Then someone actually used the package the way a normal person would — fresh install, no tribal knowledge, straight to pass-cli login — and it broke.

That's the moment a package stops being "done" and starts being maintained.

The comment that started it

It came in on the original PR thread, from @EvanTechDev, the same person who'd cheered the package on back when it was just an issue:

"Hi there! Is this a bug?" — with a screenshot of pass-cli login blowing up.

The error underneath the screenshot was this:

Error: Error creating client features
Caused by:
    0: Failed to get encryption key for database
    1: Could not get local key from keyring
    2: Error accessing credential [...]: NoDefaultStore

My first reply was the fast one, the kind you type from your phone between other things:

export PROTON_PASS_KEY_PROVIDER=fs

That workaround was correct, and it unblocked Evan. But a one-line env var you have to know to paste into your shell config isn't a fix — it's a rumor that gets passed around in comment threads. I opened PR #31137 — fix(main/proton-pass-cli): disable keyring provider on Android to actually close the gap.

Why it was broken in the first place

pass-cli's default key storage, PROTON_PASS_KEY_PROVIDER=keyring, doesn't talk to D-Bus or Secret Service at all — it goes straight for the Linux kernel keyring, via the linux_keyutils crate. Android's kernel doesn't expose that the way a normal desktop Linux kernel does, so the backend fails to even initialize. NoDefaultStore isn't a config problem, it's a "this API doesn't exist here" problem.

And installing gnome-keyring doesn't rescue you, either — pass-cli only speaks to a Secret Service provider like GNOME Keyring when you explicitly set PROTON_PASS_LINUX_KEYRING=dbus. There's no automatic fallback. On Termux, the default provider was simply never going to work, for anyone, out of the box.

Two philosophies, one thread

I opened the PR with a shim: intercept the env var, force it to something sane before pass-cli ever saw the broken default. It was the smaller diff.

@robertkirkman, who'd reviewed nearly every line of the original proton-pass-cli PR too, wasn't on board:

"I prefer not to use this solution. Please patch the Rust code to completely erase PROTON_PASS_KEY_PROVIDER=keyring as an option from the codebase, forcing the default to something else that way."

Meanwhile @TomJo2000 had actually been the one who nudged me toward the shim approach in the first place, drawing a comparison to how Termux handles just's env var. So I had two respected reviewers, two different directions, and I did the only sane thing: I stopped coding and asked them to agree with each other first.

They did — and TomJo2000 talked himself out of his own suggestion in the process:

"If keyring is entirely broken then removing the codepath is probably the better solution. [...] the difference being here that the options form a set and the default selection doesn't work on Android. Whereas just provides its env var as an additional configuration mechanism with no default, and we set it to a sane value for our context."

That distinction stuck with me. A shim makes sense when you're adding a knob Termux needs. It doesn't make sense when the knob already exists and one of its settings is just categorically broken on the platform — at that point you patch the source, not the environment around it.

Patching Rust, then patching it properly

So I went into pass-cli/src/features/mod.rs and rewrote the provider match: an empty key provider ("") now maps to fs, and anyone who explicitly asks for keyring gets a clear error explaining that the kernel keyring is unsupported on Termux/Android, instead of a cryptic NoDefaultStore three layers deep in a stack trace.

First pass, I did it as inline sed edits in build.sh. Robertkirkman flagged that immediately — three separate instances of the same file path, code being replaced with no context preserved, and lines getting long inside build.sh itself. He also mentioned, not unkindly, that I'd never actually written a .patch file for a Termux package before and offered to walk me through it if I needed it. I moved everything into a proper patch file instead, per the contributing guide's instructions on creating patch files.

Even inside the patch file, the review kept sharpening things. Robertkirkman spotted that my new "" case and the existing "fs" case were doing the same thing and could just be combined:

"fs" | "" => { /* filesystem-based local key provider */ }

I made the change, pushed what I thought was the update — and then sat through a slightly awkward round where he was still looking at the old version because I'd merged locally but hadn't actually pushed yet. Nothing dramatic, just the very normal rhythm of an async review: confirm, fix, confirm again.

The last review comment wasn't even about my patch — it was about the older 0001-fix-protoc-path.patch from the original PR. Robertkirkman asked me to preserve a short comment above --- a/pass-domain/build.rs explaining that the patch exists to point the build at the protoc binary from termux_setup_protobuf, so the next person reading the patch file doesn't have to reconstruct why it exists from scratch.

Where it landed

By the end there were two clean patch files sitting in packages/proton-pass-cli/: the existing protoc path fix, now with context preserved at the top, and a new 0002-disable-android-keyring.patch that removes the broken default at the source instead of working around it downstream.

Robertkirkman closed the thread with the kind of message that makes the whole review cycle worth it:

"Thank you for fixing it!"

What actually changed

pass-cli login now works on a fresh Termux install, no env var required, no tribal knowledge to pass around in comment threads.
Anyone who does explicitly reach for PROTON_PASS_KEY_PROVIDER=keyring gets told exactly why it won't work on Android, instead of NoDefaultStore.
The fix lives in a real .patch file with context preserved, which was a first for me on this project — and something I now know how to do for the next bug.
The original shim idea didn't survive review, and that's fine. Getting talked out of the smaller diff by two people who understood the platform better than I did is exactly what review is for.

The part that keeps repeating

This is the second time in a month that shipping a Termux package taught me more than writing it did. First it was a broken symlink chain in sqlcipher that nobody had ever tripped over. This time it was a keyring backend that simply doesn't exist on Android, hiding behind an env var nobody knew to set. Neither bug showed up until a real person ran a real command and hit a wall.

Maintaining a package, it turns out, is mostly this: someone posts a screenshot, and you go find out why.

If you want the trail:

And if this is the first you're hearing of any of it:

pkg install proton-pass-cli

It'll actually log in now.

From a High School Termux User to a Package Maintainer: The Story Behind My First Merged PR on termux-packages

Gouranga Das Samrat — Tue, 18 Aug 2026 16:35:01 +0000

There's a specific kind of disbelief that hits when you run a command on your own phone and the output has your own name in it.

~ $ pkg show proton-pass-cli
Package: proton-pass-cli
Version: 2.3.2
Maintainer: Gouranga Das Samrat <gouranga.das.khulna@gmail.com>
Installed-Size: 26.5 MB
Depends: openssl, protobuf, sqlcipher, zlib
Homepage: https://protonpass.github.io/pass-cli/
Download-Size: 6346 kB
APT-Sources: https://packages-cf.termux.dev/apt/termux-main stable/main aarch64 Packages
Description: Proton Pass Command Line Interface (CLI)

I've been using Termux since high school — mostly as the terminal I didn't have on a laptop, running scripts on a phone screen, poking at packages other people maintained. I never expected to end up on the other side of Maintainer:. But that's exactly what happened this week, and I want to write down how it went, because the journey mattered more than the merge.

It started with a gap I kept running into

I use Proton Pass for my passwords, and its official CLI client, pass-cli, is exactly the kind of tool Termux users like — no browser, no Electron GUI, just a fast terminal client for managing vault items over SSH sessions and scripts. Termux already ships pass and gopass. pass-cli was conspicuously missing.

So I opened issue #30966, laid out the case for why it belonged in termux-packages, and went through the packaging policy checklist. A day after I filed it, @EvanTechDev dropped a comment saying they were looking forward to it too — which, small as it was, made the whole thing feel less like a solo request and more like something worth actually building.

Opening my first real PR

That turned into PR #30987 — addpkg(main/proton-pass-cli): 2.3.2. On paper it sounds simple: package a Rust CLI, point it at system libraries instead of vendoring everything, ship it. In practice it was my first real PR to termux-packages, and it showed almost immediately.

The build script needed protoc patched in via sed because the crate's usual vendored-binary downloader has no prebuilt for aarch64-unknown-linux-android. I wired up OPENSSL_NO_VENDOR, LIBSQLITE3_SYS_USE_PKG_CONFIG, and LIBZ_SYS_TEXT_LINK to keep everything on system libraries instead of source builds. Small, mechanical fixes — the kind you make while you're still learning where the edges of the build system are.

Then @robertkirkman, who reviewed nearly every line of this PR, pointed out something I hadn't clocked at all: proton-pass-cli was about to become the first true reverse dependency of sqlcipher in the entire termux-packages repo. Nothing had ever linked against it before. That single fact is what turned a routine "add a package" PR into a two-week deep dive.

The bug that only existed because I showed up

Right on cue, the final link step died:

ld.lld: error: unable to find library -lsqlcipher

libsqlcipher.so was sitting right there in find output. The linker didn't care. It turned out to be a broken symlink chain, left behind by a mv on a symlink that renamed the link's name but not what it pointed to — a bug that had been quietly sitting in sqlcipher's build.sh for who knows how long, invisible because nothing had ever needed to resolve that symlink before.

I actually wrote up the full investigation as its own post if you want the blow-by-blow: The Ghost in the Symlink: How I Hunted Down a Broken -lsqlcipher Bug in Termux (and Got Ninja'd on the Fix). Short version: I patched around it locally first, then opened PR #31013 to fix it properly in sqlcipher itself — and @robertkirkman had already opened PR #31010 fixing the exact same root cause about two hours earlier. I closed mine as a duplicate, no hard feelings, and rebased proton-pass-cli on top of his fix instead.

I figured that was the hard part done. It was not.

The edge case nobody had hit before

sqlcipher and proton-pass-cli being fixed separately still left an open question: what happens when sqlcipher and its reverse dependency are modified in the same PR, so both build fresh in the same CI run? @robertkirkman asked me to actually test that scenario, since it changes build ordering in ways that don't show up when sqlcipher is just pulled pre-built from the apt repo.

That request turned into its own small saga — a merge-commit accidentally slipping into my branch that CI correctly rejected, a stale local copy of sqlcipher/build.sh that silently reintroduced the very bug we'd just fixed, and finally a real rebase that let the ld.lld: unable to find library -lsqlcipher error resurface on purpose, in the exact edge case it was supposed to test. Once it did, TERMUX_PKG_EXTRA_MAKE_ARGS overriding libsqlite3.DLL.basename turned out to be the clean fix, and CI went green on aarch64, arm, i686, and x86_64 at once, with sqlcipher and proton-pass-cli both built fresh in the same run.

Then we found a second, related gap: the headers and .pc file only get their sqlcipher names inside the final packaged .deb, not in the live prefix during a same-run build — meaning a future C/C++ reverse dependency of sqlcipher could hit the same class of bug at #include <sqlcipher.h> or pkg-config sqlcipher time instead of at the linker. I confirmed it with a fresh build and a handful of ls/pkg-config checks against the live $TERMUX_PREFIX. Since it didn't block a Rust package like mine, we split it off as its own follow-up rather than holding up #30987 for it, and @robertkirkman landed a proper fix for it with a tcl/main.mk patch that removes the fragile rename step entirely. He was even generous enough to file an upstream issue on sqlcipher itself about why this pattern exists across so many distros in the first place.

Along the way @TomJo2000 reviewed too — alphabetizing dependencies, fixing the Maintainer: field format, spacing conventions before functions. Small things, but the kind of small things that add up to a package that looks like it belongs in the repo instead of one that was just dropped in.

Squash, rebase, merge

By the time everything was resolved — sqlcipher's .so symlinks fixed upstream in the package, the header/pkgconfig gap fixed in a follow-up, six commits squashed into one clean commit at @robertkirkman's request — there was one last exchange that made me smile: he asked whether there should also be a plain proton-pass package to match the AUR naming, and once I explained that one's the full Electron GUI and this one is CLI-only, he agreed the Electron build wasn't worth packaging for Termux.

Then: "Thank you for making this!"

PR #30987 merged. proton-pass-cli 2.3.2 is now a real Termux package. Anyone can run pkg install proton-pass-cli and get it — no vendored binaries, no Electron footprint, just a clean CLI backed by the system's openssl, protobuf, sqlcipher, and zlib.

What actually changed

The version string says 2.3.2, but that's not really what shipped. What shipped was:

A real, upstream fix to a sqlcipher symlink bug that had existed silently for as long as nobody linked against it — now fixed for every reverse dependency that comes after mine, not just this one.
A same-PR/same-run build ordering edge case tested and fixed, so the next person adding a sqlcipher reverse dependency doesn't have to rediscover any of this.
A second, related header/pkgconfig gap found and fixed before a C/C++ package ever had the chance to hit it blind.
An upstream issue opened against sqlcipher itself, so this isn't just patched around in Termux forever.
One more terminal-native way to manage Proton Pass vaults on Android, for anyone who'd rather not touch a browser extension.

The part that actually stuck with me

I've been a Termux user since I was in high school, running other people's packages without a second thought about how they got there. What I didn't expect from filing one feature request is that it would turn into weeks of testing build orderings, reading symlink resolution behavior, and getting pulled into a genuinely upstream sqlcipher discussion — all because I happened to be the first person to ask for a package that needed to link against sqlcipher.

None of that was in the plan. I just wanted a password manager CLI on my phone. But that's apparently how you become a maintainer: not by planning to, but by being the first person to actually need something, and staying in the thread long enough to fix what breaks.

If you want the full trail, it's all public:

And if you're on Termux and want a terminal-native way into your Proton Pass vault:

pkg install proton-pass-cli

One Line, One NULL, One Noisy Error: Fixing usql's Tab Completion Crash

Gouranga Das Samrat — Mon, 17 Aug 2026 04:00:00 +0000

Not every open-source contribution needs a saga. Sometimes the whole story is: hit an annoying error, find the one missing COALESCE, ship a one-line diff, done. This is one of those — a small bug in usql, the universal command-line SQL client, that turned into a satisfying little fix with a slightly bumpy landing.

The bug: tab completion that complains before it works

While using usql against PostgreSQL, hitting Tab for autocompletion threw this at me every single time:

Error getting selectables sql: Scan error on column index 6, name "routine_definition": converting NULL to string is unsupported

The frustrating part: completion still worked afterward. The error was purely noise — but noise you'd see on every single tab-press, which gets old fast. I filed it as issue #554.

Root cause: not every function has a definition

usql builds its completion suggestions by querying information_schema.routines, and one of the columns it scans is routine_definition. That column holds the SQL body of a function or procedure — but only for functions written in SQL. For external or C-language functions, PostgreSQL simply has nothing to put there, so the column comes back NULL.

Go's database/sql scanning is strict about this: you can't scan a NULL straight into a string. You need a sql.NullString, a pointer type, or — the simplest fix when you're just displaying the value — coerce it at the SQL level.

Digging into drivers/metadata/informationschema/metadata.go, the surrounding query already knew this. Neighboring nullable columns were wrapped defensively:

"COALESCE(routine_type, '')",
"COALESCE(data_type, '')",

routine_definition was just the one column that had been missed.

The fix

One line, same pattern as its neighbors:

- "routine_definition",
+ "COALESCE(routine_definition, '')",

That's it. COALESCE swaps the NULL for an empty string before it ever reaches the scanner, consistent with how the query already treated routine_type and data_type. No new imports, no new types, no behavior change for the common case — just one more nullable column brought in line with its siblings.

I opened PR #555 with the fix, referencing #554.

Merged — sort of

Maintainer @kenshaw reviewed it quickly and closed out the issue, and a few days later the PR itself was closed with a note: "Added to main. Thanks!"

Except the PR wasn't merged in the GitHub sense — the change had been applied manually rather than through a merge commit. GitHub was straightforward about it too, flagging the PR as "Closed with unmerged commits" since my branch still had commits that were never actually merged into main.

I asked about it, since authorship tracking matters for contribution history:

"I noticed the changes were added manually instead of merging the PR. Would it be possible to preserve authorship in such cases (e.g., via merge or co-author)?"

@kenshaw's answer cleared it up immediately — this wasn't a snub, it was branch juggling:

"I used cherry-pick here as I needed to add it to the release-21 branch as well as main. I should have used rebase onto main, and then cherry-picked it to the release branch."

Which makes complete sense once you think about it: a one-line fix like this isn't just useful on main, it's useful on the active release branch too, and cherry-picking is the standard way to land the same commit in two places without a merge tangling up both histories. The trade-off is that GitHub's PR UI doesn't recognize a cherry-picked commit as "merged," even though the commit — author, committer, and all — is sitting right there in the Git history on both branches.

Takeaways

A few small things worth remembering from a fix this size:

COALESCE is your friend for optional metadata columns. Anywhere you're joining against information_schema or similar catalogs, assume any column can be NULL unless you know otherwise, and handle it at the query level if you're just going to stringify it anyway.
Consistency is a debugging shortcut. The fix here wasn't found through deep investigation — it was found by noticing the query already had a pattern for handling this exact problem on two other columns, and one column had been left out.
"Closed, not merged" isn't always a red flag. If a maintainer needs a fix on multiple branches (like a release branch and main), cherry-picking is often the cleaner tool, even though it means GitHub won't show your PR as formally merged. Your authorship still travels with the commit either way.

Full trail if you want to see it:

The Ghost in the Symlink: How I Hunted Down a Broken `-lsqlcipher` Bug in Termux (and Got Ninja'd on the Fix)

Gouranga Das Samrat — Sun, 16 Aug 2026 12:27:43 +0000

Some bugs announce themselves loudly. Segfaults, stack traces, five-hundred-line panics. This one didn't. This one just sat there quietly for who knows how long, waiting for the first person unlucky (or lucky?) enough to actually need it.

That person turned out to be me.

The setup: packaging `proton-pass-cli` for Termux

I've been working on getting the Proton Pass CLI packaged for termux-packages, tracked in PR #30987. It's a Rust project, cross-compiled for Android, pulling in system libraries instead of vendored ones wherever possible — openssl, zlib, protobuf, and sqlcipher.

Everything was going fine until the final link step, when the build died with this:

ld.lld: error: unable to find library -lsqlcipher

Which is a delightfully unhelpful error when you're staring at find output that clearly shows libsqlcipher.so sitting right there in $PREFIX/lib.

Chasing a library that "exists" but doesn't

My first instinct was the usual suspects: wrong PKG_CONFIG_PATH, missing PKG_CONFIG_ALLOW_CROSS for cross-compilation, wrong SQLCIPHER_LIB_DIR. I set all of those. Still broken.

So I went straight to the filesystem. ls -la on the lib directory told a different story than find had:

libsqlcipher.so   -> libsqlite3.so.0          (broken)
libsqlcipher.so.0 -> libsqlite3.so.<version>  (broken)
libsqlcipher.so.<version>                     (the only real file)

There it was. libsqlcipher.so existed as a name, but it was a symlink pointing at libsqlite3.so.0 — a file that no longer existed, because it had also been renamed away. The linker doesn't care that a file named libsqlcipher.so is present; it cares whether the symlink actually resolves. find and ls will happily list a broken symlink by its entry name and let you assume everything's fine. The linker knows better.

Root cause: `mv` on a symlink doesn't do what you think

The actual bug lived one layer upstream, in the sqlcipher package's own termux_step_post_massage(), where Termux renames the sqlite3 build artifacts to sqlcipher names to avoid collisions:

mv lib/lib{sqlite3,sqlcipher}.so
mv lib/lib{sqlite3,sqlcipher}.so.0
mv lib/lib{sqlite3,sqlcipher}.so."$sql_version"

Here's the trap: libsqlite3.so and libsqlite3.so.0 aren't regular files, they're symlinks. mv on a symlink only renames the link itself — it does not rewrite the target path stored inside it. So after this rename:

The link now named libsqlcipher.so still internally points at libsqlite3.so.0
The link now named libsqlcipher.so.0 still internally points at libsqlite3.so.<version>
Both of those target names no longer exist, because the real versioned file got renamed to libsqlcipher.so.<version> in the same step

A broken symlink chain, hiding in plain sight, for what appears to have been the entire life of the sqlcipher package — because nothing had ever linked against it before. proton-pass-cli was about to become the first true reverse dependency of sqlcipher in termux-packages, and reverse dependencies are exactly the kind of thing that surfaces bugs nobody could have found by testing the package in isolation.

The temporary fix

I didn't own the sqlcipher package, and I needed my own PR unblocked, so I patched around it locally in proton-pass-cli's own termux_step_pre_configure() — detect the real installed .so.<version> file at build time and recreate the symlinks pointing at it correctly:

_sqlcipher_real_so="$(find "$TERMUX_PREFIX/lib" -maxdepth 1 -type f -name 'libsqlcipher.so.*' -print -quit)"
if [ -n "$_sqlcipher_real_so" ]; then
    _sqlcipher_real_so="$(basename "$_sqlcipher_real_so")"
    ln -sf "$_sqlcipher_real_so" "$TERMUX_PREFIX/lib/libsqlcipher.so.0"
    ln -sf "$_sqlcipher_real_so" "$TERMUX_PREFIX/lib/libsqlcipher.so"
fi

It worked. The build went green on all four architectures. Problem solved — for my package, at least.

"Fix it properly, in the right place"

When @robertkirkman reviewed PR #30987, he pointed out the obvious: papering over a broken symlink in every downstream consumer of sqlcipher doesn't scale. The correct fix belongs in sqlcipher's own build.sh, not duplicated in mine and every future reverse dependency.

Fair. So I opened PR #31013 against packages/sqlcipher/build.sh, fixing it at the source:

rm -f lib/libsqlite3.so lib/libsqlite3.so.0
mv lib/lib{sqlite3,sqlcipher}.so."$sql_version"
ln -sf libsqlcipher.so."$sql_version" lib/libsqlcipher.so.0
ln -sf libsqlcipher.so.0 lib/libsqlcipher.so

Instead of trying to mv symlinks and hoping the target updates itself, remove the stale links entirely and recreate them fresh, pointing at the correctly renamed versioned file — with the version pulled from $sql_version so it stays correct across future bumps.

Beaten to the finish line by two hours

Here's the part that made me laugh instead of sigh: by the time I pushed PR #31013, @robertkirkman had already opened PR #31010 fixing the exact same root cause — roughly two hours earlier. Same diagnosis, functionally the same fix, just arrived at independently and slightly faster.

No hard feelings there. It happens constantly in open source — two people staring at the same broken symlink chain from different angles, both reaching for ln -sf. I closed #31013 as a duplicate and updated #30987 to track #31010 instead. Once that lands, my temporary workaround in proton-pass-cli comes back out, and the fix lives exactly where it should: upstream, in sqlcipher itself, benefiting every reverse dependency that comes after — not just mine.

Takeaways

A few things stuck with me from this one:

mv on a symlink is not the same as mv on a file. It renames the link, not the target it points to. If you're renaming a pair of symlink + real file in the same operation, do the real file first and rebuild the links from scratch.
find and ls lie by omission. They'll show you a symlink's name happily, broken or not. If you actually need to know whether something resolves, check that explicitly.
First reverse dependencies are bug detectors. A library that's never been linked against can hide structural issues indefinitely. The moment something actually depends on it, all bets are off.
Fix bugs where they live, not where you found them. My instinct was to patch around the symptom in my own package. The maintainer's instinct — fix it in sqlcipher itself — was the right one, even though it meant more work and, as it turned out, a friendly race I didn't win.

If you want to follow the whole trail, it's all public:

Bloom Filters

Gouranga Das Samrat — Sun, 16 Aug 2026 02:00:00 +0000

One-liner: A probabilistic data structure that tells you if an element is definitely not in a set, or possibly in a set — using very little memory.

📌 The Problem

You have 1 billion URLs in a database. Before adding a new URL, you want to check if it already exists.

Naive approach: Query the database every time.

Cost: 1 DB query per URL check → slow, expensive

Bloom Filter approach: Check the bloom filter first (microseconds, no DB hit).

If filter says NO → URL definitely not in DB → safe to insert
If filter says YES → URL might be in DB → query DB to confirm

💡 How Bloom Filters Work

Structure

An array of m bits, all initialized to 0.

Bit array: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0]  (m=10 bits)
            0  1  2  3  4  5  6  7  8  9

Insertion (k hash functions)

To insert element x:

Hash x with k different hash functions
Each hash function returns a position in the bit array
Set those positions to 1

Insert "google.com":
  hash1("google.com") = 2 → bit[2] = 1
  hash2("google.com") = 5 → bit[5] = 1
  hash3("google.com") = 8 → bit[8] = 1

Bit array: [0, 0, 1, 0, 0, 1, 0, 0, 1, 0]

Lookup

To check if y is in the set:

Hash y with the same k functions
Check if ALL those positions are 1

Check "google.com":
  hash1 → bit[2] = 1 ✅
  hash2 → bit[5] = 1 ✅
  hash3 → bit[8] = 1 ✅
  → POSSIBLY in set (correct! it was inserted)

Check "bing.com":
  hash1 → bit[1] = 0 ❌
  → DEFINITELY NOT in set (100% accurate)

⚠️ False Positives (Not False Negatives)

False Positive Example

Insert "amazon.com":
  hash1 = 2, hash2 = 7, hash3 = 3

Bit array (after inserting google.com + amazon.com):
[0, 0, 1, 1, 0, 1, 0, 1, 1, 0]

Check "yahoo.com":
  hash1("yahoo.com") = 2 → bit[2] = 1 ✅
  hash2("yahoo.com") = 7 → bit[7] = 1 ✅
  hash3("yahoo.com") = 3 → bit[3] = 1 ✅
  → "POSSIBLY in set" ← FALSE POSITIVE! (yahoo.com was never inserted)

Bits were set by OTHER elements, creating a false positive.

Key Guarantees

Result	Guarantee
DEFINITELY NOT in set	100% accurate (no false negatives)
POSSIBLY in set	Might be wrong (false positives possible)
Cannot delete	Once a bit is set, you can't safely unset it

📊 Tuning Bloom Filters

Two parameters control accuracy:

m = size of bit array (more bits → fewer false positives)
k = number of hash functions (optimal k depends on m and n)
n = number of expected elements

False positive rate formula:

p ≈ (1 - e^(-kn/m))^k

Practical sizing:

1% false positive rate → ~10 bits per element
0.1% false positive rate → ~15 bits per element

For 1 billion URLs, 1% FP rate:
→ 10 × 1B bits = 10 billion bits = 1.25 GB
vs
→ Storing 1B URLs as strings = ~50-100 GB
→ 40-80× memory savings!

🌍 Real-World Use Cases

System	Use Case
Google Chrome	Malicious URL check (local bloom filter)
Apache Cassandra	Skip SSTables that don't contain a key
Bitcoin	SPV wallets filter transactions
Akamai CDN	Avoid caching one-hit-wonder URLs
Medium	"Have you seen this article?" check
Email spam filters	Fast first-pass spam detection
HBase/BigTable	Reduce disk reads for non-existent rows

Example: Web Crawler (Avoid Revisiting URLs)

from pybloom_live import BloomFilter

bf = BloomFilter(capacity=1_000_000_000, error_rate=0.01)

def should_crawl(url):
    if url in bf:
        return False  # probably already crawled (or false positive)
    bf.add(url)
    return True  # definitely not crawled yet

Example: Username Availability

User types username "rahul123"
→ Check bloom filter (microseconds)
→ Filter says NO → username definitely available ✅ (no DB query needed)
→ Filter says YES → query DB to confirm (might be false positive)

🆚 Bloom Filter vs Hash Set

Feature	Bloom Filter	Hash Set
Memory	Very small (bits)	Large (full values)
Lookup	O(k) very fast	O(1) fast
False positives	Possible	Never
False negatives	Never	Never
Deletion	Not supported	Supported
Count elements	No	Yes

🔄 Variants

Variant	Feature
Counting Bloom Filter	Supports deletions (use counters instead of bits)
Scalable Bloom Filter	Grows dynamically as elements are added
Cuckoo Filter	Supports deletion, similar performance

🎨 Diagram

The diagram shows:

Bit array with positions labeled
Three hash functions pointing to different positions
Insertion of "google.com" setting 3 bits
Lookup showing definite miss vs possible hit
False positive scenario with two elements colliding

🔑 Key Takeaways

Bloom filters use tiny memory to check set membership
No false negatives — if it says NO, it's definitely NO
False positives possible — if it says YES, verify with DB
Perfect for pre-filtering expensive DB/disk lookups
Tune with bits-per-element to control false positive rate

CAP Theorem

Gouranga Das Samrat — Sat, 15 Aug 2026 02:00:00 +0000

One-liner: In a distributed system, you can only guarantee two of three properties — Consistency, Availability, and Partition Tolerance — at the same time.

📌 The Three Properties

C — Consistency

Every read returns the most recent write (or an error). All nodes see the same data at the same time.

Node A: Write x=5
Node B: Read x → must return 5 (not an old value)

A — Availability

Every request receives a non-error response (but the data might be stale).

Node B is out of sync but still responds:
Read x → returns 3 (old value, but NOT an error)

P — Partition Tolerance

The system continues to operate even when network partitions cause nodes to be unable to communicate.

[Node A] ~~~ NETWORK PARTITION ~~~ [Node B]
System still works (doesn't go down)

🔺 The Triangle

         Consistency
             /\
            /  \
           /    \
          / CP   \
         /        \
        /____  ____\
   CA  /      \/     \ AP
      /    PICK 2    \
     /________________\
  Availability      Partition
                    Tolerance

In practice: Partitions happen. You must choose P.
So the real choice is: CP or AP.

🔀 CP Systems — Consistency + Partition Tolerance

When a network partition occurs:

System refuses to respond rather than return stale data
Prioritizes correctness over availability

Node A (Primary) ~~~ partition ~~~ Node B (Replica)

Request to Node B → "I can't reach primary, refusing to serve" → Error/timeout

Examples: HBase, Zookeeper, etcd, MongoDB (by default config), Google Spanner

Use when:

Banking — wrong balance is worse than no balance
Inventory — showing wrong stock can cause overselling
Leader election — must have consistent view of who's the leader

🔀 AP Systems — Availability + Partition Tolerance

When a network partition occurs:

System continues to serve requests (possibly stale data)
Prioritizes availability over correctness

Node A (Primary) ~~~ partition ~~~ Node B (Replica)

Request to Node B → "I'll serve my stale data" → Responds (maybe stale)

Examples: Cassandra, DynamoDB, CouchDB, DNS, Riak

Use when:

Social media likes/views — a few seconds lag is fine
Product catalog — slightly stale price is acceptable
DNS — serving cached records during failures is fine

📊 Real Database Classification

Database	Type	Notes
PostgreSQL	CA (single node) / CP (distributed)	Single node: no partition
MySQL	CA (single node) / CP (with replication)
MongoDB	CP	Can configure for AP with lower write concern
Cassandra	AP	Tunable consistency (ONE to ALL)
DynamoDB	AP (default) / CP (with strong reads)
Redis	CP (Cluster mode)
Zookeeper	CP	Used for coordination
HBase	CP	Strong consistency
CouchDB	AP	Conflict resolution

🔧 Tunable Consistency (Cassandra)

Real systems aren't binary. Cassandra lets you tune per-query:

CONSISTENCY ONE   → fastest, least consistent (1 node responds)
CONSISTENCY QUORUM → balanced (majority of nodes respond)
CONSISTENCY ALL   → slowest, most consistent (all nodes respond)

Quorum formula:

Nodes = 5
Quorum = floor(5/2) + 1 = 3

Write to 3 + Read from 3 → at least 1 node overlaps → strong consistency

🔄 PACELC — Extension of CAP

CAP only talks about partition scenarios. PACELC extends it:

If Partition (P): choose between Availability (A) or Consistency (C)
Else (E):         choose between Latency (L) or Consistency (C)

Even without partitions, there's a trade-off:

Sync replication → strong consistency but higher latency
Async replication → lower latency but weaker consistency

System	If P	Else
DynamoDB	AP	EL
Cassandra	AP	EL
MongoDB	CP	EC
Spanner	CP	EC

🏗️ Eventual Consistency in Practice

AP systems promise eventual consistency — given no new writes, all nodes will eventually converge.

t=0: Write x=5 to Node A
t=1: Read from Node B → returns 3 (stale)
t=2: Replication happens
t=3: Read from Node B → returns 5 ✅ (converged)

How long does "eventually" take?

Same datacenter: milliseconds
Cross-region: 100ms to seconds
During partition: until partition heals

🔑 Key Takeaways

In practice: Partition Tolerance is non-negotiable → choose CP or AP
CP = strong consistency, sacrifice availability during partition
AP = always available, sacrifice consistency (eventual)
Most modern databases offer tunable consistency — you choose per operation
Match the trade-off to your business need: financial data → CP; social data → AP