* Package name : et
Upstream Author : Jason Gauci
* URL : https://mistertea.github.io/EternalTCP/
* License : Apache 2.0
Programming Lang: C++
Description : Eternal Terminal (ET) is a remote shell that automatically
reconnects without interrupting the session.
Also why is this changed to RFP? I'm more than happy to maintain this package since I'm the author :-) Jason G.
didn't check if PPA upstream promotes a good start Re Jason's because it had been over a year without package materializing, thus it is more of RFP than ITP.
Hi ChangZhuo,
For fun, I did a packaging for it, see https://salsa.debian.org/ncts/EternalTerminal. Note it Debianizes on top of upstream Git history, including removing Files-Excluded in the debian/sid branch, a style some haven't adopted yet or won't, though the debian/ directory should still be usable when copied to a gbp-import-orig style packaging.
A few problems:
- A few dependencies are still vendored, under external_imported/. Arguably they are small enough (~2k SLoC total from tokei).
- Binary packages are named et and etserver, per upstream naming. Such short names might become controversial.
- The htm and htmd executables are installed into /usr/libexec/et/, because I don't really know what they do, other than a vague line of "headless terminal multiplexer". You might want to mention such in a README.Debian.
- Additionally, htm is installed into /usr/libexec/et/htm_/, with a wrapper in the expected place. The reason is that, htm calls `system("htmd")`, which I suppose expects htmd to be in $PATH. The wrapper prepends the libexec path before calling the actual htm executable.
- `-fuse-ld=mold`. This is mostly personal preference, but does have the nice aspect of reducing build time (if mold is really faster than GNU ld or lld, I didn't benchmark).
Telemetry is completely removed.
I'm mildly interested in this software, though don't currently have the passion to be its (co-)maintainer. So please feel free to take what you need, and change my name in various fields to yours :>
This seems amazingly close to inclusion. Perhaps man pages for htm and htmd can be quickly written up? On Wed, 8 Jan 2025 22:43:44 +0800 Blair Noctis <ncts@debian.org> wrote: > Hi ChangZhuo, > > For fun, I did a packaging for it, see https://salsa.debian.org/ncts/EternalTerminal. Note it Debianizes on top of upstream Git history, including removing Files-Excluded in the debian/sid branch, a style some haven't adopted yet or won't, though the debian/ directory should still be usable when copied to a gbp-import-orig style packaging. > > A few problems: > > - A few dependencies are still vendored, under external_imported/. Arguably they are small enough (~2k SLoC total from tokei). > - Binary packages are named et and etserver, per upstream naming. Such short names might become controversial. > - The htm and htmd executables are installed into /usr/libexec/et/, because I don't really know what they do, other than a vague line of "headless terminal multiplexer". You might want to mention such in a README.Debian. > - Additionally, htm is installed into /usr/libexec/et/htm_/, with a wrapper in the expected place. The reason is that, htm calls `system("htmd")`, which I suppose expects htmd to be in $PATH. The wrapper prepends the libexec path before calling the actual htm executable. > - `-fuse-ld=mold`. This is mostly personal preference, but does have the nice aspect of reducing build time (if mold is really faster than GNU ld or lld, I didn't benchmark). > > Telemetry is completely removed. > > I'm mildly interested in this software, though don't currently have the passion to be its (co-)maintainer. So please feel free to take what you need, and change my name in various fields to yours :> > > -- > Sdrager, > Blair Noctis
Seems like this has stalled unfortunately?
Folks, A full year passed since I proposed a packaging for then latest 6.2.9. I'd rather that effort doesn't go into the void. I didn't see, however, that the old ITP bugs were from 2017 and 2018, when it was named EternalTCP. I didn't quite even knew what Debian was back then. (And Debian hasn't changed much in the way it handles "bug" reports.) So it's possible that as years passed by you have lost interest in maintaining it. It'd be helpful it you state so. And we can move it to be a RFP so someone else could take it. If you still ITP, please consider doing so, maybe using my previous packaging.
Sorry, can you help me understand this thread? I maintain Debian packages in a separate repo, but would love to get them into main Debian. Is that the topic here?
Yes. The intent-to-package and request-for-package have been floating for several years unfortunately.
Got it. If there's any way I can help, just let me know