date:20210826

Source: gnome-shell-extension-xrdesktop
Version: 0.14.0-3
Severity: important

git master appears to be compatible with gnome-shell 3.38 and 40.

Thanks,
Jeremy Bicha

Bug#993064: gpaste: Please update to 3.40

Source: gpaste
Version: 3.38.6-1
Severity: important

gpaste 3.40 says it's compatible with gnome-shell 40 but not with
earlier releases of gnome-shell.

Thanks,
Jeremy Bicha

Bug#993063: gnome-shell-pomodoro: Please update to version 0.19.1

Source: gnome-shell-pomodoro
Version: 0.18.0-0.1
Severity: important

Please package gnome-shell-pomodoro 0.19.1 which claims to be
compatible with gnome-shell 3.38 and 40.

Thanks,
Jeremy Bicha

Bug#993059: dpkg-cross: support ld-linux-mipsn8.so.1 for MIPS r6

2021-08-26 Thread YunQiang Su

On Fri, 27 Aug 2021 09:28:47 +0800 YunQiang Su  wrote:
> Package: dpkg-cross
> Version: 2.6.18+nmu1
> 

Oh, sorry I paste the patch more than needed.
@@ -633,10 +633,13 @@ sub sub_build {
while () {
if ($multiarch =~ m/mips(isa)?64.*-linux.*-gnuabi64.*/) 
{

s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslib64/ld.so.1:g;
+   
s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux-mipsn8\.so\.1:$1$crosslib64/ld-linux-mipsn8\.so\.1:g;
} elsif ($multiarch =~ 
m/^mips(isa)?64.*-linux.*-gnuabin32.*/) {

s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslibn32/ld.so.1:g;
+   
s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux-mipsn8\.so\.1:$1$crosslibn32/ld-linux-mipsn8\.so\.1:g;
} elsif ($multiarch =~ 
m/^mips(isa32)?.*-linux.*-gnu.*/) {
-   
s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslib/ld.so.1:g;
+   
s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslib/ld\.so\.1:g;
+   
s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux-mipsn8\.so\.1:$1$crosslib/ld-linux-mipsn8\.so\.1:g;
} elsif ($multiarchtriplet eq "sparc64-linux-gnu") {

s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux\.so\.2:$1$crosslib64/ld-linux.so.2:g;
}
@@ -1065,6 +1068,7 @@ sub sub_build {
# skip /usr/$(multiarch)/lib/ld.so.1 for mips n32 and 64.
# their ld.so.1 should be in lib32 and lib64.
next if ($multiarch =~ m/^mips(isa)?64/ && $_ =~ 
m:lib/ld\.so\.1$:);
+   next if ($multiarch =~ m/^mips(isa)?64/ && $_ =~ 
m:lib/ld-linux-mipsn8\.so\.1$:);
next if ($multiarchtriplet eq "sparc64-linux-gnu" && $_ =~ 
m:lib/ld-linux\.so\.2$:);

# skip links to private modules and plugins that are not
This is the correct one, or see:
https://salsa.debian.org/toolchain-team/cross-toolchain-base/-/commit/9b1b149dc4cb852ce5f1643ba9d56cc040342bab.patch

> MIPS r6 uses different ld files as the previous version:
> 
> @@ -633,10 +633,13 @@ sub sub_build {
> while () {
> if ($multiarch =~
> m/mips(isa)?64.*-linux.*-gnuabi64.*/) {
> 
> s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslib64/ld.so.1:g;
> +
> s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux-mipsn8\.so\.1:$1$crosslib64/ld-linux-mipsn8\.so\.1:g;
> } elsif ($multiarch =~
> m/^mips(isa)?64.*-linux.*-gnuabin32.*/) {
> 
> s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslibn32/ld.so.1:g;
> +
> s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux-mipsn8\.so\.1:$1$crosslibn32/ld-linux-mipsn8\.so\.1:g;
> } elsif ($multiarch =~
> m/^mips(isa32)?.*-linux.*-gnu.*/) {
> -
> s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslib/ld.so.1:g;
> +
> s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslib/ld\.so\.1:g;
> +
> s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux-mipsn8\.so\.1:$1$crosslib/ld-linux-mipsn8\.so\.1:g;
> } elsif ($multiarchtriplet eq "sparc64-linux-gnu") {
> 
> s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux\.so\.2:$1$crosslib64/ld-linux.so.2:g;
> }
> @@ -1065,6 +1068,7 @@ sub sub_build {
> # skip /usr/$(multiarch)/lib/ld.so.1 for mips n32 and 64.
> # their ld.so.1 should be in lib32 and lib64.
> next if ($multiarch =~ m/^mips(isa)?64/ && $_ =~
> m:lib/ld\.so\.1$:);
> +   next if ($multiarch =~ m/^mips(isa)?64/ && $_ =~
> m:lib/ld-linux-mipsn8\.so\.1$:);
> next if ($multiarchtriplet eq "sparc64-linux-gnu" &&
> $_ =~ m:lib/ld-linux\.so\.2$:);
> 
> # skip links to private modules and plugins that are not
> @@ -1137,7 +1141,9 @@ sub sub_build {
> # Link the shlibs file
> if (-f "$src/DEBIAN/shlibs") {
> print "Installing shlibs file\n" if $verbose >= 2;
> -   fix_shlibs("$src/DEBIAN/shlibs", "$dst/DEBIAN/shlibs");
> +   link_file("$src/DEBIAN/shlibs", "$dst/DEBIAN/shlibs");
> +   # FIXME: not enabling in this copy. needed?
> +   #fix_shlibs("$src/DEBIAN/shlibs", "$dst/DEBIAN/shlibs");
> }
> 
> # Create the control file.
> 
> The patch is also avaiable from:
> https://salsa.debian.org/toolchain-team/cross-toolchain-base/-/commit/9b1b149dc4cb852ce5f1643ba9d56cc040342bab
> 
> 
> -- 
> YunQiang Su

Bug#993062: gnome-shell-extension-top-icons-plus: Needs update for gnome-shell 40

Source: gnome-shell-extension-top-icons-plus
Version: 27-2
Severity: important

It looks like git master works with gnome-shell 40 but not with
previous gnome-shell releases.

Thanks,
Jeremy Bicha

Bug#993061: gnome-shell-extension-easyscreencast: Not compatible with gnome-shell 40

Source: gnome-shell-extension-easyscreencast
Version: 1.1.0+git20210116.3252312-1
Severity: important

gnome-shell-extension-easyscreencast does not work with gnome-shell 40.

Thanks,
Jeremy Bicha

Bug#893851: ffcall: Fix build for MIPS release 6

2021-08-26 Thread YunQiang Su

Sébastien Villemot  于2021年8月27日周五 上午1:57写道：
>
> Dear YunQiang,
>
> Le mercredi 28 mars 2018 à 10:49 +0200, Sébastien Villemot a écrit :
> > On Fri, Mar 23, 2018 at 09:38:04PM +0800, YunQiang Su wrote:
> > > On Fri, Mar 23, 2018 at 8:41 PM, Sébastien Villemot
> > >  wrote:
> > > > On Fri, Mar 23, 2018 at 08:02:58PM +0800, YunQiang Su wrote:
> > > > > On Fri, Mar 23, 2018 at 7:58 PM, YunQiang Su  
> > > > > wrote:
> > > > > > On Fri, Mar 23, 2018 at 7:27 PM, Sébastien Villemot
> > > > > >  wrote:
> > > > > > > Dear YunQiang,
> > > > > > >
> > > > > > > On Fri, Mar 23, 2018 at 06:15:08PM +0800, YunQiang Su wrote:
> > > > > > > > Package: src:ffcall
> > > > > > > > Version: 2.1-1
> > > > > > > >
> > > > > > > > MIPS release 6 drops some instructions: bnel/beql included.
> > > > > > > > For r6, we should use bne/beq for replace.
> > > > > > > >
> > > > > > > > The patch has submit in salsa as a merge request.
> > > > > > > >
> > > > > > > > https://salsa.debian.org/common-lisp-team/ffcall/merge_requests/1
> > > > > > >
> > > > > > > Thanks for your report and your patch.
> > > > > > >
> > > > > > > You may have overlooked the fact that these assembly files are 
> > > > > > > actually
> > > > > > > generated by GCC from C source code (see the DEP-3 header of
> > > > > > > debian/patches/mips-fpxx.patch), so your proposed patch is not 
> > > > > > > very
> > > > > > > maintainable in the long term.
> > > > > >
> > > > > > Oh, thanks. Since then, I guess we should generate these .S files
> > > > > > when build instead of put them in the source code.
> > > > > >
> > > > > > I will have a look at it.
> > > > >
> > > > > After read Makefile.devel, I think that we should call the right
> > > > > target in debian/rules.
> > > > > Should this the ideal way?
> > > >
> > > > This could be a possiblity, but this is not supported by upstream. And 
> > > > we would
> > > > have to patch this Makefile.devel to make it work (it expects 
> > > > non-standard
> > > > names for GCC). So I do not really like this solution.
> > > >
> > >
> > > In fact we can patch it to use $(CC), and pass it when we call these 
> > > targets,
> > > and then we can drop the patch for the .S/.s files.
> > > The length of patch file will be much shorter.
> > >
> > > Anyway, we will have to patch it.
> > > Wish my attached patch can change your mind. ;)
> >
> > I really don't like the kludge for mips in debian/rules.
> >
> > I think that all things considered I prefer your very first patch, which had
> > the advantage of being very small.
>
> I just wanted to inform you that, with the upload of ffcall 2.4, I had
> to drop your MIPS r6, because it no longer applies, and I don’t know
> how to refresh it.
>
> I think this shows that the best solution for MIPS r6 support would
> rather be to work directly with upstream, rather than applying a
> Debian-specific patch.
>

The upstream had some big restruct work and I think that the current source
can work with MIPS r6 out of box now.

> Best regards,
>
> --
> ⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
> ⣾⠁⢠⠒⠀⣿⡁  Debian Developer
> ⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
> ⠈⠳⣄  https://www.debian.org
>


-- 
YunQiang Su

Bug#993060: gnome-shell-extension-caffeine: Not compatible with gnome-shell 40

Source: gnome-shell-extension-caffeine
Version: 37-1
Severity: important

It looks like upstream git master is compatible with gnome-shell 40
but not with earlier gnome-shell releases.

Thanks,
Jeremy Bicha

Bug#993058: gnome-shell-extension-dash-to-panel: New upstream release 43

Source: gnome-shell-extension-dash-to-panel
Version: 40-1
Severity: important

gnome-shell-extension-dash-to-panel 43 was released. It works on
gnome-shell 40 but does not work on earlier gnome-shell releases.

Thanks,
Jeremy Bicha

Bug#993059: dpkg-cross: support ld-linux-mipsn8.so.1 for MIPS r6

2021-08-26 Thread YunQiang Su

Package: dpkg-cross
Version: 2.6.18+nmu1

MIPS r6 uses different ld files as the previous version:

@@ -633,10 +633,13 @@ sub sub_build {
while () {
if ($multiarch =~
m/mips(isa)?64.*-linux.*-gnuabi64.*/) {

s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslib64/ld.so.1:g;
+
s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux-mipsn8\.so\.1:$1$crosslib64/ld-linux-mipsn8\.so\.1:g;
} elsif ($multiarch =~
m/^mips(isa)?64.*-linux.*-gnuabin32.*/) {

s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslibn32/ld.so.1:g;
+
s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux-mipsn8\.so\.1:$1$crosslibn32/ld-linux-mipsn8\.so\.1:g;
} elsif ($multiarch =~
m/^mips(isa32)?.*-linux.*-gnu.*/) {
-
s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslib/ld.so.1:g;
+
s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslib/ld\.so\.1:g;
+
s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux-mipsn8\.so\.1:$1$crosslib/ld-linux-mipsn8\.so\.1:g;
} elsif ($multiarchtriplet eq "sparc64-linux-gnu") {

s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux\.so\.2:$1$crosslib64/ld-linux.so.2:g;
}
@@ -1065,6 +1068,7 @@ sub sub_build {
# skip /usr/$(multiarch)/lib/ld.so.1 for mips n32 and 64.
# their ld.so.1 should be in lib32 and lib64.
next if ($multiarch =~ m/^mips(isa)?64/ && $_ =~
m:lib/ld\.so\.1$:);
+   next if ($multiarch =~ m/^mips(isa)?64/ && $_ =~
m:lib/ld-linux-mipsn8\.so\.1$:);
next if ($multiarchtriplet eq "sparc64-linux-gnu" &&
$_ =~ m:lib/ld-linux\.so\.2$:);

# skip links to private modules and plugins that are not
@@ -1137,7 +1141,9 @@ sub sub_build {
# Link the shlibs file
if (-f "$src/DEBIAN/shlibs") {
print "Installing shlibs file\n" if $verbose >= 2;
-   fix_shlibs("$src/DEBIAN/shlibs", "$dst/DEBIAN/shlibs");
+   link_file("$src/DEBIAN/shlibs", "$dst/DEBIAN/shlibs");
+   # FIXME: not enabling in this copy. needed?
+   #fix_shlibs("$src/DEBIAN/shlibs", "$dst/DEBIAN/shlibs");
}

# Create the control file.

The patch is also avaiable from:
https://salsa.debian.org/toolchain-team/cross-toolchain-base/-/commit/9b1b149dc4cb852ce5f1643ba9d56cc040342bab


-- 
YunQiang Su

Bug#993057: gnome-shell-extension-bluetooth-quick-connect: New upstream release 20

Source: gnome-shell-extension-bluetooth-quick-connect
Version: 16-1
Severity: important

Please update gnome-shell-extension-bluetooth-quick-connect to version
20. According to the metadata.json, the new version is compatible with
gnome-shell 40 but not compatible with earlier gnome-shell releases.

Thanks,
Jeremy Bicha

Bug#993056: monit: incorrect comment level in monitrc

Package: monit
Version: 1:5.28.0-3
Severity: minor

In the monitrc file:

## Set the list of mail servers for alert delivery. Multiple servers may be
## specified using a comma separator. If the first mail server fails, Monit
# will use the second mail server in the list and so on. By default Monit uses
# port 25 - it is possible to override this with the PORT option.

This should be:

## Set the list of mail servers for alert delivery. Multiple servers may be
## specified using a comma separator. If the first mail server fails, Monit
## will use the second mail server in the list and so on. By default Monit uses
## port 25 - it is possible to override this with the PORT option.

(A single # is used for commented out statements.)

-- Package-specific info:

Monit config file /etc/monit/monitrc is *NOT* readable by reportbug.
Please, consider to rerun reportbug as root and *carefully* examine
reportbug's output (e.g., monitrc content), before sending it out.

Contents of /etc/monit/ directory:
/etc/monit:
total 68
drwxr-xr-x 2 root root  4096 2021-08-27 03:01:07 conf-available
drwxr-xr-x 2 root root  4096 2015-12-05 21:19:30 conf-enabled
drwxr-xr-x 2 root root  4096 2020-01-04 22:11:10 conf.d
-rw--- 1 root root 13175 2020-08-03 11:01:55 monitrc
drwxr-xr-x 2 root root  4096 2021-07-14 02:13:13 monitrc.d
-rw--- 1 root root 13110 2020-07-31 13:12:44 monitrc.dpkg-dist
-rw--- 1 root root 13500 2021-08-26 14:54:26 monitrc.dpkg-new
drwxr-xr-x 2 root root  4096 2021-08-27 03:00:20 templates

/etc/monit/conf-available:
total 60
-rw-r--r-- 1 root root  481 2015-12-05 21:13:49 acpid
-rw-r--r-- 1 root root  640 2015-12-05 21:13:49 apache2
-rw-r--r-- 1 root root  455 2015-12-05 21:13:49 at
-rw-r--r-- 1 root root  691 2015-12-05 21:13:49 cron
-rw-r--r-- 1 root root  602 2015-12-05 21:13:49 mdadm
-rw-r--r-- 1 root root  669 2015-12-05 21:13:49 memcached
-rw-r--r-- 1 root root  703 2015-12-05 21:13:49 mysql
-rw-r--r-- 1 root root  521 2015-12-05 21:13:49 nginx
-rw-r--r-- 1 root root  471 2015-12-05 21:13:49 openntpd
-rw-r--r-- 1 root root 1200 2020-07-31 13:12:44 openssh-server
-rw-r--r-- 1 root root  683 2015-12-05 21:13:49 pdns-recursor
-rw-r--r-- 1 root root 1426 2018-12-21 09:32:54 postfix
-rw-r--r-- 1 root root  869 2016-03-22 16:43:44 rsyslog
-rw-r--r-- 1 root root  501 2015-12-05 21:13:49 smartmontools
-rw-r--r-- 1 root root  306 2016-02-04 15:03:50 snmpd

/etc/monit/conf-enabled:
total 0

/etc/monit/conf.d:
total 4
-rw-r--r-- 1 root root 357 2020-01-04 22:11:10 eth0

/etc/monit/monitrc.d:
total 64
-rw-r--r-- 1 root root  481 2015-06-09 15:52:48 acpid
-rw-r--r-- 1 root root  640 2015-06-09 15:52:48 apache2
-rw-r--r-- 1 root root  455 2015-06-09 15:52:48 at
-rw-r--r-- 1 root root  691 2015-06-09 15:52:48 cron
-rw-r--r-- 1 root root  403 2016-12-09 15:37:54 fail2ban
-rw-r--r-- 1 root root  602 2015-06-09 15:52:48 mdadm
-rw-r--r-- 1 root root  669 2015-06-09 15:52:48 memcached
-rw-r--r-- 1 root root  703 2015-06-09 15:52:48 mysql
-rw-r--r-- 1 root root  521 2015-06-09 15:52:48 nginx
-rw-r--r-- 1 root root  471 2015-06-09 15:52:48 openntpd
-rw-r--r-- 1 root root  950 2015-06-09 15:52:48 openssh-server
-rw-r--r-- 1 root root  683 2015-06-09 15:52:48 pdns-recursor
-rw-r--r-- 1 root root 1421 2015-06-09 15:52:48 postfix
-rw-r--r-- 1 root root  867 2015-06-09 15:52:48 rsyslog
-rw-r--r-- 1 root root  501 2015-06-09 15:52:48 smartmontools
-rw-r--r-- 1 root root  310 2015-06-09 15:52:48 snmpd

/etc/monit/templates:
total 24
-rw-r--r-- 1 root root 164 2015-06-09 15:52:48 rootbin
-rw-r--r-- 1 root root 164 2021-08-26 14:52:02 rootbin.dpkg-new
-rw-r--r-- 1 root root 160 2015-06-09 15:52:48 rootrc
-rw-r--r-- 1 root root 160 2021-08-26 14:52:02 rootrc.dpkg-new
-rw-r--r-- 1 root root 164 2015-06-09 15:52:48 rootstrict
-rw-r--r-- 1 root root 164 2021-08-26 14:52:02 rootstrict.dpkg-new


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.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 monit depends on:
ii  init-system-helpers  1.60
ii  libc62.31-17
ii  libcrypt11:4.4.25-1
ii  libpam0g 1.4.0-9
ii  libssl1.11.1.1l-1
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-2

monit recommends no packages.

Versions of packages monit suggests:
ii  postfix [mail-transport-agent]  3.5.6-1+b1
pn  sysvinit-core   

-- Configuration Files:
/etc/monit/monitrc [Errno 13] Permission denied: '/etc/monit/monitrc'

-- no debconf information

-- 
Vincent Lefèvre  - Web:

Bug#993055: monit: incorrect comment in /etc/monit/monitrc

Package: monit
Version: 1:5.28.0-3
Severity: normal

I can see in the monitrc file:

set daemon  120 # check services at 30 seconds intervals

That's 2 minutes, not 30 seconds.

The error comes from debian/patches/010_monitrc.patch, which modifes
the value, but not the comment:

-set daemon  30  # check services at 30 seconds intervals
+set daemon  120 # check services at 30 seconds intervals

-- Package-specific info:

Monit config file /etc/monit/monitrc is *NOT* readable by reportbug.
Please, consider to rerun reportbug as root and *carefully* examine
reportbug's output (e.g., monitrc content), before sending it out.

Contents of /etc/monit/ directory:
/etc/monit:
total 68
drwxr-xr-x 2 root root  4096 2021-08-27 03:01:07 conf-available
drwxr-xr-x 2 root root  4096 2015-12-05 21:19:30 conf-enabled
drwxr-xr-x 2 root root  4096 2020-01-04 22:11:10 conf.d
-rw--- 1 root root 13175 2020-08-03 11:01:55 monitrc
drwxr-xr-x 2 root root  4096 2021-07-14 02:13:13 monitrc.d
-rw--- 1 root root 13110 2020-07-31 13:12:44 monitrc.dpkg-dist
-rw--- 1 root root 13500 2021-08-26 14:54:26 monitrc.dpkg-new
drwxr-xr-x 2 root root  4096 2021-08-27 03:00:20 templates

/etc/monit/conf-available:
total 60
-rw-r--r-- 1 root root  481 2015-12-05 21:13:49 acpid
-rw-r--r-- 1 root root  640 2015-12-05 21:13:49 apache2
-rw-r--r-- 1 root root  455 2015-12-05 21:13:49 at
-rw-r--r-- 1 root root  691 2015-12-05 21:13:49 cron
-rw-r--r-- 1 root root  602 2015-12-05 21:13:49 mdadm
-rw-r--r-- 1 root root  669 2015-12-05 21:13:49 memcached
-rw-r--r-- 1 root root  703 2015-12-05 21:13:49 mysql
-rw-r--r-- 1 root root  521 2015-12-05 21:13:49 nginx
-rw-r--r-- 1 root root  471 2015-12-05 21:13:49 openntpd
-rw-r--r-- 1 root root 1200 2020-07-31 13:12:44 openssh-server
-rw-r--r-- 1 root root  683 2015-12-05 21:13:49 pdns-recursor
-rw-r--r-- 1 root root 1426 2018-12-21 09:32:54 postfix
-rw-r--r-- 1 root root  869 2016-03-22 16:43:44 rsyslog
-rw-r--r-- 1 root root  501 2015-12-05 21:13:49 smartmontools
-rw-r--r-- 1 root root  306 2016-02-04 15:03:50 snmpd

/etc/monit/conf-enabled:
total 0

/etc/monit/conf.d:
total 4
-rw-r--r-- 1 root root 357 2020-01-04 22:11:10 eth0

/etc/monit/monitrc.d:
total 64
-rw-r--r-- 1 root root  481 2015-06-09 15:52:48 acpid
-rw-r--r-- 1 root root  640 2015-06-09 15:52:48 apache2
-rw-r--r-- 1 root root  455 2015-06-09 15:52:48 at
-rw-r--r-- 1 root root  691 2015-06-09 15:52:48 cron
-rw-r--r-- 1 root root  403 2016-12-09 15:37:54 fail2ban
-rw-r--r-- 1 root root  602 2015-06-09 15:52:48 mdadm
-rw-r--r-- 1 root root  669 2015-06-09 15:52:48 memcached
-rw-r--r-- 1 root root  703 2015-06-09 15:52:48 mysql
-rw-r--r-- 1 root root  521 2015-06-09 15:52:48 nginx
-rw-r--r-- 1 root root  471 2015-06-09 15:52:48 openntpd
-rw-r--r-- 1 root root  950 2015-06-09 15:52:48 openssh-server
-rw-r--r-- 1 root root  683 2015-06-09 15:52:48 pdns-recursor
-rw-r--r-- 1 root root 1421 2015-06-09 15:52:48 postfix
-rw-r--r-- 1 root root  867 2015-06-09 15:52:48 rsyslog
-rw-r--r-- 1 root root  501 2015-06-09 15:52:48 smartmontools
-rw-r--r-- 1 root root  310 2015-06-09 15:52:48 snmpd

/etc/monit/templates:
total 24
-rw-r--r-- 1 root root 164 2015-06-09 15:52:48 rootbin
-rw-r--r-- 1 root root 164 2021-08-26 14:52:02 rootbin.dpkg-new
-rw-r--r-- 1 root root 160 2015-06-09 15:52:48 rootrc
-rw-r--r-- 1 root root 160 2021-08-26 14:52:02 rootrc.dpkg-new
-rw-r--r-- 1 root root 164 2015-06-09 15:52:48 rootstrict
-rw-r--r-- 1 root root 164 2021-08-26 14:52:02 rootstrict.dpkg-new


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.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 monit depends on:
ii  init-system-helpers  1.60
ii  libc62.31-17
ii  libcrypt11:4.4.25-1
ii  libpam0g 1.4.0-9
ii  libssl1.11.1.1l-1
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-2

monit recommends no packages.

Versions of packages monit suggests:
ii  postfix [mail-transport-agent]  3.5.6-1+b1
pn  sysvinit-core   

-- Configuration Files:
/etc/monit/monitrc [Errno 13] Permission denied: '/etc/monit/monitrc'

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#993054: gbp import-orig: support more advanced upstream-vcs-tag mangling

Source: git-buildpackage
Version: 0.9.22
Severity: wishlist

The GNOME project has adopted a new version numbering scheme [1]. Here
are version numbers sorted in order from oldest to newest:
40.alpha
40.beta
40.rc
40.0
40.1

Here are the version numbers mangled so they sort correctly on Debian:
40~alpha
40~beta
40~rc
40.0
40.1

The Debian GNOME team uses gbp's upstream-vcs-tag feature and we'd
like to set it in debian/gbp.conf so it finds the git tag that
corresponds with the upstream version number as handled by uscan (see
the debian/watch file at [2]).

I don't see a way to change a period (.) to a tilde (~) only when
followed by a letter.

[1] https://discourse.gnome.org/t/new-gnome-versioning-scheme/4235
[2] https://salsa.debian.org/gnome-team/evince/-/commit/730e048

Thanks,
Jeremy Bicha

Bug#993047: A libvirt-qemu user is added and shown on the login screen because the UID is too high

2021-08-26 Thread mYnDstrEAm

Package: libvirt
Version: 5.0.0

I didn't create this user - I think it was added by installing the "Virtual
Machine manager" (virt-manager) on Debian10/KDE, or more specifically by
libvirt-daemon-system.

`grep -E 'libvirt|qemu' /etc/passwd` returns `libvirt-qemu:x:64055:1xx:Libvirt
Qemu,,,:/var/lib/libvirt:/usr/sbin/nologin`
KDE's User Manager doesn't show the account but it's displayed on the login
screen on the left of the actual user account (not when locking the screen but
at least after booting).

This useraccount shouldn't be displayed as a normal user if adding it is indeed
needed/useful.
If the solution is to not remove the user but to hide it by creating the
/users/libvirt-qemu file why isn't that done when the user is set up already?
If the user is necessary I'd find it strange that iirc it was only added after
installing virt-manager but not after installing and using aqemu.

I asked about it here where users cas and A.B. made some helpful comments. A.B.
suggested that "libvirt-qemu is a system account but with a specific UID not in
the default system range ( < 500 or something like this): `grep
LIBVIRT_QEMU_UID /var/lib/dpkg/info/libvirt`*" (it's over 6). Changing the
UID or creating that config-file containing `SystemAccount=true` upon
installation seem to be two ways of solving this issue.

Per https://github.com/sddm/sddm/issues/816 it really seems to be a bug of
virt-manager. I don't know if this has been fixed in newer versions. If the
solution really is just changing the UID there may be an additional issue of
500 being too low. It should probably check which UIDs within that range are
still available and then assign one of these. It seems like running `usermod -u
345 libvirt-qemu` would solve the issue for those affected, right?

Per https://github.com/virt-manager/virt-manager/issues/293 the problem is the
hard-coded UID here:
https://salsa.debian.org/libvirt-team/libvirt/-/blob/debian/buster/debian/libvirt-daemon-system.config

It would be great if people would set up a proper issue-tracking system for
Debian (one that's modern, somewhat convenient to use, doesn't look outdated by
decades and is Web-based).

Bug#992034: installation-guide: Include a note on how to change init system during install

2021-08-26 Thread Holger Wansing

Hi,

Am 26. August 2021 09:24:58 MESZ schrieb Matthew Vernon :
>Hi,
>
>Could someone merge 
>https://salsa.debian.org/installer-team/installation-guide/-/merge_requests/15 
>please?
>
>It's the smaller change that folk asked for :)

I wonder if "the easiest time to select an alternative init system is during 
the 
installation process" is correct English.

Maybe better "the best time ... " ?

Asking debian-l10n-english for advise.

@debian-l10n-english: 
Hi all, could someone please comment on the merge request
mentioned above?

Thanks

Holger



-- 
Sent from /e/ OS on Fairphone3

Bug#993053: python3-flasgger: bad formatting of summary with MK_SANITIZER

2021-08-26 Thread Francesco Potortì

Package: python3-flasgger
Version: 0.9.5+dfsg.2-1
Severity: normal
X-Debbugs-Cc: none, Francesco Potortì 

when using the MK_SANITIZER the summary of each endpoint appears
embedded between  and 

Please write to me in private get a link to the API I am documenting to
see an example of this behaviour

-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (101, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=it_IT.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-flasgger depends on:
ii  libjs-jquery3.5.1+dfsg+~3.5.5-7
ii  python3 3.9.2-3
ii  python3-flask   1.1.2-2
ii  python3-jsonschema  3.2.0-3
ii  python3-mistune 0.8.4-4
ii  python3-six 1.16.0-2
ii  python3-yaml5.3.1-5

python3-flasgger recommends no packages.

python3-flasgger suggests no packages.

-- no debconf information

Bug#685264: merge bugs 685264, 705155 and 746206?

Shouldn't these bugs be merged?

685264: debbugs: obey “Control” field in pseudoheader of messages to 
‘nnn-d...@bugs.debian.org’
705155: allow Control: commands at -done and -forwarded
746206: Control: pseudoheaders do not work for -done bugs; finish() called too 
early

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#993052: transition: tracker

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: trac...@packages.debain.org
Severity: normal

The Debian GNOME team requests permission to do the "tracker"
transition, updating the library and service from version 2 to version
3. All affected packages need sourceful uploads.

All affected packages are maintained by the Debian GNOME team except
for grilo-plugins, kylin-burner and netatalk.

All package updates are staged in experimental except for
grilo-plugins and netatalk.

The transition was successfully completed in Ubuntu a month ago.

https://release.debian.org/transitions/html/auto-tracker.html

https://salsa.debian.org/berto/grilo-plugins/-/merge_requests/2

Thank you,
Jeremy Bicha

Bug#992755: closed by Don Armstrong (reply to ow...@bugs.debian.org) (Re: Bug#992755: marked as done ([BTS] Bcc'ed close mails not archived in bug log ?))

2021-08-26 Thread Don Armstrong

On Thu, 26 Aug 2021, Vincent Lefevre wrote:
> On 2021-08-26 03:51:03 +, Debian Bug Tracking System wrote:
> > As a counterexample, this bug is only being closed via Bcc, but it
> > should show up both in the log and in what the bugreport.cgi
> > displays.
> 
> This is not the case. The "close" does not appear and actually
> corresponds to
> 
>   Reply sent to ow...@bugs.debian.org:
>   You have taken responsibility. (Thu, 26 Aug 2021 03:51:03 GMT) (full text, 
> mbox, link).

Yes, that's what happens when you send a mail to -done. There's an
argument to be made that we should change that to something more
obvious, but that's what a close message has looked like for the past 20
years or so.

[...]

> the main page of the bug report should also display when some metadata
> (close status, tags, etc.) is changed.

Mail to -done is handled differently than a control message, and doesn't
cause a separate html message to be added to the log indicating that the
bug status has been changed.

> Actually, "the first mail message to be received is shown" does not
> seem to be how bugreport.cgi behaves in general. For instance, see
> Message #30. It is displayed on the main page, but this main page
> *also* shows 3 copies:
>   * Message #32 ("Bug reopened")
>   * Message #34 ("Changed Bug title to ...")
>   * Message #36 ("Severity set to 'minor' from 'wishlist'")

Those are just the html that corresponds to the control commands which
were processed from message #30.

> I expect the same thing for "Bug closed", which is currently not the
> case.

It's reasonable to argue that it would be less surprising for the BTS to
handle -done like a control@ message, but that's a separate bug from
this bug.

-- 
Don Armstrong  https://www.donarmstrong.com

We cast this message into the cosmos. [...] We are trying to survive
our time so we may live into yours. We hope some day, having solved
the problems we face, to join a community of Galactic Civilizations.
This record represents our hope and our determination and our goodwill
in a vast and awesome universe.
 -- Jimmy Carter on the Voyager Golden Record

Bug#993051: avahi-daemon CPU usage increases over time

2021-08-26 Thread Ryan Armstrong


Package: avahi-daemon
Version: 0.8-5
Severity: normal

Dear Maintainer,

After upgrading to Debian Bullseye, I noticed that the Avahi CPU usage on my 
server machine was
quite high (eventually 100% of one core). After resetting Avahi, the CPU usage 
was normal then
eventually increased over time again until it was again rather high. The
increase appears to be (very roughly) 1 or 2% per hour on my rather humble 
Intel(R) Celeron(R)
CPU 4205U @ 1.80GHz.

Checking the journal, I only see the following sorts of lines:

Aug 25 16:21:30 zeta avahi-daemon[31]: avahi_normalize_name() failed.
Aug 25 16:21:30 zeta avahi-daemon[31]: avahi_key_new() failed.
Aug 25 16:21:30 zeta avahi-daemon[31]: avahi_normalize_name() failed.
Aug 25 16:21:30 zeta avahi-daemon[31]: avahi_key_new() failed.
Aug 25 16:21:31 zeta avahi-daemon[31]: avahi_normalize_name() failed.
Aug 25 16:21:31 zeta avahi-daemon[31]: avahi_key_new() failed.

Which was around the time I turned on another machine on my network.
However, the timing was not aligned with when Avahi CPU usage increased.
Instead, it seems to be aligned with when I turn on my printer, but nothing
of note was printed in the log when that happened.

Is there any means for me to gather additional information to help
diagnose this problem?

Thanks,
Ryan

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

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

Versions of packages avahi-daemon depends on:
ii  adduser  3.118
ii  bind9-host [host]1:9.16.15-1
ii  dbus 1.12.20-2
ii  init-system-helpers  1.60
ii  libavahi-common3 0.8-5
ii  libavahi-core7   0.8-5
ii  libc62.31-13
ii  libcap2  1:2.44-1
ii  libdaemon0   0.14-7.1
ii  libdbus-1-3  1.12.20-2
ii  libexpat12.2.10-2
ii  lsb-base 11.1.0

Versions of packages avahi-daemon recommends:
ii  libnss-mdns  0.14.1-2

Versions of packages avahi-daemon suggests:
pn  avahi-autoipd  

-- no debconf information

Bug#993040: [Debian-med-packaging] Bug#993040: htscodecs FTBFS on i386

2021-08-26 Thread Étienne Mollier

Hi Andrian,

Adrian Bunk, on 2021-08-26:
> debian/rules should use DEB_HOST_MULTIARCH instead of DEB_TARGET_GNU_TYPE.

Cool, Thanks for the speed and the tip!  I was still waiting for
the build result.  (:

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#993050: Automatic login uses GNOME on X11 rather than Wayland

2021-08-26 Thread Josh Triplett

Package: gdm3
Version: 3.38.2.1-1
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

I enabled automatic login in gdm3, by adding this to
/etc/gdm3/daemon.conf:

AutomaticLoginEnable=True
AutomaticLogin=josh

After doing so, I get automatically logged in, but running a
GNOME-on-X11 session.

If I log out, and manually log in, I can select a GNOME on Wayland
session. But automatic logins don't seem to use GNOME on Wayland.

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

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

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.55-3
ii  adduser   3.118
ii  dbus  1.12.20-2
ii  dconf-cli 0.38.0-2
ii  dconf-gsettings-backend   0.38.0-2
ii  debconf [debconf-2.0] 1.5.77
ii  gir1.2-gdm-1.03.38.2.1-1
ii  gnome-session [x-session-manager] 40.1.1-1
ii  gnome-session-bin 40.1.1-1
ii  gnome-session-common  40.1.1-1
ii  gnome-settings-daemon 3.38.2-1
ii  gnome-shell   3.38.6-1
ii  gnome-terminal [x-terminal-emulator]  3.40.3-1
ii  gsettings-desktop-schemas 3.38.0-2
ii  libaccountsservice0   0.6.55-3
ii  libaudit1 1:3.0.5-1
ii  libc6 2.31-17
ii  libcanberra-gtk3-00.30-7+b1
ii  libcanberra0  0.30-7+b1
ii  libgdk-pixbuf-2.0-0   2.42.6+dfsg-2
ii  libgdm1   3.38.2.1-1
ii  libglib2.0-0  2.68.4-1
ii  libglib2.0-bin2.68.4-1
ii  libgtk-3-03.24.30-2
ii  libkeyutils1  1.6.1-2
ii  libpam-modules1.4.0-9
ii  libpam-runtime1.4.0-9
ii  libpam-systemd247.9-1
ii  libpam0g  1.4.0-9
ii  librsvg2-common   2.50.3+dfsg-1
ii  libselinux1   3.1-3
ii  libsystemd0   247.9-1
ii  libx11-6  2:1.7.2-1
ii  libxau6   1:1.0.9-1
ii  libxcb1   1.14-3
ii  libxdmcp6 1:1.1.2-3
ii  lsb-base  11.1.0
ii  policykit-1   0.105-31
ii  procps2:3.3.17-5
ii  ucf   3.0043
ii  x11-common1:7.7+23
ii  x11-xserver-utils 7.7+8

Versions of packages gdm3 recommends:
ii  at-spi2-core2.40.3-3
ii  desktop-base11.0.3
ii  x11-xkb-utils   7.7+5
pn  xserver-xephyr  
ii  xserver-xorg1:7.7+23
ii  zenity  3.32.0-7

Versions of packages gdm3 suggests:
pn  gnome-orca
pn  libpam-fprintd
ii  libpam-gnome-keyring  40.0-2

-- Configuration Files:
/etc/gdm3/daemon.conf changed:
[daemon]
AutomaticLoginEnable=True
AutomaticLogin=josh
[security]
[xdmcp]
[chooser]
[debug]


-- debconf information:
* shared/default-x-display-manager: gdm3
  gdm3/daemon_name: /usr/sbin/gdm3

Bug#992931: [Debichem-devel] Bug#992931: libopenmm7.5 does not include libOpenMMAmoeba.so, libOpenMMDrude.so, and libOpenMMRPMD.so

2021-08-26 Thread Adam Sjøgren

Andrius writes:

> These libraries do not have sonames, thus I reckon they are not a part
> of public API.

Ah, I see - I was thinking that there would be a reason I didn't know of.

However if you run alphafold2 you get an exception where it tries to use
libOpenMMAmoeba.so. Hm.

(Unfortunately I don't have a small script to reproduce the problem.)

> On the other hand, reference libraries,
>
> libOpenMMAmoebaReference.so
> libOpenMMDrudeReference.so
> libOpenMMRPMDReference.so
>
> are provided in libopenmm-plugins binary package (>= 7.5.1+dfsg-1) at
> /usr/lib/${DEB_HOST_MULTIARCH}/openmm/plugins.
>
> If this would be of use, libOpenMM{Amoeba,Drude,RPMD}.so could be
> provided at /usr/lib/${DEB_HOST_MULTIARCH}/openmm, as
> /usr/lib/${DEB_HOST_MULTIARCH} is reserved for libraries with sonames.

Ah, ok, thanks for the explanation.

I will give it a go locally, see if that works and return.


  Thanks!

   Adam

-- 
 "I wonder if you can refuse to inherit the world." Adam Sjøgren
 "I think if you're born, it's too late."  a...@koldfront.dk

Bug#979047: RM: pepperflashplugin-nonfree -- RoQA; No longer work; upstream eol

2021-08-26 Thread Andreas Beckmann


Control: reassign -1 ftp.debian.org

On 15/01/2021 17.12, Andreas Beckmann wrote:

As pointed out in #978954, its better to replace it by a dummy with the
broken download/install functionality removed to ensure clean upgrades.


That was shipped in bullseye and buster.


So let's postpone the removal to bookworm.


We can do this now.


Andreas

Bug#993049: bullseye-pu: package rpki-trust-anchors/20210817-1+deb11u1

2021-08-26 Thread Marco d'Itri

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

rpki-trust-anchors is a data package containing public keys, similar to 
dns-root-data, which are used by RPKI validators (cfrpki, 
fort-validator, rpki-client, stayrtr).
A stable update is needed because an https URL was finally added to the 
LACNIC trust anchor. This allows the software currently in stable to use 
https to download the certificates instead of the problematic and 
deprecated rsync method.
Also, the same package from testing which I have rebuilt here gained a
new debconf translation.

-- 
ciao,
Marco
diff -Nru rpki-trust-anchors-20210417/debian/changelog rpki-trust-anchors-20210817/debian/changelog
--- rpki-trust-anchors-20210417/debian/changelog	2021-04-17 11:55:56.0 +0200
+++ rpki-trust-anchors-20210817/debian/changelog	2021-08-27 00:21:41.0 +0200
@@ -1,3 +1,15 @@
+rpki-trust-anchors (20210817-1+deb11u1) bullseye; urgency=medium
+
+  * Rebuilt for the stable distribution.
+
+ -- Marco d'Itri   Fri, 27 Aug 2021 00:21:41 +0200
+
+rpki-trust-anchors (20210817-1) unstable; urgency=medium
+
+  * Added the https URL to the LACNIC TAL.
+
+ -- Marco d'Itri   Tue, 17 Aug 2021 01:03:51 +0200
+
 rpki-trust-anchors (20210417-1) unstable; urgency=medium
 
   * Updated the https URL for the APNIC TAL.
diff -Nru rpki-trust-anchors-20210417/debian/control rpki-trust-anchors-20210817/debian/control
--- rpki-trust-anchors-20210417/debian/control	2021-04-17 11:53:53.0 +0200
+++ rpki-trust-anchors-20210817/debian/control	2021-08-17 00:53:56.0 +0200
@@ -2,7 +2,7 @@
 Section: net
 Priority: optional
 Maintainer: Marco d'Itri 
-Standards-Version: 4.4.1.1
+Standards-Version: 4.5.1.0
 Rules-Requires-Root: no
 Build-Depends: debhelper-compat (= 12), po-debconf
 Vcs-Git: https://salsa.debian.org/md/rpki-trust-anchors.git
diff -Nru rpki-trust-anchors-20210417/debian/po/es.po rpki-trust-anchors-20210817/debian/po/es.po
--- rpki-trust-anchors-20210417/debian/po/es.po	1970-01-01 01:00:00.0 +0100
+++ rpki-trust-anchors-20210817/debian/po/es.po	2021-08-17 00:39:31.0 +0200
@@ -0,0 +1,47 @@
+# rpki-trust-anchors po-debconf translation to Spanish.
+# Copyright (C) 2021
+# This file is distributed under the same license as the rpki-trust-anchors package.
+# Camaleón , 2021.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: rpki-trust-anchors\n"
+"Report-Msgid-Bugs-To: rpki-trust-anch...@packages.debian.org\n"
+"POT-Creation-Date: 2019-12-14 17:54+0100\n"
+"PO-Revision-Date: 2021-04-18 10:31+0200\n"
+"Last-Translator: Camaleón \n"
+"Language-Team: Debian Spanish \n"
+"Language: es\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Type: boolean
+#. Description
+#: ../rpki-trust-anchors.templates:1001
+msgid "Do you accept the ARIN Relying Party Agreement (RPA)?"
+msgstr "¿Acepta el acuerdo de confianza (Relying Party Agreement, RPA) de ARIN?"
+
+#. Type: boolean
+#. Description
+#: ../rpki-trust-anchors.templates:1001
+msgid ""
+"ARIN forbids third parties from distributing the Trust Anchor Locator (TAL) "
+"for their RPKI repository, hence this package can download it only if you "
+"will agree to ARIN's conditions."
+msgstr ""
+"ARIN prohíbe la distribución a terceras partes del localizador de ancla de "
+"confianza (Trust Anchor Locator, TAL) desde su repositorio RPKI, por lo que "
+"solo puede descargar este paquete si acepta las condiciones de ARIN."
+
+#. Type: boolean
+#. Description
+#: ../rpki-trust-anchors.templates:1001
+msgid ""
+"If you want that this package automatically download and installs the ARIN "
+"TAL, then you need to accept the ARIN Relying Party Agreement (RPA): https://";
+"www.arin.net/resources/manage/rpki/rpa.pdf ."
+msgstr ""
+"Si desea que este paquete se descargue automáticamente e instale el TAL de "
+"ARIN, tiene que aceptar el acuerdo de confianza de ARIN (Relying Party "
+"Agreement, RPA): «https://www.arin.net/resources/manage/rpki/rpa.pdf».";
\ Manca newline alla fine del file
diff -Nru rpki-trust-anchors-20210417/tals/lacnic.tal rpki-trust-anchors-20210817/tals/lacnic.tal
--- rpki-trust-anchors-20210417/tals/lacnic.tal	2021-04-17 03:31:46.0 +0200
+++ rpki-trust-anchors-20210817/tals/lacnic.tal	2021-08-17 00:42:23.0 +0200
@@ -1,3 +1,4 @@
+https://rrdp.lacnic.net/ta/rta-lacnic-rpki.cer
 rsync://repository.lacnic.net/rpki/lacnic/rta-lacnic-rpki.cer
 
 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqZEzhYK0+PtDOPfub/KR


signature.asc
Description: PGP signature

Bug#993039: ejabberd: Please add autopkgtests

2021-08-26 Thread James Valleroy

Package: ejabberd
Severity: wishlist
X-Debbugs-Cc: jvalle...@mailbox.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please consider adding some autopkgtests, hopefully including one that
starts the ejabberd service. This is so that when bugs like #992998
come up, the packages causing the breakage can automatically be
prevented from migrating to testing.

-BEGIN PGP SIGNATURE-

iQJKBAEBCgA0FiEEfWrbdQ+RCFWJSEvmd8DHXntlCAgFAmEn2H4WHGp2YWxsZXJv
eUBtYWlsYm94Lm9yZwAKCRB3wMdee2UICKeTD/974sjvekWGpOz/+RH4wERQOyfY
8buvSbqXV3j8Aj5av2QACKvMJwAG4dYZxEvkozTvtn6fFJuoHVE5jR+XkefktVqK
YAJYPcyBKLSKiSF3dsowkp2e6HaGq9Wc4RFMT/amg5jh5V7iUTdFu8VuHM2asnwx
CSwwCNJdo90lCmkKZDMdoJKTV/8qP3CYHZGKTf0bHwwQ6Wp8QifXhmBAoTMaJSk8
X7oxs6QPaWbD+11YsvAagoFCvfLSKE/PqPIeEJa1pY/B4gCk3eqW11H/TckfhxeA
rQJ1IkVTnzY3qYoX4+TadwhLX4GrDqv3Blcu5stw71qD4ehcBhf5P/L3l6DyTAux
HcLFQyQqgYB3QvmqMo3+Y6v82OIxzObzy6kJ6JwuJKR8Gqr2SQVNXa6k0eetz+v+
rWVufo4yTZCfmHug9QUKSOx1nO0xw4J4QzTZwc3/0hz9EIDayWwwY1BYpKDS4xj6
l9a6GEYbLXrqZ1JS0wmP+EZvxjEpfkJt1hWQccCW6n1LvSgjxrZ01rgtH/vfBorj
6dWNkK2FPKaoxp0SKQP+AgnP8NTghxh+8FfA8kOzVTnkXUV+sVzRlYvrPB0jGWV8
eaW4GdYELYAWftbPUvO63+nCscSJqTax0s3DFmuEih9SVWzt1v8S8JmBJxLkYXWE
dmY5e/JH+HZITJsSdw==
=iuUw
-END PGP SIGNATURE-

Bug#988146: Fwd: Inconsistent behavior creating partitions with 'Xmib' and 'X%' (off-by-1 error?)

2021-08-26 Thread Diederik de Haas

On zondag 22 augustus 2021 20:53:05 CEST you wrote:
> Control: forwarded -1 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21136
> 
> I tried to forward this bug to the upstream bug-par...@gnu.org ML to get
> some progress and I've 'attached' that to this bug report.

With quite a bit delay, but https://debbugs.gnu.org/50168 was eventually 
created. And I just received a message that it was closed.
Personally, I think the 'explanation' is ridiculous.
So if partition 3 ends at '60mib' and the 4th starts at that, which is imo 
what most/normal people would do, it is expected to fail.
But I'm glad he explained the error message ...

Also he mentioned 'MiB' while it appears that that is a crucial distinction 
wrt 'mib' (and is where the forwarded bug report is about).

Maintainers: afaic you're free to close the bug as I doubt very much the issue 
will receive an appropriate fix.

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

Bug#993048: mosquitto init script broken with bullseye update

2021-08-26 Thread Chris Zubrzycki

Package: mosquitto
Version: 2.0.11-1
Severity: important
Tags: patch

Dear Maintainer,

With the 2.0 upgrade, mosquitto now writes a pid file on it's own as the
mosquitto user. This breaks the init script as the run directory is root
writable, and on top of that the init script uses s-s-d to also write a
root-owned pid file. The attached patch should match the behavior of the
systemd file, which is let the daemon write it's own pid file in
/var/run/mosquitto/ and chowns the dir to allow it. I have disabled
s-s-d from making a root owned file, and also added a match to the
mosquitto user for stopping/reloading as the new policy says non-root
pid files are insecure unless additional matches are present.


Oh, and listener 1883 needs to be added ito the config otherwise mosquitto
only listens on loopback which will break most existing installs.

references:
https://issues.apache.org/jira/secure/attachment/13001569/0001-Fix-init-script-for-debian-Buster.patch
https://github.com/eclipse/mosquitto/issues/1950

-- System Information:
Debian Release: 11.0
 APT prefers stable
 APT policy: (700, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
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 /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages mosquitto depends on:
ii  adduser3.118
ii  libc6  2.31-13
ii  libcjson1  1.7.14-1
ii  libdlt22.18.6-1
ii  libelogind0 [libsystemd0]  246.9.1-1+debian1
ii  libmosquitto1  2.0.11-1
ii  libssl1.1  1.1.1k-1
ii  libwebsockets164.0.20-2
ii  libwrap0   7.6.q-31
ii  lsb-base   11.1.0

mosquitto recommends no packages.

Versions of packages mosquitto suggests:
ii  apparmor  2.13.6-10

-- Configuration Files:
/etc/init.d/mosquitto changed:
set -e
PIDFILE=/run/mosquitto/mosquitto.pid
DAEMON=/usr/sbin/mosquitto
USER=mosquitto
test -x ${DAEMON} || exit 0
umask 022
. /lib/lsb/init-functions
run_by_init() {
   ([ "$previous" ] && [ "$runlevel" ]) || [ "$runlevel" = S ]
}
export PATH="${PATH:+$PATH:}/usr/sbin:/sbin"
case "$1" in
 start)
if init_is_upstart; then
exit 1
fi
log_daemon_msg "Starting network daemon:" "mosquitto"
/bin/mkdir -m 740 -p /var/log/mosquitto
/bin/chown mosquitto /var/log/mosquitto
/bin/mkdir -m 740 -p /run/mosquitto
/bin/chown mosquitto /run/mosquitto
if start-stop-daemon --start --quiet --oknodo --background  --user 
${USER} --pidfile ${PIDFILE} --exec ${DAEMON} -- -c 
/etc/mosquitto/mosquitto.conf ; then
log_end_msg 0
else
log_end_msg 1
fi
;;
 stop)
if init_is_upstart; then
exit 0
fi
log_daemon_msg "Stopping network daemon:" "mosquitto"
if start-stop-daemon --stop --quiet --oknodo --user ${USER} --pidfile 
${PIDFILE}; then
log_end_msg 0
rm -f ${PIDFILE}
else
log_end_msg 1
fi
;;
 reload|force-reload)
if init_is_upstart; then
exit 1
fi
log_daemon_msg "Reloading network daemon configuration:" "mosquitto"
   if start-stop-daemon --stop --signal HUP --quiet --oknodo --user ${USER} 
--pidfile $PIDFILE; then
   log_end_msg 0
   else
   log_end_msg 1
   fi   
;;
 restart)
if init_is_upstart; then
exit 1
fi
log_daemon_msg "Restarting network daemon:" "mosquitto"
if start-stop-daemon --stop --quiet --oknodo --retry 30 --user ${USER} 
--pidfile ${PIDFILE}; then
rm -f ${PIDFILE}
fi

/bin/mkdir -m 740 -p /var/log/mosquitto
/bin/chown mosquitto /var/log/mosquitto
/bin/mkdir -m 740 -p /run/mosquitto
/bin/chown mosquitto /run/mosquitto
if start-stop-daemon --start --quiet --oknodo --background --pidfile 
${PIDFILE} --user ${USER} --exec ${DAEMON} -- -c /etc/mosquitto/mosquitto.conf 
; then
log_end_msg 0
else
log_end_msg 1
fi
;;
 try-restart)
if init_is_upstart; then
exit 1
fi
log_daemon_msg "Restarting Mosquitto message broker" "mosquitto"
set +e
start-stop-daemon --stop --quiet --retry 30 --pidfile ${PIDFILE}
RET="$?"
set -e
case $RET in
0)
# old daemon stopped
rm -f ${PIDFILE}
if start-stop-daemon --start --quiet --oknodo --background 
--pidfile ${PIDFILE} --user ${USER} --exec ${DAEMON} -- -c 
/etc/mosquitto/mosquitto.conf ; then
log_end_msg 0
else
log_end_msg 1
fi
;;
1)

Bug#923396: file -e should silently ignore nonexistent testnames

Control: fixed 923396 1:5.39-1

On 2021-08-26 19:59:18 +0200, Christoph Biedl wrote:
> Control: fixed 923396 1:5.39-1

Really marking as fixed in this version (it seems that Control lines
are ignored in mail to -done@b.d.o addresses).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#992034: installation-guide: Include a note on how to change init system during install

2021-08-26 Thread Charles Curley

On Thu, 26 Aug 2021 22:45:17 +0200
Holger Wansing  wrote:

> I wonder if "the easiest time to select an alternative init system is
> during the installation process" is correct English.
> 
> Maybe better "the best time ... " ?

Much better, although both are literally true. From an native American
speaker.


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Bug#991532: fixed in vmdb2 0.24-1)

2021-08-26 Thread Diederik de Haas

Thank you for updating vmdb2 to 0.24!

On donderdag 26 augustus 2021 18:57:07 CEST you wrote:
> afaict the qemu-debootstrap plugin is still available and doesn't alert
> the user of its deprecation.
> And I think it should, by at least outputting/logging a warning and
> possibly switching to error/fail (over time?).

I'm not sure what to do about it as I think the above quoted part is still 
true and therefor a future problem.
It began with me not entirely correctly marking the issue as fixed-upstream.
While it should now be possible to replace the qemu-debootstrap element in 
yaml files with (plain) debootstrap, upstream still 'happily' invokes qemu-
debootstrap without issuing a warning (or error). And I think it should to 
actively steer people away from qemu-debootstrap.
(Currently qemu-debootstrap 'redirects' the call to normal debootstrap, but 
that will probably not forever be the case)

But I also saw recently a somewhat worrying commit:
say in README project is in "selfish maintenance mode"
https://gitlab.com/larswirzenius/vmdb2/-/commit/
cbd86eb1b70738793b8849bbac54f4a28a1dbe33

So that doesn't look good.

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

Bug#983427: libpam-runtime: please add support for DPKG_ROOT

2021-08-26 Thread Johannes Schauer Marin Rodrigues

Hi sam,

Quoting Sam Hartman (2021-08-26 22:23:18)
> > "Johannes" == Johannes 'josch' Schauer  writes:
> 
> Johannes> diff --git a/debian/libpam-runtime.postinst
> 
> I think that your patch ends up with things like $confdir set to
> "//etc/pam.d" when $DPKG_ROOT is empty.  You get one slash from the
> initialization of the variable and one slash from the separator in the
> code you added.
> 
> 
> Please review the following alternate patch hopefully before it makes
> its way into testing:

you are right and your changed patch looks good to me. I just tested your patch
in our salsaci setup and there does not seem to be a regression.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#993031: ripser FTCBFS: hard codes the build architecture compiler

2021-08-26 Thread Gard Spreemann



Thanks! Including your patch in a new upload now.

 -- Gard

Bug#991463: fixed in knot-resolver 5.4.1-1

2021-08-26 Thread Santiago Ruano Rincón

El 26/08/21 a las 14:45, Jakub Ružička escribió:
> > - Includes fix for CVE-2021-40083 (Closes: #991463)
> 
> I've used this magic syntax found throughout the changelog and it closed
> the bug upon experimental upload, which isn't what I expected. Please
> reopen as needed, I'm not yet familiar with handling bugs wrt different
> Debian branches.
> 

Why would you like to reopen the bug? The BTS knows it is still to be
fixed in unstable. Take a look at the image at the top right of the bug
report page:
https://bugs.debian.org/cgi-bin/version.cgi?absolute=0;found=knot-resolver%2F5.3.1-1;info=1;fixed=knot-resolver%2F5.4.1-1;collapse=1;package=knot-resolver

> Regardless, experimental knot-resolver-5.4.1-1 built against
> experimental knot-3.1.1-3 so I'll try to proceed with the transition
> which should fix the bug for sid.

Awesome, thanks!

> After that I plan to cherry-pick the fix for next bullseye-point release.

Did you have any feedback from the security team?

💤,

 -- S


signature.asc
Description: PGP signature

Bug#983427: libpam-runtime: please add support for DPKG_ROOT

2021-08-26 Thread Sam Hartman

> "Johannes" == Johannes 'josch' Schauer  writes:

Johannes> diff --git a/debian/libpam-runtime.postinst

I think that your patch ends up with things like $confdir set to
"//etc/pam.d" when $DPKG_ROOT is empty.  You get one slash from the
initialization of the variable and one slash from the separator in the
code you added.


Please review the following alternate patch hopefully before it makes
its way into testing:

commit b296f47cab5c8d97e2d57ef35694ba8328a9477f
Author: Sam Hartman 
Date:   Thu Aug 26 14:17:22 2021 -0600

pam-auth-update: support DPKG_ROOT

Patch from Johannes 'josch' Schauer to implement a --root argument to
pam-auth-update and to use it in the call in libpam-runtime.
* debian/local/pam-auth-update: support --root

* debian/libpam-runtime.postinst: call with --root $DPKG_ROOT

diff --git a/debian/changelog b/debian/changelog
index 848f13c0..96dd28fc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -5,6 +5,8 @@ pam (1.4.0-10) UNRELEASED; urgency=medium
   * Include upstream patch not to use crypt_checksalt; without this
 passwords set prior to bullseye were considered expired, Closes:
 #992848
+  * Support DPKG_ROOT for pam-auth-update, thanks Johannes 'josch' Schauer
+Closes: #983427
 
  -- Sam Hartman   Thu, 26 Aug 2021 13:43:23 -0600
 
diff --git a/debian/libpam-runtime.postinst b/debian/libpam-runtime.postinst
index 518e8d24..053fdae2 100644
--- a/debian/libpam-runtime.postinst
+++ b/debian/libpam-runtime.postinst
@@ -29,7 +29,7 @@ then
done
 fi
 
-pam-auth-update --package $force
+pam-auth-update --root "$DPKG_ROOT" --package $force
 
 if [ -n "$force" ]; then
rm -f /etc/pam.d/common-auth.pam-old \
diff --git a/debian/local/pam-auth-update b/debian/local/pam-auth-update
index 5b3c8a07..6c4134bb 100644
--- a/debian/local/pam-auth-update
+++ b/debian/local/pam-auth-update
@@ -88,6 +88,11 @@ while ($#ARGV >= 0) {
$force = 1;
} elsif ($opt eq '--package') {
$package = 1;
+} elsif ($opt eq '--root') {
+my $rootdir = shift @ARGV;
+$savedir = "${rootdir}$savedir";
+$confdir = "${rootdir}$confdir";
+   $inputdir = "${rootdir}$inputdir";
} elsif ($opt eq '--remove') {
while ($#ARGV >= 0) {
last if ($ARGV[0] =~ /^--/);


signature.asc
Description: PGP signature

Bug#993046: libssh: CVE-2021-3634

2021-08-26 Thread Salvatore Bonaccorso

Source: libssh
Version: 0.9.5-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libssh.

CVE-2021-3634[0]:
| Possible heap-buffer overflow when rekeying

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-3634
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3634
[1] https://www.libssh.org/security/advisories/CVE-2021-3634.txt
[2] 
https://git.libssh.org/projects/libssh.git/commit/?id=d3060bc84ed4e160082e819b4d404f76df7c8063

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#977790: (no subject)

2021-08-26 Thread unxed

Please update far2l debian package 
https://mentors.debian.net/package/far2l/


as recent far2l has license-problem-convert-utf-code problem fixed 
(ConvertUTF is removed).


Thanks!

Bug#992610: dh-make-golang make fails when no main, no external module dependency

2021-08-26 Thread Anthony Fok

Control: title -1 dh-make-golang fails with "../.." in import path

Hi Kentaro,

Thank you for reporting this issue.

On Fri, Aug 20, 2021 at 10:57 PM Kentaro Hayashi  wrote:
> Package: dh-make-golang
> Version: 0.4.0-1+b6
> Severity: normal
> X-Debbugs-Cc: ken...@xdump.org
>
> # Problem:
>
> When dh-make-golang make is executed for library without no main, no external
> module dependencies, it seems that dh-make-golang will fail.

No, that is not it.  Plenty of existing Go pure library packages (with
no main.go) have been created by dh-make-golang with no issues at all.

The real culprit turns out to be the following code in example/main.go:

import (
"../../notificator"
"log"
)

Relative import path, especially one that refers to a (grand)parent
directory, and such practice is not supported by Go.
It is the "go list github.com/0xAX/notificator/..." command that fails here.

Indeed, other 0xAX/notificator users have run into issue too:
https://github.com/0xAX/notificator/issues

So, it is not a bug in dh-make-golang but in github.com/0xAX/notificator

That said, I'll add in a workaround that retries running "go list"
without the "/...".
This would allow "go list" to avoid such problematic subdirectory.

> I've found this issue against the following case:
>
> $ dh-make-golang make github.com/0xax/notificator

Please note that Go import paths are case-sensitive.
Please follow how upstream has used uppercase for "AX" in "0xAX", as in:

$ dh-make-golang make github.com/0xAX/notificator

Kind regards,

Anthony

Bug#993045: Please bring back the -unsafe-string switch

2021-08-26 Thread Julien Puydt

Package: ocaml
Version: 4.11.1-4

a part of scilab (modelica) is written in OCaml, but needs the -unsafe-
string switch ; unfortunately:

/usr/bin/ocaml: OCaml has been configured with -force-safe-string: -
unsafe-string is not available.

Can you please re-enable unsafe strings?

Thanks,

J.Puydt

Bug#989494: buster-pu: package http-parser/2.8.1-1

Christoph Biedl wrote...

> there is a minor (non-DSA) security issue open in the Debian 10
> ("buster") version of http-parser, and I'd like to fix that in a stable
> point release. This is #977467 [CVE-2019-15605].

Now uploaded in the hope it will help to resolve the issue.

Christoph



signature.asc
Description: PGP signature

Bug#993044: libxcrypt breaks existing password hashes

2021-08-26 Thread Sam Hartman

package: libxcrypt
version: 1:4.4.22-1
severity: serious
justification: breaks login

See bug #992848.
Because of the way libpam0g calls libxcrypt any existing sha256 hash
will be rejected at login as expired.
I'm going to fix this in pam using the linux-pam upstream fix, but
libxcrypt should not migrate to testing before the fixed pam is in
testing.

This bug is intended to block that migration.
Feel free to do something else that blocks the migration.
If this bug is still open when libpam migrates, I'll close it.


signature.asc
Description: PGP signature

Bug#992133: firebird4.0 debian packaging

2021-08-26 Thread Damyan Ivanov

-=| Frank Doepper, 26.08.2021 10:42:33 +0200 |=-
> I tried this (commit f89edee), but it fails again on sid with the 
> same libre2 linker error.

Bummer.

> I think that's a clash between bundled libre2 and system libre2.

Nah, the bundled libre2 is not part of the orig.tar source and can't 
interfere with the build.

> Although
> configure is called with --with-system-re2, the flags contain
> -I/<>/extern/re2, and I guess that's the problem. Maybe
> debian/patches/out/system-re2.patch needs a second look at.

I agree that removing the -I directive would be nice. This is already 
done for other bundled libraries for which upstream supports using the 
system ones. Patch updated.

-- Damyan

Bug#978863: milter-greylist: ftbfs with autoconf 2.70

2021-08-26 Thread Sudip Mukherjee

Hi,

On Thu, Dec 31, 2020 at 02:28:20PM +, Matthias Klose wrote:
> Package: src:milter-greylist
> Version: 4.6.2-1
> Severity: normal
> Tags: sid bookworm
> User: d...@debian.org
> Usertags: ftbfs-ac270
> 
> [This bug report is not targeted to the upcoming bullseye release]
> 
> The package fails to build in a test rebuild on at least amd64 with
> autoconf 2.70, but succeeds to build with autoconf 2.69. The
> severity of this report will be raised before the bookworm release,
> so nothing has to be done for the bullseye release.

I am not seeing the FTBFS with autoconf 2.71-2 present in unstable now.
Please check https://salsa.debian.org/debian/milter-greylist/-/pipelines/281026

Can you please retest and confirm.


--
Regards
Sudip

Bug#979974: cloud-init wait an unnecessary timeout

2021-08-26 Thread Noah Meyerhans

Control: tags -1 + upstream fixed upstream

On Tue, Jan 12, 2021 at 01:57:27PM +0100, Matteo Croce wrote:
> At boot cloud-init waits 120 seconds for an ephemeral disk, but some
> VM types doesn't have ephemeral storage at all, so this just blocks
> the boot for 120 seconds:
> 
> Jan 12 11:23:13 mcroce-buster cloud-init[506]: 2021-01-12 11:23:13,608
> - azure.py[WARNING]: ephemeral device '/dev/disk/cloud/azure_resource'
> did not appear after 120 seconds.
> 
> Please consider mounting the disk upon attach.

I believe that this was fixed upstream with
https://github.com/canonical/cloud-init/pull/800, which was released
with cloud-init 21.2

So the fix should be available in unstable and testing at this time.  I
don't have the ability to launch an Azure VM to confirm this, so if
you're able to do so, that would be appreciated.  We can then consider
options for (old)stable branches.

noah

Bug#927397: networking fails with A20-OLinuXino-Lime2-eMMC Rev. G2 and bullseye u-boot and -kernel

2021-08-26 Thread Andreas Mundt

Hi all,

the last days, I tried upgrading two A20-OLinuXino-Lime2 boards to bullseye.
After booting the bullseye kernel, 5.10.46-4 (2021-08-03), the network did 
not work anymore: The interface shows up (IIRC, even a link is detected),
but any attempts to connect (DHCP) fail.  

After playing with different delays following [1], I succeeded with 
CONFIG_GMAC_TX_DELAY=4, where both boards seem to work fine. I also played a
bit with iperf3:  At higher bitrates (> approx. 200Mbits/s) more and more 
retries seem to be needed.  So the issue this bug is about seems to affect
also the G2 revision boards that worked fine so far.

Best regards,

  Andi


[1] 
https://wiki.debian.org/InstallingDebianOn/Allwinner#Olimex_A20-OLinuXino-LIME2_rev._K.3B_rev._G2_and_bullseye_kernel

Bug#993043: ensmallen: autopkgtest regression on arm64/i386/ppc64el

Source: ensmallen
Version: 2.17.0-2
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/arm64/e/ensmallen/14865434/log.gz
https://ci.debian.net/data/autopkgtest/testing/i386/e/ensmallen/14865770/log.gz
https://ci.debian.net/data/autopkgtest/testing/ppc64el/e/ensmallen/14865925/log.gz

...
---
MOEADZDTONETest
---
tests/moead_test.cpp:510
...

tests/moead_test.cpp:544: FAILED:
  REQUIRE( g == Approx(1.0).margin(0.99) )
with expansion:
  2.1844866419 == Approx( 1.0 )
...

Bug#993042: nim FTBFS on armhf when built on arm64 hardware

Source: nim
Version: 1.4.8-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=nim&arch=armhf&ver=1.4.8-2&stamp=1629152447&raw=0

...
   dh_auto_configure -a
install -d /<>/debian/.debhelper/generated/_source/home
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
echo "running make to build ./bin/nim from csources"
running make to build ./bin/nim from csources
PATH=./bin/:$PATH  make -j
make[2]: Entering directory '/<>'
makefile:164: *** unknown processor: armv8l.  Stop.


The uname usage in tools/niminst/makefile.nimf is fragile.

Adding cases for armv8l and armv9l might work due to the Debian buildds
using setarch, without that a 32bit on a 64bit system would even be
misdetected as arm64.

Bug#992694: reprotest: kernel variation makes ldconfig abort with message "FATAL: Kernel too old"

2021-08-26 Thread Baptiste Beauplat

On 2021/08/26 04:25 PM, Mattia Rizzolo wrote:
> 
> What would you say about this patch:
> 
> |--- a/README.rst
> |+++ b/README.rst
> |@@ -378,9 +378,9 @@ mechanism to vary the system time.
> | Kernel
> | --
> |
> |-The "kernel" variation is currently not working for RPM based packages. 
> While
> |-building with this variation enabled, the tool 
> `/usr/lib/rpm/redhat/brp-ldconfig`
> |-compains about `FATAL: kernel too old` and aborts the build.
> |+The "kernel" variation is currently not working for RPM based packages and 
> other
> |+build process requiring `ldconfig`.  While building with this variation 
> enabled,
> |+`ldconfig` complains about `FATAL: kernel too old` and aborts the build.
> |
> | Avoid sudo(1) password prompts
> | ==

Looks good to me.

> Besides potentially better identifying which versions of ldconfig are
> effectively broken, I don't think we could do much else.

IIRC, the change was introduced by

https://salsa.debian.org/glibc-team/glibc/-/commit/2d7aa68d5d30a203b61b551432efcefac7413885#98f7bc9994884d56cdc1b30b364e50f8800dbc07_147_147

which was packaged with glibc-2.25.

I agree. A possibility would be to introduce a '--uname-3.2' to setarch
and I don't think, for the number of packages using ldconfig at build
time, this is worth the trouble (specially since upstream might not be
interested by it).

-- 
Baptiste Beauplat - lyknode


signature.asc
Description: PGP signature

Bug#993041: libopenmpi3: Overwriting file which is also in package libopenmpi-dev

Package: libopenmpi3
Version: 4.1.1-2
Severity: serious

...
Unpacking libopenmpi3:amd64 (4.1.1-2) over (4.1.0-10) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-o2pk7b/32-libopenmpi3_4.1.1-2_amd64.deb (--unpack):
 trying to overwrite 
'/usr/lib/x86_64-linux-gnu/openmpi/lib/libopen-orted-mpir.so', which is also in 
package libopenmpi-dev:amd64 4.1.1-2
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
...

Bug#993040: htscodecs FTBFS on i386

Source: htscodecs
Version: 1.1.1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=htscodecs&arch=i386&ver=1.1.1-1&stamp=162111&raw=0

...
mkdir -p  debian/libhtscodecs-dev/usr/lib/i686-linux-gnu
mv debian/tmp/usr/lib/i686-linux-gnu/libhtscodecs.a 
debian/libhtscodecs-dev/usr/lib/i686-linux-gnu/
mv: cannot stat 'debian/tmp/usr/lib/i686-linux-gnu/libhtscodecs.a': No such 
file or directory
make[1]: *** [debian/rules:26: override_dh_auto_install] Error 1


debian/rules should use DEB_HOST_MULTIARCH instead of DEB_TARGET_GNU_TYPE.

Bug#976313: new magic: plocate database

Control: tags 976313 confirmed moreinfo

Thanks for your patience ...


Steinar H. Gunderson wrote...

> Here's a suggested magic entry for plocate databases:
>
(...)
> 0   string  \0plocate   plocate database
> >8  long0   \b, version %d (obsolete)
> >8  long>0  \b, version %d
> >>40longx   \b, max version %d

That will lead to ... interesting results on plocate files created on
big-endian hosts, like

| plocate database, version 16777216, max version 33554432

My suggestion is to probe for a plausible version number. Assuming you
will not get up to 8 any time soon, I'd do:

0   string  \0plocate   plocate database
>8  lelong  0   \b, version %d (obsolete)
>8  lelong  !0
>>8 lelong  <8  \b, little endian, version %d
>>>40   lelong  x   \b, max version %d
>>8 belong  <8  \b, big endian, version %d
>>>40   belong  x   \b, max version %d

Does that look good to you?

Christoph


signature.asc
Description: PGP signature

Bug#911560: networking fails with A20-OLinuXino-Lime2-eMMC Rev. G2 and bullseye u-boot and -kernel

2021-08-26 Thread Jonas Smedegaard

Control: retitle -1 A20-OLinuXino-Lime2-eMMC Rev. K: very poor ethernet 
performance

Hi Andreas,

Quoting Andreas B. Mundt (2021-08-26 20:01:16)
> Control: retitle -1 A20-OLinuXino-Lime2-(eMMC): Rev. K, G2: very poor/no 
> ethernet performance

Please re-post your info about rev.G board to bug#927397 - thanks!


 - Jonas

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

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

signature.asc
Description: signature

Bug#911560: networking fails with A20-OLinuXino-Lime2-eMMC Rev. G2 and bullseye u-boot and -kernel

2021-08-26 Thread Andreas B. Mundt

Control: retitle -1 A20-OLinuXino-Lime2-(eMMC): Rev. K, G2: very poor/no 
ethernet performance


Hi all,

the last days, I tried upgrading two A20-OLinuXino-Lime2 boards to bullseye.
After booting the bullseye kernel, 5.10.46-4 (2021-08-03), the network did 
not work anymore: The interface shows up (IIRC, even a link is detected),
but any attempts to connect (DHCP) fail.  

After playing with different delays following [1], I succeeded with 
CONFIG_GMAC_TX_DELAY=4, where both boards seem to work fine. I also played a
bit with iperf3:  At higher bitrates (> approx. 200Mbits/s) more and more 
retries seem to be needed.  So the issue this bug is about seems to affect
also the G2 revision boards that worked fine so far.

Best regards,

  Andi


[1] 
https://wiki.debian.org/InstallingDebianOn/Allwinner#Olimex_A20-OLinuXino-LIME2_rev._K.3B_rev._G2_and_bullseye_kernel

Bug#893851: ffcall: Fix build for MIPS release 6

2021-08-26 Thread Sébastien Villemot

Dear YunQiang,

Le mercredi 28 mars 2018 à 10:49 +0200, Sébastien Villemot a écrit :
> On Fri, Mar 23, 2018 at 09:38:04PM +0800, YunQiang Su wrote:
> > On Fri, Mar 23, 2018 at 8:41 PM, Sébastien Villemot
> >  wrote:
> > > On Fri, Mar 23, 2018 at 08:02:58PM +0800, YunQiang Su wrote:
> > > > On Fri, Mar 23, 2018 at 7:58 PM, YunQiang Su  wrote:
> > > > > On Fri, Mar 23, 2018 at 7:27 PM, Sébastien Villemot
> > > > >  wrote:
> > > > > > Dear YunQiang,
> > > > > > 
> > > > > > On Fri, Mar 23, 2018 at 06:15:08PM +0800, YunQiang Su wrote:
> > > > > > > Package: src:ffcall
> > > > > > > Version: 2.1-1
> > > > > > > 
> > > > > > > MIPS release 6 drops some instructions: bnel/beql included.
> > > > > > > For r6, we should use bne/beq for replace.
> > > > > > > 
> > > > > > > The patch has submit in salsa as a merge request.
> > > > > > > 
> > > > > > > https://salsa.debian.org/common-lisp-team/ffcall/merge_requests/1
> > > > > > 
> > > > > > Thanks for your report and your patch.
> > > > > > 
> > > > > > You may have overlooked the fact that these assembly files are 
> > > > > > actually
> > > > > > generated by GCC from C source code (see the DEP-3 header of
> > > > > > debian/patches/mips-fpxx.patch), so your proposed patch is not very
> > > > > > maintainable in the long term.
> > > > > 
> > > > > Oh, thanks. Since then, I guess we should generate these .S files
> > > > > when build instead of put them in the source code.
> > > > > 
> > > > > I will have a look at it.
> > > > 
> > > > After read Makefile.devel, I think that we should call the right
> > > > target in debian/rules.
> > > > Should this the ideal way?
> > > 
> > > This could be a possiblity, but this is not supported by upstream. And we 
> > > would
> > > have to patch this Makefile.devel to make it work (it expects non-standard
> > > names for GCC). So I do not really like this solution.
> > > 
> > 
> > In fact we can patch it to use $(CC), and pass it when we call these 
> > targets,
> > and then we can drop the patch for the .S/.s files.
> > The length of patch file will be much shorter.
> > 
> > Anyway, we will have to patch it.
> > Wish my attached patch can change your mind. ;)
> 
> I really don't like the kludge for mips in debian/rules.
> 
> I think that all things considered I prefer your very first patch, which had
> the advantage of being very small.

I just wanted to inform you that, with the upload of ffcall 2.4, I had
to drop your MIPS r6, because it no longer applies, and I don’t know
how to refresh it.

I think this shows that the best solution for MIPS r6 support would
rather be to work directly with upstream, rather than applying a
Debian-specific patch.

Best regards,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#810501: file: no detection for dosbox's pcjr rom cartrage format

Control: tags 810501 pending

Francis Laniel wrote...

> I sent a patch to file which implements the detection of PCjr cartridge file 
> based on the information given in this bug report.

Thanks, will be fixed in the next upload which will hopefully take less
than two weeks.

Christoph


signature.asc
Description: PGP signature

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

2021-08-26 Thread Chuck Zmudzinski


On 8/26/2021 8:01 AM, Chuck Zmudzinski wrote:

On 8/24/2021 7:12 PM, Ben Hutchings wrote:


The current limit on the environment of a uevent appears to be 2 KB
(UEVENT_BUFFER_SIZE defined in ).ï¿½ That seems like it
*might* be easier to change, so long as user-space doesn't have a
similar limit.

I looked into systemd/udev, and it seems to use an 8 KB buffer for
receiving uevents:

https://sources.debian.org/src/systemd/247.9-1/src/libsystemd/sd-device/device-monitor.c/?hl=390#L390 



But as a first step I think increasing the kernel buffer size to 4 KB
would be enough.ï¿½ Perhaps someone could test whether this patch to the
domU kernel makes udev happier:

--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -30,7 +30,7 @@
ï¿½ ï¿½ #define UEVENT_HELPER_PATH_LENï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ 256
ï¿½ #define UEVENT_NUM_ENVPï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ 64ï¿½ï¿½ï¿½ /* 
number of env pointers */
-#define UEVENT_BUFFER_SIZEï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ 2048ï¿½ï¿½ï¿½ /* buffer for the 
variables */
+#define UEVENT_BUFFER_SIZEï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ 4096ï¿½ï¿½ï¿½ /* buffer for the 
variables */

ï¿½ ï¿½ #ifdef CONFIG_UEVENT_HELPER
ï¿½ /* path to the userspace helper executed on an event */
--- END ---

?

Ben.



I tested this patch on my Xen HVM bullseye system and
it appears 4k is enough for the UEVENT_BUFFER_SIZE
to accommodate the Xen Virtual Keyboard's large
modalias. I needed to follow the instructions in
the Kernel team's handbook for changing the ABI
name of the kernel for the build to succeed with
the patch. I just bumped it from 8 to 8.1.

Results:

1. No coldplug failure reported at boot time.

2. With the patch the system can write uevent
data to sysfs for the Xen Virtual Keyboard device.

With the current 5.10.0-8 kernel:

chuckz@debian:~$ cat /sys/devices/virtual/input/input2/uevent
chuckz@debian:~$

With the patched kernel with a change to the ABI version from 8 to 8.1:

chuckz@debian:~$ uname -r
5.10.0-8.1-amd64
chuckz@debian:~$ cat /sys/devices/virtual/input/input2/uevent
PRODUCT=1/5853//0
NAME="Xen Virtual Keyboard"
PHYS="xenbus/device/vkbd/0"
PROP=0
EV=3
KEY=7fff  ...
MODALIAS=input:b0001v5853pe-e0,1,k71,72... really long MODALIAS
--- 



So I think a test of the installation media in a Xen HVM with the
4k buffer in the kernel is the next step.

I would also like to test a live CD in a Xen HVM with this patch.
It was also reported to fail to boot in a Xen HVM on the
debian-user list.

BTW, my complements to the Debian Kernel Team for the
excellent handbook on building kernels for Debian. It is
easy to understand and made it very easy for me to
build and test the patch even though I have not built
a Linux kernel in many years, and I never built a Debian
kernel before.

All the best,

Chuck



Results of more tests with the patched kernel:

1. Boot on dom0 - works normally, can create VMs, run Liinux container, etc.
2. Boot in Xen PV - works normally
3. Boot on bare hardware - works normally

I do not see any issues with the patched kernel on my system.

Cheers,

Chuck

Bug#992848: pam_unix: Treats SHA256 and older hashes as expired

2021-08-26 Thread Sam Hartman

> "Paul" == Paul Menzel  writes:

Paul> Dear Mattias, Thank you for the analysis. I hit this too, and
Paul> GDM autologin did not work anymore [1], so users thought
Paul> Debian crashed during startup.  Switching to tty2 and logging
Paul> in and changing the password there, fixed the issue.

Yes, thanks for the analysis.
I hope to have a pam release including this in Debian in the next few
days.

Bug#993024: debian-fbx: Please add fbx-clients tasks

2021-08-26 Thread James Valleroy

Source: debian-fbx
Severity: wishlist
X-Debbugs-Cc: jvalle...@mailbox.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

We can add an additional binary package "fbx-clients" which suggests
packages that are GUI/desktop (also mobile) clients that work together
with FreedomBox. There is a list of relevant packages on the wiki:
https://wiki.debian.org/FreedomBox/Clients

-BEGIN PGP SIGNATURE-

iQJKBAEBCgA0FiEEfWrbdQ+RCFWJSEvmd8DHXntlCAgFAmEnmrcWHGp2YWxsZXJv
eUBtYWlsYm94Lm9yZwAKCRB3wMdee2UICAIOEACgVSeAk9+B8Vzik0sbd8mXTz1S
w/dhO5omr43LjC/masiGCQPzCtYogAapV0uu1sVIewUVgmzIH5ZjIVPvz07dPLEg
cDqNzzDF9SRErQvUaw6iNsHVxRClAmo3gD7hTvNuiwXnIzgOVIp1bgaO4guf5BHM
ueejjHNWrRqBBr4wjh36F2nNaOHEgENed6VVfLch/H7bBhThuZde0DaNxaK4DYPZ
US2qy1hMDkL3gy8JH59kLPoTwPfq/kusFEP5UAaGuLN6iz45cH98m+Kxe0mAZMqM
wpaWkeSOGDBoywYWvnBmPLdENRWlg/V1dzOQN/J9wDWYr32Qu595NwRAqwWB4EhH
Smg7K/5QGqNgd6VCvl1RT0xDNoWSg5BqgPyx+6/4NonM+m6Qtx94EjXcRrbFIpXX
NETRkkgDeJIvigE3nX2f8grIGgeMAOoU4xd7DBWAOWjcgZGhtlORbcbYD4QsjNX+
hE1JznAEUCSlF2cxN2AgXZ3kdToZUOYR59sKtPQEeakhUd8ykqz5Lch7TamfnVUQ
rPeee6zR3hpiZoj6nyfd0ttm8VrRpn3ie5EEEXlwikw05CdJ2NqeZCyEChmRdqtq
mFyozGYPSYaHnjMu9hdlBs3hKNZDcZxY5cSrvLoK2JEH+XWFP7BlwBlEnkkGOS9q
UbzspdqMUCwHNGHqnw==
=ggaQ
-END PGP SIGNATURE-

Bug#863488: I got the bug after moving the /usr/share directory on ubuntu

Control: tags 863488 moreinfo unreproducible

Никита Кудрявцев wrote...

> for reference: I have two drives, one of which is system and the other is
> for user data, it is mounted in /share.
> I moved /usr/share to /share/usr/share (...)

In other words, you split /usr/ - that scenario isn't supported as it
possibly breaks symbolic links since Debian policy requires them to be
relative within /usr:

| 10.5. Symbolic links
|
| In general, symbolic links within a top-level directory should be
| relative, (...). (A top-level directory is a sub-directory of the root
| directory /.) For example, a symbolic link from /usr/lib/foo to
| /usr/share/bar should be relative (../share/bar), (...).

So the link /usr/share/misc/magic.mgc is relative but since it points
outside /usr/share/, will likely point to nowhere on your system. FWIW,
the links are made relative during build so it was quite hard to provide
absolute links even if I wanted to.

So if you really want to continue on your a bit unusual file system
layout, you'd have to adjust the link on your own, and possibly every
time the package gets updated.

About man, I have no idea why that one fails, strace -f however should
give you an idea.

Christoph


signature.asc
Description: PGP signature

Bug#982354: closed by Debian FTP Masters (reply to Gunnar Wolf ) (Bug#982354: fixed in vmdb2 0.24-1)

2021-08-26 Thread tomas

On Thu, Aug 26, 2021 at 04:57:03PM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the vmdb2 package:
> 
> #982354: vmdb2 build-depends on LaTeX package lmodern
> 
> It has been closed by Debian FTP Masters  
> (reply to Gunnar Wolf ).

[...]

Warmest thanks :)

-- tomás


signature.asc
Description: Digital signature

Bug#949973: closed by maximilian attems (Re: firmware-realtek: kernel error caught)

2021-08-26 Thread pior...@gmail.com


Hi,

My apologies, I forgot about this bug completely and didn't noticed your 
follow up. Now I use different laptop, but it works perfectly with 
Debian 11. Thanks for your work!

Bug#992993: libapt-pkg6.0: infinite recursion in pkgDepCache::MarkPackage

2021-08-26 Thread Aaron M. Ucko

u...@debian.org (Aaron M. Ucko) writes:

> David Kalnischkies  writes:
>
>> Points at my changes in 2.3.3, especially "Mark only provides from
>> protected versioned kernel packages", as the most likely culprit.

I went ahead with git bisect here; it wound up pointing to

  9a54e70c1040379fb06827bacb461c61e341e694 is the first bad commit
  commit 9a54e70c1040379fb06827bacb461c61e341e694
  Author: David Kalnischkies 
  Date:   Thu Mar 18 14:40:31 2021 +0100
  
  Reexplore providers of marked packages if some didn't satisfy before
  
  [...]

Please let me know if you need anything else.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#992890: subversion: Broken pipe on the diff command with --diff-cmd

Control: tags -1 upstream
Control: forwarded -1 https://issues.apache.org/jira/browse/SVN-4879

Confirmed upstream. I've just reported the bug in the issue tracker.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#993038: Duplicate file libopen-orted-mpir.so

2021-08-26 Thread Nicolas Patrois

Package: libopenmpi3
Version: 4.1.0-10
Followup-For: Bug #993038

Dear Maintainer,

reportbug asked me if the bug is in a more recent version of the package, I
asked yes because I couldn’t answer that I don’t know.
Moreover, the bug breaks apt. I can’t fix the broken packages nor finish the
installation of the remaining packages with autoremove. I can’t remove the
libmpi packages either.
I had to use aptitude in order to fix it, either full-upgrade and then removing
libmpi*.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 5.7.0-1-686-pae (SMP w/3 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR:fr:en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libopenmpi3 depends on:
ii  libc62.31-17
ii  libevent-core-2.1-7  2.1.12-stable-1
ii  libevent-pthreads-2.1-7  2.1.12-stable-1
ii  libfabric1   1.11.0-2
ii  libgcc-s111.2.0-3
ii  libhwloc-plugins 2.5.0+dfsg-2
ii  libhwloc15   2.5.0+dfsg-2
ii  libibverbs1  33.2-1
ii  libnl-3-200  3.4.0-1+b1
ii  libpmix2 4.1.0-3
ii  libpsm-infinipath1   3.3+20.604758e7-6.1
ii  libstdc++6   11.2.0-3
ii  zlib1g   1:1.2.11.dfsg-2

libopenmpi3 recommends no packages.

libopenmpi3 suggests no packages.

Bug#993037: Acknowledgement (nextcloud-desktop: Stop working since 3.3.1 release.)

2021-08-26 Thread Christian Marillat

On 26 août 2021 16:45, "Debian Bug Tracking System"  
wrote:

To be sure I did another try.

Close nextcloud from the systray icon
Do a "ps aux| grep -i nextclooud" to be sure that nothing is running.
Delete the current configuration in ~/.config/Nextcloud
Install 3.3.1-2
Create an account
Login : this work.
Close nextcloud
New login : doesn't work

Christian

Bug#993038: Duplicate file libopen-orted-mpir.so

2021-08-26 Thread Yuri D'Elia

Package: libopenmpi-dev
Version: 4.1.1-2
Severity: important

dpkg: error processing archive 
/var/cache/apt/archives/libopenmpi3_4.1.1-2_amd64.deb (--install):
 trying to overwrite 
'/usr/lib/x86_64-linux-gnu/openmpi/lib/libopen-orted-mpir.so', which is also in 
package libopenmpi-dev:amd64 4.1.1-2

Bug#993037: nextcloud-desktop: Stop working since 3.3.1 release.

2021-08-26 Thread Christian Marillat

Package: nextcloud-desktop
Version: 3.3.1-2
Severity: serious

Dear Maintainer,

Since this version nextcloud doesn't work :

Remote nextcloud is 20.1.1

Firefox 88.0.1-1 is my browser.

The firewox windows connexion tell me I'm connected.

The log file :

2021-08-26 18:19:45:841 [ info nextcloud.sync.networkjob ]: 
OCC::SimpleNetworkJob created for "https://cloud.xxx.xx"; + "" ""
2021-08-26 18:19:46:069 [ info nextcloud.sync.credentials.webflow ]:request 
finished
2021-08-26 18:19:46:069 [ warning nextcloud.sync.networkjob ]:  
QNetworkReply::ContentNotFoundError "Server replied \"404 Not Found\" to \"POST 
https://cloud.xxx.xx/index.php/login/v2/poll\""; QVariant(int, 404)
2021-08-26 18:19:46:069 [ warning nextcloud.sync.credentials.webflow ]: 
QNetworkReply::ContentNotFoundError
2021-08-26 18:19:46:069 [ warning nextcloud.sync.credentials.webflow ]: "Error 
transferring https://cloud.xxx.xx/index.php/login/v2/poll - server 
replied: Not Found"

Downgrading to nextcloud 3.1.1-2 "solved" this issue.

Christian

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

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

Versions of packages nextcloud-desktop depends on:
ii  libc6  2.31-17
ii  libcloudproviders0 0.3.1-2
ii  libgcc-s1  11.2.0-3
ii  libglib2.0-0   2.68.4-1
ii  libnextcloudsync0  3.3.1-2
ii  libqt5core5a   5.15.2+dfsg-10
ii  libqt5dbus55.15.2+dfsg-10
ii  libqt5gui5 5.15.2+dfsg-10
ii  libqt5keychain10.10.0-1
ii  libqt5network5 5.15.2+dfsg-10
ii  libqt5qml5 5.15.2+dfsg-8
ii  libqt5quick5   5.15.2+dfsg-8
ii  libqt5quickcontrols2-5 5.15.2+dfsg-4
ii  libqt5sql5-sqlite  5.15.2+dfsg-10
ii  libqt5svg5 5.15.2-3
ii  libqt5webenginecore5   5.15.5+dfsg-2
ii  libqt5webenginewidgets55.15.5+dfsg-2
ii  libqt5widgets5 5.15.2+dfsg-10
ii  libstdc++6 11.2.0-3
ii  nextcloud-desktop-common   3.3.1-2
ii  nextcloud-desktop-l10n 3.3.1-2
ii  qml-module-qtgraphicaleffects  5.15.2-2
ii  qml-module-qtqml-models2   5.15.2+dfsg-8
ii  qml-module-qtquick-controls2   5.15.2+dfsg-4
ii  qml-module-qtquick-layouts 5.15.2+dfsg-8
ii  qml-module-qtquick-window2 5.15.2+dfsg-8
ii  qml-module-qtquick25.15.2+dfsg-8

Versions of packages nextcloud-desktop recommends:
pn  nextcloud-desktop-doc  

nextcloud-desktop suggests no packages.

-- no debconf information

Bug#981349: kde/plasma does not start under wayland (solved)

2021-08-26 Thread Dennis Filder

X-Debbugs-CC: Antonio 

This happened to me, too.  I can't tell what the cause in your case
might have been, but in my case it was because I set DISPLAY to ":0"
via ~/.pam_environment which made kwin_wayland believe it is running
within an X server, so it chose the X11 backend without testing if it
could actually connect to the X server first.  Since with SDDM (which
I use, too) the sddm-greeter's X server runs as user sddm, the
logged-in user's .Xauthority file will not match (because it is not
updated when entering a Wayland session) and the connection will fail
with an authentication error.

A remedy would be to actually try to open an X display in
kwin/main_wayland.cpp:automaticBackendSelection() and choose a
different plugin if it fails.  The code could look as simple as this:

#include 
...
static QString automaticBackendSelection(SpawnMode spawnMode)
{
...
if (qEnvironmentVariableIsSet("DISPLAY")) {
if (qEnvironmentVariableIsSet("KWIN_WAYLAND_SKIP_X11CHECK"))
return s_x11Plugin;

Display *d = XOpenDisplay(NULL);
if (d) {
XCloseDisplay(d);
return s_x11Plugin;
}
}
...
}

Since kwin_wayland already links against libX11.so.6 there would be no
new dependencies.

N.B.: There is another very insidious problem here with how
startplasma-wayland chooses default values.  If startplasma-wayland is
called without arguments it unconditionally runs:

kwin_wayland --xwayland 
--exit-with-session=/path/to/startplasma-waylandsession

But if a user modifies the Exec= line in
/usr/share/wayland-sessions/plasmawayland.desktop to e.g.

 /usr/bin/startplasma-wayland --drm

then it runs only this:

kwin_wayland --drm

The user has no way of knowing (beyond studying the source code) that
he must also specify those other options, too, as otherwise the Plasma
session will not be set up correctly due to a missing X server.  The
lack of a manpage does not help exactly either.

Regards.

Bug#993036: plasma-workspace: Provide locked sessions

2021-08-26 Thread Dennis Filder

Package: plasma-workspace
Version: 5.21.5-3
Severity: wishlist
Tags: patch

The attached patch creates additional session definitions for X and
Wayland that launch Plasma in a locked state.  Using them with
auto-login makes for a great combination.  I had been looking for
something like this for years.

The patch applies against 5.21.5-3, but I have only tested it with
5.20.5-6.

Locked auto-login under X works nicely and it's what I'll be using.
Locked auto-login under Wayland works, too, but is a rather rocky
experience IMO.  I also recommend using throwaway user accounts for
testing (to not mess up your saved session) and running top/htop on a
separate VT during the familiarization phase and keeping an eye on CPU
usage.  Notable observations from my testing:

* kwin_wayland pegs the CPU to ~385% until you unlock the session
  (with DRM backend on nouveau).  I guess disabling some effects could
  reduce that, but I haven't looked into that.

* Consequently mouse movement is choppy, and you have to put the
  pointer directly over the password field for it to retain focus.

* The window dimensions of the kscreenlocker_greet window change once
  Plasma launches the Task Manager leaving a black bar at the position
  where the Task Manager would be.

* Also upon logout sometimes stray processes (korgac,
  kactivitymanager, kded5) stay around which consume ~200 % CPU till
  killed.  I can't reliably reproduce this yet, though, so it might be
  nothing.

Regards,
Dennis Filder
--- a/debian/rules
+++ b/debian/rules
@@ -11,6 +11,18 @@ include /usr/share/pkg-kde-tools/qt-kde-team/2/library-packages.mk
 override_dh_auto_configure:
 	dh_auto_configure -Skf5 -- -DBUILD_TESTING=OFF
 
+override_dh_auto_install:
+	dh_auto_install --buildsystem=kf5 -i -O--buildsystem=kf5
+	rm -f debian/tmp/usr/share/xsessions/plasmalocked.desktop debian/tmp/usr/share/wayland-sessions/plasmawaylandlocked.desktop
+	cp -a debian/tmp/usr/share/xsessions/plasma.desktop debian/tmp/usr/share/xsessions/plasmalocked.desktop
+	cp -a debian/tmp/usr/share/wayland-sessions/plasmawayland.desktop debian/tmp/usr/share/wayland-sessions/plasmawaylandlocked.desktop
+	sed -f debian/genlockedplasma.sed -i debian/tmp/usr/share/xsessions/plasmalocked.desktop
+	sed -f debian/genlockedplasma.sed -i debian/tmp/usr/share/wayland-sessions/plasmawaylandlocked.desktop
+# Test if the above actually took effect and error out if it didn't
+	grep -q -e DESKTOP_LOCKED=true debian/tmp/usr/share/xsessions/plasmalocked.desktop
+	grep -q -e --lockscreen debian/tmp/usr/share/wayland-sessions/plasmawaylandlocked.desktop
+	grep -q -e '^Name=.*(Wayland)$$' debian/tmp/usr/share/wayland-sessions/plasmawaylandlocked.desktop
+
 override_dh_auto_test:
 	# Disable auto tests at build time
 	:
--- a/debian/plasma-workspace.install
+++ b/debian/plasma-workspace.install
@@ -66,3 +66,4 @@ usr/share/kservicetypes5/
 usr/share/metainfo/
 usr/share/solid/actions/test-predicate-openinwindow.desktop
 usr/share/xsessions/plasma.desktop
+usr/share/xsessions/plasmalocked.desktop
--- a/debian/plasma-workspace-wayland.install
+++ b/debian/plasma-workspace-wayland.install
@@ -1,3 +1,4 @@
 usr/bin/startplasma-wayland
 usr/lib/*/libexec/startplasma-waylandsession
 usr/share/wayland-sessions/plasmawayland.desktop
+usr/share/wayland-sessions/plasmawaylandlocked.desktop
--- /dev/null
+++ b/debian/genlockedplasma.sed
@@ -0,0 +1,26 @@
+# -*- mode: conf; -*-
+
+# https://github.com/sddm/sddm/issues/306 has some discussion
+
+s@^Exec=\(/usr/.*/startplasma-x11.*\)$@Exec=/usr/bin/env DESKTOP_LOCKED=true \1@
+# The Plasma devs in their infinite wisdom made startplasma-wayland
+# ignore DESKTOP_LOCKED.  Also because their approach to command line
+# defaults is a bit unorthodox, we have to specify the command line
+# in full like so carefully preserving arch-specific paths.
+s@^Exec=/usr/\(.*/libexec\)/\(plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland.*\)$@Exec=/usr/\1/\2 --lockscreen --xwayland --exit-with-session /usr/\1/startplasma-waylandsession@
+
+# sddm in src/common/Session.cpp:Session::setTo() foolishly expects
+# the string "(Wayland)" at the very end of Name= (instead of e.g.
+# inspecting Type=), so we must preserve it until they fix the code.
+#
+# Consider using U+1F510 CLOSED LOCK WITH KEY (🔐) or U+1F512 LOCK
+# (🔒) once Qt supports it.
+#s@^Name=\(Plasma\)\(.*\)$@Name=\1 🔐\2@
+#s@^Name=\(Plasma\)\(.*\)$@Name=Locked \1\2@
+#s@^Name=\(Plasma\)\(.*\)$@Name=\1 „-o\2@
+#s@^Name=\(Plasma\)\(.*\)$@Name=\1 o––⃩\2@
+#s@^Name=\(Plasma\)\(.*\)$@Name=\1 o¬\2@
+#s@^Name=\(Plasma\)\(.*\)$@Name=\1 ◯—▄\2@
+s@^Name=\(Plasma\)\(.*\)$@Name=\1 [locked]\2@
+
+s@^Comment=\(.*\)$@Comment=\1 (locked)@

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

2021-08-26 Thread Chuck Zmudzinski


On 8/24/2021 7:12 PM, Ben Hutchings wrote:


The current limit on the environment of a uevent appears to be 2 KB
(UEVENT_BUFFER_SIZE defined in ).  That seems like it
*might* be easier to change, so long as user-space doesn't have a
similar limit.

I looked into systemd/udev, and it seems to use an 8 KB buffer for
receiving uevents:

https://sources.debian.org/src/systemd/247.9-1/src/libsystemd/sd-device/device-monitor.c/?hl=390#L390

But as a first step I think increasing the kernel buffer size to 4 KB
would be enough.  Perhaps someone could test whether this patch to the
domU kernel makes udev happier:

--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -30,7 +30,7 @@
  
  #define UEVENT_HELPER_PATH_LEN		256

  #define UEVENT_NUM_ENVP   64  /* number of env 
pointers */
-#define UEVENT_BUFFER_SIZE 2048/* buffer for the variables */
+#define UEVENT_BUFFER_SIZE 4096/* buffer for the variables */
  
  #ifdef CONFIG_UEVENT_HELPER

  /* path to the userspace helper executed on an event */
--- END ---

?

Ben.



I tested this patch on my Xen HVM bullseye system and
it appears 4k is enough for the UEVENT_BUFFER_SIZE
to accommodate the Xen Virtual Keyboard's large
modalias. I needed to follow the instructions in
the Kernel team's handbook for changing the ABI
name of the kernel for the build to succeed with
the patch. I just bumped it from 8 to 8.1.

Results:

1. No coldplug failure reported at boot time.

2. With the patch the system can write uevent
data to sysfs for the Xen Virtual Keyboard device.

With the current 5.10.0-8 kernel:

chuckz@debian:~$ cat /sys/devices/virtual/input/input2/uevent
chuckz@debian:~$

With the patched kernel with a change to the ABI version from 8 to 8.1:

chuckz@debian:~$ uname -r
5.10.0-8.1-amd64
chuckz@debian:~$ cat /sys/devices/virtual/input/input2/uevent
PRODUCT=1/5853//0
NAME="Xen Virtual Keyboard"
PHYS="xenbus/device/vkbd/0"
PROP=0
EV=3
KEY=7fff  ...
MODALIAS=input:b0001v5853pe-e0,1,k71,72... really long MODALIAS
---

So I think a test of the installation media in a Xen HVM with the
4k buffer in the kernel is the next step.

I would also like to test a live CD in a Xen HVM with this patch.
It was also reported to fail to boot in a Xen HVM on the
debian-user list.

BTW, my complements to the Debian Kernel Team for the
excellent handbook on building kernels for Debian. It is
easy to understand and made it very easy for me to
build and test the patch even though I have not built
a Linux kernel in many years, and I never built a Debian
kernel before.

All the best,

Chuck

Bug#993035: bullseye-pu: package sabnzbdplus/3.1.1+dfsg-2

2021-08-26 Thread Jeroen Ploemen

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: t...@security.debian.org

The sabnzbdplus package has a security vulnerability, allowing a
directory escape in the renamer() function through malicious par2 files.

An attacker can create new files anywhere the privileges of the
sabnzbdplus process permit, but not overwrite or delete existing files.

The attached debdiff fixes the problem by backporting the upstream fix.

Tested by downloading a proof-of-concept job designed to trigger the bug.
All checks on salsa-ci also complete successfully, including the upstream
testsuite used as autopkgtest.

Upstream advisory:
https://github.com/sabnzbd/sabnzbd/security/advisories/GHSA-jwj3-wrvf-v3rp
Upstream fix:
https://github.com/sabnzbd/sabnzbd/commit/3766ba54026eaa520dbee5b57a2f33d4954fb98b
Security tracker (low severity/no-dsa):
https://security-tracker.debian.org/tracker/CVE-2021-29488


sabnzbdplus_3.1.1+dfsg-2+deb11u1.debdiff
Description: Binary data


pgp5blDmXiTpe.pgp
Description: OpenPGP digital signature

Bug#993034: buster-pu: package sabnzbdplus/2.3.6+dfsg-1+deb10u1

2021-08-26 Thread Jeroen Ploemen

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: t...@security.debian.org

The sabnzbdplus package has a security vulnerability, allowing a
directory escape in the renamer() function through malicious par2 files.

An attacker can create new files anywhere the privileges of the
sabnzbdplus process permit, but not overwrite or delete existing files.

The attached debdiff fixes the problem by backporting the upstream fix.
Tested in buster by downloading a proof-of-concept job designed to
trigger the bug.

Upstream advisory:
https://github.com/sabnzbd/sabnzbd/security/advisories/GHSA-jwj3-wrvf-v3rp
Upstream fix:
https://github.com/sabnzbd/sabnzbd/commit/3766ba54026eaa520dbee5b57a2f33d4954fb98b
Security tracker (low severity/no-dsa):
https://security-tracker.debian.org/tracker/CVE-2021-29488


sabnzbdplus_2.3.6+dfsg-1+deb10u2.debdiff
Description: Binary data


pgp5FxBadDbCh.pgp
Description: OpenPGP digital signature

Bug#993011: pulseaudio-module-bluetooth: no longer detects bluetooth headphones

On 2021-08-26 09:07:55 -0400, Felipe Sateler wrote:
> Could you attach verbose logs of both a succesful and an unsuccesful run?
> 
> https://fedoraproject.org/wiki/How_to_debug_PulseAudio_problems

I've attached an archive with:
  * pa14.out: "pulseaudio -v" output with PulseAudio 14 (working).
  * pa15.out: "pulseaudio -v" output with PulseAudio 15 (failing).
  * pacmd-14: "pacmd ls" output with PulseAudio 14.
  * pacmd-15: "pacmd ls" output with PulseAudio 15.

I did the following (with output filenames for PulseAudio 14):
  1. systemctl --user stop pulseaudio.socket
  2. systemctl --user stop pulseaudio.service
  3. pulseaudio -v >& pa14.out
  4. Switch on my bluetooth headphones.
  5. pacmd ls > pacmd-14
  6. Ctrl-C on "pulseaudio -v".

Please tell me whether this is sufficient or you need more information.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

pa-dbg.tar.xz
Description: application/xz

Bug#993032: openldap FTBFS: autoreconf failure

2021-08-26 Thread Helmut Grohne

Source: openldap
Version: 2.4.57+dfsg-3
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap

openldap fails to build from source, because autoreconf fails. A build
ends as follows:

| dh_autoreconf debian/rules -- autoreconf
| make[3]: Entering directory '/<>'
| autoreconf -f -i . contrib/ldapc++
| autoreconf: warning: autoconf input should be named 'configure.ac', not 
'configure.in'
| aclocal: warning: autoconf input should be named 'configure.ac', not 
'configure.in'
| libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build'.
| libtoolize: copying file 'build/ltmain.sh'
| libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.in,
| libtoolize: and rerunning libtoolize and aclocal.
| libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
| aclocal: warning: autoconf input should be named 'configure.ac', not 
'configure.in'
| configure.in:72: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms 
are deprecated.
| ./lib/autoconf/general.m4:2434: AC_DIAGNOSE is expanded from...
| aclocal.m4:9483: AM_INIT_AUTOMAKE is expanded from...
| configure.in:72: the top level
| configure.in:671: warning: The macro `AC_LIBTOOL_WIN32_DLL' is obsolete.
| configure.in:671: You should run autoupdate.
| aclocal.m4:8540: AC_LIBTOOL_WIN32_DLL is expanded from...
| configure.in:671: the top level
| configure.in:671: warning: AC_LIBTOOL_WIN32_DLL: Remove this warning and the 
call to _LT_SET_OPTION when you
| configure.in:671: put the 'win32-dll' option into LT_INIT's first parameter.
| ./lib/autoconf/general.m4:2434: AC_DIAGNOSE is expanded from...
| aclocal.m4:8540: AC_LIBTOOL_WIN32_DLL is expanded from...
| configure.in:671: the top level
| configure.in:672: warning: The macro `AC_LIBTOOL_DLOPEN' is obsolete.
| configure.in:672: You should run autoupdate.
| aclocal.m4:8505: AC_LIBTOOL_DLOPEN is expanded from...
| configure.in:672: the top level
| configure.in:672: warning: AC_LIBTOOL_DLOPEN: Remove this warning and the 
call to _LT_SET_OPTION when you
| configure.in:672: put the 'dlopen' option into LT_INIT's first parameter.
| ./lib/autoconf/general.m4:2434: AC_DIAGNOSE is expanded from...
| aclocal.m4:8505: AC_LIBTOOL_DLOPEN is expanded from...
| configure.in:672: the top level
| configure.in:673: warning: The macro `AC_PROG_LIBTOOL' is obsolete.
| configure.in:673: You should run autoupdate.
| aclocal.m4:121: AC_PROG_LIBTOOL is expanded from...
| configure.in:673: the top level
| configure.in:1216: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected 
in body
| ./lib/autoconf/lang.m4:199: AC_LANG_CONFTEST is expanded from...
| ./lib/autoconf/general.m4:2736: _AC_PREPROC_IFELSE is expanded from...
| ./lib/autoconf/general.m4:2751: AC_PREPROC_IFELSE is expanded from...
| configure.in:1216: the top level
| configure.in:1369: warning: The macro `AC_TRY_LINK' is obsolete.
| configure.in:1369: You should run autoupdate.
| ./lib/autoconf/general.m4:2920: AC_TRY_LINK is expanded from...
| lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
| ./lib/autoconf/general.m4:2981: AC_RUN_IFELSE is expanded from...
| lib/m4sugar/m4sh.m4:692: _AS_IF_ELSE is expanded from...
| lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
| ./lib/autoconf/general.m4:2249: AC_CACHE_VAL is expanded from...
| ./lib/autoconf/general.m4:2270: AC_CACHE_CHECK is expanded from...
| configure.in:1369: the top level
| configure.in:1369: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected 
in body
| ./lib/autoconf/lang.m4:199: AC_LANG_CONFTEST is expanded from...
| ./lib/autoconf/general.m4:2962: _AC_RUN_IFELSE is expanded from...
| lib/m4sugar/m4sh.m4:692: _AS_IF_ELSE is expanded from...
| lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
| ./lib/autoconf/general.m4:2981: AC_RUN_IFELSE is expanded from...
| lib/m4sugar/m4sh.m4:692: _AS_IF_ELSE is expanded from...
| lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
| ./lib/autoconf/general.m4:2249: AC_CACHE_VAL is expanded from...
| ./lib/autoconf/general.m4:2270: AC_CACHE_CHECK is expanded from...
| configure.in:1369: the top level
| configure.in:1384: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected 
in body
| ./lib/autoconf/lang.m4:199: AC_LANG_CONFTEST is expanded from...
| ./lib/autoconf/general.m4:2962: _AC_RUN_IFELSE is expanded from...
| lib/m4sugar/m4sh.m4:692: _AS_IF_ELSE is expanded from...
| lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
| ./lib/autoconf/general.m4:2981: AC_RUN_IFELSE is expanded from...
| lib/m4sugar/m4sh.m4:692: _AS_IF_ELSE is expanded from...
| lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
| ./lib/autoconf/general.m4:2249: AC_CACHE_VAL is expanded from...
| ./lib/autoconf/general.m4:2270: AC_CACHE_CHECK is expanded from...
| build/openldap.m4:664: OL_PTHREAD_TRY is expanded from...
| configure.in:1384: the top level
| configure.in:1385: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected 
in body
| ./lib/autoconf/lang.m4:199: AC_LANG_CONFTEST is expanded from...
| ./lib/aut

Bug#993033: libmcrypt FTBFS: autoreconf failure

2021-08-26 Thread Helmut Grohne

Source: libmcrypt
Version: 2.5.8-3.4
Tags: ftbfs
Severity: serious

libmcrypt fails to build from source, because autoreconf fails. A build
ends as follows:


|dh_autoreconf
| autoreconf: warning: autoconf input should be named 'configure.ac', not 
'configure.in'
| aclocal: warning: autoconf input should be named 'configure.ac', not 
'configure.in'
| aclocal: warning: autoconf input should be named 'configure.ac', not 
'configure.in'
| acinclude.m4:3740: warning: the serial number must appear before any macro 
definition
| libtoolize: putting auxiliary files in '..'.
| libtoolize: copying file '../compile'
| libtoolize: copying file '../config.guess'
| libtoolize: copying file '../config.sub'
| libtoolize: copying file '../depcomp'
| libtoolize: copying file '../install-sh'
| libtoolize: copying file '../missing'
| libtoolize: copying file '../ltmain.sh'
| libtoolize: putting macros in 'libltdl/m4'.
| libtoolize: copying file 'libltdl/m4/libtool.m4'
| libtoolize: You should add the contents of 'libltdl/m4/libtool.m4' to 
'aclocal.m4'.
| libtoolize: copying file 'libltdl/m4/ltargz.m4'
| libtoolize: You should add the contents of 'libltdl/m4/ltargz.m4' to 
'aclocal.m4'.
| libtoolize: copying file 'libltdl/m4/ltdl.m4'
| libtoolize: You should add the contents of 'libltdl/m4/ltdl.m4' to 
'aclocal.m4'.
| libtoolize: copying file 'libltdl/m4/ltoptions.m4'
| libtoolize: You should add the contents of 'libltdl/m4/ltoptions.m4' to 
'aclocal.m4'.
| libtoolize: copying file 'libltdl/m4/ltsugar.m4'
| libtoolize: You should add the contents of 'libltdl/m4/ltsugar.m4' to 
'aclocal.m4'.
| libtoolize: copying file 'libltdl/m4/ltversion.m4'
| libtoolize: You should add the contents of 'libltdl/m4/ltversion.m4' to 
'aclocal.m4'.
| libtoolize: copying file 'libltdl/m4/lt~obsolete.m4'
| libtoolize: You should add the contents of 'libltdl/m4/lt~obsolete.m4' to 
'aclocal.m4'.
| libtoolize: putting libltdl files in 'libltdl'.
| libtoolize: copying file 'libltdl/COPYING.LIB'
| libtoolize: creating file 'libltdl/Makefile.am'
| libtoolize: copying file 'libltdl/README'
| libtoolize: creating file 'libltdl/configure.ac'
| libtoolize: creating file 'libltdl/aclocal.m4'
| libtoolize: creating file 'libltdl/Makefile.in'
| libtoolize: copying file 'libltdl/config-h.in'
| libtoolize: creating file 'libltdl/configure'
| libtoolize: copying file 'libltdl/libltdl/lt__alloc.h'
| libtoolize: copying file 'libltdl/libltdl/lt__argz_.h'
| libtoolize: copying file 'libltdl/libltdl/lt__dirent.h'
| libtoolize: copying file 'libltdl/libltdl/lt__glibc.h'
| libtoolize: copying file 'libltdl/libltdl/lt__private.h'
| libtoolize: copying file 'libltdl/libltdl/lt__strl.h'
| libtoolize: copying file 'libltdl/libltdl/lt_dlloader.h'
| libtoolize: copying file 'libltdl/libltdl/lt_error.h'
| libtoolize: copying file 'libltdl/libltdl/lt_system.h'
| libtoolize: copying file 'libltdl/libltdl/slist.h'
| libtoolize: copying file 'libltdl/loaders/dld_link.c'
| libtoolize: copying file 'libltdl/loaders/dlopen.c'
| libtoolize: copying file 'libltdl/loaders/dyld.c'
| libtoolize: copying file 'libltdl/loaders/load_add_on.c'
| libtoolize: copying file 'libltdl/loaders/loadlibrary.c'
| libtoolize: copying file 'libltdl/loaders/preopen.c'
| libtoolize: copying file 'libltdl/loaders/shl_load.c'
| libtoolize: copying file 'libltdl/lt__alloc.c'
| libtoolize: copying file 'libltdl/lt__argz.c'
| libtoolize: copying file 'libltdl/lt__dirent.c'
| libtoolize: copying file 'libltdl/lt__strl.c'
| libtoolize: copying file 'libltdl/lt_dlloader.c'
| libtoolize: copying file 'libltdl/lt_error.c'
| libtoolize: copying file 'libltdl/ltdl.c'
| libtoolize: copying file 'libltdl/ltdl.h'
| libtoolize: copying file 'libltdl/slist.c'
| libtoolize: You should add the contents of the following files to 
'aclocal.m4':
| libtoolize:   '/usr/share/aclocal/libtool.m4'
| libtoolize:   '/usr/share/aclocal/ltargz.m4'
| libtoolize:   '/usr/share/aclocal/ltdl.m4'
| libtoolize:   '/usr/share/aclocal/ltoptions.m4'
| libtoolize:   '/usr/share/aclocal/ltsugar.m4'
| libtoolize:   '/usr/share/aclocal/ltversion.m4'
| libtoolize:   '/usr/share/aclocal/lt~obsolete.m4'
| libtoolize: Remember to add 'LT_CONFIG_LTDL_DIR([libltdl])' to 'configure.in'.
| libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([libltdl/m4])' to 
configure.in,
| libtoolize: and rerunning libtoolize and aclocal.
| libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
| aclocal: warning: autoconf input should be named 'configure.ac', not 
'configure.in'
| acinclude.m4:3740: warning: the serial number must appear before any macro 
definition
| configure.in:24: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms 
are deprecated.
| ./lib/autoconf/general.m4:2434: AC_DIAGNOSE is expanded from...
| aclocal.m4:429: AM_INIT_AUTOMAKE is expanded from...
| configure.in:24: the top level
| configure.in:25: warning: 'AM_CONFIG_HEADER': this macro is obsolete.
| configure.in:25: You should use the 'AC_CONFIG_HEADERS' macro instead

Bug#993031: ripser FTCBFS: hard codes the build architecture compiler

2021-08-26 Thread Helmut Grohne

Source: ripser
Version: 1.2.1-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ripser fails to cross build from source, because debian/rules hard codes
the build architecture compiler. The easiest way of fixing that - using
dpkg's buildtools.mk to initialize CXX - makes ripser cross buildable.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru ripser-1.2.1/debian/changelog ripser-1.2.1/debian/changelog
--- ripser-1.2.1/debian/changelog   2021-08-14 18:10:29.0 +0200
+++ ripser-1.2.1/debian/changelog   2021-08-26 13:48:50.0 +0200
@@ -1,3 +1,10 @@
+ripser (1.2.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dpkg's buildtools.mk supply a C++ compiler. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 26 Aug 2021 13:48:50 +0200
+
 ripser (1.2.1-1) unstable; urgency=medium
 
   * New upstream version.
diff --minimal -Nru ripser-1.2.1/debian/rules ripser-1.2.1/debian/rules
--- ripser-1.2.1/debian/rules   2021-08-14 18:01:42.0 +0200
+++ ripser-1.2.1/debian/rules   2021-08-26 13:48:49.0 +0200
@@ -5,6 +5,8 @@
 CXXFLAGS:=$(shell dpkg-buildflags --get CXXFLAGS)
 LDFLAGS:=$(shell dpkg-buildflags --get LDFLAGS)
 
+-include /usr/share/dpkg/buildtools.mk
+
 %:
dh $@
 
@@ -12,8 +14,8 @@
mkdir -p build
 
 override_dh_auto_build:
-   c++ $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) -o build/ripser ripser.cpp
-   c++ $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) -DUSE_COEFFICIENTS -o 
build/ripser-coeff ripser.cpp
+   $(CXX) $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) -o build/ripser ripser.cpp
+   $(CXX) $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) -DUSE_COEFFICIENTS -o 
build/ripser-coeff ripser.cpp
 
 override_dh_auto_clean:
rm -rf build

Bug#992990: systemd: Does not clean up user session

2021-08-26 Thread Samuel Thibault

Control: tags -1 wontfix

So AIUI, to get a proper cleanup when the X server happens to go away
(lightdm restart, or main session process exit), the processes have to
notice that the X server went away?

Samuel

Bug#992990: systemd: Does not clean up user session

2021-08-26 Thread Michael Biebl


Am 26.08.21 um 15:58 schrieb Ansgar:

On Thu, 2021-08-26 at 09:13 +0200, Michael Biebl wrote:

In your case, dbus-daemon is *not* started as a user service, but as
a
regular process within a login session, so there can be multiple
ones.


This looks incorrect: dbus was started with `--address=systemd` and
`--systemd-activation`. So it looks like it was started via systemd as
a user service.


Right, sorry. I was confused by the instance that was started via AT-SPI.


systemd does have a facility `KillUserProcesses=yes` which kills all
processes of such a login session, when the user logs out.
The upstream default is "yes" but in Debian we had complaints that
this
killed processes like screen, so we patch it to "no" as default in
Debian.


And with `KillUserProcesses=no` any process still left in the user's
login session will keep the login alive (in "closing" state) and the
user's `systemd --user` instance and thus dbus will be kept running.


Nod, the end result is the same and the underlying issue is that we 
default to `KillUserProcesses=no`





OpenPGP_signature
Description: OpenPGP digital signature

Bug#993030: plasma-desktop: keyboard layout swaps third level characters

2021-08-26 Thread Marius Mikucionis

Package: plasma-desktop
Version: 4:5.21.5-2
Severity: normal

Dear Maintainer,

Something strange happened to the keyboard layout treatment and I am not sure 
where exactly. It manifests in KDE plasma, which I upgraded recently and thus I 
assume that the issue is with plasma. I do not know the exact package which 
handles the keybord layout, so feel free to reassign to other package.

The issue is with "Lithuanian" kayboard layout with "Lithuanian (US)" variant.
Normally the layout is the same as US keyboard, except the 3rd level 
(accessible by holding Right-AltGr) contains Lithuanian letters on the number 
keys (the row above the letters, not the numberpad).
The issue is that the 3rd level (Lithuanian letters) now work at the 1st level 
(ie. without Right-AltGr) and the numbers are accessible as 3rd level (while 
holding the Right-AltGr).
The keyboard settings still show the correct layout (1st numbers, 3rd LT 
letters).

I have tried removing and re-adding this layout, and the issue persists.

I have tried Danish layout and the issue is not there (i.e. 1st level are 
numbers and 3rd are currency and other characters), so maybe the issue is 
specific to this particular variant.

   * What led up to the situation?

   apt update && apt upgrade && plasmashell --restart

   * What exactly did you do (or not do) that was effective (or ineffective)?

   now I am forced to switch between US and LT layout which is not convenient.

   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages plasma-desktop depends on:
ii  accountsservice  0.6.55-3
ii  breeze   4:5.21.5-2
ii  kactivitymanagerd5.21.5-2
ii  kde-cli-tools4:5.21.5-2
ii  kded55.83.0-2
ii  kio  5.83.0-2
ii  kpackagetool55.83.0-2
ii  libaccounts-qt5-11.16-2
ii  libc62.31-13
ii  libcrypt11:4.4.18-4
ii  libglib2.0-0 2.68.4-1
ii  libibus-1.0-51.5.24-1
ii  libkaccounts24:21.08.0-1
ii  libkf5activities55.83.0-2
ii  libkf5activitiesstats1   5.83.0-2
ii  libkf5authcore5  5.83.0-2
ii  libkf5baloo5 5.83.0-2
ii  libkf5codecs55.83.0-2
ii  libkf5completion55.83.0-2
ii  libkf5configcore55.83.0-2
ii  libkf5configgui5 5.83.0-2
ii  libkf5configwidgets5 5.83.0-3
ii  libkf5coreaddons55.83.0-2
ii  libkf5crash5 5.83.0-2
ii  libkf5dbusaddons55.83.0-2
ii  libkf5declarative5   5.83.0-2
ii  libkf5globalaccel-bin5.83.0-2
ii  libkf5globalaccel5   5.83.0-2
ii  libkf5guiaddons5 5.83.0-2
ii  libkf5i18n5  5.83.0-3
ii  libkf5iconthemes55.83.0-2
ii  libkf5itemviews5 5.83.0-2
ii  libkf5jobwidgets55.83.0-2
ii  libkf5kcmutils5  5.83.0-2
ii  libkf5kdelibs4support5   5.83.0-2
ii  libkf5kiocore5   5.83.0-2
ii  libkf5kiofilewidgets55.83.0-2
ii  libkf5kiogui55.83.0-2
ii  libkf5kiowidgets55.83.0-2
ii  libkf5newstuff5  5.83.0-2
ii  libkf5notifications5 5.83.0-3
ii  libkf5notifyconfig5  5.83.0-2
ii  libkf5package5   5.83.0-2
ii  libkf5plasma55.83.0-2
ii  libkf5plasmaquick5   5.83.0-2
ii  libkf5quickaddons5   5.83.0-2
ii  libkf5runner55.83.0-3
ii  libkf5service-bin5.83.0-2
ii  libkf5service5   5.83.0-2
ii  libkf5solid5 5.83.0-2
ii  libkf5sonnetcore55.83.0-2
ii  libkf5sonnetui5  5.83.0-2
ii  libkf5w

Bug#992976: uscan: mode=git refs/heads/ instruction scans for tags instead, and fails

2021-08-26 Thread Yadd

Hi,

could you try using "heads/Beta" instead of "refs/heads/Beta" ?

Bug#992694: reprotest: kernel variation makes ldconfig abort with message "FATAL: Kernel too old"

2021-08-26 Thread Mattia Rizzolo

On Sun, Aug 22, 2021 at 03:03:14PM +0200, Baptiste Beauplat wrote:
> While trying to debug
> https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/191, I found
> out that the kernel variation makes ldconfig abort with the following
> message: "FATAL: Kernel too old"

> This behavour is partially documented in the manpage under:
> 
> ```
> Kernel
> --
> 
> The "kernel" variation is currently not working for RPM based packages.
> While building with this variation enabled, the tool 
> `/usr/lib/rpm/redhat/brp-ldconfig`
> compains about `FATAL: kernel too old` and aborts the build.
> ```
> 
> However all version of ldconfig (at least since 2017) require a kernel
> 3.2, not just the RPM ldconfig.
> 
> I think the documentation should be updated to warn users about ldconfig
> not working in all cases.

What would you say about this patch:

|--- a/README.rst
|+++ b/README.rst
|@@ -378,9 +378,9 @@ mechanism to vary the system time.
| Kernel
| --
|
|-The "kernel" variation is currently not working for RPM based packages. While
|-building with this variation enabled, the tool 
`/usr/lib/rpm/redhat/brp-ldconfig`
|-compains about `FATAL: kernel too old` and aborts the build.
|+The "kernel" variation is currently not working for RPM based packages and 
other
|+build process requiring `ldconfig`.  While building with this variation 
enabled,
|+`ldconfig` complains about `FATAL: kernel too old` and aborts the build.
|
| Avoid sudo(1) password prompts
| ==

Besides potentially better identifying which versions of ldconfig are
effectively broken, I don't think we could do much else.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

signature.asc
Description: PGP signature

Bug#992848: pam_unix: Treats SHA256 and older hashes as expired

2021-08-26 Thread Paul Menzel


Dear Mattias,


Thank you for the analysis. I hit this too, and GDM autologin did not 
work anymore [1], so users thought Debian crashed during startup. 
Switching to tty2 and logging in and changing the password there, fixed 
the issue.


I asked for a Linux PAM point release, so distributions can easily pick 
it up [2].



Kind regards,

Paul


[1]: https://gitlab.gnome.org/GNOME/gdm/-/issues/724
[2]: https://github.com/linux-pam/linux-pam/issues/367

Bug#993026: nvidia-cuda-dev not installable on ppc64el

2021-08-26 Thread Samuel Thibault

Samuel Thibault, le jeu. 26 août 2021 15:51:53 +0200, a ecrit:
> There is no libnvidia-tesla-470-cuda1 in debian, nor >= 465

Ah, I see nvidia-graphics-drivers-tesla-470 is in NEW.

hwloc-contrib will have to wait then.

Samuel

Bug#992999: ITP: unyt -- Python package for handling numpy arrays with units.

2021-08-26 Thread Ole Streicher


On 26.08.21 15:29, Alastair McKinstry wrote:
It would be good to clarify. There is another package I maintain in 
Debian, udunits, thats a C library but also provides a "canonical" units 
database. It would be good not to  duplicate (reuse libudunits-data in 
unyt etc ?)


I know that the situation if far from perfect; however both unyts and 
astropy.units are currently hand-written (and hand-optimized) and do not 
have a structured "database" behind. This will probably make it 
difficult to unify them. And both packages are so deeply integrated in 
their "universe" (astropy resp. yp-project) that even a unification 
within the (rather small) astronomy community did not happen yet.


Cheers

Ole

Bug#992990: systemd: Does not clean up user session

2021-08-26 Thread Ansgar

On Thu, 2021-08-26 at 09:13 +0200, Michael Biebl wrote:
> In your case, dbus-daemon is *not* started as a user service, but as
> a 
> regular process within a login session, so there can be multiple
> ones.

This looks incorrect: dbus was started with `--address=systemd` and
`--systemd-activation`. So it looks like it was started via systemd as
a user service.

> systemd does have a facility `KillUserProcesses=yes` which kills all 
> processes of such a login session, when the user logs out.
> The upstream default is "yes" but in Debian we had complaints that
> this 
> killed processes like screen, so we patch it to "no" as default in
> Debian.

And with `KillUserProcesses=no` any process still left in the user's
login session will keep the login alive (in "closing" state) and the
user's `systemd --user` instance and thus dbus will be kept running.

Ansgar

Bug#993027: transition: knot 3.0 to 3.1

2021-08-26 Thread Jakub Ružička

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

Hello,

in order to update knot to latest 3.1.1, its only reverse dependency
knot-resolver needs to be updated to >= 5.4 which supports new
knot 3.1 API/ABI.

I've tested this in experimental - knot-resolver-5.4.1-1 built against
knot-3.1.1-3. Both packages have autopkgtests as well upstream tests
enabled.

Ben file:

title = "knot";
is_affected = .depends ~ /\b(libknot12|libzscanner4|libknot11|libzscanner3)\b/;
is_good = .depends ~ /\b(libknot12|libzscanner4)\b/;
is_bad = .depends ~ /\b(libknot11|libzscanner3)\b/;

Thank you.


Cheers,
Jakub

Bug#993026: nvidia-cuda-dev not installable on ppc64el

2021-08-26 Thread Samuel Thibault

Package: nvidia-cuda-dev
Version: 11.2.2-3
Severity: important

Hello,

I was trying to build hwloc-contrib on ppc64el, but couldn't install
nvidia-cuda-dev, even in a fresh sid chroot:

# apt-get install nvidia-cuda-dev
[...]
The following packages have unmet dependencies:
 nvidia-cuda-dev : Depends: libcuinj64-11.3 (= 11.3.111~11.3.1-3) but it is not 
going to be installed
   Depends: libnvidia-ml-dev (= 11.3.58~11.3.1-3) but it is not 
going to be installed
   Depends: libnvidia-tesla-470-cuda1 (>= 465) but it is not 
installable or
libcuda.so.1 (>= 465) or
libcuda-11.3-1 but it is not installable

There is no libnvidia-tesla-470-cuda1 in debian, nor >= 465

Samuel

-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldstable-proposed-updates-debug'), (500, 
'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), 
(500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages nvidia-cuda-dev depends on:
ii  libaccinj64-11.2 11.2.152~11.2.2-3
ii  libcublas11  11.4.1.1043~11.2.2-3
ii  libcublaslt1111.4.1.1043~11.2.2-3
ii  libcuda1 [libcuda.so.1]  470.57.02-2
ii  libcudart11.011.2.152~11.2.2-3
ii  libcufft10   11.1.1+~10.4.1.152~11.2.2-3
ii  libcufftw10  11.1.1+~10.4.1.152~11.2.2-3
ii  libcuinj64-11.2  11.2.152~11.2.2-3
ii  libcupti-dev 11.2.152~11.2.2-3
ii  libcurand10  11.1.1+~10.2.3.152~11.2.2-3
ii  libcusolver1111.1.1+~11.1.0.152~11.2.2-3
ii  libcusolvermg11  11.1.1+~11.1.0.152~11.2.2-3
ii  libcusparse1111.4.1.1152~11.2.2-3
ii  libnppc1111.3.2.152~11.2.2-3
ii  libnppial11  11.3.2.152~11.2.2-3
ii  libnppicc11  11.3.2.152~11.2.2-3
ii  libnppidei11 11.3.2.152~11.2.2-3
ii  libnppif11   11.3.2.152~11.2.2-3
ii  libnppig11   11.3.2.152~11.2.2-3
ii  libnppim11   11.3.2.152~11.2.2-3
ii  libnppist11  11.3.2.152~11.2.2-3
ii  libnppisu11  11.3.2.152~11.2.2-3
ii  libnppitc11  11.3.2.152~11.2.2-3
ii  libnpps1111.3.2.152~11.2.2-3
ii  libnvblas11  11.4.1.1043~11.2.2-3
ii  libnvidia-ml-dev 11.2.152~11.2.2-3
ii  libnvjpeg11  11.4.0.152~11.2.2-3
ii  libnvrtc11.2 11.2.152~11.2.2-3
ii  libnvtoolsext1   11.2.152~11.2.2-3
ii  libnvvm4 11.2.152~11.2.2-3
ii  libthrust-dev1.11.0-1

Versions of packages nvidia-cuda-dev recommends:
ii  libgl-dev1.3.2-1
ii  libgl1-mesa-dev  20.3.5-1
ii  libnvcuvid1  470.57.02-2
ii  libvdpau-dev 1.4-3

nvidia-cuda-dev suggests no packages.

-- no debconf information

-- 
Samuel
We are Pentium of Borg. Division is futile. You will be approximated.
(seen in someone's .signature)

Bug#993025: dcm2xml.dtd>dumppat.txt are not installed

2021-08-26 Thread Mathieu Malaterre

Source: dcmtk
Version: 3.6.5-1

Something has gone wrong since jessie. The files:

* dcm2xml.dtd
* dumppat.txt

are not installed anymore. Looking at the 3.6.6 exp package, it seems
those files are installed in the wrong location. And looking at the
git/master branch, those files are now properly installed by cmake in
the right location (/dcmtk subfolders).

Someone will need to spend some time on this...

Bug#992555: probably same on Dell Inspiron 3580

2021-08-26 Thread Piotr A. Dybczyński

Hi,

both: after upgrade from Buster and after clean install laptop does not wake up
when opening lid. Simply freezes, only power off helps.

When I boot Bullseye with 4.19 kernel it works.

Regards,
Piotr A. Dybczyński
-- 
/**
  dr Piotr A. Dybczyński 
 homepage: https://www.dybczynski.pl/Piotr e-mail: pi...@dybczynski.pl
PAD***/

Bug#924912: pristine-tar: Failed to reproduce original tarball python-django_1.11.20.orig.tar.gz

2021-08-26 Thread Ludovic Rousseau

On Fri, 6 Aug 2021 19:26:56 +0900 Roger Shimizu  wrote:
> should be caused by:
> - https://bugs.debian.org/897653
> 
> if you upgrade tar to buster version 1.30+dfsg-6 or later, it should
> be resolved.

I am on buster with:
ii  pristine-tar   1.49 amd64regenerate pristine tarballs
ii  tar1.34+dfsg-1  amd64GNU version of the tar archiving 
utility
and I still have the problem.

I try to upgrade the package 0ad to a new upstream version but that fails:
$ gbp import-orig --uscan
gbp:info: Launching uscan...
gbp:info: Using uscan downloaded tarball ../0ad_0.0.25.orig.tar.xz
What is the upstream version? [0.0.25]
gbp:info: Importing '../0ad_0.0.25.orig.tar.xz' to branch 'upstream'...
gbp:info: Source package is 0ad
gbp:info: Upstream version is 0.0.25
gbp:error: Import of ../0ad_0.0.25.orig.tar.xz failed: Couldn't commit to 
'pristine-tar' with upstream 'c98ef96af6f9638844dce03af30a3060b677fee2': 
pristine-xz failed to reproduce build of ../0ad_0.0.25.orig.tar.xz
(Please file a bug report.)
pristine-tar: failed to generate delta
gbp:error: Error detected, Will roll back changes.
gbp:info: Rolling back branch upstream by resetting it to 
86bb850b0a939ace014cbd3b7126410c258fc25c
gbp:info: Rolling back branch pristine-tar by resetting it to 
f0bd6693182069f87ebd7f5ab8e28911ffc157db
gbp:error: Rolled back changes after import error.

I tried with a fresh "git clone" of 0ad but the problem is still
present.

I don't want to regerenrate old tarballs, but to add a new one.

I extracted the upstream 0ad_0.0.25.orig.tar.xz and regenerated a new
.tar.xz file and this time the inclusion worked:
$ gbp import-orig ../0ad_0.0.25.orig.tar.xz
What is the upstream version? [0.0.25]
gbp:info: Importing '../0ad_0.0.25.orig.tar.xz' to branch 'upstream'...
gbp:info: Source package is 0ad
gbp:info: Upstream version is 0.0.25
gbp:info: Replacing upstream source on 'master'
gbp:info: Successfully imported version 0.0.25 of ../0ad_0.0.25.orig.tar.xz

But, of course, the archived version is not more a "pristine-tar" since
that is one that I re-created myself.

I have no idea what version of tar was used by upstream.
Upsteam file is available at 
https://releases.wildfiregames.com/0ad-0.0.25-alpha-unix-data.tar.xz

Bye

Bug#992999: ITP: unyt -- Python package for handling numpy arrays with units.

2021-08-26 Thread Alastair McKinstry

It would be good to clarify. There is another package I maintain in 
Debian, udunits, thats a C library but also provides a "canonical" units 
database. It would be good not to  duplicate (reuse libudunits-data in 
unyt etc ?)



On 26/08/2021 10:51, Ole Streicher wrote:

On 26.08.21 11:36, Alastair McKinstry wrote:

How does this interact with xarray, etc?


I don't know; the reason to package it is that it is a new requirement 
of the "yt" package. It was first developed within yt, and then 
separated. There is another attempt to use units in the "astropy" 
package; as far as I know they are not compatible.


A quick search however brings up

https://github.com/pydata/xarray/issues/525

with some long-lasting, unresolved discussion of the situation.


--
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.

Bug#993023: tortoisehg: uninstallable, needs an update for mercurial 5.9

2021-08-26 Thread Julien Cristau

Package: tortoisehg
Version: 5.6.1-1
Severity: serious
Tags: bookworm sid

Hi,

mercurial 5.9 is now in sid, making tortoisehg uninstallable.  There'll
hopefully be a tortoisehg 5.9 release in the near future...

Cheers,
Julien

Bug#993022: libretls FTBFS: configure: error: unable to find OpenSSL