Bug#1075789: ITP: libssc -- libssc
Package: wnpp Severity: wishlist Owner: Guido Günther X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libssc Version : 0.1.6 Upstream Contact: Dylan Van Assche * URL : https://libssc.dylanvanassche.be/ * License : LGPL Programming Lang: C Description : libssc `libssc` is a library to expose the sensors managed by the Qualcomm Sensor Core found in many Qualcomm System-on-Chips (SoCs) from 2018 and onwards
Re: Bug#1074175: netkit-rwho: remove for trixie?
Hi. Most tools from netkit are candidates for migration to GNU InetUtils, and rwho(d) may be another one -- see email and bug report below. Cc'ing debian-devel to have broader discussion. First, I think we need to understand the rationale for doing anything about 'netkit-rwho': do we want to do something because 1) it is not maintained upstream? or 2) because it is an insecure design?, or 3) something else? I believe that like telnet and ftp the second argument is not convincing enough: sometimes you need these implementations for various strange things, and it is poor style to dictate what people must do with their software. The position I've taken in GNU InetUtils is that it is better for users to offer maintained tools and include a notice that they are insecure, rather to offer un-maintained tools and refuse to work further on them because they are insecure, putting users into a worse situation than before. Some people may disagree, and instead believe it is better to actively kill old things rather than continue support them. This is a subjective decision, and if people are willing to do the work to keep things alive, I think it is better to let them than to refuse this contribution. So, are our reason for doing anything about netkit-rwho really because netkit upstream is not maintained? If so, then one option is to add a rwho(d) implementation to GNU InetUtils and let that replace the netkit implementation in Debian. Historically, netkit tools have often had unclear or weird license situation, so my preference is to import rwho(d) from some of the BSD and to make that build for a wide variety of architectures and platforms like we do with other tools in GNU InetUtils. The BSD implementations are usually not intended to be portable, and often have some minor flaw that makes them troublesome to build on Debian -- we fix those issues in GNU InetUtils. That said, introducing yet another fork into the ecosystem shouldn't be done lightly, so we should explore some way to pool resources (like I've tried to establish with tnftp(d) maintainers when we have joint bugs). I haven't analyzed what rwho(d) implementations are out there. I see NetBSD/FreeBSD has one still in -current, but OpenBSD removed it during 5.x. Are people aware of any other implementations worth considering? What do you think? /Simon Gürkan Myczko writes: > rwho(d) is a design from a different time, when networks were > trusted, and so on. It seems to me, we should and could stop > shipping it for trixie. > > I'm raising this bug now, to: > 1) establish awareness > > I was long aware of this, as I was using rwhod/ruptime when networks > were not split into thousand networks... > > 2) auto-rm it from trixie > > I'd rather have a migration path, not binary compatible, but > functionality compatible > > 3) give people time to chime in / secure replacements to show up > > Please have a look at https://github.com/alexmyczko/rutpime (there's > an ITP for it, and it has > been in new queue several times: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013361 > > After a while I intend to clone this bug to ftp.debian.org for > removal from unstable. > > Please do not remove it if possible. I really wish to have a migration > path for this, but well > we're waiting for ftp team. > > Best, > Alex > > Chris > > signature.asc Description: PGP signature
Bug#1075810: ITP: psrecord -- A small utility that records the CPU and memory activity of a process. Can also output results to a plot.
Package: wnpp Severity: wishlist Owner: Alexandru Mihail X-Debbugs-Cc: debian-devel@lists.debian.org * Package name : psrecord Version : 1.4 Upstream Contact: Thomas Robitaille thomas.robitai...@gmail.com * URL : https://github.com/astrofrog/psrecord * License : BSD-2-Clause Programming Lang: Python Description : A small utility that records the CPU and memory activity of a process. Can also output results to a plot. Psrecord is a small python CLI utility that attaches itself to a process and records its CPU and memory usage. It appends results every sample interval into a log file. It can also plot the data nicely into an image file at the end of a session using matplotlib. It provides an easier to use alternative to bash scripts based on ps or /proc files and is lightweight. The plotting feature is similar to heavier, more feature full benchmark utilities in a more minimal package. It provides a different use case compared to top/atop/htop in monitoring a single process for a long time without requiring active monitoring and could be useful in scripting. I began using it recently and find its minimal footprint useful for testing random processes on headless servers or constrained virtual machines which cannot run a more complete test suite. I plan to maintain this package alone for now. If the workload increases in the future, I might start looking for co-maintainers. signature.asc Description: This is a digitally signed message part
Bug#1075835: ITP: python-bayesian-optimization -- Bayesian Optimization package
Package: wnpp Severity: wishlist Owner: Yogeswaran Umasankar X-Debbugs-Cc: debian-devel@lists.debian.org, y...@debian.org * Package name: python-bayesian-optimization Version : 1.5.0 Upstream Contact: Fernando M. F. Nogueira * URL : https://github.com/bayesian-optimization/BayesianOptimization * License : Expat Programming Lang: Python Description : Bayesian Optimization package Pure Python implementation of bayesian global optimization with gaussian processes. This is a constrained global optimization package built upon bayesian inference and gaussian process, that attempts to find the maximum value of an unknown function in as few iterations as possible. This technique is particularly suited for optimization of high cost functions, situations where the balance between exploration and exploitation is important. I planned to maintain this package under DPT.
Bug#1075838: ITP: pygml -- Pure Python parser and encoder for OGC GML Geometries
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pygml Version : 0.2.2 Upstream Author : Fabian Schindler * URL : https://github.com/geopython/pygml * License : MIT Programming Lang: Python Description : Pure Python parser and encoder for OGC GML Geometries The Open Geospatial Consortium (OGC) is an international industry consortium that develops standards for geospatial and location-based services. Geographic Markup Language (GML) is an XML grammar defined by OGC for expressing geographical features. . Pygml supports GML versions 3.1, 3.2, compact encoded GML 3.3, and GeoRSS geometries, converting them to a Geo Interface compliant class. I plan to maintain this package as part of the Python team.
