Bug#951135: zeromq3: zmq_addons.hpp missing from installed headers

[Gordon Ball]

On Fri, Feb 21, 2020 at 06:49:06AM +, Gordon Ball wrote:
> On Thu, Feb 20, 2020 at 09:31:16PM +0100, László Böszörményi (GCS) wrote:
> > On Thu, Feb 20, 2020 at 9:06 PM Luca Boccassi  wrote:
> > > On Thu, 2020-02-20 at 20:57 +0100, László Böszörményi wrote:
> > > > Luca, what's your opinion on this? I think that needs to be packaged
> > > > separately.
> > >
> > > It's a bit weird, but given it's just a header, IMHO it's fine to keep
> > > shipping it in libzmq3-dev. Upstream we generally try our best to keep
> > > the hpp header forward and backward compatible, so there should be no
> > > surprises.
> > > I do the same in the packages I build upstream in OBS.
> >  OK. I don't see the point then being developed in a separate git tree
> > - but let it be. I'm going to sync it with zeromq3 packaging.
> 
> Thanks for responding to this quickly.
> 
> I don't have a strong opinion on whether the headers from the cppzmq
> respository should be bundled in libzmq3-dev or split out into a
> separate package (although if they're largely released in sync, having a
> separate package for two header files seems unnecessary).
> 
> However, the original request in #951135 was for `zmq_addon.hpp` from
> `cppzmq`, which has not been included in 4.3.2-2. Was this intentional?

Sorry, ignore me - I didn't see mention of `zmq_addon.hpp` in the
changelog and then failed to notice that the file list on sources.d.o
was out-of-date and still showing 4.3.2-1.

> 
> (To be clear, this isn't at all urgent - I'm just experimenting with
> xeus at the moment. I encountered this issue because I assumed cppzmq
> was unpackaged and made a local stub package to install it, only to find
> it conflicted with libzmq3-dev. Assuming that the package will continue
> to ship the C++ headers, adding the string `cppzmq` to the description
> or `Provides: cppzmq-dev` might aid discoverability).
> 
> Gordon
> > 
> > Regards,
> > Laszlo/GCS

Bug#951135: zeromq3: zmq_addons.hpp missing from installed headers

[Gordon Ball]

On Thu, Feb 20, 2020 at 09:31:16PM +0100, László Böszörményi (GCS) wrote:
> On Thu, Feb 20, 2020 at 9:06 PM Luca Boccassi  wrote:
> > On Thu, 2020-02-20 at 20:57 +0100, László Böszörményi wrote:
> > > Luca, what's your opinion on this? I think that needs to be packaged
> > > separately.
> >
> > It's a bit weird, but given it's just a header, IMHO it's fine to keep
> > shipping it in libzmq3-dev. Upstream we generally try our best to keep
> > the hpp header forward and backward compatible, so there should be no
> > surprises.
> > I do the same in the packages I build upstream in OBS.
>  OK. I don't see the point then being developed in a separate git tree
> - but let it be. I'm going to sync it with zeromq3 packaging.

Thanks for responding to this quickly.

I don't have a strong opinion on whether the headers from the cppzmq
respository should be bundled in libzmq3-dev or split out into a
separate package (although if they're largely released in sync, having a
separate package for two header files seems unnecessary).

However, the original request in #951135 was for `zmq_addon.hpp` from
`cppzmq`, which has not been included in 4.3.2-2. Was this intentional?

(To be clear, this isn't at all urgent - I'm just experimenting with
xeus at the moment. I encountered this issue because I assumed cppzmq
was unpackaged and made a local stub package to install it, only to find
it conflicted with libzmq3-dev. Assuming that the package will continue
to ship the C++ headers, adding the string `cppzmq` to the description
or `Provides: cppzmq-dev` might aid discoverability).

Gordon
> 
> Regards,
> Laszlo/GCS

Bug#950716: transition: ruby2.7

[Graham Inggs]

On Fri, 21 Feb 2020 at 00:15, Lucas Kanashiro  wrote:
> I'd like to request some rebuilds:

Thanks for the info, ruby-god, libsemanage and unicorn given back now.

Bug#951697: GDM crashing after last upgrade

[Andrei POPESCU]

Control: reassign -1 gdm3 3.30.2-3

