Bug#982587: ckeditor: CVE-2021-26271 CVE-2021-26272

[Salvatore Bonaccorso]

Source: ckeditor
Version: 4.12.1+dfsg-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for ckeditor.

CVE-2021-26271[0]:
| It was possible to execute a ReDoS-type attack inside CKEditor 4
| before 4.16 by persuading a victim to paste crafted text into the
| Styles input of specific dialogs (in the Advanced Tab for Dialogs
| plugin).


CVE-2021-26272[1]:
| It was possible to execute a ReDoS-type attack inside CKEditor 4
| before 4.16 by persuading a victim to paste crafted URL-like text into
| the editor, and then press Enter or Space (in the Autolink plugin).


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-26271
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-26271
[1] https://security-tracker.debian.org/tracker/CVE-2021-26272
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-26272

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#982586: otrs2: CVE-2021-21435

[Salvatore Bonaccorso]

Source: otrs2
Version: 6.0.30-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for otrs2.

CVE-2021-21435[0]:
| Article Bcc fields and agent personal information are shown when
| customer prints the ticket (PDF) via external interface. This issue
| affects: OTRS AG OTRS 7.0.x version 7.0.23 and prior versions; 8.0.x
| version 8.0.10 and prior versions.

According to [1] it affects as well the 6.0.x versions but there is no
mention of a fix in the 6.0.x series yet.


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-21435
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21435
[1] https://otrs.com/release-notes/otrs-security-advisory-2021-02/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#982284: fonts-yuseki-magic: wrong long description: identical to that of fonts-yusei-magic

[Hideki Yamane]

control: reassign -1 ftp.debian.org
control: retitle -1 RoM: fonts-yuseki-magic uploader's mistake

Hi,

 I'm really sorry that it was mistake by me, just typo of fonts-yusei-magic...
 Could you remove it from experimental repo, please?


-- 
Hideki Yamane 

Bug#982530: libpam-modules: unable to login when using pam_tally2 after upgrade to libpam-modules >1.4.0

[Martin Schurz]

Am 2021-02-12 00:46, schrieb Sam Hartman:

Why wouldn't we just comment out the lines in the upgrade rather than
blocking the upgrade?


I absolutely want to avoid breaking pam config for the user. I am not
sure if we can comment out something without possibly causing havoc.
I am not overly familiar with debian, so I might miss some important
places.

From what I understand we would need to search for any file in
/usr/share/pam-configs that contains pam_tally and run "pam-auth-update
--package --remove ". I am currently not sure how to handle files
is /usr/share/pam. I suppose we could comment out lines there.

After this we need to check files in /etc/pam.d because, if the user
already manually edited these, pam-auth-update will not touch them.
That is also why we should not just comment directly in /etc/pam.d.

Another problem with commenting is pam stacking, some pam modules like
to be called differently if they come first, and pam_tally usually has
the first place in configs. So this would change the parameters of the
new first module. This is something we cannot handle automatically.

So as a short summary, if the user uses pam-auth-config and did not
break stuff before, I think we could handle this, but anything further
than that will get complicated very fast.

The main problem is, once the update is installed, it is already to
late and pam is broken. The user would have to keep the session where
the upgrade was started and fix the problem exactly in this moment,
or be locked out from the system.

In any case we really should write a message to the user, because we
are disabling a willfully enabled security feature.

Bug#981419: closed by Debian FTP Masters (reply to Timo Aaltonen ) (Bug#981419: fixed in libwacom 1.8-1)

[Helmut Grohne]

Control: reopen -1

On Wed, Feb 10, 2021 at 10:21:05AM +, Debian Bug Tracking System wrote:
> @@ -2,7 +2,7 @@
>  
>  override_dh_auto_configure:
>   dh_auto_configure -- \
> - -Dudev-dir=/lib/udev
> + -Dudev-dir=/lib/udev -Dtests=$(if $(filter 
> nocheck,$(DEB_BUILD_OPTIONS)),en,dis)abled
>  
>  override_dh_install:
>   find debian/tmp -name '*.la' -delete

I'm quite embarrassed that I got this wrong. I was sure that I had
tested this case, but it slipped through nonetheless.

The condition is inversed. A regular build now has tests disabled while
a nocheck build enables them. I think you want to fix that sooner rather
than later as none of the buildds perform tests now.


The ",en,dis)" needs to become ",dis,en)".

I'm sorry for the mess here.

Helmut

Bug#982585: astroscrappy: annotate test dependencies

[Helmut Grohne]

Source: astroscrappy
Version: 1.0.8-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

astroscrappy cannot be cross built from source, because it has
unsatisfiable cross Build-Depends. Instead of looking into such a
difficult problem, I looked for easily droppabel dependencies. It turns
out that a nocheck build with the following dependencies moved to
Build-Conflicts exactly reproduces the binary artifacts of a regular
build:
 * python3-astropy
 * python3-pytest
 * python3-scipy

Dropping any other dependency makes it FTBFS. Please consider applying
the attached patch to annotate the mentioned dependencies .

