Bug#941062: RM: webhelpers -- RoM; obsolete; no Python 3 support

2019-09-24 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Part of the Pylons stack, last release in 2011.

Reverse deps checked with dak rm -Rn pylons webhelpers

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#941061: RM: pylons -- RoM; obsolete; no Python 3 support

2019-09-24 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Pylons is dead and Python2-only. The only revdep is python-webhelpers.

Reverse deps checked with dak rm -Rn pylons webhelpers

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#941063: RM: python-weberror -- RoM; no Python 3 support

2019-09-24 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Part of the Pylons stack. Last release in 2016, but no Python 3 support
anyway. "This software is not actively maintained. Simple bugfixes and
other patches will be accepted, and released."

Reverse deps checked with dak rm -Rn pylons webhelpers python-weberror

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#941064: RM: myghty -- RoQA; orphaned; obsolete; no Python 3 support

2019-09-24 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Long dead. "Myghty is a legacy library. New projects should use Mako
templates". Last release in 2010.

Reverse deps checked with dak rm -Rn myghty pylons webhelpers

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#941065: dh_strip: Please provide a way to pass options to strip

2019-09-24 Thread Matthias Klose

Package: debhelper
Version: 12.6.1

For packages needing debug information for backtraces or stack unwinding in the 
binary itself, it's not possible to pass custom strip optons to strip, having to 
mimic the dh_strip behavior in the rules when you require different options for 
stripping. Also with the proposed new CTF debug format package might want to 
keep the relatively small CTF overhead instead of the rather large DWARF debug 
information.


There is also discussion at [1] how upstream strip should handle stripping CTF.

[1] https://sourceware.org/ml/binutils/2019-09/msg00209.html



Bug#941066: RM: python-toscawidgets -- RoQA; orphaned; no Python 3 support and no reverse deps

2019-09-24 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Last release in 2011. Popcon 20.

Reverse deps checked with dak rm -Rn python-toscawidgets

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#941067: RM: python-webflash -- RoQA; orphaned; dead upstream; no Python 3 support and no reverse deps

2019-09-24 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Last release in 2009. http://python-rum.org/wiki/WebFlash is dead.

Reverse deps checked with dak rm -Rn python-webflash

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#935931: debian-installer: Reinstalling Debian on a current Debian installation without erasing or fomatting the home folder

2019-09-24 Thread Holger Wansing
Hi,

Daniel  wrote:
> Package: debian-installer
> Severity: wishlist
> 
> Dear Maintainer, this is a feature request.
> 
> Debian related distros like POP!_os and ElementaryOS, when the system is
> installed in one partition: I mean inside "/", have the ability to recognize
> the previous installation and reinstalling the system without erasing the user
> folders already existing, so you can reuse your actual existent user. It would
> be a nice feature having the same on Debian; for desktop installations this
> eliminates the necessity to have partitions separated while you can reinstall
> your system several times for whatever reason. Even macOS has this feature
> since a very long time.

The debian-installer supports similar use case via the "separate partition for
/home" approach.


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076



Bug#941068: nmu: dolfin_2019.1.0-5

2019-09-24 Thread Drew Parsons
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

dolfin has a tight dependency on pybind11 (we were burnt in the past
by mismatching pybind11 builds), so requires binNMU to update.

nmu dolfin_2019.1.0-5 . ANY . unstable . -m "Rebuild against pybind11 2.4.2."



mshr will follow after this, dep-wait on dolfin (is this needed?),

dw mshr_2019.1.0+dfsg1-4 . ANY . unstable . -m "python3-dolfin (>= 
2019.1.0-5+b1)"

then,

nmu mshr_2019.1.0+dfsg1-4 . ANY . unstable . -m "Rebuild against pybind11 
2.4.2."

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (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_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled



Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

2019-09-24 Thread Trek
On Tue, 24 Sep 2019 07:28:29 +0800
Ian Campbell  wrote:

> Has anyone investigated late dynamic binding using a stub library
> which merely determines which init is running and then dlopens the
> appropriate libsystemd0 of libelogind0 library and forwards the calls
> to it?

it could be in the form of libglvnd, a generic dispatcher to have
co-installed multiple vendor implementations of libgl, with runtime
selection

https://github.com/NVIDIA/libglvnd

a stripped down version of that architecture could be used to simply
detect what init system is actually running and then dispatch to the
correct library (libsystemd or libelogind)

ciao!



Bug#562727:

2019-09-24 Thread duke james
-- 
האם קיבלת את מכתבי הקודם?


Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

2019-09-24 Thread Mark Hindley
Ian,

Thanks for this.

On Tue, Sep 24, 2019 at 07:28:29AM +0800, Ian Campbell wrote:
> On Fri, 2019-09-20 at 10:16 +0100, Mark Hindley wrote:
> Would it be any help at all of the "dbus client-ish" bits and the
> "direct API-ish" bits of the two libraries were split up into two
> separate libraries? i.e. would that allow the c/r/p replacement of one
> of the two libraries (AIUI the API one is the more problematic) to be
> pushed further up the dependency stack?

I think that is what we already have (if I have understood you correctly). The
dbus components are in systemd/elogind and the sd-*(3) APIs are in
libsystemd0/libelogind0. Or have I misunderstood?

> Has anyone investigated late dynamic binding using a stub library which
> merely determines which init is running and then dlopens the
> appropriate libsystemd0 of libelogind0 library and forwards the calls
> to it?
 
> I don't know if the dynamic linker could be coerced into doing the
> selection automagically, in a way similar to how the hwcap stuff can be
> used to pickup versions of libraries optimised for different classes of
> processor. hwcap is provided by the kernel so I think can't be used
> directly, but maybe there is a parallel mechanism somewhere?

I think Adam Borowski suggested somthing similar a while ago as an option, but I
am not aware of anything more than an idea.

I also experimented with LD_PRELOAD a while ago. But it felt very hackish.

Mark



Bug#941069: /usr/bin/mate-screenshot: mate-screenshot should have option to not show Save dialog

2019-09-24 Thread Witold Baryluk
Package: mate-utils
Version: 1.22.1-1
Severity: normal
File: /usr/bin/mate-screenshot

I think when using screenshot by pressing PrtSc key, or Alt+PrtSc, as well when
using mate-screenshot from command line, there should be an option to bypass the
Save dialog, and automatically write the file in last selected directory and 
with
last selected format. If there is a name clash (i.e. the file already exists, 
due
to print screen pressed multiple times), just append an extra prefix with
microseconds or something).

When starting mate-screenshot from the Menu -> Applications -> Accessories ->
Take Screenshot, the Save dialog could be left, as it as is, as usually one 
might
need to Cancel / retake the screenshot if the options were not quite right.

Similarly the option to include a mouse cursos or not, should be remembered when
using mate-screenshot from the menu, and respected when using PrtSc.



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

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

Versions of packages mate-utils depends on:
ii  libatk1.0-0   2.34.0-1
ii  libc6 2.29-1
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libcanberra-gtk3-00.30-7
ii  libcanberra0  0.30-7
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.60.6-2
ii  libgtk-3-03.24.11-1
ii  libgtop-2.0-112.38.0-4.1
ii  libice6   2:1.0.9-2
ii  libmate-panel-applet-4-1  1.22.1-2
ii  libmatedict6  1.22.1-1
ii  libpango-1.0-01.42.4-7
ii  libpangocairo-1.0-0   1.42.4-7
ii  libsm62:1.2.3-1
ii  libx11-6  2:1.6.7-1
ii  libxext6  2:1.3.3-1+b2
ii  mate-desktop-common   1.22.1-1
ii  mate-utils-common 1.22.1-1
ii  zlib1g1:1.2.11.dfsg-1+b1

mate-utils recommends no packages.

mate-utils suggests no packages.

-- no debconf information



Bug#941071: linux-image-4.19.0-6-amd64: dmesg report error:acpi MSFT0101:00: platform device creation failed: -16

2019-09-24 Thread Shengwen Xiao
Package: src:linux
Version: 4.19.67-2
Severity: wishlist

Dear Maintainer,

   My notebook dmesg has the following error info:

[0.620736] platform MSFT0101:00: failed to claim resource 1: [mem 
0xfed4-0xfed40fff]
[0.620849] acpi MSFT0101:00: platform device creation failed: -16

Is this a bug of the kernel ?

-- Package-specific info:
** Version:
Linux version 4.19.0-6-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2 (2019-08-28)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-6-amd64 
root=UUID=78948e64-af17-4e4e-92e2-ebabdc9e6ddc ro quiet

** Not tainted

** Kernel log:
[0.00] microcode: microcode updated early to revision 0xcc, date = 
2019-04-01
[0.00] Linux version 4.19.0-6-amd64 (debian-ker...@lists.debian.org) 
(gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2 (2019-08-28)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-6-amd64 
root=UUID=78948e64-af17-4e4e-92e2-ebabdc9e6ddc ro quiet
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: xstate_offset[3]:  832, xstate_sizes[3]:   64
[0.00] x86/fpu: xstate_offset[4]:  896, xstate_sizes[4]:   64
[0.00] x86/fpu: Enabled xstate features 0x1f, context size is 960 
bytes, using 'compacted' format.
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009e7ff] usable
[0.00] BIOS-e820: [mem 0x0009e800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x7569dfff] usable
[0.00] BIOS-e820: [mem 0x7569e000-0x7569efff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7569f000-0x756c8fff] reserved
[0.00] BIOS-e820: [mem 0x756c9000-0x75778fff] usable
[0.00] BIOS-e820: [mem 0x75779000-0x76078fff] reserved
[0.00] BIOS-e820: [mem 0x76079000-0x8c28dfff] usable
[0.00] BIOS-e820: [mem 0x8c28e000-0x8cc7dfff] reserved
[0.00] BIOS-e820: [mem 0x8cc7e000-0x8ce7dfff] ACPI NVS
[0.00] BIOS-e820: [mem 0x8ce7e000-0x8cefdfff] ACPI data
[0.00] BIOS-e820: [mem 0x8cefe000-0x8cefefff] usable
[0.00] BIOS-e820: [mem 0x8ceff000-0x8fff] reserved
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfd00-0xfe7f] reserved
[0.00] BIOS-e820: [mem 0xfeb0-0xfeb03fff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved
[0.00] BIOS-e820: [mem 0xfed1-0xfed19fff] reserved
[0.00] BIOS-e820: [mem 0xfed84000-0xfed84fff] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xffa0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00016eff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.8 present.
[0.00] DMI: Timi TM1612/TM1612, BIOS A05 10/20/2016
[0.00] tsc: Detected 1500.000 MHz processor
[0.004689] tsc: Detected 1512.000 MHz TSC
[0.004689] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.004695] e820: remove [mem 0x000a-0x000f] usable
[0.004714] last_pfn = 0x16f000 max_arch_pfn = 0x4
[0.004722] MTRR default type: uncachable
[0.004724] MTRR fixed ranges enabled:
[0.004727]   0-9 write-back
[0.004728]   A-B uncachable
[0.004730]   C-F write-protect
[0.004732] MTRR variable ranges enabled:
[0.004735]   0 base 00 mask 7E write-back
[0.004738]   1 base 008CEFF000 mask 7FF000 uncachable
[0.004740]   2 base 008CF0 mask 70 uncachable
[0.004741]   3 base 008D00 mask 7FFF00 uncachable
[0.004743]   4 base 008E00 mask 7FFE00 uncachable
[0.004745]   5 base 009000 mask 7FF000 uncachable
[0.004746]   6 base 00A000 mask 7FE000 uncachable
[0.004748]   7 base 00C000 mask 7FC000 uncachable
[0.004749]   8 disabled
[0.004750]   9 disabled
[0.007060] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.007319] e820: update

Bug#941072: kivy: please make the build reproducible

2019-09-24 Thread Chris Lamb
Source: kivy
Version: 1.10.1-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

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

This is because it generated a version.py file that contains the current
build date. A patch is attached that uses SOURCE_DATE_EPOCH [1].

 [0] https://reproducible-builds.org/
 [1] https://reproducible-builds.org/specs/source-date-epoch/


Regards,

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


Bug#753423: 15 av dina inkommande meddelanden har avbrutits

2019-09-24 Thread Davor Pašalić
MICROSOFT MEDDELANDE MEMO

15 av dina inkommande meddelanden har stängts av eftersom ditt e-postkonto 
maste verifieras nu. Kontrollera nu 
för att släppa dina meddelanden

Microsoft Verification Team


Microsoft Webmail. Inc. (c) 2019

?

?



Bug#941073: /usr/bin/mate-screenshot: Focused window temporarily looses focuse when doing screenshot using PrtSc in MATE

2019-09-24 Thread Witold Baryluk
Package: mate-utils
Version: 1.22.1-1
Severity: normal
File: /usr/bin/mate-screenshot

When taking a screenshot using a PrtSc, the current window temporarily looses
focus (and I see it on the screenshot, but also in the window, as a brief
flicker). This doesn't happen when using the "Take screenshot" tool manually and
taking full screen screenshot, even with 0 delay.

Additionally the cursor is also incorrect. It turns into generic mouse pointer,
even if the mouse cursor was different (i.e. text selection I-beam thingy). For
example in Terminator, the I-beam text selection cursor shows all the time in
most of the sub-windows, even if they are not active, or terminator is not
focused, but still visible on screen and cursor is over it.

But when taking a screenshot, it always is gone.

See attached screenshots for a detail.


Cheers,
Witold




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

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

Versions of packages mate-utils depends on:
ii  libatk1.0-0   2.34.0-1
ii  libc6 2.29-1
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libcanberra-gtk3-00.30-7
ii  libcanberra0  0.30-7
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.60.6-2
ii  libgtk-3-03.24.11-1
ii  libgtop-2.0-112.38.0-4.1
ii  libice6   2:1.0.9-2
ii  libmate-panel-applet-4-1  1.22.1-2
ii  libmatedict6  1.22.1-1
ii  libpango-1.0-01.42.4-7
ii  libpangocairo-1.0-0   1.42.4-7
ii  libsm62:1.2.3-1
ii  libx11-6  2:1.6.7-1
ii  libxext6  2:1.3.3-1+b2
ii  mate-desktop-common   1.22.1-1
ii  mate-utils-common 1.22.1-1
ii  zlib1g1:1.2.11.dfsg-1+b1

mate-utils recommends no packages.

mate-utils suggests no packages.

-- no debconf information


Bug#941074: ghostscript: ps2pdf SAFER and transparency interference

2019-09-24 Thread Markus Demleitner
Package: ghostscript
Version: 9.27~dfsg-2+deb10u2
Severity: minor

ps2pdf14 as delivered in buster will only produce PDF transparency when
run with -dNOSAFER.  This deviates from previous releases (I'm quite
sure about jessie), when transparency was produced without further
configuration.  Although I *might* see some relationship to accepting
pdfmarks, the connection between SAFER and transparent colours frankly
strikes me as just a little non-intuitive (but that may be because I
don't know what's going on when producing transparency in PDFs).

Because of this, I'd suggest that if turning off PDF transparency
without -dNOSAFER is intentional, that should be documented in the NEWS,
even more so as I couldn't make out that fact in the upstream Use.htm
that the current 9.28~~rc1~dfsg-1 NEWS item refers to.  Perhaps that
particular item could be amended with saying something like "Note that
that has some rather unexpected consequences (e.g., PDF transparency is
now lost without -dNOSAFER)."

Here's my minimal working example:

With the LaTeX document

\documentclass{article}
\usepackage{pstricks}
\begin{document}

\psframebox*[linecolor=white,fillcolor=red,fillstyle=solid,
opacity=0.85,framesep=4mm]{abc}
\vskip -9mm
\psframebox*[fillcolor=white, opacity=0.5,strokeopacity=0.5,
fillstyle=solid,framesep=4mm,linewidth=3pt,linecolor=black]{abc}

\end{document}

in a.tex, run

