Bug#684134: Package 'locales' resets pre-set debconf variable 'default_environment_locale' on install

[Lee Garrett]

Hi,

having run into this issue, I have figured out why locales behaves unexpectedly. 
Here's a snippet to show the issue:


--->8-->8-->8-->8-->8-->8-->8-->8-->8---
root@sid:/tmp/autopkgtest.3hIrFA/build.AZ6/real-tree# apt install locales
Installing:
  locales

Summary:
  Upgrading: 0, Installing: 1, Removing: 0, Not Upgrading: 1
  Download size: 0 B / 3902 kB
  Space needed: 16.1 MB / 3378 MB available

debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 79, 
 line 1.)

debconf: falling back to frontend: Readline
Preconfiguring packages ...
Selecting previously unselected package locales.
(Reading database ... 27044 files and directories currently installed.)
Preparing to unpack .../locales_2.39-6_all.deb ...
Unpacking locales (2.39-6) ...
Setting up locales (2.39-6) ...
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 79.)

debconf: falling back to frontend: Readline
Generating locales (this might take a while)...
Generation complete.
Processing triggers for man-db (2.12.1-2) ...
root@sid:/tmp/autopkgtest.3hIrFA/build.AZ6/real-tree# cat << EOF | 
debconf-set-selections

locales locales/default_environment_locale  select  en_US.UTF-8
locales locales/locales_to_be_generated multiselect en_US.UTF-8 UTF-8
EOF
root@sid:/tmp/autopkgtest.3hIrFA/build.AZ6/real-tree# debconf-get-selections | 
grep -P ^locales

locales locales/default_environment_locale  select  en_US.UTF-8
locales locales/locales_to_be_generated multiselect en_US.UTF-8 UTF-8
root@sid:/tmp/autopkgtest.3hIrFA/build.AZ6/real-tree# dpkg-reconfigure 
--frontend=noninteractive locales

Generating locales (this might take a while)...
Generation complete.
root@sid:/tmp/autopkgtest.3hIrFA/build.AZ6/real-tree# debconf-get-selections | 
grep -P ^locales

locales locales/default_environment_locale  select  None
locales locales/locales_to_be_generated multiselect 
root@sid:/tmp/autopkgtest.3hIrFA/build.AZ6/real-tree#
--->8-->8-->8-->8-->8-->8-->8-->8-->8---

As you can see above, I'm setting the debconf selections first, verifying that 
they're correctly set, then run dpkg-reconfigure to let the reconfigure 
mechanism run it's course. However, instead of correctly setting the 
/etc/locale.gen and /etc/locale.conf to the debconf selections, those values are 
reverted to the defaults. Interestingly, if the order of the "apt install 
locales" and the debconf-set-selections command are reversed, it correctly sets 
the locale.


The reason is how /var/lib/dpkg/info/locales.config is run. Here's the relevant 
code snippet from this file:


--->8-->8-->8-->8-->8-->8-->8-->8-->8---
# Get the list of selected locales from /etc/locale.gen
if [ -e /etc/locale.gen ]; then
if [ -L $LG ] && [ "$(readlink $LG)" = "/usr/share/i18n/SUPPORTED" ]; then
SELECTED_LOCALES="All locales"
else
SELECTED_LOCALES="$(echo "$GEN_LOCALES" | sort -u | tr '\n' ',' | sed 
-e 's/, */, /g' -e 's/, *$//g')"

fi
db_set locales/locales_to_be_generated "$SELECTED_LOCALES"
fi

DEFAULT_ENVIRONMENT="$(cat $LEGACY_EE $EE 2>/dev/null | awk '/^LANG=/ 
{gsub("\"", ""); sub("LANG=", ""); lang=$0;} END {print lang}')"

DEFAULT_ENVIRONMENT="$(convert_locale "$DEFAULT_ENVIRONMENT")"
if [ -n "$SUPPORTED_LOCALES" ] && [ -n "$DEFAULT_ENVIRONMENT" ]; then
  if echo "$SUPPORTED_LOCALES" | grep -q -e "\b$DEFAULT_ENVIRONMENT\b" ; then
db_set locales/default_environment_locale "$DEFAULT_ENVIRONMENT"
  fi
fi
--->8-->8-->8-->8-->8-->8-->8-->8-->8---

So when /etc/locale.gen exists, this file is read, and then the settings in the 
debconf database overwritten by those value. So once debconf is installed, 
there's no programmatic way via debconf to change the locale. A workaround is 
template the files /etc/locale.gen and /etc/locale.conf and then run 
dpkg-reconfigure locales.


This however seems counterintuitive to me, as practically all other packages 
using debconf have the debconf database as authoritative data from which the 
config is written (e.g. apt-cacher-ng, ca-certificates, console-setup, iproute2, 
grub-efi-amd64, grub-pc, postfix, tzdata, wireshark-common, to name a few).


Neither /etc/locale.gen, nor /etc/locale.conf are marked as conffiles, so they 
shouldn't edited by users, and neither be preserved, nor authoritative on the 
matter. As such, I'm raising the bug severity.


I propose to remove the shown code lines from locales.config. This would make 
any debconf selections authoritative again.


A compromise would be to add another debconf option that decides on which side 
is authoritative (either config file, or 

Bug#1076343: setup-testbed will break networking in certain conditions

[Lee Garrett]

On 14.07.24 20:48, Lee Garrett wrote:
[...]

In a step not completely clear to me network-manager then gets removed in line
620 [1]. I at least can't make out any package there that network-manager
depends on.

I found the reason; it's because xml-core gets removed.

Bug#1076343: setup-testbed will break networking in certain conditions

[Lee Garrett]

Package: autopkgtest
Version: 5.28
Severity: normal
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

issue is that setup-testbed will break networking config of a VM by writing a
broken config file, e.g.
/etc/network/interfaces/enp0s31f6\nenx482ae3598891 with the following contents:
auto enp0s31f6
enx482ae3598891
iface enp0s31f6
enx482ae3598891 iface dhcp

The reason is the following:
I'm calling setup-testbed from within vmdb2, which will chroot into the
filesystem before executing the command. As such, $root=/ and line 429 [0]
will evaluate to true.

In the next step, `cd /sys/class/net; ls -d e* 2>/dev/null` is run, which
returns two network interfaces on my machine: enp0s31f6 and enx482ae3598891. And
a few steps later the above broken ifupdown config file will be written out.

There are several problems with the code: First, it assumes that if being run
with $root=/ that it's already in a VM, whereas it can be running in a chroot.
The second problem is that if `ls -d e*` returns more than one line the config
it creates will be broken.

In a step not completely clear to me network-manager then gets removed in line
620 [1]. I at least can't make out any package there that network-manager
depends on.

I was able to work around this (admittedly hilarious) bug by setting
AUTOPKGTEST_IS_SETUP_COMMAND=1.

Regards,
Lee

[0] 
https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/setup-commands/setup-testbed?ref_type=heads#L429
[1] 
https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/setup-commands/setup-testbed?ref_type=heads#L620

-- System Information:
Debian Release: 12.6
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'proposed-updates'), (990, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-22-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages autopkgtest depends on:
ii  apt-utils   2.6.1
ii  libdpkg-perl1.21.22
ii  procps  2:4.0.2-3
ii  python3 3.11.2-1+b1
ii  python3-debian  0.1.49

Versions of packages autopkgtest recommends:
ii  autodep8  0.28
ii  fakeroot  1.31-1.2

Versions of packages autopkgtest suggests:
pn  docker.io
ii  fakemachine  0.0.4-1+b2
ii  lxc  1:5.0.2-1+deb12u2
pn  lxd  
ii  ovmf 2022.11-6+deb12u1
pn  ovmf-ia32
pn  podman   
ii  python3-distro-info  1.5+deb12u1
ii  qemu-efi-aarch64 2022.11-6+deb12u1
ii  qemu-efi-arm 2022.11-6+deb12u1
ii  qemu-system  1:7.2+dfsg-7+deb12u6
ii  qemu-utils   1:7.2+dfsg-7+deb12u6
ii  schroot  1.6.13-3+b2
ii  util-linux   2.38.1-5+deb12u1
ii  vmdb20.27+really.0.26-1
ii  zerofree 1.1.1-1

-- no debconf information

Bug#1069768: The 'no-agent-forwarding' key restriction disables server alive message support

[Lee Garrett]

On 09.07.24 17:24, Guilhem Moulin wrote:

On Tue, 09 Jul 2024 at 14:20:59 +0200, Guilhem Moulin wrote:

On Sat, 29 Jun 2024 at 15:52:49 +0200, Lee Garrett wrote:

Hi Guilhem, could you give quick feedback on this? I'm also happy to prepare
a NMU for bookworm if you can't find the time for it.


In my view this issue doesn't warrant an (o)s-pu upload on its own, but
the fix is trivial so I can do it anyway.


Filed #1076015 for s-pu and #1076016 for os-pu.



Thanks a bunch!

Bug#1042768: Stop shipping scripts that don't work with irssi >= 1.4

[Lee Garrett]

Hi Daniel,

On 31.10.23 00:37, Daniel Echeverri wrote:

Hello!!

Thanks for the report!. I am working in a new version of irssi-scripts that 
remove all deprecated scripts, and include a replacements scripts. Do you mean 
to create a new file debian/NEWS with [0]?

Regards

[0]: https://irssi.org/posts/#major-news-in-irssi-14-coming-from-irssi-123 



Yes, I'm proposing that. Thanks for fixing it in unstable! I think it's also a 
good idea to get an update in bookworm, too, so other users upgrading don't 
stumble upon the same issue.



Greetings,
Lee

Bug#1069768: The 'no-agent-forwarding' key restriction disables server alive message support

[Lee Garrett]

On Wed, 24 Apr 2024 22:00:48 +0200 Lee Garrett  wrote:


my /etc/dropbear/initramfs/dropbear.conf has:

DROPBEAR_OPTIONS="-s -j -k -I 180 -c /usr/bin/cryptroot-unlock"

-j and -k are "disable local/remote port forwarding".

Seems like we cracked the case. Nice! Is there a chance we can get that into 
bookworm via s-p-u?


Hi Guilhem, could you give quick feedback on this? I'm also happy to prepare a 
NMU for bookworm if you can't find the time for it.


Greets,
Lee

Bug#1054544: community.zabbix plugin misses bookworm support and fails with error dict object' has no attribute 'bookworm'

[Lee Garrett]

On Wed, 25 Oct 2023 20:36:48 +0530 Pirate Praveen  
wrote:

package: anisble
severity: important
version: 7.3.0+dfsg-1

: FAILED! => {"msg": "The task includes an option with an undefined 
variable. The error was: 'dict object' has no attribute 'bookworm'. 
'dict object' has no attribute 'bookworm'\n\nThe error appears to be in 
'/usr/lib/python3/dist-packages/ansible_collections/community/zabbix/roles/zabbix_server/tasks/Debian.yml': 
line 86, column 3, but may\nbe elsewhere in the file depending on the 
exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: 
\"Debian | Install gpg key\"\n  ^ here\n"}


I can see a newer commit adding support

https://github.com/ansible-collections/community.zabbix/commit/9856769381625c7994c33a07b7e27a277f8bea86#diff-c1a1a767b71f8dcff0bb354327aba87b4b1885711f107a2b8ecb58fce7992697

It is kind of a chicken and egg problem to include bookworm support in 
bookworm first release. But I think we can include a patch in a stable 
update.


I managed to fix this by installing with ansible-galaxy (2.1.0) but 
would be nice to fix the packaged version.





I had a look at the patch, and it does not cleanly apply against ansible 7.7.0 
(which should soon be in bookworm-proposed-updates). In fact, it seems as though 
bullseye isn't even supported [0].


Do you believe you could come up with a patch against 
https://salsa.debian.org/python-team/packages/ansible/-/tree/debian/bookworm?ref_type=heads 
that would add support for bullseye and bookworm? I unfortunately don't have a 
zabbix setup I could test against.


Regards,
Lee

[0] 
https://salsa.debian.org/python-team/packages/ansible/-/blob/debian/bookworm/ansible_collections/community/zabbix/docs/ZABBIX_AGENT_ROLE.md?ref_type=heads#zabbix-versions

Bug#1070193: bookworm-pu: package ansible-core/2.14.16-0+deb12u1

[Lee Garrett]

On 16.06.24 00:25, Jonathan Wiltshire wrote:

Control: tag -1 confirmed

On Wed, May 01, 2024 at 05:05:05PM +0200, Lee Garrett wrote:

[ Reason ]
This is a bugfix-only update from ansible-core 2.14.3 to 2.14.16. This fixes
three CVEs:
- Address issue where ANSIBLE_NO_LOG was ignored (CVE-2024-0690)
- Address issues where internal templating can cause unsafe variables to
   lose their unsafe designation (CVE-2023-5764)
- Prevent roles from using symlinks to overwrite files outside of the
   installation directory (CVE-2023-5115)

and various other bugfixes as seen here:
https://salsa.debian.org/python-team/packages/ansible-core/-/blob/debian/bookworm-proposed/changelogs/CHANGELOG-v2.14.rst


  1051 files changed, 8802 insertions(+), 159082 deletions(-)

Normally I'd been looking for targetted fixes for the security issues but
upstream's descriptive changelog does look quite sensible.

You might want to change your version number - if 2.14.16-1 was never in
sid you could use that. A +/~ revision to a version which never existed
feels odd, as do -0 Debian versions (-1 being the first Debian release of
this upstream version, -0 is... the zeroth?).


I double-checked if it was me or the tooling that set the version number to 
2.14.16-0+deb12u1, and it's even part of official policy:


https://www.debian.org/doc/debian-policy/ch-controlfields.html#special-version-conventions 
-> stable-updates -> bullet point 3


So I'll go ahead and upload as is unless you have any reservations.

Greetings,
Lee

Bug#1069891: bookworm-pu: package ansible/7.7.0+dfsg-3+deb12u1

[Lee Garrett]

On 16.06.24 00:06, Jonathan Wiltshire wrote:

Control: tag -1 moreinfo

On Fri, Apr 26, 2024 at 03:05:00PM +0200, Lee Garrett wrote:

I'm requesting to bump the version of the ansible package ("ansible-community
collection") to the last minor semantic version of the v7 series in bookworm.
This version has previously spent ~10 months in testing/unstable, so I'm fairly
confident that any potential regressions would have been caught (so far none).


If upstream uses semver then 7.3 -> 7.7 implies new features. Along with a
10MiB diff this is usually a good indicator that it's inappropriate for
stable.


Ack, fair point. I have reviewed the upstream changelog, and the only added 
collection between 7.3 and 7.7 is microsoft.ad (out of ~100 collections).



The trouble with a package's time spent in sid as an indicator of
reliability isn't so much the package itself, but all the differences
around it like library versions. We've been bitten by that assumption
before now.


Indeed, that has happened e.g. with the python3-jinja2 dependency in the past. 
However, this only happened in major version upgrades of ansible. Newer deps 
would warrant a bump in major version number.


I should also mention that I ran this version on my bookworm machine in that 
timeframe, and I extensively use ansible for $work.



Are there known issues for users which you can target with fixes rather
than a wholesale backport?


Not exactly. While "ansible" (the package) is a curated collection of smaller 
projects, it would theoretically be possible to redo that work by hand with 
stricter selection criteria. In practice however I'd have to review ~100 
individual projects, which is IMHO not feasible. I'm also unsure how I'd convey 
that info to users, as it would neither be ansible 7.3, nor ansible 7.7 in 
practice, but something else entirely.


Since this is a fairly large leaf package (~3.7m LoC), I'd more treat it like 
other large projects (libreoffice, firefox-esr, etc.) with slightly relaxed 
s-p-u criteria.


On a sidenote: While ansible-lint and python-mitogen depend on ansible, this is 
just a leftover from the package split in bookworm. They should depend on 
ansible-core instead.


If there was an easy way to leave out the few new features, I'd be happy to do 
so. I'm mostly worried about the upgrade path from bookworm to trixie. A lot of 
collections have added deprecation warnings that will notify users to migrate 
away from a certain collection, or use different parameters for the module. And 
those are mostly not included in 7.3 yet. One example is the postgresql module: 
https://salsa.debian.org/python-team/packages/ansible/-/blob/debian/bookworm-proposed/CHANGELOG-v7.rst#id765


There are several others in the changelog under the sections "deprecated 
features" in each release.


As I have several large playbooks for different $work projects, upgrading 
ansible and only then noticing things have been removed is a major PITA. I'd 
much rather have the deprecation warnings pop up during a playbook run, allowing 
me to fix the deprecated code over time, before upgrading. We're doing our users 
a much better service this way.


So in overall I think the bugfixes+deprecation warnings outweigh the slightly 
higher probability of regressions from potential new features.



Otherwise maybe bookworm-backports is a better place for this, so users can
choose to take slightly more risk for features, or stick with the released
version and put up with known quantity bugs.


That's an option, I'd see this however complementary to this s-p-u. The package 
soon in testing will be three major releases ahead.




Thanks,

Bug#1070193: bookworm-pu: package ansible-core/2.14.16-0+deb12u1

[Lee Garrett]

On 16.06.24 00:25, Jonathan Wiltshire wrote:

Control: tag -1 confirmed

On Wed, May 01, 2024 at 05:05:05PM +0200, Lee Garrett wrote:

[ Reason ]
This is a bugfix-only update from ansible-core 2.14.3 to 2.14.16. This fixes
three CVEs:
- Address issue where ANSIBLE_NO_LOG was ignored (CVE-2024-0690)
- Address issues where internal templating can cause unsafe variables to
   lose their unsafe designation (CVE-2023-5764)
- Prevent roles from using symlinks to overwrite files outside of the
   installation directory (CVE-2023-5115)

and various other bugfixes as seen here:
https://salsa.debian.org/python-team/packages/ansible-core/-/blob/debian/bookworm-proposed/changelogs/CHANGELOG-v2.14.rst


  1051 files changed, 8802 insertions(+), 159082 deletions(-)

Normally I'd been looking for targetted fixes for the security issues but
upstream's descriptive changelog does look quite sensible.

You might want to change your version number - if 2.14.16-1 was never in
sid you could use that. A +/~ revision to a version which never existed
feels odd, as do -0 Debian versions (-1 being the first Debian release of
this upstream version, -0 is... the zeroth?).

Thanks,



Will do, and thanks for the ack!

Bug#982968: ansible-pull output on terminal is buffered (not live)

[Lee Garrett]

Hi Ludovic,

if this still affects current Debian versions please report it with upstream: 
https://github.com/ansible/ansible/issues


If they consider it a good change I'm happy to backport it to the release 
currently in bookworm.


Greets,
Lee

On Wed, 17 Feb 2021 14:53:40 +0100 Ludovic Pouzenc  wrote:

Source: ansible
Version: 2.9.6+dfsg-1~bpo10+1
Severity: normal

Dear Maintainer,

Using ansible-pull command from a virtual machine console works but
the progression of the work done is not displayed live. It is buffered
(4kio ?) and bunch of text appears at once, "too late".

It shows up also via ssh but with a less big buffer (less annoying, but
happens too).

For me it affects current buster and current buster-backports. I didn't
see any clue upstream about solving this issue. I just report it here
for now.

I expect that the output should be live as when using ansible-playbook.
Code appears to handle that. strace shows up many unbuffered read from
forked ansible commands, but only a few big writes to terminal.

Please find attached a patch that works for me on 2.9 and 2.7. I suspect
that is an upstream that may be distro-agnotic bug but I didn't tried it
elsewhere right now.

diff --git a/ansible/utils/cmd_functions.py b/ansible/utils/cmd_functions.py
index 7a0fb23..ef6cb14 100644
--- a/ansible/utils/cmd_functions.py
+++ b/ansible/utils/cmd_functions.py
@@ -57,6 +57,7 @@ def run_cmd(cmd, live=False, readsize=10):
 sys.stdout.buffer.write(dat)
 else:
 sys.stdout.write(dat)
+sys.stdout.flush()
 stdout += dat
 if dat == b'':
 rpipes.remove(p.stdout)
@@ -69,6 +70,7 @@ def run_cmd(cmd, live=False, readsize=10):
 sys.stdout.buffer.write(dat)
 else:
 sys.stdout.write(dat)
+sys.stdout.flush()
 if dat == b'':
 rpipes.remove(p.stderr)
 # only break out if we've emptied the pipes, or there is nothing to

I may have tested onnly 1 code path of the two that are patched above. I am
unclear about python 2/3 mixing and ansible on Debian 10.

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

Kernel: Linux 5.9.0-0.bpo.5-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1069283: New version of arista.eos collection

[Lee Garrett]

Hi Simon,

I've just uploaded ansible 10.0.0-1 which contains arista.eos 9.0.0. I'm closing 
this bug as such.


Greets,
Lee

On Fri, 19 Apr 2024 11:51:15 +0200 =?UTF-8?Q?Simon_Sp=C3=B6hel?= 
 wrote:

Package: ansible
Version: 9.4.0+dfsg-1

Dear Maintainers

Thank you for updating and maintaining Ansible.

Ansible in Debian contains arista.eos collection version 6.2.2. Current 
upstream version is 9.0.0. An update would be much appreciated.


Regards
Simon

Bug#1061591: rhsrvany: tests can fail on ci.debian.net due to wine32 installation

[Lee Garrett]

On Sat, 27 Jan 2024 00:17:50 + Michael Gilbert  wrote:

package: src:rhsrvany
version: 1.1-2
severity: serious
tag: patch

runsrvany64 and runpnpwait64 autopkgtests can fail on amd64 on
ci.debian.net because of foreign arch wine32 installability issues
[0].  This currently prevents wine from migrating to testing [1].

The attached patch solves the problem by removing wine32 install from
the scripts.  wine32 isn't needed since the tests run correctly on
amd64 when wine and wine64 are installed, which is the case for
ci.debian.net.

Best wishes,
Mike

[0] https://ci.debian.net/packages/r/rhsrvany/testing/amd64/42392786/
[1] https://qa.debian.org/excuses.php?package=wine


Hi,

I've uploaded 1.1-3 which fixes the issue by removing the tests for amd64. 
However, I believe the original purpose was to ensure that pushing the git 
branch would also run the autopkgtests (which only run on amd64 containers).


Unfortunately the logs are not available anymore. Any idea what the original 
problem was?


It would be nice to have autopkgtests run on amd64 when testing things out 
before uploading a package.


Regards,
Lee

Bug#1072013: uscan unconditionally downloads signature file

[Lee Garrett]

Package: devscripts
Version: 2.23.4+deb12u1
Severity: important
File: /usr/bin/uscan
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

when the tarball and signature file already exists, uscan will skip downloading
the tarball, but will unconditionally re-download the signature file. In my
specific case upstream has opted to build a bot detection on their web page,
which then instead serves a HTML file with a captcha. This causes the previous
signature file (that verifies) to be replaced with a HTML file that of course
does not verify anymore.

Together with a related bug (#1072008) in gbp it makes it really hard to
actually import a tarball with signature in such a scenario. As developers might
be tempted to skip signature checks (which would be one workaround), I'm setting
the severity to important.

I believe that the right thing to do is to skip downloading the signature file,
as it's consistent with already skipping downloading the tarball.

Greets,
Lee

Full transcript below:

---8<--8<--8<--8<--8<--8<--8<--8<---

$ cat debian/watch 
version=4
opts="pgpmode=mangle,pgpsigurlmangle=s%$%.sig%,filenamemangle=s%[^?]+\?file=(.+)%$1%"
 \
https://dianne.skoll.ca/projects/rp-pppoe/ \
download.php\?file=rp-pppoe-(4.0).tar.gz \
debian uupdate

$ gpg --verify ../rp-pppoe-4.0.tar.gz.sig ../rp-pppoe-4.0.tar.gz
gpg: Signature made Mi 26 Apr 2023 21:02:53 CEST
gpg:using RSA key 738E4D954052902C147D07B2685A5A5E511D30E2
gpg:issuer "dia...@skoll.ca"
gpg: Good signature from "Dianne Skoll " [unknown]
gpg: aka "Dianne Skoll " [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 738E 4D95 4052 902C 147D  07B2 685A 5A5E 511D 30E2

$ head debian/changelog 
rp-pppoe (3.15-2) unstable; urgency=medium

  * Update upstream contact email address
  * Bump Standards-Version (no changes needed)
  * Update d/copyright
  * Fix lintian override
  * Update hardening flag according to wiki
  * Add hardening build flags to Makefile
  * Remove superfluous lintian override

$ uscan -vvv
uscan info: uscan (version 2.23.4+deb12u1) See uscan(1) for help
uscan info: Scan watch files in .
uscan debug: Found ./debian
uscan info: Check debian/watch and debian/changelog in .
uscan info: package="rp-pppoe" version="3.15-2" (as seen in debian/changelog)
uscan info: package="rp-pppoe" version="3.15" (no epoch/revision)
uscan info: ./debian/changelog sets package="rp-pppoe" version="3.15"
uscan info: Found upstream signing keyring: debian/upstream/signing-key.asc
uscan info: Process watch file at: debian/watch
package = rp-pppoe
version = 3.15
pkg_dir = .
uscan debug: parse line 
opts="pgpmode=mangle,pgpsigurlmangle=s%$%.sig%,filenamemangle=s%[^?]+\?file=(.+)%$1%"
 https://dianne.skoll.ca/projects/rp-pppoe/ 
download.php\?file=rp-pppoe-(4.0).tar.gz debian uupdate
uscan info: opts: 
pgpmode=mangle,pgpsigurlmangle=s%$%.sig%,filenamemangle=s%[^?]+\?file=(.+)%$1%
uscan info: line: https://dianne.skoll.ca/projects/rp-pppoe/ 
download.php\?file=rp-pppoe-(4.0).tar.gz debian uupdate
uscan info: Parsing pgpmode=mangle
uscan info: Parsing pgpsigurlmangle=s%$%.sig%
uscan info: Parsing filenamemangle=s%[^?]+\?file=(.+)%$1%
uscan info: line: https://dianne.skoll.ca/projects/rp-pppoe/ 
download.php\?file=rp-pppoe-(4.0).tar.gz debian uupdate
uscan debug: $self->{'pgpmode'}=mangle, $self->{'pgpsigurlmangle'}=s%$%.sig%
uscan info: Last orig.tar.* tarball version (from debian/changelog): 3.15
uscan info: Last orig.tar.* tarball version (dversionmangled): 3.15
uscan debug: watch file has:
$base= https://dianne.skoll.ca/projects/rp-pppoe/
$filepattern = download.php\?file=rp-pppoe-(4.0).tar.gz
$lastversion = 3.15
$action  = uupdate
mode = http
pgpmode  = mangle
versionmode  = newer
$site= https://dianne.skoll.ca
$basedir = /projects/rp-pppoe/
uscan debug: line: search()
uscan info: Requesting URL:
   https://dianne.skoll.ca/projects/rp-pppoe/
uscan debug: received content:








Dianne Skoll's Web Site - RP-PPPoE - Software Projects


  

  

  
  

  Home
  Contact
  Software
  Comedy
  Writings
  Store


  

  


  
  


  RP-PPPoE

  PPPoE (Point-to-Point Protocol over Ethernet) is a protocol used
  by many DSL Internet Service Providers. RP-PPPoE is a free PPPoE
  client, relay and server for Linux.
  
  Commercial PPPoE Server
  Fine Point Networks sells a commercial PPPoE server based on rp-pppoe; 
their product is called ServPoET BMS.
  
  Download RP-PPPoE
  You can download RP-PPPoE here:
  rp-pppoe-4.0.tar.gz
GPG 
Signature
  


  
  Public Git Repository
  RP-PPPoE has a public Git repo at 

Bug#1072008: gbp import-orig does not document which signature extensions it expects

[Lee Garrett]

Package: git-buildpackage
Version: 0.9.30
Severity: important
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

I was trying to import a newer upstream version of rp-pppoe, here's the shell
session transcript:

---8<--8<--8<--8<--8<--8<--8<--8<--8<---

$ ls -l ../rp-pppoe-4.0.tar.gz*
-rw-r--r-- 1 randall randall 139539 Mai 21 14:58 ../rp-pppoe-4.0.tar.gz
-rw-r--r-- 1 randall randall583 Mai 20 10:32 ../rp-pppoe-4.0.tar.gz.sig

$ gbp import-orig --upstream-signatures=on --upstream-tag=deleteme --verbose 
../rp-pppoe-4.0.tar.gz
gbp:debug: ['git', 'rev-parse', '--show-cdup']
gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
gbp:debug: ['git', 'rev-parse', '--git-dir']
gbp:debug: ['git', 'for-each-ref', '--format=%(refname:short)', 'refs/heads/']
gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream/latest']
gbp:debug: ['git', 'status', '--porcelain']
What is the upstream version? [4.0] 
gbp:debug: ['git', 'tag', '-l', 'deleteme']
gbp:debug: tar ['-C', '../tmpcjic_cw6', '-a', '-xf', '../rp-pppoe-4.0.tar.gz'] 
[]
gbp:debug: Unpacked '../rp-pppoe-4.0.tar.gz' to '../tmpcjic_cw6/rp-pppoe-4.0'
gbp:info: 
gbp:info: Importing '../rp-pppoe-4.0.tar.gz' to branch 'upstream/latest'...
gbp:info: Source package is rp-pppoe
gbp:info: Upstream version is 4.0
gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream/latest']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'upstream/latest']
gbp:debug: ['git', 'add', '-f', '.']
gbp:debug: ['git', 'write-tree']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'upstream/latest']
gbp:debug: ['git', 'commit-tree', '3017f5070cb7a09b0d79d49df8860a42e460f66e', 
'-p', '31d68177a90b0e56367dbd8901711fdc551ec2ad']
gbp:debug: ['git', 'update-ref', '-m', 'gbp: New upstream version 4.0', 
'refs/heads/upstream/latest', 'b7b1dd7a852a6fe0c544d38e2baf8cff7b65cd4f', 
'31d68177a90b0e56367dbd8901711fdc551ec2ad']
gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/pristine-tar']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'pristine-tar']
gbp:error: ../rp-pppoe-4.0.tar.gz does not have a signature file
gbp:error: Error detected, Will roll back changes.
gbp:info: Rolling back branch upstream/latest by resetting it to 
31d68177a90b0e56367dbd8901711fdc551ec2ad
gbp:debug: ['git', 'update-ref', '-m', 'gbp import-orig: failure rollback of 
upstream/latest', 'refs/heads/upstream/latest', 
'31d68177a90b0e56367dbd8901711fdc551ec2ad']
gbp:info: Rolling back branch pristine-tar by resetting it to 
3b63b1f0270f976f8b6f6d5eb27d4d7054bf50e1
gbp:debug: ['git', 'update-ref', '-m', 'gbp import-orig: failure rollback of 
pristine-tar', 'refs/heads/pristine-tar', 
'3b63b1f0270f976f8b6f6d5eb27d4d7054bf50e1']
gbp:error: Rolled back changes after import error.
gbp:debug: rm ['-rf', '../tmpcjic_cw6'] []

$ gpg --verify ../rp-pppoe-4.0.tar.gz.sig ../rp-pppoe-4.0.tar.gz
gpg: Signature made Mi 26 Apr 2023 21:02:53 CEST
gpg:using RSA key 738E4D954052902C147D07B2685A5A5E511D30E2
gpg:issuer "dia...@skoll.ca"
gpg: Good signature from "Dianne Skoll " [unknown]
gpg: aka "Dianne Skoll " [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 738E 4D95 4052 902C 147D  07B2 685A 5A5E 511D 30E2

---8<--8<--8<--8<--8<--8<--8<--8<--8<---

As you can see, the signature is valid. After digging around I found out that
renaming the .sig file to .asc actually makes the above import-orig command run
through. It would be great if `gbp import-orig` would check a set of extensions
similar to uscan (?:asc|pgp|gpg|sig|sign) and also document those in the man
page.

Set to important as I believe importing signed tarballs is a crucial step in
Debian packaging and maintainers should not be tempted to import it unsigned to
work around bugs.

Greets,
Lee

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'proposed-updates'), (990, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-21-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages git-buildpackage depends on:
ii  devscripts 2.23.4+deb12u1
ii  git1:2.39.2-1.1
ii  man-db 2.11.2-2
ii  python33.11.2-1+b1
ii  python3-dateutil   2.8.2-2
ii  python3-pkg-resources  66.1.1-1
ii  python3-yaml   6.0-3+b2
ii  sensible-utils 0.0.17+nmu1

Versions of packages git-buildpackage recommends:
ii  pristine-tar  1.50
ii  python3-requests  2.28.1+dfsg-1
ii  sbuild0.85.0

Versions of packages 

Bug#1072006: reference gbp-import-ref(1) in gbp(1) man page

[Lee Garrett]

Package: git-buildpackage
Version: 0.9.30
Severity: minor
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

looking at the man page of gbp, there is no reference to import-ref, neither in
the "GBP COMMANDS" section, nor in the "SEE ALSO" section. Would be great to add
that there for bookworm and later. The man page for import-ref is actually
shipped in the package, just not referenced anywhere.

Greets,
Lee


-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'proposed-updates'), (990, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-21-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages git-buildpackage depends on:
ii  devscripts 2.23.4+deb12u1
ii  git1:2.39.2-1.1
ii  man-db 2.11.2-2
ii  python33.11.2-1+b1
ii  python3-dateutil   2.8.2-2
ii  python3-pkg-resources  66.1.1-1
ii  python3-yaml   6.0-3+b2
ii  sensible-utils 0.0.17+nmu1

Versions of packages git-buildpackage recommends:
ii  pristine-tar  1.50
ii  python3-requests  2.28.1+dfsg-1
ii  sbuild0.85.0

Versions of packages git-buildpackage suggests:
ii  python3-notify2  0.3-5
ii  sudo 1.9.13p3-1+deb12u1
ii  unzip6.0-28

-- no debconf information

Bug#722344: eog: saving multiple rotations failes, only last is saved

[Lee Garrett]

Package: eog
Version: 43.2-1
Followup-For: Bug #722344
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

this bug is still present in bookworm. The steps to reproduce are trivial:

1) view several (> 2) jpg in a folder
2) rotate the first picture by clicking the rotate right button at the bottom of
the pic
3) repeat the last step for all pictures
4) close eog, and select save images before closing
5) Notice that only the last picture is actually rotated, all the others are
untouched.

