Bug#986268: Should be in non-free, not main; no source code

[Josh Triplett]

Package: firmware-ast
Version: 20140808-1
Severity: serious
X-Debbugs-Cc: j...@joshtriplett.org

firmware-ast is binary-only firmware. The "source code" appears to
consist of a C header file containing a hex dump of a binary, and a
makefile transforming the hex dump into binary.

The previous package, xserver-xorg-video-ast, had a similar bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941077 .

Bug#986267: xfce4-appfinder: Application Finder doesn't show up xfce4's "Add New Items" window

[Ron Murray]

Package: xfce4-appfinder
Version: 4.16.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

   I noticed "Application Finder" in a Debian Live build I'd made, and
wondered why I'd never seen it on my normal Debian box. So I tried to
add it with xfce4's "Add New Items" option, but it doesn't show up
there.

   I tried reinstalling the package, but it made no difference.

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

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

Versions of packages xfce4-appfinder depends on:
ii  libc62.31-10
ii  libgarcon-1-04.16.1-1
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-3
ii  libxfce4ui-2-0   4.16.0-1
ii  libxfce4util74.16.0-1
ii  libxfconf-0-34.16.0-2

xfce4-appfinder recommends no packages.

xfce4-appfinder suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJCBAEBCgAsFiEETZlw4yMXM0sUHntjEvfoZbXi52EFAmBmpEEOHHJqbXhAcmpt
eC5uZXQACgkQEvfoZbXi52F04xAArMNAHq2ONetNwTnDYDUUD7C8YkpJnU5JQKgu
Q+pFhqfZlBHLFceslYTOIFS8OoBNJxmZJuD7qaRe0eDz6J/RGvOyS8lCAaNi4rla
Es+U9Qs6wsTupbyD7+fr4ysYXVteasaLUBtU6nKjTKmVnvyNEDnSCJQ9LnVg9Z+O
FazZhvQmdzWjL3wo3zRc98s39Ss5Q2QhShNXIxFTal7jiUKKW1SAfOosCEAaeL+6
oBFSXT05+LvGQkrLD9+08t2TvOaO11SxIA5tVVPAI7tfRZL0BNHDKazIWi6grMDT
bwMQmG4b6VndliKnlIAlpQbgwmAuvgQ0uo2Sb3nCBP7PfyANuanxBE4LGS+9LrDO
pbuR1hNDOgX9kXmgfNhkyQIjd1SWpUTk7TuuOHVidrZI0GON1ACNWHgqThNEeOrH
86PyAJ/SIvuKCLdYFaXnjfEOwV3ISrdapTMANX4pHKLocCUOFepzmLmpOPbizPwr
aHS6L6q6kCq6h4Gtm3FXYP0b1zo8W5aFof+B1IynTIFNo5UZQE7z1nI5Nda7V+B5
SbZ2NUVdgYG8sJu2EzRHtnAvVQpAIFYixfqIeBaa6B1R3HGuD+F12QlhaL5InBsC
yhPqf9yuA0AZ8QyQUIBAs0BLCrHEZYXRhZv6Rf3mAJiCq+YohIL1MLYJZaxMFkOv
DP2rsR4=
=1xzi
-END PGP SIGNATURE-

Bug#986266: RFS: golang-github-mholt-acmez/0.1.3-1 [ITP] -- Premier ACME client library for Go (library)

[Ganesh Pawar]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "golang-github-mholt-acmez":

* Package name : golang-github-mholt-acmez
Version : 0.1.3-1
Upstream Author : Matthew Holt
* URL : https://github.com/mholt/acmez
* License : Apache-2.0
* Vcs : https://salsa.debian.org/go-team/packages/golang-github-mholt-acmez
Section : devel

It builds those binary packages:

golang-github-mholt-acmez-dev - Premier ACME client library for Go (library)

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


https://mentors.debian.net/package/golang-github-mholt-acmez/

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

dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-github-mholt-acmez/golang-github-mholt-acmez_0.1.3-1.dsc


Changes for the initial release:

