* Package name : linenoise Version : 1.0+git20180718.4a961c010872 Upstream Author : Salvatore Sanfilippo <antirez@gmail.com> * URL : https://github.com/antirez/linenoise * License : BSD-2-Clause Programming Lang: C Description : Minimal replacement for readline A minimal, zero-config, BSD licensed, readline replacement used in Redis, MongoDB, and Android. * Single and multi line editing mode with the usual key bindings implemented. * History handling. * Completion. * Hints (suggestions at the right of the prompt as you type). * About 1,100 lines of BSD license source code. * Only uses a subset of VT100 escapes (ANSI.SYS compatible).
Hi Jeremy, It's been a few years since this ITP was filed. Do you still plan to package it? I'm packaging osquery which depends on this. Happy to help ;)
Thanks for the offer. :) I've cloned the osquery repo and it appears to use the C++ Linenoise NG fork: https://github.com/arangodb/linenoise-ng not the C original: https://github.com/antirez/linenoise which is what I started packaging. The reason that I stopped work on it was that linenoise is intended to be used by adding the sources to the code-base of the application that wants the functionality. I created a PR to add support for building it as a shared library: https://github.com/antirez/linenoise/pull/174 and there has been no response (mind you, there are a lot of open PR's going back years), so I wasn't sure whether it was worth adding to Debian. I've had a quick look at the linenoise-ng repo and it appears to be API-compatible with the original and has a [c]make file, so it may be a better candidate for packaging -- particularly now that you have provided a use-case for it. I'll take a closer look and see how much of my work can be salvaged. J.
No problem ;) It uses the -ng fork, but the fork's repo was archived in 2017,
which leads me back to the original. And
is "solved" by adding a make target that builds a .so ("solved" only in my
opinion, of course). But…
This is indeed a problem, which I overlooked at first. A second check shows 59
open issues vs 24 closed, and as you said 73 open PRs vs 54 closed, an obvious
sign of abandonment, overlooked largely due to its recent commits.
Speaking of API-compatible — I asked in #debian-mentors and someone expressed
strong concern over the lack of versioning of the original, while -ng at least
has a macro that defines its version.
In the compatibility sense I'm now more on the -ng side. Personally I don't like
cmake… but it's fine on this level.
The use case is a big headache, vendoring everything with its various own
compilation tweaks baked in cmake files. linenoise is hardly a problem compared
to that… Still, happy to help ;)
I came across linenoise because of a request to support it in nftables. The request came from someone who wanted to install nftables in a resource-constrained environment where the existing libreadline support was too heavyweight. In the case of osquery, would it possible to go the other way? Do you think that upstream would be open to adding support for libreadline if we offered patches? J.
Feasible on the resource level I think, it links to many libraries anyway. But for using readline… they actually switched away from it in 2016: https://github.com/osquery/osquery/pull/2613 Considering their rather radical approach of vendoring everything, I don't have too much hope for that.
Ah, right. So much for that idea! It occurs to me that it might make more sense for you to take the lead in packaging linenoise since you have an interest in getting it into Debian. Would you like me to transfer ownership of the ITP bug to you? Happy to lend a hand if you need one. J.
Hmm, can I ask for a review while I upload to mentors.d.n? Wanna make sure I did it right.
Yes, absolutely. Apologies for taking three weeks to reply. J.
Here it goes: https://mentors.debian.net/package/linenoise/
Here it goes: https://mentors.debian.net/package/linenoise/
You've gone a for a less elaborate build process for the shared library than I did: https://github.com/antirez/linenoise/pull/174/commits/ab860406520ad7fc5e7e8e91fcf60cdc43a786f0 but that's probably fine. I do have one observation, however. The shared library should be liblinenoise.so.0.0.0 and there should be two sym-links: liblinenoise.so.0, which is needed by the library's dependencies at run-time, and liblinenoise.so which is needed by its dependencies at build-time. I've attached a patch-series with some suggested changes. J.
This time took literally two weeks, haha. Dragged away by $work. I've applied the patches after reading them. It's great to learn from code. OTOH I saw your salsa repo. Since you've done that much I think it's probably better to let you finish it?
Hi, Any progress on getting linenoise packaged? This is urgently needed to devendor linenoise in the redict package (a new fork of redis). If you've lost interest, I'm happy to take over this ITP. Kind regards, Maytham
I can't speak for Blair, but I transferred ownership of the ITP bug to him, because I didn't have a use-case for linenoise, so if you want to take it on, that's fine by me. I've had a quick look at the upstream project and it doesn't seem entirely dead, which had been a concern. There isn't a lot of activity, but some commits are being made. No response to my PR, however. :) I've updated my Salsa repo to the latest upstream snapshot and given the packaging a polish: https://salsa.debian.org/azazel/linenoise HTH, J.
Hi, sorry for the delay. Please feel free to take over.
retitle 803502 RFP: osquery -- operating system instrumentation framework noowner 803502 retitle 940960 RFP: linenoise -- Minimal replacement for readline noowner 940960 thanks There's unfortunately no compelling use on my end for osquery, thus linenoise.
Hello, Did you have any luck in packaging linenoise? One of the packages I maintain, voronota, embeds linenoise, and I would like to use the Debian-provided code. Andrius