Bug#921705: gnome: Please do not override debian-xterm.desktop file

[Ben Wong]

Has there been any move towards a consensus?

I read the bug linked to by the menus.blacklist file. While I don't think
Ubuntu is correct in how confusing the Xterm desktop file would be for
their users, I get that "simplicity" is part of their brand.

Debian, however, is not Ubuntu. From a Debian user's perspective, Xterm's
desktop file not working when the package is installed is confusing. Can we
please not attempt to second-guess what users want when they install xterm?
Note that Debian doesn't do anything similar for Thai X Terminal,
Multilingual Xterm, or any other terminal packages besides Xterm.

Or, at the least, can we make this something that is easily discovered and
fixed? The Gnome Menus blacklist doesn't appear to be mentioned anywhere in
Debian's Xterm documentation:

$ zgrep -i blacklist $(dpkg -L xterm)
$

Further, a local admin who does find the menus.blacklist config would be
wary of editing it for fear of causing an upgrade conflict in the future
requiring manual intervention. ("Configuration file changed by you or a
script. What would you like to do about it?")

Ubuntu's GNOME maintainer, Jeremy Bicha , suggested a
reasonable solution in bug #856858: create a separate package called
xterm-desktop which contains just the .desktop files for Xterm. It can be a
Recommended but not Required package so Ubuntu can simply choose to ship
without it by default, but if a user installs it by hand they'll get the
appropriate desktop files. Since it wouldn't be a config file, local admins
would not suffer from potential conflicts during package updates. And, by
including it explicitly in the package system, local admins might have half
a chance of discovering it and installing it even if the documentation is
not improved.

Thank you for your consideration,

Ben


On Tue, Feb 12, 2019 at 5:48 PM Laurent Bigonville  wrote:

> On Fri, 08 Feb 2019 00:24:58 -0800 Ben Wong 
> wrote:
>
>  > Dear Maintainer,
>
> Hello,
>
> [...]
>  >
>  > It turns out that some part of Gnome is creating a *second* desktop
>  > file which disables the first one by setting NoDisplay = True. This is
>  > extremely frustrating and unnecessary. The file is
>  > /usr/share/gnome/applications/debian-xterm.desktop
>  >
>  > I would like to tell you which part of Gnome is the culprit, but
>  > `dpkg -S` on the file says it doesn't belong to any packages.
>  >
>  > I can understand that certain distributions derived from Debian —
>  > those which believe minimalism equates to simplicity — may wish to
>  > hide "redundant" functionality like `xterm`. However, it doesn't make
>  > sense to hide xterm from Debian users. And if it did, it certainly
>  > should not be implemented in such a hard to discover way.
>
> [...]
>
> The preferred solution to fix this is to modify the
> /etc/gnome/menus.blacklist (that file controls the mechanism applying
> the blacklisting) and then run the gnome-menus-blacklist command.
>
> There is not real consensus in the team about changing this ATM
>
> Kind regards,
>
> Laurent Bigonville
>
>

Bug#938909: Dealing with zope.interface unsatisfiable build-dependency.

[peter green]

zope.interface is currently rc buggy because of an unsatisfiable 
build-depenency on python-zope.event, the package is also orphaned.

The package is a key package, so the issue won't be dealt with by autoremovals, 
furthermore the python-zope.interface package has quite a stack of reverse 
dependencies, so dropping it doesn't seem like a good option at this point.

Testing reveals that the build-dependency in question is only needed by the 
test suite, so I believe the least-bad option is to drop the build-dependency 
and not run the testsuite.

It would be preferable to only disable the testsuite for python2, but I have no 
idea how to do that, so my current debdiff disables the testsuite completely, I 
also ran into an issue with the package's clean target not cleaning up properly.

If anyone can suggest how to modify the package so it runs the testsuite for 
python3 but not python2 that would be appreciated. I plan to go ahead with an 
upload next week.

diff -Nru zope.interface-4.6.0/debian/changelog 
zope.interface-4.6.0/debian/changelog
--- zope.interface-4.6.0/debian/changelog   2019-09-05 11:09:40.0 
+
+++ zope.interface-4.6.0/debian/changelog   2019-12-07 07:00:43.0 
+
@@ -1,3 +1,13 @@
+zope.interface (4.6.0-2) unstable; urgency=medium
+
+  * QA upload.
+  * Drop build-dependency on nonexistent python-zope.event. Downgrades: 
#938909.
+  * Disable testsuite, it needs python-zope.event.
+  * Fix clean target.
+  * Add build-depends on moreutils, needed by fixed clean target.
+
+ -- Peter Michael Green   Sat, 07 Dec 2019 07:00:43 +
+
 zope.interface (4.6.0-1) unstable; urgency=medium
 
   * QA upload.
diff -Nru zope.interface-4.6.0/debian/control 
zope.interface-4.6.0/debian/control
--- zope.interface-4.6.0/debian/control 2019-09-05 11:09:40.0 +
+++ zope.interface-4.6.0/debian/control 2019-12-07 07:00:43.0 +
@@ -12,11 +12,11 @@
python-all-dbg:any,
python-all-dev:any,
python-setuptools,
-   python-zope.event,
python3-all-dbg:any,
python3-all-dev:any,
python3-setuptools,
-   python3-zope.event
+   python3-zope.event,
+   moreutils
 Standards-Version: 4.4.0
 Testsuite: autopkgtest
 Homepage: http://pypi.python.org/pypi/zope.interface
diff -Nru zope.interface-4.6.0/debian/rules zope.interface-4.6.0/debian/rules
--- zope.interface-4.6.0/debian/rules   2016-07-05 21:43:11.0 +
+++ zope.interface-4.6.0/debian/rules   2019-12-07 07:00:43.0 +
@@ -97,3 +97,10 @@
 override_dh_strip:
dh_strip -p$(package) --dbg-package=$(package)-dbg
dh_strip -p$(package3) --dbg-package=$(package3)-dbg
+
+override_dh_auto_test:
+   echo testsuite disabled
+
+override_dh_auto_clean:
+   rm -f .eggs/README.txt
+   rm -f src/zope.interface.egg-info/requires.txt

Bug#946201: ibus: some keystrokes are taken in account

[Changwoo Ryu]

> > > == locale ==
> > > LANG=fr_FR.UTF-8
> > > LANGUAGE=
> > > LC_CTYPE="C"
> > > LC_NUMERIC="C"
> > > LC_TIME="C"
> > > LC_COLLATE="C"
> > > LC_MONETARY="C"
> > > LC_MESSAGES="C"
> > > LC_PAPER="C"
> > > LC_NAME="C"
> > > LC_ADDRESS="C"
> > > LC_TELEPHONE="C"
> > > LC_MEASUREMENT="C"
> > > LC_IDENTIFICATION="C"
> > > LC_ALL=C
> >
> > This can be a problem. 'C" locale is basically ASCII only so some
> > characters won't be input in some applications.
>
> It is weird because if I input locale command in a terminal I get:

Never mind. It was reportbug overriding LC_ALL env variable.

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

Bug#946326: python3-reportbug: reportbug runs bugscript in "C" locale

[Changwoo Ryu]

Package: python3-reportbug
Version: 7.5.3
Severity: normal

reportbug seems to run bugscript in "C" locale. In /usr/lib/python3/dist-
packages/reportbug/utils.py:

rc = runner('LC_ALL=C %s %s %s' % (handler, pipes.quote(bugscript),
pipes.quote(filename)))


It prevents the ibus bugscript from getting "locale" command result. For
example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946201#5

I understand that running locale dependent bugscript can be often buggy and
confusing, but some bugscripts want the locale dependent behavior. I think
settings locale settings should be up to the individual bugscript authors.



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

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

Versions of packages python3-reportbug depends on:
ii  apt1.8.4
ii  file   1:5.37-6
ii  python33.7.5-3
ii  python3-apt1.8.4+b1
ii  python3-debian 0.1.36
ii  python3-debianbts  3.0.2
ii  python3-requests   2.22.0-2
ii  sensible-utils 0.0.12+nmu1

python3-reportbug recommends no packages.

Versions of packages python3-reportbug suggests:
ii  reportbug  7.5.3

-- no debconf information

Bug#936710: html5-parser: Python2 removal in sid/bullseye

[Norbert Preining]

Hi Peter,

> Thank you for fixing the rc aspect of this issue, reopening and downgrading 
> for the broader issue.

Indeed, thanks. I will remove the Py2 version as soon as I drop the
Calibre Py2 version. This will happen sooner or later. The Py3 version
is parallel developed in experimental, but most external plugins are by
now still broken, so I wait for the general Calibre community to move to
Py3.

Best

Norbert

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

Bug#946324: excellent-bifurcation FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: excellent-bifurcation
Version: 0.0.20071015-8
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

excellent-bifurcation fails to cross build from source, because it uses
build architecture build tools. The easiest way of fixing that - using
dh_auto_build - does not suffice, because the upstream Makefile hard
codes the build architecture pkg-config. Another change is necessary to
make that substitutable. Please consider applying the attached patch to
make excellent-bifurcation cross buildable.

Helmut
diff --minimal -Nru excellent-bifurcation-0.0.20071015/debian/changelog 
excellent-bifurcation-0.0.20071015/debian/changelog
--- excellent-bifurcation-0.0.20071015/debian/changelog 2016-06-06 
04:23:40.0 +0200
+++ excellent-bifurcation-0.0.20071015/debian/changelog 2019-12-07 
07:18:14.0 +0100
@@ -1,3 +1,12 @@
+excellent-bifurcation (0.0.20071015-8.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ cross.patch: Make pkg-config substitutable.
++ Let dh_auto_build pass cross tools to make.
+
+ -- Helmut Grohne   Sat, 07 Dec 2019 07:18:14 +0100
+
 excellent-bifurcation (0.0.20071015-8) unstable; urgency=medium
 
   * Make build reproducible by sorting list of source files to ensure
diff --minimal -Nru 
excellent-bifurcation-0.0.20071015/debian/patches/cross.patch 
excellent-bifurcation-0.0.20071015/debian/patches/cross.patch
--- excellent-bifurcation-0.0.20071015/debian/patches/cross.patch   
1970-01-01 01:00:00.0 +0100
+++ excellent-bifurcation-0.0.20071015/debian/patches/cross.patch   
2019-12-07 07:18:12.0 +0100
@@ -0,0 +1,23 @@
+--- excellent-bifurcation-0.0.20071015.orig/src/Makefile
 excellent-bifurcation-0.0.20071015/src/Makefile
+@@ -1,8 +1,9 @@
+ CC=gcc
+ CFLAGS=-Wall -O2
++PKG_CONFIG?=pkg-config
+ PKGCONFIG_FILES=libxdg-basedir
+-PKGCONFIG_CFLAGS= `pkg-config $(PKGCONFIG_FILES) --cflags`
+-PKGCONFIG_LDFLAGS= `pkg-config $(PKGCONFIG_FILES) --libs`
++PKGCONFIG_CFLAGS= `$(PKG_CONFIG) $(PKGCONFIG_FILES) --cflags`
++PKGCONFIG_LDFLAGS= `$(PKG_CONFIG) $(PKGCONFIG_FILES) --libs`
+ LDFLAGS=`allegro-config --libs`
+ SOURCES=$(sort $(shell find . -name "*.c"))
+ OBJECTS=$(SOURCES:.c=.o)
+@@ -14,7 +15,7 @@
+   $(CC) $(OBJECTS) -o $@ $(LDFLAGS) $(PKGCONFIG_LDFLAGS) -lm
+ 
+ .c.o:
+-  $(CC) $(CFLAGS) $(PKGCONFIG_CFLAGS) `pkg-config libxdg-basedir --libs` 
-c $< -o $@
++  $(CC) $(CFLAGS) $(PKGCONFIG_CFLAGS) `$(PKG_CONFIG) libxdg-basedir 
--libs` -c $< -o $@
+ 
+ clean:
+   rm -f $(EXECUTABLE) $(OBJECTS)
diff --minimal -Nru excellent-bifurcation-0.0.20071015/debian/patches/series 
excellent-bifurcation-0.0.20071015/debian/patches/series
--- excellent-bifurcation-0.0.20071015/debian/patches/series2016-06-06 
04:18:00.0 +0200
+++ excellent-bifurcation-0.0.20071015/debian/patches/series2019-12-07 
07:17:37.0 +0100
@@ -5,3 +5,4 @@
 fix_allegro_linker_flag.patch
 fix_hurd_ftbfs.patch
 reproducible-build.patch
+cross.patch
diff --minimal -Nru excellent-bifurcation-0.0.20071015/debian/rules 
excellent-bifurcation-0.0.20071015/debian/rules
--- excellent-bifurcation-0.0.20071015/debian/rules 2015-06-29 
08:03:06.0 +0200
+++ excellent-bifurcation-0.0.20071015/debian/rules 2019-12-07 
07:18:14.0 +0100
@@ -8,4 +8,4 @@
dh_clean
 
 override_dh_auto_build:
-   $(MAKE) -C src CFLAGS="$(CFLAGS) -std=gnu89 
-DDATA_DIR=\\\"/usr/share/games/excellent-bifurcation\\\""
+   dh_auto_build --sourcedirectory=src -- CFLAGS="$(CFLAGS) -std=gnu89 
-DDATA_DIR=\\\"/usr/share/games/excellent-bifurcation\\\""

Bug#946325: gtimer: broken, outdated, embedded copy of AM_PATH_GTK_2_0

[Helmut Grohne]

Source: gtimer
Version: 2.0.0-1.2
Tags: fixed-upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

gtimer fails to cross build from source, because it uses a broken,
outdated, embedded copy of AM_PATH_GTK_2_0 in aclocal.m4. The actual bug
is already fixed, see #895002. gtimer just happens to ship a copy of the
bug. The Debian policy discourages embedded code copies. Please remove
your copy. Failing that, please update your copy and register it with
the security tracker. See https://wiki.debian.org/EmbeddedCodeCopies for
how to do that. This bug report comes without a patch, because the
actual issue is already fixed.

Helmut

Bug#946323: simh FTCBFS: fuses compiler flags into CC

[Helmut Grohne]

Source: simh
Version: 3.8.1-6
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

simh fails to cross build from source, because the upstream Makefile
fuses compiler flags into the CC variable. When dh_auto_build
substitutes CC, those flags get lost and the build fails. Moving the
flags to a separate variabel (usually called CFLAGS) fixes the cross
build. Please consider applying the attached patch.

Helmut
diff -u simh-3.8.1/makefile simh-3.8.1/makefile
--- simh-3.8.1/makefile
+++ simh-3.8.1/makefile
@@ -1,7 +1,8 @@
 # Simh makefile for Debian Package
 #
 OS_CCDEFS = -lrt -D_GNU_SOURCE
-CC = gcc -std=c99 -O2 -U__STRICT_ANSI__ -g $(OS_CCDEFS) -I .
+CC = gcc
+CFLAGS = -std=c99 -O2 -U__STRICT_ANSI__ -g $(OS_CCDEFS) -I .
 LIBS = -lm -lrt
 USE_NETWORK = 1
 
@@ -278,120 +279,120 @@
 eclipseemu : ${ECLIPSEEMU} ${SIM}
-	${CC} ${ECLIPSEEMU} ${SIM} ${ECLIPSEEMU_OPT} -o $@ ${LDFLAGS} ${LIBS}
+	${CC} ${CFLAGS} ${ECLIPSEEMU} ${SIM} ${ECLIPSEEMU_OPT} -o $@ ${LDFLAGS} ${LIBS}
 
 pdp1 : ${PDP1} ${SIM}
-	${CC} ${PDP1} ${SIM} ${PDP1_OPT} -o $@ ${LDFLAGS} ${LIBS}
+	${CC} ${CFLAGS} ${PDP1} ${SIM} ${PDP1_OPT} -o $@ ${LDFLAGS} ${LIBS}
 
 pdp4 : ${PDP18B} ${SIM}
-	${CC} ${PDP18B} ${SIM} ${PDP4_OPT} -o $@ ${LDFLAGS} ${LIBS}
+	${CC} ${CFLAGS} ${PDP18B} ${SIM} ${PDP4_OPT} -o $@ ${LDFLAGS} ${LIBS}
 
 pdp7 : ${PDP18B} ${SIM}
-	${CC} ${PDP18B} ${SIM} ${PDP7_OPT} -o $@ ${LDFLAGS} ${LIBS}
+	${CC} ${CFLAGS} ${PDP18B} ${SIM} ${PDP7_OPT} -o $@ ${LDFLAGS} ${LIBS}
 
 pdp8 : ${PDP8} ${SIM}
-	${CC} ${PDP8} ${SIM} ${PDP8_OPT} -o $@ ${LDFLAGS} ${LIBS}
+	${CC} ${CFLAGS} ${PDP8} ${SIM} ${PDP8_OPT} -o $@ ${LDFLAGS} ${LIBS}
 
 pdp9 : ${PDP18B} ${SIM}
-	${CC} ${PDP18B} ${SIM} ${PDP9_OPT} -o $@ ${LDFLAGS} ${LIBS}
+	${CC} ${CFLAGS} ${PDP18B} ${SIM} ${PDP9_OPT} -o $@ ${LDFLAGS} ${LIBS}
 
 pdp15 : ${PDP18B} ${SIM}
-	${CC} ${PDP18B} ${SIM} ${PDP15_OPT} -o $@ ${LDFLAGS} ${LIBS}
+	${CC} ${CFLAGS} ${PDP18B} ${SIM} ${PDP15_OPT} -o $@ ${LDFLAGS} ${LIBS}
 
 pdp10 : ${PDP10} ${SIM}
-	${CC} ${PDP10} ${SIM} ${PDP10_OPT} -o $@ ${LDFLAGS} ${LIBS}
+	${CC} ${CFLAGS} ${PDP10} ${SIM} ${PDP10_OPT} -o $@ ${LDFLAGS} ${LIBS}
 
 pdp11 : ${PDP11} ${SIM}
-	${CC} ${PDP11} ${SIM} ${PDP11_OPT} -o $@ ${LDFLAGS} ${LIBS}
+	${CC} ${CFLAGS} ${PDP11} ${SIM} ${PDP11_OPT} -o $@ ${LDFLAGS} ${LIBS}
 
 vax : ${VAX} ${SIM}
-	${CC} ${VAX} ${SIM} ${VAX_OPT} -o $@ ${LDFLAGS} ${LIBS}
+	${CC} ${CFLAGS} ${VAX} ${SIM} ${VAX_OPT} -o $@ ${LDFLAGS} ${LIBS}
 
 vax780 : ${VAX780} ${SIM}
-	${CC} ${VAX780} ${SIM} ${VAX780_OPT} -o $@ ${LDFLAGS} ${LIBS}
+	${CC} ${CFLAGS} ${VAX780} ${SIM} ${VAX780_OPT} -o $@ ${LDFLAGS} ${LIBS}
 
 dgnova : ${NOVA} ${SIM}
-	${CC} ${NOVA} ${SIM} ${NOVA_OPT} -o $@ ${LDFLAGS} ${LIBS}
+	${CC} ${CFLAGS} ${NOVA} ${SIM} ${NOVA_OPT} -o $@ ${LDFLAGS} ${LIBS}
 
 h316 : ${H316} ${SIM}
-	${CC} ${H316} ${SIM} ${H316_OPT} -o $@ ${LDFLAGS} ${LIBS}
+	${CC} ${CFLAGS} ${H316} ${SIM} ${H316_OPT} -o $@ ${LDFLAGS} ${LIBS}
 
 hp2100 : ${HP2100} ${SIM}
-	${CC} ${HP2100} ${SIM} ${HP2100_OPT} -o $@ ${LDFLAGS} ${LIBS}
+	${CC} ${CFLAGS} ${HP2100} ${SIM} ${HP2100_OPT} -o $@ ${LDFLAGS} ${LIBS}
 
 i1401 : ${I1401} ${SIM}
-	${CC} ${I1401} ${SIM} ${I1401_OPT} -o $@ ${LDFLAGS} ${LIBS}
+	${CC} ${CFLAGS} ${I1401} ${SIM} ${I1401_OPT} -o $@ ${LDFLAGS} ${LIBS}
 
 i1620 : ${I1620} ${SIM}
-	${CC} ${I1620} ${SIM} ${I1620_OPT} -o $@ ${LDFLAGS} ${LIBS}
+	${CC} ${CFLAGS} ${I1620} ${SIM} ${I1620_OPT} -o $@ ${LDFLAGS} ${LIBS}
 
 i7094 : ${I7094} ${SIM}
-	${CC} ${I7094} ${SIM} ${I7094_OPT} -o $@ ${LDFLAGS} ${LIBS}
+	${CC} ${CFLAGS} ${I7094} ${SIM} ${I7094_OPT} -o $@ ${LDFLAGS} ${LIBS}
 
 system3 : ${SYSTEM3} ${SIM}
-	${CC} ${SYSTEM3} ${SIM} ${SYSTEM3_OPT} -o $@ ${LDFLAGS} ${LIBS}
+	${CC} ${CFLAGS} ${SYSTEM3} ${SIM} ${SYSTEM3_OPT} -o $@ ${LDFLAGS} ${LIBS}
 
 altair : ${ALTAIR} ${SIM}
-	${CC} ${ALTAIR} ${SIM} ${ALTAIR_OPT} -o $@ ${LDFLAGS} ${LIBS}
+	${CC} ${CFLAGS} ${ALTAIR} ${SIM} ${ALTAIR_OPT} -o $@ ${LDFLAGS} ${LIBS}
 
 altairz80 : ${ALTAIRZ80} ${SIM} 
-	${CC} ${ALTAIRZ80} ${SIM} ${ALTAIRZ80_OPT} -o $@ ${LDFLAGS} ${LIBS}
+	${CC} ${CFLAGS} ${ALTAIRZ80} ${SIM} ${ALTAIRZ80_OPT} -o $@ ${LDFLAGS} ${LIBS}
 
 gri909 : ${GRI} ${SIM}
-	${CC} ${GRI} ${SIM} ${GRI_OPT} -o $@ ${LDFLAGS} ${LIBS}
+	${CC} ${CFLAGS} ${GRI} ${SIM} ${GRI_OPT} -o $@ ${LDFLAGS} ${LIBS}
 
 lgp : ${LGP} ${SIM}
-	${CC} ${LGP} ${SIM} ${LGP_OPT} -o $@ ${LDFLAGS} ${LIBS}
+	${CC} ${CFLAGS} ${LGP} ${SIM} ${LGP_OPT} -o $@ ${LDFLAGS} ${LIBS}
 
 id16 : ${ID16} ${SIM}
-	${CC} ${ID16} ${SIM} ${ID16_OPT} -o $@ ${LDFLAGS} ${LIBS}
+	${CC} ${CFLAGS} ${ID16} ${SIM} ${ID16_OPT} -o $@ ${LDFLAGS} ${LIBS}
 
 id32 : ${ID32} ${SIM}
-	${CC} ${ID32} ${SIM} ${ID32_OPT} -o $@ ${LDFLAGS} ${LIBS}
+	${CC} ${CFLAGS} ${ID32} ${SIM} ${ID32_OPT} -o $@ ${LDFLAGS} ${LIBS}
 
 sds : ${SDS} ${SIM}
-	${CC} ${SDS} ${SIM} ${SDS_OPT} -o $@ ${LDFLAGS} ${LIBS}
+	${CC} ${CFLAGS} ${SDS} ${SIM} ${SDS_OPT} -o $@ ${LDFLAGS} ${LIBS}
 
 macro1 : ${MACRO1}
-	${CC} ${MACRO1} -o $@
+	${CC} ${CFLAGS} ${MACRO1} -o $@
 
 macro7 : ${MACRO7}
-	${CC} ${MACRO7} -o $@
+	${CC} ${CFLAGS} ${MACRO7} -o

Bug#945501: python-statsmodels-doc: unhandled symlink to directory conversion: /usr/share/doc/python-statsmodels-doc/examples

[peter green]

Should the package attempt to clean this up (and if so is there a better
method than unconditionally deleting those directories), or is
permanently leaving this behind (to become more and more obsolete, and
potentially be read by users looking for the current documentation) the
best that can be safely done?

Personally, I would be tempted to add the cleanup code, then remove it again in 
a couple of months. That should clean up the majority of systems, while not 
leaving aggressive cleanup code in a stable release.

Bug#840782: closed by Hideki Yamane (Bug#840782: fixed in fontforge 1:20190801~dfsg-1)

[Helmut Grohne]

Control: reopen -1
Control: affects -1 - src:fontforge

On Sat, Nov 09, 2019 at 07:03:03PM +, Debian Bug Tracking System wrote:
> Changes:
>  fontforge (1:20190801~dfsg-1) experimental; urgency=medium
>  .
>* New upstream version 20190801~dfsg (Closes: #866690, #912062)
>* debian/control{,.in}
>  - remove Christian Perrier  from Uploaders
>(Closes: #894873, #927590)
>  - add Rules-Requires-Root: no
>  - bump up libfontforge3 from 2
>  - migrate to python3 (Closes: #936538)
>  - set Multi-Arch: foreign for -common,doc
>  - drop gnulib (Closes: #840782)

While your change to fontforge is gnulib-related. The bug you closed is
with gnulib, not fontforge. It no longer affects fontforge, but it's
still there.

Helmut

Bug#936710: html5-parser: Python2 removal in sid/bullseye

[peter green]

reopen 936710
severity 936710 normal
thanks

Thank you for fixing the rc aspect of this issue, reopening and downgrading for 
the broader issue.

Bug#936454: dulwich: Python2 removal in sid/bullseye

[peter green]

severity 936454 serious
thanks

dulwich build-depends on the python-fastimport binary package, which is no 
longer built by the python-fastimport source package and is gone from 
testing/unstable.

Bug#946322: dbus: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: dbus
Version: 1.12.16-2
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The dbus tests currently fail in this environment, because they include
build tests that do not invoke the toolchain in a cross-aware manner.  I've
verified that the attached patch lets the tests successfully build (and run)
i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru dbus-1.12.16/debian/tests/build dbus-1.12.16/debian/tests/build
--- dbus-1.12.16/debian/tests/build 2019-09-30 00:47:02.0 -0700
+++ dbus-1.12.16/debian/tests/build 2019-12-06 21:22:14.0 -0800
@@ -12,6 +12,12 @@
 
 cd "$AUTOPKGTEST_TMP"
 
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 echo "1..1"
 
 cat > connect.c <<'EOF'
@@ -42,7 +48,7 @@
 # We don't exercise static linking because libsystemd is not available
 # as a static library.
 
-gcc -o connect connect.c $(pkg-config --cflags --libs dbus-1)
+${CROSS_COMPILE}gcc -o connect connect.c $(${CROSS_COMPILE}pkg-config --cflags 
--libs dbus-1)
 test -x connect
 dbus-run-session -- ./connect
 echo "# everything seems OK"

Bug#946321: gir1.2-ggit-1.0: Incorrect Python override path

[Changwoo Ryu]

Package: gir1.2-ggit-1.0
Version: 0.28.0.1-1+b1
Severity: normal

$ dpkg -S /usr/lib/python3/dist-packages/gi/overrides/overrides/Ggit.py
gir1.2-ggit-1.0:amd64: /usr/lib/python3/dist-
packages/gi/overrides/overrides/Ggit.py
$

gir1.2-ggit-1.0 has /usr/lib/python3/dist-
packages/gi/overrides/overrides/Ggit.py (overrides under overrides) which looks
like incorrect install.



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

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

Versions of packages gir1.2-ggit-1.0 depends on:
ii  gir1.2-glib-2.0 1.62.0-2
ii  libgit2-glib-1.0-0  0.28.0.1-1+b1

gir1.2-ggit-1.0 recommends no packages.

gir1.2-ggit-1.0 suggests no packages.

-- no debconf information

Bug#946320: lintian: Adjust blacklist on lindsay.d.o

[Felix Lechner]

Package: lintian
Severity: wishlist
Control: block -1 by 926543

Hi,

Following the resolution of #926543, several packages can be removed
from the blacklist in config.yaml. Please upgrade lindsay.d.o to the
latest git revision before making the change.

I only tested the latest source packages:

- firefox
- firefox-esr
- opentk
- pilot-link
- twoftpd
- khronos-opencl-man
- libnb-platform18-java
- netbeans
- thunderbird

Kind regards
Felix

Bug#946282: wireguard broken by iptables 1.8.4

[Jeff King]

On Fri, Dec 06, 2019 at 05:48:40PM -0500, Daniel Kahn Gillmor wrote:

> Upstream commit 884b6e36e6af0c6fa5b9467ccc8c2e2e4477bc95 should fix this
> empty line problem, if i'm understanding it correctly.  That commit is
> part of 0.0.20191206, which i've just uploaded to unstable.  Could you
> try that out and report back if it solves the problem?

Yes, it works perfectly. Thanks for the quick response!

-Peff

Bug#946240: grub-xen-host: Missing ARM Build

[Elliott Mitchell]

On Fri, Dec 06, 2019 at 03:26:12PM +, Colin Watson wrote:
> On Fri, Dec 06, 2019 at 06:20:36AM -0800, Elliott Mitchell wrote:
> > The former has been deprecated, the latter is very much active and
> > apparently usable.  GRUB's support for working with Xen on ARM may merely
> > be preliminary, in which case the issue is GRUB.
> 
> I can tell you that such support is nonexistent, not merely preliminary
> (aside from the ability to boot a hypervisor, as I mentioned; but that's
> not what grub-xen-host is about).

Yeah, a few minutes of thinking and realized the situation and how silly
I was being thinking this was likely possible out of the box.  Bit of
brain going funky.  %-/

> > I would expect grub-xen-host to be minimally different between ARM and
> > x86.
> 
> Much of the support for running in PV mode on x86-based Xen is of course
> written as relatively generic C code that ought to be usable on other
> architectures, but there are essential pieces (at minimum: startup code,
> the hypercall ABI, a relocator, and the build system) that nobody has
> yet implemented for Xen on ARM, or if they have then I haven't seen it
> and the work doesn't seem to have gone upstream.  I'm sure it would be
> welcomed, but it wouldn't be entirely trivial.

Hrmm.  That is distinctly suboptimal.  This seems like a rather major
weakness for trying to run Xen on ARM.  In other news the
Raspberry PI 4B has hardware which matches the profile for running Xen.
There appears to be a distinct pool of people trying to run Xen on
Raspberry PI devices (I'm not the only one, I think I've got rather more
of a clue than most, doesn't mean I'm anywhere near perfect).


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

Bug#946319: installation-reports: Submission of successful installation

[Diogo]

Package: installation-reports
Severity: minor

Dear Maintainer,

This is a submission of a report (after a successful installation) to
contribute to the hardware statistics.

Be free to contact me if you need additional information.



-- Package-specific info:

Boot method: usb
Image version: netinstall 10.2.0 torrent
Date: 

Machine: AMD200GE Gigabyte B450M S2H
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [ ]
Detect network card:[ ]
Configure network:  [ ]
Detect CD:  [ ]
Load installer modules: [ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:




-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20190702+deb10u2"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux silo-test 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1 
(2019-09-20) x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:15d0]
lspci -knn: Subsystem: Advanced Micro Devices, Inc. [AMD] Device [1022:15d0]
lspci -knn: 00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Device 
[1022:15d1]
lspci -knn: Subsystem: Advanced Micro Devices, Inc. [AMD] Device [1022:15d1]
lspci -knn: 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:1452]
lspci -knn: 00:01.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:15d3]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:1452]
lspci -knn: 00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:15db]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:08.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:15dc]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus 
Controller [1022:790b] (rev 61)
lspci -knn: Subsystem: Gigabyte Technology Co., Ltd Device [1458:5001]
lspci -knn: 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH 
LPC Bridge [1022:790e] (rev 51)
lspci -knn: Subsystem: Gigabyte Technology Co., Ltd Device [1458:5001]
lspci -knn: 00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:15e8]
lspci -knn: 00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:15e9]
lspci -knn: 00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:15ea]
lspci -knn: 00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:15eb]
lspci -knn: 00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:15ec]
lspci -knn: 00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:15ed]
lspci -knn: 00:18.6 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:15ee]
lspci -knn: 00:18.7 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:15ef]
lspci -knn: 01:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:43d5] (rev 01)
lspci -knn: Subsystem: ASMedia Technology Inc. Device [1b21:1142]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 01:00.1 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:43c8] (rev 01)
lspci -knn: Subsystem: ASMedia Technology Inc. Device [1b21:1062]
lspci -knn: Kernel driver in use: ahci
lspci -knn: Kernel modules: ahci
lspci -knn: 01:00.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:43c6] (rev 01)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 02:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:43c7] (rev 01)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 02:01.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:43c7] (rev 01)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 02:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:43c7] (rev 01)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 02:05.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:43c7] (rev 01)
lspci -knn: Kernel driver in use: 

