Bug#928009: file: "name use count (30) exceeded error with file on TIFF image inside mail"

[Paul Wise]

Control: forwarded -1 
https://github.com/file/file/commit/52400a1cf98e4cc252920239c291c66648c8fb3d

On Sat, 14 Mar 2020 12:58:53 +0800 Paul Wise wrote:

> Another workaround for this issue is to decrease the bytes limit:

I've bisected this upstream and the first commit that came up was a
change to the bytes limit, but changing the bytes limit on that old
version also causes failure, so I redid the bisection using the newer
bytes limit and came up with the above commit that adds support for
using recursion to traverse the JPEG markers and printing JPEG info.

https://github.com/file/file/commit/dd89d293fe62ca55542a5637e239b33404c58a8d

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#938027: [Python-modules-team] Bug#938027: Bug#938027: python-pip: Python2 removal in sid/bullseye

[Scott Kitterman]

On Friday, March 13, 2020 6:36:59 PM EDT Sandro Tosi wrote:
> On Fri, Mar 13, 2020 at 3:51 PM Scott Kitterman  
wrote:
> > I don't know of a reason not to go ahead, but if you do, please be careful
> > of what's already in git.  Update to the new version is staged there.  It
> > is blocked on updates for some of the packages it builds wheels from.
> oooh i see you were working on updating pip, wanna take care of
> dropping its py2 suppor while at it? i cant really tell from the 2
> seconds look i gave the package what's actually required :)

I should be able to do it, but there are still some build-depends that need 
updating, so I'm not sure how quickly.

Scott K

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

Bug#953857: lintian: t/tags/odd-inputs/strings-elf-detection/eval/literal fails on ubuntu

[Dimitri John Ledkov]

Package: lintian
Version: 2.48.0
Severity: wishlist

Dear Maintainer,

t/tags/odd-inputs/strings-elf-detection/eval/literal fails on ubuntu
with failing to produce tags for dbgsym package.

It seems to be due to lintian not processing .ddeb packages on Ubuntu
at all.

Note unlike Debian, dbgsym packages in Ubuntu have Package-Type field
set to 'ddeb' and filename extension changed to .ddeb.

I've tried to find a few places where Package-Type is used, and regexp
hardcodes .deb pattern, but tweaking all of those to dd?eb did make
the test case pass. Thus I have disabled those assertions.

Regards,

Dimitri.

Bug#928009: file: "name use count (30) exceeded error with file on TIFF image inside mail"

[Paul Wise]

On Wed, 24 Jul 2019 13:41:54 +0800 Paul Wise wrote:

> The workaround for this issue is to increase the name recursion limit:

Another workaround for this issue is to decrease the bytes limit:

$ file --parameter bytes=857393 ../test.jpg ; echo $?
../test.jpg: JPEG image data, JFIF standard 1.01, resolution (DPI),
density 240x240, segment length 16, Exif Standard: [TIFF image data,
big-endian, direntries=8, description=Picture saved with settings
embedded., orientation=upper-left, xresolution=148, yresolution=156,
resolutionunit=2, software=Adobe Photoshop Lightroom 6.1.1 (Windows),
datetime=2017:08:17 11:16:47]
0

-- 
bye,
pabs

https://bonedaddy.net/pabs3/


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

Bug#953854: workaround

[sergio]

https://gitlab.gnome.org/GNOME/gimp/issues/4490

I confirm that removing /usr/lib/gimp/2.0/plug-ins/pagecurl/pagecurl is
a workaround.

-- 
sergio.

Bug#953856: dict-gazetteer2k: should this package be removed?

[Sandro Tosi]

Source: dict-gazetteer2k
Severity: serious

Hello,
i believe this package should be removed:

* python2-only
* last upstream upload in 2001 (makes sense)
* last maintainer upload in 2006, from there 4 NMUs
* last reverse dependes on python-dictclient (py2removal effort)
* does it still make sense to skip 2000 US Census data as a package?

If i dont here back within a week with a good reason to keep this package, i'll
file for its removal.

Regards,
Sandro

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
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= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#953855: libspdlog-dev: tries to include file that doesn't exist

[Hubert Chathi]

Package: libspdlog-dev
Severity: normal

Dear Maintainer,

As seen in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952613,
nheko recently FTBFS after #include-ing /usr/include/spdlog/spdlog.h
which caused /usr/include/spdlog/fmt/fmt.h to be #includ-ed, which tried
to #include spdlog/fmt/bundled/core.h, which is no longer in
libspdlog-dev.  It looks like, since libspdlog-dev depends on
libfmt-dev, it should be #include-ing , etc. instead of
trying to use the bundled version which doesn't exist.

I've worked around the FTBFS in nheko by defining SPDLOG_FMT_EXTERNAL
(and FMT_HEADER_ONLY) to force the use of the external libfmt.

Thanks

