This package has not seen a commit in about five years. It was
archived on September 20, 2021:

https://github.com/howeyc/gopass

Its README file says:

"terminal" is a link to https://golang.org/x/crypto/ssh/terminal.

Antoine Beaupre <anarcat@debian.org> writes:

I suppose we need to go through each of the reverse dependencies below,
file Debian BTS bugs and forwarded them upstream and/or then update to a
corrected version, and once that has been completed, reassign this bug
as a ftp-master RoM removal request?

jas@frallan:~$ ssh mirror.ftp-master.debian.org dak rm -Rn -b    golang-github-howeyc-gopass-dev
Will remove the following packages from unstable:

golang-github-howeyc-gopass-dev | 0.0~git20190910.7cb4b85+dfsg.1-1 | all

Maintainer: Debian Go Packaging Team <pkg-go-maintainers@lists.alioth.debian.org>
------------------- Reason -------------------

----------------------------------------------

Checking reverse dependencies...
# Broken Depends:
golang-gopkg-godo.v2: golang-gopkg-godo.v2-dev
relic: golang-github-sassoftware-relic-dev

# Broken Build-Depends:
golang-gopkg-godo.v2: golang-github-howeyc-gopass-dev
mender-cli: golang-github-howeyc-gopass-dev
mirrorbits: golang-github-howeyc-gopass-dev
pat: golang-github-howeyc-gopass-dev
percona-toolkit: golang-github-howeyc-gopass-dev
relic: golang-github-howeyc-gopass-dev

Dependency problem found.

jas@frallan:~$

/Simon

On 2026-03-13 07:55:28, Simon Josefsson wrote:

[...]

well, i filed this as a RC bug so, presumably, this will ring all sorts
of alarm bells in downstream deps.

i was kind of assuming deps have fixed this upstream, but then, as it
turns out, that's naive. both of those first level deps still depend on
gopass and worse, one of those (godo, which has its own ton of rdeps)
has not seen a release in *over a decade* and should probably be
considered dead itself.

relic, on the other hand, still seems active, so there's hope.

i wonder how deep this rabbit hole goes...

a.

fre 2026-03-13 klockan 10:16 -0400 skrev Antoine Beaupré:

Hmm, I'm not sure anything will happen in the PTS until the bug
triggers autoremoval? Having bug reports for each of the dependent
packages would help to separate discussion.  I think we could just
clone this bug to each of the other packages, right?

With Go packages, you rarely understand before you start the work.

So should we clone this bug to the following source packages?  I think
the clones should be severity:wishlist, and then this RC bug will block
on those bugs.

Another alternative is to use 'affects' for those packages.  I never
understood which semantics is better.

jas@frallan:~$ dd-list golang-gopkg-godo.v2 relic mender-cli mirrorbits
pat percona-toolkit
Andreas Henriksson <andreas@fatal.se>
   mender-cli (U)

Arnaud Rebillout <arnaudr@kali.org>
   mirrorbits (U)

Dario Minnucci <midget@debian.org>
   percona-toolkit

Debian Go Packaging Team <team+pkg-go@tracker.debian.org>
   golang-gopkg-godo.v2
   mender-cli
   relic

Debian Hamradio Maintainers <debian-hams@lists.debian.org>
   pat

Federico Grau <donfede@casagrau.org>
   pat (U)

Francisco Vilmar Cardoso Ruviaro <vilmar@debian.org>
   golang-gopkg-godo.v2 (U)

Mirrorbits Maintainers <mirrorbits@packages.debian.org>
   mirrorbits

Simon Josefsson <simon@josefsson.org>
   relic (U)

Taowa <taowa@debian.org>
   pat (U)

jas@frallan:~$

/Simon

Well, if package A depends on package B and package B has a RC bug that
will trigger autoremoval, it will trigger autoremoval for package A, and
that will show up in the PTS.

Sure, or affects, but i would keep that for first-level deps, not the
whole forest.

a.

I have uploaded a new version of 'relic' with a patch from Reinhard
Tartler replacing gopass with x/term:

