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

[John Paul Adrian Glaubitz]

Control: reassign -1 src:linux
Control: tags -1 patch

On 4/16/19 1:16 PM, Ben Hutchings wrote:
>> Do you think we could carry a patch in src:linux for the time being?
> [...]
> 
> I would rather not do that until it's accepted, as if it that doesn't
> happen we either have to switch back or carry it forever.

My patch has been merged upstream now and is planned for -stable [1].

Attaching the patch.

Adrian

> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git/commit/?id=07a6d63eb1b54b5fb38092780fe618dfe1d96e23

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>From 0d7bc2b2fbdfeb58a06371996dd8c225b6d03343 Mon Sep 17 00:00:00 2001
From: John Paul Adrian Glaubitz 
Date: Tue, 11 Jun 2019 16:54:27 +0200
Subject: [PATCH] sunhv: Fix device naming inconsistency between sunhv_console
 and sunhv_reg

In d5a2aa24, the name in struct console sunhv_console was changed from "ttyS"
to "ttyHV" while the name in struct uart_ops sunhv_pops remained unchanged.

This results in the hypervisor console device to be listed as "ttyHV0" under
/proc/consoles while the device node is still named "ttyS0":

root@osaka:~# cat /proc/consoles
ttyHV0   -W- (EC p  )4:64
tty0 -WU (E )4:1
root@osaka:~# readlink /sys/dev/char/4:64
../../devices/root/f02836f0/f0285690/tty/ttyS0
root@osaka:~#

This means that any userland code which tries to determine the name of the
device file of the hypervisor console device can not rely on the information
provided by /proc/consoles. In particular, booting current versions of debian-
installer inside a SPARC LDOM will fail with the installer unable to determine
the console device.

After renaming the device in struct uart_ops sunhv_pops to "ttyHV" as well,
the inconsistency is fixed and it is possible again to determine the name
of the device file of the hypervisor console device by reading the contents
of /proc/console:

root@osaka:~# cat /proc/consoles
ttyHV0   -W- (EC p  )4:64
tty0 -WU (E )4:1
root@osaka:~# readlink /sys/dev/char/4:64
../../devices/root/f02836f0/f0285690/tty/ttyHV0
root@osaka:~#

With this change, debian-installer works correctly when installing inside
a SPARC LDOM.
---
 drivers/tty/serial/sunhv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/sunhv.c b/drivers/tty/serial/sunhv.c
index 63e34d868de8..f8503f8fc44e 100644
--- a/drivers/tty/serial/sunhv.c
+++ b/drivers/tty/serial/sunhv.c
@@ -397,7 +397,7 @@ static const struct uart_ops sunhv_pops = {
 static struct uart_driver sunhv_reg = {
 	.owner			= THIS_MODULE,
 	.driver_name		= "sunhv",
-	.dev_name		= "ttyS",
+	.dev_name		= "ttyHV",
 	.major			= TTY_MAJOR,
 };
 
-- 
2.21.0

Bug#930508: installation-reports: Corrupt display after grub as soon as kernel loads - buster netinst iso

[Fab Stz]

Please find updated system info attached.
The ones added by reportbug are those of my previous system.
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 
Root Complex [1022:15d0]
Subsystem: ASUSTeK Computer Inc. Device [1043:876b]
00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 IOMMU 
[1022:15d1]
Subsystem: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 IOMMU 
[1022:15d1]
00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
00:01.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 PCIe 
GPP Bridge [6:0] [1022:15d3]
Kernel driver in use: pcieport
00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 
Internal PCIe GPP Bridge 0 to Bus A [1022:15db]
Kernel driver in use: pcieport
00:08.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 
Internal PCIe GPP Bridge 0 to Bus B [1022:15dc]
Kernel driver in use: pcieport
00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller 
[1022:790b] (rev 61)
Subsystem: ASUSTeK Computer Inc. FCH SMBus Controller [1043:876b]
Kernel driver in use: piix4_smbus
Kernel modules: i2c_piix4, sp5100_tco
00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge 
[1022:790e] (rev 51)
Subsystem: ASUSTeK Computer Inc. FCH LPC Bridge [1043:876b]
00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 
Device 24: Function 0 [1022:15e8]
00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 
Device 24: Function 1 [1022:15e9]
00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 
Device 24: Function 2 [1022:15ea]
00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 
Device 24: Function 3 [1022:15eb]
Kernel driver in use: k10temp
Kernel modules: k10temp
00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 
Device 24: Function 4 [1022:15ec]
00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 
Device 24: Function 5 [1022:15ed]
00:18.6 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 
Device 24: Function 6 [1022:15ee]
00:18.7 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 
Device 24: Function 7 [1022:15ef]
01:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] 400 Series 
Chipset USB 3.1 XHCI Controller [1022:43d5] (rev 01)
Subsystem: ASMedia Technology Inc. Device [1b21:1142]
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci
01:00.1 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] 400 Series 
Chipset SATA Controller [1022:43c8] (rev 01)
Subsystem: ASMedia Technology Inc. Device [1b21:1062]
Kernel driver in use: ahci
Kernel modules: ahci
01:00.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 400 Series 
Chipset PCIe Bridge [1022:43c6] (rev 01)
Kernel driver in use: pcieport
02:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 400 Series 
Chipset PCIe Port [1022:43c7] (rev 01)
Kernel driver in use: pcieport
02:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 400 Series 
Chipset PCIe Port [1022:43c7] (rev 01)
Kernel driver in use: pcieport
02:05.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 400 Series 
Chipset PCIe Port [1022:43c7] (rev 01)
Kernel driver in use: pcieport
02:06.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 400 Series 
Chipset PCIe Port [1022:43c7] (rev 01)
Kernel driver in use: pcieport
02:07.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 400 Series 
Chipset PCIe Port [1022:43c7] (rev 01)
Kernel driver in use: pcieport
07:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)
Subsystem: ASUSTeK Computer Inc. RTL8111/8168/8411 PCI Express Gigabit 
Ethernet Controller [1043:8677]
Kernel driver in use: r8169
Kernel modules: r8169
08:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] 
[1002:15dd] (rev cb)
Subsystem: ASUSTeK Computer Inc. Device [1043:876b]
Kernel driver in use: amdgpu
Kernel modules: amdgpu
08:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] 
Raven/Raven2/Fenghuang HDMI/DP Audio Controller [1002:15de]
Subsystem: ASUSTeK Computer Inc. Device [1043:876b]
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
08:00.2 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] Family 
17h (Models 10h-1fh) Platform Security 

Bug#930507: libompl-dev: libeigen required to build against OMPL

[Neil Dantam]

Package: libompl-dev
Version: 1.4.2+ds1-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

 Attempting to build against libompl on Buster.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

 I installed libompl-dev and used pkg-config to obtain compiler
 options to build against ompl.

   * What was the outcome of this action?

 The `Eigen/Core` header was not found.  This eigen header is
 referenced in `/usr/include/ompl/base/ProjectionEvaluator.h:49`.

   * What outcome did you expect instead?

 Eigen is automatically installed with libompl-dev and
 pkg-config sets the appropriate flags to find the Eigen headers.

 Specifically:

 1. Installing libompl-dev pulls libeigen3-dev as a dependency.

 2. The ompl.pc pkg-config file includes the appropriate flags
to find the Eigen headers.  In OMPL 1.5.0, the generated ompl.pc
includes `-I/usr/include/eigen3` in the cflags.


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

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

Versions of packages libompl-dev depends on:
ii  libboost-dev  1.62.0.1
pn  libompl11 
ii  pkg-config0.29-4+b1

libompl-dev recommends no packages.

Versions of packages libompl-dev suggests:
ii  libode-dev  2:0.14-2

Bug#930508: installation-reports: Corrupt display after grub as soon as kernel loads - buster netinst iso

[Fab Stz]

Package: installation-reports
Severity: normal

Dear Maintainer,

I'm booting the latest weekly netinst iso to install Buster.
I'm facing corrupt display as soon as grub starts loading the kernel.
Grub's display is fine. [1]
The only workaround I found working is setting these parameters to the
kernel vga=794 or vga=791 for example.

My System is ASUS Prime B450M-A with AMD Athlon 200GE CPU (with
integrated vega graphics), and no additional video card.

This is with the latest weekly netinst iso for buster (10/Jun/2019)
It also happened with the one of 27/May. I don't know if this is a
regression from previous versions (buster or stretch) since I didn't test them
with that hardware

Regards,

[1] https://framapic.org/lbQZBKAocMy9/wpvIcPEyMzIY.jpg (URL valid 1 year)



-- Package-specific info:

Boot method: CD
Image version: 
https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso
Date: 

