Bug#937624: Test suite errors with Python3 (Was: Why is dh_auto_clean calling python2.7? (Was: Bug#937624: python-burrito: ...))

2019-08-31 Thread Andreas Tille
On Sat, Aug 31, 2019 at 04:47:42PM -0400, Sandro Tosi wrote:
> burrito.util.ApplicationError: Could not open "/tmp/fixed.txt"
> 
> is the file there?

No, that file does not exist.

 $ grep -R /tmp/fixed.txt
burrito/tests/test_util.py:f = open('/tmp/fixed.txt','w')
burrito/tests/test_util.py:result['fixed_file'] = 
ResultPath(Path='/tmp/fixed.txt')
burrito/tests/test_util.py:result['fixed_file'] = 
ResultPath(Path='/tmp/fixed.txt')

The code snippet that should create the file is

...
#generate some stderr
print('I am stderr', file=stderr)

# Write the fixed file
f = open('/tmp/fixed.txt','w')
f.writelines(['I am fixed file'])
f.close()
...

I have no idea why it might fail.

Kind regards

 Andreas.

> > ...
> > ==
> > ERROR: CLAppTester: Alternative TmpDir functions as expected
> > --
> > Traceback (most recent call last):
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> >  line 304, in __call__
> > result_paths)
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> >  line 330, in _handle_app_result_build_failure
> > raise ApplicationError("Error constructing CommandLineAppResult.")
> > burrito.util.ApplicationError: Error constructing CommandLineAppResult.
> >
> > During handling of the above exception, another exception occurred:
> >
> > Traceback (most recent call last):
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/tests/test_util.py",
> >  line 769, in test_TmpDir
> > result = app()
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> >  line 308, in __call__
> > raise e1
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> >  line 299, in __call__
> > result_paths=result_paths)
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> >  line 104, in __init__
> > raise ApplicationError('Could not open %s' % value.Path)
> > burrito.util.ApplicationError: Could not open "/tmp/fixed.txt"
> >
> > ==
> > ERROR: CLAppTester: TmpDir functions as expected w space in name
> > --
> > Traceback (most recent call last):
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> >  line 304, in __call__
> > result_paths)
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> >  line 330, in _handle_app_result_build_failure
> > raise ApplicationError("Error constructing CommandLineAppResult.")
> > burrito.util.ApplicationError: Error constructing CommandLineAppResult.
> >
> > During handling of the above exception, another exception occurred:
> >
> > Traceback (most recent call last):
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/tests/test_util.py",
> >  line 797, in test_TmpDir_w_space
> > result = app()
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> >  line 308, in __call__
> > raise e1
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> >  line 299, in __call__
> > result_paths=result_paths)
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> >  line 104, in __init__
> > raise ApplicationError('Could not open %s' % value.Path)
> > burrito.util.ApplicationError: Could not open "/tmp/fixed.txt"
> >
> > ==
> > ERROR: CLAppTester: WorkingDir functions as expected
> > --
> > ...
> > ==
> > ERROR: CLAppTester: parameters turned on, no data, space in command
> > --
> > Traceback (most recent call last):
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> >  line 304, in __call__
> > result_paths)
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> >  line 330, in _handle_app_result_build_failure
> > raise ApplicationError("Error constructing CommandLineAppResult.")
> > burrito.util.ApplicationError: Error constructing CommandLineAppResult.
> >
> > During handling of the above exception, another exception occurred:
> >
> > Traceback (most recent call last):
> >   File 
> > 

Bug#936399: diodon: Python2 removal in sid/bullseye

2019-08-31 Thread Scott Kitterman
On Fri, 30 Aug 2019 07:15:05 + Matthias Klose  wrote:
> Package: src:diodon
> Version: 1.8.0-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.

I've attached a fix in the form of an NMU debdiff.  I don't currently plan to 
NMU, but may later if this remains open.  Please fix.

