Bug#774711: tables of debian openssh crypto features

[Antoine Beaupré]

So it's been a while this bug was discussed, and even more since when it
was opened.

Things have changed, since. SHA-1 has been retired in OpenSSH 7, for
example...

Is this still relevant?

taggart, how did you generate those nice tables, can you make them
again? :)

On 2015-09-10 16:19:21, Matt Taggart wrote:
> I was interested in what crypto features the ssh in each Debian release 
> supported, to see what disabling some would mean, so I gathered the info. 
> Let me know if you see any errors.
>
> Current versions of openssh as of Sept 10, 2015:
>
> | squeeze-lts | 1:5.5p1-6+squeeze6 |
> |wheezy   |  1:6.0p1-4+deb7u2  |
> |jessie   |  1:6.7p1-5 |
> |   stretch   |  1:6.9p1-1 |
> | sid |  1:6.9p1-2 |
>
> Tables of crypto features that the openssh in each release of Debian 
> supports. Gathered with ssh -Q(jessie and newer), ssh_config(5) and 
> source(wheezy and squeeze). (These will look better with a fixed width font)
>
> Key types
> | sq | wh | je | st | si | type |
> =
> | X  | X  | X  | X  | X  | ssh-rsa  |
> | X  | X  | X  | X  | X  | ssh-dss  |
> | X  | X  | X  | X  | X  | ssh-rsa-cert-...@openssh.com |
> | X  | X  | X  | X  | X  | ssh-dss-cert-...@openssh.com |
> | X  | X  | X  | X  | X  | ssh-rsa-cert-...@openssh.com |
> | X  | X  | X  | X  | X  | ssh-dss-cert-...@openssh.com |
> || X  | X  | X  | X  | ecdsa-sha2-nistp256  |
> || X  | X  | X  | X  | ecdsa-sha2-nistp384  |
> || X  | X  | X  | X  | ecdsa-sha2-nistp521  |
> || X  | X  | X  | X  | ecdsa-sha2-nistp256-cert-...@openssh.com |
> || X  | X  | X  | X  | ecdsa-sha2-nistp384-cert-...@openssh.com |
> || X  | X  | X  | X  | ecdsa-sha2-nistp521-cert-...@openssh.com |
> ||| X  | X  | X  | ssh-ed25519  |
> ||| X  | X  | X  | ssh-ed25519-cert-...@openssh.com |
>
>
> KexAlgorithms
> | sq | wh | je | st | si | type |
> =
> | X  | X  | X  || X  | diffie-hellman-group-exchange-sha256 |
> | X  | X  | X  || X  | diffie-hellman-group-exchange-sha1   |
> | X  | X  | X  || X  | diffie-hellman-group14-sha1  |
> | X  | X  | X  || X  | diffie-hellman-group1-sha1   |
> || X  | X  || X  | ecdh-sha2-nistp256   |
> || X  | X  || X  | ecdh-sha2-nistp384   |
> || X  | X  || X  | ecdh-sha2-nistp521   |
> ||| X  || X  | curve25519-sha...@libssh.org |
>
> Ciphers
> | sq | wh | je | st | si | type  |
> ==
> | X  | X  | X  | X  | X  | aes128-ctr|
> | X  | X  | X  | X  | X  | aes192-ctr|
> | X  | X  | X  | X  | X  | aes256-ctr|
> | X  | X  | X  | X  | X  | arcfour   |
> | X  | X  | X  | X  | X  | arcfour256|
> | X  | X  | X  | X  | X  | arcfour128|
> | X  | X  | X  | X  | X  | aes128-cbc|
> | X  | X  | X  | X  | X  | 3des-cbc  |
> | X  | X  | X  | X  | X  | blowfish-cbc  |
> | X  | X  | X  | X  | X  | cast128-cbc   |
> | X  | X  | X  | X  | X  | aes192-cbc|
> | X  | X  | X  | X  | X  | aes256-cbc|
> ||| X  | X  | X  | aes128-...@openssh.com|
> ||| X  | X  | X  | aes256-...@openssh.com|
> ||| X  | X  | X  | chacha20-poly1...@openssh.com |
> ||| X  | X  | X  | rijndael-...@lysator.liu.se   |
>
> MACs
> | sq | wh | je | st | si   | type   |
> =
> | X  | X  | X  | X  | X| hmac-md5   |
> | X  | X  | X  | X  | X| hmac-sha1  |
> | X  | X  | X  | X  | X| umac...@openssh.com|
> | X  | X  | X  | X  | X| hmac-ripemd160 |
> | ?  | X  | X  | X  | X| hmac-ripemd...@openssh.com |
> | X  | X  | X  | X  | X| hmac-sha1-96   |
> | X  | X  | X  | X  | X| hmac-md5-96|
> | X  | X  | X  | X  | X| hmac-sha2-256  |
> | X  | X  |||  | hmac-sha2-256-96   | *
> | X  | X  | X  | X  | X| hmac-sha2-512  |
> | X  | X  |||  | hmac-sha2-512-96   | *
> ||| X  | X  | X| umac-64-...@openssh.com|
> ||| X  | X  | X| umac-128-...@openssh.com   |
> ||| X  | X  | X| hmac-sha2-256-...@openssh.com  |
> || 

Bug#1073065: ssh_config manpage disagrees with ssh -Q kex on KexAlgorithms

[Antoine Beaupre]

Package: openssh-client
Version: 1:9.2p1-2+deb12u2
Severity: minor

In Debian stable, the manual page says:

 KexAlgorithms
 Specifies the available KEX (Key Exchange) algorithms.
 Multiple algorithms must be comma-separated.  If the spec‐
 ified list begins with a ‘+’ character, then the specified
 algorithms will be appended to the default set instead of
 replacing them.  If the specified list begins with a ‘-’
 character, then the specified algorithms (including wild‐
 cards) will be removed from the default set instead of re‐
 placing them.  If the specified list begins with a ‘^’
 character, then the specified algorithms will be placed at
 the head of the default set.  The default is:

   sntrup761x25519-sha...@openssh.com,
   curve25519-sha256,curve25519-sha...@libssh.org,
   ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,
   diffie-hellman-group-exchange-sha256,
   diffie-hellman-group16-sha512,
   diffie-hellman-group18-sha512,
   diffie-hellman-group14-sha256

 The list of available key exchange algorithms may also be
 obtained using "ssh -Q kex".

Yet that command, `ssh -Q kex`, has a *different* list:

anarcat@angela:~$ ssh -Q kex | sort
curve25519-sha256
curve25519-sha...@libssh.org
diffie-hellman-group14-sha1
diffie-hellman-group14-sha256
diffie-hellman-group16-sha512
diffie-hellman-group18-sha512
diffie-hellman-group1-sha1
diffie-hellman-group-exchange-sha1
diffie-hellman-group-exchange-sha256
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
sntrup761x25519-sha...@openssh.com

The diff is:

--- b   2024-06-12 12:44:27.872122356 -0400
+++ /dev/fd/63  2024-06-12 12:44:44.476131607 -0400
@@ -1,8 +1,11 @@
 curve25519-sha256
 curve25519-sha...@libssh.org
+diffie-hellman-group14-sha1
 diffie-hellman-group14-sha256
 diffie-hellman-group16-sha512
 diffie-hellman-group18-sha512
+diffie-hellman-group1-sha1
+diffie-hellman-group-exchange-sha1
 diffie-hellman-group-exchange-sha256
 ecdh-sha2-nistp256
 ecdh-sha2-nistp384

This might be related to the SHA1 removal, but it seems to me -Q
should reflect the manual page output.

-- 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 openssh-client depends on:
ii  adduser   3.134
ii  libc6 2.36-9+deb12u7
ii  libedit2  3.1-20221030-2
ii  libfido2-11.12.0-2+b1
ii  libgssapi-krb5-2  1.20.1-2+deb12u1
ii  libselinux1   3.4-1+b6
ii  libssl3   3.0.11-1~deb12u2
ii  passwd1:4.13+dfsg1-1+b1
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages openssh-client recommends:
ii  xauth  1:1.1.2-1

Versions of packages openssh-client suggests:
pn  keychain  
pn  libpam-ssh
pn  monkeysphere  
ii  ssh-askpass   1:1.2.4.1-16

-- no debconf information

Bug#1072977: bembo.debian.org TLS certificate is not signed by a well-known authority

[Antoine Le Gonidec]

While the update to apt-listbugs 0.1.42 does indeed trigger the
reported problem, its cause is not in apt-listbugs code itself.

This update uses https by default, but one of the servers answering to
bugs.debian.org (bembo.debian.org) uses a TLS certificate that is not
signed by a well-known authority, leading to the certificate
verification failure.

The other server answering to bugs.debian.org (buxtehude.debian.org)
does not have this problem, so people might not get this certificate
error when using apt-listbugs if they are lucky enough to contact the
server with the correct TLS configuration.

What should be fixed here is the TLS certificate served by
bembo.debian.org, not apt-listbugs itself.

Bug#1072977: bembo.debian.org TLS certificate is not signed by a well-known authority

[Antoine Le Gonidec]

> This update uses https by default, but one of the servers answering to
> bugs.debian.org (bembo.debian.org) uses a TLS certificate that is not
> signed by a well-known authority, leading to the certificate
> verification failure.

You can probably forget about that, further investigation seems to show
that I messed up during my tests and something else is amiss.

Sorry for the noise.

Bug#1010445: mono-complete: Mono package in Debian is very outdated (6.8 but should be 6.12)

[Antoine Le Gonidec]

Please consider lowering this bug report severity.

While it would indeed be really nice to get a more recent build of Mono
in Debian repositories (I am sure the Debian Mono Group would be happy
to get help with this), keeping the current outdated build is much more
useful than not having access to Mono at all from Debian repositories.

Here we rely extensively on the Debian-provided 6.8 build to run
non-free games built on top of the XNA/FNA engine through
./play.it (https://wiki.debian.org/Games/PlayIt). Losing these packages
would make us rely on the binaries and libraries shipped by the game
developers instead, that are usually older than the current Debian
build.

More generally requests for the packaging of new upstream releases
tend to use a "wishlist" severity level, not "important" and even less
"serious".


pgpLS55jyDxJZ.pgp
Description: Signature digitale OpenPGP

Bug#1072166: python-zombie-imp: Missing build dependency

[Antoine Le Gonidec]

Source: python-zombie-imp
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

The python-zombie-imp source requires the "setuptools" Python module,
but python3-setuptools is not included in its build dependencies.

This has been noticed when trying to build a local backport of
python3-zombie-imp for Bookworm, I have not checked yet if the same
problem happens when building on top of Trixie or Sid.

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

Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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#1071578: browse-url silently fails on some wayland corner cases

[Antoine Beaupre]

Package: emacs-pgtk
Version: 1:29.3+1-2~bpo12+1
Severity: normal

After upgrading from Emacs 28 to 29 and switching from xorg to
wayland, I have noticed emacs sometimes fail to open URLs. It seems to
be an ordering issue in my session: it seems like Emacs sometimes
starts before Sway is fully setup and the environment properly
populated, which makes it use the incorrect WAYLAND_DISPLAY variable.

This, in itself, is a bug in my setup: Emacs should be started
properly.

*But* my bug here is this fails completely silently. No URL gets
opened at all, which is *really* disruptive because I can open a bunch
of URLs while reading my mail, then i go to my browser and nothing is
there and now I've lost data.

Instead, browse-url should fail noisily if it fails to load a URL. If
I look at the `browse-url' source, for example at the end we see this
kind of failure, which happens when no browser can be found at all:

(if (functionp function)
(apply function url args)
  (error "No suitable browser for URL %s" url

That is what I would expect the handler to do in this case, something
like "uh, we can't find your wayland display, so we're just dropping
this URL to the floor, sorry".

That function also has that mysterious blob:

  (progn
;; The `display' frame parameter is probably wrong.
;; See bug#53969 for some context.
;; (setenv "WAYLAND_DISPLAY" dpy)
)
(setenv "DISPLAY" dpy)))

... which refers to:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53969

... which I'm struggling to understand. If I uncomment that blob, the
bug, actually, just completely goes away which i find quite puzzling.

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 emacs-pgtk depends on:
ii  emacs-bin-common  1:29.3+1-2~bpo12+1
ii  emacs-common  1:29.3+1-2~bpo12+1
ii  libacl1   2.3.1-3
ii  libasound21.2.8-1+b1
ii  libc6 2.36-9+deb12u7
ii  libcairo2 1.16.0-7
ii  libdbus-1-3   1.14.10-1~deb12u1
ii  libfontconfig12.14.1-4
ii  libfreetype6  2.12.1+dfsg-5
ii  libgccjit012.2.0-14
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libgif7   5.2.1-2.5
ii  libglib2.0-0  2.74.6-2+deb12u2
ii  libgmp10  2:6.2.1+dfsg1-1.1
ii  libgnutls30   3.7.9-2+deb12u2
ii  libgpm2   1.20.7-10+b1
ii  libgtk-3-03.24.38-2~deb12u1
ii  libharfbuzz0b 6.0.0+dfsg-3
ii  libjansson4   2.14-2
ii  libjpeg62-turbo   1:2.1.5-2
ii  liblcms2-22.14-2
ii  libotf1   0.9.16-4
ii  libpango-1.0-01.50.12+ds-1
ii  libpng16-16t64 [libpng16-16]  1.6.43-5
ii  librsvg2-22.54.7+dfsg-1~deb12u1
ii  libselinux1   3.4-1+b6
ii  libsqlite3-0  3.40.1-2
ii  libsystemd0   252.22-1~deb12u1
ii  libtiff6  4.5.0-6+deb12u1
ii  libtinfo6 6.4-4
ii  libtree-sitter0   0.20.7-1
ii  libwebp7  1.2.4-0.2+deb12u1
ii  libwebpdemux2 1.2.4-0.2+deb12u1
ii  libxml2   2.9.14+dfsg-1.3~deb12u1
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages emacs-pgtk recommends:
ii  fonts-noto-color-emoji  2.042-0+deb12u1