-- System Information:
Debian Release: 10.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (300, 'testing'), (200, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#953854: gimp: Segmentation fault on start after the last dist-upgrade

[sergio]

Package: gimp
Version: 2.10.14-2+b1
Severity: important

Dear Maintainer,

gimp start segfaults just at start after the last update.

I've tried to remove .config/GIMP, but this doesn't help.


GNU Image Manipulation Program version 2.10.14
git-describe: GIMP_2_10_12-511-ga4f55d6c7e
C compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 
9.2.1-31' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-9 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib 
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch 
--disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none,hsa --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean 
--enable-link-mutex
Thread model: posix
gcc version 9.2.1 20200306 (Debian 9.2.1-31)

using babl version 0.1.74 (compiled against version 0.1.74)
using GEGL version 0.4.22 (compiled against version 0.4.22)
using GLib version 2.64.0 (compiled against version 2.64.0)
using GdkPixbuf version 2.40.0 (compiled against version 2.40.0)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.42.3 (compiled against version 1.42.3)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Segmentation fault

Stack trace:
```
/usr/lib/libgimpbase-2.0.so.0(gimp_stack_trace_print+0x398)[0x7f81cbb74398]
gimp(+0xd7980)[0x557848736980]
gimp(+0xd7da8)[0x557848736da8]
gimp(+0xd8419)[0x557848737419]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x14110)[0x7f81cb06d110]
gimp(gimp_param_spec_layer_id+0x64)[0x557848ac3704]
gimp(gimp_pdb_compat_param_spec+0x1c7)[0x5578489db647]
gimp(gimp_plug_in_handle_message+0x1197)[0x5578489e8067]
gimp(gimp_plug_in_manager_call_query+0x191)[0x5578489f6681]
gimp(gimp_plug_in_manager_restore+0x796)[0x5578489ee606]
gimp(+0x3ad24d)[0x557848a0c24d]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x1a2)[0x7f81cb2fefd2]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x26f06)[0x7f81cb311f06]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xbdf)[0x7f81cb31d54f]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7f81cb31dedf]
gimp(gimp_restore+0x102)[0x557848a0b7d2]
gimp(app_run+0x4ab)[0x5578487362bb]
gimp(main+0x37e)[0x557848735a4e]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f81caebae0b]
gimp(_start+0x2a)[0x557848735bda]

Bug#953853: musl-tools: should it be Multi-Arch: foreign?

[Thorsten Glaser]

Package: musl-tools
Version: 1.1.24-1
Severity: wishlist

I just discovered https://bootstrap.debian.net/cross_all/mksh.html
seems to be hung up on musl-tools wanting the native compiler.

Wondering whether, if musl-tools were M-A:foreign, it could satisfy
cross-compiling dependencies?

Perhaps, even if not (and we’d need something else) M-A:foreign
won’t hurt? (Cosidering the i386/amd64 case for example.)

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages musl-tools depends on:
ii  gcc   4:9.2.1-3.1
ii  musl-dev  1.1.24-1

musl-tools recommends no packages.

musl-tools suggests no packages.

-- no debconf information

Bug#948789: [racket/racket] Illegal Instruction on freescale i.mx53 (armv7l) (#3050)

[David Bremner]

Paulo Matos  writes:

> Upstream issue reference for: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948789
> Mailing list information: 
> https://groups.google.com/d/msg/racket-dev/o631-azv-5g/r9Ct1H_KDAAJ

I'm not sure if this is a surprise or not, but it looks like the 7.6 is
breaking in the same place:

https://buildd.debian.org/status/fetch.php?pkg=racket=armhf=7.6%2Bdfsg1-1=1584149113=0

Bug#937150: nodeenv: diff for NMU version 0.13.4-1.1

[Sandro Tosi]

Control: tags 937150 + patch


Dear maintainer,

I've prepared an NMU for nodeenv (versioned as 0.13.4-1.1). The diff
is attached to this message.

Regards.

diff -Nru nodeenv-0.13.4/debian/changelog nodeenv-0.13.4/debian/changelog
--- nodeenv-0.13.4/debian/changelog	2015-08-31 16:55:28.0 -0400
+++ nodeenv-0.13.4/debian/changelog	2020-03-13 22:05:05.0 -0400
@@ -1,3 +1,10 @@
+nodeenv (0.13.4-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Replace spurious python2.7 dependency with python3; Closes: #937150
+
+ -- Sandro Tosi   Fri, 13 Mar 2020 22:05:05 -0400
+
 nodeenv (0.13.4-1) unstable; urgency=medium
 
   * New upstream version
diff -Nru nodeenv-0.13.4/debian/control nodeenv-0.13.4/debian/control
--- nodeenv-0.13.4/debian/control	2015-08-16 13:35:33.0 -0400
+++ nodeenv-0.13.4/debian/control	2020-03-13 22:03:19.0 -0400
@@ -16,7 +16,7 @@
 Package: nodeenv
 Architecture: all
 Depends: python3-pkg-resources, ${misc:Depends}, ${python3:Depends}, make,
- gcc (>= 4:4.9.1) | nodejs, g++ (>= 4:4.9.1) | nodejs, libssl-dev | nodejs, python2.7 | nodejs
+ gcc (>= 4:4.9.1) | nodejs, g++ (>= 4:4.9.1) | nodejs, libssl-dev | nodejs, python3 | nodejs
 Description: Node.js virtual environment builder
  Tool to create isolated node.js environments with their own installation
  directories that don't share libraries with other node.js virtual

Bug#935706: lintian: Make tag certainty a programmatic assessment

[Felix Lechner]

[cc'ing the bug this time]

Hi Chris,

On Fri, Mar 13, 2020 at 4:58 PM Chris Lamb  wrote:
>
> I would very much
> suggest we repurpose "severity" here instead of inventing a new term.

That is exactly what I thought you might think (and it is why I
prepared a merge request instead of committing directly).

Just one thought, please: Do you think the term severity may be, well,
too severe?

Ever since Michael Stapelberg called Lintian the policy's
"programmatic embodiment" I have been trying to round its edges. (I
even have a new logo idea, an L-shaped allen wrench instead of a
square.) Is there not another, softer term like "alert level",
"significance" or "relevance" we can use?

Kind regards
Felix


On Fri, Mar 13, 2020 at 4:58 PM Chris Lamb  wrote:
>
> Hi Felix,
>
> > > it appears to simply encode the currently unhelpful distinction between
> > > "wild-guess", "possible" and "certain" in a new and relatively unfamiliar
> > > way with a slightly ambiguous name.
> >
> > I think this is a case of miscommunication.
> […]
> > Any references to certainty or its values, "wild-guess", "possible"
> > and "certain", are gone. The table you quote is being removed.
>
> Ah... very glad to hear we're on the same page here. I think I was
> misled by the quoting of the table as it appeared to imply that
> "certainty" or something similar would be retained, when that is not
> what is being proposed here.
>
> Regarding the name of this new combined field, we should never forget
> that is not only graphical applications that have a "user interface" —
> even command-line utilities have one, but it is merely encoded in
> ASCII form. Interface design is a long-established field and has
> various hard-won best practices and conventions, more easily noticed
> in GUI programs with regard to visual design, but an oft-neglected and
> extremely important component of a good interface concerns itself with
> the terminology used. For example, words should not surprise or
> confuse the user, and indeed should be as entirely seamless and
> unnoticable as possible. "Don't make me think", the saying goes.
> Another way of putting this is that if the user even consciously has
> to consider the word, it is ipso facto not a good word.
>
> I mention this because I believe "visibility" would not be serving our
> users best. There are examples where a technically-correct name like
> this, even if backed up by a well-meaning dictionary definition might
> very well fit the idea better but we must have some empathy for the
> casual and regular users of Lintian (a very old project, remember!)
> who will be expecting the term "severity", even though that may not
> 100% fit the idea of this new tag (eg. not quite matching the BTS or
> whatever). In other words, if any user of Lintian now thinks questions
> like "where did severities go? what is visibility? how does it
> differ?" then we are not doing our job to the best of our ability.
>
> Anyway, unless I'm misunderstanding something again, I would very much
> suggest we repurpose "severity" here instead of inventing a new term.
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org chris-lamb.co.uk
>`-

Bug#807990: oath-toolkit: diff for NMU version 2.6.1-1.4

[anarcat]

[this is a resend: the prevous version had the wrong date in
debian/changelog]

Dear maintainer,

I've prepared an NMU for oath-toolkit (versioned as 2.6.1-1.4) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
diff -Nru oath-toolkit-2.6.1/debian/changelog oath-toolkit-2.6.1/debian/changelog
--- oath-toolkit-2.6.1/debian/changelog	2019-02-09 10:39:41.0 -0500
+++ oath-toolkit-2.6.1/debian/changelog	2016-08-20 09:51:41.0 -0400
@@ -1,3 +1,11 @@
+oath-toolkit (2.6.1-1.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * patch: fail gracefully for missing users (Closes: #807990)
+  * push to salsa
+
+ -- Antoine Beaupré   Sat, 20 Aug 2016 09:51:41 -0400
+
 oath-toolkit (2.6.1-1.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru oath-toolkit-2.6.1/debian/control oath-toolkit-2.6.1/debian/control
--- oath-toolkit-2.6.1/debian/control	2018-06-22 13:48:52.0 -0400
+++ oath-toolkit-2.6.1/debian/control	2016-08-20 09:51:41.0 -0400
@@ -6,8 +6,8 @@
 Build-Depends: cdbs, debhelper (>= 7.0.0), libpam0g-dev, datefudge, gtk-doc-tools, dblatex, libxml2-utils, libxmlsec1-dev, dh-autoreconf
 Standards-Version: 3.9.6
 Homepage: http://www.nongnu.org/oath-toolkit/
-Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/oath-toolkit.git
-Vcs-Git: git://anonscm.debian.org/collab-maint/oath-toolkit.git
+Vcs-Browser: https://salsa.debian.org/debian/oath-toolkit
+Vcs-Git: https://salsa.debian.org/debian/oath-toolkit.git
 
 Package: liboath-dev
 Section: libdevel
diff -Nru oath-toolkit-2.6.1/debian/patches/0001-fail-gracefully-for-missing-users.patch oath-toolkit-2.6.1/debian/patches/0001-fail-gracefully-for-missing-users.patch
--- oath-toolkit-2.6.1/debian/patches/0001-fail-gracefully-for-missing-users.patch	1969-12-31 19:00:00.0 -0500
+++ oath-toolkit-2.6.1/debian/patches/0001-fail-gracefully-for-missing-users.patch	2016-08-20 09:51:41.0 -0400
@@ -0,0 +1,83 @@
+From 509c4cda7e08384d7cd16dfdb3917b4373f1e36e Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
+Date: Mon, 1 Aug 2016 12:25:10 -0400
+Subject: [PATCH] fail gracefully for missing users
+
+when the pam module is enabled, it forces *all* users to immediately
+start using OATH, or they can't login at all.
+
+a more progressive approach would seem more reasonable to me,
+especially since each user need to get an admin user to update the
+central file for them.
+
+this patch adds an early check to the users file and makes sure the
+user exists before prompting for a password.
+
+if the user is missing, it exits early with a standard error code
+(PAM_USER_UNKNOWN) which can then be ignored in the PAM configuration
+(as shown in the README file). this leaves the policy decision up to
+the admin (and defaults to "fail closed").
+
+if the user is present, the code path remains the same except the
+usersfile is scanned twice, which may be a performance penalty on very
+slow filesystems or very large files. the only workaround I can think
+of for this would be to load the whole file into memory, but this
+could have significant memory impact on large files.
+
+the function used (`oath_authenticate_usersfile`) is a little overkill
+as it actually goes and tries to authenticate the user with an empty
+password. this is harmless because the file isn't updated if the OTP
+is incorrect and because no warning is sent to syslog.
+
+a possible improvement on this would be to have a warning shown to the
+user inciting them to configure OATH or to warn them about a possible
+typo in their username before they enter their regular passphrase
+---
+ pam_oath/README |  2 +-
+ pam_oath/pam_oath.c | 17 +
+ 2 files changed, 18 insertions(+), 1 deletion(-)
+
+diff --git a/pam_oath/README b/pam_oath/README
+index bef4265..24b9f8b 100644
+--- a/pam_oath/README
 b/pam_oath/README
+@@ -23,7 +23,7 @@ window open before making any changes!
+ 
+ -
+ # head -1 /etc/pam.d/su
+-auth requisite pam_oath.so debug usersfile=/etc/users.oath window=20
++auth [user_unknown=ignore success=ok] pam_oath.so debug usersfile=/etc/users.oath window=20
+ #
+ -
+ 
+diff --git a/pam_oath/pam_oath.c b/pam_oath/pam_oath.c
+index 2820318..25a3452 100644
+--- a/pam_oath/pam_oath.c
 b/pam_oath/pam_oath.c
+@@ -162,6 +162,23 @@ pam_sm_authenticate (pam_handle_t * pamh,
+ }
+   DBG (("get user returned: %s", user));
+ 
++  // quick check to skip unconfigured users before prompting for password
++  {
++time_t last_otp;
++otp[0] = '\0';
++rc = oath_authenticate_usersfile (cfg.usersfile,
++  user,
++  otp, cfg.window, onlypasswd, _otp);
++
++DBG (("authenticate first pass rc %d (%s: %s) last otp %s", rc,
++  oath_strerror_name (rc) ? oath_strerror_name (rc) : "UNKNOWN",
++  oath_strerror (rc), ctime (_otp)));
++if (rc == 

Bug#953852: ardentryst: should this package be removed?

[Sandro Tosi]

Package: ardentryst
Severity: serious

Hello,
i believe this package should be removed:

* python2-only
* dead upstream:
  * last new upstream release in debian in 2011
  * https://sourceforge.net/projects/ardentryst/ reports "Status: Abandoned"
  * http://www.jordantrudgett.com/ardentryst/ is dead
* low popcon

If i dont hear back within a week with a good reason to keep this package, i'll
file for its removal.

Regards,
Sandro

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
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= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ardentryst depends on:
ii  fonts-freefont-ttf  20120503-9
ii  python  2.7.16-1
pn  python-pygame   

ardentryst recommends no packages.

ardentryst suggests no packages.

Bug#948712: raspi-firmware: Please add support for Raspberry Pi4

[Gunnar Wolf]

Hello,

As far as I understand, the CPU in the RPi4 is a *completely*
different beast from the ones in the rest of the family. It seems it
will not require a binary firmware loader anymore!

Right now, it is not *yet* bootable using the stock Linux kernel, but
there are people working on its support. I have asked them to update
this bug when our kernel can boot on RPi4.

Bug#936667: fixed in grpc 1.24.3-1

[Sandro Tosi]

Hey Laszlo,

> Format: 1.8
> Date: Wed, 23 Oct 2019 05:45:37 +
> Source: grpc
> Binary: libgrpc++-dev libgrpc++1 libgrpc-dev libgrpc8 protobuf-compiler-grpc 
> protobuf-compiler-grpc-dbgsym python3-grpcio python3-grpcio-dbgsym ruby-grpc 
> ruby-grpc-dbgsym ruby-grpc-tools
> Architecture: source amd64 all
> Version: 1.24.3-1
> Distribution: experimental

could you please upload this package to unstable? grpc is the last
reverse dependency of python-sphinx-rtd-theme, so once this his sid,
we can remove that package.

Thanks,
Sandro

Bug#953851: pymissile: should this package be removed?

[Sandro Tosi]

Package: pymissile
Severity: serious

Hello,
i believe this package should be removed:

* python2-only
* dead upstream, no new releases since 2007 (!)
* no debian uploads since 2016
* last reverse dependency of python-usb (py2removal effort)

if i dont hear back within a week with a good reason to keep this package, i'll
file for its removal.

Regards,
Sandro

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
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= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pymissile depends on:
ii  python2.7.16-1
pn  python-urwid  
pn  python-usb

pymissile recommends no packages.

pymissile suggests no packages.

Bug#953811: lintian: handle ADTTMP fallback code

[Thorsten Glaser]

Chris Lamb dixit:

>Debian tool that is within our locus of control, so I would very much
>prefer that src:devscripts is fixed instead of preventing Lintian

Oh… looking at it now, it appears that the sid version is indeed fixed.

I’ll be keeping this though, for now… I may need it for backports.

bye,
//mirabilos
-- 
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival

Bug#953850: tinywm: should this package be removed?

[Sandro Tosi]

Package: tinywm
Severity: serious

Hello,
i believe this package should be removed:

* no upstream release since 2005 (!!!)
* no upload since 2012
* last reverse dependency of python-xlib (py2removal effort)

if i dont hear back within a week a good reason to keep this package, i'll file
for its removal

Regards,
Sandro

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
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= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tinywm depends on:
ii  libc6 2.29-1
ii  libx11-6  2:1.6.7-1

tinywm recommends no packages.

tinywm suggests no packages.

Bug#881826: devscripts: sadt: does not parse debian/control with comments

[Thorsten Glaser]

Package: devscripts
Version: 2.20.2
Followup-For: Bug #881826

Workaround: With a debian/control like this…

Source: s
Build-Depends:
# some comment here
 sl
Standards-Version: 4.5.0

… it works (I wondered why I wasn’t hit by this sadt bug).


-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
DEBCHANGE_AUTO_NMU=no
DEBCHANGE_MAINTTRAILER=no
DEBCHANGE_MULTIMAINT_MERGE=yes

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.7
ii  fakeroot  1.24-1
ii  file  1:5.38-4
ii  gnupg 2.2.19-3
ii  gnupg22.2.19-3
ii  gpgv  2.2.19-3
ii  libc6 2.30-2
ii  libfile-homedir-perl  1.004-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20180523.0-2
ii  libmoo-perl   2.003006-1
ii  libwww-perl   6.43-1
ii  patchutils0.3.4-2+b1
ii  perl  5.30.0-9
ii  python3   3.8.2-1
ii  sensible-utils0.0.12+nmu1
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 2.0.0
ii  at  3.1.23-1+b1
ii  curl7.68.0-1
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2020.02.02
ii  dput1.0.3
ii  equivs  2.2.0
pn  libdistro-info-perl 
ii  libdpkg-perl1.19.7
ii  libencode-locale-perl   1.05-1
pn  libgit-wrapper-perl 
pn  libgitlab-api-v4-perl   
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
pn  libsoap-lite-perl   
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-2
pn  licensecheck
ii  lintian 2.55.0
ii  man-db  2.9.1-1
ii  patch   2.7.6-6
ii  python3-apt 1.9.10
ii  python3-debian  0.1.36
ii  python3-magic   2:0.4.15-3
ii  python3-requests2.22.0-2
pn  python3-unidiff 
pn  python3-xdg 
ii  strace  4.26-0.2
ii  unzip   6.0-25
ii  wget1.20.3-1+b2
ii  xz-utils5.2.4-1+b1

Versions of packages devscripts suggests:
ii  adequate  0.15.2
pn  autopkgtest   
pn  bls-standalone
ii  bsd-mailx [mailx] 8.1.2-0.20180807cvs-1+b1
ii  build-essential   12.8
pn  check-all-the-things  
pn  cvs-buildpackage  
ii  debhelper 12.9
pn  devscripts-el 
ii  diffoscope137
pn  disorderfs
pn  dose-extra
pn  duck  
pn  faketime  
pn  gnuplot   
pn  how-can-i-help
pn  libauthen-sasl-perl   
ii  libdbd-pg-perl3.10.4-1
pn  libfile-desktopentry-perl 
pn  libnet-smtps-perl 
pn  libterm-size-perl 
ii  libtimedate-perl  2.3200-1
ii  libyaml-syck-perl 1.32-2
pn  mozilla-devscripts
pn  mutt  
ii  openssh-client [ssh-client]   1:8.2p1-4
pn  piuparts  
ii  postgresql-client-12 [postgresql-client]  12.2-1+b1
ii  quilt 0.65-3
pn  ratt  
pn  reprotest 
pn  svn-buildpackage  
ii  w3m   0.5.3-37+b1

-- no debconf information

Bug#953849: debootstrap: broken runtime (at least in d-i)

[Cyril Brulebois]

Package: debootstrap
Version: 1.0.121
Severity: serious
Justification: RoM

[ Could have been filed against debootstrap-udeb instead, but this might
also break use cases with regular debootstrap too. ]

While reviewing the recent changes in debootstrap (#953759), I was
concerned with commit 7ecd8191c377bc062b5816195dab3e38ab45c17d, which
removes a safeguard without real rationale.

Today, Johannes 'josch' Schauer was working on some autopkgtest to be
added to debian-installer, and detected a failure to install. And this
confirms the fears I expressed on #debian-boot during my quick review:
the safeguard is needed! Without it, one can end up getting an empty
string in that variable, leading to unmounting the whole /target
directory, breaking the installation entirely.

I'll reinstate that safeguard.


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

Bug#953276: bug 953276 is forwarded to https://github.com/golang/go/issues/34191

[Guillem Jover]

Hi!

On Fri, 2020-03-13 at 18:33:08 +0100, Guillem Jover wrote:
> On Mon, 2020-03-09 at 15:36:32 +1300, Michael Hudson-Doyle wrote:
> > forwarded 953276 https://github.com/golang/go/issues/34191
> 
> On Mon, 2020-03-09 at 13:57:45 +0100, Dr. Tobias Quathamer wrote:
> > reassign 953276 src:golang-1.14 1.14-1
> > thanks
> 
> > golang-1.13 is about to be removed from unstable and will be superseded
> > by golang-1.14.
> 
> Thanks. This has now been fixed upstream. I've tested the patch proposed
> at  and it build
> golang-1.14 fine.
> 
> Attached the upstream patch.

BTW I'm told by upstream the patch that finally got comitted git
slightly modified from the one I attached previously. :)

Regards,
Guillem

Bug#938027: python-pip: Python2 removal in sid/bullseye

[Barry Warsaw]

Hi Sandro.

Honestly, I have not contributed to Debian in a couple of years, and I don’t 
see that changing any time soon.  Best to contact Matthias, the Python Team, or 
just do whatever you think is best.

Cheers,
-Barry

> On Mar 13, 2020, at 12:32, Sandro Tosi  wrote:
> 
> On Fri, 30 Aug 2019 07:44:13 + Matthias Klose  wrote:
>> Package: src:python-pip
>> Version: 18.1-5
>> Severity: normal
>> Tags: sid bullseye
>> User: debian-pyt...@lists.debian.org
>> Usertags: py2removal
> 
> the only rdeps of `bin:python-pip` have been removed from testing, so
> it's probably time we drop this package too!
> 
> Carl, Barry: do you see anything wrong with this? what should we do
> about the -whl package? is it still required for something or can we
> drop it along with bin:python-pip? is it needed for anything
> py3k-related?
> 
> I would like to proceed quickly, ideally within a week.
> 
> thanks,
> Sandro



signature.asc
Description: Message signed with OpenPGP

Bug#807990: oath-toolkit: diff for NMU version 2.6.1-1.4

[anarcat]

Control: tags 807990 + pending

Dear maintainer,

I've prepared an NMU for oath-toolkit (versioned as 2.6.1-1.4) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru oath-toolkit-2.6.1/debian/changelog oath-toolkit-2.6.1/debian/changelog
--- oath-toolkit-2.6.1/debian/changelog	2019-02-09 10:39:41.0 -0500
+++ oath-toolkit-2.6.1/debian/changelog	2016-08-20 09:51:41.0 -0400
@@ -1,3 +1,11 @@
+oath-toolkit (2.6.1-1.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * patch: fail gracefully for missing users (Closes: #807990)
+  * push to salsa
+
+ -- Antoine Beaupré   Sat, 20 Aug 2016 09:51:41 -0400
+
 oath-toolkit (2.6.1-1.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru oath-toolkit-2.6.1/debian/control oath-toolkit-2.6.1/debian/control
--- oath-toolkit-2.6.1/debian/control	2018-06-22 13:48:52.0 -0400
+++ oath-toolkit-2.6.1/debian/control	2016-08-20 09:51:41.0 -0400
@@ -6,8 +6,8 @@
 Build-Depends: cdbs, debhelper (>= 7.0.0), libpam0g-dev, datefudge, gtk-doc-tools, dblatex, libxml2-utils, libxmlsec1-dev, dh-autoreconf
 Standards-Version: 3.9.6
 Homepage: http://www.nongnu.org/oath-toolkit/
-Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/oath-toolkit.git
-Vcs-Git: git://anonscm.debian.org/collab-maint/oath-toolkit.git
+Vcs-Browser: https://salsa.debian.org/debian/oath-toolkit
+Vcs-Git: https://salsa.debian.org/debian/oath-toolkit.git
 
 Package: liboath-dev
 Section: libdevel
diff -Nru oath-toolkit-2.6.1/debian/patches/0001-fail-gracefully-for-missing-users.patch oath-toolkit-2.6.1/debian/patches/0001-fail-gracefully-for-missing-users.patch
--- oath-toolkit-2.6.1/debian/patches/0001-fail-gracefully-for-missing-users.patch	1969-12-31 19:00:00.0 -0500
+++ oath-toolkit-2.6.1/debian/patches/0001-fail-gracefully-for-missing-users.patch	2016-08-20 09:51:41.0 -0400
@@ -0,0 +1,83 @@
+From 509c4cda7e08384d7cd16dfdb3917b4373f1e36e Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
+Date: Mon, 1 Aug 2016 12:25:10 -0400
+Subject: [PATCH] fail gracefully for missing users
+
+when the pam module is enabled, it forces *all* users to immediately
+start using OATH, or they can't login at all.
+
+a more progressive approach would seem more reasonable to me,
+especially since each user need to get an admin user to update the
+central file for them.
+
+this patch adds an early check to the users file and makes sure the
+user exists before prompting for a password.
+
+if the user is missing, it exits early with a standard error code
+(PAM_USER_UNKNOWN) which can then be ignored in the PAM configuration
+(as shown in the README file). this leaves the policy decision up to
+the admin (and defaults to "fail closed").
+
+if the user is present, the code path remains the same except the
+usersfile is scanned twice, which may be a performance penalty on very
+slow filesystems or very large files. the only workaround I can think
+of for this would be to load the whole file into memory, but this
+could have significant memory impact on large files.
+
+the function used (`oath_authenticate_usersfile`) is a little overkill
+as it actually goes and tries to authenticate the user with an empty
+password. this is harmless because the file isn't updated if the OTP
+is incorrect and because no warning is sent to syslog.
+
+a possible improvement on this would be to have a warning shown to the
+user inciting them to configure OATH or to warn them about a possible
+typo in their username before they enter their regular passphrase
+---
+ pam_oath/README |  2 +-
+ pam_oath/pam_oath.c | 17 +
+ 2 files changed, 18 insertions(+), 1 deletion(-)
+
+diff --git a/pam_oath/README b/pam_oath/README
+index bef4265..24b9f8b 100644
+--- a/pam_oath/README
 b/pam_oath/README
+@@ -23,7 +23,7 @@ window open before making any changes!
+ 
+ -
+ # head -1 /etc/pam.d/su
+-auth requisite pam_oath.so debug usersfile=/etc/users.oath window=20
++auth [user_unknown=ignore success=ok] pam_oath.so debug usersfile=/etc/users.oath window=20
+ #
+ -
+ 
+diff --git a/pam_oath/pam_oath.c b/pam_oath/pam_oath.c
+index 2820318..25a3452 100644
+--- a/pam_oath/pam_oath.c
 b/pam_oath/pam_oath.c
+@@ -162,6 +162,23 @@ pam_sm_authenticate (pam_handle_t * pamh,
+ }
+   DBG (("get user returned: %s", user));
+ 
++  // quick check to skip unconfigured users before prompting for password
++  {
++time_t last_otp;
++otp[0] = '\0';
++rc = oath_authenticate_usersfile (cfg.usersfile,
++  user,
++  otp, cfg.window, onlypasswd, _otp);
++
++DBG (("authenticate first pass rc %d (%s: %s) last otp %s", rc,
++  oath_strerror_name (rc) ? oath_strerror_name (rc) : "UNKNOWN",
++  oath_strerror (rc), ctime (_otp)));
++if (rc == OATH_UNKNOWN_USER)
++  {
++return PAM_USER_UNKNOWN;
++   

Bug#930780: ITS: pssh

[Sandro Tosi]

On Thu, 20 Jun 2019 06:24:13 -0700 Mo Zhou  wrote:
> Source: pssh
> Version: 2.3.1-1
>
> I plan to salvage pssh and fix at least the following bug:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891340

Not sure if Mo is still interested in salvaging this package, other
wise this could be a nice project for someone willing to improve their
packaging skills. this would translate to:

* bring it under PAPT maintenance
* update to the latest upstream release (check #891340 or even
https://github.com/ParallelSSH/parallel-ssh ?)
* drop python2 support, add python3 support
* upload to debian.

Regards,
Sandro

Bug#925758: librecad: ftbfs with GCC-9

[Sudip Mukherjee]

I was looking at this bug today and I did not get any error in building
the current version.

Build Architecture: amd64
Build Type: full
Build-Space: 1596216
Build-Time: 325
Distribution: unstable
Host Architecture: amd64
Install-Time: 192
Job: /home/sudip/debian/librecad/librecad_2.1.3-1.2.dsc
Lintian: info
Machine Architecture: amd64
Package: librecad
Package-Time: 564
Source-Version: 2.1.3-1.2
Space: 1596216
Status: successful
Version: 2.1.3-1.2

Can you please test it again..

--
Regards
Sudip

Bug#925753: libneo4j-client: diff for NMU version 2.2.0-1.1

[Sudip Mukherjee]

Control: tags 925753 + patch
Control: tags 925753 + pending

Dear maintainer,

I've prepared an NMU for libneo4j-client (versioned as 2.2.0-1.1) and
uploaded it to mentors for sponsoring. Please feel free to tell me if I
should remove it.

--
Regards
Sudip

diff -Nru libneo4j-client-2.2.0/debian/changelog 
libneo4j-client-2.2.0/debian/changelog
--- libneo4j-client-2.2.0/debian/changelog  2017-09-20 08:30:52.0 
+0100
+++ libneo4j-client-2.2.0/debian/changelog  2020-03-13 23:36:49.0 
+
@@ -1,3 +1,10 @@
+libneo4j-client (2.2.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with gcc-9. (Closes: #925753)
+
+ -- Sudip Mukherjee   Fri, 13 Mar 2020 23:36:49 
+
+
 libneo4j-client (2.2.0-1) unstable; urgency=medium
 
   * New upstream release 2.2.0
diff -Nru libneo4j-client-2.2.0/debian/patches/fix_null.patch 
libneo4j-client-2.2.0/debian/patches/fix_null.patch
--- libneo4j-client-2.2.0/debian/patches/fix_null.patch 1970-01-01 
01:00:00.0 +0100
+++ libneo4j-client-2.2.0/debian/patches/fix_null.patch 2020-03-13 
23:36:49.0 +
@@ -0,0 +1,23 @@
+Description: Fix null-termination warnings from gcc8
+
+upstream - 
https://github.com/cleishm/libneo4j-client/commit/960bf2eb620370bd35534ea28b977c748d45aea3
 
+Bug-Debian: https://bugs.debian.org/925753
+
+---
+
+--- libneo4j-client-2.2.0.orig/src/lib/client_config.c
 libneo4j-client-2.2.0/src/lib/client_config.c
+@@ -492,9 +492,11 @@ int ensure_basic_auth_credentials(neo4j_
+ char username_buf[NEO4J_MAXUSERNAMELEN + 1];
+ char password_buf[NEO4J_MAXPASSWORDLEN + 1];
+ strncpy(username_buf, (config->username != NULL)? config->username : "",
+-sizeof(username_buf));
++sizeof(username_buf) - 1);
++username_buf[sizeof(username_buf) - 1] = '\0';
+ strncpy(password_buf, (config->password != NULL)? config->password : "",
+-sizeof(password_buf));
++sizeof(password_buf) - 1);
++password_buf[sizeof(password_buf) - 1] = '\0';
+ 
+ int err = -1;
+ 
diff -Nru libneo4j-client-2.2.0/debian/patches/series 
libneo4j-client-2.2.0/debian/patches/series
--- libneo4j-client-2.2.0/debian/patches/series 1970-01-01 01:00:00.0 
+0100
+++ libneo4j-client-2.2.0/debian/patches/series 2020-03-13 23:36:49.0 
+
@@ -0,0 +1,2 @@
+fix_null.patch
+use_memcpy.patch
diff -Nru libneo4j-client-2.2.0/debian/patches/use_memcpy.patch 
libneo4j-client-2.2.0/debian/patches/use_memcpy.patch
--- libneo4j-client-2.2.0/debian/patches/use_memcpy.patch   1970-01-01 
01:00:00.0 +0100
+++ libneo4j-client-2.2.0/debian/patches/use_memcpy.patch   2020-03-13 
23:36:49.0 +
@@ -0,0 +1,17 @@
+Description: Use memcpy over strncpy
+
+upstream: 
https://github.com/cleishm/libneo4j-client/commit/03bdc0ae23a48da1745f6cb08bde3ebb4b8c6588
+
+---
+
+--- libneo4j-client-2.2.0.orig/src/lib/print.c
 libneo4j-client-2.2.0/src/lib/print.c
+@@ -49,7 +49,7 @@ size_t neo4j_null_str(const neo4j_value_
+ {
+ n = 5;
+ }
+-strncpy(buf, "null", n);
++memcpy(buf, "null", n-1);
+ buf[n-1] = '\0';
+ }
+ return 4;

Bug#953848: RFS: libneo4j-client/2.2.0-1.1 [NMU, RC] -- Command line shell for the Neo4j graph database

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "libneo4j-client"

 * Package name: libneo4j-client
   Version : 2.2.0-1.1
   Upstream Author : Chris Leishman 
 * URL : https://neo4j-client.net
 * License : Apache
 * Vcs : https://github.com/cleishm/libneo4j-client
   Section : devel

It builds those binary packages:

  neo4j-client - Command line shell for the Neo4j graph database
  libneo4j-client11 - Client library for the Neo4j graph database
  libneo4j-client-dev - Development files for libneo4j-client, a client library 
for Neo4j
  libneo4j-client-doc - Documentation for libneo4j-client, a client library for 
Neo4j

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

  https://mentors.debian.net/package/libneo4j-client

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libn/libneo4j-client/libneo4j-client_2.2.0-1.1.dsc

Changes since the last upload:

   * Non-maintainer upload.
   * Fix ftbfs with gcc-9. (Closes: #925753)


-- 
Regards
Sudip

Bug#953811: lintian: handle ADTTMP fallback code

[Chris Lamb]

Thorsten Glaser wrote:

> > Noted. However, given that ADTTMP is actually deprecated I would like
> > to confirm that this is not instead a bug in sadt(1) instead.
> 
> I’m certain it is ☻ but I wrote the autopkgtest script conservatively.

In general I would share your principle of writing code in a
backwards-compatible manner.

However, I believe this case differs from the norm as sadt(1) is a
Debian tool that is within our locus of control, so I would very much
prefer that src:devscripts is fixed instead of preventing Lintian
ceasing to warn about a deprecated option. Debian has, how can I
put it, enough legacy code as it is.


Regards,

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

Bug#935706: lintian: Make tag certainty a programmatic assessment

[Chris Lamb]

Hi Felix,

> > it appears to simply encode the currently unhelpful distinction between
> > "wild-guess", "possible" and "certain" in a new and relatively unfamiliar
> > way with a slightly ambiguous name.
> 
> I think this is a case of miscommunication.
[…]
> Any references to certainty or its values, "wild-guess", "possible"
> and "certain", are gone. The table you quote is being removed.

Ah... very glad to hear we're on the same page here. I think I was
misled by the quoting of the table as it appeared to imply that
"certainty" or something similar would be retained, when that is not
what is being proposed here.

Regarding the name of this new combined field, we should never forget
that is not only graphical applications that have a "user interface" —
even command-line utilities have one, but it is merely encoded in
ASCII form. Interface design is a long-established field and has
various hard-won best practices and conventions, more easily noticed
in GUI programs with regard to visual design, but an oft-neglected and
extremely important component of a good interface concerns itself with
the terminology used. For example, words should not surprise or
confuse the user, and indeed should be as entirely seamless and
unnoticable as possible. "Don't make me think", the saying goes.
Another way of putting this is that if the user even consciously has
to consider the word, it is ipso facto not a good word.

I mention this because I believe "visibility" would not be serving our
users best. There are examples where a technically-correct name like
this, even if backed up by a well-meaning dictionary definition might
very well fit the idea better but we must have some empathy for the
casual and regular users of Lintian (a very old project, remember!)
who will be expecting the term "severity", even though that may not
100% fit the idea of this new tag (eg. not quite matching the BTS or
whatever). In other words, if any user of Lintian now thinks questions
like "where did severities go? what is visibility? how does it
differ?" then we are not doing our job to the best of our ability.

Anyway, unless I'm misunderstanding something again, I would very much
suggest we repurpose "severity" here instead of inventing a new term.


Regards,

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

Bug#953847: sbcl: Please include patch to fix build on powerpc and ppc64el

[John Paul Adrian Glaubitz]

Source: sbcl
Severity: normal
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: powerpc,ppc64el

Hello!

The attached patch fixes the sbcl build on powerpc and ppc64el,
I have already included it in the sbcl package on openSUSE [1].

Please apply.

Thanks,
Adrian

> [1] https://build.opensuse.org/package/show/devel:languages:misc/sbcl

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru sbcl-2.0.2.orig/src/runtime/Config.ppc64-linux 
sbcl-2.0.2/src/runtime/Config.ppc64-linux
--- sbcl-2.0.2.orig/src/runtime/Config.ppc64-linux  2020-02-29 
21:25:50.0 +0100
+++ sbcl-2.0.2/src/runtime/Config.ppc64-linux   2020-03-13 15:20:42.148527131 
+0100
@@ -10,7 +10,7 @@
 # files for more information.
 
 CFLAGS += -m64
-LINKFLAGS += -rdynamic -m64
+LINKFLAGS += -rdynamic -m64 -Wl,-no-as-needed
 NM = ./linux-nm
 
 ASSEM_SRC = ppc64-assem.S
diff -Nru sbcl-2.0.2.orig/src/runtime/Config.ppc-linux 
sbcl-2.0.2/src/runtime/Config.ppc-linux
--- sbcl-2.0.2.orig/src/runtime/Config.ppc-linux2020-02-29 
21:25:50.0 +0100
+++ sbcl-2.0.2/src/runtime/Config.ppc-linux 2020-03-13 15:18:48.903522685 
+0100
@@ -10,7 +10,7 @@
 # files for more information.
 
 CFLAGS += -m32
-LINKFLAGS += -rdynamic -m32
+LINKFLAGS += -rdynamic -m32 -Wl,-no-as-needed
 NM = ./linux-nm
 
 ASSEM_SRC = ppc-assem.S

Bug#930534: Bug#930521: release.debian.org: provide machine-readable information about the freeze period for each release

[Paul Wise]

On Fri, 2020-03-13 at 22:56 +0100, Paul Gevers wrote:

> I assume you have read the current freeze_policy [1]. As you have seen,
> we have introduced a new phase, where the automatic migration depends on
> the package. I'm not sure how easy it is to cover that information into
> a this template. Do you have suggestions?

Since the release team are going to be able to tell which packages are
at which stage of the freeze, you could export the information
(migrations: manual or x days) alongside the excuses for each package
and the tracker could list that information in human readable form.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#953846: psychopy: ships /usr/lib/python3/dist-packages/packaging/__init__.py

[Andreas Beckmann]

Package: psychopy
Version: 2020.1.3+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

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

  Selecting previously unselected package psychopy.
  Preparing to unpack .../237-psychopy_2020.1.3+dfsg-1_all.deb ...
  Unpacking psychopy (2020.1.3+dfsg-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-JKpyB5/237-psychopy_2020.1.3+dfsg-1_all.deb (--unpack):
   trying to overwrite '/usr/lib/python3/dist-packages/packaging/__init__.py', 
which is also in package python3-packaging 19.1-2
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-JKpyB5/237-psychopy_2020.1.3+dfsg-1_all.deb

The path /usr/lib/python3/dist-packages/packaging/__init__.py
is clearly owned by python3-packaging.


cheers,

Andreas


python3-packaging=19.1-2_psychopy=2020.1.3+dfsg-1.log.gz
Description: application/gzip

Bug#953158: sdpa: hardcoded old mumps-seq dependency

[Nobuhiro Iwamatsu]

Hi,

> http://launchpadlibrarian.net/468909506/sdpa_7.3.13+dfsg-1_7.3.13+dfsg-1ubuntu1.diff.gz
>
> Can I upload the following fix? otherwise the package won't ever go in testing
>
> G.

Makoto is now working on a package with this fix.
Would you please wait for his fix?

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#953818: python-paver: should this package be removed?

[Hans-Christoph Steiner]

Please remove!

Sandro Tosi:
> Package: python-paver
> Severity: serious
> 
> Hello,
> i believe this package should be removed:
> 
> * python2-only
> * while upstream has released a py3k compatible version (and several others in
>   between the one in the archive), the debian maintainer didnt upload this
>   package since late 2013
> * no rdeps
> * extremely low popcon
> 
> if i dont hear back within a week to keep this package, i'll file for its
> removal.
> 
> Regards,
> Sandro
> 
> -- System Information:
> Debian Release: 10.0
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
> 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= 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages python-paver depends on:
> ii  libjs-jquery  3.3.1~dfsg-3
> ii  python2.7.16-1
> 
> python-paver recommends no packages.
> 
> python-paver suggests no packages.
> 

Bug#953158: sdpa: hardcoded old mumps-seq dependency

[Nobuhiro Iwamatsu]

Hi Gianfranco,

2020年3月8日(日) 17:10 Gianfranco Costamagna :
>
> control: tags -1 patch
>
> the following works.
> diff -Nru sdpa-7.3.12+dfsg/debian/changelog sdpa-7.3.12+dfsg/debian/changelog
> --- sdpa-7.3.12+dfsg/debian/changelog2019-12-06 08:00:00.0 +0100
> +++ sdpa-7.3.12+dfsg/debian/changelog2020-03-08 09:03:01.0 +0100
> @@ -1,3 +1,10 @@
> +sdpa (7.3.12+dfsg-1.1) unstable; urgency=medium
> +
> +  * Fix rules to dynamically evaluate mumps version on binNMU
> +(Closes: #953158)
> +
> + -- Gianfranco Costamagna   Sun, 08 Mar 2020 
> 09:03:01 +0100
> +
>  sdpa (7.3.12+dfsg-1) unstable; urgency=low
>
> * New upstream
> diff -Nru sdpa-7.3.12+dfsg/debian/control sdpa-7.3.12+dfsg/debian/control
> --- sdpa-7.3.12+dfsg/debian/control2019-12-06 08:00:00.0 +0100
> +++ sdpa-7.3.12+dfsg/debian/control2020-03-08 08:32:37.0 +0100
> @@ -11,7 +11,7 @@
>  Package: sdpa
>  Architecture: any
>  Depends: ${shlibs:Depends}, ${misc:Depends},
> -   libopenblas-dev, libmumps-seq-5.1.2
> +   libopenblas-dev, libmumps-seq-${mumps-seq:Version}

Aha,  this is nice!

>  Description: High-performance package for SemiDefinite Programs
>   The software SDPA (SemiDefinite Programming Algorithm) is one of the most
>   efficient and stable  software packages for solving SDPs based on the
> @@ -38,7 +38,7 @@
>  Package: sdpam
>  Architecture: any
>  Depends: ${shlibs:Depends}, ${misc:Depends},
> -   libopenblas-pthread-dev, libmumps-seq-5.1.2,
> +   libopenblas-pthread-dev, libmumps-seq-${mumps-seq:Version},
> octave, libsdpa-dev
>  Description: Matlab/Octave interface of SDPA
>   This package provides SDPA-M, Matlab/Octave interface
> diff -Nru sdpa-7.3.12+dfsg/debian/rules sdpa-7.3.12+dfsg/debian/rules
> --- sdpa-7.3.12+dfsg/debian/rules2019-12-06 08:00:00.0 +0100
> +++ sdpa-7.3.12+dfsg/debian/rules2020-03-08 09:02:45.0 +0100
> @@ -37,6 +37,8 @@
>  MUMPS_LIBS="/usr/lib/$(DEB_HOST_MULTIARCH)/libdmumps_seq.a 
> /usr/lib/$(DEB_HOST_MULTIARCH)/libmumps_common_seq.a 
> /usr/lib/$(DEB_HOST_MULTIARCH)/libmpiseq_seq.a 
> /usr/lib/$(DEB_HOST_MULTIARCH)/libpord_seq.a -lscotch -lesmumps"
>  DEB_CONFIGURE_EXTRA_FLAGS += --with-mumps-libs=$(MUMPS_LIBS)
>
> +LIBMUMPS_VER := $(shell dpkg --status libmumps-seq-dev | awk '/^Version:/ 
> {print $$2}' |cut -f 1 -d "-")
> +DEB_DH_GENCONTROL_ARGS_ALL = -- -Vmumps-seq:Version=$(LIBMUMPS_VER)
>
>  SDPA_DIR=$(CURDIR)/debian/sdpa
>  SDPAM_DIR=$(CURDIR)/debian/sdpam
>
>

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#937897: python-lockfile: diff for NMU version 1:0.12.2-2.1

[Sandro Tosi]

Control: tags 937897 + patch


Dear maintainer,

I've prepared an NMU for python-lockfile (versioned as 1:0.12.2-2.1). The diff
is attached to this message.

Regards.

diff -Nru python-lockfile-0.12.2/debian/changelog python-lockfile-0.12.2/debian/changelog
--- python-lockfile-0.12.2/debian/changelog	2016-08-21 01:59:20.0 -0400
+++ python-lockfile-0.12.2/debian/changelog	2020-03-13 19:12:13.0 -0400
@@ -1,3 +1,10 @@
+python-lockfile (1:0.12.2-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937897, #939930
+
+ -- Sandro Tosi   Fri, 13 Mar 2020 19:12:13 -0400
+
 python-lockfile (1:0.12.2-2) unstable; urgency=medium
 
   * The “Tuğçe Albayrak” release.
diff -Nru python-lockfile-0.12.2/debian/control python-lockfile-0.12.2/debian/control
--- python-lockfile-0.12.2/debian/control	2016-08-21 01:59:20.0 -0400
+++ python-lockfile-0.12.2/debian/control	2020-03-13 19:01:33.0 -0400
@@ -11,42 +11,9 @@
 python3-nose,
 python3-sphinx,
 python3-all,
-python-setuptools,
-python-pbr (>= 1.8),
-python-nose,
-python-all
 Standards-Version: 3.9.8
 VCS-Git: https://notabug.org/bignose/debian_python-lockfile.git
 VCS-Browser: https://notabug.org/bignose/debian_python-lockfile/
-X-Python-Version: >= 2.7
-X-Python3-Version: >= 3.2
-
-Package: python-lockfile
-Architecture: all
-Depends:
-${python:Depends},
-${misc:Depends}
-Suggests: python-lockfile-doc
-Description: file locking library for Python — Python 2 library
- The ‘lockfile’ library exports a ‘LockFile’ class which provides a
- simple API for locking files.
- .
- The appropriate implementation for ‘LockFile’ is chosen automatically
- based on the OS capabilities for an atomic filesystem operation.
- These implementations are also available for explicit use as
- ‘LinkLockFile’ and ‘MkdirLockFile’.
- .
- Other back ends are possible with the same semantics. Examples
- included are:
-  * ‘SQLiteLockFile’, using records in an SQLite database.
-  * ‘PIDLockFile’, using the semantics of a Unix PID file.
- .
- Unlike other Python locking libraries (the Windows ‘msvcrt.locking’
- function, the Unix ‘fcntl.flock’, ‘fcntl.lockf’, and the deprecated
- ‘posixfile’ module), the API is identical across both Unix (including
- GNU/Linux and MacOS) and Windows platforms.
- .
- This package installs the Python 2 library.
 
 Package: python3-lockfile
 Architecture: all
@@ -81,7 +48,7 @@
 Depends:
 ${sphinxdoc:Depends},
 ${misc:Depends}
-Recommends: python-lockfile
+Recommends: python3-lockfile
 Description: file locking library for Python — documentation
  The ‘lockfile’ library exports a ‘LockFile’ class which provides a
  simple API for locking files.
diff -Nru python-lockfile-0.12.2/debian/python-lockfile.docs python-lockfile-0.12.2/debian/python-lockfile.docs
--- python-lockfile-0.12.2/debian/python-lockfile.docs	2016-08-21 01:59:20.0 -0400
+++ python-lockfile-0.12.2/debian/python-lockfile.docs	1969-12-31 19:00:00.0 -0500
@@ -1,3 +0,0 @@
-README.rst
-ACKS
-AUTHORS
diff -Nru python-lockfile-0.12.2/debian/rules python-lockfile-0.12.2/debian/rules
--- python-lockfile-0.12.2/debian/rules	2016-08-21 01:59:20.0 -0400
+++ python-lockfile-0.12.2/debian/rules	2020-03-13 19:02:08.0 -0400
@@ -24,7 +24,7 @@
 SPHINX_OPTS = -N
 
 %:
-	dh $@ --with python2,python3,sphinxdoc --buildsystem=pybuild
+	dh $@ --with python3,sphinxdoc --buildsystem=pybuild
 
 
 .PHONY: get-packaged-orig-source
diff -Nru python-lockfile-0.12.2/debian/tests/control python-lockfile-0.12.2/debian/tests/control
--- python-lockfile-0.12.2/debian/tests/control	2016-08-21 01:59:20.0 -0400
+++ python-lockfile-0.12.2/debian/tests/control	2020-03-13 19:02:22.0 -0400
@@ -2,11 +2,6 @@
 # Control file for Debian ‘autopkgtests’.
 # Documentation: ‘/usr/share/doc/autopkgtest/README.package-tests.rst.gz’
 
-Tests: smoke-python2
-Depends:
-python-pkg-resources,
-python-lockfile
-
 Tests: smoke-python3
 Depends:
 python3-pkg-resources,
diff -Nru python-lockfile-0.12.2/debian/tests/smoke-python2 python-lockfile-0.12.2/debian/tests/smoke-python2
--- python-lockfile-0.12.2/debian/tests/smoke-python2	2016-08-21 01:59:20.0 -0400
+++ python-lockfile-0.12.2/debian/tests/smoke-python2	1969-12-31 19:00:00.0 -0500
@@ -1,47 +0,0 @@
-#! /bin/bash
-#
-# debian/tests/smoke-python2
-# Part of Debian ‘python-lockfile’ package.
-#
-# Copyright © 2016 Ben Finney 
-# This is free software; you may copy, modify, and/or distribute this work
-# under the terms of the GNU General Public License, version 3 or later.
-# No warranty expressed or implied.
-# See the file ‘/usr/share/common-licenses/GPL-3’ for details.
-#
-# Smoke test for package in Python 2 environments.
-
-set -o errexit
-set -o errtrace
-set -o nounset
-
-DISTRIBUTION_NAME=lockfile
-MODULE_NAMES=(
-lockfile
-)
-
-program_dir="$(dirname "$(realpath --strip "$0")")"
-
-# Use a working 

Bug#953843: kdeconnect: sftp file transfer is broken with openssh 8.2

[Alexander Kernozhitsky]

Package: kdeconnect
Version: 1.3.3-2+b1
Severity: important
Tags: upstream

After the update to openssh 8.2, transferring files via SFTP is broken. That's
what I got in the error log:

kdeconnect.plugin.sftp: stdout: "Unable to negotiate with 192.168.31.203 port
1743: no matching key exchange method found. Their offer: diffie-hellman-
group14-sha1,diffie-hellman-group1-sha1\r\n"

The upstream bug is tracked in https://bugs.kde.org/show_bug.cgi?id=417787

Maybe it can be a good idea to re-enable the old ciphers as a workaround. This
was done in Arch:
https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/kdeconnect=3f4cabc50dab5ea4ca613c4e48808912e4e5fb71



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

Kernel: Linux 5.4.0-4-amd64 (SMP w/8 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 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kdeconnect depends on:
ii  kde-cli-tools 4:5.17.5-2
ii  kio   5.62.1-2+b1
ii  libc6 2.29-10
ii  libfakekey0   0.1-10+b1
ii  libkf5configcore5 5.62.0-1+b1
ii  libkf5configwidgets5  5.62.0-1+b1
ii  libkf5coreaddons5 5.62.0-1
ii  libkf5dbusaddons5 5.62.0-1
ii  libkf5i18n5   5.62.0-1
ii  libkf5iconthemes5 5.62.0-1+b1
ii  libkf5kcmutils5   5.62.0-1+b2
ii  libkf5kiocore55.62.1-2+b1
ii  libkf5kiofilewidgets5 5.62.1-2+b1
ii  libkf5kiowidgets5 5.62.1-2+b1
ii  libkf5notifications5  5.62.0-1+b1
ii  libkf5service-bin 5.62.0-1
ii  libkf5service55.62.0-1
ii  libkf5waylandclient5  4:5.62.0-2+b1
ii  libkf5widgetsaddons5  5.62.0-1+b1
ii  libqca-qt5-2  2.2.1-2
ii  libqca-qt5-2-plugins  2.2.1-2
ii  libqt5core5a  5.12.5+dfsg-9
ii  libqt5dbus5   5.12.5+dfsg-9
ii  libqt5gui55.12.5+dfsg-9
ii  libqt5network55.12.5+dfsg-9
ii  libqt5qml55.12.5-5
ii  libqt5widgets55.12.5+dfsg-9
ii  libqt5x11extras5  5.12.5-1
ii  libstdc++610-20200304-1
ii  libx11-6  2:1.6.9-2
ii  libxtst6  2:1.2.3-1
ii  plasma-framework  5.62.0-2
ii  qml-module-qtquick-controls   5.12.5-1+b1
ii  qml-module-qtquick-controls2  5.12.5+dfsg-2+b1
ii  qml-module-qtquick-layouts5.12.5-5
ii  qml-module-qtquick2   5.12.5-5
ii  sshfs 3.7.0+repack-1

kdeconnect recommends no packages.

Versions of packages kdeconnect suggests:
ii  plasma-workspace  4:5.17.5-4
pn  python-nautilus   

-- no debconf information

Bug#953845: RM: python-paisley -- RoQA; Dead upstream, depends on Py2

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove python-paisley. It's dead upstream, not ported to Python 2,
there are no reverse deps and couchdb itself has also been removed from
the archive.

Cheers,
Moritz

Bug#953844: gcc-arm-none-eabi: PRIx64 not available anymore with gcc-arm-none-eabi_8-2019-q3-1

[Philippe Teuwen]

Package: gcc-arm-none-eabi
Version: 15:8-2019-q3-1
Severity: normal

Dear Maintainer,

Code containing PRIx64 macro after inclusion of  does not
compile anymore,
the macro doesn't exist contrarily to the situation with
gcc-arm-none-eabi_7-2018-q2-6.

I tracked it down to the following difference between 7.3.1 and 8.3.1:

/usr/lib/gcc/arm-none-eabi/7.3.1/include/stdint.h is a wrapper:

#ifndef _GCC_WRAP_STDINT_H
#if __STDC_HOSTED__
# if defined __cplusplus && __cplusplus >= 201103L
#  undef __STDC_LIMIT_MACROS
#  define __STDC_LIMIT_MACROS
#  undef __STDC_CONSTANT_MACROS
#  define __STDC_CONSTANT_MACROS
# endif
# include_next 
#else
# include "stdint-gcc.h"
#endif
#define _GCC_WRAP_STDINT_H
#endif

while
/usr/lib/gcc/arm-none-eabi/8.3.1/include/stdint.h is the same as
/usr/lib/gcc/arm-none-eabi/7.3.1/include/stdint-gcc.h

So in 8.3.1 we don't have anymore the include_next 
which includes /usr/include/newlib/stdint.h
which includes /usr/include/newlib/sys/_stdint.h
which defines __int64_t_defined
and /usr/include/newlib/inttypes.h defines PRIx64 only if
__int64_t_defined is defined.


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

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

Versions of packages gcc-arm-none-eabi depends on:
ii  binutils-arm-none-eabi  2.32.51.20190909-1+13
ii  libc6   2.29-9
ii  libgcc-s1   10-20200204-1
ii  libgmp102:6.1.2+dfsg-4
ii  libisl220.22-2
ii  libmpc3 1.1.0-1
ii  libmpfr64.0.2-1
ii  libstdc++6  9.2.1-25
ii  zlib1g  1:1.2.11.dfsg-1+b1

Versions of packages gcc-arm-none-eabi recommends:
ii  libnewlib-arm-none-eabi  3.1.0.20181231-1

gcc-arm-none-eabi suggests no packages.

-- no debconf information

Bug#953838: apt: "apt-cache pkgnames" lists source packages, breaking bash-completion

[Alexander Kernozhitsky]

Package: apt
Version: 2.0.0
Severity: normal


Hello,

I noticed that completion for apt and aptitude sometimes list invalid packages.
For example:

$ apt show openssh
openssh  openssh-client-ssh1  openssh-server   openssh-ssh1
openssh-client   openssh-known-hosts  openssh-sftp-server  openssh-tests
$ apt show openssh
N: Unable to locate package openssh
N: Unable to locate package openssh
E: No packages found

The reason is that bash-completion relies on the output of "apt-cache pkgnames"
command. Currently, it shows both source and binary packages, but we need to
complete only binary packages in the case above.

Not sure if it's a bug in bash-completion or in apt, but it seems that it's
more suitable to fix in apt, because of the following:
- it seems that the bug appeared after the upgrade to apt 2.0
- I didn't find an option to exclude source packages from the output. Adding
this option would be also good to fix the issue in bash-completion.



-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-5\.4\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-image-5\.5\.8$";
APT::NeverAutoRemove:: "^linux-headers-5\.4\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-headers-5\.5\.8$";
APT::NeverAutoRemove:: "^linux-image-extra-5\.4\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-5\.5\.8$";
APT::NeverAutoRemove:: "^linux-modules-5\.4\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-modules-5\.5\.8$";
APT::NeverAutoRemove:: "^linux-modules-extra-5\.4\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-5\.5\.8$";
APT::NeverAutoRemove:: "^linux-signed-image-5\.4\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-5\.5\.8$";
APT::NeverAutoRemove:: "^linux-image-unsigned-5\.4\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-image-unsigned-5\.5\.8$";
APT::NeverAutoRemove:: "^kfreebsd-image-5\.4\.0-4-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-5\.5\.8$";
APT::NeverAutoRemove:: "^kfreebsd-headers-5\.4\.0-4-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-5\.5\.8$";
APT::NeverAutoRemove:: "^gnumach-image-5\.4\.0-4-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-5\.5\.8$";
APT::NeverAutoRemove:: "^.*-modules-5\.4\.0-4-amd64$";
APT::NeverAutoRemove:: "^.*-modules-5\.5\.8$";
APT::NeverAutoRemove:: "^.*-kernel-5\.4\.0-4-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-5\.5\.8$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-5\.4\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-5\.5\.8$";
APT::NeverAutoRemove:: "^linux-modules-.*-5\.4\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-5\.5\.8$";
APT::NeverAutoRemove:: "^linux-tools-5\.4\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-tools-5\.5\.8$";
APT::NeverAutoRemove:: "^linux-cloud-tools-5\.4\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-5\.5\.8$";
APT::NeverAutoRemove:: "^linux-buildinfo-5\.4\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-buildinfo-5\.5\.8$";
APT::NeverAutoRemove:: "^linux-source-5\.4\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-source-5\.5\.8$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Default-Release "bullseye";
APT::Architectures "";

Bug#953842: RM: python-wstools -- RoQA; python2-only; dead upstream; no rdeps

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#953841: RM: rtcninjajs -- RoQA; Outdated, unmaintained, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove rtcninjajs. It hasn't seen an upload since 2015, is dead
upstream and there are no reverse deps.

Cheers,
Moritz

Bug#953840: RM: parsley -- RoQA; python2-only; dead upstream; no rdeps

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#953839: RM: jquery-i18n-properties -- RoQA; unmaintained, unused

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove jquery-i18n-properties. There has only been a single upload
back in 2014 and there are no reverse dependencies.

Cheers,
Moritz

Bug#952366:

[Mybillserv Inc]

Test

Bug#953809: tasksel 3.59: it needs to delete task-print-server and task-print-service

[Cyril Brulebois]

Hi,

Сергей Фёдоров  (2020-03-13):
> Package: tasksel
> Version: 3.59
> Severity: normal
> 
> When upgrading any of the packages from version 3.58 to 3.59:
>task-cyrillic
>task-desktop
>task-russian
>task-xfce-desktop
>tasksel
>tasksel-data
> it needs to delete packages version 3.58
>task-print-server
>task-print-service
> but their version 3.59 is not available.

Yes, that's been in removed in the latest version. See the latest
changelog entry (sorry, one needs to scoll until “Changes:”):
  
https://tracker.debian.org/news/1107708/accepted-tasksel-359-source-into-unstable/

So I don't think there's anything to fix here. Looping in Didier to make
extra sure.


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


signature.asc
Description: PGP signature

Bug#938027: [Python-modules-team] Bug#938027: Bug#938027: python-pip: Python2 removal in sid/bullseye

[Sandro Tosi]

On Fri, Mar 13, 2020 at 3:51 PM Scott Kitterman  wrote:
>
> I don't know of a reason not to go ahead, but if you do, please be careful of 
> what's already in git.  Update to the new version is staged there.  It is 
> blocked on updates for some of the packages it builds wheels from.

oooh i see you were working on updating pip, wanna take care of
dropping its py2 suppor while at it? i cant really tell from the 2
seconds look i gave the package what's actually required :)

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#882584: Found the salsa package

[Martin Quinson]

https://salsa.debian.org/debian-edu-pkg-team/openboard/

could we however modify this git repository to use git-buildpackage?
It makes things so much easier to maintain...

Thanks for your work,
Mt


signature.asc
Description: PGP signature

Bug#953830: /usr/include/limits.h:124:26: error: no include path in which to search for limits.h

[Aurelien Jarno]

control: reassign -1 gcc-9
control: forcemerge 953806 -1

On 2020-03-13 23:00, Thorsten Glaser wrote:
> Package: libc6-dev
> Version: 2.30-2
> Severity: grave
> Justification: renders package unusable
> 
> Unsure whether it’s upstream or Debian, but…

It's debian specific and not a glibc issue. Reassigning.

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

Bug#953837: RM: dynalogin -- RoQA; RC-buggy, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove dynalogin. It's RC-buggy for over a year, missed Buster
and hasn't seen an upload since 2013.

Cheers,
Moritz

Bug#953836: iso-scan: Debian installer can't select correct ISO file on multi-iso installation usb-sticks

[Oliver C.]

Package: iso-scan
Version: 1.79
Severity: important



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

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



Hello,

Debian's TUI installer or in general it's script iso-scan.postinst does
not select the correct ISO file to use, when i try to install Debian
from a multi-iso USB-stick with several different ISO files on the
USB-stick.
This bug affects iso-scan upstream and was also tested on Debian 9 and
10 stable with the same effect.

The error is in the file of the initrd.gz hd-image:
./var/lib/dpkg/info/iso-scan.postinst

In line 21 the script is doing a check of an iso file that is given to
the function if that iso file is a Debian one:
/*
  is_debian_iso () {
test -e /cdrom/.disk/info
  }
*/

And starting in line 79 it is doing some more checks:
/*
  if is_debian_iso; then
if isodesc=$(analyze_cd); then
log "Debian ISO $iso_to_try usable"
ISOS_FOUND="${ISOS_FOUND:+$ISOS_FOUND, }$isodesc"
else
log "Debian ISO not usable, skipping"
fi
else
log "$iso_to_try not a Debian ISO"
fi
*/


There are three problems with this approach.
1. The is_debian_iso () function also accepts Kubuntu ISO files.
For example, the entry of /cdrom/.disk/info of a Kubuntu ISO file does
look like this:
/*
Kubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725)
*/

2. If an iso file is accepted by the is_debian_iso () function, the
Debian installer is trying to use ONLY this one, it will not continue to
test other ISO files that might be on the disk.
In my case it accepts the Kubuntu iso file first, but then it fails in
the next "if block" of line 80 (see above).
Thus the whole installation fails, because it's not possible to check
for other iso files on the USB stick.

3. If it finds a real Debian ISO file, it could be the wrong one.
It might select a Debian iso file for AMD64 architecture on an 32 Bit
machine (i386). The installation might work, but the installed system
won't work. Or it also could be an old Version of Debian, for example
Debian 9 (Stretch) instead of Debian 10 (Buster), thus it will install
the wrong one.


Solution:
As a solution i suggest to ask the user if the selected and proposed ISO
file is the correct one and if not, let the user choose the ISO file
manually afterwards. Overwriting what was automatically selected by
iso-scan.postinst script.

There is some code in the script starting at line 381 that should do
that, but it seems to be, that this code is never run:
/*
20) # One or multiple ISO(s) found: ask which one we'll use
# FIXME: not l10n safe
db_subst iso-scan/ask_which_iso ISOS_LIST "$ISOS_FOUND"
db_input ${CRITICAL:-medium} iso-scan/ask_which_iso || true
;;
*/


Workaround:
If i rename all ISO files that do look similar to a Debian one (for
example all Ubuntu ISO files) and all Debian iso files with the wrong
architecture or version that i don't want to install, before rebooting
the usb-stick, the installation works.

But it doesn't work to mount the correct iso file to /cdrom in another
terminal manually during setup, because the script iso-scan.postinst is
unmounting all ISO files in line 292 when the user continues with the
installation dialog.
/*
  # Try to unmount anything that was previously mounted
  umount -d /cdrom 2>/dev/null || true
*/


It's an old Bug:
According to the changelog of the newest iso-scan package and a
comparison of the source code in the git repository, this bug is still
not fixed in version 1.79. The code of that script in version 1.75 of
Debian stable and 1.79 upstream doesn't differ:
https://metadata.ftp-master.debian.org/changelogs//main/i/iso-scan/iso-scan_1.79_changelog
https://salsa.debian.org/installer-team/iso-scan/-/compare/1.75...master

Before writing this bug report i also read all the other bug reports
about the iso-scan package.
And what i found out is that this bug is also related to the following
bugs, which means, fixing this bug, can close the following 7 other bug
reports:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841135
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701772
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707479
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541276
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510666
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886468
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762316

There is a fix mentioned in bug #841135 which should fix 

Bug#953835: RM: ganglia-nagios-bridge -- RoQA; Depends on Python 2

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove ganglia-nagios-bridge. It depends on Python 2, which is going
away.

Cheers,
Moritz

Bug#953834: RM: node-sdp-transform -- RoQA; Outdated, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove node-sdp-transform. It hasn't seen an upload since
2015, is far behind upstream (currently at 2.14) and there are
no reverse deps.

Cheers,
Moritz

Bug#948206: mitmproxy incompatible with python3-wsproto=0.15.0-2

[Kevin Locke]

On Sun, 2020-01-05 at 11:27 +0100, Adrian Vollmer wrote:
> After upgrading python3-wsproto to version 0.15.0-2, mitmproxy fails
> immediately with this error message:
> 
> ImportError: cannot import name 'WSConnection' from 'wsproto.connection'
> (/usr/lib/python3/dist-packages/wsproto/connection.py)

I just encountered the same issue.  For reference, this specific error
was fixed in 106948d99[1] which is included in 5.0.0.  Apparently
setup.py was not updated to wsproto 0.15 due to mypy type checking
errors[2] (which I'm unable to reproduce on e01f044c).  Using wsproto
0.15 with 5.0.1 has been working well for me.

Best,
Kevin

[1]: https://github.com/mitmproxy/mitmproxy/commit/106948d99
[2]: https://github.com/mitmproxy/mitmproxy/pull/3651

Bug#953833: RM: captagent -- RoQA; RC-buggy, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove captagent. It's RC-buggy since 2017, missed Buster
and no longer has an active maintainer.

Cheers,
Moritz

Bug#953811: lintian: handle ADTTMP fallback code

[Thorsten Glaser]

Chris Lamb dixit:

>Thorsten Glaser wrote:
>
>> I need to have this code present because I use sadt locally to test
>> the autopkgtests, which only sets ADTTMP.
>
>Noted. However, given that ADTTMP is actually deprecated I would like
>to confirm that this is not instead a bug in sadt(1) instead.

I’m certain it is ☻ but I wrote the autopkgtest script conservatively.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#953832: drmaa: autopkgtest failure: RuntimeError: Could not find drmaa library

[Paul Gevers]

Source: drmaa
Version: 0.7.9-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainers,

With a recent upload of drmaa you added an autopkgtest, great. However,
it fails. I copied some of the output at the bottom of this report.

Currently this is blocking the migration to testing [1]. Can you please
investigate the situation and fix it?

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/d/drmaa/4335284/log.gz

autopkgtest [03:10:24]: test autodep8-python3: set -e ; for py in
$(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing
with $py:" ; $py -c "import drmaa; print(drmaa)" ; done
autopkgtest [03:10:24]: test autodep8-python3: [---
Testing with python3.8:
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/drmaa/__init__.py", line 65, in

from .session import JobInfo, JobTemplate, Session
  File "/usr/lib/python3/dist-packages/drmaa/session.py", line 39, in

from drmaa.helpers import (adapt_rusage, Attribute,
attribute_names_iterator,
  File "/usr/lib/python3/dist-packages/drmaa/helpers.py", line 36, in

from drmaa.wrappers import (drmaa_attr_names_t, drmaa_attr_values_t,
  File "/usr/lib/python3/dist-packages/drmaa/wrappers.py", line 52, in

raise RuntimeError(('Could not find drmaa library.  Please specify
its ' +
RuntimeError: Could not find drmaa library.  Please specify its full
path using the environment variable DRMAA_LIBRARY_PATH
autopkgtest [03:10:24]: test autodep8-python3: ---]



signature.asc
Description: OpenPGP digital signature

Bug#953831: /usr/lib/x86_64-linux-gnu/hexchat/plugins/python3.so: undefined symbol: PyExc_RuntimeError

[Vinicius Couto]

Package: hexchat
Version: 2.14.3-2+b1
Severity: normal

Dear Maintainer,

Whe the progam begins, the program shows:

Sysinfo plugin carregado
 FiSHLiM plugin loaded
 Perl interface loaded
 AutoLoad failed for: /usr/lib/x86_64-linux-gnu/hexchat/plugins/python3.so
 /usr/lib/x86_64-linux-gnu/hexchat/plugins/python3.so: undefined symbol: 
PyExc_RuntimeError
 Checksum plugin loaded

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

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

Versions of packages hexchat depends on:
ii  hexchat-common  2.14.3-2
ii  libc6   2.29-10
ii  libcanberra00.30-7
ii  libdbus-glib-1-20.110-5
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-2
ii  libglib2.0-02.62.5-1
ii  libgtk2.0-0 2.24.32-4
ii  libnotify4  0.7.9-1
ii  libpango-1.0-0  1.42.4-8
ii  libproxy1v5 0.4.15-9
ii  libssl1.1   1.1.1d-2
ii  libx11-62:1.6.9-2

Versions of packages hexchat recommends:
ii  hexchat-perl 2.14.3-2+b1
ii  hexchat-plugins  2.14.3-2+b1
ii  hexchat-python3  2.14.3-2+b1
ii  libglib2.0-bin   2.62.5-1

Versions of packages hexchat suggests:
pn  hexchat-otr  
pn  unifont  

-- no debconf information

Bug#953803: Fwd: Re: Bug#953803: RFS: xdg-utils/1.1.3-2 -- desktop integration utilities from freedesktop.org

[Nicholas Guriev]

By mistake I did not check recipients and forgot to send my reply to
Debian bug tracker, sorry.

 Forwarded Message 
From: Nicholas Guriev 
To: Emilio Pozuelo Monfort 
Subject: Re: Bug#953803: RFS: xdg-utils/1.1.3-2 -- desktop integration 
utilities from freedesktop.org
Date: Fri, 13 Mar 2020 23:05:44 +0300
Mailer: Evolution 3.34.1-2 

dpkg was earlier configured for the package to automatically use single
debian patch, and hence I can choose not to bother with Quilt and manage
changes by using Git. It has a smarter merge algorithm and a wider
integration with external conflict resolvers. Besides that, the package
repository is a plain fork of the upstream one and so it has shared
history. It would be fairly odd to have two concurrent systems for
control modifications of the sole package.

Bug#953830: /usr/include/limits.h:124:26: error: no include path in which to search for limits.h

[Thorsten Glaser]

Package: libc6-dev
Version: 2.30-2
Severity: grave
Justification: renders package unusable

Unsure whether it’s upstream or Debian, but…


tglase@tglase-nb:~ $ gcc x.c
In file included from x.c:1:
/usr/include/limits.h:124:26: error: no include path in which to search for 
limits.h
  124 | # include_next 
  |  ^
1|tglase@tglase-nb:~ $ cat x.c
#include 


(MWE extracted from a much larger attempt to compile something.)

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages libc6-dev:amd64 depends on:
ii  libc-dev-bin2.30-2
ii  libc6   2.30-2
ii  libcrypt-dev1:4.4.15-1
ii  linux-libc-dev  5.4.19-1

libc6-dev:amd64 recommends no packages.

Versions of packages libc6-dev:amd64 suggests:
pn  glibc-doc 
ii  manpages-dev  5.05-1

-- no debconf information

Bug#930534: Bug#930521: release.debian.org: provide machine-readable information about the freeze period for each release

[Paul Gevers]

Hi Paul,

On 07-02-2020 03:01, Paul Wise wrote:
>> Let me try to come back to this bug when we have communicated the dates
>> and provide a prototype so we can see if it works.
> 
> Great, no rush. There isn't much activity on tracker.d.o features anyway.

I assume you have read the current freeze_policy [1]. As you have seen,
we have introduced a new phase, where the automatic migration depends on
the package. I'm not sure how easy it is to cover that information into
a this template. Do you have suggestions?

Paul

[1] https://release.debian.org/bullseye/freeze_policy.html



signature.asc
Description: OpenPGP digital signature

Bug#882584: Any progress on packaging openboard?

[Martin Quinson]

Hello,

is there any progress in this packaging? Is the current package
somewhere on salsa where we could help?

I will need such a software with my students (due to the covid
outbreak), so I'm highly interested.

Thanks, Mt.

signature.asc
Description: PGP signature

Bug#908845: debhelper: Remove dh_gconf in bullseye

[Thorsten Glaser]

Package: debhelper
Version: 12.9
Followup-For: Bug #908845

I’m getting this warning during a package build:

dh_gconf: warning: Please migrate to dh_installgsettings; gconf + dh_gconf is 
scheduled for removal.

It’s clearly dh7-caused as I don’t use gconf at all…


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

Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages debhelper depends on:
ii  autotools-dev20180224.1
ii  dh-autoreconf19
ii  dh-strip-nondeterminism  1.6.3-2
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  dwz  0.13-5
ii  file 1:5.38-4
ii  libdebhelper-perl12.9
ii  libdpkg-perl 1.19.7
ii  man-db   2.9.1-1
ii  perl 5.30.0-9
ii  po-debconf   1.0.21

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

-- no debconf information

Bug#953829: regression/crash: mtr: Probes exhausted

[Marc Lehmann]

Package: mtr-tiny
Version: 0.92-2
Severity: normal

Dear Maintainer,

recent versions of mtr started to crash seemingly randomly with the
following message:

   mtr: Probes exhausted

and an exit status of 1. It's not consistently reproducible, but I found
that when specifying a low interval, e.g.

   mtr -i 0.01 target

it happens much more often than with the default interval.

This might not be new. However, I use mtr daily for many years, and also
with low intervals, and have never seen this message until recently, so I
assume this is new behaviour.

-- System Information:
Debian Release: 10.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), 
(500, 'stable-updates'), (500, 'stable-debug'), (500, 'unstable'), (500, 
'testing'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32

Kernel: Linux 5.4.24-050424-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mtr-tiny depends on:
ii  libc62.28-10
ii  libncurses6  6.1+20181013-2+deb10u2
ii  libtinfo66.1+20181013-2+deb10u2

mtr-tiny recommends no packages.

mtr-tiny suggests no packages.

-- no debconf information

Bug#953827: Migrate classification tags to a new group of value-neutral diagnostics (lab hints)

[Felix Lechner]

Package: lintian
Severity: wishlist

Hi,

as alluded to in #935706 [1], I would like to split the diagnostics
performed in Lintian checks into two levels. One level states
value-neutral facts (such as, a field is present with attached
content), while the other generates user alerts (which we call tags).

These two diagnostic layers will operate similar to a doctor and a
lab: One is a scanning layer that issues hints. It is completely
uncontroversial. It works or it does not.

The other layer is the expert knowledge; a notice layer that, similar
to a doctor, issues alerts for some conditions based on results from
the labs. The notices can be customized, but a standard profile,
perhaps consisting of multiple components (one of which would be
'policy'), would impose widely accepted alert levels on many
conditions indicated by the labs.

The key advantages of such a setup are:

1. Detection methods in the lab layer are no longer burdened by
community discussions about severity.
2. The lab hints are available separately for tools such as Debian Janitor.
3. Classification tags will eventually be turned off in favor of lab
hints, which are more plentiful and offer greater detail.

My current branch is based on

https://salsa.debian.org/lintian/lintian/-/merge_requests/297

and will be submitted for community review after the 'certainty'
concept was removed from Lintian.

Please do not confuse this new terminology of 'labs' with the previous
name for unpacked packages.

Kind regards
Felix Lechner

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

Bug#953828: nevow: should this package be removed?

[Sandro Tosi]

Source: nevow
Severity: serious

Hello,
i believe this package should be removed:

* python2-only
* upstream still hasnt finish porting it to python3,
  https://github.com/twisted/nevow/issues/101
* no rdeps
* relatively low popcon and dropping rapidly

if i dont hear back within a week with a good reason to keep it, im gonna file
for its removal.

Regards,
Sandro

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
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= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#930492: marked as pending in mingw-w64

[Antonio Ospite]

On Sat, 11 Jan 2020 19:33:51 +
Stephen Kitt  wrote:

> Control: tag -1 pending
> 
> Hello,
> 
> Bug #930492 in mingw-w64 reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
> 
> https://salsa.debian.org/mingw-w64-team/mingw-w64/commit/17f8832bff1d2e6eadfb878f7d5afb056d200364
>

Hi, any ETA for an upload with this fix in?

Thanks,
   Antonio

> 
> Ship our own pkg-config-crosswrapper
> 
> Closes: #930492
> 
> 
> (this message was generated automatically)
> -- 
> Greetings
> 
> https://bugs.debian.org/930492
> 


-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Bug#953826: r-cran-rprotobuf: autopkgtest regression: cannot open file '/usr/share/doc/r-cran-rprotobuf/tests/runUnitTests.R'

[Paul Gevers]

Source: r-cran-rprotobuf
Version: 0.4.15-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of r-cran-rprotobuf the autopkgtest of
r-cran-rprotobuf fails in testing when that autopkgtest is run with the
binary packages of r-cran-rprotobuf from unstable. It passes when run
with only packages from testing. In tabular form:
   passfail
r-cran-rprotobuf   from testing0.4.15-1
all others from testingfrom testing

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

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

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

Paul

[1] https://qa.debian.org/excuses.php?package=r-cran-rprotobuf

https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-rprotobuf/4556210/log.gz

autopkgtest [15:21:04]: test run-unit-test: [---
Fatal error: cannot open file
'/usr/share/doc/r-cran-rprotobuf/tests/runUnitTests.R': No such file or
directory
autopkgtest [15:21:05]: test run-unit-test: ---]



signature.asc
Description: OpenPGP digital signature

Bug#953825: RM: backports.ssl-match-hostname -- ROM; python2-only; backport of a py3.5 stdlib module; no rdeps

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#855115: No joystick support in 17.6

[Bob Ham]

Hi,

Just writing to confirm that I've come up against the same lack of
joystick support in 2:17.6+dfsg1-4+b1.  As noted previously, it looks
like a kodi-peripheral-joystick package is needed.

Regards,

Bob Ham



signature.asc
Description: OpenPGP digital signature

Bug#953824: RM: inotifyx -- ROM; python2-only; dead upstream; extremely low popcon; no rdeps; last upload in 2011; better alternatives exist (pyinotify)

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#953823: RM: python-mrjob -- RoQA; python2-only; effectively orphaned (#905288); no uploads since 2012; low popcon; no rdeps

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#953822: src:debian-cloud-images: fails to migrate to testing for too long

[Paul Gevers]

Source: debian-cloud-images
Version: 0.0.1
Severity: serious
Control: fixed -1 0.0.3
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package
src:debian-cloud-images in its current version in unstable has been
trying to migrate for 65 days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have marked the version in unstable as fixing this bug, so if that
version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=debian-cloud-images




signature.asc
Description: OpenPGP digital signature

Bug#930888: augeas-lenses: postfix master lens cannot parse default /etc/postfix/master.cf

[Christopher Cooper]

Hi all,

This has been fixed upstream in
https://github.com/hercules-team/augeas/commit/1e219dbdb9145a5b81c993f691ec2be75099d0bf,
but has not yet landed in a release. Could this patch be included in
the Debian package?

Christopher

On Fri, 21 Jun 2019 21:43:56 + "brian m. carlson" <
sand...@crustytoothpaste.net> wrote:
> Package: augeas-lenses
> Version: 1.12.0-1
> Severity: important
> Tags: upstream
>
> The default augeas lens for Postfix's master.cf cannot parse the
> default configuration file. The configuration file contains the
> following line:
>
>   postlog   unix-dgram n  -   n   -   1   postlogd
>
> Augeas does not understand the "unix-dgram" portion, since the lens
> contains a list of enumerated types and it is not among them.
>
> This prevents Puppet from being used to modify this file on a stock
> Debian buster system.
>
> -- System Information:
> Debian Release: 10.0
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500,
'testing'), (500, 'stable'), (1, 'experimental-debug'), (1,
'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> augeas-lenses depends on no packages.
>
> augeas-lenses recommends no packages.
>
> Versions of packages augeas-lenses suggests:
> pn  augeas-doc  
>
> -- no debconf information
>
> --
> brian m. carlson: Houston, Texas, US
> OpenPGP: https://keybase.io/bk2204

Bug#953821: ITP: dnapi -- adapter prediction for small RNA sequencing - utils

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: dnapi -- adapter prediction for small RNA sequencing - utils
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: dnapi
  Version : 1.1
  Upstream Author : , 2016 Junko Tsuji
* URL : https://github.com/jnktsj/DNApi/
* License : MIT
  Programming Lang: Python
  Description : adapter prediction for small RNA sequencing - utils
 de novo adapter prediction (iterative) algorithm for small RNA sequencing
 data.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/dnapi

Bug#953811: lintian: handle ADTTMP fallback code

[Chris Lamb]

Thorsten Glaser wrote:

> I need to have this code present because I use sadt locally to test
> the autopkgtests, which only sets ADTTMP.

Noted. However, given that ADTTMP is actually deprecated I would like
to confirm that this is not instead a bug in sadt(1) instead.


Regards,

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

Bug#953820: foolscap: should this package be removed?

[Sandro Tosi]

Source: foolscap
Severity: serious

Hello,
i belive this package should be removed:

* python2-only
* upstream hasnt finish porting it to python3
  https://github.com/warner/foolscap/issues/48
* no rdeps in testing

if i dont hear back within a week with a good reason to keep it, i'm gonna file
for its removal.

Regards,
Sandro

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
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= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#936911: librdkafka: Python2 removal in sid/bullseye

[Christian Barcenas]

Control: tags -1 patch

Python is only used in a few small build scripts which are easy to
patch for Python 3.

I have submitted a merge request on Salsa containing (among other
things) a fix for this issue:

  https://salsa.debian.org/kafka-team/librdkafka/-/merge_requests/1

Christian

Bug#953676: gedit: External tool not working on gedit v3.36

[Default User]

Package: gedit
Version: 3.36.0-3
Followup-For: Bug #953676

Dear Maintainer,

[PLEASE DISREGARD MESSAGE #10, AND DELETE, IF POSSIBLE.]

(I am just trying to figure out how to use reportbug, and I am having problems
with it.)

I just want to confirm that I have a very similar problem with gedit, since
updating to 3.36.0-3 on 2020-03-09 (Mon).

The "snippets" function does not paste a snippet into a  document.

And if I run gedit in Gnome terminal, and try to paste a snippet into a
document, I get:

Traceback (most recent call last):
  File "/usr/lib/x86_64-linux-gnu/gedit/plugins/snippets/library.py", line 674,
in accelerator_activated
ret = cb(group, obj, keyval, mod)
  File "/usr/lib/x86_64-linux-gnu/gedit/plugins/snippets/windowactivatable.py",
line 182, in accelerator_activated
return controller.accelerator_activate(keyval, mod)
  File "/usr/lib/x86_64-linux-gnu/gedit/plugins/snippets/document.py", line
150, in accelerator_activate
self.apply_snippet(snippets[0])
  File "/usr/lib/x86_64-linux-gnu/gedit/plugins/snippets/document.py", line
527, in apply_snippet
env = self.get_environment()
  File "/usr/lib/x86_64-linux-gnu/gedit/plugins/snippets/document.py", line
491, in get_environment
v = variables[var](buf)
  File "/usr/lib/x86_64-linux-gnu/gedit/plugins/snippets/document.py", line
441, in env_get_documents_uri
r = self.location_uri_for_env(doc.get_location())
AttributeError: 'Document' object has no attribute 'get_location'
Traceback (most recent call last):
  File "/usr/lib/x86_64-linux-gnu/gedit/plugins/snippets/library.py", line 674,
in accelerator_activated
ret = cb(group, obj, keyval, mod)
  File "/usr/lib/x86_64-linux-gnu/gedit/plugins/snippets/windowactivatable.py",
line 182, in accelerator_activated
return controller.accelerator_activate(keyval, mod)
  File "/usr/lib/x86_64-linux-gnu/gedit/plugins/snippets/document.py", line
150, in accelerator_activate
self.apply_snippet(snippets[0])
  File "/usr/lib/x86_64-linux-gnu/gedit/plugins/snippets/document.py", line
527, in apply_snippet
env = self.get_environment()
  File "/usr/lib/x86_64-linux-gnu/gedit/plugins/snippets/document.py", line
491, in get_environment
v = variables[var](buf)
  File "/usr/lib/x86_64-linux-gnu/gedit/plugins/snippets/document.py", line
441, in env_get_documents_uri
r = self.location_uri_for_env(doc.get_location())
AttributeError: 'Document' object has no attribute 'get_location'


I know nothing about bug reporting, so that's all for now.

Thank you.





-- Package-specific info:

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

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

Versions of packages gedit depends on:
ii  gedit-common   3.36.0-3
ii  gir1.2-glib-2.01.62.0-5+b1
ii  gir1.2-gtk-3.0 3.24.14-1
ii  gir1.2-gtksource-4 4.6.0-1
ii  gir1.2-pango-1.0   1.42.4-8
ii  gir1.2-peas-1.01.26.0-2
ii  gsettings-desktop-schemas  3.36.0-1
ii  iso-codes  4.4-1
ii  libamtk-5-05.0.2-1
ii  libatk1.0-02.34.1-1
ii  libc6  2.30-2
ii  libcairo2  1.16.0-4
ii  libgdk-pixbuf2.0-0 2.40.0+dfsg-3
ii  libgirepository-1.0-1  1.62.0-5+b1
ii  libglib2.0-0   2.64.0-2
ii  libgspell-1-2  1.8.3-1
ii  libgtk-3-0 3.24.14-1
ii  libgtksourceview-4-0   4.6.0-1
ii  libpango-1.0-0 1.42.4-8
ii  libpeas-1.0-0  1.26.0-2
ii  libtepl-4-04.4.0-1
ii  libx11-6   2:1.6.9-2
ii  python33.8.2-1
ii  python3-gi 3.34.0-6
ii  python3-gi-cairo   3.34.0-6
ii  python3.8  3.8.2-1

Versions of packages gedit recommends:
ii  yelp3.34.0-1
ii  zenity  3.32.0-5

Versions of packages gedit suggests:
ii  gedit-plugins  3.36.0-1

-- no debconf information

Bug#953819: FTBFS with Boost 1.71

[Giovanni Mascellani]

Package: src:ns3
Version: 3.30+dfsg-4
Severity: wishlist
User: team+bo...@tracker.debian.org
Usertags: boost1.71

Dear Maintainer,

your package fails to build with boost1.71. If you want to attempt the
build yourself, an updated version of boost-defaults which brings in
boost1.71 dependencies can be found adding this line to your
sources.list file:

  deb https://people.debian.org/~gio/reprepro gio main

This bug has severity whishlist for the moment, but it will raised to RC
as soon as version 1.71 of Boost is promoted to default.

More specifically, your package fails building because it depends on
libboost-signals-dev, which does not exist anymore. However, it doesn't
really use Boost.Signals, so removing the dependency is enough to fix
the FTBFS.

Thanks and all the best, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Bug#953818: python-paver: should this package be removed?

[Sandro Tosi]

Package: python-paver
Severity: serious

Hello,
i believe this package should be removed:

* python2-only
* while upstream has released a py3k compatible version (and several others in
  between the one in the archive), the debian maintainer didnt upload this
  package since late 2013
* no rdeps
* extremely low popcon

if i dont hear back within a week to keep this package, i'll file for its
removal.

Regards,
Sandro

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
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= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python-paver depends on:
ii  libjs-jquery  3.3.1~dfsg-3
ii  python2.7.16-1

python-paver recommends no packages.

python-paver suggests no packages.

Bug#953773: RFS: codelite/14.0+dfsg-1 [QA] -- Powerful and lightweight IDE

[David Hart]

Hi,

>On Fri, Mar 13, 2020 at 11:19:46AM +, David Hart wrote:
>>  * Package name: codelite
>>Version : 14.0+dfsg-1
>> ...
>> This is an update to the latest upstream version, codelite 14.0.
>> The amended package builds and works, and has no significant lintian issues.
>
>Hi!
>I'm afraid it doesn't build on current unstable: there's this bug repeated
>in eleventy zillion places:
>
>/usr/include/wx-3.0/wx/datetime.h:462:40: error: ‘INT_MIN’ was not declared in
>this scope
>  462 | wxDateTime() { m_time = wxLongLong(wxINT32_MIN, 0); }
>  |^~~
>/usr/include/wx-3.0/wx/datetime.h:462:40: note: ‘INT_MIN’ is defined in header
>‘’; did you forget to ‘#include ’?

Argh!, yes. I now get that too after a dist-upgrade, and in a new sbuild (I
don't think my previous one was updating properly). However it also happens when
trying to build the current codelite 13.0 package.

It seems to be a result of gcc upgrading to 9.3.0, and has now been reported
elsewhere: e.g. #953806 and #953796. There's also an explanation (that's well
outside my comfort zone) at
https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1867316 .

IIUC this needs to be fixed in gcc, and there's nothing that can be done at
codelite level.

Thank you for your input.

Regards,

David

Bug#814382: RFH: samba -- SMB/CIFS file, print, and login server for Unix

[Mathieu Parent]

Le ven. 13 mars 2020 à 19:39, Alex Crichton  a écrit :
>
> Hi Jelmer

Hi Alex,

I'm currently the main contributor.

>
>
> RE: RFH: samba -- SMB/CIFS file, print, and login server for Unix
>
>
>
> Is there anything I can help with?

Help includes:
- triaging bug reports: trying to reproduce a bug or ask for
reproducibility, test with newer versions of the packages
- proposing merge requests to improve packaging or to fix bugs
- improving the tests

Note that help is needed in all packages of the pkg-samba team, but
the "samba" package is where most of the work is needed.

>
>
> Regards
>
> Alex

Regards
-- 
Mathieu Parent

Bug#953773: RFS: codelite/14.0+dfsg-1 [QA] -- Powerful and lightweight IDE

[David Hart]

Hi,

>David Hart kirjoitti 13.3.2020 klo 13.19:
>> Changes since the last upload:
>> 
>>* QA upload.
>>  .
>>* New upstream release.
>>  - Remove the .py extension from a script with language-extension
>>  .
>>* d/patches:
>>  - Refresh patches.
>>  - Drop 2 patches applied upstream.
>>  - Make a helper script python3-compatible.
>>  .
>>* debian/control:
>>  - Bump standards to 4.5.0.
>>  .
>>* debian/lintian-overrides:
>>  - Add override for file-references-package-build-path false positive.
>> 
>> This is an update to the latest upstream version, codelite 14.0.
>> The amended package builds and works, and has no significant lintian issues.
>
>Hi!
>
>The codelite-plugins package recommends qt4-qmake which has been removed from
>Debian already. Can the recommendation be upgraded to qt5-qmake?

Thank you for letting me know. I've done so in the git repo, and I'll create an
updated package when building is possible again.

Regards,

David

Bug#938027: [Python-modules-team] Bug#938027: python-pip: Python2 removal in sid/bullseye

[Scott Kitterman]

I don't know of a reason not to go ahead, but if you do, please be careful of 
what's already in git.  Update to the new version is staged there.  It is 
blocked on updates for some of the packages it builds wheels from.

Scott K

On March 13, 2020 7:32:35 PM UTC, Sandro Tosi  wrote:
>On Fri, 30 Aug 2019 07:44:13 + Matthias Klose 
>wrote:
>> Package: src:python-pip
>> Version: 18.1-5
>> Severity: normal
>> Tags: sid bullseye
>> User: debian-pyt...@lists.debian.org
>> Usertags: py2removal
>
>the only rdeps of `bin:python-pip` have been removed from testing, so
>it's probably time we drop this package too!
>
>Carl, Barry: do you see anything wrong with this? what should we do
>about the -whl package? is it still required for something or can we
>drop it along with bin:python-pip? is it needed for anything
>py3k-related?
>
>I would like to proceed quickly, ideally within a week.
>
>thanks,
>Sandro
>
>___
>Python-modules-team mailing list
>python-modules-t...@alioth-lists.debian.net
>https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

Bug#953815: libc6-dev: Cannot build GNU Emacs - limits.h error in configure

[Adam Sjøgren]

Sven writes:

> Known problem, wait for gcc-9 9.3.0-3 to appear on your mirror.

Thanks - sorry for hitting the wrong "target" (I only looked at
libc6-dev and glibc bugs :-/)

> Welcome to unstable!

Been here since bo.


  Best regards,

Adam

-- 
 "Vilken sanning, Måns, är sann?"   Adam Sjøgren
   a...@koldfront.dk

Bug#938027: python-pip: Python2 removal in sid/bullseye

[Sandro Tosi]

On Fri, 30 Aug 2019 07:44:13 + Matthias Klose  wrote:
> Package: src:python-pip
> Version: 18.1-5
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal

the only rdeps of `bin:python-pip` have been removed from testing, so
it's probably time we drop this package too!

Carl, Barry: do you see anything wrong with this? what should we do
about the -whl package? is it still required for something or can we
drop it along with bin:python-pip? is it needed for anything
py3k-related?

I would like to proceed quickly, ideally within a week.

thanks,
Sandro

Bug#953676: gedit: External tool not working on gedit v3.36

[Default User]

Package: gedit
Version: 3.36.0-3
Followup-For: Bug #953676

Dear Maintainer,

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

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

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



-- Package-specific info:

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

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

Versions of packages gedit depends on:
ii  gedit-common   3.36.0-3
ii  gir1.2-glib-2.01.62.0-5+b1
ii  gir1.2-gtk-3.0 3.24.14-1
ii  gir1.2-gtksource-4 4.6.0-1
ii  gir1.2-pango-1.0   1.42.4-8
ii  gir1.2-peas-1.01.26.0-2
ii  gsettings-desktop-schemas  3.36.0-1
ii  iso-codes  4.4-1
ii  libamtk-5-05.0.2-1
ii  libatk1.0-02.34.1-1
ii  libc6  2.30-2
ii  libcairo2  1.16.0-4
ii  libgdk-pixbuf2.0-0 2.40.0+dfsg-3
ii  libgirepository-1.0-1  1.62.0-5+b1
ii  libglib2.0-0   2.64.0-2
ii  libgspell-1-2  1.8.3-1
ii  libgtk-3-0 3.24.14-1
ii  libgtksourceview-4-0   4.6.0-1
ii  libpango-1.0-0 1.42.4-8
ii  libpeas-1.0-0  1.26.0-2
ii  libtepl-4-04.4.0-1
ii  libx11-6   2:1.6.9-2
ii  python33.8.2-1
ii  python3-gi 3.34.0-6
ii  python3-gi-cairo   3.34.0-6
ii  python3.8  3.8.2-1

Versions of packages gedit recommends:
ii  yelp3.34.0-1
ii  zenity  3.32.0-5

Versions of packages gedit suggests:
ii  gedit-plugins  3.36.0-1

-- no debconf information

Bug#953815: libc6-dev: Cannot build GNU Emacs - limits.h error in configure

[Sven Joachim]

Control: reassign -1 cpp-9
Control: forcemerge 953806 -1

On 2020-03-13 20:03 +0100, Adam Sjøgren wrote:

> Package: libc6-dev
> Version: 2.30-2
> Severity: normal
>
> Dear Maintainer,
>
> I cannot build GNU Emacs on Debian unstable after the latest update - 
> configure
> fails with an error with the limits.h include.
>
> Here is a minimal reproduction:
>
> $ cat test.c
> #include 
> #include 
>
> int main(void) {
> exit(0);
> }
> $ gcc -Wall test.c
> In file included from test.c:2:
> /usr/include/limits.h:124:26: error: no include path in which to search for 
> limits.h
>   124 | # include_next 
>   |  ^
> $ 

Known problem, wait for gcc-9 9.3.0-3 to appear on your mirror.
Welcome to unstable!

Cheers,
   Sven

Bug#953815: libc6-dev: Cannot build GNU Emacs - limits.h error in configure

[Adam Sjøgren]

Package: libc6-dev
Version: 2.30-2
Severity: normal

Dear Maintainer,

I cannot build GNU Emacs on Debian unstable after the latest update - configure
fails with an error with the limits.h include.

Here is a minimal reproduction:

$ cat test.c
#include 
#include 

int main(void) {
exit(0);
}
$ gcc -Wall test.c
In file included from test.c:2:
/usr/include/limits.h:124:26: error: no include path in which to search for 
limits.h
  124 | # include_next 
  |  ^
$ 

On Debian stable the example program compiles without problem.

For completeness, here are the errors from the config.log produced by GNU Emacs'
configure:

configure:6307: checking how to run the C preprocessor
configure:6338: gcc -E  conftest.c
In file included from conftest.c:11:
/usr/include/limits.h:124:26: error: no include path in which to search for 
limits.h
  124 | # include_next 
  |  ^
configure:6338: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU Emacs"
| #define PACKAGE_TARNAME "emacs"
| #define PACKAGE_VERSION "28.0.50"
| #define PACKAGE_STRING "GNU Emacs 28.0.50"
| #define PACKAGE_BUGREPORT "bug-gnu-em...@gnu.org"
| #define PACKAGE_URL "https://www.gnu.org/software/emacs/;
| #define HAVE_PDUMPER 1
| /* end confdefs.h.  */
| #ifdef __STDC__
| # include 
| #else
| # include 
| #endif
|Syntax error
configure:6338: gcc -E  conftest.c
In file included from conftest.c:11:
/usr/include/limits.h:124:26: error: no include path in which to search for 
limits.h
  124 | # include_next 
  |  ^
configure:6338: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU Emacs"
| #define PACKAGE_TARNAME "emacs"
| #define PACKAGE_VERSION "28.0.50"
| #define PACKAGE_STRING "GNU Emacs 28.0.50"
| #define PACKAGE_BUGREPORT "bug-gnu-em...@gnu.org"
| #define PACKAGE_URL "https://www.gnu.org/software/emacs/;
| #define HAVE_PDUMPER 1
| /* end confdefs.h.  */
| #ifdef __STDC__
| # include 
| #else
| # include 
| #endif
|Syntax error
configure:6338: gcc -E -traditional-cpp  conftest.c
In file included from /usr/include/features.h:447,
 from /usr/include/assert.h:36,
 from conftest.c:14:
/usr/include/x86_64-linux-gnu/sys/cdefs.h:30:3: error: #error "You need a ISO C 
conforming compiler to use the glibc headers"
   30 | # error "You need a ISO C conforming compiler to use the glibc headers"
  |   ^
configure:6338: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU Emacs"
| #define PACKAGE_TARNAME "emacs"
| #define PACKAGE_VERSION "28.0.50"
| #define PACKAGE_STRING "GNU Emacs 28.0.50"
| #define PACKAGE_BUGREPORT "bug-gnu-em...@gnu.org"
| #define PACKAGE_URL "https://www.gnu.org/software/emacs/;
| #define HAVE_PDUMPER 1
| /* end confdefs.h.  */
| #ifdef __STDC__
| # include 
| #else
| # include 
| #endif
|Syntax error

  [...]

configure:6427: error: in `/usr/src/emacs':
configure:6429: error: C preprocessor "/lib/cpp" fails sanity check

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

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

Versions of packages libc6-dev depends on:
ii  libc-dev-bin2.30-2
ii  libc6   2.30-2
ii  libcrypt-dev1:4.4.15-1
ii  linux-libc-dev  5.4.19-1

libc6-dev recommends no packages.

Versions of packages libc6-dev suggests:
pn  glibc-doc 
ii  manpages-dev  5.05-1

-- no debconf information

Bug#953817: RM: faulthandler -- ROM; python2-only, backport of a py3.3 stdlib module; no rdeps

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#953816: nvidia-settings: query status of attached displays + query monitoring/daemon mode

[Alex Andreotti]

Package: nvidia-settings
Version: 440.64-1
Severity: wishlist
Tags: upstream

Dear Maintainer,

   * What led up to the situation?

1) I have a second monitor (DVI) which is always connected to the video card, 
but it is not always on, I have not found a way with nvidia-settings to detect 
if the second monitor is physically on or off.

2) I run nvidia-settings -t -q ... every few seconds to monitor the status of 
the card, I thought it would be useful to have a command line option for 
nvidia-settings that does not end it immediately, but that continues to re- run 
the query every n seconds.

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

Thanks
Regards

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
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=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nvidia-settings depends on:
ii  libc6 2.29-10
ii  libcairo2 1.16.0-4
ii  libgdk-pixbuf2.0-02.40.0+dfsg-3
ii  libglib2.0-0  2.64.0-2
ii  libgtk-3-03.24.14-1
ii  libgtk2.0-0   2.24.32-4
ii  libjansson4   2.12-1
ii  libpango-1.0-01.42.4-8
ii  libpangocairo-1.0-0   1.42.4-8
ii  libx11-6  2:1.6.9-2
ii  libxnvctrl0   440.64-1
ii  libxxf86vm1   1:1.1.4-1+b2
ii  nvidia-alternative440.64-1
ii  nvidia-installer-cleanup  20151021+11

Versions of packages nvidia-settings recommends:
ii  libgl1-nvidia-glvnd-glx  440.64-1
ii  libnvidia-ml1440.64-1
ii  nvidia-vdpau-driver  440.64-1

nvidia-settings suggests no packages.

-- no debconf information

Bug#953805: zsh-syntax-highlighting: Please make another source-only upload to allow testing migration

[Daniel Shahaf]

Boyuan Yang wrote on Fri, 13 Mar 2020 13:55 -0400:
> Source: zsh-syntax-highlighting
> Version: 0.7.1-1
> Severity: important
> X-Debbugs-CC: danie...@apache.org
> 
> Dear zsh-syntax-highlighting maintainers,
> 
> The latest upload of your package was not a source-only upload. As a result,
> it will not migrate to Testing.
> 
> Please consider making another source-only upload to solve this problem, as
> suggested in https://wiki.debian.org/SourceOnlyUpload . Feel free to let me
> know if there's any questions.
> 

Should be fixed now.

Thanks for the report!

Daniel

Bug#953803: RFS: xdg-utils/1.1.3-2 -- desktop integration utilities from freedesktop.org

[Emilio Pozuelo Monfort]

Hi Nicholas,

On 13/03/2020 18:20, Nicholas Guriev wrote:
> Package: sponsorship-requests
> Severity: normal
> X-Debbugs-CC: pkg-freedesktop-maintain...@lists.alioth.debian.org
> Control: block 652038 by -1
> Control: block 908760 by -1
> Control: block 910070 by -1
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "xdg-utils"

I would sponsor this, but I don't like that you patched the upstream scripts
directly without using a patch system. That will make it harder to merge newer
upstream versions (due to conflicts). If you change that and use proper patches
(ideally git-format'ted ones when coming from upstream), I will happily sponsor
this.

Cheers,
Emilio

Bug#814382: RFH: samba -- SMB/CIFS file, print, and login server for Unix

[Alex Crichton]

Hi Jelmer

 

RE: RFH: samba -- SMB/CIFS file, print, and login server for Unix

 

Is there anything I can help with?

 

Regards

Alex

Bug#953814: RM: ditrack -- RoQA; Depends on Python 2, dead upstream, unmaintainewd

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove ditrack. It depends on Python 2 and is dead upstream and 
unmaintained
(last release/upload in 2008)

Cheers,
Moritz

Bug#883346: release.debian.org: improve reportbug templates for pu and unblock bugs

[Julien Cristau]

Control: reassign -1 reportbug

Yay me.

On Fri, Mar 13, 2020 at 07:36:28PM +0100, Julien Cristau wrote:
> On Sat, Dec 02, 2017 at 07:14:01PM +0100, Julien Cristau wrote:
> > Package: release.debian.org
> > Severity: wishlist
> > 
> > I brought this up in Cambridge, filing here so we can discuss specifics.
> > 
> > At Mozilla we're using a template in bugzilla [1] for requests to
> > cherry-pick changes from trunk to a release branch, to help release
> > management assess reward/risk from specific changes, and I thought
> > something like that might be useful in Debian too.
> > 
> [...]
> > 
> > Ubuntu may have something in their SRU bug process too?
> > 
> > Eventually we could reassign this to reportbug if/when we come to an
> > agreement.
> > 
> Paul ran with this (thanks!) and provided a template for unblocks:
> https://salsa.debian.org/reportbug-team/reportbug/-/merge_requests/31
> and pu:
> https://salsa.debian.org/reportbug-team/reportbug/-/merge_requests/53
> 
> Reassigning to reportbug so it can be closed there.
> 

Bug#883346: release.debian.org: improve reportbug templates for pu and unblock bugs

[Julien Cristau]

On Sat, Dec 02, 2017 at 07:14:01PM +0100, Julien Cristau wrote:
> Package: release.debian.org
> Severity: wishlist
> 
> I brought this up in Cambridge, filing here so we can discuss specifics.
> 
> At Mozilla we're using a template in bugzilla [1] for requests to
> cherry-pick changes from trunk to a release branch, to help release
> management assess reward/risk from specific changes, and I thought
> something like that might be useful in Debian too.
> 
[...]
> 
> Ubuntu may have something in their SRU bug process too?
> 
> Eventually we could reassign this to reportbug if/when we come to an
> agreement.
> 
Paul ran with this (thanks!) and provided a template for unblocks:
https://salsa.debian.org/reportbug-team/reportbug/-/merge_requests/31
and pu:
https://salsa.debian.org/reportbug-team/reportbug/-/merge_requests/53

Reassigning to reportbug so it can be closed there.

Cheers,
Julien

Bug#953811: lintian: handle ADTTMP fallback code

[Thorsten Glaser]

Package: lintian
Version: 2.55.0
Severity: wishlist

W: rs source: uses-deprecated-adttmp debian/tests/regress (line 4)

This is caused by:

tglase@tglase-nb:~/Misc/Vendor/rs $ sed -n 4p debian/tests/regress
test -n "$AUTOPKGTEST_TMP" || AUTOPKGTEST_TMP=${ADTTMP:-$TMPDIR}

I need to have this code present because I use sadt locally to test
the autopkgtests, which only sets ADTTMP. It also has even older
support for if both aren’t set.

Please whitelist this, perhaps don’t flag ADTTMP if it shows up
on a line beginning with “test -n "$AUTOPKGTEST_TMP" ||”.

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils 2.34-4
ii  bzip21.0.8-2
ii  diffstat 1.63-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.38-4
ii  gettext  0.19.8.1-10
ii  gpg  2.2.19-3
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b3
ii  libarchive-zip-perl  1.67-2
ii  libberkeleydb-perl   0.62-1+b1
ii  libcapture-tiny-perl 0.48-1
ii  libcgi-pm-perl   4.46-1
ii  libclass-accessor-perl   0.51-1
ii  libclass-xsaccessor-perl 1.19-3+b3
ii  libclone-perl0.43-2
ii  libdevel-size-perl   0.83-1+b1
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libfont-ttf-perl 1.06-1
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.75-1
ii  libipc-run-perl  20180523.0-2
ii  libjson-perl 4.02000-2
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b5
ii  libmldbm-perl2.05-2
ii  libmoo-perl  2.003006-1
ii  libmoox-aliases-perl 0.001006-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.108-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3200-1
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.008001-2
ii  liburi-perl  1.76-2
ii  libxml-libxml-perl   2.0134+dfsg-2
ii  libyaml-libyaml-perl 0.81+repack-1
ii  man-db   2.9.1-1
ii  patchutils   0.3.4-2+b1
ii  perl [libdigest-sha-perl]5.30.0-9
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1+b1

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
ii  binutils-multiarch 2.34-4
ii  libhtml-parser-perl3.72-5
pn  libtext-template-perl  

-- no debconf information