Bug#1070077: ships files directly in /usr/onionprobe

[Antoine Beaupre]

Package: onionprobe
Version: 1.0.0+ds-2.1+deb12u1
Severity: serious

The Debian package shipped in bookworm right now changed the path to
the examples/ directory. It used to be:

/usr/lib/python3/dist-packages/onionprobe/examples/tpo.py

 and now seems to be:

/usr/onionprobe/examples/tpo.py

Apart from the gratuitous change, this seems to be a violation of the
FHS policy, packages shouldn't ship their own stuff directly under
/usr like this...

I haven't checked in unstable to see if this is fixed.

A.

-- System Information:
Debian Release: 12.5
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'experimental'), (1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.13+bpo-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages onionprobe depends on:
ii  adduser3.134
ii  init-system-helpers1.65.2
ii  python33.11.2-1+b1
ii  python3-cryptography   38.0.4-3
pn  python3-prometheus-client  
ii  python3-requests   2.28.1+dfsg-1
ii  python3-socks  1.7.1+dfsg-1
ii  python3-stem   1.8.1-2.1
ii  python3-yaml   6.0-3+b2
ii  tor0.4.7.16-1

onionprobe recommends no packages.

Versions of packages onionprobe suggests:
pn  prometheus  

Bug#1068764: RFP: nginx-module-vts -- Nginx virtual host traffic status module

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: pkg-nginx-maintain...@alioth-lists.debian.net

* Package name: nginx-module-vts
  Version : 0.2.2
  Upstream Contact: YoungJoo.Kim 
* URL : https://github.com/vozlt/nginx-module-vts
* License : BSD-2
  Programming Lang: C
  Description : Nginx virtual host traffic status module

This is an Nginx module that provides access to virtual host status
information. It contains the current status such as servers,
upstreams, caches. This is similar to the live activity monitoring of
nginx plus. The built-in html is also taken from the demo page of old
version.



This module provides more in-depth stats than the ones provided by the
built-in statistics module, crippled by its opencore/non-free
counterpart only available in nginx plus.

There's already another nginx exporter in Debian, but it proxies (and
rewrites) the requests to the builtin stats module, with limited
effect. It cannot, for example, count bytes or examine hit ratios, nor
per-vhost usage stats.

I'm not sure I'm going to package this myself, and I don't know if it
should be shipped alongside nginx-full: it seems to me it would be
better as its own standalone module, would love to hear thoughts from
the nginx maintainers as well..

I would definitely need this at torproject.org. We're using nginx more
and more, and the stats we're able to extract from the components
available in debian pale in comparison with what we have in the apache
exporter, for example.

Bug#1068527: test suite failures

[Antoine Beaupre]

Package: elpa-rg
Version: 2.3.0-1
Severity: normal

The test suite currently fails on this package, and those failures
have been ignored in debian/rules to get the package to build at all.

The package *works*: i've been using it as is, in bookworm, for months
now. It *might* actually be broken in unstable, but I doubt it: i
suspect this is more a test harness problem than anything else.

So I'm filing this issue to remember about this problem and possibly
see if we can collaborate with upstream to fix it.