Bug#877783: spyne_2.13.11a0-0.1_source.changes REJECTED

[Russell Stuart]

On Fri, 2019-12-06 at 13:25 +0100, Bastian Germann wrote:
> Hi Sandro,
> 
> would you please reupload with the binary package? The package is
> still available on https://mentors.debian.net/package/spyne.

Perhaps you missed it as I only replied to the Debian bug, but I am not
OK with an alpha version ending up in testing:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877783#30

If you still want to do this upload the alpha version to experimental. 
If you do proceed any with uploading the alpha version to unstable I
will replace it with the old version.



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

Bug#914398: (no subject)

[Sean Whitton]

control: tag 914398 + patch
control: tag 914399 + patch

Hello Ian,

I've been using my perl git-branchmove for long enough now that I think
it would be good to upstream it into chiark-utils.

-- 
Sean Whitton
From 3643cd09c5a77d2f4e4ab7a02c6e3eb541dfa440 Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Fri, 6 Dec 2019 18:19:31 -0700
Subject: [PATCH] git-branchmove: rewrite in perl

Closes: #914398, #914399

Signed-off-by: Sean Whitton 
---
 debian/changelog   |   8 +
 debian/control |   2 +-
 debian/copyright   |   3 +
 scripts/git-branchmove | 404 +
 4 files changed, 219 insertions(+), 198 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 55e2097..f60b7da 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+chiark-utils (6.1.0~) unstable; urgency=medium