latex a;dvips a;ps2pdf a.ps

and the second white box obscures most of the red box in the background
(i.e., pstricks opacity is ignored).  Run

latex a;dvips a;ps2pdf -dNOSAFER a.ps

and the two boxes blend as expected.


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

Kernel: Linux 5.1.9 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_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/bash
Init: sysvinit (via /sbin/init)

Versions of packages ghostscript depends on:
ii  libc6   2.28-10
ii  libgs9  9.27~dfsg-2+deb10u2

Versions of packages ghostscript recommends:
ii  gsfonts  1:8.11+urwcyr1.0.7~pre44-4.4

Versions of packages ghostscript suggests:
ii  ghostscript-x  9.27~dfsg-2+deb10u2

-- no debconf information



Bug#941075: monit: no systemctl file for monit

2019-09-24 Thread Han Boetes
Package: monit
Version: 1:5.26.0-1~bpo10+1
Severity: important

The current monit package does not include a systemctl file, often resulting in
monit not running. If I'd check the status with systemctl the result was:
active(exited) see also: https://unix.stackexchange.com/questions/241970/what-
does-status-active-exited-mean-for-a-systemd-service

Now for example puppet can't check it's not running because systemctl says it's
running when it isn't.

Easy fix: add a systemd file and remove the /etc/init.d/monit file

Here is an example which I installed with puppet, fixing this problem for me.

[Unit]
Description=Pro-active monitoring utility for unix systems
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/monit -I
ExecStop=/usr/bin/monit quit
ExecReload=/usr/bin/monit reload

[Install]
WantedBy=multi-user.target



-- Package-specific info:

Monit config file /etc/monit/monitrc is *NOT* readable by reportbug.
Please, consider to rerun reportbug as root and *carefully* examine
reportbug's output (e.g., monitrc content), before sending it out.

Contents of /etc/monit/ directory:
/etc/monit:
total 32
drwxr-xr-x 2 root root17 Aug  9 15:04 conf-available
drwxr-xr-x 2 root root 2 Jan 11  2017 conf-enabled
drwxr-xr-x 2 root root 2 Jan 11  2017 conf.d
drwx-- 2 root root 3 Sep  9 09:29 monit.d
-rw--- 1 root root   765 Aug 28 12:00 monitrc
-rw--- 1 root root 13111 Jul 13 07:21 monitrc.dpkg-dist
drwxr-xr-x 2 root root 5 Aug  9 15:04 templates

/etc/monit/conf-available:
total 68
-rw-r--r-- 1 root root  481 Jan 11  2017 acpid
-rw-r--r-- 1 root root  640 Jan 11  2017 apache2
-rw-r--r-- 1 root root  455 Jan 11  2017 at
-rw-r--r-- 1 root root  691 Jan 11  2017 cron
-rw-r--r-- 1 root root  602 Jan 11  2017 mdadm
-rw-r--r-- 1 root root  669 Jan 11  2017 memcached
-rw-r--r-- 1 root root  703 Jan 11  2017 mysql
-rw-r--r-- 1 root root  521 Jan 11  2017 nginx
-rw-r--r-- 1 root root  471 Jan 11  2017 openntpd
-rw-r--r-- 1 root root  831 Jul 13 07:21 openssh-server
-rw-r--r-- 1 root root  683 Jan 11  2017 pdns-recursor
-rw-r--r-- 1 root root 1426 Jul 13 07:21 postfix
-rw-r--r-- 1 root root  869 Jan 11  2017 rsyslog
-rw-r--r-- 1 root root  501 Jan 11  2017 smartmontools
-rw-r--r-- 1 root root  306 Jan 11  2017 snmpd

/etc/monit/conf-enabled:
total 0

/etc/monit/conf.d:
total 0
/bin/ls: cannot open directory '/etc/monit/monit.d': Permission denied

/etc/monit/templates:
total 14
-rw-r--r-- 1 root root 164 Jan 11  2017 rootbin
-rw-r--r-- 1 root root 160 Jan 11  2017 rootrc
-rw-r--r-- 1 root root 164 Jan 11  2017 rootstrict


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

Kernel: Linux 5.0.21-2-pve (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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

Versions of packages monit depends on:
ii  libc6  2.28-10
ii  libpam0g   1.3.1-5
ii  libssl1.1  1.1.1c-1
ii  lsb-base   10.2019051400
ii  zlib1g 1:1.2.11.dfsg-1

monit recommends no packages.

Versions of packages monit suggests:
ii  postfix [mail-transport-agent]  3.4.5-1
pn  sysvinit-core   

-- Configuration Files:
/etc/monit/monitrc [Errno 13] Permission denied: '/etc/monit/monitrc'

-- no debconf information



Bug#935578: (no subject)

2019-09-24 Thread Paride Legovini
control: forcemerge 935578 934850

Merging the two bugs, as what we need is a full rename of the 'bat'
binary file and of its manpage, as #935578 bug states.

Paride



Bug#934850: (no subject)

2019-09-24 Thread Paride Legovini
We settled with 'batcat', see

https://github.com/sharkdp/bat/issues/656

Ongoing discussion on the upstream tooling make the rename easier and
keep the manpage consistent:

https://github.com/sharkdp/bat/issues/659

Paride



Bug#935578: (no subject)

2019-09-24 Thread Paride Legovini
We settled with 'batcat', see

https://github.com/sharkdp/bat/issues/656

Ongoing discussion on the upstream tooling make the rename easier and
keep the manpage consistent:

https://github.com/sharkdp/bat/issues/659

Paride



Bug#941077: xserver-xorg-video-ast: sourceless firmware in AST_DP501_firmware in src/ast_dp501fw.h

2019-09-24 Thread Paul Wise
Source: xserver-xorg-video-ast
Version: 1.1.5-1.1
Severity: serious
Justification: DFSG item 2

The AST_DP501_firmware array in src/ast_dp501fw.h contains a sourceless
firmware blob. I think this means that xserver-xorg-video-ast needs to
move to non-free, or it could use ast_dp501_fw.bin from the firmware
directory like the Linux kernel does and then move to contrib.

xserver-xorg-video-ast-1.1.5/ $ grep -C1 0x src/ast_dp501fw.h | head -n3
UCHAR AST_DP501_firmware[] = {\
0x00,0x00,0x00,0x00,0x00,0x00,0x04,0x00,\
0x00,0x00,0x04,0x56,0x00,0x00,0x04,0x56,\

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#941076: debsign crashes gnome on wayland session

2019-09-24 Thread Pirate Praveen

Package: gnome-session,pinentry-gnome3
severity: critical

After updating gnome to 2.34 I'm not able to use debsign, it crashes 
the desktop. I'm logged out after screen is blacked out. Tried updating 
task-gnome-desktop and *wayland* packages but no effect. GNOME on Xorg 
works, it still shows a black screen when launching debsign but I don't 
lose the session.


It is possibly a bug in pinentry-gnome3 or gnome-keyring. I can use 
debsign with curses pinentry screen if I switch to a virtual terminal 
(control+alt+f2).




Bug#941075: monit: no systemctl file for monit

2019-09-24 Thread Sergey B Kirpichev
tags 941075 +moreinfo
thanks

On Tue, Sep 24, 2019 at 11:38:52AM +0200, Han Boetes wrote:
> The current monit package does not include a systemctl file, often resulting 
> in
> monit not running. If I'd check the status with systemctl the result was:
> active(exited) see also: https://unix.stackexchange.com/questions/241970/what-
> does-status-active-exited-mean-for-a-systemd-service

I don't understand.  What conditions lead to the state "monit not
running"?

Perhaps, you have system with systemd, but manage monit using /etc/init.d/monit
script directly.  You shouldn't do it, this makes systemd crazy, but
this is not a monit's problem.

Use systemctl to start/stop/reload monit on systemd-enabled
hosts - and everything should work and systemd will be happy.  Please
let me know if you still have problems after using this suggestion.

> Easy fix: add a systemd file and remove the /etc/init.d/monit file

Are you volunteered to debug and fix any problems with systemd-enabled
setups and this unit file?  Please look to the README.Debian: monit can
work with systemd, but it would be better, if you avoid this use case.



Bug#941076: debsign crashes gnome on wayland session

2019-09-24 Thread Simon McVittie
Control: retitle -1 [GNOME 3.34] debsign crashes gnome on wayland session
Control: tags -1 + experimental moreinfo

On Tue, 24 Sep 2019 at 15:33:05 +0530, Pirate Praveen wrote:
> After updating gnome to 2.34

I'm fairly sure you mean 3.34. There was no GNOME 2.34 release: GNOME
2.32 was in 2010, and was followed by 3.0.

Key GNOME 3.34 components, including gnome-session and gnome-shell, are
currently only in experimental. You're welcome to try it, but please
make sure that bug reports are complete, precise and actionable.

> I'm not able to use debsign, it crashes the
> desktop. I'm logged out after screen is blacked out.

Please send details of the package versions involved, and whatever
backtraces and system log entries are available.

For what it's worth, I have not experienced similar crashes when using
debsign and pinentry-gnome3 in conjunction with a smart card (Nitrokey
Pro) in either a GNOME 3.30 or 3.34 environment. I assume most of the
other people uploading GNOME 3.34 for the GNOME team are also using
debsign and pinentry-gnome3 in that environment.

smcv



Bug#940930: devscripts: add new script for self-service give-backs

2019-09-24 Thread Paul Wise
On Tue, 2019-09-24 at 08:13 +0200, Mattia Rizzolo wrote:

> *Using* the certs still works everywhere and I suspect it will for a
> very long time, given how many institutions use them.
> What is being removed is the part producing the certs.

Given how they intentionally make support for them worse over time and
don't improve the terrible UI situation, it seems very likely they are
going to work towards removing them from browsers completely.

I'm tempted to file an issue proposing a removal timeline myself just
so that there is a decision about whether to support or remove them.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#753423: 15 av dina inkommande meddelanden har avbrutits

2019-09-24 Thread Davor Pašalić
MICROSOFT MEDDELANDE MEMO

15 av dina inkommande meddelanden har stängts av eftersom ditt e-postkonto 
maste verifieras nu. Kontrollera nu 
för att släppa dina meddelanden

Microsoft Verification Team


Microsoft Webmail. Inc. (c) 2019


?



Bug#941074: ghostscript: ps2pdf SAFER and transparency interference

2019-09-24 Thread Jonas Smedegaard
Hi Markus,

Quoting Markus Demleitner (2019-09-24 11:36:09)
> ps2pdf14 as delivered in buster will only produce PDF transparency 
> when run with -dNOSAFER.  This deviates from previous releases (I'm 
> quite sure about jessie), when transparency was produced without 
> further configuration.  Although I *might* see some relationship to 
> accepting pdfmarks, the connection between SAFER and transparent 
> colours frankly strikes me as just a little non-intuitive (but that 
> may be because I don't know what's going on when producing 
> transparency in PDFs).
> 
> Because of this, I'd suggest that if turning off PDF transparency 
> without -dNOSAFER is intentional, that should be documented in the 
> NEWS, even more so as I couldn't make out that fact in the upstream 
> Use.htm that the current 9.28~~rc1~dfsg-1 NEWS item refers to.  
> Perhaps that particular item could be amended with saying something 
> like "Note that that has some rather unexpected consequences (e.g., 
> PDF transparency is now lost without -dNOSAFER)."
>
> Here's my minimal working example:
> 
> With the LaTeX document
> 
> \documentclass{article}
> \usepackage{pstricks}
> \begin{document}
> 
> \psframebox*[linecolor=white,fillcolor=red,fillstyle=solid,
> opacity=0.85,framesep=4mm]{abc}
> \vskip -9mm
> \psframebox*[fillcolor=white, opacity=0.5,strokeopacity=0.5,
> fillstyle=solid,framesep=4mm,linewidth=3pt,linecolor=black]{abc}
> 
> \end{document}
> 
> in a.tex, run
> 
> latex a;dvips a;ps2pdf a.ps
> 
> and the second white box obscures most of the red box in the background
> (i.e., pstricks opacity is ignored).  Run
> 
> latex a;dvips a;ps2pdf -dNOSAFER a.ps
> 
> and the two boxes blend as expected.

Thanks for reporting this issue.

Above minimal code is processed by LaTeX, not Ghostscript directly.

Please provide a (minimal, preferrably) example of date and commands 
directly involving Ghostscript.


 - 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#765971: Change #765971 from RFP to ITP

2019-09-24 Thread Svante Signell
retitle 765971 ITP: eudev -- udev fork, independent of systemd trunk.
owner 765971 !
thanks

This package is already packaged by Devuan, and as so the Debian version will
get an +debian1 extension. Current Devuan version is 3.2.7-6 from Feb 9, 2019.
Latest upstream version is 3.2.8 from May 20, 2019.

In order not to conflict with systemd-udev, as a start we will aim for
experimental and then package it for sid. Later on we will have to decide on how
it can coexist with udev.

Thanks!



Bug#941078: transition: postgresql-12

2019-09-24 Thread Christoph Berg
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi,

PostgreSQL 12 rc1 is due to be released this week. Ben patch attached.

As usual the transition will be done using sourceful uploads, so
little release team interaction is expected to be needed.

Christoph
>From dc20c59f948622dc761f06aa0d5da7d6813c3811 Mon Sep 17 00:00:00 2001
From: Christoph Berg 
Date: Tue, 24 Sep 2019 12:44:26 +0200
Subject: [PATCH] Add postgresql-12 tracker

---
 config/ongoing/postgresql-12.ben | 5 +
 1 file changed, 5 insertions(+)
 create mode 100644 config/ongoing/postgresql-12.ben

diff --git a/config/ongoing/postgresql-12.ben b/config/ongoing/postgresql-12.ben
new file mode 100644
index 000..4ac60b1
--- /dev/null
+++ b/config/ongoing/postgresql-12.ben
@@ -0,0 +1,5 @@
+title = "postgresql-12";
+is_affected = .depends ~ /postgresql.*-1[012].*/ | .build-depends ~ /postgresql.*-1[012].*/ | .recommends ~ /postgresql.*-1[012].*/ | .suggests ~ /postgresql.*-1[012].*/;
+is_good = .depends ~ /postgresql.*-12.*/ | .build-depends ~ /postgresql.*-12.*/ | .recommends ~ /postgresql.*-12.*/ | .suggests ~ /postgresql.*-12.*/;
+is_bad =  .depends ~ /postgresql.*-1[01].*/  | .build-depends ~ /postgresql.*-1[01].*/  | .recommends ~ /postgresql.*-1[01].*/  | .suggests ~ /postgresql.*-1[01].*/;
+export = false;
-- 
2.23.0



Bug#940724: Fixed upstream

2019-09-24 Thread spam-debian
There is a 0.7.1 release upstream which should fix this crash.

Bug#886590: Please add python3-z3 package

2019-09-24 Thread Roman Lebedev
Bump. Any chance this could be prioritized?
Lack of python3-z3 package prevents me from porting
some other python2 software to python3.

Roman.



Bug#940967: libsecp256k1-0: ECDH support not built

2019-09-24 Thread Jonas Smedegaard
Quoting Janus Troelsen (2019-09-22 20:29:45)
> libsecp256k1 can be built with "experimental" ECDH support. This adds 
> an additional symbol to the shared object. I have used this ECDH 
> support for years (built myself), and have had no issues with it. It 
> is only experimental because the API might change. Consumers of the 
> library should know this. Note that libsecp256k1 has never had a 
> stable release, so even functions not marked "experimental" are 
> vulnerable to the same kind of API breakage.
> 
> I request building with ECDH support.

Thanks for the suggestion - and the detailed background information.

This sounds sensible to try explore - in experimental at first, to 
ensure it compiles succesfully on all supported architectures.

 - 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#941046: bbdb: byte-compilation and startup broken with unversioned emacs

2019-09-24 Thread David Bremner


Control: severity -1 important
Control: tag -1 help

David Bremner  writes:

>
> debian/bbdb.emacsen-install was never updated for unversioned
> emacs. This means the package fails to byte compile, which in turn
> causes the startup file to bail out.

I have work in progress [1] that fixes the
byte-compilation. Unfortunately that seems to reveal another bug with
the maintainer scripts that bbdb-autoload.elc is not being generated.
That feels like a different bug to me, but I'd need more testing to be
sure.

> I'm not 100% sure about the severity. This bug does mean that unless
> people write their own startup code (manipulating load-paths and so
> on), bbdb is completely useless.

I'm downgrading the severity of this bug, as it only affects users
without emacs25 installed, and I suspect that's a minority.


[1]:  https://salsa.debian.org/emacsen-team/bbdb/tree/buster



Bug#941079: git-checkout: regression on initial checkout

2019-09-24 Thread Thomas Faivre
Package: git
Version: 1:2.20.1-2
Severity: normal

Dear Maintainer,

There is a regression in the behavior of git checkout on a new,
uncecked-out git repository:

$ git clone --no-checkout  /tmp/repo
$ git -C /tmp/repo checkout -b  
$ ls /tmp/repo


Bug was fixed in v2.21.0 of git. Patch is available [1].

I known v2.23.x is available in experimental/testing/unstable branch,
but it would be nice to have it in stable too.

Thank you!

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

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

Versions of packages git depends on:
ii  git-man  1:2.20.1-2
ii  libc62.28-10
ii  libcurl3-gnutls  7.64.0-4
ii  liberror-perl0.17027-2
ii  libexpat12.2.6-2+deb10u1
ii  libpcre2-8-0 10.32-5
ii  perl 5.28.1-6
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages git recommends:
ii  ca-certificates  20190110
ii  less 487-0.1+b1
ii  openssh-client [ssh-client]  1:7.9p1-10
ii  patch2.7.6-3+deb10u1

Versions of packages git suggests:
ii  gettext-base  0.19.8.1-9
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
pn  git-el
pn  git-email 
pn  git-gui   
pn  git-mediawiki 
pn  git-svn   
pn  gitk  
ii  gitweb1:2.20.1-2

-- no debconf information



Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

2019-09-24 Thread Ian Campbell
On Tue, 2019-09-24 at 10:05 +0100, Mark Hindley wrote:
> Ian,
> 
> Thanks for this.
> 
> On Tue, Sep 24, 2019 at 07:28:29AM +0800, Ian Campbell wrote:
> > On Fri, 2019-09-20 at 10:16 +0100, Mark Hindley wrote:
> > Would it be any help at all of the "dbus client-ish" bits and the
> > "direct API-ish" bits of the two libraries were split up into two
> > separate libraries? i.e. would that allow the c/r/p replacement of
> one
> > of the two libraries (AIUI the API one is the more problematic) to
> be
> > pushed further up the dependency stack?
> 
> I think that is what we already have (if I have understood you correctly). The
> dbus components are in systemd/elogind and the sd-*(3) APIs are in
> libsystemd0/libelogind0. Or have I misunderstood?

Probably I have, I thought the dbus client side stuff was in
libsystemd0/libelogind0 too.

> > Has anyone investigated late dynamic binding using a stub library which
> > merely determines which init is running and then dlopens the
> > appropriate libsystemd0 of libelogind0 library and forwards the calls
> > to it?
>  
> > I don't know if the dynamic linker could be coerced into doing the
> > selection automagically, in a way similar to how the hwcap stuff can be
> > used to pickup versions of libraries optimised for different classes of
> > processor. hwcap is provided by the kernel so I think can't be used
> > directly, but maybe there is a parallel mechanism somewhere?
> 
> I think Adam Borowski suggested somthing similar a while ago as an option, 
> but I
> am not aware of anything more than an idea.

Might be worth a PoC?

> I also experimented with LD_PRELOAD a while ago. But it felt very hackish.

Yeah. that's probably not the way to go.

Ian.



Bug#941079:

2019-09-24 Thread Thomas FAIVRE
Always better with the link:
https://github.com/git/git/commit/8424bfd45b291a56594f0289dc6af22e900a1d88
--
Thomas



Bug#934627: transition: libmatio

2019-09-24 Thread Sébastien Villemot
Le lundi 23 septembre 2019 à 22:13 +0200, Paul Gevers a écrit :
> Control: tags -1 confirmed
> 
> On 12-08-2019 17:24, Sébastien Villemot wrote:
> > Please schedule a transition for libmatio. The new version stands in
> > experimental. I expect the transition to be smooth (only two symbols
> > deprecated, and those are not used by reverse dependencies according to
> > sources.debian.org).
> 
> Please go ahead.

Thanks. It is now uploaded and built on all release archs.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org



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


Bug#881901: #971: "management tunnel " ignores port

2019-09-24 Thread OpenVPN Trac instance
#971: "management tunnel " ignores port
-+-
 Reporter:  berni|   Owner:  (none)
 Type:  Bug / Defect |  Status:  new
 Priority:  minor|   Milestone:
Component:  Management   | Version:  OpenVPN 2.4.4
 Severity:  Not set (select this |  (Community Ed)
  one, unless your'e a OpenVPN   |  Resolution:
  developer) |
 Keywords:   |
-+-

Comment (by thhart):

 I can confirm the patch fixes the problem for my installation.

 I know this is a very rare used feature, however we use it for monitoring
 connected clients heavily. I know there might be other possibilities to
 achieve this but I think it is extremely hard to drop this feature while
 it is "only" necessary to have this simple patch in place.

-- 
Ticket URL: 
OpenVPN Community 
OpenVPN is a layer 2/3 SSL VPN


Bug#941048: fwupd: provide option to never send report

2019-09-24 Thread Mario.Limonciello
Oh it looks like that just stops it from actually going out.  To prevent the 
prompt you'll need to launch fwupdmgr with --no-unreported-check.

https://github.com/fwupd/fwupd/blob/ce94d163f8d7bef4748a75def1ace0326083eea5/src/fu-util.c#L2092

> -Original Message-
> From: brian m. carlson 
> Sent: Monday, September 23, 2019 9:06 PM
> To: Limonciello, Mario
> Cc: 941...@bugs.debian.org
> Subject: Re: Bug#941048: fwupd: provide option to never send report
> 
> On 2019-09-24 at 01:00:01, mario.limoncie...@dell.com wrote:
> > To accomplish this, I believe you can just comment out ReportURI= in
> > the LVFS remote and restart the daemon. (IE
> > /etc/fwupd/remotes.d/lvfs.conf)
> 
> That doesn't seem to be effective.  Running "fwupdmgr get-updates"
> still prompts, even after restarting the daemon.
> --
> brian m. carlson: Houston, Texas, US
> OpenPGP: https://keybase.io/bk2204


Bug#931551: transition: llvm-defaults to 8

2019-09-24 Thread Sylvestre Ledru



Le 23/09/2019 à 22:04, Paul Gevers a écrit :

Hi Shengjing, Sylvestre,

On 15-09-2019 09:52, Shengjing Zhu wrote:

Now that we release buster, I would like to move llvm-defaults to 
llvm-toolchain-8.

[...]


Affected: .depends ~ /(clang|llvm)1?-?[345678]/
Good: .depends ~ /(clang|llvm)1?-?[8]/
Bad: .depends ~ /(clang|llvm)1?-?[34567]/


I recently package ccls, which depends on libllvm[1].
I'm curious why this ben file doesn't include libllvm?

So am I, Sylvestre, can you comment please. Is this intentional, or just
missing from the ben file?

Probably missing, sorry :)

