Bug#950822: systemd-sysusers hangs if nis is enabled in a systemd-nspawn container

[Michael Biebl]

Am 09.02.20 um 02:24 schrieb Ryutaroh Matsumoto:
> Control: tags -1 + fixed - moreinfo
> Control: retitle -1 Fix found: systemd-sysusers hangs if nis is
> enabled in a systemd-nspawn container
> 
> I found a solution (or a workaround).
> 
> The problem is that
> (1) systemd-sysusers  tries to use Sun RPC (TCP connection to 127.0.0.1:111)
>   in a nis enabled container.

To be more speficic, it's not systemd-sysusers directly, but the nis NSS
module which appears to access the rpcbind socket.

> (2) at that time, rpcbind.socket is ready (by systemd), and

I guess this is actually a timinig issue and you seem to hit this
condition that rpcbind.socket is already started in the container but
not on the physical system.

> (3) rpcbind.service is not ready, because rpcbind.service depends on
>   systemd-sysusers.service.

More specifically, rpcbind.service has
After=systemd-tmpfiles-setup.service
and systemd-tmpfiles-setup.service has
After=systemd-sysusers.service

So the dependency chain is like this
rpcbind.service->systemd-tmpfiles-setup.service->systemd-sysusers.service

> (4) Then systemd-sysusers communication to 127.0.0.1:111 get stuck.
> 
> When I made
> 
> [Unit]
> Before=rpcbind.socket
> as /etc/systemd/system/systemd-sysusers.service.d/my.conf
> 
> OR
> 
> [Unit]
> After=systemd-sysusers.service
> as /etc/systemd/system/rpcbind.socket.d/my.conf
> 
> Then the problem goes away!!!
> 
> Anyway, the current dependency
> rpcbind.socket -> systemd-sysusers.service -> rpcbind.service
> looks nonsense.
> 
> The remaining problem is where the above nonsense order of
> dependency should be fixed, rpcbind Debian package or the systemd
> upstream...

Not sure what the right solution is. One might be, that the nis NSS
module handles this situation (rpcbind.socket running, rpcbind.service
not running) better, or that rpcbind.socket changes its ordering to
avoid this situation.

I do think this should be fixed on the nis/rpcbind side though.




signature.asc
Description: OpenPGP digital signature

Bug#950221: Taking over natsort into Debian Python Modules Team (Was: natsort 6.0 doesn't support Python 3.8)

[Andreas Tille]

On Sat, Feb 08, 2020 at 10:21:06PM +0100, Agustin Henze wrote:
> Hi Andreas, that would be really awesome! If you have time go ahead :).

:-)

If you either give me permissions or transfer the project according to

   https://docs.gitlab.com/ee/user/project/settings/

Navigate to your project’s Settings > General > Advanced settings.
Under “Transfer project”, choose the namespace you want to transfer the
project to.
Confirm the transfer by typing the project’s path as instructed.

to

python-team/modules

this would be a clean move which forwards users of the old Salsa URL to
the new one.

Kind regards

  Andreas.
 
> Thanks,
> 
> On 2/8/20 6:19 AM, Andreas Tille wrote:
> > Hi Agustin,
> >
> > Matthias Klose wrote
> >> natsort 6.0 doesn't support Python 3.8, 6.2 is the first version 
> >> supporting it.
> >> There's also a 7.0 release.
> > I wonde whether you agree to move natsort to Debian Python Modules team
> > to support simple team uploads.  Seems the solution would be to upgrade
> > natsort to a later version.
> >
> > Kind regards
> >
> >Andreas.
> >
> -- 
> TiN
> 
> 

-- 
http://fam-tille.de

Bug#950931: [rebecca_pal...@zoho.com: Bug#950931: q2templates: FTBFS with pandas 1.0: test failures]

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/qiime2/q2templates/issues/41

On Sat, Feb 08, 2020 at 07:25:37PM +0100, Liubov Chuprikova wrote:
> The error seems to be related to this issue:
> https://github.com/qiime2/q2templates/issues/41. We could possibly work on
> it but the upstream is already going to fix the issue in the next release.

I think waiting for upstream is fine.  Setting apropriate tags hereby.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#950979: vdr-plugin-games FTCBFS: use build architecture build tools

[Helmut Grohne]

Source: vdr-plugin-games
Version: 0.6.3-46.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

vdr-plugin-games fails to cross build from source. The upstream
Makefiles hard code g++ in a few occasions and debian/rules hard codes
pkg-config. The attached patch fixes both. Please consider applying it.

