Bug#1009309: udhcpc: allow usage without busybox

[Michael Tokarev]

13.04.2022 09:31, Helmut Grohne wrote:

Control: tags -1 + moreinfo

On Wed, Apr 13, 2022 at 09:13:58AM +0300, Michael Tokarev wrote:

No, as far as I understand. B/c udhcpc package lacks the main binary
if there's no busybox... ;)

Can you explain please? :)


Head -> table. I now understand why udhcpc is so small. Thank you for
your kind reply. There is nothing to change here. I'll look into the
reverse (and usual) solution to space saving: replace everything else
with busybox.


That was good Helmut!  Thank you!


On a related note, I have been wondering whether we could somehow put
the integration of busybox on more solid footing. A possible route could
be adding tiny symlink packages e.g. iproute2-minimal containing ip,
kmod-minimal containing lsmod and friends or procps-minimal containing
top et al. These would have to conflict with iproute2, kmod and procps
respectively as they're sharing paths. To make that actually useful,
downstream packages could update their depends to foo | foo-minimal when
they are known to work with busybox. If toybox wants to join, -minimal
would refer to the minimal baselines provided by both busybox and
toybox. It's a lot of small packages and metadata though. I'm not
convinced yet and merely sharing thoughts. Properly minimizing Debian
chroots with busybox is not a "it just works" experience yet.


I thought about this back when I stepped on as busybox maintainer a few
years back.  Busybox isn't really suitable as a full-blown implementation
for many system utilities. For one, quite some things on the system will
break when you replace something with busybox, due to maintscripts, or
startup scripts, whatever, usage of options/features/lack-of-bugs of the
busybox's large brothers. Eg, file^Wcoreutils or [mg]awk provides much
more features than busybox counterparts, and these features are being
used in debian.  This isn't difficult to fix in most places but you
know the drill with cross-compile, how slow this process is :)

But busybox is basically not maintained in Debian. I tried to at least
reduce the number of active bug reports (there were many of them),
updated version to current one (previous update was a few versions
behind), tried to sync different configuration with each other and
with reality.. until something happened a few debian releases ago
and I was pissed off and stepped down.  I don't even remember what
happened, just a vague memory of someone uploading busybox backing
up changes I did and refusing my changes to go, or some such..  So
after that, busybox basically froze again.  I still maintain it
locally for our needs just like I did before, but I don't do that
in Debian anymore.  Maybe I should try again...

/mjt

Bug#989959: unbound: Corrupt/empty trust anchor file is not healed upon start

[Michael Tokarev]

On Wed, 16 Jun 2021 18:57:26 +0200 Dennis Filder  wrote:

Package: unbound
Version: 1.13.1-1
Severity: normal
Tags: patch

I ran out of space on /var and unbound still tried to update the root
trust anchor file which ended up empty.  Then later after reboot the
package-helper failed to detect and recover from that, and
unbound.service failed to start.

With the attached patch (which adds a rudimentary sanity check) and
freshly freed disk space unbound started normally.  However, a better
solution might be to test more carefully for sufficient disk space
when making changes to the file or using 2 oversized files in rotation
and never truncating them.


I wonder if we should address the root problem here instead of the
symptoms.

Maybe we can always update this (very small) file as a part of the
daemon startup procedure.

And/or, when doing this (it is just being copied to the chroot from
/usr/share/dns/root.key), unbound can do it atomically - copying it
to a temporary file and renaming it to the right place when done.
Unlike install(1), this will never result in having an incomplete
file in place (provided the filesystem is doing the right thing).

Yet another option is to compare the two files and copy over if the
files are different.

Neither of that requires verification of the validity of the file.
But it will surely change behavior if people used to keep their own
file in /var/lib/unbound/root.key - can this *ever* happen at all?
But this is not a conffile to begin with, if one wants to have their
own root.key, they sure can set ROOT_TRUST_ANCHOR_UPDATE=no in
/etc/default/unbound.

What do you think?

Thank you for the patch!

/mjt


P.S.: I also noticed that unbound.service under [Service] defines no
StateDirectory=/var/lib/unbound to ensure that it is mounted on start.


The chroot setup procedure has its own load of issues.

Bug#1009143: plocate: Similar issue here

[James Cloos]

> "SG" == Steinar H Gunderson  writes:

SG> If so, I don't understand why running updatedb manually doesn't do anything.
SG> Perhaps there are multiple issues in play on the same bug number.

*perhaps* he gets something similar to what i see on one arm32 buster sbc:

   updatedb exits complaining that $CWD is a directory. (cf below :)

i've not had a chance to debug that beyond trying --debug-pruning and
trying it from a variety of current directories and uids, all w/o
benefit.

the strace output ends with:

  openat(AT_FDCWD, "/var/lib/plocate/", O_WRONLY|O_LARGEFILE|O_TMPFILE, 0640) = 
-1 EISDIR (Is a directory)

i've only seen it on arm32 buster, though.

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

Bug#620041: initramfs-tools-core: Please migrate to KEYMAP=auto

[Martin-Éric Racine]

Package: initramfs-tools-core
Version: 0.141
Followup-For: Bug #620041

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The main problem is that, should system booting fail and get dropped into the 
Busybox rescue shell, rescuing will be hampered by the kernel having remained 
on US keymap assumptions. This makes it very difficult to perform emergency 
maintenance on systems with a non-US keyboard.

Two possible solutions:

1) Use KEYMAP=y as the stock upstream default. There however may be reasons why 
this would be undesirable.

2) Migrate to a new KEYMAP=auto stock default (similar to BUSYBOX=auto) and 
install the keymap into the initrd image if the utilities are present on the 
system. This would probably be the best solution in the long run.

Martin-Éric

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