https://github.com/sassoftware/relic/issues/59#issuecomment-4141591226

I believe that patch could be an inspiration to fix all the remaining
packages.  They need a similar fix.  Together with upstream bug report.
Complete dd-list output for affected packages below.

Help will be needed to do finish this work.  I suppose the simplest way
to properly track this is to open bugs on all of these packages...
would that be a mass-bug-filing that needs wider coordination?  Seems
like an un-controversial MBF though.

/Simon

# dd-list apptainer bettercap bettercap-caplets bettercap-ui cockpit-podman cosign debcraft distrobox distrobuilder eztrace eztrace-contrib gitsign gittuf gloo-rocm golang-github-bettercap-gatt golang-github-containers-buildah golang-github-containers-common golang-github-containers-image golang-github-containers-toolbox golang-github-crc-org-crc golang-github-mgutz-logxi golang-gopkg-godo.v2 hipcub kiwi kiwi-boxed-plugin mender-cli mirrorbits oci-seccomp-bpf-hook pat percona-toolkit pkg-rocm-tools podman rekor relic rocprim rocthrust rust-repro-env sigstore-go skopeo starpu starpu-contrib

Andreas Henriksson <andreas@fatal.se>
   mender-cli (U)

Andrej Shadura <andrewsh@debian.org>
   golang-github-containers-toolbox (U)

Arnaud Rebillout <arnaudr@debian.org>
   mirrorbits (U)

Christian Bayle <bayle@debian.org>
   rocthrust (U)

Christian Kastner <ckk@debian.org>
   hipcub (U)
   pkg-rocm-tools (U)
   rocprim (U)
   rocthrust (U)

Cordell Bloor <cgmb@debian.org>
   hipcub (U)
   rocprim (U)
   rocthrust (U)

Debian Deep Learning Team <debian-ai@lists.debian.org>
   gloo-rocm

Debian Go Packaging Team <pkg-go-maintainers@lists.alioth.debian.org>
   podman

Debian Go Packaging Team <team+pkg-go@tracker.debian.org>
   apptainer
   cosign
   distrobuilder
   gitsign
   gittuf
   golang-github-bettercap-gatt
   golang-github-containers-buildah
   golang-github-containers-common
   golang-github-containers-image
   golang-github-containers-toolbox
   golang-github-crc-org-crc
   golang-github-mgutz-logxi
   golang-gopkg-godo.v2
   mender-cli
   oci-seccomp-bpf-hook
   rekor
   relic
   sigstore-go
   skopeo

Debian Hamradio Maintainers <debian-hams@lists.debian.org>
   pat

Debian ROCm Team <debian-ai@lists.debian.org>
   hipcub
   pkg-rocm-tools
   rocprim
   rocthrust

Debian Rust Maintainers <pkg-rust-maintainers@alioth-lists.debian.net>
   rust-repro-env

Debian Security Tools <team+pkg-security@tracker.debian.org>
   bettercap
   bettercap-caplets
   bettercap-ui

Dmitry Smirnov <onlyjob@debian.org>
   golang-github-containers-buildah (U)
   golang-github-containers-image (U)
   podman (U)

Domenico Andreoli <cavok@debian.org>
   oci-seccomp-bpf-hook (U)

Faidon Liambotis <paravoid@debian.org>
   podman (U)

Federico Grau <donfede@casagrau.org>
   pat (U)

Francisco Vilmar Cardoso Ruviaro <vilmar@debian.org>
   bettercap (U)
   bettercap-caplets (U)
   bettercap-ui (U)
   golang-github-bettercap-gatt (U)
   golang-github-mgutz-logxi (U)
   golang-gopkg-godo.v2 (U)

Hayley Hughes <hayley@foxes.systems>
   golang-github-containers-toolbox (U)

Isaac True <isaac@is.having.coffee>
   kiwi-boxed-plugin

John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
   kiwi

Kari Pahula <kaol@debian.org>
   hipcub (U)
   rocprim (U)
   rocthrust (U)

