Bug#918316: nocache: FTBFS in sid

[Sven Joachim]

On 2019-01-04 22:49 +, Santiago Vila wrote:

> Package: src:nocache
> Version: 1.1-1
> Severity: serious
> Tags: ftbfs
>
> Dear maintainer:
>
> I tried to build this package in sid but it failed:
>
> 
> [...]
>  debian/rules build-arch
> dh build-arch
>dh_update_autotools_config -a
>dh_autoreconf -a
>dh_auto_configure -a
>dh_auto_build -a
>   make -j1 "INSTALL=install --strip-program=true"
> make[1]: Entering directory '/<>'
> cc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
> -Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 
> -Wl,-z,relro -Wl,-z,now -o cachedel cachedel.c
> cc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
> -Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 
> -Wl,-z,relro -Wl,-z,now -o cachestats cachestats.c
> cc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
> -Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 
> -Wl,-z,relro -Wl,-z,now -fPIC -c -o nocache.o nocache.c
> cc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
> -Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 
> -Wl,-z,relro -Wl,-z,now -fPIC -c -o fcntl_helpers.o fcntl_helpers.c
> cc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
> -Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 
> -Wl,-z,relro -Wl,-z,now -fPIC -c -o pageinfo.o pageinfo.c
> cc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
> -Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 
> -Wl,-z,relro -Wl,-z,now -pthread -shared -Wl,-soname,nocache.so -o nocache.so 
> nocache.o fcntl_helpers.o pageinfo.o -ldl
> sed 's!##libdir##!$(dirname "$0")!' nocache
> chmod a+x nocache
> make[1]: Leaving directory '/<>'
>debian/rules override_dh_auto_test
> make[1]: Entering directory '/<>'
> ## #916415
> timeout 11 ./nocache apt show coreutils 1>>/dev/null
>
> WARNING: apt does not have a stable CLI interface. Use with caution in 
> scripts.
>
> make[1]: *** [debian/rules:21: override_dh_auto_test] Error 124

I get a different error here:

,
| ## #916415
| timeout 11 ./nocache apt show coreutils 1>>/dev/null
| apt: nocache.c:148: init_mutexes: Assertion `fds_lock != NULL' failed.
| Aborted
| make[1]: *** [debian/rules:21: override_dh_auto_test] Error 134
`

Increasing the timeout to 60 as you suggested does not help.

Cheers,
   Sven

Bug#918329: apriltag ftbfs on release architectures

[Matthias Klose]

Package: src:apriltag
Version: 0.10.0-1
Severity: serious
Tags: sid buster

apriltag ftbfs on release architectures, where it built before.  Looks like the
build system is exaggerating optimization flags, using -O4 nonsense.

Bug#918259: idle-python3.6 is not installable in unstable

[Matthias Klose]

On 04.01.19 20:58, Adrian Bunk wrote:
> Package: idle-python3.6
> Severity: serious
> 
> The following packages have unmet dependencies:
>  idle-python3.6 : Depends: python3.6-tk but it is not installable

it doesn't make sense to file this issue, with the python3.6 removal pending.

Bug#918328: aptitude: symbol lookup error: aptitude: undefined symbol: _ZN6Xapian4MSetC1EOS0_

[Ted Percival]

Package: aptitude
Version: 0.8.11-3
Severity: important

Starting aptitude fails due to a missing Xapian symbol:

$ aptitude
aptitude: symbol lookup error: aptitude: undefined symbol:
_ZN6Xapian4MSetC1EOS0_

This is probably a bug in the syms in the applicable xapian library package
causing aptitude to get a library dependency that is too weak.

In particular, my system has a recent version of aptitude with an older version
of libxapian30, so there was probably a new symbol introduced in libxapian30
without adjusting the shared library dependency information.

$ apt-cache policy aptitude
aptitude:
  Installed: 0.8.11-3
  Candidate: 0.8.11-6
  Version table:
 0.8.11-6 500
500 http://mirrors.xmission.com/debian testing/main amd64 Packages
500 http://mirrors.xmission.com/debian unstable/main amd64 Packages
 *** 0.8.11-3 100
100 /var/lib/dpkg/status
 0.8.7-1 990
990 http://mirrors.xmission.com/debian stable/main amd64 Packages

$ apt-cache policy libxapian30
libxapian30:
  Installed: 1.4.3-2+deb9u2
  Candidate: 1.4.3-2+deb9u2
  Version table:
 1.4.9-1 500
500 http://mirrors.xmission.com/debian testing/main amd64 Packages
500 http://mirrors.xmission.com/debian unstable/main amd64 Packages
 *** 1.4.3-2+deb9u2 990
990 http://mirrors.xmission.com/debian stable/main amd64 Packages
100 /var/lib/dpkg/status


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

aptitude version information:

aptitude linkage:
linux-vdso.so.1 (0x7ffdbd4e5000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 
(0x7f7386abf000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7f7386a85000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7f7386a57000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f738685)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7f738674a000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f7386629000)
libboost_iostreams.so.1.62.0 => 
/usr/local/lib/libboost_iostreams.so.1.62.0 (0x7f738660a000)
libboost_system.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.62.0 (0x7f7386605000)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 
(0x7f73861f1000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f73861d)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f738604d000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f7385eca000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f7385eae000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f7385ced000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7f7385cd3000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f7385ab5000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f7385aa2000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f738587c000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7f7385668000)
libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 
(0x7f73855cd000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f73855ac000)
/lib64/ld-linux-x86-64.so.2 (0x7f7387101000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f73855a7000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f738559d000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f7385396000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common   0.8.11-3
ii  libapt-pkg5.0 1.8.0~alpha2
ii  libboost-iostreams1.62.0  1.62.0+dfsg-10
ii  libboost-system1.62.0 1.62.0+dfsg-10
ii  libc6 2.28-4
ii  libcwidget3v5 0.5.17-11
ii  libgcc1   1:8.2.0-13
ii  libncursesw6  6.1+20181013-1
ii  libsigc++-2.0-0v5 2.10.0-1
ii  libsqlite3-0  3.25.3-2
ii  libstdc++68.2.0-13
ii  libtinfo6 6.1+20181013-1
ii  libxapian30   1.4.3-2+deb9u2

Versions of packages aptitude recommends:
ii  libparse-debianchangelog-perl  1.2.0-12
ii  sensible-utils 0.0.9+deb9u1

Versions of packages aptitude suggests:
ii  apt-xapian-index0.49

Bug#918327: ERROR #80 extracting when an ISO file contains non-english characters.

[Gong S.]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: wit
Version: 3.01a-2

It looks like that "wit" expects that everything is in English, and crashed 
when dealing with files that contain non-english entries.
===BEGIN OUTPUT===
pthfdr:/r/m/s/W/q>wit copy --fst test.iso Popn\ Music_\[R83EA4].wbfs/
*  wit: Wiimms ISO Tool v3.01a r0 x86_64 - Dirk Clemens - 2018-10-25  *
wit: EXTRACT 1/1 ISO:test.iso -> Popn Music_[R83EA4].wbfs/
!! wit: ERROR #80 [CAN'T CREATE FILE] in CreateFileFST() @ 
src/iso-interface.c#2987
!!  Can't create temp file: Popn 
Music_[R83EA4].wbfs/./files/g3ddemo/3ddemo/CutieLiveHouse/nw4reffect/t@C¼Íeffect_liveŨ袵ܷB
!! wit: ERROR #80 [CAN'T CREATE FILE] in CreateFileFST() @ 
src/iso-interface.c#2987
!!  Can't create temp file: Popn 
Music_[R83EA4].wbfs/./files/g3ddemo/3ddemo/SpecialDJClub/nw4reffect/t@C¼Íeffect_djŨ袵ܷB
!! wit: ERROR #80 [CAN'T CREATE FILE] in CreateFileFST() @ 
src/iso-interface.c#2987
!!  Can't create temp file: Popn 
Music_[R83EA4].wbfs/./files/g3ddemo/3ddemo/SweetsStage/nw4reffect/t@C¼Íeffect_sweetsŨ袵ܷB
!! wit: ERROR #80 [CAN'T CREATE FILE] in ExtractImage() @ src/lib-sf.c#3408
!!  3 files and/or directories not created.
===END OUTPUT===
--
"And in the naked light, I saw ten thousand people, maybe more. People \
talking without speaking, people hearing without listening. People writ\
ing songs that voices never shared, no one dared disturb the sound of s\
ilence." --MA Bo'yong
-BEGIN PGP SIGNATURE-
Version: ProtonMail
Comment: https://protonmail.com

wsBcBAEBCAAGBQJcMErkAAoJENi1YDlFXXQfVpkIAJgJJz4Bcv0UiVYsOqq2
V4z7UkwCCFcsRc9ljEY/jaft8WdxIW4I0Zd38C4O3+By4zqZcWLXMjcmgSbG
QSnpNRIR2negr6X0y03klDsyVW9wC9kVXtS5107g8+LfEtVimcryH5G6CGer
jXjHc+ZdAxiWXMgALoAODc/XwVCGqOUPUHAXOEspJLhpjHsXEXCRYtUn9Tgp
tzRQbrfVfJ5ArQ3KbQoX+pP8mbOU8H3VoC2EHvGsc4lTN8ifDTOrlIqVENLM
tB87vjyZV0k+KhgpPjIEcV04uYPCLK4tKNWtpcA3twbKhDQlKOwktjiKHaJ/
GrxpOc49I2Q4ymJh3wnd43k=
=UPdi
-END PGP SIGNATURE-



publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc
Description: application/pgp-keys


publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc.sig
Description: PGP signature

Bug#918188: linux: FTBFS on arm64

[Noah Meyerhans]

On Fri, Jan 04, 2019 at 06:57:21AM +0100, Salvatore Bonaccorso wrote:
> >   LD  vmlinux.o
> >   MODPOST vmlinux.o
> >   GEN .version
> >   CHK include/generated/compile.h
> >   UPD include/generated/compile.h
> >   CC  init/version.o
> >   LD  init/built-in.o
> > ./drivers/firmware/efi/libstub/lib.a(arm64-stub.stub.o): In function 
> > `handle_kernel_image':
> > ./debian/build/build_arm64_none_arm64/./drivers/firmware/efi/libstub/arm64-stub.c:63:
> >  undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_'
> > ld: ./drivers/firmware/efi/libstub/lib.a(arm64-stub.stub.o): relocation 
> > R_AARCH64_ADR_PREL_PG_HI21 against external symbol 
> > `__efistub__GLOBAL_OFFSET_TABLE_' can not be used when making a shared 
> > object; recompile with -fPIC
> > /<>/Makefile:1010: recipe for target 'vmlinux' failed
> > make[5]: *** [vmlinux] Error 1
> > Makefile:152: recipe for target 'sub-make' failed
> > make[4]: *** [sub-make] Error 2
> > Makefile:24: recipe for target '__sub-make' failed
> > make[3]: *** [__sub-make] Error 2
> > make[3]: Leaving directory 
> > '/<>/debian/build/build_arm64_none_arm64'
> > debian/rules.real:190: recipe for target 
> > 'debian/stamps/build_arm64_none_arm64' failed
> > make[2]: *** [debian/stamps/build_arm64_none_arm64] Error 2
> > make[2]: Leaving directory '/<>'
> > debian/rules.gen:400: recipe for target 'build-arch_arm64_none_arm64_real' 
> > failed
> > make[1]: *** [build-arch_arm64_none_arm64_real] Error 2
> > make[1]: Leaving directory '/<>'
> > debian/rules:41: recipe for target 'build-arch' failed
> > make: *** [build-arch] Error 2
> > dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2
> 
> https://buildd.debian.org/status/fetch.php?pkg=linux=arm64=4.9.144-1=1546572157=0

The problem was introduced with upstream commit
27b5ebf61818749b3568354c64a8ec2d9cd5ecca. Reverting that commit fixes
the build, but there may be a better option.



signature.asc
Description: PGP signature

Bug#918326: python-dfwinreg and python3-dfwinreg depend on cruft package dtfabric

[peter green]

package: python3-dfwinreg
version: 20180712-1
severity: serious

It seems that with the most recent upload the build-dependencies were fixed from "dtfabric" to 
"python-dtfabric" and "python3-dtfabric", but the binary dependencies for python-dfwinreg and 
python3-dtwinreg are still on "dtfabric", can you please fix them.

Bug#914607: closed by Hilko Bengen (Bug#914607: fixed in dfwinreg 20181214-2)

[peter green]

reassign 914607 dfwinreg
found 914607 20180712-1
fixed 914607 20181214-2
thanks

Britney gets confused when a bug is closed by a package other than the one it 
is filed against, so I am reassinging the bug to the package that closed it.

On 01/01/19 23:09, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the plaso package:

#914607: plaso depends on cruft package python-dfwinreg

It has been closed by Hilko Bengen .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Hilko Bengen 
 by
replying to this email.

Bug#918325: RM: ktap -- RoQA; kernel module not usable; dead upstream

[Ben Hutchings]

Package: ftp.debian.org
Severity: normal

As discussed in bug #832355, the ktap kernel module hasn't been
buildable since Linux 4.6 due to kernel API changes.  The
project is dead upstream, so this is unlikely ever to be fixed.
The maintainer has acknowledged this.

Ben.

Bug#917989: Probably can close

[Troy Telford]

I rebuilt my (lxc/sid) container from scratch, and copied in the original 
asterisk config.

Asterisk now works perfectly.

I did a filesystem-wide `diff` between the container that is broken and the one 
that works. There’s no smoking gun, unfortunately.

There are definitely no library differences.

What differences exist are differences are expected:  /etc/passwd & friends, 
the apt/dpkg/debconfig state files, snakeoil-certs. The list is not long.

As I’m not seeing anything at all related to asterisk, this bug can be closed.

Bug#918324: Error: Permission denied (/home/user/Downloads/torrent file)

[Marc Bonnor]

Package: transmission-daemon
Version: 2.94-2
Severity: important

Dear Maintainer,

I have been using transmission-daemon for an extended time without any
problems. Today, shortly after adding a torrent file I get an error stating
permission denied to my downloads folder in my home directory. The consequence
is that the torrent files stop downloading. I have removed the torrent and
tried again and I have rebooted as well, still get the same error.

The transmission GUI version appears to be working ok.

I see there was a recent update to the transmission packages in my aptitude log
file, but I don't see anything in the change log that may be related to my
problem.

I see there was also a recent update the apparmor package, not sure if that may
be causing my problem?




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

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

Versions of packages transmission-daemon depends on:
ii  adduser  3.118
ii  libc62.28-4
ii  libcurl4 7.62.0-1
ii  libevent-2.1-6   2.1.8-stable-4
ii  libminiupnpc17   2.1-1+b1
ii  libnatpmp1   20150609-5+b1
ii  libssl1.11.1.1a-1
ii  libsystemd0  240-2
ii  lsb-base 10.2018112800
ii  transmission-common  2.94-2
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages transmission-daemon recommends:
ii  transmission-cli  2.94-2

transmission-daemon suggests no packages.

-- Configuration Files:
/etc/default/transmission-daemon changed:
ENABLE_DAEMON=1
CONFIG_DIR="/var/lib/transmission-daemon/info" 
OPTIONS="--config-dir $CONFIG_DIR"

/etc/transmission-daemon/settings.json [Errno 13] Permission denied: 
'/etc/transmission-daemon/settings.json'

-- no debconf information

Bug#914236: ibus-chewing: Should we upgrade to v1.6.1?

[陳昌倬]

Control: fixed -1 1.6.1-1

On Tue, Nov 20, 2018 at 03:14:58PM -0500, Boyuan Yang wrote:
> Source: ibus-chewing
> Version: 1.5.1-3
> Severity: normal
> X-Debbugs-CC: m...@debian.org czc...@debian.org
> 
> I noticed that ibus-chewing is tagging some new releases but didn't
> explicitly list them on
> https://github.com/definite/ibus-chewing/releases .
> 
> @mwei @czchen I'm wondering if they are official upstream releases and
> whether we should package them in Debian for Debian Buster.

Fixed by uploading 1.6.1-1.


-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debconf,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#905877: regression in 1.4: upgrades random packages from testing to experimental (doesn't respect pinning?)

[Paul Wise]

Package: unattended-upgrades
Version: 1.9

On Sat, 11 Aug 2018 10:40:33 +0800 Paul Wise wrote:

> Recently I have had unattended-upgrades upgrade random packages from
> testing to experimental.

I thought this had been fixed but recently I got git upgraded to
experimental for some reason. I've included the full debug log below.

Unattended upgrade result: All upgrades installed 

Warning: A reboot is required to complete this upgrade, or a previous one.

Packages that were upgraded:
 git git-cvs git-doc git-email git-gui git-man git-mediawiki git-svn 
 gitk libqt5help5 libqt5multimediagsttools5 
 libqt5multimediagsttools5-dbgsym libqt5multimediaquick5 
 libqt5x11extras5 libqt5x11extras5-dbgsym python3-dbus.mainloop.pyqt5 
 python3-dbus.mainloop.pyqt5-dbg qml-module-qtmultimedia 
 qml-module-qtqml-models2 qml-module-qtquick-window2 
 qml-module-qtquick2 roodi 

Packages with upgradable origin but kept back:
 gimp gimp-data libgimp2.0 

Package installation log:
Log started: 2019-01-03  10:27:53
apt-listchanges: Reading changelogs...
apt-listchanges: Mailing root: apt-listchanges: changelogs for chianamo
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 460714 files and directories currently installed.)
Preparing to unpack .../00-git-cvs_1%3a2.20.1+next.20181228-1_all.deb ...
Unpacking git-cvs (1:2.20.1+next.20181228-1) over (1:2.19.2-1) ...
Preparing to unpack .../01-gitk_1%3a2.20.1+next.20181228-1_all.deb ...
Unpacking gitk (1:2.20.1+next.20181228-1) over (1:2.19.2-1) ...
Preparing to unpack .../02-git-svn_1%3a2.20.1+next.20181228-1_all.deb ...
Unpacking git-svn (1:2.20.1+next.20181228-1) over (1:2.19.2-1) ...
Preparing to unpack .../03-git-mediawiki_1%3a2.20.1+next.20181228-1_all.deb ...
Unpacking git-mediawiki (1:2.20.1+next.20181228-1) over (1:2.19.2-1) ...
Preparing to unpack .../04-git-gui_1%3a2.20.1+next.20181228-1_all.deb ...
Unpacking git-gui (1:2.20.1+next.20181228-1) over (1:2.19.2-1) ...
Preparing to unpack .../05-git-email_1%3a2.20.1+next.20181228-1_all.deb ...
Unpacking git-email (1:2.20.1+next.20181228-1) over (1:2.19.2-1) ...
Preparing to unpack .../06-git_1%3a2.20.1+next.20181228-1_amd64.deb ...
Unpacking git (1:2.20.1+next.20181228-1) over (1:2.19.2-1) ...
Preparing to unpack .../07-git-man_1%3a2.20.1+next.20181228-1_all.deb ...
Unpacking git-man (1:2.20.1+next.20181228-1) over (1:2.19.2-1) ...
Preparing to unpack .../08-git-doc_1%3a2.20.1+next.20181228-1_all.deb ...
Unpacking git-doc (1:2.20.1+next.20181228-1) over (1:2.19.2-1) ...
Preparing to unpack .../09-libqt5help5_5.11.3-2_amd64.deb ...
Unpacking libqt5help5:amd64 (5.11.3-2) over (5.11.2-5) ...
Preparing to unpack .../10-libqt5multimediagsttools5-dbgsym_5.11.3-2_amd64.deb 
...
Unpacking libqt5multimediagsttools5-dbgsym:amd64 (5.11.3-2) over (5.11.2-2) ...
Preparing to unpack .../11-libqt5multimediagsttools5_5.11.3-2_amd64.deb ...
Unpacking libqt5multimediagsttools5:amd64 (5.11.3-2) over (5.11.2-2) ...
Preparing to unpack .../12-libqt5multimediaquick5_5.11.3-2_amd64.deb ...
Unpacking libqt5multimediaquick5:amd64 (5.11.3-2) over (5.11.2-2) ...
Preparing to unpack .../13-libqt5x11extras5-dbgsym_5.11.3-2_amd64.deb ...
Unpacking libqt5x11extras5-dbgsym:amd64 (5.11.3-2) over (5.11.2-2) ...
Preparing to unpack .../14-libqt5x11extras5_5.11.3-2_amd64.deb ...
Unpacking libqt5x11extras5:amd64 (5.11.3-2) over (5.11.2-2) ...
Preparing to unpack 
.../15-python3-dbus.mainloop.pyqt5-dbg_5.11.3+dfsg-1+b3_amd64.deb ...
Unpacking python3-dbus.mainloop.pyqt5-dbg (5.11.3+dfsg-1+b3) over 
(5.11.3+dfsg-1+b2) ...
Preparing to unpack 
.../16-python3-dbus.mainloop.pyqt5_5.11.3+dfsg-1+b3_amd64.deb ...
Unpacking python3-dbus.mainloop.pyqt5 (5.11.3+dfsg-1+b3) over 
(5.11.3+dfsg-1+b2) ...
Preparing to unpack .../17-qml-module-qtquick2_5.11.3-2_amd64.deb ...
Unpacking qml-module-qtquick2:amd64 (5.11.3-2) over (5.11.2-3) ...
Preparing to unpack .../18-qml-module-qtmultimedia_5.11.3-2_amd64.deb ...
Unpacking qml-module-qtmultimedia:amd64 (5.11.3-2) over (5.11.2-2) ...
Preparing to unpack .../19-qml-module-qtqml-models2_5.11.3-2_amd64.deb ...
Unpacking qml-module-qtqml-models2:amd64 (5.11.3-2) over (5.11.2-3) ...
Preparing to unpack .../20-qml-module-qtquick-window2_5.11.3-2_amd64.deb ...
Unpacking qml-module-qtquick-window2:amd64 (5.11.3-2) over (5.11.2-3) ...
Preparing to unpack .../21-roodi_5.0.0-2_all.deb ...
Unpacking roodi (5.0.0-2) over (5.0.0-1) ...
Setting up git-man (1:2.20.1+next.20181228-1) ...
Setting up qml-module-qtquick2:amd64 (5.11.3-2) ...