On Jo, 20 feb 20, 10:54:59, korczy...@gmail.com wrote:
> Package: gdm (but not sure)
> Version: Package: 3.30.2-3
> 
> After last update GDM crashing after provided credentials to login in. 
> It displays grey background and I can't switch to other terminal with
> ctrl+alt+function key. It only reacts to hardware power button - shut
> down normally. 
> Going to other terminal before providing password in gdm and issuing
> startx works and my gnome session is loaded. 
> 
> 
> 
> 
> Feb 20 10:30:53 dionizos gsettings[1872]: unable to open file
> '/var/lib/gdm3/greeter-dconf-defaults': /var/lib/gdm3/greeter-dconf-
> defaults: invalid gvdb header; expect degraded performance
> Feb 20 10:30:53 dionizos gnome-session-b[1871]: unable to open file
> '/var/lib/gdm3/greeter-dconf-defaults': /var/lib/gdm3/greeter-dconf-
> defaults: invalid gvdb header; expect degraded performa
> nce
> Feb 20 10:30:53 dionizos gnome-shell[1879]: unable to open file
> '/var/lib/gdm3/greeter-dconf-defaults': /var/lib/gdm3/greeter-dconf-
> defaults: invalid gvdb header; expect degraded performance
> Feb 20 10:30:53 dionizos org.gnome.Shell.desktop[1879]: can't load
> /usr/lib/x86_64-linux-gnu/spa/support/libspa-support.so:
> /usr/lib/x86_64-linux-gnu/spa/support/libspa-support.so: nie można 
> otworzyć pliku obiektu dzielonego: Nie ma takiego pliku ani katalogu
> Feb 20 10:31:17 dionizos kernel: [   83.698475] bbswitch: enabling
> discrete graphics
> Feb 20 10:31:17 dionizos org.gnome.Shell.desktop[1879]: could not
> connect to wayland server
> Feb 20 10:31:17 dionizos org.gnome.Shell.desktop[1879]: (EE)
> Feb 20 10:31:17 dionizos org.gnome.Shell.desktop[1879]: Fatal server
> error:
> Feb 20 10:31:17 dionizos org.gnome.Shell.desktop[1879]: (EE) Couldn't
> add screen
> Feb 20 10:31:17 dionizos org.gnome.Shell.desktop[1879]: (EE)
> 
> 
> What was updated:
> Start-Date: 2020-02-20  10:14:11
> Commandline: apt upgrade
> Install: linux-headers-4.19.0-8-common:amd64 (4.19.98-1, automatic),
> linux-headers-4.19.0-8-amd64:amd64 (4.19.98-1, automatic), linux-image-
> 4.19.0-8-amd64:amd64 (4.19.98-1, automatic)
> Upgrade: libpython3.7-minimal:amd64 (3.7.3-2, 3.7.3-2+deb10u1),
> evince:amd64 (3.30.2-3, 3.30.2-3+deb10u1), libperl4-corelibs-perl:amd64 
> (0.004-1, 0.004-1+deb10u1), libopenjp2-7:amd64 (2.3.0-2, 2.3.0-
> 2+deb10u1), libopenjp2-7:i386 (2.3.0-2, 2.3.0-2+deb10u1), libcom-
> err2:amd64 (1.44.5-1+deb10u2, 1.44.5-1+deb10u3), libcom-err2:i386
> (1.44.5-1+deb10u2, 1.44.5-1+deb10u3), libcups2:amd64 (2.2.10-6+deb10u1, 
> 2.2.10-6+deb10u2), libcups2:i386 (2.2.10-6+deb10u1, 2.2.10-6+deb10u2),
> linux-libc-dev:amd64 (4.19.67-2+deb10u2, 4.19.98-1), libevdocument3-
> 4:amd64 (3.30.2-3, 3.30.2-3+deb10u1), libvncclient1:amd64 (0.9.11+dfsg-
> 1.3, 0.9.11+dfsg-1.3+deb10u2), libegl-mesa0:amd64 (18.3.6-2, 18.3.6-
> 2+deb10u1), signal-desktop:amd64 (1.30.1, 1.31.0), libsystemd0:amd64
> (241-7~deb10u2, 241-7~deb10u3), libsystemd0:i386 (241-7~deb10u2, 241-
> 7~deb10u3), libglapi-mesa:amd64 (18.3.6-2, 18.3.6-2+deb10u1), libglapi-
> mesa:i386 (18.3.6-2, 18.3.6-2+deb10u1), mariadb-common:amd64
> (1:10.3.18-0+deb10u1, 1:10.3.22-0+deb10u1), e2fsprogs:amd64 (1.44.5-
> 1+deb10u2, 1.44.5-1+deb10u3), sudo:amd64 (1.8.27-1+deb10u1, 1.8.27-
> 1+deb10u2), google-chrome-stable:amd64 (79.0.3945.130-1, 80.0.3987.116-
> 1), libpython3.7:amd64 (3.7.3-2, 3.7.3-2+deb10u1), python3.7:amd64
> (3.7.3-2, 3.7.3-2+deb10u1), gir1.2-evince-3.0:amd64 (3.30.2-3, 3.30.2-
> 3+deb10u1), libxatracker2:amd64 (18.3.6-2, 18.3.6-2+deb10u1),
> libwinpr2-2:amd64 (2.0.0~git20190204.1.2693389a+dfsg1-1,
> 2.0.0~git20190204.1.2693389a+dfsg1-1+deb10u1), udev:amd64 (241-
> 7~deb10u2, 241-7~deb10u3), linux-compiler-gcc-8-x86:amd64 (4.19.67-
> 2+deb10u2, 4.19.98-1), python3.7-dev:amd64 (3.7.3-2, 3.7.3-2+deb10u1),
> cups-server-common:amd64 (2.2.10-6+deb10u1, 2.2.10-6+deb10u2), cups-
> common:amd64 (2.2.10-6+deb10u1, 2.2.10-6+deb10u2), libcpupower1:amd64
> (4.19.67-2+deb10u2, 4.19.98-1), libpython3.7-stdlib:amd64 (3.7.3-2,
> 3.7.3-2+deb10u1), libudev1:amd64 (241-7~deb10u2, 241-7~deb10u3),
> libudev1:i386 (241-7~deb10u2, 241-7~deb10u3), python3.7-minimal:amd64
> (3.7.3-2, 3.7.3-2+deb10u1), libgbm1:amd64 (18.3.6-2, 18.3.6-2+deb10u1), 
> libss2:amd64 (1.44.5-1+deb10u2, 1.44.5-1+deb10u3), libext2fs2:amd64
> (1.44.5-1+deb10u2, 1.44.5-1+deb10u3), libexif12:amd64 (0.6.21-5.1,
> 0.6.21-5.1+deb10u1), libexif12:i386 (0.6.21-5.1, 0.6.21-5.1+deb10u1),
> evince-common:amd64 (3.30.2-3, 3.30.2-3+deb10u1), libfreerdp2-2:amd64
> (2.0.0~git20190204.1.2693389a+dfsg1-1,
> 2.0.0~git20190204.1.2693389a+dfsg1-1+deb10u1), cups-ppdc:amd64 (2.2.10-
> 6+deb10u1, 2.2.10-6+deb10u2), libboost-iostreams1.67.0:amd64 (1.67.0-
> 13, 1.67.0-13+deb10u1), libevview3-3:amd64 (3.30.2-3, 3.30.2-
> 3+deb10u1), libimobiledevice6:amd64 (1.2.1~git20181030.92c5462-1,
> 1.2.1~git20181030.92c5462-2), libboost-chrono1.67.0:amd64 (1.67.0-13,
> 1.67.0-13+deb10u1), libnss-myhostname:amd64 (241-7~deb10u2, 241-
> 

Bug#951752: gcc-python-plugin FTBFS with python3.8

[Steve Langasek]

Package: gcc-python-plugin
Version: 0.17-5
Severity: serious
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hi Matthias,

gcc-python-plugin ftbfs with python3.8.  Attached is the patch I've uploaded
to Ubuntu for this build failure.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru gcc-python-plugin-0.17/debian/patches/python3.8-compat.patch 
gcc-python-plugin-0.17/debian/patches/python3.8-compat.patch
--- gcc-python-plugin-0.17/debian/patches/python3.8-compat.patch
1969-12-31 16:00:00.0 -0800
+++ gcc-python-plugin-0.17/debian/patches/python3.8-compat.patch
2020-02-20 21:44:49.0 -0800
@@ -0,0 +1,40 @@
+Description: fix compatibility with Python 3.8
+ Python 3.8 changes the type of an element of the PyTypeObject struct
+ (https://www.python.org/dev/peps/pep-0590/) leading to compiler errors.
+Author: Steve Langasek 
+Last-Update: 2020-02-20
+Forwarded: no
+
+Index: gcc-python-plugin-0.17/gcc-python-wrapper.c
+===
+--- gcc-python-plugin-0.17.orig/gcc-python-wrapper.c
 gcc-python-plugin-0.17/gcc-python-wrapper.c
+@@ -137,7 +137,11 @@
+ sizeof(PyGccWrapperTypeObject), /*tp_basicsize*/
+ 0, /*tp_itemsize*/
+ NULL, /* tp_dealloc */
++#if PY_VERSION_HEX >= 0x0308
++0, /* tp_vectorcall_offset */
++#else
+ NULL, /* tp_print */
++#endif
+ NULL, /* tp_getattr */
+ NULL, /* tp_setattr */
+ #if PY_MAJOR_VERSION < 3
+Index: gcc-python-plugin-0.17/cpybuilder.py
+===
+--- gcc-python-plugin-0.17.orig/cpybuilder.py
 gcc-python-plugin-0.17/cpybuilder.py
+@@ -254,7 +254,11 @@
+ result += 'sizeof(%(struct_name)s), /*tp_basicsize*/\n' % 
self.__dict__
+ result += '0, /*tp_itemsize*/\n'
+ result += self.c_ptr_field('tp_dealloc')
+-result += self.c_ptr_field('tp_print')
++result += '#if PY_VERSION_HEX >= 0x0308\n' % self.__dict__
++result += '0, /*tp_vectorcall_offset*/\n' % self.__dict__
++result += '#else\n' % self.__dict__
++result += 'NULL, /*tp_print*/\n' % self.__dict__
++result += '#endif\n' % self.__dict__
+ result += self.c_ptr_field('tp_getattr')
+ result += self.c_ptr_field('tp_setattr')
+ result += '#if PY_MAJOR_VERSION < 3\n' % self.__dict__
diff -Nru gcc-python-plugin-0.17/debian/patches/series 
gcc-python-plugin-0.17/debian/patches/series
--- gcc-python-plugin-0.17/debian/patches/series2020-02-20 
05:15:45.0 -0800
+++ gcc-python-plugin-0.17/debian/patches/series2020-02-20 
21:43:59.0 -0800
@@ -4,3 +4,4 @@
 gcc-8-fix.diff
 werror.diff
 gcc-10.diff
+python3.8-compat.patch

Bug#951751: audtty FTCBFS: improperly uses autotools

[Helmut Grohne]

Source: audtty
Version: 0.1.12-5
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

audtty fails to cross build from source, because it uses the build
architecture compiler and pkg-config. That's unusual for an autotools
project and indeed configure detects the correct compiler. It happens
that Makefile.in fails to pick up the detected compiler. Makefile.in
also tries to detect glib with a hard coded pkg-config. It is much
better to let configure do that detection and have it fail early in case
glib is missing. Please consider applying the attached patch.

Helmut
--- audtty-0.1.12.orig/Makefile.in
+++ audtty-0.1.12/Makefile.in
@@ -7,9 +7,11 @@
 sysconfdir=${DESTDIR}/@sysconfdir@
 
 
+CC=@CC@
 AUDACIOUS_CFLAGS=@AUDACIOUS_CFLAGS@ -I/usr/include/dbus-1.0
-GLIB_CFLAGS=`pkg-config --cflags glib-2.0`
-LDADD=-ldbus-glib-1 -lncursesw -laudclient -lgobject-2.0 `pkg-config --libs glib-2.0 `
+GLIB_CFLAGS=@GLIB_CFLAGS@
+GLIB_LIBS=@GLIB_LIBS@
+LDADD=-ldbus-glib-1 -lncursesw -laudclient -lgobject-2.0 $(GLIB_LIBS)
 
 SOURCES=main.c curses_printf.c playlist.c playlist_jump.c playlist_addurl.c settings.c connect.c browse.c playlist_create.c
 BINS=$(SOURCES:.c=.o)
@@ -19,10 +21,10 @@
 all: audtty
 
 audtty: ${BINS}
-	cc -g -O2 -g2 -Wall -Werror ${LDFLAGS} -o audtty $(BINS) $(LDADD)
+	$(CC) -g -O2 -g2 -Wall -Werror ${LDFLAGS} -o audtty $(BINS) $(LDADD)
 
 .c.o:
-	cc -g -Wall ${AUDACIOUS_CFLAGS} ${GLIB_CFLAGS} ${CFLAGS} -o $@ -c $<
+	$(CC) -g -Wall ${AUDACIOUS_CFLAGS} ${GLIB_CFLAGS} ${CFLAGS} -o $@ -c $<
 
 install: audtty
 	mkdir -p ${bindir}
--- audtty-0.1.12.orig/configure.ac
+++ audtty-0.1.12/configure.ac
@@ -22,6 +22,8 @@
 	[],
 	[AC_MSG_ERROR([Can't find Audacious development files.])])
 
+PKG_CHECK_MODULES([GLIB],[glib-2.0])
+
 # Checks for header files.
 AC_HEADER_STDC
 AC_CHECK_HEADERS([stdlib.h])

Bug#951745: Please don't ship (empty) upstart config file

[Ondřej Surý]

Well, the last update should have removed the file. I must have made some 
mistake in the mainscript then.

Ondrej 
--
Ondřej Surý 

> On 21 Feb 2020, at 00:12, Michael Biebl  wrote:
> 
> Package: php7.3-fpm
> Version: 7.3.15-1
> Severity: important
> File: /etc/init/php7.3-fpm.conf
> 
> upstart is dead.
> Shipping an (empty) upstart config file is not really benefitting
> anyone.
> Please consider dropping /etc/init/php7.3-fpm.conf 
> 
> Thanks,
> Michael
> 

Bug#951707: gringo ftbfs with Python 3.8

[Steve Langasek]

Package: gringo
Followup-For: Bug #951707
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Please find attached a patch for this issue, which has been uploaded to
Ubuntu.

This debdiff also includes fixes to the packaging to cause it to use the
default python3 at build-time, instead of a hard-coded python3.7, since
python3.7 will shortly disappear from unstable.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru gringo-5.3.0/debian/control gringo-5.3.0/debian/control
--- gringo-5.3.0/debian/control 2019-03-01 23:11:37.0 -0800
+++ gringo-5.3.0/debian/control 2020-02-20 21:43:17.0 -0800
@@ -11,9 +11,9 @@
  re2c,
  bison,
  liblua5.3-dev,
- python3.7,
- libpython3.7-dev,
- python3.7-distutils
+ python3,
+ libpython3-dev,
+ python3-distutils
 Standards-Version: 4.3.0
 Vcs-Git: https://salsa.debian.org/science-team/gringo.git
 Vcs-Browser: https://salsa.debian.org/science-team/gringo
diff -Nru gringo-5.3.0/debian/patches/python3.8-compat.patch 
gringo-5.3.0/debian/patches/python3.8-compat.patch
--- gringo-5.3.0/debian/patches/python3.8-compat.patch  1969-12-31 
16:00:00.0 -0800
+++ gringo-5.3.0/debian/patches/python3.8-compat.patch  2020-02-20 
21:43:07.0 -0800
@@ -0,0 +1,23 @@
+Description: fix compatibility with Python 3.8
+ Python 3.8 changes the type of an element of the PyTypeObject struct
+ (https://www.python.org/dev/peps/pep-0590/) leading to compiler errors.
+Author: Steve Langasek 
+Last-Update: 2020-02-20
+Forwarded: no
+
+Index: gringo-5.3.0/libpyclingo/pyclingo.cc
+===
+--- gringo-5.3.0.orig/libpyclingo/pyclingo.cc
 gringo-5.3.0/libpyclingo/pyclingo.cc
+@@ -1128,7 +1128,11 @@
+ sizeof(T),  // tp_basicsize
+ 0,  // tp_itemsize
+ PythonDetail::Get_tp_dealloc::value, // tp_dealloc
++#if PY_VERSION_HEX >= 0x0308
++0,  // tp_vectorcall_offset
++#else
+ nullptr,// tp_print
++#endif
+ nullptr,// tp_getattr
+ nullptr,// tp_setattr
+ nullptr,// tp_compare
diff -Nru gringo-5.3.0/debian/patches/series gringo-5.3.0/debian/patches/series
--- gringo-5.3.0/debian/patches/series  2018-11-18 21:48:21.0 -0800
+++ gringo-5.3.0/debian/patches/series  2020-02-20 21:40:23.0 -0800
@@ -1,3 +1,4 @@
 gringo-manpages.patch
 gringo-python3-utf8.patch
 gringo-python37-async.patch
+python3.8-compat.patch
diff -Nru gringo-5.3.0/debian/rules gringo-5.3.0/debian/rules
--- gringo-5.3.0/debian/rules   2018-11-04 00:23:40.0 -0700
+++ gringo-5.3.0/debian/rules   2020-02-20 20:26:14.0 -0800
@@ -13,7 +13,7 @@
 
 # use custom hardening config flags for compiling clasp
 CONFIG=hardening
-CONFIGPARMS = -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr -LAH 
-DCMAKE_SKIP_RPATH=YES -DCLINGO_MANAGE_RPATH=OFF -DLIB_POTASSCO_BUILD_APP=ON 
-DLIB_POTASSCO_BUILD_TESTS=ON -DCLASP_BUILD_APP=OFF -DCLASP_BUILD_TESTS=OFF 
-DCLASP_BUILD_EXAMPLES=OFF -DCLINGO_BUILD_EXAMPLES=ON -DCLINGO_BUILD_TESTS=ON 
-DPYTHON_EXECUTABLE:FILEPATH=/usr/bin/python3.7
+CONFIGPARMS = -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr -LAH 
-DCMAKE_SKIP_RPATH=YES -DCLINGO_MANAGE_RPATH=OFF -DLIB_POTASSCO_BUILD_APP=ON 
-DLIB_POTASSCO_BUILD_TESTS=ON -DCLASP_BUILD_APP=OFF -DCLASP_BUILD_TESTS=OFF 
-DCLASP_BUILD_EXAMPLES=OFF -DCLINGO_BUILD_EXAMPLES=ON -DCLINGO_BUILD_TESTS=ON 
-DPYTHON_EXECUTABLE:FILEPATH=/usr/bin/python3
 TOPBUILDDIR = build/$(CONFIG)_mt
 ROOTDIR = $(shell pwd)
 

Bug#951750: ksyntax-highlighting FTCBFS: misses a native qt intsllation

[Helmut Grohne]

Source: ksyntax-highlighting
Version: 5.62.0-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ksyntax-highlighting fails to cross build from source, because it fails
to build the indexer component. The indexer is meant to be run during
build and thus needs to either be prebuilt or built using a native qt,
neither of which is provided. Since the Debian package does not install
the indexer into any binary package that could be added to
Build-Depends, the preferred solution likely is to build depend on a
native qmake and pass the prefix to the build. After doing so,
ksyntax-highlighting cross builds successfully. The cross build support
is great on the uptream side. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru ksyntax-highlighting-5.62.0/debian/changelog 
ksyntax-highlighting-5.62.0/debian/changelog
--- ksyntax-highlighting-5.62.0/debian/changelog2020-02-19 
19:38:17.0 +0100
+++ ksyntax-highlighting-5.62.0/debian/changelog2020-02-21 
05:58:26.0 +0100
@@ -1,3 +1,10 @@
+ksyntax-highlighting (5.62.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass a native qt to the build. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 21 Feb 2020 05:58:26 +0100
+
 ksyntax-highlighting (5.62.0-3) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru ksyntax-highlighting-5.62.0/debian/control 
ksyntax-highlighting-5.62.0/debian/control
--- ksyntax-highlighting-5.62.0/debian/control  2020-02-19 08:44:34.0 
+0100
+++ ksyntax-highlighting-5.62.0/debian/control  2020-02-21 05:58:26.0 
+0100
@@ -12,7 +12,9 @@
libqt5xmlpatterns5-dev (>= 5.11.0~),
pkg-kde-tools (>= 0.15.15ubuntu1~),
qtbase5-dev (>= 5.11.0~),
+   qtbase5-dev:native,
qttools5-dev (>= 5.4),
+   qttools5-dev:native,
 Standards-Version: 4.5.0
 Homepage: https://projects.kde.org/projects/frameworks/syntax-highlighting
 Vcs-Browser: https://salsa.debian.org/qt-kde-team/kde/syntax-highlighting
diff --minimal -Nru ksyntax-highlighting-5.62.0/debian/rules 
ksyntax-highlighting-5.62.0/debian/rules
--- ksyntax-highlighting-5.62.0/debian/rules2020-02-19 08:44:34.0 
+0100
+++ ksyntax-highlighting-5.62.0/debian/rules2020-02-21 05:57:26.0 
+0100
@@ -7,4 +7,4 @@
dh $@ --with kf5,pkgkde_symbolshelper --buildsystem kf5 --without 
build_stamp
 
 override_dh_auto_configure:
-   dh_auto_configure -- -DBUILD_QCH=ON
+   dh_auto_configure -- -DBUILD_QCH=ON -DKF5_HOST_TOOLING=/usr/lib

Bug#951749: System installation hangs on decompressing tzdata

[Rahul Martim Juliato]

Package: tzdata


System install hangs on trying to uncompress tzdata.


I tried with the mini image, DVD and DVD without network (hoping it would
force not to download anything and using what is on DVD)


But in all tries the installation hangs (both on graphical and text)
just after tzdata is being uncompressed.


After a red screen said it tried 5 times and cannot continue, I went to
sheel and was able to read something like this on the log:


debootstrap: dpkg: error while cleaning up
debootstrap: unable to trstore backup version of
'/usr/share/zoneinfo/right/Australi...' and many other lines similary to
this.


Version I was unable to install is 10.3.0-amd64-DVD1.iso

I was using a VirtualBox VM.

Thanks.

- End forwarded message -

Bug#951696: certbot: Incompatibility with python3-urllib3=1.25.8-1

[Harlan Lieberman-Berg]

Hello Alexandre,

Can you please tell me exactly what command you're running when
certbot gives you that stacktrace?  Can you also let me know what
version of python3-requests you have? That looks like a
requests/urllib3 incompatibility, but I can't reproduce it by hand or
inside certbot.

Sincerely,

On Thu, Feb 20, 2020 at 4:27 AM abeelen  wrote:
>
> Package: certbot
> Version: 1.1.0-1
> Severity: important
>
> Dear Maintainer,
>
> When run with python3-urllib3=1.25-8-1, certbot fails to run with a traceback 
> :
>
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/requests/models.py", line 379, in 
> prepare_url
> scheme, auth, host, port, path, query, fragment = parse_url(url)
>   File "/usr/lib/python3/dist-packages/urllib3/util/url.py", line 392, in 
> parse_url
> return six.raise_from(LocationParseError(source_url), None)
>   File "", line 3, in raise_from
> urllib3.exceptions.LocationParseError: Failed to parse: 
> https://acme-v02.api.letsencrypt.org/directory
>
> downgrading to python3-urllib3=1.24.1-1 solve this issue.
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
> 'oldstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> 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 /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages certbot depends on:
> ii  python3  3.7.5-3
> ii  python3-certbot  1.1.0-1
>
> certbot recommends no packages.
>
> Versions of packages certbot suggests:
> pn  python-certbot-doc  
> ii  python3-certbot-apache  1.1.0-1
> pn  python3-certbot-nginx   
>
> -- no debconf information
>


-- 
Harlan Lieberman-Berg
~hlieberman

Bug#951748: dh-python: subst emission results in dpkg-gencontrol warning in absence of deprecated field

[Nick Black]

Package: dh-python
Version: 4.20191017
Severity: normal
Tags: patch

Dear Maintainer,

dpkg-gencontrol emits warnings for defined but unused subst
variables. An example:

 dpkg-gencontrol: warning: package python3-notcurses: substitution variable
${python3:Versions} unused, but is defined
 dpkg-gencontrol: warning: package python3-notcurses: substitution variable
${python3:Versions} unused, but is defined

dh-python, through both dh_python2 and dh_python3, emits a
definition for python3:Versions (or python:Versions in the
former case). So far as I can tell, this was done in conjunction with
an XB-Python-Version initiative which has since been deprecated:

"The use of XB-Python-Version in the binary package paragraphs of
debian/control file has been deprecated and should be removed in the normal
course of package updates. It never achieved sufficient deployment to support
its intended purpose of managing Python transitions. This purpose can be
adequately accomplished by examining package dependencies."
--https://www.debian.org/doc/packaging-manuals/python-policy/ch-
module_packages.html

"unused substitution,variable ${python:Versions}"
--https://lists.debian.org/debian-python/2010/07/msg00011.html

I am not a Python expert by any means, so I might be missing
something. If not, this warning is annoying, and there seems
no reason to emit the subst. This patch removes it (also available
from g...@salsa.debian.org:nickblack-guest/dh-python.git).

--
diff --git dh_python2 dh_python2
index 64cd438..36dd797 100755
--- dh_python2
+++ dh_python2
@@ -439,8 +439,6 @@ def main():
 dependencies.parse(stats, options)

 if stats['public_vers']:
-dh.addsubstvar(package, 'python:Versions',
-   ', '.join(str(i) for i in
sorted(stats['public_vers'])))
 ps = package.split('-', 1)
 if len(ps) > 1 and ps[0] == 'python':
 dh.addsubstvar(package, 'python:Provides',
diff --git dh_python3 dh_python3
index 5f58d9b..77a75c0 100755
--- dh_python3
+++ dh_python3
@@ -201,8 +201,6 @@ def main():
 dependencies.parse(stats, options)

 if stats['ext_vers']:
-dh.addsubstvar(package, 'python3:Versions',
-   ', '.join(str(v) for v in
sorted(stats['ext_vers'])))
 ps = package.split('-', 1)
 if len(ps) > 1 and ps[0] == 'python3':
 dh.addsubstvar(package, 'python3:Provides',
--



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

Kernel: Linux 5.5.3nlb (SMP w/20 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dh-python depends on:
ii  python33.7.5-3
ii  python3-distutils  3.8.0-1

dh-python recommends no packages.

Versions of packages dh-python suggests:
ii  dpkg-dev  1.19.7
ii  libdpkg-perl  1.19.7

-- no debconf information
>From cf21b467f3051a69a27ef2aacd4cb29736d4f3f7 Mon Sep 17 00:00:00 2001
From: nick black 
Date: Thu, 20 Feb 2020 22:37:54 -0500
Subject: [PATCH] Don't emit python[3]:Versions

---
 dh_python2 | 2 --
 dh_python3 | 2 --
 2 files changed, 4 deletions(-)

diff --git dh_python2 dh_python2
index 64cd438..36dd797 100755
--- dh_python2
+++ dh_python2
@@ -439,8 +439,6 @@ def main():
 dependencies.parse(stats, options)
 
 if stats['public_vers']:
-dh.addsubstvar(package, 'python:Versions',
-   ', '.join(str(i) for i in 
sorted(stats['public_vers'])))
 ps = package.split('-', 1)
 if len(ps) > 1 and ps[0] == 'python':
 dh.addsubstvar(package, 'python:Provides',
diff --git dh_python3 dh_python3
index 5f58d9b..77a75c0 100755
--- dh_python3
+++ dh_python3
@@ -201,8 +201,6 @@ def main():
 dependencies.parse(stats, options)
 
 if stats['ext_vers']:
-dh.addsubstvar(package, 'python3:Versions',
-   ', '.join(str(v) for v in 
sorted(stats['ext_vers'])))
 ps = package.split('-', 1)
 if len(ps) > 1 and ps[0] == 'python3':
 dh.addsubstvar(package, 'python3:Provides',
-- 
2.25.1

Bug#951280: fixed in ncbi-blast+ 2.9.0-4

[Aaron M. Ucko]

Andreas Tille  writes:

> Cool.  Please ping me if its in testing.

It is; please go ahead with the upload to backports.

Thanks!

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

Bug#855541: Update: actually it works

[Jean-Philippe MENGUAL]

Hi,

Ok I have just built the git release, now it works. So to maintain this 
package usable in Debian, you need to update it to the latest git 
release, from December, 28. Do you want a specific bug to request 
update? Without it, I think it is unusable now.


Regards

--
Jean-Philippe MENGUAL

Bug#855541: purple-matrix: Not ready for release yet

[Jean-Philippe MENGUAL]

Package: purple-matrix
Version: 0.0.0+git20191228-1
Followup-For: Bug #855541

Hi,

What server do you use to have this package working? Here on two
servers I get:
Failed to create e2e db table (step)

So this package seems unusable now.

Regards

Dear Maintainer,

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

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

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


-- 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.4.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages purple-matrix depends on:
ii  libc6   2.29-10
ii  libgcrypt20 1.8.5-3
ii  libglib2.0-02.62.4-2
ii  libhttp-parser2.9   2.9.2-2
ii  libjson-glib-1.0-0  1.4.4-2
ii  libolm3 3.1.3+dfsg-2
ii  libpurple0  2.13.0-2.2+b1
ii  libsqlite3-03.31.1-2

purple-matrix recommends no packages.

purple-matrix suggests no packages.

-- debconf-show failed

Bug#951747: linux-image-5.4.0-4-amd64: please configure with SND_SOC_SOF_COMETLAKE_LP_SUPPORT

[Daniel Serpell]

Package: src:linux
Version: 5.4.19-1
Severity: wishlist

Dear maintainer,

The SND_SOC_SOF_COMETLAKE_LP_SUPPORT option is needed for snd-soc-sof driver to 
work on this CPU, can it be configured to "y"?

Regards,

Daniel.

-- Package-specific info:
** Version:
Linux version 5.4.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 
20200203 (Debian 9.2.1-28)) #1 SMP Debian 5.4.19-1 (2020-02-13)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.4.0-4-amd64 root=/dev/nvme0n1p5 ro quiet

** Model information
sys_vendor: Acer
product_name: Swift SF314-58G
product_version: V1.04
chassis_vendor: Acer
chassis_version: V1.04
bios_vendor: Insyde Corp.
bios_version: V1.04
board_vendor: CML
board_name: Strongbow_CM
board_version: V1.04

** Loaded modules:
snd_sof_pci
snd_sof_intel_hda_common
snd_sof_intel_hda
snd_sof_intel_byt
snd_sof_intel_ipc
snd_sof_xtensa_dsp
snd_soc_hdac_hda
snd_hda_ext_core
snd_soc_acpi_intel_match
snd_soc_acpi
snd_intel_nhlt
snd_hda_codec
snd_hda_core
snd_hwdep
snd_sof
snd_soc_core
snd_compress
snd_pcm
snd_timer
snd
sctp
nls_ascii
nls_cp437
vfat
fat
uinput
sd_mod
sg
uas
fuse
ctr
ccm
rfcomm
xt_CHECKSUM
xt_MASQUERADE
xt_conntrack
ipt_REJECT
nf_reject_ipv4
xt_tcpudp
nft_compat
veth
dm_mod
cmac
nft_counter
nft_chain_nat
nf_nat
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
nf_tables
nfnetlink
loop
tun
bridge
stp
llc
x86_pkg_temp_thermal
intel_powerclamp
bnep
coretemp
bbswitch(OE)
kvm_intel
kvm
irqbypass
crct10dif_pclmul
ghash_clmulni_intel
intel_rapl_msr
ledtrig_audio
btusb
btrtl
btbcm
btintel
bluetooth
iwlmvm
mac80211
aesni_intel
crypto_simd
libarc4
cryptd
glue_helper
intel_cstate
intel_uncore
drbg
efi_pstore
intel_rapl_perf
iwlwifi
joydev
ansi_cprng
evdev
ecdh_generic
i915
pcspkr
cfg80211
serio_raw
efivars
intel_wmi_thunderbolt
acer_wmi
ecc
drm_kms_helper
wmi_bmof
iTCO_wdt
iTCO_vendor_support
soundcore
uvcvideo
watchdog
drm
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
videobuf2_common
videodev
processor_thermal_device
mei_me
intel_rapl_common
mc
mei
hid_multitouch
rfkill
i2c_algo_bit
intel_soc_dts_iosf
button
tpm_crb
tpm_tis
int3403_thermal
tpm_tis_core
int340x_thermal_zone
ac
tpm
rng_core
int3400_thermal
acpi_pad
intel_hid
acpi_thermal_rel
sparse_keymap
binfmt_misc
nfsd
parport_pc
auth_rpcgss
ppdev
nfs_acl
lockd
grace
lp
parport
sunrpc
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
btrfs
zstd_decompress
zstd_compress
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
crc32c_generic
raid1
raid0
multipath
linear
md_mod
f2fs
crc32_generic
usb_storage
ehci_pci
ehci_hcd
hid_generic
i2c_designware_platform
i2c_designware_core
xhci_pci
ahci
xhci_hcd
libahci
libata
nvme
usbcore
crc32_pclmul
scsi_mod
i2c_i801
crc32c_intel
nvme_core
i2c_hid
intel_lpss_pci
hid
intel_lpss
idma64
mfd_core
usb_common
battery
video
wmi

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:9b61] (rev 0c)
Subsystem: Acer Incorporated [ALI] Device [1025:1410]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 
[8086:9b41] (rev 02) (prog-if 00 [VGA controller])
Subsystem: Acer Incorporated [ALI] UHD Graphics [1025:1410]
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

00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200 
v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 0c)
Subsystem: Acer Incorporated [ALI] Xeon E3-1200 v5/E3-1500 v5/6th Gen 
Core Processor Thermal Subsystem [1025:1410]
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: proc_thermal
Kernel modules: processor_thermal_device

00:12.0 Signal processing controller [1180]: Intel Corporation Comet Lake 
Thermal Subsytem [8086:02f9]
Subsystem: Acer Incorporated [ALI] Comet Lake Thermal Subsytem 
[1025:1410]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:14.0 USB controller [0c03]: Intel Corporation Device [8086:02ed] (prog-if 30 
[XHCI])
Subsystem: Acer Incorporated [ALI] Device [1025:1410]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:14.2 RAM memory 

Bug#947856: php-mongo-php-adapter: Remove depends/build-depends on src:mongodb

[David Prévot]

Hi Moritz,

Le 20/02/2020 à 12:43, Moritz Mühlenhoff a écrit :

> let's remove this (and php-php-mongodb)? There are no rev deps in the archive

Sure, please proceed. I uploaded those in order to enable mongoDB tests
in other packages (before being aware of the mongoDB state) so they are
pretty useless.

Regards

David



signature.asc
Description: OpenPGP digital signature

Bug#951565: freerdp2-x11: does not work at all, immediately exits, against xrdp server (rdesktop works)

[Thorsten Glaser]

Hi Mike,

> While being keen on seeing the above issue fixed very soon, I think it
> does not justify a severity:grave (unless you also observe freerdp2
> failing against MS Windows's RDP server).

I think I could argue that if it works only against Windows, it’s
either RC or xfreerdp would need to be moved from main to contrib ☻
but let’s not get there, I believe you when you say you’re also
interested in fixing it; I’ve not got a Windows to test against at
the moment.

> Please let me know which xRDP version you tested against.

Both buster…

xorgxrdp1:0.2.9-1
xrdp0.9.9-1

… and sid…

xorgxrdp1:0.2.12-1
xrdp0.9.12-1

… fail in the same manner. I normally use rdesktop, but I
wanted microphone redirection, so I tried xfreerdp.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#951442: debian-security-support: Please allow to exclude specific packages from the check

[Daniel Shahaf]

Holger Levsen wrote on Fri, 21 Feb 2020 00:26 +00:00:
> On Sun, Feb 16, 2020 at 07:35:39PM +, Daniel Shahaf wrote:
> > > & patches welcome.
> > Here you go, against current git:
> 
> wheeehoo, very nice.
> 

Thanks for the review!

> just two comments:
>  
> > +write_file ($list_limited, <<__EOS__);
> > +php5See README.Debian.security for the PHP security policy
> > +__EOS__
> 
> why is php5 mentioned here?

I'm not sure I understand the question.

I based the new test on the existing "simple ($awk)" test.  That test
uses php5 as the example, so that carried over to the new test.

However, I suspect that doesn't answer your question.  Could you clarify
it, please?

> > % ./check-support-status 
> > --except=binutils,binutils-common:amd64,binutils-x86-64-linux-gnu,libbinutils:amd64,libctf0:amd64,libctf-nobfd0:amd64
> > I'm not sure if the handling of the ":amd64" architecture suffixes is
> > ideal.  Thoughts?
> 
> I'd rather not have this there:
> - it makes things complicated if I need to know if a package is 
> arch:all or the host binary arch
> - it's also redudant, if the system is amd64, all packages will be 
> amd64. (well, modulo multi-arch i guess)

Okay, so what would you prefer?  To have --except=foo match both
foo and foo:bar for any value of bar?  (and 'foo' documented as
a bare package name without a ":arch" suffix)

Cheers,

Daniel

Bug#950652: ITP: gcc64 -- compiler host64 and target 32 with multilib

[YunQiang Su]

Control: unblock 950652 by 950542 950545 950547 950549 950550
Control: block 950652 by 950642 950645 950647 950649 950650

Mike Gabriel  于2020年2月21日周五 上午5:26写道：
>
> Hi YunQiang,
>
> On Tue, 4 Feb 2020 21:41:12 +0800 YunQiang Su  wrote:
>  > Package: wnpp
>  > Severity: wishlist
>  > Owner: YunQiang Su 
>  > Control: block -1 by 950542 950545 950547 950549 950550
>  >
>  >
>  > * Package name : gcc64
>  > * URL : https://www.gnu.org/software/gcc/
>  > * License : GPLv3+
>  > Programming Lang: C/C++
>  > Description : compiler host64 and target 32 with multilib
>  >
>  > Since the 2GB/3GB memory limitation for 32bit architectures,
>  > we need a toolchain host64 while target32.
>  >
>  > This package archive this by multilib.
>  >
>  >
>  > --
>  > YunQiang Su
>  >
>  >
>
> Please fix the blocking bugs of #950652. Thanks.

Ohh. Sorry. it is my typo

s/9505/9506/g

>
> I don't think that a buster-pu bug and a translation bug in
> x2gothinclient relate to the gcc64 ITP...
>
> Mike

Bug#951442: debian-security-support: Please allow to exclude specific packages from the check

[Holger Levsen]

Hi Daniel,

On Sun, Feb 16, 2020 at 07:35:39PM +, Daniel Shahaf wrote:
> > & patches welcome.
> Here you go, against current git:

wheeehoo, very nice.

just two comments:
 
> +write_file ($list_limited, <<__EOS__);
> +php5See README.Debian.security for the PHP security policy
> +__EOS__

why is php5 mentioned here?

> % ./check-support-status 
> --except=binutils,binutils-common:amd64,binutils-x86-64-linux-gnu,libbinutils:amd64,libctf0:amd64,libctf-nobfd0:amd64
> I'm not sure if the handling of the ":amd64" architecture suffixes is
> ideal.  Thoughts?

I'd rather not have this there:
- it makes things complicated if I need to know if a package is arch:all or the 
host binary arch
- it's also redudant, if the system is amd64, all packages will be amd64. 
(well, modulo multi-arch i guess)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

In Europe there are people prosecuted by courts because they saved other people
from drowning in the  Mediterranean Sea.  That is almost as absurd  as if there
were people being prosecuted because they save humans from drowning in the sea.


signature.asc
Description: PGP signature

Bug#951117: libecore1: .xsession-errors eats all disk space

[Ross Vandegrift]

On Thu, Feb 20, 2020 at 11:51:04AM +0300, sergio wrote:
> On 17/02/2020 09:03, Ross Vandegrift wrote:
> > Okay great- about how long it was from the time the session started to the 
> > time
> > you saw the log messages?
> 
> I'm monitoring .xsession-errors and can't say anything definite.
> Sometimes it takes several hours, sometimes I don't see it for a day or
> two. Anyway I see no obvious triggers. I have a couple apps runned
> permanently and have no idea what it can be.

Thanks, I've setup a session to stay open and idle for tonight.  Let's
see what happens if I let it sit for a while.

Thanks,
Ross

Bug#951693: libmodbus: please backport to buster

[Martin]

On 2020-02-20 22:28, SZ Lin (林上智) wrote:
> Great! I'm glad to hear that.

Good, I'll start right now!

> Apart from that, are you willing to co-maintain this package after 
> backporting?

I would not mind adding myself to Uploaders.

Bug#951745: Please don't ship (empty) upstart config file

[Michael Biebl]

Package: php7.3-fpm
Version: 7.3.15-1
Severity: important
File: /etc/init/php7.3-fpm.conf

upstart is dead.
Shipping an (empty) upstart config file is not really benefitting
anyone.
Please consider dropping /etc/init/php7.3-fpm.conf 

Thanks,
Michael

Bug#941669: python3-rpi.gpio fails to work on aarch64 (upgrade needed)

[peter green]

I just found my Debian arm64 Pi and tested this, it seems to work after setting 
"iomem=relaxed" on the kernel command line.

More than enough time has passed since my last mail where I said I would NMU 
after testing, so I have gone ahead with the upload.

Bug#909504: libreoffice-draw: Error when saving odg file containing curve

[Edmund Christian Herenz]

I can reproduce this, but on debian stable:
Libre Office Draw - Version: 6.1.5.2 Build-ID: 1:6.1.5-3+deb10u.

I made a screencast recording the steps to reproduce:
http://people.sc.eso.org/~eherenz/screencast_bugs/simplescreenrecorder-2020-02-20_19.33.16.ogg

Best regards,
Christian


-- 

Edmund Christian Herenz (ESO Fellow) Office: M152
ESO Vitacura Email:  eher...@eso.org
Alonso de Córdova 3107   Phone:  +56 2 2463 3047  (Office)
Vitacura, Casilla 19001  +56 9 4613 7517  (Mobile)
Santiago de Chile, Chile WWW:http://www.sc.eso.org/~eherenz/

Bug#951744: raspi-firmware, please provide a mechanism to add parameters to the kernel command line.

[peter green]

Package: raspi-firmware

Hi,

Sometimes it is necessary to add parameters to the kernel command line, for example 
rpi.gpio requires "iomem=relaxed".

In the current setup there is no good way to do this, editing cmdline.txt 
directly will result in changes being overwritten on the next kernel upgrade. 
Editing /etc/kernel/postinst.d/z50-raspi-firmware is likely to result in 
conflicts when upgrading.

Bug#80123: Interested

[Francesco Poli]

On Wed, 19 Feb 2020 15:24:29 +0100 Julian Andres Klode  wrote:
> On Wed, Feb 19, 2020 at 06:22:55PM +0530, Avinash Sonawane wrote:
[...]
> > I would love to see this implemented so that apt-listbugs can show the
> > bugs before downloading the megs of packages.
> 
> 
> We have hooks now that run before downloads, even before the y/n prompt,
> at least for apt's own command-line tools. apt-listbugs could use that
> I'm sure. See the doc for json-rpc hooks in the tree.

Hello Julian,
apt-listbugs maintainer speaking!

This interesting development has been just been [pointed out] to me by
Avinash.

[pointed out]: 

Are you referring to the [json hooks]?

[json hooks]: 


They seem to be completely different from the DPkg::Pre-Install-Pkgs
hook and its version 3 protocol. Or am I misinterpreting the
documentation?

Isn't there a simple Pre-Download-Pkgs hook that speaks the version 3
protocol, so that I can just change /etc/apt/apt.conf.d/10apt-listbugs,
without redesigning all the interaction between apt-listbugs and
libapt-pkg?

Please let me know, thanks for your time!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpCpySZEnVyl.pgp
Description: PGP signature

Bug#947856: php-mongo-php-adapter: Remove depends/build-depends on src:mongodb

[Moritz Mühlenhoff]

On Tue, Dec 31, 2019 at 02:40:54PM -0500, mo...@debian.org wrote:
> Package: php-mongo-php-adapter
> Severity: normal
> 
> Hello,
> this package still depends/build-depends on a binary package from src:mongodb.
> As mentioned in #947743, there are several issues with mongodb:
> 
> * rc-buggy
> * un-upgreadable due to license issues
> * not part of stable
> * preventing some py2rm work
> 
> and so we're trying to remove it from Debian as it doesnt provide a good
> enough solution nor provides an actual service to our users (who very likely
> want to get a latest version of mongodb, which we cant provide).
> 
> Please remove the dependency (either binary of build-) from this package.

David,
let's remove this (and php-php-mongodb)? There are no rev deps in the archive
and this blocking the removal of src:mongodb and in turn various Python 2 
removals.

Cheers,
Moritz

Bug#885299: bumping severity of pygtk bugs

[Moritz Mühlenhoff]

On Sun, Oct 06, 2019 at 05:09:30PM -0400, Jeremy Bicha wrote:
> Control: severity -1 serious
> Control: tags -1 -buster
> 
> 
> As part of the Python2 removal, it is our intent that pygtk will be removed 
> from Testing before the release of Debian 11
> "Bullseye". Therefore, I am bumping the severity of this bug to Serious to 
> ensure that there is plenty of warning before
> the Debian 11 release and to make the eventual removal of pygtk as smooth as 
> possible.

Should griffith be removed? It's dropped from testing for two years now
and the upstream homepage vanished. Piotr, given that you're among the
upstream authors, is this still maintained?

Cheers,
Moritz

Bug#951743: OpenSSL linking without license exception

[Bastian Germann]

Package: calibre
Severity: serious

This package links to OpenSSL even though it does not have any license
exception for it. ftp-master considers this a serious issue. Please
build without the certgen extension or try to build with an OpenSSL API
compatible library like wolfssl.

Bug#951741: RFS: coinor-cbc/2.10.4+repack1-1 [QA] -- Coin-or branch-and-cut mixed integer programming solver

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "coinor-cbc"

 * Package name: coinor-cbc
   Version : 2.10.4+repack1-1
   Upstream Author :
 * URL : https://projects.coin-or.org/Cbc
 * License : EPL-1
 * Vcs : https://salsa.debian.org/science-team/coinor-cbc
   Section : science

It builds those binary packages:

  coinor-cbc - Coin-or branch-and-cut mixed integer programming solver
  coinor-libcbc3 - Coin-or branch-and-cut mixed integer programming 
solver (shared libraries)
  coinor-libcbc-dev - Coin-or branch-and-cut mixed integer programming 
solver (developer files)
  coinor-libcbc-doc - Coin-or branch-and-cut mixed integer programming 
solver (documentation)


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


  https://mentors.debian.net/package/coinor-cbc

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/coinor-cbc/coinor-cbc_2.10.4+repack1-1.dsc


Changes since the last upload:

   * QA upload.
   * New upstream version 2.10.4+repack1
   * Update Standards-Version to 4.5.0
   * Changes to include BuildTools in source, so we can make use of
 autoreconf during build.
 - Change URI in d/watch
 - Add folders to Files-Excluded in d/copyright
 - Update path in d/coinor-libclp-doc.examples
 - Remove without autoreconf and add override_dh_autoreconf in d/rules
 - Update path for file in d/copyright
   * Update version on runtime and build-dependencies
   * Set upstream metadata fields: Bug-Database, Repository, 
Repository-Browse.

 Update: Bug-Submit
   * Add duplicated file in d/coinor-libcbc-doc.links
   * Remove override_dh_fixperms from d/rules

Regards,
Håvard

Bug#951742: ITP: Liberty CLI -- command-line client for Liberty Deckplan Host

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name : ldh-client
  Version  : 0.0.3
  Upstream Author  : Purism SPC
* Url  : https://source.puri.sm/liberty/tool/client
* Licenses : AGPL-3+
  Programming Lang : Python
  Section  : utils

 Liberty CLI is a user-facing command-line client
 for interacting with a Liberty Deckplan Host (LDH).

I plan to maintain this in the liberty one team, keeping debianization 
in following Git repository:

 https://salsa.debian.org/liberty-one-team/ldh-client.git

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#951367: [PATCH] don't pass an empty arg to wget when --verbose is applied (Closes: #951367)

[Stefan Pietsch]

On 2020-02-18 20:47, Daniel Kahn Gillmor wrote:

If NVSWITCH is empty, the old code was running wget '' …

But this causes wget to fail to fetch the empty URL, which means the
return code ends up being non-zero.  This breaks sbuild-createchroot,
which apparently always passes --verbose to debootstrap.

This error was introduced in 14f0b7aafb4d568b027baeecee08cfac6c4f874d,
so is relatively recent.
---
  functions | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/functions b/functions
index a3c93e9..d6725f7 100644
--- a/functions
+++ b/functions
@@ -93,7 +93,7 @@ wgetprogress () {
ret=$({ { wget $@ 2>&1 >/dev/null || echo $? >&2; } | "$PKGDETAILS" "WGET%" "$PROGRESS_NOW" 
"$PROGRESS_NEXT" "$PROGRESS_END" >&3; } 2>&1)
: ${ret:=0}
else
-   wget "$NVSWITCH" "$@"
+   wget $NVSWITCH "$@"
ret=$?
fi
return $ret



I can confirm the bug and the solutions. Either omitting "--verbose" or 
patching /usr/share/debootstrap/functions helps.



Regards,
Stefan

Bug#950716: transition: ruby2.7

[Lucas Kanashiro]

I'd like to request some rebuilds:

1) ruby-god: It has the status "Maybe-Given-Back" on armel for almost 2
days, and it failed [1] because the builder was not able to resolve
"incoming.debian.org".

2) libsemanage: It failed [2] because of the swig bug #951703, and a fix
was already uploaded.

3) unicorn: For some reason unicorn and ruby-raindrops are in the same
dependency level 2 but unicorn depends on ruby-raindrops to run build
time tests. It failed executing tests against ruby2.7 [3] because at
that time ruby-raindrops rebuilt against ruby2.7 was not available yet.

[1]
https://buildd.debian.org/status/fetch.php?pkg=ruby-god=armel=0.13.7-3%2Bb1=1582077950=0
[2] https://buildd.debian.org/status/package.php?p=libsemanage
[3] https://buildd.debian.org/status/package.php?p=unicorn

-- 
Lucas Kanashiro

Bug#951739: fontmatrix FTCBFS: runs cmake for the build architecture

[Helmut Grohne]

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

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

Helmut
diff --minimal -Nru fontmatrix-0.9.99/debian/changelog 
fontmatrix-0.9.99/debian/changelog
--- fontmatrix-0.9.99/debian/changelog  2020-02-17 12:09:08.0 +0100
+++ fontmatrix-0.9.99/debian/changelog  2020-02-20 22:53:58.0 +0100
@@ -1,3 +1,10 @@
+fontmatrix (0.9.99-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass cross flags to cmake. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 20 Feb 2020 22:53:58 +0100
+
 fontmatrix (0.9.99-1) unstable; urgency=medium
 
   * Add debian/missing-sources. (Closes: #744698)
diff --minimal -Nru fontmatrix-0.9.99/debian/rules 
fontmatrix-0.9.99/debian/rules
--- fontmatrix-0.9.99/debian/rules  2019-07-30 09:45:03.0 +0200
+++ fontmatrix-0.9.99/debian/rules  2020-02-20 22:53:58.0 +0100
@@ -24,11 +24,10 @@
 configure-stamp:
dh_testdir
mkdir -p $(BUILD_DIR)
-   cd $(BUILD_DIR) && $(CMAKE) \
-   -DCMAKE_INSTALL_PREFIX:PATH=/usr \
+   dh_auto_configure --builddirectory=$(BUILD_DIR) -- \
-DCMAKE_SKIP_RPATH:BOOL=1 \
-DRPATH_STYLE:STRING=none \
-   -DCMAKE_C_FLAGS:STRING='$(OPT_FLAG)' ../../
+   -DCMAKE_C_FLAGS:STRING='$(OPT_FLAG)'
 #for the future   -DWANT_PODOFO:bool=1
touch configure-stamp
 #-DCMAKE_BUILD_TYPE=Debug

Bug#951740: bomstrip FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: bomstrip
Version: 9-12
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

bomstrip fails to cross build from source, because debian/rules uses the
build architecture compiler as a make default. The easiest way to fix
that is including dpkg's buildtools.mk. Please consider applying the
attached patch to make bomstrip cross buildable.

Helmut
diff --minimal -Nru bomstrip-9/debian/changelog bomstrip-9/debian/changelog
--- bomstrip-9/debian/changelog 2018-12-26 00:33:57.0 +0100
+++ bomstrip-9/debian/changelog 2020-02-20 17:15:59.0 +0100
@@ -1,3 +1,10 @@
+bomstrip (9-12.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dpkg's buildtools.mk supply ${CC}. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 20 Feb 2020 17:15:59 +0100
+
 bomstrip (9-12) unstable; urgency=medium
 
   * Use my Debian e-mail address.
diff --minimal -Nru bomstrip-9/debian/rules bomstrip-9/debian/rules
--- bomstrip-9/debian/rules 2018-01-16 08:41:06.0 +0100
+++ bomstrip-9/debian/rules 2020-02-20 17:15:58.0 +0100
@@ -18,7 +18,7 @@
 endif
 export DEB_CFLAGS_MAINT_APPEND DEB_CPPFLAGS_MAINT_APPEND
 
-CC?=   cc
+include /usr/share/dpkg/buildtools.mk
 
 override_dh_auto_build:
${CC} -c ${CPPFLAGS} ${CFLAGS} bomstrip.c

Bug#951738: ITP: azure-functions-devops-build -- Azure Devops Build Manager For Azure Functions

[Luca Boccassi]

Package: wnpp
Severity: wishlist
Owner: "Luca Boccassi" 
X-Debbugs-CC: debian-de...@lists.debian.org
Control: block 930413 by -1

* Package name: azure-functions-devops-build
  Version : 0.0.22
  Upstream Author : Microsoft Corporation
* URL : https://github.com/Azure/azure-functions-devops-build
* License : MIT
* Programming Lang: Python
* Description : Azure Devops Build Manager For Azure Functions

This project provides the class AzureDevopsBuildManager and supporting classes.
This manager class allows the caller to manage Azure Devops pipelines that are
maintained within an Azure Devops account. This project was created to be able
to support command line tooling for the AZ Cli.

It is required as a dependency of azure-cli.

-- 
Kind regards,
Luca Boccassi


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

Bug#951732: fails to show UI on gnome

[Lee Garrett]

Found the minimum hard deps needed:

qml-module-qtquick-controls2
qml-module-qtqml-models2

Adrian, please add those two as hard deps to ausweisapp2.

Thanks!

On 20/02/2020 22:30, Lee Garrett wrote:
> Hi again,
> 
> On 20/02/2020 22:16, John Paul Adrian Glaubitz wrote:
>> Hi Lee!
>>
>> On 2/20/20 9:58 PM, Lee Garrett wrote:
>>> I'm trying to run ausweisapp2 on gnome. I tried running it via terminal,
>>> and also get terminal output. But it's impossible for me to get it to show 
>>> an UI. Running
>>> it again on another terminal will create the following output on the first 
>>> one:
>>>
>>> (...)
>>>
>>> So it seems like it *should* be raised somewhere, but still no UI visible.
>>>
>>> At the start of ausweisapp2 following output was shown:
>>>
>>> Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use 
>>> QT_QPA_PLATFORM=wayland to run on Wayland anyway.
>>>
>>> For the fun of it, I installed qtwayland5 and tried running it with:
>>>
>>> QT_QPA_PLATFORM=wayland AusweisApp2
>>>
>>> However, the problem still persists (no GUI).
>>
>> Did you try running it on KDE on your machine?
> 
> I tried running it on xfce, where it showed a systray icon, but only
> offered "Exit Ausweisapp2" when right-clicking on it. Left click/ double
> click did nothing. After installing "kde-standard" (which pulled in a
> bunch of Qt dependencies) it immediately showed a GUI window on start!
> So on the one side ausweisapp2 is not complaining loudly about missing
> libraries, and on the other hand some hard package deps are missing.
> I'll see if I can bisect those for you.
> 
>>
>>> I tried authenticating in on a German government site via ausweisapp2, but 
>>> the
>>> connection stalls, and eventually times out. I'm assuming that the GUI is
>>> waiting for some kind of confirmation, or the PIN.
>>
>> Normally the app should be put in the foreground so you can enter your PIN
>> and that worked for me on KDE when I tried it. I did not test it on GNOME
>> though.
>>
>>> It would be great if we could get it to also work on gnome, I'm assuming it
>>> works on other DEs.
>>
>> I would suggest asking upstream. I can put one of the developers in the loop.
>>
>>> Thanks for packaging ausweisapp2!
>> Sure.
>>
>> Adrian
>>
> 
> Greetings,
> Lee
> 

Bug#951737: ITP: ros-diagnostics -- Robot Operating System (ROS) stack for collecting, publishing, analyzing and viewing diagnostics data

[Johannes 'josch' Schauer]

Package: wnpp
Severity: wishlist
Owner: Johannes 'josch' Schauer 

* Package name: ros-diagnostics
  Version : 1.9.3
  Upstream Author : Open Source Robotics Foundation
* URL : https://wiki.ros.org/diagnostics
* License : BSD
  Programming Lang: C++
  Description : Robot Operating System (ROS) stack for collecting,
publishing, analyzing and viewing diagnostics data

The diagnostics system is designed to collect information from hardware drivers
and robot hardware to users and operators for analysis, troubleshooting, and
logging. The diagnostics stack contains tools for collecting, publishing,
analyzing and viewing diagnostics data.

The diagnostics toolchain is built around the /diagnostics topic. On this
topic, hardware drivers and devices publish diagnostic_msgs/DiagnosticArray
messages with the device names, status and specific data points.

The diagnostic_updater and self_test packages allow nodes to collect and
publish diagnostics data. The diagnostic_aggregator can categorize and analyze
diagnostics at runtime. Operators and developers can view the diagnostics data
using the rqt_robot_monitor package. The diagnostic_analysis package can
convert diagnostics logs to CSV files for examination and after-the-fact
analysis.

The package will be maintained under the science team umbrella.

Bug#951736: ITP: ros-perception-pcl -- PCL (Point Cloud Library) ROS interface stack

[Johannes 'josch' Schauer]

Package: wnpp
Severity: wishlist
Owner: Johannes 'josch' Schauer 

* Package name: ros-perception-pcl
  Version : 1.7.0
  Upstream Author : Open Source Robotics Foundation
* URL : http://wiki.ros.org/perception_pcl
* License : BSD
  Programming Lang: C++
  Description : PCL (Point Cloud Library) ROS interface stack

Upstream moved the code that so far was packaged in Debian as
src:ros-pcl-conversions into ros-perception-pcl together with other
components. So here we package ros-perception-pcl which builds the
binary packages that were formerly built by src:ros-pcl-conversions and
a few more.

The package will be maintained under the science team umbrella.

Bug#951732: fails to show UI on gnome

[Lee Garrett]

Hi again,

On 20/02/2020 22:16, John Paul Adrian Glaubitz wrote:
> Hi Lee!
> 
> On 2/20/20 9:58 PM, Lee Garrett wrote:
>> I'm trying to run ausweisapp2 on gnome. I tried running it via terminal,
>> and also get terminal output. But it's impossible for me to get it to show 
>> an UI. Running
>> it again on another terminal will create the following output on the first 
>> one:
>>
>> (...)
>>
>> So it seems like it *should* be raised somewhere, but still no UI visible.
>>
>> At the start of ausweisapp2 following output was shown:
>>
>> Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use 
>> QT_QPA_PLATFORM=wayland to run on Wayland anyway.
>>
>> For the fun of it, I installed qtwayland5 and tried running it with:
>>
>> QT_QPA_PLATFORM=wayland AusweisApp2
>>
>> However, the problem still persists (no GUI).
> 
> Did you try running it on KDE on your machine?

I tried running it on xfce, where it showed a systray icon, but only
offered "Exit Ausweisapp2" when right-clicking on it. Left click/ double
click did nothing. After installing "kde-standard" (which pulled in a
bunch of Qt dependencies) it immediately showed a GUI window on start!
So on the one side ausweisapp2 is not complaining loudly about missing
libraries, and on the other hand some hard package deps are missing.
I'll see if I can bisect those for you.

> 
>> I tried authenticating in on a German government site via ausweisapp2, but 
>> the
>> connection stalls, and eventually times out. I'm assuming that the GUI is
>> waiting for some kind of confirmation, or the PIN.
> 
> Normally the app should be put in the foreground so you can enter your PIN
> and that worked for me on KDE when I tried it. I did not test it on GNOME
> though.
> 
>> It would be great if we could get it to also work on gnome, I'm assuming it
>> works on other DEs.
> 
> I would suggest asking upstream. I can put one of the developers in the loop.
> 
>> Thanks for packaging ausweisapp2!
> Sure.
> 
> Adrian
> 

Greeting,
Lee

Bug#950652: ITP: gcc64 -- compiler host64 and target 32 with multilib

[Mike Gabriel]

Hi YunQiang,

On Tue, 4 Feb 2020 21:41:12 +0800 YunQiang Su  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: YunQiang Su 
> Control: block -1 by 950542 950545 950547 950549 950550
>
>
> * Package name : gcc64
> * URL : https://www.gnu.org/software/gcc/
> * License : GPLv3+
> Programming Lang: C/C++
> Description : compiler host64 and target 32 with multilib
>
> Since the 2GB/3GB memory limitation for 32bit architectures,
> we need a toolchain host64 while target32.
>
> This package archive this by multilib.
>
>
> --
> YunQiang Su
>
>

Please fix the blocking bugs of #950652. Thanks.

I don't think that a buster-pu bug and a translation bug in 
x2gothinclient relate to the gcc64 ITP...


Mike

Bug#951735: klayout: FTBFS against Ruby2.7 on different $arch

[Utkarsh Gupta]

Package: klayout
Version: 0.26.2-1
Severity: critical
User pkg-ruby-extras-maintain...@lists.alioth.debian.org
Usertags: ruby2.7-transition

Dear Maintainer,

There's FTBFS against Ruby2.7 on different architectures which is
blocking our transition going on right now.
I reported this upstream, too (https://github.com/KLayout/klayout/issues/506).

The failures against Ruby2.7 on different $arch could be found here:
https://buildd.debian.org/status/package.php?p=klayout

Requesting you to please take a look at it and help us in fixing them :)


Best,
Utkarsh
---

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

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

Versions of packages klayout depends on:
ii  libc6 2.29-10
ii  libgcc-s1 [libgcc1]   10-20200211-1
ii  libgcc1   1:10-20200211-1
ii  libpython3.7  3.7.6-1+b1
ii  libqt5core5a  5.12.5+dfsg-8
pn  libqt5designer5   
ii  libqt5gui55.12.5+dfsg-8
pn  libqt5multimedia5 
pn  libqt5multimediawidgets5  
ii  libqt5network55.12.5+dfsg-8
pn  libqt5printsupport5   
pn  libqt5sql5
ii  libqt5svg55.12.5-2
ii  libqt5widgets55.12.5+dfsg-8
pn  libqt5xml5
pn  libqt5xmlpatterns5
ii  libruby2.52.5.7-1+b1
ii  libstdc++610-20200211-1
ii  python3   3.7.5-3
ii  zlib1g1:1.2.11.dfsg-1.2

Bug#951565: freerdp2-x11: does not work at all, immediately exits, against xrdp server (rdesktop works)

[Mike Gabriel]

Control: severity -1 important

Hi Thorsten,

On  Di 18 Feb 2020 07:18:23 CET, Thorsten Glaser wrote:


Package: freerdp2-x11
Version: 2.0.0~git20190204.1.2693389a+dfsg1-2
Severity: grave
Justification: renders package unusable

tglase@tglase-nb:~ $ xfreerdp /v:tglase-edge
[07:15:07:750] [29233:29234]  
[INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[07:15:07:751] [29233:29234] [INFO][com.freerdp.client.x11] - No  
user name set. - Using login name: tglase
[07:15:08:615] [29233:29234] [INFO][com.freerdp.gdi] - Local  
framebuffer format  PIXEL_FORMAT_BGRX32
[07:15:08:615] [29233:29234] [INFO][com.freerdp.gdi] - Remote  
framebuffer format PIXEL_FORMAT_RGB16
[07:15:08:628] [29233:29234] [INFO][com.winpr.clipboard] -  
initialized POSIX local file subsystem
[07:15:08:744] [29233:29234] [ERROR][com.freerdp.core.update] -  
[0x03] Cache Glyph - SERVER BUG: The support for this feature was  
not announced! Use /relax-order-checks to ignore
[07:15:08:744] [29233:29234] [ERROR][com.freerdp.core.update] -  
order flags 03 failed
[07:15:08:744] [29233:29234] [ERROR][com.freerdp.core.fastpath] -  
Fastpath update Orders [0] failed, status 0
[07:15:08:744] [29233:29234] [ERROR][com.freerdp.core.fastpath] -  
fastpath_recv_update() - -1
[07:15:08:744] [29233:29234] [ERROR][com.freerdp.core.fastpath] -  
fastpath_recv_update_data() fail
[07:15:08:744] [29233:29234] [ERROR][com.freerdp.core.transport] -  
transport_check_fds: transport->ReceiveCallback() - -3
[07:15:08:745] [29233:29234] [ERROR][com.freerdp.core] -  
freerdp_check_fds() failed - 0
[07:15:08:745] [29233:29234] [INFO][com.freerdp.client.common] -  
Network disconnect!
[07:15:08:745] [29233:29234] [ERROR][com.freerdp.client.x11] -  
Failed to check FreeRDP file descriptor

131|tglase@tglase-nb:~ $ rdesktop -g 1000x768 tglase-edge
Connection established using plain RDP.
[…]

xfreerdp just exits with errorlevel 131 (could be signal 3),
whereas rdesktop works (shows the remote login screen).
xfreerdp, just before exiting, paints a window, but I cannot
see if anything is in it because it goes away too quickly.

I also tried xfreerdp /size:1000x768 /v:tglase-edge but that
does not change anything.


While being keen on seeing the above issue fixed very soon, I think it  
does not justify a severity:grave (unless you also observe freerdp2  
failing against MS Windows's RDP server).


Please let me know which xRDP version you tested against.

I will get in touch with upstream and see what can be done about this.

Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpDCX5o6LFH0.pgp
Description: Digitale PGP-Signatur

Bug#951727: qmelt: command not found

[Jonas Smedegaard]

Quoting Celelibi (2020-02-20 21:42:02)
> The error message is pretty simple (and is mostly the subject of this 
> bug report).
> 
> When I try to export a video, the export job fails immediately and its 
> log (accessible via right-click on the job) says verbatim:
> 
> /usr/bin/nice: '/usr/bin/qmelt': No such file or directory
> Failed with exit code 127

Thanks for the clarification.


> However, I think I found a workaround.
> As I understand, qmelt is supposed to be provided by mltframework. It
> looks like it's actually part of the melt package, with the name 'melt',
> instead of 'qmelt'.
> 
> Therefore, an easy workaround that works for me is to install melt and
> make a symlink from qmelt to melt.
> 
> I'm not sure whether the package melt is actually supposed to provide a
> binary named qmelt. Anyway I guess a fix could be to add a dependency to
> melt and add a postinst script that runs:
> ln -s /usr/bin/melt /usr/bin/qmelt

If indeed qmelt and melt is the same (I suspect it isn't, given the 
comment by author of melt to the upstream bugreport you referenced 
earlier - but I'll leave it to the package maintainer to examine closer) 
then I guess a better approach would be to patch the code tp call melt 
instead of qmelt.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#951732: fails to show UI on gnome

[John Paul Adrian Glaubitz]

Hi Lee!

On 2/20/20 9:58 PM, Lee Garrett wrote:
> I'm trying to run ausweisapp2 on gnome. I tried running it via terminal,
> and also get terminal output. But it's impossible for me to get it to show an 
> UI. Running
> it again on another terminal will create the following output on the first 
> one:
> 
> (...)
> 
> So it seems like it *should* be raised somewhere, but still no UI visible.
> 
> At the start of ausweisapp2 following output was shown:
> 
> Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use 
> QT_QPA_PLATFORM=wayland to run on Wayland anyway.
> 
> For the fun of it, I installed qtwayland5 and tried running it with:
> 
> QT_QPA_PLATFORM=wayland AusweisApp2
> 
> However, the problem still persists (no GUI).

Did you try running it on KDE on your machine?

> I tried authenticating in on a German government site via ausweisapp2, but the
> connection stalls, and eventually times out. I'm assuming that the GUI is
> waiting for some kind of confirmation, or the PIN.

Normally the app should be put in the foreground so you can enter your PIN
and that worked for me on KDE when I tried it. I did not test it on GNOME
though.

> It would be great if we could get it to also work on gnome, I'm assuming it
> works on other DEs.

I would suggest asking upstream. I can put one of the developers in the loop.

> Thanks for packaging ausweisapp2!
Sure.

Adrian

-- 
 .''`.  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#951734: ITP: golang-github-jfrog-gofrog -- The gofrog collection of go utilities

[Fabrice BAUZAC-STEHLY]

Package: wnpp
Severity: wishlist
Owner: Fabrice BAUZAC 

* Package name: golang-github-jfrog-gofrog
  Version : 1.0.5-1
  Upstream Author : JFrog Ltd.
* URL : https://github.com/jfrog/gofrog
* License : Apache-2.0
  Programming Lang: Go
  Description : A collection of go utilities

Description: The gofrog collection of go utilities (library)
 This collection from JFrog contains modules for:
 * Running tasks in parallel
 * Caches following the Least-recently-used policy
 * Running commands and reading their output
 * Creating random files
 * A reader that publishes to multiple consumers
 * Basic AES encryption/decryption

Note: my ultimate goal is to package the JFrog-CLI commandline tool [1]
(Apache-2.0 license).  golang-github-jfrog-gofrog is one of its
dependencies, and I have run dh-make-golang to help me make it.

[1] https://jfrog.com/getcli/

--
Fabrice BAUZAC-STEHLY
PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D

Bug#951733: RFS: bombardier/0.8.3+nmu2 [NMU, RC] -- The GNU Bombing utility

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: bombardier
   Version : 0.8.3+nmu2
   Upstream Author : Gergely Risko  
 * License : GPL-3.0
 * Vcs : 
http://git.debian.org/?p=collab-maint/bombardier.git;a=summary
   Section : games

It builds those binary packages:

  bombardier - The GNU Bombing utility

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/bombardier/bombardier_0.8.3+nmu2.dsc

Changes since the last upload:

   * Non-maintainer upload.
   * Fix FTCBFS. (Closes: #923149)
 - Thanks to Helmut Grohne
   * Fix ftbfs. (Closes: #925646)
 - Thanks to Reiner Herrmann


-- 
Regards
Sudip

Bug#951732: fails to show UI on gnome

[Lee Garrett]

Package: ausweisapp2
Version: 1.20.0-1
Severity: important

Hi John,

I'm trying to run ausweisapp2 on gnome. I tried running it via terminal,
and also get terminal output. But it's impossible for me to get it to show an 
UI. Running
it again on another terminal will create the following output on the first one:

network2020.02.20 21:53:05.987 160492   
HttpRequest::insertHeader(network/HttpRequest.cpp:224) : 
Header | "Host": "127.0.0.1:24727"
network2020.02.20 21:53:05.987 160492   
HttpRequest::insertHeader(network/HttpRequest.cpp:224) : 
Header | "User-Agent": "AusweisApp2/1.20.0 (TR-03124/1.3)"
network2020.02.20 21:53:05.987 160492   
HttpRequest::insertHeader(network/HttpRequest.cpp:224) : 
Header | "Connection": "Keep-Alive"
network2020.02.20 21:53:05.987 160492   
HttpRequest::insertHeader(network/HttpRequest.cpp:224) : 
Header | "Accept-Encoding": "gzip, deflate"
network2020.02.20 21:53:05.987 160492   
HttpRequest::insertHeader(network/HttpRequest.cpp:224) : 
Header | "Accept-Language": "en-US,*"
network2020.02.20 21:53:05.987 160492   
HttpRequest::onHeadersComplete(network/HttpRequest.cpp:181): 
"GET" | QUrl("/eID-Client?Status")
network2020.02.20 21:53:05.987 160492   
HttpRequest::onHeadersComplete(network/HttpRequest.cpp:182): 
Header completed
network2020.02.20 21:53:05.987 160492   
HttpRequest::onMessageComplete(network/HttpRequest.cpp:172): 
Message completed
activation 2020.02.20 21:53:05.987 160492   
...:onNewRequest(activation/webservice/WebserviceActivationHandler.cpp:98) : 
Request type: status
activation 2020.02.20 21:53:05.987 160492   
...tatusRequest(activation/webservice/WebserviceActivationHandler.cpp:226) : 
Create response with status format: PLAIN
network2020.02.20 21:53:05.989 160492   
HttpRequest::insertHeader(network/HttpRequest.cpp:224) : 
Header | "Host": "127.0.0.1:24727"
network2020.02.20 21:53:05.989 160492   
HttpRequest::insertHeader(network/HttpRequest.cpp:224) : 
Header | "User-Agent": "AusweisApp2/1.20.0 (TR-03124/1.3)"
network2020.02.20 21:53:05.989 160492   
HttpRequest::insertHeader(network/HttpRequest.cpp:224) : 
Header | "Connection": "Keep-Alive"
network2020.02.20 21:53:05.989 160492   
HttpRequest::insertHeader(network/HttpRequest.cpp:224) : 
Header | "Accept-Encoding": "gzip, deflate"
network2020.02.20 21:53:05.989 160492   
HttpRequest::insertHeader(network/HttpRequest.cpp:224) : 
Header | "Accept-Language": "en-US,*"
network2020.02.20 21:53:05.989 160492   
HttpRequest::onHeadersComplete(network/HttpRequest.cpp:181): 
"GET" | QUrl("/eID-Client?ShowUI=CURRENT")
network2020.02.20 21:53:05.989 160492   
HttpRequest::onHeadersComplete(network/HttpRequest.cpp:182): 
Header completed
network2020.02.20 21:53:05.989 160492   
HttpRequest::onMessageComplete(network/HttpRequest.cpp:172): 
Message completed
activation 2020.02.20 21:53:05.989 160492   
...:onNewRequest(activation/webservice/WebserviceActivationHandler.cpp:91) : 
Request type: showui

So it seems like it *should* be raised somewhere, but still no UI visible.

At the start of ausweisapp2 following output was shown:

Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use 
QT_QPA_PLATFORM=wayland to run on Wayland anyway.

For the fun of it, I installed qtwayland5 and tried running it with:

QT_QPA_PLATFORM=wayland AusweisApp2

However, the problem still persists (no GUI).

I tried authenticating in on a German government site via ausweisapp2, but the
connection stalls, and eventually times out. I'm assuming that the GUI is
waiting for some kind of confirmation, or the PIN.

It would be great if we could get it to also work on gnome, I'm assuming it
works on other DEs.

Thanks for packaging ausweisapp2!

Regards,
Lee Garrett

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

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

Versions of packages ausweisapp2 depends on:
ii  libc62.29-10
ii  libhttp-parser2.92.9.2-2
ii  libpcsclite1 1.8.26-3
ii  libqt5core5a 5.12.5+dfsg-8
ii  libqt5gui5   5.12.5+dfsg-8
ii  libqt5network5   5.12.5+dfsg-8
ii  libqt5qml5   5.12.5-5
ii  libqt5quick5 5.12.5-5
ii  libqt5svg5   5.12.5-2
ii  libqt5websockets5  

Bug#951731: ITP: azure-multiapi-storage-python -- Azure Storage Data Plane SDK supporting multiple API versions

[Luca Boccassi]

Package: wnpp
Severity: wishlist
Owner: "Luca Boccassi" 
X-Debbugs-CC: debian-de...@lists.debian.org
Control: block 930413 by -1

* Package name: azure-multiapi-storage-python
  Version : 0.2.4
  Upstream Author : Microsoft Corporation
* URL : https://github.com/Azure/azure-multiapi-storage-python
* License : MIT
* Programming Lang: Python
* Description : Azure Storage Data Plane SDK supporting multiple API 
versions

Handles multi-API versions of Azure Storage Data Plane as provided by
python3-azure-storage and python3-azure-cosmos.

It is required as a dependency of azure-cli.

-- 
Kind regards,
Luca Boccassi


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

Bug#951730: OpenSSL linking without license exception

[Bastian Germann]

Package: argyll
Severity: serious

This package links to OpenSSL even though it does not have any license
exception for it. ftp-master considers this a serious issue. I can build
fine without libssl, so please remove this dependency.

Bug#951727: qmelt: command not found

[Celelibi]

Package: shotcut
Version: 20.02.17-1
Followup-For: Bug #951727

The error message is pretty simple (and is mostly the subject of this
bug report).

When I try to export a video, the export job fails immediately and its log
(accessible via right-click on the job) says verbatim:

/usr/bin/nice: '/usr/bin/qmelt': No such file or directory
Failed with exit code 127


However, I think I found a workaround.
As I understand, qmelt is supposed to be provided by mltframework. It
looks like it's actually part of the melt package, with the name 'melt',
instead of 'qmelt'.

Therefore, an easy workaround that works for me is to install melt and
make a symlink from qmelt to melt.

I'm not sure whether the package melt is actually supposed to provide a
binary named qmelt. Anyway I guess a fix could be to add a dependency to
melt and add a postinst script that runs:
ln -s /usr/bin/melt /usr/bin/qmelt

Best regards,
Celelibi

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages shotcut depends on:
ii  libc6  2.29-10
ii  libgcc-s1  10-20200211-1
ii  libjs-three111+dfsg1-1
ii  libmlt++3  6.20.0-1
ii  libmlt66.20.0-1
ii  libqt5core5a   5.12.5+dfsg-8
ii  libqt5gui5 5.12.5+dfsg-8
ii  libqt5multimedia5  5.12.5-1+b1
ii  libqt5network5 5.12.5+dfsg-8
ii  libqt5opengl5  5.12.5+dfsg-8
ii  libqt5qml5 5.12.5-5
ii  libqt5quick5   5.12.5-5
ii  libqt5quickwidgets55.12.5-5
ii  libqt5sql5 5.12.5+dfsg-8
ii  libqt5webkit5  5.212.0~alpha3-6
ii  libqt5websockets5  5.12.5-2+b1
ii  libqt5widgets5 5.12.5+dfsg-8
ii  libqt5xml5 5.12.5+dfsg-8
ii  libstdc++6 10-20200211-1
ii  qml-module-qtgraphicaleffects  5.12.5-2+b1
ii  qml-module-qtqml-models2   5.12.5-5
ii  qml-module-qtquick-controls5.12.5-1+b1
ii  qml-module-qtquick-controls2   5.12.5+dfsg-2+b1
ii  qml-module-qtquick-dialogs 5.12.5-1+b1
ii  qml-module-qtquick-extras  5.12.5-1+b1
ii  qml-module-qtquick-layouts 5.12.5-5
ii  qml-module-qtquick-window2 5.12.5-5
ii  qml-module-qtquick25.12.5-5

shotcut recommends no packages.

shotcut suggests no packages.

-- no debconf information

Bug#951729: argyll should use axtls package

[Bastian Germann]

Package: argyll
Severity: normal

argyll vendors axtls which is available as a package in Debian now.
Please move to ths package.

Bug#950063: influxdb-python FTBFS with pandas 0.25.3

[Andreas Tille]

On Thu, Feb 20, 2020 at 10:31:41AM -0500, Alexandre Viau wrote:
> On Thu, Feb 20, 2020 at 4:15 AM Andreas Tille  wrote:
> > Regarding your wish to remove you from Maintainers: I did not intend to
> > take over the package from you personally.  I rather wanted to do
> > something like:
> >
> >   Maintainer: Debian Python Modules Team 
> > 
> >   Uploaders: Alexandre Viau 
> >
> > and you become a member of DPMT to maintain the package inside the team.
> > If you are short in time I could probably do a team upload to fix the
> > current issues, thought.
> 
> Okay that works.

Since I do not have sufficient permissions I asked for it in

   https://salsa.debian.org/salsa/support/issues/197

I'll keep you updated who the migration proceeds.

Kind regards

  Andreas.

> You may do the upload right now and I'll make sure that I am a member
> on salsa DPMT (I used to be on Alioth) before my next upload.
> 
> Thank you for caring about this package!
> 
> Cheers,
> 
> --
> Alexandre Viau
> av...@debian.org
> 

-- 
http://fam-tille.de

Bug#951726: licensecheck: option --encoding is not propagated during recursive scan

[Jonas Smedegaard]

Control: tag -1 confirmed

Hi Dominique,

Quoting Dominique Dumont (2020-02-20 17:15:29)
> While packaging nqp, I've noticed a discrepancy in licensecheck output:
> 
> licensecheck correctly reports the absence of information when
> scanning nqp/115-nums.t file from nqp directory:
> 
> $ licensecheck --encoding utf8 --copyright --machine --recursive nqp | grep 
> 115 
> nqp/115-nums.t  UNKNOWN *No copyright*
> 
> licensecheck correctly reports garbage when scanning nqp/115-nums.t
> file from current directory:
> 
> $ licensecheck --encoding utf8 --copyright --machine --recursive . | grep 115
> ./nqp/115-nums.tUNKNOWN ೨೪, ೫e-೩೨೪, '6e-324 denormal 
> equates to 5e-324 denormal (Uni)'); / ೨೪, ೫e-೩೨೪, '5e-324 
> denormal equates to 5e-324 denormal (Uni)'); / ೨೪, ೧e-೩೨೩, 
> '9e-324 denormal is 1e-323 (Uni)'); / ೨೪, ೦e೦, 'denormal 5e-324 is 
> recognized and is not 0 (Uni)'); / ೨೪, ೦e೦, '2e-324 denormal is 0e0 
> (Uni)'); / e-೩೨೪, ೫e-೩೨೪, '2e-324 denormal equates to 5e-324 
> denormal (Uni)');
> 
> The mis-decoded file contains © character hence the mojibake garbage.
> 
> I would expect --encoding utf8 option to be used to read all files.

Thanks for an excellently framed bugreport!

The cause for the difference in output is revealed in --verbose mode:

$ licensecheck --encoding utf8 --copyright --machine --recursive --verbose . | 
grep '115\|cannot be read'
file moar/05-decoder.t cannot be read with 
App::Licensecheck=HASH(0x563009ec7500)->encoding; encoding, will try latin-1:
- nqp/115-nums.t header -
./nqp/115-nums.tUNKNOWN ೨೪, ೫e-೩೨೪, '6e-324 denormal 
equates to 5e-324 denormal (Uni)'); / ೨೪, ೫e-೩೨೪, '5e-324 denormal 
equates to 5e-324 denormal (Uni)'); / ೨೪, ೧e-೩೨೩, '9e-324 denormal 
is 1e-323 (Uni)'); / ೨೪, ೦e೦, 'denormal 5e-324 is recognized and is not 
0 (Uni)'); / ೨೪, ೦e೦, '2e-324 denormal is 0e0 (Uni)'); / e-೩೨೪, 
೫e-೩೨೪, '2e-324 denormal equates to 5e-324 denormal (Uni)');

Licensecheck chokes on moar/05-decoder.t and re-reads as latin-1.

...but then licensecheck _continues_ to read following files as latin-1, 
which is wrong.

(enabling --verbose also reveals that Licensecheck wrongly treats Encode 
objects as strings, as seen with the HASH string in the warning message)


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#951135: zeromq3: zmq_addons.hpp missing from installed headers

[GCS]

On Thu, Feb 20, 2020 at 9:06 PM Luca Boccassi  wrote:
> On Thu, 2020-02-20 at 20:57 +0100, László Böszörményi wrote:
> > Luca, what's your opinion on this? I think that needs to be packaged
> > separately.
>
> It's a bit weird, but given it's just a header, IMHO it's fine to keep
> shipping it in libzmq3-dev. Upstream we generally try our best to keep
> the hpp header forward and backward compatible, so there should be no
> surprises.
> I do the same in the packages I build upstream in OBS.
 OK. I don't see the point then being developed in a separate git tree
- but let it be. I'm going to sync it with zeromq3 packaging.

Regards,
Laszlo/GCS

Bug#951135: zeromq3: zmq_addons.hpp missing from installed headers

[Luca Boccassi]

On Thu, 2020-02-20 at 20:57 +0100, László Böszörményi wrote:
> On Tue, Feb 11, 2020 at 4:00 PM Gordon Ball <
> gor...@chronitis.net
> > wrote:
> > zeromq3 installs /usr/include/zmq.hpp, which has been copied from
> > cppzmq
> > (
> > https://github.com/zeromq/cppzmq
> > ).
> 
>  Please note it's an upstream issue, the cppzmq is a separate
> project.
> I don't think I should merge that into the zeromq3 package.
> 
> > It's unclear which version of zmq.hpp this is (the copyright dates
> > would
> > suggest fairly old). Possibly since this version the cppzmq repo
> > now
> > includes a second header zmq_addons.hpp ; it would be useful if
> > libzmq3-dev would include updated versions of both headers from
> > cppzmq.
> 
> Luca, what's your opinion on this? I think that needs to be packaged
> separately.

It's a bit weird, but given it's just a header, IMHO it's fine to keep
shipping it in libzmq3-dev. Upstream we generally try our best to keep
the hpp header forward and backward compatible, so there should be no
surprises.
I do the same in the packages I build upstream in OBS.

-- 
Kind regards,
Luca Boccassi


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

Bug#951135: zeromq3: zmq_addons.hpp missing from installed headers

[GCS]

On Tue, Feb 11, 2020 at 4:00 PM Gordon Ball  wrote:
> zeromq3 installs /usr/include/zmq.hpp, which has been copied from cppzmq
> (https://github.com/zeromq/cppzmq).
 Please note it's an upstream issue, the cppzmq is a separate project.
I don't think I should merge that into the zeromq3 package.

> It's unclear which version of zmq.hpp this is (the copyright dates would
> suggest fairly old). Possibly since this version the cppzmq repo now
> includes a second header zmq_addons.hpp ; it would be useful if
> libzmq3-dev would include updated versions of both headers from cppzmq.
Luca, what's your opinion on this? I think that needs to be packaged separately.

> (this would be needed for eg, https://github.com/jupyter-xeus/xeus ).
 How soon do you need this?

Regards,
Laszlo/GCS

Bug#951703: swig: diff for NMU version 4.0.1-2.1

[Boyuan Yang]

Control: tags 951703 + patch
Control: tags 951703 + pending

Dear maintainer,

I've prepared an NMU for swig (versioned as 4.0.1-2.1) and
uploaded it to DELAYED/0 since you are listed in the lowNMU
list.

Regards,
Boyuan Yang

diff -Nru swig-4.0.1/debian/changelog swig-4.0.1/debian/changelog
--- swig-4.0.1/debian/changelog 2020-02-19 15:13:39.0 -0500
+++ swig-4.0.1/debian/changelog 2020-02-20 14:46:05.0 -0500
@@ -1,3 +1,16 @@
+swig (4.0.1-2.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+
+  [ Boyuan Yang ]
+  * debian/: Replace all occurrences of swig3.0 with swig4.0.
+
+  [ Ole Streicher ]
+  * debian/swig.links: Update swig.links for version 4.0.
+(Closes: #951703)
+
+ -- Boyuan Yang   Thu, 20 Feb 2020 14:46:05 -0500
+
 swig (4.0.1-2) unstable; urgency=low
 
   * debian/control: Update Standards-Version to 4.5.0 (no changes).
diff -Nru swig-4.0.1/debian/patches/ccache-rename.diff swig-
4.0.1/debian/patches/ccache-rename.diff
--- swig-4.0.1/debian/patches/ccache-rename.diff2020-01-16
17:50:05.0 -0500
+++ swig-4.0.1/debian/patches/ccache-rename.diff2020-02-20
14:43:25.0 -0500
@@ -1,6 +1,6 @@
 Description: Work around renaming of ccache-swig binary
  The package suffixes binaries with the major version, which changes
- ccache-swig to ccache-swig3.0. However, ccache is sensitive to the
+ ccache-swig to ccache-swig4.0. However, ccache is sensitive to the
  name of its binary. The test did not take the program-suffix configure
  option into account.
  .
diff -Nru swig-4.0.1/debian/swig4.0.dirs swig-4.0.1/debian/swig4.0.dirs
--- swig-4.0.1/debian/swig4.0.dirs  2020-01-16 17:30:31.0 -0500
+++ swig-4.0.1/debian/swig4.0.dirs  2020-02-20 14:43:43.0 -0500
@@ -1,4 +1,4 @@
 usr/bin
 usr/share/man/man1
-usr/share/swig3.0
+usr/share/swig4.0
 usr/share/doc
diff -Nru swig-4.0.1/debian/swig4.0-examples.links swig-4.0.1/debian/swig4.0-
examples.links
--- swig-4.0.1/debian/swig4.0-examples.links2020-01-16 17:30:31.0
-0500
+++ swig-4.0.1/debian/swig4.0-examples.links2020-02-20 14:44:22.0
-0500
@@ -1 +1 @@
-usr/share/doc/swig3.0-examples usr/share/doc/swig3.0/examples
+usr/share/doc/swig4.0-examples usr/share/doc/swig4.0/examples
diff -Nru swig-4.0.1/debian/swig4.0-examples.override swig-
4.0.1/debian/swig4.0-examples.override
--- swig-4.0.1/debian/swig4.0-examples.override 2020-01-18 17:32:43.0
-0500
+++ swig-4.0.1/debian/swig4.0-examples.override 2020-02-20 14:43:58.0
-0500
@@ -1 +1 @@
-swig3.0-examples: extra-license-file usr/share/doc/swig3.0-
examples/GIFPlot/LICENSE
+swig4.0-examples: extra-license-file usr/share/doc/swig4.0-
examples/GIFPlot/LICENSE
diff -Nru swig-4.0.1/debian/swig.links swig-4.0.1/debian/swig.links
--- swig-4.0.1/debian/swig.links2020-01-16 17:30:31.0 -0500
+++ swig-4.0.1/debian/swig.links2020-02-20 14:42:11.0 -0500
@@ -1,2 +1,2 @@
-usr/bin/swig3.0usr/bin/swig
-usr/bin/ccache-swig3.0 usr/bin/ccache-swig
+usr/bin/swig4.0usr/bin/swig
+usr/bin/ccache-swig4.0 usr/bin/ccache-swig
diff -Nru swig-4.0.1/debian/tests/control swig-4.0.1/debian/tests/control
--- swig-4.0.1/debian/tests/control 2020-01-16 17:30:31.0 -0500
+++ swig-4.0.1/debian/tests/control 2020-02-20 14:42:43.0 -0500
@@ -1,8 +1,8 @@
 Tests: flatnested-crash
-Depends: swig3.0
+Depends: swig4.0
 
-Test-Command: ccache-swig3.0 -V
-Depends: swig3.0
+Test-Command: ccache-swig4.0 -V
+Depends: swig4.0
 
 Test-Command: ccache-swig -V
 Depends: swig
diff -Nru swig-4.0.1/debian/tests/flatnested-crash swig-
4.0.1/debian/tests/flatnested-crash
--- swig-4.0.1/debian/tests/flatnested-crash2020-01-16 17:30:31.0
-0500
+++ swig-4.0.1/debian/tests/flatnested-crash2020-02-20 14:43:00.0
-0500
@@ -20,10 +20,10 @@
 %}
 EOF
 
-swig3.0 -version
-swig3.0 -c++ -python nested_scope.i
+swig4.0 -version
+swig4.0 -c++ -python nested_scope.i
 echo "Wrapping for Python: okay"
-swig3.0 -c++ -ruby nested_scope.i
+swig4.0 -c++ -ruby nested_scope.i
 echo "Wrapping for Ruby: okay"
-swig3.0 -c++ -tcl nested_scope.i
+swig4.0 -c++ -tcl nested_scope.i
 echo "Wrapping for Tcl: okay"

Bug#951728: autofdo: FTBFS on armel, mipsel

[Ivo De Decker]

package: src:autofdo
version: 0.19-2
severity: serious
tags: ftbfs

Hi,

The latest upload of autofdo to unstable fails on armel, mipsel:

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

Cheers,

Ivo

Bug#951709: /boot should get a bigger share of disk in default installation

[Ben Hutchings]

On Thu, 2020-02-20 at 18:50 +0530, Pirate Praveen wrote:
> Package: debian-installer
> Version: 20190702+deb10u3
> Severity: important
> 
> With initrd around 60+ MBs, 236 MB /boot in a 300 GB hard disk can hold 
> only 2 versions of the kernels at the same time. When installing a 3rd 
> kernel /boot gets filled up. I think it should be able to store at 
> least 3 kernels and ideally 4 or even more.
>
> The paritions were created automatically with just /home in a separate 
> partition with lvm by debian buster installer.

I agree; the default size of /boot is now too small.  I think we should
normally allocate at least 500 MB to it.

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.




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

Bug#951727: qmelt: command not found

[Jonas Smedegaard]

Hi Celelibi,

Quoting Celelibi (2020-02-20 20:00:20)
> shotcut uses the program qmelt to export the videos. However, unless 
> I'm mistaken, this program is nowhere to be found in debian.

You reference other bugreports about non-Debian packages.

Please describe the exact commands you use with official Debian 
packages, and quote the error messages you experience.

(also, please note that I am not the package maintainer)


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#901148: timidity: upgrading broke sound via pulseaudio

[Joachim Wiedorn]

Now I have made new Debian packages for buster and testing
including my patch:

https://www.joonet.de/sources/timidity/

---
Have a nice day.
Joachim (Germany)


pgpvUH9a2waYC.pgp
Description: Digitale Signatur von OpenPGP

Bug#951727: qmelt: command not found

[Celelibi]

Package: shotcut
Version: 20.02.17-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

shotcut uses the program qmelt to export the videos. However, unless I'm
mistaken, this program is nowhere to be found in debian.

This has already been asked on the forum of shotcut and been discarded
as a packaging issue.
https://forum.shotcut.org/t/shotcut-export-not-working-usr-bin-nice-usr-bin-qmelt-not-found/8043


I tagged this bug as grave since the inability to export a video would
make the whole package pretty useless for most people.

It looks like this bug was already reported back in 2016 for a
non-official debian version.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818114

If anyone has already managed to use this package, I wonder where does
their qmelt program come from.

Best regards,
Celelibi


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

Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages shotcut depends on:
ii  libc6  2.29-10
ii  libgcc-s1  10-20200211-1
ii  libjs-three111+dfsg1-1
ii  libmlt++3  6.20.0-1
ii  libmlt66.20.0-1
ii  libqt5core5a   5.12.5+dfsg-8
ii  libqt5gui5 5.12.5+dfsg-8
ii  libqt5multimedia5  5.12.5-1+b1
ii  libqt5network5 5.12.5+dfsg-8
ii  libqt5opengl5  5.12.5+dfsg-8
ii  libqt5qml5 5.12.5-5
ii  libqt5quick5   5.12.5-5
ii  libqt5quickwidgets55.12.5-5
ii  libqt5sql5 5.12.5+dfsg-8
ii  libqt5webkit5  5.212.0~alpha3-6
ii  libqt5websockets5  5.12.5-2+b1
ii  libqt5widgets5 5.12.5+dfsg-8
ii  libqt5xml5 5.12.5+dfsg-8
ii  libstdc++6 10-20200211-1
ii  qml-module-qtgraphicaleffects  5.12.5-2+b1
ii  qml-module-qtqml-models2   5.12.5-5
ii  qml-module-qtquick-controls5.12.5-1+b1
ii  qml-module-qtquick-controls2   5.12.5+dfsg-2+b1
ii  qml-module-qtquick-dialogs 5.12.5-1+b1
ii  qml-module-qtquick-extras  5.12.5-1+b1
ii  qml-module-qtquick-layouts 5.12.5-5
ii  qml-module-qtquick-window2 5.12.5-5
ii  qml-module-qtquick25.12.5-5

shotcut recommends no packages.

shotcut suggests no packages.

-- no debconf information

Bug#951726: licensecheck: option --encoding is not propagated during recursive scan

[Dominique Dumont]

Package: licensecheck
Version: 3.0.44-1
Severity: normal

Dear Maintainer,

While packaging nqp, I've noticed a discrepancy in licensecheck output:

licensecheck correctly reports the absence of information when
scanning nqp/115-nums.t file from nqp directory:

$ licensecheck --encoding utf8 --copyright --machine --recursive nqp | grep 115 
nqp/115-nums.t  UNKNOWN *No copyright*

licensecheck correctly reports garbage when scanning nqp/115-nums.t
file from current directory:

$ licensecheck --encoding utf8 --copyright --machine --recursive . | grep 115
./nqp/115-nums.tUNKNOWN ೨೪, ೫e-೩೨೪, '6e-324 denormal 
equates to 5e-324 denormal (Uni)'); / ೨೪, ೫e-೩೨೪, '5e-324 denormal 
equates to 5e-324 denormal (Uni)'); / ೨೪, ೧e-೩೨೩, '9e-324 denormal 
is 1e-323 (Uni)'); / ೨೪, ೦e೦, 'denormal 5e-324 is recognized and is not 
0 (Uni)'); / ೨೪, ೦e೦, '2e-324 denormal is 0e0 (Uni)'); / e-೩೨೪, 
೫e-೩೨೪, '2e-324 denormal equates to 5e-324 denormal (Uni)');

The mis-decoded file contains © character hence the mojibake garbage.

I would expect --encoding utf8 option to be used to read all files.

To reproduce:
$ git clone https://salsa.debian.org/perl6-team/nqp.git
$ git checkout 50fb547df36cc51df65c12503f4db223db39361d # optional
$ cd t/

and then run the commands above.

All the best



Dod


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

Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 licensecheck depends on:
ii  libarray-intspan-perl  2.003-1
ii  libgetopt-long-descriptive-perl0.104-1
ii  liblist-someutils-perl 0.58-1
ii  liblog-any-adapter-screen-perl 0.140-1
ii  liblog-any-perl1.708-1
ii  libmoo-perl2.003006-1
ii  libmoox-struct-perl0.017-1
ii  libnamespace-clean-perl0.27-1
ii  libpath-iterator-rule-perl 1.014-1
ii  libpath-tiny-perl  0.108-1
ii  libpod-constants-perl  0.19-1
ii  libre-engine-re2-perl  0.13-4+b1
ii  libregexp-pattern-license-perl 3.1.102-1
ii  libregexp-pattern-perl 0.2.12-1
ii  libscalar-list-utils-perl  1:1.54-1
ii  libsort-key-perl   1.33-2+b2
ii  libstrictures-perl 2.06-1
ii  libstring-copyright-perl   0.003006-1
ii  libstring-escape-perl  2010.002-2
ii  libtry-tiny-perl   0.30-1
ii  perl   5.30.0-9
ii  perl-base [libscalar-list-utils-perl]  5.30.0-9

licensecheck recommends no packages.

Versions of packages licensecheck suggests:
ii  bash-completion  1:2.10-1

-- no debconf information

Bug#869617: Acknowledgement (libutempter0: Helper executable multiply broken: can't add, can't del)

[Taeer Bar-Yam]

I think I understand the problem. Dimitry, please correct me if I'm
wrong.

Indeed it is not possible to do what we're trying to do Conrad, because
what we want to do is change the `utmp` file from the position of any
old program running on a terminal. This is a security problem because it
allows unprivileged users to modify the file for terminals they do not
own.

`utempter` is not meant to be *called* as a utility on the command line,
it's meant to be used from within a terminal emulator, when they
*create* the /dev/pts/X file, they will be handed a file descriptor
pointing to the master. `utempter` is supposed to be used by calling the
helper function with *that* file descriptor.

So TL;DR, what we're trying to do is simply unsafe. We shouldn't be able
to do it. 


That said, does anyone know if there are bigger security holes opened up
by this? How much of a problem is it if someone spoofs a `utmp` entry?
Why should I care?

 --Taeer

Excerpts from Conrad Hughes's message of February 20, 2020 2:46 am:

Hi Dmitry,

Thanks for getting back to me.  Unfortunately I remember little of what
I learned while digging into this two years ago, so I don't know how to
recognise a properly configured pseudo-terminal master device or a
mis-configured operating system with a broken ptsname: I'm just running
Debian 10.3 with Gnome/Wayland.

All I was after was a program that could wrap gnome-terminal's shell
invocations, and add them to utmp, so:

  utmp_wrap /bin/bash -l

would use libutempter to create a utmp entry for each terminal window.
I attach example source that fails with libutempter as released, but
succeeds if it's patched as suggested above.

Are you saying that what I'm after is impossible because of security
concerns, or can you please suggest a means to make it work?

Best regards,
Conrad

Bug#951676: RFS: dia/0.97.3+git20160930-9 -- Diagram editor

[Adam Borowski]

On Wed, Feb 19, 2020 at 10:39:14PM -0300, Rodrigo Carvalho wrote:
>  * Package name: dia

>  - remove obsolete VCS URLs (anonscm no longer exists,
>we should create a VCS on salsa).

There's https://salsa.debian.org/debian/dia already.


-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ I was born a dumb, ugly and work-loving kid, then I got swapped on
⠈⠳⣄ the maternity ward.

Bug#951725: scikit-learn: FTBFS on arm64, armhf, ppc64el: test failures

[Ivo De Decker]

package: src:scikit-learn
version: 0.22.1+dfsg-2
severity: serious
tags: ftbfs

Hi,

The latest upload of scikit-learn to unstable fails on arm64, armhf, ppc64el:

https://buildd.debian.org/status/package.php?p=scikit-learn

Cheers,

Ivo

Bug#951656: r-cran-lwgeom: FTBFS with PROJ 7.0.0 (ERROR: lazy loading failed for package 'lwgeom')

[Sebastiaan Couwenberg]

On 2/19/20 6:35 PM, Bas Couwenberg wrote:
> Your package FTBFS with PROJ 7 from experimental:
> 
>  ** byte-compile and prepare package for lazy loading
>  double free or corruption (!prev)
>  Aborted
>  ERROR: lazy loading failed for package 'lwgeom'

The build succeeded with the fix r-cran-sf.

Not sure if the lazy loading was a transient issue or fixed by sf.

Kind Regards,

Bas

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

Bug#951723: pymongo: FTBFS: test failures on 32 bit architectures

[Ivo De Decker]

package: src:pymongo
version: 3.10.0-1
severity: serious
tags: ftbfs

Hi,

The latest upload of pymongo to unstable fails on armel, armhf, i386, mipsel:

"OverflowError: timestamp out of range for platform time_t"

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

Cheers,

Ivo

Bug#951655: r-cran-sf: FTBFS with PROJ 7.0.0 (configure: error: proj_api.h not found in standard or given locations.)

[Sebastiaan Couwenberg]

Control: tags -1 fixed-upstream patch

The attached patch fixes the issue.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
diff -Nru r-cran-sf-0.8-1+dfsg/debian/changelog 
r-cran-sf-0.8-1+dfsg/debian/changelog
--- r-cran-sf-0.8-1+dfsg/debian/changelog   2020-02-05 07:59:58.0 
+0100
+++ r-cran-sf-0.8-1+dfsg/debian/changelog   2020-02-19 08:33:09.0 
+0100
@@ -1,3 +1,9 @@
+r-cran-sf (0.8-1+dfsg-2) UNRELEASED; urgency=medium
+
+  * Rebuild with PROJ 7.0.0.
+
+ -- Dylan Aïssi   Wed, 19 Feb 2020 08:33:09 +0100
+
 r-cran-sf (0.8-1+dfsg-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru r-cran-sf-0.8-1+dfsg/debian/patches/proj-6.3.x.patch 
r-cran-sf-0.8-1+dfsg/debian/patches/proj-6.3.x.patch
--- r-cran-sf-0.8-1+dfsg/debian/patches/proj-6.3.x.patch1970-01-01 
01:00:00.0 +0100
+++ r-cran-sf-0.8-1+dfsg/debian/patches/proj-6.3.x.patch2020-02-19 
08:33:09.0 +0100
@@ -0,0 +1,18 @@
+Description: use full +init=epsg:xxx strings if PROJ >= 6.3.1
+Author: Edzer Pebesma 
+Origin: 
https://github.com/r-spatial/sf/commit/7e25be898e5b8f0bcc6a775238d81631ad6a75b0
+Bug-Debian: https://bugs.debian.org/951655
+
+--- a/R/crs.R
 b/R/crs.R
+@@ -155,7 +155,9 @@ make_crs = function(x, wkt = FALSE) {
+   else if (is.numeric(x))
+   CPL_crs_from_epsg(as.integer(x))
+   else if (is.character(x)) {
+-  if (grepl("+init=epsg:", x) && sf_extSoftVersion()[["proj.4"]] 
>= "6.0.0") {
++  if (grepl("+init=epsg:", x) &&
++  sf_extSoftVersion()[["proj.4"]] >= "6.0.0" &&
++  sf_extSoftVersion()[["proj.4"]] < "6.3.1") { # 
nocov start FIXME:
+   x = strsplit(x, " ")[[1]]
+   if (length(x) > 1)
+   warning(paste("the following proj4string 
elements are going to be ignored:",
diff -Nru r-cran-sf-0.8-1+dfsg/debian/patches/proj-7.0.0.patch 
r-cran-sf-0.8-1+dfsg/debian/patches/proj-7.0.0.patch
--- r-cran-sf-0.8-1+dfsg/debian/patches/proj-7.0.0.patch1970-01-01 
01:00:00.0 +0100
+++ r-cran-sf-0.8-1+dfsg/debian/patches/proj-7.0.0.patch2020-02-19 
08:33:09.0 +0100
@@ -0,0 +1,44 @@
+Description: configure for PROJ 7.x.y
+Author: Edzer Pebesma 
+Origin: 
https://github.com/r-spatial/sf/commit/25b558fa8896a90e28e16e59d6e31fbc2b63c1db
+Bug-Debian: https://bugs.debian.org/951655
+
+--- a/configure
 b/configure
+@@ -3636,6 +3636,8 @@ if test "${gdal_has_proj}" = no; then
+as_fn_error $? "OGRCoordinateTransformation() does not return a 
coord.trans: PROJ not available?" "$LINENO" 5
+ fi
+ rm -fr errors.txt gdal_proj.cpp gdal_proj
++{ $as_echo "$as_me:${as_lineno-$LINENO}: GDAL: ${GDAL_VERSION}" >&5
++$as_echo "$as_me: GDAL: ${GDAL_VERSION}" >&6;}
+ 
+ 
+ #
+@@ -3684,7 +3686,7 @@ PROJH="no"
+ if test "${proj_config_ok}" = yes; then
+   PROJ_VERSION=`${PROJ_CONFIG} --modversion`
+   PROJV1=`echo "${PROJ_VERSION}" | cut -c 1`
+-  if test "${PROJV1}" = "6"; then
++  if test "${PROJV1}" -ge "6"; then
+ PROJ6="yes"
+ PROJ_CPPFLAGS="${PROJ_CPPFLAGS} -DHAVE_PROJ_H"
+ if test "${proj_api}" = yes; then
+--- a/configure.ac
 b/configure.ac
+@@ -300,6 +300,7 @@ if test "${gdal_has_proj}" = no; then
+AC_MSG_ERROR([OGRCoordinateTransformation() does not return a coord.trans: 
PROJ not available?])
+ fi
+ rm -fr errors.txt gdal_proj.cpp gdal_proj
++AC_MSG_NOTICE([GDAL: ${GDAL_VERSION}])
+ 
+ 
+ #
+@@ -341,7 +342,7 @@ PROJH="no"
+ if test "${proj_config_ok}" = yes; then
+   PROJ_VERSION=`${PROJ_CONFIG} --modversion`
+   PROJV1=`echo "${PROJ_VERSION}" | cut -c 1`
+-  if test "${PROJV1}" = "6"; then
++  if test "${PROJV1}" -ge "6"; then
+ PROJ6="yes"
+ PROJ_CPPFLAGS="${PROJ_CPPFLAGS} -DHAVE_PROJ_H"
+ if test "${proj_api}" = yes; then
diff -Nru r-cran-sf-0.8-1+dfsg/debian/patches/series 
r-cran-sf-0.8-1+dfsg/debian/patches/series
--- r-cran-sf-0.8-1+dfsg/debian/patches/series  2020-02-05 07:59:58.0 
+0100
+++ r-cran-sf-0.8-1+dfsg/debian/patches/series  2020-02-19 08:33:09.0 
+0100
@@ -1,2 +1,4 @@
 exclude_test_requiring_rgeos.patch
 exclude_test_requiring_rgdal.patch
+proj-7.0.0.patch
+proj-6.3.x.patch

Bug#951722: autopkgtest suite flaky on arm64

[Michael Biebl]

Source: dovecot
Version: 1:2.3.7.2-1
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky

Hi,

the autopkgtest suite appears to be flaky on arm64. Sometimes it
succeeds, sometimes command1 fails [1].

This is problematic, as this (randomly) blocks other packages from
entering testing, a recent example is systemd which is currently blocked
because of

  autopkgtest for dovecot/1:2.3.7.2-1: amd64: Pass, arm64: Regression

I asked on #debci, and they recommended to file this as RC bug.
If you think this is an issue of the debci arm64 infrastructure, please
get in touch with debian...@lists.debian.org.

Regards,
Michael

[1] 
https://ci.debian.net/data/autopkgtest/unstable/arm64/d/dovecot/4294703/log.gz

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

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

Bug#951721: autopkgtest suite flaky on arm64: command10 randomly fails

[Michael Biebl]

Source: suricata
Version: 1:4.1.5-2
Severity: serious
User: debian...@lists.debian.org

Hi,

the autopkgtest suite appears to be flaky on arm64. Sometimes it
succeeds, sometimes command10 fails.

This is problematic, as this (randomly) blocks other packages from
entering testing, a recent example is systemd which is currently blocked
because of

  autopkgtest for suricata/1:4.1.5-2: amd64: Pass, arm64: Regression

I asked on #debci, and they recommended to file this as RC bug.
If you think this is an issue of the debci arm64 infrastructure, please
get in touch with debian...@lists.debian.org.

Regards,
Michael

Bug#942622: Would the Games Team adopt Lightyears (pygame based, Python 3 port available)?

[Olek Wojnar]

Hi Steve,

On Thu, Feb 13, 2020, 14:42 Steve Cotton  wrote:

> Hi all in the Games Team,
>
> One of the Debian games affected by the python3 transition is 2
> Lightyears
> Into Space, source package name "lightyears". I've ported it to
> python3-pygame,
> and opened an upstream issue for merging it (sadly this doesn't have an
> upstream response yet).
>
> The Debian package isn't currently maintained by the Games Team, but one
> of the
> serious bugs is "Maintainer email address not working". I'm wondering if
> the
> Games Team would adopt it and apply my python3 port?
>

That's a great game, I've played it quite a few times over the years. I'll
be happy to sponsor the upload under the Games Team umbrella.

However, have you tried contacting the maintainer and the uploader team to
make sure they're ok with transferring the package to the Games Team? I
think it makes sense for us to have it but we need to check with them
first. If you have already obtained that permission, please forward the
email to these lists so that we have it for reference.

Debian bugs:
>   #942622 src:lightyears: Maintainer email address not working
>   #912488 lightyears: Please migrate to python3-pygame
>   #936945 lightyears: Python2 removal in sid/bullseye
>
> Upstream pull request:
>   https://github.com/20kly/20kly/issues/2
>   https://github.com/stevecotton/20kly/tree/version1.4/python3
>
> The Debian package's "copyright" file cleans up some of the oddities of the
> upstream README.md's licensing section, I'm sure it's distributable but
> expect
> it to get some questions if it went through the NEW queue. Oddities such as
> attributing an image as "copyright NASA" instead of saying that it's one of
> NASA's public domain images. I'm happy to put some effort in to fixing
> that.
>

Please do (pending approval to move the package)! Let me know what you need
from me (off-lists is fine for coordinating details).

-Olek

>

Bug#951718: selectively enable seccomp not working as documented

[Marc Haber]

On Thu, Feb 20, 2020 at 05:21:31PM +0100, Julian Andres Klode wrote:
> It is the correct syntax. libseccomp2 in stable is too old to know
> the new syscalls, and there's no way to override by syscall number in
> apt. Both should be fixed IMO:
> 
> - the list of syscalls the libseccomp library handles in stable 
>   does not match the syscalls used in stable

I am not using a stable kernel though. Does that change things?

> - apt should allow you to override by number because that's easier.

So, at the moment, seccomp in apt in stable is unuseable with a more
recent kernel because of this, and should be switched off on my affected
systems?

Greetings
Marc

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

Bug#951703: swig: does not install /usr/bin/swig anymore

[Boyuan Yang]

Control: affects -1 + mypaint

On Thu, 20 Feb 2020 11:39:07 +0100 Ole Streicher  wrote:
> Package: swig
> Version: 4.0.1-2
> Severity: serious
> Affects: astrometry.net
> Tags: +patch
> 
> The "swig" binary package does not install a symlink /usr/bin/swig -->
> swig4.0 anymore. Since this breaks the build of a number of packages, I
> set the severity to "serious".

Looks like it's indeed the case and it is breaking everything that build-
depends on swig. Please consider uploading the trivial fix with a source-only
upload.

-- 
Thanks,
Boyuan Yang


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

Bug#951720: libjs-jquery-file-upload: Please include the css files in the package

[Elena Grandi]

Source: libjs-jquery-file-upload
Severity: wishlist

Dear Maintainer,

thanks for your work maintaining libjs-jquery-file-upload.

I've noticed that your package doesn't ship the css files from the css
directory of the upstream package; could you please add them?

I'm trying to package a program_ that uses those css files; I've already
patched it to get its js files from your package, and it would be nice
to be able to provide all needed files.

.. _program: http://bugs.debian.org/950721

Thanks in advance

Bug#951718: selectively enable seccomp not working as documented

[Julian Andres Klode]

Control: clone -1 -2
Control: reassign -2 libseccomp/2.3.3-4
Control: retitle -1 apt: allow seccomp overrides by number
Control: retitle -2 libseccomp: syscalls missing in stable

On Thu, Feb 20, 2020 at 05:00:18PM +0100, Marc Haber wrote:
> Package: apt
> Version: 1.8.2
> Severity: normal
> 
> Hi,
> 
> /usr/share/doc/apt/examples/configure-index.gz says:
> 
> APT::Sandbox
> {
>User "";
>ResetEnvironment "";
>Verify ""
>{
>   Groups "";
>   IDs "";
>   Regain "";
>};
>seccomp ""
>{
>   print ""; // print what syscall was trapped
>   allow "";
>   trap "";
>};
> };
> 
> To selectively allow the clock_gettime64 syscall as suggested by Julian in
> #951012, I made this
> 
> APT::Sandbox
> {
>seccomp "true"
>{
>   allow "clock_gettime64";
>};
> };
> 
> which results in "E: Cannot allow clock_gettime64: Invalid argument -
> aptMethod::Configuration (0: Success)".
> 
> What would be the correct syntax? Can the docs be fixed please?

It is the correct syntax. libseccomp2 in stable is too old to know
the new syscalls, and there's no way to override by syscall number in
apt. Both should be fixed IMO:

- the list of syscalls the libseccomp library handles in stable 
  does not match the syscalls used in stable
- apt should allow you to override by number because that's easier.

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

Bug#951718: selectively enable seccomp not working as documented

[Marc Haber]

Package: apt
Version: 1.8.2
Severity: normal

Hi,

/usr/share/doc/apt/examples/configure-index.gz says:

APT::Sandbox
{
   User "";
   ResetEnvironment "";
   Verify ""
   {
  Groups "";
  IDs "";
  Regain "";
   };
   seccomp ""
   {
  print ""; // print what syscall was trapped
  allow "";
  trap "";
   };
};

To selectively allow the clock_gettime64 syscall as suggested by Julian in
#951012, I made this

APT::Sandbox
{
   seccomp "true"
   {
  allow "clock_gettime64";
   };
};

which results in "E: Cannot allow clock_gettime64: Invalid argument -
aptMethod::Configuration (0: Success)".

What would be the correct syntax? Can the docs be fixed please?

Greetings
Marc


-- System Information:
Debian Release: 10.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 5.5.2-zgbpi-armmp-lpae (SMP w/2 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2019.1
ii  gpgv2.2.12-1+deb10u1
ii  libapt-pkg5.0   1.8.2
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libgnutls30 3.6.7-4+deb10u2
ii  libseccomp2 2.3.3-4
ii  libstdc++6  8.3.0-6

Versions of packages apt recommends:
ii  ca-certificates  20190110

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.11-7
pn  dpkg-dev
ii  gnupg   2.2.12-1+deb10u1
pn  powermgmt-base  

-- Configuration Files:
/etc/logrotate.d/apt changed [not included]

-- no debconf information

Bug#951488: rspamd/buster causes extensive load on upstream servers, will be disabled

[Lee Garrett]

Package: rspamd
Followup-For: Bug #951488

Hi,

after debugging the issue further with the upstream author we came to the
conclusion that the packages in Debian are not reponsible for the issue.
Apparently even older versions shipped by Synology appliances are causing the
issue due to a broken backpressue algorithm.

Source:
https://twitter.com/rspamd/status/1229774962296225799
https://www.reddit.com/r/synology/comments/f5jczp/mailplus_server_and_rspamdcom/fi0g29t/

As such, I'm closing this bug.

Regards,
Lee

Bug#937302: playonlinux: Python2 removal in sid/bullseye

[Scott Talbert]

On Thu, 30 Jan 2020, Scott Talbert wrote:


Package: src:playonlinux
Version: 4.3.4-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.


Hello,

What is the games team plan for Python 3 support in playonlinux?  Do you plan 
to port it to Python 3?  Or remove?


Ping?

Bug#915386: . libfdk-aac-dev: New upstream version 2.0.0 available

[GMiller]

Hello:

For your information, below is the posting I made to the subject Debian 
Bug#915386:



    Completion of Dream Bug#907576 requires the newer codec of 
libfdk-aac-dev 2.0.0, which has also been requested by Bug#915386 
(latest at Github is 2.0.1). Dream cannot function properly with the 
current 1.6 codec in Debian.


    Is anyone working to complete 915386? I am willing to try to 
package it (ie, ITP), subject to my limited experience in Debian.



Suggestions or help is welcome.

Thank You,

Garie Miller

---

Take back your privacy. Switch to StartMail.com 



--
Take back your privacy. Switch to www.StartMail.com

Bug#938807: RM wammu

[Scott Talbert]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: wammu -- RoQA; no upstream py3 support; unmaintained 
upstream; blocking py2 removal

There is currently no Python3 support upstream[1] and the existing 
maintainer is looking for a new one[2], so it seems best to just remove 
this package.


[1] https://github.com/gammu/wammu/issues/78
[2] https://github.com/gammu/wammu/issues/83

Bug#951717: broccoli-ruby: suppor for multiple Ruby versions is broken

[Antonio Terceiro]

Source: broccoli-ruby
Version: 1.62-1
Severity: serious
Justification: broken, deprecated upstream, blocks Ruby transition
User pkg-ruby-extras-maintain...@lists.alioth.debian.org
Usertags: ruby2.7-transition

After rebuilding broccoli-ruby with ruby2.7 support added, the shared
libraries are not linked correctly. For example, this is after building
from source, and extracting the resulting binary into
/tmp/ruby-broccoli:

$ find /tmp/ruby-broccoli/usr/ -name \*.so -print -exec 'ldd' '{}' ';' | grep 
ruby
/tmp/ruby-broccoli/usr/lib/x86_64-linux-gnu/ruby/vendor_ruby/2.7.0/broccoli_ext.so
libruby-2.5.so.2.5 => /lib/x86_64-linux-gnu/libruby-2.5.so.2.5 
(0x7f92d9dea000)
/tmp/ruby-broccoli/usr/lib/x86_64-linux-gnu/ruby/vendor_ruby/2.5.0/broccoli_ext.so
libruby-2.5.so.2.5 => /lib/x86_64-linux-gnu/libruby-2.5.so.2.5 
(0x7fafc0e04000)

note that both libraries are linked against ruby2.5 (which is currently
the default).

OTOH, at https://github.com/zeek/broccoli-ruby upstream says this is
"DEPRECATED", so maybe it shoud be removed from Debian? For as long as I
can remember, this package has caused problems on new Ruby versions.

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

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


signature.asc
Description: PGP signature

Bug#950063: influxdb-python FTBFS with pandas 0.25.3

[Alexandre Viau]

On Thu, Feb 20, 2020 at 4:15 AM Andreas Tille  wrote:
> Regarding your wish to remove you from Maintainers: I did not intend to
> take over the package from you personally.  I rather wanted to do
> something like:
>
>   Maintainer: Debian Python Modules Team 
> 
>   Uploaders: Alexandre Viau 
>
> and you become a member of DPMT to maintain the package inside the team.
> If you are short in time I could probably do a team upload to fix the
> current issues, thought.

Okay that works.

You may do the upload right now and I'll make sure that I am a member
on salsa DPMT (I used to be on Alioth) before my next upload.

Thank you for caring about this package!

Cheers,

--
Alexandre Viau
av...@debian.org

Bug#951716: packaging-tutorial: [INTL:nl] Dutch po file for the packaging-tutorial package's documentation

[Frans Spiesschaert]

 
 
Package: packaging-tutorial 
Severity: wishlist 
Tags: l10n patch 
 
 
 
 
Dear Maintainer, 
 
 
Please find attached the Dutch po file for the packaging-tutorial
package's documentation. 
It has been submitted for review to the 
debian-l10n-dutch mailing list. Please add it to your next package 
revision. It should be put as "po4a/po/nl.po" in your package build tree. 

Pleas also find attached nl.add, meant to be placed under a new po4a/add_nl
map in your source tree.
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip
PO4A-HEADER:mode=before;position=\\end\{document};beginboundary=NoT_In_ThE_DocUMEnt

\section*{Vertaling}
\begin{frame}{Vertaling}
 Deze handleiding werd uit het Engels vertaald door Frans Spiesschaert en het Nederlandstalig lokalisatieteam.
 \hbr

 Signaleer fouten in de vertaling en geef commentaar op het e-mailadres
 \href{mailto:debian-l10n-du...@lists.debian.org}{\texttt{}}.
\end{frame}

Bug#951687: #951687 mawk vs gawk incompatibility

[Julien Puydt]

Le jeudi 20 février 2020 à 05:04 -0500, Thomas Dickey a écrit :
> The referenced script uses "asort", which is a gawk extension (rather
> than, for instance, being a POSIX feature).  It's not part of BWK
> (one-true-awk), either.
> 
> According to the bug-reporting guidelines, that makes this a feature
> request, aka "wishlist" item.

I wasn't sure exactly what went wrong, so I didn't set a severity. If
it's a feature request, then yes, it's wishlist.

I have proposed my upstream to just drop the awk call, since the order
doesn't seem that meaningful here...

Thanks for the quick answer!

JP

Bug#930367: Virtualbox default network behaviour for Buster

[Emmanuel Kasper]

Hi Nicolas
Sorry I missed your mail here.
The Virtualbox default for Buster is ifupdown, and that will remain the
case as long as Debian uses it as the default.


-- 
You know an upstream is nice when they even accept m68k patches.
  - John Paul Adrian Glaubitz, Debian OpenJDK maintainer

Bug#951715: pygments: What about providing the css files generated by pygmentize?

[Elena Grandi]

Source: pygments
Version: 2.3.1+dfsg-1
Severity: wishlist

Dear Maintainer,

I'm packaging a program_ that uses a css generated_ from pygmentize as
packaged (for pip) by xstatic-pygments.

.. _program: http://bugs.debian.org/950721
.. _generated: 
https://github.com/xstatic-py/xstatic-pygments/blob/master/genstyles.sh

I'm already patching the program to use debian packaged versions of
other js/css resources, and I'm wondering about the best way to deal
with this file.

I wonder if it's worth generating them inside the pygments package and
having them in /usr/share/javascript/pygments (I guess having just css in there 
is fine?) for other packages to use.

If you don't think it is, I can just generate the one I need inside my
package and be done with it, but I'm first trying to understand which
one would be the cleaner solution.

Thanks

Bug#951714: ruby2.5: Please include small workaround to fix the build on sh4

[John Paul Adrian Glaubitz]

Source: ruby2.5
Severity: normal
User: debian-sup...@lists.debian.org
Usertags: sh4

Hello!

Due to a compiler bug in gcc-9 and newer, ruby2.5 (and ruby2.7) currently
gets miscompiled and crashes with an 'Illegal Instruction' error [1].

The problem can be easily worked around by passing -fno-crossjumping through
CFLAGS to the compiler. Could you include the small attached workaround in
the next upload of ruby2.5 (and ruby2.7) to fix the build on sh4 until
the compiler bug has been fixed upstream?

diff -Nru old/ruby2.5-2.5.7/debian/rules new/ruby2.5-2.5.7/debian/rules
--- old/ruby2.5-2.5.7/debian/rules  2019-10-23 17:48:04.0 +0200
+++ new/ruby2.5-2.5.7/debian/rules  2020-02-20 15:17:13.910784900 +0100
@@ -55,6 +55,11 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow
 configure_options += $(shell dpkg-buildflags --export=configure)
 
+# See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
+ifneq (,$(filter $(DEB_HOST_ARCH),sh3 sh4))
+export DEB_CFLAGS_MAINT_APPEND += -fno-crossjumping
+endif
+
 # Always build with /bin/bash, to get consistent rbconfig.rb (which embeds 
SHELL).
 export SHELL := /bin/bash

Thanks,
Adrian

> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru old/ruby2.5-2.5.7/debian/rules new/ruby2.5-2.5.7/debian/rules
--- old/ruby2.5-2.5.7/debian/rules  2019-10-23 17:48:04.0 +0200
+++ new/ruby2.5-2.5.7/debian/rules  2020-02-20 15:17:13.910784900 +0100
@@ -55,6 +55,11 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow
 configure_options += $(shell dpkg-buildflags --export=configure)
 
+# See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
+ifneq (,$(filter $(DEB_HOST_ARCH),sh3 sh4))
+export DEB_CFLAGS_MAINT_APPEND += -fno-crossjumping
+endif
+
 # Always build with /bin/bash, to get consistent rbconfig.rb (which embeds 
SHELL).
 export SHELL := /bin/bash
 

Bug#951693: libmodbus: please backport to buster

[林上智]

Hi,

Martin  於 2020年2月20日 週四 下午4:57寫道：
>
> Source: libmodbus
> Version: 3.1.6-2
> Severity: wishlist
>
> My colleague needs a new feature
> ("New functions to define the indication timeout (#95)")
> in stable. It is in 3.1.5, but stable has 3.1.4.
>
> I can do the backport myself and also push it to salsa.

Great! I'm glad to hear that.

Apart from that, are you willing to co-maintain this package after backporting?

SZ

Bug#951713: weechat: please replace build dependency on ruby-all-dev with ruby-dev

[Antonio Terceiro]

Source: weechat
Version: 2.6-2
Severity: wishlist
Tags: patch
User pkg-ruby-extras-maintain...@lists.alioth.debian.org
Usertags: ruby2.7-transition

When handling transitions to new versions of the ruby interpreter, it's
useful to know which packages can be rebuilt to gain support for the new
interpreter being introduced, and a build-dependency on ruby-all-dev is
a good indicator.

However, there are some packages like weechat that build-depend on
ruby-all-dev, but don't build against all supported Ruby versions, only
against the default/current Ruby. For that, build-depending on ruby-dev
is enough.

Please apply the attached patch.


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

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru weechat-2.6/debian/control weechat-2.6/debian/control
--- weechat-2.6/debian/control	2019-10-11 12:07:22.0 -0300
+++ weechat-2.6/debian/control	2020-02-20 11:01:30.0 -0300
@@ -8,7 +8,7 @@
 debhelper (>= 12),
 cmake, pkg-config,
 libncursesw5-dev,
-gem2deb,
+ruby-dev,
 libperl-dev,
 python3-dev,
 libaspell-dev,


signature.asc
Description: PGP signature

Bug#951712: pyppl hard-codes python 3.7 for the build, ftbfs with 3.8

[Matthias Klose]

Package: src:pplpy
Version: 0.8.4-3
Severity: serious
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: python3.8

pyppl hard-codes python 3.7 for the build, ftbfs with 3.8, and doesn't have a
specific build dependency on 3.7.  Please make the build independent of the
python3 version.

Bug#951710: ITP: microsoft-authentication-extensions-for-python -- Microsoft Authentication extensions for MSAL for Python

[Luca Boccassi]

On Thu, 2020-02-20 at 08:48 -0500, Sam Hartman wrote:
> The description should describe what MSAL is.

The extension depends on the actual MSAL package so I left it out, but
sure here's v2:

Description: Microsoft Authentication extensions for MSAL for Python
 The Microsoft Authentication Library (MSAL) for Python enables applications to
 integrate with the Microsoft identity platform.
 The Microsoft Authentication extensions for MSAL for Python provides
 cross-platform utilities for interacting with MSAL, including a shared cache
 for token that is safe to use concurrently among multiple processes. It is
 intended to be used with python3-msal.

-- 
Kind regards,
Luca Boccassi


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

Bug#951711: ITP: pytest-aiohttp -- pytest plugin for aiohttp support

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name : python-pytest-aiohttp
  Version  : 0.3.0
  Upstream Author  : Andrew Svetlov 
* Url  : https://github.com/aio-libs/pytest-aiohttp
* Licenses : Apache-2.0
  Programming Lang : Python
  Section  : python

 pytest-aiohttp allows to use aiohttp pytest plugin
 without need for implicitly loading it
 like pytest_plugins = 'aiohttp.pytest_plugin'.

This package is required by (testsuite for) python-matrix-nio.

I plan to maintain this package myself, keeping debianization in 
following Git repository:

 https://salsa.debian.org/debian/python-pytest-aiohttp.git


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#951710: ITP: microsoft-authentication-extensions-for-python -- Microsoft Authentication extensions for MSAL for Python

[Sam Hartman]

The description should describe what MSAL is.

Bug#951603: php-nesbot-carbon: new major upstream version available

[Thorsten Glaser]

Hi Robin,

>The only reverse dependency, php-illuminate-support, supports 2.x already at 
>its

considering it’s only packaged for php-illuminate-* which you are
taking over from us, do you wish to also take over this package?

If so please consider this as an OK to proceed.

If not, we’ll have a look at it as time permits.

bye,
//mirabilos
-- 
Thorsten Glaser (Founding Member)
Teckids e.V. — Digital freedom with youth and education
https://www.teckids.org/

Bug#951710: ITP: microsoft-authentication-extensions-for-python -- Microsoft Authentication extensions for MSAL for Python

[Luca Boccassi]

Package: wnpp
Severity: wishlist
Owner: "Luca Boccassi" 
X-Debbugs-CC: debian-de...@lists.debian.org
Control: block 949763 by -1

* Package name: microsoft-authentication-extensions-for-python
  Version : 0.1.3
  Upstream Author : Microsoft Corporation
* URL : 
https://github.com/AzureAD/microsoft-authentication-extensions-for-python
* License : MIT
* Programming Lang: Python
* Description : Microsoft Authentication extensions for MSAL for Python

The Microsoft Authentication extensions for MSAL for Python enables provide
cross-platform utilities for interacting with MSAL, including a shared cache
for token that is safe to use concurrently among multiple processes.

It is required as a new dependency of the new version of python-azure.

-- 
Kind regards,
Luca Boccassi


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

Bug#951709: /boot should get a bigger share of disk in default installation

[Pirate Praveen]

On Thu, Feb 20, 2020 at 2:28 pm, John Paul Adrian Glaubitz 
 wrote:

On 2/20/20 2:20 PM, Pirate Praveen wrote:
 With initrd around 60+ MBs, 236 MB /boot in a 300 GB hard disk can 
hold only 2 versions
 of the kernels at the same time. When installing a 3rd kernel /boot 
gets filled up.


Please note that the default partition layout and hence the size of 
/boot is architecture-
specific. Thus, you need to specify the architecture when asking to 
change the partition

sizes.


This is amd64. (lenovo thinkpad x230 and x240).