Helmut
diff --minimal -Nru vdr-plugin-games-0.6.3/debian/changelog 
vdr-plugin-games-0.6.3/debian/changelog
--- vdr-plugin-games-0.6.3/debian/changelog 2017-09-16 11:22:32.0 
+0200
+++ vdr-plugin-games-0.6.3/debian/changelog 2020-02-09 06:58:34.0 
+0100
@@ -1,3 +1,12 @@
+vdr-plugin-games (0.6.3-46.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Supply pkg-config from dpkg's buildtools.mk.
++ cross.patch: Make g++ substitutable.
+
+ -- Helmut Grohne   Sun, 09 Feb 2020 06:58:34 +0100
+
 vdr-plugin-games (0.6.3-46.1) unstable; urgency=medium
 
   * Non-maintainer upload
diff --minimal -Nru vdr-plugin-games-0.6.3/debian/patches/cross.patch 
vdr-plugin-games-0.6.3/debian/patches/cross.patch
--- vdr-plugin-games-0.6.3/debian/patches/cross.patch   1970-01-01 
01:00:00.0 +0100
+++ vdr-plugin-games-0.6.3/debian/patches/cross.patch   2020-02-09 
06:58:34.0 +0100
@@ -0,0 +1,56 @@
+--- vdr-plugin-games-0.6.3.orig/Makefile
 vdr-plugin-games-0.6.3/Makefile
+@@ -64,11 +64,11 @@
+   @echo
+ 
+ libvdr-games.so: $(OBJS)
+-  g++ $(OBJS) $(LFLAGS) $(ARCHIVES) -o $@
++  $(CXX) $(OBJS) $(LFLAGS) $(ARCHIVES) -o $@
+   @cp $@ $(LIBDIR)/$@.$(APIVERSION)
+ 
+ sdl-games: $(OBJS)
+-  g++ $(OBJS) $(LFLAGS) $(ARCHIVES) -o $@
++  $(CXX) $(OBJS) $(LFLAGS) $(ARCHIVES) -o $@
+ 
+ install: all
+   @cp $(LIBDIR)/libvdr-games.so.$(VDRVER) /mnt/vdr/lib/plugins/
+--- vdr-plugin-games-0.6.3.orig/minesweeper/Makefile
 vdr-plugin-games-0.6.3/minesweeper/Makefile
+@@ -11,4 +11,4 @@
+ 
+ .cpp.o:
+   @echo -n "."
+-  g++ $(DEFINES) $(CFLAGS) -c $<
++  $(CXX) $(DEFINES) $(CFLAGS) -c $<
+--- vdr-plugin-games-0.6.3.orig/snake/Makefile
 vdr-plugin-games-0.6.3/snake/Makefile
+@@ -11,4 +11,4 @@
+ 
+ .cpp.o:
+   @echo -n "."
+-  g++ $(DEFINES) $(CFLAGS) -c $<
++  $(CXX) $(DEFINES) $(CFLAGS) -c $<
+--- vdr-plugin-games-0.6.3.orig/tetris/Makefile
 vdr-plugin-games-0.6.3/tetris/Makefile
+@@ -11,4 +11,4 @@
+ 
+ .cpp.o:
+   @echo -n "."
+-  g++ $(DEFINES) $(CFLAGS) -c $<
++  $(CXX) $(DEFINES) $(CFLAGS) -c $<
+--- vdr-plugin-games-0.6.3.orig/tictactoe/Makefile
 vdr-plugin-games-0.6.3/tictactoe/Makefile
+@@ -11,4 +11,4 @@
+ 
+ .cpp.o:
+   @echo -n "."
+-  g++ $(DEFINES) $(CFLAGS) -c $<
++  $(CXX) $(DEFINES) $(CFLAGS) -c $<
+--- vdr-plugin-games-0.6.3.orig/tron/Makefile
 vdr-plugin-games-0.6.3/tron/Makefile
+@@ -11,4 +11,4 @@
+ 
+ .cpp.o:
+   @echo -n "."
+-  g++ $(DEFINES) $(CFLAGS) -c $<
++  $(CXX) $(DEFINES) $(CFLAGS) -c $<
diff --minimal -Nru vdr-plugin-games-0.6.3/debian/patches/series 
vdr-plugin-games-0.6.3/debian/patches/series
--- vdr-plugin-games-0.6.3/debian/patches/series2017-09-16 
11:22:32.0 +0200
+++ vdr-plugin-games-0.6.3/debian/patches/series2020-02-09 
06:57:53.0 +0100
@@ -3,3 +3,4 @@
 04_gcc-4.6.patch
 flags.patch
 vdr.patch
+cross.patch
diff --minimal -Nru vdr-plugin-games-0.6.3/debian/rules 
vdr-plugin-games-0.6.3/debian/rules
--- vdr-plugin-games-0.6.3/debian/rules 2015-09-22 20:55:36.0 +0200
+++ vdr-plugin-games-0.6.3/debian/rules 2020-02-09 06:58:33.0 +0100
@@ -2,10 +2,11 @@
 
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
+include /usr/share/dpkg/buildtools.mk
 
 MAKE_OPTIONS = VDRDIR=/usr/include/vdr LIBDIR=. LOCALEDIR=locale
-CXXFLAGS += $(shell pkg-config vdr --variable=cxxflags)
-CFLAGS += $(shell pkg-config vdr --variable=cflags)
+CXXFLAGS += $(shell $(PKG_CONFIG) vdr --variable=cxxflags)
+CFLAGS += $(shell $(PKG_CONFIG) vdr --variable=cflags)
 export LFLAGS=$(LDFLAGS)
 
 %:

Bug#950978: rtklib FTCBFS: does not pass cross tools to makefile subdirs

[Helmut Grohne]

Source: rtklib
Version: 2.4.3+dfsg1-2.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

rtklib fails to cross build from source, because it does not pass cross
tools to some app and util makefile buildsystems. Using dh_auto_build
fixes that and makes rtklib cross buildable. The attached patch fixes
that and it also fixes a policy 4.6 violation. Please consider applying
it.

Helmut
diff --minimal -Nru rtklib-2.4.3+dfsg1/debian/changelog 
rtklib-2.4.3+dfsg1/debian/changelog
--- rtklib-2.4.3+dfsg1/debian/changelog 2019-12-05 18:54:09.0 +0100
+++ rtklib-2.4.3+dfsg1/debian/changelog 2020-02-09 07:38:36.0 +0100
@@ -1,3 +1,10 @@
+rtklib (2.4.3+dfsg1-2.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 09 Feb 2020 07:38:36 +0100
+
 rtklib (2.4.3+dfsg1-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru rtklib-2.4.3+dfsg1/debian/rules 
rtklib-2.4.3+dfsg1/debian/rules
--- rtklib-2.4.3+dfsg1/debian/rules 2017-12-08 22:46:05.0 +0100
+++ rtklib-2.4.3+dfsg1/debian/rules 2020-02-09 07:38:34.0 +0100
@@ -20,8 +20,8 @@
 
 #  needed patches: 
https://github.com/Rescube/RTKLIB/commit/a4d665a2c6384ff270d1bfe6e6bcb5f0f3b1066c
 override_dh_auto_build:
-   for i in $(DIRS); do $(MAKE) -C app/$$i/gcc; done
-   $(MAKE) -C util/rnx2rtcm
+   set -e; for i in $(DIRS); do dh_auto_build 
--sourcedirectory=app/$$i/gcc; done
+   dh_auto_build --sourcedirectory=util/rnx2rtcm
dh_auto_build
 
 override_dh_clean:

Bug#950980: vfu FTCBFS: uses build architecture build tools

[Helmut Grohne]

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

vfu fails to cross build from source, because it uses build architecture
build tools. It starts with using the autoconf build system and then
skipping configure. That results in debhelper not passing cross tools to
make. Using the makefile build system is better here as it also skips
makes dh_auto_configure a noop. Then the upstream build system uses
non-standard variables for g++ in lots of places. I think it is best to
canonicalize that and hope that this change is upstreamable. Also the
build strips by default. Doing so also breaks generation of -dbgsym
packages as well as DEB_BUILD_OPTIONS=nostrip. The attached patch fixes
all of that. Please consider applying it.

Helmut
diff --minimal -Nru vfu-4.18/debian/changelog vfu-4.18/debian/changelog
--- vfu-4.18/debian/changelog   2020-01-02 01:49:06.0 +0100
+++ vfu-4.18/debian/changelog   2020-02-09 07:01:09.0 +0100
@@ -1,3 +1,12 @@
+vfu (4.18-2) UNRELEASED; urgency=medium
+
+  * Fix FTCBFS: (Closes: #-1)
++ Use the makefile debhelper build system to pass cross tools.
++ Defer stripping to dh_strip.
++ cross.patch: make build tools substitutable via standard means.
+
+ -- Helmut Grohne   Sun, 09 Feb 2020 07:01:09 +0100
+
 vfu (4.18-1) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru vfu-4.18/debian/patches/cross.patch 
vfu-4.18/debian/patches/cross.patch
--- vfu-4.18/debian/patches/cross.patch 1970-01-01 01:00:00.0 +0100
+++ vfu-4.18/debian/patches/cross.patch 2020-02-09 07:01:09.0 +0100
@@ -0,0 +1,389 @@
+--- vfu-4.18.orig/vslib/makefile
 vfu-4.18/vslib/makefile
+@@ -25,8 +25,8 @@
+ 
+ 
+ AR = ar rv
+-CC = g++
+-LD = g++
++CXX = g++
++LD = $(CXX)
+ MKDIR = mkdir -p
+ RANLIB = ranlib
+ RMDIR = rm -rf
+@@ -36,8 +36,8 @@
+ 
+ ### TARGET 1: libvslib.a 
###
+ 
+-CC_1   = g++
+-LD_1   = g++
++CXX_1  = $(CXX)
++LD_1   = $(CXX_1)
+ AR_1   = ar rv
+ RANLIB_1   = ranlib
+ CCFLAGS_1  = -I. -O2 $(CCDEF)  
+@@ -100,33 +100,33 @@
+ ### TARGET OBJECTS FOR TARGET 1: libvslib.a 

+ 
+ .OBJ.libvslib.a/clusters.o: clusters.cpp  clusters.cpp clusters.h
+-  $(CC_1) $(CFLAGS_1) $(CCFLAGS_1) -c clusters.cpp -o 
.OBJ.libvslib.a/clusters.o
++  $(CXX_1) $(CFLAGS_1) $(CCFLAGS_1) -c clusters.cpp -o 
.OBJ.libvslib.a/clusters.o
+ .OBJ.libvslib.a/dlog.o: dlog.cpp  dlog.cpp dlog.h
+-  $(CC_1) $(CFLAGS_1) $(CCFLAGS_1) -c dlog.cpp -o 
.OBJ.libvslib.a/dlog.o
++  $(CXX_1) $(CFLAGS_1) $(CCFLAGS_1) -c dlog.cpp -o 
.OBJ.libvslib.a/dlog.o
+ .OBJ.libvslib.a/eval.o: eval.cpp  eval.cpp eval.h
+-  $(CC_1) $(CFLAGS_1) $(CCFLAGS_1) -c eval.cpp -o 
.OBJ.libvslib.a/eval.o
++  $(CXX_1) $(CFLAGS_1) $(CCFLAGS_1) -c eval.cpp -o 
.OBJ.libvslib.a/eval.o
+ .OBJ.libvslib.a/fnmatch2.o: fnmatch2.cpp  fnmatch2.cpp fnmatch2.h
+-  $(CC_1) $(CFLAGS_1) $(CCFLAGS_1) -c fnmatch2.cpp -o 
.OBJ.libvslib.a/fnmatch2.o
++  $(CXX_1) $(CFLAGS_1) $(CCFLAGS_1) -c fnmatch2.cpp -o 
.OBJ.libvslib.a/fnmatch2.o
+ .OBJ.libvslib.a/getopt2.o: getopt2.cpp  getopt2.cpp getopt2.h
+-  $(CC_1) $(CFLAGS_1) $(CCFLAGS_1) -c getopt2.cpp  -o 
.OBJ.libvslib.a/getopt2.o
++  $(CXX_1) $(CFLAGS_1) $(CCFLAGS_1) -c getopt2.cpp  -o 
.OBJ.libvslib.a/getopt2.o
+ .OBJ.libvslib.a/scroll.o: scroll.cpp  scroll.cpp scroll.h
+-  $(CC_1) $(CFLAGS_1) $(CCFLAGS_1) -c scroll.cpp   -o 
.OBJ.libvslib.a/scroll.o
++  $(CXX_1) $(CFLAGS_1) $(CCFLAGS_1) -c scroll.cpp   -o 
.OBJ.libvslib.a/scroll.o
+ .OBJ.libvslib.a/vslib.o: vslib.cpp  vslib.cpp
+-  $(CC_1) $(CFLAGS_1) $(CCFLAGS_1) -c vslib.cpp-o 
.OBJ.libvslib.a/vslib.o
++  $(CXX_1) $(CFLAGS_1) $(CCFLAGS_1) -c vslib.cpp-o 
.OBJ.libvslib.a/vslib.o
+ .OBJ.libvslib.a/vstring.o: vstring.cpp  vstring.cpp vstring.h
+-  $(CC_1) $(CFLAGS_1) $(CCFLAGS_1) -c vstring.cpp  -o 
.OBJ.libvslib.a/vstring.o
++  $(CXX_1) $(CFLAGS_1) $(CCFLAGS_1) -c vstring.cpp  -o 
.OBJ.libvslib.a/vstring.o
+ .OBJ.libvslib.a/vstrlib.o: vstrlib.cpp  vstrlib.cpp vstrlib.h vstring.h
+-  $(CC_1) $(CFLAGS_1) $(CCFLAGS_1) -c vstrlib.cpp  -o 
.OBJ.libvslib.a/vstrlib.o
++  $(CXX_1) $(CFLAGS_1) $(CCFLAGS_1) -c vstrlib.cpp  -o 
.OBJ.libvslib.a/vstrlib.o
+ .OBJ.libvslib.a/vsuti.o: vsuti.cpp  vsuti.cpp vsuti.h target.h vstring.h 
vstrlib.h
+-  $(CC_1) $(CFLAGS_1) $(CCFLAGS_1) -c vsuti.cpp-o 
.OBJ.libvslib.a/vsuti.o
++  $(CXX_1) $(CFLAGS_1) $(CCFLAGS_1) -c vsuti.cpp-o 
.OBJ.libvslib.a/vsuti.o
+ .OBJ.libvslib.a/vscrc.o: vscrc.cpp  vscrc.cpp vsuti.h target.h vstring.h
+-  $(CC_1) $(CFLAGS_1) $(CCFLAGS_1) -c vscrc.cpp-o 
.OBJ.libvslib.a/vscrc.o
++  $(CXX_1) $(CFLAGS_1) $(CCFLAGS_1) -c vscrc.cpp-o 

Bug#950977: nim-unicode: should use Files-Excluded: and +ds version suffix

[Sean Whitton]

Package: nim-unicode
Version: 0.5.1-1

Hello,

The orig.tar has been repacked to remove the docs/ subdirectory, but
then the upstream version number needs a '+ds' suffix, and ideally a
Files-Excluded field in d/copyright.  Otherwise this could be a source
of confusion.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#613185: Väärää toimintaa havaitaan,ystävällisesti tarkistaa tilisi uusin versio sisällä 24 tuntia välttää keskeytetty.

[Beate Schuster]

MICROSOFT-PAKOLLINEN ILMOITUS


20 tulevasta viestistäsi on jäädytetty, koska sähköpostilaatikkosi tili
on vahvistettava nyt.
Napsauta alla olevaa vahvistusta vahvistaaksesi sähköpostilaatikkosi
tilisi nyt.

tarkistaa..https://admin00web.wixsite.com/outlookweb0022 

HUOMAUTUS: Älä ohita tätä sähköpostia, jotta tilisi sulkeminen vältetään

   Kiitos,

Microsoftin tarkistustiimi

Tekijänoikeudet 2019 Mail! Inc. (Co. Reg. No.2344507D) Kaikki oikeudet
pidätetään.

Bug#950976: libsword-1.8.1: python3-sword package missing

[Cyrille]

Package: libsword-1.8.1
Version: 1.8.1+dfsg-18.04-1
Severity: normal
File: libsword-1.8.1

Dear Maintainer,

The current sword package doens't have the python3-sword package. This
package can be very usefull. It exist already on Fedora. You can find
more information in this post
https://www.mail-archive.com/sword-devel@crosswire.org/msg34027.html and
the material to build a new package there:
https://src.fedoraproject.org/rpms/sword/tree/master


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

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

Versions of packages libsword-1.8.1:amd64 depends on:
ii  libc6   2.27-3ubuntu1
ii  libclucene-core1v5  2.3.3.4+dfsg-1
ii  libcurl3-gnutls 7.58.0-2ubuntu3.8
ii  libgcc1 1:8.3.0-6ubuntu1~18.04.1
ii  libstdc++6  8.3.0-6ubuntu1~18.04.1
ii  libsword-common 1.8.1+dfsg-18.04-1
ii  zlib1g  1:1.2.11.dfsg-0ubuntu2

Versions of packages libsword-1.8.1:amd64 recommends:
ii  xiphos [sword-frontend]  4.1.0.1-3

libsword-1.8.1:amd64 suggests no packages.

-- no debconf information

Bug#950975: ITP: python3-xdelta3 -- Fast delta encoding in python using xdelta3

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 

* Package name: python3-xdelta3
  Version : 0.0.6a1
  Upstream Author : Samuel Colvin 
* URL : https://github.com/samuelcolvin/xdelta3-python
* License : Apachev2
  Programming Lang: Python
  Description : Fast delta encoding in python using xdelta3

xdelta3-python is a thin Python wrapper around xdelta 3.1.1 which is a
highly optimised c library for delta calculation and compression.

Bug#950973: exim4-config: ignore_target_hosts in dnslookup router does not ignore IPv6 localhost

[C Snover]

Package: exim4-config
Version: 4.92-8+deb10u3
Severity: normal
Tags: ipv6 patch

Dear Maintainer,

Badly configured domain names with an MX record of "localhost" cause 
Exim to freeze messages instead of bouncing them when the local DNS 
resolver resolves "localhost" to an IPv6 address instead of an IPv4 address.


This happens because there are no IPv6 addresses in 
`ignore_target_hosts` for the `dnslookup` router. Adding IPv6 addresses 
to this configuration option ensures identical behaviour regardless of 
whether the DNS resolver returns IPv4 or IPv6 addresses.


In line with the current list of `ignore_target_hosts` which includes 
only private IPv4 networks, the patch I am attaching here tries to add 
only the localhost, private, and link-local IPv6 networks.


All this said, given other reports like Bug #927733 which ask to extend 
the list of target hosts to exclude more special IPv4 subnets, it might 
be a better idea to just make `ignore_target_hosts` use a macro to 
maximise maintainability over the long term.


Thank you for taking the time to read and consider this report.

Best regards,
--- a/conf.d/router/200_exim4-config_primary2019-09-07 08:59:59.0 
+
+++ b/conf.d/router/200_exim4-config_primary2020-02-09 01:12:42.531689133 
+
@@ -33,10 +33,11 @@
   domains = ! +local_domains
   transport = remote_smtp
   same_domain_copy_routing = yes
-  # ignore private rfc1918 and APIPA addresses
-  ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8 : 192.168.0.0/16 :\
-172.16.0.0/12 : 10.0.0.0/8 : 169.254.0.0/16 :\
-   255.255.255.255
+  # ignore private rfc1918, rfc4193, rfc4291, rfc, and APIPA addresses
+  ignore_target_hosts = <; 0.0.0.0 ; 127.0.0.0/8 ; 192.168.0.0/16 ;\
+172.16.0.0/12 ; 10.0.0.0/8 ; 169.254.0.0/16 ;\
+   255.255.255.255 ; ::/128 ; ::1/128 ; fc00::/7 ;\
+   fe80::/10 ; 100::/64
   dnssec_request_domains = *
   no_more
 

Bug#950974: sqlite3: Regressions on big-endian targets break other packages

[John Paul Adrian Glaubitz]

Source: sqlite3
Severity: critical
Tags: patch
Justification: breaks unrelated software
User: debian-s...@lists.debian.org
Usertags: s390x

Hi!

Due to a regression in sqlite3, git has been failing to build from source
on multiple big-endian targets, including the release target s390x [1].

openSUSE has recently cherry-picked two upstream commits which address
this issue [2, 3, 4] and I have verified that these patches fix git
in Debian on ppc64 (and I assume s390x and sparc64 as well). Thus, please
include these patches to unbreak git on ppc64, sparc64 and s390x.

Severity set to 'critical' as this bug breaks unrelated software.

Attaching the two patches taken from openSUSE.

Thanks,
Adrian

> [1] https://marc.info/?l=git=158120991004802=2
> [2] 
> https://build.opensuse.org/package/rdiff/server:database/sqlite3?linkrev=base=241
> [3] https://sqlite.org/src/info/04885763c4cd00cb
> [4] https://sqlite.org/src/info/b20503aaf5b6595a

--
 .''`.  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
Index: ext/fts5/test/fts5matchinfo.test
==
--- ext/fts5/test/fts5matchinfo.test
+++ ext/fts5/test/fts5matchinfo.test
@@ -498,23 +498,26 @@
   CREATE VIRTUAL TABLE t1 USING fts5(x, y);
   INSERT INTO t1 VALUES('a', 'b');
   INSERT INTO t1 VALUES('c', 'd');
 }
 
+if {$tcl_platform(byteOrder)=="littleEndian"} {
+  set res {X'0200'}
+} else {
+  set res {X'0002'}
+}
 do_execsql_test 15.1 {
   SELECT quote(matchinfo(t1, 'n')) FROM t1 LIMIT 1;
-} {X'0200'}
-
+} $res
 do_execsql_test 15.2 {
   DELETE FROM t1_content WHERE rowid=1;
   SELECT quote(matchinfo(t1, 'n')) FROM t1 LIMIT 1;
-} {X'0200'}
+} $res
 
 fts5_aux_test_functions db
 do_execsql_test 15.3 {
   SELECT fts5_test_all(t1) FROM t1 LIMIT 1;
 } {
   {columnsize {0 0} columntext {c d} columntotalsize {2 2} poslist {} tokenize 
{c d} rowcount 2}
 }
 
 finish_test
-

Index: test/fts4aa.test
==
--- test/fts4aa.test
+++ test/fts4aa.test
@@ -227,17 +227,22 @@
 } {1 {database disk image is malformed}}
 
 # 2019-11-18 https://bugs.chromium.org/p/chromium/issues/detail?id=1025467
 db close
 sqlite3 db :memory:
+if {$tcl_platform(byteOrder)=="littleEndian"} {
+  set res 
{X'02000E000E000100010001000100'}
+} else {
+  set res 
{X'0002000E000E0001000100010001'}
+}
 do_execsql_test fts4aa-6.10 {
   CREATE VIRTUAL TABLE f USING fts4();
   INSERT INTO f_segdir VALUES (77,91,0,0,'255 
77',x'000130804d5c4ddd4d4d7b4d4d4d614d8019ff4d0501204d4d2e4d6e4d4d4d4b4d6c4d004d4d4d4d4d4d3d4d5d4d4d645d4d004d4d4d4d4d4d4d4d4d454d6910004d05054d646c4d004d5d4d4d4d4d3d4d4d4d4d4d4d4d4d4d4d4d69624d4d4d04004d4d4d4d4d604d4ce1404d554d45');
   INSERT INTO f_segdir VALUES (77,108,0,0,'255 
77',x'000131fa64004d4d4d3c5d4d654d4d4d614d8000ff4d0501204d4d2e4d6e4d4d4dff4d4d4d4d4d4d00104d4d4d4d4d4d4d0400311d4d4d4d4d4d4d4d4d4d684d6910004d05054d4d6c4d004d4d4d4d4d4d3d4d4d4d4d644d4d4d4d4d4d69624d4d4d03ed4d4d4d4d4d604d4ce1404d550080');
   INSERT INTO f_stat VALUES 
(0,x'808080801064004d4d4d3c4d4d654d4d4d614d8000ff4df6ff1a00204d4d2e4d6e4d4d4d104d4d4d4d4d4d00104d4d4d4d4d4d69574d4d4d31044d4d4d3e4d4d4c4d05004d6910');
   SELECT quote(matchinfo(f,'pnax')) from f where f match '0 1';
-} {X'02000E000E000100010001000100'}
+} $res
 
 # 2019-11-18 Detect infinite loop in fts3SelectLeaf()
 db close
 sqlite3 db :memory:
 do_catchsql_test fts4aa-7.10 {

Index: src/insert.c
==
--- src/insert.c
+++ src/insert.c
@@ -2168,16 +2168,18 @@
 ** Hence, make a complete copy of the opcode, rather than using
 ** a pointer to the opcode. */
 x = *sqlite3VdbeGetOp(v, addrConflictCk);
 if( x.opcode!=OP_IdxRowid ){
   int p2;  /* New P2 value for copied conflict check opcode */
+  const char *zP4;
   if( sqlite3OpcodeProperty[x.opcode]_JUMP ){
 p2 = lblRecheckOk;
   }else{
 p2 = x.p2;
   }
-  sqlite3VdbeAddOp4(v, x.opcode, x.p1, p2, x.p3, x.p4.z, x.p4type);
+  zP4 = x.p4type==P4_INT32 ? SQLITE_INT_TO_PTR(x.p4.i) : x.p4.z;
+  sqlite3VdbeAddOp4(v, x.opcode, x.p1, p2, x.p3, zP4, x.p4type);
   sqlite3VdbeChangeP5(v, x.p5);
   VdbeCoverageIf(v, p2!=x.p2);
 }
 nConflictCk--;
 addrConflictCk++;

Bug#584975: libnet-ldapapi-perl shall depends on libconvert-asn1-perl

[A. Lewenberg]

On Tue, 08 Jun 2010 08:30:24 +0800 chao  wrote:

Package: libnet-ldapapi-perl
Version: 3.0.3-7
Severity: important

libnet-ldapapi-perl require "Convert::ASN1" to work

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

Kernel: Linux 2.6.34 (SMP w/2 CPU cores)
Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



Recent versions of the libnet-ldapapi-perl Debian package have an 
install dependency on the libconvert-asn1-perl Debian package.


Does that address this issue? If so, the bug should be closed.

Adam Lewenberg

Bug#949312: txsocksx: should this package be removed?

[Sandro Tosi]

On Fri, Feb 7, 2020 at 6:37 AM Adrian Bunk  wrote:
>
> On Thu, Feb 06, 2020 at 09:20:31PM -0500, Sandro Tosi wrote:
> > On Sun, Feb 2, 2020 at 6:51 AM Adrian Bunk  wrote:
> > >
> > > On Tue, Jan 28, 2020 at 04:06:28PM -0500, Sandro Tosi wrote:
> > > >...
> > > > python-txsocksx -> foolscap -> tahoe-lafs
> > > >
> > > > both foolscap and tahoe-lafs were removed from testing, so to my
> > > > script python-txsocksx appears as a leaf package (as its removal wont
> > > > break already broken/RC packages not in testing). not sure what we
> > > > want to do here, none of the 2 other packages will get fix anytime
> > > > soon and may get removed from debian entirely at some point.
> > > >...
> > >
> > > The latter statement is not true.
> > >
> > > Both tahoe-lafs and foolscap have substantial upstream activities
> > > towards Python 3 porting,
> >
> > my statement says "none of the 2 other packages will get fix anytime
> > soon and may get removed from debian entirely at some point" -- what
> > do you find un-true about it?
> >
> > i did not say those projects python3 port is not being worked on, but
> > i say that they are not close to finishing it, which includes both
> > porting the code *and* testing it and finally release a version that
> > has the python3 port.
>
> To me it looks likely to be finished in time for the bullseye freeze.

that'd be great, so they could be easily re-introduced in Debian once
they are ready.

> > for tahoe-lafs the effort is tracked at
> > https://tahoe-lafs.org/trac/tahoe-lafs/milestone/Support%20Python%203
> > which is currently marked at 89% completed; it was marked to be
> > completed by Dec 1, 2019, so they are 2 months behind their own
> > schedule (again, no blaming, just stating facts)
> >...
>
> You are pushing strongly for the removal of a package where upstream is

"pushing strongly"? I opened a bug against a package that's not
actively maintained upstream, waited a week (without any objection or
reply), and then reassigned it to ftp.d.o.

It may be quicker than usual Debian processes, but definitely not "strongly"

> working hard on Python 3 porting which is already 89% completed.
> (no blaming, just stating facts)

i'm afraid you got facts mixed up: i asked for the removal of
txsocksx, while it's tahoe-lafs port that's at 89% completion.

Please also consider this: right now, txsocksx has no python3 support;
so either the new port of tahoe-lafs to python3 has removed the
dependency on txsocksx or they are gonna have to wait for a port to be
available. In any case, txsocksx can be removed right now and
reintroduced when ported to python3 (or even never, if that wont
happen)

> It has happened that a removal bug was filed for a Python2 using package
> that was executed by the ftp team despite objection from the Debian 
> maintainer.
> (again, no blaming, just stating facts)

is this the case? according to PTS you're not part of the
maintainers/uploaders for txsocksx, tahoe-lafs or foolscap, and to my
knowledge none of them objected here. What am i missing?

> For many maintainers the approaching bullseye freeze is the deadline
> when they get all their packages into shape. Some people have enough
> spare time to work on Debian continuously, others don't.

and that's why there are people helping out, what's your point here?

> Many upstream developers also have priorities that can make it a
> challenge to find the time to do a proper conversion to Python 3, and
> made it lower priority when the conversion didn't bring any benefits.
> (again, no blaming, just stating facts)

right, but according to https://www.python.org/doc/sunset-python-2/
there has been plenty of time to migrate to python3, so i do
understand the human nature to procrastinate until the very last
moment (i do that all the time!) but that moment is now. It's also a
good indication if that upstream project is still maintained or not,
which consequently allow Debian to drop such projects, which i believe
is the case for txsocksx.

> Removal from testing is not really problematic, but removal from Debian
> is something that should not be done too aggressively.

are you referring to this specific example or any other of *my*
activities towards the py2removal effort? i dont see how this removal
request is aggressive.

just realize removing txsocksx will allow `src:parsley` to drop its
python2 support, since it's the only remaining rdep.

> > > the reasonable way forward would be to close
> > > this RM bug and watch how it all will get resolved in a few months with
> > > new upstream versions.
> >
> > We've been known the end of python2 support would be in 2020 since
> > years, i'm not sure it's fair for the projects that took the time
> > earlier and to the debian maintainers to ask to keep supporting
> > python2 packages for (relatively) old software for additional *few months*.
> >...
>
> What always strikes me as weird is the py2keep option, why are you
> offering that some packages can use Python 2.7 

Bug#950822: systemd-sysusers hangs if nis is enabled in a systemd-nspawn container

[Ryutaroh Matsumoto]

Control: tags -1 + fixed - moreinfo
Control: retitle -1 Fix found: systemd-sysusers hangs if nis is
enabled in a systemd-nspawn container

I found a solution (or a workaround).

The problem is that
(1) systemd-sysusers  tries to use Sun RPC (TCP connection to 127.0.0.1:111)
  in a nis enabled container.
(2) at that time, rpcbind.socket is ready (by systemd), and
(3) rpcbind.service is not ready, because rpcbind.service depends on
  systemd-sysusers.service.
(4) Then systemd-sysusers communication to 127.0.0.1:111 get stuck.

When I made

[Unit]
Before=rpcbind.socket
as /etc/systemd/system/systemd-sysusers.service.d/my.conf

OR

[Unit]
After=systemd-sysusers.service
as /etc/systemd/system/rpcbind.socket.d/my.conf

Then the problem goes away!!!

Anyway, the current dependency
rpcbind.socket -> systemd-sysusers.service -> rpcbind.service
looks nonsense.

The remaining problem is where the above nonsense order of
dependency should be fixed, rpcbind Debian package or the systemd
upstream...

Best regards, Ryutaroh

Bug#942345:

[wai phyoe]

Bug#397724: heimdal-kdc: ipropd-slave dies when master goes away

[A. Lewenberg]

On Thu, 09 Nov 2006 01:42:46 +0100 Peter Palfrader  
wrote:

Package: heimdal-kdc
Version: 0.7.2.dfsg.1-5
Severity: normal



This problem has long-been addressed. This bug should be closed.

Adam Lewenberg


Hi,

the ipropd-slave process exits when it either cannot connect to the
master, or when the master goes away.

The slave probably should continue to run in either case, trying to
(re)establish a connection every minute or so.
--
Peter

Bug#950859: cegui-mk2: FTBFS with boost171 and new cmake and symbol changes

[Dimitri John Ledkov]

Yes there is a way.

You can provide libcegui-mk2-x.y.z-boost171
And then rewrite shlib deps to require a dep on libcegui-mk2-x.y.z-boost171
( >= X.y.z)

That way things that build against this new lib get the right dep, and
whenever cegui is NMUed for new boost Abi autochanges.

However, when you switch to this scheme either the library package needs to
change name, or you need to declare breaks on your reverse deps, to prevent
partial upgrade

Boost does similar to encode python versions and icu. And many other deb
languages do similar things like ocaml, gch, etc.

On Sat, 8 Feb 2020, 17:48 Olek Wojnar,  wrote:

> Hi Dimitri,
>
> Thanks for the bug report, and thanks for the patch!
>
> On 2/7/20 8:49 AM, Dimitri John Ledkov wrote:
> > Package: cegui-mk2
> > Version: 0.8.7-5
> > Severity: serious
> > Tags: patch
> > Justification: ftbfs
> >
> > Dear Maintainer,
> >
> > cegui-mk2 ftbfs with new cmake & boost1.71 due to change in cmake
> > policy w.r.t. boost version detection (it is now more normal). See patch
> attached.
>
> Thank goodness for them making it more normal! I was not a fan of that
> old system.
>
> > I am currently in process of migrating to boost1.71 in Ubuntu, which
> > has not started yet in Debian but is upcoming.
> >
> > When built against boost1.71 symbols are dropped and changed. It seems
> > as if cegui-mk2 re-exports boost symbols, and thus boost abi change in
> > templates leakes in the change of cegui-mk2 libraries ABI change.
> >
> > How should this be handled?
> >
> > Is there a new upstream release of cegui that we can package in
> > experimental, always built against boost1.71 with new symbols?
>
> No, upstream has not done a new release in a while. Although I can (and
> plan to) package the current version in experimental once boost1.71
> lands there. Since I don't follow Boost, a notification in this bug
> report would be appreciated.
>
> > Or shall i just blindly update the symbols file, rebuild ember and
> > hope for the best?
> >
> > How was this handled in cegui-mk2 before, when boost changed without
> > cegui-mk2 new upstream releases?
>
> I've only recently taken a more-active role in maintaining this package.
> I think I previously only submitted a few NMUs. But, I believe that what
> you listed is exactly what happened. I know I saw that with Ember (which
> I *have* been maintaining for a while).
>
> If you have any suggestions for a better, less-reactive, way forward on
> this I'm certainly open to it!
>
> > I would like to avoid diverging ABI between ubuntu & debian here.
>
> Absolutely! I'm a big fan of keeping Debian and Ubuntu closely
> synchronized.
>
> -Olek
>
>
>

Bug#717660: seems like a bug in kadmind

[A. Lewenberg]

On Mon, 11 Nov 2013 11:25:00 +1100 Brian May 
 wrote:

On 11 November 2013 04:57, Russ Allbery  wrote:

> I think the Debian packagers (of which I'm not one, to be clear; I just
> watch the bug traffic since we use Heimdal extensively) packaged a
> development snapshot in anticipation of the 1.6 release, which was
> supposed to be forthcoming.  I believe it has some features that are
> needed/desirable for Samba.  Unfortunately, various bugs were found in the
> development branch and 1.6 never stabilized enough to be released.


Yes, that matches my understanding too.


This bug should be closed.

Adam Lewenberg
deb...@lewenberg.com



--
Brian May 

Bug#940926: Xorg logs

[Andreas Beckmann]

Hi,

On 08/02/2020 10.29, TarotApprentice wrote:
> Buster doesn't appear to have a nvidia glx driver.

This sounds more like the glx alternative is set to mesa-diverted
instead of nvidia. And then of course the driver links are not in place.
(You can use update-glx to change the settings.)

Please run
  reportbug -N 940926
on the problematic machine to collect a lot of helpful information.

Do you have the nvidia-driver meta-package installed?


Andreas

PS: looking at your name, I'm always tempted to flag your emails as spam

Bug#939181: cycle: should it be RM'd ?

[Ana Guerrero Lopez]

On Tue, Jan 28, 2020 at 06:06:59PM +0100, Andreas Tille wrote:
> On Tue, Jan 28, 2020 at 10:56:23AM -0500, Scott Talbert wrote:
> > Is there any hope for a Python 3 port of cycle, or should it just be RM'd?
> 
> Ana, could you please have a last word about this?
>
Thanks Andreas.

I haven't given up yet in a Python 3 port, but if cycle must be removed for the
sake of removing Python 2, just do it. It's always possible to re-introduce
the package later.

Cheers,
Ana

Bug#950972: press: Broken/mangled space characters in 10.3 and 9.12 point release announcements

[Salvatore Bonaccorso]

Hi Ana,

On Sat, Feb 08, 2020 at 10:49:24PM +0100, Ana Guerrero Lopez wrote:
> On Sat, Feb 08, 2020 at 10:41:47PM +0100, Salvatore Bonaccorso wrote:
> > Package: press
> > Severity: normal
> > 
> > Hi
> > 
> > Just noticed that in the release announcement for the 10.3[0] and
> > 9.12[1] announcements, there seem to be broken spaces in the generated
> > table between the source package names and the reference markers.
> > 
> > Many thanks for your work!
> > 
> > Regards,
> > Salvatore
> > 
> > [0] https://lists.debian.org/debian-announce/2020/msg0.html
> > [1] https://lists.debian.org/debian-announce/2020/msg1.html
> 
> These mails are generated from the website using this script:
> https://salsa.debian.org/publicity-team/publicity/blob/master/dpn/scripts/DPNhtml2mail.pl
> 
> That is adding an extra unicode character.
> 
> A perl coder help would be very appreciated :-)

Just checked quickly, in the script there is a U+00A0 (0xc2 0xa0) which seem to
cause the issue. If I replace the space with "normal" space U+0020, then the
issue disapear. The issue at least is triggerable as well with older issues not
only the recent 2020 ones.

Hexdump of current script:

1800  65 6e 74 20 3d 20 27 27  3b 0a 6d 79 20 24 6c 69  |ent = '';.my $li|
1810  6e 6b 5f 66 6f 72 6d 61  74 20 20 20 20 20 20 20  |nk_format   |
1820  3d 20 27 c2 a0 5b 25 64  5d 27 3b 0a 6d 79 20 24  |= '..[%d]';.my $|
1830  6c 69 73 74 5f 6c 69 6e  6b 20 20 20 20 20 20 20  |list_link   |
1840  20 20 3d 20 22 25 35 64  3a 20 22 3b 0a 0a 69 66  |  = "%5d: ";..if|

and patches replacing the space:

1800  65 6e 74 20 3d 20 27 27  3b 0a 6d 79 20 24 6c 69  |ent = '';.my $li|
1810  6e 6b 5f 66 6f 72 6d 61  74 20 20 20 20 20 20 20  |nk_format   |
1820  3d 20 27 20 5b 25 64 5d  27 3b 0a 6d 79 20 24 6c  |= ' [%d]';.my $l|
1830  69 73 74 5f 6c 69 6e 6b  20 20 20 20 20 20 20 20  |ist_link|
1840  20 3d 20 22 25 35 64 3a  20 22 3b 0a 0a 69 66 20  | = "%5d: ";..if |

I do not know if this is the right solution, but attached patch with the above.

Regards,
Salvatore
>From 5e3ad5df1c47db302914673edf6314b0c3e008c9 Mon Sep 17 00:00:00 2001
From: Salvatore Bonaccorso 
Date: Sat, 8 Feb 2020 23:28:55 +0100
Subject: [PATCH] Replace NO-BREAK SPACE (U+00A0) with SPACE (U+0020) for
 link_format

---
 dpn/scripts/DPNhtml2mail.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dpn/scripts/DPNhtml2mail.pl b/dpn/scripts/DPNhtml2mail.pl
index 8188dc5bf5d0..2fc8abb4345b 100755
--- a/dpn/scripts/DPNhtml2mail.pl
+++ b/dpn/scripts/DPNhtml2mail.pl
@@ -192,7 +192,7 @@ my $project_name = 'The Debian Project';
 my $openquote = ' "';
 my $closequote = '" ';
 my $first_line_indent = '';
-my $link_format   = ' [%d]';
+my $link_format   = ' [%d]';
 my $list_link = "%5d: ";
 
 if ($opts{l} eq "fr") {
-- 
2.25.0

Bug#950972: press: Broken/mangled space characters in 10.3 and 9.12 point release announcements

[Ana Guerrero Lopez]

On Sat, Feb 08, 2020 at 10:41:47PM +0100, Salvatore Bonaccorso wrote:
> Package: press
> Severity: normal
> 
> Hi
> 
> Just noticed that in the release announcement for the 10.3[0] and
> 9.12[1] announcements, there seem to be broken spaces in the generated
> table between the source package names and the reference markers.
> 
> Many thanks for your work!
> 
> Regards,
> Salvatore
> 
> [0] https://lists.debian.org/debian-announce/2020/msg0.html
> [1] https://lists.debian.org/debian-announce/2020/msg1.html

These mails are generated from the website using this script:
https://salsa.debian.org/publicity-team/publicity/blob/master/dpn/scripts/DPNhtml2mail.pl

That is adding an extra unicode character.

A perl coder help would be very appreciated :-)

Cheers,
Ana

Bug#950972: press: Broken/mangled space characters in 10.3 and 9.12 point release announcements

[Salvatore Bonaccorso]

Package: press
Severity: normal

Hi

Just noticed that in the release announcement for the 10.3[0] and
9.12[1] announcements, there seem to be broken spaces in the generated
table between the source package names and the reference markers.

Many thanks for your work!

Regards,
Salvatore

[0] https://lists.debian.org/debian-announce/2020/msg0.html
[1] https://lists.debian.org/debian-announce/2020/msg1.html

Bug#950300: mod-gnutls: diff for NMU version 0.9.0-1.1

[Adrian Bunk]

Control: tags 950300 + patch
Control: tags 950300 + pending
Control: tags 950301 + patch
Control: tags 950301 + pending

Dear maintainer,

I've prepared an NMU for mod-gnutls (versioned as 0.9.0-1.1) and 
uploaded it to DELAYED/15. Please feel free to tell me if I should 
cancel it.

My main interest is fixing #950300 in buster and stretch afterwards,
upstream release 0.10.0 would be a superset of my changes.

cu
Adrian
diff -Nru mod-gnutls-0.9.0/debian/changelog mod-gnutls-0.9.0/debian/changelog
--- mod-gnutls-0.9.0/debian/changelog	2019-02-08 23:27:06.0 +0200
+++ mod-gnutls-0.9.0/debian/changelog	2020-02-08 23:14:39.0 +0200
@@ -1,3 +1,13 @@
+mod-gnutls (0.9.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Backported patches to fix test failures with the
+apache CVE-2019-10092 fix. (Closes: #950300)
+  * Disable a test that fails with GnuTLS >= 3.6.11. (Closes: #950301)
+  * Backported a fix for a possible segfault on failed TLS handshake.
+
+ -- Adrian Bunk   Sat, 08 Feb 2020 23:14:39 +0200
+
 mod-gnutls (0.9.0-1) unstable; urgency=medium
 
   [ Fiona Klute ]
diff -Nru mod-gnutls-0.9.0/debian/patches/0001-Fix-possible-segfault-NULL-pointer-dereference-on-fa.patch mod-gnutls-0.9.0/debian/patches/0001-Fix-possible-segfault-NULL-pointer-dereference-on-fa.patch
--- mod-gnutls-0.9.0/debian/patches/0001-Fix-possible-segfault-NULL-pointer-dereference-on-fa.patch	1970-01-01 02:00:00.0 +0200
+++ mod-gnutls-0.9.0/debian/patches/0001-Fix-possible-segfault-NULL-pointer-dereference-on-fa.patch	2020-02-08 17:20:28.0 +0200
@@ -0,0 +1,40 @@
+From dcec2098a29e43d93efe6b0b6150e35ef198a1eb Mon Sep 17 00:00:00 2001
+From: Fiona Klute 
+Date: Thu, 28 Nov 2019 10:42:46 +0100
+Subject: Fix possible segfault (NULL pointer dereference) on failed TLS
+ handshake
+
+Calling ssl_var_lookup() after a failed handshake could lead to GnuTLS
+session information functions being called on a NULL session pointer,
+leading to segfault. I observed this in a case where mod_http2 was
+trying to check the negotiated TLS version after the client rejected
+the server certificate.
+---
+ src/mod_gnutls.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/mod_gnutls.c b/src/mod_gnutls.c
+index d6edffc..b667a9c 100644
+--- a/src/mod_gnutls.c
 b/src/mod_gnutls.c
+@@ -2,7 +2,7 @@
+  *  Copyright 2004-2005 Paul Querna
+  *  Copyright 2008, 2014 Nikos Mavrogiannopoulos
+  *  Copyright 2011 Dash Shendy
+- *  Copyright 2015-2018 Fiona Klute
++ *  Copyright 2015-2019 Fiona Klute
+  *
+  *  Licensed under the Apache License, Version 2.0 (the "License");
+  *  you may not use this file except in compliance with the License.
+@@ -178,7 +178,7 @@ char* ssl_var_lookup(apr_pool_t *p, server_rec *s __attribute__((unused)),
+ mgs_handle_t *ctxt = get_effective_gnutls_ctxt(c);
+ 
+ /* TLS parameters are empty if there is no session */
+-if (ctxt == NULL || ctxt->c == NULL)
++if (ctxt == NULL || ctxt->c == NULL || ctxt->session == NULL)
+ return NULL;
+ 
+ if (strcmp(var, "SSL_PROTOCOL") == 0)
+-- 
+2.20.1
+
diff -Nru mod-gnutls-0.9.0/debian/patches/0001-Test-suite-ignore-Content-Length-header.patch mod-gnutls-0.9.0/debian/patches/0001-Test-suite-ignore-Content-Length-header.patch
--- mod-gnutls-0.9.0/debian/patches/0001-Test-suite-ignore-Content-Length-header.patch	1970-01-01 02:00:00.0 +0200
+++ mod-gnutls-0.9.0/debian/patches/0001-Test-suite-ignore-Content-Length-header.patch	2020-02-08 17:20:44.0 +0200
@@ -0,0 +1,291 @@
+From 20a20dfab4f9b854228ae1999b912dcab7f8c260 Mon Sep 17 00:00:00 2001
+From: Krista Karppinen 
+Date: Fri, 1 Nov 2019 23:07:20 +0200
+Subject: Test suite: ignore "Content-Length" header
+
+Do not check the returned "Content-Length" header value when running the
+tests, as long as it's valid. This will allow for more flexibility in
+matching the content in the future.
+---
+ test/runtests| 5 +++--
+ test/tests/00_basic/output   | 1 -
+ test/tests/01_serverwide_priorities/output   | 1 -
+ test/tests/03_cachetimeout_in_vhost/output   | 1 -
+ test/tests/04_basic_nosni/output | 1 -
+ test/tests/06_verify_sni_a/output| 1 -
+ test/tests/07_verify_sni_b/output| 1 -
+ test/tests/08_verify_no_sni_fallback_to_first_vhost/output   | 1 -
+ test/tests/10_basic_client_verification/output   | 1 -
+ test/tests/14_resume_session/output  | 1 -
+ test/tests/15_basic_msva/output  | 1 -
+ test/tests/19_TLS_reverse_proxy/output   | 1 -
+ test/tests/20_TLS_reverse_proxy_client_auth/output   | 1 -
+ test/tests/21_TLS_reverse_proxy_wrong_cert/output| 1 -
+ test/tests/22_TLS_reverse_proxy_crl_revoke/output| 1 -
+ 

Bug#950221: Taking over natsort into Debian Python Modules Team (Was: natsort 6.0 doesn't support Python 3.8)

[Agustin Henze]

Hi Andreas, that would be really awesome! If you have time go ahead :).

Thanks,

On 2/8/20 6:19 AM, Andreas Tille wrote:
> Hi Agustin,
>
> Matthias Klose wrote
>> natsort 6.0 doesn't support Python 3.8, 6.2 is the first version supporting 
>> it.
>> There's also a 7.0 release.
> I wonde whether you agree to move natsort to Debian Python Modules team
> to support simple team uploads.  Seems the solution would be to upgrade
> natsort to a later version.
>
> Kind regards
>
>Andreas.
>
-- 
TiN

Bug#830307: Re virt-manager: Virt-manager uses qemu-system-i386 /usr/lib/xen/bin

[Dave Hill]

Further to my previous message, it appears that the nominal architecture 
makes no difference to qemu, as it emulates no CPU instructions: 
https://wiki.xen.org/wiki/QEMU_Upstream#Why_is_qemu-system-i386_used_even_on_x86_64_and_even_non-x86.3F


The qemu-system-i386 emulator is always used, regardless of the 
architecture being installed. So, while confusing, virt-manager's 
emulator specification is actually correct.

Bug#950971: firmware-misc-nonfree: warnings about missing firmware while updating initramfs

[Alexander Kernozhitsky]

Package: firmware-misc-nonfree
Version: 20190717-2
Severity: normal

Hello,

while invoking update-initramfs -u, I always get a bunch of warnings:

update-initramfs: Generating /boot/initrd.img-5.4.0-3-amd64
W: Possible missing firmware /lib/firmware/i915/icl_dmc_ver1_07.bin for module
i915
W: Possible missing firmware /lib/firmware/i915/tgl_dmc_ver2_04.bin for module
i915
W: Possible missing firmware /lib/firmware/i915/bxt_huc_ver01_8_2893.bin for
module i915

Please include the missing firmware.



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

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

firmware-misc-nonfree depends on no packages.

firmware-misc-nonfree recommends no packages.

Versions of packages firmware-misc-nonfree suggests:
ii  initramfs-tools  0.136

-- no debconf information

Bug#947744: installation-reports: Debian Live Testing LXQt + nonfree - install fails with: "Bad unsquash configuration" Date: Wed, 1 Jan 2020 04:54:06 +0000 (UTC)

[Steve McIntyre]

Hey Scott,

On Sat, Feb 08, 2020 at 02:53:41AM +, scott092...@aol.com wrote:
>>I'm wondering exactly what the effect of "with persistence" is, for example. 
>
>Persistence is a very useful feature, whereby a certain amount of storage is 
>reserved
>on the media that is used when a change is made from the .iso , so that when 
>it is again
>booted, that change is still there.

Oh, sorry. I wasn't clear enough. I know what persistence *is*, I was
more wondering exactly how mkusb modifies an image to *enable*
persistence. If it's blindly modifying the filesystems included in an
image, that could cause all kinds of problems. :-/

...

>>Could you try again without that and see if that makes a difference for you, 
>>please?
>Yes... well... booting the live-usb without persistence solved the problem.
>
>I can only speculate, that Calamares (or something Calamares calls) refers to
>/run/live/medium/live/filesystem.squashfs
>two different ways in two (or more) different locations of the code.
>Without persistence, the two ways point to the same place, and all is good.
>With persistence, the two ways point to two different places, and it fails.

I'm thinking that it's more likely that mkusb is doing something odd
to the image, I'll be honest. I don't have time to dig into it right
now (prepping the latest buster point release this weekend!), but
AFAICS it's a tool written to work primarily with Ubuntu images?
Ubuntu and Debian live images are really quite different beasts and it
*may* be making invalid assumptions about how live images work.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html

Bug#950970: fonts-noto-color-emoji: Browsers crash while interacting with emoji.

[Apostolis Xekoukoulotakis]

Package: fonts-noto-color-emoji
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

   I upgraded to the buster release.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

   When I click on a tweet that contains an emoji,

   * What was the outcome of this action?

   the complete monitor is blacked out and after a few seconds, I am
   returned in the initial login of my system, probably this means that
   the X server has crashed.

   * What outcome did you expect instead?


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


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

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

Bug#950968: install gkrellm.pc to a multiarch location

[Helmut Grohne]

Package: gkrellm
Version: 2.3.10-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:gkrelluim

gkrelluim fails to cross build from source, because it cannot find
gkrellm.pc. During cross compilation, pkg-config only searches
/usr/share/pkgconfig and /usr/lib//pkgconfig. It does not
search /usr/lib/pkgconfig. Thus gkrellm.pc needs to be moved. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru gkrellm-2.3.10/debian/changelog 
gkrellm-2.3.10/debian/changelog
--- gkrellm-2.3.10/debian/changelog 2018-05-14 01:16:12.0 +0200
+++ gkrellm-2.3.10/debian/changelog 2020-02-08 20:49:05.0 +0100
@@ -1,3 +1,10 @@
+gkrellm (2.3.10-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install gkrellm.pc to a multiarch location. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 08 Feb 2020 20:49:05 +0100
+
 gkrellm (2.3.10-2) unstable; urgency=medium
 
   * debian/control
diff --minimal -Nru gkrellm-2.3.10/debian/gkrellm.install 
gkrellm-2.3.10/debian/gkrellm.install
--- gkrellm-2.3.10/debian/gkrellm.install   2018-05-14 01:16:12.0 
+0200
+++ gkrellm-2.3.10/debian/gkrellm.install   2020-02-08 20:49:05.0 
+0100
@@ -2,7 +2,7 @@
 debian/tmp/usr/bin/gkrellm /usr/bin/
 debian/tmp/usr/share/man/man1/gkrellm.1 /usr/share/man/man1/
 debian/tmp/usr/share/locale/* /usr/share/locale/
-debian/tmp/usr/lib/pkgconfig/* /usr/lib/pkgconfig/
+usr/lib/*/pkgconfig/*
 debian/tmp/usr/include/gkrellm2/gkrellm.h /usr/include/gkrellm2/
 debian/tmp/usr/include/gkrellm2/log.h /usr/include/gkrellm2/
 debian/tmp/usr/include/gkrellm2/gkrellm-public-proto.h /usr/include/gkrellm2
diff --minimal -Nru gkrellm-2.3.10/debian/rules gkrellm-2.3.10/debian/rules
--- gkrellm-2.3.10/debian/rules 2018-05-14 01:16:12.0 +0200
+++ gkrellm-2.3.10/debian/rules 2020-02-08 20:49:04.0 +0100
@@ -1,5 +1,9 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
+
+MAKE_VARS=PREFIX=/usr 
'PKGCONFIGDIR=$$(INSTALLROOT)/lib/$(DEB_HOST_MULTIARCH)/pkgconfig'
+
 %:
dh $@
 
@@ -7,10 +11,10 @@
dh_installinit -u"defaults 21"
 
 override_dh_auto_build:
-   dh_auto_build -- PREFIX=/usr without-ssl=1
+   dh_auto_build -- $(MAKE_VARS) without-ssl=1
 
 override_dh_auto_install:
-   $(MAKE) install DESTDIR=`pwd`/debian/tmp PREFIX=/usr
+   $(MAKE) install DESTDIR=`pwd`/debian/tmp $(MAKE_VARS)
 
 override_dh_clean:
dh_clean

Bug#950969: stringtie FTCBFS: uses the build architecture compiler as linker

[Helmut Grohne]

Source: stringtie
Version: 2.1.1+ds-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

stringtie fails to cross build from source, because it uses the build
architecture compiler as linker. This happens, because stringtie's
Makefile uses the non-standard variable LINKER and dh_auto_build doesn't
supply it. The attached patch passes it from dh_auto_build. An
alternative would be defaulting its value to $(CXX) as an upstream
improvement.

Still then, stringtie fails to cross build, because it uses help2man.
There are no good solutions to this problem. Options include:
 * Stop using help2man. Write a real manual page.
 * Move the manual page to an Architecture: all package.
 * Generate the manual page at upload time instead of build time.
 * Build twice, once for help2man and once for real.

None of these is particularly attractive. So let's just fix the LINKER
part here. Please close this bug when addressing that part.

Helmut
diff --minimal -Nru stringtie-2.1.1+ds/debian/changelog 
stringtie-2.1.1+ds/debian/changelog
--- stringtie-2.1.1+ds/debian/changelog 2020-02-07 16:33:31.0 +0100
+++ stringtie-2.1.1+ds/debian/changelog 2020-02-08 16:54:59.0 +0100
@@ -1,3 +1,10 @@
+stringtie (2.1.1+ds-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Improve cross building: Pass LINKER. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 08 Feb 2020 16:54:59 +0100
+
 stringtie (2.1.1+ds-1) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru stringtie-2.1.1+ds/debian/rules 
stringtie-2.1.1+ds/debian/rules
--- stringtie-2.1.1+ds/debian/rules 2020-02-07 16:24:51.0 +0100
+++ stringtie-2.1.1+ds/debian/rules 2020-02-08 16:54:58.0 +0100
@@ -10,6 +10,9 @@
 %:
dh $@
 
+override_dh_auto_build:
+   dh_auto_build -- 'LINKER=$$(CXX)'
+
 # Disabling tests, as they require network access. In future, a multiple
 # upstream tarball could be created to pull in the required test files.
 override_dh_auto_test:

Bug#950967: netty: CVE-2019-20445 CVE-2020-7238

[Salvatore Bonaccorso]

Source: netty
Version: 1:4.1.33-3
Severity: grave
Tags: security upstream
Forwarded: https://github.com/netty/netty/issues/9861

Hi,

The following vulnerabilities were published for netty.

CVE-2019-20445[0]:
| HttpObjectDecoder.java in Netty before 4.1.44 allows a Content-Length
| header to be accompanied by a second Content-Length header, or by a
| Transfer-Encoding header.


CVE-2020-7238[1]:
| Netty 4.1.43.Final allows HTTP Request Smuggling because it mishandles
| Transfer-Encoding whitespace (such as a [space]Transfer-
| Encoding:chunked line) and a later Content-Length header. This issue
| exists because of an incomplete fix for CVE-2019-16869.

Both appears to be fixed with the same fix upstream, as per [2].

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-20445
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-20445
[1] https://security-tracker.debian.org/tracker/CVE-2020-7238
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7238
[2] https://github.com/netty/netty/issues/9861

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#916605: HI

[David Kossi]

Please my dear i want to confirmed if you receive the last message i send
to you i am waiting to hear from you.

Bug#950966: netty: CVE-2019-20444

[Salvatore Bonaccorso]

Source: netty
Version: 1:4.1.33-3
Severity: grave
Tags: security upstream
Forwarded: https://github.com/netty/netty/issues/9866

Hi,

The following vulnerability was published for netty.

CVE-2019-20444[0]:
| HttpObjectDecoder.java in Netty before 4.1.44 allows an HTTP header
| that lacks a colon, which might be interpreted as a separate header
| with an incorrect syntax, or might be interpreted as an "invalid
| fold."


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-20444
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-20444
[1] https://github.com/netty/netty/issues/9866
[2] 
https://github.com/netty/netty/commit/a7c18d44b46e02dadfe3da225a06e5091f5f328e

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#950965: python3-popcon: /usr/bin/popcon broken after changes in module

[gregor herrmann]

Package: python3-popcon
Version: 2.0.1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

It looks like the (example?) script /usr/bin/popcon was not adjusted
to the changes of the module itself between 2.0.0 and 2.0.1.

Something like the following makes it output sane numbers again:

#v+
- --- unpacked/usr/lib/python3/dist-packages/popcon/__main__.py 2019-01-13 
14:19:57.0 +0100
+++ /usr/lib/python3/dist-packages/popcon/__main__.py   2020-02-08 
21:18:52.797787145 +0100
@@ -1,6 +1,6 @@
 import sys
 
- -from popcon import package
+from popcon.popcon import packages
 
 
 def main():
@@ -8,7 +8,7 @@
 raise RuntimeError('No package name given')
 pkg = sys.argv[1]
 print(pkg)
- -print(package(pkg))
+print(packages([pkg]))
 
 
#v-


Cheers,
gregor


-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl4/GGpfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qga04Q//atzp/9W9Ng83UZ3Y+8FNZZIaV1lgPU+mYjGIvhE2V2gyh8tvNUNqKGZn
eKNCCN+JhRL7rWzp36G3xl228mv+BzrqZbulMe6rMj7lxLfvCafiRAnBwcisLIMh
ROC1WISbQ6s9sXoy0Nc/L+ujgshJBfg80yNpSnzsT7IuAvlZ2D1Le21ivljzKtqm
OkYS2cHwqOQU/PMH6vKC7VTygkYErvpBnsHEITX8pVctbS7vuYyLSiJZwO+c4KE6
G2wNsb0jUIT1XmlNGbb+SumKZRoGfP4Lw6tFY65Ez9k/5DHlz080/x9hvNNrDr1C
ACxsDEfWxFUNaxWE3oDNiMybg0SOTYmJRjj2j9SF54iPpfDihvh/TfsLiprChcTp
pDEFH04yrONXVLhJJVhSI/2cfGdP8AYtaZzgywNbt+hR7Xg9Svdr9brzTJpAQMbi
g+L3/HcsPntgiR8KfnNe6O3eMvEKD+cX/Pc7keIhqIIm2DWHPyoDJKpZeJH1NQhc
hEb+maK6KwyiAOAyeIY00QCCq9QrEHJXmFw37F+4AJdurBnnmQaA+qy2Xoyq+VG4
jUOsLaJ58uqhtpTzyffwZ+ybIR+F2nAFVgbG1hKOP+UhpGO5ZKxcjh9u0nn3ExiU
7VGg8l+rOD4IQXfKqs3EYYNkmzzyeuHUnNLfOHrIYF0Rsf3L5ro=
=vBL5
-END PGP SIGNATURE-

Bug#950964: anki: Anki won't play sound, claims mpv is too old

[Alexander Batischev]

Package: anki
Version: 2.1.15+dfsg-1
Severity: normal

Dear Maintainer,

When I start Anki, it reports on the stdout:

mpv too old, reverting to mplayer

Then it starts fine, but when I review a card that contains audio, no 
sound is played, and an error box is shown instead:

Sound and video on cards will not function until mpv or mplayer is 
installed.

Indeed, I only have MPV installed.

If I install mplayer manually (2:1.3.0-8+b5 at the moment), it makes the 
error box go away, and audio plays fine. The message on stdout persists, 
though.

I understand this is probably a temporary problem, and it'll be fixed 
when a newer version of MPV hits Debian testing, but until then, please 
consider adding mplayer as a hard dependency of Anki.

Thanks!


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

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

Versions of packages anki depends on:
ii  libjs-jquery3.3.1~dfsg-3
ii  libjs-jquery-flot   0.8.3+dfsg-1
ii  libjs-jquery-ui 1.12.1+dfsg-5
ii  libjs-mathjax   2.7.4+dfsg-1
ii  libqt5core5a5.12.5+dfsg-8
ii  python3 3.7.5-3
ii  python3-bs4 4.8.2-1
ii  python3-decorator   4.3.0-1.1
ii  python3-distro  1.3.0-2
ii  python3-distutils   3.8.0-1
ii  python3-jsonschema  3.0.2-4
ii  python3-markdown3.1.1-2
ii  python3-pyaudio 0.2.11-1.1
ii  python3-pyqt5   5.14.1+dfsg-2
ii  python3-pyqt5.qtwebchannel  5.14.1+dfsg-2
ii  python3-pyqt5.qtwebengine   5.14.0-1
ii  python3-requests2.22.0-2
ii  python3-send2trash  1.5.0-2

Versions of packages anki recommends:
ii  python3-matplotlib  3.1.2-1

Versions of packages anki suggests:
pn  dvipng  
pn  lame
ii  mpv 0.32.0-1

-- debconf-show failed

Bug#950723: debhelper: dh_installsystemd doesn't install template unit files by default

[Niels Thykier]

Badreddin Aboubakr:
> The packaging is available on
> https://salsa.debian.org/go-team/packages/golang-github-hashicorp-serf/
> Step to reproduce :
> * i took serf from this branch (0.8.1+git20171021.c20a0b1~ds1-4~bpo9+1) as
> starting point
> * rename `serf.service` inside debian/ to `serf@.service`
>  * in `debian/rules` i added `override_dh_installinit:` so initscript won't
> get installed
> 
> Thanks a lot
> 
> Best,
> Badr
> 
> [...]

Hmm, that is a backport version.  With normal Debian build tools, it
would be built with debhelper 10.2.5, which does not have (a finished)
dh_installsystemd AFAIR and it uses compat 9 where dh_installsystemd is
not run by default either.

 * Which version of debhelper is used when you built serf?
 * Are you using compat 9?
 * What is the output of "dh binary --no-act" when run from the source
   root with the version of debhelper?


Thanks,
~Niels

Bug#950723: debhelper: dh_installsystemd doesn't install template unit files by default

[Badreddin Aboubakr]

The packaging is available on
https://salsa.debian.org/go-team/packages/golang-github-hashicorp-serf/
Step to reproduce :
* i took serf from this branch (0.8.1+git20171021.c20a0b1~ds1-4~bpo9+1) as
starting point
* rename `serf.service` inside debian/ to `serf@.service`
 * in `debian/rules` i added `override_dh_installinit:` so initscript won't
get installed

Thanks a lot

Best,
Badr

On Sat, Feb 8, 2020 at 7:45 PM Niels Thykier  wrote:

> Badreddin Aboubakr:
> > Hey Niels,
> >
> > thanks for replying.
> > I tired removing the arguments given
> > to dh_installsystemd, however in this case serf@.service did not get
> copied
> > Wich was the scope of thia bug report
> > I did add the argument as workaround to let dh_installsystemd copy serf@
> > .service
> >
> > Best,
> >
> > [...]
>
> That is interesting; I cannot reproduce this behaviour you are
> describing when I call dh_installsystemd (albeit with different package
> names, but that should not be the deciding factor).
>
> I may have to look at serf at some point to see what is going on.  Is
> the packaging available somewhere publicly?
>
> Thanks,
> ~Niels
>
>

-- 

Badreddin Aboubakr


GAPS (IONOS Cloud)

1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany
Phone:
E-mail: badreddin.aboub...@cloud.ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498

Vorstand: Dr. Christian Böing, Hüseyin Dogan, Dr. Martin Endreß,
Hans-Henning Kettler, Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke

Member of United Internet

Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen
enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese
E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den Absender und
vernichten Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten
ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt
auf welche Weise auch immer zu verwenden.

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient of this e-mail, you are hereby notified that
saving, distribution or use of the content of this e-mail in any way is
prohibited. If you have received this e-mail in error, please notify the
sender and delete the e-mail.

Bug#950963: FTBFS: Could not find gem 'sqlite3 (~> 1.3.8)' in any of the gem sources listed in your Gemfile

[Antonio Terceiro]

Source: ruby-joiner
Version: 0.4.2-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

ruby-sqlite3 was recently updated in unstable, and now ruby-joiner fails
to build with:

Could not find gem 'sqlite3 (~> 1.3.8)' in any of the gem sources listed in 
your Gemfile.

Note that ~> 1.3.8 is too strict a dependency. Please consider chancing
it to ~> 1.3, and possibly send a patch upstream.

See attached the full build log.

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


ruby-joiner_amd64.build.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#950962: FTBFS: "JSON blows up on circular references" test fails

[Antonio Terceiro]

Source: ruby-sentry-raven
Version: 2.9.0-1
Severity: serious
Tags: ftbfs bullseye sid
Justification: fails to build from source

Failures:

  1) JSON blows up on circular references
 Failure/Error: expect { JSON.dump(data) }.to raise_error(SystemStackError)
   expected SystemStackError, got # with backtrace:
 # ./spec/raven/json_spec.rb:75:in `block (2 levels) in '

Find atteched the full build log

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


ruby-sentry-raven_amd64.build.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#950894: Acknowledgement (mawk: numeric comparison on 'sub()' resulted ${n} vars does not work properly)

[Stephen Dowdy]

On 2/7/20 2:15 PM, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 950894: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950894.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  Boyuan Yang 

If you wish to submit further information on this problem, please
send it to 950...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.



Considered this closed.  Communication on 'bug-g...@gnu.org' indicates that 'sub()' 
modifies a 'strnum' to a 'string' for $1, and that it is no longer considered "user 
input", but a string constant, and thus comparisons will be done as string only.

Ref: https://www.gnu.org/software/gawk/manual/html_node/Variable-Typing.html

thanks,
--stephen

Bug#937791: Blocked on reverse dependencies

[Sandro Tosi]

> Is it possible to remove the AUTORM tag until this is done, or should we
> let it get deleted and upload a new python3-gmpy package after that?

it will just be removed from testing, which is fine: it will go back
in when the python3 package hits unstable and no more RC bugs pop up

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

Bug#950205: python-gmpy2 fails autopkg tests with python3.8

[Martin Kelly]

On 1/29/20 10:39 PM, Matthias Klose wrote:

Package: src:python-gmpy2
Version: 2.1.0~b3-3
Severity: important
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: python3.8

python-gmpy2 fails autopkg tests with python3.8:

autopkgtest [09:06:22]: test command1:  - - - - - - - - - - results - - - - - -
- - - -
command1 FAIL stderr: :1:
DeprecationWarning: an integer is required (got type mpfr).  Implicit conversion
to integers using __int__ is deprecated, and may be removed in a future version
of Python.
autopkgtest [09:06:22]: test command1:  - - - - - - - - - - stderr - - - - - - -
- - -
:1: DeprecationWarning: an integer is required
(got type mpfr).  Implicit conversion to integers using __int__ is deprecated,
and may be removed in a future version of Python.
   gmpy2.factorial(r)
autopkgtest [09:06:22]:  summary
command1 FAIL stderr: :1:
DeprecationWarning: an integer is required (got type mpfr).  Implicit conversion
to integers using __int__ is deprecated, and may be removed in a future version
of Python.
Exit request sent.



Adding the maintainer, Case Van Horsen. Case, it looks like the 
following autopkgtest command is failing with Python 3.8. The output is 
above. You should be able to repro by running:


python3 test/runtests.py

as this is the command that the autopkgtest runs.

I have also opened a bug report on Github for this:
https://github.com/aleaxit/gmpy/issues/259

Bug#937791: Blocked on reverse dependencies

[Martin Kelly]

On Sat, 8 Feb 2020 10:55:23 -0800 Martin Kelly  
wrote:

On 2/2/20 8:39 PM, Sandro Tosi wrote:
> should we remove this package then? or do you want to generate a python3-gmpy?
> 

I didn't realize, but it looks like this package actually does support 
Python 3. I had assumed we would let this package die when Python 2 
dies, since the package is dead upstream since 2013. However, looking at 
the popcon stats, the original python GMPY is still much more popular 
than than python GMPY2 (3543 vs 443). So I think it's worth keeping this 
package.


I'm working on converting it over now and should be able to get it done 
in the next few weeks.


Is it possible to remove the AUTORM tag until this is done, or should we 
let it get deleted and upload a new python3-gmpy package after that?




Looking further, it seems that with current versions of Python 3 (I 
tested with 3.7.3), the old GMPY 1.17 is no longer passing. When I run 
test3/gmpy_test.py, I'm getting:


$ python3 test3/gmpy_test.py
...
8 items had failures:
   1 of   4 in gmpy_test_cvr
   4 of 126 in gmpy_test_cvr.__test__.user_errors
   1 of   1 in gmpy_test_dec
   2 of   2 in gmpy_test_mpf
   2 of  60 in gmpy_test_mpf.__test__.binio
   2 of   2 in gmpy_test_mpq
   2 of   4 in gmpy_test_mpz
   7 of  25 in gmpy_test_rnd.__test__.rand
1504 tests in 42 items.
1483 passed and 21 failed.
***Test Failed*** 21 failures.

In contrast, the tests for GMPY 2 all succeed, so I think the author 
clearly intended for tests to fully pass. Since this hasn't been 
maintained for 7 or so years, I'm not too surprised.


Given this, I think we should let this package be removed and consider 
resurrecting it in the future if people ask for it and someone will step 
up to maintain it.


Sandro, is there anything more to do if I want to let this package be 
removed, or do I just wait for the auto-removal?

Bug#950960: photocollage: GUI field too small for border width

[cacatoes]

Subject: photocollage: GUI field too small for border width
Package: photocollage
Version: 1.4.3-2.1

Hello dear Maintainers,

As you can see on the screenshot, in photocollage settings, the width field for
border size is a bit small, and not all digits are displayed. It would be nice
to make it larger for accessibility.
It seems to have been fixed upstream:
https://github.com/adrienverge/PhotoCollage/commit/5ed917a87a392db0fcd65346b5603f3bad20dacf

Thanks a lot!

PS: I am running cinnamon and using vivix as a GTK3 theme.

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

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

Versions of packages photocollage depends on:
pn  gir1.2-gtk-3.0
ii  python3   3.7.3-1
pn  python3-cairo 
pn  python3-gi-cairo  
pn  python3-pil   
ii  python3-six   1.12.0-1

photocollage recommends no packages.

photocollage suggests no packages.

Bug#950961: photocollage: model input field provides no feedback after choice

[cacatoes]

Package: photocollage
Version: 1.4.3-2.1

Hello again dear Maintainers,

In photocollage's settings, we can choose the model of the image size
(A4 and so on). When selecting and validating between the formats, our
choice is applied and the size changes accordingly. However, the model
input field remains blank, so it doesn't give a very good visual
feedback to confirm our choice.

Hope this helps, thanks for the app.

Bug#950723: debhelper: dh_installsystemd doesn't install template unit files by default

[Niels Thykier]

Badreddin Aboubakr:
> Hey Niels,
> 
> thanks for replying.
> I tired removing the arguments given
> to dh_installsystemd, however in this case serf@.service did not get copied
> Wich was the scope of thia bug report
> I did add the argument as workaround to let dh_installsystemd copy serf@
> .service
> 
> Best,
> 
> [...]

That is interesting; I cannot reproduce this behaviour you are
describing when I call dh_installsystemd (albeit with different package
names, but that should not be the deciding factor).

I may have to look at serf at some point to see what is going on.  Is
the packaging available somewhere publicly?

Thanks,
~Niels

Bug#950959: Signed grub-efi binaries missing jfs support

[Steve McIntyre]

Source: grub2
Version: 2.02+dfsg1-20
Severity: important

Hi,

We've just found a bug when testing the 10.3 point release: our signed
Grub binaries don't include support for jfs. Easily fixed, and maybe
worth doing a stable upload too to add this.

It's currently possible to install a system with jfs on root that will
then fail on first boot, which is not great. :-/

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

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

Bug#937791: Blocked on reverse dependencies

[Martin Kelly]

On 2/2/20 8:39 PM, Sandro Tosi wrote:

$ apt-cache rdepends python-gmpy
python-gmpy
Reverse Depends:
obfsproxy
python-tlslite-ng
python-sympy
python-gmpy-doc




Dependencies on obfsproxy and python-sympy documented with affects and
blocks. python-tlslite-ng has been removed already,


there are no more reverse dependencies on python-gmpy, what should we
do next? i see the source package doesnt produce any python3 package,
and the last changelog entry contains:

   * Override python-foo-but-no-python3-foo Lintian warning, since this package
 is end-of-life after Python 2 support ends.

should we remove this package then? or do you want to generate a python3-gmpy?



I didn't realize, but it looks like this package actually does support 
Python 3. I had assumed we would let this package die when Python 2 
dies, since the package is dead upstream since 2013. However, looking at 
the popcon stats, the original python GMPY is still much more popular 
than than python GMPY2 (3543 vs 443). So I think it's worth keeping this 
package.


I'm working on converting it over now and should be able to get it done 
in the next few weeks.


Is it possible to remove the AUTORM tag until this is done, or should we 
let it get deleted and upload a new python3-gmpy package after that?



and we can rename
python-gmpy-doc to python3-gmpy-doc once the blocking bugs are resolved.


please dont, -doc package must preserve the python- prefix.

Cheers,
Sandro

Bug#950938:

[Łukasz Dudek]

https://mailman.astron.com/pipermail/tcsh/2019-November/36.html

Bug#950957: libtime-mock-perl FTBFS with debhelper >= 12.7.3

[Adrian Bunk]

Source: libtime-mock-perl
Version: 0.0.2-5
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libtime-mock-perl.html

...
   dh_gencontrol
dpkg-gencontrol: warning: can't parse dependency perl:any:any
dpkg-gencontrol: error: error occurred while parsing Depends field: , 
perl:any:any
dh_gencontrol: error: dpkg-gencontrol -plibtime-mock-perl -ldebian/changelog 
-Tdebian/libtime-mock-perl.substvars -Pdebian/libtime-mock-perl returned exit 
code 25
dh_gencontrol: error: Aborting due to earlier error
make: *** [debian/rules:4: binary] Error 25


See #946655 for background.

Bug#950958: RM: koji -- RoQA; depends on Python 2, open security issues

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove koji. It depends on Python 2 and packaging current upstream
releases is blocked on dnf. Holger (the last active maintainer) acked the
removal in #936806.

Cheers,
Moritz

Bug#936806: koji: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Thu, Jan 30, 2020 at 01:36:33AM -0500, Sandro Tosi wrote:
> > > koji is keeping createrepo in the archive, which keeps python-lzma in
> > > the archive.
> >
> > there's also mock, yum, rpm, deltarpm and yum-metadata-parser affected by 
> > this.
> 
> yep i came across all of them starting from python-lzma -- do you know
> what's the status of the "RedHat infrastructure" in debian? many (if
> not all) of those tools are relatively old, not maintained (or just in
> life support mode) and most of all, python2 with no port to python3
> available
> 
> > > upgrading koji will help getting rid of some old python2 packages.
> >
> > dropping it, at least for now, seems to be the best way foreward here :/
> 
> Allright then, i'll just wait a week for allowing people to comment
> and then i'll file for koji removal.

Since there were no further objections I've just filed a removal bug.

Cheers,
Moritz

Bug#940696: please add drbdtop or keep drbd-overview

[Joe Rayhawk]

On Thu, 19 Sep 2019 08:24:46 +0200 Harald Dunkel  
wrote:
> Would it be possible to either *keep* drbd-overview (I am using it
> for monitoring) or to add drbdtop to Debian?

While not nearly as pleasant to work with as drbd-overview, drbdadm can
produce output marginally servicable for use in crontabs, including
uninitialized drbd resources.

set -o pipefail
/sbin/drbdadm sh-status | /usr/bin/pee \
  '! /bin/grep ^_cstate | /bin/grep -v Connected' \
  '! /bin/grep ^_peer   | /bin/grep -v Secondary' \
  '! /bin/grep ^_role   | /bin/grep -v Primary'   \
  '! /bin/grep ^_disk   | /bin/grep -v UpToDate'  \
  '! /bin/grep ^_pdsk   | /bin/grep -v UpToDate'
# /usr/bin/pee from the moreutils package

Bug#950956: libsql-tokenizer-perl FTBFS with debhelper >= 12.7.3

[Adrian Bunk]

Source: libsql-tokenizer-perl
Version: 0.24-6
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libsql-tokenizer-perl.html

...
   dh_gencontrol
dpkg-gencontrol: warning: can't parse dependency perl:any:any
dpkg-gencontrol: error: error occurred while parsing Depends field: , 
perl:any:any,
dh_gencontrol: error: dpkg-gencontrol -plibsql-tokenizer-perl 
-ldebian/changelog -Tdebian/libsql-tokenizer-perl.substvars 
-Pdebian/libsql-tokenizer-perl returned exit code 25
dh_gencontrol: error: Aborting due to earlier error
make: *** [debian/rules:4: binary] Error 25


See #946655 for background.

Bug#950954: liburi-perl FTBFS with debhelper >= 12.7.3

[Adrian Bunk]

Source: liburi-perl
Version: 1.76-1
Severity: serious
Tags: ftbfs bullseye sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/liburi-perl.html

...
   dh_gencontrol
dpkg-gencontrol: warning: can't parse dependency perl:any:any
dpkg-gencontrol: error: error occurred while parsing Depends field: ,
perl:any:any
dh_gencontrol: error: dpkg-gencontrol -pliburi-perl -ldebian/changelog 
-Tdebian/liburi-perl.substvars -Pdebian/liburi-perl returned exit code 25
dh_gencontrol: error: Aborting due to earlier error
make: *** [debian/rules:4: binary] Error 25


See #946655 for background.

Bug#950955: puppet-lint: FTBFS on unstable: undefined method `branch_coverage?' for SimpleCov:Module (NoMethodError)

[Antonio Terceiro]

Source: puppet-lint
Version: 2.3.6-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

After running the actual tests, something happens that makes the build
crash.

8<8<8<-
Finished in 1.34 seconds (files took 0.26891 seconds to load)
819 examples, 0 failures

/usr/lib/ruby/vendor_ruby/simplecov-html.rb:20:in `initialize': undefined 
method `branch_coverage?' for SimpleCov:Module (NoMethodError)
from /usr/lib/ruby/vendor_ruby/simplecov/result.rb:48:in `new'
from /usr/lib/ruby/vendor_ruby/simplecov/result.rb:48:in `format!'
from /usr/lib/ruby/vendor_ruby/simplecov/configuration.rb:182:in `block 
in at_exit'
from /usr/lib/ruby/vendor_ruby/simplecov.rb:200:in `run_exit_tasks!'
from /usr/lib/ruby/vendor_ruby/simplecov/defaults.rb:27:in `block in 
'
/usr/bin/ruby2.5 /usr/bin/rspec --pattern ./spec/\*\*/\*_spec.rb --format 
documentation failed
ERROR: Test "ruby2.5" failed. Exiting.
dh_auto_install: error: dh_ruby --install /<>/debian/puppet-lint 
returned exit code 1
make: *** [debian/rules:15: binary] Error 25
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit 
status 2
8<8<8<-

See full build log attached.

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


puppet-lint_amd64.build.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#911560: [Kinda solved] Re: Network not working on Olimex LIME2 rev K ??

[Jonas Smedegaard]

Quoting Dominique Dumont (2020-02-08 17:55:10)
> On samedi 8 février 2020 16:54:45 CET Jonas Smedegaard wrote:
> > I guess you mean that the negotiated ethernet mode is 1G. 
> 
> yes.
> 
> > What is the actual performance - i.e. which concrete transfer speeds 
> > is achievable, in each direction, for each board?
> 
> I've seen only outgoing traffic at about 20 to 30 Mbytes/s through NFS 
> for the rev. K board.
> 
> As far as I recall, I had about 20-25 Mbytes/s with the rev. G2 board 
> and the vanilla u-boot.
> 
> > With which kind on low-level network wiring did you test the 
> > negotiated mode - e.g. cross-over cable to another host or 
> > gigabit-capable switch?
> 
> standard cable to a gigabit-capable switch.

Thanks!


> > Would be great if you could also test with patched u-boot in stable 
> > Debian - so we can consider fixing this in a point release.
> 
> I can easily test with a patched u-boot from stable with a 
> Debian/unstable. Would that be helpful ?

Yes, that would be helpful.  Thanks!


 - 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#851747: sysvinit-utils: drop Essential flag

[Michael Biebl]

Am 08.02.20 um 19:23 schrieb Andreas Henriksson:
> Hello,
> 
> Regarding the previous discussion about packages with init scripts
> that source /lib/init/vars.sh 
> 
> I've now submitted bug reports including an attempt at a service file
> for packages with popcon install count above 100 (and some below),

Thanks so much for your work, Andreas.
Very much appreciated!

Regards,
Michael




signature.asc
Description: OpenPGP digital signature

Bug#931644: Buster kernel entropy pool too low on VM boot

[Salvatore Bonaccorso]

Hi Michael,

On Sat, Feb 08, 2020 at 11:38:23AM -0500, Michael J. Redd wrote:
> I've upgraded my VMs to the 10.3 point release and can confirm that
> cryptographic services (SSH and others) start quite rapidly now on
> system boot.

Thanks for confirming!

Closing then the bug as well with 4.19.98-1.

Regards,
Salvatore

Bug#851747: sysvinit-utils: drop Essential flag

[Andreas Henriksson]

Hello,

Regarding the previous discussion about packages with init scripts
that source /lib/init/vars.sh 

I've now submitted bug reports including an attempt at a service file
for packages with popcon install count above 100 (and some below),
except for a few that I didn't find motivation for:

sasl2-bin
sendmail-bin
xen-utils-common

lprng

webfs
heimdal-kcm 

The bug reports in question are:

https://bugs.debian.org/950236
https://bugs.debian.org/950240
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738548
https://bugs.debian.org/950427
https://bugs.debian.org/950241
http://bugs.debian.org/950952
https://bugs.debian.org/950432
https://bugs.debian.org/950694
https://bugs.debian.org/950246
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950263
https://bugs.debian.org/950696
https://bugs.debian.org/950697
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849955
https://bugs.debian.org/950270
http://bugs.debian.org/950948
https://bugs.debian.org/950949
https://bugs.debian.org/950945
https://bugs.debian.org/950943
https://bugs.debian.org/950951
https://bugs.debian.org/950442
https://bugs.debian.org/950320
https://bugs.debian.org/793854
https://bugs.debian.org/950441
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833067
https://bugs.debian.org/950388
https://bugs.debian.org/950386

My impression is that adding service files for most of the affected init
scripts should be pretty straight forward and hasn't been done simply
because the maintainer hasn't cared enough to do so.
In case there are any complex cases those could ofcourse always resort
to depending on sysvinit-utils. Several of the init scripts I've looked
at already use commands and assume packages with Priority >= important
are always installed and don't specify dependencies for them (and it'll
likely be quite a while before sysvinit-utils drops its priority below
that, which is certainly not the scope for this bug report).

Regards,
Andreas Henriksson

Bug#950931: [rebecca_pal...@zoho.com: Bug#950931: q2templates: FTBFS with pandas 1.0: test failures]

[Liubov Chuprikova]

Hello,

The error seems to be related to this issue:
https://github.com/qiime2/q2templates/issues/41. We could possibly work on
it but the upstream is already going to fix the issue in the next release.

Best,
Liubov

Bug#948797: fails to compile cqrlog on mipsel: Fatal: Internal error 200603251

[Abou Al Montacir]

Control: reassign -1 fp-compiler

Hi All,
On Thu, 2020-01-16 at 18:41 +0100, Christoph Berg wrote:
> > /<>/src/./synapse/synautil.pas(2118,1) Fatal: Internal error
> > 200603251

I would say that this is an issue in FPC, not in Lazarus.
Running grep on FPC sources gives:
fpcsrc/compiler/mips/cpubase.pas:402:  internalerror(200603251);
So I'm moving it to fp-compiler package
-- 
Cheers,
Abou Al Montacir


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

Bug#950953: python3-numpy: Provide dh-sequence-numpy3

[Andreas Metzler]

Package: python3-numpy
Version: 1:1.17.4-5
Severity: wishlist
Tags: patch

Hello,

could you please let python3-numpy Provide dh-sequence-numpy3 to allow
using the newish debhelper declarative interface[1], i.e. replacing

debian/control:
Build-Depends: python3-numpy
debian/rules
dh $@ --with numpy3

with

Build-Depends: dh-sequence-numpy3
debian/rules
dh $@

TIA, cu Andreas

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg0.html

Bug#950859: cegui-mk2: FTBFS with boost171 and new cmake and symbol changes

[Olek Wojnar]

Hi Dimitri,

Thanks for the bug report, and thanks for the patch!

On 2/7/20 8:49 AM, Dimitri John Ledkov wrote:
> Package: cegui-mk2
> Version: 0.8.7-5
> Severity: serious
> Tags: patch
> Justification: ftbfs
>
> Dear Maintainer,
>
> cegui-mk2 ftbfs with new cmake & boost1.71 due to change in cmake
> policy w.r.t. boost version detection (it is now more normal). See patch 
> attached.

Thank goodness for them making it more normal! I was not a fan of that
old system.

> I am currently in process of migrating to boost1.71 in Ubuntu, which
> has not started yet in Debian but is upcoming.
>
> When built against boost1.71 symbols are dropped and changed. It seems
> as if cegui-mk2 re-exports boost symbols, and thus boost abi change in
> templates leakes in the change of cegui-mk2 libraries ABI change.
>
> How should this be handled?
>
> Is there a new upstream release of cegui that we can package in
> experimental, always built against boost1.71 with new symbols?

No, upstream has not done a new release in a while. Although I can (and
plan to) package the current version in experimental once boost1.71
lands there. Since I don't follow Boost, a notification in this bug
report would be appreciated.

> Or shall i just blindly update the symbols file, rebuild ember and
> hope for the best?
>
> How was this handled in cegui-mk2 before, when boost changed without
> cegui-mk2 new upstream releases?

I've only recently taken a more-active role in maintaining this package.
I think I previously only submitted a few NMUs. But, I believe that what
you listed is exactly what happened. I know I saw that with Ember (which
I *have* been maintaining for a while).

If you have any suggestions for a better, less-reactive, way forward on
this I'm certainly open to it!

> I would like to avoid diverging ABI between ubuntu & debian here.

Absolutely! I'm a big fan of keeping Debian and Ubuntu closely
synchronized.

-Olek




signature.asc
Description: OpenPGP digital signature

Bug#950952: aprx: missing-systemd-service-for-init.d-script

[Andreas Henriksson]

Package: aprx
Version: 2.9.0+dfsg-2
Severity: normal
Tags: bullseye sid

Dear Maintainer,

Please consider adding a native systemd service masking the already
shipped init script (fixes lintian tag[1] in subject).

I've attached my own attempt at writing a service file, based off
looking at what the init script does. Note that it is completely
untested (as I don't use aprx myself).
You can install the aprx.service file by simple dropping it into
the debian/ directory and debhelper will handle it for you (however
note that the current compat level 11 is discuraged, so you might want
to move to either 10 or 12).

Please note that the service file could be simplified. By adding
the aprx -i flag the program will run in the foreground and you
could use Type=simple. It is also recommended *not* to use
EnvironmentFile and setting options via /etc/default files, but instead
use 'systemctl edit aprx.service' so that systemd-delta will be able
to show any customizations. I however opted for the attached way
as the user might already have some important settings in DAEMON_OPTS
that I'm not aware of.

Additional improvements eg. using security hardening[2] could also be
added.

Regards,
Andreas Henriksson


[1]: 
https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script.html
[2]: 
https://lintian.debian.org/tags/systemd-service-file-missing-hardening-features.html
[Unit]
Description=Monitor and gateway radio amateur APRS radio network datagrams
After=network.target

[Service]
Type=forking
PIDFile=/run/aprx.pid
EnvironmentFile=-/etc/default/aprx
ExecStart=/usr/sbin/aprx $DAEMON_OPTS
#TODO: security hardening

[Install]
WantedBy=multi-user.target

Bug#950951: ptunnel: missing-systemd-service-for-init.d-script

[Andreas Henriksson]

Package: ptunnel
Version: 0.72-3
Severity: normal
Tags: bullseye sid

Dear Maintainer,

Please consider adding a native systemd service masking the already
shipped init script (fixes lintian tag[1] in subject).

I've attached my own attempt at writing a service file, based off
looking at what the init script does. Note that it is completely
untested (as I don't use ptunnel myself).
The ptunnel.service could simply be dropped into the debian/ directory
and debhelper should do the right thing with the service file (although
note that the current compat 11 is now discuraged!).

Please also note that the magic expansions as done to $password
is a shell feature and is not supported inside a service file.
Also passing a password on the command line to a process is
a local security hole as anyone could see it by simply running
'ps aux' or similar. I would recommend that ptunnel implements
reading the password from the environment variable directly itself.

The service could also be simplified by dropping the -daemon argument
running ptunnel in the foreground and set Type=simple. It is recommended
that user changes to settings are done via 'systemctl edit
ptunnel.service' rather than using /etc/default files, which will
allow 'systemd-delta' to show customizations. I however did not
go this route as users current setup might contain important settings
already in their $OPTIONS variable that I'm not aware of.

Additional improvements eg. using security hardening[2] could also be
added.

Finally please get rid of the homebrew enable/disable[3] service
implementation $run_daemon. Ship the service disabled and let
the user simply run 'service ptunnel enable' when they have
configured it.

Regards,
Andreas Henriksson


[1]: 
https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script.html
[2]: 
https://lintian.debian.org/tags/systemd-service-file-missing-hardening-features.html
[3]: 
https://lintian.debian.org/tags/init.d-script-should-always-start-service.html
[Unit]
Description=TCP over ICMP tunnelling daemon
After=network.target

[Service]
Type=forking
PIDFile=/run/ptunnel.pid
Environment="OPTIONS=-daemon /run/ptunnel.pid"
#Environment=run_daemon=false
EnvironmentFile=-/etc/default/ptunnel
# Note: 
https://lintian.debian.org/tags/init.d-script-should-always-start-service.html
#ExecStartPre=/bin/bash -c 'if [ "$run_daemon" != true ]; then echo "To run the 
ptunnel daemon, please set run_daemon to 'true' in /etc/default/ptunnel "; exit 
1 ; fi'
ExecStart=/usr/sbin/ptunnel
# TODO: security hardening

[Install]
WantedBy=multi-user.target

Bug#950926: ember: Using packages to install "snap" packages is not a correct use of the packaging system

[Olek Wojnar]

Hi Manuel,

Thanks for your bug report and thanks for your thoughts. However, at
this point I'm inclined to respectfully disagree with you on this subject.

On 2/8/20 8:44 AM, Manuel A. Fernandez Montecelo wrote:
> Package: ember
> Version: 0.8.0~snap1
> Severity: serious
>
> Hello,
>
> I don't think taht using this package as an empty shell and a gateway to 
> install
> the "snap" package [1] is a valid use of the packaging system.

Not only is this use listed in Policy [1] under the contrib section
(where I'm moving the two packages I've done this with, pending NEW) but
a number of other packages (in contrib) do exactly the same thing. Flash
[2] being the obvious example. I'd also like to point out that I asked
about this course of action back in December [3] and no one raised any
concerns. So it's a little frustrating that after I've done all the work
to convert the packages I'm now getting feedback saying I shouldn't have
done it.

> Otherwise, if this was an accepted practice, we could start to have many
> packages which are just a way to install snap packages, which can easily 
> contain
> security vulnerabilities and install not free software, specially if the 
> version
> is not restricted in some way.  And this not generally expected by users of
> Debian, IMO.

This is a fair concern. However, I think that users *do* expect this of
packages in contrib. Pabs made a good argument in a different bug report
about this issue and convinced me. I'm going with that.

However, I do agree that this shouldn't be *normal*. Ideally, we should
host source code and build the packages ourselves, in main. In this
case, I see this as a gap-filler while the upstream packages go through
a period of extreme instability. Upstream is very small and this process
is likely to last more than a year. I structured the transitional
packages, and annotated a comment in d/copyright, explaining that this
is a temporary step to have a usable package (for Debian users who opt
in to contrib) until upstream stabilizes and I can package it in main again.

> If users want to install Snap packages, they can always do so on their own.

They can. I'm just trying to provide a transition path that will
eventually lead to the main packaging of the updated upstream software.

> So please reconsider and either package the game properly or drop this package
> altogether.

FWIW, I am planning to temporarily drop the supporting Worldforge
libraries [1] since they will just be taking up space in the archive and
they'll get pulled back in to a user's system once Ember and Cyphesis
return to main.

Again, I want to clarify that I am open to inputs (and I appreciate
yours) and I'm happy to continue the discussion if you have additional
points that you think I should consider. But I really wish that these
concerns had been brought up back in December...

> [1] https://salsa.debian.org/games-team/ember/blob/master/debian/ember.preinst

-Olek

[1]
https://www.debian.org/doc/debian-policy/ch-archive.html#the-contrib-archive-area
[2] https://packages.debian.org/sid/flashplugin-nonfree
[3] https://lists.debian.org/debian-devel-games/2019/12/msg0.html



signature.asc
Description: OpenPGP digital signature

Bug#950930: python-skbio: FTBFS with pandas 1.0: test failures

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/biocore/scikit-bio/issues/1692

Bug#950950: hamlib: Please include patch to fix unaligned access in dummy/dummy.c

[John Paul Adrian Glaubitz]

Source: hamlib
Version: 3.3-8
Severity: normal
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hi!

The attached patch fixes an unaligned access in dummy_get_level() which
resulted in the testsuite crashing on sparc64 [1].

I have opened a pull request upstream as well to address the issue [2],
so carrying the patch should hopefully not be necessary in the future.

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=hamlib=sparc64=3.3-8=1580780480=0

--
 .''`.  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
dummy/dummy.c: Fix unaligned access in dummy_get_level()

This fixes an unaligned access in dummy/dummy.c in the function
dummy_get_level() which resulted in crashes (Bus Error) on systems
with stricter alignment requirements such as SPARC.

On x86_64 (and any other architecture with less strict alignment
requirements), the compiler automatically optimizes the memcpy()
out if necessary such that there are no performance issues.

--- hamlib-3.3.orig/dummy/dummy.c
+++ hamlib-3.3/dummy/dummy.c
@@ -834,7 +834,7 @@ static int dummy_get_level(RIG *rig, vfo
 }
   }
 
-  *val = curr->levels[idx];
+  memcpy (val, >levels[idx], sizeof(value_t));
   rig_debug(RIG_DEBUG_VERBOSE,"%s called: %s\n",__FUNCTION__,
  rig_strlevel(level));
 

Bug#950310: re: nomacs ftbfs with libexiv2-27

[Alf Gaida]

ok, it turns out that only one extra line was to change in the
imagestore headers and code - so i will upload soon

--- nomacs-3.12.0+dfsg.orig/src/DkCore/DkImageStorage.cpp
+++ nomacs-3.12.0+dfsg/src/DkCore/DkImageStorage.cpp
@@ -1424,7 +1424,7 @@ void DkImage::mapGammaTable(cv::Mat& img
    qDebug() << "gamma computation takes: " << dt;
 }
 
-void DkImage::logPolar(const cv::Mat& src, cv::Mat& dst, CvPoint2D32f
center, double scaleLog, double angle, double scale) {
+void DkImage::logPolar(const cv::Mat& src, cv::Mat& dst, cv::Point2d
center, double scaleLog, double angle, double scale) {
 
    cv::Mat mapx, mapy;
 

--- nomacs-3.12.0+dfsg.orig/src/DkCore/DkImageStorage.h
+++ nomacs-3.12.0+dfsg/src/DkCore/DkImageStorage.h
@@ -95,7 +95,7 @@ public:
    static void mapGammaTable(cv::Mat& img, const QVector& gammaTable);
    static void gammaToLinear(cv::Mat& img);
    static void linearToGamma(cv::Mat& img);
-   static void logPolar(const cv::Mat& src, cv::Mat& dst,
CvPoint2D32f center, double scaleLog, double angle, double scale = 1.0);
+   static void logPolar(const cv::Mat& src, cv::Mat& dst,
cv::Point2d center, double scaleLog, double angle, double scale = 1.0);
    static void tinyPlanet(QImage& img, double scaleLog, double
angle, QSize s, bool invert = false);
 #endif

Bug#950929: python-biom-format: FTBFS with pandas 1.0: test failures

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/biocore/biom-format/issues/837

Bug#950720: FTBFS: error: conflicting declaration ‘typedef long long unsigned int __u64’

[Hilmar Preuße]

Control: reopen 950720
Control: found 950720 3.86-3

Am 05.02.2020 um 12:11 teilte Hilmar Preusse mit:

> Package: wp2latex
> Version: 3.86-2
> Severity: serious
> Tags: patch upstream
> Justification: 4.
> 
> Dear Maintainer,
> 
> the package FTBFS on s390x & arm64.
> 
Still build issues on both arches, due to type conflicts. Reopening.

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



signature.asc
Description: OpenPGP digital signature

Bug#950900: llvm-toolchain-10: FTBFS on s390x invalid instructions

[Sylvestre Ledru]

forwarded 950900 https://bugs.llvm.org/show_bug.cgi?id=44849
thanks


Le 07/02/2020 à 23:28, Dimitri John Ledkov a écrit :

Package: llvm-toolchain-10
Severity: important

Dear Maintainer,

llvm-toolchain-10 ftbfs on s390x with

fatal error: error in backend: Not supported instr:  
>
make[8]: *** [lib/Target/X86/CMakeFiles/LLVMX86CodeGen.dir/build.make:326: 
lib/Target/X86/CMakeFiles/LLVMX86CodeGen.dir/X86ISelLowering.cpp.o] Error 70
make[8]: Leaving directory 
'/<>/llvm-toolchain-10-10.0.0~+rc1/build-llvm/tools/clang/stage2-bins'
make[7]: *** [CMakeFiles/Makefile2:30692: 
lib/Target/X86/CMakeFiles/LLVMX86CodeGen.dir/all] Error 2
make[7]: *** Waiting for unfinished jobs


Please note that normally on Ubuntu Focal we default to -march=z13 and
we do build on z13 instructions capable mainframe.


the issue also exists on the Debian side:


https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-10=s390x=1%3A10.0.0%7E%2Brc1-1%7Eexp1=1580899435=0
  


S

Bug#796257: dpkg-source: Does not respect permissions from tarball when umask is set to 0002

[Thorsten Glaser]

Package: dpkg-dev
Version: 1.19.7
Followup-For: Bug #796257
Control: affects -1 src:musescore
Control: affects -1 src:musescore-snapshot

Please fix this bug; all other tarball extractors I’ve tested
(GNU tar, GNU cpio, paxtar, bsdtar/libarchive-tools) use the
permission bits from the archive, and all except GNU cpio then
mask those *further* by the user’s umask (but paxcpio/bsdcpio
behave the same).

This is important for reproducible builds as well: some tools
(like cmake) copy the extracted permissions.


-- Package-specific info:

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

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

Versions of packages dpkg-dev depends on:
ii  binutils  2.34-2
ii  bzip2 1.0.8-2
ii  libdpkg-perl  1.19.7
ii  make  4.2.1-1.2
ii  patch 2.7.6-6
ii  perl  5.30.0-9
ii  tar   1.30+dfsg-6+b1
ii  xz-utils  5.2.4-1+b1

Versions of packages dpkg-dev recommends:
ii  build-essential  12.8
ii  fakeroot 1.24-1
ii  gcc [c-compiler] 4:9.2.1-3.1
ii  gcc-9 [c-compiler]   9.2.1-26
ii  gnupg2.2.19-1
ii  gnupg2   2.2.19-1
ii  gpgv 2.2.19-1
pn  libalgorithm-merge-perl  
ii  tcc [c-compiler] 0.9.27-8

Versions of packages dpkg-dev suggests:
ii  debian-keyring  2020.02.02

-- no debconf information

Bug#945888: The nscd daemon use a wrong path to open cache files

[Aurelien Jarno]

On 2019-11-30 16:00, André Rodier wrote:
> Package: nscd
> Version: 2.28-10
> 
> When using AppArmor and ldap for users database, and nscd on Debian, a
> lot of errors are visible in the AppArmor logs, when any program
> queries nscd.
> 
> The nscd daemon tries to open files in "var/cache/nscd/..." instead of
> "/var/cache/nscd/...". Note the missing slash character at the
> beginning. AppArmor complains about the file access denied, but the
> error is really a missing '/' character in the path of the cache files.

What makes you believe that? I have just tried with strace, and I see
the correct path with the leading '/':

openat(AT_FDCWD, "/var/cache/nscd/passwd", O_RDWR|O_CLOEXEC) = 4
openat(AT_FDCWD, "/var/cache/nscd/passwd", O_RDONLY|O_CLOEXEC) = 5
openat(AT_FDCWD, "/var/cache/nscd/group", O_RDWR|O_CLOEXEC) = 6
openat(AT_FDCWD, "/var/cache/nscd/group", O_RDONLY|O_CLOEXEC) = 7
openat(AT_FDCWD, "/var/cache/nscd/hosts", O_RDWR|O_CLOEXEC) = 8
openat(AT_FDCWD, "/var/cache/nscd/hosts", O_RDONLY|O_CLOEXEC) = 9
openat(AT_FDCWD, "/var/cache/nscd/services", O_RDWR|O_CLOEXEC) = 10
openat(AT_FDCWD, "/var/cache/nscd/services", O_RDONLY|O_CLOEXEC) = 11
openat(AT_FDCWD, "/var/cache/nscd/netgroup", O_RDWR|O_CLOEXEC) = 12
openat(AT_FDCWD, "/var/cache/nscd/netgroup", O_RDONLY|O_CLOEXEC) = 13

Regards,
Aurelien

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

Bug#911560: [Kinda solved] Re: Network not working on Olimex LIME2 rev K ??

[Dominique Dumont]

On samedi 8 février 2020 16:54:45 CET Jonas Smedegaard wrote:
> I guess you mean that the negotiated ethernet mode is 1G. 

yes.

> What is the
> actual performance - i.e. which concrete transfer speeds is achievable,
> in each direction, for each board?

I've seen only outgoing traffic at about 20 to 30 Mbytes/s through NFS for the 
rev. K board. 

As far as I recall, I had about 20-25 Mbytes/s with the rev. G2 board and the 
vanilla u-boot.

> With which kind on low-level network wiring did you test the negotiated
> mode - e.g. cross-over cable to another host or gigabit-capable switch?

standard cable to a gigabit-capable switch.

> Would be great if you could also test with patched u-boot in stable
> Debian - so we can consider fixing this in a point release.

I can easily test with a patched u-boot from stable with a Debian/unstable. 
Would that be helpful ?

All the best

Dod

Bug#950949: ndpmon: missing-systemd-service-for-init.d-script

[Andreas Henriksson]

Package: ndpmon
Version: 1.4.0-2.1
Severity: normal
Tags: bullseye sid

Dear Maintainer,

Please consider adding a native systemd service masking the already
shipped init script (fixes lintian tag[1] in subject).

I've attached my own attempt at writing a service file, based off
looking at what the init script does. Note that it is completely
untested (as I don't use ndpmon myself).

You should be able to use the ndpmon.service file by dropping it into
the debian/ directory and then bumping debhelper compat to >= 10
which will get the service file automatically handled (also
debhelper compat <= 9 is deprecated).

Additional improvements eg. using security hardening[2] could also be
added.

Regards,
Andreas Henriksson


[1]: 
https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script.html
[2]: 
https://lintian.debian.org/tags/systemd-service-file-missing-hardening-features.html
[Unit]
Description=IPv6 Neighbor Discovery Protocol Monitor
After=network.target
ConditionPathExists=/etc/ndpmon/config_ndpmon.xml

[Service]
Type=simple
#Environment=DAEMON_ARGS=
EnvironmentFile=-/etc/default/ndpmon
ExecStart=/usr/sbin/ndpmon $DAEMON_ARGS

[Install]
WantedBy=multi-user.target

Bug#950899: llvm-toolchain-10: FTBFS on ppc64el fail-missing hwasan_symbolize

[Sylvestre Ledru]

Hello,

Le 07/02/2020 à 23:27, Dimitri John Ledkov a écrit :

Package: llvm-toolchain-10
Version: 1:10.0.0~+rc1-1~exp1
Severity: important

Dear Maintainer,

llvm-toolchain-10 FTBFS on ppc64el due to fail-missing:

dh_install --fail-missing
dh_install: warning: Please use dh_missing --list-missing/--fail-missing instead
dh_install: warning: This feature will be removed in compat 12.
dh_install: warning: Cannot find (any matches for) 
"usr/lib/llvm-10/lib/clang/10.0.0/bin/hwasan_symbolize" (tried in ., debian/tmp)

dh_install: warning: clang-tools-10 missing files: 
usr/lib/llvm-10/lib/clang/10.0.0/bin/hwasan_symbolize
dh_install: error: missing files, aborting

Full Ubuntu Focal build log at:
https://launchpadlibrarian.net/464010057/buildlog_ubuntu-focal-ppc64el.llvm-toolchain-10_1%3A10.0.0~+rc1-1~exp1_BUILDING.txt.gz


Fixed in the vcs already :)

S

Bug#950885: RFS: scons-doc/3.1.2+repack-2 -- Documentation for SCons, a replacement for Make

[Jörg Frings-Fürst]

Hallo Adam,

thanks for your review. I have check it with sbuild and pdebuild again
and found no error.  The sbuild log is attached.

Am Freitag, den 07.02.2020, 20:44 +0100 schrieb Adam Borowski:
> On Fri, Feb 07, 2020 at 07:16:07PM +0100, Jörg Frings-Fürst wrote:
> >Package name: scons-doc
> >Version : 3.1.2+repack-2
> > Changes since the last upload:
> > 
> >* debian/watch: Add repacksuffix.
> >* debian/copyright:
> >  - Add year 2020 to debian/*.
> >* Declare compliance with Debian Policy 4.5.0 (No changes
> > needed).
> >* upload to unstable (Closes: #943200).
> 
> Alas, it fails at the "clean" stage:
> 
> dh clean
>debian/rules override_dh_auto_clean
> make[1]: Entering directory '/<>'
> scons -c
> *** Error loading site_init file './site_scons/site_init.py':
> *** cannot import site init file './site_scons/site_init.py':
> ModuleNotFoundError: No module named 'distutils.util':
>   File "/usr/lib/scons/SCons/Script/Main.py", line 1396:
> _exec_main(parser, values)
>   File "/usr/lib/scons/SCons/Script/Main.py", line 1359:
> _main(parser)
>   File "/usr/lib/scons/SCons/Script/Main.py", line 971:
> _load_all_site_scons_dirs(d.get_internal_path())
>   File "/usr/lib/scons/SCons/Script/Main.py", line 817:
> _load_site_scons_dir(d)
>   File "/usr/lib/scons/SCons/Script/Main.py", line 751:
> exec(compile(fp.read(), fp.name, 'exec'), site_m)
>   File "./site_scons/site_init.py", line 2:
> from Utilities import is_windows, whereis, platform, deb_date
>   File "/<>/site_scons/Utilities.py", line 4:
> import distutils.util
> make[1]: *** [debian/rules:7: override_dh_auto_clean] Error 2
> 
> 
> Meow!


CU
Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



scons-doc_3.1.2+repack-2_amd64-2020-02-08T16:18:20Z.build.gz
Description: application/gzip


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

Bug#950948: n2n: missing-systemd-service-for-init.d-script

[Andreas Henriksson]

Package: n2n
Version: 1.3.1~svn3789-7
Severity: normal

Dear Maintainer,

Please consider adding a native systemd service masking the already
shipped init script (fixes lintian tag[1] in subject).

I've attached my own attempt at writing a service file, based off
looking at what the init script does. Note that it is completely
untested (as I don't use n2n myself).
You should be able to use it just by dropping the n2n.service file
in the debian/ directory and then bump debhelper compat to >= 10
which will get the service file automatically handled (also compat 9 in
now deprecated).

Please note that the service could be a Type=simple if you drop the
-f flag in ExecStart. (Even better would be if the service implemented
support for sd_notify READY=1 so you could use Type=notify.)
Given the comment in the long description of the init script I however
imagine you really want to create a template service instance instead
(and just mask n2n.service -> /dev/null) using n2n@.service.

Additional improvements eg. using security hardening[2] could also be
added.

While at it please also get rid of the home-brew enable/disable[3]
and instead ship the service disabled by default and let the user
do 'service n2n enable' once they've configured it.

Regards,
Andreas Henriksson

PS. the init script uses $DAEMON_ARGS but the default file contains
an (empty) example variable N2N_DAEMON_OPTS (which is ignored).


[1]: 
https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script.html
[2]: 
https://lintian.debian.org/tags/systemd-service-file-missing-hardening-features.html
[3]: 
https://lintian.debian.org/tags/init.d-script-should-always-start-service.html
[Unit]
Description=n2n P2P VPN
After=network.target

[Service]
Type=forking
#PIDFile=/run/$NAME-edge.pid
#Environment=DAEMON_ARGS=
EnvironmentFile=-/etc/default/n2n
# Note: 
https://lintian.debian.org/tags/init.d-script-should-always-start-service.html
# ExecStartPre=/bin/bash -c '[ ! -z "$N2N_EDGE_CONFIG_DONE" ] || echo "Warning: 
n2n VPN client is not configured, edit config file in /etc/default/$NAME."; 
exit 1'
ExecStart=/usr/sbin/edge -f -a $N2N_IP -c $N2N_COMMUNITY -l $N2N_SUPERNODE 
$DAEMON_ARGS
User=nobody
Group=nobody


[Install]
WantedBy=multi-user.target

Bug#931644: Buster kernel entropy pool too low on VM boot

[Michael J. Redd]

I've upgraded my VMs to the 10.3 point release and can confirm that
cryptographic services (SSH and others) start quite rapidly now on
system boot.

Thanks, all!

-Michael

Bug#950947: RM: tophat -- ROM; obsolete

[Alex Mestiashvili]

Package: ftp.debian.org
Severity: normal


I'd like to request removal of tophat. It is obsoleted and substituted 
by hisat2.


Best regards,
Alex

Bug#874051: swami 2.0.0-svn389-5

[paul ulrich niggli]

On Sun, 3 Sep 2017 13:57:46 +0200 paul ulrich niggli 
 wrote:

> Dear Maintainer,


still no luck with the new version.

first I had to copy /usr/share/swami to my

home as /share/swami.and when I restart fluidsynth I get

(swami:15991): libswami-CRITICAL **: 17:23:54.980: swami_wavetbl_close: 
assertion 'SWAMI_IS_WAVETBL (wavetbl)' failed


(swami:15991): libswami-CRITICAL **: 17:23:54.980: swami_wavetbl_open: 
assertion 'SWAMI_IS_WAVETBL (wavetbl)' failed


so still no sound.

Bug#950946: RM: giira -- ROM; obsolete

[Alex Mestiashvili]

Package: ftp.debian.org
Severity: normal


I'd like to request removal of giira which is a reverse dependency of 
tophat which is obsoleted and substituted by hisat2.

Giira itself hasn't been updated for at least 6 years.

Best regards,
Alex

Bug#950945: orthanc: missing-systemd-service-for-init.d-script

[Andreas Henriksson]

Source: orthanc
Version: 1.5.8+dfsg-2
Severity: normal

Dear Maintainer,

Please consider adding a native systemd service masking the already
shipped init script (fixes lintian tag[1] in subject).

I've attached my own attempt at writing a service file, based off
looking at what the init script does. Note that it is completely
untested (as I don't use orthanc myself).

You should be able to just drop the orthanc.service in the debian/
directory and then debhelper will do the right thing as you're
already using compat 10.

Additional improvements eg. using security hardening[2] could also be
added.

Regards,
Andreas Henriksson

[1]: 
https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script.html
[2]: 
https://lintian.debian.org/tags/systemd-service-file-missing-hardening-features.html
[Unit]
Description=Orthanc - Lightweight, RESTful Vendor Neutral Archive
After=network.target
Wants=postgresql.service mysql.service

[Service]
Type=simple
Environment=LOGDIR=/var/log/orthanc
Environment="DAEMON_ARGS=--logdir=${LOGDIR} /etc/orthanc/"
ExecStart=/usr/sbin/Orthanc $DAEMON_ARGS
# Note: Signals are async but the ExecReload command should block
#   until reload finished.
#ExecReload=/bin/kill -HUP $MAINPID
#ExecReload=/bin/sleep 2
User=orthanc
Group=orthanc

[Install]
WantedBy=multi-user.target

Bug#948917: FTBFS: No rule to make target '/usr/lib/x86_64-linux-gnu/libglib-2.0.so'

[Alf Gaida]

Nice, without changing a line of code screengrab now need libglib2.0-dev
as build dependency.

Bug#933750: Python3 porting attempt in 2to3 branch - but failed

[Andreas Tille]

Just for the record: I tried a 2to3 port in branch

https://salsa.debian.org/med-team/paleomix/tree/2to3

but this fails because lots of failed byte-string conversions.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#950943: psad: missing-systemd-service-for-init.d-script

[Andreas Henriksson]

Package: psad
Version: 2.4.3-1.2
Severity: normal
Tags: bullseye sid

Dear Maintainer,

Please consider adding a native systemd service masking the already
shipped init script (fixes lintian tag[1] in subject).

I've attached my own attempt at writing a service file, based off
looking at what the init script does. Note that it is completely
untested (as I don't use psad myself).

You should be able to just drop the psad.service in the debian/
directory and then I would recommend bumping debhelper compat to >= 10
which will give you automatic handling of the service file (and also
note that debhelper 9 is now deprecated).

Additional improvements eg. using security hardening[2] could also be
added.

Regards,
Andreas Henriksson


[1]: 
https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script.html
[2]: 
https://lintian.debian.org/tags/systemd-service-file-missing-hardening-features.html
[Unit]
Description=Port Scan Attack Detector (psad)
After=network.target
ConditionPathExists=/etc/psad/psad.conf
Wants=netfilter-persistent.service

[Service]
Type=forking
PIDFile=/run/psad/psad.pid
#Environment=DAEMON_ARGS=
EnvironmentFile=-/etc/default/psad
RuntimeDirectory=psad
ExecStart=/usr/sbin/psad $DAEMON_ARGS
# TODO: security hardening

[Install]
WantedBy=multi-user.target

Bug#950944: clamav: Vulnerability in the Data-Loss-Prevention (DLP) module

[Scott Kitterman]

Package: clamav
Version: 0.102.1+dfsg-0+deb10u2
Severity: important
Tags: upstream

CVE-2020-3123

A vulnerability in the Data-Loss-Prevention (DLP) module in Clam AntiVirus
(ClamAV) Software versions 0.102.1 and 0.102.0 could allow an unauthenticated,
remote attacker to cause a denial of service condition on an affected device.
The vulnerability is due to an out-of-bounds read affecting users that have
enabled the optional DLP feature. An attacker could exploit this vulnerability
by sending a crafted email file to an affected device. An exploit could allow
the attacker to cause the ClamAV scanning process crash, resulting in a denial
of service condition.

Fixed in 0.102.2.

Bug#950759: hardened systemd configuration

[Antoine Beaupré]

On 2020-02-08 15:38:48, Martina Ferrari wrote:
> Hi!
>
> On 05/02/2020 20:44, Antoine Beaupre wrote:
>> We recently introduced a new feature where the systemd unit file is
>> hardened. I think it would be a great addition to the Debian package
>> as well, considering that it seems to work for us. Here's the magic
>> incantation that was added:
> Thanks for the report! This seems indeed useful and a good addition.
> Sadly, I don't have the knowledge to evaluate whether these settings can
> have unintended side-effects. Have you (or anybody reading this)
> evaluated that? If so, I would be happy to apply the "patch". Maybe
> adding an one-line explanation to each line would be a good addition too.

The fact that this is running on multiple prometheus deployments feels
sufficient for me to assume this will work. There are multiple users of
this module and I assume that has been thoroughly tested...

a.
-- 
If you have come here to help me, you are wasting our time.
But if you have come because your liberation is bound up with mine, then
let us work together.- Aboriginal activists group, Queensland, 1970s

Bug#911560: [Kinda solved] Re: Network not working on Olimex LIME2 rev K ??

[Jonas Smedegaard]

Quoting Dominique Dumont (2020-02-08 16:07:17)
> On Wednesday, 5 February 2020 19:41:30 CET Vagrant Cascadian wrote:
> >   A20-OLinuXino-Lime 2 Rev. K Ethernet problem - No connection 
> > possible in installer https://bugs.debian.org/911560
> 
> So I've applied the suggestion to build u-boot with 
> 
> CONFIG_GMAC_TX_DELAY=3
> 
> I can confirm that both LIME2 rev G2 and rev K boards have a working 
> network with 1G speed with u-boot version debian/2020.01+dfsg-1 and 
> the tweak above.

That's quite helpful. Thanks!

Even more helpful if you provide a bit more information (if possible):

I guess you mean that the negotiated ethernet mode is 1G.  What is the 
actual performance - i.e. which concrete transfer speeds is achievable, 
in each direction, for each board?

With which kind on low-level network wiring did you test the negotiated 
mode - e.g. cross-over cable to another host or gigabit-capable switch?


Would be great if you could also test with patched u-boot in stable 
Debian - so we can consider fixing this in a point release.


 - 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#950759: hardened systemd configuration

[Martina Ferrari]

Hi!

On 05/02/2020 20:44, Antoine Beaupre wrote:
> We recently introduced a new feature where the systemd unit file is
> hardened. I think it would be a great addition to the Debian package
> as well, considering that it seems to work for us. Here's the magic
> incantation that was added:
Thanks for the report! This seems indeed useful and a good addition.
Sadly, I don't have the knowledge to evaluate whether these settings can
have unintended side-effects. Have you (or anybody reading this)
evaluated that? If so, I would be happy to apply the "patch". Maybe
adding an one-line explanation to each line would be a good addition too.

-- 

Bug#950942: python-oslo.reports: please make the build reproducible

[Chris Lamb]

Source: python-oslo.reports
Version: 1.30.0-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] I noticed that
python-oslo.reports could not be built reproducibly.

This was because the documentation (somewhat-uselessly) generated
documentation for the tests themselves, which revealed some MagicMock
special objects that had had a Python string representation containing
a nondetermistic number.

For example:

  -MM_FILE = MagicMock 
name='file_obj' id='139866970863568'
  +MM_FILE = MagicMock 
name='file_obj' id='140338508670736'

Patch attached that simply skips the API documentation for the tests
from being generated in the first place.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible-build.patch   2020-02-08 15:28:58.005976410 
+
@@ -0,0 +1,11 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2020-02-08
+
+--- python-oslo.reports-1.30.0.orig/doc/source/conf.py
 python-oslo.reports-1.30.0/doc/source/conf.py
+@@ -92,3 +92,4 @@ latex_documents = [
+ # -- sphinxcontrib.apidoc configuration --
+ apidoc_module_dir = '../../oslo_reports'
+ apidoc_output_dir = 'reference/api'
++apidoc_excluded_paths = ['tests']
--- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/series 2020-02-08 15:28:57.149990690 +
@@ -0,0 +1 @@
+reproducible-build.patch

Bug#949887: fixed in munin 2.0.56-1

[Michael Biebl]

Am 08.02.20 um 16:11 schrieb Michael Biebl:
> The sysvinit based munin-cron still fails in 2.0.56-1 so re-opening
> accordingly.

Sorry, meant master-cron:


autopkgtest [04:00:42]:  summary
master-cron  PASS
master-cgi   PASS
master-cron  FAIL non-zero exit status 1
master-cgi   PASS
node PASS
command1 PASS



signature.asc
Description: OpenPGP digital signature

Bug#949887: fixed in munin 2.0.56-1

[Michael Biebl]

Control: found -1 2.0.56-1

On Fri, 07 Feb 2020 23:34:54 + Debian FTP Masters   munin (2.0.56-1) unstable; urgency=medium
>  .
>[ Holger Levsen ]
>* New upstream bugfix release, 2.0.56.
>* Bump standards version to 4.5.0, no changes needed.
>  .
>[ Lars Kruse ]
>* New upstream bugfix release, 2.0.55.
>* Disable test of munin-node with sysvinit. Closes: #949887.

The sysvinit based munin-cron still fails in 2.0.56-1 so re-opening
accordingly.

See
https://ci.debian.net/data/autopkgtest/testing/amd64/m/munin/4227930/log.gz



signature.asc
Description: OpenPGP digital signature

Bug#950941: thunderbird: Remove wrapper for Icedove profile

[Paul Menzel]

Package: thunderbird
Version: 1:68.4.2-1
Severity: normal

Dear Debian folks,


`sudo execsnoop.bt` from the package *bpftrace* shows, Mozilla 
Thunderbird is not started directly, but that `/usr/bin/thunderbird` is 
a wrapper script.



# Purpose:
#   This is a wrapper script for starting the thunderbird binary with taking
#   care of the searching for an old user Icedove profile folder and adopting
#   the folder into the new place if possible.


As Debian migrated from Icedove to Mozilla Thunderbird more than two(?) 
releases ago, it’d be great if the wrapper script was removed.



Kind regards,

Paul

Bug#950940: ITP: pocketsphinx-python -- Speech recognition tool - Python3 bindings

[Samuel Thibault]

Package: wnpp
Severity: wishlist
Owner: Samuel Thibault 

* Package name: pocketsphinx-python
  Version : 0.1.15
  Upstream Author : Dmitry Prazdnichnov 
* URL : https://github.com/bambocher/pocketsphinx-python/
* License : BSD
  Programming Lang: Python
  Description : Speech recognition tool - Python3 bindings

 CMU Sphinx is a large vocabulary, speaker-independent continuous speech
 recognition engine.
 .
 This package contains Python3 bindings for libpocketsphinx.


This is related to the request in bug 943646: the python bindings from
the pocketsphinx package are not evolving as much as people seem to
want, so Dmitry reworked it, and e.g. pypi is now tracking it.  Nickolay
himself said it should be fine to package these Python bindings instead
of those from pocketsphinx, thus proposing doing so.

Samuel

Bug#911560: [Kinda solved] Re: Network not working on Olimex LIME2 rev K ??

[Dominique Dumont]

On Wednesday, 5 February 2020 19:41:30 CET Vagrant Cascadian wrote:
>   A20-OLinuXino-Lime 2 Rev. K Ethernet problem - No connection possible in
> installer https://bugs.debian.org/911560

So I've applied the suggestion to build u-boot with 

CONFIG_GMAC_TX_DELAY=3

I can confirm that both LIME2 rev G2 and rev K boards have a working network 
with 1G speed with  u-boot version debian/2020.01+dfsg-1 and the tweak above.

For the record, here's the recipe to get a working network OlinuXino Lime2 
rev. K :

Setup u-boot source:
- git clone https://salsa.debian.org/debian/u-boot.git
- sudo apt build-dep u-boot

In u-boot:
- apply all debian patches: quilt push -a
- run: make CROSS_COMPILE=arm-linux-gnueabihf- A20-OLinuXino-Lime2_defconfig
- edit .config to set CONFIG_GMAC_TX_DELAY=3
- build u-boot: make CROSS_COMPILE=arm-linux-gnueabihf-


You should get a u-boot-sunxi-with-spl.bin file which is the bootloader to 
install on your SD card (see [1])

First backup your SD card
- sudo cp /dev/$sdcard backup.img

Then copy the bootloader:
- sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/$sdcard bs=1024 seek=8

In both case, $sdcard is to be replaced with the block device file of your SD 
card.

Hope this helps

[1] https://linux-sunxi.org/Bootable_SD_card#Bootloader