Re: graphs at https://ftp-master.debian.org/stat.html have intermissions.
On 24/04/18 07:34, Geert Stappers wrote: > > Hello, > > > The graphs at https://ftp-master.debian.org/stat.html have intermissions. > > What used to be a contineus line is now a dotted line. > > > This posting to d-devel@ldo is for asking where to report the issue. > > Who to contact to get it fixed? https://ftp-master.debian.org/#contact Emilio
Re: Please do not drop Python 2 modules
On 23/04/18 23:54, Thomas Goirand wrote: > Also, I have noticed that when removing Python 2 legacy packages, a lot > of cruft remains in the archive. This isn't trivial to track and clean. > I'd love to have the opinion of the FTP master team about this. How can > we file sensible bugs about it? How can I track what hasn't been un-crufted? If the package that you removed has no reverse dependencies, then it will be automatically removed (decrufted), and the removal will be mentioned in https://ftp-master.debian.org/removals.txt If it has rdeps and can't be auto-removed, then it will appear in the cruft report: https://ftp-master.debian.org/cruft-report-daily.txt But please do not remove packages that have rdeps if you don't have a transition plan. Otherwise you're just going to cause your package to get stuck in unstable with no chance to migrate to testing, see e.g.: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894560 By all means start getting your rdeps / python2 apps ported, so that when the time comes, dropping Python 2 support won't be such a daunting task. Cheers, Emilio
Re: graphs at https://ftp-master.debian.org/stat.html have intermissions.
On Tue, Apr 24, 2018 at 09:11:09AM +0200, Emilio Pozuelo Monfort wrote: > On 24/04/18 07:34, Geert Stappers wrote: > > > > The graphs at https://ftp-master.debian.org/stat.html have intermissions. > > What used to be a contineus line is now a dotted line. > > > > This posting to d-devel@ldo is for asking where to report the issue. > > Who to contact to get it fixed? > > https://ftp-master.debian.org/#contact > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896536#10
Bug#896769: ITP: tini -- tiny but valid init for containers
Package: wnpp
Severity: wishlist
Owner: ChangZhuo Chen (陳昌倬)
* Package name: tini
Version : 0.18.0
Upstream Author : Copyright (c) 2015 Thomas Orozco
* URL : https://github.com/krallin/tini
* License : Expat
Programming Lang: C
Description : tiny but valid init for containers
Tini is the simplest init you could think of.
.
All Tini does is spawn a single child (Tini is meant to be run in a
container), and wait for it to exit all the while reaping zombies and
performing signal forwarding.
--
ChangZhuo Chen (陳昌倬) czchen@{czchen,debconf,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790 8793 CC65 B0CD EC27 5D5B
signature.asc
Description: PGP signature
Bug#896770: ITP: dired-rsync -- support for rsync from Emacs dired buffers
Package: wnpp Owner: Lev Lamberov Severity: wishlist * Package name: dired-rsync Version : 0.2 Upstream Author : Alex Bennée * URL or Web page : https://github.com/stsquad/dired-rsync * License : GPL-3+ Programming Lang: Emacs Lisp Description : support for rsync from Emacs dired buffers This package adds a single command dired-rsync which allows the user to copy marked files in a dired buffer via rsync. This is useful, especially for large files, because the copy happens in the background and doesn’t lock up Emacs. It is also more efficient than using TRAMP's own encoding methods for moving data between systems.
How to handle conflict well
We recently had a much better demonstration of how to handle a situation where someone made a mistake, and exceded their authority when uploading, on d-private. With the names and identifying features removed, here are the messages from the maintainer, the contributor, and the sponsor. I have not included messages in the thread from others; those were generally very positive about the way this was handled. Ian. From: Alice Maintainer To: Bob Contributor Cc: debian-priv...@lists.debian.org, Carol Sponsor Subject: Your recent upload of somepkg Date: Tue, 17 Apr 2018 11:53:26 GMT Resent-Message-ID: Hi, Your recent upload of somepkg to unstable surprised me. You did not follow the NMU procedure as far as I can tell. I know I left some mails unanswered, and I have nothing to reproach on a technical level. However, I don't understand the emergency of this upload that would justify breaking the rules. In case of emergency, [there is another way to contact me and I wasn't contacted that way related to Debian recently]. Alice From: Carol Sponsor To: Alice Maintainer Cc: Bob Contributor, debian-priv...@lists.debian.org Subject: Re: Your recent upload of somepkg Date: Tue, 17 Apr 2018 12:38:19 GMT Resent-Message-ID: <2bubp_SKXCF.A.n6C.Wqe1aB@bendel> On Tue, Apr 17, 2018 at 01:53:03PM +0200, Alice Maintainer wrote: > Your recent upload of somepkg to unstable surprised me. You did not > follow the NMU procedure as far as I can tell. > > I know I left some mails unanswered, and I have nothing to reproach > on a technical level. However, I don't understand the emergency of > this upload that would justify breaking the rules. > > In case of emergency, [there is another way to contact me and I > wasn't contacted that way related to Debian recently]. I'm terribly sorry if I assumed things I shouldn't have. However, I'm just about to depart for a week[1], and I'm too busy packing to even investigate the issue. My good phone just broken, so I'm unsure if I'll have adequate connectivity to respond. Thus, I'm afraid I have nothing but this apology to what turned out to be a semi-hijack. I seriously hope this won't be taken similarly to yesterday's flamewar about gjots2. My fault is that I looked only at the technical side of Bob's improvements, without even bothering to ask whether adding themselves as a co-maintainer was discussed with you. I'm sorry to hear you take this badly -- but, any change in unstable can be easily reverted (although I don't believe you'd want to revert the contents of this upload, at most the metadata). In any case, there's enough folks around who, unlike me, have adequate social skills and can mediate. Good day (Nothing private in this mail; house isn't left empty.) [1]. Somecity until Saturday evening; if any readers of -private would want beersigning, it would be awesome. -- Resent-Date: Tue, 17 Apr 2018 15:30:18 + (UTC) From: Bob Contributor To: Alice Maintainer Cc: debian-priv...@lists.debian.org, Carol Sponsor Subject: Re: Your recent upload of somepkg Date: Tue, 17 Apr 2018 15:30:33 GMT Resent-Message-ID: <7R1idsqKVvO.A.koB.KMh1aB@bendel> Hi Alice, It is so great to hear from you. Thank you for your long endeavor of maintaining somepkg. I would never come upon this beautiful piece of software should you not introduce it to Debian. Alice Maintainer writes: > Your recent upload of somepkg to unstable surprised me. You did not > follow the NMU procedure as far as I can tell. Thank you for pointing it out and sorry I haven't read carefully the NMU procedure at https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu And now I see I failed to follow the procedure as per, , | When doing an NMU, you must first make sure that your intention to NMU | is clear. Then, you must send a patch with the differences between the | current package and your proposed NMU to the BTS. ` Last weekend, I did not investigate the literature and went ahead to ask for advice on #debian-devel. I thought adding myself as an uploader was the quickest way to achieve my goal. I will be careful next time. Actually, as Carol said, feel free to revert my changes. The public conversation over #debian-devel was (oftc/\#debian-devel/2018-MM-DD.log) , | [HH:06:50] [ I'm a DM and I want to upload somepkg, |maintained by Alice. It's rather out of |date and the maintainer seems not to have time. |How can I be made an uploader ? ] | | [HH:11:59] [ The package is in collab-maint. | So you just need to have it | sponsored by a DD. ] | | [HH:14:47] [ bystander: Thanks. Would you be able to |sponsor me ? The package is a small one |for rotating stoats. It won't take up |too much of your time. ] | | [HH:15:33] [ I'm aware of somepkg, but I'm afraid | I don't have time
Bug#896810: ITP: libjs-js-md5 -- simple MD5 hash function for JavaScript
Package: wnpp Severity: wishlist Owner: Xavier Guimard * Package name: libjs-js-md5 Version : 0.7.3 Upstream Author : Chen, Yi-Cyuan * URL : https://github.com/emn178/js-md5 * License : Expat Programming Lang: JavaScript Description : simple MD5 hash function for JavaScript js-md5 provides a md5() function that supports UTF-8 encoding and Array, Uint8Array and ArrayBuffer types. Different outputs are supported: hex, array, arrayBuffer or base64
Bug#896816: ITP: lowdown -- Simple markdown translator
Package: wnpp Severity: wishlist Owner: Jon Bernard * Package name: lowdown Version : 0.3.2 Upstream Author : Kristaps Dzonsons * URL : https://kristaps.bsd.lv/lowdown/ * License : ISC Programming Lang: C Description : Simple markdown translator Lowdown is a Markdown translator producing HTML5 and roff documents in the ms and man formats. It doesn't require XSLT, Python, or external libraries – it’s just clean, secure, open source C code with no dependencies. Its canonical documentation is lowdown(1) for the formatter, lowdown(5) for the syntax, and the library interface at lowdown(3).
Re: Please do not drop Python 2 modules
On 2018-04-24 07:45:16 +0200 (+0200), Matthias Klose wrote: [...] > Sure we can remove mercurial and OpenStack if they are not ready > for Python3, but I'd like to avoid that. It doesn't mean that we > should any old, upstream unmaintained Python2 dependent package. To be clear, OpenStack has been thoroughly testing its upstream releases against Python 3 for a while. The reason it was brought up earlier in this thread is because Thomas has recently dropped Python 2.7 builds for it and switched to only building Python 3.x packages. -- Jeremy Stanley signature.asc Description: PGP signature
Bug#896839: ITP: aes-js.js -- pure JavaScript implementation of the AES block cipher algorithm
Package: wnpp Severity: wishlist Owner: Xavier Guimard * Package name: aes-js.js Version : 3.1.1 Upstream Author : Richard Moore * URL : https://github.com/ricmoo/aes-js * License : Expat Programming Lang: JavaScript Description : pure JavaScript implementation of AES aes-js provides a pure JavaScript implementation of the AES block cipher algorithm and all common modes of operation (CBC, CFB, CTR, ECB and OFB). It also supports all key sizes (128-bit, 192-bit and 256-bit). It works in either node.js or web browsers.
Re: Please do not drop Python 2 modules
On Tue, Apr 24, 2018 at 12:29:54AM +0200, Thomas Goirand wrote: > Looking at other distros is interesting. If I understand well, they will > never have Python 2 and 3 interpreters in the distro, and will > completely switch from 2 to 3 at once. Unless I'm misunderstanding, I don't think you're correct. To give a concrete example, Fedora switched to using Python 3 as the default several releases ago[1]; despite that, Python 2 is still available in the archive, and will get pulled in when installing software that (regrettably) hasn't been ported yet. The same is true for FreeBSD and, I believe, Ubuntu. I'm not familiar with the approach other distributions and OS are taking, but I would expect it to be fairly similar. [1] https://fedoraproject.org/wiki/Changes/Python_3_as_Default -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#896846: ITP: node-compressjs -- fast pure-JavaScript compression/decompression algorithms
Package: wnpp Severity: wishlist Owner: Daniel Kahn Gillmor * Package name: node-compressjs Version : 1.0.3 Upstream Author : C. Scott Ananian * URL : https://github.com/cscott/compressjs * License : GPL Programming Lang: Javascript Description : fast pure-JavaScript compression/decompression algorithms Fast, pure-JavaScript implementations of various compression and decompression algorithms, including: * bzip2 * LZP3 * a modified LZJB, and * PPM-D --- this is needed for recent versions of OpenPGP.js, which i'm struggling to package. --dkg
Re: Please do not drop Python 2 modules
On 2018-04-24 22:39:48 +0200 (+0200), Andrea Bolognani wrote: > On Tue, Apr 24, 2018 at 12:29:54AM +0200, Thomas Goirand wrote: > > Looking at other distros is interesting. If I understand well, they will > > never have Python 2 and 3 interpreters in the distro, and will > > completely switch from 2 to 3 at once. > > Unless I'm misunderstanding, I don't think you're correct. > > To give a concrete example, Fedora switched to using Python 3 > as the default several releases ago[1]; despite that, Python 2 > is still available in the archive, and will get pulled in when > installing software that (regrettably) hasn't been ported yet. > > The same is true for FreeBSD and, I believe, Ubuntu. I'm not > familiar with the approach other distributions and OS are > taking, but I would expect it to be fairly similar. [...] Rumor has it that RHEL 8 will be dropping Python 2 while (finally!) adding Python 3. Much of that is fueled by the Deprecated Functionality[*] section of the RHEL 7.5 Release Notes wherein it states, "Python 2 will be replaced with Python 3 in the next Red Hat Enterprise Linux (RHEL) major release." [*] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.5_release_notes/chap-red_hat_enterprise_linux-7.5_release_notes-deprecated_functionality > -- Jeremy Stanley signature.asc Description: PGP signature
Re: Please do not drop Python 2 modules
On Tue, Apr 24, 2018 at 10:42:15PM +, Jeremy Stanley wrote: > On 2018-04-24 22:39:48 +0200 (+0200), Andrea Bolognani wrote: > > To give a concrete example, Fedora switched to using Python 3 > > as the default several releases ago[1]; despite that, Python 2 > > is still available in the archive, and will get pulled in when > > installing software that (regrettably) hasn't been ported yet. > > > > The same is true for FreeBSD and, I believe, Ubuntu. I'm not > > familiar with the approach other distributions and OS are > > taking, but I would expect it to be fairly similar. > [...] > > Rumor has it that RHEL 8 will be dropping Python 2 while (finally!) > adding Python 3. Much of that is fueled by the Deprecated > Functionality[*] section of the RHEL 7.5 Release Notes wherein it > states, "Python 2 will be replaced with Python 3 in the next Red Hat > Enterprise Linux (RHEL) major release." Two paragraphs below the text you quoted: > Note that Python 3 is available to RHEL customers, and supported > on RHEL, as a part of Red Hat Software Collections. So you could say that RHEL is taking the approach described above - having a transitional period where both versions are available side by side - with the only difference being that Python 3 is currently not delivered through the same channel as Python 2. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Re: Please do not drop Python 2 modules
On 2018-04-25 01:05:59 +0200 (+0200), Andrea Bolognani wrote: [...] > So you could say that RHEL is taking the approach described above - > having a transitional period where both versions are available side > by side - with the only difference being that Python 3 is currently > not delivered through the same channel as Python 2. Given that "software collections" provides a containerized Python 3 build and basically none of the rest of the Python ecosystem modules outside the stdlib (which would all require manual rebuilding against it), this is nowhere close to the same as providing an optional Python interpreter within the global system context as Debian has done. At least the projects I work on don't see RHEL software collections Python 3 as remotely supportable. -- Jeremy Stanley signature.asc Description: PGP signature
Re: Please do not drop Python 2 modules
On Tue, Apr 24, 2018 at 12:29:54AM +0200, Thomas Goirand wrote: > On 04/21/2018 11:19 PM, Scott Kitterman wrote: > > Since we are supporting Python2 in the next release, there is no value> in > > dumping python-* packages now. Unlike many areas of the archive, > > Python packages are actively used by third-party code that isn't and > > won't be in Debian. > > There's always value to start de-crufting legacy stuff early. That being > said, I hear your message: this is breaking 3rd party code, and we need > to keep this in mind. > > > I'm generally in favor of getting rid of old stuff, but python2 isn't > > there yet. > > Right. But I do believe we need to be very careful to not send a wrong > message to our users. Debian deprecating Python 2 is good. A strong, > bold deprecation message is needed, even if we want to continue > supporting Python 2 for a bit more. At what stage should Python IDEs uploaded to NEW disable or not install Python 2 support? Now? Should Python 2-specific IDEs and/or Python 2-specific educational materials be removed from the archive? If so, then when? Andreas, I've CCed you because we've been in touch in the past, and because I have friends who do graduate work in bioinformatics on Debian systems. With the upcoming end of Python 2 in Debian, what can we do to avoid losing them to CentOS? Also, if appropriate and if it wouldn't be too much work, does Debian have a role in encouraging new masters and PhD candidates to choose Python 3? Sincerely, Nicholas signature.asc Description: PGP signature
Bug#896850: ITP: golang-github-bruth-assert -- Simple test assertions for Golang tests
Package: wnpp Severity: wishlist Owner: Arnaud Rebillout * Package name: golang-github-bruth-assert Version : release.r60+git20130823.de420fa-1 Upstream Author : Byron Ruth * URL : https://github.com/bruth/assert * License : Expat Programming Lang: Go Description : Simple test assertions for Golang tests Assert Simple test assertions for Go. This is a fork of a fork of a bmizerany/assert (http://github.com/bmizerany/assert) with improved support for things like nil pointers, etc. Why packaging it? I'm packaging Docker, this is a dependency of Docker cli.
Bug#896852: ITP: golang-github-ishidawataru-sctp -- SCTP library for the Go programming language
Package: wnpp Severity: wishlist Owner: Arnaud Rebillout * Package name: golang-github-ishidawataru-sctp Version : 0.0~git20180208.07191f8-1 Upstream Author : Wataru Ishida * URL : https://github.com/ishidawataru/sctp * License : Apache-2.0 Programming Lang: Go Description : SCTP library for the Go programming language Stream Control Transmission Protocol (SCTP) Why packaging it? I'm packaging Docker, this is a dependency of Docker cli.
Bug#896853: ITP: golang-gopkg-gorethink-gorethink.v3 -- Go language driver for RethinkDB
Package: wnpp Severity: wishlist Owner: Arnaud Rebillout * Package name: golang-gopkg-gorethink-gorethink.v3 Version : 3.0.5-1 Upstream Author : Daniel Cannon * URL : https://github.com/gorethink/gorethink * License : Apache-2.0 Programming Lang: Go Description : Go language driver for RethinkDB Why packaging it? I'm packaging Docker, this is a dependency of Docker cli.
Bug#896854: ITP: golang-vbom-util -- Go utility packages
Package: wnpp Severity: wishlist Owner: Arnaud Rebillout * Package name: golang-vbom-util Version : 0.0~git20170409.256737a-1 Upstream Author : Frits van Bommel * URL : https://github.com/fvbommel/util * License : Expat Programming Lang: Go Description : Go utility packages Package util includes various small pieces of code. . cmd/short-regexp . short-regexp is a command-line utility that reads strings from standard input (one per line) and outputs a regexp that matches only those strings. . rope . Package rope implements a "heavy-weight string", which represents very long strings more efficiently (especially when many concatenations are performed). . sortorder . Package sortorder implements sort orders and comparison functions. Why packaging it? I'm packaging Docker, this is a dependency of Docker cli.
Bug#896855: ITP: fernet-go -- Generates and verifies HMAC-based authentication tokens
Package: wnpp Severity: wishlist Owner: Arnaud Rebillout * Package name: fernet-go Version : 0.0~git20151007.1b2437b-1 Upstream Author : Keith Rarick * URL : https://github.com/fernet/fernet-go * License : Expat Programming Lang: Go Description : Generates and verifies HMAC-based authentication tokens Fernet takes a user-provided *message* (an arbitrary sequence of bytes), a *key* (256 bits), and the current time, and produces a *token*, which contains the message in a form that can't be read or altered without the key. Why packaging it? I'm packaging Docker and it's a dependency of the Docker engine.
Bug#896856: ITP: golang-github-ijc-gotty -- Gotty is a library written in Go that provides interpretation and loading of Termcap database files.
Package: wnpp Severity: wishlist Owner: Arnaud Rebillout * Package name: golang-github-ijc-gotty Version : 0.0~git20170406.a8b993b-1 Upstream Author : Neal van Veen, Ian Campbell * URL : https://github.com/ijc/Gotty * License : BSD-2-clause Programming Lang: Go Description : Go library for working with Termcap database files Gotty is a library written in Go that determines and reads termcap database files to produce an interface for interacting with the capabilities of a terminal. See the godoc documentation or the source code for more information about function usage. Why packaging it? I'm packaging Docker and it's a dependency of the Docker engine.
Bug#896857: ITP: golang-github-phayes-permbits -- Easy file permissions for golang.
Package: wnpp Severity: wishlist Owner: Arnaud Rebillout * Package name: golang-github-phayes-permbits Version : 0.0~git20171109.529f712-1 Upstream Author : Patrick D Hayes * URL : https://github.com/phayes/permbits * License : Expat Programming Lang: Go Description : Easy file permissions for golang. Easily get and set file permission bits. This package makes it a breeze to check and modify file permission bits in Linux, Mac, and other Unix systems. Why packaging it? I'm packaging Docker and it's a dependency of the Docker engine.
Re: Please do not drop Python 2 modules
Le mer. 25 avr. 2018 01:54, Nicholas D Steeves a écrit : > On Tue, Apr 24, 2018 at 12:29:54AM +0200, Thomas Goirand wrote: > > On 04/21/2018 11:19 PM, Scott Kitterman wrote: > > > Since we are supporting Python2 in the next release, there is no > value> in dumping python-* packages now. Unlike many areas of the archive, > > > Python packages are actively used by third-party code that isn't and > > > won't be in Debian. > > > > There's always value to start de-crufting legacy stuff early. That being > > said, I hear your message: this is breaking 3rd party code, and we need > > to keep this in mind. > > > > > I'm generally in favor of getting rid of old stuff, but python2 isn't > > > there yet. > > > > Right. But I do believe we need to be very careful to not send a wrong > > message to our users. Debian deprecating Python 2 is good. A strong, > > bold deprecation message is needed, even if we want to continue > > supporting Python 2 for a bit more. > > At what stage should Python IDEs uploaded to NEW disable or not > install Python 2 support? Now? > > Should Python 2-specific IDEs and/or Python 2-specific educational > materials be removed from the archive? If so, then when? > > Andreas, I've CCed you because we've been in touch in the past, and > because I have friends who do graduate work in bioinformatics on > Debian systems. With the upcoming end of Python 2 in Debian, what can > we do to avoid losing them to CentOS? Also, if appropriate and if it > wouldn't be too much work, does Debian have a role in encouraging > new masters and PhD candidates to choose Python 3? > I do not see your point here. Regarding education, using python 2 or 3 should be transparent. The matter is only to have the expected programs/libraries available in python3. The only issue would be for students not to have their favorite program available. Anyway, py2 will not be supported anymore at some time... Olivier > Sincerely, > Nicholas >
Bug#896859: ITP: node-fs-jetpack -- high-level file API for Node.js
Package: wnpp Severity: wishlist Owner: Xavier Guimard * Package name: node-fs-jetpack Version : 1.3.0 Upstream Author : Jakub Szwacz * URL : https://github.com/szwacz/fs-jetpack * License : Expat Programming Lang: JavaScript Description : high-level file API for Node.js Node's fs library is very low level and because of that often painful to use. fs-jetpack wants to fix that by giving you completely rethought, much more convenient API to work with file system.
Re: Please do not drop Python 2 modules
On Tue, Apr 24, 2018 at 11:17:08PM +, Jeremy Stanley wrote: > On 2018-04-25 01:05:59 +0200 (+0200), Andrea Bolognani wrote: > [...] > > So you could say that RHEL is taking the approach described above - > > having a transitional period where both versions are available side > > by side - with the only difference being that Python 3 is currently > > not delivered through the same channel as Python 2. > > Given that "software collections" provides a containerized Python 3 > build and basically none of the rest of the Python ecosystem > modules outside the stdlib (which would all require manual > rebuilding against it), this is nowhere close to the same as > providing an optional Python interpreter within the global system > context as Debian has done. At least the projects I work on don't > see RHEL software collections Python 3 as remotely supportable. Fair enough; the point about distribution with lifecycles closer to Debian's keeping Python 2 around for a while after switching their default to Python 3 still stands. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#896862: ITP: ruby-ed25519 -- efficient digital signature library providing the Ed25519 algorithm
Package: wnpp Severity: wishlist Owner: Unit 193 * Package name: ruby-ed25519 Version : 1.2.4 Upstream Author : Tony Arcieri * URL : https://github.com/crypto-rb/ed25519 * License : Expat Programming Lang: Ruby Description : efficient digital signature library providing the Ed25519 algorithm A Ruby binding to the Ed25519 elliptic curve public-key signature system described in RFC 8032. . Ed25519 is a modern implementation of a Schnorr signature system using elliptic curve groups. . Ed25519 provides a 128-bit security level, that is to say, all known attacks take at least 2^128 operations, providing the same security level as AES-128, NIST P-256, and RSA-3072. This package will be required for newer versions of ruby-net-ssh.
