Bug#958899: dbab: /etc/init.d/dbab stop does not stop

[Kevin Ryde]

Tong Sun  writes:
>
> see if removing the added lines works for you

Yep, beaut, removing that works.

The messages slightly stack up.  I wonder if that was the reason for the
--quiet stuff in the actual init-d-script, which I thought was hiding
information!  Nothing to worry about though.

> I was forced to add them back because of the
>
> initd-script-does-not-implement-required-option &
> init.d-script-does-not-source-init-functions

Hmm.  You can always stick a lintian override file in the package, to
mean vaguely you considered it and had good reason :-).  Or ignore!

If it might be of interest, and since I mentioned having a go a long
time ago, for comparison

http://user42.tuxfamily.org/temporary/x2gpm.init

It's a slight cut and paste, but is all I understood needed at the time.
/etc/init.d has quite a few examples of varying levels of difficulty or
configability though :).

I'm a fork and make pidfile myself, so no --background which you have.
And being an executable I can match --exec in addition to the pidfile
for stop.

Bug#961396: python3: signed/unsigned mismatch in Py_UNICODE_ISSPACE macro

[Kipp Cannon]

Package: python3
Version: 3.8.2-3
Severity: normal
Tags: patch upstream

Dear Maintainer,

There is a signed/unsigned mismatch in the Py_UNICODE_ISSPACE() macro in
Python's unicodeobject.h.  The following program demonstrates the problem

#include 

int main(int argc, char *argv[])
{
Py_UNICODE x = 0;

return Py_UNICODE_ISSPACE(x);
}

compile with

$ gcc -Wsign-compare -Werror $(pkg-config --cflags python3) a.c
In file included from /usr/include/python3.8/unicodeobject.h:1037,
 from /usr/include/python3.8/Python.h:97,
 from a.c:1:
a.c: In function ‘main’:
/usr/include/python3.8/cpython/unicodeobject.h:25:11: error: comparison of
integer expressions of different signedness: ‘Py_UNICODE’ {aka ‘int’} and
‘unsigned int’ [-Werror=sign-compare]
   25 | ((ch) < 128U ? _Py_ascii_whitespace[(ch)] :
_PyUnicode_IsWhitespace(ch))
  |   ^
a.c:7:9: note: in expansion of macro ‘Py_UNICODE_ISSPACE’
7 |  return Py_UNICODE_ISSPACE(x);
  | ^~
cc1: all warnings being treated as errors


The comparison is between the macro's parameter ch and the unsigned integer
128.  On Debian amd64, Py_UNICODE is typedef'd to signed int causing a
signed/unsigned mismatch warning when the Py_UNICODE_ISSPACE() macro is used
with variables that have been defined to be the correct Py_UNICODE type.  The
warning is mostly harmless, but it prevents Python extension  modules from
being compiled with warnings enabled and -Werror.

The following patch fixes it

$ diff /usr/include/python3.8/cpython/unicodeobject.h unicodeobject.h
25c25
< ((ch) < 128U ? _Py_ascii_whitespace[(ch)] : _PyUnicode_IsWhitespace(ch))
---
> ((ch) < (Py_UNICODE)128 ? _Py_ascii_whitespace[(ch)] :
_PyUnicode_IsWhitespace(ch))


I don't know if this problem is unique to the Debian packaging of Python or if
it exists upstream, so I'm reporting it here.  If I should report this upstream
instead please let me know.  Thanks,

-Kipp



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

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

Versions of packages python3 depends on:
ii  libpython3-stdlib  3.8.2-3
ii  python3-minimal3.8.2-3
ii  python3.8  3.8.3-1

python3 recommends no packages.

Versions of packages python3 suggests:
pn  python3-doc   
ii  python3-tk3.8.2-2
pn  python3-venv  

-- no debconf information

Bug#961395: initramfs-tools: failed hardlink initrd.img

[jan de kruyf]

Package: initramfs-tools
Version: 0.137
Severity: important

Dear Maintainer,

   * What led up to the situation?
New installation of 'testing' while updating initramfs
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 root@snowflake# update-initramfs -u
ln: failed to create hard link '/boot/initrd.img-5.6.0-1-amd64.dpkg-bak' =>
'/boot/initrd.img-5.6.0-1-amd64': Operation not permitted
update-initramfs: Generating /boot/initrd.img-5.6.0-1-amd64
-
-
-
I: The initramfs will attempt to resume from /dev/sda4
I: (UUID=b6c95418-424c-4e50-b856-c6c9e9ba6f58)
I: Set the RESUME variable to override this.
root@snowflake#

 NOTE:
The system seems stable after one or two rebuilds of the initrd.img.
/dev/sda4 is the swap partition.
The system is booting UEFI so according to bits and pieces of info
found here and there
the first partition is a fat/efi partition mounted under /boot/efi
and the 2nd partion is fat32 and mounted under /boot.
This is possibly the cause of this warning.

It might be useful to clarify the thinking about this matter in the doku.

Regards,

Jan de Kruyf.



-- Package-specific info:
-- initramfs sizes
-rwxr-xr-x 1 root root 64M May 24 04:52 /boot/initrd.img-5.6.0-1-amd64
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-5.6.0-1-amd64 
root=UUID=a3feaf78-b118-40ed-a405-06caf7c1a5cd ro quiet splash

-- /proc/filesystems
btrfs
ext3
ext2
ext4
vfat
fuseblk

-- lsmod
Module  Size  Used by
dm_mod159744  0
rfcomm 90112  12
fuse  139264  3
ctr16384  2
ccm20480  6
cmac   16384  1
bnep   28672  2
snd_soc_skl   180224  0
snd_soc_hdac_hda   24576  1 snd_soc_skl
snd_hda_ext_core   36864  2 snd_soc_hdac_hda,snd_soc_skl
snd_soc_sst_ipc20480  1 snd_soc_skl
snd_hda_codec_hdmi 73728  1
ath10k_pci 49152  0
snd_soc_sst_dsp40960  1 snd_soc_skl
ath10k_core   405504  1 ath10k_pci
snd_soc_acpi_intel_match40960  1 snd_soc_skl
btusb  57344  0
btrtl  24576  1 btusb
btbcm  20480  1 btusb
snd_soc_acpi   16384  2 snd_soc_acpi_intel_match,snd_soc_skl
ath36864  1 ath10k_core
btintel32768  1 btusb
snd_soc_core  278528  2 snd_soc_hdac_hda,snd_soc_skl
x86_pkg_temp_thermal20480  0
intel_powerclamp   20480  0
snd_hda_codec_realtek   126976  1
nls_ascii  16384  2
coretemp   20480  0
snd_compress   28672  1 snd_soc_core
mei_wdt16384  0
nls_cp437  20480  2
snd_hda_codec_generic94208  1 snd_hda_codec_realtek
snd_hda_intel  57344  0
vfat   20480  2
bluetooth 667648  39 btrtl,btintel,btbcm,bnep,btusb,rfcomm
snd_intel_dspcfg   24576  2 snd_hda_intel,snd_soc_skl
kvm_intel 327680  0
intel_rapl_msr 20480  0
fat86016  1 vfat
snd_hda_codec 163840  5 
snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek,snd_soc_hdac_hda
dell_laptop28672  0
uvcvideo  114688  0
mac80211  892928  1 ath10k_core
ledtrig_audio  16384  3 
snd_hda_codec_generic,snd_hda_codec_realtek,dell_laptop
snd_hda_core  106496  8 
snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_ext_core,snd_hda_codec,snd_hda_codec_realtek,snd_soc_hdac_hda,snd_soc_skl
videobuf2_vmalloc  20480  1 uvcvideo
kvm   811008  1 kvm_intel
videobuf2_memops   20480  1 videobuf2_vmalloc
snd_hwdep  16384  1 snd_hda_codec
irqbypass  16384  1 kvm
videobuf2_v4l2 28672  1 uvcvideo
intel_cstate   16384  0
videobuf2_common   57344  2 videobuf2_v4l2,uvcvideo
snd_pcm   131072  6 
snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_soc_core,snd_soc_skl,snd_hda_core
dell_smm_hwmon 20480  0
intel_uncore  147456  0
drbg   28672  1
videodev  266240  3 videobuf2_v4l2,uvcvideo,videobuf2_common
dell_wmi   20480  0
intel_rapl_perf16384  0
dell_smbios32768  2 dell_wmi,dell_laptop
efi_pstore 16384  0
ansi_cprng 16384  0
snd_timer  45056  1 snd_pcm
dcdbas 20480  1 dell_smbios
joydev 28672  0
mc 57344  4 
videodev,videobuf2_v4l2,uvcvideo,videobuf2_common
sparse_keymap  16384  1 dell_wmi
cfg80211  864256  3 ath,mac80211,ath10k_core
iTCO_wdt   16384  0
iTCO_vendor_support16384  1 iTCO_wdt
dell_wmi_descriptor20480  2 dell_wmi,dell_smbios
serio_raw  20480  0
snd   106496  10 
snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_compress,snd_soc_core,snd_pcm

Bug#961347: sra-sdk: autopktest failure

[Aaron M. Ucko]

Sebastian Ramacher  writes:

> | 2020-05-22T21:52:08 fastq-load.2.10.6 err: 
> libs/vdb/wtable.c:204:VTableOpenUpdate: schema not found while creating 
> manager within virtual database module - failed to create table with schema 
> NCBI:SRA:Illumina:tbl:phred:v2

Thanks for the report.

FTR, libncbi-vdb2 does already install the schemas; the problem is
getting it to acknowledge our differences from upstream's layout
preferences.  I already saw this failure and am working on a proper fix.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#961394: RM: klone -- RoQA; Orphaned; Upstream Inactive; Low popcon

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-CC: k...@debian.org

Dear Debian FTP Masters,

I believe it doesn't make sense for us to keep src:klone in the archive
anymore.

This package saw no upload since 2008, was orphaned in 
https://bugs.debian.org/646214 in 2011 and saw no upstream activity
since 2014. The popcon value is only 9. Its current packaging is also
hardly meaningful since it only ships docs as well as source code
*tarballs*. Now that no one is maintaining this package, the best
choice should be removing the package.

This email copy is also sent to the original package maintainer.

-- 
Regards,
Boyuan Yang


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

Bug#847442: gnome-software says 'Failed to obtain authentication.'

[Stephen Paul Weber]

Package: gnome-software
Version: 3.30.6-5
Followup-For: Bug #847442

Dear Maintainer,

I believe I have the same issue.  After installing `gnome-software` when I try 
to install anything it does not prompt for password and simply says "you do not 
have permission to install software".

I am not running under a full GNOME environment, but nevertheless policykit and 
packagekit and dbus are running, if that is relevant.

Running gnome-software as root from a terminal works, but using the menu 
launcher does not, and of course if I run it as root then other features are 
not quite right (such as the "launch" button on installed applications).

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

Kernel: Linux 5.4.0-0.bpo.4-amd64 (SMP w/2 CPU cores)
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

Versions of packages gnome-software depends on:
ii  appstream0.12.5-1
ii  apt-config-icons 0.12.5-1
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  gnome-software-common3.30.6-5
ii  gsettings-desktop-schemas3.28.1-1
ii  libappstream-glib8   0.7.14-1
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libfwupd21.2.5-2
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgnome-desktop-3-173.30.2.1-2
ii  libgspell-1-11.6.1-2
ii  libgtk-3-0   3.24.5-1
ii  libgtk3-perl 0.034-2
ii  libgudev-1.0-0   232-2
ii  libjson-glib-1.0-0   1.4.4-2
ii  libpackagekit-glib2-18   1.1.12-5
ii  libpolkit-gobject-1-00.105-25
ii  libsecret-1-00.18.7-1
ii  libsoup2.4-1 2.64.2-2
ii  packagekit   1.1.12-5
ii  software-properties-gtk  0.96.20.2-2

Versions of packages gnome-software recommends:
ii  fwupd  1.2.5-2

Versions of packages gnome-software suggests:
pn  apt-config-icons-hidpi 
pn  gnome-software-plugin-flatpak  
pn  gnome-software-plugin-snap 

-- no debconf information

Bug#950971: fault still exists in testing distribution

[Jan de Kruyf]

hallo,

This is the report I get on a DELL LatitudeE7470:

update-initramfs: Generating /boot/initrd.img-5.6.0-1-amd64
W: Possible missing firmware /lib/firmware/i915/icl_dmc_ver1_09.bin for
module i915
W: Possible missing firmware /lib/firmware/i915/tgl_dmc_ver2_04.bin for
module i915
W: Possible missing firmware /lib/firmware/i915/skl_huc_2.0.0.bin for
module i915
W: Possible missing firmware /lib/firmware/i915/bxt_huc_2.0.0.bin for
module i915
W: Possible missing firmware /lib/firmware/i915/kbl_huc_4.0.0.bin for
module i915
W: Possible missing firmware /lib/firmware/i915/glk_huc_4.0.0.bin for
module i915
W: Possible missing firmware /lib/firmware/i915/kbl_huc_4.0.0.bin for
module i915
W: Possible missing firmware /lib/firmware/i915/cml_huc_4.0.0.bin for
module i915
W: Possible missing firmware /lib/firmware/i915/cml_guc_33.0.0.bin for
module i915
W: Possible missing firmware /lib/firmware/i915/icl_huc_9.0.0.bin for
module i915
W: Possible missing firmware /lib/firmware/i915/ehl_huc_9.0.0.bin for
module i915
W: Possible missing firmware /lib/firmware/i915/ehl_guc_33.0.4.bin for
module i915
W: Possible missing firmware /lib/firmware/i915/tgl_huc_7.0.3.bin for
module i915
W: Possible missing firmware /lib/firmware/i915/tgl_guc_35.2.0.bin for
module i915
I: The initramfs will attempt to resume from /dev/sda4
I: (UUID=b6c95418-424c-4e50-b856-c6c9e9ba6f58)
I: Set the RESUME variable to override this.
jan@snowflake:~$

Please update the firmware.


Regards,

jan de kruyf.

Bug#961393: pulseaudio,elogind: Can't install both

[Matti Palmström]

Package: pulseaudio,elogind
Severity: important
Version: pulseaudio/13.0-5 elogind/241.3-1+debian3

Heya

I was gonna try to install elogind but then aptitude (and apt) wants to
uninstall a lot. After a bit of reading dependencies I realised that you
can't have elogind and pulseaudio at the same time since libpulse0 depends
on libsystemd0. This also make it impossible to use elogind and wine since
wine depends on libpulse0. Would be nice to have the possibility to at
least try out elogind.

Regards
Matti

Bug#953116: [petsc-maint] 32 bit vs 64 bit PETSc

[Drew Parsons]

On 2020-05-23 23:45, Satish Balay wrote:


One more issue: Most externalpackages don't support 64bit-indices.

Note: OpenBLAS supports 64bit indices. MKL has bunch of packages built 
as ILP64


[MPICH/OpenMPI - as far as I know is LP64]


The primary reason PETSc defaults to 32bit indices is - this is the
compiler default on LP64 systems.

If debian is building ILP64 system [with compilers defaulting to
64-bit integers] - that would mean all packages would be ILP64
[obviously most packages are not tested in this mode - so might break]

--with-64-bit-indices is the option for 64-bit-indices on LP64 systems
which most packages don't support - hence the usage of PetscBLASInt
PetscMPIInt etc.

If I remember correctly - the 'full 64-bit' mode relies on fortran 
compiler
option '-i8' - which is basally equivalent to ILP64 - and this mode 
only works

with ILP64 MPI, BLAS etc from Intel-MPI/MKL



If I understand correctly, the Debian systems are LP64 (so gcc defaults 
to int=int32_t).
Our user who started these discussions with Bug#953116 reports that 
--with-64-bit-indices is working fine for his local build. But he may 
not have tested using MUMPS in 64-bit PETSc.



We haven't tried using MUMPS in this mode with PETSc


This will be the interesting test. I'll start with the 64-bit build of 
MUMPS and see how tests hold up.


Drew

Bug#953116: [petsc-maint] 32 bit vs 64 bit PETSc

[Drew Parsons]

On 2020-05-23 20:27, Junchao Zhang wrote:

On Sat, May 23, 2020 at 1:49 AM Drew Parsons 
wrote:


On 2020-05-23 14:18, Jed Brown wrote:


You don't need to change BLAS or MPI.


I see, the PETSc API allows for PetscBLASInt and PetscMPIInt
distinct
from PetscInt. That gives us more flexibility. (In any case, the
Debian
BLAS maintainer is already providing blas64 packages. We've started
discussions about MPI).

But what about MUMPS? Would MUMPS need to be built with 64 bit
support
to work with 64-bit PETSc?
(the MUMPS docs indicate that its 64 bit support needs 64-bit
versions
of BLAS, SCOTCH, METIS and MPI).



 In MUMPS's manual, it is called full 64-bit. Out of the same memory
bandwidth concern, MUMPS also supports selective 64-bit, in a sense it
only uses int64_t for selected variables. One can still use it with
32-bit BLAS, MPI etc.  We support selective 64-bit MUMPS starting from
petsc-3.13.0



Thanks Junchao.  Sounds like we can get started on providing 64-bit 
MUMPS and PETSc without needing to wait for MPI then.

That's good timing with 3.13.

Drew

Bug#961311: ssh-agent.service: cannot work without x11-common installed

[Paul Wise]

Control: severity -1 minor

I consider this bug pretty minor since X11 stuff is going to be
installed for quite some time on Debian's Wayland based desktops, so
don't spend too much effort on this right now.

On Sat, 2020-05-23 at 15:57 +0100, Colin Watson wrote:

> My concern about that is that it's about what's installed, not what's
> active/running for that particular user.  It may not matter in your case
> but I'm sure cutting that corner is going to be wrong for somebody.

Hmm, that is a good point.

I think the main problem here is that the service itself (ssh-agent) is
checking settings (Xsession.options) for the service manager (Xsession)
to see if the service should run instead of the service manager doing
the checking. Ideally it should be the other way around instead.

I noticed that Xsession.d 99x11-common_start exists too and also starts
the ssh-agent when appropriate but I assume Xsession isn't used for the
GNOME X11 session run from gdm on systemd though.

In addition various desktops have their own session service starting
mechanisms, although some are moving to systemd user services.

In addition there is the xdg autostart mechanism and I guess there are
user services started by dbus too.

I'm not sure how to untangle this mess, but I guess the first thing to
be done would be to test on both systemd/sysvinit what happens when
launching different X11/Wayland desktops and window managers from
startx and from different login managers to see exactly when ssh-agent
is launched by Xsession and when by systemd and when there are any race
conditions between the two options. Then you can go through the matrix
of possibilities and find plausible fixes. Since the results will
probably be useful to other Debian folks, perhaps a wiki page of the
results and a thread about them would be useful to Debian too.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#961385: RFS: xine-lib-1.2/1.2.10-2 [QA] -- xine media player library

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "xine-lib-1.2"

 * Package name: xine-lib-1.2
   Version : 1.2.10-2
   Upstream Author :
 * URL : https://xine-project.org/
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/xine-lib-1.2
   Section : libs

It builds those binary packages:

  libxine2   - xine media player library – metapackage
   libxine2-all-plugins - xine video/media player library ‒ metapackage
for all plugins
   libxine2-bin - xine video/media player library – binary files
   libxine2-console - libaa/libcaca/framebuffer/directfb related plugins
for libxine2
   libxine2-dev - xine video player library – development packages
   libxine2-doc - xine video player library – documentation files
   libxine2-ffmpeg - MPEG-related plugins for libxine2
   libxine2-gnome - GNOME-related plugins for libxine2
   libxine2-misc-plugins - Input, audio output and post plugins for libxine2
   libxine2-plugins - xine video/media player library ‒ metapackage for
commonly-used p
   libxine2-vdr - VDR-related plugins for libxine2
   libxine2-x - X desktop video output plugins for libxine2

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

  https://mentors.debian.net/package/xine-lib-1.2

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

  dget -x
https://mentors.debian.net/debian/pool/main/x/xine-lib-1.2/xine-lib-1.2_1.2.10-2.dsc

Changes since the last upload:

   * QA upload.
   * Update year in d/copyright
   * Bump debhelper to 13
 - Remove override_dh_missing
   * Remove xineplug_decode_qt.so from d/libxine2-misc-plugins.install
   * Add 0003-fix-non-Linux-build.patch