kpcyrd <git@rxv.cc>
   rust-repro-env (U)

Lena Voytek <lena@voytek.dev>
   percona-toolkit

Marcus Schäfer <marcus.schaefer@gmail.com>
   kiwi (U)

Martin Pitt <mpitt@debian.org>
   cockpit-podman

Mathias Gibbens <gibmat@debian.org>
   distrobuilder (U)

Michel Lind <michel@michel-slm.name>
   distrobox

Mirrorbits Maintainers <mirrorbits@packages.debian.org>
   mirrorbits

Mo Zhou <lumin@debian.org>
   gloo-rocm (U)

Otto Kekäläinen <otto@debian.org>
   debcraft

Reinhard Tartler <siretart@tauware.de>
   cockpit-podman (U)
   golang-github-containers-buildah (U)
   golang-github-containers-common (U)
   golang-github-containers-image (U)
   golang-github-crc-org-crc (U)
   podman (U)
   rekor (U)
   skopeo (U)

Roland Mas <lolando@debian.org>
   apptainer (U)

Samuel Thibault <sthibault@debian.org>
   eztrace
   eztrace-contrib
   starpu
   starpu-contrib

Simon Josefsson <simon@josefsson.org>
   cosign (U)
   gitsign (U)
   gittuf (U)
   rekor (U)
   relic (U)
   sigstore-go (U)

Taowa <taowa@debian.org>
   pat (U)

Hi,

I was able to update Percona Toolkit upstream to use x/term instead - https://github.com/percona/percona-toolkit/pull/1091
I just uploaded a new version to unstable with the fix.

Thanks!

I've uploaded a patched golang-gopkg-godo.v2 now.

The dd-list is in my last post is incorrect: that was the complete list
of transitive dependencies.  The right list is the direct dependencies.
I believe the correct list of reverse dependencies that needs to be
fixed is golang-gopkg-godo.v2, relic, mender-cli, mirrorbits, pat,
percona-toolkit -- see:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1130525#20

Now only mender-cli, mirrorbits, pat remains, so no MBF necessary, and
the testing autoremoval in the PTS seems to work fine.  I'll look at
mender-cli next, but will leave pat and mirrorbits hoping those teams
will attend this (or that those packages simply be dropped too).

Andreas Henriksson <andreas@fatal.se>
   mender-cli (U)

Arnaud Rebillout <arnaudr@kali.org>
   mirrorbits (U)

Debian Go Packaging Team <team+pkg-go@tracker.debian.org>
   mender-cli

Debian Hamradio Maintainers <debian-hams@lists.debian.org>
   pat

Federico Grau <donfede@casagrau.org>
   pat (U)

Mirrorbits Maintainers <mirrorbits@packages.debian.org>
   mirrorbits

Taowa <taowa@debian.org>
   pat (U)

/Simon

Simon Josefsson <simon@josefsson.org> writes:

The `pat' package, which depends on golang-github-howeyc-gopass, has been
making progress upstream addressing this bug...

pat issue 517 ( https://github.com/la5nta/pat/issues/517 ) was created, and
the upstream author (Martin H Pedersen) has a fix, no longer using
golang-github-howeyc-gopass.

However, a new pat release with the fix is still in process, and we're kindly
seeking a little more time before #1130525 takes effect.  Hoping that bumping
this bug buys us at least a couple more weeks.


Respectfully,
donfede

Fede Grau

Couldn't you add

https://github.com/la5nta/pat/commit/43788c1b73e5616a6f6ec0dd37eea4b89d77da85

to debian/patches?  That could also give confidence to the patch, which
may help upstream.  If a new upstream release is expected soon, waiting
seems fine, but if it takes more than 2-3 weeks I suggest trying the
patch.

/Simon

Federico Grau <donfede@casagrau.org> writes:

Hi Federico,

I would suggest to include the upstream patch and make a new upload as
it may helps you and others to test and see if it works or any new
issue that you may report to upstream.

You can also send email to go mailing to request review MR and sponsor
upload as usual.

Best regards,