Bug#449606: Watch "JEEZY-BACK 2 THA TRAP [FULL MIXTAPE]" on YouTube

[Jarrod Jackson]

https://youtu.be/vKlCKz0M8_U

Bug#971523: ntpsec-ntpdate: ntpdate fail if DNS name for server resolve to IPv6

[Richard Laager]

tags 971523 upstream
forwarded 971523 https://gitlab.com/NTPsec/ntpsec/-/issues/680

On 10/1/20 4:13 AM, Petter Reinholdtsen wrote:
> ntpdig: socket error on transmission: [Errno 101] Network is unreachable
> 
> My guess is that you have working IPv6, while I do not.
> 
> root@devuan-n900:~# ping6 2001:67c:558::43
> connect: Network is unreachable
> root@devuan-n900:~# 

I previously had IPv6 enabled, but no (non-link-local) IPv6 address. If
I disable IPv6 entirely, I get:
[Errno 99] Cannot assign requested address

That's slightly different than your error, but the principle of the
failure is the same.

-- 
Richard



signature.asc
Description: OpenPGP digital signature

Bug#972904: git-debrebase: provide bash-completions

[Calum McConnell]

Package: git-debrebase
Version: 9.12
Severity: wishlist
X-Debbugs-Cc: calumlikesapple...@gmail.com

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

It would be really neat if there were bash-completions for the git-debrebase
command.  I could put them together, but I am currently a bit busy, so I
figure I should file a bug, and work on it later.

It would really be quite straightforward, I think, since you could reuse a
lot of the code from git's autocompletions.

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

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

Versions of packages git-debrebase depends on:
ii  devscripts  2.20.4
ii  git [git-core]  1:2.28.0-1
ii  libdpkg-perl1.20.5
ii  libfile-fnmatch-perl0.02-2+b7
ii  liblocale-gettext-perl  1.07-4
ii  perl5.30.3-4

Versions of packages git-debrebase recommends:
ii  dgit  9.12
ii  git-buildpackage  0.9.20

git-debrebase suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7FiEE/vC/PEGxsMPJ5u5w7/Xh1+DNmzIFAl+WVmIdHGNhbHVtbGlr
ZXNhcHBsZXBpZUBnbWFpbC5jb20ACgkQ7/Xh1+DNmzKvBBAA4FUmJlm6NOI1enF4
zVhQk+Rb9DwIupBaHQLlh6VzGi/N5J1voeVrdZ9oHySONmTxfpBdC4UsViAnVXe1
vT8Zt1911XaTfNMqlw0eDIJn52r1MPVzVh9YnFtGbD1oag7SdeCr80f05MSRluxz
hJTrwG3oohps3CNkaGvqr+x6tZ23va9pgU7i7L99D59KCZtnwj6nX5Iv3ZTbDJnD
5FtOzIlZPPQ7oAkrzJVNlX9ZRo9LkkxvrFzDTL8kdz0og4713dfuW3df0ohEJ/Hr
caiGx1rzejyh2JJKoqDew0Bv71FxThJiB229MiOzM7om7YHeJcRv+XbvaPzCLhLv
fzY2Au5IebgD1kp951ksxz5MNQ7eqKXa468t7wgzWoH/YvFUIWv/xjOqF+rCy0FI
rjkfYLnwzDCRJAw5Hs+yVdOxjcuC27nCZ7zb5Gle+M2jHQQodxxlHumzJhBlNUQQ
Q6Si7cZLlkZa7fVJtdOTwS7BtzyEPuY8YsVuoToGDG/VgD0O9jhByQ+aa9r6bVij
F5rP3RzPGz1jXh+xPRaHCU7y8vRJrazEyetNuvNVbEmkcChQS+nCAAKsG0Qhib/9
LIoy9Ka9uyrkFo3viRkM46M2GipafSlFNzrXdkdWgfaU6po1pYDJcL+AexjN9r+R
SwpJtdnQ1LPNeRzoccYtWD0PmM0=
=Qb9a
-END PGP SIGNATURE-

Bug#703656: mp3gain: Segfault in III_dequantize_sample

[Paul Wise]

On Thu, 21 Mar 2013 22:49:01 +0100 Matthieu Dalstein wrote:

> I am facing systematic segfaults when running mp3gain on some mp3 files.

I know it was a long time ago, but it would be interesting to know if
you can reproduce this issue with the new version of mp3gain in
Debian unstable. If the crash has been solved or is still present, or
if you are unable to test this, please let us know.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#700765: rednotebook: Crashes when holding down ctrl-pgup or ctrl-pgdn to move through dates

[Paul Wise]

On Sat, 16 Feb 2013 22:47:13 -0800 Andrew Bennett wrote:

> If I hold down the ctrl key and the pgup or pgdn key to *quickly*
 > move through many dates, Rednotebook crashes.

I know it was a long time ago, but it would be interesting to know if
you can reproduce this issue with the new version of rednotebook in
Debian unstable. If the crash has been solved or is still present, or
if you are unable to test this, please let us know.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#788797: rednotebook: crashing at startup with segmentation fault - SOLVED

[Paul Wise]

On Mon, 15 Jun 2015 19:02:49 +0200 Stefano De Toni wrote:

> I moved the old directory .rednotebook in a backup directory and then I
> launched rednotebook to create a new .rednotebook directory. Finally I
> copied the data directory to new .rednotebook folder.

I know it was a long time ago, but it would be interesting to know if
you can reproduce this issue with the new version of rednotebook in
Debian unstable. If the crash has been solved or is still present, or
if you no longer have a backup of the old .rednotebook folder or are
otherwise unable to test this, please let us know.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#965098: migrated to guile 2.2

[Kai-Martin Knaak]

Just a heads-up: 
Upstream pushed a few patches to the git repository to make the package
compatible with guile 2.2. 

This removes the road block that triggered this removal request. Is
there anything else that prevents geda-gaf from staying in the Debian
repos?

