Bug#931105: unblock: python-periodictable/1.5.0-8

[Drew Parsons]

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

Please unblock package python-periodictable

This version fixes a broken doc package dependency.

It's in no way a critical bug, but it seems silly to release buster
with a known dependency bug when the fix is so trivial.

$ debdiff python-periodictable_1.5.0-7.dsc python-periodictable_1.5.0-8.dsc
diff -Nru python-periodictable-1.5.0/debian/changelog 
python-periodictable-1.5.0/debian/changelog
--- python-periodictable-1.5.0/debian/changelog 2018-12-30 09:27:41.0 
+0800
+++ python-periodictable-1.5.0/debian/changelog 2019-06-26 16:18:35.0 
+0800
@@ -1,3 +1,10 @@
+python-periodictable (1.5.0-8) unstable; urgency=medium
+
+  [ Stuart Prescott ]
+  * Fix typo in Suggests entry for documentation (Closes: #923744).
+
+ -- Drew Parsons   Wed, 26 Jun 2019 16:18:35 +0800
+
 python-periodictable (1.5.0-7) unstable; urgency=medium
 
   * Replace sphinx directives that have been removed in matplotlib 3
diff -Nru python-periodictable-1.5.0/debian/control 
python-periodictable-1.5.0/debian/control
--- python-periodictable-1.5.0/debian/control   2018-12-30 09:27:41.0 
+0800
+++ python-periodictable-1.5.0/debian/control   2019-06-26 16:18:35.0 
+0800
@@ -36,7 +36,7 @@
  ${python:Depends}
 Suggests:
  python-matplotlib,
- python-python-periodictable-doc
+ python-periodictable-doc
 Description: Extensible periodic table of the elements (Python 2)
  This package provides a periodic table of the elements with support
  for mass, density and xray/neutron scattering information.
@@ -67,7 +67,7 @@
  ${misc:Depends},
  ${python3:Depends}
 Suggests:
-  python-python-periodictable-doc,
+  python-periodictable-doc,
   python3-matplotlib
 Description: Extensible periodic table of the elements (Python 3)
  This package provides a periodic table of the elements with support


unblock python-periodictable/1.5.0-8

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

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

Bug#925312: pcscd: Does not work if "used" in wrong order

[Ludovic Rousseau]

Hello Joerg,

I have no news from you since 3 months now.
I documented the problem and solution at 
https://ludovicrousseau.blogspot.com/2019/06/gnupg-and-pcsc-conflicts.html

With no news from you I will consider that the problem is fixed with my 
solution and close this Debian bug.

Regards,

Le 24/03/2019 à 22:15, Ludovic Rousseau a écrit :

Le 24/03/2019 à 22:05, Ludovic Rousseau a écrit :

Le 24/03/2019 à 21:19, Joerg Jaspert a écrit :

On 15351 March 1977, Ludovic Rousseau wrote:


I think I found the problem.


I think my system disagrees. :)


In my case "gpg --card-status" works only if pcscd is NOT running.
GnuPG has its own way to access the smart card readers (here a yubikey)


Its a yubikey here too.


I propose two possible solutions:
1. remove pcscd from your system but that is a drastic change. No
PC/SC application will work any more.


Not a good thing, it's there for a reason.
And I know it worked in stretch.


2. configure scdaemon to NOT use its internal CCID driver but use the PC/SC 
interface instead



To make option 2 just edit/create the scdaemon configuration file as bellow:
$ cat ~/.gnupg/scdaemon.conf
disable-ccid


Done that. Doesn't do anything.

Logged out. Killed gpg agent (just in case). Rebooted (damn system,
maybe). Nope, nothing. Same behaviour as before.


:-(

Before you restart pcscd, can you see your YubiKey listed by the pcsc_scan 
command (from the pcsc-tools package)?
Does "gpg --card-status" works as expected?

Once you have restarted pcscd, can you see your YubiKey listed by the pcsc_scan 
command?
Does "gpg --card-status" works as expected?


What are the USB VendorID & ProductID of your YukiKey token?
You can just attach the output of lsusb.

Thanks




--
 Dr. Ludovic Rousseau

Bug#931110: Bluetooth

[Мухоморик Мухоморик]

Package: bluetoothctl
Version: 5.50

LXDE

Linux debian 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64
GNU/Linux

$ sudo /etc/init.d/bluetooth status
● bluetooth.service - Bluetooth service
   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor
preset: enabled)
   Active: active (running) since Wed 2019-06-26 12:08:38 MSK; 51min ago
 Docs: man:bluetoothd(8)
 Main PID: 470 (bluetoothd)
   Status: "Running"
Tasks: 1 (limit: 4915)
   Memory: 3.4M
   CGroup: /system.slice/bluetooth.service
   └─470 /usr/lib/bluetooth/bluetoothd

июн 26 12:08:33 debian systemd[1]: Starting Bluetooth service...
июн 26 12:08:34 debian bluetoothd[470]: Bluetooth daemon 5.50
июн 26 12:08:38 debian systemd[1]: Started Bluetooth service.
июн 26 12:08:38 debian bluetoothd[470]: Starting SDP server
июн 26 12:08:38 debian bluetoothd[470]: Bluetooth management interface
1…ized
июн 26 12:08:38 debian bluetoothd[470]: Sap driver initialization failed.
июн 26 12:08:38 debian bluetoothd[470]: sap-server: Operation not permit…
(1)
июн 26 12:08:38 debian bluetoothd[470]: Failed to set mode: Blocked
thro…x12)
Hint: Some lines were ellipsized, use -l to show in full.

Bug#931111: linux-image-4.9.0-9-amd64: Memory leak - fixed with 4.9.174 (or earlier)

[Philipp Hahn]

Package: linux-image-4.9.0-9-amd64
Version: 4.9.168-1+deb9u3
Severity: important

Dear fellow DDs,

we (Univention GmbH) have several reports of a memory leak wtih 4.9.168
as shipped by Debian (and used by us):

https://help.univention.com/t/memoryleak-auf-slave-contoller/11892/8
https://forge.univention.org/bugzilla/show_bug.cgi?id=49614

I was not yet able to pin-point the area where the leak occurs, but the
bug seemd to be fixed after switching to 4.9.174.a( I hand-applied the
incremental patches on top of Debians 4.9.168 fixing the rejects and
enabled KMEMLEAK.) The fix can be earlied than 174; I chose that version
from a hint given by one of our customers, who reported 174 to be fixed.

4.9.144 was also fine (at leat no leak was observed).

Stopping all processes did NOT free the memory again.
My interpretation of this is, that the leak is not in user-space, but in
kernel-land.

 does not
show any leaks so far.

One of the affected systems is a system of us, where I can do some
limited testing, e.g. install self-compiled kernel version.
As I don't have a (simple) reproducer running `git bisect` is somehow
inefficient.
So if you have any idea on what to test or where I can help just ask.


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

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

Versions of packages linux-image-4.9.0-9-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.130
ii  kmod23-2
ii  linux-base  4.5

Versions of packages linux-image-4.9.0-9-amd64 recommends:
ii  firmware-linux-free  3.4
ii  irqbalance   1.1.0-2.3

Versions of packages linux-image-4.9.0-9-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.02~beta3-5+deb9u1A~4.3.3.201812061306
pn  linux-doc-4.9   

Versions of packages linux-image-4.9.0-9-amd64 is related to:
ii  firmware-amd-graphics 20161130-5
ii  firmware-atheros  20161130-5
ii  firmware-bnx2 20161130-5
ii  firmware-bnx2x20161130-5
ii  firmware-brcm8021120161130-5
ii  firmware-cavium   20161130-5
pn  firmware-intel-sound  
ii  firmware-intelwimax   20161130-5
pn  firmware-ipw2x00  
pn  firmware-ivtv 
ii  firmware-iwlwifi  20161130-5
ii  firmware-libertas 20161130-5
ii  firmware-linux-nonfree20161130-5
ii  firmware-misc-nonfree 20161130-5
ii  firmware-myricom  20161130-5
ii  firmware-netxen   20161130-5
ii  firmware-qlogic   20161130-5
ii  firmware-realtek  20161130-5
pn  firmware-samsung  
pn  firmware-siano
ii  firmware-ti-connectivity  2016113

Bug#929527: [pkg-netfilter-team] Bug#929527: Bug#914694

[Arturo Borrero Gonzalez]

On 6/25/19 10:25 AM, Thomas Lamprecht wrote:
> Don't want to nag to much but is there any news regarding this?
> Buster is planned to release pretty soon (<2 weeks) and iptables
> is quite a important package, IMO. Maybe it went under my radar
> but I saw no unblock request on d.o release list.
> 
> For now I just used update-alternative to use the legacy variants,
> which work fine here, but if my understanding is correct then this
> package (version?) could be thrown out of Buster if it still has RC
> bug so close to the planned release, I mean iptables may be an
> exception as it's quite relevant and still used by a lot but still.
> 

The last upstream release of iptables won't make it into Debian Buster at this
point.

Once buster is released I will:

* provide uptodate package backports of newer upstream releases in
buster-backports (for both iptables and nftables)
* for important bugs, I would try backporting concrete patches to the version in
buster-stable.

Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3

[Ilias Tsitsimpis]

On Tue, Jun 25, 2019 at 09:44PM, Paul Gevers wrote:
> It helps if you can check if all the packages that you expect migrate.

Yep, everything (except for taffybar) has migrated.

Thanks,

-- 
Ilias

Bug#870814: show message if unable to play video

[積丹尼 Dan Jacobson]

OK, now it works, but how about sound? I can hear it in chromium, but
not in minibrowser.

Bug#852032: libjavascriptcoregtk-4.0-18: Segmentation fault in LLIntAssembly.h:2610 on powerpc64

[Emilio Pozuelo Monfort]

On 25/06/2019 15:05, Alberto Garcia wrote:
> On Mon, Jan 23, 2017 at 11:14:16AM +0100, Alberto Garcia wrote:
>> webkit2gtk itself builds fine, seed-webkit2 is what fails:
> 
> I wanted to test this with the latest versions of WebKitGTK, but I
> don't seem to have access to any porterbox with ppc64 (only ppc64el,
> in which things work fine).

Apparently there used to be one (pizetti) but that seems down now. Cc'ing the
ppc64 buildd maintainers, maybe they can clarify if there's another porterbox.

Emilio

Bug#931106: flang-7: fails to remove: rm: cannot remove '/usr/lib/x86_64-linux-gnu/fortran/': Is a directory

[Andreas Beckmann]

Package: flang-7
Version: 20190329-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to remove.

>From the attached log (scroll to the bottom...):

  Removing flang-7 (20190329-1) ...
  rm: cannot remove '/usr/lib/x86_64-linux-gnu/fortran/': Is a directory
  dpkg: error processing package flang-7 (--remove):
   installed flang-7 package post-removal script subprocess returned error exit 
status 1


cheers,

Andreas


flang-7_20190329-1.log.gz
Description: application/gzip

Bug#931114: cluster-glue: ibmrsa-telnet not python3 ready

[Pierre Dinh van]

Package: cluster-glue
Version: 1.0.12-12
Severity: normal

Dear Maintainer,

I just upgraded my corosync cluster to buster, and the stonith external helper 
/usr/lib/stonith/plugins/external/ibmrsa-telnet wasn't starting anymore :

Jun 26 12:02:16 nfs4-c external/ibmrsa-telnet[22786]: [22848]: ERROR: Exception 
raised: cannot use a string pattern on a bytes-like object
Jun 26 12:02:17 nfs4-c stonith: [22764]: WARN: external_status: 'ibmrsa-telnet 
status' failed with rc 1
Jun 26 12:02:17 nfs4-c stonith: [22764]: ERROR: external/ibmrsa-telnet device 
not accessible.
Jun 26 12:02:17 nfs4-c pacemaker-fenced[2062]:  warning: stonith-nfs-a:22639 [ 
Performing: stonith -t external/ibmrsa-telnet -E -S ]

I changed the #!/usr/bin/python3 to #!/usr/bin/python2 and it works back.

Looks like it's not python3 ready.

Cheers

Pierre Dinh-van


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

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

Versions of packages cluster-glue depends on:
ii  adduser   3.118
ii  bzip2 1.0.6-9
ii  libbz2-1.01.0.6-9
ii  libc6 2.28-10
ii  libcurl4  7.64.0-4
ii  libdbus-1-3   1.12.16-1
ii  libdbus-glib-1-2  0.110-4
ii  libglib2.0-0  2.58.3-2
ii  liblrm2   1.0.12-12
ii  libltdl7  2.4.6-9
ii  libopenhpi3   3.8.0-2
ii  libopenipmi0  2.0.25-2.1
ii  libpils2  1.0.12-12
ii  libplumb2 1.0.12-12
ii  libplumbgpl2  1.0.12-12
ii  libsnmp30 5.7.3+dfsg-5
ii  libssl1.1 1.1.1c-1
ii  libstonith1   1.0.12-12
ii  libtimedate-perl  2.3000-2
ii  libuuid1  2.33.1-0.1
ii  libxml2   2.9.4+dfsg1-7+b3
ii  lsb-base  10.2019051400
ii  perl  5.28.1-6
ii  python3   3.7.3-1
ii  python3.7 3.7.3-2
ii  zlib1g1:1.2.11.dfsg-1

cluster-glue recommends no packages.

Versions of packages cluster-glue suggests:
ii  ipmitool  1.8.18-6

-- no debconf information

Bug#403619: Se non verifichi il tuo account entro le prossime 24 ore, il tuo account verrà sospeso

[Giuliana.Bacia]

Aggiorna il tuo account

Il nostro record indica che il tuo account non è stato aggiornato, il che 
potrebbe comportare la chiusura del tuo account. Se non aggiorni il tuo 
account, non sarai più in grado di inviare e ricevere e-mail e inoltre ti verrà 
negato l'accesso a molte delle nostre ultime conversazioni avanzate, contatti e 
allegati.

Prenditi un minuto per aggiornare il tuo account per un'esperienza di mailing 
più veloce e completa.

Clicca qui per aggiornare il tuo account
Nota: se non si aggiorna la casella di posta elettronica, verrà cancellata 
definitivamente l'account.

Grazie molto,
Il team di sicurezza

Copyright © 2019 Webmail .Inc. Tutti i diritti riservati.

Bug#870814: show message if unable to play video

[Alberto Garcia]

On Wed, Jun 26, 2019 at 04:19:11PM +0800, 積丹尼 Dan Jacobson wrote:
> OK, now it works, but how about sound? I can hear it in chromium, but
> not in minibrowser.

Do you have gstreamer1.0-alsa and/or gstreamer1.0-pulseaudio ?

Berto

Bug#931109: libglib2.0: Memory leak when linking gobject-2.0

[Daniele E. Domenichelli]

Package: libglib2.0
Version: libglib2.0-0
Severity: normal

Dear Maintainer,

Just linking any executable with -lgobject-2.0 and running the executable
with valgrind --leak-check=full causes several warnings, I'm not sure if
these are false positives, and therefore it should be suppressed in
valgrind, or if it is an issue in the library.

This is a very quick way to reproduce the issue:

  echo "int main(){}" > /tmp/foo.c
  gcc -o /tmp/foo /tmp/foo.c -lgobject-2.0
  ldd /tmp/foo # Check that libgobject-2.0.so.0 is linked
  valgrind --leak-check=full /tmp/foo

If you remove the '-lgobject-2.0' argument, the issues disappear.

Thanks.

Regards,
 Daniele