Versions of packages emacs-pgtk suggests:
ii  emacs-common-non-dfsg  1:28.2+1-2

-- no debconf information

Bug#1070759: new upstream release

[Antoine Beaupre]

Package: fabric
Version: 2.6.0-1
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org

A new upstream release is available for Fabric (3.2.2 at the time of
writing).

It depends on the new pytest-relaxed package, missing from Debian,
itself blocked on upstream upgrading their pytest support (#1008768).

-- 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 fabric depends on:
ii  libjs-sphinxdoc5.3.0-4
ii  python33.11.2-1+b1
ii  python3-fabric 2.6.0-1
ii  python3-pkg-resources  66.1.1-1

fabric recommends no packages.

fabric suggests no packages.

-- no debconf information

Bug#1070758: new upstream release (2.2.0)

[Antoine Beaupre]

Package: python3-invoke
Version: 2.0.0-1
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org, Alexandre Detiste 


Invoke has had several releases that are not included yet in Debian. I
had started working on updating to 2.2.0 but got blocked on
pytest-relaxed missing from Debian, itself blocked on upstream
upgrading their pytest support (#1008768).

Right now, the git repository is in bad shape, as it has some blobs
from 2.2.0 but not the latest changes from unstable, so that needs to
be fixed first. I tried to do it myself but failed, so I'm hoping the
uploader (tchet, in cc) can handle this first.

-- 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 python3-invoke depends on:
ii  python33.11.2-1+b1
ii  python3-pkg-resources  66.1.1-1
ii  python3-six1.16.0-4
ii  python3-yaml   6.0-3+b2

python3-invoke recommends no packages.

Versions of packages python3-invoke suggests:
pn  python-invoke-doc  

-- no debconf information

Bug#925623: RFP: karma -- A simple tool that allows you to execute JavaScript code in multiple real browsers.

[Antoine Beaupré]

Hi!

On 2019-03-27 15:07:59, Jeff Cliff wrote:

[...]

> The main goal for Karma is to bring a productive testing environment to 
> developers. The environment being 
> one where they don't have to set up loads of configurations, but rather a 
> place where developers can 
> just write the code and get instant feedback from their tests. Because 
> getting quick feedback is what
> makes you productive and creative.

Do you still think we should package this in Debian? Since this bug was
filed, there hasn't been a single change upstream, in over 6 years
now... I wasn't familiar with Karma, and I suspect other (better
maintained) solutions might be more relevant here.

I'm asking because I found this bug while looking for *another* karma:

https://github.com/prymitive/karma

... which is about Prometheus alerting and monitoring, something
completely different...

a.

-- 
Treating different things the same can generate as much inequality as
treating the same things differently.
- Kimberlé Crenshaw

Bug#1044135: openmw: Crosshair, interactive prompts and character creation menus not visible.

[Antoine Le Gonidec]

In addition to the missing UI, OpenMW RAM usage is very high if
-DCMAKE_BUILD_TYPE=RelWithDebInfo is not set when building mygui.

I see a fix for this is already included in the Salsa repository for
mygui.  Please consider uploading a new release based on the current
state of the git repository, as it would make OpenMW usable again
without the need to locally build updated packages.


pgp0GRibRNn4c.pgp
Description: Signature digitale OpenPGP

Bug#1070129: ITP: web-cache -- Simple Python key-value storage backed up by sqlite3 database

[Antoine Beaupré]

Control: retitle -1 ITP: web-cache -- Simple Python key-value storage backed up 
by sqlite3 database

On 2024-04-30 12:26:05, Antoine Beaupre wrote:
> * Package name: python3-web-cache

Actually, py2dsp makes a package named `web-cache` for this, which seems
a tad too generic. Thoughts?

-- 
Only after disaster can we be resurrected.
It's only after you've lost everything that you're free to doanything.
Nothing is static, everything is evolving, everything is falling apart.
- Chuck Palahniuk, Fight Club

Bug#1070129: ITP: python3-web-cache -- Simple Python key-value storage backed up by sqlite3 database

[Antoine Beaupre]

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

* Package name: python3-web-cache
  Version : 1.1.0
  Upstream Contact: https://github.com/desbma
* URL : https://github.com/desbma/web_cache/
* License : LGPL-2.1
  Programming Lang: Python
  Description : Simple Python key-value storage backed up by sqlite3 
database

Python module for simple key-value storage backed up by sqlite3 database. The 
typical use case is a URL to HTTP data cache, but it can also be used for non 
web ressources.
Features

Simple dict interface allows natural usage (if key in cache, value = 
cache[key], etc.)
Optional Zlib (deflate), BZIP2, LZMA or ZSTD (Zstandard) compression, with 
configurable compression level
FIFO or LRU cache eviction strategies
Optional thread safe interface to work around Python Sqlite3 'same thread' 
limitation
Provides cache hit rate statistics



dependency of sacad (#1057152)

Bug#1070077: [Pkg-privacy-maintainers] Bug#1070077: ships files directly in /usr/onionprobe

[Antoine Beaupré]

On 2024-04-30 08:25:55, Georg Faerber wrote:
> On 24-04-29 16:19:21, Antoine Beaupre wrote:
>> 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...
>
> Indeed -- I wasn't aware, or probably forgot, that bookworm is affected.
> Given the severity, this might warrant a bookworm-pu, I guess?

Honestly, I'm not sure. It's relatively minor because it's just the
examples files, and the rest of the package is functional. I've patched
our puppet manifests to workaround the issue over here...

>> I haven't checked in unstable to see if this is fixed.
>
> This was reported via #1025508 and fixed in unstable via 1.1.2+ds-1.

Oh, I didn't realize that, good job! :)

-- 
It is capitalism and government which stand for disorder and
violence. Anarchism is the very reverse of it; it means order without
government and peace without violence.
- Alexander Berkman

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#1069962: renpy: Missing dependency on python3-ecdsa

[Antoine Le Gonidec]

Package: renpy
Version: 8.1.3+dfsg-1
Severity: normal

`import ecdsa` is called from /usr/share/games/renpy/renpy/savetoken.py,
but the renpy package has no dependency on python3-ecdsa.

This leads to a crash when this file is loaded:

Traceback (most recent call last):
  File "/usr/games/renpy", line 252, in 
main()
  File "/usr/games/renpy", line 248, in main
renpy.bootstrap.bootstrap(renpy_base)
  File "/usr/share/games/renpy/renpy/bootstrap.py", line 250, in bootstrap
renpy.import_all()
  File "/usr/share/games/renpy/renpy/__init__.py", line 428, in import_all
import renpy.savetoken
  File "/usr/share/games/renpy/renpy/savetoken.py", line 26, in 
import ecdsa
ModuleNotFoundError: No module named 'ecdsa'

Installing the python3-ecdsa package is enough to avoid this error, but
it should probably be added to the direct dependencies of the renpy
package.

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

Kernel: Linux 6.7.9-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 renpy depends on:
ii  fonts-dejavu-core 2.37-8
ii  fonts-motoya-l-cedar  1.01-5
ii  fonts-nanum   20200506-1
ii  fonts-roboto-hinted   2:0~20170802-3
ii  python3   3.11.8-1
ii  python3-pefile2023.2.7-3
ii  python3-pygame-sdl2   8.2.1-1
ii  python3-renpy 8.1.3+dfsg-1+b1
ii  python3-six   1.16.0-6

Versions of packages renpy recommends:
pn  python3-tk  
pn  zenity  

renpy suggests no packages.

-- no debconf information

Bug#1069961: ImportError: cannot import name 'RWops_from_file' from 'pygame_sdl2.rwobject'

[Antoine Le Gonidec]

Package: renpy
Version: 8.1.3+dfsg-1
Severity: important

When trying to run commercial games with Debian-provided renpy (I tried
Slay the Princess and Roadwarden), a crash is triggered before the game
window would be shown:

Traceback (most recent call last):
  File "/usr/games/renpy", line 252, in 
main()
  File "/usr/games/renpy", line 248, in main
renpy.bootstrap.bootstrap(renpy_base)
  File "/usr/share/games/renpy/renpy/bootstrap.py", line 250, in bootstrap
renpy.import_all()
  File "/usr/share/games/renpy/renpy/__init__.py", line 409, in import_all
import renpy.loader
  File "/usr/share/games/renpy/renpy/loader.py", line 37, in 
from pygame_sdl2.rwobject import RWops_from_file, RWops_create_subfile
ImportError: cannot import name 'RWops_from_file' from 'pygame_sdl2.rwobject' 
(/usr/lib/python3/dist-packages/pygame_sdl2/rwobject.cpython-311-x86_64-linux-gnu.so)

The import line triggering this error is no longer part of the upstream
codebase, it has been replaced with the following commit:
https://github.com/renpy/renpy/commit/13cfd68491a38ca1d864c6b668b8c527e58923e2

Applying this patch on top of the cuurent sid build does indeed avoid
this crash, and allow to run the games I tested.

I suggest either backporting this patch, or, better, packaging the
current upstream release (8.2.1).

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

Kernel: Linux 6.7.9-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 renpy depends on:
ii  fonts-dejavu-core 2.37-8
ii  fonts-motoya-l-cedar  1.01-5
ii  fonts-nanum   20200506-1
ii  fonts-roboto-hinted   2:0~20170802-3
ii  python3   3.11.8-1
ii  python3-pefile2023.2.7-3
ii  python3-pygame-sdl2   8.2.1-1
ii  python3-renpy 8.1.3+dfsg-1+b1
ii  python3-six   1.16.0-6

Versions of packages renpy recommends:
pn  python3-tk  
pn  zenity  

renpy suggests no packages.

-- no debconf information

Bug#642504: bash: file number exhaustion on certain redirections in loop: "Too many open files"

[Antoine Beaupré]

I saw a similar crash here, where bash would start failing around about
500 iterations in such a loop:

```
export GIT_ASKPASS=echo

grep -v '^#' ../gitolite2gitlab.txt |while read gitolite_path gitlab_path; do
gitolite_url=/srv/git.torproject.org/repositories/$gitolite_path.git 
gitlab_url=https://gitlab.torproject.org/$gitlab_path.git 
echo "diff -u $gitolite_url $gitlab_url"
diff -u <(git ls-remote $gitolite_url) <(git ls-remote $gitlab_url)
done | tee final-remote-diff.patch
```

~500 is not a random number. it's about half of 1024, which i suspect is
the fd limit i'm hitting. i'm betting the shell is just not closing
those file descriptor at all after the pipeline completes.

normally, i would expect the FD to close after the `diff -u` command
returns there, but it seems that's just not happening.

Bug#1055811: O: coreboot -- free firmware

[Antoine Beaupré]

On 2024-04-15 23:02:20, Matthias Geiger wrote:
> On 15.04.24 22:59, Antoine Beaupré wrote:
>> On 2024-04-15 22:22:04, Matthias Geiger wrote:
>>> On 15.04.24 21:01, Antoine Beaupré wrote:
>>>> On 2023-12-22 00:15:30, Matthias Geiger wrote:
>>>>> Once the StarBook VI AMD get mainline coreboot support I will adopt this
>>>>> package.
>>>> Hi!
>>>>
>>>> It would be nice to see this come through! Do you still intend on
>>>> adopting this package, and if so, when will StarBook get that nice
>>>> update? :)
>>> Hi.
>>>
>>> yes, I still intend to adopt coreboot once the StarBook (AMD variant)
>>> gets coreboot support. TTBOMK this hasn't happened yet.
>>>
>>> I could update it right now but this is of little use if I have no
>>> device to test it on.
>> I believe I have such a device this could be tested on, at least to a
>> certain extent. It seems like the Framework laptop can use the recent ectool
>> binary from coreboot even if the BIOS itself doesn't use coreboot:
>>
>> https://community.frame.work/t/exploring-the-embedded-controller/12846/156?u=anarcat
>>
>> So I'm happy to serve as a guinea pig if you need one, otherwise I'm
>> considering just looking at doing the upgrade myself (gulp!) but i'm not
>> sure i have the cycles in maintaining this long term.
>>
>> a.
>
> If you're willing to test the package then I will look into updating 
> coreboot to the latest release. This might take some time. I hope 
> StarLabs can get coreboot to work in a reasonable timeframe.
>
> I'll ping back here once I made some progress.

Amazing, thanks!

-- 
The true revolutionary is guided by a great feeling of love.
- Ernesto "Che" Guevara

Bug#1055811: O: coreboot -- free firmware

[Antoine Beaupré]

On 2024-04-15 22:22:04, Matthias Geiger wrote:
> On 15.04.24 21:01, Antoine Beaupré wrote:
>> On 2023-12-22 00:15:30, Matthias Geiger wrote:
>>> Once the StarBook VI AMD get mainline coreboot support I will adopt this
>>> package.
>> Hi!
>>
>> It would be nice to see this come through! Do you still intend on
>> adopting this package, and if so, when will StarBook get that nice
>> update? :)
>
> Hi.
>
> yes, I still intend to adopt coreboot once the StarBook (AMD variant) 
> gets coreboot support. TTBOMK this hasn't happened yet.
>
> I could update it right now but this is of little use if I have no 
> device to test it on.

