Bug#940686: buster-pu: package uim_1.8.8-4+deb10u2

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Thu, 2019-09-19 at 10:24 +0900, NOKUBI Takatsugu wrote:
> We uim maintainers had a critical report #939588.
> We made a transition package for libuim-data on buster, but
> stretch's libuim-data package contains postrm and it causes
> removing essential configration files.
> So we made dummpy package and re-generate essential files on
> postinst.
> 
> I already uploaded it. And the following is debdiff:

+uim (1:1.8.8-4+deb10u2) buster; urgency=medium

That version is higher than the package in unstable, which is wrong.

Moreover, the package obviously landed in NEW. I have asked ftp-master
to reject it, partly due to the broken version number, but also please
*do not* upload packages to {,old}stable that will involve NEW without
an explicit ACK from the Release Team.

Regards,

Adam

Bug#940691: texlive-bin FTCBFS: missing build dependency for tangle

[Norbert Preining]

tag 940691 + pending
thanks

Hi Helmut,

On Thu, 19 Sep 2019, Helmut Grohne wrote:
> texlive-bin fails to cross build from source, because it fails to find a
> native tangle. tangle resides in texlive-binaries, which is built from
> texlive-bin, so we cannot just add the dependency. It's needed for cross
> compilation only though, so the cross profile is applicable here.
> Indeed, just adding that dependency makes texlive-bin cross buildable.
> Please consider applying the attached patch.

Interesting. So cross compilation does not allow the binaries already
created to be run.

Thanks for the patch, already put in our git repository, will be in the
next upload

Best

Norbert

--
PREINING Norbert   http://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#930264: DMR radio and ModemManager

[Iain Learmonth]

Hi,

On Tue, 27 Aug 2019 13:42:01 +0200 Aleksander Morgado
 wrote:
> Iain, could you let me know the full lsusb -v output of that specific DMR 
> radio? I need to understand whether the device is wrongly claiming AT 
> protocol support in the ttyACM interface or not.

I think from the output, the answer is yes.

Thanks,
Iain.

---


Bus 005 Device 006: ID 28e9:018a GD32Microelectronics GD32 Virtual
ComPort in FS Mode
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass2 Communications
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x28e9
  idProduct  0x018a
  bcdDevice1.00
  iManufacturer   1
  iProduct2
  iSerial 3
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   0x0043
bNumInterfaces  2
bConfigurationValue 1
iConfiguration  0
bmAttributes 0x80
  (Bus Powered)
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 2 Communications
  bInterfaceSubClass  2 Abstract (modem)
  bInterfaceProtocol  1 AT-commands (v.25ter)
  iInterface  0
  CDC Header:
bcdCDC   1.10
  CDC Call Management:
bmCapabilities   0x00
bDataInterface  1
  CDC ACM:
bmCapabilities   0x02
  line coding and serial state
  CDC Union:
bMasterInterface0
bSlaveInterface 1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0008  1x 8 bytes
bInterval  10
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass10 CDC Data
  bInterfaceSubClass  0
  bInterfaceProtocol  0
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03  EP 3 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0



signature.asc
Description: OpenPGP digital signature

Bug#940695: micro-httpd FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: micro-httpd
Version: 20051212-15.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

