Bug#831424: RFP: parsoid -- Web service converting HTML+RDFa to MediaWiki wikitext and back

[Kunal Mehta]

retitle 831424 ITP: parsoid -- bidirectional parser between wikitext and
HTML5
owner 831424 !
thanks

Parsoid has been ported to PHP and is now being bundled inside MediaWiki
as a library rather than a separate web service. I plan to close this
ITP with my next MediaWiki upload (upstream version 1.35) as it fulfills
the spirit of this request. If someone would like a separate Parsoid
package, let me know and I can see what's possible.

-- Kunal

Bug#935899: Acknowledgement (Quotas stopped working after upgrade to buster (systemd problem?))

[karl156]

This bug is almost a year old and still unfixed. Worse than that I did
not get a single comment on the issue. Is this package dead?

When fixing it you should also fix this:
Aug  1 12:34:56 hostname systemd[1]:
/lib/systemd/system/dovecot.service:9: PIDFile= references path below
legacy directory /var/run/, updating /var/run/dovecot/master.pid →
/run/dovecot/master.pid; please update the unit file accordingly.

Bug#966646: dwww-build-menu fails to recognize continuation lines in format sections of doc-base control files

[Peter Deister]

Package: dwww
Version: 1.13.4+nmu3
Severity: normal
Tags: patch

Dear Maintainer,

Dear Maintainer,

Trying to access a locally installed manual, I noticed it was missing from the
dwww menu. Instead, dwww listed a spurious error related to that manual,
complaining about a file with the empty string for its path. install-docs,
invoked with the -c or -i option, did not report any errors or warnings for the
respective control file.

Examination of the Perl script /usr/sbin/dwww-build-menu lead to subroutine
ParseDocBaseFile of module Debian::Dwww::DocBase (defined in file
/usr/share/perl5/Debian/Dwww/DocBase.pm). This routine is apparently expected
to parse a document control file (installed in /var/lib/doc-base/documents) and
represent its contents as a Perl object it returns.

I found this routine would not append continuation lines for headers appearing
in a format section. (Instead, the continuation lines would from a fictitious
header of that name in the main section; for example, continuation lines for
the Files header of the format sections would be concatenated to form the
content of some Files header in the main section.)

Since quite obvious, this defect was readily corrected in the installed file,
with the changes recorded in the diff file included below. Upon re-running
dwww-build-menu the missing manual documents appeared properly in the dwww
menu, as expected. I also noticed that documentation of some other package,
libxml-parser-perl in particular, also appeared after rebuilding the menu with
the patched module.

*** DocBase.pm.diff
21c21,22
< my ($fld, $val, $lastfld) = ('', '', '');
---
> my ($fld, $val) = ('', '');
> my $last = undef;
37c38
< $lastfld = '';
---
>   $last = undef;
43c44
< $entry->{$fld} = $val;
---
>   ${$last = \$entry->{$fld}} = $val;
45a47
>   $last = undef;
47c49,50
< $entry->{'formats'}->{$format}->{'index'} = $val;
---
>   $last = \$entry->{formats}->{$format}->{index};
>   $$last = $val;
49c52,53
< $entry->{'formats'}->{$format}->{'files'} = $val;
---
>   $last = \$entry->{formats}->{$format}->{files};
>   $$last = $val
53,55c57,58
< $lastfld = $fld;
< } elsif (/^\s+/ and $lastfld ne '') {
< $entry->{$lastfld} .= "\n$_";
---
> } elsif (/^\s+/ and defined($last)) {
> $$last .= "\n$_";



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

Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dwww depends on:
ii  apache2 [httpd-cgi]2.4.38-3+deb10u3
ii  debconf [debconf-2.0]  1.5.71
ii  debianutils4.8.6.1
ii  doc-base   0.10.8
ii  file   1:5.35-4+deb10u1
ii  libc6  2.28-10
ii  libfile-ncopy-perl 0.36-2
ii  libmime-types-perl 2.17-1
ii  man-db 2.8.5-2
ii  mime-support   3.62
ii  perl   5.28.1-6
ii  ucf3.0038+nmu1

Versions of packages dwww recommends:
ii  apache2 [httpd]  2.4.38-3+deb10u3
ii  apt  1.8.2.1
ii  dlocate  1.07+nmu1
ii  info2www 1.2.2.9-24
ii  swish++  6.1.5-5

Versions of packages dwww suggests:
ii  doc-debian  6.4
pn  dpkg-www
ii  firefox-esr [www-browser]   68.10.0esr-1~deb10u1
ii  google-chrome-stable [www-browser]  84.0.4147.89-1

-- debconf information:
  dwww/serverport: 80
  dwww/badport:
  dwww/nosuchdir:
  dwww/cgidir: /usr/lib/cgi-bin
  dwww/nosuchuser:
  dwww/docrootdir: /var/www
  dwww/index_docs: false
  dwww/servername: PD-T420.intra
  dwww/cgiuser: www-data
21c21,22
< my ($fld, $val, $lastfld) = ('', '', ''); 
---
> my ($fld, $val) = ('', ''); 
> my $last = undef;
37c38
< $lastfld = '';
---
>   $last = undef;
43c44
< $entry->{$fld} = $val;
---
>   ${$last = \$entry->{$fld}} = $val;
45a47
>   $last = undef;
47c49,50
< $entry->{'formats'}->{$format}->{'index'} = $val;
---
>   $last = \$entry->{formats}->{$format}->{index};
>   $$last = $val;
49c52,53
< $entry->{'formats'}->{$format}->{'files'} = $val;
---
>   $last = \$entry->{formats}->{$format}->{files};
>   $$last = $val
53,55c57,58
< $lastfld = $fld;
< } elsif (/^\s+/ and $lastfld ne '') {
< $entry->{$lastfld} .= "\n$_";
---
> } elsif (/^\s+/ and defined($last)) {
> $$last .= 

Bug#966098: systemd: 'systemctl status' reports "access denied" after upgrade

[Dima Kogan]

Michael Biebl  writes:

> Control: tags -1 + moreinfo unreproducible
>
> Am 23.07.20 um 03:13 schrieb Dima Kogan:
>> Package: systemd
>> Version: 245.6-3
>> Severity: grave
>> X-Debbugs-Cc: none, Dima Kogan 
>> 
>> Hi. I'm running Debian/sid. Updating all the packages on my system put
>> apt into a broken state:
>> 
>
> 239-15 is from 2 years ago.
> Why was systemd kept at version 239-15?

This is a laptop that I don't use very much. I guess I haven't done a
full-system update on it for a while. This was an "apt upgrade" not a
"dist-upgrade". This is sid.


> Is this inside a container?

No


> Is something like SELinux active?

I don't think so? I never purposely enabled it.


Alright. So I'm now at a state where apt is happy, the system is
up-to-date, except the systemd packages, which are old. I can get into a
similar broken state as before, but not identical by trying to upgrade,
installing these:

  libnss-systemd_245.6-3_amd64.deb
  libudev1_245.6-3_amd64.deb
  systemd-timesyncd_245.6-3_amd64.deb
  libsystemd0_245.6-3_amd64.deb
  udev_245.6-3_amd64.deb
  libpam-systemd_245.6-3_amd64.deb
  systemd-sysv_245.6-3_amd64.deb
  systemd_245.6-3_amd64.deb

It says this:

  dima@snarky:~/systemd-debugging$ sudo dpkg -i *245*

  (Reading database ... 208119 files and directories currently installed.)
  Preparing to unpack libnss-systemd_245.6-3_amd64.deb ...
  Unpacking libnss-systemd:amd64 (245.6-3) over (245.6-3) ...
  Preparing to unpack libpam-systemd_245.6-3_amd64.deb ...
  Unpacking libpam-systemd:amd64 (245.6-3) over (245.6-3) ...
  Preparing to unpack libsystemd0_245.6-3_amd64.deb ...
  Unpacking libsystemd0:amd64 (245.6-3) over (245.6-3) ...
  Preparing to unpack libudev1_245.6-3_amd64.deb ...
  Unpacking libudev1:amd64 (245.6-3) over (245.6-3) ...
  Preparing to unpack systemd-sysv_245.6-3_amd64.deb ...
  Unpacking systemd-sysv (245.6-3) over (245.6-3) ...
  Preparing to unpack systemd-timesyncd_245.6-3_amd64.deb ...
  Unpacking systemd-timesyncd (245.6-3) over (245.6-3) ...
  Failed to reload daemon: Access denied
  Preparing to unpack systemd_245.6-3_amd64.deb ...
  Unpacking systemd (245.6-3) over (245.6-3) ...
  Preparing to unpack udev_245.6-3_amd64.deb ...
  Unpacking udev (245.6-3) over (245.6-3) ...
  Setting up libsystemd0:amd64 (245.6-3) ...
  Setting up libudev1:amd64 (245.6-3) ...
  Setting up udev (245.6-3) ...
  Failed to reload daemon: Access denied
  Failed to reload daemon: Access denied
  Failed to retrieve unit state: Access denied
  Failed to restart udev.service: Access denied
  See system logs and 'systemctl status udev.service' for details.
  invoke-rc.d: initscript udev, action "restart" failed.
  Failed to get properties: Access denied
  dpkg: error processing package udev (--install):
   installed udev package post-installation script subprocess returned error 
exit status 4
  Setting up systemd-timesyncd (245.6-3) ...
  Failed to preset unit: Access denied
  /usr/bin/deb-systemd-helper: error: systemctl preset failed on 
systemd-timesyncd.service: No such file or directory
  Failed to reload daemon: Access denied
  Failed to get unit file state for systemd-timesyncd.service: Access denied
  Failed to retrieve unit state: Access denied
  systemd-timesyncd.service is a disabled or a static unit not running, not 
starting it.
  Setting up systemd (245.6-3) ...
  Failed to reload daemon: Access denied
  Failed to try-restart systemd-networkd.service: Access denied
  See system logs and 'systemctl status systemd-networkd.service' for details.
  Failed to try-restart systemd-resolved.service: Access denied
  See system logs and 'systemctl status systemd-resolved.service' for details.
  Failed to try-restart systemd-journald.service: Access denied
  See system logs and 'systemctl status systemd-journald.service' for details.
  Setting up libnss-systemd:amd64 (245.6-3) ...
  Setting up systemd-sysv (245.6-3) ...
  Setting up libpam-systemd:amd64 (245.6-3) ...
  Processing triggers for libc-bin (2.31-1) ...
  Processing triggers for man-db (2.9.3-2) ...
  Processing triggers for dbus (1.12.20-1) ...
  Processing triggers for initramfs-tools (0.137) ...
  update-initramfs: Generating /boot/initrd.img-5.7.0-1-amd64
  Errors were encountered while processing:
   udev

At this point udev is broken, and I can't fix it without downgrading:

  dima@snarky:~/systemd-debugging$ dpkg -l | grep 245

  ii  libnss-systemd:amd64 245.6-3  
amd64nss module providing dynamic user and group name resolution
  ii  libpam-systemd:amd64 245.6-3  
amd64system and service manager - PAM module
  ii  libsystemd0:amd64245.6-3  
amd64systemd utility library
  ii  libudev1:amd64   245.6-3  
amd64libudev shared library
  ii  systemd  245.6-3 

Bug#966645: Service file specifying 'Run in terminal' gives "Error code 100, Could not find the program ‘konsole’"

[Leandro Cunha]

Source: kio
Version: 5.70.1-1
Severity: normal
Tags: fixed-upstream, upstream
Forwarded: https://bugs.kde.org/show_bug.cgi?id=421374

Dear maintainer,

A bug has been reported about this package that for programs that work on
konsole when clicking on them shows that it was not found.
This problem was corrected by the upstream, according to the links below
and bug tracker of KDE.

[1] https://phabricator.kde.org/D29738
[2]
https://invent.kde.org/frameworks/kio/commit/6452a34cf01d03d3167b38bc28a2fe8e13569021
[3]
https://forum.manjaro.org/t/could-not-find-the-program-konsole-error-after-manjaro-update/140484/7
[4] https://tracker.debian.org/pkg/kio

Greetings,

Leandro Cunha

Bug#966640: build-depends: debhelper-compat (= 13) cannot be satisfied

[Russ Allbery]

rharwood  writes:

> I think the debhelper-compat version is out of date:

> rharwood@eesha:~$ sudo aptitude build-dep krb5
> [sudo] password for rharwood:
> Unable to satisfy the build-depends: Build-Depends: debhelper-compat (= 
> 13)
> Unable to apply some actions, aborting
> rharwood@eesha:~$ 

13 is the current compatibility level and is provided by the debhelper
package.  I think there's something missing from your environment.  Could
it be Debian stable instead of unstable, for example?  If so, you'll need
to enable backports to get a current debhelper if you want to build the
unstable version of krb5.

-- 
Russ Allbery (r...@debian.org)  

Bug#966644: lintian: detect mismatches between symbols files and changelog versions

[Paul Wise]

Package: lintian
Severity: wishlist

In #966409 I detected that libjpeg-turbo added symbols without
including the epoch in the symbols version numbers.

It would be great if lintian could detect when a version number in the
symbols files does not match one of the upstream or Debian versions in
the Debian changelog files. Versions older than the oldest version in
the Debian changelog file can be ignored of course.

I'd suggest structuring this as two complaints with two severities:

 * At error level, probably ftp-master rejected, for when a symbols
   version is just missing the epoch. So a check that any of the
   versions in the Debian changelog file would match the symbol
   versions if the epoch were present in the symbols version.
 * At pedantic level, for when symbols version just doesn't match any
   of the versions in the Debian changelog file. Maybe later once there
   is an indication of how many false positives there are, this can
   then be elevated to warning level.

Both of these need to take into account that the versions in the
symbols file might be missing the Debian revision or they might have a
tilde appended to the Debian revision in order to allow backports.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#966409: libjpeg-turbo: versions in debian/*.symbols files are missing the epochs

[Paul Wise]

On Tue, 28 Jul 2020 11:55:02 + Mike Gabriel wrote:

> Please NMU (ideally with commits to the packaging Git).
> Also coordinate with Adrian Bunk.

FTR I won't be uploading but Adrian will be.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#966575: same error message here

[Miklós Quartus]

Dear Debian maintainers,

On Fri, 31 Jul 2020 22:39:22 +0200 cacat...@tuxfamily.org wrote:
> Package: grub-pc
> Version: 2.02+dfsg1-20+deb10u2
>
> Dear Maintainers,
>
> Don't know if it's useful but contributing infos I collected on this,
> since I ran into the same error message on a Lenovo Thinkpad T510
> running Debian Stable.

The same here. You should be more careful when upgrading or fixing a security 
issue in the boot loader. It currently breaks a Debian Buster system, which is 
production. The suggested grub reinstall method did _not_ work for me. I booted 
from a USB stick into rescue mode and had to downgrade grub-common package (I 
don’t have grub2 on my system) and reinstall all dependent packages again. 
After downgrading grub-common/grub2-common to version 2.02+dfsg1-20, my system 
boots and works fine.

Downgrade grub-common/grub2-common:

from: 2.02+dfsg1-20+deb10u2
to:2.02+dfsg1-20

and it did work after reboot.


See my APT history log for details.


“
Start-Date: 2020-07-31  22:52:35
Commandline: apt install grub-common=2.02+dfsg1-20
Downgrade: grub-common:amd64 (2.02+dfsg1-20+deb10u2, 2.02+dfsg1-20)
Remove: grub2-common:amd64 (2.02+dfsg1-20+deb10u2), grub-efi-amd64-bin:amd64 
(2.02+dfsg1-20+deb10u2), grub-efi-amd64:amd64 (2.02+dfsg1-20+deb10u2), 
shim-signed:amd64 (1.33+15+1533136590.3beb971-7), grub-efi-amd64-signed:amd64 
(1+2.02+dfsg1+20+deb10u2)
End-Date: 2020-07-31  22:53:28

Start-Date: 2020-07-31  22:55:36
Commandline: apt install grub2-common=2.02+dfsg1-20
Install: grub2-common:amd64 (2.02+dfsg1-20)
End-Date: 2020-07-31  22:55:41

Start-Date: 2020-07-31  22:56:39
Commandline: apt install grub-efi-amd64-bin=2.02+dfsg1-20
Install: grub-efi-amd64-bin:amd64 (2.02+dfsg1-20)
End-Date: 2020-07-31  22:56:53

Start-Date: 2020-07-31  22:57:09
Commandline: apt install grub-efi-amd64=2.02+dfsg1-20
Install: grub-efi-amd64:amd64 (2.02+dfsg1-20)
End-Date: 2020-07-31  22:57:33

Start-Date: 2020-07-31  22:58:43
Commandline: apt install grub-efi-amd64-signed=1+2.02+dfsg1+20
Install: shim-signed:amd64 (1.33+15+1533136590.3beb971-7, automatic), 
grub-efi-amd64-signed:amd64 (1+2.02+dfsg1+20)
End-Date: 2020-07-31  22:58:50
“

My kernel is: 4.19.0-9-amd64
No grub2.
grub-common, grub2-common is now at v2.02+dfsg1-20.
Debian Buster latest v10.4.
Linux package: linux-image-4.19.0-9-amd64-signed v4.19.118-2+deb10u1
I have working UEFI booting system, w/o secure boot and amd64 grub package UEFI 
signed by Debian.


Kind regards,
--
Miklós Quartus
q...@foresthacker.hu






signature.asc
Description: Message signed with OpenPGP

Bug#814851: INQUIRY

[KHALISH AMAR]

Good day Sir/Madam,


I am Khalish Amar, am the purchase manager of mckinsey Trading Company 
Malaysia. We have visited your site and would like to try your firm as we have 
been disappointed by our main suppliers with the less quality they are settled 
for, we would like very good quality of product as per whenever we place an 
order.

Kindly send me your latest/current catalogue so we can review your prices, 
please have in mind to give us your best prices and its very urgent as we need 
placing order as soon as possible in order to satisfy our customer requirements.

Hope to hear from you soon,

Thanks.


Khalish Amar
purchase Department
Overseers Business Unit
Website: https://www.mckinsey.com
Email:mckinseyimp...@hotmail.com
Skype:mckinseyimp...@hotmail.com

Bug#966641: Suggested tweaks for redis-openvas.conf to avoid stuck scans

[Christian Fischer]

Package: src:openvas-scanner
Version: 7.0.1-1~exp1

Dear Maintainer,

there are currently two problematic parts of the shipped
redis-openvas.conf which could be optimized:

> databases 16
(See [1])

and:

> save 900 1
> save 300 10
> save 60 1
(See [2])

Bot current settings are known to cause "stuck" scans. An example redis
config is available at [3] with some additional background info in [4]
and [5].

Regards,

[1]
https://salsa.debian.org/pkg-security-team/openvas-scanner/-/blob/8223e051d6405f1e905c3273e37b9ec3047688c7/debian/redis-openvas.conf#L186
[2]
https://salsa.debian.org/pkg-security-team/openvas-scanner/-/blob/8223e051d6405f1e905c3273e37b9ec3047688c7/debian/redis-openvas.conf#L218
[3]
https://github.com/greenbone/openvas/blob/v7.0.1/config/redis-openvas.conf
[4]
https://community.greenbone.net/t/hint-redis-setup-configuration-for-gse-gvm-openvas/333
[5] https://github.com/greenbone/openvas/blob/v7.0.1/doc/redis_config.txt

Bug#966575: grub-pc: error: symbol `grub_calloc' not found.

[Colin Watson]

On Sat, Aug 01, 2020 at 01:23:30AM +0200, MichaIng wrote:
> we face the same issue whenever a ready-to-run image has been created and
> booted from a different device.
> 
> From what we found, the Debian installer (or the grub install/config
> scripts) stores the hardware ID of the drive to debconf database, if one is
> available. Of course on a different machine this identifier and the related
> /dev/disk/by-id/ path is invalid. On VirtualBox and non-virtual PCs this is
> usually the case, on VMware on the other hand, ho hardware identifier
> exists, hence /dev/sda is stored there which is still valid when importing
> the same image to other VMware machines.

Indeed.

> I suggest to do the grub target check on `preinst` and skip/fail with error
> code if the debconf entry is invalid. It is better to skip or break the
> package upgrade and force admins to check/run manually then letting them
> running into a unbootable system.

That's fairly close to one of my suggestions in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966575#102.  It's not
necessary to move things to the preinst to make this work; it just needs
to be checked a bit more thoroughly before the postinst runs
grub-install.

> Otherwise elegant would be a scan to find the matching grub instance, but
> not sure how easy this is. At least the bootloader locations are fixed?

In principle it's impossible.  In practice it may be possible to do some
degree of guesswork; that's one of my other suggestions in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966575#102. :-)  We do
have to be pretty conservative though, as going overboard is likely to
break some multiboot setups.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#966575: same error message here

[Colin Watson]

Control: severity -1 grave

On Fri, Jul 31, 2020 at 10:40:34PM +0100, Colin Watson wrote:
> I'm going to downgrade this to non-release-critical.  It is absolutely a
> problem that we need to deal with (somehow ... it may be that in some
> cases we need to refuse to continue the upgrade instead, which would be
> a different kind of bug that would tend to be filed as release-critical
> too!), but given that it's a latent problem that would have been exposed
> by any change of a similar magnitude, I don't think it makes sense for
> it to block migration of this new version to testing.

On second thoughts, I'm going to leave this as RC for now.  I made some
specific suggestions in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966575#102 that I
think could probably be implemented without taking too long, and if we
do that before this reaches testing then that would reduce the number of
people with unbootable systems.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#966633: libmariadb3: In Perl, doing a ping() after a disconnect() causes a segfault using DBD::mysql

[Dianne Skoll]

Package: libmariadb3
Version: 1:10.3.22-0+deb10u1
Severity: important
Tags: patch

Hi,

The issue is described at https://github.com/perl5-dbi/DBD-mysql/issues/306
The following Perl script segfaults quite regularly:

use Test::More;
use DBI;

my $dbname = 'mysql';
my $user = 'user';
my $password = 'password';
chomp $password;
my $dbh = DBI->connect("dbi:mysql:$dbname;host=localhost",$user, $password,
{ mysql_auto_reconnect => 0 });
$dbh->disconnect();
ok( ! $dbh->ping(), 'dbh is disconnected and did not segv');

done_testing();

The problem is that mysql_close frees a couple of objects, but does not
set the pointer to those objects to NULL.  The ping() call references
freed memory and behavior is undefined.

The patch below fixes the problem.

Regards,

Dianne.

===
--- mariadb-10.3-10.3.22.orig/libmariadb/libmariadb/mariadb_lib.c
+++ mariadb-10.3-10.3.22/libmariadb/libmariadb/mariadb_lib.c
@@ -2000,6 +2000,8 @@ mysql_close(MYSQL *mysql)
 if (mysql->extension)
   free(mysql->extension);
 
+mysql->net.extension = NULL;
+mysql->extension = NULL;
 mysql->net.pvio= 0;
 if (mysql->free_me)
   free(mysql);
===


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

Kernel: Linux 5.7.11 (SMP w/12 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Bug#966632: Malformed debian patch for tools/gvm-migrate-to-postgres.in

[Christian Fischer]

Package: src:gvmd
Version: 9.0.1-1~exp1

Dear Maintainer,

currently the following patch is applied to the file
tools/gvm-migrate-to-postgres.in (see [1]):

-  HAVE_CACHE=`sqlite "SELECT EXISTS (SELECT FROM sqlite_master WHERE
type='table' AND name='permissions_get_tasks');"`
+  HAVE_CACHE=`sqlite "SELECT * EXISTS (SELECT FROM sqlite_master WHERE
type='table' AND name='permissions_get_tasks');"`

which should be the following instead (SELECT * FROM instead of SELECT *
EXISTS) as shown in the linked github patch/commit (see [2]):

-  HAVE_CACHE=`sqlite "SELECT EXISTS (SELECT FROM sqlite_master WHERE
type='table' AND name='permissions_get_tasks');"`
+  HAVE_CACHE=`sqlite "SELECT EXISTS (SELECT * FROM sqlite_master WHERE
type='table' AND name='permissions_get_tasks');"`

Regards,


[1]
https://salsa.debian.org/pkg-security-team/gvmd/-/blob/b1cf764952205dc9da6ccc0e58d05931f28204ac/debian/patches/Fix-gvm-migrate-to-postgres.patch#L22-23
[2]
https://github.com/greenbone/gvmd/commit/d994d8742558bfe0e82948a8a5cf92911d6d5884

Bug#966575: grub-pc: error: symbol `grub_calloc' not found.

[MichaIng]

Hey guys,

we face the same issue whenever a ready-to-run image has been created 
and booted from a different device.


From what we found, the Debian installer (or the grub install/config 
scripts) stores the hardware ID of the drive to debconf database, if one 
is available. Of course on a different machine this identifier and the 
related /dev/disk/by-id/ path is invalid. On VirtualBox and non-virtual 
PCs this is usually the case, on VMware on the other hand, ho hardware 
identifier exists, hence /dev/sda is stored there which is still valid 
when importing the same image to other VMware machines.


Since there is no software ID for non-fs disks like a UUID, the 
behaviour to use the hardware ID seems reasonable, to not rely on the 
bid unpredictable /dev/sd* path. However that this easily leads to 
unbootable systems when doing such trivial thing like booting a disk 
image and run some automated package upgrades on a new machine is a 
serious issue.


I suggest to do the grub target check on `preinst` and skip/fail with 
error code if the debconf entry is invalid. It is better to skip or 
break the package upgrade and force admins to check/run manually then 
letting them running into a unbootable system.


Otherwise elegant would be a scan to find the matching grub instance, 
but not sure how easy this is. At least the bootloader locations are fixed?


Proactive fix, where "/dev/sda" needs to be replaced in case:
---
debconf-set-selections <<< 'grub-pc grub-pc/install_devices multiselect 
/dev/sda'

---
Or of course use the hardware identifier path found in /dev/disk/by-id/.

Best regards,
Micha

Bug#966575: same error message here

[Colin Watson]

On Fri, Jul 31, 2020 at 11:27:18PM +0200, Miklós Quartus wrote:
> The same here. You should be more careful when upgrading or fixing a
> security issue in the boot loader.

We do take considerable care - the fact that sometimes problems slip
through doesn't mean we weren't careful.  (In general, this type of
problem relates to oddities of particular people's systems.)

> It currently breaks a Debian Buster system, which is production. The
> suggested grub reinstall method did _not_ work for me. I booted from a
> USB stick into rescue mode and had to downgrade grub-common package (I
> don’t have grub2 on my system) and reinstall all dependent packages
> again. After downgrading grub-common/grub2-common to version
> 2.02+dfsg1-20, my system boots and works fine.

Unlike other folks reporting this bug, you seem to be using UEFI.  That
means that you have a completely different problem, even though it
presents with similar symptoms.

Could you please file a *separate* bug report with details of the
problem you encountered?  We're also likely to need to know the
disk/partition/filesystem layout of your system, whether you're using
UEFI Secure Boot, and anything else that might be interesting about how
your machine boots.  This isn't the same thing as the other problems in
this bug, and we'll need to investigate it separately.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#966575: Security update can break grub - grub_calloc not found

[Colin Watson]

On Fri, Jul 31, 2020 at 03:07:58PM +0100, Geoff Gibbs wrote:
> mount /dev/sda5 /mnt
> grub-install --boot-directory=/mnt /dev/sda
> 
> has fixed the problem for me.

You should use "dpkg-reconfigure grub-pc" to update the system's idea of
which disk(s) to install to in future, or this problem may recur in a
future upgrade.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#966575: grub-pc: error: symbol `grub_calloc' not found.

[Colin Watson]

On Fri, Jul 31, 2020 at 02:06:53PM -0700, Chad Phillips wrote:
> This bug appears to affect a standard Vagrant install of Debian Buster as
> well. After booting, upgrading, and rebooting, I'm faced with the error.
> 
> The Vagrant base box is a fairly common one:
> https://app.vagrantup.com/bento/boxes/debian-10

I can reproduce this, but it only happens if you upgrade grub-pc
noninteractively, or if you upgrade it interactively and explicitly
choose to ignore the relatively insistent prompts about installing GRUB
somewhere.

You can see the problem here, after "vagrant init bento/debian-10" and
"vagrant up", before running the upgrade:

  vagrant@debian-10:~$ sudo debconf-show grub-pc | grep grub-pc/install_devices:
  * grub-pc/install_devices: 
/dev/disk/by-id/ata-VBOX_HARDDISK_VB9a8a894f-9374ac8c
  vagrant@debian-10:~$ ls -l /dev/disk/by-id
  total 0
  lrwxrwxrwx 1 root root  9 Jul 31 22:24 ata-VBOX_HARDDISK_VBeefaa213-4b33f182 
-> ../../sda
  lrwxrwxrwx 1 root root 10 Jul 31 22:24 
ata-VBOX_HARDDISK_VBeefaa213-4b33f182-part1 -> ../../sda1
  lrwxrwxrwx 1 root root 10 Jul 31 22:24 
ata-VBOX_HARDDISK_VBeefaa213-4b33f182-part2 -> ../../sda2
  lrwxrwxrwx 1 root root 10 Jul 31 22:24 
ata-VBOX_HARDDISK_VBeefaa213-4b33f182-part5 -> ../../sda5
  lrwxrwxrwx 1 root root 10 Jul 31 22:24 dm-name-debian--10--vg-root -> 
../../dm-0
  lrwxrwxrwx 1 root root 10 Jul 31 22:24 dm-name-debian--10--vg-swap_1 -> 
../../dm-1
  lrwxrwxrwx 1 root root 10 Jul 31 22:24 
dm-uuid-LVM-AHa0Cuw3bi6DXPasmzrqEr387MQdhJrwITlGZz1P8nfxOHl0uLYcTkF0r0sDcIlc -> 
../../dm-0
  lrwxrwxrwx 1 root root 10 Jul 31 22:24 
dm-uuid-LVM-AHa0Cuw3bi6DXPasmzrqEr387MQdhJrwvb35YFl6T9W6Vy8Gh8qyNGl96xAtCwRz -> 
../../dm-1
  lrwxrwxrwx 1 root root 10 Jul 31 22:24 
lvm-pv-uuid-CP04tS-xWMP-4zmQ-WbUt-U8JQ-bIHD-IuGjp0 -> ../../sda5

It looks like the base VM image provided by bento/debian-10 hardcodes
some details of how it was built that don't carry over to other systems
booting the same image, and this causes problems.

debian/buster64 has a similar problem, but with different details.  It
has:

  vagrant@buster:~$ sudo debconf-show grub-pc | grep grub-pc/install_devices:
  * grub-pc/install_devices: /dev/vda

But when I booted that in virtualbox, /dev/vda doesn't exist.  Upgrading
grub-pc suggested that I install to /dev/sda instead.  (I suspect
/dev/vda would have worked with libvirt; I haven't used vagrant before
and haven't yet managed to get its libvirt provider to work with some
quirks of the libvirt setup on my laptop.)

> I'm using the (admittedly insecure) solution  of "sudo apt-mark hold grub*"
> shown here: https://askubuntu.com/a/1263204

As several comments there note, a better fix is "sudo dpkg-reconfigure
grub-pc".

This is in some ways the most interesting subtype of this bug, because
it's one we can easily reproduce!  It falls into the category of "error
in a cloning process"; but it also makes it relatively straightforward
to experiment with ways to mitigate the problem further.

We could at minimum make this be an upgrade error in the noninteractive
case, ensuring that it doesn't touch modules if the target device is
just plain missing: the upgrade error might be a bit rough for some
people, but it would be better than a boot failure.

A refinement of this might be that if the system only has one disk, and
that disk appears to have GRUB installed on it (by relatively crude boot
sector scanning), then we could assume that this is the common case of a
disk having been swapped out and automatically change
grub-pc/install_devices to point to that instead.  With appropriate
guard rails, I think that could help quite a lot of the people affected
by this sort of problem.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#955469: initramfs-tools-core: Enable zstandard support

[Norbert Lange]

Am Fr., 31. Juli 2020 um 16:48 Uhr schrieb Sedat Dilek :
>
> Just FYI:
>
> Version 10 was now accepted in .
>
> Let's hope this will get into upcoming Linux v5.9.
>
> - Sedat -
>
> [1] https://github.com/terrelln/linux/commits/zstd-v10
> [2] 
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=x86/boot

Thanks,

I updated the patch, and made a merge request there:
https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests

Norbert

Bug#958883: unattended-upgrades pegs CPU at 100% for an extended period

[Matt Taggart]

I am also seeing unattended upgrade consume 100% CPU. Attached is a 
image of the cpu usage that started upon upgrade to buster. Each time uu 
runs the system has 30-40mins of 100% cpu spinning.


The system is running the current buster version, 1.11.2.

I see:
#958883 (this bug) - fixed in 2.4, might be the same issue?
#899366 - fixed in 1.4
#960966 - still open but strace seems different

The last things I see in strace -f are:


recvmsg(5, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base=NULL, 
iov_len=0}], msg_iovlen=1, msg_controllen=0, 
msg_flags=MSG_CTRUNC|MSG_TRUNC|MSG_CMSG_CLOEXEC}, 
MSG_PEEK|MSG_TRUNC|MSG_CMSG_CLOEXEC) = 20
recvmsg(5, {msg_name={sa_family=AF_NETLINK, nl_pid=0, 
nl_groups=}, msg_namelen=128->12, msg_iov=[{iov_base={{len=20, 
type=NLMSG_DONE, flags=NLM_F_MULTI, seq=0, pid=31505}, 0}, iov_len=20}], 
msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CTRUNC|MSG_CMSG_CLOEXEC}, 
MSG_CMSG_CLOEXEC) = 20

