Bug#961158: ITP: distlib -- Java library of statistical distribution functions

[Pierre Gruet]

Control: retitle -1 ITP: libdistlib-java -- Java library of statistical 
distribution functions

Hi Scott and Andreas,

Le 21/05/2020 à 06:44, Scott Kitterman a écrit :
> On Thursday, May 21, 2020 12:08:44 AM EDT Andreas Tille wrote:

>> At least the name of the binary package should be
>>
>> libdistlib-java
>>
>> Choosing the same name for the source package as the binary package is
>> frequently done.
> 
> That would certainly resolve my concern.
> 
> Thanks,
> 
> Scott K
> 

Thanks for your reactions and suggestions, this looks fine. I am therefore 
renaming the ITP bug
and changing the identification block for this new package to the following.

* Package name: libdistlib-java
  Version : 0.9.1
  Upstream Author : Peter N. Steinmetz
* URL : https://sourceforge.net/projects/statdistlib
* License : GPL-2
  Programming Lang: Java
  Description : Java library of statistical distribution functions

Best regards,
Pierre

Bug#959236: Bonding doesn't work

[Roberto Ibáñez]

Bonding doesn't work. Same behavior here.

Debian bullseye/sid 5.6.0-1-amd64 #1 SMP Debian 5.6.7-1 (2020-04-29) x86_64
GNU/Linux

 /etc/network/if-pre-up.d/ifenslave: 67: Maximum function recursion depth
(1000) reached

Bug#961191: src:python-traceback2: fails to migrate to testing for too long: makes python-unittest2 non-installable

[Paul Gevers]

Source: python-traceback2
Version: 1.4.0-5
Severity: serious
Control: close -1 1.4.0-6
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:python-traceback2 in its current version in unstable has been trying
to migrate for 60 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 immediately closed this bug with the version in unstable, 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=python-traceback2




signature.asc
Description: OpenPGP digital signature

Bug#961190: ITP: libla4j-java -- Linear Algebra for Java

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: libla4j-java -- Linear Algebra for Java
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: libla4j-java
  Version : 0.6.0
  Upstream Author : , Vladimir Kostyukov 
* URL : http://la4j.org
* License : Apache-2.0
  Programming Lang: Java
  Description : Linear Algebra for Java
 La4j (Linear Algebra for Java) is a 100% Java library that provides
 Linear Algebra primitives (matrices and vectors) and algorithms. The
 la4j library was initially designed to be a lightweight and simple
 tool for passionate Java developers.

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

Bug#961158: ITP: distlib -- Java library of statistical distribution functions

[Scott Kitterman]

On Thursday, May 21, 2020 12:08:44 AM EDT Andreas Tille wrote:
> Hi,
> 
> On Wed, May 20, 2020 at 04:30:47PM -0400, Scott Kitterman wrote:
> > On Wednesday, May 20, 2020 4:23:41 PM EDT Pierre Gruet wrote:
> > > Package: wnpp
> > > Severity: wishlist
> > > Owner: Debian-med project 
> > > 
> > > * Package name: distlib
> > > 
> > >   Version : 0.9.1
> > >   Upstream Author : Peter N. Steinmetz
> > > 
> > > * URL : https://sourceforge.net/projects/statdistlib
> > > ...
> > > This package will be taken care of in Debian-med team, where it is
> > > needed as a dependency of SnpEff.
> 
> Very cool!  Pierre, thanks a lot!
> 
> > "distlib" is a very generic name.  Could the package be named java-distlib
> > or some other more specific term?
> 
> At least the name of the binary package should be
> 
> libdistlib-java
> 
> Choosing the same name for the source package as the binary package is
> frequently done.

That would certainly resolve my concern.

Thanks,

Scott K

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

Bug#961188: src:postgis: autopkgtests fail on 32bit ARM, due to missing sfcgal

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Stefano,

Thank for reporting this issue with a patch. Instead of applying your
patch I chose to skip the autopkgtests entirely on arm{el,hf} like we do
for other problematic architectures.

Kind Regards,

Bas

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

Bug#961189: mc: include Markdown viewing support

[Celejar]

Package: mc
Version: 3:4.8.24-2
Severity: wishlist

I suggest that mc include support for proper viewing of Markdown files
out of the box. They are ubiquitious these days, due to the popularity
of GitHub.

I'm currently using this snippet in $HOME/.config/mc.ext:

# Markdown
shell/i/.md
View=pandoc %f | lynx -stdin

mc gurus can likely come up with something better - there are a bunch of
suggestions here:

https://unix.stackexchange.com/questions/4140/markdown-viewer

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

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

Versions of packages mc depends on:
ii  libc6 2.30-8
ii  libext2fs21.45.6-1
ii  libglib2.0-0  2.64.2-1
ii  libgpm2   1.20.7-6
ii  libslang2 2.3.2-4
ii  libssh2-1 1.8.0-2.1
ii  mc-data   3:4.8.24-2

Versions of packages mc recommends:
ii  mime-support  3.64
ii  perl  5.30.2-1
ii  unzip 6.0-25

Versions of packages mc suggests:
pn  arj   
ii  bzip2 1.0.8-2
pn  catdvi | texlive-binaries 
pn  dbview
pn  djvulibre-bin 
pn  epub-utils
ii  evince [pdf-viewer]   3.36.1-1
ii  file  1:5.38-5
ii  genisoimage   9:1.1.11-3.1
pn  gv
ii  imagemagick-6.q16 [imagemagick]   8:6.9.10.23+dfsg-2.1+b2
pn  libaspell-dev 
ii  lynx  2.9.0dev.5-1
ii  mupdf [pdf-viewer]1.16.1+ds1-2
pn  odt2txt   
ii  poppler-utils 0.71.0-6
ii  python2.7.17-2
pn  python-boto   
pn  python-tz 
ii  qpdfview [pdf-viewer] 0.4.18-1+b1
ii  zathura-pdf-poppler [pdf-viewer]  0.3.0-1
ii  zip   3.0-11+b1

-- no debconf information

Bug#961183: metis: providing a 64-bit build

[Drew Parsons]

Should add a caveat on the urgency: this bug report is Wishlist, really.

That's because mumps uses scotch rather than metis. This is because 
parmetis is not available (not-free).


If the licence for parmetis became free, then we would use it with mumps 
(and would be looking for a 64-bit build).


Drew

Bug#961188: src:postgis: autopkgtests fail on 32bit ARM, due to missing sfcgal

[Stefano Rivera]

Package: src:postgis
Version: 3.0.1+dfsg-4
Severity: normal
Tags: patch

The libsfcgal-dev Build-Dep is arch-specific, but the autopkgtests don't
avoid exercising this area, leading to autopkgtest failures like this on
armhf:

> CREATE EXTENSION postgis
> CREATE EXTENSION
> CREATE EXTENSION postgis_raster
> CREATE EXTENSION
> CREATE EXTENSION postgis_sfcgal
> ERROR:  could not find function "postgis_sfcgal_version" in file 
> "/usr/lib/postgresql/12/lib/postgis-3.so"
> *** /tmp/pg_virtualenv.cMSs63/log/postgresql-12-regress.log (last 100 lines) 
> ***
...
> autopkgtest [04:16:30]:  summary
> test-extension-creation FAIL non-zero exit status 1
> regress  FAIL non-zero exit status 2

Full autopkgtest log attached.

Patch attached.

SR
diff -Nru postgis-3.0.1+dfsg/debian/tests/regress postgis-3.0.1+dfsg/debian/tests/regress
--- postgis-3.0.1+dfsg/debian/tests/regress	2020-04-17 11:30:49.0 -0700
+++ postgis-3.0.1+dfsg/debian/tests/regress	2020-05-20 16:02:36.0 -0700
@@ -34,6 +34,8 @@
   pg_virtualenv -v $v <<-EOF
 	set -eux
 	make -C regress/core -f Makefile.in check PERL=perl RUNTESTFLAGS="--extension --verbose" POSTGIS_GEOS_VERSION=$POSTGIS_GEOS_VERSION
-	make -C regress/sfcgal -f Makefile.in check PERL=perl RUNTESTFLAGS="--extension --verbose" HAVE_SFCGAL=yes
+	if [ "$ARCH" != "armhf" -a "$ARCH" != "armel" ]; then
+		make -C regress/sfcgal -f Makefile.in check PERL=perl RUNTESTFLAGS="--extension --verbose" HAVE_SFCGAL=yes
+	fi
 	EOF
 done
diff -Nru postgis-3.0.1+dfsg/debian/tests/test-extension-creation postgis-3.0.1+dfsg/debian/tests/test-extension-creation
--- postgis-3.0.1+dfsg/debian/tests/test-extension-creation	2020-04-17 11:30:49.0 -0700
+++ postgis-3.0.1+dfsg/debian/tests/test-extension-creation	2020-05-20 16:08:18.0 -0700
@@ -5,9 +5,13 @@
 for v in $(pg_buildext supported-versions); do
 	pg_virtualenv -v $v sh -e <<-'EOF'
 	# test extension (fuzzystrmatch is part of postgresql-contrib and is needed by postgis_tiger_geocoder)
-	for ext in postgis postgis_raster postgis_sfcgal fuzzystrmatch postgis_tiger_geocoder postgis_topology address_standardizer address_standardizer_data_us; do
+	for ext in postgis postgis_raster fuzzystrmatch postgis_tiger_geocoder postgis_topology address_standardizer address_standardizer_data_us; do
 		psql -eXc "CREATE EXTENSION $ext"
 	done
+	ARCH="$(dpkg-architecture -qDEB_BUILD_ARCH)"
+	if [ "$ARCH" != "armhf" -a "$ARCH" != "armel" ]; then
+		psql -eXc "CREATE EXTENSION postgis_sfcgal"
+	fi
 	EOF
 done
 