---<)kaimartin(>---
-- 
Kai-Martin Knaak
Email: k...@familieknaak.de
Öffentlicher PGP-Schlüssel:
https://keyserver.ubuntu.com/pks/lookup?op=index=0x7B0F9882


pgpkbooHNwbcN.pgp
Description: OpenPGP digital signature

Bug#972903: buster-pu: package node-pathval/1.1.0-3+deb10u1

[Xavier Guimard]

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

[ Reason ]
node-pathval is vulnerable to a prototype pollution (CVE-2020-7751,
#972895)

[ Impact ]
Little security risk

[ Tests ]
The same patch is applied to debian/sid (same version) and tests are
enabled (and succeeds of course)

[ Risks ]
No risk, patch just adds a check

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
Just one check
diff --git a/debian/changelog b/debian/changelog
index 91b3ad0..05749be 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+node-pathval (1.1.0-3+deb10u1) buster; urgency=medium
+
+  * Fix prototype pollution (Closes: #972895, CVE-2020-7751)
+
+ -- Xavier Guimard   Mon, 26 Oct 2020 04:44:16 +0100
+
 node-pathval (1.1.0-3) unstable; urgency=medium
 
   * Point d/watch to /releases instead of /tags.
diff --git a/debian/patches/CVE-2020-7751.diff 
b/debian/patches/CVE-2020-7751.diff
new file mode 100644
index 000..7d1ed9a
--- /dev/null
+++ b/debian/patches/CVE-2020-7751.diff
@@ -0,0 +1,21 @@
+Description: fix prototype pollution
+Author: Adam Gold 
+Origin: upstream, https://github.com/chaijs/pathval/commit/21a9046
+Bug: https://snyk.io/vuln/SNYK-JS-PATHVAL-596926
+Bug-Debian: https://bugs.debian.org/972895
+Forwarded: not-needed
+Reviewed-By: Xavier Guimard 
+Last-Update: 2020-10-25
+
+--- a/index.js
 b/index.js
+@@ -76,6 +76,9 @@
+   var str = path.replace(/([^\\])\[/g, '$1.[');
+   var parts = str.match(/(\\\.|[^.]+?)+/g);
+   return parts.map(function mapMatches(value) {
++if (value === "constructor" || value === "__proto__" || value === 
"prototype") {
++  return {}
++}
+ var regexp = /^\[(\d+)\]$/;
+ var mArr = regexp.exec(value);
+ var parsed = null;
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..2c7bbd9
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+CVE-2020-7751.diff

Bug#895462: Please keep asciidoc in Debian

[Paul Wise]

On Fri, 13 Dec 2019 08:38:19 +0100 Simon Ruderich wrote:

> Another issue with asciidoctor, unrelated to its features, is
> that the output changes when compared to asciidoc. This is not a
> big issue but adds additional work during the conversion. So
> staying with asciidoc is simpler.

On that note, the upstream for autorevision has stated that they prefer
the asciidoc default theme and also don't like that asciidoctor uses
the Google web fonts in its themes.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#972902: Move /var/lib/debspawn/aptcache/ into /var/cache?

[Trent W. Buck]

Package: debspawn
Version: 0.2.1-1
Severity: minor

I noticed most of my /var/lib/debspawn is actually an apt cache.

Doesn't that belong in /var/cache/, next apt-cacher-ng and apt? ;-)

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

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

Bug#968204: Removal of packges which depend on GTK2

[Michael Gratton]

On 26 October 2020 01:06:59 Pál Tamás Ács  wrote:
Technically, Gtk2 and Gtk3 are two different toolkits with a similar name. 
It's a completely different thing that Red Hat is trying to make us believe 
that GTK3 is an improved successor of GTK2. It isn't. It never has been.


GTK3 has been very much unstable, full of API breaks and annoyances from 
the get-go. It's slower due to CPU bloat under certain circumstances, eats 
up more RAM and is suffering from a serious UX dumbing down to the level of 
consumer devices like smartphones thus being made less suitable for 
desktop. Anti-features like mandatory recursive search in File Dialog have 
also been introduced.


GTK3 was marked stable in many distros despite it wasn't stable at all. 
Software creators and package maintainers didn't want to migrate to a 
poorly designed, underdeveloped, buggy graphical toolkit. They either moved 
forward to Qt or stayed with Gtk2. A famous precedent case is the cancelled 
GTK3 migration of Audacious. They went back to Gtk2 then moved forward 
toward Qt.


There must be a cooperation among Linux maintainters outside of Red Hat to 
save Gtk2 and provide security updates and some critical bug fixes on the 
maintainer level


Can you please take your conspiracy theories, mis-information and 
top-posting elsewhere, like /dev/null? Thanks.


— Mike

Bug#972898: hplip: no network scanner detection with 3.20.9

[Ahzo]

Package: hplip
Version: 3.20.9+dfsg0-4
Severity: important
Tags: patch

Dear Maintainer,

hplip version 3.20.9 replaced the custom mDNS implementation for scanner 
discovery (protocol/discovery/mdns.c) with using avahi 
(protocol/discovery/avahiDiscovery.c).
While this is a welcome change in principle, unfortunately the new code does 
not work.

The main problem is that it does not wait until all callbacks are called before 
stopping via avahi_simple_poll_quit.
Thus there is a 50/50 chance whether the '_scanner._tcp.local' or the 
'_uscan._tcp.local' mDNS reply gets processed (in the browse_callback) and it 
is practically impossible that any scanner gets processed (in the 
resolve_callback), because avahi_simple_poll_quit is called when the first mDNS 
reply has been processed.
It seems like this code was never really tested with an actual scanner on the 
network.

Attached is a patch fixing this by implementing a check_terminate function 
similar to the one used by avahi-browse.

The second problem is that the code expects the 'ty' part of the mDNS reply, 
which contains the device name, to start with 'HP'. However this is not always 
the case.
Previous versions of hplip would simply remove the first three letters of the 
scanner name and continue, which could be worked around by also removing these 
three letters in the models.dat. That issue has been reported two years ago 
upstream without response from HP. (see: 
https://bugs.launchpad.net/hplip/+bug/1797501)
The new code however  discards the scanner if its 'ty' name does not start with 
'HP', breaking that workaround.
Fortunately, since the new code now uses avahi, a proper fix is relatively 
simple: If the 'ty' part of the mDNS response does not start with 'HP', check 
whether the 'mfg' part does.

The second attached patch implements this fix.

While debugging this I also noticed that the log level for one message is 
wrong, causing spurious errors to be reported.

The third attached patch changes the log level for this message from BUG to DBG 
to fix this.

I hope HP solves this eventually, but until then please include these patches 
in the Debian package, so that scanner detection works again.

Thanks in advance,
Ahzo

PS: I tried to report this upstream, but my Launchpad login attempts always 
fail, because "something just went wrong in Launchpad".

>From 67dbad25f503e1d8c6794efba3f17718c77848ea Mon Sep 17 00:00:00 2001
From: Ahzo 
Date: Sun, 25 Oct 2020 22:17:04 +0100
Subject: [PATCH 1/3] avahiDiscovery: wait for all callbacks

When calling avahi_simple_poll_quit too early, not all callbacks will be called.
---
 protocol/discovery/avahiDiscovery.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/protocol/discovery/avahiDiscovery.c b/protocol/discovery/avahiDiscovery.c
index 8d325ffc0..395aec088 100644
--- a/protocol/discovery/avahiDiscovery.c
+++ b/protocol/discovery/avahiDiscovery.c
@@ -28,6 +28,7 @@ char ipAddressBuff[MAX_IP_ADDR_LEN]={'\0'};
 static int aBytesRead = 0;
 static AvahiSimplePoll *aSimplePoll = NULL;
 static int aMemAllocated = 0;
+static int n_all_for_now = 0, n_resolving = 0;
 
 /*
 This function will fill the dictionary arguments for the dbus function call
@@ -237,6 +238,15 @@ static bool getHPScannerModel(AvahiStringList *iStrList, const char *ikey,char *
 return aValueFound;  
 }
 
+static void check_terminate() {
+
+assert(n_all_for_now >= 0);
+assert(n_resolving >= 0);
+
+if (n_all_for_now <= 0 && n_resolving <= 0)
+avahi_simple_poll_quit(aSimplePoll);
+}
+
 /*
 This function will gets called whenever a service has been resolved successfully or timed out
 */
@@ -300,6 +310,9 @@ static void resolve_callback(
 }
 }
 //avahi_service_resolver_free(r);
+assert(n_resolving > 0);
+n_resolving--;
+check_terminate();
 }
 /* Called whenever a new services becomes available on the LAN or is removed from the LAN */
 static void browse_callback(
@@ -337,11 +350,14 @@ static void browse_callback(
 
 if (!(avahi_service_resolver_new(c, interface, protocol, name, type, domain, AVAHI_PROTO_INET, (AvahiLookupFlags)0, resolve_callback, c)))
 BUG( "Failed to resolve service '%s': %s\n", name, avahi_strerror(avahi_client_errno(c)));
+else
+n_resolving++;
 
 break;
 
 case AVAHI_BROWSER_ALL_FOR_NOW:
- avahi_simple_poll_quit(aSimplePoll);
+ n_all_for_now--;
+ check_terminate();
  break;
 }
 }
@@ -444,6 +460,7 @@ static void avahi_setup(const int iCommandType, const char* iHostName)
 goto fail;
 }
}
+   n_all_for_now++;
 
/* Create the service browser */
if (!(sb = avahi_service_browser_new(client, AVAHI_IF_UNSPEC, AVAHI_PROTO_INET, "_scanner._tcp", NULL, (AvahiLookupFlags)0, browse_callback, client))) 
@@ -451,6 +468,7 @@ static void avahi_setup(const int 

Bug#685506: debian-policy: Please add field Files-Excluded to machine readable copyright files definition

[Joe Nahmias]

Hello,

I really miss the mention of Files-Excluded in CF1.0 and when searching
found this bug.

On Fri, Feb 15, 2019 at 02:12:37PM -0700, Sean Whitton wrote:
> Hello,
> 
> Contrary to an older e-mail in this bug, the consensus among the Policy
> Editors is that we can add new, optional fields to the copyright-format
> spec without bumping its version number.  This is because the addition
> of optional fields is backwards compatible.
> 
> I have not read the whole thread, but a quick scan suggests that all we
> are waiting for here is for someone to write a patch against current
> Policy's master branch.

Is this truly the case that all that's needed is a new patch? Can we get
an official ACK from one of the policy editors? I'd be happy to re-write
the original patch to apply against HEAD if that's all that is required.

--Joe


signature.asc
Description: PGP signature

Bug#972885: emacs: Bundled Gnus unable to enter any group

[Florent Rougon]

retitle 972885 Lexical binding causes regression for gnus-summary-highlight
thanks

The problem appears to be due to the (presumably recent) use of lexical
binding in /usr/share/emacs/27.1/lisp/gnus/gnus-sum.el.gz
(cf. lexical-binding:t on the first line).

It is triggered by this piece of configuration from my .gnus.el:

(eval-after-load "gnus-sum"
  '(add-to-list
'gnus-summary-highlight
'((memq article gnus-newsgroup-processable)
  . flo-gnus-summary-processable-face)))

This code nicely highlights lines in the *Summary* buffer corresponding
to articles that have the process mark set. It has worked perfectly for
years until the aforementioned Emacs upgrade.

The problem can be solved either by me not using the above configuration
bit anymore (which is of course a regression), or by making the
`article' variable use dynamic binding before the failing `funcall' in
`gnus-summary-highlight-line' (see the attached patch; the change could
probably be done earlier in the function, along with the other similar
defvar's, but I've only tested the attached patch).

Regards

-- 
Florent
--- patch/gnus-sum.el.orig	2020-10-26 02:19:24.938566201 +0100
+++ patch/gnus-sum.el	2020-10-26 02:20:18.062310644 +0100
@@ -12834,6 +12834,7 @@
 	 (uncached (and gnus-summary-use-undownloaded-faces
 (memq article gnus-newsgroup-undownloaded)
 (not (memq article gnus-newsgroup-cached)
+(defvar article)
 (let ((face (funcall (gnus-summary-highlight-line-0
   (unless (eq face (gnus-get-text-property-excluding-characters-with-faces beg 'face))
 	(gnus-put-text-property-excluding-characters-with-faces

Bug#972901: nvidia-kernel-dkms: Nvidia driver won't compile

[mando]

Package: nvidia-kernel-dkms
Version: 450.66-1
Severity: important
X-Debbugs-Cc: ma...@april.org

Dear Maintainer,

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

   * What led up to the situation?

I upgrade my debian and tried to install nvidia-kernel-dkms on a freshly 
updated debian.

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

I ran apt install nvidia-kernel-dkms.

   * What was the outcome of this action?

Running apt install nvidia-kernel-dkms fails (see compilation errors below).

   * What outcome did you expect instead?

The compilation should not fails or the unmet dependencies (if any) should be 
added to the package.


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


-- Package-specific info:
uname -a:
Linux aldur 5.9.0-1-amd64 #1 SMP Debian 5.9.1-1 (2020-10-17) x86_64 GNU/Linux

/proc/version:
Linux version 5.9.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.0-15) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 
5.9.1-1 (2020-10-17)

lspci 'display controller [030?]':
00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 620 
(Whiskey Lake) [8086:3ea0] (rev 02) (prog-if 00 [VGA controller])
DeviceName: VGA
Subsystem: ASUSTeK Computer Inc. UHD Graphics 620 (Whiskey Lake) 
[1043:1b2e]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

02:00.0 3D controller [0302]: NVIDIA Corporation GP108M [GeForce MX150] 
[10de:1d12] (rev a1)
DeviceName: Second VGA
Subsystem: ASUSTeK Computer Inc. GP108M [GeForce MX150] [1043:1b2e]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw+ 1 root video  226,   0 Oct 26 01:21 /dev/dri/card0
crw-rw+ 1 root render 226, 128 Oct 26 01:21 /dev/dri/renderD128

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root  8 Oct 26 01:21 pci-:00:02.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Oct 26 01:21 pci-:00:02.0-render -> ../renderD128
video:x:44:mando,vdr

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 May  4 21:44 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   49 May  4 21:43 
/etc/alternatives/glx--libEGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so
lrwxrwxrwx 1 root root   51 May  4 21:44 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root   48 May  4 21:43 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   48 May  4 21:43 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   50 May  4 21:44 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   50 May  4 21:44 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   55 May  4 21:43 
/etc/alternatives/glx--libGLESv1_CM.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so
lrwxrwxrwx 1 root root   55 May  4 21:43 
/etc/alternatives/glx--libGLESv1_CM.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so
lrwxrwxrwx 1 root root   57 May  4 21:44 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   57 May  4 21:44 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   52 May  4 21:43 
/etc/alternatives/glx--libGLESv2.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so
lrwxrwxrwx 1 root root   52 May  4 21:43 
/etc/alternatives/glx--libGLESv2.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so
lrwxrwxrwx 1 root root   54 May  4 21:44 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   54 May  4 21:44 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   44 May  4 21:44 
/etc/alternatives/glx--libGLX_indirect.so.0-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0
lrwxrwxrwx 1 root root   44 May  4 21:44 
/etc/alternatives/glx--libGLX_indirect.so.0-x86_64-linux-gnu -> 

Bug#964987: marked as pending in reportbug

[Nis Martensen]

Hi Adam,

On 24.10.2020 21.01, Adam D. Barratt wrote:

reportbug/debbugs.py: Fix crash with stable-pu update request

[...]

 TypeError: not all arguments converted during string formatting

Closes: #964987


Is there an ETA for getting the fix for this issue uploaded? It's been
marked as pending for a few months now, and we've had several queries
on IRC from people trying to file p-u requests and hitting this bug.


Will happen once I have upload permission. (In the next few days.)

Regards,
 Nis

Bug#972166: Rising severities

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Sun, 25 Oct 2020 at 20:34, Yaroslav Halchenko  wrote:
>
> Feel welcome to NMU without delay.  Sorry for being slow etc.
>
> Thank you!

Thanks to you!!!


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#972166: Rising severities

[Yaroslav Halchenko]

Feel welcome to NMU without delay.  Sorry for being slow etc.

Thank you!

On Sun, 25 Oct 2020, Lisandro Damián Nicanor Pérez Meyer wrote:

> severity 972163 serious
> severity 972166 serious
> block 972176 by 972163
> block 972176 by 972166
> thanks

> Hi! We are close to begin the Qt transition that will remove
> qt5-default, so I'm raising the severities.  If everything goes well
> I'll be NMUing your package today with an upload to delayed/5. Of
> course feel free to ping me if needed.

> Thanks, Lisandro.
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik



signature.asc
Description: PGP signature

Bug#972627: Minimal reproducible example

[Steven Robbins]

On Wednesday, October 21, 2020 9:09:54 A.M. CDT Benjamin Eikel wrote:
> Package: googletest
> Version: 1.10.0.20201018-1
> Followup-For: Bug #972627
> 
> Here is a minimal example that can be used to reproduce the problem:

Thanks!  That's extremely helpful.


> Building with `g++ -std=c++20 test.cpp -lgmock_main -lgmock -lgtest
> -pthread` and version 1.10.0.20201018-1 leads to:
> 
> ```
> /usr/bin/ld: /tmp/ccgTGXuD.o: in function `Test_test_Test::TestBody()':
> test.cpp:(.text+0x68): undefined reference to
> `testing::Matcher >
> >::Matcher(std::basic_string_view >)'
> collect2: error: ld returned 1 exit status
> ```
> 
> Using the same command, but version 1.10.0-3 works.

Yes, confirmed.  I'm not sure yet why there is a difference.  However, I can 
offer a workaround: compile googletest and googlemock yourself.  It's a one-
liner:

g++ -std=c++20 test.cpp -I /usr/src/googletest/googletest -I /usr/src/
googletest/googlemock /usr/src/googletest/googlemock/src/gmock_main.cc /usr/
src/googletest/googlemock/src/gmock-all.cc /usr/src/googletest/googletest/src/
gtest-all.cc -pthread

Meanwhile, I'll continue to investigate.
-Steve


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

Bug#774129: dpkg-buildpackage: Should set the cross build profile automatically

[Elliott Mitchell]

(sending a second copy to the body of the message since
<774...@bugs.debian.orgg> didn't quite work)
retitle 774129 dpkg-buildpackage: Should set the cross build profile 
automatically
severity 774129 normal
quit

Setting the "cross" build profile could be the difference between a
successful cross package build and a build failure.  As such I believe
this rates a normal bug as the -a/-t options are effectively broken right
now.

Stating in the man page "-Pcross" must be used if -a or -t is used might
turn this minor, though I really think the full solution should be aimed
for.



As stated in my last message, I also think setting the cross profile
should cause "noocaml" and potentially a few other no profiles to be set.
This would both simplify supporting cross-building (since packages
wouldn't need to detect the cross profile at every point the noocaml
profile is detected).  This would also make a future transition when
OCAML became cross build-friendly simpler since some packages wouldn't
need further adjustment to work, and those which did need adjustment
would cause bug reports mentioning the situation.


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

Bug#972900: pychess has an unlisted dependency on python3-sqlalchemy

[Brian Vaughan]

Package: pychess
Version: 1.0.0-1.1
Severity: important
X-Debbugs-Cc: bgvaug...@gmail.com

When launching pychess from the GUI, pychess immediately exited. When launching
from the commandline:

$ pychess
/usr/games/pychess:17: PyGIWarning: Gtk was imported without specifying a
version first. Use gi.require_version('Gtk', '3.0') before import to ensure
that the right version gets loaded.
  from gi.repository import Gtk, Gdk
ERROR: PyChess requires sqlalchemy to be installed

After installing python3-sqlalchemy, pychess starts as expected.



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

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 pychess depends on:
ii  gaviotatb0.4-2
ii  gir1.2-gdkpixbuf-2.0 2.40.0+dfsg-5
ii  gir1.2-glib-2.0  1.66.1-1
ii  gir1.2-gst-plugins-base-1.0  1.18.0-2
ii  gir1.2-gstreamer-1.0 1.18.0-3
ii  gir1.2-gtk-3.0   3.24.23-2
ii  gir1.2-gtksource-3.0 3.24.11-2
ii  gir1.2-pango-1.0 1.46.2-1
ii  gir1.2-rsvg-2.0  2.50.1+dfsg-1
ii  gnome-icon-theme 3.12.0-3
ii  gobject-introspection1.66.1-1
ii  libgaviotatb10.4-2+b2
ii  python3  3.8.6-1
ii  python3-cairo1.16.2-4+b1
ii  python3-gi   3.38.0-1+b1
ii  python3-gi-cairo 3.38.0-1+b1
ii  python3-websockets   8.1-1

pychess recommends no packages.

pychess suggests no packages.

-- no debconf information

Bug#972899: Package misses a .gemspec and cannot be found as a dependency

[Daniel Leidert]

Package: ruby-net-http-pipeline
Version: 1.0.1-2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The package ships no gemspec and it failing to be recognised as a dependency.


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

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 ruby-net-http-pipeline depends on:
ii  ruby  1:2.7+2

ruby-net-http-pipeline recommends no packages.

ruby-net-http-pipeline suggests no packages.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl+WASoACgkQS80FZ8KW
0F2Y1w//aFSIiju/l4qQltiJfmSboetoItorN9wHAEvCx6xKssF/9pM05yJENhJZ
SymEtBkLwr0VuWFwZltzL4hR9mkkQrKQ0xRV06mrK3/AcDfnM0COIUYhE/dT5lJd
ULDbnWIxePQF6uhalns3n/zZ3udyT0fgG1apPMmDBGTNxE8sEVXbzOcRSNBVUm+K
4Cuy2JAt4pOmMJi7z/uRC/hK0ttZ9Iafgkgcw5azp12fFXFpIgXOf4Z3ORbnm1W9
qH3hY9SeClV3ric+Kg579EHi9mGsPekSPVqkPofg8bBs213dbSJrBjIbvJl2RTKq
Ji268TLL/fQGjtp9W7dGkYqaM/XPlCYZhWqdDiLiRgY56yIZb2gjD5yi1+yHy/aX
mHd11uaINdavN4YqSkQAFZoUz0QMxtVVoZg6q+0BYwg6HYVSWBKVOdewWQLKTQab
yCPBHclGXBHpiOOtmYk1l3+xNWvCvOTC8eePZ4sCNh0u8nGCfG7xUAFPZ50et0xo
K9dx9H0jOJZnH8tC0Zyv/B6HbumSvx9N3C4OMtpg7i5czg5ddRTOiV/he2QMmPp4
K9oz3soGrrqPfDXYAabuy3/1jq4T1Z4kvKl07S8b8txXjsMGL2kgbhlnVvRg+mv4
g34/JG6iXYuNLPQqJDx+e3aCzeW00ZUmkEtKZ8SNZWrZ+1Ug5YE=
=2DQf
-END PGP SIGNATURE-

Bug#942391: poppler-utils: pdfinfo Jessie crash (double free)

[Markus Koschany]

Hello,

thanks for reporting. Although this issue is no longer relevant in
Debian because it is fixed in Stretch and later releases, I have found
the root cause in Jessie and just addressed it. The patch for
CVE-2018-13988 introduced a regression which is the reason why pdfinfo
will segfault with the provided pdf file. I believe it is best to not
the change the code because it successfully protects users from this
specific kind of malformed pdf documents. The original issue is of low
priority anyway and there seems to be no real evidence that it really
triggers a buffer overflow.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#972348: closed by Craig Small (Re: Bug#972348: procps: [sysctl] /etc/sysctl.d should supersede /lib and /usr/lib)

[Matthew Gabeler-Lee]

On Mon, 19 Oct 2020, Craig Small wrote:


On Mon, 19 Oct 2020 at 15:51, Matthew Gabeler-Lee 
wrote:


Aah, no, I can't, that's my point. Because /etc/sysctl.d/ is read before
package-shipped files, then it doesn't matter what file I put it in, it
will still be overridden by package-shipped files in (/usr)/lib.


Did you test this?


I thought I did, and the results I thought I got seemed to match up with 
the documentation: /usr/lib overrides /etc. But it seems that my "test" 
was faulty and the documentation is confusing.


The documentation states the order the directories are read in, but the 
files do not seem to be applied in that order at all. Instead the files 
seem to be applied in order of their base name, and the directory order 
is only used to de-duplicate files with the same base name. I would have 
never figured that out from reading this paragraph in the documentation:


Files are read from directories in the following list in given order 
from top to bottom.  Once a file of a given filename is loaded, any 
file of the same name in subsequent directories is ignored.


That says to me that it processes everything from the first directory, 
and then everything that doesn't have an overlapping name from the 
second directory, and so on, but that is _not_ what it does at all, as 
your example demonstrates.


The "test" then got confused because some pacakges (tracker-miner-fs is 
the one that tripped me up) run selective sysctl updates in their 
postinst, leaving the system in an inconstent state after an apt 
upgrade.


--
-- Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE  77C5 16AF 1460 4A3C C4E9

Bug#972896: libgs9-common: please relax the dependency on fonts-urw-base35

[Jonas Smedegaard]

Quoting Fabian Greffrath (2020-10-25 21:58:30)
> the fonts-urw-base35 is currently stuck in unstable and not allowed to 
> migrate to testing because the ghostscript package currently suffers 
> from a completely unrelated RC bug. This is because the libgs9-common 
> package has an overly strict dependecy on fonts-urw-base35:
> 
> Depends: fonts-urw-base35 (<< 20170801.1.0~), fonts-urw-base35 (>= 20170801.1)
> 
> Thus, the font package is punished for a bug in ghostscript that's not
> even related to the font at all. Please relax the dependency to just
> the "fonts-urw-base35 (>= 20170801.1)" part so that newer versions of
> the font than the one the ghostscript package was built with are
> allowed to migrate to testing.

It seems to me that the concrete delay is caused by ghostscript in 
_testing_ having tight dependency on the font, and that it therefore 
cannot be solved by an upload to unstable - only by ghostscript 
migrating to testing (or ghostscript getting kicked out of testing).  
That said, relaxing the dependency would avoid similar delays in the 
future.

Regardless of what exactly is fixed when, I am not convinced that it is 
wise to relax the dependency:

The reason for the tight dependency is to ensure the integrity of the 
symlinking between the font package and Ghostscript.  It is resolved by 
dh_linktree which explains it like this in its man page:

> Since symlink trees are created statically at build-time, they are not 
> very future-proof and have a risk to miss some files introduced by a 
> newer version of the package providing the file tree which is 
> duplicated. That's why the generated dependencies generally ensure 
> that the same upstream version be used at run-time than at build-time.


Sorry, I do understand how it is frustrating for the font to be held 
ransom by another package like this.


 - Jonas

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

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

signature.asc
Description: signature

Bug#972832: dialog: can't change menu border lines

[Ennio-Sr]

In reply to:
> 
> From: Thomas Dickey 
> To: 972...@bugs.debian.org
> Cc: 972832-submit...@bugs.debian.org
> Subject: Re: Bug#972832: dialog: can't change menu border lines
> Date: Sun, 25 Oct 2020 16:27:13 -0400
> 
> [Message part 1
> 
> (text/plain, inline)]
> 
> On Sat, Oct 24, 2020 at 06:17:39PM +0200, Ennio-Sr wrote:
> > Package: dialog
> > Version: 1.3-20160828-2
> > Severity: minor
> >
> > Hi all!
> >
> > As I like to work on virtual console with black background, when I try to
> > use dialog with my personalized colors (and a .dialogrc file) the 'upper
> > left inner box'  and 'lower right external box' lines appear as black
> > lines on white background, whereas the remaining lines come out on a black
> > background as the whole dialog background.
> > Deleting the .dialogrc file the corner lines are still in differnet
> > colors, but on the same 'grey' background.
> 
> I'd start by seeing if this option helps:
> 
>--no-shadow
>   Suppress  shadows that would be drawn to the right and bottom of
>   each dialog box.
> 
> -- 
> Thomas E. Dickey
> https://invisible-island.netftp://ftp.invisible-island.net

Thanks for your reply! 
Unluckily the --no-shadow option doesn't solve the problem as my
foreground is black.
But, if I delete the .dialogrc file the whole screen foreground is
blue. In this case I can see that the --no-shadow eliminates the right
end corner (black) shadow but not the problem described above.

Afaic understand, in the dialog structure the border lines are written
as 'black on white fg' which does not go well on my black background.
Perhaps I should modify some of the dialog sources files but I don't
know how and which one to adjust...

Regards,
  Ennio

PS: If necessary I could send a copy of the script I'm testing with an
abridged .dialogrc. But where to send it? As an attachement or within a
massage (with '<< EOF - EOF')?

-- 
[Perché usare Win$ozz (dico io) se ..."anche uno sciocco sa farlo.  \\?//
 Fà qualche cosa di cui non sei capace!"  (diceva Henry Miller) (°|°)
[Why use Win$ozz (I say) if ... "even a fool can do that.   .)=(. 
 Do something you aren't good at!" (as Henry Miller used to say)]  /_\ 

Bug#972897: libavformat58: provide libavformat-extra package now?

[Fabian Greffrath]

Package: libavformat58
Version: 7:4.3.1-4
Severity: wishlist

Hi there,

is there any reason why we don't yet provide an additional
libavformat-extra package which could contain support for the SMB
protocol? We already do so for libavcodec-extra and libavfilter-extra,
so I don't see any reason why we shouldn't add another -extra flavor
to provide for a popular feature. The next possible opportunity could
be the next SONAME bump in one of the libraries when we have to go
through the NEW queue anyway.

Thoughts?

Cheers,

 - Fabian


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

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

Versions of packages libavformat58 depends on:
ii  libavcodec58 7:4.3.1-4
ii  libavutil56  7:4.3.1-4
ii  libbluray2   1:1.2.0-3
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-4
ii  libchromaprint1  1.5.0-1
ii  libgme0  0.6.3-2
ii  libgnutls30  3.6.15-4
ii  libopenmpt0  0.4.11-1
ii  librabbitmq4 0.10.0-1
ii  libsrt1-gnutls   1.4.1-5+b1
ii  libssh-gcrypt-4  0.9.4-1
ii  libxml2  2.9.10+dfsg-6.1
ii  libzmq5  4.3.3-2+b1
ii  zlib1g   1:1.2.11.dfsg-2

libavformat58 recommends no packages.

libavformat58 suggests no packages.

-- no debconf information

Bug#790303: [Pkg-net-snmp-devel] Bug#790303: snmpd: "snmpd" fails to "restart" during "logrotate" if it is too busy

[Graham Inggs]

Hi Craig

On Sun, 25 Oct 2020 at 23:03, Craig Small  wrote:
>   In snmpd version 5.7.3+dfsg-2 the init script was changed to follow the 
> standard LSB init setup.  This has retries built into it (or the 
> start-stop-daemon does anyway).  So I suspect this has been fixed, although 
> not in the way mentioned in the bug report.  Before I close this bug off, are 
> you asking to clean up old bugs or are you having the same issue?

I recently heard from a friend experiencing this issue, which led me
to this bug report.

Regards
Graham

Bug#972394: likely cause: Python.h not found because of version mismatch 3.8 vs 3.9

[Adrian Bunk]

On Sun, Oct 25, 2020 at 10:22:47PM +0100, Stephen Sinclair wrote:
> On Wed, Oct 21, 2020 at 10:39 AM Adrian Bunk  wrote:
> >
> > Control: retitle -1 siconos FTBFS with more than one supported python3 
> > version
> >
> > On Mon, Oct 19, 2020 at 11:38:42PM +0200, Markus Koschany wrote:
> > >
> > > I built siconos in a clean chroot environment. The recent rebuild of
> > > siconos also shows build failures
> > >
> > > https://buildd.debian.org/status/package.php?p=siconos
> > >
> > > I don't think it's specific to my environment.
> >
> > You need something like python3-dev -> python3-all-dev in the build
> > dependencies.
> 
> I can confirm that making this change allows the package to build.
> However, some Python-related tests in autopkgtest fail when trying to
> import the Siconos python modules, so something still needs to be
> fixed.  I will investigate.
> As for this change, however, is it the correct one to make?  Or should
> I wait for more information in #972551?
> 
> > The next problem is what it builds - it then builds for the highest
> > version only, not for the default version.
> 
> Can I ask how you determined this?
>...

I ran debdiff between the package in the archive and the package
I built myself.

The lack of 3.8 modules in the package also explains your problem.

> regards,
> Steve

cu
Adrian

Bug#972886: dash: printf %b '\000' # does not produce NUL in output

[Flavio Poletti]

Il giorno dom 25 ott 2020 alle ore 20:27 Flavio Poletti 
ha scritto:

> Package: dash
> Version: 0.5.8-2.4
> Severity: normal


It occurred to me that there might be no bug report and still this might
have been solved in more recent versions of the package.

I then got an updated version of Debian 10 with dash 0.5.10.2-5 inside and
lo and behold! My examples are working fine.

So... apologies for the noise and keep up with the good work!

Regards,

Flavio.

Bug#972394: likely cause: Python.h not found because of version mismatch 3.8 vs 3.9

[Stephen Sinclair]

On Wed, Oct 21, 2020 at 10:39 AM Adrian Bunk  wrote:
>
> Control: retitle -1 siconos FTBFS with more than one supported python3 version
>
> On Mon, Oct 19, 2020 at 11:38:42PM +0200, Markus Koschany wrote:
> >
> > I built siconos in a clean chroot environment. The recent rebuild of
> > siconos also shows build failures
> >
> > https://buildd.debian.org/status/package.php?p=siconos
> >
> > I don't think it's specific to my environment.
>
> You need something like python3-dev -> python3-all-dev in the build
> dependencies.

I can confirm that making this change allows the package to build.
However, some Python-related tests in autopkgtest fail when trying to
import the Siconos python modules, so something still needs to be
fixed.  I will investigate.
As for this change, however, is it the correct one to make?  Or should
I wait for more information in #972551?

> The next problem is what it builds - it then builds for the highest
> version only, not for the default version.

Can I ask how you determined this?  It is not surprising that
something could be wrong, as the CMake configuration is very
complicated in this package.
However, the configure step includes the line,

-DPYTHON_EXECUTABLE=$(shell which python3)"

which should specify the path to the default Python interpreter.  Is
there a better way to determine this path?

> This bug could be solved by either adjusting the build dependencies
> and the build to build for all supported python3 versions, or by fixing
> whatever in the build system does not use the default version.

I would prefer the latter as the package is already quite complicated
and does not play well with multiple pythons.

regards,
Steve

Bug#971015: RFS: vim-ultisnips/3.1-3.1 [NMU] [RC] -- snippet solution for Vim

[Nicholas Guriev]

On Wed, 30 Sep 2020 08:17:15 +0200 Tobias Frost  wrote:
> Did you talk with the maintainer about that change and he ACKED it?
> 
> Otherwise it is inappropiate. For once, it was collab-maint before, so it 
> should
> be the Debian namespace. Also, Michael is not member of the new
> repo, so he would loose access.
> 
> If you want to have it in the vim team, you need to either an ACK by Michael 
> or
> do an ITS.

I have no permission to create new projects under "debian" namespace.
Can you please move or reimport the repository? Does it still matter
since Michael Fladischer, current maintainer, does not mind adopting the
package?

While I was trying to keep changes as little as possible, things get
harder without active VCS. So I had to modify link to Git in the
d/control file. Former repository on alioth was deleted and not
functioning anymore. So I think at Michael point of view, access rights
do not change.

Sorry for late response, I did not receive your message in my inbox and
just now saw it at bugs.d.o site.



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

Bug#972896: libgs9-common: please relax the dependency on fonts-urw-base35

[Fabian Greffrath]

Package: libgs9-common
Version: 9.52.1~dfsg-1
Severity: important

Hi there,

the fonts-urw-base35 is currently stuck in unstable and not allowed to
migrate to testing because the ghostscript package currently suffers
from a completely unrelated RC bug. This is because the libgs9-common
package has an overly strict dependecy on fonts-urw-base35:

Depends: fonts-urw-base35 (<< 20170801.1.0~), fonts-urw-base35 (>= 20170801.1)

Thus, the font package is punished for a bug in ghostscript that's not
even related to the font at all. Please relax the dependency to just
the "fonts-urw-base35 (>= 20170801.1)" part so that newer versions of
the font than the one the ghostscript package was built with are
allowed to migrate to testing.

Thanks!

 - Fabian


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

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

Versions of packages libgs9-common depends on:
ii  fonts-urw-base35  20170801.1-3

Versions of packages libgs9-common recommends:
ii  fonts-droid-fallback  1:6.0.1r16-1.1

libgs9-common suggests no packages.

-- no debconf information

Bug#790303: [Pkg-net-snmp-devel] Bug#790303: snmpd: "snmpd" fails to "restart" during "logrotate" if it is too busy

[Craig Small]

Hi Graham,
  In snmpd version 5.7.3+dfsg-2 the init script was changed to follow the
standard LSB init setup.  This has retries built into it (or the
start-stop-daemon does anyway).  So I suspect this has been fixed, although
not in the way mentioned in the bug report.  Before I close this bug off,
are you asking to clean up old bugs or are you having the same issue?

- Craig


On Sun, 25 Oct 2020 at 06:18, Graham Inggs  wrote:

> Is this fix really still pending?
>
> ___
> Pkg-net-snmp-devel mailing list
> pkg-net-snmp-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-net-snmp-devel

Bug#946205: jsunit: autopkgtest times out without the right version of thunderbird

[Paul Gevers]

Hi,

On Thu, 5 Dec 2019 12:21:51 +0100 Paul Gevers  wrote:
> Since thunderbird 1:68.2.1-1 entered unstable the autopkgtest of your
> package started to fail because it times out (after 2:47h) on
> ci.debian.net in testing, except for runs where both thunderbird
> 1:68.2.1-1 and jsunit 0.2.2-2 were installed. To me, it looks like there
> is a missing versioned (test) dependency missing somewhere, but in any
> case I would appreciate it when the time out is prevented in case of
> such a miss-match.
> 
> Can you please investigate the situation? Don't hesitate to ask for help
> from the Debian CI team (in X-Debbugs-CC) if you need help solving this
> issue.
> 
> If the situation doesn't change in a week or two I may blacklist this
> package on the ci.debian.net infrastructure. If that happens I will
> remove the blacklist once this bug is fixed. If needed, please ping
> me to try any uploads you make that should fix the issue if you are
> unsure and don't want to close this bug until verified.

This is happening again. Now with thunderbird/1:78.3.3-1 and jsunit 0.2.2-2.

Your autopkgtest also fails on amd64, armhf and i386 by the way.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#972832: dialog: can't change menu border lines

[Thomas Dickey]

On Sat, Oct 24, 2020 at 06:17:39PM +0200, Ennio-Sr wrote:
> Package: dialog
> Version: 1.3-20160828-2
> Severity: minor
> 
> Hi all!
> 
> As I like to work on virtual console with black background, when I try to
> use dialog with my personalized colors (and a .dialogrc file) the 'upper
> left inner box'  and 'lower right external box' lines appear as black
> lines on white background, whereas the remaining lines come out on a black
> background as the whole dialog background.
> Deleting the .dialogrc file the corner lines are still in differnet
> colors, but on the same 'grey' background.

I'd start by seeing if this option helps:

   --no-shadow
  Suppress  shadows that would be drawn to the right and bottom of
  each dialog box.

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


signature.asc
Description: PGP signature

Bug#972514: nvidia-kernel-dkms: fails to build with linux-headers-5.9.0-1-amd64

[Heinz Repp]

I too confirm the bug with my Debian testing setup and Linux 5.9.0-1. In 
message #30 Rob points out that nvidia-kernel-dkms 455.23.04-1 works, 
and I can confirm this too. You won't find it in unstable (this has the 
same 450.66-1 as testing), but in experimental. Do not forget to install 
all other nvidia dependencies also from experimental.


So for the time being: grab the whole nvidia files from experimental, 
and then you will be able to use the 5.9 kernel. Guess they should 
accelerate the propagation to unstable and then to testing pretty soon, 
as the 5.9 kernel installed per default else breaks all nvidia owners/users.


Heinz

Bug#821037: adt-virt-lxc: leaves used containers behind

[Paul Gevers]

Hi all,

On Sun, 22 Mar 2020 12:17:08 +0100 Paul Gevers  wrote:
> We're seeing this quite a lot currently on our ci.d.n infrastructure,
> and maybe also on Ubuntu's infra, as reported in bug #908193 (I'm not
> sure if that is actually a duplicate or different.)

Another example:

https://ci.debian.net/data/autopkgtest/testing/amd64/o/openjdk-15/7742200/log.gz

jaxp SKIP exit status 77 and marked as skippable
autopkgtest [19:39:42]: ERROR: "rm -rf
/tmp/autopkgtest-lxc.9db11r52/downtmp/jaxp-artifacts
/tmp/autopkgtest-lxc.9db11r52/downtmp/autopkgtest_tmp" failed with
stderr "rm: cannot remove
'/tmp/autopkgtest-lxc.9db11r52/downtmp/autopkgtest_tmp/hotspot/JTwork':
Directory not empty
"

I checked the worker, it had a tree in /tmp with (however, this is
probably from another run):
admin@ci-worker05:/tmp/autopkgtest-lxc._w5283nq/downtmp/autopkgtest_tmp/hotspot/JTwork$
ls -al
total 24
drwxr-xr-x  6 admin admin 4096 Oct 25 15:55 .
drwxr-xr-x  3 admin admin 4096 Oct 25 15:55 ..
drwxr-xr-x  3 admin admin 4096 Oct 25 15:55 classes
drwxr-xr-x 11 admin admin 4096 Oct 25 15:55 runtime
drwxr-xr-x  3 admin admin 4096 Oct 25 15:55 scratch
drwxr-xr-x 12 admin admin 4096 Oct 25 15:55 serviceability

There was one lxc present:
admin@ci-worker05:~$ sudo lxc-ls -f
NAMESTATE   AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED
autopkgtest-oldstable-amd64 STOPPED 0 -  --false
autopkgtest-stable-amd64STOPPED 0 -  --false
autopkgtest-testing-amd64   STOPPED 0 -  --false
autopkgtest-unstable-amd64  STOPPED 0 -  --false
ci-298-ba5278af STOPPED 0 -  --false

But I could not start it:admin@ci-worker05:~$ sudo lxc-start ci-298-ba5278af
lxc-start: ci-298-ba5278af: lxccontainer.c: wait_on_daemonized_start:
851 Received container state "ABORTING" instead of "RUNNING"
lxc-start: ci-298-ba5278af: tools/lxc_start.c: main: 329 The container
failed to start
lxc-start: ci-298-ba5278af: tools/lxc_start.c: main: 332 To get more
details, run the container in foreground mode
lxc-start: ci-298-ba5278af: tools/lxc_start.c: main: 335 Additional
information can be obtained by setting the --logfile and --logpriority
options
admin@ci-worker05:~$ sudo lxc-start ci-298-ba5278af --foreground
lxc-start: ci-298-ba5278af: start.c: proc_pidfd_open: 1619 Function not
implemented - Failed to send signal through pidfd

 lxc-start:
ci-298-ba5278af: utils.c: safe_mount: 1225 Permission denied - Failed to
mount "proc" onto "/proc"

  lxc-start: ci-298-ba5278af: conf.c:
lxc_mount_auto_mounts: 728 Permission denied - Failed to mount "proc" on
"/proc" with flags 14

lxc-start: ci-298-ba5278af: conf.c: lxc_setup:
3561 Failed to setup first automatic mounts
  lxc-start:
ci-298-ba5278af: start.c: do_start: 1311 Failed to setup container
"ci-298-ba5278af"
 lxc-start: ci-298-ba5278af: sync.c: __sync_wait: 62 An
error occurred in another process (expected sequence number 5)
  lxc-start: ci-298-ba5278af: start.c: __lxc_start: 2031 Failed to spawn
container "ci-298-ba5278af"

lxc-start: ci-298-ba5278af:
tools/lxc_start.c: main: 329 The container failed to start
lxc-start: ci-298-ba5278af: tools/lxc_start.c: main: 335 Additional
information can be obtained by setting the --logfile and --logpriority
options


Paul




signature.asc
Description: OpenPGP digital signature

Bug#972895: node-pathval: CVE-2020-7751

[Salvatore Bonaccorso]

Source: node-pathval
Version: 1.1.0-3
Severity: important
Tags: security upstream
Forwarded: https://github.com/chaijs/pathval/pull/58
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for node-pathval.

 * CVE-2020-7751[0]

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-7751
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7751
[1] https://github.com/chaijs/pathval/pull/58
[2] https://snyk.io/vuln/SNYK-JS-PATHVAL-596926

Regards,
Salvatore

Bug#972893: cfengine3 FTCBFS: fails finding libxml2

[Helmut Grohne]

Source: cfengine3
Version: 3.15.2-3
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

cfengine3 gained another use of libxml2 in libntech and that refuses to
use xml2-config during cross builds again. The attached patch fixes it
in the same way as my previous patch. Please consider applying it.

What remains unsolved is the part about manual pages. It's difficult to
fix, because the upstream approach is fundamentally incompatible with
cross builds. One solution violating a policy should is splitting manual
pages into a cfengine3-doc package which happens to be Architecture:
all. Policy says that manual pages should be included.

So please just fix the libxml2 part and close this bug when doing so.

Helmut
Index: cfengine3-3.15.2/libntech/configure.ac
===
--- cfengine3-3.15.2.orig/libntech/configure.ac	2020-05-31 15:37:42.0 +0200
+++ cfengine3-3.15.2/libntech/configure.ac	2020-10-25 07:59:48.138071540 +0100
@@ -584,7 +584,7 @@
 fi
 
 # xml2-config is only for native builds
-if test "x$cross_compiling" = "xno" && test x`which $XML2_CONFIG` != x
+if test x`which $XML2_CONFIG` != x
 then
 xml2_include_dir=`$XML2_CONFIG --cflags`
 if test -n "$xml2_include_dir"

Bug#972891: pam-mysql FTCBFS: fails finding mysql libraries

[Helmut Grohne]

Source: pam-mysql
Version: 0.8.1-2
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

pam-mysql fails to cross build from source, because it fails finding
mysql libraries. It tries to do so using mysql_config, but mysql_config
does not work during cross compilation at all. Instead, pkg-config
should be used. The attached patch implements pkg-config-based detection
and inserts it after mysql_config, but before searching hard coded
locations. As such any previous detection is retained while supporting
cross compilation via pkg-config. Please consider applying the attached
patch.

Helmut
--- pam-mysql-0.8.1.orig/m4/pam-mysql.m4
+++ pam-mysql-0.8.1/m4/pam-mysql.m4
@@ -163,84 +163,94 @@
   AC_MSG_CHECKING([if] $1 [is a mysql_config script])
 
   _cfg="$1"
-  if test -x "$_cfg" -a -r "$_cfg" -a -f "$_cfg"; then
+  AS_IF([test -x "$_cfg" -a -r "$_cfg" -a -f "$_cfg"],[
 dnl $1 may be a path to mysql_config
 AC_MSG_RESULT([yes])
 AC_DEFINE([HAVE_MYSQL_H], [1], [Define to `1' if you have the  header file.])
 mysql_config="$1"
-  else
+  ],[
 AC_MSG_RESULT([no])
-mysql_lib_path=
-mysql_include_path=
-mysql_lib_name=mysqlclient
-
-for _pfx in $1; do
-  _cfg="$_pfx/bin/mysql_config"
 
-  AC_MSG_CHECKING([mysql_config availability in $_pfx/bin])
+PKG_CHECK_MODULES([MYSQLCLIENT],[mysqlclient],[
+  mysql_pkg_config=yes
+  AC_DEFINE([HAVE_MYSQL_H], [1], [Define to `1' if you have the  header file.])
+],[
+  mysql_pkg_config=no
+  mysql_lib_path=
+  mysql_include_path=
+  mysql_lib_name=mysqlclient
 
-  if test -x "$_cfg" -a -r "$_cfg" -a -f "$_cfg"; then
-AC_MSG_RESULT([yes])
-AC_DEFINE([HAVE_MYSQL_H], [1], [Define to `1' if you have the  header file.])
-mysql_config="$_cfg"
-break
-  else
-AC_MSG_RESULT([no])
-  fi
+  for _pfx in $1; do
+_cfg="$_pfx/bin/mysql_config"
 
-  for dir in "$_pfx/lib" "$_pfx/lib/mysql"; do
-AC_MSG_CHECKING([$mysql_lib_name availability in $dir])
-name="$mysql_lib_name"
+AC_MSG_CHECKING([mysql_config availability in $_pfx/bin])
 
-if eval test -e "$dir/$libname_spec$shrext_cmds" -o -e "$dir/$libname_spec.$libext"; then
+if test -x "$_cfg" -a -r "$_cfg" -a -f "$_cfg"; then
   AC_MSG_RESULT([yes])
-
-  AC_MSG_CHECKING([$dir/$name usability])
-  ac_save_LIBS="$LIBS"
-  LIBS="$LIBS -L$dir"
-  AC_CHECK_LIB([$mysql_lib_name], [mysql_init], [
-AC_MSG_RESULT([yes])
-mysql_lib_path="$dir"
-  ], [
-AC_MSG_RESULT([no])
-  ])
-  LIBS="$ac_save_LIBS"
-
-  if test ! -z "$mysql_lib_path"; then
-break
-  fi
+  AC_DEFINE([HAVE_MYSQL_H], [1], [Define to `1' if you have the  header file.])
+  mysql_config="$_cfg"
+  break
 else
   AC_MSG_RESULT([no])
 fi
-  done
 
-  for dir in "$_pfx/include" "$_pfx/include/mysql"; do
-AC_MSG_CHECKING([mysql headers availability in $dir])
-if test -e "$dir/mysql.h"; then
-  AC_MSG_RESULT([yes])
-  AC_MSG_CHECKING([mysql headers usability])
-  ac_save_CPPFLAGS="$CPPFLAGS"
-  CPPFLAGS="$CPPFLAGS -I$dir"
-  AC_CHECK_HEADER([mysql.h], [
+for dir in "$_pfx/lib" "$_pfx/lib/mysql"; do
+  AC_MSG_CHECKING([$mysql_lib_name availability in $dir])
+  name="$mysql_lib_name"
+
+  if eval test -e "$dir/$libname_spec$shrext_cmds" -o -e "$dir/$libname_spec.$libext"; then
 AC_MSG_RESULT([yes])
-AC_DEFINE([HAVE_MYSQL_H], [1], [Define to `1' if you have the  header file.])
-mysql_include_path="$dir"
-  ], [
+
+AC_MSG_CHECKING([$dir/$name usability])
+ac_save_LIBS="$LIBS"
+LIBS="$LIBS -L$dir"
+AC_CHECK_LIB([$mysql_lib_name], [mysql_init], [
+  AC_MSG_RESULT([yes])
+  mysql_lib_path="$dir"
+], [
+  AC_MSG_RESULT([no])
+])
+LIBS="$ac_save_LIBS"
+
+if test ! -z "$mysql_lib_path"; then
+  break
+fi
+  else
 AC_MSG_RESULT([no])
-  ])
-  CPPFLAGS="$ac_save_CPPFLAGS"
+  fi
+done
 
-  if test ! -z "$mysql_include_path"; then
-break
+for dir in "$_pfx/include" "$_pfx/include/mysql"; do
+  AC_MSG_CHECKING([mysql headers availability in $dir])
+  if test -e "$dir/mysql.h"; then
+AC_MSG_RESULT([yes])
+AC_MSG_CHECKING([mysql headers usability])
+ac_save_CPPFLAGS="$CPPFLAGS"
+CPPFLAGS="$CPPFLAGS -I$dir"
+AC_CHECK_HEADER([mysql.h], [
+  AC_MSG_RESULT([yes])
+  AC_DEFINE([HAVE_MYSQL_H], [1], [Define to `1' if you have the  header file.])
+  

Bug#972892: 4g8 FTCBFS: configures for the build architecture

[Helmut Grohne]

Source: 4g8
Version: 1.0-3.3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

4g8 fails to cross build from source, because it does not pass --host to
./configure. The easiest way of doing so - using dh_auto_configure -
makes 4g8 cross buildable. Please consider applying the attached patch.

Helmut
diff -u 4g8-1.0/debian/changelog 4g8-1.0/debian/changelog
--- 4g8-1.0/debian/changelog
+++ 4g8-1.0/debian/changelog
@@ -1,3 +1,10 @@
+4g8 (1.0-3.4) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass --host to ./configure. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 24 Oct 2020 16:03:35 +0200
+
 4g8 (1.0-3.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u 4g8-1.0/debian/rules 4g8-1.0/debian/rules
--- 4g8-1.0/debian/rules
+++ 4g8-1.0/debian/rules
@@ -21,7 +21,7 @@
# Add here commands to compile the package.
cp /usr/share/misc/config.guess /usr/share/misc/config.sub .
chmod u+x ./configure
-   $(shell dpkg-buildflags --export=cmdline) ./configure --prefix=/usr 
--mandir=/usr/share/man
+   $(shell dpkg-buildflags --export=cmdline) dh_auto_configure
$(MAKE)
 
touch build-stamp

Bug#972890: tcpreplay: CVE-2020-24265

[Salvatore Bonaccorso]

Source: tcpreplay
Version: 4.3.3-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/appneta/tcpreplay/issues/616
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for tcpreplay.

CVE-2020-24265[0]:
| An issue was discovered in tcpreplay tcpprep v4.3.3. There is a heap
| buffer overflow vulnerability in MemcmpInterceptorCommon() that can
| make tcpprep crash and cause a denial of service.


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-24265
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24265
[1] https://github.com/appneta/tcpreplay/issues/616

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#972889: tcpreplay: CVE-2020-24266

[Salvatore Bonaccorso]

Source: tcpreplay
Version: 4.3.3-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/appneta/tcpreplay/issues/617
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for tcpreplay.

CVE-2020-24266[0]:
| An issue was discovered in tcpreplay tcpprep v4.3.3. There is a heap
| buffer overflow vulnerability in get_l2len() that can make tcpprep
| crash and cause a denial of service.


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-24266
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24266
[1] https://github.com/appneta/tcpreplay/issues/617

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#972888: libclutter-perl: Deprecated upstream

[intrigeri]

Source: libclutter-perl
Severity: serious
User: debian-p...@lists.debian.org
Usertags: rm-candidate

Hi,

upstream announced¹ that the Clutter Perl module would be deprecated
in December 2020. It is actually already archived on their GitLab,
so:

 - The module will no longer be updated with security patches, bug
   fixes, or when changes are made in the Perl ABI.

 - It will no longer be possible to submit new issues or pull requests
   for these modules, or push new changes to their Git repos.

Therefore, I don't think we should ship this package in Bullseye.

Any objection to removing the package from testing & sid?

This is a leaf package and popcon is 0/9 (vote/inst).

[1] https://mail.gnome.org/archives/gtk-perl-list/2020-October/msg2.html

Bug#972651: buster-pu: package fastd/18-3+deb10u1

[Sven Eckelmann]

On Saturday, 24 October 2020 20:37:36 CET Adam D. Barratt wrote:
> Please go ahead.

Thanks, uploaded [1] with appended CVE in the changelog.

Kind regards,
Sven

[1] 
https://release.debian.org/proposed-updates/buster_diffs/fastd_18-3+deb10u1.debdiff

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

Bug#972887: libgstreamer1-perl: Deprecated upstream

[intrigeri]

Source: libgstreamer1-perl
Severity: serious
X-Debbugs-Cc: Mike Gabriel 
User: debian-p...@lists.debian.org
Usertags: rm-candidate

Hi,

upstream announced¹ that the GStreamer Perl module would be deprecated
and archived in December 2020:

 - The module will no longer be updated with security patches, bug
   fixes, or when changes are made in the Perl ABI.

 - It will no longer be possible to submit new issues or pull requests
   for these modules, or push new changes to their Git repos.

Therefore, I don't think we should ship this package in Bullseye.

Any objection to removing the package from testing & sid?

This is a leaf package and popcon is 4/19 (vote/inst).

[1] https://mail.gnome.org/archives/gtk-perl-list/2020-October/msg2.html

Bug#972514: nvidia-kernel-dkms: fails to build with linux-headers-5.9.0-1-amd64

[Wellington Almeida]

https://forums.developer.nvidia.com/t/nvidia-driver-not-yet-supported-for-linux-kernel-5-9/157263

Em qui, 22 de out de 2020 12:49, Matthias Cramer 
escreveu:

> I have the same problem.
>
>

Bug#972875: lintian: fix override usage detection for renamed tags

[Felix Lechner]

Hi Thorsten,

On Sun, Oct 25, 2020 at 12:35 PM Thorsten Glaser  wrote:
>
> I figured so, but the original message malformed-override was bogus.

The message was not bogus. Your override referred to a non-existing
tag, and the 'malformed' message simply said so.

Kind regards
Felix Lechner

Bug#972844: lintian: E: musescore2 source: malformed-override Unknown tag testsuite-autopkgtest-missing in line 5

[Thorsten Glaser]

Felix Lechner dixit:

>"wide-character" Perl warning?

No, the first few lines of lintian’s output are literally:

N: Using profile debian/main.
N: Starting on group musescore2/2.3.2+dfsg3-10
N: Finished processing group musescore2/2.3.2+dfsg3-10
E: musescore2 source: malformed-override Unknown tag 
testsuite-autopkgtest-missing in line 5
N:
E: malformed-override

bye,
//mirabilos

Bug#972886: dash: printf %b '\000' # does not produce NUL in output

[Flavio Poletti]

Package: dash
Version: 0.5.8-2.4
Severity: normal

Dear Maintainer,

I was trying out various examples in article "Rich's sh (POSIX shell)
tricks" and the example in section "Writing bytes to stdout by numeric
value" failed. It was working in Mac OS X /bin/sh.

The error arised when trying to print out a NUL byte.

The following examples will help show what the bug is about:

$ printf %b '\0074\0101\0076' | hexdump -c
000   <   A   >
003
$ printf %b '\0074\0001\0076' | hexdump -c
000   < 001   >
003
$ printf %b '\0074\\0076' | hexdump -c
000   <
001
$ perl -e 'print "<\x{0}>"' | hexdump -c
000   <  \0   >
003

The first two commands work as expected: all three octets are printed on
the standard output, as shown by the output from hexdump.

The third and the last command are expected to yield the same result,
but the one based on printf does not comply and stops processing the
input as soon as it reaches the \ string, which is also dropped from
the output.

I scanned through the list of bugs but found none about this specific
issue.

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

Kernel: Linux 4.9.0-7-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dash depends on:
ii  debianutils  4.8.1.1
ii  dpkg 1.18.25
ii  libc62.24-11+deb9u3

dash recommends no packages.

dash suggests no packages.

-- debconf information:
* dash/sh: true

Bug#972858: zim FTBFS: FileNotFoundError: [Errno 2] No such file or directory: '/run/user/2952'

[Raphael Hertzog]

FWIW, this is really a bug in the build daemon that should not
set XDG_RUNTIME_DIR to some incorrect value:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842565

But I'll work around it in the mean time.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#972885: emacs: Bundled Gnus unable to enter any group

[Florent Rougon]

Package: emacs
Version: 1:27.1+1-2
Severity: normal

Hello,

After upgrading my emacs packages today:

   [UPGRADE] emacs:amd64 1:26.3+1-2 -> 1:27.1+1-2
   [UPGRADE] emacs-bin-common:amd64 1:26.3+1-2 -> 1:27.1+1-2
   [UPGRADE] emacs-bin-common-dbgsym:amd64 1:26.3+1-2 -> 1:27.1+1-2
   [UPGRADE] emacs-common:amd64 1:26.3+1-2 -> 1:27.1+1-2
   [UPGRADE] emacs-el:amd64 1:26.3+1-2 -> 1:27.1+1-2
   [UPGRADE] emacs-gtk:amd64 1:26.3+1-2 -> 1:27.1+1-2
   [UPGRADE] emacs-gtk-dbgsym:amd64 1:26.3+1-2 -> 1:27.1+1-2

Gnus bundled with Emacs 27 can't enter any group anymore (from the
*Group* buffer). If I try to enter a group, I get the following error:

  Symbol's value as variable is void: article

Here is a backtrace of the error:

Debugger entered--Lisp error: (void-variable article)
  #f(compiled-function () #)()
  funcall(#f(compiled-function () #))
  (let ((face (funcall (gnus-summary-highlight-line-0 (if (eq face 
(gnus-get-text-property-excluding-characters-with-faces beg 'face)) nil 
(gnus-put-text-property-excluding-characters-with-faces beg (point-at-eol) 
'face (setq face (if (boundp face) (symbol-value face) face))) (if 
gnus-summary-highlight-line-function (progn (funcall 
gnus-summary-highlight-line-function article face)
  (let* ((beg (point-at-bol)) (article (or (gnus-summary-article-number) 
gnus-current-article)) (score (or (cdr (assq article gnus-newsgroup-scored)) 
gnus-summary-default-score 0)) (mark (or (let ((cl-x (gnus-data-find-in ... 
gnus-newsgroup-data))) (progn (progn (nth 1 cl-x gnus-unread-mark)) 
(inhibit-read-only t) (default gnus-summary-default-score) (default-high 
gnus-summary-default-high-score) (default-low gnus-summary-default-low-score) 
(uncached (and gnus-summary-use-undownloaded-faces (memq article 
gnus-newsgroup-undownloaded) (not (memq article gnus-newsgroup-cached) (let 
((face (funcall (gnus-summary-highlight-line-0 (if (eq face 
(gnus-get-text-property-excluding-characters-with-faces beg 'face)) nil 
(gnus-put-text-property-excluding-characters-with-faces beg (point-at-eol) 
'face (setq face (if (boundp face) (symbol-value face) face))) (if 
gnus-summary-highlight-line-function (progn (funcall 
gnus-summary-highlight-line-function article face))
  gnus-summary-highlight-line()
  gnus-summary-insert-line([0 "" "" "05 Apr 2001 23:33:09 +0400" "" "" 0 0 "" 
nil] 0 nil t 90 t nil "" nil 1)
  gnus-update-summary-mark-positions()
  gnus-summary-setup-buffer("nnml+mail:AUCTeX")
  gnus-summary-read-group-1("nnml+mail:AUCTeX" nil t nil nil nil)
  gnus-summary-read-group("nnml+mail:AUCTeX" nil t nil nil nil nil)
  gnus-group-read-group(nil t)
  gnus-group-select-group(nil)
  gnus-topic-select-group(nil)
  funcall-interactively(gnus-topic-select-group nil)
  call-interactively(gnus-topic-select-group nil nil)
  command-execute(gnus-topic-select-group)

This happens when `gnus-summary-highlight-line' from
/usr/share/emacs/27.1/lisp/gnus/gnus-sum.el.gz calls the byte-compiled
function that `gnus-summary-highlight-line-0' evaluates to. I've used my
nnml+mail:AUCTeX group as an example here, but this happens with all
groups I've tried. Hence, I can't read any mail with this version of the
emacs package. :-|

Thanks for your work!

Regards

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

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

Versions of packages emacs depends on:
ii  emacs-gtk  1:27.1+1-2

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Bug#972869: RFA: fmtlib

[Alexis Murzeau]

Hi,

On Sun, 25 Oct 2020 16:07:37 +0100 "Eugene V. Lyubimkin"  
wrote:
> Package: wnpp
> Severity: normal
> 
> Hello,
> 
> This package needs a more responsive maintainer. I unfortunately haven't
> had enough time for months and this is unlikely to change in the near
> future.
> 
> fmtlib is a modern C++ library, it provides fast and type-safe
> replacement of (s)printf and related machinery.
> 
> What needs to be done:
>  - package a new upstream release;
>  - solve a (documentation-related) FTBFS;
>  - potentially make a shared library instead of a static library.
> 
> 
> Regards,
> -- 
> Eugene V. Lyubimkin
> C++ GNU/Linux userspace developer, Debian Developer
> 
> 

Do you have an existing VCS repository somewhere for that package ?

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|



signature.asc
Description: OpenPGP digital signature

Bug#954655: apparmor autopkgtest doesn't work nice on ci.d.n infrastructure

[Paul Gevers]

Hi intrigeri,

On 25-10-2020 19:44, intrigeri wrote:
> This being said, this was a while ago, and I wonder if the problem got
> somehow fixed in one of those packages in the meantime. Could you
> please give it another try with 2.13.5-1 (sid) or 3.0.0-1
> (experimental), and ideally both? This would establish an updated
> baseline for further investigation.

Scheduled on amd64. Note however that I reported that the test didn't
always fail, so if it passes, it's not saying for sure that everything
is OK.

>>> Is there a better way for me to investigate?
> 
>> We have given DD's temporarily access to one of our workers before. If
>> you're interested we could do that again for this case. That way you
>> could even skip the upload to experimental, assuming it reproduces if
>> run from a local tree. And you can check what's going on in the test bed.
> 
> This looks great. I'd like to do this once the updated baseline is
> established, if it still fails. I could book time for this on Nov
> 28-29.

Can you can already point me at your public key? Easiest is with a
signed e-mail, but if it's otherwise easily traceable it's from you, I
can take it from elsewhere.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#972872: apt.systemd.daily should vary exit code based on unattended-upgrades failures

[Julian Andres Klode]

On Sun, Oct 25, 2020 at 04:09:23PM +, Filippo Giunchedi wrote:
> Package: apt
> Version: 1.8.2.1
> Severity: normal
> 
> Hi,
> I've ran into a situation where an unattended-upgrades run would fail to
> upgrade packages on an host. I'm using the u-u APT integration, thus u-u is
> called via /usr/lib/apt/apt.systemd.daily and its corresponding service+timer.
> 
> Even on a failed u-u run the apt-daily-upgrade.service unit is still reported 
> a
> successful, AFAICT because apt.systemd.daily exits 0 even when u-u fails. I
> think it makes sense to surface u-u errors back and thus fail the systemd
> service, does that seem reasonble? What do you think re: surfacing other 
> errors
> as well?

We need a substantial rework of exit logic and introduce retry to the
whole service.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#954655: apparmor autopkgtest doesn't work nice on ci.d.n infrastructure

[intrigeri]

Hi,

Paul Gevers (2020-05-25):
> The most obvious alternative is that your run it locally, but I guess
> you tried and couldn't reproduce?

I usually use the libvirt backend but I tried today with the lxc
backend locally, and could not reproduce. Note I don't see this
problem on Salsa CI either.

I took a closer look and the problem happens after successfully
running the compile-policy test. I can't imagine how what this test
does can interfere with shutting down the container, *but* that test
installs a bunch of packages:

  apparmor, apparmor-profiles-extra, bind9, cups-browsed, cups-daemon,
  evince, haveged, kopano-dagent, kopano-server, libreoffice-common,
  libvirt-daemon-system, man-db, ntp, onioncircuits, tcpdump, tor

I suspect one of those failed to stop within the 600s timeout in the
ci.d.n environment.

This being said, this was a while ago, and I wonder if the problem got
somehow fixed in one of those packages in the meantime. Could you
please give it another try with 2.13.5-1 (sid) or 3.0.0-1
(experimental), and ideally both? This would establish an updated
baseline for further investigation.

>> Is there a better way for me to investigate?

> We have given DD's temporarily access to one of our workers before. If
> you're interested we could do that again for this case. That way you
> could even skip the upload to experimental, assuming it reproduces if
> run from a local tree. And you can check what's going on in the test bed.

This looks great. I'd like to do this once the updated baseline is
established, if it still fails. I could book time for this on Nov
28-29.

Cheers!

Bug#972514: nvidia-kernel-dkms: fails to build with linux-headers-5.9.0-1-amd64

[Rob Oosterling]

On Sat, 24 Oct 2020 18:32:10 +0200 Alexander Heinlein <
alexander.heinl...@web.de> wrote:
> 
> Installing nvidia-kernel-dkms from unstable (455.23.04-1) works.
> 
Yes, that does work, but 455.23.04-1 does not provide a working OpenCl
with kernel 5.9 (it does with 5.8).

Bug#972844: lintian: E: musescore2 source: malformed-override Unknown tag testsuite-autopkgtest-missing in line 5

[Felix Lechner]

Hi Thorsten,

On Sun, Oct 25, 2020 at 11:23 AM Thorsten Glaser  wrote:
>
> Ehm, but I’m running unstable and reported it against the version
> in unstable.

Yes, you are using a newer Perl version. Did you see a
"wide-character" Perl warning?

Kind regards
Felix Lechner

Bug#972305: catch2: FTBFS with DEB_BUILD_OPTIONS=reproducible=+fixfilepath

[Mathieu Mirmont]

control: tag -1 confirmed
control: tag -1 pending

On Thu, Oct 15, 2020 at 05:08:09PM -0700, Vagrant Cascadian wrote:

The attached patch works around this issue by disabling the fixfilepath
feature in debian/rules using DEB_BUILD_MAINT_OPTIONS=-fixfilepath. 


Thanks, I'm applying it and releasing. I've been scratching my head
about this FTBFS but never had the time to get to the bottom of it. 

Cheers, 


--
Mathieu Mirmont 


signature.asc
Description: PGP signature

Bug#972163: Rising severities

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Sun, 25 Oct 2020 at 15:00, Sylvestre Ledru  wrote:
[snip]
> Please upload your version, it is fine :)

Done! Of course I'll keep an eye on the buildds in case something goes wrong.

Thanks!!!


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#972884: apparmor-profiles: usr.lib.dovecot.stats profile is needed

[Vincas Dargis]

Package: apparmor-profiles
Version: 2.13.2-10
Severity: normal

Dear Maintainer,

AppArmor 2.13.3 got usr.lib.dovecot.stats profile:
https://gitlab.com/apparmor/apparmor/-/commit/36bdd6ea7011455f94106e6ea6d4aad626863815

To make dovecot work on Debian Buster, I need to modify
`/etc/apparmor.d/local/usr.sbin.dovecot` file to add:
```
/usr/lib/dovecot/stats Px,
```
and of course add missing profile.

Is it possible to get this fix for.. stable release?

-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

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

Versions of packages apparmor-profiles depends on:
ii  apparmor  2.13.2-10

apparmor-profiles recommends no packages.

apparmor-profiles suggests no packages.

-- Configuration Files:
/etc/apparmor.d/bin.ping changed [not included]
/etc/apparmor.d/sbin.klogd changed [not included]
/etc/apparmor.d/sbin.syslog-ng changed [not included]
/etc/apparmor.d/sbin.syslogd changed [not included]
/etc/apparmor.d/usr.sbin.avahi-daemon changed [not included]
/etc/apparmor.d/usr.sbin.dnsmasq changed [not included]
/etc/apparmor.d/usr.sbin.identd changed [not included]
/etc/apparmor.d/usr.sbin.mdnsd changed [not included]
/etc/apparmor.d/usr.sbin.nmbd changed [not included]
/etc/apparmor.d/usr.sbin.nscd changed [not included]
/etc/apparmor.d/usr.sbin.smbd changed [not included]
/etc/apparmor.d/usr.sbin.smbldap-useradd changed [not included]
/etc/apparmor.d/usr.sbin.traceroute changed [not included]

-- no debconf information

Bug#972844: lintian: E: musescore2 source: malformed-override Unknown tag testsuite-autopkgtest-missing in line 5

[Thorsten Glaser]

Felix Lechner dixit:

>We are unsure about the last bug, especially because you did not
>report it in unstable (and it would have been hard to miss). The Perl

Ehm, but I’m running unstable and reported it against the version
in unstable. (I was actually seeing this in a cowbuilder buildd
chroot.)

bye,
//mirabilos

Bug#972883: apparmor-profiles: dovecot needs usr.lib.dovecot.script-login profile

[Vincas Dargis]

Package: apparmor-profiles
Version: 2.13.2-10
Severity: normal
Tags: upstream

Dear Maintainer,

Debian Buster,Bullseye needs usr.lib.dovecot.script-login, which was addred not
long ago [0].

I'll work for backport to AppArmor 2.13.


[0]
https://gitlab.com/apparmor/apparmor/-/commit/6e59f454b136c4103e5b37e125715dfa8ba7b0bd

*** 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.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

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

Versions of packages apparmor-profiles depends on:
ii  apparmor  2.13.2-10

apparmor-profiles recommends no packages.

apparmor-profiles suggests no packages.

-- Configuration Files:
/etc/apparmor.d/bin.ping changed [not included]
/etc/apparmor.d/sbin.klogd changed [not included]
/etc/apparmor.d/sbin.syslog-ng changed [not included]
/etc/apparmor.d/sbin.syslogd changed [not included]
/etc/apparmor.d/usr.sbin.avahi-daemon changed [not included]
/etc/apparmor.d/usr.sbin.dnsmasq changed [not included]
/etc/apparmor.d/usr.sbin.identd changed [not included]
/etc/apparmor.d/usr.sbin.mdnsd changed [not included]
/etc/apparmor.d/usr.sbin.nmbd changed [not included]
/etc/apparmor.d/usr.sbin.nscd changed [not included]
/etc/apparmor.d/usr.sbin.smbd changed [not included]
/etc/apparmor.d/usr.sbin.smbldap-useradd changed [not included]
/etc/apparmor.d/usr.sbin.traceroute changed [not included]

-- no debconf information

Bug#972882: linux-image-4.19.0-12-amd64: startx fails

[Damjan]

Package: src:linux
Version: 4.19.152-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
Regular upgrade of linux-image-amd64.

   * What exactly did you do (or not do) that was effective (or ineffective)?
After an upgrade, XWindows don't start. Selecting older linux-image from the
boot menu (4.19.0-11) still works.

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




-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: Gigabyte Technology Co., Ltd.
product_name: A320M-S2H
product_version: Default string
chassis_vendor: Default string
chassis_version: Default string
bios_vendor: American Megatrends Inc.
bios_version: F42
board_vendor: Gigabyte Technology Co., Ltd.
board_name: A320M-S2H-CF
board_version: x.x

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 
Root Complex [1022:15d0]
Subsystem: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Root Complex 
[1022:15d0]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 

00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:08.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 
Internal PCIe GPP Bridge 0 to Bus B [1022:15dc] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller 
[1022:790b] (rev 61)
Subsystem: Gigabyte Technology Co., Ltd FCH SMBus Controller [1458:5001]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

01:00.1 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] Device 
[1022:43b8] (rev 02) (prog-if 01 [AHCI 1.0])
Subsystem: ASMedia Technology Inc. Device [1b21:1062]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: ahci
Kernel modules: ahci

01:00.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device 
[1022:43b3] (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

02:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series 
Chipset PCIe Port [1022:43b4] (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

02:05.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series 
Chipset PCIe Port [1022:43b4] (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- 

Bug#972163: Rising severities

[Sylvestre Ledru]

Le 25/10/2020 à 18:54, Lisandro Damián Nicanor Pérez Meyer a écrit :

Hi Sylvestre!

On Sun, 25 Oct 2020 at 11:20, Lisandro Damián Nicanor Pérez Meyer
 wrote:

Hi!

El dom., 25 oct. 2020 11:07, Sylvestre Ledru  escribió:

Hello,

[snip]

I tried to upload it with your fix but the build failed for me.

If it works for you, please upload (without delay)

many thanks

tl;dr: I could build the package with just my changes, but only using
the uploaded debian source package.

# Building using the salsa repo

I cloned the repo and noticed that apart from the merge of the MR I
created there are other changes to the packaging. I tried building
master's HEAD but autoconf fails almost immediately. I'm afraid I
don't know a thing about it, so I switched to commit
673f53defb054873e40860ba11937860b3266863 (the one in which you accept
my MR) and the build failed with missing installation files more on
this below.
I then switched to tag 5.3.7-4 (which should be "the same thing" as
the last upload to the archive) and got the same error.

See buildlog.xz attached to this mail for the full build log of this
last two cases.

The builds where done in an schroot-managed chroot which is not
exactly clean: it also has git and a few more packages installed in
it, I normally use it for development.

# Building with the package uploaded to the archive

I then tried to build the latest uploaded version to the archive,
fwbuilder_5.3.7-4 using an sbuild chroot. It just went fine. I then
added my changes on top of it and the build succeeded again. So it's
either a difference in my build environment or the packaging and
what's in salsa.

In order to fix this bug I could upload an NMU containing just my
changes, but I don't think I'll be able to also add the ones you added
in the repo.


Please upload your version, it is fine :)

Thanks

S

Bug#972677: deepin-image-viewer: FTBFS with Qt 5.15: error: aggregate ‘QPainterPath path’ has incomplete type and cannot be defined

[Dmitry Shachnev]

Control: tags -1 + pending

On Thu, Oct 22, 2020 at 02:05:20PM +0300, Dmitry Shachnev wrote:
> Dear Maintainer,
>
> deepin-image-viewer fails to build with Qt 5.15, currently available in
> experimental.
>
> After rebuilding dde-qt-dbus-factory and libqtxdg, and building a fixed
> version of dtkwidget (see #972155), I get this error:
>
>   widgets/popupmenustyle.cpp: In member function ‘virtual void 
> PopupMenuStyle::drawPrimitive(QStyle::PrimitiveElement, const QStyleOption*, 
> QPainter*, const QWidget*) const’:
>   widgets/popupmenustyle.cpp:117:22: error: aggregate ‘QPainterPath path’ has 
> incomplete type and cannot be defined
> 117 | QPainterPath path;
> |  ^~~~
>   widgets/popupmenustyle.cpp:133:13: error: ‘QPainterPathStroker’ was not 
> declared in this scope; did you mean ‘QPainterPath’?
> 133 | QPainterPathStroker stroker;
> | ^~~
> | QPainterPath
>   widgets/popupmenustyle.cpp:134:13: error: ‘stroker’ was not declared in 
> this scope; did you mean ‘strtok_r’?
> 134 | stroker.setWidth(FRAME_BORDER_WIDTH);
> | ^~~
> | strtok_r
>   widgets/popupmenustyle.cpp:136:26: error: variable ‘QPainterPath 
> borderPath’ has initializer but incomplete type
> 136 | QPainterPath borderPath = stroker.createStroke(path);
> |  ^~
>
>   widgets/thumbnaillistview.cpp: In member function ‘virtual void 
> ThumbnailListView::paintEvent(QPaintEvent*)’:
>   widgets/thumbnaillistview.cpp:301:18: error: aggregate ‘QPainterPath bp’ 
> has incomplete type and cannot be defined
> 301 | QPainterPath bp;
> |  ^~
>
> This is fixed upstream, see the linked commit.

I have just uploaded the NMU fixing this to DELAYED/5.

The debdiff is attached.

--
Dmitry Shachnev
diff -Nru deepin-image-viewer-5.0.0/debian/changelog deepin-image-viewer-5.0.0/debian/changelog
--- deepin-image-viewer-5.0.0/debian/changelog	2019-10-04 18:08:11.0 +0300
+++ deepin-image-viewer-5.0.0/debian/changelog	2020-10-25 20:33:15.0 +0300
@@ -1,3 +1,10 @@
+deepin-image-viewer (5.0.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream patch to fix build with Qt 5.15 (closes: #972677).
+
+ -- Dmitry Shachnev   Sun, 25 Oct 2020 20:33:15 +0300
+
 deepin-image-viewer (5.0.0-1) unstable; urgency=medium
 
   * New upstream release 5.0.0.
diff -Nru deepin-image-viewer-5.0.0/debian/patches/fix-build-failed-under-Qt-5.15.0.patch deepin-image-viewer-5.0.0/debian/patches/fix-build-failed-under-Qt-5.15.0.patch
--- deepin-image-viewer-5.0.0/debian/patches/fix-build-failed-under-Qt-5.15.0.patch	1970-01-01 03:00:00.0 +0300
+++ deepin-image-viewer-5.0.0/debian/patches/fix-build-failed-under-Qt-5.15.0.patch	2020-10-25 20:33:15.0 +0300
@@ -0,0 +1,60 @@
+From: zhangjinqiang 
+Date: Mon, 14 Sep 2020 02:54:58 +
+Subject: fix: build failed under Qt 5.15.0
+
+(cherry picked from commit b11d7cbdcdd99c82e3feff2aac21e28c6a81f7e7)
+---
+ viewer/widgets/dspinner.cpp  | 1 +
+ viewer/widgets/popupmenustyle.cpp| 1 +
+ viewer/widgets/thumbnaildelegate.cpp | 1 +
+ viewer/widgets/thumbnaillistview.cpp | 1 +
+ 4 files changed, 4 insertions(+)
+
+diff --git a/viewer/widgets/dspinner.cpp b/viewer/widgets/dspinner.cpp
+index 2931f3e..ccfae88 100644
+--- a/viewer/widgets/dspinner.cpp
 b/viewer/widgets/dspinner.cpp
+@@ -2,6 +2,7 @@
+ 
+ #include 
+ #include 
++#include 
+ #include 
+ 
+ #include 
+diff --git a/viewer/widgets/popupmenustyle.cpp b/viewer/widgets/popupmenustyle.cpp
+index ddb509c..0fd91f7 100644
+--- a/viewer/widgets/popupmenustyle.cpp
 b/viewer/widgets/popupmenustyle.cpp
+@@ -19,6 +19,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ 
+diff --git a/viewer/widgets/thumbnaildelegate.cpp b/viewer/widgets/thumbnaildelegate.cpp
+index 64bd65e..1a09702 100644
+--- a/viewer/widgets/thumbnaildelegate.cpp
 b/viewer/widgets/thumbnaildelegate.cpp
+@@ -23,6 +23,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ #include 
+diff --git a/viewer/widgets/thumbnaillistview.cpp b/viewer/widgets/thumbnaillistview.cpp
+index f27fa22..cb7e015 100644
+--- a/viewer/widgets/thumbnaillistview.cpp
 b/viewer/widgets/thumbnaillistview.cpp
+@@ -30,6 +30,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ #include 
diff -Nru deepin-image-viewer-5.0.0/debian/patches/series deepin-image-viewer-5.0.0/debian/patches/series
--- deepin-image-viewer-5.0.0/debian/patches/series	1970-01-01 03:00:00.0 +0300
+++ deepin-image-viewer-5.0.0/debian/patches/series	2020-10-25 20:33:15.0 +0300
@@ -0,0 +1 @@
+fix-build-failed-under-Qt-5.15.0.patch


signature.asc
Description: PGP signature

Bug#972867: CharLS should have changed its SOVERSION

[Mathieu Malaterre]

Control: tags -1 upstream

For details:

https://github.com/team-charls/charls/issues/81

Bug#969114: apparmor-profiles: usr.sbin.dovecot does not allow reading /usr/share/dovecot/dh.pem (dovecot fails to start)

[Vincas Dargis]

I think it's for upstream. There's more rules to add too. I'll try to work on 
that.

On 2020-10-24 16:05, intrigeri wrote:

Hi Vincas!

Vincas Dargis (2020-08-27):

This is produced if usr.sbin.dovecot is copied to /etc/apparmor.d:

```
type=AVC msg=audit(1598556536.092:901): apparmor="DENIED" operation="open" profile="dovecot" 
name="/usr/share/dovecot/dh.pem" pid=12625 comm="doveconf" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
```

This results in dovecot failing to start:

```
Aug 27 22:31:47 systemd[1]: Started Dovecot IMAP/POP3 email server.
Aug 27 22:31:47 dovecot[13693]: doveconf: Fatal: Error in configuration file 
/etc/dovecot/conf.d/10-ssl.conf line 50: ssl_dh: Can't open file /usr/share/dove
Aug 27 22:31:47 systemd[1]: dovecot.service: Main process exited, code=exited, 
status=89/n/a
Aug 27 22:31:47 systemd[1]: dovecot.service: Failed with result 'exit-code'.
```

It is fixed by adding single rule:

```
/usr/share/dovecot/dh.pem r,
```


Do you think it's too Debian-specific to fix upstream?

Cheers!

Bug#972879: tor: fail to start if the ipv6 addr is not yet assigned

[Domenico Andreoli]

Package: tor

A friend of mine has a relay that receives the ipv6 address from the
router but needs to specify it in the torrc file, they are not aware
of any other way of configuring an ipv6 relay.

There is a window of time during boot when the ipv6 address is not
assigned yet, if tor is started in such window it then fails to bind
to the configured ipv6 address and the execution is aborted.

Almost every time they reboot the relay they then need to restart the
tor daemon manually in order to bind and announce properly on the net.

It should be possible to configure systemd so that the tor daemon is
started only after the ipv6 address has been assigned.

-- 
rsa4096: 3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA  356E CC79 2832 ED38 CB05

Bug#972844: lintian: E: musescore2 source: malformed-override Unknown tag testsuite-autopkgtest-missing in line 5

[Felix Lechner]

Control: clone -1 -2 -3
Control: retitle -1 lintian: mark tag as renamed to missing-tests-control
Control: retitle -2 lintian: fix override usage detection for renamed tags
Control: retitle -3 lintian: Wide character in say at Lintian::Output line 156

Hi Thorsten,

On Sat, Oct 24, 2020 at 4:39 PM Thorsten Glaser  wrote:
>
> I’ve been recompiling musescore2_2.3.2+dfsg3-10.dsc (currently
> in sid) on latest sid

On Debian stable. this package actually triggers three Lintian bugs:

1. The tag testsuite-autopkgtest-missing was renamed to
missing-tests-control, the old name was not recorded properly. This is
remedied quite easily and will result in a 'renamed-tag' warning.
2. The override comes up as unused, but that does not seem to be true.
Your sources do not declare a d/tests/control.
3. At least on stable your override comment for cute-field, "what the
ever…", which contains the Unicode codepoint U+2026 (e2 80 a6)
HORIZONTAL ELLIPSIS, triggers the following warning:

Wide character in say at
/lcl/lechner/lintian/git/bin/../lib/Lintian/Output.pm line 156.
Lintian::Output::msg(Lintian::Output::EWI=HASH(0x5639082d1c60),
"oh really?! what the ever\x{2026}") called at
/lcl/lechner/lintian/git/bin/../lib/Lintian/Output/EWI.pm line 170
Lintian::Output::EWI::print_tag(Lintian::Output::EWI=HASH(0x5639082d1c60),
Lintian::Tag::Standard=HASH(0x56390e6ec1d0)) called at
/lcl/lechner/lintian/git/bin/../lib/Lintian/Output/EWI.pm line 113
Lintian::Output::EWI::issue_tags(Lintian::Output::EWI=HASH(0x5639082d1c60),
ARRAY(0x56391071feb8)) called at
/lcl/lechner/lintian/git/bin/../lib/Lintian/Pool.pm line 286
Lintian::Pool::process(Lintian::Pool=HASH(0x5639082d2378),
Lintian::Profile=HASH(0x56390955ace0), SCALAR(0x563909616fc0),
HASH(0x56390960a388), GLOB(0x563909692948),
Lintian::Output::EWI=HASH(0x5639082d1c60)) called at bin/lintian line
758
N: oh really?! what the ever…
O: musescore2 source: cute-field debian/control@source VCS-git vs Vcs-Git

We are unsure about the last bug, especially because you did not
report it in unstable (and it would have been hard to miss). The Perl
folks are telling us it is probably a bug in Perl. The output layer
"encoding:uft-8" is active on the handle being printed to. We are at a
loss for now.

This bug is being cloned and retitled to deal with each of the
described conditions. Thanks for bringing them to our attention.

> lintian output has
> become less reliable and more hard to parse in the last few
> months…

I disagree with that broad condemnation. As a community project that
touches the lives of many contributors, Lintian accepted bug fixes in
many wrong places. The ripples you see stem from a careful but
difficult reshuffling of decades of hard work into a modern code base.

Lintian is no longer multi-threaded, and when that is accounted for,
the software runs better and faster than ever. It will also be much
easier to maintain (and contribute to) going forward.

Kind regards
Felix Lechner

Bug#972809: dracut-core: Acts on /boot/initramfs-... instead of /boot/initrd... by default

[Antonio Russo]

Hello,

On 10/25/20 4:03 AM, Thomas Lange wrote:

Thanks for the patch. But when I tried to apply it on my local machine
it failed. Can you please check this

[snip]

Hmm... it looks like 050+65-1 isn't on salsa, only 050+35-4 (and that's
what the patch is based on).

If you push 050+65-1 to salsa and ping me, I'll rebase on that.

Antonio


OpenPGP_0xB01C53D5DED4A4EE.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#972874: django-ldapdb 1.5.1-1 fails its autopkgtest

[Ryan Tandy]

Source: django-ldapdb
Version: 1.5.1-1
Severity: serious

Dear Maintainer,

The autopkgtest of django-ldapdb 1.5.1-1 fails in testing and unstable.

https://ci.debian.net/data/autopkgtest/testing/amd64/d/django-ldapdb/7719338/log.gz


django.core.exceptions.ImproperlyConfigured: Requested setting INSTALLED_APPS, 
but settings are not configured. You must either define the environment 
variable DJANGO_SETTINGS_MODULE or call settings.configure() before accessing 
settings.


I see the same failure in a pure unstable chroot without any packages from 
testing.

Could you please take a look? This is blocking openldap from migrating to 
testing. (https://qa.debian.org/excuses.php?package=openldap)

Thank you,
Ryan

Bug#972873: ITP: fdb -- FDB (Fields DataBase) is a domain-specific object store for storing, indexing and retrieving GRIB data.

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: fdb
  Version : 5.7.0
  Upstream Author : ECMWF (European Centre for Medium-Range Weather Forecasts)
* URL : http://github.com/ecmwf/fdb
* License : Apache 2
  Programming Lang: C++
  Description : FDB (Fields DataBase) is a domain-specific object store for 
storing, indexing and retrieving GRIB data.

FDB (Fields DataBase) is a domain-specific object store developed at ECMWF
for storing, indexing and retrieving GRIB data. Each GRIB message is stored as 
a field and indexed
trough semantic metadata (i.e. physical variables such as temperature, 
pressure, ...).
A set of fields can be retrieved specifying a request using a specific language 
developed for accessing MARS_ Archive

FDB exposes a C++ API as well as CLI tools_.
 
This is to be used by the rest of the ECMWF (European Centre for Medium-Range 
Weather Forecasts)
stack currently on Debian - Metview, etc.

Bug#972788: openjdk-11-jre-dcevm: incompatible with openjdk-11-jre 11.0.9

[tony mancill]

On Fri, Oct 23, 2020 at 05:21:00PM +0200, Michael Meier wrote:
> Package: openjdk-11-jre-dcevm
> Version: 11.0.7+1-1
> Severity: normal
> X-Debbugs-Cc: schissdra...@rmm.li
> 
> my system just upgraded to openjdk-11-jre 11.0.9.
> when starting up java with dcevm support you get following error:
> java --version -dcevm
> Error occurred during initialization of VM
> Unable to load native library: /usr/lib/jvm/java-11-openjdk-
> amd64/lib/libjava.so: undefined symbol: JVM_IsUseContainerSupport, version
> SUNWprivate_1.1
> 
> Downgrading openjdk-11-jre to 11.0.8 makes it work again.
> 
> So the dcevm package is broken (again) for newer java versions.

Thank you for the bug report.

I just uploaded a new upstream version, 11.0.9+1, which will prevent
users from having to downgrade.  I feel like this was warranted given
the CVEs addressed in JDK 11.0.9.  However, there is a more general
issue of dependency version testing (and maybe pinning).  At a minimum,
we can add an autopkgtest to instantiate a JVM with the -dcevm option.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#972872: apt.systemd.daily should vary exit code based on unattended-upgrades failures

[Filippo Giunchedi]

Package: apt
Version: 1.8.2.1
Severity: normal

Hi,
I've ran into a situation where an unattended-upgrades run would fail to
upgrade packages on an host. I'm using the u-u APT integration, thus u-u is
called via /usr/lib/apt/apt.systemd.daily and its corresponding service+timer.

Even on a failed u-u run the apt-daily-upgrade.service unit is still reported a
successful, AFAICT because apt.systemd.daily exits 0 even when u-u fails. I
think it makes sense to surface u-u errors back and thus fail the systemd
service, does that seem reasonble? What do you think re: surfacing other errors
as well?

thank you!
Filippo

Bug#972785: zeromq3: Include cmake files for cppzmq

[GCS]

On Fri, Oct 23, 2020 at 4:57 PM Gordon Ball  wrote:
> src:zeromq3 and libzmq3-dev currently embed headers from the separate
> cppzmq repository. However, the associated cmake files are not included,
> which means when trying to build downstream projects which use cppzmq
> and cmake, it's necessary to hack the buildsystem or embed the cmake
> files from cppzmq.
 These are different projects and should be packaged differently. As
czmq is packaged by Luca, I think cppzmq should be packaged by him as
well. But let's hear what he says.

Regards,
Laszlo/GCS

Bug#972429: djview4: djview4 as a server

[Janusz S. Bień]

On Sun, Oct 25 2020 at 15:27 +00, Barak A. Pearlmutter wrote:
> That's great. If the extension is in Debian, than djview4 could
> "Suggest:" it. Or maybe would could just put appropriate instructions
> in /usr/share/doc/djview4/README.Debian, if you have wording for such
> a paragraph I'm happy to slip it in.

I think the extension is worth a separate package in Debian, but for
djview for a configuration file is needed (cf. the end of the issue
thread). I think it can be distributed with djview, but perhaps you will
ask the author of the extension for an advice?

Regards

Janusz

-- 
 ,   
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien

Bug#972543: apt-file: Apt-update downloads full Contents file, not pdiffs

[Niels Thykier]

calumlikesapple...@gmail.com:
> On Sun, 2020-10-25 at 11:04 +0100, Niels Thykier wrote:
>> Hi again,
>>
>> Thanks for the data.  Unfortunately, it did reveal a smoking gun, so
>> I
>> think we need /tmp/update.log generated from this command.
>>
>>  apt -o Debug::pkgAcquire::Worker=1  \
>> -o Debug::pkgAcquire::Diffs=1 update \
>>   2>&1 | tee /tmp/update.log
> 
> Attached.
> 

Apologies, I should have been more precise.

Please use that command next time you need to run an apt update and when
you get a run where you should have had PDiffs but did not get any, then
submit the log file for that run.
  The log file provided is for a "no-changes" run. Accordingly, I cannot
tell if it skipped PDiffs or not because it concluded there was no need
for an update at all.

>> Please attach the file rather than copy-paste in the output from it.
> 
> Sure! I just wasn't sure if attaching was standard, or if you'd gotten
> my original attachment.
> 

My rule of thumb is more about length and whether the mail programs line
wrap long lines. :)  For mail programs that don't, "short" inline
copy-paste is often nicer, but for long files or zealous line wrapping
attachments are often more readable.

~Niels

Bug#972543: apt-file: Apt-update downloads full Contents file, not pdiffs

[calumlikesapplepie]

On Sun, 2020-10-25 at 11:24 -0400, calumlikesapple...@gmail.com wrote:
> On Sun, 2020-10-25 at 11:04 +0100, Niels Thykier wrote:
> > Hi again,
> > 
> > Thanks for the data.  Unfortunately, it did reveal a smoking gun,
> > so
> > I
> > think we need /tmp/update.log generated from this command.
> > 
> >  apt -o Debug::pkgAcquire::Worker=1  \
> > -o Debug::pkgAcquire::Diffs=1 update \
> >   2>&1 | tee /tmp/update.log
> 
> Attached.
> 
> > Please attach the file rather than copy-paste in the output from
> > it.
> 
> Sure! I just wasn't sure if attaching was standard, or if you'd
> gotten
> my original attachment.

I just realized that I forgot to mention something important: the issue
doesn't happen every time I run apt update, and even sometimes when it
needs to update other files, it doesn't wind up updating the contents.
I'll log my manual updates for the next week (gnome-software sometimes
runs it in the background), in case this log is useless.


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

Bug#972429: djview4: djview4 as a server

[Barak A. Pearlmutter]

That's great. If the extension is in Debian, than djview4 could
"Suggest:" it. Or maybe would could just put appropriate instructions
in /usr/share/doc/djview4/README.Debian, if you have wording for such
a paragraph I'm happy to slip it in.

Cheers,

--Barak.

Bug#972543: apt-file: Apt-update downloads full Contents file, not pdiffs

[calumlikesapplepie]

On Sun, 2020-10-25 at 11:04 +0100, Niels Thykier wrote:
> Hi again,
> 
> Thanks for the data.  Unfortunately, it did reveal a smoking gun, so
> I
> think we need /tmp/update.log generated from this command.
> 
>  apt -o Debug::pkgAcquire::Worker=1  \
> -o Debug::pkgAcquire::Diffs=1 update \
>   2>&1 | tee /tmp/update.log

Attached.

> Please attach the file rather than copy-paste in the output from it.

Sure! I just wasn't sure if attaching was standard, or if you'd gotten
my original attachment.

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

Starting method '/usr/lib/apt/methods/http'
 <- http:100%20Capabilities%0aSend-Config:%20true%0aPipeline:%20true%0aVersion:%201.2
Configured access method http
Version:1.2 SingleInstance:0 Pipeline:1 SendConfig:1 LocalOnly: 0 NeedsCleanup: 0 Removable: 0 AuxRequests: 0
Starting method '/usr/lib/apt/methods/https'
 <- https:100%20Capabilities%0aSend-Config:%20true%0aPipeline:%20true%0aVersion:%201.2
Configured access method https
Version:1.2 SingleInstance:0 Pipeline:1 SendConfig:1 LocalOnly: 0 NeedsCleanup: 0 Removable: 0 AuxRequests: 0
Starting method '/usr/lib/apt/methods/http'
 <- http:100%20Capabilities%0aSend-Config:%20true%0aPipeline:%20true%0aVersion:%201.2
Configured access method http
Version:1.2 SingleInstance:0 Pipeline:1 SendConfig:1 LocalOnly: 0 NeedsCleanup: 0 Removable: 0 AuxRequests: 0
 -> 

Bug#972871: git-el: .el files not installed / byte-compiled

[Zack Weinberg]

Package: git-el
Version: 1:2.28.0-1
Severity: grave
Justification: renders package unusable

While updating my emacs configuration for 27.1 (now in unstable)
I noticed that /etc/emacs/site-start.d/50git-core.el prints

git removed but not purged, skipping setup

and does not autoload either git.el or git-blame.el.  This appears to
be because /usr/lib/emacsen-common/packages/install/git does nothing
when $FLAVOR is “emacs”:

| # The emacs startup file looks for these files in
| # /usr/share/${debian-emacs-flavor}/site-lisp/git.
| # Installing to the generic /usr/share/emacs/site-list/git would be
| # pointless.
| [ "$FLAVOR" != emacs ] || exit 0

This has been incorrect for quite some time - I’m not sure how long
ago it was that (symbol-name debian-emacs-flavor) was changed to
evaluate to “emacs” for the ordinary packages of GNU Emacs, but
probably more than one release by now.

I think a sufficient fix is to remove the above quoted lines from
/usr/lib/emacsen-common/packages/install/git.

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

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

Versions of packages git-el depends on:
ii  emacs1:27.1+1-2
ii  emacs-gtk [emacsen]  1:27.1+1-2
ii  git  1:2.28.0-1

Versions of packages git-el recommends:
ii  elpa-magit  2.99.0.git0957.ge8c7bd03-1

git-el suggests no packages.

-- no debconf information

Bug#972870: Should libhal1-flash be shipped in bullseye?

[Adrian Bunk]

Package: libhal1-flash
Version: 0.3.3-3
Severity: serious
Tags: bullseye sid

This package was needed for older versions of Flash,
which itself is both EOL before the release of bullseye
and already no longer supported by any major browser.

Bug#972429: djview4: djview4 as a server

[Janusz S. Bień]

The problem is solved:

https://github.com/andy-portmen/external-application-button/issues/50

The question is only how to distribute it in Debian.

Regards

Janusz

-- 
 ,   
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien

Bug#972869: RFA: fmtlib

[Eugene V. Lyubimkin]

Package: wnpp
Severity: normal

Hello,

This package needs a more responsive maintainer. I unfortunately haven't
had enough time for months and this is unlikely to change in the near
future.

fmtlib is a modern C++ library, it provides fast and type-safe
replacement of (s)printf and related machinery.

What needs to be done:
 - package a new upstream release;
 - solve a (documentation-related) FTBFS;
 - potentially make a shared library instead of a static library.


Regards,
-- 
Eugene V. Lyubimkin
C++ GNU/Linux userspace developer, Debian Developer

Bug#972556: ffmpeg: Fails to build from source with newer src:srt

[John Paul Adrian Glaubitz]

On 10/25/20 3:04 PM, Sebastian Ramacher wrote:
> I'd be more comfortable with the patch if it was at least merged on
> upstream's master branch.

Upstream isn't responding which would mean the package will remain unfixed in 
Debian
for the next months and I will have to keep pinging both you and upstream which 
would
be rather annoying.

The guaeded code itself is built on powerpc and ppc64 only so there is no risk 
in breaking
any other architecture. Currently, ffmpeg does not build on powerpc and ppc64 
at all which
means I will have to build the package locally with the patch applied everytime 
a new version
or Debian revision of the ffmpeg package gets uploaded which I would rather 
like to avoid.

Adrian

> [1] https://lists.debian.org/debian-sparc/2017/12/msg00060.html

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#972862: swi-prolog: FTBFS with OpenSSL 1.1.1h

[Lev Lamberov]

Hi Kurt,

Вс 25 окт 2020 @ 13:30 Kurt Roeckx :

> Package: swi-prolog
> Version: 8.2.1+dfsg-2
> Severity: serious
>
> Hi,
>
> swi-prolog fails to build using OpenSSL 1.1.1h. See
> https://ci.debian.net/data/autopkgtest/testing/amd64/s/swi-prolog/7715788/log.gz
> for a log.
>
> I've filed an upstream bug about this at:
> https://github.com/SWI-Prolog/packages-ssl/issues/158

Thanks for your report and for submitting it upstream too.

Cheers!
Lev

Bug#958454: From a minimum installation of Sid, metapackage Cinnamon installs neither X nor a login manager

[Fabio Fantoni]

@Daniel Tourde: 'apt install cinnamon' don't install the meta packages
but only the main component and its deps.
For install the meta packages that include login manager as recommends
(that are installed by default) you need install cinnamon-core or for a
additional software for a full desktop use cinnamon-desktop-environment
(same used by tasksel, or simply install cinnamon using tasksel that
include also task-desktop).
When cinnamon was added also in DE selection in debian install I tested
it and was ok, on 4.6 (and probably also 4.4, I not remember good) I not
tested clean install of debian with cinnamon but only upgrade on
existant Sid installation, if for unexpected case something important is
missed please tell me it.

Bug#972868: xkcdpass: TAB-completion after --wordfile completes at directories

[Jonas Smedegaard]

Package: xkcdpass
Version: 1.16.5+dfsg.1-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

When in a bash shell typing "xkcdpass --wordfile /us" and hitting TAB,
it completes to "xkcdpass --wordfile /usr ".

I would expect it to instead expand to "xkcdpass --wordfile /usr/"
to indicate that files exist within that directory but (missing a space)
the expansion is incomplete because the option takes a file as argument.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl+VjKgACgkQLHwxRsGg
ASEcow//WXZdBBGB58+/li2XV2APtm9gf/9gFZYtMbZeLXDq2d9uKPO8qjvK5a7L
fgfsKagNOO569sXbrmXXrWUx3b1qXsnrwX/Se07R2nmIPG7A36kjvbezHqo3t12T
SoVrVfiIMmRtYxKvFdMsjzEpEAPDTjOLWN3rUbGKo8Sajf0Ba/xIw7ij7WNLVmgy
Ck9n4SZgHG4XHOglSCORlZP1hD4M06gzZaPhhRvGKz7EjQWPFZPeG0TO5p/luTsN
+y+srIwTPCEt21KWloe93ZpBG1WzvyUEepU1GsW248k6GUTOexCMwdlfIcOxibqb
QJogpuzAvledf/JFEw5hppS4o1sOVQghg3kCuXbWD2JYLNLtSWuTzIHvzcto7Q/z
VkDoNavChXmaEtHXWJ0TgxsjHyUdZOJTzwNZ+vM+C9RQ2dIFc4gTE6eznhzGRR7/
Yng21/Q1By4KNt6h3p8gfFLhV3SZo4gml6uu+L5JBliifpufYkmygRjyEu/lCexr
kAJxGF6vLjFW3nBJKBgZmw55WnZi3bYlsW5ABbgqNPLj2WsBHeqbLDP7qlAC023b
v4YlIbaxMPTuU4WZLgId9S2YL/tj10a2xYuCE8bapmMKVgb3pmctxc8FfODI5wFO
t+sO1FQEeM0YyJKtMynbkiNI/EuHnJEQy8FKNRDDRMQ8dONULEE=
=Gc4q
-END PGP SIGNATURE-

Bug#972867: gdcm: FTBFS in testing and unstable

[Graham Inggs]

Source: gdcm
Version: 3.0.7-3
Severity: serious
Tags: ftbfs bullseye sid


Hi Maintainer

As per reproducible builds [1], gdcm recently started failing to build
in testing and unstable.

I've copied what I hope is the relevant part of the log below.

Regards
Graham


[1] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gdcm.html


/usr/bin/c++ -DgdcmMSFF_EXPORTS -I../Source/Common -ISource/Common
-I../Source/DataStructureAndEncodingDefinition
-I../Source/DataDictionary -I../Source/InformationObjectDefinition
-I../Source/MediaStorageAndFileFormat -I../Utilities -IUtilities
-I/usr/include/openjpeg-2.3 -I/usr/include/json-c -I/usr/include/json
-g -O2 -ffile-prefix-map=/build/1st/gdcm-3.0.7=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -fPIC -DCHARLS_DLL -MD -MT
Source/MediaStorageAndFileFormat/CMakeFiles/gdcmMSFF.dir/gdcmJPEGLSCodec.cxx.o
-MF 
Source/MediaStorageAndFileFormat/CMakeFiles/gdcmMSFF.dir/gdcmJPEGLSCodec.cxx.o.d
-o 
Source/MediaStorageAndFileFormat/CMakeFiles/gdcmMSFF.dir/gdcmJPEGLSCodec.cxx.o
-c ../Source/MediaStorageAndFileFormat/gdcmJPEGLSCodec.cxx
In file included from
../Source/MediaStorageAndFileFormat/gdcmJPEGLSCodec.cxx:24:
../Utilities/gdcm_charls.h:21:11: fatal error: CharLS/charls.h: No
such file or directory
   21 | # include 
  |   ^
compilation terminated.

Bug#972866: xkcdpass: man page documents non-working option --valid_chars

[Jonas Smedegaard]

Package: xkcdpass
Version: 1.16.5+dfsg.1-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

manpage for xkcdpass documents an option --valid_chars, but that fails.

Instead, option --valid-chars works.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl+VirUACgkQLHwxRsGg
ASEzsg//YA3zma4CNJaJIFXuC+QKQtaWv1X3gBcJ5n3k3Pt01DT+sWD8Dt8lNB39
0ScritVXlHxrifOR4BFYFmtuZtOW6uSKQyhJgXWosGiOpEpeH6CzsmIUuivuXTed
q/F5C9d73Ab2/96NS5ksOhVHXv/A1AjAfhE1o5nmeQOJKPCYcG4TUtZb8ubVSH0C
hFnXOWvd5r1oUtu2ZUf72jho0P1jof6M2D7d8ehzV3TRfaJv7cXJ404H47IPw2/o
7aij2xllg373gr5Mxck8M67pKVSdl8dy2HN3m6RWec8OJOHvRHgLeVAwQ/c2H9z5
SDAPZG2sUDU4gfny0ea05cmJ8l+ONglFljBxUuTPUmsCGCZ1q22S7Esmx0lrATHT
rHWt8tkWzurV6ce+NIfmkJ3hAlLw9ON4itWABEQzMKGxrfiznl8Ur/DeErExuwVD
TV8DORfS4IrHdT5k+QOuE8A6iSYWZsRBN5NoAZktNtbSK0F+OWjIPn113LzcS7Xn
lT/WF3ILyj6OZ8KJzZWo4iF8meBVn9batQs2HOoi6hUu4Y/4Sx/zxlE2A0PAMfKb
po51S5puGr/6kj7hdBhxoosqrDKfIZUALDgMdX9CbPZ3o1EI0+xPeI9hmWGGYGe+
aBSFMAk9HqRLwWPLEJrQmMpu3zHmgjU8Sjs/26HHcQu0jKrAx4Y=
=x6F0
-END PGP SIGNATURE-

Bug#972163: Rising severities

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

El dom., 25 oct. 2020 11:07, Sylvestre Ledru 
escribió:

> Hello,
>
> Le 25/10/2020 à 14:57, Lisandro Damián Nicanor Pérez Meyer a écrit :
> > severity 972163 serious
> > severity 972166 serious
> > block 972176 by 972163
> > block 972176 by 972166
> > thanks
> >
> > Hi! We are close to begin the Qt transition that will remove
> > qt5-default, so I'm raising the severities.  If everything goes well
> > I'll be NMUing your package today with an upload to delayed/5. Of
> > course feel free to ping me if needed.
> >
> > Thanks, Lisandro.
> >
> I tried to upload it with your fix but the build failed for me.
>
> If it works for you, please upload (without delay)
>
> many thanks
>


Great, I'll check the build then! Thanks to you too!

>

Bug#972163: Rising severities

[Sylvestre Ledru]

Hello,

Le 25/10/2020 à 14:57, Lisandro Damián Nicanor Pérez Meyer a écrit :

severity 972163 serious
severity 972166 serious
block 972176 by 972163
block 972176 by 972166
thanks

Hi! We are close to begin the Qt transition that will remove
qt5-default, so I'm raising the severities.  If everything goes well
I'll be NMUing your package today with an upload to delayed/5. Of
course feel free to ping me if needed.

Thanks, Lisandro.


I tried to upload it with your fix but the build failed for me.

If it works for you, please upload (without delay)

many thanks

S

Bug#968204: Removal of packges which depend on GTK2

[Pál Tamás Ács]

Technically, Gtk2 and Gtk3 are two different toolkits with a similar name.
It's a completely different thing that Red Hat is trying to make us believe
that GTK3 is an improved successor of GTK2. It isn't. It never has been.

GTK3 has been very much unstable, full of API breaks and annoyances from
the get-go. It's slower due to CPU bloat under certain circumstances, eats
up more RAM and is suffering from a serious UX dumbing down to the level of
consumer devices like smartphones thus being made less suitable for
desktop. Anti-features like mandatory recursive search
 in File Dialog have also
been introduced.

GTK3 was marked stable in many distros despite it wasn't stable at all.
Software creators and package maintainers didn't want to migrate to a
poorly designed, underdeveloped, buggy graphical toolkit. They either moved
forward to Qt or stayed with Gtk2. A famous precedent case is the cancelled
GTK3 migration of Audacious. They went back to Gtk2 then moved forward
toward Qt.

There must be a cooperation among Linux maintainters outside of Red Hat to
save Gtk2 and provide security updates and some critical bug fixes on the
maintainer level.

On Sun, Oct 25, 2020 at 12:43 PM Simon McVittie  wrote:

> On Sat, 10 Oct 2020 at 09:11:23 -0700, Sean Whitton wrote:
> > Hello GNOME team,
>
> Note that pkg-gnome-maintainers receives bugmail etc. for the entire
> GNOME suite, and most (all?) GNOME maintainers aren't subscribed to that
> particular fire hose (we get bug mail for packages of interest, or for
> all GNOME packages, via tracker.debian.org instead). Our discussion list
> is debian-gtk-gnome; I only saw this because I happened to follow the
> link on a removal notification for one of the GTK2 mass-bug-filing mails.
>
> > The FTP Team are starting to see removal requests for packages which
> > use GTK2 and are unlikely to be ported to GTK3, but are not RC-buggy.
> > Examples are #968204 and #968283.
> >
> > I read your bug report against one of those two packages and smcv writes
> >
> > GTK 2 is used by some important productivity applications like GIMP,
> > and has also historically been a popular UI toolkit for proprietary
> > software that we can't change, so perhaps removing GTK 2 from Debian
> > will never be feasible. However, it has reached the point where a
> > dependency on it is a bug - not a release-critical bug, and not a
> > bug that can necessarily be fixed quickly, but a piece of technical
> > debt that maintainers should be aware of.
> >
> > My interpretation of this is that use of GTK2 is not really grounds for
> > removal by itself, because there is no removal of GTK2 planned for the
> > time being.
>
> Yes. As I said in the mass-bug-filing, I think use of GTK 2 is a bug,
> but not release-critical for bullseye. Depending what happens in the
> next 1-2 years, it might be RC for bookworm - I don't know.
>
> However, if a package hasn't been able to move from GTK 2 to GTK 3 in
> the time since GTK 2 was superseded (about a decade), that's a data point
> for assessing how actively maintained it is, both upstream and in Debian.
>
> > So maintainers who don't want to deal with a package which
> > is not likely to be updated for newer versions of GTK (which is fair
> > enough) should orphan rather than request removal.
>
> Not necessarily: a package's maintainer is in a good position to assess
> whether that package has a future in Debian, and whether it's suitable for
> inclusion in a stable release. I think we need to distinguish between
> "I think this package is suitable for Debian, but I can't/won't
> maintain it" (orphaning) and "from my knowledge as maintainer, I think
> this package is unsuitable for Debian" (RM: RoM).
>
> There's little point in orphaning a package if the most likely outcome
> is that several weeks or months later, someone with less knowledge of
> this particular package has to spend time on deciding that *now* it's
> time to remove it.
>
> smcv
>
>

Bug#972556: ffmpeg: Fails to build from source with newer src:srt

[Sebastian Ramacher]

On 2020-10-20 12:08:01, John Paul Adrian Glaubitz wrote:
> On 10/20/20 12:05 PM, Sebastian Ramacher wrote:
> >> So, this patch and the patch from #968574 would be great!
> > 
> > Has the patch from #968574 been merged upstream in the meantime?
> 
> Apparently not. But merging won't break anything due to the #ifdef guards and 
> unbreaks ffmpeg
> on powerpc and ppc64 which is important due to the way Debian Ports works 
> with no support
> for cruft [1].

I'd be more comfortable with the patch if it was at least merged on
upstream's master branch.

Cheers

> 
> Adrian
> 
> > [1] https://lists.debian.org/debian-sparc/2017/12/msg00060.html
> 
> -- 
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#972865: opencfu fails tu start with " Gtk-ERROR **: GTK+ 2.x symbols detected"

[Wolf-Dieter Groll]

Package: opencfu
Version: 3.9.0-3
Severity: important

Dear Maintainer,

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

I installed the package as a possible solution to count nanoparticles on a SEM
image.

Trying to run the program results in the error-message:

(opencfu:13255): Gtk-ERROR **: 14:25:04.548: GTK+ 2.x symbols detected. Using
GTK+ 2.x and GTK+ 3 in the same process is not supported
Trace/Breakpoint ausgelöst

A Version compiled from the source (https://sourceforge.net/projects/opencfu/)
showed the same behaviour, so it doesn't seem to be a matter of dependencies.

I also looked in the unstable repositories, but the version in Sid seems to be
exactly the same as in Buster.



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

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

Versions of packages opencfu depends on:
ii  libatk1.0-0  2.30.0-2
ii  libatkmm-1.6-1v5 2.28.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libcairomm-1.0-1v5   1.12.2-4
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3+deb10u2
ii  libgcc1  1:8.3.0-6
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libglibmm-2.4-1v52.58.0-2
ii  libgomp1 8.3.0-6
ii  libgtk2.0-0  2.24.32-3
ii  libgtkmm-2.4-1v5 1:2.24.5-4
ii  libopencv-calib3d3.2 3.2.0+dfsg-6
ii  libopencv-contrib3.2 3.2.0+dfsg-6
ii  libopencv-core3.23.2.0+dfsg-6
ii  libopencv-features2d3.2  3.2.0+dfsg-6
ii  libopencv-flann3.2   3.2.0+dfsg-6
ii  libopencv-highgui3.2 3.2.0+dfsg-6
ii  libopencv-imgcodecs3.2   3.2.0+dfsg-6
ii  libopencv-imgproc3.2 3.2.0+dfsg-6
ii  libopencv-ml3.2  3.2.0+dfsg-6
ii  libopencv-objdetect3.2   3.2.0+dfsg-6
ii  libopencv-photo3.2   3.2.0+dfsg-6
ii  libopencv-shape3.2   3.2.0+dfsg-6
ii  libopencv-stitching3.2   3.2.0+dfsg-6
ii  libopencv-superres3.23.2.0+dfsg-6
ii  libopencv-video3.2   3.2.0+dfsg-6
ii  libopencv-videoio3.2 3.2.0+dfsg-6
ii  libopencv-videostab3.2   3.2.0+dfsg-6
ii  libopencv-viz3.2 3.2.0+dfsg-6
ii  libpango-1.0-0   1.42.4-8~deb10u1
ii  libpangocairo-1.0-0  1.42.4-8~deb10u1
ii  libpangoft2-1.0-01.42.4-8~deb10u1
ii  libpangomm-1.4-1v5   2.42.0-2
ii  libsigc++-2.0-0v52.10.1-2
ii  libstdc++6   8.3.0-6

opencfu recommends no packages.

opencfu suggests no packages.

-- no debconf information

Bug#972163: Rising severities

[Lisandro Damián Nicanor Pérez Meyer]

severity 972163 serious
severity 972166 serious
block 972176 by 972163
block 972176 by 972166
thanks

Hi! We are close to begin the Qt transition that will remove
qt5-default, so I'm raising the severities.  If everything goes well
I'll be NMUing your package today with an upload to delayed/5. Of
course feel free to ping me if needed.

Thanks, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#972864: qemu: CVE-2020-27661: divide by zero in dwc2_handle_packet() in hw/usb/hcd-dwc2.c

[Salvatore Bonaccorso]

Source: qemu
Version: 1:5.1+dfsg-4
Severity: important
Tags: security upstream
Forwarded: 
https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg04263.html
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for qemu.

CVE-2020-27661[0]:
| divide by zero in dwc2_handle_packet() in hw/usb/hcd-dwc2.c

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-27661
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27661
[1] https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg04263.html
[2] 
https://git.qemu.org/?p=qemu.git;a=commit;h=bea2a9e3e00b275dc40cfa09c760c715b8753e03

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#969529: libxml2: diff for NMU version 2.9.10+dfsg-6.2

[Salvatore Bonaccorso]

Control: tags 969529 + patch
Control: tags 969529 + pending


Dear maintainer,

I've prepared an NMU for libxml2 (versioned as 2.9.10+dfsg-6.2) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Additionally to the attached debdiff prepared merge request is at
https://salsa.debian.org/xml-sgml-team/libxml2/-/merge_requests/5

Regards,
Salvatore
diff -Nru libxml2-2.9.10+dfsg/debian/changelog libxml2-2.9.10+dfsg/debian/changelog
--- libxml2-2.9.10+dfsg/debian/changelog	2020-10-14 08:45:25.0 +0200
+++ libxml2-2.9.10+dfsg/debian/changelog	2020-10-25 13:56:23.0 +0100
@@ -1,3 +1,11 @@
+libxml2 (2.9.10+dfsg-6.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix out-of-bounds read with 'xmllint --htmlout' (CVE-2020-24977)
+(Closes: #969529)
+
+ -- Salvatore Bonaccorso   Sun, 25 Oct 2020 13:56:23 +0100
+
 libxml2 (2.9.10+dfsg-6.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libxml2-2.9.10+dfsg/debian/patches/Fix-out-of-bounds-read-with-xmllint-htmlout.patch libxml2-2.9.10+dfsg/debian/patches/Fix-out-of-bounds-read-with-xmllint-htmlout.patch
--- libxml2-2.9.10+dfsg/debian/patches/Fix-out-of-bounds-read-with-xmllint-htmlout.patch	1970-01-01 01:00:00.0 +0100
+++ libxml2-2.9.10+dfsg/debian/patches/Fix-out-of-bounds-read-with-xmllint-htmlout.patch	2020-10-25 13:56:23.0 +0100
@@ -0,0 +1,39 @@
+From: Nick Wellnhofer 
+Date: Fri, 7 Aug 2020 21:54:27 +0200
+Subject: Fix out-of-bounds read with 'xmllint --htmlout'
+Origin: https://gitlab.gnome.org/GNOME/libxml2/-/commit/50f06b3efb638efb0abd95dc62dca05ae67882c2
+Bug: https://gitlab.gnome.org/GNOME/libxml2/-/issues/178
+Bug-Debian: https://bugs.debian.org/969529
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2020-24977
+
+Make sure that truncated UTF-8 sequences don't cause an out-of-bounds
+array access.
+
+Thanks to @SuhwanSong and the Agency for Defense Development (ADD) for
+the report.
+
+Fixes #178.
+---
+ xmllint.c | 6 ++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/xmllint.c b/xmllint.c
+index f6a8e463639a..c647486f39b4 100644
+--- a/xmllint.c
 b/xmllint.c
+@@ -528,6 +528,12 @@ static void
+ xmlHTMLEncodeSend(void) {
+ char *result;
+ 
++/*
++ * xmlEncodeEntitiesReentrant assumes valid UTF-8, but the buffer might
++ * end with a truncated UTF-8 sequence. This is a hack to at least avoid
++ * an out-of-bounds read.
++ */
++memset([sizeof(buffer)-4], 0, 4);
+ result = (char *) xmlEncodeEntitiesReentrant(NULL, BAD_CAST buffer);
+ if (result) {
+ 	xmlGenericError(xmlGenericErrorContext, "%s", result);
+-- 
+2.28.0
+
diff -Nru libxml2-2.9.10+dfsg/debian/patches/series libxml2-2.9.10+dfsg/debian/patches/series
--- libxml2-2.9.10+dfsg/debian/patches/series	2020-10-13 09:39:13.0 +0200
+++ libxml2-2.9.10+dfsg/debian/patches/series	2020-10-25 13:56:23.0 +0100
@@ -4,3 +4,4 @@
 Fix-freeing-of-nested-documents.patch
 python3-unicode-errors.patch
 parenthesize-type-checks.patch
+Fix-out-of-bounds-read-with-xmllint-htmlout.patch