brk(0x79c5000)  = 0x79c5000
brk(0x7a1f000)  = 0x7a1f000
mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0x7f257770d000

mremap(0x7f257770d000, 1052672, 2101248, MREMAP_MAYMOVE) = 0x7f257750c000
mremap(0x7f257750c000, 2101248, 4198400, MREMAP_MAYMOVE) = 0x7f257710b000


I considered trying 2.5 from testing but it wants to pull in newer apt 
and some other things.

Is a backport of 2.5 to buster possible for testing?
Let me know if you want me to try anything.
This seems important enough to fix in a stable update.

--
Matt Taggart
tagg...@debian.org

Bug#966636: asterisk: after upfgrade from buster, no sip connections succeed due to silent ls 1.3 requirement

[Bernhard Schmidt]

Control: tags -1 confirmed

Hi,

> after upgrading the asterisk version from buster to testing, the pjsip 
> channel no longer accepts any connections, due to:
> 
> SSL SSL_ERROR_SSL (Handshake): Level: 0 err: <337678594>  routines-tls_early_post_process_client_hello-unsupported protocol>
> 
> as it turns out, this is because the new asterisk version enforces a minimum 
> tls version of 1.3, i.e., clients connecting with tls 1.2 (all of them for 
> us, as this includes android) can no longer connect.
> 
> There doesn't seem to be a way to confifgure this in pjsip.conf, at least not 
> a documented way, and even drastic workarounds such as method=sslv23 do not 
> help.

Confirmed. I will test with 16.12.0 and report the bug upstream if it is
still there.

method=tlsv1_2

seems to accept both TLSv1.2 and TLSv1.3 as a workaround.

Bernhard

Bug#948286: maven: CDK 2.3 fails to compile with Maven 3.6.2 with ClassNotFoundException

[Jorge Moraleda]

I confirm this is still an issue and that it can be manually fixed by
installing libplexus-utils2-java from Testing.

On Wed, 8 Jan 2020 17:35:04 +0200 Andrius Merkys  wrote:
> On Tue, 7 Jan 2020, 23:41 Emmanuel Bourg,  wrote:
>
> > I confirm this is not a cdk issue. It happened because the maven package
> > from testing was installed in stable and libplexus-utils2-java 3.2
> > wasn't brought along.
> >
> > This wouldn't happen if libmaven3-core-java had the correct versioned
> > dependency on libplexus-utils2-java. Unfortunately due to a bug in
> > maven-debian-helper the versioned dependency is wrong (the version is
> > 2.x instead of 3.2.1).
> >
>
> Hello,
>
> I was too quick to jump to conclusions, sorry. Is there a bug filed for
> this issue in maven-debian-helper? If so, we should consider merging this
> report to it.
>
> Best,
> Andrius
>
> >

Bug#966643: python3-jsonschema unnecessarily depends on python3-importlib-metadata

[Anthony Sottile]

Package: python3-jsonschema
Version: 3.2.0-3

For python3.8 and above, jsonschema should use `importlib.metadata`
from the standard library

You can see the conditional dependency listed in jsonschema's
setuptools metadata here:
https://github.com/Julian/jsonschema/blob/7a2cc2faf04a1182d3901bd907e87a746671f879/setup.cfg#L32

Anthony

Bug#957403: kexec-tools: diff for NMU version 1:2.0.20-2.1

[Khalid Aziz]

On 7/31/20 12:03 PM, casca...@debian.org wrote:
> Control: tags 957403 + patch
> 
> 
> Dear maintainer,
> 
> I've prepared an NMU for kexec-tools (versioned as 1:2.0.20-2.1). The diff
> is attached to this message.
> 
> Regards.
> 

Thanks! I appreciate it.

--
Khalid

Bug#966575: same error message here

[Colin Watson]

Control: severity -1 important

On Fri, Jul 31, 2020 at 10:39:22PM +0200, cacat...@tuxfamily.org wrote:
> Don't know if it's useful but contributing infos I collected on this,
> since I ran into the same error message on a Lenovo Thinkpad T510
> running Debian Stable.

For anyone affected by this bug, the workaround is to run
"dpkg-reconfigure grub-pc" as root and follow the instructions in the
"GRUB install devices" question.  If your system has already failed to
boot, you can use a rescue image of some kind to get back in: for
example, the Debian installer's rescue mode should be suitable.


This is a long-standing problem: we get a scattering of reports of the
same general kind with every GRUB upgrade that changes the binary
interface between GRUB's core image and modules in some way, although
the exact details depend on the upgrade in question.  The situation
certainly needs to be improved.

However, the problem is not with the actual changes made in this version
of GRUB.  Rather, it's a latent configuration problem on your system
(and on the systems of other people affected by this) that is triggered
by the act of making *any* change to GRUB that causes new modules in
/boot/grub not to be compatible with old core images in the boot sector
that your firmware jumps to when booting your machine.  This problem
happens on systems that are configured to run grub-install to a target
device that is not actually the one that your firmware uses to boot your
computer.

This configuration error is normally the result of something like
changing disks around without telling the GRUB packaging about it, so it
continues to install to an old device without realising it isn't the one
that your firmware is configured to boot from any more.  Sometimes it's
the result of a bug in some kind of installation or cloning process
instead.  Unfortunately it is rarely possible to tell exactly what
caused it from any information that still exists on the systems in
question; sometimes the affected users have an idea what might have
happened and sometimes they don't.  The packaging tries to detect some
problems along these lines - I did considerable work on this way back in
2010 to try to improve the situation - and the volume of reports of this
kind is much lower than it used to be as a result, but it still happens
sometimes.

I'm going to downgrade this to non-release-critical.  It is absolutely a
problem that we need to deal with (somehow ... it may be that in some
cases we need to refuse to continue the upgrade instead, which would be
a different kind of bug that would tend to be filed as release-critical
too!), but given that it's a latent problem that would have been exposed
by any change of a similar magnitude, I don't think it makes sense for
it to block migration of this new version to testing.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#957614: nut: ftbfs with GCC-10

[Lucas Kanashiro]

Hi,

I submitted a merge request updating the symbols file which will fix the
FTBFS with GCC-10:

https://salsa.debian.org/debian/nut/-/merge_requests/2

Thanks for considering the patch.

-- 
Lucas Kanashiro

Bug#966642: libengine-gost-openssl1.1 successfully cross builds a broken package

[Helmut Grohne]

Source: libengine-gost-openssl1.1
Version: 1.1.0.3-1
Tags: patch

