Bug#1064880: ITP: golang-github-mattn-go-sixel -- DRCS/Sixel Encoder/Decoder

2024-02-27 Thread Robin Jarry
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.

2024-02-27 Thread Robin Jarry
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

2024-02-27 Thread Georges Khaznadar (debian)

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

2024-02-27 Thread Georges Khaznadar
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

2024-02-27 Thread Antoine Beaupré
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

2024-02-27 Thread Dirk Eddelbuettel


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