-- System Information:
Debian Release: 12.5
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'experimental'), (1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.13+bpo-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages elpa-rg depends on:
ii  dh-elpa-helper  2.0.16
ii  elpa-wgrep  3.0.0-1
ii  emacsen-common  3.0.5
ii  ripgrep 13.0.0-4+b2

Versions of packages elpa-rg recommends:
ii  emacs  1:28.2+1-15
ii  emacs-gtk [emacs]  1:28.2+1-15

elpa-rg suggests no packages.

-- no debconf information

Bug#1068488: RFP: iterable-io -- Adapt generators and other iterables to a file-like interface

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org

* Package name: iterable-io
  Version : 1.0.0
  Upstream Contact: Carey Metcalfe 
* URL : https://pypi.org/project/iterable-io/
* License : LGPLv3
  Programming Lang: Python
  Description : Adapt generators and other iterables to a file-like 
interface

iterable-io is a small Python library that provides an adapter so that
it's possible to read from iterable objects in the same way as
file-like objects.

It is primarily useful as "glue" between two incompatible
interfaces. As an example, in the case where one interface expects a
file-like object to call .read() on, and the other only provides a
generator of bytes.

One way to solve this issue would be to write all the bytes in the
generator to a temporary file, then provide that file instead, but if
the generator produces a large amount of data then this is both slow
to start, and resource-intensive.

This library allows streaming data between these two incompatible
interfaces so as data is requested by .read(), it's pulled from the
iterable. This keeps resource usage low and removes the startup delay.



this is a new dependency introduced by magic-wormhole 0.14

Bug#1068486: vendors versioneer.py

[Antoine Beaupre]

Source: magic-wormhole-mailbox-server
Version: 0.4.1-2
Severity: normal

I hadn't noticed this before (or didn't care) but this package vendors
versioneer.py. This cause at least one RC / FTBFS bug (#1058173),
which has been fixed upstream, but not part of a release.

We should really repack the source to avoid this.


-- System Information:
Debian Release: 12.5
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'experimental'), (1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.13+bpo-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1068342: RFP: valkey -- Persistent key-value database with network interface (Redis fork)

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: Guillem Jover , "Chris Lamb" 


* Package name: valkey
  Version : 7.2.4
  Upstream Contact: https://github.com/valkey-io
* URL : https://github.com/valkey-io/valkey
* License : BSD-3
  Programming Lang: C
  Description : Persistent key-value database with network interface (Redis 
fork)

Valkey is a high-performance data structure server that primarily
serves key/value workloads. It supports a wide range of native
structures and an extensible plugin system for adding new data
structures and access patterns.



"This project was forked from the open source Redis project right
before the transition to their new source available licenses."

Valkey is one of many Redis forks out there, but it seems to me to be
the most promising one, at least after reading this LWN article:

https://lwn.net/SubscriberLink/966631/4b4104ce85bf92f7/

For me, the plus sides:

 1. unchanged licence (while redict changed to LGPL)

 2. has the backing of the Linux foundation

 3. exact same feature set as Redis before the fork (while KeyDB is
lagging behind)

We use Redis at the Tor Project internnally, and we're looking for a
smooth transition, drop-in replacement.

Bug#1065578: ITP: python-sqlite-migrate -- A simple database migration system for SQLite, based on sqlite-utils

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-sqlite-migrate
  Version : 0.1b0
  Upstream Contact: Simon Willison 
* URL : https://github.com/simonw/sqlite-migrate
* License : Apache-2.0
  Programming Lang: Python
  Description : A simple database migration system for SQLite, based on 
sqlite-utils

Python library to operate changes on SQLite database, based on
migration files.



This is a dependency of the LLM package (#1065572).

Bug#1065576: ITP: python-ulid -- Universally unique lexicographically sortable identifier (Python library)

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-ulid
  Version : 2.2.0
  Upstream Contact: Martin Domke 
* URL : https://python-ulid.rtfd.io/
* License : MIT
  Programming Lang: Python
  Description : Universally unique lexicographically sortable identifier 
(Python library)

A ULID is a universally unique lexicographically sortable
identifier. It is:

- 128-bit compatible with UUID
- 1.21e+24 unique ULIDs per millisecond
- Lexicographically sortable!
- Canonically encoded as a 26 character string, as opposed to the 36 character 
UUID
- Uses Crockford's base32 for better efficiency and readability (5 bits per 
character)
- Case insensitive
- No special characters (URL safe)



This is a dependency for the llm package (#1065572). We have another
ULID implementation in Debian (golang-github-oklog-ulid-dev) but it's
not sufficient for the LLM package, which expects the Python library.

This is going to be packaged in the Python team.

Bug#1065572: ITP: llm -- Access large language models from the command-line

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, 
debian...@lists.debian.org

* Package name: llm
  Version : 0.13.1
  Upstream Contact: Simon Willison 
* URL : https://llm.datasette.io/
* License : Apache-2.0
  Programming Lang: Python
  Description : CLI utility and Python library for interacting
  with Large Language Models

A CLI utility and Python library for interacting with Large Language
Models, both via remote APIs and models that can be installed and run
on your own machine.

Run prompts from the command-line, store the results in SQLite,
generate embeddings and more.



So there has been some discussions about packaging LLM things in
Debian, and this is my stab at opening a discussion about *what*
exactly, we *can* package, right now.

LLM is a (possibly poorly named) package that allows users to interact
with various language models. Its primary target is obviously the
OpenAI API (it's the example in the "Quick Start"), but it also
supports local models like Llama 2, Ollama, and MLC, and other online
models like Claude, GEmini and Mistral.

I *think* this belongs in contrib, because it *mostly* relies on
non-free software (and services) to do its thing, but I'd be happy to
move that around.

I need this because I was using GPT plus for a while and now I'm
switching to the API to cut down on costs.

Bug#1064253: new upstream release

[Antoine Beaupre]

Source: git-annex
Version: 10.20230126-3
Severity: wishlist

Upstream is now at 10.20240129 and we seem to be lagging behind a
little bit, is there a plan to sync up before trixie?

thanks!

-- System Information:
Debian Release: 12.5
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'experimental'), (1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#864001: git-annex: Possible SHA-1 vulnerability: fixed in newer releases

[Antoine Beaupre]

Source: git-annex
Followup-For: Bug #864001

Control: fixed -1 7.20190129-3

Seems to me this should be closed; the fixed version has shipped in
Debian eons ago.


-- System Information:
Debian Release: 12.5
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'experimental'), (1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#1063912: ITP: pass-extension-update -- pass extension that provides an easy flow for updating passwords

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: pass-extension-update
  Version : 2.1
  Upstream Contact: Alex roddhjav
* URL : https://github.com/roddhjav/pass-update
* License : GPL-3
  Programming Lang: Shell
  Description : pass extension that provides an easy flow for updating 
passwords

pass update extends the pass utility with an update command providing
an easy flow for updating passwords. It supports path, directory and
wildcard update. Moreover, you can select how to update your passwords
by automatically generating new passwords or manually setting your
own.

pass update assumes that the first line of the password file is the
password and so only ever updates the first line unless the
--multiline option is specified.

By default, pass update prints the old password and waits for the user
before generating a new one. This behaviour can be changed using the
provided options.



I need something like this for work so I'll take a look at how
reasonable this is. There's already a Debian package in the upstream
source too.$

Bug#1061772: RFP: jujutsu -- Git-compatible VCS that is both simple and powerful

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-r...@lists.debian.org

* Package name: jujutsu
  Version : 0.13.0
  Upstream Contact: Martin von Zweigbergk 
* URL : https://martinvonz.github.io/jj/
* License : Apache-2.0
  Programming Lang: Rust
  Description : Git-compatible VCS that is both simple and powerful

Jujutsu is a powerful version control system for software
projects. You use it to get a copy of your code, track changes to the
code, and finally publish those changes for others to see and use. It
is designed from the ground up to be easy to use—whether you're new or
experienced, working on brand new projects alone, or large scale
software projects with large histories and teams.

Jujutsu is unlike most other systems, because internally it abstracts
the user interface and version control algorithms from the storage
systems used to serve your content. This allows it to serve as a VCS
with many possible physical backends, that may have their own data or
networking models—like Mercurial or Breezy, or hybrid systems like
Google's cloud-based design, Piper/CitC.

Today, we use Git repositories as a storage layer to serve and track
content, making it compatible with many of your favorite Git-based
tools, right now! All core developers use Jujutsu to develop Jujutsu,
right here on GitHub. But it should hopefully work with your favorite
Git forges, too.

We combine many distinct design choices and concepts from other
version control systems into a single tool. Some of those sources of
inspiration include:

 * Git: We make an effort to be fast—with a snappy UX, efficient
   algorithms, correct data structures, and good-old-fashioned
   attention to detail. The default storage backend uses Git
   repositories for "physical storage", for wide interoperability and
   ease of onboarding.

 * Mercurial & Sapling: There are many Mercurial-inspired features,
   such as the revset language to select commits. There is no explicit
   index or staging area. Branches are "anonymous" like Mercurial, so
   you don't need to make up a name for each small change. Primitives
   for rewriting history are powerful and simple. Formatting output is
   done with a robust template language that can be configured by the
   user.

 * Pijul & Darcs: Jujutsu keeps track of conflicts as first-class
   objects in its model; they are first-class in the same way commits
   are, while alternatives like Git simply think of conflicts as
   textual diffs. While not as rigorous as systems like Darcs and
   Pijul (which are based on a formalized theory of patches, as
   opposed to snapshots), the effect is that many forms of conflict
   resolution can be performed and propagated automatically.

And it adds several innovative, useful features of its own:

 * Working-copy-as-a-commit: Changes to files are recorded
   automatically as normal commits, and amended on every subsequent
   change. This "snapshot" design simplifies the user-facing data
   model (commits are the only visible object), simplifies internal
   algorithms, and completely subsumes features like Git's stashes or
   the index/staging-area.

 * Operation log & undo: Jujutsu records every operation that is
   performed on the repository, from commits, to pulls, to
   pushes. This makes debugging problems like "what just happened?" or
   "how did I end up here?" easier, especially when you're helping
   your coworker answer those questions about their repository! And
   because everything is recorded, you can undo that mistake you just
   made with ease. Version control has finally entered the 1960s!

 * Automatic rebase and conflict resolution: When you modify a commit,
   every descendent is automatically rebased on top of the
   freshly-modified one. This makes "patch-based" workflows a
   breeze. If you resolve a conflict in a commit, the resolution of
   that conflict is also propagated through descendants as well. In
   effect, this is a completely transparent version of git rebase
   --update-refs combined with git rerere, supported by design.

[!WARNING] The following features are available for use, but experimental; they 
may have bugs, backwards incompatible storage changes, and user-interface 
changes!

 * Safe, concurrent replication: Have you ever wanted to store your
   version controlled repositories inside a Dropbox folder? Or
   continuously backup repositories to S3? No? Well, now you can!

   The fundamental problem with using filesystems like Dropbox and
   backup tools like rsync on your typical Git/Mercurial repositories
   is that that they rely on local filesystem operations being atomic,
   serialized, and non-concurrent with respect to other reads and
   writes—which is not true when operating on distributed file
   systems, or when operations like concurrent file copies (for
   backup) happen while lock files are being held.

   Jujutsu is instead designed to be safe under 

Bug#1061119: RFP: prometheus-script-exporter -- Prometheus exporter to execute scripts and collect metrics from the output or the exit status

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: pkg-go-maintain...@lists.alioth.debian.org

* Package name: prometheus-script-exporter
  Version : 2.17.0
  Upstream Contact: https://github.com/ricoberger
* URL : https://github.com/ricoberger/script_exporter
* License : MIT
  Programming Lang: Golang
  Description : Prometheus exporter to execute scripts and collect metrics 
from the output or the exit status

The script_exporter is a Prometheus exporter to execute scripts and
collect metrics from the output or the exit status. The scripts to be
executed are defined via a configuration file. In the configuration
file several scripts can be specified. The script which should be
executed is indicated by a parameter in the scrap configuration. The
output of the script is captured and is provided for Prometheus. Even
if the script does not produce any output, the exit status and the
duration of the execution are provided.



I often use the node exporter textfile collector to do this kind of
thing:

exporter | sponge /var/lib/prometheus/node_exporter/exporter.prom

... but i often have issues where i don't quite know *when* to run the
script. It would be nice to run the script when prometheus scrapes...

I don't have time to package this right now.

Bug#1058702: pius fails completely on bookworm and up

[Antoine Beaupre]

Package: pius
Version: 3.0.0-5
Severity: grave

I've been trying to use pius to sign things, and it's completely
failing me:

anarcat@angela:~$ pius -s BBB6CD4C98D74E1358A752A602293A6FA4E53473  
D477040C70C2156A5C298549BB7E9101495E6BF7
Welcome to PIUS, the PGP Individual UID Signer.

Usage: pius [options] -s   [ ...]
   pius [options] -A -r  -s 

pius: error: GnuPG binary not found at /usr/bin/gpg2.

gpg2 hasn't been around for a long time. but maybe we can work around
this with:

anarcat@angela:~[2]$ pius -b /usr/bin/gpg -s 
BBB6CD4C98D74E1358A752A602293A6FA4E53473  
D477040C70C2156A5C298549BB7E9101495E6BF7
Welcome to PIUS, the PGP Individual UID Signer.

Usage: pius [options] -s   [ ...]
   pius [options] -A -r  -s 

pius: error: Keyring /home/anarcat/.gnupg/pubring.gpg doesn't exist

Nope! That doesn't work either! I have not dared to use the --keyring
argument to correct `.gnupg/pubring.kbx` keyring, for fear of
corruption, but clearly something is wrong here.

-- System Information:
Debian Release: 12.4
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'experimental'), (1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pius depends on:
ii  gnupg2.2.40-1.1
ii  python3  3.11.2-1+b1

pius recommends no packages.

pius suggests no packages.

-- no debconf information

Bug#1057152: RFP: sacad -- Smart Automatic Cover Art Downloader

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org

* Package name: sacad
  Version : 2.7.5
  Upstream Contact: https://github.com/desbma
* URL : https://github.com/desbma/sacad/
* License : MPL-2
  Programming Lang: Python
  Description : Smart Automatic Cover Art Downloader

SACAD is a multi platform command line tool to download album covers
without manual intervention, ideal for integration in scripts, audio
players, etc.

SACAD also provides a second command line tool, sacad_r, to scan a
music library, read metadata from audio tags, and download missing
covers automatically, optionally embedding the image into audio audio
files.  Features

 * Can target specific image size, and find results for high resolution covers
 * Support JPEG and PNG formats
 * Customizable output: save image along with the audio files / in a different 
directory named by artist/album / embed cover in audio files...
 * Currently support the following cover sources:
   * Amazon CD (.com, .ca, .cn, .fr, .de, .co.jp and .co.uk variants)
   * Amazon digital music
   * CoverLib (site is dead)
   * Deezer
   * Discogs
   * Google Images (removed, too unreliable)
   * Last.fm
   * Itunes
 * Smart sorting algorithm to select THE best cover for a given query,
   using several factors: source reliability, image format, image
   size, image similarity with reference cover, etc.
 * Automatically crunch images with optipng, oxipng or jpegoptim (can
   save 30% of filesize without any loss of quality, great for
   portable players)
 * Cache search results locally for faster future search
 * Do everything to avoid getting blocked by the sources: hide
   user-agent and automatically take care of rate limiting
 * Automatically convert/resize image if needed
 * Multiplatform (Windows/Mac/Linux)

SACAD is designed to be robust and be executed in batch of thousands
of queries:

 * HTML parsing is done without regex but with the LXML library, which
   is faster, and more robust to page changes

 * When the size of an image reported by a source is not reliable
   (ie. Google Images), automatically download the first KB of the
   file to get its real size from the file header

 * Process several queries simultaneously (using asyncio), to speed up
   processing

 * Automatically reuse TCP connections (HTTP Keep-Alive), for better
   network performance

 * Automatically retry failed HTTP requests

 * Music library scan supports all common audio formats (MP3, AAC,
   Vorbis, FLAC..)

 * Cover sources page or API changes are quickly detected, thanks to
   high test coverage, and SACAD is quickly updated accordingly



There are no tools, as far as I know, to do this in Debian. A friend
used this to great effect to cleanup their local music library, while
in the meantime I did this by hand to much lesser effect...

Bug#1057118: RFP: anyrun -- A wayland native, highly customizable runner.

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-r...@lists.debian.org

* Package name: anyrun
  Version : No releases published
  Upstream Contact: https://github.com/Kirottu
* URL : https://github.com/Kirottu/anyrun
* License : GPL-3
  Programming Lang: Rust
  Description : A wayland native, highly customizable runner.

A wayland native krunner-like runner, made with customizability in
mind.

Features

Style customizability with GTK+ CSS
Can do basically anything
As long as it can work with input and selection
Hence the name anyrun
Easy to make plugins
You only need 4 functions!
See Rink for a simple example. More info in the documentation of the 
anyrun-plugin crate.
Responsive
Asynchronous running of plugin functions
Wayland native
GTK layer shell for overlaying the window
data-control for managing the clipboard



There's a bunch of runners in Debian, but none of them are written in
Rust. I find this one particularly interesting because of the
integration with Rink (which is *also* not packaged in Debian but very
well could):

https://rinkcalc.app/

Bug#1057067: new upstream release (1.65)

[Antoine Beaupre]

Source: rclone
Severity: critical

Debian is somewhat lagging behind upstream. Unstable currently has
1.60.1 (2022-11-17, uploaded to unstable on 2022-12-13) while upstream
is at 1.65.0 (released 2022-11-26).

It looks like upstream does a release roughly every two months, is
there a plan to follow that cadence here or what's the plan for
following upstream?

Open to help? :)

I'm asking because there's a bunch of bugfixes and major changes,
since 1.60, particularly new providers, multi-threaded transfers,
several improvements to the S3 backend (like support for empty
directories), and so on...

-- System Information:
Debian Release: 12.2
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'experimental'), (1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#1056358: bookworm-pu: package needrestart/3.6-4+deb12u1

[Antoine Beaupre]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: needrest...@packages.debian.org, pmatth...@debian.org
Control: affects -1 + src:needrestart

[ Reason ]
needrestart, starting with bookworm, supports more microcode checks
than before. In particular, it now checks AMD CPUs.

The amd64-microcode package seem to ship *less* firmware files than
its Intel counterpart, which leads to *many* machines (half a dozen)
in our fleet to suddenly start warning us about "UNKNOWN" firmware
status.

[ Impact ]
Spurious warnings lead to alert fatigue and consequently untimely
security upgrades, which is the main reason why I'm considering this
serious enough to warrant a stable update.

[ Tests ]
The provided patches were tested in production on a fleet (~50
machines) of Debian bookworm servers on torproject.org.

[ Risks ]
Code is relatively simple. There's a risk that operators who did *not*
install the amd64-microcode package will not get a warning, but that's
consider an operator error, and out of scope for this.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [~] the issue is verified as fixed in unstable

[ Changes ]
There are three patches here:

1. 05-fix-AMD-ucode-checking-in-non-debug-mode.patch - fixes a bug
   where AMD microcode checks would fail unless -v is passed
2. 06-uCode-fix-uninitialized-value-in-logging-of-processo.patch - fix
   uninitialized variable error, required for the other patches to
   work
3. 07-mark-unavailable-firmware-as-CURRENT.patch - do not mark
   unavailable firmware as "UNKNOWN"

The first and second patches have shipped into unstable with the -6
release, the last patch is pending.

[ Other info ]

anarcat@angela:dist$ debdiff needrestart_3.6-4.dsc 
needrestart_3.6-4+deb12u1.dsc| diffstat 
dpkg-source: warning: extracting unsigned source package 
(/home/anarcat/dist/needrestart_3.6-4+deb12u1.dsc)
 changelog |6 
 patches/05-fix-AMD-ucode-checking-in-non-debug-mode.patch |   33 
+
 patches/06-uCode-fix-uninitialized-value-in-logging-of-processo.patch |   30 

 patches/07-mark-unavailable-firmware-as-CURRENT.patch |   61 
++
 patches/series|3 
 5 files changed, 133 insertions(+)


We might also want to consider updating to the unstable version
directly, as the patch is relatively similar, in fact it's currently
*smaller* because it's lacking the third patch here:

anarcat@angela:dist[1]$ debdiff needrestart_3.6-4.dsc needrestart_3.6-6.dsc | 
diffstat 
 NEWS |8 --
 changelog|   26 
+++
 control  |1 
 patches/05-fix-AMD-ucode-checking-in-non-debug-mode.diff |   33 
++
 patches/06-uCode-fix-uninitialized-value-in-logging-of-processo.diff |   30 
+
 patches/series   |2 
 6 files changed, 91 insertions(+), 9 deletions(-)

Bug#1056355: puppet-agent should depend more strongly on core modules

[Antoine Beaupre]

Package: puppet-agent
Version: 7.23.0-1
Severity: important
X-Debbugs-Cc: b...@bastelfreak.de

bastelfreak (in cc) explicitly requested that our Debian packages
follow the upstream convention of shipping the vendored "core" modules
with puppet-agent. Those are augeas, cron, host, mailalias, mount,
selinux, (etc?). They have been taken out of Puppet, but are actually
*vendored* in the upstream source and shipped with Puppet AIO
packages.

Right now, our puppet-agent debian package merely "Suggests"
those. (The puppetserver package, surprisingly, "Recommends" them,
even though it Depends: puppet-agent. My feeling is that it should
delegate that decision to puppet-agent, but that's another issue
altogether.)

This was discussed before: in #1050337, the puppetserver was noted as
missing a Recommends: *mailalias-core. And in #1054664, someone
installed the puppet-module-puppetlabs-cron-core package and *still*
couldn't use the Cron resource (which I personnally find surprising,
but probably worth investigating on its own).

Overall, I agree with bastelfreak here: upstream split out those
resources in their own git repos to make development easier, but
didn't actually *mean* to remove them completely from Puppet. They are
still shipped upstream, and we should still ship them as well.

That we package them as separate packages is probably fine (as long as
it works!). But I say we should Depend on them.

An alternative would be to Recommends: the packages, but I think
that's not strong enough.

The downside of Depends is it makes it Really Hard to *not* install
those *-core modules, but I don't see how that use case would be
important in the first place.

Opinions?


-- System Information:
Debian Release: 12.2
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'experimental'), (1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages puppet-agent depends on:
ii  adduser3.134
ii  debconf [debconf-2.0]  1.5.82
ii  facter 4.3.0-2
ii  hiera  3.10.0-1
ii  init-system-helpers1.65.2
ii  ruby   1:3.1
ii  ruby-augeas1:0.5.0+gem-1
ii  ruby-concurrent1.1.6+dfsg-5
ii  ruby-deep-merge1.1.1-2
ii  ruby-semantic-puppet   1.0.4-1
ii  ruby-shadow2.5.1-1
ii  ruby-sorted-set1.0.3-3

Versions of packages puppet-agent recommends:
ii  augeas-tools   1.14.0-1
ii  debconf-utils  1.5.82
ii  lsb-release12.0-1
ii  ruby-selinux   3.4-1+b6

Versions of packages puppet-agent suggests:
pn  hiera-eyaml
pn  puppet-module-puppetlabs-augeas-core   
pn  puppet-module-puppetlabs-cron-core 
pn  puppet-module-puppetlabs-host-core 
pn  puppet-module-puppetlabs-mount-core
pn  puppet-module-puppetlabs-selinux-core  
pn  puppet-module-puppetlabs-sshkeys-core  
pn  puppet-module-puppetlabs-stdlib
ii  ruby-hocon 1.3.1-2
pn  ruby-msgpack   

-- Configuration Files:
/etc/default/puppet changed [not included]
/etc/puppet/puppet.conf changed [not included]

-- debconf information excluded

Bug#1056319: RFP: avis-imgv -- Fast and Configurable Rust Image Viewer

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-r...@lists.debian.org

* Package name: avis-imgv
  Version : No releases published
  Upstream Contact: https://github.com/hats-np
* URL : https://github.com/hats-np/avis-imgv
* License : GPL-3
  Programming Lang: Rust
  Description : Fast and Configurable Rust Image Viewer

avis-imgv is a fast, configurable and color managed image viewer built
with Rust and egui. My goal was for it to be fast and to be able to
adapt to any kind of hardware power through user configuration.

As of now it's only been tested in Linux, but I don't see why it
wouldn't work in Windows/macOS. Configuration and cache directories
are obtained through the directories crate which is platform-agnostic.



"I" in the above is not me, but the upstream author.

I'm always on the hunt for a good image viewer. I am particularly
interested in software that has the capability of showing multiple
images at once, and recursing into subdirectories.

This one is also one of the (currently) rare image viewers written in
a safe language (Rust), which I find particularly relevant given the
attack surface of image rendering in general.

Bug#1055294: RFP: bitlbee-discord -- Bitlbee plugin for Discord

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: jel...@debian.org, wil...@gaast.net

* Package name: bitlbee-discord
  Version : 0.4.3
  Upstream Contact: https://github.com/sm00th
* URL : https://github.com/sm00th/bitlbee-discord
* License : GPL-2
  Programming Lang: C
  Description : Bitlbee plugin for Discord

Plugin to bridges IRC and Discord through the bitlbee server.



There's already support for discord through the bitlbee-libpurple
plugin, but this one is a little more straightforward and doesn't
require pulling in the entire libpurple attack surface...

Bug#1055284: RFP: harpoon -- CLI tool for open source and threat intelligence

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: harpoon
  Version : no releases published 
https://github.com/Te-k/harpoon/issues/194
  Upstream Contact: https://github.com/Te-k
* URL : https://github.com/Te-k/harpoon
* License : GPL-3
  Programming Lang: Python
  Description : CLI tool for open source and threat intelligence

harpoon doesn't have a long description upstream, but it's a recon
tool with various backends. i personnally want to use it to answer
questions like "who is this set of IPs doing nasty things to my
server?" looking for answers like reverse DNS, geolocation, ASN,
shodan information and so on.

harpoon can do a lot more though, by tapping into various data sources
like virustotal, haveibeenpwned, and many more.

i do not believe there is an equivalent in Debian. maybe metasploit
could be crafted to do *some* of this, but there's so many modules in
metasploit nowadays that it's hard to tell. there *is* a shodan
module, for example and there's a tool to do reverse DNS lookups, but
no ASN lookup I could find.

harpoon is designed with recon in mind specifically. there's even a
separate toolset called harpoontools that give commandline tools to a
basic set of tools:

https://github.com/Te-k/harpoontools

Just that basically answers most of my needs!

Would be maintained under the python team, I suppose.

Code is not the cleanest (and due for a refactor) but has unit tests
and written by a friend of a friend.

Bug#1055115: bookworm-pu: package prometheus-node-exporter-collectors/0.0~git20230203.6f710f8-1

[Antoine Beaupre]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: prometheus-node-exporter-collect...@packages.debian.org
Control: affects -1 + src:prometheus-node-exporter-collectors

[ Reason ]
Since the bookworm upgrade, all hosts with the
prometheus-node-exporter-collectors package install repeatedly hit the
mirrors with spurious apt-update runs. The Debian package
systemd.timer(1) schedule is once on boot and then every 15 minutes
after, which imposes a tremendous load on the mirror system.

It also happens to lock the apt status files which can in turn cause
deadlocks with other programs. There seems to be an (unrelated?)
regression in apt where some (python?) apt program can hang this way
indefinitely. That's tracked separately, e.g.

https://bugs.launchpad.net/ubuntu/+source/apt/+bug/2003851

[ Impact ]
The mirror networks are going to be badly negatively affected by
this. This actually doesn't seem to have been a problem so far,
possibly because deb.debian.org is absorbing everything we can throw
at it and no one is looking at Fastly (or Amazon?), but I suspect this
could become a problem as Prometheus adoption widens.

This also can mean some security upgrades don't get deployed, as the
apt update lockfile gets hung.

[ Tests ]
There's no autopkgtest on this package, but the patches provided here
have been tested in production in about 90 servers for torproject.org
over a few weeks now, fixing the diagnosed issue.

https://gitlab.torproject.org/tpo/tpa/team/-/issues/41355 is our
tracking ticket documenting this.

[ Risks ]
Code is *relatively* simple. It diverges from upstream a little now
because upstream did a little reactoring post bookworm and I didn't
want to make the patch bigger than it absolutely needs to be.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
There are three individual patches, cherry-picked and backported from
upstream. The first one simply stops running apt-update.

The second and third patch add a new metric which keeps track of the
last update timestamp on the apt metadata.

That is important: previously, the script was running apt-update so we
could be pretty sure it was running automatically. But by making this
change, we're *not* running apt-update automatically and assume users
have properly setup something *else* that does.

This was the behaviour in bullseye, for the record, but it's possible
that some users *assume* the wrong (new) behavior was the correct one
and installed the package not knowing they need to deploy their own
APT::Periodic thing.
diff -Nru 
prometheus-node-exporter-collectors-0.0~git20230203.6f710f8/debian/changelog 
prometheus-node-exporter-collectors-0.0~git20230203.6f710f8/debian/changelog
--- 
prometheus-node-exporter-collectors-0.0~git20230203.6f710f8/debian/changelog
2023-02-02 23:57:45.0 -0500
+++ 
prometheus-node-exporter-collectors-0.0~git20230203.6f710f8/debian/changelog
2023-10-31 13:57:52.0 -0400
@@ -1,3 +1,10 @@
+prometheus-node-exporter-collectors (0.0~git20230203.6f710f8-1+deb12u1) 
bookworm; urgency=medium
+
+  * Team upload
+  * Fix deadlock with other apt update runs (Closes: #1028212)
+
+ -- Antoine Beaupré   Tue, 31 Oct 2023 13:57:52 -0400
+
 prometheus-node-exporter-collectors (0.0~git20230203.6f710f8-1) unstable; 
urgency=medium
 
   * New upstream snapshot (Closes: #1030058)
diff -Nru 
prometheus-node-exporter-collectors-0.0~git20230203.6f710f8/debian/patches/0001-do-not-run-apt-update-or-simulate-apt-dist-upgrade.patch
 
prometheus-node-exporter-collectors-0.0~git20230203.6f710f8/debian/patches/0001-do-not-run-apt-update-or-simulate-apt-dist-upgrade.patch
--- 
prometheus-node-exporter-collectors-0.0~git20230203.6f710f8/debian/patches/0001-do-not-run-apt-update-or-simulate-apt-dist-upgrade.patch
1969-12-31 19:00:00.0 -0500
+++ 
prometheus-node-exporter-collectors-0.0~git20230203.6f710f8/debian/patches/0001-do-not-run-apt-update-or-simulate-apt-dist-upgrade.patch
2023-10-31 13:57:52.0 -0400
@@ -0,0 +1,65 @@
+From 28c179ddfd3d7e0f5bc49b93f924f0dffba5b71d Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
+Date: Fri, 13 Oct 2023 12:29:48 -0400
+Subject: [PATCH] do not run apt update or simulate apt dist-upgrade
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+This is causing all sorts of problems. The first of which is that
+we're hitting our poor mirrors every time the script is ran, which, in
+the Debian package configuration, is *every 15 minutes* (!!).
+
+The second is that this locks the cache and makes this script
+needlessly stumble upon a possible regression in APT from Debian
+bookworm and Ubuntu 22.06:
+

Bug#1054447: RFP: soft-serve -- mighty, self-hostable Git server for the command line

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian...@lists.debian.org

* Package name: soft-serve
  Version : 0.6.2
  Upstream Contact: https://github.com/charmbracelet
* URL : https://github.com/charmbracelet/soft-serve
* License : MIT
  Programming Lang: Golang
  Description : mighty, self-hostable Git server for the command line

A tasty, self-hostable Git server for the command line.

Features:

 * Easy to navigate TUI available over SSH
 * Clone repos over SSH, HTTP, or Git protocol
 * Git LFS support with both HTTP and SSH backends
 * Manage repos with SSH
 * Create repos on demand with SSH or git push
 * Browse repos, files and commits with SSH-accessible UI
 * Print files over SSH with or without syntax highlighting and line numbers
 * Easy access control
   * SSH authentication using public keys
   * Allow/disallow anonymous access
   * Add collaborators with SSH public keys
   * Repos can be public or private
   * User access tokens

Bug#1054442: bookworm-pu: package hash-slinger/3.1-1.1

[Antoine Beaupre]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: hash-slin...@packages.debian.org, ond...@debian.org, 
team+...@tracker.debian.org
Control: affects -1 + src:hash-slinger

[ Reason ]
When upgrading our Puppet server to bullseye, our DNS server couldn't
generate TLSA rules anymore because it was relying on a unpackaged
program. We eventually migrated to hash-slinger but in doing so
noticed it was generating broken TLSA records.

This has been reported as #1053483 against unstable, where it was
fixed and migrated to testing without known ill effects.

[ Impact ]
TLSA records cannot be generated.

[ Tests ]
Reproducer:

tlsa --create --usage=3 --selector=1 --mtype=1 --certificate 
example.com.crt --port 443 example.com --output=generic

Expected:

_443._tcp.cdn-fastly-backend.torproject.org. IN TYPE52 \# 35 
030101e86cb4aa5bec41b44c5e78c0b3b05992ab276d540376aca18eb494d8e229cd4c

Actual:

_443._tcp.cdn-fastly-backend.torproject.org. IN TYPE52 \# 35.0 
030101e86cb4aa5bec41b44c5e78c0b3b05992ab276d540376aca18eb494d8e229cd4c

Notice the float ("35.0") which should obviously be an integer. This
chokes the DNS server completely.

[ Risks ]
Code is a relatively trivial Python 3 tweak, minimal risk.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
This consists of a single, one-line patch, which has been submitted
and accepted upstream:

https://github.com/letoams/hash-slinger/pull/46

[ Other info ]
This is the second NMU on this package. I have tried to work on the
Git repository as well, but it's seriously lagging behind the versions
even in stable, so I haven't been able to do this. I understand the
maintainer is looking for help for the package but I unfortunately
cannot offer much help but patching this very issue for now...

Bug#1054244: poweralertd warns me about my battery at 99/100% constantly

[Antoine Beaupre]

Package: poweralertd
Version: 0.2.0-1+b1
Severity: normal

I keep getting those messages from poweralertd:

Power status: Framework
Battery fully charged
Current level: 100%

And then, shortly after:

Power status: Framework
Battery status: discharging
Current level: 100%

And then, it loops back above.

This is quite irritating, and keeps happening. It's not that big of a
deal because notifications do go away after a while, but it would be
great if this could be just a tad more silent.

It seems to me like a case where some hysteresis could control the
messaging here. I'm not sure exactly *how* that could be implemented
however... Upstream there are two discussions about how to fix this,
one about filtering notifications:

https://todo.sr.ht/~kennylevinsen/poweralertd/1

and another about adding a threshold for notifications:

https://lists.sr.ht/~kennylevinsen/poweralertd-devel/patches/43895

Perfection being the ennemy of good here, I think the latter patch is
our best hope for sanity.

-- System Information:
Debian Release: 12.2
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'experimental'), (1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages poweralertd depends on:
ii  init-system-helpers  1.65.2
ii  libc62.36-9+deb12u3
ii  libsystemd0  252.17-1~deb12u1
ii  upower   0.99.20-2

poweralertd recommends no packages.

poweralertd suggests no packages.

-- no debconf information

Bug#1054138: RFP: prometheus-ganeti-exporter -- Export Ganeti Statistics to Prometheus

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: gan...@packages.debian.org

* Package name: prometheus-ganeti-exporter
  Version : No release published
  Upstream Contact: https://github.com/ganeti/
* URL : https://github.com/ganeti/prometheus-ganeti-exporter
* License : BSD-2-Clause
  Programming Lang: Python
  Description : Export Ganeti Statistics to Prometheus

No real long description upstream.

Bug#1053805: ITP: tremotesf2 -- Remote GUI for transmission-daemon

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: tremotesf2
  Version : 2.4.0
  Upstream Contact: Alexey Rochev <https://github.com/equeim>
* URL : https://github.com/equeim/tremotesf2/
* License : GPL-3.0-or-later
  Programming Lang: C++
  Description : Remote GUI for transmission-daemon

Tremotesf is yet another, but modern (first-released in 2016)
cross-platfom GUI for Transmission daemon written in C++ and Qt.

Features include, but not necessarily limited to:
 * View torrent list
 * Sort torrents
 * Filter torrents by name, status and trackers
 * Start/stop/verify/remove torrents with multi-selection
 * Add torrents from torrent files and magnet links
 * Select which files to download when adding torrent
 * Manage torrent files
 * Add and remove torrent trackers
 * View torrent peers
 * Set torrent limits
 * Change remote server settings
 * View server statistics
 * Multiple servers
 * Supports HTTPS connection
 * Can connect to servers with self-signed certificates (you need to add
   certificate to server settings)
 * Client certificate authentication



The above description is taken from the FreeBSD port:

https://www.freshports.org/net-p2p/tremotesf/

There are other Transmission clients in Debian of course, but the best
one (the official "transmission-qt") has several release-critical
bugs, including crashes when adding new torrent files. It also doesn't
have as many features as the above, the one I am most interested in is
HTTPS.

Bug#1053477: RFP: pass-secret-service -- dbus-service to serve secret-service api with pass backend

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: pass-secret-service
  Version : no release published
  Upstream Contact: Matthias Dellweg 
* URL : https://github.com/mdellweg/pass_secret_service/
* License : GPL-3
  Programming Lang: Python
  Description : dbus-service to serve secret-service api with pass backend

Expose the libsecret dbus api with pass as backend.



I am not aware of any other wrapper around pass that provides a
standard interface for other applications to store their secrets into
it, is anyone else?

Requirements mention a few problematic deps:

git+https://github.com/mdellweg/python-dbus-next@master
secretstorage (python library not packaged in Debian)

It also depends on pypass, but that's already packaged in Debian
(interesting!).

Bug#1053413: RFP: tox-current-env -- tox plugin to run tests in current Python environment

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org

* Package name: tox-current-env
  Version : 0.0.11
  Upstream Contact: Miro Hrončok 
* URL : https://github.com/fedora-python/tox-current-env
* License : MIT
  Programming Lang: Python
  Description : tox plugin to run tests in current Python environment

The tox-current-env plugin adds these options:

tox --current-env
Runs the tox testenv's commands in the current Python environment
(that is, the environment where tox is invoked from and installed
in). Unlike regular tox invocation, this installs no dependencies
declared in deps. An attempt to run this with a Python version
that doesn't match will fail (if tox is invoked from an Python 3.7
environment, any non 3.7 testenv will fail).

tox --print-deps-to=FILE
Instead of running any commands, simply prints the declared
dependencies in deps to the specified FILE. This is useful for
preparing the current environment for tox --current-env. Use - for
FILE to print to standard output.

tox --print-extras-to=FILE
Instead of running any commands, simply prints the names of the
declared extras in extras to the specified FILE. This is useful
for preparing the current environment for tox --current-env. Use -
for FILE to print to standard output.

It is possible to use the two printing options together, as long as
the FILE is different.

Invoking tox without any of the above options should behave as regular
tox invocation without this plugin. Any deviation from this behavior
is considered a bug.

The plugin disables tox's way of providing a testing environment, but
assumes that you supply one in some other way. Always run tox with
this plugin in a fresh isolated environment, such as Python
virtualenv, Linux container or chroot. See other caveats below.

Obviously, tox was created to run tests in isolated Python virtual
environments. The --current-env flag totally defeats the purpose of
tox. Why would anybody do that, you might ask?

Well, it turns out that tox became too popular and gained another purpose.

The Python ecosystem now has formal specifications for many pieces of
package metadata like versions or dependencies. However, there is no
standardization yet for declaring test dependencies or running
tests. The most popular de-facto standard for that today is tox, and
we expect a future standard to evolve from tox.ini. This plugin lets
us use tox's dependency lists and testing commands for environments
other than Python venvs.

We hope this plugin will enable community best practices around tox
configuration to grow to better accomodate non-virtualenv environments
in general – for example, Linux distros, Conda, or containers.

Specifically, this plugin was created for Fedora's needs. When we
package Python software as RPM packages, we try to run the project's
test suite during package build. However, we need to test if the
software works integrated into Fedora, not with packages downloaded
from PyPI into a fresh environment. By running the tests in current
environment, we can achieve that.



In my case, I want to avoid constantly downloading unverified code
from the internet, or, even worse, *compile* code (e.g. for
python3-ldap, in my case) which involves a whole other pile of stuff
to install.

Other Tox plugins are currently maintained by the Python team (and
Peter Pentchev), so it would probably be the same for this one.

Bug#1053294: RFP: auto-cpufreq -- Automatic CPU speed & power optimizer

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: Adnan Hodzic 

* Package name: auto-cpufreq
  Version : 2.0.0
  Upstream Contact: Adnan Hodzic 
* URL : https://github.com/AdnanHodzic/auto-cpufreq
* License : LGPL-3
  Programming Lang: Python
  Description : Automatic CPU speed & power optimizer

Automatic CPU speed & power optimizer for, Linux based on active
monitoring of a laptop's battery state, CPU usage, CPU temperature and
system load. Ultimately allowing you to improve battery life without
making any compromises.

Features:


 * Monitoring
   * Basic system information
   * CPU frequency (system total & per core)
   * CPU usage (system total & per core)
   * CPU temperature (total average & per core)
   * Battery state
   * System load
 * CPU frequency scaling, governor and turbo boost management based on
   * Battery state
   * CPU usage (total & per core)
   * CPU temperature in combination with CPU utilization/load (prevent 
overheating)
   * System load
 * Automatic CPU & power optimization (temporary and persistent)




I found this package through this post on Debian Planet:

https://foolcontrol.org/?p=4603

This is a tool similar to already existing tools in Debian,
specifically TLP. According to the auto-cpufreq author though:

> Using tools like TLP can help in this situation with extending
> battery life (which is something I used to do for numerous years),
> but it also might come with its own set of problems, like losing
> turbo boost.
>
> With that said, I needed a simple tool which would automatically
> make "cpufreq" related changes, save battery like TLP, but let Linux
> kernel do most of the heavy lifting. That's how auto-cpufreq was
> born.
>
> Please note: auto-cpufreq aims to replace TLP in terms of
> functionality and after you install auto-cpufreq it's recommended to
> remove TLP. If both are used for same functionality, i.e: to set CPU
> frequencies it'll lead to unwanted results like overheating. Hence,
> only use both tools in tandem if you know what you're doing.

So I'm not exactly clear on what the overlap between the two is, but I
do feel there's some room in this space for another option. TLP is
rather "heavy" in terms of the number of things it does, it's a rather
big pill to swallow, with all sorts of pitfalls...

I like the idea of having a simple, one-task-focused tool.

I do not currently have the cycles to evaluate this any further, but
would love to collaborate on further research when I have time.

Otherwise, if anyone is interested in pursuing this any further,
please go right ahead (but keep this bug in CC!).

Bug#1052189: RFP: innernet -- Wireguard-based private network

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-r...@lists.debian.org

* Package name: innernet
  Version : 1.6.0
  Upstream Contact: https://github.com/tonarino
* URL : https://github.com/tonarino/innernet
* License : MIT
  Programming Lang: Rust
  Description : Wireguard-based private network

Innernet is an opinionated configuration system on top of WireGuard
that comes with some added features to make life easy, and is friendly
with various sizes of networks: one for your organization, one for
your project, one for your social circle to create an idealistic
alternate internet universe — your imagination's the limit.

Goals:

 * Conveniences a typical WireGuard user wants: peer names,
   auto-updating peer lists, groups based on IP blocks, and automatic
   NAT holepunching.

 * Free, open source, and made to be self-hosted. We think it's
   especially important for such a vital and low-level piece of our
   infrastructure to not be dependent on the livelihood of a company
   one has no control over.

 * Straightforward architecture — no Raft consensus here. It's a
   simple SQLite server/client model.



#972439 is related in the sense that Tailscale is similar in purpose
to this, but tailscale is only the client-side to a proprietary
server.

Nebula, Meshbird, ouroborous, unetd, and vpncloud are all somewhat
related alternatives, not packaged in Debian. There's also n2n and
yggdrasil that *are* packaged in Debian, but take a different approach
(ie. not Wireguard based).

Considering this is a Rust program, I'd love to have some other Rust
person take care of it. :)

Bug#1051812: RFP: vosk-api -- Offline speech recognition API

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: vosk-api
  Version : 0.3.45
  Upstream Contact: Alpha Cephei 
* URL : https://alphacephei.com/vosk/
* License : Apache-2.0
  Programming Lang: Jupyter, C++, Python, Java, ...
  Description : Offline speech recognition API

Vosk is an offline open source speech recognition toolkit. It enables
speech recognition for 20+ languages and dialects - English, Indian
English, German, French, Spanish, Portuguese, Chinese, Russian,
Turkish, Vietnamese, Italian, Dutch, Catalan, Arabic, Greek, Farsi,
Filipino, Ukrainian, Kazakh, Swedish, Japanese, Esperanto, Hindi,
Czech, Polish.

Vosk models are small (50 Mb) but provide continuous large vocabulary
transcription, zero-latency response with streaming API,
reconfigurable vocabulary and speaker identification.

Speech recognition bindings implemented for various programming
languages like Python, Java, Node.JS, C#, C++, Rust, Go and others.

Vosk supplies speech recognition for chatbots, smart home appliances,
virtual assistants. It can also create subtitles for movies,
transcription for lectures and interviews.

Vosk scales from small devices like Raspberry Pi or Android smartphone
to big clusters.



Debian has been shipping speech recognition software for a
while, mostly in the form of Sphinx, which is... well, it's not as
good as one would imagine those things to be.

Historically, such programs used to be extremely inaccurate and
largely in the realm of sci-fi and play things, but recent advances in
machine learning have shown tremendous progress in this area, which
makes it possible make use of (free!) software to enable voice-driven
applications of all sorts.

vosk is an API layer that can be used by other programs to implement
such solutions, and I think it would be a great addition to Debian.

The models are small and all free although the licenses vary:

https://alphacephei.com/vosk/models

Also, it could be possible to just package the API bits without
shipping the models in Debian, which of course would be less useful,
but more useful than nothing.

I'm not exactly sure what our policy is on models, actually: the
license of the models above is "free" in the sense that you can get
the binary and do what you want with it, but i'm not sure it would
pass the smell test of "wait, but where's the training data" kind of
stuff. I leave that to people more familiar with those sticky issues
and focus this RFP on the software side of things.

Also bewarned that I'm only peripherally familiar with ML and current
developments in AI.  I mostly fell (again) on vosk because of Numen:

https://numenvoice.org/

There are other models out there, that might be better targets. For
example,  "is a tensor library for machine learning
to enable large models and high performance on commodity hardware. It
is used by llama.cpp and whisper.cpp". But the latter two are on
relatively shakier legal grounds, as far as Debian is concerned.

There's also Mozilla's , "an
open source embedded (offline, on-device) speech-to-text engine which
can run in real time on devices ranging from a Raspberry Pi 4 to high
power GPU servers."

And there's a whole area of "home assistants" that have their own way
of doing things. This is just one of them, and I would be happy to
hear what's the best solution for this problem space.

Bug#1051717: split wtf(6) in a separate package?

[Antoine Beaupre]

Package: bsdgames
Version: 2.17-29+b1
Severity: critical

I wonder if wtf(6) should be split in a separate package. It's a
genuinely useful package (as opposed to a "game") that I have only
discovered recently, even though I have been familiar with BSD games
for more than a few decades at this point (!).

It seems to be effectively maintained in its own fork right now, with
updates on the acronyms files maintained in debian/patches, which
... doesn't seem ideal.

void-linux seem to have their own git repo for this now:

https://github.com/void-linux/netbsd-wtf

... and it seems relatively up to date. It *looks* like the upstream
source is split between:

http://cvsweb.netbsd.org/bsdweb.cgi/src/share/misc/?only_with_tag=MAIN

and:

http://cvsweb.netbsd.org/bsdweb.cgi/src/games/wtf/?only_with_tag=MAIN

... so I'm not sure how we should handle that, but maybe converging
over the above git repo would be best?

Another upstream I found is:

https://sourceforge.net/projects/bsd-games/

... but i'm not sure how valid that actually is either.

Arch seems to be using this as an upstream now:

https://github.com/vattam/BSDGames

See:

https://archlinux.org/packages/extra/x86_64/bsd-games/

... but that doesn't ship the wtf(6) program!

Anyway, just a thought!

-- System Information:
Debian Release: 12.1
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-11-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bsdgames depends on:
ii  libc6  2.36-9+deb12u1
ii  libfl2 2.6.4-8.2
ii  libgcc-s1  12.2.0-14
ii  libncurses66.4-4
ii  libstdc++6 12.2.0-14
ii  libtinfo6  6.4-4
ii  miscfiles [wordlist]   1.5+dfsg-4
ii  wamerican-huge [wordlist]  2020.12.07-2
ii  wfrench [wordlist] 1.2.7-2

bsdgames recommends no packages.

bsdgames suggests no packages.

-- no debconf information

Bug#1051647: please ship a fd(1) binary

[Antoine Beaupre]

Package: fd-find
Version: 8.6.0-3
Severity: wishlist

I understand this must be controversial, but I'd love if this package
could ship a /usr/bin/fd binary.

A casual search (`apt-file search bin/fd | grep fd'$'`) seem to
indicate a single package would conflict with this is the fdclone
package.

I don't think it would be fair to have the main binary package
conflict with fdclone, but perhaps there could be a secondary binary
package with a symlink that would?

I understand *I* can just add `alias fd=fd-find` to my shell, but I
happen to manage a *lot* of machines and don't really enjoy deploying
hacks like this all over the place. I also think it's doing a
disservice to our users to needlessly diverge from upstream.

Thank you for your consideration!

-- System Information:
Debian Release: 12.1
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-11-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fd-find depends on:
ii  libc6  2.36-9+deb12u1
ii  libgcc-s1  12.2.0-14

fd-find recommends no packages.

fd-find suggests no packages.

-- no debconf information

Bug#1040786: RFP: wl-screenrec -- High performance wlroots screen recording, featuring hardware encoding

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: wl-screenrec
  Version : no release published
  Upstream Contact: Russell Greene 
* URL : https://github.com/russelltg/wl-screenrec
* License : Apache-2.0
  Programming Lang: Rust
  Description : High performance wlroots screen recording, featuring 
hardware encoding

High performance screen recorder for wlroots Wayland.

Uses dma-buf transfers to get surface, and uses the GPU to do both the
pixel format conversion and the encoding, meaning the raw video data
never touches the CPU, leaving it free to run your applications.

System Requirements:
* Wayland compositor supporting the following protocols:
  * wlr-output-management-unstable-v1 (missing in hikari, cage, gamescope, 
kwinft)
  * wlr-screencopy-unstable-v1 (missing in gamescope and kwinft)
  Known working examples: sway, hyprland, wayfire, labwc.
* VA-API encoding:
  * Intel iGPUs: libva-intel-media-driver or libva-intel-driver
  * AMD/ATI GPUs: mesa-gallium-va


There's wf-recorder already packaged in Debian, and probably
desktop-specific ones as well, but, according to this project's
README, wl-screenrec beats wf-recorder by something like an order of
magnitude, at least, in performance.

Bug#1040213: RFP: backdown -- a file deduplicator

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: backdown
  Version : 1.1.1
  Upstream Contact: Denys Séguret
* URL : https://github.com/Canop/backdown/
* License : MIT?
  Programming Lang: Rust
  Description : a file deduplicator

Backdown helps you safely and ergonomically remove duplicate files.

Its design is based upon my observation of frequent patterns regarding
build-up of duplicates with time, especially images and other media
files.

Finding duplicates is easy. Cleaning the disk when there are thousands
of them is the hard part. What Backdown brings is the easy way to
select and remove the duplicates you don't want to keep.

A Backdown session goes through the following phases:

 1. Backdown analyzes the directory of your choice and find sets of
duplicates (files whose content is exactly the same). Backdown
ignores symlinks and files or directories whose name starts with a
dot.

 2. Backdown asks you a few questions depending on the
analysis. Nothing is removed at this point: you only stage files
for removal. Backdown never lets you stage all items in a set of
identical files

 3. After having maybe looked at the list of staged files, you confirm
the removals

 4. Backdown does the removals on disk



There's obviously at least half a dozen file deduplicators in Debian
or out there already. But those all compete more or less towards a
different goal, claiming all to be faster or safer than their
counterparts.

This one takes a different tack. It helps users decide whether
duplicate files need to be deleted or not, using quite interesting
(and exhaustive) primitives. Those are somewhat hidden in the
screenshots, so i'll try to expand on the questions here...

First question:

> You have several duplicates with "copy" names in the same directory
> than their identical "source" (for example 20200929_125405 (5th
> copy).jpg and 20200929_125405 (copy).jpg). I can automatically stage
> those 21 duplicates which would let you gain 73M. If you accept,
> you'll skip 10 questions.

Other questions:

> The /home/dys/Images/201911 directory contains 167 files which are
> all present elsewhere. [...]

> The /home/dys/Images/201911 directory contains 2 identical files, each
> one of size 27M. What do you want to do with those duplicates?
> [1] keep VID_20210924_120421.mp4 and stage other one(s) for removal
> [2] keep réussite-railsbleus-01.mp4 and stage other one(s) for removal
> [s] Skip and go to next question
> [e] End staging phase

... and so on. Quite clever.

This should probably be maintained under some rust umbrella.

Same author as broot (#948483).

Bug#1039857: podman crashes my systemd-managed sway session on exit

[Antoine Beaupre]

Package: sway
Version: 1.8.1-1
Severity: minor

This is a rather hairy problem.

I have made the perhaps-ill-advised configuration of hooking up my
wayland / sway session as a systemd --user unit.

When i run containers with podman and they exit with an error, the whole 
session crashes.

The last lines before death are:


jun 28 16:53:39 angela podman[298210]: 2023-06-28 16:53:39.53329688 -0400 EDT 
m=+1.000110624 container died 
de96bebba97ba50229c01a93e1a0928c34b954b50ca1ea295c20c1d3c2970137 
(image=quay.io/minio/mc:latest [...]
jun 28 16:53:39 angela podman[298287]: 2023-06-28 16:53:39.624658051 -0400 EDT 
m=+0.086326242 container cleanup [...]
jun 28 16:53:39 angela systemd[296508]: sway.service: Main process exited, 
code=exited, status=1/FAILURE


The podman lines have way more stuff in there, but i spare you the
details...

My .config/systemd/user/ setup is documented in 
https://anarc.at/software/desktop/wayland/#systemd-integration

A plain:

podman run docker.io/library/debian:bookworm-slim

... can reproduce the issue. Note that the command needs to be ran
from a terminal spawned by Sway itself, say with $mod-Return. If I
start it from a separate unit or with `systemd-run`, it doesn't crash
the session on exit.

If I run:

podman run -it --rm docker.io/library/debian:bookworm-slim

I notice that `conmon(8)` takes over the Main PID which is
essentially the core of the problem here. Because Sway refuses to
support systemd:

https://github.com/swaywm/sway/issues/5160

... it does not send a proper "READY" state through sd_notify as other
services might normally do.

In general, that's not *too* much of a problem: systemd can start and
manage services fine without this. But in this case, I'm starting
other units that *do* depend on Sway being ready to run, so I *do*
need this state to properly chain dependencies here.

So I have this horror in my sway config:

exec dbus-update-activation-environment --systemd XDG_CURRENT_DESKTOP=sway \
  && systemctl --user import-environment SWAYSOCK \
 DISPLAY \
 I3SOCK \
 WAYLAND_DISPLAY \
 XCURSOR_SIZE \
 XCURSOR_THEME \
  && systemd-notify --ready


And the systemd sway.service has:

NotifyAccess=all

... which is how conmon is able to hijack the Main PID.

A workaround is to change the Sway keybindings to start processes with
systemd, like this:

# start a terminal
#
# we start it as a systemd unit on the fly otherwise podman takes over
# the Main PID of the sway.service and container exits crash the whole
# session
bindsym $mod+Return exec systemd-run --user foot

The real fix here would be for Sway to send something to sd-daemon. Of
course, the easiest way to do this would be to do a clever call to
sd_notify() just at the right place in the Sway source code, but
there's little chance such a patch would be merged upstream...

I looked at the code, and the actual sd_notify() call is not *that*
complex. It opens a UNIX socket and shoves a message in there,
probably just READY=1. Surely Sway could figure out how to write to a
socket on its own?

Hell, it could even just vendor this stupid piece of code here:

https://sources.debian.org/src/systemd/253-4/src/libsystemd/sd-daemon/sd-daemon.c/#L453-L602

Anyway, I don't mean to troll here, but this was a really complicated
bug to figure out and to fix for me (thanks #debian-systemd folks!),
so I figured I would at *least* document it here somehow.

The best case scenario for me is that sway gets sd_notify support. A
working compromise could be an update to the README.Debian file or
even better a sample sway config that has the right knobs.

Failing that, I'm happy to just see this bug closed and add this to
the pile of custom weird shit I carry around everywhere.

Cheers! :)

-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sway depends on:
ii  libc62.36-9
ii  libcairo21.16.0-7
ii  libevdev21.13.0+dfsg-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgl1-mesa-dri  22.3.6-1+deb12u1
ii  libgles2 1.6.0-1
ii  libglib2.0-0 2.74.6-2
ii  libinput10   1.22.1-1
ii  libjson-c5   0.16-2
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libpcre2-8-0 10.42-1
ii  libpixman-1-00.42.2-1
ii  libsystemd0  

Bug#1037954: please ship upstream themes/

[Antoine Beaupre]

Package: foot
Version: 1.13.1-2
Severity: critical
X-Debbugs-Cc: please ship upstream themes

Upstream has a bunch of themes in the source tree. Those can be
included with a simple, say:

[main]
include=/usr/share/foot/themes/gruvbox-light.ini

yet we don't ship those themes! Wouldn't it be great to have those
around?

I'm not sure about /usr/share/foot, but i'm pretty sure it's a good
idea to ship them. :)


-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages foot depends on:
ii  foot-terminfo   1.13.1-2
ii  libc6   2.36-9
ii  libfcft43.1.5-3
ii  libfontconfig1  2.14.1-4
ii  libpixman-1-0   0.42.2-1
ii  libutf8proc22.8.0-1
ii  libwayland-client0  1.21.0-1
ii  libwayland-cursor0  1.21.0-1
ii  libxkbcommon0   1.5.0-1

foot recommends no packages.

Versions of packages foot suggests:
pn  foot-themes  

-- no debconf information

Bug#1036359: crashes with (wrong-type-argument consp nil)

[Antoine Beaupre]

Package: elpa-markdown-toc
Version: 0.1.5-2
Severity: grave

In Debian bookworm, markdown-toc is currently unusable.

Given the following markdown buffer:

```


# Background


## Why migrate?


## Gitolite and GitWeb inventory


# Proposal
```

markdown-toc-generate-toc crashes with:

Debugger entered--Lisp error: (wrong-type-argument consp nil)
  markdown-imenu-create-nested-index()
  funcall(markdown-imenu-create-nested-index)
  (markdown-toc--compute-toc-structure (funcall imenu-create-index-function))
  (funcall markdown-toc-user-toc-structure-manipulation-fn 
(markdown-toc--compute-toc-structure (funcall imenu-create-index-function)))
  (markdown-toc--generate-toc (funcall 
markdown-toc-user-toc-structure-manipulation-fn 
(markdown-toc--compute-toc-structure (funcall imenu-create-index-function
  (insert (markdown-toc--generate-toc (funcall 
markdown-toc-user-toc-structure-manipulation-fn 
(markdown-toc--compute-toc-structure (funcall imenu-create-index-function)
  (save-excursion (if (markdown-toc--toc-already-present-p) (progn 
(markdown-toc--delete-toc t))) (insert (markdown-toc--generate-toc (funcall 
markdown-toc-user-toc-structure-manipulation-fn 
(markdown-toc--compute-toc-structure (funcall imenu-create-index-function))
  markdown-toc-generate-toc(nil)
  funcall-interactively(markdown-toc-generate-toc nil)
  command-execute(markdown-toc-generate-toc record)
  execute-extended-command(nil "markdown-toc-generate-toc" nil)
  funcall-interactively(execute-extended-command nil 
"markdown-toc-generate-toc" nil)
  command-execute(execute-extended-command)



-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 
'testing'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages elpa-markdown-toc depends on:
ii  dh-elpa-helper  2.0.16
ii  elpa-dash   2.19.1+git20220608.1.0ac1ecf+dfsg-1
ii  elpa-markdown-mode  2.5-1
ii  elpa-s  1.12.0-5
ii  emacsen-common  3.0.5

Versions of packages elpa-markdown-toc recommends:
ii  emacs  1:28.2+1-14
ii  emacs-gtk [emacs]  1:28.2+1-14

elpa-markdown-toc suggests no packages.

-- no debconf information

Bug#1035947: fresh build from git fails with cannot access local variable 'new_file'

[Antoine Beaupre]

Source: firefox
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)

I'm trying to build Firefox 113 from the git repository. I have pulled
the package with:

debcheckout firefox

Then tried to download the latest tarballs with:

uscan --download-current

This crashes with a Python exception:

anarcat@angela:firefox$ uscan --download-current
Newest version of firefox on remote site is 113.0, specified download version 
is 113.0
uscan warn: Possible OpenPGP signature found at:
   
https://archive.mozilla.org/pub/firefox/releases/113.0/source/firefox-113.0.source.tar.xz.asc
 * Add opts=pgpsigurlmangle=s/$/.asc/ or opts=pgpmode=auto to debian/watch
 * Add debian/upstream/signing-key.asc.
 See uscan(1) for more details
Successfully symlinked ../firefox-113.0.source.tar.xz to 
../firefox_113.0.orig.tar.xz.
Traceback (most recent call last):
  File "/home/anarcat/dist/firefox/debian/repack.py", line 217, in 
main()
  File "/home/anarcat/dist/firefox/debian/repack.py", line 205, in main
if not new_file:
   
UnboundLocalError: cannot access local variable 'new_file' where it is not 
associated with a value
uscan: error: python3 debian/repack.py --upstream-version 113.0 
../firefox_113.0.orig.tar.xz subprocess returned exit status 1
anarcat@angela:firefox[1]$ 

I believe the following patch fixes the issue somehow:

diff --git i/debian/repack.py w/debian/repack.py
index 00d20928f6e..4f04ea200fb 100755
--- i/debian/repack.py
+++ w/debian/repack.py
@@ -199,6 +199,8 @@ def main():
 
 if options.new_file:
 new_file = options.new_file
+else:
+new_file = None
 
 if os.path.islink(args[0]):
 orig = os.path.realpath(args[0])

a.

-- Package-specific info:


-- Addons package information

-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 
'stable-security'), (500, 'testing'), (500, 'stable'), (1, 'experimental'), (1, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-8-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#1035578: fails to write image with TypeError: write() argument must be str, not bytes

[Antoine Beaupre]

Package: python3-matplotlib
Version: 3.6.3-1+b1
Severity: important

I have this tiny script which generates a silly graph of cryptographic
primitives here:

https://gitlab.com/anarcat/crypto-bench/-/blob/master/benchdiceware.py

The details are rather irrelevant here, but it eventually does this:

plt.savefig(args.output,
format=args.output.name[-3:])

... which is basically:

plt.savefig("foo.png", "png")

This used to work fine in Python 2. Now that we switched to Python 3,
this explodes with:

anarcat@angela:crypto-bench$ ./benchpasswords.py -o benchdiceware.png 
Traceback (most recent call last):
  File "/home/anarcat/src/crypto-bench/./benchpasswords.py", line 102, in 

render_graph(args.output)
  File "/home/anarcat/src/crypto-bench/./benchpasswords.py", line 90, in 
render_graph
plt.savefig(args.output,
  File "/usr/lib/python3/dist-packages/matplotlib/pyplot.py", line 959, in 
savefig
res = fig.savefig(*args, **kwargs)
  
  File "/usr/lib/python3/dist-packages/matplotlib/figure.py", line 3285, in 
savefig
self.canvas.print_figure(fname, **kwargs)
  File "/usr/lib/python3/dist-packages/matplotlib/backend_bases.py", line 2338, 
in print_figure
result = print_method(
 ^
  File "/usr/lib/python3/dist-packages/matplotlib/backend_bases.py", line 2204, 
in 
print_method = functools.wraps(meth)(lambda *args, **kwargs: meth(
 ^
  File "/usr/lib/python3/dist-packages/matplotlib/_api/deprecation.py", line 
410, in wrapper
return func(*inner_args, **inner_kwargs)
   ^
  File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_agg.py", 
line 517, in print_png
self._print_pil(filename_or_obj, "png", pil_kwargs, metadata)
  File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_agg.py", 
line 464, in _print_pil
mpl.image.imsave(
  File "/usr/lib/python3/dist-packages/matplotlib/image.py", line 1667, in 
imsave
image.save(fname, **pil_kwargs)
  File "/usr/lib/python3/dist-packages/PIL/Image.py", line 2431, in save
save_handler(self, fp, filename)
  File "/usr/lib/python3/dist-packages/PIL/PngImagePlugin.py", line 1307, in 
_save
fp.write(_MAGIC)
TypeError: write() argument must be str, not bytes
anarcat@angela:crypto-bench[1]$ 

It looks like matplotlib is calling PIL wrong. Or PIL is wrong itself,
I'm not sure where to lay the blame here...

a.

-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 
'stable-security'), (500, 'testing'), (500, 'stable'), (1, 'experimental'), (1, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-7-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-matplotlib depends on:
ii  libc6   2.36-9
ii  libfreetype62.12.1+dfsg-5
ii  libgcc-s1   12.2.0-14
ii  libjs-jquery3.6.1+dfsg+~3.5.14-1
ii  libjs-jquery-ui 1.13.2+dfsg-1
ii  libqhull-r8.0   2020.2-5
ii  libstdc++6  12.2.0-14
ii  python-matplotlib-data  3.6.3-1
ii  python3 3.11.2-1+b1
ii  python3-contourpy   1.0.7-1+b1
ii  python3-cycler  0.11.0-1
ii  python3-dateutil2.8.2-2
ii  python3-fonttools   4.38.0-1+b1
ii  python3-kiwisolver  1.4.4-1+b1
ii  python3-numpy [python3-numpy-abi9]  1:1.24.2-1
ii  python3-packaging   23.0-1
ii  python3-pil 9.4.0-1.1+b1
ii  python3-pil.imagetk 9.4.0-1.1+b1
ii  python3-pyparsing   3.0.9-1
ii  python3-six 1.16.0-4

Versions of packages python3-matplotlib recommends:
ii  python3-tk  3.10.8-1

Versions of packages python3-matplotlib suggests:
ii  cm-super-minimal 0.3.4-17
pn  dvipng   
ii  ffmpeg   7:5.1.2-3
pn  fonts-staypuft   
ii  ghostscript  10.0.0~dfsg-11
ii  gir1.2-gtk-3.0   3.24.37-2
ii  inkscape 1.2.2-2+b1
ii  ipython3 8.5.0-4
ii  librsvg2-common  2.54.5+dfsg-1
pn  python3-cairocffi
ii  python3-gi   3.42.2-3+b1
ii  python3-gi-cairo 3.42.2-3+b1
pn  python3-gobject  
ii  python3-pyqt55.15.9+dfsg-1
ii  python3-scipy1.10.1-2
ii  python3-sip  4.19.25+dfsg-5+b1
ii  python3-tornado  6.2.0-3
pn  texlive-extra-utils  
ii  texlive-latex-extra  2022.20230122-3

-- no debconf information

Bug#1034262: buffer overflow on peculiar drive

[Antoine Beaupre]

Package: nwipe
Version: 0.34-1+b1
Severity: normal
Tags: patch

I've used nwipe probably dozens of times on various times, and it
works fairly reliably. So I was surprised to find out it chokes on
this tiny little SSD drive here:

anarcat@angela:~$ sudo nwipe /dev/sdc
*** buffer overflow detected ***: terminated
Aborted
anarcat@angela:~[SIGABRT]$

Well isn't this odd! This is a fiarly normal drive:

anarcat@angela:~$ sudo smartctl -i -qnoserial /dev/sdc
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-7-amd64] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: Crucial/Micron RealSSD m4/C400/P400
Device Model: M4-CT512M4SSD1
Firmware Version: 040H
User Capacity:512 110 190 592 bytes [512 GB]
Sector Size:  512 bytes logical/physical
Rotation Rate:Solid State Device
Form Factor:  2.5 inches
TRIM Command: Available, deterministic
Device is:In smartctl database 7.3/5319
ATA Version is:   ACS-2, ATA8-ACS T13/1699-D revision 6
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:Tue Apr 11 15:42:51 2023 EDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

And speaking of smartctl, I suspect it's where nwipe chokes, because
as it turns out it crashes right after calling it, according to
strace:


anarcat@angela:~$ sudo strace -s8192 nwipe /dev/sdc
execve("/usr/sbin/nwipe", ["nwipe", "/dev/sdc"], 0x7ffda312d030 /* 15 vars */) 
= 0
brk(NULL)   = 0x55afbf726000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fbb351ae000
[...]
read(3, "smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-7-amd64] (local 
build)\nCopyright (C) 2002-22, Bruce Allen, Christian Franke, 
www.smartmontools.org\n\n", 4096) = 150
read(3, "=== START OF INFORMATION SECTION ===\nModel Family: Crucial/Micron 
RealSSD m4/C400/P400\nDevice Model: M4-CT512M4SSD1\nSerial Number:
REDACTED\nLU WWN Device Id: 5 00a075 109210beb\nFirmware Version: 040H\n", 
4096) = 223
read(3, "User Capacity:512\342\200\257110\342\200\257190\342\200\257592 
bytes [512 GB]\nSector Size:  512 bytes logical/physical\nRotation Rate:
Solid State Device\n", 4096) = 137
read(3, "Form Factor:  2.5 inches\nTRIM Command: Available, 
deterministic\nDevice is:In smartctl database 7.3/5319\nATA Version is: 
  ACS-2, ATA8-ACS T13/1699-D revision 6\nSATA Version is:  SATA 3.0, 6.0 Gb/s 
(current: 6.0 Gb/s)\nLocal Time is:Tue Apr 11 15:44:34 2023 EDT\nSMART 
support is: Available - device has SMART capability.\nSMART support is: 
Enabled\n\n", 4096) = 366
read(3, "", 4096)   = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=72484, si_uid=0, 
si_status=0, si_utime=0, si_stime=0} ---
close(3)= 0
wait4(72484, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 72484
writev(2, [{iov_base="*** ", iov_len=4}, {iov_base="buffer overflow detected", 
iov_len=24}, {iov_base=" ***: terminated\n", iov_len=17}], 3*** buffer overflow 
detected ***: terminated
) = 45
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fbb351ad000
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
gettid()= 72472
getpid()= 72472
tgkill(72472, 72472, SIGABRT)   = 0
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=72472, si_uid=0} ---
+++ killed by SIGABRT +++
Aborted

Of you look at the spaces in the "User Capacity" field more closely,
you'll notice it's actually a little odd. Those are not mere spaces in
those thousands separators, they are actually `U+202F NARROW NO-BREAK
SPACE` (represented by \342\200\257 in strace), according to
unicode(1). That, in itself, shouldn't be a problem: my terminal,
foot(1), is handling that fine, for example. But I bet it's the cause
of the overflow here.

Looking at gdb:

(gdb) bt
#0  __pthread_kill_implementation (threadid=, 
signo=signo@entry=6, 
no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1  0x77d8dd2f in __pthread_kill_internal (signo=6, 
threadid=) at ./nptl/pthread_kill.c:78
#2  0x77d3eef2 in __GI_raise (sig=sig@entry=6)
at ../sysdeps/posix/raise.c:26
#3  0x77d29472 in __GI_abort () at ./stdlib/abort.c:79
#4  0x77d822d0 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x77e9c210 "*** %s ***: terminated\n")
at ../sysdeps/posix/libc_fatal.c:155
#5  0x77e1af32 in __GI___fortify_fail (
msg=msg@entry=0x77e9c1b6 "buffer overflow detected")
at ./debug/fortify_fail.c:26
#6  0x77e19a40 in __GI___chk_fail () at ./debug/chk_fail.c:28
#7  0x77e19322 in __strcpy_chk (dest=dest@entry=0x55573622 "", 
src=src@entry=0x7fffe850 "125009210BEBUU", 
destlen=destlen@entry=21) at ./debug/strcpy_chk.c:30
#8  

Bug#1034205: wayout: does not do anything

[Antoine Beaupre]

Package: wayout
Version: 0.1.4-1
Severity: normal
X-Debbugs-Cc: ~mil/sxmo-de...@lists.sr.ht

I can't figure out how to use this program.

The upstream README (which is actually not shipped with the Debian
package) has a few examples:

> Static example for a calendar:
> 
> $ cal | wayout
> 
> Example to use wayout as a simple digital clock using --feed-line:
> 
> $ while; do date +%H:%M:%S; sleep 1; done | wayout --feed-line
> 
> You can use the pango markup language for text markup and colours:
> 
> $ echo "bold\nred" | wayout

Yet those don't really work so well:

 1. the first example just immediately exits and leaves no trace of
 a calendar in the output

 2. the second example *does* work, but is buried under all the other
 windows, so it's actually pretty hard to tell it actually *did* work
 unless you know where to look for it

 3. the third example fails for the same reason as the first
 (presumably?)

It looks like wayout immediately exits when the pipe shuts down, and
tears out its own widget alongside. For example, the first example, in
verbose mode, says this:

anarcat@angela:~$ cal | wayout --verbose
[main] wayout: version=0.1.4
[main] w=320 h=240 font=Monospace 26
[main] Init Wayland.
[output] Creating: global_name=44
[output] Configuring: global_name=44
[main] Starting loop.
[main] Got end of input, exiting
[main] Finish Wayland.
[output] Destroying all outputs.

Interestingly, using `--feed-line` with `cal` kind of works if you
squint a little, except not really: it only outputs the last line of
the calendar.

So, how does one use this?

My use case is to make a pop-up on a keybinding or a status bar
button, for example to show a calendar or undertime(1) in an overlay.

Thanks!

a.

-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'stable-security'), (500, 
'testing'), (500, 'stable'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-7-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wayout depends on:
ii  libc62.36-8
ii  libcairo21.16.0-7
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libwayland-client0   1.21.0-1

wayout recommends no packages.

wayout suggests no packages.

-- no debconf information

Bug#1034204: RFP: wlclock -- A digital analog clock for Wayland desktops

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: wlclock
  Version : 1.0.1
  Upstream Contact: Leon Plickat
* URL : https://git.sr.ht/~leon_plickat/wlclock
* License : GPL3
  Programming Lang: C
  Description : A digital analog clock for Wayland desktops

wlclock is a digital analog clock for Wayland desktops.

wlclock is inspired by xclock and the default configuration has been
chosen to mimic it. However unlike xclock, wlclock is not a regular
window but a desktop-widget.

A Wayland compositor must implement the Layer-Shell and XDG-Output for
wlclock to work.



Found this after finding wayout, which is derived from wlclock and
which *is* packaged in Debian...

Seems like a good foundational tool to have in this brave new Wayland
universe... Also curious to see if it keeps time as well as xclock...

Bug#1033915: puppetserver ca list fails with a 403 error

[Antoine Beaupre]

Package: puppetserver
Version: 7.9.5-1
Severity: important

In an upgraded Puppet server 7 running in Debian testing (bookworm), I
am seeing the following error when trying to list or sign CSRs:

root@marcos:/etc# puppetserver ca list
Error:
code: 403
body: Forbidden request: /puppet-ca/v1/certificate_statuses/any_key (method 
:get). Please see the server logs for details.
Error while getting certificate requests

Said logs tell me this:

2023-04-03T15:51:33.497-04:00 ERROR [qtp1647989340-88] [p.t.a.rules]
Forbidden request: marcos.anarc.at(127.0.0.1) access to 
/puppet-ca/v1/certificate_statuses/any_key (method :get) (authenticated: true) 
denied by rule 'puppetlabs cert status'.

It looks like I need extra hostnames in 
/etc/puppet/puppetserver/conf.d/auth.conf

In my case, adding `localhost` wasn't sufficient, I had to add the
FQDN of the Puppet server, which is a little distressing because it
feels like the Puppet server is relying on the reverse DNS to
authenticate clients, which is obviously flawed.

The patch, in my case, ended up something like:

root@marcos:/etc# git diff
diff --git a/puppet/puppetserver/conf.d/auth.conf 
b/puppet/puppetserver/conf.d/auth.conf
index 5059f0a5..b7ddc868 100644
--- a/puppet/puppetserver/conf.d/auth.conf
+++ b/puppet/puppetserver/conf.d/auth.conf
@@ -63,11 +63,16 @@ authorization: {
 type: path
 method: [get, put, delete]
 }
-allow: {
-   extensions: {
-   pp_cli_auth: "true"
-   }
-}
+allow: [
+   "localhost",
+   "127.0.0.1",
+   "marcos.anarc.at",
+   {
+   extensions: {
+   pp_cli_auth: "true"
+   }
+}
+]
 sort-order: 500
 name: "puppetlabs cert status"
 },

-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'stable-security'), (500, 
'testing'), (500, 'stable'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-6-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages puppetserver depends on:
ii  default-jre-headless 2:1.17-74
ii  facter   4.3.0-2
ii  hiera3.10.0-1
pn  jruby
pn  libclj-time-clojure  
pn  libclj-yaml-clojure  
pn  libclojure-java  
pn  libcomidi-clojure
pn  libcommons-exec-java 
ii  libcommons-io-java   2.11.0-2
pn  libcommons-lang-java 
pn  libdropwizard-metrics-java   
pn  libdujour-version-check-clojure  
pn  libjruby-utils-clojure   
pn  libkitchensink-clojure   
pn  libliberator-clojure 
pn  libprismatic-schema-clojure  
pn  libpuppetlabs-http-client-clojure
pn  libpuppetlabs-i18n-clojure   
pn  libpuppetlabs-ring-middleware-clojure
pn  libraynes-fs-clojure 
pn  libsemver-clojure
pn  libshell-utils-clojure   
pn  libslingshot-clojure 
pn  libssl-utils-clojure 
pn  libtrapperkeeper-authorization-clojure   
pn  libtrapperkeeper-clojure 
pn  libtrapperkeeper-comidi-metrics-clojure  
pn  libtrapperkeeper-filesystem-watcher-clojure  
pn  libtrapperkeeper-metrics-clojure 
pn  libtrapperkeeper-scheduler-clojure   
pn  libtrapperkeeper-status-clojure  
pn  libtrapperkeeper-webserver-jetty9-clojure
pn  libyaml-snake-java   
ii  puppet-agent 7.23.0-1
ii  ruby 1:3.1
ii  ruby-deep-merge  1.1.1-2
ii  ruby-fast-gettext2.0.3-2
ii  ruby-gettext 3.3.3-2
ii  ruby-hocon   1.3.1-2
ii  ruby-locale  2.1.3-1
pn  ruby-puppet-resource-api 
pn  ruby-puppetserver-ca-cli 
ii  ruby-semantic-puppet 1.0.4-1
ii  ruby-text1.3.1-1

Versions of packages puppetserver recommends:
pn  puppet-module-puppetlabs-augeas-core   
pn  puppet-module-puppetlabs-cron-core 
pn  puppet-module-puppetlabs-host-core 
pn  

Bug#1033564: pip install changes should be documented

[Antoine Beaupre]

Package: release-notes
Severity: important

Starting in bookworm, the seemingly innocuous command:

pip3 install foo

... will not work anymore. It will fail with this rather distressing
error:

$ pip install rsendmail
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
python3-xyz, where xyz is the package you are trying to
install.

If you wish to install a non-Debian-packaged Python package,
create a virtual environment using python3 -m venv path/to/venv.
Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
sure you have python3-full installed.

If you wish to install a non-Debian packaged Python application,
it may be easiest to use pipx install xyz, which will manage a
virtual environment for you. Make sure you have pipx installed.

See /usr/share/doc/python3.11/README.venv for more information.

note: If you believe this is a mistake, please contact your Python 
installation or OS distribution provider. You can override this, at the risk of 
breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.

... and while the error is somewhat self-documented, it would probably
help our users to flag this issue *before* they run the upgrade, and I
believe the release notes are a good place for this.

I am not sure *what* to say exactly. I think I'd give a heads up that
this is happening and show an example of `--break-system-packages` or
preferably how to do this in a virtual env.

It's basically a redux of the above error message, but that can't
assume (say) `/usr/share/doc/python3.11` is available because we
haven't done the upgrade yet.

Bug#1033013: execsnoop truncates arguments output

[Antoine Beaupre]

Package: libbpf-tools
Version: 0.26.0+ds-1
Severity: normal
File: /usr/sbin/execsnoop

execsnoop is super useful, but fails rather ungracefully if the
commandline argument is longer than 128 characters.

i have tried to improve that with a patch, but couldn't figure out
why.

execsnoop.bt in the bpftrace package doesn't suffer from this
limitation, so it's not a problem in the kernel itself.

See also: https://github.com/iovisor/bcc/issues/740


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'stable-security'), (500, 
'testing'), (500, 'stable'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libbpf-tools depends on:
ii  libc62.36-8
ii  libelf1  0.188-2.1
ii  zlib1g   1:1.2.13.dfsg-1

libbpf-tools recommends no packages.

libbpf-tools suggests no packages.

-- no debconf information

Bug#1033010: improve performance on 9p by raising msize

[Antoine Beaupre]

Package: autopkgtest
Version: 5.28
Severity: normal

I get this warning when building packages with the autopkgtest
sbuild-qemu backend:

qemu-system-x86_64: warning: 9p: degraded performance: a reasonable high 
msize sho.

It looks like this is an upstream issue, but I wonder if we might not
be able to do some better tweaking for this. This is discussed here
upstream:

https://wiki.qemu.org/Documentation/9psetup#Performance_Considerations_(msize)

where they suggest changing from the default 128KiB to tens of
*megabytes*. The example uses:

msize=104857600

which is 100 megs, if i'm not mistaken.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'stable-security'), (500, 
'testing'), (500, 'stable'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages autopkgtest depends on:
ii  apt-utils   2.5.6
ii  libdpkg-perl1.21.20
ii  procps  2:4.0.2-3
ii  python3 3.11.2-1
ii  python3-debian  0.1.49

Versions of packages autopkgtest recommends:
ii  autodep8  0.28
ii  fakeroot  1.29-1

Versions of packages autopkgtest suggests:
pn  docker.io
pn  fakemachine  
pn  lxc  
pn  lxd  
ii  ovmf 2022.11-2
pn  ovmf-ia32
ii  podman   4.3.1+ds1-5+b2
ii  python3-distro-info  1.5
ii  qemu-efi-aarch64 2022.11-2
ii  qemu-efi-arm 2022.11-2
pn  qemu-system  
ii  qemu-utils   1:7.2+dfsg-4
ii  schroot  1.6.13-3+b1
ii  util-linux   2.38.1-5
ii  vmdb20.26-2
ii  zerofree 1.1.1-1

-- no debconf information

Bug#1032960: RFP: elpa-corfu -- Completion Overlay Region FUnction in Emacs

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-em...@lists.debian.org

* Package name: elpa-corfu
  Version : 0.35
  Upstream Contact: Daniel Mendler 
* URL : https://github.com/minad/corfu/
* License : GPL-3
  Programming Lang: Emacs Lisp
  Description : Completion Overlay Region FUnction in Emacs

Corfu enhances completion at point with a small completion popup. The
current candidates are shown in a popup below or above the
point. Corfu is the minimalistic completion-in-region counterpart of
the Vertico minibuffer UI.

Corfu is a small package, which relies on the Emacs completion
facilities and concentrates on providing a polished completion
UI. Completions are either provided by commands like
dabbrev-completion or by pluggable backends
(completion-at-point-functions, Capfs). Most programming language
major modes implement a Capf. Furthermore the language server
packages, Eglot and Lsp-mode, use Capfs which talk to the LSP server
to retrieve the completions. Corfu does not include its own completion
backends. The Emacs built-in Capfs and the Capfs provided by other
programming language packages are usually sufficient. A few additional
Capfs and completion utilities are provided by the Cape package.



This is similar to the already packaged company mode, but has the
crucial difference that it doesn't require any mode-specific
completion mechanism like company. Instead, it reuses the existing
"completion-at-point-function" already defined in the major mode. It
interoperates with Language Server Protocol (LSP) packages as well,
like eglot and lsp-mode.

More completion modes are provided by an external "cape" package:

https://github.com/minad/cape

... not packaged in Debian.

Corfu also integrates with the "orderless" completion style, already
packaged in Debian as elpa-orderless

I am currently using company but I'm considering switching to this in
a feeble attempt at simplifying my init file.

Bug#1032888: unblock: pubpaste/0.8.3

[Antoine Beaupre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: pubpa...@packages.debian.org
Control: affects -1 + src:pubpaste

Please unblock package pubpaste

[ Reason ]
There are two serious crashes in pubpaste in testing right now, which
I haven't reported myself but have fixed, as the upstream.

[ Impact ]
Worst case: program crashes when doing a screenshot. Best case, it
works, but fails to copy unicode from Firefox.

[ Tests ]
I use this code daily, in graphical and console environment.

[ Risks ]
It's a leaf package, low popcon, low impact on the rest of the
ecosystem, really a convenience for the poor users.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
I must apologize for this: I uploaded the package before the hard
freeze and miscalculated the transition time. I was expecting 0.8.3 to
land in bookworm before the hard freeze.

To be more accurate, I had the understanding that the freeze applied
to packages uploaded to sid *after* the hard freeze start. Maybe that
was engrained in my brain from a previous policy that had changed
since?

In any case, sorry about this! I hope you're not too swamped by all
the unblock requests.

(And yes, this package should really have autopkgtests, I only have
myself to blame for that one too...)

If this fails to unblock, I think it might be preferable to maintain
this through backports and simply remove it from bookworm.

unblock pubpaste/0.8.3
diff -Nru pubpaste-0.8.1/debian/changelog pubpaste-0.8.3/debian/changelog
--- pubpaste-0.8.1/debian/changelog 2023-02-21 11:27:35.0 -0500
+++ pubpaste-0.8.3/debian/changelog 2023-03-09 12:29:54.0 -0500
@@ -1,3 +1,16 @@
+pubpaste (0.8.3) unstable; urgency=medium
+
+  * fix crash when uploading badly-encoded unicode
+  * support for Firefox in HTML pastes
+
+ -- Antoine Beaupré   Thu, 09 Mar 2023 12:29:54 -0500
+
+pubpaste (0.8.2) unstable; urgency=high
+
+  * fix regression in screenshots introduced in 0.8.1
+
+ -- Antoine Beaupré   Mon, 06 Mar 2023 14:12:11 -0500
+
 pubpaste (0.8.1) unstable; urgency=medium
 
   * fix another crash when running without GTK
diff -Nru pubpaste-0.8.1/pubpaste.py pubpaste-0.8.3/pubpaste.py
--- pubpaste-0.8.1/pubpaste.py  2023-02-21 11:27:35.0 -0500
+++ pubpaste-0.8.3/pubpaste.py  2023-03-09 12:29:54.0 -0500
@@ -48,6 +48,11 @@
 Type,
 TypeVar,
 )
+
+try:
+from typing import TypeAlias
+except ImportError:
+from typing_extensions import TypeAlias  # Python 3.9 or earlier
 from urllib.parse import quote
 import yaml
 
@@ -76,7 +81,8 @@
 
 gi.require_version("Gtk", "3.0")
 from gi.repository import GLib, Gtk, Gdk, GdkPixbuf  # type: ignore
-from Gtk import MessageDialog  # type: ignore
+
+MessageDialog = Gtk.MessageDialog
 except (ImportError, ValueError):
 # "ValueError('Namespace %s not available' % namespace)"
 gi = None
@@ -84,6 +90,7 @@
 class MessageDialog:  # type: ignore
 pass
 
+
 __epilog__ = """ This program will upload the provided files on the internet 
and
 notify the user when completed. The resulting URL will also be copied
 to the clipboard. Preprocessors can do fancy things before (only
@@ -583,7 +590,7 @@
 """
 
 
-class TimerWindow(MessageDialog):  # type: ignore[misc]
+class TimerWindow(MessageDialog):  # type: ignore[misc, valid-type]
 """This widget will show a timer and a spinner in a window for the
 given delay, then close the dialog.
 
@@ -1072,6 +1079,9 @@
 return datetime.now().strftime("%Y-%m-%d"), secrets.token_urlsafe()
 
 
+SupportedExtensions: TypeAlias = Literal["png", "jpg", "txt", "html"]
+
+
 class BaseClipboard:
 def __init__(self, selection: Literal["CLIPBOARD", "PRIMARY"]) -> None:
 """configure the clipboard, based on whether the clipboard is PRIMARY
@@ -1088,7 +1098,7 @@
 def put_image(self, path: bytes) -> bool:
 raise NotImplementedError()
 
-def get(self) -> Tuple[Optional[bytes], Optional[Literal["png", "jpg", 
"txt"]]]:
+def get(self) -> Tuple[Optional[bytes], Optional[SupportedExtensions]]:
 raise NotImplementedError()
 
 
@@ -1181,7 +1191,7 @@
 # we use _exit() to avoid firing atexit() in double
 os._exit(0)
 
-def get(self) -> Tuple[Optional[bytes], Optional[Literal["png", "jpg", 
"txt"]]]:
+def get(self) -> Tuple[Optional[bytes], Optional[Literal["png", "txt"]]]:
 """get the clipboard content, possible as an image or, failing that, 
as text
 
 GTK clipboards also support "rich text" and "URI", but I'm not
@@ -1243,12 +1253,12 @@
 logging.warning("could not copy to clipboard with: %r", command)
 return False
 
-def get(self) -> Tuple[Optional[bytes], Optional[Literal["png", "jpg", 
"txt"]]]:
+def get(self) -> Tuple[Optional[bytes], 

Bug#1032287: SystemError: PY_SSIZE_T_CLEAN macro must be defined for '#' formats

[Antoine Beaupre]

Package: python3-qrencode
Version: 1.2-5+b8
Severity: grave
X-Debbugs-Cc: debian-pyt...@lists.debian.org

It looks like the qrencode Python library is currently unusable in
Debian bookworm. Here's a simple example:

anarcat@angela:paperbackup$ python3 -c 'import qrencode ; version, size, data = 
qrencode.encode(b"test")'
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/qrencode/__init__.py", line 47, in encode
version, size, data = _encode(data, version, level, hint, True)
  ^
SystemError: PY_SSIZE_T_CLEAN macro must be defined for '#' formats
anarcat@angela:paperbackup[1]$

According to a casual search on the web, it looks like the extension
needs to be recompiled / patched for Python 3.10:

https://stackoverflow.com/a/71019907

Quote:

> On 3.10 any module(s) that use the # variant when parsing arguments
> need to have a #define PY_SSIZE_T_CLEAN before including Python.h.

So this could be as simple as:

--- python-qrencode-1.2.orig/qr_encode.c
+++ python-qrencode-1.2/qr_encode.c
@@ -1,3 +1,4 @@
+#define PY_SSIZE_T_CLEAN
 #include 
 #include 
 #include 

Will test this out soon.

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'testing'), (500, 'stable'), (1, 
'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-qrencode depends on:
ii  libc6 2.36-8
ii  libqrencode4  4.1.1-1
ii  python3   3.11.2-1

python3-qrencode recommends no packages.

python3-qrencode suggests no packages.

-- no debconf information

Bug#1031941: O: tty-clock -- simple terminal clock

[Antoine Beaupre]

Package: wnpp
Severity: normal
X-Debbugs-Cc: tty-cl...@packages.debian.org
Control: affects -1 + src:tty-clock

I intend to orphan the tty-clock package.

The package description is:
 tty-clock is a simple ncurses-based clock that shows the time and date
 using a large display. It has a few commandline options to customize
 the output.

I am kind of upstream on this, but not really: I just have access to
the upstream's repo. And really, at this point, I don't use this
software, so I don't really have time nor interest into maintain it
any further.

Bug#1031940: RM: pepper -- ROM; inactive upstream, FTBFS in gcc-11

[Antoine Beaupre]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: pep...@packages.debian.org
Control: affects -1 + src:pepper

pepper has a FTBFS in Debian unstable / bookworm (#984287) which seems
to be mostly due to stricter GCC (basically -Wimplicit-fallthrough).

While this is a somewhat minor fix, I doubt it will be merged
upstream, which hasn't seen a single commit in over 6 years:

https://github.com/jgehring/pepper/commits/master

I do not wish to institute a Debian-specific fork of Pepper, and I
believe this package is best retired from Debian.

At first I thought, "oh there aren't that many alternatives for
pepper", but then I went down that rabbit hole and found a whopping 13
programs doing something similar, with a handful actually packaged in
Debian. Here's what I found, more or less by relevance:

# Packaged in Debian:

 * git-sizer: https://github.com/github/git-sizer

   Shows large files, history depth, big objects.

 * git-quick-stats: https://git-quick-stats.sh/

   "Simple way to access various statistics in git
   repository". Probably the best replacement, but command line
   only.

 * gitinspector: https://github.com/ejwa/gitinspector

   "statistical analysis tool". looks really promising, packaged in
   Debian.

# Not packaged in Debian

 * git-metrics: https://github.com/Praqma/git-metrics

   "analyse another git repository for metrics such as lead time and
   open branches". Not packaged, Python.

 * hercules: https://github.com/src-d/hercules

   "advanced insights from Git repository history". not packged in
   Debian (src:hercules is http://www.hercules-390.eu/, not this).

 * git-stats: https://github.com/IonicaBizau/git-stats

   "Local git statistics including GitHub-like contributions
   calendars." HTML/Javascript. Not packaged in Debian.

 * git_stats: https://github.com/tomgi/git_stats

   "git repository statistics generator", unclear how it differs from
   the above. Ruby. Not packaged in Debian.

 * gitstats: https://github.com/hoxu/gitstats

   "statistics generator", actually pretty similar to Pepper, mostly
   abandoned, not packaged in Debian.

 * repostat: https://github.com/vifactor/repostat

   Fork of gitstats, same.

 * git-bars: https://github.com/knadh/git-bars

   "render a simple git commit activity bars on the terminal"

 * git-hours: https://github.com/kimmobrunfeldt/git-hours

   "Estimate time spent on a git repository." Not packaged in Debian
   (NPM/JS).

 * fornalder: https://github.com/hpjansson/fornalder

   Shows commit threads over long periods of history (think
   decades). Not packaged in Debian. Used to make:

   https://hpjansson.org/blag/2020/12/16/on-the-graying-of-gnome/

 * this thing: https://jpalmer.dev/2021/05/interactive-git-history/

   Not sure if this can be called a replacement, as it's highly
   specific to analysing git itself.

Phew!

Anyways, please remove this package. :)

Bug#1031789: RFP: thunar-plugins -- easy Python plugins for Thunar

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org

* Package name: thunar-plugins
  Version : 1.4.0
  Upstream Contact: Yann Büchau
* URL : https://pypi.org/project/thunar-plugins/
* License : GPLv3
  Programming Lang: Python
  Description : easy Python plugins for Thunar

This Python package extends the Thunar file manager and provides a way for 
other Python packages to do the same without worrying about Thunar finding them.

Features Added to Thunar

  * a settings menu to en-/disable plugins added by this or other Python 
packages
  * creating links to a file or folder
  * Calculating various checksums of files
  * Git Annex support:
* git annex sync|add|get|drop|lock|unlock
* branch switching
* metadata-driven views
* editing metadata in the file properties dialog



This plugin seems amazing. It's the best git-annex integration I've
seen in a file manager so far.

It has an unfortunate name though, as it does way more as being
"plugins", it actually ships a bunch of plugins itself...

Bug#1031562: RFP: phockup -- Media sorting tool to organize photos and videos from your camera in folders by year, month and day

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org

* Package name: phockup
  Version : 1.9.2
  Upstream Contact: Ivan Dokov 
* URL : https://github.com/ivandokov/phockup
* License : MIT
  Programming Lang: Python
  Description : Media sorting tool to organize photos and videos from your 
camera in folders by year, month and day

The software will collect all files from the input directory and copy
them to the output directory without changing the files content. It
will only rename the files and place them in the proper directory for
year, month and day.

All files which are not images or videos or those which do not have
creation date information will be placed in a directory called unknown
without file name change. By doing this you can be sure that the input
directory can be safely deleted after the successful process
completion because all files from the input directory have a copy in
the output directory.

If the target file already exists, its checksum is compared with the
source to determine if it is a duplicate. If the checksums are
different, we do not have a duplicate and the target filename will be
suffixed with a number, for example "-1". If the checksums match, the
copy operation will be skipped.



Debian has Rapid Photo Downloader packaged right now (and I'm one of
the uploaders), but I'm having issues with it at the moment:

 1. it basically crashes under Wayland #1031557
 2. it does not allow me to move images (anymore)
 3. it only partly allows culling images (you can deselect images but
 not delete them)

Right now I've reverted back to using exiftool to batch-import images,
but exiftool is notoriously counter-intuitive and error prone.

This looks like a promising alternative.

Bug#1031557: uses a full CPU doing nothing in Wayland

[Antoine Beaupre]

Package: rapid-photo-downloader
Version: 0.9.33-1.1
Severity: normal

It's been a long time since I used RPD and now when I start it up, it
eats up a whole CPU. The fans on my shiny new 12th gen intel Framework
CPU spin up like crazy and CPU temperature reaches 95C.

I'm not sure what is happening: nothing is going on in the UI. At
first I thought it was rendering thumbnails, but it not, the thumbs
are actually rendered already.

strace tells me the process is looping over something like this:

poll([{fd=4, events=POLLIN}, {fd=12, events=POLLIN}, {fd=76, events=POLLIN}, 
{fd=80, events=POLLIN}], 4, 0) = 1 ([{fd=4, revents=POLLIN}])
read(4, "\5\0\0\0\0\0\0\0", 16) = 8
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
sendmsg(5, {msg_name=NULL, msg_namelen=0, 
msg_iov=[{iov_base="\32\0\0\0\1\0\24\0,\0\0\0\0\0\0\0\0\0\0\0\32\0\0\0\t\0\30\\2\0\0"...,
 iov_len=76}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 
MSG_DONTWAIT|MSG_NOSIGNAL) = 76
poll([{fd=4, events=POLLIN}, {fd=12, events=POLLIN}, {fd=76, events=POLLIN}, 
{fd=80, events=POLLIN}], 4, 0) = 1 ([{fd=4, revents=POLLIN}])
read(4, "\3\0\0\0\0\0\0\0", 16) = 8
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
futex(0x1eb0e70, FUTEX_WAKE_PRIVATE, 1) = 1
poll([{fd=4, events=POLLIN}, {fd=12, events=POLLIN}, {fd=76, events=POLLIN}, 
{fd=80, events=POLLIN}], 4, 0) = 1 ([{fd=4, revents=POLLIN}])
read(4, "\5\0\0\0\0\0\0\0", 16) = 8
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
sendmsg(5, {msg_name=NULL, msg_namelen=0, 
msg_iov=[{iov_base="\32\0\0\0\1\0\24\0,\0\0\0\0\0\0\0\0\0\0\0\32\0\0\0\t\0\30\\2\0\0"...,
 iov_len=76}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 
MSG_DONTWAIT|MSG_NOSIGNAL) = 76
poll([{fd=4, events=POLLIN}, {fd=12, events=POLLIN}, {fd=76, events=POLLIN}, 
{fd=80, events=POLLIN}], 4, 0) = 1 ([{fd=4, revents=POLLIN}])
read(4, "\3\0\0\0\0\0\0\0", 16) = 8
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
write(4, "\1\0\0\0\0\0\0\0", 8) = 8

File descriptors 4 and 5 are:

lrwx-- 1 anarcat anarcat 64 2023-02-18 11:03 /proc/21490/fd/4 -> 
'anon_inode:[eventfd]'
lrwx-- 1 anarcat anarcat 64 2023-02-18 11:03 /proc/21490/fd/5 -> 
'socket:[174401]'

Inspecting the output of `sudo lsof -P -n` shows me that socket 174401
is a UNIX socket connected to another RPD thread that's called
WaylandEv[...?]:

COMMAND PID   TID TASKCMD USER   FD  TYPE DEVICE  
SIZE/OFF   NODE NAME
rapid-pho 21490 21503 WaylandEvanarcat5u unix 0xce9ee8de
   0t0 174401 type=STREAM (CONNECTED)

I've also ran out of 16GB of memory on this machine trying to run RPD
and Darktable in parallel, and also seen Sway crash.

It seems this thing really doesn't like to run under Wayland (or
Sway?)... This could also be a bug in python3-qt5 or Qt itself. It
could an instance of #996550 for example. Not sure.

a.

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'testing'), (500, 'stable'), (1, 
'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rapid-photo-downloader depends on:
ii  gir1.2-gexiv2-0.10  0.14.0-1+b1
ii  gir1.2-glib-2.0 1.74.0-3
ii  gir1.2-gstreamer-1.01.22.0-2
ii  gir1.2-gudev-1.0237-2
ii  gir1.2-notify-0.7   0.8.1-1
ii  gir1.2-udisks-2.0   2.9.4-4
ii  gstreamer1.0-libav  1.22.0-2
ii  gstreamer1.0-plugins-good   1.22.0-4
ii  ifuse   1.1.4~git20181007.3b00243-1
ii  libgphoto2-62.5.30-1
ii  libimage-exiftool-perl  12.55+dfsg-1
ii  libimobiledevice-utils  1.3.0-6+b3
ii  libmediainfo0v5 22.12+dfsg-1
ii  libqt5svg5  5.15.8-2
ii  python3 3.11.1-3
ii  python3-arrow   1.2.3-1
ii  python3-babel   2.10.3-1
ii  python3-colour  0.1.5-3
ii  python3-dateutil2.8.2-1
ii  python3-easygui 0.98.1-3
ii  python3-gi  3.42.2-3+b1
ii  python3-gphoto2 1.9.0-1+b4
ii  python3-importlib-metadata  4.12.0-1
ii  python3-pkg-resources   66.1.1-1
ii  python3-psutil  5.9.4-1+b1
ii  python3-pymediainfo 6.0.1-2
ii  python3-pyqt5   5.15.9+dfsg-1
ii  python3-requests2.28.1+dfsg-1
ii  

Bug#1030323: /etc/default/puppet refers to non-existent /etc/init.d/puppet-agent

[Antoine Beaupre]

Package: puppet-agent
Version: 7.22.0-3
Severity: normal

Today's upgrade suggested this patch to the configuration file:

Configuration file '/etc/default/puppet'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
  D : show the differences between the versions
  Z : start a shell to examine the situation
 The default action is to keep your current version.
*** puppet (Y/I/N/O/D/Z) [default=N] ? d
--- /etc/default/puppet 2022-09-29 12:50:59.011237328 -0400
+++ /etc/default/puppet.dpkg-new2023-01-29 10:45:20.0 -0500
@@ -1 +1,4 @@
-START=no
+# Defaults for puppet - sourced by /etc/init.d/puppet
+
+# Startup options
+DAEMON_OPTS=""

Yet that file doesn't exist:

cat: /etc/init.d/puppet: No such file or directory

The init file is actually /etc/init.d/puppet-agent now, so the default
file needs to be corrected.

It should also be noted (perhaps in the NEWS.Debian?) that the
previous START=no variable will probably not work to disable the agent
daemon... Considering `exit 0` in there, not sure.


-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'testing'), (500, 'stable'), (1, 
'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages puppet-agent depends on:
ii  adduser3.130
ii  debconf [debconf-2.0]  1.5.82
ii  facter 4.2.13-2
ii  hiera  3.10.0-1
ii  init-system-helpers1.65.2
ii  ruby   1:3.1
ii  ruby-augeas1:0.5.0+gem-1
ii  ruby-concurrent1.1.6+dfsg-5
ii  ruby-deep-merge1.1.1-2
ii  ruby-semantic-puppet   1.0.4-1
ii  ruby-shadow2.5.1-1
ii  ruby-sorted-set1.0.3-3

Versions of packages puppet-agent recommends:
ii  augeas-tools   1.14.0-1
ii  debconf-utils  1.5.82
ii  lsb-release12.0-1
ii  ruby-selinux   3.4-1+b5

Versions of packages puppet-agent suggests:
pn  hiera-eyaml
pn  puppet-module-puppetlabs-augeas-core   
pn  puppet-module-puppetlabs-cron-core 
pn  puppet-module-puppetlabs-host-core 
pn  puppet-module-puppetlabs-mount-core
pn  puppet-module-puppetlabs-selinux-core  
pn  puppet-module-puppetlabs-sshkeys-core  
pn  puppet-module-puppetlabs-stdlib
ii  ruby-hocon 1.3.1-2
pn  ruby-msgpack   

-- Configuration Files:
/etc/puppet/puppet.conf changed [not included]

-- debconf information:
  puppet-agent/postrm_purge_data: true

Bug#1030249: unexpected "prefclean output on ..." emails since bookworm upgrade

[Antoine Beaupre]

Package: apt-listbugs
Version: 0.1.40
Severity: minor

Since I'm running bookworm, apt-listbugs started pestering me with
emails that look like this:

Date: Wed, 01 Feb 2023 07:25:20 -0500
From: apt-listbugs timer 
To: r...@anarc.at
Subject: prefclean output on curie

/usr/libexec/apt-listbugs/prefclean:
 Paquets corrigés : breeze kactivitymanagerd ksshaskpass kwayland-integration 
polkit-kde-agent-1

That "Paquets corrigés" string there means "Fixed packages" in
english. I've traced it down to /usr/libexec/apt-listbugs/aptcleanup,
itself called from /usr/libexec/apt-listbugs/prefclean which
specifically makes a point of explicitely writing an email if you're
running under systemd.

I'd love a way to turn that stuff off or, preferably, have it logged
normally in syslog/journald. I don't need to be told when those things
are fixed: I'm assuming apt-listbugs will do its job correctly unless
otherwise noted. In other words, this is not a failure condition, it's
actually a *success* condition, and I don't really need to be told
about those.

Could we make this a knob at least? It looks like aptcleanup looks at
the apt preferences to that might be a good place, but prefclean is
where the decision is actually mean on how to treat the aptclean
output, so I'm not sure how best this could be done...

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (1, 
'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt-listbugs depends on:
ii  apt 2.5.5
ii  ruby1:3.1
ii  ruby-debian 0.3.10+b8
ii  ruby-gettext3.3.3-2
ii  ruby-soap4r 2.0.5-5
ii  ruby-unicode0.4.4.4-1+b5
ii  ruby-xmlparser  0.7.3-4+b4

Versions of packages apt-listbugs recommends:
ii  ruby-httpclient  2.8.3+git20211122.4658227-1

Versions of packages apt-listbugs suggests:
ii  chromium [www-browser]  109.0.5414.119-1
ii  firefox [www-browser]   109.0-1
ii  lynx [www-browser]  2.9.0dev.12-1
ii  reportbug   11.6.0
ii  sensible-utils  0.0.17+nmu1
ii  w3m [www-browser]   0.5.3+git20230121-1
ii  xdg-utils   1.1.3-4.1

-- debconf-show failed

Bug#1030153: journald floods itself with apparmor warnings

[Antoine Beaupre]

Package: apparmor
Version: 3.0.8-2
Severity: important

I'm not sure where to lay the blame here, but I can't really use
journalctl since the bookworm upgrade here anymore.


anarcat@marcos:~$ journalctl -n 10| tail -10
jan 31 11:56:02 marcos audit[2208193]: AVC apparmor="ALLOWED" operation="open" 
profile="/usr/sbin/sshd//null-/usr/bin/bash//null-/usr/bin/screen//null-/usr/bin/bash//null-/usr/bin/journalctl"
 
name="/var/log/journal/3840589866da411b178e07aa001d/user-1041@3109a3dba85e4c67820c02b55f829e1e-0d34f9da-0005f3830e701d7e.journal"
 pid=2208193 comm="journalctl" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=0
jan 31 11:56:02 marcos audit[2208193]: AVC apparmor="ALLOWED" operation="open" 
profile="/usr/sbin/sshd//null-/usr/bin/bash//null-/usr/bin/screen//null-/usr/bin/bash//null-/usr/bin/journalctl"
 
name="/var/log/journal/3840589866da411b178e07aa001d/user-1046@52cb1b4160de4973b22b9d1e879ceafe-0d1c3822-0005f36d67b663da.journal"
 pid=2208193 comm="journalctl" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=0
jan 31 11:56:02 marcos audit[2208193]: AVC apparmor="ALLOWED" operation="open" 
profile="/usr/sbin/sshd//null-/usr/bin/bash//null-/usr/bin/screen//null-/usr/bin/bash//null-/usr/bin/journalctl"
 
name="/var/log/journal/3840589866da411b178e07aa001d/system@c4b260b6361649e1819ca8a888938e1d-0d3d0d11-0005f391218d8df8.journal"
 pid=2208193 comm="journalctl" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=0
jan 31 11:56:02 marcos audit[2208193]: AVC apparmor="ALLOWED" operation="open" 
profile="/usr/sbin/sshd//null-/usr/bin/bash//null-/usr/bin/screen//null-/usr/bin/bash//null-/usr/bin/journalctl"
 
name="/var/log/journal/3840589866da411b178e07aa001d/user-1041@3109a3dba85e4c67820c02b55f829e1e-0d1c23b4-0005f36d51aba5d8.journal"
 pid=2208193 comm="journalctl" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=0
jan 31 11:56:02 marcos audit[2208193]: AVC apparmor="ALLOWED" operation="open" 
profile="/usr/sbin/sshd//null-/usr/bin/bash//null-/usr/bin/screen//null-/usr/bin/bash//null-/usr/bin/journalctl"
 
name="/var/log/journal/3840589866da411b178e07aa001d/user-1004@a38efa23684347ef9b31acdaaf262dd8-0d2d8e5d-0005f37ebe1948bb.journal"
 pid=2208193 comm="journalctl" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=0
jan 31 11:56:02 marcos audit[2208193]: AVC apparmor="ALLOWED" operation="open" 
profile="/usr/sbin/sshd//null-/usr/bin/bash//null-/usr/bin/screen//null-/usr/bin/bash//null-/usr/bin/journalctl"
 name="/var/log/journal/3840589866da411b178e07aa001d/user-1046.journal" 
pid=2208193 comm="journalctl" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=0
jan 31 11:56:02 marcos audit[2208193]: AVC apparmor="ALLOWED" operation="open" 
profile="/usr/sbin/sshd//null-/usr/bin/bash//null-/usr/bin/screen//null-/usr/bin/bash//null-/usr/bin/journalctl"
 
name="/var/log/journal/3840589866da411b178e07aa001d/user-1000@783a473ea10e4ba8b524e790c32932d9-0d379eb3-0005f389ebe36e8a.journal"
 pid=2208193 comm="journalctl" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=0
jan 31 11:56:02 marcos audit[2208193]: AVC apparmor="ALLOWED" operation="open" 
profile="/usr/sbin/sshd//null-/usr/bin/bash//null-/usr/bin/screen//null-/usr/bin/bash//null-/usr/bin/journalctl"
 
name="/var/log/journal/3840589866da411b178e07aa001d/user-1004@a38efa23684347ef9b31acdaaf262dd8-0d24946f-0005f37de770b945.journal"
 pid=2208193 comm="journalctl" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=0
jan 31 11:56:02 marcos audit[2208193]: AVC apparmor="ALLOWED" operation="open" 
profile="/usr/sbin/sshd//null-/usr/bin/bash//null-/usr/bin/screen//null-/usr/bin/bash//null-/usr/bin/journalctl"
 
name="/var/log/journal/3840589866da411b178e07aa001d/user-1000@783a473ea10e4ba8b524e790c32932d9-0d38d511-0005f38e27865a08.journal"
 pid=2208193 comm="journalctl" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=0
jan 31 11:56:02 marcos audit[2208193]: AVC apparmor="ALLOWED" operation="open" 
profile="/usr/sbin/sshd//null-/usr/bin/bash//null-/usr/bin/screen//null-/usr/bin/bash//null-/usr/bin/journalctl"
 
name="/var/log/journal/3840589866da411b178e07aa001d/system@c4b260b6361649e1819ca8a888938e1d-0d3a15fc-0005f390ce56bd38.journal"
 pid=2208193 comm="journalctl" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=0

I'm not sure it's journalctl that's at fault here, but I can't really
use it at all anymore. I am not sure either if it's journald triggering
this, or journalctl, but I regularly get this error in dmesg:

[jan31 11:53] systemd-journald[1071826]: Data hash table of 
/var/log/journal/3840589866da411b178e07aa001d/system.journal has a fill 
level at 75.0 (174765 of 233016 items, 67108864 file size, 383 bytes per hash 
table item), suggesting rotation.
[  +0,023450] systemd-journald[1071826]: 
/var/log/journal/3840589866da411b178e07aa001d/system.journal: Journal 
header limits reached or header out-of-date, rotating.

Bug#1030058: nvme output misquoting

[Antoine Beaupre]

Package: prometheus-node-exporter-collectors
Version: 0.0~git20230110.843e550-1
Severity: normal
Tags: upstream

Since the bookworm upgrade, my logs are full of this:

2023-01-30T15:08:02.764677-05:00 marcos prometheus-node-exporter[3724]: 
ts=2023-01-30T20:08:02.764Z caller=textfile.go:227 level=error 
collector=textfile msg="failed to collect textfile data" file=nvme.prom 
err="failed to parse textfile data from 
\"/var/lib/prometheus/node-exporter/nvme.prom\": text format parsing error in 
line 14: expected float as value, got \"\\\"34564\\\"\""

It looks like a JSON transcoding issue, see also: 
https://github.com/prometheus-community/node-exporter-textfile-collector-scripts/issues/130


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (1, 
'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages prometheus-node-exporter-collectors depends on:
ii  moreutils 0.67-1
pn  prometheus-node-exporter  
ii  python3-apt   2.5.2
ii  systemd-sysv  252.4-1

Versions of packages prometheus-node-exporter-collectors recommends:
ii  dbus   1.14.4-1
pn  ipmitool   
ii  jq 1.6-2.1
ii  nvme-cli   2.2.1-4
ii  python33.11.1-1
ii  smartmontools  7.3-1+b1

prometheus-node-exporter-collectors suggests no packages.

Bug#1030039: crashes on startup with "cannot be cast to class schema.core.FnSchema"

[Antoine Beaupre]

Package: puppetserver
Version: 7.9.3-3
Severity: grave

*Something* this weekend broke my Puppetserver. I'm not sure
what. It's now failing to start (repeatedly) with:

jan 29 06:57:07 marcos systemd[1]: Starting Puppet Server...
jan 29 06:57:10 marcos java[1079416]: WARNING: update-vals already refers to: 
#'clojure.core/update-vals in namespace: clojure.tools.analyzer.utils, being 
replaced by: #'clojure.tools.analyzer.utils/update-vals
jan 29 06:57:10 marcos java[1079416]: WARNING: update-keys already refers to: 
#'clojure.core/update-keys in namespace: clojure.tools.analyzer.utils, being 
replaced by: #'clojure.tools.analyzer.utils/update-keys
jan 29 06:57:10 marcos java[1079416]: WARNING: update-vals already refers to: 
#'clojure.core/update-vals in namespace: clojure.tools.analyzer, being replaced 
by: #'clojure.tools.analyzer.utils/update-vals
jan 29 06:57:10 marcos java[1079416]: WARNING: update-keys already refers to: 
#'clojure.core/update-keys in namespace: clojure.tools.analyzer, being replaced 
by: #'clojure.tools.analyzer.utils/update-keys
jan 29 06:57:10 marcos java[1079416]: WARNING: update-vals already refers to: 
#'clojure.core/update-vals in namespace: clojure.tools.analyzer.passes, being 
replaced by: #'clojure.tools.analyzer.utils/update-vals
jan 29 06:57:10 marcos java[1079416]: WARNING: update-vals already refers to: 
#'clojure.core/update-vals in namespace: 
clojure.tools.analyzer.passes.uniquify, being replaced by: 
#'clojure.tools.analyzer.utils/update-vals
jan 29 06:57:12 marcos java[1079416]: WARNING: abs already refers to: 
#'clojure.core/abs in namespace: medley.core, being replaced by: 
#'medley.core/abs
jan 29 06:57:13 marcos java[1079416]: Exception in thread "main" 
java.lang.ClassCastException: class schema.core.FnSchema cannot be cast to 
class schema.core.FnSchema (schema.core.FnSchema is in unnamed module of loader 
clojure.lang.DynamicClassLoader @6af78a48; schema.core.FnSchema is in unnamed 
module of loader 'app')
jan 29 06:57:13 marcos java[1079416]: at 
plumbing.fnk.pfnk$input.invokeStatic(pfnk.cljc:19)
jan 29 06:57:13 marcos java[1079416]: at 
plumbing.fnk.pfnk$input.invoke(pfnk.cljc:18)
jan 29 06:57:13 marcos java[1079416]: at 
clojure.core$juxt$fn__5891.invoke(core.clj:2611)
jan 29 06:57:13 marcos java[1079416]: at 
plumbing.fnk.pfnk$fn__4109.invokeStatic(pfnk.cljc:35)
jan 29 06:57:13 marcos java[1079416]: at 
plumbing.fnk.pfnk$fn__4109.invoke(pfnk.cljc:30)
jan 29 06:57:13 marcos java[1079416]: at 
plumbing.fnk.pfnk$fn__4090$G__4085__4095.invoke(pfnk.cljc:13)
jan 29 06:57:13 marcos java[1079416]: at 
plumbing.fnk.pfnk$input_schema.invokeStatic(pfnk.cljc:38)
jan 29 06:57:13 marcos java[1079416]: at 
plumbing.fnk.pfnk$input_schema.invoke(pfnk.cljc:37)
jan 29 06:57:13 marcos java[1079416]: at 
plumbing.fnk.pfnk$input_schema_keys.invokeStatic(pfnk.cljc:44)
jan 29 06:57:13 marcos java[1079416]: at 
plumbing.fnk.pfnk$input_schema_keys.invoke(pfnk.cljc:43)
jan 29 06:57:13 marcos java[1079416]: at 
plumbing.core$map_vals$fn__4262.invoke(core.cljc:50)
jan 29 06:57:13 marcos java[1079416]: at 
clojure.lang.PersistentHashMap$NodeSeq.kvreduce(PersistentHashMap.java:1307)
jan 29 06:57:13 marcos java[1079416]: at 
clojure.lang.PersistentHashMap$BitmapIndexedNode.kvreduce(PersistentHashMap.java:802)
jan 29 06:57:13 marcos java[1079416]: at 
clojure.lang.PersistentHashMap$ArrayNode.kvreduce(PersistentHashMap.java:466)
jan 29 06:57:13 marcos java[1079416]: at 
clojure.lang.PersistentHashMap.kvreduce(PersistentHashMap.java:236)
jan 29 06:57:13 marcos java[1079416]: at 
clojure.core$fn__8525.invokeStatic(core.clj:6908)
jan 29 06:57:13 marcos java[1079416]: at 
clojure.core$fn__8525.invoke(core.clj:6888)
jan 29 06:57:13 marcos java[1079416]: at 
clojure.core.protocols$fn__8257$G__8252__8266.invoke(protocols.clj:175)
jan 29 06:57:13 marcos java[1079416]: at 
clojure.core$reduce_kv.invokeStatic(core.clj:6919)
jan 29 06:57:13 marcos java[1079416]: at 
clojure.core$reduce_kv.invoke(core.clj:6910)
jan 29 06:57:13 marcos java[1079416]: at 
plumbing.core$map_vals.invokeStatic(core.cljc:50)
jan 29 06:57:13 marcos java[1079416]: at 
plumbing.core$map_vals.invoke(core.cljc:43)
jan 29 06:57:13 marcos java[1079416]: at 
plumbing.graph$__GT_graph.invokeStatic(graph.cljc:64)
jan 29 06:57:13 marcos java[1079416]: at 
plumbing.graph$__GT_graph.invoke(graph.cljc:47)
jan 29 06:57:13 marcos java[1079416]: at 
plumbing.graph$eager_compile$eager_compile__5949.invoke(graph.cljc:148)
jan 29 06:57:13 marcos java[1079416]: at 
plumbing.graph$eager_compile.invokeStatic(graph.cljc:155)
jan 29 06:57:13 marcos java[1079416]: at 
plumbing.graph$eager_compile.invoke(graph.cljc:130)
jan 29 06:57:13 marcos java[1079416]: at 
plumbing.graph$eager_compile.invokeStatic(graph.cljc:141)
jan 29 

Bug#1030006: new upstream release (10.2.1)

[Antoine Beaupre]

Package: linkchecker
Version: 10.1.0-1
Severity: normal

I've been trying to figure out how to upgrade the Debian package to
the latest upstream, but got stopped along the way. Here's my attempt
to document the current status.

The upstream has changed quite a bit since the last debian
update... They dropped the setuptools dependency and now use
hatchling. That in itself is not a problem except they *also* use the
hatchling-vcs package...

So I'm stuck there right now. I pushed my stuff on the `experimental`
branch on salsa. I think the quickest fix here would be to have some
tweak to bypass the -vcs plugin in hatchling so that it uses the
version number from debian/changelog, just like we have an override
for setuptools_scm... but then that was actually packaged.

So maybe the quickest fix would be to patch out hatchling and hardcode
the version check somehow...

Or we just package hatchling-vcs. There might be other stumbling
blocks ahead as well, the debian package is not in great shape, in
general.

But I've also not checked the upstream changelog very well, it needs
another glance.


-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'testing'), (500, 'stable'), (1, 
'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linkchecker depends on:
ii  python3 3.10.6-3+b1
ii  python3-bs4 4.11.1-3
ii  python3-dnspython   2.2.1-2
ii  python3-importlib-metadata  4.12.0-1
ii  python3-requests2.28.1+dfsg-1
ii  python3-urllib3 1.26.12-1
ii  python3-xdg 0.28-2

linkchecker recommends no packages.

Versions of packages linkchecker suggests:
pn  clamav-daemon
pn  linkchecker-web  
ii  python3-argcomplete  2.0.0-1
pn  python3-cssutils 
pn  python3-gconf
ii  python3-geoip1.3.2-6+b1
pn  python3-meliae   

-- no debconf information

Bug#1030005: O: slop -- queries for a selection from the user and prints the region to stdout

[Antoine Beaupre]

Package: wnpp
Severity: normal
X-Debbugs-Cc: s...@packages.debian.org, p...@trickod.com
Control: affects -1 + src:slop

I intend to orphan the slop package.

I am not using X11 anymore, and can't keep up on maintaining those
two... It's best for someone to pickup both slop and maim at once, if
possible. Maintainer of the maim package in CC.

(Patrick, by the way, I am going to remove myself from uploaders, but
I'm happy to sponsor future uploads if you need such a thing and you
can't find another sponsor. I recommend you adopt slop as well, let me
know if you need guidance on that front...)

The package description is:
 slop (Select Operation) is an application that queries for a
 selection from the user and prints the region to stdout. It grabs the
 mouse and turns it into a crosshair, lets the user click and drag to
 make a selection (or click on a window) while drawing a pretty box
 around it, then finally prints the selection's dimensions to stdout.
 .
 Features:
 .
  * Hovering over a window will cause a selection rectangle to appear
over it.
  * Clicking on a window makes slop return the dimensions of the
window.
  * Clicking and dragging causes a selection rectangle to appear,
renders pretty well (compared to scrot). And will return the
dimensions of that rectangle in absolute screen coords.
  * On startup it turns your cursor into a crosshair, then adjusts the
cursor into angles as you drag the selection rectangle.
  * Supports simple arguments:
* Change selection rectangle border size.
* Select X display.
* Set padding size, even negative padding sizes!
* Set click tolerance for if you have a shaky mouse.
* Set the color of the selection rectangles to match your theme!
  (Even supports transparency!)
  * Remove window decorations from selections.
  * Supports OpenGL hardware acceleration.
  * Supports textured themes.
  * Supports programmable shaders.
  * Supports a magnifying glass.

Bug#1030003: O: xininfo -- small helper program for monitor layouts

[Antoine Beaupre]

Package: wnpp
Severity: normal
X-Debbugs-Cc: xini...@packages.debian.org
Control: affects -1 + src:xininfo

I intend to orphan the xininfo package.

The package description is:
 xininfo is an X11 utility to query the current layout and size of
 each configured monitor. It is designed to be used by scripts.

I had planned to use this alongside rofi for teiler, according to
#842975. But I never got around to packaging teiler either
(#842977), and now I use something else entirely for screenshots
(basically maim and slop).

And in fact I don't even use maim and slop either anymore, as I
switched to Wayland. But that's a different story best told
elsewhere...

(... like: https://anarc.at/software/desktop/wayland/)

Bug#1015888: pypi2deb: py2dsp fails with "KeyError: 'releases'"

[Antoine Beaupre]

Package: pypi2deb
Version: 3.20220721
Followup-For: Bug #1015888

This is still a problem in bookworm, and makes me wonder if this bug
should not be release-critical, as it makes the whole thing here
pretty useless...

... although if you can fetch the sdist yourself, you can still use
this to build a package, so not all is lost I guess... if anything, it
forces you to make that extra verification step. ;)

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (1, 
'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pypi2deb depends on:
ii  build-essential  12.9
ii  devscripts   2.22.2
ii  dh-python5.20230109
ii  python3  3.10.6-3+b1
ii  python3-aiohttp  3.8.3-1+b1
ii  python3-debian   0.1.49
ii  python3-github   1.55-3
ii  python3-jinja2   3.0.3-2
ii  python3-redis4.3.4-3

Versions of packages pypi2deb recommends:
ii  python3-msgpack  1.0.3-2

Versions of packages pypi2deb suggests:
pn  cython  
ii  cython3 0.29.32-2
ii  pypy7.3.9+dfsg-1+b1
pn  python-all-dev  
pn  python-nose 
pn  python-pytest   
pn  python-setuptools   
ii  python3-all-dev 3.10.6-3+b1
ii  python3-nose1.3.7-9
ii  python3-pytest  7.2.1-1
ii  python3-setuptools  65.6.3-1
ii  python3-sphinx  5.3.0-3

-- debconf-show failed

Bug#1029569: fails to estimate: cannot find package "github.com/hashicorp/hcl/hcl/printer"

[Antoine Beaupre]

Package: dh-make-golang
Version: 0.6.0-2+b1
Severity: normal

I'm getting this while trying to do an estimate for #969482:

anarcat@curie:dist$ dh-make-golang estimate gitlab.com/gitlab-org/cli
go get: 258.03 MiBpackage gitlab.com/gitlab-org/cli/cmd/gen-docs: cannot find 
package "github.com/hashicorp/hcl/hcl/printer" in any of:
/usr/lib/go-1.19/src/github.com/hashicorp/hcl/hcl/printer (from $GOROOT)
/tmp/dh-make-golang2745715808/src/github.com/hashicorp/hcl/hcl/printer 
(from $GOPATH)
2023/01/24 12:14:11 estimate: go get: exit status 1
anarcat@curie:dist[1]$ 

I'm not sure what's going on here, maybe the import path is a little
weird (the hcl/printer subpath?) and is confusing
dh-make-golang... But in any case, it seems to me it shouldn't fail
outright and just mark that dependency as an unknown for manual
inspection...


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (1, 
'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dh-make-golang depends on:
ii  git   1:2.39.0-1
ii  git-buildpackage  0.9.30
ii  golang-any2:1.19~1
ii  libc6 2.36-8
ii  pristine-tar  1.50

Versions of packages dh-make-golang recommends:
ii  golang-golang-x-tools   1:0.2.0+ds-2
ii  postfix [mail-transport-agent]  3.7.3-4

dh-make-golang suggests no packages.

-- no debconf information

Bug#1024326: bullseye to bookworm upgrade failure: Could not locate dkms.conf file

[Antoine Beaupre]

Package: zfs-dkms
Version: 2.1.6-3
Severity: serious

I have tried to upgrade to bookworm today and kernel builds fail on
zfs-dkms. It fails with:

dkms: running auto installation service for kernel 6.0.0-4-amd64:Error! Could 
not locate dkms.conf file.
File: /var/lib/dkms/zfs/2.0.3/source/dkms.conf does not exist.

It's odd because zfs 2.0.3 is gone now... The package has been
upgraded at this point... Yet the /var/lib/dkms/zfs/2.0.3 directory
was still around. Removing it fixes the problem:

rm -rf /var/lib/dkms/zfs/2.0.3

Note that I am doing batch upgrades with a special procedure, with
this command:

env DEBIAN_FRONTEND=noninteractive APT_LISTCHANGES_FRONTEND=none 
APT_LISTBUGS_FRONTEND=none UCF_FORCE_CONFFOLD=y \
apt full-upgrade -y -o Dpkg::Options::='--force-confdef' -o 
Dpkg::Options::='--force-confold' &&

... which might have cause the old directory to not be removed.

See this for my upgrade procedure:

https://anarc.at/services/upgrades/bookworm/

More of the error log:

Setting up linux-image-6.0.0-4-amd64 (6.0.8-1) ...
/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 6.0.0-4-amd64:Error! Could 
not locate dkms.conf file.
File: /var/lib/dkms/zfs/2.0.3/source/dkms.conf does not exist.
 failed!
run-parts: /etc/kernel/postinst.d/dkms exited with return code 4
dpkg: error processing package linux-image-6.0.0-4-amd64 (--configure):
 installed linux-image-6.0.0-4-amd64 package post-installation script 
subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of linux-image-amd64:
 linux-image-amd64 depends on linux-image-6.0.0-4-amd64 (= 6.0.8-1); however:
  Package linux-image-6.0.0-4-amd64 is not configured yet.

dpkg: error processing package linux-image-amd64 (--configure):
 dependency problems - leaving unconfigured
Setting up linux-headers-6.0.0-4-amd64 (6.0.8-1) ...
/etc/kernel/header_postinst.d/dkms:
dkms: running auto installation service for kernel 6.0.0-4-amd64:Error! Could 
not locate dkms.conf file.
File: /var/lib/dkms/zfs/2.0.3/source/dkms.conf does not exist.
 failed!
run-parts: /etc/kernel/header_postinst.d/dkms exited with return code 4
Failed to process /etc/kernel/header_postinst.d at 
/var/lib/dpkg/info/linux-headers-6.0.0-4-amd64.postinst line 11.
dpkg: error processing package linux-headers-6.0.0-4-amd64 (--configure):
 installed linux-headers-6.0.0-4-amd64 package post-installation script 
subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of linux-headers-amd64:
 linux-headers-amd64 depends on linux-headers-6.0.0-4-amd64 (= 6.0.8-1); 
however:
  Package linux-headers-6.0.0-4-amd64 is not configured yet.

dpkg: error processing package linux-headers-amd64 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 linux-image-6.0.0-4-amd64
 linux-image-amd64
 linux-headers-6.0.0-4-amd64
 linux-headers-amd64



-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages zfs-dkms depends on:
ii  debconf [debconf-2.0]  1.5.79
pn  dkms   
ii  file   1:5.41-4
ii  libc6-dev [libc-dev]   2.36-4
ii  libpython3-stdlib  3.10.6-1
ii  lsb-release12.0-1
ii  perl   5.36.0-4
ii  python3-distutils  3.10.8-1

Versions of packages zfs-dkms recommends:
ii  linux-libc-dev  6.0.8-1
pn  zfs-zed 
pn  zfsutils-linux  

Versions of packages zfs-dkms suggests:
ii  debhelper  13.10.1

Bug#1024092: thumbnail view doesn't render in Wayland

[Antoine Beaupre]

Package: geeqie
Version: 1:2.0.1-4
Severity: normal

I'm not sure what's happening here, but it seems like Geeqie doesn't
correctly render thumbnails in the left pane under Wayland anymore.

The images just don't show up: they are clickable, and show up on the
right pane, but are basically just white squares.

Here is a screenshot of the problem:

https://paste.anarc.at/publish/2022-11-14-EkB6-ytmKHVUzKkCLJOzZwoQhDrlClzVX_kh4wR_tn8/snap-20221114T125640.png


-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages geeqie depends on:
ii  geeqie-common1:2.0.1-4
ii  libarchive13 3.6.0-1
ii  libc62.36-4
ii  libcairo21.16.0-6
ii  libdjvulibre21   3.5.28-2
ii  libexiv2-27  0.27.5-4
ii  libffmpegthumbnailer4v5  2.2.2+git20220218+dfsg-1+b1
ii  libgcc-s112.2.0-9
ii  libgdk-pixbuf-2.0-0  2.42.9+dfsg-1
ii  libglib2.0-0 2.74.1-2
ii  libgspell-1-21.12.0-1+b1
ii  libgtk-3-0   3.24.34-3
ii  libheif1 1.13.0-1
ii  libjpeg62-turbo  1:2.1.2-1+b1
ii  liblcms2-2   2.13.1-1+b1
ii  liblua5.3-0  5.3.6-1+b1
ii  libopenjp2-7 2.5.0-1
ii  libpango-1.0-0   1.50.10+ds-1
ii  libpangocairo-1.0-0  1.50.10+ds-1
ii  libpoppler-glib8 22.08.0-2.1
ii  libraw20 0.20.2-2+b1
ii  libstdc++6   12.2.0-9
ii  libtiff5 4.4.0-5+b1
ii  libwebp7 1.2.2-2+b2
ii  sensible-utils   0.0.17

Versions of packages geeqie recommends:
ii  cups-bsd [lpr]   2.4.2-1+b2
ii  exiftran 2.10-4
ii  exiv20.27.5-4
ii  imagemagick  8:6.9.11.60+dfsg-1.3+b4
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3+b4
ii  librsvg2-common  2.54.5+dfsg-1
ii  zenity   3.43.0-1

Versions of packages geeqie suggests:
ii  gimp 2.10.32-1+b2
ii  libjpeg-turbo-progs [libjpeg-progs]  1:2.1.2-1+b1
pn  xpaint   

-- no debconf information

Bug#1023749: RFP: snac2 -- simple, minimalistic ActivityPub instance

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: snac2
  Version : 2.0.9
  Upstream Author : https://codeberg.org/grunfink
* URL : https://codeberg.org/grunfink/snac2/
* License : MIT
  Programming Lang: C
  Description : simple, minimalistic ActivityPub instance

This program runs as a daemon (proxied by a TLS-enabled real httpd
server) and provides the basic services for a Fediverse / ActivityPub
instance (sharing messages and stuff from/to other systems like
Mastodon, Pleroma, Friendica, etc.).

Features:

 * Lightweight, minimal dependencies
 * Extensive support of ActivityPub operations, e.g. write public
   notes, follow users, be followed, reply to the notes of others,
   admire wonderful content (like or boost), write private
   messages...
 * Simple but effective web interface
 * Easily-accessed MUTE button to silence morons
 * Tested interoperability with similar software
 * No database needed
 * Not much bullshit



There is currently no actual Mastodon/ActivityPub *server* in
Debian. There's an effort to package the reference Mastodon server in
#859741 but that seems stuck in Ruby dependency hell right now, and is
likely to prove difficult to maintain in the long term unless upstream
calms down a bit... and that's unlikely to happen given that Musk has
basically took over Twitter and ran it to the ground as fast as he
could. But I digress.

snac2 is a much simpler implementation. It's written in C, which might
not be everyone's favorite language right now, but it's something that
could be *much* easier to package than Ruby or Rust, or whaver is that
other implementation you're currently thinking of right now.

So maybe this would be a good and easier way to server our users,
thirsty for some federation action.

https://sr.ht/~tsileo/microblog.pub is another option, but even
smaller: it's a single user server.

Bug#1022903: systemd unit fails by default

[Antoine Beaupre]

Package: soundmodem
Version: 0.20-6+b1
Severity: normal

On a newly installed system, the systemd unit fails with this:

oct 06 12:15:58 angela systemd[1]: Starting Soundmodem systemD service file to 
fix device permissions...
oct 06 12:15:58 angela soundmodem[2069]: Configuartion not found
oct 06 12:15:58 angela soundmodem[2063]: SoundModem init failed
oct 06 12:15:58 angela systemd[1]: soundmodem.service: Control process exited, 
code=exited, status=1/FAILURE
oct 06 12:15:58 angela systemd[1]: soundmodem.service: Failed with result 
'exit-code'.
oct 06 12:15:58 angela systemd[1]: Failed to start Soundmodem systemD service 
file to fix device permissions.

... this marks the whole system as "degraded" which is really kind of
inaccurate, because the system is actually perfectly functional;
soundmodem is just not configured yet.

I can think of two ways of fixing this:

 1. add a condition in the systemd unit so that it doesn't try to
 start the service when it's unconfigured

 2. add a sample config file so that the service *does* start by
 default

I would favor the former. I think it needs a ConditionPathExists=
entry in the [Unit] section of the service file. I'm not sure which
actual config file we're talking about anymore though, but I figured I
would just mention it. :)


-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages soundmodem depends on:
ii  libasound2   1.2.7.2-1
ii  libatk1.0-0  2.46.0-3
ii  libaudiofile10.3.6-5+b1
ii  libc62.35-3
ii  libgdk-pixbuf-2.0-0  2.42.9+dfsg-1
ii  libglib2.0-0 2.74.0-3
ii  libgtk2.0-0  2.24.33-2
ii  libhamlib4   4.3.1-1+b3
ii  libpango-1.0-0   1.50.10+ds-1
ii  libxml2  2.9.14+dfsg-1+b1

soundmodem recommends no packages.

soundmodem suggests no packages.

-- no debconf information

Bug#1022724: systemd restarts prometheus forever, leading to disk usage death spiral

[Antoine Beaupre]

Package: prometheus
Version: 2.24.1+ds-1+b7
Severity: important

In the systemd unit provided by this Debian package (in
`debian/service`), we have this:

[Service]
Restart=on-failure

This makes it so that systemd will try to restart prometheus if it
exits for whatever reason other than exit code 0. This may be nice:
you may want it to retry if it crashes or something.

But I had a situation where I mistakenly pushed a broken config
(broken rules, more accurately) to prometheus. The gory details are in
this incident report:

https://gitlab.torproject.org/tpo/tpa/team/-/issues/40939

... but the gist of it is that systemd repeatedly tried to restart the
service and failed. And retried, and retried... this would fill the
disk not only with logs of those attempts, but it would also grow the
WAL every time (which is a separate issue).

(Normally, prometheus fails to start and doesn't mess with its data if
the config file is broken, since 2.20:

https://github.com/prometheus/prometheus/pull/7399

... but it seems this to be a courtesy that is not extended to
rules. will file an upstream bug on that one.)

Anyways, point is maybe we shouldn't restart so aggressively. Maybe
`Restart=on-abnormal` or `Restart=on-abort` would be better? That way
systemd wouldn't try to restart prometheus on syntax errors, and
correctly fail instead of retrying the service forever.

For now, I added a local override (`Restart=no`) to get through my
day, but I'd be happy to have a discussion on the best way to deal
with this.

(I first considered limiting the number of retries to something more
decent than the current "infinity", but there isn't a setting directly
for that in systemd. There *are* things like
`StartLimitIntervalSec=interval` and `StartLimitBurst=burst` but those
were not triggered by my incident, because prometheus would take about
3 seconds to startup, which is above the default 5 restarts in 10
seconds default. So maybe that's another way to fix this, ie. raise
the StartLimitIntervalSec (to, say 30 seconds) or lower the
StartLimitBurst.)

Either way, I think we can expect prometheus to return proper exit
statuses and, in those case *not* restart prometheus, so I would
propose `Restart=on-abort` instead of the `on-failure`.

(Interestingly, the Restart=on-failure was introduced explicitly to
handle situations like this:

https://salsa.debian.org/go-team/packages/prometheus/-/commit/1a61bbb194

Excerpt:

> Subject: Change systemd service Restart directive from always to on-failure
> 
> The always value is unusual, as it ignores successful exits. The
> prometheus daemon can also be requested to exit from its API, that
> should be honored.

... but it didn't take into account non-transient failures like
configuration errors.)

I'll probably followup with a MR on the package as well.

-- System Information:
Debian Release: 11.5
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-19-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages prometheus depends on:
ii  adduser  3.118
ii  fonts-glyphicons-halflings   1.009~3.4.1+dfsg-2
ii  init-system-helpers  1.60
ii  libc62.31-13+deb11u4
pn  libjs-bootstrap4 
pn  libjs-eonasdan-bootstrap-datetimepicker  
ii  libjs-jquery 3.5.1+dfsg+~3.5.5-7
ii  libjs-jquery-hotkeys 0~20130707+git2d51e3a9+dfsg-2.1
pn  libjs-moment 
pn  libjs-moment-timezone
pn  libjs-mustache   
pn  libjs-popper.js  
pn  libjs-rickshaw   

Versions of packages prometheus recommends:
pn  prometheus-node-exporter  

prometheus suggests no packages.

Bug#1021954: RFP: git-xl -- git diff extension for Excel spreadsheets

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org

* Package name: git-xl
  Version : 0.5.1
  Upstream Author : https://github.com/xlwings
* URL : https://www.xltrail.com/git-xl
* License : MIT
  Programming Lang: Python
  Description : git diff extension for Excel spreadsheets

Git XL is an open-source Git command line extension for managing Excel
workbook files in Git.

The extension makes git diff work for Excel VBA (xls, xlt, xla, xlam,
xlsx, xlsm, xlsb, xltx, xltm). Git XL does not require Excel as it
works directly on the workbook file.

With Git XL installed, Git can diff Excel VBA just like any other
source code file.



Git XL was previously called "git-xltrail". Possibly depends on the
xlwings library:

https://github.com/xlwings/xlwings

... which is an opencore thing, but might work well enough for most
use cases (e.g. not for cloud documents) in the opensource version.

Bug#1021409: RFP: fw-ectool -- Framework laptop embedded controller tool

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: fw-ectool
  Version : none
  Upstream Author : https://frame.work/
* URL : https://github.com/FrameworkComputer/EmbeddedController
* License : BSD-3 clause
  Programming Lang: C
  Description : Framework laptop embedded controller tool

The fw-ectool binary provides users with ways of interacting with
the embedded controller in their laptop. This could mean something as
fancy as changing LED colors:

ectool led left blue

or more critical as limiting charge percentages:

ectool fwchargelimit 80

The actual repository above contains the *entire* embedded controller
source code, but the actual binary I'm interested in is only inside
the `util` directory. Apparently:

https://www.howett.net/posts/2021-12-framework-ec/#using-fw-ectool

... the way to get the binary is with:

make utils

inside said repository.

I'm not sure we want to ship the entirety of this source code in
Debian, however, so I'm looking for advice on how to manage this. In
particular, I understand that the framework EC is based on the
Chromebook EC, so it's technically a fork. And therefore the ectool
here *could* be used (or not?) on a chromebook as well. I'm not sure.

Ideally, that tool would be split out in a different source repository
and could interoperate with different ECs out there, but this is not
the hand we have been given yet.

I am not aware of a similar tool in Debian, but would very welcome
other advice on this.

Thanks!

Bug#1021396: ITP: batterylog -- laptop battery logging tool

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: batterylog
  Version : none
  Upstream Author : Leonard Lin
* URL : https://github.com/lhl/batterylog
* License : GPLv3
  Programming Lang: Python
  Description : laptop battery logging tool

A simple Python app with few dependencies that reads your
sysfs-class-power numbers and records them to a local sqlite3 db with
an "event" tag.

It was built to track suspend power usage for Framework laptops, but
is flexible/easily extensible to do all kinds of other stuff.



This is similar to the already packaged battery-stats, but is a little
more explicit in its output. While battery-stats keeps a text and CSV
log, batterylog stores its entries in a SQLite database.

battery-stats stores new entries every minute, in cron, while
batterylog does it on systemd triggers (like sleep/resume). It could,
in theory, do exactly the same as battery-stats and run in a cron job,
but those are triggers installed by default upstream.

They both keep different records in each entry. battery-stats keep the
charge status (charging/discharging), manufacturer, battery type and
identifier, while batterylog keeps voltages.

both ship similarly-named binaries, battery-stats ships battery-log,
and batterylog ships... batterylog.

batterylog is a single script, ~130 lines of python, quite readable,
while battery-stats is a mix of shell and python, spread over multiple
files.

batterlog was started a few months ago, and is the work of a single
maintainer. batterystats has been around since 2013 and has seen half
a dozen contributors (including myself).

batterystats can generate graphs, and, really, all batterylog
currently does is this:

$ /opt/batterylog/batterylog
Slept for 8.72 hours
Used 6.10 Wh, an average rate of 0.70 W
For your 53.67 Wh battery this is 1.30%/hr or 31.29%/day

But it's surprisingly useful in trying to tune battery life,
especially during suspend.

Bug#1021202: RM: puppet -- ROM; EOL upstream

[Antoine Beaupre]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-puppet-de...@alioth-lists.debian.net

Hi,

We've had many discussions about this in the past, but it seems the
time has come to remove src:puppet from Debian.

The 5.5 Puppet agent and "puppetmaster" code that is shipped by this
package has been EOL for almost two years now[1]. It is broken by the
Ruby 3.0 upgrade in Debian[2], and, generally, is just mostly dead code.

Multiple RC bugs have just kicked it out of testing:

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950182
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009643

We have been working on repackaging everything from scratch. Puppet
agent 7 has landed in unstable yesterday[3] and we're still trying to
figure out how to package the Puppet Server 7 code base. This is
currently blocked on jruby things, but we are confident this can be
solved before the bookworm freeze.

Therefore, we hope to ship Puppet Agent and Server 7 in bookworm. The
src:puppet codebase is just one of the blockers we have of course, but
it's a blocker and should therefore be removed from Debian for now.

Details and progress of our work can be seen here:

https://wiki.debian.org/Teams/Puppet/Work

A.

[3] 
https://tracker.debian.org/news/1368401/accepted-puppet-agent-7160-3-source-into-unstable/

Bug#1020710: RFP: flycheck-grammalecte -- Adds support for Grammalecte (a french grammar checker) to flycheck.

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-emac...@lists.debian.org

* Package name: flycheck-grammalecte
  Version : 2.1
  Upstream Author : Étienne Deparis 
* URL : https://git.umaneti.net/flycheck-grammalecte/about/
* License : GPLv3
  Programming Lang: Elisp
  Description : Integrate Grammalecte with Flycheck

Integrate the french grammar and typography checker Grammalecte with
flycheck to automatically look for mistakes in your writings. It also
provides an easy way to find synonyms and antonyms for a given word
(to avoid repetitions for exemple). This package is of very little
interest for other languages.



I've been forcing myself to write in french this week (!) and I found
out I got really bad at it. A friend told me they found a metric ton
of mistakes grammalecte could easily pick up, which is even worse. But
at least it's there.

Now I don't really want to copy-paste stuff between Emacs and
LibreOffice. In fact, I would be much happier never ever starting
LibreOffice at all, but that's another story.

Point is: there's a plugin for this, and it's flycheck-grammalecte,
and we should have this fantastic thing in Debian now that Grammalecte
itself is.

Bug#1019503: postgresql-13: memory leak with JIT compilation

[Antoine Beaupre]

Package: postgresql-13
Version: 13.7-0+deb11u1
Severity: important

We have found severe regressions when upgrading from bookworm to
bullseye on two of our PostgreSQL servers.

It seems like, in busy workloads, the JIT actually leaks memory. Like
a lot. In this screenshot of a yearly Grafana dashboard, you can see
memory usage is fairly regular until the upgrade (early May) at which
point the server starts regularly swapping and eventually OOM'ing:

https://gitlab.torproject.org/tpo/tpa/team/uploads/41f8850ecc4b4170f56901b4018a9870/image.png

The internal ticket we filed about this has all the gory details,
which are probably too much for this bug report:

https://gitlab.torproject.org/tpo/tpa/team/-/issues/40815

We also had issues on other servers, more examples:

https://gitlab.torproject.org/tpo/tpa/team/-/issues/40814

While this may seem like a one-off thing that affects only certain
workloads — we certainly have other PostgreSQL that do not suffer from
this problem — when it *does* affect the workload, it's pretty
catastrophic. Hence the "important" severity ("major effect on the
usability of a package, without rendering it completely unusable to
everyone").

Also, it took us a long time to track down this problem... it's
basically only because of the release notes of an unrelated project
(PuppetDB) happened to feature a similar bug report that we were
hinted this could be a problem:

https://tickets.puppetlabs.com/browse/PDB-5452

... which makes me think this problem might be more widespread than a
few workloads. It seems like DSA also had problems with the upgrade on
the sources.debian.org server which, granted, is a huge server as
well, but I don't see why that should necessarily be a problem with
PostgreSQL...

Past PostgreSQL upgrades have been basically without flaw for us: the
procedure is a little disruptive (e.g. dump/restore, basically) but
apart from that, we have never seen such a huge regression in
performance. So I figured it was worth at least a bug report.

I'm not sure what should come out of this; I can't help but think this
is a bug in the JIT, but it's far beyond my capacity to even start
debugging this specifically. So maybe this could be forwarded
upstream? But in the meantime, maybe this could be fixed "simply" by
adding a note to the Debian bullseye release notes.

One should also see if this behavior also occurs in newer releases: we
briefly considered upgrading to 14 to see if this was still happening,
before finding the JIT trick, but have not done so (yet?).

Thank you for your attention,

a.

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-17-amd64 (SMP w/2 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages postgresql-13 depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libc6  2.31-13+deb11u3
ii  libgcc-s1  10.2.1-6
ii  libgssapi-krb5-2   1.18.3-6+deb11u1
ii  libicu67   67.1-7
ii  libldap-2.4-2  2.4.57+dfsg-3+deb11u1
ii  libllvm11  1:11.0.1-2
ii  libpam0g   1.4.0-9+deb11u1
ii  libpq5 13.7-0+deb11u1
ii  libselinux13.1-3
ii  libssl1.1  1.1.1n-0+deb11u3
ii  libstdc++6 10.2.1-6
ii  libsystemd0247.3-7
ii  libuuid1   2.36.1-8+deb11u1
ii  libxml22.9.10+dfsg-6.7+deb11u2
ii  libxslt1.1 1.1.34-4+deb11u1
ii  locales2.31-13+deb11u3
ii  locales-all2.31-13+deb11u3
ii  postgresql-client-13   13.7-0+deb11u1
ii  postgresql-common  225
ii  ssl-cert   1.1.0+nmu1
ii  tzdata 2021a-1+deb11u5
ii  zlib1g 1:1.2.11.dfsg-2+deb11u2

Versions of packages postgresql-13 recommends:
pn  sysstat  

postgresql-13 suggests no packages.

-- debconf information:
  postgresql-13/postrm_purge_data: true

Bug#1018899: gcr-prompter dumps secrets in syslog/journald

[Antoine Beaupre]

Package: gcr
Version: 3.41.1-1
Severity: important

It looks like some secrets are leaking from the gcr program into my
system logs. I see this when GnuPG triggers a password prompt:

sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: received BeginPrompting call from 
callback /org/gnome/keyring/Prompt/p0@:1.40
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: preparing a prompt for callback 
/org/gnome/keyring/Prompt/p0@:1.40
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: creating new GcrPromptDialog 
prompt
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: automatically selecting secret 
exchange protocol
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: generating public key
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: beginning the secret exchange: 
[sx-aes-1]\npublic=[REDACTED]\n
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: calling the PromptReady method on 
/org/gnome/keyring/Prompt/p0@:1.40
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: returned from the PromptReady 
method on /org/gnome/keyring/Prompt/p0@:1.40
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: received PerformPrompt call from 
callback /org/gnome/keyring/Prompt/p0@:1.40
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: stopping prompting for operation 
/org/gnome/keyring/Prompt/p0@:1.40
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: closing the prompt
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: stopping prompting for operation 
/org/gnome/keyring/Prompt/p0@:1.40
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: couldn't find the callback for 
prompting operation /org/gnome/keyring/Prompt/p0@:1.40
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: stopping prompting for operation 
/org/gnome/keyring/Prompt/p0@:1.40
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: couldn't find the callback for 
prompting operation /org/gnome/keyring/Prompt/p0@:1.40
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: stopping prompting for operation 
/org/gnome/keyring/Prompt/p0@:1.40
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: couldn't find the callback for 
prompting operation /org/gnome/keyring/Prompt/p0@:1.40
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: calling the PromptDone method on 
/org/gnome/keyring/Prompt/p0@:1.40, and ignoring reply
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: received BeginPrompting call from 
callback /org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: preparing a prompt for callback 
/org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: creating new GcrPromptDialog 
prompt
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: automatically selecting secret 
exchange protocol
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: generating public key
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: beginning the secret exchange: 
[sx-aes-1]\npublic=[REDACTED]\n
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: calling the PromptReady method on 
/org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: returned from the PromptReady 
method on /org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: received PerformPrompt call from 
callback /org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: receiving secret exchange: 
[sx-aes-1]\npublic=[REDACTED]\n
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: deriving shared transport key
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: deriving transport key
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: starting password prompt for 
callback /org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:49 emma gcr-prompter[7681]: Gcr: completed password prompt for 
callback :1.42@/org/gnome/keyring/Prompt/p1
sep 01 13:45:49 emma gcr-prompter[7681]: Gcr: encrypting data
sep 01 13:45:49 emma gcr-prompter[7681]: Gcr: sending the secret exchange: 
[sx-aes-1]\npublic=[REDACTED]\n
sep 01 13:45:49 emma gcr-prompter[7681]: Gcr: calling the PromptReady method on 
/org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:49 emma gcr-prompter[7681]: Gcr: returned from the PromptReady 
method on /org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:49 emma gcr-prompter[7681]: Gcr: received PerformPrompt call from 
callback /org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:49 emma gcr-prompter[7681]: Gcr: stopping prompting for operation 
/org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:49 emma gcr-prompter[7681]: Gcr: closing the prompt
sep 01 13:45:49 emma gcr-prompter[7681]: Gcr: stopping prompting for operation 
/org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:49 emma gcr-prompter[7681]: Gcr: couldn't find the callback for 
prompting operation /org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:49 emma gcr-prompter[7681]: Gcr: stopping prompting for operation 
/org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:49 emma gcr-prompter[7681]: Gcr: couldn't find the callback for 
prompting operation /org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:49 emma gcr-prompter[7681]: Gcr: stopping prompting for operation 
/org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:49 emma 

Bug#1018890: ITP: pubpaste -- publish files and clipboard online easily

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: pubpaste
  Version : 0.6
  Upstream Author : Antoine Beaupré 
* URL : https://gitlab.com/anarcat/pubpaste/
* License : AGPL
  Programming Lang: Python
  Description : publish files and clipboard online easily

This tool makes it easy to publish files, clipboards, screenshots, and
photo galleries online with a single command. It's somewhat messy but
it does its job well.

pubpaste is not for novice users: it assumes you have access to an SSH
server and know how to configure a YAML file. It has been written by
and for its author in a fit of egoistical mania (unfortunately typical
for hackers), apologies normal humans out there reading this.

Bug#1015888: pypi2deb: py2dsp fails with "KeyError: 'releases'"

[Antoine Beaupre]

Package: pypi2deb
Version: 2.20180804+nmu1
Followup-For: Bug #1015888

I confirm I also see the problem in bullseye right now, with:

py2dsp pubpaste

The patch suggested here:

https://lists.debian.org/debian-python/2022/07/msg00076.html

does not work either, the program instead fails with:


anarcat@curie:~$ py2dsp -v --application pubpaste
D: py2dsp py2dsp:141: version: 2.20180804
D: py2dsp py2dsp:142: ['/usr/bin/py2dsp', '-v', '--application', 'pubpaste']
D: py2dsp py2dsp:42: args: Namespace(verbose=True, quiet=False, 
root='/home/anarcat/result', clean=False, build=False, application=True, 
distribution='UNRELEASED', revision='0~py2deb', message='converte0~py2deb', 
profile=None, name='pubpaste')
E: py2dsp py2dsp:148: source package not available on PyPI
Traceback (most recent call last):
  File "/usr/bin/py2dsp", line 146, in 
loop.run_until_complete(main(args))
  File "/usr/lib/python3.9/asyncio/base_events.py", line 642, in 
run_until_complete
return future.result()
  File "/usr/bin/py2dsp", line 64, in main
fname = yield from download(name, version=version, destdir=args.root)
  File "/usr/share/pypi2deb/pypi2deb/pypi.py", line 136, in download
raise Exception('source package not available on PyPI')
Exception: source package not available on PyPI

If i first make a `python setup.py sdist` and then run py2dsp on that,
it kind of succeeds (in the sense that it creates a result/ directory
that i can use) but fails to build the source package:

anarcat@curie:pubpaste$ py2dsp dist/pubpaste-0.6.tar.gz
dpkg-buildpackage: info: paquet source pubpaste
dpkg-buildpackage: info: version source 0.5-0~pypi2deb
dpkg-buildpackage: info: distribution source UNRELEASED
dpkg-buildpackage: info: source changé par Antoine Beaupré 
 dpkg-source -I.git -i.git --before-build .
dpkg-source: info: utilisation des options depuis 
pubpaste-0.6/debian/source/options : --extend-diff-ignore=^[^/]+.egg-info/
dpkg-buildpackage: avertissement: création d'un paquet source sans le nettoyer 
préalablement comme demandé ; il peut contenir des fichiers non souhaités
 dpkg-source -I.git -i.git -b .
dpkg-source: info: utilisation des options depuis 
pubpaste-0.6/debian/source/options : --extend-diff-ignore=^[^/]+.egg-info/
dpkg-source: erreur: impossible de construire avec le format source « 3.0 
(quilt) » : pas de tarball de sources amont à 
../pubpaste_0.5.orig.tar.{bz2,gz,lzma,xz}
dpkg-buildpackage: erreur: dpkg-source -I.git -i.git -b . subprocess returned 
exit status 2

Not sure why it thinks I'm on 0.5 there... 

-- System Information:
Debian Release: 11.4
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-17-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pypi2deb depends on:
ii  build-essential  12.9
ii  devscripts   2.21.3+deb11u1
ii  dh-python4.20201102+nmu1
ii  python3  3.9.2-3
ii  python3-aiohttp  3.7.4-1
ii  python3-debian   0.1.39
ii  python3-jinja2   2.11.3-1
ii  python3-redis3.5.3-2

Versions of packages pypi2deb recommends:
ii  python3-msgpack  1.0.0-6+b1

Versions of packages pypi2deb suggests:
pn  cython  
ii  cython3 0.29.21-3+b1
ii  pypy7.3.3+dfsg-2
pn  python-all-dev  
pn  python-nose 
pn  python-pytest   
pn  python-setuptools   
pn  python3-all-dev 
ii  python3-nose1.3.7-7
ii  python3-pytest  7.1.2-2
ii  python3-setuptools  52.0.0-4
ii  python3-sphinx  3.4.3-2

-- debconf-show failed

Bug#1018174: AttributeError exception with --reverse

[Antoine Beaupre]

Package: urlscan
Version: 0.9.5-1
Severity: normal
Control: forwarded -1 https://github.com/firecat53/urlscan/issues/99
Control: fixed -1 0.9.6-1

The `--reverse` option doesn't seem to work at all in bullseye. It
crashes with an exception, regardless of what I throw at it.

ie. this works:

anarcat@curie:~$ urlscan --no-browser < /dev/null > /dev/null
anarcat@curie:~$

This doesn't:

anarcat@curie:~$ urlscan --no-browser --reverse < /dev/null > /dev/null
Traceback (most recent call last):
  File "/usr/bin/urlscan", line 216, in 
main()
  File "/usr/bin/urlscan", line 206, in main
out = urlchoose.URLChooser(urlscan.msgurls(msg),
  File "/usr/lib/python3/dist-packages/urlscan/urlchoose.py", line 226, in 
__init__
self._reverse()
  File "/usr/lib/python3/dist-packages/urlscan/urlchoose.py", line 465, in 
_reverse
fpo = self.top.body.focus_position
AttributeError: 'Padding' object has no attribute 'body'
anarcat@curie:~[1]$

I can also reproduce with an actual input of course:

anarcat@curie:~$ urlscan --no-browser --reverse < /etc/motd > /dev/null
Traceback (most recent call last):
  File "/usr/bin/urlscan", line 216, in 
main()
  File "/usr/bin/urlscan", line 206, in main
out = urlchoose.URLChooser(urlscan.msgurls(msg),
  File "/usr/lib/python3/dist-packages/urlscan/urlchoose.py", line 226, in 
__init__
self._reverse()
  File "/usr/lib/python3/dist-packages/urlscan/urlchoose.py", line 465, in 
_reverse
fpo = self.top.body.focus_position
AttributeError: 'Padding' object has no attribute 'body'
anarcat@curie:~[1]$

It looks like the --reverse option is just completely broken.

It looks like this was reported upstream as:

https://github.com/firecat53/urlscan/issues/99

... and fixed in 0.9.6.

a.

-- System Information:
Debian Release: 11.4
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages urlscan depends on:
ii  python33.9.2-3
ii  python3-urwid  2.1.2-1

Versions of packages urlscan recommends:
ii  libcanberra-gtk3-module  0.30-7

Versions of packages urlscan suggests:
ii  chromium [www-browser] 104.0.5112.101-1~deb11u1
ii  firefox-esr [www-browser]  91.13.0esr-1~deb11u1
ii  lynx [www-browser] 2.9.0dev.6-3~deb11u1
ii  mutt   2.0.5-4.1+deb11u1
ii  neomutt20201127+dfsg.1-1.2
ii  w3m [www-browser]  0.5.3+git20210102-6

-- debconf-show failed

Bug#1018103: ERROR: Unknown command 'lock'

[Antoine Beaupre]

Package: xdg-utils
Version: 1.1.3-4.1
Severity: minor
File: /usr/bin/xdg-screensaver

The xdg-screensaver usage goes like this:

anarcat@curie:~$ xdg-screensaver --help
xdg-screensaver - command line tool for controlling the screensaver

Synopsis

xdg-screensaver suspend WindowID

xdg-screensaver resume WindowID

xdg-screensaver { activate | lock | reset | status }

xdg-screensaver { --help | --manual | --version }

Use 'man xdg-screensaver' or 'xdg-screensaver --manual' for additional info.

Yet the lock command does *not* actually work in bullseye:

anarcat@curie:~$ xdg-screensaver lock
ERROR: Unknown command 'lock'
anarcat@curie:~[4]$

I suspect this is because I fall out of the normal "desktop" scenario:
i use i3 as wm and xss-lock as a screensaver.

looking at the source, it looks like screensaver_xserver() is lacking
a lock() clause. it would suffice to merge it with the activate) case
to fix this bug, I believe. Something like this:

>From 6f2840821c376aa77904e9ee50e6d152186e4a4f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
Date: Thu, 25 Aug 2022 13:35:05 -0400
Subject: [PATCH] add lock support to generic desktop environments

---
 scripts/xdg-screensaver.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/xdg-screensaver.in b/scripts/xdg-screensaver.in
index 06d6667..b412a00 100644
--- a/scripts/xdg-screensaver.in
+++ b/scripts/xdg-screensaver.in
@@ -402,7 +402,7 @@ screensaver_xserver()
 result=$?
 ;;
 
-activate)
+activate|lock)
 xset s activate > /dev/null
 result=$?
 ;;
-- 
2.30.2

Cheers

-- Package-specific info:
Desktop environment: XDG_CURRENT_DESKTOP=

-- System Information:
Debian Release: 11.4
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

xdg-utils depends on no packages.

Versions of packages xdg-utils recommends:
ii  libfile-mimeinfo-perl  0.30-1
ii  libnet-dbus-perl   1.2.0-1+b1
ii  libx11-protocol-perl   0.56-7.1
ii  x11-utils  7.7+5
ii  x11-xserver-utils  7.7+8

xdg-utils suggests no packages.

-- no debconf information

Bug#1018102: idle detection failure

[Antoine Beaupre]

Package: xss-lock
Version: 0.3.0-10+b1
Severity: important

I have xss-lock setup to start xsecurelock automatically after the
delay prescribed by my `xset` configuration.

Basically, I have this in my .config/systemd/user/xset.service:

[Unit]
Description=Miscellaneous settings for X11
PartOf=graphical-session.target

[Service]
# `b off` disables the audible bell
# http://netbuz.org/blog/2011/11/x-bells-and-urgency-hints/
# `s IDLE BLANK` is the screensaver setup
# start after 1 minute idle, then lock in 3 seconds
# the blank timeout corresponds to the dimmer delay
# (XSECURELOCK_BLANK_TIMEOUT) in ~/.xsecurelock.env
ExecStart=/usr/bin/xset b off s 60 3
Type=oneshot
RemainAfterExit=false

[Install]
WantedBy=graphical-session.target

... and this in my .config/systemd/user/xss-lock.service:

[Unit]
Description=xss-lock - use external locker as X screen saver
Documentation=man:xss-lock(1)
PartOf=graphical-session.target
Wants=xset.service
After=xset.service

[Service]
Type=simple
EnvironmentFile=/home/anarcat/.xsecurelock.env
ExecStart=/usr/bin/xss-lock --verbose --transfer-sleep-lock 
--session=${XDG_SESSION_ID} --notifier /usr/libexec/xsecurelock/dimmer -- 
xsecurelock

[Install]
WantedBy=graphical-session.target

In general, this works: on my laptop, right now, the screen correctly
locked after 60 seconds. But on my desktop, right now, the screen does
*not* lock after 60 seconds.

Calling `xset s activate` *does* lock the screen though, so xss-lock
is correctly behaving on that part. I have tried lowering the delay as
well (`xset s 3 3`, wait 3 seconds), no effect: it's as if my session
is not seen as idle by Xorg.

I suspect this is hard to reproduce: I seem to recall this workstation
correctly locking itself, but I'm not sure.

I wonder if I'm missing a key service in my session, or how to debug
the screensaver in Xorg (or if I should just switch to wayland already
anyways... ;)

Thanks for any help you can give me!

-- System Information:
Debian Release: 11.4
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xss-lock depends on:
ii  libc62.31-13+deb11u3
ii  libglib2.0-0 2.66.8-1
ii  libxcb-screensaver0  1.14-3
ii  libxcb-util1 0.4.0-1+b1
ii  libxcb1  1.14-3

xss-lock recommends no packages.

xss-lock suggests no packages.

-- debconf-show failed

Bug#1017921: mpd tries to start on non-interactive sessions

[Antoine Beaupre]

Package: mpd
Version: 0.22.6-1+b1
Severity: minor

Hi!

Here the mpd daemon tries to start whenever *anyone* SSHes into my
home server. I have a system-wide mpd running on that server, yet it
still tries to start the socket service, which means that any systemd
--user session is "degraded". Here's one example:

anarcat@marcos:~$ systemctl list-units --failed
  UNIT LOAD   ACTIVE SUBDESCRIPTION
● mpd.socket   loaded failed failed mpd.socket

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB= The low-level unit activation state, values depend on unit type.
2 loaded units listed.

anarcat@marcos:~$ systemctl --user  status mpd.socket
● mpd.socket
 Loaded: loaded (/home/anarcat/.config/systemd/user/mpd.socket; enabled; 
vendor preset: enabled)
 Active: failed (Result: resources)
   Triggers: ● mpd.service
 Listen: [::]:6600 (Stream)

aoû 18 15:17:04 marcos systemd[1426573]: mpd.socket: Failed with result 
'resources'.
aoû 18 15:17:04 marcos systemd[1426573]: Failed to listen on mpd.socket.
aoû 18 15:30:36 marcos systemd[1430876]: mpd.socket: Failed to create listening 
socket ([::]:6600): Address already in use
aoû 18 15:30:36 marcos systemd[1430876]: mpd.socket: Failed to listen on 
sockets: Address already in use
aoû 18 15:30:36 marcos systemd[1430876]: mpd.socket: Failed with result 
'resources'.
aoû 18 15:30:36 marcos systemd[1430876]: Failed to listen on mpd.socket.

etc.

The .service file also tries to start for some users:

register@marcos:~$ systemctl --user list-units --failed
  UNITLOAD   ACTIVE SUBDESCRIPTION
● mpd.service loaded failed failed Music Player Daemon

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB= The low-level unit activation state, values depend on unit type.
1 loaded units listed.
register@marcos:~$ systemctl --user status mpd.service
● mpd.service - Music Player Daemon
 Loaded: loaded (/usr/lib/systemd/user/mpd.service; enabled; vendor preset: 
enabled)
 Active: failed (Result: exit-code) since Mon 2022-08-22 10:51:21 EDT; 18s 
ago
   Docs: man:mpd(1)
 man:mpd.conf(5)
 file:///usr/share/doc/mpd/html/user.html
Process: 613776 ExecStart=/usr/bin/mpd --no-daemon (code=exited, 
status=1/FAILURE)
   Main PID: 613776 (code=exited, status=1/FAILURE)
CPU: 85ms

Aug 22 10:51:21 marcos systemd[613761]: Starting Music Player Daemon...
Aug 22 10:51:21 marcos mpd[613776]: config_file: config parameter 
"id3v1_encoding" on line 470 is deprecated
Aug 22 10:51:21 marcos mpd[613776]: exception: failed to open log file 
"/var/log/mpd/mpd.log" (config line 39): Permission denied
Aug 22 10:51:21 marcos systemd[613761]: mpd.service: Main process exited, 
code=exited, status=1/FAILURE
Aug 22 10:51:21 marcos systemd[613761]: mpd.service: Failed with result 
'exit-code'.
Aug 22 10:51:21 marcos systemd[613761]: Failed to start Music Player Daemon.

It seems to me mpd should generally not run for any arbitrary user
unless the user explicitly opted in. Maybe make it conditional on the
graphical session, for example?

Other packages fixed this by not enabling the service by default, see
for example #1001147 and this patch:

https://salsa.debian.org/go-team/packages/syncthing/-/commit/890542804f7a358bd36f86bd452845b7bc968cce

Maybe we should consider the same thing here?

-- System Information:
Debian Release: 11.4
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mpd depends on:
ii  adduser   3.118
ii  init-system-helpers   1.60
ii  libadplug-2.3.3-0 2.3.3+dfsg-2
ii  libao41.2.2+20180113-1.1
ii  libasound21.2.4-1.1
ii  libaudiofile1 0.3.6-5
ii  libavahi-client3  0.8-5
ii  libavahi-common3  0.8-5
ii  libavcodec58  7:4.3.4-0+deb11u1
ii  libavformat58 7:4.3.4-0+deb11u1
ii  libavutil56   7:4.3.4-0+deb11u1
ii  libbz2-1.01.0.8-4
ii  libc6 2.31-13+deb11u3
ii  libcdio-cdda2 10.2+2.0.0-1+b2
ii  libcdio-paranoia2 10.2+2.0.0-1+b2
ii  libcdio19 2.1.0-2
ii  libchromaprint1  

Bug#1017805: RFP: viddy -- modern watch command. Time machine and pager

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian...@lists.debian.org

* Package name: viddy
  Version : 0.3.6
  Upstream Author : https://github.com/sachaos
* URL : https://github.com/sachaos/viddy
* License : MIT
  Programming Lang: Golang
  Description : modern watch command. Time machine and pager

 * Basic features of original watch command.
 * Execute command periodically, and display the result.
 * color output.
 * diff highlight.
 * Time machine mode. sunglasses
   * Rewind like video.
   * Go to the past, and back to the future.
 * See output in pager.
 * Vim like keymaps.
 * Search text.
 * Suspend and restart execution.
 * Run command in precise intervals forcibly.
 * Support shell alias
 * Customize keymappings.
 * Customize color.



I just filed a request about pw mentioning this package, so I might as
well document it here. I understand we don't want to package the
entire universe just because it exists, but I've had a few colleagues
just "uh" and "ah" seeing this one, so I am betting someone
will be interested enough in this package to want it in Debian.

Obviously, a similar package to this is the watch command... I also
just filed an ITP for pw ("pipe watcher", #1017804) that is somewhat
similar, but IMHO more powerful.

Bug#1017804: ITP: pw -- interactively filtered pipe watcher

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: pw
  Version : 2
  Upstream Author : Kaz Kylheku
* URL : https://www.kylheku.com/cgit/pw/
* License : BSD-2
  Programming Lang: C
  Description : interactively filtered pipe watcher

pw can monitor anything that produces textual output. tail -f
/var/logfile, tcpdump, strace, ...

pw does not show you everything. Of course, it reads all the data, but
it does that in the background. It continuously pumps lines of input
through a small FIFO buffer. This buffer is sampled, and the sample is
displayed. When that sampling occurs is controlled in various
interactive ways. What goes into the FIFO can be filtered and the
filters can be edited interactively.

With pw you can:

 * Interactively apply and remove filters on-the-fly, without
   interrupting the source.

 * Make recurring patterns in the stream appear to "freeze" on the
   screen, using triggers.

 * Prevent the overwhelming amount of output from a program from
   flooding the terminal, while consuming all of that output so that
   the program isn't blocked. pw can pause its display updates
   entirely.

 * Juggle multiple shell background jobs that produce output, yet
   execute indefinitely without blocking. When pw runs as part of a
   shell background job, it continues to consume input, process
   filters and take snapshots, without displaying anything. When put
   into the foreground again, display resumes.

For instance the command "tcpdump -i  -l | pw" turns
tcpdump into an interactive network monitoring tool in which you can
use the dynamic filtering in pw to select different kinds of packets,
and use the trigger feature to capture certain patterns of
interaction.

pw is like an oscilloscope for text streams. Digital oscilloscopes
sample the signal and pass it through a fifo, which is sampled to the
oscilloscope screen, and can trigger the sampling on certain
conditions in the signal to make waveforms appear to stand still. pw
does something like that for text streams.



I am rather intrigued by this program. It's the sort of "swiss army
knife" kind of tool that kind of makes no sense until you find a
purpose for it. I've been trying to figure out where this tool fits in
my toolbox and, just today, I was trying to find out what this silly
Purism Librem firmware upgrade tool was doing in the background, with
`ps axfu`. But I was having all this garbage out there, and it was
hard to filter things out properly. I might have been able to pull
something out with `watch`, but I think pw might have been better for
this particular case. I'm also quite interested in using it to analyse
logs or packet dumps during attacks or outages.

Another similarly named package, already in Debian (and maintained by
yours truly) is `pv`, the "pipe viewer". But it has a completely
different function; whereas pw shows you the content of the pipe in a
specific way, pv just counts lines or bytes going through it,
specifically without showing you its content.

There is another tool similar to "watch" that overlaps with this a
little bit:

https://github.com/sachaos/viddy

... it's basically the "watch" command with history. It supports
searching (which pw does, and probably better) and going back in
history (which pw does not). I had a hard time finding that package
name again, for what that's worth...

I suspect I could also forget the name `pw` quite quickly, but by
packaging it, I guess I'm more confident I will forget it less. :p
Probably the worst reason to package something ever, but there you go,
that's how I ended up maintaining pv in the first place, so probably
that means.. uh... something good something.

Bug#1017759: RFP: ruby-activerecord-jdbc-adapter -- JRuby's ActiveRecord adapter using JDBC

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-j...@lists.debian.org, debian-r...@lists.debian.org

* Package name: ruby-activerecord-jdbc-adapter
  Version : 1.3.24
  Upstream Author : https://github.com/jruby/
* URL : https://github.com/jruby/activerecord-jdbc-adapter
* License : BSD-2-clause
  Programming Lang: Ruby
  Description : JRuby's ActiveRecord adapter using JDBC

ActiveRecord-JDBC-Adapter (AR-JDBC) is the main database adapter for
Rails' ActiveRecord component that can be used with
JRuby. ActiveRecord-JDBC-Adapter provides full or nearly full support
for: MySQL, PostgreSQL, SQLite3 and MSSQL* (SQLServer).



This seems to be a dependency of the newer ruby-moneta package, see
also #1010286.

Bug#1017744: RFP: solanum -- IRCv3 server designed to be highly scalable

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: solanum
  Version : N/A
  Upstream Author : https://github.com/solanum-ircd
* URL : https://solanum.chat/
* License : GPL-2, but probably a mess
  Programming Lang: C
  Description : IRCv3 server designed to be highly scalable

Solanum is an IRCv3 server designed to be highly scalable. It
implements IRCv3.1 and some parts of IRCv3.2.

It is meant to be used with an IRCv3-capable services implementation
such as Atheme or Anope.



Solanum is the Charybdis fork that has been built, launched, and used
by the Libera.chat folks during the upheaval that ultimately led to
freenode's death. From what I understand the OFTC people are also
involved.

Charybdis has been removed from Debian in #1017344 with the
understanding that it would be replaced by Solanum. Unfortunately, it
doesn't look like the Solanum team is making official releases just
yet.

Bug#1017641: RFP: snappymail -- Simple, modern, lightweight & fast web-based email client

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: pkg-javascript-de...@lists.alioth.debian.org

* Package name: snappymail
  Version : 2.17.2
  Upstream Author : https://github.com/the-djmaze
* URL : https://snappymail.eu/
* License : AGPL-3
  Programming Lang: PHP, Javascript
  Description : Simple, modern, lightweight & fast web-based email client

Simple, modern, lightweight & fast web-based email client.

The drastically upgraded & secured fork of RainLoop Webmail Community
edition.



Rainloop was removed from Debian due to packaging issues (#1006060,
#1001632), and it's unclear if the fork fixes that. The primary goal
of the fork seems to have been to fix a security issue (#1004548),
but also unblock maintenance of the project:

https://github.com/RainLoop/rainloop-webmail/issues/2162

It seems like it would be nice to consider packaging this instead of
rainloop...

Bug#1017477: IPv6 port forwarding fails in bullseye

[Antoine Beaupre]

Package: docker.io
Version: 20.10.5+dfsg1-1+deb11u2
Severity: normal
Tags: ipv6

In bullseye, this doesn't work over IPv6:

docker run --publish 80:80 nginx:latest

... in the sense that this, on the same host, fails:

anarcat@curie:~$ curl -6 -v localhost
*   Trying ::1:80...
* connect to ::1 port 80 failed: Connection refused
* Failed to connect to localhost port 80: Connection refused
* Closing connection 0
curl: (7) Failed to connect to localhost port 80: Connection refused
anarcat@curie:~[7]$

This is actually a known regression in Docker, documented upstream as
introduced some time around 20.10.2 in:

https://github.com/moby/libnetwork/issues/2607

It *looks* like it is fixed in in 20.10.6 which is just one version
short of what we're running. The patch is here:

https://github.com/moby/moby/pull/42205

I have also confirmed the bug is fixed in unstable.

-- System Information:
Debian Release: 11.4
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages docker.io depends on:
ii  adduser  3.118
ii  containerd   1.4.13~ds1-1~deb11u2
ii  init-system-helpers  1.60
ii  iptables 1.8.7-1
ii  libc62.31-13+deb11u3
ii  libdevmapper1.02.1   2:1.02.175-2.1
ii  libsystemd0  247.3-7
ii  lsb-base 11.1.0
ii  runc 1.0.0~rc93+ds1-5+deb11u2
ii  tini 0.19.0-1

Versions of packages docker.io recommends:
ii  apparmor 2.13.6-10
ii  ca-certificates  20210119
ii  cgroupfs-mount   1.4
ii  git  1:2.30.2-1
ii  needrestart  3.5-4+deb11u2
ii  xz-utils 5.2.5-2.1~deb11u1

Versions of packages docker.io suggests:
pn  aufs-tools  
ii  btrfs-progs 5.10.1-2
ii  debootstrap 1.0.123
pn  docker-doc  
ii  e2fsprogs   1.46.2-2
pn  rinse   
pn  rootlesskit 
ii  xfsprogs5.10.0-4
ii  zfsutils-linux  2.0.3-9

-- Configuration Files:
/etc/default/docker changed:
OPTIONS=" -H unix:///var/run/docker.sock --ip-forward=true --iptables=true 
--ip-masq=true -G docker"
TMPDIR="/tmp/"


-- no debconf information

Bug#1017464: do not Depends on a web browser

[Antoine Beaupre]

Package: fish
Severity: normal

In #361713, fish added a hard Depends on `lynx | www-browser`. This is
typically fine on desktop machines, but I hardly see why servers where
you'd possibly want to install fish would need a web browser.

It seems this is because the "help" command relies on HTML
documentation. But power users might not need that command
systematically. At least the dependency is described upstream as
"optional" here:

https://github.com/fish-shell/fish-shell#dependencies

... and it seems like the "help" command actually only need the
manpages system to be operational. Instead, the dependency is now for
the "`fish_config` web configuration tool", which also requires Python
3.5+, apparently.

In any case, it seems like this is a spurious dependency that should
probably be moved to a Recommends.

-- System Information:
Debian Release: 11.4
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fish depends on:
ii  bc 1.07.1-2+b2
ii  bsdextrautils  2.36.1-8+deb11u1
ii  chromium [www-browser] 104.0.5112.79-1~deb11u1
ii  dpkg   1.20.11
ii  firefox-esr [www-browser]  91.12.0esr-1~deb11u1
pn  fish-common
ii  groff-base 1.22.4-6
ii  libc6  2.31-13+deb11u3
ii  libpcre2-32-0  10.36-2
ii  libstdc++6 10.2.1-6
ii  libtinfo6  6.2+20201114-2
ii  lynx [www-browser] 2.9.0dev.6-3~deb11u1
ii  man-db 2.9.4-2
ii  python33.9.2-3
ii  python3-distutils  3.9.2-1
ii  w3m [www-browser]  0.5.3+git20210102-6

Versions of packages fish recommends:
ii  xsel  1.2.0+git9bfc13d.20180109-3

Versions of packages fish suggests:
pn  doc-base  

Bug#1017407: bullseye regression on pass generate: tr: write error: Broken pipe

[Antoine Beaupre]

Package: pass
Version: 1.7.3-2
Severity: normal

Since the bullseye upgrade (at least?), `pass generate` has been
complaining like this:

anarcat@curie:~$ pass generate foo
tr: write error: Broken pipe
tr: write error
[master xx] Add generated password for foo.
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 foo.gpg
The generated password for foo is:
[...]

This is probably because pass uses something like this to generate
passwords. I don't remember exactly what the code is anymore, but it's
the same in spirit:

pwge() {
ENTROPY=${1:-20} # in bytes
# strip possible newlines if output is wrapped and trailing = signs as they 
add nothing to the password's entropy
head -c $ENTROPY /dev/random | base64 | tr -d '\n='
echo
}


... and that code yields the same error.

Oddly, I cannot reproduce this issue anymore, as of this writing. It's
unclear to me what, exactly, is triggering this issue, because I
cannot reproduce it right now. But I've seen it often enough to
warrant a bug report.

I would be ready to bet this is due to entropy gathering. Maybe `tr`
fails when `/dev/random` isn't full enough?

Anyways, this was scary enough to warrant a bug report, in my humble
opinion. Feel free to close if you are more familiar with the issue
and do not witness the problem ever.

-- System Information:
Debian Release: 11.4
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pass depends on:
ii  gnupg  2.2.27-2+deb11u2
ii  tree   1.8.0-1+b1

Versions of packages pass recommends:
ii  git   1:2.30.2-1
ii  qrencode  4.1.1-1
ii  xclip 0.13-2

Versions of packages pass suggests:
ii  libxml-simple-perl  2.25-1
ii  perl5.32.1-4+deb11u2
pn  python  
ii  python3 3.9.2-3
ii  ruby1:2.7+2

-- debconf-show failed

Bug#1015802: RFP: qrcp -- transfer files by qrcode

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian...@lists.debian.org

* Package name: qrcp
  Version : 0.9.1
  Upstream Author : https://github.com/claudiodangelis
* URL : https://github.com/claudiodangelis/qrcp
* License : MIT
  Programming Lang: Golang
  Description : transfer files by qrcode

Transfer files over Wi-Fi from your computer to a mobile device by
scanning a QR code without leaving the terminal.

qrcp binds a web server to the address of your Wi-Fi network interface
on a random port and creates a handler for it. The default handler
serves the content and exits the program when the transfer is
complete. When used to receive files, qrcp serves an upload page and
handles the transfer.

The tool prints a QR code that encodes the text:

http://{address}:{port}/{random_path}

Most QR apps can detect URLs in decoded text and act accordingly
(i.e. open the decoded URL with the default browser), so when the QR
code is scanned the content will begin downloading by the mobile
browser.

It can send and receive files from other devices.



While there are tools that could be duct-taped together to do this in
Debian, there's no one-stop-shop that actually does like this, pretty
neat.

Bug#1015798: RFP: battop -- interactive batteries viewer

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-r...@lists.debian.org

* Package name: battop
  Version : 0.2.4
  Upstream Author : s...@svartalf.info
* URL : https://github.com/svartalf/rust-battop
* License : Apache-2, MIT
  Programming Lang: Rust
  Description : interactive batteries viewer

battop is an interactive viewer, similar to top, htop and other *top
utilities, but about the batteries installed in your notebook.

I am not aware of a similar tool already in Debian, but I might be
mistaken on that.

Bug#1015738: xcb-util-xrm fails to parse resources like *.foo

[Antoine Beaupre]

Package: libxcb-xrm0
Version: 1.0-3+b1
Severity: normal

This is a rather convoluted issue, but bear with me for a minute and
hopefully things will be a little clearer.

I have recently changed themes to use srcery, which basically means I
loaded this Xresources file:

https://github.com/srcery-colors/srcery-terminal/blob/566eb23e7bbf084bb56587a08ba2df6cb65db5a8/xresources/srcery.xresources

Notice the ... particular pattern:

! white
*.color7:   #baa67f
*.color15:  #fce8c3

Normally, that would be something like:

! white
*color7:   #baa67f
*color15:  #fce8c3

... which was fixed in:

https://github.com/srcery-colors/srcery-terminal/commit/96b21803832d00fd816473fd20517d39f9245741

... but, actually, *.foo *is* legal according to the X(7)
specification. The actual quote, if I may, is:

When an application looks for the value of a resource, it specifies
a complete path in the hierarchy, with both class and instance
names. However, resource values are usually given with only
partially specified names and classes, using pattern matching
constructs. An asterisk (*) is a loose binding and is used to
represent any number of intervening components, including none. A
period (.) is a tight binding and is used to separate immediately
adjacent components. A question mark (?) is used to match any single
component name or class. A database entry cannot end in a loose
binding; the final component (which cannot be "?") must be
specified. The lookup algorithm searches the resource database for
the entry that most closely matches (is most specific for) the full
name and class being queried. When more than one database entry
matches the full name and class, precedence rules are used to select
just one.

So this *should* work, but doesn't. This affects any package using the
libxcb-xrm0 which includes, most prominently for me, the i3 window
manager (but there are problem many others).

This bug has been acknowledged upstream:

https://github.com/Airblader/xcb-util-xrm/issues/79

... and fixed over 4 years ago, in a release that was shipped as 1.3
in March 2018:

https://github.com/Airblader/xcb-util-xrm/releases/tag/v1.3

It seems like Debian should probably fix this bug as well, so I'm
filing this here to make sure we have that particularly hairy issue,
which sent me spinning over three different GitHub projects (i3,
xcb-util-frm, and srcery). ;)

More details in:

https://github.com/i3/i3/discussions/5051
https://github.com/srcery-colors/srcery-terminal/pull/164

Thanks!

-- System Information:
Debian Release: 11.3
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-15-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libxcb-xrm0 depends on:
ii  libc6 2.31-13+deb11u3
ii  libxcb-util1  0.4.0-1+b1
ii  libxcb1   1.14-3

libxcb-xrm0 recommends no packages.

libxcb-xrm0 suggests no packages.

-- no debconf information

Bug#1012765: RFP: irssi-plugin-matrix -- Matrix plugin for Irssi

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: irssi-plugin-matrix
  Version : no tag yet
  Upstream Author : https://codeberg.org/ticho/
* URL : https://codeberg.org/ticho/irssi-matrix/
* License : GPL-2
  Programming Lang: C
  Description : Matrix plugin for Irssi

Upstream doesn't have a long description or a readme, but this is
basically a plugin, written in C, to make irssi talk with Matrix home
servers. I don't know what it supports, or how well, but it's the
first of this I've ever seen, so it seems worthwhile to consider
packaging it in Debian.

It seems built on top of glib and matrix-glib, and the latter might
not be packaged in Debian.

The above maintainer seems to also maintain a fork of the latter:

https://codeberg.org/ticho/matrix-glib

a fork of:

https://github.com/gergelypolonkai/matrix-glib-sdk

... so that might complicate things as well.

I haven't tried to build or test this at all.

Bug#1012577: update puppetdb to latest upstream (currently 6.21.0)

[Antoine Beaupre]

Source: puppetdb
Version: 6.2.0-5
Severity: wishlist

We're lagging quite a bit behind upstream, and should update to follow
the latest.

This is a meta-ticket tracking that effort, which should close a bunch
of other issues.


-- System Information:
Debian Release: 11.3
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-14-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1012456: RFP: timescaledb -- time-series SQL database optimized for fast ingest and complex queries

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: team+postgre...@tracker.debian.org

* Package name: timescaledb
  Version : 2.7.0
  Upstream Author : https://github.com/timescale
* URL : https://www.timescale.com/
* License : Apache 2.0
  Programming Lang: C
  Description : time-series SQL database optimized for fast ingest and 
complex queries

TimescaleDB is an database designed to make SQL scalable for
time-series data.  It is engineered up from PostgreSQL and packaged as
a PostgreSQL extension, providing automatic partitioning across time
and space (partitioning key), as well as full SQL support



Before embarking in packaging this, one should probably carefully
review the legal review I have done here:

https://lists.debian.org/debian-legal/2022/06/msg0.html

... and the packaging work guix performed here:

https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/databases.scm?id=ae1d8d6a6f3eb3f705394061be5fcf0efa996870#n1299

They basically remove the entire tsl/ directory and some tests.