cross building libengine-gost-openssl1.1 succeeds. However it looks up
the engine directory from the openssl command, which happens to be the
build architecture path since openssl is marked Multi-Arch: foreign.
However, the host architecture engine path must be used. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru libengine-gost-openssl1.1-1.1.0.3/debian/changelog 
libengine-gost-openssl1.1-1.1.0.3/debian/changelog
--- libengine-gost-openssl1.1-1.1.0.3/debian/changelog  2018-09-16 
17:58:16.0 +0200
+++ libengine-gost-openssl1.1-1.1.0.3/debian/changelog  2020-07-31 
22:41:02.0 +0200
@@ -1,3 +1,10 @@
+libengine-gost-openssl1.1 (1.1.0.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix openssl engine path for cross compilation. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 31 Jul 2020 22:41:02 +0200
+
 libengine-gost-openssl1.1 (1.1.0.3-1) unstable; urgency=medium
 
   * New upstream version
diff --minimal -Nru libengine-gost-openssl1.1-1.1.0.3/debian/rules 
libengine-gost-openssl1.1-1.1.0.3/debian/rules
--- libengine-gost-openssl1.1-1.1.0.3/debian/rules  2018-09-16 
17:58:16.0 +0200
+++ libengine-gost-openssl1.1-1.1.0.3/debian/rules  2020-07-31 
22:41:00.0 +0200
@@ -16,7 +16,7 @@
 # package maintainers to append LDFLAGS
 #export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
-OPENSSL_ENGINE_DIR=$(shell openssl version -e |sed -e 's/^[^.]*"//' -e 
's/".*$$//')
+OPENSSL_ENGINE_DIR=$(shell openssl version -e |sed -e 's/^[^.]*"//' -e 
's/".*$$//' -e 's/$(DEB_BUILD_MULTIARCH)/$(DEB_HOST_MULTIARCH)/')
 # main packaging script based on dh7 syntax
 %:
dh $@ 

Bug#882145: asterisk: pjsip show history causes segmentation fault

[Bernhard Schmidt]

> 0x7fff8d3a11d0 in sprint_list_entry
> (entry=entry@entry=0x55d91ff8, line=line@entry=0x7fffabc902b0
> "[2001:4ca0:0:10a:215:65ff:feb7:4e7e]:11922", len=256) at
> res_pjsip_history.c:663

Benoit, are you using IPv6? If yes,
https://issues.asterisk.org/jira/browse/ASTERISK-28854 could be the
culprit.

Bernhard

Bug#862727: RFP: libjasper -- JasPer JPEG-2000 runtime library

[Steven Robbins]

On Tue, 16 May 2017 11:40:41 +0200 Adam Cecile  wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-CC: debian-de...@lists.debian.org
> 
> Package name: libjasper
> Version: 2.0.12
> Upstream: Michael David Adams
> License: JasPer License
> Description: This package has been scheduled for removal after Stretch 
> release but is very important to me ...

For what it's worth: JasPer upstream has recently been revived: 
https://github.com/jasper-software/jasper/issues/208


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

Bug#966575: grub-pc: error: symbol `grub_calloc' not found.

[Chad Phillips]

This bug appears to affect a standard Vagrant install of Debian Buster as
well. After booting, upgrading, and rebooting, I'm faced with the error.

The Vagrant base box is a fairly common one:
https://app.vagrantup.com/bento/boxes/debian-10

I'm guessing this is a fairly standard disk layout in their build:

# fdisk -l
Disk /dev/sda: 64 GiB, 68719476736 bytes, 134217728 sectors
Disk model: VBOX HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x1b8eb89d

Device Boot  Start   End   Sectors  Size Id Type
/dev/sda1  *  2048499711497664  243M 83 Linux
/dev/sda2   501758 134215679 133713922 63.8G  5 Extended
/dev/sda5   501760 134215679 133713920 63.8G 8e Linux LVM


Disk /dev/mapper/debian--10--vg-root: 62.8 GiB, 67385688064 bytes,
131612672 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/debian--10--vg-swap_1: 1 GiB, 1073741824 bytes, 2097152
sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

I'm using the (admittedly insecure) solution  of "sudo apt-mark hold grub*"
shown here: https://askubuntu.com/a/1263204

Chad

Bug#966575: same error message here

[cacatoes]

Package: grub-pc
Version: 2.02+dfsg1-20+deb10u2

Dear Maintainers,

Don't know if it's useful but contributing infos I collected on this,
since I ran into the same error message on a Lenovo Thinkpad T510
running Debian Stable.

Some specifics are :
- I use unattended-upgrades, so it might be I missed something
- Install was made with no root password set, but I set one recently.
- It has a LUKS partition but it's secondary and not a system mount
  point.
- It runs a kernel from the backports.

What happened :

Start-Date: 2020-07-30  09:09:13
Commandline: /usr/bin/unattended-upgrade
Upgrade: grub-common:amd64 (2.02+dfsg1-20, 2.02+dfsg1-20+deb10u1),
grub2-common:amd64 (2.02+dfsg1-20, 2.02+dfsg1-20+deb10u1), grub-pc:amd64
(2.02+dfsg1-20, 2.02+dfsg1-20+deb10u1), grub-pc-bin:amd64
(2.02+dfsg1-20, 2.02+dfsg1-20+deb10u1)
End-Date: 2020-07-30  09:09:25

Start-Date: 2020-07-30  09:09:27
Commandline: /usr/bin/unattended-upgrade
Upgrade: firefox-esr-l10n-fr:amd64 (68.10.0esr-1~deb10u1,
68.11.0esr-1~deb10u1), firefox-esr:amd64 (68.10.0esr-1~deb10u1,
68.11.0esr-1~deb10u1)
End-Date: 2020-07-30  09:09:38

Start-Date: 2020-07-31  10:41:26
Commandline: /usr/bin/unattended-upgrade
Upgrade: grub-common:amd64 (2.02+dfsg1-20+deb10u1,
2.02+dfsg1-20+deb10u2), grub2-common:amd64 (2.02+dfsg1-20+deb10u1,
2.02+dfsg1-20+deb10u2), grub-pc:amd64 (2.02+dfsg1-20+deb10u1,
2.02+dfsg1-20+deb10u2), grub-pc-bin:amd64 (2.02+dfsg1-20+deb10u1,
2.02+dfsg1-20+deb10u2)
End-Date: 2020-07-31  10:41:36

Reboot on 2020-07-31 @ 22:00:00, then same error message than OP.

Fixed situation by rebooting on a USB key with Debian installer, rescue
mode, reinstalling grub on /dev/sda.

More system infos in attachment.
-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda1 / ext4 rw,relatime,errors=remount-ro 0 0
/dev/sda8 /mnt/debiantesting ext4 rw,relatime 0 0
/dev/sda6 /home ext4 rw,relatime 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  
ad4ff815-580a-4bad-965f-c66dbd806733
else
  search --no-floppy --fs-uuid --set=root ad4ff815-580a-4bad-965f-c66dbd806733
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=fr_FR
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=1
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=1
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  
ad4ff815-580a-4bad-965f-c66dbd806733
else
  search --no-floppy --fs-uuid --set=root ad4ff815-580a-4bad-965f-c66dbd806733
fi
insmod png
if background_image 
/usr/share/desktop-base/futureprototype-theme/grub/grub-4x3.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-ad4ff815-580a-4bad-965f-c66dbd806733' {
load_video

Bug#966626: evolution: does not use proxy settings

[Patrick Zanon]

Package: evolution
Version: 3.36.4-1
Severity: important

Dear Maintainer,

I work in a poxy based intranet configuration so it is not possible to
reach directly internet email servers. So it is necessary to have a
proxy configured, and in my case there is, and it works perfectly with
my browsers.

I tried to use them also in evolution with no success: 
 * I specified 
   + a system wide configurations of proxy, 
   + and a evolution specific configuration of proxy, considering 
  . a default configuration (the same for all mailboxex)
  . and a specific one for google mailboxes

 * the proxy definition was specified
   + by referring to the system wide configuration
   + with a proxy.pac file obtained from the local net
   + with environment variables manually set in the profile dir
   + and also manually into the configuration fields

In every combination of these cases, evolution still refuses to 
use the proxy and to connect to external mailboxes, while the internal
one is correcly managed.

P.Z.





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

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

Versions of packages evolution depends on:
ii  dbus   1.12.20-1
ii  evolution-common   3.36.4-1
ii  evolution-data-server  3.36.4-1
ii  libc6  2.31-2
ii  libcamel-1.2-623.36.4-1
ii  libclutter-gtk-1.0-0   1.8.4-4
ii  libecal-2.0-1  3.36.4-1
ii  libedataserver-1.2-24  3.36.4-1
ii  libevolution   3.36.4-1
ii  libglib2.0-0   2.64.4-1
ii  libgtk-3-0 3.24.20-1
ii  libical3   3.0.8-2
ii  libnotify4 0.7.9-1
ii  libsoup2.4-1   2.70.0-1
ii  libwebkit2gtk-4.0-37   2.28.3-2
ii  libxml22.9.10+dfsg-5+b1
ii  psmisc 23.3-1

Versions of packages evolution recommends:
ii  evolution-plugin-bogofilter  3.36.4-1
ii  evolution-plugin-pstimport   3.36.4-1
ii  evolution-plugins3.36.4-1
ii  yelp 3.36.0-1

Versions of packages evolution suggests:
ii  evolution-ews   3.36.4-1
pn  evolution-plugins-experimental  
ii  gnupg   2.2.20-1
ii  network-manager 1.26.0-1

-- no debconf information

Bug#932298: krb5-admin-server: Confusing error if DES encryption types are enabled

[rharwood]

Package: krb5-admin-server
Version: 1.17-10
Followup-For: Bug #932298
Control: tags -1 + patch

Hi,

I believe I fixed this upstream in https://github.com/krb5/krb5/pull/1094

Thanks,
--Robbie

Bug#966640: build-depends: debhelper-compat (= 13) cannot be satisfied

[rharwood]

Source: krb5
Severity: normal

Hi Sam, Ben, Russ,

I think the debhelper-compat version is out of date:

rharwood@eesha:~$ sudo aptitude build-dep krb5
[sudo] password for rharwood:
Unable to satisfy the build-depends: Build-Depends: debhelper-compat (= 13)
Unable to apply some actions, aborting
rharwood@eesha:~$ 

Thanks,
--Robbie

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (700, 'testing-debug'), (700, 'testing'), (500, 
'unstable-debug'), (500, 'unstable'), (300, 'experimental-debug'), (300, 
'experimental')
Architecture: amd64 (x86_64)

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

Bug#966639: lybniz: Lybniz depends on python3-scipy

[Oliver Schode]

Package: lybniz
Version: 3.0.4-3
Severity: important

Hi,

lybniz expects a scipy installation present, but it's currently missing
from the dependencies:


Versions of packages lybniz depends on:
ii  gir1.2-gdkpixbuf-2.0  2.40.0+dfsg-5
ii  gir1.2-glib-2.0   1.64.1-1
ii  gir1.2-gtk-3.03.24.20-1
ii  gir1.2-pango-1.0  1.44.7-4
ii  python3   3.8.2-3
ii  python3-cairo 1.16.2-4
ii  python3-gi3.36.0-4

lybniz recommends no packages.

lybniz suggests no packages.

Bug#966624: please build firmware for qemu ppc e500 machine

[Vagrant Cascadian]

Control: tags 966624 patch

On 2020-07-31, Michael Tokarev wrote:
> qemu powerpc machine emulation uses u-boot for booting,
> and this firmware image is currently missing.  Please
> provide a package containing such firmware.
>
> Here's how it is built within qemu sources (where u-boot
> is present as a submodule):
>
> u-boot.e500:
> $(MAKE) -C u-boot O=build.e500 qemu-ppce500_config
> $(MAKE) -C u-boot CROSS_COMPILE=$(powerpc_cross_prefix) \
> O=build.e500
> $(powerpc_cross_prefix)strip u-boot/build.e500/u-boot -o \
> ../pc-bios/u-boot.e500

The following *untested* patch might work:

diff --git a/debian/control b/debian/control
index d6f24e3218..f7019e5207 100644
--- a/debian/control
+++ b/debian/control
@@ -28,6 +28,7 @@ Build-Depends-Indep:
  gcc-aarch64-linux-gnu [!arm64],
  gcc-riscv64-linux-gnu [!riscv64],
  gcc-x86-64-linux-gnu [!amd64],
+ gcc-powerpc-linux-gnu [!powerpc],
 Rules-Requires-Root: no
 Standards-Version: 4.5.0
 Homepage: http://www.denx.de/wiki/U-Boot/
diff --git a/debian/rules b/debian/rules
index 5cafdbf0e0..1bd0591119 100755
--- a/debian/rules
+++ b/debian/rules
@@ -87,6 +87,7 @@ build-targets: configs/novena-rawsd_defconfig 
configs/am335x_boneblack_defconfig
all:mips) export CROSS_COMPILE=mips-linux-gnu- ;;\
all:mipsel) export CROSS_COMPILE=mipsel-linux-gnu- ;;\
all:mips64el) export 
CROSS_COMPILE=mips64el-linux-gnuabi64- ;;\
+   all:powerpc) export CROSS_COMPILE=powerpc-linux-gnu- ;;\
all:riscv64) export CROSS_COMPILE=riscv64-linux-gnu- ;;\
all:i386) export CROSS_COMPILE=i686-linux-gnu- ;;\
all:amd64) export CROSS_COMPILE=x86_64-linux-gnu- ;;\
diff --git a/debian/targets b/debian/targets
index 9bd210d46d..78db9c7ade 100644
--- a/debian/targets
+++ b/debian/targets
@@ -262,5 +262,6 @@ all:amd64   qemuqemu-x86_64 u-boot.bin
 all:armhf  qemuqemu_armu-boot.bin
 all:arm64  qemuqemu_arm64  u-boot.bin
 all:i386   qemuqemu-x86u-boot.bin
+all:powerpcqemuqemu-ppce500u-boot.elf
 all:riscv64qemuqemu-riscv64u-boot.bin
 all:riscv64qemuqemu-riscv64_smode  u-boot.bin


> qemu expects this image to be found as /usr/share/qemu/u-boot.e500
> (this is the directory where all other images are located).

You would still need to symlink /usr/lib/u-boot/qemu-ppce500/uboot.elf
to the location that qemu expects it.


> I dunno what's the name to suggest for this package, since
> u-boot-qemu is already taken and it provides different images,
> not directly used by qemu.  Maybe qemu-uboot or something, dunno.

I would just add it to u-boot-qemu; it is still a small number of
targets and each one is not very large, and while qemu does not use the
other targets shipped in u-boot-qemu out-of-the-box, they can be used
with qemu.


> There's a bug open in the Debian BTS about this, #756833 , - open
> for a long time already.  The difference from this #756833 context
> is that now, powerpc cross-compiler is available and can be used
> for build-dependencies.

I'll read up on that bug later...

> I can build this firmware directly from the qemu sources (which
> includes roms/u-boot), and qemu already uses powerpc cross-gcc
> to build other things, but this is something to avoid in Debian.

Right!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#908908: turn lvm2-dbusd Architecture: all

[Helmut Grohne]

Hi Bastian,

On Sun, Jul 26, 2020 at 01:38:02PM +0200, Bastian Blank wrote:
> On Sat, Sep 15, 2018 at 09:01:02PM +0200, Helmut Grohne wrote:
> >  * There is a longer dependency cycle between lvm2 (via systemd) through
> >python3. Turning lvm2-dbusd Architecture: all means that all of the
> >python depends can be moved to Build-Depends-Indep solving the cycle.
> 
> There is a clear build-dep cycle between lvm2 and systemd, via
> cryptsetup.  Not sure what a possible cycle via python3 would be.

Yes, there is. However, systemd has a build profile to break that
particular cycle.

We do bootstrap without python these days. Cross building Python
extensions is still too unreliable to rely on during architecture
bootstrap. Most of the relevant packages have split out their python
bindings via build profiles or b-d-i. lvm2 needs this at least for the
cross bootstrap even after resolving any remaining cycles.

Even then, the python3-dbus dependency is a deal-breaker. dbus-python
Build-Depends on python3-gi and gobject-introspection doesn't work for
cross compilation. This is not going to be fixed any time soon. You
cannot have gobject-introspection in the bootstrap set.

Beyond that, https://bootstrap.debian.net/botch-native/amd64/stats.html
reports src:lvm2 -> python3-pyudev as a strong bridge.

Trust me, the python bindings need to be droppable for lvm2. I gave you
a simple solution. I fear using build profiles will be slightly more
complex. Do you prefer that?

I also note that I am a little unsatisfied with the combination of your
response time for patches and your NACK-time for NMUs. Please bring them
closer together.

Helmut

Bug#966638: gkrellm-cpufreq: Error: /usr/lib/gkrellm2/plugins/cpufreq.so: undefined symbol: cpufreq_cpu_exists

[Helmut Grohne]

Package: gkrellm-cpufreq
Version: 0.6.4-6+b1
Severity: grave
Justification: plugin cannot be loaded into gkrellm anymore

gkrellm-cpufreq no longer works. The plugin install log says:

| Error: /usr/lib/gkrellm2/plugins/cpufreq.so: undefined symbol: 
cpufreq_cpu_exists

Downgrading to 0.6.4-4+b2 makes the plugin work again. I haven't tested
any other versions in between. I think libcpufreq0 -> libcpupower1
conversion went wrong here.

Helmut

Bug#943719: closed by Debian FTP Masters (reply to godi...@debian.org (Martin A. Godisch)) (Bug#943719: fixed in cgoban 1.9.14-19)

[Helmut Grohne]

Control: reopen -1

On Sun, Jul 26, 2020 at 02:45:03PM +, Debian Bug Tracking System wrote:
>   * Fixed FTCBFS: ./configure thinks it cannot cross, closes: #943719.
> Thanks to Helmut Grohne.

You patched configure.in. However, configure is not built from source.
Therefore it still is buggy and the cross build still fails. Please
rebuild configure.

I strongly recommend using dh-autoreconf.

Helmut

Bug#859388: Bug#908908: lvm2 NMU

[Helmut Grohne]

On Sun, Jul 26, 2020 at 11:22:35AM +0200, Bastian Blank wrote:
> On Sun, Jul 26, 2020 at 07:21:38AM +0200, Helmut Grohne wrote:
> > I've prepared a NMU fixing these long-standing bugs with patches. Thanks
> > to all the contributors. I've uploaded it to delayed/15. Please let me
> > know if I should defer it any longer. I'm attaching a .debdiff of the
> > proposed changes.
> 
> Don't.  At least in this form.

Cancelled.

> > diff --minimal -Nru lvm2-2.03.07/debian/.gitignore 
> > lvm2-2.03.07/debian/.gitignore
> > --- lvm2-2.03.07/debian/.gitignore  2020-01-07 14:46:03.0 +0100
> > +++ lvm2-2.03.07/debian/.gitignore  1970-01-01 01:00:00.0 +0100
> > @@ -1,8 +0,0 @@
> > -/autoreconf.*
> > -/debhelper*
> > -/files
> > -/*.debhelper
> > -/*.log
> > -/*.substvars
> > -/*/
> > -!/bin/
> 
> .gitignore is git metadata.  How does this relate to anything?

I have no clue. The .gitignore gets deleted by dpkg-source. I have no
clue why it does that nor how to make it stop. If lvm2 does not work
with dpkg-source, then most likely, it's a bug in lvm2. I considered
this a minor nuisance easily reverted with the next MU that is properly
tracked in git.

> > diff --minimal -Nru lvm2-2.03.07/debian/control lvm2-2.03.07/debian/control
> > --- lvm2-2.03.07/debian/control 2020-01-07 14:46:03.0 +0100
> > +++ lvm2-2.03.07/debian/control 2020-07-18 20:53:01.0 +0200
> > @@ -5,7 +5,6 @@
> >  Uploaders: Bastian Blank 
> >  Build-Depends:
> >   debhelper (>= 10.9.2),
> > - dh-python,
> 
> Needed by python packages.

I know. Why do you tell me?

> > @@ -59,8 +60,8 @@
> >   regular block devices.
> >  
> >  Package: lvm2-dbusd
> > -Architecture: linux-any
> > -Depends: ${shlibs:Depends}, ${python3:Depends}, ${misc:Depends}, lvm2 (= 
> > ${binary:Version}), dbus,
> > +Architecture: all
> > +Depends: ${python3:Depends}, ${misc:Depends}, lvm2 (>= ${source:Version}), 
> > lvm2 (<< ${source:Version}.1), dbus,
> 
> Err, no hacks in dependencies.

