IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Not that clap is bad or anything the like, but for one it's rather
over engineered, and it has to be as long as it wants to provide a
dozen wildly different way to do things.
And the second, more important reason: it's still undergoing a lot of
churn every year or so. Each upgrade to a major version needs like
two hours of understanding what's going on, at least if one wants to
Do It Right™.
Termproxy, otoh., is a small and internal tool that doesn't need an
overly fancy CLI targetting humans, as it will be only called by the
API anyway.
So, to reduce the time required to constantly catch up, and remove
some complexity, switch over to pico-args. That one provides a few
small interfaces for the most common things, does it right and uses
OsString as main type and has exactly zero dependencies on its own.
In other words, perfect for such internal tools (and possibly also
most others).
Copy over the help output from the clap based tool for convenience,
pico-args really doesn't bother with such things, and introduce an
Options struct to have a, well, more structured way of handling CLI
arguments/options.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The valid upper range was swapped, while at it switch from i32::Max to
RawFd::Max, while currently RawFd is a type alias to i32, it's easier
to grasp what's going on and might even change in the future.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
this is not a standard CLI tool that should be exposed to all users,
but an internal binary, so move it to /usr/libexec/proxmox.
That location was chosen over a multiarch path
/usr/lib/<triplet>/proxmox to make resolving the path easier for the
caller, as the standard ways to get the multiarch triplet (e.g.,
"x86_64-linux-gnu") involve CC and are not easily/cheaply available in
perl – we would basically create an architecture specific package that
provides a path resolution with multiarch triplet resolved at "build"
time of that module; as we probably do not ever install termproxy
multiple times targeting different arch's on the same system, this is
just to much complexity.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
shaves of over 100KB of the final binary and this crate is small
enough to not notice a relevant compile time impact.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
We should have never added a upstream repackage and some custom tools
in the same source package, let alone binary package. Finally resolve
that tech debt and do a split.
This commit does a bit more than I'd like at once, but it's really not
trivial to make a clean split while keeping all sanely buildable in
multiple commits.
What roughly happens is:
- two complete separate source packages
- one for xterm.js, we keep this purely to the xterm.js and our
local additions and modifications that are relevant directly to
xterm.js itself
- one for termproxy, where only the rust-based tool is shipped.
This also reduces churn, as the termproxy doesn't sees lots of
updates, so no point in building it on every xterm.js update.
- drop debcargo, which while great for library source code packages
for build dependencies, is just a PITA for binary packages
shipping actual compiled rust code, it adds almost nothing there
but provides lots of special handling to get the correct result.
- rename `termproxy` to `proxmox-termproxy` but keep a backward
compat link for now, termproxy is way to general a name.
Maybe we should also move this away from /bin in general, into the
/lib/<arch-qualifier>/proxmox/ directory like we do for
proxmox-backup.
- clean ups all over the place
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
