Dear Maintainer,

The original obfs4proxy at https://git.torproject.org/pluggable-transports/obfs4.git
and https://gitlab.com/yawning/obfs4 has ceased development, but The Tor
Project has forked it, and renamed it to lyrebird at
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird
.

Could we adopt lyrebird, and make it "Replaces" and "Provides" obfs4proxy in
the APT repository?

Hello,

I'm one of the maintainers of lyrebird at the Tor Project. I'm happy to help
with the process of getting lyrebird in debian, debian is used by many bridge
operators that will need an easy way to get lyrebird installed.

I'm happy to help with this process.

Dear Maintainer,

Now the lyrebird has the client functionality of webtunnel and snowflake integrated, so adopting lyrebird can at least bring native webtunnel client support to Debian repository.

Debian contains old version 0.0.14 of obfs4proxy, new upstream is at 0.8.0
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird
(with changed name any many improvements)

Is help needed? I'm not DD/DM, but I have worked with packaging few packages
into Debian with sponsors, so I am willing to help too.

Ahoy there!

Matija Nalis wrote:
 • rename the source package and the principal binary package to Lyrebird but retain the contents generally (preserving the old changelog should be possible)
 • have that source package build an transitional package named 'obfs4proxy', with a version matching the source package version, and which Depends on Lyrebird
 • have Lyrebird set Replaces appropriately, but after this I'm lost:
	◦ If the binaries are renamed too and the packages are, in principle, co-installable, I'm not sure what should happen after that, especially if Tor needs to change its invocation in tandem anyway. If we ship a compatibility symbolic link so Lyrebird can be invoked as 'obfs4proxy' then Breaks + Replaces should be good (to help remove the old obfs4proxy binary package). Since they work alike, though, we probably would want a 'Provides: obfs4proxy' then too?

I've not actually used this package before but I guess it comes down to whether an automatic transition should, in principle, be possible.
(These rambling notes are for the benefit of Debian folks who want to know what's going on with respect to the details. Don't concern yourself with these technicalities now.)

As an onlooker, I say "almost surely". Packaging software written in the Go language requires some special care and the Debian Go Team's documentation might help you if you're not familiar.

Quoting John Scott (2025-12-27 17:58:24)
name. AFAIK obfs4proxy doesn't appear configured in the current tor package,
maybe it is in other packages. But it might make sense to make a symlink from
/bin/obfs4proxy to /bin/lyrebird for backward compatibility.

There is already an ITP:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1111471

And I'm not sure how much Yifei has already advanced on this package, but maybe
something to check with Yifei (in CC).

lyrebird is being prepared here:
https://salsa.debian.org/go-team/packages/lyrebird

I still need to work on debian/copyright but functionally it works OK, I
tested it with webtunnel and obfs4 bridges and it worked on my machine. Please
test it if you can and let me know how it goes.

To build it, first build golang-webtunnel-dev from the webtunnel git repo:
https://salsa.debian.org/go-team/packages/webtunnel.git

and build lyrebird with something like `sbuild -s --extra-
package=PATH_TO_golang-webtunnel-dev`

I think having a symlink from /bin/obfs4proxy to /bin/lyrebird is sensible,
that way existing torrc can continue to work.

Thanks,
Yifei.