-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'stable'), (300, 'unstable'), (150, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libglib2.0 depends on:
pn  cli-common 
ii  libc6  2.28-10
ii  libelf10.176-1.1
ii  libffi-dev 3.2.1-9
ii  libffi63.2.1-9
ii  libgcc11:9.1.0-4
ii  libglib2.0-0   2.58.3-2
ii  libglib2.0-bin 2.58.3-2
pn  libglib2.0-cil 
ii  libglib2.0-data2.58.3-2
ii  libglib2.0-dev-bin 2.58.3-2
pn  libmono-corlib4.5-cil  
pn  libmono-system4.0-cil  
ii  libmount-dev   2.33.1-0.1
ii  libmount1  2.33.1-0.1
ii  libpcre3   2:8.39-12
ii  libpcre3-dev   2:8.39-12
ii  libselinux12.8-1+b1
ii  libselinux1-dev2.8-1+b1
ii  libstdc++6 9.1.0-4
ii  pkg-config 0.29-6
ii  python33.7.3-1
ii  python3-distutils  3.7.3-1
ii  python3.7  3.7.3-2
ii  shared-mime-info   1.10-1
ii  zlib1g 1:1.2.11.dfsg-1
ii  zlib1g-dev 1:1.2.11.dfsg-1

Versions of packages libglib2.0 recommends:
ii  libglib2.0-data   2.58.3-2
ii  shared-mime-info  1.10-1
ii  xdg-user-dirs 0.17-2

Versions of packages libglib2.0 suggests:
pn  devhelp
ii  libgdk-pixbuf2.0-bin   2.38.1+dfsg-1
ii  libgdk-pixbuf2.0-dev   2.38.1+dfsg-1
pn  libglib2.0-doc 
ii  libxml2-utils  2.9.4+dfsg1-7+b3
pn  monodoc-gtk2.0-manual  

Bug#144876: 10 Ihrer eingehenden Nachrichten wurden ausgesetzt

[DONG Si-Thanh]

DRINGENDE MICROSOFT-MITTEILUNG

10 Ihrer eingehenden Nachrichten wurden jetzt gesperrt, da Ihr E-Mail-Konto 
jetzt überprüft werden muss. Überprüfen Sie 
jetzt Ihr E-Mail-Konto, um diese Nachrichten zu erhalten, die angehalten wurden.


Microsoft Verification Team



Microsoft © 2019 Webmail .Inc. Alle Rechte vorbehalten.

Bug#931117: liblemonldap-ng-portal-perl: XXE vulnerability in SOAP notification server

[Xavier Guimard]

Package: liblemonldap-ng-portal-perl
Version: 1.9.7-3
Severity: normal
Tags: security upstream

Notification server (not enabled by default) allows authorized
administrators to push XML files to notify a message to a user. Due to
#838097, XML::LibXML expands external entities by default. Then an
administrator can push a XML that allows him to read any file in server
filesystem accessible by www-data.

See https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/1818 for
more.

This issue exists in versions [>= 2.0.0, < 2.0.5] but isn't exploitable
since:
 - notification system does not use SOAP/XML by default
 - old-compatibility mode is broken is these versions

Bug#931100: ITP: r-cran-assertive.sets -- GNU R assertions to check properties of sets

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-assertive.sets -- GNU R assertions to check properties of 
sets
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-assertive.sets
  Version : 0.0
  Upstream Author : Richard Cotton
* URL : https://cran.r-project.org/package=assertive.sets
* License : GPL-3+
  Programming Lang: GNU R
  Description : GNU R assertions to check properties of sets
 A set of predicates and assertions for checking the properties of
 sets.  This is mainly for use by other package developers who want to
 include run-time testing features in their own packages.  End-users will
 usually want to use assertive directly.

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

Bug#931097: installing python3.4 fails

[Chris Lamb]

reassign 931097 python3.4
forcemerge 931044 931097
thanks

Thanks for filing this. However it was already filed as #931044 and
the issue itself was fixed in python3.4 3.4.2-1+deb8u4.

Hope that helps.


Regards,

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

Bug#931066: Info

[MaXaMaR]

After memcpy replace (just in radeonsi_dri and some other places):

maxamar@ubuntu:/var/log$ cat Xorg.0.log
[69.599]
X.Org X Server 1.20.4
X Protocol Version 11, Revision 0
[69.599] Build Operating System: Linux 4.4.0-143-generic x86_64 Ubuntu
[69.599] Current Operating System: Linux ubuntu 5.0.0-19-generic #20-Ubuntu 
SMP Wed Jun 19 17:04:04 UTC 2019 x86_64
[69.599] Kernel command line: BOOT_IMAGE=/vmlinuz-5.0.0-19-generic 
root=UUID=dd5bf364-43c0-4d36-908a-dc9b663ac1a4 ro amdgpu.dc=0 
amdgpu.si_support=1
[69.599] Build Date: 03 April 2019  09:03:57AM
[69.599] xorg-server 2:1.20.4-1ubuntu3 (For technical support please see 
http://www.ubuntu.com/support)
[69.599] Current version of pixman: 0.36.0
[69.599]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[69.599] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[69.599] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Jun 26 11:15:08 
2019
[69.599] (++) Using config file: "/root/xorg.conf.new"
[69.599] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[69.600] (==) ServerLayout "X.org Configured"
[69.600] (**) |-->Screen "Screen0" (0)
[69.600] (**) |   |-->Monitor "Monitor0"
[69.600] (**) |   |-->Device "Card0"
[69.600] (**) |-->Screen "Screen1" (1)
[69.600] (**) |   |-->Monitor "Monitor1"
[69.601] (**) |   |-->Device "Card1"
[69.601] (**) |-->Screen "Screen2" (2)
[69.601] (**) |   |-->Monitor "Monitor2"
[69.601] (**) |   |-->Device "Card2"
[69.601] (**) |-->Input Device "Mouse0"
[69.601] (**) |-->Input Device "Keyboard0"
[69.601] (==) Automatically adding devices
[69.601] (==) Automatically enabling devices
[69.601] (==) Automatically adding GPU devices
[69.601] (==) Automatically binding GPU devices
[69.601] (==) Max clients allowed: 256, resource mask: 0x1f
[69.601] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[69.601]Entry deleted from font path.
[69.601] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist.
[69.601]Entry deleted from font path.
[69.601] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist.
[69.601]Entry deleted from font path.
[69.601] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist.
[69.601]Entry deleted from font path.
[69.601] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist.
[69.601]Entry deleted from font path.
[69.601] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[69.601]Entry deleted from font path.
[69.601] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist.
[69.601]Entry deleted from font path.
[69.601] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist.
[69.601]Entry deleted from font path.
[69.601] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist.
[69.601]Entry deleted from font path.
[69.601] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist.
[69.601]Entry deleted from font path.
[69.601] (**) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/Type1,
built-ins,
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/Type1,
built-ins
[69.601] (**) ModulePath set to "/usr/lib/xorg/modules"
[69.602] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 
'vmmouse' will be disabled.
[69.602] (WW) Disabling Mouse0
[69.602] (WW) Disabling Keyboard0
[69.602] (II) Loader magic: 0x55b3e6614020
[69.602] (II) Module ABI versions:
[69.602]X.Org ANSI C Emulation: 0.4
[69.602]X.Org Video Driver: 24.0
[69.602]X.Org XInput driver : 24.1
[69.602]X.Org Server Extension : 10.0
[69.603] (--) using VT number 2

[69.603] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[69.604] (II) xfree86: Adding drm device (/dev/dri/card0)
[69.604] (II) xfree86: Adding drm device (/dev/dri/card1)
[69.638] (--) PCI:*(0@0:1:0) 1234::1af4:1100 rev 2, Mem @ 
0xf000/16777216, 0xfea14000/4096, BIOS @ 0x/131072
[69.638] (--) PCI: (1@0:0:0) 1002:67df:1da2:e366 rev 225, Mem @ 
0x6/8589934592, 0x8/2097152, 0xfe80/262144, I/O @ 
0x5000/256, BIOS @ 0x/131072
[69.638] (II) "glx" will be loaded. This was enabled by default and also 
specified in the config file.
[69.638] (II) LoadModule: "glx"
[69.638] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[69.639] (II) Module glx: vendor="X.Org Foundation"
[69.639]compiled for 1.20.4, module version = 1.0.0
[69.639]ABI 

Bug#931108: ITP: ruby-google-cloud-env -- Google Cloud Platform hosting environment information

[Samyak Jain]

Package: wnpp
Severity: wishlist
Owner: Samyak Jain 

* Package name: ruby-google-cloud-env
  Version : 1.2.0
  Upstream Author : 2004 Google APIs
* URL :
https://github.com/googleapis/google-cloud-ruby/tree/master/google-cloud-env
* License : Apache-2.0
  Programming Lang: Ruby
  Description : Google Cloud Platform hosting environment information

  This library provides information on the application hosting environment for
  apps running on Google Cloud Platform. This library is supported on Ruby 2.3+.
  Google provides official support for Ruby versions that are actively supported
  by Ruby Core—that is, Ruby versions that are either in normal maintenance or
  in security maintenance, and not end of life.


It is a dependency for google-cloud-core, loomio and hence needs to be packaged.

Thanks,
Samyak Jain

Bug#931107: hdparm -I /dev/sda turns system unusable

[Schnieders, Siegfried]

Package: hdparm
Version: 9.58+ds-1

When I issue the command

hdparm -I /dev/sda

I get

ATA device, with non-removable media
Model Number:   2.5" SATA SSD 3SE
Serial Number:  20140430AA000263
Firmware Revision:  S130710
Transport:  Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA 
Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
Supported: 8 7 6 5
Likely used: 8
Configuration:
Logical max current
cylinders   16383   16383
heads   16  16
sectors/track   63  63
--
CHS current addressable sectors:16514064
LBAuser addressable sectors:31277232
LBA48  user addressable sectors:31277232

Then after about 30 seconds I get kernel messages and additional output from 
hdparm:

[  106.761031] ata1.01: revalidatin failed (errno=-5)
[  129.285000] ata1.01: revalidatin failed (errno=-5)
[  173.316994] ata1.01: revalidatin failed (errno=-5)
SG_IO: bad/missing sense data, sb[]: [  185.648280]: print_req_error: I/O 
error, dev sda, sector 2048
... more Buffer I/O error and print_req_error ...
[  185.625550] Aborting journal on device sda1-8
... more Buffer I/O error and print_req_error ...
[  185.652707] Ext4-fs (sda1): previous I/O error to superblock detected
... more Buffer I/O error and print_req_error ...
[  185.652840] JDB2: Error -5 detected when updating journal superblock for 
sda1-8
[  185.653050] Ext4-fs error (device sda1): ext4_journal_check_start:61: 
Detected aborted journal
[  185.653052] Ext4-fs (sda1): Remounting file system read-only
... more Buffer I/O error and print_req_error ...
[  185.653096] Ext4-fs (sda1): I/O error while writing superblock
... more Buffer I/O error and print_req_error ...
70 00 05 00 00 00 00 0a 00 40 50 00 21 04 00 ... 00
Logical  Sector size:   512 bytes
... more hdparm information ...
Checksum correct.

Afterwards the system is unusable. I only can halt it (with magic SysRq). 
Restart works fine.

The problem was reproducible with another SSD of the same type, and with the 
SSD in another computer.

Additional information can be found at 
https://sourceforge.net/p/hdparm/bugs/84/.

I am using Debian GNU/Linux 10 Buster installed from the "Debian Installer 
Buster RC 1 release" with libc6 2.28-8.
# uname -a
Linux ks2 4.19.0-4-686-pae #1 SMP Debian 4.19.28-2 (2019-03-15) i686 GNU/Linux


--

Dipl.-Math. Siegfried Schnieders
Systemengineering

ATM ComputerSysteme GmbH
Max-Stromeyer-Straße 116
78467 Konstanz

T: +49 7531 808 4248
F: +49 7531 808 4363
siegfried.schnied...@atm-computer.de
www.atm-computer.de




ATM ComputerSysteme GmbH
Sitz der Gesellschaft ist Konstanz
Registergericht: Amtsgericht Freiburg i. BR. HRB 381 906
Geschäftsführer: Friedhelm Lachenmaier
Umsatzsteueridentifikationsnummer gemäß Paragraph 27a
Umsatzsteuergesetz: DE 214 356 925

Bug#929272: kaspersky av

[Oguz Yilmaz]

Kaspersky AV also has detected the same file as UDS:Trojan.Win32.Inject
asof June 26, 2019.

Bug#931097: unattended-upgrades: InvalidURL(f"URL can't contain control characters. {url!r} "

[Bálint Réczey]

Control: tags -1 moreinfo unreproducible

Hi,

duncanwebb  ezt írta (időpont: 2019. jún.
26., Sze, 10:05):
>
> Package: unattended-upgrades
> Version: 0.83.3.2+deb8u1
> Severity: serious
> Justification: normal
>
> Dear Maintainer,
>
> Jessie uses python 3.4 and python 3.4 does not support f"" strings
>
> So now unattended upgrades no longer performs security upgrades.
>
> /etc/cron.daily/apt:
> Traceback (most recent call last):
>   File "/usr/bin/unattended-upgrade", line 55, in 
> import apt
>   File "/usr/lib/python3/dist-packages/apt/__init__.py", line 26, in 
> from apt.package import Package
>   File "/usr/lib/python3/dist-packages/apt/package.py", line 32, in 
> from http.client import BadStatusLine
>   File "/usr/lib/python3.4/http/client.py", line 1014
> raise InvalidURL(f"URL can't contain control characters. {url!r} "
>  ^
> SyntaxError: invalid syntax
>
> The problem is in the file /usr/lib/python3.4/http/client.py, changing (f"URL 
> to ("URL will
> will allow unattended-upgrades to work again but doesn't do what is intended.

Seems to be working for me:

root@j:~# unattended-upgrade --dry-run --verbose
Initial blacklisted packages:
Initial whitelisted packages:
Starting unattended upgrades script
Allowed origins are: ['origin=Debian,codename=jessie,label=Debian-Security']
No packages found that can be upgraded unattended
root@j:~# dpkg -l unattended-upgrades
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version
  ArchitectureDescription
+++--===-===-=
ii  unattended-upgrades
0.83.3.2+deb8u1 all
automatic installation of security upgrades

>
> -- System Information:
> Debian Release: 8.10
>   APT prefers oldstable
>   APT policy: (500, 'oldstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.9.0-0.bpo.5-amd64 (SMP w/32 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages unattended-upgrades depends on:
> ii  apt1.0.9.8.5
> ii  apt-utils  1.0.9.8.5
> ii  debconf [debconf-2.0]  1.5.56+deb8u1
> ii  init-system-helpers1.22
> ii  lsb-base   4.1+Debian13+nmu1
> ii  lsb-release4.1+Debian13+nmu1
> ii  python33.4.2-2

root@j:~# dpkg -l python3.4
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version
  ArchitectureDescription
+++--===-===-=
ii  python3.4
3.4.2-1+deb8u4  amd64
Interactive high-level object-oriented language (version 3.4)

Your python3.4 version seem to be newer than mine. Probably it
introduced a regression.
Please seek for help at the source of this package.

Cheers,
Balint

> ii  python3-apt0.9.3.12
> ii  ucf3.0030
> ii  xz-utils   5.1.1alpha+20120614-2+b3
>
> unattended-upgrades recommends no packages.
>
> Versions of packages unattended-upgrades suggests:
> ii  bsd-mailx  8.1.2-0.20141216cvs-2
> ii  exim4-daemon-light [mail-transport-agent]  4.84.2-2+deb8u5
>
> -- debconf-show failed
>

Bug#931116: btrfs-progs fails to build using git tarball

[Михаил Новоселов]

Package: btrfs-progs
Version: 5.1

I have updated the letest Debian Experimental package btrfs-progs to 
5.1.1 from 5.1, but took the tarball from Github.


To make the build work, I had to:

--- a/btrfs-progs-5.1.1/debian/rules
+++ b/btrfs-progs-5.1.1/debian/rules
@@ -15,10 +15,11 @@ CFLAGS := $(patsubst -O2,-Os,$(CFLAGS))
 %:
    dh ${@} --with bash-completion,python3

-override_dh_autoreconf:
-   dh_autoreconf ./autogen.sh
+#override_dh_autoreconf:
+#  dh_autoreconf ./autogen.sh

 override_dh_auto_configure:
+   dh_autoreconf ./autogen.sh


Otherwise got an error:
Makefile:47: *** Makefile.inc not generated, please configure first.  Stop.

--
--
С уважением,
Михаил Новоселов | mikhail...@dumalogiya.ru | https://nixtux.ru

Bug#931098: convert googletest and googletest-tools to Architecture: all + Multi-Arch: foreign

[Helmut Grohne]

Source: googletest
Version: 1.8.1-3
Tags: patch

I noticed that googletest and googletest-tools are Architecture:any and
Multi-Arch:same, but their contents are bit-identical accross all
release architectures. Their dependecies are Multi-Arch: foreign or
annotated :any. Thus these packages can safely be converted to
Architecture: all. Doing so saves around 8MB on the mirros and removes
any potential M-A:same version skews from these packages. A little care
must be taken to converted ${binary:Version} dependencies to
${source:Version} and for the dh_install override, but this looks
manageable. Please consider applying the attached patch.

Helmut
diff -Nru googletest-1.8.1/debian/changelog googletest-1.8.1/debian/changelog
--- googletest-1.8.1/debian/changelog   2019-01-12 22:42:59.0 +0100
+++ googletest-1.8.1/debian/changelog   2019-06-26 09:31:25.0 +0200
@@ -1,3 +1,11 @@
+googletest (1.8.1-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert googletest and googletest-tools to Architecture:all and
+Multi-Arch:foreign. Closes: #-1.
+
+ -- Helmut Grohne   Wed, 26 Jun 2019 09:31:25 +0200
+
 googletest (1.8.1-3) unstable; urgency=medium
 
   [ Steven Robbins ]
diff -Nru googletest-1.8.1/debian/control googletest-1.8.1/debian/control
--- googletest-1.8.1/debian/control 2019-01-12 22:42:59.0 +0100
+++ googletest-1.8.1/debian/control 2019-06-26 09:31:25.0 +0200
@@ -10,8 +10,8 @@
 Vcs-Browser: https://salsa.debian.org/debian/googletest
 
 Package: googletest
-Architecture: any
-Multi-Arch: same
+Architecture: all
+Multi-Arch: foreign
 Section: libdevel
 Depends: ${misc:Depends}
 Conflicts: libgtest-dev (<< 1.8.0), google-mock (<< 1.8.0)
@@ -53,8 +53,8 @@
  C++ code under test.
 
 Package: googletest-tools
-Architecture: any
-Multi-Arch: same
+Architecture: all
+Multi-Arch: foreign
 Section: libdevel
 Depends: ${misc:Depends}, python:any
 Conflicts: googletest (<= 1.8.0-8)
@@ -67,7 +67,7 @@
 Architecture: any
 Multi-Arch: same
 Section: libdevel
-Depends: ${misc:Depends}, googletest (= ${binary:Version})
+Depends: ${misc:Depends}, googletest (= ${source:Version})
 Conflicts: googletest (<= 1.8.0-8)
 Replaces: googletest (<= 1.8.0-8)
 Description: Google's framework for writing C++ tests
@@ -109,7 +109,7 @@
 Architecture: any
 Multi-Arch: same
 Section: oldlibs
-Depends: ${misc:Depends}, googletest (= ${binary:Version})
+Depends: ${misc:Depends}, googletest (= ${source:Version})
 Description: Google's framework for writing and using C++ mock classes
  NOTE: This is a transitional package, retained for backwards compatibility.
  New code should instead use either package libgmock-dev (for compiled lib)
diff -Nru googletest-1.8.1/debian/rules googletest-1.8.1/debian/rules
--- googletest-1.8.1/debian/rules   2019-01-12 22:42:59.0 +0100
+++ googletest-1.8.1/debian/rules   2019-06-26 09:31:25.0 +0200
@@ -33,7 +33,7 @@
cd obj-* && ctest || (cat Testing/Temporary/LastTest.log; exit 1)
 endif
 
-override_dh_install:
+override_dh_install-indep:
dh_install
find debian/googletest/usr/src/googletest -iname autom4te.cache -type d 
| xargs rm -rf
find debian/googletest/usr/src/googletest -iname LICENSE -o -iname 
.gitignore -o -iname '*.pyc' | xargs rm

Bug#870814: show message if unable to play video

[積丹尼 Dan Jacobson]

OK I installed gstreamer1.0-alsa and now I can hear the video too!

Bug#931103: ITP: r-cran-discriminer -- GNU R tools of the trade for discriminant analysis

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-discriminer -- GNU R tools of the trade for discriminant 
analysis
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-discriminer
  Version : 0.1
  Upstream Author : Gaston Sanchez,
* URL : https://cran.r-project.org/package=DiscriMiner
* License : GPL-3
  Programming Lang: GNU R
  Description : GNU R tools of the trade for discriminant analysis
 Functions for Discriminant Analysis and Classification purposes
 covering various methods such as descriptive, geometric, linear, quadratic,
 PLS, as well as qualitative discriminant analyses

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

Bug#870814: show message if unable to play video

[Alberto Garcia]

On Wed, Jun 26, 2019 at 04:48:57PM +0800, 積丹尼 Dan Jacobson wrote:

> OK I installed gstreamer1.0-alsa and now I can hear the video too!

Ok, the package recommends gstreamer1.0-pulseaudio | gstreamer1.0-alsa,
and either one is enough to be able to play sound (of course if you use
the former you need to have pulseaudio installed and running).

So what I'm going to do is recommend gstreamer1.0-libav as well, and
with that we'd have all packages necessary to play videos, so we can
close this bug. Does that sound fine?

Berto

Bug#894880: ruby-graphviz: please use HOME (or do not override) instead of G_HOME

[Iain Lane]

Control: severity -1 minor

On Thu, Apr 05, 2018 at 09:07:09AM +0100, Simon McVittie wrote:
> Package: ruby-graphviz
> Version: 1.2.3-1
> Severity: normal
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: g-home
> 
> ruby-graphviz has this in d/rules:
> 
> > # Tests try to read /root/.pangorc and fail if we don't set this variable.
> > # See #570313 for more details
> > export G_HOME=/
> 
> […]
> Please investigate whether this is still needed, and if it is, set HOME=/
> instead.

I just test-built with libglib2.0-0 2.60.4-1 from experimental. This
version of glib2.0 does not respect G_HOME. The build ran the upstream
testsuite, and it all passed, so I believe the above portion of
debian/rules is likely to be obsolete and can be removed.

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: PGP signature

Bug#718035: get-orig-source is not policy compliant

[Gianfranco Costamagna]

control: fixed -1 0.1.4-2
control: close -1

G.
On Sun, 28 Jul 2013 11:13:48 +0800 Thomas Goirand  wrote:
> Package: python-mimeparse
> Version: 0.1.4-1
> Severity: important
> 
> Here's the FTP masters remark after validating mimeparse 0.1.4. Please fix
> this problem on the next upload.
> 
>  Original Message 
> Subject: Comments regarding python-mimeparse_0.1.4-1_amd64.changes
> Date: Sat, 27 Jul 2013 23:33:33 +
> From: Paul Richards Tagliamonte 
> To: Mathias Ertl ,  
> CC: Debian FTP Masters 
> 
> Howdy, maintainer,
> 
> Please either fix or remove the get-orig-source line; from
> the policy - section 4.9:
> 
>   This target may be invoked in any directory, and should take care to clean
>   up any temporary files it may have left.
> 
> Clearly, uscan can't be invoked in any directory :)
> 
> It's optional, so I'm letting it through, (and since this target is also
> broken
> in the archive.) It'd be nice to get that fixed quickly, though! :)
> 
> Cheers,
>   Paul
> 
> 

Bug#929469: systemd-networkd: systemd-networkd: fails with "could not set address: Permission denied"

[Felipe Sateler]

On Tue, Jun 25, 2019, 17:12 Michael Biebl  wrote:

> Control: severity -1 important
>
> Hi Raphael
>
> On Wed, 19 Jun 2019 22:33:21 +0200 Michael Biebl  wrote:
> > Hi Raphael,
> >
> > On Tue, 11 Jun 2019 15:51:14 +0200 Raphael Hertzog 
> > wrote:
> > > Hi,
> > >
> > > On Wed, 05 Jun 2019, Michael Biebl wrote:
> > > > systemd-networkd.service in v241 is locked down more tightly then
> v232.
> > > > It might be worth a try to comment out the hardening features one by
> one
> > > > to see if one of them causes your problem.
> > >
> > > Thanks for the idea! I tried that but it did not help. I found the
> issue
> > > after a few more tries tweaking the network configuration file. It's
> > > simply that the system has IPv6 disabled in the kernel policy while the
> > > .network file instructs to configure an IPv6 address.
> > >
> > > Both are contradictory but they happily lived together up-to-now.
> > > I don't know what changed but if we don't improve systemd-networkd
> > > to just skip IPv6 configuration when the kernel has a policy disabling
> > > IPv6, then we will have plenty of servers broken on upgrades because
> > > it's quite common to keep the network configuration file provided by
> > > the hoster and just disable IPv6 at the kernel level with sysctl:
> > >
> > > $ grep ipv6 /etc/sysctl.conf
> > > # Disable ipv6
> > > net.ipv6.conf.all.disable_ipv6 = 1
> > > net.ipv6.conf.default.disable_ipv6 = 1
> > > net.ipv6.conf.lo.disable_ipv6 = 1
> >
> > Ok, thanks for figuring out the root cause.
> > Given that this only happens under very special circumstances and
> > networkd not being enabled by default, I'm not entirely sure if this
> > issue should qualify as RC.
> > Cherry-picking the 6 upstream commits leads to a merge conflict when
> > applied on top of v241 and I haven't yet investigated if those can
> > easily be resolved.
> > TBH, I feel a bit uneasy doing this change so late in the release cycle
> > and personally I would downgrade this issue to non-RC and fix this via a
> > v243 upload to buster-backports.
> >
> > If you feel strongly about this though, please feel free ask the release
> > team if the change is ok. A tested patch set would be great in this case.
>
> I haven't heard back from you and my current gut feeling is that this
> issue is not RC, so I'm downgrading it to important.
> I'm open to be persuaded otherwise though.
>
> Whether we are going to fix this via a stable point release or
> stretch-backports remains to be decided. The latter is easier for me, as
> it doesn't mean all the administrative overhead of a stable upload.
>

Perhaps the problem can be mitigated by a NEWS or release guide update.

Honestly, I don't think networkd should keep quiet about ipv6 being
disabled when you explicitly set up an ipv6 address.

Saludos

>

Bug#929527: [pkg-netfilter-team] Bug#929527: Bug#914694

[Thomas Lamprecht]

On 6/26/19 2:14 PM, Arturo Borrero Gonzalez wrote:
> On 6/25/19 10:25 AM, Thomas Lamprecht wrote:
>> Don't want to nag to much but is there any news regarding this?
>> Buster is planned to release pretty soon (<2 weeks) and iptables
>> is quite a important package, IMO. Maybe it went under my radar
>> but I saw no unblock request on d.o release list.
>>
>> For now I just used update-alternative to use the legacy variants,
>> which work fine here, but if my understanding is correct then this
>> package (version?) could be thrown out of Buster if it still has RC
>> bug so close to the planned release, I mean iptables may be an
>> exception as it's quite relevant and still used by a lot but still.
>>
> 
> The last upstream release of iptables won't make it into Debian Buster at this
> point.
> 
> Once buster is released I will:
> 
> * provide uptodate package backports of newer upstream releases in
> buster-backports (for both iptables and nftables)
> * for important bugs, I would try backporting concrete patches to the version 
> in
> buster-stable.
> 
> 

Hmm, but that's a grave issue which may just render the firewall void
for _any_ intermediate chain and produces segmentation faults errors.

How about a minimal patch which places higher update-alternative priority
to the the -legacy parts of iptables so that the alternative currently
working in Buster is used by default. Once the fixed nft based is rolled
out the priorities could then be switched again (or if that cannot be done
for a stable release, in Bullseye).

Bug#931097: unattended-upgrades: InvalidURL(f"URL can't contain control characters. {url!r} "

[duncanwebb]

Package: unattended-upgrades
Version: 0.83.3.2+deb8u1
Severity: serious
Justification: normal

Dear Maintainer,

Jessie uses python 3.4 and python 3.4 does not support f"" strings

So now unattended upgrades no longer performs security upgrades.

/etc/cron.daily/apt:
Traceback (most recent call last):
  File "/usr/bin/unattended-upgrade", line 55, in 
import apt
  File "/usr/lib/python3/dist-packages/apt/__init__.py", line 26, in 
from apt.package import Package
  File "/usr/lib/python3/dist-packages/apt/package.py", line 32, in 
from http.client import BadStatusLine
  File "/usr/lib/python3.4/http/client.py", line 1014
raise InvalidURL(f"URL can't contain control characters. {url!r} "
 ^
SyntaxError: invalid syntax

The problem is in the file /usr/lib/python3.4/http/client.py, changing (f"URL 
to ("URL will
will allow unattended-upgrades to work again but doesn't do what is intended.

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

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

Versions of packages unattended-upgrades depends on:
ii  apt1.0.9.8.5
ii  apt-utils  1.0.9.8.5
ii  debconf [debconf-2.0]  1.5.56+deb8u1
ii  init-system-helpers1.22
ii  lsb-base   4.1+Debian13+nmu1
ii  lsb-release4.1+Debian13+nmu1
ii  python33.4.2-2
ii  python3-apt0.9.3.12
ii  ucf3.0030
ii  xz-utils   5.1.1alpha+20120614-2+b3

unattended-upgrades recommends no packages.

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx  8.1.2-0.20141216cvs-2
ii  exim4-daemon-light [mail-transport-agent]  4.84.2-2+deb8u5

-- debconf-show failed

Bug#930803: new program: runcached

[Andras Korn]

On Tue, Jun 25, 2019 at 08:22:12PM +0200, Nicolas Schier wrote:

Hi,

> > I just wrote this script:
> > https://gist.github.com/akorn/51ee2fe7d36fa139723c851d87e56096 and thought
> > it might be a good addition to moreutils.
> > 
> > It caches the stdout, stderr and exit status of arbitrary commands for a
> > configurable length of time, returning data from cache on subsequent
> > invocations if the cache is still fresh.
> 
> thanks for your suggestion; I think it's quite an interesting idea!
> And you made me curious:  which commands are you running through
> 'runcached'?  All programs I thought of have their basic functionality
> based on side-effects as file system or network access.

Examples:

 * I have a Makefile to regenerate the data.cdb file for tinydns whenever
   any of the local source files changed. Part of the process is downloading
   some remote DNS zones with axfr-get, which is relatively slow. The remote
   zones don't change frequently; I don't want to download them each time,
   but I do want to download them at least once every eight hours or so. So
   I run axfr-get via runcached, with a cache ttl of 8 hours.

 * Some monitoring systems like Zabbix and Munin need to run data-gathering
   stuff that is time-consuming; it sometimes happens that several plugins
   need to run the same thing, but extract different data from its output.
   Instead of having separate, ad-hoc caching in all such plugins, it's
   better to have a generic caching solution.

 * When looking for space hogs in the filesystem, I often use
   'du -hscx * .* | sort -h' and then dig down further. Without runcached
   I would have to either save the output separately, or keep opening new
   sessions in screen(1), or wait for the same output to be generated again,
   when I go up to the higher level directory again. With runcached, `du` is
   cheap the 2nd time, and I don't care if the numbers are slightly off when
   they come from the cache.

 * Same for ad-hoc log analysis sessions: I may grep through a bunch of
   logs, then grep for something else, then grep for the same thing again.
   With runcached, I don't need to worry about saving output I may need
   again, because runcached does it for me.

> > It currently has semi-esoteric dependencies: it's written in zsh and uses
> > chpst from the runit package for locking. If you're willing to include the
> > script I can change it to use flock(1) instead, but I'm not rewriting it in
> > POSIX sh.
> 
> Adding new scripts to the moreutils collection is usually done by
> forwarding to the upstream maintainer (Joey Hess ) and
> asking for script inclusion.  But, as Joey keeps more than just one eye
> on cross platform compatibility, I expect non-POSIX implementations to
> be rejected.  Do you keep your non-POSIX statement?

I modified it to use zsh's system module for locking, but I'm sticking with
zsh; I have no interest in rewriting it in plain Bourne sh. zsh isn't much
less cross-platform than, say, perl or Python.

The --prune-cache functionality probably depends on GNU find(1).

I'm offering the script in the belief that it might be useful to others, but
getting it into moreutils is no priority for me.

> Did you think about the license you want to stick it to? GPL2+?

I was thinking GPLv3+, but if the rest of moreutils is GPL2+, I'm fine with
that too.

András

-- 
A synonym is a word you use when you can't spell the other one.

Bug#931115: openjdk-11-jre-headless: please add Breaks: libequinox-osgi-java (<< 3.9.1)

[Andreas Beckmann]

Package: openjdk-11-jre-headless
Version: 11.0.3+7-5
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

With the Breaks against eclipse in place, another related package shows
upgrade problems from stretch. This should be solvable by adding yet
another Breaks ...


Andreas


eclipse-wtp_None.log.gz
Description: application/gzip

Bug#929611: Update

[Xavier]

Hi all,

I updated my debdiff due to a little security hole discovered in
lemonldap-ng 1.9.x

Cheers,
Xavier
diff --git a/debian/changelog b/debian/changelog
index a1fe37b..e1e20aa 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+lemonldap-ng (1.9.7-3+deb9u2) stretch; urgency=medium
+
+  * Fix CDA regression introduced in 1.9.7-3+deb9u1
+  * Fix XXE vulnerability (Closes: #931117)
+
+ -- Xavier Guimard   Wed, 26 Jun 2019 13:46:13 +0200
+
 lemonldap-ng (1.9.7-3+deb9u1) stretch-security; urgency=medium
 
   * Add patch to fix token security (Closes: #928944, CVE-2019-12046)
diff --git a/debian/patches/CDA-regression.patch 
b/debian/patches/CDA-regression.patch
new file mode 100644
index 000..242ce9c
--- /dev/null
+++ b/debian/patches/CDA-regression.patch
@@ -0,0 +1,62 @@
+Description: CDA regression fix
+ Fix for #928944 (CVE-2019-12046) introduced a regression in cross-domain
+ feature. This diff fix it and fix also a little issue when portal is called
+ using an Ajax request: it must not send Access-Control-Allow-Origin header.
+ (https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/1519)
+Author: Clément Oudot 
+Origin: upstream, 
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/commit/deff50f072c64898d1204daa28c01fdcc7275ea4
+Bug: https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/1756
+Bug-Debian: https://bugs.debian.org/928944
+Forwarded: not-needed
+Reviewed-By: Guilhem Moulin 
+Last-Update: 2019-05-27
+
+--- a/lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Simple.pm
 b/lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Simple.pm
+@@ -1049,7 +1049,7 @@
+ 
+ }
+ 
+-## @method void updateSession(hashRef infos, string id)
++## @method void updateSession(hashRef infos, string id, string kind)
+ # Update session stored.
+ # If no id is given, try to get it from cookie.
+ # If the session is available, update datas with $info.
+@@ -1057,9 +1057,10 @@
+ # server local cache, if there are several LL::NG servers.
+ # @param infos hash reference of information to update
+ # @param id Session ID
++# @param kind Session kind
+ # @return nothing
+ sub updateSession {
+-my ( $self, $infos, $id ) = @_;
++my ( $self, $infos, $id, $kind ) = @_;
+ 
+ # Return if no infos to update
+ return () unless ( ref $infos eq 'HASH' and %$infos );
+@@ -1084,7 +1085,7 @@
+ }
+ 
+ # Update session in global storage
+-if ( my $apacheSession = $self->getApacheSession( $id, 1 ) ) {
++if ( my $apacheSession = $self->getApacheSession( $id, 1, undef, 
$kind ) ) {
+ 
+ # Store updateTime
+ $infos->{updateTime} = strftime( "%Y%m%d%H%M%S", localtime() );
+@@ -1569,7 +1570,6 @@
+ print $self->header(
+ -status=> '401 Unauthorizated',
+ '-WWW-Authenticate'=> "SSO $self->{portal}",
+-'-Access-Control-Allow-Origin' => '*',
+ );
+ $self->quit;
+ }
+@@ -2744,7 +2744,7 @@
+ $cdaInfos->{cookie_name} = $self->{cookieName} . "http";
+ }
+ 
+-$self->updateSession( $cdaInfos, $cdaSession->id );
++$self->updateSession( $cdaInfos, $cdaSession->id, 'CDA' );
+ 
+ $self->{urldc} .=
+ ( $self->{urldc} =~ /\?/ ? '&' : '?' )
diff --git a/debian/patches/fix-xxe-vulnerability.patch 
b/debian/patches/fix-xxe-vulnerability.patch
new file mode 100644
index 000..90d8b90
--- /dev/null
+++ b/debian/patches/fix-xxe-vulnerability.patch
@@ -0,0 +1,19 @@
+Description: Fix XXE vulnerability
+ Due to #838097, XML::LibXML expands external entities by default. In
+ lemonldap-ng, this permits to an administrator allowed to create
+ notifications to access to server filesystem.
+Author: Xavier Guimard 
+Forwarded: https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/commit/5cbdaf7a
+Last-Update: 2019-06-26
+
+--- a/lemonldap-ng-common/lib/Lemonldap/NG/Common/Notification.pm
 b/lemonldap-ng-common/lib/Lemonldap/NG/Common/Notification.pm
+@@ -44,7 +44,7 @@
+ }
+ 
+ # Initiate XML parser
+-$parser = XML::LibXML->new();
++$parser = XML::LibXML->new( load_ext_dtd => 0, expand_entities => 0 );
+ 
+ return $self;
+ }
diff --git a/debian/patches/series b/debian/patches/series
index b13b6df..eb00970 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -3,3 +3,5 @@ avoid-modify-sources.patch
 replace-mouse-by-moose.patch
 Avoid-developer-tests.patch
 CVE-2019-12046.patch
+CDA-regression.patch
+fix-xxe-vulnerability.patch

Bug#930728: pg_cltlcluster leaks logfile descriptor into PostgreSQL backends

[Christoph Berg]

Re: Andrey Borodin 2019-06-19 
<4178a7b3-b742-49d7-afa9-fcb3439a0...@yandex-team.ru>
> On my observation - yes, descriptor 4 is no longer in lsof.

Ah, I had not noticed the "4" before. Only 1 and 2 are expected.
We can simply close() that one after dup2()'ing it to stdout/stderr.

Thanks for spotting!

Christoph

Bug#931121: qtscrob FTCBFS: missing Build-Depends qt5-qmake:native for running lrelease

[Helmut Grohne]

Source: qtscrob
Version: 0.11+git-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

qtscrob fails to cross build from source, because it fails running
lrelease in the absence of a build dependency on qt5-qmake:native. This
dependency is required for using lrelease. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru qtscrob-0.11+git/debian/changelog 
qtscrob-0.11+git/debian/changelog
--- qtscrob-0.11+git/debian/changelog   2018-08-25 19:05:36.0 +0200
+++ qtscrob-0.11+git/debian/changelog   2019-06-26 17:28:13.0 +0200
@@ -1,3 +1,9 @@
+qtscrob (0.11+git-6) UNRELEASED; urgency=medium
+
+  * Fix FTCBFS: Missing Build-Depends qt5-qmake for lrelease. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 26 Jun 2019 17:28:13 +0200
+
 qtscrob (0.11+git-5) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru qtscrob-0.11+git/debian/control 
qtscrob-0.11+git/debian/control
--- qtscrob-0.11+git/debian/control 2018-08-25 19:05:36.0 +0200
+++ qtscrob-0.11+git/debian/control 2019-06-26 17:28:12.0 +0200
@@ -2,7 +2,7 @@
 Section: sound
 Priority: optional
 Maintainer: Debian QA Group 
-Build-Depends: debhelper (>= 11), qtbase5-dev, qttools5-dev-tools, libmtp-dev, 
pkg-config
+Build-Depends: debhelper (>= 11), qtbase5-dev, qttools5-dev-tools, libmtp-dev, 
pkg-config, qt5-qmake:native
 Standards-Version: 4.2.0
 Homepage: http://qtscrob.sourceforge.net/
 Vcs-Browser: https://salsa.debian.org/debian/qtscrob

Bug#931120: morris FTCBFS: does not pass --host to ./configure

[Helmut Grohne]

Source: morris
Version: 0.2-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

morris fails to cross build from source, because it does not pass --host
to ./configure. The easiest way of fixing that - using dh_auto_configure
- does not work for morris, because its configure does not like
--runstatedir. Thus we have to manually construct the --host flag.
Please consider applying the attached patch to make morris cross
buildable.

Helmut
diff --minimal -Nru morris-0.2/debian/changelog morris-0.2/debian/changelog
--- morris-0.2/debian/changelog 2018-09-13 18:54:58.0 +0200
+++ morris-0.2/debian/changelog 2019-06-26 17:26:53.0 +0200
@@ -1,3 +1,10 @@
+morris (0.2-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass --host to ./configure. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 26 Jun 2019 17:26:53 +0200
+
 morris (0.2-5) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru morris-0.2/debian/rules morris-0.2/debian/rules
--- morris-0.2/debian/rules 2018-09-13 18:54:58.0 +0200
+++ morris-0.2/debian/rules 2019-06-26 17:26:51.0 +0200
@@ -5,6 +5,9 @@
 
 include /usr/share/dpkg/default.mk
 
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+CROSS=--build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE)
+endif
 CPPFLAGS:=$(shell dpkg-buildflags --get CPPFLAGS)
 CFLAGS:=$(shell dpkg-buildflags --get CFLAGS)
 CXXFLAGS:=$(shell dpkg-buildflags --get CXXFLAGS)

Bug#927369: network-manager: The NetworkManager process continues to consume increasing amounts of memory on a dhcp client events

[Michael Biebl]

Control: fixed -1 1.8.0-1

On Thu, 18 Apr 2019 10:34:42 -0400 Artem Panfilov
 wrote:
> Package: network-manager
> Version: 1.6.2-3+deb9u2
> Severity: important
> Tags: patch
> 
> Description of problem: NetworkManager is consuming hugh memory when dhclient
> invoke nm-dhcp-wrapper.
> 
> How to reproduce:
> To repoduce the issue you have to call a dhclient in the loop to simulate dhcp
> events:
> dhclient -q -sf /usr/lib/NetworkManager/nm-dhcp-helper -pf
> /var/run/ -lf /var/lib/NetworkManager/
> 
> Actual results:
> The amount of memory consumed by NetworkManager increases during a short 
> period
> of time during handling dhcp events by NetworkManager.
> 
> Expected results:
> Memory usage of NetworkManager should not increased on dhcp events.
> 
> Red Hat bugzilla report:
> https://bugzilla.redhat.com/show_bug.cgi?id=1496204
> 
> Upstream patch:
> https://github.com/NetworkManager/NetworkManager/commit/44cbd3b036411c8b49bc2d34d4602fdc47d4921a#diff-f3e26d982a3f07282c78f0784c9955ab
> 

Thanks for the detailed bug report.
Both versions in unstable/buster and experimental are not affected as
they carry the above upstream commit, so marking the fixed version
accordingly.

In case we make another stretch stable release, I will take this patches
into consideration. Whether we make another stable upload for
network-manager is not decided yet.

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#931097: unattended-upgrades: InvalidURL(f"URL can't contain control characters. {url!r} "

[Markus Koschany]

Hello,

Am 26.06.19 um 09:59 schrieb duncanwebb:
> Package: unattended-upgrades
> Version: 0.83.3.2+deb8u1
> Severity: serious
> Justification: normal
> 
> Dear Maintainer,
> 
> Jessie uses python 3.4 and python 3.4 does not support f"" strings
> 
> So now unattended upgrades no longer performs security upgrades.

[...]

Thank you for reporting this issue. We have corrected this problem with
the upload of python3.4 version 3.4.2-1+deb8u4 yesterday. Unfortunately
a manual upgrade is required, afterwards unattended-upgrades will
continue to work again as intended.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#928283: lintian: false positive pkg-js-tools-test-is-missing for openjk: assumes variables contain --with=nodejs

[Christoph Berg]

Re: Chris Lamb 2019-05-02 
<30f34bfa-050d-4966-856d-2cce9da3b...@www.fastmail.com>
> Indeed, how common even is this false-positive? It might be even more
> sensible to add a Lintian override until upstream accepts the package;
> it's meant to be temporary until upstream reviews/accepts some change,
> after all.

Same problem in postgresql-common:

W: postgresql-common source: pkg-js-tools-test-is-missing

WITH_SYSTEMD=--with systemd

%:
dh $@ $(WITH_SYSTEMD)

(It's written that way to make disabling it on older distributions using `sed` 
easier.)

Christoph

Bug#931118: unblock: debian-keyring/2019.06.25

[Mattia Rizzolo]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian-keyr...@packages.debian.org

Dear RT,

The last upload of debian-keyring done yesterday updates the security
team key.  See #928222 for more context.

I think it would be good if this change could find its way into buster.
With this package providing data only, there are no regression
potentials, imho.  Also, with it shipping mostly binary files, a debdiff
is quite useless.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#929527: [pkg-netfilter-team] Bug#929527: Bug#929527: Bug#914694

[Thomas Lamprecht]

On 6/26/19 2:59 PM, Arturo Borrero Gonzalez wrote:
> On 6/26/19 2:28 PM, Thomas Lamprecht wrote:
>> Hmm, but that's a grave issue which may just render the firewall void
>> for _any_ intermediate chain and produces segmentation faults errors.
>>
> The issue you found is not a general-case issue.
> The segfault is only produced apparently if you:
> 
> * define a custom chain
> * flush all rules of that custom chain (not required, because the chain was 
> just
> created)
> * add a rule to that custom chain
> 
> all in the same batch.
> 
> I may understand that this is important for some scripts or robots making use 
> of
> the iptables interface in that particular way, but is not the general case of
> how people define and add rules to custom chain/ruleset.
> Because of this, I think we should lower the severity of this bug.

I see this exactly the other way, this is the normal use case for
iptables-restore, i.e.:

* iptables-save before shutdown
* iptables-restore after boot

And in such an use all your points always happen in one batch. Also, all my
servers do it that way and I do not think that manual, rule-by-rule,
iptables editing is the norm or general case, like you're trying to suggest.
I only add new stuff this way, and that only quite seldom.

If I had not tried this before quite a few of my servers would have been
without any FW rule, no protection, no NAT masquerading for LANs, this
would have real and bad implications...

Because of this, I think the bug importance downgrade now should not be done,
this is IMO still grave.

I mean I and we as downstream distro with a few 100k users now know it and can
work around it, but I guess that this may hit quite some Debian users which 
update
to Buster without knowing that they would even need working around this.

Bug#870814: show message if unable to play video

[積丹尼 Dan Jacobson]

AG> with that we'd have all packages necessary to play videos, so we can
AG> close this bug. Does that sound fine?
OK! (I thought maybe there is some gstreamer meta package that would
grab them all.)

Bug#929527: [pkg-netfilter-team] Bug#929527: Bug#929527: Bug#914694

[Arturo Borrero Gonzalez]

Control: severity -1 important

On 6/26/19 2:28 PM, Thomas Lamprecht wrote:
> 
> Hmm, but that's a grave issue which may just render the firewall void
> for _any_ intermediate chain and produces segmentation faults errors.
> 

The issue you found is not a general-case issue.
The segfault is only produced apparently if you:

* define a custom chain
* flush all rules of that custom chain (not required, because the chain was just
created)
* add a rule to that custom chain

all in the same batch.

I may understand that this is important for some scripts or robots making use of
the iptables interface in that particular way, but is not the general case of
how people define and add rules to custom chain/ruleset.
Because of this, I think we should lower the severity of this bug.

I understand is annoying in your use case, and I'm sorry for that.
Thankfully, we already have an iptables version fixing the issue, but
unfortunately it won't make it to Debian Buster in the first round as I already
explained in my previous email.

> How about a minimal patch which places higher update-alternative priority
> to the the -legacy parts of iptables so that the alternative currently
> working in Buster is used by default. Once the fixed nft based is rolled
> out the priorities could then be switched again (or if that cannot be done
> for a stable release, in Bullseye).
> 

No, sorry, we won't do this at this point.

Bug#931119: smem: please use Python 3 i.e. package version 1.5

[W. Martin Borgert]

Package: smem
Version: 1.4-2
Severity: wishlist

I like to use smem on a system without Python 2.
Upstream seems to support Python 3 in version 1.5 (2015-05-15),
according to the hg log: https://selenic.com/repo/smem
Please consider updating the package.

Bug#931039: dh-strip-nondeterminism: Does not appear to clamp timestamps in PNG files

[Thorsten Glaser]

Hi Chris,

>I can see how it may make tests fail if they were naively comparing
>checksums or similar, but I'm not sure how this could make a package
>not reproducible.

Consider package A, contains PNGs, and package B, embeds the PNGs
from package A into its output (B can be identical to A). Then
consider package C which runs B at build time ⇒ C is not reproducible.

But yes, that’s esoterical. Anyway, I’m glad the issue ended up at
the right package in the meantime, thanks everyone!

bye,
//mirabilos
-- 
 exceptions: a truly awful implementation of quite a nice idea.
 just about the worst way you could do something like that, afaic.
 it's like anti-design.   that too… may I quote you on that?
 sure, tho i doubt anyone will listen ;)

Bug#929469: systemd-networkd: systemd-networkd: fails with "could not set address: Permission denied"

[Michael Biebl]

Am 26.06.19 um 14:17 schrieb Felipe Sateler:
> Honestly, I don't think networkd should keep quiet about ipv6 being
> disabled when you explicitly set up an ipv6 address.

I agree. While setting up an IPv6 address and at the same time disabling
IPv6 on the kernel side could be seen as a misconfiguration, it might
just as well be plain oversight on the admin's side.
networkd behaving more sensibly in that case is certainly desirable,
including logging about this issue (and afaics this is what the upstream
patch set does via log_info).
At the same time I don't think this issue is critical enough for the
buster release to be delayed, given that networkd is still optional and
non-default and the circumstances where this happens are kinda special.

TBH, I'm not even sure if it should be added to NEWS.
NEWS entries are shown to almost everyone. If we flood users with NEWS
entries they are not affected by, they will get into a habit of ignoring
NEWS entries.
Fwiw, I really struggled whether to add a NEWS entry for the
video->render group change for exactly this reason.

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#929749: libwebkit2gtk-4.0-37: version 2.24.2-1 does not play some streams

[Alberto Garcia]

On Thu, May 30, 2019 at 11:48:19AM +0200, Richard Lucassen wrote:

> 3 issues:

A quick update about this. It turns out that the 3 issues that you
describe are 3 separate bugs, and all of them have been reported
upstream.

> A) There is a significant difference between the time it takes
> to open an HLS stream between the versions 2.24.1-1/2.24.2-1 and
> 2.24.0-1:

This one is "[GStreamer] HLS stream slow start":

   https://bugs.webkit.org/show_bug.cgi?id=198377

This has already been fixed upstream.

> B) There is one station that does not play at all:

This one is "[GStreamer] Cannot play Bert's Bytes radio stream":

   https://bugs.webkit.org/show_bug.cgi?id=198376

Not fixed yet.

> C) Last but certainly not least: switching too fast between two HLS
> stations (e.g. 5 Live and BBC Worldservice) makes the whole beast
> hang.

This one is "[GStreamer] Web process hangs when scrolling twitter
timeline which contains HLS videos":

   https://bugs.webkit.org/show_bug.cgi?id=197558

Not fixed yet.

  ---

As for this Debian bug report, I'd keep things as they are for now.
If the next upstream release fixes all of them then let's close this,
if not we can open separate bugs for the pending issues.

Berto

Bug#930803: new program: runcached

[Andras Korn]

On Wed, Jun 26, 2019 at 12:18:25PM +0200, Andras Korn wrote:

> > > I just wrote this script:
> > > https://gist.github.com/akorn/51ee2fe7d36fa139723c851d87e56096 and thought
> > > it might be a good addition to moreutils.
> > > 
> > > It caches the stdout, stderr and exit status of arbitrary commands for a
> > > configurable length of time, returning data from cache on subsequent
> > > invocations if the cache is still fresh.
> > 
> > thanks for your suggestion; I think it's quite an interesting idea!
> > And you made me curious:  which commands are you running through
> > 'runcached'?  All programs I thought of have their basic functionality
> > based on side-effects as file system or network access.
> 
> Examples:
> 
>  * I have a Makefile to regenerate the data.cdb file for tinydns whenever
>any of the local source files changed. Part of the process is downloading
>some remote DNS zones with axfr-get, which is relatively slow. The remote
>zones don't change frequently; I don't want to download them each time,
>but I do want to download them at least once every eight hours or so. So
>I run axfr-get via runcached, with a cache ttl of 8 hours.
> 
>  * Some monitoring systems like Zabbix and Munin need to run data-gathering
>stuff that is time-consuming; it sometimes happens that several plugins
>need to run the same thing, but extract different data from its output.
>Instead of having separate, ad-hoc caching in all such plugins, it's
>better to have a generic caching solution.
> 
>  * When looking for space hogs in the filesystem, I often use
>'du -hscx * .* | sort -h' and then dig down further. Without runcached
>I would have to either save the output separately, or keep opening new
>sessions in screen(1), or wait for the same output to be generated again,
>when I go up to the higher level directory again. With runcached, `du` is
>cheap the 2nd time, and I don't care if the numbers are slightly off when
>they come from the cache.
> 
>  * Same for ad-hoc log analysis sessions: I may grep through a bunch of
>logs, then grep for something else, then grep for the same thing again.
>With runcached, I don't need to worry about saving output I may need
>again, because runcached does it for me.

* Oh, and ldapsearch. I have some scheduled scripts that each do something
  to members of the same group; before, I had an ad-hoc cache for group
  members, but with runcached I can just re-run ldapsearch with the same
  arguments and get cached results.

András

-- 
Win any staring contest: slowly go in for a kiss without breaking eye contact.

Bug#930293: unblock: docker.io/18.09.1+dfsg1-7

[Shengjing Zhu]

On Tue, Jun 25, 2019 at 08:13:46PM +0200, Paul Gevers wrote:
[...] 
> That said, I decided to unblock docker.io.
> 

Thanks!

But... you have a typo in the hint. The version should be
18.09.1+dfsg1-7.1.

-- 
Shengjing Zhu


signature.asc
Description: PGP signature

Bug#924657: console-setup | kbdnames-maker: Call `{bind,}textdomain` after switching locale (!2)

[Niko Tyni]

On Wed, Jun 26, 2019 at 11:23:28PM +0300, Niko Tyni wrote:
> clone 924657 -1
> reassign -1 perl 5.28.1-6
> severity -1 important
> retitle -1 perl: switching locales no longer invalidates gettext translation 
> cache
> thanks

Forgot that the BTS doesn't like clones of merged bugs.
I've filed #931139 instead.
-- 
Niko

Bug#926539: rootskel: steal-ctty no longer works on at least sparc64

[James Clarke]

Control: reopen -1
Control: reassign -1 src:linux,rootskel
Control: severity -1 serious

(Don't know if this is a blocker for the release, but it should at
least be reviewed before we release IMO, hence the severity)

On Sun, Apr 07, 2019 at 12:53:35AM +0100, Ben Hutchings wrote:
> On Sat, 2019-04-06 at 21:33 +0200, John Paul Adrian Glaubitz wrote:
> > On 4/6/19 6:46 PM, John Paul Adrian Glaubitz wrote:
> > > My suspicion is that the support multiple consoles in parallel [2] 
> > > introduced
> > > this particular regression. I haven't done any debugging yet though as I'm
> > > not sure where to start, I haven't touched the rootskel package before and
> > > therefore would be interested in any pointers how to debug this.
> >
> > The problem seems to be the fact that the sparc64 kernel uses different 
> > names
> > for /proc/console and the actual console name:
> >
> > root@landau:~# cat /proc/consoles
> > ttyHV0   -W- (EC p  )4:64
> > tty0 -WU (E )4:1
> > root@landau:~# readlink /sys/dev/char/4:64
> > ../../devices/root/f0299a70/f029b788/tty/ttyS0
>
> The inconsistent name seems like a kernel bug...
>
> > root@landau:~#
> >
> > And this is what used to make it work [1]:
> >
> > *) # >= 2.6.38
> > console_major_minor="$(get-real-console-linux)"
> > console_raw="$(readlink "/sys/dev/char/${console_major_minor}")"
> > console="${console_raw##*/}"
> > ;;
>
> So maybe rootskel should use that again, but applied to each console's
> char device number.
>
> (Though directly using the symlinks under /dev/char seems cleaner than
> poking in sysfs.)

Just got a report in #debian-cd of a user running into this issue on
s390x with Hercules; a subset of the messages sent in conversation are
below:

[20:12:18]  steal-ctty: No such file or directory
[20:12:29]  will go hunt this down once i find time
[20:12:52]  (DI buster RC2 / s390x)
[21:52:40]  gruetzkopf: cat /proc/consoles ?
[21:54:00]  should give something like:
[21:54:00]  ttyS0-W- (EC p  )4:64
[21:54:22]  rootskel will prefer a console which has the C flag
[21:55:17]  now let's see how to get there
[21:55:57]  (note: running in hercules, not real hw or qemu 
where i'd have virtio console)
[22:01:39]  cat /proc/consoles
[22:01:40]  ttyS0-W- (EC p  )4:64
[22:02:05]  and ls -l /dev/ttyS0?
[22:03:06]  ls: /dev/ttyS0: No such file or directory
[22:03:06]  oh, fun!
[22:04:36]  and ls -l /sys/dev/char/4:64 ?
[22:06:06]  ls -l /sys/dev/char/4:64
[22:06:06]  lrwxrwxrwx1 root root 0 Jun 
26 21:05 /sys/dev/char/4:64 -> .
[22:06:06]  ./../devices/virtual/tty/sclp_line0
[22:06:28]  ok, so, it's not /dev/ttyS0, it's /dev/sclp_line0?
[22:06:32]  (does that exist?)
[22:06:48]  we had an issue like this on sparc64 (#926539)
[22:07:38]  i just found that
[22:07:53]  does that device node exist for you?
[22:08:13]  crw--w1 root root4,  64 Jun 
26 20:58 /dev/sclp_line0
[22:08:43]  (and so does /dev/ttysclp0)

This is the "fault" of drivers/s390/char/sclp_tty.c. I don't know what
the best fix is; we could also patch the kernel to ensure this shows up
as /dev/sclp_line0 in /proc/consoles like sparc64 now does for sunhv,
but I worry now that this might be a game of whack-a-mole and there are
other character device drivers out there that also suffer from this.
Perhaps therefore we need to go back to looking up the device name from
the device number as has been suggested already...

James

Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd

[Baptiste BEAUPLAT]

On 6/26/19 11:04 PM, Michael Biebl wrote:
> Am 26.06.19 um 21:39 schrieb andreimpope...@gmail.com:
>>
>> On Mi, 26 iun 19, 20:23:59, Baptiste BEAUPLAT wrote:
> 
>>> The only way to force modprobe to use local configuration is to rename
>>> the /etc/modprobe.d/dummy.conf file to /etc/modprobe.d/systemd.conf.
>>
>> Is this documented anywhere else?
> 
> According to the docs in man 5 modules-load.d it should be sufficient to
> name the local config so that is sorted after systemd.conf.
> 
> 

I've opened the bug #931137 [1] directly against kmod.

Following the prompt reply from the maintainer, it would appear that
it's the only way to go.

This is what I'm going to apply to fix the actual issue on my systems.

I'll let you decided if this new override from systemd to dummy and
bonding modules should be mentioned in the release notes.

I would advocate for it since unaware sysadmins (like me) could easly
break their network configuration because of that.

Best,

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

-- 
Baptiste BEAUPLAT - lyknode



signature.asc
Description: OpenPGP digital signature

Bug#931134: procps: Please include 'older' than option

[ed neville]

Package: procps
Version: 2:3.3.12-3+deb9u1
Severity: wishlist

Dear Maintainer,

pgrep does not currently include an option to limit selection to tasks
which are older than N number of seconds. The work around requires
numeric work in shell which is not desirable.

Pull request:

  https://gitlab.com/procps-ng/procps/merge_requests/79

It would be great if this could be included in debian and RH where I
currently have work arounds, but this code change would be more reliable
than my shell code.

Thanks in advance,
Ed

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

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages procps depends on:
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u4
ii  libncurses5  6.0+20161126-1+deb9u2
ii  libncursesw5 6.0+20161126-1+deb9u2
ii  libprocps6   2:3.3.12-3+deb9u1
ii  libtinfo56.0+20161126-1+deb9u2
ii  lsb-base 9.20161125

Versions of packages procps recommends:
ii  psmisc  22.21-2.1+b2

procps suggests no packages.

-- no debconf information

Bug#931135: German translation made me laugh during a meeting

[Stefan Potyra]

Package: dpkg-dev
Version: 1.19.6
Severity: minor
Tags: l10n

Hi,

the following translation in the "FEATURE AREAS" -> "qa" might need some
improvement:

LANG=C man dpkg-buildflags
___snip___
   canary This  setting  (disabled  by  default) adds dummy canary
   options to the build flags, so that the build logs can be checked
   for how the build flags propagate and to allow finding any omission
   of normal build flag settings.  The only currently supported
   flags are CPPFLAGS, CFLAGS, OBJCFLAGS, CXXFLAGS and OBJCXXFLAGS with
   flags set to -D__DEB_CANARY_flag_random-id__, and LDFLAGS set
   to -Wl,-z,deb-canary-random-id.
__snip__

LANG=de_DE.UTF-8 man dpkg-buildflags
__snip__
canary Diese  Einstellung  (standardmäßig  deaktiviert)  fügt 
Pseudo-Kanarienvögel-Optionen  zu  den  Bauschaltern  hinzu, 
so  dass die Bauprotokolle überprüft werden können, wie die
Bauschalter sich fortpflanzen. Dies erlaubt, Auslassungen in den
normalen Bauschaltereinstellungen zu finden. Derzeit werden nur
die Schalter CPPFLAGS, CFLAGS,  OBJCFLAGS,  CXXFLAGS  und 
OBJCXXFLAGS  unterstützt,  wobei  die  Schalter  auf
-D__DEB_CANARY_Schalter_Zufallskennung__  gesetzt  werden,
und  LDFLAGS,  das  auf -Wl,-z,deb-canary-Zufallskennung gesetzt wird.
__snip__

Not too sure, if we should fix this or just keep it as an easter egg :).

From https://www.oocities.org/spunk/birds.htm#canary:

 .-"-.
/ 4 4 \
\_ v _/
//   \\
   (( ))
 ===""===""===
  jgs |||
  '|'

Cheers,
  Stefan.

-- Package-specific info:

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

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

Versions of packages dpkg-dev depends on:
ii  binutils  2.31.1-16
ii  bzip2 1.0.6-9
ii  libdpkg-perl  1.19.6
ii  make  4.2.1-1.2
ii  patch 2.7.6-3
ii  perl  5.28.1-6
ii  tar   1.30+dfsg-6
ii  xz-utils  5.2.4-1

Versions of packages dpkg-dev recommends:
ii  build-essential  12.6
ii  fakeroot 1.23-1
ii  gcc  4:8.3.0-1
ii  gcc-4.7 [c-compiler] 4.7.4-3
ii  gcc-4.8 [c-compiler] 4.8.5-4
ii  gcc-4.9 [c-compiler] 4.9.4-2
ii  gcc-5 [c-compiler]   5.5.0-12
ii  gcc-6 [c-compiler]   6.5.0-2
ii  gcc-7 [c-compiler]   7.4.0-9
ii  gcc-8 [c-compiler]   8.3.0-7
ii  gnupg2.2.13-2
ii  gnupg2   2.2.13-2
ii  gpgv 2.2.13-2
ii  libalgorithm-merge-perl  0.08-3

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

-- no debconf information

Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd

[Justin B Rye]

Baptiste BEAUPLAT wrote:
> Systemd, in buster, will ship the file /lib/modprobe.d/systemd.conf,
> which contains the following:
> 
> options bonding max_bonds=0
> 
> # Do the same for dummy0.
> 
> options dummy numdummies=0
> 
> This breaks any configuration that an administrator could have added to
> /etc/modprobe.d regarding the dummy and bonding modules.

We need more information about why an administrator might have done
this, since otherwise for a start it's impossible to guess what would
go wrong as a result.  VMs with sabotaged networking, or what?  Is
there some other bugreport where we could read about these symptoms?
 
> For instance, a file in /etc/modprobe.d/dummy.conf containing:
> 
> options dummy numdummies=1
> 
> Will result in the following being executed by modprobe:
> 
> insmod /lib/modules/4.19.0-5-amd64/kernel/drivers/net/dummy.ko
> numdummies=1 numdummies=0
> 
> And the original configuration will be overridden.
> 
> The only way to force modprobe to use local configuration is to rename
> the /etc/modprobe.d/dummy.conf file to /etc/modprobe.d/systemd.conf.

This overrides the /lib/modprobe.d/systemd.conf entirely, doesn't it?
In which case you'd lose any other things in that file that systemd
might be depending on.  Checking on a Buster box I see it also defines
"options bonding max_bonds=0" - if I want to avoid overriding that,
would it be better to use a name like /etc/modprobe.d/zz-local.conf?

> I thinks this should be documented in the release notes as admins would
> need to be aware of that.

And/or quite possibly about max_bonds=0?  I'm afraid I know even less
about what symptoms that might have.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd

[Justin B Rye]

Justin B Rye wrote:
> Checking on a Buster box I see it also defines
> "options bonding max_bonds=0"

Oh, yes, you already said that!  But anyway: what are the ill effects?
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#924657: console-setup | kbdnames-maker: Call `{bind,}textdomain` after switching locale (!2)

[Niko Tyni]

clone 924657 -1
reassign -1 perl 5.28.1-6
severity -1 important
retitle -1 perl: switching locales no longer invalidates gettext translation 
cache
thanks

On Wed, Jun 19, 2019 at 08:01:01PM +, Iain Lane wrote:
 
> Hi @MichaIng-guest - sorry, I've dropped the ball on this a bit. There's a 
> [corresponding Debian 
> bug](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924657) with some 
> discussion in it, but the status is that we're a bit stalled a the minute. I 
> agree that my proposal here in this MR is a workaround and maybe Perl should 
> do something about this itself (slightly less convinced that glibc can be 
> blamed since presumably this has always been the behaviour of `uselocale()`?).
> 
> For Buster should we go ahead with this workaround? I'm not very confident in 
> pushing on it myself alone but maybe between me, @intrigeri and @ntyni we 
> have enough bravery?

As I already noted on the bug, the workaround seems fine to me. I think
it should be used for Buster, but I don't have a chance to do anything
else about this right now. Sorry.

I'm cloning a bug against perl and will try to take it upstream later
when I find the time.
-- 
Niko Tyni   nt...@debian.org

Bug#931136: Remove reference to module options support for /etc/modules in modules(5) man-page

[Baptiste BEAUPLAT]

Package: kmod

Dear maintainers,

As per 627949 [1], options are not supported any more in /etc/modules
and /etc/modules-load.d.

Please consider the following patch to remove the reference present in
the modules(5) man-page.

Best regards,

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

-- 
Baptiste BEAUPLAT - lyknode
From 036716bf6489a4dd1fc4a486aff3f9d1030e0ee8 Mon Sep 17 00:00:00 2001
From: Baptiste BEAUPLAT 
Date: Wed, 26 Jun 2019 22:26:23 +0200
Subject: [PATCH] Reference to module options in modules(5) manpage replaced by
 a pointer to modprobe.d configuration files

---
 debian/patches/debian_manpages | 23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/debian/patches/debian_manpages b/debian/patches/debian_manpages
index ff2c917..949f9d1 100644
--- a/debian/patches/debian_manpages
+++ b/debian/patches/debian_manpages
@@ -1,6 +1,6 @@
 --- /dev/null
 +++ b/extra/modules.5
-@@ -0,0 +1,25 @@
+@@ -0,0 +1,26 @@
 +.TH MODULES 5 "Version 1.2" "Debian GNU/Linux"
 +.SH NAME
 +/etc/modules - kernel modules to load at boot time
@@ -9,8 +9,9 @@
 +The
 +.B /etc/modules
 +file contains the names of kernel modules that are to be loaded at boot
-+time, one per line. Arguments can be given in the same line as the module
-+name. Lines beginning with a '#' are ignored.
++time, one per line. Options can only be specified using
++.B modprobe.d
++configuration files. Lines beginning with a '#' are ignored.
 +.SH "EXAMPLE"
 +# /etc/modules: kernel modules to load at boot time.
 +#
@@ -20,15 +21,15 @@
 +
 +w83781d
 +
-+3c509 irq=15
++3c509
 +nf_nat_ftp
 +.SH "SEE ALSO"
 +.BR depmod (8)
 +.BR modprobe (8)
-+.BR modprobe.conf (5)
++.BR modprobe\.d (5)
 --- /dev/null
 +++ b/extra/modules.fr.5
-@@ -0,0 +1,19 @@
+@@ -0,0 +1,21 @@
 +.\"Traduction Lundi 14 octobre 2002 par Antoine Gémis
 +.\"(age...@netuup.com)
 +.TH MODULES 5 "Version 1.1" "Debian GNU/Linux"
@@ -39,12 +40,14 @@
 +Le fichier
 +.B /etc/modules
 +contient la liste des modules du noyau à charger au démarrage, un module par
-+ligne. Une ligne peut inclure, après le nom du module, des paramètres à lui
-+passer. Sur une ligne, tout ce qui suit «\ #\ » sera considéré comme commentaire
-+et ignoré. 
++ligne. Les paramètres du module doivent être spécifiés avec les fichiers de
++configuration
++.B modprobe.d.
++Sur une ligne, tout ce qui suit «\ #\ » sera considéré comme commentaire et
++ignoré.
 +.SH "VOIR AUSSI"
 +.BR depmod (8)
 +.BR modprobe (8)
-+.BR modprobe.conf (5)
++.BR modprobe\.d (5)
 +.SH TRADUCTION
 +Antoine Gémis .
-- 
2.20.1



signature.asc
Description: OpenPGP digital signature

Bug#931137: modprobe: Local configuration in /etc/modprobe.d/ is overridden by system configuration in /lib/modprobe.d/

[Baptiste BEAUPLAT]

Package: kmod
Severity: important

Dear maintainer,

While I was doing some post upgrade operation after migrating to buster,
I realized that my network configuration was failing.

Here is what I have in my /etc/network/interfaces:

auto dummy0
iface dummy0 inet static
address 192.168.64.1
netmask 24

In my /etc/modules:

dummy

And in my /etc/modprobe.d/dummy.conf:

options dummy numdummies=1

It used to work correctly with stretch but is broken with buster. The
interface doesn't show up (as in not even listed).

It appears that the problem originate from particular file from systemd
shipped with buster, /lib/modprobe.d/systemd.conf, overriding my
configuration.

Result from a modprobe -v dummy:

insmod /lib/modules/4.19.0-5-amd64/kernel/drivers/net/dummy.ko
numdummies=1 numdummies=0

Both parameters are added (the one from my local configuration and the
one from systemd).

This issue is here: A local configuration SHOULD be able to override a
system one and not the opposite.

As per the man-page, this is a known behavior:

Packages should install their configuration files in /lib/. Files in
/etc/ are reserved for the local administrator, who may use this logic
to override the
   configuration files installed by vendor packages. All
configuration files are sorted by their filename in lexicographic order,
regardless of which of the directories
   they reside in. If multiple files specify the same option, the
entry in the file with the lexicographically latest name will take
precedence. It is recommended to
   prefix all filenames with a two-digit number and a dash, to
simplify the ordering of the files.

This is NOT a desired behavior as any update to the system configuration
directory might override local configuration (based on how the file is
named). Please change it accordingly to process system configuration (in
lexical order) and _then_ local configuration to always ensure that
local configure takes priority over the system one.

Best regards,

-- 
Baptiste BEAUPLAT - lyknode



signature.asc
Description: OpenPGP digital signature

Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd

[Michael Biebl]

Am 26.06.19 um 21:39 schrieb andreimpope...@gmail.com:
> 
> On Mi, 26 iun 19, 20:23:59, Baptiste BEAUPLAT wrote:

>> The only way to force modprobe to use local configuration is to rename
>> the /etc/modprobe.d/dummy.conf file to /etc/modprobe.d/systemd.conf.
> 
> Is this documented anywhere else?

According to the docs in man 5 modules-load.d it should be sufficient to
name the local config so that is sorted after systemd.conf.


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

Bug#931138: ctdb: DEB_HOST_ARCH_CPU initialization through dpkg-architecture

[Rafael David Tinoco]

Package: ctdb
Version: 2:4.9.5+dfsg-5
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Simple DEB_HOST_ARCH_CPU initialization fix

Build environment might not have DEB_HOST_ARCH_CPU variable and,
because of that, AES-NI enablement might fail silently, causing issues
on amd64 machines since the .install file refers to, now, missing
aesni shared library.

- From "man1/dpkg-architecture":

  The environment variables set by dpkg-architecture are passed to
  debian/rules as make variables (see make documentation). However, you
  should not rely on them, as this breaks manual invocation of the
  script. Instead, you should always initialize them using
  dpkg-architecture with the -q option.

With that, debian/rules should define DEB_HOST_ARCH_CPU.

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

Kernel: Linux 4.19.0-5-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)

Versions of packages ctdb depends on:
ii  iproute24.20.0-2
ii  libbsd0 0.9.1-2
ii  libc6   2.28-10
ii  libpopt01.16-12
ii  libtalloc2  2.1.14-2
ii  libtdb1 1.3.16-2+b1
ii  libtevent0  0.9.37-1
ii  lsb-base10.2019051400
ii  psmisc  23.2-1
ii  samba-libs  2:4.9.5+dfsg-5
ii  sudo1.8.27-1
ii  tdb-tools   1.3.16-2+b1
ii  time1.7-25.1+b1

Versions of packages ctdb recommends:
ii  ethtool  1:4.19-1

Versions of packages ctdb suggests:
ii  logrotate  3.14.0-4
ii  lsof   4.91+dfsg-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE9/EO4QjRa7yS94ISqT4OCtg8DQ8FAl0T3hoACgkQqT4OCtg8
DQ+8Gg//bH/eqhNca7RiqJWU9lKI7PDsR/Q4gXTwRnmq8TQtfKRK7MagWwrOLTYA
KkxQe1PFzAMlWOYIn4mIhmI6Uo57XQBibSiztLyJvhrNJIe+B0uNWRsCIPUJ+xTU
GQGt5joak1Yp+5kqb3XKRDeftMzXWIYdEOx2kkscHx0NYD1FVR0gmGEqxf78980o
sxfpZrgnq4KdSX0Nxr8YXEC69uaiV0gmr358kBJtfeRdjgd7L6GvOh2N8FFkNG6T
Hb8SxNZb0bbpTCaTRqfrYHUTO/PVTU6rURbXHcxJQJ7VcKh2EnJ91vcldR1XsQDc
Q7b0WksxuJ0K+Rt/UJ4saBgePceJlFl9f36bphyodf5v0BGVQDiMG6squpFkz7qC
AMGtbX/86gFn//KA+nVspYLgCcyXwY9D4aalthSwcc+jCdQpKXrwAdMPKY/33hwG
9GLRpZM9XNSpu1UEhhFituZXfjpadm1ga4gXDI5IjW9ZpmR/cf0pbn+x9T4HDzII
hKhRkMOfraZFmo6MPwuuaVHoa+OE57G8jCmy8chbwhN0xDluP7qqPIu0jfJyFQOc
qeAGr3THG3me/2hmRdZbjg061XvboJNi3rpsRxBAqqtqNSK4YvA7wmhWgYQkzLCb
RhjnvHLvVetqYwf5w85mcr3P3SMRYW4RKbMslMoRxtwEol3O3a0=
=y68G
-END PGP SIGNATURE-

Bug#893134: openjdk-11-source: inconsistent place for src.zip

[Vincent Smeets]

Package: openjdk-11-source
Version: 11.0.3+7-5
Followup-For: Bug #893134

This bug still exists in 11.0.3+7-5

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

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

Versions of packages openjdk-11-source depends on:
ii  openjdk-11-jdk  11.0.3+7-5

openjdk-11-source recommends no packages.

openjdk-11-source suggests no packages.

-- no debconf information

Bug#931085: mailavenger: drops TCP immediately after receiving 'QUIT', without sending the 221 response

[Philip Hands]

I thought I had a working autopkgtest in the branch I referred to in the
bug report, but it turns out that it wouldn't work in the salsa-ci
docker environment.

That being the case, I've set up a couple of new branches:

  salsa-ci -- changes needed to get salsa-ci working
  bug-931085-fix -- that plus the bug fix

Here's the original code failing with the unexpected connection closure:

  https://salsa.debian.org/philh/mailavenger/-/jobs/204437

whereas this is it running successfully with the bugfix:

  https://salsa.debian.org/philh/mailavenger/-/jobs/204443

Meanwhile I got in touch with David Mazieres (upstream) referring to
this bug -- given that asmptd is single threaded, my patch is not
actually good enough because the flush will wait for the other end,
which may have already gone away.  The existing code when run on BSD
sends the last packet but doesn't hang around if it doesn't get
acknowledged.  David intends to investigate how to get Linux to do
something similar.  I'd imagine he'd appreciate suggestions.

Now that the two new git branches exist, and are a bit cleaner than the
old ones had become after my attempts to get CI to work, I'll discard
the old branches, so the original links in the report will break -- all
the information is in the new branches anyway.

BTW while doing that, I noticed that the package's systemd postinst
attempts to activate the daemon immediately.  The salsa-ci branch
includes changes to stop this being the case, because as with init.d
this should not occur until the admin has a chance to configure things.
Also, it was breaking the autopkgtest.  My changes regarding than are
not ready for release though.  I should report a new bug regarding this bit.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY

Bug#931133: apt-xapian-index: unusable after recent python-apt update due to usage of deprecated Package.section attribute

[Simon Quigley]

Package: apt-xapian-index
Version: 0.49
Severity: important

Dear Maintainer,

When rebuilding the latest version of apt-xapian-index against the
version of python-apt recently uploaded to Experimental,
apt-xapian-index FTBFS with the following error:

Traceback (most recent call last):
  File "/usr/sbin/update-apt-xapian-index", line 111, in 
indexer.rebuild(opts.pkgfile)
  File "/usr/lib/python3/dist-packages/axi/indexer.py", line 758, in rebuild
self.buildIndex(dbdir, generator)
  File "/usr/lib/python3/dist-packages/axi/indexer.py", line 733, in
buildIndex
for doc in documents:
  File "/usr/lib/python3/dist-packages/axi/indexer.py", line 580, in
gen_documents_apt
yield self.get_document_from_apt(pkg)
  File "/usr/lib/python3/dist-packages/axi/indexer.py", line 543, in
get_document_from_apt
addon.obj.index(document, pkg)
  File "/usr/share/apt-xapian-index/plugins/sections.py", line 86, in index
sec = pkg.section
AttributeError: 'Package' object has no attribute 'section'

The usage of Package.version should be replaced by Version.section, as
shown in the recent deprecation notice:
"Package.section is deprecated, use Version.section instead"

I will raise this bug to RC once the version of python-apt that is in
Experimental is uploaded to Sid.

Thanks.

-- 
Simon Quigley
tsimo...@debian.org
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4



signature.asc
Description: OpenPGP digital signature

Bug#931132: apt-xapian-index: please enable autopkgtests

[Simon Quigley]

Package: apt-xapian-index
Version: 0.49
Severity: important

Dear Maintainer,

autopkgtests should be enabled by default in this package so when e.g.
python-apt removes deprecated features that this package uses, it is
detected early.

Please consider enabling the autopkgtests.

-- 
Simon Quigley
tsimo...@debian.org
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4



signature.asc
Description: OpenPGP digital signature

Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd

[andreimpopescu]

Control: tags -1 moreinfo

On Mi, 26 iun 19, 20:23:59, Baptiste BEAUPLAT wrote:
> Package: release-notes
> 
> Dear maintainers,
> 
> Systemd, in buster, will ship the file /lib/modprobe.d/systemd.conf,
> which contains the following:
> 
> options bonding max_bonds=0
> 
> # Do the same for dummy0.
> 
> options dummy numdummies=0
> 
> This breaks any configuration that an administrator could have added to
> /etc/modprobe.d regarding the dummy and bonding modules.

Would you have background information on why this is done?
What would be the impact on local configuration (networking unusable, 
degraded, etc.)?
 
> For instance, a file in /etc/modprobe.d/dummy.conf containing:
> 
> options dummy numdummies=1
> 
> Will result in the following being executed by modprobe:
> 
> insmod /lib/modules/4.19.0-5-amd64/kernel/drivers/net/dummy.ko
> numdummies=1 numdummies=0
> 
> And the original configuration will be overridden.
> 
> The only way to force modprobe to use local configuration is to rename
> the /etc/modprobe.d/dummy.conf file to /etc/modprobe.d/systemd.conf.

Is this documented anywhere else?

> I thinks this should be documented in the release notes as admins would
> need to be aware of that.


Thanks,
Andrei - not a Release Notes Maintainer, just anticipating what 
information might be necessary to write a useful entry.
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd

[Michael Biebl]

Am 26.06.19 um 21:39 schrieb andreimpope...@gmail.com:
> Control: tags -1 moreinfo
> 
> On Mi, 26 iun 19, 20:23:59, Baptiste BEAUPLAT wrote:
>> Package: release-notes
>>
>> Dear maintainers,
>>
>> Systemd, in buster, will ship the file /lib/modprobe.d/systemd.conf,
>> which contains the following:
>>
>> options bonding max_bonds=0
>>
>> # Do the same for dummy0.
>>
>> options dummy numdummies=0
>>
>> This breaks any configuration that an administrator could have added to
>> /etc/modprobe.d regarding the dummy and bonding modules.
> 
> Would you have background information on why this is done?
> What would be the impact on local configuration (networking unusable, 
> degraded, etc.)?

Assuming this was targeted at pkg-systemd-maintainers, I assume xnox can
tell you more. See
https://github.com/systemd/systemd/pull/6448


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

Bug#931099: ITP: r-cran-assertive.base -- GNU R lightweight core of the 'assertive' package

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-assertive.base -- GNU R lightweight core of the 
'assertive' package
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-assertive.base
  Version : 0.0
  Upstream Author : Richard Cotton,
* URL : https://cran.r-project.org/package=assertive.base
* License : GPL-3+
  Programming Lang: GNU R
  Description : GNU R lightweight core of the 'assertive' package
 A minimal set of predicates and assertions used by the assertive
 package.  This is mainly for use by other package developers who want to
 include run-time testing features in their own packages.  End-users will
 usually want to use assertive directly.

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

Bug#870814: show message if unable to play video

[Alberto Garcia]

On Wed, Jun 26, 2019 at 12:28:28AM +0800, 積丹尼 Dan Jacobson wrote:
> AG> With gstreamer1.0-libav installed ? What video are you exactly trying
> AG> to play ?
> 
> Yes.
> The first one that youtube shows me.
> So OK, give me a youtube movie url that plays for you and I'll try it.

These two for example work fine in my computer:

https://www.youtube.com/watch?v=ePO5PSDxEz0

https://www.youtube.com/watch?v=qigAsdGouX4

I installed gstreamer1.0-plugins-good, gstreamer1.0-gl and
gstreamer1.0-libav

Berto

Bug#931102: combblas: please make the documentation reproducible

[Chris Lamb]

Source: combblas
Version: 1.6.2-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpaths
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

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

This is because it ships .dot files that contain absolute build paths.
These files are not used/referenced by the documentation itself — did
you mean to build .pngs of them?

  -  Node9 
[label="/build/1st/combblas\l-1.6.2/debian/libcombblas\l-dev/usr/include/usort/dtypes.h",height=0.2
  +  Node9 
[label="/build/combblas-1.6.2\l/2nd/debian/libcombblas\l-dev/usr/include/usort\l/dtypes.h",height=0.2

Patch attached that also removes installation of the definitely-
useless .md5 files which simply vary due to the above.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2019-06-26 08:40:06.704293953 +0100
--- b/debian/rules  2019-06-26 09:43:56.421058440 +0100
@@ -53,4 +53,4 @@
 
 override_dh_installdocs-indep:
doxygen
-   dh_installdocs
+   dh_installdocs -X.dot -X.md5

Bug#931104: openvswitch-common: Wrong dependency on python-six

[Benjamin Drung]

Package: openvswitch-common
Version: 2.10.0+2018.08.28+git.8ca7c82b7d+ds1-12
Severity: grave

Hi,

openvswitch-common correctly depends on python3, because it ships
scripts written in Python 3:

```
# file /usr/bin/ov* | grep python
/usr/bin/ovn-detrace:a /usr/bin/python3 script, ASCII text 
executable
/usr/bin/ovn-docker-overlay-driver:  a /usr/bin/python3 script, ASCII text 
executable
/usr/bin/ovn-docker-underlay-driver: a /usr/bin/python3 script, ASCII text 
executable
/usr/bin/ovs-dpctl-top:  a /usr/bin/python3 script, ASCII text 
executable
/usr/bin/ovs-l3ping: a /usr/bin/python3 script, ASCII text 
executable
/usr/bin/ovs-parse-backtrace:a /usr/bin/python3 script, ASCII text 
executable
/usr/bin/ovs-pcap:   a /usr/bin/python3 script, ASCII text 
executable
/usr/bin/ovs-tcpdump:a /usr/bin/python3 script, ASCII text 
executable
/usr/bin/ovs-tcpundump:  a /usr/bin/python3 script, ASCII text 
executable
/usr/bin/ovs-test:   a /usr/bin/python3 script, ASCII text 
executable
/usr/bin/ovs-vlan-test:  a /usr/bin/python3 script, ASCII text 
executable
```

But openvswitch-common depends on python-six (pulling in Python 2) instead of
python3-six. Following script import six and will fail if python3-six is
missing:

```
# grep "from six" $(file /usr/bin/ov* | grep python | sed 's/:.*//') 
/usr/bin/ovs-l3ping:from six.moves import xmlrpc_client as xmlrpclib
/usr/bin/ovs-test:from six.moves import xmlrpc_client as xmlrpclib
/usr/bin/ovs-vlan-test:from six.moves import BaseHTTPServer
/usr/bin/ovs-vlan-test:from six.moves import http_client as httplib
```

This can be easily reproduced in a minimal Debian chroot:

```
# ovs-l3ping
Traceback (most recent call last):
  File "/usr/bin/ovs-l3ping", line 24, in 
from six.moves import xmlrpc_client as xmlrpclib
ModuleNotFoundError: No module named 'six'
```

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss

Member of United Internet

Bug#931113: cflow: wierd Info node with emacs

[Dmitry Bogatov]

Package: cflow
Version: 1:1.6-1
Severity: normal

Dear Maintainer,

under Emacs Info reader (C-h i) I have two cflow-related nodes:
one under Programming section, which works fine

  Programming
  * AutoGen: (autogen).   The Automated Program Generator
  * cflow: (cflow).   Create a graph of control flow within a 
program.

and one under Emacs section:

  Emacs
  [...]
  * IDN Library: (libidn)Emacs API.
  Emacs API for IDN functions.
  * cflow mode: (cflow)cflow mode.
  Major mode for visiting cflow charts.
^^^

Underlined symbols are marked as link, but attempt to follow link (place
a point and press ) results in "No such node or archor: cflow
mode" error in minibuffer. Emacs version is 1:26.1+1-3.2

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

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

Versions of packages cflow depends on:
ii  libc6  2.28-10

cflow recommends no packages.

cflow suggests no packages.

-- no debconf information


pgp3A7j4GbtJQ.pgp
Description: PGP signature

Bug#931112: lintian: false-positives of harndening-no-fortify-functions

[Dmitry Bogatov]

Package: lintian
Version: 2.15.0
Severity: wishlist

Dear Maintainer,

"hardening-no-fortify-functions" has extermely high false-positive rate.
From reading of its description, I can see two groups of packages.

First group of false-positives consists of packages that use little or
none of standard library /directly/:

 - bcron
 - ftpcopy
 - runit
 - djbdns
 - ...

You can check, these packages use CFLAGS/CPPFLAGS/LDFLAGS, provided by
dpkg-buildflags via /usr/share/dpkg/default.mk (While I was writing this
bug, I notices that in "runit" package I forgot LDFLAGS, but fix to
include them changes nothing.)

Secondly, even "gdbm" library (but not binary), which is conventional
user of libc as whole and stdio in particular, triggers this tag.

I believe, blhc(1) does everything this tag was supposed to do.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.


pgpcnPVyNHP32.pgp
Description: PGP signature

Bug#930700: Re: Bug#930700: Re: Bug#930700: lintian: support "suppress-tags-from-file" in configuration file

[Dmitry Bogatov]

[2019-06-24 13:53] "Chris Lamb" 
> > Some of tags have too much false-positive rate, and some of them are not
> > worth spending time. Here is incomplete list:
>
> Neat. So, I think there are three categories here.

Well, I would divide only into two categories: "don't care" and
"false-positive".

Most (all?) "don't care" tags are pedantic, but not all pedantic are
"don't care".

For example, currently "debian-watch-does-not-check-gpg-signature" is
pedantic, but I consider it error, unless it is false-positive.

I'd prefer opt-out approach to opt-in, to not miss something useful.
This bug is about making it simplier.

> Lastly, there are ones with too many false-positives. These seem the
> easy ones to address actually -- if you have a concrete example of
> false-positives, please file away.

Just filed.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#931066: Info

[MaXaMaR]

Baremetal linux distributions also don’t work with modeset, just hang & 
shutdown, livecds too.

Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd

[Baptiste BEAUPLAT]

Hi all,

On 6/26/19 9:23 PM, Justin B Rye wrote:
> Baptiste BEAUPLAT wrote:
>> Systemd, in buster, will ship the file /lib/modprobe.d/systemd.conf,
>> which contains the following:
>>
>> options bonding max_bonds=0
>>
>> # Do the same for dummy0.
>>
>> options dummy numdummies=0
>>
>> This breaks any configuration that an administrator could have added to
>> /etc/modprobe.d regarding the dummy and bonding modules.
> 
> We need more information about why an administrator might have done
> this, since otherwise for a start it's impossible to guess what would
> go wrong as a result.  VMs with sabotaged networking, or what?  Is
> there some other bugreport where we could read about these symptoms?

The dummy module can be used to create virtual interfaces, that can then
be configured for a particular use.

I've seen it a couple of times, usually for router or vpn box. It would
allow to bind some services especially for that virtual interface.

I stumble across this bug just as of today, while testing the upgrade to
buster. I don't think there is yet other bug report on it.

If you think that release-notes is not the place and that I should
report it to another package, I don't mind at all reassigning it.

>  
>> For instance, a file in /etc/modprobe.d/dummy.conf containing:
>>
>> options dummy numdummies=1
>>
>> Will result in the following being executed by modprobe:
>>
>> insmod /lib/modules/4.19.0-5-amd64/kernel/drivers/net/dummy.ko
>> numdummies=1 numdummies=0
>>
>> And the original configuration will be overridden.
>>
>> The only way to force modprobe to use local configuration is to rename
>> the /etc/modprobe.d/dummy.conf file to /etc/modprobe.d/systemd.conf.
> 
> This overrides the /lib/modprobe.d/systemd.conf entirely, doesn't it?
> In which case you'd lose any other things in that file that systemd
> might be depending on.  Checking on a Buster box I see it also defines
> "options bonding max_bonds=0" - if I want to avoid overriding that,
> would it be better to use a name like /etc/modprobe.d/zz-local.conf?

The current problem is the actual processing order of modprobe.

It should be /lib/modprobe.d then /etc/modprobe.d.

Currently, it merges both directories and then do the sorting.
The 'ill' effect is that it processes /lib/modprobe.d/systemd.conf
_after_ /etc/aa-systemd.conf, overwritting its content.

I now realize that I should have reported the issue directly against
modprobe. I don't think it will be fixed in time for buster release, so
it might be still useful to have the info on the release notes.

>> I thinks this should be documented in the release notes as admins would
>> need to be aware of that.
> 
> And/or quite possibly about max_bonds=0?  I'm afraid I know even less
> about what symptoms that might have.
> 

I'll open a new bug against modprobe with a better explaining of the
problem. I'll wait for maintainers' reply and see then.

Thanks for your quick replies,

Best,

-- 
Baptiste BEAUPLAT - lyknode



signature.asc
Description: OpenPGP digital signature

Bug#931139: perl: switching locales no longer invalidates gettext translation cache

[Niko Tyni]

Package: perl
Version: 5.28.1-6
Severity: important

As discussed in #924657, glibc has a cache of already loaded translations
that gets invalidated (by incrementing _nl_msg_cat_cntr) in setlocale(3),
bindtextdomain(3) and textdomain(3) but not uselocale(3).

Starting with Perl 5.28, Perl uses POSIX 2008 thread-safe locales, so
it calls uselocale(3) underneath when the Perl side POSIX::setlocale()
function is invoked.

This makes gettext think that a translation for the new locale is already
loaded when it really corresponds to the old locale.

While this is a 5.28 regression for Perl, it's not clear to me
whether glibc is working correctly here or not.
-- 
Niko Tyni   nt...@debian.org

Bug#931140: lsat: probably obsolete

[Ivo De Decker]

package: lsat
severity: serious

Hi,

lsat claims to be a 'security auditor tool':

"The Linux Security Auditing Tool (LSAT) is a post install security auditor
for Linux/Unix. It checks many system configurations and local network
settings on the system for common security/config errors and for packages that
are not needed."

However, the last maintainer upload was in 2009, so I guess this package
probably cannot give any useful security information.

Ivo

Bug#931125: ufw: Rules disappear when updating task list

[Eloi Coutant]

Package: ufw
Version: 0.35-4
Severity: important

Dear Maintainer,

I configured ufw with a DENY IN and DENY OUT default position. To ease
the configuration, I created new apps placed in
/etc/ufw/applications.d/custom, as well as used some existing apps, then
allowed in and out the desired apps.

Unfortunately, some ALLOW OUT rules disappear after installing new packages 
when dpkg triggers... trigger. I traced that back to the "ufw app update all" 
command, which effectively disable some outgoing rules for no apparent reason.

While some rules are not as important, it is problematic to lose
outgoing traffic for a mail server because we updated some other
packages...

Here are the lines deleted in the rules file after ufw app update all:
< ### tuple ### allow tcp 80,443 0.0.0.0/0 any 0.0.0.0/0 Nginx%20Full - out 

< -A ufw-user-output -p tcp -m multiport --dports 80,443 -j ACCEPT -m comment 
--comment 'dapp_Nginx% 20Full'  
   
<   

< ### tuple ### allow any 53 0.0.0.0/0 any 0.0.0.0/0 DNS - out  

< -A ufw-user-output -p tcp --dport 53 -j ACCEPT -m comment --comment 
'dapp_DNS'
< -A ufw-user-output -p udp --dport 53 -j ACCEPT -m comment --comment 
'dapp_DNS'
<   

< ### tuple ### allow tcp 25,143,465,587,993,4190 0.0.0.0/0 any 0.0.0.0/0 Mail 
- out
< -A ufw-user-output -p tcp -m multiport --dports 25,143,465,587,993,4190 -j 
ACCEPT -m comment --com ment 'dapp_Mail'


Some of the app are custom (the "Mail" one), others are provided by ufw
or package maintainer ('Nginx Full' or 'DNS').

Please do not hesitate to ask for further information. I think this bug
is quite critical as we really shouldn't have changes in rules not
explicitely provided by the administrator.

Regards,
Eloi

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

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

Versions of packages ufw depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  init-system-helpers1.48
ii  iptables   1.6.0+snapshot20161117-6
ii  lsb-base   9.20161125
ii  python33.5.3-1
ii  ucf3.0036

ufw recommends no packages.

Versions of packages ufw suggests:
ii  rsyslog  8.24.0-1

-- Configuration Files:
/etc/default/ufw changed:
IPV6=no
DEFAULT_INPUT_POLICY="DROP"
DEFAULT_OUTPUT_POLICY="DROP"
DEFAULT_FORWARD_POLICY="DROP"
DEFAULT_APPLICATION_POLICY="SKIP"
MANAGE_BUILTINS=no
IPT_SYSCTL=/etc/ufw/sysctl.conf
IPT_MODULES="nf_conntrack_ftp nf_nat_ftp nf_conntrack_netbios_ns"


-- debconf-show failed

Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd

[Baptiste BEAUPLAT]

Package: release-notes

Dear maintainers,

Systemd, in buster, will ship the file /lib/modprobe.d/systemd.conf,
which contains the following:

options bonding max_bonds=0

# Do the same for dummy0.

options dummy numdummies=0

This breaks any configuration that an administrator could have added to
/etc/modprobe.d regarding the dummy and bonding modules.

For instance, a file in /etc/modprobe.d/dummy.conf containing:

options dummy numdummies=1

Will result in the following being executed by modprobe:

insmod /lib/modules/4.19.0-5-amd64/kernel/drivers/net/dummy.ko
numdummies=1 numdummies=0

And the original configuration will be overridden.

The only way to force modprobe to use local configuration is to rename
the /etc/modprobe.d/dummy.conf file to /etc/modprobe.d/systemd.conf.

I thinks this should be documented in the release notes as admins would
need to be aware of that.

Best,

-- 
Baptiste BEAUPLAT - lyknode



signature.asc
Description: OpenPGP digital signature

Bug#931122: haskell-mode: interactive mode fails to parse ghci start message

[Dylan Thurston]

Package: haskell-mode
Version: 16.1-6
Severity: normal

Dear Maintainer,

When starting interactive-haskell-mode with the current ghc (8.4.4),
the mode does not correctly parse the line indicating how many modules
are loaded.

To reproduce:

% emacs -q t.hs [attached, dummy file]
* M-x interactive-haskell-mode
* M-l

results in
  Haskell Process command errored with: (error "Unexpected response from 
haskell process.")

You can see the problem by running ghci manually:

% ghci t.hs
GHCi, version 8.4.4: http://www.haskell.org/ghc/  :? for help
[1 of 1] Compiling Main ( t.hs, interpreted ) [flags changed]
Ok, one module loaded.
*Main> 


This response, "Ok, one module loaded", is not what the code in
haskell-load.el is expecting. This is addressed upstream here:
  https://github.com/haskell/haskell-mode/issues/1553
That's from a previous iteration of the message, the current github
code apparently handles up to GHC 8.6.3.

This makes interactive-haskell-mode almost useless.

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

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

Versions of packages haskell-mode depends on:
ii  elpa-haskell-mode  16.1-6

haskell-mode recommends no packages.

haskell-mode suggests no packages.

-- no debconf information
module Main where
import Data.Group

main = print "Hello World"

Bug#930728: pg_cltlcluster leaks logfile descriptor into PostgreSQL backends

[Andrey Borodin]

Hi!

> 26 июня 2019 г., в 19:22, Christoph Berg  написал(а):
> 
> Re: Andrey Borodin 2019-06-19 
> <4178a7b3-b742-49d7-afa9-fcb3439a0...@yandex-team.ru>
>> On my observation - yes, descriptor 4 is no longer in lsof.
> 
> Ah, I had not noticed the "4" before. Only 1 and 2 are expected.
> We can simply close() that one after dup2()'ing it to stdout/stderr.
> 
> Thanks for spotting!

Thanks for pushing fix for this.
Maybe we can somehow get rid of 1 and 2 attached to logfile (that will be 
logrotated and deleted)?
Can we redirect output to some temporary file and after pg_ctl append this file 
to logfile?

I simply want to be able to delete this file via logrotate...

Best regards, Andrey Borodin.

Bug#931123: Puts systemd service files in arch tuple lib directory

[Jonathan McDowell]

Package: tpm2-abrmd
Version: 2.1.0-1
Severity: normal

This package puts its systemd service file in a /usr/lib//
directory:

/usr/lib/x86_64-linux-gnu/systemd/system/tpm2-abrmd.service
/usr/lib/x86_64-linux-gnu/systemd/system-preset/tpm2-abrmd.preset

These should be:

/lib/systemd/system/tpm2-abrmd.service
/lib/systemd/system-preset/tpm2-abrmd.preset

as otherwise systemd does not pick them up.

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

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

Versions of packages tpm2-abrmd depends on:
ii  libc6  2.28-10
ii  libglib2.0-0   2.58.3-2
ii  libtss2-esys0  2.1.0-4

tpm2-abrmd recommends no packages.

tpm2-abrmd suggests no packages.

-- no debconf information

Bug#931124: debhelper: Add dh_missing option or feature to report/error on unreproduced empty directories

[Daniel Schepler]

Package: debhelper
Version: 12.1.1
Severity: wishlist

It's not uncommon for an upstream build system's install process to
create a hierarchy of empty directories as placeholders for data
storage.  It would be nice if dh_missing would report it (and error
out in --fail-missing mode) when a maintainer has failed to include
those placeholder directories in any package.
-- 
Daniel Schepler

Bug#931126: unblock: enigmail/2:2.0.11+ds1-2

[Daniel Kahn Gillmor]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Control: affects -1 src:enigmail
X-debbugs-cc: Salvatore Bonaccorso , Moritz Mühlenhoff 


Please unblock package enigmail

enigmail 2:2.0.11+ds1-2 includes several usability and security fixes
from upstream, including a fix for CVE-2019-12269 (debian bug #929363).

The debdiff is attached.

unblock enigmail/2:2.0.11+ds1-2

About half of this bulky debdiff is upstream fixes to the test suite,
which has been improved; this is useful for our own testing, and it
should have no effect on the functionality of the package.

Some of the code in debian/patches is also obsolete thanks to the new
upstream version.  In particular,
debian/patches/0005-avoid-OpenPGP.js-during-key-file-import.patch is now
much simpler -- it now rips out a chunk of unusable code (that
references OpenPGP.js, see #787774) and doesn't need to add very much,
because of adoption of the same gpg-based strategy by upstream.

Thanks for your work on fine-tuning the debian Buster release!

   --dkg

diff --git enigmail-2:2.0.10+ds1-1/configure.ac enigmail-2:2.0.11+ds1-2/configure.ac
index 4db7ecc57..e64eff0c1 100644
--- enigmail-2:2.0.10+ds1-1/configure.ac
+++ enigmail-2:2.0.11+ds1-2/configure.ac
@@ -2,7 +2,7 @@
 AC_PREREQ(2.61)
 min_automake_version="1.10"
 
-AC_INIT([enigmail],[2.0.10], [https://www.enigmail.net])
+AC_INIT([enigmail],[2.0.11], [https://www.enigmail.net])
 
 
 AC_PATH_PROG(PYTHON, "python2")
diff --git enigmail-2:2.0.10+ds1-1/debian/changelog enigmail-2:2.0.11+ds1-2/debian/changelog
index 5baba4f74..234181b12 100644
--- enigmail-2:2.0.10+ds1-1/debian/changelog
+++ enigmail-2:2.0.11+ds1-2/debian/changelog
@@ -1,3 +1,17 @@
+enigmail (2:2.0.11+ds1-2) unstable; urgency=medium
+
+  * minimize legacy-display protected headers for encrypted mails
+
+ -- Daniel Kahn Gillmor   Thu, 30 May 2019 15:40:57 -0400
+
+enigmail (2:2.0.11+ds1-1) unstable; urgency=medium
+
+  * new upstream release
+  * refresh patches
+  * use the older import-show with --dry-run instead of show-only
+
+ -- Daniel Kahn Gillmor   Thu, 23 May 2019 17:06:35 -0400
+
 enigmail (2:2.0.10+ds1-1) unstable; urgency=medium
 
   * new upstream release
diff --git enigmail-2:2.0.10+ds1-1/debian/patches/0005-avoid-OpenPGP.js-during-key-file-import.patch enigmail-2:2.0.11+ds1-2/debian/patches/0005-avoid-OpenPGP.js-during-key-file-import.patch
index 4496a5ce1..a52cf709a 100644
--- enigmail-2:2.0.10+ds1-1/debian/patches/0005-avoid-OpenPGP.js-during-key-file-import.patch
+++ enigmail-2:2.0.11+ds1-2/debian/patches/0005-avoid-OpenPGP.js-during-key-file-import.patch
@@ -7,15 +7,18 @@ contingent on GnuPG's mechanisms for reporting standalone revocation
 certs:
 
 https://dev.gnupg.org/T4018
+
+This means we depend on a more recent version (or a patched version)
+of GnuPG than upstream enigmail does.
 ---
- package/key.jsm | 92 +++--
- 1 file changed, 57 insertions(+), 35 deletions(-)
+ package/key.jsm | 58 ++---
+ 1 file changed, 2 insertions(+), 56 deletions(-)
 
 diff --git a/package/key.jsm b/package/key.jsm
-index f7976dc..85572cc 100644
+index 0b4a0ef..565273f 100644
 --- a/package/key.jsm
 +++ b/package/key.jsm
-@@ -128,7 +128,8 @@ var EnigmailKey = {
+@@ -137,7 +137,8 @@ var EnigmailKey = {
 *  - id (key ID)
 *  - fpr
 *  - name (the UID of the key)
@@ -24,106 +27,66 @@ index f7976dc..85572cc 100644
 +   *  - revoke? (boolean, true if contains a revocation cert, undefined is the same as false)
 */
getKeyListFromKeyBlock: function(keyBlockStr, errorMsgObj, interactive = true) {
- EnigmailLog.DEBUG("key.jsm: getKeyListFromKeyBlock\n");
-@@ -148,46 +149,67 @@ var EnigmailKey = {
- 
- let keyList = [];
+ EnigmailLog.DEBUG("key.jsm: getKeyListFromKeyBlock()\n");
+@@ -150,61 +151,6 @@ var EnigmailKey = {
+ let keyList = getGpgKeyData(keyBlockStr);
  let key = {};
--for (let b of blocks) {
--  let m = EnigmailOpenPGP.openpgp.message.readArmored(b);
+ 
+-if (keyList.length === 0) {
+-  EnigmailLog.DEBUG("key.jsm: getKeyListFromKeyBlock: no data from GnuPG\n");
+-  if (keyBlockStr.search(/-BEGIN PGP (PUBLIC|PRIVATE) KEY BLOCK-/) >= 0) {
+-blocks = this.splitArmoredBlocks(keyBlockStr);
+-  } else {
+-isBinary = true;
+-blocks = [EnigmailOpenPGP.enigmailFuncs.bytesToArmor(EnigmailOpenPGP.openpgp.enums.armor.public_key, keyBlockStr)];
+-  }
 -
--  for (let i = 0; i < m.packets.length; i++) {
--let packetType = EnigmailOpenPGP.openpgp.enums.read(EnigmailOpenPGP.openpgp.enums.packet, m.packets[i].tag);
--switch (packetType) {
--  case "publicKey":
--  case "secretKey":
--key = {
--  id: m.packets[i].getKeyId().toHex().toUpperCase(),
--  fpr: 

Bug#931114: [Debian-ha-maintainers] Bug#931114: cluster-glue: ibmrsa-telnet not python3 ready

[Valentin Vidić]

On Wed, Jun 26, 2019 at 12:41:29PM +0200, Pierre Dinh van wrote:
> I just upgraded my corosync cluster to buster, and the stonith external 
> helper /usr/lib/stonith/plugins/external/ibmrsa-telnet wasn't starting 
> anymore :
> 
> Jun 26 12:02:16 nfs4-c external/ibmrsa-telnet[22786]: [22848]: ERROR: 
> Exception raised: cannot use a string pattern on a bytes-like object
> Jun 26 12:02:17 nfs4-c stonith: [22764]: WARN: external_status: 
> 'ibmrsa-telnet status' failed with rc 1
> Jun 26 12:02:17 nfs4-c stonith: [22764]: ERROR: external/ibmrsa-telnet device 
> not accessible.
> Jun 26 12:02:17 nfs4-c pacemaker-fenced[2062]:  warning: stonith-nfs-a:22639 
> [ Performing: stonith -t external/ibmrsa-telnet -E -S ]
> 
> I changed the #!/usr/bin/python3 to #!/usr/bin/python2 and it works back.
> 
> Looks like it's not python3 ready.

Thanks for the report. I will try to reproduce and fix for python3 but you can
also try to use fence_rsa from the fence-agents package.  That is what the
upstream maintains these days and probably works better with python3.

-- 
Valentin

Bug#931129: knotifyconfig FTCBFS: missing Build-Depends: qttools5-dev

[Helmut Grohne]

Source: knotifyconfig
Version: 5.54.0-1
Tags: pending

knotifyconfig fails to cross build from source. This is fixed in git:
https://salsa.debian.org/qt-kde-team/kde/knotifyconfig/commit/ecae8a80af0f6632838d6536ba7a2003125b76e7
Please close this bug with the next upload to trigger a qa rebuild.

Helmut

Bug#930062: enigmail: Engimail decrypt-passphrase window takes control of desktop

[Daniel Kahn Gillmor]

Control: reassign 930062 pinentry-gnome3
Control: retitle 930062 pinentry-gnome3 grabs keyboard and mouse input despite 
--no-global-grab or 'OPTION no-grab'
Control: forwarded 930062 https://dev.gnupg.org/T4587

Hi Emmanuel--

Thanks for the report!  An explanation follows, along with some
diagnostics and an upstream bug report.  But as a caveat, i should warn
you that i personally prefer the system-modal prompting, because as i
understand it:

 a) it ensures that i don't accidentally type into another window when i
think i'm typing in the prompter

 b) it keeps other X11 clients from sniffing the keyboard input

All that said, there are still some weird bugs in here…

On Thu 2019-06-06 12:44:30 +0200, Emmanuel Revah wrote:
> I opened Thunderbird and selected an encrypted message. Or, I opened
> Thunderbird and the first message on the list is encrypted.
 […]
> A dialog window pops up and asks me to enter my gpg passphrase, and
> takes over the desktop.
 […]
> I expected to be able to leave that window on the side and use other
> programs (Pidgin, volume control, etc). I can see other windows and
> mouse actions seem to work, but anything keyboard related does not
> work. I can navigate in Firefox, but I can't enter a new url, I can't
> edit text in Vim or type something in Pidgin, but I can clock the
> volume controle in the task bar

The thing that's taking over your keyboard and mouse is pinentry.
It's doing that because (sorry about the long chain here):

  * thunderbird wants to read a message
  * enigmail notices that the message is encrypted, and asks gpg to
decrypt it
  * gpg notices that it is encrypted to a secret key, which it does not
control directly, so it asks gpg-agent to use the secret key on its
behalf
  * gpg-agent checks its passphrase cache and realizes that it doesn't
have the a passphrase so it needs to ask the user by invoking
pinentry
  * pinentry (implemented by pinentry-gnome3) in turn invokes gnome's
gcr service via dbus, to prompt the user for a password.
  * gcr prefers to grab the desktop inputs, to avoid other
processes snooping on your password as it is typed.  it's not clear

whew!

Note that gpg-agent's configuration has a choice of "grab" and
"no-grab", with "no-grab" being the default.  This choice is (i believe)
supposed to change whether pinentry receives the "OPTION no-grab"
directive or "OPTION grab" (see
https://salsa.debian.org/debian/gnupg2/blob/debian/master/agent/call-pinentry.c#L423
)

but that doesn't seem to have any effect on gcr, as tested by:

   printf 'OPTION no-grab\ngetpin\n' | pinentry-gnome3

Furthermore, pinentry-gnome3 appears to ignore its documented
--no-global-grab option:

   printf getpin\n' | pinentry-gnome3 --no-global-grab

still does a global grab.

This is because gcr's prompting is by definition system modal, i think:

https://developer.gnome.org/gcr/3.20/GcrSystemPrompt.html

As a workaround, since you're using KDE and plasma anyway, you could try
uninstalling pinentry-gnome3, but leaving pinentry-qt installed.  This
should make the system fall back to using pinentry-qt, which i believe
doesn't have the same behavior.

I've opened https://dev.gnupg.org/T4587 to try to address the
contradictions between the documentation and behavior of
pinentry-gnome3.

  --dkg


signature.asc
Description: PGP signature

Bug#929363: enigmail: CVE-2019-12269

[Daniel Kahn Gillmor]

On Tue 2019-06-25 22:35:44 +0200, Moritz Mühlenhoff wrote:
> Buster still has 2.0.10, what's the plan for it

I've just filed https://bugs.debian.org/931126 to unblock for buster.

> (and for stretch), should we fix this in older releases?

Given that we're updating thunderbird in stable, yes, we should probably
also update enigmail there.

Do you want to do that as the security team, or should i propose it?

 --dkg


signature.asc
Description: PGP signature

Bug#930765: Acknowledgement ([cron] default crontab produces error due to whitespace instead of tab)

[Peter Niederlag]

hourly mail is getting more and more into my way.

I know discovered an exact copy of original /etc/crontab as crontab of
root user, this one is saved into /var/spool/cron/crontabs/root and
managed via crontab cli binary.

Now I added tab separation there as well, let's see how it turns out.

Bug#931127: ramond FTCBFS: non-standard compiler variable GCC

[Helmut Grohne]

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

ramond fails to cross build from source, because it uses a non-standard
compiler variable "GCC". After renaming the compiler, ramond cross
builds successfully. Please consider applying the attached patch.

Helmut
diff --minimal -Nru ramond-0.5/debian/changelog ramond-0.5/debian/changelog
--- ramond-0.5/debian/changelog 2012-06-05 01:19:14.0 +0200
+++ ramond-0.5/debian/changelog 2019-06-26 19:29:14.0 +0200
@@ -1,3 +1,10 @@
+ramond (0.5-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Rename compiler to GCC. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 26 Jun 2019 19:29:14 +0200
+
 ramond (0.5-4) unstable; urgency=low
 
   * Add explicit build-depends on zlib1g-dev (Closes: #676011)
diff --minimal -Nru ramond-0.5/debian/rules ramond-0.5/debian/rules
--- ramond-0.5/debian/rules 2012-04-04 02:23:30.0 +0200
+++ ramond-0.5/debian/rules 2019-06-26 19:29:13.0 +0200
@@ -11,3 +11,6 @@
 
 %:
dh $@ 
+
+override_dh_auto_build:
+   dh_auto_build -- 'GCC=$$(CC)'

Bug#931128: an FTCBFS: uses the wrong pkg-config

[Helmut Grohne]

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

an fails to cross build from source, because the upstream Makefile hard
codes the build architecture pkg-config. The attached patch makes it
substitutable to make an cross buildable. Please consider applying it.

Helmut
--- an-1.2.orig/Makefile
+++ an-1.2/Makefile
@@ -22,9 +22,10 @@
 CC:=gcc
 INSTALL:=install
 
-CFLAGS += $(shell pkg-config --cflags icu-i18n)
+PKG_CONFIG ?= pkg-config
+CFLAGS += $(shell $(PKG_CONFIG) --cflags icu-i18n)
 CPPFLAGS += -D_DEFAULT_SOURCE
-LIBS += $(shell pkg-config --libs icu-i18n)
+LIBS += $(shell $(PKG_CONFIG) --libs icu-i18n)
 
 BIN=an
 MAN=an.6

Bug#930062: enigmail: Engimail decrypt-passphrase window takes control of desktop

[Daniel Kahn Gillmor]

On Wed 2019-06-26 14:03:09 -0400, Daniel Kahn Gillmor wrote:
>   * gcr prefers to grab the desktop inputs, to avoid other
> processes snooping on your password as it is typed.  it's not clear

sorry, this last sentence got cut off.  it was:

   it's not clear to me how to use gcr in a non-system-modal
   (non-grabby) way.

   --dkg

Bug#931131: tomcat9: CVE-2019-10072

[Salvatore Bonaccorso]

Source: tomcat9
Version: 9.0.16-4
Severity: important
Tags: security upstream
Control: found -1 9.0.16-1

Hi,

The following vulnerability was published for tomcat9.

CVE-2019-10072[0]:
| The fix for CVE-2019-0199 was incomplete and did not address HTTP/2
| connection window exhaustion on write in Apache Tomcat versions
| 9.0.0.M1 to 9.0.19 and 8.5.0 to 8.5.40 . By not sending WINDOW_UPDATE
| messages for the connection window (stream 0) clients were able to
| cause server-side threads to block eventually leading to thread
| exhaustion and a DoS.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-10072
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10072

Regards,
Salvatore

Bug#931145: gddccontrol: requires the GUI be run as root, doesn't work under Wayland

[Paul Wise]

Package: gddccontrol
Version: 0.4.4-1
Severity: normal
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: wayland

gddccontrol seems to require the GUI be run as root and as a result it
currently doesn't work under Wayland. GNOME are working on allowing X11
apps to run as root under Wayland but once gddccontrol becomes a
Wayland app it won't be able to run as root. So I think that the right
way to fix this is to make the app run as the user but make calls to a
dbus or other API running as root.

$ echo $DISPLAY $WAYLAND_DISPLAY
:0 wayland-0

$ gddccontrol
GUI: No monitor supporting DDC/CI available

$ sudo gddccontrol
No protocol specified

(gddccontrol:20140): Gtk-WARNING **: 12:11:34.961: cannot open display: :0

-- System Information:
Debian Release: 10.0
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (860, 
'testing-proposed-updates'), (800, 'unstable-debug'), (800, 'unstable'), (790, 
'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 
'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages gddccontrol depends on:
ii  ddccontrol  0.4.4-1
ii  libc6   2.28-10
ii  libddccontrol0  0.4.4-1
ii  libglib2.0-02.58.3-2
ii  libgtk2.0-0 2.24.32-3
ii  libpango-1.0-0  1.42.4-6
ii  policykit-1 0.105-25

gddccontrol recommends no packages.

gddccontrol suggests no packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#930717: unblock: pysynphot/0.9.12+dfsg-3

[Paul Gevers]

Hi Ole,

On 19-06-2019 10:10, Ole Streicher wrote:
> unblock pysynphot/0.9.12+dfsg-3

Unblocked, thanks.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#930669: unblock: qtbase-opensource-src/5.11.3+dfsg1-2

[Paul Gevers]

Hi Dmitry,

On 19-06-2019 06:10, Paul Gevers wrote:
> Hi Dmitry,
> 
> On 18-06-2019 09:41, Dmitry Shachnev wrote:
>> Please see #911844 for details.
> 
> Interesting bug report :)
> 
>> unblock qtbase-opensource-src/5.11.3+dfsg1-2
> 
> Unblocked, thanks.

Your package is blocked behind gcc-8. So although unblocked, it will not
be part of buster at release time. Sorry. If you still want to deploy
the fix in buster, please take the point release route.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#931141: grub-pc: Update hangs (not the same as 558422)

[Nigel Horne]

Package: grub-pc
Version: 2.02+dfsg1-19
Severity: normal

Dear Maintainer,

'apt upgrade' hangs on updating grub.  No kill signal makes
the command grub-mkdevicemap stop, unlike bug 558422, since it's in a D state.

Running strace clearly shows where it's hung:

lstat("/dev/sdc", {st_mode=S_IFBLK|0660, st_rdev=makedev(0x8, 0x20), 
...}) = 0
openat(AT_FDCWD, 
"/dev/disk/by-id/usb-Generic-_SD_MMC_058F63626476-0:0", O_RDONLY) = -1 
ENOMEDIUM (No medium found)
lstat("/dev", {st_mode=S_IFDIR|0755, st_size=3900, ...}) = 0
lstat("/dev/disk", {st_mode=S_IFDIR|0755, st_size=140, ...}) = 0
lstat("/dev/disk/by-id", {st_mode=S_IFDIR|0755, st_size=540, ...}) = 0
lstat("/dev/disk/by-id/usb-Generic-_Compact_Flash_058F63626476-0:1", 
{st_mode=S_IFLNK|0777, st_size=9, ...}) = 0
readlink("/dev/disk/by-id/usb-Generic-_Compact_Flash_058F63626476-0:1", 
"../../sdd", 4095) = 9
lstat("/dev/sdd", {st_mode=S_IFBLK|0660, st_rdev=makedev(0x8, 0x30), 
...}) = 0
openat(AT_FDCWD, 
"/dev/disk/by-id/usb-Generic-_Compact_Flash_058F63626476-0:1", O_RDONLY) = -1 
ENOMEDIUM (No medium found)
lstat("/dev", {st_mode=S_IFDIR|0755, st_size=3900, ...}) = 0
lstat("/dev/disk", {st_mode=S_IFDIR|0755, st_size=140, ...}) = 0
lstat("/dev/disk/by-id", {st_mode=S_IFDIR|0755, st_size=540, ...}) = 0
lstat("/dev/disk/by-id/usb-Generic-_SM_xD-Picture_058F63626476-0:2", 
{st_mode=S_IFLNK|0777, st_size=9, ...}) = 0
readlink("/dev/disk/by-id/usb-Generic-_SM_xD-Picture_058F63626476-0:2", 
"../../sde", 4095) = 9
lstat("/dev/sde", {st_mode=S_IFBLK|0660, st_rdev=makedev(0x8, 0x40), 
...}) = 0
openat(AT_FDCWD, 
"/dev/disk/by-id/usb-Generic-_SM_xD-Picture_058F63626476-0:2", O_RDONLY

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda6 / ext4 rw,noatime,errors=remount-ro 0 0
/dev/sdb1 /var ext4 rw,noatime,errors=remount-ro 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos
insmod ext2
set root='hd0,msdos6'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos6 
--hint-efi=hd0,msdos6 --hint-baremetal=ahci0,msdos6 --hint='hd0,msdos6'  
d88eb8d2-bf12-44bd-abc2-2d297da04816
else
  search --no-floppy --fs-uuid --set=root d88eb8d2-bf12-44bd-abc2-2d297da04816
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_GB
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-d88eb8d2-bf12-44bd-abc2-2d297da04816' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos6'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos6 
--hint-efi=hd0,msdos6 --hint-baremetal=ahci0,msdos6