Kernel: Linux 5.16.0-6-686 (SMP w/1 CPU thread; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages initramfs-tools-core depends on:
ii  coreutils8.32-4.1
ii  cpio 2.13+dfsg-7
ii  e2fsprogs1.46.5-2
ii  klibc-utils  2.0.10-4
ii  kmod 29-1
ii  logsave  1.46.5-2
ii  udev 250.4-1

Versions of packages initramfs-tools-core recommends:
ii  busybox-static [busybox]  1:1.30.1-7+b2
ii  zstd  1.5.2+dfsg-1

Versions of packages initramfs-tools-core suggests:
ii  bash-completion  1:2.11-6

- -- Configuration Files:
/etc/initramfs-tools/initramfs.conf changed:
MODULES=most
BUSYBOX=auto
KEYMAP=y
COMPRESS=zstd
DEVICE=
NFSROOT=auto
RUNSIZE=10%
FSTYPE=auto


- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmJc6IQACgkQrh+Cd8S0
17YLvA//e88s7yi67XVaeJpy6SotDGBDUfcZNi1S1XdbbrYdHcyitN1rx6HZURzi
Vii7IthpOkA2le2FsbJ6HXtXW98JQ/iGi8Vz1cWqNLlkpLRRlNIoFa9eb2uHZljg
BmMRYB3AS7UApZNaTlBbmiTyobJEqlRXj6YZ4kuPMSuH2C9q1BMs+Y2CTxKMcy+y
OzSdGhjpAjEdR176uvOowBL+FUK62DeSYpCiyqBN6JN4dhhtempE4FZK2PlM0JG0
L5DrT6vK7wzj+lOKuENK6E0ZKezb2X399Tv64OjSJ+Bz11Au9gTi3jhSt51DXaen
oCMhnu1ogt4LvNt+yG4iNSgBqWr5pcjtg8YUCADC7Bt8zmuEy9Au8/QvS0ypogwH
VXXrZxf6whFn8iUEHOMqNxj80iEm0QYgf/uEdL4VKX8e5Npx5nEIgYKrjYzPByET
9WlRLLnzxw37IQCMkca9sxPotqErP1g8C5YB2Nwy3q7Jwm0Qi4uMfT45TdTW6j93
SLHcmuEIjM26iqWr2YlHFvNCszgwxzkHlZbIspzRWmB+Roem0cL+8pO3/jLR5Hks
FRkII85ywM/EhnqjZV1qqpXkxwMX5j9h84+v4gtWZtpMWCH+StyX6WzGWWIRL9pc
ccnV9LqZeU6OtOSma0XpjDxrAbbtfoMnSEd7k3VAE6LXkgdNmzQ=
=R5Vp
-END PGP SIGNATURE-

Bug#1009800: RM: ctop -- RoQA; dead upstream; imcompatible with debian 11+; unresponsive maintainer

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: mo...@debian.org

Hello,
as stated at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=99626 we can 
remove this package

Bug#1009799: puppet: reproducible builds: domain name embedded in puppet.conf.5 man page

[Vagrant Cascadian]

Source: puppet
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: hostname
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The domainname of the system is embeded in the puppet.conf.5 man page:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/puppet.html

  \fIDefault\fR:·debian\.net
vs.
  \fIDefault\fR:

The attached patch is an update to the previous reproducible builds
patch, fixing a new occurance of the domain name. It checks if
SOURCE_DATE_EPOCH is set, and displays a fixed string instead of the
running system's domain name.


This patch appears to apply to puppet from experimental too, although I
was unable to get that to build to confirm the fix.


With this patch applied, puppet should build reproducibly on
tests.reproducible-builds.org!


Thanks for maintaining puppet!


live well,
  vagrant
From f2fbbd0b92ac3fdd5647c59802680da91814d91c Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 18 Apr 2022 02:47:05 +
Subject: [PATCH] lib/puppet/defaults.rb: Patch "srv_domain" to generate
 puppet.conf.5 manpage reproducibly.

Similar to how this was handled with "certname", when
SOURCE_DATE_EPOCH is set, print a descriptive string rather than the
system's domain name.
---
 lib/puppet/defaults.rb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/puppet/defaults.rb b/lib/puppet/defaults.rb
index 404c02e939..96e6d6fdf6 100644
--- a/lib/puppet/defaults.rb
+++ b/lib/puppet/defaults.rb
@@ -1587,7 +1587,7 @@ EOT
   :desc   => "Whether the server will search for SRV records in DNS for the current domain.",
 },
 :srv_domain => {
-  :default=> lambda { Puppet::Settings.domain_fact },
+  :default=> lambda { ENV.has_key?('SOURCE_DATE_EPOCH') ? '(node\'s fully qualified domain name)' : Puppet::Settings.domain_fact },
   :desc   => "The domain which will be queried to find the SRV records of servers to use.",
 },
 :ignoreschedules => {
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1009798: key-mon: New upstream location with recent releases

[GSR]

Package: key-mon
Version: 1.17-1
Severity: normal

Dear Maintainer,

upstream appears to be https://github.com/scottkirkwood/key-mon now
and version 1.20 was released recently. Please consider packaging it
for future Debian releases instead of letting it expire.

Thank you,
GSR
 

Bug#1009797: apt: support "nodoc" build profile

[Vagrant Cascadian]

Source: apt
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

There are some non-deterministic identifiers that doxygen introduces
into apt's documentation packages:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/apt.html

The attached patch, adds support for the "nodoc" build profile, allowing
to build the other apt packages reproducibly by excluding the
documentation packages.

This also allows building functional apt packages with a smaller
dependency chain, so might help with bootstrapping efforts too!

I thought docbook* and xsltproc could also be excluded from the
Build-Depends, but that triggered some other build failures.


Of course, ideally building documentation reproducibly would be very
nice as well, so it would be good to eventually fix the underlying
issues in doxygen:

  
https://tests.reproducible-builds.org/debian/issues/unstable/nondeterminstic_todo_identifiers_in_documentation_generated_by_doxygen_issue.html
  
https://tests.reproducible-builds.org/debian/issues/unstable/nondeterministic_ordering_in_documentation_generated_by_doxygen_issue.html


Thanks for maintaining apt!


live well,
  vagrant
From d408a3b439dafa4378a1eec6c7c4dbefe4986897 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 17 Apr 2022 22:11:12 +
Subject: [PATCH 2/2] Add support for "nodoc" build profile.

  https://wiki.debian.org/BuildProfileSpec#Registered_profile_names
---
 debian/control | 4 +++-
 debian/rules   | 8 +++-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 2f1d0515e..7f10eec3e 100644
--- a/debian/control
+++ b/debian/control
@@ -31,7 +31,7 @@ Build-Depends: cmake (>= 3.4),
triehash,
xsltproc,
zlib1g-dev
-Build-Depends-Indep: doxygen, graphviz, w3m
+Build-Depends-Indep: doxygen , graphviz , w3m 
 Vcs-Git: https://salsa.debian.org/apt-team/apt.git
 Vcs-Browser: https://salsa.debian.org/apt-team/apt
 
@@ -101,6 +101,7 @@ Priority: optional
 Depends: ${misc:Depends}
 Section: doc
 Multi-Arch: foreign
+Build-Profiles: 
 Description: documentation for APT
  This package contains the user guide and offline guide for various
  APT tools which are provided in a html and a text-only version.
@@ -125,6 +126,7 @@ Priority: optional
 Depends: ${misc:Depends}
 Section: doc
 Multi-Arch: foreign
+Build-Profiles: 
 Description: documentation for APT development
  This package contains documentation for development of the APT
  Debian package manipulation program and its libraries.
diff --git a/debian/rules b/debian/rules
index ce9218968..38db7819a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -17,6 +17,12 @@ else
 	configure_test_flags =
 endif
 
+ifeq ($(filter nodoc,$(DEB_BUILD_PROFILES)),)
+	WITH_DOC=-DWITH_DOC=ON
+else
+	WITH_DOC=-DWITH_DOC=OFF
+endif
+
 %:
 	dh $@ --buildsystem=cmake+ninja
 
@@ -45,6 +51,6 @@ override_dh_installsystemd:
 	dh_installsystemd --remaining-packages
 
 override_dh_auto_configure-arch: flags=-DWITH_DOC=OFF
-override_dh_auto_configure-indep: flags=-DWITH_DOC=ON
+override_dh_auto_configure-indep: flags=$(WITH_DOC)
 override_dh_auto_configure-arch override_dh_auto_configure-indep:
 	dh_auto_configure -- $(flags) $(configure_test_flags)
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#982160: sudo does not honour "NOPASSWD" directive

[Wolfgang Sourdeau]

Hi Marc,


This problem no longer seems to occur, whenever the user is in group 
"sudo" or not. I think this bug report can be closed.


Thank you!

Le 2022-03-14 15:52, Marc Haber a écrit :

Control: outlook -1 close 2021-04-30
thanks

On Wed, Feb 02, 2022 at 12:40:47PM +0100, Marc Haber wrote:

Is your user in group sudo? If so, this is a case of #116705.


No answer to this question was received. Will close the bug by the end
of April 2022.

Greetings
Marc

Bug#1009796: apt: reproducible-builds: BuildId differences triggered by RPATH

[Vagrant Cascadian]

Source: apt
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The RPATH contains the build path resulting in different buildid:

  https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/apt.html

The attached patch to debian/rules passes
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via a dh_auto_configure override,
which should use a relative path for RPATH.

Alternately, updating the packaging to debhelper compat level 14 should
fix this, although it is currently an experimental compat level.

Unfortunately, other issues prevent this package from being reproducible
(randomness in documentation), but this patch should at least reduce the
diff.


Thanks for maintaining apt!


live well,
  vagrant
From 73c5b2945d385823f4291f27211c226f242c90c3 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 17 Apr 2022 23:12:47 +
Subject: [PATCH 1/2] debian/rules: Pass -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via
 dh_auto_configure override.

This avoids embedding the full path in RPATH, which triggers BuildId
differences.

https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 8a110f7a1..ce9218968 100755
--- a/debian/rules
+++ b/debian/rules
@@ -47,4 +47,4 @@ override_dh_installsystemd:
 override_dh_auto_configure-arch: flags=-DWITH_DOC=OFF
 override_dh_auto_configure-indep: flags=-DWITH_DOC=ON
 override_dh_auto_configure-arch override_dh_auto_configure-indep:
-	dh_auto_configure -- $(flags) $(configure_test_flags)
+	dh_auto_configure -- $(flags) $(configure_test_flags) -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#493784: libgc: please provide a build with --enable-large-config

[Torrance, Douglas]

On Mon, 04 Aug 2008 23:26:10 +0200 Bernd Zeimetz  wrote:

for some use cases ([1] for example) it would be useful to have a
version of libgc available, which was built with --enable-large-config.
I didn't dig into libgc to find out what the best way would be to
achive this, but I'm sure there is one ;)


I would also like to see this.  libgc is used by Macaulay2, a software
platform for algebraic geometry and commutative algebra research, and
the memory limitations of the current Debian libgc package aren't
sufficient for some problems [3].

[3] https://github.com/Macaulay2/M2/issues/2445


signature.asc
Description: PGP signature

Bug#1009668: irqtop/lsirq: missing commands in util-linux package

[Axel Beckert]

Hi Chris,

> > * From src:util-linux's side the only thing left is that the package
> >   shipping util-linux's implementation of irqtop needs to sport Breaks
> >   and Replaces (not Conflicts) against "irqtop (<< 2.6-4~)".
> > 
> >   If you want, I can file a RC bug-report against the version in
> >   Experimental due to its util-linux-extra package missing these
> >   headers so far.
> > 
> > * Optionally you could add a note in the package description of
> >   util-linux(-extra) that the previously known, ruby-written
> >   implementation of irqtop can be found in the package irqtop-nf.
> 
> > [..]
> 
> > I'd be happy if you could fix the missing Breaks/Replaces headers in
> > util-linux-extra. TIA!
> 
> Both - the Breaks/Replaces, and the package description - are now in
> experimental, as src:util-linux / util-linux-extra 2.38-4+exp2.

Thanks. Looks good to me now. I though suggest to slightly rephrase
this sentence:

  Another variant of irqtop is found in the irqtop-nf package.

I suggest to phrase it more like this:

  A different implementation of irqtop can be found in the irqtop-nf
  package.

I'm working on the accompanying irqtop and irqtop-nf package, but will
probably upload it only after a round of sleeping (aka "tomorrow"
despite it's already "tomorrow" in my time zone ;-).

My work on it so far can be found on
https://salsa.debian.org/debian/iptables-netflow/ with most of it
being in this commit:

https://salsa.debian.org/debian/iptables-netflow/-/commit/85f7bb9ba685e7bfe5837c5aa476dfd8f5c3ec08

Also remember that it will have to go through the NEW queue due to the
additional binary package, i.e. it might take a week or so before it
shows up in experimental.

> Would love your feedback on these changes.

Not a comment on these changes, but still something I'm wondering
about:

Why does util-linux have a hard dependency on util-linux-extra?

I would have expected a Recommends or Suggests. Because otherwise
splitting off that package seems to make no sense to me.

And also the alternative dependency from the future irqtop
transitional package makes no sense as it will be always fulfilled
since currently util-linux-extra is a defacto essential package.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1009795: should depend on correct python3-pluggy version

[Roland Hieber]

Package: python3-pylsp
Version: 1.4.1-1
Severity: minor

Dear Maintainer,

After trying to use pylsp as a backend with vim-lsp, I noticed that the
backend didn't start. Indeed, when started on the command line, I got a
stack trace:

$ pylsp
Traceback (most recent call last):
  File "/usr/bin/pylsp", line 5, in 
from pylsp.__main__ import main
  File "/usr/lib/python3/dist-packages/pylsp/__main__.py", line 15, in 

from .python_lsp import (PythonLSPServer, start_io_lang_server,
  File "/usr/lib/python3/dist-packages/pylsp/python_lsp.py", line 15, in 

from .config import config
  File "/usr/lib/python3/dist-packages/pylsp/config/config.py", line 11, in 

from pluggy._hooks import HookImpl
ModuleNotFoundError: No module named 'pluggy._hooks'

Apparently the problem arose because apt chose to install the pylsp
version from unstable (as there is none in stable), but the
python3-pluggy version from stable, and apparently those are not
compatible. Installing python3-pluggy 1.0.0-1 from unstable solved the
problem, so I think the dependency should be versionised.

Thanks,

 - Roland

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

Kernel: Linux 5.10.0-12-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-pylsp depends on:
ii  python33.9.2-3
ii  python3-jedi   0.18.0-1
ii  python3-pkg-resources  52.0.0-4
ii  python3-pluggy 0.13.0-6
ii  python3-pylsp-jsonrpc  1.0.0-2
ii  python3-ujson  4.0.2-1

python3-pylsp recommends no packages.

Versions of packages python3-pylsp suggests:
ii  flake8   3.8.4-1
pn  pylint   
pn  python3-autopep8 
ii  python3-mccabe   0.6.1-3
ii  python3-pycodestyle  2.6.0-1
pn  python3-pydocstyle   
ii  python3-pyflakes 2.2.0-2
pn  python3-rope 
pn  python3-yapf 

-- no debconf information

Bug#1009794: Current version (1.5.2-1) doesn't work with Dovecot 2.3.18, please upgrade

[Sergio Durigan Junior]

Source: dovecot-fts-xapian
Version: 1.5.2-1
Severity: grave

Hello,

The current version of dovecot-fts-xapian doesn't work with Dovecot
2.3.18, currently in unstable/testing:

# doveadm index -A \*
Fatal: Couldn't load required plugin 
/usr/lib/dovecot/modules/lib21_fts_xapian_plugin.so: Module is for different 
ABI version 2.3.ABIv16(2.3.16) (we have 2.3.ABIv18(2.3.18))

The latest upstream version (1.5.5) fixes this problem.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1009668: irqtop/lsirq: missing commands in util-linux package

[Chris Hofstaedtler]

Hi Axel,

* Axel Beckert  [220417 13:50]:
> TL;DR: What if we just make util-linux-extra taking over the binary
> path /usr/bin/irqtop and the irqtop(-nf) package providing a binary
> name irqtop-nf in the future plus leaving the remainder to
> package descriptions and NEWS.Debian?

Thanks for the analysis and suggestions!

> [..]

> * From src:util-linux's side the only thing left is that the package
>   shipping util-linux's implementation of irqtop needs to sport Breaks
>   and Replaces (not Conflicts) against "irqtop (<< 2.6-4~)".
> 
>   If you want, I can file a RC bug-report against the version in
>   Experimental due to its util-linux-extra package missing these
>   headers so far.
> 
> * Optionally you could add a note in the package description of
>   util-linux(-extra) that the previously known, ruby-written
>   implementation of irqtop can be found in the package irqtop-nf.

> [..]

> I'd be happy if you could fix the missing Breaks/Replaces headers in
> util-linux-extra. TIA!

Both - the Breaks/Replaces, and the package description - are now in
experimental, as src:util-linux / util-linux-extra 2.38-4+exp2.
Would love your feedback on these changes.

Best,
Chris

Bug#1009143: plocate: Similar issue here

[Ron Murray]

Yes. Once I've figured out what the problem is, I'll file another bug
report.

-- 
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E 7B63 12F7 E865 B5E2 E761


On Sun, 2022-04-17 at 23:27 +0200, Steinar H. Gunderson wrote:
> On Sun, Apr 17, 2022 at 04:39:30PM -0400, Ron Murray wrote:
> >    Sorry, perhaps I wasn’t too clear. Running updatedb manually
> > works fine.
> >    I just had to do it again. I think the only issue is the auto
> > update.
> 
> I think that should be on a different bug, then.
> 
> /* Steinar */

Bug#346541: We need to talk. URGENT

[James Atkin]

I will email to you more details as soon as you acknowledge this message.
Thank you.
James Atkinson.

Bug#1009793: linux-source 5.10.106-1 changes block device order

[Elliott Mitchell]

Package: src:linux
Version: 5.10.106-1

Between 5.10.103-1 and 5.10.106-1 (image -13) something changed which
reliably causes what used to show as /dev/sda to show as /dev/sdb.  Other
block devices plugged into the SCSI subsystem may have swapped around,
but I've yet to untangle the others.

A few utilities are still sensitive to block device order and this
causes issues for those.  Nothing on the hardware explains this.  The
controller thinks the device has a lower number, the device should
respond much faster.

The lowest level is the cciss driver.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#1009792: mpich: armci-mpi test error: MPIR_pmi_init(151)...: PMIX_Init returned -25

[Drew Parsons]

Package: mpich
Version: 4.0.2-1
Severity: serious
Justification: FTBFS/debci

debci tests for armci-mpi with the new mpich 4.0.2-1 are failing with
the error:

Abort(605670927): Fatal error in internal_Init: Other MPI error, error stack:
internal_Init(59): MPI_Init(argc=0x7ffca340893c, argv=0x7ffca3408930) failed
MPII_Init_thread(209): 
MPID_Init(359)...: 
MPIR_pmi_init(151)...: PMIX_Init returned -25

The problem is not as simple as just rebuilding armci-mpi (which
builds static libraries) in a binNMU, since the same error occurs in
build-time tests.

The error also appears in nwchem (possibly via its use of armci-mpi),
and in bagel tests.

Is there an incompatibility between mpich 4.0.2 and libpmix ?



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

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

Versions of packages mpich depends on:
ii  hwloc   2.7.1-1
ii  libc6   2.33-7
ii  libhwloc15  2.7.1-1
ii  libmpich12  4.0.2-1
ii  libslurm37  21.08.6-1

Versions of packages mpich recommends:
ii  libmpich-dev  4.0.2-1

Versions of packages mpich suggests:
ii  mpich-doc  4.0.2-1

-- no debconf information

Bug#1009781: ITP: safe-vdash -- the Safe Network - node dashboard

[Jonas Smedegaard]

Needs embedding 43 crates; builds in ~5 minutes; completely untested

[ adjustment of wrong negation in summary line ]

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1009143: plocate: Similar issue here

[Steinar H. Gunderson]

On Sun, Apr 17, 2022 at 04:39:30PM -0400, Ron Murray wrote:
>Sorry, perhaps I wasn’t too clear. Running updatedb manually works fine.
>I just had to do it again. I think the only issue is the auto update.

I think that should be on a different bug, then.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#1009781: ITP: safe-vdash -- the Safe Network - node dashboard

[Jonas Smedegaard]

Needs embedding 43 crates; builds in ~5 minutes; completely tested

The packaging draft at https://salsa.debian.org/debian/safe-vdash now 
succesfully builds the working binary package safe-vdash.  It is a dirty 
build: Many crates not yet packaged in Debian are needed, so this is not 
acceptable officially in Debian yet.

Main task now, besides keeping the packaging up-to-date with upstream 
releases, is to patch the code to align closer with Rust crates 
available in Debian, to reduce the amount of reverse dependencies 
needing packaging before this can be released officially in Debian.

You can help by testing this draft package (either build it yourself or 
tell if you want access to binary packages I've built) and provide 
feedback on how well it works for you.

You can also help by joining the Rust team in Debian and contribute to 
unbreaking/upgrading/adding needed crate packages, as listed here: 
https://salsa.debian.org/debian/safe-vdash/-/blob/debian/latest/debian/TODO


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1009243: libapache2-mod-python: (autopkgtest) needs update for python3.10

[Bastian Germann]

Am 17.04.22 um 21:37 schrieb Paul Gevers:

The package obviously has no support for python3.10; there are python3.9 bugs 
as well.


Could you elaborate? The issue you copy/pasted above is a pure python3.10 
regression.


Examples: #975608 and #986977.


It is abandoned upstream. I suggest filing a RM bug for this package.


Sure, but somebody that assessed the situation has to do that. Until somebody does that, at least this bug will remove 
the package from testing in due time.


Paul

Bug#1009143: plocate: Similar issue here

[Ron Murray]

Ah.

   Sorry, perhaps I wasn’t too clear. Running updatedb manually works fine. I 
just had to do it again. I think the only issue is the auto update.

-- 
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E  7B63 12F7 E865 B5E2 E761

> On Apr 17, 2022, at 16:14, Steinar H. Gunderson  wrote:
> 
> On Sun, Apr 17, 2022 at 04:07:21PM -0400, Ron Murray wrote:
>> I think the problem is that the cron.daily plocate job isn't being run.
>> I'd suspect the systemd timer doesn't work, but I'm not sure. I'll hack
>> the cron.daily/plocate script to save some diagnostic information, and
>> perhaps that'll help.
> 
> If so, I don't understand why running updatedb manually doesn't do anything.
> Perhaps there are multiple issues in play on the same bug number.
> 
> /* Steinar */
> -- 
> Homepage: https://www.sesse.net/

Bug#1009791: mutt: change-folder no longer selects next folder with new mail

[Bob Proulx]

Package: mutt
Version: 2.2.3-1
Severity: normal

I upgrade my Sid Unstable desktop daily.  The upgrade from 2.1.4-1 to
2.2.3-1 breaks the change-folder action (normally bound to 'c').

Normally and up through mutt 2.1.4-1 (at least) typing 'c' would
prompt with the next mailbox that has new mail since the last time
mutt visited the folder.  That allowed a set of mailboxes to be walked
through one after the other.  The messages are seen.  Then whether
mail is read or not read 'c' moves to another folder.  Mutt will
prompt for a different folder with new mail.  If new mail arrives in a
previously visited folder then it will once again become a candidate
for prompting with the change-folder action.

Starting with 2.2.3-1 the 'c' change-folder action now prompts with
the *previous folder always* and never prompts with any other folders.
It no longer selects a mailboxes folder with new mail.  It prompts
with the previous folder even if no new mail has arrived there.
Effectively creating a situation where one toggles between two folders
endlessly.

I don't know why the previous folder is always selected.  It's
possible that upon leaving the folder that mutt 2.2.3-1 modifies it in
some way causing it to appear new and therefore to be placed at the
top of the new mail folder list next change-folder action.  I don't
know.  That would be one possible way to create this behavior.  But
whatever the root cause it breaks use of the 'c' change-folder action.

Note that this is separate from pressing space to rotate through the
mailboxes list manually.  Yes it is always possible to spacebar
through all of the configured mailboxes manually.  But that is very
tedious when a lot of mailboxes are configured.  This is definitely a
regression from before when this prompted for a folder from the
configured mailboxes list that had new mail.

Downgrading to 2.1.4-1 and holding it works around this problem.

apt-get install mutt=2.1.4-1
apt-mark hold mutt

Thank you for maintaining Mutt in Debian.

Bob


-- Package-specific info:
Mutt 2.2.3 (2022-04-12)
Copyright (C) 1996-2022 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 5.16.0-6-amd64 (x86_64)
ncurses: ncurses 6.3.20211021 (compiled with 6.3)
libidn2: 2.3.2 (compiled with 2.3.2)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 11.2.0-19' 
--with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-11 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib 
--enable-libphobos-checking=release --with-target-system-zlib=auto 
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet 
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 
--enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none=/build/gcc-11-uiwEqG/gcc-11-11.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-uiwEqG/gcc-11-11.2.0/debian/tmp-gcn/usr
 --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu 
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Debian 11.2.0-19)

Configure options: --build=x86_64-linux-gnu --prefix=/usr 
'--includedir=${prefix}/include' '--mandir=${prefix}/share/man' 
'--infodir=${prefix}/share/info' --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
'--libdir=${prefix}/lib/x86_64-linux-gnu' --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking 
--with-mailpath=/var/mail --enable-compressed --enable-debug --enable-fcntl 
--enable-hcache --enable-gpgme --enable-imap --enable-smtp --enable-pop 
--enable-sidebar --enable-dotlock --disable-fmemopen --with-curses 
--with-gnutls --with-gss --with-idn2 --with-mixmaster --with-sasl 
--without-gdbm --without-bdb --without-qdbm --with-tokyocabinet 
build_alias=x86_64-linux-gnu 'CFLAGS=-g -O2 
-ffile-prefix-map=/build/mutt-Z2eSdv/mutt-2.2.3=. -fstack-protector-strong 
-Wformat -Werror=format-security' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 

Bug#1009790: idjc: New upstream release 0.9.3 available

[Magnus Holmgren]

Package: idjc
Severity: wishlist

Hi,

I thought IDJC was dead (there were no new releases for a couple of years), 
but apparently upstream has been working on converting to Python 3 and GTK+ 3, 
so it can be included in Debian again, which I'd be interested in, since I use 
IDJC regularly. Although I'm not a Python packaging expert, I've taken a stab 
at updating the packaging. I could fork and open a merge request, but that 
doesn't really work with the upsteam and pristine-tar branches, so I'll attach 
a patch for now.

Some comments:

configure.ac requires git, or else it won't define the GIT_VERSION_CONTROL 
conditional, leading to a make error.

./py-compile needs PYTHON to be set in order to work with python3.

I hope that it's correct to pass --no-ext-rename to dh_python3. This package 
is not going to be Multi-Arch compatible.

I also hope that I got the dependencies right. I added a python3-pymysql | 
python3-mysqldb recommendation (can be used to connect to Prokyon or Ampache 
database).

idjc.appdata.xml.in.in stil needs to be patched to conform to the current 
standard (Lintian reports an error).

-- 
Magnus Holmgrenholmg...@debian.org
Debian Developer diff --git a/debian/changelog b/debian/changelog
index 346888f..a83eec2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,9 +1,15 @@
-idjc (0.8.17-2) UNRELEASED; urgency=medium
+idjc (0.9.3-1) UNRELEASED; urgency=low
 
+  [ Debian Janitor ]
   * Wrap long lines in changelog entries: 0.7.5-1.
   * Set upstream metadata fields: Repository.
 
- -- Debian Janitor   Sat, 01 Feb 2020 23:10:14 +
+  [ Magnus Holmgren ]
+  * New upstream version 0.9.3
+  * Refresh patches.
+  * Drop ogg.patch; applied upstream.
+
+ -- Magnus Holmgren   Sun, 17 Apr 2022 13:43:27 +0200
 
 idjc (0.8.17-1) unstable; urgency=medium
 
diff --git a/debian/control b/debian/control
index 1a34fbf..12d23e0 100644
--- a/debian/control
+++ b/debian/control
@@ -9,10 +9,12 @@ Uploaders:
 Build-Depends: debhelper-compat (= 11),
  autopoint,
  dh-python,
+ git,
+ libglib2.0-dev,
  libavcodec-dev,
  libavformat-dev,
  libflac-dev,
- libjack-dev,
+ libjack-jackd2-dev,
  libmp3lame-dev,
  libmpg123-dev,
  libogg-dev (>= 1.3.0),
@@ -23,9 +25,8 @@ Build-Depends: debhelper-compat (= 11),
  libspeex-dev,
  libswscale-dev,
  libvorbis-dev,
- python-dev (>= 2.7~),
- python-gtk2-dev,
- python-mutagen
+ python3-dev (>= 3.7~),
+ python3-mutagen
 Standards-Version: 4.1.4
 Homepage: http://idjc.sourceforge.net/
 Vcs-Git: https://salsa.debian.org/multimedia-team/idjc.git
@@ -34,16 +35,20 @@ Vcs-Browser: https://salsa.debian.org/multimedia-team/idjc
 Package: idjc
 Architecture: any
 Depends:
+ python3-dbus,
+ python3-gi,
+ python3-irc,
+ python3-mutagen,
+ gir1.2-gtk-3.0,
+ gir1.2-pango-1.0,
+ gir1.2-glib-2.0,
+ gir1.2-gdkpixbuf-2.0,
  jackd,
- python-dbus,
- python-gobject,
- python-gtk2,
- python-irc,
- python-mutagen,
  ${misc:Depends},
- ${python:Depends},
+ ${python3:Depends},
  ${shlibs:Depends}
-Recommends: python-eyed3
+Recommends: python3-eyed3,
+ python3-pymysql | python3-mysqldb
 Description: graphical shoutcast/icecast client
  Internet DJ Console is an Internet radio application for making a live radio
  show or podcast. Features include two main media players with a crossfader,
diff --git a/debian/patches/desktop.patch b/debian/patches/desktop.patch
index 5904426..4c5d976 100644
--- a/debian/patches/desktop.patch
+++ b/debian/patches/desktop.patch
@@ -4,10 +4,10 @@ Last-Update: 2015-11-15
 
 --- a/idjc.desktop.in.in
 +++ b/idjc.desktop.in.in
-@@ -12,15 +12,14 @@
+@@ -12,15 +12,14 @@ GenericName[it]=Client grafico shoutcast
  GenericName[de]=Grafischer Shoutcast/Icecast Client
  GenericName[fr]=Client graphique shoutcast/icecast
- Icon=${prefix}/share/pixmaps/@PACKAGE_NAME@.png
+ Icon=${prefix}/share/icons/hicolor/scalable/apps/@PACKAGE_NAME@.svg
 -MimeType=
  Name=Internet DJ Console
  Path=
diff --git a/debian/patches/link-ogg.patch b/debian/patches/link-ogg.patch
deleted file mode 100644
index 636b258..000
--- a/debian/patches/link-ogg.patch
+++ /dev/null
@@ -1,39 +0,0 @@
-Description: Link libogg into idjc.so
- This in turn ensures that the correct dependency on libogg is generated.
- .
- The patch is the "strictest" way of including this in the upstream build system
- because it adds libogg as a required dependency.
-Author: James Cowgill 
-Bug: https://sourceforge.net/p/idjc/bugs/99/
-Bug-Debian: https://bugs.debian.org/900754

-This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
 a/c/Makefile.am
-+++ b/c/Makefile.am
-@@ -32,7 +32,7 @@ idjc_la_CFLAGS = ${GLIB_CFLAGS} ${LIBAVC
- 			\
- ${LIBSPEEX_CFLAGS} ${LIBVORBISENC_CFLAGS} ${LIBVORBIS_CFLAGS} ${TWOLAME_CFLAGS} ${OPUS_CFLAGS}			\
- 			\
--${LIBSWRESAMPLE_CFLAGS} -O2 -Wall -std=gnu99
-+${LIBSWRESAMPLE_CFLAGS} ${LIBOGG_CFLAGS} -O2 -Wall -std=gnu99
- 
- idjc_la_LIBADD = ${DYN_LIBS} ${GLIB_LIBS} ${LIBAVCODEC_LIBS} ${LIBAVFORMAT_LIBS} ${LIBAVUTIL_LIBS} ${LIBFLAC_LIBS} 		\
- 

Bug#1009789: bmtk: autopkgtest failure on !amd64

[Paul Gevers]

Source: bmtk
Version: 1.0.4+ds-2
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package bmtk, great. However, 
it fails on all architectures but amd64. Currently this failure is 
blocking the migration to testing [1]. Can you please investigate the 
situation and fix it?


I copied some of the output at the bottom of this report.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=bmtk

https://ci.debian.net/data/autopkgtest/testing/arm64/b/bmtk/20682058/log.gz

 ERRORS 

 ERROR collecting tests/builder/test_connection_map.py 
_
ImportError while importing test module 
'/tmp/autopkgtest-lxc.tmonru7m/downtmp/autopkgtest_tmp/tests/builder/test_connection_map.py'.

Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.10/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
tests/builder/test_connection_map.py:4: in 
from bmtk.builder.connection_map import ConnectionMap
E   ModuleNotFoundError: No module named 'bmtk'
___ ERROR collecting tests/builder/test_connector.py 
___
ImportError while importing test module 
'/tmp/autopkgtest-lxc.tmonru7m/downtmp/autopkgtest_tmp/tests/builder/test_connector.py'.

Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.10/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
tests/builder/test_connector.py:1: in 
from bmtk.builder import connector
E   ModuleNotFoundError: No module named 'bmtk'
_ ERROR collecting tests/builder/test_densenetwork.py 
__
ImportError while importing test module 
'/tmp/autopkgtest-lxc.tmonru7m/downtmp/autopkgtest_tmp/tests/builder/test_densenetwork.py'.

Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.10/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
tests/builder/test_densenetwork.py:4: in 
import numpy as np
E   ModuleNotFoundError: No module named 'numpy'
_ ERROR collecting tests/builder/test_edge_iterator.py 
_
ImportError while importing test module 
'/tmp/autopkgtest-lxc.tmonru7m/downtmp/autopkgtest_tmp/tests/builder/test_edge_iterator.py'.

Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.10/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
tests/builder/test_edge_iterator.py:3: in 
from bmtk.builder import NetworkBuilder
E   ModuleNotFoundError: No module named 'bmtk'
_ ERROR collecting tests/builder/test_edges_sorter.py 
__
ImportError while importing test module 
'/tmp/autopkgtest-lxc.tmonru7m/downtmp/autopkgtest_tmp/tests/builder/test_edges_sorter.py'.

Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.10/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
tests/builder/test_edges_sorter.py:3: in 
import h5py
E   ModuleNotFoundError: No module named 'h5py'
_ ERROR collecting tests/builder/test_id_generator.py 
__
ImportError while importing test module 
'/tmp/autopkgtest-lxc.tmonru7m/downtmp/autopkgtest_tmp/tests/builder/test_id_generator.py'.

Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.10/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
tests/builder/test_id_generator.py:3: in 
from bmtk.builder.id_generator import IDGenerator
E   ModuleNotFoundError: No module named 'bmtk'
 ERROR collecting tests/builder/test_index_builders.py 
_
ImportError while importing test module 
'/tmp/autopkgtest-lxc.tmonru7m/downtmp/autopkgtest_tmp/tests/builder/test_index_builders.py'.

Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.10/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
tests/builder/test_index_builders.py:3: in 
import h5py
E   ModuleNotFoundError: No module named 'h5py'
___ ERROR collecting tests/builder/test_iterator.py 

ImportError while importing test module 
'/tmp/autopkgtest-lxc.tmonru7m/downtmp/autopkgtest_tmp/tests/builder/test_iterator.py'.

Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.10/importlib/__init__.py:126: in import_module

Bug#844459: autopkgtest: Please add autopkgtest-virt-uchroot

[Jochen Sprickerhof]

Hi,

* Martin Pitt  [2016-11-16 13:37]:

Johannes Schauer [2016-11-16  1:12 +0100]:

in the context of #833407 I told you about my plan of adding a
virtualization backend which would allow completely unprivileged chroot
operation by using linux user namespaces.


Nice!


In contrast to what I thought was required back then, I now managed
to write that backend using just lxc-usernsexec and lxc-unshare.
Thus, I was able to get it to work using the existing Python
modules. You can find the script attached.  As you can see, it is
extremely simple, which I find makes the beauty of it all. All you
need is:



 - the lxc package installed for lxc-usernsexec and lxc-unshare


I'd like to eliminate this even. util-linux' unshare has known about
--user/-U for a while now, and thus replaces lxc-unshare and
lxc-usernsexec:

 $ unshare -rmU  sh -c 'whoami; mount -t tmpfs foo /mnt; touch /mnt/foo; ls -l 
/mnt/foo'
 root
 -rw-r--r-- 1 root root 0 Nov 16 12:59 /mnt/foo

And you can use util-linux' nsenter to enter an existing namespace.

These lxc-* tools were written before util-linux learned about those,
and I'm not sure if they are going to stick around forever as they are
basically obsolete. It would also avoid the lxc dependency.

Would you be willing to try this?


I have implemented this in autopkgtest-virt-unshare (attached). Would be 
great to get it into the autopkgtest package.



$ sbuild --chroot-mode=autopkgtest --autopkgtest-virt-server=uchroot \
--autopkgtest-virt-server-opts="-- /srv/chroot/%r-%a-sbuild.tar.gz 
/tmp/rootfs"

The path /tmp/rootfs is the path that the rootfs will be extracted to
and can be at any location that the user has access to.


I think it would be more comfortable to use mkdtemp() by default, and
provide --unpack-dir as an option?


I implemented this as well.


It would be great if this backend could be added to autopkgtest itself.
If you think that it is not a good fit for autopkgtest, then I can
maintain it in a separate package.


I think it would be a great fit, but in order to accept it I have some
stricter requirements:

* tests/autopkgtest should run at least the standard
  DebTestsVirtContainer tests. Look at classes LxcRunner and LxdRunner, should
  be a fairly simple extension.

  This will show the limits of what the backend can do, uncover
  possible encoding/locale/whatever issues, and ensure that this will
  keep working over time.

* It should get a manpage, probably starting from
  virt/autopkgtest-virt-chroot.1.


I can look into this if you are fine with the script in general.


As building such a chroot tarball doesn't require new tools, that
should be it (the manpage should just explain how to build them, with
sbuild-createchroot or mk-sbuild).

I actually have wanted to deprecate the "chroot" backend for a long
time, as it's inherently insecure and I never use it myself any more.
I wonder if uschroot could completely replace that? At first sight it
should have the same isolation and robustness capabilities like
lxc/lxd (at least wrt. the file system and mounting), except with a
lot fewer dependencies.

| tarball = None
| rootdir = None
|
|
| def parse_args():
| global tarball, rootdir
|
| parser = argparse.ArgumentParser()
| parser.add_argument('-d', '--debug', action='store_true',
| help='Enable debugging output')
| parser.add_argument('tarball', help='path to rootfs tarball')
|
| def hook_open():
| global tarball, rootdir
|
| # We want to find out our user and group id inside the chroot but we want
| # to avoid having to parse /etc/subuid and /etc/subgid. We solve the
| # situation by creating a temporary file from inside the user namespace
| # and then checking its user and group ids from outside the user 
namespace.
| probe = VirtSubproc.check_exec(['lxc-usernsexec', 'mktemp',
| '/tmp/uchroot.XX'], outp=True)
| inner_uid = os.stat(probe)[stat.ST_UID]
| inner_gid = os.stat(probe)[stat.ST_GID]
| VirtSubproc.check_exec(['lxc-usernsexec', 'rm', probe])
| outer_uid = os.getuid()
| outer_gid = os.getgid()

This dance wouldn't even be necessary with unshare -rU -- you know
that the outside uid/gid is just the normal user, and the inside one
is root/root.


done.


I'm not sure if there is something to be gained from the UID shift --
that isolates the chroot test better, but also makes it much harder to
clean up after a failed tests, as your normal user cannot touch/rm the
temporary directories? But if you want this, there's newuidmap(1).

| # Unpack the tarball into the new directory.
| # Make sure not to extract any character special files because we cannot
| # mknod.
| VirtSubproc.check_exec(['lxc-usernsexec', '--', 'tar',
| '--exclude=./dev/urandom',

Eek, do chroot tarballs regularly have /dev in them? Might be easier
and safer to exclude /dev/ wholesale, as you provide a minimal /dev

Bug#1009143: plocate: Similar issue here

[Steinar H. Gunderson]

On Sun, Apr 17, 2022 at 04:07:21PM -0400, Ron Murray wrote:
> I think the problem is that the cron.daily plocate job isn't being run.
> I'd suspect the systemd timer doesn't work, but I'm not sure. I'll hack
> the cron.daily/plocate script to save some diagnostic information, and
> perhaps that'll help.

If so, I don't understand why running updatedb manually doesn't do anything.
Perhaps there are multiple issues in play on the same bug number.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#1009143: plocate: Similar issue here

[Ron Murray]

I think the problem is that the cron.daily plocate job isn't being run.
I'd suspect the systemd timer doesn't work, but I'm not sure. I'll hack
the cron.daily/plocate script to save some diagnostic information, and
perhaps that'll help.

Thanks,

 .Ron

-- 
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E 7B63 12F7 E865 B5E2 E761


On Sun, 2022-04-17 at 21:38 +0200, Steinar H. Gunderson wrote:
> On Sat, Apr 09, 2022 at 07:50:09PM -0400, Ron Murray wrote:
> >    Steinar, you may be right about problems with the upgrade. I
> > started
> > looking into this earlier today because 'locate' couldn't find
> > files
> > that I knew were present in the filesystem. Based on what you said,
> > I
> > checked plocate.db and siscovered that it hadn't been updated since
> > December 30. The files I was looking for had, of course, been added
> > since then.
> 
> That's strange; do you know if the updatedb.plocate command was ever
> actually
> run? Did it output anything to the error log?
> 
> I've tried reproducing this by installing mlocate and then upgrading,
> but I can't get it to break.
> 
> >    I also note that there's still a 'locate' in /etc/cron.daily,
> > which
> > runs '/usr/bin/updatedb.findutils'. Should these be still on the
> > sysytem? Could they be interfering with plocate?
> 
> No, it's entirely independent.
> 
> /* Steinar */

Bug#935175: ITP #935175: python-pypdf4 -- PDF manipulation library

[Drew Parsons]

Control: affects 935175 src:xhtml2pdf

The PyPDF4 project at https://github.com/claird/PyPDF4 appears to have 
stalled.


PyPDF3 seem to be more actively maintained, 
https://github.com/sfneal/PyPDF3


If you proceed with this ITP then it might work better as packaging for 
PyPDF3 rather than PyPDF4


Latest versions of xhtml2pdf have switched to PyPDF3 (from PyPDF2).

Drew

Bug#1009174: [request-tracker-maintainers] Bug#1009174: request-tracker4: disordering of email headers in forwarded messages

[Dominic Hargreaves]

On Fri, Apr 08, 2022 at 08:59:06AM +0200, Joost van Baal-Ilić via 
pkg-request-tracker-maintainers wrote:
> Package: request-tracker4
> Version: 4.4.1-3+deb9u3
> Severity: normal
> 
> Dear Maintainer,
> 
> RT changes the original order of email headers when forwarding attached 
> emails.
> This is seen in case the original message was offered to RT with a leading 
> unix
> style From_ header.  This behaviour causes havoc in case the full mime message
> later gets analysed by strict spam scanners who interpret mime-included 
> message
> headers.

Thanks for the detailed report!

4.4.1 is now very old from an upstream point of view (and indeed even
in Debian that's from an LTS only release now).

Have you been able to reproduce this with a newer release such as
4.4.5 (which is in sid/testing)? I don't have a suitable test system
for this at the moment, unfortunately (I'm not using RT at all any more).

If it can be reproduced with 4.4.5 I think this report would be in a
good state to forwards upstream.

Cheers
Dominic

Bug#1009243: libapache2-mod-python: (autopkgtest) needs update for python3.10

[Paul Gevers]

Hi Bastian,

On 17-04-2022 14:50, Bastian Germann wrote:

On Sat, 9 Apr 2022 18:28:23 +0200 Paul Gevers  wrote:
We are in the transition of making python3.10 the default Python 
versions [0]. With a recent upload of python3-defaults the autopkgtest 
of libapache2-mod-python fails in testing when that autopkgtest is run 
with the binary packages of python3-defaults from unstable.


PythonHandler mod_python.publisher: Traceback (most recent call last):
mod_python/apache.py, line 398, in HandlerDispatch\n    result = obj(req)
mod_python/publisher.py", line 222, in handler\n    published = 
publish_object(req, object)
mod_python/publisher.py", line 440, in publish_object\n    if 
_callable(obj):
mod_python/publisher.py", line 54, in _callable\n    return 
(isinstance(obj, collections.Callable)

AttributeError: module 'collections' has no attribute 'Callable'

The package obviously has no support for python3.10; there are python3.9 
bugs as well.


Could you elaborate? The issue you copy/pasted above is a pure 
python3.10 regression.



It is abandoned upstream. I suggest filing a RM bug for this package.


Sure, but somebody that assessed the situation has to do that. Until 
somebody does that, at least this bug will remove the package from 
testing in due time.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009143: plocate: Similar issue here

[Steinar H. Gunderson]

On Sat, Apr 09, 2022 at 07:50:09PM -0400, Ron Murray wrote:
>Steinar, you may be right about problems with the upgrade. I started
> looking into this earlier today because 'locate' couldn't find files
> that I knew were present in the filesystem. Based on what you said, I
> checked plocate.db and siscovered that it hadn't been updated since
> December 30. The files I was looking for had, of course, been added
> since then.

That's strange; do you know if the updatedb.plocate command was ever actually
run? Did it output anything to the error log?

I've tried reproducing this by installing mlocate and then upgrading,
but I can't get it to break.

>I also note that there's still a 'locate' in /etc/cron.daily, which
> runs '/usr/bin/updatedb.findutils'. Should these be still on the
> sysytem? Could they be interfering with plocate?

No, it's entirely independent.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#1009788: rtl-433: CVE-2022-27419: Stack-based Buffer Overflow

[Salvatore Bonaccorso]

Source: rtl-433
Version: 21.12-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/merbanan/rtl_433/issues/2012
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for rtl-433.

CVE-2022-27419[0]:
| rtl_433 21.12 was discovered to contain a stack overflow in the
| function acurite_00275rm_decode at /devices/acurite.c. This
| vulnerability allows attackers to cause a Denial of Service (DoS) via
| a crafted file.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-27419
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-27419
[1] https://github.com/merbanan/rtl_433/issues/2012
[2] 
https://github.com/merbanan/rtl_433/commit/37455483889bd1c641bdaafc493d1cc236b74904

Regards,
Salvatore

Bug#1009787: ruby-nokogiri: CVE-2022-24836: Inefficient Regular Expression Complexity

[Salvatore Bonaccorso]

Source: ruby-nokogiri
Version: 1.13.1+dfsg-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for ruby-nokogiri.

CVE-2022-24836[0]:
| Nokogiri is an open source XML and HTML library for Ruby. Nokogiri
| ` v1.13.4` contains an inefficient regular expression that is
| susceptible to excessive backtracking when attempting to detect
| encoding in HTML documents. Users are advised to upgrade to Nokogiri
| `= 1.13.4`. There are no known workarounds for this issue.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-24836
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24836
[1] 
https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-crjr-9rc5-ghw8
[2] 
https://github.com/sparklemotion/nokogiri/commit/e444525ef1634b675cd1cf52d39f4320ef0aecfd

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1009786: request-tracker4: CVE-2021-38562 username enumeration via timing side-channel attack

[Dominic Hargreaves]

Source: request-tracker
Version: 4.4.4+dfsg-3
Severity: important

Per https://docs.bestpractical.com/release-notes/rt/4.4.5:

Security

* In previous versions, RT's native login system is vulnerable to user 
enumeration
through a timing side-channel attack. This means an external entity could try to
find valid usernames by attempting logins and comparing the time to evaluate 
each
login attempt for valid and invalid usernames. This vulnerability does not 
allow any
access to the RT system. This vulnerability is assigned CVE-2021-38562 and is 
fixed
in this release.

Bug#912682: e: Bug#912682: usefulness of this package?g

[Dominic Hargreaves]

On Sat, Jan 08, 2022 at 03:04:17AM +0100, gregor herrmann wrote:
> On Thu, 06 Jun 2019 10:56:07 +0100, Dominic Hargreaves wrote:
> 
> > Per our new policy[1], we'll remove this after July if no new
> > upstream update appears.
> > [1] 
> 
> Looks like this hasn't happened :)
> 
> I came to this bug as ExtUtils::ParseXS 3.44 was released yesterday.
> 
> So the current situation is:
> 
> We have libextutils-parsexs-perl 3.35-1 in unstable.
> 
> For ExtUtils::ParseXS in perl core we have
> 
>   v5.32.13.40  
> …
>   v5.34.03.43  
>   v5.35.03.43  
>   v5.35.13.43  
>   v5.35.23.43  
>   v5.35.33.43  
>   v5.35.43.44  
>   v5.35.53.44  
>   v5.35.63.44  
>   v5.35.73.44  
> 
> This means we could upload 3.44() to unstable, and after the
> transition to 5.34 this would still be ok, and after the migration to
> 5.36 in a couple of months we'd be in the same situation as now.
> 
> If I understand it correctly, ExtUtils::ParseXS is one of those
> dual-lifed modules which are primarily maintained in perl core, and
> then also released to the CPAN (ideally when a new perl is releaesed,
> right now a couple of months later), which means that there probably
> won't by any release where CPAN precedes perl core.
> 
> If this understanding is correct, than keeping libextutils-parsexs-perl
> as a separate package doesn't make a lot of sense (it will only be
> newer in the window between new upstream perl releases and our
> migrations in Debian), and I propose to remove it.

Good plan. I've just filed the removal request: https://bugs.debian.org/1009785

Bug#1009785: RM: libextutils-parsexs-perl -- ROM; Maintained primarily in src:perl

[Dominic Hargreaves]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-p...@lists.debian.org

Per #912682, this package doesn't have any real use.

Bug#1009784: src:scikit-learn: fails to migrate to testing for too long: FTBFS on half the architectures

[Paul Gevers]

Source: scikit-learn
Version: 1.0.1-1.1
Severity: serious
Control: close -1 1.0.2-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1003165

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:scikit-learn has been trying to migrate 
for 61 days [2]. Hence, I am filing this bug.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=scikit-learn



OpenPGP_signature
Description: OpenPGP digital signature

Bug#997994: Incompatibility between Net::FTP and IO::Socket::SSL

[Dominic Hargreaves]

Control: forwarded -1 https://github.com/steve-m-hay/perl-libnet/pull/40

On Thu, Oct 28, 2021 at 01:42:15PM +0200, Nathan MALO wrote:
> Package: perl-modules-5.32
> Version: 5.32.1-4+deb11u2
> 
> Hello,
> 
> I use backup-manager (conf attached) to upload tarballs to a FTPS
> destination.
> backup-manager use the perl package Net::FTP to handle ftp connections.
> It seems that the Net::FTP v3.11 perl package is incompatible with the
> IO::Socket:SSL perl package provided by the libio-socket-ssl-perl v2.069-1
> debian package.
> This version of Net::FTP uses a custom SSL_session_cache which lacks a
> 'del_session' routine invoked by IO::Socket:SSL.

...

> Net::FTP=GLOB(0x5646f37d5218)<<< 227 Entering Passive Mode
> (xx,xxx,xxx,xxx,xxx,xxx)
> Net::FTP=GLOB(0x5646f37d5218)>>> NLST
> Can't locate object method "del_session" via package
> "Net::FTP::_SSL_SingleSessionCache" at /usr/share/perl5/IO/Socket/SSL.pm
> line 3042.
> 
> 
> It seems to have been fixed in Net::FTP v3.13 by this commit :
> https://github.com/steve-m-hay/perl-libnet/commit/67281c8f29f081962cb7702a87c16a4473b936e8#diff-506ff1e09133b22009f33a185017deec1c04bce8e645f818c7c4fb2665c57ec3
> 
> This commit is present in perl 5.34, but I have not tested it.
> 
> Do you think that perl 5.34 could arrive in bullseye-backports ?
> 
> I am available for testing.
> I am using Debian GNU/Linux 11.1, kernel 5.10.0-9, and libc6
> 2.31-13+deb11u2.

Sorry for the delay in replying. Yes, I think this could be added to
a stable release. It looks like we should also include
https://github.com/steve-m-hay/perl-libnet/pull/41 too. I've enquired
about whether that can be released to CPAN.

Bug#1009783: synthv1 FTBFS: cp: cannot stat src/man1/ynthv1.fr.1: No such file or directory

[Adrian Bunk]

Source: synthv1
Version: 0.9.25-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=synthv1=sid

...
   debian/rules override_dh_auto_install
make[1]: Entering directory '/<>'
cp  /<>/src/man1/synthv1.1 /<>/src/man1/synthv1_jack.1
cp  /<>/src/man1/ynthv1.fr.1 
/<>/src/man1/synthv1_jack.fr.1
cp: cannot stat '/<>/src/man1/ynthv1.fr.1': No such file or 
directory
make[1]: *** [debian/rules:21: override_dh_auto_install] Error 1

Bug#965463: cntlm: diff for NMU version 0.92.3-1.1

[Joao Eriberto Mota Filho]

Control: tags 965463 + patch
Control: tags 965463 + pending

Dear maintainer,

I've prepared an NMU for cntlm (versioned as 0.92.3-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards,

Eriberto

diff -u cntlm-0.92.3/debian/changelog cntlm-0.92.3/debian/changelog
--- cntlm-0.92.3/debian/changelog
+++ cntlm-0.92.3/debian/changelog
@@ -1,3 +1,16 @@
+cntlm (0.92.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Using new DH level format. Consequently:
+  - debian/compat: removed.
+  - debian/control: changed from 'debhelper' to 'debhelper-compat' in
+Build-Depends field and bumped level to 13.
+  - debian/rules: using 'dh_prep' instead of 'dh_clean -k' because the
+'-k' option is not supported since compat 12.
+  - Closes: #965463
+
+ -- Joao Eriberto Mota Filho   Sun, 17 Apr 2022 15:10:54 
-0300
+
 cntlm (0.92.3-1) unstable; urgency=low
 
   * New upstream release. Closes: #652725, #588920.
diff -u cntlm-0.92.3/debian/control cntlm-0.92.3/debian/control
--- cntlm-0.92.3/debian/control
+++ cntlm-0.92.3/debian/control
@@ -2,7 +2,7 @@
 Section: net
 Priority: optional
 Maintainer: David Watson 
-Build-Depends: debhelper (>= 5)
+Build-Depends: debhelper-compat (= 13)
 Standards-Version: 3.9.3
 Vcs-Git: git://planetwatson.co.uk/cntlm
 Vcs-Browser: http://projects.planetwatson.co.uk/repositories/show/cntlm
reverted:
--- cntlm-0.92.3/debian/compat
+++ cntlm-0.92.3.orig/debian/compat
@@ -1 +0,0 @@
-5
diff -u cntlm-0.92.3/debian/rules cntlm-0.92.3/debian/rules
--- cntlm-0.92.3/debian/rules
+++ cntlm-0.92.3/debian/rules
@@ -47,7 +47,7 @@
 install: build
dh_testdir
dh_testroot
-   dh_clean -k 
+   dh_prep
dh_installdirs
 
# Add here commands to install the package into debian/cntlm.

Bug#1008573: gpg-agent -managed SSH keys stored in Yubikeys cannot be used with OpenSSH 8.9

[Vagrant Cascadian]

On 2022-04-18, Shengjing Zhu wrote:
> For anyone who suffers this, the workaround is:
>
> Add `KexAlgorithms=-sntrup761x25519-sha...@openssh.com` to ~/.ssh/config
> or `-o KexAlgorithms=-sntrup761x25519-sha...@openssh.com` to the command.

Thanks!  That works for me with openssh-client 1:9.0p1-1 and gpg-agent
2.2.27-3+b1.

Though for clarity, the ~/.ssh/config option is without the '=':

  KexAlgorithms -sntrup761x25519-sha...@openssh.com


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1009782: RFP: python3-showinfilemanager -- Open the system file manager and optionally select files

[Tino Mettler]

Package: wnpp
Severity: wishlist

* Package name: python3-showinfilemanager
  Version : 1.1.4
  Upstream Author : Damon Lynch 
* URL : https://github.com/damonlynch/showinfilemanager
* License : Expat
  Programming Lang: Python
  Description : Open the system file manager and optionally select files

 The point is not to open the files, but to select them in the file manager,
 thereby highlighting the files and allowing the user to quickly do something
 with them.
 .
 Functions when called from the command line or within a Python 3 script. Cross-
 platform, it supports 19 file managers, and works within the Windows Subsystem
 for Linux (WSL) versions 1 and 2.

The package is required for recent versions of rapid-photo-downloader. 
Currently,
rapid-photo-downloader is broken in Debian Sid (aborts at startup) due to 
Python changes.

python3-showinfilemanager is already packaged for Ubuntu.

https://packages.ubuntu.com/jammy/python3-showinfilemanager

Bug#1009781: ITP: safe-vdash -- the Safe Network - node dashboard

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: safe-vdash
  Version : 0.6.5
  Upstream Author : Mark 
* URL : https://github.com/happybeing/vdash
* License : GPL-3
  Programming Lang: Rust
  Description : the Safe Network - node dashboard

 vdash is a terminal based dashboard
 for monitoring SAFE Network nodes.
 .
 The Safe Network is a fully autonomous
 data and communications network.

This package will be maintained in the collaborative Debian area of
Salsa: https://salsa.debian.org/debian/safe-vdash


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmJcU14ACgkQLHwxRsGg
ASG1cA/+JfU7R06Km8QPbJgQFOOzgjJmJS44a2C7El11SK1nfgpQASdZopFCZd4Q
U8hezsmvLWKJyQYAXf553y9BE0x1hzJjGXnEmD913aRVz95d0S1uTJfPfIe6TAWF
9dug43zBXF6oijoUFBGbEHxR1gXPOCQJr5a4/ZVkLlIS7spiv/qtfeQmtwia7mcp
+uMMd5Ts711RwEx67n6NvDWCYY77KE8RhlwRRx2l9/g/+Pvs507qyHME+cDKEATg
HJCTOcBu8gr5EA8QijNiUo2gB57zOeQ99emVxC+kSfLGiUgwnnfc3+vn3zQlwCY/
1zLNzjgCPSmk3li34X8uHbrtfGgpUCa+o8Ks6VUsfGntuekXI1s5lPkwolUltX7o
Nsr/L33YKBL1N3ArK/8GJ43kZZl6Dvi4TcwNwdSrGT0gL0a8CzlmC3Ty3mtJxGpB
d23/n8wGgb24wl+h4nk64+ImutTxqa8Nv/Uq/6yfRC59tWPy2gd+hfzCuMG67VrP
Vs54lh3OGneAk6LnJwKvi33g6GjU5IbTnZaqnWU8jEa2+dYh394ucogTOP0r2wNz
B5hHOzLt7M8EMOUGHSsUHI1blEjh3rwjaMnwlrXcIjtGhrENYuc2XnRPihPBFrfD
ZNRVypdt60/SL9ISk7/09PTqZ2nLIyqbqTT1VJss+7LEn8+jq0U=
=LT1x
-END PGP SIGNATURE-

Bug#988905: [request-tracker-maintainers] Bug#988905:

[Dominic Hargreaves]

On Mon, Jul 12, 2021 at 01:27:42PM +1200, Michael Hudson-Doyle wrote:
> I see there is a fix in the git repo now. Are you planning an upload any
> time soon, or only after the buster release?

Hi Andrew

Is there anything blocking the upload of 5.0.2 now? Do you need any
help with this?

Cheers
Dominic

Bug#1008573: gpg-agent -managed SSH keys stored in Yubikeys cannot be used with OpenSSH 8.9

[Shengjing Zhu]

Hi,

For anyone who suffers this, the workaround is:

Add `KexAlgorithms=-sntrup761x25519-sha...@openssh.com` to ~/.ssh/config
or `-o KexAlgorithms=-sntrup761x25519-sha...@openssh.com` to the command.

-- 
Shengjing Zhu

Bug#1007260: performance regression due to linking against libnettle

[Michael Tokarev]

On Mon, 14 Mar 2022 23:58:37 +0100 "Steinar H. Gunderson"  
wrote:

Package: libunbound8
Version: 1.13.1-1
Severity: normal

Hi,

We were investigating a performance regression in production that crept
in at some point (we noticed by accident that something had become very slow
and started investigating). It turns out the culprit was libunbound; we do
a series of DNS lookups against localhost using ub_resolve(), and each of them
now takes a bit over 6 ms, which is huge for sending a UDP packet and getting
an answer from cache.

It turns out that some of this is because libunbound in Debian is now built
against libnettle (it wasn't when we built the system). The libnettle code in
util/random.c goes through a very slow reseeding phase; and worse, it does it
for both creating a context (we create a new one for each call, because
Reasons(TM)) and for each and every query (because ub_resolve() starts its own
worker, which reseeds). This reseeding is responsible for 60% of the CPU usage
or so, according to perf.


Wug.  This is awful.


According to pkg-config --libs libunbound, it seems one links to OpenSSL anyway,


This, if true, is a bug. libunbound itself does not link to openssl.

On my system with 1.13.1-1 version of libunbound, pkg-config does not
list openssl libs for it:

$ pkg-config --libs libunbound
-lunbound


so perhaps the simplest solution is to stop linking against libnettle?


Well, you already noted above the "Reasons(TM)". If you want to know
the particular reason for this, see #828699 which forced us to build
libunbound with nettle. It indeed is "Reasons(TM)" :)

Maybe someone from the Debian DNS team can add something here.
But it looks like we're sort of stuck here and should address
this on the nettle side.  Is it at all possible?  Or should
we reopen #828699?

BTW, Robert, do you remember why you had to split libunbound
build? The changelog/comments says this build is here to have
less dependencies, - which dependencies these are?


Optionally, one can use getentropy() (which calls getrandom()) unconditionally
on Linux, at least with modern kernels.

Doing the latter, and also reusing contexts (which is a pain for us, and I
don't think we had to do it before?) takes it down to a more reasonable 0.5 ms.


Well, these are workarounds, it seems...

Thanks!

/mjt

Bug#1003045: libreoffice: Since testing update on Jan 2, 2021, libreoffice doesn't start.

[yg2709]

Package: libreoffice
Followup-For: Bug #1003045
X-Debbugs-Cc: yg2...@hotmail.com

Dear Maintainer,

Probbing at a VM debian testing (12), checking with MATE (1.26.0),
 after upgrading all versions (from 1:7.2.4-1 thru 1:7.3.1-1), it opens 
sucessfully.

The real machine with version 1:7.2.4-1 and with apt-listbugs,
 is waiting to solve this issue.

Thank you very much.


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

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

Versions of packages libreoffice depends on:
hi  libreoffice-base1:7.2.4-1
hi  libreoffice-calc1:7.2.4-1
hi  libreoffice-core1:7.2.4-1
hi  libreoffice-draw1:7.2.4-1
hi  libreoffice-impress 1:7.2.4-1
hi  libreoffice-math1:7.2.4-1
hi  libreoffice-report-builder-bin  1:7.2.4-1
hi  libreoffice-writer  1:7.2.4-1
hi  python3-uno 1:7.2.4-1

Versions of packages libreoffice recommends:
ii  fonts-crosextra-caladea 20130214-2.1
ii  fonts-crosextra-carlito 20130920-1.1
ii  fonts-dejavu2.37-2
ii  fonts-liberation1:1.07.4-11
ii  fonts-liberation2   2.1.5-1
ii  fonts-linuxlibertine5.3.0-6
ii  fonts-noto-core 20201225-1
pn  fonts-noto-extra
ii  fonts-noto-mono 20201225-1
ii  fonts-noto-ui-core  20201225-1
ii  fonts-sil-gentium-basic 1.102-1.1
hi  libreoffice-java-common 1:7.2.4-1
hi  libreoffice-nlpsolver   0.9+LibO7.2.4-1
hi  libreoffice-report-builder  1:7.2.4-1
hi  libreoffice-script-provider-bsh 1:7.2.4-1
hi  libreoffice-script-provider-js  1:7.2.4-1
hi  libreoffice-script-provider-python  1:7.2.4-1
pn  libreoffice-sdbc-mysql  
hi  libreoffice-sdbc-postgresql 1:7.2.4-1
hi  libreoffice-wiki-publisher  1.2.0+LibO7.2.4-1

Versions of packages libreoffice suggests:
ii  cups-bsd2.4.1op1-2
ii  default-jre [java8-runtime] 2:1.11-72
ii  firefox-esr 91.8.0esr-1
ii  ghostscript 9.55.0~dfsg-3
ii  gnupg   2.2.27-3
ii  gpa 0.10.0-3+b1
ii  gstreamer1.0-libav  1.20.1-1
ii  gstreamer1.0-plugins-bad1.20.1-1
ii  gstreamer1.0-plugins-base   1.20.1-1
ii  gstreamer1.0-plugins-good   1.20.1-1
ii  gstreamer1.0-plugins-ugly   1.20.1-1
ii  hunspell-en-us [hunspell-dictionary]1:2020.12.07-2
ii  hyphen-en-us [hyphen-hyphenation-patterns]  2.8.8-7
ii  hyphen-es [hyphen-hyphenation-patterns] 1:7.2.0-2
ii  imagemagick 8:6.9.11.60+dfsg-1.3+b2
ii  imagemagick-6.q16 [imagemagick] 8:6.9.11.60+dfsg-1.3+b2
ii  libgl1  1.4.0-1
pn  libofficebean-java  
pn  libreoffice-gnome | libreoffice-plasma  
pn  libreoffice-grammarcheck
hi  libreoffice-help-en-us [libreoffice-help]   1:7.2.4-1
hi  libreoffice-help-es [libreoffice-help]  1:7.2.4-1
hi  libreoffice-l10n-es [libreoffice-l10n]  1:7.2.4-1
hi  libreoffice-librelogo   1:7.2.4-1
ii  libsane11.1.1-5
ii  libxrender1 1:0.9.10-1
ii  myspell-es [myspell-dictionary] 1.11-19
ii  mythes-en-us [mythes-thesaurus] 1:7.2.0-2
ii  mythes-es [mythes-thesaurus]1:7.2.0-2
pn  openclipart-libreoffice 
ii  openjdk-11-jre [java8-runtime]  11.0.14.1+1-1
ii  pstoedit3.78-1
ii  thunderbird 1:91.8.0-1
pn  unixodbc

Versions of packages libreoffice-core depends on:
ii  fontconfig  2.13.1-4.4
hi  fonts-opensymbol2:102.12+LibO7.2.4-1
ii  libboost-locale1.74.0   1.74.0-14
ii  libc6   2.33-7
ii  libcairo2   1.16.0-5
ii  libclucene-contribs1v5  2.3.3.4+dfsg-1+b1
ii  libclucene-core1v5  2.3.3.4+dfsg-1+b1
ii  libcups22.4.1op1-2
ii  libcurl3-gnutls 7.82.0-2
ii  libdbus-1-3 1.14.0-1
ii  libdconf1   0.40.0-3
ii  libeot0 0.01-5+b1
ii  libepoxy0   1.5.10-1
ii  

Bug#1009779: ITP: doas-portable -- A port of OpenBSD's doas which runs on FreeBSD, Linux, NetBSD, and illumos

[Scupake]

Package: wnpp
Severity: wishlist

* Package name: doas-portable
  Version : 6.3p6
  Upstream Author : Jesse Smith
* URL : https://github.com/slicer69/doas
* License : BSD 2-Clause
  Programming Lang: C
  Description : A port of OpenBSD's doas which runs on multiple OSes

A portable version of OpenBSD's doas, and an alternative to sudo and the
already existing doas package (will soon be renamed to OpenDoas).


signature.asc
Description: PGP signature

Bug#1009778: linux-image-5.10.0-13-amd64: NETDEV WATCHDOG stack trace

[js1]

Package: src:linux
Version: 5.10.106-1
Severity: normal
X-Debbugs-Cc: sujiannm...@gmail.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***
The router that the laptop is connected to lost power


-- Package-specific info:
** Version:
Linux version 5.10.0-13-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.106-1 (2022-03-17)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-13-amd64 
root=UUID=27876db4-6b63-4db1-b0bd-b8c9522ced14 ro

** Tainted: W (512)
 * kernel issued warning

** Kernel log:
[1006084.072858] r8169 :01:00.0 enp1s0: Link is Down
[1006085.740273] r8169 :01:00.0 enp1s0: Link is Up - 100Mbps/Full - flow 
control rx/tx
[1006156.165124] [ cut here ]
[1006156.165283] NETDEV WATCHDOG: enp1s0 (r8169): transmit queue 0 timed out
[1006156.165437] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:467 
dev_watchdog+0x24d/0x260
[1006156.165581] Modules linked in: tcp_diag udp_diag inet_diag md4 
sha512_ssse3 sha512_generic nls_utf8 cifs libarc4 dns_resolver fscache libdes 
cmac algif_hash tun algif_skcipher af_alg bnep nft_chain_nat xt_MASQUERADE 
nf_nat nft_counter xt_tcpudp xt_state xt_conntrack nf_conntrack nf_defrag_ipv6 
amdgpu nf_defrag_ipv4 nft_compat nf_tables libcrc32c crc32c_generic gpu_sched 
nfnetlink uvcvideo nls_ascii nls_cp437 videobuf2_vmalloc videobuf2_memops 
videobuf2_v4l2 vfat fat videobuf2_common videodev mc rtsx_usb_ms memstick 
snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi 
snd_hda_intel snd_intel_dspcfg btusb soundwire_intel 
soundwire_generic_allocation snd_soc_core btrtl btbcm snd_compress btintel 
soundwire_cadence bluetooth snd_hda_codec snd_hda_core edac_mce_amd snd_hwdep 
jitterentropy_rng soundwire_bus drbg kvm ansi_cprng snd_pcm irqbypass 
ecdh_generic ecc snd_timer snd ghash_clmulni_intel crc16 soundcore 
ideapad_laptop aesni_intel radeon sparse_keymap rfkill libaes
[1006156.166056]  crypto_simd cryptd sg wmi sp5100_tco glue_helper watchdog 
joydev ttm pcspkr serio_raw evdev drm_kms_helper ccp cec efi_pstore 
i2c_algo_bit rng_core fam15h_power k10temp acpi_cpufreq button ac drm fuse 
configfs efivarfs ip_tables x_tables autofs4 jfs rtsx_usb_sdmmc mmc_core 
rtsx_usb sd_mod sr_mod cdrom t10_pi crc_t10dif crct10dif_generic ahci xhci_pci 
libahci xhci_hcd libata r8169 ehci_pci ehci_hcd realtek crct10dif_pclmul 
mdio_devres crct10dif_common crc32_pclmul psmouse usbcore crc32c_intel scsi_mod 
i2c_piix4 libphy usb_common battery video
[1006156.168484] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.10.0-13-amd64 #1 
Debian 5.10.106-1
[1006156.168626] Hardware name: LENOVO INVALID/VIUU4, BIOS 1QCN32WW 08/18/2016
[1006156.168752] RIP: 0010:dev_watchdog+0x24d/0x260
[1006156.168843] Code: c9 c9 fd ff eb a9 4c 89 f7 c6 05 d8 61 10 01 01 e8 48 9a 
fa ff 44 89 e9 4c 89 f6 48 c7 c7 18 b9 56 b8 48 89 c2 e8 32 3b 14 00 <0f> 0b eb 
8a 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44
[1006156.169103] RSP: 0018:bac0800fceb8 EFLAGS: 00010286
[1006156.169231] RAX:  RBX: 9fac50be1200 RCX: 

[1006156.169286] RDX: 9fac5b4ac760 RSI: 9fac5b49ca00 RDI: 
0300
[1006156.169430] RBP: 9fac408e63dc R08:  R09: 
bac0800fccd8
[1006156.169553] R10: bac0800fccd0 R11: b8acb408 R12: 
9fac408e6480
[1006156.169678] R13:  R14: 9fac408e6000 R15: 
9fac50be1280
[1006156.169802] FS:  () GS:9fac5b48() 
knlGS:
[1006156.169930] CS:  0010 DS:  ES:  CR0: 80050033
[1006156.170068] CR2: 7f74c913a5e0 CR3: 0001031d6000 CR4: 
000406e0
[1006156.170175] Call Trace:
[1006156.170297]  
[1006156.170348]  ? pfifo_fast_enqueue+0x150/0x150
[1006156.170382]  call_timer_fn+0x29/0xf0
[1006156.170519]  __run_timers.part.0+0x1d3/0x240
[1006156.173027]  ? ktime_get+0x38/0xa0
[1006156.181023]  ? native_x2apic_icr_read+0x10/0x10
[1006156.185075]  ? lapic_next_event+0x1d/0x20
[1006156.189023]  ? clockevents_program_event+0x8d/0xf0
[1006156.197018]  run_timer_softirq+0x26/0x50
[1006156.201039]  __do_softirq+0xc5/0x275
[1006156.205026]  asm_call_irq_on_stack+0x12/0x20
[1006156.213071]  
[1006156.217025]  do_softirq_own_stack+0x37/0x40
[1006156.221024]  irq_exit_rcu+0x8e/0xc0
[1006156.229089]  sysvec_apic_timer_interrupt+0x36/0x80
[1006156.233023]  asm_sysvec_apic_timer_interrupt+0x12/0x20
[1006156.237016] RIP: 0010:cpuidle_enter_state+0xc7/0x350
[1006156.241024] Code: 8b 3d 1d 23 57 48 e8 28 d8 a1 ff 49 89 c5 0f 1f 44 00 00 
31 ff e8 39 e3 a1 ff 45 84 ff 0f 85 fa 00 00 00 fb 66 0f 1f 

Bug#1007924: RFS: rshell/0.0.31-1 [ITP] -- Remote shell for working with MicroPython boards

[Dave Jones]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "rshell":

 * Package name: rshell
   Version : 0.0.31-1
   Upstream Author : https://github.com/dhylands/rshell
 * URL : https://github.com/dhylands/rshell
 * License : MIT
 * Vcs : https://salsa.debian.org/python-team/packages/rshell
   Section : python

The source builds the following binary packages:

  python3-rshell - Remote shell for working with MicroPython boards - python3 
library
  rshell - Remote shell for working with MicroPython boards

To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/rshell/

Alternatively, you can download the package with 'dget' using this 
command:


  dget -x 
https://mentors.debian.net/debian/pool/main/r/rshell/rshell_0.0.31-1.dsc

Changes for the initial release:

 rshell (0.0.31-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1007924)

Thanks for you consideration!

--
  Dave Jones



signature.asc
Description: PGP signature

Bug#1008016: ITP: safe-network -- network routing and service daemon for the Safe Network

[Jonas Smedegaard]

Needs embedding 231 crates; Builds in ~60 minutes; Runs but actual 
connection to and ineraction with some network not yet tested

The packaging draft at https://salsa.debian.org/debian/safe-network now 
succesfully builds a working set of packages - safe-network-node and 
safe-network-cli.  It is a dirty build: Many crates not yet packaged in 
Debian are needed, so this is not acceptable officially in Debian yet.

Main task now, besides keeping the packaging up-to-date with upstream 
releases, is to patch the code to align closer with Rust crates 
available in Debian, to reduce the amount of reverse dependencies 
needing packaging before this can be released officially in Debian.

You can help by testing this draft package (either build it yourself or 
tell if you want access to binary packages I've built) and provide 
feedback on how well it works for you.

You can also help by joining the Rust team in Debian and contribute to 
unbreaking/upgrading/adding needed crate packages, as listed here: 
https://salsa.debian.org/debian/safe-network/-/blob/debian/latest/debian/TODO


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1004874: dialog: --max-input ignores values higher than 2048

[Thomas Dickey]

fixed in 1.3.20220414

https://invisible-island.net/dialog/CHANGES.html#t20220414

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#1004868: dialog: menu segfaults when resizing

[Thomas Dickey]

fixed in 1.3.20220404

https://invisible-island.net/dialog/CHANGES.html#t20220404

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#1003185: dialog: Dialog segfaults when passing large line to editbox

[Thomas Dickey]

fixed in 1.3.20220117

https://invisible-island.net/dialog/CHANGES.html#t20220117

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#997851: Update on doas package status

[Jesse Smith]

On 2022-04-17 11:49 a.m., Scupake wrote:
> Hello,
>
> I'm very very sorry for taking an unreasonable time to reply and resolve
> this issue. I will try to be more active from now on.
>
> I'm also currently packaging slicer69/doas, though I still haven't
> decided on a name, I would like to use "doas-portable" if it is at least
> mentioned in upstream's README file.
>

I like the name "doas-portable". I'd be happy to add that to the README
file so Debian users know about it and can find it under that name.

- Jesse

Bug#997851: Update on doas package status

[Scupake]

Hello,

I'm very very sorry for taking an unreasonable time to reply and resolve
this issue. I will try to be more active from now on.

I'm also currently packaging slicer69/doas, though I still haven't
decided on a name, I would like to use "doas-portable" if it is at least
mentioned in upstream's README file.

-- 
Scupake :D
4737A2C0A769B53AE82F77922BD8BE5CDD5ADA16


signature.asc
Description: PGP signature

Bug#1009769: libhoel1.4: ABI break: h_exec_query_sqlite was dropped

[Andreas Metzler]

On 2022-04-17 Nicolas Mora  wrote:
> Hello,

> Le 2022-04-17 à 01 h 32, Andreas Metzler a écrit :

> > i.e. the symbol h_exec_query_sqlite was dropped from the library ABI.
> > This breaks all reverse dependencies built against 1.4.18, e.g. glewlwyd
> > is now broken:
> > (sid)ametzler@argenau:/dev/shm/GLEWY$ ldd -r /usr/bin/glewlwyd | tail -n1
> > undefined symbol: h_exec_query_sqlite   (/usr/bin/glewlwyd)

> Thanks,

> the symbol has changed its name, but a macro was added to make it source
> compatible:
> https://sources.debian.org/src/hoel/1.4.20-1/include/hoel.h/#L534

> Therefore the package glewlwyd-2.6.2 still builds with this new source.
> Glewlwyd 2.7.0 will use the new function h_execute_query_sqlite instead.

Hello Nicolas,

Yes, a rebuild will get a binary which works against the new
library, however (partial) upgrades from bookworm won't work.

BTW, the symbol file seems to be wrong:
| h_execute_query_sqlite@Base 1.4.15
the symbol is not available in 1.4.15, so the rebuilt glewlwyd would
depend on the libhoel1.4 (>= 1.14) instead of >= 1.18.

> What is the best approach to close this bug?

I think the first step would be to talk to upstream. One should not
break the ABI of a shraed library without need, when it must be done it
should happen properly with a soname bump.

The proper and easy fix would now be
for them to provide both symbols (Not a #define, but e.g. the deprecated
function calling the new one.)

> - Should I patch hoel package to replace the #define h_exec_query_sqlite()
> with a redefinition of h_exec_query_sqlite()?

Yeah, that is what I exactly thought upstream should do. ;-) Like

int h_exec_query_sqlite(const struct _h_connection * conn, const char * query)
   { return h_execute_query_sqlite(  }


> - Should I re-upload glewlwyd 2.6.2 to force a rebuild?

Afaict libhoel1.4 has only got glewlwyd as reverse depends? As plan B
if upstream is unwilling you could either patch libhoel (with the
downside that it would not be cross distribution compatible) or simply
make two new sourceful uploads, with
a) let new libhoel1.4 Breaks: glewlwyd (<= 2.6.2-2~) and have a fixed
symbol file. and
b) glewlwyd Build-Depend-ing on libhoel-dev >= 1.18-2 to get the correct
 Depends on  libhoel1.4 (>= 1.18-2).

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#952704: libqt5printsupport5: Printer and queue attributes not available

[Brian Potkin]

tags 952704 upstream
found 952704 5.15.2+dfsg-16
thanks


In my opinion, the Qt print dialog should support the CUPS temporary
queue facility correctly. CUPS has APIs to do this. There shoudn't be
any need to set up a permanent manual queue or have cups-browsed add
a permanent queue in order to get remote queue or printer attributes 

Cheers,

Brian.

Bug#965455: chrootuid: diff for NMU version 1.3-6.1

[Eriberto]

Em dom., 17 de abr. de 2022 às 05:48, Javier Fernandez-Sanguino
 escreveu:
>
> Dear João,
>
> Thanks for preparing, the patch looks ok to me.
>
> Saludos,
>
> Javier

Thanks Javier! I will kill the delay.

Have a nice day.

Regards,

Eriberto

Bug#1009777: ITP: fcitx5-solarized -- Fcitx5 theme based on solarized color

[Boyuan Yang]

Package: wnpp
Severity: wishlist

* Package name: fcitx5-solarized
  Version : 0.1
  Upstream Author : Mingye Chen 
* URL : https://github.com/mingyech/fcitx5-solarized
* License : Expat
  Programming Lang: N/A
  Description : Fcitx5 theme based on solarized color

 This package provides the solarized color theme for fcitx5 input method
 framework.

I plan to maintain this package under Debian Input Method Team:
https://salsa.debian.org/input-method-team/fcitx5-solarized .

Thanks,
Boyuan Yang


signature.asc
Description: This is a digitally signed message part

Bug#1009776: podman: Packages uidmap and slirp4netns should be full dependencies

[Cal.]

My thinking was more along the lines of "If I'm going to run this as
root, I might as well run docker." And I saw podman rootless mode
kinda equivalent to the docker group when using docker. (But I am a
novice with podman, I pretty much just discovered it.)

If you want some comparisons, on Fedora podman rootless just works (I
don't actually know want dependencies they install, because I use it
to run one-off containers on my laptop -- the servers run docker)

The errors were not that cryptic by themselves but required some
googling to understand what binaries were missing and what packages
provided them. I think adding some instructions on the wiki
(https://wiki.debian.org/Podman) should be enough if dependencies are
to be minimal.

On Sun, 17 Apr 2022 at 15:20, Reinhard Tartler  wrote:
>
> Control: tag -1 upstream
> Control: severity -1 minor
>
> On Sun, Apr 17, 2022 at 9:09 AM Giuseppe  
> wrote:
>>
>> Package: podman
>> Version: 3.0.1+dfsg1-3+deb11u1
>> Severity: important
>> X-Debbugs-Cc: peppecal+debianb...@gmail.com
>>
>> Dear Maintainer,
>>
>> I really think packages uidmap and slirp4netns should be full-fledged 
>> dependencies for podman.
>>
>> I say this because after installing podman and trying to run some containers 
>> in rootless mode I found myself fighting cryptic error messages that were 
>> solved by installing those two packages.
>>
>
> My thinking when choosing dependencies was:
>
> - podman has significant performance benefits when running as root
> - the podman package dependencies should be as minimal as possible, in 
> particular on system where podman is running as root.
>
> I do sympathize with the cryptic error message. May I ask you to forward your 
> suggestion on wording directly to upstream at 
> https://github.com/containers/podman/issues ?
>
> Please do let me know the  upstream bug number and your thoughts on this.
>
> Best,
> -rt
>

Bug#1009776: podman: Packages uidmap and slirp4netns should be full dependencies

[Reinhard Tartler]

Control: tag -1 upstream
Control: severity -1 minor

On Sun, Apr 17, 2022 at 9:09 AM Giuseppe 
wrote:

> Package: podman
> Version: 3.0.1+dfsg1-3+deb11u1
> Severity: important
> X-Debbugs-Cc: peppecal+debianb...@gmail.com
>
> Dear Maintainer,
>
> I really think packages uidmap and slirp4netns should be full-fledged
> dependencies for podman.
>
> I say this because after installing podman and trying to run some
> containers in rootless mode I found myself fighting cryptic error messages
> that were solved by installing those two packages.
>
>
My thinking when choosing dependencies was:

- podman has significant performance benefits when running as root
- the podman package dependencies should be as minimal as possible, in
particular on system where podman is running as root.

I do sympathize with the cryptic error message. May I ask you to forward
your suggestion on wording directly to upstream at
https://github.com/containers/podman/issues ?

Please do let me know the  upstream bug number and your thoughts on this.

Best,
-rt

Bug#1009776: podman: Packages uidmap and slirp4netns should be full dependencies

[Giuseppe]

Package: podman
Version: 3.0.1+dfsg1-3+deb11u1
Severity: important
X-Debbugs-Cc: peppecal+debianb...@gmail.com

Dear Maintainer,

I really think packages uidmap and slirp4netns should be full-fledged 
dependencies for podman.

I say this because after installing podman and trying to run some containers in 
rootless mode I found myself fighting cryptic error messages that were solved 
by installing those two packages.

Thank you for all you're doing. 

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

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

Versions of packages podman depends on:
ii  conmon   2.0.25+ds1-1.1
ii  containernetworking-plugins  0.9.0-1+b6
ii  crun 0.17+dfsg-1
ii  golang-github-containers-common  0.33.4+ds1-1+deb11u1
ii  init-system-helpers  1.60
ii  iptables 1.8.7-1
ii  libc62.31-13+deb11u3
ii  libdevmapper1.02.1   2:1.02.175-2.1
ii  libgpgme11   1.14.0-1+b2
ii  libseccomp2  2.5.1-1+deb11u1

Versions of packages podman recommends:
pn  buildah   
pn  catatonit | tini | dumb-init  
pn  fuse-overlayfs
pn  golang-github-containernetworking-plugin-dnsname  
ii  slirp4netns   1.0.1-2
ii  uidmap1:4.8.1-1

Versions of packages podman suggests:
pn  containers-storage  
ii  docker-compose  1.25.0-1

-- no debconf information

Bug#1009243: libapache2-mod-python: (autopkgtest) needs update for python3.10

[Bastian Germann]

On Sat, 9 Apr 2022 18:28:23 +0200 Paul Gevers  wrote:
We are in the transition of making python3.10 the default Python 
versions [0]. With a recent upload of python3-defaults the autopkgtest 
of libapache2-mod-python fails in testing when that autopkgtest is run 
with the binary packages of python3-defaults from unstable.


PythonHandler mod_python.publisher: Traceback (most recent call last):
mod_python/apache.py, line 398, in HandlerDispatch\nresult = obj(req)
mod_python/publisher.py", line 222, in handler\npublished = 
publish_object(req, object)
mod_python/publisher.py", line 440, in publish_object\nif _callable(obj):
mod_python/publisher.py", line 54, in _callable\nreturn (isinstance(obj, 
collections.Callable)
AttributeError: module 'collections' has no attribute 'Callable'

The package obviously has no support for python3.10; there are python3.9 bugs 
as well.
It is abandoned upstream. I suggest filing a RM bug for this package.

Bug#1009775: ITP: ruby-net-smtp -- library to send Internet mail via SMTP, the Simple Mail Transfer Protocol

[Georg Faerber]

Package: wnpp
Owner: Georg Faerber 
Severity: wishlist
X-Debbugs-CC: debian-r...@lists.debian.org
Control: affects -1 schleuder
Control: block -1 by 1009774

Package name: ruby-net-smtp
Version : 0.3.1
Upstream Author : Yukihiro Matsumoto, Minero Aoki
URL : https://github.com/ruby/net-smtp
License : BSD-2-clause
Programming Lang: Ruby
Description : library to send Internet mail via SMTP, the Simple Mail 
Transfer Protocol

This package will provide functionality to send Internet mail via SMTP,
the Simple Mail Transfer Protocol. It used to be part of the Ruby
standard library before Ruby 3.1, and was extracted to a standalone
package.

It depends on ruby-net-protocol.

This package will be maintained within the Debian Ruby team.

Bug#1009774: ITP: ruby-net-protocol -- Internal class for the other net-* libraries

[Georg Faerber]

Package: wnpp
Owner: Georg Faerber 
Severity: wishlist
X-Debbugs-CC: debian-r...@lists.debian.org
Control: affects -1 schleuder

Package name: ruby-net-protocol
Version : 0.1.3
Upstream Author : Yukihiro Matsumoto, Minero Aoki
URL : https://github.com/ruby/net-protocol
License : BSD-2-clause
Programming Lang: Ruby
Description : internal class for the other net-* libraries

This package will provide an internal class for the other net-*
libraries, for example ruby-net-smtp. It used to be part of the Ruby
standard library before Ruby 3.1, and was extracted to a standalone
package.

It will become a dependency of ruby-net-smtp.

This package will be maintained within the Debian Ruby team.

Bug#1009769: libhoel1.4: ABI break: h_exec_query_sqlite was dropped

[Nicolas Mora]

Hello,

Le 2022-04-17 à 01 h 32, Andreas Metzler a écrit :


i.e. the symbol h_exec_query_sqlite was dropped from the library ABI.
This breaks all reverse dependencies built against 1.4.18, e.g. glewlwyd
is now broken:
(sid)ametzler@argenau:/dev/shm/GLEWY$ ldd -r /usr/bin/glewlwyd | tail -n1
undefined symbol: h_exec_query_sqlite   (/usr/bin/glewlwyd)


Thanks,

the symbol has changed its name, but a macro was added to make it source 
compatible: 
https://sources.debian.org/src/hoel/1.4.20-1/include/hoel.h/#L534


Therefore the package glewlwyd-2.6.2 still builds with this new source. 
Glewlwyd 2.7.0 will use the new function h_execute_query_sqlite instead.


What is the best approach to close this bug?
- Should I patch hoel package to replace the #define 
h_exec_query_sqlite() with a redefinition of h_exec_query_sqlite()?

- Should I re-upload glewlwyd 2.6.2 to force a rebuild?

Thanks in advance for your advice

/Nicolas

Bug#1009447: iddawc: FTBFS: Errors while running CTest

[Nicolas Mora]

Hello,

On Tue, 12 Apr 2022 20:41:02 +0200 Lucas Nussbaum  wrote:


During a rebuild of all packages in sid, your package failed to build
on amd64.


This has been fixed in iddawc-1.1.2-2, thanks!

/Nicolas

Bug#1009668: irqtop/lsirq: missing commands in util-linux package

[Axel Beckert]

Hi Chris,

TL;DR: What if we just make util-linux-extra taking over the binary
path /usr/bin/irqtop and the irqtop(-nf) package providing a binary
name irqtop-nf in the future plus leaving the remainder to
package descriptions and NEWS.Debian?

Chris Hofstaedtler wrote:
> > Regarding the ruby-written irqtop:
> > 
> > * It is currently endangered to be removed from testing by the
> >   horribly outdated ruby-curses (https://bugs.debian.org/958973) in
> >   Debian which is also no more maintained; see
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959115#10 and
> >   https://bugs.debian.org/1009727 (Christian: I X-Debbugs-Cc'ed you on
> >   #1009727 for that and because I know that you're also active in
> >   Debian's Ruby packaging.)
> 
> (I understand this is "temporarily fixed" now.)

Indeed. I was very surprised and happy that my poking of the (not-)
maintainers actually triggered an upload. :-)

> > * I think we should also try to use /etc/alternatives/irqtop +
> >   update-alternatives with irqtop from util-linux-extra having the
> >   higher priority so that those who install both, get the probably
> >   more expected util-linux-extra's implementation by default.
> 
> > In case you agree, I'd upload an updated iptables-netflow source
> > package to Debian Experimental implementing these changes so we can
> > cross-installability and upgrade paths.
> 
> I think I agree with almost everything here. There is a small caveat
> with regards to update-alternatives:
> 
> 1) general question: do we get anything "actually useful" out of
> using u-a?

The sole thing we get off this is that users who have used the
ruby-written irqtop beforehand don't have to learn a new name.

There is one other possibility to provide that: Using dpkg-divert
instead of update-alternatives with util-linux(-extra) shipping irqtop
and irqtop diverting it away to irqtop-ul iff both packages are
installed.

This would have advantages and disadvantages:

Advantage:

* No special handling needed at all for util-linux or
  util-linux-extra.

Disadvantages:

* Less choice for the admin which package provides irqtop if both are
  installed. Then again that case usually only happens if someone has
  already installed irqtop (the package, i.e. the ruby-written one) or
  installs it on purpose.

* The concept of dpkg-divert seems less well-known than
  update-alternatives and might confuse users more often if they
  expect util-linux's irqtop in that package.

Most of the disadvantages could be fixed with making it clear in the
package description of the irqtop package that it's not util-linux's
irqtop implementation but a different one existing for a longer time
already.

Then again, I don't think the gain isn't worth the effort. See below

So that confusion (either with dpkg-divert or with renaming the
ruby-written irqtop binary to irqtop-nf and keeping it there) should
be limited to those users knowning about the ruby-written irqtop
implementation and not reading package descriptions and not reading
NEWS.Debian entries — which should the a very small group of users.
:-)

> Regardless of using u-a, (I think) util-linux would need to grow a
> versioned Conflicts/Replaces/Breaks on irqtop.

That (or for util-linux-extra) is needed anyways. (Except maybe if
src:util-linux produces an irqtop package, but nobody seems to have
considered that so far.)

> 2) If we settle on update-alternatives, irqtop from util-linux
> really needs to be (and stay) in util-linux-extra.

I thought that was your plan anyways.

> util-linux is Essential: yes. -> I want util-linux to be relatively small, 
> contain only utilities that are useful on -all- installations, and
> it should be "postinst free".

I see.

> All of this pretty much already says util-linux-extra should have
> irqtop, and not util-linux.

Ack.

> So, if we go with update-alternatives, which program names do you
> propose? irqtop-nf and irqtop-ul?

Yes.

> There is some precedent to use "." instead of "-", but probably
> either are fine.

Just wanted to note the same, too. But I personally prefer the dash.
But see below.

Anyway, given all those thoughts and the context of util-linux being
an essential package, I changed my opinion and think we should proceed
as follows:

> > * Renaming the current irqtop package (and binary) to irqtop-nf.
> > 
> > * Making a "irqtop" a transitional package which pulls in either
> >   irqtop-nf or util-linux-extra , i.e. has a
> > 
> > Depends: irqtop-nf | util-linux-extra
> > 
> >   in its control file. That way those who upgrade automatically get
> >   the same implementation as before. But those who look at the package
> >   see that there are two choices.
> > 
> > * After the Bookworm release, the "irqtop" package should be removed
> >   and provided by the util-linux-extra package, so that those who do
> >   "apt install irqtop" actually get the more expected implementation
> >   from util-linux.

So far the same.

* I will add a note to the 

Bug#1008062: gnutls28 3.6.7-4+deb10u8 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1008062 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: gnutls28
Version: 3.6.7-4+deb10u8

Explanation: fix test suite when combined with OpenSSL 1.1.1e or newer

Bug#1008056: libnet-ssleay-perl 1.85-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1008056 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: libnet-ssleay-perl
Version: 1.85-2+deb10u1

Explanation: fix test failures with OpenSSL 1.1.1n

Bug#1007762: nginx 1.18.0-6.1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1007762 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: nginx
Version: 1.18.0-6.1+deb11u1

Explanation: fix crash when libnginx-mod-http-lua is loaded and 
init_worker_by_lua* is used

Bug#1006316: libapache2-mod-auth-openidc 2.4.9.4-0+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1006316 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: libapache2-mod-auth-openidc
Version: 2.4.9.4-0+deb11u1

Explanation: new upstream stable release; fix open redirect issue 
[CVE-2021-39191]; fix crash on reload / restart

Bug#1006504: bash 5.1-2+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1006504 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: bash
Version: 5.1-2+deb11u1

Explanation: fix 1-byte buffer overflow read, causing corrupted multibyte 
characters in command substitutions

Bug#1009668: irqtop/lsirq: missing commands in util-linux package

[Chris Hofstaedtler]

Hi Axel,

* Axel Beckert  [220415 17:53]:
> Hi Chris,
> 
[comparison between irqtop variants, my thanks to both of you]

> Anyway, IMHO we should:
> 
> * Figure out how to get the util-linux implementation into Debian
>   proper.
> 
> * irqtop from util-linux should in some way become the future default,
>   as its probably what the user usually expects. The ruby-written
>   irqtop is only a niche tool written for analysing the performace of
>   the ipt_NETFLOW.ko iptables plugin kernel module. (But seems to have
>   been useful elsewhere, too, as probably shown by the fact that
>   util-linux added a similar tool, which is probably less focussed on
>   that one job. :-)
> 
> Regarding the ruby-written irqtop:
> 
> * It is currently endangered to be removed from testing by the
>   horribly outdated ruby-curses (https://bugs.debian.org/958973) in
>   Debian which is also no more maintained; see
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959115#10 and
>   https://bugs.debian.org/1009727 (Christian: I X-Debbugs-Cc'ed you on
>   #1009727 for that and because I know that you're also active in
>   Debian's Ruby packaging.)

(I understand this is "temporarily fixed" now.)

> * It has a higher popularity than I expected:
>   
> https://qa.debian.org/popcon-graph.php?packages=irqtop_installed=on_vote=on_legend=on=1
> 
> Because I as user and Linux admin prefer having choice and because the
> two irqtop implementations seem to rather different, I really would
> prefer to keep the ruby-written irqtop in Debian nevertheless at least
> for now.

Right.

> My currently preferred variant (probably needs to be a bit more
> polished) to go forward is:
> 
> * Renaming the current irqtop package (and binary) to irqtop-nf.
> 
> * Making a "irqtop" a transitional package which pulls in either
>   irqtop-nf or util-linux-extra , i.e. has a
> 
> Depends: irqtop-nf | util-linux-extra
> 
>   in its control file. That way those who upgrade automatically get
>   the same implementation as before. But those who look at the package
>   see that there are two choices.
> 
> * After the Bookworm release, the "irqtop" package should be removed
>   and provided by the util-linux-extra package, so that those who do
>   "apt install irqtop" actually get the more expected implementation
>   from util-linux.
> 
> * I think we should also try to use /etc/alternatives/irqtop +
>   update-alternatives with irqtop from util-linux-extra having the
>   higher priority so that those who install both, get the probably
>   more expected util-linux-extra's implementation by default.

> In case you agree, I'd upload an updated iptables-netflow source
> package to Debian Experimental implementing these changes so we can
> cross-installability and upgrade paths.

I think I agree with almost everything here. There is a small caveat
with regards to update-alternatives:

1) general question: do we get anything "actually useful" out of
using u-a?
Regardless of using u-a, (I think) util-linux would need to grow a
versioned Conflicts/Replaces/Breaks on irqtop.

2) If we settle on update-alternatives, irqtop from util-linux
really needs to be (and stay) in util-linux-extra. Some background:
util-linux is Essential: yes. -> I want util-linux to be relatively small, 
contain only utilities that are useful on -all- installations, and
it should be "postinst free". All of this pretty much already says
util-linux-extra should have irqtop, and not util-linux.

So, if we go with update-alternatives, which program names do you
propose? irqtop-nf and irqtop-ul?
There is some precedent to use "." instead of "-", but probably
either are fine.

Chris

Bug#1009764: [pkg-crosswire-devel] Bug#1009764: xiphos: freezes when page is changed

[Bastian Germann]

Control: tags -1 moreinfo

Am 17.04.22 um 01:25 schrieb garywk:

Hadn't used xiphos in a while and when attempted to change Bible book
program
froze.  Only way to close program was to reboot computer.


I cannot reproduce this.

Please explain which Bible you were using and how you changed the book.
From/to which book did you try to change? Which Xiphos element were you using (arrow buttons, drop 
down, search box)?

Bug#998939: Bug#965455: chrootuid: diff for NMU version 1.3-6.1

[Javier Fernandez-Sanguino]

Dear João,

Thanks for preparing, the patch looks ok to me.

Saludos,

Javier

El sáb, 16 abr 2022 22:30, Joao Eriberto Mota Filho 
escribió:

> Control: tags 965455 + patch
> Control: tags 965455 + pending
> Control: tags 998939 + patch
> Control: tags 998939 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for chrootuid (versioned as 1.3-6.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
>
> Regards,
>
> Eriberto
>
> diff -u chrootuid-1.3/debian/rules chrootuid-1.3/debian/rules
> --- chrootuid-1.3/debian/rules
> +++ chrootuid-1.3/debian/rules
> @@ -53,4 +53,6 @@
> dh_builddeb
>
>  binary: binary-indep binary-arch
> -.PHONY: build clean binary-indep binary-arch binary install configure
> +build-arch: build
> +build-indep: build
> +.PHONY: build build-arch build-indep clean binary-indep binary-arch
> binary install configure
> diff -u chrootuid-1.3/debian/control chrootuid-1.3/debian/control
> --- chrootuid-1.3/debian/control
> +++ chrootuid-1.3/debian/control
> @@ -2,7 +2,7 @@
>  Section: admin
>  Priority: optional
>  Maintainer: Javier Fernandez-Sanguino Pen~a 
> -Build-Depends: debhelper (>> 3.0.0)
> +Build-Depends: debhelper-compat (= 13)
>  Standards-Version: 3.9.1.0
>  Homepage: http://ftp.porcupine.org/pub/security/index.html
>
> diff -u chrootuid-1.3/debian/changelog chrootuid-1.3/debian/changelog
> --- chrootuid-1.3/debian/changelog
> +++ chrootuid-1.3/debian/changelog
> @@ -1,3 +1,16 @@
> +chrootuid (1.3-6.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Using new DH level format. Consequently:
> +  - debian/compat: removed.
> +  - debian/control: changed from 'debhelper' to 'debhelper-compat' in
> +Build-Depends field and bumped level to 13.
> +  - Closes: #965455
> +  * debian/rules: added missing targets build-arch and build-indep.
> +(Closes: #998939)
> +
> + -- Joao Eriberto Mota Filho   Sat, 16 Apr 2022
> 17:10:27 -0300
> +
>  chrootuid (1.3-6) unstable; urgency=low
>
>* Change maintainer's e-mail address
> reverted:
> --- chrootuid-1.3/debian/compat
> +++ chrootuid-1.3.orig/debian/compat
> @@ -1 +0,0 @@
> -5
>

Bug#1009773: matrix-synapse: updating the package rewrites /etc/matrix-synapse/conf.d/server_name.yaml with wrong domain name

[Alessandro Polverini]

Package: matrix-synapse
Version: 1.55.0-1~bpo11+1
Severity: important

The installer on every update rewrites the content of the file
/etc/matrix-synapse/conf.d/server_name.yaml setting server_name with the
host name of the server it's running.

This can be right most of times, but not when we use server delegation,
i.e. when for example we run synapse on matrix.domain.ext for users of
domain.ext

In this case the file get created with the content:
server_name: matrix.domain.ext

while it should be:
server_name: domain.ext

So every time I upgrade the package I need to stop synapse (since it
restart with the wrong settings and gives error), manually modify the
file and restart it again.

I don't know what the right fix for this is, maybe just avoid
re-creating the file if it already exists?

Thanks for mantaining this package!


-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (90, 'testing'), (50, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.0-0.bpo.3-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages matrix-synapse depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.77
ii  init-system-helpers1.60
ii  libjs-jquery   3.5.1+dfsg+~3.5.5-7
ii  libpython3-stdlib  3.9.2-3
ii  lsb-base   11.1.0
ii  python33.9.2-3
pn  python3-attr   
pn  python3-bcrypt 
pn  python3-bleach 
pn  python3-canonicaljson  
ii  python3-cryptography   3.3.2-1
ii  python3-distutils  3.9.2-1
pn  python3-frozendict 
ii  python3-idna   2.10-1
pn  python3-ijson  
pn  python3-jinja2 
pn  python3-jsonschema 
pn  python3-lxml   
pn  python3-matrix-common  
pn  python3-msgpack
pn  python3-nacl   
pn  python3-netaddr
ii  python3-openssl20.0.1-1
pn  python3-packaging  
pn  python3-phonenumbers   
pn  python3-pil
pn  python3-prometheus-client  
pn  python3-psycopg2   
pn  python3-pyasn1 
pn  python3-pyasn1-modules 
pn  python3-pymacaroons
pn  python3-service-identity   
pn  python3-signedjson 
pn  python3-sortedcontainers   
pn  python3-systemd
pn  python3-treq   
pn  python3-twisted
pn  python3-typing-extensions  
pn  python3-unpaddedbase64 
ii  python3-yaml   5.3.1-5

Versions of packages matrix-synapse recommends:
pn  matrix-synapse-ldap3  
pn  python3-pympler   

Versions of packages matrix-synapse suggests:
pn  python3-authlib  
pn  python3-jwt  

Bug#1008658: virtualbox: Rebuild against python3 >= 3.10

[Felix Stupp]

Dear Maintainers,

couldn't this be resolved in a better way? Because the VirtualBox package is 
now requires python3 >= 3.10, << 3.11,
I cannot upgrade it to its newer version without upgrading python3 to its 
unstable version as well.
I'm primarily using Debian testing packages but install some packages from 
unstable, like VirtualBox.
I have installed python3.10 as well, but currently python3 (the dependency 
package) from testing.

Does VirtualBox really need python3.10 as default and cannot work, if package 
python3 is installed in version 3.9 while python3.10 is available as well?
If not, I think it would be better to remove the dependency on python3 and only 
depend on the currently required / targeted python package (like python3.9 / 
python3.10 / …).
Or another way could be to lift the restriction on the python3 package versions 
and only introduce them if really required.
With either solution, it should be possible to use the virtualbox package on 
multiple versions without any more hassle than necessary about these 
dependencies.
I propose these solutions because if multiple packages would pin python3 to 
their required versions and a user wants to install two packages, where these 
versions differ, it would not be possible.

Regards,
Felix

Bug#1009772: armci-mpi: autopkgtest regression on s390x

[Graham Inggs]

Source: armci-mpi
Version: 0.3.1~beta-6
X-Debbugs-CC: debian-s...@lists.debian.org
Severity: important
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

armci-mpi's autopkgtests started failing on the big-endian s390x
architecture [1] where they passed previously.  I've copied what I
hope is the relevant part of the log below.

Regards
Graham


[1] https://ci.debian.net/packages/a/armci-mpi/testing/s390x/


PASS: benchmarks/ping-pong
PASS: benchmarks/ring-flood
PASS: benchmarks/contiguous-bench
FAIL: benchmarks/strided-bench
PASS: benchmarks/rmw_perf
PASS: tests/test_onesided
PASS: tests/test_onesided_shared
PASS: tests/test_onesided_shared_dla
PASS: tests/test_mutex
PASS: tests/test_mutex_rmw
PASS: tests/test_mutex_trylock
PASS: tests/test_malloc_irreg
FAIL: tests/ARMCI_PutS_latency
FAIL: tests/ARMCI_AccS_latency
PASS: tests/test_groups
PASS: tests/test_group_split
PASS: tests/test_malloc_group
FAIL: tests/test_accs
FAIL: tests/test_accs_dla
FAIL: tests/test_puts
FAIL: tests/test_puts_gets
FAIL: tests/test_puts_gets_dla
FAIL: tests/test_putv
PASS: tests/test_igop
PASS: tests/test_rmw_fadd
PASS: tests/test_parmci
PASS: tests/mpi/test_mpi_accs
FAIL: tests/mpi/test_mpi_dim
FAIL: tests/mpi/test_mpi_indexed_accs
FAIL: tests/mpi/test_mpi_indexed_gets
FAIL: tests/mpi/test_mpi_indexed_puts_gets
FAIL: tests/mpi/test_mpi_subarray_accs
PASS: tests/mpi/test_win_create
PASS: tests/mpi/test_win_model
PASS: tests/ctree/ctree_test
PASS: tests/ctree/ctree_test_rand
PASS: tests/ctree/ctree_test_rand_interval
FAIL: tests/contrib/armci-perf
FAIL: tests/contrib/armci-test
PASS: tests/contrib/lu/lu-block
PASS: tests/contrib/lu/lu-b-bc
PASS: tests/contrib/transp1D/transp1D-c
PASS: tests/contrib/non-blocking/simple

Testsuite summary for armci 0.1

# TOTAL: 43
# PASS:  27
# SKIP:  0
# XFAIL: 0
# FAIL:  16
# XPASS: 0
# ERROR: 0
...

test-armci-mpich FAIL non-zero exit status 2

Bug#1001407: lynx: still recommends on transitional package mime-suport

[Andreas Metzler]

Control: tags -1 pending

On 2022-04-17 Charles Plessy  wrote:
> Dear Elimar,

> I am the maintainer of mime-support, mailcap and media-types.

> I would like to remove mime-support from Debian this release cycle.

> Sorry that I did not contact you earlier, but may I ask you to recommend
> mailcap instead of mime-support ?

Good morning,

Fixed in git.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


signature.asc
Description: PGP signature