autopkgtest [04:11:01]: version 5.11ubuntu1
autopkgtest [04:11:01]: host ip-172-18-1-80; command line: /usr/bin/autopkgtest 
-o adt-sid -BU postgis -- schroot unstable-armhf-sbuild
autopkgtest [04:11:01]:  test bed setup
Hit:1 http://deb.debian.org/debian unstable InRelease
Get:2 http://deb.debian.org/debian unstable/main Translation-en [6185 kB]
Fetched 6185 kB in 3s (2102 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
autopkgtest [04:11:07]: testbed dpkg architecture: armhf
autopkgtest [04:11:07]: testbed running kernel: Linux 5.4.0-1009-aws #9-Ubuntu 
SMP Sun Apr 12 19:42:55 UTC 2020
autopkgtest [04:11:07]:  apt-source postgis
Get:1 http://deb.debian.org/debian unstable/main postgis 3.0.1+dfsg-4 (dsc) 
[2945 B]
Get:2 http://deb.debian.org/debian unstable/main postgis 3.0.1+dfsg-4 (tar) 
[9093 kB]
Get:3 http://deb.debian.org/debian unstable/main postgis 3.0.1+dfsg-4 (diff) 
[41.0 kB]
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/home/ubuntu/.gnupg/trustedkeys.kbx': General error
gpgv: Signature made Sun May  3 13:58:33 2020 UTC
gpgv:using RSA key 8182DE417056408D614650D16750F10AE88D4AF1
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on ./postgis_3.0.1+dfsg-4.dsc
autopkgtest [04:11:11]: testing package postgis version 3.0.1+dfsg-4
autopkgtest [04:11:11]: build not needed
autopkgtest [04:11:12]: test test-extension-creation: preparing testbed
Reading package lists...
Building dependency tree...
Correcting dependencies...Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
 Done
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
The following additional packages will be installed:
  adwaita-icon-theme binfmt-support clang-10 fontconfig fontconfig-config
  fonts-dejavu-core gdal-data gtk-update-icon-cache hicolor-icon-theme libaec0
  libarmadillo9 libarpack2 libatk1.0-0 libatk1.0-data libavahi-client3
  libavahi-common-data libavahi-common3 libblas3 libbrotli1 libbsd0 libc-l10n
  libcairo2 libcfitsio8 libcharls2 libclang-common-10-dev libclang-cpp10
  libclang1-10 libcups2 libcurl3-gnutls libdap25 libdapclient6v5 libdatrie1
  libdbus-1-3 libecpg-compat3 l

Bug#961158: ITP: distlib -- Java library of statistical distribution functions

[Andreas Tille]

Hi,

On Wed, May 20, 2020 at 04:30:47PM -0400, Scott Kitterman wrote:
> On Wednesday, May 20, 2020 4:23:41 PM EDT Pierre Gruet wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Debian-med project 
> > 
> > * Package name: distlib
> >   Version : 0.9.1
> >   Upstream Author : Peter N. Steinmetz
> > * URL : https://sourceforge.net/projects/statdistlib
> > ...
> > This package will be taken care of in Debian-med team, where it is needed as
> > a dependency of SnpEff.

Very cool!  Pierre, thanks a lot!

> "distlib" is a very generic name.  Could the package be named java-distlib or 
> some other more specific term?

At least the name of the binary package should be

libdistlib-java

Choosing the same name for the source package as the binary package is
frequently done.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#961187: pulseaudio: CPU 100% when play one song,alsa-util.c: snd_pcm_avail() return very big value

[xiao sheng wen]

Package: pulseaudio
Version: 12.2-4+deb10u1
Severity: normal

Dear Maintainer,

When I play one song,I meet the CPU  100%.
I only can reboot my laptap.

There is the following error info in /var/log/syslog:


May 21 11:12:52 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c: snd_pcm_avail() 返回的值非常大：5628016 字节(31904 毫秒)。

translate to En:   ~~~return value very big~~~

May 21 11:12:53 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c: 这很可能是由 ALSA 驱动程序 snd_hda_intel 的缺陷导致的。请向 ALSA 开发者报告这个问题。

translate to En:   ~~This possible is the bug of ALSA driver snd_hda_intel. 
Please report the bug to ALSA developer.~~~
 
May 21 11:12:53 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c: snd_pcm_dump():
May 21 11:12:53 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c: Soft volume PCM
May 21 11:12:53 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c: Control: PCM Playback Volume
May 21 11:12:53 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c: min_dB: -51
May 21 11:12:53 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c: max_dB: 0
May 21 11:12:54 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c: resolution: 256
May 21 11:12:54 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c: Its setup is:
May 21 11:12:54 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c:   stream   : PLAYBACK
May 21 11:12:54 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c:   access   : MMAP_INTERLEAVED
May 21 11:12:54 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c:   format   : S16_LE
May 21 11:12:54 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c:   subformat: STD
May 21 11:12:54 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c:   channels : 2
May 21 11:12:54 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c:   rate : 44100
May 21 11:12:54 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c:   exact rate   : 44100 (44100/1)
May 21 11:12:54 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c:   msbits   : 16
May 21 11:12:54 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c:   buffer_size  : 88200
May 21 11:12:54 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c:   period_size  : 44100
May 21 11:12:54 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c:   period_time  : 100
May 21 11:12:54 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c:   tstamp_mode  : ENABLE
May 21 11:12:54 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c:   tstamp_type  : MONOTONIC
May 21 11:12:54 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c:   period_step  : 1
May 21 11:12:54 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c:   avail_min: 86878
May 21 11:12:54 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c:   period_event : 0
May 21 11:12:54 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c:   start_threshold  : -1
May 21 11:12:54 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c:   stop_threshold   : 6206523236469964800
May 21 11:12:54 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c:   silence_threshold: 0
May 21 11:12:54 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c:   silence_size : 0
May 21 11:12:54 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c:   boundary : 6206523236469964800
May 21 11:12:54 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c: Slave: Hardware PCM card 0 'HDA Intel PCH' device 0 subdevice 0
May 21 11:12:55 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c: Its setup is:
May 21 11:12:56 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c:   stream   : PLAYBACK
May 21 11:12:57 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c:   access   : MMAP_INTERLEAVED
May 21 11:13:39 atzlinux pulseaudio[1344]: E: [alsa-sink-ALC233 Analog] 
alsa-util.c:   format   : S16_LE


This bug can't been reproduce,only take palace once.


-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

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

Versions of packages pulseaudio depends on:
ii  adduser  3.118
ii  libasound2   

Bug#961186: scalapack: provide a 64-bit build

[Drew Parsons]

Source: scalapack
Severity: normal

We're discussing introducing a 64 bit-build for the computational
stack. This refers to 64-bit addressing to cells in meshes, etc.

c.f. Bug#953116 (petsc)
Bug#961108 (openmpi)
https://lists.debian.org/debian-science/2020/05/msg00051.html

BLAS is already 64-bit enabled.

For the 64-bit environment to work, it needs to be carried through all
along the library stack, from BLAS to PETSc.

MUMPS is in the middle, and depends on scalapack (and blas/lapack).

It's not clear that scalapack needs a direct 64-bit build as such.
It has no 64-bit build flag.  But it does depend on blas/lapack, so
scalapack will need separate builds to catch the 32-bit and 64-bit
blas (and MPI) builds.

Probably we want 2 separate builds, 32-bit (the current
libscalapack-mpi-dev) and a separate 64-bit libscalapack64-mpi-dev
(with openmpi/mpich variants)

Opening this bug to track the chain of 64-bit package dependencies.

Bug#961185: mumps: provide 64-bit build

[Drew Parsons]

Source: mumps
Severity: normal

We're discussing introducing a 64 bit-build for the computational
stack. This refers to 64-bit addressing to cells in meshes, etc.

c.f. Bug#953116 (petsc)
Bug#961108 (openmpi)
https://lists.debian.org/debian-science/2020/05/msg00051.html

BLAS is already 64-bit enabled.

For the 64-bit environment to work, it needs to be carried through all
along the library stack, from BLAS to PETSc.

MUMPS is in the middle.

Probably we want 2 separate builds, 32-bit (the current libmumps-dev)
and a separate 64-bit libmumps64-dev.

Opening this bug to track the chain of 64-bit package dependencies.

Bug#961184: scotch: provide 64-bit build

[Drew Parsons]

Source: scotch
Severity: normal

We're discussing introducing a 64 bit-build for the computational
stack. This refers to 64-bit addressing to cells in meshes, etc.

c.f. Bug#953116 (petsc)
Bug#961108 (openmpi)
https://lists.debian.org/debian-science/2020/05/msg00051.html

BLAS is already 64-bit enabled.

For the 64-bit environment to work, it needs to be carried through all
along the library stack, from BLAS to PETSc.

MUMPS is in the middle. Its docs indicate that its 64-bit support
requires SCOTCH to be 64-bit enabled.

Probably we want 2 separate builds, 32-bit (the current libmetis-dev)
and a separate 64-bit libmetis64-dev.

Opening this bug to track the chain of 64-bit package dependencies.

Bug#961183: metis: providing a 64-bit build

[Drew Parsons]

Source: metis
Severity: normal

We're discussing introducing a 64 bit-build for the computational
stack. This refers to 64-bit addressing to cells in meshes, etc.

c.f. Bug#953116 (petsc)
Bug#961108 (openmpi)
https://lists.debian.org/debian-science/2020/05/msg00051.html

BLAS is already 64-bit enabled.

For the 64-bit environment to work, it needs to be carried through all
along the library stack, from BLAS to PETSc.

MUMPS is in the middle. Its docs indicate that its 64-bit support
requires METIS to be 64-bit enabled.

Probably we want 2 separate builds, 32-bit (the current libmetis-dev)
and a separate 64-bit libmetis64-dev.

Opening this bug to track the chain of 64-bit package dependencies.

Bug#961182: ITP: nni -- An open source AutoML toolkit for automate machine learning lifecycle

[Mo Zhou]

Package: wnpp
Severity: wishlist
Owner: Mo Zhou 

* Package name: nni
* URL : https://github.com/microsoft/nni
* License : MIT/Expat
  Programming Lang: Python
  Description : An open source AutoML toolkit for automate machine learning 
lifecycle

AutoML.
Debian Deep Learning Team.

Bug#961181: ITP: tpot -- Automated Machine Learning tool that optimizes machine learning pipelines using genetic programming

[Mo Zhou]

Package: wnpp
Severity: wishlist
Owner: Mo Zhou 

* Package name: tpot
* URL : https://github.com/EpistasisLab/tpot
* License : LGPL-3.0
  Programming Lang: Python
  Description : Automated Machine Learning tool that optimizes machine 
learning pipelines using genetic programming

AutoML.
Debian Deep Learning Team.

Bug#961130: ethtool can read DOM values

[Ben Hutchings]

Control: reassign -1 src:linux 4.19.118-2

On Wed, 2020-05-20 at 13:09 +, Yannis Aribaud wrote:
> Package: ethtool
> Version: 1:4.19-1
> Severity: important
> The command ethtool -m  is unable to read the transceiver DOM values.

Again, this is a driver or hardware issue, not a bug in ethtool.

[...]
> As you can see all mesuring values are zeros.
> I am using Debian GNU/Linux 10 (buster), kernel 4.19.0-9-amd64 #1 SMP
> Debian 4.19.118-2 (2020-04-29) x86_64 GNU/Linux and libc6 2.28-10
> 
> FYI, I get correct values using SystemRescueCD 6 (ethtool 5.0, kernel
> 4.19.34-1-lts) on this same hardware, using the same command.

I see no changes to ethtool between 4.19 and 5.0 that would explain
that.

Ben.

-- 
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.



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

Bug#961180: RFS: rumur/2020.05.18-1 -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "rumur"

* Package name: rumur
   Version : 2020.05.18-1
   Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
   Section : devel

It builds those binary packages:

  rumur - model checker for the Murphi language

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/rumur/rumur_2020.05.18-1.dsc

Changes since the last upload:

   * New upstream release.
.
   * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository,
 Repository-Browse, thanks to Debian Janitor.

Regards,
Matthew

Bug#942960: patch

[Kunal Mehta]

tags 942960 + patch
thanks

I submitted a pretty straightforward patch at
, please let
me know if you'd prefer I upload it to the BTS.

-- Kunal / Legoktm



signature.asc
Description: OpenPGP digital signature

Bug#953116: Bug#961108: openmpi: providing 64-bit MPI

[Drew Parsons]

Hi Gard, bringing this question over to petsc bug#953116.


On 2020-05-20 17:07, Gard Spreemann wrote:

Drew Parsons  writes:


If I understand correctly, it's dangerous to simply enable 64-bit in
PETSc alone. It needs to be done all along the computational library
stack.


In the case of PETSc, is the intention to change to using the 64-bit
indexing option, or to provide a new additional package that uses 
64-bit

indexing? The latter sounds burdensome long-term, so I would probably
lean towards the former.


I was assuming we'd carry the two bit builds, "petsc-dev" and 
"petsc64-dev", at least in the medium term.  This would follow what's in 
place with BLAS.  It's also the practice in CRAY which offers both 
cray-petsc and cray-petsc-64 modules.


But it's a good question to consider.



If you do intend to go for the former, I think it's a good idea to very
clearly warn the user upon upgrade. The PETSc binary sparse matrix and
vector file formats are assumed to use whatever indexing data types 
that

the library is compiled with, and as far as I remember there is no
metadata about this in the file format itself. Without warning, I
suspect a lot of users might burn themselves when using LoadMat [1] and
friends on data files written with 32 bit index versions of the
package. I don't know how common the file format is and whether most
people just use HDF5, but I know I've often used the PETSc format to
avoid the complications of HDF5.


Certainly.  I can anticipate it might be quite disruptive if the 
standard package just jumps to 64 bit. I imagine that would break 
things.



One question to consider is why petsc doesn't just use 64 bits in the 
first place on 64 bit systems.


I was under the impression that a 32 bit build actually runs faster on a 
64 bit system, in the sense of getting twice as much done per clock 
cycle. That you only need the 64 bit build if you actually need that 
much address space (i.e. if your mesh carrys that many degree of freedom 
DOFs)


I guess we should clear up whether that's true or not. It would be 
regrettable to drop 32 bit if it means performance on smaller jobs is 
diminished.



PS: I can volunteer to write a 32->64 bit conversion tool for these
files if desired. Ideally I guess upstream should provide 32/64-bit
specific versions of the reading/writing functions.


That could be a helpful tool.  We could include it the -dev packages.

Drew

Bug#942094: [Aptitude-devel] Bug#942094: aptitude: [INTL:fr] French templates translation

[Axel Beckert]

Hi Jean-Pierre,

Jean-Pierre Giraud wrote:
> This file should be put as debian/po/fr.po in your package build
> tree.

I'm sorry, but this is wrong. There is no debian/po directory in
aptitude's source package. The file looks similar like the
doc/po4a/po/fr.po in aptitude's source tree, so I will try to replace
that one with your file.

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

Bug#961179: RFS: inkscape-textext/1.0.1-1 [ITP] -- Re-editable LaTeX graphics for Inkscape

[Antonio Russo]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: 942...@bugs.debian.org

Dear mentors,

I am looking for a sponsor for my package "inkscape-textext"

 * Package name: inkscape-textext
   Version : 1.0.1-1
   Upstream Author : Jan Winkler 
 * URL : https://textext.github.io/textext
 * License : AGPL
 * Vcs : https://github.com/textext/textext
   Section : graphics
   Description : Re-editable LaTeX graphics for Inkscape

TexText is a Python plugin for the vector graphics editor Inkscape
providing the possibility to add and re-edit LaTeX generated SVG
elements to your drawing.

 Key features
 . Windows/Linux/MacOS support
 . LaTeX generated SVG elements can be re-edited later
 . Multi-line editor with syntax highlighting
 . Compilation with PdfLaTeX, XeLaTeX or LuaLaTex
 . Interoperable scaling in TexText and Inkscape
 . Font size match with Inkscape text
 . Customizable TeX preamble (additional packages, parskip, parindent, etc.)
 . Colorization via TeX commands/Inkscape is kept after re-editing
 . Alignment anchor of the produced output
 . Preview images

Since my last upload, upstream has released 1.0 (and 1.0.1).  Now that
there is an upstream release, the package is suitable for unstable, rather
than experimental.  I've renamed the package to inkscape-textext, aligning
with the naming of other inkscape extensions I have found.

The package is lintian clean, with the exception of the warning about
upstream tarball signing (and tests) [1].  I'm currently interacting with
upstream to get signed releases [2].

The packaging is maintained in Debian salsa [3], and builds in pbuilder.

Best,
Antonio Russo

[1] https://mentors.debian.net/package/inkscape-textext
[2] https://github.com/textext/textext/issues/231
[3] https://salsa.debian.org/aerusso-guest/textext

Bug#960562: [Aptitude-devel] Bug#960562: had to reinstall a package to avoid 'bullying'

[積丹尼 Dan Jacobson]

AB> * APT::AutoRemove::RecommendsImportant (when set to false)
AB> * APT::AutoRemove::SuggestsImportant (when set to false)..
AB> I though was not able to find a combination of these and
AB> Aptitude::Purge-Unused to provoke this behaviour either.

Well

APT::Default-Release "unstable";
APT::AutoRemove::RecommendsImportant false;
APT::AutoRemove::SuggestsImportant false;
APT::Cache::AllVersions false;
APT::Clean-Installed false;
APT::Get::Fix-Missing true;
APT::Get::Purge true;
APT::Install-Recommends false;
APT::Keep-Downloaded-Packages true;
APT::Periodic::Enable false;
Acquire::PDiffs true;
Acquire::http::No-Cache true;
Aptitude::CmdLine::Always-Prompt true;
Aptitude::CmdLine::Show-Deps true;
Aptitude::CmdLine::Show-Why true;
Aptitude::CmdLine::Verbose 1;
Aptitude::Purge-Unused true;
Binary::apt::APT::Keep-Downloaded-Packages true;

is all that is in my 10jidanni in directory /etc/apt/apt.conf.d/ :
01autoremove  05security  20apt-show-versions  70debconf
01autoremove-kernels  10jidanni   20listchanges

Well it already happened on two of my machines.
I still have one machine in town that I will make a note of doing
aptitude-create-state-bundle for you first, and waiting for your reply
until fixing... but it might be months before I go there.

As far a fdisk (which I use every few months), yes I(?) installed it 20
years ago so it was quite a surprise to see it suddenly on the chopping
block.

Bug#942249: RFS: inkscape-textext/1.0.1-1 [ITP] -- Re-editable LaTeX graphics for Inkscape

[Antonio Russo]

Dear mentors,

I am looking for a sponsor for my package "inkscape-textext"

 * Package name: inkscape-textext
   Version : 1.0.1-1
   Upstream Author : Jan Winkler 
 * URL : https://textext.github.io/textext
 * License : AGPL
 * Vcs : https://github.com/textext/textext
   Section : graphics
   Description : Re-editable LaTeX graphics for Inkscape

TexText is a Python plugin for the vector graphics editor Inkscape
providing the possibility to add and re-edit LaTeX generated SVG
elements to your drawing.

 Key features
 . Windows/Linux/MacOS support
 . LaTeX generated SVG elements can be re-edited later
 . Multi-line editor with syntax highlighting
 . Compilation with PdfLaTeX, XeLaTeX or LuaLaTex
 . Interoperable scaling in TexText and Inkscape
 . Font size match with Inkscape text
 . Customizable TeX preamble (additional packages, parskip, parindent, etc.)
 . Colorization via TeX commands/Inkscape is kept after re-editing
 . Alignment anchor of the produced output
 . Preview images

Since my last upload, upstream has released 1.0 (and 1.0.1).  Now that
there is an upstream release, the package is suitable for unstable, rather
than experimental.  I've renamed the package to inkscape-textext, aligning
with the naming of other inkscape extensions I have found.

The package is lintian clean, with the exception of the warning about
upstream tarball signing (and tests) [1].  I'm currently interacting with
upstream to get signed releases [2].

The packaging is maintained in Debian salsa [3], and builds in pbuilder.

Best,
Antonio Russo

[1] https://mentors.debian.net/package/inkscape-textext
[2] https://github.com/textext/textext/issues/231
[3] https://salsa.debian.org/aerusso-guest/textext

Bug#961178: RM: libasr -- ROM; merged into opensmtpd

[Ryan Kavanagh]

Package: ftp.debian.org
Severity: normal

Please remove the source package libasr. It has been merged back into
the opensmtpd project and is no longer developed separately.

libasr's only reverse dependencies were opensmtpd and opensmtpd-extras,
and the most recent versions of these packages in unstable no longer
(build-)depend on libasr.

See upstream's announcement [0] for more details.

Thanks,
Ryan

[0] 
https://poolp.org/posts/2020-01-22/january-2020-opensmtpd-work-libasr-and-libtls/

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#766441: RFA: scala-mode-el -- Emacs major mode for editing scala source code

[Nicholas D Steeves]

P.S.  Are you using the following as the new upstream source?:

  https://github.com/hvesalai/emacs-scala-mode

I've received confirmation this is the one smartparens requires.


signature.asc
Description: PGP signature

Bug#766441: RFA: scala-mode-el -- Emacs major mode for editing scala source code

[Nicholas D Steeves]

Hi Sławomir,

Thank you for your interest and initiative!

Sławomir Wójcik  writes:

[snip]
> One issue is that I've created the repo from scratch because git repo is not
> reachable, existing package have quite ancient upstream version and it's 
> debian
> files(especially rules is obviously not using dh-elpa) are mostly outdated.
>
> I can try to use gbp-import-dsc and recreate a new repo if it's really 
> necessary
> or required but I don't see much value in it because:
>

The issue isn't the "repo" so much as continuity with the existing
source package.  Two people's occasional contributions over three years
are valuable, and erasing them from Debian history would be unjust.

> -if we want to adhere to EmacsenTeam Addons packaging policy
> (https://wiki.debian.org/EmacsenTeam) and I think we should for better
> collaboration and consistency then the package name should be changed to
> elpa-scala-mode and existing https://packages.debian.org/sid/scala-mode-el
> should be marked as transitional dummy package installing new one, right?
>

The binary package name should be elpa-scala-mode, but the source
package should remain scala-mode-el.

> -upstream version in existing package and most of debian files are very old
> or outdated
>

Yup, that's part of the work of adopting a package that needs work ;-)

> Please, let me know what should be done. As I pointed out here:
> https://lists.debian.org/debian-emacsen/2020/05/msg00039.html
> it would be the best if someone from Debian Emacsen Packaging Team will work
> with me on this and other packages but maybe someone else will be 
> interested to
> give his/her opinion.
>

If you proceed with this ITP I'd like to work with you and/or comaintain
it, because it's a blocker for my smartparens ITP.

Best,
Nicholas


signature.asc
Description: PGP signature

Bug#893983: ITP: all-the-icons-el -- library for inserting developer icons in Emacs

[Nicholas D Steeves]

I just learned that I had never provided my rationale for abandoning
this ITP.

I do not believe this one meets our high standards, which is why I gave
up on the ITP.  Namely, I investigated the standards of the Font Team,
saw how they were generating fonts, saw this was not possible with
all-the-icons.el.  I believe I also filed some bugs and/or attempted to
contact our Font Team, but sadly never received a reply.  At any rate,
while I think font icons are a cool hack, others have expressed strong
opinions about how font icons are an abomination that should DIAF.

Supposing we did go ahead with uploading this, my concerns are:  1)
trademarked images that are removed from the font-foo packages for DFSG
reasons.  2) Conflicts with the system-wide font-foo packages and
associated bug potential.  3) Missing collaboration with the Font Team.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#961144: ucf breaks bacula autopkgtest: Job for bacula-director.service failed

[Manoj Srivastava]

The usage of ucf in debian/bacula-director.postinst seems fine.

Manoj
--
Nothing ever becomes real till it is experienced -- even a proverb is no
proverb to you till your life has illustrated it.  -- John Keats
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


smime.p7s
Description: S/MIME cryptographic signature

Bug#961144: ucf breaks bacula autopkgtest: Job for bacula-director.service failed

[Manoj Srivastava]

Hi,

There is very little actionable in the bug report. We can’t see
 the ucf invocation, nor do we see any error messages that might point
 us to the root cause.

The last lines in the logs:
--8<---cut here---start->8---
service bacula-director restart
Job for bacula-director.service failed because the control process
exited with error code.
See "systemctl status bacula-director.service" and "journalctl -xe" for
details.
--8<---cut here---end--->8---

Point to bacula-director failing to start, which has probably
 little to do with ucf. The package install part of the logs seems to go
 wiothout an error.

--8<---cut here---start->8---
 apt-get -y install bacula bacula-director-pgsql