micro-httpd fails to cross build from source, because debian/rules uses
the build architecture compiler as a make default for CC. The easiest
way of fixing that is letting dpkg's buildtools.mk initialize it. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru micro-httpd-20051212/debian/changelog 
micro-httpd-20051212/debian/changelog
--- micro-httpd-20051212/debian/changelog   2016-07-02 18:14:04.0 
+0200
+++ micro-httpd-20051212/debian/changelog   2019-09-19 06:05:43.0 
+0200
@@ -1,3 +1,10 @@
+micro-httpd (20051212-15.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCFBS: Seed CC from dpkg's buildtools.mk. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 19 Sep 2019 06:05:43 +0200
+
 micro-httpd (20051212-15.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru micro-httpd-20051212/debian/rules 
micro-httpd-20051212/debian/rules
--- micro-httpd-20051212/debian/rules   2016-07-02 18:14:04.0 +0200
+++ micro-httpd-20051212/debian/rules   2019-09-19 06:04:09.0 +0200
@@ -4,6 +4,7 @@
 BIN= micro_httpd
 
 include debian/debian-vars.mk
+-include /usr/share/dpkg/buildtools.mk
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic

Bug#940692: gffread FTCBFS: uses the build architecture compiler as linker

[Helmut Grohne]

Source: gffread
Version: 0.11.4-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

gffread fails to cross build from source, because it uses the build
architecture compiler as linker. The upstream Makefile stores the linker
in the non-standard LINKER variable, which dh_auto_build does not
supply. We'll have to supply it manually. Alternatively, you can propose
that upstream defaults LINKER to CXX (which should be sane almost
everywhere). I'm attaching a patch for supplying LINKER for your
convenience.

Helmut
diff --minimal -Nru gffread-0.11.4/debian/changelog 
gffread-0.11.4/debian/changelog
--- gffread-0.11.4/debian/changelog 2019-08-08 11:54:09.0 +0200
+++ gffread-0.11.4/debian/changelog 2019-09-19 06:09:33.0 +0200
@@ -1,3 +1,10 @@
+gffread (0.11.4-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass LINKER to make. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 19 Sep 2019 06:09:33 +0200
+
 gffread (0.11.4-1) unstable; urgency=medium
 
   * New upstream version
diff --minimal -Nru gffread-0.11.4/debian/rules gffread-0.11.4/debian/rules
--- gffread-0.11.4/debian/rules 2019-08-08 11:54:09.0 +0200
+++ gffread-0.11.4/debian/rules 2019-09-19 06:09:30.0 +0200
@@ -12,6 +12,9 @@
 %:
dh $@
 
+override_dh_auto_build:
+   dh_auto_build -- 'LINKER=$$(CXX)'
+
 ### When overriding auto_test make sure DEB_BUILD_OPTIONS will be respected
 #override_dh_auto_test:
 #ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))

Bug#940691: texlive-bin FTCBFS: missing build dependency for tangle

[Helmut Grohne]

Source: texlive-bin
Version: 2019.20190605.51237-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

texlive-bin fails to cross build from source, because it fails to find a
native tangle. tangle resides in texlive-binaries, which is built from
texlive-bin, so we cannot just add the dependency. It's needed for cross
compilation only though, so the cross profile is applicable here.
Indeed, just adding that dependency makes texlive-bin cross buildable.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru texlive-bin-2019.20190605.51237/debian/changelog 
texlive-bin-2019.20190605.51237/debian/changelog
--- texlive-bin-2019.20190605.51237/debian/changelog2019-07-10 
02:59:23.0 +0200
+++ texlive-bin-2019.20190605.51237/debian/changelog2019-09-19 
06:02:02.0 +0200
@@ -1,3 +1,11 @@
+texlive-bin (2019.20190605.51237-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Add texlive-binaries  to Build-Depends to have
+a native tangle. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 19 Sep 2019 06:02:02 +0200
+
 texlive-bin (2019.20190605.51237-2) unstable; urgency=medium
 
   * Cherry pick various fixes:
diff --minimal -Nru texlive-bin-2019.20190605.51237/debian/control 
texlive-bin-2019.20190605.51237/debian/control
--- texlive-bin-2019.20190605.51237/debian/control  2019-07-10 
02:59:23.0 +0200
+++ texlive-bin-2019.20190605.51237/debian/control  2019-09-19 
06:01:58.0 +0200
@@ -36,6 +36,7 @@
   m4 (>= 1.4.16),
   sharutils,
   texinfo,
+  texlive-binaries ,
   time,
   zlib1g-dev | libz-dev
 Standards-Version: 4.2.1

Bug#940694: dbus-cpp FTCBFS: forces build architecture compilers

[Helmut Grohne]

Source: dbus-cpp
Version: 5.0.0+18.04.20171031-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

dbus-cpp fails to cross build from source, because debian/rules forces
build architecture compilers upon cmake as make defaults in
debian/rules. dh_auto_configure also supplies a sane compiler choice and
environment variables are also honoured by it. There is no benefit in
assigning them here. After fixing that, the cross build runs into the
same FTBFS as observed by reproducible builds. Please consider applying
the attached patch and close this bug when doing so.

Helmut
diff --minimal -Nru dbus-cpp-5.0.0+18.04.20171031/debian/changelog 
dbus-cpp-5.0.0+18.04.20171031/debian/changelog
--- dbus-cpp-5.0.0+18.04.20171031/debian/changelog  2018-07-24 
10:27:30.0 +0200
+++ dbus-cpp-5.0.0+18.04.20171031/debian/changelog  2019-09-19 
06:18:18.0 +0200
@@ -1,3 +1,9 @@
+dbus-cpp (5.0.0+18.04.20171031-3) UNRELEASED; urgency=medium
+
+  * Improve cross building: Don't override compilers. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 19 Sep 2019 06:18:18 +0200
+
 dbus-cpp (5.0.0+18.04.20171031-2) unstable; urgency=medium
 
   * Orphan package.
diff --minimal -Nru dbus-cpp-5.0.0+18.04.20171031/debian/rules 
dbus-cpp-5.0.0+18.04.20171031/debian/rules
--- dbus-cpp-5.0.0+18.04.20171031/debian/rules  2018-07-24 10:27:30.0 
+0200
+++ dbus-cpp-5.0.0+18.04.20171031/debian/rules  2019-09-19 06:18:17.0 
+0200
@@ -18,8 +18,6 @@
 override_dh_auto_configure:
dh_auto_configure -- \

-DCMAKE_INSTALL_LIBEXECDIR=/usr/lib/$(DEB_HOST_MULTIARCH)/dbus-cpp \
-   -DCMAKE_C_COMPILER=$(CC) \
-   -DCMAKE_CXX_COMPILER=$(CXX) \
-DDBUS_CPP_VERSION_MAJOR=$(MAJOR) \
-DDBUS_CPP_VERSION_MINOR=$(MINOR) \
-DDBUS_CPP_VERSION_PATCH=$(PATCH)

Bug#940693: nss-wrapper FTCBFS: does not pass cross flags to cmake

[Helmut Grohne]

Source: nss-wrapper
Version: 1.1.3-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

nss-wrapper fails to cross build from source, because it does not pass
the various cross compilation flags to cmake. The easiest way of doing
so - using dh_auto_configure - makes nss-wrapper cross buildable. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru nss-wrapper-1.1.3/debian/changelog 
nss-wrapper-1.1.3/debian/changelog
--- nss-wrapper-1.1.3/debian/changelog  2016-12-03 00:43:26.0 +0100
+++ nss-wrapper-1.1.3/debian/changelog  2019-09-19 06:15:12.0 +0200
@@ -1,3 +1,10 @@
+nss-wrapper (1.1.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass cross flags to cmake. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 19 Sep 2019 06:15:12 +0200
+
 nss-wrapper (1.1.3-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru nss-wrapper-1.1.3/debian/rules 
nss-wrapper-1.1.3/debian/rules
--- nss-wrapper-1.1.3/debian/rules  2016-12-03 00:32:05.0 +0100
+++ nss-wrapper-1.1.3/debian/rules  2019-09-19 06:15:00.0 +0200
@@ -4,9 +4,6 @@
 ldflags = $(shell dpkg-buildflags --get LDFLAGS)
 
 cmake_options = \
-   -DCMAKE_INSTALL_PREFIX=/usr \
-   -DCMAKE_VERBOSE_MAKEFILE=ON \
-   -DCMAKE_BUILD_TYPE=None \
-DCMAKE_C_FLAGS="$(cflags)" \
-DCMAKE_SHARED_LINKER_FLAGS="$(ldflags)" \
-DCMAKE_EXE_LINKER_FLAGS="$(ldflags)" \
@@ -28,8 +25,7 @@
 build-arch: obj/stamp
 
 obj/stamp: CMakeLists.txt
-   mkdir -p obj
-   cd obj && cmake $(cmake_options) ..
+   dh_auto_configure --builddirectory=obj  -- $(cmake_options)
$(MAKE) $(parallel) -C obj/
 ifeq "$(filter nocheck,$(DEB_BUILD_OPTIONS))" ""
$(MAKE) -C obj/ test ARGS="-V"

Bug#940681: elogind: Should only build-depend on libseccomp-dev on architectures supporting it

[Mark Hindley]

Control: tags -1 pending

Adrian,

On Thu, Sep 19, 2019 at 01:13:20AM +0200, John Paul Adrian Glaubitz wrote:
> Source: elogind
> Severity: normal
> 
> Hello!
> 
> Currently, elogind unconditionally build-depends on libseccomp-dev despite 
> the fact
> that not all supported architectures in Debian currently support libseccomp 
> [1].
> 
> This results elogind being BD-Uninstallable on a couple of architectures [2] 
> where
> the original systemd code builds fine [3].
> 
> Thus, could you modify your debian/control such that it adopts what systemd 
> does
> in this regard and if necessary make the necessary changes to elogind so it 
> can
> be built on architectures without libseccomp support?

Thanks for the pointer on this.

Yes, happily.

I have made the changes in git and it will be in the next upload.

Thanks.

Mark


signature.asc
Description: Digital signature

Bug#940690: nvidia-kernel-dkms: build fails with kernel built with different gcc version

[Celejar]

Package: nvidia-kernel-dkms
Version: 430.50-1
Severity: normal

Build fails on a Sid system, with gcc symlinked to gcc-9, running a
kernel built on a Buster system with gcc-8. Based on make.log and the
documentation in README.txt, I tried setting the CC environment variable
with:

CC=/usr/bin/gcc-8
export CC
aptitude
...

But the results were the same, with the installation process still
trying to use gcc 9.x.

-- Package-specific info:
uname -a:
Linux lila 4.19.72-lila #1 SMP Fri Sep 13 17:42:52 EDT 2019 x86_64 GNU/Linux

/proc/version:
Linux version 4.19.72-lila (@alice) (gcc version 8.3.0 (Debian 
8.3.0-6)) #1 SMP Fri Sep 13 17:42:52 EDT 2019

lspci 'display controller [030?]':
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 5500 
[8086:1616] (rev 09) (prog-if 00 [VGA controller])
Subsystem: Lenovo HD Graphics 5500 [17aa:2225]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

08:00.0 3D controller [0302]: NVIDIA Corporation GM108GLM [Quadro K620M / 
Quadro M500M] [10de:137a] (rev a2)
Subsystem: Lenovo GM108GLM [Quadro K620M / Quadro M500M] [17aa:2225]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-  [disabled]
Capabilities: 
Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw+ 1 root video  226,   0 Sep 17 23:28 /dev/dri/card0
crw-rw+ 1 root render 226, 128 Sep 17 23:28 /dev/dri/renderD128

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root  8 Sep 17 23:28 pci-:00:02.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Sep 17 23:28 pci-:00:02.0-render -> ../renderD128
video:x:44:

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root25 Nov 13  2018 /etc/alternatives/glx -> 
/usr/lib/nvidia/bumblebee
lrwxrwxrwx 1 root root51 Nov 13  2018 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root48 Nov 13  2018 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root48 Nov 13  2018 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root50 Nov 13  2018 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root50 Nov 13  2018 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root57 Nov 13  2018 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root57 Nov 13  2018 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root54 Nov 13  2018 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root54 Nov 13  2018 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root40 Nov 13  2018 
/etc/alternatives/glx--libGLX_indirect.so.0-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/libGLX_mesa.so.0
lrwxrwxrwx 1 root root40 Nov 13  2018 
/etc/alternatives/glx--libGLX_indirect.so.0-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/libGLX_mesa.so.0
lrwxrwxrwx 1 root root42 Nov 13  2018 
/etc/alternatives/glx--libGLX_indirect.so.0-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0
lrwxrwxrwx 1 root root42 Nov 13  2018 
/etc/alternatives/glx--libGLX_indirect.so.0-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0
lrwxrwxrwx 1 root root51 Nov 13  2018 
/etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root42 Nov 13  2018 
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> 
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root36 Nov 13  2018 
/etc/alternatives/glx--nvidia-bug-report.sh -> 
/usr/lib/nvidia/nvidia-bug-report.sh
lrwxrwxrwx 1 root root32 Nov 13  2018 
/etc/alternatives/glx--nvidia-modprobe.conf -> /etc/nvidia/nvidia-modprobe.conf
lrwxrwxrwx 1 root root23 Sep 18 08:03 /etc/alternatives/nvidia -> 
/usr/lib/nvidia/current
lrwxrwxrwx 1 root root50 Sep 18 08:03 
/etc/alternatives/nvidia--libEGL.so.1-i386-linux-gnu -> 

Bug#710440: upstream now provides a library

[Graham Percival]

Hi Barak and Micah,

As of scrypt-1.3.0, upstream now supports building a shared library with:

./configure --enable-libscrypt-kdf

(We named it libscrypt-kdf to avoid conflicts with the existing libscrypt [1]
library, which has slightly different functionality.)
[1] https://tracker.debian.org/pkg/libscrypt 

If/when you make a -dev package, I'd be happy to work with you if there's any
upstream changes that would make the process easier.

Cheers,
- Graham Percival, Tarsnap employee

Bug#940689: deepin-deb-installer: Chinese word display error in package Description

[Shengwen Xiao]

Package: deepin-deb-installer
Version: 1.3.0-1
Severity: minor

Dear Maintainer,

If one deb package's Description: use chinese word,these chinese word can't 
been display in deepin-deb-installer.

For example:

This deb package:
http://issuecdn.baidupcs.com/issue/netdisk/LinuxGuanjia/2.0.2/baidunetdisk_linux_2.0.2.deb

The control file's Description: only has chinese word "百度网盘".
These chinese word can't been display correct.


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

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

Versions of packages deepin-deb-installer depends on:
ii  libc6   2.28-10
ii  libdtkcore2 2.0.9.17-1
ii  libdtkwidget2   2.0.9.17-1
ii  libgcc1 1:8.3.0-6
ii  libqapt33.0.4-1
ii  libqt5core5a5.11.3+dfsg1-1
ii  libqt5gui5  5.11.3+dfsg1-1
ii  libqt5widgets5  5.11.3+dfsg1-1
ii  libstdc++6  8.3.0-6

deepin-deb-installer recommends no packages.

deepin-deb-installer suggests no packages.

-- no debconf information

Bug#940628: grub-efi-{non-i386/amd64}-bin: Missing multiboot.mod

[Elliott Mitchell]

On Wed, Sep 18, 2019 at 07:06:49AM +0100, Colin Watson wrote:
> On Tue, Sep 17, 2019 at 04:29:37PM -0700, Elliott Mitchell wrote:
> > This makes it impossible for GRUB to load Xen on any platform that is not
> > either i386 or amd64.  Xen has support for running on ARM platforms, but
> > with no bootloader...
> > 
> > For example there is known to be working UEFI third-stage firmware for
> > the Raspberry PI:
> > https://github.com/tianocore/edk2-platforms/tree/master/Platform/RaspberryPi/RPi3
> > 
> > The absence of /usr/lib/grub/arm64-efi/multiboot.mod means entries
> > generated by /etc/grub.d/20_linux_xen cannot work.
> 
> I don't understand this point.  20_linux_xen looks like this:
> 
> if ($grub_file --is-arm64-efi $current_xen); then
> xen_loader="xen_hypervisor"
> module_loader="xen_module"
> else
> if ($grub_file --is-x86-multiboot2 $current_xen); then
> xen_loader="multiboot2"
> module_loader="module2"
> else
> xen_loader="multiboot"
> module_loader="module"
> fi
> fi
> 
> So on ARM (64-bit, anyway) it should use xen_hypervisor, not multiboot.

Okay, this may not be an issue for 2.04-3, and instead merely a problem
with 2.02+dfsg1-20.  On 2.02+dfsg1-20, 20_linux_xen is missing the first
if, which means it tries to load multiboot.mod which doesn't exist.

For 2.02+dfsg1-20 and 2.04-3 though I note there is a
/usr/lib/grub/arm64-efi/xen_boot.mod, but no
/usr/lib/grub/arm64-efi/xen_hypervisor.mod.  I don't know too much about
GRUB's workings, but I'm suspicious of 'xen_loader="xen_hypervisor"'.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#940687: ucblogo: Missing corresponding source for configure

[Olly Betts]

Source: ucblogo
Version: 6.0+dfsg-2
Severity: serious
Tags: upstream
Justification: Policy 2.1.2

I noticed this comment in debian/rules:

# don't autoreconf, as configure is newer than configure.in
# -> configure.in doesn't contain wxwidgets related checks
dh $@ --without autoreconf

I've checked and this comment still seems to be correct for the current
package in unstable.

But that means we don't actually have the source code for configure,
which is required by DFSG2.

GPL2 (which is upstream's licence) also requires "complete corresponding
machine-readable source code" and includes "the scripts used to control
compilation and installation of the executable" in its definition of
that.

Have you tried asking upstream to fix this configure/configure.in
mismatch?

Cheers,
Olly

Bug#940686: buster-pu: package uim_1.8.8-4+deb10u2

[NOKUBI Takatsugu]

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

We uim maintainers had a critical report #939588.
We made a transition package for libuim-data on buster, but
stretch's libuim-data package contains postrm and it causes
removing essential configration files.
So we made dummpy package and re-generate essential files on postinst.

I already uploaded it. And the following is debdiff:

diff -Nru uim-1.8.8/debian/changelog uim-1.8.8/debian/changelog
--- uim-1.8.8/debian/changelog  2019-03-28 09:31:18.0 +0900
+++ uim-1.8.8/debian/changelog  2019-09-12 00:08:30.0 +0900
@@ -1,3 +1,18 @@
+uim (1:1.8.8-4+deb10u2) buster; urgency=medium
+
+  [ HIGUCHI Daisuke (VDR dai) ]
+  * resurrect libuim-data as a transitional package (Closes: #939588).
+After upgrading from stretch to buster, if purging libuim-data,
+its postrm script deletes /var/lib/uim/*.scm files required by uim.
+This libuim-data transitional package can be removed safely.
+
+  [ NOKUBI Takatsugu ]
+  * d/control: uim-data depends libuim-data dummy package,
+change the description.
+  * d/libuim-data.postint: re-register all modules, fix #939588
+
+ -- HIGUCHI Daisuke (VDR dai)   Thu, 12 Sep 2019 00:08:30 
+0900
+
 uim (1:1.8.8-4) unstable; urgency=medium
 
   [ YOSHINO Yoshihito ]
diff -Nru uim-1.8.8/debian/control uim-1.8.8/debian/control
--- uim-1.8.8/debian/control2019-03-27 23:08:38.0 +0900
+++ uim-1.8.8/debian/control2019-09-12 00:08:30.0 +0900
@@ -110,7 +110,7 @@
uim-ipa-x-sampa (<< 1:1.8.6+gh20161003.0.d63dadd-5~),
uim-look (<< 1:1.8.6+gh20161003.0.d63dadd-5~),
uim-common (<< 1:1.8.6+gh20161003.0.d63dadd-5~)
-Depends: m17n-db,
+Depends: m17n-db, libuim-data (>= ${source:Version}),
${misc:Depends}
 Multi-Arch: foreign
 Description: Universal Input Method - data files
@@ -122,6 +122,13 @@
  .
  This package contains the data files for uim.
 
+Package: libuim-data
+Depends: ${misc:Depends}, ${shlibs:Depends}
+Architecture: all
+Section: oldlibs
+Description: transitional package for uim-data
+ This is a transitional package. It will be removed next release.
+
 Package: libuim8
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}
diff -Nru uim-1.8.8/debian/libuim-data.postinst 
uim-1.8.8/debian/libuim-data.postinst
--- uim-1.8.8/debian/libuim-data.postinst   1970-01-01 09:00:00.0 
+0900
+++ uim-1.8.8/debian/libuim-data.postinst   2019-09-12 00:08:30.0 
+0900
@@ -0,0 +1,40 @@
+#!/bin/sh
+
+register_module() {
+PKGNAME=$1
+MODNAME=$2
+dpkg-query -W -f='${Status}\n' $PKGNAME 2>/dev/null | grep "not-installed" 
> /dev/null
+if [ $? = "1" ]
+then
+uim-module-manager --register $MODNAME --path /var/lib/uim
+fi
+}
+
+case "$1" in
+configure)
+   if which uim-module-manager >/dev/null 2>&1; then
+register_module uim-anthy anthy-utf8
+register_module uim-byeoru byeoru
+register_module uim-ipa-x-sampa ipa-x-sampa
+register_module uim-latin latin
+register_module uim-latin elatin
+register_module uim-look look
+register_module uim-m17nlib m17nlib
+register_module uim-pinyin pyload
+register_module uim-skk skk
+register_module uim-tcode tutcode
+register_module uim-viqr viqr
+   fi
+;;
+
+abort-upgrade|abort-remove|abort-deconfigure)
+
+;;
+
+*)
+echo "postinst called with unknown argument \`$1'" >&2
+exit 1
+;;
+esac
+
+exit 0
\ ファイル末尾に改行がありません
diff -Nru uim-1.8.8/debian/rules uim-1.8.8/debian/rules
--- uim-1.8.8/debian/rules  2019-03-27 23:08:38.0 +0900
+++ uim-1.8.8/debian/rules  2019-09-12 00:08:30.0 +0900
@@ -99,7 +99,8 @@
dh_installdocs -puim -puim-data \
-plibuim8 -plibuim-scm0 -plibuim-custom2 \
-puim-plugins \
-   -puim-el -puim-fep -puim-xim
+   -puim-el -puim-fep -puim-xim \
+   -plibuim-data
rm -f $(CURDIR)/debian/uim.docs
# arch:all
dh_installdocs --link-doc uim-data \
@@ -118,4 +119,5 @@
-puim-plugins \
-plibuim8 -plibuim-scm0 -plibuim-custom2 -plibuim-dev \
-puim-el -puim-fep -puim-xim \
+   -plibuim-data \
RELNOTE

Bug#939907: stretch-pu: package libsixel/1.5.2-2+deb9u1

[NOKUBI Takatsugu]

I uploaded fixed package for stretch.
This fix #931311, CVE-2018-14072 and CVE-2018-14073.

A little bit changed debdiff is here:

diff -Nru libsixel-1.5.2/debian/changelog libsixel-1.5.2/debian/changelog
--- libsixel-1.5.2/debian/changelog 2015-09-04 15:50:56.0 +0900
+++ libsixel-1.5.2/debian/changelog 2019-09-06 16:11:01.0 +0900
@@ -1,3 +1,17 @@
+libsixel (1.5.2-2+deb9u1) stretch; urgency=medium
+
+  * d/patches/0001-Add-malloc-size-check.patch: fix CVE-2018-19756
+  * d/patches/0002-assign-default-error-message.patch: fix CVE-2018-19757
+  * d/patches/0003-add-limitation-to-width-and-height.patch: fix CVE-2018-19759
+  * CVE-2018-19761 is not security issue
+  * d/patches/0004-size-check.patch: fix CVE-2018-19762
+  * CVE-2018-19763 is fixed by 0001-Add-malloc-size-check.patch
+  * d/patches/0005-check-error-for-jpeg_read_scanlines.patch: fix CVE-2019-3573
+  * d/patches/0006-check-number-of-repeat_count.patch: fix CVE-2019-3574
+  * d/patches/0007-fix-memory-leak.patch: fix CVE-2018-14072, CVE-2018-14073
+
+ -- NOKUBI Takatsugu   Fri, 06 Sep 2019 16:11:01 +0900
+
 libsixel (1.5.2-2) unstable; urgency=medium
 
   * Disable python.
diff -Nru libsixel-1.5.2/debian/patches/0001-Add-malloc-size-check.patch 
libsixel-1.5.2/debian/patches/0001-Add-malloc-size-check.patch
--- libsixel-1.5.2/debian/patches/0001-Add-malloc-size-check.patch  
1970-01-01 09:00:00.0 +0900
+++ libsixel-1.5.2/debian/patches/0001-Add-malloc-size-check.patch  
2019-09-06 16:11:01.0 +0900
@@ -0,0 +1,25 @@
+From: NOKUBI Takatsugu 
+Date: Wed, 7 Aug 2019 16:23:53 +0900
+Subject: Add malloc size check
+
+---
+ src/allocator.c | 6 ++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/src/allocator.c b/src/allocator.c
+index 216fa34..c33c74b 100644
+--- a/src/allocator.c
 b/src/allocator.c
+@@ -147,6 +147,12 @@ sixel_allocator_malloc(
+ assert(allocator);
+ assert(allocator->fn_malloc);
+ 
++if (n == 0) {
++sixel_helper_set_additional_message(
++"sixel_allocator_malloc: called with n == 0");
++return NULL;
++}
++
+ return allocator->fn_malloc(n);
+ }
+ 
diff -Nru libsixel-1.5.2/debian/patches/0002-assign-default-error-message.patch 
libsixel-1.5.2/debian/patches/0002-assign-default-error-message.patch
--- libsixel-1.5.2/debian/patches/0002-assign-default-error-message.patch   
1970-01-01 09:00:00.0 +0900
+++ libsixel-1.5.2/debian/patches/0002-assign-default-error-message.patch   
2019-09-06 16:11:01.0 +0900
@@ -0,0 +1,21 @@
+From: NOKUBI Takatsugu 
+Date: Fri, 9 Aug 2019 16:47:29 +0900
+Subject: assign default error message
+
+---
+ src/stb_image.h | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/src/stb_image.h b/src/stb_image.h
+index d0fa9c2..5f8f96d 100644
+--- a/src/stb_image.h
 b/src/stb_image.h
+@@ -875,6 +875,8 @@ static const char *stbi__g_failure_reason;
+ 
+ STBIDEF const char *stbi_failure_reason(void)
+ {
++   if (stbi__g_failure_reason == NULL)
++  stbi__g_failure_reason = "unknwon error, refer error message before 
assignment";
+return stbi__g_failure_reason;
+ }
+ 
diff -Nru 
libsixel-1.5.2/debian/patches/0003-add-limitation-to-width-and-height.patch 
libsixel-1.5.2/debian/patches/0003-add-limitation-to-width-and-height.patch
--- libsixel-1.5.2/debian/patches/0003-add-limitation-to-width-and-height.patch 
1970-01-01 09:00:00.0 +0900
+++ libsixel-1.5.2/debian/patches/0003-add-limitation-to-width-and-height.patch 
2019-09-06 16:11:01.0 +0900
@@ -0,0 +1,39 @@
+From: NOKUBI Takatsugu 
+Date: Tue, 20 Aug 2019 15:20:55 +0900
+Subject: add limitation to width and height
+
+---
+ include/sixel.h.in | 3 +++
+ src/decoder.c  | 5 +
+ 2 files changed, 8 insertions(+)
+
+diff --git a/include/sixel.h.in b/include/sixel.h.in
+index 397974f..8552c23 100644
+--- a/include/sixel.h.in
 b/include/sixel.h.in
+@@ -355,6 +355,9 @@ typedef int SIXELSTATUS;
+ #define SIXEL_OPTFLAG_VERSION  ('V')  /* -V, --version: show version 
and license info */
+ #define SIXEL_OPTFLAG_HELP ('H')  /* -H, --help: show this help */
+ 
++#define SIXEL_WIDTH_LIMIT   100
++#define SIXEL_HEIGHT_LIMIT  100
++
+ #if SIXEL_USE_DEPRECATED_SYMBOLS
+ /* output character size */
+ enum characterSize {
+diff --git a/src/decoder.c b/src/decoder.c
+index 98b5c30..e3fbd0d 100644
+--- a/src/decoder.c
 b/src/decoder.c
+@@ -303,6 +303,11 @@ sixel_decoder_decode(
+ goto end;
+ }
+ 
++if (sx > SIXEL_WIDTH_LIMIT || sy > SIXEL_HEIGHT_LIMIT) {
++status = SIXEL_BAD_INPUT;
++goto end;
++}
++
+ status = sixel_helper_write_image_file(indexed_pixels, sx, sy, palette,
+SIXEL_PIXELFORMAT_PAL8,
+decoder->output,
diff -Nru libsixel-1.5.2/debian/patches/0004-malloc-size-check.patch 
libsixel-1.5.2/debian/patches/0004-malloc-size-check.patch
--- 

Bug#940685: buster-pu: libsixel/1.8.2-1+deb10u1

[NOKUBI Takatsugu]

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

I'll upload a new version of libsixel for buster.
It contains many security fix reported by #931311

fixed package for unstable had already uploaded.
This is just a backports but almost same.

diff -Nru libsixel-1.8.2/debian/changelog libsixel-1.8.2/debian/changelog
--- libsixel-1.8.2/debian/changelog 2018-07-23 16:29:35.0 +0900
+++ libsixel-1.8.2/debian/changelog 2019-09-09 12:42:52.0 +0900
@@ -1,3 +1,17 @@
+libsixel (1.8.2-1+deb10u1) buster; urgency=high
+
+  * d/patches/0001-Add-malloc-size-check.patch: fix CVE-2018-19756
+  * d/patches/0002-assign-default-error-message.patch: fix CVE-2018-19757
+  * d/patches/0003-add-limitation-to-width-and-height.patch: fix CVE-2018-19759
+  * d/patches/0004-position-error-check.patch: fix CVE-2018-19761
+  * d/patches/0005-size-check.patch: fix CVE-2018-19762
+  * d/patches/0006-prevent-to-access-heap-overflow.patch: fix CVE-2018-19763
+  * d/patches/0007-check-error-for-jpeg_read_scanlines.patch: fix CVE-2019-3573
+  * d/patches/0008-check-number-of-repeat_count.patch: fix CVE-2019-3574
+  * security fix, closes: #931311
+
+ -- NOKUBI Takatsugu   Mon, 09 Sep 2019 12:42:52 +0900
+
 libsixel (1.8.2-1) unstable; urgency=medium
 
   * New upstream, security fix (closes: #903858)
diff -Nru libsixel-1.8.2/debian/patches/0001-Add-malloc-size-check.patch 
libsixel-1.8.2/debian/patches/0001-Add-malloc-size-check.patch
--- libsixel-1.8.2/debian/patches/0001-Add-malloc-size-check.patch  
1970-01-01 09:00:00.0 +0900
+++ libsixel-1.8.2/debian/patches/0001-Add-malloc-size-check.patch  
2019-09-09 12:42:52.0 +0900
@@ -0,0 +1,24 @@
+From: Takatsugu Nokubi 
+Date: Mon, 8 Jul 2019 13:46:11 +0900
+Subject: Add malloc size check
+
+---
+ src/allocator.c | 5 +
+ 1 file changed, 5 insertions(+)
+
+diff --git a/src/allocator.c b/src/allocator.c
+index b9b2d02..bb0c009 100644
+--- a/src/allocator.c
 b/src/allocator.c
+@@ -147,6 +147,11 @@ sixel_allocator_malloc(
+ assert(allocator);
+ assert(allocator->fn_malloc);
+ 
++if (n == 0) {
++sixel_helper_set_additional_message(
++"sixel_allocator_malloc: called with n == 0");
++return NULL;
++}
+ return allocator->fn_malloc(n);
+ }
+ 
diff -Nru libsixel-1.8.2/debian/patches/0002-assign-default-error-message.patch 
libsixel-1.8.2/debian/patches/0002-assign-default-error-message.patch
--- libsixel-1.8.2/debian/patches/0002-assign-default-error-message.patch   
1970-01-01 09:00:00.0 +0900
+++ libsixel-1.8.2/debian/patches/0002-assign-default-error-message.patch   
2019-09-09 12:42:52.0 +0900
@@ -0,0 +1,21 @@
+From: Takatsugu Nokubi 
+Date: Tue, 23 Jul 2019 17:12:43 +0900
+Subject: assign default error message
+
+---
+ src/stb_image.h | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/src/stb_image.h b/src/stb_image.h
+index 2673809..09ebbd5 100644
+--- a/src/stb_image.h
 b/src/stb_image.h
+@@ -845,6 +845,8 @@ static const char *stbi__g_failure_reason;
+ 
+ STBIDEF const char *stbi_failure_reason(void)
+ {
++   if (stbi__g_failure_reason == NULL)
++  stbi__g_failure_reason = "unknwon error, refer error message before 
assignment";
+return stbi__g_failure_reason;
+ }
+ 
diff -Nru 
libsixel-1.8.2/debian/patches/0003-add-limitation-to-width-and-height.patch 
libsixel-1.8.2/debian/patches/0003-add-limitation-to-width-and-height.patch
--- libsixel-1.8.2/debian/patches/0003-add-limitation-to-width-and-height.patch 
1970-01-01 09:00:00.0 +0900
+++ libsixel-1.8.2/debian/patches/0003-add-limitation-to-width-and-height.patch 
2019-09-09 12:42:52.0 +0900
@@ -0,0 +1,39 @@
+From: Takatsugu Nokubi 
+Date: Thu, 1 Aug 2019 14:59:58 +0900
+Subject: add limitation to width and height
+
+---
+ include/sixel.h.in | 3 +++
+ src/decoder.c  | 5 +
+ 2 files changed, 8 insertions(+)
+
+diff --git a/include/sixel.h.in b/include/sixel.h.in
+index 7ffe90f..4365c67 100644
+--- a/include/sixel.h.in
 b/include/sixel.h.in
+@@ -366,6 +366,9 @@ typedef int SIXELSTATUS;
+ #define SIXEL_OPTFLAG_VERSION   ('V')  /* -V, --version: show version 
and license info */
+ #define SIXEL_OPTFLAG_HELP  ('H')  /* -H, --help: show this help 
*/
+ 
++#define SIXEL_WIDTH_LIMIT   100
++#define SIXEL_HEIGHT_LIMIT  100
++
+ #if SIXEL_USE_DEPRECATED_SYMBOLS
+ /* output character size */
+ enum characterSize {
+diff --git a/src/decoder.c b/src/decoder.c
+index 63ab4af..c763e4d 100644
+--- a/src/decoder.c
 b/src/decoder.c
+@@ -315,6 +315,11 @@ sixel_decoder_decode(
+ goto end;
+ }
+ 
++if (sx > SIXEL_WIDTH_LIMIT || sy > SIXEL_HEIGHT_LIMIT) {
++status = SIXEL_BAD_INPUT;
++goto end;
++}
++
+ status = sixel_helper_write_image_file(indexed_pixels, sx, sy, palette,
+

Bug#938816: webtest: Python2 removal in sid/bullseye

[peter green]

severity 938816 serious
thanks

python-webtest depends on python-waitress, which has already been dropped from 
the waitress source package.

Bug#940684: breezy: build-depends on obsolete package.

[peter green]

Package: breezy
Severity: serious
Version: 3.0.1-2

Breezy (both versions 3.0.1-2 and 3.0.1-4) build-depends on python-subunit 
which is no longer built by the subunit source package.

Bug#940682: lava-server: depends on cruft package.

[peter green]

Package: lava-server
Version: 2019.01-5
Severity: serious
Tags: bullseye, sid

lava depends on gunicorn3 which is no longer built by the gunicorn source package. 
I belive you need to change your dependency to gunicorn, possiblly with a version 
constraint of >= 19.9.0-4

Bug#940681: elogind: Should only build-depend on libseccomp-dev on architectures supporting it

[John Paul Adrian Glaubitz]

Source: elogind
Severity: normal

Hello!

Currently, elogind unconditionally build-depends on libseccomp-dev despite the 
fact
that not all supported architectures in Debian currently support libseccomp [1].

This results elogind being BD-Uninstallable on a couple of architectures [2] 
where
the original systemd code builds fine [3].

Thus, could you modify your debian/control such that it adopts what systemd does
in this regard and if necessary make the necessary changes to elogind so it can
be built on architectures without libseccomp support?

Thanks,
Adrian

> [1] 
> https://git.devuan.org/devuan-packages/elogind/blob/debian/debian/control#L23
> [2] https://buildd.debian.org/status/package.php?p=elogind=sid
> [3] https://buildd.debian.org/status/package.php?p=systemd=sid
> [4] 
> https://salsa.debian.org/systemd-team/systemd/blob/master/debian/control#L48

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#940624: Errors in the translatable messages

[Justin B Rye]

Summary: a few of these are good wishlist-grade suggestions.

>> SOURCE TEXT
>> Alternatively the passwords can be permanently remembered in the
>> debconf database (which is protected by Unix file permissions),
>> though this is less secure and thus not the default setting.
>> ERRORS
>> - Word choice error: 'permanently remembered' ('stored').

"Permanently stored" would work, but presumably the idea is that it's
meant to remind users of dialogues saying "Remember password?"
 
>> SOURCE TEXT
>> The ${pkg} package must have a database installed and configured
>> before it can be used. This can be optionally handled with
>> dbconfig-common.
>> ERRORS
>> - Phrasing error: 'This can be optionally handled with
>> dbconfig-common.' (This can be done with dbconfig-common when
>> desired.).

No, that says something different; for a start, it implies that you
can leave it until some other time, if you like.  Also, which verb in
the main sentence is "This can be done" referring back to?  Presumably
"configure(d)", but it's hard to be sure; whereas "this can handled"
only needs to refer back to a noun, such as the situation in general.

>> SOURCE TEXT
>> If you are an advanced database administrator and know that you want
>> to perform this configuration manually, or if your database has
>> already been installed and configured, you should refuse this option.
>> Details on what needs to be done should most likely be provided in
>> /usr/share/doc/${pkg}.
>> ERRORS
>> - Phrasing error: 'know that you want' ('want').

Again, not quite the same.  "Are sure that you want" would work too,
but it isn't *better* (since for a start it's longer).

>> - Phrasing error: 'should most likely be provided in' ('is likely
>> provided in').

No - not quite idiomatic ("probably" would work better), a bit weak
(so beef it up to "most probably"), and not quite grammatical (the
"is" should be "are").  Or leave it as it is, since there's nothing
really wrong with it.

>> SOURCE TEXT
>> If you wish to reinstall the database for ${pkg}, you should select
>> this option. If you do not wish to do so (if you are reconfiguring
>> the package for unrelated reasons), you should not select this option.
>> ERRORS
>> - Clarity error: 'for unrelated reasons'.

I don't remember the context, but I presume it means something like
"If you are reconfiguring the package that uses the database for
reasons that have nothing in particular to do with the database
itself".
 
>> SOURCE TEXT
>> Warning: if you change the name of the database, the old database
>> will not be removed. If you change the name of the user that connects
>> to the database, the privileges of the original user will not be
>> revoked.
>> ERRORS
>> - Word choice error: 'Warning' ('Warnings').

No,  Warning signs aren't labelled "WARNINGS!" even if they go on to
mention several dangers.

>> - Grammatical error: 'if' (If).

No.  There are style guides that prefer uppercase after a colon in
particular circumstances, and style guides that always forbid it.  The
debian-l10n-english "house style" (more or less by accident) goes with
the lowercase option.

>> - Coherence error: 'If' (And if).

Make your mind up!  Are these two separate warnings or do you want
them run together into one?  Besides, there are probably just as many
style guides that prohibit sentence-initial "and/but" as there are
style guides that allow uppercase after colons.

>> SOURCE TEXT
>> Perform upgrade on database for ${pkg} with dbconfig-common?
>> ERRORS
>> - Phrasing error: 'Perform upgrade on' (Upgrade).

I suspect that the point of this phrasing was that it makes the
structure clear: with "Upgrade database" the reader needs to expend a
tiny amount of mental effort working out that it has "upgrade" as a
verb and "database" as its object (it's not, for instance, introducing
the concept of an upgrade database), "Perform upgrade on database" is
longwinded, but unambiguous.

If you want to translate it starting from the assumption that "what it
really means is UPGRADE DATABASE, and if English had a proper system
of grammatical word-endings, that's what it would say!", well. feel
free to imagine that's what it says, but there's no need to change the
English text.

>> SOURCE TEXT
>> According to the maintainer for this package, database upgrade
>> operations need to be performed on ${pkg}. Typically, this is due to
>> changes in how a new upstream version of the package needs to store
>> its data.
>> ERRORS
>> - Word choice error: 'for this package' (of this package).

This is the first one I've seen so far where I think your version
might actually be an improvement, but the difference is so tiny! 

>> - Phrasing error: 'database upgrade operations need to be performed
>> on ${pkg}' (the ${pkg} database needs to be updated).

Hang on, updated or upgraded?  That aside... the longwindedness here
*might* be because the "operations" that need to be performed may be
slightly obscure package-management-admin activities on the 

Bug#939588: uim package lacks 2 files

[Takatsugu Nokubi]

On Tue, 10 Sep 2019 21:34:23 +0900 (JST) "NIDE, Naoyuki"
 wrote:
> buster# apt-get purge $(dpkg -l | awk '$1=="rc"{print $2}')
>
> Then, when libuim-data is purged, /var/lib/uim/installed-modules.scm
> and /var/lib/uim/loader.scm are disappeared, since the postrm script of
> libuim-data deletes them.
> This was the cause why these files disappeared in my environment.

The following snippet is a workaround for this problem.
Can you try it?
https://salsa.debian.org/snippets/327

We, uim maintainers, will upload new package with such fix.

Bug#929062: Updated and reworked log4cplus packaging

[Guillem Jover]

Control: tags 811183 patch
Control: tags 863771 patch
Control: tags 929062 patch

Hi!

We needed an updated version of this package, so I went ahead and did
that, and various other cleanups and fixes. Attached is the patch
series for these changes.

I've left the alioth stuff alone, as I'm not sure where you'd like to
migrate to, if at all. And because I'm not really a fan of packaging
repos with non packaging-only layouts.

The other remaining issue I found is that binutils' strip removes the
relro program header, which means that security feature might get
disabled. I'll report another bug and mark as affecting this package.

Thanks,
Guillem
From 7b08ac0a56db8c3ef2d52a8fa77021d27f8d464b Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Thu, 19 Sep 2019 00:01:03 +0200
Subject: [PATCH 01/16] Switch to automatically generated debug packages

---
 debian/changelog |  6 ++
 debian/control   | 15 ---
 debian/rules |  2 +-
 3 files changed, 7 insertions(+), 16 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index fa2b138..c94971c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+log4cplus (1.1.2-3.3) UNRELEASED; urgency=medium
+
+  * Switch to automatically generated debug packages.
+
+ -- Guillem Jover   Fri, 13 Sep 2019 23:31:35 +0200
+
 log4cplus (1.1.2-3.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/control b/debian/control
index ca8f6db..ab349b7 100644
--- a/debian/control
+++ b/debian/control
@@ -28,18 +28,3 @@ Description: C++ logging API modeled after the Java log4j API - development libr
  .
  This package contains the header files and static library for 
  developers.
-
-Package: liblog4cplus-dbg
-Section: debug
-Priority: extra
-Architecture: any
-Depends: ${misc:Depends}, liblog4cplus-1.1-9 (= ${binary:Version})
-Description: C++ logging API modeled after the Java log4j API - debug library
- log4cplus is a simple to use C++ logging API providing thread-safe,
- flexible, and arbitrarily granular control over log management and
- configuration.  It is modeled after the Java log4j API.
- .
- This package is provided primarily to provide a backtrace with names
- in a debugger, this makes it somewhat easier to interpret core
- dumps.  Most people will not need this package.
-
diff --git a/debian/rules b/debian/rules
index f0625f0..0a1b5ed 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,7 +6,7 @@ export DEB_CXXFLAGS_MAINT_APPEND := --std=c++11
 	dh $@ --with autoreconf
 
 override_dh_strip:
-	dh_strip --dbg-package=liblog4cplus-dbg
+	dh_strip --dbgsym-migration='liblog4cplus-dbg (<< 1.1.2-3.3~)'
 
 override_dh_install:
 	sed -i "/dependency_libs/ s/'.*'/''/" `find . -name '*.la'`
-- 
2.23.0.359.gb967887aa5

From 07f51113c670e8ab0225ed565452c4f139669e77 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Thu, 19 Sep 2019 00:01:18 +0200
Subject: [PATCH 02/16] Wrap and sort debian control files (with -sat)

---
 debian/changelog|  1 +
 debian/control  | 19 +++
 debian/liblog4cplus-dev.install |  2 +-
 3 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index c94971c..ad642a8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,7 @@
 log4cplus (1.1.2-3.3) UNRELEASED; urgency=medium
 
   * Switch to automatically generated debug packages.
+  * Wrap and sort debian control files (with -sat).
 
  -- Guillem Jover   Fri, 13 Sep 2019 23:31:35 +0200
 
diff --git a/debian/control b/debian/control
index ab349b7..4288b5a 100644
--- a/debian/control
+++ b/debian/control
@@ -2,8 +2,15 @@ Source: log4cplus
 Section: libs
 Priority: extra
 Maintainer: Andrew Pollock 
-Uploaders: Daigo Moriwaki , Eric Kom 
-Build-Depends: debhelper (>= 9), dh-autoreconf, libtool, automake, doxygen
+Uploaders:
+ Daigo Moriwaki ,
+ Eric Kom ,
+Build-Depends:
+ automake,
+ debhelper (>= 9),
+ dh-autoreconf,
+ doxygen,
+ libtool,
 Standards-Version: 3.9.6
 Homepage: http://log4cplus.sourceforge.net
 Vcs-Browser: http://git.debian.org/?p=collab-maint/log4cplus.git;a=summary
@@ -11,7 +18,9 @@ Vcs-Git: git://git.debian.org/collab-maint/log4cplus.git
 
 Package: liblog4cplus-1.1-9
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
 Description: C++ logging API modeled after the Java log4j API - shared library
  log4cplus is a simple to use C++ logging API providing thread-safe,
  flexible, and arbitrarily granular control over log management and
@@ -20,7 +29,9 @@ Description: C++ logging API modeled after the Java log4j API - shared library
 Package: liblog4cplus-dev
 Architecture: any
 Section: libdevel
-Depends: liblog4cplus-1.1-9 (= ${binary:Version}), ${misc:Depends}
+Depends:
+ ${misc:Depends},
+ liblog4cplus-1.1-9 (= ${binary:Version}),
 Description: C++ logging API modeled after the Java log4j API - development library
  log4cplus is a simple to use C++ logging API providing 

Bug#912077: Any chance to get libbiod compiling again?

[Matthias Klumpp]

Am Mi., 18. Sept. 2019 um 20:39 Uhr schrieb Andreas Tille :
> [...]
> > This is definitely an error in BioD itself, caused by a deprecation
> > that turned into an error in recent LDC versions.
> > So, libbiod will need to be upgraded for sure to fix this.
>
> @Pjotr: Can you comment on this?
>
> > In order to support all architectures and generate a pkg-config file I
> > would have to reintroduce the Meson build definition (which upstream
> > apparently has removed) or apply some hacks around the existing
> > Makefile to make that work in a Debian context, which is quite a bit
> > more work.
>
> As I told you before:  I have no idea about meson.  It would be great if
> we could get it working but if we restrict the package to those
> architectures where it builds out of the box and save some manpower I
> bet the world will keep on turning round.

It's not just that. Also the build needs to be changed to respect
Debian's compile flags, build a shared library and write a pkg-config
file. All doable with Makefiles, but not really much fun. At that
point just using Meson becomes easier.
The package is team-maintained, right? In that case I may just give
this a shot this weekend and get the biod package to build again. It
shouldn't actually by hard to do at all (famous last words :P)

> > Btw, if libundead has no users anymore, removing it completely may be
> > a good idea - we don't need to maintain something that's dead and has
> > no users.
>
> I was about to file a removal request to ftpmaster before you said in
> your last mail that the former build issue might have been caused due
> to the lack of libundead.  I would really love to get rid of unneeded
> packages.

Better check for reverse dependencies, but if there are none, I don't
see a need to keep it. Undead is basically deprecated & removed D
stdlib modules with zero or very little maintenance, so generally
something a project wants to get rid of rather quickly anyway, and
quite likely nothing worth keeping in Debian on its own.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#912077: Any chance to get libbiod compiling again?

[Pjotr Prins]

Hi all,

Libundead was removed as dependency for biod, but it may be there are
some other issues now because the D ecosystem keeps moving.

My main interest is sambamba and we are working on a fix for one of
the main outstanding bugs building against the latest D compilers.

I suggest to drop the packages until we have fixed them. Not many
takers anyway (right now).

Andreas, I think we'll meet in Paris in November. May be a good time
to hack.

Pj.

On Wed, Sep 18, 2019 at 08:39:52PM +0200, Andreas Tille wrote:
> Hi,
> 
> [Pjotr as upstream in CC]
> 
> On Wed, Sep 18, 2019 at 04:54:16PM +0200, Matthias Klumpp wrote:
> > Am Fr., 13. Sept. 2019 um 22:51 Uhr schrieb Andreas Tille 
> > :
> > >
> > > On Fri, Sep 13, 2019 at 03:37:32PM +0200, Matthias Klumpp wrote:
> > > > Am Fr., 13. Sept. 2019 um 15:21 Uhr schrieb Andreas Tille 
> > > > :
> > > > > /usr/bin/ld.gold: error: bin/biod_tests.o: multiple definition of 
> > > > > '_d_execBssBegAddr'
> > > > > /usr/bin/ld.gold: contrib/undead/*/__main.o: previous definition here
> > > > > /usr/bin/ld.gold: error: bin/biod_tests.o: multiple definition of 
> > > > > '_d_execBssEndAddr'
> > > > > /usr/bin/ld.gold: contrib/undead/*/__main.o: previous definition here
> > > > > collect2: error: ld returned 1 exit status
> > > > > [...]
> > > >
> > > > It's very likely that undeaD needs to be updated first in order to
> > > > compile this again.
> > > > Has upgrading that been attempted yet?
> > >
> > > I just upgraded libundead and re-added it to libbiod (I assumed libundead
> > > would not have been needed for libbiod any more and thus it was removed)
> > > Now the error is:
> > 
> > When I try to compile libbiod now, I get this error:
> > ```
> > ../bio/bam/baseinfo.d-mixin-165(165): Error: Options at
> > ../bio/bam/baseinfo.d(579) conflicts with Options at
> > ../bio/bam/baseinfo.d(482)
> > ../bio/bam/baseinfo.d(175):called from here: getRangeMethods()
> > ../bio/bam/baseinfo.d(278): Error: template instance
> > `bio.bam.baseinfo.PerBaseInfo!(BamRead, "FZ", "MD", cast(Option)0,
> > cast(Option)1, cast(Option)2, cast(Option)3)` error instantiating
> > ../test/unittests.d(382):instantiated from here:
> > basesWith!(BamRead, MixinArg!(string, "flowOrder"), MixinArg!(string,
> > "keySequence"))
> > [100/177] ldc2 -I=biod_test@exe -I=. -I=.. -I/usr/include/d
> > -enable-color -O -g -release -wi -unittest
> > -of='biod_test@exe/bio_bam_cigar.d.o' -c ../bio/bam/cigar.d
> > [101/177] ldc2 -I=biod_test@exe -I=. -I=.. -I/usr/include/d
> > -enable-color -O -g -release -wi -unittest
> > -of='biod_test@exe/bio_bam_tagvalue.d.o' -c ../bio/bam/tagvalue.d
> > [102/177] ldc2 -I=biod_test@exe -I=. -I=.. -I/usr/include/d
> > -enable-color -O -g -release -wi -unittest
> > -of='biod_test@exe/bio_bam_bai_indexing.d.o' -c
> > ../bio/bam/bai/indexing.d
> > [103/177] ldc2 -I=biod_test@exe -I=. -I=.. -I/usr/include/d
> > -enable-color -O -g -release -wi -unittest
> > -of='biod_test@exe/bio_bam_iontorrent_flowcall.d.o' -c
> > ../bio/bam/iontorrent/flowcall.d
> > [104/177] ldc2 -I=biod_test@exe -I=. -I=.. -I/usr/include/d
> > -enable-color -O -g -release -wi -unittest
> > -of='biod_test@exe/bio_bam_thirdparty_msgpack.d.o' -c
> > ../bio/bam/thirdparty/msgpack.d
> > ../bio/bam/thirdparty/msgpack.d(2035): Deprecation: integral promotion
> > not done for -header, use '-preview=intpromote' switch or
> > -cast(int)(header)
> > ../bio/bam/thirdparty/msgpack.d(2035): Deprecation: integral promotion
> > not done for -header, use '-preview=intpromote' switch or
> > -cast(int)(header)
> > ../bio/bam/thirdparty/msgpack.d(2035): Deprecation: integral promotion
> > not done for -cast(byte)-header, use '-preview=intpromote' switch or
> > -cast(int)(cast(byte)-header)
> > ../bio/bam/thirdparty/msgpack.d(2035): Deprecation: integral promotion
> > not done for -header, use '-preview=intpromote' switch or
> > -cast(int)(header)
> > ../bio/bam/thirdparty/msgpack.d(2035): Deprecation: integral promotion
> > not done for -cast(short)-header, use '-preview=intpromote' switch or
> > -cast(int)(cast(short)-header)
> > ../bio/bam/thirdparty/msgpack.d(2035): Deprecation: integral promotion
> > not done for -header, use '-preview=intpromote' switch or
> > -cast(int)(header)
> > ninja: build stopped: subcommand failed.
> > dh_auto_build: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j6 -v
> > returned exit code 1
> > ```
> > This is definitely an error in BioD itself, caused by a deprecation
> > that turned into an error in recent LDC versions.
> > So, libbiod will need to be upgraded for sure to fix this.
> 
> @Pjotr: Can you comment on this?
> 
> > In order to support all architectures and generate a pkg-config file I
> > would have to reintroduce the Meson build definition (which upstream
> > apparently has removed) or apply some hacks around the existing
> > Makefile to make that work in a Debian context, which is quite a bit
> > more work.
> 
> As I told you before:  I have no idea about meson.  It 

Bug#875184: Help needed for medical imaging framework sofa (Was: Bug#875184: [sofa-framework] Future Qt4 removal from Buster)

[Lisandro Damián Nicanor Pérez Meyer]

On 19/09/17 10:17, Andreas Tille wrote:
> On Tue, Sep 17, 2019 at 01:26:17PM -0300, Lisandro Damián Nicanor Pérez Meyer 
> wrote:
> > 
> > Is the embedded stuff all in extlibs/? or is there some other 3rdparty code?
> 
> A lot is excluded in advance from the packaging Git:
> 
> Files-Excluded: */libQGLViewer*
> */csparse
> */gtest
> */qwt*
> */eigen-3*
> */newmat
> */extlibs/json
> */tinyxml
> */*.dll
> */*.lib
> */SuiteSparse
> 
> Some of these previously resided in SofaKernel/extlibs before
> the removal.

Well, the first error I see is that the software seems to require cpsarse, but I
don't seem to find it in the archive :-(

Am I missing something? 

Bug#554167: New mawk upstream version

[Dima Kogan]

Guillem Jover  writes:

> At this point I think the best course of action is to start a Package
> Salvaging process.

OK. I'm going to do this. Steve: do you have strong opinions about the
specific way this should be done? I have thoughts, but you should weigh
in, as the maintainer.

Thanks.
dima

Bug#928607: W: Possible missing firmware /lib/firmware/amdgpu/vega20_asd.bin for module amdgpu

[Archie]

I hope that the following info helps in some small degree.

I first encountered this bug on 20190418 during a routine update.

From the Synaptic update log Details:

desktop-base (version 10.0.0) will be upgraded to version 10.0.2
+ 9 other packages


The most recent failure occurred on: 2019-09-16
Part of the package update was to: update-initramfs: Generating 
/boot/initrd.img-4.19.0-6-amd64

The update failed because:
From the Synaptic update log Details:
W: Possible missing firmware /lib/firmware/amdgpu/vega20_asd.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_sos.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_rlc.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_mec2.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_mec.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_me.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_pfp.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_ce.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_sdma1.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_sdma.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_uvd.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_vce.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_smc.bin for 
module amdgpu

pigz: abort: write error on  (No space left on device)
E: mkinitramfs failure cpio 141 pigz 28
update-initramfs: failed for /boot/initrd.img-4.19.0-6-amd64 with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
dpkg: error processing package linux-image-4.19.0-6-amd64 (--configure):
 installed linux-image-4.19.0-6-amd64 package post-installation script 
subprocess returned error exit status 1

Setting up samba-common-bin (2:4.9.5+dfsg-5+deb10u1) ...
Checking smb.conf with testparm
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Server role: ROLE_STANDALONE

From: Synaptic Commit Log for Sun Sep  8 16:57:24 2019
firmware-amd-graphics (version 20190114-1) was upgraded to version 
20190114-2


https://packages.debian.org/buster/firmware-amd-graphics
I have verified that firmware for "vega20" is not documented as being 
part of:

Package: firmware-amd-graphics (20190114-2) [non-free]


From hardinfo:
Summary

Computer
Processor    AMD Ryzen 5 1600 Six-Core Processor
Memory    16423MB (2190MB used)
Machine Type    Desktop
Operating System    Debian GNU/Linux 10 (buster)
User Name    archie (archie croom)
Date/Time    Wed 18 Sep 2019 09:05:01 AM CDT

Display
Resolution    1920x1080 pixels
*** The following GPU is the ONLY graphic device ever installed in this 
system. ***
OpenGL Renderer    Radeon RX 560 Series (POLARIS11, DRM 3.27.0, 
4.19.0-6-amd64, LLVM 7.0.1)

X11 Vendor    The X.Org Foundation

Audio Devices
Audio Adapter    HDA-Intel - HDA ATI HDMI
Audio Adapter    HDA-Intel - HD-Audio Generic

Input Devices
Power Button
Power Button
Logitech K270
Logitech M570
PC Speaker
HDA ATI HDMI HDMI/DP,pcm:3
HDA ATI HDMI HDMI/DP,pcm:7
HDA ATI HDMI HDMI/DP,pcm:8
HDA ATI HDMI HDMI/DP,pcm:9
HDA ATI HDMI HDMI/DP,pcm:10
HD-Audio Generic Front Mic
HD-Audio Generic Rear Mic
HD-Audio Generic Line
HD-Audio Generic Line Out
HD-Audio Generic Front Headphone
Eee PC WMI hotkeys

Printers (CUPS)
EPSON-XP-7100-Series    Default
XP-7100-Series

Operating System
Version
Kernel    Linux 4.19.0-6-amd64 (x86_64)
Version    #1 SMP Debian 4.19.67-2 (2019-08-28)
C Library    GNU C Library / (Debian GLIBC 2.28-10) 2.28
Distribution    Debian GNU/Linux 10 (buster)


An attempt to reclaim space to resolve the write error which was noted 
above:

archie@debian:~$ sudo apt autoremove
[sudo] password for archie:
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up initramfs-tools (0.133+deb10u1) ...
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools (0.133+deb10u1) ...
update-initramfs: Generating /boot/initrd.img-4.19.0-6-amd64
W: Possible missing firmware /lib/firmware/amdgpu/vega20_asd.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_sos.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_rlc.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_mec2.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_mec.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_me.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_pfp.bin for 
module amdgpu
W: 

Bug#940680: Provide backports for Buster

[ghisvail]

Package: flatpak
Version: 1.2.4-1
Severity: wishlist

Dear maintainer,

Since the release of freedesktop runtime version 19.08, flatpak attempts
to install org.freedesktop.Platform.openh264 but fails with the
following warning message:

Warning: org.freedesktop.Platform.openh264 needs a later flatpak version

Would you consider providing backports of newer releases of flatpak to
Buster to bypass future issues with new runtimes?

Best regards,
Ghislain


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

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

Versions of packages flatpak depends on:
ii  bubblewrap 0.3.1-4
ii  libappstream-glib8 0.7.14-1
ii  libarchive13   3.3.3-4
ii  libc6  2.28-10
ii  libdconf1  0.30.1-2
ii  libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii  libglib2.0-0   2.58.3-2+deb10u1
ii  libgpgme11 1.12.0-6
ii  libjson-glib-1.0-0 1.4.4-2
ii  libostree-1-1  2019.1-1
ii  libpolkit-agent-1-00.105-25
ii  libpolkit-gobject-1-0  0.105-25
ii  libseccomp22.3.3-4
ii  libsoup2.4-1   2.64.2-2
ii  libsystemd0241-7~deb10u1
ii  libxau61:1.0.8-1+b2
ii  libxml22.9.4+dfsg1-7+b3
ii  xdg-dbus-proxy 0.1.1-1
ii  xdg-desktop-portal 1.2.0-1

Versions of packages flatpak recommends:
ii  desktop-file-utils   0.23-4
ii  gtk-update-icon-cache3.24.5-1
ii  hicolor-icon-theme   0.17-2
ii  libpam-systemd   241-7~deb10u1
ii  p11-kit  0.23.15-2
ii  policykit-1  0.105-25
ii  shared-mime-info 1.10-1
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.2.0-1

Versions of packages flatpak suggests:
ii  avahi-daemon  0.7-4+b1

-- no debconf information

Bug#940679: pandas: FTBFS on amd64 - TestDatetimelikeSubtype::test_astype_category[index3] crash

[Rebecca N. Palmer]

Source: pandas
Version: 0.23.3+dfsg-6
Severity: serious

https://buildd.debian.org/status/fetch.php?pkg=pandas=amd64=0.23.3%2Bdfsg-6=1568839095=0

Was your local build on a different architecture, or must this be 
something random / hardware-or-environment-dependent / a very recent 
change in a build-dependency?

Bug#940678: zfsutils-linux: zfs-import-cache fails w. "one or more devices is currently unavailable" on Buster after upgrade from Stretch

[Alberto Berti]

Package: zfsutils-linux
Version: 0.7.12-2+deb10u1
Severity: critical
Justification: causes serious data loss

Dear Maintainer,

after upgrading from Stretch, the zfs filesystems fail to mount at boot time 
due to the zfs-import-cache 
service unit fails, with the following log:

 systemd[1]: Starting Import ZFS pools by cache file...
 zpool[2896]: cannot import 'tank': one or more devices is currently unavailable
 systemd[1]: zfs-import-cache.service: Main process exited, code=exited, 
status=1/FAILURE
 systemd[1]: zfs-import-cache.service: Failed with result 'exit-code'.
 systemd[1]: Failed to start Import ZFS pools by cache file.

In order to manually mount the filesytems, I have to run:

 # zpool import -d /dev  -aN`
 # zfs mount -a

The pool is made by two devices in mirroring.

any clue?
 
-- System Information:
Debian Release: 10.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), 
LANGUAGE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages zfsutils-linux depends on:
ii  libblkid12.33.1-0.1
ii  libc62.28-10
ii  libnvpair1linux  0.7.12-2+deb10u1
ii  libuuid1 2.33.1-0.1
ii  libuutil1linux   0.7.12-2+deb10u1
ii  libzfs2linux 0.7.12-2+deb10u1
ii  libzpool2linux   0.7.12-2+deb10u1
ii  python3  3.7.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages zfsutils-linux recommends:
ii  lsb-base10.2019051400
ii  zfs-dkms [zfs-modules]  0.7.12-2+deb10u1
pn  zfs-zed 

Versions of packages zfsutils-linux suggests:
pn  nfs-kernel-server   
pn  samba-common-bin
pn  zfs-initramfs | zfs-dracut  

-- no debconf information

Bug#760873: [vim-gtk] Incorrect display of ascii glyps (ie. displays 'm' in place of 'g').

[Mattia Dongili]

On Mon, Sep 16, 2019 at 11:31:07PM -0400, James McCoy wrote:
> On Sun, Mar 08, 2015 at 04:27:21PM +0900, Mattia Dongili wrote:
> > Hi James,
> > yes, it's totally related to the font face used:
> > 
> > $ gvim -u NONE -c 'set guifont=PragmataPro\ 12'
> > $
> >   ** (gvim:26280): CRITICAL **: ascii_glyph_table_init: assertion
> >   'gui.ascii_glyphs->num_glyphs == sizeof(ascii_chars)' failed
> > 
> > With this particular font all characters are messed up (screenshot
> > attached).
> > 
> > Here's a related discussion:
> > https://groups.google.com/forum/#!topic/vim_dev/0sETSAwe5Wo
> 
> It looks like Bram included a fix for this problem some time ago (patch
> 7.4.2214).
> 
> Could someone confirm whether this now works as expected?

Using the command from 4 years ago I no longer see the CRITICAL log
entry and gvim seems to behave for me (and admittedly has been for some
time now).

Thanks
-- 
mattia
:wq!

Bug#935505: guile-2.0: FTBFS on hurd-i386

[Samuel Thibault]

Control: tags -1 + pending

Hello,

Svante Signell, le ven. 23 août 2019 13:13:11 +0200, a ecrit:
> Currently guile-2.0 FTBFS on GNU/Hurd due to one test failing. The
> attached upstream patch, renamed to 0006-fix-hurd-statprof-test.patch
> fixes that problem. It is already fixed upstream, in commit 
> https://git.savannah.gnu.org/cgit/guile.git/commit/?h=stable-2.0=f2764cb1031379c47a17c02fef3f8164a6ce9cda
> , see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37037

Thanks for dealing with upstream!  I have NMU-ed the attached change to
DELAYED/5.

Samuel
diff -Nru guile-2.0-2.0.13+1/debian/changelog 
guile-2.0-2.0.13+1/debian/changelog
--- guile-2.0-2.0.13+1/debian/changelog 2019-03-30 19:24:44.0 +0100
+++ guile-2.0-2.0.13+1/debian/changelog 2019-09-18 01:38:50.0 +0200
@@ -1,3 +1,14 @@
+guile-2.0 (2.0.13+1-5.2) unstable; urgency=medium
+
+  [ Samuel Thibault ]
+  * Non-maintainer upload.
+
+  [ Svante Signell ]
+  * 0006-fix-hurd-statprof-test.patch: new patch by Ludovic Courtès to fix
+FTBFS on hurd-i386 (Closes: #935505)
+
+ -- Samuel Thibault   Wed, 18 Sep 2019 01:38:50 +0200
+
 guile-2.0 (2.0.13+1-5.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru guile-2.0-2.0.13+1/debian/patches/0006-fix-hurd-statprof-test.patch 
guile-2.0-2.0.13+1/debian/patches/0006-fix-hurd-statprof-test.patch
--- guile-2.0-2.0.13+1/debian/patches/0006-fix-hurd-statprof-test.patch 
1970-01-01 01:00:00.0 +0100
+++ guile-2.0-2.0.13+1/debian/patches/0006-fix-hurd-statprof-test.patch 
2019-09-18 01:38:50.0 +0200
@@ -0,0 +1,49 @@
+From f2764cb1031379c47a17c02fef3f8164a6ce9cda Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= 
+Date: Sat, 11 Feb 2017 22:00:18 +0100
+Subject: tests: Avoid statprof test failure on systems without 'setitimer'.
+
+Partly fixes .
+Reported by ren...@openmailbox.org.
+
+* test-suite/tests/statprof.test ("return values"): Wrap in
+'when-implemented'.
+---
+ test-suite/tests/statprof.test | 21 +++--
+ 1 file changed, 11 insertions(+), 10 deletions(-)
+
+diff --git a/test-suite/tests/statprof.test b/test-suite/tests/statprof.test
+index 482709f..885e310 100644
+--- a/test-suite/tests/statprof.test
 b/test-suite/tests/statprof.test
+@@ -47,16 +47,17 @@
+ 
+ (pass-if-equal "return values"
+ '(42 77)
+-  (call-with-values
+-  (lambda ()
+-(with-output-to-port (%make-void-port "w")
+-  (lambda ()
+-(with-statprof
+-(let loop ((i 1))
+-  (if (zero? i)
+-  (values 42 77)
+-  (loop (1- i
+-list))
++  (when-implemented
++   (call-with-values
++   (lambda ()
++ (with-output-to-port (%make-void-port "w")
++   (lambda ()
++ (with-statprof
++ (let loop ((i 1))
++   (if (zero? i)
++   (values 42 77)
++   (loop (1- i
++ list)))
+ 
+ (pass-if "statistical sample counts within expected range"
+   (when-implemented
+-- 
+cgit v1.0-41-gc330
+
diff -Nru guile-2.0-2.0.13+1/debian/patches/series 
guile-2.0-2.0.13+1/debian/patches/series
--- guile-2.0-2.0.13+1/debian/patches/series2019-03-30 19:21:50.0 
+0100
+++ guile-2.0-2.0.13+1/debian/patches/series2019-09-18 01:38:50.0 
+0200
@@ -3,3 +3,4 @@
 0003-tests-Avoid-race-condition-in-REPL-server-test.patch
 0004-ia64-Fix-crash-in-thread-context-switch.patch
 0005-fix-french-locale-test.patch
+0006-fix-hurd-statprof-test.patch

Bug#940677: cinnamon: default PDF handler specification is broken

[Gábor Gombás]

Package: cinnamon-desktop-data
Version: 4.0.1-1
Severity: normal

Hi,

When opening a PDF downloaded from the web, it often gets opened by
random applications like Libreoffice or Calibre, instead of evince. This
is caused by /usr/share/applications/x-cinnamon-mimeapps.list having:

$ grep application/pdf /usr/share/applications/x-cinnamon-mimeapps.list
application/pdf=evince.desktop;

... but evince ships org.gnome.Evince.desktop, evince.desktop does not
exist. Please fix the file name.

Regards,
Gabor

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

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

Versions of packages cinnamon-desktop-data depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-1
ii  python3  3.7.3-1
ii  python3-gi   3.34.0-1

cinnamon-desktop-data recommends no packages.

cinnamon-desktop-data suggests no packages.

-- no debconf information

Bug#931536: aptitude: Release info changes ignored ininteractive mode

[Braun Gábor]

Package: aptitude
Version: 0.8.11-7
Followup-For: Bug #931536

Dear Maintainer,

Running aptitude without arguments then pressing u seemingy successfully 
updated the package list,
however it did not contain the changes from the new stable update 10.1.

Running "apt-get update" on the command line produced the following error 
messages:

N: Für das Depot »http://ftp.hu.debian.org/debian buster InRelease« wurde der 
»Version«-Wert von »« in »10.1« geändert.
E: Für das Depot »http://ftp.hu.debian.org/debian buster InRelease« wurde der 
»Suite«-Wert von »testing« in »stable« geändert.
N: Sie müssen dies explizit bestätigen, bevor Aktualisierungen von diesem Depot 
angewendet werden können. Lesen Sie die apt-secure(8)-Handbuchseite, wenn Sie 
weitere Informationen benötigen.
N: Für das Depot »http://deb.debian.org/debian buster InRelease« wurde der 
»Version«-Wert von »« in »10.1« geändert.
E: Für das Depot »http://deb.debian.org/debian buster InRelease« wurde der 
»Suite«-Wert von »testing« in »stable« geändert.
N: Sie müssen dies explizit bestätigen, bevor Aktualisierungen von diesem Depot 
angewendet werden können. Lesen Sie die apt-secure(8)-Handbuchseite, wenn Sie 
weitere Informationen benötigen.


After running "apt update" and answering "i" to the confirmation questions,
I have managed to update.

In my opinion, aptitude should explicitly ask for confirmation in these cases, 
instead of silently ignoring the messages.

Best wishes,
Gábor

-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.11
Compiler: g++ 8.2.0
Compiled against:
  apt version 5.0.2
  NCurses version 6.1
  libsigc++ version: 2.10.1
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.1.20181013
  cwidget version: 0.5.17
  Apt version: 5.0.2

aptitude linkage:
linux-vdso.so.1 (0x7ffeba7f5000)
libgtk3-nocsd.so.0 => /usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 
(0x7f583ec06000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 
(0x7f583ea3)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7f583e9f6000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7f583e9c8000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f583e9bf000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7f583e8b9000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f583e795000)
libboost_iostreams.so.1.67.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.67.0 (0x7f583e777000)
libboost_system.so.1.67.0 => 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.67.0 (0x7f583e77)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 
(0x7f583e544000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f583e523000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f583e39f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f583e21a000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f583e20)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f583e03f000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f583e03a000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7f583e02)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f583de02000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f583dded000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f583ddc5000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7f583dda6000)
libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 
(0x7f583dd06000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f583dce)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7f583dc3f000)
/lib64/ld-linux-x86-64.so.2 (0x7f583f26d000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f583dc33000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f583dc2a000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7f583db0c000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 
(0x7f583dae9000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common   0.8.11-7
ii  libapt-pkg5.0 1.8.2
ii  libboost-iostreams1.67.0  

Bug#940676: golang-1.12-go: Go builds failing on mips64el

[Drew Parsons]

Package: golang-1.12-go
Version: 1.12.9-2
Severity: important

go builds (dh_auto_build invoking /usr/bin/go -> golang-1.12-go) are
failing consistently on mip64el. I'm seeing the error in
golang-github-anacrolix-dms and rclone but I think other packages are
affected.


All builds fail on mip64el. mipsel is also intermittently affected,
but a giveback gets a successful build. The mipsel pattern suggests
that builds fail on mipsel-manda-03, while succeeding on eberlin and
mipsel-aql-01.


The package providing /usr/lib/go-1.12/bin/go, golang-1.12-go
(golang-1.12), built successfully 25 days ago.


dms logs are at
https://buildd.debian.org/status/logs.php?pkg=golang-github-anacrolix-dms=mips64el
e.g.
https://buildd.debian.org/status/fetch.php?pkg=golang-github-anacrolix-dms=mips64el=1.0.0-2=1568632405=0


Log snippets:
   dh_auto_build -a -O--buildsystem=golang
signal 10 received but handler not on signal stack
fatal error: non-Go code set up signal handler without SA_ONSTACK flag

runtime stack:

runtime: unexpected return pc for runtime.sigtramp called from 0xee4560 
stack: frame={sp:0xc09c88, fp:0xc09cd0} 
stack=[0xc01be8,0xc09fe8) 00c09b88: 00c00480 
000120037ad4  00c09b98: 00c09ba0 
00012005380c  00c09ba8: 00c09bb0 
000120069a50 

00c09bb8:  00012065dd02  0039

00c09bc8: 000120052a44  00012065dd02 
00c09bd8: 0039 00012006e4cc 

...

runtime.sigtramp(0x0, 0x0, 0x8a, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)

/usr/lib/go-1.12/src/runtime/sys_linux_mips64x.s:254 +0x54

goroutine 17 [syscall, locked to thread]:
runtime.goexit()

/usr/lib/go-1.12/src/runtime/asm_mips64x.s:646 +0x4 fp=0xc58fe0 
sp=0xc58fe0 pc=0x12006da1c


goroutine 1 [running, locked to thread]:
goroutine running on other thread; stack unavailable

goroutine 20 [syscall]:
os/signal.signal_recv(0x0)
/usr/lib/go-1.12/src/runtime/sigqueue.go:139 +0x150
os/signal.loop()
/usr/lib/go-1.12/src/os/signal/signal_unix.go:23 +0x34
created by os/signal.init.0
/usr/lib/go-1.12/src/os/signal/signal_unix.go:29 +0x54

cd obj-mips64el-linux-gnuabi64 && go install 
-gcflags=all=\"-trimpath=/<>/obj-mips64el-linux-gnuabi64/src\" 
-asmflags=all=\"-trimpath=/<>/obj-mips64el-linux-gnuabi64/src\" -v 
-p 4 dh_auto_build: cd obj-mips64el-linux-gnuabi64 && go install 
-gcflags=all=\"-trimpath=/<>/obj-mips64el-linux-gnuabi64/src\" 
-asmflags=all=\"-trimpath=/<>/obj-mips64el-linux-gnuabi64/src\" -v 
-p 4 died with signal 10

make: *** [debian/rules:4: build-arch] Error 255

dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2





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

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

Versions of packages golang-1.12-go depends on:
ii  golang-1.12-src  1.12.9-2
ii  libc62.29-1

Versions of packages golang-1.12-go recommends:
ii  g++ 4:9.2.1-3.1
ii  gcc 4:9.2.1-3.1
ii  libc6-dev   2.29-1
ii  pkg-config  0.29-6

Versions of packages golang-1.12-go suggests:
ii  bzr  2.7.0+bzr6622-16
ii  ca-certificates  20190110
ii  git  1:2.23.0-1
ii  mercurial5.1.1-1
ii  subversion   1.10.6-1

-- no debconf information

Bug#940675: ITP: r-cran-lifecycle -- manage the life cycle of your GNU R package functions

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-lifecycle -- manage the life cycle of your GNU R package 
functions
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-lifecycle
  Version : 0.1.0
  Upstream Author : Lionel Henry,
* URL : https://cran.r-project.org/package=lifecycle
* License : GPL-3
  Programming Lang: GNU R
  Description : manage the life cycle of your GNU R package functions
 Manage the life cycle of your exported functions with
 shared conventions, documentation badges, and non-invasive
 deprecation warnings. The 'lifecycle' package defines four
 development stages (experimental, maturing, stable, and
 questioning) and three deprecation stages (soft-deprecated,
 deprecated, and defunct). It makes it easy to insert badges
 corresponding to these stages in your documentation. Usage of
 deprecated functions are signalled with increasing levels of
 non-invasive verbosity.

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

Bug#940674: libtfbs-perl: Please update debian/tests/control to match autodep8/pkg-perl-autopkgtest changes

[Xavier Guimard]

Package: libtfbs-perl
Version: 0.7.1-2
Severity: normal

Hi,

autodep8/pkg-perl-autopkgtest changes introduces a regression in
libtfbs-perl autopkgtest tests. Could you accept my merge request [1] and
re-upload this package ?

Cheers,
Xavier

[1]: https://salsa.debian.org/med-team/libtfbs-perl/merge_requests/1

Bug#940673: reprof: Please update debian/tests/control to match autodep8/pkg-perl-autopkgtest changes

[Xavier Guimard]

Source: reprof
Version: 1.0.1-6
Severity: normal

Hi,

autodep8/pkg-perl-autopkgtest changes introduces a regression in reprof
autopkgtest tests. Could you accept my merge request [1] and re-upload this
package ?

Cheers,
Xavier

https://salsa.debian.org/med-team/reprof/merge_requests/1

Bug#940672: Please add support for HP x2 210 PMIC and sound card

[Benoît Laniel]

Package: linux-image-5.3.0-rc5-amd64
Version: 5.3~rc5-1~exp2
Severity: wishlist
Tags: patch

HP x2 210 has an AXP288 PMIC. Battery driver is already enabled but not
the
charger one. Moreover, the ADC driver is needed to make them work.

Also, this device uses the (now landed) CX2072X codec.

Here is a proposed patch (against current debian linux git branch)
which
enables the necessary drivers.

Thanks for all your work ;)
diff --git a/debian/config/kernelarch-x86/config 
b/debian/config/kernelarch-x86/config
index cbf9193..e58a66b 100644
--- a/debian/config/kernelarch-x86/config
+++ b/debian/config/kernelarch-x86/config
@@ -454,6 +454,7 @@ CONFIG_EDAC_AMD8111=m
 ## file: drivers/extcon/Kconfig
 ##
 CONFIG_EXTCON=m
+CONFIG_EXTCON_AXP288=m
 CONFIG_EXTCON_INTEL_CHT_WC=m
 
 ##
@@ -703,6 +704,11 @@ CONFIG_KXCJK1013=m
 CONFIG_MMA9551=m
 CONFIG_MMA9553=m
 
+##
+## file: drivers/iio/adc/Kconfig
+##
+CONFIG_AXP288_ADC=m
+
 ##
 ## file: drivers/iio/gyro/Kconfig
 ##
@@ -1444,6 +1450,7 @@ CONFIG_PNP=y
 ## file: drivers/power/supply/Kconfig
 ##
 CONFIG_BATTERY_SBS=m
+CONFIG_AXP288_CHARGER=m
 CONFIG_AXP288_FUEL_GAUGE=m
 CONFIG_BATTERY_MAX17042=m
 CONFIG_CHARGER_BQ24190=m
@@ -2102,6 +2109,7 @@ CONFIG_SND_SOC_INTEL_CHT_BSW_RT5672_MACH=m
 CONFIG_SND_SOC_INTEL_CHT_BSW_RT5645_MACH=m
 CONFIG_SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH=m
 CONFIG_SND_SOC_INTEL_CHT_BSW_NAU8824_MACH=m
+CONFIG_SND_SOC_INTEL_BYT_CHT_CX2072X_MACH=m
 CONFIG_SND_SOC_INTEL_BYT_CHT_DA7213_MACH=m
 CONFIG_SND_SOC_INTEL_BYT_CHT_ES8316_MACH=m
 # CONFIG_SND_SOC_INTEL_BYT_CHT_NOCODEC_MACH is not set

Bug#940671: alacarte crashes on start with GNOME 3.34 installed

[Matteo Settenvini]

Package: alacarte
Version: 3.11.91-5
Severity: important

Dear Maintainer,

whenever I attempt to start alacarte with GNOME 3.34 installed,
I get the following output:

$ alacarte
/usr/share/alacarte/Alacarte/MainWindow.py:22: PyGIWarning: GMenu was imported 
without specifying a version first. Use gi.require_version('GMenu', '3.0') 
before import to ensure that the right version gets loaded.
  from gi.repository import Gtk, GdkPixbuf, Gdk, GMenu

(alacarte:10516): Gtk-WARNING **: 21:44:38.368: Theme parsing error: 
gtk.css:6:20: The 'gtk-key-bindings' property has been renamed to 
'-gtk-key-bindings'

(alacarte:10516): Gtk-CRITICAL **: 21:44:38.386: 
gtk_accel_label_set_accel_closure: assertion 
'gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed

(alacarte:10516): Gtk-CRITICAL **: 21:44:38.386: 
gtk_accel_label_set_accel_closure: assertion 
'gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed
Traceback (most recent call last):
  File "/usr/bin/alacarte", line 26, in 
main()
  File "/usr/share/alacarte/Alacarte/MainWindow.py", line 464, in main
app.setMenuBasename(basename)
  File "/usr/share/alacarte/Alacarte/MainWindow.py", line 62, in setMenuBasename
self.editor = MenuEditor(menu_basename)
  File "/usr/share/alacarte/Alacarte/MenuEditor.py", line 36, in __init__
self.load()
  File "/usr/share/alacarte/Alacarte/MenuEditor.py", line 49, in load
if not self.tree.load_sync():
gi.repository.GLib.Error: g-markup-error-quark: Errore alla riga 1 carattere 1: 
Il documento era vuoto oppure conteneva unicamente spazi (1)


The program then exits.

Cheers,
Matteo Settenvini

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

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

Versions of packages alacarte depends on:
ii  gir1.2-gdkpixbuf-2.0  2.38.1+dfsg-1
ii  gir1.2-glib-2.0   1.62.0-1
ii  gir1.2-gmenu-3.0  3.32.0-1
ii  gir1.2-gtk-3.03.24.11-1
ii  gnome-menus   3.32.0-1
ii  python3   3.7.3-1
ii  python3-gi3.34.0-1

alacarte recommends no packages.

alacarte suggests no packages.

-- no debconf information

Bug#939818: new magic: OpenSSH Key Revocation List (KRL)

[Christoph Biedl]

Control: tags 939818 upstream pending
Cotrol: forwarded 939818 
https://mailman.astron.com/pipermail/file/2019-September/000195.html

Trent W. Buck wrote...

> Please teach file about this file format.

Thanks for an instructive bug report, now forwarded upstream (and
already applied there).

Christoph


signature.asc
Description: PGP signature

Bug#940670: tesseract-ocr-ita: ita.traineddata does not work

[Davide Viti]

Package: tesseract-ocr-ita
Version: 1:4.00~git30-7274cfa-1
Severity: important

Dear Maintainer,

the following command:

  tesseract list.txt mypage -l ita --oem 2

fails with the following error:

Failed loading language 'ita'
Tesseract couldn't load any languages!
Could not initialize tesseract.


A little bit of googling got me to [1]
As suggested, I've tried the following:

  wget https://github.com/tesseract-ocr/tessdata/raw/4.00/ita.traineddata

and copied it to /usr/share/tesseract-ocr/4.00/tessdata

it now works.

Regards,
Davide

[1] https://www.mail-archive.com/tesseract-ocr@googlegroups.com/msg15127.html
[2] https://github.com/tesseract-ocr/tesseract/wiki/Data-Files



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

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

tesseract-ocr-ita depends on no packages.

Versions of packages tesseract-ocr-ita recommends:
ii  tesseract-ocr  4.0.0-2

tesseract-ocr-ita suggests no packages.

-- no debconf information

Bug#940648: marked as done (Do not install bench dir)

[Xavier]

Control: reopen -1

Only bench*.js files are ignored, I miss to ignore bench dir...

Bug#875195: [stretchplayer] Future Qt4 removal from Buster

[Moritz Muehlenhoff]

On Wed, Sep 18, 2019 at 02:44:49PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Hi!
> 
> El mié., 18 sep. 2019 13:18, Reiner Herrmann  escribió:
> 
> > Control: tags -1 + patch
> >
> > Dear maintainers,
> >
> > porting stretchplayer to Qt5 was straightforward.
> > You can find a merge request on salsa [0].
> >
> 
> The patch looks great. I'll happy NMU it if you (the maintainer) agree.
> I'll also NMU it if we don't get a reply in ~3 days, as this bug never got
> a reply from the maintainers.

Thanks Reiner, I'll have a look at the MR and do a pkg-multimedia team upload.

Cheers,
Moritz

Bug#940669: RM: common-lisp-controller -- ROM; obsolete

[Sébastien Villemot]

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

Please remove common-lisp-controller. It is obsolete, and did not ship with
buster (see #913649).

Best,

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org

Bug#940587: cloud.debian.org: additional Vagrant boxes with puppet/ansible pre-installed?

[Geert Stappers]

On Wed, Sep 18:
> On 2019-09-18 1:36 a.m., Geert Stappers wrote:
> > On Tue, Sep 17, 2019 at 10:52:54AM -0400, Gabriel Filion wrote:
> >> vagrant boxes images that would have puppet/ansible pre-installed
> > There is https://cloudinit.readthedocs.io/en/latest/
> > But it lacks what it makes it tick.
> > 
> > Nowhere is documented
> > * how it starts (what triggers the start)
> > * how "client" finds "server"
> > * why "client" trusts "server"
> 
} I don't quite understand how this is related to building Vagrant boxes.

It isn't indeed.  Now the uncensored version:

|It feels wrong to put specific orchestartion components in all images
|when one knowns there is a generic component (cloudinit) that solves
|the problem. Sadly is cloudinit poorly documented.
|So now to choose from two problems.
|My choice would be going for understanding "cloudinit"


Good luck with your approach.


Regards
Geert Stappers


signature.asc
Description: PGP signature

Bug#940668: xwatch FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: xwatch
Version: 2.11-15
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

xwatch fails to cross build from source, because it does not pass cross
tools to make. The easiest way of doing so - using dh_auto_build - makes
xwatch cross buildable. Please consider applying the attached patch.

Helmut
diff --minimal -Nru xwatch-2.11/debian/changelog xwatch-2.11/debian/changelog
--- xwatch-2.11/debian/changelog2010-05-29 00:10:00.0 +0200
+++ xwatch-2.11/debian/changelog2019-09-18 21:04:02.0 +0200
@@ -1,3 +1,10 @@
+xwatch (2.11-15.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 18 Sep 2019 21:04:02 +0200
+
 xwatch (2.11-15) unstable; urgency=low
 
   * Rebuild for libforms2.
diff --minimal -Nru xwatch-2.11/debian/rules xwatch-2.11/debian/rules
--- xwatch-2.11/debian/rules2010-05-28 23:41:55.0 +0200
+++ xwatch-2.11/debian/rules2019-09-18 21:03:58.0 +0200
@@ -12,7 +12,7 @@
 
 build:
$(checkdir) 
-   cd src; make final "STDLFLAGS=-L/usr/lib" "RGB_FILEFLAG = 
-DRGB_FILE=\\\"/usr/share/xwatch/rgb.txt\\\""
+   dh_auto_build --sourcedirectory=src -- final "STDLFLAGS=-L/usr/lib" 
"RGB_FILEFLAG = -DRGB_FILE=\\\"/usr/share/xwatch/rgb.txt\\\""
cd src; touch build
 
 clean:

Bug#940667: RFS: cpupower-gui/0.7.0-1 [ITP] -- GUI utility to change the CPU frequency

[Rigas, Evangelos]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "cpupower-gui"

 * Package name: cpupower-gui
   Version : 0.7.0-1
   Upstream Author : Evangelos Rigas 
 * URL : https://gitlab.com/vagnum08/cpupower-gui
 * License : GPL-3.0+
 * Vcs : https://gitlab.com/vagnum08/cpupower-gui
   Section : admin

It builds those binary packages:

  cpupower-gui - GUI utility to change the CPU frequency

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

  https://mentors.debian.net/package/cpupower-gui

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/cpupower-gui/cpupower-gui_0.7.0-1.dsc

Changes since the last upload:

   * New upstream version 0.7.0

Regards,

--
  Evangelos Rigas


P.S. Apologies, the previous bug submission was a mistake.

Bug#940666: RFS: phpliteadmin/1.9.8.2-1 -- web-based SQLite database admin tool

[Коля Гурьев]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: phpliteadmin
   Version : 1.9.8.2-1
   Upstream Author : Dane Iracleous , Christopher 
Kramer  and others
 * URL : https://www.phpliteadmin.org/
 * License : GPL-3.0+
 * Vcs : https://salsa.debian.org/mymedia-guest/phpliteadmin
   Section : web

It builds those binary packages:

  phpliteadmin - web-based SQLite database admin tool
  phpliteadmin-themes - web-based SQLite database admin tool - themes

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/phpliteadmin/phpliteadmin_1.9.8.2-1.dsc

Or you can see a merge request of the new package version:

  
https://salsa.debian.org/mymedia-guest/phpliteadmin/merge_requests/2/diffs#b92c9d7f6a1fe2f439cb4bef6011394658166981

Changes since the last upload:

   * New upstream release.
 - New dependency, PHP module mbstring.
   * Drop Fix-authentication-bypass.patch since hash_equals() is now used
 to compare passwords.
   * Bump Standards-Version to 4.4.0.
 - Specify 'Rules-Requires-Root: binary-targets' in d/control.
   * Bump debhelper compatibility level to 12, no related changes.

Regards,

--
  Nicholas Guriev



signature.asc
Description: OpenPGP digital signature

Bug#892939: Working

[Torben Schou Jensen]

I have setup a second Debian Stable partition.
Booting this, kernel 4.19.0-6, graphics work fine in 1920x1080.
No drm "Link Training Unsuccessful" errors.

But booting old partition, graphics still fail and set 1024x768.

I have then compared packages on these 2 partition and cleaned up, I could
see xorg packages was missing in old partition.

By this I could see a change.
Now lightdm would startup in high resolution.
But XFCE would not start, giving black display, set monitor to sleep.
Clearing files in .cache/sessions and .config/xfce4 of user have some
effect on this, now XFCE start fine in 1920x1080.

I will now monitor and see if this is stable.
Looks like first boot, when monitor is cold, still go for 1024x768.

/Torben









-- 
Torben Schou Jensen
Swamp Thing
Homepage: http://swampthing.dk/~tsj/
Skype: swampthing38

Bug#940665: RFS: cpupower-gui/0.7.0-1 -- GUI utility to change the CPU frequency

[Rigas, Evangelos]

Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

Dear mentors,

I am looking for a sponsor for my package "cpupower-gui"

 * Package name: cpupower-gui
   Version : 0.7.0-1
   Upstream Author : [fill in name and email of upstream]
 * URL : https://gitlab.com/vagnum08/cpupower-gui
 * License : GPL-3.0+
 * Vcs : https://gitlab.com/vagnum08/cpupower-gui
   Section : admin

It builds those binary packages:

  cpupower-gui - GUI utility to change the CPU frequency

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

  https://mentors.debian.net/package/cpupower-gui

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/cpupower-gui/cpupower-gui_0.7.0-1.dsc

Changes since the last upload:

   * New upstream version 0.7.0

Regards,

Evangelos Rigas

Bug#940222: libmagic1: wrong video detection

[Christoph Biedl]

Control: tags 940222 moreinfo

Paolo Benvenuto wrote...

> I have an .avi file on a debian server. The file command reports a wrong 
> result:
>
> $ file -i myfile.avi
> myfile.avi: image/x-tga; charset=binary
>
> I get the same mime type with python3 and magic.from_file().
>
> However, the same file on my ubuntu pc (rsynced) is correctly reported as a 
> video:
>
> $ file -i myfile.avi
> myfile.avi: video/mpeg; charset=binary

Before digging further, could you please submit the version number of
file of that Ubuntu installation?

Regards,

Christoph


signature.asc
Description: PGP signature

Bug#912077: Any chance to get libbiod compiling again?

[Andreas Tille]

Hi,

[Pjotr as upstream in CC]

On Wed, Sep 18, 2019 at 04:54:16PM +0200, Matthias Klumpp wrote:
> Am Fr., 13. Sept. 2019 um 22:51 Uhr schrieb Andreas Tille :
> >
> > On Fri, Sep 13, 2019 at 03:37:32PM +0200, Matthias Klumpp wrote:
> > > Am Fr., 13. Sept. 2019 um 15:21 Uhr schrieb Andreas Tille 
> > > :
> > > > /usr/bin/ld.gold: error: bin/biod_tests.o: multiple definition of 
> > > > '_d_execBssBegAddr'
> > > > /usr/bin/ld.gold: contrib/undead/*/__main.o: previous definition here
> > > > /usr/bin/ld.gold: error: bin/biod_tests.o: multiple definition of 
> > > > '_d_execBssEndAddr'
> > > > /usr/bin/ld.gold: contrib/undead/*/__main.o: previous definition here
> > > > collect2: error: ld returned 1 exit status
> > > > [...]
> > >
> > > It's very likely that undeaD needs to be updated first in order to
> > > compile this again.
> > > Has upgrading that been attempted yet?
> >
> > I just upgraded libundead and re-added it to libbiod (I assumed libundead
> > would not have been needed for libbiod any more and thus it was removed)
> > Now the error is:
> 
> When I try to compile libbiod now, I get this error:
> ```
> ../bio/bam/baseinfo.d-mixin-165(165): Error: Options at
> ../bio/bam/baseinfo.d(579) conflicts with Options at
> ../bio/bam/baseinfo.d(482)
> ../bio/bam/baseinfo.d(175):called from here: getRangeMethods()
> ../bio/bam/baseinfo.d(278): Error: template instance
> `bio.bam.baseinfo.PerBaseInfo!(BamRead, "FZ", "MD", cast(Option)0,
> cast(Option)1, cast(Option)2, cast(Option)3)` error instantiating
> ../test/unittests.d(382):instantiated from here:
> basesWith!(BamRead, MixinArg!(string, "flowOrder"), MixinArg!(string,
> "keySequence"))
> [100/177] ldc2 -I=biod_test@exe -I=. -I=.. -I/usr/include/d
> -enable-color -O -g -release -wi -unittest
> -of='biod_test@exe/bio_bam_cigar.d.o' -c ../bio/bam/cigar.d
> [101/177] ldc2 -I=biod_test@exe -I=. -I=.. -I/usr/include/d
> -enable-color -O -g -release -wi -unittest
> -of='biod_test@exe/bio_bam_tagvalue.d.o' -c ../bio/bam/tagvalue.d
> [102/177] ldc2 -I=biod_test@exe -I=. -I=.. -I/usr/include/d
> -enable-color -O -g -release -wi -unittest
> -of='biod_test@exe/bio_bam_bai_indexing.d.o' -c
> ../bio/bam/bai/indexing.d
> [103/177] ldc2 -I=biod_test@exe -I=. -I=.. -I/usr/include/d
> -enable-color -O -g -release -wi -unittest
> -of='biod_test@exe/bio_bam_iontorrent_flowcall.d.o' -c
> ../bio/bam/iontorrent/flowcall.d
> [104/177] ldc2 -I=biod_test@exe -I=. -I=.. -I/usr/include/d
> -enable-color -O -g -release -wi -unittest
> -of='biod_test@exe/bio_bam_thirdparty_msgpack.d.o' -c
> ../bio/bam/thirdparty/msgpack.d
> ../bio/bam/thirdparty/msgpack.d(2035): Deprecation: integral promotion
> not done for -header, use '-preview=intpromote' switch or
> -cast(int)(header)
> ../bio/bam/thirdparty/msgpack.d(2035): Deprecation: integral promotion
> not done for -header, use '-preview=intpromote' switch or
> -cast(int)(header)
> ../bio/bam/thirdparty/msgpack.d(2035): Deprecation: integral promotion
> not done for -cast(byte)-header, use '-preview=intpromote' switch or
> -cast(int)(cast(byte)-header)
> ../bio/bam/thirdparty/msgpack.d(2035): Deprecation: integral promotion
> not done for -header, use '-preview=intpromote' switch or
> -cast(int)(header)
> ../bio/bam/thirdparty/msgpack.d(2035): Deprecation: integral promotion
> not done for -cast(short)-header, use '-preview=intpromote' switch or
> -cast(int)(cast(short)-header)
> ../bio/bam/thirdparty/msgpack.d(2035): Deprecation: integral promotion
> not done for -header, use '-preview=intpromote' switch or
> -cast(int)(header)
> ninja: build stopped: subcommand failed.
> dh_auto_build: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j6 -v
> returned exit code 1
> ```
> This is definitely an error in BioD itself, caused by a deprecation
> that turned into an error in recent LDC versions.
> So, libbiod will need to be upgraded for sure to fix this.

@Pjotr: Can you comment on this?

> In order to support all architectures and generate a pkg-config file I
> would have to reintroduce the Meson build definition (which upstream
> apparently has removed) or apply some hacks around the existing
> Makefile to make that work in a Debian context, which is quite a bit
> more work.

As I told you before:  I have no idea about meson.  It would be great if
we could get it working but if we restrict the package to those
architectures where it builds out of the box and save some manpower I
bet the world will keep on turning round.
 
> Btw, if libundead has no users anymore, removing it completely may be
> a good idea - we don't need to maintain something that's dead and has
> no users.

I was about to file a removal request to ftpmaster before you said in
your last mail that the former build issue might have been caused due
to the lack of libundead.  I would really love to get rid of unneeded
packages.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#813815: Open ITPs (turned into RFPs)

[Andreas Tille]

Hi Joost,

On Wed, Aug 14, 2019 at 01:07:29AM +0200, Joost van Baal-Ilić wrote:
> 
> Thanks for this reminder.  For both r-cran-nfactors and r-cran-semplot there
> already _is_ work in our g...@salsa.debian.org:r-pkg-team : at
> r-cran-nfactors.git and r-cran-semplot.git .

By chance I stumbled upon these packages as pre-dependencies for some
other package.  They also needed quite some more pre-depends, but all is
uploaded now.

> So no need for
> prepare_missing_cran_package for those.

For sure I forgot and just noticed when injecting my repository failed
since there was an existing one (same for some pre-dependencies you had
prepared before).  I kept you as second Uploader for all those packages
you created repositories.

Admittedly the existing repositories were not really a help but rather
extra work.  Dh-make-R became better over time and so I just have
overridden your work with a single commit.  I guess the detailed history
is not that important.
 
> I cannot commit to maintaining these packages appear in a stable Debian
> release: I do all my R packaging work during $dayjob; I'm mainly interested in
> keeping the packages working on Debian stable, and somewhat in sync with
> upsteam.  So that's technically what would end up in debian backports.

I would really appreciate if you would do more official backports.  I
need to do this as well (currently even more for Debian 9 than for
Debian 10).  It would be really help if you would join this so we could
share the workload.  I have some **rudimentary** script which really
needs some work (or some research whether something better exists) here:

   
https://salsa.debian.org/med-team/community/helper-scripts/blob/master/do_backport

It helps a bit to automatise things but its not really reliably neither
well testet.

> The
> reason I stick the work in git @ salsa is I feel there's a chance others might
> benefit from it too.  That's the reason I've recently not been very active in
> actually uploading it to NEW.

That's fine in general.  However, as I said, dh-make-R becomes better
and better and there is probably no point to inject something that is
not really actively used in production.
 
> There some packages of me in our git now for which I've not yet posted ITP's.
> I believe this interferes badly with some of your workflows.  Would it help 
> you
> if I actually _would_ post ITP's?  I'd be glad to.

I do not think its needed to file ITPs.  Its just a script call away.
This can be done by the maintainer who actually wants to care for the
package.

> Also, debian/copyright of most of my recent packages is still lacking.  I'll
> try to find time to work on that (note to self: have another look at cme).

That's partly what I mean.  I just added LGPL-2.1 to dh-make-R since it
was lacking before.  In case you might have generated the packaging with
an older dh-make-R and it has this license you need to copy-n-paste the
text manually.  Creating from scratch would be less work. :-P
 
> What do you think?

I hope you can join official backporting for common profit. :-)
 
> PS: thanks for your talk @ debconf, I enjoyed the video!

Nice.

Kind regards

   Andreas.
 

-- 
http://fam-tille.de

Bug#940664: combblas FTCBFS: uses mpicc

[Helmut Grohne]

Source: combblas
Version: 1.6.2-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

combblas fails to cross build from source, because it uses mpicc. mpicc
is unfixable for cross compilation and the only way to make cross
building work is not using mpicc. Fortunately, much of combblas already
uses pkg-config for discovering mpi already. It's just two
subdirectories that fail to propagate the relevant compiler flags. After
doing so, there is no need to use mpicc anymore. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru combblas-1.6.2/debian/changelog 
combblas-1.6.2/debian/changelog
--- combblas-1.6.2/debian/changelog 2019-09-14 16:43:46.0 +0200
+++ combblas-1.6.2/debian/changelog 2019-09-18 19:30:51.0 +0200
@@ -1,3 +1,10 @@
+combblas (1.6.2-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Improve cross building: Don't use mpicc. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 18 Sep 2019 19:30:51 +0200
+
 combblas (1.6.2-4) unstable; urgency=medium
 
   * Standards-Version: 4.4.0
diff --minimal -Nru combblas-1.6.2/debian/patches/mpi.patch 
combblas-1.6.2/debian/patches/mpi.patch
--- combblas-1.6.2/debian/patches/mpi.patch 1970-01-01 01:00:00.0 
+0100
+++ combblas-1.6.2/debian/patches/mpi.patch 2019-09-18 19:30:51.0 
+0200
@@ -0,0 +1,20 @@
+--- combblas-1.6.2.orig/graph500-1.2/generator/CMakeLists.txt
 combblas-1.6.2/graph500-1.2/generator/CMakeLists.txt
+@@ -3,6 +3,7 @@
+ ADD_LIBRARY( GraphGenlib btrd_binomial_distribution.c splittable_mrg.c 
mrg_transitions.c graph_generator.c permutation_gen.c make_graph.c utils.c 
scramble_edges.c)
+ target_include_directories(GraphGenlib PUBLIC 
$ 
$)
+ target_include_directories(GraphGenlib PRIVATE include/graph500/generator)
++target_include_directories(GraphGenlib PUBLIC "${MPI_C_INCLUDE_PATH}")
+ if(CMAKE_C_COMPILER_ID STREQUAL "Intel")
+   target_compile_options(GraphGenlib PRIVATE "-restrict")
+ endif()
+--- combblas-1.6.2.orig/usort/CMakeLists.txt
 combblas-1.6.2/usort/CMakeLists.txt
+@@ -3,6 +3,7 @@
+ ADD_LIBRARY( Usortlib src/parUtils.cpp src/binUtils.cpp )
+ target_include_directories(Usortlib PUBLIC 
$ 
$)
+ target_include_directories(Usortlib PRIVATE include/usort)
++target_include_directories(Usortlib PUBLIC "${MPI_C_INCLUDE_PATH}")
+ 
+ install(DIRECTORY include/ DESTINATION ${CMAKE_INSTALL_INCLUDEDIR})
+ install(TARGETS Usortlib EXPORT CombBLASTargets
diff --minimal -Nru combblas-1.6.2/debian/patches/series 
combblas-1.6.2/debian/patches/series
--- combblas-1.6.2/debian/patches/series2019-09-14 16:43:46.0 
+0200
+++ combblas-1.6.2/debian/patches/series2019-09-18 19:30:51.0 
+0200
@@ -1,2 +1,3 @@
 cmake_multiarch.patch
 sublibs_soname.patch
+mpi.patch
diff --minimal -Nru combblas-1.6.2/debian/rules combblas-1.6.2/debian/rules
--- combblas-1.6.2/debian/rules 2019-09-14 16:43:46.0 +0200
+++ combblas-1.6.2/debian/rules 2019-09-18 19:30:51.0 +0200
@@ -30,8 +30,6 @@
dh_auto_configure -- \
 -DBUILD_SHARED_LIBS=ON \
 -DCMAKE_SKIP_RPATH=ON \
--DCMAKE_C_COMPILER=mpicc \
--DCMAKE_CXX_COMPILER=mpic++ \
 -DMPIEXEC_PREFLAGS=--allow-run-as-root
tar xzf debian/testdata_combblas*.tgz -C $(BUILDDIR)
 

Bug#936399: diodon: Python2 removal in sid/bullseye

[Oliver Sauder]

Thanks for trying. Currently an outdated version of waf is used maybe 
that explains why it doesn't run with python3.


I will see when I get around to update waf upstream and repackage a new 
Diodon version.


Oliver

On 18.09.19 06:21, Scott Kitterman wrote:

This turns out to be more complicated than I had expected.  Internally waf
uses /usr/bin/env python (which still, of course, is /usr/bin/python vice
python3), so it fails with python3 even though the upstream code appears to at
least in part consider python3.

This I could fix with sed, something like:

 find -name "*.py" | xargs sed -i "s:\/usr\/bin\/env\ python:\/usr/bin\/
python3:g"
 sed -i "s:\/usr\/bin\/env\ python:\/usr/bin\/python3:g" waf
 sed -i "s:\/usr\/bin\/env\ python:\/usr/bin\/python3:g" wscript

Not pretty, but works.  But then waf exploads on me:

./waf distclean --nocache --prefix=/usr
Traceback (most recent call last):
   File "./diodon-1.8.0/waflib/Node.py", line 491, in ant_iter
 raise StopIteration
StopIteration

The above exception was the direct cause of the following exception:

Traceback (./diodon-1.8.0/waflib/Scripting.py", line 138, in waf_entry_point
 run_commands()
   File "./diodon-1.8.0/waflib/Scripting.py", line 225, in run_commands
 parse_options()
   File "./diodon-1.8.0/waflib/Scripting.py", line 186, in parse_options
 Context.create_context('options').execute()
   File "./diodon-1.8.0/waflib/Options.py", line 250, in execute
 super(OptionsContext, self).execute()
   File "./diodon-1.8.0/waflib/Context.py", line 216, in execute
 self.recurse([os.path.dirname(g_module.root_path)])
   File "./diodon-1.8.0/waflib/Context.py", line 294, in recurse
 user_function(self)
   File "./diodon-1.8.0/wscript", line 39, in options
 opt.tool_options('compiler_c')
   File "./diodon-1.8.0/waflib/Context.py", line 209, in load
 fun(self)
   File "./diodon-1.8.0/waflib/Tools/compiler_c.py", line 87, in options
 opt.load_special_tools('c_*.py', ban=['c_dumbpreproc.py'])
   File "./diodon-1.8.0/waflib/Context.py", line 515, in load_special_tools
 lst = self.root.find_node(waf_dir).find_node('waflib/extras').ant_glob(var)
   File "./diodon-1.8.0/waflib/Node.py", line 579, in ant_glob
 ret = [x for x in self.ant_iter(accept=accept, pats=[to_pat(incl),
to_pat(excl)], maxdepth=25, dir=dir, src=src, remove=kw.get('remove', True))]
   File "./diodon-1.8.0/waflib/Node.py", line 579, in 
 ret = [x for x in self.ant_iter(accept=accept, pats=[to_pat(incl),
to_pat(excl)], maxdepth=25, dir=dir, src=src, remove=kw.get('remove', True))]
RuntimeError: generator raised StopIteration
make[1]: *** [debian/rules:18: override_dh_auto_clean] Error 2
make[1]: Leaving directory './diodon-1.8.0'
make: *** [debian/rules:10: clean] Error 2
dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit
status 2

I don't know anything about waf, so that's not something I can troubleshoot.
Not going to NMU.

Scott K

On Tuesday, September 17, 2019 1:46:07 PM EDT Oliver Sauder wrote:

I currently do not have a lot of time at hand. So if you could follow up
releasing your NMU debdiff that would be great (diff looks good to me).

Oliver

On 01.09.19 09:18, Scott Kitterman wrote:

On Fri, 30 Aug 2019 07:15:05 + Matthias Klose  wrote:

Package: src:diodon
Version: 1.8.0-1
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Python2 becomes end-of-live upstream, and Debian aims to remove
Python2 from the distribution, as discussed in
https://lists.debian.org/debian-python/2019/07/msg00080.html

Your package either build-depends, depends on Python2, or uses Python2
in the autopkg tests.  Please stop using Python2, and fix this issue
by one of the following actions.


I've attached a fix in the form of an NMU debdiff.  I don't currently plan
to NMU, but may later if this remains open.  Please fix.

Scott K

Bug#940551: Please package version 2.3 of networkx

[Sandro Tosi]

> Please package version >= 2.3 of networkx, which I need for the next version 
> of
> OpenStack (called "train"). python-vitrageclient needs it.

2.3 is py3k only, so it will take a bit longer to prepare, upload, and
be available in unstable. I'll work on it soon

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#875195: [stretchplayer] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

El mié., 18 sep. 2019 13:18, Reiner Herrmann  escribió:

> Control: tags -1 + patch
>
> Dear maintainers,
>
> porting stretchplayer to Qt5 was straightforward.
> You can find a merge request on salsa [0].
>

The patch looks great. I'll happy NMU it if you (the maintainer) agree.
I'll also NMU it if we don't get a reply in ~3 days, as this bug never got
a reply from the maintainers.

Cheers, Lisandro

>

Bug#940269: [Pkg-giraffe-maintainers] Bug#940269: kopano-webapp-files: Does not appear in plugins list

[Dr. Axel Stammler]

Thank you.

Is there a way for me to use local storage space on the server to store user 
files?

Best regards,

Axel

signature.asc
Description: PGP signature

Bug#940663: xfce4-panel: first-order menus of panel items have unusually thick borders

[Piotr Engelking]

Package: xfce4-panel
Version: 4.14.0-1
Severity: minor

With window manager compositing enabled, first-order menus of panel
items have unusually thick borders. Depending on the menu, the color of
the border can be black or gray. The submenus have standard borders.

Please make all menus use standard borders.

The attached screenshot shows the right-click context menu of a panel
separator.


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

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xfce4-panel depends on:
ii  exo-utils0.12.8-1
ii  libatk1.0-0  2.34.0-1
ii  libc62.29-1
ii  libcairo21.16.0-4
ii  libexo-2-0   0.12.8-1
ii  libgarcon-1-00.6.4-1
ii  libgarcon-gtk3-1-0   0.6.4-1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.60.6-2
ii  libgtk-3-0   3.24.11-1
ii  libgtk2.0-0  2.24.32-4
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libwnck-3-0  3.32.0-1
ii  libx11-6 2:1.6.7-1
ii  libxext6 2:1.3.3-1+b2
ii  libxfce4panel-2.0-4  4.14.0-1
ii  libxfce4ui-2-0   4.14.1-1+b1
ii  libxfce4util74.14.0-1
ii  libxfconf-0-34.14.1-1

xfce4-panel recommends no packages.

xfce4-panel suggests no packages.

-- no debconf information

Bug#940660: elpa-elpy: add Suggests: python3-rope to refactor code

[David Bremner]

Salman Mohammadi  writes:

> Package: elpa-elpy
> Version: 1.31.0-1
> Severity: normal
>
> Dear Nicholas,
>
> Adding this entry `Suggests: python3-rope` to debian/control ensures
> that we can refactor the code without error messages like this:
>
> elpy-rpc--default-error-callback: Elpy error: rope not installed, cannot
> refactor code.
>


Just for the record, Suggests won't cause it to be installed
automatically for many (most?) users.

d

Bug#940662: contextfree FTCBFS: strips with the wrong strip

[Helmut Grohne]

Source: contextfree
Version: 3.1+dfsg1-2
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

contextfree fails to cross build from source, because it strips with the
wrong strip. Such stripping also breaks DEB_BUILD_OPTIONS=nostrip as
well as generation of -dbgsym packages. stripping is best deferred to
dh_strip. Please consider applying the attached patch.

Helmut
--- contextfree-3.1+dfsg1.orig/Makefile
+++ contextfree-3.1+dfsg1/Makefile
@@ -129,11 +129,9 @@
 #
 # Executable
 #
-# Under Cygwin replace strip $@ with strip $@.exe
 
 cfdg: $(OBJS)
 	$(LINK.o) $^ $(LINKFLAGS) -o $@
-	strip $@
 
 
 #

Bug#940624: Errors in the translatable messages

[Paul Gevers]

Dear debian-l10n-english members,

Yesterday, I received the following bug report about the templates of
dbconfig-common. I recall the templates have been reviewed on this list
in the past, could you please comment on the remarks by Maarten?

Paul

On 17-09-2019 23:20, maar...@posteo.de wrote:
> Package: dbconfig-common
> Version: 2.0.12
> Severity: minor
> 
> 
> 
> Dear Maintainer
> 
> 
> On 1 September 2019 I delivered an updated Dutch translation for
> dbconfig-common. This is my report on the errors that I found in the
> English source text.
> 
> This report uses 'the English source text' as an abstraction that
> refers to the strings that have been made translatable in the source
> code of dbconfig-common. It also uses 'paragraph' to refer to one of
> those strings.
> 
> I will use the error types that are listed in the following table.
> If you use a monospaced font, the table will be displayed neatly.
> 
> ===
> linguistic level error types
> ===
> word level   spelling error
>  word choice error
> ---
> sentence level   grammatical error
>  phrasing error
> ---
> paragraph level  coherence error
>  clarity error
> ---
> text level   text level error
> ===
> 
> 
> SOURCE TEXT
> Alternatively the passwords can be permanently remembered in the
> debconf database (which is protected by Unix file permissions),
> though this is less secure and thus not the default setting.
> ERRORS
> - Word choice error: 'permanently remembered' ('stored').
> 
> SOURCE TEXT
> The ${pkg} package must have a database installed and configured
> before it can be used. This can be optionally handled with
> dbconfig-common.
> ERRORS
> - Phrasing error: 'This can be optionally handled with
> dbconfig-common.' (This can be done with dbconfig-common when
> desired.).
> 
> SOURCE TEXT
> If you are an advanced database administrator and know that you want
> to perform this configuration manually, or if your database has
> already been installed and configured, you should refuse this option.
> Details on what needs to be done should most likely be provided in
> /usr/share/doc/${pkg}.
> ERRORS
> - Phrasing error: 'know that you want' ('want').
> - Phrasing error: 'should most likely be provided in' ('is likely
> provided in').
> 
> SOURCE TEXT
> If you wish to reinstall the database for ${pkg}, you should select
> this option. If you do not wish to do so (if you are reconfiguring
> the package for unrelated reasons), you should not select this option.
> ERRORS
> - Clarity error: 'for unrelated reasons'.
> 
> SOURCE TEXT
> Warning: if you change the name of the database, the old database
> will not be removed. If you change the name of the user that connects
> to the database, the privileges of the original user will not be
> revoked.
> ERRORS
> - Word choice error: 'Warning' ('Warnings').
> - Grammatical error: 'if' (If).
> - Coherence error: 'If' (And if).
> 
> SOURCE TEXT
> Perform upgrade on database for ${pkg} with dbconfig-common?
> ERRORS
> - Phrasing error: 'Perform upgrade on' (Upgrade).
> 
> SOURCE TEXT
> According to the maintainer for this package, database upgrade
> operations need to be performed on ${pkg}. Typically, this is due to
> changes in how a new upstream version of the package needs to store
> its data.
> ERRORS
> - Word choice error: 'for this package' (of this package).
> - Phrasing error: 'database upgrade operations need to be performed
> on ${pkg}' (the ${pkg} database needs to be updated).
> - Phrasing error: 'needs to store' (stores).
> - Coherence error: 'its data' (the database).
> 
> SOURCE TEXT
> If you want to handle this process manually, you should refuse this
> option. Otherwise, you should choose this option. During the upgrade,
> a backup of the database will be made in
> /var/cache/dbconfig-common/backups, from which the database can be
> restored in the case of problems.
> ERRORS
> - Phrasing error: 'handle this process' (do this) {verbosity}.
> - Word choice error: 'from which' (with which).
> - Phrasing error: 'in the case of' (in case of) {not idiomatic}.
> 
> SOURCE TEXT
> If other database types are supported by ${pkg} but not shown here,
> the reason for their omission is that the corresponding
> dbconfig- packages are not installed. If you know that
> you want the package to use another supported database type, your
> best option is to back out of the dbconfig-common questions and opt
> out of dbconfig-common assistance for this package for now. Install
> your preferred dbconfig- option from the list in 

Bug#919825: systemd: local filesystems other than '/' and '/usr' not checked and mounted -- emergency mode

[Michael Biebl]

Am 17.09.19 um 04:47 schrieb Bob Tracy:
> I note the bug was closed back on April 15th.  I wanted to report that
> the underlying issue was evidently a buggy "glibc" implementation.  A
> recent upgrade to "libc6.1" (to version 2.29-1) took care of the
> problem.
> 
> See a discussion thread in the "debian-alpha" mail list with subject
> "systemd woes continue".  Aurelien Jarno reported on Sept. 9th he had
> been seeing the same bug I was, and that the recent "glibc" update in
> "unstable" fixed it.  As of today, I can verify the fix.

Have you (or Aurelien) further investigated what the underlying issue in
glibc was and which specific commit fixed it?

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#940661: swh-plugins: analogueOsc produces NaN under some conditions (reloaded)

[Frank Heckenbach]

Package: swh-plugins
Version: 0.4.17-2
Severity: normal
Tags: upstream patch

The bug from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781997
has reappeared!

The same test program as given there fails again, even though my
patch from then has been applied.

I suppose this is due to more aggressive optimizations by newer
compiler versions, in connection with the "-ffast-math" option.

In particular, my isnan() check doesn't work because "-ffast-math"
ignores NaNs (see https://stackoverflow.com/a/38981307).

So I tried a different fix now by checking for the problematic case
before NaN is produces. This seems to work for me.

This patch undoes my previous patch, so it's to be applied on top of
it.

It also fixes another instance of the problem (which my previous
patch didn't) that occurs when q is close to zero, i.e. when warm is
close to 0.999f (which is in the valid range!).

Though I wonder if "-ffast-math" should be used at all. As another
answer on the SO page linked above says: "No, you cannot safely use
-ffast-math except on code designed to be used with it. There are
all sorts of important constructs for which it generates completely
wrong results." I think edge cases like the one causing this problem
are exactly the kind of things one must watch out for when using
"-ffast-math", so I wonder if the code has actually been checked
carefully for "-ffast-math" compatibility. If not, it might be
worthwhile to sacrifice a few CPU cycles for correct results. Of
course, that's a bigger decision that I can't make in a bug fix, but
you may want to consider it.
--- analogue_osc_1416.xml
+++ analogue_osc_1416.xml
@@ -59,12 +59,13 @@
 rnda *= 59;
 osc->ph.all += (((rnda + rndb)/2) % max_jump) - max_jump/2;
 osc->ph.all &= osc->ph_mask;
-	y = (x - q) / (1.0f - f_exp(-1.2f * (x - q))) +
-  q / (1.0f - f_exp(1.2f * q));
-	/* Catch the case where x ~= q */
-	if (isnan(y) || fabs(y) > 1.0f) {
-		y = 0.8f + q / (1.0f - f_exp(1.2f * q));
-	}
+	/* If x - q or q are close to 0, these computations would produce NaN.
+	   To avoid this, substitute the limit instead -- the results aren't
+	   noticeably different (in float) from the limit already around 1e-8. */
+	y = fabs(x - q) < 1e-10 ? 0.8f
+	  : (x - q) / (1.0f - f_exp(-1.2f * (x - q)));
+	y += fabs(q) < 1e-10 ? -0.8f
+	   : q / (1.0f - f_exp(1.2f * q));
 	otm2 = otm1;
 otm1 = leak * otm1 + y - itm1;
 itm1 = y;

Bug#940660: elpa-elpy: add Suggests: python3-rope to refactor code

[Salman Mohammadi]

Package: elpa-elpy
Version: 1.31.0-1
Severity: normal

Dear Nicholas,

Adding this entry `Suggests: python3-rope` to debian/control ensures
that we can refactor the code without error messages like this:

elpy-rpc--default-error-callback: Elpy error: rope not installed, cannot
refactor code.


Regards

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

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

Versions of packages elpa-elpy depends on:
ii dh-elpa-helper 2.0.2
ii elpa-company 0.9.9-2
ii elpa-find-file-in-project 5.7.7-1
ii elpa-highlight-indentation 0.7.0-4
ii elpa-pyvenv 1.20-2
ii elpa-s 1.12.0-3
ii elpa-yasnippet 0.13.0-3
ii emacsen-common 3.0.4
ii flake8 3.7.8-3
ii python3 3.7.3-1
ii python3-flake8 3.7.8-3

Versions of packages elpa-elpy recommends:
ii emacs 1:26.1+1-4
ii emacs-gtk [emacs] 1:26.1+1-4
ii libjs-sphinxdoc 1.8.5-3
ii python3-jedi 0.14.1-1

Versions of packages elpa-elpy suggests:
pn black 
pn elpa-pip-requirements 
pn python3-autopep8 
pn python3-jupyter-console 
ii python3-pip 18.1-5
pn yapf3 

-- no debconf information

Bug#875195: [stretchplayer] Future Qt4 removal from Buster

[Reiner Herrmann]

Control: tags -1 + patch

Dear maintainers,

porting stretchplayer to Qt5 was straightforward.
You can find a merge request on salsa [0].

Kind regards,
  Reiner

[0] https://salsa.debian.org/multimedia-team/stretchplayer/merge_requests/1


signature.asc
Description: PGP signature

Bug#940659: starts editing in wrong line

[Juan Cespedes]

Package: ldapvi
Version: 1.7-10+b3
Severity: normal
Tags: patch

When using "ldapvi" without SASL, ldapvi starts editing the LDAP results
at an undefined line number instead of just below the initial comments.

This patch fixes it:

--- ldapvi-1.7.orig/ldapvi.c
+++ ldapvi-1.7/ldapvi.c
@@ -1465,7 +1465,7 @@ copy_sasl_output(FILE *out, char *sasl)
int line = 0;
int c;
 
-   if (lstat(sasl, ) == -1) return;
+   if (lstat(sasl, ) == -1) return line;
if ( !(in = fopen(sasl, "r"))) syserr();
 
if (st.st_size > 0) {

Bug#940658: gnunet-gtk FTCBFS: broken, oudated, embedded copy of AM_PATH_GTK_3_0

[Helmut Grohne]

Source: gnunet-gtk
Version: 0.10.1-5
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

gnunet-gtk fails to cross build from source, because it uses a broken,
outdated, embedded copy of AM_PATH_GTK_3_0. Please remove your copy and
use the fixed version from the archive instead. Alternatively, update
your copy and register it with the security tracker as an embedded code
copy. This bug comes without a patch, because the bug is already fixed
upstream. gnunet-gtk just happens to have a copy of the bug.

Helmut

Bug#940657: oscpack FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: oscpack
Version: 1.1.0-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

oscpack fails to cross build from source, because it does not pass cross
tools to make. The easiest way of doing so - using dh_auto_build - makes
oscpack cross buildable. Please consider applying the attached patch.

Helmut
diff --minimal -Nru oscpack-1.1.0/debian/changelog 
oscpack-1.1.0/debian/changelog
--- oscpack-1.1.0/debian/changelog  2017-07-23 09:24:16.0 +0200
+++ oscpack-1.1.0/debian/changelog  2019-09-18 17:56:45.0 +0200
@@ -1,3 +1,9 @@
+oscpack (1.1.0-3) UNRELEASED; urgency=medium
+
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 18 Sep 2019 17:56:45 +0200
+
 oscpack (1.1.0-2) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru oscpack-1.1.0/debian/rules oscpack-1.1.0/debian/rules
--- oscpack-1.1.0/debian/rules  2017-07-23 01:14:28.0 +0200
+++ oscpack-1.1.0/debian/rules  2019-09-18 17:56:42.0 +0200
@@ -10,7 +10,7 @@
dh $@
 
 override_dh_auto_build:
-   make lib
+   dh_auto_build -- lib
 
 override_dh_strip:
dh_strip --dbgsym-migration='liboscpack-dbg (<< 1.1.0-1~)'

Bug#940656: torbrowser-launcher: Torbrowser downloads but apparmor stops from running, xfce

[ithink314]

Package: torbrowser-launcher
Version: 0.3.2-2
Severity: important

Dear Maintainer,

   * What led up to the situation?
Net install debian 10.1, update upgrade to testing
Add contrib to sources, install torbrowser-launcher and run it

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Applications menu, internet, torbrowser
   * What was the outcome of this action?
First time, displayed download progress, downloaded, then nothing. 
Subsequent attempts, nothing. 
Syslog has, for each time:
Sep 18 08:12:20 machine kernel: [  138.869232] audit: type=1400 
audit(1568808740.221:18): 
apparmor="DENIED" operation="file_mmap" profile="torbrowser_firefox" 
name="/home/user/.local/share/torbrowser/tbb/i686/tor-browser_en-US/Browser/TorBrowser/Tor/libstdc++/libstdc++.so.6"
 
pid=954 comm="firefox.real" requested_mask="m" denied_mask="m" fsuid=1000 
ouid=1000

   * What outcome did you expect instead?
torbrowser runs.


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

Kernel: Linux 5.2.0-2-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages torbrowser-launcher depends on:
ii  ca-certificates   20190110
ii  libdbus-glib-1-2  0.110-4
ii  python3   3.7.3-1
ii  python3-gpg   1.13.1-1
ii  python3-pyqt5 5.12.3+dfsg-2
ii  python3-requests  2.21.0-1
ii  python3-socks 1.6.8+dfsg-1

Versions of packages torbrowser-launcher recommends:
ii  tor  0.4.1.5-1

Versions of packages torbrowser-launcher suggests:
ii  apparmor  2.13.3-5

-- no debconf information

Bug#940653: ITP: r-cran-openmx -- GNU R extended structural equation modelling

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-openmx -- GNU R extended structural equation modelling
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-openmx
  Version : 2.13.2
  Upstream Author : Steven M. Boker,
* URL : https://cran.r-project.org/package=OpenMx
* License : Apache-2.0
  Programming Lang: GNU R
  Description : GNU R extended structural equation modelling
 Create structural equation models that can be manipulated
 programmatically. Models may be specified with matrices or paths (LISREL
 or RAM) Example models include confirmatory factor, multiple group,
 mixture distribution, categorical threshold, modern test theory,
 differential Fit functions include full information maximum likelihood,
 maximum likelihood, and weighted least squares. equations, state space,
 and many others. Support and advanced package binaries available at
 . The software is described in Neale,
 Hunter, Pritikin, Zahery, Brick, Kirkpatrick, Estabrook, Bates, Maes, &
 Boker (2016) .

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

Bug#935290: moar digging

[Mo Zhou]

Fresh installation is fine. /usr/share/perl6 should be a
symlink pointing to /usr/lib/perl6 in the latest version.
When directly upgrading rakudo to the expeirmental version,
this is not handled by dpkg.

I've fixed the upgrade issue in rakduo 2019.07.1-2 (experimental).
Later when the binary is avaialble in mirrors, I'll test
rakudo with the following dockerfile. If anything looks fine,
I'll start uploading 2019.07 to unstable.

--

fromdebian:sid
workdir /tmp
run echo "deb http://ftp2.cn.debian.org/debian sid main contrib
non-free" > /etc/apt/sources.list
run echo "deb http://ftp2.cn.debian.org/debian experimental main
contrib non-free" >> /etc/apt/sources.list
run apt update -y
run apt dist-upgrade -y
run apt autoremove -y

# fresh install [OK]
#runapt install -t experimental rakudo -y
#runperl6 -e '"Hello Perl6!".say'

# sid->experimental upgrade [unverified]
run apt install -t sid rakudo -y
run perl6 -e '"Hello Perl6!".say'
run apt install -t experimental rakudo -y
run perl6 -e '"Hello Perl6!".say'


On 2019-09-16 10:58, Dominique Dumont wrote:
> On Saturday, 14 September 2019 02:37:41 CEST Mo Zhou wrote:
>> Could you please verify the {moarvm,nqp,rakudo}-2019.07.1 in
>> experimental? Shall I proceed and upload it to unstable?
> 
> Looks like there's an issue with /usr/share/perl6 link:
> 
> $ perl6 -e 'say "hello"'
> Unhandled exception: While looking for '/usr/share/perl6/runtime/
> perl6.moarvm': no such file or directory
> 
> /usr/share/perl6 is not a link on my machine:
> 
> $ ll /usr/share/perl6
> total 8
> drwxr-xr-x 5 root root 4096 Aug 31 19:28 debian-sources
> -rw-r--r-- 1 root root   41 Jun 22  2018 previous-compiler-id
> 
> May be because /usr/share/perl6 existed before rakudo 2019-07 installation.
> 
> All the best
> 
> Dod

Bug#939169: update

[Cihan Kaya]

Hi,

I've tried Debian 10 with Gnome, KDE Neon, Opensuse Tumbleweed, Ubuntu
19.04 and Manjaro KDE 18.1.0 and except Manjaro, all distros have this
ussue. Since I tried Gnome and detected same issue, I think it is not
plasma problem. It might be a driver issue or alsa bug.

I hear this noise after logging in and just before computer resets or
shots down as well.

Please find attached alsa info logs for hardware details.

Kind regards,
Cihan
upload=true=true=
!!
!!ALSA Information Script v 0.4.64
!!

!!Script ran on: Wed Sep 18 14:28:29 UTC 2019


!!Linux Distribution
!!--

Debian GNU/Linux bullseye/sid \n \l PRETTY_NAME="Debian GNU/Linux bullseye/sid" 
NAME="Debian GNU/Linux" ID=debian HOME_URL="https://www.debian.org/; 
SUPPORT_URL="https://www.debian.org/support; 
BUG_REPORT_URL="https://bugs.debian.org/;


!!DMI Information
!!---

Manufacturer:  Packard Bell
Product Name:  EasyNote TM85
Product Version:   V1.15
Firmware Version:  V1.15
Board Vendor:  Packard Bell
Board Name:EasyNote TM85


!!ACPI Device Status Information
!!---

/sys/bus/acpi/devices/LNXVIDEO:01/status 15
/sys/bus/acpi/devices/PNP0103:00/status  15
/sys/bus/acpi/devices/PNP0303:00/status  15
/sys/bus/acpi/devices/PNP0C0A:00/status  31
/sys/bus/acpi/devices/PNP0C0F:00/status  11
/sys/bus/acpi/devices/PNP0C0F:01/status  11
/sys/bus/acpi/devices/PNP0C0F:02/status  9
/sys/bus/acpi/devices/PNP0C0F:03/status  11
/sys/bus/acpi/devices/PNP0C0F:04/status  9
/sys/bus/acpi/devices/PNP0C0F:05/status  11
/sys/bus/acpi/devices/PNP0C0F:06/status  11
/sys/bus/acpi/devices/PNP0C0F:07/status  11
/sys/bus/acpi/devices/SYN1B16:00/status  15
/sys/bus/acpi/devices/device:0b/status   15


!!Kernel Information
!!--

Kernel release:5.2.0-2-amd64
Operating System:  GNU/Linux
Architecture:  x86_64
Processor: unknown
SMP Enabled:   Yes


!!ALSA Version
!!

Driver version: k5.2.0-2-amd64
Library version:1.1.8
Utilities version:  1.1.8


!!Loaded ALSA modules
!!---

snd_hda_intel
snd_hda_intel


!!Sound Servers on this system
!!

Pulseaudio:
  Installed - Yes (/usr/bin/pulseaudio)
  Running - Yes


!!Soundcards recognised by ALSA
!!-

 0 [MID]: HDA-Intel - HDA Intel MID
  HDA Intel MID at 0xb710 irq 30
 1 [NVidia ]: HDA-Intel - HDA NVidia
  HDA NVidia at 0xb300 irq 17


!!PCI Soundcards installed in the system
!!--

00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High 
Definition Audio (rev 05)
01:00.1 Audio device: NVIDIA Corporation GF108 High Definition Audio Controller 
(rev a1)


!!Advanced information - PCI Vendor/Device/Subsystem ID's
!!---

00:1b.0 0403: 8086:3b56 (rev 05)
Subsystem: 1025:036d
--
01:00.1 0403: 10de:0bea (rev a1)
Subsystem: 1025:036d


!!Modprobe options (Sound related)
!!

snd_pcsp: index=-2
snd_usb_audio: index=-2
snd_atiixp_modem: index=-2
snd_intel8x0m: index=-2
snd_via82xx_modem: index=-2


!!Loaded sound module options
!!---

!!Module: snd_hda_intel
align_buffer_size : -1
bdl_pos_adj : 
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
beep_mode : 
Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y
enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y
enable_msi : -1
id : 
(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
index : 
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
jackpoll_ms : 
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
model : 
(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
patch : 
(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
pm_blacklist : Y
position_fix : 
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
power_save : 1
power_save_controller : Y
probe_mask : 

Bug#912077: Any chance to get libbiod compiling again?

[Matthias Klumpp]

Am Fr., 13. Sept. 2019 um 22:51 Uhr schrieb Andreas Tille :
>
> On Fri, Sep 13, 2019 at 03:37:32PM +0200, Matthias Klumpp wrote:
> > Am Fr., 13. Sept. 2019 um 15:21 Uhr schrieb Andreas Tille 
> > :
> > > /usr/bin/ld.gold: error: bin/biod_tests.o: multiple definition of 
> > > '_d_execBssBegAddr'
> > > /usr/bin/ld.gold: contrib/undead/*/__main.o: previous definition here
> > > /usr/bin/ld.gold: error: bin/biod_tests.o: multiple definition of 
> > > '_d_execBssEndAddr'
> > > /usr/bin/ld.gold: contrib/undead/*/__main.o: previous definition here
> > > collect2: error: ld returned 1 exit status
> > > [...]
> >
> > It's very likely that undeaD needs to be updated first in order to
> > compile this again.
> > Has upgrading that been attempted yet?
>
> I just upgraded libundead and re-added it to libbiod (I assumed libundead
> would not have been needed for libbiod any more and thus it was removed)
> Now the error is:

When I try to compile libbiod now, I get this error:
```
../bio/bam/baseinfo.d-mixin-165(165): Error: Options at
../bio/bam/baseinfo.d(579) conflicts with Options at
../bio/bam/baseinfo.d(482)
../bio/bam/baseinfo.d(175):called from here: getRangeMethods()
../bio/bam/baseinfo.d(278): Error: template instance
`bio.bam.baseinfo.PerBaseInfo!(BamRead, "FZ", "MD", cast(Option)0,
cast(Option)1, cast(Option)2, cast(Option)3)` error instantiating
../test/unittests.d(382):instantiated from here:
basesWith!(BamRead, MixinArg!(string, "flowOrder"), MixinArg!(string,
"keySequence"))
[100/177] ldc2 -I=biod_test@exe -I=. -I=.. -I/usr/include/d
-enable-color -O -g -release -wi -unittest
-of='biod_test@exe/bio_bam_cigar.d.o' -c ../bio/bam/cigar.d
[101/177] ldc2 -I=biod_test@exe -I=. -I=.. -I/usr/include/d
-enable-color -O -g -release -wi -unittest
-of='biod_test@exe/bio_bam_tagvalue.d.o' -c ../bio/bam/tagvalue.d
[102/177] ldc2 -I=biod_test@exe -I=. -I=.. -I/usr/include/d
-enable-color -O -g -release -wi -unittest
-of='biod_test@exe/bio_bam_bai_indexing.d.o' -c
../bio/bam/bai/indexing.d
[103/177] ldc2 -I=biod_test@exe -I=. -I=.. -I/usr/include/d
-enable-color -O -g -release -wi -unittest
-of='biod_test@exe/bio_bam_iontorrent_flowcall.d.o' -c
../bio/bam/iontorrent/flowcall.d
[104/177] ldc2 -I=biod_test@exe -I=. -I=.. -I/usr/include/d
-enable-color -O -g -release -wi -unittest
-of='biod_test@exe/bio_bam_thirdparty_msgpack.d.o' -c
../bio/bam/thirdparty/msgpack.d
../bio/bam/thirdparty/msgpack.d(2035): Deprecation: integral promotion
not done for -header, use '-preview=intpromote' switch or
-cast(int)(header)
../bio/bam/thirdparty/msgpack.d(2035): Deprecation: integral promotion
not done for -header, use '-preview=intpromote' switch or
-cast(int)(header)
../bio/bam/thirdparty/msgpack.d(2035): Deprecation: integral promotion
not done for -cast(byte)-header, use '-preview=intpromote' switch or
-cast(int)(cast(byte)-header)
../bio/bam/thirdparty/msgpack.d(2035): Deprecation: integral promotion
not done for -header, use '-preview=intpromote' switch or
-cast(int)(header)
../bio/bam/thirdparty/msgpack.d(2035): Deprecation: integral promotion
not done for -cast(short)-header, use '-preview=intpromote' switch or
-cast(int)(cast(short)-header)
../bio/bam/thirdparty/msgpack.d(2035): Deprecation: integral promotion
not done for -header, use '-preview=intpromote' switch or
-cast(int)(header)
ninja: build stopped: subcommand failed.
dh_auto_build: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j6 -v
returned exit code 1
```
This is definitely an error in BioD itself, caused by a deprecation
that turned into an error in recent LDC versions.
So, libbiod will need to be upgraded for sure to fix this.
In order to support all architectures and generate a pkg-config file I
would have to reintroduce the Meson build definition (which upstream
apparently has removed) or apply some hacks around the existing
Makefile to make that work in a Debian context, which is quite a bit
more work.

Btw, if libundead has no users anymore, removing it completely may be
a good idea - we don't need to maintain something that's dead and has
no users.

Cheers,
Matthias
-- 
I welcome VSRE emails. See http://vsre.info/

Bug#940652: ITP: git-quick-stats -- simple and efficient way to access various statistics in git repository

[Birger Schacht]

Package: wnpp
Severity: wishlist
Owner: Birger Schacht 

* Package name: git-quick-stats
  Version : 2.0.9
  Upstream Author : Lukáš Mešťan
* URL : https://lukasmestan.com/git-quick-stats/
* License : MIT
  Programming Lang: Shellscript
  Description : simple and efficient way to access various statistics in 
git repository


git-quick-stats is a simple and efficient way to access various
statistics in git repository.
.
Any git repository contains tons of information about commits,
contributors, and files. Extracting this information is not always
trivial, mostly because of a gadzillion options to a gadzillion git
commands.

Bug#940650: uphpmvault FTCBFS: strips with the wrong strip, twice

[Helmut Grohne]

Source: uphpmvault
Version: 0.8
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

uphpmvault fails to cross build from source, because both make and make
install strip with the wrong strip. Beyond breaking cross compilation,
this also breaks DEB_BUILD_OPTIONS=nostrip as well as generation of
-dbgsym packages. It is best to defer stripping to dh_strip. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru uphpmvault-0.8/Makefile uphpmvault-0.8+nmu1/Makefile
--- uphpmvault-0.8/Makefile 2011-05-02 19:07:50.0 +0200
+++ uphpmvault-0.8+nmu1/Makefile2019-09-18 16:07:56.0 +0200
@@ -13,6 +13,7 @@
 CFLAGS:=-O2 -g
 LFLAGS:=-g
 CFLAGS += -Wall -Wformat -Wstrict-aliasing
+INSTALL?=install
 
 .PHONY: all
 all: $(TARGETS)
@@ -22,13 +23,11 @@
 uphpmvault: $(uphpmvault_OBJS)
@echo "LINK   " $@
@$(CXX) -o $@ $^ $(LFLAGS)
-   @cp $@ $@_unstripped
-   @strip $@
 
 .PHONY: install
 install:
-   install -d $(DESTDIR)/usr/bin
-   install -s uphpmvault $(DESTDIR)/usr/bin
+   $(INSTALL) -d $(DESTDIR)/usr/bin
+   $(INSTALL) -s uphpmvault $(DESTDIR)/usr/bin
 
 .PHONY: build
 build:
diff --minimal -Nru uphpmvault-0.8/debian/changelog 
uphpmvault-0.8+nmu1/debian/changelog
--- uphpmvault-0.8/debian/changelog 2011-07-03 20:03:10.0 +0200
+++ uphpmvault-0.8+nmu1/debian/changelog2019-09-18 16:13:03.0 
+0200
@@ -1,3 +1,10 @@
+uphpmvault (0.8+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Defer stripping to dh_strip. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 18 Sep 2019 16:13:03 +0200
+
 uphpmvault (0.8) unstable; urgency=low
 
   * Added stddef.h s.t. offsetof macro is available.  Required by GCC 4.6.  
(closes: bug#632569)
diff --minimal -Nru uphpmvault-0.8/debian/rules uphpmvault-0.8+nmu1/debian/rules
--- uphpmvault-0.8/debian/rules 2008-06-25 06:53:22.0 +0200
+++ uphpmvault-0.8+nmu1/debian/rules2019-09-18 16:09:21.0 +0200
@@ -1,3 +1,6 @@
 #!/usr/bin/make -f
 %:
dh $@
+
+override_dh_auto_install:
+   dh_auto_install -- INSTALL='install --strip-program=true'

Bug#940651: cycle: package installation fails at configuration stage due to TabError

[Giuseppe Bilotta]

Package: cycle
Version: 0.3.1-15
Severity: serious

Upgrading cycle to the latest version in unstable leads to the following
error during configuration:

Sorry: TabError: inconsistent use of tabs and spaces in indentation (cycle.py, 
line 29)

This is due to the mix of 4 spaces for one level of indent vs 1 tab for
two levels, which is not supported in Python3.

Best regards,

Giuseppe Bilotta


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

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

Versions of packages cycle depends on:
ii  python3   3.7.3-1
ii  python3-wxgtk4.0  4.0.6+dfsg-2

cycle recommends no packages.

cycle suggests no packages.

-- no debconf information

Bug#940649: git-debrebase checkout rune

[Ian Jackson]

Package: git-debrebase
Version: 9.9
User: d...@packages.debian.org
Usertags: rsn

git-debrebase uses runes like this for trying to make the working tree
and index like some commit without disturbing HEAD:
runcmd @git, qw(reset --quiet), $u->{Commit}, qw(-- .);
runcmd @git, qw(checkout), $u->{Commit}, qw(-- .);
runcmd @git, qw(clean -xdff);

This is ridiculous.  Mark Wooding did some archaeology and discovered
that `git-reset' used to contain a rune like this:
   git read-tree -v --reset -u REV

This is simpler and probably faster and in my tests at least as
reliable (I think I may have seen some anomalies with strange corner
cases with the original runes above, but I haven't tried a systematic
repro).  (It is also rather mad.)

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#919504: [kmail] blank page on print preview

[Dmitry Shachnev]

Hi Melvin!

On Tue, Sep 17, 2019 at 01:57:09PM +0200, Melvin Vermeeren wrote:
> Hi,
>
> I have looked around in a bunch of sources and have come to the conclusion 
> that this is most probably a bug in the bundled chromium version of Qt 5.11.1 
> Looking around For Chromium it is difficult to track bugs due to its size and 
> due to many users making bogus bug reports, but over the years there have 
> been 
> multiple issues where Chromium print(-preview) results in blank pages.
>
> The changelog of Qt 5.12.x does also not list anything significant related to 
> printing, further supporting this theory. I have also confirmed Qt 5.12.0 
> resolves the issue.
>
>
> There are two ways to fix this issue as I see it now:
>
> 1. Hard: Figure out the difference between Chromium 65.0.3325.230 (Qt 5.11.1 
> - 
> Qt 5.11.3) and Chromium 69.0.3497.128 (Qt 5.12.0), find upstream bug reports 
> in Chromium and see if there are any relevant patches and/or commits. Then 
> attempt to backport these to fix the bug.
>
> 2. Easy: update to QtWebEngine 5.12.0, keep build depends as Qt 5.11.x. Take
> the earliest Debian 5.12.x release, before build depends were updated, and
> downgrade to 5.12.0 so the diff is as small as possible. This builds fine in a
> buster environment and works as expected. The only "issue" is applications
> still say "QtWebEngine 5.11.3" in their about as they aren't recompiled.

Thanks for your analysis. We are going to update the whole Qt to 5.12 soon
in unstable.

Regarding Buster, the second variant will not be possible for many reasons.

First reason: the diff is huge and it is impossible to review it manually,
which is required for a stable release update.

Second reason: while newer Qt WebEngine can build fine against older Qt,
the version mismatch can cause issues in other applications. In Ubuntu,
I tried to build Qt WebEngine 5.9.8 with Qt 5.9.5 (same series!), and
several KDE applications started getting this error (when building or
running tests):

> CMake Error at 
> /usr/lib/x86_64-linux-gnu/cmake/Qt5WebEngineCore/Qt5WebEngineCoreConfig.cmake:101
>  (find_package):
>   Could not find a configuration file for package "Qt5Quick" that is
>   compatible with requested version "5.9.8".
>
>   The following configuration files were considered but not accepted:
>
> /usr/lib/x86_64-linux-gnu/cmake/Qt5Quick/Qt5QuickConfig.cmake, version: 
> 5.9.5 

So the only way to fix this issue in Buster is the first (hard) variant.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#880199: interested in the skopeo

[Yaroslav Halchenko]

We are interested to use skopeo in DataLad project.  So I wondered about
the status of this ITP.  Thank you in advance for the reply!

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#940582: [debian-mysql] Bug#940582: Update Severity of issue - Production Builds Can't Deploy

[Michael Amato]

Hi Faustin-

Thanks for the quick reply on this. It seems like prefacing my apt install
with apt update had resolved the issue. Great catch here - I didn't even
think about the apt cache not being up to date.

Thanks for your help - you rock!
-Mike

On Wed, 18 Sep 2019 13:09:25 +0200 Faustin Lammler  wrote:
> Control: tags -1 moreinfo
>
> Hi Michael!
> Thank you for your report.
>
> I am not able to reproduce the 404 you are talking about on a fresh
> Stretch installation, are you sure that your apt cache is up to date or
> that you are using default apt preferences?
>
> This is what I have just tested successfully:
> | docker run -t debian:stretch /bin/bash -c "apt update && apt
--assume-yes install default-libmysqlclient-dev"
>
> Regards,
> Faustin

Bug#940290: q2-types: triangular dependency with q2-types, q2cli

[Andreas Tille]

Uploaded after adding you to Uploaders since you obviously care for
this package.  Thanks for your work on this, Andreas.

On Wed, Sep 18, 2019 at 12:09:51PM +0200, Liubov Chuprikova wrote:
> Hi Andreas,
> 
> On Tue, 17 Sep 2019 at 14:39, Andreas Tille  wrote:
> 
> > Control: reassign -1 qiime
> >
> > Hi Liubov,
> >
> > On Tue, Sep 17, 2019 at 12:19:51PM +0200, Liubov Chuprikova wrote:
> > > > This is the case if neither q2-types or q2cli are totally broken if
> > > > qiime is not installed (do not import anything from qiime etc.)  If
> > this
> > > > assumption is wrong and both really need qiime to be installed than we
> > > > should consider
> > > >
> > > >qiime: Recommends: q2cli, q2-types
> > > >
> > >
> > > Yes, you are right, I have just moved q2 plugins into Recommends for
> > qiime.
> > > Is this OK that I made the required changes in qiime, but the bug will be
> > > closed for q2-types?
> >
> > It should be OK.  The clean approach would be to reassign the bug - as I
> > did above with this mail.
> >
> 
> Thank you! I put the bug closure line in qiime and did the required changes.
> 
> 
> > Just ping me if you are ready with the package (may be you intend more
> > changes or so).
> >
> 
> That's all for now, qiime is ready for upload!
> 
> Best regards,
> Liubov
> 
> 
> > Kind regards
> >
> >Andreas.
> >
> > --
> > http://fam-tille.de
> >

-- 
http://fam-tille.de

Bug#940648: Do not install bench dir

[Bastien ROUCARIES]

Package: pkg-js-tools
Version: 0.9.10
Severity: wishlist

Dear Maintainer,

Bench like test should not be installed

Bug#867557: CPU colours

[Joseph Walton]

This is fixed in
https://github.com/GNOME/gnome-system-monitor/commit/1b216e8c48bee7c5d7cf0476f0f2bc2bfc4e503f
, which adds default colours for sixteen CPUs.
-- 
 Joseph Walton --
 "Collapsing the waveform brought its own relief." --

Bug#940479: pocketsphinx: please add a -doc package

[Gianfranco Costamagna]

 Hello,

 
>Thinking about this, can't we just move the doc to libpocketsphinx-dev?
>(since the doc is about the library, not the programs)
>
>I understand that it'll be appreciated to have a pocketsphinx package
>that is reduced as much as possible, but I don't think it's such a
>concern for libpocketsphinx-dev? I'm just meaning to save developers
>from installing yet another package only to get the documentation, when
>it's just 8MiB away.

I think you are the best person to think about this, but I appreciate your 
answer and I agree!
The package is unfortunately already existing in Ubuntu, so I'll need to 
break/replaces the -doc package for some time, but nothing too worrying,because 
we already have a bad delta anyway...the package in Ubuntu has been uploaded as 
0.8.0, so we had to call the version 0.8.0+real5prealpha+1-5ubuntu2 to make it 
recognized as "higher"
Having a new upstream snapshot might help :)
but if you can move the documentation, and enable parallel builds, it will 
simplify the delta to mostly zero until the next ubuntu LTS and next upstream 
is out!
thanks again,
G.
  

Bug#940587: cloud.debian.org: additional Vagrant boxes with puppet/ansible pre-installed?

[Gabriel Filion]

Hi,

On 2019-09-18 1:36 a.m., Geert Stappers wrote:
> On Tue, Sep 17, 2019 at 10:52:54AM -0400, Gabriel Filion wrote:
>> I was wondering if folks maintaining the vagrant boxes would be willing to
>> publish additional images that would have puppet/ansible pre-installed with
>> the debian packages from each release's package repository?
> 
> I also don't understand how cloudinit works.
> 
> There is https://cloudinit.readthedocs.io/en/latest/
> But it lacks what it makes it tick.
> 
> Nowhere is documented
> * how it starts (what triggers the start)
> * how "client" finds "server"
> * why "client" trusts "server"

I don't quite understand how this question is related to building
Vagrant boxes.

According to the documentation[0] the boxes are generated using a Packer
template, and cloudinit is mentioned nowhere on that wiki page.

[0]: https://wiki.debian.org/Teams/Cloud/VagrantBaseBoxes#Build_process



signature.asc
Description: OpenPGP digital signature

Bug#940647: buster-pu: package libmysofa/0.6~dfsg0-3

[IOhannes m zmoelnig]

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

Dear release-team,

the binary package libmysofa0 is used by VLC (the ubiquitous media
player) and the ffmpeg framework (the ubiquitous media framework), and
consequently has a popcon of 43382.

The src:libmysofa package has been assigned a number of CVEs and a
cumulative Debian bug #939735.
The issues (NULL-pointer access, out-of-bound reads, invalid reads and
writes) have been promptly fixed by upstream, who have released a new
version (0.8).

I've uploaded the new version to 'sid' yesterday (setting urgency=high; I
hope this is correct).
For buster (which ships 0.6) I need your cooperation in order to get the
package uploaded.

Since there are a number of CVEs involved, I have first contacted the security
team, to coordinate an upload via buster-security. However, their response was:
> I have looked at those now from stable update point of view, and I
> think they are somehow limited impact (clearly with posibility to lead
> to crashes of reverse dependecies), but would not warrant a DSA on its
> own.
>
> I tend to mark those as no-dsa for buster and ask you if you can
> schedule an update just for the next buster point release.

I agree with their assassment of the impact of these CVEs, so here I am :-)

Please see the attached debdiff for my proposed changes.
These changes include fixes for the various CVEs and a (small but) cumulative
patch for 3 more security issues fixed upstream, which haven't got a CVE
assigned.

Let me know what I should do.

Cheers and thanks for making Debian a better place.

fgamsdr
IOhannes
diff -Nru libmysofa-0.6~dfsg0/debian/changelog 
libmysofa-0.6~dfsg0/debian/changelog
--- libmysofa-0.6~dfsg0/debian/changelog2019-04-01 23:25:15.0 
+0200
+++ libmysofa-0.6~dfsg0/debian/changelog2019-09-18 13:44:59.0 
+0200
@@ -1,3 +1,15 @@
+libmysofa (0.6~dfsg0-3+deb10u1) buster; urgency=high
+
+  * Backport security fixes (Closes: #939735)
+* CVE-2019-16091
+* CVE-2019-16092
+* CVE-2019-16093
+* CVE-2019-16094
+* CVE-2019-16095
+* misc security fixes that have no CVE assigned
+
+ -- IOhannes m zmölnig (Debian/GNU)   Wed, 18 Sep 2019 
13:44:59 +0200
+
 libmysofa (0.6~dfsg0-3) unstable; urgency=medium
 
   [ IOhannes m zmölnig ]
diff -Nru libmysofa-0.6~dfsg0/debian/gbp.conf 
libmysofa-0.6~dfsg0/debian/gbp.conf
--- libmysofa-0.6~dfsg0/debian/gbp.conf 1970-01-01 01:00:00.0 +0100
+++ libmysofa-0.6~dfsg0/debian/gbp.conf 2019-09-18 13:44:59.0 +0200
@@ -0,0 +1,4 @@
+[DEFAULT]
+pristine-tar = True
+#upstream-branch = upstream
+debian-branch = buster
diff -Nru libmysofa-0.6~dfsg0/debian/patches/CVE-2019-16091.patch 
libmysofa-0.6~dfsg0/debian/patches/CVE-2019-16091.patch
--- libmysofa-0.6~dfsg0/debian/patches/CVE-2019-16091.patch 1970-01-01 
01:00:00.0 +0100
+++ libmysofa-0.6~dfsg0/debian/patches/CVE-2019-16091.patch 2019-09-18 
13:44:59.0 +0200
@@ -0,0 +1,99 @@
+Description: Fix for CVE-2019-16091
+Author: IOhannes m zmölnig
+Origin: upstream
+Bug: https://github.com/hoene/libmysofa/issues/78
+Last-Update: 2019-09-17
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- libmysofa.orig/src/hdf/fractalhead.c
 libmysofa/src/hdf/fractalhead.c
+@@ -10,6 +10,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include "reader.h"
+ 
+ static int log2i(int a) {
+@@ -36,7 +37,7 @@
+   if (fread(buf, 1, 4, reader->fhd) != 4 || strncmp(buf, "FHDB", 4)) {
+   log("cannot read signature of fractal heap indirect block\n");
+   return MYSOFA_INVALID_FORMAT;
+-  } log("%08lX %.4s\n", (uint64_t )ftell(reader->fhd) - 4, buf);
++  } log("%08" PRIX64 " %.4s\n", (uint64_t )ftell(reader->fhd) - 4, buf);
+ 
+   if (fgetc(reader->fhd) != 0) {
+   log("object FHDB must have version 0\n");
+@@ -60,7 +61,7 @@
+   else
+   length_size = ceilf(log2f(fractalheap->maximum_size) / 8);
+ 
+-  log(" %d %ld %d\n",size,block_offset,offset_size);
++  log(" %d %" PRIu64 " %d\n",size,block_offset,offset_size);
+ 
+   /*
+* 3e00  00 46 48 44 42 00 40 02  00 00 00 00 00 00 00 00  
|.FHDB.@.|
+@@ -81,10 +82,10 @@
+   typeandversion = (uint8_t)fgetc(reader->fhd);
+   offset = readValue(reader, offset_size);
+   length = readValue(reader, length_size);
+-  if(offset>0x1000 || length>0x1000)
++  if(offset>0x1000 || length>0x1000 || length == 0)
+   return MYSOFA_UNSUPPORTED_FORMAT;
+ 
+-  log(" %d %4lX %ld 
%8lX\n",typeandversion,offset,length,ftell(reader->fhd));
++  log(" %d %4" PRIX64 " %" PRIu64 " %8" PRIX64 
"\n",typeandversion,offset,length,ftell(reader->fhd));
+ 
+   /* TODO: for the following part, the specification is 
incomplete */
+   if 

Bug#940269: [Pkg-giraffe-maintainers] Bug#940269: kopano-webapp-files: Does not appear in plugins list

[Roel van Meer]

after installation and restart of both the Kopano server and
Apache, the plugin is still not listed (the only plugin
appearing is “WebApp Manual”).


Thank you for reporting this problem.

It seems it is necessary to have one of the filesbackend plugins
installed for the files plugin to show up. Unfortunately, neither
the filesbackend-owncloud nor the filesbackend-smb plugin are
currently available in Buster.

Best regards, Roel

Bug#939225: [Pkg-sssd-devel] Bug#939225: sssd fails on dual stack / ipv6 only hosts

[Timo Aaltonen]

On 2.9.2019 14.28, Robert Senger wrote:
> Package: sssd
> Version: 1.16.3-3.1
> Severity: important
> Tags: ipv6
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
> Laptop with sssd and sssd-krb5 installed. Two wifi networks, one dual stack
> ipv4/ipv6, other ipv6 only (with dns64/nat64).
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Laptop connects to dual stack netwotk. Kerberos authentication works, kdc is
> reached via ipv4 (seen with tcpdump on the server). Laptop then switches to
> ipv6 only network. Kerberos authentication fails, kinit reports kdc cannot be
> contacted.
> 
>* What was the outcome of this action?
> 
> Kerberos authentication fails if ipv4 is initially available, and becomes
> unavailable after switching networks.
> 
>* What outcome did you expect instead?
> 
> sssd should always try both address families, regardless of previous
> availability. sssd should prefer ipv6 by default.

This is probably same as https://pagure.io/SSSD/sssd/issue/3973 ?

fixed in 1.16.4/2.x


-- 
t

Bug#811180: etckeeper: Please port it to python 3

[Jelmer Vernooij]

On Thu, 2019-08-29 at 23:58 -0400, Daniel Kahn Gillmor wrote:
> On Mon 2016-01-25 18:20:11 +, Jelmer Vernooij wrote:
> 
> > The bzr bits have to be python2 because bzr is python 2 only at the
> > moment.
> > 
> > Bzr is optional though.
> 
> fwiw, i'd much rather see etckeeper shipping with python3 with bzr
> disabled at this point.  or maybe whatever folks need it to work with
> bzr can fix that part?

I'll have a look at porting the bzr part to breezy (which supports
Bazaar repositories and is Python3 compatible).

Jelmer

Bug#805711: Me too, and some additional info.

[Matthew Wakeling]

I confirm this bug exists on my laptop, which is an ASUS UX305C. I just 
upgraded to Buster, and the bug appears. To be specific:


If I lock the screen (by pressing Ctrl-Alt-Del, selecting "Lock Screen", 
closing the laptop lid, or letting the screensaver time out), then the 
screen goes black, as expected. If I then move the mouse or hit keys on 
the keyboard, the screen does not stop being black. However, if I then 
type Ctrl-Alt-F1, I get a working console login. If I then type 
Ctrl-Alt-F7, I get a message about the screen being locked, and if I type 
Ctrl-Alt-F8, I get the unlock screen. If I then leave the laptop for a 
while on the unlock screen, the screen will go black again, with the same 
consequences - moving the mouse or hitting keys on the keyboard does not 
bring the screen up again.


I would very much appreciate any progress being made on this bug, despite 
there being a workaround.


Matthew

Bug#940582: [debian-mysql] Bug#940582: Update Severity of issue - Production Builds Can't Deploy

[Faustin Lammler]

Control: tags -1 moreinfo

Hi Michael!
Thank you for your report.

I am not able to reproduce the 404 you are talking about on a fresh
Stretch installation, are you sure that your apt cache is up to date or
that you are using default apt preferences?

This is what I have just tested successfully:
| docker run -t debian:stretch /bin/bash -c "apt update && apt --assume-yes 
install default-libmysqlclient-dev"

Regards,
Faustin


signature.asc
Description: PGP signature

Bug#504333: logrotate ignores files with date 1904-1-1 in /var/lib/logrotate/status

[Christian Göttsche]

Please share your current setup:
Debian version: (old-stable | stable | testing | unstable)
Logrotate version: (logrotate --version)
Please share your cronjob config '/etc/cron.daily/logrotate'
Are you using systemd?
If yes, please share 'systemctl status logrotate.timer' and
'journalctl -u logrotate' (the most recent part of it).


> It seems really broken, worse than expected. First, I did not get
> any error via cron, and the error logs did not change:
>
> -rw-r- 1 root adm 306 1904-01-01 00:00:00 error.log
> -rw-r- 1 root adm 440 1904-01-01 00:00:00 error.log.1
> -rw-r- 1 root adm 271 2019-09-16 00:00:02 error.log.2.gz
> -rw-r- 1 root adm 269 2019-09-15 00:00:02 error.log.3.gz
> -rw-r- 1 root adm 271 2019-09-14 00:00:02 error.log.4.gz
> -rw-r- 1 root adm 271 2019-09-13 00:00:01 error.log.5.gz
> [...]

That the logs do not change is expected, as gzip failed;
if you using systemd you should see some error messages in the journal.

> Worse, this seemed to have interrupted the rotation of the
> access logs (or is this a different bug?):
>
> -rw-r- 1 root adm 308 2019-09-17 16:39:00 access.log
> -rw-r- 1 root adm 156 2019-09-16 16:31:06 access.log.2.gz
> -rw-r- 1 root adm 157 2019-09-13 12:36:03 access.log.3.gz
> -rw-r- 1 root adm 155 2019-09-12 12:25:14 access.log.4.gz
> -rw-r- 1 root adm 156 2019-09-10 10:33:38 access.log.5.gz
> [...]

This is indeed unexpected, in my tests logrotate continues to rotate
other logs. (see https://paste.debian.net/1101399/)


p.s.:
To avoid these timestamps you can use the configuration option 'prerotate'.
Otherwise it's on gzip.

Bug#921537: gnome-terminal: mouse wheel scrolling sends 6 key up / key down escape sequences (kcuu1 / kcud1) in alternate screen

[Vincent Lefevre]

On 2019-09-18 11:37:10 +0200, Egmont Koblinger wrote:
> I don't intent do revive that discussion where we disagreed. We
> probably still disagree on those things the exact same way, and still
> nothing changed on VTE's side.

What I'm just asking is that this should be configurable.

Currently, gnome-terminal is unusable for me.

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

Bug#940191: texlive-binaries: xdvi does not display enclosed eps graphics due to ghostscript dropped execute command (patch)

[Norbert Preining]

Hi Chris,

thanks for your quick response.

On Wed, 18 Sep 2019, Chris Liddell wrote:
> That seems absolutely ideal to me. In fact, I would say it is probably
> how it should have been done originally.

Good to hear!

> custom/internal operators. I'm sorry if that's what happened, and sorry
> for the upheaval, regardless.

Don't worry, even if there are more of them popping up in the future ;-)

> that is less vulnerable to malicious attacks.

Agreed, 100%.

Thanks a lot

Norbert

--
PREINING Norbert   http://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#934269: lavacli: default_flow_style changed in newer pyyaml

[Remi Duraffort]

On Thu, 08 Aug 2019 17:44:40 -0400 Mathieu Trudel-Lapierre <
cypher...@ubuntu.com> wrote:
> Package: lavacli
> Version: 0.9.7-1
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu eoan ubuntu-patch
>
> Dear Maintainer,
>
> pyyaml 5.2.1 appears to have some changes in the default flow style used.
> Rather than representing sequences and dicts similary to python, it now
> defaults to printing them in longform [1]:
>
>  - item 1
>  - item 2
>
> etc.
>
> I've written a quick and heavyhanded patch to add default_flow_style=None
> to all of the calls to yaml.dump() that otherwise don't include options,
but
> that might not be the best solution. Maybe upstream would rather fix the
tests?
>
> [1] https://github.com/yaml/pyyaml/issues/265
>
>
> *** /tmp/tmpton7Uz/bug_body
>
> In Ubuntu, the attached patch was applied to achieve the following:
>
>   * debian/patches/fix_pyyaml_default_flow_style.patch: Make sure all
calls
> to yaml.dump() include default_flow_style=None, to retain previous
behavior
> that is checked for in tests, unless it's already otherwise specified.
>
>
> Thanks for considering the patch.

The patch has been integrated upstream with
https://git.lavasoftware.org/lava/lavacli/commit/1d374ccba0dc291e8d745ec90ffa8b4a32fb11af

Thanks for your patch.


Rgds

-- 
Rémi Duraffort

Bug#940290: q2-types: triangular dependency with q2-types, q2cli

[Liubov Chuprikova]

Hi Andreas,

On Tue, 17 Sep 2019 at 14:39, Andreas Tille  wrote:

> Control: reassign -1 qiime
>
> Hi Liubov,
>
> On Tue, Sep 17, 2019 at 12:19:51PM +0200, Liubov Chuprikova wrote:
> > > This is the case if neither q2-types or q2cli are totally broken if
> > > qiime is not installed (do not import anything from qiime etc.)  If
> this
> > > assumption is wrong and both really need qiime to be installed than we
> > > should consider
> > >
> > >qiime: Recommends: q2cli, q2-types
> > >
> >
> > Yes, you are right, I have just moved q2 plugins into Recommends for
> qiime.
> > Is this OK that I made the required changes in qiime, but the bug will be
> > closed for q2-types?
>
> It should be OK.  The clean approach would be to reassign the bug - as I
> did above with this mail.
>

Thank you! I put the bug closure line in qiime and did the required changes.


> Just ping me if you are ready with the package (may be you intend more
> changes or so).
>

That's all for now, qiime is ready for upload!

Best regards,
Liubov


> Kind regards
>
>Andreas.
>
> --
> http://fam-tille.de
>