Bug#990651: unblock: nx-libs/2:3.5.99.26-2

[Mike Gabriel]

Control: tags -1 - moreinfo

On  So 04 Jul 2021 21:15:15 CEST, Sebastian Ramacher wrote:


Control: tags -1 moreinfo

The debdiff appears to be missing.


Ouch. I forgot that. Now attached.

Mike
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net

diff -Nru nx-libs-3.5.99.26/debian/changelog nx-libs-3.5.99.26/debian/changelog
--- nx-libs-3.5.99.26/debian/changelog  2021-02-04 14:46:49.0 +0100
+++ nx-libs-3.5.99.26/debian/changelog  2021-07-03 20:42:32.0 +0200
@@ -1,3 +1,22 @@
+nx-libs (2:3.5.99.26-2) unstable; urgency=medium
+
+  * debian/patches:
++ Add 0001_Compext.c-fix-comparisons-of-16bit-sequence-numbers.patch.
+  Compext.c: fix comparisons of 16bit sequence numbers. (Closes:
+  #990647).
++ Add 0002_Forward-ClientMessages-to-nxproxy-side.patch.
+  Forward ClientMessages to nxproxy side. (Closes: #990649).
++ Add 0003_randr-Do-not-update-ConnectionInfo-if-NULL.patch.
+  randr: Do not update ConnectionInfo if NULL (and avoid the nxagent
+  Xserver from crashing). (Closes: #990650).
++ Add 0004_document-additional-options-only-nxagent-knows-about.patch.
+  Update man page and --help documentation of nxproxy/nxagent.
++ Adjust 0004_document-additional-options-only-nxagent-knows-about.patch.
+  Version 3.5.99.26 does not yet have the textclipboard= session
+  parameter.
+
+ -- Mike Gabriel   Sat, 03 Jul 2021 20:42:32 +0200
+
 nx-libs (2:3.5.99.26-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru 
nx-libs-3.5.99.26/debian/patches/0001_Compext.c-fix-comparisons-of-16bit-sequence-numbers.patch
 
nx-libs-3.5.99.26/debian/patches/0001_Compext.c-fix-comparisons-of-16bit-sequence-numbers.patch
--- 
nx-libs-3.5.99.26/debian/patches/0001_Compext.c-fix-comparisons-of-16bit-sequence-numbers.patch
 1970-01-01 01:00:00.0 +0100
+++ 
nx-libs-3.5.99.26/debian/patches/0001_Compext.c-fix-comparisons-of-16bit-sequence-numbers.patch
 2021-06-09 09:25:13.0 +0200
@@ -0,0 +1,86 @@
+From 1b4ebce2ce8ef29c01bd124ed56c9d6a14c9a82d Mon Sep 17 00:00:00 2001
+From: Ulrich Sibiller 
+Date: Wed, 17 Mar 2021 22:17:55 +0100
+Subject: [PATCH] Compext.c: fix comparisons of 16bit sequence numbers
+
+rep->generic.sequenceNumber is of type CARD16
+state->sequence is of type unsigned long
+
+Converting state->sequence to an int as it has been done since the
+first version of nxcomp I know of (1.3.0-18 from 2003) is wrong here
+because for numbers > INT_MAX this will result in a negative number,
+which, after applying the 16bit modulo, will not match
+rep->generic.sequenceNumber.
+
+Example with numbers:
+
+CARD16 c = 24565
+unsigned long u = 3179110389
+
+c % 65536 = 24565
+u % 65536 = 24565
+
+(int)(u) = -1115856907
+(int)(u) % 65536 = -40971
+
+-40971 will not match 24565
+
+To fix this we need to ensure the number stays positive. We use CARD16
+for this to match the type in the request which is a 16bit number. On
+my system CARD16 is unsigned short which is guaranteed to contain _at
+least_ the 0-65,535 range. As there is no upper limit of the range we
+cannot drop the modulo because we need this value to be 16bit and not
+more.
+
+Thanks to Norm Green for providing log after log until we could
+finally identify the reason for him seeing "Xlib: unexpected async
+reply (sequence 0x94b01439)!" when pasting stopped working.
+
+Signed-off-by: Mike Gabriel 
+---
+ nx-X11/programs/Xserver/hw/nxagent/compext/Compext.c | 8 
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/nx-X11/programs/Xserver/hw/nxagent/compext/Compext.c 
b/nx-X11/programs/Xserver/hw/nxagent/compext/Compext.c
+index 4a8dacaf4..7a6cb9e30 100644
+--- a/nx-X11/programs/Xserver/hw/nxagent/compext/Compext.c
 b/nx-X11/programs/Xserver/hw/nxagent/compext/Compext.c
+@@ -3435,7 +3435,7 @@ static Bool _NXCollectImageHandler(Display *dpy, xReply 
*rep, char *buf,
+   state = (_NXCollectImageState *) data;
+ 
+   if ((rep -> generic.sequenceNumber % 65536) !=
+-  ((int)(state -> sequence) % 65536))
++  ((CARD16)(state -> sequence) % 65536))
+   {
+ #ifdef TEST
+ fprintf(stderr, "**_NXCollectImageHandler: Unmatched sequence [%d] 
for opcode [%d] "
+@@ -3819,7 +3819,7 @@ static Bool _NXCollectPropertyHandler(Display *dpy, 
xReply *rep, char *buf,
+   state = (_NXCollectPropertyState *) data;
+ 
+   if ((rep -> generic.sequenceNumber % 65536) !=
+-  ((int)(state -> sequence) % 65536))
++  ((CARD16)(state -> sequence) % 65536))
+   {
+ #ifdef TEST
+ fprintf(stderr, "**_NXCollectPropertyHandler: Unmatched sequence [%d] 
for opcode [%d] "
+@@ -4173,7 +4173,7 @@ static Bool _NXCollectGrabPointerHandler(Display *dpy, 
xReply *rep, char *buf,
+   state = (_NXCollectGrabPointerState *) data;
+ 
+   if ((rep -> generic.sequenceNumber 

Bug#990695: side note about 1.1.9-4

[Mike Gabriel]

Sometime ago, I uploaded uif 1.1.9-4 to fix the debian/watch file  
regarding Github URL changes and retrieval of upstream releases. This  
fix is also included in 1.1.9-5.


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp6P9rdOp3Ev.pgp
Description: Digitale PGP-Signatur

Bug#990700: ITP: target-factory -- Factory library to generate DPU target description file

[Nobuhiro Iwamatsu]

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

* Package name: target-factory
  Version : 1.3.2
  Upstream Author : Jian Weng 
* URL : https://github.com/Xilinx/Vitis-AI.git
* License : Apache 2.0
  Programming Lang: C++
  Description : Factory library to generate DPU target description file

  A factory to manage Deep learning Processing Unit (DPU) target
  description infos. Register targets and then you can get infos by
  name or fingerprint. 

Bug#990692: uif: does not apply filter rules anymore when started

[Mike Gabriel]

Package: uif
Severity: grave
Version: 1.1.9-3

Some time ago I spotted that the "uif" firewall script when run on a  
Debian 11 system does not set iptables filter rules correctly anymore.


Only today, I found time to investigate the cause on this issue.

I have a patch ready and will upload it in a minute.

Greets,
Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpM9pc9Vgnqi.pgp
Description: Digitale PGP-Signatur

Bug#990699: release.debian.org: Sorting out bug 990059 in bullseye

[Mike Hommey]

Package: release.debian.org
Severity: important
Usertags: binnmu transition

Hi,

Recent versions of libnss3 had a backwards incompatible change that made
packages built with the newer versions fail to work properly with the older
version of the package that is in bullseye.

That wouldn't be a problem if 2 packages that use the problematic symbol
and are built with the newer version hadn't themselves made it to
bullseye. The packages are, namely, firefox-esr and curl (curl has only
become a problem this week).

I uploaded a version of nss (2:3.67-2) that works around the issue and
will make rebuilds of those packages work with the version of nss in
bullseye, meaning we'd need binNMUs of both curl and firefox-esr and
subsequent transitions.

However, firefox-esr is due for a security update next tuesday/wednesday,
so it will be rebuilt anyways. I guess we might as well wait.

Which leaves us with just curl.

 nmu curl_7.74.0-1.3 . ANY . -m 'Rebuild against newer libnss3-dev'

Mike

Bug#971683: postgresql-common: obsolete-conffile (apt.conf.d, createcluster.conf)

[Christoph Anton Mitterer]

Hey.

Also found /etc/apt/apt.conf.d/01autoremove-postgresql to be an
obsolete dpkg conffile...

Though AFAIU it's still used in the package, just not longer as a
conffile "registered" to dpkg.


I think the reason why it's leftover is, that the maintainer scripts
remove:
/etc/apt/apt.conf.d/01autoremove
not:
/etc/apt/apt.conf.d/01autoremove-postgresql

/var/lib/dpkg/info# grep -i 01autoremove *postgresql*
postgresql-common.list:/etc/apt/apt.conf.d/01autoremove-postgresql
postgresql-common.postinst:dpkg-maintscript-helper rm_conffile 
/etc/apt/apt.conf.d/01autoremove 215~ postgresql-common -- "$@"
postgresql-common.postrm:rm -f /etc/apt/apt.conf.d/01autoremove-postgresql
postgresql-common.postrm:dpkg-maintscript-helper rm_conffile 
/etc/apt/apt.conf.d/01autoremove 215~ postgresql-common -- "$@"
postgresql-common.preinst:dpkg-maintscript-helper rm_conffile 
/etc/apt/apt.conf.d/01autoremove 215~ postgresql-common -- "$@"
postgresql-common.prerm:dpkg-maintscript-helper rm_conffile 
/etc/apt/apt.conf.d/01autoremove 215~ postgresql-common -- "$@"


Of course, if you change that now,... you need to adapt the version to
"the latest version of the package whose upgrade should trigger
the operation"... so "215~" would be wrong.

Quoting the manpage:
   For example, for a conffile removed in version 2.0-1 of a package,
   prior-version should be set to 2.0-1~. This will cause the conffile
   to be removed even if the user rebuilt the previous version 1.0-1
   as 1.0-1local1. Or a package switching a path from a symlink
   (shipped in version 1.0-1) to a directory (shipped in version
   2.0-1), but only performing the actual switch in the maintainer
   scripts in version 3.0-1, should set prior-version to 3.0-1~.


Oh and things might be a bit more tricky here, because AFAIU the file
is actually still used (just not as a "registered" conffile).

It does seem to get re-created in the configure step, but that would of
course loose any user modifications.

Not really sure what should be done here...

If it had user modification, I think dpkg-maintscript-helper
rm_conffile would anyway leave the file over with some new extension...
but that's of course not a "nice" transition.

Maybe ask the dpkg people what they suggest in such situation?


Thanks,
Chris.

Bug#990059: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[Mike Hommey]

On Mon, Jul 05, 2021 at 08:14:45AM +0900, Mike Hommey wrote:
> On Mon, Jul 05, 2021 at 07:57:30AM +0900, Mike Hommey wrote:
> > reopen 990059
> > affects 990059 firefox-esr firefox libcurl3-nss
> > thanks
> > 
> > On Sat, Jun 19, 2021 at 09:00:13AM +0200, Carsten Schoenert wrote:
> > > Hello Kevin, hello Sebastian,
> > > 
> > > thanks for working on this issue in between times, I wasn't able to do
> > > anything practically the last days.
> > > 
> > > Am 18.06.21 um 23:31 schrieb Kevin Locke:
> > > > Hi Sebastian,
> > > > 
> > > > On Fri, 2021-06-18 at 22:26 +0200, Sebastian Ramacher wrote:
> > > >> Thanks for this detailed analysis. That actually means that the symbol
> > > >> file for libnss3 2:3.67-1 is broken. It would need to bump the minimum
> > > >> version requirement for all symbols that works with SSLChannelInfo. 
> > > >> From
> > > >> your description, at least the version for SSL_GetChannelInfo would 
> > > >> need
> > > >> to be bumped. If thunderbird would then be built against a libnss3
> > > >> version with a fixed symbol files, it would pick up tight enought
> > > >> dependencies.
> > > >>
> > > >> So ideally the bug against thunderbird would be reassigned to libnss3
> > > >> 2:3.67-1 and its severits raised to serious. Once fixed, we can rebuild
> > > >> thunderbird to pick up the correct depedencies.
> > > > 
> > > > Good point.  Fixing the libnss3 symbol file sounds like the right fix to
> > > > me.  As far as I can tell SSL_GetChannelInfo is the only symbol which
> > > > takes SSLChannelInfo.  I've opened https://bugs.debian.org/990058 with
> > > > the proposed fix.
> > > 
> > > Fixing libnss3 is obviously the correct thing anyway. But this will take
> > > its time to get it landed into bullseye.
> > > 
> > > >> But since that version of libnss3 is not in bullseye, the rebuild would
> > > >> not be abile to migrate. Ideally libnss3 would be reverted to the
> > > >> version in bullseye to avoid this issue. Otherwise I can schedule
> > > >> binNMUs of thunderbird in tpu, but that means that we would need to do
> > > >> that for any thunderbird upload that we want in bullseye until the
> > > >> release. That is suboptimal - it's more work with less testing.
> > > > 
> > > > That may be tricky.  firefox 88.0.1-1 in unstable depends on
> > > > libnss3 (>= 2:3.63~).  If the maintainers are willing to upload an NSS
> > > > version between 2:3.63 and 2:3.65, I believe that would solve the issue
> > > > without breaking firefox.  (2:3.63-1 is the only suitable version
> > > > in debian/changelog.)  I've opened https://bugs.debian.org/990059 to
> > > > discuss.
> > > 
> > > To prevent quite a lot of work on all involved parties with not that
> > > much gain in the end I'd suggest to go back to my option B that was to
> > > (re)build Thunderbird with it's internal shipped NSS version.
> > 
> > Unfortunately, this affects more than Thunderbird. It also affects
> > Firefox ESR (although not on amd64 because for some reason it was built
> > against an older version of NSS, but it affects other architectures). It
> > also affects the latest upload of curl.
> 
> It also affects openjdk-17, openjdk-8 and pcp in sid, if they're ever
> meant to transition to testing (which, from the look of it, is probably
> not the case).

Scrap that, openjdk* and pcp are not using the problematic symbol.

Mike

Bug#931339: [pkg-gnupg-maint] Bug#931339: gnupg: Change default keyserver?

[Paul Wise]

On Sun, 2021-07-04 at 22:28 +0900, Roger Shimizu wrote:

> Is there any other bug involved?

In another mail, Harald Welte says lxc is now broken:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931339#29

Hopefully he can re-check things and reply.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#990698: zookeeperd: legacy conffiles leftover

[Christoph Anton Mitterer]

Package: zookeeperd
Version: 3.4.13-6
Severity: normal


Hi.

Apparently the package used to contain the conffiles:
/etc/init/zookeeper.conf
but no longer does so.

Please properly clean them up using dpkg-maintscript-helper(1).
(AFAIU, the version that needs to be specified for that is NOT
the version where the conffile was dropped, but rather "the
latest version of the package whose upgrade should trigger
the operation"

Quoting the manpage:
   For example, for a conffile removed in version 2.0-1 of a package,
   prior-version should be set to 2.0-1~. This will cause the conffile
   to be removed even if the user rebuilt the previous version 1.0-1
   as 1.0-1local1. Or a package switching a path from a symlink
   (shipped in version 1.0-1) to a directory (shipped in version
   2.0-1), but only performing the actual switch in the maintainer
   scripts in version 3.0-1, should set prior-version to 3.0-1~.



Also, it hadn't "registered" /etc/reader.conf.d/ so that will probably be left
over, too, unless some other package that contains it is installed (like 
libccid).


Cheers,
Chris.

Bug#950386: zookeeperd: missing-systemd-service-for-init.d-script

[Christoph Anton Mitterer]

Hey.

It seems that zookeeper actually already contained a systemd unit in
stretch (and still does so in the source package):

https://packages.debian.org/stretch/all/zookeeperd/filelist

but apparently this got already lost in buster (and by the way not
properly cleaned up, so there remain dead dangling symlinks in
/etc/systemd/system).


Cheers,
Chris.

Bug#990058: libnss3: increase symbol version for SSL_GetChannelInfo when SSLChannelInfo size changes

[Mike Hommey]

severity 990058 normal
thanks

With #990059 addressed in 2:3.67-2, this can be downgraded to normal.
The problem also exists with other functions, which is why I'll keep
this open for a more complete and long-term solution.

Mike

On Fri, Jun 18, 2021 at 03:09:36PM -0600, Kevin Locke wrote:
> Package: libnss3
> Version: 2:3.67-1
> Severity: serious
> Tags: patch
> Justification: Policy 8.6.3.3
> X-Debbugs-Cc: Sebastian Ramacher , Carsten Schoenert 
> 
> 
> Dear Maintainer,
> 
> Thunderbird 1:78.11.0-1 in testing is unable to establish some (all?)
> TLS connections when run with libnss3 2:3.61-1, because it was built
> with libnss3-dev 2:3.66-1.  The issue occurs because the size of
> SSLChannelInfo increased between NSS 3.61 and 3.66 (due to the addition
> of PRBool isFIPS).  SSL_GetChannelInfo takes both a pointer to and size
> of SSLChannelInfo as arguments.  If the size is greater than the size it
> expects, it returns SECFailure, causing the connection to fail.  See
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989839#48 for details.
> 
> The issue is being discussed on debian-release, where Sebastian Ramacher
> pointed out that the libnss3 symbol file should bump the minimum version
> requirement for all symbols that works with SSLChannelInfo.[1]  I agree.
> As far as I can tell, SSL_GetChannelInfo is the only such symbol.  I
> believe it should be bumped to 2:3.66 for package 2:3.67 and bumped in
> future versions whenever the size of SSLChannelInfo changes.  I've
> attached a patch to do so.
> 
> Thanks for considering,
> Kevin
> 
> [1]: https://lists.debian.org/debian-release/2021/06/msg00597.html
> 
> -- System Information:
> Debian Release: 11.0
>   APT prefers testing-debug
>   APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
> 'unstable-debug'), (500, 'testing-security'), (500, 'stable-debug'), (500, 
> 'unstable'), (500, 'oldstable'), (101, 'experimental'), (1, 
> 'experimental-debug')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.13.0-rc6 (SMP w/4 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 libnss3 depends on:
> ii  libc6 2.31-12
> ii  libnspr4  2:4.29-1
> ii  libsqlite3-0  3.34.1-3
> 
> libnss3 recommends no packages.
> 
> libnss3 suggests no packages.
> 
> -- no debconf information

> >From eaffc616b99dd2be285ade5df072cfa1e30924fe Mon Sep 17 00:00:00 2001
> Message-Id: 
> 
> From: Kevin Locke 
> Date: Fri, 18 Jun 2021 14:41:27 -0600
> Subject: [PATCH] libnss3.symbols: bump SSL_GetChannelInfo to 2:3.66
> 
> PRBool isFIPS was added to SSLChannelInfo in NSS 3.66, causing its size
> to increase.  Since SSL_GetChannelInfo is called with
> sizeof(SSLChannelInfo) and returns SECFailure when called with a larger
> size than it expects, it creates a version incompatibility where
> programs compiled with NSS >= 3.66 do not function correction when
> loaded with NSS < 3.66, as in #989839 for thunderbird.
> 
> To avoid breakage, bump the version of SSL_GetChannelInfo, as suggested
> by Sebastian Ramacher in
> https://lists.debian.org/debian-release/2021/06/msg00597.html
> 
> Signed-off-by: Kevin Locke 
> ---
>  debian/libnss3.symbols | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/debian/libnss3.symbols b/debian/libnss3.symbols
> index 5213379c..2bb7294a 100644
> --- a/debian/libnss3.symbols
> +++ b/debian/libnss3.symbols
> @@ -154,5 +154,5 @@ libssl3.so libnss3 #MINVER#
>   (symver)NSS_3.4 2:3.13.4-2~
>   (symver)NSS_3.7.4 2:3.13.4-2~
>   SSL_GetCipherSuiteInfo@NSS_3.4 2:3.44.0
> - SSL_GetChannelInfo@NSS_3.4 2:3.34
> + SSL_GetChannelInfo@NSS_3.4 2:3.66
>   SSL_GetPreliminaryChannelInfo@NSS_3.21 2:3.44.0
> -- 
> 2.30.2
> 

Bug#990697: unblock: gnome-desktop3/3.38.5-3

[Gunnar Hjalmarsson]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: pkg-gnome-maintain...@lists.alioth.debian.org

Please unblock package gnome-desktop3.

[ Reason ]

Cherry picked upstream commit to fix segfault when adding input sources 
while show-all-sources is "true". The problem was reported in 
.


[ Impact ]

Without the fix, GNOME users can't make use of the so-called "exotic" 
XKB keyboard layouts. Let's not ship Debian 11 with that bug, even if 
only a minor portion of the users are affected.


[ Tests ]

Manually installed the binaries built by version 3.38.5-3 of the 
gnome-desktop3 source, and confirmed that the bug was fixed as expected.


[ Risks ]

The change is a targeted fix to address the issue at hand. It was 
committed upstream on April 22, and no reported regression.


[ 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 testing

--
Cheers,
Gunnar Hjalmarsson
diff --git a/debian/changelog b/debian/changelog
index 80634e36..d39f84fc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+gnome-desktop3 (3.38.5-3) unstable; urgency=medium
+
+  * Team upload
+  * d/p/xkbinfo-only-insert-new-layouts-skip-over-duplicate-ones.patch:
+Fix segfault when adding input sources while show-all-sources is
+"true" (closes: #989045).
+
+ -- Gunnar Hjalmarsson   Sun, 04 Jul 2021 15:40:52 +0200
+
 gnome-desktop3 (3.38.5-2) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/patches/series b/debian/patches/series
index 6b64c79b..0630c1a8 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -4,3 +4,4 @@ xkbinfo-refactor-some-of-the-rules-parsing.patch
 test-convert-the-xkbinfo-test-to-produce-YAML.patch
 xkbinfo-use-libxkbregistry-to-parse-the-rules-files-for-u.patch
 xkbinfo-Update-iso639Ids-correctly-in-evdev.patch
+xkbinfo-only-insert-new-layouts-skip-over-duplicate-ones.patch
diff --git 
a/debian/patches/xkbinfo-only-insert-new-layouts-skip-over-duplicate-ones.patch 
b/debian/patches/xkbinfo-only-insert-new-layouts-skip-over-duplicate-ones.patch
new file mode 100644
index ..1274aae8
--- /dev/null
+++ 
b/debian/patches/xkbinfo-only-insert-new-layouts-skip-over-duplicate-ones.patch
@@ -0,0 +1,53 @@
+From: Peter Hutterer 
+Date: Thu, 22 Apr 2021 01:29:18 +
+Subject: xkbinfo: only insert new layouts, skip over duplicate ones
+
+This matches the behavior to the one in the old code path before
+libxkbregistry.
+
+This also fixes a use-after-free bug when a duplicate layout is present. The
+same layout struct is a member of multiple hashtables, specifically
+priv->layouts_table, priv->layouts_by_language and  priv->layouts_by_country.
+
+When the duplicate layout is added, add_layouts calls g_hash_table_replace
+(priv->layouts_table, l->id, l) which frees the original layout - but the
+layouts_by_{country|language} still have that now-freed layout.
+Immediately afterwards, add_layouts calls add_layout_to_locale_tables () which
+calls add_layout_to_table () which triggers a use-after-free.
+
+Avoid all this by simply skipping any duplicate layout.
+
+Reproducible with
+  gsettings set org.gnome.desktop.input-sources show-all-sources true
+  valgrind /usr/libexec/gnome-desktop-debug/test-xkb-info
+
+Requires xkeyboard-config <= 2.32, it has a duplicate cm(mmuock) entry
+(one is marked exotic, hence the need for show-all-sources).
+
+Origin: concatenation of:
+ https://gitlab.gnome.org/GNOME/gnome-desktop/-/commit/a39dd0d2
+ https://gitlab.gnome.org/GNOME/gnome-desktop/-/commit/81c6cd79
+Bug: https://gitlab.gnome.org/GNOME/gnome-desktop/-/issues/190
+Bug-Debian: https://bugs.debian.org/989045
+Bug-Ubuntu: https://launchpad.net/bugs/1933022
+---
+ libgnome-desktop/gnome-xkb-info.c | 6 ++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/libgnome-desktop/gnome-xkb-info.c 
b/libgnome-desktop/gnome-xkb-info.c
+index b2eca699..f2a3214b 100644
+--- a/libgnome-desktop/gnome-xkb-info.c
 b/libgnome-desktop/gnome-xkb-info.c
+@@ -268,6 +268,12 @@ add_layouts (GnomeXkbInfo*self,
+   l->iso3166Ids = g_slist_prepend (l->iso3166Ids, id);
+ }
+ 
++  if (g_hash_table_contains (priv->layouts_table, l->id))
++{
++  g_clear_pointer (, free_layout);
++  continue;
++}
++
+   g_hash_table_replace (priv->layouts_table, l->id, l);
+   add_layout_to_locale_tables (l,
+priv->layouts_by_language,


OpenPGP_signature
Description: OpenPGP digital signature

Bug#989839: Bug#990059: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[Mike Hommey]

On Mon, Jul 05, 2021 at 07:57:30AM +0900, Mike Hommey wrote:
> reopen 990059
> affects 990059 firefox-esr firefox libcurl3-nss
> thanks
> 
> On Sat, Jun 19, 2021 at 09:00:13AM +0200, Carsten Schoenert wrote:
> > Hello Kevin, hello Sebastian,
> > 
> > thanks for working on this issue in between times, I wasn't able to do
> > anything practically the last days.
> > 
> > Am 18.06.21 um 23:31 schrieb Kevin Locke:
> > > Hi Sebastian,
> > > 
> > > On Fri, 2021-06-18 at 22:26 +0200, Sebastian Ramacher wrote:
> > >> Thanks for this detailed analysis. That actually means that the symbol
> > >> file for libnss3 2:3.67-1 is broken. It would need to bump the minimum
> > >> version requirement for all symbols that works with SSLChannelInfo. From
> > >> your description, at least the version for SSL_GetChannelInfo would need
> > >> to be bumped. If thunderbird would then be built against a libnss3
> > >> version with a fixed symbol files, it would pick up tight enought
> > >> dependencies.
> > >>
> > >> So ideally the bug against thunderbird would be reassigned to libnss3
> > >> 2:3.67-1 and its severits raised to serious. Once fixed, we can rebuild
> > >> thunderbird to pick up the correct depedencies.
> > > 
> > > Good point.  Fixing the libnss3 symbol file sounds like the right fix to
> > > me.  As far as I can tell SSL_GetChannelInfo is the only symbol which
> > > takes SSLChannelInfo.  I've opened https://bugs.debian.org/990058 with
> > > the proposed fix.
> > 
> > Fixing libnss3 is obviously the correct thing anyway. But this will take
> > its time to get it landed into bullseye.
> > 
> > >> But since that version of libnss3 is not in bullseye, the rebuild would
> > >> not be abile to migrate. Ideally libnss3 would be reverted to the
> > >> version in bullseye to avoid this issue. Otherwise I can schedule
> > >> binNMUs of thunderbird in tpu, but that means that we would need to do
> > >> that for any thunderbird upload that we want in bullseye until the
> > >> release. That is suboptimal - it's more work with less testing.
> > > 
> > > That may be tricky.  firefox 88.0.1-1 in unstable depends on
> > > libnss3 (>= 2:3.63~).  If the maintainers are willing to upload an NSS
> > > version between 2:3.63 and 2:3.65, I believe that would solve the issue
> > > without breaking firefox.  (2:3.63-1 is the only suitable version
> > > in debian/changelog.)  I've opened https://bugs.debian.org/990059 to
> > > discuss.
> > 
> > To prevent quite a lot of work on all involved parties with not that
> > much gain in the end I'd suggest to go back to my option B that was to
> > (re)build Thunderbird with it's internal shipped NSS version.
> 
> Unfortunately, this affects more than Thunderbird. It also affects
> Firefox ESR (although not on amd64 because for some reason it was built
> against an older version of NSS, but it affects other architectures). It
> also affects the latest upload of curl.

It also affects openjdk-17, openjdk-8 and pcp in sid, if they're ever
meant to transition to testing (which, from the look of it, is probably
not the case).

Mike

Bug#505381: genisoimage: writes blank sectors

[Sam Trenholme]

OK, some updates for 2021:

* genisoimage is officially marked "abandoned" and should not be used 
(time stamps will start break come 2028; I've fixed the bug but there's 
no genisoimage maintainer to update the program with the fix).  See 
https://wiki.debian.org/genisoimage for end-of-life notice


* As per that Wiki page, the official answer is to use xorrisofs, which 
yes has fixed (or never had) this "blank sector" bug


* I have made my own fork of genisoimage, iso9660, which fixes this bug 
and the bug with post-2027 timestamps: https://github.com/samboy/iso9660


- Sam


This behavior (or one very similar to it) appears to still be present,
five and a half years later. The patch still appears to apply (albeit
with considerable a offset) against current upstream SVN.

I have not managed to find any indication of what the reason for adding
these blank sectors is supposed to be. The code in question appears to
date all the way back to the original import of mkisofs into Subversion,
so there's no help there.

Any chance of either getting this patch applied, or at least figuring
out a reason why it would be a bad idea?

>
>

Bug#990059: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[Mike Hommey]

reopen 990059
affects 990059 firefox-esr firefox libcurl3-nss
thanks

On Sat, Jun 19, 2021 at 09:00:13AM +0200, Carsten Schoenert wrote:
> Hello Kevin, hello Sebastian,
> 
> thanks for working on this issue in between times, I wasn't able to do
> anything practically the last days.
> 
> Am 18.06.21 um 23:31 schrieb Kevin Locke:
> > Hi Sebastian,
> > 
> > On Fri, 2021-06-18 at 22:26 +0200, Sebastian Ramacher wrote:
> >> Thanks for this detailed analysis. That actually means that the symbol
> >> file for libnss3 2:3.67-1 is broken. It would need to bump the minimum
> >> version requirement for all symbols that works with SSLChannelInfo. From
> >> your description, at least the version for SSL_GetChannelInfo would need
> >> to be bumped. If thunderbird would then be built against a libnss3
> >> version with a fixed symbol files, it would pick up tight enought
> >> dependencies.
> >>
> >> So ideally the bug against thunderbird would be reassigned to libnss3
> >> 2:3.67-1 and its severits raised to serious. Once fixed, we can rebuild
> >> thunderbird to pick up the correct depedencies.
> > 
> > Good point.  Fixing the libnss3 symbol file sounds like the right fix to
> > me.  As far as I can tell SSL_GetChannelInfo is the only symbol which
> > takes SSLChannelInfo.  I've opened https://bugs.debian.org/990058 with
> > the proposed fix.
> 
> Fixing libnss3 is obviously the correct thing anyway. But this will take
> its time to get it landed into bullseye.
> 
> >> But since that version of libnss3 is not in bullseye, the rebuild would
> >> not be abile to migrate. Ideally libnss3 would be reverted to the
> >> version in bullseye to avoid this issue. Otherwise I can schedule
> >> binNMUs of thunderbird in tpu, but that means that we would need to do
> >> that for any thunderbird upload that we want in bullseye until the
> >> release. That is suboptimal - it's more work with less testing.
> > 
> > That may be tricky.  firefox 88.0.1-1 in unstable depends on
> > libnss3 (>= 2:3.63~).  If the maintainers are willing to upload an NSS
> > version between 2:3.63 and 2:3.65, I believe that would solve the issue
> > without breaking firefox.  (2:3.63-1 is the only suitable version
> > in debian/changelog.)  I've opened https://bugs.debian.org/990059 to
> > discuss.
> 
> To prevent quite a lot of work on all involved parties with not that
> much gain in the end I'd suggest to go back to my option B that was to
> (re)build Thunderbird with it's internal shipped NSS version.

Unfortunately, this affects more than Thunderbird. It also affects
Firefox ESR (although not on amd64 because for some reason it was built
against an older version of NSS, but it affects other architectures). It
also affects the latest upload of curl.

I'm going to upload a new version of 3.67 that will restore the binary
compat so that things built against the new version will work with the
older one. That should allow to binNMU the affected packages.

Mike

Bug#990486: mtools: mcopy -b crashes with "Internal error, size too big"

[Chris Lamb]

Hi Göran,

> I have a script that uses mtools to create a FAT partition and it has
> stopped working with recent mtools versions:
>
[..]
> This worked with 4.0.26-1 (currently in testing). It also works
> without the -b flag. The -b flag is described as an optimization, so a
> simple workaround for anyone affected is to stop using -b.

Thank for the bug report. Are you able to report this upstream via
their mailing list? I can do this myself, but it might more sense for
you to do so just in case they have any followups. I believe you can
signup and post by following these instructions:

  https://www.gnu.org/software/mtools/#mailing


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#990696: unblock: netselect/0.3.ds1-29

[Javier Fernández-Sanguino Peña]

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

Please unblock package netselect

[ Reason ]

Netselect-apt is not able to properly parse the URLs in the mirror list
available in the Debian website. This version fixes the bug in parsing which
makes it work again.

[ Impact ]
If the unblock is not implemented users will not be able to use netselect-apt

[ Tests ]
I have run manually tests in my unstable system to confi

[ Risks ]
The change is very simple. This is a package which is used by a small number of
users. 

[ 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 testing

unblock netselect/0.3.ds1-29

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

Kernel: Linux 5.10.0-1-686-pae (SMP w/4 CPU threads)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru netselect-0.3.ds1/debian/changelog netselect-0.3.ds1/debian/changelog
--- netselect-0.3.ds1/debian/changelog  2021-07-05 00:14:53.0 +0200
+++ netselect-0.3.ds1/debian/changelog  2021-07-04 23:04:35.0 +0200
@@ -1,3 +1,14 @@
+netselect (0.3.ds1-29) unstable; urgency=high
+
+  * netselect-apt:
+- Fix bug that makes it output some hosts with negative value (Closes: 
920907)
+- Fix bug in the Pelr parsing which prevented it from processing properly
+  the mirrors listed in the Debian website (Closes: 989674)
+  * debian/control: Move curl to depends as it is required by netselect-apt
+   (Closes: 788793)
+
+ -- Javier Fernández-Sanguino Peña   Sun, 04 Jul 2021 
23:04:35 +0200
+
 netselect (0.3.ds1-28) unstable; urgency=medium
 
   * Use debhelper files properly to relocation binaries and
diff -Nru netselect-0.3.ds1/debian/control netselect-0.3.ds1/debian/control
--- netselect-0.3.ds1/debian/control2021-07-05 00:14:53.0 +0200
+++ netselect-0.3.ds1/debian/control2021-07-04 23:04:35.0 +0200
@@ -22,8 +22,7 @@
 
 Package: netselect-apt
 Architecture: all
-Depends: wget, netselect (>= 0.3.ds1-17), ${misc:Depends}
-Recommends: curl
+Depends: wget, netselect (>= 0.3.ds1-17), curl, ${misc:Depends}
 Enhances: apt
 Suggests: dpkg-dev
 Description: speed tester for choosing a fast Debian mirror
diff -Nru netselect-0.3.ds1/netselect-apt netselect-0.3.ds1/netselect-apt
--- netselect-0.3.ds1/netselect-apt 2021-07-05 00:14:53.0 +0200
+++ netselect-0.3.ds1/netselect-apt 2021-07-04 23:04:35.0 +0200
@@ -35,7 +35,7 @@
 # Default distribution
 distro="stable"
 # Default protocol
-protocol="HTTP"
+protocol="http"
 # Number of fastest hosts that will be validated
 test_hosts="10"
 # URL where the mirror list is retrieved from 
@@ -120,7 +120,7 @@
 
 # Second test: do we have the test file we are looking for?
 [ -n "$DEBUG" ] && log "DEBUG: Checking if the file '$test_file' is 
available in site"
-temp=`tempfile`
+temp=`mktemp`
 [ ! -e "$temp" ] && return 0 # Return without error if we cannot create
  # a temporary file
 curl -m 2 -q -s "$host/$test_file"  >$temp 2>&1
@@ -156,12 +156,14 @@
SEARCH="$1"
PROTO="$2"
 hosts=$(cat "$infile" \
-   | perl -n -e '
+   | perl -n -e '
+use warnings;
+use strict;
$/="";
-$country_name  = ".*";
-$country_iso  = "..";
-$country = "'"$country"'";
-$my_country = 1;
+my $country_name  = ".*";
+my $country_iso  = "..";
+my $country = "'"$country"'";
+my $my_country = 1;
 if ( $country ne "" ) {
   $my_country = 0;
   if ( $country =~ /^\w{2}$/ ) {
@@ -184,7 +186,7 @@
next if $_ !~ /Site:/;
if( ( /Includes architectures:.+'"$arch"'.+/i ||
$_ !~ /Includes architectures:/ 
) &&
-   
m@'"$SEARCH"':.*@i && $my_country == 1
+   
m@'"$SEARCH"':.*@i && $my_country == 1
){
print("$1\n");
}}')
@@ -197,7 +199,7 @@
corruptedhosts=$(echo "$out" | egrep '^ *-')
if [ $? -eq 0 ]; then
log "Detected corrupt scores from bug in netselect: 
$corruptedhosts"
-   out=$(echo "$out" | sed -e '/^-/d')
+   out=$(echo "$out" | 

Bug#988289: closed by Håvard Flaget Aasen (Re: htmldoc: CVE-2019-19630)

[Andreas Beckmann]

Control: fixed -1 1.8.27-8+deb9u1
Control: fixed -1 1.9.3-1+deb10u1

'Control: bts command' does not work on -done@, thus resending the commands.


Andreas

Bug#990695: unblock: uif/1.1.9-5

[Mike Gabriel]

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

Please unblock package uif

[ Reason ]
I recently discovered that uif stopped setting up the kernel firewall
(via iptables-legacy still) on a Debian bullseye systems.

I only got around to investigating this today, so I came up with a patch
that replaces single quotes by double quotes when opening pipes.

[ Impact ]
People using uif will have a dysfunctional firewall.

[ Tests ]
Manual tests and debugging to come up with a patch.

[ Risks ]
None, uif is a leaf package.

[ 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 testing

[ Other info ]
None.

unblock uif/1.1.9-5
diff -Nru uif-1.1.9/debian/changelog uif-1.1.9/debian/changelog
--- uif-1.1.9/debian/changelog  2021-03-26 21:09:26.0 +0100
+++ uif-1.1.9/debian/changelog  2021-07-04 22:59:36.0 +0200
@@ -1,3 +1,17 @@
+uif (1.1.9-5) unstable; urgency=medium
+
+  * debian/patches:
++ Add 1003_correctly-quote-when-opening-pipe.patch. Use double quotes in
+  open statement to properly evaluate variables. (Closes: #990692).
+
+ -- Mike Gabriel   Sun, 04 Jul 2021 22:59:36 +0200
+
+uif (1.1.9-4) unstable; urgency=medium
+
+  * debian/watch: Fix Github watch URL.
+
+ -- Mike Gabriel   Wed, 28 Apr 2021 22:27:57 +0200
+
 uif (1.1.9-3) unstable; urgency=medium
 
   * debian/control:
diff -Nru uif-1.1.9/debian/patches/1003_correctly-quote-when-opening-pipe.patch 
uif-1.1.9/debian/patches/1003_correctly-quote-when-opening-pipe.patch
--- uif-1.1.9/debian/patches/1003_correctly-quote-when-opening-pipe.patch   
1970-01-01 01:00:00.0 +0100
+++ uif-1.1.9/debian/patches/1003_correctly-quote-when-opening-pipe.patch   
2021-07-04 22:54:57.0 +0200
@@ -0,0 +1,32 @@
+Description: Use double quotes in open statement to properly evaluate 
variables.
+Author: Mike Gabriel 
+
+--- a/uif.pl
 b/uif.pl
+@@ -1490,7 +1490,7 @@
+ 
+   @$Listing=map { $_."\n" } @$Listing;
+ 
+-  open (IPT, '$iptables_save|');
++  open (IPT, "$iptables_save|");
+ 
+   @oldrules = ;
+   close (IPT);
+@@ -1500,7 +1500,7 @@
+   $SIG{'QUIT'} = 'signalCatcher';
+   $SIG{'TERM'} = 'signalCatcher';
+ 
+-  open (IPT, '|$iptables_restore');
++  open (IPT, "|$iptables_restore");
+ 
+   print IPT @$Listing;
+   close (IPT);
+@@ -1510,7 +1510,7 @@
+   sleep $timeout;
+   }
+   if ($timeout || $SignalCatched || $error) {
+-  open (IPT, '|$iptables_restore');
++  open (IPT, "|$iptables_restore");
+ 
+   print IPT @oldrules;
+   close (IPT);
diff -Nru uif-1.1.9/debian/patches/series uif-1.1.9/debian/patches/series
--- uif-1.1.9/debian/patches/series 2021-03-26 09:01:55.0 +0100
+++ uif-1.1.9/debian/patches/series 2021-07-04 22:50:02.0 +0200
@@ -1,2 +1,3 @@
 1001_use-iptables-legacy.patch
 1002_use-iptables-from-usr-sbin.patch
+1003_correctly-quote-when-opening-pipe.patch
diff -Nru uif-1.1.9/debian/watch uif-1.1.9/debian/watch
--- uif-1.1.9/debian/watch  2018-08-20 12:19:45.0 +0200
+++ uif-1.1.9/debian/watch  2021-04-28 22:27:41.0 +0200
@@ -1,4 +1,4 @@
 version=3
 opts=filenamemangle=s/.*\/v?([\d\.-]+)\.tar\.gz/uif-$1.tar.gz/ \
-https://github.com/cajus/uif/tags .*/archive/v?([\d\.]+).tar.gz
+https://github.com/cajus/uif/tags .*/archive/refs/tags/v?([\d\.]+).tar.gz
 

Bug#990694: unison -addversionno option broken

[Ken Milmore]

Package: unison-2.51+4.11.1
Version: 2.51.3-1

The -addversionno option of unison attempts to invoke the same version of 
unison on the server as on the client, to prevent version mismatches.

This facility seems to have been broken since Debian has augmented the version 
number of the binary with the ocaml library version.

Example to reproduce:



$touch test.src
$unison -addversionno test.src ssh://localhost/test.dst

Unison 2.51.3 (ocaml 4.11.1): Contacting server...
bash: line 1: unison-2.51: command not found
Fatal error: Lost connection with the server



The problem is that "unison-2.51" is invoked over the ssh connection, but the 
unison package no longer provides a binary or symlink with this name.
It does provide:

/usr/bin/unison-2.51+4.11.1 (binary)
/usr/bin/unison (symlink)

A workaround is to install the symlink manually, e.g.:

$sudo ln -s ../../bin/unison-2.51+4.11.1 /usr/local/bin/unison-2.51

Suggested possible bug fixes:

1) Install an additional /usr/bin/unison-2.51 symbolic link in the package, or

2) Modify the unison source to invoke "unison-2.51+4.11.1" instead of 
"unison-2.51" when the -addversionno option is supplied (however this might 
break compatibility with other systems).

Bug#990693: RFS: fonts-gemunu-libre/1.100+ds-1 -- new interpretation to FM Gamunu font

[Gürkan Myczko]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "fonts-gemunu-libre":

 * Package name: fonts-gemunu-libre
   Version : 1.100+ds-1
   Upstream Author : mooniak Pvt. Ltd 
 * URL : http://mooniak.com/gemunu-libre-font/tests/
 * License : OFL-1.1
 * Vcs : 
https://salsa.debian.org/fonts-team/fonts-gemunu-libre

   Section : fonts

It builds those binary packages:

  fonts-gemunu-libre - new interpretation to FM Gamunu font

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


  https://mentors.debian.net/package/fonts-gemunu-libre/

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


  dget -x 
https://mentors.debian.net/debian/pool/main/f/fonts-gemunu-libre/fonts-gemunu-libre_1.100+ds-1.dsc


Changes since the last upload:

 fonts-gemunu-libre (1.100+ds-1) experimental; urgency=medium
 .
   * New upstream version.
   * d/copyright: updated years, added Files-Exluded and 
Upstream-Contact.

   * d/upstream/metadata: added.
   * d/control: added Rules-Requires-Root.
   * Bump debhelper version to 13, drop d/compat.
   * d/rules: build from glyphs file.
   * d/install: update source.
   * d/watch: added filemangle for repacking.

Regards,
--
  Gürkan Myczko

Bug#989037: Bug#988214: fixed in rails 2:6.0.3.7+dfsg-1

[Salvatore Bonaccorso]

Hi Utkarsh,

On Fri, Jun 18, 2021 at 10:23:39PM +0200, Paul Gevers wrote:
> Hi Utkarsh
> 
> On 06-06-2021 06:14, Paul Gevers wrote:
> > I am hoping it's possible to just downgrade the *dependency* in rails
> > only, such that the upload can happen via unstable. There is no "direct
> > bullseye" route. Or do you expect you'll have to make (lots) of changes
> > to rails to match the right ruby-marcel package? If that's the case,
> > than ruby-marcel/unstable isn't a drop in replacement for
> > ruby-marcel/bullseye and I'd expect that ruby-marcel/unstable would need
> > a versioned Breaks for reverse dependent packages (ruby-activestorage),
> > but I'm not seeing that.
> 
> Did your experimenting (as discussed on IRC last week) yield anything?

Since the bullseye release is fastly approaching, do you have any news
on the above?

Regards,
Salvatore

Bug#990690: unblock: pillow/8.1.2+dfsg-0.2

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: car...@debian.org,j...@debian.org

Hi Release team,

Please unblock package pillow

Moritz fixed several CVEs affecting pillow in unstable, and the fixes
should be present in bullseye before the relese to avoid an early need
oa possible DSA or having the CVEs just unfixed in bullseye.

Can you please unblock the package?

Regards,
Salvatore
diff -Nru pillow-8.1.2+dfsg/debian/changelog pillow-8.1.2+dfsg/debian/changelog
--- pillow-8.1.2+dfsg/debian/changelog  2021-04-24 15:51:24.0 +0200
+++ pillow-8.1.2+dfsg/debian/changelog  2021-06-13 18:11:04.0 +0200
@@ -1,3 +1,12 @@
+pillow (8.1.2+dfsg-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Cherrypick security fixes from 8.2:
+- CVE-2021-25287 / CVE-2021-25288 / CVE-2021-28675 / CVE-2021-28676
+  CVE-2021-28677 / CVE-2021-28678 (Closes: #989062)
+
+ -- Moritz Muehlenhoff   Sun, 13 Jun 2021 18:11:04 +0200
+
 pillow (8.1.2+dfsg-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru pillow-8.1.2+dfsg/debian/patches/CVE-2021-25287_CVE-2021-25288.patch 
pillow-8.1.2+dfsg/debian/patches/CVE-2021-25287_CVE-2021-25288.patch
--- pillow-8.1.2+dfsg/debian/patches/CVE-2021-25287_CVE-2021-25288.patch
1970-01-01 01:00:00.0 +0100
+++ pillow-8.1.2+dfsg/debian/patches/CVE-2021-25287_CVE-2021-25288.patch
2021-06-13 18:08:32.0 +0200
@@ -0,0 +1,69 @@
+From 3bf5eddb89afdf690eceaa52bc4d3546ba9a5f87 Mon Sep 17 00:00:00 2001
+From: Eric Soroos 
+Date: Sun, 7 Mar 2021 12:32:12 +0100
+Subject: [PATCH] Fix OOB Read in Jpeg2KDecode CVE-2021-25287,CVE-2021-25288
+
+* For J2k images with multiple bands, it's legal in to have different
+  widths for each band, e.g. 1 byte for L, 4 bytes for A
+* This dates to Pillow 2.4.0
+
+--- pillow-8.1.2+dfsg.orig/src/libImaging/Jpeg2KDecode.c
 pillow-8.1.2+dfsg/src/libImaging/Jpeg2KDecode.c
+@@ -589,7 +589,7 @@ j2k_decode_entry(Imaging im, ImagingCode
+ j2k_unpacker_t unpack = NULL;
+ size_t buffer_size = 0, tile_bytes = 0;
+ unsigned n, tile_height, tile_width;
+-int components;
++int total_component_width = 0;
+ 
+ 
+ stream = opj_stream_create(BUFFER_SIZE, OPJ_TRUE);
+@@ -753,23 +753,40 @@ j2k_decode_entry(Imaging im, ImagingCode
+ goto quick_exit;
+ }
+ 
++if (tile_info.nb_comps != image->numcomps) {
++state->errcode = IMAGING_CODEC_BROKEN;
++state->state = J2K_STATE_FAILED;
++goto quick_exit;
++}
++  
+ /* Sometimes the tile_info.datasize we get back from openjpeg
+-   is less than numcomps*w*h, and we overflow in the
++   is less than sum(comp_bytes)*w*h, and we overflow in the
+shuffle stage */
+ 
+ tile_width = tile_info.x1 - tile_info.x0;
+ tile_height = tile_info.y1 - tile_info.y0;
+-components = tile_info.nb_comps == 3 ? 4 : tile_info.nb_comps;
+-if (( tile_width > UINT_MAX / components ) ||
+-( tile_height > UINT_MAX / components ) ||
+-( tile_width > UINT_MAX / (tile_height * components )) ||
+-( tile_height > UINT_MAX / (tile_width * components ))) {
++
++/* Total component width = sum (component_width) e.g, it's
++ legal for an la file to have a 1 byte width for l, and 4 for
++ a. and then a malicious file could have a smaller tile_bytes
++*/
++
++for (n=0; n < tile_info.nb_comps; n++) {
++// see csize /acsize calcs
++int csize = (image->comps[n].prec + 7) >> 3;
++csize = (csize == 3) ? 4 : csize;
++total_component_width += csize;
++}
++if ((tile_width > UINT_MAX / total_component_width) ||
++(tile_height > UINT_MAX / total_component_width) ||
++(tile_width > UINT_MAX / (tile_height * total_component_width)) ||
++(tile_height > UINT_MAX / (tile_width * total_component_width))) {
+ state->errcode = IMAGING_CODEC_BROKEN;
+ state->state = J2K_STATE_FAILED;
+ goto quick_exit;
+ }
+-
+-tile_bytes = tile_width * tile_height * components;
++  
++tile_bytes = tile_width * tile_height * total_component_width;
+ 
+ if (tile_bytes > tile_info.data_size) {
+ tile_info.data_size = tile_bytes;
diff -Nru pillow-8.1.2+dfsg/debian/patches/CVE-2021-28675.patch 
pillow-8.1.2+dfsg/debian/patches/CVE-2021-28675.patch
--- pillow-8.1.2+dfsg/debian/patches/CVE-2021-28675.patch   1970-01-01 
01:00:00.0 +0100
+++ pillow-8.1.2+dfsg/debian/patches/CVE-2021-28675.patch   2021-06-13 
18:09:24.0 +0200
@@ -0,0 +1,132 @@
+From 22e9bee4ef225c0edbb9323f94c26cee0c623497 Mon Sep 17 00:00:00 2001
+From: Eric Soroos 
+Date: Sun, 7 Mar 2021 19:04:25 +0100
+Subject: [PATCH] Fix DOS in PSDImagePlugin -- CVE-2021-28675
+
+* 

Bug#990214: unblock: dovecot-fts-xapian/1.4.9a-1

[Sebastian Ramacher]

Control: tags -1 moreinfo confirmed

On 2021-06-22 22:50:00 -0400, Joseph Nahmias wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package dovecot-fts-xapian
> 
> This version (1.4.9a) fixes a number of important bugs in the indexer 
> including:
> 
>  + fix indexing of attachments, closes: #985654
>  + fix indexing of accented characters
>  + fix memory errors / segfaults when indexing large mailboxes
> 
> Source debdiff from 1.4.7-1 (currently in testing) to 1.4.9a-1 is attached
> here. Please let me know when approved so I can upload to unstable.
> 
> unblock dovecot-fts-xapian/1.4.9a-1

Assuming that the upload happens soon, please go ahead and remove the
moreinfo tag once the new version is available in unstable.

Cheers

> 
> Thanks,
> --Joe

> diffstat for dovecot-fts-xapian-1.4.7 dovecot-fts-xapian-1.4.9a
> 
>  .gitignore   |   65 ++
>  Makefile.am  |4 
>  PACKAGES/RPM/README.md   |   20 +++
>  PACKAGES/RPM/fts-xapian.spec |   41 ++
>  README.md|   46 +--
>  configure.ac |2 
>  debian/changelog |   11 +
>  debian/watch |4 
>  fts-xapian-config.h.in   |2 
>  src/fts-backend-xapian-functions.cpp |  175 +
>  src/fts-backend-xapian.cpp   |  211 
> ++-
>  src/fts-xapian-plugin.c  |2 
>  src/fts-xapian-plugin.h  |9 -
>  13 files changed, 425 insertions(+), 167 deletions(-)
> 
> diff -Nru -w dovecot-fts-xapian-1.4.7/.gitignore 
> dovecot-fts-xapian-1.4.9a/.gitignore
> --- dovecot-fts-xapian-1.4.7/.gitignore   1969-12-31 19:00:00.0 
> -0500
> +++ dovecot-fts-xapian-1.4.9a/.gitignore  2021-04-24 16:27:55.0 
> -0400
> @@ -0,0 +1,65 @@
> +# http://www.gnu.org/software/automake
> +
> +Makefile.in
> +/ar-lib
> +/mdate-sh
> +/py-compile
> +/test-driver
> +/ylwrap
> +.deps/
> +.dirstamp
> +
> +# http://www.gnu.org/software/autoconf
> +
> +autom4te.cache
> +/autoscan.log
> +/autoscan-*.log
> +/aclocal.m4
> +/compile
> +/config.guess
> +/config.h.in
> +/config.log
> +/config.status
> +/config.sub
> +/configure
> +/configure.scan
> +/depcomp
> +/install-sh
> +/missing
> +/stamp-h1
> +/stamp-h2
> +/stamp.h
> +
> +# https://www.gnu.org/software/libtool/
> +
> +/ltmain.sh
> +/libtool
> +
> +# http://www.gnu.org/software/texinfo
> +
> +/texinfo.tex
> +
> +# http://www.gnu.org/software/m4/
> +
> +m4/libtool.m4
> +m4/ltoptions.m4
> +m4/ltsugar.m4
> +m4/ltversion.m4
> +m4/lt~obsolete.m4
> +
> +# Generated Makefile 
> +# (meta build system like autotools, 
> +# can automatically generate from config.status script
> +# (which is called by configure script))
> +Makefile
> +
> +/dummy-config.h
> +/dummy-config.h.in
> +/fts-xapian-config.h
> +/run-test.sh
> +
> +src/*.o
> +src/*.lo
> +src/*.la
> +
> +src/.libs/**
> diff -Nru -w dovecot-fts-xapian-1.4.7/Makefile.am 
> dovecot-fts-xapian-1.4.9a/Makefile.am
> --- dovecot-fts-xapian-1.4.7/Makefile.am  2021-01-31 14:06:29.0 
> -0500
> +++ dovecot-fts-xapian-1.4.9a/Makefile.am 2021-04-24 16:27:55.0 
> -0400
> @@ -2,5 +2,5 @@
>  
>  ACLOCAL_AMFLAGS = -I m4
>  
> -PACKAGE_VERSION = "1.4.7"
> -VERSION = "1.4.7"
> +PACKAGE_VERSION = "1.4.9a"
> +VERSION = "1.4.9a"
> diff -Nru -w dovecot-fts-xapian-1.4.7/PACKAGES/RPM/README.md 
> dovecot-fts-xapian-1.4.9a/PACKAGES/RPM/README.md
> --- dovecot-fts-xapian-1.4.7/PACKAGES/RPM/README.md   1969-12-31 
> 19:00:00.0 -0500
> +++ dovecot-fts-xapian-1.4.9a/PACKAGES/RPM/README.md  2021-04-24 
> 16:27:55.0 -0400
> @@ -0,0 +1,20 @@
> +As root:
> +
> +Install the development environment and required devel packages:
> +-- dnf groupinstall "Development Tools"
> +-- dnf install rpm-build rpm-devel rpmlint make coreutils diffutils 
> patch rpmdevtools
> +-- dnf install dovecot-devel dovecot libicu-devel icu xapian-core 
> xapian-core-devel
> +
> +As a normal user:
> +
> +Create the ~/rpmbuild tree as a normal user (never build rpms as root):
> +-- rpmdev-setuptree
> +Place the spec file under:
> +~/rpmbuild/SPECS/fts-xapian.spec
> +Place the tar.gz sources under:
> +~/rpmbuild/SOURCES/fts-xapian-1.4.9a.tar.gz
> +Generate the binary rpm with:
> +-- QA_RPATHS=$(( 0x0001|0x0010 )) rpmbuild -bb 
> ~/rpmbuild/SPECS/fts-xapian.spec
> +
> +Your RPM packages will be under ~/rpmbuild/RPMS/x86_64/
> +
> diff -Nru -w dovecot-fts-xapian-1.4.7/PACKAGES/RPM/fts-xapian.spec 
> dovecot-fts-xapian-1.4.9a/PACKAGES/RPM/fts-xapian.spec
> --- dovecot-fts-xapian-1.4.7/PACKAGES/RPM/fts-xapian.spec 1969-12-31 
> 19:00:00.0 -0500
> +++ dovecot-fts-xapian-1.4.9a/PACKAGES/RPM/fts-xapian.spec2021-04-24 
> 16:27:55.0 -0400
> @@ -0,0 +1,41 @@
> +Name:  

Bug#990689: unblock: node-nodemailer/6.4.17-3

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: car...@debian.org,y...@debian.org

Hi Release team,

Please unblock package node-nodemailer

Yadd fixed #990485, CVE-2021-23400 for node-nodemailer in unstable.
Can you please unblock the package (it would not need to, if I
understand correctly, not beeing a key package and having autopkgtests
passing) still to make sure it lands in testing and so in bullseeye
before the release?

Regards,
Salvatore
diff -Nru node-nodemailer-6.4.17/debian/changelog 
node-nodemailer-6.4.17/debian/changelog
--- node-nodemailer-6.4.17/debian/changelog 2021-01-21 06:26:01.0 
+0100
+++ node-nodemailer-6.4.17/debian/changelog 2021-06-30 14:59:47.0 
+0200
@@ -1,3 +1,11 @@
+node-nodemailer (6.4.17-3) unstable; urgency=medium
+
+  * Fix GitHub tags regex
+  * Fix header injection vulnerability in address object
+(Closes: #990485, CVE-2021-23400)
+
+ -- Yadd   Wed, 30 Jun 2021 14:59:47 +0200
+
 node-nodemailer (6.4.17-2) unstable; urgency=medium
 
   * Ignore cookie test (Closes: #980702)
diff -Nru node-nodemailer-6.4.17/debian/control 
node-nodemailer-6.4.17/debian/control
--- node-nodemailer-6.4.17/debian/control   2021-01-21 06:09:40.0 
+0100
+++ node-nodemailer-6.4.17/debian/control   2021-04-15 20:35:08.0 
+0200
@@ -2,7 +2,7 @@
 Section: javascript
 Priority: optional
 Maintainer: Debian Javascript Maintainers 

-Uploaders: Xavier Guimard 
+Uploaders: Yadd 
 Testsuite: autopkgtest-pkg-nodejs
 Build-Depends:
  debhelper-compat (= 13)
diff -Nru node-nodemailer-6.4.17/debian/copyright 
node-nodemailer-6.4.17/debian/copyright
--- node-nodemailer-6.4.17/debian/copyright 2021-01-21 06:09:40.0 
+0100
+++ node-nodemailer-6.4.17/debian/copyright 2021-04-15 20:35:08.0 
+0200
@@ -8,7 +8,7 @@
 License: Expat
 
 Files: debian/*
-Copyright: 2019-2020, Xavier Guimard 
+Copyright: 2019-2020, Yadd 
 License: Expat
 
 Files: debian/tests/test_modules/base32.js/*
diff -Nru node-nodemailer-6.4.17/debian/patches/CVE-2021-23400.patch 
node-nodemailer-6.4.17/debian/patches/CVE-2021-23400.patch
--- node-nodemailer-6.4.17/debian/patches/CVE-2021-23400.patch  1970-01-01 
01:00:00.0 +0100
+++ node-nodemailer-6.4.17/debian/patches/CVE-2021-23400.patch  2021-06-30 
14:58:51.0 +0200
@@ -0,0 +1,80 @@
+Description: fix header injection vulnerability in address object
+Author: Andris Reinman 
+Origin: upstream, https://github.com/nodemailer/nodemailer/commit/7e02648c
+Bug: https://github.com/nodemailer/nodemailer/issues/1289
+Bug-Debian: https://bugs.debian.org/990485
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2021-06-30
+
+--- a/lib/mime-node/index.js
 b/lib/mime-node/index.js
+@@ -1130,9 +1130,9 @@
+ address.address = this._normalizeAddress(address.address);
+ 
+ if (!address.name) {
+-values.push(address.address);
++values.push(address.address.indexOf(' ') >= 0 ? 
`<${address.address}>` : `${address.address}`);
+ } else if (address.name) {
+-values.push(this._encodeAddressName(address.name) + ' <' 
+ address.address + '>');
++values.push(`${this._encodeAddressName(address.name)} 
<${address.address}>`);
+ }
+ 
+ if (address.address) {
+@@ -1141,9 +1141,8 @@
+ }
+ }
+ } else if (address.group) {
+-values.push(
+-this._encodeAddressName(address.name) + ':' + 
(address.group.length ? this._convertAddresses(address.group, uniqueList) : 
'').trim() + ';'
+-);
++let groupListAddresses = (address.group.length ? 
this._convertAddresses(address.group, uniqueList) : '').trim();
++
values.push(`${this._encodeAddressName(address.name)}:${groupListAddresses};`);
+ }
+ });
+ 
+@@ -1157,13 +1156,17 @@
+  * @return {String} address string
+  */
+ _normalizeAddress(address) {
+-address = (address || '').toString().trim();
++address = (address || '')
++.toString()
++.replace(/[\x00-\x1F<>]+/g, ' ') // remove unallowed characters
++.trim();
+ 
+ let lastAt = address.lastIndexOf('@');
+ if (lastAt < 0) {
+ // Bare username
+ return address;
+ }
++
+ let user = address.substr(0, lastAt);
+ let domain = address.substr(lastAt + 1);
+ 
+@@ -1172,7 +1175,24 @@
+ // 'jõgeva.ee' will be converted to 'xn--jgeva-dua.ee'
+ // non-unicode domains are left as is
+ 
+-return user + '@' + punycode.toASCII(domain.toLowerCase());
++let encodedDomain;
++
++try {
++encodedDomain = punycode.toASCII(domain.toLowerCase());
++} catch (err) {
++// keep as is?
++

Bug#990688: unblock: node-mermaid/8.7.0+ds+~cs27.17.17-3

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: car...@debian.org,y...@debian.org

Hi Release team,

Please unblock package node-mermaid

Yadd fixed CVE-2021-35513 affecting node-mermaid in unstable with a
targetted fix from upstream. Can you please unlbock the package and
make sure it lands in testing and so bullseye in time before the
release?

I'm attaching the debdiff as generated by the upload from Yadd.

Regards,
Salvatore
diff -Nru node-mermaid-8.7.0+ds+~cs27.17.17/debian/changelog 
node-mermaid-8.7.0+ds+~cs27.17.17/debian/changelog
--- node-mermaid-8.7.0+ds+~cs27.17.17/debian/changelog  2020-10-19 
14:00:00.0 +0200
+++ node-mermaid-8.7.0+ds+~cs27.17.17/debian/changelog  2021-06-29 
14:46:20.0 +0200
@@ -1,3 +1,10 @@
+node-mermaid (8.7.0+ds+~cs27.17.17-3) unstable; urgency=medium
+
+  * Team upload
+  * Fix XSS vulnerability when antiscript is used (Closes: CVE-2021-35513)
+
+ -- Yadd   Tue, 29 Jun 2021 14:46:20 +0200
+
 node-mermaid (8.7.0+ds+~cs27.17.17-2) unstable; urgency=medium
 
   * Source-only-upload 
diff -Nru node-mermaid-8.7.0+ds+~cs27.17.17/debian/patches/CVE-2021-35513.patch 
node-mermaid-8.7.0+ds+~cs27.17.17/debian/patches/CVE-2021-35513.patch
--- node-mermaid-8.7.0+ds+~cs27.17.17/debian/patches/CVE-2021-35513.patch   
1970-01-01 01:00:00.0 +0100
+++ node-mermaid-8.7.0+ds+~cs27.17.17/debian/patches/CVE-2021-35513.patch   
2021-06-29 14:44:46.0 +0200
@@ -0,0 +1,33 @@
+Description: Small positoining fix for parallell processes and nested
+Author: Knut Sveidqvist 
+Origin: upstream, https://github.com/mermaid-js/mermaid/pull/2123/files
+Bug: https://github.com/mermaid-js/mermaid/issues/2122
+Bug-Debian: https://bugs.debian.org/990449
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2021-06-29
+
+--- a/src/dagre-wrapper/clusters.js
 b/src/dagre-wrapper/clusters.js
+@@ -194,7 +194,7 @@
+   const rectBox = rect.node().getBBox();
+   node.width = rectBox.width;
+   node.height = rectBox.height;
+-
++  node.diff = -node.padding / 2;
+   node.intersect = function(point) {
+ return intersectRect(node, point);
+   };
+--- a/src/diagrams/common/common.js
 b/src/diagrams/common/common.js
+@@ -26,6 +26,10 @@
+   break;
+ }
+   }
++
++  rs = rs.replace('javascript:', '#');
++  rs = rs.replace('

Bug#990687: unblock: mutt/2.0.5-4.1

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: car...@debian.org

Hi release team,

Please unblock package mutt

[ Reason ]
mutt in bullseye is affected by CVE-2021-32055, #988106. Should thoug
be noted that the $imap_qresync setting for QRESYNC is not enabled by
default. It looked to me still worth trying to get the fix into
bullseye before the release.

Note, the same issue would have affected as well neomutt, but back
when I prepared the NMU for mutt, I did unfortunately not found time
to do as well the neomutt NMU. This is surely kind of unfortunate :(

[ Impact ]
CVE-2021-32055 would remain open.

[ Tests ]
None specifically.

[ Risks ]
Would consider it low, and it is a feature not used by default. The
package was 22 days now in unstable without any regression report
reported specifically targetting this update.

[ 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 testing

[ Other info ]
None.

unblock mutt/2.0.5-4.1

Regards,
Salvatore
diff -Nru mutt-2.0.5/debian/changelog mutt-2.0.5/debian/changelog
--- mutt-2.0.5/debian/changelog 2021-03-20 17:26:12.0 +0100
+++ mutt-2.0.5/debian/changelog 2021-06-06 21:11:36.0 +0200
@@ -1,3 +1,11 @@
+mutt (2.0.5-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix seqset iterator when it ends in a comma (CVE-2021-32055)
+(Closes: #988106)
+
+ -- Salvatore Bonaccorso   Sun, 06 Jun 2021 21:11:36 +0200
+
 mutt (2.0.5-4) unstable; urgency=medium
 
   * debian/patches:
diff -Nru mutt-2.0.5/debian/patches/series mutt-2.0.5/debian/patches/series
--- mutt-2.0.5/debian/patches/series2021-03-20 17:24:06.0 +0100
+++ mutt-2.0.5/debian/patches/series2021-06-06 21:11:36.0 +0200
@@ -13,3 +13,4 @@
 upstream/528233-readonly-open.patch
 upstream/980924-updated-german-translation.patch
 upstream/985152-body-color-slowness.patch
+upstream/Fix-seqset-iterator-when-it-ends-in-a-comma.patch
diff -Nru 
mutt-2.0.5/debian/patches/upstream/Fix-seqset-iterator-when-it-ends-in-a-comma.patch
 
mutt-2.0.5/debian/patches/upstream/Fix-seqset-iterator-when-it-ends-in-a-comma.patch
--- 
mutt-2.0.5/debian/patches/upstream/Fix-seqset-iterator-when-it-ends-in-a-comma.patch
1970-01-01 01:00:00.0 +0100
+++ 
mutt-2.0.5/debian/patches/upstream/Fix-seqset-iterator-when-it-ends-in-a-comma.patch
2021-06-06 21:11:36.0 +0200
@@ -0,0 +1,39 @@
+From: Kevin McCarthy 
+Date: Mon, 3 May 2021 13:11:30 -0700
+Subject: Fix seqset iterator when it ends in a comma.
+Origin: 
https://gitlab.com/muttmua/mutt/-/commit/7c4779ac24d2fb68a2a47b58c7904118f40965d5
+Bug-Debian: https://bugs.debian.org/988106
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-32055
+
+If the seqset ended with a comma, the substr_end marker would be just
+before the trailing nul.  In the next call, the loop to skip the
+marker would iterate right past the end of string too.
+
+The fix is simple: place the substr_end marker and skip past it
+immediately.
+---
+ imap/util.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+diff --git a/imap/util.c b/imap/util.c
+index c529fd8fba3c..488e8396d269 100644
+--- a/imap/util.c
 b/imap/util.c
+@@ -1036,13 +1036,11 @@ int mutt_seqset_iterator_next (SEQSET_ITERATOR *iter, 
unsigned int *next)
+ if (iter->substr_cur == iter->eostr)
+   return 1;
+ 
+-while (!*(iter->substr_cur))
+-  iter->substr_cur++;
+ iter->substr_end = strchr (iter->substr_cur, ',');
+ if (!iter->substr_end)
+   iter->substr_end = iter->eostr;
+ else
+-  *(iter->substr_end) = '\0';
++  *(iter->substr_end++) = '\0';
+ 
+ range_sep = strchr (iter->substr_cur, ':');
+ if (range_sep)
+-- 
+2.32.0.rc0
+

Bug#990500: unblock: lxml/4.6.3+dfsg-0.1

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2021-06-30 23:02:33 +0200, Paul Gevers wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: unblock
> Severity: normal
> 
> Please unblock package lxml
> 
> [ Reason ]
> The source of lxml contained a file that's marked as unacceptable by
> ftp-master and as such a future upload of lxml would hit the
> auto-reject list. To avoid problems with security uploads, I prefer to
> fix the issue now. The file was a image shipped with the
> documentation, which wasn't even used.
> 
> In the process of fixing this issue, I discovered that the
> documentation package was nearly empty and didn't contain any
> documentation. This is fixed by enabling the build of the
> documentation.
> 
> [ Impact ]
> If not unblocked, security or plain pu uploads will have to take
> remove the file at that time.
> 
> [ Tests ]
> The removed file is just an unlinked image. I have checked that the
> package now contains the documentation files.
> 
> [ Risks ]
> Close to 0 risk as it's just removing an image and building
> documentation files.
> 
> [ 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 testing
> 
> unblock lxml/4.6.3+dfsg-0.1

> diff -Nru lxml-4.6.3/debian/changelog lxml-4.6.3+dfsg/debian/changelog
> --- lxml-4.6.3/debian/changelog   2021-03-22 14:31:55.0 +0100
> +++ lxml-4.6.3+dfsg/debian/changelog  2021-06-26 19:40:37.0 +0200
> @@ -1,3 +1,11 @@
> +lxml (4.6.3+dfsg-0.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload
> +  * Repack upstream to drop non-free and unused file (Closes: #988717)
> +  * Build and ship documentation (Closes: #799334)
> +
> + -- Paul Gevers   Sat, 26 Jun 2021 19:40:37 +0200
> +
>  lxml (4.6.3-1) unstable; urgency=high
>  
>* New upstream version.
> diff -Nru lxml-4.6.3/debian/control lxml-4.6.3+dfsg/debian/control
> --- lxml-4.6.3/debian/control 2020-12-07 14:42:24.0 +0100
> +++ lxml-4.6.3+dfsg/debian/control2021-06-26 19:40:37.0 +0200
> @@ -9,6 +9,7 @@
>python3-setuptools (>= 0.6.29),
>python3-bs4,
>python3-html5lib,
> +  python3-lxml ,
>cython3, cython3-dbg,
>python3-sphinx-autoapi,
>  X-Python-Version: all
> diff -Nru lxml-4.6.3/debian/rules lxml-4.6.3+dfsg/debian/rules
> --- lxml-4.6.3/debian/rules   2020-07-17 11:16:59.0 +0200
> +++ lxml-4.6.3+dfsg/debian/rules  2021-06-26 19:40:37.0 +0200
> @@ -24,6 +24,9 @@
>   touch $@
>  build3-python%: prebuild
>   python$* setup.py build
> +ifeq (,$(filter nodoc,$(DEB_BUILD_OPTIONS)))
> + python$* doc/mkhtml.py doc/html . $(UPSTREAMVER)
> +endif

Shouldn't this use the just built version of lxml, e.g., by setting the
appropriate PYTHONPATH, instead of the old packaged lxml in python3-lxml?

Cheers

>   touch $@
>  dbg-build3-python%: prebuild
>   python$*-dbg setup.py build
> Binary files /tmp/nGluINxi3b/lxml-4.6.3/doc/html/flattr-badge-large.png and 
> /tmp/DP0ayk9l1g/lxml-4.6.3+dfsg/doc/html/flattr-badge-large.png differ





-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#990679: unblock: [pre-approval] privacybadger/2021.6.8-1

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2021-07-04 17:10:49 +, John Scott wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: 981...@bugs.debian.org
> Control: block 981702 by -1
> 
> Please unblock package privacybadger
> 
> [ Reason ]
> Privacy Badger is unique and different from other anti-tracking
> extensions in that instead of using artificial whitelists and
> blacklists, it learns based on one's browsing behavior. However, it was
> privately disclosed by Google's Security Team that Privacy Badger's
> learning, which is unique to each user, can itself enable
> fingerprinting:
> https://www.eff.org/deeplinks/2020/10/privacy-badger-changing-protect-you-better
> 
> To address this, newer versions of Privacy Badger work by everyone
> using the same whitelists, yellowlists, and blacklists, which are
> aggregated from everyone's learning data.
> 
> [ Impact ]
> If this unblock isn't granted, or it's not possible for Privacy Badger
> to be shipped in bullseye-updates during the release cycle, then users
> would be left more vulnerable to fingerprinting, as they could be
> identified based on their older Privacy Badger versions. Upstream has
> indicated that this situation would be unacceptable (and I concur), so
> it would be better to remove the package altogether then.
> 
> This situation is not unlike the need to ship up-to-date ClamAV data in
> stable-updates.
> 
> [ Tests ]
> Since this is a browser extension it's difficult to automate testing. I
> have tested with Firefox ESR, Firefox non-ESR, and Chromium that it
> works.
> 
> [ Risks ]
> This package is a leaf package, and if this package were to be instead
> removed from Bullseye, users would need to install it manually by
> fetching the extension from another source. The debdiff is quite large,
> but consists mostly of changes to the website data and translations.
> 
> [ 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 testing
> 
> This is a request for pre-approval since I need to seek a sponsor to
> update the package anyway. My debdiff was detected as malware so you'll
> have to fetch it from
> https://salsa.debian.org/-/snippets/549/raw/master/privacybadger.diff

 119 files changed, 37556 insertions(+), 16534 deletions(-)

This is too much for us to sensibly review. If possible, please provide
a filtered debdiff (e.g., by filtering the website data and
translations).

Cheers

> 
> unblock privacybadger/2021.6.8-1
> 
> 



-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#990559: Please unblock package mdevctl 0.81-1

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2021-07-02 07:37:22 +0200, Christian Ehrhardt wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Hi,
> please unblock mdevctl 0.81-1.
> 
> It fixes a problem with an allowed combined usage two parameters.
> v0.78 -> 0.81 sounds a lot, but that is due to the way upstream creates
> versions which essentially is a counter of git commits.
> Therefore the only real change is [1] which should be ok for the freeze time.
> 
> There are two packaging-only changes which I had in git but not
> uploaded yes (as they didn't qualify for an upload without any fix.
> But both are no-impact changes (compat level while the package has not much
> that is affected by it and the drop of the unused d/source/local-options.
> 
> The builds all LGTM, see [2]. I have installed the new build and it works
> as expected:
> 
> Before
> # mdevctl define -p 0.0.0033 --jsonfile mdev_nodedev.json
> /usr/sbin/mdevctl: line 183:
> /etc/mdevctl.d/0.0.0033/eea1c8dc-ce6d-42dd-bd26-02e3b707ff95: No such
> file or directory
> After
> # mdevctl define -p 0.0.0033 --jsonfile mdev_nodedev.json
> 83123a52-3147-44d1-9154-1175e266804e
> 
> The package has no autopkgtests as they would be superficial and not much
> worth or would need mdev splittable GPUs or such on the test systems which we
> can not assume/expect to have. Therefore I need to ask you via this ubblock
> request. I hope that this is sufficient to unblock, if you need anything
> else please let me know.
> 
> [1]: https://github.com/mdevctl/mdevctl/commit/e6cf620b4b04c6
> [2]: 
> https://buildd.debian.org/status/fetch.php?pkg=mdevctl=all=0.78-1=1606290427

Please attach a debdiff between the version in testing and unstable.

Regarding the packaging changes: it's too late to bump debhelper compat.
See https://release.debian.org/bullseye/freeze_policy.html. Please
revert that change (or show that the change does not cause any
differences in the produced binary packages).

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#951257: udevadm: please exit nonzero with "Running in chroot, ignoring request." when /proc is not mounted

[Vasyl Gello]

Dear colleagues,

I trapped into the same issue testing the installation of udisks2 on top of 
udev from buster-backports.
An inexperienced user following the random guides from Internet can issue 
something like:

apt-get install -t buster-backports udisks2

(or package depending on udisks2) and get the failed install.

The workaround patch to udisks2 that fixes the issue for bullseye is
https://salsa.debian.org/utopia-team/udisks2/-/commit/050527c84bed6bc6c90d46d3eb612c48baf92e7d
but it was never backported to buster-updates. Can you please do it?
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#990670: [pre-approval] unblock: python-apt/2.2.1

[Sebastian Ramacher]

Control: tags -1 confirmed moreinfo

On 2021-07-04 14:25:00 +0200, Julian Andres Klode wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: j...@debian.org
> 
> Please unblock package python-apt
> 
> [ Reason ]
> 
> - Mark python-apt-common as Multi-Arch: common to unblock the
>   crossgrader script (#968458). People have very varied understanding
>   about severity of this; it's just a single line anyway.
> - update the mirror lists.
> 
> [ Impact ]
> People can't crossgrade and might see outdated mirror information
> in mirror selection tools like software-properties
> 
> [ Tests ]
> No code changed, just metadata. Unit tests are run at
> build time and during autopkgtest.
> 
> 
> [ Risks ]
> 
> It's just metadata changes, only risk is like regressions
> in toolchain since last upload.
> 
> [ 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 testing
> 
> unblock python-apt/2.2.1

ACK, please remove the moreinfo tag once the ne wversion is available in
unstable.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#990678: budgie-desktop: Software windows don't display correctly, move badly or stay on the screen after being shut

[Pascal]

Package: budgie-desktop
Version: 10.5.2-3
Followup-For: Bug #990678
X-Debbugs-Cc: pascal.mart...@gmx.fr

Dear Maintainer,

Thanks for your very quick response. I did not contact the upstream Budgie
maintainers but the Debian Budgie maintainers at  on
2021 March the 19th. It was because I did not use Reportbug yet at the time.

I must say I am not a software professional, just a Linux/Debian & free
software passionate. I used to program a little (Basic, C & Assembler) 20/30
years ago before I knew Linux more recently in 2015. As a non-professional,
knowing what package to choose for a bug report is difficult.

My description of the bug is reported to be a bit long but it is also a bit
unfair because this problem of windows staying displayed on the screen (though
being shut) seems to have been corrected now. I got back to Bugdie just
yesterday after several months and I think I have noticed still a few minor
problems, difficult to describe & report. That's why I suggested further
testing, from the maintainers or the readers/users.

The most noticeable problem on my PC is with MPV. I made a few more tests and I
remarked that MPV had to be launched fullscreen a little time (say, more than
15s) for the bug to appear (can't move the window with the mouse). If you do
the test rapidly, the video window displays correctly. I also remarked that
launching a video with MPV in Gnome or Budgie (I don't know for other desktops)
produced a horizontal defect in the upper part of the image (10% of it) for a
fraction of a second. Nothing serious, and of no consequence in Gnome. I
mention it just for info to help, it may be the sign of a malfunction in MPV.

As for my Graphics (Radeon), I had to install regular Debian non-free firmware
for quickness, my PC could not run properly with totally free software (esp.
Wifi, brightness & sound control apparently). All my installation is quite
regular, with a few (reported by Synaptic) obsolete packages like
gstreamer1.0-crystalhd. No non-Debian deb packages.

Please I am not waiting to any quick response for myself, I reported this bug
for the maintainers & the community. Bullseye will become stable soon and it
will be better if all works fine. And Budgie is maybe my 2nd favourite desktop
after Gnome itself. KDE of course is wonderful & efficient (maybe because it's
all C++ & Qt). But it's a huge installation whereas Budgie just requires a
little installation on top (or besides) of Gnome. I think that what I like best
in Gnome (& Budgie) is its totally free project & effort to find a kind of
harmony between all these different programming languages (C, C++, Python,
Guile, Javascript, Vala, etc.).

Cordially,
Pascal.

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

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

Versions of packages budgie-desktop depends on:
ii  budgie-core  10.5.2-3
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  gir1.2-budgie-1.010.5.2-3
ii  gnome-control-center 1:3.38.4-1
ii  gnome-menus  3.36.0-1
ii  network-manager-gnome1.20.0-3

Versions of packages budgie-desktop recommends:
ii  budgie-desktop-view  1.1.1-1

Versions of packages budgie-desktop suggests:
ii  gnome-terminal  3.38.3-1
ii  nautilus3.38.2-1
pn  slick-greeter   

Bug#990651: unblock: nx-libs/2:3.5.99.26-2

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2021-07-03 22:17:59 +0200, Mike Gabriel wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package nx-libs
> 
> [ Reason ]
> Several important upstream issues have recently been resolved in nx-libs.
> The fixes for those issues have been cherry-picked into this version of
> Debian's nx-libs package.
> 
> +  * debian/patches:
> ++ Add 0001_Compext.c-fix-comparisons-of-16bit-sequence-numbers.patch.
> +  Compext.c: fix comparisons of 16bit sequence numbers. (Closes:
> +  #990647).
> 
> -> Fixes flawed 16 bit comparison. This resolves an "Xlib: unexpected async
> reply (sequence 0x94b01439)!" and clipboard pasting being broken afterwards.
> 
> ++ Add 0002_Forward-ClientMessages-to-nxproxy-side.patch.
> +  Forward ClientMessages to nxproxy side. (Closes: #990649).
> 
> -> Resolve window control problems with client side decorated windows if
> nxagent is used in rootless/seamless session mode.
> 
> ++ Add 0003_randr-Do-not-update-ConnectionInfo-if-NULL.patch.
> +  randr: Do not update ConnectionInfo if NULL (and avoid the nxagent
> +  Xserver from crashing). (Closes: #990650).
> 
> -> Regression fix of unknown origin. Could be resolved by cherry-picking
> a commit original from X.Org upstream. 
> 
> ++ Add 0004_document-additional-options-only-nxagent-knows-about.patch.
> +  Update man page and --help documentation of nxproxy/nxagent.
> 
> -> Recently, upstream added a documentation improvement that now
> documents various session options that were undocumented before.
> 
> ++ Adjust 0004_document-additional-options-only-nxagent-knows-about.patch.
> +  Version 3.5.99.26 does not yet have the textclipboard= session
> +  parameter.
> 
> -> The above patch added one option that is not yet available in 3.5.99.26,
> So we removed this bit of documenation for nx-libs in Debian (bullseye).
> 
> 
> [ Impact ]
> The "connect to local X11 desktop" (shadow session support) would be broken, 
> 
> The clipboard between nxagent and the local Xserver might break in some 
> situations.
> 
> There would be problems with client side decorated windows.
> 
> There would be undocumented options.
> 
> [ Tests ]
> Manual tests.
> 
> [ Risks ]
> X2Go sessions being busted if some of the above commits is flawed.
> 
> [ 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 testing

The debdiff appears to be missing.

Cheers

> 
> [ Other info ]
> None.
> 
> unblock nx-libs/2:3.5.99.26-2
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#990183: libopenscap8: libopenscap.so.8 is missing from libopenscap8 and is expected by scap-workbench

[Sebastian Ramacher]

Hi

On 2021-07-04 04:04:13 +0900, Hideki Yamane wrote:
> On Sat, 3 Jul 2021 21:36:53 +0900
> Hideki Yamane  wrote:
> >  Mostly done, still have an error with autopkgtest for python3-openscap
> 
>  Updated. Passed all salsa-ci test as below, and eliminate most of
>  lintian warning/info.
>  https://salsa.debian.org/henrich/openscap/-/pipelines/265972
> 
> 
> diff -Nru openscap-1.3.4/debian/changelog openscap-1.3.4/debian/changelog
> --- openscap-1.3.4/debian/changelog   2021-02-02 00:22:30.0 +0900
> +++ openscap-1.3.4/debian/changelog   2021-06-30 16:33:53.0 +0900
> @@ -1,3 +1,37 @@
> +openscap (1.3.4-1.1) UNRELEASED; urgency=medium
> +
> +  * Non-maintainer upload.
> +
> +  * Package structure changes
> +- Apply soname change (libopenscap8 -> 25)
> +- Split libopenscap25 to openscap-scanner, openscap-utils and
> +  openscap-common
> +- Drop -dbg package and unnecessary lintian-overrides
> +  * debian/control
> +- Specify https for upstream URL
> +- Use debhelper-compat (= 13) to not forget to install necessary files
> +  with dh_missing
> +- Add missing dependencies: libacl1-dev, libblkid-dev, libglib2.0-dev,
> +  libyaml-dev, librpm-dev, libpopt-dev, libprocps-dev, libopendbx1-dev,
> +  libxmlsec1-dev, doxygen, graphviz, asciidoc,
> +  * Drop unnecessary debian/compat
> +  * debian/rules
> +- Enable documentation build
> +- Enable hardening
> +  * Add openscap-common.docs to install HTML docs
> +  * debian/openscap-scanner.install
> +- Install bash-completion
> +  * openscap-utils.install
> +- Install autotailor and scap-as-rpm
> +  * Add debian/openscap-{scanner,utils}.manpages
> +
> +  * Trim trailing whitespace.
> +  * Update watch file format version to 4.
> +  * Set upstream metadata fields: Bug-Database, Bug-Submit.
> +  * Drop unnecessary dependency on dh-autoreconf.
> +
> + -- Hideki Yamane   Wed, 30 Jun 2021 16:33:53 +0900

Doing a transition now and adding new binary packages is already
stretching the rules a lot. So please keep all the other changes to a
minimum. Especially changing debhelper compat level is undesirable
during the freeze (see
https://release.debian.org/bullseye/freeze_policy.html)

More comments below.

> +
>  openscap (1.3.4-1) unstable; urgency=medium
>  
>* New upstream version 1.3.4
> diff -Nru openscap-1.3.4/debian/compat openscap-1.3.4/debian/compat
> --- openscap-1.3.4/debian/compat  2021-02-02 00:22:30.0 +0900
> +++ openscap-1.3.4/debian/compat  1970-01-01 09:00:00.0 +0900
> @@ -1 +0,0 @@
> -11
> diff -Nru openscap-1.3.4/debian/control openscap-1.3.4/debian/control
> --- openscap-1.3.4/debian/control 2021-02-02 00:22:30.0 +0900
> +++ openscap-1.3.4/debian/control 2021-06-30 16:33:53.0 +0900
> @@ -2,7 +2,7 @@
>  Priority: optional
>  Maintainer: Pierre Chifflier 
>  Uploaders: Philippe Thierry 
> -Build-Depends: debhelper (>= 13),
> +Build-Depends: debhelper-compat (= 13),
>  cmake,
>  libpcre3-dev,
>  libxml2-dev,
> @@ -18,19 +18,30 @@
>  libattr1-dev,
>  libldap2-dev,
>  libbz2-dev,
> +libacl1-dev,
> +libblkid-dev,
> +libglib2.0-dev,
> +libyaml-dev,
> +librpm-dev,
> +libpopt-dev,
> +libprocps-dev,
> +libopendbx1-dev,
> +libxmlsec1-dev,
> +doxygen, graphviz,
> +asciidoc,
>  pkg-config,
>  dh-python,
>  chrpath,
>  libdbus-1-dev
> +Section: admin
>  X-Python3-Version: >= 3.9
>  Standards-Version: 4.5.1
> -Section: libs
> -Homepage: http://www.open-scap.org/
> +Homepage: https://www.open-scap.org/
>  
>  Package: libopenscap-dev
>  Section: libdevel
>  Architecture: linux-any
> -Depends: libopenscap8 (= ${binary:Version}), ${misc:Depends}, 
> ${python3:Depends}, libjs-jquery
> +Depends: libopenscap25 (= ${binary:Version}), ${misc:Depends}, 
> ${python3:Depends}, libjs-jquery
>  Description: Set of libraries enabling integration of the SCAP line of 
> standards
>   OpenSCAP is a set of open source libraries providing an easier path
>   for integration of the SCAP line of standards. SCAP is a line of
> @@ -48,13 +59,13 @@
>   .
>   This package contains the development files for OpenSCAP.
>  
> -Package: libopenscap8
> +Package: libopenscap25
>  Section: libs
>  Architecture: linux-any
> -Conflicts: libopenscap0, libopenscap1, libopenscap3
> -Replaces: libopenscap0, libopenscap1, libopenscap3
> +Conflicts: libopenscap0, libopenscap1, libopenscap3, libopenscap8,
> +Replaces: libopenscap0, libopenscap1, libopenscap3, libopenscap8,
>  Pre-Depends: ${misc:Pre-Depends}
> -Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends}
> +Depends: ${shlibs:Depends}, ${misc:Depends},
>  Description: Set of libraries enabling integration of the SCAP line of 
> standards
>   OpenSCAP is a set of open source libraries providing an easier path
>   for integration of the SCAP line of standards. SCAP is a line of
> @@ -69,11 +80,13 @@
>* Common Vulnerability Scoring System 

Bug#981702: RFS: privacybadger/2021.2.2-1 -- browser extension automatically learns to block invisible trackers

[John Scott]

On Wed, 2021-06-09 at 17:07 +0200, Tobias Frost wrote:
> >     * Friendly takeover back into the WebExt team.
> 
> I can't find any documentation about that have been ACKed by the
> current maintainer. (CCing Jonas so that he can response/confirm, to
> put it on record that this is not an hijack…)
I've attached a digitally signed message from him asserting it's okay.

I've applied for an unblock request with the release team to see about
uploading it to unstable.


Re:_Privacy_Badger_WebExtension_package.mbox
Description: application/mbox


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

Bug#990365: unblock: nemo/4.8.6-2

[Sebastian Ramacher]

On 2021-07-03 16:32:44 +0200, Fabio Fantoni wrote:
> Il 29/06/2021 22:52, Sebastian Ramacher ha scritto:
> > > The diff: 
> > > https://salsa.debian.org/cinnamon-team/nemo/-/compare/debian%2F4.8.6-1...debian%2F4.8.6-2
> > Please attach a debdiff of the source packages in testing and unstable to 
> > the bug.
> > 
> > Cheers
> 
> Thanks for reply, the link to salsa with diff from 4.8.6-1 to 4.8.6-2 was
> correct and working, however now I attached the diff generates from debdiff
> dsc of testing and unstable as requested.

It's not that the salsa diff isn't working, but we want the debdiffs in
the bug report so that if we spot anything we can directly address those
issues. It also saves us a context switch which makes it more likely
that we actually process the unblock request.

Cheers

> 

> diff -Nru nemo-4.8.6/debian/changelog nemo-4.8.6/debian/changelog
> --- nemo-4.8.6/debian/changelog   2021-03-12 23:47:45.0 +0100
> +++ nemo-4.8.6/debian/changelog   2021-06-20 15:51:07.0 +0200
> @@ -1,3 +1,10 @@
> +nemo (4.8.6-2) unstable; urgency=medium
> +
> +  * d/patches: nemo-tree-sidebar.c: Fix states for pin/unpin and
> +create-folder menu items (Closes: #988924)
> +
> + -- Fabio Fantoni   Sun, 20 Jun 2021 15:51:07 +0200
> +
>  nemo (4.8.6-1) unstable; urgency=medium
>  
>* New upstream version 4.8.6
> diff -Nru nemo-4.8.6/debian/patches/fix-states-pin-create-folder-menu.patch 
> nemo-4.8.6/debian/patches/fix-states-pin-create-folder-menu.patch
> --- nemo-4.8.6/debian/patches/fix-states-pin-create-folder-menu.patch 
> 1970-01-01 01:00:00.0 +0100
> +++ nemo-4.8.6/debian/patches/fix-states-pin-create-folder-menu.patch 
> 2021-06-20 15:51:07.0 +0200
> @@ -0,0 +1,134 @@
> +Author: Michael Webster 
> +Description: nemo-tree-sidebar.c: Fix states for pin/unpin and
> + create-folder menu items.
> +
> +- Don't allow pinning of items in the root tree level.
> +- Correctly set visiblity/sensitivity of the create-folder menu item -
> +  disallow in non-writeable locations and in favorites (this is
> +  already forbidden elsewhere).
> +- Fix incorrect jump when right-clicking a non-selected tree entry.
> +
> +Fixes #2759
> +Origin: 
> https://github.com/linuxmint/nemo/commit/d1807d43898861cf159d4bdf8be2f912b396ff05
> +---
> + src/nemo-tree-sidebar.c | 44 +
> + 1 file changed, 31 insertions(+), 13 deletions(-)
> +
> +--- a/src/nemo-tree-sidebar.c
>  b/src/nemo-tree-sidebar.c
> +@@ -93,11 +93,13 @@
> + GtkWidget *popup_open_in_new_window;
> + GtkWidget *popup_open_in_new_tab;
> + GtkWidget *popup_create_folder;
> ++GtkWidget *popup_post_create_folder_separator;
> + GtkWidget *popup_cut;
> + GtkWidget *popup_copy;
> + GtkWidget *popup_paste;
> + GtkWidget *popup_rename;
> + GtkWidget *popup_pin;
> ++GtkWidget *popup_post_pin_separator;
> + GtkWidget *popup_unpin;
> + GtkWidget *popup_trash;
> + GtkWidget *popup_delete;
> +@@ -689,13 +691,14 @@
> + button_pressed_callback (GtkTreeView *treeview, GdkEventButton *event,
> +  FMTreeView *view)
> + {
> +-GtkTreePath *path, *cursor_path;
> ++GtkTreePath *path;
> + gboolean parent_file_is_writable;
> + gboolean file_is_home_or_desktop;
> + gboolean file_is_special_link;
> + gboolean can_move_file_to_trash;
> + gboolean can_delete_file;
> + gboolean using_browser;
> ++gint is_toplevel;
> + 
> + using_browser = g_settings_get_boolean (nemo_preferences,
> + 
> NEMO_PREFERENCES_ALWAYS_USE_BROWSER);
> +@@ -719,12 +722,11 @@
> + gtk_tree_path_free (path);
> + return FALSE;
> + }
> +-gtk_tree_view_get_cursor (view->details->tree_widget, 
> _path, NULL);
> +-
> +-gtk_tree_path_free (path);
> + 
> + create_popup_menu (view);
> + 
> ++is_toplevel = gtk_tree_path_get_depth (path) == 1;
> ++
> + if (using_browser) {
> + gtk_widget_set_sensitive 
> (view->details->popup_open_in_new_window,
> +   nemo_file_is_directory 
> (view->details->popup_file));
> +@@ -735,6 +737,15 @@
> + gtk_widget_set_sensitive (view->details->popup_create_folder,
> + nemo_file_is_directory (view->details->popup_file) &&
> + nemo_file_can_write (view->details->popup_file));
> ++
> ++if (nemo_file_is_in_favorites (view->details->popup_file)) {
> ++gtk_widget_hide (view->details->popup_create_folder);
> ++gtk_widget_hide 
> (view->details->popup_post_create_folder_separator);
> ++} else {
> ++gtk_widget_show (view->details->popup_create_folder);
> ++gtk_widget_show 
> (view->details->popup_post_create_folder_separator);
> ++}
> ++
> + gtk_widget_set_sensitive 

Bug#990442: debmirror: fails to handle multiple keyrings specified in a config-file

[Colin Watson]

On Tue, Jun 29, 2021 at 11:08:36AM +0200, Stefan Kisdaroczi wrote:
> debmirror fails to handle multiple keyrings specified in a config-file.
> 
> config-file:
> @keyrings="/etc/apt/trusted.gpg.d/key-a.gpg,/etc/apt/trusted.gpg.d/key-b.gpg";

In a config file, couldn't you just write:

  @keyrings = ("/etc/apt/trusted.gpg.d/key-a.gpg", 
"/etc/apt/trusted.gpg.d/key-b.gpg");

?

My concern about applying your patch is that it would break the
(admittedly probably rare, but perfectly valid) case where the path to a
keyring file contains a comma.  While it's true that we do manual
comma-separation of other values (release names, section names,
architecture names, rsync-extra directory names), those are all cases
where the individual values themselves may not contain commas.

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

Bug#924009: closed by Dimitrios Eftaxiopoulos (Bug not reproduced)

[Andrey Rahmatullin]

Control: reassign -1 src:freefem++
Control: severity -1 serious
Control: retitle -1 Baseline violation in i386 (-mmx -msse2) and amd64 (-mavx)
Control: found -1 3.47+dfsg1-1

On Sun, Mar 24, 2019 at 09:52:28PM +0100, Bernhard Übelacker wrote:
> Unfortunately I saw some bugs in the debian bug tracker
> that were told a "baseline violation", I never saw it somewhere
> explained what exactly the cpu feature baseline is.
It's indeed unfortunate that this info is hard to find and many
mainatiners don't know it. It's currently available at
https://wiki.debian.org/ArchitectureSpecificsMemo#Architecture_baselines
The baseline for amd64 is basic amd64, so only SSE2 and below.
The baseline for i386 is i686 without MMX.

While for amd64 the problem appeared in 3.61.1 (so since buster), for i386
it exists even in stretch.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#990530: unblock: horizon/18.6.2-4 and all of its plugins

[Thomas Goirand]

On 7/1/21 10:48 PM, Sebastian Ramacher wrote:
>> magnum-ui/7.0.0-2
> 
> This seems to be missing an upload.

magnum-ui uploaded.

>> sahara-dashboard/13.0.0-2
> 
> This introduces piuparts regressions.
> 
>> vitrage-dashboard/3.2.0-3
> 
> This only seems to have a changelog entry.

I'll fix these tomorrow morning and let will let you know.

Cheers,

Thomas Goirand (zigo)

Bug#990675: Windows guest looses network connectivity after udpate to bullseye

[Michael Ablassmeier]

hi,

On Sun, Jul 04, 2021 at 08:53:11PM +0300, Michael Tokarev wrote:
> And here's the fix:
> 
>  
> https://git.qemu.org/?p=qemu.git;a=commit;h=0a343a5add75f9f90c65e932863d57ddbcb28f5c
> 
> Now I wonder if this is something which should be fixed... the problem
> here is that with this patch applied, machines created with the buggy
> qemu will show the behavior you describe, *after* this patch... :)
> Okay, it looks like we should keep upgrade from stable to stable working,
> not upgrade from testing to stable.. Oh well.. :)

as already been discussed on the qemu list, this issue will affect lots
of users updating (the proxmox project received various reports after
they rolled with qemu 5.2 just for a "testing" repository), so if not
fixed, it should at least be documented somewhere.

bye,
- michael

Bug#990686: dirmngr: any keyserver operations fail because of dirmngr using Tor

[Christoph Anton Mitterer]

Package: dirmngr
Version: 2.2.27-2
Severity: normal


Hi.

It seesm with a default configuration of gnupg (and Tor) any keyserver 
operations
like --refresh-keys --search-keys --recv-keys fail with errors like:
gpg: keyserver refresh failed: Permission denied

Debug mode shows dirmngr is the reason:
gpg: DBG: chan_3 <- ERR 167804929 Permission denied 
gpg: keyserver refresh failed: Permission denied


and it seems to turn out that this uses Tor by default and apparently in an 
improper
manner:
Tor[2100]: Your application (using socks5 to port 53) is giving Tor only an IP 
address. Applications that do DNS resolves themselves may leak information. 
Consider using Socks4A (e.g. via privoxy or socat) instead. For more 
information, please see 
https://2019.www.torproject.org/docs/faq.html.en#WarningsAboutSOCKSandDNSInformationLeaks.
 Rejecting.


Not sure whether it would be a good workaround to simply disable tor per 
default.
Can't dirmngr switch to sock 4a?


Thanks,
Chris.


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

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

Versions of packages dirmngr depends on:
ii  adduser  3.118
ii  gpgconf  2.2.27-2
ii  init-system-helpers  1.60
ii  libassuan0   2.5.4-1
ii  libc62.31-12
ii  libgcrypt20  1.8.7-6
ii  libgnutls30  3.7.1-5
ii  libgpg-error01.38-2
ii  libksba8 1.5.0-3
ii  libldap-2.4-22.4.57+dfsg-3
ii  libnpth0 1.6-3
ii  lsb-base 11.1.0

Versions of packages dirmngr recommends:
ii  gnupg  2.2.27-2

Versions of packages dirmngr suggests:
ii  dbus-user-session  1.12.20-2
ii  libpam-systemd 247.3-5
ii  pinentry-gnome31.1.0-4
ii  tor0.4.5.9-1

-- no debconf information

Bug#990675: Windows guest looses network connectivity after udpate to bullseye

[Michael Tokarev]

Control: tag -1 + upstream patch

04.07.2021 16:33, Michael Ablassmeier wrote:

Package: qemu
Version: 1:5.2+dfsg-10

hi,

recently i migrated a windows virtual machine from debian buster to
debian bullseye. Libvirt configuration was exactly the same but the
booted windows system lost its network connectivity and also deactivated
a second attached virtual disk because of policy reasons.

The problem would have also appeared if i simply updated the host system
from buster to bullseye.  Chances are high that this also results in an
unbootable virtual machine.

Investigation has shown that the following commit in qemu causing the
issue is most likely:
  
  Commit af1b80ae56c9 ("i386/acpi: fix inconsistent QEMU/OVMF device paths")


And here's the fix:

 
https://git.qemu.org/?p=qemu.git;a=commit;h=0a343a5add75f9f90c65e932863d57ddbcb28f5c

Now I wonder if this is something which should be fixed... the problem
here is that with this patch applied, machines created with the buggy
qemu will show the behavior you describe, *after* this patch... :)
Okay, it looks like we should keep upgrade from stable to stable working,
not upgrade from testing to stable.. Oh well.. :)

Thank you for the bugreport!

/mjt

Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade

[Paul Gevers]

Hi all,

On 04-07-2021 00:42, Colin Watson wrote:
> Sorry for my delay - it took me a while to spot the problem.  libc6's
> postinst does arrange to restart services where needed, but in this case
> it doesn't realize that you have the ssh service installed because you
> only have the openssh-server package installed, not the ssh metapackage
> (i.e. the package with the same name as the service).
> 
> I've proposed
> https://salsa.debian.org/glibc-team/glibc/-/merge_requests/3 to fix
> this.  glibc maintainers, if there's any way to get this into bullseye,
> I'm sure it would help avoid some people upgrading remote systems ending
> up being unable to fix them if something goes wrong between configuring
> libc6 and configuring openssh-server.  Also CCing debian-release for
> their information, as I know it's pretty late for glibc changes.

I think we really want this. I *think* I ran into exactly this issue two
days ago when I upgraded my NAS. It's really scary to notice that you
can't log into your system and your only connection is the current one
running the upgrade. In my case, it was asking questions along the way.
I had considered running the upgrade in screen. In the end it look
longer than expected and I left my laptop on. If I would have run in
screen and disconnected, I would have had no idea what hit me.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#990683: Audio from USB Headset not working

[Bruno Cuesta]

Package: Pulseaudio
Version: 12.2

When I connect my USB Headset I don't hear audio. When I remove the USB cable 
from the Headset the audio is routed to the Laptop speaker.

My headset is recognized as:
ID 1b3f:2008 Generalplus Technology Inc.

The headset microphone works as people can hear me. The problem is with the 
audio routing to the Headset when I connect it.
The system does not emit the volume sound when using the fn+F3 and fn+F4 
hotkeys. But it does when I use the volume icon.
I checked the settings in alsamixer and there is nothing muted.

Informations:

bruno@debian:~$ lsusb
Bus 002 Device 005: ID 1b3f:2008 Generalplus Technology Inc.
Bus 002 Device 003: ID 0458:0186 KYE Systems Corp. (Mouse Systems)
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 064e:a213 Suyin Corp.
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

bruno@debian:~$ pactl list short sinks
0 alsa_output.pci-_00_1b.0.analog-stereo module-alsa-card.c s16le 2ch 
44100Hz SUSPENDED
2 alsa_output.usb-GeneralPlus_USB_Audio_Device-00.analog-stereo 
module-alsa-card.c s16le 2ch 44100Hz SUSPENDED

bruno@debian:~$ cat /proc/asound/cards
 0 [MID]: HDA-Intel - HDA Intel MID
  HDA Intel MID at 0xf600 irq 28
 1 [Device ]: USB-Audio - USB Audio Device
  GeneralPlus USB Audio Device at usb-:00:1d.0-1.5, 
full speed

bruno@debian:~$ sudo dmesg | grep General
[  584.514861] usb 2-1.5: Manufacturer: GeneralPlus
[  584.516507] input: GeneralPlus USB Audio Device as 
/devices/pci:00/:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.3/0003:1B3F:2008.0002/input/input15
[  584.575814] hid-generic 0003:1B3F:2008.0002: input,hidraw1: USB HID v2.01 
Device [GeneralPlus USB Audio Device] on usb-:00:1d.0-1.5/input3
[  974.656859] usb 2-1.5: Manufacturer: GeneralPlus
[  974.680652] input: GeneralPlus USB Audio Device as 
/devices/pci:00/:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.3/0003:1B3F:2008.0003/input/input16
[  974.738008] hid-generic 0003:1B3F:2008.0003: input,hidraw1: USB HID v2.01 
Device [GeneralPlus USB Audio Device] on usb-:00:1d.0-1.5/input3

bruno@debian:~$ aplay -l
 List of PLAYBACK Hardware Devices 
card 0: MID [HDA Intel MID], device 0: ALC269 Analog [ALC269 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: MID [HDA Intel MID], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Device [USB Audio Device], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

bruno@debian:~$ arecord -l
 List of CAPTURE Hardware Devices 
card 0: MID [HDA Intel MID], device 0: ALC269 Analog [ALC269 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Device [USB Audio Device], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

bruno@debian:~$ pacmd list-cards
2 card(s) available.
index: 0
name: 
driver: 
owner module: 6
properties:
alsa.card = "0"
alsa.card_name = "HDA Intel MID"
alsa.long_card_name = "HDA Intel MID at 0xf600 irq 28"
alsa.driver_name = "snd_hda_intel"
device.bus_path = "pci-:00:1b.0"
sysfs.path = "/devices/pci:00/:00:1b.0/sound/card0"
device.bus = "pci"
device.vendor.id = "8086"
device.vendor.name = "Intel Corporation"
device.product.id = "3b56"
device.product.name = "5 Series/3400 Series Chipset High Definition Audio"
device.form_factor = "internal"
device.string = "0"
device.description = "Áudio interno"
module-udev-detect.discovered = "1"
device.icon_name = "audio-card-pci"
profiles:
input:analog-stereo: Entrada de Estéreo analógico (priority 65, available: 
unknown)
output:analog-stereo: Saída de Estéreo analógico (priority 6500, available: 
unknown)
output:analog-stereo+input:analog-stereo: Duplex estéreo analógico (priority 
6565, available: unknown)
output:hdmi-stereo: Saída de Digital Stereo (HDMI) (priority 5900, available: 
no)
output:hdmi-stereo+input:analog-stereo: Saída de Digital Stereo (HDMI) + 
Entrada de Estéreo analógico (priority 5965, available: unknown)
output:hdmi-surround: Saída de Digital Surround 5.1 (HDMI) (priority 800, 
available: no)
output:hdmi-surround+input:analog-stereo: Saída de Digital Surround 5.1 (HDMI) 
+ Entrada de Estéreo analógico (priority 865, available: unknown)
output:hdmi-surround71: Saída de Digital Surround 7.1 (HDMI) (priority 800, 
available: no)
output:hdmi-surround71+input:analog-stereo: Saída de Digital Surround 7.1 
(HDMI) + Entrada de Estéreo analógico (priority 865, available: unknown)
off: Desligado (priority 0, available: unknown)
active profile: 
sinks:
alsa_output.pci-_00_1b.0.analog-stereo/#0: Áudio interno Estéreo analógico
sources:
alsa_output.pci-_00_1b.0.analog-stereo.monitor/#0: Monitor of Áudio interno 
Estéreo analógico
alsa_input.pci-_00_1b.0.analog-stereo/#1: 

Bug#990684: ITP: sfsexp -- small fast s-expression library

[David Bremner]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: sfsexp
  Version : 1.3.1
  Upstream Author : Matthew Sottile 
* URL : https://github.com/mjsottile/sfsexp
* License : LGPL2.1+
  Programming Lang: C
  Description : small fast s-expression library

This library is intended for developers who wish to manipulate (read,
parse, modify, and create) symbolic expressions (s-expressions) from C
or C++ programs.


I did not find a library with equivalent footprint and functionality
in Debian.

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmDh9j8ACgkQA0U5G1Wq
FSH88A/+MF/IrmVmvsvHsylcbTCwvtypdkS/G1EKuOpp1nBblq57yan3VuFJi2JY
+f5DsOvutkE9dnDaCe4jWgN4ZBvngHLzReDj2ITHgRSxTIyQ+8zSu/6fVkQiqnqn
RcA7tTvi6CaUDNF1CKAnbpmaxgtJwt77R7kqq3AFt4cWrVFLJCReTo/4pqDsGIzF
1Z8L4c6VmhVqObfoMQ/lGAjw4vpJyod7vCbt5XOPyf/yb7VBuIWneUrJv07WVznF
5fVTj4/AEDw4osKrBnBviAgmS6FdVaSSu/Cn0ODBf3ZSKiQGrJH4qHFk5MtBJaA1
aRfsKEmkhCU1jARdJM/kI87fLHV3oOShyJcUSOiZ5PnescAhL0ovO3mv8H1+kaBZ
iclVDN7r40cZfDgrxpX8A9SL6UOT0Sssxbi6IaH35Aj+/DYFjpL1Xo+VGPyezvZ+
+tHAPKAHyIzP6Bl0+vlEFR5B3RFHuhG8789FWUp/n/g5M1fxVKdbEqzNz/JxFb5H
OdSa29izQrNv4OcfVhDE2ZWwBh/hnQoM+FwPYrM3jreEy7VxurN8+8GR5jJoK1gB
H1AVayAxyrA+ycs0r0RQBv491+FeX7wNPHjYhbjZP0nOiDl4NZy3EtS7N0NmQHeC
Ih2xSmTkhWiFeVsVvPR37eYMVdd+Sl7dU/lsxDVFQ4VFuaFdIpI=
=PzAS
-END PGP SIGNATURE-

Bug#990680: ITP: nebula -- A scalable overlay networking tool with a focus on performance, simplicity and security

[Flu0r1ne]

Package: wnpp

Severity: wishlist

Owner: Alex David

Package name : nebula

Version : 1.4.0-1

Upstream Author : Slack Technologies, Inc.

  Nate Brown

  Ryan Huber

URL : https://github.com/slackhq/nebula

License : MIT

Programming Lang: Go

Description : A scalable overlay networking tool with a focus on
performance, simplicity and security

  Nebula is a scalable overlay networking tool with a focus on
performance, simplicity and security. It lets you seamlessly

  connect computers anywhere in the world. Nebula is portable, and runs
on Linux, OSX, Windows, iOS, and Android. It can

  be used to connect a small number of computers, but is also able to
connect tens of thousands of computers. . Nebula incorporates

  a number of existing concepts like encryption, security groups,
certificates, and tunneling, and each of those individual pieces existed

  before Nebula in various forms. What makes Nebula different to
existing offerings is that it brings all of these ideas together, resulting

  in a sum that is greater than its individual parts.


Nebula is a popular networking tool installed on many machines. Creating
a path for users to to receive updates would be

beneficial to many users as it is network facing.

Bug#990679: unblock: [pre-approval] privacybadger/2021.6.8-1

[John Scott]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: 981...@bugs.debian.org
Control: block 981702 by -1

Please unblock package privacybadger

[ Reason ]
Privacy Badger is unique and different from other anti-tracking
extensions in that instead of using artificial whitelists and
blacklists, it learns based on one's browsing behavior. However, it was
privately disclosed by Google's Security Team that Privacy Badger's
learning, which is unique to each user, can itself enable
fingerprinting:
https://www.eff.org/deeplinks/2020/10/privacy-badger-changing-protect-you-better

To address this, newer versions of Privacy Badger work by everyone
using the same whitelists, yellowlists, and blacklists, which are
aggregated from everyone's learning data.

[ Impact ]
If this unblock isn't granted, or it's not possible for Privacy Badger
to be shipped in bullseye-updates during the release cycle, then users
would be left more vulnerable to fingerprinting, as they could be
identified based on their older Privacy Badger versions. Upstream has
indicated that this situation would be unacceptable (and I concur), so
it would be better to remove the package altogether then.

This situation is not unlike the need to ship up-to-date ClamAV data in
stable-updates.

[ Tests ]
Since this is a browser extension it's difficult to automate testing. I
have tested with Firefox ESR, Firefox non-ESR, and Chromium that it
works.

[ Risks ]
This package is a leaf package, and if this package were to be instead
removed from Bullseye, users would need to install it manually by
fetching the extension from another source. The debdiff is quite large,
but consists mostly of changes to the website data and translations.

[ 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 testing

This is a request for pre-approval since I need to seek a sponsor to
update the package anyway. My debdiff was detected as malware so you'll
have to fetch it from
https://salsa.debian.org/-/snippets/549/raw/master/privacybadger.diff

unblock privacybadger/2021.6.8-1




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

Bug#990678: budgie-desktop: Software windows don't display correctly, move badly or stay on the screen after being shut

[David Mohammed]

You mentioned you contacted the upstream budgie maintainers.

What is the github issue you are referring to?

In my testing of bullseye budgie is perfectly stable. No issues here.

So it is very likely to be graphic driver issues specific to your setup.

On Sun, 4 Jul 2021, 17:57 Pascal,  wrote:

> Package: budgie-desktop
> Version: 10.5.2-3
> Severity: normal
> X-Debbugs-Cc: pascal.mart...@gmx.fr
>
> Dear Maintainer,
>
> Not using yet Reportbug a few months ago, I had written directly to budgie
> maintainers about this problem of bad window display : Menu windows opened
> correctly, and after shutting them down they very often remained on the
> screen
> even though they were shut, software side. I had noticed this especially
> with
> software like Abiword or MPV. But it happened unexpectedly with other
> software
> too. Since then things have improved a lot. For instance all seems to be
> working fine with Abiword now.
>
> But there are still problems with MPV. It works fine if you click on a
> video
> which displays at normal size. But if the video is launched fullscreen
> (e.g.
> from SMPlayer), when you return to normal size, you first can't move the
> video.
> The video display doesn't follow the movement of the mouse. Just try it
> yourself, the details of it are difficult to explain. Remark that after a
> few
> minutes, you can move the video correctly again.
>
> I have noticed a few other little bugs (e.g. regarding top and back
> windows)
> about this windows display problem. Budgie Maintainers should do intensive
> testing to solve these window bugs before bullseye becomes stable. I have
> not
> been testing too much myself because these problems were so annoying that
> I had
> to return to Gnome. But now, MPV apart, Budgie seems to be usable in
> Debian.
>
> Cordially,
> Pascal.
>
> -- System Information:
> Debian Release: 11.0
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-7-amd64 (SMP w/2 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE
> not
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages budgie-desktop depends on:
> ii  budgie-core  10.5.2-3
> ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
> ii  gir1.2-budgie-1.010.5.2-3
> ii  gnome-control-center 1:3.38.4-1
> ii  gnome-menus  3.36.0-1
> ii  network-manager-gnome1.20.0-3
>
> Versions of packages budgie-desktop recommends:
> ii  budgie-desktop-view  1.1.1-1
>
> Versions of packages budgie-desktop suggests:
> ii  gnome-terminal  3.38.3-1
> ii  nautilus3.38.2-1
> pn  slick-greeter   
>

Bug#990678: budgie-desktop: Software windows don't display correctly, move badly or stay on the screen after being shut

[Pascal]

Package: budgie-desktop
Version: 10.5.2-3
Severity: normal
X-Debbugs-Cc: pascal.mart...@gmx.fr

Dear Maintainer,

Not using yet Reportbug a few months ago, I had written directly to budgie
maintainers about this problem of bad window display : Menu windows opened
correctly, and after shutting them down they very often remained on the screen
even though they were shut, software side. I had noticed this especially with
software like Abiword or MPV. But it happened unexpectedly with other software
too. Since then things have improved a lot. For instance all seems to be
working fine with Abiword now.

But there are still problems with MPV. It works fine if you click on a video
which displays at normal size. But if the video is launched fullscreen (e.g.
from SMPlayer), when you return to normal size, you first can't move the video.
The video display doesn't follow the movement of the mouse. Just try it
yourself, the details of it are difficult to explain. Remark that after a few
minutes, you can move the video correctly again.

I have noticed a few other little bugs (e.g. regarding top and back windows)
about this windows display problem. Budgie Maintainers should do intensive
testing to solve these window bugs before bullseye becomes stable. I have not
been testing too much myself because these problems were so annoying that I had
to return to Gnome. But now, MPV apart, Budgie seems to be usable in Debian.

Cordially,
Pascal.

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

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

Versions of packages budgie-desktop depends on:
ii  budgie-core  10.5.2-3
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  gir1.2-budgie-1.010.5.2-3
ii  gnome-control-center 1:3.38.4-1
ii  gnome-menus  3.36.0-1
ii  network-manager-gnome1.20.0-3

Versions of packages budgie-desktop recommends:
ii  budgie-desktop-view  1.1.1-1

Versions of packages budgie-desktop suggests:
ii  gnome-terminal  3.38.3-1
ii  nautilus3.38.2-1
pn  slick-greeter   

Bug#990456: Processed: Bug#990456 marked as pending in openssh

[Martin]

On 2021-07-04 10:21, Colin Watson wrote:
> On Sun, Jul 04, 2021 at 08:17:59AM +, Martin wrote:
>> No harm done by `update_ssh_group_name()`, but maybe I would use
>> `if ! getent group _ssh >/dev/null; then` instead of
>> `if getent group ssh >/dev/null; then` just for the aesthetics (and to
>> prevent postinst failure, in case both `ssh` and `_ssh` already exist).
>
> The version check should deal with most of this in practice, but I've
> added a check for _ssh in addition (rather than "instead").

Even better, thank you!

Bug#990458: babel umd support is limited

[Pirate Praveen]

On Sat, 03 Jul 2021 23:01:35 +0530 Pirate Praveen 
 wrote:
> I switched to rollup for generating umd and removed 
add-module-exports
> plugin and it is working now. Possibly defining "autosize" global 
with

> @babel/plugin-transform-modules-umd without add-module-exports plugin
> would have worked as well.

I tried this option today and it did not work. Looks like this is a 
known limitaion of babel umd plugin. 
https://github.com/babel/babel/issues/10696 so we will stick with 
rollup.

Bug#901636: mandoc: "mandoc -mdoc -T man" causes memory dump

[Ingo Schwarze]

I just fixed the assertion failure upstream at mandoc.bsd.lv,
see https://inbox.vuxu.org/mandoc-source/c2aa13aac88a7...@mandoc.bsd.lv/
and http://cvsweb.bsd.lv/mandoc/ .

Supporting tbl(7) and eqn(7) in -T man has been on the
http://cvsweb.bsd.lv/mandoc/TODO list for some time, but it causes
a non-trivial amount of work and is not particularly high priority
for the following reason: The main use case for -T man is that you
can maintain the documentation of your portable software project
in the mdoc(7) format and yet provide autogenerated man(7) versions
of your manual pages for the very few remaining operating systems
that still do not support mdoc(7).  If you care about that, embedding
tbl(7) or eqn(7) code in your manual pages is just a bad idea in
the first place.

Thanks to Nab for proposing patches, but these can't be committed
as-is because they consitute a layering violation.  The new code
is essentially a tbl-to-tbl output mode and would belong into a new
module tbl_tbl.c; it is misplaced in mdoc_man.c because it is neither
related to mdoc(7) input nor to man(7) output.  It appears setting
that up properly wouldn't be excessively difficult, but i don't
have the time to do so right now.  Besides, this would be the first
src_dst.c output module where src == dst, so some generic design
questions might need to be considered before commit.

Thanks to all of you for your input!
  Ingo

Bug#990677: crashes with stretch's linux-4.9.0-16-amd64 kernel

[Robert Scott]

Package: linux
Version: 4.9.0-16

Hi,

linux-4.9.0-16-amd64 is not a happy kernel.

I don't know whether this is a duplicate of #990423, because I'm also using 
iwlwifi, but this is on a thinkpad X220.

I actually received the latter two crashes *during* my upgrade to buster, 
which didn't do a lot to steady my nerves. The main observable effect was to 
cause systemd (pid #1) to become unresponsive occupying 100% cpu, where it 
would not allow dpkg to probe it or restart services. That was a fun 
afternoon.

Three crash traces and my lspci:

kernel: Modules linked in: ctr ccm hid_generic usbhid hid tun intel_rapl 
x86_pkg_temp_thermal intel_powerclamp coretemp iTCO_wdt iTCO_vendor_support 
kvm_intel kvm uvcvideo irqbypass videobuf2_vmalloc intel_cstate 
videobuf2_memops arc4 snd_h
kernel:  xt_tcpudp xt_addrtype nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack 
ip6table_filter ip6_tables nf_conntrack_netbios_ns nf_conntrack_broadcast 
nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack parport_pc sunrpc ppdev 
iptable_filter lp
kernel: CPU: 1 PID: 1552 Comm: kdeinit5 Not tainted 4.9.0-16-amd64 #1 Debian 
4.9.272-1
kernel: Hardware name: LENOVO 4290A48/4290A48, BIOS 8DET49WW (1.19 ) 
07/01/2011
kernel: task: 8b98d26b8080 task.stack: acbf42304000
kernel: RIP: 0010:[]  [] 
vma_interval_tree_insert_after+0x2f/0x80
kernel: RSP: 0018:acbf42307dd0  EFLAGS: 00010206
kernel: RAX: 1000 RBX: 8b98d26d6e10 RCX: 8b981d4720c8
kernel: RDX: 0018 RSI: 8b98d2516190 RDI: 8b981d4720c8
kernel: RBP: acbf42307ea0 R08: 8b98cf24a700 R09: 8b98d26d6e70
kernel: R10: 0018 R11: 8b980898fa40 R12: 8b981d4720c8
kernel: R13: 8b98cfcb2000 R14: 8b98cf24a708 R15: 8b98cf24a6e0
kernel: FS:  7f0157f73140() GS:8b98de24() knlGS:

kernel: CS:  0010 DS:  ES:  CR0: 80050033
kernel: CR2: 7f0156c47038 CR3: 00021251a000 CR4: 00060670
kernel: Stack:
kernel:  a7878bff a79ea3b4 0246 8b98d0f6e410
kernel:    01200011 8b981d472728
kernel:  8b981d472730 8b981d472718 8b98cfcb2068 8b98cf5ca068
kernel: Call Trace:
kernel:  [] ? copy_process.part.34+0xcbf/0x1b70
kernel:  [] ? __kmalloc+0x114/0x580
kernel:  [] ? _do_fork+0xe3/0x3f0
kernel:  [] ? __do_pipe_flags+0x55/0xc0
kernel:  [] ? do_syscall_64+0x8d/0x100
kernel:  [] ? entry_SYSCALL_64_after_swapgs+0x58/0xc6
kernel: Code: 90 48 8b 47 08 48 2b 07 49 89 d0 48 8b 97 98 00 00 00 48 89 f9 
4c 8d 4e 60 48 c1 e8 0c 48 8d 54 10 ff 48 8b 46 60 48 85 c0 74 1b <48> 39 50 
18 48 8d 70 a8 73 04 48 89 50 18 48 8b 46 68 48 85 c0 
kernel: RIP  [] vma_interval_tree_insert_after+0x2f/0x80
kernel:  RSP 
kernel: ---[ end trace cc3ab798cf972fa9 ]---

---

[20251.164878] BUG: Bad page map in process lpqd  pte:1c42d4a90b pmd:1cdd43067
[20251.164879] addr:7fb43d58 vm_flags:0870 anon_vma:  
(null) mapping:89cd30d88ad8 index:a5
[20251.164899] file:libsamba-credentials.so.0.0.1 fault:ext4_filemap_fault 
[ext4] mmap:ext4_file_mmap [ext4] readpage:ext4_readpage [ext4]
[20251.164901] CPU: 3 PID: 1771 Comm: lpqd Tainted: GB   4.9.0-16-
amd64 #1 Debian 4.9.272-1
[20251.164902] Hardware name: LENOVO 4290A48/4290A48, BIOS 8DET49WW (1.19 ) 
07/01/2011
[20251.164902]   afe13377 7fb43d58 
89cd0dca73e8
[20251.164904]  af9b7c31 af9b7c31 0001 

[20251.164905]  7fb43d58 89cd0dd43c00 001c42d4a90b 
b24b42bf3dd8
[20251.164907] Call Trace:
[20251.164909]  [] ? dump_stack+0x66/0x81
[20251.164910]  [] ? print_bad_pte+0x1d1/0x2a0
[20251.164911]  [] ? print_bad_pte+0x1d1/0x2a0
[20251.164912]  [] ? vm_normal_page+0x78/0xa0
[20251.164913]  [] ? unmap_page_range+0x5e9/0x9d0
[20251.164915]  [] ? unmap_vmas+0x4c/0xa0
[20251.164916]  [] ? exit_mmap+0x8f/0x140
[20251.164918]  [] ? mmput+0x54/0x100
[20251.164919]  [] ? do_exit+0x27e/0xb60
[20251.164921]  [] ? do_group_exit+0x3a/0xa0
[20251.164922]  [] ? SyS_exit_group+0x10/0x10
[20251.164924]  [] ? do_syscall_64+0x8d/0x100
[20251.164925]  [] ? entry_SYSCALL_64_after_swapgs+0x58/0xc6
[20251.166178] BUG: Bad rss-counter state mm:89cd52219c00 idx:2 val:-1

---

[30864.914773] BUG: Bad page map in process Socket Thread  pte:
801c42d4a90b pmd:18ac36067
[30864.914780] addr:7f8d8bac vm_flags:08fb anon_vma:  
(null) mapping:89cd4d596268 index:2
[30864.914787] file:org.mozilla.ipc.2088.276 fault:shmem_fault mmap:shmem_mmap 
readpage:  (null)
[30864.914791] CPU: 0 PID: 2092 Comm: Socket Thread Tainted: GB   
4.9.0-16-amd64 #1 Debian 4.9.272-1
[30864.914792] Hardware name: LENOVO 4290A48/4290A48, BIOS 8DET49WW (1.19 ) 
07/01/2011
[30864.914794]   afe13377 7f8d8bac 
89cca7f61af0
[30864.914797]  af9b7c31 89cd5e218a00 b24b430a3c38 
7f8d8babf000

Bug#990668: pastebinit: If text posted on paste.debian.net is too long, it gets out of text box

[Tia]

Package: pastebinit
Version: 1.5.1-1
Severity: minor
X-Debbugs-Cc: tia3...@protonmail.com

Dear Maintainer,

I was posting some long lines and noticed that they would overflow the text box.
You coudl still read them as scroll bar appears, but it looks odd.

For example using pastebinit for

BBB

BBB

Will show them passing through text box. It would make more sence that line 
gets broken once it reaches end of text box.



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

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

Versions of packages pastebinit depends on:
ii  python3 3.9.2-3
ii  python3-distro  1.5.0-1

pastebinit recommends no packages.

pastebinit suggests no packages.

-- no debconf information

Bug#990397: What are the development priorities for the csironn library? (was Bug#990397: depends on deprecated qhull library)

[Rafael Laboissière]

* Alan W. Irwin  [2021-07-04 03:38]:

A message on this thread from Atri Bhattacharya 
 bounced (presumably because he used a 
non-subscription return address).  But as list administrator I saw 
that bounced message which turned out to be of immediate interest.  So 
I am reposting it here without asking Atri to resubmit with 
subscription address == return address.


Atri said: 
_


For openSUSE's plplot package, we have a patch to build against 
libqhull_r, kindly contributed by Stefan. Here is the bug reference 
which has the patch as an attachment: 
. Would be great to get 
this checked into plplot upstream.


Hope that helps. 
_


Hi Atri:

I don't know how I missed that PLplot bug report with a patch that 
from its title likely implements the csironn library 
development topic that I just discussed on this thread!


Anyhow, thanks for drawing this patch to my attention, and I hope 
I have time to take a close look at in in the coming week or so.


JFYI, I applied the patch indicated by Atri to the Debian package and 
released version 5.15.0+dfsg-21 to the experimental distribution : 
https://tracker.debian.org/news/1243929/accepted-plplot-5150dfsg-21-source-into-experimental/


Best,

Rafael

Bug#990676: dlib incompatible with 4.5.1

[Alexandr Podgorniy]

Source: dlib
Version: 19.10-3
Severity: important
Tags: patch
X-Debbugs-Cc: sca...@scaledteam.ru

Bug better described there:
https://github.com/davisking/dlib/issues/1955

Easily fixable with this patches:
https://github.com/davisking/dlib/commit/131e4598093fea6d8469e7687ac31ef60571f336
https://github.com/davisking/dlib/commit/34dc7303045877226ebdd6cd07ce6384c0881eb8


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

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#989045: gnome-control-center: Region+Language panel segfault after trying to add new input source

[Gunnar Hjalmarsson]

On 2021-07-04 12:48, Prof. Will Tuladhar-Douglas wrote:

Yes, that works, and it looks as though a patch is on the way.


Thanks for confirming. Yes, it's fixed upstream. I'll try to have it 
fixed in bullseye before the release of Debian 11.

Bug#990675: Windows guest looses network connectivity after udpate to bullseye

[Michael Ablassmeier]

Package: qemu
Version: 1:5.2+dfsg-10

hi,

recently i migrated a windows virtual machine from debian buster to
debian bullseye. Libvirt configuration was exactly the same but the
booted windows system lost its network connectivity and also deactivated
a second attached virtual disk because of policy reasons.

The problem would have also appeared if i simply updated the host system
from buster to bullseye.  Chances are high that this also results in an
unbootable virtual machine.

Investigation has shown that the following commit in qemu causing the
issue is most likely:
 
 Commit af1b80ae56c9 ("i386/acpi: fix inconsistent QEMU/OVMF device paths")

i havent checked in detail but it seems likely debian ships a qemu
version with this change.

See following resources for more informations:

 https://bugzilla.redhat.com/show_bug.cgi?id=1934158
 https://github.com/virtio-win/kvm-guest-drivers-windows/issues/592
 https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg08484.html

bye,
-michael

Bug#931339: [pkg-gnupg-maint] Bug#931339: gnupg: Change default keyserver?

[Roger Shimizu]

On Sun, Jul 4, 2021 at 6:00 PM Paul Wise  wrote:
>
> On Tue, 2 Jul 2019 15:55:32 +0200 Guillem Jover wrote:
>
> > According to the dirmngr(8) man page, the default built-in server is
> > «hkps://hkps.pool.sks-keyservers.net». Given the recent attacks, and
> > the problems inherent in that network, could we just change the
> > default to be «hkps://keys.openpgp.org» instead?
>
> This is fixed in bullseye, but not buster. Now that sks-keyservers.net
> is no longer working, Debian users on bullseye are having issues, so it
> would be great if the default could be updated in buster/stretch too:

>From changelog, version in buster already [1] updated the default
server to keys.openpgp.org
Is there any other bug involved?

[1] 
https://tracker.debian.org/news/1060144/accepted-gnupg2-2212-1deb10u1-source-into-proposed-updates-stable-new-proposed-updates/

Cheers,
Roger

Bug#982794: firefox-esr: illegal instruction in libxul.so on armhf

[Vincent Arkesteijn]

Control: found -1 78.11.0esr-1

Hi Hideki and Jochen,

Thank you for both of your responses.

On Thu, Jul 01, 2021 at 08:08:44AM +0200, Jochen Sprickerhof wrote:
> * Hideki Yamane  [2021-06-28 22:35]:

> > Can you reproduce it on freshly installed bullseye sytem?

After apt upgrade (firefox now at 78.11.0esr-1), the issue is still there. The 
offending instruction is the same and the backtrace looks very similar. Given 
that the cause seems well understood (use of NEON instructions on a non-NEON 
system), I don't think a fresh install would give us any new information.

> I only found this reference for NEON on armhf:
> 
> "NEON and VFP/VFP2/VFP3 remain an optional part of the architecture."
> 
> https://wiki.debian.org/ArmHardFloatPort#VFP

In addition:

"VFPv3-D16 is the common denominator of the processors to support here 
(therefore the recommended build option is -mfpu=vfpv3-d16)"

https://wiki.debian.org/ArmHardFloatPort/VfpComparison#FPU

I couldn't find a more authoritative definition of the supported architecture 
subset for the armhf port.

> If this is still reproducible, I see two options:
> - Disable NEON code.
> - Depend on the neon-support dummy package.

Agreed.

> > > Kernel: Linux 3.5.7-14-ARCH (PREEMPT)
> > It seems that is not the kernel bullseye provides.

Correct. The default Debian armhf kernel doesn't give me video, and I forgot 
whether it even boots.

> > And it maybe help to provide its hardware information, too.
> The bug author wrote:
> 
> > > This is on a Marvell Dove system, with VFPv3-D16. From /proc/cpuinfo:
> > > Features  : swp half thumb fastmult vfp edsp iwmmxt thumbee vfpv3 
> > > vfpv3d16 tls

More specifically, this is on a SolidRun CuBox (first generation, so not the 
CuBox-i or CuBox-M).

I noticed that some time ago, the severity of this bug was raised from normal 
to serious. While it is serious on my system, I had set it to normal because it 
likely affects only a relatively small number of systems. And while I would 
appreciate this bug getting resolved, making it release critical seems 
unnecessary.

Regards,
Vincent.

Bug#990674: s2-geometry-library: The Homepage is wrong in metadata

[Emmanuel Arias]

Source: s2-geometry-library
Version: 1.0.1-2
Severity: normal
X-Debbugs-Cc: eam...@yaerobi.com

Dear Maintainer,

s2-geometry-library is pointing to [0] and that's wrong. The
correct homepage should be [1].

[0] https://s2geometry.io/
[1] https://github.com/google/s2-geometry-library-java


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

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

Bug#990645: Debian's installer's GRUB installer detects Vista instead of my 64-bit W7 installation.

[Cyril Brulebois]

Ant  (2021-07-03):
> I downloaded, mounted, and booted Debian's net installer ISO (e.g., 
> https://gemmei.ftp.acc.umu.se/debian-cd/current/amd64/iso-cd/debian-10.10.0-amd64-netinst.iso
>  and 
> https://gemmei.ftp.acc.umu.se/cdimage/unofficial/non-free/cd-including-firmware/bullseye_di_rc2+nonfree/amd64/iso-cd/firmware-bullseye-DI-rc2-amd64-netinst.iso)
>  
> in an old 64-bit W7 HPE SP1 VirtualBox v6.1 VM with a brand new virtual SSD 
> (2 virtual drives = 1 old W7 HDD + 1 new blank SSD). I'm trying it before 
> doing it virtually instead of my real physical PC to learn and practice 
> (don't want to hose my 12 yrs. old real hardware production PC!). I picked 
> most of Debian's defaults (no GUI packages to install for now). I'm currently 
> having problems with its GRUB bootloader part. It detected Vista, but I 
> don't have Vista as shown in my https://i.ibb.co/ctfV40c/Grub-Vista.gif 
> screen shot/capture. I have W7!
> 
> Thank you for reading and hopefully fixing it soon. :)

Hi Ant,

If you look at os-prober's code:
  
https://salsa.debian.org/installer-team/os-prober/-/blob/master/os-probes/mounted/x86/20microsoft#L26-60

you'll see that Windows 7 could be detected on its own, which I suppose
is not happening for whatever reason on your machine, but also that
Vista is the fallback (see “else” part on L51); another possibility
could be that the BCD indeed advertises Vista, even for Windows 7
installation, but I'm definitely not a Windows expert (nor do I want to
become one).

Either way, it seems to me your Windows bootloader has been detected
just fine, it might just get the wrong label in the end, but that
shouldn't be a huge issue?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#990667: Follow-up Bug#990667: Acknowledgement (dgit(7) Documentation: MODEL dgit-repo, --overwrite, /fast forward/fast-forward/, --deliberately-not-fast-forward, ...)

[Osamu Aoki]

Hi,

As for #990667: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990667.

I wrore:

   The mastery of pseudo-remote and its persistence over --overwrite gives
   me iffy feeling.
   
Here, I meant: s/mastery/mystery/ of course.

Also, as for --overwrite, the following bug report needs to be addressed.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933044

Osamu

Bug#990630: unblock: fuse3/3.10.3-2

[Cyril Brulebois]

Paul Gevers  (2021-07-03):
> On 03-07-2021 07:17, László Böszörményi (GCS) wrote:
> > [ Other info ]
> > Builds an udeb and needs a d-i hint as well.
> 
> So, let's make kibi aware of this too (via boot).

Looks good, thanks.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#986650: winetricks: move from contrib to main

[Jens Reyer]

On 04.07.21 14:51, Johannes Schauer Marin Rodrigues wrote:
> Hi,
> 
> Quoting Jens Reyer (2021-07-04 14:36:13)
>> On 08.04.21 22:47, Johannes 'josch' Schauer wrote:
>>> a recent threat on debian-devel [1] revealed that winetricks falls into the
>>> same category as other packages that are happily sitting in main.
>>> Specifically, winetricks not only allows to download non-free software but
>>> also DFSG-free software like dxvk or faudio. As such it is in the same
>>> category as many other packages in main that allow to download both free
>>> and non-free binaries from the internet if the user requests it to do so.
>>>
>>> Since other packages that allow to download and run non-free stuff are
>>> allowed in main I think winetricks can be uploaded to main.
>>>
>>> The advantage would be that this would make it easier for our users to
>>> install winetricks.
>>>
>>> Thanks!
>>>
>>> cheers, josch
>>>
>>> [1] https://lists.debian.org/20210404091701.eum2iid4ffvpfn3v@frifot
>>
>> thanks, I agree that winetricks can be moved to "main".  Although the thread
>> was not completely in favor of doing so, I think there was a loose consensus
>> that this is ok.
>>
>> I'm a DM, so I can't upload to NEW which (afair) is required for such a
>> change.  I'd appreciate it if you or some other DD directly took care of
>> that after the freeze (without me preparing this trivial change upload).
>>
>> Since I'm in the process of stepping down as Debian maintainer I generally
>> welcome anyone taking over winetricks maintainership.
> 
> I would upload the package to main/experimental today if you have no
> objections?
> 
> Thanks!
> 
> cheers, josch
> 


Thanks, please go ahead.

If you have access to the git repository please upload your changes also
there, otherwise send a "git am"-able commit per mail.  Or I'll import
your changes later on.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#986650: winetricks: move from contrib to main

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Jens Reyer (2021-07-04 14:58:31)
> If you have access to the git repository please upload your changes also
> there, otherwise send a "git am"-able commit per mail.  Or I'll import your
> changes later on.

I just requested access to the "Debian Wine Packaging" team on salsa. I will
push my changes once I got accepted and will then do the upload.

Thank you for all your work on winetricks! :)

cheers, josch

signature.asc
Description: signature

Bug#986650: winetricks: move from contrib to main

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Jens Reyer (2021-07-04 14:36:13)
> On 08.04.21 22:47, Johannes 'josch' Schauer wrote:
> > a recent threat on debian-devel [1] revealed that winetricks falls into the
> > same category as other packages that are happily sitting in main.
> > Specifically, winetricks not only allows to download non-free software but
> > also DFSG-free software like dxvk or faudio. As such it is in the same
> > category as many other packages in main that allow to download both free
> > and non-free binaries from the internet if the user requests it to do so.
> > 
> > Since other packages that allow to download and run non-free stuff are
> > allowed in main I think winetricks can be uploaded to main.
> > 
> > The advantage would be that this would make it easier for our users to
> > install winetricks.
> > 
> > Thanks!
> > 
> > cheers, josch
> > 
> > [1] https://lists.debian.org/20210404091701.eum2iid4ffvpfn3v@frifot
> 
> thanks, I agree that winetricks can be moved to "main".  Although the thread
> was not completely in favor of doing so, I think there was a loose consensus
> that this is ok.
> 
> I'm a DM, so I can't upload to NEW which (afair) is required for such a
> change.  I'd appreciate it if you or some other DD directly took care of
> that after the freeze (without me preparing this trivial change upload).
> 
> Since I'm in the process of stepping down as Debian maintainer I generally
> welcome anyone taking over winetricks maintainership.

I would upload the package to main/experimental today if you have no
objections?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#986650: winetricks: move from contrib to main

[Jens Reyer]

On 08.04.21 22:47, Johannes 'josch' Schauer wrote:
> Package: winetricks
> Version: 0.0+20210206-1
> Severity: normal
> 
> Hi,
> 
> a recent threat on debian-devel [1] revealed that winetricks falls into
> the same category as other packages that are happily sitting in main.
> Specifically, winetricks not only allows to download non-free software
> but also DFSG-free software like dxvk or faudio. As such it is in the
> same category as many other packages in main that allow to download both
> free and non-free binaries from the internet if the user requests it to
> do so.
> 
> Since other packages that allow to download and run non-free stuff are
> allowed in main I think winetricks can be uploaded to main.
> 
> The advantage would be that this would make it easier for our users to
> install winetricks.
> 
> Thanks!
> 
> cheers, josch
> 
> [1] https://lists.debian.org/20210404091701.eum2iid4ffvpfn3v@frifot

Hi josch,

thanks, I agree that winetricks can be moved to "main".  Although the
thread was not completely in favor of doing so, I think there was a
loose consensus that this is ok.

I'm a DM, so I can't upload to NEW which (afair) is required for such a
change.  I'd appreciate it if you or some other DD directly took care of
that after the freeze (without me preparing this trivial change upload).

Since I'm in the process of stepping down as Debian maintainer I
generally welcome anyone taking over winetricks maintainership.

Greets and sorry for the late answer
jre



OpenPGP_signature
Description: OpenPGP digital signature

Bug#990671: libjdom2-java: CVE-2021-33813

[Salvatore Bonaccorso]

Source: libjdom2-java
Version: 2.0.6-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/hunterhacker/jdom/pull/188
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: clone -1 -2
Control: reassign -2 src:libjdom1-java 1.1.3-2
Control: found -1 2.0.6-1
Control: found -2 1.1.3-2

Hi,

The following vulnerability was published for libjdom2-java.

CVE-2021-33813[0]:
| An XXE issue in SAXBuilder in JDOM through 2.0.6 allows attackers to
| cause a denial of service via a crafted HTTP request.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-33813
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33813
[1] https://github.com/hunterhacker/jdom/pull/188
[2] https://alephsecurity.com/vulns/aleph-2021003

Regards,
Salvatore

Bug#990397: What are the development priorities for the csironn library? (was Bug#990397: depends on deprecated qhull library)

[Alan W. Irwin]

Hi Timo:

As a Debian user, I agreed with what you said all the way down the
line concerning how Debian is dealing with this transition from
libqhull to reentrant libqhull_r.

Furthermore, it looks like there is already a patch submitted to
upstream PLplot to solve this issue which I will be looking at fairly
soon.  If comprehensive testing works for that patch I will accept it
upstream, and in that case and assuming Rafael's tests work as well, I
assume Rafael will also accept that patch downstream in order to close
your bug#990397 against PLplot as fixed.

Best wishes for many more such quick fixes for this issue,

Alan
__
Alan W. Irwin

Research affiliation with the Department of Physics and Astronomy,
University of Victoria, Victoria, BC, Canada.

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Bug#990670: [pre-approval] unblock: python-apt/2.2.1

[Julian Andres Klode]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: j...@debian.org

Please unblock package python-apt

[ Reason ]

- Mark python-apt-common as Multi-Arch: common to unblock the
  crossgrader script (#968458). People have very varied understanding
  about severity of this; it's just a single line anyway.
- update the mirror lists.

[ Impact ]
People can't crossgrade and might see outdated mirror information
in mirror selection tools like software-properties

[ Tests ]
No code changed, just metadata. Unit tests are run at
build time and during autopkgtest.


[ Risks ]

It's just metadata changes, only risk is like regressions
in toolchain since last upload.

[ 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 testing

unblock python-apt/2.2.1

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


python-apt_2.2.1.diff.gz
Description: application/gzip

Bug#990659: qemu-system-misc: qemu-riscv64-static sometimes crashes while running gcc in chroot

[Rich]

When I tried building qemu 6.0 or git on buster, as I recall it
errored out on dependencies not available in sufficiently new
incarnations, even in backports.

If the answer to "this is quite buggy" is "just run a version not even
in unstable yet", that's...quite unfortunate.

If you're just saying this because it's qemu upstream's opinion, well,
I knew that. :)

On Sun, Jul 4, 2021 at 7:18 AM Michael Tokarev  wrote:
>
> 04.07.2021 02:45, Rich Ercolani wrote:
> > Package: qemu-system-misc
> > Version: 1:5.2+dfsg-9~bpo10+1
> [..]> [1726926.715475] cc1[66416]: segfault at 2ad48a0 ip 004857e0 sp 
> 7ffc9ef97948 error 4 in qemu-riscv64-static[401000+2cc000]
> > [1726926.715488] Code: 00 e9 24 fc 18 00 0f 1f 40 00 64 83 2c 25 60 ff ff 
> > ff 01 74 05 c3 0f 1f 40 00 48 8d 3d c9 6f 77 00 e9 74 0a 19 00 0f 1f 40 00 
> > <64> 8b 04 25 60 ff ff ff 85 c0 0f 9f c0 c3 66 90 48 83 ec 08 64 8b
> > [1726967.092517] cc1[71234]: segfault at 2ad58a0 ip 004857e0 sp 
> > 7ffc23573a18 error 4 in qemu-riscv64-static[401000+2cc000]
> > [1726967.092530] Code: 00 e9 24 fc 18 00 0f 1f 40 00 64 83 2c 25 60 ff ff 
> > ff 01 74 05 c3 0f 1f 40 00 48 8d 3d c9 6f 77 00 e9 74 0a 19 00 0f 1f 40 00 
> > <64> 8b 04 25 60 ff ff ff 85 c0 0f 9f c0 c3 66 90 48 83 ec 08 64 8b
> >
> > (There's a couple more.)
>
> First of all, please try the current version of qemu, which is 6.0.
> Riscv is a very rapidly developing system and it received a LOT of
> changes since 5.2 and even after 6.0. I suggest you to try current
> upstream git.
>
> Myself, I don't have any expirience in this area, I never used any
> riscv system or tools and know nothing about qemu emulation of it.
> If the more recent version shows the same issue, it is much better
> to ask upstream for more help.
>
> I'm sorry if this seems unhelpful, - but I can't pretend to be
> competent and just do nothing, either.
>
> Thanks!
>
> /mjt

Bug#986293: closed by Debian FTP Masters (reply to Adrian Bunk ) (Bug#986293: fixed in virtuoso-opensource 7.2.5.1+dfsg-3.1)

[Adrian Bunk]

On Tue, Jun 29, 2021 at 02:52:49PM +0200, Andreas Beckmann wrote:
> On 23/05/2021 16.21, Debian Bug Tracking System wrote:
> >   virtuoso-opensource (7.2.5.1+dfsg-3.1) unstable; urgency=medium
> 
> > * Drop the libvirtuoso5.5-cil package. (Closes: #986293)
> > * Updated debconf translations:
> 
> I've just reintroduced the -cil package (avoiding NEW since it was still as
> cruft in sid) since the upgrade error was actually caused by the mono
> dependency cycle. (mono fix is in experimental/NEW and RT approved)
> 
> Do you want to get the translation updates unbocked?

There is little point in getting the translation updates unblocked
when another update is pending for fixing/removing libvirtuoso5.5-cil.

> On 01/05/2021 17.14, Adrian Bunk wrote:
> > In any case there is a bug that libvirtuoso5.5-cil lost all dependencies
> > except cli-common in bullseye.
> 
> I haven't looked at that. Do you want to file a new bug for it?
> (#986293 has been reassigned to mono)

So file a new bug and then revert your NMU?

My fix for that was removing the package,
since I did not find any other solution.

> Andreas

cu
Adrian

Bug#990669: crossgrader: Third stage fails with protected packages

[Adrian Bunk]

Package: crossgrader
Version: 0.0.3+nmu2
Severity: important

Trying to do an amd64 -> i386 crossgrade after debootstrap
of the amd64 chroot fails with:

# crossgrader --third-stage amd64 i386
Installing initramfs binary architecture check hook...
arch check hook already installed.
Hook installation failed.
Hit http://deb.debian.org/debian sid InRelease
Fetched 0 B in 0s (0 B/s)
4 targets found.
gcc-10-base:amd64
libc6:amd64
libcrypt1:amd64
libgcc-s1:amd64
Do you want to continue [y/N]? y
dpkg: error processing package libcrypt1:amd64 (--purge):
 this is a protected package; it should not be removed
dpkg: error processing package libgcc-s1:amd64 (--purge):
 this is a protected package; it should not be removed
dpkg: dependency problems prevent removal of gcc-10-base:amd64:
 libgcc-s1:amd64 depends on gcc-10-base (= 10.2.1-6).

dpkg: error processing package gcc-10-base:amd64 (--purge):
 dependency problems - not removing
(Reading database ... 18110 files and directories currently installed.)
Removing libc6:amd64 (2.31-12) ...
Purging configuration files for libc6:amd64 (2.31-12) ...
Processing triggers for libc-bin (2.31-12) ...
Errors were encountered while processing:
 libcrypt1:amd64
 libgcc-s1:amd64
 gcc-10-base:amd64
Traceback (most recent call last):
  File "/usr/bin/crossgrader", line 33, in 
sys.exit(load_entry_point('debian-crossgrader==0.0.3', 'console_scripts', 
'crossgrader')())
  File "/usr/lib/python3/dist-packages/debian_crossgrader/__main__.py", line 
260, in main
third_stage(args)
  File "/usr/lib/python3/dist-packages/debian_crossgrader/__main__.py", line 
141, in third_stage
subprocess.check_call(['dpkg', '--purge'] + targets)
  File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['dpkg', '--purge', 
'gcc-10-base:amd64', 'libc6:amd64', 'libcrypt1:amd64', 'libgcc-s1:amd64']' 
returned non-zero exit status 1.
#


libgcc-s1 and libcrypt1 both got
  Protected: yes
to prevent accidental removal in some buster -> bullseye upgrade situations,
some additional forcing seems necessary to overwrite that.


It works after changing line 141 in
/usr/lib/python3/dist-packages/debian_crossgrader/__main__.py to:
if cont == 'y':
subprocess.check_call(['dpkg', '--purge', 
'--force-remove-protected'] + targets)

Bug#990659: qemu-system-misc: qemu-riscv64-static sometimes crashes while running gcc in chroot

[Michael Tokarev]

04.07.2021 02:45, Rich Ercolani wrote:

Package: qemu-system-misc
Version: 1:5.2+dfsg-9~bpo10+1

[..]> [1726926.715475] cc1[66416]: segfault at 2ad48a0 ip 004857e0 sp 
7ffc9ef97948 error 4 in qemu-riscv64-static[401000+2cc000]

[1726926.715488] Code: 00 e9 24 fc 18 00 0f 1f 40 00 64 83 2c 25 60 ff ff ff 01 74 05 
c3 0f 1f 40 00 48 8d 3d c9 6f 77 00 e9 74 0a 19 00 0f 1f 40 00 <64> 8b 04 25 60 
ff ff ff 85 c0 0f 9f c0 c3 66 90 48 83 ec 08 64 8b
[1726967.092517] cc1[71234]: segfault at 2ad58a0 ip 004857e0 sp 
7ffc23573a18 error 4 in qemu-riscv64-static[401000+2cc000]
[1726967.092530] Code: 00 e9 24 fc 18 00 0f 1f 40 00 64 83 2c 25 60 ff ff ff 01 74 05 
c3 0f 1f 40 00 48 8d 3d c9 6f 77 00 e9 74 0a 19 00 0f 1f 40 00 <64> 8b 04 25 60 
ff ff ff 85 c0 0f 9f c0 c3 66 90 48 83 ec 08 64 8b

(There's a couple more.)


First of all, please try the current version of qemu, which is 6.0.
Riscv is a very rapidly developing system and it received a LOT of
changes since 5.2 and even after 6.0. I suggest you to try current
upstream git.

Myself, I don't have any expirience in this area, I never used any
riscv system or tools and know nothing about qemu emulation of it.
If the more recent version shows the same issue, it is much better
to ask upstream for more help.

I'm sorry if this seems unhelpful, - but I can't pretend to be
competent and just do nothing, either.

Thanks!

/mjt

Bug#990636: qgis not listed as file browser alternative for opening kml files

[Sebastiaan Couwenberg]

Control: tags -1 fixed-upstream pending

Hi Jürgen,

Thanks for working on this upstream. [0]

See my comment there for further changes that have been applied to the
package in Debian.

On 7/3/21 5:03 PM, Jürgen E. Fischer wrote:
> On Sat, 03. Jul 2021 at 14:16:26 +0200, Sebastiaan Couwenberg wrote:
>> Are you sure qgis supports opening KML?
> 
> If it's a KML that GDAL recognizes, QGIS will load it.  E.g.
> 
> /usr/share/doc/libkml-dev/examples/kml/sky.kml
> 
> or
> 
> /usr/share/doc/libkml-dev/examples/kml/snippets.kml

I only tried the first file I found there:

 /usr/share/doc/libkml-dev/examples/kml/allstyles.kml

That one is apparently not supported.

The changes from the upstream commit and the shared-mime-info changes
have been applied in git, and will be included in the next upload.

[0]
https://github.com/qgis/QGIS/commit/ce3ee598e505cd2f7e9b5a857919caf332ca5439

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#990397: What are the development priorities for the csironn library? (was Bug#990397: depends on deprecated qhull library)

[Alan W. Irwin]

A message on this thread from Atri Bhattacharya
 bounced (presumably because he used a
non-subscription return address).  But as list administrator I saw
that bounced message which turned out to be of immediate interest.  So
I am reposting it here without asking Atri to resubmit with
subscription address == return address.

Atri said:
_

For openSUSE's plplot package, we have a patch to build against
libqhull_r, kindly contributed by Stefan. Here is the bug reference
which has the patch as an attachment:
. Would be great to get
this checked into plplot upstream.

Hope that helps.
_

Hi Atri:

I don't know how I missed that PLplot bug report with a patch that
from its title likely implements the csironn library
development topic that I just discussed on this thread!

Anyhow, thanks for drawing this patch to my attention, and I hope
I have time to take a close look at in in the coming week or so.

Alan
__
Alan W. Irwin

Research affiliation with the Department of Physics and Astronomy,
University of Victoria, Victoria, BC, Canada.

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Bug#990456: Processed: Bug#990456 marked as pending in openssh

[Colin Watson]

On Sun, Jul 04, 2021 at 08:17:59AM +, Martin wrote:
> Thanks for solving this so quickly, Colin!
> 
> But doesn't need the `addgroup --system --quiet` also `--force-badname`,
> if the group name starts with an underscore?

Yes, a CI job pointed that out as well - fixed.

> No harm done by `update_ssh_group_name()`, but maybe I would use
> `if ! getent group _ssh >/dev/null; then` instead of
> `if getent group ssh >/dev/null; then` just for the aesthetics (and to
> prevent postinst failure, in case both `ssh` and `_ssh` already exist).

The version check should deal with most of this in practice, but I've
added a check for _ssh in addition (rather than "instead").

Thanks,

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

Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade

[Olaf van der Spek]

Op zo 4 jul. 2021 om 00:42 schreef Colin Watson :
> Sorry for my delay - it took me a while to spot the problem.  libc6's
> postinst does arrange to restart services where needed, but in this case
> it doesn't realize that you have the ssh service installed because you
> only have the openssh-server package installed, not the ssh metapackage
> (i.e. the package with the same name as the service).
>
> I've proposed
> https://salsa.debian.org/glibc-team/glibc/-/merge_requests/3 to fix
> this.  glibc maintainers, if there's any way to get this into bullseye,
> I'm sure it would help avoid some people upgrading remote systems ending
> up being unable to fix them if something goes wrong between configuring
> libc6 and configuring openssh-server.  Also CCing debian-release for
> their information, as I know it's pretty late for glibc changes.

Thanks Colin!

I assume openssh-server would then be restarted after the "There are
services installed on your system which need to be
restarted when certain libraries, such as libpam, libc, and libssl,
are upgraded." question. But ssh is already 'down' when that question
is being asked, so wouldn't there still be a time window, with
required user interaction, where ssh would be 'down'?




-- 
Olaf

Bug#990397: What are the development priorities for the csironn library? (was Bug#990397: depends on deprecated qhull library)

[Timo Röhling]

Hi Alan!

* Alan W. Irwin  [2021-07-04 01:16]:

 However, I quarrel with that "likely to disappear soon" phrase since
 on that subject the qhull developers say the following (from
 ):

 "New code should be written with libqhull_r. Existing users of
 libqhull should consider converting to libqhull_r. Although *libqhull
 will be supported indefinitely* [emphasis mine], improvements may not be
 implemented."


As the submitter of the original bugreport and co-maintainer of the
Debian qhull packages, I admit I overlooked that statement of
indefinite support. However, upstream did stop building the libqhull
shared library in their CMakeLists.txt and I had to patch the file
to re-enable it for the latest release [1]. I felt this development
was justification enough to prod the qhull reverse-dependencies to
move towards the reentrant version.

Of course, I'm not going to drop libqhull support unless all
reverse-dependencies in Debian have transitioned to the reentrant
version or upstream forces my hand by actively removing the sources
from the release (which seems very unlikely now in light of the
above statement), so the transition is still beneficial (IMHO), but
not urgent.


Cheers
Timo

[1] 
https://sources.debian.org/src/qhull/2020.2-3/debian/patches/0006-Build-deprecated-libqhull-for-now.patch/

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#931339: dirmgr in buster now points to invalid key servers

[Harald Welte]

I've seen this has already been fixed in bullseye, but a current debian
stable/buster now ships with a default keyserver that has non-resolving
DNS records. (pool.sks-keyservers.net).

This in turn makes any application using dirmgr unusable by default.

One such example being 'lxc-create -t download' which now fails on a
non-customized buster installation.

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#872206: restic: broken symlinks: /usr/share/doc/restic/_static/*/* -> ../../../../sphinx_rtd_theme/*/*

[Andreas Beckmann]

Followup-For: Bug #872206

Hi,

there are still broken symlinks:

0m14.2s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/restic/html/_static/doctools.js -> 
../../../../javascript/sphinx-doc/html/_static/doctools.js (restic)
  /usr/share/doc/restic/html/_static/fonts/Lato-Bold.ttf -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-Bold.ttf (restic)
  /usr/share/doc/restic/html/_static/fonts/Lato-BoldItalic.ttf -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-BoldItalic.ttf (restic)
  /usr/share/doc/restic/html/_static/fonts/Lato-Italic.ttf -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-Italic.ttf (restic)
  /usr/share/doc/restic/html/_static/fonts/Lato-Regular.ttf -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-Regular.ttf (restic)
  /usr/share/doc/restic/html/_static/fonts/fontawesome-webfont.ttf -> 
../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.ttf (restic)
  /usr/share/doc/restic/html/_static/js/html5shiv-printshiv.min.js -> 
../../../../../sphinx_rtd_theme/static/js/html5shiv-printshiv.min.js (restic)
  /usr/share/doc/restic/html/_static/js/html5shiv.min.js -> 
../../../../../sphinx_rtd_theme/static/js/html5shiv.min.js (restic)
  /usr/share/doc/restic/html/_static/language_data.js -> 
../../../../javascript/sphinx-doc/html/_static/language_data.js (restic)
  /usr/share/doc/restic/html/_static/searchtools.js -> 
../../../../javascript/sphinx-doc/html/_static/searchtools.js (restic)

Some of the targets would be provided by sphinx-rtd-theme-common,
but most?/all? .js files are not located (any more?) at the
targeted location.

Theoretically you should be able to use the ${sphinxdoc:Depends}
substitution variable generated by sphinxdoc to get the correct
dependencies, but that does not seem to get populated for your
package. Perhaps you are calling sphinxdoc in some non-standard
way?

Andreas

PS: Also a 'Suggests: ${sphinxdoc:Depends}' would be fine if
it brings the correct dependencies.

Bug#990667: dgit(7) Documentation: MODEL dgit-repo, --overwrite, /fast forward/fast-forward/, --deliberately-not-fast-forward, ...

[Osamu Aoki]

Package: dgit
Version: 9.13
Severity: wishlist

This is a wishlist bug report on dgit(7) and dgit(1) documentation.

dgit is a very useful tool which I think all Debian actively maintained
packages eventually need to migrate to.  But dgit suffers fear,
self-imposed uncertainty, and doubt feelings from well-intended DDs
since it does many irreversible things such as uploading
(source-)packages with very scant explanation of its design and
functioning principles in its documents.  For example, the documentation
of dgit encourages to use "--overwrite" to make dgit to behave in
non-default way without mentioning possible adverse effects explicitly.

As I read https://bugs.debian.org/913451, it looks quite complicated due
to the task dealing is complicated. ( ... still, I am not sure exactly
how this impacts us).  The word like "overwrite" is scary for publicly
published git contents.  Another scary thing is
"deliberately-not-fast-forward".

I think dgit(7), especially around "MODEL" needs more love.

* What exactly is dgit-repo?
  * Is this URL printed by dgit print-dgit-repos-server-source-url?
git+ssh://d...@push.dgit.debian.org/dgit/debian/repos/_dgit-repos-server.git
  or repo like:
https://git.dgit.debian.org/dgit (for dgit)
  or
https://salsa.debian.org/dgit-team/dgit.git (for dgit)

* What is the role separation between the "package VCS site" and
  dgit-repo?   I mean "package VCS site" such as:
Vcs-Git: https://salsa.debian.org/dgit-team/dgit.git

* Where do operation such as "dgit push" and "dgit push-source" send
  data to?
  * dgit-repo  (?, one got from dgit clone had following refs)
- vcs-git (looks like normal branch tracking Vcs-Git repo)
- dgit(gitk works but "git ls-remote" doesn't work)
  * Vcs-Git git repo accessed by git
- origin  (has archive/... tags but no dgit like branch)
  * Debian archive (incoming)

* Usage of words: "repo" and "archive", within dgit context may be
  documented clearly somewhere.

* Why some dgit documents use "fast forward" without hyphen and some
  dgit documents use "fast-forward" with hyphen.  (It looks like
  git-merge(1) consistently uses "fast-forward" with hyphen.)  Are they
  used in the same sense as used by git-merge(1)?  If so, it may be
  better to mention it.  Please also explain
  --deliberately-not-fast-forward.

* In --overwrite section in dgit(1) doesn't mention
  --deliberately-not-fast-forward.  The --overwrite seems to me for the
  *first* time for each suite but "not the very first upload with dgit".
  This latter fact needs to be documented clearly.  Anyway, these 2
  things may scare new users.

* In MODEL, in the following text, "used" is very confusing:

   dgit maintains a pseudo-remote called dgit, with one branch per
   suite.  This remote cannot be used with plain git.

At least, gitk can be used to identify their existence.  I see git remote
branch like remotes/dgit/dgit/sid in gitk for the local repository which
used dgit but "git ls-remote" etc. doesn't seem to work.  I don't see
definition what exactly is the *pseudo-remote* in MODEL.  I don't know
exactly but something like:

   dgit pseudo-remote commit is like a git commit refs but without
   the actual file content in the git repository.  Actual file
   content needs to be obtained by dgit. (or whatever it actually
   does, please describe.)

   dgit maintains a pseudo-remote called dgit, with one branch per
   suite.  The existence of such branch ad associated tags can be
   seen by gitk ... but cannot be used with plain git since it is
   missing some normal git file content.  The content of 
   archive 

The mastery of pseudo-remote and its persistence over --overwrite gives
me iffy feeling.

The good news is dgit stops if try to do something stupid.

Thanks and regards

Osamu


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

Kernel: Linux 5.10.0-7-amd64 (SMP w/12 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 dgit depends on:
ii  apt2.2.4
ii  ca-certificates20210119
ii  coreutils  8.32-4+b1
ii  curl   7.74.0-1.3
ii  devscripts 2.21.2
ii  dpkg-dev   1.20.9
ii  dput   1.1.0
ii  git [git-core] 1:2.30.2-1
ii  git-buildpackage   0.9.22
ii  libdpkg-perl   1.20.9
ii  libjson-perl   4.03000-1
ii  liblist-moreutils-perl 0.430-2
ii  liblocale-gettext-perl 1.07-4+b1
ii  libtext-csv-perl   2.00-1
ii  libtext-glob-perl  0.11-1
ii  libtext-iconv-perl 1.7-7+b1
ii  libwww-curl-perl   4.17-7+b1
ii  perl [libdigest-sha-perl]  5.32.1-4

Versions of 

Bug#931339: gnupg: Change default keyserver?

[Paul Wise]

Control: fixed -1 2.2.27-2
Control: severity -1 important

On Tue, 2 Jul 2019 15:55:32 +0200 Guillem Jover wrote:

> According to the dirmngr(8) man page, the default built-in server is
> «hkps://hkps.pool.sks-keyservers.net». Given the recent attacks, and
> the problems inherent in that network, could we just change the
> default to be «hkps://keys.openpgp.org» instead?

This is fixed in bullseye, but not buster. Now that sks-keyservers.net
is no longer working, Debian users on bullseye are having issues, so it
would be great if the default could be updated in buster/stretch too:

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#upload-stable

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#990666: ns3-doc: broken symlinks: /usr/share/doc/ns3/manual/html/_static/*.js -> ../../../../../javascript/sphinxdoc/1.0/*.js

[Andreas Beckmann]

Package: ns3-doc
Version: 3.31+dfsg-2
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m13.6s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/ns3/doxygen/jquery.js -> 
../../../javascript/sphinxdoc/1.0/jquery.js (ns3-doc)
  /usr/share/doc/ns3/manual/html/_static/jquery.js -> 
../../../../../javascript/sphinxdoc/1.0/jquery.js (ns3-doc)
  /usr/share/doc/ns3/manual/html/_static/underscore.js -> 
../../../../../javascript/sphinxdoc/1.0/underscore.js (ns3-doc)
  /usr/share/doc/ns3/models/html/_static/jquery.js -> 
../../../../../javascript/sphinxdoc/1.0/jquery.js (ns3-doc)
  /usr/share/doc/ns3/models/html/_static/underscore.js -> 
../../../../../javascript/sphinxdoc/1.0/underscore.js (ns3-doc)
  /usr/share/doc/ns3/tutorial/html/_static/jquery.js -> 
../../../../../javascript/sphinxdoc/1.0/jquery.js (ns3-doc)
  /usr/share/doc/ns3/tutorial/html/_static/underscore.js -> 
../../../../../javascript/sphinxdoc/1.0/underscore.js (ns3-doc)

Theoretically you should be able to use the ${sphinxdoc:Depends}
substitution variable generated by sphinxdoc to get the correct
dependencies, but that does not seem to get populated for your
package. Perhaps you are calling sphinxdoc in some non-standard
way?

There is a (manually added?) dependency on libjs-jquery, but there
should rather/also be one on libjs-sphinxdoc.


cheers,

Andreas


ns3-doc_3.31+dfsg-2.log.gz
Description: application/gzip

Bug#990665: libflint-doc: broken symlinks: /usr/share/doc/libflint-dev/html/_static/*.js -> ../../../../javascript/sphinxdoc/1.0/*.js

[Andreas Beckmann]

Package: libflint-doc
Version: 2.6.3-3
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m14.1s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/libflint-dev/html/_static/doctools.js -> 
../../../../javascript/sphinxdoc/1.0/doctools.js (libflint-doc)
  /usr/share/doc/libflint-dev/html/_static/language_data.js -> 
../../../../javascript/sphinxdoc/1.0/language_data.js (libflint-doc)
  /usr/share/doc/libflint-dev/html/_static/searchtools.js -> 
../../../../javascript/sphinxdoc/1.0/searchtools.js (libflint-doc)

Theoretically you should be able to use the ${sphinxdoc:Depends}
substitution variable generated by sphinxdoc to get the correct
dependencies, but that does not seem to get populated for your
package. Perhaps you are calling sphinxdoc in some non-standard
way?

There are (manually added?) dependencies on libjs-jquery,
libjs-mathjax, libjs-underscore, but there should rather/also
be one on libjs-sphinxdoc.


cheers,

Andreas


libflint-doc_2.6.3-3.log.gz
Description: application/gzip

Bug#990397: What are the development priorities for the csironn library? (was Bug#990397: depends on deprecated qhull library)

[Alan W. Irwin]

On 2021-07-02 10:38+0200 Rafael Laboissière wrote:


Dear PLplot developers,

I am hereby forwarding a bug report filed against the Debian plplot package 
regarding the use of a deprecated Qhull library [1]. Conversion of the code 
to the reentrant version of Qhull needs more changes than merely linking 
against libqhull_r.so instead of libqhull.so and including 
libqull_r/qhull_ra.h instead of libqull/qhull_a.h [2], and should be done by 
the upstream authors.


Hi Rafael:

Since this email is primarily directed to the upstream Plplot
development list, I have generalized this discussion of how upstream
PLplot development should respond to Debian Bug#990397 to the new
subject line which is "What are the development priorities for the
csironn library?".  I would value your input into that general
discussion since you are a former PLplot developer who at that time
had a lot of interest in that library and its dependence on libqhull.

You likely know all this stuff already, but to set up this discussion
for the benefit of the others here, this is a quick review why the
plgriddata routine and therefore PLplot depends on our csironn library, and
that library in turn depends on the libqhull library.

The lib/nn/README file documents that question from the historical
(2003!)  viewpoint.  To add to that from my own current perspective,
the fundamental issue appears to be that Pavel Sakov's free nn-c
library throughout its history including [it's latest
version](https://github.com/sakov/nn-c) has depended on [the triangle
library](http://www.cs.cmu.edu/~quake/triangle.html) whose licensing
terms are as follows:

"Please note that although Triangle is freely available, it is
copyrighted by the author and may not be sold or included in
commercial products without a license."

You (and other Debian developers) know a lot more about licensing
legalities than I do so please let me know whether this license means
in Debian packaging terms Triangle is non-free as asserted in
lib/nn/README and therefore nn-c is "contrib" rather than "free" in
Debian packaging terms.

Anyhow, as a result of that perceived (and likely real, but that needs
confirmation) licensing issue Joao stripped the version of the nn-c
library available in 2003 to just what was needed by plgriddata, and
replaced all calls to triangle library routines in that stripped
version with the equivalent libqhull calls.  Anyhow it is that
stripped and triangle-replaced ancient version of nn-c that we call
csironn and that we have been maintaining (in a small way since 2003) as a free
(as opposed to contrib if the above licensing issue is confirmed) fork
of nn-c.

To help motivate further discussion of the subject-line topic would
you please briefly comment on the *potential* importance of the
csironn library in the free software world?  My guess is you will find
in practice it is not important (at least at present) because nobody
knows about this PLplot gem, e.g., you will likely discover that no
other Debian package depends on our csironn library.  However, do you agree
with me that situation is a real shame since the issue of
interpolating from non-gridded sample points to gridded sample points
is an important and fairly common issue that is nicely addressed by
our csironn library?

I would also appreciate your responses to the following comments and
questions concerning the new subject line topic:

* The original Debian Bug#990397 that started me thinking about this
  general topic states

  "your package builds and links against the non-reentrant version of
  Qhull, which has been deprecated by Qhull upstream and is likely to
  disappear soon."

  However, I quarrel with that "likely to disappear soon" phrase since
  on that subject the qhull developers say the following (from
  ):

  "New code should be written with libqhull_r. Existing users of
  libqhull should consider converting to libqhull_r. Although *libqhull
  will be supported indefinitely* [emphasis mine], improvements may not be
  implemented."

  It is up to you, of course, but my feeling is you would be entirely
  justified in closing this bug report because of the "supported
  indefinitely" phrase above which completely contradicts the premise
  of the bug report!

  That said, from this language from the qhull developers I do agree use
  of libqhull is (very lightly) deprecated.  Therefore "it would be
  nice" for libcsironn to change its dependence on libqhull to a
  dependence on libqhull_r (as suggested by the libqhull developers and you)
  since rentrancy although not the same as thread-safe often is a step
  toward thread safety which is an extremely desirable library
  characteristic.  It does appear (from comments later in the above
  URL) this change would be straightforward so this should be a nice
  simple development topic for someone to implement.

* It "would be nice" to update our fork to the latest version of nn-c.
  The reason I 

Bug#990456: Processed: Bug#990456 marked as pending in openssh

[Martin]

Thanks for solving this so quickly, Colin!

But doesn't need the `addgroup --system --quiet` also `--force-badname`,
if the group name starts with an underscore?

No harm done by `update_ssh_group_name()`, but maybe I would use
`if ! getent group _ssh >/dev/null; then` instead of
`if getent group ssh >/dev/null; then` just for the aesthetics (and to
prevent postinst failure, in case both `ssh` and `_ssh` already exist).

Bug#990664: libflint-arb-doc: broken symlinks: /usr/share/doc/libflint-arb-doc/html/_static/*.js -> ../../../../javascript/sphinxdoc/1.0/*.js

[Andreas Beckmann]

Package: libflint-arb-doc
Version: 1:2.19.0-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m10.9s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/libflint-arb-doc/html/_static/doctools.js -> 
../../../../javascript/sphinxdoc/1.0/doctools.js (libflint-arb-doc)
  /usr/share/doc/libflint-arb-doc/html/_static/jquery.js -> 
../../../../javascript/sphinxdoc/1.0/jquery.js (libflint-arb-doc)
  /usr/share/doc/libflint-arb-doc/html/_static/language_data.js -> 
../../../../javascript/sphinxdoc/1.0/language_data.js (libflint-arb-doc)
  /usr/share/doc/libflint-arb-doc/html/_static/searchtools.js -> 
../../../../javascript/sphinxdoc/1.0/searchtools.js (libflint-arb-doc)
  /usr/share/doc/libflint-arb-doc/html/_static/underscore.js -> 
../../../../javascript/sphinxdoc/1.0/underscore.js (libflint-arb-doc)

Theoretically you should be able to use the ${sphinxdoc:Depends}
substitution variable generated by sphinxdoc to get the correct
dependencies, but that does not seem to get populated for your
package. Perhaps you are calling sphinxdoc in some non-standard
way?


cheers,

Andreas


libflint-arb-doc_1:2.19.0-1.log.gz
Description: application/gzip

Bug#990663: unblock: libuv1/1.40.0-1

[Dominique Dumont]

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

Please unblock package libuv1

[ Reason ]
libuv1 1.40.0-1 is affected by CVE-2021-22918
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990561

In more details:

> Node.js (through libuv1) is vulnerable to out-of-bounds read in
> libuv's uv__idna_toascii() function which is used to convert strings
> to ASCII. This is called by Node's dns module's lookup() function and
> can lead to information disclosures or crashes.

See https://nodejs.org/en/blog/vulnerability/july-2021-security-releases/

I've applied a patch prepared by upstream.
https://github.com/nodejs/node/commit/d33aead28bcec32a2a450f884907a6d971631829

Debdiff does not give much information besides the changelog.

The patch is:
https://salsa.debian.org/debian/libuv1/-/blob/debian/sid/debian/patches/fix-cve-2021-22918


[ Impact ] Without this patch, libuv1 (hence nodejs and may be raku)
are vulnerable to specially crafted host names encoded in punicode.

[ Tests ]
Upstream patch contains specific tests that check that the
vulnerability was fixed.

[ Risks ] Hmm. I guess risk is low as the patch is not so big. I also
trust the judgment of upstream.

[ 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 testing


unblock libuv1/1.40.0-1
diff -Nru libuv1-1.40.0/debian/changelog libuv1-1.40.0/debian/changelog
--- libuv1-1.40.0/debian/changelog  2020-10-31 18:43:46.0 +0100
+++ libuv1-1.40.0/debian/changelog  2021-07-04 09:43:38.0 +0200
@@ -1,3 +1,9 @@
+libuv1 (1.40.0-2) unstable; urgency=medium
+
+  * add patch for CVE-2021-22918 (Closes: #990561)
+
+ -- Dominique Dumont   Sun, 04 Jul 2021 09:43:38 +0200
+
 libuv1 (1.40.0-1) unstable; urgency=medium
 
   * new upstream version

Bug#990561: libuv1: CVE-2021-22918

[Dominique Dumont]

On Friday, 2 July 2021 10:36:18 CEST you wrote:
> The patch hasn't landed in libuv.git, but here's the patch as applied
> by nodejs:
> https://github.com/nodejs/node/commit/d33aead28bcec32a2a450f884907a6d9716318
> 29

This patch modifies a file that was introduced in version 1.24.

So I guess that buster and backport are also vulnerables.

I will upload a new package to unstable soon.

All the best.

Bug#990662: nouveau 0000:01:00.0: firmware: failed to load nouveau/nvd9_fuc084 (-2)

[Mathieu Malaterre]

Package: firmware-misc-nonfree
Version: 20210315-2~bpo10+1

It would be super nice to distribute the nividia/nouveau firmware in
firmware-misc-nonfree. Right now symptoms are:

[127020.582478] nouveau :01:00.0: firmware: failed to load
nouveau/nvd9_fuc084 (-2)
[127020.582481] firmware_class: See https://wiki.debian.org/Firmware
for information about missing firmware
[127020.582482] nouveau :01:00.0: Direct firmware load for
nouveau/nvd9_fuc084 failed with error -2
[127020.582487] nouveau :01:00.0: firmware: failed to load
nouveau/nvd9_fuc084d (-2)
[127020.582488] nouveau :01:00.0: Direct firmware load for
nouveau/nvd9_fuc084d failed with error -2
[127020.582489] nouveau :01:00.0: msvld: unable to load firmware data
[127020.582491] nouveau :01:00.0: msvld: init failed, -19
[127064.484342] nouveau :01:00.0: firmware: failed to load
nouveau/nvd9_fuc084 (-2)
[127064.484353] nouveau :01:00.0: Direct firmware load for
nouveau/nvd9_fuc084 failed with error -2
[127064.484375] nouveau :01:00.0: firmware: failed to load
nouveau/nvd9_fuc084d (-2)
[127064.484380] nouveau :01:00.0: Direct firmware load for
nouveau/nvd9_fuc084d failed with error -2
[127064.484384] nouveau :01:00.0: msvld: unable to load firmware data
[127064.484389] nouveau :01:00.0: msvld: init failed, -19

Reference:

https://build.opensuse.org/package/view_file/hardware/nvidia-firmware-installer/nvidia-firmware-installer.spec?expand=1
https://raw.githubusercontent.com/envytools/firmware/master/extract_firmware.py

Thanks

Bug#990397: Reopen Bug#990397, fixed in experimental

[Rafael Laboissière]

Control: reopen -1
Control: tags -1 + fixed-in-experimental

I am hereby reopening this bug report and tagging it accordingly. The 
fixed version was uploaded to experimental and the version currently in 
sid and testing is impacted by the bug.


Rafael Laboissière

Bug#990661: polyml: Consider making 'libpolyml-dev' a dependent package

[William Mitchell Jr]

Package: polyml
Version: 5.7.1-4
Severity: wishlist
X-Debbugs-Cc: wdm...@gmail.com

Dear Maintainer,

Since the Poly/ML compiler 'polyc' is included in the 'polyml' package, please
consider including 'libpolyml-dev' as a dependent package because
'polyc' is usesless without it.

Thanks,
William

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

Kernel: Linux 5.10.0-7-amd64 (SMP w/2 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 polyml depends on:
ii  file1:5.39-3
ii  g++ 4:10.2.1-1
ii  libc6   2.31-12
ii  libffi-dev  3.3-6
ii  libpolyml9  5.7.1-4
ii  polyml-modules  5.7.1-4

polyml recommends no packages.

polyml suggests no packages.

-- no debconf information