Machine: ASUS Prime B450M-A with AMD Athlon 200GE CPU (with
Partitions: 


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

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

Comments/Problems:




-- 

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

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

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="9 (stretch) - installer build 20170615"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux debian 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2 (2017-06-12) x86_64 
GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 82946GZ/PL/GL Memory 
Controller Hub [8086:2970] (rev 02)
lspci -knn: Subsystem: Intel Corporation 82946GZ/PL/GL Memory Controller 
Hub [8086:2970]
lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation 82946GZ/PL/GL PCI 
Express Root Port [8086:2971] (rev 02)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation 
82946GZ/GL Integrated Graphics Controller [8086:2972] (rev 02)
lspci -knn: Subsystem: Micro-Star International Co., Ltd. [MSI] Device 
[1462:7336]
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation NM10/ICH7 Family 
High Definition Audio Controller [8086:27d8] (rev 01)
lspci -knn: Subsystem: Micro-Star International Co., Ltd. [MSI] Device 
[1462:7336]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel
lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation NM10/ICH7 Family 
USB UHCI Controller #1 [8086:27c8] (rev 01)
lspci -knn: Subsystem: Micro-Star International Co., Ltd. [MSI] Device 
[1462:7336]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: Kernel modules: uhci_hcd
lspci -knn: 00:1d.1 USB controller [0c03]: Intel Corporation NM10/ICH7 Family 
USB UHCI Controller #2 [8086:27c9] (rev 01)
lspci -knn: Subsystem: Micro-Star International Co., Ltd. [MSI] Device 
[1462:7336]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: Kernel modules: uhci_hcd
lspci -knn: 00:1d.2 USB controller [0c03]: Intel Corporation NM10/ICH7 Family 
USB UHCI Controller #3 [8086:27ca] (rev 01)
lspci -knn: Subsystem: Micro-Star International Co., Ltd. [MSI] Device 
[1462:7336]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: Kernel modules: uhci_hcd
lspci -knn: 00:1d.3 USB controller [0c03]: Intel Corporation NM10/ICH7 Family 
USB UHCI Controller #4 [8086:27cb] (rev 01)
lspci -knn: Subsystem: Micro-Star International Co., Ltd. [MSI] Device 
[1462:7336]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: Kernel modules: uhci_hcd
lspci -knn: 00:1d.7 USB controller [0c03]: Intel Corporation NM10/ICH7 Family 
USB2 EHCI Controller [8086:27cc] (rev 01)
lspci -knn: Subsystem: Micro-Star International Co., Ltd. [MSI] Device 
[1462:7336]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge 
[8086:244e] (rev e1)
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GB/GR (ICH7 
Family) LPC Interface Bridge [8086:27b8] (rev 01)
lspci -knn: Subsystem: Micro-Star International Co., Ltd. [MSI] Device 
[1462:7336]
lspci -knn: 00:1f.2 IDE 

Bug#930506: conf.d in /etc skipped

[Daniel Baumann]

Package: netdata
Version: 1.15.0-1

(as a reminder)

Starting a couple of versions back, due to the reshuffeling of the
packaging files, it appears that some/most conf.d "example/default"
files (they're not strictly needed as defaults are automatically used if
the files are missing) are skipped. they should be re-included.

Regards,
Daniel

Bug#930505: check for display problems with 'summary gauges'

[Daniel Baumann]

Package: netdata
Version: 1.15.0-1
Severity: normal

(as a reminder)

Starting with 1.15.0-1, all but the middle gauges in the 'System
Overview' are showing an ugly white background. need to check if it's an
upstream regression or caused on our side, needs fixing anyhow.

Regards,
Daniel

Bug#930504: skip 'sign-in' note

[Daniel Baumann]

Package: netdata
Version: 1.15.0-1
Severity: minor

(as a reminder)

when opening netdata (for the first time only?), it will show at the
bottom a bar with 'sign in for the full feature experience' or something
like that. we shoud disable that, the sign-in button is already quite
present on the top-bar anyway.

Regards,
Daniel

Bug#930469: chromium: Insta-segfault on start

[Michael Gilbert]

control: tag -1 moreinfo

On Thu, Jun 13, 2019 at 5:36 AM Guillem Jover wrote:
>   [23609:23609:0613/102304.872428:FATAL:render_process_host_impl.cc(4060)] 
> Check failed: render_process_host->InSameStoragePartition( 
> BrowserContext::GetStoragePartition(browser_context, site_instance, false )).

This is the error.  FATAL errors in chromium intentionally abort
execution.  That output should have also been seen without --debug,
although upstream's handling of FATAL messages can be flaky.

My best guess is that there is an incompatibility with profiles
created before 75.  If you start with --temp-profile, does that avoid
the problem?

Best wishes,
Mike

Bug#930503: ITP: php-wmerrors -- PHP extension that enhances and customizes handling of PHP errors

[Kunal Mehta]

Package: wnpp
Severity: wishlist
Owner: Kunal Mehta 

* Package name: php-wmerrors
  Version : 2.0.0
  Upstream Author : Tim Starling 
* URL : https://gerrit.wikimedia.org/g/mediawiki/php/wmerrors
* License : MIT/Expat
  Programming Lang: C
  Description : PHP extension that enhances and customizes handling of PHP 
errors

wmerrors allows for customizing how PHP errors are handled and displayed to
the user. It is specifically designed for situations where userland code is
insufficient (e.g. OOM errors), but stacktraces and logging are still needed.

Some more explanation of where PHP's built-in error handling is insufficient
is at . The current
wmerrors development is to get it at feature parity with what HHVM provided.

Bug#930472: lintian: systemd-service-file-missing-install-key shouldn't fire for dbus activated services

[Arnaud Rebillout]

  Hi Chris,

On 6/13/19 11:05 PM, Chris Lamb wrote:
> tags 930472 + moreinfo
> thanks
>
> Hi Arnaud,
>
>> Upstream ships a systemd service file, and a d-bus service file. The
>> rauc daemon is d-bus activated (meaning, it's automatically started by
>> the client when needed).
> […]
>> So, well, I don't know if Lintian is aware of dbus service files that
>> get installed at `/usr/share/dbus-1/` (I'm not familiar with lintian at
>> all). If so, then Lintian could look for a key `SystemdService=` in the
>> d-bus service file, along with `BusName=` in the systemd service file.
> Perhaps I'm missing something but it looks sufficient to not emit this
> tag if the .service file contains a `BusName=` key, no need to look at
> any other files.


I did a bit of reading, but I'm not the d-bus expert, so this is just my
understanding.

1. A d-bus service that wants to "bus-activatable" ships a d-bus service
file in /usr/share/dbus-1 [1]
2. A d-bus service that wants to be started with systemd ships a systemd
service file in /lib/systemd/system, and provides `BusName=`
3. A d-bus service that wants both ships both files, and uses
`SystemdService=` in the d-bus service file, so that d-bus can let
systemd start the service.

Based on that, it seems to me that there's room for d-bus service that
just do number 2: ship a systemd service file, but don't want to be
dbus-activatable, and don't ship a d-bus service file.

Well, that's my understanding, and that's just theory.

Practice now, let me check what's up on my system

  $ ack -l BusName= /lib/systemd/system | wc -l
  27
  $ ack -l BusName= /lib/systemd/system | xargs grep '\[Install\]' | wc -l
  11
  # -> a bit less than 50% of the BusName= services here have an
[Install] section


Now let's see how many of these services have a d-bus service file that
contains `SystemdService=`


  $ c=0
  $ services=$(ack -l BusName= /lib/systemd/system | rev | cut -d/ -f1 |
rev | sort)
  $ for svc in $services; do grep -q -rn "SystemdService=$svc"
/usr/share/dbus-1/ || { echo "$svc ko"; c=$(expr $c + 1); }; done
  $ echo "$c BusName= systemd services don't have a dbus service file
with SystemdService="
  avahi-daemon.service ko
  bluetooth.service ko
  gdm.service ko
  iio-sensor-proxy.service ko
  ModemManager.service ko
  NetworkManager-dispatcher.service ko
  NetworkManager.service ko
  switcheroo-control.service ko
  systemd-hostnamed.service ko
  systemd-importd.service ko
  systemd-localed.service ko
  systemd-logind.service ko
  systemd-machined.service ko
  systemd-timedated.service ko
  14 BusName= systemd services don't have a dbus service file with
SystemdService=

I didn't look into all of them. But avahi proved to be a good example of
a the case number 2. If you look at
usr/share/dbus-1/system-services/org.freedesktop.Avahi.service, you will
see:

  # This service should not be bus activated if systemd isn't running,
  # so that activation won't conflict with the init script startup.
  Exec=/bin/false

So this is a good example of a service that provides `BusName=` and also
requires a Install section in the systemd service file.

What do you think of all of that ?

Cheers,

  Arnaud



[1]: https://dbus.freedesktop.org/doc/system-activation.txt

Bug#930484: e2fsck corrupts sparse files with -E bmap2extent

[Theodore Ts'o]

On Thu, Jun 13, 2019 at 11:19:13PM +0200, Florian Zumbiehl wrote:
> 
> That fixed versions are available in buster and as a backport is of no use
> to anyone walking into this trap who doesn't know that they are about to
> corrupt their files. As far as I am concerned, that is more than enough
> reason to not fix the conversion in stretch--but please, at least make
> e2fsck bail out with an error message when someone asks it to corrupt the
> file system. That should be an easy and low-risk fix, and if you had done
> that when the bug was discovered, you would at least have saved me a lot of
> time, as I amh still trying to figure out what's been corrupted--and as
> noone should be using this version of the code that is almost guaranteed to
> corrupt your data, replacing it with an error message is not a regression
> either.

I'm very sorry that you lost data.

The problem is not the difficulty in backporting the change --- the
fix is really just a one-line change.  Most of the complexity in the
commit is in adding regression test.

The problem is actually making any kind of change to stretch at this
point.  The release team strongly discourages package updates, unless
the bug is ***really*** serious.  This is especially true for packages
like e2fsck which are built into the installer, since taking an
e2fsprogs package involves respinning the installer.

Given how niche the bmap2extent option is, and combine the judgement
that it's highly unlikely that people conservative enough to use
Debian Obsolete^H^H^H^H^H^H^H Stable would be using an exotic e2fsck
option with how many hoops the Debian Release Team makes people doing
stable updates (I feel actively discouraged from going down that
route) and I feel extremely demotatived towards trying to extract out
just the bug reports and backport them to ancient versions of
e2fsprogs.  Red Hat pays masochists vast amounts money to do that.
It's just not sort of thing that volunteers are likely to do, and if
you look at the very small number of packages that are updated to
Debian stretch (not even all security fixes), compared to what Red Hat
releases in its updates, it's just the way life is.

In my mind, this is why Debian Backports exists.  If you want the
latest bug fixes (including one whhich avoids data corruption when
doing off-line shrinks using resize2fs), and/or you are doing anything
at all exotic, my only recommendation is to use the Debian Backports
version of e2fsprogs.

Bottom line, for *this* particular bug (as opposed to the various
resize2fs shrink fixes) preparing an update to 1.43.4-2 is pretty
simple.  And if I had any optimism that the Release Team would be
willing to take a very late update to Debian Stretch at the point when
it's just about become oldstable, I might even be willing to do the
upload.  But it's not something where I'm feeling particularly
motivated to convince the release team that this is a change they
should be taking, and respinning the Stretch installer at this point.

Best regards,

- Ted

Bug#807471: [kde-config-telepathy-accounts] Jabber configuration unusable

[John Scott]

On Mon, 4 Jan 2016 16:00:11 +0100 =?UTF-8?Q?Luc_B=c3=a9gault?= 
 wrote:
> You can close this bug, I was missing the telepathy-gabble package.
> Sorry for the inconvenience.
I just ran into this issue too, and I think it should be made a Depends or 
Recommends of the package seeing as it's needed. Thanks for reporting it.

Bug#930502: htop: Please support new libnl hooks

[Shawn Landden]

Package: htop
Version: 2.2.0-1+b1
Severity: wishlist

Htop now includes metrics from libnl, as described in this talk 
https://hisham.hm/htop/

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

Please enable these new features.


http://hisham.hm/htop/index.php?page=downloads


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

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

Versions of packages htop depends on:
ii  libc6 2.28-10
ii  libncursesw6  6.1+20181013-2
ii  libtinfo6 6.1+20181013-2

htop recommends no packages.

Versions of packages htop suggests:
ii  lsof4.91+dfsg-1
ii  strace  4.26-0.2

-- no debconf information

Bug#803119: [Debian-rtc-admin] prosody config, status update

[gustavo panizzo]

On Thu, Jun 13, 2019 at 02:50:25PM +0200, Jonas Smedegaard wrote:

Quoting gustavo panizzo (2019-06-13 13:08:52)

I've been working on how to maintain and update the prosody config


Great!



this is my current attempt using puppet and the module Victor
suggested

[...]

My goal for the first iteration is to have the patch merged by DSA so
we can have a way to deploy changes in the service easily and
auditable,


Your previous draft tracked plain configfiles, and you've [questioned]
the need for us using Puppet.  What changed?  Did I miss some
conversation?

[questioned]: 
https://alioth-lists.debian.net/pipermail/debian-rtc-team/2019-May/000112.html



I thought more about it

we'll need more from DSA to administer the service, for example sudo to
prosody user to further troubleshoot issues when they arise, list users
(how to enable http_uploads without knowing that?)

DSA uses puppet and takes care of patching, takes care of ssl
certificates, backups, monitoring, etc.

Using puppet is a way (IMHO) to have a closer relationship with DSA, so
it should make easier the outgoing relationship/maintenance.




afterwards (help welcomed!) I'll add anti-spam measures and
http_uploads :)

reviews of the MR are very much welcomed


I am not familiar with Puppet so cannot help review that.

It seems to me noone else in the team is familiar with it either -
including Victor who wrote previously that he has "no idea how to test
this and see what the result would be."



I tested the code in my prosody server, I can replicate the current
config, however is true that is not a 100% equal test.
I was expecting Victor the help with the review and then of course DSA
will review the patch.
After that, changing features of the service is just adding key =>
values in puppet code


For urgent fixing the current setup it is enough that one person (you,
Gustavo?) is capable of administrating the configuration, but it is
quite relevant to understand if one specific approach is the only one
available to us, or if we have choices then take into account how many
of us are able to handle different approaches.



The current setup is not versioned, there is no way to audit if someone
made a change, there is no way to rollback changes.

Before doing anything else we need to put the configuration
under git and automate the deploy so there are no more manual changes

Regarding on how to drive the future changes, I'm open to ansible and I
can help with the ongoing maintenance of it but I won't make the initial
implementation as I'm not as confident with ansible as I'm with puppet ATM

TL;DR 


I feel comfortable with both approaches, Makefile and Puppet. I
personally think puppet is cleaner and more future-proof.
If as a team we choose one of them I'll stick to it, if someone else writes a
clean ansible deployment, and we agree to it, I'll help maintaining it in the 
future.

I'm pretty much open to any *proper* way to maintain the service we
agree as a team. I wrote something for the two I'm the most comfortable with 


--
IRC: gfa
GPG: 0x27263FA42553615F904A7EBE2A40A2ECB8DAD8D5
OLD GPG: 0x44BB1BA79F6C6333

Bug#930270: mu-editor: debugger broken

[Nick Morrott]

Severity of this bug increased to 'important' to reflect the fact that the 
provision of a working Python 3 debugger is a key component of mu-editor.

Bug#930501: Backport VMW_PVRDMA PPN64 patch

[Adit Ranadive]

Package: src:linux
Version: 4.19.37-3
Severity: wishlist

Dear Maintainer,

Can this kernel patch [1] for VMW_PVRDMA be backported to Debian 10 and later?
This would allow larger sized Debian VMs to use PVRDMA device correctly.

Here is the commit log:

commit 8aa04ad3b39396e315b23448c56d5465200fa777
Author: Adit Ranadive 
Date: Sat Jan 26 05:09:36 2019 +

RDMA/vmw_pvrdma: Support upto 64-bit PFNs

Update the driver to use the new device capability to report 64-bit UAR
PFNs.

Thanks,
Adit

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8aa04ad3b39396e315b23448c56d5465200fa777


-- Package-specific info:
** Version:
Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-3 (2019-05-15)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 
root=UUID=9b0eb070-17d5-4e5d-98ef-fe640c663c5f ro quiet

** Not tainted

** Kernel log:
[1.862333] sd 0:0:0:0: [sda] Mode Sense: 61 00 00 00
[1.862454] sd 0:0:0:0: [sda] Cache data unavailable
[1.862455] sd 0:0:0:0: [sda] Assuming drive cache: write through
[1.865538]  sda: sda1 sda2 < sda5 >
[1.866314] sd 0:0:0:0: [sda] Attached SCSI disk
[1.896204] sr 3:0:0:0: [sr0] scsi3-mmc drive: 1x/1x writer dvd-ram cd/rw 
xa/form2 cdda tray
[1.896206] cdrom: Uniform CD-ROM driver Revision: 3.20
[1.896616] sr 3:0:0:0: Attached scsi CD-ROM sr0
[2.016689] usb 2-1: New USB device found, idVendor=0e0f, idProduct=0003, 
bcdDevice= 1.03
[2.016691] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[2.016692] usb 2-1: Product: VMware Virtual USB Mouse
[2.016693] usb 2-1: Manufacturer: VMware
[2.038438] hidraw: raw HID events driver (C) Jiri Kosina
[2.046691] usbcore: registered new interface driver usbhid
[2.046692] usbhid: USB HID core driver
[2.048214] input: VMware VMware Virtual USB Mouse as 
/devices/pci:00/:00:11.0/:02:00.0/usb2/2-1/2-1:1.0/0003:0E0F:0003.0001/input/input5
[2.048360] hid-generic 0003:0E0F:0003.0001: input,hidraw0: USB HID v1.10 
Mouse [VMware VMware Virtual USB Mouse] on usb-:02:00.0-1/input0
[2.099584] tsc: Refined TSC clocksource calibration: 2194.839 MHz
[2.099627] clocksource: tsc: mask: 0x max_cycles: 
0x1fa32779500, max_idle_ns: 440795235982 ns
[2.099680] clocksource: Switched to clocksource tsc
[2.163481] usb 2-2: new full-speed USB device number 3 using uhci_hcd
[2.281146] PM: Image not found (code -22)
[2.346450] usb 2-2: New USB device found, idVendor=0e0f, idProduct=0002, 
bcdDevice= 1.00
[2.346451] usb 2-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[2.346452] usb 2-2: Product: VMware Virtual USB Hub
[2.363522] hub 2-2:1.0: USB hub found
[2.370440] hub 2-2:1.0: 7 ports detected
[2.478608] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: 
(null)
[4.384855] systemd[1]: Inserted module 'autofs4'
[4.580579] 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)
[4.580608] systemd[1]: Detected virtualization vmware.
[4.580612] systemd[1]: Detected architecture x86-64.
[4.592363] systemd[1]: Set hostname to .
[5.360189] systemd[1]: Listening on initctl Compatibility Named Pipe.
[5.360323] systemd[1]: Listening on Journal Audit Socket.
[5.365038] systemd[1]: Created slice User and Session Slice.
[5.365261] systemd[1]: Set up automount Arbitrary Executable File Formats 
File System Automount Point.
[5.365536] systemd[1]: Created slice system-getty.slice.
[5.365607] systemd[1]: Listening on fsck to fsckd communication Socket.
[5.550458] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
[5.714465] systemd-journald[397]: Received request to flush runtime journal 
from PID 1
[6.430087] audit: type=1400 audit(1559010294.601:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oopslash" 
pid=433 comm="apparmor_parser"
[6.437211] audit: type=1400 audit(1559010294.609:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=436 
comm="apparmor_parser"
[6.437525] audit: type=1400 audit(1559010294.609:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=436 comm="apparmor_parser"
[6.46] audit: type=1400 audit(1559010294.633:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" 
pid=463 comm="apparmor_parser"
[6.490391] audit: type=1400 audit(1559010294.661:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=464 comm="apparmor_parser"
[6.521883] ACPI: AC Adapter [ACAD] (on-line)
[6.699438] audit: 

Bug#930500: ITP: intel-undervolt -- tool for undervolting Intel CPUs

[Stephan Lachnit]

Package: wnpp
Severity: wishlist
Owner: Stephan Lachnit 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: intel-undervolt
  Version : 1.6
  Upstream Author : kitsunyan 
* URL : https://github.com/kitsunyan/intel-undervolt
* License : GPL-3
  Programming Lang: C
  Description : tool for undervolting Intel CPUs

 intel-undervolt is a tool for undervolting CPUs,
 working with Intel CPUs since Generation Haswell.
 It can also change power and temperature limits.
 Note: undervolting can cause stability issues

I think this is a useful tool for users where power-
consumption matters. This include for example laptops
or servers which run permanently.
Although there are packages which can limit power
consumption, for example powercap, I haven't found
any packages which can read or change voltages.

I already started packaging, but there is still some
things I have to figure out, since this is my first
debian package. I plan to maintain this package
publicly on github: (debian branch)
https://github.com/stephanlachnit/intel_undervolt_deb




-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEu0Wws/9WG9vUXuips1tJ6l1WPv4FAl0C3S4ACgkQs1tJ6l1W
Pv6eaxAAh9sAjB7apEYfGosygtmXVp58Rt5WJhP7dTIx1MCaFJ0NskA/I1UUKK8R
B3UCQLiZKTNwFhJmwrSkZO3u4fhyeAkRD/4w5+TNAaxZABHlCvRwlWz0PxIjfiaj
1uvLHvcK11TV6rcj0ya3IjKHS0kV5eXqrFyKs/0NlXy09BWXd/MtxFMzWfV6IwH5
1vcho74FQq9fY5IUkUDIbgr/IxAlRuA35p4iKqGLOOZ7du+BhBGU4k+5zrB+Ec4K
z06UdBXikYplBTmeyrLavLqDJaxFrF2xgrf6eEC4o2OYcp6mE+NJlAPu86XTAujP
TBio3BmIbEKQeC3QmDb5mtaam147iXTkoNx1vZzjZgeCgm4aaGUOPHPp/bmDFa35
llHNeWUkXYSKRh9JLQqTiD7yzhUq6zXYN3H4QQx8lnyGzxcVvOxXxDUcQpCNP8SN
JEBnimITxKn0SQetjbrJhNUCzW3/h/rJ8rCLJ9cEtPrppsebENLOwh/ZQ0Lorl+n
CEXV+ZQdAkfRZqKmzLwlMM4okcLuDUpmz1ME+DK0BJOn6UdOxYCONui9RAeBOmp/
TEs3CZ6GrKIPrw9I34qsjiBylX6mXE667lLsw71pQ6AaoixkwfXtNOHgYffGaDUW
G3Pk+61u9+Hl3FwqWJsSFdkp0gA2dh23q1tZRGyDfXGJDdd98NE=
=82kQ
-END PGP SIGNATURE-

Bug#842676: 1000 diamond

[rang ajg]

rang7078...@gmail.com

Bug#930495: My bad

[Michael Reed]

After reviewing a stretch system I see that I've mischaracterized the
issue.  Stretch has postgresql-9.6-postgis-2.3 and
postgresql-9.6-postgis-2.3-scripts which are analogous to buster's v11
packages, including being recommendations rather than depends.  My
notes don't say anything about me manually installing these but I must
have.

This is a weird situation though, with the postgis extension not being
in the postgis package, and the package instead having some utilities
only tangentially related to the extension.

Perhaps what is needed is a meta package (like postgresql) so someone
can install the extension once and have it upgraded across releases.
The stuff currently in the postgis package should be moved to an
optional postgis-utilities package (recommended by, but not a dependant
of the meta package).

Bug#930473: bsdgames: New wtf acronym makes no sense

[Salvo Tomaselli]

I'd go for fsck or f*ck

Best

Il giorno gio 13 giu 2019 alle ore 13:30 Fabian Greffrath
 ha scritto:
>
> Salvo Tomaselli wrote:
> > -WTF{what,where,who,why} the fuck
> > +WTFwhere's the food
>
> It's understandable that this was introduced to avoid using the f-word.
> How about replacing it with "frick" or "fsck" instead?
>
>  - Fabian
>
>


-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

http://ltworf.github.io/ltworf/

Bug#930134: Please package new upstream version

[Jonas Meurer]

Thomas Goirand:
>>> Also, the current OpenStack version
>>> needs 1.4.1, so uploading 2.0.0 to Experimental would break it.
>>
>> Mh, but the version in Debian is 1.0.0, so that doesn't work for current
>> OpenStack version either, right? Mailman3 would be fine with any version
>> newer than 1.0.0, so 1.4.1 would be sufficient.
> 
> Falcon 1.4.1 requires python3-mimeparse (>= 1.5.2), which isn't packaged
> in Debian. Can you fill a bug against it so that it gets upgraded in
> Experimental as well? Otherwise, I wont be able to do the work.

Sure, I did this now: https://bugs.debian.org/930499

The package seems rather unmaintained, though. So I assume that one of
us needs to take care of it. But let's wait a bit, maybe I'm mistaken ;)

Cheers
 jonas




signature.asc
Description: OpenPGP digital signature

Bug#924961: [Mailman-Developers] Re: How strict are the dependencies on the django-compressor related backends?

[Jonas Meurer]

Hi Christian,

(I removed some more addresses from the list of recipients as it seemed
appropriate.)

Christian Ehrhardt:
> [...]
> 
>> I think this is perfectly fine and I don't see much benefit in combining
>> the CSS and JS files at build-time. It would allow to drop the
>> django-compressor dependency but with the cost of more heavy build-time
>> adjustments that need to be maintained in future.
> 
> I agree, the extra gain by this would be minimal at a rather high
> maintenance cost.

Great that we agree here :)

>> So I'm happy to now have a solution to drop both node-less and sassc
>> from runtime dependencies in the Debian package. Thanks to everyone for
>> their input on this topic.
> 
> Thank you so much!
> 
> I think that also eases the maintenance of a live mailman deployment having
> much less complex components installed.
> 
> I understand that this won't be for Buster.
> Just curious for related Ubuntu planning - are you planning to do an
> upload to experimental ahead of time or are you waiting until Buster
> is released?

I'll probably wait until Buster release before uploading the new
packages. I pushed the changes the packaging repos now, though. So if
you're curious, you can take a look:

https://salsa.debian.org/mailman-team/hyperkitty
https://salsa.debian.org/mailman-team/mailman-suite

What's your plans for Ubuntu? Would it help to have the changes uploaded
to experimental? If so, then we certainly could do this.

Cheers
 jonas



signature.asc
Description: OpenPGP digital signature

Bug#930484: e2fsck corrupts sparse files with -E bmap2extent

[Florian Zumbiehl]

Hi,

> It's an unfortunate bug, but we've lived with it for about ten years,
> and it was only noticed in 2017.  The reality is very few people
> actually try to convert an indirect mapped file system the new
> extent-mapped system, because you get much more of the benefits of
> using a more modern version of ext4 by doing a backup, reformat, and
> restore of the file system.
> 
> Given that so few people have noticed, I don't believe this qualifies
> as even "important", since doing the conversion is not a fundamental
> aspect of e2fsck, so it doesn't qualify as a significant impact on the
> usability of the package.  For similar reasons, I don't believe the
> release team would agree to a new release of e2fsprogs to stretch ---
> especially since (a) it's fixed in buster, (b) the fix is also
> available in stretch-backports, and (c) in three weeks, Stretch will
> become oldstable and Buster will become the new stable release of
> Debian.

Now, I would agree that the *functionality* isn't important, but what I
don't agree with is that a bug that silently corrupts files isn't.

For one, you write that the bug was only noticed in 2017. But really, the
bug was only *found* in 2017--I doubt you have any idea how many people
*noticed* the bug, that is to say, its effects, but weren't able to figure
out what the cause was? If a bug just makes fsck crash, that's bad, but at
least the data is still fine. If a bug destroys the filesystem, that's bad,
but at least you notice, do a restore, and everything is fine.

But this corrupts files in a way that you don't necessarily notice: fsck
doesn't complain, it often will corrupt few enough files that you don't
notice immediately, once you do notice, you may not make the connection
that that conversion that you did possibly months or years ago was the
reason, and you may not have old enough backups anymore to restore from or
to compare against. So, not only do you not know how many people noticed
effects of the bug but had no clue what the cause was, you know even less
how many people have corrupted and are corrupting their files and have yet
to find out.

That fixed versions are available in buster and as a backport is of no use
to anyone walking into this trap who doesn't know that they are about to
corrupt their files. As far as I am concerned, that is more than enough
reason to not fix the conversion in stretch--but please, at least make
e2fsck bail out with an error message when someone asks it to corrupt the
file system. That should be an easy and low-risk fix, and if you had done
that when the bug was discovered, you would at least have saved me a lot of
time, as I am still trying to figure out what's been corrupted--and as
noone should be using this version of the code that is almost guaranteed to
corrupt your data, replacing it with an error message is not a regression
either.

Using the backport for the conversion, doing a dump-and-restore instead, or
waiting until buster are all perfectly fine solutions for the problem of
converting the filesystem. But silently corrupting files and hoping the
user will notice is not a sensible solution for letting the user know that
they should not be using the e2fsck in stretch to do the conversion--IMO.

Regards, Florian

Bug#930499: Please package new upstream release

[Jonas Meurer]

Package: src:python-mimeparse
Version: 0.1.4-3.1
Severity: normal

Hello,

there's newer upstream releases of python-mimeparse, the latest one
being 1.6.0. Do you have plans to update the packages accordingly?
Newer versions of python-falcon requires python3-mimeparse (>= 1.5.2),
and python-falcon itself needs to be updated for newer OpenStack and
Mailman3 versions.

Would be really nice to get a newer python-mimeparse package into
Debian.

Cheers
 jonas

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

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

Bug#930498: Enabling VMware PVRDMA driver

[Adit Ranadive]

Package: linux-image-amd64
Version: 5.0.0-trunk
Severity: important

Hi,

Can the VMware Paravirtual RDMA driver be enabled by default in the next 
Debian release? The config option is CONFIG_INFINIBAND_VMWARE_PVRDMA=m.
This would allow Debian VMs to be deployed easily for virtual RDMA use.

Thanks,
Adit

Bug#893572: tracker.debian.org: Debian Maintainer display: [dm] links empty, should be uppercase and use parentheses

[Raphael Hertzog]

Hi,

On Thu, 13 Jun 2019, Herbert Fortes wrote:
> I found where to make the change. But the information about
> who gave the permission I do not know where it is at *debian.org.
> 
> In distro_tracker/vendor/debian/rules.py file:
> 
> _add_dm_entry function - extra.append({'display': 'dm'})
> 
> 'link': "https://ftp-master.debian.org/dm.txt;
> 'description': "Debian Maintainer upload allowed by Andreas Henriksson"

In https://ftp-master.debian.org/dm.txt behind each package, there's a
fingerprint between parenthesis. This fingerprint is the fingerprint
of the key who signed the addition of the DM right. So if you can map
that back to a name, then you're good.

There's some code doing that already with the help of the GPG keyring
that we have configured, see verify_signature() in
distro_tracker/core/utils/__init__.py (in particular
ctx.get_key(...)).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#930497: multi-arch: please depend on erlang-base{,-hipe}:any to enable amd64 erlang+elixir on i386 debian

[Tomas Janousek]

Source: elixir-lang
Version: 1.7.4-0.1
Severity: wishlist
Tags: patch

It's not currently possible to apt install elixir erlang:amd64 on an i386 
system, or
apt install elixir erlang:i386 on an amd64 system. But the elixir package only
contains arch-independent beams and shell scripts, so it should be possible to
do so. The erlang packages were recently made Multi-Arch: allowed [1] and the
only missing piece is to make elixir explicitly depend on erlang-base:any |
erlang-base-hipe:any, which expresses the fact that elixir doesn't use any
arch-specific bits of erlang. For more info, see [2]. I'm attaching a patch
that does exactly this.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926241
[2]: 
https://wiki.ubuntu.com/MultiarchSpec#Extended_semantics_of_per-architecture_package_relationships

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

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

-- 
Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, http://work.lisk.in/
diff -up ./debian/control.multiarch ./debian/control
--- ./debian/control.multiarch	2019-06-13 22:39:27.704336401 +0200
+++ ./debian/control	2019-06-13 22:39:48.860510119 +0200
@@ -18,7 +18,7 @@ Homepage: http://elixir-lang.org/
 
 Package: elixir
 Architecture: all
-Depends: erlang-base (>= 1:19) | erlang-base-hipe (>= 1:19),
+Depends: erlang-base:any (>= 1:19) | erlang-base-hipe:any (>= 1:19),
  ${misc:Depends}
 Description: functional meta-programming aware language
  Elixir is a functional meta-programming aware language intended primarily for

Bug#930496: ktexteditor FTCBFS: unsatisfiable perl dependency

[Helmut Grohne]

Source: ktexteditor
Version: 5.54.0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability ftcbfs

ktexteditor fails to satisfy its cross build dependencies, because its
dependency on the host architecture perl is unsatisfiable. I couldn't
figure out what this dependency is being used for and the build
architecture perl is build-essential anyway. Certainly dropping it won't
break native builds. ktexteditor is also affected by the qhelpgenerator
mess and needs a build dependency on qttools5-dev to cross build. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru ktexteditor-5.54.0/debian/changelog 
ktexteditor-5.54.0/debian/changelog
--- ktexteditor-5.54.0/debian/changelog 2019-01-17 23:27:20.0 +0100
+++ ktexteditor-5.54.0/debian/changelog 2019-06-13 21:51:06.0 +0200
@@ -1,3 +1,12 @@
+ktexteditor (5.54.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Drop redundant perl from Build-Depends.
++ Add missing qttools5-dev to Build-Depends (see #915122).
+
+ -- Helmut Grohne   Thu, 13 Jun 2019 21:51:06 +0200
+
 ktexteditor (5.54.0-1) unstable; urgency=medium
 
   * New upstream release (5.52.0).
diff --minimal -Nru ktexteditor-5.54.0/debian/control 
ktexteditor-5.54.0/debian/control
--- ktexteditor-5.54.0/debian/control   2019-01-17 23:27:20.0 +0100
+++ ktexteditor-5.54.0/debian/control   2019-06-13 21:51:06.0 +0200
@@ -22,12 +22,12 @@
libkf5syntaxhighlighting-dev (>= 5.54.0~),
libqt5sql5-sqlite,
libqt5xmlpatterns5-dev (>= 5.8.0~),
-   perl,
pkg-config,
pkg-kde-tools (>= 0.15.15ubuntu1~),
qtbase5-dev (>= 5.9.0~),
qtdeclarative5-dev (>= 5.9.0~),
qtscript5-dev (>= 5.7.0~),
+   qttools5-dev,
qttools5-dev-tools (>= 5.4),
xauth,
xvfb,

Bug#930492: pkg-config: Broken i686-w64-mingw32-pkg-config and x86_64-w64-mingw32-pkg-config

[Helmut Grohne]

On Thu, Jun 13, 2019 at 09:19:34PM +0200, Stefan Weil wrote:
> recent versions of pkg-config fail to work in cross builds targetting Windows,
> so such cross builds no longer work for many users.
> 
> Error message when calling i686-w64-mingw32-pkg-config or 
> x86_64-w64-mingw32-pkg-config:
> 
> Please install dpkg-dev to use pkg-config when cross-building
> 
> A simple fix just removes the problematic lines (which I think were 
> introduced recently):

I guess I'm responsible for this. Removing the lines makes the user
experience bad when dpkg-dev is not installed.

> A better fix would skip the multiarch check for *-w64-mingw32 as I don't 
> expect

Why do you think so? The cross wrapper is intended to be used with
Debian architectures. Using it beyond that way is out of scope. I argue
that placing a symlink i686-w64-mingw32-pkg-config -> crosswrapper is a
bug in itself. A different cross wrapper should be used for things that
are not Debian architectures. As such I propose reassigning the bug to
mingw-w64-tools. Any objections to doing so?

> that Debian will add multiarch support for *-w64-mingw32 in the near future.

I actually looked into this and attempted doing it (though I couldn't
figure out how to make the toolchain bootstrap work similar enough to
Linux). I think that doing so would be a very good idea, because it
simplifies cross building in a number of ways: The current way we do
mingw in Debian is repeating the ia32-libs mess. Every package that is
needed for mingw incurs a new binary package (and a trip through NEW).
Instead, we could have a Debian architecture (which would never be a
"full" or release architecture) and cross build packages for that
architecture. Doing so could get us rid of a pile of packages (such as
libz-mingw-w64*, libgpg-error-mingw-w64*, libgcrypt-mingw-w64*, ...) and
provide lots of libraries at once instead. If you are interested in
pursuing this, contact debian-cross@l.d.o.

Helmut

Bug#930495: Recommends should be Depends

[Michael Reed]

Package: postgis
Version: 2.5.1+dfsg-1

The PostGIS extension for postgresql has apparently been moved out of
the PostGIS package.  One must now install postgresql-11-postgis-2.5
and postgresql-11-postgis-2.5-scripts to get the needed functionality.

These packages are only Recommends though, so someone upgrading from
stretch with postgis package to buster will not actually get the
postgis extension, causing the pg_upgradecluster to fail spectacularly.

It seems like postgis should depend on both postgresql-11-postgis-2.5
and postgresql-11-postgis-2.5-scripts.

Bug#930487: lintian: speed up test suite CI

[Chris Lamb]

Felix Lechner wrote:

> For Lintian, however, I would prefer to upload the test packages
> separately to Debian's regular build infrastructure.

Hm, I think you are talking at cross-purposes to Dmitry here. Nobody
was suggesting we upload the test packages to Debian; that would
surely be impossible.

Gitlab has a support for saving various parts of a successful build
for the next one. I believe the idea is that we would build the test
packages and then push them to this cache re-using them on any subsequent
test runs. People often use this to cache "pip" Python dependencies
but I don't see any obvious reason why we can't use it here.

(This is indexed by some cache key so that changing the testsuite
itself could/would rebuild the packages as appropriate.)


Regards,

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

Bug#930445: Info received (Bug#930445: [debian-mysql] Bug#930445: ITP: odbc-mariadb -- ODBC driver for MariaDB)

[Bernhard Schmidt]

Control: tags -1 pending

mariadb-connector-odbc is now in NEW

https://ftp-master.debian.org/new/mariadb-connector-odbc_3.1.1-1.html

Bug#930494: unblock: rootskel/1.131

[Samuel Thibault]

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

Hello,

As mentioned in #930493, I have re-measured the minimum memory
contraints of d-i, and the g-i part is in rootskel, as attached here,
could you unblock it?

unblock rootskel/1.131

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

Kernel: Linux 5.1.0 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru rootskel-1.129/debian/changelog rootskel-1.131/debian/changelog
--- rootskel-1.129/debian/changelog 2019-04-20 02:24:53.0 +0200
+++ rootskel-1.131/debian/changelog 2019-06-13 21:28:44.0 +0200
@@ -1,3 +1,24 @@
+rootskel (1.131) unstable; urgency=medium
+
+  * Team upload
+  * Remove spurious files.
+
+ -- Samuel Thibault   Thu, 13 Jun 2019 21:28:44 +0200
+
+rootskel (1.130) unstable; urgency=medium
+
+  * Team upload
+
+  [ Cyril Brulebois ]
+  * Remove Christian Perrier from Uploaders, with many thanks for all
+his contributions over the years! (Closes: #927486)
+
+  [ Samuel Thibault ]
+  * src/lib/debian-installer.d/S60frontend: Update gtk memory limit, now with
+encryption support which eats a lot.
+
+ -- Samuel Thibault   Thu, 13 Jun 2019 20:39:11 +0200
+
 rootskel (1.129) unstable; urgency=medium
 
   * S50entropy-source: start haveged when appropriate, to avoid entropy
diff -Nru rootskel-1.129/debian/control rootskel-1.131/debian/control
--- rootskel-1.129/debian/control   2019-03-08 15:21:53.0 +0100
+++ rootskel-1.131/debian/control   2019-06-02 13:29:14.0 +0200
@@ -2,7 +2,7 @@
 Section: debian-installer
 Priority: standard
 Maintainer: Debian Install System Team 
-Uploaders: Colin Watson , Bastian Blank 
, Christian Perrier , Steve McIntyre 
<93...@debian.org>
+Uploaders: Colin Watson , Bastian Blank 
, Steve McIntyre <93...@debian.org>
 Build-Depends: debhelper (>= 9), dpkg-dev (>= 1.7.0), linux-libc-dev (>= 
2.6.38) [linux-any]
 Vcs-Browser: https://salsa.debian.org/installer-team/rootskel
 Vcs-Git: https://salsa.debian.org/installer-team/rootskel.git
diff -Nru rootskel-1.129/src/lib/debian-installer.d/S60frontend 
rootskel-1.131/src/lib/debian-installer.d/S60frontend
--- rootskel-1.129/src/lib/debian-installer.d/S60frontend   2017-02-11 
22:24:40.0 +0100
+++ rootskel-1.131/src/lib/debian-installer.d/S60frontend   2019-06-02 
13:28:52.0 +0200
@@ -31,14 +31,14 @@
case "$(archdetect)" in
# Tested with Uyghur
powerpc/*|amd64/*)
-   local MEMLIMIT=310 ;;   # is 316864kB, qemu -m 327
+   local MEMLIMIT=766 ;;   # is 783460kB, qemu -m 800
kfreebsd-amd64/*)
# See Bug#783775 for derivation.
local MEMLIMIT=144 ;;   # is 147456kB, qemu -m 256
hurd-i386/*)
local MEMLIMIT=750 ;;   #  qemu -m 750
*)
-   local MEMLIMIT=281 ;;   # is 287732kB, qemu -m 293
+   local MEMLIMIT=534 ;;   # is 546188kB, qemu -m 550
esac
 
if [ $(get_mem) -lt $MEMLIMIT ] ; then

Bug#930484: e2fsck corrupts sparse files with -E bmap2extent

[Theodore Ts'o]

Control: severity -1 normal
Control: fixed -1 1.43.5-1

On Thu, Jun 13, 2019 at 04:09:15PM +0200, Florian Zumbiehl wrote:
> Package: e2fsprogs
> Version: 1.43.4-2
> Severity: critical
> 
> e2fsck potentially moves blocks around in sparse files when running with
> -E bmap2extent, in particular when the blocks are physically adjacent on
> the underlying block device, but have a hole in between in the file.
> ...
>
> With version 1.44.5-1~bpo9+1, the test above does not produce corruption on
> my system, but I have not investigated whether that is just coincidence or
> because the bug has been fixed. As this silently corrupts files, I would
> think it should get some fix in stretch, and be it by disabling the
> feature.

The bug was fixed in e2fsprogs 1.43.5, via the fix:

commit 855c2ecb21d1556c26d61df9b014e1c79dbbc956
Author: Darrick J. Wong 
Date:   Wed May 24 21:56:36 2017 -0400

e2fsck: fix sparse bmap to extent conversion

When e2fsck is trying to convert a sparse block-mapped file to an extent
file, we incorrectly merge block mappings that are physically contiguous
but not logically contiguous because of insufficient checking with the
extent we're constructing.  Therefore, compare the logical offsets for
contiguity as well.

Signed-off-by: Darrick J. Wong 
Signed-off-by: Theodore Ts'o 

It's an unfortunate bug, but we've lived with it for about ten years,
and it was only noticed in 2017.  The reality is very few people
actually try to convert an indirect mapped file system the new
extent-mapped system, because you get much more of the benefits of
using a more modern version of ext4 by doing a backup, reformat, and
restore of the file system.

Given that so few people have noticed, I don't believe this qualifies
as even "important", since doing the conversion is not a fundamental
aspect of e2fsck, so it doesn't qualify as a significant impact on the
usability of the package.  For similar reasons, I don't believe the
release team would agree to a new release of e2fsprogs to stretch ---
especially since (a) it's fixed in buster, (b) the fix is also
available in stretch-backports, and (c) in three weeks, Stretch will
become oldstable and Buster will become the new stable release of
Debian.

Feel free to escalate this to the Debain release team but I don't
think this is going to be considered worth their time (or mine) to be
worth a backport of the fix to e2fsprogs 1.43.4-2.

Cheers,

- Ted

Bug#930493: unblock: lowmem/1.47

[Samuel Thibault]

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

Hello,

Now that things have settled down, I have re-measured the minimum memory
contraints of d-i and thus uploaded a new version of lowmem with the
attached changes, could you unblock it?

It can be noted that the minimum have changed quite a lot because I
changed the test a bit: we were not testing with encryption support
previously, and it happens to require quite a lot of memory.

I have also added ignoring a lintian error about missing translations,
since lowmem conditions are precisely when we want to drop translations
:)

unblock lowmem/1.47

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

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

-- 
Samuel
 r: et la marmotte, elle écrit un papier IPDPS
diff -Nru lowmem-1.46/debian/changelog lowmem-1.47/debian/changelog
--- lowmem-1.46/debian/changelog2018-08-28 18:00:17.0 +0200
+++ lowmem-1.47/debian/changelog2019-06-13 20:28:13.0 +0200
@@ -1,3 +1,17 @@
+lowmem (1.47) unstable; urgency=medium
+
+  * Team upload
+
+  [ Cyril Brulebois ]
+  * Remove Christian Perrier from Uploaders, with many thanks for all
+his contributions over the years! (Closes: #927570)
+
+  [ Samuel Thibault ]
+  * Update limits.
+  * source.lintian-overrides: Ignore untranslated templates.
+
+ -- Samuel Thibault   Thu, 13 Jun 2019 20:28:13 +0200
+
 lowmem (1.46) unstable; urgency=medium
 
   * Team upload
diff -Nru lowmem-1.46/debian/control lowmem-1.47/debian/control
--- lowmem-1.46/debian/control  2018-08-10 21:22:39.0 +0200
+++ lowmem-1.47/debian/control  2019-06-02 14:23:59.0 +0200
@@ -2,7 +2,6 @@
 Section: debian-installer
 Priority: optional
 Maintainer: Debian Install System Team 
-Uploaders: Christian Perrier 
 Build-Depends: debhelper (>= 9), dpkg-dev (>= 1.9.0)
 Vcs-Browser: https://salsa.debian.org/installer-team/lowmem
 Vcs-Git: https://salsa.debian.org/installer-team/lowmem.git
diff -Nru lowmem-1.46/debian/source.lintian-overrides 
lowmem-1.47/debian/source.lintian-overrides
--- lowmem-1.46/debian/source.lintian-overrides 2018-08-10 21:22:39.0 
+0200
+++ lowmem-1.47/debian/source.lintian-overrides 2019-06-13 20:28:13.0 
+0200
@@ -1 +1,2 @@
 lowmem source: not-using-po-debconf
+lowmem source: untranslatable-debconf-templates
diff -Nru lowmem-1.46/debian-installer-startup.d/S15lowmem 
lowmem-1.47/debian-installer-startup.d/S15lowmem
--- lowmem-1.46/debian-installer-startup.d/S15lowmem2018-08-10 
21:22:39.0 +0200
+++ lowmem-1.47/debian-installer-startup.d/S15lowmem2019-06-02 
14:21:18.0 +0200
@@ -25,9 +25,9 @@
min=39
;;
amd64)
-   level1=163 # MT=166348, qemu: -m 178
-   level2=163 # MT=166348, qemu: -m 178
-   min=163# MT=166348, qemu: -m 178
+   level1=483 # MT=494300, qemu: -m 550
+   level2=273 # MT=279260, qemu: -m 300
+   min=145# MT=148188, qemu: -m 170
;;
arm|armel|armhf)
# Update needed
@@ -42,9 +42,9 @@
min=18
;;
i386)
-   level1=135 # MT=137688, qemu: -m 145
-   level2=135 # MT=137688, qemu: -m 145
-   min=135# MT=137688, qemu: -m 145
+   level1=386 # MT=394604, qemu: -m 400
+   level2=237 # MT=242628, qemu: -m 250
+   min=109# MT=110956, qemu: -m 120
;;
mips)
# Update needed
@@ -88,11 +88,10 @@
level2=44 # MT=44376, qemu: -m 104
min=30# MT=30040, qemu: -m 90
;;
-   # Update needed
hurd-i386)
level1=499 # qemu: -m 500
level2=409 # qemu: -m 410
-   min=364# qemu: -m 365
+   min=389# qemu: -m 390
;;
*)
level1=64
diff -Nru lowmem-1.46/README lowmem-1.47/README
--- lowmem-1.46/README  2018-08-10 21:22:39.0 +0200
+++ lowmem-1.47/README  

Bug#929405: ITP: pveclib -- power vector library

[Steven Munroe]

yes but distracted by the bug I found with GCC9 (Fedora 30).

I need s work around for that, Then I will update/tag.

On Thu, Jun 13, 2019 at 9:07 AM Gabriel F. T. Gomes <
gabr...@inconstante.net.br> wrote:

> On Wed, 29 May 2019, Gabriel F. T. Gomes wrote:
> >
> >I submitted a pull request [2] upstream to foster this discussion.
> >
> >[...]
> >
> >[2] https://github.com/open-power-sdk/pveclib/pull/71
>
> For the record: this pull request was superseded by pull request #73 [1],
> which has been integrated.
>
> Steve,
>
> You mentioned you had plans to tag pveclib again (as v1.0.1, iirc)?  If
> you still have them, I'll wait for it then sync the source code in Debian.
> Otherwise, I'll add debian/patches for pull requests #73 (and #74).
>
> Please, let me know of your current plans.
>
> Thanks,
> Gabriel
>
> [1] https://github.com/open-power-sdk/pveclib/pull/73
>

Bug#930492: pkg-config: Broken i686-w64-mingw32-pkg-config and x86_64-w64-mingw32-pkg-config

[Stefan Weil]

Package: pkg-config
Version: 0.29-6
Severity: important

Dear Maintainer,

recent versions of pkg-config fail to work in cross builds targetting Windows,
so such cross builds no longer work for many users.

Error message when calling i686-w64-mingw32-pkg-config or 
x86_64-w64-mingw32-pkg-config:

Please install dpkg-dev to use pkg-config when cross-building

A simple fix just removes the problematic lines (which I think were introduced 
recently):

--- /usr/share/pkg-config-crosswrapper.orig  2019-01-27 05:56:33.0 +0100
+++ /usr/share/pkg-config-crosswrapper   2019-03-12 17:28:40.721179639 +0100
@@ -11,10 +11,6 @@
   triplet="${basename%-pkg-config}"
   # Normalized multiarch path if any, e.g. i386-linux-gnu for i386
   multiarch="$(dpkg-architecture -t"${triplet}" -qDEB_HOST_MULTIARCH 
2>/dev/null)"
-  if [ "$?" != 0 ]; then
-  echo "Please install dpkg-dev to use pkg-config when cross-building" >&2
-  exit 1
-  fi
   # Native multiarch path
   native_multiarch="$(cat /usr/lib/pkg-config.multiarch)"
 
A better fix would skip the multiarch check for *-w64-mingw32 as I don't expect
that Debian will add multiarch support for *-w64-mingw32 in the near future.

Best regards
Stefan Weil


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

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

Versions of packages pkg-config depends on:
ii  libc6 2.28-10
ii  libdpkg-perl  1.19.7
ii  libglib2.0-0  2.58.3-2

pkg-config recommends no packages.

Versions of packages pkg-config suggests:
ii  dpkg-dev  1.19.7

-- no debconf information

Bug#912916: Bible Yes, Constitution No! 03-21-53

[santos]

это единственный шанс для вознесения церкви, СЛУЖЕНИЯ восстановления.
https://youtu.be/gfpUwOnpwlM
 

Поколение Иисуса Христа



The voice of restoration, the last entry for the rapture of the disciples of 
Jesus Christ.
2070 Jesus returns
 
 

 74830016

Bug#929450: caml-crush, build-dependencies unsatisfiable on armel

[Peter Green]

On 13/06/19 10:00, Thomas Calderon wrote:

Hi there,

It's unfortunate that OCaml has removed the support for ocamlopt for armel, it 
sounds like CamlCrush will not be able to ship for armel.
Is it required that I create an updated Debian release excluding armel as a 
target or as you said, ftpmaster can just remove the binaries?

Removing the binaries is enough in cases like this, they won't be rebuilt 
until/unless their build-dependencies become available again.

I'm not sure if the binary removal will propagate automatically from unstable 
to testing during the freeze or if one needs to ask the release team for that.

Bug#850280: Handling plymouth default theme with alternatives

[Raphael Hertzog]

Hello Laurent & Aurélien,

On Fri, 06 Jan 2017, Laurent Bigonville wrote:
> > So what would you think of making an alternative of :
> >  /usr/share/plymouth/plymouthd.defaults
> > currently shipped by plymouth ?
> > 
> > This would let desktop-base override the version currently shipped by 
> > plymouth, without the need for plymouth to add a dependency on desktop-base.
> 
> I'm not sure I would use the alternative for the
> /usr/share/plymouth/plymouthd.defaults file.

Unless plymouth grows some other mechanism to override only
the theme, I think it makes a lot of sense... right now plymouth gets
installed by default through desktop-base and there's no good way
for a derivative to override that theme.

For now we added a call to "plymouth-set-default-theme" in desktop-base
but that modifies a conffile...

> Ubuntu is doing something with /usr/share/plymouth/themes/default.plymouth,
> I would go that way maybe (see 
> https://anonscm.debian.org/cgit/collab-maint/plymouth.git/tree/src/main.c#n449).

I believe overriding/diverting the default theme is not sufficient since a
theme is now hardcoded in /usr/share/plymouth/plymouthd.defaults (as
shipped by plymouth).

It would be really nice to a have a proper endorsed solution to this for
derivatives. Up to now, all our theme overrides are made through
desktop-base without modifying anything else, it would be nice if this
could be the case for plymouth as well.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#930487: lintian: speed up test suite CI

[Felix Lechner]

On Thu, Jun 13, 2019 at 8:51 AM Dmitry Bogatov  wrote:
>
> It would be great to ... avoid rebuiling package at every job run.

I would be nice to see how other projects deal with this issue. There
is some support for uploading the test packages separately. [1]

For Lintian, however, I would prefer to upload the test packages
separately to Debian's regular build infrastructure. The test packages
can and do have conflicting build dependencies and architectures.
These conflicts are not addressed currently, and may require separate
chroot build environments. It would be difficult to implement even in
a single bulk package. Debian's infrastructure, on the other hand, is
designed to build the packages.

At the same time, separate uploads would place an undue burden on the
archive's namespace and on the NEW queue. There would also be delays
for new tags, as Lintian may at some point require that tags are
tested. All test packages would have to be in the archive before the
lintian source is uploaded.

Right now, my favorite solution would be for the archive to offer
dependent namespaces for source packages (such as lintian/...). Such
internal packages could be uploaded separately and would not have to
go through the NEW queue. Outside packages could not depend on them,
but they would be installed if their source package requires them.

This idea will likely generate much opposition. Let me just say that I
am not sure my suggestion is worth the effort, or useful for anyone
else.

Kind regards,
Felix

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

Bug#929214: release.debian.org - Add package constraint for cloud images

[Bastian Blank]

Hi

On Wed, Jun 12, 2019 at 08:01:08PM +0200, Bastian Blank wrote:
> On Wed, Jun 12, 2019 at 05:57:00PM +0200, Ivo De Decker wrote:
> > If you create such a package, having a binary per architecture as you
> > describe, should do what you want. It can be added to the list as soon as it
> > is in testing.
> Okay, thank you.

A quick question:

Will britney choke if we list conflicting packages as dependencies?

Something like this:
| Depends: exim4, postfix

Regards,
Bastian

-- 
Death, when unnecessary, is a tragic thing.
-- Flint, "Requiem for Methuselah", stardate 5843.7

Bug#930487: lintian: use GitLab caching of test packages to speed up test suite CI

[Xavier]

Maybe prove parallel execution can help here (--jobs N)

Bug#930490: unblock: exim4/4.92-8

[Andreas Metzler]

forgot the diff ...
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files only in first set of .debs, found in package exim4-daemon-heavy-dbgsym

-rw-r--r--  root/root   
/usr/lib/debug/.build-id/34/a72aedf4830a64e9961936f0a93b3622cea618.debug

Files only in first set of .debs, found in package exim4-daemon-light-dbgsym

-rw-r--r--  root/root   
/usr/lib/debug/.build-id/16/688cb8a676f11335e1024842d2a40f8a46c0e3.debug

Files only in first set of .debs, found in package eximon4-dbgsym
-
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/fa/ceba3b71bca811aa3fbfb78e57ab48cdbf8f82.debug

New files in second set of .debs, found in package exim4-daemon-heavy-dbgsym

-rw-r--r--  root/root   
/usr/lib/debug/.build-id/d5/aaad5b8de78f401c35c3c4bf1df0aa93e70bcc.debug

New files in second set of .debs, found in package exim4-daemon-light-dbgsym

-rw-r--r--  root/root   
/usr/lib/debug/.build-id/0c/787f2ab182ef325414f50a2410be0d7d032c29.debug

New files in second set of .debs, found in package eximon4-dbgsym
-
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/6c/8920f1a04a04ae113141c38137cca0ad2fe624.debug


Control files of package exim4: lines which differ (wdiff format)
-
Depends: debconf (>= 1.4.69) | cdebconf (>= 0.39), exim4-base (<< 
[-4.92-7.1),-] {+4.92-8.1),+} exim4-base (>= [-4.92-7),-] {+4.92-8),+} 
exim4-daemon-light | exim4-daemon-heavy | exim4-daemon-custom, debconf (>= 0.5) 
| debconf-2.0
Version: [-4.92-7-] {+4.92-8+}

Control files of package exim4-base: lines which differ (wdiff format)
--
Installed-Size: [-1623-] {+1624+}
Version: [-4.92-7-] {+4.92-8+}

Control files of package exim4-base-dbgsym: lines which differ (wdiff format)
-
Depends: exim4-base (= [-4.92-7)-] {+4.92-8)+}
Version: [-4.92-7-] {+4.92-8+}

Control files of package exim4-config: lines which differ (wdiff format)

Version: [-4.92-7-] {+4.92-8+}

Control files of package exim4-daemon-heavy: lines which differ (wdiff format)
--
Installed-Size: [-1477-] {+1473+}
Version: [-4.92-7-] {+4.92-8+}

Control files of package exim4-daemon-heavy-dbgsym: lines which differ (wdiff 
format)
-
Build-Ids: [-34a72aedf4830a64e9961936f0a93b3622cea618-] 
{+d5aaad5b8de78f401c35c3c4bf1df0aa93e70bcc+}
Depends: exim4-daemon-heavy (= [-4.92-7)-] {+4.92-8)+}
Version: [-4.92-7-] {+4.92-8+}

Control files of package exim4-daemon-light: lines which differ (wdiff format)
--
Version: [-4.92-7-] {+4.92-8+}

Control files of package exim4-daemon-light-dbgsym: lines which differ (wdiff 
format)
-
Build-Ids: [-16688cb8a676f11335e1024842d2a40f8a46c0e3-] 
{+0c787f2ab182ef325414f50a2410be0d7d032c29+}
Depends: exim4-daemon-light (= [-4.92-7)-] {+4.92-8)+}
Version: [-4.92-7-] {+4.92-8+}

Control files of package exim4-dev: lines which differ (wdiff format)
-
Version: [-4.92-7-] {+4.92-8+}

Control files of package eximon4: lines which differ (wdiff format)
---
Version: [-4.92-7-] {+4.92-8+}

Control files of package eximon4-dbgsym: lines which differ (wdiff format)
--
Build-Ids: [-faceba3b71bca811aa3fbfb78e57ab48cdbf8f82-] 
{+6c8920f1a04a04ae113141c38137cca0ad2fe624+}
Depends: eximon4 (= [-4.92-7)-] {+4.92-8)+}
Version: [-4.92-7-] {+4.92-8+}
diff -Nru exim4-4.92/debian/changelog exim4-4.92/debian/changelog
--- exim4-4.92/debian/changelog 2019-05-07 19:44:23.0 +0200
+++ exim4-4.92/debian/changelog 2019-06-08 17:37:43.0 +0200
@@ -1,3 +1,24 @@
+exim4 (4.92-8) unstable; urgency=low
+
+  * Pulled from exim-4.92+fixes branch:
++ 75_11-GnuTLS-fix-tls_out_ocsp-under-hosts_request_ocsp.patch
+  Fix expansion of $tls_out_ocsp under hosts_request_ocsp.
++ 75_12-GnuTLS-fix-the-advertising-of-acceptable-certs-by-th.patch
+  When tls_verify_certificates was set to a directory 

Bug#930491: unblock: gnutls28/3.6.7-4

[Andreas Metzler]

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

Please unblock package gnutls28. This upload cherry-picks the
recommended fixes[1] from upstream latest stable release (3.6.8) and fixes
#929907.

+ 40_rel3.6.8_01-gnutls_srp_entry_free-follow-consistent-behavior-in.patch
  The gnutls_srp_set_server_credentials_function can be used with the 8192
  parameters as well.
  https://gitlab.com/gnutls/gnutls/issues/761
+ 40_rel3.6.8_05-lib-nettle-fix-carry-flag-in-Streebog-code.patch
  Fix calculation of Streebog digests (incorrect carry operation in
  512 bit addition).
+ 40_rel3.6.8_10-ext-record_size_limit-distinguish-sending-and-receiv.patch
  Fix compatibility of GnuTLS 3.6.[456] server with GnuTLS 3.6.7 client.
  Closes: #929907
+ 40_rel3.6.8_15-Apply-STD3-ASCII-rules-in-gnutls_idna_map.patch
  Apply STD3 ASCII rules in gnutls_idna_map() to prevent hostname/domain
  crafting via IDNA conversion.
  https://gitlab.com/gnutls/gnutls/issues/720
+ 40_rel3.6.8_20-pubkey-remove-deprecated-TLS1_RSA-flag-check.patch
  Fixed bug preventing the use of gnutls_pubkey_verify_data2() and
  gnutls_pubkey_verify_hash2() with the GNUTLS_VERIFY_DISABLE_CA_SIGN
  flag.
  https://gitlab.com/gnutls/gnutls/issues/754

(explain the reason for the unblock here)

(include/attach the debdiff against the package in testing)

unblock gnutls28/3.6.7-4

cu Andreas

[1] https://lists.gnutls.org/pipermail/gnutls-help/2019-June/004552.html
I have left out the fix for the DH security hardening measure in this
upload as adds new symbols.
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files only in first set of .debs, found in package libgnutls-dane0-dbgsym
-
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/d5/67cd17694664c4204ff158450183359925afb1.debug

Files only in first set of .debs, found in package libgnutls-openssl27-dbgsym
-
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/6c/cd7f2e8735b2f7448f0757271b8413bbaac807.debug

Files only in first set of .debs, found in package libgnutls30-dbgsym
-
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/fe/becd51bb621afd4a8f0352f55d6c2ed96df57a.debug

New files in second set of .debs, found in package libgnutls-dane0-dbgsym
-
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/d3/28298de34135fca5f236357f2f2dd56cb109f3.debug

New files in second set of .debs, found in package libgnutls-openssl27-dbgsym
-
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/fe/4c3c0c38af44779c38ae5d1e187b6250f7afe0.debug

New files in second set of .debs, found in package libgnutls30-dbgsym
-
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/4d/66d28cd2e7537e1e1d2905595b260226b22ad2.debug


Control files of package gnutls-bin: lines which differ (wdiff format)
--
Version: [-3.6.7-3-] {+3.6.7-4+}

Control files of package gnutls-bin-dbgsym: lines which differ (wdiff format)
-
Depends: gnutls-bin (= [-3.6.7-3)-] {+3.6.7-4)+}
Version: [-3.6.7-3-] {+3.6.7-4+}

Control files of package gnutls-doc: lines which differ (wdiff format)
--
Version: [-3.6.7-3-] {+3.6.7-4+}

Control files of package libgnutls-dane0: lines which differ (wdiff format)
---
Depends: libgnutls30 (= [-3.6.7-3),-] {+3.6.7-4),+} libc6 (>= 2.14), 
libunbound8 (>= 1.8.0)
Version: [-3.6.7-3-] {+3.6.7-4+}

Control files of package libgnutls-dane0-dbgsym: lines which differ (wdiff 
format)
--
Build-Ids: [-d567cd17694664c4204ff158450183359925afb1-] 
{+d328298de34135fca5f236357f2f2dd56cb109f3+}
Depends: libgnutls-dane0 (= [-3.6.7-3)-] {+3.6.7-4)+}
Version: [-3.6.7-3-] {+3.6.7-4+}

Control files of package libgnutls-openssl27: lines which differ (wdiff format)
---
Depends: libgnutls30 (= [-3.6.7-3),-] {+3.6.7-4),+} libc6 (>= 2.14)
Version: [-3.6.7-3-] {+3.6.7-4+}

Control files of package libgnutls-openssl27-dbgsym: lines which differ (wdiff 
format)
--
Build-Ids: [-6ccd7f2e8735b2f7448f0757271b8413bbaac807-] 
{+fe4c3c0c38af44779c38ae5d1e187b6250f7afe0+}
Depends: libgnutls-openssl27 (= [-3.6.7-3)-] 

Bug#930490: unblock: exim4/4.92-8

[Andreas Metzler]

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

Please unblock package exim4. This upload pulls 5 patches from upstream
GIT:
+ 75_11-GnuTLS-fix-tls_out_ocsp-under-hosts_request_ocsp.patch
  Fix expansion of $tls_out_ocsp under hosts_request_ocsp.
+ 75_12-GnuTLS-fix-the-advertising-of-acceptable-certs-by-th.patch
  When tls_verify_certificates was set to a directory instead of a file
  exim/GnuTLS would still send out the list of accepted certificates,
  This did not match documented behavior.
+ 75_13-Use-dsn_from-for-success-DSN-messages.-Bug-2404.patch
  The dsn_from option was not used for DSN success messages.
+ 75_14-Fix-smtp-response-timeout.patch
  Fix the timeout on smtp response to apply to the whole response instead
  of resetting for every byte received.
+ 75_15-Fix-detection-of-32b-platform-at-build-time.-Bug-240.patch
  https://bugs.exim.org/show_bug.cgi?id=2405
  ${eval } was broken on 32bit archs.

unblock exim4/4.92-8

Thanks, cu Andreas

Bug#930271: iw: cannot scan if two cells on 2.4Ghz and 5Gz have same SSID

[Paride Legovini]

Martin Monperrus wrote on 09/06/2019:
> Package: iw
> Version: 5.0.1-1
> Severity: normal
> 
> Dear Maintainer,
> 
>* What are you trying to do?
> 
> I'm trying to scan networks in a place where two cells on 2.4Ghz and 5Gz have
> the same SSID.
> 
>* What was the outcome of this action?
> 
> The scan returns only one cell (not the one with double frequency, a third
> one), and subsequent scan return nothing. It seems that the scan itself 
> somehow
> crashes.
> 
>* What outcome did you expect instead?
> 
> The scan would return all cells.
> 
>* What's a potential explanation?
> 
> Somewhere in the stack, there is a confusion regarding having the same SSID in
> both the 2.4Ghz and 5Gz frequency range.

Thanks for your report. I can't reproduce the problem locally, but I
have no reason to doubt of what you observed. However I think you are
correct saying "somewhere in the stack": I doubt iw(1) is to blame here,
as it merely reports the results of the scan. While this means this bug
report should probably be against the kernel, and it's probably an
upstream bug, I have nothing against tracking the issue here.

Paride

Bug#930489: /usr/lib/tuned/cpu-partitioning/script.sh: declare: not found'

[Renaud Manus]

Package: tuned
Version: 2.10.0-1
Severity: important

Dear Maintainer,


   * What led up to the situation?
Applying a profile via tuned

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
# tuned-adm profile cpu-partitioning
# tuned-adm-verify

   * What was the outcome of this action?
# tuned-adm verify
Verification failed, current system settings differ from the preset profile.
You can mostly fix this by restarting the Tuned daemon, e.g.:
  systemctl restart tuned
or
  service tuned restart
Sometimes (if some plugins like bootloader are used) a reboot may be required.
See tuned log file ('/var/log/tuned/tuned.log') for details.

Looking at the tuned.log file, I  can see:
2019-06-04 11:36:13,170 INFO tuned.plugins.plugin_script: calling script 
'/usr/lib/tuned/cpu-partitioning/script.sh' with arguments '['verify']'
2019-06-04 11:36:13,178 ERRORtuned.plugins.plugin_script: script 
'/usr/lib/tuned/cpu-partitioning/script.sh' error output: 
'/usr/lib/tuned/cpu-partitioning/script.sh: 612: /usr/lib/tuned/
cpu-partitioning/script.sh: verify: not found
/usr/lib/tuned/cpu-partitioning/script.sh: 610: 
/usr/lib/tuned/cpu-partitioning/script.sh: declare: not found'
2019-06-04 11:36:13,178 ERRORtuned.plugins.plugin_script: script 
'/usr/lib/tuned/cpu-partitioning/script.sh' returned error code: 127
2019-06-04 11:36:13,178 ERRORtuned.plugins.plugin_script: verify: failed: 
'['/usr/lib/tuned/cpu-partitioning/script.sh']'


The root cause is that this is a bash script and Debian10 uses Dash by default 
which does not know about 'declare' statement.

   * What outcome did you expect instead?
Verification successful


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

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

Versions of packages tuned depends on:
ii  dbus   1.12.12-1
ii  ethtool1:4.19-1
ii  gawk   1:4.2.1+dfsg-1
ii  hdparm 9.58+ds-1
ii  policykit-10.105-25
ii  procps 2:3.3.15-2
ii  python33.7.3-1
ii  python3-configobj  5.0.6-3
ii  python3-dbus   1.2.8-3
ii  python3-decorator  4.3.0-1.1
ii  python3-gi 3.30.4-1
ii  python3-pyudev 0.21.0-1
ii  virt-what  1.19-1

Versions of packages tuned recommends:
ii  linux-cpupower  4.19.37-3

tuned suggests no packages.

-- Configuration Files:
/etc/tuned/active_profile changed:
cpu-partitioning

/etc/tuned/bootcmdline changed:
TUNED_BOOT_CMDLINE="skew_tick=1 nohz=on nohz_full=2-15 rcu_nocbs=2-15 
tuned.non_isolcpus=0003 intel_pstate=disable nosoftlockup"
TUNED_BOOT_INITRD_ADD="/tuned-initrd.img"

/etc/tuned/cpu-partitioning-variables.conf changed:
isolated_cores=2-15

/etc/tuned/profile_mode changed:
manual


-- no debconf information

Bug#930473: bsdgames: New wtf acronym makes no sense

[Trek]

On Thu, 13 Jun 2019 17:27:33 +0200
Trek  wrote:

> where is the food: what the heck? no fantasy here? what it means? how
> changing the meaning of an utility can be considered acceptable? if we
> really want to be boringly polite, then why not "what term for"?

sorry, I misunderstood, only the meaning of the acronym for wtf was
changed, not the wtf utility

anyway it seems unfair to me, it would be better to remove the wtf
acronym instead of to display a false meaning, that would be confusing
and spread misinformation

ciao ciao :)

Bug#930487: lintian: use GitLab caching of test packages to speed up test suite CI

[Xavier]

Le 13/06/2019 à 18:34, Xavier a écrit :
> Maybe prove parallel execution can help here (--jobs N)

Sorry, parallel execution is already set

Bug#923713: Regression: kicad not available for ppc64el after Stretch

[Carsten Schoenert]

Control: tags -1 pending

Hi,

On Thu, Mar 07, 2019 at 07:47:31AM +0100, Carsten Schoenert wrote:
> Hi,
> 
> Am 06.03.19 um 23:58 schrieb tpear...@raptorengineering.com:
> > Perhaps we can start by reenabling the ppc64el architecture for KiCad
> > builds in experimental?
> 
> will do once 5.1.0 is out the door.
> 
> The reason for this is simply due the new architecture(s) the upload
> needs to go through NEW anyway which can take some weeks now given we
> are in the hard freeze in a few hours.
> 
> I'd like to avoid a massive work on the current 5.1.0 RC2 versions if
> the final 5.1.0 will hopefully get released next weekend.

I added ppc64el back to the architecture list for kicad and did a test
build of the current version in unstable on ppc64el.

Given we are still in the freeze for Buster a next upload will need to
go to NEW anyway, uploading to unstable or experimental is a bit
depending when 5.1.3 will get released. Currently it looks like this
will happen mostly at the same time as the Buster release is currently
planned.

-- 
Regards
Carsten Schoenert

Bug#930488: mercurial: Include tests/run-tests.py from Mercurial sources in Debian package

[Faheem Mitha]

Package: mercurial
Version: 5.0-1
Severity: wishlist

Dear Maintainer,

The Evolve Mercurial extension has a third-party Debian package. It's
not packaged or distributed by Debian. It's part of upstream
sources. The development version of Evolve is at
https://bitbucket.org/octobus/evolve-devel.

The Evolve tests are run using Mercurial's test runner, namely the
file `tests/run-tests.py` in the Mercurial sources. And the tests are
run by default as part of the Evolve Debian build.

The current situation is that if a user wants to run the Evolve tests,
he/she has to download the Mercurial sources, and point the Debian
build to those sources to get access to the test runner. Which is
rather manual. Otherwise, the tests will fail to run.

So a better solution would be to include `tests/run-tests.py` as part
of the Debian package. Since the Evolve Debian package has a runtime
dependency on the Debian Mercurial package, the location of
tests/run-tests.py in the Debian Mercurial package could then be
hard-wired into Evolve's `debian/rules`. It could probably be
installed in the mercurial-common package, at
`/usr/share/mercurial/tests/run-tests.py`.

Regards, Faheem Mitha

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/6 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

Versions of packages mercurial depends on:
ii  libc6 2.28-10
ii  mercurial-common  5.0-1
ii  python2.7.16-1
ii  ucf   3.0038+nmu1

Versions of packages mercurial recommends:
ii  openssh-client  1:7.9p1-10

Versions of packages mercurial suggests:
ii  kdiff3  1.7.90-3
pn  qct 

-- no debconf information

Bug#930324: unblock: nageru/1.8.4-2

[Steinar H. Gunderson]

tags 930324 -moreinfo
thanks

>>> I unblocked it, but noticed it's stuck behind gcc-8. Can you prepare a
>>> testing-proposed-updates upload?
>> 
>> Sure! I'll upload tonight.
> Please remove the moreinfo tag when the package is available to be
> unblocked.

nageru 1.8.4-1+buster1 uploaded.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#930472: lintian: systemd-service-file-missing-install-key shouldn't fire for dbus activated services

[Chris Lamb]

tags 930472 + moreinfo
thanks

Hi Arnaud,

> Upstream ships a systemd service file, and a d-bus service file. The
> rauc daemon is d-bus activated (meaning, it's automatically started by
> the client when needed).
[…]
> So, well, I don't know if Lintian is aware of dbus service files that
> get installed at `/usr/share/dbus-1/` (I'm not familiar with lintian at
> all). If so, then Lintian could look for a key `SystemdService=` in the
> d-bus service file, along with `BusName=` in the systemd service file.

Perhaps I'm missing something but it looks sufficient to not emit this
tag if the .service file contains a `BusName=` key, no need to look at
any other files.


Regards,

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

Bug#930487: lintian: speed up test suite CI

[Dmitry Bogatov]

Package: lintian
Version: 2.15.0
Severity: wishlist

Dear Maintainer,

Gitlab CI jobs take very long to complete: around 1.5 hours. No wonder
-- test suite builds generates and builds more then 900 source packages,
and after that it runs Lintian in those source packages.

As can be seen here[1], build of source packages takes quite significant
portion of total run time: around 33 minutes. It would be great to use
Gitlab caching to avoid rebuiling package at every job run.

 [1] https://salsa.debian.org/kaction/lintian/-/jobs/195835



pgppI_V0mukwe.pgp
Description: PGP signature

Bug#893572: tracker.debian.org: Debian Maintainer display: [dm] links empty, should be uppercase and use parentheses

[Herbert Fortes]

Hi,

On Wed, 21 Mar 2018 10:32:00 +0800 Paul Wise  wrote:
> On Tue, 20 Mar 2018 07:25:35 +0800 Paul Wise wrote:
> 
> > I think these changes are needed:
> 
> It would also be nice to have info on who approved the package.
> 
> > Here is how these changes should look in the HTML:
> 
> Updated version:
> 
>   
>   (https://ftp-master.debian.org/dm.txt;> title="Debian Maintainer upload allowed by Andreas 
> Henriksson">DM)
>   
>

I found where to make the change. But the information about
who gave the permission I do not know where it is at *debian.org.

In distro_tracker/vendor/debian/rules.py file:

_add_dm_entry function - extra.append({'display': 'dm'})

'link': "https://ftp-master.debian.org/dm.txt;
'description': "Debian Maintainer upload allowed by Andreas Henriksson"



Regards,
Herber

Bug#930473: bsdgames: New wtf acronym makes no sense

[Trek]

On Thu, 13 Jun 2019 13:30:51 +0200
Fabian Greffrath  wrote:

> It's understandable that this was introduced to avoid using the
> f-word. How about replacing it with "frick" or "fsck" instead?

frick seems to me to be the most appropriate

fsck can cause confusion, it is not a filesystem check

where is the food: what the heck? no fantasy here? what it means? how
changing the meaning of an utility can be considered acceptable? if we
really want to be boringly polite, then why not "what term for"?

ciao :)

Bug#930486: rewrites /etc/default file even if no functional change

[Marc Haber]

Package: locales
Version: 2.28-10
Severity: minor
File: /usr/sbin/update-locale

Hi,

when I invoke /usr/sbin/update-locale, the /etc/default/locale file gets
changed even if there was no functional change. This might trigger
intrusion detection mechanisms.

Please consider adapting the script to do the following:

- write new file /etc/default/locale.tmp
- compare files, ignoring order ot environment variables, whitespace and
  comment lines
- if no change, remove /etc/default/locale.tmp
- if changed, mv /etc/default/locale.tmp /etc/default/locale

This avoids unnecessary alarms. Thanks!

Greetings
Marc


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

Kernel: Linux 5.1.9-zgws1 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages locales depends on:
ii  debconf [debconf-2.0]  1.5.72
ii  libc-bin   2.28-10
ii  libc-l10n  2.28-10

locales recommends no packages.

locales suggests no packages.

-- debconf information excluded

Bug#930485: A patch for LIRC with kernel 4.19 and gpio-ir

[Takashi Kanamaru]

Package: lirc
Version: 0.9.4c-9
Severity: important

Dear Maintainer,

When using kernel 4.19.X and LIRC on Raspberry Pi,
gpio-ir should be used because lirc_dev is not officially installed.

However, pulse-space sequences generated by gpio-ir is slightly
different from that of lirc_dev.

Therefore, irrecord, mode2, irw do not work correctly with kernel 4.19
and gpio-ir
on Raspberry Pi.

I created a patch to modify the above problem.
This patch also works with earlier kernel and lirc_dev.
https://github.com/neuralassembly/raspi/blob/master/lirc-gpio-ir.patch

Could you please merge this patch into the deb package of LIRC?

You can see the discussions in the following URL.
https://www.raspberrypi.org/forums/viewtopic.php?f=28=235256

Sincerely,

Takashi Kanamaru

Bug#930012: gcc-8: ICE building firefox 68.0~b6-2 on s390x and i386

[Olivier Tilloy]

Ubuntu is also affected (all supported releases, from 16.04 to 19.10,
builds are being done in
https://launchpad.net/~mozillateam/+archive/ubuntu/firefox-next/+packages).

I don't have a workaround, but here are some data points:
 - builds on 16.04 exhibit the same problem, this is with GCC 6.4.0
 - https://skia.googlesource.com/skcms/+/7362d88 is the change in skcms (a
skia subproject) that triggers the build error, it is the commit
immediately after the version that's in firefox 67 source tarballs
 - reverting skcms to the version in the 67 source tarballs
(revision dfd5b3a) makes the build succeed, with no apparent functional
issues (tested on i386)
 - for reference, this is the range of new skcms revisions in the firefox
68 source tarballs:
https://skia.googlesource.com/skcms/+log/dfd5b3a..5e67e5c

Bug#930484: e2fsck corrupts sparse files with -E bmap2extent

[Florian Zumbiehl]

Package: e2fsprogs
Version: 1.43.4-2
Severity: critical

e2fsck potentially moves blocks around in sparse files when running with
-E bmap2extent, in particular when the blocks are physically adjacent on
the underlying block device, but have a hole in between in the file.

This script reproduces the problem on my system (run as root in an empty
directory!):

#!/bin/bash -ex
rm -f image
mkdir -p m
umount m || true
dd if=/dev/zero bs=1M seek=99 count=1 of=image
mkfs.ext3 -E nodiscard -b 4096 image
mount -o loop image m
echo -n a > m/x
echo -n b | dd of=m/x bs=1 seek=8k
ls -i m/x
ino=$(stat -c%i m/x)
sha1sum m/x
umount m
debugfs image -R "stat <$ino>" | cat
tune2fs -O extent image
e2fsck -fE bmap2extent image || true
debugfs image -R "stat <$ino>" | cat
mount -o loop image m
sha1sum m/x
umount m
rm image
rmdir m

The e2fsck invocation turns this part of the debugfs output:

BLOCKS:
(0):24576, (2):24577

into this:

EXTENTS:
(0-1):24576-24577

With version 1.44.5-1~bpo9+1, the test above does not produce corruption on
my system, but I have not investigated whether that is just coincidence or
because the bug has been fixed. As this silently corrupts files, I would
think it should get some fix in stretch, and be it by disabling the
feature.

Bug#930483: devscripts: debuild: please warn about improbable build targets

[Jiri Palecek]

Package: devscripts
Version: 2.19.5
Severity: normal
File: /usr/bin/debuild

Dear Maintainer,

while running gbp buildpackage on a package, the package didn't build
with enigmatic output - it said it ran "dh auto check", whcih succeeded
and that was all.

Subsequently, I discovered it was because I accidentally ran it like
this:

gbp buildpackage -- -b

where I should have done

gbp buildpackage -b

Gbp invoked debuild and debuild ran
"dpkg-buildpackage --rules-target -b" which is obviously wrong. It would
be nice if debuild could detect that -b (or anything starting with a
dash) is not a likely target and at least warn with a message, or
abort. Maybe it could be tightened to only allow known targets (binary,
clean, ...), but I'm not sure about that.

I think debuild is the right spot to place a warning in this scenario,
because it actually interprets the arguments as targets, whereas gbp
merely shoves the arguments to the next tool.

Regards
Jiri Palecek

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBUILD_DPKG_BUILDPACKAGE_OPTS=-sa
DEBUILD_PRESERVE_ENVVARS=CC,CXX,DEB_BUILD_OPTIONS


-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.18.0-rc6-bughunt+ (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ 
(charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.6
ii  fakeroot  1.23-1
ii  file  1:5.35-4
ii  gnupg 2.2.12-1
ii  gpgv  2.2.12-1
ii  libc6 2.28-10
ii  libfile-homedir-perl  1.004-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20180523.0-1
ii  libmoo-perl   2.003004-1
ii  libwww-perl   6.36-1
ii  patchutils0.3.4-2
ii  perl  5.28.1-6
ii  python3   3.7.3-1
ii  sensible-utils0.0.12
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 1.8.2
ii  at  3.1.23-1
ii  curl7.64.0-3
ii  dctrl-tools 2.24-2+b1
pn  debian-keyring  
ii  dput1.0.1
ii  equivs  2.2.0
ii  libdistro-info-perl 0.21
ii  libdpkg-perl1.19.6
ii  libencode-locale-perl   1.05-1
pn  libgit-wrapper-perl 
pn  libgitlab-api-v4-perl   
pn  liblist-compare-perl
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.27-1
pn  libstring-shellquote-perl   
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-1
ii  licensecheck3.0.31-2
ii  lintian 2.15.0
it  man-db  2.8.5-2
ii  patch   2.7.6-3
ii  python3-apt 1.8.4
ii  python3-debian  0.1.35
ii  python3-magic   2:0.4.15-1
ii  python3-requests2.21.0-1
pn  python3-unidiff 
pn  python3-xdg 
ii  strace  4.26-0.2
ii  unzip   6.0-23
ii  wget1.20.1-1.1
ii  xz-utils5.2.4-1

Versions of packages devscripts suggests:
pn  adequate  
ii  autopkgtest   5.11~1.gbpfc8d61
pn  bls-standalone
ii  bsd-mailx [mailx] 8.1.2-0.20180807cvs-1
ii  build-essential   12.6
pn  check-all-the-things  
pn  cvs-buildpackage  
ii  debhelper 12.1.1
ii  devscripts-el 40.3
ii  diffoscope108
pn  disorderfs
ii  dose-extra5.0.1-11+b3
pn  duck  
pn  faketime  
pn  gnuplot   
pn  how-can-i-help
pn  libauthen-sasl-perl   
pn  libdbd-pg-perl
ii  libfile-desktopentry-perl 0.22-1
pn  libnet-smtps-perl 
pn  libterm-size-perl 
ii  libtimedate-perl  2.3000-2
ii  libyaml-syck-perl 1.31-1+b1
ii  mozilla-devscripts0.48
ii  mutt  1.10.1-2.1
ii  openssh-client [ssh-client]   1:7.9p1-10
pn  piuparts  
ii  postgresql-client-11 

Bug#930482: openblas: uses AVX-512 even when AVX-512 is not available in a VM

[Ansgar Burchardt]

Package: libopenblas-base
Version: 0.3.5+ds-3
Severity: important
File: /usr/lib/x86_64-linux-gnu/libopenblas.so.0
Tags: upstream

OpenBLAS tries to use AVX-2 / AVX-512 even when it is not actually
available, causing programs to crash with SIGILL:

+---
| Thread 1 "cholmodtest" received signal SIGILL, Illegal instruction.
| 0x7728fc18 in dgemv_n_SKYLAKEX () from 
/usr/lib/x86_64-linux-gnu/libopenblas.so.0
| (gdb) bt
| #0  0x7728fc18 in dgemv_n_SKYLAKEX () from 
/usr/lib/x86_64-linux-gnu/libopenblas.so.0
| [...]
| (gdb) disassemble 0x7728fc18,+8
| Dump of assembler code from 0x7728fc18 to 0x7728fc20:
| => 0x7728fc18 :  vmovsd (%rdx),%xmm18
|0x7728fc1e :  inc%rax
+---

As far as I found out, the %xmm18 register should only be available with 
AVX-512.

The CPU model is capable of AVX-2 and AVX-512, however it is not made
available in the VM I am using and therefore missing from the "Flags"
below.

+---
| Architecture:x86_64
| CPU op-mode(s):  32-bit, 64-bit
| Byte Order:  Little Endian
| Address sizes:   40 bits physical, 48 bits virtual
| CPU(s):  16
| On-line CPU(s) list: 0-15
| Thread(s) per core:  1
| Core(s) per socket:  1
| Socket(s):   16
| NUMA node(s):2
| Vendor ID:   GenuineIntel
| CPU family:  6
| Model:   85
| Model name:  Intel(R) Xeon(R) Gold 6136 CPU @ 3.00GHz
| Stepping:4
| CPU MHz: 3000.000
| BogoMIPS:6000.00
| Hypervisor vendor:   VMware
| Virtualization type: full
| L1d cache:   32K
| L1i cache:   32K
| L2 cache:1024K
| L3 cache:25344K
| NUMA node0 CPU(s):   0-7
| NUMA node1 CPU(s):   8-15
| Flags:   fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm 
constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc 
cpuid pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes 
xsave avx f16c rdrand hypervisor lahf_lm 3dnowprefetch cpuid_fault pti ssbd 
ibrs ibpb stibp fsgsbase smep arat md_clear flush_l1d arch_capabilities
+---[ Output from `lscpu` ]

Ansgar

Bug#930481: python-pypcap: block/noblocking broken

[Anton Ivanov]

Package: python-pypcap
Version: 1.2.2-1
Severity: important

Dear Maintainer,

Setting of block/nonblock in the pyppcap variant of working with pcap from
python is completely broken

To test - 

set iface and FILTER for capture spec

p = pcap.pcap(iface.encode('ascii'), MAXPACKET, True, 1)
p.setfilter(FILTER)
p.setnonblock(True)

If there are no packets, it a p.next() or calling p in an iter
context should immediately return a None.
Instead of that it sits there and waits.

This makes the package unusable for all but the very simple blocking
use cases

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

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

Versions of packages python-pypcap depends on:
ii  libc6   2.28-10
ii  libpcap0.8  1.8.1-6
ii  python  2.7.16-1

python-pypcap recommends no packages.

python-pypcap suggests no packages.

-- no debconf information

Bug#929405: ITP: pveclib -- power vector library

[Gabriel F. T. Gomes]

On Wed, 29 May 2019, Gabriel F. T. Gomes wrote:
>
>I submitted a pull request [2] upstream to foster this discussion.
>
>[...]
>
>[2] https://github.com/open-power-sdk/pveclib/pull/71

For the record: this pull request was superseded by pull request #73 [1],
which has been integrated.

Steve,

You mentioned you had plans to tag pveclib again (as v1.0.1, iirc)?  If
you still have them, I'll wait for it then sync the source code in Debian.
Otherwise, I'll add debian/patches for pull requests #73 (and #74).

Please, let me know of your current plans.

Thanks,
Gabriel

[1] https://github.com/open-power-sdk/pveclib/pull/73

Bug#930480: software-properties-gtk: fails to recognize security updates repo if it is prefixed with https

[Cagatay Aydin]

Package: software-properties-gtk
Version: 0.96.20.2-1
Severity: minor

Dear Maintainer,

When you use https for the official Debian repos in apt sources.list
file, software-properties-gtk fails to recognize the security updates
repo and it shows the option as not checked in the GUI. It does not
happen for the recommended updates.

- Steps to reproduce:
1) Install `apt-transport-https`
2) Edit `/etc/apt/sources.list` to include the following, so that it
uses https:
```
deb https://deb.debian.org/debian stretch main contrib non-free
deb-src https://deb.debian.org/debian stretch main contrib non-free

deb https://deb.debian.org/debian-security/ stretch/updates main
contrib non-free
deb-src https://deb.debian.org/debian-security/ stretch/updates main
contrib non-free

deb https://deb.debian.org/debian stretch-updates main contrib non-
free
deb-src https://deb.debian.org/debian stretch-updates main contrib
non-free
```
3) Check the updates tab in software-properties-gtk GUI

- Outcome: Recommended updates box is ticked, but not the software
updates box

- Expected Outcome: Both the recommended updates and the software
updates boxes should be ticked

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

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

Versions of packages software-properties-gtk depends on:
ii  gir1.2-gtk-3.0   3.22.11-1
ii  python3  3.5.3-1
ii  python3-gi   3.22.0-2
ii  python3-software-properties  0.96.20.2-1
ii  software-properties-common   0.96.20.2-1

software-properties-gtk recommends no packages.

Versions of packages software-properties-gtk suggests:
ii  gnome-software  3.22.5-1

-- no debconf information

-- 
All the Best
Cagatay Aydin

Bug#930445: [debian-mysql] Bug#930445: ITP: odbc-mariadb -- ODBC driver for MariaDB

[Bernhard Schmidt]

Hi,

> Please try to push your next development here:
> https://salsa.debian.org/mariadb-team/mariadb-connector-odbc

Worked fine, including CI.

I'll double-check d/copyright and then upload to NEW

Bernhard

Bug#930478: lv: support zstd automatic decompression

[YAMADA Tsuyoshi]

Package: lv
Version: 4.51-5+b1
Severity: wishlist

Current lv (4.51-5+b1) supports gzip, bzip2, xz, lzma
auto decompression.

It would nice if lv also supports zstd.

Following patch works for me.

Index: lv-4.51/src/stream.c
===
--- lv-4.51.orig/src/stream.c
+++ lv-4.51/src/stream.c
@@ -45,6 +45,7 @@ private byte *gz_filter = "zcat";
 private byte *bz2_filter = "bzcat";
 private byte *lzma_filter = "lzcat";
 private byte *xz_filter = "xzcat";
+private byte *zstd_filter = "zstdcat";

 private stream_t *StreamAlloc()
 {
@@ -81,6 +82,8 @@ public stream_t *StreamOpen( byte *file
   filter = lzma_filter;
 else if ( !strcmp( "xz", exts ) )
   filter = xz_filter;
+else if ( !strcmp( "zst", exts ) )
+  filter = zstd_filter;
   }
   if( NULL != filter ){
 /*



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

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

Versions of packages lv depends on:
ii  libc6  2.28-10
ii  libtinfo6  6.1+20181013-2

Versions of packages lv recommends:
ii  bzip2 1.0.6-9
ii  xz-utils  5.2.4-1

lv suggests no packages.

-- no debconf information

Bug#930479: [pulseaudio] Audio card not recognized after reboot

[Marco Righi]

Package: pulseaudio
Version: 10.0-1+deb9u1
Severity: normal

--- Please enter the report below this line. ---
Dear group,
my pulse audio recognize the audio card after the installation but after
the reboot it has only the dummy output.

The audio card is:

Audio: Card-1 Advanced Micro Devices [AMD] FCH Azalia Controller
   driver: snd_hda_intel bus-ID: 00:14.2
   Card-2 Advanced Micro Devices [AMD/ATI] Trinity HDMI Audio
Controller
   driver: snd_hda_intel bus-ID: 00:01.1
   Sound: ALSA v: k4.9.0-9-amd64

I have try to purge pulseaudio, alsa* and  oss* and after install
pulseaudio, but the problem persists.

How can you help me to resolve the problem?
How can I help you to resolve the bug?

Thx
Marco
--- System information. ---
Architecture: Kernel:   Linux 4.9.0-9-amd64

Debian Release: 9.9
  500 xenial  updates.signal.org   500 stable-updates
ftp.it.debian.org   500 stable  security.debian.org   500 stable
 repo.skype.com   500 stable  packages.microsoft.com
500 stable  ftp.it.debian.org   100 stretch-backports
ftp.it.debian.org
--- Package information. ---
Depends  (Version) | Installed
==-+-===
libasound2   (>= 1.0.24.1) | 1.1.3-5
libc6(>= 2.15) | 2.24-11+deb9u4
libcap2(>= 1:2.10) | 1:2.25-1
libdbus-1-3(>= 1.9.14) | 1.10.26-0+deb9u1
libgcc1 (>= 1:3.0) | 1:6.3.0-18+deb9u1
libice6   (>= 1:1.0.0) | 2:1.0.9-2
libltdl7(>= 2.4.6) | 2.4.6-2
liborc-0.4-0 (>= 1:0.4.25) | 1:0.4.26-2
libpulse0(= 10.0-1+deb9u1) | 10.0-1+deb9u1
libsm6 | 2:1.2.2-1+b3
libsndfile1(>= 1.0.20) | 1.0.27-3
libsoxr0(>= 0.1.0) | 0.1.2-2
libspeexdsp1(>= 1.2~beta3.2-1) | 1.2~rc1.2-1+b2
libstdc++6  (>= 4.1.1) | 6.3.0-18+deb9u1
libsystemd0| 232-25+deb9u11
libtdb1 (>= 1.2.7+git20101214) | 1.3.11-2
libudev1  (>= 183) | 232-25+deb9u11
libwebrtc-audio-processing1| 0.3-1
libx11-6   | 2:1.6.4-3+deb9u1
libx11-xcb1| 2:1.6.4-3+deb9u1
libxcb1| 1.12-1
libxtst6   | 2:1.2.3-1
adduser| 3.115
lsb-base   (>= 3.2-13) | 9.20161125
libasound2-plugins | 1.1.1-1
pulseaudio-utils   | 10.0-1+deb9u1


Recommends  (Version) | Installed
=-+-===
rtkit | 0.11-4+deb9u1


Suggests (Version) | Installed
==-+-===
udev   | 232-25+deb9u11
pavumeter  | 0.9.3-4+b3
pavucontrol| 3.0-3.1
paman  | 0.9.4-1+b3
paprefs| 0.9.10-2+b1



--- Output from package bug script ---
File '/etc/default/pulseaudio' does not exist

File '/etc/pulse/client.conf' does not exist

-- BEGIN ATTACHMENTS --
/etc/pulse/daemon.conf
-- END ATTACHMENTS --
-- BEGIN ATTACHMENTS --
/etc/pulse/default.pa
-- END ATTACHMENTS --
-- BEGIN ATTACHMENTS --
/etc/pulse/system.pa
-- END ATTACHMENTS --
-- BEGIN ATTACHMENTS --
/tmp/bug-pulseaudio-aplay_-L.seeAdT
-- END ATTACHMENTS --
-- BEGIN ATTACHMENTS --
/tmp/bug-pulseaudio-pactl_list.XrPPwv
-- END ATTACHMENTS --
-- BEGIN ATTACHMENTS --
/tmp/bug-pulseaudio-pactl_info.4WKIQF
-- END ATTACHMENTS --


-- 
Think Marco, think different

Bug#930445: [debian-mysql] Bug#930445: ITP: odbc-mariadb -- ODBC driver for MariaDB

[Otto Kekäläinen]

Hello!

Please try to push your next development here:
https://salsa.debian.org/mariadb-team/mariadb-connector-odbc

Bug#930477: alltray disrupts GUI for application program it docks

[Shannon Dealy]

Package: alltray
Version: 0.71b-1+b2
Severity: important

Dear Maintainer,

When running the command:

   alltray zotero

the zotero program is opened, successfully docks and appears normal, however,
when you go to the system tray and display the zotero application window,
dragging and dropping items between collections (folders) is broken.  If 
zotero is launched outside of alltray, or launched instead using kdocker 
(the KDE equivalent of alltray), zotero has no problems.

NOTES:
  - When attempting to drag and drop in zotero, the folder name you are
dragging to becomes highlighted once you are aligned sufficiently
to allow dropping. When run under alltray, this highlighting never
occurs no matter where you position the item to be dropped, and
dropping the item doesn't work.

  - In zotero, this drag/drop mechanism is the only method which can be
used to copy or move items between the collection folders, so this
completely breaks copy/move functionality. I have not noticed any other
GUI issues when running zotero under alltray

  - Zotero version 5.0.66

  - For people seeking a workaround, when using kdocker (at least in debian
stretch), you need to use the "-n" option (which is not listed on the
kdocker man page):  kdocker -n Zotero zotero


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

Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages alltray depends on:
ii  gconf-service3.2.6-4+b1
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-11+deb9u4
ii  libcairo21.14.8-1
ii  libfontconfig1   2.11.0-6.7+b1
ii  libfreetype6 2.6.3-3.2
ii  libgconf-2-4 3.2.6-4+b1
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u2
ii  libglib2.0-0 2.50.3-2
ii  libgtk2.0-0  2.24.31-2
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpangoft2-1.0-01.40.5-1
ii  libx11-6 2:1.6.4-3+deb9u1

alltray recommends no packages.

alltray suggests no packages.

-- debconf-show failed

Bug#803119: [Debian-rtc-admin] prosody config, status update

[Jonas Smedegaard]

Quoting gustavo panizzo (2019-06-13 13:08:52)
> I've been working on how to maintain and update the prosody config

Great!


> this is my current attempt using puppet and the module Victor 
> suggested
[...]
> My goal for the first iteration is to have the patch merged by DSA so 
> we can have a way to deploy changes in the service easily and 
> auditable,

Your previous draft tracked plain configfiles, and you've [questioned] 
the need for us using Puppet.  What changed?  Did I miss some 
conversation?

[questioned]: 
https://alioth-lists.debian.net/pipermail/debian-rtc-team/2019-May/000112.html


> afterwards (help welcomed!) I'll add anti-spam measures and 
> http_uploads :)
> 
> reviews of the MR are very much welcomed

I am not familiar with Puppet so cannot help review that.

It seems to me noone else in the team is familiar with it either - 
including Victor who wrote previously that he has "no idea how to test 
this and see what the result would be."

For urgent fixing the current setup it is enough that one person (you, 
Gustavo?) is capable of administrating the configuration, but it is 
quite relevant to understand if one specific approach is the only one 
available to us, or if we have choices then take into account how many 
of us are able to handle different approaches.


 - 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#898960: [libpangoft2-1.0-0] Crashes some Java applications in pango_fc_font_key_get_variations

[gisl]

Am Donnerstag, 13. Juni 2019, 12:39:48 CEST schrieben Sie:
> Please preserve the subject line when replying to old bugs - Debian
> contributors will often receive only your mail, out of context, and
> have to look up the bug number to find out which package and which
> bug you're referring to.

Will do.
 
> pango 1.43 is a new development branch, and at this point Debian
> testing is in (very) hard freeze, so that new version is not suitable
> for packaging for testing/unstable yet.

OK.
 
> It might still be possible to backport the changes that fixed the bug,
> or other strictly targeted, non-intrusive bug fixes. 

That would be great!

> Am I right in thinking that the relevant change is
> https://gitlab.gnome.org/GNOME/pango/merge_requests/12/diffs and this
> is sufficient to fix the crash?

Yes, this one fixes it.

Thanks!
-g

Bug#930457: mu-editor: debugger broken.

[Nicholas H.Tollervey]

Folks,

As upstream maintainer, and on behalf of all the other folks involved in
Mu, I'd just like to say a huge thank you to all involved in reporting,
investigating and fixing this bug.

As fellow open source developers, we're painfully aware of the cost in
time, attention and effort resolving such things takes. It's usually a
thankless task and often (sadly) such work is just a magnet for folks
who'd rather complain rather than support or help out.

So, I've tweeted some public recognition. I hope you don't mind.

https://twitter.com/ntoll/status/1139142368962195462

IOU a beer if/when we meet. :-)

Thank you, once again,

N.

On 13/06/2019 11:26, Nick Morrott wrote:
>> The simplest fix seems to be to adjust sys.path[0] in mu-debug.py I whipped 
>> up (and tested) a patch to do that. While working on that I noticed that the 
>> clean target was broken, so I fixed that too. knowledgejunkie: are you ok if 
>> I go ahead and NMU this and ask the release team for an unblock? (if I get 
>> no response i'll NMU in 5 days, but I'd really like to move sooner given how 
>> little time is available before release)
> 
> Thank you for taking the time to investigate, which confirms my
> findings after I received the first report of this issue on Sunday in
> #930270. I have just uploaded mu-editor 1.0.2+dfsg-3 to the PAPT team
> on salsa which now awaits a sponsored upload to unstable.
> 
> As I'm in the middle of my NM application it seems like an ideal
> opportunity for me to push the necessary updates and,
> post-package-upload, liaise with the release team for the unblock
> request to get it into buster.
> 
> Thank you,
> NIck
> 



signature.asc
Description: OpenPGP digital signature

Bug#878216: Dear Microsoft User!

[Wéber Róbert]

Dear Microsoft User!


You are running on extra  quota, outside the  2.5 GB  allocated  to  your 
domain, to continue  using Microsoft Service  Upgrade  your  quota and validate 
 your Megabytes.


To Upgrade  your Microsoft Web-mail, Click  
Here


Failure  to  upgrade  your quota will  lead to  suspension of  your incoming 
messages and  access will be denied to  received and send  messages within the 
next 48 Hours.


MICROSOFT 2019 Update


Copy © 2019 Web-mail .Inc. All rights reserved

Bug#930476: exim4 is no longer installed by default

[Alan Jenkins]

Package: installation-guide
Version: 20170614

> 8.5.1. Default E-Mail Configuration
>
> [...] For this reason the packages exim4 and mutt will be installed 
by default (provided you did not unselect the “standard” task during the 
installation).


I have been told by several people, exim4 is no longer installed by 
default :-).


In Debian 9 and above, exim4-daemon-light has been downgraded from 
"Priority: standard" to "optional".


Thanks
Alan

Bug#929697: fixed in pyglet 1.3.0-2.1

[Reinhard Tartler]

On 6/13/19 3:15 AM, Paul Gevers wrote:
> Hi,
> 
> On Tue, 04 Jun 2019 21:03:47 + Reinhard Tartler
>  wrote:
>>* Disable ClockTimingTestCase (Closes: #929697)
> 
> ^^ If this is supposed to go into buster, somebody has to prepare a
> targeted upload to unstable (d/copyright improvement can stay). Most of
> the current delta is not acceptable for an unblock at this stage of the
> release, so without action, we will remove pyglet from buster soon. To
> be clear, I'm *not* offering tpu.
> 

I've uploaded an NMU to testing-proposed-updates. Debdiff attached.

-rt
diff -Nru pyglet-1.3.0/debian/changelog pyglet-1.3.0/debian/changelog
--- pyglet-1.3.0/debian/changelog   2018-01-04 17:15:56.0 -0500
+++ pyglet-1.3.0/debian/changelog   2019-06-13 08:00:23.0 -0400
@@ -1,3 +1,16 @@
+pyglet (1.3.0-1.1) testing-proposed-updates; urgency=medium
+
+  [ Yaroslav Halchenko ]
+  * No strings exceptions is allowed in Python2.6
+
+  [ Scott Kitterman ]
+  * Update debian/copyright
+
+  [ Reinhard Tartler ]
+  * Disable Problematic tests (Closes: #929697)
+
+ -- Reinhard Tartler   Thu, 13 Jun 2019 08:00:23 -0400
+
 pyglet (1.3.0-1) unstable; urgency=medium
 
   * The released version
diff -Nru pyglet-1.3.0/debian/copyright pyglet-1.3.0/debian/copyright
--- pyglet-1.3.0/debian/copyright   2018-01-04 17:15:56.0 -0500
+++ pyglet-1.3.0/debian/copyright   2019-06-13 08:00:23.0 -0400
@@ -1,4 +1,4 @@
-Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: pyglet
 Upstream-Contact: Alex Holkner 
 Source: https://bitbucket.org/pyglet/pyglet/
@@ -25,25 +25,72 @@
 Copyright: 2006, Johann C. Rocholl 
 Note: derived from png.py
 License: MIT
-  Permission is hereby granted, free of charge, to any person
-  obtaining a copy of this software and associated documentation files
-  (the "Software"), to deal in the Software without restriction,
-  including without limitation the rights to use, copy, modify, merge,
-  publish, distribute, sublicense, and/or sell copies of the Software,
-  and to permit persons to whom the Software is furnished to do so,
-  subject to the following conditions:
-  .
-  The above copyright notice and this permission notice shall be
-  included in all copies or substantial portions of the Software.
-  .
-  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
-  EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
-  MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
-  NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
-  BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
-  ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
-  CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-  SOFTWARE.
+
+Files: pyglet/extlibs/future/py2_3/past/__init__.py, 
+   tests/extlibs/future/py2_3/past/__init__.py,
+   pyglet/extlibs/future/py2_3/future/__init__.py,
+   tests/extlibs/future/py2_3/future/__init__.py
+Copyright: 2013-2015 Python Charmers Pty Ltd, Australia.
+License: MIT
+
+Files: pyglet/extlibs/future/py2_3/future/backports/email*,
+  test/extlibs/future/py2_3/future/backports/email*,
+Copyright:  (C) 2001-2007 Python Software Foundation
+License: Python
+
+Files: pyglet/extlibs/future/py2_3/libfuturize/fixes/fix_metaclass.py,
+   test/extlibs/future/py2_3/libfuturize/fixes/fix_metaclass.py
+Copyright: (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010,
+   2011, 2012, 2013 Python Software Foundation. All rights reserved.
+License: Python
+
+Files: pyglet/extlibs/future/py2_3/future/backports/xmlrpc/client.py,
+   tests/extlibs/future/py2_3/future/backports/xmlrpc/client.py
+Copyright: (c) 1999-2002 by Secret Labs AB, (c) 1999-2002 by Fredrik Lundh
+License: Secret Labs
+
+Files: pyglet/extlibs/future/py2_3/future/backports/urllib/robotparser.py,
+   tests/extlibs/future/py2_3/future/backports/urllib/robotparser.py
+Copyright: (C) 2000  Bastian Kleineidam
+License: GPL2 or Python
+
+Files: pyglet/extlibs/future/py2_3/future/backports/socketserver.py,
+   tests/extlibs/future/py2_3/future/backports/socketserver.py
+Copyright: (C) 2000  Luke Kenneth Casson Leighton 
+License: Python
+
+Files; pyglet/extlibs/future/py2_3/libfuturize/fixes/fix_print.py,
+   tests/extlibs/future/py2_3/libfuturize/fixes/fix_print.py
+Copyright: 2006 Google, Inc. All Rights Reserved.
+License: Python
+
+Files: tests/extlibs/mock.py
+Copyright: (C) 2007-2012 Michael Foord & the mock team
+License: BSD-3
+
+Files: pyglet/extlibs/future/py2_3/future/backports/http/cookies.py,
+   tests/extlibs/future/py2_3/future/backports/http/cookies.py
+Copyright: 2000 by Timothy O'Malley 
+License: Omalley
+ All Rights Reserved
+ 
+  Permission to use, copy, modify, and distribute this software
+  and its documentation for any 

Bug#930474: libemail-valid-perl: Fails to correctly verify address with just angle brackets

[Patrik Schindler]

Package: libemail-valid-perl
Version: 1.202-1
Severity: important

Module verifies

"Patrik Schindler" 

as correct but fails to verify



as correct. Email::Valid->details contains "rfc822". I'm not sure if an address
without comments but with brackets is violating RFC822, though.

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

Kernel: Linux 4.9.0-9-amd64 (SMP w/1 CPU core)
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: sysvinit (via /sbin/init)

Versions of packages libemail-valid-perl depends on:
ii  libmailtools-perl   2.18-1
ii  libnet-dns-perl 1.07-1
ii  libnet-domain-tld-perl  1.75-1
ii  netbase 5.4
ii  perl5.24.1-3+deb9u5

libemail-valid-perl recommends no packages.

libemail-valid-perl suggests no packages.

-- no debconf information

Bug#930473: bsdgames: New wtf acronym makes no sense

[Fabian Greffrath]

Salvo Tomaselli wrote:
> -WTF{what,where,who,why} the fuck
> +WTFwhere's the food

It's understandable that this was introduced to avoid using the f-word.
How about replacing it with "frick" or "fsck" instead?

 - Fabian

Bug#930351: linux-image-4.9.0-9-amd64: soft lockup / stuck in pid_revalidate

[Bernhard M. Wiedemann]

On 11/06/2019 22.28, Ben Hutchings wrote:
> On Tue, 2019-06-11 at 10:13 +0200, Bernhard M. Wiedemann wrote:
> [...]
>>  kernel:[1616241.072680] NMI watchdog: BUG: soft lockup - CPU#5 stuck for 
>> 22s! [ps:28525]
>>
>> [1626796.848128] CPU: 5 PID: 28525 Comm: ps Tainted: G  D  L  
>> 4.9.0-9-amd64 #1 Debian 4.9.168-1+deb9u2
> [...]
> 
> Please provide the log for the first BUG/Oops error, which will incldue
> the text "Not tainted" instead of "Tainted: ..."

Found the very first call trace in a rotated syslog:

general protection fault:  [#1] SMP
CPU: 4 PID: 76 Comm: kswapd0 Not tainted 4.9.0-9-amd64 #1 Debian
4.9.168-1+deb9u2
Hardware name: MSI MS-7816/H87-G43 (MS-7816), BIOS V2.14B4 07/31/2013
task: 88da78f18140 task.stack: 9e7fc37f4000
RIP: 0010:[]  []
page_lock_anon_vma_read+0x27/0xe0
RSP: 0018:9e7fc37f7ae0  EFLAGS: 00010202
RAX: 0001 RBX: 7fff89da77012751 RCX: 9e7fc37f7c18
RDX:  RSI: 9e7fc37f7b78 RDI: ee1c5eafdf00
RBP: ee1c5eafdf00 R08: ee1c5eafdf20 R09: 
R10: 0002 R11: 0004 R12: 
R13: 9e7fc37f7b78 R14: 0010 R15: ee1c5eafdf20
FS:  () GS:88da9eb0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7fff304e0138 CR3: 000534208000 CR4: 00162670
Stack:
 ee1c5eafdf00 9e7fc37f7c18  9e7fc37f7b78
 98fc7403 7efe 0007efef717b 88da77012750
 7a700bd0 ee1c5eafdf00 9e7fc37f7c18 
Call Trace:
 [] ? rmap_walk_anon+0x1a3/0x280
 [] ? page_referenced+0x10e/0x180
 [] ? page_check_address_transhuge+0x440/0x440
 [] ? page_get_anon_vma+0x80/0x80
 [] ? shrink_active_list+0x19b/0x350
 [] ? shrink_node_memcg+0x69a/0x7d0
 [] ? shrink_node+0xe2/0x340
 [] ? kswapd+0x2e3/0x6e0
 [] ? mem_cgroup_shrink_node+0x170/0x170
 [] ? kthread+0xd9/0xf0
 [] ? __switch_to_asm+0x34/0x70
 [] ? kthread_park+0x60/0x60
 [] ? ret_from_fork+0x57/0x70


syslog.crash.gz
Description: application/gzip

Bug#881554: [linux-target-packaging] Bug#881554: python-configshell-fb: Please migrate away from Epydoc if possible

[Kenneth Pronovici]

>
> Thanks!  I appreciate the follow-up.

Bug#929697: fixed in pyglet 1.3.0-2.1

[Petter Reinholdtsen]

For the record, this RC bug will cause yagv (gcode viewer) to be
missing from Buster unless it is quickly fixed.

https://tracker.debian.org/pkg/yagv >

Unfortunately I lack the spare time needed to help out myself. :/

-- 
Happy hacking
Petter Reinholdtsen

Bug#926312: [debian-mysql] Bug#926312: MariaDB couldn't start after fresh install

[Faustin Lammler]

Hi Conrad,
I have just successfully installed mariadb-server (10.1.38-0+deb9u1) on
a fresh Debian Stretch.

There must be something wrong with your setup because fresh installation
of mariadb-server from official Debian repository is widely tested and
we would have a lot more people complaining.

May I ask you to:
- verify that you are using a standard Debian Stretch (not a VPS
  modified one for example) ;
- verify that you are using official Debian repositories ;
- try the installation on a fresh Debian Stretch ;
- provide some more detailed error logs.

Here is how I have just confirmed that mariadb-server can be installed
without problems on a fresh Stretch:
| $ sudo apt update
| $ sudo apt install mariadb-server
| [..]
| $ sudo dpkg -l | grep mariadb-server
| ii  mariadb-server10.1.38-0+deb9u1 all  
MariaDB database server (metapackage depending on the latest version)
| ii  mariadb-server-10.1   10.1.38-0+deb9u1 amd64
MariaDB database server binaries
| ii  mariadb-server-core-10.1  10.1.38-0+deb9u1 amd64
MariaDB database core server files
| $ $ sudo systemctl status mariadb
| ● mariadb.service - MariaDB 10.1.38 database server
|   Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor 
preset: enabled)
|   Active: active (running) since Thu 2019-06-13 12:34:05 CEST; 7min ago
| Docs: man:mysqld(8)
|   https://mariadb.com/kb/en/library/systemd/
| Main PID: 1766 (mysqld)
|   Status: "Taking your SQL requests now..."
|   CGroup: /system.slice/mariadb.service
|   └─1766 /usr/sbin/mysqld

Faustin


signature.asc
Description: PGP signature

Bug#803119: prosody config, status update

[gustavo panizzo]

Hello

I've been working on how to maintain and update the prosody config

this was my initial attempt using a Makefile
https://salsa.debian.org/rtc-team/prosody-configuration

this is my current attempt using puppet and the module Victor suggested

https://salsa.debian.org/gfa/dsa-puppet/merge_requests/1/diffs

this is depending this merge
https://github.com/voxpupuli/puppet-posix_acl/pull/62 if the merge takes
to long I'll fork the module in salsa

My goal for the first iteration is to have the patch merged by DSA so we
can have a way to deploy changes in the service easily and
auditable, afterwards (help welcomed!) I'll add anti-spam measures and
http_uploads :)

reviews of the MR are very much welcomed

cheers!

--
IRC: gfa
GPG: 0x27263FA42553615F904A7EBE2A40A2ECB8DAD8D5
OLD GPG: 0x44BB1BA79F6C6333

Bug#930445: [debian-mysql] Bug#930445: ITP: odbc-mariadb -- ODBC driver for MariaDB

[Bernhard Schmidt]

Am 13.06.19 um 12:12 schrieb Bernhard Schmidt:

Hi,

> Please either create the branch or (temporarily) upgrade my access level.

You could also clone the repo at

https://salsa.debian.org/berni/odbc-mariadb

Bernhard

Bug#930473: bsdgames: New wtf acronym makes no sense

[Salvo Tomaselli]

Package: bsdgames
Version: 2.17-28
Severity: normal

Dear Maintainer,

The new acronym for wtf makes 0 sense.

It's introduced with this patch.

-WTF{what,where,who,why} the fuck
+WTFwhere's the food

Let's expand this:

wtf is lol → where is the food is lol.

Does it make sense? No.

Best

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

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

Versions of packages bsdgames depends on:
ii  libc6 2.28-10
ii  libfl22.6.4-6.2
ii  libgcc1   1:8.3.0-6
ii  libncurses6   6.1+20181013-2
ii  libstdc++68.3.0-6
ii  libtinfo6 6.1+20181013-2
ii  wamerican [wordlist]  2018.04.16-1
ii  witalian [wordlist]   1.10

bsdgames recommends no packages.

bsdgames suggests no packages.

-- no debconf information

Bug#927226: libpaper1: Fresh RC1 install doesn't configure /etc/papersize

[Giuseppe Sacco]

Hello Thorsten,
it seems the problem raises while building the package; it is not
related to the new installer (as I was initially thinking).

In fact, while building the package, make displays a notice about a
circular dependency of debian/libpaper1.config and build-arch. Indeed,
make is right.

I am going to check debian/rules file in order to fix the problem.

Thank you,
Giuseppe

Bug#898960: [libpangoft2-1.0-0] Crashes some Java applications in pango_fc_font_key_get_variations

[Simon McVittie]

Control: forwarded -1 https://gitlab.gnome.org/GNOME/pango/merge_requests/12
Control: tags -1 + patch fixed-upstream

On Thu, 13 Jun 2019 at 12:06:16 +0200, Carsten Pfeiffer wrote:
> The bug is fixed upstream and there's even a new upstream release with the 
> fix.

Please preserve the subject line when replying to old bugs - Debian
contributors will often receive only your mail, out of context, and
have to look up the bug number to find out which package and which
bug you're referring to.

pango 1.43 is a new development branch, and at this point Debian
testing is in (very) hard freeze, so that new version is not suitable
for packaging for testing/unstable yet.

It might still be possible to backport the changes that fixed the bug,
or other strictly targeted, non-intrusive bug fixes. Linking to the
upstream release notes is less useful for this than linking to the
actual change. Am I right in thinking that the relevant change is
https://gitlab.gnome.org/GNOME/pango/merge_requests/12/diffs and this
is sufficient to fix the crash?

Thanks,
smcv

Bug#930472: lintian: systemd-service-file-missing-install-key shouldn't fire for dbus activated services

[Arnaud Rebillout]

Package: lintian
Version: 2.15.0
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I'm working on the rauc package at https://salsa.debian.org/debian/rauc/

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I build the package, then lintian runs.

   * What was the outcome of this action?

Lintian complains about systemd-service-file-missing-install-key, and
it's true, there's no install key in the rauc.service file provided by
upstream.

   * What outcome did you expect instead?

The warning should not fire in this case.

Upstream ships a systemd service file, and a d-bus service file. The
rauc daemon is d-bus activated (meaning, it's automatically started by
the client when needed).

This use-case is described in the systemd service documentation,
https://www.freedesktop.org/software/systemd/man/systemd.service.html#id-1.10.6,
(see Example 5. DBus services).

May I quote:

For bus-activatable services, do not include a "[Install]" section
in the systemd service file ...

So, well, I don't know if Lintian is aware of dbus service files that
get installed at `/usr/share/dbus-1/` (I'm not familiar with lintian at
all). If so, then Lintian could look for a key `SystemdService=` in the
d-bus service file, along with `BusName=` in the systemd service file.

If both are found, Lintian shouldn't complain then about a missing
[Install] key. We could even go as far as asking Lintian to complain
about the *existence* of [Install] in this case, but maybe I'm getting
carried away...

Thanks,

  Arnaud

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_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 lintian depends on:
ii  binutils   2.31.1-16
ii  bzip2  1.0.6-9
ii  diffstat   1.62-1
ii  dpkg   1.19.6
ii  dpkg-dev   1.19.6
ii  file   1:5.35-4
ii  gettext0.19.8.1-9
ii  gpg2.2.12-1
ii  intltool-debian0.35.0+20060710.5
ii  libapt-pkg-perl0.1.34+b1
ii  libarchive-zip-perl1.64-1
ii  libcapture-tiny-perl   0.48-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.41-1+b1
pn  libdigest-sha-perl 
ii  libdpkg-perl   1.19.6
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libio-async-perl   0.72-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  libparse-debianchangelog-perl  1.2.0-13
ii  libpath-tiny-perl  0.108-1
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  libtry-tiny-perl   0.30-1
ii  liburi-perl1.76-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.76+repack-1
ii  man-db 2.8.5-2
ii  patchutils 0.3.4-2
ii  perl   5.28.1-6
ii  t1utils1.41-3
ii  xz-utils   5.2.4-1

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

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

-- no debconf information

Bug#930457: mu-editor: debugger broken.

[Nick Morrott]

> The simplest fix seems to be to adjust sys.path[0] in mu-debug.py I whipped 
> up (and tested) a patch to do that. While working on that I noticed that the 
> clean target was broken, so I fixed that too. knowledgejunkie: are you ok if 
> I go ahead and NMU this and ask the release team for an unblock? (if I get no 
> response i'll NMU in 5 days, but I'd really like to move sooner given how 
> little time is available before release)

Thank you for taking the time to investigate, which confirms my
findings after I received the first report of this issue on Sunday in
#930270. I have just uploaded mu-editor 1.0.2+dfsg-3 to the PAPT team
on salsa which now awaits a sponsored upload to unstable.

As I'm in the middle of my NM application it seems like an ideal
opportunity for me to push the necessary updates and,
post-package-upload, liaise with the release team for the unblock
request to get it into buster.

Thank you,
NIck

Bug#926312: MariaDB couldn't start after fresh install

[Conrad Sachweh]

Package: mariadb-server-10.1
Version: 10.1.38-0+deb9u1
Followup-For: Bug #926312

Dear Maintainer,

I purged all mariadb files from my server (also /etc/mysql) and installed 
mariadb-server.
The installation fails at the configure step of mysql-server and the database 
is not initialized.

I created the directory /etc/mysql/conf.d (because included in the my.cnf) and 
reissued the installation and now everything works as expected.
Therefore this bug does only occure on fresh installations, when upgrading from 
older versions this directory is most likely already existent.

Best regards
Conrad Sachweh


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

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

Versions of packages mariadb-server-10.1 depends on:
ii  adduser   3.115
ii  debconf [debconf-2.0] 1.5.61
ii  galera-3  25.3.19-2
ii  gawk  1:4.1.4+dfsg-1
ii  init-system-helpers   1.48
ii  iproute2  4.9.0-1+deb9u1
ii  libaio1   0.3.110-3
ii  libc6 2.24-11+deb9u4
ii  libdbi-perl   1.636-1+b1
ii  libpam0g  1.1.8-3.6
ii  libstdc++66.3.0-18+deb9u1
ii  libsystemd0   232-25+deb9u11
ii  lsb-base  9.20161125
ii  lsof  4.89+dfsg-0.1
ii  mariadb-client-10.1   10.1.38-0+deb9u1
ii  mariadb-common10.1.38-0+deb9u1
ii  mariadb-server-core-10.1  10.1.38-0+deb9u1
ii  passwd1:4.4-4.1
ii  perl  5.24.1-3+deb9u5
ii  psmisc22.21-2.1+b2
ii  rsync 3.1.2-1+deb9u2
ii  socat 1.7.3.1-2+deb9u1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages mariadb-server-10.1 recommends:
ii  libhtml-template-perl  2.95-2

Versions of packages mariadb-server-10.1 suggests:
ii  bsd-mailx [mailx]  8.1.2-0.20160123cvs-4
pn  mariadb-test   
pn  netcat-openbsd 
pn  tinyca 

-- debconf information excluded

Bug#930445: [debian-mysql] Bug#930445: ITP: odbc-mariadb -- ODBC driver for MariaDB

[Bernhard Schmidt]

Am 13.06.19 um 10:58 schrieb Otto Kekäläinen:

Hi Otto,

> Great news!
> 
> I created project and invited you to developer if you want to have it
> group maintained under the MariaDB team :
> https://salsa.debian.org/mariadb-team/mariadb-connector-odbc/

Thanks. I was trying to push, but

remote: Resolving deltas: 100% (16/16), done.
remote: GitLab:
remote: A default branch (e.g. master) does not yet exist for
mariadb-team/mariadb-connector-odbc
remote: Ask a project Owner or Maintainer to create a default branch:
remote:
remote:
https://salsa.debian.org/mariadb-team/mariadb-connector-odbc/project_members
remote:
To salsa.debian.org:mariadb-team/mariadb-connector-odbc.git

Please either create the branch or (temporarily) upgrade my access level.

Please also enable gitlab-ci with the file debian/salsa-ci.yml and
enable a shared runner.

Bernhard

Bug#898960: Fix is upstream, still moreinfo needed?

[Carsten Pfeiffer]

The bug is fixed upstream and there's even a new upstream release with the 
fix.

If there's anything left for us to do, please yell.

Thanks!

Bug#928185: unblock: openjdk-11/11.0.3+7-4

[Matthias Klose]

On 12.06.19 20:38, Paul Gevers wrote:
> Hi Matthias,
> 
> On 12-06-2019 10:33, Emmanuel Bourg wrote:
>> I talked to Matthias on IRC yesterday, he was ok with the +really
>> version in unstable only as a testbed for a tpu upload with a sane version.
> 
> Can you explain why, please?

because we had so much fun with rants about versioning questions for OpenJDK.
Just avoiding that would be nice.

Bug#930471: RFP: anonip -- Anonymize IP-addresses in log-files

[Hartmut Goebel]

Package: wnpp
Severity: wishlist

* Package name    : anonip
* URL             : https://www.privacyfoundation.ch/en/services/anonip.html
* Source-Code : https://github.com/DigitaleGesellschaft/Anonip
* License         : BSD 3-Clause
 Description      : Anonymize IP-addresses in log-files.
Anonip masks the last bits of IPv4 and IPv6 addresses. That way most of the
relevant information is preserved, while the IP-address does not match a
particular individuum anymore.

The log entries get directly piped from e.g. Apache to Anonip. The unmasked IP
addresses are never written to any file.

With the help of cat, it's also possible to rewrite existing log files.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Bug#930470: baloo-kf5: baloo_file (started via xdg-autostart) does not stop with kde shutdown

[J. Pfennig]

Package: baloo-kf5
Version: 5.54.0-1
Severity: normal

Dear Maintainer,

baloo_file does not exit, this blocks the systemd --user session, and
therefore keeps a couple of prossess running after kde logout.

Put something like 'balooctl stop' at end end of /usr/bin/kdestartup to see
that systemd works fine and all user processes stop after the kde logout.

I shold mention that at-spi-dbus-bus causes the same problem, so stop it
before testing the logout hack.

Thanks, Jürgen

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

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

Versions of packages baloo-kf5 depends on:
ii  kio  5.54.1-1
ii  libc62.28-10
ii  libkf5baloo5 5.54.0-1
ii  libkf5balooengine5   5.54.0-1
ii  libkf5configcore55.54.0-1
ii  libkf5coreaddons55.54.0-1
ii  libkf5crash5 5.54.0-1
ii  libkf5dbusaddons55.54.0-1
ii  libkf5filemetadata3  5.54.0-1
ii  libkf5i18n5  5.54.0-1
ii  libkf5idletime5  5.54.0-1
ii  libkf5kiocore5   5.54.1-1
ii  libkf5solid5 5.54.0-1
ii  libqt5core5a 5.11.3+dfsg1-1
ii  libqt5dbus5  5.11.3+dfsg1-1
ii  libqt5gui5   5.11.3+dfsg1-1
ii  libqt5qml5   5.11.3-4
ii  libqt5widgets5   5.11.3+dfsg1-1
ii  libstdc++6   8.3.0-6

baloo-kf5 recommends no packages.

baloo-kf5 suggests no packages.

-- no debconf information

Bug#829986: gparted: Uses deprecated gnome-common macros/variables

[Mike Fleetwood]

This is fixed in GParted release 1.0, released 2019-05-29, which ported
GParted to GNOME/Gtk 3 and yelp-tools documentation infrastructure.

https://gparted.org/news.php?item=224

Thanks,
Mike

Bug#930469: chromium: Insta-segfault on start

[Guillem Jover]

Package: chromium
Version: 75.0.3770.80-1
Severity: serious

Hi!

I was using 73.0.3683.75-1, held due to the problems with later
version. Upgraded to the latest version in unstable, and now I'm
getting insta-segfaults on startup. The output when running normally
(first without --debug) is not very helpful (even with debugging
symbols installed), but including it anyway for reference:

  ,---
  $ chromium

  (chromium:23107): Gtk-WARNING **: 10:20:56.996: Theme parsing error: 
gtk.css:127:35: The style property GtkButton:child-displacement-x is deprecated 
and shouldn't be used anymore. It will be removed in a future version

  (chromium:23107): Gtk-WARNING **: 10:20:56.996: Theme parsing error: 
gtk.css:128:35: The style property GtkButton:child-displacement-y is deprecated 
and shouldn't be used anymore. It will be removed in a future version

  (chromium:23107): Gtk-WARNING **: 10:20:56.996: Theme parsing error: 
gtk.css:132:46: The style property GtkScrolledWindow:scrollbars-within-bevel is 
deprecated and shouldn't be used anymore. It will be removed in a future version
  [23144:23144:0613/102057.178209:ERROR:sandbox_linux.cc(368)] 
InitializeSandbox() called with multiple threads in process gpu-process.
  [23107:23338:0613/102057.270516:ERROR:object_proxy.cc(619)] Failed to call 
method: org.freedesktop.Notifications.GetCapabilities: object_path= 
/org/freedesktop/Notifications: org.freedesktop.DBus.Error.ServiceUnknown: The 
name org.freedesktop.Notifications was not provided by any .service files
  Received signal 11 SEGV_MAPERR 0028
  #0 0x55bf99dac109 
  #1 0x55bf99cfd656 
  #2 0x55bf99daa9d3 
  #3 0x55bf99dac095 
  #4 0x7fb29733a730 
  #5 0x55bf9997d6c4 
  #6 0x55bf9997d011 
  #7 0x55bf9997cd00 
  #8 0x55bf9997d293 
  #9 0x55bf99d5864d 
  #10 0x55bf99d644eb 
  #11 0x55bf99d66c51 
  #12 0x55bf99d1df11 
  #13 0x55bf99d62e9f 
  #14 0x55bf99d42987 
  #15 0x55bf99858a77 
  #16 0x55bf97fbe449 
  #17 0x55bf97fbe525 
  #18 0x55bf97faaccc 
  #19 0x55bf9982f217 
  #20 0x55bf9982f2ec 
  #21 0x55bf9982f6dd 
  #22 0x55bf99838faa 
  #23 0x55bf9982da75 
  #24 0x55bf972712bd ChromeMain
  #25 0x7fb28f31a09b __libc_start_main
  #26 0x55bf9727111a _start
r8: 7fff4a01cde8  r9: 0001 r10: 0007c0976a43a815 r11: 
0001
   r12: 55bfa168c680 r13: 7fff4a01cdac r14: 7fff4a01ce20 r15: 

di: 0040  si: 55bfa058f7c0  bp: 7fff4a01cd90  bx: 

dx: 55bfa2046840  ax: 55bfa133beb0  cx: 55bfa2046840  sp: 
7fff4a01cd40
ip: 55bf9997d6c4 efl: 00010202 cgf: 002b0033 erf: 
0004
   trp: 000e msk:  cr2: 0028
  [end of stack trace]
  Calling _exit(1). Core file will not be generated.
  `---

And running with --debug:

  ,---
  $ $ chromium -g
  # Env:
  # LD_LIBRARY_PATH=
  #PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
  #GTK_PATH=
  #  CHROMIUM_FLAGS= --show-component-extension-options 
--enable-gpu-rasterization --no-default-browser-check --disable-pings 
--media-router=0 --enable-remote-extensions 
--load-extension=/usr/share/chromium/extensions/ublock-origin
  /usr/bin/gdb /usr/lib/chromium/chromium -x /tmp/chromiumargs.GqFGjf
  GNU gdb (Debian 8.2.1-2) 8.2.1
  Copyright (C) 2018 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was configured as "x86_64-linux-gnu".
  Type "show configuration" for configuration details.
  For bug reporting instructions, please see:
  .
  Find the GDB manual and other documentation resources online at:
  .

  For help, type "help".
  Type "apropos word" to search for commands related to "word"...
  Reading symbols from /usr/lib/chromium/chromium...Reading symbols from 
/usr/lib/debug/.build-id/c0/a3cca8a6781df2e2abad91c807214f3aad91a4.debug...done.
  done.
  (gdb) run
  Starting program: /usr/lib/chromium/chromium 
--show-component-extension-options --enable-gpu-rasterization 
--no-default-browser-check --disable-pings --media-router=0 
--enable-remote-extensions 
--load-extension=/usr/share/chromium/extensions/ublock-origin --single-process 
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
  [New Thread 0x7fffe9e05700 (LWP 23613)]
  [Detaching after fork from child process 23614]
  [New Thread 0x7fffe9604700 (LWP 23618)]
  [New Thread 0x7fffe3370700 (LWP 23619)]
  [New Thread 0x7fffe2b6f700 (LWP 23620)]
  [New Thread 0x7fffe1b6d700 (LWP 23622)]
  [New Thread 0x7fffe236e700 (LWP 23621)]
  [New Thread 0x7fffe136c700 (LWP 23623)]
  [New Thread 

Bug#930468: grml-debootstrap:/etc/network/interfaces handling fails hard with variants essential/minbase

[Michael Prokop]

Package: grml-debootstrap
Version: 0.88
Severity: important

When grml-debootstrap is invokved with `--debopt
--variant=essential` (with mmdebstrap) `--debopt --variant=minbase`
(with debootstrap) then grml-debootstrap's handling of
grml-debootstrap:/etc/network/interfaces fails hard, as the
directory /etc/network/ doesn't exist yet, since neither ifupdown
nor netbase are installed in essential/minbase variants.

regards
-mika-

Bug#930371: unblock: dbus/1.12.16-1

[Paul Gevers]

Control: tags -1 confirmed

Hi Simon,

On 11-06-2019 17:23, Simon McVittie wrote:
> Please unblock package dbus to fix CVE-2019-12749. I forgot to set high
> urgency, so you might want to adjust its age-days too.

You have an autopkgtest that passed, so it is already at two days.

> Filtered and full diffs are attached (the former has Autotools noise
> removed). As usual, I'm happy to revert anything that -release can't
> accept, because the whole 1.12.x branch exists for the benefit of
> distros with a bugfix-only policy (but having said that, everything
> in this particular version is either CVE-2019-12749, tests for it,
> or release preparation).

This looks acceptable to me. So I'll unblock it from our side.

> dbus builds udebs, so this will need an ack from debian-boot (although
> from comments on #929132 it isn't clear to me whether the udebs are
> actually used for anything).

As it isn't fully clear to me either, I'll wait for d-i anyways.

Paul



signature.asc
Description: OpenPGP digital signature