I believe I have such a device this could be tested on, at least to a
certain extent. It seems like the Framework laptop can use the recent ectool
binary from coreboot even if the BIOS itself doesn't use coreboot:

https://community.frame.work/t/exploring-the-embedded-controller/12846/156?u=anarcat

So I'm happy to serve as a guinea pig if you need one, otherwise I'm
considering just looking at doing the upgrade myself (gulp!) but i'm not
sure i have the cycles in maintaining this long term.

a.

-- 
Freedom of speech is a principal pillar of a free government; when
this support is taken away, the constitution of a free society is
dissolved, and tyranny is erected on its ruins.
- Benjamin Franklin, 1737

Bug#1055811: O: coreboot -- free firmware

[Antoine Beaupré]

On 2023-12-22 00:15:30, Matthias Geiger wrote:
> Once the StarBook VI AMD get mainline coreboot support I will adopt this 
> package.

Hi!

It would be nice to see this come through! Do you still intend on
adopting this package, and if so, when will StarBook get that nice
update? :)

a.

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of speech
because I have nothing to say."
- Edward Snowden

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#1068704: login: Wrong comment in login.defs about USERGROUPS_ENAB

[Antoine Le Gonidec]

Package: login
Version: 1:4.13+dfsg1-4
Severity: normal

>From /etc/login.defs, part of the comment above USERGROUPS_ENAB is no
longer describing the actual behaviour:

> Other former uses of this variable such as setting the umask when
> user==primary group are not used in PAM environments, such as Debian

Recent changes in src:pam made this configuration value change the
setting of umask when the user name and its primary group name are the
same, cf. https://bugs.debian.org/1065806 and https://bugs.debian.org/583958

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

Kernel: Linux 6.7.7-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 login depends on:
ii  libaudit1   1:3.1.2-2.1
ii  libc6   2.37-15.1
ii  libcrypt1   1:4.4.36-4
ii  libpam-modules  1.5.3-7
ii  libpam-runtime  1.5.3-7
ii  libpam0g1.5.3-7

login recommends no packages.

login suggests no packages.

-- no debconf information

Bug#1068527: test suite failures

[Antoine Beaupré]

Control: tags -1 +patch +upstream

Upstream actually fixed this issue, possibly:

https://github.com/dajva/rg.el/commit/8e2347d0a11aa64fd721702b176b1dbc7889f78e

So, woot, i guess we get this fix when upstream makes a new release (or
we import that patch).

A.
-- 
Science knows still practically nothing about the real nature of
matter, energy, dimension, or time; and even less about those
remarkable things called life and thought. But whatever the meaning
and purpose of this universe, you are a legitimate part of it.
- Gene Roddenberry

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#1068342: RFP: valkey -- Persistent key-value database with network interface (Redis fork)

[Antoine Beaupré]

FWIW, valkey just entered FreeBSD ports as well:

https://www.freshports.org/databases/valkey/
-- 
For once you have tasted flight,
You will walk the earth with your eyes turned skyward;
For there you have been,
And there you long to return.
- Leonardo da Vinci

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#1042262: cumin: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.11 returned exit code 13

[Antoine Beaupré]

On 2023-07-27 13:04:22, Riccardo Coccioli wrote:
> I've checked the issue and opened a bug upstream to pyparsing [1] as this
> is indeed a regression.
> Running CI on cumin I've also found that pylint is reporting new issues
> related to pyparsing code, for which I've opened a separate bug upstream
> [2].
>
> [1] https://github.com/pyparsing/pyparsing/issues/502
> [2] https://github.com/pyparsing/pyparsing/issues/501

Hi!

Thanks for this! It looks like those are fixed upstream, do we need to
update pyparsing to 3.1.2 to fix this bug or what's the next step?

(upstream 502 is fixed in 3.1.1, in unstable, but 501 is only in
3.1.2...)

a.

-- 
Sous le projecteur, on ne voit pas les autres.
- Félix Leclerc

Bug#1067413: RFP: keydb -- persistent key-value database with network interface

[Antoine Beaupré]

On 2024-03-25 17:43:58, Guillem Jover wrote:
> Hi!
>
> On Fri, 2024-03-22 at 12:35:47 +, Chris Lamb wrote:
>> > I'm CCing Chris, who might perhaps be interested in replacing Redis with
>> > KeyDB as its spiritual successor and taking this on? Or if not, at least
>> > to perhaps potentially coordinate some kind of transition, even though
>> > we've had issues migrating persistent DBs from newer Redis to KeyDB, so
>> > that might be tricky or not feasible at all.
>> 
>> Thanks for including me here. I had not yet looked into potential
>> Redis replacements nor the exact and precise details of the new
>> license etc. and this activity around KeyDB feels like a good start.
>> I thought I'd let the dust settle for a bit before making any
>> decisions — perhaps the change even gets reversed (!), and no doubt
>> there might be new alternatives that will fork the code immediately
>> prior to the license change.
>
> Yeah, fair enough.
>
>> My personal and professional usage of Redis has dropped off in the
>> past few years, so it would make more sense for me to help out in a
>> team maintainership role, at least with respect to KeyDB.
>
> Ack.
>
>> However, I'd be interested in coordinating around some kind of
>> Redis→KeyDB/something transition if need be.
>
> For KeyDB, that would also depend on whether KeyDB adds Redis 7 support
> or not I guess.
>
>   https://github.com/Snapchat/KeyDB/issues/420
>
> and if that does not materialize, a potential migration path via:
>
>   https://github.com/Snapchat/KeyDB/issues/527#issuecomment-1370606311
>
> In our, case we migrated from Redis 6 to KeyDB, so the above did not
> really affect us.

After reading https://lwn.net/SubscriberLink/966631/4b4104ce85bf92f7/, i
have the feeling valkey is probably a better bet for a smooth
transition. I filed a RFP about it in https://bugs.debian.org/1068342

A.

-- 
We know the road to freedom has always been stalked by death.
- Angela Davis

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#947858: ITP: wshowkeys -- Displays keypresses on screen on supported Wayland compositors

[Antoine Beaupré]

On 2024-03-21 21:47:28, Birger Schacht wrote:
> Hi Antoine,
>
> ah, I think I've forgotten about this, also because `wev` serves a 
> similar usecase, without SUID.
>
> Feel free to upload, I won't have time for this in the next couple of 
> days. Feel free to put it under the swaywm-team umbrella, I can also 
> give you access to the salsa team, if you want to move it there.

I'm happy to move it wherever.

For me, wev doesn't cut it because it doesn't show keystrokes unless you
type them in the wev window, did I miss anything?

A.

-- 
Some believe it is only great power that can hold evil in check, but
that is not what I have found. It is the small everyday deeds of
ordinary folk that keep the darkness at bay. Small acts of kindness and
love.   - J.R.R. Tolkien

Bug#947858: ITP: wshowkeys -- Displays keypresses on screen on supported Wayland compositors

[Antoine Beaupré]

On 2024-03-21 10:03:10, Antoine Beaupré wrote:
> On 2019-12-31 22:11:31, Birger Schacht wrote:
>> Package: wnpp
>> Severity: wishlist
>> Owner: Birger Schacht 
>>
>> * Package name: wshowkeys
>
> hello!
>
> this has been now open for (checks time)... a little over 4 years... any
> progress? :)

This seems like a relatively trivial package, so I just went ahead and
built ... something. Source is at:

https://salsa.debian.org/debian/wshowkeys

I'm not uploading this to NEW out of respect for this ticket, assigned
to you. I'm really happy to just give you maintainership, just
s/myname/yourname/ in the package and put it wherever you want. :)

Happy to share maintainership as well. Maybe it should go under the
team+swa...@tracker.debian.org umbrella too?

Tested locally, it works fine. Only annoyance, IMHO, is the lack of a
manual page and the SUID bit.

Bug#947858: ITP: wshowkeys -- Displays keypresses on screen on supported Wayland compositors

[Antoine Beaupré]

On 2019-12-31 22:11:31, Birger Schacht wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Birger Schacht 
>
> * Package name: wshowkeys

hello!

this has been now open for (checks time)... a little over 4 years... any
progress? :)

a.

-- 
In a world where Henry Kissinger wins the Nobel Peace Prize,
there is no need for satire.
- Tom Lehrer

Bug#1066893: missing deps

[Antoine Beaupré]

A bunch of deps are missing from debian at the moment:

2024/03/14 21:19:20 Build-Dependency "github.com/pterm/pterm" is not yet 
available in Debian, or has not yet been converted to use XS-Go-Import-Path in 
debian/control
2024/03/14 21:19:20 Build-Dependency "github.com/d5/tengo" is not yet available 
in Debian, or has not yet been converted to use XS-Go-Import-Path in 
debian/control
2024/03/14 21:19:20 Build-Dependency "github.com/errata-ai/regexp2" is not yet 
available in Debian, or has not yet been converted to use XS-Go-Import-Path in 
debian/control
2024/03/14 21:19:20 Build-Dependency "github.com/mholt/archiver" is not yet 
available in Debian, or has not yet been converted to use XS-Go-Import-Path in 
debian/control
2024/03/14 21:19:20 Build-Dependency "github.com/adrg/strutil" is not yet 
available in Debian, or has not yet been converted to use XS-Go-Import-Path in 
debian/control
2024/03/14 21:19:20 Build-Dependency "github.com/errata-ai/ini" is not yet 
available in Debian, or has not yet been converted to use XS-Go-Import-Path in 
debian/control
2024/03/14 21:19:20 Build-Dependency "github.com/jdkato/twine" is not yet 
available in Debian, or has not yet been converted to use XS-Go-Import-Path in 
debian/control

so that's kind of a big undertaking. some of those are actually pretty
interesting on their own, like pterm looks like a cool lib!

Others are more of a problem, like errata-ai/regexp2 which is a fork of
an existing lib (*also* not in Debian). errata-ai/ini looks like a
rather gratitious fork as well.

-- 
Qui vit sans folie n'est pas si sage qu'il croit.
- François de La Rochefoucauld

Bug#1066893: RFP: vale -- :pencil: A markup-aware linter for prose built with speed and extensibility in mind.

[Antoine Beaupré]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupré 

* Package name: vale
  Version : 3.0.0-1
  Upstream Author : errata.ai
* URL : https://github.com/errata-ai/vale
* License : Expat
  Programming Lang: Go
  Description : A markup-aware linter for prose built with speed and 
extensibility in mind.

Vale is a command-line tool that brings code-like linting to
prose. It's fast, cross-platform (Windows, macOS, and Linux), and
highly customizable.

Key Features

Support for markup: Vale has a rich understanding of many markup formats, 
allowing it to avoid syntax-related false positives and intelligently exclude 
code snippets from prose-related rules.

A highly customizable extension system: Vale is capable of enforcing your 
style—be it a standard editorial style guide or a custom in-house set of rules 
(such as those created by GitLab, Homebrew, Linode, CockroachDB, and Spotify).

Easy-to-install, stand-alone binaries: Unlike other tools, Vale doesn't 
require you to install and configure a particular programming language and its 
related tooling (such as Python/pip or Node.js/npm).



There are a handful of spell-checkers and linters for prose in Debian,
but vale is a little different. It's not *only* a spellchecker and does
*other* things like checking for styles or allow for extensibility.

Similar software include diction(1) and markdownlint, where diction is
*really* old (e.g. doesn't know about markdown) and mdl is not very
customizable (e.g. it's hard, in my experience to add words to a
dictionary).

So I'm considering vale instead.

-- 
We must learn to live together as brothers or perish together as fools.
- Martin Luther King, Jr.

Bug#1066139: podman: Cannot create a network with dns_enabled

[Antoine Sirinelli]

On Wed, Mar 13, 2024 at 12:14:28PM +0200, Faidon Liambotis wrote:
> 1) Perhaps you installed podman with apt install --no-install-recommends?

Not the case.

> 2) Alternatively, perhaps you first set up podman without Netavark (e.g.
>before 4.0), and later upgraded to a newer version?