golang-github-mholt-acmez (0.1.3-1) UNRELEASED; urgency=medium
.
* Initial release (Closes: #985878)

Regards,
Ganesh Pawar



OpenPGP_signature
Description: OpenPGP digital signature

Bug#986264: db.c: add information for the compiler to make analyzing execution paths easier

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 809b3aa962b341be1f9c047bf8c6e2279730239d Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Fri, 2 Apr 2021 02:35:40 +
>Subject: [PATCH] db.c: Add information for the compiler to make analyzing
> execution paths easier

  The compiler option "-fanalyzer" shows:

db.c:1239:12: warning: leak of '' [CWE-401] [-Wanalyzer-malloc-leak]
 1239 | grplist[count] = NULL;
  |^
...
   | 1151 | if (actfp == NULL) {
   |  |~
   |  ||
   |  |(10) following 'true' branch (when 'actfp' is 
NULL)...
   | 1152 |  nn_exitmsg(1, "could not open .newsrc file %s\n", 
newsrc_file);
   |  |  
~~
   |  |  |
   |  |  (11) ...to here
   |..
   | 1165 | if (nntp_debug) {

Signed-off-by: Bjarni Ingi Gislason 
---
 db.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/db.c b/db.c
index 90221d0..c55fa3f 100644
--- a/db.c
+++ b/db.c
@@ -1216,6 +1216,9 @@ readpartactfile(void)
 if (grplist == NULL) {
nn_exitmsg(1, "can't create active or group list (%d entries)\n",
   count + 1);
+/* Give the compiler the information that the program exits with the
+   previous command */
+   exit(1);
 }
 
 /*
-- 
2.30.2



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

Kernel: Linux 5.10.24-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#948875: ignore-me: FTBFS: dh: unable to load addon python3

[Logan Rosen]

Control: tags -1 patch

Hi,

In Ubuntu, the attached patch was applied to achieve the following:

  * Build-depend on dh-python to fix FTBFS.

Thanks for considering the patch.

Logan
diff -Nru ignore-me-0.1.2/debian/control ignore-me-0.1.2/debian/control
--- ignore-me-0.1.2/debian/control  2017-12-16 03:00:06.0 -0500
+++ ignore-me-0.1.2/debian/control  2021-04-01 22:34:48.0 -0400
@@ -2,7 +2,7 @@
 Section: utils
 Priority: optional
 Maintainer: Sascha Manns 
-Build-Depends: debhelper (>= 10), python3-all, xsltproc, itstool, docbook-xsl, 
docbook-xml
+Build-Depends: debhelper (>= 10), python3-all, xsltproc, itstool, docbook-xsl, 
docbook-xml, dh-python
 Standards-Version: 4.1.3
 Homepage: https://launchpad.net/ignore-me
 Vcs-Git: https://git.launchpad.net/ignore-me

Bug#986263: db.c: move declaration of "*p" outside of a "while" and "if" construct

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 3dfc43b569d405086b9c8affe32660ffa621cc32 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Fri, 2 Apr 2021 01:56:54 +
>Subject: [PATCH] db.c: move declaration of "*p" outside of a "while" and "if"
> construct

  The compiler reported:

db.c: In function 'readtimfile':
db.c:1428:11: warning: unused variable 'p' [-Wunused-variable]
 1428 |   char   *p = NULL;
  |   ^
db.c:1431:11: warning: unused variable 'p' [-Wunused-variable]
 1431 |   char   *p = strchr(line, ' ');
  |   ^
db.c:1433:6: error: 'p' undeclared (first use in this function)
 1433 |  if (p == NULL)
  |  ^

Signed-off-by: Bjarni Ingi Gislason 
---
 db.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/db.c b/db.c
index 257ee5c..90221d0 100644
--- a/db.c
+++ b/db.c
@@ -1415,6 +1415,7 @@ readtimfile(void)
 
 tprintf("Reading the \"active.times\" file ... ");
 fflush(stdout);
+char *p;
 #ifdef NNTP
 while (use_nntp ? nntp_fgets(timline, sizeof timline)
   : fgets(timline, sizeof timline, timfp))
@@ -1425,10 +1426,10 @@ readtimfile(void)
 {
char   *line = strkeep(timline, 0, POOL_TIM);
if (line == NULL) {
-   char   *p = NULL;
+   p = NULL;
}
else {
-   char   *p = strchr(line, ' ');
+   p = strchr(line, ' ');
}
if (p == NULL)
continue;
-- 
2.30.2



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

Kernel: Linux 5.10.24-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#986213: RM: ansible/2.9.16+dfsg-1.1

[Lee Garrett]

Hi Bas,

On 31/03/2021 20:20, Sebastiaan Couwenberg wrote:
> On 3/31/21 7:30 PM, Lee Garrett wrote:
>> Unfortunately 2.10 didn't make it into bullseye in time (#984557). I tried
>> getting the unit tests from 2.9.16 to work with python 3.9, but I had to give
>> up. I don't feel comfortable with maintaining such a large package over the
>> lifecycle of bullseye without unit tests, official py3.9 support, and 
>> security
>> support running out in a few months, so please remove ansible from bullseye.
> 
> Shipping bullseye without ansible is going to make many users unhappy.
> 
> Will you actively maintain the package in bullseye-backports instead?

Up until now Pierre-Elliott Bécue has provided versions for backports,
and I'm happy to regulary upload ansible to backports, too.

However, ansible has a somewhat active deprecation cycle for
modules/features, meaning that backports users will be forced to adapt
their playbooks and roles with every feature release to avoid breakage.
Adding to this, there have been times where ansible in testing/unstable
was broken for a while due to moving python packages (the month long
breakage due to jinja2 which broke templating in many ansible modules
comes to mind).

So I don't think those users who have previously depended on ansible
from stable will be happy with using ansible from backports.

I can only say that I screwed up the migration process due to making a
few wrong assumptions about the finer details of the freeze process, and
I'm somewhat embarrassed about causing the release team additional work.
I had been working on packaging ansible 2.10 since December, and my
intention was to get ansible 2.10 into bullseye. Had I known what I know
now, I would have set my personal deadline differently, or raised the
issue with the release team earlier.

Those things said, I agree with Raphaël that ansible 2.10 is a good fit
for bullseye, and I'd maintain it over the life cycle of our next
release if the release team chooses to unblock it.

Kind regards,
Lee

Bug#986262: emacs-nox: Quitting emacs just after starting it can send data to the command line

[Vincent Lefevre]

Package: emacs-nox
Version: 1:26.1+1-3.2+deb10u2
Severity: normal

I started emacs from xterm (via a ssh session) on some text file and
quitted it with C-x C-c almost immediately. As a result, I got

^[]11;rgb://^[\%

(the % is from zsh, because of the lack of \n), and
"11;rgb://" appeared in the command line.

I suspect that this is data sent by xterm as a response from some
escape sequence sent by emacs. This could mean that emacs quits
before waiting for the answer from the terminal.

I can't reproduce this issue, but I think that a temporary network
slowness (remember, this is via ssh) may trigger it.

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

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

Versions of packages emacs-nox depends on:
ii  emacs-bin-common  1:26.1+1-3.2+deb10u2
ii  emacs-common  1:26.1+1-3.2+deb10u2
ii  libacl1   2.2.53-4
ii  libasound21.1.8-1
ii  libc6 2.28-10
ii  libdbus-1-3   1.12.20-0+deb10u1
ii  libgnutls30   3.6.7-4+deb10u6
ii  libgpm2   1.20.7-5
ii  libjpeg62-turbo   1:1.5.2-2+deb10u1
ii  liblcms2-22.9-3
ii  libselinux1   2.8-1+b1
ii  libsystemd0   241-7~deb10u7
ii  libtinfo6 6.1+20181013-2+deb10u2
ii  libxml2   2.9.4+dfsg1-7+deb10u1
ii  zlib1g1:1.2.11.dfsg-1

emacs-nox recommends no packages.

Versions of packages emacs-nox suggests:
pn  emacs-common-non-dfsg  

-- no debconf information

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

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Russ Allbery]

Here is an updated diff that documents the most well-understood version
conventions in the Debian archive.  More could certainly be added; this is
just a first start that addresses this specific bug.

This revised patch is less aggressive about defining native packages to
only mean packages with no existence external to Debian.  I also found
that we never define upstream, which seems like a critical concept, so I
added a definition to the Definitions section.

I've also reviewed the places where the Developer's Reference talks about
similar issues and I believe this is consistent with it.

I think this change is ready for seconds.

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

diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index a21a510..cd7daaa 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -582,20 +582,17 @@ The three components here are:
 alphanumerics and the characters ``+`` ``.`` ``~`` (plus, full stop,
 tilde) and is compared in the same way as the ``upstream_version`` is.
 
-It is optional; if it isn't present then the ``upstream_version``
-may not contain a hyphen. This format represents the case where a
-piece of software was written specifically to be a Debian package,
-where the Debian package source must always be identical to the
-pristine source and therefore no revision indication is required.
+It is conventional to restart the ``debian_revision`` at ``1`` each
+time the ``upstream_version`` is increased.
 
-It is conventional to restart the ``debian_revision`` at ``1``
-each time the ``upstream_version`` is increased.
+The package management system will break the version number apart at
+the last hyphen in the string (if there is one) to determine the
+``upstream_version`` and ``debian_revision``. The absence of a
+``debian_revision`` is equivalent to a ``debian_revision`` of ``0``.
 
-The package management system will break the version number apart
-at the last hyphen in the string (if there is one) to determine
-the ``upstream_version`` and ``debian_revision``. The absence of a
-``debian_revision`` is equivalent to a ``debian_revision`` of
-``0``.
+Presence of the ``debian_revision`` part indicates this package is a
+non-native package (see :ref:`s-source-packages`).  Absence indicates
+the package is a native package.
 
 When comparing two version numbers, first the epoch of each are
 compared, then the ``upstream_version`` if epoch is equal, and then
@@ -646,6 +643,83 @@ numbers containing strings of letters which the package management
 system cannot interpret (such as ``ALPHA`` or ``pre-``), or with silly
 orderings.  [#]_
 
+Special version conventions
+^^^
+
+The following special version numbering conventions are used in the Debian
+archive:
+
+- The absence of ``debian_revision``, and therefore of a hyphen in the
+  version number, indicates that the package is native.
+
+- ``debian_revision`` components ending in ``.`` (period) followed by a
+  number indicate this version of the non-native package was uploaded by
+  someone other than the maintainer (an NMU or non-maintainer upload).
+  This is used for a source package upload; for uploads of only binary
+  packages without source changes, see the binary NMU convention below.
+
+- ``upstream_version`` components in native packages ending in ``+nmu``
+  followed by a number indicate an NMU of a native package.  As with the
+  convention for non-native packages, this is used for a source package
+  upload, not for uploads of only binary packages without source changes.
+
+- ``upstream_version`` components in native packages or
+  ``debian_revision`` components in non-native packages ending in ``+b``
+  followed by a number indicate a binary NMU: an upload of a binary
+  package without any source changes and hence without any corresponding
+  source package upload or version change.
+
+- ``upstream_version`` components in native packages or
+  ``debian_revision`` components in non-native packages ending in
+  ``+debNuX`` indicate a stable update.  This is a version of the package
+  uploaded directly to a stable release, and the version is chosen to sort
+  before any later version of the package uploaded to Debian's unstable
+  distribution.  ``N`` is the major version number of the Debian stable
+  release to which the package was uploaded, and ``X`` is a number,
+  starting at 1, that is increased for each stable upload of this package.
+
+  For example, suppose Debian 10 released with a package with version
+  ``1.4-5``.  If that package later receives a stable update in Debian 10,
+  the first update would have the version ``1.4-5+deb10u1``.  A subsequent
+  update would have version ``1.4-5+deb10u2``.  These numbers are designed
+  to sort earlier than ``1.4-6``, the version number that would be used
+  for the next 

Bug#986261: folder.c: add code for the case "cur_grp = NULL"

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From c91bc29f6ddf5ba18b9e642b3575fa7ddc651dd4 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Fri, 2 Apr 2021 00:35:55 +
>Subject: [PATCH] folder.c: add code for the case "cur_grp = NULL"

  The compiler option "-fanalyzer" shows:

folder.c: In function 'expand_file_name':
folder.c:177:17: warning: use of NULL 'cur_grp' where non-null expected 
[CWE-690] [-Wanalyzer-null-argument]
  177 |   if ((cp = strrchr(cur_grp, '.')))
  | ^

Signed-off-by: Bjarni Ingi Gislason 
---
 folder.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/folder.c b/folder.c
index 1a095be..70d0033 100644
--- a/folder.c
+++ b/folder.c
@@ -174,7 +174,7 @@ expand_file_name(char *dest, char *src, int expand_mode)
cp = cur_grp;
break;
case 'L':
-   if ((cp = strrchr(cur_grp, '.')))
+   if ((cur_grp != NULL) && (cp = strrchr(cur_grp, '.')))
cp++;
else
cp = cur_grp;
-- 
2.30.2



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

Kernel: Linux 5.10.24-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#986260: Add --some-flag to help user figure out what the abbreviations used are

[積丹尼 Dan Jacobson]

Package: dict
Version: 1.13.0+dfsg-1
Severity: wishlist

$ dict sheriff|sed /AS/q
4 definitions found

>From The Collaborative International Dictionary of English v.0.48 [gcide]:

  Sheriff \Sher"iff\, n. [OE. shereve, AS. sc[imac]r-ger?fa;

OK that's great, but there should be a flag,
$ dict --some-flag
that would help us figure out what
AS
stands for.

Bug#986259: nntp.c: close the file pointer "in" before returning

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 35eacc5e3ac83d71a22139bc8bd52fb43316a47c Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Thu, 1 Apr 2021 23:47:36 +
>Subject: [PATCH] nntp.c: close the file pointer "in" before returning

  The compiler option "-fanalyzer" shows:

nntp.c:1726:9: warning: leak of FILE 'in' [CWE-775] [-Wanalyzer-file-leak]
 1726 |  return 1;
  | ^
...
| 1716 | FILE   *in = fopen(temp_file, "r");

Signed-off-by: Bjarni Ingi Gislason 
---
 nntp.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/nntp.c b/nntp.c
index 66064b6..07d7420 100644
--- a/nntp.c
+++ b/nntp.c
@@ -1723,8 +1723,10 @@ nntp_post(char *temp_file)
sprintf(delayed_msg, "Posting failed because we couldn't re-open file 
%s.", temp_file);
return 1;
 }
-if (!is_connected && connect_server() < 0)
+if (!is_connected && connect_server() < 0) {
+   fclose(in);
return 1;
+}
 
 switch (n = ask_server("POST")) {
case CONT_POST:
-- 
2.30.2



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

Kernel: Linux 5.10.24-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#986257: RFS: age/1.0.0~rc1-2 -- simple, modern and secure encryption tool

[Johan Fleury]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: age
   Version : 1.0.0~rc1-2
   Upstream Author : Filippo Valsorda 
 * URL : https://github.com/FiloSottile/age
 * License : BSD-3-clause, Expat, ISC
 * Vcs : https://salsa.debian.org/go-team/packages/age
   Section : utils

It builds those binary packages:

  age - simple, modern and secure encryption tool

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/a/age/age_1.0.0~rc1-2.dsc

Changes since the last upload:

 age (1.0.0~rc1-2) unstable; urgency=medium
 .
   * Set main.Version at build time to ease debuging (Closes: #986144)

Regards,

--
Johan Fleury

signature.asc
Description: OpenPGP digital signature

Bug#910548: base-files - please consider adding /usr/share/common-licenses/Unicode-Data

[Russ Allbery]

Paul Hardy  writes:

> I recently formatted the Unicode Data license for the d/copyright file
> of a Debian package that I created.  I thought I would offer it to
> Debian if you are interested.  You probably do not want the Copyright
> stanza, and you might not want the Comment stanza, but I erred on the
> side of too much rather than too little.

> Unicode data files are used in a number of free software packages, such
> as linux-libc-dev and the Linux kernel itself.  Use of Unicode data in
> software is likely to continue growing over time.  Thus you might find
> this useful.

Hi Paul,

It looks like you included the entire statement from the web site, which I
think is intended to cover the whole web site.  As near as I can tell, the
files that Debian is packaging are the ones referenced by this stanza:

4. Further specifications of rights and restrictions pertaining to the
   use of the particular set of data files known as the "Unicode
   Character Database" can be found in the License.

and therefore appear to only be covered by this license instead:

https://www.unicode.org/license.html

The full license that you formatted includes a bunch of other clauses like
choice of venue and unilateral license changes that I don't think are
intended to cover the things that we're packaging.  I think we should
therefore consider incorporating only the above text instead?

Scott Kitterman  writes:

> According to my wrangling of codesearch.debian.net, unicode.org gets
> mentioned in over 1,000 packages and it's mostly about this data.  I
> think that's enough to merit inclusion in common-licenses.

Could you provide more detail on your search?  I searched for:

path:debian/copyright DOWNLOADING, INSTALLING, COPYING OR OTHERWISE
USING UNICODE INC

and only found 26 packages.  I'm not sure that's enough to warrant
inclusion in common-licenses.

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

Bug#986258: privoxy: apparmor profile disallows one from using --pidfile or alternate configfile

[Brian Murray]

Package: privoxy
Version: 3.0.32-1
Severity: normal

Dear Maintainer,

The autopkgtest for privoxy is failing to run on Ubuntu because the
apparmor profile is enabled and the test passes a pidfile and config
file to privoxy.

  /usr/sbin/privoxy --pidfile $PIDFILE $CONFIG

This fails because apparmor denies access to $PIDFILE and $CONFIG.

autopkgtest [20:14:35]: test privoxy-regression-test: [---
Starting privoxy on port 8119
2021-01-17 20:14:35.385 7fb3e30f4200 Fatal error: can't open pid file 
'/tmp/autopkgtest.TAxSNW/autopkgtest_tmp/privoxy.pid': Permission denied

Furthermore this means that one can't use the --pidfile argument or a
config file other than one in /etc/privoxy because of the apparmor
profile.

While I'll work around this in Ubuntu by disabling the apparmor profile
for the test I don't think that's the best solution.

Bug#844528: #844528 systemd is missing the systemd-firstboot binary (and service)

[Martin Verges]

Please add systemd-firstboot as it is required for pxe/boostrap tasks.

--
Martin Verges
Managing director

Mobile: +49 174 9335695
E-Mail: martin.ver...@croit.io
Chat: https://t.me/MartinVerges

croit GmbH, Freseniusstr. 31h, 81247 Munich
CEO: Martin Verges - VAT-ID: DE310638492
Com. register: Amtsgericht Munich HRB 231263

Web: https://croit.io
YouTube: https://goo.gl/PGE1Bx

Bug#952950: nss: Replace PKCS11 headers provided by OASIS

[Timo Röhling]

On Tue, 23 Mar 2021 00:44:07 +0100 Bastian Germann  
wrote:

As far as I can see, the license for NSS's PKCS#11 headers is MPL 2.0
(DFSG-free) and not the OASIS IPR.

Well, I can see from the discussion you linked that the OASIS IPR
license is intended to apply to their work products, and not the shared
code. And they do have separate rules for their open repositories, which
default to BSD-3-Clause license unless stated otherwise [1].

However, the PKCS#11 repository [2] is not in the linked "oasis-open"
namespace on Github, there is an explicit reference to the IPR
license in that repository.

As for the MPL 2.0 license, the Mozilla upstream added that to their
version of the headers after stating that bug 1618918 had clarified the
situation, but I can't seem to access that bug [3].

Cheers
Timo

[1] https://www.oasis-open.org/open-repositories/#licensingRules
[2] https://github.com/oasis-tcs/pkcs11
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1618918


signature.asc
Description: PGP signature

Bug#952950: nss: Replace PKCS11 headers provided by OASIS

[Timo Röhling]

On Tue, 23 Mar 2021 00:44:07 +0100 Bastian Germann  
wrote:

On Tue, 23 Mar 2021 00:18:08 +0100 Bastian Germann wrote:> Upstream had
a discussion about the license at
> https://phabricator.services.mozilla.com/D63241 and with OASIS at
> https://markmail.org/thread/4juvugfvj45iyrmp

As far as I can see, the license for NSS's PKCS#11 headers is MPL 2.0
(DFSG-free) and not the OASIS IPR.

Bug#682347: resurrect editor virtual package name

[Russ Allbery]

Russ Allbery  writes:

> 2. Document editor and recommend everyone implement it properly.  Since
>we're going to allow packages to depend on editor, I think providing
>it would need to be a should, so that's going to be a lot of buggy
>(but not RC-buggy) editor packages.  But it would get us to a clean
>dependency system.  (I will leave it to someone else to tackle this
>for pager if someone really wants to.)

When I let the ball drop on this three years ago, there was a consensus
that this option was the way to go.  Picking this up again, here is a
proposed Policy change to document the editor and default-editor virtual
packages.

Note that this would make quite a few packages buggy (but not RC-buggy)
since they don't Provide: editor although they participate in the
/usr/bin/editor alternative.  This was considered reasonable since it
would be cleaning up the dependency structure and the bug is fairly minor
and can be dealt with when those maintainers have a chance.

I'm looking for seconds for this diff.  It documents the status quo for
/usr/bin/pager; if we want to make a similar cleanup there, we can do that
as a separate bug.

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

diff --git a/policy/ch-customized-programs.rst b/policy/ch-customized-programs.rst
index 747df56..27abebd 100644
--- a/policy/ch-customized-programs.rst
+++ b/policy/ch-customized-programs.rst
@@ -93,21 +93,30 @@ alternative should have a slave alternative for
 ``/usr/share/man/man1/pager.1.gz`` pointing to the corresponding manual
 page.
 
-If it is very hard to adapt a program to make use of the EDITOR or PAGER
-variables, that program may be configured to use
-``/usr/bin/sensible-editor`` and ``/usr/bin/sensible-pager`` as the
-editor or pager program respectively. These are two scripts provided in
-the sensible-utils package that check the EDITOR and PAGER variables and
+Packages that register as an alternative for ``/usr/bin/editor`` should
+also provide the virtual package ``editor`` by including it in the
+``Provides`` control field. The package providing the current default
+editor for the Debian base system, and only that package, should also
+provide the ``default-editor`` virtual package. Packages that call
+``editor`` directly (not via ``sensible-editor`` or the EDITOR environment
+variable) should depend on ``default-editor | editor``.
+
+Programs may assume that ``/usr/bin/pager`` is available as a fallback
+without adding an explicit package dependency. There is no ``pager``
+virtual package.
+
+If it is difficult to adapt a program to use the EDITOR or PAGER
+variables, that program may instead be configured to use
+``/usr/bin/sensible-editor`` and ``/usr/bin/sensible-pager`` as the editor
+or pager program respectively. These are scripts provided by the
+``sensible-utils`` package that check the EDITOR and PAGER variables and
 launch the appropriate program, and fall back to ``/usr/bin/editor`` and
-``/usr/bin/pager`` if the variable is not set.
+``/usr/bin/pager`` if the variable is not set. Packages using these
+scripts should declare an appropriate dependency on ``sensible-utils``.
 
 A program may also use the VISUAL environment variable to determine the
 user's choice of editor. If it exists, it should take precedence over
-EDITOR. This is in fact what ``/usr/bin/sensible-editor`` does.
-
-It is not required for a package to depend on ``editor`` and ``pager``,
-nor is it required for a package to provide such virtual
-packages. [#]_
+EDITOR. This is also what ``/usr/bin/sensible-editor`` does.
 
 .. _s-web-appl:
 
@@ -573,10 +582,6 @@ installed in ``/usr/share/man/man6``.
portion is handled internally by the package system based on the os
and cpu.
 
-.. [#]
-   The Debian base system already provides an editor and a pager
-   program.
-
 .. [#]
If it is not possible to establish both locks, the system shouldn't
wait for the second lock to be established, but remove the first
diff --git a/virtual-package-names-list.yaml b/virtual-package-names-list.yaml
index 2a9857a..6c0b59e 100644
--- a/virtual-package-names-list.yaml
+++ b/virtual-package-names-list.yaml
@@ -100,6 +100,14 @@ virtualPackages:
 
 # System
 
+ - name: default-editor
+   description: default base system /usr/bin/editor
+   alternatives:
+ - /usr/bin/editor
+ - name: editor
+   description: suitable /usr/bin/editor
+   alternatives:
+ - /usr/bin/editor
  - name: flexmem
description: anything that can access flexible memory via the OBEX Protocol
  - name: foomatic-data
@@ -457,3 +465,7 @@ virtualPackages:
 #   Added default-dbus-session-bus
 #   15 Feb 2019 Added logind
 #   Added default-logind
+#
+# Russ Allbery:
+#   01 Apr 2021 Added editor
+#   Added default-editor

Bug#986186: postgresql-common: pg_dump does not talk to the last major version (11): Error: PostgreSQL version 9.6 is not installed

[Johannes Ranke]

...

> It would probably be a good idea to include the "-p 5433" argument in
> the cluster selection algorithm - so far I refrained from doing that
> in order not to create more corner cases, but I guess it just makes
> sense. (And granted, -p 54NN is also how I select my local version NN
> cluster here.) It's too late to do that for bullseye, though.

I'm glad you like the idea. This will make it more intuitive, as it will be 
consistent with psql in this respect.

> > BTW, is there work underway to provide a postgresql specific paragraph
> > in the bullseye release notes? I am not very experienced with
> > postgresql, but would be willing to help writing/proof reading/testing.
> 
> Everything should be detailed in
> /usr/share/doc/postgresql-common/README.Debian.gz.

How about inserting a pointer to this (very helpful and carefully prepared) 
document in the release notes under 5.3? I think it is important for 
administrators to be aware that psql and the commands handled by pg_wrapper 
will not "just work" after the upgrade.

Johannes

Bug#932696: Please document Haskell team style Vcs-Git sytax

[Russ Allbery]

Ian Jackson  writes:

> Package: debian-policy
> Version: 4.4.0.1

> Many packages' .dscs contain something like this:
>   Source: bustle
>   Version: 0.7.4-1
>   Vcs-Git: https://salsa.debian.org/haskell-team/DHG_packages.git [p/bustle]

> The semantics do not appearr to be documented in policy.

Reminder that this proposed patch needs one more second to be merged into
the next release of Policy.

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

diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index a21a510..2a2e364 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -972,11 +972,33 @@ repository where the Debian source package is developed.
 - Mtn (Monotone)
 - Svn (Subversion)
 
-In the case of Git and Mercurial, the value consists of a URL,
-optionally followed by the word ``-b`` and the name of a branch in
-the indicated repository, following the syntax of the ``git clone``
-or ``hg clone`` command. If no branch is specified, the packaging
-should be on the default branch.
+In the case of Git, the value must have the following syntax::
+
+ [ " -b "  ] [ " ["  "]" ]
+
+where the portions enclosed in brackets are optional and the portions
+enclosed in double quotes are literal strings.   indicates
+the repository.  If the  stanza is present, it names a
+branch in the indicated repository.  If no branch is specified, the
+packaging should be on the default branch.  If the  stanza
+is present, it specifies the relative path to the top of the packaging
+tree (the parent directory of the ``debian`` directory).  If no path
+is specified, it defaults to ``.`` (the top level of the indicated
+repository and branch).
+
+For example::
+
+Vcs-Git: https://example.org/repo -b debian [p/package]
+
+indicates a subdirectory named ``p/package`` in the ``debian`` branch
+of the repository at ``https://example.org/repo``.
+
+In the case of Mercurial, the value must have the following syntax::
+
+ [ " -b "  ]
+
+This is interpreted the same way as the Git syntax except a path
+within the repository is not supported.
 
 A package control file must not have more than one ``Vcs-``
 field.  If the package is maintained in multiple version control

Bug#985402: libgconf-2-4: found segmentation fault

[Bernhard Übelacker]

Hello Antonio,
was this line in dmesg maybe followed by a "Code:" line?
Could you provide that too?

Otherwise maybe you could install systemd-coredump and after
the next crash journal should contain more info about it and
collect a core for later inspection.

More details here: https://wiki.debian.org/HowToGetABacktrace

Kind regards,
Bernhard

Bug#985977: unblock: dlt-viewer/2.21.2+dfsg-1

[Paul Gevers]

Hi Gianfranco,

On Mon, 29 Mar 2021 10:49:38 +0200 Sebastian Ramacher
 wrote:
> Seems fine without the compat bump.

Please revert.

https://release.debian.org/bullseye/FAQ.html (last section).

Paul





OpenPGP_signature
Description: OpenPGP digital signature

Bug#985364: Aborted (core dumped) drawing a simple GRIB file

[Bernhard Übelacker]

Hello Enrico,
I am not involved in packaging python3-magics++,
just tried to reproduce this fault.

Unfortunately it did not show up in my minimal test VM.
It produced a png with a frame and a text and a symbol
at the bottom. Is there something more expected to
be in the rendered png?
Do I have missed to install some kind of map data or similar?

You write grib_dump shows no fault, should
XyGrib work on that file too - it shows me (translated):

file cannot be opened.
It's not a GRIB file
or it contains no valid data
or ...

Might that give a hint on what is the issue?

Maybe you could add a backtrace of the assert?

Kind regards,
Bernhard

Bug#986233: closed by Norbert Preining (Re: Bug#986233: texlive-fonts-extra: no further upgrades until #923423 is resolved)

[Norbert Preining]

Hi Joachim,

> Anyway, having this correspondence in the Debian
> data base may help others who will run into the
> same problem.

As said, this is very cryptic in particular on an SSD. I am running
several (>3) systems and in none of them this behaviour is shown.
I don't have more guesses than what was discussed in the dpkg bug.

> Could you possibly give me a short hint how to
> use "eatmydata" to switch off fsync?

Try
eatmydata dpkg -i /texlive-fonts-extradeb
and see if this makes it faster. It disables all fsync calls.

> And one more question: Isn't texlive-fonts-extra
> too big? Why not split it into a few topical
> packages, like math, greek, asian, ...

We already have about 50 TeX Live packages, and the split is according
to what upstream does. For complexity reduction reasons I contemplated
one single package with all of TeX Live containing 4Gb of package ...

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Fujitsu Research Labs  +  IFMGA Guide + TU Wien + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#986186: postgresql-common: pg_dump does not talk to the last major version (11): Error: PostgreSQL version 9.6 is not installed

[Christoph Berg]

Control: retitle -1 pg_wrapper: Include -p  argument in port selection
Control: severity -1 wishlist

> $ pg_lsclusters 
> Ver Cluster Port StatusOwnerData directory   
> Log file
> 9.6 main5432 down,binaries_missing postgres /var/lib/postgresql/9.6/main 
> /var/log/postgresql/postgresql-9.6-main.log
> 11  main5433 onlinepostgres /var/lib/postgresql/11/main  
> /var/log/postgresql/postgresql-11-main.log
> 13  main5434 onlinepostgres /var/lib/postgresql/13/main  
> /var/log/postgresql/postgresql-13-main.log
> 
> I can connect to the version 11 cluster with psql -p 5433 my_database, but 
> when I
> run pg_dump -p 5433 my_database, I get
> 
> Error: PostgreSQL version 9.6 is not installed

As per pg_wrapper(1), the version selection mechanism will pick the
cluster running on port 5432, so pg_dump -p 5433 will try to use the
9.6 pg_dump. Use `pg_dump --cluster 11/main` to make it pick the
11 pg_dump.

It would probably be a good idea to include the "-p 5433" argument in
the cluster selection algorithm - so far I refrained from doing that
in order not to create more corner cases, but I guess it just makes
sense. (And granted, -p 54NN is also how I select my local version NN
cluster here.) It's too late to do that for bullseye, though.

> BTW, is there work underway to provide a postgresql specific paragraph
> in the bullseye release notes? I am not very experienced with
> postgresql, but would be willing to help writing/proof reading/testing.

Everything should be detailed in 
/usr/share/doc/postgresql-common/README.Debian.gz.

Christoph

Bug#985307: sudo-ldap is built with --disable-setresuid

[Marc Haber]

tags #985307 confirmed
thanks

On Mon, Mar 15, 2021 at 06:11:14PM +0100, Dennis Filder wrote:
> While looking into #783889 I noticed that the sudo binary shipped in
> sudo-ldap does not use setresuid.  The changelog entry for 1.8.2-1
> reads: "drop --disable-setresuid since modern systems should not run
> 2.2 kernels", but apparently only the first configure statement in
> d/rules was changed.

Thanks for spotting this. This bug was even taken over to the
experimental branch where ...

> Using a variable for common options should prevent such accidents in
> the future.

... the common options ARE in a variable, but --disable-setresuid was
explicitly set for sudo-ldap.

I committed a fix, but this is not going to be in bullseye.

Greetings
Marc

Bug#986250: libtraildb-dev: should Architecture: amd64 x32

[Andrei POPESCU]

Control: reassign -1 src:traildb

On Jo, 01 apr 21, 22:09:17, Yangfl wrote:
> Source: libtraildb-dev
> 
> In file included from src/tdb_encode_model.c:22:
> src/dsfmt/dSFMT.h:148:12: fatal error: emmintrin.h: No such file or directory
>   148 | #  include 
>   |^
> compilation terminated.

Reassigning to correct source package.

Kind regards,
Andrei
-- 
Looking after bugs assigned to unknown or inexistent packages


signature.asc
Description: PGP signature

Bug#986256: simka: flaky amd64 autopkgtest: regularly times out after 2:47 h

[Paul Gevers]

Source: simka
Version: 1.5.3-2
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky timeout

Dear maintainer(s),

Your package has an autopkgtest, great. However, I looked into
the history of your autopkgtest [1] and I noticed version 1.5.3-2 fails
regularly on amd64, while sporadically a rerun passes. I copied some of
the output at the bottom of this report. It hits the autopkgtest time
out after 2hours and 47 minutes. Successful runs pass in less than a minute.

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Paul

[1] https://ci.debian.net/packages/s/simka/testing/amd64/

https://ci.debian.net/data/autopkgtest/testing/amd64/s/simka/11355132/log.gz

Computing stats...

Stats
Reads
Total:8470M0G
Min:980M0G
Max:4020M0G
Average:1690M0G
Kmers
Distinct Kmers (before merging):146700M0G
Distinct Kmers (after merging):81230M0G
Shared distinct Kmers:43220M0G
Kmers:501300M0G
Mean k-mer coverage: 2.66341


Output dir: ./simka_results/




*** Test: PASSED

Command used:
/usr/bin/simka -in ../example/simka_input.txt -out ./simka_results/
-out-tmp ./simka_temp_output

Command for visualizing results:
python ../scripts/visualization/run-visualization.py -in
./simka_results/ -out ./simka_results/ -pca -heatmap -tree

Command for visualizing results with metadata annotations:
python ../scripts/visualization/run-visualization.py -in
./simka_results/ -out ./simka_results/ -pca -heatmap -tree -metadata-in
../example/dataset_metadata.csv -metadata-variable VARIABLE_1
autopkgtest [07:42:20]: ERROR: timed out on command "su -s /bin/bash
debci -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 ||
true;  . ~/.profile >/dev/null 2>&1 || true;
buildtree="/tmp/autopkgtest-lxc.zk5p_5wg/downtmp/build.NZn/src"; mkdir
-p -m 1777 --
"/tmp/autopkgtest-lxc.zk5p_5wg/downtmp/run-unit-test-artifacts"; export
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.zk5p_5wg/downtmp/run-unit-test-artifacts";
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755
"/tmp/autopkgtest-lxc.zk5p_5wg/downtmp/autopkgtest_tmp"; export
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.zk5p_5wg/downtmp/autopkgtest_tmp";
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive;
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=48; unset
LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY
LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; chmod
+x
/tmp/autopkgtest-lxc.zk5p_5wg/downtmp/build.NZn/src/debian/tests/run-unit-test;
touch /tmp/autopkgtest-lxc.zk5p_5wg/downtmp/run-unit-test-stdout
/tmp/autopkgtest-lxc.zk5p_5wg/downtmp/run-unit-test-stderr;
/tmp/autopkgtest-lxc.zk5p_5wg/downtmp/build.NZn/src/debian/tests/run-unit-test
2> >(tee -a /tmp/autopkgtest-lxc.zk5p_5wg/downtmp/run-unit-test-stderr
>&2) > >(tee -a
/tmp/autopkgtest-lxc.zk5p_5wg/downtmp/run-unit-test-stdout);" (kind: test)
autopkgtest [07:42:20]: test run-unit-test: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#986246: axel: flaky autopkgtest (on ci.d.n arm64) due to output on stderr: Connection gone.

[Eriberto Mota]

Hi Paul,

Em qui., 1 de abr. de 2021 às 10:24, Paul Gevers  escreveu:
>
> Your package has an autopkgtest, great. However, I looked into
> the history of your autopkgtest [1] and I noticed it fails regularly on
> arm64. I have copied some of the output below. Can
> you please look into it and fix it? Either suppress this particular case
>  of output to stderr if you still want to catch the rest, or add an
> allow-stderr restriction to your test cases.

Thanks a lot for your help. I decided to add allow-stderr in some tests.

Regards,

Eriberto

Bug#986255: gnome-calculator: Incorrect copyright date

[Vadim Naumuk]

Package: gnome-calculator
Version: 3.30.1-2
Severity: minor

Dear Maintainer, in the window "about" the copyright date is 2016. After
examining the source code, it was revealed that 2016 is spelled out in the file
/src/gnome-calculator.vala on line 350.

Possible solution:
add code to line 341:
var dt = new DateTime.now_local ();
var year = dt.format ("%Y");

edit line 350:
from "\xc2\xa9 1986–2016 The Calculator authors",  => to  "\xc2\xa9
1986–" + year + " The Calculator authors",



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

Kernel: Linux 4.19.0-16-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_RU.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 gnome-calculator depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgtk-3-0   3.24.5-1
ii  libgtksourceview-3.0-1   3.24.9-2
ii  libmpc3  1.1.0-1
ii  libmpfr6 4.0.2-1
ii  libsoup2.4-1 2.64.2-2
ii  libxml2  2.9.4+dfsg1-7+deb10u1

Versions of packages gnome-calculator recommends:
ii  gvfs  1.38.1-5
pn  yelp  

gnome-calculator suggests no packages.

-- no debconf information

Bug#966387: unattended-upgrade-shutdown left running after package removal

[Balint Reczey]

Control: tags -1 confirmed
Control: severity -1 minor

On Mon, Jul 27, 2020 at 10:03 PM Jakub Wilk  wrote:
>
> Package: unattended-upgrades
> Version: 1.11.2
>
> I removed the unattended-upgrades package, but the
> unattended-upgrade-shutdown process is still running running in the
> background:
>
># dpkg -P unattended-upgrades
>(Reading database ... 39928 files and directories currently installed.)
>Removing unattended-upgrades (1.11.2) ...
>Purging configuration files for unattended-upgrades (1.11.2) ...
>dpkg: warning: while removing unattended-upgrades, directory 
> '/var/log/unattended-upgrades' not empty so not removed
>Processing triggers for man-db (2.8.5-2) ...
>Processing triggers for systemd (241-7~deb10u4) ...
>
># pgrep -a unattended
>575 /usr/bin/python3 
> /usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal

Yes, thanks for reporting it.
The process does no harm and will disappear at next reboot.
Not nice, though.

Cheers,
Balint

Bug#944920: Revise terminology used to specify requirements

[Russ Allbery]

Russ Allbery  writes:

> In attempting to revise recent GRs to use the same terminology as
> Policy, I got frustrated again by the lack of precision of our current
> language.  This is an attempt to make a minor improvement.  It doesn't
> go all the way to using all-caps terms the way that RFC 2119 does; I
> think that might be an improvement, but it was a larger change than I
> wanted to tackle.

It's been over a year since the last activity on this bug so although
there were enough seconds for a revised form of this patch, I'm reposting
it to remind people where the discussion was and as a quick double-check
that I didn't mess up the rebase.

This includes relaxing the debian/missing-sources wording back to optional
again, although I kept some rewording of that paragraph to hopefully make
it a bit clearer.

Proposed debian/changelog entry:

  * Policy: Add new encouraged keyword, make keywords consistent
Wording: Russ Allbery 
Seconded: Sam Hartman 
Seconded: Sean Whitton 
Closes: #944920
  * Clarify that no package may install files in /usr/lib64.  The previous
wording implied this restriction only applied to 64-bit packages.
  * Reserve the /etc/rcn.d directories for the init-system-helpers package
rather than the sysvinit package, reflecting a change already made in
the archive.

Attached is a regular unified diff since I think that's marginally easier
to read (although I'm very used to unified diffs).  For folks who want a
word diff instead, clone https://salsa.debian.org/dbnpolicy/policy.git and
run git diff --word-diff next..bug944920-rra

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

diff --git a/debian/changelog b/debian/changelog
index fe13e5a..b4d81f1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,6 @@
 debian-policy (4.5.2.0) UNRELEASED; urgency=medium
 
+  [ Sean Whitton ]
   * Policy: Allow manpages to be included in the dependencies of packages
 Wording: Helmut Grohne 
 Seconded: Russ Allbery 
@@ -7,6 +8,18 @@ debian-policy (4.5.2.0) UNRELEASED; urgency=medium
 Seconded: Sean Whitton 
 Closes: #983657
 
+  [ Russ Allbery ]
+  * Policy: Add new encouraged keyword, make keywords consistent
+Wording: Russ Allbery 
+Seconded: Sam Hartman 
+Seconded: Sean Whitton 
+Closes: #944920
+  * Clarify that no package may install files in /usr/lib64.  The previous
+wording implied this restriction only applied to 64-bit packages.
+  * Reserve the /etc/rcn.d directories for the init-system-helpers package
+rather than the sysvinit package, reflecting a change already made in
+the archive.
+
  -- Sean Whitton   Sun, 28 Feb 2021 14:25:28 -0700
 
 debian-policy (4.5.1.0) unstable; urgency=medium
diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst
index 5fbc0a3..ab04261 100644
--- a/policy/ch-archive.rst
+++ b/policy/ch-archive.rst
@@ -348,8 +348,8 @@ management tools.
 the user doesn't select anything else. It doesn't include many large
 applications.
 
-No two packages that both have a priority of ``standard`` or higher
-may conflict with each other.
+Two packages that both have a priority of ``standard`` or higher must
+not conflict with each other.
 
 ``optional``
 This is the default priority for the majority of the archive. Unless
diff --git a/policy/ch-binary.rst b/policy/ch-binary.rst
index 784bca3..937d0d9 100644
--- a/policy/ch-binary.rst
+++ b/policy/ch-binary.rst
@@ -362,8 +362,8 @@ adding or removing diversions, package maintainer scripts must provide
 the ``--package`` flag to ``dpkg-divert`` and must not use ``--local``.
 
 All packages which supply an instance of a common command name (or, in
-general, filename) should generally use ``update-alternatives``, so that
-they may be installed together. If ``update-alternatives`` is not used,
+general, filename) should generally use ``update-alternatives`` so that
+they can be installed together. If ``update-alternatives`` is not used,
 then each package must use ``Conflicts`` to ensure that other packages
 are removed. (In this case, it may be appropriate to specify a conflict
 against earlier versions of something that previously did not use
diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index a21a510..fdb1b51 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -72,7 +72,7 @@ Whitespace must not appear inside names (of packages, architectures,
 files or anything else) or version numbers, or between the characters of
 multi-character version relationships.
 
-The presence and purpose of a field, and the syntax of its value may
+The presence and purpose of a field, and the syntax of its value, may
 differ between types of control files.
 
 Field names are not case-sensitive, but it is usual to capitalize the
@@ -571,19 +571,19 @@ The three components here are:
 respect to the ``upstream_version`` is described below. The
 

Bug#986254: gem2deb creates gemspec file as a binary file for ruby-magic-static gem

[Pirate Praveen]

Package: gem2deb
Version: 1.4

Since the gemspec file has some binary data quilt is failing to create 
a patch. Attached is the generated gemspec file. I had to manually 
remove the offending characters using gedit and add it as 
debian/gemspec for the build to work.


I'm not sure if it is really gem2deb issue or an upstream issue.

#
# This file has been automatically generated by gem2tgz #
#
# -*- encoding: utf-8 -*-
# stub: ruby-magic-static 0.3.5 ruby liblib
# stub: ext/magic/extconf.rb

Gem::Specification.new do |s|
  s.name = "ruby-magic-static".freeze
  s.version = "0.3.5"

  s.required_rubygems_version = Gem::Requirement.new(">= 0".freeze) if s.respond_to? :required_rubygems_version=
  s.metadata = { "bug_tracker_uri" => "https://gitlab.com/gitlab-org/ruby-magic/-/issues;, "changelog_uri" => "https://gitlab.com/gitlab-org/ruby-magic/-/blob/main/CHANGELOG.md;, "documentation_uri" => "https://www.rubydoc.info/gems/ruby-magic-static;, "source_code_uri" => "https://gitlab.com/gitlab-org/ruby-magic; } if s.respond_to? :metadata=
  s.require_paths = ["lib".freeze, "lib".freeze]
  s.authors = ["Krzysztof Wilczy\u0144ski".freeze]
  s.cert_chain = ["kwilczynski-public.pem".freeze]
  s.date = "2021-03-31"
  s.description = "File Magic in Ruby.\n\nSimple interface to libmagic for Ruby Programming Language.\n".freeze
  s.email = "k...@linux.com".freeze
  s.extensions = ["ext/magic/extconf.rb".freeze]
  s.files = ["AUTHORS".freeze, "CHANGELOG.md".freeze, "COPYRIGHT".freeze, "LICENSE".freeze, "NOTICE".freeze, "README.md".freeze, "VERSION".freeze, "ext/magic/common.h".freeze, "ext/magic/extconf.rb".freeze, "ext/magic/functions.c".freeze, "ext/magic/functions.h".freeze, "ext/magic/ruby-magic.c".freeze, "ext/magic/ruby-magic.h".freeze, "kwilczynski-public.pem".freeze, "lib/magic.rb".freeze, "lib/magic/core/file.rb".freeze, "lib/magic/core/string.rb".freeze, "lib/magic/version.rb".freeze]
  s.homepage = "https://gitlab.com/gitlab-org/ruby-magic".freeze
  s.licenses = ["Apache-2.0".freeze]
  s.post_install_message = "Thank you for installing!\n".freeze
  s.required_ruby_version = Gem::Requirement.new(">= 2.5.0".freeze)
  s.rubygems_version = "3.2.0.rc.2".freeze
  s.summary = "File Magic in Ruby".freeze

  if s.respond_to? :specification_version then
s.specification_version = 4
  end

  if s.respond_to? :add_runtime_dependency then
s.add_runtime_dependency(%q.freeze, ["~> 2.5.0"])
  else
s.add_dependency(%q.freeze, ["~> 2.5.0"])
  end
end

Bug#985402: libgconf-2-4: found segmentation fault

[Antonio]

Salve Bernhard,
I did the tests you indicated me, here are the results:

_package:_
- gconf2

_file in autostart:_
- gsettings-data-convert.desktop

_called executable:_
- gsettings-data-convert

_log dmesg:_
[gio apr  1 18:58:26 2021] gsettings-data-[4466]: segfault at 48 ip 
7fc8059392bc sp 7fff007e3d90 error 4 in 
libgconf-2.so.4.1.5[7fc805922000+1b000]
[gio apr  1 18:58:26 2021] Code: 4d 89 c7 41 56 41 89 ce 41 55 49 89 d5 
41 54 49 89 f4 55 48 89 fd 48 83 ec 20 64 48 8b 04 25 28 00 00 00 48 89 
44 24 18 31 c0 <48> 83 7f 48 00 c7 04 24 01 00 00 00 c7 44 24 04 00 00 
00 00 74 0b


_test gdb:_

$ gdb gsettings-data-convert
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
    .

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from gsettings-data-convert...
Reading symbols from 
/usr/lib/debug/.build-id/d2/00eb838d134772a161f2a3f6b63b1511ee35ea.debug...


(gdb) r
Starting program: /usr/bin/gsettings-data-convert
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

(gsettings-data-convert:4756): GConf-CRITICAL **: 19:00:31.514: 
gconf_engine_get_local_for_addresses: assertion 'addresses != NULL' failed

[New Thread 0x773f7700 (LWP 4760)]
[New Thread 0x76bf6700 (LWP 4761)]
[New Thread 0x763f5700 (LWP 4762)]

Thread 1 "gsettings-data-" received signal SIGSEGV, Segmentation fault.
gconf_engine_get_entry (conf=0x0,
    key=key@entry=0x555917d0 
"/system/pulseaudio/modules/combine/args0",
    locale=0x77b70b6e <_nl_C_name> "C", 
use_schema_default=use_schema_default@entry=1,

    err=err@entry=0x7fffde60) at gconf-dbus.c:1293
1293    gconf-dbus.c: File o directory non esistente.

(gdb) bt
#0  gconf_engine_get_entry
    (conf=0x0, key=key@entry=0x555917d0 
"/system/pulseaudio/modules/combine/args0", locale=0x77b70b6e 
<_nl_C_name> "C", use_schema_default=use_schema_default@entry=1, 
err=err@entry=0x7fffde60)

    at gconf-dbus.c:1293
#1  0x77f4d7a6 in get
    (client=client@entry=0xd2a0, key=0x555917d0 
"/system/pulseaudio/modules/combine/args0", use_default=0, 
error=error@entry=0x7fffde60) at gconf-client.c:1493

#2  0x77f4ee93 in gconf_client_get_full
    (client=client@entry=0xd2a0, key=key@entry=0x555917d0 
"/system/pulseaudio/modules/combine/args0", 
use_schema_default=use_schema_default@entry=0, 
err=err@entry=0x7fffdef8, locale=0x0)

    at gconf-client.c:1543
#3  0x77f4efbf in gconf_client_get_without_default
    (client=client@entry=0xd2a0, key=key@entry=0x555917d0 
"/system/pulseaudio/modules/combine/args0", 
err=err@entry=0x7fffdef8) at gconf-client.c:1605

#4  0x715d in handle_file
    (filename=filename@entry=0x5556b490 
"/usr/share/GConf/gsettings/pulseaudio.convert")

    at gsettings-data-convert.c:214
#5  0x6912 in handle_dirPython Exception  
There is no member named keys.:


    (converted=0xc980, stored_mtime=0, dirname=0x5556a3e0 
"/usr/share/GConf/gsettings")

    at gsettings-data-convert.c:436
#6  main (argc=, argv=) at 
gsettings-data-convert.c:670


_Full test gdb:_

$ gdb -batch -n -ex 'set pagination off' -ex run -ex bt -ex 'bt full' 
-ex 'thread apply all bt full' --args gsettings-data-convert
Downloading separate debug info for 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0...
Downloading separate debug info for 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0...
Downloading separate debug info for 
/run/home/root/.cache/debuginfod_client/d0e0fbe8b2783580f652ad6c14f3ef21cc4d223b/debuginfo...
Downloading separate debug info for 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0...

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Downloading separate debug info for 
/usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0...
Downloading separate debug info for 
/usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2...

Downloading separate debug info for /lib/x86_64-linux-gnu/libdbus-1.so.3...
Downloading separate debug info for /lib/x86_64-linux-gnu/libz.so.1...
Downloading separate debug info for 
/usr/lib/x86_64-linux-gnu/libmount.so.1...

Downloading separate debug info for /lib/x86_64-linux-gnu/libselinux.so.1...
Downloading separate debug info for 

Bug#986222: Acknowledgement (glibc: Fix O_NONBLOCK value on hppa architecture)

[Aurelien Jarno]

Hi,

On 2021-04-01 11:08, Helge Deller wrote:
> > This looks like a duplicate of #981650, which can't be fixed right now
> > due to the freeze. Merging the bugs.
> 
> Thanks for merging the bugs!
> Does the freeze is relevant for non-released architectures like hppa as well?
> I'm asking, because for hppa it would be very good if this gets fixed before
> the release

You should see it the other way around. During the full freeze, fixing a
bug on a non-release architecture is not in the list of appropriate
changes.

Aureliej

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#983362: Bug#983367: gvfs: autopkg test always fails on qemu testbed

[Balint Reczey]

Hi Ryutaroh.

On Thu, Feb 25, 2021 at 1:39 AM Ryutaroh Matsumoto
 wrote:
>
> I was told that autopkg test scripts should not assume that an ordinary user 
> can sudo at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983432#10

This can be looked at several ways and thank you for collecting a few opinions.

As Simon pointed out passwordless sudo is available in Ubuntu test
images (both for VMs and LXC runners), thus it is not a surprise that
tests started relying on that. IMO making passwordless sudo available
is the most pleasant way of enabling testing as a normal user and
still allowing raising privileges for a few operations.
On Ubuntu isolation-container and isolation-machine will keep implying
passwordless sudo being available and IMO the easiest solution forward
would be generating Debian test images the same way. Personally I'd
like to see Debian executing the tests using sudo and any other way
would be just more complicated.

The needs-sudo restriction can be a good way of documenting the tests'
requirements and the test runners' capability.

Should none of the above would be adopted in Debian I can make the
test SKIP if sudo fails.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#841666: release-notes: recommend installing usrmerge on upgrade to stretch

[Marco d'Itri]

On Apr 01, Paul Gevers  wrote:

> We already mention usrmerge in the release notes [1] with the following
> text. Does that suffice for the current purpose?
Looks good to me.

> """
> The historical justifications for the filesystem layout with /bin,
> /sbin, and /lib directories separate from their equivalents under /usr
> no longer apply today; see the Freedesktop.org summary. Debian bullseye
> will be the last Debian release that supports the non-merged-usr layout;
> for systems with a legacy layout that have been upgraded without a
> reinstall, the usrmerge package exists to do the conversion if desired.
> """

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#841666: release-notes: recommend installing usrmerge on upgrade to stretch

[Paul Gevers]

Control: tags -1 moreinfo

Hi,

On 27-02-2021 23:29, Marco d'Itri wrote:
> On Feb 27, Paul Gevers  wrote:
> 
>>> Due to systemd changes, currently usrmerge requires a reboot to complete.
>>> To lower support load on the community, as the usrmerge author I suggest 
>>> that we wait to explicitly recommend users to install it until we will 
>>> have implemented running it from the initramfs or some other workaround.
>>> Hence, for buster +1.
>> What's the current status on this? Should we recommend anything of this
>> kind already in the bullseye release notes? If so, can either of you
>> maybe propose some text?
> Actually this is not clear: me and other people attempted some more 
> conversions and we have not been able to reproduce this anymore: the 
> conversion just works as expected with no mid-conversion reboot needed.
> So we assumed that whatever the problem was with the systemd bind mounts 
> it was "fixed" at some point.

We already mention usrmerge in the release notes [1] with the following
text. Does that suffice for the current purpose?

"""
The historical justifications for the filesystem layout with /bin,
/sbin, and /lib directories separate from their equivalents under /usr
no longer apply today; see the Freedesktop.org summary. Debian bullseye
will be the last Debian release that supports the non-merged-usr layout;
for systems with a legacy layout that have been upgraded without a
reinstall, the usrmerge package exists to do the conversion if desired.
"""

Paul

[1]
https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#deprecated-components



OpenPGP_signature
Description: OpenPGP digital signature

Bug#986253: build with pie again

[Matthias Klose]

Package: src:pymol
Version: 2.4.0+dfsg-1
Tags: patch

pie builds were disabled in 2016.  pymol seems to build with pie again.
patch to re-enable:

http://launchpadlibrarian.net/531253709/pymol_2.4.0+dfsg-1_2.4.0+dfsg-1ubuntu1.diff.gz

Bug#986248: pdfsandwich: detect native-archs for ocaml

[Tobias Frost]

Control: tags -1 upstream help newcomer
Control: severity -1 wishlist

On Thu, 1 Apr 2021 21:38:51 +0800 Yangfl  wrote:
> Source: pdfsandwich
> 
> Hi,
> 
> pdfsandwich ftbfs on many archs (
> https://buildd.debian.org/status/package.php?p=pdfsandwich ) because
> of missing ocamlopt.

Yeah, known issue.

 Please consider adjusting makefile according to
> https://bugs.debian.org/883018 , thanks.

I remember trying this years ago, but didn't succeed.

So unfortunatly, unless someone™ sends a patch and give some commitment to
maintain those archs*, I won't have the time and energy to tackle this; As
Adding archs increases the maintaince burden and I could not test those anyway.
You might want to file an upstream bug…

(* Comaintainers welcome -- but it should be already clear as it is maintained
in the salsa  Debian group)

--
tobi

Bug#986252: ITP: ntcard -- Streaming algorithm to estimate cardinality in genomics datasets

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-Cc: debian-de...@lists.debian.org, nil...@debian.org

* Package name: ntcard
  Version : 1.2.2+dfsg
  Upstream Author : Hamid Mohamadi
* URL : https://github.com/bcgsc/ntCard
* License : Expat
  Programming Lang: C++
  Description : Streaming algorithm to estimate cardinality in genomics 
datasets
  As input it takes file(s) in fasta, fastq, sam, or bam formats
  and computes the total number of distinct k-mers, F0, and also
  the k-mer coverage frequency histogram, fi, i>=1.

  I shall maintain this package

Bug#986251: python-bleach: CVE-2021-23980

[Salvatore Bonaccorso]

Source: python-bleach
Version: 3.2.1-2
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for python-bleach.

CVE-2021-23980[0]:
| mutation XSS via allowed math or svg; p or br; and style, title,
| noscript, script, textarea, noframes, iframe, or xmp tags with
| strip_comments=False

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-23980
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-23980
[1] https://github.com/mozilla/bleach/security/advisories/GHSA-vv2x-vrpj-qqpq
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1689399

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#841237: openssh-server: force exact permissions on newly uploaded files and directories

[Mark Gallagher]

I'd like to register a vote here. Fedora and therefore RHEL have been 
shipping this patch for 6 years now:


https://src.fedoraproject.org/rpms/openssh/blob/f22/f/openssh-6.7p1-sftp-force-permission.patch

The chances of BSD either upstreaming this patch OR providing a patch 
which behaves differently to this one seems to me to be quite low.

Bug#887374: ITP: node-aws-sdk

[Wookey]

How far did you get with this ITP?

tensorflow needs this package too so I have an interest and may end up having 
to package this too.

If you have done any of the base work (especially copyright checking)
it would be good not to have to repeat that.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#986250: libtraildb-dev: should Architecture: amd64 x32

[Yangfl]

Source: libtraildb-dev

In file included from src/tdb_encode_model.c:22:
src/dsfmt/dSFMT.h:148:12: fatal error: emmintrin.h: No such file or directory
  148 | #  include 
  |^
compilation terminated.

Bug#985412: sudo: Re-defined aliases result in incorrect error message

[Marc Haber]

On Thu, Apr 01, 2021 at 01:38:39PM +0100, Chris Boot wrote:
> Control: notfound -1 1.9.6-1~exp1
> 
> On 01/04/2021 11:33, Marc Haber wrote:
> > On Wed, Mar 17, 2021 at 05:39:28PM +, Chris Boot wrote:
> > > If a Cmnd_Alias (others may also be affected) is defined twice, the
> > > error message produced is misleading:
> > > 
> > > $ cat >test < > > > Cmnd_Alias BUG_TEST = /bin/true
> > > > Cmnd_Alias BUG_TEST = /bin/true
> > > > EOF
> > > $ visudo -c -f test
> > > test:2:32: Alias "en_GB.UTF-8" already defined
> > > Cmnd_Alias BUG_TEST = /bin/true
> > > ^
> > 
> > Weirdness ;-)
> > 
> > Can you try whether sudo 1.9.6 from experimental has the same issue? If
> > so, it would probably be best if you'd report this upstream
> > (https://bugzilla.sudo.ws/index.cgi) yourself. If you can't do this,
> > please let me know and I'll open the upstream issue myself.
> 
> I can't replicate the bug in 1.9.6-1~exp1:
> 
> $ visudo -c -f test
> test:2:32: Alias "BUG_TEST" already defined
> Cmnd_Alias BUG_TEST = /bin/true

Thanks for checking! I will keep this bug report open to document the
behavior of our current version.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#986249: python-procrunner: should Build-Conflicts: wget

[Yangfl]

Package: python-procrunner
Severity: important

==
test session starts
==
platform linux -- Python 3.9.2, pytest-6.0.2, py-1.10.0, pluggy-0.13.0
rootdir: /home/ding/mips/python-procrunner-1.1.0, configfile: setup.cfg
collected 33 items

tests/test_procrunner.py 

[ 36%]
tests/test_procrunner_resolution.py ..sss

[ 87%]
tests/test_procrunner_system.py ..F.

[100%]

===
FAILURES 

___
test_running_wget
___

tmpdir = local('/tmp/pytest-of-ding/pytest-0/test_running_wget0')

def test_running_wget(tmpdir):
tmpdir.chdir()
command = ["wget", "https://www.google.com;, "-O", "-"]
try:
result = procrunner.run(command)
except OSError as e:
if e.errno == 2:
pytest.skip("wget not available")
raise
>   assert result.returncode == 0
E   AssertionError: assert 4 == 0
E+  where 4 = {'exitcode': 4, 'command': ('wget',
'https://www.google.com', '-O', '-'), 'stdout': b'', 'stderr':
b'--2021-04-01 21:4... False, 'runtime': 0.16795628699765075,
'time_start': '2021-04-01 13:48:11 GMT', 'time_end': '2021-04-01
13:48:11 GMT'}.returncode

/home/ding/mips/python-procrunner-1.1.0/.pybuild/cpython3_3.9_python-procrunner/build/tests/test_procrunner_system.py:52:
AssertionError

Bug#986248: pdfsandwich: detect native-archs for ocaml

[Yangfl]

Source: pdfsandwich

Hi,

pdfsandwich ftbfs on many archs (
https://buildd.debian.org/status/package.php?p=pdfsandwich ) because
of missing ocamlopt. Please consider adjusting makefile according to
https://bugs.debian.org/883018 , thanks.

Bug#986247: libpam-alreadyloggedin: pam does not find pam_alreadyloggedin.so

[ziegler]

Package: libpam-alreadyloggedin
Version: 0.3-8
Severity: grave
Tags: patch
Justification: renders package unusable
X-Debbugs-Cc: zieg...@uni-freiburg.de

Dear Maintainer,

The "alreadyloggedin" mechanism does not work, since pam does not find
pam_alreadyloggedin.so.

According to /var/log/auth.log pam expects the file to be in
/lib/x86_64-linux-gnu/security:

login[1926]: PAM unable to dlopen(pam_alreadyloggedin.so):\
 /lib/x86_64-linux-gnu/security/pam_alreadyloggedin.so:\
 cannot open shared object file: No such file or\
 directory

But the package has the file in /lib/security.

ln -s /usr/lib/security/pam_alreadyloggedin.so\
  /lib/x86_64-linux-gnu/security/pam_alreadyloggedin.so

solves the issue.

Regards,
Martin

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

Kernel: Linux 5.11.11-01884-g6c087ce7eca4 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libpam-alreadyloggedin depends on:
ii  libc6  2.31-10

Versions of packages libpam-alreadyloggedin recommends:
ii  login  1:4.8.1-1

libpam-alreadyloggedin suggests no packages.

-- no debconf information

Bug#635513: clusterssh: pasting special characters results in perl errors

[Philipp Marek]

Package: clusterssh
Version: 4.16-2
Followup-For: Bug #635513
X-Debbugs-Cc: phil...@marek.priv.at

Still not fixed - pasting words that include "@" results in errors and 
no pasting.


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

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

Versions of packages clusterssh depends on:
ii  libexception-class-perl 1.44-1
ii  libtry-tiny-perl0.30-1
ii  libx11-protocol-other-perl  31-1
ii  libx11-protocol-perl0.56-7.1
ii  openssh-client  1:8.4p1-5
ii  perl5.32.1-3
ii  perl-tk 1:804.035-0.1+b1
ii  xterm   366-1

clusterssh recommends no packages.

clusterssh suggests no packages.

-- no debconf information

Bug#986246: axel: flaky autopkgtest (on ci.d.n arm64) due to output on stderr: Connection gone.

[Paul Gevers]

Source: axel
Version: 2.17.10-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

Your package has an autopkgtest, great. However, I looked into
the history of your autopkgtest [1] and I noticed it fails regularly on
arm64. I have copied some of the output below. Can
you please look into it and fix it? Either suppress this particular case
 of output to stderr if you still want to catch the rest, or add an
allow-stderr restriction to your test cases.

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Paul

https://ci.debian.net/packages/a/axel/testing/arm64/

https://ci.debian.net/data/autopkgtest/testing/arm64/a/axel/11378435/log.gz
https://ci.debian.net/data/autopkgtest/testing/arm64/a/axel/11231826/log.gz
https://ci.debian.net/data/autopkgtest/testing/arm64/a/axel/9185770/log.gz
https://ci.debian.net/data/autopkgtest/testing/arm64/a/axel/10004494/log.gz



OpenPGP_signature
Description: OpenPGP digital signature

Bug#985951: upnp-router-control: New upstream version since February 2021

[jim_p]

Package: upnp-router-control
Version: 0.2-1.2+b1
Followup-For: Bug #985951
X-Debbugs-Cc: pitsior...@gmail.com

Thank you for the clarification and the quick response. Feel free to close this
bug now.

Bug#985412: sudo: Re-defined aliases result in incorrect error message

[Chris Boot]

Control: notfound -1 1.9.6-1~exp1

On 01/04/2021 11:33, Marc Haber wrote:

On Wed, Mar 17, 2021 at 05:39:28PM +, Chris Boot wrote:

If a Cmnd_Alias (others may also be affected) is defined twice, the
error message produced is misleading:

$ cat >test <
Cmnd_Alias BUG_TEST = /bin/true
Cmnd_Alias BUG_TEST = /bin/true
EOF

$ visudo -c -f test
test:2:32: Alias "en_GB.UTF-8" already defined
Cmnd_Alias BUG_TEST = /bin/true
^


Weirdness ;-)

Can you try whether sudo 1.9.6 from experimental has the same issue? If
so, it would probably be best if you'd report this upstream
(https://bugzilla.sudo.ws/index.cgi) yourself. If you can't do this,
please let me know and I'll open the upstream issue myself.


I can't replicate the bug in 1.9.6-1~exp1:

$ visudo -c -f test
test:2:32: Alias "BUG_TEST" already defined
Cmnd_Alias BUG_TEST = /bin/true
   ^

Cheers,
Chris

--
Chris Boot
bo...@debian.org

Bug#986245: RFS: python-imgviz/1.2.6+ds-1 -- Image Visualization Tools (Python 3)

[Gürkan Myczko]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-imgviz":

 * Package name: python-imgviz
   Version : 1.2.6+ds-1
   Upstream Author : Kentaro Wada
 * URL : https://github.com/wkentaro/imgviz
 * License : MIT, BSD-3-clause
 * Vcs : https://salsa.debian.org/myczko-guest/imgviz
   Section : python

It builds those binary packages:

  python3-imgviz - Image Visualization Tools (Python 3)

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


  https://mentors.debian.net/package/python-imgviz/

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


  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-imgviz/python-imgviz_1.2.6+ds-1.dsc


Changes since the last upload:

 python-imgviz (1.2.6+ds-1) experimental; urgency=medium
 .
   * New upstream version.

Regards,
--
  Gürkan Myczko

Bug#986244: RFS: gnome-shell-extension-sound-device-chooser/38-1 [ITP] -- sound output device chooser extension for GNOME Shell

[Fabio A. De Muzio Tobich]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package 
"gnome-shell-extension-sound-device-chooser":

 * Package name: gnome-shell-extension-sound-device-chooser
   Version : 38-1
   Upstream Author : 
https://github.com/kgshank/gse-sound-output-device-chooser/issues/new
 * URL : 
https://extensions.gnome.org/extension/906/sound-output-device-chooser/
 * License : GPL-3+
 * Vcs : 
https://salsa.debian.org/debian/gnome-shell-extension-sound-device-chooser
   Section : gnome

It builds those binary packages:

  gnome-shell-extension-sound-device-chooser - sound output device chooser 
extension for GNOME Shell

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

  https://mentors.debian.net/package/gnome-shell-extension-sound-device-chooser/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gnome-shell-extension-sound-device-chooser/gnome-shell-extension-sound-device-chooser_38-1.dsc

Changes for the initial release:

 gnome-shell-extension-sound-device-chooser (38-1) experimental; urgency=medium
 .
   * Initial release. (Closes: #810222)

Regards,

-- 
⢀⣴⠾⠻⢶⣦⠀ Fabio A. De Muzio Tobich
⣾⠁⢰⠒⠀⣿⡁ 9730 4066 E5AE FAC2 2683
⢿⡄⠘⠷⠚⠋⠀ D03D 4FB3 B4D3 7EF6 3B2E
⠈⠳⣄  GPG:rsa4096/7EF63B2E


signature.asc
Description: PGP signature

Bug#986243: RFS: gnome-shell-extension-shelltile/61+git20210205.1d56815-1 [ITP] -- tiling window extension for GNOME Shell

[Fabio A. De Muzio Tobich]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "gnome-shell-extension-shelltile":

 * Package name: gnome-shell-extension-shelltile
   Version : 61+git20210205.1d56815-1
   Upstream Author : https://github.com/emasab/shelltile/issues/new/choose
 * URL : https://extensions.gnome.org/extension/657/shelltile/
 * License : GPL-2+, BSD-3-Clause
 * Vcs : 
https://salsa.debian.org/debian/gnome-shell-extension-shelltile
   Section : gnome

It builds those binary packages:

  gnome-shell-extension-shelltile - tiling window extension for GNOME Shell

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

  https://mentors.debian.net/package/gnome-shell-extension-shelltile/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gnome-shell-extension-shelltile/gnome-shell-extension-shelltile_61+git20210205.1d56815-1.dsc

Changes for the initial release:

 gnome-shell-extension-shelltile (61+git20210205.1d56815-1) experimental; 
urgency=medium
 .
   * Initial release. (Closes: #986219)

Regards,

-- 
⢀⣴⠾⠻⢶⣦⠀ Fabio A. De Muzio Tobich
⣾⠁⢰⠒⠀⣿⡁ 9730 4066 E5AE FAC2 2683
⢿⡄⠘⠷⠚⠋⠀ D03D 4FB3 B4D3 7EF6 3B2E
⠈⠳⣄  GPG:rsa4096/7EF63B2E


signature.asc
Description: PGP signature

Bug#986242: ITP: fastq-pair -- Rewrites paired end fastq so all reads have a mate to separate out singletons

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-Cc: debian-de...@lists.debian.org, nil...@debian.org

* Package name: fastq-pair
  Version : 1.0
  Upstream Author : Rob Edwards
* URL : https://github.com/linsalrob/fastq-pair
* License : Expat
  Programming Lang: C
  Description : Rewrites paired end fastq so all reads have a mate to 
separate out singletons
  
  This package rewrites the fastq files with the sequences in order,
  with matching files for the two files provided on the command line,
  and then any single reads that are not matched are place in two separate
  files, one for each original file.
  .
  This code is designed to be fast and memory efficient, and works with large
  fastq files. It does not store the whole file in memory, but rather just 
stores
  the locations of each of the indices in the first file provided in memory

  I shall maintain this package

Bug#986241: ITP: r-cran-diagrammer -- Graph/Network Visualization

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: cru...@debian.org

Subject: ITP: r-cran-diagrammer -- Graph/Network Visualization
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: r-cran-diagrammer
  Version : 1.0.6.1+ds
  Upstream Author : Richard Iannone
* URL : https://cran.r-project.org/package=DiagrammeR
* License : MIT
  Programming Lang: GNU R
  Description : Graph/Network Visualization
 Build graph/network structures using functions for stepwise addition and
 deletion of nodes and edges. Work with data available in tables for bulk
 addition of nodes, edges, and associated metadata. Use graph selections
 and traversals to apply changes to specific nodes or edges. A wide
 selection of graph algorithms allow for the analysis of graphs. Visualize
 the graphs and take advantage of any aesthetic properties assigned to
 nodes and edges.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-diagrammer

Bug#985951: upnp-router-control: New upstream version since February 2021

[Daniele Napolitano]

Sadly I'm still the maintainer (and upstream) of this package but currently
I don't have access to the computer with all packaging stuff and, more
important, my GPG key to upload the package.

I think It's better to find another maintainer.

Kind regards,
Daniele.

On Fri, Mar 26, 2021 at 6:24 PM jim_p  wrote:

> Package: upnp-router-control
> Version: 0.2-1.2+b1
> Severity: minor
> Tags: upstream
> X-Debbugs-Cc: pitsior...@gmail.com
>
> Dear Maintainer,
>
> Earlier, I noticed that upnp-router-control was removed from the repo 1+
> year
> ago. I had installed it a couple of years ago in order to troubleshoot some
> connection issues I had and I can say it helped me a bit.
> Then I went to its launchpad page to check if it is still developed from
> upstream and saw that a new version (0.3) was released a month ago, with
> the
> port to gtk3 being the most important new feature. A new version after 10
> YEARS
> of inactivity!
> So, can you please bring it back to the repo after the freeze?
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'testing-security'), (500,
> 'unstable'),
> (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-5-amd64 (SMP w/2 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
> not
> set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages upnp-router-control depends on:
> ii  libatk1.0-0  2.36.0-2
> ii  libc62.31-10
> ii  libcairo21.16.0-5
> ii  libfontconfig1   2.13.1-4.2
> ii  libfreetype6 2.10.4+dfsg-1
> ii  libgdk-pixbuf2.0-0   2.40.2-2
> ii  libglib2.0-0 2.66.7-2
> ii  libgssdp-1.0-3   1.0.5-0+deb10u1
> ii  libgtk2.0-0  2.24.33-1
> ii  libgupnp-1.0-4   1.0.5-0+deb10u1
> ii  libpango-1.0-0   1.46.2-3
> ii  libpangocairo-1.0-0  1.46.2-3
> ii  libpangoft2-1.0-01.46.2-3
>
> upnp-router-control recommends no packages.
>
> upnp-router-control suggests no packages.
>


-- 
*Daniele Napolitano*
dna...@gmail.com

Skype: DnaX88
https://www.linkedin.com/in/daniele-napolitano
https://github.com/DnaX
https://launchpad.net/~dnax88

Bug#986157: unblock: libchemistry-opensmiles-perl/0.4.3-2

[Andrius Merkys]

Control: tags -1 - moreinfo

On 2021-04-01 13:43, Sebastian Ramacher wrote:
> ACK, please remove the moreinfo tag once the version is available in
> unstable.

Thanks! Uploaded to unstable.

Best,
Andrius

Bug#986233: closed by Norbert Preining (Re: Bug#986233: texlive-fonts-extra: no further upgrades until #923423 is resolved)

[Joachim Wuttke]

Sorry, Norbert, for what was bogus in my report.

Anyway, having this correspondence in the Debian
data base may help others who will run into the
same problem.

Could you possibly give me a short hint how to
use "eatmydata" to switch off fsync?

And one more question: Isn't texlive-fonts-extra
too big? Why not split it into a few topical
packages, like math, greek, asian, ...

Kind greetings, Joachim



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#977990: os-autoinst: FTBFS on i386: 3/3 Test #3: test-perl-testsuite ..............***Failed 332.81 sec

[Frédéric Bonnard]

Hi,
sorry for the delay.
Initially I wanted to include all tests in the packaging as they just
didn't fail for me on ppc64el, amd64 and i386.
Having a look at the .spec file upstream, they skip some of the tests,
amongst them, the one we have an issue with.

---
# don't require qemu within OBS
# and exclude known flaky tests in OBS check
# https://progress.opensuse.org/issues/52652
# 07-commands: https://progress.opensuse.org/issues/60755
for i in 07-commands 13-osutils 14-isotovideo 18-qemu-options 18-backend-qemu 
99-full-stack; do
rm t/$i.t
done
---

So I think we can safely skip them, if upstream does.
I'm going to change this.

Fred

On Sat, 27 Mar 2021 17:12:17 +0200, Adrian Bunk  wrote:
> ping
> 
> 
> On Fri, Mar 12, 2021 at 05:33:27PM +0200, Adrian Bunk wrote:
> > On Thu, Feb 25, 2021 at 09:52:08AM +0100, Paul Gevers wrote:
> > > Control: found -1 4.5.1527308405.8b586d5-4.2
> > > 
> > > Hi Frédéric, Hideki,
> > > 
> > > On 17-02-2021 22:01, Paul Gevers wrote:
> > > > If the forth time worked because of sheer luck, then please no, keep the
> > > > bug open until the build is less flaky. We need packages to be build
> > > > without failure [1]. Having to baby-sit flaky is not really an option as
> > > > there are too many packages in the Debian archive.
> > > 
> > > I had a look at the reproducible build project history for os-autoinst
> > > [1] and the package FTBFS very, very often, both in unstable and
> > > testing. I have marked this bug as found, so now this package is able to
> > > migrate, *but* you'll have to fix this bug if you want the package to
> > > ship with bullseye. If you can't fix the tests and still believe that
> > > the package is in a good shape for the bullseye release, I suggest you
> > > disable the tests for now.
> > 
> > Or if the package is not in a good shape on i386,
> > remove it from the architecture list.
> > 
> > os-autoinst is amd64-only in buster.
> > 
> > > Paul
> > >...
> > 
> > cu
> > Adrian
> 


signature.asc
Description: PGP signature

Bug#986240: make-guile: broken symlink: /usr/bin/gmake -> /make

[Andreas Beckmann]

Package: make-guile
Version: 4.3-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

0m14.7s ERROR: FAIL: Broken symlinks:
  /usr/share/man/man1/gmake.1.gz -> /make.1.gz (make-guile)
  /usr/bin/gmake -> /make (make-guile)


cheers,

Andreas


make-guile_4.3-4.log.gz
Description: application/gzip

Bug#986239: ITP: fplus -- Helps developers writing concise and readable C++ code

[Filippo Rusconi]

Package: wnpp
Severity: wishlist
Owner: Filippo Rusconi 
X-Debbugs-Cc: debian-de...@lists.debian.org, lopi...@debian.org

* Package name: fplus
  Version : 0.2.13
  Upstream Author : Tobias Hermann (https://github.com/Dobiasd/FunctionalPlus)
* URL : https://github.com/Dobiasd/FunctionalPlus
* License : Boost Software License 1.0
  Programming Lang: C++
  Description : Helps developers writing concise and readable C++ code
 Great code should mostly be self-documenting, but while using C++ in reality
 you can find yourself dealing with low-level stuff like iterators or
 hand-written loops that distract from the actual essence of your code.
 . 
 FunctionalPlus is a small header-only library supporting you in reducing code
 noise and in dealing with only one single level of abstraction at a time. By
 increasing brevity and maintainability of your code it can improve
 productivity (and fun!) in the long run. It pursues these goals by providing
 pure and easy-to-use functions that free you from implementing commonly used
 flows of control over and over again.
(Include the long description here.)

This library is a dependency for a recent version of toppic that I package and
that I need for my own laboratory research work.

Sincerely,
lopippo

-- 

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Research scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄  http://msxpertsuite.org
  http://www.debian.org

Bug#986238: gubbins: broken symlink: /usr/bin/gubbins_drawer -> ../share/gubbins/gubbins_drawer.py

[Andreas Beckmann]

Package: gubbins
Version: 2.4.1-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

0m42.3s ERROR: FAIL: Broken symlinks:
  /usr/bin/gubbins_drawer -> ../share/gubbins/gubbins_drawer.py (gubbins)


cheers,

Andreas


gubbins_2.4.1-3.log.gz
Description: application/gzip

Bug#980539: ASoC: sunxi: sun4i-codec: fill ASoC card owner

[Bastian Germann]

Control: tag - moreinfo

A patch addressing this was upstreamed: 
https://mailman.alsa-project.org/pipermail/alsa-devel/2021-April/183120.html

Bug#986157: unblock: libchemistry-opensmiles-perl/0.4.3-2

[Sebastian Ramacher]

Control: tags -1 confirmed moreinfo

On 2021-03-30 17:57:16, Andrius Merkys wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Dear release-team,
> 
> I am seeking pre-approval to upload libchemistry-opensmiles-perl/0.4.3-2.

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

Cheers

> 
> [ Reason ]
> libchemistry-opensmiles-perl/0.4.3-1 has a bug which has been fixed
> upstream (also by me). The bug is in code logic detecting aromatic bonds
> in chemical compounds, and as such is not specific to Debian. Fix has
> been released in 0.4.5. libchemistry-opensmiles-perl/0.4.3-2 fixes this
> bug in unstable via patch.
> 
> [ Impact ]
> Without the fix, users of libchemistry-opensmiles-perl will observe
> false-negatives in aromatic bond detection.
> 
> [ Tests ]
> * Built on clean sid chroot;
> * Upstream regression test for the bug passes.
> 
> [ Risks ]
> Changes are minimal and are unlikely to affect other packages
> negatively. Currently libchemistry-opensmiles-perl is a leaf package in
> Debian.
> 
> [ Checklist ]
>   [*] all changes are documented in the d/changelog
>   [*] I reviewed all changes and I approve them
>   [*] attach debdiff against the package in testing
> 
> unblock libchemistry-opensmiles-perl/0.4.3-2
> 
> Best,
> Andrius
> 

> diff -Nru libchemistry-opensmiles-perl-0.4.3/debian/changelog 
> libchemistry-opensmiles-perl-0.4.3/debian/changelog
> --- libchemistry-opensmiles-perl-0.4.3/debian/changelog   2021-01-28 
> 05:16:40.0 -0500
> +++ libchemistry-opensmiles-perl-0.4.3/debian/changelog   2021-03-30 
> 07:23:23.0 -0400
> @@ -1,3 +1,10 @@
> +libchemistry-opensmiles-perl (0.4.3-2) unstable; urgency=medium
> +
> +  * Applying upstream commit 6b8267f0bbc87d877bce87bfd28d4538c3f95ee5 as
> +a patch fixing detection of aromatic bonds.
> +
> + -- Andrius Merkys   Tue, 30 Mar 2021 07:23:23 -0400
> +
>  libchemistry-opensmiles-perl (0.4.3-1) unstable; urgency=medium
>  
>* New upstream version 0.4.3
> diff -Nru 
> libchemistry-opensmiles-perl-0.4.3/debian/patches/6b8267f0bbc87d877bce87bfd28d4538c3f95ee5.patch
>  
> libchemistry-opensmiles-perl-0.4.3/debian/patches/6b8267f0bbc87d877bce87bfd28d4538c3f95ee5.patch
> --- 
> libchemistry-opensmiles-perl-0.4.3/debian/patches/6b8267f0bbc87d877bce87bfd28d4538c3f95ee5.patch
>   1969-12-31 19:00:00.0 -0500
> +++ 
> libchemistry-opensmiles-perl-0.4.3/debian/patches/6b8267f0bbc87d877bce87bfd28d4538c3f95ee5.patch
>   2021-03-30 07:19:40.0 -0400
> @@ -0,0 +1,36 @@
> +From 6b8267f0bbc87d877bce87bfd28d4538c3f95ee5 Mon Sep 17 00:00:00 2001
> +From: Andrius Merkys 
> +Date: Thu, 25 Mar 2021 13:28:22 +0200
> +Subject: [PATCH] Fixing a bug due to incorrectly identified aromatic bond.
> +
> +---
> + lib/Chemistry/OpenSMILES/Parser.yp | 2 +-
> + t/06_write.t   | 2 ++
> + 2 files changed, 3 insertions(+), 1 deletion(-)
> +
> +diff --git a/lib/Chemistry/OpenSMILES/Parser.yp 
> b/lib/Chemistry/OpenSMILES/Parser.yp
> +index 8094826..f0e0a13 100644
> +--- a/lib/Chemistry/OpenSMILES/Parser.yp
>  b/lib/Chemistry/OpenSMILES/Parser.yp
> +@@ -60,7 +60,7 @@ chain: atom
> + 
> + $_[2]->{graph}->add_edge( $_[1]->{last}, $_[2] );
> + 
> +-if( is_aromatic $_[1]->{last} && is_aromatic $_[1]->{last} ) {
> ++if( is_aromatic $_[1]->{last} && is_aromatic $_[2] ) {
> + $_[2]->{graph}->set_edge_attribute( $_[1]->{last},
> + $_[2],
> + 'bond',
> +diff --git a/t/06_write.t b/t/06_write.t
> +index aee54c5..c0f4656 100644
> +--- a/t/06_write.t
>  b/t/06_write.t
> +@@ -19,6 +19,8 @@ my @cases = (
> + # Chirality information is preserved:
> + [ 'N[C@](Br)(O)C', 'N([C@](Br)(O)(C))' ],
> + [ 'N[C@@](Br)(O)C', 'N([C@@](Br)(O)(C))' ],
> ++# A regression test for previously incorrectly identified aromatic bond:
> ++[ 'c1(c(1)F)C(=O)[O-]', 'c:1(:c(:c(:c(:c(:c:1(F))(C(=O)([O-]))' 
> ],
> + );
> + 
> + plan tests => 2 * scalar @cases;
> diff -Nru libchemistry-opensmiles-perl-0.4.3/debian/patches/series 
> libchemistry-opensmiles-perl-0.4.3/debian/patches/series
> --- libchemistry-opensmiles-perl-0.4.3/debian/patches/series  1969-12-31 
> 19:00:00.0 -0500
> +++ libchemistry-opensmiles-perl-0.4.3/debian/patches/series  2021-03-30 
> 07:19:55.0 -0400
> @@ -0,0 +1 @@
> +6b8267f0bbc87d877bce87bfd28d4538c3f95ee5.patch


-- 
Sebastian Ramacher

Bug#986237: ITP: r-cran-influencer -- Software Tools to Quantify Structural Importance of Nodes in a

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: cru...@debian.org

Subject: ITP: r-cran-influencer -- Software Tools to Quantify Structural 
Importance of Nodes in a
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: r-cran-influencer
  Version : 0.1.0
  Upstream Author : Jacobs Simon,
* URL : https://cran.r-project.org/package=influenceR
* License : GPL-2
  Programming Lang: GNU R
  Description : Software Tools to Quantify Structural Importance of Nodes 
in a
   Network Provides functionality to compute various node centrality
   measures on networks. Included are functions to compute
   betweenness centrality (by utilizing Madduri and Bader's SNAP
   library), implementations of Burt's constraint and effective
   network size (ENS) metrics, Borgatti's algorithm to identify key
   players, and Valente's bridging metric. On Unix systems, the
   betweenness, Key Players, and bridging implementations are
   parallelized with OpenMP, which may run faster on systems which
   have OpenMP configured.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-influencer

This package is a precondition for r-cran-diagrammer

Bug#986236: ITP: r-cran-visnetwork -- Network Visualization using 'vis.js' Library

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: cru...@debian.org

Subject: ITP: r-cran-visnetwork -- Network Visualization using 'vis.js' Library
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: r-cran-visnetwork
  Version : 2.0.9+ds
  Upstream Author : Almende B.V. (vis.js library in htmlwidgets/lib,
* URL : https://cran.r-project.org/package=visNetwork
* License : MIT
  Programming Lang: GNU R
  Description : Network Visualization using 'vis.js' Library
 Provides an R interface to the 'vis.js' JavaScript charting
 library. It allows an interactive visualization of networks.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-visnetwork

This package is a precondition for r-cran-diagrammer

Bug#986199: unblock: python-oslo.cache/2.6.2-1

[Sebastian Ramacher]

Control: tags -1 + moreinfo

On 2021-03-31 13:39:37, Thomas Goirand wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package python-oslo.cache
> 
> This new release adds support for pymemcache, which was by
> the way already available in the relevant backend driver,
> here, dogpile.cache.
> 
> The relevant part of upstream code is just this:
> 
> +if dogpile.__version__ >= '1.1.2':
> +_backend_choices.append('dogpile.cache.pymemcache')

dogpile with that version is only available in experimental. So I wonder
what we would gain from accepting this change into testing.

Cheers

> 
> the rest of the debdiff is just distraction.
> 
> Please unblock python-oslo.cache/2.6.2-1.
> 
> Cheers,
> 
> Thomas Goirand (zigo)

> diff -Nru python-oslo.cache-2.6.1/debian/changelog 
> python-oslo.cache-2.6.2/debian/changelog
> --- python-oslo.cache-2.6.1/debian/changelog  2020-10-15 23:00:34.0 
> +0200
> +++ python-oslo.cache-2.6.2/debian/changelog  2021-03-31 13:34:14.0 
> +0200
> @@ -1,3 +1,9 @@
> +python-oslo.cache (2.6.2-1) unstable; urgency=medium
> +
> +  * New upstream release.
> +
> + -- Thomas Goirand   Wed, 31 Mar 2021 13:34:14 +0200
> +
>  python-oslo.cache (2.6.1-2) unstable; urgency=medium
>  
>* Uploading to unstable.
> diff -Nru python-oslo.cache-2.6.1/.gitreview 
> python-oslo.cache-2.6.2/.gitreview
> --- python-oslo.cache-2.6.1/.gitreview2020-08-25 14:01:17.0 
> +0200
> +++ python-oslo.cache-2.6.2/.gitreview2021-02-09 14:18:20.0 
> +0100
> @@ -2,3 +2,4 @@
>  host=review.opendev.org
>  port=29418
>  project=openstack/oslo.cache.git
> +defaultbranch=stable/victoria
> diff -Nru python-oslo.cache-2.6.1/lower-constraints.txt 
> python-oslo.cache-2.6.2/lower-constraints.txt
> --- python-oslo.cache-2.6.1/lower-constraints.txt 2020-08-25 
> 14:01:17.0 +0200
> +++ python-oslo.cache-2.6.2/lower-constraints.txt 1970-01-01 
> 01:00:00.0 +0100
> @@ -1,65 +0,0 @@
> -appdirs==1.4.3
> -certifi==2018.1.18
> -cffi==1.13.1
> -chardet==3.0.4
> -cliff==3.1.0
> -cmd2==0.8.9
> -debtcollector==2.1.0
> -decorator==4.4.2
> -dogpile.cache==1.0.2
> -entrypoints==0.3
> -etcd3gw==0.2.0
> -extras==1.0.0
> -fixtures==3.0.0
> -future==0.18.2
> -futurist==2.2.0
> -gitdb2==2.0.3
> -GitPython==2.1.8
> -idna==2.6
> -iso8601==0.1.12
> -keystoneauth1==3.4.0
> -linecache2==1.0.0
> -mock==4.0.2
> -mox3==0.25.0
> -msgpack==1.0.0
> -netaddr==0.7.19
> -netifaces==0.10.9
> -os-client-config==1.29.0
> -oslo.config==8.1.0
> -oslo.context==3.1.0
> -oslo.i18n==5.0.0
> -oslo.log==4.2.1
> -oslo.serialization==3.2.0
> -oslo.utils==4.2.0
> -oslotest==3.2.0
> -pbr==3.1.1
> -pifpaf==0.10.0
> -prettytable==0.7.2
> -pycparser==2.18
> -pyinotify==0.9.6
> -pymongo==3.0.2
> -pyparsing==2.2.0
> -pyperclip==1.8.0
> -python-binary-memcached==0.29.0
> -python-dateutil==2.8.1
> -python-memcached==1.56
> -python-mimeparse==1.6.0
> -python-subunit==1.2.0
> -pytz==2020.1
> -PyYAML==3.12
> -requests==2.18.4
> -requestsexceptions==1.4.0
> -rfc3986==1.4.0
> -six==1.11.0
> -smmap2==2.0.3
> -stestr==2.0.0
> -stevedore==1.28.0
> -testrepository==0.0.20
> -testtools==2.3.0
> -traceback2==1.4.0
> -unittest2==1.1.0
> -urllib3==1.22
> -voluptuous==0.11.7
> -wcwidth==0.2.4
> -wrapt==1.12.1
> -xattr==0.9.3
> diff -Nru python-oslo.cache-2.6.1/oslo_cache/_opts.py 
> python-oslo.cache-2.6.2/oslo_cache/_opts.py
> --- python-oslo.cache-2.6.1/oslo_cache/_opts.py   2020-08-25 
> 14:01:17.0 +0200
> +++ python-oslo.cache-2.6.2/oslo_cache/_opts.py   2021-02-09 
> 14:18:20.0 +0100
> @@ -12,11 +12,34 @@
>  # License for the specific language governing permissions and limitations
>  # under the License.
>  
> +import dogpile
> +
>  from oslo_config import cfg
>  
>  
>  _DEFAULT_BACKEND = 'dogpile.cache.null'
>  
> +_backend_choices = [
> +'oslo_cache.memcache_pool',
> +'oslo_cache.dict',
> +'oslo_cache.mongo',
> +'oslo_cache.etcd3gw',
> +'dogpile.cache.memcached',
> +'dogpile.cache.pylibmc',
> +'dogpile.cache.bmemcached',
> +'dogpile.cache.dbm',
> +'dogpile.cache.redis',
> +'dogpile.cache.memory',
> +'dogpile.cache.memory_pickle',
> +'dogpile.cache.null'
> +]
> +
> +# NOTE(moguimar): dogpile.cache.pymemcache is currently the best
> +# driver for using Memcached with TLS. This backport is intent for
> +# security purposes.
> +if dogpile.__version__ >= '1.1.2':
> +_backend_choices.append('dogpile.cache.pymemcache')
> +
>  FILE_OPTIONS = {
>  'cache': [
>  cfg.StrOpt('config_prefix', default='cache.oslo',
> @@ -34,18 +57,7 @@
>  # prevent issues with the memory cache ending up in "production"
>  # unintentionally, we register a no-op as the default caching 
> backend.
>  cfg.StrOpt('backend', default=_DEFAULT_BACKEND,
> -   choices=['oslo_cache.memcache_pool',
> -

Bug#985412: sudo: Re-defined aliases result in incorrect error message

[Marc Haber]

On Wed, Mar 17, 2021 at 05:39:28PM +, Chris Boot wrote:
> If a Cmnd_Alias (others may also be affected) is defined twice, the
> error message produced is misleading:
> 
> $ cat >test < > Cmnd_Alias BUG_TEST = /bin/true
> > Cmnd_Alias BUG_TEST = /bin/true
> > EOF
> $ visudo -c -f test
> test:2:32: Alias "en_GB.UTF-8" already defined
> Cmnd_Alias BUG_TEST = /bin/true
>^

Weirdness ;-)

Can you try whether sudo 1.9.6 from experimental has the same issue? If
so, it would probably be best if you'd report this upstream
(https://bugzilla.sudo.ws/index.cgi) yourself. If you can't do this,
please let me know and I'll open the upstream issue myself.

I am not sure whether this would be a candidate fix for bullseye, but I
doubt it.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#906330:

[Andrej Shadura]

Control: retitle -1 bmake: sanitise MAKEFLAGS in the debhelper plugin

Hi,

On Thu, 1 Apr 2021, at 12:09, Yangfl wrote:
> > On Thu, 1 Apr 2021, at 11:51, Yangfl wrote:
> > > `sbuild --no-arch-all --no-run-lintian -j1 -d unstable csh` will fail
> > > (which use bmake) and `sbuild --no-arch-all --no-run-lintian -d
> > > unstable csh` does not, since in the former case bmake will get
> > > `MAKEFLAGS='w -j1'`.

> 1. sbuild --no-arch-all --no-run-lintian -j1 -d unstable csh
> 2. sbuild --no-arch-all --no-run-lintian -d unstable csh

I see. This is, in fact, a different bug: bmake required MAKEFLAGS to start 
with a dash while GNU make accepts it anyway.

-- 
Cheers,
  Andrej

Bug#986235: libconfig-model-dpkg-perl: Need to support "author" as object in package.json

[Walter Lozano]

Package: libconfig-model-dpkg-perl
Version: 2.132
Severity: normal

Dear Maintainer,

While getting "author" from package.json the expected values are string or
lists. However some packages like less.js present an object as value.

As an example here is how "author" is declared in less.js

  "author": {
"name": "Alexis Sellier",
"email": "s...@cloudhead.net"
  },

So I think it is a good idea to support this by retrieving the value of key
"name" in that case.

I have sent a MR but my perl skills are limited

https://salsa.debian.org/perl-team/modules/packages/libconfig-model-dpkg-
perl/-/merge_requests/3



-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-70-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 libconfig-model-dpkg-perl depends on:
ii  debhelper  12.10ubuntu1
ii  libapt-pkg-perl0.1.36build3
ii  libarray-intspan-perl  2.003-1
ii  libconfig-model-backend-yaml-perl  2.133-2
ii  libconfig-model-perl   2.138-2
ii  libexporter-lite-perl  0.08-1
ii  liblog-log4perl-perl   1.49-1
ii  libmouse-perl  2.5.9-1
ii  libparse-recdescent-perl   1.967015+dfsg-2
ii  libsoftware-licensemoreutils-perl  1.004-1
ii  libsort-versions-perl  1.62-1
ii  libtext-autoformat-perl1.75-1
ii  libtext-levenshtein-damerau-perl   0.41-1
ii  liburi-perl1.76-2
ii  libwww-perl6.43-1
ii  libyaml-libyaml-perl   0.81+repack-1
ii  licensecheck   3.0.45-1
ii  lintian2.62.0
ii  perl [libmodule-corelist-perl] 5.30.0-9ubuntu0.2

Versions of packages libconfig-model-dpkg-perl recommends:
ii  libconfig-model-tkui-perl  1.371-2

libconfig-model-dpkg-perl suggests no packages.

-- no debconf information

Bug#986234: calcurse: ftbfs at the second run of dpkg-buildpackage

[Yangfl]

Source: calcurse
Version: 4.6.0-2
Severity: wishlist

$ dpkg-buildpackage -j6 -B -us -uc
[... build succeed]
$ dpkg-buildpackage -j6 -B -us -uc
[...]
checking pthread.h presence... yes
checking for pthread.h... yes
checking for pthread_create in -lpthread... yes
checking for math.h... (cached) yes
checking for exp in -lm... yes
checking whether to include documentation... yes
checking for asciidoc... no
configure: WARNING: AsciiDoc not found - cannot rebuild documentation!
configure: error: Asciidoc is required to build documentation.
tail -v -n \+0 config.log
==> config.log <==
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by calcurse configure 4.6.0, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  $ ./configure --build=mipsisa64r6el-linux-gnuabi64 --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/mipsisa64r6el-linux-gnuabi64
--libexecdir=${prefix}/lib/mipsisa64r6el-linux-gnuabi64
--disable-maintainer-mode --disable-dependency-tracking
[...]

Bug#906330:

[Yangfl]

Andrej Shadura  于2021年4月1日周四 下午5:55写道：
>
> Control: tag -1 moreinfo
>
> Hi,
>
> On Thu, 1 Apr 2021, at 11:51, Yangfl wrote:
> > `sbuild --no-arch-all --no-run-lintian -j1 -d unstable csh` will fail
> > (which use bmake) and `sbuild --no-arch-all --no-run-lintian -d
> > unstable csh` does not, since in the former case bmake will get
> > `MAKEFLAGS='w -j1'`.
>
> Please provide more info (logs etc).
>
> Thanks!
>
> --
> Cheers,
>   Andrej

1. sbuild --no-arch-all --no-run-lintian -j1 -d unstable csh
2. sbuild --no-arch-all --no-run-lintian -d unstable csh


csh2.build
Description: Binary data


csh1.build
Description: Binary data

Bug#986233: texlive-fonts-extra: no further upgrades until #923423 is resolved

[Joachim Wuttke]

Package: texlive-fonts-extra
Version: 2020.20210202-3
Severity: serious

Upgrading texlive-fonts-extra takes incredibly long (>20'),
and slows down all other processes.

This issue has been reported before, and has been transferred
to dpkg, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923423.

May I kindly ask the texlive-fonts-extra maintainers to abstain
from further upgrades until the dpkg issue is solved?

- Joachim



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#906330:

[Andrej Shadura]

Control: tag -1 moreinfo

Hi,

On Thu, 1 Apr 2021, at 11:51, Yangfl wrote:
> `sbuild --no-arch-all --no-run-lintian -j1 -d unstable csh` will fail
> (which use bmake) and `sbuild --no-arch-all --no-run-lintian -d
> unstable csh` does not, since in the former case bmake will get
> `MAKEFLAGS='w -j1'`.

Please provide more info (logs etc).

Thanks!

-- 
Cheers,
  Andrej

Bug#923423: confirm severe problem

[Joachim Wuttke]

To confirm the issue:

Unpacking texlive-fonts-extra (2020.20210202-3) over (2020.20210202-1) ...

is incredibly slow.

I'm running Debian/bullseye; the SSD is ext4 and far from full.

What is the status of this issue?
What are the conclusions after all the above correspondence?
Is there any hope?

- Joachim




smime.p7s
Description: S/MIME Cryptographic Signature

Bug#986213: RM: ansible/2.9.16+dfsg-1.1

[Raphael Hertzog]

Hello,

On Wed, 31 Mar 2021, Lee Garrett wrote:
> Unfortunately 2.10 didn't make it into bullseye in time (#984557). I tried
> getting the unit tests from 2.9.16 to work with python 3.9, but I had to give
> up. I don't feel comfortable with maintaining such a large package over the
> lifecycle of bullseye without unit tests, official py3.9 support, and security
> support running out in a few months, so please remove ansible from bullseye.

I know everybody is trying to do their best, in one side with ansible
maintainance and on the other side with release management but this
outcome is really not desirable.

Shipping bullseye without a core system administration tool like ansible
is not something that we should do. Our users are the clear losers of this
situation (and thus Debian as a whole).

Graham, can you please reconsider your position in #984557? Maybe have
some broader discussion within the release team on whether an exception
is to be made?

I know exceptions are the doors to more arbitrary unblock requests but
in general I have the feeling that we are too strict with such requests.

It is important for maintainers of software that don't have intractable
reverse dependencies to be able to push the last upstream release that can
be reallistically supported for 5 years even when the release schedule is
not 100% aligned with Debian (IMO sometimes we should even encourage the
packaging of release candidates with the right to push the final releases
through a stable update soon after).

And when the upstream release schedule is not at fault, but something else
is at fault, instead of punishing the maintainer that failed to act on
time, maybe have some "recovery" mechanism where X DD can support the
fact that having the (updated) package is important. By doing so they
would sign up to help if anyhing goes wrong with this update during the
release process.

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

Bug#986232: RFP: omapsapp -- offline maps application

[Martin]

Package: wnpp
Severity: wishlist

* Package name: omapsapp
  Version : 10.2.3
  Upstream Author : Many, see

https://github.com/omapsapp/omapsapp/blob/master/CONTRIBUTORS
* URL : https://omaps.app/
* License : Apache-2.0
  Programming Lang: C++, Python
  Description : offline maps application

OMaps is offline maps application, built on top of OpenStreetMap data.
It is a community-driven fork of MAPS.ME.

While the official releases target Android and iOS, Linux builds are
supported:

https://github.com/omapsapp/omapsapp/blob/master/docs/INSTALL.md#desktop-app

Unfortunately, there are a number of dependencies, that need
packaging:

https://github.com/omapsapp/omapsapp/blob/master/.gitmodules

Bug#986222: Acknowledgement (glibc: Fix O_NONBLOCK value on hppa architecture)

[Helge Deller]

This looks like a duplicate of #981650, which can't be fixed right now
due to the freeze. Merging the bugs.


Thanks for merging the bugs!
Does the freeze is relevant for non-released architectures like hppa as well?
I'm asking, because for hppa it would be very good if this gets fixed before
the release

Helge

Bug#986231: [util-linux] lsblk doesn't report FSTYPE for mirrored volumes

[Alex Volkov]

Package: util-linux
Version: 2.33.1-0.1
Severity: important

--- Please enter the report below this line. ---

lsblk lsblk doesn't report FSTYPE for mirrored volumes.

~$ lsblk -o +FSTYPE -n /dev/vg0/home -n /dev/vg0/mmedia
vg0-home   254:60 551,3G  0 lvm  /home   
vg0-mmedia 254:17   0 922,5G  0 lvm  /mnt/mmedia ext4

~$ mount | grep 'home \|mmedia '
/dev/mapper/vg0-home on /home type ext4 (rw,relatime,commit=10)
/dev/mapper/vg0-mmedia on /mnt/mmedia type ext4 (rw,relatime,commit=10)

~$ sudo lvs -o lv_name,lv_layout vg0/home vg0/mmedia
  LV Layout
  home   raid,raid1
  mmedia cache

(`mmedia` is a cachepool on top of a mirrored volume, and it gets reported 
normally)

This makes impossible to use e2scrub, as it relies onto lsblk for checking the 
filesystem type.


--- System information. ---
Architecture: 
Kernel:   Linux 5.10.19-bootes0-p-1000

Debian Release: 10.9
  991 stable  security.debian.org 
  991 stable  ftp.fi.debian.org 
  990 buster-backports ftp.debian.org 
   99 testing ftp.fi.debian.org 
   99 stable-backports www.deb-multimedia.org 
   99 stable  www.deb-multimedia.org 
  500 stable  deb.torproject.org 
  500 buster  ookla.bintray.com 
  500 buster  linux.dropbox.com 

--- Package information. ---
Depends   (Version) | Installed
===-+-
fdisk   | 2.33.1-0.1
login   (>= 1:4.5-1.1~) | 1:4.5-1.1


Package's Recommends field is empty.

Suggests(Version) | Installed
=-+-===
dosfstools| 4.1-2
kbd   | 2.0.4-4
 OR console-tools | 
util-linux-locales| 

Bug#985673: CVE-2020-15400

[Dmitry Smirnov]

On Monday, 22 March 2021 6:06:18 AM AEDT Moritz Muehlenhoff wrote:
> The XSS issue mentioned here was assigned CVE-2020-15400:
> https://bakery.cakephp.org/2020/04/18/cakephp_406_released.html

Thanks.


> cakephp in bullseye is quite old compared to upstream, is it
> still useful, should it be in bullseye?

It is used by ZoneMinder. Last time I've checked v2 was still supported,
but I don't know if that's still the case...

-- 
Regards,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

Man weeps to think that he will die so soon; woman, that she was born so
long ago.
-- H. L. Mencken

---

The consequences of the lockdowns are so devastating and far-reaching that
all decent and humane people must reject the whole strategy.
-- https://wrongaboutlockdown.com/


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

Bug#986230: davfs2: After silent crash of mount.davfs background process, accessing user space program hangs busy

[Andreas Feldner]

Package: davfs2
Version: 1.6.0-1
Severity: important

Dear Maintainer,

a move command was issued to move a directory from a local directory onto a 
mounted webdav resource.
The mount is system-wide, configured in /etc/fstab and handled by systemd.
After creating the target directory and successfully copying one file, mv hangs 
busy (100% of one CPU core).
Analysing the system showed that the corresponding mount.davfs background 
process was gone. No message as of
the cause could be found in /var/log/daemon.log. No message at all at that time 
is shown in dmesg. The mv 
process cannot be killed (not even with -KILL, neither with -STOP), trying to 
attach with strace or gdb
just hangs strace/gdb (can be killed). Any command accessing the stale webdav 
mount point also hangs unkillable,
however not consuming CPU.
The mv command does not hold a file descriptor on the stale mount, I'd conclude 
that it hangs in an "open"
system call. Its process status is R (running), not D (uninteruptible sleep)! 
The process is not consuming
more memory, not generating I/O, nor generating any diagnostic (neither itself 
nor from the kernel). It
remains a mystery what it is doing.
Unmounting the volume is not possible (device busy). After a lazy unmount, 
mounting the webdav resource again 
is possible and the mount point is usable for any future access. Moving the 
same directory again worked without
problems, so the presumed crash of mount.davfs was not related to the content.
The original mv command is still running constantly consuming one CPU core 
after 24 hours.

I'd expect to see a diagnostic log entry from the crashing mount.davfs process. 
I'd expect the user space
programs accessing the stale mount point to receive an I/O error.

Yours,
Andreas.

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

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

Versions of packages davfs2 depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.75
ii  libc6  2.31-10
ii  libneon27  0.31.2-1

davfs2 recommends no packages.

davfs2 suggests no packages.

-- Configuration Files:
/etc/davfs2/davfs2.conf changed:
connect_timeout 10
read_timeout 30
retry   5
max_retry 300
  #  httpauth, locks, ssl, httpbody, secrets, most

/etc/davfs2/secrets [Errno 13] Keine Berechtigung: '/etc/davfs2/secrets'

-- debconf information:
  davfs2/new_user: true
  davfs2/group_name: davfs2
  davfs2/non_root_users_confimed:
  davfs2/user_name: davfs2
* davfs2/suid_file: true
  davfs2/new_group: true

Bug#985652: libnettle8: New upstream version fixes ECDSA signature verification issue

[Salvatore Bonaccorso]

Hi,

On Sun, Mar 21, 2021 at 01:14:00PM +0100, Andreas Metzler wrote:
> Package: libnettle8
> Version: 3.7-2.1
> Severity: important
> 
> Hello,
> 
> nettle 3.7.2 features the following fix:
> 
> | This is a bugfix release, fixing a bug in ECDSA signature
> | verification that could lead to a denial of service attack
> | (via an assertion failure) or possibly incorrect results. It
> | also fixes a few related problems where scalars are required
> | to be canonically reduced modulo the ECC group order, but in
> | fact may be slightly larger.
> | 
> | Upgrading to the new version is strongly recommended.
> | 
> | Even when no assert is triggered in ecdsa_verify, ECC point
> | multiplication may get invalid intermediate values as input,
> | and produce incorrect results. It's trivial to construct
> | alleged signatures that result in invalid intermediate values.
> | It appears difficult to construct an alleged signature that
> | makes the function misbehave in such a way that an invalid
> | signature is accepted as valid, but such attacks can't be
> | ruled out without further analysis.
> 
> A DSA is currently not planned. Please upgrade nettle for sid (and
> bullseye) to 3.7.2.
> 
> FWIW I have forked the salsa repo and packaged the new version at
> . I have not sent a merge
> request since Debian packaging involves multiple branches.

FTR, the security issue part has been assigned CVE-2021-20305. Cf.
https://bugzilla.redhat.com/show_bug.cgi?id=1942533 .

Regards,
Salvatore

Bug#984439: Maybe related issue ...

[Gianfranco Costamagna]

Hello,
In Ubuntu I uploaded this ugly workaround for armhf

diff -pruN 6.2.2006+really6.2.1905+dfsg-2/debian/changelog 
6.2.2006+really6.2.1905+dfsg-2ubuntu1/debian/changelog
--- 6.2.2006+really6.2.1905+dfsg-2/debian/changelog 2020-12-21 
20:21:12.0 +
+++ 6.2.2006+really6.2.1905+dfsg-2ubuntu1/debian/changelog  2021-03-17 
09:27:28.0 +
@@ -1,3 +1,12 @@
+netgen (6.2.2006+really6.2.1905+dfsg-2ubuntu1) hirsute; urgency=medium
+
+  * Ignore test results on armhf. They failed since the begin, but testsuite
+was not ran, and they are already being worked/looked by upstream and
+Debian. They fail when armhf is ran on arm64 kernel, leading to unaligned
+accesses. See Debian bug #984439 and LP bug: #1919335
+
+ -- Gianfranco Costamagna   Wed, 17 Mar 2021 
10:27:28 +0100
+
 netgen (6.2.2006+really6.2.1905+dfsg-2) unstable; urgency=medium
 
   [ Christophe Trophime ]
diff -pruN 6.2.2006+really6.2.1905+dfsg-2/debian/rules 
6.2.2006+really6.2.1905+dfsg-2ubuntu1/debian/rules
--- 6.2.2006+really6.2.1905+dfsg-2/debian/rules 2020-12-21 20:21:06.0 
+
+++ 6.2.2006+really6.2.1905+dfsg-2ubuntu1/debian/rules  2021-03-17 
09:27:28.0 +
@@ -44,10 +44,17 @@ override_dh_auto_configure:
 
 override_dh_auto_test:
dh_auto_install
+ifeq ($(DEB_HOST_ARCH),armhf)
+   cd tests/pytest && \
+  PYTHONPATH=$(CURDIR)/debian/tmp/usr/lib/python3/dist-packages \
+  LD_LIBRARY_PATH=$(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH) \
+  python3 -m pytest || true
+else
cd tests/pytest && \
   PYTHONPATH=$(CURDIR)/debian/tmp/usr/lib/python3/dist-packages \
   LD_LIBRARY_PATH=$(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH) \
   python3 -m pytest
+endif
 
 override_dh_shlibdeps:
dh_shlibdeps -l/usr/lib/${DEB_HOST_MULTIARCH}/netgen

Do you think its worth a Debian upload too?

Gianfranco

Bug#986213: RM: ansible/2.9.16+dfsg-1.1

[Alexander Wirt]

On Wed, Mar 31, 2021 at 08:20:09PM +0200, Sebastiaan Couwenberg wrote:
> On 3/31/21 7:30 PM, Lee Garrett wrote:
> > Unfortunately 2.10 didn't make it into bullseye in time (#984557). I tried
> > getting the unit tests from 2.9.16 to work with python 3.9, but I had to 
> > give
> > up. I don't feel comfortable with maintaining such a large package over the
> > lifecycle of bullseye without unit tests, official py3.9 support, and 
> > security
> > support running out in a few months, so please remove ansible from bullseye.
> 
> Shipping bullseye without ansible is going to make many users unhappy.
> 
> Will you actively maintain the package in bullseye-backports instead?
And always remember, you can only update ansible in bpo with the version that
is in testing.

 
Alex