I think Mosh would be happy to support this transition, but Mosh doesn't
write to utmp/wtmp itself or with a PAM module; Mosh uses libutempter for
this. If libutempter is going to be updated to use wtmpdb, I don't think
Mosh itself has to change.
Sincerely,
Keith
On Thu, May 30, 2024 at 11:49 AM
forwarded 1005718 https://github.com/mobile-shell/mosh/issues/1174
thankyou
On Sun, Feb 13, 2022 at 1:03 PM Sebastian Andrzej Siewior
wrote:
>
> Source: mosh
> Version: 1.3.2-2.1
> Severity: important
> Tags: bookworm sid
> User: pkg-openssl-de...@lists.alioth.debian.org
> Usertags: ftbfs-3.0
>
its packages to have, I'm happy to comply and have no quibbles
with your patch.
Cheers,
Keith
On Fri, Dec 18, 2020 at 3:24 PM Vagrant Cascadian <
vagr...@reproducible-builds.org> wrote:
> On 2020-12-18, Keith Winstein wrote:
> > Thank you for tracking this down! Hap
Thank you for tracking this down! Happy to take the patch -- would you mind
filing this as an upstream pull request at
https://github.com/ravinet/mahimahi ? That way we will have this in one
place when we next have cycles to upload a new mahimahi package.
Sincerely,
Keith
On Fri, Dec 18, 2020 at
Hello -- unfortunately mosh-server does need to be installed on the server
(it is sort of like ssh in this respect). You can either install it from a
package (which probably requires root -- you would need to ask the
sysadmin), or you can compile it from source, install it in your own home
director
Thank you for the bug report. I believe this is a duplicate of bug 803253,
which was fixed in mosh 1.2.5-1.1.
2018-05-22 1:08 GMT-07:00 ikar.us :
> Package: mosh
> Version: 1.2.5-1~bpo8+1
> Severity: important
>
>
> root@:~# apt-get -t jessie-backports install mosh
> Paketlisten werden gelesen...
Thank you for this report. Is it possible you have a different version of
libprotobuf in your LD_LIBRARY_PATH, or a different version of mosh-server
in your PATH?
(Do you have anything related to libprotobuf in /usr/local ?)
On Sun, Jul 30, 2017 at 2:40 PM, Ivan Vucica wrote:
> Package: mosh
>
This is caused by #817236. We are working on a workaround.
On Sat, Feb 11, 2017 at 4:05 AM, Adrian Bunk wrote:
> Source: mosh
> Version: 1.3.0~rc2-1
> Severity: serious
>
> https://buildd.debian.org/status/package.php?p=mosh
>
> ...
> FAIL: local
> ===
>
> ../../scripts/mosh: Did not fin
Hello Dominik,
Mosh, OpenSSH, and TELNET all just literally convey these characters from
the client to the pty. None of these programs try to interpret sequences
like "Ctrl-A n" or "ESC #". (To double-check, I have just tested ESC #
using "mosh localhost" and I could not see any difference in the
On Tue, Nov 8, 2016 at 1:53 AM, Philipp Marek
wrote:
> > 3) Can you please send all *three* logs from "script"? We need
> simultaneous
> > captures of the output (1) entering tmux, (2) leaving tmux and entering
> > mosh, and then (3) leaving mosh.
> All three things are included in the previous f
Thanks Philipp!
1) Can you fill me in -- what version of Mosh is running on the server in
your setup?
2) There are packages for pre-1.2.6 versions of Mosh in wheezy, jessie, and
jessie-backports (please see https://packages.debian.
org/search?keywords=mosh). You could also build from source (it w
Thank you for this report.
What version of Mosh is running on the server?
What architecture is the server (is it also a Debian amd64 machine)?
Could you please also test running Mosh 1.2.5 on the client *and* server,
and seeing if you can replicate the bug? That will help us determine if
this is
Thank you. I'm not sure what the etiquette is here -- I am fine with this
proposed change (we have taken the patch upstream but have not released a
new version of Mosh or an updated package yet). I'm happy to let your NMU
go through as-is, but if you would like me to do a 1.2.5-2 upload that
cherry
Thanks -- can you confirm that this fixes the problem for you? If so I'm
happy to apply it.
On Wed, Oct 28, 2015 at 2:47 PM, Jakub Wilk wrote:
> Control: tags -1 + patch
>
> --
> Jakub Wilk
>
My suspicion is that this error is coming from some package that mosh
depends on, instead of from mosh itself. Mosh doesn't try to run dpkg
itself.
Do you see this error message if you remove the mosh package (dpkg --purge
mosh) and then re-install mosh only?
On Wed, Oct 28, 2015 at 5:30 AM, Jaku
I have just packaged and uploaded the upstream 1.2.5 release.
Please feel free to upload this package to backports once it reaches testing.
Best regards,
Keith
On Tue, Jul 21, 2015 at 1:17 PM, Miguel Landaeta wrote:
> Package: mosh
> Version: 1.2.4a-1+b2
> Severity: wishlist
>
> Now 1.2.4.95rc2
This is fixed in git (adding a new mosh option, --bind-server=ANY) and
will be in the next release.
On Fri, Sep 7, 2012 at 12:12 PM, chrysn wrote:
> Package: mosh, sslh
> Severity: minor
>
> mosh can't be used on hosts that hide their ssh services behind sslh.
>
> when connecting to such a host,
Thank you for catching this. We applied the patch and pushed to
Github. It will be in the next release.
On Sat, Nov 17, 2012 at 8:29 AM, Jonathan McCrohan wrote:
> Package: mosh
> Severity: normal
> Tags: patch
>
> Hi,
>
> Github have changed their website which breaks debian/watch. I have
> atta
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hello,
We respectfully request that you unblock mosh 1.2.3-1 and include it
in the wheezy release. A debdiff from mosh 1.2.2-1 is available at
http://mosh.mit.edu/mosh_1.2.2-1_to_mosh-1.2.3
Package: mosh
Version: 1.2.3-1
Closing, as we believe performance over this kind of network has been
improved in 1.2.3 and have not heard back from filer. Please reopen if
this is not your experience.
On Fri, Oct 5, 2012 at 9:11 PM, Keith Winstein wrote:
> Hello,
>
> Could you pleas
Hello,
Could you please try the 1.2.2.95rc1-1 package, recently uploaded to
unstable, and see if you still have trouble? The source package should
build fine on stable as well.
We can't think of something that could have gotten worse between 1.1 and
1.2, but 1.2.3 (and its release candidate) have
Package: debian-maintainers
Dear Maintainer,
Please add Keith Winstein to the Debian Maintainers
keyring. I attached the jetring changeset.
Thanks very much,
KeithComment: Add Keith Winstein as a Debian Maintainer
Date: Mon, 04 Jun 2012 19:06:47 -0400
Action: import
Recommended-By
Thanks for this.
This has been added to the version in Git and the 1.2.1 release candidate
if you would like to test it.
(https://github.com/downloads/keithw/mosh/mosh-1.2.0.97.tar.gz)
We are planning to release 1.2.1 imminently so please let me know if this
does not meet your needs asap.
Best
Thanks, Timo, and thanks for submitting the original bug as well.
This bug allows applications and unscreened terminal input (run or
"catted" by the user) to DOS the mosh-server (also run by the user).
It also allowed the mosh-server process (invoked by the user but
resident on a remote host and n
Hello,
Thanks for the report. Mosh does need to have working UDP passing in
both directions. In the documentation (http://mosh.mit.edu), we
recommend just opening UDP ports 6-61000, but you can open a
smaller range if you like (e.g. 6-60010) or just open a single
port and request it with t
Package: mosh
Version: 1.2-1
Thanks for this report. We made this much smoother in version 1.2
(just released), both in avoiding the error and in giving a clear
diagnostic when it can't be avoided.
In previous versions, you do need to have SSH set up to pass the
locale-related environment variabl
Further testing indicates that FreeBSD just doesn't have working UTF-8
character-erase (yet); the kernel does leave garbage in the input
buffer when it tries to erase a multibyte character in canonical mode.
We decided to just add an autoconf test for IUTF8, triggering a patch
along the lines subm
Hello,
Thanks for filing this. I can't take this patch as written, but I am very
interested in getting mosh working on FreeBSD.
(1) We need and use IUTF8 on Mac OS X (XNU), so #ifdef __linux__ is not
quite the right test.
(2) On platforms without IUTF8, we still need _some_ solution to the
Hello,
Thanks for filing -- you are correct. The mosh protocol is IPv4 only for
now. We have some people working on an IPv6 port and I plan to commit
these changes as soon as I can verify that IPv4-to-IPv6-to-IPv4 roaming is
correctly implemented and that mosh behaves sensibly in common
confi
tag wontfix
thanks
Please feel free to reopen if necessary.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Thanks for this. My thinking has been that the client and server
really just sit there, linked with the same libraries, and it would be
silly to split them into two separate packages. (It is true that the
client pulls in openssh-client, but that also just sits there and is
relatively small.)
But I
31 matches
Mail list logo