Bug#851189: keyboard-configuration: ALT+Cursor-Left switches consoles instead of working on app in focus

[Mike McGuire]

This started happening to me recently, not sure what change could be to blame 
but I found a lengthy thread on the ubuntu bug tracker that seems to confirm 
things. Copying the relevant post: 
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1508146/comments/66

---

In my case, I traced the issue to the keyboard-configuration package postinst 
script, which ends up calling 'setupcon --force --save' which in turn calls 
'kbd_mode -u'

To reproduce:
sudo apt install --reinstall keyboard-configuration

setupcon documentation states:
"--force Do not check whether we are on the console. Notice that you can be 
forced to hard-reboot your computer if you run setupcon with this option and 
the screen is controlled by a X server."

It looks like the checks to avoid this behavior while a graphic environment is 
active don't work in the context of the installer.

---

In any case they've found 'sudo kbd_mode -s' to be a workaround.

Bug#918323: unattended-upgrades: tried to upgrade package with conffile prompt

[Paul Wise]

Package: unattended-upgrades
Version: 1.9
Severity: serious

unattended-upgrades tried to upgrade a package (lvm2) with a conffile
prompt and failed because conffile prompts require user input. This
meant that the upgrade of lvm2 failed and was the system was left in a
partially broken state. Normally unattended-upgrades refuses to upgrade
packages that need conffile prompts, so this seems like a regression.

I've included the full log with debug info below:

Unattended upgrade result: All upgrades installed 

Warning: A reboot is required to complete this upgrade, or a previous one.

Packages that attempted to upgrade:
 antlr4 cppcheck dh-golang dmeventd dmsetup gir1.2-secret-1 
 gnome-shell-extension-suspend-button gnome-shell-extension-weather 
 hub kpartx libantlr4-runtime-java libcdr-0.1-1 
 libdevmapper-event1.02.1 libdevmapper1.02.1 
 libdevmapper1.02.1-dbgsym libetonyek-0.1-1 libqxp-0.0-0 
 libsecret-1-0 libsecret-1-0-dbgsym libsecret-common libsecret-tools 
 libwpd-0.10-10 lvm2 python-sqlalchemy 

Packages with upgradable origin but kept back:
 gimp gimp-data libgimp2.0 

Package installation log:
Log started: 2019-01-04  12:49:36
[master 31e4f0db] saving uncommitted changes in /etc prior to apt run
 1 file changed, 0 insertions(+), 0 deletions(-)
 rewrite debdelta/gnupg/random_seed (100%)
apt-listchanges: Reading changelogs...
apt-listchanges: Mailing root: apt-listchanges: changelogs for chianamo
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 460811 files and directories currently installed.)
Preparing to unpack .../libdevmapper1.02.1-dbgsym_2%3a1.02.155-1_amd64.deb ...
Unpacking libdevmapper1.02.1-dbgsym:amd64 (2:1.02.155-1) over (2:1.02.145-4.1) 
...
Preparing to unpack .../dmsetup_2%3a1.02.155-1_amd64.deb ...
Unpacking dmsetup (2:1.02.155-1) over (2:1.02.145-4.1) ...
Setting up dmsetup (2:1.02.155-1) ...
update-initramfs: deferring update (trigger activated)
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 460811 files and directories currently installed.)
Preparing to unpack .../libdevmapper1.02.1_2%3a1.02.155-1_amd64.deb ...
Unpacking libdevmapper1.02.1:amd64 (2:1.02.155-1) over (2:1.02.145-4.1) ...
Setting up libdevmapper1.02.1:amd64 (2:1.02.155-1) ...
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 460811 files and directories currently installed.)
Preparing to unpack .../00-antlr4_4.7.1-1_all.deb ...
Unpacking antlr4 (4.7.1-1) over (4.6-2) ...
Preparing to unpack .../01-libantlr4-runtime-java_4.7.1-1_all.deb ...
Unpacking libantlr4-runtime-java (4.7.1-1) over (4.6-2) ...
Preparing to unpack .../02-cppcheck_1.86-1_amd64.deb ...
Unpacking cppcheck (1.86-1) over (1.85-2) ...
Preparing to unpack .../03-dh-golang_1.39_all.deb ...
Unpacking dh-golang (1.39) over (1.38) ...
Preparing to unpack .../04-libdevmapper-event1.02.1_2%3a1.02.155-1_amd64.deb ...
Unpacking libdevmapper-event1.02.1:amd64 (2:1.02.155-1) over (2:1.02.145-4.1) 
...
Selecting previously unselected package liblvm2cmd2.03:amd64.
Preparing to unpack .../05-liblvm2cmd2.03_2.03.02-1_amd64.deb ...
Unpacking liblvm2cmd2.03:amd64 (2.03.02-1) ...
Preparing to unpack .../06-dmeventd_2%3a1.02.155-1_amd64.deb ...
Unpacking dmeventd (2:1.02.155-1) over (2:1.02.145-4.1) ...
Preparing to unpack .../07-libsecret-1-0-dbgsym_0.18.7-1_amd64.deb ...
Unpacking libsecret-1-0-dbgsym:amd64 (0.18.7-1) over (0.18.6-3) ...
Preparing to unpack .../08-libsecret-common_0.18.7-1_all.deb ...
Unpacking libsecret-common (0.18.7-1) over 

Bug#918322: More info

[Jakub Sokołowski]

Seems like I failed to add additional info:

Picture of error: 
https://mega.nz/#!LehDlKbB!x_pFGX3wlq-Kgo6v5jUC6ydbqTQ4R43bft7mAC6j_ms

This seems to be realted to initrd since when I ran update-initramfs on an 
older kernel that one started showing the same symptoms as the new one.

Bug#918246: dune-common: FTBFS for armhf on arm64, fails tests

[Steve McIntyre]

On Fri, Jan 04, 2019 at 08:37:24PM +0200, Graham Inggs wrote:
>This sounds like #918157.