Reading package lists...
Building dependency tree...
Reading state information...
bacula is already the newest version (9.6.3-1).
bacula-director-pgsql is already the newest version (9.6.3-1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
--8<---cut here---end--->8---

Indeed, this does not seem ucf at all.

Can you show me what I am missing?

Manoj
--
Numeric stability is probably not all that important when you're
guessing.
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


smime.p7s
Description: S/MIME cryptographic signature

Bug#961088: Acknowledgement (libsane-hpaio fails to detect HP MFDs)

[Jan Nordholz]

Hi,

my issue is plain and simple: libsane.hpaio.1.0.0 is no longer dlopen()able
due to an unresolved symbol '_DBG', used in scan/sane/orblite.c:198.
You can check this easily by running scanimage with envvar SANE_DEBUG_DLL=1:

=
] jan@p53:~$ SANE_DEBUG_DLL=1 scanimage -d 
"hpaio:/net/envy_5000_series?ip=192.168.178.41&queue=false" -T
] [sanei_debug] Setting debug level of dll to 1.
] [dll] sane_init: SANE dll backend version 1.0.13 from sane-backends 1.0.27
] [dll] add_backend: `hpaio' is already there
] [dll] load: dlopen() failed 
(/usr/lib/x86_64-linux-gnu/sane/libsane-hpaio.so.1: undefined symbol: _DBG)
] scanimage: open of device 
hpaio:/net/envy_5000_series?ip=192.168.178.41&queue=false failed: Invalid 
argument
=

A few other files in scan/sane/ include a header that defines the _DBG()
macro to call syslog(), but orblite.c doesn't.

What puzzles me is that the call is flagged as undefined in both build
logs (3.20.3+dfsg0-2 and 3.20.5+dfsg0-2) - however, in the old version
the call in the final shared library *has* been replaced by a call to
__syslog_chk(). (Don't want to figure out how that's happening.)

Anyway, resolving that _DBG() invocation in orblite.c should trivially
fix this bug.

Thanks for considering

Jan

Bug#960674: golang-go: "fatal error: gc_trigger underflow" on mipsel

[YunQiang Su]

Adrian Bunk  于2020年5月21日周四 上午4:44写道：
>
> On Tue, May 19, 2020 at 11:43:30AM +0800, Shengjing Zhu wrote:
> >
> > FTR, after giving back golang-1.14 mipsel several times, it's finally
> > built, by a longson builder.
> > So I guess it only occurs on octeon. Since the porterbox eller is also
> > octeon, it also can't build any go program.
>
> On eller golang-1.14 fails to build both in sid and buster chroots.
>
> golang-1.11 also fails to build in a buster chroot with floating point
> test errors.
>
> golang-1.14 gets unbroken by GOMIPS=softfloat.
>
> The only kernel configuration change on eller in the buster point
> release is CONFIG_MIPS_O32_FP64_SUPPORT=y, everything observed would
> make sense if the problem is that golang-1.11 and golang-1.14 are
> not compatible with CONFIG_MIPS_O32_FP64_SUPPORT.

It is just support O32_FP64. I don't expect it will have any effect.
Since currently, the toolchain/libraries are all FPXX.

>
> > Shengjing Zhu
>
> cu
> Adrian

Bug#961146: systemd-logind sometimes ignores a systemd-inhibit lock

[Vincent Lefevre]

The suspend also occurs if I switch to a VT.

So it seems that if a "block" was triggered, it is cancelled once
the login session that started it is no longer associated with the
screen (something like that).

This would explain the issue I had with light-locker / lightdm
(bug 961124), because this is exactly this case.

The systemd-inhibit(1) man page says:

  --mode=
  Takes either "block" or "delay" and describes how the lock is
  applied. If "block" is used (the default), the lock prohibits any
  of the requested operations without time limit, and only privileged
  users may override it. If "delay" is used, the lock can only delay
  the requested operations for a limited time. If the time elapses,
  the lock is ignored and the operation executed. The time limit may
  be specified in logind.conf(5). Note that "delay" is only available
  for "sleep" and "shutdown".

So "without time limit", and I can't see any override in my case.

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

Bug#961146: systemd-logind sometimes ignores a systemd-inhibit lock

[Vincent Lefevre]

And once again, after I logged out from the VT to log in as root.
And this time, no light-locker or lightdm running.

[...]
May 21 00:06:42 zira login[902]: pam_unix(login:session): session closed for us>
May 21 00:06:42 zira systemd[1]: getty@tty1.service: Succeeded.
May 21 00:06:42 zira systemd-logind[785]: Session 13 logged out. Waiting for pr>
May 21 00:06:42 zira systemd[1]: getty@tty1.service: Scheduled restart job, res>
May 21 00:06:42 zira systemd[1]: Stopped Getty on tty1.
May 21 00:06:42 zira systemd[1]: Started Getty on tty1.
May 21 00:06:44 zira login[107800]: pam_unix(login:auth): Couldn't open /etc/se>
May 21 00:06:48 zira inhibit-suspend[107804]: (vinc17) on-line: yes
May 21 00:06:48 zira inhibit-suspend[107809]: (vinc17) output: 0
May 21 00:06:48 zira login[107800]: pam_unix(login:auth): Couldn't open /etc/se>
May 21 00:06:48 zira login[107800]: pam_unix(login:session): session opened for>
May 21 00:06:48 zira systemd[1]: Created slice User Slice of UID 0.
May 21 00:06:48 zira systemd[1]: Starting User Runtime Directory /run/user/0...
May 21 00:06:48 zira systemd-logind[785]: New session 96 of user root.
May 21 00:06:48 zira systemd-logind[785]: Suspending...
May 21 00:06:48 zira systemd[1]: Reached target Sleep.
May 21 00:06:48 zira systemd[1]: Starting Suspend...
[...]

and after resuming, the systemd-inhibit lock was still there.

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

Bug#961176: django-taggit: Not compatible with Django 3.x

[Chris Lamb]

Source: django-taggit
Version: 0.24.0-2
Severity: normal
User: python-modules-t...@lists.alioth.debian.org
Usertags: django-3.x
Control: affects -1 python-django-modelcluster

Dear maintainer,

The version of Django experimental is currently 3.0.6-1. I have built
the 153 reverse-dependencies in unstable against this version and 114
of these build & pass their testsuite successfully. For more
information, see:

http://bugs.debian.org/960890

Please use the above bug report for queries or questions regarding
Django 3.x that are not specific to this particular package in order
to reduce duplicated work across all of the bugs.

Whilst django-taggit itself builds from source, it causes other
packages (eg. python-django-modelcluster) to FTBFS.

Here is the FTBFS from python-django-modelcluster.:

  […]

  runtests()
File "./runtests.py", line 15, in runtests
  execute_from_command_line(argv)
File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
line 401, in execute_from_command_line
  utility.execute()
File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
line 377, in execute
  django.setup()
File "/usr/lib/python3/dist-packages/django/__init__.py", line 24, in setup
  apps.populate(settings.INSTALLED_APPS)
File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 114, in 
populate
  app_config.import_models()
File "/usr/lib/python3/dist-packages/django/apps/config.py", line 211, in 
import_models
  self.models_module = import_module(models_module_name)
File "/usr/lib/python3.8/importlib/__init__.py", line 127, in import_module
  return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1014, in _gcd_import
File "", line 991, in _find_and_load
File "", line 975, in _find_and_load_unlocked
File "", line 671, in _load_unlocked
File "", line 783, in exec_module
File "", line 219, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/taggit/models.py", line 6, in 
  from django.utils.encoding import python_2_unicode_compatible
  ImportError: cannot import name 'python_2_unicode_compatible' from 
'django.utils.encoding' 
(/usr/lib/python3/dist-packages/django/utils/encoding.py)
  E: pybuild pybuild:352: test: plugin custom failed with: exit code=1: 
python3.8 ./runtests.py
  dh_auto_test: error: pybuild --test -i python{version} -p 3.8 --system=custom 
"--test-args={interpreter} ./runtests.py" returned exit code 13
  make[1]: *** [debian/rules:12: override_dh_auto_test] Error 25
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20200517002443.TfWa5BcsUg.ags.lamby-debian-experimental.python3-django-modelcluster/python-django-modelcluster-5.0.1'
  make: *** [debian/rules:9: binary] Error 2
  dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2

  […]

The full build log is attached.


Regards,

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

python-django-modelcluster.5.0.1-2.unstable.amd64.log.txt.gz
Description: Binary data

Bug#961175: django-haystack: Not compatible with Django 3.x

[Chris Lamb]

Source: django-haystack
Version: 2.8.1-3
Severity: normal
User: python-modules-t...@lists.alioth.debian.org
Usertags: django-3.x
Control: affects -1 celery-haystack hyperkitty

Dear maintainer,

The version of Django experimental is currently 3.0.6-1. I have built
the 153 reverse-dependencies in unstable against this version and 114
of these build & pass their testsuite successfully. For more
information, see:

http://bugs.debian.org/960890

Please use the above bug report for queries or questions regarding
Django 3.x that are not specific to this particular package in order
to reduce duplicated work across all of the bugs.

Whilst django-haystack itself builds from source, it causes other
packages (eg. celery-haystack and hyperkitty) to FTBFS.

Here is the FTBFS from celery-haystack:

  […]

  management.execute_from_command_line()
File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
line 401, in execute_from_command_line
  utility.execute()
File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
line 377, in execute
  django.setup()
File "/usr/lib/python3/dist-packages/django/__init__.py", line 24, in setup
  apps.populate(settings.INSTALLED_APPS)
File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 91, in 
populate
  app_config = AppConfig.create(entry)
File "/usr/lib/python3/dist-packages/django/apps/config.py", line 90, in 
create
  module = import_module(entry)
File "/usr/lib/python3.8/importlib/__init__.py", line 127, in import_module
  return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1014, in _gcd_import
File "", line 991, in _find_and_load
File "", line 975, in _find_and_load_unlocked
File "", line 671, in _load_unlocked
File "", line 783, in exec_module
File "", line 219, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/haystack/__init__.py", line 11, in 

  from haystack.utils import loading
File "/usr/lib/python3/dist-packages/haystack/utils/__init__.py", line 9, 
in 
  from django.utils import six
  ImportError: cannot import name 'six' from 'django.utils' 
(/usr/lib/python3/dist-packages/django/utils/__init__.py)
  E: pybuild pybuild:352: test: plugin custom failed with: exit code=1: 
PYTHONPATH=. HAYSTACK=v2 python3 /usr/bin/django-admin test 
--settings=celery_haystack.test_settings
  dh_auto_test: error: pybuild --test -i python{version} -p 3.8 returned exit 
code 13
  make[1]: *** [debian/rules:12: override_dh_auto_test] Error 25
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20200517000807.BbMTSL1dzK.ags.lamby-debian-experimental.python3-django-celery-haystack/celery-haystack-0.10'
  make: *** [debian/rules:9: build] Error 2
  dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

  […]

The full build log is attached.


Regards,

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

celery-haystack.0.10-4.unstable.amd64.log.txt.gz
Description: Binary data

Bug#961177: django-simple-captcha: Not compatible with Django 3.x

[Chris Lamb]

Source: django-simple-captcha
Version: 0.5.6-2
Severity: normal
User: python-modules-t...@lists.alioth.debian.org
Usertags: django-3.x
Control: affects -1 plinth

Dear maintainer,

The version of Django experimental is currently 3.0.6-1. I have built
the 153 reverse-dependencies in unstable against this version and 114
of these build & pass their testsuite successfully. For more
information, see:

http://bugs.debian.org/960890

Please use the above bug report for queries or questions regarding
Django 3.x that are not specific to this particular package in order
to reduce duplicated work across all of the bugs.

Whilst django-simple-captcha itself builds from source, it causes
other packages (eg. plinth) to FTBFS.

Here is the FTBFS from plinth:

  […]

  raise ex[1].with_traceback(ex[2])
File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 187, in 
_multicall
  res = hook_impl.function(*args)
File "/usr/lib/python3/dist-packages/pytest_django/plugin.py", line 335, in 
pytest_load_initial_conftests
  _setup_django()
File "/usr/lib/python3/dist-packages/pytest_django/plugin.py", line 223, in 
_setup_django
  django.setup()
File "/usr/lib/python3/dist-packages/django/__init__.py", line 24, in setup
  apps.populate(settings.INSTALLED_APPS)
File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 114, in 
populate
  app_config.import_models()
File "/usr/lib/python3/dist-packages/django/apps/config.py", line 211, in 
import_models
  self.models_module = import_module(models_module_name)
File "/usr/lib/python3.8/importlib/__init__.py", line 127, in import_module
  return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1014, in _gcd_import
File "", line 991, in _find_and_load
File "", line 975, in _find_and_load_unlocked
File "", line 671, in _load_unlocked
File "", line 783, in exec_module
File "", line 219, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/captcha/models.py", line 4, in 
  from django.utils.encoding import python_2_unicode_compatible
  ImportError: cannot import name 'python_2_unicode_compatible' from 
'django.utils.encoding' 
(/usr/lib/python3/dist-packages/django/utils/encoding.py)
  E: pybuild pybuild:352: test: plugin custom failed with: exit code=1: 
python3.8 setup.py test
  dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.8 
returned exit code 13
  make[1]: *** [debian/rules:15: override_dh_auto_test] Error 25
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20200516235112.uZ6Wnbr4DL.ags.lamby-debian-experimental.freedombox/plinth-20.8'
  make: *** [debian/rules:7: binary] Error 2
  dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2

  […]

The full build log is attached.


Regards,

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

plinth.20.8.unstable.amd64.log.txt.gz
Description: Binary data

Bug#284760: debian-installer-manual: netboot/debian-installer/i386/initrd.gz

[Holger Wansing]

Control: tags -1 + pending


Olaf van der Spek  wrote:
> http://d-i.alioth.debian.org/manual/en.i386/ch05s01.html#boot-initrd
> 
> > you should download the netboot/debian-installer/i386/initrd.gz file 
> 
> The manual doesn't tell where this file can be downloaded.
> I think a link is appropriate.

I just fixed that in git (changing the filename into a link; amongst some
more improvements).

Tagging this bug as pending


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#954089: libplack-perl: Please verify server identity via SSL

[Dominic Hargreaves]

Hello everyone, I just caught up with this. (Side note - please don't
assume I will see a message sent to a random pkg-perl bug report[1].)

On Sun, May 17, 2020 at 06:39:34PM +0300, Damyan Ivanov wrote:
> -=| gregor herrmann, 15.05.2020 21:14:35 +0200 |=-
> > On Thu, 19 Mar 2020 14:39:13 +0200, Damyan Ivanov wrote:
> > 
> > > > > But to fully measure the impact, it would be nice to have the number 
> > > > > of failing packages built with a patched HTTP::Tiny.
> > > > I have one small concern: As the change is about checking remote SSL
> > > > certs, and tests don't/can't/must not call out to the internet, is it
> > > > possible that we won't really catch all potential issues?
> > > Noted. The test rebuilds should be done without the usual isolation 
> > > from the Internet.
> > > I guess a closer inspection of the affected packages is needed.
> > 
> > Hi Dam and all,
> > 
> > did you or anyone else get to look into this rebuild effort?
> 
> I haven't. I am still at the stage of "(re-)invent an easy way to 
> rebuild a list of packages with a crafted chroot". I don't see this 
> changing soon, so please Dom, anybody, feel free to take the job.
> 
> > If not, Dom said that he could also try the rebuilds on
> > perl.debian.net.
> > 
> > Notes:
> > - HTTP::Tiny is in perl core and in libhttp-tiny-perl;
> > - The required change looks like a one-character-patch:
> >   lib/HTTP/Tiny.pm:verify_SSL   => $args{verify_SSL} || 
> > $args{verify_ssl} || 0, # no verification by default
> > - The tests should be run with internet enabled as much as possible.

I am happy to do this, but I want to add a large caution: I do not
think that a clean bill of health from rebuild testing by itself
will allow us to draw any meaningful conclusions. It'd tell us that 
the unit tests were correctly disabling SSL verification in their test
suites, or their test suites don't test SSL-related functionality, or
their test suites (inappropriately) rely on external servers with
correct SSL setups.

But what's much more important here, surely, is what effect such a
change will have on our users in the real world, who will be using
this module to talk to the internet, and not to mention their own
internal services. I don't really see a way to know the scale of
breakage this will cause without trying it and seeing how much noise
there is from our (unstable) users.

Note that this is not a reason to avoid making the change. I just want
to make sure we're going into this with our eyes open.

Cheers
Dominic

[1] Side note to the side note: ugh, is the BTS setting Reply-To
to strip out other correspondents? I have subscribed to this bug
on the BTS so I will hopefully receive all mail to it in my inbox.

Bug#960516:

[Yoon Khe]

Suggest closing due to the release of librime (1.5.3+dfsg1-6), which appears to 
fix this. In addition, this is a duplicate of #960474.

librime (1.5.3+dfsg1-6) changelog: 
https://metadata.ftp-master.debian.org/changelogs//main/libr/librime/librime_1.5.3+dfsg1-6_changelog,

Bug#960474:

[Yoon Khe]

Suggest closing due to the release of librime (1.5.3+dfsg1-6), which appears to 
fix this. Note: #960474 is a duplicate of this.

librime (1.5.3+dfsg1-6) changelog: 
https://metadata.ftp-master.debian.org/changelogs//main/libr/librime/librime_1.5.3+dfsg1-6_changelog,

Bug#961157: latexml: needs a dependency on libpod-parser-perl

[Hilmar Preuße]

Control: tags -1 + pending

Am 20.05.2020 um 22:20 teilte Niko Tyni mit:

Hi Niko,

Thanks for the report!

> Please consider adding a runtime dependency sooner rather than later,
> to help our testing efforts.
> 
Fixed in git, tag pending.

H.
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#961174: ITP: libmath-matrixreal-perl -- Manipulate NxN matrices of real numbers

[Étienne Mollier]

Package: wnpp
Owner: Etienne Mollier 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libmath-matrixreal-perl
  Version : 2.13
  Upstream Author : Jonathan Leto 
* URL : https://metacpan.org/release/Math-MatrixReal
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Manipulate NxN matrices of real numbers

It implements the data type "matrix of reals" (and consequently also "vector
of reals") which can be used almost like any other basic Perl type thanks to
operator overloading.

It features many important operations and methods: matrix norm, matrix
transposition, matrix inverse, determinant of a matrix, order and numerical
condition of a matrix, scalar product of vectors, vector product of vectors,
vector length, projection of row and column vectors, a comfortable way for
reading in a matrix from a file, the keyboard or your code, and many more.

It allows one to solve linear equation systems using an efficient algorithm
known as "L-R-decomposition" and several approximative (iterative) methods.

It features an implementation of Kleene's algorithm to compute the minimal
costs for all paths in a graph with weighted edges (the "weights" being the
costs associated with each edge).

Finally, it allows one to solve the eigensystem of a real symmetric matrix,
using Householder transformation and QL decomposition.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

This package is a dependency of libstatistics-pca-perl, which in
turn will become a dependency of prinseq-lite, to enable the
possibility of using the full prinseq-graphs.pl command without
having to skip PCA graphs.  The repository is available on
Salsa:


https://salsa.debian.org/perl-team/modules/packages/libmath-matrixreal-perl/

Kind Regards,
-- 
Étienne Mollier 
Fingerprint:  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
Help find cures against the Covid-19 !  Give CPU cycles:
  * Rosetta@home: https://boinc.bakerlab.org/rosetta/
  * Folding@home: https://foldingathome.org/

Bug#961060: qmail-verify: CVE-2020-3811 CVE-2020-3812

[Salvatore Bonaccorso]

Control: tags -1 + patch

On Tue, May 19, 2020 at 07:30:53PM +0200, Salvatore Bonaccorso wrote:
> Source: netqmail
> Version: 1.06-6.1
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> Control: found -1 1.06-6
> Control: found -1 1.06-5
> 
> Hi
> 
> See https://www.openwall.com/lists/oss-security/2020/05/19/8 for the
> Qualys advisory covering CVE-2020-3811 and CVE-2020-3812.

debdiff based on the above attached.

Salvatore
diff -u netqmail-1.06/debian/changelog netqmail-1.06/debian/changelog
--- netqmail-1.06/debian/changelog
+++ netqmail-1.06/debian/changelog
@@ -1,3 +1,10 @@
+netqmail (1.06-6.2) unstable; urgency=high
+
+  * Address CVE-2005-1513, CVE-2005-1514, CVE-2005-1515, CVE-2020-3811 and
+CVE-2020-3812 (Closes: #961060)
+
+ -- Salvatore Bonaccorso   Wed, 20 May 2020 22:23:21 +0200
+
 netqmail (1.06-6.1) unstable; urgency=medium
 
   * Non-maintainer upload.
only in patch2:
unchanged:
--- netqmail-1.06.orig/debian/diff/0004-Remote-Code-Execution-in-qmail.diff
+++ netqmail-1.06/debian/diff/0004-Remote-Code-Execution-in-qmail.diff
@@ -0,0 +1,515 @@
+From e80dc4ad2b0ee51315e336253606c0effdd0f117 Mon Sep 17 00:00:00 2001
+From: Qualys Security Advisory 
+Date: Tue, 19 May 2020 10:05:06 -0700
+Subject: [PATCH] Remote Code Execution in qmail (CVE-2005-1513)
+
+Qualys Security Advisory
+
+15 years later: Remote Code Execution in qmail (CVE-2005-1513)
+
+
+Contents
+
+
+Summary
+Analysis
+Exploitation
+qmail-verify
+- CVE-2020-3811
+- CVE-2020-3812
+Mitigations
+Acknowledgments
+Patches
+
+
+Summary
+
+
+TLDR: In 2005, three vulnerabilities were discovered in qmail but were
+never fixed because they were believed to be unexploitable in a default
+installation. We recently re-discovered these vulnerabilities and were
+able to exploit one of them remotely in a default installation.
+
+
+
+In May 2005, Georgi Guninski published "64 bit qmail fun", three
+vulnerabilities in qmail (CVE-2005-1513, CVE-2005-1514, CVE-2005-1515):
+
+http://www.guninski.com/where_do_you_want_billg_to_go_today_4.html
+
+Surprisingly, we re-discovered these vulnerabilities during a recent
+qmail audit; they have never been fixed because, as stated by qmail's
+author Daniel J. Bernstein (in https://cr.yp.to/qmail/guarantee.html):
+
+"This claim is denied. Nobody gives gigabytes of memory to each
+qmail-smtpd process, so there is no problem with qmail's assumption
+that allocated array lengths fit comfortably into 32 bits."
+
+Indeed, the memory consumption of each qmail-smtpd process is severely
+limited by default (by qmail-smtpd's startup script); for example, on
+Debian 10 (the latest stable release), it is limited to roughly 7MB.
+
+Unfortunately, we discovered that these vulnerabilities also affect
+qmail-local, which is reachable remotely and is not memory-limited by
+default (we investigated many qmail packages, and *all* of them limit
+qmail-smtpd's memory, but *none* of them limits qmail-local's memory).
+
+As a proof of concept, we developed a reliable, local and remote exploit
+against Debian's qmail package in its default configuration. This proof
+of concept requires 4GB of disk space and 8GB of memory, and allows an
+attacker to execute arbitrary shell commands as any user, except root
+(and a few system users who do not own their home directory). We will
+publish our proof-of-concept exploit in the near future.
+
+About our new discovery, Daniel J. Bernstein issues the following
+statement:
+
+"https://cr.yp.to/qmail/guarantee.html has for many years mentioned
+qmail's assumption that allocated array lengths fit comfortably into
+32 bits. I run each qmail service under softlimit -m12345678, and I
+recommend the same for other installations."
+
+Finally, we also discovered two minor vulnerabilities in qmail-verify (a
+third-party qmail patch that is included in, for example, Debian's qmail
+package): CVE-2020-3811 (a mail-address verification bypass), and
+CVE-2020-3812 (a local information disclosure).
+
+
+Analysis
+
+
+We decided to exploit Georgi Guninski's vulnerability "1. integer
+overflow in stralloc_readyplus" (CVE-2005-1513). There are, in fact,
+four potential integer overflows in stralloc_readyplus; three in the
+GEN_ALLOC_readyplus() macro (which generates the stralloc_readyplus()
+function), at line 21 (n += x->len), line 23 (x->a = base + n + ...),
+and line 24 (x->a * sizeof(type)):
+
+--

Bug#961173: claws-mail: connection to imap.mail.yahoo.com failed

[TG]

Package: claws-mail  Version: 3.17.5-2  Issue: Unable to connect to Yahoo IMAP 
server  The error message is:   Error. Connection to imap.mail.yahoo.com 
failed: login refused.  The account with the same settings is working as 
expected in Thunderbird.   Settings:  imap.mail.yahoo.com Port 993  
Authentificatiom method: Authomatic   Network log:  ---  * Account 
' IMAP': Connecting to IMAP server: imap.mail.yahoo.com:993...  
[2020-05-20 23:41:23] IMAP< * OK [CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN 
AUTH=XOAUTH2 AUTH=OAUTHBEARER ID MOVE NAMESPACE XYMHIGHESTMODSEQ UIDPLUS 
LITERAL+ CHILDREN X-MSG-EXT OBJECTID] IMAP4rev1 Hello   * IMAP connection is 
un-authenticated  [2020-05-20 23:41:24] IMAP> 1 CAPABILITY   [2020-05-20 
23:41:24] IMAP< * CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN AUTH=XOAUTH2 
AUTH=OAUTHBEARER ID MOVE NAMESPACE XYMHIGHESTMODSEQ UIDPLUS LITERAL+ CHILDREN 
X-MSG-EXT OBJECTID   [2020-05-20 23:41:24] IMAP< 1 OK CAPABILITY completed   
[2020-05-20 23:41:24] IMAP> Logging   x...@yahoo.com  to 
imap.mail.yahoo.com using PLAIN  [2020-05-20 23:41:28] IMAP< AUTHENTICATE 
Invalid credentials  ** IMAP error on imap.mail.yahoo.com: LOGIN error  
[2020-05-20 23:41:28] IMAP< Error logging in to imap.mail.yahoo.com  
[2020-05-20 23:41:28] IMAP> Logging   x...@yahoo.com  to 
imap.mail.yahoo.com using plaintext  [2020-05-20 23:41:32] IMAP< LOGIN 
Invalid credentials  ** IMAP error on imap.mail.yahoo.com: LOGIN error  ---  -- 
System Information:  Debian Release: bullseye/sid    APT prefers testing    APT 
policy: (500, 'testing'), (500, 'oldstable')  Architecture: 
amd64 (x86_64)  Foreign Architectures: i386   Kernel: Linux 4.19.0-5-amd64 (SMP 
w/4 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.UTF-8 (charmap=UTF-8)  Shell: /bin/sh linked to 
/bin/dash  Init: systemd (via /run/systemd/system)  LSM: AppArmor: enabled   
Versions of packages claws-mail depends on:  ii  libc6� 2.30-8  ii  
libcairo2  � 1.16.0-4  ii  libcompfaceg1    1:1.5.2-5+b2  ii  
libenchant-2-2   2.2.8-1  ii  libetpan20   1.9.4-2  ii  
libgdk-pixbuf2.0-0   2.40.0+dfsg-4  ii  libglib2.0-0 2.64.2-1  ii  
libgnutls30  3.6.13-2  ii  libgtk2.0-0  2.24.32-4  ii  libice6  
 � 2:1.0.9-2  ii  libldap-2.4-2    2.4.50+dfsg-1  ii  libnettle7
   3.5.1+really3.5.1-2  ii  libpango-1.0-0   1.44.7-4  ii  
libpangocairo-1.0-0  1.44.7-4  ii  librsvg2-2   2.48.4+dfsg-1  ii  
libsm6 2:1.2.3-1  ii  xdg-utils  � 1.1.3-2   Versions of 
packages claws-mail recommends:  ii  aspell-en [aspell-dictionary]  
2018.04.16-0-1  ii  aspell-eu [aspell-dictionary]  0.5.20151110-5  ii  
aspell-pl [aspell-dictionary]  20150428-3  ii  aspell-ru [aspell-dictionary]  
0.99g5-23  ii  aspell-uk [aspell-dictionary]  1.7.1-2  ii  claws-mail-i18n  
 � 3.17.5-2  ii  xfonts-100dpi� 1:1.0.4+nmu1  ii  xfonts-75dpi  
1:1.0.4+nmu1   Versions of packages claws-mail suggests:  pn  claws-mail-doc
   pn  claws-mail-tools      ii  firefox-esr 
[www-browser]  68.8.0esr-1  ii  gedit� 3.36.2-1

Bug#961172: Please enable autopkgtests

[Nicholas D Steeves]

Source: evil-el
Version: 1.12.17-1
Severity: normal

Hi David,

Autopkgtests are highly recommended by Policy, and various processes
such as migration to testing and bullseye's freeze policy are increasingly 
encouraging their use.

I'm filing this bug as a reminder, and also because I suspect there is
missing documentation about how to enable this for an existing
dh-elpa-using package.

Cheers,
Nicholas

Bug#960892: closed by Debian FTP Masters (reply to to...@debian.org (Dr. Tobias Quathamer)) (Bug#960892: fixed in po4a 0.59-1)

[Axel Beckert]

Control: reopen -1
Control: notfixed -1 0.59-1

Hi,

Debian Bug Tracking System wrote:
>  - po4a tool: Fix --srcdir handling. This bug was breaking the build
>of several packages, including dpkg. (Closes: #960892)

I'm sorry to report, but this is not fixed for aptitude.

> previously when building aptitude's documentation, it sufficed to
> declare
> 
>   [po_directory] po4a/po
> 
> in doc/po4a/po4a.cfg and then calling from the out-of-tree build
> directory in e.g. "build/doc/de/"
> 
>   /usr/bin/po4a --translate-only=de/manpage.xml --srcdir=../../../doc 
> --destdir=../../doc ../../../doc/po4a/po4a.cfg
> 
> but since recently, this fails with the IMHO not very helpful error
> message:
> 
>   ../../../doc/po4a/po4a.cfg:1: no PO files found in po4a/po

The error now looks slightly different, though:

  ../../../doc/po4a/po4a.cfg:1: no PO files found in ../../doc/po4a/po


So for me it looks as this "../../doc/po4a/po" is now prefixed with
what I gave as --destdir, but it should have been what I gave as
--srcdir.

Here's the requested run with more verbose settings:

[…]ptitude/build/doc/de → /usr/bin/po4a -d -v --translate-only=de/manpage.xml 
--srcdir=../../../doc --destdir=../../doc ../../../doc/po4a/po4a.cfg
cmd=[po_directory]; po4a/po /
../../../doc/po4a/po4a.cfg:1: no PO files found in ../../doc/po4a/po
cmd=[po4a_alias:docbook]; docbook / opt:"-M utf-8 -o 
untranslated="
cmd=[po4a_alias:svg]; xml / opt:"-M utf-8 -k 0"
cmd=[type: docbook]; en/aptitude.xml / $lang:$lang/aptitude.xml opt:"-k 0"
cmd=[type: docbook]; en/manpage.xml / $lang:$lang/manpage.xml opt:"-k 0"
cmd=[type: svg]; en/images/safety-cost-level-diagram.svg / 
$lang:$lang/images/safety-cost-level-diagram.svg
'po4a_paths' is not defined in the configuration file. Where are the POT and PO 
files?

HTH!

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

Bug#961171: djangorestframework: FTBFS with Django 3.x

[Chris Lamb]

Source: djangorestframework
Version: 3.10.2-1
Severity: normal
User: python-modules-t...@lists.alioth.debian.org
Usertags: django-3.x

Dear maintainer,

The version of Django experimental is currently 3.0.6-1. I have built
the 153 reverse-dependencies in unstable against this version and 114
of these build & pass their testsuite successfully. Unfortunately,
djangorestframework fails to build. Please see:

http://bugs.debian.org/960890

... for more information. Please use this bug report for queries
or questions regarding Django 3.x that are not specific to this
particular package in order to reduce duplicated work across all of
the bugs.

  […]
  === short test summary info 

  FAILED 
tests/test_relations.py::TestHyperlinkedRelatedField::test_hyperlinked_related_lookup_does_not_exist
  FAILED 
tests/test_relations.py::TestHyperlinkedRelatedField::test_hyperlinked_related_lookup_exists
  FAILED 
tests/test_relations.py::TestHyperlinkedRelatedField::test_hyperlinked_related_lookup_url_encoded_exists
  FAILED 
tests/test_relations.py::TestHyperlinkedRelatedField::test_hyperlinked_related_queryset_type_error
  FAILED 
tests/test_relations.py::TestHyperlinkedRelatedField::test_hyperlinked_related_queryset_value_error
  = 5 failed, 1325 passed,  warnings in 7.46 seconds 
=
  E: pybuild pybuild:352: test: plugin custom failed with: exit code=1: 
python3.8 
/home/lamby/temp/cdt.20200517003318.3S5eajbRWG.ags.lamby-debian-experimental.python3-djangorestframework/djangorestframework-3.10.2/runtests.py
 --nolint
  dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.8 
returned exit code 13
  make[1]: *** [debian/rules:43: override_dh_auto_test] Error 25
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20200517003318.3S5eajbRWG.ags.lamby-debian-experimental.python3-djangorestframework/djangorestframework-3.10.2'
  make: *** [debian/rules:8: build] Error 2
  dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

  […]

The full build log is attached.


Regards,

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


djangorestframework.3.10.2-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#960594: systemd: services (bind9, squid) are started before their filesystems had been mounted

[Michael Biebl]

Am 19.05.20 um 18:38 schrieb Michael Biebl:

> Could you restore the original (i.e. undo all the changes I asked you to
> do) and copy the attached file to /lib/lsb/init-functions.d/40-systemd
> 
> Please report back if that fixes your problem (and/or if you encountered
> new problems)

Did you have a chance to test with the updated lsb init-functions script?




signature.asc
Description: OpenPGP digital signature

Bug#961170: python-django-tagging: FTBFS with Django 3.x

[Chris Lamb]

Source: python-django-tagging
Version: 1:0.4.5-3
Severity: normal
User: python-modules-t...@lists.alioth.debian.org
Usertags: django-3.x

Dear maintainer,

The version of Django experimental is currently 3.0.6-1. I have built
the 153 reverse-dependencies in unstable against this version and 114
of these build & pass their testsuite successfully. Unfortunately,
python-django-tagging fails to build. Please see:

http://bugs.debian.org/960890

... for more information. Please use this bug report for queries
or questions regarding Django 3.x that are not specific to this
particular package in order to reduce duplicated work across all of
the bugs.

  […]

  done
  ——— Running tests with python3.8 ———
  Traceback (most recent call last):
File "/usr/bin/django-admin", line 5, in 
  management.execute_from_command_line()
File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
line 401, in execute_from_command_line
  utility.execute()
File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
line 377, in execute
  django.setup()
File "/usr/lib/python3/dist-packages/django/__init__.py", line 24, in setup
  apps.populate(settings.INSTALLED_APPS)
File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 114, in 
populate
  app_config.import_models()
File "/usr/lib/python3/dist-packages/django/apps/config.py", line 211, in 
import_models
  self.models_module = import_module(models_module_name)
File "/usr/lib/python3.8/importlib/__init__.py", line 127, in import_module
  return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1014, in _gcd_import
File "", line 991, in _find_and_load
File "", line 975, in _find_and_load_unlocked
File "", line 671, in _load_unlocked
File "", line 783, in exec_module
File "", line 219, in _call_with_frames_removed
File 
"/home/lamby/temp/cdt.20200517004013.fXft1ZZRIE.ags.lamby-debian-experimental.python3-django-tagging/python-django-tagging-0.4.5/tagging/models.py",
 line 7, in 
  from django.utils.encoding import python_2_unicode_compatible
  ImportError: cannot import name 'python_2_unicode_compatible' from 
'django.utils.encoding' 
(/usr/lib/python3/dist-packages/django/utils/encoding.py)
  make[1]: *** [debian/rules:11: override_dh_auto_test] Error 1
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20200517004013.fXft1ZZRIE.ags.lamby-debian-experimental.python3-django-tagging/python-django-tagging-0.4.5'
  make: *** [debian/rules:6: build] Error 2
  dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

  […]

The full build log is attached.


Regards,

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


python-django-tagging.1:0.4.5-3.unstable.amd64.log.txt.gz
Description: Binary data

Bug#961169: python-django-navtag: FTBFS with Django 3.x

[Chris Lamb]

Source: python-django-navtag
Version: 2.1.3-2
Severity: normal
User: python-modules-t...@lists.alioth.debian.org
Usertags: django-3.x

Dear maintainer,

The version of Django experimental is currently 3.0.6-1. I have built
the 153 reverse-dependencies in unstable against this version and 114
of these build & pass their testsuite successfully. Unfortunately,
python-django-navtag fails to build. Please see:

http://bugs.debian.org/960890

... for more information. Please use this bug report for queries
or questions regarding Django 3.x that are not specific to this
particular package in order to reduce duplicated work across all of
the bugs.

  […]

  dh_auto_test -- --system=custom --test-args="{interpreter} 
/usr/bin/django-admin test django_navtag.tests"
  I: pybuild base:217: python3.8 /usr/bin/django-admin test django_navtag.tests
  E
  ==
  ERROR: django_navtag.tests.test_navtag (unittest.loader._FailedTest)
  --
  ImportError: Failed to import test module: django_navtag.tests.test_navtag
  Traceback (most recent call last):
File "/usr/lib/python3.8/unittest/loader.py", line 436, in _find_test_path
  module = self._get_module_from_name(name)
File "/usr/lib/python3.8/unittest/loader.py", line 377, in 
_get_module_from_name
  __import__(name)
File 
"/home/lamby/temp/cdt.20200517002556.DquEm9jhp8.ags.lamby-debian-experimental.python3-django-navtag/python-django-navtag-2.1.3/django_navtag/tests/test_navtag.py",
 line 5, in 
  from django_navtag.templatetags.navtag import NavNode
File 
"/home/lamby/temp/cdt.20200517002556.DquEm9jhp8.ags.lamby-debian-experimental.python3-django-navtag/python-django-navtag-2.1.3/django_navtag/templatetags/navtag.py",
 line 2, in 
  from django.utils import six, safestring
  ImportError: cannot import name 'six' from 'django.utils' 
(/usr/lib/python3/dist-packages/django/utils/__init__.py)
  
  
  --
  Ran 1 test in 0.000s
  
  FAILED (errors=1)
  System check identified no issues (0 silenced).
  E: pybuild pybuild:352: test: plugin custom failed with: exit code=1: 
python3.8 /usr/bin/django-admin test django_navtag.tests
  dh_auto_test: error: pybuild --test -i python{version} -p 3.8 --system=custom 
"--test-args={interpreter} /usr/bin/django-admin test django_navtag.tests" 
returned exit code 13
  make[1]: *** [debian/rules:12: override_dh_auto_test] Error 25
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20200517002556.DquEm9jhp8.ags.lamby-debian-experimental.python3-django-navtag/python-django-navtag-2.1.3'
  make: *** [debian/rules:9: build] Error 2
  dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

  […]

The full build log is attached.


Regards,

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


python-django-navtag.2.1.3-2.unstable.amd64.log.txt.gz
Description: Binary data

Bug#961166: python-django-extensions: FTBFS with Django 3.x

[Chris Lamb]

Source: python-django-extensions
Version: 2.2.1-1
Severity: normal
User: python-modules-t...@lists.alioth.debian.org
Usertags: django-3.x

Dear maintainer,

The version of Django experimental is currently 3.0.6-1. I have built
the 153 reverse-dependencies in unstable against this version and 114
of these build & pass their testsuite successfully. Unfortunately,
python-django-extensions fails to build. Please see:

http://bugs.debian.org/960890

... for more information. Please use this bug report for queries
or questions regarding Django 3.x that are not specific to this
particular package in order to reduce duplicated work across all of
the bugs.

  […]

  django.setup()
File "/usr/lib/python3/dist-packages/django/__init__.py", line 24, in setup
  apps.populate(settings.INSTALLED_APPS)
File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 122, in 
populate
  app_config.ready()
File "/usr/lib/python3/dist-packages/django/contrib/admin/apps.py", line 
24, in ready
  self.module.autodiscover()
File "/usr/lib/python3/dist-packages/django/contrib/admin/__init__.py", 
line 26, in autodiscover
  autodiscover_modules('admin', register_to=site)
File "/usr/lib/python3/dist-packages/django/utils/module_loading.py", line 
47, in autodiscover_modules
  import_module('%s.%s' % (app_config.name, module_to_search))
File "/usr/lib/python3.8/importlib/__init__.py", line 127, in import_module
  return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1014, in _gcd_import
File "", line 991, in _find_and_load
File "", line 975, in _find_and_load_unlocked
File "", line 671, in _load_unlocked
File "", line 783, in exec_module
File "", line 219, in _call_with_frames_removed
File 
"/home/lamby/temp/cdt.20200517001318.QUh0NKOOtV.ags.lamby-debian-experimental.python3-django-extensions/python-django-extensions-2.2.1/django_extensions/admin/__init__.py",
 line 21, in 
  from django_extensions.admin.widgets import ForeignKeySearchInput
File 
"/home/lamby/temp/cdt.20200517001318.QUh0NKOOtV.ags.lamby-debian-experimental.python3-django-extensions/python-django-extensions-2.2.1/django_extensions/admin/widgets.py",
 line 7, in 
  from django.contrib.admin.templatetags.admin_static import static
  ModuleNotFoundError: No module named 
'django.contrib.admin.templatetags.admin_static'
  E: pybuild pybuild:352: test: plugin custom failed with: exit code=1: 
python3.8 -m pytest --ds=tests.testapp.settings --cov=django_extensions 
django_extensions
  dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.8 
--system=custom "--test-args={interpreter} -m pytest 
--ds=tests.testapp.settings --cov=django_extensions django_extensions" returned 
exit code 13
  make[1]: *** [debian/rules:12: override_dh_auto_test] Error 25
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20200517001318.QUh0NKOOtV.ags.lamby-debian-experimental.python3-django-extensions/python-django-extensions-2.2.1'
  make: *** [debian/rules:6: build] Error 2
  dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

  […]

The full build log is attached.


Regards,

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


python-django-extensions.2.2.1-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#961168: python-django-mptt: FTBFS with Django 3.x

[Chris Lamb]

Source: python-django-mptt
Version: 0.10.0-1
Severity: normal
User: python-modules-t...@lists.alioth.debian.org
Usertags: django-3.x

Dear maintainer,

The version of Django experimental is currently 3.0.6-1. I have built
the 153 reverse-dependencies in unstable against this version and 114
of these build & pass their testsuite successfully. Unfortunately,
python-django-mptt fails to build. Please see:

http://bugs.debian.org/960890

... for more information. Please use this bug report for queries
or questions regarding Django 3.x that are not specific to this
particular package in order to reduce duplicated work across all of
the bugs.

  […]

  **
  File 
"/home/lamby/temp/cdt.20200517002530.a3OpEH3j9P.ags.lamby-debian-experimental.python3-django-mptt/python-django-mptt-0.10.0/tests/myapp/doctests.txt",
 line 1139, in doctests.txt
  Failed example:
  print_tree_details(OrderedInsertion.objects.all())
  Expected:
  6 - 1 0 1 6
  5 6 1 1 2 3
  4 6 1 1 4 5
  2 - 2 0 1 2
  3 - 3 0 1 4
  1 3 3 1 2 3
  Got:
  2 - 1 0 1 2
  3 - 2 0 1 6
  4 6 2 1 2 3
  5 6 2 1 4 5
  6 - 3 0 1 2
  1 3 3 0 3 4
  **
  1 items had failures:
 4 of 547 in doctests.txt
  ***Test Failed*** 4 failures.
  
  E: pybuild pybuild:352: test: plugin custom failed with: exit code=1: 
python3.8 /usr/bin/django-admin test --settings=settings --verbosity 2 
--traceback myapp
  dh_auto_test: error: pybuild --test -i python{version} -p 3.8 --system=custom 
"--test-args={interpreter} /usr/bin/django-admin test --settings=settings 
--verbosity 2 --traceback myapp" returned exit code 13
  make[1]: *** [debian/rules:13: override_dh_auto_test] Error 25
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20200517002530.a3OpEH3j9P.ags.lamby-debian-experimental.python3-django-mptt/python-django-mptt-0.10.0'
  make: *** [debian/rules:6: build] Error 2
  dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

  […]

The full build log is attached.


Regards,

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


python-django-mptt.0.10.0-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#961167: python-django-imagekit: FTBFS with Django 3.x

[Chris Lamb]

Source: python-django-imagekit
Version: 4.0.2-3
Severity: normal
User: python-modules-t...@lists.alioth.debian.org
Usertags: django-3.x

Dear maintainer,

The version of Django experimental is currently 3.0.6-1. I have built
the 153 reverse-dependencies in unstable against this version and 114
of these build & pass their testsuite successfully. Unfortunately,
python-django-imagekit fails to build. Please see:

http://bugs.debian.org/960890

... for more information. Please use this bug report for queries
or questions regarding Django 3.x that are not specific to this
particular package in order to reduce duplicated work across all of
the bugs.

  […]

File "/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py", 
line 1390, in execute_sql
  for sql, params in self.as_sql():
File "/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py", 
line 1333, in as_sql
  value_rows = [
File "/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py", 
line 1334, in 
  [self.prepare_value(field, self.pre_save_val(field, obj)) for field in 
fields]
File "/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py", 
line 1334, in 
  [self.prepare_value(field, self.pre_save_val(field, obj)) for field in 
fields]
File "/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py", 
line 1285, in pre_save_val
  return field.pre_save(obj, add=True)
File "/usr/lib/python3/dist-packages/django/db/models/fields/files.py", 
line 288, in pre_save
  file.save(file.name, file.file, save=False)
File "/usr/lib/python3/dist-packages/django/db/models/fields/files.py", 
line 87, in save
  self.name = self.storage.save(name, content, 
max_length=self.field.max_length)
File "/usr/lib/python3/dist-packages/django/core/files/storage.py", line 
51, in save
  name = self.get_available_name(name, max_length=max_length)
File "/usr/lib/python3/dist-packages/django/core/files/storage.py", line 
93, in get_available_name
  raise SuspiciousFileOperation(
  django.core.exceptions.SuspiciousFileOperation: Storage can not find an 
available filename for 
"/home/lamby/temp/cdt.20200517002106.mF5dDFrQ5J.ags.lamby-debian-experimental.python3-django-imagekit/python-django-imagekit-4.0.2/tests/media/reference_ejJn4Ty.png".
 Please make sure that the corresponding file field allows sufficient 
"max_length".
  
  --
  Ran 37 tests in 0.232s
  
  FAILED (errors=2)
  Destroying test database for alias 'default'...
  nosetests tests -s --cover-tests --cover-html --cover-package=imagekit 
--cover-html-dir=/home/lamby/temp/cdt.20200517002106.mF5dDFrQ5J.ags.lamby-debian-experimental.python3-django-imagekit/python-django-imagekit-4.0.2/tests/cover
 --verbosity=1
  E: pybuild pybuild:352: test: plugin distutils failed with: exit code=2: 
python3.8 setup.py test 
  dh_auto_test: error: pybuild --test -i python{version} -p 3.8 returned exit 
code 13
  make: *** [debian/rules:9: binary] Error 25
  dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2

  […]

The full build log is attached.


Regards,

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


python-django-imagekit.4.0.2-3.unstable.amd64.log.txt.gz
Description: Binary data

Bug#961165: libthumbor: FTBFS with Django 3.x

[Chris Lamb]

Source: libthumbor
Version: 1.3.3-2
Severity: normal
User: python-modules-t...@lists.alioth.debian.org
Usertags: django-3.x

Dear maintainer,

The version of Django experimental is currently 3.0.6-1. I have built
the 153 reverse-dependencies in unstable against this version and 114
of these build & pass their testsuite successfully. Unfortunately,
libthumbor fails to build. Please see:

http://bugs.debian.org/960890

... for more information. Please use this bug report for queries
or questions regarding Django 3.x that are not specific to this
particular package in order to reduce duplicated work across all of
the bugs.

  […]

  pieces.append(str(getattr(self, piece)()))
File "/usr/lib/python3/dist-packages/django/utils/dateformat.py", line 287, 
in r
  return self.format('D, j M Y H:i:s O')
File "/usr/lib/python3/dist-packages/django/utils/dateformat.py", line 38, 
in format
  pieces.append(str(getattr(self, piece)()))
File "/usr/lib/python3/dist-packages/django/utils/functional.py", line 124, 
in __text_cast
  return func(*self.__args, **self.__kw)
File "/usr/lib/python3/dist-packages/django/utils/translation/__init__.py", 
line 92, in gettext
  return _trans.gettext(message)
File 
"/usr/lib/python3/dist-packages/django/utils/translation/trans_real.py", line 
354, in gettext
  _default = _default or translation(settings.LANGUAGE_CODE)
File 
"/usr/lib/python3/dist-packages/django/utils/translation/trans_real.py", line 
267, in translation
  _translations[language] = DjangoTranslation(language)
File 
"/usr/lib/python3/dist-packages/django/utils/translation/trans_real.py", line 
154, in __init__
  self._add_installed_apps_translations()
File 
"/usr/lib/python3/dist-packages/django/utils/translation/trans_real.py", line 
195, in _add_installed_apps_translations
  raise AppRegistryNotReady(
  django.core.exceptions.AppRegistryNotReady: The translation infrastructure 
cannot be initialized before the apps registry is ready. Check that you don't 
make non-lazy gettext calls at import time.
   >> begin captured logging << 
  django.db.backends: DEBUG: (0.000) SAVEPOINT "s139755412752192_x10"; args=None
  - >> end captured logging << -
  
  --
  Ran 79 tests in 0.283s
  
  FAILED (errors=10)
  E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1: cd 
/home/lamby/temp/cdt.20200517004702.Bpm1EcYkwZ.ags.lamby-debian-experimental.python3-libthumbor/libthumbor-1.3.3/.pybuild/cpython3_3.8_libthumbor/build;
 python3.8 -m nose -v tests
  dh_auto_test: error: pybuild --test -i python{version} -p 3.8 returned exit 
code 13
  make: *** [debian/rules:6: build] Error 25
  dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

  […]

The full build log is attached.


Regards,

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


libthumbor.1.3.3-2.unstable.amd64.log.txt.gz
Description: Binary data

Bug#961164: django-oauth-toolkit: FTBFS with Django 3.x

[Chris Lamb]

Source: django-oauth-toolkit
Version: 1.3.2-1
Severity: normal
User: python-modules-t...@lists.alioth.debian.org
Usertags: django-3.x

Dear maintainer,

The version of Django experimental is currently 3.0.6-1. I have built
the 153 reverse-dependencies in unstable against this version and 114
of these build & pass their testsuite successfully. Unfortunately,
django-oauth-toolkit fails to build. Please see:

http://bugs.debian.org/960890

... for more information. Please use this bug report for queries
or questions regarding Django 3.x that are not specific to this
particular package in order to reduce duplicated work across all of
the bugs.

  […]

  File "/usr/lib/python3/dist-packages/django/template/defaulttags.py", line 
1023, in find_libraryraise 
TemplateSyntaxError(django.template.exceptions.TemplateSyntaxError: 
'staticfiles' is not a registered tag library. Must be one of:
admin_list
admin_modify
admin_urls
cache
i18n
l10n
log
static
tz

  […]

The full build log is attached.


Regards,

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


django-oauth-toolkit.1.3.2-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#960674: golang-go: "fatal error: gc_trigger underflow" on mipsel

[Adrian Bunk]

On Tue, May 19, 2020 at 11:43:30AM +0800, Shengjing Zhu wrote:
> 
> FTR, after giving back golang-1.14 mipsel several times, it's finally
> built, by a longson builder.
> So I guess it only occurs on octeon. Since the porterbox eller is also
> octeon, it also can't build any go program.

On eller golang-1.14 fails to build both in sid and buster chroots.

golang-1.11 also fails to build in a buster chroot with floating point
test errors.

golang-1.14 gets unbroken by GOMIPS=softfloat.

The only kernel configuration change on eller in the buster point 
release is CONFIG_MIPS_O32_FP64_SUPPORT=y, everything observed would
make sense if the problem is that golang-1.11 and golang-1.14 are
not compatible with CONFIG_MIPS_O32_FP64_SUPPORT.

> Shengjing Zhu

cu
Adrian

Bug#961163: django-modeltranslation: FTBFS with Django 3.x

[Chris Lamb]

Source: django-modeltranslation
Version: 0.13.3-0.1
Severity: normal
User: python-modules-t...@lists.alioth.debian.org
Usertags: django-3.x

Dear maintainer,

The version of Django experimental is currently 3.0.6-1. I have built
the 153 reverse-dependencies in unstable against this version and 114
of these build & pass their testsuite successfully. Unfortunately,
django-modeltranslation fails to build. Please see:

http://bugs.debian.org/960890

... for more information. Please use this bug report for queries
or questions regarding Django 3.x that are not specific to this
particular package in order to reduce duplicated work across all of
the bugs.

  […]

 debian/rules override_dh_auto_test
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20200517002452.CQB2y6IUfr.ags.lamby-debian-experimental.python3-django-modeltranslation/django-modeltranslation-0.13.3'
  PYBUILD_SYSTEM=custom \
PYBUILD_TEST_ARGS="{interpreter} ./runtests.py" \
dh_auto_test
  I: pybuild base:217: python3.8 ./runtests.py
  Traceback (most recent call last):
File "./runtests.py", line 62, in 
  runtests(*args)
File "./runtests.py", line 50, in runtests
  django.setup()
File "/usr/lib/python3/dist-packages/django/__init__.py", line 24, in setup
  apps.populate(settings.INSTALLED_APPS)
File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 122, in 
populate
  app_config.ready()
File 
"/home/lamby/temp/cdt.20200517002452.CQB2y6IUfr.ags.lamby-debian-experimental.python3-django-modeltranslation/django-modeltranslation-0.13.3/modeltranslation/apps.py",
 line 11, in ready
  handle_translation_registrations()
File 
"/home/lamby/temp/cdt.20200517002452.CQB2y6IUfr.ags.lamby-debian-experimental.python3-django-modeltranslation/django-modeltranslation-0.13.3/modeltranslation/models.py",
 line 75, in handle_translation_registrations
  autodiscover()
File 
"/home/lamby/temp/cdt.20200517002452.CQB2y6IUfr.ags.lamby-debian-experimental.python3-django-modeltranslation/django-modeltranslation-0.13.3/modeltranslation/models.py",
 line 14, in autodiscover
  from modeltranslation.translator import translator
File 
"/home/lamby/temp/cdt.20200517002452.CQB2y6IUfr.ags.lamby-debian-experimental.python3-django-modeltranslation/django-modeltranslation-0.13.3/modeltranslation/translator.py",
 line 5, in 
  from django.utils.six import with_metaclass
  ModuleNotFoundError: No module named 'django.utils.six'
  E: pybuild pybuild:352: test: plugin custom failed with: exit code=1: 
python3.8 ./runtests.py
  dh_auto_test: error: pybuild --test -i python{version} -p 3.8 returned exit 
code 13
  make[1]: *** [debian/rules:13: override_dh_auto_test] Error 25
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20200517002452.CQB2y6IUfr.ags.lamby-debian-experimental.python3-django-modeltranslation/django-modeltranslation-0.13.3'
  make: *** [debian/rules:6: build] Error 2
  dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

  […]

The full build log is attached.


Regards,

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


django-modeltranslation.0.13.3-0.1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#961162: django-fsm: FTBFS with Django 3.x

[Chris Lamb]

Source: django-fsm
Version: 2.6.1-2
Severity: normal
User: python-modules-t...@lists.alioth.debian.org
Usertags: django-3.x

Dear maintainer,

The version of Django experimental is currently 3.0.6-1. I have built
the 153 reverse-dependencies in unstable against this version and 114
of these build & pass their testsuite successfully. Unfortunately,
django-fsm fails to build. Please see:

http://bugs.debian.org/960890

... for more information. Please use this bug report for queries
or questions regarding Django 3.x that are not specific to this
particular package in order to reduce duplicated work across all of
the bugs.

  […]

  Traceback (most recent call last):
File "tests/manage.py", line 14, in 
  execute_from_command_line(sys.argv)
File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
line 401, in execute_from_command_line
  utility.execute()
File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
line 377, in execute
  django.setup()
File "/usr/lib/python3/dist-packages/django/__init__.py", line 24, in setup
  apps.populate(settings.INSTALLED_APPS)
File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 91, in 
populate
  app_config = AppConfig.create(entry)
File "/usr/lib/python3/dist-packages/django/apps/config.py", line 90, in 
create
  module = import_module(entry)
File "/usr/lib/python3.8/importlib/__init__.py", line 127, in import_module
  return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1014, in _gcd_import
File "", line 991, in _find_and_load
File "", line 975, in _find_and_load_unlocked
File "", line 671, in _load_unlocked
File "", line 783, in exec_module
File "", line 219, in _call_with_frames_removed
File 
"/home/lamby/temp/cdt.20200517001623.iiYoFCQhhs.ags.lamby-debian-experimental.python3-django-fsm/django-fsm-2.6.1/django_fsm/__init__.py",
 line 11, in 
  from django.utils.functional import curry
  ImportError: cannot import name 'curry' from 'django.utils.functional' 
(/usr/lib/python3/dist-packages/django/utils/functional.py)
  E: pybuild pybuild:352: test: plugin custom failed with: exit code=1: 
python3.8 tests/manage.py
  dh_auto_test: error: pybuild --test -i python{version} -p 3.8 returned exit 
code 13
  make[1]: *** [debian/rules:13: override_dh_auto_test] Error 25
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20200517001623.iiYoFCQhhs.ags.lamby-debian-experimental.python3-django-fsm/django-fsm-2.6.1'
  make: *** [debian/rules:10: build] Error 2
  dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

  […]

The full build log is attached.


Regards,

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


django-fsm.2.6.1-2.unstable.amd64.log.txt.gz
Description: Binary data

Bug#961161: kio-perldoc: needs a dependency on libpod-parser-perl

[Niko Tyni]

Package: kio-perldoc
Version: 4:19.12.2-2
Severity: normal
User: debian-p...@lists.debian.org
Usertags: perl-5.32-transition

This package uses Pod::Parser, part of the Pod-Parser distribution which
will be removed from the Perl core in upcoming version 5.32.  It is
being packaged separately for Debian as libpod-parser-perl (#960790),
and affected packages need to declare appropriate dependencies on that.

As the perl core packages already Provide libpod-parser-perl, these
dependencies can be added at any time and do not need to wait for the
separate package to enter sid.

Please consider adding a runtime dependency sooner rather than later,
to help our testing efforts.

 /usr/share/kio_perldoc/pod2html.pl:use base qw{ Pod::Parser };

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

Bug#961160: django-model-utils: FTBFS with Django 3.x

[Chris Lamb]

Source: django-model-utils
Version: 3.1.1-2
Severity: normal
User: python-modules-t...@lists.alioth.debian.org
Usertags: django-3.x

Dear maintainer,

The version of Django experimental is currently 3.0.6-1. I have built
the 153 reverse-dependencies in unstable against this version and 114
of these build & pass their testsuite successfully. Unfortunately,
django-model-utils fails to build. Please see:

http://bugs.debian.org/960890

... for more information. Please use this bug report for queries
or questions regarding Django 3.x that are not specific to this
particular package in order to reduce duplicated work across all of
the bugs.

  […]

  res = hook_impl.function(*args)
File "/usr/lib/python3/dist-packages/pytest_django/plugin.py", line 335, in 
pytest_load_initial_conftests
  _setup_django()
File "/usr/lib/python3/dist-packages/pytest_django/plugin.py", line 223, in 
_setup_django
  django.setup()
File "/usr/lib/python3/dist-packages/django/__init__.py", line 24, in setup
  apps.populate(settings.INSTALLED_APPS)
File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 114, in 
populate
  app_config.import_models()
File "/usr/lib/python3/dist-packages/django/apps/config.py", line 211, in 
import_models
  self.models_module = import_module(models_module_name)
File "/usr/lib/python3.8/importlib/__init__.py", line 127, in import_module
  return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1014, in _gcd_import
File "", line 991, in _find_and_load
File "", line 975, in _find_and_load_unlocked
File "", line 671, in _load_unlocked
File "", line 783, in exec_module
File "", line 219, in _call_with_frames_removed
File 
"/home/lamby/temp/cdt.20200517002516.AVX64zAwRd.ags.lamby-debian-experimental.python3-django-model-utils/django-model-utils-3.1.1/model_utils/models.py",
 line 13, in 
  from model_utils.managers import QueryManager, SoftDeletableManager
File 
"/home/lamby/temp/cdt.20200517002516.AVX64zAwRd.ags.lamby-debian-experimental.python3-django-model-utils/django-model-utils-3.1.1/model_utils/managers.py",
 line 14, in 
  from django.utils.six import string_types
  ModuleNotFoundError: No module named 'django.utils.six'
  E: pybuild pybuild:352: test: plugin custom failed with: exit code=1: 
python3.8 -m pytest -k 'not deferred'
  dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.8 
--system=custom "--test-args={interpreter} -m pytest -k 'not deferred'" 
returned exit code 13
  make[1]: *** [debian/rules:12: override_dh_auto_test] Error 25
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20200517002516.AVX64zAwRd.ags.lamby-debian-experimental.python3-django-model-utils/django-model-utils-3.1.1'
  make: *** [debian/rules:7: build] Error 2
  dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

  […]

The full build log is attached.


Regards,

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


django-model-utils.3.1.1-2.unstable.amd64.log.txt.gz
Description: Binary data

Bug#961159: lib32{,x}gcc-s1: please provide lib{,x}32gcc1 (= 1:${binary:Version})

[Andreas Beckmann]

Package: lib32gcc-s1,libx32gcc-s1
Version: 10.1.0-2
Severity: important

With the transitional packages gone in 10.1.0-2, please add versioned
(epoched!) provides on the old names (as already done in libgcc-s1)
in order to keep old packages installable along the latest gcc.

Thanks

Andreas

Bug#961158: ITP: distlib -- Java library of statistical distribution functions

[Scott Kitterman]

On Wednesday, May 20, 2020 4:23:41 PM EDT Pierre Gruet wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Debian-med project 
> 
> * Package name: distlib
>   Version : 0.9.1
>   Upstream Author : Peter N. Steinmetz
> * URL : https://sourceforge.net/projects/statdistlib
> * License : GPL-2
>   Programming Lang: Java
>   Description : Java library of statistical distribution functions
> 
> This is a library written in Java, providing probability density function,
> cumulative distribution function, quantiles and random variate generation
> for several common statistical distributions.
> 
> This package will be taken care of in Debian-med team, where it is needed as
> a dependency of SnpEff.

"distlib" is a very generic name.  Could the package be named java-distlib or 
some other more specific term?

Scott K

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

Bug#961141: antimony: error while loading shared libraries: libboost_python36.so.1.67.0

[Patrick Davis Naylor Gonzalez]

Package: antimony
Version: 0.9.3-1+b1
Severity: normal

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

Hi! I think this approach to CAD modelling is very interesting.I
installed the program but then when I try to launch Antimony in the
terminal, the following message appears: "antimony: error while loading
shared libraries: libboost_python36.so.1.67.0: cannot open shared
object file: No such file or directory". An It does not launch or work.

--- System information. ---
Architecture: 
Kernel:   Linux 4.19.0-8-amd64

Debian Release: 10.4
  500 stable  security.debian.org 
  500 stable  packages.microsoft.com 
  500 stable  download.jitsi.org 
  500 stable  dl.google.com 
  500 stable  debian.redlibre.cl 
  100 buster-backports deb.debian.org 

--- Package information. ---
Depends (Version) | Installed
=-+-
python3:any   | 
libboost-python1.67.0 | 1.67.0-13+deb10u1
libc6   (>= 2.14) | 
libgcc1(>= 1:3.0) | 
libpng16-16  (>= 1.6.2-1) | 
libpython3.7   (>= 3.7.0) | 
libqt5concurrent5  (>= 5.0.2) | 
libqt5core5a  (>= 5.11.0~rc1) | 
libqt5gui5 (>= 5.8.0) | 
libqt5network5 (>= 5.0.2) | 
libqt5opengl5  (>= 5.0.2) | 
libqt5widgets5 (>= 5.3.0) | 
libstdc++6   (>= 5.2) | 
zlib1g   (>= 1:1.1.4) | 


Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#961158: ITP: distlib -- Java library of statistical distribution functions

[Pierre Gruet]

Package: wnpp
Severity: wishlist
Owner: Debian-med project 

* Package name: distlib
  Version : 0.9.1
  Upstream Author : Peter N. Steinmetz
* URL : https://sourceforge.net/projects/statdistlib
* License : GPL-2
  Programming Lang: Java
  Description : Java library of statistical distribution functions

This is a library written in Java, providing probability density function,
cumulative distribution function, quantiles and random variate generation
for several common statistical distributions.

This package will be taken care of in Debian-med team, where it is needed as a
dependency of SnpEff.

Bug#959138: nipy: resolve nipy autopkgtest failure due to numpy testing decorators

[Matthieu Clemenceau]

Source: nipy
Followup-For: Bug #959138
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu groovy ubuntu-patch

Dear Maintainer,

While working on numpy proposed-migration for groovy, I realize nipy
autopkgtest was failing. It appears that numpy changed the pass to the
module decorators from numpy.testing.decorators to
numpy.testing._private.decorators.

In Ubuntu, the attached patch was applied allowing nipy to pass autopkg
test and migrate from groovy-proposed to groovy.

The Changelog below was added to nipy-0.4.2-3ubuntu1
  * Resolved test failure due to numpy 1:1.18.4-1. (Closes: #959138)


Thanks for considering the patch.


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

Kernel: Linux 5.4.0-29-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Description: Fix Autopkgtest failure caused by the new numpy 1:1.18.4-1
Author: Matthieu Clemenceau 
Origin: vendor
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959138#5
Forwarded: yes
Last-Update: 2020-05-15
--- a/nipy/algorithms/clustering/tests/test_vmm.py
+++ b/nipy/algorithms/clustering/tests/test_vmm.py
@@ -13,7 +13,7 @@
 select_vmm_cv)
 
 from nose.tools import assert_true, assert_equal
-from numpy.testing import decorators
+from numpy.testing._private import decorators
 
 from nibabel.optpkg import optional_package
 
--- a/nipy/algorithms/diagnostics/tests/test_screen.py
+++ b/nipy/algorithms/diagnostics/tests/test_screen.py
@@ -23,7 +23,8 @@
 from nose.tools import (assert_true, assert_false, assert_equal, assert_raises)
 
 from numpy.testing import (assert_array_equal, assert_array_almost_equal,
-   assert_almost_equal, decorators)
+   assert_almost_equal)
+from numpy.testing._private import decorators
 
 from nipy.testing import funcfile
 from nipy.testing.decorators import needs_mpl_agg
--- a/nipy/fixes/numpy/testing/nosetester.py
+++ b/nipy/fixes/numpy/testing/nosetester.py
@@ -21,7 +21,7 @@
 
 Examples
 
->>> from numpy.testing import nosetester
+>>> from numpy.testing._private import nosetester
 >>> nosetester.get_package_name('nonsense')
 'numpy'
 
--- a/nipy/testing/decorators.py
+++ b/nipy/testing/decorators.py
@@ -8,7 +8,7 @@
 from __future__ import print_function
 from __future__ import absolute_import
 
-from numpy.testing.decorators import *
+from numpy.testing._private.decorators import *
 
 from nipy.utils import templates, example_data, DataError
 
--- a/nipy/tests/test_scripts.py
+++ b/nipy/tests/test_scripts.py
@@ -19,7 +19,9 @@
 from nose.tools import assert_true, assert_false, assert_equal, assert_raises
 
 from ..testing import funcfile
-from numpy.testing import decorators, assert_almost_equal
+
+from numpy.testing._private import decorators
+from numpy.testing import assert_almost_equal
 
 from nipy.testing.decorators import make_label_dec
 

Bug#961157: latexml: needs a dependency on libpod-parser-perl

[Niko Tyni]

Package: latexml
Version: 0.8.4-1
Severity: normal
User: debian-p...@lists.debian.org
Usertags: perl-5.32-transition

This package uses Pod::Find, part of the Pod-Parser distribution which
will be removed from the Perl core in upcoming version 5.32.  It is
being packaged separately for Debian as libpod-parser-perl (#960790),
and affected packages need to declare appropriate dependencies on that.

As the perl core packages already Provide libpod-parser-perl, these
dependencies can be added at any time and do not need to wait for the
separate package to enter sid.

Please consider adding a runtime dependency sooner rather than later,
to help our testing efforts.

Test setup with a newer Perl:

# latexmlc
Can't locate Pod/Find.pm in @INC (you may need to install the Pod::Find module) 
(@INC contains: /usr/bin/../lib /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.31.11 /usr/local/share/perl/5.31.11 
/usr/lib/x86_64-linux-gnu/perl5/5.31 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.31 /usr/share/perl/5.31 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at 
/usr/share/perl5/LaTeXML/Common/Config.pm line 19.
BEGIN failed--compilation aborted at /usr/share/perl5/LaTeXML/Common/Config.pm 
line 19.
Compilation failed in require at /usr/share/perl5/LaTeXML.pm line 23.
BEGIN failed--compilation aborted at /usr/share/perl5/LaTeXML.pm line 23.
Compilation failed in require at /usr/bin/latexmlc line 35.
BEGIN failed--compilation aborted at /usr/bin/latexmlc line 35.


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

Bug#959828: systemctl: `Provides: systemd`, but doesn't provide what systemd does

[Ross Vandegrift]

On Thu, May 07, 2020 at 07:52:31PM +0200, Julien Cristau wrote:
> On Thu, May 07, 2020 at 09:48:34PM +1000, Dmitry Smirnov wrote:
> > On Thursday, 7 May 2020 7:04:17 PM AEST Julien Cristau wrote:
> > > This use of Provides is not acceptable.  The systemctl package does not
> > > in any way provide the same functionality / interfaces as the systemd
> > > package, and as such it does not get to pretend that it does and cause
> > > problems to other packages.
> > 
> > I have to challenge that. "systemctl" provides enough functionality to 
> > replace "systemd" inside application containers. Therefore there are 
> > situations where "Provides: systemd" is justified.
> > 
> That's not what "Provides" means though.  What you're saying is
> "systemctl provides a subset of the systemd package's functionality".
> That's not good enough.  Provides is much stronger than "there are cases
> where this might be enough", and there's more to systemd than systemctl.

Indeed- packages that Build-Depend on systemd need a way to express that
fact.  experimental builds use apt-cudf, which now sees systemctl as a
more attractive solution:
https://buildd.debian.org/status/package.php?p=e17&suite=experimental

Ross

Bug#940511: Re: [Pkg-javascript-devel] Bug#940511: yarnpkg: Package symlink yarn -> yarnpkg

[Maël Nison]

Hi, I'm Maël, Yarn's lead maintainer.

While cmdtest has a popcon score higher than the yarn package, it's mostly
because Yarn isn't traditionally installed using the Debian package. For
historical reasons the 1.x branch always updated it, but in general our
users install Yarn using it's "competitor", npm. The npm numbers give a
very different picture: Yarn is downloaded 6.1m times per month.

There are currently talks to, potentially, ship symlinks for the three main
package managers along with Node (npm, which is already there, along with
Yarn and maybe pnpm). These plans aren't concrete yet, but a few people
think it's worth studying. In any case, the decision is expected to be
taken for Node 15, which will happen this year. To the extent possible, I
think it could be wise (and very appreciated!) to consider renaming the
`yarn` binary from `cmdtest` before it risks becoming an actual problem.

As a last note, I pinged Lars Wirzenius (who I think was the original
cmdtest maintainer?), back in March '19. He mentioned having recently
retired, but seemed fairly supportive of the idea ("I've now discussed the
name of our testing tool with its other developer and we will likely change
the name of our program during the Debian buster+1 development cycle").

Maël

On Mon, 16 Sep 2019 16:41:00 +0200 "Xavier"  wrote:
> Control: tags -1 + wontfix
>
> Le Lundi, Septembre 16, 2019 16:02 CEST, Melvin Vermeeren <
vermee...@posteo.net> a écrit:
> > Package: yarnpkg
> > Version: 1.13.0-1
> > Severity: normal
> >
> > Upstream calls the binary itself yarn as yarnpkg appears to have been
> > deprecated. Packaging as yarnpkg for backwards-compatibility is
understandable,
> > though I believe a symlink yarn -> yarnpkg should be added as tools and
scripts
> > nowadays typically check only for yarn.
> >
> > For example a problem occurs when installing GitLab from source, it
only checks
> > for yarn during the rake task and complains it cannot be found. A local
symlink
> > /usr/local/bin/yarn -> /usr/bin/yarnpkg resolved the issue.
> >
> > (Alternatively, perhaps make yarn the primary installation and symlink
the
> > legacy yarnpkg -> yarn.)
> >
> > Thanks.
>
> Debian has already a /usr/bin/yarn file given by cmdtest. cmdtest has a
better "popcon" than yarnpkg, that's why we won't change this for now.
>
> Cheers,
> Xavier
>
>
>

Bug#961155: pod2pdf: needs build and runtime dependencies on libpod-parser-perl

[Niko Tyni]

Package: pod2pdf
Version: 0.42-5
Severity: normal
User: debian-p...@lists.debian.org
Usertags: perl-5.32-transition

This package uses the Pod::Parser perl module, part of the Pod-Parser
distribution which will be removed from the Perl core in upcoming version
5.32.  It is being packaged separately for Debian as libpod-parser-perl
(#960790), and affected packages need to declare appropriate dependencies
on that.

As the perl core packages already Provide libpod-parser-perl, these
dependencies can be added at any time and do not need to wait for the
separate package to enter sid.

Please consider adding the necessary build and runtime dependencies
sooner rather than later, to help our testing efforts.

>From a test build log with Perl 5.31.11:

PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" 
"-e" "undef *Test::Harness::Switches; test_harness(1, 'blib/lib', 'blib/arch')" 
t/*.t

#   Failed test 'script compiles'
#   at t/compile.t line 11.
#   'Can't locate Pod/Parser.pm in @INC (you may need to 
install the Pod::Parser module) (@INC contains: /<>/blib/lib 
/<>/blib/arch /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.31.11 /usr/local/share/perl/5.31.11 
/usr/lib/x86_64-linux-gnu/perl5/5.31 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.31 /usr/share/perl/5.31 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .) at 
/<>/blib/lib/App/pod2pdf.pm line 20.
# BEGIN failed--compilation aborted at /<>/blib/lib/App/pod2pdf.pm 
line 20.
# Compilation failed in require at blib/script/pod2pdf line 19.
# BEGIN failed--compilation aborted at blib/script/pod2pdf line 19.
# '
# doesn't match '(?^:syntax OK$)'
# Looks like you failed 1 test of 1.
t/compile.t .. 
1..1
not ok 1 - script compiles

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

Bug#961156: tech-ctte: Call for votes on TC membership of Elana Hashman

[David Bremner]

Package: tech-ctte
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I call for votes on the following ballot to fill a vacant seat in the
Debian Technical Committee. The voting period starts immediately and
lasts for up to one week, or until the outcome is no longer in doubt
(§6.3.1).

===BEGIN
The Technical Committee recommends that Elana Hashman  be
appointed by the Debian Project Leader to the Technical Committee.

S: Recommend to Appoint Elana Hashman 
F: Further Discussion
===END

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

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAl7FjrEACgkQA0U5G1Wq
FSFzhBAAuoTkGCCjBTGqFTDOMHvFuQaKPp5sRWHGuNv4DNuZQ92GBtkWHjo2pVaN
np5f6RHFaDfG50PqqITvrSarHmpIaLvESVaFCYjaBGKXhkqa/I0vS/KRFiuXwu0j
YQHHCTMqbTWwHLU0MSYXwZtacXGE9muk12yCZH9IxICvU7rzwO2GKo4TpKPGjwlF
D3jMmxa0/KtYDDMuiReY8O/5XV+Ht5dEVUMNb7yDTIeBv5r9AzWSZT3iCve5ox+p
e1EUDIpLpy9zQH0z+G9fy8rQWsjpRAdxBqaWySgH76NOM8Ni02KC8k9UXCbezOiZ
NAQvtnRLTy1ovDvN3X3uP8xxp65fIkBTZwS8HfM4atiSV89IiN3hiipf1rDlrzz5
iwvxyK186cKlZlExgLwV+lrjWY1mco3KV1lgsmKuf6p9px4f9IPDwGKaMgzDP7yl
KOxdSKhilP54Ve6lodsFaqMDVr/wZS1sx7B9EBawBhMLYWrFHc26WKCQ45cWrLvd
QDhcYj6d6N+X3AfJVru83c0rTLcrwbn/0hnhCeYWbrak0sUfsY4E8+/4LjXX0tdF
+MGYWsySdaNHDqMa+n0yKxCvQQnZc0Xv1Bmns1DNZD/M+wi2wkUt1ZHuFdm0JtJ4
lDhDRZdqDEMIDzxMbIHa+0iiS+wCx01yGGBlmtcLUEtgfyzcE0M=
=LfgW
-END PGP SIGNATURE-

Bug#960658: Partially solved

[Xavier]

Control: severity -1 important

This bug is partially  fixed in version 3.2.0-5. Keeping it opened due to:
 * some unimportant tests still fail (disabled in 3.2.0-5)
 * build still fail for hppa and sparc64 [1]

[1]: https://buildd.debian.org/status/logs.php?pkg=cyrus-imapd&ver=3.2.0-5

Bug#961153: tech-ctte: Call for votes on TC membership of Sean Whitton

[David Bremner]

Package: tech-ctte
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I call for votes on the following ballot to fill a vacant seat in the
Debian Technical Committee. The voting period starts immediately and
lasts for up to one week, or until the outcome is no longer in doubt
(§6.3.1).

===BEGIN
The Technical Committee recommends that Sean Whitton  be
appointed by the Debian Project Leader to the Technical Committee.

S: Recommend to Appoint Sean Whitton 
F: Further Discussion
===END
- -- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAl7FjQMACgkQA0U5G1Wq
FSEFRg/9GBxoEc1kvjkJ87jstyqLbPs9mm5fslBnA4vZ479AoRcG1NgowifN2cTA
emF3d2FyHV2Q3r/xk4bo1GFAzLxvcBy/nh1WEetgLDBOrii0G63YaMWjpCpSyzI+
UiMUrHio+qIYLqtCnGGlOBn4OlONIADjzeytSH/wFl2Puv6txjK0zRiDrLO8B5RS
iZ8j/zD6mb3a+3AJKfbzrP+/jElVrEfMrwTVMJzni2K/QYlEc3uW/QiEnDUbcg08
+DiF0BiVqNXXOMPYfeIIT6cG89Evh3uxEqWOjgNREnrOOhtJzeVQrHW5N3X9XYM0
JOHGqJTBVDryR6tmQWBh38ta72nSkskMxV0An/Rbz5EUMKYq5Qy3RSkN6H9ogROS
HeovIdwB8vLbVRuUJY93kA112m0LgdTtqRZIz5Fqj1zj9U6cm5gt1pcC60xZnM5+
qH95UEbsuIbDpnxc8KdHTtVyNU6mZAT2novOFwwM2JjXgvPzj6AZ4AQ1nn1OWZMo
uajo1tmwXqENPlO288Edsml5mSNT+ztgOo6gTqyYca+38nu/RqmfO85MbFFSgOE4
uYtQm30MRjNsjLKkNLu7miadpWfUIIRddqBZRN8A2i18KyPpzpv/CkjIeaM3ejxs
vv9lSOyLC7vy14LGXELQ4nO6NmKu54XL7K0QIgVLIesTFJYFmpY=
=nouT
-END PGP SIGNATURE-

Bug#960955: inkscape: crash when resizing canvas on a system running wayland

[Mattia Rizzolo]

On Tue, May 19, 2020 at 10:19:40AM -0700, Diane Trout wrote:
> I mentioned this in the upstream report but the flatpak version from
> flathub does seem to work.

That's because the Debian toolchain by default passes
-DCMAKE_BUILD_TYPE=None
to cmake while building, which in the case of inkscape is pretty much
the same as passing -DCMAKE_BUILD_TYPE=Debug.
The flatpak is built with -DCMAKE_BUILD_TYPE=Release, which disables the
asserts therefore it doesn't crash.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#961154: debarchiver: needs a build dependency on libpod-parser-perl

[Niko Tyni]

Package: debarchiver
Version: 0.11.5
Severity: normal
User: debian-p...@lists.debian.org
Usertags: perl-5.32-transition

This package uses /usr/bin/podselect, part of the Pod-Parser distribution
which will be removed from the Perl core in upcoming version 5.32.
It is being packaged separately for Debian as libpod-parser-perl
(#960790), and affected packages need to declare appropriate dependencies
on that.

As the perl core packages already Provide libpod-parser-perl, these
dependencies can be added at any time and do not need to wait for the
separate package to enter sid.

Please consider adding a build dependency sooner rather than later,
to help our testing efforts.

 make[3]: Entering directory '/<>/po4a'
 podselect ../src/debarchiver.pl > debarchiver.pod

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

Bug#961137: RFS: wand/0.6.1-1 -- Python interface for ImageMagick library (Python 3)

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "wand"

 * Package name: wand
   Version : 0.6.1-1
   Upstream Author : E. McConville 
 * URL : https://github.com/emcconville/wand
 * License : Expat
 * Vcs : https://salsa.debian.org/debian/wand
   Section : python

It builds those binary packages:

  python3-wand - Python interface for ImageMagick library (Python 3)
  pypy-wand - Python interface for ImageMagick library (PyPy build)
  wand-doc - Python interface for ImageMagick library (documentation)

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/w/wand/wand_0.6.1-1.dsc

Changes since the last upload:

   * New upstream release.
   * Bump debhelper to 13
   * Update package description
   * Remove unneeded entries in d/rules
   * Add libmagickwand-6.q16-6 as build-dependency

I would also appreciate if the sponsor can grant me accsess to upload
this package on my own.

Regards,
Håvard

Bug#961152: apt-show-versions: needs a build dependency on libpod-parser-perl

[Niko Tyni]

Package: apt-show-versions
Version: 0.22.11
Severity: normal
User: debian-p...@lists.debian.org
Usertags: perl-5.32-transition

This package uses /usr/bin/podselect, part of the Pod-Parser distribution
which will be removed from the Perl core in upcoming version 5.32.
It is being packaged separately for Debian as libpod-parser-perl
(#960790), and affected packages need to declare appropriate dependencies
on that.

As the perl core packages already Provide libpod-parser-perl, these
dependencies can be added at any time and do not need to wait for the
separate package to enter sid.

Please consider adding a build dependency sooner rather than later,
to help our testing efforts.

>From a test rebuild log with Perl 5.31.11:

make[1]: Entering directory '/<>'
cp ./apt-show-versions blib/script/apt-show-versions
"/usr/bin/perl" -MExtUtils::MY -e 'MY->fixin(shift)' -- 
blib/script/apt-show-versions
Manifying 1 pod document
make[1]: Leaving directory '/<>'
podselect apt-show-versions > man/apt-show-versions.pod
/bin/sh: 1: podselect: not found
make: *** [debian/rules:24: build-stamp] Error 127

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

Bug#961151: xmms2: needs a build dependency on libpod-parser-perl

[Niko Tyni]

Package: xmms2
Version: 0.8+dfsg-18.2
Severity: normal
User: debian-p...@lists.debian.org
Usertags: perl-5.32-transition

This package uses /usr/bin/podselect, part of the Pod-Parser distribution
which will be removed from the Perl core in upcoming version 5.32.
It is being packaged separately for Debian as libpod-parser-perl
(#960790), and affected packages need to declare appropriate dependencies
on that.

As the perl core packages already Provide libpod-parser-perl, these
dependencies can be added at any time and do not need to wait for the
separate package to enter sid.

Please consider adding a build dependency sooner rather than later,
to help our testing efforts.

>From a test rebuild log with Perl 5.31.11:

   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
mv _build_without_python_ _build_ && ./waf -v && mv _build_ 
_build_without_python_
Waf: Entering directory `/<>/_build_'
[...]
[ 22/311] perldoc: src/clients/lib/perl/XMMSClientPlaylist.xs -> 
_build_/src/clients/lib/perl/Audio/XMMSClient/Playlist.pod
11:23:40 runner ' podselect ../src/clients/lib/perl/XMMSClientPlaylist.xs > 
src/clients/lib/perl/Audio/XMMSClient/Playlist.pod '
11:23:40 runner ' podselect ../src/clients/lib/perl/XMMSClient.xs > 
src/clients/lib/perl/Audio/XMMSClient.pod '
/bin/sh: 1: podselect: not found
[ 23/311] perldoc: src/clients/lib/perl/XMMSClientCollection.xs -> 
_build_/src/clients/lib/perl/Audio/XMMSClient/Collection.pod
11:23:40 runner ' podselect ../src/clients/lib/perl/XMMSClientCollection.xs > 
src/clients/lib/perl/Audio/XMMSClient/Collection.pod '
/bin/sh: 1: podselect: not found
/bin/sh: 1: podselect: not found
Waf: Leaving directory `/<>/_build_'
Build failed
 -> task failed (exit status 127): 
{task 140711141636112: perldoc XMMSClientPlaylist.xs -> Playlist.pod}
' podselect ../src/clients/lib/perl/XMMSClientPlaylist.xs > 
src/clients/lib/perl/Audio/XMMSClient/Playlist.pod '
 -> task failed (exit status 127): 
{task 140711141636240: perldoc XMMSClient.xs -> XMMSClient.pod}
' podselect ../src/clients/lib/perl/XMMSClient.xs > 
src/clients/lib/perl/Audio/XMMSClient.pod '
 -> task failed (exit status 127): 
{task 140711141636560: perldoc XMMSClientCollection.xs -> 
Collection.pod}
' podselect ../src/clients/lib/perl/XMMSClientCollection.xs > 
src/clients/lib/perl/Audio/XMMSClient/Collection.pod '
make[1]: *** [debian/rules:54: override_dh_auto_build] Error 1

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

Bug#961150: tech-ctte: Call for votes on TC membership of Sean Whitton

[David Bremner]

Package: tech-ctte
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I call for votes on the following ballot to fill a vacant seat in the
Debian Technical Committee. The voting period starts immediately and
lasts for up to one week, or until the outcome is no longer in doubt
(§6.3.1).

===BEGIN
The Technical Committee recommends that Niko Tyni  be
appointed by the Debian Project Leader to the Technical Committee.

S: Recommend to Appoint Sean Whitton 
F: Further Discussion
===END

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

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAl7FhWoACgkQA0U5G1Wq
FSEKuA/+I/D3o3m2MVTYQSbanNygV8PiXAvtRuRZ1n8uxmXGAsNc45pmKH6uiHhn
dXJxen2KZaaBiYwkYMUQiJxL500+28sWJX9VFHAbsRLqZsqdhmkEL/dzreAqLiWL
NrwzmQUlawvslbepJnHQOfjMXo4PRfoUyxg3UXwVIcNOBujjL4VDciUn8U+FljXo
AnYYcLcgj1oSpJM6a999MqFjvEYGupstfnjW7PZH9sZGwl4XwAmrv5PiCtjE28sW
rlF/INFXWa8CVbQrky+Ib0yKxhA4Cx7JsPVQP0egI+WmD7bmvNmMcfisk0YqtzES
nHPCyEWUjMwfwGAS7rWHkttyqIdSen+3+zYqxM+2VgblRW0bXmOtC/BV5ldgsdL2
ieAyVVB+KgZtzSiPNh0+tWL6A/EA6r4E+bDAjgsnhK7TeM6NfdSrQFylh2v42+0+
0dOicsnWUeZqIfii3WlXNjRJa6NqFArzpXG48CHL66ud0efUDwLK/qdEdGTXT1iy
H4wUtN4zXSTADrCgyV1qV4Kn2LYRCJSHl6SBu/Pzjw2EaIWQX6MEwW4PTSbhupfG
QQiwh96Xd1fBXq2X1Jw9zLX59bRAKjb7jgPlf+9gD/Ntd18EjCydIePVPLnYVLky
Lz7JOSq0EdErDXncL4nt81CO9QEt0mdc/1f62Txx/Svg+XwESpM=
=5gqS
-END PGP SIGNATURE-

Bug#961149: rxvt-unicode: needs a build dependency on libpod-parser-perl

[Niko Tyni]

Package: rxvt-unicode
Version: 9.22-6
Severity: normal
User: debian-p...@lists.debian.org
Usertags: perl-5.32-transition

This package uses the Pod::Parser perl module, which will be removed from
the Perl core in upcoming version 5.32. It is being packaged separately
for Debian as libpod-parser-perl (#960790), and affected packages need
to declare appropriate dependencies on that.

As the perl core packages already Provide libpod-parser-perl, these
dependencies can be added at any time and do not need to wait for the
separate package to enter sid.

Please consider adding a build dependency sooner rather than later,
to help our testing efforts.

>From a test rebuild log with Perl 5.31.11:

   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
# We patch the documentation and need to rebuild it
/usr/bin/make -C doc clean alldoc
make[2]: Entering directory '/<>/doc'
rm -f rxvt.1.man rxvt.7.man rxvtc.1.man rxvtd.1.man
./podtbl rxvt.1.tbl
Can't locate Pod/Parser.pm in @INC (you may need to install the Pod::Parser 
module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.31.11 
/usr/local/share/perl/5.31.11 /usr/lib/x86_64-linux-gnu/perl5/5.31 
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.31 /usr/share/perl/5.31 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at ./podtbl line 
3.
BEGIN failed--compilation aborted at ./podtbl line 3.
make[2]: *** [Makefile:47: rxvt.1.tbl] Error 2

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

Bug#961128: apt-transport-https: https fails with segmentation fault

[mehturt]

‐‐‐ Original Message ‐‐‐
On Wednesday, May 20, 2020 3:04 PM, Julian Andres Klode  wrote:

> Control: tag -1 moreinfo
>
> On Wed, May 20, 2020 at 02:41:12PM +0200, Mehturt wrote:
>
> > Package: apt-transport-https
> > Version: 1.4.10
> > Severity: important
> > Dear Maintainer,
> > running "apt update" finishes with segmentation fault
> > when the following entry is in my sources.list:
> > deb http://packages.matrix.org/debian stretch main
> > Removing the entry from sources.list produces no crash.
> > This seems to be similar to already reported
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778375
>
> Please obtain a full backtrace.

Sorry, not sure what full backtrace means, but I installed 
apt-transport-https-dbgsym,
run apt update again and got this using gdb and the core file:

Core was generated by `/usr/lib/apt/methods/https.bin'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f0d6c04f4d7 in ?? () from 
/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
(gdb) bt
#0  0x7f0d6c04f4d7 in ?? () from 
/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
#1  0x5638ad9bf74b in HttpsMethod::~HttpsMethod (this=0x7ffe4abe9690, 
__in_chrg=) at ./methods/https.cc:538
#2  main (argv=) at ./methods/https.cc:546

