Bug#951855:
Maybe Michal is busy? We already had one round and he accepted all the fixes (found during packaging gammu) upstream. At that time there were several things to improve and the package was not ready for uploading. Also I will need sponsoring the upload, but I think that the proper way is to wait for Michal to approve and sponsor this. In case he only approves, I will file a RFS... -- With best regards, b. signature.asc Description: This is a digitally signed message part
Bug#959161: ITA: complexity -- tool for analyzing the complexity of C program functions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: wnpp Severity: normal Control: owner -1 ! Control: thanks I intend to adopt the complexity package. There are no bugs open. The upstream looks like not dead with a recent release. The update to the latest release version is not trivial - it includes removing repackaging because the offending file is licensed under a free license (but would generate content that itself is under a non- DFSG license and that is not used in the build). The proposed upload is in mentors. I believe that I am able to properly maintain it. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEumC8IPN+WURNbSUAE2VyCRPS8i0FAmE+wckACgkQE2VyCRPS 8i31fg/+OULA91T9o88NMiDCezasjn5fJkYSEuuJkMY7ENA8GEfQTSnSGyc1EeR6 bmjoMmC4ir3c1kkLwIqO1fpWXgSfZC1JdpuoLXlWFWXCZUFhzoNnfAtySpPDFGvA +iL4H+icVaazHhrFZGTQ3KEZ3QAnUa1/PVWFLD28SUke5jEgcE+/t4tEvwLo8Kf6 apUAjkocWpBrFk0wgCJxEFQFQU0o+aQLjkxgF+sT51HYbpD8bEvZfJmvw/w4onFW rlayYrR9vGhAF6TbKz1k6PXbQGnFy19b6hX5X0RkvkyfSfeEEZkQw9cPwveqtNNj rw2yAA+8Ko10XIMEyT5j7et5GCIpL5j+CKr3Y2Qj7g1ZcugE3hakN2BTco9ePTle VygaP85S/sdaNR/TMPfCxAcfi3MjLiBAAS58A8cIJLyVCEQVkAr/f/M8TD8/7l5R DBbw+lzj6FVMOBRPzzKpvjQTF4Wz1vPuOrLgI7JAgLKgzg/KZ3rQfda9ojpAb13E cHdaas2fA9wd/e6E/TTbWPOB0hczsjCcFAi2VBNcn+w8SBbUOrHka21UMCnP5wFJ caWeWr0+HhV6hsz+yRpaOVsuW1PF8E1ei30xR3oFKKe/SPi8bn/RM9SCWNdO5lJW sy5dKtONGVU0fmOIgEJF8t1x0xtxKZuH4xEbRtJxzPUOBftzeD8= =r8IN -END PGP SIGNATURE-
Bug#969931: ITP: bpfmon -- BPF based visual packet rate monitor
Initial packaging is done and uploaded to mentors.d-n https://mentors.debian.net/package/bpfmon/
Bug#969927: ITP: yascreen -- Yet Another Screen Library (curses replacement for daemons and embedded apps)
Initial packaging is done and uploaded to mentors.d-n https://mentors.debian.net/package/yascreen/
Bug#969931: ITP: bpfmon -- BPF based visual packet rate monitor
Package: wnpp Severity: wishlist Owner: Boian Bonev X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: bpfmon Version : 2.46 Upstream Author : Boian Bonev * URL : https://github.com/bbonev/bpfmon * License : AGPL-3 Programming Lang: C Description : BPF based visual packet rate monitor While tcpdump shows the packets that match a BPF filter, bpfmon shows how many are they in a visual way. There are several display modes, including pseudo graphs using ASCII or UTF characters and numerical representation of packets per second and bytes per second. bpfmon can take its data from an iptables rule counters instead from BPF (only on Linux). bpfmon depends on libyascreen for handling its output.
Bug#969927: ITP: yascreen -- Yet Another Screen Library (curses replacement for daemons and embedded apps)
Package: wnpp Severity: wishlist Owner: Boian Bonev X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: yascreen Version : 1.80 Upstream Author : Boian Bonev * URL : https://github.com/bbonev/yascreen * License : AGPL-3 Programming Lang: C Description : Yet Another Screen Library (curses replacement for daemons and embedded apps) Main features: - small footprint - does not have external dependencies - allows both internal and external event loop - allows stdin/stdout or external input/output (can work over socket) - supports basic set of telnet sequences, making it suitable for built-in terminal interfaces for daemons - supports a limited set of input keystroke sequences - fully unicode compatible (parts of this depend on wcwidth in libc) - supports utf8 verification of input - relies only on a limited subset of ansi/xterm ESC sequences, making it compatible with mostly all modern terminals (inspired by linenoise - https://github.com/antirez/linenoise) - there is no curses API and ancient terminal compatibility, hence less bloat - there is no autoconf - there is no need to have one - clean API with opaque private data, usable from C/C++ - easy cross compilation setup (by setting CC, AR, STRIP and RANLIB) This library is a dependency of vfu (already in Debian, using ncurses) and bpfmon (a monitoring tool that I plan to package for Debian).
Bug#847513: ITA: vfu -- A versatile text-based filemanager
retitle 847513 ITA: vfu -- A versatile text-based filemanager owner 847513 ! thanks
Bug#847513: ITA: vfu -- Versatile text-based filemanager
Package: wnpp Severity: normal Control: retitle 847513 ITA: vfu -- A versatile text-based filemanager Control: owner 847513 ! Control: thanks I intend to adopt the vfu package. Besides using it, I am well familiar with the code and have also contributed to the upstream project. The package description is: vfu is a nice filemanager using the ncurses library. It has many nice features: . * Fast one-key commands * Filename completion and wildcard expansion * Directory tree with sizes * File-type colorization * Archives support (TAR, TGZ, BZ2, and many more) * FTP support through archive-like interface * Internal text/hex file viewer and hex editor * Automount feature * Extensive user-defined external support/utils!
Bug#966225: ITA: vfu -- Versatile text-based filemanager
Package: wnpp Severity: normal retitle 847513 ITA: vfu -- A versatile text-based filemanager owner 847513 ! I intend to adopt the vfu package. Besides using it, I am well familiar with the code and have also contributed to the upstream project. The package description is: vfu is a nice filemanager using the ncurses library. It has many nice features: . * Fast one-key commands * Filename completion and wildcard expansion * Directory tree with sizes * File-type colorization * Archives support (TAR, TGZ, BZ2, and many more) * FTP support through archive-like interface * Internal text/hex file viewer and hex editor * Automount feature * Extensive user-defined external support/utils!
Bug#963612: Initial packaging done
Hi, Initial packaging is done and included in the upstream repo ( https://github.com/Tomas-M/iotop). The new iotop-c package is made to support alternatives; also alternatives patch is proposed to the Python package maintainer in order for both packages to be able to coexist in the same installation. Maybe I need to add Conflicts: iotop (version before alternatives) And maybe there is some other change that I am missing because I am not very well familiar with Debian's packaging system... With best regards, b.
Bug#963612: ITP: iotop-c -- simple top-like I/O monitor (implemented in C)
Package: wnpp Severity: wishlist Owner: Boian Bonev * Package name: iotop-c Version : 1.1 Upstream Author : Boian Bonev * URL : https://github.com/Tomas-M/iotop * License : GPL Programming Lang: C Description : simple top-like I/O monitor (implemented in C) iotop-c does for I/O usage what top(1) does for CPU usage. It watches I/O usage information output by the Linux kernel and displays a table of current I/O usage by processes on the system. It is handy for answering the question "Why is the disk churning so much?". iotop-c can only run under a Linux 2.6.20 or later kernel built with the CONFIG_TASKSTATS, CONFIG_TASK_DELAY_ACCT, CONFIG_TASK_IO_ACCOUNTING and CONFIG_VM_EVENT_COUNTERS build config options on. iotop-c is an alternative reimplementation of iotop in C, optimized for performance. Normally a monitoring tool intended to be used on a system under heavy stress should use the least additional resources as possible. The project was started by Vyacheslav Trushkin back in 2014 and now is maintained on GitHub by Tomas Matejicek and Boian Bonev. The effort to revive it, optimize it and backport most of the original iotop features started for an embedded target where installing Python was not an option. Performance comparisson between iotop-py, iotop-c v0.1 and iotop-c v1.1 on an idle system with a few processes only is roughly 6.3% / 1.7% / 1.3% respectively (smaller is better) while on a loaded one with many processes the difference will increase in a non-linear way. iotop-c needs a sponsor for inclusion in Debian.