Please point out what the hack is. This is a standard approach for
having a version-locked dependency from an arch:all on an arch:any
package. No hack involved.

> > diff --minimal -Nru lvm2-2.03.07/debian/rules lvm2-2.03.07/debian/rules
> > --- lvm2-2.03.07/debian/rules   2020-01-07 14:46:03.0 +0100
> > +++ lvm2-2.03.07/debian/rules   2020-07-18 20:53:01.0 +0200
> > @@ -27,7 +27,8 @@
> >  endif
> >  
> >  %:
> > -   dh $@ --parallel --with python3
> > +   dh $@ --parallel $(DH_ADDONS)
> > +build binary %-indep: DH_ADDONS+=--with=python3
> 
> No.

Can you explain why?

There now is a simpler way to achive the same:

Build-Depends: debhelper-compat (= 13)
Build-Depends-Indep: dh-sequence-python3

Does that work any better?

Helmut

Bug#966637: libarchive FTCBFS: multiple issues

[Helmut Grohne]

Source: libarchive
Version: 3.4.3-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability ftcbfs

libarchive fails to cross build from source for three reasons:
 * Its gcc dependency is not cross-satisfiable. We need to perform
   toolchain dependency translation here, but this is not yet supported
   on the toolchain side. Bummer. Fortunately, the versioned dependency
   is implicitly satisfied even in oldstable. It can simply be dropped.
 * The locales | locales-all dependency is not cross-satisfiable. The
   locales-all alternative would help cross compilation, but sbuild
   drops alternatives and locales is not Multi-Arch: foreign.
   Fortunately, this is only needed for running tests, so we can opt out
   using .
 * debian/rules wrongly matches for DEB_BUILD_OPTIONS=nocheck. Fix the
   pattern.

After applying the attached patch, libarchive cross builds successfully.
Please consider using it.

Helmut
diff --minimal -Nru libarchive-3.4.3/debian/changelog 
libarchive-3.4.3/debian/changelog
--- libarchive-3.4.3/debian/changelog   2020-06-03 15:40:28.0 +0200
+++ libarchive-3.4.3/debian/changelog   2020-07-31 19:41:19.0 +0200
@@ -1,3 +1,12 @@
+libarchive (3.4.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: correctly implement DBE_BUILD_OPTIONS=nocheck
+  * Annotate locale build dependencies with .
+  * Drop versioned gcc from Build-Depends as it is satisfied in oldstable.
+
+ -- Helmut Grohne   Fri, 31 Jul 2020 19:41:19 +0200
+
 libarchive (3.4.3-1) unstable; urgency=medium
 
   * New upstream release:
diff --minimal -Nru libarchive-3.4.3/debian/control 
libarchive-3.4.3/debian/control
--- libarchive-3.4.3/debian/control 2020-06-03 15:40:28.0 +0200
+++ libarchive-3.4.3/debian/control 2020-07-31 19:41:17.0 +0200
@@ -2,7 +2,6 @@
 Priority: optional
 Maintainer: Peter Pentchev 
 Build-Depends: debhelper-compat (= 13),
-   gcc (>> 4:9.2.1~),
pkg-config,
libbz2-dev,
liblz4-dev,
@@ -16,7 +15,7 @@
sharutils,
nettle-dev,
liblzo2-dev,
-   locales | locales-all
+   locales  | locales-all ,
 Standards-Version: 4.5.0
 Section: libs
 Homepage: https://www.libarchive.org/
diff --minimal -Nru libarchive-3.4.3/debian/rules libarchive-3.4.3/debian/rules
--- libarchive-3.4.3/debian/rules   2020-06-03 15:40:28.0 +0200
+++ libarchive-3.4.3/debian/rules   2020-07-31 19:40:49.0 +0200
@@ -22,7 +22,7 @@
find debian -name '*.la' -delete
 
 override_dh_auto_test:
-ifneq (,$(filter check,$(DEB_BUILD_OPTIONS)))
+ifneq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
 ifneq (,$(shell locale -a | grep en_US.utf8))
_VERBOSITY_LEVEL=1 dh_auto_test --parallel
 else

Bug#952871: itstool: Segmentation Fault when Merging French Translation

[François Mazen]

fixed 952871
thanks

Can not reproduce on recent sid, package versions:

itstool 2.0.6-1
python3 3.8.2-3
python3-libxml2 2.9.10+dfsg-5+b1

It was probably an issue in python3-libxml2.

Thanks,
François

Bug#966636: asterisk: after upfgrade from buster, no sip connections succeed due to silent ls 1.3 requirement

[anonymous envelope]

Package: asterisk
Version: 1:16.10.0~dfsg-1
Severity: normal

Dear Maintainer,

after upgrading the asterisk version from buster to testing, the pjsip channel 
no longer accepts any connections, due to:

SSL SSL_ERROR_SSL (Handshake): Level: 0 err: <337678594> 

as it turns out, this is because the new asterisk version enforces a minimum 
tls version of 1.3, i.e., clients connecting with tls 1.2 (all of them for us, 
as this includes android) can no longer connect.

There doesn't seem to be a way to confifgure this in pjsip.conf, at least not a 
documented way, and even drastic workarounds such as method=sslv23 do not help.

I think an enforced tls 1.3 minimum version is too harsh.

For reference, here is the transport configuration that works with asterisk 
16.2 in buster:

[transport-tls]
type=transport
protocol=tls
bind=0.0.0.0
cert_file=...
priv_key_file=...
method=tlsv1

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages asterisk depends on:
ii  adduser  3.118
ii  asterisk-config  1:16.10.0~dfsg-1
ii  asterisk-core-sounds-en  1.6.1-1
ii  asterisk-modules 1:16.10.0~dfsg-1
ii  libc62.31-2
ii  libcap2  1:2.25-2
ii  libcrypt11:4.4.16-1
ii  libedit2 3.1-20181209-1
ii  libjansson4  2.12-1
ii  libpopt0 1.16-12
ii  libsqlite3-0 3.27.2-3
ii  libssl1.11.1.1d-0+deb10u3
ii  libsystemd0  241-7~deb10u4
ii  liburiparser10.9.1-1
ii  libuuid1 2.33.1-0.1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxslt1.1   1.1.32-2.2~deb10u1
ii  lsb-base 10.2019051400

Versions of packages asterisk recommends:
ii  asterisk-moh-opsound-gsm 2.03-1
ii  asterisk-voicemail [asterisk-voicemail-storage]  1:16.10.0~dfsg-1
ii  sox  14.4.2+git20190427-1

Versions of packages asterisk suggests:
pn  asterisk-dahdi   
pn  asterisk-dev 
pn  asterisk-doc 
ii  asterisk-ooh323  1:16.10.0~dfsg-1
ii  asterisk-opus13.7+20171009-2
pn  asterisk-vpb 

-- no debconf information

Bug#966635: RFS: filezilla/3.49.1-1 [Team] -- Full-featured graphical FTP/FTPS/SFTP client

[Phil Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: filezilla
   Version : 3.49.1-1
   Upstream Author : Tim Kosse 
 * URL : https://filezilla-project.org/
 * License : MIT, BSD-like, GPL-2+, permissive, CC0-1.0
 * Vcs : https://salsa.debian.org/debian/filezilla
   Section : net

It builds those binary packages:

  filezilla-common - Architecture independent files for filezilla
  filezilla - Full-featured graphical FTP/FTPS/SFTP client

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/filezilla/filezilla_3.49.1-1.dsc

Changes since the last upload:

 filezilla (3.49.1-1) unstable; urgency=medium
 .
   * Team upload
   * New upstream version 3.49.1
   * Updated libfilezilla-dev versioned build-dep to 0.23.0
   * Bump std-version to 4.5.0, no changes required
   * Bump debhelper-compat to 13
   * Add Rules-Requires-Root: no
   * Disable dwz as not beneficial on filezilla binary
   * Add hardening

Regards

Phil

-- 

*** Playing the game for the games sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B



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

Bug#966634: RFS: libfilezilla/0.23.0-1 [Team] -- build high-performing platform-independent programs (runtime lib)

[Phil Wyett]

package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: libfilezilla
   Version : 0.23.0-1
   Upstream Author : Tim Kosse 
 * URL : https://lib.filezilla-project.org/
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/libfilezilla
   Section : libs

It builds those binary packages:

  libfilezilla0 - build high-performing platform-independent programs
(runtime lib)
  libfilezilla-dev - build high-performing platform-independent programs
(development)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libf/libfilezilla/libfilezilla_0.23.0-1.dsc

Changes since the last upload:

 libfilezilla (0.23.0-1) unstable; urgency=medium
 .
   * Team upload
   * New upstream version 0.23.0
   * Add hardening
   * Use override_dh_auto_install and remove .la file(s)
   * Bump std-version to 4.5.0, no changes required
   * Bump debhelper-compat to 13
   * Add Rules-Requires-Root: no

Regards

Phil

-- 

*** Playing the game for the games sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B



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

Bug#966548: Further information

[Daniel Teichmann]

Further information can be retrieved here:

https://github.com/novnc/noVNC/issues/1276

-- 

DAS-NETZWERKTEAM
Daniel Teichmann

GnuPG Key ID 0x8100A778
mail: daniel.teichm...@das-netzwerkteam.de, http://das-netzwerkteam.de




signature.asc
Description: OpenPGP digital signature

Bug#964915: Raspi 4 debian image update-initramfs

[basti]

OK thanks lucas and Gunnar.
Sorry for any inconvenience that I does not found this bugreport.
Have a nice weekend.


Am 31.07.20 um 18:09 schrieb Gunnar Wolf:
> [ Adding a Cc: to #964915 ] Lucas Nussbaum dijo [Fri, Jul 31, 2020 at
> 02:15:29PM +0200]:
>> Hi, Can you confirm that it's not
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964915
> Yes, that's precisely the culprit. Even more - Both basti and me
> didn't find it any further because (I guess) we both booted with the
> HDMI console. When using a serial console, I found the all too
> familiar: Begin: Running /scripts/local-block ... done. Begin: Running
> /scripts/local-block ... done. Begin: Running /scripts/local-block ...
> done. And of course, after a couple iterations, I got dumped to the
> very useful busybox: Begin: Running /scripts/local-block ... done.
> Begin: Running /scripts/local-block ... done. done. Gave up waiting
> for root file system device. Common problems: - Boot args (cat
> /proc/cmdline) - Check rootdelay= (did the system wait long enough?) -
> Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/mmcblk0p2
> does not exist. Dropping to a shell! BusyBox v1.30.1 (Debian
> 1:1.30.1-4) built-in shell (ash) Enter 'help' for a list of built-in
> commands. (initramfs) So, Basti: 1. Try editing cmdline.txt in your
> first partition, replacing «/dev/mmcblk0p2» by «LABEL=RASPIROOT» as
> the bug report suggests 2. If you don't use a serial console, consider
> removing the «console=ttyS1,115200» part, so that the main information
> is sent to the HDMI output. Or even better, swap the order, so that
> the serial console functionality is preserved, but the main console is
> HDMI. So, we should definitively address item 1, as it is a serious
> bug (and I'm bumping up severity - It will affect all Raspberry
> models, not just the 4). As for 2... well, we can document it and
> maybe add some black magic to the initrd generation to allow the user
> to specify what the default console should be. But as the preferences
> are completely depending on the user and there is no "righter"
> value... And, following Lucas' report -- I think his last point
> actually makes a lot of sense: 1) setting ROOTPART=`findmnt -n
> --output=source /boot/firmware/`, 2) or using the label and doing
> ROOTPART=`findmnt -n --output=source /boot/firmware/`;
> ROOTLABEL="`lsblk -no label $ROOTPART`", and when overwriting
> cmdline.txt using "root=LABEL=$ROOTLABEL", 3) or my personal favorite
> - not touching cmdline.txt at all. I don't really see the point of
> modifying it during postinst of a kernel package, unless the
> pre_cmdline stuff needs to modify console boot settings for some
> reason. So that's surely an issue to look into ASAP! (and yes, the bug
> is not getting any younger :-| )

Bug#966631: tab-in-license-text: replaces tabs with spaces+tabs in some cases

[Jelmer Vernooij]

Package: lintian-brush
Version: 0.74
Severity: normal
X-Debbugs-Cc: m...@debian.org

See 
https://salsa.debian.org/3dprinting-team/arduino-mighty-1284p/-/merge_requests/1?commit_id=2ab658ba14414481f2044a0132585c5e72adae62

lintian-brush currently just cares about the first character, which in
some cases leads to all lines starting with a space and a tab.

If there is a consistent indentaton that's used elsewhere in the copyright
file, lintian-brush should stick to that (some copyright files only have
a single line that starts with a tab).

Otherwise, like Christoph mentions, lintian-brush will need to
pick a style.

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

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

Versions of packages lintian-brush depends on:
ii  devscripts   2.20.4
ii  python3  3.8.2-3
ii  python3-breezy   3.1.0-5
ii  python3-debian   0.1.37
ii  python3-debmutate0.4
ii  python3-distro-info  0.23
ii  python3-dulwich  0.20.2-1
ii  python3-iniparse 0.4-3
ii  python3-ruamel.yaml  0.16.10-2

Versions of packages lintian-brush recommends:
ii  decopy   0.2.4.3-0.1
ii  dos2unix 7.4.1-1
ii  gpg  2.2.20-1
ii  libdebhelper-perl13.2
ii  lintian  2.85.0
ii  python3-asyncpg  0.20.1-1+b1
ii  python3-bs4  4.9.1-1
ii  python3-levenshtein  0.12.0-5+b1
ii  python3-pyinotify0.9.6-1.3
ii  python3-toml 0.10.1-1

Versions of packages lintian-brush suggests:
pn  gnome-pkg-tools
ii  postgresql-common  215

-- no debconf information

Bug#965225: bash-completion: dh_bash-completion at debhelper-compat (= 13) chokes on "${foo}" in proper snippet

[Gabriel F. T. Gomes]

On Fri, 31 Jul 2020, Sergio Durigan Junior wrote:
>
> Yeah, the list is large, indeed.  I guess we'll find out whether this
> breaks something or not when it reaches unstable and starts to be used
> :-).

And if it breaks *before* people update debhelper's compat level, then
we know we broke it backwards, hehehe. I believe we haven't. :)


> > May I set git commit authorship to
> > "Sergio Durigan Junior " ?  
> 
> Sure thing!  Feel free to mention in the d/changelog entry as well.

Done. :)
https://salsa.debian.org/debian/bash-completion/-/commit/9230db41952b8cf95e3b814455c7f268d485829a


I'm no Queen, but I now make you the Earl of Perl! :)
Thank you very much.

Bug#966630: claws-mail: CVE-2020-16094

[Salvatore Bonaccorso]

Source: claws-mail
Version: 3.17.6-1
Severity: important
Tags: security upstream
Forwarded: 
https://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=4313
X-Debbugs-Cc: Debian Security Team 

Hi,

The following vulnerability was published for claws-mail.

CVE-2020-16094[0]:
| In imap_scan_tree_recursive in Claws Mail through 3.17.6, a malicious
| IMAP server can trigger stack consumption because of unlimited
| recursion into subdirectories during a rebuild of the folder tree.


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-2020-16094
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-16094
[1] https://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=4313

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#966518: build: hook up traditional dbus activation

[Andreas Henriksson]

On systems using systemd dbus will use the SystemdServices= directive,
but on non-systemd systems the so called "traditional dbus activation"
method involves reading the Exec= directive. Setting that to /bin/false
means this service is not relevant on non-systemd systems, but
apparently there's an interest from users of such systems to use
iwd (and possibly ead). Thus hook up the expansion of the paths in the
Exec= directive of the dbus service files to allow the traditional dbus
activation to start respective daemon.

Signed-off-by: Andreas Henriksson 
---
 Makefile.am  | 11 ++-
 src/net.connman.iwd.service  |  5 -
 src/net.connman.iwd.service.in   |  5 +
 wired/net.connman.ead.service|  5 -
 wired/net.connman.ead.service.in |  5 +
 5 files changed, 16 insertions(+), 15 deletions(-)
 delete mode 100644 src/net.connman.iwd.service
 create mode 100644 src/net.connman.iwd.service.in
 delete mode 100644 wired/net.connman.ead.service
 create mode 100644 wired/net.connman.ead.service.in

diff --git a/Makefile.am b/Makefile.am
index 57c694d..006d1d1 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -250,7 +250,7 @@ dist_dbus_data_DATA += src/iwd-dbus.conf
 endif
 
 if SYSTEMD_SERVICE
-src_iwd_DEPENDENCIES += src/iwd.service
+src_iwd_DEPENDENCIES += src/iwd.service src/net.connman.iwd.service
 
 systemd_unit_DATA += src/iwd.service
 dbus_bus_DATA += src/net.connman.iwd.service
@@ -328,7 +328,7 @@ dist_dbus_data_DATA += wired/ead-dbus.conf
 endif
 
 if SYSTEMD_SERVICE
-wired_ead_DEPENDENCIES += wired/ead.service
+wired_ead_DEPENDENCIES += wired/ead.service wired/net.connman.ead.service
 
 systemd_unit_DATA += wired/ead.service
 dbus_bus_DATA += wired/net.connman.ead.service
@@ -524,8 +524,8 @@ unit_test_p2p_LDADD = $(ell_ldadd)
 
 TESTS = $(unit_tests)
 