S



Bug#939983: error: Unable to read from '/sys/fs/cgroup/unified/machine/cgroup.controllers'

2019-09-24 Thread Thorsten Glaser
Hi,

I’ve had to downgrade in the meantime, since #935734 at least
has a workaround.

FWIW, the GNU Guix people have the same problem, and with a
different path, others:

https://www.redhat.com/archives/libvir-list/2019-July/msg01310.html
https://bugzilla.redhat.com/show_bug.cgi?id=1751120

I have this:

tglase@tglase:~ $ mount | fgrep cgroup
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
cgroup2 on /sys/fs/cgroup/unified type cgroup2 
(rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/elogind type cgroup 
(rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/elogind/elogind-cgroups-agent,name=elogind)

So, s!/machine!! on the path would most likely make it work.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**



Bug#886590: Please add python3-z3 package

2019-09-24 Thread Sylvestre Ledru

Hello


Le 24/09/2019 à 12:51, Roman Lebedev a écrit :

Bump. Any chance this could be prioritized?
Lack of python3-z3 package prevents me from porting
some other python2 software to python3.


Thanks to the work of Fabian Wolff, we have a better version of z3.

I don't know if he is planning to work on this soon but if you write a patch
i would be happy to sponsor it.

thanks
Sylvestre



Bug#886590: Please add python3-z3 package

2019-09-24 Thread Roman Lebedev
On Tue, Sep 24, 2019 at 3:32 PM Sylvestre Ledru  wrote:
>
> Hello
>
>
> Le 24/09/2019 à 12:51, Roman Lebedev a écrit :
> > Bump. Any chance this could be prioritized?
> > Lack of python3-z3 package prevents me from porting
> > some other python2 software to python3.
>
> Thanks to the work of Fabian Wolff, we have a better version of z3.
I'm a little bit out of context here, of *z3* or of z3 packaging?
Also, link?

> I don't know if he is planning to work on this soon but if you write a patch
> i would be happy to sponsor it.
>
> thanks
> Sylvestre
Roman



Bug#941080: package ships two log rotation mechanisms

2019-09-24 Thread Antoine Beaupre
Source: puppetdb
Version: 6.2.0-3
Severity: normal

This package ships two log rotation mechanisms for
/var/log/puppetdb/puppetdb.log:

root@pauli:~# dpkg -L puppetdb | grep log
/etc/puppetdb/logback.xml
/etc/puppetdb/request-logging.xml
/usr/share/doc/puppetdb/changelog.Debian.gz
/var/log
/var/log/puppetdb
/etc/logrotate.d/puppetdb

This creates noise when logrotate comes at night to try rotating the
logs:

/etc/cron.daily/logrotate:
error: destination /var/log/puppetdb/puppetdb-access.log.1 already exists, 
renaming to /var/log/puppetdb/puppetdb-access.log.1-2019030706.backup
error: error setting owner of /var/log/puppetdb/puppetdb-access.log.1 to uid 
119 and gid 125: Operation not permitted
error: destination /var/log/puppetdb/puppetdb.log.1 already exists, renaming to 
/var/log/puppetdb/puppetdb.log.1-2019030706.backup
error: error setting owner of /var/log/puppetdb/puppetdb.log.1 to uid 119 and 
gid 125: Operation not permitted
run-parts: /etc/cron.daily/logrotate exited with return code 1

It also marks the service as "degraded" in systemd, just for good
measure.

A workaround is to not ship a logrotate.d file at all, and it's the
approach DSA has taken to solve the issue so far:

https://salsa.debian.org/dsa-team/mirror/dsa-puppet/commit/e31d91af7a8a5d9b90bc309e38067605c00d7f13

... but I wonder if we would rather not ship `logback.xml`, to follow
POLA (Principle Of Least Astonishment). That config file is:

 1. XML, and therefore not quite human readable
 2. non-standard, as far as basic Linux sysadmin work is concerned (it
might be "standard" in the Java world, but looks like gibberish to
me)

So I would suggest to not let PuppetDB rotate its own logs unless
there's a good reason to do so in the first place.

But in either case, we shouldn't do *both*.

PS: after investigation, I noticed this bug (#881584) was declared
fixed in 4.4.1-3, but that's not really accurate: the bug won't be
present on new installs, but on upgrade, the old config file sticks
around. So you need to somehow remove that config file on upgarde, but
I would still argue against using the logback.xml mechanism and
instead revert to using the logrotate one.

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

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



Bug#941081: O: clipit -- lightweight GTK+ clipboard manager

2019-09-24 Thread Andrej Shadura
Package: wnpp
Severity: normal

I intend to orphan the clipit package. The package was previously
maintained by Dmitry Smirnov, who gave up on it at some point; I
attempted to take it over, but with upstream not taking care of it, and
unable to fix bugs, I switched to diodon[1] myself, so I’m not using
ClipIt anymore, and I cannot take it over upstream, unfortunately; I
have too many other things on my plate at the moment.

Parcellite, from which ClipIt was forked, had had some life breathed
into it temporarily, and I believe the annoying UTF-8 support bug has
been fixed, but otherwise it’s been equally dead upstream for years[2].

Diodon hasn’t seen any upstream development recently either, but at
least it seems to be the least buggy of the three, and it also supports
images, which both ClipIt and Parcellite don’t, so I’m sticking with it
for now.

If you intend to take this package over, please please make sure that you
actually can get it sorted, it is not a trivial job, as I have painfully
learnt myself.

The package description is:
 Clipboard manager with features such as:
  * Save history of your last copied items
  * Search through the history
  * Global hotkeys for most used functions
  * Execute actions with clipboard items
  * Exclude specific items from history
 .
 ClipIt was forked[0] from Parcellite and adds many bugfixes and features to the
 project.

References:
 [0]: https://github.com/CristianHenzel/ClipIt
 [1]: https://packages.qa.debian.org/d/diodon.html
 [2]: https://github.com/rickyrockrat/parcellite/commits/master

-- 
Cheers,
  Andrej


Bug#940710: Fails to load pkcs8_key_parser module

2019-09-24 Thread Felipe Sateler
Control: reopen -1

Hi Andreas,

On Fri, 20 Sep 2019 15:17:28 +0200 Andreas Henriksson 
wrote:
> Hello Yuri D'Elia,
>
> Thanks for your bug report.
>
> On Thu, Sep 19, 2019 at 12:39:32PM +0200, Yuri D'Elia wrote:
> > Package: iwd
> > Version: 0.21-1
> > Severity: normal
> >
> > iwd includes /usr/lib/modules-load.d/pkcs8.conf to load pkcs8_key_parser
> > when available. This however causes an error message during startup in
> > my case, which I'd like to silence.
>
> Ok.
>

This causes failed boots on debian by default since the debian kernels
don't enable that module:

% grep CONFIG_PKCS8_PRIVATE_KEY_PARSER /boot/config-*
/boot/config-5.2.0-2-amd64:# CONFIG_PKCS8_PRIVATE_KEY_PARSER is not set
/boot/config-5.3.0-rc5-amd64:# CONFIG_PKCS8_PRIVATE_KEY_PARSER is not set

Since I have no idea what does pkcs8_key_parser do, I don't know if it
would be best to have linux enable that option or to have iwd not ship this
file.


Saludos


Bug#934350: Debug make.log

2019-09-24 Thread Jan Huijsmans
Hi,

I found this bug as well on my server, after findingloads of ssh
probes in the iptables logging that should be dropped by the geoip
module. The issue is with the 5.2.0 kernel. I started with
xtables-addons 2.12 and got an error on line 472 of the same 
C file (.._timer was not found, suggested that this should be
..._timers). Alas I forgot to save that log.

Fall-back for me was to install a 4.19 kernel (4.19.0-6 from sid
repo, few minutes ago) The 4.19.0-6 kernel is now running nicely
with the 3.2-1 xtables-addons active.

Log of the 3.2-1 build:


DKMS make.log for xtables-addons-3.2 for kernel 5.2.0-2-amd64 (x86_64)
Tue 24 Sep 14:58:27 CEST 2019
make: Entering directory '/usr/src/linux-headers-5.2.0-2-amd64'
make -C /usr/src/linux-headers-5.2.0-2-amd64 -f 
/usr/src/linux-headers-5.2.0-2-common/Makefile modules
test -e include/generated/autoconf.h -a -e include/config/auto.conf || (
\
echo >&2;   \
echo >&2 "  ERROR: Kernel configuration is invalid.";   \
echo >&2 " include/generated/autoconf.h or include/config/auto.conf are 
missing.";\
echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix 
it.";  \
echo >&2 ;  \
/bin/false)
mkdir -p /var/lib/dkms/xtables-addons/3.2/build/extensions/.tmp_versions ; rm 
-f /var/lib/dkms/xtables-addons/3.2/build/extensions/.tmp_versions/*
make -f /usr/src/linux-headers-5.2.0-2-common/scripts/Makefile.build 
obj=/var/lib/dkms/xtables-addons/3.2/build/extensions
make -f /usr/src/linux-headers-5.2.0-2-common/scripts/Makefile.build 
obj=/var/lib/dkms/xtables-addons/3.2/build/extensions/ACCOUNT need-builtin=
   gcc-8 
-Wp,-MD,/var/lib/dkms/xtables-addons/3.2/build/extensions/ACCOUNT/.xt_ACCOUNT.o.d
  -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/8/include 
-I/usr/src/linux-headers-5.2.0-2-common/arch/x86/include 
-I./arch/x86/include/generated -I/usr/src/linux-headers-5.2.0-2-common/include 
-I./include -I/usr/src/linux-headers-5.2.0-2-common/arch/x86/include/uapi 
-I./arch/x86/include/generated/uapi 
-I/usr/src/linux-headers-5.2.0-2-common/include/uapi -I./include/generated/uapi 
-include /usr/src/linux-headers-5.2.0-2-common/include/linux/kconfig.h -include 
/usr/src/linux-headers-5.2.0-2-common/include/linux/compiler_types.h 
-D__KERNEL__ -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs 
-fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE 
-Werror=implicit-function-declaration -Werror=implicit-int -Wno-format-security 
-std=gnu89 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -falign-jumps=1 
-falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 
-mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel 
-DCONFIG_X86_X32_ABI -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 
-DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_AVX=1 
-DCONFIG_AS_AVX2=1 -DCONFIG_AS_AVX512=1 -DCONFIG_AS_SHA1_NI=1 
-DCONFIG_AS_SHA256_NI=1 -Wno-sign-compare -fno-asynchronous-unwind-tables 
-mindirect-branch=thunk-extern -mindirect-branch-register -fno-jump-tables 
-fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation 
-Wno-format-overflow -O2 --param=allow-store-data-races=0 
-Wframe-larger-than=2048 -fstack-protector-strong -Wno-unused-but-set-variable 
-Wno-unused-const-variable -fno-var-tracking-assignments -g -pg -mrecord-mcount 
-mfentry -DCC_USING_FENTRY -Wdeclaration-after-statement -Wvla 
-Wno-pointer-sign -Wno-stringop-truncation -fno-strict-overflow 
-fno-merge-all-constants -fmerge-constants -fno-stack-check -fconserve-stack 
-Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init 
-fmacro-prefix-map=/usr/src/linux-headers-5.2.0-2-common/= 
-Wno-packed-not-aligned 
-I/var/lib/dkms/xtables-addons/3.2/build/extensions/ACCOUNT/..  -DMODULE  
-DKBUILD_BASENAME='"xt_ACCOUNT"' -DKBUILD_MODNAME='"xt_ACCOUNT"' -c -o 
/var/lib/dkms/xtables-addons/3.2/build/extensions/ACCOUNT/xt_ACCOUNT.o 
/var/lib/dkms/xtables-addons/3.2/build/extensions/ACCOUNT/xt_ACCOUNT.c
   ./tools/objtool/objtool orc generate  --module --no-fp --retpoline --uaccess 
/var/lib/dkms/xtables-addons/3.2/build/extensions/ACCOUNT/xt_ACCOUNT.o
  if objdump -h 
/var/lib/dkms/xtables-addons/3.2/build/extensions/ACCOUNT/xt_ACCOUNT.o | grep 
-q __ksymtab; then  gcc-8 -E -D__GENKSYMS__ 
-Wp,-MD,/var/lib/dkms/xtables-addons/3.2/build/extensions/ACCOUNT/.xt_ACCOUNT.o.d
  -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/8/include 
-I/usr/src/linux-headers-5.2.0-2-common/arch/x86/include 
-I./arch/x86/include/generated -I/usr/src/linux-headers-5.2.0-2-common/include 
-I./include -I/usr/src/linux-headers-5.2.0-2-common/arch/x86/include/uapi 
-I./arch/x86/include/generated/uapi 
-I/usr/src/linux-headers-5.2.0-2-common/include/uapi -I./include/generated/uapi 
-include /usr/src/linux-headers-5.2.0-2-common/include/linux/kconfig.h -include 
/usr/src/linux-headers-5.2.0-2-common/include/li

Bug#941082: LLVMExports.cmake is broken as compared with LLVM-8

2019-09-24 Thread Roman Lebedev
Package: llvm-9
Version: 1:9~svn366059-1~exp1+0~20190715121055.2623~1.gbp7d3830
Severity: normal
Tags: upstream patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer.

Somewhere during the LLVM-9 dev cycle, some clang static analyzer test
plugins were added upstream - SampleAnalyzerPlugin, etc.
But while they are referenced in the LLVMExports.cmake, they are not
being installed, which results in fatal cmake errors when trying to use
said LLVMExports.cmake:

Halide/build$ CC=clang-8 CXX=clang++-8 cmake  -GNinja ../
- -- The C compiler identification is Clang 8.0.1
- -- The CXX compiler identification is Clang 8.0.1
- -- Check for working C compiler: /usr/bin/clang-8
- -- Check for working C compiler: /usr/bin/clang-8 -- works
- -- Detecting C compiler ABI info
- -- Detecting C compiler ABI info - done
- -- Detecting C compile features
- -- Detecting C compile features - done
- -- Check for working CXX compiler: /usr/bin/clang++-8
- -- Check for working CXX compiler: /usr/bin/clang++-8 -- works
- -- Detecting CXX compiler ABI info
- -- Detecting CXX compiler ABI info - done
- -- Detecting CXX compile features
- -- Detecting CXX compile features - done
CMake Error at /usr/lib/llvm-9/lib/cmake/llvm/LLVMExports.cmake:1293 (message):
  The imported target "SampleAnalyzerPlugin" references the file

 "/usr/lib/llvm-9/lib/SampleAnalyzerPlugin.so"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

 "/usr/lib/llvm-9/lib/cmake/llvm/LLVMExports.cmake"

  but not all the files it references.

Call Stack (most recent call first):
  /usr/lib/llvm-9/cmake/LLVMConfig.cmake:239 (include)
  CMakeLists.txt:24 (find_package)


- -- Configuring incomplete, errors occurred!
See also "/repositories/Halide/build/CMakeFiles/CMakeOutput.log".
See also "/repositories/Halide/build/CMakeFiles/CMakeError.log".



There's upstream bugreport: https://bugs.llvm.org/show_bug.cgi?id=43430
And a potential patch, which is not yet merged yet: 
https://reviews.llvm.org/D67877

It might be good to cherry-pick it (after it's merged upstream?)
even for 9.0.0, and not wait for 9.0.1

Roman.

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

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

Versions of packages llvm-9 depends on:
ii  libc6   2.29-2
ii  libgcc1 1:9.2.1-8
ii  libllvm91:9~svn366059-1~exp1+0~20190715121055.2623~1.gbp7d3830
ii  libpfm4 4.10.1+git14-g815ff28-1
ii  libstdc++6  9.2.1-8
ii  libtinfo6   6.1+20190803-1
ii  llvm-9-runtime  1:9~svn366059-1~exp1+0~20190715121055.2623~1.gbp7d3830
ii  zlib1g  1:1.2.11.dfsg-1+b1

Versions of packages llvm-9 recommends:
ii  llvm-9-dev  1:9~svn366059-1~exp1+0~20190715121055.2623~1.gbp7d3830

Versions of packages llvm-9 suggests:
pn  llvm-9-doc  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEjkF6151RK40WXe2HCDw+u0oWieAFAl2KGw0ACgkQCDw+u0oW
ieDZhhAAqsuE8/N4EHI/ge49yZ09lpTIzECeoHxk/bzLrkWmex4tGllw1jGtgcVi
2umqJgM1wvel+i4OvwIZpJ3VZUgTBHi2oPyMjGx32780VZD/A0wGQGEeNg/xZPTH
okJ2+n2O6rzpacZSx00vUYqw2+N2L0rUMSkePPqpiNo3akX/YfCh31Gc//pPOM0I
aNIjcyV1g0hy1qrnGlfc4cvwsiJjyt/bGwhb5C/hqUGjPxBz7Mbf6yv8rUC+5R+R
uIPcOXfZemyAH0UxpQGNRhC4M3+uPT/8eJKs4jlq95TMwUE0ZElFzHPDuA915ZW/
dCGbppj5OX9rspNQ33wDH1bpcys6CDVXCXiOuvOoknXF0mWwW2Yt52K5IbfueGj+
bqB/n84yTjmaUMf7BHrC7nqyHxrY96klzf5weJ2tCyvjS3foq+tS+xSr6zodveLF
SLYgIjAmgB2WjOafbUV8q3vK7gqsBbr0YwesNHxukMljuYii0dnrt4MAweQ000EH
UZXADLdWezOMZNgIwXuKVdZPYDYwXCf2lN2TccfmMq1on/X4LC0y0c6vj4Bl+jm6
u8iezWiKkkHu9iFzjUJ/QFiPZkN/ddjGnJXjMTuTm+du8YFfSK+ELNtvb1hobmn8
jZVk/MWDGoo+G3ZzVDsMoQY1pDwnFe1ER/vx7D8KH0JaC3SA0/o=
=CCLv
-END PGP SIGNATURE-



Bug#941042: linux-image-amd64: Stretch-Backport depends on linux-image-4.19.0-0.bpo.6-amd64 which isn't avaiable

2019-09-24 Thread Ben Hutchings
Control: reopen -1
Control: reassign -1 src:linux-latest
Control: linux-latest: Should only build after meta-package dependencies

On Tue, 2019-09-24 at 12:22 +0100, Ben Hutchings wrote:
> On Tue, 2019-09-24 at 00:32 +0200, cronoik wrote:
> > Package: linux-image-amd64
> > Version: 4.19+105+deb10u1~bpo9+1
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > the package linux-image-amd64 from the stretch-backports depends on
> > linux-image-4.19.0-0.bpo.6-amd64 [1] which isn't avaiable via
> > stretch-backports. The current available kernel via stretch-
> > backports 
> > is linux-image-4.19.0-0.bpo.5-amd64 [2].
> 
> Unfortunately there are additional approval steps needed to build the
> signed kernel packages.  These have now been done and they should be
> available within 24 hours.

On second thoughts, let's change this bug report to cover the general
problem.  Repeating what I said on debian-backports:

linux-latest has a build-dependency on a linux-headers package, which
it doesn't really *need*, to prevent it from actually being built until
after linux is built on the same architecture.  However, since we added
signed packages, that's not enough to stop it building too early.

Maybe it should now build-depend on signed kernel images for
architectures that have them, but I'm not sure that's a reasonable
thing to do.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
 - Albert Camus




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


Bug#941083: ITP: stream-lib -- library for summarizing data in streams

2019-09-24 Thread merkys
Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block 585905 by -1

* Package name    : stream-lib
  Version : 2.9.8
  Upstream Author : Matt Abrams 
* URL : https://github.com/addthis/stream-lib
* License : Apache-2.0
  Programming Lang: Java
  Description : library for summarizing data in streams
 A Java library for summarizing data in streams for which it is
infeasible to
 store all events. More specifically, there are classes for estimating:
 cardinality (i.e. counting things); set membership; top-k elements and
 frequency. One particularly useful feature is that cardinality
estimators with
 compatible configurations may be safely merged.

This package is a dependency of apache-cassandra.

Remark: This package is to be maintained with Debian Java Maintainers at
   https://salsa.debian.org/java-team/stream-lib



Bug#540312: /usr/bin/dotty: Re: Dotty generated PS file are broken

2019-09-24 Thread Bernhard Reiter
Package: graphviz
Version: 2.38.0-17
Followup-For: Bug #540312

Dear Maintainer,

the problem is still there with 2.38.0-17.

Another workaround is to remove the last line with only `FI` on it
in the .ps output.


Here is a diff for the example:
--- out.ps.org 2019-09-24 15:40:18.580577716 +0200
+++ out2.ps 2019-09-24 15:43:30.557247527 +0200
@@ -112,7 +112,6 @@
 1546 3120 lineto
 1546 29 lineto
 28 29 lineto
-FI
 0.996094 0.996094 0.992188 CL
 DO 28 29 moveto
 28 3120 lineto

Regards,
Bernhard


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

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

Versions of packages graphviz depends on:
ii  libann0   1.1.2+doc-6
ii  libc6 2.24-11+deb9u4
ii  libcdt5   2.38.0-17
ii  libcgraph62.38.0-17
ii  libexpat1 2.2.0-2+deb9u3
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libgd32.2.4-2+deb9u5
ii  libglib2.0-0  2.50.3-2+deb9u1
ii  libgts-0.7-5  0.7.6+darcs121130-4
ii  libgvc6   2.38.0-17
ii  libgvpr2  2.38.0-17
ii  libstdc++66.3.0-18+deb9u1
ii  libx11-6  2:1.6.4-3+deb9u1
ii  libxaw7   2:1.0.13-1+b2
ii  libxmu6   2:1.1.2-2
ii  libxt61:1.1.5-1

Versions of packages graphviz recommends:
ii  fonts-liberation  1:1.07.4-2

Versions of packages graphviz suggests:
ii  graphviz-doc  2.38.0-17
ii  gsfonts   1:8.11+urwcyr1.0.7~pre44-4.3



Bug#941075: monit: no systemctl file for monit

2019-09-24 Thread Sergey B Kirpichev
On Tue, Sep 24, 2019 at 03:44:03PM +0200, Han Boetes wrote:
>Never you mind, you can close the bug.

Is that means the problem was identified right, i.e. you are
using initscript /etc/init.d/monit directly?

>On Tue, Sep 24, 2019 at 12:06 PM Sergey B Kirpichev
><[1]skirpic...@gmail.com> wrote:
>  I don't understand.  What conditions lead to the state "monit not
>  running"?
> 
>  Perhaps, you have system with systemd, but manage monit using
>  /etc/init.d/monit
>  script directly.  You shouldn't do it, this makes systemd crazy, but
>  this is not a monit's problem.
> 
>  Use systemctl to start/stop/reload monit on systemd-enabled
>  hosts - and everything should work and systemd will be happy.  Please
>  let me know if you still have problems after using this suggestion.



Bug#941084: ITP: vim-gnupg -- Edit gpg encrypted files in vim

2019-09-24 Thread Subin Siby
Subject: ITP: vim-gnupg -- Edit gpg encrypted files in vim
Package: wnpp
Owner: m...@subinsb.com
Severity: wishlist

* Package name: vim-gnupg
  Version : 2.6.1
  Upstream Author : James McCoy 
* URL : https://github.com/jamessan/vim-gnupg
* License : GPL
  Programming Lang: Vim script
  Description : Edit gpg encrypted files in vim

This plugin implements transparent editing of gpg encrypted files. The
filename must have a .gpg, .pgp or .asc suffix. When opening such a
file the content is decrypted, when opening a new file the script will
ask for the recipients of the encrypted file. The file content will
be encrypted to all recipients before it is written. The script turns
off viminfo, swapfile, and undofile to increase security.

This package is very useful for easily editing gpg encrypted files. It
can also edit and then save the file after encrypting it. Hence the
transparent editing tagline. The plugin is quite stable and I intend 
to maintain this package if a new version comes out.



Bug#940817: transition: liblouis

2019-09-24 Thread Paul Gevers
Control: tags -1 pending

On 23-09-2019 22:50, Samuel Thibault wrote:
> Paul Gevers, le lun. 23 sept. 2019 21:51:06 +0200, a ecrit:
>> On 21-09-2019 00:20, Samuel Thibault wrote:
>>> Samuel Thibault, le ven. 20 sept. 2019 10:30:36 +0200, a ecrit:
 The new liblouis release (3.11.0) changed its ABI. I have checked
 the rdeps, they build and run fine, except liblouisutdml, which uses
 internal functions of liblouis. I have uploaded to experimental the new
 upstream release of liblouisutdml (2.8.0) which fixes compatibility with
 liblouis, it has no rdeps.
>>>
>>> I forgot to mention that the new liblouisutdml doesn't build with the
>>> old liblouis. That's why they have to go together, I can't upload
>>> liblouisutdml to unstable yet.
>>
>> Please go ahead.
> 
> They are now in.

binNMU's scheduled.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#941085: krb5-admin-server stopped to work after a system upgrade

2019-09-24 Thread kucera

Package: krb5-admin-server
Version: 1.15-1+deb9u1

In a working production system,
'kadmin.local' stopped to work after a system upgrade, with the 
following error message:


kadmin.local: required parameters in kdc.conf missing while initializing 
kadmin.local interface


The error went away when I commented the following line in 
/etc/krb5kdc/kdc.conf out:

default_principal_expiration = 0

(Afterwards, a similar problem with running the 'kadmin' command across 
the network also disappeared.)


Jan Kucera



Bug#886590: Please add python3-z3 package

2019-09-24 Thread Roman Lebedev
On Tue, Sep 24, 2019 at 5:39 PM Fabian Wolff  wrote:
>
> On 9/24/19 2:49 PM, Roman Lebedev wrote:
> > On Tue, Sep 24, 2019 at 3:32 PM Sylvestre Ledru  
> > wrote:
> >>
> >> Hello
> >>
> >>
> >> Le 24/09/2019 à 12:51, Roman Lebedev a écrit :
> >>> Bump. Any chance this could be prioritized?
> >>> Lack of python3-z3 package prevents me from porting
> >>> some other python2 software to python3.
> >>
> >> Thanks to the work of Fabian Wolff, we have a better version of z3.
> > I'm a little bit out of context here, of *z3* or of z3 packaging?
> > Also, link?
>
> The z3 *package* was several years behind upstream z3, so I put in some work 
> to package
> a more recent version of z3 for Debian, which is what Sylvestre was referring 
> to.
>
> >> I don't know if he is planning to work on this soon but if you write a 
> >> patch
> >> i would be happy to sponsor it.
>
> I can work on it; in fact, there has been a new upstream release of z3 
> (4.8.6, current
> Debian is 4.8.4), which I'd also like to package.
>
> *However*, there is one big problem: In order to build the libz3-cil package 
> (.NET
> bindings), z3 (starting from version 4.8.5) requires the 'dotnet' command:
>
>   https://github.com/dotnet/cli/tree/master/src/dotnet
>
> This command isn't currently available in Debian, and I have no plans of 
> packaging it,
> because I'm very inexperienced with Mono et al. (and packaging thereof).
>
>
> Rather, I'd like to take this as an opportunity to drop the libz3-cil (and 
> maybe also
> libz3-ocaml-dev) package altogether. Those two packages cause _by far_ the 
> highest
> maintenance effort, and I dare presume that they were the main reason why 
> nobody has
> bothered to update the z3 package for so long.
>
> The question is: Wouldn't it be better to have more regular updates and better
> maintenance in general of the z3 package (I'd even consider co-maintaining 
> it, given
> that Michael Tautschnig hasn't made an upload for this package in almost four 
> years),
> at the cost of dropping those two little-used (according to Popcon) packages?
>
> Because I suppose that I'm not the only one not very knowledgeable about Mono 
> and OCaml
> packaging, and this is a pretty large barrier to working on the z3 package 
> (because
> nobody wants to break these two packages, so they decide not to touch z3 at 
> all).
>
>
> But now, building the libz3-cil package is no longer possible unless somebody 
> packages
> the dotnet command (in which case we could always reintroduce it), and as to 
> the OCaml
> bindings, I have to admit that I'm not even sure whether they are currently 
> functioning
> at all (I had to do some patching in the build system even just to get them 
> to build).
>
>
> So, in conclusion: If I'm allowed to drop these two packages (but especially 
> libz3-cil),
> I will have a look at packaging the newer upstream release, and, while doing 
> so, I can
> also include a new python3-z3 package (and probably drop the Python 2 
> package, given
> that it's reaching its end-of-life soon).
>
> What are your thoughts on this?
I personally would not see dumping libz3-cil and libz3-ocaml-dev as a problem.

> Best regards,
> Fabian



Bug#886590:

2019-09-24 Thread Roman Lebedev
Hmm, actually, the py2 module does not seem to work anyway:
$ dpkg -l | grep z3 | grep py
ii  python-z3
4.8.4-1 amd64
theorem prover from Microsoft Research - Python bindings
$ python2 -c 'import z3; print(z3.get_version_string())'
Traceback (most recent call last):
 File "", line 1, in 
ImportError: No module named z3
$ python -c 'import z3; print(z3.get_version_string())'
Traceback (most recent call last):
 File "", line 1, in 
ImportError: No module named z3
$ python3 -c 'import z3; print(z3.get_version_string())'
Traceback (most recent call last):
 File "", line 1, in 
ModuleNotFoundError: No module named 'z3'
$ dpkg -L python-z3
/.
/usr
/usr/lib
/usr/lib/python2.7
/usr/lib/python2.7/dist-packages
/usr/share
/usr/share/doc
/usr/lib/python2.7/dist-packages/libz3.so
/usr/share/doc/python-z3



Bug#940973: libarchive-zip-perl breaks strip-nondeterminism autopkgtest: error: becoming Archive::Zip::DirectoryMember

2019-09-24 Thread gregor herrmann
Control: reopen -1
Control: found -1 1.66-2
Control: affects -1 + strip-nondeterminism
Control: tags -1 - fixed-upstream

On Mon, 23 Sep 2019 18:47:44 +0200, gregor herrmann wrote:

> On Mon, 23 Sep 2019 13:02:04 +0100, Chris Lamb wrote:
> 
> > This has been fixed upstream here:
> >   
> > https://github.com/farblos/perl-Archive-Zip/commit/b0179cbbfeb276ceac0f424d32acf56811b01568
> Thanks for the analysis!
> I've now uploaded -2 with this patch (minus 2 not applying but
> irrelevant hunks) plus the previous commit which also touches on the
> same topic. Will monitor the behaviour a bit :)

And the result of the monitoring is: 1.66-2 breaks strip-nondeterminism
as well:
https://ci.debian.net/data/autopkgtest/testing/amd64/s/strip-nondeterminism/3020870/log.gz

#v+
Reading ZIP archive failed: IO error: reading local extra field :  

error: becoming Archive::Zip::DirectoryMember 
# Looks like your test exited with 29 just after 20.
#v-

Looks like this needs more investigation …


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Dido: Slide


signature.asc
Description: Digital Signature


Bug#934627: transition: libmatio

2019-09-24 Thread Paul Gevers
Control: tags -1 pending

On 24-09-2019 13:28, Sébastien Villemot wrote:
> Le lundi 23 septembre 2019 à 22:13 +0200, Paul Gevers a écrit :
>> Control: tags -1 confirmed
>>
>> On 12-08-2019 17:24, Sébastien Villemot wrote:
>>> Please schedule a transition for libmatio. The new version stands in
>>> experimental. I expect the transition to be smooth (only two symbols
>>> deprecated, and those are not used by reverse dependencies according to
>>> sources.debian.org).
>>
>> Please go ahead.
> 
> Thanks. It is now uploaded and built on all release archs.

binNMU's scheduled.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#941086: ITP: python-pyperform -- fast and convenient way to performance test functions and compare results

2019-09-24 Thread Thomas Goirand
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-pyperform
  Version : 1.86
  Upstream Author : Calvin Lobo 
* URL : https://github.com/lobocv/pyperform
* License : Expat
  Programming Lang: Python
  Description : fast and convenient way to performance test functions and 
compare results

 Pyperform provies an easy and convenient way to performance test blocks of
 python code.
 .
 Tired of writing separate scripts for your performance tests? Don't like
 coding in strings? Using the pyperform decorators, you can easily implement
 timeit tests to your functions with just one line!
 .
 Features of pyperform include:
  - Quick, easy to implement in-code performance tests that run once when the
function is defined.
  - Speed comparison of several functions.
  - Validation of results between ComparisonBenchmarks.
  - Summary reports.
  - Supports class functions as well as global functions.
  - Performance tests can easily be disabled/enabled globally.
  - Community-driven library of performance tests to learn from.

Note: this is a new indirect dependency of python-jsonschema.



Bug#886590: Please add python3-z3 package

2019-09-24 Thread Fabian Wolff
On 9/24/19 2:49 PM, Roman Lebedev wrote:
> On Tue, Sep 24, 2019 at 3:32 PM Sylvestre Ledru  wrote:
>>
>> Hello
>>
>>
>> Le 24/09/2019 à 12:51, Roman Lebedev a écrit :
>>> Bump. Any chance this could be prioritized?
>>> Lack of python3-z3 package prevents me from porting
>>> some other python2 software to python3.
>>
>> Thanks to the work of Fabian Wolff, we have a better version of z3.
> I'm a little bit out of context here, of *z3* or of z3 packaging?
> Also, link?

The z3 *package* was several years behind upstream z3, so I put in some work to 
package
a more recent version of z3 for Debian, which is what Sylvestre was referring 
to.

>> I don't know if he is planning to work on this soon but if you write a patch
>> i would be happy to sponsor it.

I can work on it; in fact, there has been a new upstream release of z3 (4.8.6, 
current
Debian is 4.8.4), which I'd also like to package.

*However*, there is one big problem: In order to build the libz3-cil package 
(.NET
bindings), z3 (starting from version 4.8.5) requires the 'dotnet' command:

  https://github.com/dotnet/cli/tree/master/src/dotnet

This command isn't currently available in Debian, and I have no plans of 
packaging it,
because I'm very inexperienced with Mono et al. (and packaging thereof).


Rather, I'd like to take this as an opportunity to drop the libz3-cil (and 
maybe also
libz3-ocaml-dev) package altogether. Those two packages cause _by far_ the 
highest
maintenance effort, and I dare presume that they were the main reason why 
nobody has
bothered to update the z3 package for so long.

The question is: Wouldn't it be better to have more regular updates and better
maintenance in general of the z3 package (I'd even consider co-maintaining it, 
given
that Michael Tautschnig hasn't made an upload for this package in almost four 
years),
at the cost of dropping those two little-used (according to Popcon) packages?

Because I suppose that I'm not the only one not very knowledgeable about Mono 
and OCaml
packaging, and this is a pretty large barrier to working on the z3 package 
(because
nobody wants to break these two packages, so they decide not to touch z3 at 
all).


But now, building the libz3-cil package is no longer possible unless somebody 
packages
the dotnet command (in which case we could always reintroduce it), and as to 
the OCaml
bindings, I have to admit that I'm not even sure whether they are currently 
functioning
at all (I had to do some patching in the build system even just to get them to 
build).


So, in conclusion: If I'm allowed to drop these two packages (but especially 
libz3-cil),
I will have a look at packaging the newer upstream release, and, while doing 
so, I can
also include a new python3-z3 package (and probably drop the Python 2 package, 
given
that it's reaching its end-of-life soon).

What are your thoughts on this?

Best regards,
Fabian



Bug#940980: clang-7: ICE while building pocl on mips*el

2019-09-24 Thread Sylvestre Ledru

Hello,

Le 22/09/2019 à 23:27, Andreas Beckmann a écrit :

Package: clang-7
Version: 1:7.0.1-9
Severity: normal

https://buildd.debian.org/status/fetch.php?pkg=pocl&arch=mipsel&ver=1.3-6&stamp=1568920151&raw=0
https://buildd.debian.org/status/fetch.php?pkg=pocl&arch=mips64el&ver=1.3-6&stamp=1568939487&raw=0


Could you please check with -8 ?

I am not planning to spend more time on -7 (8.0.1 & 9 have been released 
and bullseye

won't have -7)

thanks

Sylvestre



Bug#941084: ITP: vim-gnupg -- Edit gpg encrypted files in vim

2019-09-24 Thread Reiner Herrmann
Hi Subin,

gnupg.vim is already available in the vim-scripts package
(/usr/share/vim-scripts/plugin/gnupg.vim).

Regards,
  Reiner


signature.asc
Description: PGP signature


Bug#886957: Newest Linux kernel OOPses

2019-09-24 Thread Ben Hutchings
Control: reassign -1 src:linux 4.14.7-1
Control: tag -1 moreinfo

On Thu, 11 Jan 2018 21:18:27 +0200 Vitaliyi  wrote:
> Package: linux-image-amd64
> Version: 4.14

This was not a very useful bug report.  You need to provide details of
the hardware you are using (in this case, specifically the SCSI
adapter).  Please use "reportbug kernel" in future.

Also check whether this is fixed in the current stable release (Debian
10 "buster").

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
 - Albert Camus




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


Bug#912342: linux-latest: enable CONFIG_RTL8XXXU_UNTESTED to support TL-WN725N usb wifi dongle

2019-09-24 Thread Ben Hutchings
Control: tag -1 upstream
Control: found -1 5.2.9-2

On Tue, 30 Oct 2018 16:42:43 +0100 StalkR  wrote:
> Source: linux-latest
> Version: 4.9+80+deb9u5
> Severity: normal
> 
> Dear Maintainer,
> 
> I have a TP-Link TL-WN725N USB 802.11n WiFi dongle.
> Default driver rtl8192cu is buggy (power management issue causing
> deauth). While https://github.com/pvaret/rtl8192cu-fixes works, it's
> deprecated and users are asked use the new rtl8u driver.

For reference, that version of the driver lists this as "TP-Link TL-
WN725N (0bda:8176)".  That USB ID belongs to Realtek and is presumably
shared with other devices using the same chip.

> rtl8u is compiled as a module but nothing happens because this device
> support is hidden behind CONFIG_RTL8XXXU_UNTESTED that debian kernel config
> does not set.
> I had to recompile this kernel with that option enabled to make it work.
> Please consider turning this option on by default.
> 
> Meanwhile, I emailed the maintainer upstream to report that this device works,
> so hopefully they can graduate it as stable and no longer behind untested.

I don't think this is something we would want to change in a stable
release.  If both drivers claim to support the same device ID then it's
unpredictable which of them would actually be used.  And rtl8192cu
might be working better for some other users.

What's more, the default behaviour still hasn't changed upstream.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
 - Albert Camus



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


Bug#934084: Maintainer

2019-09-24 Thread Haroldo Gambini Santos

Hi,

I'm working in the development of CBC.

I'm not used to package for debian, but I'll try to work on it. How is 
the procedure to become a maintainer ?


Cheers,

Haroldo

--
=
Haroldo Gambini Santos
Computing Department
Universidade Federal de Ouro Preto - UFOP
email: haro...@ufop.edu.br
home/research page: www.decom.ufop.br/haroldo


It has long been an axiom of mine that the little things are infinitely
the most important.
-- Sir Arthur Conan Doyle, "A Case of Identity"



Bug#941075: monit: no systemctl file for monit

2019-09-24 Thread Sergey B Kirpichev
tags 941075 +unreproducible
thanks

On Tue, Sep 24, 2019 at 04:34:21PM +0200, Han Boetes wrote:
>No, it means you can close the bug, and absolutely nothing else.

Why you open an issue, if you are not intended to help with it's
solution?

Lets reiterate my question:
--->8--
I don't understand.  What conditions lead to the state "monit not
running"?
-->8--
Could you help with this?



Bug#941087: ITP: ansimarkup -- Produce colored terminal text with an xml-like markup

2019-09-24 Thread Alastair McKinstry
Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: ansimarkup
  Version : 1.4.0
  Upstream Author : Georgi Valkov 
* URL : https://github.com/gvalkov/python-ansimarkup
* License : BSD-3-Clause
  Programming Lang: Python3
  Description : Produce colored terminal text with an xml-like markup

 This is a python3 module to produce colored terminal texty
 with an XML-like markup.

 This is a dependency of the latest version of 'cylc', already in Debian.



Bug#904001: [linux-image] Request add CONFIG_USB_PHY=y

2019-09-24 Thread Ben Hutchings
Control: tag -1 moreinfo

On Tue, 17 Jul 2018 21:19:06 -0400 Bill Prochazka  wrote:
> Package: linux-image-amd64
> Version: 4.9+80+deb9u4
> Severity: wishlist
> 
> --- Please enter the report below this line. ---
> 
> Please add CONFIG_USB_PHY=y to the x86 and amd64 configs for future
> builds.  This is required by the DWC2 and 3 modules (among others) for USB
> xDCI.

I don't think that's correct.  CONFIG_USB_PHY cannot be explicitly
enabled, but should be selected automatically by drivers that need it.

What makes you think the configuration needs to be changed?  Do you
have an example of a working configuration file?

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
 - Albert Camus



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


Bug#941088: journald fails to restart

2019-09-24 Thread Jörg Sommer
Package: systemd
Version: 243-2
Severity: normal

Hi,

since the upgrade from 242-7, journald fails to restart:

```
# s restart systemd-journald.service
Job for systemd-journald.service failed because the control process exited with 
error code.
See "systemctl status systemd-journald.service" and "journalctl -xe" for 
details.

# sst systemd-journald.service
• systemd-journald.service - Journal Service
   Loaded: loaded (/lib/systemd/system/systemd-journald.service; static; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Tue 2019-09-24 17:05:16 CEST; 7s ago
 Docs: man:systemd-journald.service(8)
   man:journald.conf(5)
  Process: 1881 ExecStart=/lib/systemd/systemd-journald (code=exited, 
status=1/FAILURE)
 Main PID: 1881 (code=exited, status=1/FAILURE)
  CPU: 178ms

# j -xe |tail -n30
Sep 24 17:05:02 sudo[1026]: pam_unix(sudo:session): session opened for user 
root by joerg(uid=0)
Sep 24 17:05:15 systemd[1]: Stopping Flush Journal to Persistent Storage...
-- Subject: A stop job for unit systemd-journal-flush.service has begun 
execution
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- A stop job for unit systemd-journal-flush.service has begun execution.
-- 
-- The job identifier is 960.
Sep 24 17:05:15 systemd[1]: systemd-journal-flush.service: Succeeded.
-- Subject: Unit succeeded
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- The unit systemd-journal-flush.service has successfully entered the 'dead' 
state.
Sep 24 17:05:15 systemd[1]: Stopped Flush Journal to Persistent Storage.
-- Subject: A stop job for unit systemd-journal-flush.service has finished
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- A stop job for unit systemd-journal-flush.service has finished.
-- 
-- The job identifier is 960 and the job result is done.
Sep 24 17:05:15 systemd-journald[465]: Journal stopped
-- Subject: The journal has been stopped
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- The system journal process has shut down and closed all currently
-- active journal files.
```

I don't know how to dig further into, to see what journald is doing.
Maybe, can you give me some advice?

Bye Jörg


-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-4
ii  libapparmor1 2.13.3-5
ii  libaudit11:2.8.5-2
ii  libblkid12.34-0.1
ii  libc62.29-2
ii  libcap2  1:2.25-2
ii  libcryptsetup12  2:2.2.1-1
ii  libgcrypt20  1.8.5-2
ii  libgnutls30  3.6.9-5
ii  libgpg-error01.36-7
ii  libidn2-02.2.0-2
ii  libip4tc21.8.3-2
ii  libkmod2 26-3
ii  liblz4-1 1.9.1-1
ii  liblzma5 5.2.4-1+b1
ii  libmount12.34-0.1
ii  libpam0g 1.3.1-5
ii  libpcre2-8-0 10.32-5+b1
ii  libseccomp2  2.4.1-2
ii  libselinux1  2.9-2+b2
ii  libsystemd0  243-2
ii  mount2.34-0.1
ii  util-linux   2.34-0.1

Versions of packages systemd recommends:
ii  dbus1.13.12-1
ii  libpam-systemd  243-2

Versions of packages systemd suggests:
ii  policykit-10.116-1
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.135
ii  udev 242-7

-- Configuration Files:
/etc/systemd/resolved.conf changed [not included]
/etc/systemd/system.conf changed [not included]

-- no debconf information


signature.asc
Description: PGP signature


Bug#940939: Bug

2019-09-24 Thread Matthieu Gallien
On Sunday, September 22, 2019 9:24:58 PM CEST you wrote:
> Hello,
> 
> Sorry for the confusion, the fix proposal is in https://phabricator.kde.org/
> D24147 .
> 
> Best regards

https://phabricator.kde.org/D24147 has landed in master branch of Kirigami2



Bug#886957: Newest Linux kernel OOPses

2019-09-24 Thread Vitaliyi
This was not a very useful reply.
I do not have that OS and hardware at hand anymore.

On Tue, Sep 24, 2019 at 5:59 PM Ben Hutchings  wrote:

> Control: reassign -1 src:linux 4.14.7-1
> Control: tag -1 moreinfo
>
> On Thu, 11 Jan 2018 21:18:27 +0200 Vitaliyi  wrote:
> > Package: linux-image-amd64
> > Version: 4.14
>
> This was not a very useful bug report.  You need to provide details of
> the hardware you are using (in this case, specifically the SCSI
> adapter).  Please use "reportbug kernel" in future.
>
> Also check whether this is fixed in the current stable release (Debian
> 10 "buster").
>
> Ben.
>
> --
> Ben Hutchings
> We get into the habit of living before acquiring the habit of thinking.
>  - Albert Camus
>
>
>


Bug#940321: Acknowledgement (gawk.1: Fix some warnings from "test-groff")

2019-09-24 Thread Bjarni Ingi Gislason
  This has been fixed by upstream in

commit 17453df8b1ba435161b29ca7e8cf266d0fbaf4ac
Author: Arnold D. Robbins 
Date:   Mon May 28 10:45:15 2018 +0300

  and

commit 20a79b31c9897f825323eedee4c0eb01922d53da
Author: Arnold D. Robbins 
Date:   Thu Mar 22 18:37:52 2018 +0200

  except for the italic corrections.


  This report and the #911759 should be closed.

  The new version of gawk (5.0.1) should be made available.

-- 
Bjarni I. Gislason



Bug#941074: ghostscript: ps2pdf SAFER and transparency interference

2019-09-24 Thread Jonas Smedegaard
Control: forwarded -1 https://bugs.ghostscript.com/show_bug.cgi?id=701624

[ replying via bugreport ]

Quoting Markus Demleitner (2019-09-24 13:16:33)
> Hi Jonas,
> 
> On Tue, Sep 24, 2019 at 12:21:15PM +0200, Jonas Smedegaard wrote:
> > Above minimal code is processed by LaTeX, not Ghostscript directly.
> > 
> > Please provide a (minimal, preferrably) example of date and commands 
> > directly involving Ghostscript.
> 
> The postscript code produced above is a bit unwieldy in comparison
> to the TeX source, but hand-crafting a minimal piece of postscript
> is... unattractive to me at this point.
> 
> So, I'm attaching the dvips-produced postscript and, in case that's
> not coming through, I'll keep
> http://www.tfiu.de/transparent-things.ps while this bug is open.
> 
> To reproduce the bug, run
> 
>   ps2pdf14 transparent-things.ps
> 
> (no transparency in transparent-things.pdf) and
> 
>   ps2pdf14 -dNOSAFER transparent-things.ps 
> 
> (transparency in transparent-things.pdf).

Thanks - that's qite useful: I have now passed this report upstream.


 - 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#941085: krb5-admin-server stopped to work after a system upgrade

2019-09-24 Thread Sam Hartman
control: close -1

The line

default_principal_expiration = 0

does not appear in the kdc.conf Debian installs.
It sounds like this was a bug in your local configuration.
Am I missing something?



Bug#941089: linux-image-4.19.0-6: "amdgpu.audio=0" ignored by kernel and loads HDMI audio anyway.

2019-09-24 Thread Alejandro Estay
Package: src:linux
Version: 4.19.67-2
Severity: important
File: linux-image-4.19.0-6
Tags: a11y

Dear Maintainer,  Due to screen EDID bugs I usually disable HDMI audio to avoid 
to see my screen overshapened (I do this in windows too, and works). However I 
set this parameter in this version of debian and kernel enables HDMI audio 
anyway. I put un grub default the parameter string and kernel efectively reads 
it but is completely ignored. The expected behavior is to disable HDMI audio 
and get my screen running in HDMI mode. Also xrandr does not report HDMI audio 
proporty no matter that parameter is pased or not (amdgpu.audio=0).


-- Package-specific info:
** Version:
Linux version 4.19.0-6-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2 (2019-08-28)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-6-amd64 
root=UUID=04721d6c-2813-4718-b9a4-aa57c3b8bad2 ro amdgpu.audio=0 
amdgpu.hw_i2c=1 quiet splash quiet splash amdgpu.audio=0 amdgpu.hw_i2c=1

** Not tainted

** Kernel log:
[3.331875] usbcore: registered new interface driver uas
[3.406257] usb 1-1.6: new high-speed USB device number 6 using ehci-pci
[3.518464] usb 1-1.6: New USB device found, idVendor=045e, idProduct=0723, 
bcdDevice= 1.00
[3.518465] usb 1-1.6: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[3.518466] usb 1-1.6: Product: Microsoft\xc2\xae LifeCam VX-7000
[3.518467] usb 1-1.6: Manufacturer: Microsoft
[3.673871] random: plymouthd: uninitialized urandom read (8 bytes read)
[3.673975] random: plymouthd: uninitialized urandom read (8 bytes read)
[3.730209] PM: Image not found (code -22)
[3.987900] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: 
(null)
[4.344702] scsi 6:0:0:0: Direct-Access Verbatim STORE N GO   8.07 
PQ: 0 ANSI: 4
[4.347112] sd 6:0:0:0: [sdb] 15564800 512-byte logical blocks: (7.97 
GB/7.42 GiB)
[4.348261] sd 6:0:0:0: [sdb] Write Protect is off
[4.348265] sd 6:0:0:0: [sdb] Mode Sense: 23 00 00 00
[4.349485] sd 6:0:0:0: [sdb] Write cache: disabled, read cache: enabled, 
doesn't support DPO or FUA
[4.358226]  sdb: sdb1
[4.362060] sd 6:0:0:0: [sdb] Attached SCSI removable disk
[5.146549] random: crng init done
[5.256253] systemd[1]: RTC configured in localtime, applying delta of -180 
minutes to system time.
[5.477210] systemd[1]: Inserted module 'autofs4'
[5.995761] systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT 
+SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS 
+ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 
default-hierarchy=hybrid)
[6.014370] systemd[1]: Detected architecture x86-64.
[6.031058] systemd[1]: Set hostname to .
[6.041768] systemd[1]: Failed to bump fs.file-max, ignoring: Invalid 
argument
[7.103863] systemd[1]: Listening on Journal Socket.
[7.105297] systemd[1]: Mounting Huge Pages File System...
[7.105401] systemd[1]: Started Forward Password Requests to Wall Directory 
Watch.
[7.105578] systemd[1]: Created slice system-systemd\x2dfsck.slice.
[7.105672] systemd[1]: Listening on Journal Socket (/dev/log).
[7.107476] systemd[1]: Starting Set the console keyboard layout...
[7.473412] EXT4-fs (sda5): re-mounted. Opts: errors=remount-ro
[7.655824] systemd-journald[347]: Received request to flush runtime journal 
from PID 1
[7.680187] lp: driver loaded but no devices found
[7.719119] ppdev: user-space parallel port driver
[8.485586] EFI Variables Facility v0.08 2004-May-17
[8.535628] RAPL PMU: API unit is 2^-32 Joules, 3 fixed counters, 163840 ms 
ovfl timer
[8.535629] RAPL PMU: hw unit of domain pp0-core 2^-16 Joules
[8.535630] RAPL PMU: hw unit of domain package 2^-16 Joules
[8.535630] RAPL PMU: hw unit of domain dram 2^-16 Joules
[8.564881] input: PC Speaker as /devices/platform/pcspkr/input/input7
[8.741010] pstore: Using compression: deflate
[8.741018] pstore: Registered efi as persistent store backend
[8.822739] iTCO_vendor_support: vendor-support=0
[8.824357] tpm_tis 00:04: 1.2 TPM (device-id 0xFE, rev-id 70)
[8.837379] tpm_tis: probe of 00:04 failed with error -5
[8.922753] parport0: PC-style at 0x2008 (0x2000), irq 18 
[PCSPP,TRISTATE,EPP]
[8.943670] sd 0:0:0:0: Attached scsi generic sg0 type 0
[8.943697] sr 1:0:0:0: Attached scsi generic sg1 type 5
[8.943728] sd 6:0:0:0: Attached scsi generic sg2 type 0
[8.974507] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[8.974552] iTCO_wdt: Found a Patsburg TCO device (Version=2, TCOBASE=0x0460)
[8.975031] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[9.026330] lp0: using parport0 (interrupt-driven).
[9.613401] snd_hda_intel :04:00.1: Handle vga_switcheroo audio client
[9.613403] snd_hda_intel :04:00.1: Force to non-snoop mode
[9.662353] media: Linux media interface: v0.10
[9.

Bug#941090: UTF-8 CJK filenames cause garbled X-windows titles

2019-09-24 Thread 積丹尼 Dan Jacobson
Package: xli
Version: 1.17.0+20061110-5
Severity: minor
File: /usr/bin/xli

Upon doing
$ xli 上城街401號.png
/tmp/上城街401號.png is a 1920x1080 8 bit deep RGB PNG image, gamma = 0.45455

The X-windows title is garbled.



Bug#941091: golang-github-docker-docker-dev: /usr/share/gocode/src/github.com/containerd/* already shipped by golang-github-containerd-containerd-dev

2019-09-24 Thread Andreas Beckmann
Package: golang-github-docker-docker-dev
Version: 18.09.9+dfsg1-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

The recent upload of golang-github-docker-docker-dev contains the
following files, which are already provided by
golang-github-containerd-containerd-dev/experimental:

usr/share/gocode/src/github.com/containerd/containerd/cio/io.go
usr/share/gocode/src/github.com/containerd/containerd/cio/io_test.go
usr/share/gocode/src/github.com/containerd/containerd/cio/io_unix.go
usr/share/gocode/src/github.com/containerd/containerd/cio/io_unix_test.go
usr/share/gocode/src/github.com/containerd/containerd/cio/io_windows.go
usr/share/gocode/src/github.com/containerd/containerd/defaults/defaults.go
usr/share/gocode/src/github.com/containerd/containerd/defaults/defaults_unix.go
usr/share/gocode/src/github.com/containerd/containerd/defaults/defaults_windows.go
usr/share/gocode/src/github.com/containerd/containerd/defaults/doc.go
usr/share/gocode/src/github.com/containerd/containerd/log/context.go
usr/share/gocode/src/github.com/containerd/containerd/log/context_test.go

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

  Preparing to unpack 
.../golang-github-containerd-containerd-dev_1.2.4~ds1-1_all.deb ...
  Unpacking golang-github-containerd-containerd-dev (1.2.4~ds1-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/golang-github-containerd-containerd-dev_1.2.4~ds1-1_all.deb
 (--unpack):
   trying to overwrite 
'/usr/share/gocode/src/github.com/containerd/containerd/cio/io.go', which is 
also in package golang-github-docker-docker-dev 18.09.9+dfsg1-3
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   
/var/cache/apt/archives/golang-github-containerd-containerd-dev_1.2.4~ds1-1_all.deb


cheers,

Andreas


golang-github-docker-docker-dev=18.09.9+dfsg1-3_golang-github-containerd-containerd-dev=1.2.4~ds1-1.log.gz
Description: application/gzip


Bug#941092: ITP: python-pyrsistent -- Persistent/Functional/Immutable data structures

2019-09-24 Thread Thomas Goirand
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-pyrsistent
  Version : 0.15.4
  Upstream Author : Tobias Gustafsson 
* URL : https://github.com/tobgu/pyrsistent/
* License : Expat
  Programming Lang: Python
  Description : Persistent/Functional/Immutable data structures

 Pyrsistent is a number of persistent collections (by some referred to as
 functional data structures). Persistent in the sense that they are immutable.
 .
 All methods on a data structure that would normally mutate it instead return a
 new copy of the structure containing the requested updates. The original
 structure is left untouched.
 .
 This will simplify the reasoning about what a program does since no hidden
 side effects ever can take place to these data structures. You can rest assured
 that the object you hold a reference to will remain the same throughout its
 lifetime and need not worry that somewhere five stack levels below you in the
 darkest corner of your application someone has decided to remove that element
 that you expected to be there.
 .
 Pyrsistent is influenced by persistent data structures such as those found in
 the standard library of Clojure. The data structures are designed to share
 common elements through path copying. It aims at taking these concepts and
 make them as pythonic as possible so that they can be easily integrated into
 any python program without hassle.
 .
 If you want to go all in on persistent data structures and use literal syntax
 to define them in your code rather than function calls check out Pyrthon.

Note: This is a new dependency of python-jsonschema 3.0.2, which I will upload
right after this package is accepted.



Bug#940994: lintian: changelog-file-missing-explicit-entry false positive for versions like flatpak_1.2.5-0+deb10u1

2019-09-24 Thread Felix Lechner
Control: tags -1 - moreinfo + pending

Hi Simon,

On Mon, Sep 23, 2019 at 8:50 AM Simon McVittie  wrote:
>
> In my opinion: no

Thank your pointing out this issue. Your fix was implemented in


https://salsa.debian.org/lintian/lintian/commit/e8a5ad1d99e7a86294e65b82de7a46ec0e9c420e

and surrounding commits.

There is also a new test that would catch future false positives for
your situation:


https://salsa.debian.org/lintian/lintian/commit/636c8c354e00b17abbafee9fd3d84ccec4b2a9fe

Kind regards,
Felix Lechner



Bug#941082: LLVMExports.cmake is broken as compared with LLVM-8

2019-09-24 Thread Shengjing Zhu
Package: llvm-9
Version: 1:9~+rc5-1~exp1
Followup-For: Bug #941082

It's still broken, with different reason,

It tries to find "/usr/lib/llvm-9/bin/lit-cpuid", which is in lldb-9.

make[1]: Entering directory '/<>'
dh_auto_configure -- -DCCLS_VERSION=0.20190823-5 
-DCLANG_RESOURCE_DIR=/usr/include/clang//usr/bin/clang
cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
"-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DCCLS_VERSION=0.20190823-5 
-DCLANG_RESOURCE_DIR=/usr/include/clang//usr/bin/clang ..
- -- The CXX compiler identification is GNU 9.2.1
- -- Check for working CXX compiler: /usr/bin/c++
- -- Check for working CXX compiler: /usr/bin/c++ -- works
- -- Detecting CXX compiler ABI info
- -- Detecting CXX compiler ABI info - done
- -- Detecting CXX compile features
- -- Detecting CXX compile features - done
CMake Error at /usr/lib/llvm-9/lib/cmake/llvm/LLVMExports.cmake:1335 (message):
  The imported target "lit-cpuid" references the file

 "/usr/lib/llvm-9/bin/lit-cpuid"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

 "/usr/lib/llvm-9/lib/cmake/llvm/LLVMExports.cmake"

  but not all the files it references.

Call Stack (most recent call first):
  /usr/lib/llvm-9/lib/cmake/llvm/LLVMConfig.cmake:245 (include)
  /usr/lib/cmake/clang-9/ClangConfig.cmake:11 (find_package)
  CMakeLists.txt:71 (find_package)



Bug#789798: Bug#792547: grub-installer: add option to _not_ install to UEFI boot order

2019-09-24 Thread Ian Jackson
Ian Jackson writes ("Bug#792547: grub-installer: add option to _not_ install to 
UEFI boot order"):
> I see that Ian C updated this patch (in July 2015) and reported
> testing it successfully.  Is it now OK ?

every Debian release I update our workaround to apply to the current
release.  FTR, I am just updating our workaround to apply to buster.
(I see the grub2 package is RFH.)

Ian.



Bug#940710: Fails to load pkcs8_key_parser module

2019-09-24 Thread Andreas Henriksson
Hello Felipe Sateler,

On Tue, Sep 24, 2019 at 10:03:19AM -0300, Felipe Sateler wrote:
> Control: reopen -1
[...]
> This causes failed boots on debian by default [...]

Really? Please share more info! It certainly doesn't for me.
(Would also be nice if you reported a dedicated bug report about that
instead of repurposing this.)

> [...] since the debian kernels don't enable that module:
> 
> % grep CONFIG_PKCS8_PRIVATE_KEY_PARSER /boot/config-*
> /boot/config-5.2.0-2-amd64:# CONFIG_PKCS8_PRIVATE_KEY_PARSER is not set
> /boot/config-5.3.0-rc5-amd64:# CONFIG_PKCS8_PRIVATE_KEY_PARSER is not set

I'm aware that it doesn't (at the moment). AFAIK the usual debian kernel
team policy is to enable things on request, so someone just needs to
request it. Since you're not the first to ask *me* (even though I'm not
on the kernel team) I've already asked on #debian-kernel if they can
enable it while at the same time asking people to please not use me as a
proxy.

> 
> Since I have no idea what does pkcs8_key_parser do, I don't know if it
> would be best to have linux enable that option or to have iwd not ship this
> file.

It is needed if you want to use iwd to connect to wpa enterprise
networks. The reason to ship the pkcs8.conf file is explained as a
comment inside it (no autoloading of module, so modular builds would
still be as broken as non-enabled if not shipping it).

To summarize: I don't really see anything to change in *iwd*. Please
talk directly to kernel people for kernel stuff. Please don't repurpose
bug reports for new topics.

Regards,
Andreas Henriksson



Bug#941093: transition: qtbase-opensource-src

2019-09-24 Thread Dmitry Shachnev
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release team,

Debian is currently shipping with Qt 5.11.3 which is quite outdated.

We would like to update to 5.12.5 release from the 5.12 LTS branch.

The packages are prepared in experimental: the core part of the stack is
updated to 5.12.5, some other packages are 5.12.4 but the changes between
.4 and .5 are minimal so we will bump the version when uploading to unstable.

As usual, we have two sub-transitions:

title = "qtbase-opensource-src";
is_affected = .depends ~ "qtbase-abi-5-11-3" | .depends ~ "qtbase-abi-5-12-5";
is_good = .depends ~ "qtbase-abi-5-12-5";
is_bad = .depends ~ "qtbase-abi-5-11-3";

and

title = "qtdeclarative-opensource-src";
is_affected = .depends ~ "qtdeclarative-abi-5-11-2" | .depends ~ 
"qtdeclarative-abi-5-12-5";
is_good = .depends ~ "qtdeclarative-abi-5-12-5";
is_bad = .depends ~ "qtdeclarative-abi-5-11-2";

At the same time, qbs will be updated to 1.13.1 (only qtcreator is affected).

The 5.12 release fixes build failure in qtwebengine (#939038) which blocks the
libvpx transition.

The only known package failing to build with Qt 5.12 is deepin-qt5dxcb-plugin
(#935105) which I can NMU if needed.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Bug#941091: golang-github-docker-docker-dev: /usr/share/gocode/src/github.com/containerd/* already shipped by golang-github-containerd-containerd-dev

2019-09-24 Thread Dmitry Smirnov
On Wednesday, 25 September 2019 1:47:28 AM AEST Andreas Beckmann wrote:
> The recent upload of golang-github-docker-docker-dev contains the
> following files, which are already provided by
> golang-github-containerd-containerd-dev/experimental:

Actually it is vice versa... We can and probably should declare conflicts 
with that package but seriously, clash with badly maintained package in 
"experimental" it is not a "serious" problem in Docker. Arguably containerd 
should not hijack Docker's namespace without conflict.

-- 
Regards,
 Dmitry Smirnov.

---

We occasionally stumble over the truth but most of us pick ourselves up
and hurry off as if nothing had happened.
-- Winston Churchill


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


Bug#939038: qtwebengine-opensource-src: FTBFS with libvpx6

2019-09-24 Thread Dmitry Shachnev
Control: fixed -1 qtwebengine-opensource-src/5.12.2+dfsg-1

On Sat, Aug 31, 2019 at 01:09:42PM +0100, Jonathan Wiltshire wrote:
> During a rebuild for the libvpx6 transition qtwebengine-opensource-src
> failed to build from source. [...]
>
> https://buildd.debian.org/status/package.php?p=qtwebengine-opensource-src

The failing code was removed in [1], so backporting that may help.

However, the Qt WebEngine 5.12 branch builds cleanly, and I have just filed
a transition bug [2]. So just uploading 5.12.5 to unstable may be the easiest
thing to do.

[1]: https://webrtc-review.googlesource.com/c/src/+/76801/
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941093

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Bug#934346: sbuild: No need to install fakeroot for source packages with Rules-Requires-Root: no

2019-09-24 Thread Vagrant Cascadian
On 2019-08-10, Johannes Schauer wrote:
> Quoting Johannes Schauer (2019-08-10 07:16:53)
>> Quoting Daniel Schepler (2019-08-10 04:45:05)
>> > I notice that on my source packages which declare
>> > "Rules-Requires-Root: no" I still see sbuild installing fakeroot in
>> > the chroot which shouldn't be necessary.
>> 
>> please be more specific. When does sbuild install fakeroot for you?
>
> ah I see it now. This could indeed be fixed. Thanks!

I can somewhat emulate support for "Rules-Requires-Root: no" by setting
in ~/.sbuildrc:

  $core_depends = [ 'build-essential:native' ];
  $build_environment = { 'RULES_REQUIRES_ROOT' => 'no', };

Which results in fakeroot not being called, though it still ends up
calling dpkg with arguments to use fakeroot:

  $ grep fakeroot ../u-boot_2019.10~rc4+dfsg-2~20190924~1_amd64.build
  Command: dpkg-buildpackage -us -uc -G -rfakeroot

But since fakeroot wasn't installed, I guess dpkg-buildpackage silently
ignored that option... or never tried to call fakeroot, since the
variables or other settings were set for Rules-Requires-Root?


Of course, it would be very nice if sbuild could just read the
Rules-Requires-Root setting an behave appropriately. :)


live well,
  vagrant


signature.asc
Description: PGP signature


Bug#941095: /usr/bin/locale: 'locale' incorrectly complains about (only) 'LC_ALL', but not offending LC_* when locale not found

2019-09-24 Thread Bernhard Hermann
Package: libc-bin
Version: 2.28-10
Severity: minor
File: /usr/bin/locale

Dear Maintainer,

-- PROBLEM:
'locale' shows an error message ONLY about not being able to set LC_ALL
when any of a number of LC_ values are wrong, instead of pointing to the
offending values, as it does in other cases.
This is misleading and prevents people from easily figuring out what is
really the problem (missing locale, typo, ...), because it misdirects
attention to LC_ALL.

affected LC_s:
LANG
LC_NUMERIC
LC_TIME
LC_COLLATE
LC_MONETARY
LC_PAPER
LC_NAME
LC_ADDRESS
LC_TELEPHONE
LC_MEASUREMENT
LC_IDENTIFICATION

(potentially LANGUAGE)

-- EXPECTED:
'locale' should show an error message indicating which LC_s locale was not
found, as it does with 'LC_CTYPE' and 'LC_MESSAGES'.

-- REPRODUCE:

for l in $(locale | cut -d '=' -f 1) ; do echo "$l" ;  env ${l}="MISSING"
locale > /dev/null ; echo ; done
LANG
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

LANGUAGE

LC_CTYPE
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

LC_NUMERIC
locale: Cannot set LC_ALL to default locale: No such file or directory

LC_TIME
locale: Cannot set LC_ALL to default locale: No such file or directory

LC_COLLATE
locale: Cannot set LC_ALL to default locale: No such file or directory

LC_MONETARY
locale: Cannot set LC_ALL to default locale: No such file or directory

LC_MESSAGES
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

LC_PAPER
locale: Cannot set LC_ALL to default locale: No such file or directory

LC_NAME
locale: Cannot set LC_ALL to default locale: No such file or directory

LC_ADDRESS
locale: Cannot set LC_ALL to default locale: No such file or directory

LC_TELEPHONE
locale: Cannot set LC_ALL to default locale: No such file or directory

LC_MEASUREMENT
locale: Cannot set LC_ALL to default locale: No such file or directory

LC_IDENTIFICATION
locale: Cannot set LC_ALL to default locale: No such file or directory

LC_ALL
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory


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

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

Versions of packages libc-bin depends on:
ii  libc6  2.28-10

Versions of packages libc-bin recommends:
ii  manpages  4.16-2

libc-bin suggests no packages.

-- no debconf information


Bug#940966: [qml-module-org-kde-kirigami2] qml-module-org-kde-kirigami2 uses an invalid version of QtQuick.Controls

2019-09-24 Thread Ximo Baldó i Soriano
Package: qml-module-org-kde-kirigami2
Version: 5.62.0-1

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

It affects other parts of 'look and feel'  from systemsettings, no only 
wallpaper selection. For now, as far I know, no one is working but color 
schemes.

--- System information. ---
Architecture: 
Kernel:   Linux 5.2.0-2-amd64

Debian Release: bullseye/sid
  900 unstable-debug  deb.debian.org 
  900 unstableftp.debian.org 
  800 experimentalftp.debian.org 
  500 stable  people.debian.org 

--- Package information. ---
Depends (Version) | Installed
=-+-
libkf5kirigami2-5(= 5.62.0-1) | 5.62.0-1
qml-module-qtgraphicaleffects | 5.11.3-2
qml-module-qtqml-models2  | 5.11.3-4
qml-module-qtquick-controls2  | 5.11.3+dfsg-2
qml-module-qtquick-templates2 | 5.11.3+dfsg-2
qml-module-qtquick2   | 5.11.3-4
libc6   (>= 2.29) | 
libqt5core5a  (>= 5.11.0~rc1) | 
libqt5gui5   (>= 5.11.0~) | 
libqt5network5   (>= 5.11.0~) | 
libqt5qml5(>= 5.11.0) | 
libqt5quick5  (>= 5.10.0) | 
libqt5quickcontrols2-5 (>= 5.7.1) | 
libstdc++6 (>= 4.1.1) | 


Package's Recommends field is empty.

Package's Suggests field is empty.





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


Bug#941096: blender: BMW doesn't render correctly

2019-09-24 Thread Iemand Die Boos Is
Package: blender
Version: 2.80+dfsg-3+b1
Severity: normal

Dear Maintainer,

When trying to render Blender's BMW demo
(https://download.blender.org/demo/test/BMW27_2.blend.zip), it looks
weird: https://ibb.co/n03sHp4. This did not happen when using Blender
2.79. When using upstream Blender downloaded from
https://www.blender.org/download/Blender2.80/blender-2.80-linux-glibc217-x86_64.tar.bz2/,
it looks like https://ibb.co/Rg3CmxB.


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

Kernel: Linux 5.2.0-2-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_WARN
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages blender depends on:
ii  blender-data  2.80+dfsg-3
ii  fonts-dejavu  2.37-1
ii  libavcodec58  7:4.1.4-1+b2
ii  libavdevice58 7:4.1.4-1+b2
ii  libavformat58 7:4.1.4-1+b2
ii  libavutil56   7:4.1.4-1+b2
ii  libboost-locale1.67.0 1.67.0-13
ii  libc6 2.29-2
ii  libfftw3-double3  3.3.8-2
ii  libfreetype6  2.9.1-4
ii  libgcc1   1:9.2.1-8
ii  libgl11.1.0-1+b1
ii  libglew2.12.1.0-4+b1
ii  libgomp1  9.2.1-8
ii  libilmbase24  2.3.0-6
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2+b1
ii  libjemalloc2  5.2.1-1
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  libopenal11:1.19.1-1+b1
ii  libopencolorio1v5 1.1.1~dfsg0-3
ii  libopenexr24  2.3.0-6
ii  libopenimageio2.0 2.0.10~dfsg0-1+b1
ii  libopenjp2-7  2.3.0-2
ii  libopenvdb5.2 5.2.0-5.1+b1
ii  libpcre3  2:8.39-12+b1
ii  libpng16-16   1.6.37-1
ii  libpython3.7  3.7.4-4
ii  libsndfile1   1.0.28-6
ii  libspnav0 0.2.3-1+b2
ii  libstdc++69.2.1-8
ii  libswscale5   7:4.1.4-1+b2
ii  libtbb2   2019~U8-1
ii  libtiff5  4.0.10+git190903-1
ii  libx11-6  2:1.6.8-1
ii  libxfixes31:5.0.3-1
ii  libxi62:1.7.9-1
ii  libxml2   2.9.4+dfsg1-7+b3
ii  libxxf86vm1   1:1.1.4-1+b2
ii  zlib1g1:1.2.11.dfsg-1+b1

blender recommends no packages.



Bug#941097: vips FTBFS on all release architectures: multiple definition of `OrcTargetPowerPCFlags'

2019-09-24 Thread Paul Gevers
Source: vips
Version: 8.7.4-1
Severity: serious
Tags: ftbfs
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

For the libmatio transition I scheduled binNMU's for vips. All architectures
FTBFS. The reproducible build infrastructure is showing the same (on amd64, the
other archs were still fine on 2019-08-26).

51:5:9  -Wl,-z,relro -Wl,-z,now -o libvips.la -rpath /usr/lib/x86_64-linux-gnu  
resample/libresample.la arithmetic/libarithmetic.la colour/libcolour.la 
conversion/libconversion.la convolution/libconvolution.la 
deprecated/libdeprecated.la foreign/libforeign.la freqfilt/libfreqfilt.la 
histogram/libhistogram.la draw/libdraw.la iofuncs/libiofuncs.la 
morphology/libmorphology.la mosaicing/libmosaicing.la create/libcreate.la -lz 
-lMagickCore-6.Q16 -lpng16 -lz  -ltiff -ljpeg  -Wl,--export-dynamic -pthread 
-lgmodule-2.0 -lgobject-2.0 -lglib-2.0  -lexpat -lpangoft2-1.0 -lpango-1.0 
-lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype -lgsf-1 -lgobject-2.0 
-lglib-2.0 -lxml2 -lfftw3 -lorc-0.4 -llcms2 -lgif -lrsvg-2 -lm -lgio-2.0 
-lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -lcairo   -lpoppler-glib 
-lgobject-2.0 -lglib-2.0 -lcairo -lIlmImf -lImath -lHalf -lIex -lIexMath 
-lIlmThread -lpthread -lopenslide -lcfitsio -lpthread -lwebp -lwebpmux -lwebp 
-L/usr/lib/x86_64-linux-gnu/hdf5/serial/lib -lmatio -lhdf5 -lz -lexif -lm 
libtool: link: g++  -fPIC -DPIC -shared -nostdlib 
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crti.o 
/usr/lib/gcc/x86_64-linux-gnu/9/crtbeginS.o  -Wl,--whole-archive 
resample/.libs/libresample.a arithmetic/.libs/libarithmetic.a 
colour/.libs/libcolour.a conversion/.libs/libconversion.a 
convolution/.libs/libconvolution.a deprecated/.libs/libdeprecated.a 
foreign/.libs/libforeign.a freqfilt/.libs/libfreqfilt.a 
histogram/.libs/libhistogram.a draw/.libs/libdraw.a iofuncs/.libs/libiofuncs.a 
morphology/.libs/libmorphology.a mosaicing/.libs/libmosaicing.a 
create/.libs/libcreate.a -Wl,--no-whole-archive  
/usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so -lpng16 -ltiff -ljpeg 
-lgmodule-2.0 -lexpat -lpangoft2-1.0 -lpango-1.0 -lfontconfig -lfreetype 
-lgsf-1 -lxml2 -lfftw3 -lorc-0.4 -llcms2 -lgif -lrsvg-2 -lgio-2.0 
-lgdk_pixbuf-2.0 -lpoppler-glib -lgobject-2.0 -lglib-2.0 -lcairo -lIlmImf 
-lImath -lHalf -lIex -lIexMath -lIlmThread -lopenslide -lcfitsio -lpthread 
-lwebpmux -lwebp -L/usr/lib/x86_64-linux-gnu/hdf5/serial/lib -lmatio -lhdf5 -lz 
-lexif -L/usr/lib/gcc/x86_64-linux-gnu/9 
-L/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu 
-L/usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib -L/lib/x86_64-linux-gnu 
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib 
-L/usr/lib/gcc/x86_64-linux-gnu/9/../../.. -lstdc++ -lm -lc -lgcc_s 
/usr/lib/gcc/x86_64-linux-gnu/9/crtendS.o 
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crtn.o  -g -O2 
-fstack-protector-strong -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--export-dynamic 
-pthread   -pthread -fopenmp -Wl,-soname -Wl,libvips.so.42 -o 
.libs/libvips.so.42.9.5
/usr/bin/ld: 
conversion/.libs/libconversion.a(composite.o):/usr/include/orc-0.4/orc/orctarget.h:28:
 multiple definition of `OrcTargetPowerPCFlags'; 
resample/.libs/libresample.a(reducev.o):/usr/include/orc-0.4/orc/orctarget.h:28:
 first defined here
collect2: error: ld returned 1 exit status

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

Kernel: Linux 5.2.0-2-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

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAl2KYCwACgkQnFyZ6wW9
dQrFZgf/fZeyd2D4my4iqiF1OZYQ8xjWQYY1kgZRO0aDJaHBT93pFv9Ez5B3i4yI
uuPRWpGGrM/9ixElSjBcm31iSqOQoT9DgByT1JuDhNTYlLODfHoeHxvYpM4umQm/
lPEdETGykLnwfVIl+sHlsO++6q12kh8OKsjPocft1K7PNzZnGaddvJWS8TMHm7vv
NvyACuqqGs9DT/0hA8Ao1quHNFhYTB7aulpz5GvgYoXCz4v6t7KK/nbiFzoGyea+
9zVgdR0m0+exDAwR3FzWzKqnsJvLbVwWlLnw89wuQRCRCf1kaFvyPQBLr5U+ku3T
uxLCT2/VhA/gRjQlUU00VWpHDpOutQ==
=3/Rm
-END PGP SIGNATURE-



Bug#741412: exim4: process crashed with signal 11 while delivering

2019-09-24 Thread Leszek Dubiel


Since 2017 I don't get that error anymore. Please close the bug.




Bug#941098: linux-image-5.2.0-2-amd64: Please enable CONFIG_PKCS8_PRIVATE_KEY_PARSER

2019-09-24 Thread Felipe Sateler
Package: src:linux
Version: 5.2.9-2
Severity: wishlist

Dear Maintainer,

As detailed in #940710, iwd needs this option in order to support
enterprise WPA networks. The lack of this module means iwd causes
systemd-modules-load to fail at boot.

It would be great if it would be enabled.

-- 

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

Versions of packages linux-image-5.2.0-2-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.135
ii  kmod26-3
ii  linux-base  4.6

Versions of packages linux-image-5.2.0-2-amd64 recommends:
ii  apparmor 2.13.3-5
ii  firmware-linux-free  3.4

Versions of packages linux-image-5.2.0-2-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-efi-amd64  2.04-3
pn  linux-doc-5.2   

Versions of packages linux-image-5.2.0-2-amd64 is related to:
ii  firmware-amd-graphics 20190717-2
ii  firmware-atheros  20190717-2
ii  firmware-bnx2 20190717-2
ii  firmware-bnx2x20190717-2
ii  firmware-brcm8021120190717-2
ii  firmware-cavium   20190717-2
ii  firmware-intel-sound  20190717-2
ii  firmware-intelwimax   20190717-2
ii  firmware-ipw2x00  20190717-2
ii  firmware-ivtv 20190717-2
ii  firmware-iwlwifi  20190717-2
ii  firmware-libertas 20190717-2
ii  firmware-linux-nonfree20190717-2
ii  firmware-misc-nonfree 20190717-2
ii  firmware-myricom  20190717-2
ii  firmware-netxen   20190717-2
ii  firmware-qlogic   20190717-2
ii  firmware-realtek  20190717-2
ii  firmware-samsung  20190717-2
ii  firmware-siano20190717-2
ii  firmware-ti-connectivity  20190717-2
pn  xen-hypervisor

-- no debconf information



Bug#940966: [qml-module-org-kde-kirigami2] qml-module-org-kde-kirigami2 uses an invalid version of QtQuick.Controls

2019-09-24 Thread Martin Steigerwald
Hi!

Ximo Baldó i Soriano - 24.09.19, 19:49:56 CEST:
> Package: qml-module-org-kde-kirigami2
> Version: 5.62.0-1
> 
> --- Please enter the report below this line. ---
> 
> It affects other parts of 'look and feel'  from systemsettings, no
> only wallpaper selection. For now, as far I know, no one is working
> but color schemes.

Please check whether this is fixed in 5.62.0-2 version of the package.

Thanks,
-- 
Martin



Bug#940979: Bug#941097: vips FTBFS on all release architectures: multiple definition of `OrcTargetPowerPCFlags'

2019-09-24 Thread GCS
Control: block 941097 by 940979

Hi Paul,

On Tue, Sep 24, 2019 at 8:30 PM Paul Gevers  wrote:
> Source: vips
> Version: 8.7.4-1
> Severity: serious
> Tags: ftbfs
> Justification: FTBFS
[...]
> /usr/bin/ld: 
> conversion/.libs/libconversion.a(composite.o):/usr/include/orc-0.4/orc/orctarget.h:28:
>  multiple definition of `OrcTargetPowerPCFlags'; 
> resample/.libs/libresample.a(reducev.o):/usr/include/orc-0.4/orc/orctarget.h:28:
>  first defined here
> collect2: error: ld returned 1 exit status
 This is known, reported and fixing it depends on the orc maintainers.

Regards,
Laszlo/GCS



Bug#941036: cacti: CVE-2019-16723

2019-09-24 Thread Paul Gevers
Hi,

On 24-09-2019 05:58, Salvatore Bonaccorso wrote:
> Hi Paul,
> 
> On Mon, Sep 23, 2019 at 10:28:31PM +0200, Paul Gevers wrote:
>> Hi Salvatore,
>>
>> Thanks for your report.
>>
>> On 23-09-2019 22:20, Salvatore Bonaccorso wrote:
>>> The following vulnerability was published for cacti, filling for
>>> tracking the upstream issue. At time of writing, I think there was not
>>> a patch upstream yet.
>>
>> I think there is:
>> https://github.com/Cacti/cacti/commit/7a6a17252a1cbda180b61fff244cb3ce797d5264
>>
>> It mentioned the wrong issue, as documented here:
>> https://github.com/Cacti/cacti/commit/de3833b0414383efc9e075dd13c95925e2ca504c
> 
> "Ack", thank you!
> 
> Regards,
> Salvatore
> 

While trying to figure out if old-stable is affected, I noticed this is
part of the fix:
https://github.com/Cacti/cacti/commit/c7cf4a26e4848872b48094e67f8d0a01dd7613d2

Paul



signature.asc
Description: OpenPGP digital signature


Bug#941099: mark open-iscsi Multi-Arch: foreign

2019-09-24 Thread Helmut Grohne
Package: open-iscsi
Version: 2.0.874-7.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:libvirt

libvirt fails to cross build from source, because installing its
Build-Depends fails during open-iscsi's postinst. open-iscsi doesn't
like being configured on a system where its executables are not
runnable. Usually this means that one should be using the build
architecture instance. To get there one way is marking open-iscsi
Multi-Arch: foreign. I wasn't sure whether that's reasonable, so I asked
Sam Hartman.

 [...] I need to figure out whether m-a:foreign makes sense on 
[open-iscsi]
 helmut:  I think so.
 helmut:  the open-iscsi package contains the tools you'd use to 
attach to a disk over the network.
 It may well be that open-iscsi needs to be the same architecture as 
your kernel, but it's definitely the case that consumers of open-iscsi (other 
packages) won't care.

This matches my experience. Therefore, I propose marking it such.

I still don't understand why libvirt has a build dependency on it, but
well.

Helmut
diff --minimal -Nru open-iscsi-2.0.874/debian/changelog 
open-iscsi-2.0.874/debian/changelog
--- open-iscsi-2.0.874/debian/changelog 2018-12-12 01:05:19.0 +0100
+++ open-iscsi-2.0.874/debian/changelog 2019-09-24 20:41:50.0 +0200
@@ -1,3 +1,10 @@
+open-iscsi (2.0.874-7.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark open-iscsi Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 24 Sep 2019 20:41:50 +0200
+
 open-iscsi (2.0.874-7.1) unstable; urgency=medium
 
   * Non-maintainer upload
diff --minimal -Nru open-iscsi-2.0.874/debian/control 
open-iscsi-2.0.874/debian/control
--- open-iscsi-2.0.874/debian/control   2018-12-12 01:05:19.0 +0100
+++ open-iscsi-2.0.874/debian/control   2019-09-24 20:41:49.0 +0200
@@ -24,6 +24,7 @@
 
 Package: open-iscsi
 Architecture: linux-any
+Multi-Arch: foreign
 Depends: udev, ${misc:Depends}, ${shlibs:Depends}, lsb-base (>= 3.0-6)
 Recommends: ${busybox:Recommends}
 Pre-Depends: debconf | debconf-2.0


Bug#941100: openscad FTCBFS: python3 build dependency not installable

2019-09-24 Thread Helmut Grohne
Source: openscad
Version: 2019.05-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

openscad fails to cross build from source, because its python3
dependency cannot be installed for the host architecture. It actually
wants to run python3 during build, so it needs the build architecture
python3. Thus it should be annotated :any. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru openscad-2019.05/debian/changelog 
openscad-2019.05/debian/changelog
--- openscad-2019.05/debian/changelog   2019-08-06 23:19:39.0 +0200
+++ openscad-2019.05/debian/changelog   2019-09-24 20:28:50.0 +0200
@@ -1,3 +1,10 @@
+openscad (2019.05-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Annotate Build-Depends: python3 with :any. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 24 Sep 2019 20:28:50 +0200
+
 openscad (2019.05-2) unstable; urgency=medium
 
   * Fix some testsuite failures (Closes: #795300).
diff --minimal -Nru openscad-2019.05/debian/control 
openscad-2019.05/debian/control
--- openscad-2019.05/debian/control 2019-08-06 23:19:39.0 +0200
+++ openscad-2019.05/debian/control 2019-09-24 20:28:48.0 +0200
@@ -29,7 +29,7 @@
 libglew-dev (>= 1.5.4) | libglew1.6-dev | libglew1.5-dev (>= 1.5.4),
 libgmp-dev | libgmp10-dev | libgmp3-dev,
 libmpfr-dev,
-python3,
+python3:any,
 cmake,
 libboost-dev (>= 1.46.0),
 libboost-regex-dev,


  1   2   >