Gouranga Das Samrat

Posted on Aug 18 Edited on Aug 20

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

#opensource #rust #termux #android

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

DEV Community