Bug#766441: RFA: scala-mode-el -- Emacs major mode for editing scala source code

[Sławomir Wójcik]

Hello,

I would like to adopt this package and hopefully maintain it as part of the
Debian Emacsen Packaging Team.

I've packaged it, the package is on debian mentors:
https://mentors.debian.net/package/emacs-scala-mode
and the repository is on salsa under my user for now:
https://salsa.debian.org/Valdaer/emacs-scala-mode

One issue is that I've created the repo from scratch because git repo is not
reachable, existing package have quite ancient upstream version and it's 
debian

files(especially rules is obviously not using dh-elpa) are mostly outdated.

I can try to use gbp-import-dsc and recreate a new repo if it's really 
necessary

or required but I don't see much value in it because:

-if we want to adhere to EmacsenTeam Addons packaging policy
(https://wiki.debian.org/EmacsenTeam) and I think we should for better
collaboration and consistency then the package name should be changed to
elpa-scala-mode and existing https://packages.debian.org/sid/scala-mode-el
should be marked as transitional dummy package installing new one, right?

-upstream version in existing package and most of debian files are very old
or outdated

Please, let me know what should be done. As I pointed out here:
https://lists.debian.org/debian-emacsen/2020/05/msg00039.html
it would be the best if someone from Debian Emacsen Packaging Team will work
with me on this and other packages but maybe someone else will be 
interested to

give his/her opinion.

Regards,
Sławomir Wójcik

Bug#961106: Bug for `telegram-desktop'

[Nicholas Guriev]

Control: tag -1 moreinfo

On Wed, 2020-05-20 at 11:22 +0430, morteza jamareh wrote:
> I use apt install telegram-desktop to install telegram,
> After that I need to use mtproxy to connect to telegram. When I go to add
> mtproxy in Credentials field I some keyboard keys not working. I checked it
> in both stable and testing and 3 other hardware,

Thank you for the feedback. I do not experience problems with
telegram-desktop in a clean Debian Stable testbed. Inter alia, the app
is still able to work through a proxy. I have tested SOCKS5 and MtProto
just now. It is quite unclear what happens on your end. Please attach
logs of the app to dig the issue. Screenshots or even a short screencast
will also help.

Bug#961148: libgraphics-colorobject-perl: broken by new libgraphics-colornames-perl

[Niko Tyni]

Package: libgraphics-colorobject-perl
Version: 0.5.0-7.1
Severity: grave
Tags: bullseye sid
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=127300

Graphics::ColorObject needs Graphics::ColorNames::HTML, which was recently
dropped from the libgraphics-colornames-perl package in Debian.

 % perl -e 'use Graphics::ColorObject'
 Cannot load color naming scheme module Graphics::ColorNames::HTML at 
/usr/share/perl5/Graphics/ColorObject.pm line 1902.
 Compilation failed in require at -e line 1.

Graphics::ColorNames::HTML is now available separately on CPAN, with a
deprecation notice pointing users to Graphics::ColorNames::WWW (packaged
in Debian as libgraphics-colornames-www-perl) instead.

So Graphics::ColorObject needs to adapt, or Graphics::ColorNames::HTML
needs to be packaged separately despite the deprecation.

Also, libgraphics-colornames-perl should add a Breaks entry for the
versions of libgraphics-colorobject-perl it broke.
-- 
Niko Tyni   nt...@debian.org

Bug#960677: Memory leak

[darkdragon]

The packaged version contains a severe memory leak (
https://github.com/rclone/rclone/issues/4259)! This is fixed in latest
upstream version 1.51.0. Please update ASAP.

Bug#961136: recode: Consider switching upstream and package new version (3.7.1)?

[Reuben Thomas]

On Wed, 20 May 2020 at 16:24, Boyuan Yang  wrote:

> According to https://www.gnu.org/software/recode/ , the new upstream
> of package recode is now https://github.com/rrthomas/recode . GNU
> is no longer hosting this software. Please consider switching the
> upstream and package new version (3.7.1).
>

This is correct, and I'm "rrthomas"!

I'm also a DM, and happy to help get recode 3.7 (latest release 3.7.6) into
Debian.
-- 
https://rrt.sc3d.org

Bug#961147: libcolor-calc-perl: broken by new libgraphics-colornames-perl

[Niko Tyni]

Package: libcolor-calc-perl
Version: 1.074-2
Severity: grave
Tags: bullseye sid
X-Debbugs-Cc: libgraphics-colornames-p...@packages.debian.org

Color::Calc uses Graphics::ColorNames::HTML, which was recently dropped
from the libgraphics-colornames-perl package in Debian.

Graphics::ColorNames::HTML is now available separately on CPAN, with a
deprecation notice pointing users to Graphics::ColorNames::WWW (packaged
in Debian as libgraphics-colornames-www-perl) instead.

So Color::Calc needs to adapt, or Graphics::ColorNames::HTML needs to be
packaged separately despite the deprecation.

Also, libgraphics-colornames-perl should add a Breaks entry for the
versions of libcolor-calc-perl it broke.
-- 
Niko Tyni   nt...@debian.org

Bug#961145: RFS: localepurge/0.7.3.9

[Miguel Figueiredo]

Package: sponsorship-requests
  Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "localepurge"

 * Package name: localepurge
   Version : 0.7.3.9
 * URL : https://salsa.debian.org/elmig-guest/localepurge
 * License : GPL-2+
   Section : admin

  It builds those binary packages:

localepurge - reclaim disk space by removing unneeded localizations

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


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

  Alternatively, one can download the package with dget using this command:
dget -x 
https://mentors.debian.net/debian/pool/main/l/localepurge/localepurge_0.7.3.9.dsc


  Changes since the last upload:
  * Remove localization files on /usr/share/X11/locale thanks to Topi
Miettinen.
  * Don't remove /usr/share/aptitude/{mine-}help.txt. Thanks to 
Gianluigi Tiesi. (Closes: #943949)

  * Remove NEWS.Debian.
  * Bump Standards to 4.5.0 version - no changes required.
  * Preserve /usr/share/help/C. Thanks to Roderich Schupp. (Closes: 
#940236)


--
Best regards / Melhores cumprimentos,

Miguel Figueiredo

Bug#961146: systemd-logind sometimes ignores a systemd-inhibit lock

[Vincent Lefevre]

Package: systemd
Version: 245.5-2
Severity: normal

I use a systemd-inhibit lock, which has currently been running
since 19:12, as shown by:

zira:~,2> ps -fwwC systemd-inhibit
UID  PIDPPID  C STIME TTY  TIME CMD
vinc17 34134   1  0 19:12 ?00:00:00 systemd-inhibit 
--what=handle-lid-switch --who=vinc17 --why=power supply or external output 
--mode=block /home/vinc17/wd/src/scripts/inhibit-suspend 10 log +

zira:~,2> systemd-inhibit --list --no-pager
WHOUID  USER   PID   COMMWHAT  WHY  
   MODE 
vinc17 1000 vinc17 34134 systemd-inhibit handle-lid-switch power supply or 
external output block

1 inhibitors listed.

But when I closed the lid at 20:55, the system got suspended:

[...]
May 20 20:55:08 zira inhibit-suspend[48475]: (vinc17) on-line: yes
May 20 20:55:08 zira inhibit-suspend[48480]: (vinc17) output: 0
May 20 20:55:14 zira systemd-logind[785]: Lid closed.
May 20 20:55:14 zira systemd-logind[785]: Suspending...
[...]

I don't know what changed now for systemd, but I've exceptionally
started the X server from a VT.

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-8
ii  libapparmor1 2.13.4-1+b1
ii  libaudit11:2.8.5-3+b1
ii  libblkid12.35.1-5
ii  libc62.30-8
ii  libcap2  1:2.34-2
ii  libcrypt11:4.4.16-1
ii  libcryptsetup12  2:2.3.2-1
ii  libgcrypt20  1.8.5-5
ii  libgnutls30  3.6.13-2
ii  libgpg-error01.37-1
ii  libidn2-02.3.0-1
ii  libip4tc21.8.4-3
ii  libkmod2 27+20200310-2
ii  liblz4-1 1.9.2-2
ii  liblzma5 5.2.4-1+b1
ii  libmount12.35.1-5
ii  libpam0g 1.3.1-5
ii  libpcre2-8-0 10.34-7
ii  libseccomp2  2.4.3-1+b1
ii  libselinux1  3.0-1+b3
ii  libsystemd0  245.5-2
ii  mount2.35.1-5
ii  systemd-timesyncd [time-daemon]  245.5-2
ii  util-linux   2.35.1-5

Versions of packages systemd recommends:
ii  dbus  1.12.16-2

Versions of packages systemd suggests:
ii  policykit-10.105-26
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.137
ii  libnss-systemd   245.5-2
ii  libpam-systemd   245.5-2
ii  udev 245.5-2

-- Configuration Files:
/etc/systemd/journald.conf changed:
[Journal]
Storage=persistent

/etc/systemd/logind.conf changed:
[Login]
HandlePowerKey=ignore

/etc/systemd/system.conf changed:
[Manager]
DefaultTimeoutStopSec=20s


-- no debconf information

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

Bug#961144: ucf breaks bacula autopkgtest: Job for bacula-director.service failed

[Paul Gevers]

Source: ucf, bacula
Control: found -1 ucf/3.0039
Control: found -1 bacula/9.6.3-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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

   passfail
ucffrom testing3.0040
bacula from testing9.6.3-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 of ucf to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/b/bacula/555/log.gz
autopkgtest [10:36:26]: test backup-test-pgsql: [---
+ apt-get -y install debconf-utils
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
  debconf-utils
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 57.1 kB of archives.
After this operation, 108 kB of additional disk space will be used.
Get:1 http://deb.debian.org/debian testing/main amd64 debconf-utils all
1.5.74 [57.1 kB]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 57.1 kB in 0s (745 kB/s)
Selecting previously unselected package debconf-utils.
(Reading database ...
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 15551 files and directories currently installed.)
Preparing to unpack .../debconf-utils_1.5.74_all.deb ...
Unpacking debconf-utils (1.5.74) ...
Setting up debconf-utils (1.5.74) ...
+ awk '$3=="password"{print}'
+ debconf-set-selections
+ debconf-get-selections
+ for pkg in bacula-director-mysql bacula-director-pgsql
++ dpkg-query --showformat '${db:Status-Status}' -W bacula-director-mysql
+ pkg_status=not-installed
+ '[' not-installed = installed ']'
+ for pkg in bacula-director-mysql bacula-director-pgsql
++ dpkg-query --showformat '${db:Status-Status}' -W bacula-director-pgsql
+ pkg_status=installed
+ '[' installed = installed ']'
+ echo 'bacula-director-pgsql bacula-director-pgsql/dbconfig-reinstall
boolean true'
+ debconf-set-selections
+ DEBIAN_FRONTEND=noninteractive
+ dpkg-reconfigure bacula-director-pgsql
dbconfig-common: writing config to
/etc/dbconfig-common/bacula-director-pgsql.conf
creating postgres user bacula:  already exists.
resetting password:  success.
dbconfig-common: dumping pgsql database bacula to
/var/tmp/bacula-director-pgsql.bacula.2020-05-20-10.36.pgsql.e6nhYl.
dbconfig-common: dropping old pgsql database bacula.
dropping database bacula: success.
verifying database bacula was dropped: success.
creating database bacula: success.
verifying database bacula exists: success.
populating database via administrative sql...  done.
populating database via sql...  done.
dbconfig-common: flushing administrative password
+ echo 'start testing ... '
start testing ...
+ echo 'USER: root'
USER: root
+ DBTYPE=pgsql
+ echo 'DBTYPE: pgsql'
DBTYPE: pgsql
+ '[' pgsql = pgsql ']'
+ echo '- installing packages ---'
- installing packages ---
+ apt-get -y install bacula bacula-director-pgsql
Reading package lists...
Building dependency tree...
Reading state information...
bacula is already the newest version (9.6.3-1).
bacula-director-pgsql is already the newest version (9.6.3-1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
+ echo '- configuring Bacula daemons ---'
- configuring Bacula daemons ---
+
FILECHGRDIR=/tmp/autopkgtest-lxc.zc_04wyr/downtmp/autopkgtest_tmp/bacula-sd/filechgr
+
RESTOREDIR=/tmp/autopkgtest-lxc.zc_04wyr/downtmp/autopkgtest_tmp/bacula-restores
+ mkdir -p
/tmp/autopkgtest-lxc.zc_04wyr/downtmp/autopkgtest_tmp/bacula-sd/filechgr
+ chown -R bacula:tape
/tmp/autopkgtest-lxc.zc_04wyr/downtmp/autopkgtest_tmp/bacula-sd/filechgr
+ sed -i
s%/nonexistant/path/to/file/archive/dir%/tmp/autopkgt

Bug#961119: ansible: Ansible fails to work on a minimal system (missing python 2 dependency)

[Lee Garrett]

Hi Elena,

On 20/05/2020 12:46, Elena ``of Valhalla'' wrote:
> Package: ansible
> Version: 2.7.7+dfsg-1
> Severity: important
> 
> Dear Maintainer,
> 
> on a minimal stable (buster) installation, ansible fails to run (at
> least on the machine itself) because of a lack of the python (2)
> interpreter.
> 
> To reproduce, debootstrap an image (but installing from netinst without
> adding things with tasksel also works):
> 
> # mkdir buster
> # debootstrap buster buster/
> # mount -t devtmpfs udev buster/dev/
> # chroot buster
> 
> # ansible -i localhost, -m setup -c local all
> 
> localhost | FAILED! => {
> "changed": false,
> "module_stderr": "/bin/sh: 1: /usr/bin/python: not found\n",
> "module_stdout": "",
> "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error",
> "rc": 127
> }
> 
> Installing python (2) of course fixes the issue.

Yes, that is correct, and also expected behaviour. Let me elaborate.

The ansible controller (the node you're running the ansible playbook
from) is fully migrated over to python3. This is where you have your
package "ansible" installed, and the dependencies for it are also correct.

The nodes you're managing with ansible (so the hosts you have listed in
your inventory file) don't have the package ansible installed, so we
can't control what's installed there and what isn't through the ansible
package. For this reason many ansible modules have documented which
python modules need to be installed on the nodes for them to work.
You're expected to ensure those packages are installed on the node
before using the ansible module there. For example, to use the ansible
module "apt" you need to have python-apt or python3-apt installed on the
node (not the controller).

In your example the controller and the managed node happen to be the
same machine. You will either need to have both python 2 and 3
installed, or you need to change the interpreter for the node by setting
the "ansible_python_interpreter" var to /usr/bin/python3. This var can
be set globally in ~/.ansible.cfg or per group/host in group_vars/ or
host_vars/. [0]

For historic reasons the interpreter pretty much defaults to python2,
because that is nearly universally installed on any Linux machine of the
last decade.

>From ansible 2.12 and onwards, the heuristic will be a little bit
smarter. [1]

> 
> I've noticed that it seems to be hardcoded as such in quite a few
> modules:
> 
> # grep -r '/usr/bin/python$' /usr/lib/python3/dist-packages/ansible | wc 
> -l
> 2083
> 
> but I've also checked that in sid the original command is working, while
> those files still have an hardcoded python2 executable, so I'm not sure
> what is going on there.

Yes, this is also expected, as the shebang will be rewritten for those
modules that get run on the controlled nodes.

I'm not sure how to approach this issue the best, it seems as though
some users have stumbled over it in the past.

Greets,
Lee

[0]
https://docs.ansible.com/ansible/latest/reference_appendices/python_3_support.html
[1]
https://docs.ansible.com/ansible/latest/reference_appendices/interpreter_discovery.html



> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable'), (1, 
> 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.6.0-1-amd64 (SMP w/2 CPU cores)
> Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
> Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_IE:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages ansible depends on:
> ii  openssh-client1:8.2p1-4
> ii  python3   3.8.2-3
> ii  python3-crypto2.6.1-13.1+b1
> ii  python3-cryptography  2.8-4
> ii  python3-distutils 3.8.2-2
> ii  python3-dnspython 1.16.0-2
> ii  python3-httplib2  0.14.0-3
> ii  python3-jinja22.10.1-2
> ii  python3-netaddr   0.7.19-4
> ii  python3-paramiko  2.6.0-2
> ii  python3-yaml  5.3.1-1+b1
> 
> Versions of packages ansible recommends:
> ii  python3-argcomplete  1.8.1-1.3
> ii  python3-jmespath 0.9.5-1
> ii  python3-kerberos 1.1.14-3.1+b1
> ii  python3-libcloud 2.8.0-1
> ii  python3-selinux  3.0-1+b3
> ii  python3-winrm0.3.0-2
> ii  python3-xmltodict0.12.0-2
> 
> Versions of packages ansible suggests:
> ii  cowsay   3.03+dfsg2-7
> ii  sshpass  1.06-1+b1
> 
> -- no debconf information
> 

Bug#961007: Re: Some directives are ignored under sshd_config.d

[Alkis Georgopoulos]

I believe it's this upstream bug:
https://bugzilla.mindrot.org/show_bug.cgi?id=3122

"New Include functionality does not work as documented"

Bug#961097: htop: segfaults after ^Z+fg on x32

[наб]

In further testing it appears to happen only on an actual VT and only
with TERM=linux (none of dumb, {xterm,st}{,-256color} crash).

I haven't been able to reproduce it over ssh, no matter the $TERM.


signature.asc
Description: PGP signature

Bug#961088: bug confirmed

[Hans-Georg Rist]

Hi,

I have the same problem with an HP Officejet 7310 AIO:

sane-find-scanner reports:
"found USB scanner (vendor=0x03f0 [HP], product=0x4211 [Officejet 7300
series]) at libusb:002:012"

but "scanimage -L" fails:
"No scanners were identified."

Unfortunately, I wasn't able to downgrade to 3.20.3+dfsg0-2. There are
(too) many dependencies, and I couldn't find the 3.20.3 packages on the
Debian servers).

A fix or a workaround would be very much appreciated.

Regards and thanks for your efforts,
HG

Bug#961132: lightdm: with the nvidia driver, lightdm suspends the system when locking or logging out

[Vincent Lefevre]

Control: forcemerge 961132 961124
Control: reassign 961132 lightdm 1.26.0-7
Control: retitle -1 lightdm: with the nvidia driver, lightdm suspends the 
system when locking or logging out

On 2020-05-20 15:58:11 +0200, Vincent Lefevre wrote:
> Package: light-locker
> Version: 1.8.0-3
> Severity: important
> 
> With the nvidia driver, light-locker suspends the system when locking.
> In the journalctl logs, I get a line like
> 
> May 20 09:16:43 zira systemd-logind[785]: Suspending...
> 
> and according to the systemd maintainer, this is light-locker's fault.
> 
> This happens at lock time, thus immediately with --no-late-locking,
> and at the time of screensaver deactivation with --late-locking.
> 
> Note: Until yesterday, IIRC, using --no-late-locking (at least) did
> not trigger a suspend, but the screen was unblanked after a few seconds
> (it remained black, but the DPMS state was no longer off, which defeats
> the purpose of the screensaver nowadays). So this may be related to
> some conditions.
> 
> Moreover, after the resume, this puts the system in a bad state, and
> the X server (thus lightdm) no longer works (apparently, according to
> the lightdm Xorg logs, no screens found). I can switch to a VT, but
> the login prompt is shown only for a fraction of second, after which
> I just get a blinking cursor over a black screen.
> 
> In case this matters, my xrandr configuration is
> 
>   xrandr --output DP-3 --off \
>  --output DP-4 --auto --primary \
>  --output DP-5 --auto --right-of DP-4
> 
> where DP-3 corresponds to the laptop screen. But this is no longer
> honored after the resume.

I eventually got rid of light-locker, so that there is no longer
any issue with the screensaver. But logging out also suspends the
system!

Both locking and logging out trigger the lightdm login prompt,
so that I suppose that this is the same issue, and it was not
light-locker that was suspending the system, but lightdm.

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

Bug#944557: bzip2: built without LFS support

[peter green]

Hi, I just had a raspbian user run into this bug.

https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=274484

I notice that this bug report was tagged as pending 6-months ago. Is there some 
blocker for uploading it?

I also wonder if a stable update should be considered for this since this is a 
regression compared to stretch and IMO a fairly major one.

Bug#961143: gpg-wks-client: /usr/lib/gnupg/gpg-wks-client binary provided outside of $PATH

[Michael Prokop]

Package: gpg-wks-client
Version: 2.2.12-1+deb10u1
Severity: normal

Hi,

for example https://wiki.gnupg.org/WKDHosting is mentioning

| gpg --list-options show-only-fpr-mbox  -k $PATTERN | gpg-wks-client -v 
--install-key

But the gpg-wks-client package on Debian provides the
gpg-wks-client binary only as /usr/lib/gnupg/gpg-wks-client,
meaning it's outside of the user's common and default $PATH setting.
Is this by intention?

regards
-mika-


signature.asc
Description: Digital signature

Bug#961128: apt-transport-https: https fails with segmentation fault

[Julian Andres Klode]

Control: fixed -1 1.5~alpha4
Control: tag -1 unreproducible

On Wed, May 20, 2020 at 03:41:57PM +, meht...@protonmail.com wrote:
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, May 20, 2020 3:04 PM, Julian Andres Klode  
> wrote:
> 
> > Control: tag -1 moreinfo
> >
> > On Wed, May 20, 2020 at 02:41:12PM +0200, Mehturt wrote:
> >
> > > Package: apt-transport-https
> > > Version: 1.4.10
> > > Severity: important
> > > Dear Maintainer,
> > > running "apt update" finishes with segmentation fault
> > > when the following entry is in my sources.list:
> > > deb http://packages.matrix.org/debian stretch main
> > > Removing the entry from sources.list produces no crash.
> > > This seems to be similar to already reported
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778375
> >
> > Please obtain a full backtrace.
> 
> Sorry, not sure what full backtrace means, but I installed 
> apt-transport-https-dbgsym,
> run apt update again and got this using gdb and the core file:

well you clearly miss a libcurl-gnutls dbgsym package, and you need to pass
"full" to bt.

> 
> Core was generated by `/usr/lib/apt/methods/https.bin'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x7f0d6c04f4d7 in ?? () from 
> /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
> (gdb) bt
> #0  0x7f0d6c04f4d7 in ?? () from 
> /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
> #1  0x5638ad9bf74b in HttpsMethod::~HttpsMethod (this=0x7ffe4abe9690, 
> __in_chrg=) at ./methods/https.cc:538
> #2  main (argv=) at ./methods/https.cc:546

This fails in curl_easy_cleanup(curl) call.

It might need running this in valgrind to figure out what's going
on, as that seems like something that should work, and it might be
a corruption elsewhere. That said, no idea really how to run the
methods in valgrind.

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

Bug#961142: snapshot.debian.org: python3 migration

[Baptiste BEAUPLAT]

Package: snapshot.debian.org
Severity: normal

Hi,

As discussed previously with pabs and weasel, I'm interested in taking
on the python 3 migration for snapshot.

With bullseye, the goal is to drop python 2 packages. As such the
framework used by snapshot, pylons, will be removed as the project is
mostly dead and not python3 compatible.

I'm willing to port snapshot to python 3, replacing the pylons framework
in the process.

After doing a bit of research on snapshot and how it works, I believe
that switching over to the flask framework [1] would be a fitting
option. flask is a lightweight python web framework, well maintained and
packaged in Debian.

That would allow us to keep the model part of snapshot, still using
psycopg2 as the driver to communicate with the postgreSQL backend.
Pylons specifics parts will have to be replaced with flask logic and
templates will have to be converted to jinja2.

Technically, I propose we use salsa to work our way on that migration:

- I port a small set of code to python3/flask on my fork
- I add the required tests to cover that set
- I submit a merge request to the snapshot project
- You review and merge the small set to a migration branch
- We go back to step 1 until migration is over

We can use this bug report to tracker progression or to exchange on
technical topics.

Once we are ready to migrate the production, you can merge the migration
branch to master.

To facilitate the migration, I do intend to cover the entire rewrite
with testing with stable+bpo and unstable as targets.

For easier communication, we could also create a #debian-snapshot on
OTFC. Else, I'm available on #-qa or #-admin.

Looking forward to your comments,

Best,
-- 
Baptiste BEAUPLAT - lyknode



signature.asc
Description: OpenPGP digital signature