This is likely the case. This system was installed in 2020 and podman has been
installed for a while but I was not able to find the logs before last year...

>I don't think an automatic transition from the old stack to the new
>stack exists. A "podman system reset" should fix it; I'm not sure if
>there is a less intrusive way to do that. Perhaps we'll know more
>about upgrade paths with the 5.0 release, which is imminent.

podman system reset fixed it.

Thank you for your help,

Antoine

Bug#1066139: podman: Cannot create a network with dns_enabled

[Antoine Sirinelli]

Package: podman
Version: 4.9.3+ds1-1
Severity: normal

Dear Maintainer,

When I create a new custom network, the dns is not enabled:

$ podman network create test
test
$ podman network inspect test
[
 {
  "name": "test",
  "id": 
"9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
  "driver": "bridge",
  "network_interface": "cni-podman1",
  "created": "2024-03-13T00:11:16.769046605+01:00",
  "subnets": [
   {
"subnet": "10.89.0.0/24",
"gateway": "10.89.0.1"
   }
  ],
  "ipv6_enabled": false,
  "internal": false,
  "dns_enabled": false,
  "ipam_options": {
   "driver": "host-local"
  }
 }
]

The outcome should have "dns_enabled" to true.

Thank you,

Antoine

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64, i386

Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 podman depends on:
ii  conmon   2.1.10+ds1-1
ii  golang-github-containers-common  0.57.4+ds1-2
ii  libc62.37-15
ii  libdevmapper1.02.1   2:1.02.196-1
ii  libgpgme11   1.18.0-4+b2
ii  libseccomp2  2.5.5-1
ii  libsqlite3-0 3.45.1-1
ii  libsubid41:4.13+dfsg1-4
ii  runc 1.1.12+ds1-1

Versions of packages podman recommends:
ii  buildah1.33.5+ds1-4
ii  catatonit  0.1.7-1+b1
ii  dbus-user-session  1.14.10-4
ii  passt  0.0~git20240220.1e6f92b-1
ii  slirp4netns1.2.1-1
ii  tini   0.19.0-1
ii  uidmap 1:4.13+dfsg1-4

Versions of packages podman suggests:
ii  containers-storage  1.51.0+ds1-2
ii  docker-compose  1.29.2-6
ii  iptables1.8.10-3

-- Configuration Files:
/etc/cni/net.d/87-podman-bridge.conflist [Errno 13] Permission non accordée: 
'/etc/cni/net.d/87-podman-bridge.conflist'
/etc/cni/net.d/87-podman-ptp.conflist [Errno 13] Permission non accordée: 
'/etc/cni/net.d/87-podman-ptp.conflist'

-- no debconf information

Bug#1065806: pam: recent upgrade changes previous default umask

[Antoine Le Gonidec]

The change of behaviour can have an unexpected and quite nasty
side-effect, by applying a misconfiguration that was ignored until this
update.

A setting of "UMASK 077" in /etc/login.defs was ignored before this
update, and is now applied (as it should) leading to unreadable files
if the user is not expecting it.

In my case this was a misconfiguration, as I thought it was a setting
applied only to the $HOME directory itself (I should have used
"HOME_MODE 0700" instead). But since it had no effect until the recent
update, I got taken by surprise with files generated with rw-rw
permissions when I was expecting the regular rw-r--r--.

I am not bumping the severity of this bug report because the new
behaviour is the correct one, but it should be kept in mind that other
people might get unexpected effects from this update.

Bug#1065572: llm packaging progress

[Antoine Beaupré]

So I'm running the llm Debian package locally. I had to package two
deps, for which I have filed ITPs as well (1065576: python-ulid,
1065578: python-sqlite-migrate). The former is a solid, globally useful
library, but I'm less sure about the latter - it seems more something
built just for that project, and that's explicitly not ready for
production. But, alas, that is done as well.

The code is on salsa:

https://salsa.debian.org/python-team/packages/llm
https://salsa.debian.org/python-team/packages/python-ulid
https://salsa.debian.org/python-team/packages/sqlite-migrate

I'm waiting a bit to see if people kick back on debian-devel before
going ahead with new. I'll also test this a little more, possibly trying
out llama.cpp if i can find the cycles.

So far this works pretty well. It's really nice to not have to use the
browser to talk to the engines, and having the ability to just pipe
stuff in and out of there is really useful.

a.

-- 
Advertisers, not governments, are the primary censors of media content 
in the United States today.
- C. Edwin Baker

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#1065572: ITP: llm -- Access large language models from the command-line

[Antoine Beaupré]

On 2024-03-06 22:06:18, Petter Reinholdtsen wrote:
> [Antoine Beaupre]
>> 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.
>
> Is the option to run models locally related to llama.cpp, ref
> https://bugs.debian.org/1063673 >?

I am not absolutely sure, but yes, I would assume that's one of the
backends llm can use.

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#1064925: ITP: fail2ban-prometheus-exporter - collect and export Prometheus metrics on Fail2Ban)

[Antoine Beaupré]

Control: retitle -1 RFP: fail2ban-prometheus-exporter - collect and export 
Prometheus metrics on Fail2Ban)

I thought all deps were in Debian, but I was wrong, those are missing:

github.com/kisielk/og-rek
github.com/nlpodyssey/gopickle

It's not that bad! Only two! But weirdly, they both relate to
(presumably Python) "pickles" so I'm not sure why both are necessary.

So I'll step away from this package for now, I ran out of cycles. It's
much easier to just do the fail2ban hack for now. I pushed the goods to
Salsa:

https://salsa.debian.org/go-team/packages/fail2ban-prometheus-exporter

Here's the build log:

Command: dpkg-buildpackage --sanitize-env -us -uc -rfakeroot
dpkg-buildpackage: info: source package fail2ban-prometheus-exporter
dpkg-buildpackage: info: source version 0.10.1-1
dpkg-buildpackage: info: source distribution experimental
dpkg-buildpackage: info: source changed by Antoine Beaupré 
 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
 debian/rules clean
dh clean --builddirectory=_build --buildsystem=golang --with=golang
   dh_auto_clean -O--builddirectory=_build -O--buildsystem=golang
   dh_autoreconf_clean -O--builddirectory=_build -O--buildsystem=golang
   dh_clean -O--builddirectory=_build -O--buildsystem=golang
 dpkg-source -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building fail2ban-prometheus-exporter using existing 
./fail2ban-prometheus-exporter_0.10.1.orig.tar.gz
dpkg-source: info: building fail2ban-prometheus-exporter in 
fail2ban-prometheus-exporter_0.10.1-1.debian.tar.xz
 debian/rules binary
dpkg-source: info: building fail2ban-prometheus-exporter in 
fail2ban-prometheus-exporter_0.10.1-1.dsc
dh binary --builddirectory=_build --buildsystem=golang --with=golang
   dh_update_autotools_config -O--builddirectory=_build -O--buildsystem=golang
   dh_autoreconf -O--builddirectory=_build -O--buildsystem=golang
   dh_auto_configure -O--builddirectory=_build -O--buildsystem=golang
   dh_auto_build -O--builddirectory=_build -O--buildsystem=golang
cd _build && go install -trimpath -v -p 12 
gitlab.com/hectorjsmith/fail2ban-prometheus-exporter 
gitlab.com/hectorjsmith/fail2ban-prometheus-exporter/auth 
gitlab.com/hectorjsmith/fail2ban-prometheus-exporter/cfg 
gitlab.com/hectorjsmith/fail2ban-prometheus-exporter/collector/f2b 
gitlab.com/hectorjsmith/fail2ban-prometheus-exporter/collector/textfile 
gitlab.com/hectorjsmith/fail2ban-prometheus-exporter/server 
gitlab.com/hectorjsmith/fail2ban-prometheus-exporter/socket
src/gitlab.com/hectorjsmith/fail2ban-prometheus-exporter/socket/fail2banSocket.go:5:2:
 cannot find package "github.com/kisielk/og-rek" in any of:
/usr/lib/go-1.22/src/github.com/kisielk/og-rek (from $GOROOT)
/<>/_build/src/github.com/kisielk/og-rek (from $GOPATH)
src/gitlab.com/hectorjsmith/fail2ban-prometheus-exporter/socket/protocol.go:7:2:
 cannot find package "github.com/nlpodyssey/gopickle/pickle" in any of:
/usr/lib/go-1.22/src/github.com/nlpodyssey/gopickle/pickle (from 
$GOROOT)
/<>/_build/src/github.com/nlpodyssey/gopickle/pickle (from 
$GOPATH)
src/gitlab.com/hectorjsmith/fail2ban-prometheus-exporter/socket/fail2banSocket.go:6:2:
 cannot find package "github.com/nlpodyssey/gopickle/types" in any of:
/usr/lib/go-1.22/src/github.com/nlpodyssey/gopickle/types (from $GOROOT)
/<>/_build/src/github.com/nlpodyssey/gopickle/types (from 
$GOPATH)
dh_auto_build: error: cd _build && go install -trimpath -v -p 12 
gitlab.com/hectorjsmith/fail2ban-prometheus-exporter 
gitlab.com/hectorjsmith/fail2ban-prometheus-exporter/auth 
gitlab.com/hectorjsmith/fail2ban-prometheus-exporter/cfg 
gitlab.com/hectorjsmith/fail2ban-prometheus-exporter/collector/f2b 
gitlab.com/hectorjsmith/fail2ban-prometheus-exporter/collector/textfile 
gitlab.com/hectorjsmith/fail2ban-prometheus-exporter/server 
gitlab.com/hectorjsmith/fail2ban-prometheus-exporter/socket returned exit code 1
make: *** [debian/rules:4: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

Build finished at 2024-02-27T19:51:28Z


-- 
By now the computer has moved out of the den and into the rest of your
life. It will consume all of your spare time, and even your vacation,
if you let it. It will empty your wallet and tie up your thoughts. It
will drive away your family. Your friends will start to think of you
as a bore. And what for?
   - The True Computerist by Tom Pittman

Bug#1064925: ITP: fail2ban-prometheus-exporter - collect and export Prometheus metrics on Fail2Ban

[Antoine Beaupré]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupré 

Reasoning: I need this! :) I could have written a mtail parser instead, but
/fail2ban.actions\s+\[\d+\]:\s+\w+\s+\[(?P)\] (?PBan|Unban)\s+/ {
fail2ban_action_count[$jail][$action]++
/fail2ban.filter\s+\[\d+\]:\s+\w+\s+\[(?P)\] (?PFound)\s+/ {
fail2ban_filter_count[$jail][$action]++
* Package name: fail2ban-prometheus-exporter
  Version : 0.10.1-1
  Upstream Author : hectorjsmith
* URL : https://gitlab.com/hectorjsmith/fail2ban-prometheus-exporter
* License : MIT
  Programming Lang: Go
  Description : collect and export Prometheus metrics on fail2ban

This Prometheus exporter provides Prometheus (or OpenMetrics) metrics
for the fail2ban package. It tracks the number of IPs currently
blocked, matched, how long they are tracked, and keeps track of
errors.

It parses data from the fail2ban socket and can export metrics over a
normal HTTP service or the text file collector.



halfway through doing that, I wondered "surely someone must have fixed that
already", and lo and behold.

A mtail equivalent might be:

# fail2ban log parser
#
# log lines:
#
# 2024-02-17 15:30:53,167 fail2ban.filter [578]: INFO
[fraud-donation-spam] Found 185.92.25.49 - 2024-02-17 15:30:52
# 2024-02-17 15:30:53,542 fail2ban.actions[578]: NOTICE  
[fraud-donation-spam] Ban 185.92.25.49
# 2024-02-24 15:30:45,200 fail2ban.actions[578]: NOTICE  
[fraud-donation-spam] Unban 91.230.225.115

counter fail2ban_action_count by jail, action

}

}

 but is not quite as accurate, because it tracks bans/unbans
independently, and doesn't reflect the actual state of the system
properly.
Autocrypt: addr=anar...@debian.org; prefer-encrypt=nopreference; 
keydata=xjMEZHZPzhYJKwYBBAHaRw8BAQdAWdVzOFRW6FYVpeVaDo3sC4aJ2kUW4ukdEZ36UJLAHd7NJUFudG9pbmUgQmVhdXByw6kgPGFuYXJjYXRAZGViaWFuLm9yZz7ClgQTFggAPhYhBLu2zUyY104TWKdSpgIpOm+k5TRzBQJkdmCVAhsDBQkB4TOABQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJEAIpOm+k5TRz+w8BANbRA+AMH0LN7trugVhaWe4wDpg94UVJloHPL+adJMK/AQCh39hyQXk3ivS2cK7xKZUgK0dBsbtJ2I2XBXvL9dS3Cc44BGR2UM4SCisGAQQBl1UBBQEBB0CYZha2IMY54WFXMG4S9/Smef54Pgon99LJ/hJ885p0ZAMBCAfCdwQYFggAIBYhBLu2zUyY104TWKdSpgIpOm+k5TRzBQJkdlDOAhsMAAoJEAIpOm+k5TRzBg0A+IbcsZhLx6FRIqBJCdfYMo7qovEo+vX0HZsUPRlq4HkBAIctCzmH3WyfOD/aUTeOF3tY+tIGUxxjQLGsNQZeGrQI
Date: Tue, 27 Feb 2024 14:34:11 -0500
Message-ID: <87msrl3dn0@angela.anarc.at>

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