Scott Kdiff -Nru diodon-1.8.0/debian/changelog diodon-1.8.0/debian/changelog
--- diodon-1.8.0/debian/changelog	2018-03-11 15:37:08.0 -0400
+++ diodon-1.8.0/debian/changelog	2019-09-01 00:55:31.0 -0400
@@ -1,3 +1,13 @@
+diodon (1.8.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch build system to python3 (Closes: #936399)
+  * Drop use of dh_python2 in debian/rules, uneeded since python is only used
+during the build
+  * Fix clean rule to also remove po cache so package builds twice in a row
+
+ -- Scott Kitterman   Sun, 01 Sep 2019 04:55:31 +
+
 diodon (1.8.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru diodon-1.8.0/debian/control diodon-1.8.0/debian/control
--- diodon-1.8.0/debian/control	2018-03-11 15:37:08.0 -0400
+++ diodon-1.8.0/debian/control	2019-09-01 00:55:31.0 -0400
@@ -11,7 +11,7 @@
libpeas-dev (>=1.1.1),
libxtst-dev (>= 1.2.0),
libzeitgeist-2.0-dev (>= 0.9.14),
-   python,
+   python3,
valac (>=0.26.0),
xvfb
 Standards-Version: 4.1.3
diff -Nru diodon-1.8.0/debian/rules diodon-1.8.0/debian/rules
--- diodon-1.8.0/debian/rules	2017-12-16 13:46:18.0 -0500
+++ diodon-1.8.0/debian/rules	2019-09-01 00:55:31.0 -0400
@@ -7,7 +7,7 @@
 endif
 
 %:
-	dh $@ --with python2
+	dh $@
 
 WAF=./waf
 
@@ -15,6 +15,7 @@
 	$(WAF) distclean $(WAFFLAGS)
 	rm -rf _build_
 	find -name '*.pyc' -delete
+	rm -rf po/.intlcache
 
 override_dh_auto_configure:
 	$(WAF) configure $(WAFFLAGS) --sysconfdir /etc --libdir /usr/lib/$(DEB_HOST_MULTIARCH)


Bug#939083: RM: neo -- RoQA; RC buggy, unmaintained, obsolete libs (python2)

2019-08-31 Thread Stuart Prescott
New Python 3 upstream can be found at

https://github.com/NeuralEnsemble/python-neo

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7



Bug#932197: Please switch to Python 3

2019-08-31 Thread Scott Kitterman
On Tue, 16 Jul 2019 16:07:38 +0200 Thomas Goirand  wrote:
> Source: nipype
> Version: 1.1.9-1
> Severity: important
> 
> Hi,
> 
> I'd like to switch python-xvfbwrapper to Python 3 only, and noticed that
> nipype only has Python 2 support. Python 2 is going to be removed from
> Sid/Testing.

Python3 is supported upstream.

Scott K



Bug#939083: RM: neo -- RoQA; RC buggy, unmaintained, obsolete libs (python2)

2019-08-31 Thread Scott Kitterman
Package: ftp.debian.org
Severity: normal

Out of testing for almost two years, missed the last stable release.

Scott K



Bug#939082: RM: spykeutils -- RoQA; RC buggy, unmaintained, obsolete libs (python2)

2019-08-31 Thread Scott Kitterman
Package: ftp.debian.org
Severity: normal

Also depends on RC buggy libs.  Out of Testing for over two years.
Missed the last stable release.

Scott K



Bug#939081: RM: spykeviewer -- RoQA; RC buggy, unmaintained, obsolete libs (python2 and Qt4)

2019-08-31 Thread Scott Kitterman
Package: ftp.debian.org
Severity: normal

Also, depends on RC buggy packages.  Out of testing for over two years
and missed the last release.

Scott K



Bug#937416: Bug #937416: fixed in pycxx 7.0.3-3

2019-08-31 Thread Scott Kitterman
I neglected to check reverse build-depends before I uploaded this, so python-
cxx-dev will stick around for awhile as cruft until it is no longer needed.

Scott K



Bug#939080: PHP4-style constructors are deprecated

2019-08-31 Thread William Blough
Source: nusoap
Severity: normal
Tags: patch

PHP4-style constructors are deprecated.  They currently produce a lot of
noisy warnings, and support for them will be removed in PHP8.

The attached patch renames the constructors to use the new convention,
and introduces wrapper functions with the old names for backwards
compatibility.


-- System Information:
Debian Release: 10.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
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_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From 5853b33679f8012150983fef207207355b67cdce Mon Sep 17 00:00:00 2001
From: Bill Blough 
Date: Sat, 31 Aug 2019 22:39:12 -0400
Subject: [PATCH] Add new-style constructors

---
 debian/patches/add_new_constructors.patch | 636 ++
 debian/patches/series |   1 +
 2 files changed, 637 insertions(+)
 create mode 100644 debian/patches/add_new_constructors.patch

diff --git a/debian/patches/add_new_constructors.patch 
b/debian/patches/add_new_constructors.patch
new file mode 100644
index 000..abade5c
--- /dev/null
+++ b/debian/patches/add_new_constructors.patch
@@ -0,0 +1,636 @@
+Description: Add new-style constructors
+ Old-style (php4) constructors are deprecated.  They generate warnings
+ currently, and will stop working in php8.  Adding new-style constructors
+ while keeping the old ones silences the warnings and prepares for php8
+Author: Bill Blough 
+Last-Update: 2019-08-31
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/lib/class.nusoap_base.php
 b/lib/class.nusoap_base.php
+@@ -222,11 +222,20 @@ class nusoap_base {
+   *
+   * @access   public
+   */
+-  function nusoap_base() {
++  function __construct() {
+   $this->debugLevel = 
$GLOBALS['_transient']['static']['nusoap_base']['globalDebugLevel'];
+   }
+ 
+   /**
++  * old constructor
++  *
++  * @access   public
++  */
++  function nusoap_base() {
++$self::__construct();
++  }
++
++  /**
+   * gets the global debug level, which applies to future instances
+   *
+   * @return   integer Debug level 0-9, where 0 turns off
+@@ -993,4 +1002,4 @@ function usleepWindows($usec)
+ }
+ 
+ 
+-?>
+\ No newline at end of file
++?>
+--- a/lib/class.soap_fault.php
 b/lib/class.soap_fault.php
+@@ -45,7 +45,7 @@ class nusoap_fault extends nusoap_base {
+ * @param string $faultstring human readable error message
+ * @param mixed $faultdetail detail, typically a string or array of string
+   */
+-  function 
nusoap_fault($faultcode,$faultactor='',$faultstring='',$faultdetail=''){
++  function 
__construct($faultcode,$faultactor='',$faultstring='',$faultdetail=''){
+   parent::nusoap_base();
+   $this->faultcode = $faultcode;
+   $this->faultactor = $faultactor;
+@@ -54,6 +54,18 @@ class nusoap_fault extends nusoap_base {
+   }
+ 
+   /**
++  * old constructor
++*
++* @param string $faultcode (SOAP-ENV:Client | SOAP-ENV:Server)
++* @param string $faultactor only used when msg routed between multiple 
actors
++* @param string $faultstring human readable error message
++* @param mixed $faultdetail detail, typically a string or array of string
++  */
++  function 
nusoap_fault($faultcode,$faultactor='',$faultstring='',$faultdetail=''){
++$self::__construct($faultcode,$faultactor,$faultstring,$faultdetail);
++}
++
++  /**
+   * serialize a fault
+   *
+   * @return   string  The serialization of the fault instance.
+@@ -87,4 +99,4 @@ class soap_fault extends nusoap_fault {
+ }
+ 
+ 
+-?>
+\ No newline at end of file
++?>
+--- a/lib/class.soap_parser.php
 b/lib/class.soap_parser.php
+@@ -57,7 +57,7 @@ class nusoap_parser extends nusoap_base
+   * @paramstring $decode_utf8 whether to decode UTF-8 to ISO-8859-1
+   * @access   public
+   */
+-  function 
nusoap_parser($xml,$encoding='UTF-8',$method='',$decode_utf8=true){
++  function 
__construct($xml,$encoding='UTF-8',$method='',$decode_utf8=true){
+   parent::nusoap_base();
+   $this->xml = $xml;
+   $this->xml_encoding = $encoding;
+@@ -144,6 +144,19 @@ class nusoap_parser extends nusoap_base
+   }
+ 
+   /**
++  * old constructor
++  *
++  * @paramstring $xml SOAP message
++  * @paramstring $encoding character encoding scheme of message
++  * @paramstring $method method for which XML is parsed (unused?)
++  * @paramstring $decode_utf8 whether to decode UTF-8 to ISO-8859-1
++  * @access   

Bug#937121: ncbi-blast+: Python2 removal in sid/bullseye

2019-08-31 Thread Aaron M. Ucko
Matthias Klose  writes:

> - Convert your Package to Python3. This is the preferred option.

Thanks for the report!  I'm pleased to observe that this option looks
very readily feasible; I should be able to implement it within the next
day or two.

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



Bug#939079: nouveau: screen dimensions and resolution are wrong

2019-08-31 Thread Vincent Lefevre
Package: src:linux
Version: 5.2.9-2
Severity: normal

With the nouveau driver, I get:

$ xdpyinfo
[...]
screen #0:
  dimensions:3200x1800 pixels (846x476 millimeters)
  resolution:96x96 dots per inch
[...]

which is wrong!

As a comparison, with the nvidia driver:

[...]
screen #0:
  dimensions:3200x1800 pixels (350x191 millimeters)
  resolution:232x239 dots per inch
[...]

which is correct.

This prevents HiDPI detection.

-- Package-specific info:
** Version:
Linux version 5.2.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 
(Debian 8.3.0-21)) #1 SMP Debian 5.2.9-2 (2019-08-21)

** Command line:
BOOT_IMAGE=/vmlinuz-5.2.0-2-amd64 root=/dev/mapper/zira--vg-root ro quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: Hewlett-Packard
product_name: HP ZBook 15 G2
product_version: A3008CD10003
chassis_vendor: Hewlett-Packard
chassis_version: 
bios_vendor: Hewlett-Packard
bios_version: M70 Ver. 01.08
board_vendor: Hewlett-Packard
board_name: 2253
board_version: KBC Version 03.10

** Loaded modules:
ipt_REJECT
nf_reject_ipv4
xt_multiport
nft_compat
nft_counter
nf_tables
nfnetlink
psnap
llc
cpufreq_conservative
cpufreq_userspace
cpufreq_powersave
cmac
bnep
snd_hda_codec_hdmi
intel_rapl
arc4
x86_pkg_temp_thermal
intel_powerclamp
mei_wdt
btusb
btrtl
btbcm
binfmt_misc
btintel
coretemp
snd_hda_codec_realtek
nouveau
bluetooth
iwlmvm
snd_hda_codec_generic
ledtrig_audio
mac80211
kvm
uvcvideo
irqbypass
ttm
videobuf2_vmalloc
videobuf2_memops
intel_cstate
videobuf2_v4l2
snd_hda_intel
intel_uncore
videobuf2_common
drm_kms_helper
snd_hda_codec
iwlwifi
videodev
snd_hda_core
drbg
iTCO_wdt
tpm_infineon
hp_wmi
snd_hwdep
joydev
intel_rapl_perf
pcspkr
serio_raw
iTCO_vendor_support
rtsx_pci_ms
sparse_keymap
mxm_wmi
wmi_bmof
media
pcc_cpufreq
cfg80211
memstick
sg
drm
ansi_cprng
watchdog
snd_pcm
ecdh_generic
snd_timer
mei_me
ecc
snd
mei
rfkill
soundcore
i2c_algo_bit
ie31200_edac
tpm_tis
battery
tpm_tis_core
hp_accel
lis3lv02d
tpm
evdev
input_polldev
hp_wireless
rng_core
button
ac
parport_pc
ppdev
lp
parport
sunrpc
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
dm_crypt
dm_mod
sr_mod
cdrom
sd_mod
hid_apple
hid_generic
usbhid
hid
crct10dif_pclmul
crc32_pclmul
crc32c_intel
ghash_clmulni_intel
rtsx_pci_sdmmc
mmc_core
ahci
libahci
aesni_intel
libata
aes_x86_64
crypto_simd
cryptd
glue_helper
xhci_pci
xhci_hcd
scsi_mod
psmouse
rtsx_pci
ehci_pci
ehci_hcd
i2c_i801
lpc_ich
mfd_core
e1000e
usbcore
ptp
pps_core
usb_common
video
wmi

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v3/4th Gen Core 
Processor DRAM Controller [8086:0c04] (rev 06)
Subsystem: Hewlett-Packard Company Xeon E3-1200 v3/4th Gen Core 
Processor DRAM Controller [103c:2253]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel modules: ie31200_edac

00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th Gen Core 
Processor PCI Express x16 Controller [8086:0c01] (rev 06) (prog-if 00 [Normal 
decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset 
Family USB xHCI [8086:8c31] (rev 04) (prog-if 30 [XHCI])
Subsystem: Hewlett-Packard Company 8 Series/C220 Series Chipset Family 
USB xHCI [103c:2253]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:16.0 Communication controller [0780]: Intel Corporation 8 Series/C220 Series 
Chipset Family MEI Controller #1 [8086:8c3a] (rev 04)
Subsystem: Hewlett-Packard Company 8 Series/C220 Series Chipset Family 
MEI Controller [103c:2253]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: mei_me
Kernel modules: mei_me

00:16.3 Serial controller [0700]: Intel Corporation 8 Series/C220 Series 
Chipset Family KT Controller [8086:8c3d] (rev 04) (prog-if 02 [16550])
Subsystem: Hewlett-Packard Company 8 Series/C220 Series Chipset Family 
KT Controller [103c:2253]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
 

Bug#935885: fuse installtion postinst script syntax error

2019-08-31 Thread Bernhard Übelacker
Dear Maintainer,
migth this be related to this bug:
https://bugs.debian.org/935496

Kind regards,
Bernhard



Bug#927689: pandoc: Package newer version available upstream

2019-08-31 Thread Jonas Smedegaard
Quoting Clint Adams (2019-09-01 00:28:02)
> On Sun, Apr 21, 2019 at 12:37:47PM +0200, Jonas Smedegaard wrote:
> > As soon as those libraries gets updated - which will happen at some 
> > point _after_ Buster gets released - Pandoc will get updated too.
> 
> It should be safe now (or when the mirrors update) to upload pandoc 
> 2.5.

Great!

Building now...

If someone has spare time to package libraries, then the only thing 
blocking from upgrading to Pandoc 2.6 is ipynb 0.1 or newer: 
https://hackage.haskell.org/package/ipynb

...and newest release, Pandoc 2.7.3 additionally needs skylighting 0.8.1 
or newer, cmark-gfm 0.3 or newer, and hslua-module-system 0.2 or newer: 
https://hackage.haskell.org/package/hslua-module-system


 - Jonas

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

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


signature.asc
Description: signature


Bug#939078: bro: unfulfilled (build) dependencies libbroker-dev and libbroker0

2019-08-31 Thread Matthias Klose

Package: src:bro
Version: 2.6.1+ds1-1
Severity: serious
Tags: sid bullseye

according to https://tracker.debian.org/pkg/bro, it references a nn-existing 
libbroker0, and doesn't build on any other architecture because of a missing 
libbroker-dev package.




Bug#939077: preserve ordering of items when replacing debhelper with debhelper-compat

2019-08-31 Thread Jelmer Vernooij
Package: lintian-brush
Version: 0.26
Severity: normal

When replacing debhelper in Build-Depends with debhelper-compat, lintian-brush
currently drops debhelper and then adds debhelper-compat to the end of the
dependency list.

Instead, it should just replace debhelper with debhelper-compati in the same
location.

See e.g. 
https://salsa.debian.org/ruby-team/gist/commit/bbcaea21a40b7763d42a588a09715aa7f3b0ea42

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

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

Versions of packages lintian-brush depends on:
ii  devscripts   2.19.6
ii  python3  3.7.3-1
ii  python3-breezy   3.0.1-2
ii  python3-debian   0.1.35
ii  python3-distro-info  0.21
ii  python3-dulwich  0.19.13-1
ii  python3-levenshtein  0.12.0-3+b1
ii  python3-pkginfo  1.4.2-2
ii  python3-ruamel.yaml  0.15.34-1+b1

Versions of packages lintian-brush recommends:
ii  dos2unix   7.4.0-2
ii  gpg2.2.17-3
ii  lintian2.19.0
ii  python3-asyncpg0.18.3-2
ii  python3-pyinotify  0.9.6-1.2

lintian-brush suggests no packages.

-- no debconf information



Bug#676409: ITP: ruby-ammeter -- Write specs for your Rails 3+ generators

2019-08-31 Thread Georg Faerber
control: retitle -1 ITP: ruby-ammeter -- Write specs for your Rails 3+ 
generators
control: owner -1 guptautkarsh2...@gmail.com
control: tags -1 + pending

This package got uploaded to NEW, updating the bug metadata accordingly.

Cheers,
Georg



Bug#936051: sdl-image1.2 1.2.12-5+deb9u2 flagged for acceptance

2019-08-31 Thread Adam D Barratt
package release.debian.org
tags 936051 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: sdl-image1.2
Version: 1.2.12-5+deb9u2

Explanation: fix buffer overflows [CVE-2018-3977 CVE-2019-5058 CVE-2019-5052], 
out-of-bounds access [CVE-2019-12216 CVE-2019-12217 CVE-2019-12218 
CVE-2019-12219 CVE-2019-12220 CVE-2019-12221 CVE-2019-1 CVE-2019-5051]



Bug#936056: sdl-image1.2 1.2.12-10+deb10u1 flagged for acceptance

2019-08-31 Thread Adam D Barratt
package release.debian.org
tags 936056 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: sdl-image1.2
Version: 1.2.12-10+deb10u1

Explanation: fix buffer overflows [CVE-2019-5052 CVE-2019-7635], out-of-bounds 
access [CVE-2019-12216 CVE-2019-12217 CVE-2019-12218 CVE-2019-12219 
CVE-2019-12220 CVE-2019-12221 CVE-2019-1 CVE-2019-5051]



Bug#932684: gnupg2 2.2.12-1+deb10u1 flagged for acceptance

2019-08-31 Thread Adam D Barratt
package release.debian.org
tags 932684 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: gnupg2
Version: 2.2.12-1+deb10u1

Explanation: 



Bug#939019: epiphany-browser 3.32.1.2-3~deb10u1 flagged for acceptance

2019-08-31 Thread Adam D Barratt
package release.debian.org
tags 939019 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: epiphany-browser
Version: 3.32.1.2-3~deb10u1

Explanation: ensure that the web extension loads our bundled copy of libdazzle



Bug#935827: cryptsetup 2.1.0-5+deb10u2 flagged for acceptance

2019-08-31 Thread Adam D Barratt
package release.debian.org
tags 935827 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: cryptsetup
Version: 2.1.0-5+deb10u2

Explanation: fix mapped segments overflow on 32-bit architectures



Bug#935485: Looking for help with a recently removed package, kcollectd

2019-08-31 Thread Antonio Russo
Hello everyone,

I am looking for a new home for kcollectd, a tool for viewing log information,
that was recently removed from unstable because it lacked a Qt 5 port [1]. I
have ported that package and I've taken over the upstream (which has been dead
for years) [2].  I'm offering to maintain the Debian package, and I've been
directed here, at the suggestion of another DD, because this community may have
interest in helping out with this package.

Of note, I spoke with Scott Kitterman, who requested the removal of kcollectd,
and he said he knows of no other reason the package should be removed.

The updated packaging fixes several outstanding bugs, and makes the Debian
lintian report much cleaner (one is, I believe, a false positive, and the other
is due to lack of package tests which aren't really relevant to this kind of
UI software).

Is anyone here willing to sponsor this package, offer any criticism of
the package, or further direct me to a place where I might get such help?

Thank you,
Antonio Russo

[1] https://bugs.debian.org/935223
[2] https://gitlab.com/aerusso/kcollectd
[3] https://bugs.debian.org/935485



Bug#939076: firmware-bnx2x: missing firmware: bnx2x/bnx2x-e2-7.13.11.0.fw

2019-08-31 Thread Lucas Nussbaum
Package: firmware-bnx2x
Version: 20190717-1
Severity: normal

Hi,

With kernel version 5.2.9-2, systems fail to boot with:
[   28.712344] bnx2x :01:00.0: firmware: failed to load 
bnx2x/bnx2x-e2-7.13.11.0.fw (-2)
[   28.723204] firmware_class: See https://wiki.debian.org/Firmware for 
information about missing firmware
[   28.734540] bnx2x :01:00.0: Direct firmware load for 
bnx2x/bnx2x-e2-7.13.11.0.fw failed with error -2
[   28.746051] bnx2x: [bnx2x_func_hw_init:6002(eno1)]Error loading firmware
[   28.754354] bnx2x: [bnx2x_nic_load:2730(eno1)]HW init failed, aborting

Version bnx2x/bnx2x-e2-7.13.11.0.fw is available upstream according to
https://github.com/wkennington/linux-firmware/commit/8fcf0ec44c11f1865f8451c0265e84bf16365312
but not included in firmware-bnx2x.

Could you please update the package to include it?

Thanks!

Lucas



Bug#935485: change to ITP

2019-08-31 Thread Antonio Russo
reassign 935485 wnpp
retitle 935485 RFS: kcollectd/0.10.2-1 ITP -- simple collectd graphing 
front-end for KDE
thanks

Changed to WNPP ITP bug per above.



Bug#930581: root-tail: buggy patch in debian package

2019-08-31 Thread Axel Beckert
Hi Marc,

Axel Beckert wrote:
> > While doing so, I found that debian has a patch that actually introduces a
> > bug:
> > 
> >config.h.patch Description: Use proper X fonts selector
> > 
> > This replaces the correct value for the font pattern by an incorrect one
> > (USE_FONT specified a font name, not a "X fonts selector", which, as far
> > as I know, does not exist in X).

The 1.3 (and 1.2) man page states:

   --font | -fn FONTSPEC
  Use font FONTSPEC. This can be either a fixed
  width font like -fn fixed or any font  using  -fn
  '-*-*-*-*-*-*-*-*-*-*-*-*-*-*' with the appropriate
  fields filled out (see xfontsel). Specifying a different
  FONTSPEC before each filename will cause each file to be
  displayed in a different font.

So according to '-*-*-*-*-*-*-*-*-*-*-*-*-*-*' is a valid string for
the base font variable, right? And Debian lets this variable default
to "-*-*-*-*-*-*-*-*-*-*-*-*-*-*", i.e. exactly the same value. Or do
I oversee something?

> Will at least check if I can still reproduce the crash reported in
> #298708 without that patch.

Actually I could neither get "-fn" nor "--font" to cause any change in
the displayed screen. I tried X font selectors like
'-misc-fixed-medium-r-*-*-12-*-*-*-*-60-iso10646-1' or
'-misc-fixed-medium-r-*-*-12-*-*-*-*-60-iso8859-1' as well as TrueType
font names like "Terminus", "$Fontname-$Fontsize", "xft:$Fontname" ,
"xft:$Fontname-$Fontsize". And I tried root-tail 1.3 and 1.2.

Not sure what I did wrong.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



Bug#927689: pandoc: Package newer version available upstream

2019-08-31 Thread Clint Adams
On Sun, Apr 21, 2019 at 12:37:47PM +0200, Jonas Smedegaard wrote:
> As soon as those libraries gets updated - which will happen at some 
> point _after_ Buster gets released - Pandoc will get updated too.

It should be safe now (or when the mirrors update) to upload
pandoc 2.5.



Bug#884999: debhelper: Please default Rules-Require-Root to no

2019-08-31 Thread Guillem Jover
Hi!

On Fri, 2019-05-24 at 13:42:28 +0900, Hideki Yamane wrote:
> > > In summary: The debhelper fundamentally cannot affect whether
> > > Rules-Requires-Root: no is default or not.  The debhelper compat level
> > > system is the wrong interface to do this as well.
> > > 
> > > That said, in a distant future, I hope we can flip the default of
> > > Rules-Requires-Root.  But when that comes, it will not be via a
> > > debhelper compat level AFAICT.
> 
>  If we want to implement "Rules-Requires-Root: no" mandatory,
>  is it dpkg-dev and policy issue?

The current thinking is that it would be acceptable to switch the
default by introducing a new dpkg-dev-specific compat level. See
.

I think the argument put forward by Adrian Bunk, about this possibly
being just another transition among many we do that can break
non-smallish parts of the archive makes sense, except that I fear in
this case it might cause silent breakage, or at least breakage not
detectable w/o an archive-wide rebuild, with several permutations,
such as binary-indep-only, binary-arch-only, etc. And this still does
not cover external users. And in any case I've not heard anyone
expressing interest in handling such transition, so that's pretty much
a non-starter.

Thanks,
Guillem



Bug#939075: debian 10 firmware-ath9k-htc usb wifi card ar9271 does not work

2019-08-31 Thread ronwirring
package: firmware-ath9k-htc 

version: 1.4.0-97-g75b3e59+dfsg-3

debian 10

kernel: 4.19.0-5-amd64

usb wifi card ar9271

The wifi card does not work. If you add
[device]
wifi.scan-rand-mac-address=no
to file
/etc/NetworkManager/NetworkManager.conf
then the wifi card works.
Please make
firmware-ath9k-htc
work. Have it support mac address randomization. It is unsound
that the only free software running usb wifi
card does not work.

During installation of debian and you have an ar9271
usb wifi card connected debian does not provide
the option to import a free software file
which enables the wifi card to
work.

Greetings



Bug#935304: [libpam-systemd] This bug also prevents KDE Plasma5 Desktop from being used in Buster for SysV init users

2019-08-31 Thread Stephen Lyons
Package: libpam-systemd
Version: 241-5
Control: severity -1 important

--- Please enter the report below this line. ---

I was using the KDE Plasma 5 Desktop in Stretch but during the upgrade
process to Buster this dependency broke things for me as a SysV init
user as the following dependency chain exists:

plasma-desktop ->
plasma-workspace ->
udisks2 ->
libpam-systemd ->
systemd AND systemd-sysv

The dependency on systemd-sysv did NOT appear in the previous "Stretch"
and I was happy to tolerate systemd on my system as long as it was NOT
PID1 i.e. with a SysV init. This bug thus seems to be a regression in
that I can no longer have this.

As this forces a change of Desktop and all the packages associated with
it I feel this warrants remarking this as an "important" bug and I have
attempted to do so...

Stephen

--- System information. ---
Architecture: Kernel:   Linux 4.19.0-5-amd64

Debian Release: 10.0
  500 stable  security.debian.org
  500 stable  ftp.uk.debian.org
  500 stable  apt.spideroak.com
--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.
-- 
To mitigate against EFAIL attacks email messages will be handled only as
plain text, please do not send emails in an HTML form to this recipient!



signature.asc
Description: OpenPGP digital signature


Bug#939074: RM: python-raven -- ROM; NPOASR; RC-buggy

2019-08-31 Thread Vincent Bernat
Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl1q7HsSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5FlAP/34wIc24kphH0em5pjgmOyaoR9KCFfJK
NPNH/9UyQYLhXjY8IFgKY0dsxVR5cqH0zzUqgzxFeRCvBH738rTMb4k7LP4ijLUt
jUu+UbLR5Yo+EXgD06DxTw3SrjzDl4WhhNXTiX43IK4CSMB3omVKypo/X3G4E0gR
ut+YOVC2gkDK+8l3GOrOkuarEsWX+DW5P8PKaUH+5/bv3XFrzxxP7P916LFcTU+N
8AuWXBSc3rx8rD/hg/oO2gTa6KAe9AnqfkXehuZ6mgqaPqOXdtZ4Xu/+7U8DkqDa
Ss6p1mvLNLxLO8NQijp5x8MXdS2Sh+QYBcSjtkhSLxSQxciWhqVrZdHkEc6CrAJY
WD3hTxAwzjwSpxBSvDCznR5H5lBrwqqUI3TWTN3AkPaZvi3vp30bwfVC2S62ggMV
kHBqCcPg6gkuBQnpRfvkcLDpKsgxYS+3jtNKoco78aFpIuKqdGkvi/7GoUdZP2t2
NrKQLaswq5suEd6JvU79m8pYF1g5xSQKg4QsgtM7kviMv+PatKBS94A/D8lYq+XY
hl0W3AZN2D8q20I8XKq0xgzFW0IYpmYUHOBNxlWNadVsfBcAui7qVVvEIu8+y/VN
i7H8aydk7yzL+ws2xvJtGjTWMlQStj38KOk4DaY+ljMSSO2CoglGO+0d9uu/mJZ7
XdklcKyl0Jfj
=zHY/
-END PGP SIGNATURE-



Bug#935485: Looking for help to adopt recently removed package, kcollectd

2019-08-31 Thread Lisandro Damián Nicanor Pérez Meyer
Hi Antonio!

On Sat, 31 Aug 2019 13:48:25 -0600 Antonio Russo 
wrote:
> Hello everyone,
>
> I've been following a bit of a breadcrumb trail, and I hope I'm in the
right
> place now. kcollectd, a tool for viewing log information, has recently
been
> removed from unstable because it lacked a Qt 5 port [1]. I have ported
that
> package and I've taken over the upstream (which has been dead for years)
[2].
> I'm offering to maintain the Debian package, but I have received very
little
> response to my ITA RFS bug [3]. Should I refile this as an ITP bug, since
the
> package has, in fact, already been removed?
>
> I spoke with Scott Kitterman, who requested the removal, and he said
> knows of no other reason the package should be removed. The updated
> packaging fixes several outstanding bugs, and makes the Debian lintian
> report much cleaner (one is, I believe, a false positive, and the other
> is due to lack of package tests which aren't really relevant to this kind
of
> UI software).
>
> Is anyone here willing to sponsor this package, offer any criticism of
> the package, or direct me to a place where I might get such help?

I'll happily sponsor you. If you do IRC I'm lisandro on oftc, feel free to
ping me, specially on #debian-kde


Bug#936033: ITP: pyprof2calltree -- visualise Python cProfile data with this kcachegrind converter

2019-08-31 Thread Lisandro Damián Nicanor Pérez Meyer
I'll happily sponsor it.

El jue., 29 ago. 2019 07:03, Nicholas D Steeves 
escribió:

> Package: wnpp
> Severity: wishlist
> Owner: Nicholas D Steeves 
>
> Package name: pyprof2calltree
> Version : 1.4.4
> Upstream Author : Peter Waller 
> URL : https://github.com/pwaller/pyprof2calltree
> License : Expat, MIT, or custom-permissive (needs verification)
> Programming Lang: Python
> Description : visualise Python cProfile data with this kcachegrind
> converter
>
>  Pyprof2calltree converts cProfile data into a format that is
>  consumable by kcachegrind and qcachegrind for graphical calltree
>  analysis.  This combination provides similar capabilities to Snakeviz
>  or RunSnakeRun.
>  .
>  Pyprof2calltree is an adaptation of lsprofcalltree.py, by David
>  Allouche, Jp Calderone, Itamar Shtull-Trauring, and Johan Dahlin.  It
>  has been adapted to behave more like scripts in the
>  kcachegrind-converters package.  One of the authors' objectives is
>  for pyprof2calltree to become part of the official upstream kdesdk
>  package.
>  .
>  This package installs the library for Python 3.
>
> I am packaging this because of the cProfile visualisers Elpy (Emacs
> IDE for Python) supports: one displays in a browser, RunSnakeRune is
> Python 2 only, which leaves this package.  IMHO it's the most
> desirable, but I have a KDE bias.
>
> As I'm already on the QT/KDE Team and upstream intents to eventually
> merge it into kdesdk, I believe the KDE Extras project is probably the
> most appropriate place for it.  I will need a sponsor for the initial
> upload.
>
>
> Regards,
> Nicholas
>
>


Bug#930581: root-tail: buggy patch in debian package

2019-08-31 Thread Axel Beckert
Hi Marc,

I'm not the maintainer of the root-tail Debian package (it currently
has no maintainer, see https://bugs.debian.org/838406), but I'm
preparing a QA upload of the package to get 1.3 into Debian and the
package back to the current state of the art with regards to
packaging. Did that already once in the past.

Marc Lehmann wrote:
> while preparing release 1.3 of root-tail, I had a look at various
> distribution packages for potential bugfixes.

Noticed and appreciated it, thanks!

> While doing so, I found that debian has a patch that actually introduces a
> bug:
> 
>config.h.patch Description: Use proper X fonts selector
> 
> This replaces the correct value for the font pattern by an incorrect one
> (USE_FONT specified a font name, not a "X fonts selector", which, as far
> as I know, does not exist in X).

I must admit, I have no idea what could be right or wrong from a
theoretical side...

> While the effect is likely small on modenr systems, it nevertheless can
> lead to fonts being skipped that would normally be found when using the
> correct value, or even lead to no fonts being found at all when they would
> otherwise be found.
> 
> Please consider removing the buggy patch.

... but since that patch fixed a crash (see
https://bugs.debian.org/298708), I'd be rather cautions with removing
it.

Will at least check if I can still reproduce the crash reported in
#298708 without that patch.

P.S.: root-tail fails to compile with GCC 9 due to --as-needed being
passed to the linker by default with GCC 9. Solved that in Debian by
patching the Makefile:
https://salsa.debian.org/debian/root-tail/blob/master/debian/patches/fix-linker-and-compiler-options.patch

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



Bug#939052: mpd: Stuttering after about 4 to 5 second or longer pause.

2019-08-31 Thread Michel
Package: mpd
Version: 0.21.13-1
Followup-For: Bug #939052

Dear Maintainer,

Was about to close the s.d.o mpd webpage[0]. Saw that there was an
intermediate version of mpd 0.21.11. So installed mpd 0.21.11, to check
if the stuttering issue also affects 0.21.11.

Yes, mpd 0.21.11 is also affected with the stuttering issue.

Thank You

[0]  https://snapshot.debian.org/package/mpd/



Bug#939073: glances: Glances requires a network interface

2019-08-31 Thread Moshe Piekarski
Package: glances
Version: 3.1.1-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

To the maintainer,

Running glances without any network interfaces initialized,
(no network manager started yet) crashes with an ip plugin error.

Thank you for your time,
Moshe Piekarski

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

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

Versions of packages glances depends on:
ii  adduser3.118
ii  init-system-helpers1.57
ii  lsb-base   11.1.0
ii  node-normalize.css 8.0.1-3
ii  python33.7.3-1
ii  python3-future 0.16.0-1
ii  python3-pkg-resources  41.1.0-1
ii  python3-psutil 5.5.1-1+b1

Versions of packages glances recommends:
ii  hddtemp 0.3-beta15-53
ii  lm-sensors  1:3.5.0-3
ii  python3-bottle  0.12.15-2
ii  python3-docker  3.4.1-4
ii  python3-influxdb5.2.0-1
ii  python3-matplotlib  3.0.2-2+b1
ii  python3-netifaces   0.10.4-1+b1
ii  python3-pysnmp4 4.4.6+repack1-1
ii  python3-pystache0.5.4-6

Versions of packages glances suggests:
pn  glances-doc 
pn  python3-pynvml  

- -- debconf-show failed

-BEGIN PGP SIGNATURE-

iQJNBAEBCAA3FiEEXbk7X2RxJi0NGP5lMn/Nf3K/IoEFAl1pqP4ZHGRlYmlhbi5i
dWdzQG1lbGFjaGltLm5ldAAKCRAyf81/cr8igf1LD/4u+QZAdigb/KWgLRHFC3w6
xw4UiIZffFRAlrCqskcKxGlZGrHXeCpv1gbeS35OUKyf7W+AS3DOCWJWhNF+wnoJ
V3n1RtzNN+goshu6QBzJ0up9s8g6+jt4z8jYd9ZqF3pbj22sP13Hy3o67adWWsdc
srxQmXe4JydB0WrMVqVK/sVSZQIcPstsg2VODBvvV6PPxNR+LMxNf9v1do14tnXT
yJpzMQvxTzdYEuPKeQKhmh3GL5cBes98R+JLXtgOxEQzpBsCdzlUL4dwV9a3MF4j
0AkaDOc+AyzoDflHEw+E9wqK4Bc90Of806JydAyU/ESJCb9dO+O97z7BL/8qkulQ
Dlfj25tbmxBYhykyTIdNvNqSV5LK3soZZ6U9xVFDy1nnW3rorJ75RxqrLkex5HIh
XYFvwPS39R+6qP4sIzdYPWl2ZLcuyI6to8bpQIP8ksYfWUiSUfpNCFDPMDEmNu8y
cLI+7/wHUb89prJekIZex7Sjt6lYkfLbR2qr7irkbGHleulHROq4gWYcvr4b39q4
ki8MVlaTsFZaQjJgRoSpEDsxOXO/xMSYLOFICF8o4ErC5umA4D8iIKBX+Uc/4Dd2
53Ph7X2Hkg7xo7YyRXzmS2k66ZHhBj+60ya9R6F+7tjlF4GY9EJ7DWt2E01RVhsC
p5Zl6ySKHLnalwhin1OGqQ==
=5VLA
-END PGP SIGNATURE-



Bug#935485: [Pkg-kde-extras] Looking for help to adopt recently removed package, kcollectd

2019-08-31 Thread Boris Pek
Hi,

> I've been following a bit of a breadcrumb trail, and I hope I'm in the right
> place now. kcollectd, a tool for viewing log information, has recently been
> removed from unstable because it lacked a Qt 5 port [1]. I have ported that
> package and I've taken over the upstream (which has been dead for years) [2].
> I'm offering to maintain the Debian package, but I have received very little
> response to my ITA RFS bug [3]. Should I refile this as an ITP bug, since the
> package has, in fact, already been removed?

Yes, please sent ITP bug report against WNPP package, update changelog in your
package noticing closing of this bug and update the title of your RFS bug
report accordingly.

> I spoke with Scott Kitterman, who requested the removal, and he said
> knows of no other reason the package should be removed. The updated
> packaging fixes several outstanding bugs, and makes the Debian lintian
> report much cleaner (one is, I believe, a false positive, and the other
> is due to lack of package tests which aren't really relevant to this kind of
> UI software).
>
> Is anyone here willing to sponsor this package, offer any criticism of
> the package, or direct me to a place where I might get such help?

I would suggest to ask about sponsoring of your package in mailing list:
pkg-kde-talk (at) alioth-lists.debian.net

Unfortunately, I do not have enough spare time for sponsoring others packages
now and I have no idea about this specific package, so I cannot help directly.

Thanks for your contributions to Debian!

Best wishes,
Boris



Bug#939046: auto-apt-proxy should timeout earlier

2019-08-31 Thread Antonio Terceiro
Hi

On Sat, Aug 31, 2019 at 01:40:10PM +, southernt...@thunix.net wrote:
> Package: auto-apt-proxy
> Version: 11
> 
> auto-apt-proxy should timeout earlier when the local apt cache is not 
> reachable. It took several minutes before acknowledging the proxy was 
> unavailable:
> 
> > root@laptop:/home/user# time apt update
> > Hit:1 http://security.debian.org/debian-security buster/updates InRelease
> > Hit:2 http://packages.microsoft.com/repos/vscode stable InRelease
> > Get:3 http://debian.mirrors.ovh.net/debian buster InRelease [118 kB]
> > Get:4 http://debian.mirrors.ovh.net/debian buster-updates InRelease [49.3 
> > kB]
> > Get:5 http://debian.mirrors.ovh.net/debian buster-backports InRelease
> > Fetched 214 kB in 3s (81.4 kB/s)
> > Reading package lists... Done
> > Building dependency tree   
> > Reading state information... Done
> > 1 package can be upgraded. Run 'apt list --upgradable' to see it.
> > 
> > real7m40.237s
> > user0m2.930s
> > sys 0m0.723s
> 
> Given auto-apt-proxy is mostly useful in a LAN context, it should time
> out after seconds, not minutes. Obviously, fetching a package can take
> time, but simply querying the proxy should succeed or fail
> quasi-instantly.

Can you give me a hint how can one reproduce this issue? what was
exactly the state of your proxy to cause this?


signature.asc
Description: PGP signature


Bug#939072: src:python-raven: Should this package be removed

2019-08-31 Thread Scott Kitterman
Package: src:python-raven
Version: 6.3.0-2
Severity: serious
Justification: Policy 2.5

This package is not in Testing, has no rdepends, is RC buggy for quite
some time, and used python2, which we are trying to remove.  It's
currently blocking removal of at least python-celery which blocks quite
a number of other packages.

I think it would be better just to remove this package.

Scott K



Bug#939071: 6.4 Load Missing Firmware should mention unpacking zip/tar

2019-08-31 Thread Joey Hess
Source: installation-guide
Severity: normal

I recently had cause to re-read 
https://www.debian.org/releases/buster/amd64/ch06s04.en.html
and tried to follow the instructions, and I ended up with a firmware.zip
on a FAT filesystem, which d-i is not able to find firmware in.

The instructions assume that the user will unpack the zip or tarball
they download, but they don't say to do so. There's an implicit
assumption that the user won't consider firmware.zip to be a
firmware file. Also that the user knows how to extract zip files or
tarballs or what any of these file types are. 

I guess if I got it wrong, plenty of other users will get it wrong.

-- 
see shy jo


signature.asc
Description: PGP signature


Bug#825809: unclutter: diff for NMU version 8-21.1

2019-08-31 Thread Axel Beckert
Hi Sean,

Sean Whitton wrote:
> +
> +override_dh_auto_install:
> +

Hmmm, I think that could be avoided.

> +override_dh_installman:
> + cp unclutter.man debian/tmp/unclutter-classic.man
> + dh_installman debian/tmp/unclutter-classic.man

Hmmm, this looks rather ugly to me. If we already use dh-exec, we
should use it for that, too, IMHO.

> diff -Nru unclutter-8/debian/unclutter.install 
> unclutter-8/debian/unclutter.install
> --- unclutter-8/debian/unclutter.install  2017-12-30 11:53:06.0 
> -0700
> +++ unclutter-8/debian/unclutter.install  2019-08-31 12:32:55.0 
> -0700
> @@ -1,2 +1,4 @@
> -debian/local/90unclutter /etc/X11/Xsession.d
> -unclutter/usr/bin
> +#!/usr/bin/dh-exec
> +
> +debian/local/90unclutter => /etc/X11/Xsession.d/90unclutter
> +unclutter=> /usr/bin/unclutter-classic

I think we'll have some issues if we don't include
/etc/X11/Xsession.d/90unclutter in the alternatives, too:

* Only either unclutter or unclutter-xfixes can ship this file.

* It will operate on whatever is chosen with update-alternatives, but
  only if the package which contains it, is installed, too.

* Installing this file with different names from both packages is no
  option as it would start both programs (and I don't think that's a
  good idea) if both are installed.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



Bug#939070: removing gnome desktop in tasksel has little or no effect

2019-08-31 Thread Joey Hess
Package: tasksel
Version: 3.54
Severity: normal

I accidentially installed debian 10.0 with gnome rather than xfce, so
after the installation, I re-ran tasksel, unselected gnome, and selected
xfce.

I then rebooted, and it still booted up to gdm3 and on login it
defaulted to gnome shell.

Tasksel probably removed task-gnome-desktop, but many of its
dependencies appeared to still be installed.

(I've since reinstalled the machine with xfce and so can't provide any
more details about its state.)

-- 
see shy jo


signature.asc
Description: PGP signature


Bug#928213: libcaca 0.99.beta19-2.1~deb9u1 flagged for acceptance

2019-08-31 Thread Adam D Barratt
package release.debian.org
tags 928213 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: libcaca
Version: 0.99.beta19-2.1~deb9u1

Explanation: fix integer overflow issues [CVE-2018-20545 CVE-2018-20546 
CVE-2018-20547 CVE-2018-20548 CVE-2018-20549]



Bug#938997: gettext 0.19.8.1-2+deb9u1 flagged for acceptance

2019-08-31 Thread Adam D Barratt
package release.debian.org
tags 938997 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: gettext
Version: 0.19.8.1-2+deb9u1

Explanation: stop xgettext() from crashing when run with --its=FILE option



Bug#825809: unclutter: diff for NMU version 8-21.1

2019-08-31 Thread Axel Beckert
Hi Sean,

Sean Whitton wrote:
> I've prepared an NMU for unclutter (versioned as 8-21.1) and uploaded it
> to DELAYED/15. Please feel free to tell me if I should delay it longer.

Huh? I don't think an NMU is necessary nor appropriate here since I
don't think that I am MIA.

I'd rather prefer if you'd update
https://salsa.debian.org/debian/unclutter instead, either in a feature
branch or directly into the master branch (fine for me).

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



Bug#935308: android-sdk-meta 25.0.0+11~deb10u2 flagged for acceptance

2019-08-31 Thread Adam D Barratt
package release.debian.org
tags 935308 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: android-sdk-meta
Version: 25.0.0+11~deb10u2

Explanation: fix regex for adding Debian version to binary packages



Bug#938954: nextcloud-desktop 2.5.1-3+deb10u1 flagged for acceptance

2019-08-31 Thread Adam D Barratt
package release.debian.org
tags 938954 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: nextcloud-desktop
Version: 2.5.1-3+deb10u1

Explanation: add missing dependency on nextcloud-desktop-common to 
nextcloud-desktop-cmd



Bug#938975: debian-edu-doc 2.10.19~deb10u1 flagged for acceptance

2019-08-31 Thread Adam D Barratt
package release.debian.org
tags 938975 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: debian-edu-doc
Version: 2.10.19~deb10u1

Explanation: update Debian Edu Buster and ITIL manuals and translations



Bug#825809: ITP: unclutter-xfixes -- hide the X mouse cursor after a period of inactivity, using XFixes

2019-08-31 Thread Axel Beckert
Hi Sean,

Sean Whitton wrote:
> After thinking about this a bit and reviewing old discussions, I think
> that using the alternatives mechanism is better than doing some sort of
> transition.

Indeed.

> I have prepared a patch to src:unclutter to implement that,
> and also I've prepared packaging of unclutter-xfixes which calls
> update-alternatives(1).

Yay, thanks! Will happily include that patch in unclutter.

> Although unclutter-xfixes will work better for a lot of people,
> classic unclutter is working perfectly fine for other people, and there
> seems no need to impose a transition on the second group if it's not
> needed to benefit the first.

I fully agree. Actually being happy with the old unclutter and never
having felt the urge to change its behaviour made me hesitate to
switch to unclutter-xfixes.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



Bug#935485: Looking for help to adopt recently removed package, kcollectd

2019-08-31 Thread Antonio Russo
Hello everyone,

I've been following a bit of a breadcrumb trail, and I hope I'm in the right
place now. kcollectd, a tool for viewing log information, has recently been
removed from unstable because it lacked a Qt 5 port [1]. I have ported that
package and I've taken over the upstream (which has been dead for years) [2].
I'm offering to maintain the Debian package, but I have received very little
response to my ITA RFS bug [3]. Should I refile this as an ITP bug, since the
package has, in fact, already been removed?

I spoke with Scott Kitterman, who requested the removal, and he said
knows of no other reason the package should be removed. The updated
packaging fixes several outstanding bugs, and makes the Debian lintian
report much cleaner (one is, I believe, a false positive, and the other
is due to lack of package tests which aren't really relevant to this kind of
UI software).

Is anyone here willing to sponsor this package, offer any criticism of
the package, or direct me to a place where I might get such help?

Thank you,
Antonio Russo

[1] https://bugs.debian.org/935223
[2] https://gitlab.com/aerusso/kcollectd
[3] https://bugs.debian.org/935485



Bug#825809: unclutter: diff for NMU version 8-21.1

2019-08-31 Thread Sean Whitton
Control: tags 913639 + patch
Control: tags 913639 + pending
Control: retitle -1 use alternatives system to permit other unclutter 
implementations

Dear maintainer,

I've prepared an NMU for unclutter (versioned as 8-21.1) and uploaded it
to DELAYED/15. Please feel free to tell me if I should delay it longer.

The content of this NMU is what I believe to be the least disruptive way
to get unclutter-xfixes into Debian for those that want it.  In #825809,
the maintainers of src:unclutter have expressed their general support
for making unclutter-xfixes available.

If the maintainers of src:unclutter later want to do drop classic
unclutter and transition all users over to unclutter-xfixes, this NMU
will not make doing that any harder.

Regards.

-- 
Sean Whitton
diff -Nru unclutter-8/debian/changelog unclutter-8/debian/changelog
--- unclutter-8/debian/changelog	2018-01-01 23:41:13.0 -0700
+++ unclutter-8/debian/changelog	2019-08-31 12:32:55.0 -0700
@@ -1,3 +1,15 @@
+unclutter (8-21.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename /usr/bin/unclutter to /usr/bin/unclutter-classic.
+- Add dh-exec build-dep.
+  * Also install unclutter.man as unclutter-classic.man.
+  * Call update-alternatives in prerm and postinst to register
+/usr/bin/unclutter-classic as an alternative for /usr/bin/unclutter,
+with the manpage as a slave link (Closes: #913639).
+
+ -- Sean Whitton   Sat, 31 Aug 2019 12:32:55 -0700
+
 unclutter (8-21) unstable; urgency=medium
 
   * Update Vcs-* headers for the switch to salsa.debian.org.
diff -Nru unclutter-8/debian/control unclutter-8/debian/control
--- unclutter-8/debian/control	2018-01-01 23:11:27.0 -0700
+++ unclutter-8/debian/control	2019-08-31 12:32:55.0 -0700
@@ -4,6 +4,7 @@
 Maintainer: Axel Beckert 
 Uploaders: Ian Jackson 
 Build-Depends: debhelper (>= 11~),
+   dh-exec,
libx11-dev
 Standards-Version: 4.1.3
 Vcs-Browser: https://salsa.debian.org/debian/unclutter
diff -Nru unclutter-8/debian/rules unclutter-8/debian/rules
--- unclutter-8/debian/rules	2018-01-01 21:36:40.0 -0700
+++ unclutter-8/debian/rules	2019-08-31 12:32:55.0 -0700
@@ -7,3 +7,9 @@
 
 override_dh_installchangelogs:
 	dh_installchangelogs patchlevel.h
+
+override_dh_auto_install:
+
+override_dh_installman:
+	cp unclutter.man debian/tmp/unclutter-classic.man
+	dh_installman debian/tmp/unclutter-classic.man
diff -Nru unclutter-8/debian/unclutter.install unclutter-8/debian/unclutter.install
--- unclutter-8/debian/unclutter.install	2017-12-30 11:53:06.0 -0700
+++ unclutter-8/debian/unclutter.install	2019-08-31 12:32:55.0 -0700
@@ -1,2 +1,4 @@
-debian/local/90unclutter	/etc/X11/Xsession.d
-unclutter			/usr/bin
+#!/usr/bin/dh-exec
+
+debian/local/90unclutter	=> /etc/X11/Xsession.d/90unclutter
+unclutter			=> /usr/bin/unclutter-classic
diff -Nru unclutter-8/debian/unclutter.manpages unclutter-8/debian/unclutter.manpages
--- unclutter-8/debian/unclutter.manpages	2017-12-30 11:53:06.0 -0700
+++ unclutter-8/debian/unclutter.manpages	1969-12-31 17:00:00.0 -0700
@@ -1 +0,0 @@
-unclutter.man
diff -Nru unclutter-8/debian/unclutter.postinst unclutter-8/debian/unclutter.postinst
--- unclutter-8/debian/unclutter.postinst	2017-12-30 11:53:06.0 -0700
+++ unclutter-8/debian/unclutter.postinst	2019-08-31 12:32:55.0 -0700
@@ -4,6 +4,13 @@
 
 . /usr/share/debconf/confmodule
 
+unclutter_update_alternatives () {
+	update-alternatives --install /usr/bin/unclutter \
+		unclutter /usr/bin/unclutter-classic 10 \
+		--slave /usr/share/man/man1/unclutter.1.gz \
+		unclutter.1.gz /usr/share/man/man1/unclutter-classic.1.gz
+}
+
 case "${1}" in
 	configure)
 		db_get unclutter/autostart
@@ -30,10 +37,12 @@
 
 			sed -i -e "s|^ *START_UNCLUTTER=.*$|START_UNCLUTTER=${START_UNCLUTTER}|" /etc/default/unclutter
 		fi
+
+		unclutter_update_alternatives
 		;;
 
 	abort-upgrade|abort-remove|abort-deconfigure)
-
+		unclutter_update_alternatives
 		;;
 
 	*)
diff -Nru unclutter-8/debian/unclutter.prerm unclutter-8/debian/unclutter.prerm
--- unclutter-8/debian/unclutter.prerm	1969-12-31 17:00:00.0 -0700
+++ unclutter-8/debian/unclutter.prerm	2019-08-31 12:32:55.0 -0700
@@ -0,0 +1,22 @@
+#!/bin/sh
+
+set -e
+
+case "${1}" in
+	remove)
+		update-alternatives --remove unclutter /usr/bin/unclutter-classic
+		;;
+
+	purge|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
+
+		;;
+
+	*)
+		echo "postrm called with unknown argument \`${1}'" >&2
+		exit 1
+		;;
+esac
+
+#DEBHELPER#
+
+exit 0


signature.asc
Description: PGP signature


Bug#939069: matrix-synapse: 'HomeServerConfig' object has no attribute 'signing_key_path'

2019-08-31 Thread sergio
Package: matrix-synapse
Version: 1.3.0-1~bpo10+1
Severity: normal

Dear Maintainer,

# /etc/init.d/matrix-synapse start
chown: missing operand after ‘matrix-synapse:nogroup’
Try 'chown --help' for more information.
chmod: missing operand after ‘0600’
Try 'chmod --help' for more information.


synapse% python3 -m synapse.config read signing_key_path --config-path 
/etc/matrix-synapse/homeserver.yaml --config-path /etc/matrix-synapse/conf.d/
Traceback (most recent call last):
  File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File "/usr/lib/python3/dist-packages/synapse/config/__main__.py", line 31, in 

print(getattr(config, key))
AttributeError: 'HomeServerConfig' object has no attribute 'signing_key_path'


synapse% grep signing_key_path /etc/matrix-synapse/homeserver.yaml
signing_key_path: "/etc/matrix-synapse/homeserver.signing.key"
synapse% ls /etc/matrix-synapse/homeserver.signing.key
/etc/matrix-synapse/homeserver.signing.key


Bug#825809: ITP: unclutter-xfixes -- hide the X mouse cursor after a period of inactivity, using XFixes

2019-08-31 Thread Sean Whitton
control: retitle -1 ITP: unclutter-xfixes -- hide the X mouse cursor after a 
period of inactivity, using XFixes
control: owner -1 !

Hello,

On Mon 30 May 2016 at 06:52PM +10, Scott Leggett wrote:

> * Package name: unclutter-xfixes
>   Version : 1.1
>   Upstream Author : Ingo Bürk 
> * URL : https://github.com/Airblader/unclutter-xfixes
> * License : Expat
>   Programming Lang: C
>   Description : unclutter-xfixes hides the mouse pointer after a period 
> of inactivity, to prevent it getting in the way. The pointer is shown again 
> on mouse movement.
>
> This version of unclutter is a rewrite of the original and uses the
> x11-xfixes extension, which means that no fake windows or pointer
> grabbing is needed. This may work better with window managers and
> applications.

After thinking about this a bit and reviewing old discussions, I think
that using the alternatives mechanism is better than doing some sort of
transition.  I have prepared a patch to src:unclutter to implement that,
and also I've prepared packaging of unclutter-xfixes which calls
update-alternatives(1).

Although unclutter-xfixes will work better for a lot of people,
classic unclutter is working perfectly fine for other people, and there
seems no need to impose a transition on the second group if it's not
needed to benefit the first.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#935827: buster-pu: package cryptsetup/2:2.1.0-5+deb10u2

2019-08-31 Thread Guilhem Moulin
Thanks, uploaded!  Hope this makes it to 10.1 :-)

And again, many thanks for your work on Buster!
-- 
Guilhem.


signature.asc
Description: PGP signature


Bug#939068: RFS: zapping/0.10~cvs6-17

2019-08-31 Thread Yavor Doganov
Package: sponsorship-requests
Severity: normal

Dear mentors,

I'm looking for a sponsor for a QA upload of the package "zapping".

 * Package name: zapping
   Version : 0.10~cvs6-17
   Upstream Author : Iñaki García Etxebarria 
 Michael H. Schimek 
 * URL : http://zapping.sourceforge.net/
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/zapping
   Section : gnome

It builds this binary package:

zapping - television viewer for the GNOME environment

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/z/zapping/zapping_0.10~cvs6-17.dsc

Changes since the last upload:

   * QA upload.
   * debian/patches/24-GConf-to-GSettings.patch: Remove GConf migration
 code; no longer needed after the buster release.
   * debian/patches/28-Python3.patch: New; port to Python 3 as version 2 is
 about to be removed during the bullseye cycle (Closes: #938878).
   * debian/patches/series: Update.
   * debian/compat: Bump to 12.
   * debian/control (Build-Depends): Require debhelper >= 12.  Replace
 python-dev with python3-dev.
 (Recommends): Remove gconf2.
 (Standards-Version): Claim compliance with 4.4.0; no changes needed.
   * debian/rules (override_dh_strip): Remove; dbgsym migration done.



Bug#939066: libodsstream-qt5-dev: depends on dropped libquazip-dev

2019-08-31 Thread Jonathan Wiltshire
Package: libodsstream-qt5-dev
Version: 0.7.0-2
Severity: serious
Tags: bullseye sid
Justification: will become uninstallable

Hi,

libodsstream-qt5-dev depends on the dropped package libquazip-dev, which
will be removed soon as part of the libquazip transition. Binary
packages cannot be cleaned up in testing until libodsstream's
dependencies are updated, presumably to libquazip5-dev.

Thanks,

-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 
'oldstable-updates'), (500, 'unstable'), (500, 'oldstable')
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_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libodsstream-qt5-dev depends on:
pn  libodsstream-qt5-0  
pn  libquazip-dev   

libodsstream-qt5-dev recommends no packages.

libodsstream-qt5-dev suggests no packages.



Bug#939065: BD on python-rdkit which isn't build anymore and isn't in bullseye

2019-08-31 Thread Paul Gevers
Source: cinfony
Version: 1.2-3
Severity: serious
Tags: ftbfs sid bullseye
Control: found -1 1.2-4

Recently the rdkit package has stopped building the python-rdkit
package. This is an issue for your package as it build-depends on it.

Unfortunately the migration software doesn't detected this kind of
situation yet, so your package also FTBFS in bullseye since 2019-08-15.
The package is still available in unstable as cruft.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#939064: cinfony: autopkgtest regression: SSL: CERTIFICATE_VERIFY_FAILED

2019-08-31 Thread Paul Gevers
Source: cinfony
Version: 1.2-4
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of cinfony the autopkgtest of cinfony fails in
testing when that autopkgtest is run with the binary packages of cinfony
from unstable. It passes when run with only packages from testing. In
tabular form:
   passfail
cinfonyfrom testing1.2-4
all others from testingfrom testing

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

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/c/cinfony/2857991/log.gz

==
ERROR: testDraw (__main__.TestWebel)
Create a 2D depiction
--
Traceback (most recent call last):
  File "testall.py", line 520, in testDraw
filename="%s.png" % self.toolkit.__name__)
  File "/usr/lib/python2.7/dist-packages/cinfony/webel.py", line 305, in
draw
imagedata = nci(_quo(self.smiles), "image")
  File "/usr/lib/python2.7/dist-packages/cinfony/webel.py", line 74, in
server
resp = urllib2.urlopen(url)
  File "/usr/lib/python2.7/urllib2.py", line 154, in urlopen
return opener.open(url, data, timeout)
  File "/usr/lib/python2.7/urllib2.py", line 435, in open
response = meth(req, response)
  File "/usr/lib/python2.7/urllib2.py", line 548, in http_response
'http', request, response, code, msg, hdrs)
  File "/usr/lib/python2.7/urllib2.py", line 467, in error
result = self._call_chain(*args)
  File "/usr/lib/python2.7/urllib2.py", line 407, in _call_chain
result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 654, in http_error_302
return self.parent.open(new, timeout=req.timeout)
  File "/usr/lib/python2.7/urllib2.py", line 429, in open
response = self._open(req, data)
  File "/usr/lib/python2.7/urllib2.py", line 447, in _open
'_open', req)
  File "/usr/lib/python2.7/urllib2.py", line 407, in _call_chain
result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 1241, in https_open
context=self._context)
  File "/usr/lib/python2.7/urllib2.py", line 1198, in do_open
raise URLError(err)
URLError: 

==
ERROR: testRFoutputfile (__main__.TestWebel)
Test the Outputfile class
--
Traceback (most recent call last):
  File "testall.py", line 536, in testRFoutputfile
outputfile.write(mol)
  File "/usr/lib/python2.7/dist-packages/cinfony/webel.py", line 158, in
write
output = molecule.write(self.format)
  File "/usr/lib/python2.7/dist-packages/cinfony/webel.py", line 281, in
write
output = nci(_quo(self.smiles), "file?format=%s" % format).rstrip()
  File "/usr/lib/python2.7/dist-packages/cinfony/webel.py", line 74, in
server
resp = urllib2.urlopen(url)
  File "/usr/lib/python2.7/urllib2.py", line 154, in urlopen
return opener.open(url, data, timeout)
  File "/usr/lib/python2.7/urllib2.py", line 435, in open
response = meth(req, response)
  File "/usr/lib/python2.7/urllib2.py", line 548, in http_response
'http', request, response, code, msg, hdrs)
  File "/usr/lib/python2.7/urllib2.py", line 467, in error
result = self._call_chain(*args)
  File "/usr/lib/python2.7/urllib2.py", line 407, in _call_chain
result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 654, in http_error_302
return self.parent.open(new, timeout=req.timeout)
  File "/usr/lib/python2.7/urllib2.py", line 429, in open
response = self._open(req, data)
  File "/usr/lib/python2.7/urllib2.py", line 447, in _open
'_open', req)
  File "/usr/lib/python2.7/urllib2.py", line 407, in _call_chain
result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 1241, in https_open
context=self._context)
  File "/usr/lib/python2.7/urllib2.py", line 1198, in do_open
raise URLError(err)
URLError: 

==
ERROR: testRFsingletofile (__main__.TestWebel)
Test the molecule.write() method
--
Traceback (most recent call last):
  File "testall.py", line 264, in testRFsingletofile
mol.write("smi", "testoutput.txt")
  File "/usr/lib/python2.7/dist-packages/cinfony/webel.py", line 285, in
write
raise IOError("%s already exists. Use 'overwrite=True' to overwrite
it." % filename)
IOError: testoutput.txt already 

Bug#939063: stretch-pu: package koji/1.10.0-1+deb9u1

2019-08-31 Thread Holger Levsen
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi,

in coordination with the security team I'd like to update koji in stretch to
fix two CVEs:

koji (1.10.0-1+deb9u1) stretch; urgency=medium

  * Team upload.
  * Add patch based on upstream commit bdec8c7399 to fix CVE-2018-1002161, an
SQL injection issue in multiple remote calls. Closes: #922922.
  * Add patch based on upstream commit ba7b5a3cbe to fix CVE-2017-1002153, to
properly validate SCM pathes. Closes: #877921.

 -- Holger Levsen   Sat, 31 Aug 2019 20:31:37 +0200

The debdiff is attached and looks like this:

$ debdiff koji_1.10.0-1.dsc koji_1.10.0-1+deb9u1.dsc|diffstat
 changelog   |   10 +
 patches/0004-CVE-2017-1002153.patch |   61 ++
 patches/0005-CVE-2018-1002161.patch |   64 
 patches/series  |2 +
 4 files changed, 137 insertions(+)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
diff -Nru koji-1.10.0/debian/changelog koji-1.10.0/debian/changelog
--- koji-1.10.0/debian/changelog	2015-12-04 11:20:58.0 +0100
+++ koji-1.10.0/debian/changelog	2019-08-31 20:31:37.0 +0200
@@ -1,3 +1,13 @@
+koji (1.10.0-1+deb9u1) stretch; urgency=medium
+
+  * Team upload.
+  * Add patch based on upstream commit bdec8c7399 to fix CVE-2018-1002161, an
+SQL injection issue in multiple remote calls. Closes: #922922.
+  * Add patch based on upstream commit ba7b5a3cbe to fix CVE-2017-1002153, to
+properly validate SCM pathes. Closes: #877921.
+
+ -- Holger Levsen   Sat, 31 Aug 2019 20:31:37 +0200
+
 koji (1.10.0-1) unstable; urgency=medium
 
   [ Marek Marczykowski-Górecki ]
diff -Nru koji-1.10.0/debian/patches/0004-CVE-2017-1002153.patch koji-1.10.0/debian/patches/0004-CVE-2017-1002153.patch
--- koji-1.10.0/debian/patches/0004-CVE-2017-1002153.patch	1970-01-01 01:00:00.0 +0100
+++ koji-1.10.0/debian/patches/0004-CVE-2017-1002153.patch	2019-08-31 19:59:44.0 +0200
@@ -0,0 +1,61 @@
+From ba7b5a3cbed11ade11c3af5e834c9a6de4f6d7c3 Mon Sep 17 00:00:00 2001
+From: Mike McLean 
+Date: Sep 19 2017 21:23:50 +
+Subject: PR#591: Normalize paths for scms
+
+
+Merges #591
+https://pagure.io/koji/pull-request/591
+
+Fixes #563
+https://pagure.io/koji/issue/563
+
+Fixes CVE-2017-1002153
+
+---
+
+Index: koji/koji/daemon.py
+===
+--- koji.orig/koji/daemon.py
 koji/koji/daemon.py
+@@ -257,22 +257,31 @@ class SCM(object):
+ netloc = userhost[1]
+ elif len(userhost) > 2:
+ raise koji.GenericError, 'Invalid username@hostname specified: %s' % netloc
++if not netloc:
++raise koji.GenericError, 'Unable to parse SCM URL: %s . Could not find the netloc element.' % self.url
+ 
+-# ensure that path and query do not end in /
+-if path.endswith('/'):
+-path = path[:-1]
+-if query.endswith('/'):
+-query = query[:-1]
++# check for empty path before we apply normpath
++if not path:
++raise koji.GenericError, 'Unable to parse SCM URL: %s . Could not find the path element.' % self.url
++
++path = os.path.normpath(path)
++
++# path and query should not end with /
++path = path.rstrip('/')
++query = query.rstrip('/')
++# normpath might not strip // at start of path
++if path.startswith('//'):
++path = '/' + path.strip('/')
++# path should start with /
++if not path.startswith('/'):  # pragma: no cover
++# any such url should have already been caught by is_scm_url
++raise koji.GenericError, 'Invalid SCM URL. Path should begin with /: %s) '
+ 
+ # check for validity: params should be empty, query may be empty, everything else should be populated
+ if params :
+ raise koji.GenericError, 'Unable to parse SCM URL: %s . Params element %s should be empty.' % (self.url, params)
+ if not scheme :
+ raise koji.GenericError, 'Unable to parse SCM URL: %s . Could not find the scheme element.' % self.url
+-if not netloc :
+-raise koji.GenericError, 'Unable to parse SCM URL: %s . Could not find the netloc element.' % self.url
+-if not path :
+-raise koji.GenericError, 'Unable to parse SCM URL: %s . Could not find the path element.' % self.url
+ if not fragment :
+ raise koji.GenericError, 'Unable to parse SCM URL: %s . Could not find the fragment element.' % self.url
+ 
diff -Nru koji-1.10.0/debian/patches/0005-CVE-2018-1002161.patch koji-1.10.0/debian/patches/0005-CVE-2018-1002161.patch

Bug#926731: ITS: urlscan/0.9.2 - extract and browse email URLs

2019-08-31 Thread Marcin Kulisz
Package: urlscan
Version: 0.8.2-1
Followup-For: Bug #926731

Boruch are you still interested in maintaining this package?
If not I my intent is to salvage/adopt it in the next couple of weeks, so please
let me know asap if you're planning to do it.



Bug#875051: [netanim] Future Qt4 removal from Buster

2019-08-31 Thread Moritz Mühlenhoff
On Sat, Sep 09, 2017 at 10:12:23PM +0200, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Source: netanim
> Version: 3.100-1
> Severity: wishlist
> User: debian-qt-...@lists.debian.org
> Usertags: qt4-removal
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:

Hi YinQiang,
3.108 supports Qt5, are you planning to upload that version? Otherwise I'll
file a removal bug.

Cheers,
Moritz



Bug#935031: konsoles started with KDE are black first

2019-08-31 Thread Marc Haber
On Sat, Aug 31, 2019 at 02:47:36AM +0200, Jiri Palecek wrote:
> On Fri, 23 Aug 2019 12:51:59 +0200 Martin Steigerwald wrote:
> 
> > > Since today's update, those konsoles are black. Window titla and Menu
> > > bar are there but no contents. When I open a new tab using
> > > Ctrl-Shift-T, the konsole becomes usable.
> 
> I have created patches fixing this problem. Please have a look at
> https://salsa.debian.org/qt-kde-team/kde/konsole/merge_requests/2

I don't see the issue even without the patches any more.

Greetings
Marc

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



Bug#917972: transition: openexr

2019-08-31 Thread Jonathan Wiltshire
On Tue, Aug 27, 2019 at 02:52:39PM +0200, Matteo F. Vescovi wrote:
> 
> So, all FTBFS are not related to Ilmbase/OpenEXR.
> Let me know if it's ok to go on with this transition.

Ok, looking good. I'd like to hold off for now and get a few of the
transitions in progress out of the way first though.



-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51



Bug#939062: r-cran-tibble: autopkgtest regression: missing versioned test dependency on r-cran-pillar?

2019-08-31 Thread Paul Gevers
Source: r-cran-tibble
Version: 2.1.3-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression
Control: affects -1 src:r-cran-pillar

Dear maintainers,

With a 1.5 month old upload of r-cran-tibble the autopkgtest of
r-cran-tibble fails in testing when that autopkgtest is run with the
binary packages of r-cran-tibble from unstable. It passes when run with
only packages from testing. In tabular form:
   passfail
r-cran-tibble  from testing2.1.3-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. Interestingly
the package passes in unstable, so it seems the problem is just that
some (test) dependency isn't migrating. Checking for other packages that
fail to test with r-cran-tibble, I spotted r-cran-pillar. The failure
there is "opposite", so I think r-cran-tibble wants the latest version
of r-cran-pillar for it's autopkgtest. This could be only a problem for
the autopkgtest, but it could point at an issue for the package as well.

Currently this regression is blocking the migration to testing [1] of
both r-cran-tibble and r-cran-pillar.

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

Paul

[1] https://qa.debian.org/excuses.php?package=r-cran-tibble

https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-tibble/2854311/log.gz

autopkgtest [14:11:04]: test run-unit-test: [---

R version 3.6.1 (2019-07-05) -- "Action of the Toes"
Copyright (C) 2019 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> library("testthat")
>
> test_check("tibble")
Loading required package: tibble
── 1. Failure: trunc_mat for POSIXlt columns (#86)
(@test-trunc-mat.R#141)  
Results have changed from known value recorded in
'output/trunc_mat/POSIXlt-8-60.txt'.
1/12 mismatches
x[3]: "  "
y[3]: " "

══ testthat results
═══
[ OK: 741 | SKIPPED: 1 | WARNINGS: 0 | FAILED: 1 ]
1. Failure: trunc_mat for POSIXlt columns (#86) (@test-trunc-mat.R#141)

Error: testthat unit tests failed
Execution halted
autopkgtest [14:11:11]: test run-unit-test: ---]



signature.asc
Description: OpenPGP digital signature


Bug#939061: RM: laborejo -- RoQA; depends onm qt4, orphaned

2019-08-31 Thread Moritz Muehlenhoff
Package: ftp.debian.org
Severity: normal

Please remove laborejo, the version currently in the archive
depends on qt4. There's qt5 support in upstream development
releases, but the package is orphaned since three years.

Cheers,
Moritz



Bug#933967: More information, testing using .link files to rename iface

2019-08-31 Thread Michael Biebl
On Tue, 6 Aug 2019 09:42:15 -0400 Kathryn Tolsen
 wrote:
> > Which version is this?
> 
> > Is the problem still reproducible?
> 
> root@t440:/home/user# dpkg -l systemd udev linux-image-amd64;cat
> /etc/systemd/network/70-wifi.link;dmesg|tail -n 31
> 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  Architecture Description
> +++-=---===
> ii  linux-image-amd64 4.19+105 amd64Linux for 64-bit PCs
> (meta-package)
> ii  systemd   241-5amd64system and service manager
> ii  udev  241-5amd64/dev/ and hotplug
> management daemon
> [Match]
> MACAddress=c4:3d:c7:74:f9:9b
> 
> [Link]
> Name=wifi0
> [   59.833725] usb 1-1: new high-speed USB device number 5 using xhci_hcd
> [   59.990838] usb 1-1: New USB device found, idVendor=0846,
> idProduct=4260, bcdDevice= 2.00
> [   59.990844] usb 1-1: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [   59.990847] usb 1-1: Product: NETGEAR WG111v3
> [   59.990850] usb 1-1: Manufacturer: Manufacturer_NETGEAR
> [   59.990852] usb 1-1: SerialNumber: C43DC774F99B
> [   60.768528] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
> [   60.769098] ieee80211 phy1: hwaddr c4:3d:c7:74:f9:9b, RTL8187BvE V0 +
> rtl8225z2, rfkill mask 2
> [   60.786783] rtl8187: Customer ID is 0x00
> [   60.787395] rtl8187: wireless switch is on
> [   60.787442] usbcore: registered new interface driver rtl8187
> [   60.804006] rtl8187 1-1:1.0 wlxc43dc774f99b: renamed from wlan0
> [   60.850461] IPv6: ADDRCONF(NETDEV_UP): wlxc43dc774f99b: link is not ready
> [   63.193129] IPv6: ADDRCONF(NETDEV_UP): wlxc43dc774f99b: link is not ready
> [   66.147517] IPv6: ADDRCONF(NETDEV_UP): wlxc43dc774f99b: link is not ready
> [   66.224888] IPv6: ADDRCONF(NETDEV_UP): wlxc43dc774f99b: link is not ready
> [  162.299965] IPv6: ADDRCONF(NETDEV_UP): wlxc43dc774f99b: link is not ready
> [  164.571920] wlxc43dc774f99b: authenticate with 8c:3b:ad:cb:08:6e
> [  164.909574] wlxc43dc774f99b: send auth to 8c:3b:ad:cb:08:6e (try 1/3)
> [  164.911514] wlxc43dc774f99b: authenticated
> [  169.910445] wlxc43dc774f99b: aborting authentication with
> 8c:3b:ad:cb:08:6e by local choice (Reason: 3=DEAUTH_LEAVING)
> [  172.471431] wlxc43dc774f99b: authenticate with 8c:3b:ad:cb:08:6e
> [  172.797357] wlxc43dc774f99b: send auth to 8c:3b:ad:cb:08:6e (try 1/3)
> [  172.799288] wlxc43dc774f99b: authenticated
> [  177.801182] wlxc43dc774f99b: aborting authentication with
> 8c:3b:ad:cb:08:6e by local choice (Reason: 3=DEAUTH_LEAVING)
> [  180.740423] wlxc43dc774f99b: authenticate with 8c:3b:ad:cb:08:6e
> [  181.081228] wlxc43dc774f99b: send auth to 8c:3b:ad:cb:08:6e (try 1/3)
> [  181.085033] wlxc43dc774f99b: authenticated
> [  186.082430] wlxc43dc774f99b: aborting authentication with
> 8c:3b:ad:cb:08:6e by local choice (Reason: 3=DEAUTH_LEAVING)
> [  187.168136] IPv6: ADDRCONF(NETDEV_UP): wlxc43dc774f99b: link is not ready
> [  190.079680] IPv6: ADDRCONF(NETDEV_UP): wlxc43dc774f99b: link is not ready
> 

Hm, you probably need to blacklist
/lib/udev/rules.d/73-usb-net-by-mac.rules. You can do that by creating a
file /etc/udev/rules.d/73-usb-net-by-mac.rules pointing at /dev/null

After that (and running update-initramfs -u), 70-wifi.link should become
active and you should be able to test, if incrementally increasing the
length of the iface name at some point triggers the problem.
-- 
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#939060: RM: pyrite-publisher -- RoQA; Depends on Python 2, dead upstream

2019-08-31 Thread Moritz Muehlenhoff
Package: ftp.debian.org
Severity: normal

Please remove pyrite-publisher. It depends on Python 2, is dead upstream
(last release from 2002) and is orphaned since 2012.

Cheers,
Moritz



Bug#939059: RM: pyew -- RoQA; depends on Python 2, mostly dead upstream, unmaintained

2019-08-31 Thread Moritz Muehlenhoff
Package: ftp.debian.org
Severity: normal

Please remove pyew, it's mostly stale/dead upstream, depends on Python 2 and
is orphaned for over three years now.

Cheers,
Moritz



Bug#939058: subnetcalc: bogus autopkgtest definition file blocking migration to testing

2019-08-31 Thread Paul Gevers
Source: subnetcalc
Version: 2.4.13-1
Severity: normal

Hi,

I noticed your package isn't migrating to testing because it's waiting
for the results of the new autopkgtest (great) you introduced. However,
the autopkgtest definition file debian/tests/control isn't using proper
syntax. Due to the autopkgtest bug #918882, this is marked as tmpfail
and is retried over and over again.

Please fix your autopkgtest.

Paul

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

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



signature.asc
Description: OpenPGP digital signature


Bug#935146: appstream: unable to open cache

2019-08-31 Thread Matthias Klumpp
Am Sa., 31. Aug. 2019 um 19:36 Uhr schrieb Matthias Klumpp
:
>
> Am Di., 20. Aug. 2019 um 10:51 Uhr schrieb Martin-Éric Racine
> :
> >
> > Geode has no PAE. Maximum memory on these as per memory controller is
> > 1GB which is what it has. Part of this is used by the GPU.
> >
> > $ free
> >   totalusedfree  shared  buff/cache   
> > available
> > Mem: 896608   56956  6774602968  162192  
> > 706860
> > Swap:   1646624   0 1646624
>
> So far I haven't been able to reproduce this in VMs, but a VM is
> probably also not the best place to try to reproduce this issue.
> Do you have some time to test a patch for me?
> If you can, fetch
> https://github.com/ximion/appstream/commit/a049482267f3caf53c5465fe6feb8d7c6a12206b.patch

Actually, that's the wrong patch...
You'd want this one instead:
https://github.com/ximion/appstream/commit/84e11c35f9ceb1b92df83e4b9707498f5267dcd3.patch

-- 
I welcome VSRE emails. See http://vsre.info/



Bug#922978: Raising severity

2019-08-31 Thread Lisandro Damián Nicanor Pérez Meyer
severity 922978 serious
thanks

Hi! phonon support for Qt 4 has been dropped, this is now RC.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/



Bug#935146: appstream: unable to open cache

2019-08-31 Thread Matthias Klumpp
Am Di., 20. Aug. 2019 um 10:51 Uhr schrieb Martin-Éric Racine
:
>
> Geode has no PAE. Maximum memory on these as per memory controller is
> 1GB which is what it has. Part of this is used by the GPU.
>
> $ free
>   totalusedfree  shared  buff/cache   
> available
> Mem: 896608   56956  6774602968  162192  
> 706860
> Swap:   1646624   0 1646624

So far I haven't been able to reproduce this in VMs, but a VM is
probably also not the best place to try to reproduce this issue.
Do you have some time to test a patch for me?
If you can, fetch
https://github.com/ximion/appstream/commit/a049482267f3caf53c5465fe6feb8d7c6a12206b.patch
and apply it to the "appstream" package sources (add to debian/patches
folder and register it in debian/series), then rebuild the package and
install the patches copy of the libappstream4 library and appstream
package.
Does that solve your problem?
If so, I would just roll out that patch with the next update.

Cheers,
 Matthias

-- 
I welcome VSRE emails. See http://vsre.info/



Bug#922978: Bug #922978 in auralquiz marked as pending

2019-08-31 Thread Lisandro Damián Nicanor Pérez Meyer
On Fri, 05 Apr 2019 10:33:46 + Markus Koschany  
wrote:
> Control: tag -1 pending
> 
> Hello,
> 
> Bug #922978 in auralquiz reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
> 
> https://salsa.debian.org/games-team/auralquiz/commit/345116dbe0d71994e2b5d8f45149b9caf73869fa

Hi! Gently ping on this one, it's already RC. If you want I can NMU it.

Cheers, Lisandro.
 



Bug#936064: gimp: Gimp crash using filling tool

2019-08-31 Thread Stephane

Hello Bernhard,

On Sat, 31 Aug 2019 15:29:17 +0200 =?UTF-8?Q?Bernhard_=c3=9cbelacker?= 
 wrote:

Dear Maintainer,
this backtrace is identical to that one reported in #935604.
Also the expected message appears in this report:
...
"[xcb] Unknown sequence number while processing queue"


This time I found also this upstream bugs that may be related:
https://gitlab.gnome.org/GNOME/gimp/issues/3076
https://gitlab.gnome.org/GNOME/gimp/issues/1475

@Stephane: By any chance, had you ClipIt running at the
   time of the crash?


Yes.
ClipIt is running and it was last time too.
But I can-t see anything about gimp in CliIt.

Gimp just crashed again the same way filling another file.
I launched gimp this way:

script -a $PWD/gimp_$(date +%Y-%m-%d_%H-%M-%S).log -c "gimp --verbose"

and it ends this way:

[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has 
not been called

[xcb] Aborting, sorry about that.
gimp: ../../src/xcb_io.c:263: poll_for_event: Assertion 
`!xcb_xlib_threads_sequence_lost' failed.

gimp: fatal error: Aborted
/usr/lib/gimp/2.0/plug-ins/script-fu/script-fu terminated: Hangup

Bug information in Gimp Crash Debug window is:
===
```
GNU Image Manipulation Program version 2.10.8
git-describe: GIMP_2_10_6-294-ga967e8d2c2
C compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/8/lto-wrapper
Target: i686-linux-gnu
	Configured with: ../src/configure -v --with-pkgversion='Debian 
8.2.0-13' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ 
--prefix=/usr --with-gcc-major-version-only --program-suffix=-8 
--program-prefix=i686-linux-gnu- --enable-shared 
--enable-linker-build-id --libexecdir=/usr/lib 
--without-included-gettext --enable-threads=posix --libdir=/usr/lib 
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new 
--enable-gnu-unique-object --disable-vtable-verify --enable-libmpx 
--enable-plugin --enable-default-pie --with-system-zlib 
--with-target-system-zlib --enable-objc-gc=auto --enable-targets=all 
--enable-multiarch --disable-werror --with-arch-32=i686 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu 
--target=i686-linux-gnu

Thread model: posix
gcc version 8.2.0 (Debian 8.2.0-13)

using GEGL version 0.4.16 (compiled against version 0.4.12)
using GLib version 2.58.3 (compiled against version 2.58.1)
using GdkPixbuf version 2.38.1 (compiled against version 2.38.0)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.42.3 (compiled against version 1.42.3)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Aborted

Stack trace:
```
/usr/lib/libgimpbase-2.0.so.0(gimp_stack_trace_print+0x391)[0xb78b9461]
gimp(+0x8f61f)[0x49261f]
gimp(+0x8faa1)[0x492aa1]
gimp(+0x901cc)[0x4931cc]
linux-gate.so.1(__kernel_sigreturn+0x0)[0xb7faad7c]
linux-gate.so.1(__kernel_vsyscall+0x9)[0xb7faad71]
/lib/i386-linux-gnu/libc.so.6(gsignal+0xc2)[0xb6b90382]
/lib/i386-linux-gnu/libc.so.6(abort+0xf0)[0xb6b7a2b6]
/lib/i386-linux-gnu/libc.so.6(+0x191c1)[0xb6b7a1c1]
/lib/i386-linux-gnu/libc.so.6(+0x27339)[0xb6b88339]
/usr/lib/i386-linux-gnu/libX11.so.6(+0x39fe4)[0xb6a43fe4]
/usr/lib/i386-linux-gnu/libX11.so.6(+0x3a0e4)[0xb6a440e4]
/usr/lib/i386-linux-gnu/libX11.so.6(_XEventsQueued+0x72)[0xb6a44432]
/usr/lib/i386-linux-gnu/libX11.so.6(XPending+0x62)[0xb6a35ae2]
/usr/lib/i386-linux-gnu/libgdk-x11-2.0.so.0(+0x52208)[0xb7973208]
/usr/lib/i386-linux-gnu/libglib-2.0.so.0(g_main_context_check+0x19a)[0xb6eb6b5a]
/usr/lib/i386-linux-gnu/libglib-2.0.so.0(+0x4b175)[0xb6eb7175]
/usr/lib/i386-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0xe9)[0xb6eb7609]
gimp(app_run+0x37d)[0x491e0d]
gimp(main+0x389)[0x4915e9]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0xb6b7bb41]
gimp(_start+0x31)[0x4917c1]

```
===

It seems to happen quite often.
I've got a few drawings to colorize.
Do you want me too launch gimp a particular way to get more informations?


Regards.
--
Stephane



Bug#939022: [#939022] Re: pyresample: autopkgtest failure with PROJ 6 (epsg data file removed)

2019-08-31 Thread Sebastiaan Couwenberg
On 8/31/19 6:58 PM, Antonio Valentino wrote:
> it seems to me that the issue is in basemap rather then pyresample.

basemap most likely also needs to be updated to support PROJ 6
correctly, as pretty much everything using PROJ should.

> As far as I can understand it has been already fixed [1,2] in the latest
> version of basemap (1.2.1) which is still not in debian.
> 
> The problem seems to be related to the recent proj/pyproj updates and
> the location of EPSG data. In particular it seems that the "epsg" data
> file used by basemap was provided by proj-data v5.2.0 but is no longer
> in the new version. Is it correct?

The init files like epsg are not longer provided in PROJ 6, this data
moved to the proj.db SQLite database.

Now you shouldn't specify the init file when doing a transformation.

An example from the proj-rdnap test suite, for PROJ <= 5 it does:

 cs2cs -r +init=epsg:4258 +to +init=rdnap:rdnap -f %.4f

For PROJ 6 it does:

 cs2cs EPSG:4937 +to EPSG:7415 -f %.4f

Note that EPSG:4937 is the 3D equivalent of EPSG:4258. The epsg & rdnap
init files are no longer used, instead the projection database is used.

> I'm going to reassign.

That doesn't seem appropriate, pyresample needs to be updated too. It
does things like this:

 pyresample/test/test_geometry.py:
projections = {'+init=epsg:3006': 'init: epsg:3006'}

Note the explicit use of init files, this is not going to work correctly
with PROJ 6.

Kind Regards,

Bas

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



Bug#939057: python-tz: Invalid Vcs-Git and misleading maintainer

2019-08-31 Thread Raphaël Hertzog
Source: python-tz
Severity: normal

$ grep Vcs debian/control
Vcs-Browser: https://salsa.debian.org:/mckinstry/python-tz.git
Vcs-Git: https://salsa.debian.org:/mckinstry/python-tz.git

Those URL are unusual (incorrect?) with the colon. And they lead to a empty
repository:
https://salsa.debian.org/mckinstry/python-tz
(Note that we drop the trailing ".git" for Vcs-Browser)

Furthermore the Maintainer field indicates the python-modules team
but the package is not hosted there either. I couldn't find it
on https://salsa.debian.org/python-team/modules

$ grep Maintainer debian/control 
Maintainer: Debian Python Modules Team 


There's the zope team in Uploaders as well but there's no reason for this,
in particular given that the team as a whole is MIA.


Please fix all those inconsistencies and make the git repository
available. I believe it would be better withing the python modules team
ideally.

Thank you for your work maintaining this package!


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

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

-- no debconf information



Bug#939022: [#939022] Re: pyresample: autopkgtest failure with PROJ 6 (epsg data file removed)

2019-08-31 Thread Antonio Valentino
Dear Bas,
it seems to me that the issue is in basemap rather then pyresample.
As far as I can understand it has been already fixed [1,2] in the latest
version of basemap (1.2.1) which is still not in debian.

The problem seems to be related to the recent proj/pyproj updates and
the location of EPSG data. In particular it seems that the "epsg" data
file used by basemap was provided by proj-data v5.2.0 but is no longer
in the new version. Is it correct?

I'm going to reassign.

@sandro probably you are busy with other packages in this period so, if
it is OK for you, I could take in charge of updating the basemap package
on salsa (not sure I have push permissions anyway). You should only take
care of reviewing/upload since I'm not a DD/DM.


[1] https://github.com/matplotlib/basemap/pull/454
[2] https://github.com/matplotlib/basemap/issues/458


kind regards
antonio

On Sat, 31 Aug 2019 11:52:33 +0200 Bas Couwenberg 
wrote:
> Source: pyresample
> Version: 1.12.3-5
> Severity: serious
> Justification: makes the package in question unusable or mostly so
> Control: block 931949 by -1
> 
> Dear Maintainer,
> 
> Since the upgrade to proj (6.1.1-1) the autopkgtest of your package
> fails:
> 
>  https://ci.debian.net/packages/p/pyresample/unstable/amd64/
> 
> The log show that basemap tries to use the epsg data file which was
> removed in PROJ 6:
> 
>  autopkgtest [12:38:14]: test python3: [---
>  === python3.7 ===
>  Traceback (most recent call last):
>File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
>  "__main__", mod_spec)
>File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
>  exec(code, run_globals)
>File "/usr/lib/python3.7/unittest/__main__.py", line 18, in 
>  main(module=None)
>File "/usr/lib/python3.7/unittest/main.py", line 100, in __init__
>  self.parseArgs(argv)
>File "/usr/lib/python3.7/unittest/main.py", line 147, in parseArgs
>  self.createTests()
>File "/usr/lib/python3.7/unittest/main.py", line 159, in createTests
>  self.module)
>File "/usr/lib/python3.7/unittest/loader.py", line 220, in 
> loadTestsFromNames
>  suites = [self.loadTestsFromName(name, module) for name in names]
>File "/usr/lib/python3.7/unittest/loader.py", line 220, in 
>  suites = [self.loadTestsFromName(name, module) for name in names]
>File "/usr/lib/python3.7/unittest/loader.py", line 154, in 
> loadTestsFromName
>  module = __import__(module_name)
>File "/usr/lib/python3/dist-packages/pyresample/test/__init__.py", line 
> 26, in 
>  from pyresample.test import (
>File "/usr/lib/python3/dist-packages/pyresample/test/test_plot.py", line 
> 31, in 
>  from mpl_toolkits.basemap import Basemap
>File "/usr/lib/python3/dist-packages/mpl_toolkits/basemap/__init__.py", 
> line 152, in 
>  epsgf = open(os.path.join(pyproj.pyproj_datadir,'epsg'))
>  AttributeError: module 'pyproj' has no attribute 'pyproj_datadir'
>  autopkgtest [12:38:16]: test python3: ---]
>  autopkgtest [12:38:16]: test python3:  - - - - - - - - - - results - - - - - 
> - - - - -
>  python3  FAIL non-zero exit status 1
> 
> Please fix or remove the autopkgtest in your package.
> 
> Kind Regards,
> 
> Bas
> 
> 

-- 
Antonio Valentino



Bug#939056: icinga-cgi: Broken Apache authentication config

2019-08-31 Thread Dominic Hargreaves
Package: icinga-cgi
Version: 1.14.2+ds-3
Severity: important

On Thu, Jul 04, 2019 at 12:38:02PM +0200, Bas Couwenberg wrote:
> fixed 892628 icinga/1.14.2+ds-1
> thanks
> 
> Hi Jan,
> 
> On 2019-07-04 11:52, Jan Wagner wrote:
> > Am 11.03.18 um 19:20 schrieb Bas Couwenberg:
> > >* Update Apache configuration for 2.4 syntax.
> > >  (closes: #892628)
> > 
> > after upgrading to buster I did run into the problem, that there was no
> > authenticating when accessing icinga. Looking into 98d8eb16 show, that
> > you added
> > 
> > Require all granted
> > 
> > Seems that is not what you whated, cause requireing authentication it
> > has to be "Require all denied".
> 
> No, "Require all granted" is the Apache 2.4 equivalent of "Allow From All".
> Which is what this issue is about.
> 
> When authentication is configured, you need "Require valid-user". Which the
> configuration also uses. "Require all granted" should probably be dropped
> instead.
> 
> That being said, Icinga 1.x is EOL upstream and as documented in the
> release-notes you should migrate to Icinga 2.
> 
> I'm not going to fix this issue in buster, if you cannot migrate to icinga2
> soon, you can try the above to see if it fixes your issue.
> 
> Users who encounter this issue will have to fix the configuration
> themselves, or you or someone else needs to be willing to prepare as stable
> update for it.

I'm copying this to a new bug report to accurately reflect that's
still a bug, even if you don't plan to fix it.

Thanks,
Dominic.



Bug#939055: TigerVNC uses functions that depend on netbase but lacks dependency

2019-08-31 Thread MichaIng

Package: tigervnc-standalone-server
Version: 1.9.0+dfsg-3

When executing tigervncserver, while the netbase package is not 
installed, it throws the following error message multiple times:

--
Use of uninitialized value $proto in socket at /usr/bin/tigervncserver
--

This is due to the failing function getprotobyname() being called, but 
this function depends on files provided by the netbase package.


netbase is a recommendation of perl, but no dependency, thus it is not 
installed when tigervnc-standalone-server or perl is installed with 
--no-install-recommends option or related APT setting.


I am not sure if this is something that should be handled on 
netbase-side, e.g. to print a meaningful error message if this function 
fails, but alternatively tigervnc-standalone-server could add netbase to 
its dependency list.


This does not break the VNC startup or sessions. The originating 
function checks for used TCP ports. Since, if check fails, the script 
would die, I assume it simply always succeeds, if the proto value is 
empty. Rarely an issue, but not desired of course.


This issue is the same with wakeonlan: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928314




Bug#939048: transition: glibc

2019-08-31 Thread Paul Gevers
Hi,

On 31-08-2019 16:12, Aurelien Jarno wrote:
> I would like to get a transition slot for glibc 2.29. It is available in
> experimental for a bit more than 2 weeks and there is no known issue or
> regression.
I can have the experimental-to-unstable pseudo britney run finish its
work for glibc soon. That can tell us if there are potential autopkgtest
regressions to be expected.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#932960: python-django doesn't fix a CVE and drops Python 2 support at the same time

2019-08-31 Thread Paul Gevers
Hi,

On Fri, 02 Aug 2019 23:02:51 +0100 "Chris Lamb"  wrote:
> So, it looks like:
> 
> django-compat django-hijack
> django-ratelimit
> django-testscenarios
> grr
> python-aws-xray-sdk
> python-carrot
> python-django-bootstrap-form
> python-oauth2client
> python-semantic-version
> 
> … still Build-Depend or Build-Depend-Indep on python-django.
> 
> (Zigo, did you neglect python-oauth2client and python-semantic-version
> in your mass uploads recently?)

The list is going down steadily. Currently this is what I see as remaining:

paul@testavoira ~ $ reverse-depends -b python-django
Reverse-Build-Depends-Indep
===
* kombu
* python-django-bootstrap-form
* python-django-registration
* python-oauth2client
* python-semantic-version

Reverse-Build-Depends
=
* django-compat
* django-hijack
* django-modeltranslation
* django-nose
* django-picklefield
* django-prometheus
* django-ratelimit
* grr
* mini-buildd
* python-aws-xray-sdk

paul@testavoira ~ $ reverse-depends python-django
Reverse-Depends
===
* bcfg2-web
* djagios
* grr-server
* python-ajax-select
* python-bootstrapform
* python-django-app-plugins
* python-django-compat
* python-django-modeltranslation
* python-django-nose
* python-django-picklefield
* python-django-prometheus
* python-django-ratelimit
* python-django-registration
* python-django-rosetta
* python-django-threaded-multihost
* python-mini-buildd

Packages without architectures listed are reverse-dependencies in:
amd64, arm64, armel, armhf, i386, mipsel, ppc64el, s390x

And the lava autopkgtest failure, however src:lava is currently marked
for autoremoval on 7 September.

The dependencies are properly tracked by britney, I'll drop my block
when all the reverse build dependencies are fixed.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#935496: Fails to install: Invalid action '-p'

2019-08-31 Thread GCS
Hi,

On Fri, Aug 30, 2019 at 12:03 PM Simon McVittie  wrote:
> On Fri, 23 Aug 2019 at 10:04:28 +0200, Michael Biebl wrote:
> > Setting up fuse (2.9.9-1) ...
> > dpkg: error processing package fuse (--configure):
> >  installed fuse package post-installation script subprocess returned error 
> > exit status 1
> ...
> > # udevadm test --action -p /devices/virtual/misc/fuse
> > Invalid action '-p'
 Ouch, it's a leftover (outdated lines) from the time when fuse
installed its udev rules. Now it should be something like this:
"udevadm test --action=change /devices/virtual/misc/fuse".
But now as udev ships its fuse rules (in 50-udev-default.rules and
99-systemd.rules) this is not needed anymore.

> Similar to the equivalent fuse3 bug #934293, this seems to be a regression
> since buster: the same binary package installs OK on buster. Maybe
> udevadm became more strict about its parameter parsing?
 As mentioned elsewhere, this seems to be the case. About the the
transition, it is expected but I would like to get more information on
it.

> Similar to fuse3, it would be helpful if the maintainer script had less
> "> /dev/null 2>&1" so that error messages would appear.
 Well, the expected output (on my Buster system) is 131 lines long.
These are not relevant for normal users / usage.

> > I'm not exactly sure what this code is supposed to achieve.
> > Since fuse no longer ships its own udev rules, maybe it can be dropped
> > altogether?
 Trigger an udev rules change after the package installed its udev rule.

> Or if the postinst is still necessary, maybe fuse3 could take over the
> fuse binary package name for bullseye (with a transitional package) so that
> bugs like this one don't need to be fixed in both places?
 For the time I will fix it independently. I can't promise when the
actual transition will take place.
But if you can, please check the proposed package update[1].

Thanks,
Laszlo/GCS
[1] dget -x http://www.barcikacomp.hu/gcs/fuse_2.9.9-2.dsc



Bug#930446: popularity-contest: unable to submit report, impossible to debug

2019-08-31 Thread Ludovic Rousseau

Le 31/08/2019 à 16:05, Bill Allombert a écrit :

On Thu, Aug 29, 2019 at 10:38:29PM +0200, Ludovic Rousseau wrote:

On Wed, 12 Jun 2019 22:52:59 +0200 Bill Allombert  wrote:

On Wed, Jun 12, 2019 at 09:46:58PM +0200, Stefan Fritsch wrote:

Package: popularity-contest
Version: 1.67
Severity: normal

Dear Maintainer,
on several of my hosts, popularity-contest logs
   unable to submit report to

http://popcon.debian.org/cgi-bin/popcon.cgi.

   unable to submit report.

But it does not log why and there is no way that I could find to

trigger

the sending from the command line with debug output enabled.

http://popcon.debian.org/cgi-bin/pop is reachable from the host via

curl. Also,

according to the documentation it should fall back to email, which it does not
do. It does not log why it does not do that.


Hello Stefan!

This comes from /etc/cron.daily/popularity-contest:
# try to post the report through http POST
if [ "$SUBMITURLS" ] && [ "yes" = "$USEHTTP" ]; then
 for URL in $SUBMITURLS ; do
 if setsid /usr/share/popularity-contest/popcon-upload \
 -u $URL -f $POPCON 2>/dev/null ; then
 SUBMITTED=yes
 else
 logger -t popularity-contest "unable to submit report to
$URL."
 fi
 done
fi

/usr/share/popularity-contest/popcon-upload has an option -d for
debugging that you could try.


I added the -d to get some more debug.


Hello Ludovic,

This report is about Stefan problem.

Stefan problem is that popcon is reporting twice, one with cron.d
time and one with the cron.daily fallback, which means somehow the
mechanism to detect that the report was already sent did not work.

Is it your problem too ? According to the email you send me, your report
is also sent at 6:25 which suggests this is the case, since the cron.daily
fallback run at 6:25.


My problem is the same as the original issue reported by Stefan Fritsch.
In my logs I get (same as Stefan):
Aug 29 06:25:15 PiHole popularity-contest: unable to submit report to 
http://popcon.debian.org/cgi-bin/popcon.cgi.
Aug 29 06:25:15 PiHole popularity-contest: unable to submit report

I have no idea if the submission worked or not.


In which case, could you check what is the issue with the timestamp
(see the full buildlog) ?


Can you be more specific about what you want me to check?


In you have an unrelated problem, please open a separate bug report.

The debug output you got just means that the server failed to answer.


Sure.
Why did the server failed to answer?

I have the same problem on different systems, not just one.

Bye

--
 Dr. Ludovic Rousseau



Bug#935947: stretch-pu: package llvm-toolchain-7 7.0.1-8~deb9u1

2019-08-31 Thread Adam D. Barratt
On Wed, 2019-08-28 at 12:53 +0200, Emilio Pozuelo Monfort wrote:
> I'd like to introduce llvm-toolchain-7 into stretch, as it's needed
> to update rustc to 1.34.2, which in turn is needed for firefox ESR
> 68.
> 
> I have already uploaded the package, which is a straight backport
> from the buster version (see attached debdiff) and I have used it to
> backport rustc (and used that to build firefox) and it's working
> well.
> 
> It'd be good to get this into the next point release to ease the
> firefox 68 ESR security updates, targetted for October.

That happened, and so far FTBFS on ppc64el and s390x, with an error
referencing an inability to find "ocamlopt".

I suspect that's due to this change in src:ocaml:

ocaml (4.03.0-2) experimental; urgency=medium

  * Add native compilers for ppc64, ppc64el, s390x.
  * Skip native tests on bytecode-only systems.

 -- Ximin Luo   Fri, 28 Oct 2016 02:13:18 +0200

stretch has ocaml 4.02.3-9.

Regards,

Adam



Bug#939021: yakuake: .bash_aliases file is not applied

2019-08-31 Thread Vincas Dargis

After some testing, I doubt this has anything to do with yakuake.

My `yakuake` profile starts `tmux` (/bin/bash -c tmux), and if I don't it works fine. If I start 
`tmux` in Konsole, I get same issue...


So it's `tmux` that ignores .bash_aliases..?



Bug#939054: O: editmoin -- edit MoinMoin wiki pages with your favourite editor

2019-08-31 Thread Martin Pitt
Package: wnpp

I haven't used editmoin myself for many years, and the upstream project has
been dead for even longer than that. I'm not even sure any more how well it
works on recent moinmoin setups.

The biggest issue right now is porting it to Python 3
(https://bugs.debian.org/936466).

If nobody is interested in adopting this package, I suggest to just remove it
from bullseye/sid.

Packaging-wise, this is in a good shape. salsa git+gbp+dh, etc.

Package: editmoin
Version: 1.17-4
Installed-Size: 51
Maintainer: Martin Pitt 
Architecture: all
Depends: python:any
Recommends: sensible-utils
Suggests: vim-addon-manager
Description-en: edit MoinMoin wiki pages with your favourite editor
 editmoin allows you to edit pages in MoinMoin wikis with your
 preferred editor instead of the (usually quite limited) web
 browser text areas.
 .
 It also supports configuration files to define shortcuts for URLs
 that you edit often.
 .
 This package also includes a Vim syntax file. Install
 vim-addon-manager and use "vim-addons install editmoin" to activate.
 .
 However, you can use any other editor by setting the standard $EDITOR
 environment variable.


Thanks,

Martin


signature.asc
Description: PGP signature


Bug#939053: firejail: dolphin profile only allows single window

2019-08-31 Thread Marc Lehmann
Package: firejail
Version: 0.9.58.2-2
Severity: normal

Dear Maintainer,

when running dolphin in firejail with the default profile, it can only
open a single window/can only be started once.

opening a second instance fails like this (including quotes):

   "Couldn't register name 'org.kde.dolphin-3' with DBUS - another process owns 
it already!"

org.kde.dolphin-3 also is seen with other numbers at the end.

I would have expected that basic usage of dolphin is undisturbed by firejail, 
but maybe my
expectation is wrong and this is the expected outcome.

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

Kernel: Linux 5.1.21-050121-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_DK.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 firejail depends on:
ii  libapparmor1  2.13.2-10
ii  libc6 2.28-10

Versions of packages firejail recommends:
ii  firejail-profiles  0.9.58.2-2
ii  iproute2   4.20.0-2
ii  iptables   1.8.2-4
ii  xauth  1:1.0.10-1
ii  xserver-xephyr 2:1.20.4-1
ii  xvfb   2:1.20.4-1

firejail suggests no packages.

-- no debconf information



Bug#935300: rsyslog: FTBFS on s390x

2019-08-31 Thread Michael Biebl
Am 31.08.19 um 16:43 schrieb Michael Biebl:
> So instead I tried reverting the following commit which was in the vicinity:
> 
> commit 7ad178cea388dd1ffc9ac17ae2fecae32c8443b3
> Author: Rainer Gerhards 
> Date:   Wed Jul 31 11:36:27 2019 +0200
> 
> omfile bugfix: race file when async writing is enabled
> 
> This seems to be a long-standing bug, introduced around 7 years ago.
> It became more visible by properly closing files during HUP, which
> was done in 8.1905.0 (and was another bugfix).
> 
> closes https://github.com/rsyslog/rsyslog/issues/3772
> 
> And tada, with that one reverted, asynwr_deadlock2 passes again on the
> s390x porterbox.

Bad news is, with that commit reverted, now the following two tests fail
(at least on the s390x porter machine)

gzipwr_hup_multi_file
gzipwr_hup_single_file



-- 
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#939052: mpd: Stuttering after about 4 to 5 second or longer pause.

2019-08-31 Thread Michel
Package: mpd
Version: 0.21.13-1
Severity: normal

Dear Maintainer,

After upgrading mpd from 0.21.5-3 to 0.21.13-1. Noticed that, when a
track is paused for at least about 4 to 5 seconds or longer, about split
second to about a second after un-pausing a track get a stutter that
does not reoccur unless the track is paused again for about 4 to 5
seconds or longer.


Looked at ~/.mpd/log does show the following:

Aug 31 11:08 : alsa_output: Decoder is too slow; playing silence to avoid xrun

each time a stutter happens.


After downgrading mpd from 0.21.13-1 back to 0.21.5-3, the stuttering
after about 4 to 5 second or longer pause is gone. And ~/.mpd/log no
longer shows those xrun messages.

I wonder if this is fixed in 0.21.14?

ver 0.21.14 (2019/08/21)
* player
- fix seek position after restarting the decoder


Thank You.


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

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

Versions of packages mpd depends on:
ii  adduser   3.118
ii  init-system-helpers   1.57
ii  libadplug-2.2.1-0v5   2.2.1+dfsg3-1+b1
ii  libao41.2.2+20180113-1+b1
ii  libasound21.1.8-1
ii  libaudiofile1 0.3.6-5
ii  libavahi-client3  0.7-4+b1
ii  libavahi-common3  0.7-4+b1
ii  libavcodec58  7:4.1.4-1+b2
ii  libavformat58 7:4.1.4-1+b2
ii  libavutil56   7:4.1.4-1+b2
ii  libbz2-1.01.0.6-9.2
ii  libc6 2.28-10
ii  libcdio-cdda2 10.2+2.0.0-1+b1
ii  libcdio-paranoia2 10.2+2.0.0-1+b1
ii  libcdio18 2.0.0-2
ii  libcurl3-gnutls   7.65.3-1
ii  libdbus-1-3   1.12.16-1
ii  libexpat1 2.2.7-1
ii  libfaad2  2.8.8-3
ii  libflac8  1.3.3-1
ii  libfluidsynth11.1.11-4
ii  libgcc1   1:9.2.1-4
ii  libgcrypt20   1.8.4-5
ii  libgme0   0.6.2-1+b1
ii  libicu63  63.2-2
ii  libid3tag00.15.1b-14
ii  libiso9660-11 2.0.0-2
ii  libixml10 1:1.8.4-2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2+b1
ii  libjs-sphinxdoc   1.8.5-3
ii  libmad0   0.15.1b-10
ii  libmikmod33.3.11.1-4
ii  libmms0   0.6.4-3
ii  libmodplug1   1:0.8.9.0-2
ii  libmp3lame0   3.100-2+b1
ii  libmpcdec62:0.1~r495-1+b2
ii  libmpdclient2 2.16-1+b1
ii  libmpg123-0   1.25.11-1
ii  libnfs12  3.0.0-2
ii  libogg0   1.3.2-1+b1
ii  libopenal11:1.19.1-1+b1
ii  libopus0  1.3-1+b1
ii  libpcre3  2:8.39-12+b1
ii  libpulse0 12.99.2-1
ii  libsamplerate00.1.9-2
ii  libshout3 2.4.1-2
ii  libsidplayfp4 1.8.8-1+b1
ii  libsmbclient  2:4.9.11+dfsg-1
ii  libsndfile1   1.0.28-6
ii  libsoxr0  0.1.2-3
ii  libsqlite3-0  3.29.0-2
ii  libstdc++69.2.1-4
ii  libsystemd0   242-4
ii  libupnp13 1:1.8.4-2
ii  libvorbis0a   1.3.6-2
ii  libvorbisenc2 1.3.6-2
ii  libwavpack1   5.1.0-7
ii  libwildmidi2  0.4.3-1
ii  libyajl2  2.1.0-3
ii  libzzip-0-13  0.13.62-3.2
ii  lsb-base  11.1.0
ii  zlib1g1:1.2.11.dfsg-1+b1

mpd recommends no packages.

Versions of packages mpd suggests:
ii  ario [mpd-client] 1.6-1+b1
ii  avahi-daemon  0.7-4+b1
pn  icecast2  
ii  mpc [mpd-client]  0.32-1+b1
ii  ncmpcpp [mpd-client]  0.8.2-0.1+b1
ii  pulseaudio12.99.2-1

-- no debconf information



Bug#935984: freerdp-x11: crashes with illegal instruction, winpr libraries contain SSE2 instructions on i386

2019-08-31 Thread Ondrej Zary
Hello,
thanks, freerdp2-x11 works fine.
It's also in stretch-backports so I can use it on my Stretch machines.

On Saturday 31 August 2019 17:08:24 Bernhard Übelacker wrote:
> Hello Ondrej Zary,
> while looking through bug reports for some random
> packages I got to your report.
> I guess your system got updated at least from Stretch to Buster,
> therefore you might have freerdp-x11 installed while that
> is not part of the official Buster release.
> It got also removed from Sid, therefore this report
> would just be a concern for Stretch.
> 
> If I see it right, it got replaced by freerdp2-x11.
> As far as I see that contains (from your short objdump test)
> no SSE2 instructions. Maybe that works for your purpose.
> 
> Attached patch shows an incomplete attempt to build without
> sse2, but unfortunately that fails, would need some more work.
> 
> Kind regards,
> Bernhard
> 
> 
> benutzer@debian:~$ objdump -d /usr/lib/i386-linux-gnu/libwinpr2.so.2.0.0 | 
> grep xmm
> benutzer@debian:~$ objdump -d /usr/bin/xfreerdp | grep xmm
> benutzer@debian:~$
> 


-- 
Ondrej Zary



Bug#935827: buster-pu: package cryptsetup/2:2.1.0-5+deb10u2

2019-08-31 Thread Cyril Brulebois
Hi,

Guilhem Moulin  (2019-08-26):
> A s-p-u was previously filed (#934956) — and accepted — for 2:2.1.0-5+deb10u1.
> The new commit cherry-picked from upstream also includes a unit test; like
> most of the test suite it'll be ignored by the build daemons as it requires
> root access, but I did verify that the entire test suite still passes on amd64
> and i386 (and that indeed large devices no longer overflow).
> 
> Given that Buster currently has 2:2.1.0-5, should the .changes include all
> changes since that version, or only since 2:2.1.0-5+deb10u1?
> 
> Thanks for considering its inclusion in Buster!  CC'ing KiBi for the d-i ack.

No obvious regressions, so no objections.


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


signature.asc
Description: PGP signature


Bug#932684: buster-pu: package gnupg2/2.2.12-1+deb10u1

2019-08-31 Thread Cyril Brulebois
Adam D. Barratt  (2019-08-22):
> > Thanks, that's entirely reasonable.  I've put this NEWS item into the
> > debian/buster branch on salsa.  Otherwise, the debdiff is the same.

No obvious regressions, so no objections.


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


signature.asc
Description: PGP signature


Bug#896557: (no subject)

2019-08-31 Thread Alexandros Afentoulis

I removed myself from owner of as I no further use this package.



Bug#935984: freerdp-x11: crashes with illegal instruction, winpr libraries contain SSE2 instructions on i386

2019-08-31 Thread Bernhard Übelacker
Hello Ondrej Zary,
while looking through bug reports for some random
packages I got to your report.
I guess your system got updated at least from Stretch to Buster,
therefore you might have freerdp-x11 installed while that
is not part of the official Buster release.
It got also removed from Sid, therefore this report
would just be a concern for Stretch.

If I see it right, it got replaced by freerdp2-x11.
As far as I see that contains (from your short objdump test)
no SSE2 instructions. Maybe that works for your purpose.

Attached patch shows an incomplete attempt to build without
sse2, but unfortunately that fails, would need some more work.

Kind regards,
Bernhard


benutzer@debian:~$ objdump -d /usr/lib/i386-linux-gnu/libwinpr2.so.2.0.0 | grep 
xmm
benutzer@debian:~$ objdump -d /usr/bin/xfreerdp | grep xmm
benutzer@debian:~$
Description: Disable SSE2 and SSE3
Bug-Debian: https://bugs.debian.org/935984
Last-Update: 2019-08-31

--- freerdp-1.1.0~git20140921.1.440916e+dfsg1.orig/CMakeLists.txt
+++ freerdp-1.1.0~git20140921.1.440916e+dfsg1/CMakeLists.txt
@@ -153,7 +153,7 @@ if(CMAKE_COMPILER_IS_GNUCC)
 		set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -g")
 	endif()
 	if(WITH_SSE2)
-		set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -msse2")
+		set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ")
 	endif()
 endif()
 
--- freerdp-1.1.0~git20140921.1.440916e+dfsg1.orig/libfreerdp/codec/CMakeLists.txt
+++ freerdp-1.1.0~git20140921.1.440916e+dfsg1/libfreerdp/codec/CMakeLists.txt
@@ -62,7 +62,7 @@ if(WITH_SSE2)
 	set(${MODULE_PREFIX}_SRCS ${${MODULE_PREFIX}_SRCS} ${${MODULE_PREFIX}_SSE2_SRCS})
 
 	if(CMAKE_COMPILER_IS_GNUCC)
-		set_source_files_properties(${${MODULE_PREFIX}_SSE2_SRCS} PROPERTIES COMPILE_FLAGS "-msse2")
+		set_source_files_properties(${${MODULE_PREFIX}_SSE2_SRCS} PROPERTIES COMPILE_FLAGS "")
 	endif()
 
 	if(MSVC)
--- freerdp-1.1.0~git20140921.1.440916e+dfsg1.orig/libfreerdp/primitives/CMakeLists.txt
+++ freerdp-1.1.0~git20140921.1.440916e+dfsg1/libfreerdp/primitives/CMakeLists.txt
@@ -50,7 +50,7 @@ endif()
 
 if(WITH_SSE2)
 	if(CMAKE_COMPILER_IS_GNUCC)
-		set(OPTIMIZATION "${OPTIMIZATION} -msse2 -mssse3 -Wdeclaration-after-statement")
+		set(OPTIMIZATION "${OPTIMIZATION} -Wdeclaration-after-statement")
 	endif()
 
 	if(MSVC)
--- freerdp-1.1.0~git20140921.1.440916e+dfsg1.orig/libfreerdp/primitives/test/CMakeLists.txt
+++ freerdp-1.1.0~git20140921.1.440916e+dfsg1/libfreerdp/primitives/test/CMakeLists.txt
@@ -84,7 +84,7 @@ endif()
 
 if(WITH_SSE2)
 	if(CMAKE_COMPILER_IS_GNUCC)
-		set(OPTFLAGS "${OPTFLAGS} -msse2 -mssse3 -O2 -Wdeclaration-after-statement")
+		set(OPTFLAGS "${OPTFLAGS} -O2 -Wdeclaration-after-statement")
 	endif()
 
 	if(MSVC)


Bug#939051: python3-autopep8: Please drop python3-autopep8 recommending python-autopep8

2019-08-31 Thread Scott Kitterman
Package: python3-autopep8
Version: 1.4.4-1
Severity: normal

Versions of packages python3-autopep8 recommends:
pn  python-autopep8  

Python2 packages are in the process of being removed, so eventually
python-autopep8 will have to be removed.  In the mean time, this
recommendation entangles python3-autopep8 in the python2 removal effort
in a way that is not useful.

Scott K



Bug#939050: lintian: python3-depends-but-no-python3-helper ignores Build-Depends: dh-sequence-python3

2019-08-31 Thread Simon McVittie
Package: lintian
Version: 2.19.0
Severity: normal

Steps to reproduce:

* Get tap.py_2.5-2.dsc from the archive. It is currently Lintian-clean.
* Apply the patch below to replace "dh --with foo" with
  Build-Depends: dh-sequence-foo where possible, and build a new source
  package. I believe the patched package is still considered correct:
  ${python:Depends} and ${python3:Depends} get filled in correctly.

Expected result:

No new Lintian warnings (except complaining about the Standards-Version
being outdated for the new changelog date, if you ran dch)

Actual result:

E: tap.py source: python-depends-but-no-python-helper python-tap
E: tap.py source: python3-depends-but-no-python3-helper python3-tap tappy

Minimal patch to make the package that reproduces this:

8<
diff -Nru tap.py-2.5/debian/control tap.py-2.5/debian/control
--- tap.py-2.5/debian/control   2019-01-14 09:47:23.0 +
+++ tap.py-2.5/debian/control   2019-08-31 15:36:42.0 +0100
@@ -9,6 +9,8 @@
  debhelper-compat (= 12),
  dh-exec,
  dh-python,
+ dh-sequence-python2,
+ dh-sequence-python3,
  python-all,
  python-babel,
  python-docutils,
diff -Nru tap.py-2.5/debian/rules tap.py-2.5/debian/rules
--- tap.py-2.5/debian/rules 2019-01-14 09:47:23.0 +
+++ tap.py-2.5/debian/rules 2019-08-31 15:36:51.0 +0100
@@ -5,7 +5,7 @@

 # main packaging script based on dh7 syntax
 %:
-   dh $@ --with python2,python3,sphinxdoc --buildsystem=pybuild
+   dh $@ --with sphinxdoc --buildsystem=pybuild


 override_dh_auto_build:
8<

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

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

Versions of packages lintian depends on:
ii  binutils 2.32.51.20190821-2
ii  bzip21.0.6-9.2
ii  diffstat 1.62-1+b1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.37-5
ii  gettext  0.19.8.1-9
ii  gpg  2.2.17-3
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b1
ii  libarchive-zip-perl  1.64-1
ii  libcapture-tiny-perl 0.48-1
ii  libcgi-pm-perl   4.44-1
ii  libclass-accessor-perl   0.51-1
ii  libclone-perl0.41-1+b1
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.74-1
ii  libipc-run-perl  20180523.0-1
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b4
ii  libmoo-perl  2.003004-2
ii  libpath-tiny-perl0.108-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3000-2
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.004004-1
ii  liburi-perl  1.76-1
ii  libxml-simple-perl   2.25-1
ii  libyaml-libyaml-perl 0.80+repack-1
ii  man-db   2.8.7-3
ii  patchutils   0.3.4-2+b1
ii  perl [libdigest-sha-perl]5.28.1-6
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1+b1

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

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

-- no debconf information



Bug#935300: rsyslog: FTBFS on s390x

2019-08-31 Thread Michael Biebl
On Wed, 21 Aug 2019 19:27:34 +0200 Rainer Gerhards
 wrote:
> I had a look but to me it seems we actually run out file handles. No
> failure indication.
>   
> Is this run in parallel? If so, how many tasks?
> 

I'm running the test-suite with the --no-parallel option, so no parallel
tests.
It seems to be the asynwr_deadlock2 test which fails.

I can reproduce this issue on a s390x porter machine by simply executing
the test

git bisect points at the following as the first faulty commit:

967b7eac17b601c773ee46017eed03cedf14be8d is the first bad commit
commit 967b7eac17b601c773ee46017eed03cedf14be8d
Merge: 2a33b2877 0b2477a9f
Author: Rainer Gerhards 
Date:   Wed Jul 31 11:35:48 2019 +0200

Merge pull request #3780 from rgerhards/i3760

imrelp bugfix: hang after HUP

 plugins/imrelp/imrelp.c | 7 +--
 runtime/glbl.c  | 2 +-
 runtime/glbl.h  | 1 +
 3 files changed, 7 insertions(+), 3 deletions(-)

That doesn't look related immediately so I was wondering if git bisect
got a bit confused by the merge history.

So instead I tried reverting the following commit which was in the vicinity:

commit 7ad178cea388dd1ffc9ac17ae2fecae32c8443b3
Author: Rainer Gerhards 
Date:   Wed Jul 31 11:36:27 2019 +0200

omfile bugfix: race file when async writing is enabled

This seems to be a long-standing bug, introduced around 7 years ago.
It became more visible by properly closing files during HUP, which
was done in 8.1905.0 (and was another bugfix).

closes https://github.com/rsyslog/rsyslog/issues/3772

And tada, with that one reverted, asynwr_deadlock2 passes again on the
s390x porterbox.

-- 
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#939049: src:lua5.3: new upstream version 5.3.5

2019-08-31 Thread Clint Adams
Package: src:lua5.3
Version: 5.3.3-1.1
Severity: normal

Please update to 5.3.5 (or newer).



Bug#935815: gnome-bluetooth 3.28.2-4~deb10u1 flagged for acceptance

2019-08-31 Thread Adam D Barratt
package release.debian.org
tags 935815 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: gnome-bluetooth
Version: 3.28.2-4~deb10u1

Explanation: avoid GNOME Shell crashes when 
gnome-shell-extension-bluetooth-quick-connect is used



Bug#939048: transition: glibc

2019-08-31 Thread Aurelien Jarno
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear release team,

I would like to get a transition slot for glibc 2.29. It is available in
experimental for a bit more than 2 weeks and there is no known issue or
regression. It has been built successfully on all release architectures
and most ports architectures. It fails to build on alpha, ia64 and
sparc64 due to a few testsuite issues that are being investigated or
need to be investigated and which do not looks really worrying. It
doesn't build on kfreebsd-*, but this has been the case for a few
glibc releases already.

As glibc is using symbol versioning, there is no soname change. That
said a few packages are using libc internal symbols and have to be
rebuilt for this transition (some packages only on some architectures):
 - apitrace
 - bro
 - dante
 - gcc-9
 - gcc-snapshot
 - glibc
 - libnih
 - libnss-db
 - unscd

Ben file:

Here is the corresponding ben file:
  title = "glibc";
  is_affected = .depends ~ /libc[0-9.]* \(<

Bug#930446: popularity-contest: unable to submit report, impossible to debug

2019-08-31 Thread Bill Allombert
On Thu, Aug 29, 2019 at 10:38:29PM +0200, Ludovic Rousseau wrote:
> On Wed, 12 Jun 2019 22:52:59 +0200 Bill Allombert  wrote:
> > On Wed, Jun 12, 2019 at 09:46:58PM +0200, Stefan Fritsch wrote:
> > > Package: popularity-contest
> > > Version: 1.67
> > > Severity: normal
> > > > Dear Maintainer,
> > > > on several of my hosts, popularity-contest logs
> > > >   unable to submit report to
> > http://popcon.debian.org/cgi-bin/popcon.cgi.
> > >   unable to submit report.
> > > > But it does not log why and there is no way that I could find to
> > trigger
> > > the sending from the command line with debug output enabled.
> > > > http://popcon.debian.org/cgi-bin/pop is reachable from the host via
> > curl. Also,
> > > according to the documentation it should fall back to email, which it 
> > > does not
> > > do. It does not log why it does not do that.
> > 
> > Hello Stefan!
> > 
> > This comes from /etc/cron.daily/popularity-contest:
> > # try to post the report through http POST
> > if [ "$SUBMITURLS" ] && [ "yes" = "$USEHTTP" ]; then
> > for URL in $SUBMITURLS ; do
> > if setsid /usr/share/popularity-contest/popcon-upload \
> > -u $URL -f $POPCON 2>/dev/null ; then
> > SUBMITTED=yes
> > else
> > logger -t popularity-contest "unable to submit report to
> > $URL."
> > fi
> > done
> > fi
> > 
> > /usr/share/popularity-contest/popcon-upload has an option -d for
> > debugging that you could try.
> 
> I added the -d to get some more debug.

Hello Ludovic,

This report is about Stefan problem.

Stefan problem is that popcon is reporting twice, one with cron.d
time and one with the cron.daily fallback, which means somehow the
mechanism to detect that the report was already sent did not work.

Is it your problem too ? According to the email you send me, your report
is also sent at 6:25 which suggests this is the case, since the cron.daily
fallback run at 6:25.

In which case, could you check what is the issue with the timestamp
(see the full buildlog) ?

In you have an unrelated problem, please open a separate bug report.

The debug output you got just means that the server failed to answer.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



  1   2   >