Nod. I'm seeing similar behaviour in a few more packages since tihs
point, too. :-(

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Google-bait:   http://www.debian.org/CD/free-linux-cd
  Debian does NOT ship free CDs. Please do NOT contact the mailing
  lists asking us to send them to you.

Bug#917850: Fwd: Server Error (500) on nm.d.o

[eamanu15]

Hi,

El vie., 4 de ene. de 2019 a la(s) 17:17, Jonathan McDowell (
nood...@earth.li) escribió:

> On Fri, Jan 04, 2019 at 09:56:10AM -0300, eamanu15 wrote:
> > El lun., 31 de dic. de 2018 a la(s) 05:02, Jonathan McDowell (
> > nood...@earth.li) escribió:
> > > On Sun, Dec 30, 2018 at 11:29:33PM -0300, eamanu15 wrote:
> > > > I joined to NM and in my personal web I have on *pending *the next
> line:
> > > > "This is a new entry that requires confirmation before Jan. 2, 2019.
> > > > Click here to send the email challenge again."
> > > >
> > > > I don't receive the email. And when I click on "here" link this give
> me a
> > > > Server Error (500).
> > > >
> > > > What would be the problem?
> > >
> > > Your GPG key has expired, so the system can't encrypt the challenge to
> > > you. You need to update your key (and we need to fix the system so it
> > > prints a proper error message in that case).
> > >
> > I am trying to update my keyring using: *gpg --keyserver
> > keyring.debian.org  --send-keys ...* But I
> > don't see the change. On Debian wiki say that this could take some
> > time, because the keyring push is monthly. Do you know approx when it
> > occur? Or, there are other way to update the key?
>
> keyring.debian.org is only for keys that are already part of the Debian
> keyring, not for new applicants. Your key will be accepted and silently
> discarded there. You should send your updated key to the keyserver
> network (nm.debian.org is currently using keys.gnupg.net I believe,
> which is a pointer to the SKS keyserver network).
>

Hmmm I've just upload my keyring to keys.gnupg.net. 
Currently If I run --recv-key this is ok. But on nm.debian.org
still give me the same error :(

>
> J.
>
> --
> 101 things you can't have too much of : 17 - Money.
>


-- 
Arias Emmanuel
http://eamanu.com
Github/Gitlab; @eamanu
Debian: @eamanu-guest

Bug#918088: Acknowledgement (autofs-ldap: automount dies with SIGABRT after libkrb5-3 upgrade - "(k5_mutex_lock: Assertion `r == 0' failed.)")

[Sam Hartman]

> "Adrian" == Adrian Bunk  writes:

latest upgrade of libkrb5-3 (1.16.1-1 -> 1.16.2-1)
>> automount starts but dies immediately after accessing a
>> automounter point.
>> 
>> Automount is configured to authenticate via GSSAPI using system
>> keytab.  After the GSSAPI authentication succeeded, any access to
>> a configure automount entry causes automount to die with an
>> assertion failure (followed by an abort()):

Adrian> Thanks for your report.

Adrian> I'm moving this bug report to libkrb5-3 since this is the
Adrian> change that triggered your regression for assessment whether
Adrian> the bug is there.

Adrian, I'm guessing you're looking at this with your QA hat on?
How well do you understand autofs?  Any chance you could help put
together a repo?  If you don't know autofs-ldap well, I can learn it
just as well as anyone, but if you do happen to know it well, help would
be appreciated.
In the latest krb5 package, the debian/tests directory contains a
slapd-gssapi test which happens to set up LDAP well enough that you can
SASL authenticate it.
So, my guess is that adapting that test to  set up an autofs-ldap that
uses gss auth to ldap probably isn't too incredibly hard.
I don't know autofs at all, and for example I don't know how to set up
the directory to have the right info.

If you or the submitter can easily help, it would be appreciated.
If not, I'll look into it.

--Sam

Bug#917782: [gimp] Missing symbol

[Paolo Redaelli]

First of all sorry for the late answer, Google tought your answer were
spam. :(

Il 30/12/18 15:51, Simon McVittie ha scritto:
> Control: tags -1 + moreinfo
>
> On Sun, 30 Dec 2018 at 11:45:12 +0100, Paolo Redaelli wrote:
>> gimp: symbol lookup error: /usr/lib/x86_64-linux-gnu/libgegl-0.4.so.0:
>> undefined symbol: babl_format_with_space
> Do you have a version of libbabl-0.1-0 installed from some apt
> source outside Debian, for instance deb-multimedia.org, or a copy of
> libbabl-0.1.so.0 in a non-dpkg-managed directory like /usr/local/lib?
>
> We have had recurring problems with deb-multimedia.org providing its own
> libbabl-0.1-0 and libgegl-0.4-0 packages, which are marked with higher
> version numbers than any official Debian version, causing them to satisfy
> versioned dependencies even when they should not.

Indeed you're right. After I removed the libbabl-0.10 which came from
deb-multimedia the issue was solved.

That's taught me to stick to Debian repositories and not tainting a
system: I removed deb-multimedia from my sources long ago, I thought its
effects were "faded"

>> libbabl-0.1-0 (>= 0.1.10) |
>> libgegl-0.4-0 (>= 0.4.12) |
> Either you do not have libbabl and libgegl installed, or (probably
> more likely) whatever software you were using to report this bug
> is not reporting installed packages correctly. 
I used reportbug-ng
> Please report bugs
> using the reportbug(1) tool from the reportbug package whenever
> possible.  The reportbug-ng package is not recommended, due to
>  (it is also no longer maintained).

I wasn't aware of its status. I'll stick to plain reportbug


> You can provide the same information that reportbug would have done
> by running "reportbug --template gimp" and pasting its output into an
> email to the bug address.

Thanks. Sorry for the lame bug.

Bug#918321: postbooks: Segfault after connecting to DB and OKing the too-new PGSQL warning

[Sean M. Pappalardo]

Package: postbooks
Version: 4.11.3-1~bpo9+1
Severity: important

Dear Maintainer,

I just tried upgrading from the version of Postbooks in Stretch to the one in 
Stretch-Backports (4.11.3-1) and the backports version hits a segmentation 
fault after I log in to the database and click to proceed despite the DB engine 
being too new (9.6.11.) This worked fine in v4.10.0-2. The DB itself is on 
version 4.9.5.

Sincerely,
Sean M. Pappalardo


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

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

Versions of packages postbooks depends on:
ii  libc6  2.24-11+deb9u3
ii  libdmtx0a  0.7.4-2
ii  libgcc11:6.3.0-18+deb9u1
ii  libgl1-mesa-glx [libgl1]   13.0.6-1+b2
ii  libopenrpt1v5  3.3.12-2
ii  libqt5core5a   5.7.1+dfsg-3+b1
ii  libqt5designer55.7.1-1
ii  libqt5designercomponents5  5.7.1-1
ii  libqt5gui5 5.7.1+dfsg-3+b1
ii  libqt5network5 5.7.1+dfsg-3+b1
ii  libqt5printsupport55.7.1+dfsg-3+b1
ii  libqt5qml5 5.7.1-2+b2
ii  libqt5quick5   5.7.1-2+b2
ii  libqt5script5  5.7.1~20161021+dfsg-2
ii  libqt5scripttools5 5.7.1~20161021+dfsg-2
ii  libqt5serialport5  5.7.1~20161021-2
ii  libqt5sql5 5.7.1+dfsg-3+b1
ii  libqt5sql5-psql5.7.1+dfsg-3+b1
ii  libqt5webchannel5  5.7.1-2
ii  libqt5webkit5  5.7.1+dfsg-1
ii  libqt5websockets5  5.7.1~20161021-4
ii  libqt5widgets5 5.7.1+dfsg-3+b1
ii  libqt5xml5 5.7.1+dfsg-3+b1
ii  libqt5xmlpatterns5 5.7.1~20161021-3
ii  libstdc++6 6.3.0-18+deb9u1
ii  libxtuplecommon1   4.10.0-2
ii  zlib1g 1:1.2.8.dfsg-5

postbooks recommends no packages.

Versions of packages postbooks suggests:
pn  postbooks-schema-demo
pn  postbooks-schema-empty   
pn  postbooks-schema-quickstart  
pn  postbooks-updater

-- no debconf information

Bug#881460: apparmor-profiles: dhclient set to enforce prevents getting an IPv4 with DHCP

[Lorenzo Ancora]

Package: apparmor-profiles
Version: 2.13.1-3
Followup-For: Bug #881460

I've created a patch to resolve this bug. After applying the patch you should
link/copy the profile to /etc/apparmor.d, enforce the profile again (the kernel
ring buffer will show a STATUS message) and restart NetworkManager.
--- /usr/share/apparmor/extra-profiles/sbin.dhclient2019-01-05 
01:06:40.237744708 +0100
+++ /usr/share/apparmor/extra-profiles/sbin.dhclient2019-01-05 
01:14:07.325115590 +0100
@@ -51,6 +51,7 @@
   /usr/bin/vmstat mrix,
   /usr/bin/w  mrix,
   /usr/lib/nm-dhcp-helper rix,
+  /usr/lib/NetworkManager/nm-dhcp-helper rix,
   /var/lib/dhcp/dhclient.leases rw,
   /var/lib/dhcp/dhclient-*.leases   rw,
   /var/lib/dhcp6/dhclient.leasesrw,

Bug#918101: cfengine3: Please package new LTS release (3.12) before Buster freezes

[Antonio Radici]

On Thu, Jan 03, 2019 at 11:16:46AM +0100, Moritz Schlarb wrote:
> Source: cfengine3
> Severity: wishlist
> 
> Dear Maintainer,
> 
> please consider packaging the latest LTS release (3.12.1) before the Buster
> freezes begin.
> 
> IMHO this makes sense if you look at the upstream support timeline at
> https://cfengine.com/product/supported-versions/ - support for 3.10 will stop
> just after Buster is actually released, whereas 3.12 will overlap more with 
> the
> Buster support timeline.
> 
> Christoph and I are happy to help with the package maintanance.

Thanks a lot for letting me know, I will do it in the next few days, hopefully
between today and tomorrow (I just need a reliable connection).

Bug#917727: openhft-lang: FTBFS: [ERROR] /<>/lang/src/main/java/net/openhft/lang/io/IOTools.java:[85, 13] cannot find symbol

[tony mancill]

On Wed, Jan 02, 2019 at 01:05:40PM +0100, Emmanuel Bourg wrote:
> Le 30/12/2018 à 17:29, tony mancill a écrit :
> 
> > Given that there aren't many (or any?) r-deps for the openhft libraries,
> > I'm tempted to pull the versions in experimental into unstable so we
> > have the libraries in buster.  It's either that, or not include these
> > packages in buster at all.
> > 
> > Thoughts?
> 
> The OpenHFT libraries are used by Spring (libspring-java), and if I
> remember well I had to pick very specific versions to have a consistent
> set of compatible libraries. I plan to upgrade Spring to the version 5.1
> before the freeze, I'll see at this moment what versions of the OpenHFT
> libraries are required.

Ah, I don't want to break libspring-java, so I'll wait to hear from you.
Let me know if there are bits I can help with.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#881460: apparmor-profiles: dhclient set to enforce prevents getting an IPv4 with DHCP

[Lorenzo Ancora]

Package: apparmor-profiles
Version: 2.13.1-3
Followup-For: Bug #881460

I've created a patch to resolve this bug. After applying the patch you should
link/copy the profile to /etc/apparmor.d, enforce the profile again (the kernel
ring buffer will show a STATUS message) and restart NetworkManager.
--- /usr/share/apparmor/extra-profiles/sbin.dhclient2019-01-05 
01:06:40.237744708 +0100
+++ /usr/share/apparmor/extra-profiles/sbin.dhclient2019-01-05 
01:14:07.325115590 +0100
@@ -51,6 +51,7 @@
   /usr/bin/vmstat mrix,
   /usr/bin/w  mrix,
   /usr/lib/nm-dhcp-helper rix,
+  /usr/lib/NetworkManager/nm-dhcp-helper rix,
   /var/lib/dhcp/dhclient.leases rw,
   /var/lib/dhcp/dhclient-*.leases   rw,
   /var/lib/dhcp6/dhclient.leasesrw,

Bug#832355: ktap: module FTBFS for Linux 4.6: error: '__GFP_WAIT' undeclared

[Azat Khuzhin]

> But it looks like ktap is dead upstream now, so perhaps we should just
> remove it from the archive instead?

Sadly, but yes.
So agree, should be just removed from the archive.

Regards,
Azat.

Bug#918320: openvswitch-switch: ifupdown integration can't work (obsolete/buggy scripts)

[Jose Luis Tallon]

Package: openvswitch-switch
Version: 2.10.0+2018.08.28+git.8ca7c82b7d+ds1-10
Severity: important
Tags: patch

Dear Maintainer,

Just configured openvswitch 2.10 on a newly-upgraded Buster machine 
(fresh install with Stretch/9.6, immediately dist-upgraded to Buster). 
When raising the interfaces via ifup, configuration of OpenVSwitch-enabled

interfaces would always failed.

* Command run: # ifup xenbr0
* Outcome: xenbr0 not configured (error)
* Expected outcome: xenbr0 + eno1 enabled and configured

Part of the problem lies in the fact that the supplied ifupdown
integration scripts are outdated: they call 'ifconfig' rather than the
correct "ip link set up" invocation. Trivial patch attached.


Probably unrelated, configuration will still fail... but that's another 
matter


-- /etc/network/interfaces (snippet) ---
auto lo
iface lo inet loopback

auto eno1
allow-hotplug eno1
iface eno1 inet manual
up ip link set up dev eno1
down ip link set down dev eno1
ovs_type OVSPort
ovs_bridge xenbr0

source /etc/network/interfaces.d/*

-- /etc/network/interfaces.d/xenbr0
auto xenbr0
allow-ovs xenbr0
iface xenbr0 inet static
address 172.20.1.54/24
mtu 1500
ovs_type OVSBridge
ovs_ports eno1
dns-nameservers 172.20.0.254
--


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

Kernel: Linux 4.19.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)

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

Versions of packages openvswitch-switch depends on:
ii kmod 25-2
ii lsb-base 10.2018112800
ii netbase 5.5
ii openvswitch-common 2.10.0+2018.08.28+git.8ca7c82b7d+ds1-10
ii procps 2:3.3.15-2
ii python 2.7.15-3
ii uuid-runtime 2.33-0.2

openvswitch-switch recommends no packages.

openvswitch-switch suggests no packages.

-- no debconf information


--- /etc/network/if-pre-up.d/openvswitch~   2018-12-14 08:47:15.0 
+0100
+++ /etc/network/if-pre-up.d/openvswitch2019-01-03 15:20:50.911578187 
+0100
@@ -25,6 +25,10 @@
 ovs-vsctl --timeout=5 "$@"
 }
 
+if_up() {
+/bin/ip link set up dev "$1"
+}
+
 if (ovs_vsctl --version) > /dev/null 2>&1; then :; else
 exit 0
 fi
@@ -57,24 +61,24 @@
 "${IFACE}" ${IF_OVS_OPTIONS} \
 ${OVS_EXTRA+-- $OVS_EXTRA}
 
-ifconfig "${IFACE}" up
+if_up "${IFACE}"
 ;;
 OVSIntPort)
 ovs_vsctl -- --may-exist add-port "${IF_OVS_BRIDGE}"\
 "${IFACE}" ${IF_OVS_OPTIONS} -- set Interface "${IFACE}"\
 type=internal ${OVS_EXTRA+-- $OVS_EXTRA}
 
-ifconfig "${IFACE}" up
+if_up "${IFACE}"
 ;;
 OVSBond)
 ovs_vsctl -- --fake-iface add-bond "${IF_OVS_BRIDGE}"\
 "${IFACE}" ${IF_OVS_BONDS} ${IF_OVS_OPTIONS} \
 ${OVS_EXTRA+-- $OVS_EXTRA}
 
-ifconfig "${IFACE}" up
+if_up "${IFACE}"
 for slave in ${IF_OVS_BONDS}
 do
-ifconfig "${slave}" up
+if_up "${slave}"
 done
 ;;
 OVSPatchPort)

Bug#918088: Acknowledgement (autofs-ldap: automount dies with SIGABRT after libkrb5-3 upgrade - "(k5_mutex_lock: Assertion `r == 0' failed.)")

[Greg Hudson]

On Fri, 04 Jan 2019 15:54:01 -0500 Sam Hartman  wrote:
> There are no thread support changes between 1.16.1 and 1.16.2.
> There is one ccache related change which I'll include below related to
> memory ccaches.
> Do you know what type of credential cache  is being used here?

krb5_mcc_start_seq_get() is in the traceback, so the memory cache change
is a clear candidate for the bug.  I can't find anything wrong with the
code, though.  From the stack trace, there appears to be a memory ccache
on the list with an invalid mutex, but I don't see any way of getting
into that state.

Bug#911399: Using --append-to-version without --make-binNMU may lead to broken packages

[Johannes Schauer]

Hi Marga,

On Fri, 19 Oct 2018 19:08:45 +0200 Marga Manterola  wrote:
> sbuild includes a handy --append-to-version parameter.  This is what the
> current manpage says:
> 
>--append-to-version=string
>   This  option  is similar to --make-binNMU except that it
> allows the user to specify an arbitrary string to be appended to the
> version number  (immediately  before  the '+'  in  the  Debian revision if
> --make-binNMU is also provided).  To pass an arbitrary changelog text as
> well, combine this option with --make-binNMU but  be  aware that  this
> will also add the +bn suffix unless you also pass --binNMU=0 to disable
> it.  This option is incompatible with --binNMU-changelog.  This command
> line option sets  the  APPEND_TO_VERSION  configuration  variable.  See
> sbuild.conf(5) for more information.
> 
> It's notable that this entry does not say that --append-to-version implies
> --no-arch-all (which the --make-binNMU entry does say).  And in fact it
> doesn't, arch all packages are built with the suffix appended to their
> versions.  However, the dpkg version that is modified when using
> --append-to-version is the binary version, not the source version.  This
> means that if the control file has a (= ${source:Version}) it will be
> replaced by the unmodified one, while still building arch all packages
> unless --no-arch-all is specified.
> 
> This leads to brokeness because packages will depend on versions that have
> been replaced and thus not available. I believe this is a bug.  Either
> --append-to-version should modify the source version as well as the binary
> version (when used without the --make-binNMU flag); or it should imply
> --no-arch-all.
> 
> I'd like to use --append-to-version for full rebuilds, so I'd rather you
> chose the first option, but if you choose the second one, maybe you could
> provide another flag to allow to change the source version as well?

what is your use-case here? Why do you need the source version modified by
sbuild instead of just editing debian/changelog yourself and then handing the
result to sbuild?

I don't think it would be right for sbuild to change the source version for
several reasons:

 - the --append-to-version option has long been documented as "just like
   --make-binNMU but with arbitrary version suffix". If the source version were
   changed, then this would be an incompatible change of behaviour

 - the source is the *input* to sbuild. Sbuild is not supposed to output or
   modify the source. That sbuild allows changing debian/changelog is a hack
   and an exception.

 - since --append-to-version is analogous to --make-binNMU, it makes sense for
   both of them to imply --no-arch-all.

I'm inclined to just let --append-to-version imply --no-arch-all. If you
disagree with that solution, please give me some more compelling arguments.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#918319: myspell-et: please provide a symlink from /usr/share/hyphen/hyph_et.dic to hyph_et_EE.dic

[Daniel Kahn Gillmor]

Package: myspell-et
Version: 1:20030606-29
Severity: wishlist

as seen in #918318 and #918305, we're trying to get language-generic
symlinks added to hyphenation packages for the purposes of getting
pyphen packaged without shipping duplicate hyphenation dictionaries.

To acheive this, myspell-et should provide a symlink from
/usr/share/hyphen/hyph_et.dic to hyph_et_EE.dic.

Regards,

--dkg

Bug#918305: hyphen-en-us: please provide fallback symlink from hyph_en.dic to hyph_en_US.dic

[Daniel Kahn Gillmor]

On Fri 2019-01-04 17:47:20 -0500, Daniel Kahn Gillmor wrote:
> Control: tags 918305 + patch

attached is a revised patch, which includes a en_Latn_US.dic symlink.

the merge request has already been updated.

regards,

 --dkg

>From f8f0902e757b65b2bfcc6e2e3faaa844e9c00780 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Fri, 4 Jan 2019 17:00:29 -0500
Subject: [PATCH 2/9] hyphen-en-us: provide fallback symlink for hyph_en.dic
 (Closes: #918305)

---
 debian/control| 1 +
 debian/hyphen-en-us.links | 2 ++
 2 files changed, 3 insertions(+)
 create mode 100644 debian/hyphen-en-us.links

diff --git a/debian/control b/debian/control
index 5aada4d..9102201 100644
--- a/debian/control
+++ b/debian/control
@@ -61,6 +61,7 @@ Suggests:
  libreoffice-writer,
 Provides:
  hyphen-hyphenation-patterns,
+ hyphen-hyphenation-patterns-en,
  hyphen-hyphenation-patterns-en-us,
 Description: English (US) hyphenation patterns
  This package contains the English (US) hyphenation patterns.
diff --git a/debian/hyphen-en-us.links b/debian/hyphen-en-us.links
new file mode 100644
index 000..0e82070
--- /dev/null
+++ b/debian/hyphen-en-us.links
@@ -0,0 +1,2 @@
+usr/share/hyphen/hyph_en_US.dic usr/share/hyphen/hyph_en.dic
+usr/share/hyphen/hyph_en_US.dic usr/share/hyphen/hyph_en_Latn_US.dic
-- 
2.20.1

Bug#918318: libreoffice-dictionaries s

[Daniel Kahn Gillmor]

Package: src:libreoffice-dictionaries
Version: 6.1.3-1

In the course of looking into pyphen packaging with Scott Kitterman, i
noticed that it expects symlinks from hyphenation files like hyph_af.dic
to hyph_af_ZA.dic.  I filed https://bugs.debian.org/918305 against
hyphen-en-us for that package.

In this case, i am asking for the same kind of symlink arrangement for
the following hyphenation dictionaries in the parenthesized binary
packages:

af → af_ZA (hyphen-af)
bg → bg_BG (hyphen-bg)
cs → cs_CZ (hyphen-cs)
da → da_DK (hyphen-da)
de → de_DE (hyphen-de)
el → el_GR (hyphen-el)
en_Latn_GB → en_GB (hyphen-en-gb)
hr → hr_HR (hyphen-hr)
hu → hu_HU (hyphen-hu)
it → it_IT (hyphen-it)
lt → lt_LT (hyphen-lt)
lv → lv_LV (hyphen-lv)
nl → nl_NL (hyphen-nl)
pl → pl_PL (hyphen-pl)
pt → pt_PT (hyphen-pt-pt)
pt_Latn_BR → pt_BR (hyphen-pt-br)
pt_Latn_PT → pt_PT (hyphen-pt-pt)
ro → ro_RO (hyphen-ro)
ru → ru_RU (hyphen-ru)
sk → sk_SK (hyphen-sk)
sl → sl_SI (hyphen-sl)
te → te_IN (hyphen-te)
uk → uk_UA (hyphen-uk)
zu → zu_ZA (hyphen-zu)

let me know if there are any problems with this!

--dkg


signature.asc
Description: PGP signature

Bug#918316: nocache: FTBFS in sid

[Santiago Vila]

tags 918316 + patch
thanks

The patch below works for me:

--- a/debian/rules
+++ b/debian/rules
@@ -18,5 +18,5 @@ override_dh_auto_test:
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
 #  -NOCACHE_NR_FADVISE=2 dh_auto_test -v
## #916415
-   timeout 11 ./nocache apt show coreutils 1>>/dev/null
+   timeout 60 ./nocache apt show coreutils 1>>/dev/null
 endif


Note: I don't quite understand the purpose of the timeout. Is it
really useful/required to set a timeout at all? Normally sbuild (the
autobuilder program used by the build daemons) has already a built-in
timeout mechanism which prevents the autobuilder to be stuck forever,
and by looking at build logs from reproducible builds, I believe
pbuilder has also a timeout by default.

Thanks.

Bug#918317: ITP: ruby-selenium-webdriver -- Browser automation framework and ecosystem

[Utkarsh Gupta]

Package: wnpp
Severity: wishlist
Owner: Utkarsh Gupta 

* Package name  : ruby-selenium-webdriver
   Version  : 3.141.0
   Upstream Author  : Selenium HQ
* URL   : https://github.com/SeleniumHQ/selenium
* License   : Apache-2.0
   Programming Lang : Ruby
   Description  : Browser automation framework and ecosystem

Selenium is an umbrella project encapsulating a variety of tools and
libraries enabling web browser automation. Selenium specifically provides
infrastructure for the W3C WebDriver specification — a platform and
language-neutral coding interface compatible with all major web browsers.
.
Selenium uses a custom build system, aptly named crazyfun available on all
fine platforms (Linux, Mac, Windows).

This is an unpackaged gem for diaspora and hence needs to be packaged.

Thanks,
Utkarsh Gupta

Bug#894285: android-framework-23 FTBFS with openjdk-9

[Markus Koschany]

I had a go at this and it looks like the package simply is not ready for
Java 9+. The unmappable character error is bogus. Rather issues like
using an underscore character as a variable name (which is forbidden in
Java 9) or naming a package java.lang ... are the root cause of the FTBFS.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#918251: d-shlibs: devlibs error: There is no package matching [libsvm3-dev] and noone provides it

[Andreas Tille]

Hi Michael,

On Fri, Jan 04, 2019 at 11:10:42AM -0800, Michael R. Crusoe wrote:
> Package: d-shlibs
> Version: 0.83
> Severity: normal
> 
> Dear Maintainer,
> 
> While fixing the missing linkage to libsvm in libpsortb I received the
> following message:
> 
> devlibs error: There is no package matching [libsvm3-dev] and noone provides
> it, please report bug to d-shlibs maintainer
> 
> So here I am :-)
> 
> d-shlibmove --commit \
> --multiarch \
> --devunversioned \
> --exclude-la \
> debian/tmp/usr/lib/*/libsvmloc.so
> Library package automatic movement utility
> devlibs error: There is no package matching [libsvm3-dev] and noone provides 
> it, please report bug to d-shlibs maintainer 

I can not really reproduce this but you do not need until this
bug is fixed in d-shlibs.  You can easily add

--override s/libsvm3-dev/libsvm-dev/ \

which should do the trick.  (If not let me know how I can
reproduce the issue.)

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#907624: What ffindex do we want to package

[Steffen Möller]

Heya, I have replied, at least I had typed it :o/

So, yes, I had chosen that version of ffsort_index to get hhsuite to 
compile. I have no idea if there are other reverse dependencies on 
ffindex, my priority is on hhsuite.


Cheers,

Steffen

On 04.01.19 18:17, Michael Crusoe wrote:
I think 0.9.9.7+sog+git20160415.14274c9-1 is the source of the recent 
FTBFS of hhsuite: https://bugs.debian.org/917495 as our packaged 
version is missing the "ffsort_index" function.


The hh-suite github repo contains a submodule pointing at their fork 
of ffindex at ~ 2017-06-01:
https://github.com/soedinglab/hh-suite/tree/v3.0-beta.3/lib → 
https://github.com/soedinglab/ffindex_soedinglab/tree/360e4176ece531be34a94298c808349916d016ac


I suggest that we package it as part of hhsuite until another package 
needs it.


hhsuite does provide  "*-Source*" packages that include ffindex, so we 
wouldn't need a multi-source build.




În joi, 20 dec. 2018 la 11:59, Andreas Tille > a scris:


Ping?
Steffen, if you did not had a specific reason I assume it was by
mistake and will replace the Segfaulting code by the original one.
If I do not hear from you I assume you will agree.
Kind regards, Andreas.

On Wed, Dec 19, 2018 at 09:53:38AM +0100, Andreas Tille wrote:
> Hi,
>
> after reading
https://github.com/soedinglab/ffindex_soedinglab/issues/4
> I came to the conclusion that we somehow picked the wrong fork of
> ffindex.  For me it seems very probable that if we pick the old
codebase
> bug #907624 which was introduced when choosing this will vanish
if we
> revert to the previously packaged code base.  I have a local commit
> which is doing this:
>
>
> diff --git a/debian/changelog b/debian/changelog
> index 6a26115..c409f4f 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,12 @@
> +ffindex (0.9.9.7+sog+git20160415.14274c9-1) UNRELEASED;
urgency=medium
> +
> +  * The previous location on Github was an improperly choosen fork
> +    (see https://github.com/soedinglab/ffindex_soedinglab/issues/4)
> +    Here the version is now named "0.9.9.7+sog" (Saved On Github)
> +    to make it alphabethically later than the previous one.
> +
> + -- Andreas Tille mailto:ti...@debian.org>>
Wed, 19 Dec 2018 09:16:09 +0100
> +
>  ffindex (0.9.9.7+soedinglab+git20180802.74550c8-1) unstable;
urgency=medium
>
>    * Fix watch file (version should actually be
+git20171201.74550c8 but
> diff --git a/debian/watch b/debian/watch
> index 91b4f38..b47f123 100644
> --- a/debian/watch
> +++ b/debian/watch
> @@ -1,4 +1,4 @@
>  version=4
>
> -opts="mode=git,pretty=0.9.9.7+soedinglab+git%cd.%h" \
> - https://github.com/soedinglab/ffindex_soedinglab.git HEAD
> +opts="mode=git,pretty=0.9.9.7+sog+git%cd.%h" \
> + https://github.com/ahcm/ffindex.git HEAD
>
>
>
> Upstream at github.com/ahcm/ffindex
 was extremely quick to tag a
> release and so it is at least active.
>
> Steffen, was your pick intentional or did you just stumbled by
chance
> over the other fork?  Are you OK with reverting to the old code?
>
> Kind regards
>
>       Andreas.
>
> PS: I reported the segfault issue to the according fork anyway
> https://github.com/soedinglab/ffindex_soedinglab/issues/7
>
>
> --
> http://fam-tille.de
>
>

-- 
http://fam-tille.de




--
Michael R. Crusoe
Co-founder & Lead, Common Workflow Language project 


Direktorius, VšĮ "Darbo eigos", Vilnius, Lithuania
https://orcid.org/-0002-2961-9670 


m...@commonwl.org 
+1 480 627 9108 / +370 653 11125

Bug#917468: Please add 'stappers' to PAPT

[Geert Stappers]

On Sat, Jan 05, 2019 at 12:58:49AM +0300, Dmitry Shachnev wrote:
> Hi Geert!

Hi Dmitry,
Hi Python list,
Hi Bugreport 917468,


> On Fri, Jan 04, 2019 at 10:16:20PM +0100, Geert Stappers wrote:
> > Hello,
> >
> > Here Debian Developer 'stappers'.
> >
> > I'm working on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917468
> > which is about fixing the VCS field of the Python package 'pelican'
> >
> > I would like to create 
> > https://salsa.debian.org/python-team/applications/pelican
> > or would like to have that git repo created and have write privilege to it.
> 
> FWIW, that repo already exists.

What a nice surprise

 
> And reading bug #917468 log, you were trying to migrate SVN to Git yourself,
> which is not needed since all PAPT repos were migrated automatically.
> 
> (Of course your request to join the team is still valid.)
> 

Yes, I would like to join the team.



Groeten
Geert Stappers
-- 
Leven en laten leven


signature.asc
Description: PGP signature

Bug#918301: libgdk-pixbuf2.0-dev: pkg-config reports version 2.10.14 when installed version is 2.36.5-2+deb9u2

[Ryan Richter]

On Fri, Jan 04, 2019 at 04:49:30PM -0500, Jeremy Bicha wrote:
> On Fri, Jan 4, 2019 at 4:33 PM  wrote:
> > pkg-config gtk+-3.0 --libs
> >
> > I get
> >
> > Package 'gdk-3.0' requires 'gdk-pixbuf-2.0 >= 2.30.0' but version of 
> > gdk-pixbuf-2.0 is 2.10.14
> >
> > In fact version 2.36.5-2+deb9u2 is installed.  The culprit seems to be 
> > /usr/lib/x86_64-linux-gnu/pkgconfig/gdk-pixbuf-2.0.pc which is part of this 
> > package.
> 
> Sorry, I can't reproduce this issue on Debian 9 "Stretch" with the
> test case you provided. If I could, I think it would be a serious bug
> that would break a lot of packages.
> 
> Please check if you have an older library installed to something like
> /usr/local/lib/

Yes, there was.  That's all it takes to throw off pkg-config?

Nevermind.

-ryan

Bug#918316: nocache: FTBFS in sid

[Santiago Vila]

Package: src:nocache
Version: 1.1-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in sid but it failed:


[...]
 debian/rules build-arch
dh build-arch
   dh_update_autotools_config -a
   dh_autoreconf -a
   dh_auto_configure -a
   dh_auto_build -a
make -j1 "INSTALL=install --strip-program=true"
make[1]: Entering directory '/<>'
cc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 
-Wl,-z,relro -Wl,-z,now -o cachedel cachedel.c
cc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 
-Wl,-z,relro -Wl,-z,now -o cachestats cachestats.c
cc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 
-Wl,-z,relro -Wl,-z,now -fPIC -c -o nocache.o nocache.c
cc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 
-Wl,-z,relro -Wl,-z,now -fPIC -c -o fcntl_helpers.o fcntl_helpers.c
cc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 
-Wl,-z,relro -Wl,-z,now -fPIC -c -o pageinfo.o pageinfo.c
cc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 
-Wl,-z,relro -Wl,-z,now -pthread -shared -Wl,-soname,nocache.so -o nocache.so 
nocache.o fcntl_helpers.o pageinfo.o -ldl
sed 's!##libdir##!$(dirname "$0")!' nocache
chmod a+x nocache
make[1]: Leaving directory '/<>'
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
## #916415
timeout 11 ./nocache apt show coreutils 1>>/dev/null

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

make[1]: *** [debian/rules:21: override_dh_auto_test] Error 124
make[1]: Leaving directory '/<>'
make: *** [debian/rules:10: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2


To be sure, I have tried to build the package 151 times on 8 different machines
and it failed 151 times. Here are the full build logs:

https://people.debian.org/~sanvila/build-logs/nocache/

A very similar failure happened here in mipsel, a release architecture:

https://buildd.debian.org/status/fetch.php?pkg=nocache=mipsel=1.1-1=1546582253=0

If you need help to reproduce this, please say so, I would gladly offer access 
to a system
where this seems to happen all the time.

Thanks.

Bug#918315: hyphen should import upstream changes that are lingering in git

[Daniel Kahn Gillmor]

Package: src:hyphen
Version: 2.8.8-5
Severity: wishlist

the hyphen package hasn't had a release in several years.

however, there are several useful-looking changes (including cleanup in
the build scripts) in git (upstream uses
https://github.com/hunspell/hyphen for hosting, afaict).

It might be good to import some of those changes.  at the least, it
would remove some autoconf warnings that we see otherwise.

  --dkg

Bug#918305: hyphen-en-us: please provide fallback symlink from hyph_en.dic to hyph_en_US.dic

[Daniel Kahn Gillmor]

Control: tags 918305 + patch

I've just submitted
https://salsa.debian.org/libreoffice-team/hyphen/merge_requests/1, which
includes the fix attached here for #918305.

Thanks for maintaining the hyphen package!

   --dkg

From 62aeebfc6a75d6b11abbd319ff22f8dc17af78a3 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Fri, 4 Jan 2019 17:00:29 -0500
Subject: [PATCH 2/7] hyphen-en-us: provide fallback symlink for hyph_en.dic
 (Closes: #918305)

---
 debian/control| 1 +
 debian/hyphen-en-us.links | 1 +
 2 files changed, 2 insertions(+)
 create mode 100644 debian/hyphen-en-us.links

diff --git a/debian/control b/debian/control
index 5aada4d..9102201 100644
--- a/debian/control
+++ b/debian/control
@@ -61,6 +61,7 @@ Suggests:
  libreoffice-writer,
 Provides:
  hyphen-hyphenation-patterns,
+ hyphen-hyphenation-patterns-en,
  hyphen-hyphenation-patterns-en-us,
 Description: English (US) hyphenation patterns
  This package contains the English (US) hyphenation patterns.
diff --git a/debian/hyphen-en-us.links b/debian/hyphen-en-us.links
new file mode 100644
index 000..358b6b6
--- /dev/null
+++ b/debian/hyphen-en-us.links
@@ -0,0 +1 @@
+usr/share/hyphen/hyph_en_US.dic usr/share/hyphen/hyph_en.dic
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#918190: systemd: timesyncd stopped updating clock file after package update

[Michael Biebl]

Am 04.01.19 um 21:49 schrieb Patrick Häcker:

> I think the state to see the problem is quite reproducible: First install 
> systemd 239 and afterwards install systemd 240, i.e. I can recreate whatever 
> state you need.

It is indeed reproducible easily, which is why I raised this upstream
https://github.com/systemd/systemd/issues/11329

Other distros are affected by this as well, and even if upstream decides
this is something to clean up by the distros, other distro maintainers,
who usually follow the github bug tracker, will be notified this way.

I'll wait a couple of days and in case there is no response, I'll add
the cleanup routine to the maintainer scripts.

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



signature.asc
Description: OpenPGP digital signature

Bug#918314: gmp: please add NEON-optimized variant for armhf

[Yuriy M. Kaminskiy]

Source: gmp
Version: 2:6.1.2+dfsg-1
Severity: wishlist
Tags: patch

Dear Maintainer,

As --enable-fat works only on i386^1, on armhf neon-optimized code is 
never used, rendering gmp much slower than it can be.


As a workaround, I suggest to compile and install separate 
neon-optimized library in $(libdir)/neon/vfp and rely on ld.so for 
runtime-detection.


Debdiff attached, passed limited testing ([1] cross-compiled [implies 
nocheck] `pbuilder --host-arch=armhf --arch=i386`, installed on 
rpi3b+/raspbian-stretch, benchmarked; [2] native recompilation on 
rpi3b+/raspbian [passed regression tests], then installed and benchmarked);


No idea how well this would work on hurd, kfreebsd, etc.

I hardcoded armv7 for neon code: debian's armhf requires minimum armv7, 
so this should be acceptable; I have not tested, but this should not 
break "fake armhf" from raspbian (rpi1 is armv6 without neon, so new 
neon-optimized variant would not be picked; newer rpi are armv7+ and 
have neon).


Potential pitfalls: it enables previously untested (at least, by debian) 
code on affected platforms, some bugs can lurk there.


About expected user-visible effect, on Raspberry Pi 3B+ (BCM2837B0, 
4-core Cortex-A53 @1.4GHz), `gnutls-cli --benchmark-tls-kx`:


Before:
Testing key exchanges (RSA/DH bits: 3072, EC bits: 256)
(TLS1.2)-(DHE-RSA-3072)-(AES-128-CBC)-(SHA1)  5.50 transactions/sec
   (avg. handshake time: 181.71 ms, sample variance: 0.43)
(TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-128-CBC)-(SHA1)  12.08 transactions/sec
   (avg. handshake time: 82.77 ms, sample variance: 0.18)
(TLS1.2)-(ECDHE-RSA-X25519)-(AES-128-CBC)-(SHA1)  12.32 transactions/sec
   (avg. handshake time: 81.03 ms, sample variance: 0.03)
(TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(AES-128-CBC)-(SHA1)  77.88 
transactions/sec

   (avg. handshake time: 12.73 ms, sample variance: 0.20)
(TLS1.2)-(ECDHE-ECDSA-X25519)-(AES-128-CBC)-(SHA1)  88.98 transactions/sec
   (avg. handshake time: 11.13 ms, sample variance: 0.11)
   (TLS1.2)-(RSA)-(AES-128-CBC)-(SHA1)  13.15 transactions/sec
   (avg. handshake time: 75.86 ms, sample variance: 0.12)

After:
Testing key exchanges (RSA/DH bits: 3072, EC bits: 256)
(TLS1.2)-(DHE-RSA-3072)-(AES-128-CBC)-(SHA1)  8.40 transactions/sec
   (avg. handshake time: 118.98 ms, sample variance: 0.27)
(TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-128-CBC)-(SHA1)  18.42 transactions/sec
   (avg. handshake time: 54.23 ms, sample variance: 0.18)
(TLS1.2)-(ECDHE-RSA-X25519)-(AES-128-CBC)-(SHA1)  18.88 transactions/sec
   (avg. handshake time: 52.82 ms, sample variance: 0.15)
(TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(AES-128-CBC)-(SHA1)  93.89 
transactions/sec

   (avg. handshake time: 10.54 ms, sample variance: 0.25)
(TLS1.2)-(ECDHE-ECDSA-X25519)-(AES-128-CBC)-(SHA1)  106.83 transactions/sec
   (avg. handshake time: 9.25 ms, sample variance: 0.19)
   (TLS1.2)-(RSA)-(AES-128-CBC)-(SHA1)  20.46 transactions/sec
   (avg. handshake time: 48.78 ms, sample variance: 0.18)

That is, 20% to 50% speedup.

^1 --enable-fat works on amd64 too - but debian disables it; maybe, it's 
time to reconsider? some related bugs was fixed upstream since last 
attempt (which resulted in #671866); that said, on my cpu amd64+fat is 
slower than current debian-packaged "fat-free" code, so I'm not very 
much interested.


-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R), 
LANGUAGE=ru_RU.KOI8-R (charmap=KOI8-R)

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

diff -Nru gmp-6.1.2+dfsg/debian/rules gmp-6.1.2+dfsg/debian/rules
--- gmp-6.1.2+dfsg/debian/rules 2016-12-21 08:38:23.0 +0300
+++ gmp-6.1.2+dfsg/debian/rules 2019-01-02 22:52:33.0 +0300
@@ -68,9 +68,20 @@
 
 confflags_ma = $(confflags) $(confflags_build) 
--libdir=/usr/lib/$(DEB_HOST_MULTIARCH)
 
+FLAVORS = main
+LIBDIR_main =
+
 CC   = $(DEB_HOST_GNU_TYPE)-gcc
 CXX   = $(DEB_HOST_GNU_TYPE)-g++
 
+ifneq (,$(filter armhf, $(DEB_HOST_ARCH)))
+FLAVORS += neon
+
+LIBDIR_neon = neon/vfp
+neon_host_type = $(patsubst 
arm-%,armcortexa7neon-unknown-%,$(DEB_HOST_GNU_TYPE))
+confflags_neon = --host=$(neon_host_type) --target=$(neon_host_type) 
--libdir=/usr/lib/$(DEB_HOST_MULTIARCH)/$(LIBDIR_neon)
+CFLAGS_neon = -march=armv7-a -mfpu=neon
+endif
 
 get-orig-source: gmp-$(ORIG_SRC_VERSION).tar.xz
tar --xz -xf $<
@@ -88,25 +99,34 @@
 gmp-$(ORIG_SRC_VERSION).tar.xz:
wget https://gmplib.org/download/gmp/$@
 
-configure: configure-stamp
-configure-stamp:
-   mkdir -p build
-   cd build && ../configure $(confflags_ma) \
-   AR=$(AR) CC="$(CC)" 

Bug#826069: libghemical5v5: breaks color rendering and atom generation in ghemical

[Carlo Segre]

Hello:

I think that I have found the origin of this bug.  It is in the 
liboglappth2 package.  This package has only one reverse dependency, that 
is ghemical.  The package has remained the same (MD5 sum) since at least 
wheezy and something in the compilation dependencies has changed so that 
it breaks ghemical.  This bug should probably be redirected to the

liboglappth2 package.

All that is needed to close this bug is to recompile the liboglappth 
source package.


Carlo

--
Carlo U. Segre -- Duchossois Leadership Professor of Physics
Interim Chair, Department of Chemistry
Director, Center for Synchrotron Radiation Research and Instrumentation
Illinois Institute of Technology
Voice: 312.567.3498Fax: 312.567.3494
se...@iit.edu   http://phys.iit.edu/~segre   se...@debian.org

Bug#908524: pipewire: Section should not be “libs”

[Jeremy Bicha]

Ben or Laurent, do one of you want to submit the follow-up bug report
to fully change the section?

Thanks,
Jeremy Bicha

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Thomas Dickey]

On Fri, Jan 04, 2019 at 08:13:53PM +0100, Alexander Meyer wrote:
> Would this warrant to add "affects" tags for firefox and chromium to
> this bug? Not sure about the Debian policy here. In this case, the

no - see https://www.debian.org/Bugs/server-control#affects

(since you're the only one to report it so far)

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#918313: RM: bfgminer -- RoQA; RC-buggy, orphaned, not in stable

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove bfgminer, it's RC-buggy, orphaned for almost a year without
an adopter and already missed the previous stable release.

Cheers,
Moritz

Bug#918312: salt-{master,minion} fail to purge

[Adrian Bunk]

Source: salt
Version: 2018.3.3+dfsg1-1
Severity: serious
Control: affects -1 salt-master salt-minion

https://piuparts.debian.org/sid/source/s/salt.html

  Purging configuration files for salt-master (2018.3.3+dfsg1-1) ...
  rmdir: failed to remove '/var/lib/salt/pki': No such file or directory
  dpkg: error processing package salt-master (--purge):
   installed salt-master package post-removal script subprocess returned error 
exit status 1
  Errors were encountered while processing:
   salt-master

  Purging configuration files for salt-minion (2018.3.3+dfsg1-1) ...
  rmdir: failed to remove '/var/lib/salt/pki': No such file or directory
  rmdir: failed to remove '/var/lib/salt': No such file or directory
  dpkg: error processing package salt-minion (--purge):
   installed salt-minion package post-removal script subprocess returned error 
exit status 1
  Errors were encountered while processing:
   salt-minion

Bug#918311: stormbaancoureur FTCBFS: uses the wrong compiler

[Helmut Grohne]

Source: stormbaancoureur
Version: 2.1.6-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

stormbaancoureur 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 stormbaancoureur cross buildable. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru stormbaancoureur-2.1.6/debian/changelog 
stormbaancoureur-2.1.6/debian/changelog
--- stormbaancoureur-2.1.6/debian/changelog 2016-08-03 19:38:05.0 
+0200
+++ stormbaancoureur-2.1.6/debian/changelog 2019-01-04 23:17:55.0 
+0100
@@ -1,3 +1,10 @@
+stormbaancoureur (2.1.6-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 04 Jan 2019 23:17:55 +0100
+
 stormbaancoureur (2.1.6-2) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru stormbaancoureur-2.1.6/debian/rules 
stormbaancoureur-2.1.6/debian/rules
--- stormbaancoureur-2.1.6/debian/rules 2016-08-03 19:38:05.0 +0200
+++ stormbaancoureur-2.1.6/debian/rules 2019-01-04 23:17:53.0 +0100
@@ -8,16 +8,8 @@
 
 
 %:
-   dh $@ --parallel
+   dh $@ --parallel --sourcedirectory=src-stormbaancoureur
 
 
 override_dh_auto_build:
-   $(MAKE) -C src-stormbaancoureur CFLAGS="$(CPPFLAGS) $(CFLAGS)"
-
-override_dh_auto_clean:
-   [ ! -f src-stormbaancoureur/Makefile ] || $(MAKE) -C 
src-stormbaancoureur clean
-   dh_auto_clean
-
-override_dh_auto_install:
-   $(MAKE) install -C src-stormbaancoureur DESTDIR=$(CURDIR)/debian/tmp
-
+   dh_auto_build -- CFLAGS="$(CPPFLAGS) $(CFLAGS)"

Bug#907624: What ffindex do we want to package

[Andreas Tille]

On Fri, Jan 04, 2019 at 07:17:24PM +0200, Michael Crusoe wrote:
> I think 0.9.9.7+sog+git20160415.14274c9-1 is the source of the recent FTBFS
> of hhsuite: https://bugs.debian.org/917495 as our packaged version is
> missing the "ffsort_index" function.
> 
> The hh-suite github repo contains a submodule pointing at their fork of
> ffindex at ~ 2017-06-01:
> https://github.com/soedinglab/hh-suite/tree/v3.0-beta.3/lib  →
> https://github.com/soedinglab/ffindex_soedinglab/tree/360e4176ece531be34a94298c808349916d016ac
> 
> I suggest that we package it as part of hhsuite until another package needs
> it.
> 
> hhsuite does provide  "*-Source*" packages that include ffindex, so we
> wouldn't need a multi-source build.

By any means just do something sensible.  I'm way to less educated about
this software and just got my fingers dirty with it since nobody else
cared about the (other!) bugs.
 
Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#918249: doc-rfc: please switch to ps2txt for testsuite

[Iustin Pop]

On 2019-01-04 21:26:03, Iustin Pop wrote:
> On 2019-01-04 20:16:40, Gianfranco Costamagna wrote:
> >  thanks  for having a look! I was wondering about something more subtle and 
> > behind the scenes :)
> > btw for some reasons the ci is not running the testsuite on 
> > unstablehttps://ci.debian.net/packages/d/doc-rfc/probably because testing 
> > is sad?
> > I don't know, I tried the -2 I committed on git on debomatic and the 
> > autopkgtestsuite was good :)
> 
> Hrmm, I thought I'd get an email about this, but no, seems I have to
> look manually at ddpo. One more thing to add to my notes…
> 
> I'll try to sort this out soon, before the soft freeze. Not sure I can
> finish everything this weekend.

This is very weird. My procedure for uploading a new package includes
running an autopkgtest manually, and I see now that this fails (on the
version I uploaded), I don't know why I missed it before the most recent
upload. Unfortunately I don't have a fully automated
'build-check-upload' pipeline, so most likely human error/oversight.

In any case, I'll be more careful in the future. New version is
uploading right now.

thanks,
iustin

Bug#918310: php-respect-validation: Drop dependency upon php-symfony-polyfill-mbstring

[Kunal Mehta]

Package: php-respect-validation
Version: 1.1.15-1
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The dependency upon php-symfony-polyfill-mbstring can safely be replaced with
php-mstring, which provides the extension itself. There is some relevant
discussion in #911832 as well. It's unlikely that the php-symfony-polyfill
package will be included at Buster at this time.

See attached patch.

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

Kernel: Linux 4.19.12-301.fc29.x86_64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages php-respect-validation depends on:
ii  php-common 2:69
ii  php-symfony-polyfill-mbstring  1.9.0-1

php-respect-validation recommends no packages.

Versions of packages php-respect-validation suggests:
pn  php-bcmath
pn  php-egulias-email-validator   
pn  php-fabpot-php-cs-fixer   
ii  php-mbstring  2:7.3+69
pn  php-symfony-validator 
pn  php-zendframework-zend-validator  
ii  php7.3-mbstring [php-mbstring]7.3.0-2

-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE+h6fmkHn9DUCyl1jUvyOe+23/KIFAlwv3EoTHGxlZ29rdG1A
ZGViaWFuLm9yZwAKCRBS/I577bf8oqM1D/4j8fH4b95XILGV7vf0QEpheW6K0soe
/1cKpa4cOqCrwihSCgqKAG6Bv56fQczio5UMsE+Y8Y/L6kkSS0vDSk9SZXG9LENt
akpCPfT7BChCbCTVjn/Efz67eApqELIkGGTS99XU887ia4k+BijKrJybzfJOXZOl
b/01FmqzN0zEtoY32zqNjSrSWS8oPlzfabxekh070M60aDW7OnRKe5B7o4yE4tsX
vIdgICOCsmsd1Za7e/3XNVutObZ9AZe4zcWiM4rUvDIsaktMopGqrCTY2sMEXJT+
RqNBBQpYd4dNA3jcr3mMbznoBetneUhxt//fbIlc1yRBrVNo6rFL7GYzVndSj/jX
7O+dO2UtecrRGwivDBuOwv0RsKjzXSyPKAhsOk/bTRajNXIN/oKAhelOqnXEvLzh
FNC7pHXxjLUYqazwmWtQw+fEn0rFUu/xyYTKT4XJ7BFUX/4DFIBraMBFJuhN2xwA
rDNlxlzYsS48QeL0RKTTfbJhbmhTT3wL8tKPQhOQyaZJz/bPcNR/Qs4Q/PlA4ncv
Wz5shKZf/fzpctqnmDKX/sy7ngiPSw6YGmbNMlAfYvh9Vt2GPcCL8R79XDmGxl60
ekByNFdF87rZNb7bNkWaaJKPGFnQ92wo/Z+Y6JC9AE61d6Cq5p8DP2u8e71Ei0RG
xw7oB5PX7zzkMQ==
=bd+z
-END PGP SIGNATURE-
>From 025b159765ca33f2c49b66c2e68b3964a7491e30 Mon Sep 17 00:00:00 2001
From: Kunal Mehta 
Date: Fri, 4 Jan 2019 14:15:03 -0800
Subject: [PATCH] Drop dependency upon php-symfony-polyfill-mbstring in favor
 of php-mbstring

Instead of using a polyfill, we can simply depend upon the actual PHP
extension. There's some relevant discussion in #911832 as well.

Using the override file, we can disable the automatic dependency and add
php-mbstring in d/control.

Closes: #-1
---
 debian/control | 2 +-
 debian/pkg-php-tools-overrides | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)
 create mode 100644 debian/pkg-php-tools-overrides

diff --git a/debian/control b/debian/control
index 832d20f..892e2f8 100644
--- a/debian/control
+++ b/debian/control
@@ -11,7 +11,7 @@ Vcs-Browser: 
https://salsa.debian.org/tdtf-team/php-respect-validation
 
 Package: php-respect-validation
 Architecture: all
-Depends: ${misc:Depends}, ${phpcomposer:Debian-require}
+Depends: ${misc:Depends}, php-mbstring, ${phpcomposer:Debian-require}
 Recommends: ${phpcomposer:Debian-recommend}
 Suggests: ${phpcomposer:Debian-suggest}
 Replaces: ${phpcomposer:Debian-replace}
diff --git a/debian/pkg-php-tools-overrides b/debian/pkg-php-tools-overrides
new file mode 100644
index 000..f295d3d
--- /dev/null
+++ b/debian/pkg-php-tools-overrides
@@ -0,0 +1 @@
+symfony polyfill-mbstring none
-- 
2.20.1

Bug#884923: abiword: CVE-2017-17529

[Jeremy Bicha]

On Fri, Jan 4, 2019 at 3:31 PM Salvatore Bonaccorso  wrote:
> Did you got a chance to ping upstream on that issue and report it?

No, but you can if you like.

https://gitlab.gnome.org/World/AbiWord is the current source repo, but
you might need to still use bugzilla for reporting issues.

Thanks,
Jeremy Bicha

Bug#903828: accountsservice: CVE-2018-14036: insufficient path check in user_change_icon_file_authorized_cb() in user.c

[Moritz Mühlenhoff]

On Sun, Jul 15, 2018 at 02:55:15PM +0200, Salvatore Bonaccorso wrote:
> Source: accountsservice
> Version: 0.6.43-1
> Severity: important
> Tags: patch security upstream
> Forwarded: https://bugs.freedesktop.org/show_bug.cgi?id=107085
> Control: found -1  0.6.45-1
> 
> Hi,
> 
> The following vulnerability was published for accountsservice.
> 
> CVE-2018-14036[0]:
> | Directory Traversal with ../ sequences occurs in AccountsService before
> | 0.6.50 because of an insufficient path check in
> | user_change_icon_file_authorized_cb() in user.c.
> 
> 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-2018-14036
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14036
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=107085
> [2] http://www.openwall.com/lists/oss-security/2018/07/02/2
> [3] 
> https://cgit.freedesktop.org/accountsservice/commit/?id=f9abd359f71a5bce421b9ae23432f539a067847a

Can you please fix this before the buster freeze?

Cheers,
Moritz

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Thomas Dickey]

On Fri, Jan 04, 2019 at 08:13:53PM +0100, Alexander Meyer wrote:
> * Thomas Dickey  [2019-01-04 01:10]:
> 
> > On Thu, Jan 03, 2019 at 05:56:26PM +0100, Alexander Meyer wrote:
> >> * Thomas Dickey  [2019-01-02 10:46]:
> >> 
> >>> I verified that the same issue exists in current code, and submitted an
> >>> 
> >>>   https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/140
> >>> 
> >>> with the attached fix.
> >> 
> >> As a side note, visiting that particular page causes both Chromium and
> >> Firefox to crash in a manner that looks similar to what I reported for
> >> xterm. Chromium crashes completely, in Firefox it's just a tab crash.
> > 
> > perhaps the bug will get more attention then :-)
> 
> Would this warrant to add "affects" tags for firefox and chromium to
> this bug? Not sure about the Debian policy here. In this case, the
> Subject line should probably be changed to something more meaningful.

agreed - the subject line is too specific.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#918309: sphinxcontrib-programoutput: Please update to v0.13 that is compatible with Sphinx 1.8

[Dmitry Shachnev]

Source: sphinxcontrib-programoutput
Version: 0.11-3
Severity: important
User: python-modules-t...@lists.alioth.debian.org
Usertags: sphinx1.8

Dear maintainer,

Currently sphinxcontrib-programoutput fails to build against Sphinx 1.8,
which is available in experimental.

Please update to the latest upstream release, 0.13, which is compatible
with new Sphinx.

See this upstream pull request for details:
https://github.com/NextThought/sphinxcontrib-programoutput/pull/31

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#918306: wrong-section-according-to-package-name is wrong about hyphen-en-us

[Daniel Kahn Gillmor]

Package: lintian
Version: 2.5.119

when checking the hyphen source package, lintian claims:

I: hyphen-en-us: wrong-section-according-to-package-name hyphen-en-us => 
localization

but all hyphen-* packages are Section: text, as hyphen-en-us is. (see
the source for libreoffice-dictionaries, which supplies most of the
other hyphenation packages).

Please adjust this check!

thanks,

--dkg


signature.asc
Description: PGP signature

Bug#906271: debug log

[Arnaud Loonstra]

K, found some hints through the Sogo ml.

If you set SoProductRegistryDebugEnabled = YES; in the sogo.conf you can 
see it fails to load some libs:


Jan 04 21:50:23 sogod [6628]: version 4.0.4 -- starting
Jan 04 21:50:23 sogod [6628]: vmem size check enabled: shutting down app 
when vmem > 384 MB. Currently at 65 MB
Jan 04 21:50:23 sogod [6628]: <0x0x13b1bd8[SOGoProductLoader]> SOGo 
products loaded from '/usr/lib/GNUstep/SOGo':
Jan 04 21:50:23 sogod [6628]: <0x0x13b1bd8[SOGoProductLoader]> 
MailerUI.SOGo, Appointments.SOGo, MainUI.SOGo, Mailer.SOGo, 
SchedulerUI.SOGo, CommonUI.SOGo, MailPartViewers.SOGo, ContactsUI.SOGo, 
AdministrationUI.SOGo, PreferencesUI.SOGo, Contacts.SOGo
Jan 04 21:50:23 sogod [6628]: [so-product-registry] could not load 
product: MailPartViewers
Jan 04 21:50:23 sogod [6628]: [so-product-registry] could not load 
product: MailerUI
Jan 04 21:50:23 sogod [6628]: All products loaded - current memory usage 
at 70 MB

Jan 04 21:50:23 sogod [6628]: <0x0x13bb1a0[WOWatchDog]> listening on *:2
Jan 04 21:50:23 sogod [6628]: <0x0x13bb1a0[WOWatchDog]> watchdog process 
pid: 6628
Jan 04 21:50:23 sogod [6628]: <0x0xb6ba7068[WOWatchDogChild]> watchdog 
request timeout set to 10 minutes

Jan 04 21:50:23 sogod [6628]: <0x0x13bb1a0[WOWatchDog]> preparing 3 children
Jan 04 21:50:23 sogod [6628]: <0x0x13bb1a0[WOWatchDog]> child spawned 
with pid 6629
Jan 04 21:50:23 sogod [6628]: <0x0x13bb1a0[WOWatchDog]> child spawned 
with pid 6630
Jan 04 21:50:23 sogod [6628]: <0x0x13bb1a0[WOWatchDog]> child spawned 
with pid 6631
Jan 04 21:50:23 sogod [6630]: <0x0x13a3b88[WOHttpAdaptor]> notified the 
watchdog that we are ready
Jan 04 21:50:23 sogod [6629]: <0x0x13a3b88[WOHttpAdaptor]> notified the 
watchdog that we are ready
Jan 04 21:50:23 sogod [6631]: <0x0x13a3b48[WOHttpAdaptor]> notified the 
watchdog that we are ready


Then when sogo terminates the following appears in the log:

Error 
(objc-load):/usr/lib/GNUstep/SOGo/MailPartViewers.SOGo/MailPartViewers: 
undefined symbol: SSL_load_error_strings
Error (objc-load):/usr/lib/GNUstep/SOGo/MailerUI.SOGo/MailerUI: 
undefined symbol: __objc_class_name_UIxMailSizeFormatter


It's fixed upstream apparently. See this thread for discussion:
https://lists.inverse.ca/sogo/arc/users/2016-05/msg00032.html

Rg,

Arnaud

Bug#918307: civicrm-common: Drop dependency upon php-symfony-polyfill-iconv

[Kunal Mehta]

Package: civicrm-common
Version: 5.8.2+dfsg-1
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The dependency upon php-symfony-polyfill-iconv can safely be dropped, since
php-common already provides the iconv extension. There is some relevant
discussion in #911832 as well. It's unlikely that the php-symfony-polyfill
package will be included at Buster at this time.

See attached patch.

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

Kernel: Linux 4.19.12-301.fc29.x86_64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages civicrm-common depends on:
pn  ckeditor  
pn  fonts-font-awesome
pn  libjs-backbone
pn  libjs-d3  
pn  libjs-jquery-datatables   
pn  libjs-jquery-form 
pn  libjs-jquery-mousewheel   
pn  libjs-jquery-ui   
pn  libjs-prettify
pn  libjs-qunit   
ii  php-common2:69
pn  php-dompdf
pn  php-htmlpurifier  
ii  php-mbstring  2:7.3+69
ii  php-psr-log   1.1.0-1
pn  php-psr-simple-cache  
pn  php-seclib
pn  php-symfony-config
pn  php-symfony-dependency-injection  
pn  php-symfony-event-dispatcher  
ii  php-symfony-filesystem3.4.20+dfsg-1
ii  php-symfony-finder3.4.20+dfsg-1
pn  php-symfony-polyfill-iconv
ii  php-symfony-process   3.4.20+dfsg-1
pn  php-tcpdf 
ii  php-xml   2:7.3+69
ii  php7.3-mbstring [php-mbstring]7.3.0-2
ii  php7.3-xml [php-xml]  7.3.0-2

Versions of packages civicrm-common recommends:
pn  civicrm-l10n
ii  php-curl2:7.3+69
ii  php-zip 2:7.3+69
ii  php7.3-curl [php-curl]  7.3.0-2
ii  php7.3-zip [php-zip]7.3.0-2
pn  wkhtmltopdf 
pn  xvfb

Versions of packages civicrm-common suggests:
pn  wordpress-civicrm  

-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE+h6fmkHn9DUCyl1jUvyOe+23/KIFAlwv2VgTHGxlZ29rdG1A
ZGViaWFuLm9yZwAKCRBS/I577bf8ot4kD/4i8yPQS+hf4v1zb+Xi/Z2npt3/qkH2
c6yVqaYVZ7PfNtTIJqdzQHsTuEPaPwnoCfnIHmQpz1AjqtUSzJuSUQzehfYfRUVU
3pq9JP1rvfzz7Chr8iC8BxMgYE04bsFJGtAc2JlQg2o6Yfwoefu+wavb9ECfuylS
hI6YB12ICGqa475IeEpYzjTqn14KlbYcju223QzE2cVgL0k1NrqRBltwNcERJn6j
AN+mmo57OalXbdBg+3BxDsuP33V4zh3cnSa8BrO7k2vLg5LhkGeErs+a+roBrEVR
1Kt/RHTBxgZhhj8NHGKQ0vk8tEnVScJdC4LQpU6Ls3oEBeTX+uUonpLqbjWBYjgT
kH2rQs25bSjX6wV9G75V2E0jNLQ0KbRSFEA2DffkTdawIU3OEIakFMcEIEa+HnMN
h4IiY0EF7RTAozKyn48pxrOXSAxlg0WoPIssztUUFHQTLBWcGCDoaiFH5Gx+AGls
NVZ+wk30wW09WF/zpLDizHUJEgpqlBaEaeRyLvjOo6+d0BIdqkKRfahpGZt4MsJT
4vVoTIEMbqy3veXur51oJ2mBc4OaOJbCLtUrVFhRZ3iz//SYJHMu5UiFqv1044FB
BPPXwLSvaNzHD2f5ZiJU74PL1lQzffdIg+32RlKFXOH27VNJKVLVKEmGlzMAUT1M
QTFHrjIy8i4DIA==
=ARKH
-END PGP SIGNATURE-
>From 53113969df12cbc463ad1e480370cd3fa3191a4d Mon Sep 17 00:00:00 2001
From: Kunal Mehta 
Date: Fri, 4 Jan 2019 13:45:41 -0800
Subject: [PATCH] Don't depend on php-symfony-polyfill-iconv

The iconv extension is included in php-common, so there's no need to include
a polyfill for it. See discussion on #911832 for some more rationale.

Closes: #-1
---
 debian/pkg-php-tools-overrides | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/pkg-php-tools-overrides b/debian/pkg-php-tools-overrides
index dd20818..f350393 100644
--- a/debian/pkg-php-tools-overrides
+++ b/debian/pkg-php-tools-overrides
@@ -23,3 +23,5 @@ pear  net_smtpnone
 #pear  net_socket  php-net-socket
 pear   net_socket  none
 
+## Provided by PHP
+symfonypolyfill-iconv  builtin
-- 
2.20.1

Bug#884923: abiword: CVE-2017-17529

[Moritz Mühlenhoff]

On Sun, May 27, 2018 at 10:54:06PM +0200, Gabriel Corona wrote:
> This seems correct with respect to injection through the URI:
> the URI string cannot be expanded into multiple arguments
> and is not passed to `system()`.

Agreed, this CVE seems like a non issue, the CVE entry at MITRE
also only refers back to the Security Tracker...

Cheers,
Moritz

Bug#918308: transition: botan

[Laszlo Boszormenyi (GCS)]

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

Hi RMs,

It's a small transition with only three packages: biboumi,
libqtshadowsocks and qtcreator. All three build fine with
this botan release as well.
It is also needed for proper upstream support for building botan
for armel/armhf on arm64 machines[1].

Thanks,
Laszlo/GCS
[1] https://bugs.debian.org/916970

Bug#918221: ftp.debian.org: Please add aceept-with-bug to DAK process-new

[Joerg Jaspert]

On 15272 March 1977, Chris Lamb wrote: 

I suggested this, since currently it's easier to write a reject 
message than a  bug from within DAK.  I envision something like 
an "Add overrides and file  bug" option within process-new so 
that accept plus bug would be approximately  as easy/fast as 
writing a reject message.


The feature sounds nice, someone get me a patch for it.

--
bye, Joerg

Bug#918305: hyphen-en-us: please provide fallback symlink from hyph_en.dic to hyph_en_US.dic

[Daniel Kahn Gillmor]

Package: hyphen-en-us
Version: 2.8.8-5
Severity: wishlist

Some tools, like pyphen's test suite (see RFP
https://bugs.debian.org/917039) expect a fallback symlink from a
generic language to a region-specific language.

Please provide a fallback symlink from hyph_en.dic to hyph_en_US.dic
in /usr/share/hyphen.  thanks!

   --dkg

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

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

Versions of packages hyphen-en-us depends on:
ii  dictionaries-common  1.28.1

hyphen-en-us recommends no packages.

Versions of packages hyphen-en-us suggests:
ii  libreoffice-writer  1:6.1.4-3

-- no debconf information

Bug#910571: qemu-user-static i386 (and x86-64) on armel host errors while loading shared libraries

[Bernhard Übelacker]

Hello Michael Tokarev, hello Theo

I have now another machine at hand where I currently have
buster installed, where today qemu-user-static in
version 3.1 appeared.

So I did some tests.
It still shows the issue reported by Theo:

root@qnap-119p-ii:~# chroot /tmp/buster-chroot-i386 /bin/bash
/bin/bash: error while loading shared libraries: b/i38/-li6ux-nnu/g: nnoa 
retd fale iatadlib/i38/-li6ux-nnu/g: o

I changed the kernel alignment configuration like this:

echo 2 > /proc/cpu/alignment

Then bash, uname and ls are working:

root@qnap-119p-ii:~# chroot /tmp/buster-chroot-i386 /bin/bash
I have no name!@qnap-119p-ii:/# uname -a
Linux qnap-119p-ii 4.19.0-1-marvell #1 Debian 4.19.12-1 (2018-12-22) i686 
GNU/Linux


Unfortunately the chroot setup cannot finish and fails trying to run:
chroot "/tmp/buster-chroot-i386" dpkg-deb -f 
/var/cache/apt/archives/dpkg_1.19.2_i386.deb Version
But that is a different issue.

Attached are some more information about the
system and tested commands.

Kind regards,
Bernhard
root@qnap-119p-ii:~# lscpu
Architecture:armv5tel
Byte Order:  Little Endian
CPU(s):  1
On-line CPU(s) list: 0
Thread(s) per core:  1
Core(s) per socket:  1
Socket(s):   1
Vendor ID:   Marvell
Model:   1
Model name:  Feroceon 88FR131
Stepping:0x2
CPU max MHz: 2000,
CPU min MHz: 500,
BogoMIPS:400.00
Flags:   swp half thumb fastmult edsp


root@qnap-119p-ii:~# cat /proc/cpuinfo 
processor   : 0
model name  : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS: 400.00
Features: swp half thumb fastmult edsp 
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant : 0x2
CPU part: 0x131
CPU revision: 1

Hardware: Marvell Kirkwood (Flattened Device Tree)
Revision: 
Serial  : 


root@qnap-119p-ii:~# cat /etc/debian_version 
buster/sid






export PKG="qemu-user-static debootstrap systemd-coredump"; apt install $PKG; 
apt-mark auto $PKG


root@qnap-119p-ii:/tmp# qemu-i386-static --version
qemu-i386 version 3.1.0 (Debian 1:3.1+dfsg-2)
Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers





root@qnap-119p-ii:/tmp# qemu-i386-static 910571_test
12

# should be 123








# https://www.kernel.org/doc/Documentation/arm/mem_alignment


root@qnap-119p-ii:/tmp# echo 1 > /proc/cpu/alignment
root@qnap-119p-ii:/tmp# cat /proc/cpu/alignment 
User:   28
System: 0 (  (null))
Skipped:0
Half:   0
Word:   0
DWord:  0
Multi:  0
User faults:1 (warn)

root@qnap-119p-ii:/tmp# qemu-i386-static 910571_test
12

root@qnap-119p-ii:/tmp# cat /proc/cpu/alignment 
User:   186
System: 0 (  (null))
Skipped:0
Half:   0
Word:   0
DWord:  0
Multi:  0
User faults:1 (warn)

dmesg:
[ 1070.346332] Alignment trap: qemu-i386-stati (5664) PC=0x6058e450 
Instr=0xe1d580b0 Address=0x080b01ff FSR 0x001
[ 1070.356571] Alignment trap: qemu-i386-stati (5664) PC=0x6058e690 
Instr=0xe1d440b0 Address=0x40800f01 FSR 0x001
... 154 lines ...
[ 1072.021357] Alignment trap: qemu-i386-stati (5664) PC=0x6058e450 
Instr=0xe1d580b0 Address=0x080b02af FSR 0x001
[ 1072.041018] Alignment trap: qemu-i386-stati (5664) PC=0x60592fd0 
Instr=0xe1d450b0 Address=0x080ad009 FSR 0x001







root@qnap-119p-ii:/tmp# echo 2 > /proc/cpu/alignment
root@qnap-119p-ii:/tmp# cat /proc/cpu/alignment 
User:   186
System: 0 (  (null))
Skipped:0
Half:   0
Word:   0
DWord:  0
Multi:  0
User faults:2 (fixup)

root@qnap-119p-ii:/tmp# qemu-i386-static 910571_test
123

root@qnap-119p-ii:/tmp# cat /proc/cpu/alignment 
User:   234
System: 0 (  (null))
Skipped:0
Half:   46
Word:   2
DWord:  0
Multi:  0
User faults:2 (fixup)









# The real thing, with "echo 2 > /proc/cpu/alignment"

mkdir /tmp/buster-chroot-i386/usr/bin -p
cp -a /usr/bin/qemu-i386-static /tmp/buster-chroot-i386/usr/bin/

debootstrap --arch=i386 buster /tmp/buster-chroot-i386 
http://192.168.178.25:/debian-10-buster-deb.debian.org/




root@qnap-119p-ii:~# debootstrap --arch=i386 buster /tmp/buster-chroot-i386 
http://192.168.178.25:/debian-10-buster-deb.debian.org/
I: Target architecture can be executed
I: Retrieving InRelease 
I: Checking Release signature
I: Valid Release signature (key id 16E90B3FDF65EDE3AA7F323C04EE7237B7D453EC)
I: Retrieving Packages 
I: Validating Packages 
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on 
http://192.168.178.25:/debian-10-buster-deb.debian.org...
I: Retrieving libacl1 2.2.52-3+b1
I: Validating libacl1 2.2.52-3+b1
I: Retrieving adduser 3.118
I: Validating adduser 3.118
I: Retrieving libapparmor1 2.13.1-3+b1
I: Validating 

Bug#918304: debmirror wants non-zero gpgv return code, instead of a GOODSIG on --status-fd

[Daniel Kahn Gillmor]

Package: debmirror
Version: 1:2.30
Severity: normal

sid is apparently currently signed by three keys -- automatic signing
keys for wheezy, jessie, and stretch.  I can't justify this (i have no
idea why it should be signed by the wheezy signing key, for example),
but that shouldn't matter for debmirror's purpose.

In practice, debmirror should accept any one good signature from any
of its trusted keys.

However, gpgv returns a non-zero error code if it notices anything
fishy, like a signature that it can't validate, and debmirror uses
that as a chance to bail out.  Here's an example:

2 debmirror@testhost:~$ debmirror --keyring 
/usr/share/keyrings/debian-archive-stretch-automatic.gpg /srv/debmirror/archive 

[GNUPG:] NEWSIG
[GNUPG:] ERRSIG 8B48AD6246925553 1 8 00 1546612061 9 
A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553
[GNUPG:] NO_PUBKEY 8B48AD6246925553
[GNUPG:] NEWSIG
[GNUPG:] ERRSIG 7638D0442B90D010 1 8 00 1546612061 9 
126C0D24BD8A2942CC7DF8AC7638D0442B90D010
[GNUPG:] NO_PUBKEY 7638D0442B90D010
[GNUPG:] NEWSIG
[GNUPG:] KEY_CONSIDERED E1CF20DDFFE4B89E802658F1E0B11894F66AEC98 0
[GNUPG:] SIG_ID xEVWVyjJFLGtpwkNoXTkQjo22Ws 2019-01-04 1546612061
[GNUPG:] KEY_CONSIDERED E1CF20DDFFE4B89E802658F1E0B11894F66AEC98 0
[GNUPG:] GOODSIG 04EE7237B7D453EC Debian Archive Automatic Signing Key 
(9/stretch) 
[GNUPG:] VALIDSIG 16E90B3FDF65EDE3AA7F323C04EE7237B7D453EC 2019-01-04 
1546612061 0 4 0 1 8 00 E1CF20DDFFE4B89E802658F1E0B11894F66AEC98
[GNUPG:] VERIFICATION_COMPLIANCE_MODE 23
gpgv: Signature made Fri 04 Jan 2019 09:27:41 AM EST
gpgv:using RSA key A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553
gpgv: Can't check signature: No public key
gpgv: Signature made Fri 04 Jan 2019 09:27:41 AM EST
gpgv:using RSA key 126C0D24BD8A2942CC7DF8AC7638D0442B90D010
gpgv: Can't check signature: No public key
gpgv: Signature made Fri 04 Jan 2019 09:27:41 AM EST
gpgv:using RSA key 16E90B3FDF65EDE3AA7F323C04EE7237B7D453EC
gpgv: Good signature from "Debian Archive Automatic Signing Key (9/stretch) 
"
[GNUPG:] NEWSIG
[GNUPG:] ERRSIG 8B48AD6246925553 1 8 01 1546612062 9 
A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553
[GNUPG:] NO_PUBKEY 8B48AD6246925553
[GNUPG:] NEWSIG
[GNUPG:] ERRSIG 7638D0442B90D010 1 8 01 1546612062 9 
126C0D24BD8A2942CC7DF8AC7638D0442B90D010
[GNUPG:] NO_PUBKEY 7638D0442B90D010
[GNUPG:] NEWSIG
[GNUPG:] KEY_CONSIDERED E1CF20DDFFE4B89E802658F1E0B11894F66AEC98 0
[GNUPG:] SIG_ID jhlMnCWh9GquPf8AQBwAiGQAPYU 2019-01-04 1546612062
[GNUPG:] KEY_CONSIDERED E1CF20DDFFE4B89E802658F1E0B11894F66AEC98 0
[GNUPG:] GOODSIG 04EE7237B7D453EC Debian Archive Automatic Signing Key 
(9/stretch) 
[GNUPG:] VALIDSIG 16E90B3FDF65EDE3AA7F323C04EE7237B7D453EC 2019-01-04 
1546612062 0 4 0 1 8 01 E1CF20DDFFE4B89E802658F1E0B11894F66AEC98
[GNUPG:] VERIFICATION_COMPLIANCE_MODE 23
gpgv: Signature made Fri 04 Jan 2019 09:27:42 AM EST
gpgv:using RSA key A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553
gpgv: Can't check signature: No public key
gpgv: Signature made Fri 04 Jan 2019 09:27:42 AM EST
gpgv:using RSA key 126C0D24BD8A2942CC7DF8AC7638D0442B90D010
gpgv: Can't check signature: No public key
gpgv: Signature made Fri 04 Jan 2019 09:27:42 AM EST
gpgv:using RSA key 16E90B3FDF65EDE3AA7F323C04EE7237B7D453EC
gpgv: Good signature from "Debian Archive Automatic Signing Key (9/stretch) 
"
Errors:
 .temp/.tmp/dists/sid/Release.gpg signature does not verify
 .temp/.tmp/dists/sid/InRelease signature does not verify
Failed to download some Release, Release.gpg or InRelease files!
WARNING: releasing 1 pending lock...
2 debmirror@testhost:~$

debmirror's gpg_verify() function should be re-written to account for
this, probably by verifying that *at least one* signature is valid.

While fixing this signature verification, it might also want to ensure
that it's verifying the status-fd output, rather than the return code
(see https://dev.gnupg.org/T1537#100523 and other related discussion
about why the return code is not reliable for what you typically want
to find out from gpgv).

In addition, the verification of InRelease is potentially buggy,
because the processing of the inline signature doesn't verify the
*contents* of the signature -- there could be additional data above or
below the signature -- or multiple things signed.  So any verification
like that needs to probably use the gpgv --output flag, and stash (or
compare) the output to Release itself.  (or sometihng like that, i
confess i don't follow all the logic in debmirror for
signature-verification yet)

  --dkg


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

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: 

Bug#917260: msmtp: hangs after message termination [.]

[Martin Lambers]

Hi,

this only happens with the zoho SMTP server if your test mail has no
blank line that separates mail headers and mail body.

Please try (for example) 'echo -e "test-header\n\ntest-body"' instead
of just 'echo "test"'; it should work fine.

Explanation: if the mail-terminating "." line appears when the zoho
SMTP server thinks we are still in the mail headers, it will not
interpret it as end-of-data, and thus will wait for more data instead
of answering with "250 Message received".

A mail that does not have the blank line separating headers and body is
malformed according to the RFCs, so one could argue that the zoho SMTP
server behavior is ok, but on the other hand it seems to be the only
SMTP server working this way and breaking the typical 'echo "test"
| ...' pattern...

Best,
Martin

Bug#918301: libgdk-pixbuf2.0-dev: pkg-config reports version 2.10.14 when installed version is 2.36.5-2+deb9u2

[Jeremy Bicha]

On Fri, Jan 4, 2019 at 4:33 PM  wrote:
> pkg-config gtk+-3.0 --libs
>
> I get
>
> Package 'gdk-3.0' requires 'gdk-pixbuf-2.0 >= 2.30.0' but version of 
> gdk-pixbuf-2.0 is 2.10.14
>
> In fact version 2.36.5-2+deb9u2 is installed.  The culprit seems to be 
> /usr/lib/x86_64-linux-gnu/pkgconfig/gdk-pixbuf-2.0.pc which is part of this 
> package.

Sorry, I can't reproduce this issue on Debian 9 "Stretch" with the
test case you provided. If I could, I think it would be a serious bug
that would break a lot of packages.

Please check if you have an older library installed to something like
/usr/local/lib/

Thanks,
Jeremy Bicha

Bug#918242: ITS: lmms

[Javier Serrano Polo]

El dv 04 de 01 de 2019 a les 17:57 +0100, Ross Gammon va escriure:
> And he has been recently adding information to some of the bugs,
> including
> asking for help to upload something.

Indeed, I am still waiting. Boyuan Yang offered to sponsor too. I am
fine if you do the upload.

Next upstream version, namely 1.2.0, is not ready.

> I am wondering if it would be a good idea to move lmms into the
> Debian
> Multimedia team where I could help with the maintenance.

This is for Debian Edu developers to decide.

smime.p7s
Description: S/MIME cryptographic signature

Bug#917559: msmtp: fails to verify TLS certificate when the mail host is not the CN but only a SAN

[Martin Lambers]

Hi,

the problem is fixed since version 1.6.8, which added support for TLS
Server Name Indication (SNI).

I just tested with the mail server mail.bdld.info mentioned in your
report.

Best,
Martin

Bug#911979: fails on chown in autopkgtest-qemu backend

[Johannes Schauer]

Quoting Antoine Beaupré (2019-01-04 22:32:56)
> > I fixed the problem by changing sbuild such that it now creates the sbuild
> > user and the BUILD_USER inside the chroot if they don't exist yet. This job
> > is usually done by sbuild-createchroot but since you are using qemu I guess
> > that you didn't use sbuild-createchroot to create the base image?
> 
> That's correct: I used autopkgtest to create the base image. :)

Since when can you use autopkgtest to create the base image? And how?

The last time I talked with the autopkgtest maintainers about a feature like
this, they were vehemently against adding any such functionality [1].

Thanks!

cheers, josch

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886332#20


signature.asc
Description: signature

Bug#906271: Still broken on 4.0.4-2

[Arnaud Loonstra]

Just noticed an updated package (4.0.4-2) was available in buster. 
However it is still broken with the same error.


Is there anything I can do to help fix this?

Rg,

Arnaud

Bug#918303: tmuxinator build depends on ruby-awesome-print that is currently not in buster

[Adrian Bunk]

Source: tmuxinator
Version: 0.12.0-3
Severity: serious
Tags: ftbfs
Control: block -1 by 888119

tmuxinator build depends on ruby-awesome-print
that is currently not in buster due to #888119.

Bug#911979: fails on chown in autopkgtest-qemu backend

[Antoine Beaupré]

On 2019-01-04 22:20:52, Johannes Schauer wrote:

[...]

> I fixed the problem by changing sbuild such that it now creates the sbuild 
> user
> and the BUILD_USER inside the chroot if they don't exist yet. This job is
> usually done by sbuild-createchroot but since you are using qemu I guess that
> you didn't use sbuild-createchroot to create the base image?

That's correct: I used autopkgtest to create the base image. :)

Thanks for the fix!

A.

-- 
Ce que les siècles des grands abatoirs nous aura appris
Devrait être inscrit au fond de toutes les écoles;
Voici l'homme: le destructeur des mondes est arrivé.
- [no one is innocent]

Bug#918302: ruby-omniauth-cas3 build depends on ruby-awesome-print that is currently not in buster

[Adrian Bunk]

Source: ruby-omniauth-cas3
Version: 1.1.4-2
Severity: serious
Tags: ftbfs
Control: block -1 by 888119

ruby-omniauth-cas3 build depends on ruby-awesome-print
that is currently not in buster due to #888119.

Bug#918300: ruby-compat-resource build depends on ruby-cheffish that is currently not in buster

[Adrian Bunk]

Source: ruby-compat-resource
Version: 12.10.5-1
Severity: serious
Tags: ftbfs buster sid
Control: block -1 by 912246

ruby-compat-resource build depends on ruby-cheffish
that is currently not in buster due to #912246.

Bug#918301: libgdk-pixbuf2.0-dev: pkg-config reports version 2.10.14 when installed version is 2.36.5-2+deb9u2

[ryan]

Package: libgdk-pixbuf2.0-dev
Version: 2.36.5-2+deb9u2
Severity: normal

Dear Maintainer,

If I run

pkg-config gtk+-3.0 --libs

I get

Package 'gdk-3.0' requires 'gdk-pixbuf-2.0 >= 2.30.0' but version of 
gdk-pixbuf-2.0 is 2.10.14

In fact version 2.36.5-2+deb9u2 is installed.  The culprit seems to be 
/usr/lib/x86_64-linux-gnu/pkgconfig/gdk-pixbuf-2.0.pc which is part of this 
package.



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

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

Versions of packages libgdk-pixbuf2.0-dev depends on:
ii  gir1.2-gdkpixbuf-2.0  2.36.5-2+deb9u2
ii  libc6 2.24-11+deb9u3
ii  libgdk-pixbuf2.0-02.36.5-2+deb9u2
ii  libglib2.0-0  2.50.3-2
ii  libglib2.0-dev2.50.3-2
ii  libpng-dev1.6.28-1
ii  libpng16-16   1.6.28-1
ii  libx11-dev2:1.6.4-3+deb9u1
ii  shared-mime-info  1.8-1+deb9u1

libgdk-pixbuf2.0-dev recommends no packages.

libgdk-pixbuf2.0-dev suggests no packages.

-- debconf-show failed

Bug#918299: python-oslo.messaging build depends on python-pyngus that is currently not in buster

[Adrian Bunk]

Source: python-oslo.messaging
Version: 8.1.0-3
Severity: serious
Tags: ftbfs
Control: block -1 by 896117 896507 897841

python-oslo.messaging build depends on python-pyngus that is currently
not in buster due to #896117, #896507 and #897841.

Bug#918298: --extract-over-symlinks missing from INFO

[積丹尼 Dan Jacobson]

Package: cpio-doc
Version: 2.12-0.1
File: /usr/share/info/cpio.info.gz
X-Debbugs-Cc: bug-c...@gnu.org

  --extract-over-symlinks   Force writing over symbolic links

is missing from the INFO version.

Also
(info "(cpio) Invoking cpio")
shows lots of whitespace when
(setq show-trailing-whitespace t)

Also the man page has a nice SYNOPSIS, unlike the INFO pages.

Bug#918297: php-services-weather build depends on php-db that is currently not in buster

[Adrian Bunk]

Source: php-services-weather
Version: 1.4.7-4
Severity: serious
Tags: ftbfs buster sid
Control: block -1 by 889532

php-services-weather build depends on php-db that is currently
not in buster due to #889532.

Bug#911979: fails on chown in autopkgtest-qemu backend

[Johannes Schauer]

Control: tag -1 + pending

Hi again,

On Fri, 04 Jan 2019 12:50:41 +0100 Johannes Schauer  wrote:
> On Fri, 26 Oct 2018 15:33:32 -0400 Antoine Beaupre  wrote:
> > I have tried to use the autopkgtest backend with the qemu server but it
> > completely failed to launch the build:
> >
> > [...]
> >
> > chown: invalid user: 'sbuild:sbuild'
> > E: Failed to set sbuild:sbuild ownership on /build
> > Failed to set up chroot
> >
> > [...]
> >
> > I can test that package with autopkgtest fine, for what that's worth, with:
> >
> > autopkgtest . -- qemu
> >
> > So this seems to be a problem specific to sbuild.
> 
> could you try adding the sbuild user and group to your qemu guest?
> 
> sbuild-createchroot is doing some customizations after running debootstrap. 
> One
> of them is to copy the sbuild user and group from the host into the chroot so
> that the user and group work with schoor. Obviously this is not necessary when
> using qemu so maybe sbuild should add a new sbuild user and group itself when
> it doesn't find them in the chroot already.

okay, I was able to reproduce this problem myself and am hoping that I ran into
the same issue as you did. What I used to test was this sbuild invocation:

   $ sbuild --chroot-mode=autopkgtest --autopkgtest-virt-server=qemu \
   > --autopkgtest-virt-server-opts=/srv/qemu/unstable-amd64-autopkgtest.qcow2

And then I got the output you quoted in your first mail:

  
+==+
  | pkg-minimal 1.0 (amd64)  Fri, 04 Jan 2019 20:37:45 
+ |
  
+==+
  
  Package: pkg-minimal
  Version: 1.0
  Source Version: 1.0
  Distribution: unstable
  Machine Architecture: amd64
  Host Architecture: amd64
  Build Architecture: amd64
  Build Type: binary
  
  qemu-system-x86_64: warning: host doesn't support requested feature: 
CPUID.01H:ECX.vmx [bit 5]
  chown: invalid user: 'sbuild:sbuild'
  E: Failed to set sbuild:sbuild ownership on /build
  Failed to set up chroot
  E: Error creating chroot session: skipping pkg-minimal

I fixed the problem by changing sbuild such that it now creates the sbuild user
and the BUILD_USER inside the chroot if they don't exist yet. This job is
usually done by sbuild-createchroot but since you are using qemu I guess that
you didn't use sbuild-createchroot to create the base image?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#918291: lintian: duplicate word check for patches goes across subjects

[Chris Lamb]

Hi Craig,

> If a patch description ends with a word and the long description starts
> with the same word, lintian incorrectly considers this a duplicate word.
> 
> For example:
>   Subject: Correct snmpwalk args in snmpcheck
> 
>   snmpcheck used the old command line arguments for snmpwalk giving an
> 
> lintian thinks "snmpcheck" is repeated, when they are different fields.

This was addressed previously in:

  https://bugs.debian.org/890100

… so this could be "fixed" by moving the Subject to the first line
from my brief re-reading of the code.

(Parsing the Subject out seems a little bit out-of-scope and error-
prone for Lintian.)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#918296: php-log build depends on php-db that is currently not in buster

[Adrian Bunk]

Source: php-log
Version: 1.12.9-2
Severity: serious
Tags: ftbfs buster sid
Control: block -1 by 889532

php-log build depends on php-db that is currently
not in buster due to #889532.

Bug#918294: openstreetmap-carto build depends on node-carto that is currently not in buster

[Adrian Bunk]

Source: openstreetmap-carto
Version: 2.45.1-1
Severity: serious
Tags: ftbfs buster sid
Control: block -1 by 872547

openstreetmap-carto build depends on node-carto that
is currently not in buster due to #872547.

Bug#918293: node-xmpp build depends on node-node-stringprep that is currently not in buster

[Adrian Bunk]

Source: node-xmpp
Version: 0.3.2-3
Severity: serious
Tags: ftbfs buster sid
Control: block -1 by 895029

node-xmpp build depends on node-node-stringprep that is currently
not in buster due to #895029.

Bug#918292: node-sshpk build depends on node-temp that is currently not in buster

[Adrian Bunk]

Source: node-sshpk
Version: 1.13.1+dfsg-1
Severity: serious
Tags: ftbfs
Control: block -1 by 834915

node-sshpk build depends on node-temp that is currently
not in buster due to #834915.

Bug#918291: lintian: duplicate word check for patches goes across subjects

[Craig Small]

Package: lintian
Version: 2.5.119
Severity: minor

If a patch description ends with a word and the long description starts
with the same word, lintian incorrectly considers this a duplicate word.

For example:
  Subject: Correct snmpwalk args in snmpcheck

  snmpcheck used the old command line arguments for snmpwalk giving an

lintian thinks "snmpcheck" is repeated, when they are different fields.

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

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

Versions of packages lintian depends on:
ii  binutils   2.31.1-11
ii  bzip2  1.0.6-9
ii  diffstat   1.62-1
ii  dpkg   1.19.2
ii  dpkg-dev   1.19.2
ii  file   1:5.34-2
ii  gettext0.19.8.1-9
ii  gpg2.2.12-1
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.34+b1
ii  libarchive-zip-perl1.64-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.41-1+b1
pn  libdigest-sha-perl 
ii  libdpkg-perl   1.19.2
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  libparse-debianchangelog-perl  1.2.0-13
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.74-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.76+repack-1
ii  man-db 2.8.4-3
ii  patchutils 0.3.4-2
ii  perl   5.28.1-3
ii  t1utils1.41-3
ii  xz-utils   5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b5

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libhtml-parser-perl3.72-3+b3
ii  libtext-template-perl  1.53-1

-- no debconf information

Bug#918290: node-postcss build depends on node-js-beautify that is currently not in buster

[Adrian Bunk]

Source: node-postcss
Version: 6.0.23-1
Severity: serious
Tags: ftbfs
Control: block -1 by 60 888903

node-postcss build depends on node-js-beautify
that is currently not in buster due to #60 and #888903.

Bug#918248: hddemux 0.4-7: FTBFS, alignment problem

[Daniel Kahn Gillmor]

Control: reassign 918248 knot-resolver
Control: affects 918248 + hddemux
Control: forwarded 918248 
https://gitlab.labs.nic.cz/knot/knot-resolver/issues/426

Hi Steve--

On Fri 2019-01-04 18:19:27 +, Steve McIntyre wrote:
> When building your package, I've found a bus error (aka alignment
> fault). The full log is online at
>
>   
> https://www.einval.com/debian/arm/rebuild-logs/armhf/FAIL/hddemux_0.4-7_armhf.log
>
> for reference.
>
> I've tried to debug this, but even after ulimit -c I can't find a core
> file anywhere. AFAICS this might be a problem in knot-resolver, but
> I'm not sure. Please reassign there if you agree.

Yes, this is presumably something like
https://gitlab.labs.nic.cz/knot/knot-resolver/issues/426 (which already
contains a comment from you!).

looks like upstream has some idea of the issue, but hasn't take steps to
fix it yet.  I'm afraid i don't have the time or knowledge to fix it
myself in short order, but i'd love to see it resolved.  Happy to
apply/test patches if anyone wants to propose them.

--dkg


signature.asc
Description: PGP signature

Bug#918289: node-autoprefixer build depends on node-js-beautify that is currently not in buster

[Adrian Bunk]

Source: node-autoprefixer
Version: 7.2.5-1
Severity: serious
Tags: ftbfs
Control: block -1 by 60 888903

node-autoprefixer build depends on node-js-beautify
that is currently not in buster due to #60 and #888903.

Bug#918288: nipype build depends on python-nipy that is currently not in buster

[Adrian Bunk]

Source: nipype
Version: 1.1.3-1
Severity: serious
Tags: ftbfs
Control: block -1 by 906388

nipype build depends on python-nipy that is currently
not in buster due to #906388.

Bug#918088: Acknowledgement (autofs-ldap: automount dies with SIGABRT after libkrb5-3 upgrade - "(k5_mutex_lock: Assertion `r == 0' failed.)")

[Sam Hartman]

So what's happening here is  that a k5_mutex_lock is getting  an invalid
argument error calling  a series of wrappers that basically all boil
down to pthread_mutex_lock.
So, basically somehow pthread_mutex_lock is getting passed a bad mutex.
This appears to be happening in the credentials cache code.

There are no thread support changes between 1.16.1 and 1.16.2.
There is one ccache related change which I'll include below related to
memory ccaches.
Do you know what type of credential cache  is being used here?

>From 6d784809fe07c2d5f60c1a692bcac08b0d40f0a7 Mon Sep 17 00:00:00 2001
From: Greg Hudson 
Date: Sun, 1 Jul 2018 00:12:25 -0400
Subject: [PATCH] Fix bugs with concurrent use of MEMORY ccaches

A memory ccache iterator stores an alias into the cache object's
linked list of credentials.  If the cache is reinitialized while the
iterator is active, the alias becomes invalid.  Also, multiple handles
referencing the same memory ccache all use aliases to the same data
object; if one of the handles is destroyed, the other contains a
dangling pointer.

Fix the first issue by adding a generation counter to the cache and to
cursors, incremented each time the cache is initialized or destroyed.
Check the generation on each cursor step and end the iteration if the
list was invalidated.  Fix the second issue by adding a reference
count to the cache object, counting one reference for the table slot
and one for each open handle.  Empty the cache object on each destroy
operation, but only release the object when the last handle to it is
destroyed or closed.

Add regression tests for the two issues to t_cc.c.

The first issue was reported by Sorin Manolache.

(cherry picked from commit 146dadec8fe7ccc4149eb2e3f577cc320aee6efb)

ticket: 8202
version_fixed: 1.16.2
---
 src/lib/krb5/ccache/cc_memory.c | 164 +---
 src/lib/krb5/ccache/t_cc.c  |  51 +
 2 files changed, 154 insertions(+), 61 deletions(-)

diff --git a/src/lib/krb5/ccache/cc_memory.c b/src/lib/krb5/ccache/cc_memory.c
index c5425eb3ae..8cdaff7fb3 100644
--- a/src/lib/krb5/ccache/cc_memory.c
+++ b/src/lib/krb5/ccache/cc_memory.c
@@ -102,18 +102,20 @@ extern krb5_error_code krb5_change_cache (void);
 typedef struct _krb5_mcc_link {
 struct _krb5_mcc_link *next;
 krb5_creds *creds;
-} krb5_mcc_link, *krb5_mcc_cursor;
+} krb5_mcc_link;
 
 /* Per-cache data header.  */
 typedef struct _krb5_mcc_data {
 char *name;
 k5_cc_mutex lock;
 krb5_principal prin;
-krb5_mcc_cursor link;
+krb5_mcc_link *link;
 krb5_timestamp changetime;
 /* Time offsets for clock-skewed clients.  */
 krb5_int32 time_offset;
 krb5_int32 usec_offset;
+int refcount;   /* One for the table slot, one per handle */
+int generation; /* Incremented at each initialize */
 } krb5_mcc_data;
 
 /* List of memory caches.  */
@@ -122,6 +124,12 @@ typedef struct krb5_mcc_list_node {
 krb5_mcc_data *cache;
 } krb5_mcc_list_node;
 
+/* Iterator over credentials in a memory cache. */
+struct mcc_cursor {
+int generation;
+krb5_mcc_link *next_link;
+};
+
 /* Iterator over memory caches.  */
 struct krb5_mcc_ptcursor_data {
 struct krb5_mcc_list_node *cur;
@@ -132,7 +140,23 @@ static krb5_mcc_list_node *mcc_head = 0;
 
 static void update_mcc_change_time(krb5_mcc_data *);
 
-static void krb5_mcc_free (krb5_context context, krb5_ccache id);
+/* Remove creds from d, invalidate any existing cursors, and unset the client
+ * principal.  The caller is responsible for locking. */
+static void
+empty_mcc_cache(krb5_context context, krb5_mcc_data *d)
+{
+krb5_mcc_link *curr, *next;
+
+for (curr = d->link; curr != NULL; curr = next) {
+next = curr->next;
+krb5_free_creds(context, curr->creds);
+free(curr);
+}
+d->link = NULL;
+d->generation++;
+krb5_free_principal(context, d->prin);
+d->prin = NULL;
+}
 
 /*
  * Modifies:
@@ -150,16 +174,12 @@ krb5_mcc_initialize(krb5_context context, krb5_ccache id, 
krb5_principal princ)
 {
 krb5_os_context os_ctx = >os_context;
 krb5_error_code ret;
-krb5_mcc_data *d;
+krb5_mcc_data *d = id->data;
 
-d = (krb5_mcc_data *)id->data;
 k5_cc_mutex_lock(context, >lock);
+empty_mcc_cache(context, d);
 
-krb5_mcc_free(context, id);
-
-d = (krb5_mcc_data *)id->data;
-ret = krb5_copy_principal(context, princ,
-  >prin);
+ret = krb5_copy_principal(context, princ, >prin);
 update_mcc_change_time(d);
 
 if (os_ctx->os_flags & KRB5_OS_TOFFSET_VALID) {
@@ -185,61 +205,59 @@ krb5_mcc_initialize(krb5_context context, krb5_ccache id, 
krb5_principal princ)
 krb5_error_code KRB5_CALLCONV
 krb5_mcc_close(krb5_context context, krb5_ccache id)
 {
-free(id);
-return KRB5_OK;
-}
-
-static void
-krb5_mcc_free(krb5_context context, krb5_ccache id)
-{
-krb5_mcc_cursor curr,next;
-krb5_mcc_data *d;
+krb5_mcc_data *d = 

Bug#918266: redis (5:5.0.3-3~bpo9+1) seems to be not built on stretch

[Niels Thykier]

Chris Lamb:
> Hi Niels,
> 
> Thanks for your input.
> 
>> As noted in [1], compat 12 is not /generally/ suitable for
>> stretch-backports
> 
> I don't see a note regarding that in your [1], namely:
> 
>   
> https://salsa.debian.org/lamby/pkg-redis/commit/e47bfc26194735b4853a6f17e29ce20b50483696
>   
> .. but point taken.
> 

Gah, copy-waste fail.  That [1] was supposed to have been
https://nthykier.wordpress.com/2019/01/04/debhelper-compat-12-is-now-released/

Sorry about that. :)

>> The alternative is to use compat 12 in general but force dh_installinit
>> + dh_installsystemd (yes, both of them) to run in compat 11 by using
>> DH_COMPAT=11 in the override.
> 
> Interesting. That's a little bit more explicit so I think I will go
> with that:
> 
>   
> https://salsa.debian.org/lamby/pkg-redis/commit/832463ab201662de5981f7afb8baa292f2cf2e28
>   
> Thanks!
> 
> 
> Best wishes,
> 

Looks good. :)

Thanks,
~Niels



signature.asc
Description: OpenPGP digital signature

Bug#918287: linux-patch-grsecurity2 build depends on dh-kpatches that is currently not in buster

[Adrian Bunk]

Source: linux-patch-grsecurity2
Version: 3.1+4.9.11-201702181444-1
Severity: serious
Tags: ftbfs
Control: block -1 by 876892

linux-patch-grsecurity2 build depends on dh-kpatches
that is currently not in buster due to #876892.

Bug#918285: makedumpfile: [INTL:pt] Portuguese translation for debconf messages

[Traduz PT]

Package: makedumpfile
Version: 1_1.6.4-3
Tags: l10n, patch
Severity: wishlist

Portuguese translation for makedumpfile's debconf messages.
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .
-- 
Best regards,

"Traduz" - Portuguese Translation Team
http://www.DebianPT.org


pt.po.gz
Description: application/gzip

Bug#918286: linux-patch-debianlogo build depends on dh-kpatches that is currently not in buster

[Adrian Bunk]

Source: linux-patch-debianlogo
Version: 1.16
Severity: serious
Tags: buster sid ftbfs
Control: block -1 by 876892

linux-patch-debianlogo build depends on dh-kpatches
that is currently not in buster due to #876892.

Bug#918266: redis (5:5.0.3-3~bpo9+1) seems to be not built on stretch

[Chris Lamb]

Hi Niels,

Thanks for your input.

> As noted in [1], compat 12 is not /generally/ suitable for
> stretch-backports

I don't see a note regarding that in your [1], namely:

  
https://salsa.debian.org/lamby/pkg-redis/commit/e47bfc26194735b4853a6f17e29ce20b50483696
  
.. but point taken.

> The alternative is to use compat 12 in general but force dh_installinit
> + dh_installsystemd (yes, both of them) to run in compat 11 by using
> DH_COMPAT=11 in the override.

Interesting. That's a little bit more explicit so I think I will go
with that:

  
https://salsa.debian.org/lamby/pkg-redis/commit/832463ab201662de5981f7afb8baa292f2cf2e28
  
Thanks!


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#918284: librdf-trine-serializer-rdfa-perl build depends on librdf-rdfa-parser-perl that is currently not in buster

[Adrian Bunk]

Source: librdf-trine-serializer-rdfa-perl
Version: 0.100-1
Severity: serious
Tags: ftbfs
Control: block -1 by 750946

librdf-trine-serializer-rdfa-perl build depends on librdf-rdfa-parser-perl
that is currently not in buster due to #750946.

Bug#918283: librdf-query-client-perl build depends on libhttp-lrdd-perl that is currently not in buster

[Adrian Bunk]

Source: librdf-query-client-perl
Version: 0.114-1
Severity: serious
Tags: ftbfs buster sid
Control: block -1 by 750946

librdf-query-client-perl build depends on libhttp-lrdd-perl
that is currently not in buster due to #750946.

Bug#918282: libokhttp-java build depends on libandroid-23-java that is currently not in buster

[Adrian Bunk]

Source: libokhttp-java
Version: 3.12.1-1
Severity: serious
Tags: ftbfs
Control: block -1 by 894285

libokhttp-java build depends on libandroid-23-java that is
currently not in buster due to #894285.