[Antoine Beaupré]

Hello!

Nvidia is not involved here.

I must admit I haven't seen this bug in a while, maybe it was a one-off
thing?

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#1061521: + XPS 13 9343

[Antoine]

On 2/4/24 08:24, Hans de Goede wrote:

The issue of the kbd on some Dell XPS models no longer
working after a suspend/resume cycle should be fixed by
these 2 patches which are on their way to Linus' tree:

https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=for-linus=683cd8259a9b883a51973511f860976db2550a6e
https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=for-linus=9cf6e24c9fbf17e52de9fff07f12be7565ea6d61


Hi Hans, and thanks,

Just completing my feedback, I am also unable to reproduce the problem 
in eight ACPI S3 suspend/resume cycles on my XPS 13 9343;


Tested from Linus' tree on 6.8.0-rc2 (cf attached dmesg)

And on top of debian's testing,unstable one 6.6.13-1,
with attached patch (thus including initial patch "Input: atkbd - skip 
ATKBD_CMD_GETID in translated mode")


best regards,
Antoinediff -Naur 6.6.13-1_debian/drivers/input/keyboard/atkbd.c 6.8.0-rc2/drivers/input/keyboard/atkbd.c
--- 6.6.13-1/drivers/input/keyboard/atkbd.c	2024-01-20 11:51:49.0 +0100
+++ 6.8.0-rc2/drivers/input/keyboard/atkbd.c	2024-02-04 08:13:05.273965270 +0100
@@ -791,9 +791,9 @@
  * not work. So in this case simply assume a keyboard is connected to avoid
  * confusing some laptop keyboards.
  *
- * Skipping ATKBD_CMD_GETID ends up using a fake keyboard id. Using a fake id is
- * ok in translated mode, only atkbd_select_set() checks atkbd->id and in
- * translated mode that is a no-op.
+ * Skipping ATKBD_CMD_GETID ends up using a fake keyboard id. Using the standard
+ * 0xab83 id is ok in translated mode, only atkbd_select_set() checks atkbd->id
+ * and in translated mode that is a no-op.
  */
 static bool atkbd_skip_getid(struct atkbd *atkbd)
 {
@@ -824,6 +824,11 @@
  "keyboard reset failed on %s\n",
  ps2dev->serio->phys);
 
+	if (atkbd_skip_getid(atkbd)) {
+		atkbd->id = 0xab83;
+		goto deactivate_kbd;
+	}
+
 /*
  * Then we check the keyboard ID. We should get 0xab83 under normal conditions.
  * Some keyboards report different values, but the first byte is always 0xab or
@@ -832,10 +837,10 @@
  */
 
 	param[0] = param[1] = 0xa5;	/* initialize with invalid values */
-	if (atkbd_skip_getid(atkbd) || ps2_command(ps2dev, param, ATKBD_CMD_GETID)) {
+	if (ps2_command(ps2dev, param, ATKBD_CMD_GETID)) {
 
 /*
- * If the get ID command was skipped or failed, we check if we can at least set
+ * If the get ID command failed, we check if we can at least set
  * the LEDs on the keyboard. This should work on every keyboard out there.
  * It also turns the LEDs off, which we want anyway.
  */
@@ -858,6 +863,7 @@
 		return -1;
 	}
 
+deactivate_kbd:
 /*
  * Make sure nothing is coming from the keyboard and disturbs our
  * internal state.
[0.00] Linux version 6.8.0-rc2-xps13-9343_2 (me@zx) (gcc (Debian 13.2.0-10) 13.2.0, GNU ld (GNU Binutils for Debian) 2.41.90.20240122) #10 SMP PREEMPT_DYNAMIC Sun Feb  4 06:20:31 CET 2024
[0.00] Command line: \\boot\vmlinuz-6.8.0-rc2-xps13-9343_2 ro root=UUID=f88efbd2-19f5-4f2f-a8ce-6c1e1255119b initrd=boot\initrd.img-6.8.0-rc2-xps13-9343_2
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x00057fff] usable
[0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved
[0.00] BIOS-e820: [mem 0x00059000-0x0009efff] usable
[0.00] BIOS-e820: [mem 0x0009f000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x0010-0xc7d97fff] usable
[0.00] BIOS-e820: [mem 0xc7d98000-0xc8255fff] reserved
[0.00] BIOS-e820: [mem 0xc8256000-0xdadc] usable
[0.00] BIOS-e820: [mem 0xdadd-0xdae92fff] reserved
[0.00] BIOS-e820: [mem 0xdae93000-0xdaebcfff] ACPI data
[0.00] BIOS-e820: [mem 0xdaebd000-0xdb7f4fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xdb7f5000-0xdbafefff] reserved
[0.00] BIOS-e820: [mem 0xdbaff000-0xdbaf] usable
[0.00] BIOS-e820: [mem 0xdd00-0xdf7f] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00021f7f] usable
[0.00] NX (Execute Disable) protection: active
[0.00] APIC: Static calls initialized
[0.00] e820: update [mem 0xc4385018-0xc4395057] usable ==> usable
[0.00] e820: update [mem 0xc4385018-0xc4395057] usable ==> usable
[0.00] extended physical RAM map:
[

Bug#1061521: + XPS 13 9343

[Antoine]

On 1/20/24 21:26, Hans de Goede wrote:

Can you try adding "i8042.dumbkbd=1" to your kernel commandline?

The next question is if the keyboard will still actually
work after suspend/resume with "i8042.dumbkbd=1". If it
stays in the list, but no longer works


Hi, thanks a lot for taking into account our hardware,
just a supplementary feedback:

In my case (Dell XPS 13 9343/i5-5200U):
- Dell Inc. XPS 13 9343/0TM99H, BIOS A19 12/24/2018
- Linux version 6.6.13-1 (2024-01-20)

commandline with `i8042.dumbkbd=1` fixes the issue,
with capslock functional but without led
+ as a side note, hibernate doesn't trigger any issue

(before getting informed of and testing `i8042.dumbkbd=1`)
I had attached logs before/after suspend against 6.6.11 and 6.6.13 :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061521#30

I remain at your disposal for any further infos/testing
best regards,
Antoine

Bug#1062325: [Pkg-puppet-devel] Bug#1062325: leatherman: NMU diff for 64-bit time_t transition

[Antoine Beaupré]

On 2024-02-01 03:27:23, Steve Langasek wrote:

[...]

> If you have any concerns about this patch, please reach out ASAP.  Although
> this package will be uploaded to experimental immediately, there will be a
> period of several days before we begin uploads to unstable; so if information
> becomes available that your package should not be included in the transition,
> there is time for us to amend the planned uploads.

Hey Steve!

I don't have any concerns with the patch at the moment and, in fact,
it's a bit over my head.

But I just wanted to say a big loud THANK YOU FOR YOUR WORK! This is
thankless, hard, complicated, multi-party work that Debian really,
really needs people to do, and I'm glad someone is doing it.

So, again, thank you.

a.

-- 
Il est sage de nous réconcilier avec notre adolescence ; haїr, mépriser,
nier ou simplement oublier l’adolescent que nous fûmes est en soi une
attitude adolescente.
- Daniel Pennac, Comme un roman

Bug#1025062: systemd-resolved Provides: resolvconf, but is missing the isc-dhcp-client integration from resolvconf

[Antoine Durand-Gasselin]

On Mon, 8 May 2023 00:43:30 +0100 Ken Milmore 
wrote:
> I was motivated to try fixing this after installing systemd-resolved
on bookworm and finding that my DNS was completely broken.
> 
> I have tested the Ubuntu hook scripts with DHCP enabled for both IPv4
and/or IPv6. They work well for me so far.
> 
> I have attached a source patch against isc-dhcp master on Salsa. This
just adds the verbatim hook scripts from Ubuntu.
> [...]
> 

Dear Debian ISC DHCP Maintainers,

Broken DNS after installing systemd-resolved is quite annoying.
Ubuntu has come up with a fix for that, so is there anything blocking
using the same fix here ?

https://git.launchpad.net/ubuntu/+source/isc-dhcp/commit/?id=a37097f48d21f3ce34cf00ccf102141e55a32d08
https://git.launchpad.net/ubuntu/+source/isc-dhcp/commit/?id=7c7bcace3f8b9b06a701d940d7f1a8f1f12a15f4

Best regards,
Antoine

Bug#1061965: snac2: A new upstream release is available: 2.46

[Antoine Le Gonidec]

Package: snac2
Version: 2.45-1
Severity: wishlist

A new release of snac2 is available:
https://codeberg.org/grunfink/snac2/releases/tag/2.46

This one adds something I had been wishing for: support for following
Peertube channels, with new videos being included in the activity feed.
So snac2 can be used as a substitute to an RSS feed reader to follow the
activity of video channels.

It would be really nice if this build could be available from Debian
repositories.

As usual, big thanks for your work maintaining this package in Debian!

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#1061521: linux-image-6.6.13-amd64: 6.6.13-1 no more keyboard resuming from suspend

[Antoine]

On 1/25/24 22:08, Salvatore Bonaccorso wrote:

Is this a regression from 6.6.11-1


Yes


When you resume from suspend, do you get anything logged in the kernel log,
can you attach it here?


As it was mixed with other upgrades from testing (libc6, grub, polkit 
mainly),

for now I just rolled back from a backup, and did them incrementally
..to finish with only 6.6.13-1  which reproduced the issue.
I rolled back again so now I need to update my backup and will then try 
getting some logs

Bug#1060053: RFP: wayprompt -- multi-purpose (password-)prompt tool for Wayland

[Antoine Beaupré]

On 2024-01-05 12:02:20, Piotr Ożarowski wrote:

[...]

> Note that this project is written in Zig which is not packaged for Debian yet,
> I didn't find any other PinEntry replacement for Wayland.

Interesting project! Too bad we don't have Zig yet (or, maybe, that this
one is written in Zig...)

that said, i'm not sure what you mean by "for Wayland". I'm currently
using pinentry-qt and it works in Wayland. pinentry-gnome3 is also
packaged and works.

Neither of those properly grabs the keyboard in Sway, that said, but I
suspect this is probably an interoperability issue more than anything
else.

a.

-- 
Every one of us is, in the cosmic perspective, precious. If a human
disagrees with you, let him live. In a hundred billion galaxies, you
will not find another.   - Carl Sagan

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#964905: RFP: goatcounter -- easy, meaningful privacy-friendly web analytics

[Antoine Beaupré]

On 2020-07-17 13:29:56, Antoine Beaupré wrote:

[...]

> It also happens to provide a nice list of missing packages which, in a
> more digestable form, looks like this:
>
>  * code.soquee.net/otp
>  * github.com/go-chi/chi
>  * github.com/monoculum/formam
>  * github.com/teamwork/reload
>  * github.com/zgoat/kommentaar
>  * honnef.co/go/tools
>
> Note that zgoat/kommentaar is a fork of teamwork/kommentaar, something
> to keep in mind.
>
> This one is a fork of an existing package in Debian,
> golang-github-oschwald-geoip2-golang-dev, we'd need to investigate if
> that can be resolved:
>
>  * github.com/arp242/geoip2-golang
>
> The other dependencies are generally sane and could be packaged for Debian.

This is now really old, but just for kicks I looked around and those are
actually packed now, already:

>  * github.com/go-chi/chi
>  * honnef.co/go/tools

Which means that goatcounter, as it was 3 years ago (!), would only
require packaging those:

>  * code.soquee.net/otp
>  * github.com/monoculum/formam
>  * github.com/teamwork/reload
>  * github.com/zgoat/kommentaar

Obviously, we'd need to review this with the latest upstream code, but I
thought that was slightly encouraging.

a.

-- 
Il faut tout un village pour élever un enfant.
- Proverbe africain

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

[Antoine Beaupré]

On 2023-09-22 22:06:30, Antoine Beaupré wrote:
> On 2023-09-22 21:56:53, Birger Schacht wrote:
>> Hi anarcat,
>>
>> I'd rather not diverge from upstream and carry a patch for a bugfix that 
>> is a wontfix on upstreams side.
>> My hope is that upstream either reconsiders or that there is a another 
>> solution for that problem, that does not require us patching every new 
>> version of sway.
>
> Thanks. I'll rollback my patch and try to find another way.
>
> I strongly doubt upstream will reconsider, they seem to be pretty stuck
> up on that one...

My last attempt at this is now in:

https://github.com/swaywm/sway/pull/7904

Will need a wrapper script, far from ideal, but maybe more likely to succeed.

-- 
Freedom is being able to make decisions that affect mainly you. Power
is being able to make decisions that affect others more than you. If
we confuse power with freedom, we will fail to uphold real freedom.
- Richard Stallman

Bug#1060084: [Pkg-puppet-devel] Bug#1060084: puppet-agent: Resource type 'Cron' was not found, even after puppet-module-puppetlabs-cron-core installed

[Antoine Beaupré]

Control: forcemerge 1054664 1060084

On 2024-01-06 08:55:04, Will Partain wrote:
> Antoine Beaupré  wrote:
>
>> Is there any specific reason why you feel this should be adressed in a
>> different bug report than the above?
>
> Hi, Antoine -- stumbling into the "bug"? again, I realized it was probably 
> more likely a puppet agent bug, not the cron_core module.
>
> My understanding of the Debian bugs process is very slight.  But I know it is 
> a wondrously good thing!  Regards to all,

Right, no problem!

For future reference, I think in this case it would have been preferable
to just reuse the existing bug report, by replying to it.

So I'll be merging the two bugs, feel free to reply to any one of the
two. :)

a.
-- 
May your trails be crooked, winding, lonesome, dangerous, leading to
the most amazing view. May your mountains rise into and above the
clouds.
- Edward Abbey

Bug#1060084: [Pkg-puppet-devel] Bug#1060084: puppet-agent: Resource type 'Cron' was not found, even after puppet-module-puppetlabs-cron-core installed

[Antoine Beaupré]

On 2024-01-05 19:02:38, Will Partain wrote:
> Package: puppet-agent
> Version: 7.23.0-1
> Severity: important
>
> Dear Maintainer,
>
> (This is a more detailed version of 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054664 )

Is there any specific reason why you feel this should be adressed in a
different bug report than the above?

Otherwise those two reports should just be merged, but in any case,
thanks for the extra information! :)

a.
-- 
Being cynical is the only way to deal with modern civilization — you
can't just swallow it whole.
- Frank Zappa

Bug#1059222: src:pv: fails to migrate to testing for too long: FTBFS on armhf

[Antoine Beaupré]

Hi Andrew!

This is a quick word to let you know that I've disabled valgrind tests
on armhf in the Debian package. They were failing since the 1.8.5 upload
(but possibly not in 1.8.0!), you can see a log here:

https://buildd.debian.org/status/fetch.php?pkg=pv=armhf=1.8.5-1=1700453788=0

Unfortunately, the failed build doesn't show the valgrind output, so
it's unclear exactly what's going on...

I might be able to get an armhf box to test this if you can't, let me
know how we should move ahead on this. For now, it seems better to
unblock the package so it trickles down to testing, considering how
slightly more flacky those tests are...

let me know!

a.

Bug#1042062: RFP: mdformat -- Markdown formatter that can be used to enforce a consistent style in Markdown files.

[Antoine Beaupré]

Control: tags -1 +pending +patch

Hi!

There's now a package for this! It was relatively easy to build, thanks
to py2dsp and the excellent pybuild toolchain (and the fact that
upstream doesn't have any dep missing from debian).

I pushed the code to salsa:

https://salsa.debian.org/python-team/packages/mdformat

... and it should land in NEW shortly as well.

One thing that's going to be missing here is the plethora of plugins in
the mdformat ecosystem. In my experiments, *most* markdown files I find
have at least need for *one* of those plugins, e.g. at least tables and
front matter, in my case.

I'm even going to need an extra plugin for GitLab's `[[_TOC_]]` thing,
although arguably that could be replaced by the mdformat-toc plugin as
well.

So I'm not sure how to package those: it seems silly to have one package
for each plugin, but maybe that's the simplest way forward, as I'm not
sure I want to deal with a multi-tarball thing...

Anyways, let me know if that works for you!

a.
-- 
Imagination is more important than knowledge.
Knowledge is limited.
Imagination encircles the world.
- Albert Einstein

Bug#1042062: RFP: mdformat -- Markdown formatter that can be used to enforce a consistent style in Markdown files.

[Antoine Beaupré]

Control: owner -1 anar...@debian.org
Control: retitle -1 ITP: mdformat -- Markdown formatter that can be used to 
enforce a consistent style in Markdown files.

I'm looking into this. The code is too large for a full audit, but i can
confirm third parties have packaged it and their checksums match, at
least FreeBSD does:

https://www.freshports.org/textproc/py-mdformat

SHA256 (executablebooks-mdformat-0.7.17_GH0.tar.gz) = 
833919e616c64cba88b8af09e485cd6b440366f572f963f2b18ea89b0d5c4416

This actually does *not* match the tarball on pypi, but it matches the
one on GitHub. And diffoscope only shows metadata differences between
the two. So I'll start with that.



signature.asc
Description: PGP signature

Bug#1058938: bookworm-pu: package onionprobe/1.0.0+ds-2.1+deb12u1

[Antoine Beaupré]

I have reviewed this patch and it looks sane to me. I have deployed the
updated package on our servers and it is so far running without flaw.

A.

-- 
There is no cloud, it's just someone else's computer.
   - Chris Watterson

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#899245: kgb-bot: support for password-protected channels

[Antoine Beaupré]

On 2023-12-13 08:34:02, Yves-Alexis Perez wrote:

[...]

> since the bug is from 2018, I have to admit I don't really remember why I
> opened it and what channel was the target. I don't have a way to test the
> patch these days, but thanks for the work anyway.

Well, the patch *is* tested, and is running in propduction already. So I
suspect it works well enough for most cases.

What I would love is some review of my perl-fu, just visually, without
running anything. I made some comments on the MR that expand on that;
I'm particularly wondering about the map { $_ => 1 } structure and the
test suite.

Thanks!

-- 
Semantics is the gravity of abstraction.

Bug#899245: kgb-bot: support for password-protected channels

[Antoine Beaupré]

Control: tags -1 +patch

On 2018-05-21 16:01:59, Yves-Alexis Perez wrote:
> subject mostly says it all, but it'd be nice if KGB could support
> password-protected IRC channels for notifications.

The library backing KGB does support it, so it seems it's only a matter
of a few lines patch:

https://salsa.debian.org/kgb-team/kgb/-/merge_requests/8

Also attached.

Please test and report back here or, preferably, in the above merge request.

a.

-- 
The secret of life is to have no fear; it's the only way to function.
- Stokely Carmichael
>From e904a049138a0cbae7ae9e72ecc0f65f9579837f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
Date: Tue, 12 Dec 2023 16:33:35 -0500
Subject: [PATCH] channel secret support (Closes: #899245)

---
 script/kgb-bot | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/script/kgb-bot b/script/kgb-bot
index 34ffdf5..6bc422a 100755
--- a/script/kgb-bot
+++ b/script/kgb-bot
@@ -296,7 +296,7 @@ sub read_conf ($) {
 die "Missing channel name at channel\n" unless ( $_->{name} );
 die "Invalid network at channel " . $_->{name} . "\n"
 unless ( $_->{network} and $conf->{networks}{ $_->{network} } );
-push @{ $conf->{networks}{ $_->{network} }{channels} }, $_->{name};
+$conf->{networks}{ $_->{network} }{channels}{$_->{name}} = $_->{secret};
 my $chanid = KGB->get_chanid( $_->{network}, $_->{name} );
 die "Invalid repos key at channel $chanid\n"
 unless $_->{broadcast}
@@ -947,8 +947,8 @@ sub _irc_reconnect {
 }
 else {
 my ( %newchan, %oldchan, %allchan );
-%newchan = map( { $_ => 1 } @{ $new->{channels} } );
-%oldchan = map( { $_ => 1 } @{ $old->{channels} } );
+%newchan = map( { $_ => 1 } %{ $new->{channels} } );
+%oldchan = map( { $_ => 1 } %{ $old->{channels} } );
 %allchan = ( %newchan, %oldchan );
 foreach my $chan ( keys %allchan ) {
 if ( $newchan{$chan} and !$oldchan{$chan} ) {
@@ -1094,7 +1094,8 @@ sub add_channel ($$$) {
 unless (exists $KGB::config->{networks}{$network});
 return if (exists $KGB::config->{chanidx}{$chanid});
 
-push @{ $KGB::config->{networks}{$network}{channels} }, $channel;
+# secret-less
+$KGB::config->{networks}{$network}{channels}{$channel} = '';
 $KGB::config->{chanidx}{$chanid} = {
 name => $channel,
 network => $network,
@@ -1124,11 +1125,12 @@ sub irc_001 {
 my ( $kernel, $sender ) = @_[ KERNEL, SENDER ];
 my $net = get_net($sender);
 my $channels = $KGB::config->{networks}{$net}{channels};
+my @channel_names = keys %{$channels};
 
 # Get the component's object at any time by accessing the heap of
 # the SENDER
 KGB->out( "Connected to $net (", $sender->get_heap->server_name(), ")\n" );
-KGB->out( "Joining @$channels...\n" ) if ($channels);
+KGB->out( "Joining @channel_names...\n" ) if ($channels);
 undef;
 }
 
-- 
GitLab

Bug#1013285: needrestart: Failed to check for processor microcode upgrades.

[Antoine Beaupré]

On 2023-12-12 15:39:24, Patrick Matthäi wrote:

[...]

>> It doesn't *quite* fix it just yet. For platforms where the ucode is
>> *not* provided (e.g. in my case it's the pcengines APU that don't have
>> firmware upgrades), this *still* yields a UNKNOWN warning. After a brief
>> discussion in the issue tracker, I decided to submit *another* PR as
>> such:
>>
>> https://github.com/liske/needrestart/pull/290
>>
>> ... and I think we should ship this in Debian as well.
>>
>> I also think we should make a stable update for this. This affects a
>> bunch of machines on our end and we need this fixed in bookworm.
>>
>> So I'll file a bug with the release team and prepare a stable
>> update.
>>
>> Patrick: objections?
>>
>> A.
>
> I will upload this patch now with 3.6-7. I am fine with a stable update 
> and would welcome it if you could do it in this case (I am a bit busy 
> these weeks)

I believe the update proposed in #1056358 fixes this. It's unclear to me
why it missed the 12.3 window - maybe I should have just uploaded it
already - but alas, this is where we're at now. :(

a.
-- 
O gentilshommes, la vie est courte.
Si nous vivons, nous vivons 
pour marcher sur la tête des rois.
- William Shakespeare

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

[Antoine Beaupré]

sorry, i'm kind of swamped until 2024 over here, really interested in
the software, but i didn't even try it out so i don't know if i can
help... did you try reaching out upstream?

On 2023-12-06 08:32:49, Martin wrote:
> Hi Antoine,
>
> I'm started here:
>
> https://salsa.debian.org/python-team/packages/pass-secret-service
>
> So far, it doesn't work for me.
> Maybe I'm missing sth. about D-Bus activation?
>
> Any help appreciated, because I'm a little bit short on time.
>
> Cheers
>
> Btw. I tested with Gajim, which uses python3-keyring, and configured
>
> ~/.config/python_keyring/keyringrc.cfg
>
> with:
>
> [backend]
> default-keyring=keyring.backends.SecretService.Keyring

-- 
Evil exists to glorify the good. Evil is negative good.
It is a relative term. Evil can be transmuted into good.
What is evil to one at one time,
becomes good at another time to somebody else.
- Sivananda

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

[Antoine Beaupré]

Control: tags -1 - moreinfo

On 2023-12-02 18:52:39, Adam D. Barratt wrote:
> There doesn't appear to be a debdiff attached.

What is wrong with me.

diff -Nru needrestart-3.6/debian/changelog needrestart-3.6/debian/changelog
--- needrestart-3.6/debian/changelog	2023-05-31 10:47:03.0 -0400
+++ needrestart-3.6/debian/changelog	2023-11-15 15:05:37.0 -0500
@@ -1,3 +1,9 @@
+needrestart (3.6-4+deb12u1) bookworm; urgency=medium
+
+  * fix microcode check regression on AMD CPUs (Closes: #1013285)
+
+ -- Antoine Beaupré   Wed, 15 Nov 2023 15:05:37 -0500
+
 needrestart (3.6-4) unstable; urgency=medium
 
   * Remove leftover conffile 30-pacman with 3.6-4.
diff -Nru needrestart-3.6/debian/patches/05-fix-AMD-ucode-checking-in-non-debug-mode.patch needrestart-3.6/debian/patches/05-fix-AMD-ucode-checking-in-non-debug-mode.patch
--- needrestart-3.6/debian/patches/05-fix-AMD-ucode-checking-in-non-debug-mode.patch	1969-12-31 19:00:00.0 -0500
+++ needrestart-3.6/debian/patches/05-fix-AMD-ucode-checking-in-non-debug-mode.patch	2023-11-15 15:05:37.0 -0500
@@ -0,0 +1,33 @@
+From b073fb6d9969597173daa8c511a85bae9b03ed37 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
+Date: Wed, 15 Nov 2023 15:20:37 -0500
+Subject: [PATCH] fix AMD ucode checking in non-debug mode
+
+It looks like the assignment when the ucode exist was not
+done *unless* `debug` (`-v`) was set. Therefore, all AMD microcode
+checks were returning UNKNOWN, including in Nagios checks, unless the
+`-v` ("verbose", but actually `debug`) was passed.
+
+Closes: #249
+---
+ perl/lib/NeedRestart/uCode/AMD.pm | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/perl/lib/NeedRestart/uCode/AMD.pm b/perl/lib/NeedRestart/uCode/AMD.pm
+index 638e68d..6daad8f 100644
+--- a/perl/lib/NeedRestart/uCode/AMD.pm
 b/perl/lib/NeedRestart/uCode/AMD.pm
+@@ -185,8 +185,8 @@ sub nr_ucode_check_real {
+ if ( exists( $_ucodes->{cpuid}->{$cpuid} ) ) {
+ my $prid = $_ucodes->{cpuid}->{$cpuid};
+ if ( exists( $_ucodes->{prid}->{$prid} ) ) {
+-$vars{AVAIL} = sprintf( "0x%08x", $_ucodes->{prid}->{$prid} ),
+-		print STDERR "$LOGPREF #$info->{processor} found ucode $vars{AVAIL}\n" if ($debug);
++$vars{AVAIL} = sprintf( "0x%08x", $_ucodes->{prid}->{$prid} );
++print STDERR "$LOGPREF #$info->{processor} found ucode $vars{AVAIL}\n" if ($debug);
+ 	}
+ }
+ 
+-- 
+2.39.2
+
diff -Nru needrestart-3.6/debian/patches/06-uCode-fix-uninitialized-value-in-logging-of-processo.patch needrestart-3.6/debian/patches/06-uCode-fix-uninitialized-value-in-logging-of-processo.patch
--- needrestart-3.6/debian/patches/06-uCode-fix-uninitialized-value-in-logging-of-processo.patch	1969-12-31 19:00:00.0 -0500
+++ needrestart-3.6/debian/patches/06-uCode-fix-uninitialized-value-in-logging-of-processo.patch	2023-11-15 15:05:37.0 -0500
@@ -0,0 +1,30 @@
+From e85bfe33b595b88cc8052a7815d13612ecc2a841 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Stefan=20B=C3=BChler?= 
+Date: Sun, 28 May 2023 17:42:28 +0200
+Subject: [PATCH] [uCode] fix uninitialized value in logging of processor index
+
+This got broken in f8c2609f8d5a0e10bd988497b8ea9815a7bb2fa8.
+
+Before that it would have effectively logged
+`$processors{$pid}->{processor}`, but the `processor` entry
+is also the key in `%processors`, i.e. equals `$pid`.
+---
+ perl/lib/NeedRestart/uCode.pm | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/perl/lib/NeedRestart/uCode.pm b/perl/lib/NeedRestart/uCode.pm
+index 6251339..db81375 100644
+--- a/perl/lib/NeedRestart/uCode.pm
 b/perl/lib/NeedRestart/uCode.pm
+@@ -148,7 +148,7 @@ sub nr_ucode_check {
+ }
+ $ui->progress_step;
+ 
+-my $nstate = compare_ucode_versions( $debug, $processors{processor}, @nvars );
++my $nstate = compare_ucode_versions( $debug, $pid, @nvars );
+ if ( $nstate > $state ) {
+ ( $state, @vars ) = ( $nstate, @nvars );
+ }
+-- 
+2.39.2
+
diff -Nru needrestart-3.6/debian/patches/07-mark-unavailable-firmware-as-CURRENT.patch needrestart-3.6/debian/patches/07-mark-unavailable-firmware-as-CURRENT.patch
--- needrestart-3.6/debian/patches/07-mark-unavailable-firmware-as-CURRENT.patch	1969-12-31 19:00:00.0 -0500
+++ needrestart-3.6/debian/patches/07-mark-unavailable-firmware-as-CURRENT.patch	2023-11-15 15:05:37.0 -0500
@@ -0,0 +1,61 @@
+From 0e1ffe8025416a918ddf169f2d858762733d7238 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
+Date: Tue, 21 Nov 2023 10:59:32 -0500
+Subject: [PATCH] mark unavailable firmware as CURRENT
+
+This changes the policy of reporting missing firmware updates as
+"UNKNOWN". Now, if there's no available firmware, we report
+"current". That fixes needrestart on platforms that do

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 Beaupré]

On 2023-11-30 13:06:19, Matthias Geiger wrote:

[...]

> looks packageable from a first glance with only gtk-layer-shell missing 
> for anyrun and anyrun-interface. An issue is gtk-layer-shell which 
> contains generated code; gtk-rs has the same issue but I resolved that 
> via re-generating the code. I pondered whether I should package 
> gtk-layer-shell but haven't found a use case so far. If someone wants to 
> package it they should take a look at gtk4-sys for instance and must (!) 
> regenerate the code the same way. Feel free to ask me about that.

Whoa, that's way better than I expected!

I guess lots of things are plugins in there so we could package the core
without having to fix all deps. For example, rink is its whole own app
that anyrun links with, but it would definitely need to be packaged
seperately as it's a calculator that we should (IMHO) really have on its
own in Debian as well...

a.

-- 
Vivre tous simplement pour que tous puissent simplement vivre.
- Gandhi

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#1054442: forgot debdiff

[Antoine Beaupré]

On 2023-11-29 22:24:25, Adam D. Barratt wrote:
> On Mon, 2023-10-23 at 15:36 -0400, Antoine Beaupré wrote:
>> And of course I forgot the debdiff, sorry!
>
> Please go ahead.

Uploaded, thanks for the review!!

-- 
Science knows still practically nothing about the real nature of
matter, energy, dimension, or time; and even less about those
remarkable things called life and thought. But whatever the meaning
and purpose of this universe, you are a legitimate part of it.
- Gene Roddenberry

Bug#1057067: new upstream release (1.65)

[Antoine Beaupré]

On 2023-11-29 20:56:22, Tobias Quathamer wrote:
> Am 29.11.23 um 04:55 schrieb 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? :)
>
> Hi Antoine,
>
> yes, absolutely! :-)
>
> I'm lacking the time to take care of all needed (build-)dependencies of 
> rclone, that's the main reason why 1.65 is not in Debian yet. If you're 
> willing to help, great! Please feel free to commit directly to the 
> package repository on salsa.
>
> I can see that you're in the Go team as well, so you should have write 
> access to that repository.

Lots of new deps in 1.60+?

-- 
Si l'image donne l'illusion de savoir
C'est que l'adage pretend que pour croire,
L'important ne serait que de voir
- Lofofora

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#1013285: needrestart: Failed to check for processor microcode upgrades.

[Antoine Beaupré]

Control: reopen -1
Control: subscribe -1

On 2023-11-15 15:46:24, Antoine Beaupré wrote:
> Control: tags -1 +patch
>
> On 2023-11-15 14:54:26, Antoine Beaupré wrote:
>> On 2022-06-20 13:54:38, Nick Lewycky wrote:
>>> Package: needrestart
>>> Version: 3.6-1
>>> Severity: normal
>>>
>>> `sudo needrestart -w` always prints "Failed to check for processor
>>> microcode upgrades." on my AMD Ryzen 9 3900X 12-Core Processor.
>>
>> [...]
>>
>> There's now a PR for this upstream:
>>
>> https://github.com/liske/needrestart/pull/285
>>
>> People suffering from this issue are encouraged to test this and report
>> back upstream (or here, if you can't upstream).
>
> I tested it and it doesn't work. It only *seemed* to work because the
> author tested with -v, which *does* work around the issue.
>
> I found the issue, and sent this PR upstream to fix it:
>
> https://github.com/liske/needrestart/pull/288
>
> Patch attached, people are again encouraged to test and report back.
>
> I also attach upstream commit v3.6-9-ge85bfe3 which also seem necessary
> to fix firmware checks on my end...

It doesn't *quite* fix it just yet. For platforms where the ucode is
*not* provided (e.g. in my case it's the pcengines APU that don't have
firmware upgrades), this *still* yields a UNKNOWN warning. After a brief
discussion in the issue tracker, I decided to submit *another* PR as
such:

https://github.com/liske/needrestart/pull/290

... and I think we should ship this in Debian as well.

I also think we should make a stable update for this. This affects a
bunch of machines on our end and we need this fixed in bookworm.

So I'll file a bug with the release team and prepare a stable
update.

Patrick: objections?

A.

-- 
All governments are run by liars and nothing they say should be
believed.
   - I. F. Stone

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#1055284: Acknowledgement (RFP: harpoon -- CLI tool for open source and threat intelligence)

[Antoine Beaupré]

On 2023-11-03 10:30:49, Antoine Beaupré wrote:
> https://github.com/kpcyrd/sn0int
> https://github.com/aancw/Belati
> https://github.com/nitefood/asn

Another, more minimalistic tool is simply a DNS resolver with support
for looking up ASNs:

https://github.com/natesales/q

Specifically those options are interesting:

  -w   Resolve ASN/ASName for A and  records
  -R, --resolve-ipsResolve PTR records for IP addresses in A and
    records

It's unclear how much batch support this supports and obviously it
doesn't do much beyond that (e.g. no lookup on other databases or
geoip...)

a.

-- 
If I can't dance, I don't want to be part of your revolution.
- Emma Goldman

Bug#1013285: needrestart: Failed to check for processor microcode upgrades.

[Antoine Beaupré]

Control: tags -1 +patch

On 2023-11-15 14:54:26, Antoine Beaupré wrote:
> On 2022-06-20 13:54:38, Nick Lewycky wrote:
>> Package: needrestart
>> Version: 3.6-1
>> Severity: normal
>>
>> `sudo needrestart -w` always prints "Failed to check for processor
>> microcode upgrades." on my AMD Ryzen 9 3900X 12-Core Processor.
>
> [...]
>
> There's now a PR for this upstream:
>
> https://github.com/liske/needrestart/pull/285
>
> People suffering from this issue are encouraged to test this and report
> back upstream (or here, if you can't upstream).

I tested it and it doesn't work. It only *seemed* to work because the
author tested with -v, which *does* work around the issue.

I found the issue, and sent this PR upstream to fix it:

https://github.com/liske/needrestart/pull/288

Patch attached, people are again encouraged to test and report back.

I also attach upstream commit v3.6-9-ge85bfe3 which also seem necessary
to fix firmware checks on my end...

a.

-- 
Advertisers, not governments, are the primary censors of media content 
in the United States today.
- C. Edwin Baker
>From b073fb6d9969597173daa8c511a85bae9b03ed37 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
Date: Wed, 15 Nov 2023 15:20:37 -0500
Subject: [PATCH] fix AMD ucode checking in non-debug mode

It looks like the assignment when the ucode exist was not
done *unless* `debug` (`-v`) was set. Therefore, all AMD microcode
checks were returning UNKNOWN, including in Nagios checks, unless the
`-v` ("verbose", but actually `debug`) was passed.

Closes: #249
---
 perl/lib/NeedRestart/uCode/AMD.pm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/perl/lib/NeedRestart/uCode/AMD.pm b/perl/lib/NeedRestart/uCode/AMD.pm
index 638e68d..6daad8f 100644
--- a/perl/lib/NeedRestart/uCode/AMD.pm
+++ b/perl/lib/NeedRestart/uCode/AMD.pm
@@ -185,8 +185,8 @@ sub nr_ucode_check_real {
 if ( exists( $_ucodes->{cpuid}->{$cpuid} ) ) {
 my $prid = $_ucodes->{cpuid}->{$cpuid};
 if ( exists( $_ucodes->{prid}->{$prid} ) ) {
-$vars{AVAIL} = sprintf( "0x%08x", $_ucodes->{prid}->{$prid} ),
-		print STDERR "$LOGPREF #$info->{processor} found ucode $vars{AVAIL}\n" if ($debug);
+$vars{AVAIL} = sprintf( "0x%08x", $_ucodes->{prid}->{$prid} );
+print STDERR "$LOGPREF #$info->{processor} found ucode $vars{AVAIL}\n" if ($debug);
 	}
 }
 
-- 
2.39.2

>From e85bfe33b595b88cc8052a7815d13612ecc2a841 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20B=C3=BChler?= 
Date: Sun, 28 May 2023 17:42:28 +0200
Subject: [PATCH] [uCode] fix uninitialized value in logging of processor index

This got broken in f8c2609f8d5a0e10bd988497b8ea9815a7bb2fa8.

Before that it would have effectively logged
`$processors{$pid}->{processor}`, but the `processor` entry
is also the key in `%processors`, i.e. equals `$pid`.
---
 perl/lib/NeedRestart/uCode.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/perl/lib/NeedRestart/uCode.pm b/perl/lib/NeedRestart/uCode.pm
index 6251339..db81375 100644
--- a/perl/lib/NeedRestart/uCode.pm
+++ b/perl/lib/NeedRestart/uCode.pm
@@ -148,7 +148,7 @@ sub nr_ucode_check {
 }
 $ui->progress_step;
 
-my $nstate = compare_ucode_versions( $debug, $processors{processor}, @nvars );
+my $nstate = compare_ucode_versions( $debug, $pid, @nvars );
 if ( $nstate > $state ) {
 ( $state, @vars ) = ( $nstate, @nvars );
 }
-- 
2.39.2

Bug#1013285: needrestart: Failed to check for processor microcode upgrades.

[Antoine Beaupré]

On 2022-06-20 13:54:38, Nick Lewycky wrote:
> Package: needrestart
> Version: 3.6-1
> Severity: normal
>
> `sudo needrestart -w` always prints "Failed to check for processor
> microcode upgrades." on my AMD Ryzen 9 3900X 12-Core Processor.

[...]

There's now a PR for this upstream:

https://github.com/liske/needrestart/pull/285

People suffering from this issue are encouraged to test this and report
back upstream (or here, if you can't upstream).

I've also bumped the severity of this bug. For us it leads to alert
fatigue and creates security and reliability issues.

a.
-- 
Je viens d'un pays où engagé veut dire que tu t'es trouvé une job.
- Patrice Desbiens

Bug#1042356: rapid-photo-downloader: FTBFS: make: *** [debian/rules:8: clean] Error 25

[Antoine Beaupré]

Control: tags -1 +patch

There's a patch posted in this thread for this bug:

https://discuss.pixls.us/t/patch-for-newer-python-setuptools/36593

Actual link to the patch on Arch:

https://build.opensuse.org/request/show/1078462
-- 
The odds are greatly against you being immensely smarter than everyone
else in the field. If your analysis says your terminal velocity is
twice the speed of light, you may have invented warp drive, but the
chances are a lot better that you've screwed up.
- Akin's Laws of Spacecraft Design

Bug#1055793: snac2: A new upstream release is available: 2.42

[Antoine Le Gonidec]

Package: snac2
Version: 2.41-1
Severity: wishlist

Please consider packaging the new 2.42 upstream release:
https://codeberg.org/grunfink/snac2/releases/tag/2.42

It has been requested by a reader of my snac instance, because it
includes a fix for the broken RSS feed:
https://codeberg.org/grunfink/snac2/issues/81
(the bug report has not been closed yet, but the fix is listed in the
release notes of version 2.42)

Thanks for your work on maintaining the package for snac2, I would have
never considered connecting to the Fediverse without it ;)

Bug#1055284: followup on use case

[Antoine Beaupré]

More notes on my use case... harpoon serves this poorly, as I explain
upstream here:

https://github.com/Te-k/harpoon/issues/190#issuecomment-1798667942

Basically, harpoon has a good `intel` command to lookup the reputation
of a single IP address on multiple plugins. But that's it: it works only
a on a *single* IP address, not *multiple*.

Also, it doesn't seem like it works very reliably on all backends. For
example, even though the `vt` command works, it doesn't seem to hookup
with the `intel` command.

Effectively, what harpoon fundamentally is is a wrapper around many
backend services. The most interesting I have found are:

 * asn and the asncount command in harpoontools: ASN to name mappings
   from https://ftp.ripe.net/ripe/asnames/asn.txt,
   ftp://archive.routeviews.org/datapath/MM/ribs/
   http://archive.routeviews.org/bgpdata/%d.%02d/RIBS (from pyasn
   package)

 * dns: simple reverse/forward DNS checks, not in intel either

 * ipinfo.io: provides ASN lookups, VPN/Tor/Proxy checks

 * pulsedive.com: tor, blocklists, cryptomining, threat reports

 * threatminer.org: unclear
 
 * tor: check tor exit lists, pulls
   https://check.torproject.org/torbulkexitlist on each call (!)

 * urlhaus.abuse.ch: more malware oriented, https://threatfox.abuse.ch
   more interesting but not implemented

 * virustotal (vt command): domain, IP reputation, history, API, free to
   use but rate limited unless a premium account is requested (note that
   there's a separate RFP for the vt-cli commandline, #1034826)

Then there's a bunch more interesting resources that are not implemented
yet but that are still interesting:

 * criminalip.io: abuse records, botnet, Tor, VPN, Proxy, Hosting, CDN,
   mobile, scanner checks, requires plan to do more
   https://github.com/Te-k/harpoon/issues/184

 * crowdsec.net: federated collaborative IP reporting, free daily data
   source https://github.com/Te-k/harpoon/issues/199

 * project honeypot: lists IPs that fell into a honeypot,
   https://github.com/Te-k/harpoon/issues/64

 * proxycheck.io: simple API, Tor, Proxy, "type" (business, wireless,
   residential, etc), VPN check,
   https://github.com/Te-k/harpoon/issues/110

More services I found in my search that could be useful to tap for extra
confirmations:

 * abuseipdb.com: abuse reports

 * dronebl.org: abuse reports of "infected machines", RBL

 * check.spamhaus.org: classic spammer database, RBL

Alright, that's what I got so far!

a.

-- 
The destiny of Earthseed is to take root among the stars.
- Octavia Butler

Bug#1055284: preliminary research

[Antoine Beaupré]

I've also looked for more alternatives, thinking "surely someone else
fixed this in a more simple way". I looked mostly at
https://kali.org/tools for now.

Out of those, i have selected the following tools:

 https://www.maltego.com/
 https://github.com/smicallef/spiderfoot
 https://github.com/SparrowOchon/dnsenum2
 https://github.com/GoVanguard/legion
 https://github.com/owasp-amass/amass

A.
-- 
The problem is not a lack of highly educated workers, the problem is a
lack of highly educated workers willing to work for the minimum wage or
lower in the U.S. Costs are driving outsourcing, not the quality of
American schools.   - Scott Kirwin, IT Professionals Association

Bug#1055284: preliminary research

[Antoine Beaupré]

I started working on a Docker container for this, based on a Debian
container. To simplify the install (e.g. not require rebuilding lxml), I
pre-install a bunch of Debian packages for Python dependencies, but a
*lot* are missing.

The following are present:

python3-bs4 \
python3-dateutil \
python3-dnspython \
python3-geoip2 \
python3-ipy \
python3-lxml \
python3-maxminddb \
python3-phonenumbers \
python3-pip \
python3-psycopg2 \
python3-pyasn \
python3-pygments \
python3-tz \
python3-requests \
python3-selenium \
python3-setproctitle \
python3-simplejson \
python3-telethon \
python3-virustotal-api \

But the following are not:

"OTXv2",
"PyGitHub>=1.55",
"archiveis",
"censys==2.2.0",
"consolemd==0.5.1",
"fullcontact.py",
"greynoise>=1.2.0",
"passivetotal>=2.5.9",
"pybinaryedge==0.5",
"pycrtsh==0.3.11",
"pyhashlookup==1.2.1",
"pyhunter",
"pymisp==2.4.159",
"pypdns==1.3",
"pypermacc==0.1.1",
"pysafebrowsing==0.1.2",
"pysecuritytrails==0.1.3",
"pythreatgrid2==0.1.1",
"shodan",
"spyonweb==0.1",
"threatminer==1.0",
"tweepy>=3.8.0",
"zetalytics-api==1.0.1",

The following are available in Debian, but somehow pinned or declared in
a way that makes pip still install them

"beautifulsoup4==4.11.1",
"configparser",
"lxml==4.9.2",
"phonenumbers==8.12.4",
"simplejson==3.17.6"
"telethon==0.19.1.6",

So if we actually want everything in harpoon to actually work, there is
a *lot* of work to package dependencies here.

-- 
You can't get to the moon by climbing successively taller trees.
- Akin's Laws of Spacecraft Design

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

[Antoine Beaupré]

After writing this report, I have also found two alternate
implementation, one is an actual IRC server and the other an irssi
plugin.

https://github.com/mk-fg/reliable-discord-client-irc-daemon
https://github.com/mjsir911/irssi-discord

the ircd has this interesting WARNING that Discord might consider any
non-native client to be a bot and accordingly banned.

a.
-- 
Non qui parum habet, sed qui plus cupit, pauper est.
It is not the man who has too little, but the man who craves more,
that is poor.- Lucius Annaeus Seneca (65 AD)

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: Acknowledgement (RFP: harpoon -- CLI tool for open source and threat intelligence)

[Antoine Beaupré]

Another thing I forgot, the author wrote a good guide on their blog in:

https://randhome.io/blog/2018/02/23/harpoon-an-osint-/-threat-intelligence-tool/

-- 
The steel horse fills a gap in modern life, it is an answer not only to
its needs, but also to its aspirations.  It's quite certainly here to
stay.
 - Le Vélocipède Illustré, 1869

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

[Antoine Beaupré]

Control: forwarded -1 https://github.com/Te-k/harpoon/issues/195

Oh, and another thing I forgot: the harpoon wiki names a few
alternatives to this.

https://github.com/Te-k/harpoon/wiki#other-tools

Of those, the following might be interesting:

https://github.com/kpcyrd/sn0int
https://github.com/aancw/Belati

Out of band, someone also mentioned nmap as an alternative already
packaged in Debian, but I figured nmap was a much more active tool than
what I am looking for here.

Finally, there's also this tool I found that does a *lot* of what I
want:

https://github.com/nitefood/asn

... but it's kind of a messy shell script, which is why I am hoping to
package harpoon instead.

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#1028212: proposed stable release update

[Antoine Beaupré]

I have filed #1055115 to update the package in bookworm.

a.
-- 
Nothing in life is to be feared, it is only to be understood.
Now is the time to understand more, so that we may fear less.
 - Marie Curie

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:
+
+https://bugs.launchpad.net/ubuntu/+source/apt

Bug#1054608: tt-rss: New entries always marked as read even if the unread counter is not null

[Antoine EMERIT]

Package: tt-rss
Version: 21~git20210204.b4cbc79+dfsg-1.2
Severity: normal
Tags: patch

Dear Maintainer,

After a dist-upgrade my server from Debien 11 to Debian 12, my Tiny Tiny RSS 
server diplays
all new entries as already ridden. The unread counters are not impacted.

To reproduce : 
- access to new unread entries in any categories (or in "Unread Articles"), 
unread entries
  are well displayed but the title text is greyed.
- the unread filter is well applied and the unread counters count theses 
entries.
- manually mark an entry as unread -> counter doens't change (this is correct)
- manually mark an entry as read -> counter is correctly decreased (this is 
correct)

After a search in the javascript, I see that the entry JSON attribut returned 
by the
backend.php is always "unread: 0".

In the class/feeds.php at line 258, I see a specific code that check the unread 
database
value and retest it in case of mysql :

if (DB_TYPE == "mysql") {
   foreach (["unread", "marked", "published"] as $k) {
  $line[$k] = $line[$k] === "1";
   }
}

I suspect a change in the MariaDB upgrade that cause this problem.

I propose the following simple modification :
diff classes/feeds.php classes/feeds.php.old
258c258
<   $line[$k] = $line[$k]  === 1 || 
$line[$k] === "1";
---
>   $line[$k] = $line[$k] === "1";

Regards


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

Kernel: Linux 6.1.0-13-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 tt-rss depends on:
ii  dbconfig-common   2.0.24
ii  dbconfig-pgsql2.0.24
ii  debconf [debconf-2.0] 1.5.82
ii  fonts-material-design-icons-iconfont  6.7.0+dfsg-1
ii  init-system-helpers   1.65.2
ii  libapache2-mod-php2:8.2+93
ii  libapache2-mod-php8.2 [php-json]  8.2.7-1~deb12u1
ii  libjs-dojo-core   1.17.2+dfsg1-2.1
ii  libjs-dojo-dijit  1.17.2+dfsg1-2.1
ii  libjs-scriptaculous   1.9.0-3
ii  lsb-base  11.6
ii  php   2:8.2+93
ii  php-cli   2:8.2+93
ii  php-intl  2:8.2+93
ii  php-json  2:8.2+93
ii  php-mbstring  2:8.2+93
ii  php-mysql 2:8.2+93
ii  php-php-gettext   1.0.12-5
ii  php-psr-log   1.1.4-2
ii  php-xml   2:8.2+93
ii  php8.2 [php]  8.2.7-1~deb12u1
ii  php8.2-cli [php-json] 8.2.7-1~deb12u1
ii  php8.2-intl [php-intl]8.2.7-1~deb12u1
ii  php8.2-mbstring [php-mbstring]8.2.7-1~deb12u1
ii  php8.2-phpdbg [php-json]  8.2.7-1~deb12u1
ii  php8.2-xml [php-xml]  8.2.7-1~deb12u1
ii  phpqrcode 1.1.4-3.1
ii  sysvinit-utils [lsb-base] 3.06-4

Versions of packages tt-rss recommends:
ii  apache2 [httpd] 2.4.57-2
ii  ca-certificates 20230311
ii  php-curl2:8.2+93
ii  php-gd  2:8.2+93
pn  php-mcrypt  
ii  php8.2-curl [php-curl]  8.2.7-1~deb12u1
ii  php8.2-gd [php-gd]  8.2.7-1~deb12u1

Versions of packages tt-rss suggests:
pn  php-apc   
pn  sphinxsearch  

-- Configuration Files:
/etc/tt-rss/config.php changed [not included]

-- debconf information excluded

-- debsums errors found:
debsums: changed file /usr/share/tt-rss/www/classes/feeds.php (from tt-rss 
package)
debsums: changed file /usr/share/tt-rss/www/include/errorhandler.php (from 
tt-rss package)

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