My previous release got uploaded earlier today, I noticed it didn't
build on i386 and hurd-i386. This release should fix it.

Regards,
Håvard

Bug#961391: cowdancer: hard links are not copied on write and are changed in the original location

[Norbert Preining]

Hi Jessica,

thanks for the quick response.

> My initial suggestion would be to capture what system call is being
> used using strace. Pick one of the files that changes, and run the

Good idea indeed. We will try to reproduce the failure under strace, and
hope to see something in the log.

Thanks

Norbert

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

Bug#961392: src:varnish: use mktemp instead of tempfile

[Clint Adams]

Package: src:varnish
Version: 6.4.0-2
Tags: patch

tempfile has been deprecated for years.

diff --git a/debian/varnish.init b/debian/varnish.init
index cffd1f978..345118f83 100755
--- a/debian/varnish.init
+++ b/debian/varnish.init
@@ -45,7 +45,7 @@ export PATH="${PATH:+$PATH:}/usr/sbin:/usr/bin:/sbin:/bin"
 
 start_varnishd() {
 log_daemon_msg "Starting $DESC" "$NAME"
-output=$(/bin/tempfile -s.varnish)
+output=$(mktemp --suffix=.varnish)
 if start-stop-daemon \
 --start --quiet --pidfile ${PIDFILE} --exec ${DAEMON} -- \
 -P ${PIDFILE} ${DAEMON_OPTS} > ${output} 2>&1; then
diff --git a/debian/varnish.varnishncsa.init b/debian/varnish.varnishncsa.init
index 1476c1a66..b8177994b 100644
--- a/debian/varnish.varnishncsa.init
+++ b/debian/varnish.varnishncsa.init
@@ -37,7 +37,7 @@ fi
 test -x $DAEMON || exit 0
 
 start_varnishncsa() {
-output=$(/bin/tempfile -s.varnish)
+output=$(mktemp --suffix=.varnish)
 log_daemon_msg "Starting $DESC" "$NAME"
 create_pid_directory
 if start-stop-daemon --start --quiet --pidfile ${PIDFILE} \

Bug#961391: cowdancer: hard links are not copied on write and are changed in the original location

[Jessica Clarke]

On 24 May 2020, at 00:50, Norbert Preining  wrote:
> 
> Package: cowdancer
> Version: 0.88
> Severity: important
> 
> Hi all,
> 
> we use cow-shell on our server to build update and test the TeX Live
> network distribution on a daily basis, but be aware, this is not Debian
> but CentOS. But since cow-shell is useful outside Debian, too, and
> upstream seems to be Debian now, I report this error here.
> 
> We have moved recently to a new server (hardware) while the software
> stack hasn't changed. But we are seeing the following in our setup:
> When the rebuild and test of TL fails, the cow-shell is exited and we
> do not publish the changes, and the source directory should not be
> changed.
> 
> But we see changes in the source directory!
> 
> Basically what we do
>   mkdir target
>   for i in source/* ; do
> cp -al $i target
>   done
>   cow-shell < # do lots of things, updates, tests
> # if it fails exit 1
>   EOF
> Unfortunately, at this point files have changed in "source".
> 
> I have tried to reproduce this with a small example, unsuccessfully.
> OTOH, we can reproduce it with the full TeX Live tlnet directory
> (about 5Gb).
> 
> Is there any way how to debug/test/fix this?

My initial suggestion would be to capture what system call is being
used using strace. Pick one of the files that changes, and run the
entire cow-shell under `strace -o log -f -P target/file`. Hopefully
strace doesn't interfere and it's obvious from the system calls what's
going on...

Jess

Bug#961391: cowdancer: hard links are not copied on write and are changed in the original location

[Norbert Preining]

Package: cowdancer
Version: 0.88
Severity: important

Hi all,

we use cow-shell on our server to build update and test the TeX Live
network distribution on a daily basis, but be aware, this is not Debian
but CentOS. But since cow-shell is useful outside Debian, too, and
upstream seems to be Debian now, I report this error here.

We have moved recently to a new server (hardware) while the software
stack hasn't changed. But we are seeing the following in our setup:
When the rebuild and test of TL fails, the cow-shell is exited and we
do not publish the changes, and the source directory should not be
changed.

But we see changes in the source directory!

Basically what we do
mkdir target
for i in source/* ; do
  cp -al $i target
done
cow-shell <

Bug#960302: [Pkg-roundcube-maintainers] Bug#960302: Bug#960302: imap retry must be tunable

[Guilhem Moulin]

On Sun, 24 May 2020 at 01:34:24 +0200, Sandro Knauß wrote:
> Control: forwarded -1 https://github.com/roundcube/roundcubemail/pull/7402
> […]
> Well I tried several times to reach upstream and they are often not 
> answering. 
> Never the less I created a pull request with an updated version, that does no 
> retry for unrecoverable failures like authentication failure, no password, 
> configuration failure. That should improve the situation already in this 
> issue.

Thanks, Sandro! :-)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#961378: -v causes Temporary failure in name resolution

[Guilhem Moulin]

On Sun, 24 May 2020 at 01:38:14 +0200, Guilhem Moulin wrote:
> That error should probably not be fatal

FTR that's in report_sock().

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#961378: -v causes Temporary failure in name resolution

[Guilhem Moulin]

Control: retitle -1 -v yields fatal name resolution errors
Control: tag -1 upstream

On Sat, 23 May 2020 at 18:33:38 +0800, Dan Jacobson wrote:
> $ nc -v -l -p 60111
> nc: getnameinfo: Temporary failure in name resolution

Do you have a working resolver on that host?  I can't reproduce this
with a working resolver.

$ nc -v -l -p 60111
Listening on 0.0.0.0 60111
 
> and it dies. That's crazy.

That error should probably not be fatal but I don't think it's
especially crazy to have to add `-n` to skip the reverse lookup.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#960302: [Pkg-roundcube-maintainers] Bug#960302: imap retry must be tunable

[Sandro Knauß]

Control: forwarded -1 https://github.com/roundcube/roundcubemail/pull/7402

hey,
 
> Could you please have a look at this regression report?  You authored
> the patch and my PHP-fu is failing me :-P  It should definitely not
> retry the very same incorrect credentials.  Even on systems without
> anti-bruteforce logic that locks the user out, Roundcube still takes 5
> times longer to complain a about a failed login — which is not
> negligible when an expensive PBKDF is used for credential verification.

ACK
 
> I think it's rather unfortunate that
> debian/patches/retry_to_reach_imap_server.patch was AFAICT never submitted
> upstream and landed into stable through -p-u. I dunno whether
> program/lib/Roundcube/rcube_imap.php:connect() has access to the IMAP state
> machine to determine whether a greeting was seen (AFAICT your intention was
> to retry on missing greeting lines, not on NO/BYE greeting conditions let
> alone failed authentication attempts) or to another interface returning
> whether the error is transient or not. Either way it'd be good to have
> upstream's blessing before adopting such patches to Debian :-)

Well I tried several times to reach upstream and they are often not answering. 
Never the less I created a pull request with an updated version, that does no 
retry for unrecoverable failures like authentication failure, no password, 
configuration failure. That should improve the situation already in this issue.

@Matus UHLAR: please try the patch attached to the pull request if this fixes 
your issue:
 https://github.com/roundcube/roundcubemail/pull/7402

Cheers,

hefee

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

Bug#961390: otrs2: Hardcoded font dep ttf-dejavu no longer exists

[Boyuan Yang]

Source: otrs2
Severity: grave
Version: 6.0.28-1
Tags: sid bullseye
X-Debbugs-CC: pmatth...@debian.org tho...@chaschperli.ch

Dear Debian otrs2 maintainers,

As in https://bugs.debian.org/872809 , the following transitional font
packages were removed:

* ttf-dejavu
* ttf-dejavu-core
* ttf-dejavu-extra

Your packages still depend and build-depend on those transitional
packages, which would render your packages uninstallable.

Please note that only replacing the dependencies in debian/control file
is not an option. It looks like the source code of your package is
hardcoding ttf-dejavu in various places. Please consider working on
updating debian-specific patches to fix those occurrences.

-- 
Best Regards,
Boyuan Yang


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

Bug#960539: RFP: hydrogen -- advanced drum machine/step sequencer repackaging

[Nicholas D Steeves]

Hi Alexandre,

Please CC the bug (xyz...@bugs.debian.org) in the future.  I've had to
cut your reply, because we can't release private mail to the public.

I appreciate that you filed an RFS for reintroduction of the package.
When the package is reintroduced I'll open all the old auto-closed bugs;
testing to see if an old bug still exists then that would be another way
to help out.

Current status/progress update: I need to carefully examine upstream
source to see which of the 1000-series patches that failed to rebase can
be dropped.  I'll also have to analyse the package to see if sticking
with CDBS would be for the best, or if we can move it to debhelper at
this time.  Both of these things are a bit advanced, which is why I
didn't leave this work for a newcomer; Increasingly I like to leave work
for newcomers, because it sometimes feels hard to find a place to
contribute.  Anyways, I think real-life testing has equal value to
packaging, so thank you again for your willingness to contribute in
this way! :-)


Cheers,
Nicholas



signature.asc
Description: PGP signature

Bug#961332: gnome-flashback: System indicators (volume, bluetooth, ...) do not appear

[Alberts Muktupāvels]

On Sat, May 23, 2020 at 1:33 PM Timothy Allen  wrote:

> Recently (and I'm afraid I don't have an exact date, although
> I'm pretty user it was the 3.34 → 3.36 upgrade) gnome-flashback's
> standard system indicators (the volume control, Bluetooth,
> the battery charging indicator, etc.) have stopped appearing in the
> notification area. Other indicators (VLC, Network Manager) appear
> just fine, but the system indicators are missing. This is still
> true after logging out and back in, and after rebooting.
>

Mentioned things where turned into gnome-panel applet - System Indicators.

Full disclosure: I normally use gnome-flashback with the i3
> window manager rather than Metacity, according to the instructions in
> https://zork.net/~st/jottings/gnome-i3.html - although the only
> difference between gnome-flashback's stock
> `gnome-flashback-metacity.session`
> file and mine is that I've swapped `metacity` for
> `i3` and removed `gnome-panel`.


There is nothing wrong with session files. GNOME Flashback simply no longer
provides system tray icons.

Nevertheless, the missing system
> indicators are still missing if I log into a standard "GNOME Flashback
> (Metacity)" session rather than my custom one.
>

Existing users needs to add new applet to panel.

-- 
Alberts Muktupāvels

Bug#961313: Thanks! (Was: Bug#961313: pyspread: Fix example in package's tutorial?)

[Kingsley G. Morse Jr.]

Dear Andreas,

Thank you very much!

Sharing your tech skill so quickly and generously
are all fine qualities!

Kind regards,
Kingsley

On 05/23/2020 12:45, Andreas Noteng wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Looks like Pyspread is not correctly rendering the markdown files, the file
> included in the package is the same one that is used by upstream on the web
> page. I have identified the error and will try to make a patch to have the
> files display correctly.
> 
> Andreas
> -BEGIN PGP SIGNATURE-
> Version: FlowCrypt 7.7.7 Gmail Encryption
> Comment: Seamlessly send and receive encrypted email
> 
> wsFcBAEBCgAGBQJeyVMNAAoJELRG7qgympRa50UP/2zbvG+04Zg0tODNLn/4
> oaF2xJyRUqpujGV1bKzEwiDdJ8a4Ef35h9G9LH++gP0ikoYpG1EUnSg6WgU+
> wgkdZuAlxQ00BwScSD9tQe0L2ys/m1kkykM8lyNfMHMIUq2ofeDvm1WBlVMa
> FeJp3KX4xAZRcWjaQUXA4fNxst1RIY0sBB5mS9hT1WiwBzkr47jAeFxQmMHS
> BDhCMMpYz67MWaXcihj5YiO2TBntCIjlrNu+RrSUtTWZ5M40hIY8baB1J1Zs
> zBPFSOpnlJwo5Urwb1MoD/4IQyRZURI5J7DkHv/sH9Wuf4G/Y1g+7uSXFY3x
> AVKMpQSKRi62kkZw6g8K6CqsqxdNaX0b5pNniVEQ1XaBpWNyFxoplKucmqb+
> 5Mxw8XAooV+gxn0vNDCZm9sjXQhpRswqsjG3PJNE1jxHHEqe/47dmrll9aVb
> 4yGaX5X5LnwB2cVILbLe6SARBnp758hRTJuT9i5YCikj8kc99oEuXOaq48nc
> IzLSs9hHKvOzQkbOMo6MLjZG/xlmlL2KuFXH3JFWvQ33UPWmbw8/cWPyyPES
> Je/4DjU5F/QUmuuhMkXzNUtsRSoCwb/j1qaG8QVcoA23LCoydPIwJdmLfZMF
> /KxltD9TLEnVM7oNczOBA7LCnZjw/pz24wPsxGy8/0xsOnf5hJL7E4Fe8HMO
> BgZt
> =1tua
> -END PGP SIGNATURE-

-- 
Time is the fire in which we all burn.

Bug#961263: nvidia-cuda-dev: File collision

[Andreas Beckmann]

Control: severity -1 serious

On 22/05/2020 11.21, Tristan Seligmann wrote:
> dpkg: error processing archive 
> /var/cache/apt/archives/nvidia-cuda-dev_10.1.168-10_amd64.deb (--unpack):
>  trying to overwrite '/usr/include/ansidecl.h', which is also in package 
> binutils-dev 2.34-8

These sneaked in from building cuda-gdb from source:

Files in second .deb but not in first
-
-rw-r--r--  root/root   /usr/include/ansidecl.h
-rw-r--r--  root/root   /usr/include/bfd.h
-rw-r--r--  root/root   /usr/include/bfdlink.h
-rw-r--r--  root/root   /usr/include/dis-asm.h
-rw-r--r--  root/root   /usr/include/plugin-api.h
-rw-r--r--  root/root   /usr/include/symcat.h

Andreas

Bug#961363: slirp4netns - Fails on Linux 5.5: enable_seccomp failed

[Reinhard Tartler]

On 5/23/20 5:03 PM, Bastian Blank wrote:
> Hi Reinhard
> 
> On Sat, May 23, 2020 at 04:09:42PM -0400, Reinhard Tartler wrote:
>> Can you please elaborate on your use-case and ideally demonstrate with a 
>> minimal testcase? - What kind of namespaces are shared/unshared? The 
>> command-line looks like it was generated by some other proram. Please 
>> elaborate.
> 
> In the meantime I found out that it works in some cases.
> 
> I today tried some new stuff:
> - podman (https://github.com/containers/libpod)
> - usernetes (https://github.com/rootless-containers/usernetes)
> 
> With podman slirp4netns broke with the mentioned error.  With
> rootlesskit, used by usernetes, it seems to work.  Let's see if I manage
> to look again.

Are you using the packaged podman that we have in Debian since a couple of days 
now, or did you compile yourself?
The packaged version does work just fine for me with slirp4netns.

I didn't have the chance to look at usernetes yet.

In any case, please do file a ticket upstream and please cc me to get some 
clarification from upstream.

Best,
-rt

Bug#961389: fonts-dejavu-core: unannounced change of default config breaks user configuration

[Vincent Lefevre]

Package: fonts-dejavu-core
Version: 2.37-2
Severity: normal

Since the upgrade to 2.37-2, box drawing and underline characters
no longer work in Emacs with my configuration. I could check that
this is because Bitstream Vera Sans Mono (which is very incomplete)
is used as the primary font instead of DejaVu Sans Mono: Since I'm
currently using generic names, I suppose that this is due to

  * Apply upstream commit to remove redundant generic name assignment
and aliasing from fontconfig configuration. Thanks Jan Niklas
Hasse, Closes: #753401.

Before the upgrade:

cventin% fc-match Mono
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"
cventin% fc-match Monospace
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"

After the upgrade:

zira% fc-match Mono
VeraMono.ttf: "Bitstream Vera Sans Mono" "Roman"
zira% fc-match Monospace
VeraMono.ttf: "Bitstream Vera Sans Mono" "Roman"

I've reported the following bug against fontconfig-config concerning
this poor choice:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961386

I think that the issue should have first been fixed there before
changing fonts-dejavu.

Anyway, since the change affects user config that uses generic names,
it should be announced in NEWS.Debian.

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

-- no debconf information

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

Bug#961388: Evolution reports "Error performing TLS handshake: Internal error in memory allocation" with Yahoo! IMAPX

[bigiu...@gmail.com]

Package: evolution
Version: 3.22.6-1+deb9u2
Severity: normal

Dear Maintainer,

   * What led up to the situation?
Starting approximately beginning of May, my previously working Yahoo! IMAPX 
Evolution email account
started complaining as per the message in the Subject

   * What exactly did you do (or not do) that was effective (or
 ineffective) and what was the outcome of this action?
I've tried the same conf with fresh vanilla 
**debian-live-9.12.0-amd64-gnome+nonfree.iso** getting
exactly the same message

   * What outcome did you expect instead?
Furthermore, I've tried the same conf with fresh vanilla 
**debian-live-10.4.0-amd64-
gnome+nonfree.iso** getting rid of it (it works)


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

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

Versions of packages evolution depends on:
ii  dbus   1.10.28-0+deb9u1
ii  evolution-common   3.22.6-1+deb9u2
ii  evolution-data-server  3.22.7-1
ii  libc6  2.24-11+deb9u4
ii  libcamel-1.2-593.22.7-1
ii  libclutter-gtk-1.0-0   1.8.2-2
ii  libecal-1.2-19 3.22.7-1
ii  libedataserver-1.2-22  3.22.7-1
ii  libevolution   3.22.6-1+deb9u2
ii  libglib2.0-0   2.50.3-2+deb9u2
ii  libgtk-3-0 3.22.11-1
ii  libical2   2.0.0-0.5+b1
ii  libicu57   57.1-6+deb9u4
ii  libnotify4 0.7.7-2
ii  libsoup2.4-1   2.56.0-2+deb9u2
ii  libwebkit2gtk-4.0-37   2.18.6-1~deb9u1.0
ii  libxml22.9.4+dfsg1-2.2+deb9u2
ii  psmisc 22.21-2.1+b2

Versions of packages evolution recommends:
ii  bogofilter 1.2.4+dfsg1-9
ii  evolution-plugins  3.22.6-1+deb9u2
ii  spamassassin   3.4.2-1~deb9u3
ii  yelp   3.22.0-1

Versions of packages evolution suggests:
ii  evolution-ews   3.22.6-1
ii  evolution-plugins-experimental  3.22.6-1+deb9u2
ii  gnupg   2.1.18-8~deb9u4
ii  network-manager 1.6.2-3+deb9u2

Bug#961363: slirp4netns - Fails on Linux 5.5: enable_seccomp failed

[Bastian Blank]

Hi Reinhard

On Sat, May 23, 2020 at 04:09:42PM -0400, Reinhard Tartler wrote:
> Can you please elaborate on your use-case and ideally demonstrate with a 
> minimal testcase? - What kind of namespaces are shared/unshared? The 
> command-line looks like it was generated by some other proram. Please 
> elaborate.

In the meantime I found out that it works in some cases.

I today tried some new stuff:
- podman (https://github.com/containers/libpod)
- usernetes (https://github.com/rootless-containers/usernetes)

With podman slirp4netns broke with the mentioned error.  With
rootlesskit, used by usernetes, it seems to work.  Let's see if I manage
to look again.

Bastian

-- 
Men will always be men -- no matter where they are.
-- Harry Mudd, "Mudd's Women", stardate 1329.8

Bug#961387: FTBFS due to usage of array::into_iter()

[Logan Rosen]

Source: rust-ring
Version: 0.16.9-3
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu groovy ubuntu-patch

Hi,

rust-ring currently FTBFS due to usage of array::into_iter() instead of
array::iter(). See build log: 
https://buildd.debian.org/status/fetch.php?pkg=rust-ring=amd64=0.16.9-3=1587387625=0

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

  * d/p/use-array-iter.patch: Cherrypick upstream commit to use array::iter,
fixing FTBFS.

Thanks for considering the patch.

Logan
diff -Nru rust-ring-0.16.9/debian/patches/series 
rust-ring-0.16.9/debian/patches/series
--- rust-ring-0.16.9/debian/patches/series  2020-04-20 08:16:05.0 
-0400
+++ rust-ring-0.16.9/debian/patches/series  2020-05-23 17:01:04.0 
-0400
@@ -1,2 +1,3 @@
 relax-deps.patch
 built-using.patch
+use-array-iter.patch
diff -Nru rust-ring-0.16.9/debian/patches/use-array-iter.patch 
rust-ring-0.16.9/debian/patches/use-array-iter.patch
--- rust-ring-0.16.9/debian/patches/use-array-iter.patch1969-12-31 
19:00:00.0 -0500
+++ rust-ring-0.16.9/debian/patches/use-array-iter.patch2020-05-23 
17:00:40.0 -0400
@@ -0,0 +1,23 @@
+From c250e3125e2621cbe947e811e3de0fc5fa1904aa Mon Sep 17 00:00:00 2001
+From: lzutao 
+Date: Wed, 30 Oct 2019 14:51:17 +0700
+Subject: [PATCH] Use array::iter
+
+See clippy::into_iter lint and https://github.com/rust-lang/rust/pull/65819
+---
+ build.rs | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/build.rs b/build.rs
+index c6cb3a700..f7eded9de 100644
+--- a/build.rs
 b/build.rs
+@@ -418,7 +418,7 @@ fn build_c_code(target: , pregenerated: PathBuf, 
out_dir: ) {
+ 
+ // XXX: Ideally, ring-test would only be built for `cargo test`, but Cargo
+ // can't do that yet.
+-libs.into_iter()
++libs.iter()
+ .for_each(|&(lib_name, srcs, additional_srcs)| {
+ build_library(
+ ,

Bug#960777: libmail-dkim-perl: Argument "1.20200513.1" isn't numeric

[Bob Proulx]

Elimar Riesebieter wrote:
> Argument "1.20200513.1" isn't numeric in numeric ge (>=) at 
> /usr/share/perl5/Mail/SpamAssassin/Plugin/DKIM.pm line 686
> Argument "1.20200513.1" isn't numeric in numeric ge (>=) at 
> /usr/share/perl5/Mail/SpamAssassin/Plugin/DKIM.pm line 809.

In order to silence the errors and to hopefully work correctly while
waiting for an upstream bug fix I have made the following local hacks
on my system.  Perhaps this will be useful to others too.

--- /var/tmp/DKIM.pm.orig 2020-01-18 01:44:49.0 -0700
+++ /usr/share/perl5/Mail/SpamAssassin/Plugin/DKIM.pm 2020-05-23 
13:52:41.345815168 -0600
@@ -128,6 +128,7 @@
 use Mail::SpamAssassin::Logger;
 use Mail::SpamAssassin::Timeout;
 
+use version;
 use strict;
 use warnings;
 # use bytes;
@@ -682,8 +683,8 @@
   dbg("dkim: cannot load Mail::DKIM module, DKIM checks disabled: %s",
   $eval_stat);
 } else {
-  my $version = Mail::DKIM::Verifier->VERSION;
-  if ($version >= 0.31) {
+  my $version = version->parse(Mail::DKIM::Verifier->VERSION);
+  if ($version >= version->parse("0.31")) {
 dbg("dkim: using Mail::DKIM version $version");
   } else {
 info("dkim: Mail::DKIM $version is older than the required ".
@@ -806,7 +807,7 @@
 # signature objects not provided by the caller, must verify for ourselves
 my $timemethod = $self->{main}->UNIVERSAL::can("time_method") &&
  $self->{main}->time_method("check_dkim_signature");
-if (Mail::DKIM::Verifier->VERSION >= 0.40) {
+if (version->parse(Mail::DKIM::Verifier->VERSION) >= 
version->parse("0.40")) {
   my $edns = $conf->{dns_options}->{edns};
   if ($edns && $edns >= 1024) {
 # Let Mail::DKIM use our interface to Net::DNS::Resolver.

Bob

Bug#961386: fontconfig-config: 60-latin.conf should prefer the most complete font DejaVu

[Vincent Lefevre]

Package: fontconfig-config
Version: 2.13.1-4.2
Severity: normal

Since fonts-dejavu 2.37-2, 60-latin.conf is no longer overridden
by the default fonts-dejavu-core configuration. As a consequence,
Bitstream Vera is preferred to DejaVu, e.g. for monospace:


monospace

Bitstream Vera Sans Mono
DejaVu Sans Mono
Inconsolata
Andale Mono
Courier New
Cumberland AMT
Luxi Mono
Nimbus Mono L
Nimbus Mono
Nimbus Mono PS
Courier



This is an issue since Bitstream Vera is very incomplete, at least
compared to DejaVu.

In particular, Bitstream Vera Sans Mono does not have box drawing
characters and this breaks box drawing in Emacs when one uses a
generic font name (thus hoping to get the best font).

-- 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 fontconfig-config depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  fonts-croscore 20200323-1
ii  fonts-dejavu-core  2.37-2
ii  fonts-freefont-otf 20120503-10
ii  fonts-freefont-ttf 20120503-10
ii  fonts-liberation   1:1.07.4-11
ii  fonts-liberation2  2.1.0-1
ii  fonts-texgyre  20180621-3
ii  fonts-urw-base35   20170801.1-3
ii  ttf-bitstream-vera 1.10-8
ii  ucf3.0042

fontconfig-config recommends no packages.

fontconfig-config suggests no packages.

-- debconf information:
* fontconfig/hinting_style: hintslight
* fontconfig/enable_bitmaps: false
* fontconfig/subpixel_rendering: Automatic
* fontconfig/hinting_type: Native

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

Bug#887534: plume-creator FTBFS with libquazip5-headers 0.7.3-3

[Adrian Bunk]

On Sat, May 23, 2020 at 08:08:44PM +0100, Sudip Mukherjee wrote:
> On Sat, May 23, 2020 at 07:51:52PM +0300, Adrian Bunk wrote:
> > Control: tags 960678 moreinfo
> > Control: tags 887534 - patch
> > 
> > On Fri, Apr 24, 2020 at 08:31:31PM +0100, Sudip Mukherjee wrote:
> > > This error is not reproducible any more
> > >...
> > 
> > It is still there, both for me locally and in reproducible:
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/plume-creator.html
> 
> Thats odd. It was not there when I made the last package.
> 
> Anyways, I have now uploaded new package to mentors. And attached the new 
> diff.

Thanks, uploaded to DELAYED/2.

> Regards
> Sudip

cu
Adrian

Bug#961122: 1.5.0.87+dfsg1-1 is out of the way already

[Julien Puydt]

Le samedi 23 mai 2020 à 22:37 +0300, Adrian Bunk a écrit :
> On Fri, May 22, 2020 at 04:13:02PM +0200, Julien Puydt wrote:
> > I don't understand why you report a bug on 1.5.0.87+dfsg1-1 on the
> > 20th
> > of may when testing has 1.5.0.87+dfsg1-4 since the 9th of march,
> > and
> > unstable had it since the 4th of march.
> 
> The version should indicate the earliest known-broken version.
> 
> > Isn't the problem history already?
> 
> 1.5.0.87+dfsg1-4+b1 built only at the second attempt,
> the bug is still in unstable.
> 
> armhf build failures are also frequent in the reproducible CI:
> https://tests.reproducible-builds.org/debian/history/giac.html
> 

I was sure everything was green - and obviously I was wrong : I'll
investigate again.

Thanks!

JP

Bug#961384: asciidoctor: manpage links in a manpage are rendered in a weird way

[Christoph Biedl]

Package: asciidoctor
Version: 2.0.10-2
Severity: normal
Tags: upstream

Dear Maintainer,

ASCIIPATIENT(1)
===

NAME

asciipatient - manpage links in a manpage are rendered in a weird way


DESCRIPTION
---

Observed in one of the packages I maintain: The links to other manpages
in the adoc provided by upstream are rendered in a unsual and
irritating way.

It is possible upstream did a bad job here - but all I can tell is
using the old a2x yields a sound result. In case this is just bad
adoc style - I could use a pointer to the documentation where this is
described. Read: While asciidoctor has a lot of documentation, I
constantly fail to find the bits I need to got something done.


HOW TO REPEAT
-

Run this document through "asciidoctor --backend manpage", then execute
"man ./asciipatient.1". Compare with the result of "a2x -f manpage".


SEE ALSO


link:asciidoctor.1.adoc[*asciidoctor*(1)]


EXPECTED



SEE ALSO
   asciidoctor(1)



GOT
---


SEE ALSO
   asciidoctor(1) 



signature.asc
Description: PGP signature

Bug#961383: libxc builds with -march=native on most architectures

[Adrian Bunk]

Source: libxc
Version: 4.2.3-3
Severity: serious

libxc builds with -march=native on most architectures,
this makes the code only run on hardware that is compatible
with whatever buildd built the package.

Bug#961363: slirp4netns - Fails on Linux 5.5: enable_seccomp failed

[Reinhard Tartler]

Control: severity -1 normap
Control: tag -1 upstream moreinfo

Hello Bastian,

thanks for reporting this issue:

On 5/23/20 11:46 AM, Bastian Blank wrote:
> Package: slirp4netns
> Version: 1.0.1-1
> Severity: important
> 
> slirp4netns fails with the following command line:
> | /usr/bin/slirp4netns --disable-host-loopback --mtu 65520 --enable-sandbox 
> --enable-seccomp -c -e 3 -r 4 --netns-type=path 
> /run/user/1000/netns/cni-b5f1fc5... tap0
> 
> Excerpt from strace output:
> 
> | prctl(PR_CAPBSET_DROP, CAP_BLOCK_SUSPEND) = 0
> | prctl(PR_CAPBSET_DROP, CAP_AUDIT_READ)  = 0
> | prctl(PR_CAPBSET_DROP, 0x26 /* CAP_??? */) = -1 EINVAL (Invalid argument)
> | capset({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, 
> {effective=1< inheritable=1< | write(2, "enable_seccomp failed\n", 22) = 22


I note that --enable-seccomp is (still) marked as experimental.

Also, I'm having difficulties with reproducing this issue. Here is the test 
case that I tried:

siretart@x1:/tmp$ unshare -rn
root@x1:/tmp# uname -a
Linux x1 5.6.0-1-amd64 #1 SMP Debian 5.6.7-1 (2020-04-29) x86_64 GNU/Linux
root@x1:/tmp# /usr/bin/slirp4netns --disable-host-loopback --mtu 65520 
--enable-sandbox --enable-seccomp -c  $$ tap0
WARNING: Support for seccomp is experimental
sent tapfd=5 for tap0
received tapfd=5
Starting slirp
* MTU: 65520
* Network: 10.0.2.0
* Netmask: 255.255.255.0
* Gateway: 10.0.2.2
* DNS: 10.0.2.3
* Recommended IP:  10.0.2.100
seccomp: The following syscalls will be blocked by seccomp: execve execveat 
open_by_handle_at ptrace prctl process_vm_readv process_vm_writev mount 
name_to_handle_at setns umount umount2 unshare.


So enabling seccomp as is seems to work on kernel 5.5. However, your 
command-line doesn't work for me directly, I fail to reproduce the "prctl" and 
"capset" syscall from your example.

Can you please elaborate on your use-case and ideally demonstrate with a 
minimal testcase? - What kind of namespaces are shared/unshared? The 
command-line looks like it was generated by some other proram. Please elaborate.

Also, may I suggest that you report this issue upstream at 
https://github.com/rootless-containers/slirp4netns/issues/new/choose so that 
upstream can assist you more efficiently?
Your report does look similar to 
https://github.com/rootless-containers/slirp4netns/issues/196, but I'm not sure.

Bug#961382: hyphy: baseline violation on amd64/i386

[Adrian Bunk]

Source: hyphy
Version: 2.2.7+dfsg-1
Severity: serious

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

That package in stretch and buster builds with -msse3
for no apparent reason.

The package in unstable/testing is built with
"-march=native -mtune=native -mavx  -mfma".

Bug#961299: Acknowledgement (FTBFS: debhelper compatibility level 12 breaks linux kernel build on hppa/parisc)

[Helge Deller]

It turns out, that changing
dh_strip --no-automatic-dbgsym -Xvmlinux
to
dh_strip --no-automatic-dbgsym -Xvmlinux -Xvmlinuz
in debian/rules.real fixes the build.

I added some tracing code and this shows that in former compat level 9,
the strip command is never executed on the vmlinuz file, while with
compat level 12, strip is now executed like this and thus fails:

strip --remove-section=.comment --remove-section=.note --strip-unneeded 
debian/linux-image-5.6.0-1-parisc64/boot/vmlinuz-5.6.0-1-parisc64
strip: debian/linux-image-5.6.0-1-parisc64/boot/vmlinuz-5.6.0-1-parisc64: file 
format not recognized
dh_strip: error: strip --remove-section=.comment --remove-section=.note 
--strip-unneeded 
debian/linux-image-5.6.0-1-parisc64/boot/vmlinuz-5.6.0-1-parisc64 returned exit 
code 1

Any chance we can add "-Xvmlinuz" to the dh_strip command in rules.real?

Bug#953116: [petsc-maint] 32 bit vs 64 bit PETSc

[Satish Balay]

On Sat, 23 May 2020, Junchao Zhang wrote:

> On Sat, May 23, 2020 at 1:49 AM Drew Parsons  wrote:
> 
> > On 2020-05-23 14:18, Jed Brown wrote:
> > > Drew Parsons  writes:
> > >
> > >> Hi, the Debian project is discussing whether we should start providing
> > >> a
> > >> 64 bit build of PETSc (which means we'd have to upgrade our entire
> > >> computational library stack, starting from BLAS and going through MPI,
> > >> MUMPS, etc).
> > >
> > > You don't need to change BLAS or MPI.
> >
> > I see, the PETSc API allows for PetscBLASInt and PetscMPIInt distinct
> > from PetscInt. That gives us more flexibility. (In any case, the Debian
> > BLAS maintainer is already providing blas64 packages. We've started
> > discussions about MPI).
> >
> > But what about MUMPS? Would MUMPS need to be built with 64 bit support
> > to work with 64-bit PETSc?
> > (the MUMPS docs indicate that its 64 bit support needs 64-bit versions
> > of BLAS, SCOTCH, METIS and MPI).
> >
> In MUMPS's manual, it is called full 64-bit. Out of the same memory
> bandwidth concern, MUMPS also supports selective 64-bit, in a sense it only
> uses int64_t for selected variables. One can still use it with 32-bit BLAS,
> MPI etc.  We support selective 64-bit MUMPS starting from petsc-3.13.0

If I remember correctly - the 'full 64-bit' mode relies on fortran compiler 
option '-i8' - which is basally equivalent to ILP64 - and this mode only works
with ILP64 MPI, BLAS etc from Intel-MPI/MKL

We haven't tried using MUMPS in this mode with PETSc

Satish

> 
> 
> >
> >
> > >> A default PETSc build uses 32 bit addressing to index vectors and
> > >> matrices.  64 bit addressing can be switched on by configuring with
> > >> --with-64-bit-indices=1, allowing much larger systems to be handled.
> > >>
> > >> My question for petsc-maint is, is there a reason why 64 bit indexing
> > >> is
> > >> not already activated by default on 64-bit systems?  Certainly C
> > >> pointers and type int would already be 64 bit on these systems.
> > >
> > > Umm, x86-64 Linux is LP64, so int is 32-bit.  ILP64 is relatively
> > > exotic
> > > these days.
> >
> >
> > oh ok. I had assumed int was 64 bit on x86-64. Thanks for the
> > correction.
> >
> >
> > >> Is it a question of performance?  Is 32 bit indexing executed faster
> > >> (in
> > >> the sense of 2 operations per clock cycle), such that 64-bit
> > >> addressing
> > >> is accompanied with a drop in performance?
> > >
> > > Sparse iterative solvers are entirely limited by memory bandwidth;
> > > sizeof(double) + sizeof(int64_t) = 16 incurs a performance hit relative
> > > to 12 for int32_t.  It has nothing to do with clock cycles for
> > > instructions, just memory bandwidth (and usage, but that is less often
> > > an issue).
> > >
> > >> In that case we'd only want to use 64-bit PETSc if the system being
> > >> modelled is large enough to actually need it. Or is there a different
> > >> reason that 64 bit indexing is not switched on by default?
> > >
> > > It's just about performance, as above.
> >
> >
> > Thanks Jed.  That's good justification for us to keep our current 32-bit
> > built then, and provide a separate 64-bit build alongside it.
> >
> >
> > >  There are two situations in
> > > which 64-bit is needed.  Historically (supercomputing with thinner
> > > nodes), it has been that you're solving problems with more than 2B
> > > dofs.
> > > In today's age of fat nodes, it also happens that a matrix on a single
> > > MPI rank has more than 2B nonzeros.  This is especially common when
> > > using direct solvers.  We'd like to address the latter case by only
> > > promoting the row offsets (thereby avoiding the memory hit of promoting
> > > column indices):
> > >
> > > https://gitlab.com/petsc/petsc/-/issues/333
> >
> > An interesting extra challenge.
> >
> >
> > > I wonder if you are aware of any static analysis tools that can
> > > flag implicit conversions of this sort:
> > >
> > > int64_t n = ...;
> > > for (int32_t i=0; i > >   ...
> > > }
> > >
> > > There is -fsanitize=signed-integer-overflow (which generates a runtime
> > > error message), but that requires data to cause overflow at every
> > > possible location.
> >
> > I'll ask the Debian gcc team and the Science team if they have ideas
> > about this.
> >
> > Drew
> >
> 

Bug#953116: [petsc-maint] 32 bit vs 64 bit PETSc

[Satish Balay]

On Sat, 23 May 2020, Drew Parsons wrote:

> On 2020-05-23 14:18, Jed Brown wrote:
> > Drew Parsons  writes:
> > 
> >> Hi, the Debian project is discussing whether we should start providing a
> >> 64 bit build of PETSc (which means we'd have to upgrade our entire
> >> computational library stack, starting from BLAS and going through MPI,
> >> MUMPS, etc).
> > 
> > You don't need to change BLAS or MPI.
> 
> I see, the PETSc API allows for PetscBLASInt and PetscMPIInt distinct from
> PetscInt. That gives us more flexibility. (In any case, the Debian BLAS
> maintainer is already providing blas64 packages. We've started discussions
> about MPI).
> 
> But what about MUMPS? Would MUMPS need to be built with 64 bit support to work
> with 64-bit PETSc?
> (the MUMPS docs indicate that its 64 bit support needs 64-bit versions of
> BLAS, SCOTCH, METIS and MPI).
> 
> 
> 
> >> A default PETSc build uses 32 bit addressing to index vectors and
> >> matrices.  64 bit addressing can be switched on by configuring with
> >> --with-64-bit-indices=1, allowing much larger systems to be handled.
> >> 
> >> My question for petsc-maint is, is there a reason why 64 bit indexing is
> >> not already activated by default on 64-bit systems?  Certainly C
> >> pointers and type int would already be 64 bit on these systems.
> > 
> > Umm, x86-64 Linux is LP64, so int is 32-bit.  ILP64 is relatively exotic
> > these days.
> 
> 
> oh ok. I had assumed int was 64 bit on x86-64. Thanks for the correction.
> 
> 
> >> Is it a question of performance?  Is 32 bit indexing executed faster (in
> >> the sense of 2 operations per clock cycle), such that 64-bit addressing
> >> is accompanied with a drop in performance?
> > 
> > Sparse iterative solvers are entirely limited by memory bandwidth;
> > sizeof(double) + sizeof(int64_t) = 16 incurs a performance hit relative
> > to 12 for int32_t.  It has nothing to do with clock cycles for
> > instructions, just memory bandwidth (and usage, but that is less often
> > an issue).
> > 
> >> In that case we'd only want to use 64-bit PETSc if the system being
> >> modelled is large enough to actually need it. Or is there a different
> >> reason that 64 bit indexing is not switched on by default?
> > 
> > It's just about performance, as above.
> 
> 
> Thanks Jed.  That's good justification for us to keep our current 32-bit built
> then, and provide a separate 64-bit build alongside it.

One more issue: Most externalpackages don't support 64bit-indices.

Note: OpenBLAS supports 64bit indices. MKL has bunch of packages built as ILP64

[MPICH/OpenMPI - as far as I know is LP64]


The primary reason PETSc defaults to 32bit indices is - this is the compiler 
default on LP64 systems.

If debian is building ILP64 system [with compilers defaulting to 64-bit 
integers] - that would mean all packages would be ILP64 [obviously most 
packages are not tested in this mode - so might break]

--with-64-bit-indices is the option for 64-bit-indices on LP64 systems which 
most packages don't support - hence the usage of PetscBLASInt PetscMPIInt etc.

Satish

> 
> 
> > There are two situations in
> > which 64-bit is needed.  Historically (supercomputing with thinner
> > nodes), it has been that you're solving problems with more than 2B dofs.
> > In today's age of fat nodes, it also happens that a matrix on a single
> > MPI rank has more than 2B nonzeros.  This is especially common when
> > using direct solvers.  We'd like to address the latter case by only
> > promoting the row offsets (thereby avoiding the memory hit of promoting
> > column indices):
> > 
> > https://gitlab.com/petsc/petsc/-/issues/333
> 
> An interesting extra challenge.
> 
> 
> > I wonder if you are aware of any static analysis tools that can
> > flag implicit conversions of this sort:
> > 
> > int64_t n = ...;
> > for (int32_t i=0; i >   ...
> > }
> > 
> > There is -fsanitize=signed-integer-overflow (which generates a runtime
> > error message), but that requires data to cause overflow at every
> > possible location.
> 
> I'll ask the Debian gcc team and the Science team if they have ideas about
> this.
> 
> Drew
> 

Bug#961381: gsutil: autopkgtest failure: Can't locate LWP/UserAgent.pm in @INC

[Paul Gevers]

Source: gsutil
Version: 3.1-3
X-Debbugs-CC: debian...@lists.debian.org, leandrora...@debxp.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package gsutil, great.
However, it fails. Currently this failure is blocking the migration to
testing [1]. Can you please investigate the situation and fix it?

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

[Release manager hat on] You'll also have to mark the tests as
"superficial" as the amount of what this tests is really minimal.

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=gsutil

https://ci.debian.net/data/autopkgtest/testing/amd64/g/gsutil/5507692/log.gz

autopkgtest [03:19:01]: test command1: gsutil --version | grep -i version
autopkgtest [03:19:01]: test command1: [---
Can't locate LWP/UserAgent.pm in @INC (you may need to install the
LWP::UserAgent module) (@INC contains: /etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.30.0 /usr/local/share/perl/5.30.0
/usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5
/usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at
/usr/bin/gsutil line 26.
BEGIN failed--compilation aborted at /usr/bin/gsutil line 26.
autopkgtest [03:19:02]: test command1: ---]





signature.asc
Description: OpenPGP digital signature

Bug#957140: dlt-daemon: ftbfs with GCC-10

[Gianfranco Costamagna]

hello, this
https://github.com/GENIVI/dlt-daemon/pull/228/files

might be a patch for it
(it builds, but I'm not sure if it also works or not)

G.

Bug#810865: another stakeholder

[Geert Stappers]

Hi,

During a Linux User Group meeting came along auto start Gobby server.

Using the  systemd unit from 2020-03-28 learn me
that it's need more TLC.

On "stretch" system,  logging of three starts:
stappers@jerom:~$ journalctl -u infinoted | cat -
-- Logs begin at Wed 2020-05-20 15:45:36 UTC, end at Wed 2020-05-20
20:45:05 UTC. --
May 20 19:46:36 jerom systemd[1]: [/etc/systemd/system/infinoted.service:10] 
Unknown lvalue 'ConfigurationDirectory' in section 'Service'
May 20 19:46:36 jerom systemd[1]: [/etc/systemd/system/infinoted.service:11] 
Unknown lvalue 'ConfigurationDirectoryMode' in section 'Service'
May 20 19:46:36 jerom systemd[1]: [/etc/systemd/system/infinoted.service:12] 
Unknown lvalue 'LockPersonality' in section 'Service'
May 20 19:46:36 jerom systemd[1]: [/etc/systemd/system/infinoted.service:15] 
Unknown lvalue 'PrivateMounts' in section 'Service'
May 20 19:46:36 jerom systemd[1]: [/etc/systemd/system/infinoted.service:19] 
Unknown lvalue 'ProtectKernelLogs' in section 'Service'
May 20 19:46:36 jerom systemd[1]: [/etc/systemd/system/infinoted.service:25] 
Unknown lvalue 'StateDirectory' in section 'Service'
May 20 19:50:46 jerom systemd[1]: Started collaborative text editor service.
May 20 19:50:46 jerom systemd[1]: infinoted.service: Main process exited, 
code=exited, status=217/USER
May 20 19:50:46 jerom systemd[1]: infinoted.service: Unit entered failed state.
May 20 19:50:46 jerom systemd[1]: infinoted.service: Failed with result 
'exit-code'.
May 20 19:56:11 jerom systemd[1]: Started collaborative text editor service.
May 20 19:56:11 jerom infinoted[9432]: No private key file given. \
If you don't have a suitable key file, either create one using the 
--create-key command line argument,
or disable TLS by setting the security policy to "no-tls".
May 20 19:56:11 jerom systemd[1]: infinoted.service: Main process exited, 
code=exited, status=255/n/a
May 20 19:56:11 jerom systemd[1]: infinoted.service: Unit entered failed state.
May 20 19:56:11 jerom systemd[1]: infinoted.service: Failed with result 
'exit-code'.
stappers@jerom:~$


To be continued


Regards
Geert Stappers
DD
-- 
Silence is hard to parse

Bug#961380: guitarix: baseline violation on i386

[Adrian Bunk]

Source: guitarix
Version: 0.31.0-1
Severity: serious

https://buildd.debian.org/status/logs.php?pkg=guitarix=i386

...
17:16:04 runner ['/usr/bin/g++', '-g', '-O2', 
'-fdebug-prefix-map=/<>=.', '-fstack-protector-strong', 
'-Wformat', '-Werror=format-security', '-g', '-O2', 
'-fdebug-prefix-map=/<>=.', '-fstack-protector-strong', 
'-Wformat', '-Werror=format-security', '-Wdate-time', '-D_FORTIFY_SOURCE=2', 
'-O3', '-DNDEBUG', '-D_FILE_OFFSET_BITS=64', '-std=c++11', '-msse2', 
'-mfpmath=sse', '-fPIC', '-Isrc/LV2/faust', '-I../src/LV2/faust', 
'-Isrc/LV2/gx_amp.lv2', '-I../src/LV2/gx_amp.lv2', '-Isrc/LV2/DSP', 
'-I../src/LV2/DSP', '-Isrc/LV2/DSP/tube_tables', 
'-I../src/LV2/DSP/tube_tables', '-I/usr/include/glibmm-2.4', 
'-I/usr/lib/i386-linux-gnu/glibmm-2.4/include', '-I/usr/include/glib-2.0', 
'-I/usr/lib/i386-linux-gnu/glib-2.0/include', '-I/usr/include/sigc++-2.0', 
'-I/usr/lib/i386-linux-gnu/sigc++-2.0/include', '-DIS_LINUX="linux"', 
'-DGETTEXT_PACKAGE="guitarix"', '-DENABLE_NLS=1', '-DHAVE_SNDFILE=1', 
'-DHAVE_GTHREAD=1', '-DHAVE_GLIBMM=1', '-DHAVE_FFTW3_H=1', '-DHAVE_FFTW3=1', 
'-DHAVE_JACK=1', '-DHAVE_JACK_SESSION=1', '-DHAVE_GMODULE_EXPORT=1', 
'-DHAVE_CURL=1', '-DHAVE_GTK2=1', '-DHAVE_GTKMM=1', '-DHAVE_GIOMM=1', 
'-DHAVE_LADSPA_H=1', '-DHAVE_LRDF=1', '-DHAVE_LILV=1', '-DZITA_CONVOLVER=1', 
'-DZITA_CONVOLVER_VERSION=4', '-DZITA_RESAMPLER=1', 
'-DGX_STYLE_DIR="/usr/share/gx_head/skins"', 
'-DGX_FACTORY_DIR="/usr/share/gx_head/factorysettings"', 
'-DGX_SOUND_DIR="/usr/share/gx_head/sounds"', 
'-DGX_SOUND_BPB_DIR="/usr/share/gx_head/sounds/bands"', 
'-DGX_SOUND_BPA_DIR="/usr/share/gx_head/sounds/amps"', 
'-DGX_BUILDER_DIR="/usr/share/gx_head/builder"', 
'-DGX_ICON_DIR="/usr/share/guitarix/icons"', 
'-DGX_PIXMAPS_DIR="/usr/share/pixmaps"', '-DGX_VERSION="0.39.0"', 
'-DOS_32_BIT=1', '-DHAVE_LV2CORE=1', 
'-DGX_LV2_STYLE_DIR="/usr/share/gx_head/skins/LV2"', '-DHAVE_AVAHI_GOBJECT=1', 
'-DHAVE_AVAHI_GLIB=1', '-DHAVE_AVAHI_CLIENT=1', '-DHAVE_AVAHI=1', 
'-DHAVE_BLUEZ=1', '-DHAVE_EIGEN3=1', '-DLOCALEDIR="/usr/share/locale"', 
'-DLV2_SO', '../src/LV2/gx_amp.lv2/gx_tonestack.cc', '-c', 
'-o/<>/build/src/LV2/gx_amp.lv2/gx_tonestack.cc.1.o', 
'-Wdate-time', '-D_FORTIFY_SOURCE=2']
...

SSE (and MMX) are not part of the i386 port baseline.

Fix:

--- debian/rules.old2020-05-23 18:18:14.987486993 +
+++ debian/rules2020-05-23 18:18:34.127459576 +
@@ -16,7 +16,7 @@
--cxxflags="$(shell dpkg-buildflags --get CXXFLAGS) \
$(shell dpkg-buildflags --get CPPFLAGS)" \
--ldflags="$(shell dpkg-buildflags --get LDFLAGS) 
-Wl,--as-needed" -v \
-   --shared-lib --lib-dev --glade-support --enable-lfs --ladspa
+   --shared-lib --lib-dev --glade-support --enable-lfs --ladspa 
--disable-sse
 
 override_dh_makeshlibs:
dh_makeshlibs -V

Bug#961122: 1.5.0.87+dfsg1-1 is out of the way already

[Adrian Bunk]

On Fri, May 22, 2020 at 04:13:02PM +0200, Julien Puydt wrote:
> Hi,
> 
> I don't understand why you report a bug on 1.5.0.87+dfsg1-1 on the 20th
> of may when testing has 1.5.0.87+dfsg1-4 since the 9th of march, and
> unstable had it since the 4th of march.

The version should indicate the earliest known-broken version.

> Isn't the problem history already?

1.5.0.87+dfsg1-4+b1 built only at the second attempt,
the bug is still in unstable.

armhf build failures are also frequent in the reproducible CI:
https://tests.reproducible-builds.org/debian/history/giac.html

> JP

cu
Adrian

Bug#961379: buster-pu: package libntlm/1.5-1+deb10u1

[Anton Gladky]

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

Dear release team,

I have prepared an NMU for buster release which fixes CVE-2019-17455.

Please let mw know whether I can upload it.

Diff is attached.

Thanks,

Anton
diff -Nru libntlm-1.5/debian/changelog libntlm-1.5/debian/changelog
--- libntlm-1.5/debian/changelog2018-08-24 22:03:11.0 +0200
+++ libntlm-1.5/debian/changelog2020-05-23 21:18:56.0 +0200
@@ -1,3 +1,17 @@
+libntlm (1.5-1+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload
+  * Fix buffer overflow. CVE-2019-17455:
+  Libntlm through 1.5 relies on a fixed buffer size for
+  tSmbNtlmAuthRequest, tSmbNtlmAuthChallenge, and tSmbNtlmAuthResponse
+  read and write operations, as demonstrated by a stack-based buffer
+  over-read in buildSmbNtlmAuthRequest in smbutil.c for a crafted
+  NTLM request.
+  Closes: #942145
+  * Add regression test for CVE-2019-17455
+
+ -- Anton Gladky   Sat, 23 May 2020 21:18:56 +0200
+
 libntlm (1.5-1) unstable; urgency=low
 
   * New upstream version.
diff -Nru 
libntlm-1.5/debian/patches/10_fix_buffer_overflow_CVE-CVE-2019-17455.patch 
libntlm-1.5/debian/patches/10_fix_buffer_overflow_CVE-CVE-2019-17455.patch
--- libntlm-1.5/debian/patches/10_fix_buffer_overflow_CVE-CVE-2019-17455.patch  
1970-01-01 01:00:00.0 +0100
+++ libntlm-1.5/debian/patches/10_fix_buffer_overflow_CVE-CVE-2019-17455.patch  
2020-05-23 21:12:10.0 +0200
@@ -0,0 +1,85 @@
+From b967886873fcf19f816b9c0868465f2d9e5df85e Mon Sep 17 00:00:00 2001
+From: Simon Josefsson 
+Date: Sun, 19 Apr 2020 09:30:05 +0200
+Subject: [PATCH] Fix buffer overflow.  Patch from Cedric Buissart based on
+ report by Kirin.  CVE-2019-17455
+
+
+---
+ ntlm.h|  8 +---
+ smbutil.c | 13 -
+ 2 files changed, 13 insertions(+), 8 deletions(-)
+
+Index: libntlm-1.5/ntlm.h
+===
+--- libntlm-1.5.orig/ntlm.h
 libntlm-1.5/ntlm.h
+@@ -36,6 +36,8 @@ extern "C"
+ 
+ #define NTLM_VERSION "1.5"
+ 
++#define MSG_BUFSIZE 1024
++
+ /*
+  * These structures are byte-order dependant, and should not
+  * be manipulated except by the use of the routines provided
+@@ -55,7 +57,7 @@ extern "C"
+ uint32 flags;
+ tSmbStrHeader user;
+ tSmbStrHeader domain;
+-uint8 buffer[1024];
++uint8 buffer[MSG_BUFSIZE];
+ uint32 bufIndex;
+   } tSmbNtlmAuthRequest;
+ 
+@@ -68,7 +70,7 @@ extern "C"
+ uint8 challengeData[8];
+ uint8 reserved[8];
+ tSmbStrHeader emptyString;
+-uint8 buffer[1024];
++uint8 buffer[MSG_BUFSIZE];
+ uint32 bufIndex;
+   } tSmbNtlmAuthChallenge;
+ 
+@@ -84,7 +86,7 @@ extern "C"
+ tSmbStrHeader uWks;
+ tSmbStrHeader sessionKey;
+ uint32 flags;
+-uint8 buffer[1024];
++uint8 buffer[MSG_BUFSIZE];
+ uint32 bufIndex;
+   } tSmbNtlmAuthResponse;
+ 
+Index: libntlm-1.5/smbutil.c
+===
+--- libntlm-1.5.orig/smbutil.c
 libntlm-1.5/smbutil.c
+@@ -46,9 +46,9 @@ char versionString[] = PACKAGE_STRING;
+ 
+ /*
+  * Must be multiple of two
+- * We use a statis buffer of 1024 bytes for message
++ * We use a statis buffer of MSG_BUFSIZE [1024] bytes for message
+  * At maximun we but 48 bytes (ntlm responses) and 3 unicode strings so
+- * NTLM_BUFSIZE * 3 + 48 <= 1024
++ * NTLM_BUFSIZE * 3 + 48 <= MSG_BUFSIZE
+  */
+ #define NTLM_BUFSIZE 320
+ 
+@@ -70,10 +70,13 @@ char versionString[] = PACKAGE_STRING;
+  */
+ #define AddBytes(ptr, header, buf, count) \
+ { \
+-  ptr->header.len = ptr->header.maxlen = UI16LE(count); \
++  size_t count2 = count; \
++  if (count2  > MSG_BUFSIZE - ptr->bufIndex)  \
++count2 = MSG_BUFSIZE - ptr->bufIndex; \
++  ptr->header.len = ptr->header.maxlen = UI16LE(count2); \
+   ptr->header.offset = UI32LE((ptr->buffer - ((uint8*)ptr)) + ptr->bufIndex); 
\
+-  memcpy(ptr->buffer+ptr->bufIndex, buf, count); \
+-  ptr->bufIndex += count; \
++  memcpy(ptr->buffer+ptr->bufIndex, buf, count2); \
++  ptr->bufIndex += count2; \
+ }
+ 
+ #define AddString(ptr, header, string) \
diff -Nru libntlm-1.5/debian/patches/20_test_CVE-2019-17455.patch 
libntlm-1.5/debian/patches/20_test_CVE-2019-17455.patch
--- libntlm-1.5/debian/patches/20_test_CVE-2019-17455.patch 1970-01-01 
01:00:00.0 +0100
+++ libntlm-1.5/debian/patches/20_test_CVE-2019-17455.patch 2020-05-23 
21:05:29.0 +0200
@@ -0,0 +1,90 @@
+From aa975994cf9cf39c33ce33a1b2988277c456dec1 Mon Sep 17 00:00:00 2001
+From: Simon Josefsson 
+Date: Sun, 19 Apr 2020 09:44:17 +0200
+Subject: [PATCH] Add regression check for CVE-2019-17455 overflow.
+
+---
+ Makefile.am   |  2 +-
+ test_CVE-2019-17455.c | 61 +++
+ 2 files changed, 62 insertions(+), 1 deletion(-)
+ create mode 100644 test_CVE-2019-17455.c
+
+Index: 

Bug#951722: autopkgtest suite flaky on arm64

[Michael Biebl]

Am 23.05.20 um 11:14 schrieb Nis Martensen:
> Thanks a lot Noah and Michael for working on this!
> 
> Michael Biebl wrote:
>> The patch to add sd_notify is rather trivial. Problem is, that dovecot
>> unhelpfully clears the full environment. In src/master/main.c,
>> sd_notify() should be called around/after main_init().
>> Unfortunately, at this point master_service_env_clean() has been called,
>> clearing the process environment, including NOTIFY_SOCKET, which is
>> passed from systemd to dovecot and is needed to make sd_notify work.
>>
>> I haven't found a way how to instruct dovecot not to clear the
>> NOTIFY_SOCKET env var.
> 
> I have no idea if this works, but did you try adding NOTIFY_SOCKET to
> line 65 of src/lib-master/master-service-settings.c?

This does the trick. Thanks, Nis.




signature.asc
Description: OpenPGP digital signature

Bug#961378: -v causes Temporary failure in name resolution

[Dan Jacobson]

Package: netcat-openbsd
Version: 1.206-1
File: /bin/nc.openbsd

$ man nc
 -v  Produce more verbose output.
but
$ nc -v -l -p 60111
nc: getnameinfo: Temporary failure in name resolution

and it dies. That's crazy.

$ nc.traditional -v -l -p 60111
listening on [any] 60111 ...

That's better.

Bug#887534: plume-creator FTBFS with libquazip5-headers 0.7.3-3

[Sudip Mukherjee]

On Sat, May 23, 2020 at 07:51:52PM +0300, Adrian Bunk wrote:
> Control: tags 960678 moreinfo
> Control: tags 887534 - patch
> 
> On Fri, Apr 24, 2020 at 08:31:31PM +0100, Sudip Mukherjee wrote:
> > This error is not reproducible any more
> >...
> 
> It is still there, both for me locally and in reproducible:
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/plume-creator.html

Thats odd. It was not there when I made the last package.

Anyways, I have now uploaded new package to mentors. And attached the new diff.

--
Regards
Sudip
diff -Nru plume-creator-0.66+dfsg1/debian/changelog plume-creator-0.66+dfsg1/debian/changelog
--- plume-creator-0.66+dfsg1/debian/changelog	2016-01-13 20:53:03.0 +
+++ plume-creator-0.66+dfsg1/debian/changelog	2020-05-23 18:58:23.0 +0100
@@ -1,3 +1,13 @@
+plume-creator (0.66+dfsg1-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS. (Closes: #887534)
+- Include header file.
+- Adjust remove-external.patch to quazip5.
+  * Add debug symbols. (Closes: #889273)
+
+ -- Sudip Mukherjee   Sat, 23 May 2020 18:58:23 +0100
+
 plume-creator (0.66+dfsg1-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru plume-creator-0.66+dfsg1/debian/patches/fix_ftbfs.patch plume-creator-0.66+dfsg1/debian/patches/fix_ftbfs.patch
--- plume-creator-0.66+dfsg1/debian/patches/fix_ftbfs.patch	1970-01-01 01:00:00.0 +0100
+++ plume-creator-0.66+dfsg1/debian/patches/fix_ftbfs.patch	2020-05-23 18:58:23.0 +0100
@@ -0,0 +1,16 @@
+Description: Fix FTBFS
+ Include the file as done by upstream.
+
+ Origin: https://github.com/jacquetc/plume-creator-legacy/blob/develop/src/newProjectWizard/selectpage.cpp#L3
+
+---
+
+--- plume-creator-0.66+dfsg1.orig/src/newProjectWizard/selectpage.cpp
 plume-creator-0.66+dfsg1/src/newProjectWizard/selectpage.cpp
+@@ -1,5 +1,6 @@
+ #include "selectpage.h"
+ #include "ui_selectpage.h"
++#include 
+ 
+ SelectPage::SelectPage(QWidget *parent) :
+ QWizardPage(parent),
diff -Nru plume-creator-0.66+dfsg1/debian/patches/remove-external.patch plume-creator-0.66+dfsg1/debian/patches/remove-external.patch
--- plume-creator-0.66+dfsg1/debian/patches/remove-external.patch	2016-01-13 20:53:03.0 +
+++ plume-creator-0.66+dfsg1/debian/patches/remove-external.patch	2020-05-23 18:58:23.0 +0100
@@ -54,7 +54,7 @@
  #include 
  #include 
 -#include "../../externals/quazip/JlCompress.h"
-+#include 
++#include 
  #include "../fileupdater.h"
  
  class Utils
@@ -67,7 +67,7 @@
  #include "changestests.h"
  #include "fileupdater.h"
 -#include "JlCompress.h"
-+#include 
++#include 
  #include "common/utils.h"
  #include "maintextdocument.h"
  #include "wordcountenginethread.h"
@@ -78,7 +78,7 @@
 @@ -1,5 +1,5 @@
  #include "fileupdater.h"
 -#include "JlCompress.h"
-+#include 
++#include 
  
  FileUpdater::FileUpdater(QWidget *parent) :
  QWidget(parent), attendVersion("0.6"), treeVersion("0.5"), infoVersion("0.3")
@@ -89,7 +89,7 @@
 @@ -1,5 +1,5 @@
  #include "zipper.h"
 -#include "JlCompress.h"
-+#include 
++#include 
  
  Zipper::Zipper(QObject *parent) :
  currentJob("extract"), oneTime(true)
@@ -115,7 +115,7 @@
  #include "ui_importuserdictdialog.h"
  #include "common/utils.h"
 -#include "JlCompress.h"
-+#include 
++#include 
  
  ImportUserDictDialog::ImportUserDictDialog(QWidget *parent) :
  QDialog(parent),
@@ -128,7 +128,7 @@
  #include "themes.h"
  #include "common/utils.h"
 -#include "JlCompress.h"
-+#include 
++#include 
  #include "zipper/zipchecker.h"
  
  Themes::Themes(QObject *parent) :
diff -Nru plume-creator-0.66+dfsg1/debian/patches/series plume-creator-0.66+dfsg1/debian/patches/series
--- plume-creator-0.66+dfsg1/debian/patches/series	2016-01-13 20:53:03.0 +
+++ plume-creator-0.66+dfsg1/debian/patches/series	2020-05-23 18:58:23.0 +0100
@@ -3,5 +3,5 @@
 remove-SlimUpdater.patch
 translations-es.patch
 built-in-Qt5.patch
-
 desktop.patch
+fix_ftbfs.patch
diff -Nru plume-creator-0.66+dfsg1/debian/rules plume-creator-0.66+dfsg1/debian/rules
--- plume-creator-0.66+dfsg1/debian/rules	2016-01-13 20:53:03.0 +
+++ plume-creator-0.66+dfsg1/debian/rules	2020-05-23 18:58:23.0 +0100
@@ -16,7 +16,7 @@
 	CFLAGS="$(CFLAGS) $(CPPFLAGS)" \
 	CXXFLAGS="$(CXXFLAGS) $(CPPFLAGS)" \
 	LFLAGS="$(LDFLAGS) $(LDFLAGS2)" \
-		qmake -makefile plume-creator.pro
+		qmake -makefile "CONFIG+=debug" plume-creator.pro
 	touch $@
 
 build-stamp: config

Bug#960758: libcamera FTBFS: missing boost build dependencies

[Logan Rosen]

Package: libcamera
Version: 0~git20200513+924778e-1
Followup-For: Bug #960758
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu groovy ubuntu-patch

Hi,

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

  * Build-depend on libboost-dev to fix FTBFS.

Thanks for considering the patch.

Logan

-- 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)
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
diff -Nru libcamera-0~git20200513+924778e/debian/control 
libcamera-0~git20200513+924778e/debian/control
--- libcamera-0~git20200513+924778e/debian/control  2020-05-15 
10:24:53.0 -0400
+++ libcamera-0~git20200513+924778e/debian/control  2020-05-23 
15:03:08.0 -0400
@@ -13,7 +13,8 @@
python3-sphinx,
python3-yaml,
libjs-jquery,
-   libjs-underscore
+   libjs-underscore,
+   libboost-dev
 Standards-Version: 4.5.0
 Rules-Requires-Root: no
 Section: libs

Bug#961028: hplip: No scanner found: SANE cannot load the hpaio backend

[Milomak]

patch worked
On Sat, 23 May 2020 09:56:47 +0200 Florian Hatat  wrote:
> This issue has an attached patch:
> https://launchpadlibrarian.net/480406888/hplip-configure-python.patch
> I've just applied this patch to the current Debian source, and rebuilt
> the package. This fixes the issue for me.
>
> Regards,
> --
> Florian Hatat
>
>

Bug#961374: usbguard: please provide the libusbguard public development files

[Birger Schacht]

Hi,

On 5/23/20 8:12 PM, Pino Toscano wrote:
> Hi,
> 
> it would be nice to have a libusbguard-dev package providing the
> development files for libusbguard0. Upstream already installs them,
> so it is matter of shipping them in a new libusbguard-dev package.
> This way 3rd party applications can be built using the shared
> libusbguard library.

Upstream does not consider the API to be stable, thats why we're
installing to a private location for now and therefore not shipping
development files. Also I'm not aware of any other projects besides
upstream using the usbguard library. Are there any 3rd party
applications? That might change things...

cheers,
Birger



signature.asc
Description: OpenPGP digital signature

Bug#961284: nix: FTBFS on armel and mipsel

[Adrian Bunk]

Control: tags -1 ftbfs patch

On Fri, May 22, 2020 at 11:43:24PM +0800, Boyuan Yang wrote:
>...
> /usr/include/c++/9/bits/atomic_base.h:541: undefined reference to
> `__atomic_fetch_add_8'
> collect2: error: ld returned 1 exit status
> make[1]: *** [mk/lib.mk:104: src/libutil/libnixutil.so] Error 1
>...

Fix/workaround:

--- debian/rules.old2020-05-23 18:01:16.777117658 +
+++ debian/rules2020-05-23 18:01:40.436904447 +
@@ -16,6 +16,10 @@
 # package maintainers to append LDFLAGS
 #export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
+ifneq (,$(filter $(DEB_HOST_ARCH), armel mipsel powerpc))
+  export DEB_LDFLAGS_MAINT_APPEND = -Wl,--no-as-needed -latomic -Wl,--as-needed
+endif
+
 export EDITLINE_CFLAGS = "-DREADLINE"
 export EDITLINE_LIBS   = "/usr/lib/$(DEB_HOST_MULTIARCH)/libhistory.so 
/usr/lib/$(DEB_HOST_MULTIARCH)/libreadline.so"
 export V=1

Bug#961377: raspi3-firmware: recent stable update causes non-booting systems

[Thorsten Glaser]

Package: raspi3-firmware
Version: 1.20190215-1+deb10u3
Severity: critical
Tags: patch buster
Justification: breaks the whole system

/etc/kernel/postinst.d/z50-raspi3-firmware in +deb10u3 contains:

   67   for dtn in ${dtb_path}/bcm*.dtb; do
   68 [ -e "${dtb}" ] && cp "${dtb}" /boot/firmware/
   69   done

It’s hard to see, a typo, and not in unstable (where commit
165f43a6ca14d240f199e8ab8924e503ca5f427d got it right), but
commit fc3df0e8c64c2c62a54e0efcd226e36f28ccd3a4 uses “dtn”,
not “dtb”, as for variable, but refers to “dtb”.

This causes creation of systems that cannot boot (user error
description “[…] but when I install the SD card on the Pi and
boot it, I end up with this multicolored starting screen. It
does not go any further.”) which is really tricky to debug.

The following patch causes the four files…
-rwxr-xr-x 1 root root13593 May 23 20:53 bcm2837-rpi-3-a-plus.dtb
-rwxr-xr-x 1 root root13637 May 23 20:53 bcm2837-rpi-3-b-plus.dtb
-rwxr-xr-x 1 root root13445 May 23 20:53 bcm2837-rpi-3-b.dtb
-rwxr-xr-x 1 root root13433 May 23 20:53 bcm2837-rpi-cm3-io3.dtb
… to show up in /boot/firmware/ and should (I cannot boot-test
it currently) therefore fix this problem:


diff --git a/debian/kernel/postinst.d/z50-raspi3-firmware 
b/debian/kernel/postinst.d/z50-raspi3-firmware
index 5d3dd8e..04ebb1d 100755
--- a/debian/kernel/postinst.d/z50-raspi3-firmware
+++ b/debian/kernel/postinst.d/z50-raspi3-firmware
@@ -64,7 +64,7 @@ else
 fi
 
 if [ "$KERNEL" = "auto" ]; then
-  for dtn in ${dtb_path}/bcm*.dtb; do
+  for dtb in ${dtb_path}/bcm*.dtb; do
 [ -e "${dtb}" ] && cp "${dtb}" /boot/firmware/
   done
 


-- System Information:
Debian Release: 10.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.5.0-1-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages raspi3-firmware depends on:
ii  dosfstools  4.1-2

raspi3-firmware recommends no packages.

raspi3-firmware suggests no packages.

-- Configuration Files:
/etc/default/raspi3-firmware changed:
CMA=128M


-- no debconf information

Bug#961376: rawtherapee: Segmentation fault at program termination

[Wojciech Muła]

Package: rawtherapee
Version: 5.8-1
Severity: normal

When rawtherapee is run from command line to edit a single file,
like:

$ rawtherapee DSC_4572.NEF

it sometimes segfaults after closing the main window. A .pp3 file
seems to be written without any errors.

Here are two gdb sessions I captured. The source of SIGSEGV is located
in the main window's destructor, looks to me like uninitialized member
or double free.

Backtrace #1:

Thread 1 "rawtherapee" received signal SIGSEGV, Segmentation fault.
0x55abacbb in RTWindow::~RTWindow (this=0x562c7cb0, 
__in_chrg=, 
__vtt_parm=) at ./rtgui/rtwindow.cc:467
467 ./rtgui/rtwindow.cc: No such file or directory.
(gdb) bt
#0  0x55abacbb in RTWindow::~RTWindow (this=0x562c7cb0, 
__in_chrg=, 
__vtt_parm=) at ./rtgui/rtwindow.cc:467
#1  0x55abad99 in RTWindow::~RTWindow (this=0x562c7cb0, 
__in_chrg=, 
__vtt_parm=) at ./rtgui/rtwindow.cc:455
#2  0x557d2782 in std::default_delete::operator() 
(this=, 
__ptr=0x562c7cb0) at /usr/include/c++/9/bits/unique_ptr.h:75
#3  std::unique_ptr >::~unique_ptr 
(this=, 
__in_chrg=) at /usr/include/c++/9/bits/unique_ptr.h:284
#4  main (argc=, argv=) at ./rtgui/main.cc:564

Backtrace #2:

Thread 1 "rawtherapee" received signal SIGSEGV, Segmentation fault.
0x55abacd0 in RTWindow::~RTWindow (this=0x568a7280, 
__in_chrg=, 
__vtt_parm=) at ./rtgui/rtwindow.cc:468
468 ./rtgui/rtwindow.cc: No such file or directory.
(gdb) bt
#0  0x55abacd0 in RTWindow::~RTWindow (this=0x568a7280, 
__in_chrg=, 
__vtt_parm=) at ./rtgui/rtwindow.cc:468
#1  0x55abad99 in RTWindow::~RTWindow (this=0x568a7280, 
__in_chrg=, 
__vtt_parm=) at ./rtgui/rtwindow.cc:455
#2  0x557d2782 in std::default_delete::operator() 
(this=, 
__ptr=0x568a7280) at /usr/include/c++/9/bits/unique_ptr.h:75
#3  std::unique_ptr >::~unique_ptr 
(this=, 
__in_chrg=) at /usr/include/c++/9/bits/unique_ptr.h:284
#4  main (argc=, argv=) at ./rtgui/main.cc:564


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

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

Versions of packages rawtherapee depends on:
ii  libatkmm-1.6-1v52.28.0-2
ii  libc6   2.30-4
ii  libcairomm-1.0-1v5  1.12.2-4
ii  libcanberra-gtk3-0  0.30-7
ii  libcanberra00.30-7
ii  libexpat1   2.2.9-1
ii  libfftw3-single33.3.8-2
ii  libgcc-s1   10-20200321-1
ii  libglib2.0-02.64.1-1
ii  libglibmm-2.4-1v5   2.62.0-1
ii  libgomp110-20200321-1
ii  libgtk-3-0  3.24.14-1
ii  libgtkmm-3.0-1v53.24.2-1
ii  libiptcdata01.0.5-2.1
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  liblcms2-2  2.9-4+b1
ii  liblensfun1 0.3.2-5
ii  libpangomm-1.4-1v5  2.42.0-2
ii  libpng16-16 1.6.37-2
ii  librsvg2-2  2.46.4-1
ii  libsigc++-2.0-0v5   2.10.2-1
ii  libstdc++6  10-20200321-1
ii  libtiff54.1.0+git191117-2
ii  rawtherapee-data5.8-1
ii  zlib1g  1:1.2.11.dfsg-2

rawtherapee recommends no packages.

rawtherapee suggests no packages.

-- no debconf information

Bug#961375: ITP: quicktree -- Neighbor-Joining algorithm for phylogenies

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: quicktree -- Neighbor-Joining algorithm for phylogenies
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: quicktree
  Version : 2.5
  Upstream Author : Kevin Howe 
* URL : https://github.com/khowe/quicktree/
* License : Apache-2.0
  Programming Lang: C
  Description : Neighbor-Joining algorithm for phylogenies
 QuickTree is an efficient implementation of the Neighbor-Joining
 algorithm (PMID: 3447015), capable of reconstructing phylogenies from
 huge alignments in time less than the age of the universe.
 .
 QuickTree is written in ANSI C and should complile and run on a number
 of different platforms. "make quicktree" from this directory should
 compile the program and place the executable in the current directory.

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

Bug#961374: usbguard: please provide the libusbguard public development files

[Pino Toscano]

Source: usbguard
Version: 0.7.6+ds-2
Severity: wishlist
Tags: patch

Hi,

it would be nice to have a libusbguard-dev package providing the
development files for libusbguard0. Upstream already installs them,
so it is matter of shipping them in a new libusbguard-dev package.
This way 3rd party applications can be built using the shared
libusbguard library.

Attached there are the following patches to do so:
- public-libusbguard.diff: do not move libusbguard to a private
  location, as exposing its devel stuff will make it public again;
  note that this patch requires removing the executable permissions
  from debian/libusbguard0.install (i.e. chmod -x), as this file is
  no more processed using dh-exec (not need for it)
- libusbguard-dev.diff: add a new libusbguard-dev package containing
  the development files

Thanks,
-- 
Pino
--- a/debian/libusbguard0.install
+++ b/debian/libusbguard0.install
@@ -1,2 +1,2 @@
-#! /usr/bin/dh-exec
-usr/lib/*/libusbguard.so.* usr/lib/${DEB_HOST_MULTIARCH}/usbguard/
+usr/lib/*/libusbguard.so.0
+usr/lib/*/libusbguard.so.0.*
--- a/debian/control
+++ b/debian/control
@@ -49,6 +49,17 @@ Description: USB device authorization po
  .
  This package contains the shared library
 
+Package: libusbguard-dev
+Section: libdevel
+Architecture: linux-any
+Depends: ${misc:Depends}, libusbguard0 (= ${binary:Version}), libqb-dev
+Description: USB device authorization policy framework - development files
+ The USBGuard software framework helps to protect your computer against rogue
+ USB devices (a.k.a. BadUSB) by implementing basic allow- and blocklisting
+ capabilities based on device attributes.
+ .
+ This package contains the development files for the shared library.
+
 Package: usbguard
 Architecture: linux-any
 Depends: ${misc:Depends}, ${shlibs:Depends}, dbus
--- /dev/null
+++ b/debian/libusbguard-dev.install
@@ -0,0 +1,4 @@
+usr/include/usbguard/
+usr/lib/*/libusbguard.a
+usr/lib/*/libusbguard.so
+usr/lib/*/pkgconfig/libusbguard.pc

Bug#961373: slic3r-prusa FTBFS on armhf: cc1plus: out of memory

[Adrian Bunk]

Source: slic3r-prusa
Version: 2.2.0+dfsg1-2
Severity: serious
Tags: ftbfs patch

This time it is armhf.

https://buildd.debian.org/status/fetch.php?pkg=slic3r-prusa=armhf=2.2.0%2Bdfsg1-2=1590129666=0

...
cc1plus: out of memory allocating 9048820 bytes after a total of 77602816 bytes
make[3]: *** [src/libslic3r/CMakeFiles/libslic3r_cgal.dir/build.make:66: 
src/libslic3r/CMakeFiles/libslic3r_cgal.dir/MeshBoolean.cpp.o] Error 1


Reduce debug info also for all other 32bit architectures:

--- debian/rules.old2020-05-22 10:28:59.914315778 +
+++ debian/rules2020-05-22 10:32:03.024934364 +
@@ -5,6 +5,8 @@
 # less debug info to avoid running out of address space
 ifneq (,$(filter $(DEB_HOST_ARCH), mips mipsel))
export DEB_CXXFLAGS_MAINT_APPEND += --param ggc-min-expand=5 -g0
+else ifeq ($(DEB_HOST_ARCH_BITS), 32)
+   export DEB_CXXFLAGS_MAINT_APPEND += -g1
 endif
 
 ifneq (,$(filter $(DEB_HOST_ARCH), i386))

Bug#961372: ITP: golang-github-fzambia-sentinel -- Redis Sentinel support for redigo library

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 

* Package name : golang-github-fzambia-sentinel
 Version : 1.1.0-1
 Upstream Author : Alexander Emelin
* URL : https://github.com/FZambia/sentinel
* License : Apache-2.0
 Programming Lang: Go
 Description : Redis Sentinel support for redigo library

Alternative solution is to configure Haproxy between your application 
and
Redis to proxy requests to Redis master instance if you only need HA. 
This way

you don't need to use this library.

This module is a build dependency of gitlab-workhorse.

Bug#944253: dlt-daemon contains example systemd units for binaries in dlt-tools and libdlt-examples

[Gianfranco Costamagna]

control: tags -1 patch pending


> Sorry for the delay. Now had a chance to look at this again.
> 

sorry at the end the breaks/replaces were not needed because the files are 
installed into a different location
now.

I didn't spot that part.

I uploaded in deferred/5

G.

Bug#961313: Bug #961313 fixed upstream

[Andreas Noteng]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I was going to forward the patch upstream, but the upstream maintainer had
already fixed this a few hours ago. Applying the upstream patch to debian
instead. The updated package will be uploaded shortly. Thanks for
reporting.

Andreas

- --
Andreas Noteng

()  ascii ribbon campaign - against html mail
/\- against microsoft attachments
http://www.gnu.org/philosophy/no-word-attachments
-BEGIN PGP SIGNATURE-
Version: FlowCrypt 7.7.7 Gmail Encryption
Comment: Seamlessly send and receive encrypted email

wsFcBAEBCgAGBQJeyWS0AAoJELRG7qgympRaA/AQAIG+hf4mvIQ8tiKVMdw5
OSUQagRrOQCtfjUnheJk4NdqFHL0gi4w0U7AF27SRn7Jiv9pnINzWhbnfVaP
C7WhBGun4qfwF8XkGtvv6vTlkxJhxTszkmk6Lj2qXk/gXryFAzvYnfBqK8kz
9y+Bx0aBQ7uOa7G61dbmsVZBRTtP1NO0lwxs/sUodFQlHHCrrjxeOH1L/LFU
n6j+5cWf9jseJgpvwlEMPvvsKwk8Is/dvWny/IWzv6oBN/G8GnuMFvIhYXeg
LjHc45yxVUpArZ1Ojoo10nmviEmsvFYOOsHQWCzXYsRO1YvRHvxu79wfvWi6
7sf2hx9r5pAKSA1ClytTGXeye8sZOqVOYZXI4Q3a2hnVfXEKyD/SG7yCiQwa
amMdkSAJWODfiMQdsPNMG7hmqI6Xebg02EqNrrWtByjnsWgZjHxoUM++4GlL
jsrmE8N6oSFw1P8x/NjwcEIbdWKdVmD+Ty1kqQrfBYtjOfBRI0ivFJYamLKp
gq5/Tmd92Nilp2hI9eQxOOaVgv0fiqH1LoMI9tZAfTvuIy2+P/M3s1h5BFEY
kav2sD9a+Z4t72BrMS9eiyromEjY0ZiEnK7wjWKS026WbgXDwjd4R6ApcWEW
h1lRgn8KkUpDqwSL2BeWMIdd0rZUboPLrYE+iwXvimALyYuAf1rVwYZO9RlJ
fJg5
=t71X
-END PGP SIGNATURE-

Bug#598892: hello

[westernuniondirecto...@gmail.com]

Bug#961371: ITP: due -- Wrapper tool to create and run Docker container software build environments.

[adoyle]

Package: wnpp
Severity: wishlist
Owner: adoyle 

* Package name: due
  Version : 1.3.1
  Upstream Author : Alex Doyle 
* URL : https://github.com/CumulusNetworks/DUE
* License : MIT
  Programming Lang: Bash
  Description : Wrapper tool to create and run Docker container software 
build environments.

Dedicated User Environment (DUE) is a framework for creating preconfigured 
build/development
environments in Docker containers. It serves two primary purposes:

1 - Maintains configurations for creating Docker images for any build 
environment, using
any architecture of any Debian based release it can find an image for.
 For example, the Open Network Install Environment 
(https://github.com/opencomputeproject/onie)
 currently builds on Debian 8 and 9, but requires some Backports packages, and 
a program that
 isn't packaged for Debian. DUE maintains a configuration to get all of that 
added when the
 Docker image is created so ONIE can 'just build'. Apart from not requiring the 
end user to
 have to configure the build environment, it also allows all developers to use 
the same build
 environment when debugging - regardless of where they happen to be.

2 - It goes beyond 'just using a Dockerfile' by using a launcher application 
that supplies
runtime configuration to Docker for the Docker images it has created. Apart 
from reducing
typing and being smart about the containers that it runs (ex: containers 
building Debian
packages mount the host directory _above_ the build directory so the resulting 
.debs aren't
stored in the container), DUE preserves the user's identity in the container by 
creating an account
for them with their user ID, and mounting their home directory so they can 
access their .config files.
This creates a less intrusive development environment when the user is in a 
build/test/debug
cycle.

While the above are the most important features DUE provides, there are a lot 
more ways
it makes using different development configurations easier, which are 
documented in
the Readme.md (https://github.com/CumulusNetworks/DUE/blob/master/README.md)

I also created a tutorial video using DUE to build ONIE as part of a talk I 
gave at
OpenCompute here: https://www.youtube.com/watch?v=-5onRbZA0QQ=youtu.be

History:
 DUE came out of work I did at Cumulus Networks to provide build environments 
for
 teams of engineers building packages for Cumulus' Jessie and Buster based
 releases of Cumulus Linux. When I took over as ONIE Project Lead, I saw the 
opportunity
 to use it to create a standard way of setting up build environments for ONIE 
and any other
 software projects. Cumulus saw the value in any developer being able to use it
 and DUE was open sourced under the MIT license.

Q:
Why is this package useful/relevant?
 See above.

Is it a dependency for another package?
 No. It does require a version ( Debian or upstream ) of Docker to work though.

Do you use it?
 All. The. Time.  Building packages at work, building ONIE, and if I just need
 an environment to quickly test configuration changes.
 This 'dogfooding' has provided insight into fixing program behaviors that
 initially seemed okay, and then became irritating through repeated use.

If there are other packages providing similar functionality, how does it 
compare?
 I looked around for quite a while before starting on DUE ( why reinvent the 
wheel?),
 but couldn't find anything that had the combination of:
  - Consistent, user friendly interface
  - Easy build environment configuration
  - And support for Debian derivatives
  ...that I was looking for.
 
 I think the closest software to this would be using schroots, and while they
 can be functionally the same, the end user experience, especially for users 
that
 are new to Debian ( or are trying to build code that partially exists outside
 the Debian ecosystem ) has less of a learning curve, and is faster to set up.
 
How do you plan to maintain it?
 I will be updating the upstream source and doing the work to make sure it is
 Debian compliant.
 
Are you looking for co-maintainers?
 Not at the moment.
 
Do you need a sponsor?
 Yes, as I am not a Debian Developer ( in the official sense, anyway :) )
 
Thank you for your consideration,
Alex Doyle

Bug#961370: pv: ETA is wildly off when transfer rate changes

[lemonsqueeze]

Package: pv
Version: 1.6.6-1
Severity: normal
Tags: upstream patch

Hello,

This was reported upstream some time ago but it doesn't seem new pv
versions are coming out so reporting here instead, maybe we can do
something about it in debian.

This was found on ubuntu initially, sorry I haven't tested debian per se
but from what I can see it's affected as well as package sources are
identical.

Consider following scenario:

I was running a really long task that generates a 800Mb file at about
50k/s. Something like:

   while true ; do ls -l /* ; sleep 1 ; done > /tmp/file

Sometime after it started I thought of using pv to keep track of
progress with:

   tail -n +1 -f /tmp/file | pv -s 800m >/dev/null

I was interested in ETA mostly, unfortunately if you do this after a few
mb have been generated the ETA is wildly wrong for a very long time:
transfer rate is really fast initially and fools pv into thinking we're
going to get something like that over time, and it takes a really long
time for the average rate to drop back to 50k/s which is all we're
getting actually.

It'd be nice to have an ETA based on current rate average here, say over
last 30s or last 10s, instead of global rate average.

I've been playing with this patch on top of pv 1.6.6
(also at https://github.com/lemonsqueeze/pv)

Which keeps track of history periodically over a given time window and uses
that to compute current average rate for ETA. Looks like it works pretty
well in this case. Also added a --rate-window option to change time window
(default: last 10s) (name isn't great, maybe could find a better one).


-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-174-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pv depends on:
ii  libc6  2.23-0ubuntu11

pv recommends no packages.

Versions of packages pv suggests:
pn  doc-base  

-- no debconf information
diff --git a/doc/quickref.1.in b/doc/quickref.1.in
index 5245e3f..3a0835c 100644
--- a/doc/quickref.1.in
+++ b/doc/quickref.1.in
@@ -263,6 +263,11 @@ Wait
 seconds between updates.  The default is to update every second.
 Note that this can be a decimal such as 0.1.
 .TP
+.B \-m SEC, \-\-rate-window SEC
+Compute current average rate over a
+.B SEC
+seconds window for ETA (default 10s).
+.TP
 .B \-w WIDTH, \-\-width WIDTH
 Assume the terminal is
 .B WIDTH
diff --git a/src/include/options.h b/src/include/options.h
index 0f8029e..c2834bb 100644
--- a/src/include/options.h
+++ b/src/include/options.h
@@ -42,6 +42,7 @@ struct opts_s {   /* structure describing run-time 
options */
double delay_start;/* delay before first display */
unsigned int watch_pid;/* process to watch fds of */
int watch_fd;  /* fd to watch */
+   unsigned int rate_window;  /* time window in seconds for current 
average rate */
unsigned int width;/* screen width */
unsigned int height;   /* screen height */
char *name;/* process name, if any */
diff --git a/src/include/pv-internal.h b/src/include/pv-internal.h
index 46d7496..9b49ba3 100644
--- a/src/include/pv-internal.h
+++ b/src/include/pv-internal.h
@@ -44,7 +44,13 @@ extern "C" {
 
 #define MAXIMISE_BUFFER_FILL   1
 
+   
+typedef struct pvhistory {
+   long long   total_bytes;
+   long double elapsed_sec;
+} pvhistory_t; 
 
+   
 /*
  * Structure for holding PV internal state. Opaque outside the PV library.
  */
@@ -113,6 +119,15 @@ struct pvstate_s {
long double prev_elapsed_sec;
long double prev_rate;
long double prev_trans;
+
+   /* Keep track of progress over last intervals to compute current 
average rate. */
+   pvhistory_t *history;/* state at previous intervals 
(circular buffer) */
+   int history_len; /* total size */
+   int history_interval;/* seconds between each history entry 
*/
+   int history_first;
+   int history_last;
+   long double current_avg_rate;/* current average rate over last 
history intervals */
+   
unsigned long long initial_offset;
char *display_buffer;
long display_buffer_size;
diff --git a/src/include/pv.h b/src/include/pv.h
index 7a3970c..a93faf4 100644
--- a/src/include/pv.h
+++ b/src/include/pv.h
@@ -93,6 +93,7 @@ extern void pv_state_name_set(pvstate_t, const char *);
 extern void pv_state_format_string_set(pvstate_t, const char *);
 extern void pv_state_watch_pid_set(pvstate_t, unsigned int);
 extern void pv_state_watch_fd_set(pvstate_t, int);
+extern void pv_state_rate_window_set(pvstate_t, int);
 
 extern void 

Bug#954290: kexec doesn't do reboots on systemd install?

[Khalid Aziz]

On 5/22/20 11:16 PM, Vasudev Kamath wrote:
> Vasudev Kamath  writes:
> 
>> In our setup of Debian 9 we noticed many kernel panic which never crash
>> dumped so was searching if there is something wrong in our setup and
>> came across this bug. While looking at systemd I noticed there is a
>> service called systemd-kexec.service which is disabled by default. Is
>> this needs to be enabled for kexec to work correctly with systemd?
>>
>> If this service is needed may be should be enabled on installing
>> kexec-tools?
> 
> May be I misunderstood relation between kdump-tools and kexec-tools. If
> so please ignore above message :-). Was actually looking at [1] which
> gave me a feeling that something is missing in my setup and wrote above
> mail
> 
> [1] https://wiki.archlinux.org/index.php/Kdump
> 
> Cheers,
> Vasudev
> 

kdump relies upon kexec but it is configured separately by kdump-tools.
kexec works just fine with systemd. It is just the wording of configure
message in kexec-tools package that is misleading and needs fixing. If
you are not seeing kernel crash dump on panic, take a look at
/etc/default/kdump-tools file and make sure it is configured correctly.

--
Khalid

Bug#961369: collectd: grpc is now available on all release architectures

[Adrian Bunk]

Source: collectd
Version: 5.11.0-2
Severity: normal

grpc is now available on all release architectures,
usage could be made unconditional.

Bug#961368: debc: hangs on packages with a big control file

[Niko Tyni]

Package: devscripts
Version: 2.20.3
Tags: patch
X-Debbugs-Cc: Simon McVittie 

The 'debc' program reproducibly hangs when run on a .changes
file of a binary build of texlive-extra.

I've traced this down to an issue with IPC::Run, whose pipe function
will block for data > 64 kilobytes [1]. The control file of the
texlive-latex-extra binary package in sid is 75k or so, hitting this.

  https://github.com/toddr/IPC-Run/issues/126

I'm attaching a lightly tested patch which removes IPC::Run from
the equation. However, I'm not sure if there was some reason
for its use in the first place. It was introduced in #915668 with

  https://salsa.debian.org/debian/devscripts/-/merge_requests/93

by Simon Mcvittie. I'm copying Simon: please let me know if I'm
missing something?
-- 
Niko Tyni   nt...@debian.org
>From 194ef16dc324cde02a50a9a3ecea7189bf86dd3d Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Sat, 23 May 2020 19:21:46 +0300
Subject: [PATCH] debc: Don't use IPC::Run for piping from dpkg-deb

IPC::Run pipes hang for >64k of data, and a regular open is simpler
anyway.

See https://github.com/toddr/IPC-Run/issues/126
---
 scripts/debi.pl | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/scripts/debi.pl b/scripts/debi.pl
index c833b1fc..d8eb824b 100755
--- a/scripts/debi.pl
+++ b/scripts/debi.pl
@@ -32,8 +32,6 @@ use filetest 'access';
 use Cwd;
 use Dpkg::Control;
 use Dpkg::Changelog::Parse qw(changelog_parse);
-use IPC::Run qw(run);
-use IO::Handle;
 use Dpkg::IPC;
 
 my $progname = basename($0, '.pl');# the '.pl' is for when we're debugging
@@ -373,8 +371,7 @@ for (split(/\n/, $ctrl->{Files})) {
 if (   (($progname eq 'debi') && (/ (\S*\.deb)$/))
 || (($progname eq 'debc') && (/ (\S*\.u?deb)$/))) {
 my $deb= $1;
-my $stdout = IO::Handle->new();
-run(['dpkg-deb', '-f', $deb], '>pipe', \*$stdout);
+open(my $stdout, '-|', 'dpkg-deb', '-f', $deb);
 my $fields = Dpkg::Control->new(name => $deb, type => CTRL_PKG_DEB);
 $fields->parse($stdout, $deb);
 my $pkg = $fields->{Package};
-- 
2.26.1

Bug#913664: Does not integrate with firewalld, will be broken when nftables backend is used

[Laurent Bigonville]

On Tue, 13 Nov 2018 20:38:05 +0100 Michael Biebl  wrote:

> firewalld switched its default backend from iptables to nftables
> recently [1]. Unfortunately, this caused issues with libvirt and as
> reported in [2], also docker. I don't use docker myself, so I'm only
> relaying this information.
> The main problem seems to be, that currently there is no integration
> between docker and firewalld. Both manage firewall rules on their own.
> As soon as nftables(firewalld) and iptables(docker) are mixed, the
> result is a broken network setup.
> Please consider forwarding this issue upstream. Best is probably if
> docker upstream get's in touch with firewalld upstream to figure a
> solution.

FTR, they have merged the following commit in libnetwork to add a new 
"docker" zone: https://github.com/moby/libnetwork/pull/2548 maybe that 
could be backported?


IIRC libvirt did the same thing to solve this issue, but with all the 
different bugs opened, it's not completely clear if it will do the same 
for docker

Bug#961367: tome FTBFS on 32bit: invalid conversion from ‘uint32_t*’ {aka ‘unsigned int*’} to ‘u32b*’ {aka ‘long unsigned int*’}

[Adrian Bunk]

Source: tome
Version: 2.4.0-ah-1
Severity: serious
Tags: ftbfs

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

...
/<>/src/loadsave.cc: In instantiation of ‘void 
{anonymous}::do_flag_set(flag_set*, ls_flag_t) [with unsigned int Tiers 
= 6]’:
/<>/src/loadsave.cc:391:34:   required from here
/<>/src/loadsave.cc:280:10: error: invalid conversion from 
‘uint32_t*’ {aka ‘unsigned int*’} to ‘u32b*’ {aka ‘long unsigned int*’} 
[-fpermissive]
  280 |   do_u32b(&(*flags)[i], flag);
  |   ~~~^~~~
  |  |
  |  uint32_t* {aka unsigned int*}
/<>/src/loadsave.cc:190:27: note:   initializing argument 1 of 
‘void do_u32b(u32b*, ls_flag_t)’
  190 | static void do_u32b(u32b *ip, ls_flag_t flag)
  | ~~^~
/<>/src/loadsave.cc: In instantiation of ‘void 
{anonymous}::do_flag_set(flag_set*, ls_flag_t) [with unsigned int Tiers 
= 1]’:
/<>/src/loadsave.cc:430:34:   required from here
/<>/src/loadsave.cc:280:10: error: invalid conversion from 
‘uint32_t*’ {aka ‘unsigned int*’} to ‘u32b*’ {aka ‘long unsigned int*’} 
[-fpermissive]
  280 |   do_u32b(&(*flags)[i], flag);
  |   ~~~^~~~
  |  |
  |  uint32_t* {aka unsigned int*}
/<>/src/loadsave.cc:190:27: note:   initializing argument 1 of 
‘void do_u32b(u32b*, ls_flag_t)’
  190 | static void do_u32b(u32b *ip, ls_flag_t flag)
  | ~~^~
/<>/src/loadsave.cc: In instantiation of ‘void 
{anonymous}::do_flag_set(flag_set*, ls_flag_t) [with unsigned int Tiers 
= 2]’:
/<>/src/loadsave.cc:1366:34:   required from here
/<>/src/loadsave.cc:280:10: error: invalid conversion from 
‘uint32_t*’ {aka ‘unsigned int*’} to ‘u32b*’ {aka ‘long unsigned int*’} 
[-fpermissive]
  280 |   do_u32b(&(*flags)[i], flag);
  |   ~~~^~~~
  |  |
  |  uint32_t* {aka unsigned int*}
/<>/src/loadsave.cc:190:27: note:   initializing argument 1 of 
‘void do_u32b(u32b*, ls_flag_t)’
  190 | static void do_u32b(u32b *ip, ls_flag_t flag)
  | ~~^~
...

Bug#726348: Filezilla crashed/hanged while minimized to tray in kde

[Hakan Bayındır]

Hello,

This bug report is still valid. However *crash* is not the correct way to
describe it. Below is the detailed report:

Tested on: Debian Testing (with all updates as of 2020-05-21)

KDE:
---8<---
Operating System: Debian GNU/Linux 
KDE Plasma Version: 5.17.5
KDE Frameworks Version: 5.62.0
Qt Version: 5.12.5
Kernel Version: 5.6.0-1-amd64
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-3770K CPU @ 3.50GHz
Memory: 15,6 GiB of RAM
---8<---

FileZilla Client:
---8<---

Version:  3.46.3

Build information:
  Compiled for:   x86_64-pc-linux-gnu
  Compiled on:x86_64-pc-linux-gnu
  Build date: 2019-12-23
  Compiled with:  gcc (Debian 9.2.1-22) 9.2.1 20200104
  Compiler flags: -g -O2
  -fdebug-prefix-map=/build/filezilla-lL8IRU/
filezilla-3.46.3=.
  -fstack-protector-strong -Wformat -Werror=format-security
  -Wall

Linked against:
  wxWidgets:  3.0.4
  SQLite: 3.31.1
  GnuTLS: 3.6.13

Operating system:
  Name:   Linux 5.6.0-1-amd64 x86_64
  Version:5.6
  CPU features:   sse sse2 sse3 ssse3 sse4.1 sse4.2 avx aes pclmulqdq rdrnd lm
  Settings dir:   /home/zero/.config/filezilla/
---8<---

Reproducibility: 100% (always)

Steps to reproduce:
---
1. Open FileZilla
2. Go to Edit -> Settings
3. Go to Interface
4. Enable Minimize to tray.
5. Press OK.
6. Go to File -> Exit
7. Open FileZilla
8. Connect to a site of your liking
9. Start a transfer.
10. Minimize the window. Window minimizes to tray.
11. Click to tray icon to restore window.
a. Window doesn't appear.
12. Click again to restore window.
a. Windows doesn't appear.
13. Click again to restore window.
a. Window doesn't appear, icon disappears.
b. FileZilla is alive at the background, transfer continues.
   No way to access to UI.
14. Frustration ensues.

Expected results:
-
1. Open FileZilla
2. Go to Edit -> Settings
3. Go to Interface
4. Enable Minimize to tray.
5. Press OK.
6. Go to File -> Exit
7. Open FileZilla
8. Connect to a site of your liking
9. Start a transfer.
10. Minimize the window. Window minimizes to tray.
11. Click to tray icon to restore window.
a. Window appears.

Bug#887534: plume-creator FTBFS with libquazip5-headers 0.7.3-3

[Adrian Bunk]

Control: tags 960678 moreinfo
Control: tags 887534 - patch

On Fri, Apr 24, 2020 at 08:31:31PM +0100, Sudip Mukherjee wrote:
> This error is not reproducible any more
>...

It is still there, both for me locally and in reproducible:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/plume-creator.html

> Regards
> Sudip

cu
Adrian

Bug#961313: pyspread: Fix example in package's tutorial?

[Andreas Noteng]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Looks like Pyspread is not correctly rendering the markdown files, the file
included in the package is the same one that is used by upstream on the web
page. I have identified the error and will try to make a patch to have the
files display correctly.

Andreas
-BEGIN PGP SIGNATURE-
Version: FlowCrypt 7.7.7 Gmail Encryption
Comment: Seamlessly send and receive encrypted email

wsFcBAEBCgAGBQJeyVMNAAoJELRG7qgympRa50UP/2zbvG+04Zg0tODNLn/4
oaF2xJyRUqpujGV1bKzEwiDdJ8a4Ef35h9G9LH++gP0ikoYpG1EUnSg6WgU+
wgkdZuAlxQ00BwScSD9tQe0L2ys/m1kkykM8lyNfMHMIUq2ofeDvm1WBlVMa
FeJp3KX4xAZRcWjaQUXA4fNxst1RIY0sBB5mS9hT1WiwBzkr47jAeFxQmMHS
BDhCMMpYz67MWaXcihj5YiO2TBntCIjlrNu+RrSUtTWZ5M40hIY8baB1J1Zs
zBPFSOpnlJwo5Urwb1MoD/4IQyRZURI5J7DkHv/sH9Wuf4G/Y1g+7uSXFY3x
AVKMpQSKRi62kkZw6g8K6CqsqxdNaX0b5pNniVEQ1XaBpWNyFxoplKucmqb+
5Mxw8XAooV+gxn0vNDCZm9sjXQhpRswqsjG3PJNE1jxHHEqe/47dmrll9aVb
4yGaX5X5LnwB2cVILbLe6SARBnp758hRTJuT9i5YCikj8kc99oEuXOaq48nc
IzLSs9hHKvOzQkbOMo6MLjZG/xlmlL2KuFXH3JFWvQ33UPWmbw8/cWPyyPES
Je/4DjU5F/QUmuuhMkXzNUtsRSoCwb/j1qaG8QVcoA23LCoydPIwJdmLfZMF
/KxltD9TLEnVM7oNczOBA7LCnZjw/pz24wPsxGy8/0xsOnf5hJL7E4Fe8HMO
BgZt
=1tua
-END PGP SIGNATURE-

Bug#943627: libcap-ng: diff for NMU version 0.7.9-2.2

[Adrian Bunk]

Control: tags 943627 + patch
Control: tags 943627 + pending
Control: tags 953925 + patch
Control: tags 953925 + pending
Control: tags 959225 + pending

Dear maintainer,

Håvard Flaget Aasen prepared an NMU for libcap-ng (versioned as 
0.7.9-2.2) and I've uploaded it to DELAYED/10. Please feel free
to tell me if I should cancel it.

cu
Adrian
diff -Nru libcap-ng-0.7.9/debian/changelog libcap-ng-0.7.9/debian/changelog
--- libcap-ng-0.7.9/debian/changelog	2019-10-18 00:30:59.0 +0300
+++ libcap-ng-0.7.9/debian/changelog	2020-05-19 15:54:57.0 +0300
@@ -1,3 +1,13 @@
+libcap-ng (0.7.9-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/control
+- Remove dependency on linux-kernel-headers closes: #959225
+- Remove libattr1-dev as build dependency closes: #953925
+- Build for default python3 version closes: #943627
+
+ -- Håvard Flaget Aasen   Tue, 19 May 2020 14:54:57 +0200
+
 libcap-ng (0.7.9-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libcap-ng-0.7.9/debian/control libcap-ng-0.7.9/debian/control
--- libcap-ng-0.7.9/debian/control	2019-10-18 00:30:14.0 +0300
+++ libcap-ng-0.7.9/debian/control	2020-05-19 15:53:03.0 +0300
@@ -5,11 +5,10 @@
 dh-autoreconf,
 dh-python ,
 autotools-dev,
-libattr1-dev,
-linux-kernel-headers,
+linux-libc-dev,
 swig ,
-libpython3-all-dev ,
-python3-all-dev:any 
+libpython3-dev ,
+python3-dev:any 
 Standards-Version: 3.9.8
 Section: libs
 Homepage: http://people.redhat.com/sgrubb/libcap-ng

Bug#960875: e-antic ABI break

[John Scott]

Control: reassign 960614 src:normaliz,src:e-antic
Control: forcemerge -1 960614

See bug #960614, not only the test fails but normaliz is unusable as 
installed.

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

Bug#961366: /usr/bin/ncal: -b ignores locale and -s for Gregorian adoption date

[Carl W.]

Package: bsdmainutils
Version: 11.1.2+b1
Severity: normal
File: /usr/bin/ncal

Dear Maintainer,

I was interested in [n]cal's behaviour around the Gregorian adoption
dates and noticed that ncal -b defaults to October 1582 regardless of
locale or -s specified country code, whereas plain "cal" uses the locale
correctly.

There follows an example shell session. Use of the "env" command is to
ensure shell aliases and functions are not responsible for the
unexpected behaviour.

Best Regards,
Carl W.


$ env cal 9 1752
   September 1752
Su Mo Tu We Th Fr Sa
   1  2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30



$ env ncal 9 1752
September 1752
Mo18 25
Tu  1 19 26
We  2 20 27
Th 14 21 28
Fr 15 22 29
Sa 16 23 30
Su 17 24
$ env ncal -b 9 1752
   September 1752
Mo Tu We Th Fr Sa Su
 1  2  3
 4  5  6  7  8  9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30

$ env ncal -p
 AL Albania1912-11-30  IT Italy  1582-10-04
 AT Austria1583-10-05  JP Japan  1918-12-18
 AU Australia  1752-09-02  LI Lithuania  1918-02-01
 BE Belgium1582-12-14  LN Latin  -05-31
 BG Bulgaria   1916-03-18  LU Luxembourg 1582-12-14
 CA Canada 1752-09-02  LV Latvia 1918-02-01
 CH Switzerland1655-02-28  NL Netherlands1582-12-14
 CN China  1911-12-18  NO Norway 1700-02-18
 CZ Czech Republic 1584-01-06  PL Poland 1582-10-04
 DE Germany1700-02-18  PT Portugal   1582-10-04
 DK Denmark1700-02-18  RO Romania1919-03-31
 ES Spain  1582-10-04  RU Russia 1918-01-31
 FI Finland1753-02-17  SI Slovenia   1919-03-04
 FR France 1582-12-09  SE Sweden 1753-02-17
*GB United Kingdom 1752-09-02  TR Turkey 1926-12-18
 GR Greece 1924-03-09  US United States  1752-09-02
 HU Hungary1587-10-21  YU Yugoslavia 1919-03-04
 IS Iceland1700-11-16
$ env ncal -s GB 9 1752
September 1752
Mo18 25
Tu  1 19 26
We  2 20 27
Th 14 21 28
Fr 15 22 29
Sa 16 23 30
Su 17 24
$ env ncal -b 9 1752
   September 1752
Mo Tu We Th Fr Sa Su
 1  2  3
 4  5  6  7  8  9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30

$ env ncal -s GB -b 9 1752
   September 1752
Mo Tu We Th Fr Sa Su
 1  2  3
 4  5  6  7  8  9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30

$ env ncal -b 9 1752 -s GB
   September 1752
Mo Tu We Th Fr Sa Su
 1  2  3
 4  5  6  7  8  9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30

$ env ncal -b 10 1582 -s GB
October 1582
Mo Tu We Th Fr Sa Su
 1  2  3  4 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31



$


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

Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bsdmainutils depends on:
ii  bsdutils 1:2.33.1-0.1
ii  debianutils  4.8.6.1
ii  libbsd0  0.9.1-2
ii  libc62.28-10
ii  libtinfo66.1+20181013-2+deb10u2

bsdmainutils recommends no packages.

Versions of packages bsdmainutils suggests:
ii  cpp   4:8.3.0-1
pn  vacation  
ii  wamerican [wordlist]  2018.04.16-1
ii  wbritish [wordlist]   2018.04.16-1
ii  whois 5.4.3

-- no debconf information

Bug#961365: ITP: jacksum -- Computes checksums, CRCs and message digests

[Mechtilde Stehmann]

Package: wnpp
Severity: wishlist

* Package name: jacksum
  Version : 1.7.0
  Upstream Author : Dipl.-Inf. (FH) Johann Nepomuk Loefflmann
* URL : https://sourceforge.net/projects/jacksum/
* License : LGPL
  Programming Lang: Java
  Description : computes checksums, CRCs and message digests

Jacksum is a free and platform independent software for computing and
 verifying checksums, CRCs and message digests.  Jacksum features both a
 commandline interface and an open API.
 .
 Jacksum supports 58 popular algorithms (Adler32, BSD sum, Bzip2's CRC-32,
 POSIX cksum, CRC-8, CRC-16, CRC-24, CRC-32 (FCS-32), CRC-64, ELF-32,
 eMule/eDonkey, FCS-16, GOST R 34.11-94, HAS-160, HAVAL (3/4/5 passes,
 128/160/192/224/256 bits), MD2, MD4, MD5, MPEG-2's CRC-32, RIPEMD-128,
 RIPEMD-160, RIPEMD-256, RIPEMD-320, SHA-0, SHA-1, SHA-224, SHA-256,
 SHA-384, SHA-512, Tiger-128, Tiger-160, Tiger, Tiger2, Tiger Tree
 Hash, Tiger2 Tree Hash, Unix System V sum, sum8, sum16, sum24, sum32,
 Whirlpool-0, Whirlpool-1, Whirlpool and xor8).



I need the classes in the directory sugar. This is a dependenca of the
part of numericalchameleon which is a dependency of JVerein.

I looked into the bugs and gess taht they only affect the jacksum
directory. otherwise they must be reopend.



I want to reintroduce it. Now it is published under
https://salsa.debian.org/debian/jacksum

If it is possible I would prefer to maintain it in the java-team.

I already ask Anuradha Weeraman and I get an ok.
-- 
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



signature.asc
Description: OpenPGP digital signature

Bug#872809: [Pkg-fonts-devel] Bug#872809: fixed in fonts-dejavu 2.37-2

[Fabian Greffrath]

Am Samstag, den 23.05.2020, 00:27 +0800 schrieb Boyuan Yang:
> oops...

Ah, I was expecting most of these to be fixed when the bug for removing
the transitional packages was filed some two years ago. Hm, maybe
things even moved to the worse in the meantime.

However, I still think it was right to finally remove the transitional
packages after they have been around for seven years now. I am pretty
sure most of the reverse dependencies can be fixed by trivially
changing the package name in debian/control. For the others, the worst
that could happen is that they'll need to adjust some hard-coded font
paths - as I have already patched for grub2 in #912846 and as you have
reported in #961355. Thanks for that, by the way!

 - Fabian



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

Bug#961336: prboom-plus FTBFS on big endian

[Adrian Bunk]

On Sat, May 23, 2020 at 05:52:26PM +0200, Fabian Greffrath wrote:
> Hi Adrian,

Hi Fabian,

> Am Samstag, den 23.05.2020, 15:39 +0300 schrieb Adrian Bunk:
> > cd /<>/obj-s390x-linux-gnu/data && ./rdatawad -I [...]
> > /<>/obj-s390x-linux-gnu/prboom-plus.wad
> > Segmentation fault
> > make[3]: *** [data/CMakeFiles/prboomwad.dir/build.make:257: prboom-
> > plus.wad] Error 139
> 
> are these platforms cross-built?

no, all buildd.debian.org builds are native builds.

Some non-release architectures are built inside qemu,
but for the program built this is like a native build
(e.g. the m68k build runs native m68k gcc inside qemu).

> I am asking, because one step in
> building prboom-plus is to compile a helper tool called "rdatawad" and
> run this to combine several graphics and sound files into a data "wad"
> file needed by the engine.

It is exactly all big endian architectures that fail this way,[1]
this looks like "rdatawad" always segfaults on big endian.

>  - Fabian

cu
Adrian

[1] riscv64 is little endian and fails for unrelated reasons

Bug#961364: xsp: use mktemp instead of tempfile

[Clint Adams]

Source: xsp
Version: 4.2-2.1

tempfile has been deprecated for years.

diff --git a/debian/mono-apache-server4.postinst 
b/debian/mono-apache-server4.postinst
index b8d295d..bceda77 100644
--- a/debian/mono-apache-server4.postinst
+++ b/debian/mono-apache-server4.postinst
@@ -34,7 +34,7 @@ daemon_turn_off() {
 
 case "$1" in
 configure)
-   tempfile=$(/bin/tempfile)
+   tempfile=$(mktemp)

db_get monoserver4/monoserver4_restartapache || true
daemon_turn_off
diff --git a/debian/mono-xsp4.postinst b/debian/mono-xsp4.postinst
index 53cd252..b97db00 100644
--- a/debian/mono-xsp4.postinst
+++ b/debian/mono-xsp4.postinst
@@ -82,7 +82,7 @@ should_start() {
 
 case "$1" in
 configure)
-   tempfile=$(/bin/tempfile)
+   tempfile=$(mktemp)

# Configure autostart, but don't prevent the init script
# from starting it manually.

Bug#912846: grub2: stop depending on ttf-dejavu-core

[Fabian Greffrath]

Control: forwarded -1 grub-de...@gnu.org
Control: tags -1 upstream

Hi grub devs,

the attached patch adds /usr/share/fonts/truetype/dejavu to the DejaVu
font search path in configure.ac. This is the directory where the
fonts-dejavu-core package in Debian installs its fonts.

Thanks!

 - Fabian

From a696233f623e9c2b480aa3ad10aed537c2890af6 Mon Sep 17 00:00:00 2001
From: Fabian Greffrath 
Date: Tue, 19 May 2020 12:19:26 +0200
Subject: [PATCH] add /u/s/fonts/truetype/dejavu to the DejaVu fonts search
 paths

---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index b2576b0..41b8758 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1669,7 +1669,7 @@ fi
 
 if test x"$starfield_excuse" = x; then
for ext in pcf pcf.gz bdf bdf.gz ttf ttf.gz; do
- for dir in . /usr/src /usr/share/fonts/X11/misc /usr/share/fonts/truetype/ttf-dejavu /usr/share/fonts/dejavu /usr/share/fonts/truetype; do
+ for dir in . /usr/src /usr/share/fonts/X11/misc /usr/share/fonts/truetype/dejavu /usr/share/fonts/truetype/ttf-dejavu /usr/share/fonts/dejavu /usr/share/fonts/truetype; do
 if test -f "$dir/DejaVuSans.$ext"; then
   DJVU_FONT_SOURCE="$dir/DejaVuSans.$ext"
   break 2
-- 
2.26.2



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

Bug#961336: prboom-plus FTBFS on big endian

[Fabian Greffrath]

Hi Adrian,

Am Samstag, den 23.05.2020, 15:39 +0300 schrieb Adrian Bunk:
> cd /<>/obj-s390x-linux-gnu/data && ./rdatawad -I [...]
> /<>/obj-s390x-linux-gnu/prboom-plus.wad
> Segmentation fault
> make[3]: *** [data/CMakeFiles/prboomwad.dir/build.make:257: prboom-
> plus.wad] Error 139

are these platforms cross-built? I am asking, because one step in
building prboom-plus is to compile a helper tool called "rdatawad" and
run this to combine several graphics and sound files into a data "wad"
file needed by the engine.

 - Fabian



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

Bug#961363: slirp4netns - Fails on Linux 5.5: enable_seccomp failed

[Bastian Blank]

Package: slirp4netns
Version: 1.0.1-1
Severity: important

slirp4netns fails with the following command line:
| /usr/bin/slirp4netns --disable-host-loopback --mtu 65520 --enable-sandbox 
--enable-seccomp -c -e 3 -r 4 --netns-type=path 
/run/user/1000/netns/cni-b5f1fc5... tap0

Excerpt from strace output:

| prctl(PR_CAPBSET_DROP, CAP_BLOCK_SUSPEND) = 0
| prctl(PR_CAPBSET_DROP, CAP_AUDIT_READ)  = 0
| prctl(PR_CAPBSET_DROP, 0x26 /* CAP_??? */) = -1 EINVAL (Invalid argument)
| capset({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, 
{effective=1<

Bug#961362: fonts-terminus-otb: In rxvt-unicode, M and m characters missing the left vertical stroke

[Ian Zimmerman]

Package: fonts-terminus-otb
Version: 4.48-2
Severity: important
Tags: upstream

The subject almost says it all. But the effect is only visible after 
whitespace, it seems.
The PCF format font (which I assume is generated from the same source) has no 
such  problem.

Also, I tried to unpack the Arch Linux package of the same name and install the 
files
manually, and the same problem happens there, so this is not Debian specfic.

Specifically, I use the 12 size font. Display is Dell U2410, about 94 dpi.
fontconfig: 2.13.1-2
freetype: 2.9.1-3+deb10u1

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

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

Versions of packages fonts-terminus-otb depends on:
ii  xfonts-utils  1:7.7+6

fonts-terminus-otb recommends no packages.

Versions of packages fonts-terminus-otb suggests:
pn  xfonts-terminus-oblique  
ii  xserver-xorg [xserver]   1:7.7+19

Bug#810890: caddy 2

[VA]

A few weeks ago, caddy 2.0.0 was released. Is there any progress on 
packaging?

Bug#961361: src:prads: use mktemp instead of tempfile

[Clint Adams]

Package: src:prads
Version: 0.3.3-1.1
Severity: minor
Tags: patch

This file doesn't appear to be part of the .deb, but in case it makes
its way in, tempfile has been deprecated for years.

diff --git a/doc/prads.rc b/doc/prads.rc
index 58a2835..107955e 100755
--- a/doc/prads.rc
+++ b/doc/prads.rc
@@ -52,7 +52,7 @@ fi
 
 case "$1" in
start)
-   output=$(/bin/tempfile -s.prads)
+   output=$(mktemp --suffix=.prads)
log_daemon_msg "Starting $DESC" 
log_progress_msg $NAME
if start-stop-daemon \

Bug#961360: r-cran-fontquiver: autopkgtest failure

[Sebastian Ramacher]

Source: r-cran-fontquiver
Version: 0.2.1-3
Severity: serious

The autopkgtest of r-cran-fontquiver fails in unstable:
| > test_check("fontquiver")
| ── 1. Error: Bitstream Vera files are found (@test-fonts.R#14)  

| Internal error: cannot find fontVera.ttf
| Backtrace:
|  1. fontquiver:::check_fontset_files(...)
|  2. base::Map(...)
|  3. base::mapply(FUN = f, ..., SIMPLIFY = FALSE)
|  5. base::lapply(names(styles), font_getter, variant = variant)
|  6. fontquiver:::FUN(X[[i]], ...)
|  7. fontquiver:::font_get("Bitstream Vera", variant, style, pkg = 
"fontBitstreamVera")
|  8. fontquiver:::concat_font(std_name, base, "ttf", package = pkg)
|
| ── 2. Error: Liberation files are found (@test-fonts.R#24)  

| Internal error: cannot find fontLiberationSans-Regular.ttf
| Backtrace:
|  1. fontquiver:::check_fontset_files(fontset_liberation_files, 
fontset_liberation)
|  2. base::Map(...)
|  3. base::mapply(FUN = f, ..., SIMPLIFY = FALSE)
|  5. base::lapply(names(styles), font_getter, variant = variant)
|  6. fontquiver:::FUN(X[[i]], ...)
|  7. fontquiver:::font_get("Liberation", variant, style, pkg = 
"fontLiberation")
|  8. fontquiver:::concat_font(std_name, base, "ttf", package = pkg)
|
| ── 3. Error: throw when malformed list is supplied 
(@test-html-dependency.R#5)  
| Internal error: cannot find fontVera.ttf
| Backtrace:
|  1. fontquiver:::fontset_bitstream_vera()
|  2. fontquiver:::font_get("Bitstream Vera", variant, style, pkg = 
"fontBitstreamVera")
|  3. fontquiver:::concat_font(std_name, base, "ttf", package = pkg)
|
| ── 4. Error: font collections are spliced (@test-html-dependency.R#14)  

| Internal error: cannot find fontVera.ttf
| Backtrace:
|  1. fontquiver::font_variants("Bitstream Vera")
|  2. base::Map(...)
|  3. base::mapply(FUN = f, ..., SIMPLIFY = FALSE)
|  5. base::lapply(styles, props$getter, variant = variant_name)
|  6. fontquiver:::FUN(X[[i]], ...)
|  7. fontquiver:::font_get("Bitstream Vera", variant, style, pkg = 
"fontBitstreamVera")
|  8. fontquiver:::concat_font(std_name, base, "ttf", package = pkg)
|
| ══ testthat results  
═══
| [ OK: 2 | SKIPPED: 1 | WARNINGS: 0 | FAILED: 4 ]
| 1. Error: Bitstream Vera files are found (@test-fonts.R#14) 
| 2. Error: Liberation files are found (@test-fonts.R#24) 
| 3. Error: throw when malformed list is supplied (@test-html-dependency.R#5) 
| 4. Error: font collections are spliced (@test-html-dependency.R#14) 

| Error: testthat unit tests failed
| Execution halted
| autopkgtest [13:14:48]: test run-unit-test: ---]
| autopkgtest [13:14:48]: test run-unit-test:  - - - - - - - - - - results - - 
- - - - - - - -
| run-unit-testFAIL non-zero exit status 1

See
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-fontquiver/5604728/log.gz

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#961359: src:remem: use mktemp instead of tempfile

[Clint Adams]

Package: src:remem
Version: 2.12-7
Severity: normal
Tags: patch

tempfile has been deprecated for years.


diff --git a/debian/postinst b/debian/postinst
index 9811553..1bfcc39 100644
--- a/debian/postinst
+++ b/debian/postinst
@@ -18,8 +18,7 @@ scope=memory
 program=/usr/bin/ra-index
 config_file=/etc/savantrc
 emacs_el_start=/etc/emacs/site-start.d/50remembrance-agent.el
-tmp_file=`/bin/tempfile`
-#tmp_file=/tmp/${package}.el
+tmp_file=$(mktemp)
 
 # First, per policy call emacs-install
 /usr/lib/emacsen-common/emacs-package-install ${package}

Bug#961259: dbab: daemon start/stop on install/remove

[Tong Sun]

On Fri, May 22, 2020 at 3:54 AM Kevin Ryde  wrote:
>
> Package: dbab
> Version: 1.5.01-1
> Severity: normal
>
> Under the standard "init", on first installing the dbab package, the
> dbab-svr daemon is not started.  And on a remove or purge, it is not
> stopped (that's after a fix to /etc/init.d/dbab so stop works).
>
> Letting dh_installinit put code into postinst etc has done the right
> thing for me in a package of my own, for under init at least.

Would you explain how you did it, or, better, how can we make mine
works please, Kevin?

As you can see I'm struggling to get the whole init thing working as
it has not been my cup of tea.

PS.

Here is an alternative solution to having everything installed to your host --
https://github.com/suntong/dbab-packer/tree/master/build-dbab

Please give it a try if you can.


thanks

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

[Bernhard Übelacker]

Dear Maintainer, hello Mehturt,
I guess the missing debug information is contained in libcurl3-dbg [1].

I tried to find out to which line this address in Mehturt's backtrace
points to and came to this location:

  (gdb) bt
  #0  0x777cd4d7 in Curl_close (data=0x5579f6c0) at url.c:399
  #1  0x874b in HttpsMethod::~HttpsMethod (this=0x7fffe470, 
__in_chrg=) at ./methods/https.cc:538
  #2  main (argv=) at ./methods/https.cc:546

  https://sources.debian.org/src/curl/7.52.1-5+deb9u10/lib/url.c/#L399
  https://sources.debian.org/src/apt/1.4.10/methods/https.cc/#L538

In my opinion the instruction "mov0x60(%rbx),%rdi" is executed, for Mehturt,
while $rbx contains no valid pointer.

The crash did not show up in my test VM. Attached an example debug session
to debug to this location.

@Mehturt: maybe you can still install libcurl3-dbg and inspect the core again.
(Maybe adding a "display/i $pc" and "print/x $rbx", before any "bt full")


Maybe related, upstream has added a null pointer check to Curl_close.
  https://sources.debian.org/src/curl/7.68.0-1/lib/url.c/#L325

Kind regards,
Bernhard

[1] 
https://snapshot.debian.org/package/curl/7.52.1-5%2Bdeb9u10/#libcurl3-gnutls_7.52.1-5:2b:deb9u10
# Stretch/oldstable amd64 qemu VM 2020-05-23



#sources.list
deb http://192.168.178.25:/debian-9-stretch-debug.mirrors.debian.org/ 
stretch-debug main
deb http://192.168.178.25:/debian-9-stretch-debug.mirrors.debian.org/ 
stretch-proposed-updates-debug main contrib non-free

#approx.conf
debian-9-stretch-deb.debian.org 
http://deb.debian.org/debian/
debian-9-stretch-security.debian.orghttp://security.debian.org/
debian-9-stretch-debug.mirrors.debian.org   
http://debug.mirrors.debian.org/debian-debug/


# or https://wiki.debian.org/AutomaticDebugPackages




apt update
apt dist-upgrade

apt install systemd-coredump


# https://github.com/matrix-org/synapse/blob/master/INSTALL.md

apt install -y lsb-release wget apt-transport-https
wget -O /usr/share/keyrings/matrix-org-archive-keyring.gpg 
https://packages.matrix.org/debian/matrix-org-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/matrix-org-archive-keyring.gpg] 
https://packages.matrix.org/debian/ $(lsb_release -cs) main" | tee 
/etc/apt/sources.list.d/matrix-org.list
apt update
apt install matrix-synapse-py3

# no crash




root@debian:~# dpkg -S /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
libcurl3-gnutls:amd64: /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
root@debian:~# dpkg -l | grep libcurl3-gnutls
ii  libcurl3-gnutls:amd64 7.52.1-5+deb9u10  amd64   
 easy-to-use client-side URL transfer library (GnuTLS flavour)




apt install gdb apt-transport-https-dbgsym libcurl3-dbg




rm matrix-synapse-py3_1.13.0+stretch1_amd64.deb

gdb -q
set width 0
set pagination off
file /usr/bin/apt
set detach-on-fork off
set follow-fork-mode child
set follow-exec-mode new
b HttpsMethod::~HttpsMethod
y
run download matrix-synapse-py3
info inferiors
inferior 1
cont
info inferiors
inferior 1
set detach-on-fork on
cont
info inferiors
bt
cont
stepi
stepi









benutzer@debian:~$ rm matrix-synapse-py3_1.13.0+stretch1_amd64.deb ^C
benutzer@debian:~$ gdb -q
(gdb) set width 0
(gdb) set pagination off
(gdb) file /usr/bin/apt
Reading symbols from /usr/bin/apt...(no debugging symbols found)...done.
(gdb) set detach-on-fork off
(gdb) set follow-fork-mode child
(gdb) set follow-exec-mode new
(gdb) b HttpsMethod::~HttpsMethod
Function "HttpsMethod::~HttpsMethod" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (HttpsMethod::~HttpsMethod) pending.
(gdb) run download matrix-synapse-py3
Starting program: /usr/bin/apt download matrix-synapse-py3
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New process 3044]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Reading symbols from 
/usr/lib/debug/.build-id/77/5143e680ff0cd4cd51cce1ce8ca216e635a1d6.debug...done.
Reading symbols from 
/usr/lib/debug/.build-id/db/2caeeec37482a98ab1416d0a9afe2944930de9.debug...done.
Reading symbols from 
/usr/lib/debug/.build-id/ea/d5fd817712e63c1212d1ee7d7ee1b9c29f93a7.debug...done.
Reading symbols from 
/usr/lib/debug/.build-id/16/d609487bcc4acbac29a4eaa2dda0d2f56211ec.debug...done.
Reading symbols from 
/usr/lib/debug/.build-id/4e/49714c557ce0472c798f39365ca10f9c0e1933.debug...done.
Reading symbols from 
/usr/lib/debug/.build-id/60/6df9c355103e82140d513bc7a25a635591c153.debug...done.
process 3044 is executing new program: /usr/bin/dpkg
[New process 3044]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Inferior 3 (process 3044) exited normally]
(gdb) info inferiors
  Num  Description   Executable
  1process 3040 

Bug#958710: ITP: nss-tls -- encrypted glibc name resolving library which uses DNS-over-HTTPS (DoH)

[Kan-Ru Chen]

Working on it :)

On Fri, May 22, 2020, at 5:36 PM, Petter Reinholdtsen wrote:
> Hi,
> 
> Any news on getting nss-tls into Debian?
> -- 
> Happy hacking
> Petter Reinholdtsen
>

Bug#961358: ITP: vf1 -- command-line gopher client

[Ryan Kavanagh]

Package: wnpp
Severity: wishlist
Owner: Ryan Kavanagh 

* Package name: vf1
  Version : 0.0.11
  Upstream Author : Solderpunk 
* URL : https://github.com/solderpunk/VF-1/
* License : BSD
  Programming Lang: Python 3
  Description : command-line gopher client

VF-1 is a full-featured gopher client. Its features include
 * Bookmarking
 * Configurable MIME-type handlers
 * line wrapping
 * TLS support
 * visiting a queue of links (the "tour" feature)
 * Veronica search

vf-1 has been my primary gopher client for close to a year now. I intend
to package it under the PAPT umbrella.

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


signature.asc
Description: PGP signature

Bug#961311: ssh-agent.service: cannot work without x11-common installed

[Colin Watson]

On Sat, May 23, 2020 at 08:18:55PM +0800, Paul Wise wrote:
> On Sat, 2020-05-23 at 13:07 +0100, Colin Watson wrote:
> > What do you think?
> 
> I don't think that will work because neither of the DISPLAY nor
> WAYLAND_DISPLAY environment variables are set for user services since
> they are user services *not* session services and systemd does not
> support session services.

OK, fair point.

> You could of course check the session type, but I'm not sure what sets
> that environment variable and if it is present for all Wayland
> compositors. It is also a per-session variable rather than per-user
> variable. So I think my idea of checking if Xsession.options exists is
> best after all.

My concern about that is that it's about what's installed, not what's
active/running for that particular user.  It may not matter in your case
but I'm sure cutting that corner is going to be wrong for somebody.

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

Bug#570376: texdoc barfs if BROWSER has multiple colon-separated commands

[Hilmar Preuße]

Am 18.02.2010 um 13:44 teilte Julian Gilbey mit:

Hi,

> I try running the command "texdoc eqnarray" and I get the error
> message:
> sh: links:lynx: not found
> 
> This is because my BROWSER environment variable contains "links:lynx",
> as allowed in the specification of the BROWSER variable.
> 
> So texdoc should parse this variable (and perhaps others), using the
> first one available.
> 
Somehow changed on TL 2020, but not solved.

hille@debian-amd64-sid:~$ export BROWSER="links:lynx"
hille@debian-amd64-sid:~$ texdoc progress20030701
sh: 1: links: not found
texdoc error: Failed to execute: links
"/usr/share/texlive/texmf-dist/doc/latex/progress/progress20030701.html"
hille@debian-amd64-sid:~$ which lynx
/usr/bin/lynx

Works when links is installed, but fails to do a fail over to the second
entry in list.

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



signature.asc
Description: OpenPGP digital signature

Bug#961357: r-cran-etm: autopktest failure

[Sebastian Ramacher]

Source: r-cran-etm
Version: 1.1-1
Severity: serious

r-cran-etm's autopktest currently fails with
| --- tests.etm.Rout.save_  2020-05-19 15:07:33.895363332 +
| +++ tests.etm.Rout_   2020-05-19 15:07:33.899363322 +
| @@ -554,16 +554,21 @@
|  +   cens.name = "cens", keep = "cova")
|  > 
|  > newdat
| -  id entry exit from   to cova
| -1  1 03011
| -2  1 36121
| -3  2 04010
| -4  2 49120
| -5  3 03011
| -6  3 38121
| -7  4 06020
| -8  5 08021
| -9  6 090 cens1
| +   id entry exit from   to cova
| +1   1 03011
| +2   1 36121
| +3   1 662 cens1
| +4   2 04010
| +5   2 49120
| +6   2 992 cens0
| +7   3 03011
| +8   3 38121
| +9   3 882 cens1
| +10  4 06020
| +11  4 662 cens0
| +12  5 08021
| +13  5 882 cens1
| +14  6 090 cens1
|  > 
|  > ref <- data.frame(id = c(1, 1, 2, 2, 3, 3, 4, 5, 6),
|  +   entry = c(0, 3, 0, 4, 0, 3, 0, 0, 0),
| @@ -575,7 +580,13 @@
|  > ref$to <- factor(as.character(ref$to), levels = c("0", "1", "2", "cens"))
|  > 
|  > all.equal(ref, newdat)
| -[1] TRUE
| +[1] "Attributes: < Component \"row.names\": Numeric: lengths (9, 14) differ 
>"
| +[2] "Component \"id\": Numeric: lengths (9, 14) differ"  
 
| +[3] "Component \"entry\": Numeric: lengths (9, 14) differ"   
 
| +[4] "Component \"exit\": Numeric: lengths (9, 14) differ"
 
| +[5] "Component \"from\": 'current' is not a factor"  
 
| +[6] "Component \"to\": 'current' is not a factor"
 
| +[7] "Component \"cova\": Numeric: lengths (9, 14) differ"
 
|  > 
|  > 
|  > ##
| autopkgtest [15:07:34]: test run-unit-test: ---]
| autopkgtest [15:07:34]: test run-unit-test:  - - - - - - - - - - results - - 
- - - - - - - -
| run-unit-testFAIL non-zero exit status 1

See
https://ci.debian.net/data/autopkgtest/unstable/amd64/r/r-cran-etm/5565165/log.gz

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

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

[Michael Biebl]

Am 23.05.20 um 02:59 schrieb Vincent Lefevre:
> On 2020-05-22 23:53:58 +0200, Michael Biebl wrote:
>> This is strange. Something is triggering the start of systemd-logind
> 
> What do you mean by "start of systemd-logind"?
> 
> On my machine, systemd-logind is started early at boot time and
> never quits.

You said:

> The running instance cannot be stopped as it is automatically
> restarted. 

when I adviced you to stop the running systemd-logind.service and
starting logind by hand.




signature.asc
Description: OpenPGP digital signature

Bug#961356: src:dnprogs: use mktemp instead of tempfile

[Clint Adams]

Package: src:dnprogs
Version: 2.65
Severity: normal
Tags: patch

tempfile has been deprecated for years and mktemp is guaranteed
to exist on a Debian system.

diff --git a/scripts/setup.sh b/scripts/setup.sh
index a0a162f..b4be03e 100644
--- a/scripts/setup.sh
+++ b/scripts/setup.sh
@@ -3,13 +3,7 @@
 # Configure /etc/decnet.conf
 #
 
-# Use a temp file
-if [ -x /bin/tempfile ]
-then
-  CONFFILE="`tempfile`"
-else
-  CONFFILE="/tmp/decnet.conf$$"
-fi
+CONFFILE="$(mktemp)"
 REALFILE=/etc/decnet.conf
 
 if [ -f "$REALFILE" ]

Bug#961355: allegro5: Hardcoded font dep ttf-dejavu no longer exists

[Boyuan Yang]

Source: allegro5
Severity: grave
Version: 2:5.2.6.0-1
Tags: sid bullseye
X-Debbugs-CC: than...@debian.org gus...@debian.org

Dear Debian allegro5 maintainers,

As in https://bugs.debian.org/872809 , the following transitional font
packages were removed:

* ttf-dejavu
* ttf-dejavu-core
* ttf-dejavu-extra

Your packages still depend and build-depend on those transitional
packages, which would render your packages uninstallable.

Please note that only replacing the dependencies in debian/control file
is not an option. According to codesearch result in 
https://codesearch.debian.net/search?q=package%3Aallegro5+ttf-dejavu ,
the source code of your package is hardcoding ttf-dejavu in various
places. Please consider working on updating debian-specific patches to
fix those occurrences.

-- 
Best Regards,
Boyuan Yang


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

Bug#961332: gnome-flashback: System indicators (volume, bluetooth, ...) do not appear

[Timothy Allen]

Package: gnome-flashback
Version: 3.36.3-1
Severity: normal

Dear Maintainer,

First, thank you for packaging and maintaining gnome-flashback!
It's really helped my older laptop stay useful and pleasant
to use, even as the full GNOME 3 stack is optimised for
higher-end hardware.

Recently (and I'm afraid I don't have an exact date, although
I'm pretty user it was the 3.34 → 3.36 upgrade) gnome-flashback's
standard system indicators (the volume control, Bluetooth,
the battery charging indicator, etc.) have stopped appearing in the
notification area. Other indicators (VLC, Network Manager) appear
just fine, but the system indicators are missing. This is still
true after logging out and back in, and after rebooting.

Full disclosure: I normally use gnome-flashback with the i3
window manager rather than Metacity, according to the instructions in
https://zork.net/~st/jottings/gnome-i3.html - although the only
difference between gnome-flashback's stock `gnome-flashback-metacity.session`
file and mine is that I've swapped `metacity` for
`i3` and removed `gnome-panel`. Nevertheless, the missing system
indicators are still missing if I log into a standard "GNOME Flashback
(Metacity)" session rather than my custom one.



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

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

Versions of packages gnome-flashback depends on:
ii  gnome-flashback-common   3.36.3-1
ii  libasound2   1.2.2-2.1
ii  libatk1.0-0  2.36.0-2
ii  libc62.30-8
ii  libcairo21.16.0-4
ii  libcanberra-gtk3-0   0.30-7
ii  libcanberra0 0.30-7
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-4
ii  libgdm1  3.34.1-3
ii  libglib2.0-0 2.64.2-1
ii  libgnome-bluetooth13 3.34.1-1
ii  libgnome-desktop-3-193.36.2-1
ii  libgnome-panel0  3.36.1-1+b1
ii  libgtk-3-0   3.24.20-1
ii  libibus-1.0-51.5.22-5
ii  libpam0g 1.3.1-5
ii  libpango-1.0-0   1.44.7-4
ii  libpangocairo-1.0-0  1.44.7-4
ii  libpolkit-agent-1-0  0.105-26
ii  libpolkit-gobject-1-00.105-26
ii  libpulse-mainloop-glib0  13.0-5
ii  libpulse013.0-5
ii  libsystemd0  245.5-3
ii  libupower-glib3  0.99.11-2
ii  libx11-6 2:1.6.9-2+b1
ii  libx11-xcb1  2:1.6.9-2+b1
ii  libxcb-randr01.14-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-2
ii  libxi6   2:1.7.9-1
ii  libxkbfile1  1:1.1.0-1
ii  libxrandr2   2:1.5.1-1
ii  libxxf86vm1  1:1.1.4-1+b2

Versions of packages gnome-flashback recommends:
ii  dbus   1.12.16-2
ii  gnome-settings-daemon  3.36.1-1
ii  libpam-gnome-keyring   3.36.0-1

Versions of packages gnome-flashback suggests:
ii  gnome-power-manager  3.32.0-2

-- no debconf information

Bug#961354: src:mod-mono: use mktemp instead of tempfile

[Clint Adams]

Package: src:mod-mono
Version: 3.8-3
Severity: normal
Tags: patch

tempfile has been deprecated for years

diff --git a/debian/libapache2-mod-mono.config 
b/debian/libapache2-mod-mono.config
index 6cbe7b0..bf6e8bb 100644
--- a/debian/libapache2-mod-mono.config
+++ b/debian/libapache2-mod-mono.config
@@ -5,7 +5,7 @@ db_version 2.0
 db_capb backup
 db_title Apache 2.2 mod-mono
 
-tempfile=`/bin/tempfile`
+tempfile=`mktemp`
 
 # Figure out which module we want to connect to
 USE_MONO_SERVER=none