Bug#1064880: ITP: golang-github-mattn-go-sixel -- DRCS/Sixel Encoder/Decoder
Package: wnpp Severity: wishlist Owner: Robin Jarry * Package name: golang-github-mattn-go-sixel Version : 0.0.5-1 Upstream Author : mattn * URL : https://github.com/mattn/go-sixel * License : Expat Programming Lang: Go Description : DRCS/Sixel Encoder/Decoder go-sixel . DRCS Sixel Encoder/Decoder . (http://go-gyazo.appspot.com/75ec3ce96dfc573e.png) . Installation . $ go get github.com/mattn/go-sixel . You can install gosr (go sixel renderer), gosd (go sixel decoder) with following installation instruction. . $ go get github.com/mattn/go-sixel/cmd/gosr $ go get github.com/mattn/go-sixel/cmd/gosd . COMMAND | DESCRIPTION --+--- gosr| Image renderer gosd| Decoder to png goscat | Render cats gosgif | Render animation GIF gosl| Run SL . Usage . Encode . $ cat foo.png | gosr - . Decode . $ cat foo.drcs | gosd > foo.png . Use as library . img, _, _ := image.Decode(filename) sixel.NewEncoder(os.Stdout).Encode(img) . License . MIT . Author . Yasuhiro Matsumoto (a.k.a mattn) We need this as a dependency for vaxis.
Bug#1064881: ITP: golang-github-soniakeys-quant -- An interface for image color quantizers.
Package: wnpp Severity: wishlist Owner: Robin Jarry * Package name: golang-github-soniakeys-quant Version : 1.0.0-1 Upstream Author : Sonia Keys * URL : https://github.com/soniakeys/quant * License : Expat Programming Lang: Go Description : An interface for image color quantizers. Quant . Experiments with color quantizers . Implemented here are two rather simple quantizers and an (also simple) ditherer. The quantizers satisfy the draw.Quantizer interface of the standard library. The ditherer satisfies the draw.Drawer interface of the standard library. We need this as an indirect dependency for golang-sourcehut-rockorager-vaxis.
Bug#1064903: ITP: slm -- school library management
Package: wnpp Severity: wishlist Owner: Georges Khaznadar X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: slm Version : 0.4 Upstream Contact: Georges Khaznadar * URL : https://salsa.debian.org/georgesk/slm0 * License : GPL-3+ Programming Lang: Python, Javascript Description : school library management SLM stands for "school library management". It provides a web service useful for teams who lend school books to students. Here are some features: . - defining constants for the school, like name, logo, manager's name - creating a catalogue of available books - managing the inventory of books, each one identified by a unique barcode - importing lists of students, with their optional curricula - lending quickly a few books to every student, with the help of a barcode reader - managing the book returns, with the help of a barcode reader - replying to some request, like "whom is this book?", list of students which still owe books, list of students who have no book lended, and so on. - every web page comes with a contextual help I am using SML in my school's cooperative association to lend school books to students, and already packaged extra dependencies which were not part of Debian previously: python3-pylabels, node-html5-qrcode, python3-trml2pdf. This package's source is maintained in Salsa: https://salsa.debian.org/debian/slm
Bug#1064904: ITP: slm -- school library management
Package: wnpp Severity: wishlist Owner: Georges Khaznadar X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: slm Version : 0.4 Upstream Contact: Georges Khaznadar * URL : https://salsa.debian.org/georgesk/slm0 * License : GPL-3+ Programming Lang: Python, Javascript Description : school library management SLM stands for "school library management". It provides a web service useful for teams who lend school books to students. Here are some features: . - defining constants for the school, like name, logo, manager's name - creating a catalogue of available books - managing the inventory of books, each one identified by a unique barcode - importing lists of students, with their optional curricula - lending quickly a few books to every student, with the help of a barcode reader - managing the book returns, with the help of a barcode reader - replying to some request, like "whom is this book?", list of students which still owe books, list of students who have no book lended, and so on. - every web page comes with a contextual help I am using SML in my school's cooperative association to lend school books to students, and already packaged extra dependencies which were not part of Debian previously: python3-pylabels, node-html5-qrcode, python3-trml2pdf. This package's source is maintained in Salsa: https://salsa.debian.org/debian/slm
Bug#1064925: ITP: fail2ban-prometheus-exporter - collect and export Prometheus metrics on Fail2Ban
Package: wnpp Severity: wishlist Owner: Antoine Beaupré Reasoning: I need this! :) I could have written a mtail parser instead, but /fail2ban.actions\s+\[\d+\]:\s+\w+\s+\[(?P)\] (?PBan|Unban)\s+/ { fail2ban_action_count[$jail][$action]++ /fail2ban.filter\s+\[\d+\]:\s+\w+\s+\[(?P)\] (?PFound)\s+/ { fail2ban_filter_count[$jail][$action]++ * Package name: fail2ban-prometheus-exporter Version : 0.10.1-1 Upstream Author : hectorjsmith * URL : https://gitlab.com/hectorjsmith/fail2ban-prometheus-exporter * License : MIT Programming Lang: Go Description : collect and export Prometheus metrics on fail2ban This Prometheus exporter provides Prometheus (or OpenMetrics) metrics for the fail2ban package. It tracks the number of IPs currently blocked, matched, how long they are tracked, and keeps track of errors. It parses data from the fail2ban socket and can export metrics over a normal HTTP service or the text file collector. halfway through doing that, I wondered "surely someone must have fixed that already", and lo and behold. A mtail equivalent might be: # fail2ban log parser # # log lines: # # 2024-02-17 15:30:53,167 fail2ban.filter [578]: INFO [fraud-donation-spam] Found 185.92.25.49 - 2024-02-17 15:30:52 # 2024-02-17 15:30:53,542 fail2ban.actions[578]: NOTICE [fraud-donation-spam] Ban 185.92.25.49 # 2024-02-24 15:30:45,200 fail2ban.actions[578]: NOTICE [fraud-donation-spam] Unban 91.230.225.115 counter fail2ban_action_count by jail, action } } but is not quite as accurate, because it tracks bans/unbans independently, and doesn't reflect the actual state of the system properly. Autocrypt: addr=anar...@debian.org; prefer-encrypt=nopreference; keydata=xjMEZHZPzhYJKwYBBAHaRw8BAQdAWdVzOFRW6FYVpeVaDo3sC4aJ2kUW4ukdEZ36UJLAHd7NJUFudG9pbmUgQmVhdXByw6kgPGFuYXJjYXRAZGViaWFuLm9yZz7ClgQTFggAPhYhBLu2zUyY104TWKdSpgIpOm+k5TRzBQJkdmCVAhsDBQkB4TOABQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJEAIpOm+k5TRz+w8BANbRA+AMH0LN7trugVhaWe4wDpg94UVJloHPL+adJMK/AQCh39hyQXk3ivS2cK7xKZUgK0dBsbtJ2I2XBXvL9dS3Cc44BGR2UM4SCisGAQQBl1UBBQEBB0CYZha2IMY54WFXMG4S9/Smef54Pgon99LJ/hJ885p0ZAMBCAfCdwQYFggAIBYhBLu2zUyY104TWKdSpgIpOm+k5TRzBQJkdlDOAhsMAAoJEAIpOm+k5TRzBg0A+IbcsZhLx6FRIqBJCdfYMo7qovEo+vX0HZsUPRlq4HkBAIctCzmH3WyfOD/aUTeOF3tY+tIGUxxjQLGsNQZeGrQI Date: Tue, 27 Feb 2024 14:34:11 -0500 Message-ID: <87msrl3dn0@angela.anarc.at>
CRAN Package Matrix update and a possible transition or not
A couple of days ago, the (effective) Maintainer and rather active developer of the Matrix package Mikael Jagan (CC'ed) posted on the r-package-devel list (the primary list for R package development) that the upcoming change of Matrix 1.7-0, planned for March 11, will be _very midly disruptive_ but only to the very small subset of Matrix dependents that _actually use its headers_. See the full mail at [1]. The gory detail is that Matrix embeds and uses an advanced sparse matrix library (called SuiteSparse) which it updates, and the change in headers affects those (and only those!) who compile against these headers. Now, Matrix currently has 1333 packages at CRAN using it [2]. But he lists 15 (fifteen) of possibly breaking because these are the packages having a 'LinkingTo: Matrix' [3]. That 1.113 per cent. It is similar for us. Running a simple `apt-cache rdepends r-cran-matrix | wc -l` gets us 145 lines (including headers and meta packages). Call it 140 that a transition would cover. But among the 15 affected only five are in Debian: irlbar-cran-irlba lme4 r-cran-lme4 OpenMx r-cran-openmx TMP r-cran-tmp bcSeqr-bioc-bcseq One of these is mine (lme4), I can easily produce a sequenced update. I suggested we deal with the other _four packages_ by standard bug reports and NMUs as needed instead of forcing likely 140 packages through a transition. Note that is in fact truly different from the past two hickups with Matrix transition which happened at the R-only level of caching elements of its OO resolution and whatnot hence affecting more package. This time it really is compilation, and packages NOT touching the SuiteSparse headers (ie roughly 135 or so of the 140 Debian packages using Matrix) will not be affected. That said, I of course defer to the release team. If the feeling is 'eff this, transition it is' that is what we do. Whether I think is overkill or not is moot. Feel free to CC me as I am not longer a regular on debian-devel. Cheers, Dirk [1] https://stat.ethz.ch/pipermail/r-package-devel/2024q1/010463.html [2] In R: > db <- tools::CRAN_package_db() > matrixrevdep <- tools::package_dependencies("Matrix", reverse=TRUE, db=db)[[1]] > length(matrixrevdep)# the vector 'matrixrevdep' list all [1] 1333 > [3] LinkingTo:, despite its name, is the directive to include the package C headers in the compilation. The 'db' object above allows to us to subset which of the 1333 packages using Matrix also have a LinkingTo -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org