Helmut
diff --minimal -Nru astroscrappy-1.0.8/debian/changelog 
astroscrappy-1.0.8/debian/changelog
--- astroscrappy-1.0.8/debian/changelog 2018-12-22 13:44:31.0 +0100
+++ astroscrappy-1.0.8/debian/changelog 2021-02-12 08:01:00.0 +0100
@@ -1,3 +1,10 @@
+astroscrappy (1.0.8-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Annotate test dependencies . (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 12 Feb 2021 08:01:00 +0100
+
 astroscrappy (1.0.8-1) unstable; urgency=low
 
   * New upstream version 1.0.8. Rediff patches
diff --minimal -Nru astroscrappy-1.0.8/debian/control 
astroscrappy-1.0.8/debian/control
--- astroscrappy-1.0.8/debian/control   2018-12-13 15:04:07.0 +0100
+++ astroscrappy-1.0.8/debian/control   2021-02-12 07:58:05.0 +0100
@@ -7,11 +7,11 @@
   debhelper (>= 11),
dh-python,
python3-all-dev (>= 3.3),
-   python3-astropy,
+   python3-astropy ,
python3-astropy-helpers,
   python3-numpy,
-   python3-pytest,
-  python3-scipy,
+   python3-pytest ,
+  python3-scipy ,
python3-setuptools
 Standards-Version: 4.2.1
 Homepage: https://github.com/astropy/astroscrappy

Bug#982584: atig: change Architecture to all

[Helmut Grohne]

Source: atig
Version: 0.6.1-6
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

atig cannot be cross built from source, because some of its dependencies
are not satisfiable. While looking into the problem, I quickly noticed
that atig's contents exactly match on various architectures. That
strongly suggests that atig shouldn't be architecture-dependent. Please
consider changing the Architecture field from any to all. In doing so,
cross building becomes irrelevant. I'm attaching a patch for your
convenience.

Helmut
diff --minimal -Nru atig-0.6.1/debian/changelog atig-0.6.1/debian/changelog
--- atig-0.6.1/debian/changelog 2020-09-10 03:43:10.0 +0200
+++ atig-0.6.1/debian/changelog 2021-02-12 07:54:14.0 +0100
@@ -1,3 +1,10 @@
+atig (0.6.1-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Change Architecture to all. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 12 Feb 2021 07:54:14 +0100
+
 atig (0.6.1-6) unstable; urgency=medium
 
   [ Debian Janitor ]
diff --minimal -Nru atig-0.6.1/debian/control atig-0.6.1/debian/control
--- atig-0.6.1/debian/control   2020-09-10 03:43:10.0 +0200
+++ atig-0.6.1/debian/control   2021-02-12 07:54:12.0 +0100
@@ -20,7 +20,7 @@
 XS-Ruby-Versions: all
 
 Package: atig
-Architecture: any
+Architecture: all
 XB-Ruby-Versions: ${ruby:Versions}
 Depends: ruby | ruby-interpreter,
  ruby-net-irc,

Bug#982583: cftime: annotate test dependencies

[Helmut Grohne]

Source: cftime
Version: 1.4.1+ds-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

cftime cannot be cross built from source, because it has unsatisfiable
Build-Depends. Instead of looking into such a difficult problem, I
looked for easily droppable dependencies and noticed that all of
python3-coverage, python3-pytest and python3-pytest-cov are only used
for testing. Please consider applying the attached patch to annotate
them .

Helmut
diff --minimal -Nru cftime-1.4.1+ds/debian/changelog 
cftime-1.4.1+ds/debian/changelog
--- cftime-1.4.1+ds/debian/changelog2021-02-02 06:14:57.0 +0100
+++ cftime-1.4.1+ds/debian/changelog2021-02-11 13:11:48.0 +0100
@@ -1,3 +1,10 @@
+cftime (1.4.1+ds-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Annotate test dependencies . (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 11 Feb 2021 13:11:48 +0100
+
 cftime (1.4.1+ds-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru cftime-1.4.1+ds/debian/control 
cftime-1.4.1+ds/debian/control
--- cftime-1.4.1+ds/debian/control  2020-11-28 13:35:13.0 +0100
+++ cftime-1.4.1+ds/debian/control  2021-02-11 13:11:47.0 +0100
@@ -6,11 +6,11 @@
 Build-Depends: debhelper (>= 10~),
dh-python,
python3-all-dev,
-   python3-coverage,
+   python3-coverage ,
python3-setuptools,
python3-numpy,
-   python3-pytest,
-   python3-pytest-cov,
+   python3-pytest ,
+   python3-pytest-cov ,
cython3
 Standards-Version: 4.5.1
 Vcs-Browser: https://salsa.debian.org/debian-gis-team/cftime/

Bug#982582: mark libjs-jquery-colorbox Multi-Arch: foreign

[Helmut Grohne]

Package: libjs-jquery-colorbox
Version: 1.6.4-1.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:calf

calf cannot be cross built from source, because its dependency on
libjs-jquery-colorbox cannot be satisfied. In general, Architecture: all
packages can never satisfy cross Build-Depends unless marked Multi-Arch:
foreign or annotated :native. In this case, the foreign marking is
reasonable, because libjs-jquery-colorbox is a pure javascript library
with no maintainer scripts and all of its dependencies are already thus
marked. Please consider applying the attached patch.

Helmut
diff --minimal -Nru jquery-colorbox-1.6.4/debian/changelog 
jquery-colorbox-1.6.4/debian/changelog
--- jquery-colorbox-1.6.4/debian/changelog  2021-01-03 13:42:31.0 
+0100
+++ jquery-colorbox-1.6.4/debian/changelog  2021-02-11 14:06:14.0 
+0100
@@ -1,3 +1,10 @@
+jquery-colorbox (1.6.4-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark libjs-jquery-colorbox Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 11 Feb 2021 14:06:14 +0100
+
 jquery-colorbox (1.6.4-1.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff --minimal -Nru jquery-colorbox-1.6.4/debian/control 
jquery-colorbox-1.6.4/debian/control
--- jquery-colorbox-1.6.4/debian/control2018-08-18 13:22:26.0 
+0200
+++ jquery-colorbox-1.6.4/debian/control2021-02-11 14:06:13.0 
+0100
@@ -12,6 +12,7 @@
 
 Package: libjs-jquery-colorbox
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}, libjs-jquery
 Recommends: javascript-common
 Description: jQuery customizable lightbox

Bug#982581: mark node-d3-array Multi-Arch: foreign

[Helmut Grohne]

Package: node-d3-array
Version: 1.2.4-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:ataqv

ataqv cannot be cross built from source, becuase its transitive
dependency on node-d3-array cannot be satisfied. In general,
Architecture: all packages can never satisfy cross Build-Depends unless
marked Multi-Arch: foreign or annotated :native. In this case, the
foreign marking is reasonable, because node-d3-array is a pure
javascript library that entirely lacks maintainer scripts and has all of
its dependencies annotated Multi-Arch: foreign. Please consider applying
the attached patch.

Helmut
diff --minimal -Nru node-d3-array-1.2.4/debian/changelog 
node-d3-array-1.2.4/debian/changelog
--- node-d3-array-1.2.4/debian/changelog2020-12-14 12:28:42.0 
+0100
+++ node-d3-array-1.2.4/debian/changelog2021-02-12 07:48:21.0 
+0100
@@ -1,3 +1,10 @@
+node-d3-array (1.2.4-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark node-d3-array Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 12 Feb 2021 07:48:21 +0100
+
 node-d3-array (1.2.4-3) unstable; urgency=medium
 
   [ Debian Janitor ]
diff --minimal -Nru node-d3-array-1.2.4/debian/control 
node-d3-array-1.2.4/debian/control
--- node-d3-array-1.2.4/debian/control  2020-12-14 12:28:42.0 +0100
+++ node-d3-array-1.2.4/debian/control  2021-02-12 07:48:18.0 +0100
@@ -19,6 +19,7 @@
 
 Package: node-d3-array
 Architecture: all
+Multi-Arch: foreign
 Depends:
  ${misc:Depends}
  , nodejs

Bug#981426: RM: cu2qu -- ROM; merged to fonttools

[Hideki Yamane]

Hi Yao,

On Fri, 12 Feb 2021 10:49:57 +0800
Yao Wei  wrote:
> >  And Yao, please push your changes for ufo2ft to salsa repo.
> 
> Done!  I forgot to push branch again :/

 Thanks! pushed.



-- 
Hideki Yamane 

Bug#974836: openconnect FTBFS on IPV6-only buildds

[Niko Tyni]

On Thu, Nov 26, 2020 at 05:42:35PM +, Luca Boccassi wrote:
> Control: tags -1 moreinfo unreproducible
> Control: severity -1 important
> 
> On Sun, 15 Nov 2020 13:25:11 +0200 Adrian Bunk  wrote:
> > Source: openconnect
> > Version: 8.10-1
> > Severity: serious
> > Tags: ftbfs
> > 
> > https://buildd.debian.org/status/fetch.php?pkg=openconnect=i386=8.10-1~bpo10%2B1=1589917131=0
> 
> > https://buildd.debian.org/status/fetch.php?pkg=openconnect=amd64=8.10-1~bpo10%2B1=1589912458=0
> 
> > https://buildd.debian.org/status/fetch.php?pkg=openconnect=amd64=8.10-2=1603997003=0

> Can't reproduce this in a sid chroot + unshare -n + ip link set dev lo up + 
> ip addr del 127.0.0.1/8 dev lo

> Anything specific required to reproduce?

It probably needs a non-lo device to show up, see the thread at

 https://lists.debian.org/debian-devel/2020/07/msg00070.html

-- 
Niko Tyni   nt...@debian.org

Bug#982580: netty: CVE-2021-21290

[Salvatore Bonaccorso]

Source: netty
Version: 1:4.1.48-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1:4.1.33-1+deb10u1
Control: found -1 1:4.1.33-1

Hi,

The following vulnerability was published for netty.

CVE-2021-21290[0]:
| Netty is an open-source, asynchronous event-driven network application
| framework for rapid development of maintainable high performance
| protocol servers  clients. In Netty before version 4.1.59.Final
| there is a vulnerability on Unix-like systems involving an insecure
| temp file. When netty's multipart decoders are used local information
| disclosure can occur via the local system temporary directory if
| temporary storing uploads on the disk is enabled. On unix-like
| systems, the temporary directory is shared between all user. As such,
| writing to this directory using APIs that do not explicitly set the
| file/directory permissions can lead to information disclosure. Of
| note, this does not impact modern MacOS Operating Systems. The method
| "File.createTempFile" on unix-like systems creates a random file, but,
| by default will create this file with the permissions "-rw-r--r--".
| Thus, if sensitive information is written to this file, other local
| users can read this information. This is the case in netty's
| "AbstractDiskHttpData" is vulnerable. This has been fixed in version
| 4.1.59.Final. As a workaround, one may specify your own
| "java.io.tmpdir" when you start the JVM or use
| "DefaultHttpDataFactory.setBaseDir(...)" to set the directory to
| something that is only readable by the current user.


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-21290
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21290
[1] https://github.com/netty/netty/security/advisories/GHSA-5mcr-gq6c-3hq2
[2] 
https://github.com/netty/netty/commit/c735357bf29d07856ad171c6611a2e1a0eec

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#982579: Failed to load firmware brcmfmac43430-sdio at BananaPi M2

[Bernhard]

Package: firmware-brcm80211
Version: 20201218-3

Hello,

At my BananaPi M2 Ultra, loading firmware failed:

> [   10.514530] brcmfmac mmc2:0001:1: firmware: direct-loading firmware 
> brcm/brcmfmac43430-sdio.bin
> [   10.514732] brcmfmac mmc2:0001:1: firmware: failed to load 
> brcm/brcmfmac43430-sdio.sinovoip,bpi-m2-ultra.txt (
> -2)
> [   10.525149] firmware_class: See https://wiki.debian.org/Firmware for 
> information about missing firmware
> [   10.534664] brcmfmac mmc2:0001:1: Direct firmware load for 
> brcm/brcmfmac43430-sdio.sinovoip,bpi-m2-ultra.txt f
> ailed with error -2
> [   10.551207] brcmfmac mmc2:0001:1: firmware: failed to load 
> brcm/brcmfmac43430-sdio.txt (-2)
> [   10.559692] brcmfmac mmc2:0001:1: Direct firmware load for 
> brcm/brcmfmac43430-sdio.txt failed with error -2
> 

Please add the corresponding firmware.

Best regards and thank you for the great support.
Bernhard



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

Bug#982578: stunnel4: CVE-2021-20230: client certificate not correctly verified when redirect and verifyChain options are used

[Salvatore Bonaccorso]

Source: stunnel4
Version: 3:5.56+dfsg-6
Severity: grave
Tags: patch security upstream fixed-upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for stunnel4.

CVE-2021-20230[0]:
| client certificate not correctly verified when redirect and
| verifyChain options are used

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-20230
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-20230
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1925226
[2] https://bugzilla.suse.com/show_bug.cgi?id=1177580

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#982435: [screen-devel] [bug #60030] Screen segfaults by displaying some UTF-8 character combination

[Salvatore Bonaccorso]

Hi Axel,

[dropping upstream lists and other people, + team@s.d.o]

On Thu, Feb 11, 2021 at 11:39:09PM +0100, Axel Beckert wrote:
[...]
> Salvatore, Utkarsh: Will also prepare and test at least patches in Git
> for Buster and Stretch. (Hey, I don't want my mutt screen sessions to
> be killed anymore when reading this thread. ;-) We should then
> probably coordinate 1:1 who does the according stable-security and LTS
> uploads.

Thanks for all your coordinaton, investigation, work on this!

Sounds good. I propose to have the potential final patch as well first
slightly exposed first in unstable for a couple of days (2-3)? to see
if anybody reports any further problems and only then release an
update in buster, stretch. 

Regards,
Salvatore

Bug#982577: ITP: geventhttpclient -- http client library for gevent

[Sandro Tosi]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org
X-Debbugs-Cc: debian-pyt...@lists.debian.org
Owner: Sandro Tosi 

* Package name: geventhttpclient
  Version : 1.4.5
  Upstream Author : Antonin Amand 
* URL : http://github.com/gwik/geventhttpclient
* License : LICENSE-MIT
  Programming Lang: Python
  Description : high performance, concurrent HTTP client library for Python 
using gevent

 geventhttpclient uses a fast http parser, written in C, originating from
 nginx, extracted and modified by Joyent.
 .
 geventhttpclient has been specifically designed for high concurrency,
 streaming and support HTTP 1.1 persistent connections. More generally it is
 designed for efficiently pulling from REST APIs and streaming APIs
 like Twitter's.
 .
 Safe SSL support is provided by default. geventhttpclient depends on
 the certifi CA Bundle. This is the same CA Bundle which ships with the
 Requests codebase, and is derived from Mozilla Firefox's canonical set.


this is a dependency of locust

Bug#982574: php does not compile with acl support

[Ondřej Surý]

Control: severity -1 wishlist

--
Ondřej Surý  (He/Him)

> On 12. 2. 2021, at 3:09, VenenuX GNU Linux  wrote:
> 
> Package: php7.4-fpm
> Version: 7.4.15-1
> Severity: serious
> 
> fpm fails to start due usage of "listen.acl_groups" or/and
> "listen.acl_users" ACL feature, available since php 5.6
> 
> So then it needs to be compiled with --with-fpm-acl (depends on
> libacl1-dev) for listen.acl_users directive to work.
> 
> My relatives try to use the acl feature under php fpm debian after
> failing. try to use the most recents sury repos and it is the same
> problem..
> 
> https://github.com/oerdnj/deb.sury.org/issues/948
> 
> But it is very interesting to note that inclusivelly when the
> intention on github issue is well explained by users.. i hope this
> time will not be an "works for me its upstream fault" response like in
> github!
> 
> here is the log when the issue is well appreciated:
> 
> Feb 11 19:21:21 isomaker systemd[1]: Starting The PHP 7.4 FastCGI
> Process Manager...
> Feb 11 19:21:21 isomaker php-fpm7.4[30704]: [11-Feb-2021 19:21:21]
> ERROR: [/etc/php/7.4/fpm/pool.d/www.conf:55] unknown entry
> 'listen.acl_groups'
> Feb 11 19:21:21 isomaker php-fpm7.4[30704]: [11-Feb-2021 19:21:21]
> ERROR: Unable to include /etc/php/7.4/fpm/pool.d/www.conf from
> /etc/php/7.4/fpm/php-fpm.conf at line 55
> Feb 11 19:21:21 isomaker php-fpm7.4[30704]: [11-Feb-2021 19:21:21]
> ERROR: failed to load configuration file
> '/etc/php/7.4/fpm/php-fpm.conf'
> Feb 11 19:21:21 isomaker php-fpm7.4[30704]: [11-Feb-2021 19:21:21]
> ERROR: FPM initialization failed
> Feb 11 19:21:21 isomaker systemd[1]: php7.4-fpm.service: Main process
> exited, code=exited, status=78/CONFIG
> Feb 11 19:21:21 isomaker systemd[1]: php7.4-fpm.service: Failed with
> result 'exit-code'.
> Feb 11 19:21:21 isomaker systemd[1]: Failed to start The PHP 7.4
> FastCGI Process Manager.
> Feb 11 19:21:51 isomaker systemd[1]: Starting The PHP 7.4 FastCGI
> Process Manager...
> Feb 11 19:21:51 isomaker systemd[1]: Started The PHP 7.4 FastCGI
> Process Manager.
> 

Bug#982534: liblemonldap-ng-portal-perl: Missing dependency to gsfonts breaks Captcha

[Yadd]

> Package: liblemonldap-ng-portal-perl
> Version: 2.0.0+ds-1
> Severity: normal
>
> Upstream bug:
> https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2459
>
>   "After complete install, captcha does not work. First, I have tons
>of warnings and after digging into the code, my conclusions are
>very similar to what can be found on
>https://github.com/burak/CPAN-GD-SecurityImage/issues/2;
>
> Buster workaround: install gsfonts
> Bullseye:  fixed in version 2.0.11+ds-2

I think this issue should be reassigned to libgd-securityimage-perl,
shouldn't it?

Bug#881740: avro-c: FTBFS on sparc64: bus errors in tests

[Faidon Liambotis]

Control: tags -1 patch

On Tue, Nov 14, 2017 at 11:39:44AM -0500, Aaron M. Ucko wrote:
> The build of avro-c for sparc64 (admittedly not a release
> architecture) failed as detailed in
> https://buildd.debian.org/status/fetch.php?pkg=avro-c=sparc64=1.8.2-1=1510615927=0:

I gave it a look, and found and fixed the memory alignment issues. I
submitted a patch upstream with the changes, cf. PR #1091¹. They're not
trivial, but they're not super complicated either.

With the commits in that PR, I managed to build the package successfuly
in the "kyoto" Debian porterbox, as well as on my amd64 laptop.

HTH!

Regards,
Faidon

1: https://github.com/apache/avro/pull/1091

Bug#981711: mc: cannot view .jar files any more

[Thorsten Glaser]

More on that test:

• Restoring /etc/mc/mc.ext from mc_4.8.25-1 (by copying
  it to ~/.config/mc/mc.ext) does NOT fix the bug.
  (Deleted it again for the next test.)

• Running /tmp/mc_4.8.25-1_x32-extracted/d/usr/bin/mc
  *does* fix the issue, so it must be something compiled
  into the mc binary.

HTH and please fix this for bullseye as I *rely* on this,
//mirabilos
-- 
 den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt…
oder netzteile, an die man auch den monitor angeschlossen hat und die dann für
ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder
LAN party │  damals, als der pizzateig noch auf dem monior "gegangen" ist

Bug#981711: mc: cannot view .jar files any more

[Thorsten Glaser]

Package: mc
Version: 3:4.8.26-1
Followup-For: Bug #981711
X-Debbugs-Cc: t...@mirbsd.de
Control: severity -1 important

I just did an a/b test on a sid system I had not yet upgraded.

The versions of relevant packages before the upgrade:

tglase@tglase:~ $ dpkg-query -W mc\*
mc  3:4.8.25-1
mc-data 3:4.8.25-1
[…]
tglase@tglase:~ $ dpkg-query -W file\* \*magic\*
file1:5.39-3
libmagic-mgc1:5.39-3
libmagic1:x32   1:5.39-3
[…]

No user extension file.

Then, the upgrade:

tglase@tglase:~ $ sudo apt-get install mc
Reading package lists... Done
Building dependency tree
Reading state information... Done
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
The following additional packages will be installed:
  mc-data
Suggested packages:
  dbview djvulibre-bin epub-utils gv libaspell-dev python python-boto python-tz 
unar wimtools
The following packages will be upgraded:
  mc mc-data
2 upgraded, 0 newly installed, 0 to remove and 509 not upgraded.
Need to get 1882 kB of archives.
After this operation, 12.3 kB disk space will be freed.
Do you want to continue? [Y/n]
Get:1 http://deb.debian.org/debian-ports unstable/main x32 mc x32 3:4.8.26-1 
[537 kB]
Get:2 http://deb.debian.org/debian sid/main i386 mc-data all 3:4.8.26-1 [1345 
kB]
Fetched 1882 kB in 2s (1137 kB/s)
[master c8e2f47] saving uncommitted changes in /etc prior to apt run
[…]
(Reading database ... 405823 files and directories currently installed.)
Preparing to unpack .../mc_3%3a4.8.26-1_x32.deb ...
Unpacking mc (3:4.8.26-1) over (3:4.8.25-1) ...
Preparing to unpack .../mc-data_3%3a4.8.26-1_all.deb ...
Unpacking mc-data (3:4.8.26-1) over (3:4.8.25-1) ...
Setting up mc-data (3:4.8.26-1) ...
Setting up mc (3:4.8.26-1) ...
Installing new version of config file /etc/mc/filehighlight.ini ...
Installing new version of config file /etc/mc/mc.default.keymap ...
Installing new version of config file /etc/mc/mc.emacs.keymap ...
Installing new version of config file /etc/mc/mc.ext ...
Processing triggers for man-db (2.9.3-2) ...
Processing triggers for mailcap (3.68) ...
Processing triggers for desktop-file-utils (0.26-1) ...
Processing triggers for hicolor-icon-theme (0.17-2) ...
Processing triggers for doc-base (0.11.1) ...
Processing 1 changed doc-base file...
[master faba577] committing changes in /etc made by "apt-get install mc"

And with this, it stops working.


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

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

Versions of packages mc depends on:
ii  libc6 2.31-9
ii  libext2fs21.45.6-1
ii  libglib2.0-0  2.66.4-2
ii  libgpm2   1.20.7-8
ii  libslang2 2.3.2-5
ii  libssh2-1 1.9.0-2
ii  mc-data   3:4.8.26-1

Versions of packages mc recommends:
ii  mime-support3.66
ii  perl5.32.0-6
ii  sensible-utils  0.0.14
ii  unzip   6.0-26

Versions of packages mc suggests:
ii  arj  3.10.22-24
ii  bzip21.0.8-4
pn  dbview   
pn  djvulibre-bin
pn  epub-utils   
ii  file 1:5.39-3
ii  genisoimage  9:1.1.11-3.1
pn  gv   
ii  imagemagick  8:6.9.11.58+dfsg-1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.58+dfsg-1
pn  libaspell-dev
ii  lynx 2.9.0dev.6-1
ii  mupdf [pdf-viewer]   1.17.0+ds1-1.2
ii  odt2txt  0.5-7
ii  okular [pdf-viewer]  4:20.12.1-1
ii  poppler-utils20.09.0-3.1
pn  python   
pn  python-boto  
pn  python-tz
ii  texlive-binaries 2020.20200327.54578-6
pn  unar 
pn  wimtools 
ii  zip  3.0-11

-- no debconf information

Bug#982299: Re. RTSP streams are not displayed with version 3.0.12 on Debian Sid

[wglxy]

Oh, that is a bad news. :(

Would you please tell me if you have any plan to rewrite some code to play RTSP 
stream again? It is a very fine function.


Best regards,
Gulfstream

Bug#982061: package-update-indicator throws GLib-ERROR and does not run

[Gökalp Çelik]

Great. It seems to be back to normal.

Awesome work debian devs.

On Fri, Feb 12, 2021 at 2:12 AM Unit 193  wrote:

> Howdy,
>
> I just tried the glib2.0 2.66.7-1 which was just uploaded and it fixed the
> problem for me.  Can you give it a try and see if you can confirm this?
>
>
> Thanks!
>
> ~Unit 193
> Unit193 @ freenode
> Unit193 @ OFTC
>
> On Sun, 7 Feb 2021, Gökalp Çelik wrote:
>
> > I tested with 2.66.4 package from bullseye and package-update-indicator
> came back however those older packages also suffer from a vulnerability
> that later
> > sid packages don't. So it seems that there is a problem with
> package-update-indicator implementation as well.
> >
> > On Sun, Feb 7, 2021 at 1:15 AM Unit 193  wrote:
> >   Howdy,
> >
> >   The exact error message seen is:
> > GLib-ERROR **: 17:08:39.264: ../../../glib/gmem.c:112: failed to
> allocate 93955162462643 bytes
> >
> >   This actually started happening with an update of glib2.0 to
> 2.66.6-1, though
> >   2.67.3-1 is also affected.  To work around such problem, I have
> downgraded the
> >   library to 2.66.5-1 which solved the issue for now.
> >
> >
> >   ~Unit 193
> >   Unit193 @ freenode
> >   Unit193 @ OFTC
> >
> >
> >
> > --
> > Gökalp Çelik
> > Biyoinformatik Hizmetleri
> > Intergen Genetik Hastalıklar Tanı Merkezi
> > [uc?id=13PckZnCcbyy6hUEAlkK1HhWiF33n9za0=download]
> > Tel:  +90 (312) 428 48 14  /  +90 (312) 428 36 90
> > Fax:  +90 (312) 428 26 93
> > Web: www.intergen.com.tr - @Mail: gokalpce...@intergen.com.tr
> >
> >

Bug#979840: dns-root-data: autopkgtest regression in testing: failed to query server 127.0.0.1@53

[Robert Edmonds]

severity 979840 minor
quit

Paul Gevers wrote:
> Source: dns-root-data
> Version: 2019052802
> X-Debbugs-CC: debian...@lists.debian.org
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: regression
> 
> Dear maintainer(s),
> 
> With a not so recent change (beginning 2020) somewhere outside your
> package the autopkgtest of your package started to fail. I copied some
> of the output at the bottom of this report. Can you please investigate
> the situation and fix it?
> 
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/d/dns-root-data/9516338/log.gz
> 
> autopkgtest [17:42:10]: test baseline: [---
> ;; WARNING: response timeout for 127.0.0.1@53(UDP)
> ;; WARNING: response timeout for 127.0.0.1@53(UDP)
> ;; WARNING: response timeout for 127.0.0.1@53(UDP)
> ;; ERROR: failed to query server 127.0.0.1@53(UDP)
> autopkgtest [17:42:25]: test baseline: ---]

Hi,

I have investigated this report. The purpose of the dns-root-data
package is to ship, as static content, the list of IANA DNS root
nameserver IP addresses, and the IANA DNSSEC root zone trust anchor.
According to
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation:

It can be appropriate to file an RC bug against the depended-on
package, if the regression amounts to an RC bug in the depending
package, and to keep it open while the matter is investigated. That
will prevent migration of an RC regression.

I have confirmed that the current version of the package (2019052802) is
shipping the correct root nameserver hints and root zone trust anchor
content and that no RC regression exists, so I am lowering the severity
of this bug report.

The problem seems to be that the test depends on the Knot Resolver's
kresd daemon, whose service unit is masked and is not started after
installing the knot-resolver package. I would guess something like the
following would fix the regression in the test:

--- dns-root-data-2019052802/debian/tests/baseline.orig 2021-02-11 
22:08:17.857773156 -0500
+++ dns-root-data-2019052802/debian/tests/baseline  2021-02-11 
22:13:28.483653604 -0500
@@ -2,6 +2,9 @@
 
 set -e
 
-kdig @127.0.0.1 -t ns . +dnssec > root-nameservers-result
+kresd --noninteractive --addr=127.53.53.53@53053 &
+
+kdig -p 53053 @127.53.53.53 -t ns . +dnssec > root-nameservers-result
 cat root-nameservers-result
 head -n1 < root-nameservers-result | grep -q '^;; ->>HEADER<<- opcode: QUERY; 
status: NOERROR; id: '
+head -n2 < root-nameservers-result | tail -1 | grep -q '^;; Flags: qr rd ra 
ad;'

-- 
Robert Edmonds
edmo...@debian.org

Bug#982576: "list ruleset" triggers core dump, leaves host unprotected

[Trent W. Buck]

Package: nftables
Version: 0.9.8-3
Severity: normal

NOTE: to easily test a nft firewall in isolation, create a dummy netns:

sudo ip netns add test
sudo ip netns exec test  nft --file test.nft

This minimal ruleset causes a core dump:

#!/usr/sbin/nft --file
# This is like "flush ruleset" except only flushes THIS ruleset, not ALL 
rulesets.
# In particular, it leaves the dynamic sshguard/fail2ban deny lists 
untouched.
add table A# idempotent
delete table A # not idempotent
table A {
chain B {
tcp dport {1,2}  accept
}
}
list ruleset

Commenting out "list ruleset" prevents the core dump.
Having done so, a subsequent "nft list ruleset" works fine.

Putting "list ruleset" at the bottom of the ruleset routinely prints
wrong output (see below), but this is the first time I've seen it
disable the entire firewall!

On buster-backports (nftables 0.9.6-1~bpo10+1),
the same ruleset does NOT trigger a segfault.
Instead it prints this output:

table ip A {
}

And a subsequent call to "nft list ruleset" prints this output:

table ip A {
chain B {
tcp dport { 1, 2 } accept
}
}

The core dump looks like this (sorry, I don't have -dbg set up):

cyber@light:~$ sudo coredumpctl  info 9427
   PID: 9427 (nft)
   UID: 0 (root)
   GID: 0 (root)
Signal: 11 (SEGV)
 Timestamp: Fri 2021-02-12 14:00:58 AEDT (4min 4s ago)
  Command Line: nft -f -
Executable: /usr/sbin/nft
 Control Group: /user.slice/user-0.slice/session-15.scope
  Unit: session-15.scope
 Slice: user-0.slice
   Session: 15
 Owner UID: 0 (root)
   Boot ID: 9307dbd17f1e4dd99fda1b1eda36576e
Machine ID: d18f6dfeb20d4f4ca40a61f4553e9c27
  Hostname: light
   Storage: 
/var/lib/systemd/coredump/core.nft.0.9307dbd17f1e4dd99fda1b1eda36576e.9427.161309885800.zst
   Message: Process 9427 (nft) of user 0 dumped core.

Stack trace of thread 9427:
#0  0x7fc038d1b85c n/a (libnftables.so.1 + 0x2485c)
#1  0x7fc038d116d2 n/a (libnftables.so.1 + 0x1a6d2)
#2  0x7fc038d13097 n/a (libnftables.so.1 + 0x1c097)
#3  0x7fc038d13bf7 n/a (libnftables.so.1 + 0x1cbf7)
#4  0x7fc038d451ef n/a (libnftables.so.1 + 0x4e1ef)
#5  0x7fc038d45e18 nft_run_cmd_from_filename 
(libnftables.so.1 + 0x4ee18)
#6  0x55a94b6859f6 n/a (nft + 0x29f6)
#7  0x7fc038b1fd0a __libc_start_main (libc.so.6 + 
0x26d0a)
#8  0x55a94b685a8a n/a (nft + 0x2a8a)

Bug#982546: additional information

[Felix C. Stegerman]

* "Felix C. Stegerman"  [2021-02-11 18:09]:
> I forgot to mention that I first tried removing the 
> 
>   handle->id_product == SCM_SPR532
> 
> check in ccid_vendor_specific_setup(), but that didn't work.

Which makes sense since SCM_SPR532 and SCM_SPR332 apparently have the
same product id.

I've attached an improved patch.

- Felix
--- gnupg2-2.2.27.orig/scd/ccid-driver.c
+++ gnupg2-2.2.27/scd/ccid-driver.c
@@ -1304,10 +1304,20 @@
 {
   if (handle->id_vendor == VENDOR_SCM && handle->id_product == SCM_SPR532)
 {
+  libusb_clear_halt (handle->idev, handle->ep_intr);
+}
+  return 0;
+}
+
+
+static int
+ccid_vendor_specific_transceive_setup (ccid_driver_t handle)
+{
+  if (handle->id_vendor == VENDOR_SCM && handle->id_product == SCM_SPR532)
+{
   DEBUGOUT ("sending escape sequence to switch to a case 1 APDU\n");
   send_escape_cmd (handle, (const unsigned char*)"\x80\x02\x00", 3,
NULL, 0, NULL);
-  libusb_clear_halt (handle->idev, handle->ep_intr);
 }
   return 0;
 }
@@ -3583,6 +3593,8 @@
   if (pininfo->fixedlen < 0 || pininfo->fixedlen >= 16)
 return CCID_DRIVER_ERR_NOT_SUPPORTED;
 
+  ccid_vendor_specific_transceive_setup (handle);
+
   msg = send_buffer;
   msg[0] = cherry_mode? 0x89 : PC_to_RDR_Secure;
   msg[5] = 0; /* slot */

Bug#981823: librust-alacritty-terminal-dev is not installable

[James McCoy]

On Thu, Feb 04, 2021 at 01:23:33PM +0200, Adrian Bunk wrote:
> The following packages have unmet dependencies:
>  librust-alacritty-terminal-dev : Depends: librust-terminfo-0.7+default-dev 
> (>= 0.7.1-~~) but it is not installable
>   Depends: librust-vte-0.8-dev but it is not 
> installable

The initial upload of rust-terminfo was REJECTed.  I believe the issues
have been addressed, but not uploaded, since then.  However, newer
versions of rust-alacritty-terminal no longer use rust-terminfo.

Since rust-alacritty-terminal is just part of the stack needed to get
alacritty packaged, I'll update it along with the rest of the work once
Bullseye is released.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#982575: ncmpc: fails with "unknown tag type" when talking to older mpd servers

[Daniel Kahn Gillmor]

Package: ncmpc
Version: 0.43-1
Tags: patch
Severity: important
Control: forwarded -1 https://github.com/MusicPlayerDaemon/ncmpc/issues/93

After upgrading to 0.43-1 on debian testing/unstable, ncmpc no longer
offers a useful connection to my mpd server, instead showing Unknown tag
type in red.

This makes ncmpc completely unusable for me, as I cannot reach the
playlist, the file browser, or even adjust the volume.

the server in question is running mpd version 0.21.5-3 (from debian stable)

Other mpd clients (like mpc version 0.33-1, and an Android mpd client)
continue to work fine with the same server.

Upstream offered the attached patch, which I've tested locally; it
resolves the problem for me.  It (or an even better fix) will probably
be part of 0.45 whenever upstream gets around to releasing that version.

Regards,

--dkg

From: Max Kellermann 
Date: Thu, 11 Feb 2021 21:44:15 +0100
Subject: mpdclient: make "tagtypes" errors non-fatal

This makes ncmpc usable even if applying the tag mask fails (for
whatever reason).

This fixes https://github.com/MusicPlayerDaemon/ncmpc/issues/93 (but a
better fix will follow).

(cherry picked from commit 7ce348cd21862e1f6b8228acbbff1a7df4df90d7)
---
 src/mpdclient.cxx | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/mpdclient.cxx b/src/mpdclient.cxx
index cc04743..b6e6ba2 100644
--- a/src/mpdclient.cxx
+++ b/src/mpdclient.cxx
@@ -331,9 +331,12 @@ mpdclient::OnConnected(struct mpd_connection *_connection) noexcept
 	mpd_connection_cmp_server_version(connection, 0, 21, 0) >= 0 &&
 	!SendTagWhitelist(connection, tag_whitelist)) {
 		InvokeErrorCallback();
-		Disconnect();
-		mpdclient_failed_callback();
-		return false;
+
+		if (!mpd_connection_clear_error(connection)) {
+			Disconnect();
+			mpdclient_failed_callback();
+			return false;
+		}
 	}
 #endif
 


signature.asc
Description: PGP signature

Bug#981426: RM: cu2qu -- ROM; merged to fonttools

[Yao Wei]

Hi,

Sorry that I didn't check the rdeps of cu2qu but only build-rdeps of it.

On Fri, Feb 12, 2021 at 08:14:39AM +0900, Hideki Yamane wrote:
> Hi Paul,
> 
> On Thu, 11 Feb 2021 21:32:54 +0100
> Paul Gevers  wrote:
> > So, Yao, what's the way forward for python3-fontmake and python3-ufo2ft?
> > Will fonttools provide python3-cu2qu?

fonttools will provide same functionality of cu2qu but it will be under
fonttools package.

>  And Yao, please push your changes for ufo2ft to salsa repo.

Done!  I forgot to push branch again :/

Thank,
Yao Wei


signature.asc
Description: PGP signature

Bug#982574: php does not compile with acl support

[VenenuX GNU Linux]

Package: php7.4-fpm
Version: 7.4.15-1
Severity: serious

fpm fails to start due usage of "listen.acl_groups" or/and
"listen.acl_users" ACL feature, available since php 5.6

So then it needs to be compiled with --with-fpm-acl (depends on
libacl1-dev) for listen.acl_users directive to work.

My relatives try to use the acl feature under php fpm debian after
failing. try to use the most recents sury repos and it is the same
problem..

https://github.com/oerdnj/deb.sury.org/issues/948

But it is very interesting to note that inclusivelly when the
intention on github issue is well explained by users.. i hope this
time will not be an "works for me its upstream fault" response like in
github!

here is the log when the issue is well appreciated:

Feb 11 19:21:21 isomaker systemd[1]: Starting The PHP 7.4 FastCGI
Process Manager...
Feb 11 19:21:21 isomaker php-fpm7.4[30704]: [11-Feb-2021 19:21:21]
ERROR: [/etc/php/7.4/fpm/pool.d/www.conf:55] unknown entry
'listen.acl_groups'
Feb 11 19:21:21 isomaker php-fpm7.4[30704]: [11-Feb-2021 19:21:21]
ERROR: Unable to include /etc/php/7.4/fpm/pool.d/www.conf from
/etc/php/7.4/fpm/php-fpm.conf at line 55
Feb 11 19:21:21 isomaker php-fpm7.4[30704]: [11-Feb-2021 19:21:21]
ERROR: failed to load configuration file
'/etc/php/7.4/fpm/php-fpm.conf'
Feb 11 19:21:21 isomaker php-fpm7.4[30704]: [11-Feb-2021 19:21:21]
ERROR: FPM initialization failed
Feb 11 19:21:21 isomaker systemd[1]: php7.4-fpm.service: Main process
exited, code=exited, status=78/CONFIG
Feb 11 19:21:21 isomaker systemd[1]: php7.4-fpm.service: Failed with
result 'exit-code'.
Feb 11 19:21:21 isomaker systemd[1]: Failed to start The PHP 7.4
FastCGI Process Manager.
Feb 11 19:21:51 isomaker systemd[1]: Starting The PHP 7.4 FastCGI
Process Manager...
Feb 11 19:21:51 isomaker systemd[1]: Started The PHP 7.4 FastCGI
Process Manager.

Bug#962459: unbound: constantly crashing after about 3 minutes since start

[Robert Edmonds]

Kebert Martin wrote:
> Applied '0001-Apply-a-series-of-fixes-for-Unbound-1.9.0-suggested-.patch' 
> 
> Result:
> Oct 28 20:24:28 debian systemd[1]: Starting Unbound DNS server...
> Oct 28 20:24:28 debian package-helper[464]: /var/lib/unbound/root.key has
> content
> Oct 28 20:24:28 debian package-helper[464]: fail: the anchor is NOT ok and
> could not be fixed
> Oct 28 20:24:28 debian unbound[468]: [468:0] notice: init module 0: subnet
> Oct 28 20:24:28 debian unbound[468]: [468:0] notice: init module 1: validator
> Oct 28 20:24:28 debian unbound[468]: [468:0] notice: init module 2: iterator
> Oct 28 20:24:28 debian systemd[1]: Started Unbound DNS server.
> Oct 28 20:24:28 debian unbound[468]: [468:0] info: start of service (unbound
> 1.9.0).
> ...
> Oct 28 20:31:31 debian kernel: unbound[470]: segfault at 1b0 ip
> 7fdb28876e48 sp 7fdb26fd6cf0 error 4 in libevent-2.1.so.6.0.2
> [7fdb28857000+54000]
> [...]

Hi, Kebert:

Thanks for checking that. Sorry it didn't work, and apologies for the
delay in getting back to you.

We're now looking into the possibility of updating the version of
unbound in buster to a newer upstream release that most likely already
includes the right combination of fixes for this issue, rather than
trying to backport the right set of fixes needed to the 1.9.0 release.

If you have an opportunity, could you give the candidate unbound package
available here a try?

https://people.debian.org/~edmonds/unbound/1.9.6-0+deb10u0/

Thanks!

-- 
Robert Edmonds
edmo...@debian.org

Bug#982573: apt-listbugs: When declining package-installation, apt-listbugs crashes

[c01d]

Package: apt-listbugs
Version: 0.1.35
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   
I wanted to install pinta from sid, got warned about a bug. I declined package 
installation. apt-listbugs then told:


Retrieving bug reports... Done
Parsing Found/Fixed information... Done
grave bugs of pinta (→ 1.6-2) 
 b1 - #877106 - pinta: Pinta 1.6-2 crashes on image scaling and other image 
manipulation.
Summary:
 pinta(1 bug)
Are you sure you want to install/upgrade the above packages? [Y/n/?/...] n
**
** Exiting with an error in order to stop the installation. **
**
E: Sub-process /usr/bin/apt-listbugs apt returned an error code (10)
E: Failure running script /usr/bin/apt-listbugs apt
B
B

B
B


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

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


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

Kernel: Linux 4.19.0-13-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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

Versions of packages apt-listbugs depends on:
ii  apt 2.1.20
ii  ruby1:2.7+2
ii  ruby-debian 0.3.10+b4
ii  ruby-gettext3.3.3-2
ii  ruby-soap4r 2.0.5-5
ii  ruby-unicode0.4.4.4-1+b1
ii  ruby-xmlparser  0.7.3-4

Versions of packages apt-listbugs recommends:
ii  ruby-httpclient  2.8.3-2

Versions of packages apt-listbugs suggests:
ii  chromium [www-browser] 88.0.4324.150-1
ii  firefox [www-browser]  85.0.1-1
ii  firefox-esr [www-browser]  78.7.0esr-1
ii  hv3 [www-browser]  3.0~fossil20110109-8
ii  konqueror [www-browser]4:20.12.0-4
ii  reportbug  7.10.2
ii  sensible-utils 0.0.14
ii  surf [www-browser] 2.0+git20201107-1
ii  xdg-utils  1.1.3-4

-- no debconf information

Bug#982562: general: Storing upstream signatures next to upstream tarballs is problematic

[Guillem Jover]

On Fri, 2021-02-12 at 01:05:21 +0100, Mattia Rizzolo wrote:
> On Fri, 12 Feb 2021, 12:52 am Guillem Jover,  wrote:
> > Then there's the problem with changing contents for already seen
> > files, which seems like a dak bug. It does not allow to change a
> > tarball once it has been seen, so I don't see why it should allow a
> > changed .asc either?
> 
> That's not true.
> 
> Call it a dak bug or a feature, depending on where you stand.  Dak forgets
> everything concerning a file as soon as it's not present in any suite it
> manages.
> This usually appears in the way of people uploading a package with the same
> name and version of something that was removed long long ago and since then
> archived and forgotten by dak.

Ah, sorry, right, that dak forgetfulness problem which seems
contagious. :)

Ok, so then these seems like two bugs in dak. dak sees the .asc, then
they disappear and it forgets them, and then files with different
content can then be uploaded. While ideally dak would never forget,
the problem here is that dak allows uploads that drop the .asc files,
no?

Thanks,
Guillem

Bug#971129: shim-signed: FTBFS: build-dependency not installable: shim-unsigned (= 15+1533136590.3beb971-7)

[Steve McIntyre]

Hey Ivo,

On Tue, Feb 09, 2021 at 04:26:02PM +0100, Ivo De Decker wrote:
>Hi Steve,
>
>On Sun, Sep 27, 2020 at 08:39:53PM +0200, Lucas Nussbaum wrote:
>> During a rebuild of all packages in sid, your package failed to build
>> on amd64.
>
>[...]
>
>> > The following packages have unmet dependencies:
>> >  sbuild-build-depends-main-dummy : Depends: shim-unsigned (= 
>> > 15+1533136590.3beb971-7) but it is not going to be installed
>
>What is the status of shim(-signed) for bullseye?
>
>shim-unsigned has been changed, but there is no corresponding shim-signed
>(yet). I assume a new signature from microsoft is needed. Or are there more
>changes to shim-unsigned needed first?

There are some other changes coming, not least switching compiler to
gcc-10 now we've stabilised. I'm working on new shim uploads at the
moment, but there's a couple of upstream patches we'll need to take as
well yet I think. It'll be coming soon, I promise.

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

Bug#953530: Downstream bug LP: #1886114

[Bryce Harrington]

Fwiw, ubuntu reporters have hit this issue as well:

  https://bugs.launchpad.net/debian/+source/samba/+bug/1886114

We've not yet reproduced the error about /run/samba, but I found one way
to make it fail to get into an installation failure state:

$ sudo apt-get install samba
$ sudo apt-get remove --purge samba-common-bin
$ sudo rm -rf /run/samba
$ sudo rm -rf /etc/samba
$ sudo apt-get install samba-common-bin
Reading package lists... Done
...
Setting up samba-common-bin (2:4.13.3+dfsg-1ubuntu2) ...
Checking smb.conf with testparm
Load smb config files from /etc/samba/smb.conf
Error loading services.
dpkg: error processing package samba-common-bin (--configure):
 installed samba-common-bin package post-installation script subprocess 
returned error exit status 1

After this it will continue to exhibit error messages similar to what
other reporters have seen.

To restore the system back to working order, this seems to do it:

$ sudo apt-get remove --purge *samba*
$ sudo apt-get install samba

I tried tampering with and removing /run/samba at various points, and
tinkering with /usr/lib/tmpfiles.d/samba.conf in various ways, but
wasn't able to generate the "lock directory /run/samba does not exist"
issue.

I also tested the above with 2:4.11.6+dfsg-0ubuntu1.6, and found it
gives identical behavior as above.

Bug#968843: RFH: asciio -- dynamically create ASCII charts and graphs with GTK+2

[Nick Black]

ok, i took a closer look at things, and realize you don't need a
new *backend*, but a new *gui frontend*. alas, my suggestion
would be of no help in this case. good luck finding a new
upstream author! =]

Bug#982560: epiphany-browser: default install on fresh debian prints warning messages

[Jay]

Package: epiphany-browser
Version: 3.32.1.2-3~deb10u1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

start browser using cli

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?



warning messages printed in stdout:

** (epiphany:2161): WARNING **: 15:39:37.525:
webkit_web_context_set_web_process_count_limit is deprecated and does nothing.
Limiting the number of web processes is no longer possible for security reasons

** (epiphany:2161): WARNING **: 15:39:37.526: Registering special URI scheme
ftp is no longer allowed



   * What outcome did you expect instead?

i do not expect warning messages on fresh default debian install

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



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

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

Versions of packages epiphany-browser depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-0+deb10u1
ii  dbus-x11 [dbus-session-bus]   1.12.20-0+deb10u1
ii  epiphany-browser-data 3.32.1.2-3~deb10u1
ii  gsettings-desktop-schemas 3.28.1-1
ii  iso-codes 4.2-1
ii  libc6 2.28-10
ii  libcairo2 1.16.0-4+deb10u1
ii  libgcr-base-3-1   3.28.1-1
ii  libgcr-ui-3-1 3.28.1-1
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-2+deb10u2
ii  libgmp10  2:6.1.2+dfsg-4
ii  libgtk-3-03.24.5-1
ii  libhogweed4   3.4.1-1
ii  libicu63  63.1-6+deb10u1
ii  libjavascriptcoregtk-4.0-18   2.30.4-1~deb10u1
ii  libjson-glib-1.0-01.4.4-2
ii  libnettle63.4.1-1
ii  libnotify40.7.7-4
ii  libpango-1.0-01.42.4-8~deb10u1
ii  libsecret-1-0 0.18.7-1
ii  libsoup2.4-1  2.64.2-2
ii  libsqlite3-0  3.27.2-3+deb10u1
ii  libwebkit2gtk-4.0-37  2.30.4-1~deb10u1
ii  libxml2   2.9.4+dfsg1-7+deb10u1

Versions of packages epiphany-browser recommends:
ii  ca-certificates  20200601~deb10u2
ii  evince   3.30.2-3+deb10u1
ii  yelp 3.31.90-1

epiphany-browser suggests no packages.

-- no debconf information

Bug#982572: gnome-shell: gnome freezes when dragging windows between displays

[Russell Stuart]

Package: gnome-shell
Version: 3.38.3-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

gnome 100% reliably dies when dragging a window between displays under
the following circumstances:

1.  The two displays have different resolutions, one hi-dpi, one not.

2.  You are dragging from the lo-dpi display to the hi-dpi display.

As you drag to the hi-dpi display, the resolution changes and
the window is rescaled accoringly.  The freeze happens when the
window is partially on the hi-dpi display, and partially on the
lo-dpi display.  On my laptop, the rescale doubles the size of
the window in pixels.

3.  If the rescaled window no longer fits on the lo-dpi display,
gnome-shell reliably freezes.

Here "freeze" means it no longer responds to the mouse and keyboard,
Ctl-Alt-F1 and friends don't work, and pressing the power button has no
effect.  It could be a kernel crash - but there is no indication of it
in the logs.



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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  evolution-data-server3.38.3-1
ii  gir1.2-accountsservice-1.0   0.6.55-3
ii  gir1.2-atspi-2.0 2.38.0-2
ii  gir1.2-freedesktop   1.66.1-1+b1
ii  gir1.2-gcr-3 3.38.1-2
ii  gir1.2-gdesktopenums-3.0 3.38.0-2
ii  gir1.2-gdm-1.0   3.38.2.1-1
ii  gir1.2-geoclue-2.0   2.5.7-2
ii  gir1.2-glib-2.0  1.66.1-1+b1
ii  gir1.2-gnomebluetooth-1.03.34.3-2
ii  gir1.2-gnomedesktop-3.0  3.38.3-1
ii  gir1.2-gstreamer-1.0 1.18.3-1
ii  gir1.2-gtk-3.0   3.24.24-1
ii  gir1.2-gweather-3.0  3.36.1-1
ii  gir1.2-ibus-1.0  1.5.23-2
ii  gir1.2-mutter-7  3.38.3-2
ii  gir1.2-nm-1.01.28.0-2+b1
ii  gir1.2-nma-1.0   1.8.30-1
ii  gir1.2-pango-1.0 1.46.2-3
ii  gir1.2-polkit-1.00.105-30
ii  gir1.2-rsvg-2.0  2.50.3+dfsg-1
ii  gir1.2-soup-2.4  2.72.0-2
ii  gir1.2-upowerglib-1.00.99.11-2
ii  gjs  1.66.2-1
ii  gnome-backgrounds3.38.0-1
ii  gnome-settings-daemon3.38.1-3
ii  gnome-shell-common   3.38.3-2
ii  gsettings-desktop-schemas3.38.0-2
ii  gstreamer1.0-pipewire0.3.19-3
ii  libatk-bridge2.0-0   2.38.0-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-9
ii  libcairo21.16.0-5
ii  libecal-2.0-13.38.3-1
ii  libedataserver-1.2-253.38.3-1
ii  libgcr-base-3-1  3.38.1-2
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libgirepository-1.0-11.66.1-1+b1
ii  libgjs0g 1.66.2-1
ii  libgles2 1.3.2-1
ii  libglib2.0-0 2.66.6-1
ii  libglib2.0-bin   2.66.6-1
ii  libgnome-autoar-0-0  0.2.4-2
ii  libgnome-desktop-3-193.38.3-1
ii  libgraphene-1.0-01.10.2-1
ii  libgtk-3-0   3.24.24-1
ii  libical3 3.0.9-2
ii  libjson-glib-1.0-0   1.6.0-3
ii  libmutter-7-03.38.3-2
ii  libnm0   1.28.0-2+b1
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpolkit-agent-1-0  0.105-30
ii  libpolkit-gobject-1-00.105-30
ii  libpulse-mainloop-glib0  14.1-1
ii  libpulse014.1-1
ii  libsecret-1-00.20.4-2
ii  libsystemd0  247.3-1
ii  libwayland-server0   1.18.0-2~exp1.1
ii  libx11-6 2:1.7.0-2
ii  libxfixes3  

Bug#982571: buster-pu: package gdnsd/2.4.3-1

[Faidon Liambotis]

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

Hi there,

This is a buster proposed update to fix CVE-2019-13952 aka #932407. This
is an old and really minor vulnerability, which I honestly had forgotten
about. It's easy and thus still good to fix.

I've packaged this as 2.4.3-1 (from 2.4.2-1). While technically a new
upstream release, it was released solely to contain this (two-line) fix,
with no other changes, as you can also see below. 2.4.3-1 never existed
in unstable either (it went to 3.5.0-1 directly), so it should be safe
for upgrades as well. Hope that's OK!

Diff below. Thank you for your consideration!

Regards,
Faidon


diff --git a/NEWS b/NEWS
index 152edad..33019fb 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,8 @@
+2.4.3 - 2019-07-19
+* Fix CVE-2019-13952: IPv6 addresses in local zone file data which are
+  longer than the maximum legitimate IPv6 address cause a stack buffer
+  overflow and crash.
+
 2.4.2 - 2019-02-11
 * FreeBSD: Fix EADDRNOTAVAIL issue for IPv6 sockets when the listening IP
   is bound to the loopback and traffic is routed indirectly, by resetting
diff --git a/configure.ac b/configure.ac
index 3ce9ee8..539ddec 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
 AC_PREREQ([2.63])
-AC_INIT([gdnsd],[2.4.2],[https://github.com/gdnsd/gdnsd/issues])
+AC_INIT([gdnsd],[2.4.3],[https://github.com/gdnsd/gdnsd/issues])
 AC_CONFIG_SRCDIR([src/main.c])
 AC_CONFIG_AUX_DIR([acaux])
 AM_INIT_AUTOMAKE([1.11.1 dist-xz no-dist-gzip foreign tar-ustar subdir-objects 
-Wall])
diff --git a/debian/changelog b/debian/changelog
index e4ec3c9..6cb188f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+gdnsd (2.4.3-1) buster; urgency=medium
+
+  * Fix CVE-2019-13952: IPv6 addresses in local zone file data which are
+longer than the maximum legitimate IPv6 address cause a stack buffer
+overflow and crash. (Closes: #932407)
+
+ -- Faidon Liambotis   Thu, 11 Feb 2021 23:58:20 +0200
+
 gdnsd (2.4.2-1) unstable; urgency=medium
 
   * New upstream point release.
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 81b6d6d..e4bff86 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,6 +1,6 @@
 [DEFAULT]
 upstream-tree=tag
-debian-branch=debian
+debian-branch=debian/buster
 upstream-tag = v%(version)s
 no-create-orig = True
 compression = xz
diff --git a/src/zscan_rfc1035.rl b/src/zscan_rfc1035.rl
index ad230c6..7be5ee5 100644
--- a/src/zscan_rfc1035.rl
+++ b/src/zscan_rfc1035.rl
@@ -111,6 +111,8 @@ F_NONNULL
 static void set_ipv6(zscan_t* z, const char* end) {
 char txt[INET6_ADDRSTRLEN + 1];
 unsigned len = end - z->tstart;
+if (len > INET6_ADDRSTRLEN)
+parse_error_noargs("IPv6 address unparseable (too long)");
 memcpy(txt, z->tstart, len);
 txt[len] = 0;
 z->tstart = NULL;

Bug#982570: octavia: [INTL:pt] Portuguese translation - debconf messages

[Américo Monteiro]

Package: octavia
Version: 7.1.0-1
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for octavia's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


octavia_7.1.0-1_pt.po.gz
Description: application/gzip

Bug#982562: general: Storing upstream signatures next to upstream tarballs is problematic

[Mattia Rizzolo]

On Fri, 12 Feb 2021, 12:52 am Guillem Jover,  wrote:

> Then there's the problem with changing contents for already seen
> files, which seems like a dak bug. It does not allow to change a
> tarball once it has been seen, so I don't see why it should allow a
> changed .asc either?
>

That's not true.

Call it a dak bug or a feature, depending on where you stand.  Dak forgets
everything concerning a file as soon as it's not present in any suite it
manages.
This usually appears in the way of people uploading a package with the same
name and version of something that was removed long long ago and since then
archived and forgotten by dak.


It's totally possible to overwrite a tarball with the same filename too
that way, you just need to wait the appropriate amount of time and upload
things in a way that you replace the upstream tarball.
(Honestly I haven't tried this myself, but I have a package where if you'd
like I can actually go and try to prove my point).


Back to the original bug report: I personally believe that the signatures
there are fine, and I don't believe in the "upstream the re-sign an already
released tarball" story.  But I consider the current forgetfulness of dak
as a bug.

Bug#982562: general: Storing upstream signatures next to upstream tarballs is problematic

[Guillem Jover]

Hi!

On Thu, 2021-02-11 at 21:59:42 +0100, Raphaël Hertzog wrote:
> Package: general
> Severity: normal
> User: de...@kali.org
> Usertags: origin-kali
> X-Debbugs-Cc: hert...@debian.org, debian-d...@lists.debian.org
> Control: affects -1 ftp.debian.org dpkg-dev

> After having been bitten (in Kali) by failures to import Debian packages
> because a PGP signature file has been modified [1], this lead me to think
> about this problem space and I concluded that the way we are storing
> such signatures is not appropriate.
> 
> Those files are not really meant to be immutable:
> - signing keys can expire and be revoked, upstream might want to update
>   signatures of already released tarballs

These files have similar properties and problems as our own .dsc, so
I don't see a huge difference here.

> - the set of "upstream release managers" might evolve over time and the
>   official signature to use might change...

If this changes I'd expect in most cases the signing-key.asc to get
out of date too, anyway.

> If we assume that the archive is meant to store immutable content
> under a given filename (and to me that requirement seems to be a good
> idea), then we should question ourselves whether we really want to store
> those signatures in a filename that's associated to the upstream version.
> They should either be tied to the Debian revision (so that they can change
> over time without any new upstream release) or be incorporated in the
> Debian tarball.

The upstream signatures are important to determine the provenance of
the source at the time of packaging, just like the signatures on .dsc,
both lose relevance once they hit an archive.

> After all the key to verify those signatures is already stored in the
> Debian tarball (when you use the uscan feature to verify those
> signatures), so why not store the signature there as well?

This looks messy, taking into account multi orig support for example.

> I originally filed this in https://bugs.debian.org/949962 against
> ftp.debian.org but the bug got closed because it's not really the
> responsibility of ftpmasters to change this. So I'm starting a wider
> discussion to gather feedback of all interested parties (at least
> Guillem as dpkg maintainer). I won't drive this much further but
> I wanted to have it properly recorded and considered.

This seems mostly a tooling problem TBH.

There's the accidental omissions part, which I also got bitten by at
the beginning, because the error mode was silent. This has since then
been incrementally improved, and now we have lintian warnings and
dpkg-source also warns (when upstream sig is missing but there's
upstream signing keys, and on the reverse too). I attempted to make
the former an error, but stuff was breaking so that had to be reverted
(see #963821). Ideally that would eventually be turned back into an
error, with an option to make it a warning.

Then there's the problem with changing contents for already seen
files, which seems like a dak bug. It does not allow to change a
tarball once it has been seen, so I don't see why it should allow a
changed .asc either?

Thanks,
Guillem

Bug#982569: virtuoso-opensource: [INTL:pt] Updated Portuguese translation - debconf messages

[Américo Monteiro]

Package: virtuoso-opensource
Version: 7.2.5.1+dfsg-3
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for virtuoso-opensource's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


virtuoso-opensource_7.2.5.1+dfsg-3_pt.po.gz
Description: application/gzip

Bug#982530: libpam-modules: unable to login when using pam_tally2 after upgrade to libpam-modules >1.4.0

[Sam Hartman]

Why wouldn't we just comment out the lines in the upgrade rather than
blocking the upgrade?

Bug#981426: RM: cu2qu -- ROM; merged to fonttools

[Hideki Yamane]

Hi Paul,

On Thu, 11 Feb 2021 21:32:54 +0100
Paul Gevers  wrote:
> So, Yao, what's the way forward for python3-fontmake and python3-ufo2ft?
> Will fonttools provide python3-cu2qu?

 I've done with python3-ufo2ft, and just now done for python3-fontmake :)
 

> > Date: Thu, 11 Feb 2021 14:49:37 +0900
> > Source: ufo2ft
> > Architecture: source
> > Version: 2.19.1-2
> > Distribution: unstable
> > Urgency: medium
> > Maintainer: Debian Fonts Task Force 
> > Changed-By: Hideki Yamane 
> > Changes:
> >  ufo2ft (2.19.1-2) unstable; urgency=medium
> >  .
> >* Team upload
> >  .
> >* debian/control
> >  - Set Build-Depends: python3-fonttools (>= 4.19.1) and drop 
> > python3-cu2qu
> >* debian/patches
> >  - Add cu2qu_moved_to_fonttools.patch for above change


 And Yao, please push your changes for ufo2ft to salsa repo.


-- 
Hideki Yamane 

Bug#982422: debootstrap: segmentation fault around ldconfig during debootstrapping bullseye/arm64 on a buster/amd64 host

[Josef Hahn]

Yes, indeed! Great! I've just tried with qemu-user-static from buster-
backports, and it seems to be fine.


On Thu, 2021-02-11 at 13:32 -0600, Dick Hollenbeck wrote:
> I upgraded to the latest qemu-user-static using a manual download of
> the *.deb from packages.ubuntu.com and installed
> using dpkg -i.
> 
> This fixed the problem.  So the bug must have been in qemu-user-
> static.
> 

Bug#982566: procps: Fails to install

[Craig Small]

Hi,
  Looks like I missed the epoch for manpages-pl. It Breaks/Replaces <<
4.9.1-2 but should be << 1:4.9.1-2

 - Craig


On Fri, 12 Feb 2021 at 09:48, Robert Luberda  wrote:

> Package: procps
> Version: 2:3.3.17-2
> Severity: serious
> Justification: file conflict
>
> Hi,
>
> procps fails to install due to file conflict with manpages-pl:
>
> Unpacking procps (2:3.3.17-2) over (2:3.3.17-1) ...
> dpkg: error processing archive
> /var/cache/apt/archives/procps_2%3a3.3.17-2_amd64.deb (--unpack):
>  trying to overwrite '/usr/share/man/pl/man1/free.1.gz', which is also in
> package manpages-pl 1:4.2.0-1
> dpkg: error while cleaning up:
>  new procps package post-removal script subprocess returned error exit
> status 1
> Errors were encountered while processing:
>  /var/cache/apt/archives/procps_2%3a3.3.17-2_amd64.deb
> mount: /usr: mount point is busy.
> E: Sub-process /usr/bin/dpkg returned an error code (1)
>
> Regards,
> robert
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (990, 'unstable-debug'), (990, 'unstable'), (990,
> 'testing'), (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'),
> (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>

Bug#975160: NMU still in DELAYED queue

[Maximilian Engelhardt]

Ping to avoid autoremoval. The NMU from Adrian Bunk should hit the archive 
within one day now.

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

Bug#982061: package-update-indicator throws GLib-ERROR and does not run

[Unit 193]

Howdy,

I just tried the glib2.0 2.66.7-1 which was just uploaded and it fixed the 
problem for me.  Can you give it a try and see if you can confirm this?



Thanks!

~Unit 193
Unit193 @ freenode
Unit193 @ OFTC

On Sun, 7 Feb 2021, Gökalp Çelik wrote:


I tested with 2.66.4 package from bullseye and package-update-indicator came 
back however those older packages also suffer from a vulnerability that later
sid packages don't. So it seems that there is a problem with 
package-update-indicator implementation as well. 

On Sun, Feb 7, 2021 at 1:15 AM Unit 193  wrote:
  Howdy,

  The exact error message seen is:
    GLib-ERROR **: 17:08:39.264: ../../../glib/gmem.c:112: failed to 
allocate 93955162462643 bytes

  This actually started happening with an update of glib2.0 to 2.66.6-1, 
though
  2.67.3-1 is also affected.  To work around such problem, I have 
downgraded the
  library to 2.66.5-1 which solved the issue for now.


  ~Unit 193
  Unit193 @ freenode
  Unit193 @ OFTC



--
Gökalp Çelik
Biyoinformatik Hizmetleri
Intergen Genetik Hastalıklar Tanı Merkezi
[uc?id=13PckZnCcbyy6hUEAlkK1HhWiF33n9za0=download]
Tel:  +90 (312) 428 48 14  /  +90 (312) 428 36 90
Fax:  +90 (312) 428 26 93
Web: www.intergen.com.tr - @Mail: gokalpce...@intergen.com.tr

Bug#982565: it seems to be due to not using systemd

[Matija Nalis]

I've added some basic debugging of my own, and it seems it is caused
by transitive_dependencies() function in /usr/bin/unattended-upgrade
being called with pkg.name="systemd"

Note: I run sysvinit, and do not have "systemd" package installed.

Are there any workarounds for using unattened-upgrade with sysvinit
(eg. without systemd) in Buster? How about Bullseye?

Thanks,
Matija

-- 
Opinions above are GNU-copylefted.

Bug#982568: ehcache build-depends on removed package.

[peter green]

Package: ehcache
Version: 2.6.11-4
Severity: serious

ehcache build-depends on libgeronimo-jta-1.0.1b-spec-java which is no longer
available in testing. The physical package was removed back in september
but it remained available as a virtual package provided by
libgeronimo-jta-1.1-spec-java until that too was removed recently. From
the removal request it looks like the replacement is
libgeronimo-jta-1.2-spec-java

I tried switching the build-dependency but the build failed with

[javac] /ehcache-2.6.11/src/main/java/net/sf/ehcache/transaction/manager/TransactionManagerLookup.java:18: error: package javax.transaction does not exist 
[javac] import javax.transaction.TransactionManager; 

Bug#982567: openms build-depends on removed package.

[peter green]

Package: openms
Version: 2.6.0+cleaned1-2
Severity: serious

openms build-depends on seqan-dev which was built by the sequan source
package, which was removed from unstable and testing recently. The person
requesting the removal stated that "There are no other users of seqan 1.x
in Debian." but it seems this was not correct.

I tried removing the build-dependency as there did not appear to be
a corresponding runtime depedency, but that made configure fail.

I then tried with libseqan3-dev but that also made configure fail

I then tried with libseqan2-dev, in that case configure succeeded
but the build failed with


/openms-2.6.0+cleaned1/src/openms/source/FORMAT/FASTAFile.cpp:44:10: fatal 
error: seqan/seq_io/guess_stream_format.h: No such file or directory
   44 | #include 
  |  ^~~~
compilation terminated.

Bug#982566: procps: Fails to install

[Robert Luberda]

Package: procps
Version: 2:3.3.17-2
Severity: serious
Justification: file conflict

Hi,

procps fails to install due to file conflict with manpages-pl:

Unpacking procps (2:3.3.17-2) over (2:3.3.17-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/procps_2%3a3.3.17-2_amd64.deb (--unpack):
 trying to overwrite '/usr/share/man/pl/man1/free.1.gz', which is also in 
package manpages-pl 1:4.2.0-1
dpkg: error while cleaning up:
 new procps package post-removal script subprocess returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/procps_2%3a3.3.17-2_amd64.deb
mount: /usr: mount point is busy.
E: Sub-process /usr/bin/dpkg returned an error code (1)

Regards,
robert


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

Bug#982435: [screen-devel] [bug #60030] Screen segfaults by displaying some UTF-8 character combination

[Axel Beckert]

Hi Michael,

Michael Schroeder schrieb am Thu, Feb 11, 2021 at 04:54:46PM +:
> I've dug a bit more into this, and the root cause of all the evil we
> see seems to be that utf8_isdouble() does not return true for the
> 0xdf00-0xdfff character range. This seems to be a mistake done
> in commit b8fd0c833bbd910a525d270ebc8f7e87ee00cb0a in the year 2008!

Kinda explains why the original submitter couldn't reproduce in 4.0.6
or so. Was though surprised to see this version still being around
somewhere.

> While adding the df00-dfff range to utf8_isdouble is already fixing
> the segfault, I think we should still apply the changes I sent earlier
> for extra safety.

Seems as if that "ÿ " issue is gone now with your most recent patch.
The crash is gone, too. And "e̤̒" is output properly, too.

Yay, thanks!

The only thing it didn't fix so far is
https://savannah.gnu.org/bugs/?31336 aka
https://bugs.debian.org/600246 although I really had some hope that
this might be fixed as a side-effect of your patch. :-)

(Also reenabling the patch in these bug reports still showed the
regression discovered back then: https://bugs.debian.org/677512)

So I'll switch the Debian package of screen to that third patch of
yours. Thanks!

Salvatore, Utkarsh: Will also prepare and test at least patches in Git
for Buster and Stretch. (Hey, I don't want my mutt screen sessions to
be killed anymore when reading this thread. ;-) We should then
probably coordinate 1:1 who does the according stable-security and LTS
uploads.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: PGP signature

Bug#943752: memtest86+: Please switch source tree

[Matt Taggart]

The coreboot fork of memtest86+ at

https://review.coreboot.org/q/project:memtest86plus

has commits as recently as Aug 31 2020 (although I don't see those if I 
clone https://review.coreboot.org/memtest86plus directly).


I don't know if that project is related to or coordinating with the 
recent upstream 5.31b changes. I can't find an upstream source code repo 
or bug tracker. It would be good if people could collaborate on these 
things...


There is a suggestion on the coreboot project ideas page to take the 
memtest86+ suite and make it more generic payload that could run on 
non-x86 platforms as well


https://doc.coreboot.org/contributing/project_ideas.html#libpayload-based-memtest-payload

That would be a great goal (but maybe just getting a common working code 
base would be a good start).


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

Bug#982565: Exception: 'NoneType' object has no attribute 'dependencies' (fails installing packages)

[Matija Nalis]

Package: unattended-upgrades
Version: 1.11.2
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Trying to run unattended-upgrades does not result in upgraded packages (neither 
when done automatically nor manually)

Running it manually with "unattended-upgrades -d" ends with following lines:

  Packages that will be upgraded: apt apt-utils base-files ca-certificates 
distro-info-data file grub-common grub-pc grub-pc-bin grub2-common iproute2 
libapt-inst2.0 libapt-pkg5.0 libefiboot1 libefivar1 libgnutls30 libjpeg62-turbo 
libldap-2.4-2 libldap-common libmagic-mgc libmagic1 libp11-kit0 libpq5 
libsqlite3-0 libssl-dev libssl1.1 libsystemd0 libudev1 libxml2 libzstd1 
linux-image-amd64 linux-libc-dev openssl postgresql-11 postgresql-client-11 
python-apt-common python-lxml python3-apt sudo tcpdump tzdata udev unzip
  Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
  Exception: 'NoneType' object has no attribute 'dependencies'
  InstCount=0 DelCount=0 BrokenCount=0
  Extracting content from 
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log since 2021-02-11 
23:06:20

However it does not upgrade packages, and 
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log remains zero-byte 
sized.

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

I seem to recall it working back in Stretch...

I've tried running it manually and automatically for few weeks.
I've also tried purging and reinstalling unattended-upgrades, as well as 
changing 
Unattended-Upgrade::MinimalSteps to "false" and to "true" - none of that helps.

   * What was the outcome of this action?

I expected unattended-upgrades to automatically upgrade packages.

   * What outcome did you expect instead?

Instead it dies with "Exception: 'NoneType' object has no attribute 
'dependencies'" without upgrading packages.

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


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

Kernel: Linux 4.19.0-12-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages unattended-upgrades depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  lsb-base   10.2019051400
ii  lsb-release10.2019051400
ii  python33.7.3-1
ii  python3-apt1.8.4.1
ii  python3-dbus   1.2.8-3
ii  python3-distro-info0.21
ii  ucf3.0038+nmu1
ii  xz-utils   5.2.4-1

Versions of packages unattended-upgrades recommends:
ii  cron [cron-daemon]  3.0pl1-134+deb10u1

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx  8.1.2-0.20180807cvs-1
ii  needrestart3.4-5
ii  nullmailer [mail-transport-agent]  1:2.2-3
ii  powermgmt-base 1.34
ii  python3-gi 3.30.4-1

-- debconf information:
* unattended-upgrades/enable_auto_updates: true

Bug#966575: grub-pc: Bailing out if the boot device from the debconf database does not longer exist might produce a more complicated issue

[Daniel Leidert]

Am Donnerstag, dem 11.02.2021 um 21:09 + schrieb Colin Watson:
> On Thu, Feb 11, 2021 at 09:34:31PM +0100, Daniel Leidert wrote:
> > I recently stumbled into this issue myself. Reading your explanation was
> > very
> > helpful. However the way you fixed it produces another issue as described
> > here:
> > 
> > https://forum.openmediavault.org/index.php?thread/37903-grub-related-error-on-5-5-23-update/
> > 
> > The command suggested by the error message (dpkg-reconfigure) actually
> > doesn't work if grub-pc is not fully installed.
> 
> Hm, it's true that's not entirely ideal, sorry.  I think I'd probably
> meant to recommend an interactive run of "dpkg --configure grub-pc", but
> I'll need to think about how to present that best.  Your reply on that
> thread seems slightly overkill - there should be no reason to drop to
> low priority, since the relevant questions are asked at critical.

I didn't check the priority. But I only see two possible actions to take after
the installation bailed out: either run "apt-get install -f" and enforce a
debconf frontend, or preset the value using debconf tools.

> > I don't have a technical solution myself, but bailing out creates an
> > even worse situation here.
> 
> For context: every single time the GRUB core <-> modules ABI has changed
> in the last ten years or so, we've had multiple critical bugs filed due
> to unbootable systems as a result of incorrect configuration causing the
> boot loader to be only half-upgraded.  I entirely disagree that a failed
> upgrade, even on many systems, is a worse situation than that.

"Worse" in the sense of that the upgrade bails out and the presented command
doesn't work. I wasn't just talking about the bailing-out part.

The user just needs a way to fix things when this issue is detected.

[..]
> > I was also thinking: If this cannot be handled in a technical way this
> > should definitely be mentioned in the release notes.
> 
> I'm not opposed to some kind of mention in the release notes, I suppose,
> but it feels like more of a general operations manual sort of thing (for
> example, it might happen on the next upgrade after a subtly-botched disk
> swap), and I'm not sure where would be best.  This isn't particularly
> specific to any one Debian release.

Large parts of the document are not specific to any one Debian release. Almost
all advice given in section 4 applies to upgrades in general. Maybe add a
section similar to 4.6 and call it "Upgrading grub (and related packages)"?


Regards, Daniel
-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

If you like my work consider sponsoring me via
https://www.patreon.com/join/dleidert


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

Bug#780174: memtest86 nonfree

[Matt Taggart]

Is it time for memtest86 (not memtest86+) to either:

a) fork from the last free version
b) move to nonfree (if allowed)
c) be removed from debian in favor of memtest86+

?

memtest86+ has recently been seeing some updates (although the new stuff 
is still in beta and buggy). Also while searching I found this idea in 
the coreboot wiki to make a memory tester payload that wasn't x86 
specific (well, might still have x86 specific support, but would also 
work elsewhere) 
https://doc.coreboot.org/contributing/project_ideas.html#libpayload-based-memtest-payload


Thanks,

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

Bug#982148: frama-c: autopkgtest failure: nothing logged

[Gianfranco Costamagna]

control: tags -1 patch

Hello, I see two errors:
1) the "set -e" makes the script return on first error, so you can't see in the 
test why it failed
2) there a missing libwhy3-ocaml-dev dependency triggering the error

diff -Nru frama-c-20201209+titanium/debian/changelog 
frama-c-20201209+titanium/debian/changelog
--- frama-c-20201209+titanium/debian/changelog  2021-01-11 20:17:46.0 
+0100
+++ frama-c-20201209+titanium/debian/changelog  2021-02-11 23:09:31.0 
+0100
@@ -1,3 +1,11 @@
+frama-c (20201209+titanium-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Fix new eva test dependencies and return in case of error (Closes:
+#982148)
+
+ -- Gianfranco Costamagna   Thu, 11 Feb 2021 
23:09:31 +0100
+
 frama-c (20201209+titanium-4) unstable; urgency=medium

   * Add a test for the eva plugin
diff -Nru frama-c-20201209+titanium/debian/tests/control 
frama-c-20201209+titanium/debian/tests/control
--- frama-c-20201209+titanium/debian/tests/control  2021-01-11 
20:17:46.0 +0100
+++ frama-c-20201209+titanium/debian/tests/control  2021-02-11 
23:09:19.0 +0100
@@ -1,5 +1,5 @@
 Tests: eva
-Depends: frama-c-base
+Depends: frama-c-base, why3, libwhy3-ocaml-dev

 Tests: wp
 Depends: frama-c-base, alt-ergo (>= 2.0.0), why3, libwhy3-ocaml-dev
diff -Nru frama-c-20201209+titanium/debian/tests/eva 
frama-c-20201209+titanium/debian/tests/eva
--- frama-c-20201209+titanium/debian/tests/eva  2021-01-11 20:17:46.0 
+0100
+++ frama-c-20201209+titanium/debian/tests/eva  2021-02-11 23:09:29.0 
+0100
@@ -1,6 +1,6 @@
 #!/bin/sh

-set -e
+#set -e

 indir=debian/tests/c
 this=eva

Bug#982559: xscorch Build-Depends on libreadline-gplv2-dev which has been removed

[peter green]

tags 982559 +patch
thanks

Taking a poke through the source it seems there is a bunch of logic in the 
build system to
detect if readline is available, but I can't find any evidence of any code 
actually
using readline. After removing the build-dependency I can successfully build 
xscorch
in an environment with no readline development packages installed.

I would thus propose simply dropping the build-dependency, a debdiff doing that 
is
attached, I may or may not NMU it later.
diff -Nru xscorch-0.2.1/debian/changelog xscorch-0.2.1/debian/changelog
--- xscorch-0.2.1/debian/changelog  2020-08-05 04:00:19.0 +
+++ xscorch-0.2.1/debian/changelog  2021-02-11 21:53:35.0 +
@@ -1,3 +1,10 @@
+xscorch (0.2.1-1+nmu5) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove build-dependency on libreadline-gplv2-dev
+
+ -- Peter Michael Green   Thu, 11 Feb 2021 21:53:35 +
+
 xscorch (0.2.1-1+nmu4) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru xscorch-0.2.1/debian/control xscorch-0.2.1/debian/control
--- xscorch-0.2.1/debian/control2020-07-02 14:45:01.0 +
+++ xscorch-0.2.1/debian/control2021-02-11 21:53:35.0 +
@@ -4,7 +4,7 @@
 Homepage: http://www.xscorch.org/
 Maintainer: Jacob Luna Lundberg 
 Standards-Version: 3.9.2
-Build-Depends: debhelper (>= 7), groff, libglib2.0-dev, libgtk2.0-dev (>= 
2.20), libmikmod-dev, libreadline-gplv2-dev | libreadline5-dev, libx11-dev, 
libxext-dev, libxi-dev, autotools-dev
+Build-Depends: debhelper (>= 7), groff, libglib2.0-dev, libgtk2.0-dev (>= 
2.20), libmikmod-dev, libx11-dev, libxext-dev, libxi-dev, autotools-dev
 
 Package: xscorch
 Architecture: any

Bug#910347: Not reproducible for me

[Aurélien COUDERC]

Hi ghost,

I used to have similar issues but I don’t remember seeing it recently so it 
may well be resolved. I’m using scaling 1,25 so not exactly the same as you 
but I did experience the issue and it did disappear for me on bullseye.

Did you try running bullseye by any chance ?

I’ll monitor that more closely and report back. I previously got used to it 
and learned to ignore the issue.


Happy hacking !
--
Aurélien

Bug#981864: libinih: Please provide libinih1-udeb

[Bastian Germann]

On Wed, 10 Feb 2021 17:10:30 +0800 Yangfl  wrote:

在 2021年2月9日星期二，Bastian Germann  写道：

> On Mon, 8 Feb 2021 15:36:31 +0100 Cyril Brulebois  wrote:
>
>> We would be happy to have this merged soon, since xfs support in the
>> installer is currently broken:
>>
>>   https://bugs.debian.org/981662
>>
>> I'm happy to upload the package and talk to the ftp team (a little
>> trip to NEW will happen) myself if that helps.
>>
>
> Yes, please upload. I think, the timeline justifies a NMU.
>

Hi, please upload the latest version from git repo, I have some troubles
finding sponsor, thanks.


Hi Cyril,

will you sponsor the new version?

Thanks,
Bastian

Bug#982564: munge is uninstallable on s390x

[Brian Murray]

Package: munge
Version: 0.5.14-1
Severity: important
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute

Dear Maintainer,

munge 0.5.14-1 seems to be uninstallable on s390x

This bug report was also filed in Ubuntu and can be found at
http://launchpad.net/bugs/1915457

The description, from Brian Murray, follows:

Preparing to unpack .../libmunge2_0.5.14-1_s390x.deb ...
Unpacking libmunge2 (0.5.14-1) ...   
Selecting previously unselected package munge.
Preparing to unpack .../munge_0.5.14-1_s390x.deb ...
Unpacking munge (0.5.14-1) ...
Setting up libmunge2 (0.5.14-1) ...
Setting up munge (0.5.14-1) ...
mungekey: Error: Failed to finalize HKDF MAC ctx for extraction
mungekey: Error: Failed to compute HKDF key derivation
mungekey: Error: Failed to create "/etc/munge/munge.key"
dpkg: error processing package munge (--configure):
 installed munge package post-installation script subprocess returned error 
exit status 1
Processing triggers for libc-bin (2.32-0ubuntu6) ...
Errors were encountered while processing:
 munge
E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#982563: kodiplatform build-depends unsatisfiable on mips64el, mipsel and s390x.

[peter green]

Package: kodiplatform
Version: 20180302-1
Severity: serious

kodiplatform build-depends on kodi-addons-dev which is not currently available
on mips64el, mipsel or s390x. However it appears that in the past 
kodi-addons-dev
was an arch all package and hence available on these architectures allowing
kodiplatform to be built.

Either kodi-addons-dev needs to be made available again on those architectures
or the kodiplatform binaries for those architectures need to be removed.

Bug#982399: marked as done (unblock: adequate/0.15.4)

[Willy nilly]

close #982399


On Thu, Feb 11, 2021 at 7:48 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Thu, 11 Feb 2021 20:44:06 +0100
> with message-id 
> and subject line Re: Bug#982399: unblock: adequate/0.15.4
> has caused the Debian Bug report #982399,
> regarding unblock: adequate/0.15.4
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 982399: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982399
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Andreas Beckmann 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Tue, 09 Feb 2021 18:51:57 +0100
> Subject: unblock: adequate/0.15.4
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
>
> Please unblock package adequate
>
> QA-maintained adequate fell out of testing due to python2 usage.
> That was fixed recently, but it is currently blocked from reentering by
> autopkgtest regressions and the corresponding RC bug.
> As adequate is actively being used by piuparts, I'd like to see it in
> bullseye. I'll take a look at what is going wrong there, but it's now
> too late for a fixed package to migrate to testing on its own. So maybe
> you could unblock (and/or override-autopkgtest or whatever) the current
> version and the fixed one should then be able to migrate on its own.
>
> Some of the failures are related to merged /usr (the
> bin-or-sbin-binary-requires-usr-lib-library test is probably moot
> nowadays) and the shared library failures are probably related to
> toolchain improvements.
>
> unblock adequate/0.15.4
>
> Thanks
>
> Andreas
>
>
>
> -- Forwarded message --
> From: Paul Gevers 
> To: Andreas Beckmann , 982399-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Thu, 11 Feb 2021 20:44:06 +0100
> Subject: Re: Bug#982399: unblock: adequate/0.15.4
> Hi Andreas,
>
> On 09-02-2021 18:51, Andreas Beckmann wrote:
> > Please unblock package adequate
>
> Done, but
>
> > QA-maintained adequate fell out of testing due to python2 usage.
> > That was fixed recently, but it is currently blocked from reentering by
> > autopkgtest regressions and the corresponding RC bug.
> > As adequate is actively being used by piuparts, I'd like to see it in
> > bullseye. I'll take a look at what is going wrong there, but it's now
> > too late for a fixed package to migrate to testing on its own. So maybe
> > you could unblock (and/or override-autopkgtest or whatever) the current
> > version and the fixed one should then be able to migrate on its own.
>
> We're doing this because it's part of the Debian QA infrastructure, but
> we're unhappy that is was only resolved so late. piuparts is put on the
> key packages list to avoid removal; do we understand correctly that
> adequate is not a Depends of piuparts because it's only installed inside
> the chroot (a Depends would have avoided the removal)?
>
> Paul
>
> PS: if you would have "just fixed" the autopkgtest and uploaded at the
> time this bug was filed, it would have migrated without any intervention.
>
> PS2: we'll leave the RC bug open, please fix the autopkgtest.
>
>

Bug#982209: marked as done (python-limits: autopkgtest failure on armhf)

[Willy nilly]

close #982209

On Thu, Feb 11, 2021 at 9:15 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Thu, 11 Feb 2021 21:06:13 +
> with message-id <20210211210613.gytbwquu7v5ag...@satie.tumbleweed.org.za>
> and subject line Re: Bug#982209: python-limits: autopkgtest failure on
> armhf
> has caused the Debian Bug report #982209,
> regarding python-limits: autopkgtest failure on armhf
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 982209: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982209
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Adrian Bunk 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Sun, 07 Feb 2021 15:09:48 +0200
> Subject: python-limits: autopkgtest failure on armhf
> Source: python-limits
> Version: 1.5.1-1
> Severity: serious
>
>
> https://ci.debian.net/data/autopkgtest/testing/armhf/p/python-limits/10269362/log.gz
>
> ...
> autopkgtest [03:57:13]: test python3-tests: [---
> tests/redis-configurations
> tests/redis-configurations/cluster
> tests/redis-configurations/cluster/redis-0.conf
> tests/redis-configurations/cluster/redis-3.conf
> tests/redis-configurations/cluster/redis-1.conf
> tests/redis-configurations/cluster/redis-5.conf
> tests/redis-configurations/cluster/redis-4.conf
> tests/redis-configurations/cluster/redis-2.conf
> tests/redis-configurations/sentinel
> tests/redis-configurations/sentinel/redis-master.conf
> tests/redis-configurations/sentinel/redis-sentinel.conf
> tests/redis-configurations/sentinel/redis-slave.conf
> tests/redis-configurations/passwd.conf
> tests/redis-configurations/unixdomainsocket.conf
> tests/redis-configurations/basic.conf
> >>> Performing hash slots allocation on 6 nodes...
> Master[0] -> Slots 0 - 5460
> Master[1] -> Slots 5461 - 10922
> Master[2] -> Slots 10923 - 16383
> Adding replica 127.0.0.1:7004 to 127.0.0.1:7000
> Adding replica 127.0.0.1:7005 to 127.0.0.1:7001
> Adding replica 127.0.0.1:7003 to 127.0.0.1:7002
> >>> Trying to optimize slaves allocation for anti-affinity
> [WARNING] Some slaves are in the same host as their master
> M: b819d8d92c0d7ecec86c8a5eefee9fd2fce401bf 127.0.0.1:7000
>slots:[0-5460] (5461 slots) master
> M: e0719fb092e4b44c4b0d4fbbc6ddf418ac4e53de 127.0.0.1:7001
>slots:[5461-10922] (5462 slots) master
> M: 3a72682bdff4198c501ca8c1de13db7f89229648 127.0.0.1:7002
>slots:[10923-16383] (5461 slots) master
> S: 07c23d96312c9233c66efb2a729add941e1d7466 127.0.0.1:7003
>replicates b819d8d92c0d7ecec86c8a5eefee9fd2fce401bf
> S: 43517d4fe3512ff5013c006525e50285c5343004 127.0.0.1:7004
>replicates e0719fb092e4b44c4b0d4fbbc6ddf418ac4e53de
> S: 44217cdac950b440459d099801a61a636fc30165 127.0.0.1:7005
>replicates 3a72682bdff4198c501ca8c1de13db7f89229648
> Can I set the above configuration? (type 'yes' to accept): >>> Nodes
> configuration updated
> >>> Assign a different config epoch to each node
> >>> Sending CLUSTER MEET messages to join the cluster
> Waiting for the cluster to join
> 

Bug#890209: marked as done (vapicheck: CRITICAL **: assertion 'self != NULL' failed)

[Willy nilly]

close #890209

On Thu, Feb 11, 2021 at 7:33 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Thu, 11 Feb 2021 20:22:53 +0100
> with message-id <20210211192253.xfn2m5johdb7brsy@earth.universe>
> and subject line Close old bug
> has caused the Debian Bug report #890209,
> regarding vapicheck: CRITICAL **: assertion 'self != NULL' failed
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 890209: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890209
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Paul Wise 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Mon, 12 Feb 2018 08:33:04 +0800
> Subject: vapicheck: CRITICAL **: assertion 'self != NULL' failed
> Package: valac
> Version: 0.39.7-1
> Severity: normal
> File: /usr/bin/vapicheck
> Control: found -1 0.38.7-1
>
> The vapicheck program prints four assertions no matter which file is
> loaded. I believe these are defects in vapicheck itself rather than the
> files that vapicheck is checking.
>
> $ vapicheck
> Usage: vapicheck library.gidl
> $ touch foo.gidl
> $ vapicheck foo.gidl
>
> ** (process:31239): CRITICAL **: vala_collection_get_size: assertion 'self
> != NULL' failed
>
> ** (process:31239): CRITICAL **: vala_list_get: assertion 'self != NULL'
> failed
>
> ** (process:31239): CRITICAL **: vala_code_context_get_report: assertion
> 'self != NULL' failed
>
> ** (process:31239): CRITICAL **: vala_report_err: assertion 'self != NULL'
> failed
> $ apt-file search -I dsc .gidl
> poppler: /glib/poppler.gidl
> $ apt source -qq poppler
> ...
> $ vapicheck poppler-0.62.0/glib/poppler.gidl
>
> ** (process:722): CRITICAL **: vala_collection_get_size: assertion 'self
> != NULL' failed
>
> ** (process:722): CRITICAL **: vala_list_get: assertion 'self != NULL'
> failed
>
> ** (process:722): CRITICAL **: vala_code_context_get_report: assertion
> 'self != NULL' failed
>
> ** (process:722): CRITICAL **: vala_report_err: assertion 'self != NULL'
> failed
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing-debug
>   APT policy: (900, 'testing-debug'), (900, 'testing'), (800,
> 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700,
> 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8),
> LANGUAGE=en_AU.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages valac depends on:
> ii  libc62.26-4
> ii  libglib2.0-0 2.54.3-2
> ii  libglib2.0-dev   2.54.3-2
> ii  libvala-0.40-0   0.39.7-1
> ii  valac-0.40-vapi  0.39.7-1
>
> Versions of packages valac recommends:
> ii  gcc  4:7.2.0-1d1
>
> valac suggests no packages.
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>
>
>
> -- Forwarded message --
> From: Sebastian Reichel 
> To: 890209-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Thu, 11 Feb 2021 20:22:53 +0100
> Subject: Close old bug
> Version: 0.39.91-1
>
> Hi,
>
> Let's close this old bug. Upstream closed the bug with a fix, which
> is included in 0.39.91:
>
>
> https://github.com/GNOME/vala/commit/fbb944d0a33e4b074f35d8d5457d4ec83e03f729
>
> -- Sebastian
>

Bug#972080: marked as done (routine-update: Sometimes deletes manually added python3 dependency)

[Willy nilly]

close #972080

On Thu, Feb 11, 2021 at 7:21 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Thu, 11 Feb 2021 19:19:12 +
> with message-id 
> and subject line Bug#961492: fixed in dh-r 20210211
> has caused the Debian Bug report #961492,
> regarding routine-update: Sometimes deletes manually added python3
> dependency
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 961492: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961492
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: "Michael R. Crusoe" 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Mon, 12 Oct 2020 12:24:40 +0200
> Subject: routine-update: Sometimes deletes manually added python3
> dependency
> Package: routine-update
> Version: 0.0.5
> Severity: important
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Example:
> https://salsa.debian.org/r-pkg-team/r-cran-argparse/-/commit/40280c42ef0a8635bb7af13f25c91ef34a4b2317
>
>
> -BEGIN PGP SIGNATURE-
>
> iQJGBAEBCgAwFiEEck1gkzcRPHEFUNdHPCZ2P2xn5uIFAl+ELugSHGNydXNvZUBk
> ZWJpYW4ub3JnAAoJEDwmdj9sZ+biEuoP/iI9U80wZS22VTvkSI4/M7JMoZAf7lrv
> vV6wO6IdDYYLbQQJXqoEXVc+UDzynP2V6IBKeFY2HwQQ6Mj4D75fyvfNkPKKOrgY
> CNo3Frl3eCaz4pvEt6Pho/K+c5UkHmAXpbi5PXO7wN9Qf1cNhsI4xtRA9kiQmIPi
> rShXKmEeyztilwW/E0OQTr8f7QXMZ1TXfriq9PWMNyCM2cmRsGiMOkE4jok47U4h
> p8Sqy88MsgNKuBkf4m+xrXNoyV5z8NQMPt+ZRYdhovI4w337LNg5DHag6xtg+y3E
> CTjLw7+yS0y8yRMlHNB0uAihYJfJRBYSM6su+su55xThkSs99r8+X/XNqGHNr7FT
> oNNkF96p8b0gAjohrDnwNSQeo9Yi6Ly3B8LqG5CHV6eg9ejFYF0cHV3jsHyIpt4J
> 4IfEOijnjQGLIVexoW1XRzW2MPdZBv3U4XhVxOO9oCxprtUabnJvnAZbkwc1mUnN
> 5aardnQMKkicyQi+ftlFvNHfss7voGKEG7aT0DbyXZwGHdZ9VmVlKgVTfNmwdAUd
> cG2KlkNtdxjMZbwY3icgg0TSpwmvkl6RT7snh0ntZUtkwJr1jPrCihy8FNuboZRP
> Ifp9oOTPAL6WUvPmEW+W/l0W6M4BBJI+70A/V96TCvksAKknEmOBcBNg4ZTfBApU
> 2XUTGcCvwyOO
> =nP4D
> -END PGP SIGNATURE-
>
>
>
> -- Forwarded message ------
> From: Debian FTP Masters 
> To: 961492-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Thu, 11 Feb 2021 19:19:12 +
> Subject: Bug#961492: fixed in dh-r 20210211
> Source: dh-r
> Source-Version: 20210211
> Done: Gordon Ball 
>
> We believe that the bug you reported is fixed in the latest version of
> dh-r, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 961...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Gordon Ball  (supplier of updated dh-r package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Thu, 11 Feb 2021 18:56:44 +
> Source: dh-r
> Architecture: source
> Version: 20210211
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian R Packages Maintainers <
> r-pkg-t...@alioth-lists.debian.net>
> Changed-By: Gordon Ball 
> Closes: 961492
> Changes:
>  dh-r (20210211) unstable; urgency=medium
>  .
>[ Andreas Tille ]
>* DhVersion = 13
>  .
>[ Gordon Ball ]
>* Fix excess de-duplication of dependencies which resulted
>  in non-R build dependencies getting dropped (Closes: #961492)
> Checksums-Sha1:
>  62c8f332fb4a6e0929554fbdafe54d14ef99c082 1713 dh-r_20210211.dsc
>  2104ccfbd702dbb01c60b808a578c0c724373fbe 39600 dh-r_20210211.tar.xz
>  2a247cad4059185bff804bec84b1d5d7faed9f9d 5824
> dh-r_20210211_source.buildinfo
> Checksums-Sha256:
>  bb5bf345e0b634df98a8b2bbb5d2c042a2693d4faa5a9bb74e42674fbb400a17 1713
> dh-r_20210211.dsc
>  4e9e8a0650bbf72affc484494047c1c2a56456b95108aecf97041eddfbf140b3 39600
> dh-r_20210211.tar.xz
>  632dc54f2a14599da6ccfd386bb374497bd3b9cff82179244c925572444166d1 5824
> dh-r_20210211_source.buildinfo
> Files:
>  6187df8aa64395d9a8c55ad38fbd9153 1713 science optional dh-r_20210211.dsc
>

Bug#979378: marked as done (network-manager should drop unused Build-Depends)

[Willy nilly]

close #979378

On Thu, Feb 11, 2021 at 7:51 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Thu, 11 Feb 2021 19:49:17 +
> with message-id 
> and subject line Bug#979378: fixed in network-manager 1.29.90-1
> has caused the Debian Bug report #979378,
> regarding network-manager should drop unused Build-Depends
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 979378: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979378
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Helmut Grohne 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Tue, 5 Jan 2021 22:56:22 +0100
> Subject: network-manager should drop unused Build-Depends
> Source: network-manager
> Version: 1.28.0-2
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
>
> network-manager has a number of Build-Depends and is involved in
> dependency cycles relevant to architecture bootstrap. Instead of looking
> into such cycles, a simpler measure is looking into entirely unused
> Build-Depends. As it happens, network-manager has those.
>
> According to debian/changelog, libyaml-perl was added to build the
> documentation. At this point nothing in the source mentions it in any
> way. I think it can be safely dropped.
>
> The NEWS file kindly explains that since version 1.24,
> libpolkit-agent-1-dev and libpolkit-gobject-1-dev are no longer needed.
> While meson.build and configure.ac still check for polkit-agent, they're
> completely unused otherwise and network-manager now interacts with
> polkit via dbus and its own abstraction only.
>
> Please consider applying the attached patch to drop these dependencies.
>
> Helmut
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 979378-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Thu, 11 Feb 2021 19:49:17 +
> Subject: Bug#979378: fixed in network-manager 1.29.90-1
> Source: network-manager
> Source-Version: 1.29.90-1
> Done: Michael Biebl 
>
> We believe that the bug you reported is fixed in the latest version of
> network-manager, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 979...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Michael Biebl  (supplier of updated network-manager
> package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Format: 1.8
> Date: Thu, 11 Feb 2021 20:09:16 +0100
> Source: network-manager
> Architecture: source
> Version: 1.29.90-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Utopia Maintenance Team <
> pkg-utopia-maintain...@lists.alioth.debian.org>
> Changed-By: Michael Biebl 
> Closes: 979378
> Changes:
>  network-manager (1.29.90-1) unstable; urgency=medium
>  .
>[ Michael Biebl ]
>* New upstream version 1.29.90 (1.30 rc1)
>* Rebase patches
>* Update symbols file for libnm0
>* Fix polkit-agent-helper-1 path
>  .
>[ Helmut Grohne ]
>* Drop unused Build-Depends (Closes: #979378)
> Checksums-Sha1:
>  886bf0ddfc6f72f3a2c25ade0bd735b86edf4565 3074
> network-manager_1.29.90-1.dsc
>  ffaaa96a37fbaea816bb1e5fbabf0d19be6a3b8c 5220496
> network-manager_1.29.90.orig.tar.xz
>  71b3ed5a06dd50ac801d73b3d9d0c9d082c018ba 46404
> network-manager_1.29.90-1.debian.tar.xz
>  0fe0b30c60574acbed8e41efec4b8fa4b25cdc32 10953
> network-manager_1.29.90-1_source.buildinfo
> Checksums-Sha256:
>  0e2c4275a352134181eef418c41696a5d9e38c01f2a4fed802e24a9336e127b8 3074
> network-manager_1.29.90-1.dsc
>  a6cf4f03275c7877b52c95a3e19fe7286a9742a1fe2449dddfdcaf65701d9635 5220496
> network-manager_1.29.90.orig.tar.xz
>  23a274730304e3a460487c1c2928fb6485034fb3160d55497b9417a9156f2964 46404
> network-manager_1.29.90-1.debian.tar.xz
>  964369dfdaf5177bb119f9ba4540d98621afeef507a5fd0717ffb2fdc0439fbd 10953
> network-manager_1.29.90-1_source.buildinfo
> Files:
>  b8183015cd048792c792a316dfb88b1e 3074 net optional
> network-manager_1.29.90-1.dsc
>  c9d582522bd61ec57dd5048139f017d8 5220496 net optional
> network-manager_1.29.90.orig.tar.xz
>  c08003d2509d9e6b98b92940cb36d07f 46404 net optional
> 

Bug#961492: marked as done (dh-update-R removes non-R dependencies")

[Willy nilly]

close #961492

On Thu, Feb 11, 2021 at 7:21 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Thu, 11 Feb 2021 19:19:12 +
> with message-id 
> and subject line Bug#961492: fixed in dh-r 20210211
> has caused the Debian Bug report #961492,
> regarding dh-update-R removes non-R dependencies"
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 961492: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961492
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Adrian Bunk 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Mon, 25 May 2020 12:02:58 +0300
> Subject: routine-update removes required dependencies
> Package: routine-update
> Version: 0.0.2
> Severity: grave
>
>
> https://salsa.debian.org/r-pkg-team/r-cran-nozzle.r1/-/commit/7d7b872597ffa83f453db4d3b43c0e66d49bd479
>
> https://salsa.debian.org/r-pkg-team/r-cran-fontliberation/-/commit/952ff2238ad81e9da18899dcd871ecc5454dd0c8
>
> These were causing RC bugs during the R transition,
> I hope there are not more such breakages that were
> not yet found.
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 961492-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Thu, 11 Feb 2021 19:19:12 +
> Subject: Bug#961492: fixed in dh-r 20210211
> Source: dh-r
> Source-Version: 20210211
> Done: Gordon Ball 
>
> We believe that the bug you reported is fixed in the latest version of
> dh-r, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 961...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Gordon Ball  (supplier of updated dh-r package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Thu, 11 Feb 2021 18:56:44 +
> Source: dh-r
> Architecture: source
> Version: 20210211
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian R Packages Maintainers <
> r-pkg-t...@alioth-lists.debian.net>
> Changed-By: Gordon Ball 
> Closes: 961492
> Changes:
>  dh-r (20210211) unstable; urgency=medium
>  .
>[ Andreas Tille ]
>* DhVersion = 13
>  .
>[ Gordon Ball ]
>* Fix excess de-duplication of dependencies which resulted
>  in non-R build dependencies getting dropped (Closes: #961492)
> Checksums-Sha1:
>  62c8f332fb4a6e0929554fbdafe54d14ef99c082 1713 dh-r_20210211.dsc
>  2104ccfbd702dbb01c60b808a578c0c724373fbe 39600 dh-r_20210211.tar.xz
>  2a247cad4059185bff804bec84b1d5d7faed9f9d 5824
> dh-r_20210211_source.buildinfo
> Checksums-Sha256:
>  bb5bf345e0b634df98a8b2bbb5d2c042a2693d4faa5a9bb74e42674fbb400a17 1713
> dh-r_20210211.dsc
>  4e9e8a0650bbf72affc484494047c1c2a56456b95108aecf97041eddfbf140b3 39600
> dh-r_20210211.tar.xz
>  632dc54f2a14599da6ccfd386bb374497bd3b9cff82179244c925572444166d1 5824
> dh-r_20210211_source.buildinfo
> Files:
>  6187df8aa64395d9a8c55ad38fbd9153 1713 science optional dh-r_20210211.dsc
>  04b876ad1413668064cd5e6aceb96f91 39600 science optional
> dh-r_20210211.tar.xz
>  dfe08a1d3103af01f6c24d3d18e7832f 5824 science optional
> dh-r_20210211_source.buildinfo
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEE6PwpXIa418BJ+Xuno12v+60p6N4FAmAlf8sACgkQo12v+60p
> 6N6fyA//ZMLZ9mQudrHjFckE6bDD0Ah2Sb2sUyDU5D+IAn3tSljGx3FOBIbQxTo9
> GeGvHqh2zCyNbwF813WIv4P4qMt9Tepd/t2I8y9doumjyP+Zb/TjK/nc52QODVeC
> VcY/g2+YFbsmeL/credkg2DlyKxxWAI+aPOHlnqVyjDj3Cg6EpaUsjrowyXXrUXS
> Crtp3ugl3AsIQR99jRirgEPYQdTVEmljFVRq0w1WrS3ohPkNVn/a6HXFP4XRx7Ti
> 5rx4AmZktWbS1mkRLlzVUlEzQWFpHQ2Wmep5k8Z8lsJul0jyvaF/N71WgneT+ZJK
> VmxIRmCjOYUZ+uWW6dUSl34EUz/bfFa24sEt4JUP4kfzPn/tMXhp/SYmPl6g8zYN
> VCcTG2MdwzvVr/kOUZyFUn6J6t0AxkNxRmdZeIOL9gB0Z3rc8I0lguYP6QfSAOgJ
> 4rMXG60kDvLkQsVn9g0nC2B3Zz33f9Y7DMlfxRFqa5oeiWBuFm0Aulh+Ezy09ieL
> N4iL45D4+ndZpmpdLwKjJRSjbBc1w7wf+XiCu3qP2hGE3hMaLF2os1Az59ah20Xe
> FHx1stv23m6SOzrvkj4mlqIb0Kig/EVMiR7iOdDJz/d672e2qsgyoy9AecPmIl3C
> dezid/Vbq1iZAw/cGIvHPXd+1SdjyWT1vtRHRTSR/SicGYIMiJM=
> =YFxN
> -END PGP SIGNATURE-

Bug#980428: CVE-2020-28948 write operations with directory traversal affecting Archive_Tar through 1.4.11

[Ondřej Surý]

Ack, it's in my queue for tomorrow now. Thanks for poking.

Ondrej

On Sat, 6 Feb 2021 at 22:51, Salvatore Bonaccorso  wrote:

> Control: severity -1 serous
>
> Hi PHP maintainers,
>
> On Mon, Jan 18, 2021 at 08:03:42PM -0400, David Prévot wrote:
> > Package: php-pear
> > Version: 1:1.10.9+submodules+notgz-1.1
> > Severity: important
> > Tags: security
> > X-Debbugs-Cc: Debian Security Team 
> >
> > Hi,
> >
> > The latest (1.4.11) Archive_Tar adds a fix related to CVE-2020-28948.
> >
> > https://github.com/FriendsOfPHP/security-advisories/pull/525
>
> This should ideally be fixed before the bullseye release, so raising
> the severity to RC.
>
> Regards,
> Salvatore
>
>

Bug#966575: grub-pc: Bailing out if the boot device from the debconf database does not longer exist might produce a more complicated issue

[Colin Watson]

On Thu, Feb 11, 2021 at 09:34:31PM +0100, Daniel Leidert wrote:
> I recently stumbled into this issue myself. Reading your explanation was very
> helpful. However the way you fixed it produces another issue as described 
> here:
> 
> https://forum.openmediavault.org/index.php?thread/37903-grub-related-error-on-5-5-23-update/
> 
> The command suggested by the error message (dpkg-reconfigure) actually doesn't
> work if grub-pc is not fully installed.

Hm, it's true that's not entirely ideal, sorry.  I think I'd probably
meant to recommend an interactive run of "dpkg --configure grub-pc", but
I'll need to think about how to present that best.  Your reply on that
thread seems slightly overkill - there should be no reason to drop to
low priority, since the relevant questions are asked at critical.

> I don't have a technical solution myself, but bailing out creates an
> even worse situation here.

For context: every single time the GRUB core <-> modules ABI has changed
in the last ten years or so, we've had multiple critical bugs filed due
to unbootable systems as a result of incorrect configuration causing the
boot loader to be only half-upgraded.  I entirely disagree that a failed
upgrade, even on many systems, is a worse situation than that.

> Maybe instead of bailing out print a warning instead?

I simply don't think that enough people are going to see a warning in
the middle of what's often thousands of lines of dpkg output to make any
kind of difference.  The postinst already only bails out if it can't
prompt you interactively to fix the problem, and people are even less
likely to notice warnings printed in the middle of a *noninteractive*
upgrade.  They'll just find out about it when they reboot and their
system doesn't come up, which is worse.

It's also worth noting that bailing out here has apparently prompted
some bit of FAI config to be found and fixed, which has probably been
the partial cause of quite a few of those bugs.  The problem with this
whole situation is that I've always known that a large part of the fix
would have to be in installer-type code somewhere, but could never track
down where the bugs were because they were on other people's systems and
often years distant in time; that's been apparently intractable and very
frustrating.  Maybe it's just luck, but in those terms this has already
been one of the most successful interventions I've found so far.

> I was also thinking: If this cannot be handled in a technical way this should
> definitely be mentioned in the release notes.

I'm not opposed to some kind of mention in the release notes, I suppose,
but it feels like more of a general operations manual sort of thing (for
example, it might happen on the next upgrade after a subtly-botched disk
swap), and I'm not sure where would be best.  This isn't particularly
specific to any one Debian release.

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

Bug#982562: general: Storing upstream signatures next to upstream tarballs is problematic

[Raphaël Hertzog]

Package: general
Severity: normal
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: hert...@debian.org, debian-d...@lists.debian.org
Control: affects -1 ftp.debian.org dpkg-dev

Hi people,

After having been bitten (in Kali) by failures to import Debian packages
because a PGP signature file has been modified [1], this lead me to think
about this problem space and I concluded that the way we are storing
such signatures is not appropriate.

Those files are not really meant to be immutable:
- signing keys can expire and be revoked, upstream might want to update
  signatures of already released tarballs
- the set of "upstream release managers" might evolve over time and the
  official signature to use might change...

If we assume that the archive is meant to store immutable content
under a given filename (and to me that requirement seems to be a good
idea), then we should question ourselves whether we really want to store
those signatures in a filename that's associated to the upstream version.
They should either be tied to the Debian revision (so that they can change
over time without any new upstream release) or be incorporated in the
Debian tarball.

After all the key to verify those signatures is already stored in the
Debian tarball (when you use the uscan feature to verify those
signatures), so why not store the signature there as well?

I originally filed this in https://bugs.debian.org/949962 against
ftp.debian.org but the bug got closed because it's not really the
responsibility of ftpmasters to change this. So I'm starting a wider
discussion to gather feedback of all interested parties (at least
Guillem as dpkg maintainer). I won't drive this much further but
I wanted to have it properly recorded and considered.

Cheers,

[1] For details it happened in dbus-glib:
https://snapshot.debian.org/package/dbus-glib/0.110-2/ -> it has .asc file
https://snapshot.debian.org/package/dbus-glib/0.110-3/ -> no .asc
https://snapshot.debian.org/package/dbus-glib/0.110-4/ -> no .asc
https://snapshot.debian.org/package/dbus-glib/0.110-5/ -> it has a
different .asc file

Bug#982561: sympy breaks octave-symbolic autopkgtest: _PrintFunction' object has no attribute '__globals__'

[Paul Gevers]

Source: sympy, octave-symbolic
Control: found -1 sympy/1.7.1-1
Control: found -1 octave-symbolic/2.9.0-3
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of sympy the autopkgtest of octave-symbolic fails
in testing when that autopkgtest is run with the binary packages of
sympy from unstable. It passes when run with only packages from testing.
In tabular form:

   passfail
sympy  from testing1.7.1-1
octave-symbolicfrom testing2.9.0-3
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of sympy to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=sympy

https://ci.debian.net/data/autopkgtest/testing/amd64/o/octave-symbolic/10386993/log.gz

* test
 % matrix of symbols
 syms a b c d
 A = [a b; c d];
 assume A real
 assert (strcmp (assumptions (a), 'a: real'))
 assert (strcmp (assumptions (b), 'b: real'))
 assert (strcmp (assumptions (c), 'c: real'))
 assert (strcmp (assumptions (d), 'd: real'))
Symbolic pkg v2.9.0: Traceback (most recent call last):
  File "", line 28, in 
AttributeError: '_PrintFunction' object has no attribute '__globals__'
Closing the Python communications link.

! test failed
Python exception: AttributeError: '_PrintFunction' object has no
attribute '__globals__'
occurred in python_header import block.
Try "sympref reset" and repeat your command?
(consider filing an issue at https://github.com/cbm755/octsympy/issues)



OpenPGP_signature
Description: OpenPGP digital signature

Bug#938076: Bug#835340: Bug#938076: python-pymetar: Python2 removal in sid/bullseye

[gregor herrmann]

On Tue, 09 Feb 2021 19:56:10 +0100, Mattia Rizzolo wrote:

> > I don't feel confident uploading this NMU myself but I'd like to see
> > python-pymetar in bullseye.
> Very quickly looking at the filter diff for debian/*, that looks just
> fine.

Cool, thanks!
 
> But it's too late for bullseye.  Without an autopkgtest (which I'm not
> going to write myself not knowing the package), this will go over the
> 12th, and as such won't be due to the freeze policy.

Hm, right. Well, bad luck …
 
> > Is this something the Debian Python Team could take over?
> I'll keep a tab open to review and sponsor the nmu (but anybody feel
> free to beat me).

Thanks, much appreciated. 


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Simon and Garfunkel: Homeward Bound


signature.asc
Description: Digital Signature

Bug#982559: xscorch Build-Depends on libreadline-gplv2-dev which has been removed

[Paul Gevers]

Package: xscorch
Version: 0.2.1-1+nmu5
Severity: serious
Justification: FTBFS
User: trei...@debian.org
Usertags: edos-uninstallable

Hi,

libreadline-gplv2-dev has been removed from unstable [1]. Don't ask me
how that is possible as your package still Build-Depends on it, but it
happened. Please fix your package somehow, alternatives seem to be around.

Paul

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980504




OpenPGP_signature
Description: OpenPGP digital signature

Bug#966575: grub-pc: Bailing out if the boot device from the debconf database does not longer exist might produce a more complicated issue

[Daniel Leidert]

Hi Colin,

I recently stumbled into this issue myself. Reading your explanation was very
helpful. However the way you fixed it produces another issue as described here:

https://forum.openmediavault.org/index.php?thread/37903-grub-related-error-on-5-5-23-update/

The command suggested by the error message (dpkg-reconfigure) actually doesn't
work if grub-pc is not fully installed. I don't have a technical solution
myself, but bailing out creates an even worse situation here. Maybe instead of
bailing out print a warning instead?

I was also thinking: If this cannot be handled in a technical way this should
definitely be mentioned in the release notes.

Regards, Daniel
-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

If you like my work consider sponsoring me via
https://www.patreon.com/join/dleidert


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

Bug#981426: RM: cu2qu -- ROM; merged to fonttools

[Paul Gevers]

Hi Yao,

On Sun, 31 Jan 2021 07:07:43 +0800 Yao Wei =?utf-8?B?KOmtj+mKmOW7tyk=?=
 wrote:
> Please remove cu2qu from Debian.
> 
> This package has been merged to fonttools since 2020-03-31.  This
> package has no rdeps so it can be removed safely.

Huh?

Our migration software doesn't want to migrate the removal because it
would make multiple packages uninstallable. That's because
python3-fontmake and python3-ufo2ft Depends on python3-cu2qu.

trying: -cu2qu
skipped: -cu2qu (0, 0, 5)
got: 31+0: a-1:a-29:a-0:a-0:i-0:m-0:m-0:p-0:s-1
* arm64: design-desktop-graphics, fontmake, python3-fontmake,
python3-trufont, python3-ufo2ft, trufont

dak tells me the same, I'm surprised the package got removed.

So, Yao, what's the way forward for python3-fontmake and python3-ufo2ft?
Will fonttools provide python3-cu2qu?

Paul

elbrus@coccia:~$ dak rm --no-action -R --suite testing cu2qu
Will remove the following packages from testing:

 cu2qu |1.6.7-1 | source, all
python3-cu2qu | 1.6.7-1+b3 | amd64, arm64, armel, armhf, i386, mips64el,
mipsel, ppc64el, s390x

Maintainer: Debian Fonts Task Force 

--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
fontmake: python3-fontmake
ufo2ft: python3-ufo2ft

# Broken Build-Depends:
afdko: python3-cu2qu (>= 1.6.7)
fontmake: python3-cu2qu (>= 1.6.7)
ufo2ft: python3-cu2qu (>= 1.6.7)

Dependency problem found.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#982549: RFS: sanlock/3.8.2-2 -- Shared storage lock manager

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: sanlock
   Version : 3.8.2-2
   Upstream Author :
 * URL : https://www.pagure.io/sanlock/
 * License : GPL-2+, LGPL-2.1+
 * Vcs :
   Section : libs

It builds those binary packages:

  python3-sanlock - Python3 bindings to shared storage lock manager
  libsanlock-dev - Shared storage lock manager (development files)
  libsanlock1 - Shared storage lock manager (shared library)
  libsanlock-client1 - Shared storage lock manager (client library)
  sanlock - Shared storage lock manager

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/s/sanlock/sanlock_3.8.2-2.dsc

Changes since the last upload:

 sanlock (3.8.2-2) unstable; urgency=medium
 .
   * d/control: Drop Built-Using field, for Python3 package.
   * Move libraries and pkg-config to a multiarch location Closes: #980335
 Thanks to Helmut Grohne for patch.
   * Move Python example file to correct folder.
   * Change section for the binary package sanlock, from libs to utils.
   * Remove libblkid1 as build-dependency.

Regards,
Håvard

Bug#977132: python-pygal: diff for NMU version 2.4.0-2.2

[Adrian Bunk]

Control: tags 977132 + patch
Control: tags 977132 + pending

Dear maintainer,

I've prepared an NMU for python-pygal (versioned as 2.4.0-2.2) and 
uploaded it to DELAYED/14. Please feel free to tell me if I should 
cancel it.

cu
Adrian
diff -Nru python-pygal-2.4.0/debian/changelog python-pygal-2.4.0/debian/changelog
--- python-pygal-2.4.0/debian/changelog	2019-10-08 03:53:48.0 +0300
+++ python-pygal-2.4.0/debian/changelog	2021-02-11 20:52:21.0 +0200
@@ -1,3 +1,10 @@
+python-pygal (2.4.0-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream fix for FTBFS with pytest 6. (Closes: #977132)
+
+ -- Adrian Bunk   Thu, 11 Feb 2021 20:52:21 +0200
+
 python-pygal (2.4.0-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru python-pygal-2.4.0/debian/patches/0001-Fix-test-failures-due-to-removed-attribute-in-pytest.patch python-pygal-2.4.0/debian/patches/0001-Fix-test-failures-due-to-removed-attribute-in-pytest.patch
--- python-pygal-2.4.0/debian/patches/0001-Fix-test-failures-due-to-removed-attribute-in-pytest.patch	1970-01-01 02:00:00.0 +0200
+++ python-pygal-2.4.0/debian/patches/0001-Fix-test-failures-due-to-removed-attribute-in-pytest.patch	2021-02-11 20:52:21.0 +0200
@@ -0,0 +1,29 @@
+From 06d58181ff553e9b5c818256b379a336818b9a2f Mon Sep 17 00:00:00 2001
+From: Julien Sanchez 
+Date: Mon, 12 Oct 2020 15:05:43 +0200
+Subject: Fix test failures due to removed attribute in pytest
+
+Replace removed `funcargnames` attribute with newer `fixturenames`.
+---
+ pygal/test/conftest.py | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/pygal/test/conftest.py b/pygal/test/conftest.py
+index b8c8a59..21e2801 100644
+--- a/pygal/test/conftest.py
 b/pygal/test/conftest.py
+@@ -50,9 +50,9 @@ def pytest_generate_tests(metafunc):
+ if hasattr(sys, 'pypy_version_info'):
+ etree.to_etree()
+ 
+-if "Chart" in metafunc.funcargnames:
++if "Chart" in metafunc.fixturenames:
+ metafunc.parametrize("Chart", pygal.CHARTS)
+-if "datas" in metafunc.funcargnames:
++if "datas" in metafunc.fixturenames:
+ metafunc.parametrize(
+ "datas",
+ [
+-- 
+2.20.1
+
diff -Nru python-pygal-2.4.0/debian/patches/series python-pygal-2.4.0/debian/patches/series
--- python-pygal-2.4.0/debian/patches/series	2019-10-08 03:53:16.0 +0300
+++ python-pygal-2.4.0/debian/patches/series	2021-02-11 20:52:20.0 +0200
@@ -1 +1,2 @@
 setup.cfg-pytest.patch
+0001-Fix-test-failures-due-to-removed-attribute-in-pytest.patch

Bug#982558: ircd-hybrid: [INTL:de] updated German debconf translation

[Helge Kreutzmann]

Package: ircd-hybrid
Version: 1:8.2.38+dfsg.1-1
Severity: wishlist
Tags: patch l10n

Please find the updated German debconf translation for ircd-hybrid
attached.

Please place this file in debian/po/ as de.po for your next upload.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# translation of de.po to German
#
#Translators, if you are not familiar with the PO format, gettext
#documentation is worth reading, especially sections dedicated to
#this format, e.g. by running:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
#Some information specific to po-debconf are available at
#/usr/share/doc/po-debconf/README-trans
# or http://www.debian.org/intl/l10n/po-debconf/README-trans#
#Developers do not need to manually edit POT or PO files.
# Jens Nachtigall , 2004.
# Helge Kreutzmann , 2006, 2013, 2014, 2020, 2021.
#
msgid ""
msgstr ""
"Project-Id-Version: ircd-hybrid 1:8.2.38+dfsg.1-1\n"
"Report-Msgid-Bugs-To: ircd-hyb...@packages.debian.org\n"
"POT-Creation-Date: 2021-02-07 15:23+\n"
"PO-Revision-Date: 2021-02-11 20:45+0100\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=ISO-8859-15\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms:  nplurals=2; plural=(n != 1);\n"

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:2001
msgid "Restart ircd-hybrid on each upgrade?"
msgstr "Ircd-hybrid bei jedem Upgrade neu starten?"

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:2001
msgid ""
"Please choose whether the ircd-hybrid daemon should be restarted every time "
"a new version of this package is installed."
msgstr ""
"Bitte w�hlen Sie aus, ob der Ircd-hybrid-Daemon bei jeder Installation einer "
"neuen Version dieses Pakets neu gestartet werden soll."

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:2001
msgid ""
"Automatic restarts may be problematic if, for instance, the server is "
"running with manually loaded modules, which will need to be reloaded after "
"the restart."
msgstr ""
"Automatische Neustarts sind problematisch, falls beispielsweise der Server "
"mit manuell geladenen Modulen ausgef�hrt wird, die nach jedem Neustart neu "
"geladen werden m�ssen."

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:2001
msgid ""
"If you reject this option, you will have to restart ircd-hybrid via "
"\"service ircd-hybrid restart\" when needed."
msgstr ""
"Falls Sie diese Option ablehnen, m�ssen Sie Ircd-hybrid bei Bedarf neu "
"starten, indem Sie �service ircd-hybrid restart� eingeben."

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:3001
msgid "Automatically fix references to obsolete config options?"
msgstr ""
"Automatisch Referenzen zu veralteten Konfigurationsoptionen korrigieren?"

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:3001
msgid ""
"Several ssl configuration variables have been renamed to tls-like ones in "
"version 8.2.30, with some further changes to rename network_desc and "
"max_watch in 8.2.36, and dots_in_ident in 8.2.38. If enabled, the post-"
"installation script will attempt to automatically fix them before the server "
"is restarted. If not, and you have these options specified, the "
"configuration will become invalid, and server restart will fail."
msgstr ""
"Mehrere SSL-Konfigurationsvariablen wurden in Version 8.2.30 zu tls-artigen "
"umbenannt. In 8.2.36 erfolgten weitere �ndungen zur Umbenennung von "
"network_desc und max_watch und in 8.2.38 dots_in_ident. Falls aktiviert, wird 
das "
"Nachinstallationsskript versuchen, sie automatisch zu korrigieren, bevor der "
"Server neu gestartet wird. Falls nicht und Sie diese Optionen festgelegt "
"haben, wird die Konfiguration ung�ltig und der Server-Start wird "
"fehlschlagen."

#~ msgid "Upgrade ircd-hybrid to version without cryptlink support?"
#~ msgstr ""
#~ "Upgrade von Ircd-hybrid auf eine Version ohne Cryptlink-Unterst�tzung?"

#~ msgid ""
#~ "The 8.x version of ircd-hybrid includes a change to the way secure server "
#~ "links are implemented, which is not backwards-compatible with ircd-hybrid "
#~ "7.x, from which you are upgrading."
#~ msgstr ""
#~ "Die 8.x-Version von Ircd-Hybrid enth�lt eine �nderung bez�glich der Art, "
#~ "in der sichere Server-Verbindungen implementiert sind. Diese ist nicht "
#~ "mit Ircd-Hybrid 7.x, von der Sie ein Upgrade durchf�hren, kompatibel."

#~ msgid ""
#~ "If you have any secure server links (cryptlinks) configured with this "
#~ "server, you should plan to either upgrade all servers in lock-step, or "
#~ "temporarily configure non-cryptlink server links, to ensure the "
#~ "continuity of your IRC links."
#~ msgstr ""
#~ "Falls Sie f�r diesen Server irgendwelche sicheren 

Bug#982557: bsdextrautils: should not pre-depend on shared libraries

[Sven Joachim]

Package: bsdextrautils
Version: 2.36.1-7
Severity: normal

The bsdextrautils package is not essential, so it has no business to use
${shlibs:Depends} in Pre-Depends.  Please move that to the Depends field
instead.


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

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

Versions of packages bsdextrautils depends on:
ii  libc6  2.31-9
ii  libsmartcols1  2.36.1-7
ii  libtinfo6  6.2+20201114-2

bsdextrautils recommends no packages.

bsdextrautils suggests no packages.

-- no debconf information

Bug#982505: [Pkg-zfsonlinux-devel] Bug#982505: Bug#982505: zfsutils-linux: trim cronjob triggers "cannot trim" e-mails on spinning rust

[Colm Buckley]

I did have a quick look in the zpool trim code and it's a bit difficult to
achieve what is being suggested; that error is generated deep in libzfs not
in the mainline of the zpool command, so capturing it or declaring it
not-an-error with a flag would not be super clean. It's possible, but it
might not be quick.

Short-term fix; parse the output of 'zpool status -t' to figure out if any
devices support trim and only trim when there's at least one which does;
something like:

zpool status -tLP "$pool" | fgrep /dev/ | fgrep -qv 'trim unsupported' &&
zpool trim "$pool"

... but there might be corner cases which this doesn't catch.

Colm



On Thu, 11 Feb 2021 at 17:45, Christoph Biedl <
debian.a...@manchmal.in-ulm.de> wrote:

> Petter Reinholdtsen wrote...
>
> > Any idea how to figure out if trimming is possible/useful?
>
> Haven't checked, but in the meantime I figured a sane solution was
> something like Colm suggested: Have upstream modifiy the zpool command
> so - at least when providing an option like "--cron-mode" - it is silent
> as long as there is no error, and it considers that particular situation
> not an error. Then you could also remove the "|| true" again which has
> potential of hiding errors where it should not.
>
> Christoph
> ___
> Pkg-zfsonlinux-devel mailing list
> pkg-zfsonlinux-de...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-zfsonlinux-devel



-- 
Colm Buckley | c...@tuatha.org

Bug#982556: telegram-desktop: Check failed: (_thread_checker_)->IsCurrent()

[Nicholas Guriev]

Package: telegram-desktop
Version: 2.5.8+ds-1

Prerequisites:

1. Have no video camera or unplug it.
2. Our you may block access to the camera unmounting udev filesystem
inside a chroot environment.

Steps to reproduce:

1. Start the app.
2. Go to Settings > Advanced > Call settings.

What happens:

1. Telegram crashes with the following error message.

# Fatal error in: ./src/modules/audio_device/audio_device_buffer.cc, line 114
# last system error: 2
# Check failed: (_thread_checker_)->IsCurrent()
# Aborted (core dumped)


For work around this, do initialize WebRTC library in any way. For
example, make a non-zero duration call to someone or join a group call.
After that you can safely open the settings.


(process:41375): Telegram-WARNING **: 22:14:47.390: Unfortunately, GTK 
integration conflicts with qgtk2 platformtheme and style. Therefore, 
QT_QPA_PLATFORMTHEME and QT_STYLE_OVERRIDE will be unset.
Telegram-Message: 22:14:47.390: This can be ignored by setting 
TDESKTOP_I_KNOW_ABOUT_GTK_INCOMPATIBILITY environment variable to any value, 
however, if qgtk2 theme or style is used, this will lead to a crash.
Telegram-Message: 22:14:47.390: GTK integration can be disabled by setting 
TDESKTOP_DISABLE_GTK_INTEGRATION to any value. Keep in mind that this will lead 
to clipboard issues and tdesktop will be unable to get settings from GTK (such 
as decoration layout, dark mode & more).

(process:41375): Telegram-WARNING **: 22:14:47.391: Application has been built 
with foreign rlottie, animated emojis won't be colored to the selected pack.

(process:41375): Telegram-WARNING **: 22:14:47.391: Application was built 
without embedded fonts, this may lead to font issues.
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-builder'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-builder'
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
error: : cannot open
error: : cannot open
error: : cannot open
(device_info_linux.cc:45): NumberOfDevices
(audio_device_buffer.cc:65): AudioDeviceBuffer::ctor
(audio_device_buffer.cc:181): SetRecordingSampleRate(48000)
(audio_device_buffer.cc:187): SetPlayoutSampleRate(48000)
(audio_device_buffer.cc:201): SetRecordingChannels(1)
(audio_device_buffer.cc:207): SetPlayoutChannels(2)
(audio_device_buffer.cc:76): AudioDeviceBuffer::~dtor
(audio_device_buffer.cc:65): AudioDeviceBuffer::ctor
(audio_device_buffer.cc:181): SetRecordingSampleRate(48000)
(audio_device_buffer.cc:187): SetPlayoutSampleRate(48000)
(audio_device_buffer.cc:201): SetRecordingChannels(1)
(audio_device_buffer.cc:207): SetPlayoutChannels(2)
(audio_device_buffer.cc:76): AudioDeviceBuffer::~dtor
(audio_device_buffer.cc:65): AudioDeviceBuffer::ctor
(audio_device_buffer.cc:181): SetRecordingSampleRate(48000)
(audio_device_buffer.cc:187): SetPlayoutSampleRate(48000)
(audio_device_buffer.cc:201): SetRecordingChannels(1)
(audio_device_buffer.cc:207): SetPlayoutChannels(2)
(audio_device_buffer.cc:82): RegisterAudioCallback
ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
ALSA lib conf.c:4745:(_snd_config_evaluate) function snd_func_card_driver 
returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4745:(_snd_config_evaluate) function snd_func_concat returned 
error: No such file or directory
ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
ALSA lib conf.c:4745:(_snd_config_evaluate) function snd_func_refer returned 
error: No such file or directory
ALSA lib conf.c:5233:(snd_config_expand) Evaluate error: No such file or 
directory
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM default
AL lib: (EE) ALCcaptureAlsa_open: Could not open capture device 'default': No 
such file or directory
(webrtc_openal_adm.cpp:486): OpenAL Capture Device open failed, deviceID: 'ALSA 
Default'
(audio_device_buffer.cc:181): SetRecordingSampleRate(48000)
(audio_device_buffer.cc:201): SetRecordingChannels(1)
ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
ALSA lib conf.c:4745:(_snd_config_evaluate) function snd_func_card_driver 
returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4745:(_snd_config_evaluate) function snd_func_concat returned 
error: No such file or directory
ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
ALSA lib conf.c:4745:(_snd_config_evaluate) function snd_func_refer returned 
error: No such file or directory
ALSA lib conf.c:5233:(snd_config_expand) Evaluate error: No such file or 
directory
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM default
AL lib: (EE) ALCcaptureAlsa_open: Could not open capture device 'default': No 
such file or directory
(webrtc_openal_adm.cpp:486): OpenAL Capture Device open failed, deviceID: 'ALSA 
Default'


#
# Fatal error in: ./src/modules/audio_device/audio_device_buffer.cc, line 114
# last system error: 2

Bug#982555: mutt: Messages sent by Gmail SMTP are recorded in sent box with wrong charset/encoding

[Marcelo Luiz de Laia]

Package: mutt
Version: 2.0.5-1
Severity: minor

Dear Maintainer,

After upgrade to mutt:amd64 2.0.5-1, messages sent by gmail was recorded in
sent box with wrong charset, like this:

Finalizei a inser��o das ATA no Processo.
S�o seis ATA e um documento resumo.
Encaminhei ao Louren�o e Angelo para leitura e assinatura.
Fique � vontade para revisar.
Abra�os!

These messages have the headers:

Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

This is the same headers present in previous messages sent with mutt 2.0.2-1.

Thanks



-- Package-specific info:
Mutt 2.0.5 (2021-01-21)
Copyright (C) 1996-2021 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 5.10.0-2-amd64 (x86_64)
ncurses: ncurses 6.2.20201114 (compiled with 6.2)
libidn2: 2.3.0 (compiled with 2.3.0)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-6' 
--with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-10 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib 
--enable-libphobos-checking=release --with-target-system-zlib=auto 
--enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib 
--with-tune=generic 
--enable-offload-targets=nvptx-none=/build/gcc-10-Km9U7s/gcc-10-10.2.1/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-Km9U7s/gcc-10-10.2.1/debian/tmp-gcn/usr,hsa
 --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu 
--with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.1 20210110 (Debian 10.2.1-6) 

Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' 
'--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man' 
'--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--disable-option-checking' '--disable-silent-rules' 
'--libdir=\${prefix}/lib/x86_64-linux-gnu' '--runstatedir=/run' 
'--disable-maintainer-mode' '--disable-dependency-tracking' 
'--with-mailpath=/var/mail' '--enable-compressed' '--enable-debug' 
'--enable-fcntl' '--enable-hcache' '--enable-gpgme' '--enable-imap' 
'--enable-smtp' '--enable-pop' '--enable-sidebar' '--enable-dotlock' 
'--disable-fmemopen' '--with-curses' '--with-gnutls' '--with-gss' '--with-idn2' 
'--with-mixmaster' '--with-sasl' '--without-gdbm' '--without-bdb' 
'--without-qdbm' '--with-tokyocabinet' 'build_alias=x86_64-linux-gnu' 
'CFLAGS=-g -O2 -ffile-prefix-map=/build/mutt-kukaKk/mutt-2.0.5=. 
-fstack-protector-strong -Wformat -Werror=format-security' 
'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
-ffile-prefix-map=/build/mutt-kukaKk/mutt-2.0.5=. -fstack-protector-strong 
-Wformat -Werror=format-security

Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  +USE_SASL  +USE_GSS  +HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  +HAVE_FUTIMENS  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET  
+HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  -HAVE_LIBIDN  +HAVE_LIBIDN2  +HAVE_GETSID  
+USE_HCACHE  
+USE_SIDEBAR  +USE_COMPRESSED  +USE_INOTIFY  
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"
MIXMASTER="mixmaster"

To contact the developers, please mail to .
To report a bug, please contact the Mutt maintainers via gitlab:
https://gitlab.com/muttmua/mutt/issues


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable'), (500, 

Bug#977637: libwebsockets: Please enable LWS_WITH_EXTERNAL_POLL support in libwebsockets

[GCS]

On Wed, Feb 10, 2021 at 7:01 PM Roger Light  wrote:
> On Wed, 10 Feb 2021 at 16:49, László Böszörményi (GCS)  
> wrote:
> > It was always a hack, few people used it and generated way too many 
> > messages.
> Which part of this is hacky?
[...]
> > You had two years (maybe more) to switch to a better alternative of
> > the hacky external poll support but only now realize your code is not
> > complete without it. :(
>
> I just fundamentally disagree that it's a hacky solution, and I don't
> see how anybody could say that it is.
 The code is not written by me and its coder states so [1]. I can
override upstream and enable it for you - let's see how that goes.

Regards,
Laszlo/GCS
[1] https://github.com/warmcat/libwebsockets/issues/1841#issuecomment-583261092

Bug#982554: dpkg: dpkg-deb fails to extract package contents on FAT32 devices

[Jan Luca Naumann]

To add some data for your information:

# dpkg -D100 --install
/var/cache/apt/archives/linux-image-5.10.0-3-amd64_5.10.13-1_amd64.deb
(Reading database ... 370596 files and directories currently installed.)
Preparing to unpack .../linux-image-5.10.0-3-amd64_5.10.13-1_amd64.deb ...
Unpacking linux-image-5.10.0-3-amd64 (5.10.13-1) over (5.10.12-1) ...
D000100: setupvnamevbs main='/.' tmp='/..dpkg-tmp' new='/..dpkg-new'
D000100: tarobject already exists
D000100: tarobject directory exists
D000100: setupvnamevbs main='/boot' tmp='/boot.dpkg-tmp'
new='/boot.dpkg-new'
D000100: tarobject already exists
D000100: tarobject directory exists
D000100: setupvnamevbs main='/boot/System.map-5.10.0-3-amd64'
tmp='/boot/System.map-5.10.0-3-amd64.dpkg-tmp'
new='/boot/System.map-5.10.0-3-amd64.dpkg-new'
D000100: tarobject already exists
D000100: tarobject file open size=83
D000100: tarobject file hash=e0a6c09212a19ed48183a052eab847e7
D000100: tarobject nondirectory, 'link' backup
dpkg: error processing archive
/var/cache/apt/archives/linux-image-5.10.0-3-amd64_5.10.13-1_amd64.deb
(--install):
 unable to make backup link of './boot/System.map-5.10.0-3-amd64' before
installing new version: Operation not permitted
D000100: setupvnamevbs main='/boot/System.map-5.10.0-3-amd64'
tmp='/boot/System.map-5.10.0-3-amd64.dpkg-tmp'
new='/boot/System.map-5.10.0-3-amd64.dpkg-new'
D000100: cu_installnew not restoring
D000100: secure_remove '/boot/System.map-5.10.0-3-amd64.dpkg-new' unlink OK
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/linux-image-5.10.0-3-amd64_5.10.13-1_amd64.deb


# ln System.map-5.10.0-3-amd64 System.map-5.10.0-3-amd64.bak
ln: failed to create hard link 'System.map-5.10.0-3-amd64.bak' =>
'System.map-5.10.0-3-amd64': Operation not permitted


# mount | grep boot
/dev/sda1 on /boot type vfat
(rw,noatime,nodiratime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)

On Thu, 11 Feb 2021 20:04:39 +0100 Jan Luca Naumann
 wrote:
> Package: dpkg
> Version: 1.20.7.1
> Severity: important
> 
> On EFI computer it is possible to use the ESP partition directly as
> /boot. But dpkg has problems to upgrade packages, e.g. the linux-image
> packages, then since it tries to create hardlinks as backup of existing
> files. This is not supported for FAT32 partitions.
> 
> dpkg should include some check if the target device systems may not
> support hard links so /boot on FAT32 is supported.

Bug#980370: spirv-tools: shared library should be packaged like a shared library

[Simon McVittie]

On Thu, 11 Feb 2021 at 14:33:37 +0200, Timo Aaltonen wrote:
> Uh, the shared lib was supposed to be disabled in 2020.3-1, but looks like
> the build option broke since. But 2020.6 now has this merged:
> 
> https://github.com/KhronosGroup/SPIRV-Tools/pull/3910
> 
> which should allow building a proper shared lib, but still without
> versioning. I wonder what to do for bullseye, maybe force static like it's
> supposed to be and be happy for now?

I think the first thing to do is to disable (or just not install!) the
shared library. That doesn't need a trip through NEW and should be
straightforward; it would be good if that change can be included in
bullseye.

https://codesearch.debian.net/search?q=SPIRV-Tools-shared=1
seems to indicate that nothing depends on SPIRV-Tools-shared yet.
All the search hits are in packages that bundle a copy of SPIRV-Tools,
except for vkd3d which only links to the shared library if you enable an
option that Debian apparently doesn't, and mojoshader, which is more
complicated.

mojoshader doesn't *seem* to have a runtime dependency on
libSPIRV-Tools-shared, but it checks for the -shared pkg-config data,
so it might accidentally FTBFS after disabling the shared library -
but it has a popcon score of 3 and nothing depends on it, so I don't
think you should necessarily feel guilty about breaking it?

The long-term solution is to teach upstream how SONAMEs work (I already
tried on ,
but it seems to be a slow process); and then when that has happened,
package the library according to Policy (libspirv-tools-dev and
libspirv-tools0, or similar) and go through NEW.

smcv

Bug#982516: mricron: FTBFS [arm64, mips64el]

[Juhani Numminen]

Control: retitle -1 mricron: FTBFS [arm64, ppc64el]

On Thu, 11 Feb 2021 08:55:08 +0200 Juhani Numminen  
wrote:
> mricron FTBFS on arm64 and mips64el.
Sorry, arm64 and ppc64el. I got the *64el's mixed up.

https://buildd.debian.org/status/package.php?p=mricron

Bug#982353: contrib/testing64 crashes on Vbox 6.1 when updated to kernel 5.10 due to deprecated use of graphic card

[Emmanuel Kasper]

Le 11/02/2021 à 19:26, Francesco P. Lovergine a écrit :
> On Thu, Feb 11, 2021 at 06:15:24PM +0100, Emmanuel Kasper wrote:
>> if testing64 is working so far, including with the kernel of your
>> choice, should we close this bug report ?
>>
> 
> Well, in any case I would add a doc note about the vbox graphic
> controller deprecation in 6.1 that could cause issues with current
> stable kernel. It couuld be not so evident for headless installations
> and solve a lots of headaches.

hum I could not actually reproduce the issue with VMSVGA, so I would say
the problem probably came because of the out of tree dkms module brought
by the vagrant vbguest plugin

testing:
vagrant ssh -- uname -srm
Linux 5.10.0-3-amd64 x86_64
vagrant ssh -- lspci | grep VGA
00:02.0 VGA compatible controller: VMware SVGA II Adapter

works fine

buster:
vagrant ssh -- uname -srm
Linux 4.19.0-8-amd64 x86_64

vagrant ssh -- lspci | grep VGA
00:02.0 VGA compatible controller: VMware SVGA II Adapter

works fine too

I made an issue in import2vbox to change the default graphic (I did not
notice the warning in the GUI until you mentioned it
https://github.com/EmmanuelKasper/import2vbox/issues/2



-- 
You know an upstream is nice when they even accept m68k patches.
  - John Paul Adrian Glaubitz, Debian OpenJDK maintainer

Bug#982554: dpkg: dpkg-deb fails to extract package contents on FAT32 devices

[Jan Luca Naumann]

Package: dpkg
Version: 1.20.7.1
Severity: important

On EFI computer it is possible to use the ESP partition directly as
/boot. But dpkg has problems to upgrade packages, e.g. the linux-image
packages, then since it tries to create hardlinks as backup of existing
files. This is not supported for FAT32 partitions.

dpkg should include some check if the target device systems may not
support hard links so /boot on FAT32 is supported.


-- Package-specific info:
System tainted due to merged-usr-via-aliased-dirs.

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

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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-9
ii  liblzma5 5.2.5-1.0
ii  libselinux1  3.1-2+b2
ii  tar  1.32+dfsg-1
ii  zlib1g   1:1.2.11.dfsg-2

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.1.20
pn  debsig-verify  

-- no debconf information

Bug#982270: linux: [armhf] several imx6 systems unable to detect ethernet

[Vagrant Cascadian]

Control: reassign 982270 linux
Control: retitle 982270 linux: [armhf] several imx6 systems unable to detect 
ethernet
Control: found 982270 5.10.13-1

On 2021-02-07, Rick Thomas wrote:
> It booted fine but when it got to the "Detect network hardware" phase, 
> it failed and said:
>
>> No Ethernet card was detected. If you know the name of the driver 
>> needed by your Ethernet card, you can select it from the list. 
>> Driver needed by your Ethernet card:  

I can confirm this is an issue on hummingboard-i2ex, cubox-i4x4 and
wandboard quad, all of which are similar imx6 systems, and all of which
use the SoC's gigabit ethernet interface.

I've had better luck with linux 5.9.x and 4.19.x versions, although
possibly backported patches on the stable branches may also trigger
similar issues, just not consistantly. 5.10.x seems to consistantly
result in no working ethernet interface.

Marked as found in 5.10.13-1, but I believe this affects all 5.10.x
versions I have seen.

Possibly related to changes to the mdio interface infrastructure, but
this pretty much needs someone to able take the time to git bisect and
boot test the issue...


live well,
  vagrant


> ==
> Installer hardware-summary:
> ==
> uname -a: Linux cube 4.19.0-13-armmp #1 SMP Debian 4.19.160-2 (2020-11-28) 
> armv7l GNU/Linux
> usb-list: 
> usb-list: Bus 01 Device 01: EHCI Host Controller [1d6b:0002]
> usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 
> 01
> usb-list:Manufacturer: Linux 4.19.0-13-armmp ehci_hcd
> usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
> usb-list: 
> usb-list: Bus 02 Device 01: EHCI Host Controller [1d6b:0002]
> usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 
> 01
> usb-list:Manufacturer: Linux 4.19.0-13-armmp ehci_hcd
> usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
> lsmod: Module  Size  Used by
> lsmod: dm_mod122880  9
> lsmod: md_mod143360  0
> lsmod: jfs   184320  0
> lsmod: btrfs1241088  0
> lsmod: libcrc32c  16384  1 btrfs
> lsmod: xor16384  1 btrfs
> lsmod: zstd_decompress61440  1 btrfs
> lsmod: zstd_compress 159744  1 btrfs
> lsmod: xxhash 20480  2 zstd_compress,zstd_decompress
> lsmod: zlib_deflate   28672  1 btrfs
> lsmod: raid6_pq   98304  1 btrfs
> lsmod: vfat   24576  0
> lsmod: fat73728  1 vfat
> lsmod: ext4  618496  3
> lsmod: crc16  16384  1 ext4
> lsmod: mbcache16384  1 ext4
> lsmod: jbd2  102400  1 ext4
> lsmod: crc32c_generic 16384  6
> lsmod: fscrypto   28672  1 ext4
> lsmod: ecb16384  0
> lsmod: brcmfmac  253952  0
> lsmod: brcmutil   16384  1 brcmfmac
> lsmod: cfg80211  548864  1 brcmfmac
> lsmod: rfkill 28672  1 cfg80211
> lsmod: usb_storage53248  0
> lsmod: sd_mod 49152  3
> lsmod: ahci_imx   20480  2
> lsmod: libahci_platform   20480  1 ahci_imx
> lsmod: libahci32768  2 libahci_platform,ahci_imx
> lsmod: libata208896  3 libahci_platform,libahci,ahci_imx
> lsmod: scsi_mod  196608  3 sd_mod,usb_storage,libata
> lsmod: sdhci_esdhc_imx24576  0
> lsmod: sdhci_pltfm16384  1 sdhci_esdhc_imx
> lsmod: sdhci  53248  2 sdhci_pltfm,sdhci_esdhc_imx
> lsmod: ci_hdrc_imx16384  0
> lsmod: ci_hdrc45056  1 ci_hdrc_imx
> lsmod: ulpi   16384  1 ci_hdrc
> lsmod: ehci_hcd   77824  1 ci_hdrc
> lsmod: udc_core   36864  1 ci_hdrc
> lsmod: usbcore   221184  4 usb_storage,ehci_hcd,brcmfmac,ci_hdrc
> lsmod: usbmisc_imx16384  1 ci_hdrc_imx
> lsmod: imxdrm 28672  0
> lsmod: anatop_regulator   16384  1
> lsmod: phy_mxs_usb16384  2
> lsmod: dw_hdmi_imx16384  0
> lsmod: dw_hdmi36864  1 dw_hdmi_imx
> lsmod: imx_ipu_v3 94208  1 imxdrm
> lsmod: cec49152  1 dw_hdmi
> lsmod: drm_kms_helper147456  2 dw_hdmi,imxdrm
> lsmod: drm   356352  5 
> imx_ipu_v3,dw_hdmi,dw_hdmi_imx,imxdrm,drm_kms_helper
> lsmod: at803x 16384  1
> df: Filesystem   1K-blocks  Used Available Use% Mounted on
> df: none20627656206220   0% /run
> df: devtmpfs   1010736 0   1010736   0% /dev
> df: /dev/mapper/ncube--vg-root
> df:   19092136769744  17329524   4% /target
> df: /dev/sda1   482922 31992425996   7% /target/boot
> df: 

Bug#979426: marked as done (missing linux-headers-amd64 prevents running dkms when kernel is updated in debian/contrib-testing64)

[Willy nilly]

close #979426

On Thu, Feb 11, 2021 at 5:36 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Thu, 11 Feb 2021 18:34:20 +0100
> with message-id 
> and subject line
> has caused the Debian Bug report #979426,
> regarding missing linux-headers-amd64 prevents running dkms when kernel is
> updated in debian/contrib-testing64
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 979426: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979426
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Francesco Paolo Lovergine 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Wed, 06 Jan 2021 16:42:28 +0100
> Subject: missing linux-headers-amd64 prevents running dkms when kernel is
> updated in debian/contrib-testing64
> Package: cloud.debian.org
> Severity: normal
>
> While upgrading the current debian/current-testing64 (half of 2020) under
> virtualbox provider:
>
> [...]
> /etc/kernel/postinst.d/dkms:
> dkms: running auto installation service for kernel 5.9.0-5-amd64:Error!
> Your kernel headers for kernel 5.9.0-5-amd64 cannot be found.
> Please install the linux-headers-5.9.0-5-amd64 package,
> or use the --kernelsourcedir option to tell DKMS where it's located
> [...]
>
> That's due to 5.6 -> 5.9 migration and missing of linux-headers-amd64
> package apparently.
>
> -- System Information:
> Debian Release: 10.7
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'stable-updates')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-13-amd64 (SMP w/8 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8),
> LANGUAGE=it_IT.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
>
>
> -- Forwarded message --
> From: Emmanuel Kasper 
> To: 979426-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Thu, 11 Feb 2021 18:34:20 +0100
> Subject:
> the latest testing64 released box should fix this issue

Bug#982085: Usage of language specific profiles in build dependencies

[Thorsten Glaser]

Hi Paul,

> FTBFS) but it avoids busywork for maintainers that are not involved in
> bootstrapping java. Machine time is cheap, volunteer time is not.

this is not for bootstrapping. This is to prevent building of language
bindings for e.g. Java on platforms where there is simply no Java.
This is a standard application for packages with optional language
bindings and must not lead to a build failure.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in
Form von Beratung, Trainings sowie Workshops in den Bereichen
Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung
sowie Agile Organisation.

Besuchen Sie uns auf https://www.tarent.de/consulting .
Wir freuen uns auf Ihren Kontakt.

*

Bug#977067: Bug#977060: cwltool FTBFS with pytest 6

[Étienne Mollier]

Control: retitle -1 igdiscover: test suite flaky, possibly on high core count 
machines
Control: severity -1 important
Control: tag -1 confirmed

Hi Christian, Hi Nilesh,

Christian Kastner, on 2021-02-11 15:46:16 +0100:
> On 11.02.21 15:20, Nilesh Patra wrote:
> > According to last reproducible build result[1] shows that it is building 
> > successfully on January 31, 2021 (~52 days after this bug was reported)
> > However there are a few FTBFS entries in there as well. So probably this is 
> > an occasional failure?
> > 
> > [1]: 
> > https://tests.reproducible-builds.org/debian/history/amd64/igdiscover.html
> 
> I tried N=1 build, and this time it succeeded.
> 
> But Nilesh is right, reproducible builds failed occasionally, with the
> errors as I reported above. It looks as if some of the tests are flaky.

Thanks for your observations.  The test suite stubbornly
succeeds on my six cores equipment.  I see failures on amd64 and
arm64 machines in reproducible builds reports.  If I'm right,
those hosts may have notoriously high cores count (>100).

The issue might be caused by a race to read/write test data, or
something more subtle.  I would guess a path of least resistance
would be to drop parallelization, at least for the test suite.
I'm afraid I'm not having an appropriate configuration to wrap
up a fix and test that kind of issues at the moment.

> Now, because these failures are not a pytest issue, I don't think this
> bug is valid any longer -- pytest 6 compatibility was the goal, and it
> is present.
> 
> Please feel free to downgrade and retitle for the flakiness issue.

Thanks, the bug meta-informations should be accurate now, modulo
typos.

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


signature.asc
Description: PGP signature

Bug#949959: marked as done (debcargo.toml should make it possible to declare additional dependencies for generated autopkgtests)

[Willy nilly]

close #949959

On Thu, Feb 11, 2021 at 5:57 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Thu, 11 Feb 2021 17:53:02 +
> with message-id <6e199c0c-947d-2372-5894-773000aca...@p10link.net>
> and subject line re: debcargo.toml should make it possible to declare
> additional dependencies for generated autopkgtests
> has caused the Debian Bug report #949959,
> regarding debcargo.toml should make it possible to declare additional
> dependencies for generated autopkgtests
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 949959: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949959
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Daniel Kahn Gillmor 
> To: sub...@bugs.debian.org
> Cc:
> Bcc:
> Date: Mon, 27 Jan 2020 11:55:28 -0500
> Subject: debcargo.toml should make it possible to declare additional
> dependencies for generated autopkgtests
> Package: debcargo
> Version: 2.4.2-1
> Control: block 947709 with -1
> Control: affects -1 + src:rust-clang-sys
>
> Debcargo populates the Depends: fields of its autopkgtests with
> dev_depends (see line 516 of src/debian/mod.rs, in the creation of a
> new PkgTest object).
>
> However, some tests (like rust-clang-sys, see #947709) require some
> extra dependencies because they test some recommended-but-not-universal
> mechanism of the source package.
>
> So it would be good to be able to indicate in debcargo.toml some
> additional autopkgtest dependencies.
>
> Simplest might be to add a dependency for *all* generated autopkgtests,
> but i can imagine there are some subtler requirements which will need to
> be for specific autopkgtests in the future.
>
>--dkg
>
>
>
> -- Forwarded message --
> From: peter green 
> To: 949959-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Thu, 11 Feb 2021 17:53:02 +
> Subject: re: debcargo.toml should make it possible to declare additional
> dependencies for generated autopkgtests
> Version: 2.4.4-1
>
> A feature was added to allow specifying of extra test dependencies in
> debcargo 2.4.4
>
> See https://salsa.debian.org/rust-team/debcargo/-/merge_requests/24 for
> details
> (the final syntax differs from what is described in this bug report)

Bug#982353: contrib/testing64 crashes on Vbox 6.1 when updated to kernel 5.10 due to deprecated use of graphic card

[Francesco P. Lovergine]

On Thu, Feb 11, 2021 at 06:15:24PM +0100, Emmanuel Kasper wrote:
if testing64 is working so far, including with the kernel of your 
choice, should we close this bug report ?




Well, in any case I would add a doc note about the vbox graphic controller 
deprecation in 6.1 that could cause issues with current stable kernel. It 
couuld be not so evident for headless installations and solve a lots of 
headaches.


--
Francesco P. Lovergine

Bug#982553: python3-aalib: ABI mismatch on amd64

[Celelibi]

Package: python3-aalib
Version: 0.3.2-4
Severity: normal

Dear Maintainer,

It looks like there's an ABI mismatch between the structure layout
declared in the python code and the actual layout.

It causes python to allocate less memory than needed by the C library.
On rare occasions, the uninitialized field gets a non-zero value, which
produce weird behaviors.

Specifically, the struct fields of aa_hardware_params and
aa_render_params are only aligned on 4 bytes on i386 when compiled with
gcc. Not on x64 or any other architecture as far as I can tell.

When reading the beginning of aalib.h we can see:

/* The -malign-double switch changes binarry compatibility with structures
   containing floating point values.  To avoid this, set alignment manually
   to old value.  */

#ifdef __GNUC__
#ifdef __i386__
#define __AA_ALIGN __attribute__ ((__aligned__ (4)))
#define __AA_NOALIGN __attribute__ ((__packed__))
#endif
#endif


Which shows explicitely that the struct fields are only aligned or
packed on i386. Given the specificity of the condition and the comment
above, my guess would be that this was made only to prevent an ABI
breakage when upgrading gcc, and not a general definition.

Therefore I think that the _pack_ = 4 attribute when declaring the
structures is too strict.

class HardwareSettings(Structure):
_pack_ = 4
_fields_ = [
# ...
]


Although I have no clue how to detect it, this should probably be set
only for the 32 bits builds on intel-compatible platforms (only when
__i386__ is set). Note that 32 bits systems can be installed on 64 bits
hardware, and 32 bits builds of python can be installed in 64 bits
debian systems. So it should really be the ELFCLASS of the library that
should be tested, neither the architecture of the hardware nor the
debian arch.


On the other hand, maybe an easier fix would be to have a more
consistent ABI on the aalib side? Although this would mean bumping the
ABI version and possibly breaking many packaged, this might be the best
long-term solution. If you think so, feel free to reassign this bug
report as needed.



Best regards,
Celelibi


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

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

Versions of packages python3-aalib depends on:
ii  libaa1   1.4p5-48
ii  python3  3.9.1-1

python3-aalib recommends no packages.

Versions of packages python3-aalib suggests:
ii  python3-pil  8.1.0-1

-- no debconf information

Bug#982283: override: bsdmainutils:oldlibs/optional

[Chris Hofstaedtler]

* Samuel Thibault  [210211 00:56]:
> As I mentioned previously in the bug, bsdutils (required) recommends
> bsdextrautils, so for that part things don't change.
> 
> For calendar and cal/ncal, the question indeed holds. For bsdmainutils
> maintainers: I guess the goal of splitting them out of bsdmainutils was
> precisely to not install them by default?

There were two goals:

1) for bsdmainutils delegate most things to util-linux (for various
reasons). This was done by moving the utilities to bsdextrautils
(from util-linux).

2) util-linux has the goal of making users "not pay" for tools they
do not need. That was achieved by putting the tools into
bsdextrautils and not into, say, bsdutils. The idea was that the
tools would still be there "on a normal install" (however that is
defined, ...), but not on minimal installs.

Maybe bsdextrautils should be prio standard then?
(I don't know exactly how d-i decides what to install for
"standard system".)

Thanks,
Chris