-EXTRA_DIST = src/genbuiltin src/iwd.service.in src/net.connman.iwd.service \
-   wired/ead.service.in wired/net.connman.ead.service \
+EXTRA_DIST = src/genbuiltin src/iwd.service.in src/net.connman.iwd.service.in \
+   wired/ead.service.in wired/net.connman.ead.service.in \
src/80-iwd.link src/pkcs8.conf unit/gencerts.cnf \
$(manual_pages) $(patsubst %.1,%.rst, \
$(patsubst %.5,%.rst, \
@@ -539,7 +539,8 @@ if MAINTAINER_MODE
 AM_CFLAGS += -DHAVE_PKCS8_SUPPORT
 endif
 
-CLEANFILES = src/iwd.service wired/ead.service
+CLEANFILES = src/iwd.service wired/ead.service \
+src/net.connman.iwd.service wired/net.connman.ead.service
 
 DISTCHECK_CONFIGURE_FLAGS = --disable-dbus-policy --disable-systemd-service \
--enable-sim-hardcoded \
diff --git a/src/net.connman.iwd.service b/src/net.connman.iwd.service
deleted file mode 100644
index d8ece4c..000
--- a/src/net.connman.iwd.service
+++ /dev/null
@@ -1,5 +0,0 @@
-[D-BUS Service]
-Name=net.connman.iwd
-Exec=/bin/false
-User=root
-SystemdService=iwd.service
diff --git a/src/net.connman.iwd.service.in b/src/net.connman.iwd.service.in
new file mode 100644
index 000..a7cb7ed
--- /dev/null
+++ b/src/net.connman.iwd.service.in
@@ -0,0 +1,5 @@
+[D-BUS Service]
+Name=net.connman.iwd
+Exec=@libexecdir@/iwd
+User=root
+SystemdService=iwd.service
diff --git a/wired/net.connman.ead.service b/wired/net.connman.ead.service
deleted file mode 100644
index 24af96b..000
--- a/wired/net.connman.ead.service
+++ /dev/null
@@ -1,5 +0,0 @@
-[D-BUS Service]
-Name=net.connman.ead
-Exec=/bin/false
-User=root
-SystemdService=ead.service
diff --git a/wired/net.connman.ead.service.in b/wired/net.connman.ead.service.in
new file mode 100644
index 000..63e5011
--- /dev/null
+++ b/wired/net.connman.ead.service.in
@@ -0,0 +1,5 @@
+[D-BUS Service]
+Name=net.connman.ead
+Exec=@libexecdir@/ead
+User=root
+SystemdService=ead.service

Bug#966629: RFS: spyne/2.13.15-1 [ITA] -- Python library for writing and calling soap web service

[Bastian Germann]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: spyne
   Version : 2.13.15-1
   Upstream Author : Burak Arslan 
 * URL : http://spyne.io/
 * License : LGPL-2.1+
 * Vcs : https://salsa.debian.org/python-team/modules/spyne
   Section : python

It builds those binary packages:

  python3-spyne - Python library for writing and calling soap web service

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/s/spyne/spyne_2.13.15-1.dsc

Changes since the last upload:

 spyne (2.13.15-1) unstable; urgency=medium
 .
   * Add gbp configuration
   * New maintainer (Closes: #966603)
   * Add Debian CI
   * Set Vcs fields
   * Fix wildcard-matches-nothing-in-dep5-copyright

Regards,
Bastian

Bug#957403: kexec-tools: diff for NMU version 1:2.0.20-2.1

[cascardo]

Control: tags 957403 + patch


Dear maintainer,

I've prepared an NMU for kexec-tools (versioned as 1:2.0.20-2.1). The diff
is attached to this message.

Regards.

diff -Nru kexec-tools-2.0.20/debian/changelog kexec-tools-2.0.20/debian/changelog
--- kexec-tools-2.0.20/debian/changelog	2020-03-12 16:31:02.0 -0300
+++ kexec-tools-2.0.20/debian/changelog	2020-07-31 14:27:55.0 -0300
@@ -1,3 +1,10 @@
+kexec-tools (1:2.0.20-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix build with GCC 10 (Closes: #957403)
+
+ -- Thadeu Lima de Souza Cascardo   Fri, 31 Jul 2020 14:27:55 -0300
+
 kexec-tools (1:2.0.20-2) unstable; urgency=medium
 
   * Fix FTBFS issue on x86 (Closes: #942617)
diff -Nru kexec-tools-2.0.20/debian/patches/kexec-tools-remove-duplicated-variable-d.patch kexec-tools-2.0.20/debian/patches/kexec-tools-remove-duplicated-variable-d.patch
--- kexec-tools-2.0.20/debian/patches/kexec-tools-remove-duplicated-variable-d.patch	1969-12-31 21:00:00.0 -0300
+++ kexec-tools-2.0.20/debian/patches/kexec-tools-remove-duplicated-variable-d.patch	2020-07-31 14:27:36.0 -0300
@@ -0,0 +1,86 @@
+From: Kairui Song 
+Date: Wed, 29 Jan 2020 13:38:19 +0800
+X-Dgit-Generated: 1:2.0.20-2.1 2bf3cc958fc767a2868b5766a3b6ac73da019ef3
+Subject: kexec-tools: Remove duplicated variable declarations
+
+When building kexec-tools for Fedora 32, following error is observed:
+
+/usr/bin/ld: kexec/arch/x86_64/kexec-bzImage64.o:(.bss+0x0): multiple definition of `bzImage_support_efi_boot';
+kexec/arch/i386/kexec-bzImage.o:(.bss+0x0): first defined here
+
+/builddir/build/BUILD/kexec-tools-2.0.20/kexec/arch/arm/../../fs2dt.h:33: multiple definition of `my_debug';
+kexec/fs2dt.o:/builddir/build/BUILD/kexec-tools-2.0.20/kexec/fs2dt.h:33: first defined here
+
+/builddir/build/BUILD/kexec-tools-2.0.20/kexec/arch/arm64/kexec-arm64.h:68: multiple definition of `arm64_mem';
+kexec/fs2dt.o:/builddir/build/BUILD/kexec-tools-2.0.20/././kexec/arch/arm64/kexec-arm64.h:68: first defined here
+
+/builddir/build/BUILD/kexec-tools-2.0.20/kexec/arch/arm64/kexec-arm64.h:54: multiple definition of `initrd_size';
+kexec/fs2dt.o:/builddir/build/BUILD/kexec-tools-2.0.20/././kexec/arch/arm64/kexec-arm64.h:54: first defined here
+
+/builddir/build/BUILD/kexec-tools-2.0.20/kexec/arch/arm64/kexec-arm64.h:53: multiple definition of `initrd_base';
+kexec/fs2dt.o:/builddir/build/BUILD/kexec-tools-2.0.20/././kexec/arch/arm64/kexec-arm64.h:53: first defined here
+
+And apparently, these variables are wrongly declared multiple times. So
+remove duplicated declaration.
+
+Signed-off-by: Kairui Song 
+Signed-off-by: Simon Horman 
+(cherry picked from commit cc087b11462af9f971a2c090d07e8d780a867b50)
+Signed-off-by: Thadeu Lima de Souza Cascardo 
+
+---
+
+--- kexec-tools-2.0.20.orig/kexec/arch/arm64/kexec-arm64.h
 kexec-tools-2.0.20/kexec/arch/arm64/kexec-arm64.h
+@@ -50,8 +50,8 @@ int zImage_arm64_load(int argc, char **a
+ void zImage_arm64_usage(void);
+ 
+ 
+-off_t initrd_base;
+-off_t initrd_size;
++extern off_t initrd_base;
++extern off_t initrd_size;
+ 
+ /**
+  * struct arm64_mem - Memory layout info.
+@@ -65,7 +65,7 @@ struct arm64_mem {
+ };
+ 
+ #define arm64_mem_ngv UINT64_MAX
+-struct arm64_mem arm64_mem;
++extern struct arm64_mem arm64_mem;
+ 
+ uint64_t get_phys_offset(void);
+ uint64_t get_vp_offset(void);
+--- kexec-tools-2.0.20.orig/kexec/arch/ppc64/kexec-elf-ppc64.c
 kexec-tools-2.0.20/kexec/arch/ppc64/kexec-elf-ppc64.c
+@@ -44,8 +44,6 @@
+ uint64_t initrd_base, initrd_size;
+ unsigned char reuse_initrd = 0;
+ const char *ramdisk;
+-/* Used for enabling printing message from purgatory code */
+-int my_debug = 0;
+ 
+ int elf_ppc64_probe(const char *buf, off_t len)
+ {
+--- kexec-tools-2.0.20.orig/kexec/arch/x86_64/kexec-bzImage64.c
 kexec-tools-2.0.20/kexec/arch/x86_64/kexec-bzImage64.c
+@@ -42,7 +42,6 @@
+ #include 
+ 
+ static const int probe_debug = 0;
+-int bzImage_support_efi_boot;
+ 
+ int bzImage64_probe(const char *buf, off_t len)
+ {
+--- kexec-tools-2.0.20.orig/kexec/fs2dt.h
 kexec-tools-2.0.20/kexec/fs2dt.h
+@@ -30,7 +30,7 @@ extern struct bootblock bb[1];
+ 
+ /* Used for enabling printing message from purgatory code
+  * Only has implemented for PPC64 */
+-int my_debug;
++extern int my_debug;
+ extern int dt_no_old_root;
+ 
+ void reserve(unsigned long long where, unsigned long long length);
diff -Nru kexec-tools-2.0.20/debian/patches/series kexec-tools-2.0.20/debian/patches/series
--- kexec-tools-2.0.20/debian/patches/series	2020-03-12 16:31:02.0 -0300
+++ kexec-tools-2.0.20/debian/patches/series	2020-07-31 14:27:36.0 -0300
@@ -6,3 +6,4 @@
 linker-option.patch
 powerpcspe_support.patch
 ftbfs-i386.patch
+kexec-tools-remove-duplicated-variable-d.patch


signature.asc
Description: PGP signature

Bug#966628: slick-greeter: please default draw-grid to true (or some other eyecandy)

[Adam Borowski]

Package: slick-greeter
Version: 1.3.2+dfsg.1-2
Severity: wishlist


Hi!
Perhaps this is just a minor aesthetic thing, but as most people don't
touch defaults, their installations end up ugly.

On stock Debian install, slick-greeter has a small login window on the
middle left, a bar at the top, while the entire rest of the screen is
blank.  On Buster and below, the blank part included a subtle pixel grid,
while on Bullseye it's solid black.  The former was simple but
good-looking, while the latter appears so bare and unfinished that it
makes people wonder if the greeter fully loaded.

I for one felt only an aesthetic regression (a matter of taste), but
someone else looking at my screen just insinuated that the greeter is
corrupted somehow.  And it indeed looks that way...


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

Kernel: Linux 5.8.0-rc7-00065-g232f90a1c119 (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages slick-greeter depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-2
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libcanberra0 0.30-7
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
ii  libglib2.0-0 2.64.4-1
ii  libgtk-3-0   3.24.20-1
ii  liblightdm-gobject-1-0   1.26.0-7
ii  libpango-1.0-0   1.44.7-4
ii  libpangocairo-1.0-0  1.44.7-4
ii  libx11-6 2:1.6.9-2+b1
ii  libxext6 2:1.3.3-1+b2
ii  lightdm  1.26.0-7
ii  python3  3.8.2-3
ii  python3-gi   3.36.0-4

slick-greeter recommends no packages.

slick-greeter suggests no packages.

-- no debconf information

Bug#965225: bash-completion: dh_bash-completion at debhelper-compat (= 13) chokes on "${foo}" in proper snippet

[Sergio Durigan Junior]

On Friday, July 31 2020, Gabriel F. T. Gomes wrote:

> Hi, Sergio,
>
> <3 S2 <3 S2

:-D

> On Thu, 30 Jul 2020, Sergio Durigan Junior wrote:
>> 
>> So, here's the thing.  We can't blindly rely on debhelper's
>> filedoublearray anymore, because of the problem you guys pointed out
>> above.  Which means that bash-completion will probably have to have its
>> own stripped-down, poor-man's version of filedoublearray.  Actually,
>> given the way dh_bash-completion works, it should be enough to have a
>> function that tries to determine whether the file being examined is (a)
>> a bash-completion script, or (b) a file-list.  If (a), then the file
>> itself should be installed.  If (b), then we install each file listed in
>> it.
>
> I really like this approach. It lets filedoublearray be free to do
> whatever it wants, while still working for bash-completion on the file
> list case.

Yep, that's the idea.  Avoid calling filedoublearray if we already know
what we're dealing with.

>> In order to hack this new function I used a little bit of what
>> filedoublearray does in the beginning, and then I crafted a few regexes
>> that will perform a "heuristic" to see if we catch some well-known bash
>> constructions in the file.  If we succeed, then just assume that the
>> file is a bash-completion script and be done with it.  Otherwise, it's
>> (probably) a file-list.
>
> I like the heuristic you came up with; it should be enough to cover all
> completion files I have seen so far and it is so well-documented that
> it should be easy to fix if problems show up.

Cool!  I wasn't sure if you'd like it; it's a bit hacky ;-).  But yeah,
I tried to be careful with the comments because I know that there's a
chance that the function might need to be expanded in order to
accomodate other cases.

>> As far as I have tested, everything works OK.  Of course, this is a
>> heuristic approach and it is possible to craft a problematic file that
>> will cause an error, but it's better than what we have now, IMHO.
>
> +1
>
> I have tested a couple of reverse-build-dependencies of
> bash-completion. Most of them use file lists and the patched debhelper
> script works as before when compat level is updated to 13. I also found
> one package that has a proper completion snippet (pidcat), which also
> works correctly with the patched debhelper script and debhelper 13.
>
> I haven't tested all reverse build dependencies, though. The list is
> too large.

Yeah, the list is large, indeed.  I guess we'll find out whether this
breaks something or not when it reaches unstable and starts to be used
:-).

>> Hopefully this will help.  I'm not tagging this as "+patch" because I'd
>> like to hear your opinions first.
>
> Now tagged.
>
> I'll incorporate this change to the repository, do a little more testing,
> then upload to unstable. May I set git commit authorship to
> "Sergio Durigan Junior " ?

Sure thing!  Feel free to mention in the d/changelog entry as well.

Thanks :-).

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


signature.asc
Description: PGP signature

Bug#966544: snmpd: extend option broken after update

[Felix Sperling]

Hi,

we were also effected from the update 5.7.3+dfsg-1.7+deb9u2 causing lots 
of broken icinga checks.


Our workaround is pinning 5.7.3+dfsg-1.7+deb9u1.

What's unclear from the solution if 5.8 also will be available in 
stretch and buster which we need. Otherwise it would be great to enable 
extend in 5.7.3 for those versions.


Cheers,
Felix


--
Felix Sperling
System Engineer
Team SRE

idealo internet GmbH
Ritterstraße 11
10969 Berlin, Deutschland

Bug#966451: cloud.debian.org: systemd-growfs@-.service fails on arm64 instance types

[Noah Meyerhans]

Our daily image builds include this fix as of yesterday.  I've confirmed
that it resolves the issue there.

I'll close this bug once we've published "release" images containing the
fix, which should occur with the buster update scheduled for this
weekend.

noah

Bug#965225: bash-completion: dh_bash-completion at debhelper-compat (= 13) chokes on "${foo}" in proper snippet

[Gabriel F. T. Gomes]

Control: tags -1 + patch

Hi, Sergio,

<3 S2 <3 S2

On Thu, 30 Jul 2020, Sergio Durigan Junior wrote:
> 
> So, here's the thing.  We can't blindly rely on debhelper's
> filedoublearray anymore, because of the problem you guys pointed out
> above.  Which means that bash-completion will probably have to have its
> own stripped-down, poor-man's version of filedoublearray.  Actually,
> given the way dh_bash-completion works, it should be enough to have a
> function that tries to determine whether the file being examined is (a)
> a bash-completion script, or (b) a file-list.  If (a), then the file
> itself should be installed.  If (b), then we install each file listed in
> it.

I really like this approach. It lets filedoublearray be free to do
whatever it wants, while still working for bash-completion on the file
list case.

> In order to hack this new function I used a little bit of what
> filedoublearray does in the beginning, and then I crafted a few regexes
> that will perform a "heuristic" to see if we catch some well-known bash
> constructions in the file.  If we succeed, then just assume that the
> file is a bash-completion script and be done with it.  Otherwise, it's
> (probably) a file-list.

I like the heuristic you came up with; it should be enough to cover all
completion files I have seen so far and it is so well-documented that
it should be easy to fix if problems show up.

> Now, in order to test this approach, here's what I did (inside a schroot
> session):
> 
> - Go to sources.d.o, look for all the packages that depend on
>   bash-completion.
> 
> - Download the list, iterate over it and do an "apt source" on all of
>   them.
> 
> - Check for a few interesting cases in this list.  Examples I could find
>   are: consul, cargo, caffe, 2ping, xkcdpass, virtualenvwrapper.
> 
> - Enter their directories and perform a "dh_bash-completion -v".

Thanks for being so careful about testing and for sharing the steps
with us. I'll adopt it for my workflows.

> As far as I have tested, everything works OK.  Of course, this is a
> heuristic approach and it is possible to craft a problematic file that
> will cause an error, but it's better than what we have now, IMHO.

+1

I have tested a couple of reverse-build-dependencies of
bash-completion. Most of them use file lists and the patched debhelper
script works as before when compat level is updated to 13. I also found
one package that has a proper completion snippet (pidcat), which also
works correctly with the patched debhelper script and debhelper 13.

I haven't tested all reverse build dependencies, though. The list is
too large.

> BTW: while I was hacking I had another idea, which is to use a
> try...catch block around filedoublearray and see if it "throws" anything
> like ".*cannot resolve variable.*", but that doesn't really work: if the
> error is triggered, it might mean that we're dealing with a
> bash-completion script, *but* it might also mean that the file-list file
> is broken (e.g., referencing a wrong or non-existent variable), which
> means that we would need to perform some kind of parsing to determine
> what's really happening anyway (assuming that we want to do a good job
> at detecting the error).

thanks for sharing. :)

> Hopefully this will help.  I'm not tagging this as "+patch" because I'd
> like to hear your opinions first.

Now tagged.

I'll incorporate this change to the repository, do a little more testing,
then upload to unstable. May I set git commit authorship to
"Sergio Durigan Junior " ?


Cheers,
Gabriel

Bug#966627: git-buildpackage: "gbp pull" ambiguous refname

[Antoni Villalonga]

Package: git-buildpackage
Version: 0.9.20
Severity: normal
X-Debbugs-Cc: ant...@friki.cat

Dear Maintainer,

I got a non-working situation while using routine-update package.
After tracing down the problem, I've found it's related to 'gbp pull'.

Please, take a look at this example session that reproduces the problem.
  "warning: refname 'master' is ambiguous."

 | % git init foo
 | Initialized empty Git repository in /tmp/foo/.git/
 | % pushd foo
 | % echo HELLO WORLD > README
 | % git add README
 | % git commit -m "Init"
 | [master (root-commit) 69e36c7] Init
 |  1 file changed, 1 insertion(+)
 |  create mode 100644 README
 | % popd
 | % git clone foo bar
 | Cloning into 'bar'...
 | done.
 | % pushd bar
 | % git remote rename origin master
 | % gbp pull --verbose
 | gbp:info: Fetching from default remote for each branch
 | gbp:debug: ['git', 'rev-parse', '--show-cdup']
 | gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
 | gbp:debug: ['git', 'rev-parse', '--git-dir']
 | gbp:debug: ['git', 'symbolic-ref', 'HEAD']
 | gbp:debug: ['git', 'show-ref', 'refs/heads/master']
 | gbp:debug: ['git', 'status', '--porcelain']
 | gbp:debug: ['git', 'fetch', '--quiet']
 | gbp:debug: ['git', 'fetch', '--quiet', '--tags']
 | gbp:debug: ['git', 'config', 'branch.master.remote']
 | gbp:debug: ['git', 'config', 'branch.master.merge']
 | gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/master']
 | gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream']
 | gbp:debug: ['git', 'config', 'branch.master.remote']
 | gbp:debug: ['git', 'config', 'branch.master.merge']
 | gbp:debug: ['git', 'rev-list', '--left-right', 'master...master/master', 
'--']
 | warning: refname 'master' is ambiguous.
 | gbp:info: Branch 'master' is already up to date.
 | gbp:debug: ['git', 'symbolic-ref', 'HEAD']
 | gbp:debug: ['git', 'show-ref', 'refs/heads/master']

I've fixed localy adding 'refs/heads/' to from_branch.

 | --- a/usr/lib/python3/dist-packages/gbp/git/repository.py
 | +++ b/usr/lib/python3/dist-packages/gbp/git/repository.py
 | @@ -509,7 +509,7 @@ class GitRepository(object):
 |  has_remote = False  # remote repo has new commits
 |  out = self._git_getoutput('rev-list',
 |["--left-right",
 | -   "%s...%s" % (from_branch, to_branch),
 | +   "%s...%s" % ('refs/heads/' + 
from_branch, to_branch),
 | "--"])[0]
 | 
 |  if not out:  # both branches have the same commits

By now I've didn't noticed bad side effects.

Regards,

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

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

Versions of packages git-buildpackage depends on:
ii  devscripts 2.20.4
ii  git1:2.28.0-1
ii  man-db 2.9.3-2
ii  python33.8.2-3
ii  python3-dateutil   2.8.1-4
ii  python3-pkg-resources  46.1.3-1
ii  sensible-utils 0.0.12+nmu1

Versions of packages git-buildpackage recommends:
ii  cowbuilder0.88
ii  pbuilder  0.230.4
ii  pristine-tar  1.48+salsaci
ii  python3-requests  2.23.0+dfsg-2

Versions of packages git-buildpackage suggests:
ii  python3-notify2  0.3-4
ii  sudo 1.9.1-2
ii  unzip6.0-25

-- no debconf information

Bug#966575: I was affected as well

[Norbert Kiesel]

Yes. I used the boot-repair.iso and that did the trick.  Luckily, I still
had an old Chromebook which allowed me to create the USB.

On Fri, Jul 31, 2020 at 6:25 AM Steve McIntyre <93...@debian.org> wrote:

> Hi Norbert,
>
> On Thu, Jul 30, 2020 at 11:26:15PM -0700, Norbert Kiesel wrote:
> >This is a laptop running Debain Unstable with 2 SSD and one spinning
> disk.
> >After upgrade and install, system stopped with same error message during
> boot.
> >
> >I was able to reactivate using a live boot system.
>
> ACK. Same thing applies as I suggested to Paul - maybe an inconsistent
> set of updates. Have you *fixed* the problem by using the live boot?
>
> --
> Steve McIntyre, Cambridge, UK.
> st...@einval.com
> There's no sensation to compare with this
> Suspended animation, A state of bliss
>
>

Bug#964915: raspi-firmware: upgrading kernel or firmware causes system to become unbootable on pi 4

[Gunnar Wolf]

tags 4964915 + confirmed
notfound 4964915 1.20190215-1+deb10u4
severity 4964915 critical
thanks

I am bumping up this bug to critical, as it «makes unrelated software
on the system (or the whole system) break» - Rendering a computer
unbootable is a critical bug in my book!

This bug does not affect the stable version of the firmware; I know
the control server will probably bark at me because there was a
package rename (and 1.20190215-1+deb10u4 belongs to raspi3-firmware),
but this still serves as documentation: This is the only reason why
the Raspberry images for families ≤ 3 do not break, while for RPi4
does. However, anybody installing a RPi on their own or upgrading to
unstable will be affected by this bug.

Also, to have things together in one place - Thanks to basti for
pointing out¹ the bug can be triggered (and easily tested) by running:

update-initramfs -u -k all


¹ https://lists.debian.org/debian-arm/2020/07/msg00021.html

Bug#964915: Raspi 4 debian image update-initramfs

[Gunnar Wolf]

[ Adding a Cc: to #964915 ]

Lucas Nussbaum dijo [Fri, Jul 31, 2020 at 02:15:29PM +0200]:
> Hi,
> 
> Can you confirm that it's not
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964915

Yes, that's precisely the culprit.

Even more - Both basti and me didn't find it any further because (I
guess) we both booted with the HDMI console. When using a serial
console, I found the all too familiar:

Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.

And of course, after a couple iterations, I got dumped to the very useful 
busybox:

Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
done.
Gave up waiting for root file system device.  Common problems:
 - Boot args (cat /proc/cmdline)
 - Check rootdelay= (did the system wait long enough?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  /dev/mmcblk0p2 does not exist.  Dropping to a shell!

BusyBox v1.30.1 (Debian 1:1.30.1-4) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs)

So, Basti:

1. Try editing cmdline.txt in your first partition, replacing
   «/dev/mmcblk0p2» by «LABEL=RASPIROOT» as the bug report suggests

2. If you don't use a serial console, consider removing the
   «console=ttyS1,115200» part, so that the main information is sent
   to the HDMI output. Or even better, swap the order, so that the
   serial console functionality is preserved, but the main console is
   HDMI.

So, we should definitively address item 1, as it is a serious bug (and
I'm bumping up severity - It will affect all Raspberry models, not
just the 4).

As for 2... well, we can document it and maybe add some black magic to
the initrd generation to allow the user to specify what the default
console should be. But as the preferences are completely depending on
the user and there is no "righter" value...

And, following Lucas' report -- I think his last point actually makes
a lot of sense:

1) setting ROOTPART=`findmnt -n --output=source /boot/firmware/`,
2) or using the label and doing ROOTPART=`findmnt -n
   --output=source /boot/firmware/`; ROOTLABEL="`lsblk -no label
   $ROOTPART`", and when overwriting cmdline.txt using
   "root=LABEL=$ROOTLABEL",
3) or my personal favorite - not touching cmdline.txt at all. I
   don't really see the point of modifying it during postinst of a
   kernel package, unless the pre_cmdline stuff needs to modify
   console boot settings for some reason.

So that's surely an issue to look into ASAP! (and yes, the bug is not
getting any younger :-| )

Bug#966625: gabedit crashes as soon as one opens the molecular editor

[fulvio ciriaco]

Package: gabedit
Version: 2.5.0-1
Severity: grave
Tags: upstream
Justification: renders package unusable



dear maintainer,
gabedit crashes, backtrace reports halting in libpangox.
the problem might be related to gtkglext1, recently dropping
function gdk_gl_font_use_pango_font for gl text rendering.
In fact, I have recently had a working version from upstream,
but I don't know when it will become official.

yours
Fulvio Ciriaco

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

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

Versions of packages gabedit depends on:
ii  libc6   2.31-2
ii  libcairo2   1.16.0-4
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-5
ii  libgl1  1.3.1-1
ii  libgl2ps1.4 1.4.2+dfsg1-1
ii  libglib2.0-02.64.4-1
ii  libglu1-mesa [libglu1]  9.0.1-1
ii  libgomp110.1.0-6
ii  libgtk2.0-0 2.24.32-4
ii  libgtkglext11.2.0-9
ii  libpango-1.0-0  1.44.7-4
ii  libpangocairo-1.0-0 1.44.7-4
ii  openbabel   3.1.1+dfsg-3

Versions of packages gabedit recommends:
pn  mpqc  

Versions of packages gabedit suggests:
pn  a2ps 
ii  cups-bsd [lpr]   2.3.3-1
pn  ftp-ssl | ftp
ii  openssh-client [ssh-client]  1:8.3p1-1

-- no debconf information

Bug#966624: please build firmware for qemu ppc e500 machine

[Michael Tokarev]

Source: u-boot
Severity: minor

qemu powerpc machine emulation uses u-boot for booting,
and this firmware image is currently missing.  Please
provide a package containing such firmware.

Here's how it is built within qemu sources (where u-boot
is present as a submodule):

u-boot.e500:
$(MAKE) -C u-boot O=build.e500 qemu-ppce500_config
$(MAKE) -C u-boot CROSS_COMPILE=$(powerpc_cross_prefix) \
O=build.e500
$(powerpc_cross_prefix)strip u-boot/build.e500/u-boot -o \
../pc-bios/u-boot.e500

qemu expects this image to be found as /usr/share/qemu/u-boot.e500
(this is the directory where all other images are located).

I dunno what's the name to suggest for this package, since
u-boot-qemu is already taken and it provides different images,
not directly used by qemu.  Maybe qemu-uboot or something, dunno.

There's a bug open in the Debian BTS about this, #756833 , - open
for a long time already.  The difference from this #756833 context
is that now, powerpc cross-compiler is available and can be used
for build-dependencies.

I can build this firmware directly from the qemu sources (which
includes roms/u-boot), and qemu already uses powerpc cross-gcc
to build other things, but this is something to avoid in Debian.

Thanks,

/mjt

Bug#966525: dmagnetic FTBFS on i386: check-sixel failed

[Thomas Dettbarn]

Hello Adrian.

So, I patched my package, and uploaded to mentors.

I got a message with the subject "dmagnetic_0.25-1:
ACCEPTED into unstable."

It can be found here,

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


but now I am a little bit concerned about the developer information
page: https://tracker.debian.org/pkg/dmagnetic it is still complaining
about i386 not working. Could you have a look?



Thomas


On 7/30/20 4:29 PM, Adrian Bunk wrote:

On Thu, Jul 30, 2020 at 03:47:49PM +0200, Thomas Dettbarn wrote:

...
One last thing... Why did your patch say "ifneq... i386"?

ifneq (,$(filter $(DEB_HOST_ARCH), i386))
^
This compares the empty string with the filter result.

ifeq ($(DEB_HOST_ARCH), i386)
would to the same in this case.

I am used to the filter way of writing it since it allows listing
several architectures like
ifneq (,$(filter $(DEB_HOST_ARCH), i386 mipsel hppa))


Thomas

cu
Adrian

Bug#966623: Please warn if User=nobody is used in service files

[Michael Biebl]

Package: lintian
Version: 2.85.0
Severity: wishlist
X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org

Hi,

according to [1], there are quite a few packages which use 
User=nobody (and Group=nogroup).

This is discouraged, and systemd v246 will now log a warning about this.
See https://github.com/systemd/systemd/blob/master/NEWS#L106
for the reasoning:

```
* If the service setting User= is set to the "nobody" user, a warning
  message is now written to the logs (but the value is nonetheless
  accepted). Setting User=nobody is unsafe, since the primary purpose
  of the "nobody" user is to own all files whose owner cannot be mapped
  locally. It's in particular used by the NFS subsystem and in user
  namespacing. By running a service under this user's UID it might get
  read and even write access to all these otherwise unmappable files,
  which is quite likely a major security problem.
```

It's preferrable to create a dedicated system user (and group) for
individual services, to not get accidental access for stuff they are not
supposed to be able to access.

For some services, DynamicUser=true might be an option. This would
alleviate the need for manually creating a system user.
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#DynamicUser=

Regards,
Michael


[1] https://codesearch.debian.net/search?q=User%3Dnobody=1=1


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

Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 lintian depends on:
ii  binutils  2.35-1
ii  bzip2 1.0.8-4
ii  diffstat  1.63-1
ii  dpkg  1.20.5
ii  dpkg-dev  1.20.5
ii  file  1:5.38-5
ii  gettext   0.19.8.1-10
ii  gpg   2.2.20-1
ii  intltool-debian   0.35.0+20060710.5
ii  libapt-pkg-perl   0.1.36+b3
ii  libarchive-zip-perl   1.68-1
ii  libcapture-tiny-perl  0.48-1
ii  libclass-xsaccessor-perl  1.19-3+b5
ii  libclone-perl 0.45-1
ii  libconfig-tiny-perl   2.24-1
ii  libcpanel-json-xs-perl4.19-1
ii  libdata-dpath-perl0.58-1
ii  libdata-validate-domain-perl  0.10-1
ii  libdevel-size-perl0.83-1+b1
ii  libdigest-sha-perl6.02-1+b2
ii  libdpkg-perl  1.20.5
ii  libemail-address-xs-perl  1.04-1+b2
ii  libfile-basedir-perl  0.08-1
ii  libfile-find-rule-perl0.34-1
ii  libfont-ttf-perl  1.06-1
ii  libhtml-parser-perl   3.72-5
ii  libio-async-loop-epoll-perl   0.21-1
ii  libio-async-perl  0.77-3
ii  libjson-maybexs-perl  1.004002-1
ii  liblist-compare-perl  0.53-1
ii  liblist-moreutils-perl0.416-1+b5
ii  liblist-utilsby-perl  0.11-1
ii  libmoo-perl   2.004000-1
ii  libmoox-aliases-perl  0.001006-1
ii  libnamespace-clean-perl   0.27-1
ii  libpath-tiny-perl 0.114-1
ii  libsereal-decoder-perl4.017+ds-1
ii  libsereal-encoder-perl4.017+ds-1
ii  libtext-levenshteinxs-perl0.03-4+b7
ii  libtext-xslate-perl   3.5.8-1
ii  libtime-duration-perl 1.21-1
ii  libtime-moment-perl   0.44-1+b2
ii  libtimedate-perl  2.3300-1
ii  libtry-tiny-perl  0.30-1
ii  libtype-tiny-perl 1.010002-1
ii  libunicode-utf8-perl  0.62-1+b1
ii  liburi-perl   1.76-2
ii  libxml-libxml-perl2.0134+dfsg-2
ii  libxml-writer-perl0.625-1
ii  libyaml-libyaml-perl  0.82+repack-1
ii  man-db2.9.3-2
ii  patchutils0.4.2-1
ii  perl [libdigest-sha-perl] 5.30.3-4
ii  t1utils   1.41-4
ii  xz-utils  5.2.4-1+b1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b6

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.59-1

-- no debconf information

Bug#966621: systemd: tmpfiles.d not cleaning /var/tmp by default

[Michael Biebl]

Am 31.07.20 um 17:12 schrieb Eric Desrochers:
> Package: systemd
> Version: 245.7-1
> Severity: normal
> 
> Dear Maintainer,
> 
> Debian systemd implementation does not clean
> /var/tmp by default.
> 
> * quilt patch:
> d/p/debian/Bring-tmpfiles.d-tmp.conf-in-line-with-Debian-defaul.patch
> 
> * systemd-245.7/tmpfiles.d/tmp.conf:
> #q /var/tmp 1777 root root 30d
> 
> The patch exist in Debian since 2012.
> 
> The topic has been discussed and a few suggestion has been put on the
> table in the following Ubuntu bug: https://launchpad.net/bugs/1870585
> 
> I fill this bug today to start a conversation.

This is deliberate to match the old, pre-systemd behaviour.



signature.asc
Description: OpenPGP digital signature

Bug#966622: general: lock_screen causes blank screen which is onlyresolved with full power off using button

[Sean]

Package: general
Severity: normal

Dear Maintainer,

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

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

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



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

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

Bug#965144: Proposed entry for the bullseye Release Notes

[Brian Potkin]

On Wed 29 Jul 2020 at 20:50:25 +0200, Didier 'OdyX' Raboud wrote:

> Le vendredi, 17 juillet 2020, 13.40:26 h CEST Till Kamppeter a écrit :
> > On 17/07/2020 12:54, Brian Potkin wrote:
> > > I am very much attracted by the idea of a USB connected printer becoming
> > > immediately available when it is plugged in, so a Recommends: ipp-usb
> > > would be ok with me.
> >
> > Yes, I would very much like this, too, for Ubuntu into which both CUPS
> > and ipp-usb get synced.
>
> You might have seen that I uploaded CUPS with a Recommends: ipp-usb in cups-
> daemon.
>
> Le jeudi, 23 juillet 2020, 20.52:47 h CEST Brian Potkin a écrit :
> > On Fri 17 Jul 2020 at 18:21:21 +0100, Brian Potkin wrote:
> > > I have started on planning a revision of the IPP-over-USB content on the
> > > wiki. Much of what you wrote (and I have snipped) is part of the plan's
> > > outline. However, it has helped to focus my mind. Thank you very much for
> > > the input. I hope to have something in place during this coming week.
> >
> > The IPP-over-USB content at
> >
> >   https://wiki.debian.org/CUPSDriverlessPrinting
> >
> > has been revised. There will be changes to it as developments occur. I also
> > intend altering SaneOverNetwork (to be linked to from DriverlessPrinting)
> > to take account of recent driverless scanning initiatives. This will happen
> > when the integration of libsane1 into unstable takes place.
>
> Great; thanks a lot for your continued, consistent and persistent
> documentation work!

I intend to submit the following tomorrow for inclusion in the Debian 11
Release Notes. Please feel free to comment on its accuracy or quality of
expression if necessary.



The Release Notes for Debian 10 briefly described the driverless
printing situation implemented via CUPS and cups-filters. The changes
applied to modern printers connected by ethernet or wireless.

https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#driverless-printing

The release of Debian 11 sees the inclusion of ipp-usb into the stable
archive. ipp-usb is recommended by cups-daemon and utilises the
vendor-neutral IPP-over-USB protocol that is supported by many modern
printers. ipp-usb allows a USB device to be seen and treated as a
network device. The outcome is that driverless printing is extended to
include USB connected printers. The specifics are outlined at

https://wiki.debian.org/CUPSDriverlessPrinting.

The systemd service file included in ipp-usb starts the ipp-usb daemon
when a printer is plugged in, making a USB connected printer available
for printing to, either by being auto-setup by cups-browsed or being
manually installed with a driverless print queue. The use of vendor
printer drivers, free and non-free, becomes unnecessary.



Cheers,

Brian.

Bug#966620: cpufreqd: No turbo mode for Ryzen 4750U

[tkoeck]

Package: cpufreqd
Version: 2.4.2-2.3
Severity: normal

Dear Maintainer,

cpufreqd doesn't seem to work with the new AMD Ryzen 4750U Renoir CPU.
The base clock is just 1.7 all the time.

cpufrequ-info

nalyzing CPU 0:
  driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 4294.55 ms.
  hardware limits: 1.40 GHz - 1.70 GHz
available frequency steps: 1.70 GHz, 1.60 GHz, 1.40 GHz
  available cpufreq governors: userspace, powersave,
  conservative, ondemand, performance, schedutil
current policy: frequency should be within 1.40 GHz and
1.70 GHz.
  The governor "performance" may decide
  which speed to use
within this range
Greetings
Tobias

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

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

Versions of packages cpufreqd depends on:
ii  libc62.31-2
ii  libcpufreq0  008-2
ii  libsensors5  1:3.6.0-2
ii  libsysfs22.1.0+repack-6
ii  lsb-base 11.1.0

Versions of packages cpufreqd recommends:
ii  acpid  1:2.0.32-1

Versions of packages cpufreqd suggests:
ii  cpufrequtils  008-2

-- Configuration Files:
/etc/cpufreqd.conf changed:
[General]
pidfile=/var/run/cpufreqd.pid
poll_interval=2
verbosity=4
[/General]
[Profile]
name=Performance High
minfreq=100%
maxfreq=100%
policy=performance
[/Profile]
[Profile]
name=Performance Low
minfreq=80%
maxfreq=80%
policy=performance
[/Profile]
[Profile]
name=Powersave High
minfreq=60%
maxfreq=60%
::olicy=powersave
[/Profile]
[Profile]
name=Powersave Low
minfreq=40%
maxfreq=40%
policy=powersave
[/Profile]
[Rule]
name=AC Rule
ac=on# (on/off)
profile=Performance High
[/Rule]
 
[Rule]
name=AC Off - High Power
ac=off   # (on/off)
battery_interval=70-100
profile=Performance Low
[/Rule]
[Rule]
name=AC Off - Medium Battery
ac=off   # (on/off)
battery_interval=30-70
profile=Powersave High
[/Rule]
[Rule]
name=AC Off - Low Battery
ac=off   # (on/off)
battery_interval=0-30
profile=Powersave Low
[/Rule]
[Rule]
name=CPU Too Hot
acpi_temperature=55-100
cpu_interval=50-100
profile=Performance Low
[/Rule]
[Rule]
name=Movie Watcher
programs=xine,mplayer,gmplayer
battery_interval=0-100
acpi_temperature=0-60
cpu_interval=0-100
profile=Performance High
[/Rule]

/etc/default/cpufreqd changed:
CPUFREQ_CPU_MODULE="amd_cpufreq"
CPUFREQ_GOV_MODULES="performance"


-- no debconf information

Bug#955469: initramfs-tools-core: Enable zstandard support

[Sedat Dilek]

Just FYI:

Version 10 was now accepted in .

Let's hope this will get into upcoming Linux v5.9.

- Sedat -

[1] https://github.com/terrelln/linux/commits/zstd-v10
[2] https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=x86/boot

Bug#930805: dash: Dash strips out newline from multi-line string literal when line starts with an empty $()

[Jakub Wilk]

Control: tags -1 + fixed-upstream

* Martin D. , 2019-06-20, 19:22:

echo "
$(echo '') hello
$(echo '') world"

will output " hello world", when other shells I've tried
(zsh, bash, ksh) all output:

"
hello
world"


This was fixed upstream in v0.5.11:
https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?id=c4f4ee8ecf858348

--
Jakub Wilk

Bug#963238: RFS: slib/3b6-1 [ITA] -- Portable Scheme library

[Nick Gasson]

Hi,

Is anyone available to review this package? Or maybe suggest somewhere I
could look for a sponsor?

--
Thanks,
Nick

Bug#965138: Unable to disable decoded IDN output in host

[Marc SCHAEFER]

On Tue, Jul 28, 2020 at 04:56:20PM +0200, Bernhard Schmidt wrote:
> Not sure whether we can backport this easily. The +noidnout suggestion
> is definitely bogus, that's dig style.

At least for me, I have a work-around in place.

Thank you and have a nice day.

Bug#966619: Acknowledgement (keepass2: URL doesn't work anymore)

[Tobias Köck]

And here is the screenshot.

On 7/31/20 4:18 PM, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 966619: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966619.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  Debian CLI Applications Team 

If you wish to submit further information on this problem, please
send it to 966...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

Bug#966105: qt5ct: Bug causes all icons and fonts in KeePassXC to disappear

[Patrick Franz]

Hey Christian,

I forwarded the bug to https://sourceforge.net/p/qt5ct/tickets/81/.
The best way to get the bug fixed is to follow the development there and 
provide info if needed.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#966575: Security update can break grub - grub_calloc not found

[Steve McIntyre]

On Fri, Jul 31, 2020 at 03:07:58PM +0100, Geoff Gibbs wrote:
>On Fri, 31 Jul 2020 14:30:14 +0100
>Steve McIntyre  wrote:
>
>> I'm guessing - do you have multiple disks on your system? If so, try
>> "grub-install " on each of the bootable disks and that should
>> fix your problem.
>
>As I mentioned,
>
>mount /dev/sda5 /mnt
>grub-install --boot-directory=/mnt /dev/sda
>
>has fixed the problem for me.

Yup. Sorry - I saw that. Trying to respond to lots of people atm...

>fdisk -l reports :-
>
>Disk /dev/sda: 223.6 GiB, 240057409536 bytes, 468862128 sectors
>Disk model: Corsair Force GS
>Units: sectors of 1 * 512 = 512 bytes
>Sector size (logical/physical): 512 bytes / 512 bytes
>I/O size (minimum/optimal): 512 bytes / 512 bytes
>Disklabel type: dos
>Disk identifier: 0xc1920bad
>
>Device Boot  Start   End   Sectors   Size Id Type
>/dev/sda1  *  2048206847204800   100M  7 HPFS/NTFS/exFAT
>/dev/sda2   210942 468860927 468649986 223.5G  5 Extended
>/dev/sda5   210944722943512000   250M 83 Linux
>/dev/sda6   724992 468860927 468135936 223.2G 8e Linux LVM
>
>
>Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
>Disk model: WDC WD10EZRX-00A
>Units: sectors of 1 * 512 = 512 bytes
>Sector size (logical/physical): 512 bytes / 4096 bytes
>I/O size (minimum/optimal): 4096 bytes / 4096 bytes
>Disklabel type: dos
>Disk identifier: 0xc1920ba9
>
>Device Boot StartEndSectors   Size Id Type
>/dev/sdb1  * 2048  209717247  209715200   100G  7 HPFS/NTFS/exFAT
>/dev/sdb2   209721342 1953523711 1743802370 831.5G  5 Extended
>/dev/sdb5   209721344  230201343   2048   9.8G 82 Linux swap / Solaris
>/dev/sdb6   230203392 1953523711 1723320320 821.8G 8e Linux LVM
>
>Partition 2 does not start on physical sector boundary.
>
>And then there is a list of partitions handled by LVM (many for Xen)
>but including :-
>
>Disk /dev/mapper/SSD0-root: 20 GiB, 21474836480 bytes, 41943040 sectors
>Units: sectors of 1 * 512 = 512 bytes
>Sector size (logical/physical): 512 bytes / 512 bytes
>I/O size (minimum/optimal): 512 bytes / 512 bytes
>
>Disk /dev/mapper/HDD0-var: 9.3 GiB, 220736 bytes, 19529728 sectors
>Units: sectors of 1 * 512 = 512 bytes
>Sector size (logical/physical): 512 bytes / 4096 bytes
>I/O size (minimum/optimal): 4096 bytes / 4096 bytes
>
>Disk /dev/mapper/SSD0-home: 38.6 GiB, 41473277952 bytes, 81002496 sectors
>Units: sectors of 1 * 512 = 512 bytes
>Sector size (logical/physical): 512 bytes / 512 bytes
>I/O size (minimum/optimal): 512 bytes / 512 bytes

ACK. I tend to do "fdisk -l /dev/sd?" to avoid that behaviour on my
md/lvm machine here. :-)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...

Bug#966619: keepass2: URL doesn't work anymore

[tkoeck]

Package: keepass2
Version: 2.45+dfsg-1
Severity: normal

Dear Maintainer,

if I try to open the URL I get an Cannot find the specific file. I have
attached a screenshot and I have
completely reinstalled the keepass2 package. Didn't help.

Greetings
Tobias

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

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

Versions of packages keepass2 depends on:
ii  libgcrypt20  1.8.6-2
ii  libmono-corlib4.5-cil6.8.0.105+dfsg-3
ii  libmono-system-drawing4.0-cil6.8.0.105+dfsg-3
ii  libmono-system-security4.0-cil   6.8.0.105+dfsg-3
ii  libmono-system-windows-forms4.0-cil  6.8.0.105+dfsg-3
ii  libmono-system-xml4.0-cil6.8.0.105+dfsg-3
ii  libmono-system4.0-cil6.8.0.105+dfsg-3
ii  libx11-6 2:1.6.9-2+b1
ii  mono-runtime 6.8.0.105+dfsg-3

Versions of packages keepass2 recommends:
ii  xsel  1.2.0+git9bfc13d.20180109-3

Versions of packages keepass2 suggests:
pn  keepass2-doc  
pn  mono-dmcs 
pn  xdotool   

-- no debconf information

Bug#966575: Security update can break grub - grub_calloc not found

[Geoff Gibbs]

On Fri, 31 Jul 2020 14:30:14 +0100
Steve McIntyre  wrote:

> I'm guessing - do you have multiple disks on your system? If so, try
> "grub-install " on each of the bootable disks and that should
> fix your problem.

As I mentioned,

mount /dev/sda5 /mnt
grub-install --boot-directory=/mnt /dev/sda

has fixed the problem for me.

fdisk -l reports :-

Disk /dev/sda: 223.6 GiB, 240057409536 bytes, 468862128 sectors
Disk model: Corsair Force GS
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xc1920bad

Device Boot  Start   End   Sectors   Size Id Type
/dev/sda1  *  2048206847204800   100M  7 HPFS/NTFS/exFAT
/dev/sda2   210942 468860927 468649986 223.5G  5 Extended
/dev/sda5   210944722943512000   250M 83 Linux
/dev/sda6   724992 468860927 468135936 223.2G 8e Linux LVM


Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: WDC WD10EZRX-00A
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xc1920ba9

Device Boot StartEndSectors   Size Id Type
/dev/sdb1  * 2048  209717247  209715200   100G  7 HPFS/NTFS/exFAT
/dev/sdb2   209721342 1953523711 1743802370 831.5G  5 Extended
/dev/sdb5   209721344  230201343   2048   9.8G 82 Linux swap / Solaris
/dev/sdb6   230203392 1953523711 1723320320 821.8G 8e Linux LVM

Partition 2 does not start on physical sector boundary.

And then there is a list of partitions handled by LVM (many for Xen)
but including :-

Disk /dev/mapper/SSD0-root: 20 GiB, 21474836480 bytes, 41943040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/HDD0-var: 9.3 GiB, 220736 bytes, 19529728 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/mapper/SSD0-home: 38.6 GiB, 41473277952 bytes, 81002496 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Geoff

Bug#966612: systemd-networkd failed to restart on upgrade to 246-1

[Ansgar]

On Fri, 2020-07-31 at 15:40 +0200, Michael Biebl wrote:
> thanks for testing the v246 package from experimental.

Thanks for providing an update to Debian only ~1 hour after the
upstream release :-)

> > > Jul 31 14:30:06 systemd[1]: Unknown serialization item 'show-status=no', 
> > > ignoring.
> 
> Interesting, I've not seen this one before. Might be worth investigating
> separately what this is about if it's reproducible.

Probably not worth worrying about if there are no problems.  Might be
some option that was removed, but included in the old serialized state
that systemd writes/reads on reexec.

> > > Jul 31 14:30:07 systemd[1]: cgroup compatibility translation between 
> > > legacy and unified hierarchy settings activated. See cgroup->
> > > Jul 31 14:30:07 systemd[1]: Stopping Network Service...
> > > Jul 31 14:30:07 systemd[1]: systemd-networkd.service: Succeeded.
> > > Jul 31 14:30:07 systemd[1]: Stopped Network Service.
> > > Jul 31 14:30:07 systemd[1]: Starting Network Service...
> > > Jul 31 14:30:07 systemd-networkd[171450]: Could not enumerate links: 
> > > Exchange full
> 
> Hm, this appears to be https://github.com/systemd/systemd/issues/16319
> 
> I appears the offending two commits were (unfortunately) cherry-picked
> into v245.6 and fixed in v246. Since this is supposedly a transient
> issue and upgrades from buster should not be affected, I'm inclined to
> close this bug report. WDYT?

Fine with me if it only affects upgrades from testing and also
considering that -networkd isn't enabled by default.

Ansgar

Bug#966618: network-manager: with dhcp=dhclient, dhclient hooks are not run

[Vincent Lefevre]

Package: network-manager
Version: 1.26.0-1
Severity: normal

I have configured NetworkManager with

[main]
dhcp=dhclient

in particular to use the dhclient hooks, but they are not run.

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

Kernel: Linux 5.7.0-2-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 network-manager depends on:
ii  adduser  3.118
ii  dbus 1.12.20-1
ii  libaudit11:2.8.5-3+b1
ii  libbluetooth35.50-1.2
ii  libc62.31-2
ii  libcurl3-gnutls  7.68.0-1+b1
ii  libglib2.0-0 2.64.4-1
ii  libgnutls30  3.6.14-2+b1
ii  libjansson4  2.13.1-1
ii  libmm-glib0  1.14.0-0.1
ii  libndp0  1.6-1+b1
ii  libnewt0.52  0.52.21-4+b1
ii  libnm0   1.26.0-1
ii  libpam-systemd   245.7-1
ii  libpsl5  0.21.0-1.1
ii  libreadline8 8.0-4
ii  libselinux1  3.1-2
ii  libsystemd0  245.7-1
ii  libteamdctl0 1.30-1
ii  libudev1 245.7-1
ii  libuuid1 2.36-1
ii  policykit-1  0.105-28
ii  udev 245.7-1
ii  wpasupplicant2:2.9.0-13

Versions of packages network-manager recommends:
ii  crda 4.14+git20191112.9856751-1
ii  dnsmasq-base [dnsmasq-base]  2.82-1
ii  iptables 1.8.5-2
ii  modemmanager 1.14.0-0.1
ii  ppp  2.4.7-2+4.1+deb10u1

Versions of packages network-manager suggests:
ii  isc-dhcp-client  4.4.1-2.1+b2
pn  libteam-utils

-- no debconf information

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

Bug#966612: systemd-networkd failed to restart on upgrade to 246-1

[Michael Biebl]

Control: clone -1 -2
Control: reassign -2 lintian
Control: severity -2 wishlist
Control: retitle -2 "Please if Standard{Output,Error}=syslog is used"


Hi Ansgar,

thanks for testing the v246 package from experimental.

Am 31.07.2020 um 14:45 schrieb Ansgar:
> Package: systemd
> Version: 246-1
> Severity: minor
> 
> systemd-networkd failed to (re)start on an upgrade from systemd
> 245.6-2 to 246-1:
> 
> +---
> | Jul 31 14:30:06 systemd[1]: Reexecuting.
> | Jul 31 14:30:06 systemd[1]: systemd 246-1 running in system mode. (+PAM 
> +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LI>
> | Jul 31 14:30:06 systemd[1]: Detected architecture x86-64.
> | Jul 31 14:30:06 kernel: Lockdown: systemd: /dev/mem,kmem,port is 
> restricted; see https://wiki.debian.org/SecureBoot
> | Jul 31 14:30:06 systemd[1]: /lib/systemd/system/plymouth-start.service:16: 
> Unit configured to use KillMode=none. This is unsafe, >
> | Jul 31 14:30:06 systemd[1]: /lib/systemd/system/apt-listbugs.service:30: 
> Standard output type syslog is obsolete, automatically u>
> | Jul 31 14:30:06 systemd[1]: /lib/systemd/system/apt-listbugs.service:31: 
> Standard output type syslog is obsolete, automatically u>
> | Jul 31 14:30:06 systemd[1]: /lib/systemd/system/gdm.service:30: Standard 
> output type syslog is obsolete, automatically updating t>
> | Jul 31 14:30:06 systemd[1]: /lib/systemd/system/smartmontools.service:10: 
> Standard output type syslog is obsolete, automatically >

Looks like something we should file individual bug reports for or add a
lintian check. I decided for the latter for now.

Dear lintian maintainers, please see
https://github.com/systemd/systemd/blob/master/NEWS#L101

```
* StandardError= and StandardOutput= in unit files no longer support
  the "syslog" and "syslog-console" switches. They were long removed
  from the documentation, but will now result in warnings when used,
  and be converted to "journal" and "journal+console" automatically.
```

Since journal is the default anyway, I guess the best recommendation is,
that maintainers simply remove any such lines from their unit files.

See also
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#StandardOutput=


> | Jul 31 14:30:06 systemd[1]: Unknown serialization item 'show-status=no', 
> ignoring.

Interesting, I've not seen this one before. Might be worth investigating
separately what this is about if it's reproducible.

> | Jul 31 14:30:07 systemd[1]: cgroup compatibility translation between legacy 
> and unified hierarchy settings activated. See cgroup->
> | Jul 31 14:30:07 systemd[1]: Stopping Network Service...
> | Jul 31 14:30:07 systemd[1]: systemd-networkd.service: Succeeded.
> | Jul 31 14:30:07 systemd[1]: Stopped Network Service.
> | Jul 31 14:30:07 systemd[1]: Starting Network Service...
> | Jul 31 14:30:07 systemd-networkd[171450]: Could not enumerate links: 
> Exchange full

Hm, this appears to be https://github.com/systemd/systemd/issues/16319

I appears the offending two commits were (unfortunately) cherry-picked
into v245.6 and fixed in v246. Since this is supposedly a transient
issue and upgrades from buster should not be affected, I'm inclined to
close this bug report. WDYT?

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?






signature.asc
Description: OpenPGP digital signature

Bug#966616: ITP: redmine-plugin-redhopper -- Kanban boards for Redmine, inspired by Jira Agile

[merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: redmine-plugin-redhopper
  Version : 2.0.0
  Upstream Author : infoPiiaf 
* URL : https://git.framasoft.org/infopiiaf/redhopper
* License : AGPL-3+
  Programming Lang: Ruby
  Description : Kanban boards for Redmine, inspired by Jira Agile
 Kanban boards for Redmine, inspired by Jira Agile (formerly known as
 Greenhopper). Inside a project, Redhopper places a new tab called
Kanbans. This
 view displays all the issue statuses in columns, sorted according to the
 settings in Redmine administration. All the visible issues for the
current user
 are listed within the column matching their status.

Remark: This package will be maintained at
   https://salsa.debian.org/debian/redmine-plugin-redhopper

Bug#966185: monit: new upstream version 5.27.0

[Christian Göttsche]

Am Fr., 31. Juli 2020 um 10:15 Uhr schrieb Sergey B Kirpichev
:
>
> I would appreciate any help with this upgrade.  There seems to
> be some issues with dh_autoreconf.
>

I think they should be solved by using the upstream bootstrap script:

override_dh_autoreconf:
dh_autoreconf ./bootstrap

Bug#966575: Security update can break grub - grub_calloc not found

[Steve McIntyre]

Hi Geoff,

On Fri, Jul 31, 2020 at 11:54:20AM +0100, Geoff Gibbs wrote:
>apt update
>apt full-upgrade
>
>grub upgrades
>
>from 2.02+dfsg1-20
>to 2.02+dfsg1-20+deb10u1
>
>no errors were spotted.
>
>When rebooted :-
>
>symbol grub_calloc not found
>Entering rescue mode
>grub rescue>
>
>
>I had to boot off a memory stick and then :-
>
>sudo -i
>mount /dev/sda5 /mnt
>grub-install --boot-directory=/mnt /dev/sda
>reboot
>
>This worked and the system now boots.
>
>/boot is the only ext type file system, the others are all handled by LVM

I'm guessing - do you have multiple disks on your system? If so, try
"grub-install " on each of the bootable disks and that should
fix your problem.

I think we need a proper fix for this in the longer term, but that's
not going to happen overnight.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You lock the door
And throw away the key
There's someone in my head but it's not me 

Bug#966575: grub-pc: error: symbol `grub_calloc' not found

[Steve McIntyre]

Hi John,

On Fri, Jul 31, 2020 at 09:29:43AM +0100, John Lines wrote:
>I have the same error, on a DNUK Workstar 700, dating back to 2014, so
>upgraded from squeeze on up to buster.It is possible this legacy which
>has resulted in something unusual in the grub configuration. 
>
>I upgraded grub yesterday, and am working on recovering now. Posting
>from another system.

ACK. Same thing applies as I suggested to Paul - maybe an inconsistent
set of updates. Do you have multiple disks? If so, try "grub-install
" on all the bootable disks and that may fix your problem. If
not, please get back to us ASAP and we'll try to debug the problem
here.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Into the distance, a ribbon of black
Stretched to the point of no turning back

Bug#966615: ITP: node-ansi-colors -- Add ANSI colors to your text and symbols in the terminal

[Kartik Kulkarni]

Package: wnpp
Severity: wishlist
Owner: Kartik Kulkarni 
X-Debbugs-CC: d...@jones.dk

* Package name: node-ansi-colors
  Version : 4.1.1
  Upstream Author : Brian Woodward (https://github.com/doowb)
* URL : https://github.com/doowb/ansi-colors
* License : Expat
  Programming Lang: JavaScript
  Description : Add ANSI colors to your text and symbols in the terminal

 Ansi-colors is the official ansi styling library for gulp,
 and is used by hundreds of other projects, including mocha and enquirer.
 .
 A faster drop-in replacement for chalk, kleur and turbocolor
 .
 It supports nested colors and chained colors with support
 to toggle support on and off.
 .
 It has no dependencies and thus easier to maintain.
 .
 Node.js is an event-based server-side JavaScript engine.

 This package is a transitive dependency of eslint and needs to be
 packaged for the packaging of eslint.
 .
 This package will be maintained in the javascript team.

Bug#966575: grub-pc: error: symbol `grub_calloc' not found.

[Steve McIntyre]

Hi Paul,

On Fri, Jul 31, 2020 at 06:39:20AM +0200, Paul Menzel wrote:
>Am 31.07.20 um 06:30 schrieb Paul Menzel:
>
>> Am 30.07.20 um 23:54 schrieb Paul Menzel:
>> > Package: grub-pc
>> > Version: 2.04-9
>> > Severity: grave
>> 
>> > On a Acer TravelMate 5735Z with Debian Sid/unstable, upgrading the
>> > package `grub-pc` causes GRUB to fail on next boot and drop into a
>> > rescue shell.
>> > 
>> >  GRUB loading.
>> >  Welcome to GRUB!
>> > 
>> >  error: symbol 'grub_calloc' not found.
>> >  grub rescue>
>> > 
>> > It only seems to effects MBR installation.
>> 
>> I missed to report, that the system has a separate `/boot` partition and
>> a LUKS encrypted root `/`.
>
>Sorry, please scratch that. I remembered incorrectly. It’s just one
>unencrypted F2FS formatted partition.

How many disks do you have on your system, please?

*If* you have more than one, there's a potential for grub-install to
have not been run to install grub to all the MBRs, and then the BIOS
finds an old copy of the GRUB first-stage loader but tries to use
newer modules. this mis-match can cause all kinds of problems. :-/

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

Bug#966575: I was affected as well

[Steve McIntyre]

Hi Norbert,

On Thu, Jul 30, 2020 at 11:26:15PM -0700, Norbert Kiesel wrote:
>This is a laptop running Debain Unstable with 2 SSD and one spinning disk. 
>After upgrade and install, system stopped with same error message during boot.
>
>I was able to reactivate using a live boot system.

ACK. Same thing applies as I suggested to Paul - maybe an inconsistent
set of updates. Have you *fixed* the problem by using the live boot?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
There's no sensation to compare with this
Suspended animation, A state of bliss

Bug#966614: gsd-housekeeping: Failed to enumerate children of /var/tmp/systemd-private...

[Jiangsu Kumquat]

Package: gnome-settings-daemon
Version: 3.30.2-3

$ apt policy gnome-settings-daemon
gnome-settings-daemon:
  Installed: 3.30.2-3
  Candidate: 3.30.2-3
  Version table:
 *** 3.30.2-3 500
500 http://deb.debian.org/debian buster/main amd64 Packages
100 /var/lib/dpkg/status

I have a bunch of lines like this in my systemd journal logs:

I have a bunch of lines like this for several services:

Jul 31 02:35:45 debian gsd-housekeepin[1546]: Failed to enumerate
children of 
/var/tmp/systemd-private-e7659f24f12a46ba8f34fda22628c99f-upower.service-E5eC1k:
Error opening directory
'/var/tmp/systemd-private-e7659f24f12a46ba8f34fda22628c99f-upower.service-E5eC1k':
Permission denied

looking at the journal logs, they are full of almost nothing but lines
like that for various services.

uname -a
Linux debian 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1
(2020-06-07) x86_64 GNU/Linux

libc6 Version: 2.28-10

I have not modified anything with the config for that package. I'm
using the default buster setup.

Bug#966613: orthanc-postgresql

[Gianfranco Costamagna]

Source: orthanc-postgresql
Version: 3.2-2
tags: patch


Hello, can you please add support for postgresql12?
(and maybe consider also adding 13)

thanks!
(note: I'm not the author for the patch, and I don't speak mercurial, so please 
forward upstream!)


trivial patch:

diff -Nru orthanc-postgresql-3.2/debian/patches/pg12.patch 
orthanc-postgresql-3.2/debian/patches/pg12.patch
--- orthanc-postgresql-3.2/debian/patches/pg12.patch1970-01-01 
00:00:00.0 +
+++ orthanc-postgresql-3.2/debian/patches/pg12.patch2020-02-06 
01:11:19.0 +
@@ -0,0 +1,15 @@
+Description: Add pg12 to cmake detection.
+Author: Dimitri John Ledkov 
+
+
+--- orthanc-postgresql-3.2.orig/Resources/CMake/PostgreSQLConfiguration.cmake
 orthanc-postgresql-3.2/Resources/CMake/PostgreSQLConfiguration.cmake
+@@ -378,7 +378,7 @@ if (STATIC_BUILD OR NOT USE_SYSTEM_LIBPQ
+ 
+ else()
+   set(PostgreSQL_ADDITIONAL_VERSIONS
+-"11" "10" "9.6" "9.5" "9.4" "9.3" "9.2" "9.1" "9.0" "8.4" "8.3" "8.2" 
"8.1" "8.0")
++"12" "11" "10" "9.6" "9.5" "9.4" "9.3" "9.2" "9.1" "9.0" "8.4" "8.3" 
"8.2" "8.1" "8.0")
+   if (NOT WIN32)
+ foreach (suffix ${PostgreSQL_ADDITIONAL_VERSIONS})
+   list(APPEND PostgreSQL_ADDITIONAL_SEARCH_PATHS
diff -Nru orthanc-postgresql-3.2/debian/patches/series 
orthanc-postgresql-3.2/debian/patches/series
--- orthanc-postgresql-3.2/debian/patches/series2020-04-03 
05:42:37.0 +
+++ orthanc-postgresql-3.2/debian/patches/series2020-06-05 
15:16:01.0 +
@@ -0,0 +1 @@
+pg12.patch

Bug#966612: systemd-networkd failed to restart on upgrade to 246-1

[Ansgar]

Package: systemd
Version: 246-1
Severity: minor

systemd-networkd failed to (re)start on an upgrade from systemd
245.6-2 to 246-1:

+---
| Jul 31 14:30:06 systemd[1]: Reexecuting.
| Jul 31 14:30:06 systemd[1]: systemd 246-1 running in system mode. (+PAM 
+AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LI>
| Jul 31 14:30:06 systemd[1]: Detected architecture x86-64.
| Jul 31 14:30:06 kernel: Lockdown: systemd: /dev/mem,kmem,port is restricted; 
see https://wiki.debian.org/SecureBoot
| Jul 31 14:30:06 systemd[1]: /lib/systemd/system/plymouth-start.service:16: 
Unit configured to use KillMode=none. This is unsafe, >
| Jul 31 14:30:06 systemd[1]: /lib/systemd/system/apt-listbugs.service:30: 
Standard output type syslog is obsolete, automatically u>
| Jul 31 14:30:06 systemd[1]: /lib/systemd/system/apt-listbugs.service:31: 
Standard output type syslog is obsolete, automatically u>
| Jul 31 14:30:06 systemd[1]: /lib/systemd/system/gdm.service:30: Standard 
output type syslog is obsolete, automatically updating t>
| Jul 31 14:30:06 systemd[1]: /lib/systemd/system/smartmontools.service:10: 
Standard output type syslog is obsolete, automatically >
| Jul 31 14:30:06 systemd[1]: Unknown serialization item 'show-status=no', 
ignoring.
| Jul 31 14:30:07 systemd[1]: cgroup compatibility translation between legacy 
and unified hierarchy settings activated. See cgroup->
| Jul 31 14:30:07 systemd[1]: Stopping Network Service...
| Jul 31 14:30:07 systemd[1]: systemd-networkd.service: Succeeded.
| Jul 31 14:30:07 systemd[1]: Stopped Network Service.
| Jul 31 14:30:07 systemd[1]: Starting Network Service...
| Jul 31 14:30:07 systemd-networkd[171450]: Could not enumerate links: Exchange 
full
| Jul 31 14:30:07 systemd[1]: systemd-networkd.service: Main process exited, 
code=exited, status=1/FAILURE
| Jul 31 14:30:07 systemd[1]: systemd-networkd.service: Failed with result 
'exit-code'.
| Jul 31 14:30:07 systemd[1]: Failed to start Network Service.
| Jul 31 14:30:07 systemd[1]: systemd-networkd.service: Scheduled restart job, 
restart counter is at 1.
| Jul 31 14:30:07 systemd[1]: Stopped Network Service.
| Jul 31 14:30:07 systemd[1]: Starting Network Service...
| Jul 31 14:30:07 systemd[1]: Stopping Network Name Resolution...
| Jul 31 14:30:07 systemd[1]: systemd-resolved.service: Succeeded.
| Jul 31 14:30:07 systemd[1]: Stopped Network Name Resolution.
| Jul 31 14:30:07 systemd-networkd[171452]: Could not enumerate links: Exchange 
full
| Jul 31 14:30:07 systemd[1]: systemd-networkd.service: Main process exited, 
code=exited, status=1/FAILURE
| Jul 31 14:30:07 systemd[1]: systemd-networkd.service: Failed with result 
'exit-code'.
| Jul 31 14:30:07 systemd[1]: Failed to start Network Service.
| Jul 31 14:30:07 systemd[1]: systemd-networkd.service: Scheduled restart job, 
restart counter is at 2.
| Jul 31 14:30:07 systemd[1]: Stopped Network Service.
| Jul 31 14:30:07 systemd[1]: Starting Network Service...
| Jul 31 14:30:07 systemd-networkd[171458]: Could not enumerate links: Exchange 
full
| Jul 31 14:30:07 systemd[1]: systemd-networkd.service: Main process exited, 
code=exited, status=1/FAILURE
| Jul 31 14:30:07 systemd[1]: systemd-networkd.service: Failed with result 
'exit-code'.
| Jul 31 14:30:07 systemd[1]: Failed to start Network Service.
| Jul 31 14:30:07 systemd[1]: systemd-networkd.service: Scheduled restart job, 
restart counter is at 3.
| Jul 31 14:30:07 systemd[1]: Stopped Network Service.
| Jul 31 14:30:07 systemd[1]: Starting Network Service...
| Jul 31 14:30:08 systemd-networkd[171460]: Could not enumerate links: Exchange 
full
| Jul 31 14:30:08 systemd[1]: systemd-networkd.service: Main process exited, 
code=exited, status=1/FAILURE
| Jul 31 14:30:08 systemd[1]: systemd-networkd.service: Failed with result 
'exit-code'.
| Jul 31 14:30:08 systemd[1]: Failed to start Network Service.
| Jul 31 14:30:08 systemd[1]: systemd-networkd.service: Scheduled restart job, 
restart counter is at 4.
| Jul 31 14:30:08 systemd[1]: Stopped Network Service.
| Jul 31 14:30:08 systemd[1]: Starting Network Service...
| Jul 31 14:30:08 systemd-networkd[171462]: Could not enumerate links: Exchange 
full
| Jul 31 14:30:08 systemd[1]: systemd-networkd.service: Main process exited, 
code=exited, status=1/FAILURE
| Jul 31 14:30:08 systemd[1]: systemd-networkd.service: Failed with result 
'exit-code'.
| Jul 31 14:30:08 systemd[1]: Failed to start Network Service.
| Jul 31 14:30:08 systemd[1]: systemd-networkd.service: Scheduled restart job, 
restart counter is at 5.
| Jul 31 14:30:08 systemd[1]: Stopped Network Service.
| Jul 31 14:30:08 systemd[1]: systemd-networkd.service: Start request repeated 
too quickly.
| Jul 31 14:30:08 systemd[1]: systemd-networkd.service: Failed with result 
'exit-code'.
| Jul 31 14:30:08 systemd[1]: Failed to start Network Service.
| Jul 31 14:30:08 systemd[1]: systemd-networkd.socket: Failed with result 
'service-start-limit-hit'.
| Jul 31 14:30:08 systemd[1]: Starting Network Name Resolution...
| Jul 

Bug#966611: pelican: New upstream version available

[Shayan Doust]

Package: pelican
Version: 4.0.1+dfsg-1
Severity: wishlist

The version packaged that is within unstable, testing and stable is
4.0.1, however upstream has, at this time, generated a tarball for
4.2.0.

As a regular user of Pelican, would you kindly consider packaging the
latest upstream tarball (4.2.0)? Some new features, such as live browser
reload and inline SVGs would come really handy.

Kind regards,
Shayan Doust

Bug#957941: wmcalclock: diff for NMU version 1.25-16.1

[Torrance, Douglas]

Control: tags -1 forwarded wmaker-...@googlegroups.com

On 7/31/20 7:25 AM, Sudip Mukherjee wrote:
> I've prepared an NMU for wmcalclock (versioned as 1.25-16.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should cancel it.
> 
> Also added Douglas in Cc as he intends to adopt this package.
> 
> --
> Regards
> Sudip
> 
> diff -Nru wmcalclock-1.25/debian/changelog wmcalclock-1.25/debian/changelog
> --- wmcalclock-1.25/debian/changelog2016-10-27 01:33:54.0 +0100
> +++ wmcalclock-1.25/debian/changelog2020-07-31 12:11:07.0 +0100
> @@ -1,3 +1,10 @@
> +wmcalclock (1.25-16.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Fix ftbfs with GCC-10. (Closes: #957941)
> +
> + -- Sudip Mukherjee   Fri, 31 Jul 2020 12:11:07 
> +0100
> +
>   wmcalclock (1.25-16) unstable; urgency=low
> 
> * Remove deprecated dpatch and upgrade to packaging format "3.0 quilt".
> diff -Nru wmcalclock-1.25/debian/patches/05-fix-ftbfs.patch 
> wmcalclock-1.25/debian/patches/05-fix-ftbfs.patch
> --- wmcalclock-1.25/debian/patches/05-fix-ftbfs.patch   1970-01-01 
> 01:00:00.0 +0100
> +++ wmcalclock-1.25/debian/patches/05-fix-ftbfs.patch   2020-07-29 
> 21:44:00.0 +0100
> @@ -0,0 +1,41 @@
> +Description: Fix ftbfs with GCC-10
> +
> +Author: Sudip Mukherjee 
> +Bug-Debian: https://bugs.debian.org/957941
> +Forwarded: no
> +
> +---
> +
> +--- wmcalclock-1.25.orig/Src/xutils.c
>  wmcalclock-1.25/Src/xutils.c
> +@@ -53,6 +53,11 @@ GC  NormalGC;
> + XpmIcon   wmgen;
> + Pixmappixmask;
> +
> ++Display   *display;
> ++WindowRoot;
> ++Windowiconwin, win;
> ++int   screen;
> ++int   DisplayDepth;
> +
> + /*
> +  *  Colors for wmCalClock
> +--- wmcalclock-1.25.orig/Src/xutils.h
>  wmcalclock-1.25/Src/xutils.h
> +@@ -18,11 +18,11 @@ typedef struct {
> + /*
> +  *   Global variable
> +  */
> +-Display   *display;
> +-Window  Root;
> +-Window  iconwin, win;
> +-int screen;
> +-int DisplayDepth;
> ++extern Display*display;
> ++extern Window Root;
> ++extern Window iconwin, win;
> ++extern intscreen;
> ++extern intDisplayDepth;
> +
> +
> +
> diff -Nru wmcalclock-1.25/debian/patches/series 
> wmcalclock-1.25/debian/patches/series
> --- wmcalclock-1.25/debian/patches/series   2016-10-27 01:27:28.0 
> +0100
> +++ wmcalclock-1.25/debian/patches/series   2020-07-29 21:42:34.0 
> +0100
> @@ -3,3 +3,4 @@
>   02-30hr-patch.patch
>   03-manapge-30hr-patch.patch
>   04-makefile-modifications.patch
> +05-fix-ftbfs.patch

I've forwarded your patch upstream.  Thank you!
From 704cd8679f95fca7cce61ae4fe2e7b4ba203da5c Mon Sep 17 00:00:00 2001
From: Sudip Mukherjee 
Date: Fri, 31 Jul 2020 08:13:33 -0400
Subject: [PATCH] Description: Fix ftbfs with GCC-10

Bug-Debian: https://bugs.debian.org/957941
Forwarded: no
---
 wmCalClock/Src/xutils.c |  5 +
 wmCalClock/Src/xutils.h | 10 +-
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/wmCalClock/Src/xutils.c b/wmCalClock/Src/xutils.c
index 5426d4f..008afa5 100644
--- a/wmCalClock/Src/xutils.c
+++ b/wmCalClock/Src/xutils.c
@@ -53,6 +53,11 @@ GC		NormalGC;
 XpmIcon		wmgen;
 Pixmap		pixmask;
 
+Display   *display;
+WindowRoot;
+Windowiconwin, win;
+int   screen;
+int   DisplayDepth;
 
 /*
  *  Colors for wmCalClock
diff --git a/wmCalClock/Src/xutils.h b/wmCalClock/Src/xutils.h
index 4ed615f..b8f3f77 100644
--- a/wmCalClock/Src/xutils.h
+++ b/wmCalClock/Src/xutils.h
@@ -18,11 +18,11 @@ typedef struct {
 /*
  *   Global variable
  */
-Display		*display;
-Window  Root;
-Window  iconwin, win;
-int screen;
-int DisplayDepth;
+extern Display*display;
+extern Window Root;
+extern Window iconwin, win;
+extern intscreen;
+extern intDisplayDepth;
 
 
 
-- 
2.25.1

Bug#966610: systemd: autopkgtest-virt-lxc fails in timedated on arm64

[Ryutaroh Matsumoto]

Package: systemd
Version: 245.7-1
Severity: minor

Dear Maintainer,

I ran autopkgtest-virt-lxc on systemd in unstable on arm64
(Raspberry Pi 4B). It failed in timedated test as shown below.
My configuration is a bit exotic.
LXC is 4.0.2 from unstable.
Unified Cgourp hierarchy.
Kernel is from the Raspberry Pi Foundation (see below).
The testbed was built by autopkgtest-build-lxc debian sid
(the standard way).

timedated-stderr shows:
FAIL: 'boolean false' not found in:
signal time=1596194518.252811 sender=org.freedesktop.DBus -> destination=:1.38 
serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; 
member=NameAcquired
   string ":1.38"
signal time=1596194518.253030 sender=org.freedesktop.DBus -> destination=:1.38 
serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; 
member=NameLost
   string ":1.38"

timedated-packages shows:
acl 2.2.53-8
libnss-systemd  245.7-1

timedated-stdout shows:
original tz: Etc/UTC
timedatectl works
change timezone
reset timezone to original
no adjtime file
UTC set in adjtime file
non-zero values in adjtime file
fourth line adjtime file
no final newline in adjtime file
only one line in adjtime file
only one line in adjtime file, no final newline
only two lines in adjtime file
only two lines in adjtime file, no final newline
unknown value in 3rd line of adjtime file
disable NTP
enable NTP
re-disable NTP

Best regards, Ryutaroh Matsumoto

-- Package-specific info:

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 5.4.51-v8+ (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-8
ii  libapparmor1 2.13.4-3
ii  libaudit11:2.8.5-3+b1
ii  libblkid12.36-1
ii  libc62.31-2
ii  libcap2  1:2.36-1
ii  libcrypt11:4.4.16-1
ii  libcryptsetup12  2:2.3.3-1
ii  libgcrypt20  1.8.6-2
ii  libgnutls30  3.6.14-2+b1
ii  libgpg-error01.38-2
ii  libidn2-02.3.0-1
ii  libip4tc21.8.5-2
ii  libkmod2 27+20200310-2
ii  liblz4-1 1.9.2-2
ii  liblzma5 5.2.4-1+b1
ii  libmount12.36-1
ii  libpam0g 1.3.1-5+rpt2
ii  libpcre2-8-0 10.34-7
ii  libseccomp2  2.4.3-1+b1
ii  libselinux1  3.1-2
ii  libsystemd0  245.7-1
ii  mount2.36-1
ii  systemd-timesyncd [time-daemon]  245.7-1
ii  util-linux   2.36-1

Versions of packages systemd recommends:
ii  dbus  1.12.20-1

Versions of packages systemd suggests:
pn  policykit-1
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
pn  initramfs-tools  
ii  libnss-systemd   245.7-1
ii  libpam-systemd   245.7-1
ii  udev 245.7-1

-- Configuration Files:
/etc/systemd/journald.conf changed [not included]
/etc/systemd/logind.conf changed [not included]
/etc/systemd/system.conf changed [not included]
/etc/systemd/user.conf changed [not included]

-- no debconf information

Bug#966065: tome: FTBFS with GCC 10 due to insufficient #includes

[Reiner Herrmann]

Control: tags -1 + patch
Control: forwarded -1 https://github.com/tome2/tome2/pull/49

Hi,

the attached patch fixes the FTBFS with GCC 10.

Regards,
  Reiner
diff --git a/debian/patches/gcc10.patch b/debian/patches/gcc10.patch
new file mode 100644
index ..bf9fcf45
--- /dev/null
+++ b/debian/patches/gcc10.patch
@@ -0,0 +1,16 @@
+Author: Reiner Herrmann 
+Description: Fix FTBFS with GCC 10
+Bug-Debian: https://bugs.debian.org/966065
+Forwarded: https://github.com/tome2/tome2/pull/49
+
+--- a/src/init1.hpp
 b/src/init1.hpp
+@@ -3,6 +3,8 @@
+ #include "h-basic.hpp"
+ #include "dungeon_flag_set.hpp"
+ 
++#include 
++
+ int color_char_to_attr(char c);
+ extern byte conv_color[16];
+ errr init_player_info_txt(FILE *fp);
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index ..50fb8b62
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+gcc10.patch


signature.asc
Description: PGP signature

Bug#966608: debian-cd: Daily iso flagged as virus/malware by Firefox

[Jeffrey Bouter]

Alright, thank you for replying so quickly :-) Sorry for the duplicate report, 
glad it's being worked on.

-- 
Met vriendelijke groet / Yours sincerely,

Jeffrey Bouter

PGP Key Fingerprint: AFBF 7A03 7487  5E8E F5C8 49D9 F8B6 DDB2 A352

On vrijdag 31 juli 2020 13:54:14 CEST Steve McIntyre wrote:
> On Fri, Jul 31, 2020 at 01:09:44PM +0200, Jeffrey Bouter wrote:
> >Package: debian-cd
> >Severity: normal
> >
> >Dear Maintainer,
> >
> >When downloading the daily ISO, Firefox reports the bug is flagged as
> >Virus/Malware.
> >
> >I've verified this with other users, and they have the same issue.
> 
> ACK, thanks for reporting. It *is* a false positive - we are happy
> that we do not have a problem with malware.
> 
> We've had a slew of similar complaints this week, all apparently
> triggered by Google's "safe browsing" service. We're trying to get it
> fixed at their end.


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

Bug#966191: cufflinks: FTBFS with GCC 10

[Reiner Herrmann]

Control: tags -1 + patch

Hi,

the attached patch fixes the FTBFS with GCC 10.

Regards,
  Reiner
diff --git a/debian/patches/gcc10.patch b/debian/patches/gcc10.patch
new file mode 100644
index 000..1a58bd4
--- /dev/null
+++ b/debian/patches/gcc10.patch
@@ -0,0 +1,17 @@
+Author: Reiner Herrmann 
+Description: Fix FTBFS with GCC 10
+ curwin is declared in different source file. declare it as extern
+ to fix multiple definition linker error.
+Bug-Debian: https://bugs.debian.org/966191
+
+--- a/src/locfit/startlf.c
 b/src/locfit/startlf.c
+@@ -233,7 +233,7 @@
+ extern lfit lf;
+ extern design des;
+ extern plots pl[];
+-int curwin;
++extern int curwin;
+ vari *vb;
+ 
+ INT nofit()
diff --git a/debian/patches/series b/debian/patches/series
index a478e9a..fd3fe0d 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -8,3 +8,4 @@ fix_gcc-7_ftbfs.patch
 format-security.patch
 lib_eigen.patch
 fix_gcc-6.1_issue_in_liblemon_code_copy.patch
+gcc10.patch


signature.asc
Description: PGP signature

Bug#966600: nfstrace: patch for newer json-c/gcc-10

[Gianfranco Costamagna]

control: forwarded -1 https://github.com/epam/nfstrace/pull/42

G.