It would be nice to get this fixed, as it's easy for people to waste time on
fixing the rotation only to later find out that it doesn't actually persist.

Greets,
Lee

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'proposed-updates'), (990, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-21-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages eog depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-gtk-3.0   3.24.38-2~deb12u1
ii  gir1.2-peas-1.0  1.34.0-1+b1
ii  gsettings-desktop-schemas43.0-1
ii  libc62.36-9+deb12u7
ii  libcairo21.16.0-7
ii  libexempi8   2.6.3-1
ii  libexif120.6.24-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgirepository-1.0-11.74.0-3
ii  libglib2.0-0 2.74.6-2+deb12u2
ii  libgnome-desktop-3-2043.2-2
ii  libgtk-3-0   3.24.38-2~deb12u1
ii  libhandy-1-0 1.8.1-1
ii  libjpeg62-turbo  1:2.1.5-2
ii  liblcms2-2   2.14-2
ii  libpeas-1.0-01.34.0-1+b1
ii  librsvg2-2   2.54.7+dfsg-1~deb12u1
ii  librsvg2-common  2.54.7+dfsg-1~deb12u1
ii  libx11-6 2:1.8.4-2+deb12u2
ii  shared-mime-info 2.2-1
ii  webp-pixbuf-loader   0.2.1-1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages eog recommends:
ii  yelp  42.2-1

Versions of packages eog suggests:
pn  eog-plugins  

-- no debconf information

Bug#1069891: bookworm-pu: package ansible/7.7.0+dfsg-3+deb12u1

[Lee Garrett]

I have just pushed some meta-data updates, and also a change that fixes 
CVE-2023-4237 in this package. See the commit logs here:


https://salsa.debian.org/python-team/packages/ansible/-/commits/debian/bookworm-proposed/

Bug#1069891: bookworm-pu: package ansible/7.7.0+dfsg-3+deb12u1

[Lee Garrett]

On Fri, 26 Apr 2024 15:05:00 +0200 Lee Garrett  wrote:

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ansi...@packages.debian.org, deb...@rocketjump.eu
Control: affects -1 + src:ansible

Hi,

I'm requesting to bump the version of the ansible package ("ansible-community
collection") to the last minor semantic version of the v7 series in bookworm.
This version has previously spent ~10 months in testing/unstable, so I'm fairly
confident that any potential regressions would have been caught (so far none).

[ Reason ]
This incorporates the latest bugfixes from the v7 series, which update all
modules in the collection. These contain updates to handle:
- distro releases that have been released since
- web API changes that ansible can run against
- various bugfixes
- deprecation warnings that will be useful for users before they upgrade to
  bookworm + 1

Most importantly due to semantic versioning, there is no user-visible change.
Any previous playbooks will continue to work without changes.

I intend to use the 7.7.0 release as a basis for security support until bookworm
LTS EOL.

[ Impact ]
(What is the impact for the user if the update isn't approved?)
If the update is not approved, users will likely report errors that have already
been fixed in the latest minor release, and I'd have to cherrypick those
changes, add roundtrip time to the process.

[ Tests ]
autopkgtests have been widely expanded from the previous 7.3.0 release, covering
more unit tests than before.

[ Risks ]
There is a small risk of regressions, but I believe the risk to be minimal as no
such regressions have been reported in the 10 months in testing/unstable.

[ 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 ]
- upstream update to 7.7.0


Forgot to add the link with the high-level upstream changes:
https://salsa.debian.org/debian/ansible/-/blob/debian/bookworm-proposed/CHANGELOG-v7.rst


- fixes to the libvirt connection plugin that bit me
- updates to the package metadata
- widely expanded autopkgtests for more coverage

[ Other info ]
This is my first s-p-u process, let me know what I can do better for any
following s-p-u.

Bug#1069886: piuparts fails when unrelated hardware events happen on the host machine

[Lee Garrett]

Package: piuparts
Version: 1.1.7
Severity: normal
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

I'm running piuparts in a schroot as part of my packaging workflow. However,
when I plug in hardware on my host machine, or enable/disable things like
bluetooth/LTE modem/etc, during a piuparts run it will inadvertently fail:

[...]
2m51.1s ERROR: FAIL: After purging files have disappeared:
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/
   not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/bEndpointAddress
   not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/bInterval
  not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/bLength
not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/bmAttributes
   not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/direction
  not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/interval
   not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/
 not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/async
not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/autosuspend_delay_ms
 not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/control
  not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/runtime_active_kids
  not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/runtime_active_time
  not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/runtime_enabled
  not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/runtime_status
   not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/runtime_suspended_time
   not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/runtime_usage
not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/type
   not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/uevent
 not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/wMaxPacketSize
 not owned

2m51.1s ERROR: FAIL: Installation, upgrade and purging tests.
2m51.5s DEBUG: Terminate schroot session 
'/var/run/schroot/mount/bookworm-amd64-sbuild-2ab9e614-03c3-11ef-9ce1-52540055ba9d-piuparts'
2m51.5s DEBUG: Starting command: ['schroot', '--end-session', '--chroot', 
'session:bookworm-amd64-sbuild-2ab9e614-03c3-11ef-9ce1-52540055ba9d-piuparts']
2m51.6s DEBUG: Command ok: ['schroot', '--end-session', '--chroot', 
'session:bookworm-amd64-sbuild-2ab9e614-03c3-11ef-9ce1-52540055ba9d-piuparts']
2m51.6s ERROR: piuparts run ends.

E: Piuparts run failed.

Since it's not immediately clear if it failed for those reasons alone, it makes
piuparts less useful. It would be nice if piuparts could ignore /sys, /dev,
/proc as they're not on-disk file systems anyway.

Greets,
Lee


-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'proposed-updates'), (990, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-20-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages piuparts depends on:
ii  debootstrap  1.0.128+nmu2+deb12u1
ii  debsums  3.0.2.1
ii  libjs-sphinxdoc  5.3.0-4
ii  lsb-release  12.0-1
ii  lsof 4.95.0-1
ii  mount2.38.1-5+deb12u1
ii  

Bug#1069884: Document acronym "ITA" on https://www.debian.org/devel/wnpp/

[Lee Garrett]

Package: www.debian.org
Severity: normal
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

it would be nice to document "ITA" on https://www.debian.org/devel/wnpp/ along
with the other acronyms like O/RFA/RFH/ITP/RFP. I'm guessing it means "intent to
adopt"? It's mentioned in the removing tables entries, but that's not helpful to
see which tags are available.

Greets,
Lee

Bug#1051140: lintian in bookworm does not know about bookworm-backports

[Lee Garrett]

Friendly ping. It's been half a year now without response from the maintainers. 
Can we get an update please?


On Sun, 03 Sep 2023 14:01:47 +0200 Lee Garrett  wrote:

Package: lintian
Version: 2.116.3
Severity: important
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

when preparing an upload for bookworm-backports, lintian in bookworm will
falsely error out, diminishing it's usefulness:

E: rhsrvany changes: bad-distribution-in-changes-file bookworm-backports

It would be great if lintian in stable would know about bookworm-backports.

Greetings,
Lee

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

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

Versions of packages lintian depends on:
ii  binutils2.40-2
ii  bzip2   1.0.8-5+b1
ii  diffstat1.65-1
ii  dpkg1.21.22
ii  dpkg-dev1.21.22
ii  file1:5.44-3
ii  gettext 0.21-12
ii  gpg 2.2.40-1.1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.15.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.28-2
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.35-1
ii  libdata-dpath-perl  0.58-2
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b1
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.22
ii  libemail-address-xs-perl1.05-1+b1
ii  libencode-perl  3.19-1+b1
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3

Bug#1069768: The 'no-agent-forwarding' key restriction disables server alive message support

[Lee Garrett]

On 24.04.24 19:59, Guilhem Moulin wrote:

Control: reassign -1 dropbear-bin 2022.83-1+deb12u1
Control: retitle -1: The 'no-agent-forwarding' key restriction disables server 
alive message support
Control: tag -1 upstream

On Wed, 24 Apr 2024 at 18:38:26 +0200, Guilhem Moulin wrote:

On Wed, 24 Apr 2024 at 17:10:57 +0200, Guilhem Moulin wrote:

It should be trivially reproducible by running `ssh -o ServerAliveCountMax=3
-o ServerAliveInterval=1 root@yourdropbearserver`. The client should then
disconnect after 3 seconds.


Seems to work as expected for me:

$ ssh -oLogLevel=DEBUG3 \
 -oServerAliveCountMax=3 -oServerAliveInterval=1 \
 -oUserKnownHostsFile=/tmp/known_hosts \
 -i /tmp/test.key \
 -l user -p 10022 127.0.0.1 sleep 300
[…]


No wait, this works in the main system but indeed at initramfs stage the
client doesn't get responses to its alive probes.


The above was misleading, turns out this was not due to the initramfs
per se, but because its authorized_keys file had the following
restrictions (which were set in my test environment per cryptsetup-initramfs'
recommendations):

 
no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="/bin/cryptroot-unlock"

Lee, I assume you have the ‘no-port-forwarding’ restriction too?  It
appears to disable server alive message support for some reason.  This
is reproducible at initramfs stage as well as in the main system.



my /etc/dropbear/initramfs/dropbear.conf has:

DROPBEAR_OPTIONS="-s -j -k -I 180 -c /usr/bin/cryptroot-unlock"

-j and -k are "disable local/remote port forwarding".

Seems like we cracked the case. Nice! Is there a chance we can get that into 
bookworm via s-p-u?

Bug#1069768: dropbear-initramfs becomes unresponsive after several connection attempts

[Lee Garrett]

On 24.04.24 17:10, Guilhem Moulin wrote:

On Wed, 24 Apr 2024 at 16:32:09 +0200, Lee Garrett wrote:

Although the dropbear man page is not explicit, I'm assuming it refers to
TCP keepalive.


I think this assumption is incorrect:
https://sources.debian.org/src/dropbear/2024.84-1/src/common-session.c/#L497


It should be trivially reproducible by running `ssh -o ServerAliveCountMax=3
-o ServerAliveInterval=1 root@yourdropbearserver`. The client should then
disconnect after 3 seconds.


Seems to work as expected for me:

$ ssh -oLogLevel=DEBUG3 \
 -oServerAliveCountMax=3 -oServerAliveInterval=1 \
 -oUserKnownHostsFile=/tmp/known_hosts \
 -i /tmp/test.key \
 -l user -p 10022 127.0.0.1 sleep 300
[…]
debug1: Sending command: sleep 300
debug2: channel 0: request exec confirm 1
debug3: send packet: type 98
debug3: client_repledge: enter
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 65536 rmax 32759
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug3: send packet: type 80
debug3: receive packet: type 82
debug3: send packet: type 80
debug3: receive packet: type 82
debug3: send packet: type 80
debug3: receive packet: type 82
debug3: send packet: type 80
debug3: receive packet: type 82
[…]
debug3: send packet: type 80
debug3: receive packet: type 82
debug3: receive packet: type 96
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: chan_shutdown_write: channel 0: (i0 o1 sock -1 wfd 5 efd 6 
[write])
debug2: channel 0: output drain -> closed
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug3: receive packet: type 97
debug2: channel 0: rcvd close
debug2: chan_shutdown_read: channel 0: (i0 o3 sock -1 wfd 4 efd 6 
[write])
debug2: channel 0: input open -> closed
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug3: send packet: type 97
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 [session] r0 i3/0 o3/0 e[write]/0 fd -1/-1/6 
sock -1 cc -1 io 0x00/0x00)

debug3: send packet: type 1
Transferred: sent 15360, received 7448 bytes, in 300.0 seconds
Bytes per second: sent 51.2, received 24.8
debug1: Exit status 0

There is one packet 80/82 exchange per second until the `sleep 300`
terminates.  The output is similar with OpenSSH's sshd.



Thanks for debugging this. Then I'll have to try and reproduce this on my remote 
server when I find time. Unfortuntely it might take a few days as I need the 
services on it for now. Thanks again for the swift response!

Bug#1069768: dropbear-initramfs becomes unresponsive after several connection attempts

[Lee Garrett]

On 24.04.24 16:15, Guilhem Moulin wrote:

Control: tag -1 unreproducible moreinfo

Hi,

On Wed, 24 Apr 2024 at 14:42:43 +0200, Lee Garrett wrote:

After some debugging, it turns out that ServerAliveInterval != 0 will cause the
ssh client to reset the connection, which dropbear will count as unlock attempt,
and after three tries it will fail and drop to initramfs shell, after which it's
not reachable anymore.


AFAICT dropbear does support timeout messages (see -K in the manual).
I'm unable to reproduce the issue anyway, do you start dropbear with -I?

Can you try to start your client with -oLogLevel=DEBUG3 to see why the
connection is terminated (from the client's perspective)?  Also to take
cryptroot out of the picture you could try using `cat -A` as the remote
command.



Although the dropbear man page is not explicit, I'm assuming it refers to TCP 
keepalive.


The settings ServerAliveCountMax and ServerAliveInterval on the ssh client 
however explicitely refer to SSH keepalive. To quote the man page:


"Sets the number of server alive messages (see below) which may be sent without 
ssh(1) receiving any messages back from the server.  If this threshold is 
reached while server alive messages are being sent, ssh will disconnect from the 
server, terminating the session.  It is important to note that the use of server 
alive messages is very different from TCPKeepAlive (below)."


It should be trivially reproducible by running `ssh -o ServerAliveCountMax=3 -o 
ServerAliveInterval=1 root@yourdropbearserver`. The client should then 
disconnect after 3 seconds.

Bug#1069768: dropbear-initramfs becomes unresponsive after several connection attempts

[Lee Garrett]

Package: dropbear-initramfs
Version: 2022.83-1+deb12u1
Severity: normal
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

I have a remote server running bookworm that is configured to use
dropbear-initramfs and cryptsetup-initramfs to unlock the LUKS container. The
way I unlock it is shown below:

$ until ssh r...@hopper-boot.rocketjump.eu cryptroot-unlock; do sleep 3; done
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection refused
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection refused
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection refused
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection refused
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection refused
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out
Please unlock disk md2_crypt
Timeout, server hopper-boot.rocketjump.eu not responding.
Please unlock disk md2_crypt
Timeout, server hopper-boot.rocketjump.eu not responding.
Please unlock disk md2_crypt
Timeout, server hopper-boot.rocketjump.eu not responding.
Timeout, server hopper-boot.rocketjump.eu not responding.
Timeout, server hopper-boot.rocketjump.eu not responding.
Timeout, server hopper-boot.rocketjump.eu not responding.

^C^C

As you can see, while rebooting the connection is refused, as sshd is already
shutdown, but the server is reachable. Then the connection times out while it's
still doing a POST. At some point dropbear becomes reachable, as shown by the
output of "Please unlock disk md2_crypt", however the connection seems to error
out after a while, and after three attempts, dropbear becomes unresponsive. This
forces me to hard reset the server and try again until I catch it in the right
moment.

After some debugging, it turns out that ServerAliveInterval != 0 will cause the
ssh client to reset the connection, which dropbear will count as unlock attempt,
and after three tries it will fail and drop to initramfs shell, after which it's
not reachable anymore.

It would be great to prominently document that dropbear(-initramfs) does not
handle the ServerAliveInterval ssh client setting.

Greets,
Lee


-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'proposed-updates'), (990, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-20-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dropbear-initramfs depends on:
ii  busybox  1:1.35.0-4+b3
pn  dropbear-bin 
ii  initramfs-tools  0.142
ii  udev 252.23-1~deb12u1

Versions of packages dropbear-initramfs recommends:
ii  cryptsetup-initramfs  2:2.6.1-4~deb12u2

dropbear-initramfs suggests no packages.

Bug#1005910: apt provider does not grok Deb822 sources files

[Lee Garrett]

Hi Marc,


On Thu, 17 Feb 2022 09:30:06 +0100 Marc Haber  
wrote:

Package: ansible
Version: 2.10.7+merged+base+2.10.8+dfsg-1
Severity: normal

Hi,

when using a Deb822 style sources file in apt, such as:

$ cat /etc/apt/sources.list.d/docker-stable.sources
Types: deb
URIs: https://download.docker.com/linux/debian
Suites: bullseye
Components: stable
Signed-By: /etc/apt/docker.gpg
$

ansible code like:

- name: configure apt - remove transitional packages
  apt:
name: "{{ packages }}"
state: "absent"
  vars:
packages:
  - iproute

fails with:

fatal: [corte]: FAILED! => {"changed": false, "msg": "E:Malformed stanza 1 in source 
list /etc/apt/sources.list.d/docker-stable.sources (type), E:The list of sources could not be read."}


Can you still reproduce this issue on bookworm? I tried with
$ ansible -m apt -a 'update_cache=yes' localhost -K --become
$ ansible -m apt -a 'name=0ad state=absent' localhost -K --become

and both command ran through without issue, despite having several deb822-style 
files in /etc/apt/sources.list.d/*.sources


It seems as though the ansible apt module uses python3-apt, and there the 
feature was enabled in:


python-apt (2.5.3) unstable; urgency=medium

  [ Nick Rosbrook ]
  * deb822: allow initializing a Deb822SourceEntry from string
  * all: fix PEP8 formatting
  * .gitlab-ci.yml: update typing stage to use venv

 -- Julian Andres Klode   Thu, 23 Feb 2023 21:38:02 +0100





Expected behavior would be the ansible run to succeed.

Greetings
Marc


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

Kernel: Linux 5.16.9-zgws1 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ansible depends on:
ii  openssh-client1:8.7p1-4
ii  python3   3.9.8-1
ii  python3-cryptography  3.4.8-1
ii  python3-distutils 3.9.10-1
ii  python3-dnspython 2.2.0-2
ii  python3-httplib2  0.20.2-2
ii  python3-jinja23.0.3-1
ii  python3-netaddr   0.8.0-2
ii  python3-packaging 21.3-1
ii  python3-paramiko  2.8.1-1
ii  python3-pycryptodome  3.11.0+dfsg1-3
ii  python3-yaml  5.4.1-1+b1


Greets,
Lee

Bug#1042906: ansible: please package new upstream version 8.x

[Lee Garrett]

Hi, I'll try to upload a new version of ansible and ansible-core within the next 
week.


On 14.04.24 10:00, Daniel Baumann wrote:

retitle 1042906 please package new upstream version 9.x
thanks

Hi Lee,

any updates since last year? Ansible is currently at 9.x and I'd really
like to be able to use a recent enough version of ansible via debian
packages. Is there anything I could help you with?

Regards,
Daniel

Bug#1061683: qemu-guest-agent.service does not restart on upgrade, loosing connectivity

[Lee Garrett]

Package: qemu-guest-agent
Version: 1:7.2+dfsg-7+deb12u3
Severity: normal
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

today I noticed one of my VMs was not accessible via the guest agent. Turns out
that during upgrade it was stopped, but not restarted again. Since it can be
used for automation, I believe it's crucial that qemu-ga service tries harder to
stay alive.

Terminal logs below.

--->8->8->8->8->8->8->8->8->8->8--

root@comms:~# systemctl status qemu-guest-agent.service
○ qemu-guest-agent.service - QEMU Guest Agent
 Loaded: loaded (/lib/systemd/system/qemu-guest-agent.service; static)
 Active: inactive (dead) since Sun 2023-12-10 06:36:40 CET; 1 month 18 days 
ago
   Duration: 1month 3w 16h 24min 38.992s
   Main PID: 205124 (code=exited, status=0/SUCCESS)
CPU: 1min 46.804s

Nov 30 17:42:36 comms qemu-ga[205124]: info: guest-exec-status called, pid: 
619187
Nov 30 17:42:36 comms qemu-ga[205124]: info: guest-exec-status called, pid: 
619187
Nov 30 17:42:37 comms qemu-ga[205124]: info: guest-exec-status called, pid: 
619187
Nov 30 17:42:38 comms qemu-ga[205124]: info: guest-exec-status called, pid: 
619187
Nov 30 17:42:38 comms qemu-ga[205124]: info: guest-exec called: "/bin/sh -c rm 
-f -r /root/.ansible/tmp/ansible-tmp-1701362549.8043833-135706-120368687298004/ 
> /dev/null 2>
Nov 30 17:42:38 comms qemu-ga[205124]: info: guest-exec-status called, pid: 
619913
Dez 10 06:36:40 comms systemd[1]: Stopping qemu-guest-agent.service - QEMU 
Guest Agent...
Dez 10 06:36:40 comms systemd[1]: qemu-guest-agent.service: Deactivated 
successfully.
Dez 10 06:36:40 comms systemd[1]: Stopped qemu-guest-agent.service - QEMU Guest 
Agent.
Dez 10 06:36:40 comms systemd[1]: qemu-guest-agent.service: Consumed 1min 
46.804s CPU time.
root@comms:~# systemctl start qemu-guest-agent.service
root@comms:~# systemctl status qemu-guest-agent.service
● qemu-guest-agent.service - QEMU Guest Agent
 Loaded: loaded (/lib/systemd/system/qemu-guest-agent.service; static)
 Active: active (running) since Sat 2024-01-27 22:32:06 CET; 2s ago
   Main PID: 1263386 (qemu-ga)
  Tasks: 2 (limit: 9475)
 Memory: 1.8M
CPU: 28ms
 CGroup: /system.slice/qemu-guest-agent.service
 └─1263386 /usr/sbin/qemu-ga

Jan 27 22:32:06 comms systemd[1]: Started qemu-guest-agent.service - QEMU Guest 
Agent.
root@comms:~# cat /lib/systemd/system/qemu-guest-agent.service
[Unit]
Description=QEMU Guest Agent
BindsTo=dev-virtio\x2dports-org.qemu.guest_agent.0.device
After=dev-virtio\x2dports-org.qemu.guest_agent.0.device

[Service]
ExecStart=-/usr/sbin/qemu-ga
Restart=always
RestartSec=0

[Install]

root@comms:~# zless /var/log/apt/history.log.1.gz
Start-Date: 2023-12-10  06:36:40
Commandline: /usr/bin/unattended-upgrade
Upgrade: qemu-guest-agent:amd64 (1:7.2+dfsg-7+deb12u2, 1:7.2+dfsg-7+deb12u3), 
qemu-utils:amd64 (1:7.2+dfsg-7+deb12u2, 1:7.2+dfsg-7+deb12u3)
End-Date: 2023-12-10  06:36:42

--->8->8->8->8->8->8->8->8->8->8--


Looking at the maintainer scripts, it looks like it gets stopped by this
section in the .preinst:

# End automatically added section
# Automatically added by dh_installsystemd/13.11.4
if [ -z "${DPKG_ROOT:-}" ] && [ "$1" = upgrade ] && [ -d /run/systemd/system ] 
; then
deb-systemd-invoke stop 'qemu-guest-agent.service' >/dev/null || true
fi
# End automatically added section

And nothing ever starts it again. My next guess was that the systemd unit might
not have been enabled, so I tried that:

root@comms:~# systemctl enable qemu-guest-agent.service 
Synchronizing state of qemu-guest-agent.service with SysV service script with 
/lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable qemu-guest-agent
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.
 
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
  .wants/, .requires/, or .upholds/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.

It seems like it's only enabled by the udev device trigger, which is never
triggered on upgrade.

I think it's missing a `systemctl start qemu-guest-agent` in .postinstall, do
you agree?

Greets,
Lee

-- System Information:
Debian Release: 12.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'proposed-updates'), (990, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-17-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint 

Bug#1056601: No module named

[Lee Garrett]

Hi Daniel!

On 23.11.23 20:08, Daniel Leidert wrote:

Package: ansible
Version: 7.7.0+dfsg-3
Severity: normal

When trying to use the community.general.ssh_config module, I receive:

An exception occurred during task execution. To see the full traceback, use
-vvv. The error was: ModuleNotFoundError: No module named 'paramiko' fatal:
[localhost]: FAILED! => {"changed": false, "msg": "Failed to import the
required Python library (PARAMIKO) on [hostname]'s Python /usr/bin/python3.
Please read the module documentation and install it in the appropriate
location. If the required library is installed, but Ansible is using the wrong
Python interpreter, please consult the documentation on
ansible_python_interpreter"}


Indeed. Did you try installing paramiko on the host you're executing it? This is 
documented in the upstream docs: 
https://docs.ansible.com/ansible/latest/collections/community/general/ssh_config_module.html


Since this is most of the time not the host that has ansible installed, changing 
any dependencies on the package won't make any sense.


The name in Debian for this module is python3-paramiko.

By the way:

   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable'), (500, 
'testing'), (500, 'stable'), (500, 'oldstable')


We generally recommend against mixing releases, this is not supported and will 
bite you sooner or later. It's better to just run unstable and removing any 
residue package from older releases.


Regards,
Lee

Bug#1055616: ansible-core: ansible.builtin.setup does not include facts from facter.

[Lee Garrett]

Hi Andy,

On 10.11.23 20:31, andrew bezella wrote:

On Fri, 2023-11-10 at 12:39 +0100, Lee Garrett wrote:

Hi Andrew,


hello -


On 08.11.23 22:40, andrew bezella wrote:


[...]
i was eventually able to build an updated version of bookworm's
ansible-core .deb including commit id 4b0d014.  this task was made
more difficult by the current FTBFS status of ansible-core but the
patch allowed ansible.builtin.setup to include facts from facter:


Can you elaborate please? AFAICS ansible-core builds fine in stable
and sid.


it wouldn't build in pbuilder and it shows up on the "Packages in
bookworm/amd64 which failed to build from source" page[1].  but from
the changelog it looks like you found and fixed the locale issue that i
was running up against:
ERROR: Ansible requires the locale encoding to be UTF-8; Detected None.


Indeed! I didn't notice it before because the reproducible build daemons 
apparently set a different locale than the regular build daemons. But it should 
be fixed now.




i spent a bunch of time fiddling w/pbuilder to find the "right" answer
but eventually just brute-forced it[2].  your solution is much better!

thank you for the prompt turnaround.  i would suggest/ask that the
facter fix be included in bookworm, too; the lack of expected facts can
have unexpected and significant impact on a playbook's run.


I'm working on the upload right now. It should hopefully be available in 
bookworm-proposed-updates in the next few days.




thanks again!

andy

1. https://tests.reproducible-builds.org/debian/bookworm/amd64/index_FTBFS.html
2. https://bugs.launchpad.net/ubuntu/+source/pbuilder/+bug/1947424/comments/10



Greetings,
Lee

Bug#1055616: ansible-core: ansible.builtin.setup does not include facts from facter.

[Lee Garrett]

Hi Andrew,

On 08.11.23 22:40, andrew bezella wrote:

Package: ansible-core
Version: 2.14.3-1
Severity: normal

Dear Maintainer,

i installed ansible-core and facter 4.3.0-2 in bookworm.  when testing
i found that the facts from facter were not being included by the
setup module:

% ansible -b localhost -m ansible.builtin.setup -a 'filter=facter_*'
[WARNING]: No inventory was parsed, only implicit localhost is available
localhost | SUCCESS => {
 "ansible_facts": {},
 "changed": false
}

this issue has appeared upstream and was resolved by:
setup module, retry facter to handle --puppet errors by bcoca · Pull Request 
#80645 · ansible/ansible · GitHub
https://github.com/ansible/ansible/pull/80645


Thank you for the bug report! I've been able to reproduce the bug and will 
prepare an upload for sid and bookworm shortly.




i was eventually able to build an updated version of bookworm's
ansible-core .deb including commit id 4b0d014.  this task was made
more difficult by the current FTBFS status of ansible-core but the
patch allowed ansible.builtin.setup to include facts from facter:


Can you elaborate please? AFAICS ansible-core builds fine in stable and sid.



% ansible -b localhost -m ansible.builtin.setup -a 'filter=facter_*'
[WARNING]: No inventory was parsed, only implicit localhost is available
localhost | SUCCESS => {
 "ansible_facts": {
 "facter_disks": {
 "sda": {
[...]
 "facter_timezone": "UTC",
 "facter_virtual": "physical"
 },
 "changed": false
}

thanks in advance for addressing this.

andy



Greetings,
Lee

Bug#1054230: Please change permissions on /var/lib/libvirt/images/

[Lee Garrett]

Package: libvirt-daemon-system
Version: 9.0.0-4
Severity: wishlist
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

Currently, the permissions for /var/lib/libvirt/images are root:root u=rwx,go=x.
It would be nice to change those to root:libvirt ug=rwx,o=x. This should not
change anything from the security standpoint, as users of the libvirt group can
already interact with libvirtd and add/remove/modify VMs.

The upside would be that virt-v2v can run without root permissions, as it
directly writes to that dir. I have verified that changing the permissions
allows virt-v2v to run rootless.

For completeness, this is the command line I've tested it with:
virt-v2v -i ova -o libvirt -of qcow2 -oo compressed -oc 'qemu:///system' 
win11.zip -on win11trial

Regards,
Lee


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

Kernel: Linux 6.1.0-13-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libvirt-daemon-system depends on:
ii  adduser 3.134
ii  debconf [debconf-2.0]   1.5.82
ii  gettext-base0.21-12
ii  iptables1.8.9-2
ii  libvirt-clients 9.0.0-4
ii  libvirt-daemon  9.0.0-4
ii  libvirt-daemon-config-network   9.0.0-4
ii  libvirt-daemon-config-nwfilter  9.0.0-4
ii  libvirt-daemon-system-systemd   9.0.0-4
ii  logrotate   3.21.0-1
ii  polkitd 122-3

Versions of packages libvirt-daemon-system recommends:
ii  dmidecode3.4-1
ii  dnsmasq-base [dnsmasq-base]  2.89-1
ii  iproute2 6.1.0-3
ii  mdevctl  1.2.0-3+b1
ii  parted   3.5-3

Versions of packages libvirt-daemon-system suggests:
ii  apparmor3.0.8-3
pn  auditd  
pn  nfs-common  
pn  open-iscsi  
pn  pm-utils
ii  systemd 252.17-1~deb12u1
pn  systemtap   
pn  zfsutils

-- Configuration Files:
/etc/default/libvirt-guests changed [not included]
/etc/libvirt/qemu.conf [Errno 13] Permission denied: '/etc/libvirt/qemu.conf'

-- debconf information excluded

Bug#1054220: Off-by-one when selecting days in activity window

[Lee Garrett]

Package: hamster-time-tracker
Version: 3.0.2-4
Severity: important
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

steps to reproduce:

- click on the + icon ("add activity") in the main window
- on the start time, clik on the arrow next to the date
- (a calendar pops up)
- click on e.g. Wednesday, October 18
- notice that the cmdline sets it to 2023-10-17, a whole day wrong

This also happens when editing previous activities to update them. Clicking back
and forth on the calendar will make the offset increase, being ±2 days, then ±3
days, etc.

I suspected it might be related to locale, but running `LC_ALL=C hamster` did
not change the outcome of the bug.

severity "important" as this tool is probably used by many freelancers to track
time, and wrong timetracking results in loss of income or overbilling.

Regards,
Lee


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

Kernel: Linux 6.1.0-13-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages hamster-time-tracker depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-gtk-3.0   3.24.38-2~deb12u1
ii  libjs-jquery 3.6.1+dfsg+~3.5.14-1
ii  libjs-jquery-ui  1.13.2+dfsg-1
ii  python3  3.11.2-1+b1
ii  python3-cairo1.20.1-5+b1
ii  python3-dbus 1.3.2-4+b1
ii  python3-distutils3.11.2-3
ii  python3-gi   3.42.2-3+b1
ii  python3-xdg  0.28-2

Versions of packages hamster-time-tracker recommends:
ii  gnome-shell-extension-hamster  0.10.0+git20210628-4
ii  yelp   42.2-1

hamster-time-tracker suggests no packages.

-- no debconf information

Bug#1052405: libvirtd floods journal with unhelpful message

[Lee Garrett]

Package: libvirt-daemon
Version: 9.0.0-4
Severity: normal
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

when running a Windows 11 VM, and provisioning it via ansible, the journal is
getting flooded with > 50 messages per second:

Sep 21 15:31:29 batou libvirtd[402313]: Domain id=1 name='win11trial' 
uuid=4d871bc4-364f-47d7-a498-005bf10ee6d6 is tainted: custom-ga-command
Sep 21 15:31:29 batou libvirtd[402313]: Domain id=1 name='win11trial' 
uuid=4d871bc4-364f-47d7-a498-005bf10ee6d6 is tainted: custom-ga-command
Sep 21 15:31:29 batou libvirtd[402313]: Domain id=1 name='win11trial' 
uuid=4d871bc4-364f-47d7-a498-005bf10ee6d6 is tainted: custom-ga-command
Sep 21 15:31:29 batou libvirtd[402313]: Domain id=1 name='win11trial' 
uuid=4d871bc4-364f-47d7-a498-005bf10ee6d6 is tainted: custom-ga-command

A search on the upstream documentation does not explain what this means, and it
seems it was reported on various other sites (reddit, stackoverflow, etc.)
without an answer to it.

Would be nice to have documented what this means, if I need to take action, and
how to disable the warning if it turns out to not be harmful.


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

Kernel: Linux 6.1.0-12-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libvirt-daemon depends on:
ii  libacl1 2.3.1-3
ii  libblkid1   2.38.1-5+b1
ii  libc6   2.36-9+deb12u1
ii  libdevmapper1.02.1  2:1.02.185-2
ii  libgcc-s1   12.2.0-14
ii  libglib2.0-02.74.6-2
ii  libparted2  3.5-3
ii  libpcap0.8  1.10.3-1
ii  libpciaccess0   0.17-2
ii  libselinux1 3.4-1+b6
ii  libtirpc3   1.3.3+ds-1
ii  libudev1252.12-1~deb12u1
ii  libvirt-daemon-driver-qemu  9.0.0-4
ii  libvirt09.0.0-4
ii  libxml2 2.9.14+dfsg-1.3~deb12u1

Versions of packages libvirt-daemon recommends:
ii  libvirt-daemon-driver-lxc   9.0.0-4
pn  libvirt-daemon-driver-vbox  
pn  libvirt-daemon-driver-xen   
ii  libxml2-utils   2.9.14+dfsg-1.3~deb12u1
ii  lvm22.03.16-2
ii  mount   2.38.1-5+b1
ii  netcat-openbsd  1.219-1
ii  qemu-system-x86 [qemu-kvm]  1:7.2+dfsg-7+deb12u1

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster   
pn  libvirt-daemon-driver-storage-iscsi-direct  
pn  libvirt-daemon-driver-storage-rbd   
pn  libvirt-daemon-driver-storage-zfs   
ii  libvirt-daemon-system   9.0.0-4
pn  numad   

-- no debconf information

Bug#1050906: reject non-conforming mail with helpful message when sending to d-d-a

[Lee Garrett]

Hello Cord,

On 17.09.23 12:02, Cord Beermann wrote:

tags 1050906 wontfix
severity 1050906 wishlist
thanks

Hallo! Du (Lee Garrett) hast geschrieben:


>From a user experience it's currently a bit cumbersome, as I'll send a mail,
wait 15 minutes to notice that it hasn't arrived, change a few things and
resend, wait another 15 minutes, etc. Which is quite an ineffective workflow.


Rejecting based on Mail content is discouraged by a RfC.


I was curious about that and re-read the current RFC related to SMTP. It clearly 
states that the preference is ACCEPT > REJECT > BOUNCE > DISCARD. [0]


To quote:
"If they cannot be delivered, and cannot be rejected by the SMTP server
during the SMTP transaction, they should be "bounced" (returned with
non-delivery notification messages) as described above."

This also aligns with the best current practice as propagated from IRC #postfix 
admins:

mantras:
1. do not accept mail that you do not intend to deliver.
2. do not drop mail.
3. do not use wildcards or catchalls.
4. do not forward mail to outside/third party systems

Accepting then discarding the mail would violate #1 and #2 of those mantras.

Discarding is only preferred over bouncing when the mail clearly contains 
"hostile content" (spam, malware, etc.). I would not count a malformed signature 
as such. In fact, discarding is strongly discouraged in RFC 5321:


"As discussed in Section 7.8 and Section 7.9 below, dropping mail
without notification of the sender is permitted in practice. However,
it is extremely dangerous and violates a long tradition and community
expectations that mail is either delivered or returned. If silent
message-dropping is misused, it could easily undermine confidence in
the reliability of the Internet's mail systems. So silent dropping of
messages should be considered only in those cases where there is very
high confidence that the messages are seriously fraudulent or otherwise
inappropriate."

I have also not found anything that could be read as rejecting mail based on 
content is discouraged. That would also be very surprising as spam filtering and 
rejection of such mail is widespread practice.




If we would reject misdirected mails to our lists we would produce

2 backscatter mails daily to mostly innocent netizens.


As mentioned in the previous mail, rejecting during SMTP dialog will not result 
in backscatter originating from Debian's MX. In contemporary setups, the MUA 
will open a SMTP submission connection, the submission MX will keep the SMTP 
dialog open and connect to the Debian MX, receive a reject, and backpropagate it 
to the MUA. In practice the actual rejection message will be displayed in the 
MUA, and the submission will fail.


If there is a temporary error (4xx), the submission MX might still queue the 
mail, but in that case any DSN will originate from the submission MX, outside of 
Debian's MX. And DSNs generated by other people's MX are IMHO not Debian's 
problem domain.



So in the current state of Mail-Federation which is mostly driven by
spamming monopolists I don't see a working solution.

Yours,
 Cord, Debian Listmaster of the day


[0] https://datatracker.ietf.org/doc/html/rfc5321#section-6.2

Best regards,
Lee

Bug#1050906: reject non-conforming mail with helpful message when sending to d-d-a

[Lee Garrett]

Hi Cord,

On 17.09.23 12:02, Cord Beermann wrote:

tags 1050906 wontfix
severity 1050906 wishlist
thanks

Hallo! Du (Lee Garrett) hast geschrieben:


>From a user experience it's currently a bit cumbersome, as I'll send a mail,
wait 15 minutes to notice that it hasn't arrived, change a few things and
resend, wait another 15 minutes, etc. Which is quite an ineffective workflow.


Rejecting based on Mail content is discouraged by a RfC.

If we would reject misdirected mails to our lists we would produce

2 backscatter mails daily to mostly innocent netizens.


Rejecting ingress mails at the SMTP level can't and won't create backscatter 
mails. You're probably thinking of bouncing mails?



So in the current state of Mail-Federation which is mostly driven by
spamming monopolists I don't see a working solution.

Yours,
 Cord, Debian Listmaster of the day

Bug#1051943: Document requirements for sending mails to mailing lists which require GPG signature

[Lee Garrett]

Package: lists.debian.org
Severity: normal
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

it would be nice to have a checklist of things to check for sending mails to
mailing lists that require a GPG signature.

So far it is at least:
- No whitespace or unsigned text (#1050915), excluding Thunderbird as mail
  client
- Requiring re-signing the mail content on every new delivery attempt (#1051941)
- Informing that invalid mails get blackholed, and not rejected (#1050906)
- Info on where the keys are sourced from, to be able to check for e.g. expired
  keys
- Document where to ask when mails still don't go through (#debian-lists on
  irc.oftc.net)

Ideally this should then be linked from the respective overview pages to easily
be found, e.g. https://lists.debian.org/debian-devel-announce/

Greetings,
Lee

Bug#1051941: replay cache accepts signed mail before it goes through to mailing list

[Lee Garrett]

Package: lists.debian.org
Severity: normal
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

when sending a malformed mail to a mailing list requiring a valid PGP signature,
the replay cache will add signature to the cache, but then get rejected in a
later step.

This results in any later attempts to send the signed mail to silently fail
(#1050906), even though it would otherwise have a valid signature and be
correctly formed.

It would be nice if the signature verification check would be last in the milter
list to mitigate this issue.

Regards,
Lee

Bug#1051770: move services and binaries for AD DC setup to package samba-ad-dc

[Lee Garrett]

On Tue, 12 Sep 2023 14:24:09 +0300 Michael Tokarev  wrote:

Control: tag -1 + moreinfo

12.09.2023 14:14, Lee Garrett wrote:
> Source: samba
> Severity: minor
> X-Debbugs-Cc: deb...@rocketjump.eu
> 
> Hi,
> 
> I believe it would be a good idea to move the binaries and services required for

> AD DC operation to the package samba-ad-dc. Currently it's possible to run 
such
> a setup without installing the package, as it's just a metapackage.

Sure it is a meta-package, and it is described as such.

> Moving the binaries/services over would have the benefit of being able to drop
> the support of this package separately from the samba server, as it currently 
is
> for oldstable and older.

Which binaries/services do you mean, specially?  I for one know just one: it is
samba.service (and the init script) which starts samba-ad-dc, that's just two 
files.


I'm thinking

/etc/init.d/samba-ad-dc
/lib/systemd/system/samba-ad-dc.service
/usr/sbin/samba



/mjt

Bug#1051770: move services and binaries for AD DC setup to package samba-ad-dc

[Lee Garrett]

Source: samba
Severity: minor
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

I believe it would be a good idea to move the binaries and services required for
AD DC operation to the package samba-ad-dc. Currently it's possible to run such
a setup without installing the package, as it's just a metapackage.

Moving the binaries/services over would have the benefit of being able to drop
the support of this package separately from the samba server, as it currently is
for oldstable and older.

Greetings,
Lee


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

Kernel: Linux 6.1.0-12-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#921526: geany crashes when deleting files in Tree Browser

[Lee Garrett]

This seems to be fixed in the bookworm release.

On Wed, 06 Feb 2019 15:19:24 +0100 Lee Garrett  wrote:

Package: geany
Version: 1.33-1
Severity: important

Hi,

geany crashes when deleting files in Tree Browser. Steps to reproduce:

1) Open a geany project
2) Enable the side bar with View -> Show Sidebar
3) Switch to the "Tree Browser" tab
4) Double-click on a file to open it
5) Right-click on the file in the Tree Browser
6) Select "delete"

At this point geany with crash with following shell output:

--->8-->8-->8-->8-->8-->8-->8-->8-->8-->8---

(geany:7652): Gtk-WARNING **: 15:16:21.819: Theme parsing error: 
gtk-widgets.css:186:14: not a number

(geany:7652): Gtk-WARNING **: 15:16:21.819: Theme parsing error: 
gtk-widgets.css:186:14: Expected a string.

(geany:7652): Gtk-WARNING **: 15:16:21.824: Theme parsing error: 
gtk-widgets.css:2749:24: not a number

(geany:7652): Gtk-WARNING **: 15:16:21.824: Theme parsing error: 
gtk-widgets.css:2749:24: Expected a string.

(geany:7652): Gtk-WARNING **: 15:16:21.824: Theme parsing error: 
gtk-widgets.css:2940:14: not a number

(geany:7652): Gtk-WARNING **: 15:16:21.824: Theme parsing error: 
gtk-widgets.css:2940:14: Expected a string.

(geany:7652): Gtk-WARNING **: 15:16:21.824: Theme parsing error: 
gtk-widgets.css:2946:17: Expected a string.

(geany:7652): Gtk-WARNING **: 15:16:21.827: Theme parsing error: 
gtk-widgets.css:4083:14: not a number

(geany:7652): Gtk-WARNING **: 15:16:21.827: Theme parsing error: 
gtk-widgets.css:4083:14: Expected a string.

(geany:7652): Gtk-WARNING **: 15:16:21.827: Theme parsing error: 
gtk-widgets.css:4088:17: Expected a string.

(geany:7652): Gtk-WARNING **: 15:16:21.828: Theme parsing error: 
gtk-widgets.css:4729:14: not a number

(geany:7652): Gtk-WARNING **: 15:16:21.828: Theme parsing error: 
gtk-widgets.css:4729:14: Expected a string.

(geany:7652): Gtk-WARNING **: 15:16:21.829: Theme parsing error: 
xfce.css:47:16: not a number

(geany:7652): Gtk-WARNING **: 15:16:21.829: Theme parsing error: 
xfce.css:47:16: Expected a string.

(geany:7652): Gtk-WARNING **: 15:16:21.829: Theme parsing error: 
lightdm-gtk-greeter.css:16:14: not a number

(geany:7652): Gtk-WARNING **: 15:16:21.829: Theme parsing error: 
lightdm-gtk-greeter.css:16:14: Expected a string.

(geany:7652): Gtk-WARNING **: 15:16:21.829: Theme parsing error: 
lightdm-gtk-greeter.css:26:14: not a number

(geany:7652): Gtk-WARNING **: 15:16:21.829: Theme parsing error: 
lightdm-gtk-greeter.css:26:14: Expected a string.

(geany:7652): Gtk-WARNING **: 15:16:21.830: Theme parsing error: 
lightdm-gtk-greeter.css:40:16: not a number

(geany:7652): Gtk-WARNING **: 15:16:21.830: Theme parsing error: 
lightdm-gtk-greeter.css:40:16: Expected a string.

(geany:7652): Gtk-WARNING **: 15:16:21.830: Theme parsing error: 
lightdm-gtk-greeter.css:96:14: Expected a string.

Bug#1051140: Bug #1051140: lintian in bookworm does not know about bookworm-backports

[Lee Garrett]

Indeed, however the bug is about fixing it in stable.

On 03.09.23 16:45, Joachim Wiedorn wrote:

Hello Lee,

you can fix the problem by yourself:

Open file /usr/share/lintian/data/changes-file/known-dists
and add one line with "bookworm".

---
Have a nice day.
Joachim (Germany)

Bug#1051142: bookworm dput-ng does not know about bookworm-backports

[Lee Garrett]

Package: dput-ng
Version: 1.35
Severity: important
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

when trying to upload a package to bookworm-backports, it's impossible to do
with dput-ng from bookworm:

$ dput rhsrvany_1.1-2~bpo12+1_source.changes
Uploading rhsrvany using ftp to ftp-master (host: ftp.upload.debian.org; 
directory: /pub/UploadQueue/)
running allowed-distribution: check whether a local profile permits uploads to 
the target distribution
`bookworm-backports' not in the codename group

It would be nice if dput-ng would know about bookworm-backports.

Greetings,
Lee

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

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

Versions of packages dput-ng depends on:
ii  python3   3.11.2-1+b1
ii  python3-dput  1.35

dput-ng recommends no packages.

Versions of packages dput-ng suggests:
ii  dput-ng-doc  1.35
pn  python3-twitter  

-- no debconf information

Bug#1051140: lintian in bookworm does not know about bookworm-backports

[Lee Garrett]

Package: lintian
Version: 2.116.3
Severity: important
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

when preparing an upload for bookworm-backports, lintian in bookworm will
falsely error out, diminishing it's usefulness:

E: rhsrvany changes: bad-distribution-in-changes-file bookworm-backports

It would be great if lintian in stable would know about bookworm-backports.

Greetings,
Lee

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

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

Versions of packages lintian depends on:
ii  binutils2.40-2
ii  bzip2   1.0.8-5+b1
ii  diffstat1.65-1
ii  dpkg1.21.22
ii  dpkg-dev1.21.22
ii  file1:5.44-3
ii  gettext 0.21-12
ii  gpg 2.2.40-1.1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.15.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.28-2
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.35-1
ii  libdata-dpath-perl  0.58-2
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b1
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.22
ii  libemail-address-xs-perl1.05-1+b1
ii  libencode-perl  3.19-1+b1
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-2
ii  libipc-run3-perl0.048-3
ii  libjson-maybexs-perl1.004004-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005005-1
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.144-1
ii  libperlio-gzip-perl 0.20-1+b1
ii  libperlio-utf8-strict-perl  0.010-1
ii  libproc-processtable-perl   0.634-1+b2
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.003+ds-1
ii  libsereal-encoder-perl  5.003+ds-1
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.28-1
ii  libterm-readkey-perl2.38-2+b1
ii  libtext-levenshteinxs-perl  0.03-5+b1
ii  libtext-markdown-discount-perl  0.16-1
ii  libtext-xslate-perl 3.5.9-1+b2
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b1
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2
ii  liburi-perl 5.17-1
ii  libwww-mechanize-perl   2.16-1
ii  libwww-perl 6.68-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b1
ii  libyaml-libyaml-perl0.86+ds-1
ii  lzip [lzip-decompressor]1.23-5
ii  lzop1.04-2
ii  man-db  2.11.2-2
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.36.0-7
ii  t1utils 1.41-4
ii  unzip   6.0-28
ii  xz-utils5.4.1-0.2

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 2.40-2
ii  libtext-template-perl  1.61-1

-- no debconf information

Bug#1042906: ansible: please package new upstream version 8.x

[Lee Garrett]

Hi Dominik,

indeed! I'm currently letting the version of ansible/ansible-core in unstable 
linger a little bit longer to get some more testing, before pushing it as a 
stable-update. As soon as that is done, I'll package the latest for unstable again.


Greets,
Lee

On 02.08.23 17:13, Dominik George wrote:

Source: ansible
Version: 7.3.0+dfsg-1
Severity: wishlist

Hi Lee,

Ansible upstream is currently at 8.2.

In order to not having to resort to pip install, an update
of Debian's ansible package would be much appreciated.

Cheers,
Nik

Bug#1050915: truncate unsigned parts of signed mails to d-d-a

[Lee Garrett]

Package: lists.debian.org
Severity: normal
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

currently, when using Thunderbird to send OpenPGP/MIME signed mails to d-d-a,
the mail gets silently blackholed (#1050906). It seems like the reason is that
there is a small piece of text before the actual MIME-encoded data:

"This is an OpenPGP/MIME signed message (RFC 4880 and 3156)"

Would be nice if the tool in question could just truncate the unsigned bits
instead and accept the mail, assuming there's a valid signature.

Greetings,
Lee

Bug#1050906: reject non-conforming mail with helpful message when sending to d-d-a

[Lee Garrett]

Package: lists.debian.org
Severity: normal
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

every once in a while I'd like to send a mail to d-d-a, where the mail is
required to be signed. The only description is "Only messages signed by a Debian
developer will be accepted by this list."

Apparently the restriction is more than that, and it would be nice to reject the
mail on a SMTP level with a helpful message instead of blackholing it.

>From a user experience it's currently a bit cumbersome, as I'll send a mail,
wait 15 minutes to notice that it hasn't arrived, change a few things and
resend, wait another 15 minutes, etc. Which is quite an ineffective workflow.

Regards,
Lee

Bug#1042754: tor: don't autostart the service on installation

[Lee Garrett]

Hi anonymous user,

On Mon, 31 Jul 2023 11:25:54 + svsdzj+3p1rxwpwgcq8c@cs.email wrote:

Package: tor Version: 0.4.7.13-1 Severity: grave

Dear Maintainer,

please do not autostart the tor system service immediately after installing
it using `apt install tor`.

Current behavior reveals that the user installed the tor package, because
connections to the tor network start immediately after the package is
installed. This is problematic for a great many reasons. If apt is configured


Which are those reasons that warrant RC status of this bug? If I install tor, 
I'm bound to use it, otherwise I wouldn't do it.



to use https sources, then it is unlikely a network observer would know that
the tor package was being downloaded (unless they can correlate the size of
the download with the package size of tor and dependencies, and even that is
not a definitive proof).


This has already been proven feasible, since the byte sizes of the packages are 
public knowledge. Also, a network observer will see you have installed when you 
use it. So I don't see a privacy/security breach here.



Users don't expect the tor service to start immediately after installing it,
nor do they expect it to start automatically on every boot of their system.
If users even want to use the tor service, then they generally configure it
first before autostarting it (to setup bridges for example).


Indeed, in the case of a setting up a tor bridge, not autostarting might be good 
idea. However, this can trivially be done by masking the service (e.g. 
`systemctl mask tor.service`) before installation. You can also provide a 
/etc/tor/torrc before installing the package, and that will be used after 
installation.



I want to point out that users are not informed about nor asked for any
consent to these immediate outside connections to the tor network. No privacy
policy or warnings are presented to the user after `apt install tor`, the
service simply starts and connects to tor with no indication that this is
happening.


I'd argue that users do expect it, as it is the way all other daemons on Debian 
are started when installed. This has been the default for a long time. Can you 
back up that claim somehow?



The service should be shipped in a disabled state, so that it does not start
on system boot, nor should the service start immediately after installing
tor. If users wish to run the service on the system level automatically on
every boot then they can do so by doing `systemctl enable tor.service`. If
the tor maintainer really wishes to keep the automatic start of tor service
on installation as default behavior, then they should at least create a
debconf interface that asks the users if that is what they really wish to
happen, so that users can give their informed consent.


That would not be a feasible option, as this is considered "debconf abuse" [0]. 
The other problem is that it wouldn't be shown in non-interactive sessions, 
using for example puppet, ansible or Chef to install it.


[0] 
https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#do-not-abuse-debconf



Additionally, many users simply start the tor executable directly, with
configuration files in their home directory, when they need it instead of
automatically.


I'm not convinced this is a common usage pattern. However, if you can convince 
the maintainer it is, it might be worth splitting the package in tor-bin and 
tor-server packages, the former containing the binary, and the latter containing 
the service files starting the daemon. This would be a separate bug report, though.



When users start the service manually, they are at least presented with this
information:

[notice] Tor can't help you if you use it wrong! Learn how to be safe at
https://support.torproject.org/faq/staying-anonymous

Please do not autostart the tor system service immediately after installing
it using `apt install tor`.


All in all I believe this could be implemented if you can bring up convincing 
arguments why this is dangerous behaviour. In that case it would not be started, 
and the steps to get it to autostart would be documented in 
/usr/share/doc/tor/README.Debian. Since I don't believe this is falls in the 
severity of "grave" as defined in [1] (the package works for most people, it 
does not cause data loss nor introduces security holes on the system), I'm 
changing the bug severity.


[1] https://www.debian.org/Bugs/Developer#severities

Greetings,
Lee

Bug#1042768: Stop shipping scripts that don't work with irssi >= 1.4

[Lee Garrett]

Source: irssi-scripts
Version: 20220704
Severity: important
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

irssi 1.4 in bookworm ships with a new rendering system compared to 1.2.3 from
bullseye, breaking a few scripts in the process [0]. A list of affected scripts
is listed in the 1.4.1 news entry [1].

I propose to update to the latest irssi-scripts snapshot, and then remove any
remaining scripts still using Irssi::command('^format [...]), and add a news
entry for the next stable-update.

Regards,
Lee


[0] https://irssi.org/posts/#major-news-in-irssi-14-coming-from-irssi-123
grep for "The display system now renders formats on the fly"
[1] https://irssi.org/NEWS/#news-v1-4-1


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

Kernel: Linux 6.1.0-10-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1042002: missing suggests/recommends

[Lee Garrett]

Package: virt-v2v
Version: 2.2.0-1
Severity: minor
X-Debbugs-Cc: deb...@rocketjump.eu

Hello Hilko,

I've been using virt-v2v to convert Windows vmware images to libvirt. It is
missing a suggests or recommends on nbdkit, rhsrvany (which I'm currently
packaging, see #996850), and libnbd-bin. The latter I only found out by running
it in debug mode, the regular error message was not helpful.

Would be nice if virt-v2v could check for the nbdcopy binary, and suggest
installing libnbd-bin.

Regards,
Lee


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

Kernel: Linux 6.1.0-10-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages virt-v2v depends on:
ii  libc62.36-9+deb12u1
ii  libglib2.0-0 2.74.6-2
ii  libguestfs0  1:1.48.6-2
ii  libjansson4  2.14-2
ii  libnbd0  1.14.2-1
ii  libosinfo-1.0-0  1.10.0-2
ii  libpcre2-8-0 10.42-1
ii  libvirt0 9.0.0-4
ii  libxml2  2.9.14+dfsg-1.3~deb12u1

virt-v2v recommends no packages.

virt-v2v suggests no packages.

-- no debconf information

Bug#996850: ITP: rhsrvany -- Windows tools used by virt-v2v

[Lee Garrett]

Hi Ryan,

is there any update on the packaging progress?

Greets,
Lee


On Tue, 19 Oct 2021 10:48:35 -0500 Ryan Pavlik  wrote:

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

* Package name: rhsrvany
  Version : 0.20210127
  Upstream Author : Richard W.M. Jones, Red Hat Inc.
* URL : https://github.com/rwmjones/rhsrvany
* License : GPL-2+
  Programming Lang: C
  Description : Windows tools used by virt-v2v

 This package contains open-source replacements for
 proprietary Windows tools, SrvAny (RHSrvAny) and pnp_wait.
 They are used by the virt-v2v tool when converting
 Windows virtual machines.

This is required for virt-v2v (see https://bugs.debian.org/962293)
which was formerly part of libguestfs in Buster and now the
subject of its own RFP bug linked above.
The draft of that package is in the libvirt team,
and if this package is accepted, I'd anticipate joining that team
for team maintenance and sponsorship. The code itself is quite stable,
with a limited purpose and having seen little need for changes in
the past several years, so I anticipate
packaging maintenance load to be low.

Bug#116879: ssh-keygen -d undocumented switch

[Lee Garrett]

It looks like this bug is obsolete as the switch was removed. Closing this bug 
as such.

Bug#964941: base-files: please maintain base-files in a VCS such as git on salsa.d.o

[Lee Garrett]

Bump.

I'm trying to understand why /var/local/ is root:staff (#1039973), and a VCS 
would really help with that. It would also make it easier for you to accept 
patches for bugs.

Bug#1038113: New upstream available

[Lee Garrett]

Source: triplea
Severity: wishlist
X-Debbugs-Cc: deb...@rocketjump.eu

Hello fine Debian Java maintainers,

triplea has had a few updates since the last upload. Current stable is
2.5.22294. Can we get some love for this package?

Thanks in advance!

~ lee


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

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

Bug#1037126: ansible-core: Patch to fix URI Module find json sub type

[Lee Garrett]

Hi Bernhard,

I acknowledge this bug, and will issue a point release update once it has been 
merged upstream.


Thanks for the report!

Greets,
Lee

On 05.06.23 15:21, Bernhard Turmann wrote:

Source: ansible-core
Source-Version: 2.14.3-1
Severity: important
Tags: fixed-upstream, patch, upstream


Dear Maintainer,
the attached patch applied in upstream commit [0] will fix ansible-core 2.14.3-1 
in Debian 12 Bookworm having an issue with the URI module recognizing JSON with 
some API endpoints correctly.


I am using this module in many tasks with the CEPH Dashboard API and confirm the 
patch is fixing it successfully. Without the patch, all these tasks are failing 
after installing a fresh Debian Bookworm.


Note:
The ansible version in Bullseye was working fine in this regard.

Upstream has an open PR [1] against stable-2.14, but not merged yet.

I would have opened a Merge Request on Salsa, but I just registered and waiting 
for approval.


[0] 
https://github.com/ansible/ansible/commit/0c7361d9acf7c8966a09f67de2a8679ef86fd856


[1] https://github.com/ansible/ansible/pull/80870

With Best Regards
Berni

Bug#1004301: please add more information

[Lee Garrett]

Hi,

I indeed have only one webcam (on a Lenovo Thinkpad T490). I think the 2nd 
instance might be the IR mode of the camera. Weirdly enough, cheese lists 4 (!) 
instances of the camera, all named "Integrated Camera (V4L2)", two showing a 
true color image, and showing a greyscale image (I'm guessing IR).


I've tried to reproduce the bug, and now it doesn't seem possible anymore. Qtqr 
now correclty works, and does not produce a backtrace. I guess it was somewhere 
in the underlying Qt5 libraries, and they got upgraded in the mean time. As 
such, I'm fine with closing this bug. Thanks!


Greetings,
Lee

On 31.05.23 17:19, georgesk wrote:


Hi,

thank you for your bug report.

You are telling that when you "Decode from webcam", two webcams with the
same name and identification are listed in a select widget.

Have you more than one physical webcam?

Please can you install another application using webcams, for example
"cheese" and test whether it reports also such a duplicate webcam?

So far, I could not reproduce the bug.

Thank you in advance.   Georges.

Bug#1035875: Arbitrary code execution vulnerability in versions < 2.3

[Lee Garrett]

Package: osslsigncode
Version: 2.1-1
Severity: grave
Tags: security
X-Debbugs-Cc: secur...@debian.org, deb...@rocketjump.eu, Debian Security Team 


It was reported through IRC that the current stable version of osslsigncode
contains an unpatched security vulnerability:

https://github.com/mtrojnar/osslsigncode/releases/tag/2.3

Unfortunately, upstream has not assigned a CVE, and a quick glance at the closed
bug reports didn't reveal any further details.

Regards,
Lee


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

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

Versions of packages osslsigncode depends on:
ii  libc6 2.36-9
ii  libcurl4  7.88.1-9
ii  libssl3   3.0.8-1

osslsigncode recommends no packages.

osslsigncode suggests no packages.

Bug#1029588: bts: Changes in libio-socket-ssl-perl 2.078 make bts fail to send mail to mail-server via SSL/TLS - hostname verification failed

[Lee Garrett]

On Sat, 18 Mar 2023 17:06:08 +0100 Dominique Dumont  wrote:

On Tue, 14 Feb 2023 22:21:26 +0100 Lee Garrett  wrote:
> Bumped severity as this makes bts currently unusable, and probably 
> breaks for quite a few DDs their workflow.


This does not break on my system where bts is connected to local sendmail 
(which is the default setup).

Which hints at a workaround: have bts connect to local sendmail and have 
sendmail forward the mail to the SMTPS server.


While this setup might work for some people, this has IMHO quite a few hefty 
drawbacks and requires me to maintain a MTA on my local machine. I could 
elaborate, but I don't think it's on-topic for this bug report.




The change mentioned by Daniel affects only a setup where the host if 
configured via its IP address, not via a host name:
See the change in SSL.pm in commit 
https://github.com/noxxi/p5-io-socket-ssl/commit/c0a063b70f0a3ad033da0a51923c65bd2ff118a0


While Daniel did mention this commit (which might or might not be related to the 
issue), bts fails on a configured SMTPS hostname which otherwise correctly 
validates with other MUA.




Which is not the case here:

$ perl -S -MDevel::SimpleTrace bts --smtp-host smtps://mail.wgdd.de usertag 
1029588 + dod-test-with-tls
bts: failed to open SMTPS connection to smtps://mail.wgdd.de
(hostname verification failed)
at main::send_mail(mail.wgdd.de)
at main::mailbtsall(/usr/bin/bts:2839)
at main::(/usr/bin/bts:825)

Unfortunately, I can no longer investigate this issue as it looks like that my 
IP address is now blacklisted on Daniel's server:

$ perl -MDevel::SimpleTrace scripts/bts.pl --smtp-host smtps://mail.wgdd.de 
usertag 1029588 + dod-test-with-tls
bts.pl: failed to open SMTPS connection to smtps://mail.wgdd.de
(Connection refused)
at main::send_mail(mail.wgdd.de)
at main::mailbtsall(scripts/bts.pl:2849)
at main::(scripts/bts.pl:834)

On a hunch, I would guess that Daniel's server is configured to handle STARTTLS, which is not supported by bts. But I cannot verify this. 
In any case this does not explain why Daniel sees bts working with libio-socket-ssl-perl 2.077 but not with 2.078.


I'm sure that bts supports STARTTLS. I am using bts with my MTA on 587/tcp, 
which enforces STARTTLS and requires credentials (I just double-checked via 
swaks). With the old libio-socket-ssl-perl 2.069-1 this works, so it's clearly a 
regression.




All the best


Greetings,
Lee

Bug#1032655: psi-plus segfaults

[Lee Garrett]

On 12.03.23 00:35, Stefan Kropp wrote:

On Fri, Mar 10, 2023 at 03:45:38PM +0100, Lee Garrett wrote:

psi-plus currently simply segfaults on a stock bookworm installation:

$ psi-plus
[20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile 
(unknown:0, unknown)
[20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile 
(unknown:0, unknown)
[20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile 
(unknown:0, unknown)
[20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile 
(unknown:0, unknown)
Segmentation fault


On my bookworm system, I also get libpng warnings, but no segfault.

Maybe a backtrace in gdb can help to get more information.


the bug was originally reported by a user on IRC, and I could confirm that I'm 
seeing the same as them, so I'm assuming that some portion of users are affected 
(and it's not just something broken on my system). I think it should be 
reproducible in a minimal bookworm gnome VM.


backtrace below:

$ gdb psi-plus
GNU gdb (Debian 13.1-2) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from psi-plus...
(No debugging symbols found in psi-plus)
(gdb) run
Starting program: /usr/bin/psi-plus
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x716956c0 (LWP 102344)]
[New Thread 0x70e946c0 (LWP 102345)]
[New Thread 0x7fffebfff6c0 (LWP 102346)]
[New Thread 0x7fffeb7fe6c0 (LWP 102347)]
[New Thread 0x7fffeaffd6c0 (LWP 102348)]
[New Thread 0x7fffea7fc6c0 (LWP 102349)]
[New Thread 0x7fffe9ffb6c0 (LWP 102350)]
[Detaching after fork from child process 102351]
[Detaching after fork from child process 102352]
[Detaching after fork from child process 102354]
[Detaching after fork from child process 102355]
[Detaching after fork from child process 102357]
[New Thread 0x7fffe91ff6c0 (LWP 102358)]
[New Thread 0x7fffe89fe6c0 (LWP 102359)]
[20230322 14:39:21] W:libpng warning: iCCP: known incorrect sRGB profile 
(unknown:0, unknown)
[20230322 14:39:21] W:libpng warning: iCCP: known incorrect sRGB profile 
(unknown:0, unknown)
[20230322 14:39:21] W:libpng warning: iCCP: known incorrect sRGB profile 
(unknown:0, unknown)
[20230322 14:39:21] W:libpng warning: iCCP: known incorrect sRGB profile 
(unknown:0, unknown)


Thread 1 "psi-plus" received signal SIGSEGV, Segmentation fault.
0x77e94a4d in XInternAtoms () from /lib/x86_64-linux-gnu/libX11.so.6
(gdb) where
#0  0x77e94a4d in XInternAtoms () from /lib/x86_64-linux-gnu/libX11.so.6
#1  0x55918223 in X11WindowSystem::X11WindowSystem() ()
#2  0x55918805 in X11WindowSystem::instance() ()
#3  0x559e1884 in MainWin::MainWin(bool, bool, PsiCon*) ()
#4  0x558b5ba2 in PsiCon::init() ()
#5  0x559d36b6 in PsiMain::sessionStart() ()
#6  0x770dd6f0 in QObject::event(QEvent*) () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#7  0x76362fae in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#8  0x770b16f8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() from /lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x770b4681 in QCoreApplicationPrivate::sendPostedEvents(QObject*, 
int, QThreadData*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5

#10 0x7710a153 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x7551e7a9 in g_main_context_dispatch () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0

#12 0x7551ea38 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x7551eacc in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x77109836 in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x770b017b in 
QEventLoop::exec(QFlags) () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x770b82d6 in QCoreApplication::exec() () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5

#17 0x557e4e95 in main ()
(gdb) list
1   ../sysdeps/unix/sysv/linux/dl-vdso-setup.c: No such file or directory.
(gdb)

Regards,
Lee

Bug#1032418: zcfan service is not stopped on package removal

[Lee Garrett]

Debugging this issue I found that it's caused by #1031695 (a bug in 
dh_installsystemd). I've reduced this bug severity accordingly.

Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Lee Garrett]

Hi,

is there any update on fixing this issue before the bookworm release? I stumbled 
upon this bug report trying to fix #1032418, which is a rather grave bug. zcfan 
is one of the 37 packages affected. Because of this issue, dh_installsystemd 
does not generate a .postrm file to stop the service, so when a user installs 
zcfan, and after that thinkfan, zcfan is removed, but the service still runs. 
Since there are now two services controlling the fan speed, it will cause 
unpredictable behaviour and potentially HW damage.


Regards,
Lee

Bug#1032655: psi-plus segfaults

[Lee Garrett]

Package: psi-plus
Version: 1.4.554-5+b2
Severity: grave
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

psi-plus currently simply segfaults on a stock bookworm installation:

$ psi-plus 
[20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile 
(unknown:0, unknown)
[20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile 
(unknown:0, unknown)
[20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile 
(unknown:0, unknown)
[20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile 
(unknown:0, unknown)
Segmentation fault

Regards,
Lee

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

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

Versions of packages psi-plus depends on:
ii  libc6 2.36-8
ii  libgcc-s1 12.2.0-14
ii  libhunspell-1.7-0 1.7.1-1
ii  libidn12  1.41-1
ii  libminizip1   1.1-8+b1
ii  libqca-qt5-2  2.3.5-2
ii  libqca-qt5-2-plugins  2.3.5-2
ii  libqt5concurrent5 5.15.8+dfsg-3
ii  libqt5core5a  5.15.8+dfsg-3
ii  libqt5dbus5   5.15.8+dfsg-3
ii  libqt5gui55.15.8+dfsg-3
ii  libqt5keychain1   0.13.2-5
ii  libqt5network55.15.8+dfsg-3
ii  libqt5sql55.15.8+dfsg-3
ii  libqt5sql5-sqlite 5.15.8+dfsg-3
ii  libqt5svg55.15.8-2
ii  libqt5widgets55.15.8+dfsg-3
ii  libqt5x11extras5  5.15.8-2
ii  libqt5xml55.15.8+dfsg-3
ii  libstdc++612.2.0-14
ii  libx11-6  2:1.8.4-2
ii  psi-plus-common   1.4.554-5
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages psi-plus recommends:
ii  psi-plus-l10n 1.4.554-1
ii  psi-plus-plugins  1.4.554-5+b2
ii  psi-plus-sounds   1.4.554-5
ii  sox   14.4.2+git20190427-3.4

Versions of packages psi-plus suggests:
pn  libgnome-keyring0  
ii  xdg-utils  1.1.3-4.1

-- no debconf information

Bug#1032460: unblock: thinkfan/1.3.1-4

[Lee Garrett]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: think...@packages.debian.org, deb...@rocketjump.eu
Control: affects -1 + src:thinkfan

Hello release team,

Please unblock package thinkfan. It is a tool to control the fans of Thinkpad
laptops. zcfan is a similar tool that also handles fan control on Thinkpads. To
prevent hardware damage, only one should be installed at the same time
(#1032310).

[ Reason ]
It fixes an RC bug (#1032310).
 
[ Impact ]
Users could accidentally install both zcfan and thinkfan at the same time during
triage, causing unpredictable fan speed, and at worst cause hardware damage.

[ Tests ]
I have manually tested that the added "Conflicts: zcfan" works as intended.

[ Risks ]
Both thinkfan and zcfan are leaf packages. There is no risk as this change just
adds a "Conflicts" between those packages.
(Discussion of the risks involved. E.g. code is trivial or
complex, key package vs leaf package, alternatives available.)

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

$ debdiff thinkfan_1.3.1-3_amd64.deb thinkfan_1.3.1-4_amd64.deb
File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)

{+Conflicts: zcfan+}
Depends: libatasmart4 (>= 0.13), libc6 (>= [-2.30),-] {+2.34),+} libgcc-s1 (>= 
3.0), libstdc++6 (>= [-5.2), libyaml-cpp0.6-] {+11), libyaml-cpp0.7+} (>= 
[-0.6.2)-] {+0.7.0)+}
Installed-Size: [-464-] {+472+}
Version: [-1.3.1-3-] {+1.3.1-4+}

[ Other info ]
(Anything else the release team should know.)

unblock thinkfan/1.3.1-4

Bug#1032418: zcfan service is not stopped on package removal

[Lee Garrett]

Package: zcfan
Severity: serious
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

while testing the Breaks: directive between zcfan and thinkfan, I noticed that
the zcfan service is not stopped upon uninstall. This is not caught by piuparts,
as by default the zcfan service is not started. The solution is to have a
debian/rules entry like in [0].

I noticed that you're a DM, and since it's fairly late in the freeze process,
I'm willing to guide your through the process of fixing the package for the
bookworm release.

Regards,
Lee

[0] https://salsa.debian.org/debian/thinkfan/-/blob/master/debian/rules#L24

Full terminal output showing the issue below:

12:59:18 [root@batou:~] 4s # apt install zcfan
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  zcfan
0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded.
Need to get 0 B/8.980 B of archives.
After this operation, 36,9 kB of additional disk space will be used.
Selecting previously unselected package zcfan.
(Reading database ... 377831 files and directories currently installed.)
Preparing to unpack .../zcfan_1.2.1-1+b1_amd64.deb ...
Unpacking zcfan (1.2.1-1+b1) ...
Setting up zcfan (1.2.1-1+b1) ...
Processing triggers for man-db (2.11.2-1) ...
Scanning processes...   

   
Scanning candidates...  

   
Scanning processor microcode... 

   
Scanning linux images...

   

Running kernel seems to be up-to-date.

The processor microcode seems to be up-to-date.

No services need to be restarted.

No containers need to be restarted.

User sessions running outdated binaries:
 randall @ session #2: gdm-wayland-ses[1967]
 randall @ user manager service: firefox-esr[3254], gnome-session-b[2019], 
gnome-shell[2048], systemd[1784], thunderbird[2932]

No VM guests are running outdated hypervisor (qemu) binaries on this host.
12:59:27 [root@batou:~] 4s # systemctl status zcfan
○ zcfan.service - Zero-configuration fan control for ThinkPad
 Loaded: loaded (/lib/systemd/system/zcfan.service; enabled; preset: 
enabled)
 Active: inactive (dead) since Mon 2023-03-06 12:58:59 CET; 36s ago
   Duration: 1min 9.982s
Process: 17359 ExecStart=/usr/bin/zcfan (code=exited, status=0/SUCCESS)
   Main PID: 17359 (code=exited, status=0/SUCCESS)
CPU: 275ms

Mär 06 12:57:49 batou zcfan[17359]: [CFG] At 90C fan is set to maximum
Mär 06 12:57:49 batou zcfan[17359]: [CFG] At 80C fan is set to medium
Mär 06 12:57:49 batou zcfan[17359]: [CFG] At 70C fan is set to low
Mär 06 12:57:49 batou zcfan[17359]: [FAN] Temperature now 51C, fan set to off
Mär 06 12:58:23 batou zcfan[17359]: [FAN] Temperature now 71C, fan set to low
Mär 06 12:58:26 batou zcfan[17359]: [FAN] Temperature now 50C, fan set to off
Mär 06 12:58:59 batou zcfan[17359]: [FAN] Quit requested, reenabling 
thinkpad_acpi fan control
Mär 06 12:58:59 batou systemd[1]: Stopping zcfan.service - Zero-configuration 
fan control for ThinkPad...
Mär 06 12:58:59 batou systemd[1]: zcfan.service: Deactivated successfully.
Mär 06 12:58:59 batou systemd[1]: Stopped zcfan.service - Zero-configuration 
fan control for ThinkPad.
12:59:35 [root@batou:~] 3 # systemctl start zcfan
12:59:39 [root@batou:~] # systemctl status zcfan
● zcfan.service - Zero-configuration fan control for ThinkPad
 Loaded: loaded (/lib/systemd/system/zcfan.service; enabled; preset: 
enabled)
 Active: active (running) since Mon 2023-03-06 12:59:39 CET; 3s ago
   Main PID: 18995 (zcfan)
  Tasks: 1 (limit: 28396)
 Memory: 264.0K
CPU: 21ms
 CGroup: /system.slice/zcfan.service
 └─18995 /usr/bin/zcfan

Mär 06 12:59:39 batou systemd[1]: Started zcfan.service - Zero-configuration 
fan control for ThinkPad.
Mär 06 12:59:39 batou zcfan[18995]: [CFG] At 90C fan is set to maximum
Mär 06 12:59:39 batou zcfan[18995]: [CFG] At 80C fan is set to medium
Mär 06 12:59:39 batou zcfan[18995]: [CFG] At 70C fan is set to low
Mär 06 12:59:39 batou zcfan[18995]: [FAN] Temperature now 50C, fan set to off
12:59:43 [root@batou:~] # apt purge zcfan
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following 

Bug#1032276: Running as server spams the logs with "Console input too long!"

[Lee Garrett]

Package: quakespasm
Version: 0.95.1+dfsg-1
Severity: normal
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

when using quakespasm as server (via the quake-server package), the daemon spams
the following message at about ~160 messages per second until I terminate the
daemon.

Mar 02 14:10:33 batou quake-server[1026]: Console input too long!
Mar 02 14:10:33 batou quake-server[1026]: Console input too long!
Mar 02 14:10:33 batou quake-server[1026]: Console input too long!
Mar 02 14:10:33 batou quake-server[1026]: Console input too long!
Mar 02 14:10:33 batou quake-server[1026]: Console input too long!
Mar 02 14:10:33 batou quake-server[1026]: Console input too long!
Mar 02 14:10:33 batou quake-server[1026]: Console input too long!
Mar 02 14:10:33 batou quake-server[1026]: Console input too long!
Mar 02 14:10:33 batou quake-server[1026]: Console input too long!
[...]

This is a default installation together with quake-registered installed, and no
further config customization. I had it installed for testing purposes.

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

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

Versions of packages quakespasm depends on:
ii  libc6   2.36-8
ii  libflac12   1.4.2+ds-2
ii  libgl1  1.6.0-1
ii  libmad0 0.15.1b-10.1+b1
ii  libmikmod3  3.3.11.1-7
ii  libopusfile00.12-4
ii  libsdl2-2.0-0   2.26.3+dfsg-1
ii  libvorbisfile3  1.3.7-1

quakespasm recommends no packages.

quakespasm suggests no packages.

-- no debconf information

Bug#1032077: `dch --lts` targets stretch instead of buster

[Lee Garrett]

Package: devscripts
Version: 2.22.2
Severity: normal
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

running `dch --lts` will set the target distribution to stretch. However, the
current LTS release is buster [0].

[0] https://wiki.debian.org/LTS


-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
BTS_SMTP_HOST="smtp.rocketjump.eu:587"
DEBSIGN_KEYID="2FE2 163F 611C 80BE 2BF5  EE62 48D1 9F46 BC99 C9B7"

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.21.20
ii  fakeroot  1.29-1
ii  file  1:5.44-3
ii  gnupg 2.2.40-1
ii  gpgv  2.2.40-1
ii  libc6 2.36-8
ii  libfile-dirlist-perl  0.05-3
ii  libfile-homedir-perl  1.006-2
ii  libfile-touch-perl0.12-2
ii  libfile-which-perl1.27-2
ii  libipc-run-perl   20220807.0-1
ii  libmoo-perl   2.005005-1
ii  libwww-perl   6.67-1
ii  patchutils0.4.2-1
ii  perl  5.36.0-7
ii  python3   3.11.2-1
ii  sensible-utils0.0.17+nmu1
ii  wdiff 1.2.2-5

Versions of packages devscripts recommends:
ii  apt 2.5.6
ii  curl7.87.0-2
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2022.12.24
ii  dput-ng [dput]  1.35
pn  equivs  
ii  libdistro-info-perl 1.5
ii  libdpkg-perl1.21.20
ii  libencode-locale-perl   1.05-3
pn  libgit-wrapper-perl 
pn  libgitlab-api-v4-perl   
ii  liblist-compare-perl0.55-2
ii  liblwp-protocol-https-perl  6.10-1
pn  libsoap-lite-perl   
ii  libstring-shellquote-perl   1.04-3
ii  libtry-tiny-perl0.31-2
ii  liburi-perl 5.17-1
ii  licensecheck3.3.5-1
ii  lintian 2.116.3
ii  man-db  2.11.2-1
ii  patch   2.7.6-7
ii  pristine-tar1.50
ii  python3-apt 2.5.2+b1
ii  python3-debian  0.1.49
ii  python3-magic   2:0.4.26-3
ii  python3-requests2.28.1+dfsg-1
pn  python3-unidiff 
ii  python3-xdg 0.28-2
ii  strace  6.1-0.1
ii  unzip   6.0-27
ii  wget1.21.3-1+b2
ii  xz-utils5.4.1-0.2

Versions of packages devscripts suggests:
ii  adequate  0.15.7
pn  at
ii  autopkgtest   5.28
pn  bls-standalone
ii  build-essential   12.9
pn  check-all-the-things  
pn  cvs-buildpackage  
ii  debhelper 13.11.4
ii  diffoscope234
ii  disorderfs0.5.11-3
pn  dose-extra
pn  duck  
pn  elpa-devscripts   
ii  faketime  0.9.10-2.1
pn  gnuplot   
pn  how-can-i-help
ii  libauthen-sasl-perl   2.1600-3
pn  libdbd-pg-perl
ii  libfile-desktopentry-perl 0.22-3
ii  libnet-smtps-perl 0.10-2
pn  libterm-size-perl 
ii  libtimedate-perl  2.3300-2
pn  libyaml-syck-perl 
ii  mailutils [mailx] 1:3.15-3+b2
ii  mmdebstrap1.3.1-3
pn  mozilla-devscripts
pn  mutt  
ii  openssh-client [ssh-client]   1:9.2p1-2
ii  piuparts  1.1.7
ii  postgresql-client 15+247
ii  postgresql-client-15 [postgresql-client]  15.2-1
pn  pristine-lfs  
ii  quilt 0.67+really0.66-1
pn  ratt  
pn  reprotest 
pn  svn-buildpackage  
pn  w3m   

-- no debconf information

Bug#1031835: quilt will create spurious files from certain patches on push/pop

[Lee Garrett]

Package: quilt
Version: 0.67+really0.66-1
Severity: important
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

some patches imported by quilt may be patch series, which create a file in one
diff, but remove it again in another. In those cases quilt will correctly keep
the file from existing on `quilt push`. However, on `quilt pop` the spurious
file will be created. I have a minimal reproducer here:

---8<--8<--8<--8<--8<--8<--8<--8<--8<--8<---

23:01:22 [randall@batou:~/tmp] $ find
.
./tmp.patch
23:01:23 [randall@batou:~/tmp] $ cat tmp.patch 
--- /dev/null
+++ b/spurious_file
@@ -0,0 +1 @@
+some content here
--- a/spurious_file
+++ /dev/null
@@ -1 +0,0 @@
-some content here
23:01:28 [randall@batou:~/tmp] $ quilt import tmp.patch 
Importing patch tmp.patch (stored as tmp.patch)
23:01:32 [randall@batou:~/tmp] $ quilt push; quilt pop
Applying patch tmp.patch
patching file spurious_file
patching file spurious_file

Now at patch tmp.patch
Removing patch tmp.patch
Restoring spurious_file

No patches applied
23:01:39 [randall@batou:~/tmp] $ find
.
./.pc
./.pc/.version
./.pc/.quilt_series
./.pc/.quilt_patches
./spurious_file
./tmp.patch
./debian
./debian/patches
./debian/patches/tmp.patch
./debian/patches/series
23:01:43 [randall@batou:~/tmp] $ cat spurious_file 
some content here
23:01:48 [randall@batou:~/tmp] $ rm spurious_file 
23:03:07 [randall@batou:~/tmp] $ quilt push --refresh; quilt pop
Applying patch tmp.patch
patching file spurious_file
patching file spurious_file
Refreshed patch tmp.patch

Now at patch tmp.patch
Removing patch tmp.patch
Restoring spurious_file

No patches applied
23:03:23 [randall@batou:~/tmp] $ cat spurious_file 
some content here

---8<--8<--8<--8<--8<--8<--8<--8<--8<--8<---

As you can see above, "spurious_file" is created after `quilt push; quilt pop`,
even though it shouldn't exist (it's created on "pop"). This even persists when
refreshing the patch, where it should at least drop both diffs completely.

I've set the severity to important, as it breaks with the user's expectation,
and potentially could cause spurious files ending up in source packages that
shouldn't.

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

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

Versions of packages quilt depends on:
ii  bsdextrautils   2.38.1-4
ii  bzip2   1.0.8-5+b1
ii  diffstat1.65-1
ii  ed  1.19-1
ii  gettext 0.21-11
ii  patch   2.7.6-7
ii  perl5.36.0-7
ii  sensible-utils  0.0.17+nmu1

Versions of packages quilt recommends:
ii  less  590-1.1

Versions of packages quilt suggests:
pn  default-mta | mail-transport-agent  
ii  graphviz2.42.2-7+b3
pn  procmail

-- no debconf information

Bug#1031409: Add wireguard support

[Lee Garrett]

Package: gnome-control-center
Version: 1:43.4.1-1
Severity: minor
Tags: patch
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

Since network-manager supports wireguard, and gnome-control-center is the 
default
connection editor in gnome, it would be nice to add wireguard support as already
merged upstream:

https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1364

Greets,
Lee

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

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

Versions of packages gnome-control-center depends on:
ii  accountsservice   22.08.8-5
ii  apg   2.2.3.dfsg.1-5+b2
ii  colord1.4.6-2.1
ii  desktop-base  12.0.2
ii  desktop-file-utils0.26-1
ii  gnome-control-center-data 1:43.4.1-1
ii  gnome-desktop3-data   43.1-1
ii  gnome-settings-daemon 43.0-4
ii  gsettings-desktop-schemas 43.0-1
ii  libaccountsservice0   22.08.8-5
ii  libadwaita-1-01.2.1-2
ii  libc6 2.36-8
ii  libcairo2 1.16.0-7
ii  libcolord-gtk4-1  0.3.0-3
ii  libcolord21.4.6-2.1
ii  libcups2  2.4.2-1+b2
ii  libepoxy0 1.5.10-1
ii  libfontconfig12.14.1-4
ii  libgcr-base-3-1   3.41.1-1+b1
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libglib2.0-0  2.74.5-1
ii  libgnome-bg-4-2   43.1-1
ii  libgnome-bluetooth-ui-3.0-13  42.5-3
ii  libgnome-desktop-4-2  43.1-1
ii  libgnome-rr-4-2   43.1-1
ii  libgnutls30   3.7.8-5
ii  libgoa-1.0-0b 3.46.0-1
ii  libgoa-backend-1.0-1  3.46.0-1
ii  libgsound01.0.3-2
ii  libgtk-3-03.24.36-3
ii  libgtk-4-14.8.3+ds-2
ii  libgtop-2.0-112.40.0-2
ii  libgudev-1.0-0237-2
ii  libibus-1.0-5 1.5.27-4
ii  libkrb5-3 1.20.1-1
ii  libmalcontent-0-0 0.11.0-4
ii  libmm-glib0   1.20.4-1
ii  libnm01.40.10-1
ii  libnma-gtk4-0 1.10.6-1
ii  libpango-1.0-01.50.12+ds-1
ii  libpangocairo-1.0-0   1.50.12+ds-1
ii  libpolkit-gobject-1-0 122-3
ii  libpulse-mainloop-glib0   16.1+dfsg1-2+b1
ii  libpulse0 16.1+dfsg1-2+b1
ii  libpwquality1 1.4.5-1+b1
ii  libsecret-1-0 0.20.5-3
ii  libsmbclient  2:4.17.5+dfsg-2
ii  libsnapd-glib-2-1 1.63-5
ii  libudisks2-0  2.9.4-4
ii  libupower-glib3   0.99.20-2
ii  libwacom9 2.5.0-1
ii  libx11-6  2:1.8.3-3
ii  libxi62:1.8-1+b1
ii  libxml2   2.9.14+dfsg-1.1+b3
ii  webp-pixbuf-loader0.0.5-5

Versions of packages gnome-control-center recommends:
ii  cracklib-runtime  2.9.6-5+b1
ii  cups-pk-helper0.2.6-1+b1
ii  gkbd-capplet  3.28.1-1
ii  gnome-bluetooth-sendto42.5-3
ii  gnome-online-accounts 3.46.0-1
ii  gnome-remote-desktop  43.3-1
ii  gnome-user-docs   43.0-1
ii  gnome-user-share  43.0-1
ii  iso-codes 4.12.0-1
ii  libcanberra-pulse 0.30-10
pn  libnss-myhostname 
ii  libspa-0.2-bluetooth  0.3.65-2
ii  malcontent-gui0.11.0-4
ii  network-manager-gnome 1.30.0-2
ii  polkitd   122-3
ii  power-profiles-daemon 0.12-1+b1
pn  realmd
ii  rygel 0.42.0-2
ii  rygel-tracker 0.42.0-2
ii  system-config-printer-common  1.5.18-1

Versions of packages gnome-control-center suggests:
ii  gnome-software   43.3-1
pn  gstreamer1.0-pulseaudio  
ii  pkexec   122-3
ii  x11-xserver-utils7.7+9+b1

-- debconf-show failed

Bug#995156: easy-rsa: vars Autodetection

[Lee Garrett]

I'm bumping the bug severity because currently it will ignore 
security-relevant settings like keysize and algo, and the defaults are 
pretty weak.

Bug#1029588: bts: Changes in libio-socket-ssl-perl 2.078 make bts fail to send mail to mail-server via SSL/TLS - hostname verification failed

[Lee Garrett]

Bumped severity as this makes bts currently unusable, and probably 
breaks for quite a few DDs their workflow.

Bug#1030173: Document breaking changes in NEWS.Debian

[Lee Garrett]

On 31/01/2023 22:08, Vincent Bernat wrote:

On 2023-01-31 21:44, Lee Garrett wrote:

with release 2.6 haproxy has dropped the "ssl-engine" keyword by 
default. Would

be nice to document that in NEWS.Debian so it gets shown by tools such as
apt-listchanges during upgrade from bullseye to bookworm.

In my case haproxy failed to start with my bullseye config since it 
still had

the "ssl-engine" keyword in it.


I understand this would be useful, but it opens me to get bugs like 
"NEWS.Debian says something about ssl-engine, but not about some other 
change". I would need to make a summary of upstream's CHANGELOG file. 
This seems a tedious task.


I've written a NEWS file for you:

haproxy (2.6.8-2) unstable; urgency=medium

  Starting with haproxy 2.6, the "ssl-engine" keyword has been removed. 
You will

  need to remove this setting for your previous config to continue to work.

  Previously, clients sending an invalid request header like "Version: 
rtsp/1.1"
  would still get their request being served. Starting with haproxy 
2.6, this
  will result in a 502 response. If you depend on the old, buggy 
behaviour, set

  "option accept-invalid-http-requests" in the relevant config section.

 -- Lee Garrett   Tue, 31 Jan 2023 22:57:05 +0100

Bug#1030173: Document breaking changes in NEWS.Debian

[Lee Garrett]

On 31/01/2023 22:08, Vincent Bernat wrote:

On 2023-01-31 21:44, Lee Garrett wrote:

with release 2.6 haproxy has dropped the "ssl-engine" keyword by 
default. Would

be nice to document that in NEWS.Debian so it gets shown by tools such as
apt-listchanges during upgrade from bullseye to bookworm.

In my case haproxy failed to start with my bullseye config since it 
still had

the "ssl-engine" keyword in it.


I understand this would be useful, but it opens me to get bugs like 
"NEWS.Debian says something about ssl-engine, but not about some other 
change". I would need to make a summary of upstream's CHANGELOG file. 
This seems a tedious task.
I wouldn't list all changes there, only those that break existing 
setups. So stuff where admins need to get active.


AFAICS there are only three backwards-incompatible changes [0]:
- "ssl-engine" being dropped
- openssl 0.9.8 support being dropped (irrelevant, as the package is 
built against a newer version)
- previously, clients sending an invalid "Version: rtsp/1.1" header 
would still get their request served, this is now caught and a 502 
served. The old behaviour can be enabled with "option 
accept-invalid-http-request"


All other changes add new options, or improve on existing behaviour, so 
nothing that breaks existing config during upgrade.


I'm fine with writing a NEWS.Debian for you as I think users would 
benefit from it. I think the ssl-engine drop is a bigger speedbump, as 
configs with that setting will silently fail on upgrade, as there 
doesn't seem to be any validation of it when it gets restarted. I only 
noticed a bit later as some of my services weren't reachable.


[0] https://www.mail-archive.com/haproxy@formilux.org/msg42371.html, 
grep for "potentially user-visible changes"

Bug#1030173: Document breaking changes in NEWS.Debian

[Lee Garrett]

Package: haproxy
Version: 2.6.8-1
Severity: normal
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

with release 2.6 haproxy has dropped the "ssl-engine" keyword by default. Would
be nice to document that in NEWS.Debian so it gets shown by tools such as
apt-listchanges during upgrade from bullseye to bookworm.

In my case haproxy failed to start with my bullseye config since it still had
the "ssl-engine" keyword in it.

Thanks for maintaining haproxy!
- Lee


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

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

Versions of packages haproxy depends on:
ii  adduser3.118
ii  dpkg   1.20.12
ii  init-system-helpers1.60
ii  libc6  2.31-13+deb11u5
ii  libcrypt1  1:4.4.18-4
ii  libgcc-s1  10.2.1-6
ii  liblua5.3-05.3.3-1.1+b1
pn  libopentracing-c-wrapper0  
ii  libpcre2-8-0   10.36-2+deb11u1
ii  libssl1.1  1.1.1n-0+deb11u3
pn  libssl3
ii  libsystemd0247.3-7+deb11u1
ii  lsb-base   11.1.0
ii  zlib1g 1:1.2.11.dfsg-2+deb11u2

haproxy recommends no packages.

Versions of packages haproxy suggests:
pn  haproxy-doc  
pn  vim-haproxy  

Bug#1029803: command-not-found breaks dist-upgrade bullseye → bookworm

[Lee Garrett]

Package: command-not-found
Version: 20.10.1-1
Severity: grave
Tags: patch
X-Debbugs-Cc: deb...@rocketjump.eu, k...@debian.org

Hi Julian,

(this is somewhat related to #968757 and #954249)
(kibi CCed)

Steps to reproduce (on an bullseye installation)
1) Install command-not-found
2) Edit /etc/apt/sources.list to 
deb http://deb.debian.org/debian/ bookworm main contrib non-free 
non-free-firmware
(note the new component non-free-firmware)
3) run `apt update`
# apt update
Hit:1 http://deb.debian.org/debian bullseye InRelease
Hit:2 http://deb.debian.org/debian-security bullseye-security InRelease
Hit:3 http://deb.debian.org/debian bullseye-updates InRelease
Hit:4 http://deb.debian.org/debian bullseye-backports InRelease
Hit:5 https://packages.chef.io/repos/apt/stable bullseye InRelease   
Hit:6 http://deb.debian.org/debian bookworm InRelease
Hit:7 http://deb.debian.org/debian sid InRelease
Hit:8 http://deb.debian.org/debian experimental InRelease
Traceback (most recent call last):
  File "/usr/lib/cnf-update-db", line 26, in 
col.create(db)
  File "/usr/share/command-not-found/CommandNotFound/db/creator.py", line 95, 
in create
self._fill_commands(con)
  File "/usr/share/command-not-found/CommandNotFound/db/creator.py", line 143, 
in _fill_commands
self._parse_single_contents_file(con, f, fp.stdout)
  File "/usr/share/command-not-found/CommandNotFound/db/creator.py", line 282, 
in _parse_single_contents_file
priority = component_priorities[component]
KeyError: 'non-free-firmware'
Reading package lists... Done
E: Problem executing scripts APT::Update::Post-Invoke-Success 'if /usr/bin/test 
-w /var/lib/command-not-found/ -a -e /usr/lib/cnf-update-db; then 
/usr/lib/cnf-update-db > /dev/null; fi'
E: Sub-process returned an error code

This is already fixed in unstable, but in it's current form this will break the
upgrade path from bullseye to bookworm. The fix is trivial, adding
`'non-free-firmware': 60,` to CommandNotFound/db/creator.py is enough. I propose
doing a p-u to fix it.

Greets,
Lee

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

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

Versions of packages command-not-found depends on:
ii  apt-file 3.2.2
ii  lsb-release  11.1.0
ii  python3  3.9.2-3
ii  python3-apt  2.2.1

command-not-found recommends no packages.

Versions of packages command-not-found suggests:
pn  snapd  

-- no debconf information

-- debsums errors found:
debsums: changed file 
/usr/share/command-not-found/CommandNotFound/db/creator.py (from 
command-not-found package)

Bug#1028405: ansible-core: autopkgtest regresses with new python3-defaults (python 3.11)

[Lee Garrett]

IIRC this was added because the last python transition (3.9->3.10) broke 
the autopkgtests, so I've added it. As this seems to work this time 
around, I acknowledge the NMU.


On Tue, 10 Jan 2023 08:21:09 -0800 Steve Langasek 
 wrote:

Package: ansible-core
Version: 2.14.1-1
Severity: serious
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch

Hi Lee,

The ansible-core autopkgtests fail now that /usr/bin/python3 is python 3.11:

[...]
autopkgtest [08:17:06]: test unit: [---
FATAL: Running under Python version 3.11 instead of 3.10.
FATAL: Command "/usr/bin/env 
ANSIBLE_TEST_CONTENT_ROOT=/tmp/autopkgtest-lxc.8ik95lf6/downtmp/build.jHa/src 
PYTHONPATH=/tmp/ansible-test-iin32i73 /usr/bin/python3 /usr/bin/ansible-test units 
--containers '{}' --truncate 0 --color no --host-path test/results/.tmp/host-n2w5rzai 
--metadata test/results/.tmp/metadata-_yj0am3d.json" returned exit status 1.
autopkgtest [08:17:07]: test unit: ---]
[...]

  
(https://ci.debian.net/data/autopkgtest/unstable/amd64/a/ansible-core/29976247/log.gz)

This comes down to a hard-coded "--python 3.11" option in the autopkgtest
which seems superfluous.

I have uploaded the attached patch to Ubuntu to unblock the python3-defaults
transition there.

Cheers,
--
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

Bug#1029137: Use dh sequencer in debian/rules

[Lee Garrett]

Source: rp-pppoe
Severity: normal
Tags: newcomer
X-Debbugs-Cc: deb...@rocketjump.eu

This bug report is tagged "newcomer" as it a good bug where you can learn about
debian/rules and dh.

debian/rules currently uses a rather lengthy hand-written sequencer for
debhelper tools. Current practice is to use a much shorter one as described at 

file:///usr/share/doc/maint-guide/html/dreq.en.html#rules
https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#rules

Where needed, use execute_after_dh_, execute_before_dh_, or
even override_dh_ to recreate the original flow as closely as possible.

In the second step you could then trim away any commands that are there for
historical reasons and not needed.


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

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

Bug#1027133: man page contains non-existant sha3deep

[Lee Garrett]

Package: hashdeep
Version: 4.4-7
Severity: normal
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

the man pages contain a reference to sha3deep:

sha3deep - Compute and compare SHA-3-256 message digests

However, this binary is not installed. Creating a symlink named "sha3deep" to
the binary does not work around the issue:

10:31:05 [root@batou:/usr/local/bin] # ln -s ../../bin/md5deep sha3deep
10:31:09 [root@batou:/usr/local/bin] # ./sha3deep
sha3deep: Unknown algorithm: sha3
Try `sha3deep -h` for more information.

So it seems like the binary doesn't support SHA3-256, and the line should be
removed in the man page.

Greetings,
Lee

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

Kernel: Linux 6.0.2 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages hashdeep depends on:
ii  libc6   2.31-13+deb11u5
ii  libgcc-s1   10.2.1-6
ii  libstdc++6  10.2.1-6

hashdeep recommends no packages.

hashdeep suggests no packages.

-- no debconf information

Bug#1026944: upstream homepage returns 404

[Lee Garrett]

Package: ksmtuned
Version: broken link to upstream homepage
Severity: minor
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

d/control points to https://git.centos.org/summary/rpms!qemu-kvm, which returns
404. I tried finding the new upstream homepage, but a quick google search didn't
find it.

Regards,
Lee

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

Kernel: Linux 6.0.2 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ksmtuned depends on:
ii  libc6  2.31-13+deb11u5

Versions of packages ksmtuned recommends:
ii  qemu-system-x86 [qemu-kvm]  1:5.2+dfsg-11+deb11u2

ksmtuned suggests no packages.

Bug#1025335: ansible-core: autopkgtests need to depend on python3-pytest-forked

[Lee Garrett]

On 06/12/2022 22:54, Scott Talbert wrote:



On December 2, 2022 2:54:19 PM EST, Lee Garrett  wrote:

On 02/12/2022 19:15, Scott Talbert wrote:

Source: ansible-core
Version: 2.14.0-1
Severity: important

ansible-core's autopkgtests need to add a Depends on python3-pytest-forked.

python3-pytest-xdist used to depend on -forked, but it no longer does.

See, for example:
https://ci.debian.net/data/autopkgtest/testing/amd64/a/ansible-core/28872265/log.gz


Thanks! Will update it in the next release.


Also, ansible needs to same update.  If you could make these updates in the 
relatively short term it would be appreciated.  pytest-xdist can't migrate 
otherwise.


And done. Thanks for catching it!



Thanks,
Scott

Bug#1025335: ansible-core: autopkgtests need to depend on python3-pytest-forked

[Lee Garrett]

On 02/12/2022 19:15, Scott Talbert wrote:

Source: ansible-core
Version: 2.14.0-1
Severity: important

ansible-core's autopkgtests need to add a Depends on python3-pytest-forked.

python3-pytest-xdist used to depend on -forked, but it no longer does.

See, for example:
https://ci.debian.net/data/autopkgtest/testing/amd64/a/ansible-core/28872265/log.gz


Thanks! Will update it in the next release.

Bug#1010345: ansible: python3-resolvelib >= 0.6.0 breaks Ansible

[Lee Garrett]

Hi Gregor,

On 29/11/2022 22:19, Gregor Riepl wrote:

Hi Lee,

can you still reproduce this bug? AFAICS this was fixed in the 2.13.3 
upload.


I couldn't find the original requirements.yml that produced the error, 
but I tested a similar file with Ansible 2.13.4, and it worked fine.


That's great news!



Additionally, I'll tighten the package dependencies so this issue will 
be more apparent in the future.


Thanks, I appreciate it! Hopefully there will be a more stable 
resolvelib soon that doesn't cause these problems any more.


By the way, what's the reason for the disparate versioning in Ansible 
and the ansible package? Why is Ansible 2.13.4 packaged as 6.4.0+dfsg-1?


The upstream project has split into the "core" (the binaries basically, 
which was called "base" for one release cycle), and the community 
modules (now just called "ansible").


Also check /usr/share/doc/ansible/NEWS.Debian.gz for details. :)


Regards,
Gregor


Regards,
Lee

Bug#868261: ansible: hostname module fails with "Failed to create bus connection: Connection refused" if dbus is not installed on remote machine

[Lee Garrett]

Hi Axel,

does this issue still persist for you? Looking up the code it seems as 
though there's now a heuristic in place that should fall back to other 
methods if dbus is unavailable.


Greets,
Lee

On Thu, 13 Jul 2017 23:00:34 +0200 Axel Beckert  wrote:

Package: ansible
Version: 2.2.1.0-2
Control: forwarded -1 https://github.com/ansible/ansible/issues/25543

Dear Maintainer,

the following trivial task fails if dbus is not installed on a remote
machine (e.g. a server):

- name: Set the hostname
  hostname:
name: "{{ ansible_host }}"

It fails as follows despite dbus is (obviously) not necessary to set the
hostname under Linux:

fatal: […]: FAILED! => {"changed": false, "failed": true, "msg": "Command failed 
rc=1, out=, err=Failed to create bus connection: Connection refused\n"}

If dbus is installed on the remote machine, the module works
fine. According to the upstream bug report at
https://github.com/ansible/ansible/issues/25543 this only happens with
systemd as init system (or at least if systemd is installed and dbus is
not).

-- System Information:
Debian Release: 9.0
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages ansible depends on:
ii  python2.7.13-2
ii  python-crypto 2.6.1-7
ii  python-httplib2   0.9.2+dfsg-1
ii  python-jinja2 2.8-1
ii  python-netaddr0.7.18-2
ii  python-paramiko   2.0.0-1
ii  python-pkg-resources  33.1.1-1
ii  python-yaml   3.12-1

Versions of packages ansible recommends:
ii  python-kerberos   1.1.5-2+b2
ii  python-selinux2.6-3+b1
pn  python-winrm  
ii  python-xmltodict  0.10.2-1

Versions of packages ansible suggests:
ii  cowsay   3.03+dfsg2-3
ii  sshpass  1.06-1

-- no debconf information

Bug#1024713: ansible-core: Fails autopkgtests in unstable due to new resolvelib

[Lee Garrett]

Hi Scott,

I got around to fix the issue. I took the upstream patch as yours didn't 
apply cleanly to 2.14 anymore. I will upload the package in the next hour.


Thanks for bringing this to my attention!

Regards,
Lee

On 23/11/2022 17:17, Scott Kitterman wrote:

Package: ansible-core
Version: 2.13.4-1
Severity: serious
Tags: patch upstream ftbfs
Justification: fails to build from source (but built successfully in the past)

The current ansible-core package fails autopkgtest in unstable and would
fail in testing if python3-resolvelib were to migrate [1].  The issue
has been fixed upstream [2].  I have tested both on unstable and testing
with the upstream fix using the attached debdiff and it corrects the
test failures.  It also still works with the older resolvelib.

Using the ftbfs tag for this report since it is the closest thing we
have for test failures.

I do intend to NMU in a week to fix this as it blocks testing migration
for python-resolvelib.  Please let me know if you want to take care of
it or your would prefer I go ahead.

Scott K


[1] 
https://ci.debian.net/data/autopkgtest/testing/amd64/a/ansible-core/28587311/log.gz
[2] https://github.com/ansible/ansible/pull/79399/files

Bug#1025041: changing patch level on `quilt import -f` doesn't change the patch level

[Lee Garrett]

Package: quilt
Version: 0.66-2.1
Severity: normal
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

when importing a patch with

$ quilt import -P 0009-resolvelib_0_9_0_compat.patch ../../tmp.patch -f -d n

and noticing that the patch level is wrong, the most intuitive next step is to
overwrite the patch with the correct patch level:

$ quilt import -p 0 -P 0009-resolvelib_0_9_0_compat.patch ../../tmp.patch -f -d 
n

However, subsequent import/overwrites will not update the patch level in
debian/patches/series. It would be great if quilt would in the above case also
add "-p0" to the line.

Regards,
Lee

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

Kernel: Linux 6.0.2 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages quilt depends on:
ii  bsdextrautils   2.36.1-8+deb11u1
ii  bsdmainutils12.1.7+nmu3
ii  bzip2   1.0.8-4
ii  diffstat1.64-1
ii  ed  1.17-1
ii  gettext 0.21-4
ii  patch   2.7.6-7
ii  perl5.32.1-4+deb11u2
ii  sensible-utils  0.0.14

Versions of packages quilt recommends:
ii  less  551-2

Versions of packages quilt suggests:
pn  default-mta | mail-transport-agent  
ii  graphviz2.42.2-5
pn  procmail

-- no debconf information

Bug#1010345: ansible: python3-resolvelib >= 0.6.0 breaks Ansible

[Lee Garrett]

Hi Gregor,

can you still reproduce this bug? AFAICS this was fixed in the 2.13.3 
upload.


Additionally, I'll tighten the package dependencies so this issue will 
be more apparent in the future.


Greetings,
Lee

On 29/04/2022 12:01, Gregor Riepl wrote:

Package: ansible
Version: 5.5.0-1
Severity: important
X-Debbugs-Cc: onit...@gmail.com

Dear Maintainer,

Ansible has a strict dependency on resolvelib >=0.5.3 && <0.6.0, which is
documented in the upstream requirements.txt:
https://github.com/ansible/ansible/blob/devel/requirements.txt

Debian bullseye/sid installs 0.8.1, which breaks some functionality in Ansible.

In particular, downloading collections with ansible-galaxy is no longer
possible:

$ ansible-galaxy install -r requirements.yml -vvv
...
Process install dependency map
ERROR! Unexpected Exception, this is probably a bug:
CollectionDependencyProvider.find_matches() got an unexpected keyword argument
'identifier'
the full traceback was:

Traceback (most recent call last):
   File "/usr/bin/ansible-galaxy", line 128, in 
 exit_code = cli.run()
   File "/usr/lib/python3/dist-packages/ansible/cli/galaxy.py", line 569, in run
 return context.CLIARGS['func']()
   File "/usr/lib/python3/dist-packages/ansible/cli/galaxy.py", line 86, in
method_wrapper
 return wrapped_method(*args, **kwargs)
   File "/usr/lib/python3/dist-packages/ansible/cli/galaxy.py", line 1203, in
execute_install
 self._execute_install_collection(
   File "/usr/lib/python3/dist-packages/ansible/cli/galaxy.py", line 1230, in
_execute_install_collection
 install_collections(
   File "/usr/lib/python3/dist-packages/ansible/galaxy/collection/__init__.py",
line 548, in install_collections
 dependency_map = _resolve_depenency_map(
   File "/usr/lib/python3/dist-packages/ansible/galaxy/collection/__init__.py",
line 1364, in _resolve_depenency_map
 return collection_dep_resolver.resolve(
   File "/usr/lib/python3/dist-packages/resolvelib/resolvers.py", line 481, in
resolve
 state = resolution.resolve(requirements, max_rounds=max_rounds)
   File "/usr/lib/python3/dist-packages/resolvelib/resolvers.py", line 348, in
resolve
 self._add_to_criteria(self.state.criteria, r, parent=None)
   File "/usr/lib/python3/dist-packages/resolvelib/resolvers.py", line 147, in
_add_to_criteria
 matches = self._p.find_matches(
TypeError: CollectionDependencyProvider.find_matches() got an unexpected
keyword argument 'identifier'


Related issue: https://bugs.gentoo.org/795933

I'm not aware of a proper patch for this issue.
Gentoo has fixed it by pinning the resolvelib dependency to the requested
version range.


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

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

Versions of packages ansible depends on:
ii  ansible-core   2.12.4-1
ii  openssh-client 1:9.0p1-1
ii  python33.10.4-1
ii  python3-distutils  3.9.12-1
ii  python3-dnspython  2.2.0-2
ii  python3-httplib2   0.20.2-2
ii  python3-jinja2 3.0.3-1
ii  python3-netaddr0.8.0-2
ii  python3-yaml   5.4.1-1+b1

Versions of packages ansible recommends:
ii  python3-argcomplete   1.12.3-0.1
ii  python3-cryptography  3.4.8-1
ii  python3-jmespath  1.0.0-1
ii  python3-kerberos  1.1.14-3.1+b4
ii  python3-libcloud  3.4.1-2
ii  python3-selinux   3.3-1+b2
ii  python3-winrm 0.3.0-2
ii  python3-xmltodict 0.12.0-2

Versions of packages ansible suggests:
pn  cowsay   
ii  sshpass  1.09-1+b1

-- no debconf information

Bug#998468: libvirt0: qemu KVM: USB Passthrough partially stopped working in Bullseye

[Lee Garrett]

I have not found a solution to this issue.

However there is a workaround that involves passing the serial device to 
the guest VM instead of the USB device:


https://community.home-assistant.io/t/cannot-passthrough-conbee-ii-with-kvm-host-debian-guest-haos/465496/5

In this specific case I was able to use the zigbee controller with HA.

The underlying problem (passthrough not working properly) however still 
remains.


Greets,
Lee

Bug#998468: libvirt0: qemu KVM: USB Passthrough partially stopped working in Bullseye

[Lee Garrett]

I also have a Debian bullseye laptop running as a qemu/libvirt host, 
running the home assistant guest VM, where I passed through the Conbee 
II usb adapter. Is there a solution to this yet?

Bug#1024713: ansible-core: Fails autopkgtests in unstable due to new resolvelib

[Lee Garrett]

Hi Scott,

thanks for the bug report. A NMU is not needed, I'm currently preparing 
the newest upstream release and hopefully will upload it in the next 
days. If I don't upload within 7 days, feel free to NMU it.


Regards,
Lee


On 23/11/2022 17:17, Scott Kitterman wrote:

Package: ansible-core
Version: 2.13.4-1
Severity: serious
Tags: patch upstream ftbfs
Justification: fails to build from source (but built successfully in the past)

The current ansible-core package fails autopkgtest in unstable and would
fail in testing if python3-resolvelib were to migrate [1].  The issue
has been fixed upstream [2].  I have tested both on unstable and testing
with the upstream fix using the attached debdiff and it corrects the
test failures.  It also still works with the older resolvelib.

Using the ftbfs tag for this report since it is the closest thing we
have for test failures.

I do intend to NMU in a week to fix this as it blocks testing migration
for python-resolvelib.  Please let me know if you want to take care of
it or your would prefer I go ahead.

Scott K


[1] 
https://ci.debian.net/data/autopkgtest/testing/amd64/a/ansible-core/28587311/log.gz
[2] https://github.com/ansible/ansible/pull/79399/files

Bug#1019899: trivially to trigger traceback

[Lee Garrett]

Package: lookatme
Version: 2.3.0-1
Severity: important
X-Debbugs-Cc: deb...@rocketjump.eu

Hi, it's trivally to trigger a traceback with lookatme:

---
$ lookatme README.md 
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/lookatme/__main__.py", line 139, in main
pres.run()
  File "/usr/lib/python3/dist-packages/lookatme/pres.py", line 141, in run
self.tui = lookatme.tui.create_tui(self, start_slide=start_slide)
  File "/usr/lib/python3/dist-packages/lookatme/tui.py", line 364, in create_tui
tui = MarkdownTui(pres, start_slide)
  File "/usr/lib/python3/dist-packages/lookatme/tui.py", line 222, in __init__
self.prep_pres(self.pres, start_idx)
  File "/usr/lib/python3/dist-packages/lookatme/tui.py", line 235, in prep_pres
self.update()
  File "/usr/lib/python3/dist-packages/lookatme/tui.py", line 307, in update
self.update_body()
  File "/usr/lib/python3/dist-packages/lookatme/tui.py", line 277, in 
update_body
rendered = self.slide_renderer.render_slide(self.curr_slide)
  File "/usr/lib/python3/dist-packages/lookatme/tui.py", line 75, in 
render_slide
raise res
  File "/usr/lib/python3/dist-packages/lookatme/tui.py", line 105, in run
res = self.do_render(to_render, slide_num)
  File "/usr/lib/python3/dist-packages/lookatme/tui.py", line 157, in do_render
self._render_tokens(tokens)
  File "/usr/lib/python3/dist-packages/lookatme/tui.py", line 175, in 
_render_tokens
render_token = getattr(lam_md, f"render_{token['type']}")
AttributeError: module 'lookatme.render.markdown_block' has no attribute 
'render_close_html'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/lookatme", line 33, in 
sys.exit(load_entry_point('lookatme==2.3.0', 'console_scripts', 
'lookatme')())
  File "/usr/lib/python3/dist-packages/click/core.py", line 829, in __call__
return self.main(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 782, in main
rv = self.invoke(ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1066, in invoke
return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3/dist-packages/click/core.py", line 610, in invoke
return callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/lookatme/__main__.py", line 141, in main
number = pres.tui.curr_slide.number + 1
AttributeError: 'NoneType' object has no attribute 'curr_slide'
---

it would be great to have it instead give some helpful output if it's not happy
with the markdown file.

Greetings,
Lee


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

Kernel: Linux 5.18.0-0.deb11.4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lookatme depends on:
ii  libjs-sphinxdoc  3.4.3-2
ii  python3  3.9.2-3
ii  python3-click7.1.2-1
ii  python3-marshmallow  3.10.0-1
ii  python3-mistune  0.8.4-4
ii  python3-pygments 2.7.1+dfsg-2.1
ii  python3-urwid2.1.2-1
ii  python3-yaml 5.3.1-5

lookatme recommends no packages.

lookatme suggests no packages.

-- no debconf information

Bug#975507: ansible/buster-backports incompatible with systemd/buster-backups (https://github.com/ansible/ansible/pull/68211)

[Lee Garrett]

Hi,

does this issue still affect bullseye(-backports)? AFAICS this was merged.

Greets,
Lee

On 23/11/2020 05:47, Trent W. Buck wrote:
> Package: ansible
> Version: 2.9.6+dfsg-1~bpo10+1
> Severity: minor
> 
> Is it possible to get https://github.com/ansible/ansible/pull/68211 fixed in 
> ansible/buster-backports?
> 
> I ran into this today:
> 
> FAILED! => {"changed": false,
> "msg": "Malformed output discovered from systemd 
> list-unit-files: alsa-restore.servicestatic  
> enabled  "}
> 
> AFAICT this is the problem change (from systemd NEWS):
> 
> CHANGES WITH 245:
> 
> * "systemctl list-unit-files" has been updated to show a new column
>   with the suggested enablement state based on the vendor preset files
>   for the respective units.
> 
> You can see the difference between buster-backports and buster:
> 
> bash5$ systemctl --version
> systemd 245 (245.7-1~bpo10+1)
> +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
> +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN 
> +PCRE2 default-hierarchy=hybrid
> bash5$ list-unit-files --no-pager --type service --all | head -2
> UNIT FILE   STATE   VENDOR PRESET
> alsa-restore.servicestatic  enabled
> 
> bash5$ systemctl --version
> systemd 241 (241)
> +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
> +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN 
> -PCRE2 default-hierarchy=hybrid
> bash5$ systemctl list-unit-files --no-pager --type service --all | head -2
> UNIT FILE  STATE
> accounts-daemon.serviceenabled
> 
> The code that needs to change is here:
> 
> 
> https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/service_facts.py#L221
> 
> https://github.com/ansible/ansible/pull/68211
> 
> 
> 
> 
> 
> 
> -- System Information:
> Debian Release: 10.6
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 
> 'proposed-updates')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.6.0-0.bpo.2-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), 
> LANGUAGE=en_AU:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages ansible depends on:
> ii  openssh-client1:7.9p1-10+deb10u2
> ii  python3   3.7.3-1
> ii  python3-crypto2.6.1-9+b1
> ii  python3-cryptography  2.6.1-3+deb10u2
> ii  python3-distutils 3.7.3-1
> ii  python3-dnspython 1.16.0-1
> ii  python3-httplib2  0.11.3-2
> ii  python3-jinja22.10-2
> ii  python3-netaddr   0.7.19-1
> ii  python3-paramiko  2.6.0-1~bpo10+1
> ii  python3-yaml  3.13-2
> 
> Versions of packages ansible recommends:
> ii  python3-argcomplete  1.8.1-1
> ii  python3-jmespath 0.10.0-1
> ii  python3-kerberos 1.1.14-2
> ii  python3-libcloud 2.4.0-1
> ii  python3-selinux  2.8-1+b1
> ii  python3-winrm0.3.0-2
> ii  python3-xmltodict0.11.0-2
> 
> Versions of packages ansible suggests:
> pn  cowsay   
> pn  sshpass  
> 
> -- debconf-show failed
> 

Bug#950898: ansible/buster: flatpak_remote: IndexError: list index out of range

[Lee Garrett]

AFAICS this error doesn't happen in bullseye anymore, as this patch was
merged there. So I'm closing this issue.

On 07/02/2020 23:13, Hector Oron Martinez wrote:
> Package: ansible
> Version: 2.7.7+dfsg-1
> Severity: important
> Tags: patch
> 
> Hello,
> 
> Note this issue only happens in stable, Buster 10.2 with ansible 2.7.7
> 
> When using ansible with flatpak_remote, it breaks. The following snippet:
> ```
> - name: Add the flathub flatpak repository remote to the user 
> installation
>   flatpak_remote:
> name: flathub
> state: present
> flatpakrepo_url: https://dl.flathub.org/repo/flathub.flatpakrepo
> method: user
> ```
> 
> causes:
> 
> ```
> TASK [Add the flathub flatpak repository remote to the user installation] 
> *
> fatal: [127.0.0.1]: FAILED! => {"changed": false, "module_stderr": 
> "/home/zumbi/.ansible/tmp/ansible-tmp-1581109559.271161-112064566806002/AnsiballZ_flatpak_remote.py:17:
>  DeprecationWarning: the imp module is deprecated in favour of importlib; see 
> the module's documentation for alternative uses\n  import imp\nTraceback 
> (most recent call last):\n  File 
> \"/home/zumbi/.ansible/tmp/ansible-tmp-1581109559.271161-112064566806002/AnsiballZ_flatpak_remote.py\",
>  line 113, in \n_ansiballz_main()\n  File 
> \"/home/zumbi/.ansible/tmp/ansible-tmp-1581109559.271161-112064566806002/AnsiballZ_flatpak_remote.py\",
>  line 105, in _ansiballz_main\ninvoke_module(zipped_mod, temp_path, 
> ANSIBALLZ_PARAMS)\n  File 
> \"/home/zumbi/.ansible/tmp/ansible-tmp-1581109559.271161-112064566806002/AnsiballZ_flatpak_remote.py\",
>  line 48, in invoke_module\nimp.load_module('__main__', mod, module, 
> MOD_DESC)\n  File \"/usr/lib/python3.7/imp.py\", line 234, in load_module\n   
>  return load_source(name, filename, file)\n  File 
> \"/usr/lib/python3.7/imp.py\", line 169, in load_source\nmodule = 
> _exec(spec, sys.modules[name])\n  File \"\", 
> line 630, in _exec\n  File \"\", line 
> 728, in exec_module\n  File \"\", line 219, in 
> _call_with_frames_removed\n  File 
> \"/tmp/ansible_flatpak_remote_payload_3i68y3ku/__main__.py\", line 241, in 
> \n  File 
> \"/tmp/ansible_flatpak_remote_payload_3i68y3ku/__main__.py\", line 230, in 
> main\n  File \"/tmp/ansible_flatpak_remote_payload_3i68y3ku/__main__.py\", 
> line 172, in remote_exists\nIndexError: list index out of range\n", 
> "module_stdout": "", "msg": "MODULE FAILURE\nSee stdout/stderr for the exact 
> error", "rc": 1}
>   to retry, use: --limit 
> @/home/zumbi/SCM/GITAuth/local/ansible/playbook.retry
> ```
> 
> The issue has been reported upstream at:
> https://github.com/ansible/ansible/issues/51481
> 
> And a pull request has been merged:
> https://github.com/ansible/ansible/pull/54103
> 
> I am attaching a debdiff I have tested and fixes the issue above.
> Please, consider fixing this issue in Buster, via stable-updates. If you
> need help, please let me know, I am willing to proceed with the upload
> if you wish.
> 
> Regards
> 
> -- System Information:
> Debian Release: 10.2
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
> Kernel taint flags: TAINT_USER
> Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8), 
> LANGUAGE=ca_ES:ca (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages ansible depends on:
> ii  python33.7.3-1
> ii  python3-crypto 2.6.1-9+b1
> ii  python3-cryptography   2.6.1-3+deb10u2
> ii  python3-httplib2   0.11.3-2
> ii  python3-jinja2 2.10-2
> ii  python3-netaddr0.7.19-1
> ii  python3-paramiko   2.4.2-0.1
> ii  python3-pkg-resources  40.8.0-1
> ii  python3-yaml   3.13-2
> 
> Versions of packages ansible recommends:
> ii  python3-jmespath   0.9.4-1
> ii  python3-kerberos   1.1.14-2
> ii  python3-libcloud   2.4.0-1
> ii  python3-selinux2.8-1+b1
> ii  python3-winrm  0.3.0-2
> ii  python3-xmltodict  0.11.0-2
> 
> Versions of packages ansible suggests:
> pn  cowsay   
> pn  sshpass  
> 
> -- no debconf information

Bug#1018955: ITP: ktx -- QuakeWorld mod "Kombat Teams eXtreme"

[Lee Garrett]

Package: wnpp
Severity: wishlist
Owner: Lee Garrett 
X-Debbugs-Cc: debian-de...@lists.debian.org, deb...@rocketjump.eu

* Package name: ktx
  Version : 1.40
  Upstream Author : QW Group
* URL : https://github.com/QW-Group/ktx
* License : GPLv2+
  Programming Lang: C
  Description : QuakeWorld mod "Kombat Teams eXtreme"

KTX (Kombat Teams eXtreme) is a popular QuakeWorld server modification, adding
numerous features to the core features of the server.

Although it had been developed to be Quakeworld server agnostic, it has over
the years been developed very close to MVDSV to which it has become an extent,
thus compatibility with other Quakeworld servers might not have been
maintained.

This package is an addition to mvdsv (#862954). Upstream has a slow turnover of
=< 2 releases per year. I intend to team maintain it in the games team. (no need
to sponsor, I'm a DD)

Bug#961119: ansible: Ansible fails to work on a minimal system (missing python 2 dependency)

[Lee Garrett]

Hi Elena,

current version (2.12.4) should be smarter at detecting the OS release
and picking the right python version:

https://docs.ansible.com/ansible/latest/reference_appendices/interpreter_discovery.html

As such, I'm closing this bug.

Regards,
Lee


On 20/05/2020 12:46, Elena ``of Valhalla'' wrote:
> Package: ansible
> Version: 2.7.7+dfsg-1
> Severity: important
> 
> Dear Maintainer,
> 
> on a minimal stable (buster) installation, ansible fails to run (at
> least on the machine itself) because of a lack of the python (2)
> interpreter.
> 
> To reproduce, debootstrap an image (but installing from netinst without
> adding things with tasksel also works):
> 
> # mkdir buster
> # debootstrap buster buster/
> # mount -t devtmpfs udev buster/dev/
> # chroot buster
> 
> # ansible -i localhost, -m setup -c local all
> 
> localhost | FAILED! => {
> "changed": false,
> "module_stderr": "/bin/sh: 1: /usr/bin/python: not found\n",
> "module_stdout": "",
> "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error",
> "rc": 127
> }
> 
> Installing python (2) of course fixes the issue.
> 
> I've noticed that it seems to be hardcoded as such in quite a few
> modules:
> 
> # grep -r '/usr/bin/python$' /usr/lib/python3/dist-packages/ansible | wc 
> -l
> 2083
> 
> but I've also checked that in sid the original command is working, while
> those files still have an hardcoded python2 executable, so I'm not sure
> what is going on there.
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable'), (1, 
> 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.6.0-1-amd64 (SMP w/2 CPU cores)
> Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
> Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_IE:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages ansible depends on:
> ii  openssh-client1:8.2p1-4
> ii  python3   3.8.2-3
> ii  python3-crypto2.6.1-13.1+b1
> ii  python3-cryptography  2.8-4
> ii  python3-distutils 3.8.2-2
> ii  python3-dnspython 1.16.0-2
> ii  python3-httplib2  0.14.0-3
> ii  python3-jinja22.10.1-2
> ii  python3-netaddr   0.7.19-4
> ii  python3-paramiko  2.6.0-2
> ii  python3-yaml  5.3.1-1+b1
> 
> Versions of packages ansible recommends:
> ii  python3-argcomplete  1.8.1-1.3
> ii  python3-jmespath 0.9.5-1
> ii  python3-kerberos 1.1.14-3.1+b1
> ii  python3-libcloud 2.8.0-1
> ii  python3-selinux  3.0-1+b3
> ii  python3-winrm0.3.0-2
> ii  python3-xmltodict0.12.0-2
> 
> Versions of packages ansible suggests:
> ii  cowsay   3.03+dfsg2-7
> ii  sshpass  1.06-1+b1
> 
> -- no debconf information
> 

Bug#1000885: ansible: version in experimental is uninstallable

[Lee Garrett]

IIRC this was a transient python bug in unstable. As I'm not able to
reproduce this problem, and the version in experimental was also
removed, I'm closing this bug.


On 30/11/2021 18:33, Marc Dequènes (duck) wrote:
> Package: ansible
> Version: 4.6.0-1
> Severity: important
> 
> Quack,
> 
> Despite the fix in #995879 it is not installable:
> # apt install -t experimental ansible
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> The following additional packages will be installed:
>   ansible-core python3-resolvelib
> Suggested packages:
>   cowsay sshpass
> Recommended packages:
>   python3-kerberos python3-libcloud python3-winrm python3-xmltodict
> The following NEW packages will be installed:
>   ansible-core python3-resolvelib
> The following packages will be upgraded:
>   ansible
> 1 upgraded, 2 newly installed, 0 to remove and 177 not upgraded.
> Need to get 20.8 MB of archives.
> After this operation, 67.6 MB of additional disk space will be used.
> Do you want to continue? [Y/n]
> Get:1 http://HTTPS///deb.debian.org/debian unstable/main amd64
> python3-resolvelib all 0.8.1-1 [25.4 kB]
> Get:2 http://HTTPS///deb.debian.org/debian experimental/main amd64
> ansible all 4.6.0-1 [19.6 MB]
> Get:3 http://HTTPS///deb.debian.org/debian unstable/main amd64
> ansible-core all 2.12.0-1 [1153 kB]
> Fetched 20.8 MB in 5s (4339 kB/s)
> Retrieving bug reports... Done
> Parsing Found/Fixed information... Done
> Reading changelogs... Done
> apt-listchanges: Mailing root: apt-listchanges: news for Annael
> Selecting previously unselected package python3-resolvelib.
> (Reading database ... 553625 files and directories currently installed.)
> Preparing to unpack .../python3-resolvelib_0.8.1-1_all.deb ...
> Unpacking python3-resolvelib (0.8.1-1) ...
> Preparing to unpack .../ansible_4.6.0-1_all.deb ...
> Unpacking ansible (4.6.0-1) over (2.10.7+merged+base+2.10.8+dfsg-1) ...
> Selecting previously unselected package ansible-core.
> Preparing to unpack .../ansible-core_2.12.0-1_all.deb ...
> Unpacking ansible-core (2.12.0-1) ...
> Setting up python3-resolvelib (0.8.1-1) ...
> Setting up ansible-core (2.12.0-1) ...
> [Errno 2] No such file or directory:
> '/usr/lib/python3.10/dist-packages/ansible/module_utils/ansible_release.py'dpkg:
> error processing package ansible-core (--configure):
>  installed ansible-core package post-installation script subprocess
> returned error exit status 1
> dpkg: dependency problems prevent configuration of ansible:
>  ansible depends on ansible-core (>= 2.11.5-1~); however:
>   Package ansible-core is not configured yet.
> 
> dpkg: error processing package ansible (--configure):
>  dependency problems - leaving unconfigured
> Processing triggers for man-db (2.9.4-2) ...
> Errors were encountered while processing:
>  ansible-core
>  ansible
> needrestart is being skipped since dpkg has failed
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> $ ls -l
> /usr/lib/python3.10/dist-packages/ansible/module_utils/ansible_release.py
> lrwxrwxrwx 1 root root 13 Nov 18 21:42
> /usr/lib/python3.10/dist-packages/ansible/module_utils/ansible_release.py ->
> ../release.py
> 
> But this file does not exist.
> 
> I purged ansible and ansible-core, reinstalled and obtained the same
> result. In fact upgrading or installing after purge does not change
> anything.
> 
> It seems this symlink is not owned by any package, is it generated???
> 
> I did not have time to dig deeper, hope that helps.
> And thank for the hard work, the split seems to be a real pain in the
> ass to handle.
> 
> Regards.
> \_o<
> 

Bug#1017980: zcfan should "Conflicts: thinkfan"

[Lee Garrett]

Package: zcfan
Severity: normal
X-Debbugs-Cc: deb...@rocketjump.eu

Hi Michel,

thank you for packaging zcfan! I think it should have "Conflicts: thinkfan" set
in the package meta-data, as both installed on the same machine likely will
produce unpredictable behaviour.

By the way, it looks like you're using git-buildpackage. Can you push the
pristine-tar and upstream branches? That would make it easier for me to build
and verify the package, and provide a patch.

Greetings,
Lee

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

Kernel: Linux 5.18.0-0.bpo.1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages zcfan depends on:
ii  libc6  2.31-13+deb11u3

zcfan recommends no packages.

zcfan suggests no packages.

Bug#947325: snapd: strict confinement is not enabled

[Lee Garrett]

Hi,

can can verify on bullseye that this particular test case is not present
anymore:

---8<--8<--8<--8<--8<--8<--8<--8<---
$ snap run hello-world.evil

Hello Evil World!

This example demonstrates the app confinement

You should see a permission denied error next

/snap/hello-world/29/bin/evil: 9: /snap/hello-world/29/bin/evil: cannot
create /var/tmp/myevil.txt: Permission denied


$ snap debug confinement

partial


$ snap debug sandbox-features

apparmor: kernel:caps kernel:domain kernel:file kernel:mount
kernel:namespaces kernel:network_v8 kernel:policy kernel:ptrace
kernel:query kernel:rlimit kernel:signal parser:cap-audit-read
parser:cap-bpf parser:qipcrtr-socket parser:unsafe policy:default
support-level:partial

confinement-options:  classic devmode

dbus: mediated-bus-access

kmod: mediated-modprobe

mount:layouts mount-namespace per-snap-persistency
per-snap-profiles per-snap-updates per-snap-user-profiles
stale-base-invalidation

seccomp:  bpf-actlog bpf-argument-filtering kernel:allow
kernel:errno kernel:kill_process kernel:kill_thread kernel:log
kernel:trace kernel:trap kernel:user_notif

udev: tagging


---8<--8<--8<--8<--8<--8<--8<--8<---

However, I do agree with the assessment of Mattia that this should be
treated as a security issue. Users expect from snap (just like from
flatpak) that there is a process confinement in place that limits the
exposure of the filesystem access and APIs to running snaps. That is a
central design feature, and according to the principle of least
astonishment I'd expect snap in Debian to behave the same, or at least
very prominently warn about it.

Greetings,
Lee

Bug#792169: thinkfan: Fails to set fan speed and exits when started at high temperature

[Lee Garrett]

Hi Matthijs!

Does this bug still affect you? There have been a lot of changes since
your bug report (switch from C to C++ amongst others). I was not able to
reproduce the error, however I don't have the exact same hardware.

Greetings,
Lee


On Sun, 12 Jul 2015 13:16:36 +0200 Matthijs Kooijman 
wrote:
> Package: thinkfan
> Version: 0.9.2-1
> Severity: important
> Tags: patch
> 
> Hi,
> 
> while modifying my configuration to be a bit more aggressive on high
> temperatures, I found that thinkfan exited without changing the fan
> level. When started with -n, it wrote:
> 
>   setfan_ibm: Error writing to /proc/acpi/ibm/fan: Invalid argument
>   Cleaning up and resetting fan control.
> 
> I've marked this bug as important, since it causes the fan to revert to
> automatic hardware / BIOS control when the temperature is high, which is
> likely when you need the extra fanspeed from thinkfan the most. Feel
> free to downgrade if you feel this is less of an issue then I think :-)
> 
> Adding a bit of debug information shows that it tried to write the
> empty string, instead of a proper fan level. It turns out that, at the
> top of the fancontrol() function, lvl_idx is initialized at the maximum
> level, but the cur_lvl variable is not changed.
> 
> Normally, this is not a problem since based on the temperature, the
> index is stepped down to the appropriate level and cur_lvl is updated.
> However, if the highest level turns out to be appropriate, thinkfan
> continues to write the fan level, without updating cur_lvl.
> 
> The fix is simple: Just run the set_fan macro to set cur_lvl too. This
> also means that the level is immediately made effective, which prevents
> having to wait for the watchdog timeout if the highest fanlevel is
> appropriate (which would be the effect of just setting cur_lvl instead
> of calling set_fan).
> 
> --- thinkfan.c.orig 2015-07-12 13:09:28.259263201 +0200
> +++ thinkfan.c  2015-07-12 13:09:43.231401029 +0200
> @@ -111,6 +111,7 @@
>  
> // Set initial fan level...
> lvl_idx = config->num_limits - 1;
> +   set_fan;
>  
> for (i=0; i < num_temps; i++)
> if (temps[i] > tmax) tmax = temps[i];
> 
> 
> Gr.
> 
> Matthijs
> 
> -- System Information:
> Debian Release: 8.0
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'oldoldstable'), (500, 'unstable'), 
> (500, 'testing'), (500, 'oldstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.0.2+ (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Bug#1007907: ansible-core: cannot install collecions

[Lee Garrett]

Hi,

I can confirm the issue exists, unfortunately there is no simple
solution, as upstream resolvlib does not have a stable API yet. I might
be able to downgrade resolvelib in testing/unstable, as ansible-core
seems to be the only package that currently consumes it. This will
probably get better in the near future when 1.0 is released.

Regards,
Lee

On 23/03/2022 02:31, Daniele Tricoli wrote:
> On Fri, 18 Mar 2022 13:03:13 +0100 Bernhard Bock  wrote:
>> I tried to install a collection and ran into a python stacktrace as included 
>> below.
>> According to my understanding, the Debian version of python3-resolvelib is 
>> too new.
>>
>> For reference, see also 
>> https://github.com/ansible-collections/community.digitalocean/issues/132
>> and https://bugs.gentoo.org/795933
> 
> I can confirm that the workaround of downgrading python3-resolvelib to 0.5.4-1
> solve the issue.
> 

Bug#716386: [Mayhem] Bug report on tetradraw: tetraview crashes with exit status 139

[Lee Garrett]

Package: tetradraw
Version: 2.0.3-9+b2
Followup-For: Bug #716386
X-Debbugs-Cc: deb...@rocketjump.eu

Hi Rhonda,

sorry to grave dig this bug report, but it seems that tetradraw might be broken
for a couple of releases now. On bullseye it segfaults with rc 139. A few people
in #debian reported the same issue, so it looks like it's 100% reproducible.
Since I'd love to make some nice ascii art for my /etc/motd, it would be nice if
you could find the time to fix it. Thanks in advance!

Kind regards,
Lee


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

Kernel: Linux 5.16.1 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tetradraw depends on:
ii  libc6 2.31-13+deb11u2
ii  libncursesw6  6.2+20201114-2
ii  libtinfo6 6.2+20201114-2

tetradraw recommends no packages.

tetradraw suggests no packages.

-- no debconf information