+
+  [ Sean Whitton ]
+  * git-branchmove: rewrite in perl (Closes: #914398, #914399)
+- Add dependencies on libgit-wrapper-perl, libtry-tiny-perl.
+
+ --
+
 chiark-utils (6.0.4) unstable; urgency=medium
 
   * sync-accounts: Fix perl syntax error.  Closes:#865985.
diff --git a/debian/control b/debian/control
index 11e1559..db619bb 100644
--- a/debian/control
+++ b/debian/control
@@ -25,7 +25,7 @@ Section: admin
 Priority: extra
 Conflicts: chiark-named-conf, sync-accounts
 Replaces: chiark-named-conf, sync-accounts
-Depends: ${misc:Depends}
+Depends: ${misc:Depends}, libgit-wrapper-perl, libtry-tiny-perl
 Suggests: tcl8.4, python3, gdb
 Architecture: all
 Description: chiark system administration scripts
diff --git a/debian/copyright b/debian/copyright
index 5f44a80..e641751 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -91,6 +91,9 @@ with-lock-ex
 fishdescriptor
  Copyright 2018 Citrix
 
+git-branchmove
+ Copyright 2019 Sean Whitton 
+
 The chiark utilities are all free software; you can redistribute them
 and/or modify them under the terms of the GNU General Public License
 as published by the Free Software Foundation; either version 3 of the
diff --git a/scripts/git-branchmove b/scripts/git-branchmove
index 5751c38..156078f 100755
--- a/scripts/git-branchmove
+++ b/scripts/git-branchmove
@@ -1,201 +1,211 @@
-#!/bin/bash
+#!/usr/bin/perl
+
+# git-branchmove -- move branches to or from a remote
+
+# Copyright (C) 2019 Sean Whitton
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or (at
+# your option) any later version.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+# General Public License for more details.
 #
-# Moves a branch to or from the current git tree to or from
-# another git tree
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+
+# This script is based on Ian Jackson's git-branchmove script, in the
+# chiark-utils Debian source package.  Ian's script assumes throughout
+# that it is possible to have unrestricted shell access to the remote,
+# however, while this script avoids that global assumption.
 #
-# usage:   git-branchmove get|put REMOTE PATTERN
-
-set -e
-set -o posix
-
-fail () { echo >&2 "git-branchmove: $*"; exit 16; }
-badusage () { fail "bad usage: $*"; }
-
-if [ $# -lt 3 ]; then badusage "too few arguments"; fi
-
-op="$1"; shift
-case "$op" in get|put) ;; *) badusage "unknown operation \`$op'"; esac
-
-remote="$1"; shift
-
-# Plan of attack:
-#  determine execute-sh runes for src and dst trees
-#  list affected branches on source
-#  check that source branches are not checked out
-#  list affected branches on destination and moan if any nonequal overlap
-#  transfer src->dst refs/heads/BRANCH:refs/heads/BRANCH
-#  transfer and merge reflog(s) xxx todo
-#  delete src refs
-
-case "$remote" in
-*:*)	remoteurl="$remote" ;;
-[/.]*)	remoteurl="$remote" ;;
-*)	remoteurl="$(
-		git config remote."$remote".pushurl ||
-		git config remote."$remote".url ||
-		fail "no pushurl or url defined for remote $remote"
-		)"
-	remotename="$remote"
-esac
-
-remote_spec="$(perl -e '
-$_ = $ARGV[0];
-if (m#^ssh://([^:/]+)(?:\:(\w+))?#) {
-	print "$'\''|ssh ";
-	print " -p $3" if $2;
-print "$1\n";
-} elsif (m#^([-+_.0-9a-zA-Z\@]+):(?!//|:)#) {
-print "$'\''|ssh $1\n";
-} elsif (m#^[/.]#) {
-print "$_|sh -c $1\n";
+# As much as possible we treat the remote argument as opaque, i.e., we
+# don't distinguish between git URIs and named remotes.  That means
+# that git will expand insteadOf and pushInsteadOf user config for us.
+
+=head1 NAME
+
+git-branchmove - move branches to or from a remote
+
+=head1 SYNOPSIS
+
+B [B<--detach>|B<-d>] B|B I I...
+
+=head1 DESCRIPTION
+
+Move branches matching I to 

Bug#933098: RFA: xskat -- 3-player card game "Skat"

[Barmettler Lars]

Hei Florian

I'm a newcomer in the Debian development community and would like to ask 
if I'm allowed to take over your game?

Friendly Greeting

theMaimu


On Fri, 26 Jul 2019 19:44:48 +0200 Florian Ernst  
wrote:

 > Package: wnpp
 > Severity: normal
 >
 > I request an adopter for the xskat package as I am hardly using it
 > anymore. The packaging is easy enough, so this will be easily suitable
 > for any newcomer, with maybe a first task of slavaging the old VCS
 > repository from anonscm.debian.org. However, there also isn't all too
 > much upstream activity either over the last years, with the last release
 > being from 2004 ...
 >
 > The package description is:
 > Xskat lets you play the card game Skat as defined by the official
 > German "Skatordnung".
 > .
 > You can play by sending a window to the other player's X display, or
 > via an IRC server. The computer can also simulate players.
 > .
 > Many unofficial rules like "Ramsch" or "Bock" are supported.
 >
 >

Bug#946318: changelog.gz for palapeli is missing

[shirish शिरीष]

Package: palapeli
Version: 4:19.08.1-1+b1
Severity: normal

Dear maintainer,

I was updating and upgraded palapeli today. I wanted to check what the
new things were but it seems changelog.gz is missing. From the package
-

/usr/share/doc/palapeli$ ls
changelog.Debian.amd64.gz  changelog.Debian.gz  copyright

Can you please fix it.

If it's an issue you can get the mirror of writing the changelog from
the git entries on the kde git repo. [1] or the github repo [2].

1. git clone https://anongit.kde.org/palapeli
2. https://github.com/KDE/palapeli

Please use either of the above to make changelog. Looking forward to the fix.

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

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

Versions of packages palapeli depends on:
ii  kio   5.62.1-2+b1
ii  libc6 2.29-3
ii  libkf5archive55.62.0-1
ii  libkf5completion5 5.62.0-1+b1
ii  libkf5configcore5 5.62.0-1+b1
ii  libkf5configgui5  5.62.0-1+b1
ii  libkf5configwidgets5  5.62.0-1+b1
ii  libkf5coreaddons5 5.62.0-1
ii  libkf5crash5  5.62.0-1+b1
ii  libkf5i18n5   5.62.0-1
ii  libkf5itemviews5  5.62.0-1+b1
ii  libkf5kiowidgets5 5.62.1-2+b1
ii  libkf5notifications5  5.62.0-1+b1
ii  libkf5service-bin 5.62.0-1
ii  libkf5service55.62.0-1
ii  libkf5widgetsaddons5  5.62.0-1+b1
ii  libkf5xmlgui5 5.62.0-1+b1
ii  libqt5core5a  5.12.5+dfsg-2
ii  libqt5gui55.12.5+dfsg-2
ii  libqt5svg55.12.5-2
ii  libqt5widgets55.12.5+dfsg-2
ii  libstdc++69.2.1-21
ii  palapeli-data 4:19.08.1-1

Versions of packages palapeli recommends:
ii  khelpcenter  4:18.04.0-1+b1
ii  qhull-bin2015.2-4

palapeli suggests no packages.

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#946317: the homepage link given for palapelig is wrong

[shirish शिरीष]

Package: palapeli
Version: 4:19.08.1-1+b1
Severity: normal

Dear Maintainer,
The homepage link given for palapeli is wrong. It should be
https://kde.org/applications/games/org.kde.palapeli instead of
http://games.kde.org/ which doesn't tell anything anyhow as it's so
old :(

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

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

Versions of packages palapeli depends on:
ii  kio   5.62.1-2+b1
ii  libc6 2.29-3
ii  libkf5archive55.62.0-1
ii  libkf5completion5 5.62.0-1+b1
ii  libkf5configcore5 5.62.0-1+b1
ii  libkf5configgui5  5.62.0-1+b1
ii  libkf5configwidgets5  5.62.0-1+b1
ii  libkf5coreaddons5 5.62.0-1
ii  libkf5crash5  5.62.0-1+b1
ii  libkf5i18n5   5.62.0-1
ii  libkf5itemviews5  5.62.0-1+b1
ii  libkf5kiowidgets5 5.62.1-2+b1
ii  libkf5notifications5  5.62.0-1+b1
ii  libkf5service-bin 5.62.0-1
ii  libkf5service55.62.0-1
ii  libkf5widgetsaddons5  5.62.0-1+b1
ii  libkf5xmlgui5 5.62.0-1+b1
ii  libqt5core5a  5.12.5+dfsg-2
ii  libqt5gui55.12.5+dfsg-2
ii  libqt5svg55.12.5-2
ii  libqt5widgets55.12.5+dfsg-2
ii  libstdc++69.2.1-21
ii  palapeli-data 4:19.08.1-1

Versions of packages palapeli recommends:
ii  khelpcenter  4:18.04.0-1+b1
ii  qhull-bin2015.2-4

palapeli suggests no packages.

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#946301: Should depend on php-twig < 3

[David Prévot]

Control: reassign -1 php-twig-extensions, php-twig
Control: found -1 php-twig-extensions/1.5.4-1
Control: found -1 php-twig/3.0.0~beta1-1

Hi,

Le 06/12/2019 à 12:36, Felipe Sateler a écrit :
>> Package: php-twig-extensions
>> Version: 1.5.4-1
>> Severity: wishlist

>> With php-twig 3 now in experimental, you may wish to add an explicit
>> Depends: php-twig < 3
>> override in your control file (due to #765899
[…]
>> the next upstream version should not be affected by this issue [1]).
> 
>> 1: 
>> https://github.com/twigphp/Twig-extensions/blob/master/composer.json#L15

> I looked at the upstream page to look if the new upstream version added
> compat for twig 3,
> and it says:
> 
> WARNING: This repository is abandoned in favor of Twig Core Extra
> extensions.
> 
> Maybe php-twig should just Breaks: php-twig-extensions

You’re right, I could do that too. Reassigning the bug report to both
packages to document the alternative.

> and phpmyadmin
> should migrate to Twig Core Extra extensions

FYI, a php-twig version providing binary packages for those extensions
is already in the NEW queue with some of its (build-)dependencies. Once
processed by the ftpmasters, I already plan to add those binary packages
to the php-twig version 2 in Sid (2.12 currently), I already need them
for symfony 4.4 (also in NEW queue).

Once phpMyAdmin migrates to Twig Core Extra extensions, you should have
those dependencies ready.

I don’t know yet witch php-twig version (2 or 3) will be used for
Bullseye, that will obviously depend on what phpmyadmin and cacti (the
current packages currently depending on it) will be ready for before the
freeze (assuming symfony 4.4 will stay compatible with both major versions).

Regards

David



signature.asc
Description: OpenPGP digital signature

Bug#657390: lintian: Non-dh debhelper targets?

[Felix Lechner]

Hi,

> Once build-arch and build-indep are supported by dpkg-buildpackage,
> hopefully in the next week, and/or are required by Policy, please
> could you apply the attached patch to move build-arch and build-indep
> from recommended to required?

With many people now using dh over the older explicit targets [1], is
this patch still needed?

Kind regards,
Felix Lechner

[1] According to trends.debian.net, only about 6% of packages use
debhelper currently.

Bug#946303: dbus-glib: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: dbus-glib
Followup-For: Bug #946303
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Here is a better patch that accounts for the test being set -u, and also
works when NOT cross-testing.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru dbus-glib-0.110/debian/tests/build dbus-glib-0.110/debian/tests/build
--- dbus-glib-0.110/debian/tests/build  2019-01-29 01:44:28.0 -0800
+++ dbus-glib-0.110/debian/tests/build  2019-12-06 15:39:24.0 -0800
@@ -12,6 +12,12 @@
 
 cd "$AUTOPKGTEST_TMP"
 
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 echo "1..2"
 
 cat > connect.c <<'EOF'
@@ -42,7 +48,7 @@
 
 # Deliberately word-splitting, that's how pkg-config works:
 # shellcheck disable=SC2046
-gcc -o connect connect.c $(pkg-config --cflags --libs dbus-glib-1)
+${CROSS_COMPILE}gcc -o connect connect.c $(${CROSS_COMPILE}pkg-config --cflags 
--libs dbus-glib-1)
 test -x connect
 dbus-run-session -- ./connect
 echo "ok 1"

Bug#946294: clutter-1.0: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: clutter-1.0
Version: 1.26.2+dfsg-12
Followup-For: Bug #946294
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

> I've verified that the attached patch lets the tests successfully build
> (and run) i386 tests on an amd64 host.

Sorry, this part was a lie (via cut'n'paste); I failed to notice that this
test was set -u, so it actually broke for all *non* cross cases.

The attached patch should be better.
diff -Nru clutter-1.0-1.26.2+dfsg/debian/tests/build 
clutter-1.0-1.26.2+dfsg/debian/tests/build
--- clutter-1.0-1.26.2+dfsg/debian/tests/build  2019-08-27 02:44:04.0 
-0700
+++ clutter-1.0-1.26.2+dfsg/debian/tests/build  2019-12-06 15:23:12.0 
-0800
@@ -11,6 +11,13 @@
 export XDG_RUNTIME_DIR="$WORKDIR"
 trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
 cd $WORKDIR
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 cat < cally.c
 #include 
 
@@ -53,7 +60,7 @@
 ;;
 esac
 
-gcc -o "${lib}-test" "${code}" $(pkg-config --cflags --libs ${packages})
+${CROSS_COMPILE}gcc -o "${lib}-test" "${code}" 
$(${CROSS_COMPILE}pkg-config --cflags --libs ${packages})
 echo "build ($lib): OK"
 [ -x "${lib}-test" ]
 dbus-run-session -- xvfb-run -a "./${lib}-test"

Bug#946281: transition: liblouis

[Samuel Thibault]

Hello,

Paul Gevers, le ven. 06 déc. 2019 21:09:01 +0100, a ecrit:
> On 06-12-2019 17:15, Samuel Thibault wrote:
> > Upstream of liblouis cleaned the library interface in version 3.12,
> > leading to a bump from liblouis19 to liblouis20. I am thus requesting
> > a transition slot. The only build rdeps are brltty, liblouisxml and
> > liblouisutdml, which I could check as building and running fine.
> 
> Please go ahead.

It is now in.

Samuel

Bug#946316: Please add a dependency on node-pako and remove embedded copies

[Louis-Philippe Véronneau]

Package: novnc
Severity: normal

Dear Maintainers,

I'm really not familiar with this project's codebase, but it seems you
are embedding a copy of node-pako:

/usr/share/novnc/vendor/pako/README.md
/usr/share/novnc/vendor/pako/lib/utils/common.js
/usr/share/novnc/vendor/pako/lib/zlib/adler32.js
/usr/share/novnc/vendor/pako/lib/zlib/constants.js
/usr/share/novnc/vendor/pako/lib/zlib/crc32.js
/usr/share/novnc/vendor/pako/lib/zlib/deflate.js
/usr/share/novnc/vendor/pako/lib/zlib/gzheader.js
/usr/share/novnc/vendor/pako/lib/zlib/inffast.js
/usr/share/novnc/vendor/pako/lib/zlib/inflate.js
/usr/share/novnc/vendor/pako/lib/zlib/inftrees.js
/usr/share/novnc/vendor/pako/lib/zlib/messages.js
/usr/share/novnc/vendor/pako/lib/zlib/trees.js
/usr/share/novnc/vendor/pako/lib/zlib/zstream.js

Those same file seem to be provided by the node-panko Debian package:

/usr/lib/nodejs/pako/lib/utils/common.js
/usr/lib/nodejs/pako/lib/zlib/adler32.js
/usr/lib/nodejs/pako/lib/zlib/constants.js
/usr/lib/nodejs/pako/lib/zlib/crc32.js
/usr/lib/nodejs/pako/lib/zlib/deflate.js
/usr/lib/nodejs/pako/lib/zlib/gzheader.js
/usr/lib/nodejs/pako/lib/zlib/inffast.js
/usr/lib/nodejs/pako/lib/zlib/inflate.js
/usr/lib/nodejs/pako/lib/zlib/inftrees.js
/usr/lib/nodejs/pako/lib/zlib/messages.js
/usr/lib/nodejs/pako/lib/zlib/trees.js
/usr/lib/nodejs/pako/lib/zlib/zstream.js

Maybe it would be a good idea to add a dependency on node-pako and
remove those?

Cheers,

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature

Bug#946315: infernal: please make the build reproducible

[Chris Lamb]

Source: infernal
Version: 1.1.3-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
infernal could not be built reproducibly.

This is because it embeds the current build timestamp and the absolute
build directory from which it was built in a generated file that is
shipped with the package.

Sample patch attached.

 [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   2019-12-06 15:38:14.423142750 
+
@@ -0,0 +1,34 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2019-12-05
+
+--- infernal-1.1.3.orig/hmmer/src/p7_tophits.c
 infernal-1.1.3/hmmer/src/p7_tophits.c
+@@ -2001,8 +2001,10 @@ p7_tophits_TabularTail(FILE *ofp, const
+   if (fprintf(ofp, "# Query file:  %s\n",  (qfile== NULL) ? 
"[none]" : qfile) < 0)ESL_XEXCEPTION_SYS(eslEWRITE, "tabular output tail, 
write failed");
+   if (fprintf(ofp, "# Target file: %s\n",  (tfile== NULL) ? 
"[none]" : tfile) < 0)ESL_XEXCEPTION_SYS(eslEWRITE, "tabular output tail, 
write failed");
+   if (fprintf(ofp, "# Option settings: %s\n",  spoof_cmd) < 0)
ESL_XEXCEPTION_SYS(eslEWRITE, "tabular output tail, write 
failed");
+-  if (fprintf(ofp, "# Current dir: %s\n",  (cwd  == NULL) ? 
"[unknown]" : cwd) < 0)   ESL_XEXCEPTION_SYS(eslEWRITE, "tabular output tail, 
write failed");
+-  if (fprintf(ofp, "# Date:%s",timestamp) < 0) /* 
timestamp ends in \n */ ESL_XEXCEPTION_SYS(eslEWRITE, "tabular output tail, 
write failed");
++  if (getenv("SOURCE_DATE_EPOCH") != NULL) {
++if (fprintf(ofp, "# Current dir: %s\n",(cwd  == NULL) ? 
"[unknown]" : cwd) < 0)   ESL_XEXCEPTION_SYS(eslEWRITE, "tabular output tail, 
write failed");
++if (fprintf(ofp, "# Date:%s",  timestamp) < 0) /* 
timestamp ends in \n */ ESL_XEXCEPTION_SYS(eslEWRITE, "tabular output tail, 
write failed");
++  }
+   if (fprintf(ofp, "# [ok]\n") < 0)   
ESL_XEXCEPTION_SYS(eslEWRITE, "tabular output tail, write 
failed");
+ 
+   free(spoof_cmd);
+--- infernal-1.1.3.orig/src/cm_tophits.c
 infernal-1.1.3/src/cm_tophits.c
+@@ -2780,8 +2780,10 @@ cm_tophits_TabularTail(FILE *ofp, const
+   fprintf(ofp, "# Query file:  %s\n",  (qfile== NULL) ? "[none]" 
: qfile);
+   fprintf(ofp, "# Target file: %s\n",  (tfile== NULL) ? "[none]" 
: tfile);
+   fprintf(ofp, "# Option settings: %s\n",  spoof_cmd);
+-  fprintf(ofp, "# Current dir: %s\n",  (cwd  == NULL) ? 
"[unknown]" : cwd);
+-  fprintf(ofp, "# Date:%s",timestamp); /* timestamp ends 
in \n */
++  if (getenv("SOURCE_DATE_EPOCH") != NULL) {
++fprintf(ofp, "# Current dir: %s\n",  (cwd  == NULL) ? 
"[unknown]" : cwd);
++fprintf(ofp, "# Date:%s",timestamp); /* timestamp 
ends in \n */
++  }
+   fprintf(ofp, "# [ok]\n");
+ 
+   free(spoof_cmd);
--- a/debian/patches/series 2019-12-06 15:35:28.229648170 +
--- b/debian/patches/series 2019-12-06 15:38:14.423142750 +
@@ -2,3 +2,4 @@
 #autoreconf.patch
 spelling.patch
 hardening
+reproducible_build.patch

Bug#946314: infernal: FTBFS with "nocheck" build profile

[Chris Lamb]

Source: infernal
Version: 1.1.3-2
Severity: normal
Tags: patch

Hi,

infernal fails to build from source when the "nocheck" build profile
is enabled because the testsuite does not generate the itest_brute
file.

(Approximate) patch attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/rules b/debian/rules
index 89c76e4..c203b2c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -41,7 +41,9 @@ override_dh_installexamples:
mkdir -p $(sampledir_lib)/src/
mkdir -p $(sampledir_lib)/easel/miniapps/
find ./src -name "*test" -exec cp \{\} $(sampledir_lib)/src/ \;
+ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
cp ./src/itest_brute $(sampledir_lib)/src/
+endif
cp ./easel/miniapps/esl-reformat $(sampledir_lib)/easel/miniapps/
cp ./easel/miniapps/esl-shuffle $(sampledir_lib)/easel/miniapps/
cp ./easel/miniapps/esl-sfetch $(sampledir_lib)/easel/miniapps/

Bug#946221: rspamd: segfault with pcre2 10.34, works with 10.32

[Gianfranco Costamagna]

control: tags -1 fixed-upstream
control: tags -1 patch



Hello, looks like upstream has a working simple patch that might be 
cherry-picked

G.

Bug#946282: wireguard broken by iptables 1.8.4

[Daniel Kahn Gillmor]

Control: tags 946282 + moreinfo

Hi Jeff--

On Fri 2019-12-06 11:16:02 -0500, Jeff King wrote:
> Stracing wg-quick shows that it's trying to pass this to
> iptables-restore:
>
>   *raw
>   -I PREROUTING ! -i wg -d 10.0.1.1 -m addrtype ! --src-type LOCAL -j DROP -m 
> comment --comment "wg-quick(8) rule for wg"
>   
>   COMMIT
>   *mangle
>   -I POSTROUTING -m mark --mark 51820 -p udp -j CONNMARK --save-mark -m 
> comment --comment \"wg-quick(8) rule for wg\"
>   -I PREROUTING -p udp -j CONNMARK --restore-mark -m comment --comment 
> \"wg-quick(8) rule for wg\"
>   COMMIT
>
> Note that blank line before the first COMMIT, which it seems the older
> version of iptables was happy to ignore, but 1.8.4 complains about. So
> possibly this is an iptables bug, but it seems like wireguard could be
> more careful about what it writes.

Thanks for this diagnostic, it's super helpful.

Upstream commit 884b6e36e6af0c6fa5b9467ccc8c2e2e4477bc95 should fix this
empty line problem, if i'm understanding it correctly.  That commit is
part of 0.0.20191206, which i've just uploaded to unstable.  Could you
try that out and report back if it solves the problem?

thanks,

--dkg


signature.asc
Description: PGP signature

Bug#946313: debian/tests/basic-smoke: debootstrap stable might fail on future releases

[Mauricio Faria de Oliveira]

Package: src:docker.io
Version: 19.03.4+dfsg2-2
Tags: patch

Hi,

With the release of Debian Buster, docker.io/debian/tests/basic-smoke
started to fail on Ubuntu Xenial [1].
Hopefully this bug report might help Debian too.

Two failures happened on debootstrap:

1) The Release file signature check failed, as archive signatures
changed across the stretch/buster stable releases, and the
debian-archive-keyring in Xenial lacked the keys needed to check the
signature.
This could be worked around with 'debootstrap --no-check-gpg'.

2) The Unpacking stage failed, apparently due script changes needed
(it works on Bionic, which is a newer release than Xenial).

Both problems indicate that, for the sake of build / test
reproducibility, the release used to debootstrap should not change,
which is not the case with the 'stable' suite.

Otherwise, eventually debian-archive-keyring and/or debootstrap might
become out-of-date and stop working with the newer Debian stable
releases, leading to false-positives of regressions in autopkgtest in
Debian too.

[1] https://bugs.launchpad.net/bugs/1855481

Hope this helps,

-- 
Mauricio Faria de Oliveira


docker.io_basic-smoke_buster.debdiff
Description: Binary data

Bug#946301: Should depend on php-twig < 3

[Felipe Sateler]

On Fri, Dec 6, 2019 at 5:36 PM David Prévot  wrote:

> Package: php-twig-extensions
> Version: 1.5.4-1
> Severity: wishlist
>
> Hi,
>
> Thanks for packaging twig-extensions (feel free and welcome to maintain
> it within the Debian PHP PEAR Maintainers team
>  by the way).
>
> With php-twig 3 now in experimental, you may wish to add an explicit
> Depends: php-twig < 3
> override in your control file (due to #765899, the composer.json
> versioned dependency is not fully translated into
> ${phpcomposer:Debian-require}) if you update this package before
> upgrading it to the next upstream version (looking further, I noticed
> the next upstream version should not be affected by this issue [1]).


> 1:
> https://github.com/twigphp/Twig-extensions/blob/master/composer.json#L15
>
> I noticed this issue while trying to make the phpmyadmin package work on
> my box (where I was also using the latest php-twig package). Thanks also
> for resurrecting phpMyAdmin in Debian!
>

I looked at the upstream page to look if the new upstream version added
compat for twig 3,
and it says:

WARNING: This repository is abandoned in favor of Twig Core Extra
extensions.

Maybe php-twig should just Breaks: php-twig-extensions, and phpmyadmin
should migrate to Twig Core Extra extensions


-- 

Saludos,
Felipe Sateler

Bug#921707: Salsa glowing-bear

[Louis-Philippe Véronneau]

My packaging efforts can be found here:

https://salsa.debian.org/debian/glowing-bear

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature

Bug#941853: crypt(3) should be provided by libxcrypt

[Cyril Brulebois]

Aurelien Jarno  (2019-12-06):
> There should be no changes needed on the d-i side. libc6-udeb has a
> new dependency on libcrypt1-udeb. When packages get rebuilt against
> libxcrypt, they'll have a direct dependency on libcrypt1-udeb.
> 
> There is a small impact on size (~100kB) as libxcrypt provides a bit
> more functionality.

Perfect, thanks.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#941853: crypt(3) should be provided by libxcrypt

[Aurelien Jarno]

On 2019-12-06 22:46, Cyril Brulebois wrote:
> Hi,
> 
> Marco d'Itri  (2019-10-07):
> > Dear debian-boot: for the benefit of the ftpmasters, please confirm that 
> > you have no objections to src:libxcrypt generating a libcrypt1-udeb 
> > package (initially in experimental) which will provide crypt(3) 
> > currently in the libc udeb.
> > 
> > > I guess we should keep building libcrypt1 for the bi/tri-arch packages.
> > What do I need to do about this?
> > 
> > > > (Also, do not forget about the man pages in the -dev packages.)
> > > The man page was not provided by the -dev package but by manpages-dev.
> > Actually I see that it automatically stopped shipping crypt(3) and 
> > crypt_r(3) in 5.01-1, so I will add Breaks+Replaces.
> > 
> > > We must build the libcrypt1 udeb, and add a depends from libc6-deb to
> > > libcrypt1-udeb, otherwise we might break d-i. At some point we might
> > OK, I will start again building the udeb with the next upload.
> 
> Aurelien, Marco, do we need to anticipate any changes on the d-i side?
> 
> Or will that udeb addition just result in a new dependency from crypt-using
> udebs to libcrypt1-udeb?

There should be no changes needed on the d-i side. libc6-udeb has a new
dependency on libcrypt1-udeb. When packages get rebuilt against
libxcrypt, they'll have a direct dependency on libcrypt1-udeb.

There is a small impact on size (~100kB) as libxcrypt provides a bit
more functionality.

Aurelien

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


signature.asc
Description: PGP signature

Bug#946312: puma: CVE-2019-16770

[Salvatore Bonaccorso]

Source: puma
Version: 3.12.0-2
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for puma.

CVE-2019-16770[0]:
| In Puma before version 4.3.2, a poorly-behaved client could use
| keepalive requests to monopolize Puma's reactor and create a denial of
| service attack. If more keepalive connections to Puma are opened than
| there are threads available, additional connections will wait
| permanently if the attacker sends requests frequently enough.


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-16770
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16770
[1] https://github.com/puma/puma/security/advisories/GHSA-7xx3-m584-x994
[2] https://github.com/puma/puma/commit/06053e60908074bb38293d4449ea261cb009b53e

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#946311: libpcre2-dev 10.34-5 dependency errors

[Сергей Фёдоров]

Package: libpcre2-dev
Version: 10.34-5
Severity: grave
Tags: a11y
Justification: renders package unusable



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

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

Versions of packages libpcre2-dev depends on:
ii  libc6-dev2.29-3
ii  libpcre2-16-010.34-5
ii  libpcre2-32-010.34-5
ii  libpcre2-8-0 10.34-5
pn  libpcre2-posix2  

libpcre2-dev recommends no packages.

libpcre2-dev suggests no packages.

-- no debconf information

After I installed libpcre2-dev 10.34-5 i get dependency errors for 
libpcre2-posix2.

I get a message: attempt to overwrite 
"/usr/lib/x86_64-linux-gnu/libpcre2-posix.so. 2. 0. 3"
 which is already available in package libpcre2-posix 0: amd64 10.34-3+b1

And I have to go back to the previous version 10.34-3+b1.

Bug#946310: ITP: ruby-jekyll-multiple-languages -- Jekyll plugin to internationalize sites

[Daniel Leidert]

Package: wnpp
Severity: wishlist
Owner: Daniel Leidert 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: ruby-jekyll-multiple-languages
  Version : 1.6.0
  Upstream Author : Martin Kurtsson
* URL : https://github.com/kurtsson/jekyll-multiple-languages-plugin
* License : MIT/X
  Programming Lang: Ruby
  Description : Jekyll plugin to internationalize sites

Jekyll Multiple Languages is an internationalization plugin for Jekyll. It
compiles a Jekyll site for one or more languages with a similar approach as
Rails does. The different sites will be stored in subfolders with the same
name as the language it contains.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl3q0b8ACgkQS80FZ8KW
0F3ieA//dGcMOuuc3NguSfdFuMBTDO4Tr6Yubqj3wzVlEFYCYkWKEZRvq/faL1s2
7il3wUd3rMZe5JYivDu9CA3Vq+9q3H1NR/X1dCLuGSQP/SLuuyGksTt1+WwQLbyS
jhbWsDD6l+O2TiZkOACdiTyVwPwXPviEzZflMUNb4ED+3baKmqDo1NOEcSxEhbBC
5IybueJCmkj7eAdgi7B9XmGYpzzXoBHDaw6j7Vs4zY+AtGMg46rzF34WXjIijmJf
IGCOnnZRM+N5pECmz3wEsPvlims8R1Zf9NrJJ2U73WHMZ7UWuaTCtQW129/dI+E5
3aCQSmc8oRYwuQsXtDAhOgIi80ojUGAgAzYCDYJO+mqoIN2xAX1JjSIgXMprWG1J
+JLxMwOnL5Rri/j5r0kwIZqiOH7otfr0mNgjsRjEVluUz130XoJG0CGAtZvgt/7d
3iPgredDsHAdL+SZGanWN8tB1XMldTGIXXq+ak5j5OnePCdKHGeKVyS/hwLGAPig
+EfE2eaLYJf5J1CvuWK40o8609aKHWXtzu3K8DlHxLe136KiEpM6i87d0IK7xj20
W7cQtBk4LLojJg2vI+3T3qjJX5cNbzFPBHhfPFfl3rvd9qW5iSYU6hvsoKaNu7rs
Rkc/oeJI7+WXnC4E9IW783TmQadavc9He5C6QdiPvEabd3ut8pc=
=KT1Y
-END PGP SIGNATURE-

Bug#946309: golang-github-getlantern-errors: autopkgtest failure on arm64: amd64 specific references

[Paul Gevers]

Source: golang-github-getlantern-errors
Version: 0.0~git20190325.abdb3e3-2
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of golang-github-getlantern-errors your package
added an autopkgtest, great. However, it fails on arm64. I copied some
of the output at the bottom of this report. It seems this test was only
meant for amd64.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

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

Paul

[1]
https://qa.debian.org/excuses.php?package=golang-github-getlantern-errors

https://ci.debian.net/data/autopkgtest/testing/arm64/g/golang-github-getlantern-errors/3456222/log.gz

Diff:
--- Expected
+++ Actual
@@ -3,3 +3,3 @@
   at testing.tRunner (testing.go:999)
-  at runtime.goexit (asm_amd999.s:999)
+  at runtime.goexit (asm_arm999.s:999)
 Caused by: World
@@ -8,3 +8,3 @@
   at testing.tRunner (testing.go:999)
-  at runtime.goexit (asm_amd999.s:999)
+  at runtime.goexit (asm_arm999.s:999)
 Caused by: orld
@@ -16,3 +16,3 @@
   at testing.tRunner (testing.go:999)
-  at runtime.goexit (asm_amd999.s:999)
+  at runtime.goexit (asm_arm999.s:999)
 Caused by: d
Test:   TestNewWithCause



signature.asc
Description: OpenPGP digital signature

Bug#941853: crypt(3) should be provided by libxcrypt

[Cyril Brulebois]

Hi,

Marco d'Itri  (2019-10-07):
> Dear debian-boot: for the benefit of the ftpmasters, please confirm that 
> you have no objections to src:libxcrypt generating a libcrypt1-udeb 
> package (initially in experimental) which will provide crypt(3) 
> currently in the libc udeb.
> 
> > I guess we should keep building libcrypt1 for the bi/tri-arch packages.
> What do I need to do about this?
> 
> > > (Also, do not forget about the man pages in the -dev packages.)
> > The man page was not provided by the -dev package but by manpages-dev.
> Actually I see that it automatically stopped shipping crypt(3) and 
> crypt_r(3) in 5.01-1, so I will add Breaks+Replaces.
> 
> > We must build the libcrypt1 udeb, and add a depends from libc6-deb to
> > libcrypt1-udeb, otherwise we might break d-i. At some point we might
> OK, I will start again building the udeb with the next upload.

Aurelien, Marco, do we need to anticipate any changes on the d-i side?

Or will that udeb addition just result in a new dependency from crypt-using
udebs to libcrypt1-udeb?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#891457: RFH: gnome-shell-extension-caffeine -- GNOME Shell extension to keep your computer awake

[Boyuan Yang]

X-Debbugs-CC: s...@debian.org

Hi Simon,

On Sun, 25 Feb 2018 17:58:43 + Simon McVittie  wrote:
> Package: wnpp
> Severity: normal
> 
> I request assistance with maintaining the gnome-shell-extension-caffeine
> package. It's currently unmaintained upstream, so if it stops working
> in a future version of GNOME Shell and I'm not able to fix it, it'll
> have to be removed. I can't commit to being able to take over upstream
> maintenance myself.

I am a heavy user of caffeine and would like to track its upstream to my best
effort. For now, it's okay if I could be added into the uploaders' list and/or
be granted the Salsa repo access. The short-term plan is to package latest
upstream git snapshot, which has declared to be GNOME 3.34 compatible.

Thanks,
Boyuan Yang


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

Bug#942493: 5000 is a tad too small (was Re: lintian: Please warn about overly-long header fields)

[Felix Lechner]

Hi Aurelien,

On Fri, Dec 6, 2019 at 1:03 PM Aurelien Jarno  wrote:
>
> Is it also possible to allow "long Package-List"?

Done in:


https://salsa.debian.org/lintian/lintian/commit/43c29acbba043d33277ab0670234c7bd9c4077c9

Kind regards,
Felix Lechner

Bug#946307: gitsome: autopkgtest failure: python: not found

[Paul Gevers]

Source: gitsome
Version: 0.8.0+ds-2
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a not so recent upload of gitsome added an autopkgtest, great.
However, it fails. I copied some of the output at the bottom of this
report. It seems you forgot to (test) depend on python, or really wanted
python3 there. Please note that the symlink to python is gone, so you
need either python2 or python3. Also, please be aware that your test
didn't exit non-zero, it passed (you want "set -e"). The autopkgtest
only failed due to output to stderr.

Currently this regression is blocking the migration to testing [1],
together with the fact that we don't allow binaries anymore that are
build by the maintainer, so please upload a source only package.

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/g/gitsome/2818246/log.gz
autopkgtest [23:01:21]: test build: [---
/tmp/autopkgtest-lxc.fxb4hieg/downtmp/build.Mdw/src/debian/tests/build:
5: python: not found
Start unit test on gitsome
autopkgtest [23:01:22]: test build: ---]




signature.asc
Description: OpenPGP digital signature

Bug#942493: 5000 is a tad too small (was Re: lintian: Please warn about overly-long header fields)

[Aurelien Jarno]

On 2019-12-06 13:16, Felix Lechner wrote:
> Hi Aurelien,
> 
> On Fri, Dec 6, 2019 at 1:03 PM Aurelien Jarno  wrote:
> >
> > Is it also possible to allow "long Package-List"?
> 
> Done in:
> 
> 
> https://salsa.debian.org/lintian/lintian/commit/43c29acbba043d33277ab0670234c7bd9c4077c9

Thanks for the quick fix.

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

Bug#898431: lintian.d.o: minimum version of file(1)

[Felix Lechner]

Hi Bastien,

Your report did not indicate a minimum version of file(1), but in the
meantime buster was released and lintian.d.o has been upgraded. Is
this issue moot?

If so, please feel free to close this bug.

Kind regards
Felix Lechner

Bug#946306: jsonld-java: FTBFS in sid

[Gianfranco Costamagna]

Source: jsonld-java
Version: 0.13.0-1
Severity: serious

Hello, looks like jsonld-java is now FTBFS in sid

Can you please have a look?

I: Running cd /build/jsonld-java-0.13.0/ && env 
PATH="/usr/sbin:/usr/bin:/sbin:/bin" HOME="/nonexistent" dpkg-buildpackage -us 
-uc 
dpkg-buildpackage: info: source package jsonld-java
dpkg-buildpackage: info: source version 0.13.0-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Andrius Merkys 
 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
 debian/rules clean
dh clean
   dh_auto_clean
bash -c "for dir in \$(find . -name target -type d); do if [ -f \$(echo 
\$dir | sed -e s/target\$/pom.xml/) ]; then rm -Rf \$dir; fi done"
mh_unpatchpoms -plibjsonld-java
   dh_clean
 dpkg-source -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building jsonld-java using existing 
./jsonld-java_0.13.0.orig.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: building jsonld-java in jsonld-java_0.13.0-1.debian.tar.xz
dpkg-source: info: building jsonld-java in jsonld-java_0.13.0-1.dsc
 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
   dh_auto_configure
mh_patchpoms -plibjsonld-java --debian-build --keep-pom-version 
--maven-repo=/build/jsonld-java-0.13.0/debian/maven-repo
   dh_auto_build
/usr/lib/jvm/default-java/bin/java -noverify -cp 
/usr/share/maven/boot/plexus-classworlds-2.x.jar -Dmaven.home=/usr/share/maven 
-Dmaven.multiModuleProjectDirectory=/build/jsonld-java-0.13.0 
-Dclassworlds.conf=/etc/maven/m2-debian.conf 
-Dproperties.file.manual=/build/jsonld-java-0.13.0/debian/maven.properties 
org.codehaus.plexus.classworlds.launcher.Launcher 
-s/etc/maven/settings-debian.xml -Ddebian.dir=/build/jsonld-java-0.13.0/debian 
-Dmaven.repo.local=/build/jsonld-java-0.13.0/debian/maven-repo package 
-DskipTests -Dnotimestamp=true -Dlocale=en_US
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by 
com.google.inject.internal.cglib.core.$ReflectUtils$1 
(file:/usr/share/maven/lib/guice.jar) to method 
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of 
com.google.inject.internal.cglib.core.$ReflectUtils$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal 
reflective access operations
WARNING: All illegal access operations will be denied in a future release
[INFO] Scanning for projects...
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for 
com.github.jsonld-java:jsonld-java:bundle:0.13.0
[WARNING] 
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
 must be unique: org.apache.httpcomponents:httpclient:jar -> duplicate 
declaration of version debian @ 
com.github.jsonld-java:jsonld-java-parent:0.13.0, 
/build/jsonld-java-0.13.0/pom.xml, line 121, column 16
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for 
com.github.jsonld-java:jsonld-java-parent:pom:0.13.0
[WARNING] 
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
 must be unique: org.apache.httpcomponents:httpclient:jar -> duplicate 
declaration of version debian @ line 121, column 16
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they threaten 
the stability of your build.
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer support 
building such malformed projects.
[WARNING] 
[INFO] 
[INFO] Reactor Build Order:
[INFO] 
[INFO] JSONLD Java :: Parent  [pom]
[INFO] JSONLD Java :: Core [bundle]
[INFO] 
[INFO] -< com.github.jsonld-java:jsonld-java-parent >--
[INFO] Building JSONLD Java :: Parent 0.13.0  [1/2]
[INFO] [ pom ]-
[INFO] 
[INFO] -< com.github.jsonld-java:jsonld-java >-
[INFO] Building JSONLD Java :: Core 0.13.0[2/2]
[INFO] ---[ bundle ]---
[INFO] 
[INFO] --- maven-resources-plugin:3.1.0:resources (default-resources) @ 
jsonld-java ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/build/jsonld-java-0.13.0/core/src/main/resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.8.1:compile (default-compile) @ jsonld-java 
---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 23 source files to 
/build/jsonld-java-0.13.0/core/target/classes
[INFO] 
/build/jsonld-java-0.13.0/core/src/main/java/com/github/jso

Bug#942493: 5000 is a tad too small (was Re: lintian: Please warn about overly-long header fields)

[Aurelien Jarno]

Hi,

On 2019-11-12 09:46, Chris Lamb wrote:
> Hi Thorsten,
> 
> > […] long Description field
> 
> That's actually a good point, I've left the limit at 5000 and simply
> allowed long "long descriptions".

Is it also possible to allow "long Package-List"? This is the error I
now got on the glibc package:

E: glibc source: field-too-long Package-List (5075 chars > 5000)

It's probably possible to drop some fields like build profiles to go
below the 5000 chars limit, but it also means dropping some
functionality.

Thanks,
Aurelien

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

Bug#946305: linux-image-5.3.0-2-amd64: checksum errors occur when testing rar archives

[Сергей Фёдоров]

Package: src:linux
Version: 5.3.9-3
Severity: normal



-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: System manufacturer
product_name: System Product Name
product_version: System Version
chassis_vendor: Chassis Manufacture
chassis_version: Chassis Version
bios_vendor: American Megatrends Inc.
bios_version: 4701
board_vendor: ASUSTeK COMPUTER INC.
board_name: P9X79 PRO
board_version: Rev 1.xx

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Xeon E5/Core i7 DMI2 [8086:3c00] 
(rev 07)
Subsystem: ASUSTeK Computer Inc. Xeon E5/Core i7 DMI2 [1043:84ef]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:01.0 PCI bridge [0604]: Intel Corporation Xeon E5/Core i7 IIO PCI Express 
Root Port 1a [8086:3c02] (rev 07) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.0 PCI bridge [0604]: Intel Corporation Xeon E5/Core i7 IIO PCI Express 
Root Port 2a [8086:3c04] (rev 07) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:03.0 PCI bridge [0604]: Intel Corporation Xeon E5/Core i7 IIO PCI Express 
Root Port 3a in PCI Express Mode [8086:3c08] (rev 07) (prog-if 00 [Normal 
decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:03.2 PCI bridge [0604]: Intel Corporation Xeon E5/Core i7 IIO PCI Express 
Root Port 3c [8086:3c0a] (rev 07) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:05.0 System peripheral [0880]: Intel Corporation Xeon E5/Core i7 Address 
Map, VTd_Misc, System Management [8086:3c28] (rev 07)
Subsystem: ASUSTeK Computer Inc. Xeon E5/Core i7 Address Map, VTd_Misc, 
System Management [1043:84ef]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:05.2 System peripheral [0880]: Intel Corporation Xeon E5/Core i7 Control 
Status and Global Errors [8086:3c2a] (rev 07)
Subsystem: ASUSTeK Computer Inc. Xeon E5/Core i7 Control Status and 
Global Errors [1043:84ef]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:05.4 PIC [0800]: Intel Corporation Xeon E5/Core i7 I/O APIC [8086:3c2c] (rev 
07) (prog-if 20 [IO(X)-APIC])
Subsystem: ASUSTeK Computer Inc. Xeon E5/Core i7 I/O APIC [1043:84ef]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:11.0 PCI bridge [0604]: Intel Corporation C600/X79 series chipset PCI 
Express Virtual Root Port [8086:1d3e] (rev 06) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:16.0 Communication controller [0780]: Intel Corporation C600/X79 series 
chipset MEI Controller #1 [8086:1d3a] (rev 05)
Subsystem: ASUSTeK Computer Inc. C600/X79 series chipset MEI Controller 
[1043:84ef]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: mei_me
Kernel modules: mei_me

00:19.0 Ethernet con

Bug#946304: jsonpickle: FTBFS in sid

[Gianfranco Costamagna]

Source: jsonpickle
Version: 0.9.5-2
Severity: serious

Hello, looks like some Python3 updates made the package FTBFS in sid, due to 
testsuite errors...

log following:
I: Running cd /build/jsonpickle-0.9.5/ && env 
PATH="/usr/sbin:/usr/bin:/sbin:/bin" HOME="/nonexistent" dpkg-buildpackage -us 
-uc -rfakeroot
dpkg-buildpackage: info: source package jsonpickle
dpkg-buildpackage: info: source version 0.9.5-2
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Sandro Tosi 
 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
 fakeroot debian/rules clean
dh clean --with python3,sphinxdoc --buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:217: python3.8 setup.py clean 
running clean
removing '/build/jsonpickle-0.9.5/.pybuild/cpython3_3.8/build' (and everything 
under it)
'build/bdist.linux-amd64' does not exist -- can't clean it
'build/scripts-3.8' does not exist -- can't clean it
I: pybuild base:217: python3.7 setup.py clean 
running clean
removing '/build/jsonpickle-0.9.5/.pybuild/cpython3_3.7/build' (and everything 
under it)
'build/bdist.linux-amd64' does not exist -- can't clean it
'build/scripts-3.7' does not exist -- can't clean it
   dh_clean -O--buildsystem=pybuild
 dpkg-source -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building jsonpickle using existing 
./jsonpickle_0.9.5.orig.tar.gz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: building jsonpickle in jsonpickle_0.9.5-2.debian.tar.xz
dpkg-source: info: building jsonpickle in jsonpickle_0.9.5-2.dsc
 debian/rules build
dh build --with python3,sphinxdoc --buildsystem=pybuild
   dh_update_autotools_config -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
I: pybuild base:217: python3.8 setup.py config 
running config
I: pybuild base:217: python3.7 setup.py config 
running config
   dh_auto_build -O--buildsystem=pybuild
I: pybuild base:217: /usr/bin/python3.8 setup.py build 
running build
running build_py
creating /build/jsonpickle-0.9.5/.pybuild/cpython3_3.8/build/jsonpickle
copying jsonpickle/tags.py -> 
/build/jsonpickle-0.9.5/.pybuild/cpython3_3.8/build/jsonpickle
copying jsonpickle/handlers.py -> 
/build/jsonpickle-0.9.5/.pybuild/cpython3_3.8/build/jsonpickle
copying jsonpickle/unpickler.py -> 
/build/jsonpickle-0.9.5/.pybuild/cpython3_3.8/build/jsonpickle
copying jsonpickle/compat.py -> 
/build/jsonpickle-0.9.5/.pybuild/cpython3_3.8/build/jsonpickle
copying jsonpickle/pickler.py -> 
/build/jsonpickle-0.9.5/.pybuild/cpython3_3.8/build/jsonpickle
copying jsonpickle/version.py -> 
/build/jsonpickle-0.9.5/.pybuild/cpython3_3.8/build/jsonpickle
copying jsonpickle/__init__.py -> 
/build/jsonpickle-0.9.5/.pybuild/cpython3_3.8/build/jsonpickle
copying jsonpickle/backend.py -> 
/build/jsonpickle-0.9.5/.pybuild/cpython3_3.8/build/jsonpickle
copying jsonpickle/util.py -> 
/build/jsonpickle-0.9.5/.pybuild/cpython3_3.8/build/jsonpickle
creating /build/jsonpickle-0.9.5/.pybuild/cpython3_3.8/build/jsonpickle/ext
copying jsonpickle/ext/numpy.py -> 
/build/jsonpickle-0.9.5/.pybuild/cpython3_3.8/build/jsonpickle/ext
copying jsonpickle/ext/__init__.py -> 
/build/jsonpickle-0.9.5/.pybuild/cpython3_3.8/build/jsonpickle/ext
I: pybuild base:217: /usr/bin/python3 setup.py build 
running build
running build_py
creating /build/jsonpickle-0.9.5/.pybuild/cpython3_3.7/build/jsonpickle
copying jsonpickle/tags.py -> 
/build/jsonpickle-0.9.5/.pybuild/cpython3_3.7/build/jsonpickle
copying jsonpickle/handlers.py -> 
/build/jsonpickle-0.9.5/.pybuild/cpython3_3.7/build/jsonpickle
copying jsonpickle/unpickler.py -> 
/build/jsonpickle-0.9.5/.pybuild/cpython3_3.7/build/jsonpickle
copying jsonpickle/compat.py -> 
/build/jsonpickle-0.9.5/.pybuild/cpython3_3.7/build/jsonpickle
copying jsonpickle/pickler.py -> 
/build/jsonpickle-0.9.5/.pybuild/cpython3_3.7/build/jsonpickle
copying jsonpickle/version.py -> 
/build/jsonpickle-0.9.5/.pybuild/cpython3_3.7/build/jsonpickle
copying jsonpickle/__init__.py -> 
/build/jsonpickle-0.9.5/.pybuild/cpython3_3.7/build/jsonpickle
copying jsonpickle/backend.py -> 
/build/jsonpickle-0.9.5/.pybuild/cpython3_3.7/build/jsonpickle
copying jsonpickle/util.py -> 
/build/jsonpickle-0.9.5/.pybuild/cpython3_3.7/build/jsonpickle
creating /build/jsonpickle-0.9.5/.pybuild/cpython3_3.7/build/jsonpickle/ext
copying jsonpickle/ext/numpy.py -> 
/build/jsonpickle-0.9.5/.pybuild/cpython3_3.7/build/jsonpickle/ext
copying jsonpickle/ext/__init__.py -> 
/build/jsonpickle-0.9.5/.pybuild/cpython3_3.7/build/jsonpickle/ext
   debian/rules override_dh_auto_test
make[1]: Entering directory '/build/jsonpickle-0.9.5'
PYBUILD_SYSTEM=custom \
PYBUILD_TEST_ARGS="PYTHONPATH={build_dir} {interpreter} tests/runtests.py" 
dh_auto_test
I: pybuild base:217: 
PYTHONPATH=/build/jsonpickle-0.9.5/.pybuild/cpython3_3.8/build python3.8 
tests/runtests.py
/build/jsonpickle-0.9.5/tests/backend_test.py:103: UserWarning: d

Bug#946302: black: autopkgtest regression: No module named '_black_version'

[Paul Gevers]

Control: merge 946302 945609

Oops, sorry for the noise.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#946303: dbus-glib: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: dbus-glib
Version: 0.110-4
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The dbus-glib tests currently fail in this environment, because they are
build tests that do not invoke the toolchain in a cross-aware manner.  I've
verified that the attached patch lets the tests successfully build (and run)
i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru dbus-glib-0.110/debian/tests/build dbus-glib-0.110/debian/tests/build
--- dbus-glib-0.110/debian/tests/build  2019-01-29 01:44:28.0 -0800
+++ dbus-glib-0.110/debian/tests/build  2019-12-06 11:47:56.0 -0800
@@ -12,6 +12,10 @@
 
 cd "$AUTOPKGTEST_TMP"
 
+if [ -n "$DEB_HOST_GNU_TYPE" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+fi
+
 echo "1..2"
 
 cat > connect.c <<'EOF'
@@ -42,7 +46,7 @@
 
 # Deliberately word-splitting, that's how pkg-config works:
 # shellcheck disable=SC2046
-gcc -o connect connect.c $(pkg-config --cflags --libs dbus-glib-1)
+${CROSS_COMPILE}gcc -o connect connect.c $(${CROSS_COMPILE}pkg-config --cflags 
--libs dbus-glib-1)
 test -x connect
 dbus-run-session -- ./connect
 echo "ok 1"

Bug#946302: black: autopkgtest regression: No module named '_black_version'

[Paul Gevers]

Source: black
Version: 19.10b0-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of black the autopkgtest of black fails in testing
when that autopkgtest is run with the binary packages of black from
unstable. It passes when run with only packages from testing. In tabular
form:
   passfail
black  from testing19.10b0-1
all others from testingfrom testing

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

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it? If needed, please
change the bug's severity.

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/b/black/3595361/log.gz

autopkgtest [16:20:46]: test testsuite: [---
Traceback (most recent call last):
  File "setup.py", line 3, in 
from _black_version import version as __version__
ModuleNotFoundError: No module named '_black_version'
autopkgtest [16:20:47]: test testsuite: ---]



signature.asc
Description: OpenPGP digital signature

Bug#946301: Should depend on php-twig < 3

[David Prévot]

Package: php-twig-extensions
Version: 1.5.4-1
Severity: wishlist

Hi,

Thanks for packaging twig-extensions (feel free and welcome to maintain
it within the Debian PHP PEAR Maintainers team
 by the way).

With php-twig 3 now in experimental, you may wish to add an explicit
Depends: php-twig < 3
override in your control file (due to #765899, the composer.json
versioned dependency is not fully translated into
${phpcomposer:Debian-require}) if you update this package before
upgrading it to the next upstream version (looking further, I noticed
the next upstream version should not be affected by this issue [1]).

1: 
https://github.com/twigphp/Twig-extensions/blob/master/composer.json#L15

I noticed this issue while trying to make the phpmyadmin package work on
my box (where I was also using the latest php-twig package). Thanks also
for resurrecting phpMyAdmin in Debian!

Regards

David

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

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

Versions of packages php-twig-extensions depends on:
ii  php-common  2:69
ii  php-twig2.12.2-1

php-twig-extensions recommends no packages.

Versions of packages php-twig-extensions suggests:
ii  php-symfony-translation  5.0.0-1

-- no debconf information


signature.asc
Description: PGP signature

Bug#946293: Dependency problems between espeakup-udeb and espeak-ng-data-udeb breaking d-i builds

[Paul Gevers]

Control: tags -1 pending

Hi,

Yes, it's the auto-upperlimit-espeak-ng-data-udeb.html transition [1].
I'll schedule the binNMU shortly.

Paul

[1]
https://release.debian.org/transitions/html/auto-upperlimit-espeak-ng-data-udeb.html

On 06-12-2019 19:56, Steve McIntyre wrote:
> Package: espeakup
> Version: 1:0.80-16
> Severity: serious
> Tags: d-i
> 
> Hi Samuel,
> 
> There's a problem with dependencies that's causing d-i to fail to
> build, as seen in the end of the log at:
> 
>   https://d-i.debian.org/daily-images/amd64/20191206-00:05/build_cdrom_gtk.log
> 
> ...
> Reading package lists...
> Building dependency tree...
>   espeakup-udeb:amd64 Depends on espeak-ng-data-udeb:amd64 < none -> 
> 1.50+dfsg-4 @un puN > (< 1.49.2+dfsgA) can't be satisfied!
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  espeakup-udeb : Depends: espeak-ng-data-udeb (< 1.49.2+dfsgA) but 
> 1.50+dfsg-4 is to be installed
> E: Unable to correct problems, you have held broken packages.
> make[2]: *** [Makefile:674: stamps/get_udebs-cdrom_gtk-stamp] Error 100
> make[1]: *** [Makefile:298: _build] Error 2
> make: *** [Makefile:292: build_cdrom_gtk] Error 2
> ...
> 
> Please could you take a look?
> 
> -- 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_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
> 
> Versions of packages espeakup depends on:
> pn  espeak   
> ii  init-system-helpers  1.56+nmu1
> ii  libc62.28-10
> ii  libespeak-ng11.49.2+dfsg-8
> ii  lsb-base 10.2019051400
> 
> espeakup recommends no packages.
> 
> espeakup suggests no packages.
> 



signature.asc
Description: OpenPGP digital signature

Bug#946281: transition: liblouis

[Paul Gevers]

Control: tags -1 confirmed

Hi Samuel,

On 06-12-2019 17:15, Samuel Thibault wrote:
> Upstream of liblouis cleaned the library interface in version 3.12,
> leading to a bump from liblouis19 to liblouis20. I am thus requesting
> a transition slot. The only build rdeps are brltty, liblouisxml and
> liblouisutdml, which I could check as building and running fine.

Please go ahead.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#946300: horgand FTCBFS: broken SSE detection, uses the build architecture pkg-config

[Helmut Grohne]

Source: horgand
Version: 1.14-7
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

horgand fails to cross build from source. For one thing its configure
uses /proc/cpuinfo to determine whether sse is available. This produces
broken results for cross compiling. A better way is asking the compiler
whether it supports -msse. Then it hard codes bare pkg-config. One
should use PKG_CHECK_MODULES instead. The attached patch implements both
and makes horgand cross buildable. Please consider applying it.

Helmut
--- horgand-1.14.orig/configure.in
+++ horgand-1.14/configure.in
@@ -66,16 +66,23 @@
 AC_DEFINE([WEBSITE],["horgand.berlios.de"],[WEBSITE])
 
 
-SSE=$(cat /proc/cpuinfo | grep sse) 
+AC_MSG_CHECKING([for SSE])
+_save_CFLAGS=$CFLAGS
+CFLAGS="$CFLAGS -msse"
+AC_TRY_COMPILE([],[],[
+AC_MSG_RESULT([yes])
+	SSE=-msse
+],[
+   	AC_MSG_RESULT([no])
+	SSE=
+])
+CFLAGS="$_save_CFLAGS"
 
-if test -z "$SSE"; then 
-SSE=""
-else
-SSE="-msse"
-fi
+PKG_CHECK_MODULES([JACK],[jack])
+PKG_CHECK_MODULES([SNDFILE],[sndfile])
 
-LIBS="`$FLTKCONFIG --ldflags` -lasound `pkg-config --libs jack` `pkg-config --libs sndfile` -lXpm"
-CXXFLAGS="-O3 -fno-rtti -pipe -ffast-math -ffunction-sections -fomit-frame-pointer $SSE -Wall `$FLTKCONFIG --cxxflags` `pkg-config --cflags jack` `pkg-config --cflags sndfile`"
+LIBS="`$FLTKCONFIG --ldflags` -lasound $JACK_LIBS $SNDFILE_LIBS -lXpm"
+CXXFLAGS="-O3 -fno-rtti -pipe -ffast-math -ffunction-sections -fomit-frame-pointer $SSE -Wall `$FLTKCONFIG --cxxflags` $JACK_CFLAGS $SNDFILE_CFLAGS"
 AC_CONFIG_FILES([Makefile src/Makefile data/Makefile man/Makefile])
 AC_OUTPUT
 

Bug#946299: ITP: simde -- Implementations of SIMD instructions for all systems

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

Subject: ITP: simde -- Implementations of SIMD instructions for all systems
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: simde
  Version : 0.0.0.git.20191205.c2e740c
  Upstream Author : , Evan Nemerson 
* URL : https://github.com/nemequ/simde
* License : MIT
  Programming Lang: C
  Description : Implementations of SIMD instructions for all systems
 SIMDe provides fast, portable implementations of SIMD intrinsics on hardware
 which doesn't natively support them, such as calling SSE functions on ARM.
 There is no performance penalty if the hardware supports the native
 implementation (e.g., SSE/AVX runs at full speed on x86, NEON on ARM, etc.).
 .
 This makes porting code to other architectures much easier in a few key ways:
 .
 First, instead of forcing you to rewrite everything for each architecture,
 SIMDe lets you get a port up and running almost effortlessly. You can then
 start working on switching the most performance-critical sections to native
 intrinsics, improving performance gradually. SIMDe lets (for example) SSE/AVX
 and NEON code exist side-by-side, in the same implementation.
 .
 Second, SIMDe makes it easier to write code targeting ISA extensions you don't
 have convenient access to. You can run NEON code on your x86 machine without an
 emulator. Obviously you'll eventually want to test on the actual hardware
 you're targeting, but for most development, SIMDe can provide a much easier
 path.
 .
 SIMDe takes a very different approach from most other SIMD abstraction layers
 in that it aims to expose the entire functionality of the underlying
 instruction set. Instead of limiting functionality to the lowest common
 denominator, SIMDe tries to minimize the amount of effort required to port
 while still allowing you the space to optimize as needed.
 .
 The current focus is on writing complete portable implementations, though a
 large number of functions already have accelerated implementations using one
 (or more) of the following:
 .
 SIMD intrinsics from other ISA extensions (e.g., using NEON to implement
 SSE).
 Compiler-specific vector extensions and built-ins such as
 __builtin_shufflevector and __builtin_convertvector
 Compiler auto-vectorization hints, using:
OpenMP 4 SIMD
Cilk Plus
GCC loop-specific pragmas
clang pragma loop hint directives

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

Bug#946285: libgcc-s1: probably needs Breaks: libgcc1 (<< 1:10)

[Simon McVittie]

On Fri, 06 Dec 2019 at 17:49:09 +0100, Matthias Klose wrote:
> On 06.12.19 17:36, Simon McVittie wrote:
> > I notice gcc-10 has switched from packaging libgcc_s.so.1 as
> > "libgcc1" to the Policy-recommended name libgcc-s1.
> 
> it's not an old version, it's the same version. Is this still an issue?

Oh! I hadn't realised libgcc1 (>= 1:10) still had content - I assumed it
had become an empty dependency package.

In that case, it looks as though libgcc1 (>= 1:10) and libgcc-s1
(>= 1:10) are not going to be co-installable on systems with merged /usr
(such as default buster installations), because they contain a path that
differs only in whether it starts with /lib or /usr/lib.

libgcc1 (<< 1:10) and libgcc-s1 (>= 1:10) would have the same problem,
in fact, so I should have suggested Breaks/Replaces.

> well, currently the very same library is shipped, so I don't see what could
> break. The current packaging doesn't need any breaks.

It won't break *full* upgrades on non-merged-/usr systems right now,
but it could break partial upgrades where you have for example

libgcc1 (= 1:9.2.1-21) from gcc-9
libgcc-s1 (= 10-20191205-1) from gcc-10

if there is no dependency relationship that forces that situation not
to happen.

Is there a reason why this rename and file move particularly needs to
happen, or is it just for neatness? The changelog doesn't mention it,
but I can see that it might have implications for the interaction with
${multiarch:breaks}.

If it's just for neatness, to be honest I'd be inclined to leave it
as-is and consider it to be a historical accident, the same as the way
libglib2.0-0 isn't called libglib-2.0-0 as it should be.

> > If similar bugs happen with libgcc, they would be more serious than they
> > are for GLib, since some of the programs and libraries that you'd want
> > to use to recover from that situation, notably apt, depend on libgcc.
> 
> Sure, the package will be in experimental for a few more months.

The weirdness we had with GLib involved a version from jessie causing
trouble for people upgrading buster-as-testing systems 3-4 years later,
and experimental has few users; so if you get similar upgrade issues,
I suspect you won't see them until it's already too late.

You might avoid this for libgcc, because GLib has the usual
Autotools-style layout of most shared libraries:

regular file libglib-2.0.so.0.1234.56
link libglib-2.0.so.0 -> libglib-2.0.so.0.1234.56
SONAME   libglib-2.0.so.0

whereas libgcc1, unusually, only has:

regular file libgcc_s.so.1
SONAME   libgcc_s.so.1

so maybe the failure mode from GLib can't occur here? We still don't
know the root cause of the failure mode from GLib, though, so perhaps
that difference doesn't help you.

smcv

Bug#946235: atk1.0: please make autopkgtests cross-test-friendly

[Steve Langasek]

On Fri, Dec 06, 2019 at 07:18:22PM +, Simon McVittie wrote:
> On Fri, 06 Dec 2019 at 09:41:54 -0800, Steve Langasek wrote:
> > As far as I see, installing crossbuild-essential-i386 + pkg-config doesn't
> > set up an i386-linux-gnu-pkg-config symlink.

> It's i686-etc. (GNU tuple, not multiarch tuple). It's helpful that your
> first attempts at cross-testing are for i386, because I think that's our
> only architecture where the difference between GNU and multiarch tuple
> matters in practice!

> As far as I can see, it is meant to be set up when you either add
> i386 as a foreign architecture, or install pkg-config, whichever one
> of those two actions is done second. If that isn't working for you,
> then I think there's a problem, because cross-compiling packages that
> rely on pkg-config using dpkg won't work.

Ok, sure enough, it's there.  So ${CROSS_COMPILE}pkg-config should DTRT!

> > Do you think autopkgtests
> > should be setting up such a symlink locally
> 
> No, I think they should be relying on the OS getting it right, and
> failing if the OS got it wrong.
> 
> smcv

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#946294: clutter-1.0: Please make autopkgtests cross-test-friendly

[Simon McVittie]

On Fri, 06 Dec 2019 at 10:58:46 -0800, Steve Langasek wrote:
> Support for cross-testing in
> autopkgtest is currently awaiting review at
> https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69

I've left some comments there.

> So this change should be safe to land in your package despite this
> not being upstream in autopkgtest.

Note that there is still some discussion about the similar patch in
.

smcv

Bug#946235: atk1.0: please make autopkgtests cross-test-friendly

[Simon McVittie]

On Fri, 06 Dec 2019 at 09:41:54 -0800, Steve Langasek wrote:
> As far as I see, installing crossbuild-essential-i386 + pkg-config doesn't
> set up an i386-linux-gnu-pkg-config symlink.

It's i686-etc. (GNU tuple, not multiarch tuple). It's helpful that your
first attempts at cross-testing are for i386, because I think that's our
only architecture where the difference between GNU and multiarch tuple
matters in practice!

As far as I can see, it is meant to be set up when you either add
i386 as a foreign architecture, or install pkg-config, whichever one
of those two actions is done second. If that isn't working for you,
then I think there's a problem, because cross-compiling packages that
rely on pkg-config using dpkg won't work.

> Do you think autopkgtests
> should be setting up such a symlink locally

No, I think they should be relying on the OS getting it right, and
failing if the OS got it wrong.

smcv

Bug#946298: gnome-desktop-testing: Please mark gnome-desktop-testing Multi-Arch: foreign for cross-testing

[Steve Langasek]

Package: gnome-desktop-testing
Version: 2018.1-2
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

Some packages, such as ibus, use gnome-desktop-testing as a test dependency,
and when cross-testing they should use the host version of this package. 
While these tests could be changed to depend on
gnome-desktop-testing:native, I think the right answer is to add a missing
Multi-Arch: foreign annotation to this package since gnome-desktop-testing
provides an exec interface so we should always be using the version of the
package for the testbed arch.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru gnome-desktop-testing-2018.1/debian/control 
gnome-desktop-testing-2018.1/debian/control
--- gnome-desktop-testing-2018.1/debian/control 2018-12-23 07:57:41.0 
-0800
+++ gnome-desktop-testing-2018.1/debian/control 2019-12-06 11:10:03.0 
-0800
@@ -18,6 +18,7 @@
 
 Package: gnome-desktop-testing
 Architecture: any
+Multi-Arch: foreign
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Description: runner for GNOME installed tests
  The GNOME desktop testing runner provides an execution harness for GNOME

Bug#926543: lintian: Deadlock in source-copyright check on source:khronos-opencl-man/1.0~svn33624-4

[Felix Lechner]

Hi,

This issue was fixed in:


https://salsa.debian.org/lintian/lintian/commit/9d580d4401f7501a3b1634dfe69b116901826491

The problem was caused by unsuccessful network access in the backend
XML::LibXML::SAX::Parser. The problematic packages contained XML files
that somehow did not parse correctly. The call to the parser never
returned. The issue occurred even when XML::LibXML was used directly
(without XML::Simple), but without the option 'no_network'.

For future reference, a test script and the two problematic XML files
are attached.

The issue may have been caused by a breaking change in
libxml-libxml-perl, but I am not sure.

Kind regards
Felix Lechner


xmlin.pl
Description: Perl program

http://www.oasis-open.org/docbook/xml/mathml/1.1CR1/dbmathml.dtd";>




EXTENSION




EXTENSION



2007-2011
The Khronos Group Inc.
 Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and/or associated documentation files (the
"Materials"), to deal in the Materials without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Materials, and to
permit persons to whom the Materials are furnished to do so, subject to
the condition that this copyright notice and permission notice shall be included
in all copies or substantial portions of the Materials.


3





EXTENSION


A #pragma directive to set the behavior for OpenCL extensions.















#pragma OPENCL EXTENSION extension_name : behavior
#pragma OPENCL EXTENSION all : behavior










Parameters




 
extension_name




 
The name of the extension. The extension_name will have names of
the form cl_khr_ for an extension
approved by the OpenCL working group and will have names of the form
cl__
for vendor extensions. The token all means that the behavior applies
to all extensions supported by the compiler. The table below shows the legal values for
extension_name:









Extension name
Description





cl_khr_int64_base_atomics
64-bit integer base atomic operations



cl_khr_int64_extended_atomics
64-bit integer extended atomic operations



cl_khr_3d_image_writes
Writes to 3D image objects



cl_khr_fp16
Half-precision floating-point



cl_apple_gl_sharing
MacOS X OpenGL sharing



cl_khr_gl_sharing
OpenGL sharing



cl_khr_gl_event
CL event objects from GL sync objects




cl_khr_d3d10_sharing
Sharing memory objects wth Direct3D 10




cl_khr_d3d11_sharing
Sharing memory objects wth Direct3D 11

Bug#946297: libclustalo-doc: Doxygen's "jquery.js" replaced with something else

[Helmut Grohne]

Package: libclustalo-doc
Version: 1.2.4-2
Filename: /usr/share/doc/libclustalo-doc/api/html/jquery.js

libclustalo-doc contains Doxygen generated documentation and thereby
ships a jquery.js. Unfortunately, what is called jquery.js is not
jquery, but an amalgamation of jquery-based libraries. Refer to
/usr/share/doc/doxygen/README.jquery for details. Replacing this file
breaks its functionality. Removing it would be a better option that
replacing it with something entirely different.

Helmut

Bug#946296: trace-cmd FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: trace-cmd
Version: 2.8.3-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

trace-cmd fails to cross build from source, because it uses build
architecture build tool. The all target honours cross tools, so there
using dh_auto_build helps. The gui target is a thin wrapper around a
cmake project for kernelshark. Here we need to pass cross stuff to
cmake. Rather than moving those flags through the makefile, we can run
cmake before make gui and let dh_auto_configure solve that. This is
enough to make trace-cmd cross buildable. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru trace-cmd-2.8.3/debian/changelog 
trace-cmd-2.8.3/debian/changelog
--- trace-cmd-2.8.3/debian/changelog2019-12-04 22:32:41.0 +0100
+++ trace-cmd-2.8.3/debian/changelog2019-12-06 17:25:30.0 +0100
@@ -1,3 +1,13 @@
+trace-cmd (2.8.3-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make all.
++ Let dh_auto_configure pass cross tools to the cmake invocation
+  normally performed by make gui.
+
+ -- Helmut Grohne   Fri, 06 Dec 2019 17:25:30 +0100
+
 trace-cmd (2.8.3-2) unstable; urgency=medium
 
   * build should be verbose by default (Closes: #946067)
diff --minimal -Nru trace-cmd-2.8.3/debian/rules trace-cmd-2.8.3/debian/rules
--- trace-cmd-2.8.3/debian/rules2019-12-04 21:54:12.0 +0100
+++ trace-cmd-2.8.3/debian/rules2019-12-06 17:25:30.0 +0100
@@ -10,7 +10,9 @@
 override_dh_auto_clean:
$(MAKE) clean doc_clean $(OPTS)
 override_dh_auto_build:
-   $(MAKE) all $(OPTS)
+   dh_auto_build -- all $(OPTS)
+   # Run cmake in the way the Makefile would do it, but append our flags.
+   dh_auto_configure --sourcedirectory=kernel-shark 
--builddirectory=kernel-shark/build -- -D_INSTALL_PREFIX=/usr
$(MAKE) gui $(OPTS)
$(MAKE) doc $(OPTS)
 override_dh_auto_install:

Bug#946295: gtk+2.0: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: gtk+2.0
Version: 2.24.32-4
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hi Jeremy,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The gtk+2.0 tests currently fail in this environment, because they are build
tests that do not invoke the toolchain in a cross-aware manner.  I've
verified that the attached patch lets the tests successfully build (and run)
i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru gtk+2.0-2.24.32/debian/tests/build gtk+2.0-2.24.32/debian/tests/build
--- gtk+2.0-2.24.32/debian/tests/build  2019-09-11 14:03:10.0 -0700
+++ gtk+2.0-2.24.32/debian/tests/build  2019-12-06 11:02:02.0 -0800
@@ -14,6 +14,12 @@
 WORKDIR=$(mktemp -d)
 trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
 cd $WORKDIR
+
+if [ -n "$DEB_HOST_MULTIARCH" ]; then
+export PKG_CONFIG_PATH="/usr/lib/$DEB_HOST_MULTIARCH/pkgconfig"
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+fi
+
 cat < gtktest.c
 #include 
 #include 
@@ -40,7 +46,7 @@
 }
 EOF
 
-gcc -o gtktest gtktest.c `pkg-config --cflags --libs gtk+-2.0`
+${CROSS_COMPILE}gcc -o gtktest gtktest.c `pkg-config --cflags --libs gtk+-2.0`
 echo "build: OK"
 [ -x gtktest ]
 xvfb-run -a -s "-screen 0 1024x768x24" \

Bug#946294: clutter-1.0: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: clutter-1.0
Version: 1.26.2+dfsg-12
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The clutter-1.0 tests currently fail in this environment, because they are
build tests that do not invoke the toolchain in a cross-aware manner.  I've
verified that the attached patch lets the tests successfully build (and run)
i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru clutter-1.0-1.26.2+dfsg/debian/tests/build 
clutter-1.0-1.26.2+dfsg/debian/tests/build
--- clutter-1.0-1.26.2+dfsg/debian/tests/build  2019-08-27 02:44:04.0 
-0700
+++ clutter-1.0-1.26.2+dfsg/debian/tests/build  2019-12-06 10:28:51.0 
-0800
@@ -11,6 +11,12 @@
 export XDG_RUNTIME_DIR="$WORKDIR"
 trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
 cd $WORKDIR
+
+if [ -n "$DEB_HOST_MULTIARCH" ]; then
+export PKG_CONFIG_PATH="/usr/lib/$DEB_HOST_MULTIARCH/pkgconfig"
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+fi
+
 cat < cally.c
 #include 
 
@@ -53,7 +59,7 @@
 ;;
 esac
 
-gcc -o "${lib}-test" "${code}" $(pkg-config --cflags --libs ${packages})
+${CROSS_COMPILE}gcc -o "${lib}-test" "${code}" $(pkg-config --cflags 
--libs ${packages})
 echo "build ($lib): OK"
 [ -x "${lib}-test" ]
 dbus-run-session -- xvfb-run -a "./${lib}-test"

Bug#946293: Dependency problems between espeakup-udeb and espeak-ng-data-udeb breaking d-i builds

[Steve McIntyre]

Package: espeakup
Version: 1:0.80-16
Severity: serious
Tags: d-i

Hi Samuel,

There's a problem with dependencies that's causing d-i to fail to
build, as seen in the end of the log at:

  https://d-i.debian.org/daily-images/amd64/20191206-00:05/build_cdrom_gtk.log

...
Reading package lists...
Building dependency tree...
  espeakup-udeb:amd64 Depends on espeak-ng-data-udeb:amd64 < none -> 
1.50+dfsg-4 @un puN > (< 1.49.2+dfsgA) can't be satisfied!
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 espeakup-udeb : Depends: espeak-ng-data-udeb (< 1.49.2+dfsgA) but 1.50+dfsg-4 
is to be installed
E: Unable to correct problems, you have held broken packages.
make[2]: *** [Makefile:674: stamps/get_udebs-cdrom_gtk-stamp] Error 100
make[1]: *** [Makefile:298: _build] Error 2
make: *** [Makefile:292: build_cdrom_gtk] Error 2
...

Please could you take a look?

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

Versions of packages espeakup depends on:
pn  espeak   
ii  init-system-helpers  1.56+nmu1
ii  libc62.28-10
ii  libespeak-ng11.49.2+dfsg-8
ii  lsb-base 10.2019051400

espeakup recommends no packages.

espeakup suggests no packages.

Bug#946178: mercurial: FTBFS on hurd-i386: Testsuite failures

[Julien Cristau]

On Fri, Dec 06, 2019 at 03:42:22PM +0100, Julien Cristau wrote:
> On Wed, Dec 04, 2019 at 09:45:14PM +0100, Paul Sonnenschein wrote:
> > The attached patch replaces the error number in the offending tests
> > with a * glob.
> > 
> Thanks, forwarded upstream as https://phab.mercurial-scm.org/D7556
> 
And now fixed: https://www.mercurial-scm.org/repo/hg/rev/76d32a0edbc6

Cheers,
Julien

Bug#944350: RE: [External] Bug#944350: systemd: screen remains off after waking up from suspend

[Mark Pearson]

Hi Jiri,

I'm pretty sure it's not in 5.3.0-2. Are you sure? I can look again but I 
recently did put in a merge request to get it pulled into sid: 
https://salsa.debian.org/kernel-team/linux/merge_requests/188

Not sure if/when it will be accepted (it's only my 2nd attempt at doing this) 
but hopefully someone looks at it and thinks it's useful)

Mark

> -Original Message-
> From: Jiri Kanicky 
> Sent: Saturday, November 30, 2019 6:56 AM
> To: 944...@bugs.debian.org
> Subject: Bug#944350: RE: [External] Bug#944350: systemd: screen remains
> off after waking up from suspend
> 
> Hi.
> 
> It seems that Debian 5.3.0-2-amd64 includes the code in the patch
> already and I still have the issue.
> 
> Jiri
> 
> On Mon, 25 Nov 2019 16:45:55 + Mark Pearson
>  wrote:
> 
>  > Hi,
>  >
>  > I don't know if this is helpful but I recently debugged a similar
> issue on the Lenovo P1Gen2. There the problem is only with the
> integrated graphics and an OLED screen - we tracked it down to an issue
> in the i915 driver where it wasn't giving enough time for eDP link
> training. It turned out this was due to the driver using the wrong
> clocks after a suspend and resume .
>  >
>  > Intel recently up-streamed a fix (commit 2f216a85 - it went into
> 5.4-rc8)
>  >
>  > I'm working on doing a patch that I'm hoping to get into Debian to
> backport - just not done yet :) The patch is pretty small (I've attached
> it) so you might want to give it a go and see if it helps.
>  >
>  > Note - we did also test X1 extreme with OLED panel and didn't see a
> problem therebut it's a really subtle timing issue so some units
> might be more susceptible than others. Maybe worth a go?
>  >
>  > If it does make a difference let me know.
>  > Mark
>  >

Bug#946292: at-spi2-atk: please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: at-spi2-atk
Version: 2.34.1-2
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The at-spi2-atk tests currently fail in this environment, because they are
build tests that do not invoke the toolchain in a cross-aware manner.  I've
verified that the attached patch lets the tests successfully build (and run)
i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru at-spi2-atk-2.34.1/debian/tests/tests 
at-spi2-atk-2.34.1/debian/tests/tests
--- at-spi2-atk-2.34.1/debian/tests/tests   2019-10-01 12:59:33.0 
-0700
+++ at-spi2-atk-2.34.1/debian/tests/tests   2019-12-05 21:28:39.0 
-0800
@@ -8,7 +8,19 @@
 patch -p1 < debian/patches/use_system_atk_adaptor.patch 2>&1 || true
 
 cd $WORKDIR
-meson $SRCDIR 2>&1
+if [ -n "$DEB_HOST_MULTIARCH" ]; then
+export PKG_CONFIG_PATH="/usr/lib/$DEB_HOST_MULTIARCH/pkgconfig"
+cross_file=cross_file.txt
+cat > $cross_file <&1
 ninja -v 2>&1
 xvfb-run -s -noreset -a dbus-run-session --dbus-daemon 
$SRCDIR/debian/tests/dbus-daemon -- ninja test -v
 

Bug#946290: libpcre2-posix2:amd64 is uninstallable

[Matthew Vernon]

forcemerge 946279 946290
quit

Hi,

Please check the BTS for duplicates before filing bugs.

Thanks,

Matthew

Bug#946291: leveldb: please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: leveldb
Version: 1.22-3
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The leveldb tests currently fail in this environment, because they are build
tests that do not invoke the toolchain in a cross-aware manner.  I've
verified that the attached patch lets the tests successfully build (and run)
i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru leveldb-1.22/debian/tests/build leveldb-1.22/debian/tests/build
--- leveldb-1.22/debian/tests/build 2015-04-27 23:58:17.0 -0700
+++ leveldb-1.22/debian/tests/build 2019-12-06 09:33:52.0 -0800
@@ -8,6 +8,11 @@
 WORKDIR=$(mktemp -d)
 trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
 cd $WORKDIR
+
+if [ -n "$DEB_HOST_MULTIARCH" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+fi
+
 cat < build_test.cpp
 #include 
 #include 
@@ -57,7 +62,7 @@
 }
 EOF
 
-g++ -o build_test build_test.cpp -pthread -lleveldb -lsnappy
+${CROSS_COMPILE}g++ -o build_test build_test.cpp -pthread -lleveldb -lsnappy
 echo "build: OK"
 [ -x build_test ]
 ./build_test

Bug#946235: atk1.0: please make autopkgtests cross-test-friendly

[Steve Langasek]

Hi Simon,

On Fri, Dec 06, 2019 at 09:19:30AM +, Simon McVittie wrote:
> On Thu, 05 Dec 2019 at 15:18:40 -0800, Steve Langasek wrote:
> > This requires changes to some tests so that they are cross-aware and can do
> > the right thing.

> Thanks for this patch. I'm assuming this is going to be the first of many
> build smoke-tests that will need similar changes when the autopkgtest
> change lands, so I'm being extra-careful when reviewing it, to try to
> get the clearest possible patches for other packages.

Indeed, there are a number of others in flight, so thanks for the feedback.

> > +if [ -n "$DEB_HOST_MULTIARCH" ]; then
> > +export PKG_CONFIG_PATH="/usr/lib/$DEB_HOST_MULTIARCH/pkgconfig"
> > +PREFIX="$DEB_HOST_GNU_TYPE-"
> > +fi
> > +${PREFIX}gcc -Wall -Werror -o atk1.0-dev_test atk1.0-dev_test.c 
> > `pkg-config --cflags --libs atk`

> I think it would be both more concise and more realistic to use
> ${PREFIX}pkg-config instead of setting PKG_CONFIG_PATH, and rely on the
> multiarch symlink to /usr/share/pkg-config-crosswrapper for the mechanics
> of finding the right library? That matches what will actually happen when
> cross-compiling with dpkg, if I understand correctly (and it's actually
> PKG_CONFIG_LIBDIR that gets set in the cross-wrapper).

As far as I see, installing crossbuild-essential-i386 + pkg-config doesn't
set up an i386-linux-gnu-pkg-config symlink.  Do you think autopkgtests
should be setting up such a symlink locally, rather than just manually
setting the path, provided that the latter works?

> Perhaps it would be clearer to name the variable CROSS_COMPILE instead of
> PREFIX, to avoid it being mixed up with other concepts also named prefix,
> like the one that is normally /usr? `make CROSS_COMPILE=i686-linux-gnu-`
> and `CC=${CROSS_COMPILE}gcc` is the convention used for the equivalent
> variable in for example Linux, Busybox and OpenSSL, so it should be
> reasonably familiar.

That seems reasonable to me.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#946290: libpcre2-posix2:amd64 is uninstallable

[Roman Lebedev]

Package: libpcre2-posix2
Version: 10.34-5
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Preparing to unpack .../4-libpcre2-posix2_10.34-5_amd64.deb ...
Unpacking libpcre2-posix2:amd64 (10.34-5) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-zUiPeq/4-libpcre2-posix2_10.34-5_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/x86_64-linux-gnu/libpcre2-posix.so.2.0.3', which 
is also in package libpcre2-posix0:amd64 10.34-3+b1
Preparing to unpack .../5-libpcre2-8-0_10.34-5_amd64.deb ...
Unpacking libpcre2-8-0:amd64 (10.34-5) over (10.34-3+b1) ...
Errors were encountered while processing:
 /tmp/apt-dpkg-install-zUiPeq/4-libpcre2-posix2_10.34-5_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


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

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEjkF6151RK40WXe2HCDw+u0oWieAFAl3qjgoACgkQCDw+u0oW
ieCDPA//d0SZv6h5xg9hSSzju2i9uNcTpG+pKhxTgLP+umRStmt9IvxUWQQiKnnM
qNskn3XuCKSTUqjHpwGqhM+zMMxLqUyBTpluTOekGCuDOtilGG3JL7b/eRVIrItR
CwafcADx/ZAbGwb8BMLLtc/L4jFKhfgSaH751FZY60Z8/BYTebBCERt2p002Tcbm
A0O89TRCF4epYd89LEgst8sc8PpXVsl+qo5RBsig8puPDrM1mehzEwuo0T2idP69
3UT1tKNoKafrDrQOG+hWnv38xIwwt9MiRUHRb4rz83uBBrCF+la9FjifEVHWz2fc
9zfS/L0VTmmSQbmA7xJTCbdf5HYa3qn4TAjWBZ+424t5sK22pv+JM4yeOgHik3VJ
n0HGYI9Juy9e8dP3EZKRUisV0USheVzXYjKc93pKh2fFoJjZqHumVSxqEhYxHz9l
jB8qM22HxY+KMRTbej9Xlwiv6StApD0FzmtjtwOlmLlhEdZIMwk1SrdyhSOmm9by
i1zQAoT6qZ8qGj382380Tg7gI1IXEdrn5AuAl8XCL3hRLRWWnuE4JD1BnYbLExCU
l/KMFoI5btv1iaW6act2ivHXZgaI2DHV2TFSK8JN4Fwi2GN6GwzPIQKz2/2CIfqN
MlBAF9c8fX3arjIjEvX3zdngl2TV7AljAuHh4jGS5qcZRTbLJFQ=
=JbDP
-END PGP SIGNATURE-

Bug#946288: Tests are failing

[Sebastien Bacher]

Package: mwic
Version: 0.7.7-1

The autopkgtest are currently failing
https://ci.debian.net/packages/m/mwic/unstable/amd64/

Bug#946289: ufw: fails to start with iptables 1.8.4

[Antonio Terceiro]

Package: ufw
Version: 0.36-1
Severity: grave
Justification: renders package unusable

This started since the latest upgrade of iptables (1.8.4). Reverting to
1.8.3 (testing) makes it work again.

This is the contents of the journal for ufw.service:

-- Logs begin at Thu 2019-12-05 14:15:18 -03, end at Fri 2019-12-06 13:45:35 
-03. --
dez 05 14:15:18 lemur ufw-init[455]: Bad argument `DROP'
dez 05 14:15:18 lemur ufw-init[455]: Error occurred at line: 4
dez 05 14:15:18 lemur ufw-init[455]: Try `iptables-restore -h' or 
'iptables-restore --help' for more information.
dez 05 14:15:18 lemur ufw-init[458]: Bad argument `-'
dez 05 14:15:18 lemur ufw-init[458]: Error occurred at line: 4
dez 05 14:15:18 lemur ufw-init[458]: Try `iptables-restore -h' or 
'iptables-restore --help' for more information.
dez 05 14:15:18 lemur ufw-init[460]: iptables-restore: line 2 failed
dez 05 14:15:18 lemur ufw-init[465]: Bad argument `-'
dez 05 14:15:18 lemur ufw-init[465]: Error occurred at line: 3
dez 05 14:15:18 lemur ufw-init[465]: Try `iptables-restore -h' or 
'iptables-restore --help' for more information.
dez 05 14:15:18 lemur ufw-init[468]: Bad argument `-'
dez 05 14:15:18 lemur ufw-init[468]: Error occurred at line: 3
dez 05 14:15:18 lemur ufw-init[468]: Try `iptables-restore -h' or 
'iptables-restore --help' for more information.
dez 05 14:15:18 lemur ufw-init[473]: Bad argument `-'
dez 05 14:15:18 lemur ufw-init[473]: Error occurred at line: 3
dez 05 14:15:18 lemur ufw-init[473]: Try `iptables-restore -h' or 
'iptables-restore --help' for more information.
dez 05 14:15:18 lemur ufw-init[474]: Bad argument `-'
dez 05 14:15:18 lemur ufw-init[474]: Error occurred at line: 3
dez 05 14:15:18 lemur ufw-init[474]: Try `iptables-restore -h' or 
'iptables-restore --help' for more information.
dez 05 14:15:18 lemur ufw-init[476]: iptables-restore v1.8.4 (nf_tables): Chain 
'ufw-user-input' does not exist
dez 05 14:15:18 lemur ufw-init[476]: Error occurred at line: 2
dez 05 14:15:18 lemur ufw-init[476]: Try `iptables-restore -h' or 
'iptables-restore --help' for more information.
dez 05 14:15:18 lemur ufw-init[478]: Bad argument `DROP'
dez 05 14:15:18 lemur ufw-init[478]: Error occurred at line: 4
dez 05 14:15:18 lemur ufw-init[478]: Try `ip6tables-restore -h' or 
'ip6tables-restore --help' for more information.
dez 05 14:15:18 lemur ufw-init[481]: Bad argument `-'
dez 05 14:15:18 lemur ufw-init[481]: Error occurred at line: 4
dez 05 14:15:18 lemur ufw-init[481]: Try `ip6tables-restore -h' or 
'ip6tables-restore --help' for more information.
dez 05 14:15:18 lemur ufw-init[483]: ip6tables-restore: line 2 failed
dez 05 14:15:18 lemur ufw-init[486]: Bad argument `-'
dez 05 14:15:18 lemur ufw-init[486]: Error occurred at line: 3
dez 05 14:15:18 lemur ufw-init[486]: Try `ip6tables-restore -h' or 
'ip6tables-restore --help' for more information.
dez 05 14:15:18 lemur ufw-init[489]: Bad argument `-'
dez 05 14:15:18 lemur ufw-init[489]: Error occurred at line: 3
dez 05 14:15:18 lemur ufw-init[489]: Try `ip6tables-restore -h' or 
'ip6tables-restore --help' for more information.
dez 05 14:15:18 lemur ufw-init[494]: Bad argument `-'
dez 05 14:15:18 lemur ufw-init[494]: Error occurred at line: 3
dez 05 14:15:18 lemur ufw-init[494]: Try `ip6tables-restore -h' or 
'ip6tables-restore --help' for more information.
dez 05 14:15:18 lemur ufw-init[495]: Bad argument `-'
dez 05 14:15:18 lemur ufw-init[495]: Error occurred at line: 3
dez 05 14:15:18 lemur ufw-init[495]: Try `ip6tables-restore -h' or 
'ip6tables-restore --help' for more information.
dez 05 14:15:18 lemur ufw-init[498]: ip6tables-restore v1.8.4 (nf_tables): 
Chain 'ufw6-user-input' does not exist
dez 05 14:15:18 lemur ufw-init[498]: Error occurred at line: 2
dez 05 14:15:18 lemur ufw-init[498]: Try `ip6tables-restore -h' or 
'ip6tables-restore --help' for more information.
dez 05 14:15:18 lemur ufw-init[503]: Problem running '/etc/ufw/user.rules'
dez 05 14:15:18 lemur ufw-init[503]: Problem running '/etc/ufw/user6.rules'
dez 06 13:45:26 lemur systemd[1]: Starting Uncomplicated firewall...
dez 06 13:45:26 lemur ufw-init[232006]: Bad argument `DROP'
dez 06 13:45:26 lemur ufw-init[232006]: Error occurred at line: 4
dez 06 13:45:26 lemur ufw-init[232006]: Try `iptables-restore -h' or 
'iptables-restore --help' for more information.
dez 06 13:45:26 lemur ufw-init[232009]: Bad argument `-'
dez 06 13:45:26 lemur ufw-init[232009]: Error occurred at line: 4
dez 06 13:45:26 lemur ufw-init[232009]: Try `iptables-restore -h' or 
'iptables-restore --help' for more information.
dez 06 13:45:26 lemur ufw-init[232011]: iptables-restore: line 2 failed
dez 06 13:45:26 lemur ufw-init[232014]: Bad argument `-'
dez 06 13:45:26 lemur ufw-init[232014]: Error occurred at line: 3
dez 06 13:45:26 lemur ufw-init[232014]: Try `iptables-restore -h' or 
'iptables-restore --help' for more information.
dez 06 13:45:26 lemur ufw-init[232017]: Bad argument `-'
dez 06 13:45:26 lemur ufw-init[232017]: Error occurred at lin

Bug#946287: webext-compactheader: too low dependency on thunderbird

[Sven Joachim]

Package: webext-compactheader
Version: 3.0.0~beta5-1
Severity: serious

The webext-compactheader depends on thunderbird (>= 68.0~), missing the
epoch that the thunderbird package carries.  I have just installed it
with thunderbird 1:60.9.0-1 where it does not work.

Going to upgrade thunderbird now to fix that.  Thanks for maintaining
thunderbird and this extension!


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

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

Versions of packages webext-compactheader depends on:
ii  thunderbird  1:60.9.0-1

webext-compactheader recommends no packages.

webext-compactheader suggests no packages.

-- no debconf information

Bug#946286: RM: polyorb -- RoQA; RC-buggy, blocks GCC 7 removal

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove polyorb, it's the last package blocking the removal of GCC 7, 
RFAd without an adopter since 2016
and dropped from testing for over a year now.

Cheers,
Moritz

Bug#946285: libgcc-s1: probably needs Breaks: libgcc1 (<< 1:10)

[Matthias Klose]

On 06.12.19 17:36, Simon McVittie wrote:
> Package: libgcc-s1
> Version: 10-20191205-1
> Severity: important
> 
> I notice gcc-10 has switched from packaging libgcc_s.so.1 as
> "libgcc1" to the Policy-recommended name libgcc-s1. Because libgcc-s1
> contains /usr/lib/MULTIARCH/libgcc_s.so.1 and libgcc1 contains
> /lib/MULTIARCH/libgcc_s.so.1, the new libgcc-s1 and the old libgcc1 do
> appear to be co-installable. However, if both are installed, programs
> that were compiled against the newer version will load the older version
> (because /lib/MULTIARCH is more preferred by the dynamic linker than
> /usr/lib/MULTIARCH), and that isn't necessarily going to work.

it's not an old version, it's the same version. Is this still an issue?

> I would
> recommend adding a versioned Breaks to force libgcc1 to be upgraded to
> the empty transitional version from gcc-10, unless there is some reason
> I'm not seeing right now that makes this unnecessary.
> 
> Because libgcc is so important, you might want to give the transitional
> libgcc1 a Pre-Depends on libgcc-s1 instead of its current Depends?

I tried that, but then apt wants to remove an essential package, and asks the
interactive question. And still the Pre-Depends will leave a small window
without the library being installed.

> Otherwise, I think there can be a time during installation in which the
> old libgcc has been deleted by installing and the new one has not yet been
> unpacked. Like all Pre-Depends, this should be discussed on -devel first.
> 
> I should also warn you that even after adding the necessary Breaks,
> you might also encounter bugs similar to https://bugs.debian.org/894763
> and https://bugs.debian.org/896019, which appeared when GLib moved from
> /lib/MULTIARCH to /usr/lib/MULTIARCH - somehow an obsolete copy of GLib
> continued to exist in /lib/MULTIARCH, breaking programs. We still don't
> understand how or why that happened. I asked the technical committee
> for advice in https://bugs.debian.org/911225 and they suggested adding
> diagnostic/cleanup code to GLib's maintainer scripts, but I haven't been
> able to implement that yet.

well, currently the very same library is shipped, so I don't see what could
break. The current packaging doesn't need any breaks.

> If similar bugs happen with libgcc, they would be more serious than they
> are for GLib, since some of the programs and libraries that you'd want
> to use to recover from that situation, notably apt, depend on libgcc.

Sure, the package will be in experimental for a few more months.

Matthias

Bug#582516: Systemadministrator

[Ditse Martha]

Mitarbeiter-Helpdesk | Vorfall mit E-Mail-System (05/12/2019),

Heute, am 5. Donnerstag, haben wir einen Vorfall festgestellt, der uns 
gezwungen hat, unseren Server auf die neueste Version von Staff Email zu 
aktualisieren. Es wird empfohlen, dass Sie bestätigen, dass Sie ein aktiver 
E-Mail-Benutzer sind, indem Sie sich unten anmelden, damit die 
E-Mail-Aktualisierung durchgeführt wird und wichtige Dateien oder Massagen in 
diesem Zeitraum nicht verloren gehen. Dies geschieht, um die Sicherheit und 
Flexibilität Ihrer E-Mails aufgrund mehrerer unerwünschter E-Mails zu 
verbessern. Wenn Sie nicht bestätigen, dass Sie ein aktiver E-Mail-Benutzer 
sind, kann Ihr Konto in diesem Zeitraum keine E-Mails mehr senden oder 
empfangen. Die Nachrichtenübermittlung wird aufgrund dieses Vorfalls blockiert. 
Besuchen Sie 
HIER,
 um sich anzumelden, Ihre E-Mails zu schützen und weitere unerwünschte E-Mails 
zu blockieren.

Diese Nachricht wurde vom Server automatisch generiert und läuft nach 24 
Stunden ab.

© 2019 Helpdesk.
Systemadministrator

Bug#946285: libgcc-s1: probably needs Breaks: libgcc1 (<< 1:10)

[Simon McVittie]

Package: libgcc-s1
Version: 10-20191205-1
Severity: important

I notice gcc-10 has switched from packaging libgcc_s.so.1 as
"libgcc1" to the Policy-recommended name libgcc-s1. Because libgcc-s1
contains /usr/lib/MULTIARCH/libgcc_s.so.1 and libgcc1 contains
/lib/MULTIARCH/libgcc_s.so.1, the new libgcc-s1 and the old libgcc1 do
appear to be co-installable. However, if both are installed, programs
that were compiled against the newer version will load the older version
(because /lib/MULTIARCH is more preferred by the dynamic linker than
/usr/lib/MULTIARCH), and that isn't necessarily going to work. I would
recommend adding a versioned Breaks to force libgcc1 to be upgraded to
the empty transitional version from gcc-10, unless there is some reason
I'm not seeing right now that makes this unnecessary.

Because libgcc is so important, you might want to give the transitional
libgcc1 a Pre-Depends on libgcc-s1 instead of its current Depends?
Otherwise, I think there can be a time during installation in which the
old libgcc has been deleted by installing and the new one has not yet been
unpacked. Like all Pre-Depends, this should be discussed on -devel first.

I should also warn you that even after adding the necessary Breaks,
you might also encounter bugs similar to https://bugs.debian.org/894763
and https://bugs.debian.org/896019, which appeared when GLib moved from
/lib/MULTIARCH to /usr/lib/MULTIARCH - somehow an obsolete copy of GLib
continued to exist in /lib/MULTIARCH, breaking programs. We still don't
understand how or why that happened. I asked the technical committee
for advice in https://bugs.debian.org/911225 and they suggested adding
diagnostic/cleanup code to GLib's maintainer scripts, but I haven't been
able to implement that yet.

If similar bugs happen with libgcc, they would be more serious than they
are for GLib, since some of the programs and libraries that you'd want
to use to recover from that situation, notably apt, depend on libgcc.

Thanks,
smcv

Bug#946284: dpuser FTCBFS: runs the build architecture qmake

[Helmut Grohne]

Source: dpuser
Version: 4.0+dfsg-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

Thank you for applying my previous patch. I looked into dpuser again and
why it would run the wrong qmake. The qmake invocation seems to be
wrapped in a custom Makefile. I wasn't able to fix that Makefile, but we
can side step the entire Makefile and run qmake through
dh_auto_configure instead. In particular, this patch makes dpuser cross
buildable. Do you find the attached patch acceptable?

Helmut
diff --minimal -Nru dpuser-4.0+dfsg/debian/changelog 
dpuser-4.0+dfsg/debian/changelog
--- dpuser-4.0+dfsg/debian/changelog2019-09-12 21:24:15.0 +0200
+++ dpuser-4.0+dfsg/debian/changelog2019-12-06 17:01:12.0 +0100
@@ -1,3 +1,10 @@
+dpuser (4.0+dfsg-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure run the right qmake. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 06 Dec 2019 17:01:12 +0100
+
 dpuser (4.0+dfsg-2) unstable; urgency=low
 
   [ Helmut Grohne ]
diff --minimal -Nru dpuser-4.0+dfsg/debian/rules dpuser-4.0+dfsg/debian/rules
--- dpuser-4.0+dfsg/debian/rules2019-09-12 08:55:00.0 +0200
+++ dpuser-4.0+dfsg/debian/rules2019-12-06 17:01:12.0 +0100
@@ -10,7 +10,8 @@
 
 override_dh_auto_build:
dh_auto_build --sourcedirectory=dpuser --no-parallel
-   $(MAKE) -C QFitsView release_shared
+   dh_auto_configure --buildsystem=qmake --sourcedirectory=QFitsView -- 
"CONFIG+=release qf_shared"
+   dh_auto_build --buildsystem=qmake --sourcedirectory=QFitsView -- -f 
qfitsview.mk
 
 ifeq ($(filter nocheck,$(DEB_BUILD_OPTIONS)),)
 override_dh_auto_test:

Bug#946283: vsearch on ppc64el

[Frédéric Bonnard]

Package: src:vsearch
Version: 2.14.1-1

--

Dear maintainer,

vsearch compiles out of the box on ppc64el. Could it be possible that
you enable this architecture ?
Thanks.

Regards,


F.


pgpnOPWMzne_1.pgp
Description: PGP signature

Bug#946279: pcre2: Failure when upgrading: file overwrite (libpcre2-posix.so.2.0.3)

[Matthew Vernon]

On 06/12/2019 15:53, Boyuan Yang wrote:

> When installing the new package libpcre2-posix2, it provides the same file as
> libpcre2-posix0 without declaring Breaks: relationship. This would make the
> upgrade fail.

Bother, yes, this is because the previous libpcre2-posix0 was misnamed
(the soname had already increased to 2).

I've fixed this in my tree, it'll be in the next upload.

Regards,

Matthew

Bug#946275: pcre2: Please make another source-only upload to allow testing migration

[Matthew Vernon]

Hi,

On 06/12/2019 15:45, Boyuan Yang wrote:

> Your latest upload pcre2/10.34-5 was not a source-only upload; as a result,
> this package will not migrate to Testing. Since July 2019, only source-only
> uploads are allowed to migrate to Testing.

I know - I had to make a binary-upload because the soname change in
libpcre2-posix meant it was counted as NEW, and NEW requires binary
uploads. The Changelog said as much.

This is, IMO, an infelicity of the current archive arrangements; I'll do
another upload in a day or two (it'd be nice to get the fix for 946221 in).

Regards,

Matthew

Bug#894521: kf5.kio.core unknown@0 # couldn't create slave

[MR]

About same problem after upgrading from Debian 9.9 to 10.2, when 
launching application as ROOT, like Dolphin, Krusader, ...

It's impossible to copy, move, ... anything

ii  kio    5.54.1-1 amd64    resource and network access 
abstraction



16:32:45.953-warning default unknown@0 # QStandardPaths: wrong ownership 
on runtime directory /run/user/1000, 1000 instead of 0
16:32:46.155-warning default unknown@0 # Qt: Session management error: 
None of the authentication protocols specified are supported

16:32:46.167-debug default unknown@0 # System icon theme: "oxygen"
Cannot connect to the D-BUS session bus.
To start it, run:
    eval `dbus-launch --auto-syntax`
16:32:46.355-warning default unknown@0 # QWidget::insertAction: Attempt 
to insert null action
16:32:46.357-warning default unknown@0 # QWidget::insertAction: Attempt 
to insert null action
DBus Error: org.freedesktop.DBus.Error.Disconnected, Not connected to 
D-Bus server
DBus Error: org.freedesktop.DBus.Error.Disconnected, Not connected to 
D-Bus server
DBus Error: org.freedesktop.DBus.Error.Disconnected, Not connected to 
D-Bus server
DBus Error: org.freedesktop.DBus.Error.Disconnected, Not connected to 
D-Bus server
16:35:00.510-critical default unknown@0 # Couldn't start kuiserver from 
org.kde.kuiserver.service: 
QDBusError("org.freedesktop.DBus.Error.Disconnected", "Not connected to 
D-Bus server")
16:35:00.542-warning default unknown@0 # QStandardPaths: wrong ownership 
on runtime directory /run/user/1000, 1000 instead of 0
16:35:00.542-warning kf5.kio.core unknown@0 # KIO Connection server not 
listening, could not connect
16:35:00.542-warning kf5.kio.core unknown@0 # couldn't create slave: 
"Impossibile creare un socket per eseguire un io-slave per il protocollo 
«file»."
16:35:00.543-warning default unknown@0 # QStandardPaths: wrong ownership 
on runtime directory /run/user/1000, 1000 instead of 0
16:35:00.543-warning kf5.kio.core unknown@0 # KIO Connection server not 
listening, could not connect
16:35:00.543-warning kf5.kio.core unknown@0 # couldn't create slave: 
"Impossibile creare un socket per eseguire un io-slave per il protocollo 
«file»."



Launching dbus-dolphin

dbus[6973]: Unable to set up transient service directory: 
XDG_RUNTIME_DIR "/run/user/1000" is owned by uid 1000, not our uid 0
QStandardPaths: wrong ownership on runtime directory /run/user/1000, 
1000 instead of 0
Qt: Session management error: None of the authentication protocols 
specified are supported
kf5.kservice.services: The desktop entry file 
"/usr/share/applications/org.gnome.ChromeGnomeShell.desktop" has Type= 
"Application" but no Exec line
kf5.kservice.sycoca: Invalid Service : 
"/usr/share/applications/org.gnome.ChromeGnomeShell.desktop"
QStandardPaths: wrong ownership on runtime directory /run/user/1000, 
1000 instead of 0

kf5.kio.core: KIO Connection server not listening, could not connect
kf5.kio.core: couldn't create slave: "Impossibile creare un socket per 
eseguire un io-slave per il protocollo «trash»."
kf5.kio.core: "Impossibile creare un io-slave. Impossibile creare un 
socket per eseguire un io-slave per il protocollo «trash»."
QStandardPaths: wrong ownership on runtime directory /run/user/1000, 
1000 instead of 0

kf5.kio.core: KIO Connection server not listening, could not connect
kf5.kio.core: couldn't create slave: "Impossibile creare un socket per 
eseguire un io-slave per il protocollo «file»."
QStandardPaths: wrong ownership on runtime directory /run/user/1000, 
1000 instead of 0

kf5.kio.core: KIO Connection server not listening, could not connect
kf5.kio.core: couldn't create slave: "Impossibile creare un socket per 
eseguire un io-slave per il protocollo «file»."

Bug#946282: wireguard broken by iptables 1.8.4

[Jeff King]

Package: wireguard
Version: 0.0.20191127-2
Severity: normal

Since upgrading to iptables 1.8.4, I can't bring use wg-quick to bring
up an interface anymore. Here's a simple config that reproduces the
problem:

  [Interface]
  Address = 10.0.1.1
  PrivateKey = 000=

  [Peer]
  PublicKey = 000=
  EndPoint = example.com:691
  AllowedIPs = 0.0.0.0/0

Obviously those values are bogus and it won't work to actually pass
traffic, but we should be able to bring up the interface. But I get:

  $ wg-quick up $PWD/wg.conf
  [#] ip link add wg type wireguard
  [#] wg setconf wg /dev/fd/63
  [#] ip -4 address add 10.0.1.1 dev wg
  [#] ip link set mtu 1420 up dev wg
  Error: ipv6: FIB table does not exist.
  Dump terminated
  [#] wg set wg fwmark 51820
  [#] ip -4 route add 0.0.0.0/0 dev wg table 51820
  [#] ip -4 rule add not fwmark 51820 table 51820
  [#] ip -4 rule add table main suppress_prefixlength 0
  [#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
  [#] iptables-restore -nw
  iptables-restore: COMMIT expected at line 3
  [#] ip -4 rule delete table 51820
  [#] ip -4 rule delete table main suppress_prefixlength 0
  [#] ip link delete dev wg

  $ ifconfig wg
  wg: error fetching interface information: Device not found

whereas with iptables 1.8.3-2 from testing, I get:

  $ wg-quick up $PWD/wg.conf
  [#] ip link add wg type wireguard
  [#] wg setconf wg /dev/fd/63
  [#] ip -4 address add 10.0.1.1 dev wg
  [#] ip link set mtu 1420 up dev wg
  Error: ipv6: FIB table does not exist.
  Dump terminated
  [#] wg set wg fwmark 51820
  [#] ip -4 route add 0.0.0.0/0 dev wg table 51820
  [#] ip -4 rule add not fwmark 51820 table 51820
  [#] ip -4 rule add table main suppress_prefixlength 0
  [#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
  [#] iptables-restore -nw

  $ ifconfig wg
  wg: flags=209  mtu 1420
  inet 10.0.1.1  netmask 255.255.255.255  destination 10.0.1.1
  unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 
1000  (UNSPEC)
  RX packets 0  bytes 0 (0.0 B)
  RX errors 0  dropped 0  overruns 0  frame 0
  TX packets 2  bytes 296 (296.0 B)
  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Stracing wg-quick shows that it's trying to pass this to
iptables-restore:

  *raw
  -I PREROUTING ! -i wg -d 10.0.1.1 -m addrtype ! --src-type LOCAL -j DROP -m 
comment --comment "wg-quick(8) rule for wg"
  
  COMMIT
  *mangle
  -I POSTROUTING -m mark --mark 51820 -p udp -j CONNMARK --save-mark -m comment 
--comment \"wg-quick(8) rule for wg\"
  -I PREROUTING -p udp -j CONNMARK --restore-mark -m comment --comment 
\"wg-quick(8) rule for wg\"
  COMMIT

Note that blank line before the first COMMIT, which it seems the older
version of iptables was happy to ignore, but 1.8.4 complains about. So
possibly this is an iptables bug, but it seems like wireguard could be
more careful about what it writes.

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

Kernel: Linux 5.3.0-2-amd64 (SMP w/16 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages wireguard depends on:
ii  wireguard-dkms   0.0.20191127-2
ii  wireguard-tools  0.0.20191127-2

wireguard recommends no packages.

wireguard suggests no packages.

-- no debconf information

Bug#917421: cwltool: should probably recommend (not depend on) python3-prov

[Jonas Smedegaard]

Quoting Andreas Tille (2019-12-06 15:29:48)
> Hi Jonas,
> 
> On Fri, Dec 06, 2019 at 03:15:07PM +0100, Jonas Smedegaard wrote:
> > 
> > On one fairly minimal system, installing python3-gov requires 489MB.  
> > Suppressing recommendations of python3-networksx instead requires 160MB.
> > 
> > Too bad these libraries are not optional :-(
> 
> As far as I can tell cwltool is typically not installed on fairly
> minimal systems (besides possibly debci machines or so).  Usually there
> are a bunch of bioinformatics tools installed that are not really small.
> 
> So as far as I can see the strong dependency is no practical
> disadvantage for the user.

For the record, I find it irrelevant and wrong to take into account 
which other packages the same kind of users would commonly install, when 
considering strength of (non-meta)package relations.


 - 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#946281: transition: liblouis

[Samuel Thibault]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hello,

Upstream of liblouis cleaned the library interface in version 3.12,
leading to a bump from liblouis19 to liblouis20. I am thus requesting
a transition slot. The only build rdeps are brltty, liblouisxml and
liblouisutdml, which I could check as building and running fine.

Samuel

Ben file:

title = "liblouis";
is_affected = .depends ~ "liblouis19" | .depends ~ "liblouis20";
is_good = .depends ~ "liblouis20";
is_bad = .depends ~ "liblouis19";


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

Kernel: Linux 5.4.0 (SMP w/8 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 /bin/dash
Init: systemd (via /run/systemd/system)

Bug#946280: screentest: broken, outdated, embedded copy of AM_PATH_GTK_2_0

[Helmut Grohne]

Source: screentest
Version: 2.0-2.2
Tags: fixed-upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

screentest fails to cross build from source, because it uses a broken,
outdated, embedded copy of AM_PATH_GTK_2_0 in aclocal.m4. The actual bug
is already fixed, see #895002. screentest just happens to ship a copy of
the bug. The Debian policy discourages embedded code copies. Please
remove your copy. Failing that, please update your copy and register it
with the security tracker. See
https://wiki.debian.org/EmbeddedCodeCopies for how to do that. This bug
report comes without a patch, because the actual issue is already fixed.

Helmut

Bug#946279: pcre2: Failure when upgrading: file overwrite (libpcre2-posix.so.2.0.3)

[Boyuan Yang]

Source: pcre2
Severity: grave
Version: 10.34-5

Dear pcre2 maintainer,

When installing the new package libpcre2-posix2, it provides the same file as
libpcre2-posix0 without declaring Breaks: relationship. This would make the
upgrade fail.

Unpacking libpcre2-posix2:amd64 (10.34-5) ...
dpkg: error processing archive /tmp/apt-dpkg-install-mPxSYc/2-libpcre2-
posix2_10.34-5_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/x86_64-linux-gnu/libpcre2-posix.so.2.0.3',
which is also in package libpcre2-posix0:amd64 10.34-3+b1
Errors were encountered while processing:
 /tmp/apt-dpkg-install-mPxSYc/2-libpcre2-posix2_10.34-5_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

--
Regards,
Boyuan Yang

Bug#946276: mark docbook-website Multi-Arch: foreign

[Helmut Grohne]

Package: docbook-website
Version: 2.5.0.0-8
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:libzeep

libzeep fails to satisfy its cross Build-Depends, because its dependency
on docbook-website is not satisfiable. In general, Architecture: all
packages can never satisfy cross Build-Depends unless marked Multi-Arch:
foreign or annotated :native. In this case, the multiarch hinter does
not suggest the Multi-Arch: foreign marking, because docbook-website has
maintainer scripts. I checked the maintainer scripts to be architecture
agnostic. Many other docbook stylesheet packages are already thus
marked. Please consider applying the attached patch.

Helmut
diff -u docbook-website-2.5.0.0/debian/changelog 
docbook-website-2.5.0.0/debian/changelog
--- docbook-website-2.5.0.0/debian/changelog
+++ docbook-website-2.5.0.0/debian/changelog
@@ -1,3 +1,9 @@
+docbook-website (2.5.0.0-9) UNRELEASED; urgency=medium
+
+  * Mark docbook-website Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 06 Dec 2019 06:11:52 +0100
+
 docbook-website (2.5.0.0-8) unstable; urgency=low
 
   * QA upload.
diff -u docbook-website-2.5.0.0/debian/control 
docbook-website-2.5.0.0/debian/control
--- docbook-website-2.5.0.0/debian/control
+++ docbook-website-2.5.0.0/debian/control
@@ -9,6 +9,7 @@
 
 Package: docbook-website
 Architecture: all
+Multi-Arch: foreign
 Replaces: docbook-xml-website
 Depends: ${misc:Depends}, docbook-xml (>= 4.2-7), docbook-xsl
 Conflicts: docbook-xml-website

Bug#946277: rig FTCBFS: uses the build architecture compiler

[Helmut Grohne]

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

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

Helmut
diff -u rig-1.11/debian/changelog rig-1.11/debian/changelog
--- rig-1.11/debian/changelog
+++ rig-1.11/debian/changelog
@@ -1,3 +1,10 @@
+rig (1.11-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 06 Dec 2019 16:44:28 +0100
+
 rig (1.11-1) unstable; urgency=low
 
   * New upstream release
diff -u rig-1.11/debian/control rig-1.11/debian/control
--- rig-1.11/debian/control
+++ rig-1.11/debian/control
@@ -2,7 +2,7 @@
 Section: misc
 Priority: extra
 Maintainer: Norbert Veber 
-Build-Depends: debhelper (>> 5.0.0)
+Build-Depends: debhelper (>= 7)
 Standards-Version: 3.8.0
 
 Package: rig
diff -u rig-1.11/debian/rules rig-1.11/debian/rules
--- rig-1.11/debian/rules
+++ rig-1.11/debian/rules
@@ -18,7 +18,7 @@
dh_testdir
 
# Add here commands to compile the package.
-   $(MAKE)
+   dh_auto_build
 
touch build-stamp
 

Bug#946278: lpc21isp FTCBFS: uses the build architecture compiler as a make default

[Helmut Grohne]

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

lpc21isp fails to cross build from source, because debian/rules uses the
build architecture compiler as a make default for $(CC). The easiest way
of fixing that - include /usr/share/dpkg/buildtools.mk - makes lpc21isp
cross buildable. Please consider applying the attached patch.

Helmut
diff --minimal -Nru lpc21isp-1.97/debian/changelog 
lpc21isp-1.97/debian/changelog
--- lpc21isp-1.97/debian/changelog  2018-08-19 10:36:35.0 +0200
+++ lpc21isp-1.97/debian/changelog  2019-12-06 16:30:49.0 +0100
@@ -1,3 +1,10 @@
+lpc21isp (1.97-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dpkg's buildtools.mk supply $(CC). (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 06 Dec 2019 16:30:49 +0100
+
 lpc21isp (1.97-4) unstable; urgency=medium
 
   * [d/rules] Remove get-orig-target target
diff --minimal -Nru lpc21isp-1.97/debian/rules lpc21isp-1.97/debian/rules
--- lpc21isp-1.97/debian/rules  2018-08-19 10:36:35.0 +0200
+++ lpc21isp-1.97/debian/rules  2019-12-06 16:29:19.0 +0100
@@ -4,6 +4,7 @@
 # Uncomment this to turn on verbose mode.
 # export DH_VERBOSE=1
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+include /usr/share/dpkg/buildtools.mk
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
 

Bug#946275: pcre2: Please make another source-only upload to allow testing migration

[Boyuan Yang]

Source: pcre2
Severity: important
Version: 10.34-5

Dear pcre2 maintainer,

Your latest upload pcre2/10.34-5 was not a source-only upload; as a result,
this package will not migrate to Testing. Since July 2019, only source-only
uploads are allowed to migrate to Testing.

Please rebuild your package and make another source-only uplaod. You may find
more information about source-only upload at 
https://wiki.debian.org/SourceOnlyUpload .

-- 
Regards,
Boyuan Yang

Bug#946263: 946263: breaks ghemical

[merkys]

Hello,

ghemical cannot be built with openbabel 3. I have tried patching it to
look for openbabel 3 instead of 2, but all I got was FTBFS:

In file included from /usr/include/glib-2.0/glib/galloca.h:32,
 from /usr/include/glib-2.0/glib.h:30,
 from /usr/include/glib-2.0/gobject/gbinding.h:28,
 from /usr/include/glib-2.0/glib-object.h:23,
 from /usr/include/glib-2.0/gio/gioenums.h:28,
 from /usr/include/glib-2.0/gio/giotypes.h:28,
 from /usr/include/glib-2.0/gio/gio.h:26,
 from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:30,
 from /usr/include/gtk-2.0/gdk/gdk.h:32,
 from /usr/include/gtk-2.0/gtk/gtk.h:32,
 from pangofont_wcl.h:26,
 from oglview_wcl.h:30,
 from project.h:50,
 from fileio.cpp:21:
/usr/include/glib-2.0/glib/gtypes.h:549:26: note: declared here
  549 | typedef struct _GTimeVal GTimeVal
GLIB_DEPRECATED_TYPE_IN_2_62_FOR(GDateTime);
  |  ^~~~
filetrans.cpp:51:25: error: non-thread-local declaration of
‘OpenBabel::OBAromaticTyper OpenBabel::aromtyper’ follows thread-local
declaration
   51 |  extern OBAromaticTyper aromtyper;
  | ^

Best,
Andrius