Bug#947823: geeqie-common: Debian changelog is not compressed

[Sven Joachim]

Package: geeqie-common
Version: 1:1.5.1-3
Severity: serious

The changelogs in this package are not compressed:

,
| $ ls /usr/share/doc/geeqie-common/changelog*
| /usr/share/doc/geeqie-common/changelog  
/usr/share/doc/geeqie-common/changelog.Debian
`

Looking at debian/rules, apparently the intention was to leave only the
upstream changelog uncompressed so that geeqie can find it at runtime,
but debhelper's -X option does not quite work the way a naive user might
suspect.


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

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

geeqie-common depends on no packages.

Versions of packages geeqie-common recommends:
ii  geeqie  1:1.5.1-3

geeqie-common suggests no packages.

-- no debconf information

Bug#947822: geeqie: file conflict with older geeqie-common

[Sven Joachim]

Package: geeqie
Version: 1:1.5.1-3
Severity: serious

There was a problem when updating your package (sorry for the German):

,
| Vorbereitung zum Entpacken von .../6-geeqie_1%3a1.5.1-3_amd64.deb ...
| Entpacken von geeqie (1:1.5.1-3) über (1:1.5.1-2) ...
| dpkg: Fehler beim Bearbeiten des Archivs 
/tmp/apt-dpkg-install-aJs4JD/6-geeqie_1%3a1.5.1-3_amd64.deb (--unpack):
|  Versuch, »/usr/share/man/man1/geeqie.1.gz« zu überschreiben, welches auch in 
Paket geeqie-common 1:1.5.1-2 ist
| Vorbereitung zum Entpacken von .../7-geeqie-common_1%3a1.5.1-3_all.deb ...
| Entpacken von geeqie-common (1:1.5.1-3) über (1:1.5.1-2) ...
| Fehler traten auf beim Bearbeiten von:
|  /tmp/apt-dpkg-install-aJs4JD/6-geeqie_1%3a1.5.1-3_amd64.deb
`

Thou shalt not move files between packages without proper Replaces &
Breaks - see Policy § 7.6.1.


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

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

Versions of packages geeqie depends on:
ii  geeqie-common1:1.5.1-3
ii  libc62.29-7
ii  libcairo21.16.0-4
ii  libexiv2-14  0.25-4
ii  libffmpegthumbnailer4v5  2.1.1-0.2+b1
ii  libgcc1  1:9.2.1-21
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-2
ii  libglib2.0-0 2.62.4-1
ii  libgtk2.0-0  2.24.32-4
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-4
ii  liblirc-client0  0.10.1-6
ii  liblua5.1-0  5.1.5-8.1+b3
ii  libpango-1.0-0   1.42.4-8
ii  libpangocairo-1.0-0  1.42.4-8
ii  libstdc++6   9.2.1-21
ii  libtiff5 4.1.0+git191117-1
ii  sensible-utils   0.0.12+nmu1

Versions of packages geeqie recommends:
ii  cups-bsd [lpr]   2.3.1-1
ii  exiftran 2.10-3+b1
ii  exiv20.25-4
ii  imagemagick  8:6.9.10.23+dfsg-2.1+b2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1+b2
ii  librsvg2-common  2.46.4-1
pn  ufraw-batch  
pn  zenity   

Versions of packages geeqie suggests:
pn  geeqie-dbg   
pn  gimp 
ii  libjpeg-turbo-progs [libjpeg-progs]  1:1.5.2-2+b1
pn  ufraw
pn  xpaint   

-- no debconf information

Bug#947688: systemd-networkd: Python socket.getfqdn() not working properly when resolv.conf lacks "domain" key

[Dirk Heinrichs]

Michael Biebl:


I've uploaded v244 to buster-backports so you should be able to test if
you can still reproduce the problem there.


Great, thanks a lot, will do. I've also meanwhile tested this in an Arch 
Linux Container and it shows the same behaviour. However, it seems I was 
somehow wrong reg. the need for the "domain" keyword in resolv.conf. The 
"search" keyword seems to be enough, but this is missing unless I add a 
proper "Domains=..." line to resolved.conf and restart it, although it 
should get the domain from the DHCP server.


Bye...

Dirk
--
Dirk Heinrichs 
GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E54246986015
Sichere Internetkommunikation: http://www.retroshare.org
Privacy Handbuch: https://www.privacy-handbuch.de

Bug#947365: transition: libvigraimpex

[Sebastiaan Couwenberg]

On 12/30/19 9:48 PM, Paul Gevers wrote:
> On 27-12-2019 18:08, Andreas Metzler wrote:
>> On 2019-12-26 Paul Gevers  wrote:
>>> On 25-12-2019 19:29, Andreas Metzler wrote:
 libvigraimpex is marked for autoremoval because of the python2 removal.
 This is fixed in experimental, the new version features a soname bump.
>> [...]
>>> Normally we don't want python 2 removal package uploads and transitions
>>> mixed, but it seems that python-vigra doesn't have reverse dependencies.
>>> Please go ahead in unstable.
>>
>> Thank you, uploaded.
> 
> libvigraimpex is also part of the pseudo python3.8 transition [1], but
> it is still red. This probably means that you are not correctly building
> Python3 modules for all supported Python3 versions. Can you please check?

Looks like it shouldn't build depend on python3-all-dev since the build
systems only uses the default interpreter.

 sed -i 's/python3-all-dev/python3-dev/g' debian/control

Kind Regards,

Bas

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



signature.asc
Description: OpenPGP digital signature

Bug#947720: sollya ftbfs with libfplll6

[Jerome BENOIT]

Dear Paul, thanks for your report. I can reproduce the issue on my box.
I am working on it. Cheers, Jerome
-- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B



signature.asc
Description: OpenPGP digital signature

Bug#947821: grpc: package grpc_cli tool

[Nick Lewycky]

Source: grpc
Severity: wishlist

gRPC comes with a command line tool "grpc_cli". See its documentation:

https://github.com/grpc/grpc/blob/master/doc/command_line_tool.md

This is useful both for people who have are developing a server and want 
to test it out without having to build a client program, and also for 
shell scripting.


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

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-1-amd64 (SMP w/32 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Bug#947820: vpnc-scripts: vpnc-script-sshd broken in buster with bad ip link syntax

[Karl O. Pinc]

Package: vpnc-scripts
Version: 0.1~git20190117-1
Severity: important
Tags: patch

Hello,

After upgrading from stretch to buster I found that the
vpnc-script-sshd no longer works.  Perhaps there's
a syntax change with "ip link".

In any case, "ip link" provides new syntax so there
no longer has to be any guessing about local and remote
device names.

Attached is a patch which fixes things.

See also: bug #868293.  I believe that the patch attached
there also makes the script work, just from having poked around
and tried various things.  But the attached patch is better
because its explicit.

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

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

Versions of packages vpnc-scripts depends on:
ii  iproute2   4.20.0-2
ii  net-tools  1.60+git20180626.aebd88e-1

vpnc-scripts recommends no packages.

Versions of packages vpnc-scripts suggests:
ii  dnsmasq 2.80-1
ii  openssh-server  1:7.9p1-10+deb10u1
pn  resolvconf  

-- no debconf information
--- /usr/share/vpnc-scripts/vpnc-script-sshd2019-02-26 12:14:42.0 
-0600
+++ vpnc-script-sshd2019-12-31 00:51:12.540753856 -0600
@@ -179,10 +179,9 @@
exit 1
 fi
 
-$IP link add dev $TUNDEV-vpnssh%d type veth
-# XXX: Assume vpnssh0 and vpnssh1; ip doesn't tell us!
 LOCALDEV=$TUNDEV-vpnssh0
 export REMOTEDEV=$TUNDEV-vpnssh1
+$IP link add name $LOCALDEV type veth peer name $REMOTEDEV
 
 $IP netns exec $NETNSNAME $0 $@ &
 CHILDPID=$!

Bug#947806: systemd doesn't like my raid, times out waiting for online partitions to come online, and can't continue boot

[Michael Biebl]

Control: tags -1 + moreinfo

Please provide a verbose debug log:
https://freedesktop.org/wiki/Software/systemd/Debugging/#index1h1




signature.asc
Description: OpenPGP digital signature

Bug#947819: regression: iwlwifi hangs kernel completely sometimes

[Stefan Tauner]

Package: src:linux
Version: 4.19.67-2+deb10u2
Severity: important

Dear Maintainer,

my Intel Centrino 6205 in my Thinkpad T430 sometimes hangs the hole
system with Linux 4.19. I *think* it always related to the hardware
kill switch and reloading the driver afterwards, but I am not
completely sure since my "analysis" was done on several lock up
occasions over the period of a few months. I cannot reproduce it
effectively but it has incurred data loss thus I have set the elevated
importance in this bug report.

The reason why I tinker with the kill switch and/or the module at all
is that auto-reconnecting (with nm-manager) does not work consistently.
Both, the non-working reconnect and the lock ups, are a regression to
Debian 9 stretch where everything worked flawlessly.

I have attached some kernel log snippets that I was able to gather that
show some warnings related to iwlwifi but I am not 100% sure they are
actually related to the lock ups.

Since it's very hard to reproduce and it is quite annoying I will now switch to
Buster's backport kernel (5.3) and see if that helps.

KR



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

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-6-amd64 root=/dev/mapper/vg-root ro quiet

** Tainted: OE (12288)
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Model information
sys_vendor: LENOVO
product_name: 2349PT4
product_version: ThinkPad T430
chassis_vendor: LENOVO
chassis_version: Not Available
bios_vendor: LENOVO
bios_version: G1ETB7WW (2.77 )
board_vendor: LENOVO
board_name: 2349PT4
board_version: No DPK

** Loaded modules:
iwldvm
mac80211
iwlwifi
cfg80211
btrfs
zstd_compress
zstd_decompress
xxhash
ufs
qnx4
hfsplus
hfs
minix
vfat
msdos
fat
jfs
xfs
ctr
ccm
rfcomm
fuse
pci_stub
vboxpci(OE)
vboxnetadp(OE)
vboxnetflt(OE)
cmac
cpufreq_userspace
vboxdrv(OE)
cpufreq_conservative
cpufreq_powersave
bnep
binfmt_misc
btusb
btrtl
btbcm
btintel
uvcvideo
bluetooth
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
videobuf2_common
videodev
drbg
ansi_cprng
ecdh_generic
media
intel_rapl
msr
arc4
snd_hda_codec_hdmi
x86_pkg_temp_thermal
intel_powerclamp
coretemp
kvm_intel
mei_wdt
snd_hda_codec_realtek
snd_hda_codec_generic
kvm
snd_hda_intel
irqbypass
intel_cstate
snd_hda_codec
intel_uncore
snd_hda_core
snd_hwdep
intel_rapl_perf
pcspkr
serio_raw
wmi_bmof
sg
snd_pcm
iTCO_wdt
iTCO_vendor_support
thinkpad_acpi
snd_timer
nvram
tpm_tis
tpm_tis_core
snd
mei_me
tpm
mei
pcc_cpufreq
soundcore
rfkill
ac
battery
rng_core
evdev
parport_pc
ppdev
lp
parport
sunrpc
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
fscrypto
ecb
algif_skcipher
af_alg
dm_crypt
dm_mod
raid10
raid1
raid0
multipath
linear
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
crc32c_generic
md_mod
sd_mod
crct10dif_pclmul
crc32_pclmul
crc32c_intel
ghash_clmulni_intel
pcbc
i915
ahci
libahci
aesni_intel
libata
aes_x86_64
crypto_simd
cryptd
glue_helper
psmouse
scsi_mod
i2c_i801
sdhci_pci
xhci_pci
i2c_algo_bit
cqhci
xhci_hcd
drm_kms_helper
sdhci
lpc_ich
mmc_core
ehci_pci
ehci_hcd
drm
e1000e
usbcore
thermal
usb_common
wmi
video
button

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core processor DRAM
Controller [8086:0154] (rev 09)
Subsystem: Lenovo 3rd Gen Core processor DRAM Controller [17aa:21f3]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: ivb_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core
processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA
controller])
Subsystem: Lenovo 3rd Gen Core processor Graphics Controller
[17aa:21f3]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset
Family USB xHCI Host Controller [8086:1e31] (rev 04) (prog-if 30 [XHCI])
Subsystem: Lenovo 7 Series/C210 Series Chipset Family USB xHCI Host
Controller (ThinkPad T430) [17aa:21f3]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C216
Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
Subsystem: Lenovo 7 Series/C216 Chipset Family MEI Controller
[17aa:21f3]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-

Bug#947811: systemd: don't check *mounted* filesystems by default

[Michael Biebl]

Control: tags -1 + moreinfo

Am 31.12.19 um 03:29 schrieb Joshua:
> Package: systemd
> Version: 241-7~deb10u2
> Severity: important
> 
> systemd tries to fsck mounted filesystems by default.

Please provide a verbose debug log from the complete boot where this is
happening:
https://freedesktop.org/wiki/Software/systemd/Debugging/#index1h1



signature.asc
Description: OpenPGP digital signature

Bug#947807: systemd: can't install systemd when /etc/machine-id is a symbolic link to /dev/null

[Michael Biebl]

Control: tags -1 + moreinfo

Am 31.12.19 um 01:28 schrieb Joshua:
> Package: systemd
> Version: 241-7~deb10u2
> Severity: normal
> 
> Dear Maintainer,
> 
> /etc/machine-id should not be used on workstations anymore due to privacy 
> reasons.

That's your opinion but not a recommendation of the Debian project or
systemd maintainers.

 The way to
> disable it was announced as rm /etc/machine-id ; ln -s /dev/null 
> /etc/machine-id at the time.

Announced by whom and where exactly?

> systemd's configuration script can't handle it.

Please provide verbose logs from commands you used and the exact error
messages.



signature.asc
Description: OpenPGP digital signature

Bug#942428: transition: gssdp/gupnp

[Paul Gevers]

Control: tags -1 - moreinfo
Control: tags -1 confirmed
Control: block -1 by 947805

Hi Laurent, Andreas,

On 31-12-2019 01:20, Laurent Bigonville wrote:
>> peony-extensions - no rdeps, unmaintained <--- temporary removal?
>>   not really, the package is
>> aging now in unstable as it had recent updates

> AFAICS peony-extensions has no dependency against gssdp or gupnp, so
> that's fine I guess

Right, it's not listed here:
https://release.debian.org/transitions/html/auto-gssdp.html
or here:
https://release.debian.org/transitions/html/auto-gupnp.html

>> upnp-router-control - no rdeps, unmaintained for years <-- permament
>> removal?
> 
> That package definitely look unmaintained (no upload since 2013), I see
> some recent activity upstream (a few uploads in 2019, the previous
> uploads where somewhere in 2013), but even the development branch does
> not built with the last version of gssdp/gupnp
> 
> I've opened a bug upstream and I just opened a serious bug in debian
> 
> So I guess that removing the package from testing should be fine for now?

What I was missing here is that/how upnp-router-control is broken with
the new version. But I see you mentioned that in the bug: FTBFS.

Your transition isn't colliding with any other (yet), so let's start
this and see if anybody steps up for upnp-router-control in the coming 2
weeks and if not, remove it for the migration of gssdp.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#947818: ITP: exec-path-from-shell-el -- get environment variables such as $PATH from the shell

[Lev Lamberov]

Package: wnpp
Owner: Lev Lamberov 
Severity: wishlist

* Package name: exec-path-from-shell-el
  Version : 1.12
  Upstream Author : Steve Purcell 
* URL or Web page : https://github.com/purcell/exec-path-from-shell
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : get environment variables such as $PATH from the shell

This library allows the user to set Emacs' `exec-path' and $PATH from
the shell path, so that `shell-command', `compile' and the like work
as expected.

It also allows other environment variables to be retrieved from the
shell, so that Emacs will see the same values you get in a terminal.

Bug#947706: www.debian.org: Updating Debian portages web page

[Adrian Bunk]

On Sun, Dec 29, 2019 at 12:26:08PM +0100, Alban Vidal wrote:
> Package: www.debian.org
>...
> -
> 
> Bellow the list of officials portages:
> - amd64
> - arm64
> - armel
> - armhf
> - i386
> - mipsel
> - mips64el
> - ppc64el
> - s390x
>...
> [1] https://www.debian.org/ports/
>...

Removing mips from the list of official ports is wrong.

As of Debian 10 mips is an official release architecture that will
continue to be supported in this release.

For our users the most relevant information is what is supported in the 
current stable release, not whatever changes might happen in future 
releases.

Release architectures for Debian 11 are not yet decided, further changes 
might happen and in theory it is even possible that someone starts 
working on keeping mips as release architecture.

It has happened before that a port was discontinued but later restarted
by other people.

> -
> 
> Bellow the list of unofficials portages:
> - alpha
> - arm
> - AVR32
> - hppa
> - hurd-i386
> - ia64
> - kfreebsd-amd64
> - kfreebsd-i386
> - m32r
> - m68k
> - mips
> - netbsd-i386
> - netbsd-alpha
> - or1k
> - powerpc
> - powerpcspe
> - riscv64
> - s390
> - sparc
> - sparc64
> - sh4
> - x32
>...
> [1] https://www.debian.org/ports/
>...

This list does not contain all ports that autobuild unstable as of 
today, and the status of several ports is incorrect.
The current non-release architectures are the "Hosted Architectures"
listed at https://www.ports.debian.org/

"discontinued" and "dead" seem to be different words for the same.

"in progress" is poor wording for ports that are not aiming at 
(again) becoming release architectures, the most common term
I am aware of would be "non-release architecture".

ftpmas...@ports-master.debian.org (added to Cc) is the correct contact 
for discussing the status of ports that are not part of Debian 10.

> Bests regards,
> Alban
>...

cu
Adrian

Bug#947817: ITP: kaldi -- Kaldi Speech Recognition Toolkit

[Mo Zhou]

Package: wnpp
Severity: wishlist
Owner: Mo Zhou 

* Package name: kaldi
* URL : https://github.com/kaldi-asr/kaldi
* URL : http://kaldi-asr.org/
* License : Apache-2
  Programming Lang: C++, python, etc.
  Description : Kaldi Speech Recognition Toolkit

This is a widely used Automatic Speech Recognition (ASR) toolkit.
It provides me more experience for developing ML-Policy.

Bug#947816: GeoLite2 databases are now non-free

[Harlan Lieberman-Berg]

Package: geoipupdate
Severity: serious

Hello maintainer,

Unfortunately, it seems that MaxMind have changed their policies on GeoLite2 
databases such that they now require a license key.  In addition (and more 
critically), they are no longer licensed under a Creative Commons BY-SA 
license, and now are under a custom EULA.

I reviewed the EULA (https://www.maxmind.com/en/geolite2/eula) and, while I am 
neither an attorney nor a debian-legal faux-counsel, the agreement seems to 
violate the DFSG in several regards.

First, it places restrictions on fields of endeavor -- specifically, that you 
may not use the data for Fair Credit Reporting Act purposes, including 
determining whether a person may be granted credit, eligible for insurance, for 
employment purposes, or any other purpose governed by the FCRA.

Second, you are no longer permitted to redistribute the data except by binding 
them to the EULA.

Third, you are required to check in with MaxMind regularly and destroy old 
versions of the dataset within 30 days.  This seems to violate several 
long-standing interpretations of the DFSG including the desert island test and 
the tentacles of evil test.

Based on this license change, it seems to me that geoipupdate can no longer be 
in main.  Contrib may be a suitable home, however?

Sincerely,

--
Harlan Lieberman-Berg
~hlieberman

Bug#947815: ITP: rust-spotify-tui -- Spotify for the terminal written in Rust

[Ximin Luo]

Package: wnpp
Severity: wishlist
Owner: Ximin Luo 

* Package name: rust-spotify-tui
  Version : 0.11.0
  Upstream Author : Alexander Keliris 
* URL : https://github.com/Rigellute/spotify-tui
* License : MIT or Apache-2.0
  Programming Lang: Rust
  Description : Spotify for the terminal written in Rust

spotify-tui needs to connect to Spotify’s API in order to find music by name,
play tracks etc. Instructions on how to set this up will be shown when you
first run the app.

This app uses the Web API from Spotify, which doesn't handle streaming itself.
So you'll need either an official Spotify client open or a lighter weight
alternative such as spotifyd.

If you want to play tracks, Spotify requires that you have a Premium account.

Bug#947814: RFS: rmlint/2.9.0-1 -- Extremely fast tool to remove filesystem lint

[Carlos Maddela]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "rmlint"

 * Package name: rmlint
   Version : 2.9.0-1
   Upstream Author : Christopher Pahl 
 * URL : https://rmlint.readthedocs.io/
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/debian/rmlint
   Section : utils

It builds these binary packages:

  rmlint - Extremely fast tool to remove filesystem lint
  rmlint-gui - GTK+ frontend to rmlint
  rmlint-doc - HTML documentation for rmlint

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/rmlint/rmlint_2.9.0-1.dsc

Changes since the last upload:

   * New upstream release [2.9.0]. (Closes: #928521)
   * Fix incorrect use of findstring function in debian/rules.
   * debian/patches/*:
 - Rebase drops patches already applied upstream: doco-typos.patch,
   fix-nosetests-search.patch and fix-pre-sse4.2.patch.
 - Update reproducible-build.patch to be Python version-agnostic
   so that package may be built with scons 3.1.2-1. (Closes: #947580)
 - Add xattr-fixes.patch cherry-picked from upstream
   which may resolve possible build failures in kfreebsd.
 - Add python3.8.patch to fix syntax warnings and missing metadata
   generated in egg-info.
 - Add glib-2_62.patch to remove deprecated API calls.
   * Drop use of debian/compat file.
   * Drop debian/rmlint-doc.lintian-overrides.
   * Update debian/clean.
   * Indicate compliance with Debian Policy 4.4.1 (no changes required).
   * Fix missing rmlint-gui dependency on python3-gi-cairo
 so that graphics are correctly displayed.
 Thanks to Andres for report. (Closes: #947615)

Regards,

--
  Carlos Maddela

Bug#936508: fdb: diff for NMU version 2.0.0-1.1

[Sandro Tosi]

Control: tags 936508 + patch


Dear maintainer,

I've prepared an NMU for fdb (versioned as 2.0.0-1.1). The diff
is attached to this message.

Regards.

diff -Nru fdb-2.0.0/debian/changelog fdb-2.0.0/debian/changelog
--- fdb-2.0.0/debian/changelog	2019-02-07 05:43:34.0 -0500
+++ fdb-2.0.0/debian/changelog	2019-12-30 22:53:40.0 -0500
@@ -1,3 +1,10 @@
+fdb (2.0.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #936508
+
+ -- Sandro Tosi   Mon, 30 Dec 2019 22:53:40 -0500
+
 fdb (2.0.0-1) unstable; urgency=low
 
   * New upstream version
diff -Nru fdb-2.0.0/debian/control fdb-2.0.0/debian/control
--- fdb-2.0.0/debian/control	2019-02-07 05:43:34.0 -0500
+++ fdb-2.0.0/debian/control	2019-12-30 22:48:38.0 -0500
@@ -4,31 +4,14 @@
 Priority: optional
 Build-Depends: debhelper (>= 9)
 Build-Depends-Indep:
-  python-all (>= 2.7), python3-all,
-  python-sphinx, python-sphinx-bootstrap-theme,
-  python-setuptools, python3-setuptools,
-  python-future,
+  python3-all,
+  python3-sphinx, python3-sphinx-bootstrap-theme,
+  python3-setuptools,
   libjs-sphinxdoc,
   dh-python
 Standards-Version: 3.9.8
-X-Python-Version: >= 2.7
-X-Python3-Version: >= 3.4
 Homepage: https://pypi.python.org/pypi/fdb/
 
-Package: python-fdb
-Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}, libfbclient2, python-future
-Suggests: python-fdb-doc
-Description: Python2 DB-API driver for Firebird
- FDB is a Python library package that implements Python Database API
- 2.0-compliant support for the open source relational database Firebird®.
- In addition to the minimal feature set of the standard Python DB API,
- FDB also exposes nearly the entire native client API of the database
- engine.  This version installs the Python2 byte code.
- .
- FDB is a replacement for python-kinterbasdb, which is no longer
- maintained by upstream.
-
 Package: python3-fdb
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends}, libfbclient2
@@ -47,7 +30,7 @@
 Architecture: all
 Section: doc
 Depends: ${misc:Depends}, libjs-sphinxdoc
-Recommends: python-fdb
+Recommends: python3-fdb
 Description: Python DB-API driver for Firebird documentation
  FDB is a Python library package that implements Python Database API
  2.0-compliant support for the open source relational database Firebird®.
diff -Nru fdb-2.0.0/debian/rules fdb-2.0.0/debian/rules
--- fdb-2.0.0/debian/rules	2019-02-07 05:43:34.0 -0500
+++ fdb-2.0.0/debian/rules	2019-12-30 22:53:20.0 -0500
@@ -8,7 +8,7 @@
 
 %:
 	#dh $@ -v --with python2,python3,sphinxdoc --buildsystem=pybuild
-	dh "$@" -v --with python2,python3 --buildsystem=pybuild
+	dh "$@" -v --with python3 --buildsystem=pybuild
 
 get-orig-source:
 	uscan --force-download
@@ -16,7 +16,7 @@
 override_dh_auto_build: $(PYBUILD_NAME).egg-info.orig
 	dh_auto_build
 	rm -rf docs
-	$(MAKE) --directory sphinx html
+	$(MAKE) --directory sphinx html SPHINXBUILD=/usr/share/sphinx/scripts/python3/sphinx-build
 	rm -rf html
 	mv docs html
 

Bug#947813: SIGSEGV resulting from mesa dri2_add_config dealing poorly with invalid attrib

[Martin von Gagern]

Package: libegl-mesa0
Version: 19.2.6-1

It seems dri2_add_config is encountering some invalid values causing
memory corruption and subsequent SIGSEGV at X server startup.

The stack trace written to the Xorg log isn't too useful, so I ran X
under gdb with debug symbols installed, and copied relevant portions
below. The way I read the results from that, for i==24 I get
attrib==__DRI_ATTRIB_MAX(=50). So dri2_add_config will enter the
default case in egl_dri2.c:319, call the inlined _eglSetConfigKey for
some invalid key for which _eglOffsetOfConfig returns its default of
-1 (as seen in %rdx). The assertion of a positive offset apparently is
disabled in my build. This clobbers some bytes of the display pointer
in the base data structure, which will lead to invalid access later
on, e.g. during _eglValidateConfig.

I haven't been able to work out where the invalid attrib is coming
from. I don't know where dri2_dpy->core->indexConfigAttrib is
implemented.

(gdb) break dri2_add_config
Breakpoint 1 at 0x7fffecce8a40: file
../src/egl/drivers/dri2/egl_dri2.c, line 221.
⋮
Thread 1 "Xorg" hit Breakpoint 1, dri2_add_config
(disp=disp@entry=0x55891220, dri_config=0x5585ab90,
id=id@entry=1, surface_type=surface_type@entry=4,
attr_list=attr_list@entry=0x7fffe2e4,
rgba_masks=rgba_masks@entry=0x0) at ../src/egl/drivers/dri2/egl_dri2.c:221
221 ../src/egl/drivers/dri2/egl_dri2.c: No such file or directory.
⋮ [step past _eglInitConfig call]
(gdb) watch base.Display
Hardware watchpoint 2: base.Display
(gdb) c
Continuing.

Thread 1 "Xorg" hit Hardware watchpoint 2: base.Display

Old value = (_EGLDisplay *) 0x55891220
New value = (_EGLDisplay *) 0x5500
dri2_add_config (disp=disp@entry=0x55891220,
dri_config=0x5585ab90, id=id@entry=1,
surface_type=surface_type@entry=4,
attr_list=attr_list@entry=0x7fffe2e4,
rgba_masks=rgba_masks@entry=0x0)
at ../src/egl/drivers/dri2/egl_dri2.c:239
239 in ../src/egl/drivers/dri2/egl_dri2.c
(gdb) bt
surface_type=surface_type@entry=4,
attr_list=attr_list@entry=0x7fffe2e4,
rgba_masks=rgba_masks@entry=0x0)
at ../src/egl/drivers/dri2/egl_dri2.c:239
#1  0x7fffeccef239 in drm_add_configs_for_visuals
(drv=0x7fffe370, disp=0x55891220)
at ../src/egl/drivers/dri2/platform_drm.c:640
#2  dri2_initialize_drm (drv=drv@entry=0x55891d00,
disp=disp@entry=0x55891220)
at ../src/egl/drivers/dri2/platform_drm.c:761
#3  0x7fffecce894b in dri2_initialize (disp=0x55891220,
drv=0x55891d00)
at ../src/egl/drivers/dri2/egl_dri2.c:911
#4  dri2_initialize (drv=0x55891d00, disp=0x55891220) at
../src/egl/drivers/dri2/egl_dri2.c:876
#5  0x7fffecce4b9d in _eglMatchAndInitialize
(disp=disp@entry=0x55891220) at ../src/egl/main/egldriver.c:75
#6  0x7fffecce4be6 in _eglMatchDriver
(disp=disp@entry=0x55891220) at ../src/egl/main/egldriver.c:96
#7  0x7fffeccdf188 in eglInitialize (dpy=0x55891220,
major=0x0, minor=0x0) at ../src/egl/main/eglapi.c:617
#8  0x7621d292 in glamor_egl_init
(scrn=scrn@entry=0x557ff150, fd=)
at ../../../../../../glamor/glamor_egl.c:927
#9  0x77fbd183 in try_enable_glamor (pScrn=0x557ff150)
at ../../../../../../../hw/xfree86/drivers/modesetting/driver.c:769
#10 PreInit (pScrn=0x557ff150, flags=)
at ../../../../../../../hw/xfree86/drivers/modesetting/driver.c:996
#11 0x555ef814 in InitOutput
(pScreenInfo=pScreenInfo@entry=0x557c37c0 ,
argc=argc@entry=1,
argv=argv@entry=0x7fffe6a8) at
../../../../../../hw/xfree86/common/xf86Init.c:522
#12 0x555b2714 in dix_main (argc=1, argv=0x7fffe6a8,
envp=) at ../../../../dix/main.c:193
#13 0x76ed3bbb in __libc_start_main (main=0x5559c710
, argc=1, argv=0x7fffe6a8,
init=, fini=, rtld_fini=, stack_end=0x7fffe698)
at ../csu/libc-start.c:308
#14 0x5559c74a in _start ()
(gdb) disas
Dump of assembler code for function dri2_add_config:
   0x7fffecce8a40 <+0>: push   %r15
   0x7fffecce8a42 <+2>: push   %r14
   0x7fffecce8a44 <+4>: push   %r13
   0x7fffecce8a46 <+6>: push   %r12
   0x7fffecce8a48 <+8>: mov%rsi,%r12
   0x7fffecce8a4b <+11>: mov%rdi,%rsi
   0x7fffecce8a4e <+14>: push   %rbp
   0x7fffecce8a4f <+15>: xor%ebp,%ebp
   0x7fffecce8a51 <+17>: push   %rbx
   0x7fffecce8a52 <+18>: lea0x15b7f(%rip),%rbx# 0x7fffeccfe5d8
   0x7fffecce8a59 <+25>: sub$0x118,%rsp
   0x7fffecce8a60 <+32>: mov0x70(%rdi),%r15
   0x7fffecce8a64 <+36>: mov%rdi,(%rsp)
   0x7fffecce8a68 <+40>: lea0x44(%rsp),%r14
   0x7fffecce8a6d <+45>: lea0x40(%rsp),%r13
   0x7fffecce8a72 <+50>: mov%edx,0x3c(%rsp)
   0x7fffecce8a76 <+54>: mov%ecx,0x14(%rsp)
   0x7fffecce8a7a <+58>: mov%r8,0x20(%rsp)
   0x7fffecce8a7f <+63>: mov%r9,0x28(%rsp)
   0x7fffecce8a84 <+68>: mov%fs:0x28,%rax
   0x7fffecce8a8d <+77>: mov%rax,0x108(%rsp)
   

Bug#947321: buster-pu: package dkimpy/0.9.1-1

[Scott Kitterman]

On Monday, December 30, 2019 3:56:19 PM EST Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2019-12-24 at 11:27 -0500, Scott Kitterman wrote:
> > This proposed update includes fixes for all user reported bugs since
> > the last version available before buster froze.  These are all issues
> > reported by actual package users (not all on Debian).  The two most
> > 
> > imoprtant issues are:
> >  - Updating the ARC (Authenticated Receive Chain) code to match the
> >  
> >final version of the spec.  RFC 8617 is published not, so it is
> >highly unlikely to change again during Buster's lifetime.
> >  
> >  - Ignoring unknown service types: Since 0.9.1 was released, a new
> > DKIM
> >service type, TLSRPT, has been defined and is starting to see use.
> >RFC 6376 (DKIM RFC) always required unknown service types to be
> >ignored, but since there had only ever been one, that check was
> > never
> >implemented.  This change will prevent mis-processing of TLSRPT
> >service signatures.
> 
> Please go ahead.
> 
> Regards,
> 
> Adam

Thanks,

Uploaded and in the queue.

Scott K

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

Bug#947812: python3-socksipychain: missing Breaks+Replaces: python-socksipychain

[Andreas Beckmann]

Package: python3-socksipychain
Version: 2.1.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Selecting previously unselected package python3-socksipychain.
  Preparing to unpack .../python3-socksipychain_2.1.0-1_all.deb ...
  Unpacking python3-socksipychain (2.1.0-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-socksipychain_2.1.0-1_all.deb (--unpack):
   trying to overwrite '/usr/bin/sockschain', which is also in package 
python-socksipychain 2.0.15-2
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-socksipychain_2.1.0-1_all.deb


cheers,

Andreas


python-socksipychain=2.0.15-2_python3-socksipychain=2.1.0-1.log.gz
Description: application/gzip

Bug#947811: systemd: don't check *mounted* filesystems by default

[Joshua]

Package: systemd
Version: 241-7~deb10u2
Severity: important

systemd tries to fsck mounted filesystems by default.

Don't ever try to fsck a filesystem mounted read/write.  All that does is trash 
things.

If somebody left a filesystem mounted rw on the emergency shell, best to not 
check it this boot.

-- Package-specific info:

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1), LANGUAGE=en_US 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init) (wrong!)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-4
ii  libapparmor1 2.13.2-10
ii  libaudit11:2.8.4-3
ii  libblkid12.33.1-0.1
ii  libc62.28-10
ii  libcap2  1:2.25-2
ii  libcryptsetup12  2:2.1.0-5+deb10u2
ii  libgcrypt20  1.8.4-5
ii  libgnutls30  3.6.7-4
ii  libgpg-error01.35-1
ii  libidn11 1.33-2.2
ii  libip4tc01.8.2-4
ii  libkmod2 26-1
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.4-1
ii  libmount12.33.1-0.1
ii  libpam0g 1.3.1-5
ii  libseccomp2  2.3.3-4
ii  libselinux1  2.8-1+b1
ii  libsystemd0  241-7~deb10u2
ii  mount2.33.1-0.1
ii  util-linux   2.33.1-0.1

Versions of packages systemd recommends:
ii  dbus   1.12.16-1
ii  libpam-systemd-apt-holepunch [libpam-systemd]  1

Versions of packages systemd suggests:
ii  policykit-10.105-25
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.133+deb10u1
ii  udev 241-7~deb10u2

-- Configuration Files:
/etc/systemd/journald.conf changed:
[Journal]
Storage=none
ForwardToSyslog=1


-- no debconf information

Bug#947810: gvm-libs: FTBFS during indep-only build

[Andreas Beckmann]

Source: gvm-libs
Version: 11.0.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

gvm-libs/experimental FTBFS during the indep-only build:

[...]
   dh_auto_test -i
cd obj-x86_64-linux-gnu && make -j3 test ARGS\+=-j3
make[1]: Entering directory '/build/gvm-libs-11.0.0/obj-x86_64-linux-gnu'
Running tests...
/usr/bin/ctest --force-new-ctest-process -j3
Test project /build/gvm-libs-11.0.0/obj-x86_64-linux-gnu
Start 1: testhosts
Could not find executable 
/build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/test-hosts
Looked in the following places:
/build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/test-hosts
/build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/test-hosts
/build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/Release/test-hosts
/build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/Release/test-hosts
/build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/Debug/test-hosts
/build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/Debug/test-hosts
/build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/MinSizeRel/test-hosts
/build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/MinSizeRel/test-hosts
/build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/RelWithDebInfo/test-hosts
/build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/RelWithDebInfo/test-hosts
/build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/Deployment/test-hosts
/build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/Deployment/test-hosts
/build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/Development/test-hosts
/build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/Development/test-hosts
build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/test-hosts
build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/test-hosts
build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/Release/test-hosts
build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/Release/test-hosts
build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/Debug/test-hosts
build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/Debug/test-hosts
build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/MinSizeRel/test-hosts
build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/MinSizeRel/test-hosts
build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/RelWithDebInfo/test-hosts
build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/RelWithDebInfo/test-hosts
build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/Deployment/test-hosts
build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/Deployment/test-hosts
build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/Development/test-hosts
build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/Development/test-hosts
Unable to find executable: 
/build/gvm-libs-11.0.0/obj-x86_64-linux-gnu/tests/test-hosts
1/1 Test #1: testhosts ***Not Run   0.00 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) =   0.01 sec

The following tests FAILED:
  1 - testhosts (Not Run)
Errors while running CTest
make[1]: *** [Makefile:155: test] Error 8
make[1]: Leaving directory '/build/gvm-libs-11.0.0/obj-x86_64-linux-gnu'
dh_auto_test: cd obj-x86_64-linux-gnu && make -j3 test ARGS\+=-j3 returned exit 
code 2
[...]


Andreas


gvm-libs_11.0.0-1_indep.log.gz
Description: application/gzip

Bug#947809: upgrade-reports: lost wifi on upgrade from buster to bullseye

[Ziad]

Package: upgrade-reports
Severity: important
Tags: a11y

Dear Maintainer,

   * What led up to the situation?
upgrade from buster to bullseye

wifi card is detected and corresponding realtek-firmware installed. Bluetooth
and ethernet working. Wireless interface disappeared at upgrade. network-
manager is most recent version 1.20.8-1


3d:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8822BE
802.11a/b/g/n/ac WiFi adapter
DeviceName: Realtek RTL8822BE 802.11 ac 2x2 WiFi + BT 4.2 Combo Adapter
(MU-MIMO supported)
Subsystem: Hewlett-Packard Company Realtek RTL8822BE 802.11ac 2 × 2 Wi-
Fi + Bluetooth 4.2 Combo Adapter (MU-MIMO supported)
Flags: fast devsel, IRQ 18
I/O ports at 3000 [size=256]
Memory at bc30 (64-bit, non-prefetchable) [size=64K]
Capabilities: 
Kernel modules: rtwpci

/usr/sbin/ifconfig
eno1: flags=4163  mtu 1500
inet 192.168.0.166  netmask 255.255.255.0  broadcast 192.168.0.255
inet6 fe80::e6e7:49ff:fe33:ff88  prefixlen 64  scopeid 0x20
ether e4:e7:49:33:ff:88  txqueuelen 1000  (Ethernet)
RX packets 4184  bytes 1977567 (1.8 MiB)
RX errors 0  dropped 1146  overruns 0  frame 0
TX packets 3110  bytes 371891 (363.1 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10
loop  txqueuelen 1000  (Local Loopback)
RX packets 8  bytes 396 (396.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 8  bytes 396 (396.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0



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

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

Bug#947806: systemd doesn't like my raid, times out waiting for online partitions to come online, and can't continue boot

[Joshua Hudson]

To let the gravity of the but sink in, this is the pair of scripts
that I jammed in front of systemd that got it to somehow behave
itself:

/sbin/init:
#!/bin/sh

echo "INIT: rc init is in startup"

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

/etc/rc.earlyboot || PS1='init# ' PS2='init >' PS4='init +' exec /bin/sh -i

exec /lib/systemd/systemd

/etc/rc.earlyboot:
#!/bin/bash

exec 0<>/dev/tty1 1>&0 2>&1
chvt /dev/tty1

emergency()
{
echo "The previos command failed. Starting shell to investigate."
PS1='emergency# ' PS2='emergency> ' PS4='emergency+ ' /bin/bash
}

fsck -Asp
ERR=$?

if [ $((ERR & 2)) -ne 0 ]
thenecho "*** changed mounted filesystem, reboot requried ***"
sleep 3
reboot -f
fi

if [ $ERR -ne 0 ]
thenemergency
fi

mount / -o remount,rw || emergency
mount -a || emergency
swapon -a || emergency
exit 0

Bug#947808: libvncserver: Please backport small patch to fix unaligned access on sparc64

[John Paul Adrian Glaubitz]

Source: libvncserver
Version: 0.9.12+dfsg-5
Severity: normal
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hi!

The testsuite of libvncserver currently crashes on sparc64 due to
unaligned access:

Running tests...
/usr/bin/ctest --force-new-ctest-process -j32
Test project /<>/obj-sparc64-linux-gnu
Start 1: cargs
Start 2: turbojpeg
Start 3: wstest
1/3 Test #1: cargs    Passed0.01 sec
2/3 Test #3: wstest ...Bus error***Exception:   0.01 sec

3/3 Test #2: turbojpeg    Passed   16.52 sec

67% tests passed, 1 tests failed out of 3

Total Test time (real) =  16.52 sec

This has been fixed upstream in:

commit 0cf1400c61850065de590d403f6d49e32882fd76
Author: Rolf Eike Beer 
Date:   Tue May 28 18:30:46 2019 +0200

fix crash because of unaligned accesses in hybiReadAndDecode()

I'm attaching the backported patch. Could you include it in the
next upload?

Thanks,
Adrian

--
 .''`.  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 0cf1400c61850065de590d403f6d49e32882fd76 Mon Sep 17 00:00:00 2001
From: Rolf Eike Beer 
Date: Tue, 28 May 2019 18:30:46 +0200
Subject: [PATCH] fix crash because of unaligned accesses in
 hybiReadAndDecode()

---
 libvncserver/ws_decode.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libvncserver/ws_decode.c b/libvncserver/ws_decode.c
index 441ebc7..10c44d1 100644
--- a/libvncserver/ws_decode.c
+++ b/libvncserver/ws_decode.c
@@ -327,7 +327,6 @@ hybiReadAndDecode(ws_ctx_t *wsctx, char *dst, int len, int 
*sockRet, int nInBuf)
   int bufsize;
   int nextRead;
   unsigned char *data;
-  uint32_t *data32;
 
   /* if data was carried over, copy to start of buffer */
   memcpy(wsctx->writePos, wsctx->carryBuf, wsctx->carrylen);
@@ -383,10 +382,12 @@ hybiReadAndDecode(ws_ctx_t *wsctx, char *dst, int len, 
int *sockRet, int nInBuf)
   /* for a possible base64 decoding, we decode multiples of 4 bytes until
* the whole frame is received and carry over any remaining bytes in the 
carry buf*/
   data = (unsigned char *)(wsctx->writePos - toDecode);
-  data32= (uint32_t *)data;
 
   for (i = 0; i < (toDecode >> 2); i++) {
-data32[i] ^= wsctx->header.mask.u;
+uint32_t tmp;
+memcpy(, data + i * sizeof(tmp), sizeof(tmp));
+tmp ^= wsctx->header.mask.u;
+memcpy(data + i * sizeof(tmp), , sizeof(tmp));
   }
   ws_dbg("mask decoding; i=%d toDecode=%d\n", i, toDecode);
 
-- 
2.25.0.rc0

Bug#920589: CoqIDE supports GTK 3

[John Scott]

Control: unblock -1 885677
Control: forwarded -1 https://github.com/coq/coq/pull/9279
Control: tags -1 fixed-upstream

Unfortunately CoqIDE wasn't rebuilt for Buster. CoqIDE 8.10 supports lablgtk3 
though so it can be reintroduced

Bug#947807: systemd: can't install systemd when /etc/machine-id is a symbolic link to /dev/null

[Joshua]

Package: systemd
Version: 241-7~deb10u2
Severity: normal

Dear Maintainer,

/etc/machine-id should not be used on workstations anymore due to privacy 
reasons. The way to
disable it was announced as rm /etc/machine-id ; ln -s /dev/null 
/etc/machine-id at the time.

systemd's configuration script can't handle it.


-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-4
ii  libapparmor1 2.13.2-10
ii  libaudit11:2.8.4-3
ii  libblkid12.33.1-0.1
ii  libc62.28-10
ii  libcap2  1:2.25-2
ii  libcryptsetup12  2:2.1.0-5+deb10u2
ii  libgcrypt20  1.8.4-5
ii  libgnutls30  3.6.7-4
ii  libgpg-error01.35-1
ii  libidn11 1.33-2.2
ii  libip4tc01.8.2-4
ii  libkmod2 26-1
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.4-1
ii  libmount12.33.1-0.1
ii  libpam0g 1.3.1-5
ii  libseccomp2  2.3.3-4
ii  libselinux1  2.8-1+b1
ii  libsystemd0  241-7~deb10u2
ii  mount2.33.1-0.1
ii  util-linux   2.33.1-0.1

Versions of packages systemd recommends:
ii  dbus   1.12.16-1
ii  libpam-systemd-apt-holepunch [libpam-systemd]  1

Versions of packages systemd suggests:
ii  policykit-10.105-25
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.133+deb10u1
ii  udev 241-7~deb10u2

-- no debconf information

Bug#947806: systemd doesn't like my raid, times out waiting for online partitions to come online, and can't continue boot

[Joshua]

Package: systemd
Version: 241-7~deb10u2
Severity: important

Dear Maintainer,

   * What led up to the situation?

apt-get install systemd-sysv && reboot

   * What was the outcome of this action?

boots to emergency; journald spams the console with errors, can't login as 
nonroot, can't start X

   * What outcome did you expect instead?

system boots all the way to X login

It's not clear exactly what the problem is, but if I exit the emergency shell, 
booting hangs forever.
The system will go back to working correctly immediately on reinstalling 
sysvinit-sysv and rebooting.

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-4
ii  libapparmor1 2.13.2-10
ii  libaudit11:2.8.4-3
ii  libblkid12.33.1-0.1
ii  libc62.28-10
ii  libcap2  1:2.25-2
ii  libcryptsetup12  2:2.1.0-5+deb10u2
ii  libgcrypt20  1.8.4-5
ii  libgnutls30  3.6.7-4
ii  libgpg-error01.35-1
ii  libidn11 1.33-2.2
ii  libip4tc01.8.2-4
ii  libkmod2 26-1
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.4-1
ii  libmount12.33.1-0.1
ii  libpam0g 1.3.1-5
ii  libseccomp2  2.3.3-4
ii  libselinux1  2.8-1+b1
ii  libsystemd0  241-7~deb10u2
ii  mount2.33.1-0.1
ii  util-linux   2.33.1-0.1

Versions of packages systemd recommends:
ii  dbus   1.12.16-1
ii  libpam-systemd-apt-holepunch [libpam-systemd]  1

Versions of packages systemd suggests:
ii  policykit-10.105-25
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.133+deb10u1
ii  udev 241-7~deb10u2

-- no debconf information
[OVERRIDDEN] /etc/tmpfiles.d/screen-cleanup.conf -> 
/usr/lib/tmpfiles.d/screen-cleanup.conf

--- /usr/lib/tmpfiles.d/screen-cleanup.conf 2017-07-01 05:07:57.0 
-0700
+++ /etc/tmpfiles.d/screen-cleanup.conf 2019-02-24 13:04:03.007215314 -0800
@@ -1 +1 @@
-d /run/screen 0777 root utmp
+d /run/screen 1777 root utmp

[MASKED] /etc/systemd/system/bootlogs.service -> 
/lib/systemd/system/bootlogs.service
[MASKED] /etc/systemd/system/bootmisc.service -> 
/lib/systemd/system/bootmisc.service
[MASKED] /etc/systemd/system/checkfs.service -> 
/lib/systemd/system/checkfs.service
[MASKED] /etc/systemd/system/checkroot-bootclean.service -> 
/lib/systemd/system/checkroot-bootclean.service
[MASKED] /etc/systemd/system/checkroot.service -> 
/lib/systemd/system/checkroot.service
[MASKED] /etc/systemd/system/halt.service -> 
/lib/systemd/system/halt.service
[MASKED] /etc/systemd/system/hostname.service -> 
/lib/systemd/system/hostname.service
[MASKED] /etc/systemd/system/killprocs.service -> 
/lib/systemd/system/killprocs.service
[MASKED] /etc/systemd/system/mountall-bootclean.service -> 
/lib/systemd/system/mountall-bootclean.service
[MASKED] /etc/systemd/system/mountall.service -> 
/lib/systemd/system/mountall.service
[MASKED] /etc/systemd/system/mountdevsubfs.service -> 
/lib/systemd/system/mountdevsubfs.service
[MASKED] /etc/systemd/system/mountkernfs.service -> 
/lib/systemd/system/mountkernfs.service
[MASKED] /etc/systemd/system/mountnfs-bootclean.service -> 
/lib/systemd/system/mountnfs-bootclean.service
[MASKED] /etc/systemd/system/mountnfs.service -> 
/lib/systemd/system/mountnfs.service
[MASKED] /etc/systemd/system/rc.local.service -> 
/lib/systemd/system/rc.local.service
[MASKED] /etc/systemd/system/reboot.service -> 
/lib/systemd/system/reboot.service
[MASKED] /etc/systemd/system/rmnologin.service -> 
/lib/systemd/system/rmnologin.service
[MASKED] /etc/systemd/system/sendsigs.service -> 
/lib/systemd/system/sendsigs.service
[MASKED] /etc/systemd/system/single.service -> 
/lib/systemd/system/single.service
[MASKED] /etc/systemd/system/umountfs.service -> 
/lib/systemd/system/umountfs.service
[MASKED] /etc/systemd/system/umountnfs.service -> 
/lib/systemd/system/umountnfs.service
[MASKED] /etc/systemd/system/umountroot.service -> 
/lib/systemd/system/umountroot.service
[MASKED] /etc/systemd/system/urandom.service -> 
/lib/systemd/system/urandom.service
[EXTENDED]   /lib/systemd/system/rc-local.service -> 
/lib/systemd/system/rc-local.service.d/debian.conf
[EXTENDED]   /lib/systemd/system/systemd-resolved.service -> 
/lib/systemd/system/systemd-resolved.service.d/resolvconf.conf
[EXTENDED]   /lib/systemd/system/systemd-timesyncd.service -> 

Bug#942428: transition: gssdp/gupnp

[Laurent Bigonville]

Le 30/12/19 à 22:24, Paul Gevers a écrit :
> Hi Laurent, Andreas,
> What's the current status of the two packages reported unfixed? It's not
> clear if they either FTBFS or if they are just not tried to be fixed in
> experimental. I asked to have bugs filed, but I didn't spot them.
>
> peony-extensions - no rdeps, unmaintained <--- temporary removal?
>   not really, the package is
> aging now in unstable as it had recent updates
AFAICS peony-extensions has no dependency against gssdp or gupnp, so
that's fine I guess
> upnp-router-control - no rdeps, unmaintained for years <-- permament
> removal?

That package definitely look unmaintained (no upload since 2013), I see
some recent activity upstream (a few uploads in 2019, the previous
uploads where somewhere in 2013), but even the development branch does
not built with the last version of gssdp/gupnp

I've opened a bug upstream and I just opened a serious bug in debian

So I guess that removing the package from testing should be fine for now?

> If this is cleared up, we can probably go ahead.
>
> Paul
>

Bug#947805: Please port to gupnp/gssdp 1.2

[Laurent Bigonville]

Package: upnp-router-control
Version: 0.2-1.2
Severity: serious
Tags: sid buster
Forwarded: https://bugs.launchpad.net/upnp-router-control/+bug/1857942

Hello,

We are planning to upload gupnp/gssdp 1.2 to debian unstable.

Unfortunately upnp-router-control FTBFS with this version and needs to
be ported.

Could you please have a look at porting it to the latest version? I've
opened a bug upstream for that as well:
https://bugs.launchpad.net/upnp-router-control/+bug/1857942

Kind regards,

Laurent Bigonville

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

Kernel: Linux 5.4.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#946570: stretch-pu: package libpst/0.6.59-1+deb9u1

[Paul Wise]

On Mon, 2019-12-30 at 21:18 +, Adam D. Barratt wrote:

> Please go ahead.

Signed and uploaded.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#947804: raspi-firmware: raspi3-firmware transitional package should not have Architecture: all

[Sunil Mohan Adapa]

Package: raspi-firmware
Version: 1.20190819-2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

raspi3-firmware and raspi-firmware packages are not available in testing
currently. Tracker page reports the following problems:

Migration status for raspi-firmware (- to 1.20190819-2): BLOCKED:
Rejected/violates migration policy/introduces a regression
Issues preventing migration:
Updating raspi-firmware introduces new bugs: #941974
uninstallable on arch amd64, autopkgtest delayed there
Additional info:
raspi3-firmware/amd64 unsatisfiable Depends: raspi-firmware
raspi3-firmware/i386 unsatisfiable Depends: raspi-firmware
Cannot be tested by piuparts (not a blocker) - (no link yet)
24 days old (needed 5 days)
Not considered

Since #941974 seems to be closed now, I am lead to believe that the amd64/i386
problems reported above are preventing testing migrations. For raspi3-firmware
transitional package, setting 'Architecture: all' seems to make it available in
all architectures but since raspi-firmware on which it depends is available
only in 'arm64 armhf armel', this seems to cause the problem.

The problem might get fixed by setting 'Architecture: arm64 armhf armel' for
raspi3-firmware transitional package.

PS: #947614 might be referring to the same problem.

Thanks,

- --
Sunil



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

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

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAl4KkEMRHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfI4nw//W/ocLClFFnlLlEulLPQgaf/7FYLAUSMl
O6v0riToVBVgBzaGWycdBi7C4hATcmAw3lECkR4j+p71N8iT81Z9yzqA840CqclS
lgBtlx8leAamdXwEWt2O42qsJFWRJd9Ga4jW430sMIUOrmGIZFSkXaOWgGViLHjK
SPzs3GP3+NTHqbuDd9VPnjSvck90xQNiui/NKn4LyXFPtEqZEsu0OSteyGnYnN36
V5nMq7bQDiRD3wvgWJfoe335rG/R3loW7Rpnc5lCW0kMO7nS3wVkmNN5p6FLtx5V
tufT9npvhrB80mj42JtELvPNL+ZK13mdkBOJFofohjYbgRi8DSwOAW0Qv8iBqp9c
JbEJqvR1017U9oJ8dSW/hLu8QMnugmHwN/QzrLJeE2KIJ/WOzZ6C67x8JHkC9Km3
a8ub+XlQJMnfSjpElsw+c54zixy/9R9CJIxV/YstjeMS25ucFJRvx4K+/Wzr9tFS
5rs7QN508I/JfFN/8Mx1+nbvXzBel5xS8/us3wuzxO8LA/Ei3zOV52Q689yOT7ek
ovd1U5z6pO4MZAWjDdxd3dcGaUwNDJZJi4RyYM99Awaq9674MuafrxMMsizzMaYU
jqncNFgH+M7JLLcnuZs7G74zRQPzILVzCzYxkce/IEj+gT3QzRpghBanFKvwFYCX
CZsMmQ3EKOY=
=zsXV
-END PGP SIGNATURE-

Bug#947803: smartmontools: smartctl -l error causes Micron 2200S NVME to fail

[B]

Package: smartmontools
Version: 7.0-2
Severity: normal

I've discovered that running "smartctl -l error" against my new Dell XPS 13 
laptop with a Micron 2200S NVMe causes the drive to die. This obviously causes 
the entire system to fail, because the filesystem is no longer readable, until 
the power is pulled and then I can boot normally again.

The system is a Dell XPS 13 7390 tested with EFI version 1.3.1 and 1.4.0. The 
NVME is a Micron 2200S NVMe 512GB with firmware version 22001030.

I am on Debian unstable/sid. The problem occurs on kernel 5.4.0-1 and 5.3.0-3. 
smartctl --version says it's "7.0 2018-12-30 r4883 [x86_64-linux-5.3.0-3-amd64] 
(local build)".

I first saw the problem when running smartctrl -a against the NVME drive. Then 
I narrowed it down to being caused by "smartctrl -l error".

When the drive dies I get repeating errors in my syslog:

kernel: DMAR: DRHD: handling fault status reg 3
kernel: DMAR: [DMA Read] Request device [71:00.0] fault addr ffe48000 
[fault reason 06] PTE Read access is not set

I tried and failed to reproduce the problem on live images 
ubuntu-18.04.3-desktop-amd64.iso and ubuntu-19.10-desktop-amd64.iso.

If my memory is correct I also booted on the old 4.19.67-2+deb10u2 image and it 
worked okay there too, though that kernel lacks support for this hardware in 
many other respects.

I sent this report to the smartmontools mailing list and Christian Franke 
replied, saying he had never heard of such a thing before and had no idea.

I suspect this is some kernel problem rather than something wrong with 
smartmontools, but that's just a guess based on the evidence I've seen. I'm 
reporting against smartmontools first, but you might just want to reassign.




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

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

Versions of packages smartmontools depends on:
ii  debianutils  4.9.1
ii  libc62.29-6
ii  libcap-ng0   0.7.9-2.1+b1
ii  libgcc1  1:9.2.1-21
ii  libselinux1  3.0-1
ii  libstdc++6   9.2.1-21
ii  libsystemd0  244-3
ii  lsb-base 11.1.0

smartmontools recommends no packages.

Versions of packages smartmontools suggests:
ii  bsd-mailx [mailx]  8.1.2-0.20180807cvs-1+b1
ii  curl   7.67.0-2
ii  gpg2.2.17-3
pn  gsmartcontrol  
ii  lynx   2.9.0dev.4-1
ii  mailutils [mailx]  1:3.7-2
pn  smart-notifier 
ii  wget   1.20.3-1+b2

-- no debconf information

Bug#947802: policykit-1: pkexec can't handle sessions created by Xrdp

[Joshua]

Package: policykit-1
Version: 0.105-25
Severity: normal

Ignore version. Bug exists in every version.

pkexec can't handle sessions created by Xrdp. It clearly wants something from 
the session manager
that the session manager cannot provide. On the other hand, whatever it wants 
from the session manager,
it does not need.

Tried to configure a new policy kyt file in /usr/share/polkit-1/actions; 
discovered that it doesn't
matter what the file contains, nothing will run because pkexec can't find the 
currently logged-in session.
(This is a server. The only kinds of GUI logged in sessions are Xrdp and ssh 
-X.)

Tried setting up gtksu but it doesn't exist anymore.

Grumbled and rot out the C compiler and wrote a completely stupid 
suid-target-user binary that copies
.Xauthority and sets up environment variables and runs the target binary.

Apologies--I am having to re-report this bug from a different system as 
reportbug from the system with
the problem went to the bitbucket. I removed the obviously incorrect 
information below.

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1), LANGUAGE=en_US 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
LSM: AppArmor: enabled

Bug#947801: linux-image-5.3.0-3-amd64: b44 module unable to dma to address

[Jeffry J. Smith]

Package: src:linux
Version: 5.3.15-1
Severity: normal

Dear Maintainer,


   * What led up to the situation?
   Had been having lockup with swiotlb getting overloaded, added
   iommu=force, intel_iommu=on, swiotlb=noforce to fix.  Have reduced
   the swiotlb lockup, but now get a freeze on system with the b44 DMA
   below
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Attempting to figure out b44 parametrs to get DMA to work, searched
 with google on how to overcome DMA issues 
   * What was the outcome of this action? no luck
   * What outcome did you expect instead? Reduce DMA issues, stop
 freezes of system




-- Package-specific info:
** Version:
Linux version 5.3.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 
20191130 (Debian 9.2.1-21)) #1 SMP Debian 5.3.15-1 (2019-12-07)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.3.0-3-amd64 
root=UUID=f0a976b0-b2fa-418b-bdf5-d1666e3c05fb ro iommu=force intel_iommu=on 
swiotlb=noforce quiet

** Tainted: W (512)
 * Taint on warning.

** Kernel log:
[  321.030640] b44 :03:00.0: Cannot do DMA to address 0xc3e7f802
[  325.970842] swiotlb_map: 681 callbacks suppressed
[  325.970851] b44 :03:00.0: Cannot do DMA to address 0xc3e7f802
[  325.978046] b44 :03:00.0: Cannot do DMA to address 0xc3e78002
[  325.985252] b44 :03:00.0: Cannot do DMA to address 0xc3e78002
[  325.992504] b44 :03:00.0: Cannot do DMA to address 0xc3e7f802
[  325.999757] b44 :03:00.0: Cannot do DMA to address 0xc3e7c002
[  326.007003] b44 :03:00.0: Cannot do DMA to address 0xc3e7e002
[  326.014247] b44 :03:00.0: Cannot do DMA to address 0xc3e7b002
[  326.021437] b44 :03:00.0: Cannot do DMA to address 0xc3e79002
[  326.028655] b44 :03:00.0: Cannot do DMA to address 0xc3e7d002
[  326.035878] b44 :03:00.0: Cannot do DMA to address 0xc3e7e802
[  330.976083] swiotlb_map: 681 callbacks suppressed
[  330.976092] b44 :03:00.0: Cannot do DMA to address 0xc3e7f802
[  330.983295] b44 :03:00.0: Cannot do DMA to address 0xc3e7c002
[  330.990535] b44 :03:00.0: Cannot do DMA to address 0xc3e7e002
[  330.997751] b44 :03:00.0: Cannot do DMA to address 0xc3e7b002
[  331.005015] b44 :03:00.0: Cannot do DMA to address 0xc3e79002
[  331.012209] b44 :03:00.0: Cannot do DMA to address 0xc3e7d002
[  331.019415] b44 :03:00.0: Cannot do DMA to address 0xc3e7e802
[  331.026683] b44 :03:00.0: Cannot do DMA to address 0xc3e7c802
[  331.033945] b44 :03:00.0: Cannot do DMA to address 0xc3e7c802
[  331.041102] b44 :03:00.0: Cannot do DMA to address 0xc3e7e802
[  335.981437] swiotlb_map: 681 callbacks suppressed
[  335.981446] b44 :03:00.0: Cannot do DMA to address 0xc3e7d002
[  335.988568] b44 :03:00.0: Cannot do DMA to address 0xc3e7e802
[  335.995770] b44 :03:00.0: Cannot do DMA to address 0xc3e7c802
[  336.010229] b44 :03:00.0: Cannot do DMA to address 0xc3e7c802
[  336.017460] b44 :03:00.0: Cannot do DMA to address 0xc3e7e802
[  336.024678] b44 :03:00.0: Cannot do DMA to address 0xc3e7d002
[  336.031882] b44 :03:00.0: Cannot do DMA to address 0xc3e79002
[  336.039114] b44 :03:00.0: Cannot do DMA to address 0xc3e7b002
[  336.046375] b44 :03:00.0: Cannot do DMA to address 0xc3e7e002
[  336.053610] b44 :03:00.0: Cannot do DMA to address 0xc3e7c002
[  340.986518] swiotlb_map: 680 callbacks suppressed
[  340.986527] b44 :03:00.0: Cannot do DMA to address 0xc3e7d002
[  340.993788] b44 :03:00.0: Cannot do DMA to address 0xc3e79002
[  341.000963] b44 :03:00.0: Cannot do DMA to address 0xc3e7b002
[  341.008251] b44 :03:00.0: Cannot do DMA to address 0xc3e7e002
[  341.015466] b44 :03:00.0: Cannot do DMA to address 0xc3e7c002
[  341.022652] b44 :03:00.0: Cannot do DMA to address 0xc3e7f802
[  341.029887] b44 :03:00.0: Cannot do DMA to address 0xc3e78002
[  341.037124] b44 :03:00.0: Cannot do DMA to address 0xc3e78002
[  341.044388] b44 :03:00.0: Cannot do DMA to address 0xc3e7f802
[  341.051624] b44 :03:00.0: Cannot do DMA to address 0xc3e7c002
[  345.991870] swiotlb_map: 681 callbacks suppressed
[  345.991880] b44 :03:00.0: Cannot do DMA to address 0xc3e78002
[  345.999000] b44 :03:00.0: Cannot do DMA to address 0xc3e78002
[  346.006239] b44 :03:00.0: Cannot do DMA to address 0xc3e7f802
[  346.013465] b44 :03:00.0: Cannot do DMA to address 0xc3e7c002
[  346.020694] b44 :03:00.0: Cannot do DMA to address 0xc3e7e002
[  346.027896] b44 :03:00.0: Cannot do DMA to address 0xc3e7b002
[  346.035155] b44 :03:00.0: Cannot do 

Bug#947449: networking on Olimex Lime2 (Allwinner A20)

[Marek Nečada]

Hi,

Geert Stappers kirjoitti 27.12.2019 klo 19.24:
> Quoting https://linux-sunxi.org/Olimex_A20-OLinuXino-Lime2#GMAC_u-boot_config
> 
>  GMAC u-boot config
> 
>  From Revision H onward, the Lime2 comes with a Microchip KSZ9031
>  gigabit ethernet phyceiver. These need the following line added to the
>  u-boot config (in configs/A20-OLinuXino-Lime2_defconfig):
> 
>  CONFIG_GMAC_TX_DELAY=3
> 
>  Do not set this to another value but 3.
> 
>  This Microchip PHY chip is also getting significantly hotter than the
>  old Realtek RTL8201CP PHY. 
> 
> 
> Please report back how usefull this message was.

So I tried to build u-boot myself with the CONFIG_GMAC_TX_DELAY=3
directive, and I also tried to blindly copy the SPI+bootloader from an
Armbian image (in which the networking works properly), but in neither
case networking works (the other aspects are fine, the system boots
without problems, so I assume I did not break anything myself).

So I guess the issue lies elsewhere than in u-boot (perhaps the kernel?).

Marek

Bug#941947: RFS: misspell-fixer/0.1-1 [ITP] -- Tool for fixing common misspellings, typos in source code

[Lajos Veres]

On Mon, 30 Dec 2019, Adam Borowski wrote:

> On Mon, Dec 30, 2019 at 12:00:31AM +, Lajos Veres wrote:
> > I have just uploaded a newer version:
> > https://mentors.debian.net/package/misspell-fixer
> > https://mentors.debian.net/debian/pool/main/m/misspell-fixer/misspell-fixer_0.2-1.dsc
>
> Hi!

Thanks for checking it.

> While the only change I disagree with is removal of Vcs-Browser, the

I misunderstood first this:

https://www.debian.org/doc/debian-policy/upgrading-checklist.html#version-4-4-1
---
A package control file must not have more than one Vcs- field.
---

Anyway I have just reverted it.

> changelog really should contain something other than:
>  * Debian packaging tweaks.
>
> That line could cover anything but "New upstream release"...
>
> Could you please mention what actually got changed?

Yes. Done.
(The main bits of the new upstream release are the packaging tweaks. I
have described them a little better. I hope I have not misunderstood
anything. :)

I have just uploaded a newer version with the fixes to the same place.

Best regards,
Lajos

>
> Meow!
>

-- 
Lajos Veres
vla...@gmail.com
07927 460 778

Bug#937267: Is there any Python3 version of pebl

[Abhik Shah]

The first link is mine and the original fork but its basically abandoned. I
haven’t looked at any of the forks so unsure which are popular or being
kept up-to-date.

On Mon, Dec 30, 2019 at 12:56 PM Andreas Tille  wrote:

> Hi Abhik,
>
> thanks for the quick reply.
>
> On Sun, Dec 29, 2019 at 05:55:35PM -0800, Abhik Shah wrote:
> > I haven’t made a py3 port and actually haven’t worked on Pebl in years.
> > There are some forks though (on github) and they may have py3 versions.
>
> This one looks official
>
>https://github.com/abhik/pebl
>
> I've found another clone
>
>https://github.com/arnaudsj/pebl
>
> which has just one commit less.  Any hint what fork could be recommended
> for a py3 port?
>
> Kind regards
>
>  Andreas.
>
> > On Sun, Dec 29, 2019 at 5:38 AM Andreas Tille  wrote:
> >
> > > Control: tags -1 upstream
> > > Control: forwarded -1 abhiks...@gmail.com
> > >
> > > Hi,
> > >
> > > Python2 is End Or Life at 1.1.2020 and Debian is about to remove
> > > all Python2 dependencies.  I wonder if there is any Python2 port
> > > of Pebl.  I just found
> > >
> > >https://pypi.org/project/pebl/
> > >
> > > which is at version 1.01 while it seems that at googlecode once
> > > was a version 1.0.2 - at least the Debian package is at this
> > > version.  Could you please clarify whether there is some Python3
> > > version of pebl somewhere else?
> > >
> > > Kind regards
> > >
> > >  Andreas.
> > >
> > > --
> > > http://fam-tille.de
> > >
>
> --
> http://fam-tille.de
>

Bug#947780: libcrypt1: keep from migrating to testing until libcrypt{,1}-dev situation is fixed in glibc

[Thorsten Glaser]

Marco d'Itri dixit:

>>   a new source-only upload and piuparts fails testing, though
>>   the latter might be due to the glibc issue maybe?
>No, this is an unrelated piuparts bug which was fixed yesterday.

Ah okay.

In the meantime, a new glibc was uploaded and just needs to
finish building on all release architectures, then I’ll close
this bug here as well.

bye,
//mirabilos
-- 
08:05⎜ mika: Does grml have an tool to read Apple
 ⎜System Log (asl) files? :)
08:08⎜ yeah. /bin/rm. ;)   08:09⎜ hexdump -C
08:31⎜ ft, mrud: *g*

Bug#947800: dh-python: pybuild copying of testfiles loses directory structure

[Scott Talbert]

Package: dh-python
Version: 4.20191017
Severity: normal

When a file or directory such as a/b/c.txt is listed in 
pybuild.testfiles, when it is copied to the build directory, the 
directory structure portion is lost.  Tests expect certain data files to 
exist in certain location so this makes it hard to use the 
pybuild.testfiles feature.  It seems that pybuild.testfiles should 
retain the original directory structure of the listed files.

Bug#946560: stretch-pu: package proftpd-dfsg/1.3.5b-4+deb9u3

[Adam D. Barratt]

Hi,

On Mon, 2019-12-30 at 23:27 +0100, Hilmar Preuße wrote:
> Am 30.12.2019 um 22:21 teilte Adam D. Barratt mit:
> > On Tue, 2019-12-10 at 23:51 +0100, Hilmar Preusse wrote:
[...]
> > +  *  Cherry pick patch from upstream:
> > + - for upstream 861 (CVE-2019-19269) (Closes: #946345)
> > + upstream_pull_861_CVE-2019-19269
> > 
> > I'm not sure whether that final line was intended to be included.
> > 
> Yes, this is the name of the patch, which has been added.

It's not quite, which was what led to the query:

+upstream_861_CVE-2019-19269

> > Please go ahead.
> > 
> Not sure, what you want to tell me. Should I simply upload the
> package w/ the corrections above?

That was the intention, yes.

> Will it be accepted, even if I'm not a DD (I
> have upload permits for that package as DM)?

That wasn't clear from your mail. I believe it should work, however. If
not, then dak will reject the package and you will need to find a
sponsor.

Regards,

Adam

Bug#947780: libcrypt1: keep from migrating to testing until libcrypt{,1}-dev situation is fixed in glibc

[Marco d'Itri]

On Dec 30, Thorsten Glaser  wrote:

> ① it won’t migrate as-is currently anyway, because it needs
>   a new source-only upload and piuparts fails testing, though
>   the latter might be due to the glibc issue maybe?
No, this is an unrelated piuparts bug which was fixed yesterday.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#927230: cross-gcc-dev: gcc-9 patch application failure

[Dima Kogan]

I just uploaded cross-gcc-dev=242 to apply this patch. I did just try to
actually build a cross compiler using these patches (something I haven't
done in a long time), and this patch is clearly necessary.

The build still didn't complete, because some other patch in
gcc-9-source doesn't apply anymore. This has nothing to do with the
cross-building, and I suspect that your problem is fixed now. Please let
me know if you still have trouble building, and I can look more deeply,
if necessary.

Bug#946560: stretch-pu: package proftpd-dfsg/1.3.5b-4+deb9u3

[Hilmar Preuße]

Am 30.12.2019 um 22:21 teilte Adam D. Barratt mit:
> On Tue, 2019-12-10 at 23:51 +0100, Hilmar Preusse wrote:

Hi Adam,

>> #946345 proftpd-dfsg: CVE-2019-19269
>>
>> ...for Debian stretch. I built/installed the package an Debian
>> oldstable and could login into the server and transfer file.
> 
> +proftpd-dfsg (1.3.5b-4+deb9u3) stretch-security; urgency=medium
> 
> The distribution for a stretch-pu upload should simply be "stretch".
> 
Thanks, will fix that.

> +  *  Cherry pick patch from upstream:
> + - for upstream 861 (CVE-2019-19269) (Closes: #946345)
> + upstream_pull_861_CVE-2019-19269
> 
> I'm not sure whether that final line was intended to be included.
> 
Yes, this is the name of the patch, which has been added.

> Please go ahead.
> 
Not sure, what you want to tell me. Should I simply upload the package
w/ the corrections above? Will it be accepted, even if I'm not a DD (I
have upload permits for that package as DM)?

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#947799: RM: sm-archive -- ROM; nobody cares about it

[Marco d'Itri]

Package: ftp.debian.org
Severity: normal

Popcon of 5, orphaned by me two years ago, last upload in 2010.
Let's try to keep the cruft out of the archive!

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#947798: dh-make: custom templates cannot contain directories

[Robin Gustafsson]

Package: dh-make
Version: 2.201802
Severity: normal
Tags: patch

Dear Maintainer,

Custom templates currently cannot contain directories. This makes it impossible
to use custom templates for certain files, e.g. source/options.

  Unable to open file /tmp/template/source for reading: Is a directory

It would be more useful for custom templates to also be processed recursively,
like the built-in templates are.

Regards,
Robin


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

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

Versions of packages dh-make depends on:
ii  debhelper  12.1.1
ii  dpkg-dev   1.19.7
ii  make   4.2.1-1.2
ii  python33.7.3-1

dh-make recommends no packages.

Versions of packages dh-make suggests:
ii  build-essential  12.6

-- no debconf information
>From d56bf66a5e5fcb97632430fdc4eabb967c98dc3c Mon Sep 17 00:00:00 2001
From: Robin Gustafsson 
Date: Mon, 30 Dec 2019 15:56:58 +0100
Subject: [PATCH] Support directories in custom templates

---
 dh_make | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/dh_make b/dh_make
index b8a3a7c..6526a4a 100755
--- a/dh_make
+++ b/dh_make
@@ -73,13 +73,19 @@ def process_dhlib(args, subs_func, subdir, destdir=''):
 process_file(args, subs_func, file, os.path.join(destdir, f))
 
 
-def process_dir(args, subs_func, adir):
+def process_dir(args, subs_func, adir, destdir=''):
 '''
-Find all templates in custom directory
+Recursively find all templates in custom directory
 and process them into our debian directory
 '''
 for f in os.listdir(adir):
-process_file(args, subs_func, os.path.join(adir, f), f)
+file = os.path.join(adir, f)
+dest = os.path.join(destdir, f)
+if os.path.isdir(file):
+os.mkdir(dest, 0o755)
+process_dir(args, subs_func, file, dest)
+else:
+process_file(args, subs_func, file, dest)
 
 
 def process_copyright(args, subs_func):
-- 
2.20.1

Bug#947797: perl: prove --archive fails with error: should suggest libtap-harness-archive-perl

[Jonas Smedegaard]

Package: perl
Version: 5.30.0-9
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The command-line tool "prove" part of the perl package fails when passed
option --archive:

  TAP::Harness::Archive is required to use the --archive feature: Can't locate 
TAP/Harness/Archive.pm in @INC (you may need to install the 
TAP::Harness::Archive module)

Please have perl suggest libtap-harness-archive-perl

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl4KdFoACgkQLHwxRsGg
ASHEJw/+MmjkzXgHuhkygWOfSu/tuFT/6Tic2ZFCQWiBa9/WifR9e1RU2nw3YQHl
SbU53nfORCDn/YzZII5jLZ8K6aye/PSsEnblG0zfJH8cE3EQQhBUBwcRpsBuXOcc
grKq9kC8ucaBjXzs4RAGjTjmhp62n2frtDgd55ILstg01YnBPq8YbXuHoAxIMQh3
pym/3epytKWTOaCMuqD5ENKjcRQKNaJsOtBbadcqhT7oHPfCfcC/XH2IyQKr+be/
2tUXjzNkhYCOiXoOn1thOyZzmya+TsMHD4DKYBwNV3+cJv7iKQLUTc2bjv511Gy9
FS871StRbj5WjU78nxuYTyyANHzLi/rJkrcVUmMTBVy+GoMNrKXCGdBSk7y3kYde
ohAOMYwrnizpqq9WStltuyl/jeo+S8RuAZDWoLU9F1Sao0pvirlext0PIoUtiCjz
KkQRnep3Nrs9jRxvVpwzgmAsNPjIHobqXO7MIlsM56EEt3kovXyZaV3iIP8OWjAy
Z+U8wCoUetOpnr7uowUPA5unb04IOkxpUbXJCNWgapC9ZDok+w+7rzVfDjGyYN04
pUX42g4pOyh7pwj8c76B6ihRYmL+p40blCKtMTTHWxEbHQlL8H/wT+n5siW9pfS5
kizaYzXcIxSqhzNG7EwCf41BhSTv5IrUJ0a963lN9f2OzhdNqC8=
=OKv4
-END PGP SIGNATURE-

Bug#945920: Random Chromium crashes

[Eloston]

Alright, here's a revised process to compile Chromium locally with tracing re-
enabled:

1. First, download the patch and save it as "enable-tracing.patch"
2. Run the following:

$ wget
https://salsa.debian.org/chromium-team/chromium/-/archive/c88b97a6dc183a6a7f8a05aee9e99957285a9371/chromium-c88b97a6dc183a6a7f8a05aee9e99957285a9371.tar.bz2
$ tar xf chromium-c88b97a6dc183a6a7f8a05aee9e99957285a9371.tar.bz2
$ cd chromium-c88b97a6dc183a6a7f8a05aee9e99957285a9371
$ patch -p1 < enable-tracing.patch
# mk-build-deps -i debian/control
$ ./debian/rules get-orig-source
$ cd chromium-79.0.3945.79
$ dpkg-buildpackage -b -uc

After several hours, packages should appear in chromium-
c88b97a6dc183a6a7f8a05aee9e99957285a9371

Regards,
Eloston
commit 9a07b14585c4948d3baf2763d0f71ac5b3af758c
Author: Eloston 
Date:   Mon Dec 30 21:34:23 2019 +

Revert disabling tracing

diff --git a/debian/copyright b/debian/copyright
index ef2174d..f81086c 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -37,7 +37,6 @@ Files-Excluded:
  chrome/installer/launcher_support
  chrome/common/extensions/docs
  chrome/common/safe_browsing/rar_analyzer.*
- chrome/browser/tracing
  chrome/browser/resources/chromeos
  chrome/browser/resources/default_apps
  chrome/test/data/android
@@ -45,7 +44,6 @@ Files-Excluded:
  chrome/test/data/extensions
  chrome/test/data/webui/i18n_process_css_test.html
  chrome/chrome_cleaner/test/resources/signed_dll
- services/tracing
  tools/emacs
  tools/luci-go
  tools/android
@@ -116,7 +114,6 @@ Files-Excluded:
  third_party/expat/src
  third_party/*rjsmin/bench
  third_party/unrar
- third_party/perfetto
  third_party/checkstyle
  third_party/swiftshader
  third_party/apache-win32
@@ -150,23 +147,6 @@ Files-Excluded:
  third_party/devtools-node-modules
  third_party/blanketjs/src/blanket.js
  third_party/accessibility-audit/axs_testing.js
- third_party/catapult/tracing
- third_party/catapult/third_party/flot
- third_party/catapult/third_party/chai
- third_party/catapult/third_party/vinn
- third_party/catapult/third_party/mocha
- third_party/catapult/third_party/coverage
- third_party/catapult/third_party/polymer2
- third_party/catapult/third_party/polymer3
- third_party/catapult/third_party/polymer/components
- third_party/catapult/third_party/d3/d3.min.js
- third_party/catapult/third_party/redux/redux.min.js
- third_party/catapult/experimental/heatmap/power.js
- third_party/catapult/experimental/heatmap/smoothness.js
- third_party/catapult/experimental/trace_on_tap/third_party/pako/pako_deflate.min.js
- third_party/catapult/third_party/gsutil
- third_party/catapult/third_party/Paste/paste/evalexception/media/MochiKit.packed.js
- third_party/catapult/telemetry/telemetry/internal/testing/perf_report_output.txt
  third_party/webrtc/sdk
  third_party/webrtc/data
  third_party/webrtc/examples
diff --git a/debian/patches/series b/debian/patches/series
index cc98644..42ca728 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -39,11 +39,9 @@ disable/owners.patch
 disable/signin.patch
 disable/android.patch
 disable/fuzzers.patch
-disable/tracing.patch
 disable/openh264.patch
 disable/buildbot.patch
 disable/chromeos.patch
-disable/perfetto.patch
 disable/installer.patch
 disable/font-tests.patch
 disable/swiftshader.patch
diff --git a/debian/rules b/debian/rules
index 59b541d..cafc753 100755
--- a/debian/rules
+++ b/debian/rules
@@ -199,16 +199,14 @@ get-orig-source:
 	patch -p1 < debian/scripts/mk-origtargz.patch
 	date +%s > $(seconds)
 	perl debian/scripts/mk-origtargz ../$(tarball) > $(removed)
+	echo $(extract)/third_party/perfetto/ui/src/gen >> $(removed)
 	echo $$(($$(date +%s) - $$(cat $(seconds seconds
 	test ! -e $(extract) || rm -rf $(extract)
 	tar xf ../$(tarball)
 	echo $$(($$(date +%s) - $$(cat $(seconds seconds
-	while read line; do rm -rf $$line; done < $(removed)
+	xargs rm -rf < $(removed)
 	cd $(extract) && ../debian/scripts/check-upstream
-	echo $$(($$(date +%s) - $$(cat $(seconds seconds
-	test ! -e $(origtxz) || rm -f $(origtxz)
-	tar cf - $(extract) | xz -6 -T $(njobs) - > $(origtxz)
-	echo $$(($$(date +%s) - $$(cat $(seconds seconds
-	rm -rf $(extract)
 	echo $$(($$(date +%s) - $$(cat $(seconds seconds | tee seconds
 	@mv -f seconds $(seconds)
+	test ! -e debian || rm -rf debian
+	cp -r ../debian ./

Bug#947796: ITP: r-cran-uwot -- Uniform Manifold Approximation and Projection (UMAP) Method

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-uwot -- Uniform Manifold Approximation and Projection 
(UMAP) Method
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-uwot
  Version : 0.1.3
  Upstream Author : James Melville 
* URL : https://cran.r-project.org/package=uwot
* License : GPL-3+
  Programming Lang: GNU R
  Description : Uniform Manifold Approximation and Projection (UMAP) Method
 An implementation of the Uniform Manifold Approximation and
 Projection dimensionality reduction by McInnes et al. (2018)
 . It also provides means to transform new data and to
 carry out supervised dimensionality reduction. An implementation of the
 related LargeVis method of Tang et al. (2016)  is also
 provided.
 .
 This is a complete re-implementation in R (and C++, via the 'Rcpp'
 package): no Python installation is required. See the uwot website
 () for more documentation and examples.

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

Bug#937103: nagios-plugins-contrib: Python2 removal in sid/bullseye

[Sandro Tosi]

> nagios-plugins-contrib is virtually the only rdep for python-pymongo,
> and it looks like the code from the last update already supports
> python3: could you change check_mongodb/check_mongodb.py shebang to
> point to py3k and update the recommends to python3-pymongo? this way
> we could drop the py2 support from src:pymongo. there's a percona
> mongo check too, but tbh it hasnt been updated in 5 years upstream,
> and python-pymongo is only a suggests there, so maybe we can ignore
> it?
>
> other checks depending on python2:
>
> * check_graphite/check_graphite.py
>   - very old check (upstream last change 8years ago)
>   - does it even work anymore?
>   - seems trivial to port to python3, a quick `2to3` reveals just some
> very basic changes
> * check_libs_ng/check_libs_ng
>   - this looks almost ready to get its shebang switched to py3k, small
> `2to3` fix to apply
> * percona-nagios-plugins/nagios/bin/pmp-check-aws-rds.py
>   - really old script, should be verified if it still works properly
>   - `2to3` suggests really basic changes, maybe let's apply them?
>
> please let me know what you think about this, definitely prioritizing
> dropping python-pymongo would help a lot; i can help
> preparing/committing the changes, but i wont be able to test them out
> myself in real-world examples.

I've opened 
https://salsa.debian.org/nagios-team/pkg-nagios-plugins-contrib/merge_requests/4
to port the py2 checks to python3 (i didnt really test them tho) and
the various bits of packaging that required change either to the py3k
port or to make the package build.

please let me know what you think about it, if i dont hear back within
week, i'll very likely NMU 0-day the package (so that we can remove
the python2 package from pymongo, since this package is the last rdeps
of them).

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#946559: buster-pu: package proftpd-dfsg/1.3.6-4+deb10u3

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2019-12-10 at 23:48 +0100, Hilmar Preusse wrote:
> te attached debdiff fixes the issues
> 
> #946345 proftpd-dfsg: CVE-2019-19269
> #946346 proftpd-dfsg: CVE-2019-19270
> 
> ...for Debian buster. I built/installed the package an Debian stable
> and could login into the server and transfer file.

+proftpd-dfsg (1.3.6-4+deb10u3) buster-security; urgency=medium

No "-security" for p-u, please.

+  * Cherry pick patch from upstream:
+ - for upstream 861 (CVE-2019-19269) (Closes: #946345)
+ - for upstream 859 (CVE-2019-19270) (Closes: #946346)
+ upstream_pull_859_861_CVE-2019-19270_CVE-2019-19269

Please go ahead.

Regards,

Adam

Bug#942428: transition: gssdp/gupnp

[Paul Gevers]

Hi Laurent, Andreas,

On 30-12-2019 15:09, Laurent Bigonville wrote:
> So apparently this was a bug in gupnp that was making the tests deadlock
> and for some reasons the version fixing this was stuck in the armel
> buildd...
> 
> anyway, gupnp-igd is now building fine in experimental.

Good.

> I think most of the work is already done in experimental, could we go
> forward?

What's the current status of the two packages reported unfixed? It's not
clear if they either FTBFS or if they are just not tried to be fixed in
experimental. I asked to have bugs filed, but I didn't spot them.

peony-extensions - no rdeps, unmaintained <--- temporary removal?
  not really, the package is
aging now in unstable as it had recent updates

upnp-router-control - no rdeps, unmaintained for years <-- permament
removal?

If this is cleared up, we can probably go ahead.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#946560: stretch-pu: package proftpd-dfsg/1.3.5b-4+deb9u3

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2019-12-10 at 23:51 +0100, Hilmar Preusse wrote:
> te attached debdiff fixes the issues
> 
> #946345 proftpd-dfsg: CVE-2019-19269
> 
> ...for Debian stretch. I built/installed the package an Debian
> oldstable and could login into the server and transfer file.

+proftpd-dfsg (1.3.5b-4+deb9u3) stretch-security; urgency=medium

The distribution for a stretch-pu upload should simply be "stretch".

+  *  Cherry pick patch from upstream:
+ - for upstream 861 (CVE-2019-19269) (Closes: #946345)
+ upstream_pull_861_CVE-2019-19269

I'm not sure whether that final line was intended to be included.

Please go ahead.

Regards,

Adam

Bug#946705: buster-pu: package php-horde/5.2.20+debian0-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2019-12-13 at 22:55 -0500, Roberto C. Sanchez wrote:
> Please find attached a proposed debdiff for php-horde.  The change
> fixes CVE-2019-12095, which the security team has classified as  dsa>, deeming it a minor issue which can be fixed via a point
> release.  May I have permission to upload to buster-proposed-updates?
> 

Please go ahead.

Regards,

Adam

Bug#946704: stretch-pu: package php-horde/5.2.13+debian0-1+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2019-12-13 at 22:54 -0500, Roberto C. Sanchez wrote:
> Please find attached a proposed debdiff for php-horde.  The change
> fixes CVE-2019-12095, which the security team has classified as  dsa>, deeming it a minor issue which can be fixed via a point
> release.  May I have permission to upload to stretch-proposed-
> updates?

Please go ahead.

Regards,

Adam

Bug#944227: ready to complete transition

[Gordon Ball]

The packages which I was waiting for (python-backcall, ipython-py2) have
now cleared NEW, so for me I'm ready to proceed.

Unless there are any objections, I propose to upload prompt-toolkit 2.0
(as per experimental, plus the Breaks: listed above) to unstable in
during the first week of January.

Bug#946570: stretch-pu: package libpst/0.6.59-1+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2019-12-11 at 11:02 +0800, Paul Wise wrote:
> The version of libpst in stretch does not use
> AC_USE_SYSTEM_EXTENSIONS, which means that _GNU_SOURCE is not defined
> before including unistd.h, which means that get_current_dir_name is
> not defined and so gcc presumes it returns an integer, which means
> that the returned pointer gets truncated on some architectures and
> later when the pointer gets freed a program using libpst could crash.

Please go ahead.

Regards,

Adam

Bug#946841: buster-pu: package simplesamlphp/1.16.3-1+deb10u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2019-12-16 at 14:27 +0100, Thijs Kinkhorst wrote:
> The simpleSAMLphp package in buster suffers from an incompatibility
> with PHP 7.3 (also shipped in buster) that can be fixed with a one
> character change.
> 
> The bug report is at https://bugs.debian.org/944820
> 
> This was missed during the release cycle because the already existing
> and working simplesamlphp package was not fully re-tested when PHP
> 7.3 was introduced into buster.
> 

Please go ahead.

Regards,

Adam

Bug#946901: buster-pu: package unhide/20130526-3+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2019-12-17 at 11:49 -0300, Thiago Andrade Marques wrote:
> I would like to upload the debdiff available below to fix a
> segmentation fault in unhide.
> The reason for this behaviour is that the application is exhausting
> its stack by allocation an integer array with maxpid elements.
> 

Please go ahead.

Regards,

Adam

Bug#946907: stretch-pu: package unhide/20130526-1+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2019-12-17 at 14:39 -0300, Thiago Andrade Marques wrote:
> Package: release.debian.org
> Severity: important

For reference, pu requests are <= normal.

> I would like to upload the debdiff available below to fix a
> segmentation fault in unhide.
> The reason for this behaviour is that the application is exhausting
> its stack by allocation an integer array with maxpid elements.
> 

Please go ahead.

Regards,

Adam

Bug#946960: buster-pu: package debian-security-support/2019.12.12~deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2019-12-18 at 14:55 +0100, Holger Levsen wrote:
>   * security-support-limited: point to 
> https://www.debian.org/releases/ \
> buster/amd64/release-notes/ch-information.en.html#golang-static-
> linking
> for golang* packages.
>   * Remove nodejs from security-support-limited as it is supported
> since the
> Buster release. Closes: #931376.
>   * check-support-status.in: set DEB_NEXT_VER_ID=11.
>   * d/rules: update to NEXT_VERSION_ID=11.
> 

Please go ahead.

Regards,

Adam

Bug#946083: buster-pu: package opensmtpd/6.0.3p1-5

[Adam D. Barratt]

Control: tags -1 -moreinfo +confirmed

On Sat, 2019-12-21 at 21:07 -0500, Ryan Kavanagh wrote:
> Hi,
> 
> On Sun, Dec 08, 2019 at 08:43:17PM +, Adam D. Barratt wrote:
> > Why is the dpkg-statoverride call using --force-all? It should only
> > be executing if no existing override exists, unless I'm missing
> > something.
> 
> You're right, it should not be used and I've dropped it from the
> patch.
> In the process, I discovered another bug (the statoverride needs to
> be removed before the group at purge time), which has since been
> fixed in unstable. I've attached a revised debdiff.

--- a/debian/NEWS
+++ b/debian/NEWS
@@ -1,3 +1,28 @@
+opensmtpd (6.0.3p1-5+b10u1) buster; urgency=medium

--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+opensmtpd (6.0.3p1-5+b10u1) buster; urgency=medium

You want +deb10u1 in each case, rather than +b10u1. With that change,
please go ahead.

Regards,

Adam

Bug#941657: name change: python-lark-parser -> python-lark

[Thomas Andrejak]

Hello

I asked "why changing the name" because (OK, I'm the author of some, but
not all) :
- On Fedora/EPEL : it is lark-parser
https://src.fedoraproject.org/rpms/python-lark-parser
- On gentoo : it is lark-parser
https://github.com/gentoo/gentoo/tree/master/dev-python/lark-parser
- On Arch Linux : it is lark-parser
https://www.archlinux.org/packages/community/any/python-lark-parser/
- On OpenSuse : it is lark-parser
https://software.opensuse.org/package/python-lark-parser

After that, I understand all arguments. I let you choose the final name. In
the end, the most important is to be able to do "import lark" :)

Regards

Thomas

Le lun. 30 déc. 2019 à 21:43, Simon McVittie  a écrit :

> On Mon, 30 Dec 2019 at 17:15:54 +0100, Peter Wienemann wrote:
> > https://bugs.debian.org/945823
> >
> > which says:
> >
> > "use the name you import in preference to the name from the PKG-INFO".
> >
> > That is why I decided to change the name to python-lark. But given the
> > PyPI name clash this is certainly not optimal either. So this seems to
> > be a particular unfortunate case.
>
> If there are two modules on PyPI, both of which you use via
> "import lark", then they cannot both be installed correctly into the
> system-wide module search path on the same Debian system - if they
> were, even if they happen to avoid having directly conflicting files
> (because one is /usr/lib/python3/dist-packages/lark.py and the other is
> /usr/lib/python3/dist-packages/lark/__init__.py, or similar), installing
> both and using "import lark" would not consistently import the one you
> intended to use, leading to broken programs.
>
> So the rule has served its purpose: it has detected a conflict that needs
> to be avoided somehow.
>
> For users of virtualenv there is perhaps no problem, because you can
> install the lark you wanted in a particular virtualenv and avoid installing
> the other lark, but Debian packages are a flat global namespace of modules.
>
> There are two options:
>
> * If "lark" on PyPI is a dead project, or otherwise something that is never
>   going to be useful to package in Debian for some reason, then perhaps
> it's
>   safe for the lark parser to claim the python3-lark name.
>
> * Otherwise, if its PyPI name is lark-parser, then I would personally
>   recommend asking the upstream developer to rename the module you import
>   to lark_parser (or maybe larkparser if that's preferred), and packaging
>   it as python3-lark-parser (or python3-larkparser), optionally with
>   compatibility glue to make "import lark" continue to work (which might
> not
>   get packaged in Debian).
>
> (I'm talking about binary package names python3-foo because those are the
> most important thing for avoiding conflicts, but if the binary package
> name is python3-foo then it probably makes most sense for the source
> package to be python-foo.)
>
> smcv
>

Bug#947125: buster-pu: package cyrus-imapd/3.0.8-6+deb10u4

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2019-12-23 at 18:55 +0100, Xavier wrote:
> Le 22/12/2019 à 17:32, Adam D. Barratt a écrit :
[...]
> > The patch also adds "CONVERSATIONS|SEARCH_INDEXED|SORTCACHE" to
> > another
> > clause, which was the bit I was querying.
> 
> Sorry, all values set in cyrus-db-types.txt are now included in this
> script to avoid another failure

Thanks. It might be worth being explicit about that in the changelog.

Please go ahead.

Regards,

Adam

Bug#937267: Is there any Python3 version of pebl

[Andreas Tille]

Hi Abhik,

thanks for the quick reply.

On Sun, Dec 29, 2019 at 05:55:35PM -0800, Abhik Shah wrote:
> I haven’t made a py3 port and actually haven’t worked on Pebl in years.
> There are some forks though (on github) and they may have py3 versions.

This one looks official

   https://github.com/abhik/pebl

I've found another clone

   https://github.com/arnaudsj/pebl

which has just one commit less.  Any hint what fork could be recommended
for a py3 port?

Kind regards

 Andreas. 
 
> On Sun, Dec 29, 2019 at 5:38 AM Andreas Tille  wrote:
> 
> > Control: tags -1 upstream
> > Control: forwarded -1 abhiks...@gmail.com
> >
> > Hi,
> >
> > Python2 is End Or Life at 1.1.2020 and Debian is about to remove
> > all Python2 dependencies.  I wonder if there is any Python2 port
> > of Pebl.  I just found
> >
> >https://pypi.org/project/pebl/
> >
> > which is at version 1.01 while it seems that at googlecode once
> > was a version 1.0.2 - at least the Debian package is at this
> > version.  Could you please clarify whether there is some Python3
> > version of pebl somewhere else?
> >
> > Kind regards
> >
> >  Andreas.
> >
> > --
> > http://fam-tille.de
> >

-- 
http://fam-tille.de

Bug#947321: buster-pu: package dkimpy/0.9.1-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2019-12-24 at 11:27 -0500, Scott Kitterman wrote:
> This proposed update includes fixes for all user reported bugs since
> the last version available before buster froze.  These are all issues
> reported by actual package users (not all on Debian).  The two most
> imoprtant issues are:
> 
>  - Updating the ARC (Authenticated Receive Chain) code to match the
>final version of the spec.  RFC 8617 is published not, so it is
>highly unlikely to change again during Buster's lifetime.
> 
>  - Ignoring unknown service types: Since 0.9.1 was released, a new
> DKIM
>service type, TLSRPT, has been defined and is starting to see use.
>RFC 6376 (DKIM RFC) always required unknown service types to be
>ignored, but since there had only ever been one, that check was
> never
>implemented.  This change will prevent mis-processing of TLSRPT
>service signatures.

Please go ahead.

Regards,

Adam

Bug#947524: geary: build-depends on deprecated gnome-doc-utils

[Andreas Henriksson]

Control: tags -1 + pending

On Fri, Dec 27, 2019 at 10:21:51PM +, Simon McVittie wrote:
> Source: geary
[...]
> This package Build-Depends on gnome-doc-utils.
[...]

https://salsa.debian.org/gnome-team/geary/commit/c5f02ebbd1e42bf4fa5a79ceae02ece7f8e5a7ff

Fix should be part of next upload (whoever does that)

Regards,
Andreas Henriksson

Bug#945845: buster-pu: package qtwebengine-opensource-src/5.11.3+dfsg-2+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2019-12-03 at 11:30 +0300, Dmitry Shachnev wrote:
> Dear Release team,
> 
> On Fri, Nov 29, 2019 at 11:10:16PM +0300, Dmitry Shachnev wrote:
> > This update fixes bug #919504 that is also known as #929286,
> > #931860,
> > #933278 and #945147.
> > 
> > The debdiff is attached. Please see the header of the added patch
> > for the description of the fix.
> 
> I looked at qtwebengine bugs and found two more bugs that would be
> nice to fix for Buster:
> 
> #882805 — Browsers (like Falkon) did not show proper error pages when
> something went wrong (host not found, certificate invalid, etc).
> Instead they showed empty pages with unlabeled and not working
> buttons.
> 
> #887875 aka #944971 — libQt5WebEngineCore.so.5 was requiring
> executable stack for no good reason. This is a potential security
> issue.

Please go ahead.

Regards,

Adam

Bug#947365: transition: libvigraimpex

[Paul Gevers]

Hi Andreas,

On 27-12-2019 18:08, Andreas Metzler wrote:
> On 2019-12-26 Paul Gevers  wrote:
>> On 25-12-2019 19:29, Andreas Metzler wrote:
>>> libvigraimpex is marked for autoremoval because of the python2 removal.
>>> This is fixed in experimental, the new version features a soname bump.
> [...]
>> Normally we don't want python 2 removal package uploads and transitions
>> mixed, but it seems that python-vigra doesn't have reverse dependencies.
>> Please go ahead in unstable.
> 
> Thank you, uploaded.

libvigraimpex is also part of the pseudo python3.8 transition [1], but
it is still red. This probably means that you are not correctly building
Python3 modules for all supported Python3 versions. Can you please check?

Paul

[1] https://release.debian.org/transitions/html/python3.8.html



signature.asc
Description: OpenPGP digital signature

Bug#947795: weston fails to start on one machine.

[Peter Easthope]

Package: weston
Version: 5.0.0-3
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate
***

   * What led up to the situation?

Installed weston on two machines.  Works on one; not on the other.

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

Installed weston, xwayland & etc.  Configured as in the working system.

   * What was the outcome of this action?

weston failed to start.  Display problem on this machine?

   * What outcome did you expect instead?

I expected weston to work as in another machine.

*** End of the template - remove these template lines ***

-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable')
Architecture: i386 (i686)

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

Versions of packages weston depends on:
ii  adduser  3.118
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libcolord2   1.4.3-4
ii  libdrm2  2.4.97-1
ii  libegl1  1.1.0-1
ii  libegl1-mesa 18.3.6-2
ii  libgles2 1.1.0-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libinput10   1.12.6-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3
ii  libpam0g 1.3.1-5
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
ii  libpixman-1-00.36.0-1
ii  libpng16-16  1.6.36-6
ii  libsystemd0  241-7~deb10u2
ii  libwayland-client0   1.16.0-1
ii  libwayland-cursor0   1.16.0-1
ii  libwayland-egl1  1.16.0-1
ii  libwayland-server0   1.16.0-1
ii  libweston-5-05.0.0-3
ii  libxkbcommon0   ed

Versions of packages weston depends on:
ii  adduser  3.118
ii  libc62.28-10
ii  libcairo20.8.2-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packagesed

Versions of packages weston depends on:
ii  adduser  3.118
ii  libc62.28-10
ii  libcairo2weston recommends:
ii  libgl1-mesa-dri  18.3.6-2
ed

Versions of packages weston depends on:
ii  adduser  3.118
ii  libc62.28-10
ii  libcairo2
weston suggests no packages.
ed

Versions of packages weston depends on:
ii  adduser  3.118
ii  libc62.28-10
ii  libcairo2
-- no debconf information


-- 
Tel.: +1 604 670 0140  Bcc: peter at easthope. ca

Bug#927408: new upstream (1.1.0)

[Daniel Baumann]

Hi,

any chance novnc can be updated to the current upstream version?

Regards,
Daniel

Bug#947794: python-apt: autopkgtest fails on deprecation *warnings* to stderr

[Paul Gevers]

Source: python-apt
Version: 1.8.4
Severity: serious
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:python3-defaults

Dear maintainers,

With a recent upload of python3-defaults the autopkgtest of python-apt
fails in testing when that autopkgtest is run with the binary packages
of python3-defaults from unstable. It passes when run with only packages
from testing. In tabular form:
   passfail
python3-defaults   from testing3.7.5-3
python-apt from testing1.8.4
all others from testingfrom testing

I copied some of the output at the bottom of this report. I seems your
test fails only on deprecation *warnings* to stderr. Please, either
disable deprecation warnings in your autopkgtest or allow output to
stderr (the allow-stderr restriction). Autopkgtest is not the place to
catch deprecation warnings.

Currently this regression is blocking the migration of python3-defaults
to testing [1], although we will ignore this failure for this migration.

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

Paul

[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-apt/3809163/log.gz

autopkgtest [04:46:34]: test run-tests: [---
[tests] Running on 2.7.17 (default, Oct 19 2019, 23:36:22) [GCC 9.2.1
20191008]
Using library_dir:
'None'--
Ran 104 tests in 14.284s

OK (skipped=3)
/usr/lib/python3/dist-packages/apt/package.py:484: DeprecationWarning:
PY_SSIZE_T_CLEAN will be required for '#' formats
  return apt_pkg.version_compare(self._cand.ver_str, other.version)
/usr/lib/python3/dist-packages/apt/package.py:401: DeprecationWarning:
PY_SSIZE_T_CLEAN will be required for '#' formats
  self._rec = apt_pkg.TagSection(record_str)
/usr/lib/python3/dist-packages/apt/debfile.py:89: DeprecationWarning:
PY_SSIZE_T_CLEAN will be required for '#' formats
  self._sections = apt_pkg.TagSection(control)
/usr/lib/python3/dist-packages/apt/debfile.py:325: DeprecationWarning:
PY_SSIZE_T_CLEAN will be required for '#' formats
  return apt_pkg.parse_depends(self._sections[key], False)
/usr/lib/python3/dist-packages/apt/debfile.py:338: DeprecationWarning:
PY_SSIZE_T_CLEAN will be required for '#' formats
  apt_pkg.parse_depends(self._sections[key], False))
/usr/lib/python3/dist-packages/apt/debfile.py:349: DeprecationWarning:
PY_SSIZE_T_CLEAN will be required for '#' formats
  return apt_pkg.parse_depends(self._sections[key], False)
/usr/lib/python3/dist-packages/apt/debfile.py:359: DeprecationWarning:
PY_SSIZE_T_CLEAN will be required for '#' formats
  return apt_pkg.parse_depends(self._sections[key], False)
/usr/lib/python3/dist-packages/apt/debfile.py:799: DeprecationWarning:
PY_SSIZE_T_CLEAN will be required for '#' formats
  self._depends.extend(apt_pkg.parse_src_depends(sec[tag]))
/tmp/autopkgtest-lxc.owlmydaz/downtmp/build.h5S/src/tests/test_deps.py:75:
DeprecationWarning: PY_SSIZE_T_CLEAN will be required for '#' formats
  deps = apt_pkg.parse_depends("p1a (<< 1a) | p1b (>> 1b)")
/tmp/autopkgtest-lxc.owlmydaz/downtmp/build.h5S/src/tests/test_deps.py:90:
DeprecationWarning: PY_SSIZE_T_CLEAN will be required for '#' formats
  self.assertEqual("<", apt_pkg.parse_depends("p1 (<< 1)")[0][0][2])
/tmp/autopkgtest-lxc.owlmydaz/downtmp/build.h5S/src/tests/test_deps.py:91:
DeprecationWarning: PY_SSIZE_T_CLEAN will be required for '#' formats
  self.assertEqual("<=", apt_pkg.parse_depends("p1 (< 1)")[0][0][2])
/tmp/autopkgtest-lxc.owlmydaz/downtmp/build.h5S/src/tests/test_deps.py:92:
DeprecationWarning: PY_SSIZE_T_CLEAN will be required for '#' formats
  self.assertEqual("<=", apt_pkg.parse_depends("p1 (<= 1)")[0][0][2])
/tmp/autopkgtest-lxc.owlmydaz/downtmp/build.h5S/src/tests/test_deps.py:93:
DeprecationWarning: PY_SSIZE_T_CLEAN will be required for '#' formats
  self.assertEqual("=", apt_pkg.parse_depends("p1 (= 1)")[0][0][2])
/tmp/autopkgtest-lxc.owlmydaz/downtmp/build.h5S/src/tests/test_deps.py:94:
DeprecationWarning: PY_SSIZE_T_CLEAN will be required for '#' formats
  self.assertEqual(">=", apt_pkg.parse_depends("p1 (>= 1)")[0][0][2])
/tmp/autopkgtest-lxc.owlmydaz/downtmp/build.h5S/src/tests/test_deps.py:95:
DeprecationWarning: PY_SSIZE_T_CLEAN will be required for '#' formats
  self.assertEqual(">=", apt_pkg.parse_depends("p1 (> 1)")[0][0][2])
/tmp/autopkgtest-lxc.owlmydaz/downtmp/build.h5S/src/tests/test_deps.py:96:
DeprecationWarning: PY_SSIZE_T_CLEAN will be required for '#' formats
  self.assertEqual(">", apt_pkg.parse_depends("p1 (>> 1)")[0][0][2])
/tmp/autopkgtest-lxc.owlmydaz/downtmp/build.h5S/src/tests/test_deps.py:67:
DeprecationWarning: PY_SSIZE_T_CLEAN will be required for '#' formats
  deps = apt_pkg.parse_depends("po4a:native", True)

Bug#947793: tkmpeg not working

[Ole Streicher]

Package: tk-mpeg 1.0.7-1
Severity: serious

Tkmpeg does not work and causes saods9 to fail:

Error in startup script: couldn't load file 
"/usr/lib/tcltk/x86_64-linux-gnu/tkmpeg1.0/libtkmpeg1.0.so": 
/usr/lib/tcltk/x86_64-linux-gnu/tkmpeg1.0/libtkmpeg1.0.so: undefined symbol: 
_ZTVSt9basic_iosIcSt11char_traitsIcEE
while executing
"load /usr/lib/tcltk/x86_64-linux-gnu/tkmpeg1.0/libtkmpeg1.0.so tkmpeg"
("package ifneeded tkmpeg 1.0" script)
invoked from within
"package require tkmpeg"
(file "/usr/share/saods9/library/ds9.tcl" line 207)

This is seen in the saods9 CI tests,

https://ci.debian.net/data/autopkgtest/unstable/amd64/s/saods9/3742299/log.gz

No idea what the cause is.

Bug#947790: openscenegraph-3.4: osgPlugins-3.4.1/osgdb_png.so not build on ARM

[Gaetan Allaert]

Package: openscenegraph-3.4
Version: 3.4.1+dfsg1-5
Severity: normal
Tags: patch

Dear Maintainer,

I'm using some components of FlightGear on a Raspberry Pi. FlightGear is using 
OSG to show 3D models
but when the texture of the model uses PNG files, the texture is missing. The 
osgPlugins-3.4.1/osgdb_png.so is
not compiled on ARM due to the flag OSG_CPP_EXCEPTIONS_AVAILABLE:BOOL=OFF. I 
have rebuild OSG
using pbuilder after changing OSG_CPP_EXCEPTIONS_AVAILABLE:BOOL=ON. I am using 
the rebuild OSG without any issue.

What is the reason the remove all plugins containing std::exception from the 
ARM build? Raspbian uses 
a standard GCC 8.3. Is there some kind of incompatibilities between OpenGLES, 
ARM and std::exception?

-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf

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

Versions of packages openscenegraph-3.4 depends on:
ii  freeglut3  2.8.1-3
ii  libc6  2.28-10
ii  libgcc11:8.3.0-6
ii  libgl1 1.1.0-1
ii  libopenscenegraph-3.4-131  3.4.1+dfsg1-5
ii  libopenthreads20   3.2.3+dfsg1-3
ii  libqt5core5a   5.11.3+dfsg1-1+deb10u1
ii  libqt5gui5 5.11.3+dfsg1-1+deb10u1
ii  libqt5widgets5 5.11.3+dfsg1-1+deb10u1
ii  libstdc++6 8.3.0-6

openscenegraph-3.4 recommends no packages.

openscenegraph-3.4 suggests no packages.

-- no debconf information

Bug#947791: radare2: CVE-2019-19590

[Salvatore Bonaccorso]

Source: radare2
Version: 3.2.1+dfsg-5
Severity: important
Tags: security upstream
Forwarded: https://github.com/radareorg/radare2/issues/15543

Hi,

The following vulnerability was published for radare2.

CVE-2019-19590[0]:
| In radare2 through 4.0, there is an integer overflow for the variable
| new_token_size in the function r_asm_massemble at libr/asm/asm.c. This
| integer overflow will result in a Use-After-Free for the buffer
| tokens, which can be filled with arbitrary malicious data after the
| free. This allows remote attackers to cause a denial of service
| (application crash) or possibly execute arbitrary code via crafted
| input.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-19590
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19590
[1] https://github.com/radareorg/radare2/issues/15543

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#917023: CVE-2018-1000825

[Salvatore Bonaccorso]

Hi,

On Fri, Dec 21, 2018 at 04:45:05PM +0100, Moritz Muehlenhoff wrote:
> Package: freecol
> Severity: normal
> Tags: security
> 
> Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000825:
> https://0dd.zone/2018/10/28/freecol-XXE/
> https://github.com/FreeCol/freecol/issues/26

This issue has been fixed upstream with
https://github.com/FreeCol/freecol/commit/8963506897e3270a75b062f28486934bcb79b1e3
.

Regards,
Salvatore

Bug#947789: dh-python: autopkgtest needs update for new version of python3-defaults: doesn't depend on itself

[Paul Gevers]

Source: dh-python
Version: 4.20191017
Severity: serious
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:python3-defaults

[X-Debbugs-CC: debian...@lists.debian.org,
python3-defau...@packages.debian.org]

Dear maintainers,

With a recent upload of python3-defaults the autopkgtest of dh-python
fails in testing when that autopkgtest is run with the binary packages
of python3-defaults from unstable. It passes when run with only packages
from testing. In tabular form:
   passfail
python3-defaults   from testing3.7.5-3
dh-python  from testing4.20191017
all others from testingfrom testing

I copied some of the output at the bottom of this report. It seems that
the autopkgtests of dh-python don't depend on itself when running the
tests against the (not) installed package. You'll know better than I do
why the Python packages stopped depending on dh-python.

Currently this regression is blocking the migration of python3-defaults
to testing [1], although we will ignore this failure for this migration.

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

Paul

[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/d/dh-python/3809157/log.gz

autopkgtest [04:46:25]: test nosetests: [---
Failure: OSError (No such file /usr/share/dh-python/dhpython) ... ERROR

==
ERROR: Failure: OSError (No such file /usr/share/dh-python/dhpython)
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/failure.py", line 42, in runTest
raise self.exc_class(self.exc_val)
OSError: No such file /usr/share/dh-python/dhpython

--
Ran 1 test in 0.001s

FAILED (errors=1)
autopkgtest [04:46:26]: test nosetests: ---]




signature.asc
Description: OpenPGP digital signature

Bug#947706: Updating Debian ports - Debian for PA-RISC

[Alban Vidal]

Hi Dave,

Thanks for your reply.

Le 30/12/2019 à 19:26, John David Anglin a écrit :
> Yes, ESIEE and HP Systems links can be removed.  The HOWTO documents
> are in wiki. 

- The "ESIEE's HOWTO" link removed for the merge request [1],
- For HP links, we have update them toward archive.org.

If all is good for you and for HPPA team, we merge it in the next few days.

Bests regards,
Alban

[1] https://salsa.debian.org/webmaster-team/webwml/merge_requests/325




signature.asc
Description: OpenPGP digital signature

Bug#941657: name change: python-lark-parser -> python-lark

[Peter Wienemann]

Hi Simon,

thanks for your helpful input.

On 30.12.19 18:04, Simon McVittie wrote:
> There are two options:
> 
> * If "lark" on PyPI is a dead project, or otherwise something that is never
>   going to be useful to package in Debian for some reason, then perhaps it's
>   safe for the lark parser to claim the python3-lark name.

The last commit happened six years ago. It might be dead but I am not sure.

> * Otherwise, if its PyPI name is lark-parser, then I would personally
>   recommend asking the upstream developer to rename the module you import
>   to lark_parser (or maybe larkparser if that's preferred), and packaging
>   it as python3-lark-parser (or python3-larkparser), optionally with
>   compatibility glue to make "import lark" continue to work (which might not
>   get packaged in Debian).

I opened a corresponding issue:

https://github.com/lark-parser/lark/issues/505

Peter

Bug#947788: openshot-qt: SIGSEGV crash

[ael]

Package: openshot-qt
Version: 2.4.3+dfsg1-1
Severity: normal

Dear Maintainer,
openshot-qt cannot start but hits a SIGSEGV:

preview_thread:INFO initPlayer
 main_window:ERROR Unhandled crash detected... will attempt to recover
 backup project: /home/ael/.openshot_qt/backup
  main_window:INFO updateStatusChanged
   app:INFO Process command-line arguments:
   ['/usr/bin/openshot-qt']
main_window:INFO recover_backup
project_data:INFO Setting default profile to HDV 720 24p
Caught signal 11 (SIGSEGV)
 Unhandled Exception: Stack Trace 
  /usr/lib/x86_64-linux-gnu/libjsoncpp.so.1 (
  Json::Reader::parse(char const*, char const*,
  Json::Value&, bool)  + 0x132 )  [0x7fdcf8f8b582]
/usr/lib/x86_64-linux-gnu/libjsoncpp.so.1 (
Json::Reader::parse(std::__cxx11::basic_string, std::allocator > const&,
Json::Value&, bool)  + 0x81  )  [0x7fdcf8f8b821]
  /usr/lib/x86_64-linux-gnu/libopenshot.so.16 (
  openshot::Timeline::SetJson(std::__cxx11::basic_string, std::allocator >)  +
  0x7e  )  [0x7fdcfa045a7a]

/usr/lib/python3/dist-packages/_openshot.cpython-37m-x86_64-linux-gnu.so
( + 0x203e1e)
[0x7f0de4097e1e]
  /usr/bin/python3   (
  _PyMethodDescr_FastCallKeywords   + 0x309
  )  [0x4db029]
/usr/bin/python3   (
)  [0x536716]
  /usr/bin/python3   (
  _PyEval_EvalFrameDefault  +
  0x682 )  [0x5394f2]
/usr/bin/python3   (
_PyEval_EvalCodeWithName  +
0xb87 )  [0x537ce7]
  /usr/bin/python3   (
  _PyFunction_FastCallDict
  + 0x34e )  [0x5cafbe]
/usr/bin/python3   (
)  [0x56f39b]
  /usr/bin/python3   (
  _PyObject_FastCallKeywords
  + 0x126 )  [0x5ca526]
/usr/bin/python3   (
)  [0x5367d1]
  /usr/bin/python3   (
  _PyEval_EvalFrameDefault
  + 0x552 )  [0x5393c2]
/usr/bin/python3   (
_PyFunction_FastCallKeywords
+ 0x18b
  /usr/bin/python3   (
  )  [0x536640]
/usr/bin/python3   ( _PyEval_EvalFrameDefault
+ 0x552 )  [0x5393c2]
  /usr/bin/python3   ( _PyEval_EvalCodeWithName
  + 0x247 )  [0x5373a7]
/usr/bin/python3   ( PyEval_EvalCode
+ 0x23  )  [0x64d2a3]
  /usr/bin/python3   (
  )  [0x6409c3]
/usr/bin/python3   ( PyRun_FileExFlags
+ 0x97  )  [0x640a77]
  /usr/bin/python3   ( PyRun_SimpleFileExFlags
  + 0x17a )  [0x64182a]
/usr/bin/python3   (
)  [0x67942f]
  /usr/bin/python3   ( _Py_UnixMain
  + 0x2e  )  [0x67971e]
/lib/x86_64-linux-gnu/libc.so.6 ( __libc_start_main
+ 0xeb  )  [0x7f0de5286bbb]
  /usr/bin/python3   ( _start
  + 0x2a  )  [0x5d030a]
   End of Stack Trace 


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

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

Versions of packages openshot-qt depends on:
ii  fonts-cantarell 0.111-2
ii  libjs-jquery3.3.1~dfsg-3
ii  python3 3.7.5-1
ii  python3-openshot0.2.2+dfsg1-1+b1
ii  python3-pkg-resources   41.2.0-1
ii  python3-pyqt5   5.13.2+dfsg-1
ii  python3-pyqt5.qtsvg 5.13.2+dfsg-1
ii  python3-pyqt5.qtwebkit  5.13.2+dfsg-1
ii  python3-requests2.22.0-2
ii  python3-zmq 17.1.2-4

Versions of packages openshot-qt recommends:
pn  blender   
ii  inkscape  0.92.4-4

Versions of packages openshot-qt suggests:
ii  

Bug#947787: RFS: coinor-cbc/2.10.3+repack1-1 [QA] -- Coin-or branch-and-cut mixed integer programming solver

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "coinor-cbc"

 * Package name: coinor-cbc
   Version : 2.10.3+repack1-1
   Upstream Author :
 * URL : https://projects.coin-or.org/Cbc
 * License : EPL-1
 * Vcs : https://salsa.debian.org/science-team/coinor-cbc
   Section : science

It builds those binary packages:

  coinor-cbc - Coin-or branch-and-cut mixed integer programming solver
  coinor-libcbc3 - Coin-or branch-and-cut mixed integer programming 
solver (shared libraries)
  coinor-libcbc-dev - Coin-or branch-and-cut mixed integer programming 
solver (developer files)
  coinor-libcbc-doc - Coin-or branch-and-cut mixed integer programming 
solver (documentation)


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


  https://mentors.debian.net/package/coinor-cbc

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/coinor-cbc/coinor-cbc_2.10.3+repack1-1.dsc


Changes since the last upload:

   * QA upload
   [ Debian Janitor ]
   * Drop use of autotools-dev debhelper.
   * Update standards version to 4.4.1, no changes needed.
   * Set upstream metadata fields: Bug-Submit.
   * Use secure URI in debian/watch.
 .
   [ Håvard Flaget Aasen ]
   * New upstream version 2.10.3+repack1 closes: #927237
   * Remove patch, fixed upstream.
   * Change to debhelper-compat
   * Add 'repack' in dversionmangle in debian/watch
   * Update build- and runtime-dependencies.
 - remove autotools-dev
 - Update version on dependencies
   * Remove debian/tmp/usr/share/coin from coinor-libcbc-dev.install
   * Use source created jquery.js in *.doc package
   * Fix spelling error i manpage.
   * Add coinor-libcdc-doc.links to symlink duplicates
   * In debian/rules add override_dh_fixperms to fix examples in *.doc 
package.

   * In debian/rules add override_dh_strip to fix static library.


Test-build on amd64, arm64, armel, i386 and ppc64el. No autopkgtest

Regards,
Håvard

Bug#947786: aclock.app: uses 50-100% cpu when started

[Svetlana Tkachenko]

Package: aclock.app
Version: 0.4.0-2+b1
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

I started AClock and it started using 50-100% cpu as seen in htop. I think 
there is a bug in the code and this should not occur.

*** End of the template - remove these template lines ***


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

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

Versions of packages aclock.app depends on:
ii  gnustep-back0.27   0.27.0-2
ii  gnustep-base-runtime   1.26.0-4+deb10u1
ii  gnustep-common [gnustep-fslayout-fhs]  2.7.0-4
ii  gnustep-gui-runtime0.27.0-5
ii  libc6  2.28-10
ii  libgnustep-base1.261.26.0-4+deb10u1
ii  libgnustep-gui0.27 0.27.0-5
ii  libobjc4   8.3.0-6

aclock.app recommends no packages.

aclock.app suggests no packages.

-- no debconf information

Bug#947688: systemd-networkd: Python socket.getfqdn() not working properly when resolv.conf lacks "domain" key

[Michael Biebl]

Am 29.12.19 um 16:00 schrieb Dirk Heinrichs:

>> It probably makes sense to involve upstream at this point and file a
>> corresponding bug report at
>> https://github.com/systemd/systemd/issues
> 
> Wanted to do that first, but it stated: "Bother your distribution if
> your systemd version is more than 2 behind latest upstream.", so I went
> here.

I've uploaded v244 to buster-backports so you should be able to test if
you can still reproduce the problem there.

Regards,
Michael



signature.asc
Description: OpenPGP digital signature

Bug#947785: x2gothinclient: x2go login window should show a blank username field

[Wolfgang Schweer]

Package: x2gothinclient
Version: 1.5.0.1-1
Severity: important

Hi Mike, hi all,

while testing Debian Edu X2Go integration for thin clients I noticed 
that the username field isn't blank after logging out. The username of 
the last user is shown instead. This is supposed to be unwanted.

This change lets the x2go client start again with a clean login screen:

diff --git a/management/share/etc/x2gothinclient-displaymanager_start 
b/management/share/etc/x2gothinclient-displaymanager_start
index bb9fd5e..241b317 100755
--- a/management/share/etc/x2gothinclient-displaymanager_start
+++ b/management/share/etc/x2gothinclient-displaymanager_start
@@ -32,6 +32,7 @@
 --background=/etc/x2go/x2gothinclient-background.svg \
 --no-session-edit \
 --session=X2Go.Example \
+--close-disconnect \
 --add-to-known-hosts &
 
 #/usr/bin/x2goclient --no-menu \
diff --git a/management/share/etc/x2gothinclient-minidesktop_start 
b/management/share/etc/x2gothinclient-minidesktop_start
index 9ee118d..d1bde7b 100755
--- a/management/share/etc/x2gothinclient-minidesktop_start
+++ b/management/share/etc/x2gothinclient-minidesktop_start
@@ -32,6 +32,7 @@
  --read-exports-from=~/export \
  --no-session-edit \
  --session=X2Go.Example \
+ --close-disconnect \
  --add-to-known-hosts
 
 #/usr/libx/x2go/x2goclient --no-menu \

Please check.

Wolfgang


signature.asc
Description: PGP signature

Bug#606825: mingw-w64 triplets/ostable

[Jonathan Nieder]

Hi Stephen,

Stephen Kitt wrote:

> We still need to figure out how to handle the triplet. There are multiple
> goals, from end users’ perspectives, some conflicting:
>
> * provide a Windows cross-compiler with a good selection of libraries, within
>   Debian, so that it’s easy to build Windows programs and their installers;
> * provide a Windows cross-compiler which integrates well with
>   externally-provided libraries;
> * provide a Windows cross-compiler fulfilling the requirements of other
>   Debian packages (this is what got me started down this path: Wine Gecko,
>   Wine Mono, Debian installer components, etc.).

Thanks for this breakdown.  The first sounds like (partial) architecture
bringup, the second is an additional compatibility goal, and the third
could be achieved using multilib but is simpler with multiarch.

If I label these as (a), (b), and (c), then which of these goals is
important to you?  What about others in mingw-w64 and related
projects?

 a. provide a Windows cross-development environment useful for building
non-trivial programs and their installers

 b. provide a Windows cross-compiler that integrates well with
existing externally provided libraries

 c. provide a Windows cross-compiler sufficient to meet the needs of
Debian packages such as wine, mono, and so on

For bringing up a Debian arch, I would expect (a) and (c) to be
important and (b) to not be important at all.  On the other hand, I
wouldn't be surprised if some other people have (b) as a goal, and if
it's easy to get for free then we shouldn't forget about it. :)

[...]
> Guillem has explained in previous emails why -w64-mingw32 causes issues in
> Debian.

Yes, and not only Debian: any system that relies on the notion of ABI
will run into the same problems.

> There are other problems with the triplet which haven’t been
> mentioned so far: mainly, that the same triplet is used for different
> compiler configurations which effectively result in different ABIs. For
> 32-bit targets, there’s DW2 v. SJLJ (64-bit only used SEH); for all targets,
> there’s POSIX v. Win32 threads; a more recent development is support for UCRT
> instead of MSVCRT.

Yes.

> I see two main questions to answer:

For architecture bringup, you left out the most important question of
all: what ABI do you want to use for the new architecture?

Given a choice of ABI and how to name it, it's possible to make
progress within Debian without waiting for upstream.  We'd want to
keep upstream involved every step of the way and to benefit from their
expertise, but part of the magic of having a single project for an
entire operating system distribution is that in the worst case we
*can* go it alone.

In fact I doubt that would be necessary.  Upstream has similar goals.
Picking a triplet without coordinating with upstream would be highly
dangerous unless we stick "debian" in there somewhere (yuck).  I only
mention it as a way to avoid forgetting our responsibilities: if we
aren't able to find the right way to serve these users, in the end we
have no one to blame but ourselves.

Thanks,
Jonathan

Bug#947784: gegl: FTBFS on hurd-i386

[Samuel Thibault]

Source: gegl
Version: 0.4.18-2
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

gegl currently can't build on hurd-i386 because it build-depends on
libv4l-any, which is not built on hurd-i386. Could you apply the
attached patch to fix that?

Thanks,
Samuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldstable-proposed-updates-debug'), (500, 
'oldstable-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.4.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
Accroche-toi au terminal, j'enlève le shell...
 -+- nojhan -+-
--- debian/control.in.original  2019-12-30 09:20:20.0 +
+++ debian/control.in   2019-12-30 09:20:41.0 +
@@ -33,7 +33,7 @@
libsuitesparse-dev,
libswscale-dev,
libtiff5-dev,
-   libv4l-dev,
+   libv4l-dev [!hurd-any],
libwebp-dev (>= 0.5.0),
meson (>= 0.50.0),
pkg-config,
--- debian/control.original 2019-12-30 09:20:20.0 +
+++ debian/control  2019-12-30 09:20:41.0 +
@@ -33,7 +33,7 @@
libsuitesparse-dev,
libswscale-dev,
libtiff5-dev,
-   libv4l-dev,
+   libv4l-dev [!hurd-any],
libwebp-dev (>= 0.5.0),
meson (>= 0.50.0),
pkg-config,

Bug#936387: dfdatetime: diff for NMU version 20190116-1.1

[Sandro Tosi]

Control: tags 936387 + patch
Control: tags 942957 + patch


Dear maintainer,

I've prepared an NMU for dfdatetime (versioned as 20190116-1.1). The diff
is attached to this message.

Regards.

diff -Nru dfdatetime-20190116/debian/changelog dfdatetime-20190116/debian/changelog
--- dfdatetime-20190116/debian/changelog	2019-01-22 06:58:01.0 -0500
+++ dfdatetime-20190116/debian/changelog	2019-12-30 13:04:58.0 -0500
@@ -1,3 +1,10 @@
+dfdatetime (20190116-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #942957, #936387
+
+ -- Sandro Tosi   Mon, 30 Dec 2019 13:04:58 -0500
+
 dfdatetime (20190116-1) unstable; urgency=medium
 
   * New upstream version 20190116
diff -Nru dfdatetime-20190116/debian/control dfdatetime-20190116/debian/control
--- dfdatetime-20190116/debian/control	2019-01-22 06:57:55.0 -0500
+++ dfdatetime-20190116/debian/control	2019-12-30 13:01:44.0 -0500
@@ -4,21 +4,13 @@
 Maintainer: Debian Security Tools 
 Uploaders: Hilko Bengen 
 Build-Depends: debhelper (>= 11), dh-python,
- python, python-setuptools,
  python3, python3-setuptools,
- python-mock, python3-mock,
+ python3-mock,
 Standards-Version: 4.3.0
 Homepage: https://github.com/log2timeline/dfdatetime
 Vcs-Git: https://salsa.debian.org/pkg-security-team/dfdatetime.git
 Vcs-Browser: https://salsa.debian.org/pkg-security-team/dfdatetime
 
-Package: python-dfdatetime
-Architecture: all
-Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends},
-Description: Digital Forensics date and time library for Python 2
- dfDateTime, or Digital Forensics date and time, provides date and
- time objects to preserve accuracy and precision.
-
 Package: python3-dfdatetime
 Architecture: all
 Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends},
diff -Nru dfdatetime-20190116/debian/python3-dfdatetime.install dfdatetime-20190116/debian/python3-dfdatetime.install
--- dfdatetime-20190116/debian/python3-dfdatetime.install	2018-12-21 15:37:44.0 -0500
+++ dfdatetime-20190116/debian/python3-dfdatetime.install	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-/usr/lib/python3*
diff -Nru dfdatetime-20190116/debian/python-dfdatetime.install dfdatetime-20190116/debian/python-dfdatetime.install
--- dfdatetime-20190116/debian/python-dfdatetime.install	2018-12-21 15:37:44.0 -0500
+++ dfdatetime-20190116/debian/python-dfdatetime.install	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-/usr/lib/python2*
diff -Nru dfdatetime-20190116/debian/rules dfdatetime-20190116/debian/rules
--- dfdatetime-20190116/debian/rules	2018-12-26 11:28:50.0 -0500
+++ dfdatetime-20190116/debian/rules	2019-12-30 13:04:58.0 -0500
@@ -13,7 +13,7 @@
 
 # main packaging script based on dh7 syntax
 %:
-	dh $@ --with=python2,python3 --buildsystem=pybuild
+	dh $@ --with=python3 --buildsystem=pybuild
 
 override_dh_missing:
 	dh_missing --fail-missing
@@ -22,5 +22,4 @@
 	dh_install -X/usr/share/doc/
 
 override_dh_auto_test:
-	python run_tests.py
-	python3 run_tests.py
+	PYBUILD_SYSTEM=custom PYBUILD_TEST_ARGS="{interpreter} run_tests.py" dh_auto_test

Bug#947783: Please update smtube to 19.6

[Amr Ibrahim]

Package: smtube

Please update smtube to 19.6.

https://www.smtube.org/en/index

Version 19.6

Fix for YouTube.

Version 18.10

New option in the context menu to play the video with a web browser. The 
web browser may allow you to download the video.

Version 18.9

Fix for YouTube.

Bug#947782: ITP: go-containerregistry -- Go library and CLIs for working with container registries

[James Montgomery]

Package: wnpp
Severity: wishlist
Owner: James Montgomery 

* Package name: go-containerregistry
  Version : 0.0~git20191218.34fb8ff-1
  Upstream Author : Google
* URL : https://github.com/google/go-containerregistry
* License : Apache-2.0
  Programming Lang: Go
  Description : Go library and CLIs for working with container registries

 go-containerregistry Build Status
 (https://travis-ci.org/google/go-containerregistry) GoDoc
 (https://godoc.org/github.com/google/go-containerregistry) Go Report
 Card (https://goreportcard.com/report/google/go-containerregistry)
 Code Coverage (https://codecov.io/gh/google/go-containerregistry)
 Introduction This is a golang library for working with container
 registries.  It's largely based on the Python library of the same name
 (https://github.com/google/containerregistry).
 .
 The following diagram shows the main types that this library handles.
 OCI image representation Tools This repo hosts some tools built on top
 of the library.  crane crane (cmd/crane/doc/crane.md) is a tool for
 interacting with remote images and registries.  Installation
 .
 GO111MODULE=on go get -u github.com/google/go-containerregistry/cmd/crane
 .
 Images You can also use crane as docker image
 .
 ```sh $ docker run --rm gcr.io/go-containerregistry/crane ls ubuntu
 .
 2019/12/03 09:33:01 No matching credentials were found, falling back on
 anonymous 10.04 12.04.5 12.04 12.10 ```
 .
 And it's also available with a shell, which uses the debug tag
 .
 sh docker run --rm -it --entrypoint "/busybox/sh"
 gcr.io/go-containerregistry/crane:debug
 .
 gcrane gcrane (cmd/gcrane/README.md) is a GCR-specific variant of crane
 that has richer output for the ls subcommand and some basic garbage
 collection support.  Installation
 .
 GO111MODULE=on go get -u github.com/google/go-containerregistry/cmd/gcrane
 .
 Images You can also use gcrane as docker image
 .
 ```sh $ docker run --rm gcr.io/go-containerregistry/gcrane ls ubuntu
 .
 2019/12/03 09:33:01 No matching credentials were found, falling back on
 anonymous 10.04 12.04.5 12.04 12.10 ```
 .
 And it's also available with a shell, which uses the debug tag
 .
 sh docker run --rm -it --entrypoint "/busybox/sh"
 gcr.io/go-containerregistry/gcrane:debug
 .
 k8schain k8schain (pkg/authn/k8schain/README.md) implements the
 authentication semantics use by kubelets in a way that is easily
 consumable by this library.
 .
 k8schain is not a standalone tool, but it's linked here
 for visibility.  Debug images for crane and gcrane crane and
 gcrane also provide a debug image (containing a shell), which
 can be found at • gcr.io/go-containerregistry/crane:debug•
 gcr.io/go-containerregistry/gcrane:debug Inside these images, crane and
 gcrane can be used like this:
 .
 sh /ko-app/crane cp ...
 .
 Emeritus: ko (https://github.com/google/ko) This tool was originally
 developed in this repo but has since been moved to its own repo.

Reasoning:
go-containerregistry is a dependency for container-diff 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945524)

Bug#945920: Random Chromium crashes

[Jaap Joris Vens]

Hi Eloston,

Thanks for figuring out the cause of these random crashes! However, I was
unable to recompile chromium from source following your instructions. I got
the following error message at step 4b:

jj@telos:~/src/chromium-79.0.3945.79$ debian/rules get-orig-source
wget -nv --show-progress -c 
https://gsdview.appspot.com/chromium-browser-official/chromium-79.0.3945.79-lite.tar.xz
 -O ../chromium-79.0.3945.79-lite.tar.xz
../chromium-79.0.3945.79-lite 100%[>] 633.92M  10.5MB/sin 70s 
2019-12-30 18:22:47 URL:http://commondatastorage.googleapis.com/chromium-browser-official/chromium-79.0.3945.79-lite.tar.xz [664711308/664711308] -> "../chromium-79.0.3945.79-lite.tar.xz" [1]

cp /usr/share/perl5/Devscripts/MkOrigtargz.pm debian/scripts/mk-origtargz
patch -p1 < debian/scripts/mk-origtargz.patch
patching file debian/scripts/mk-origtargz
date +%s > ../chromium_79.0.3945.79.seconds
perl debian/scripts/mk-origtargz ../chromium-79.0.3945.79-lite.tar.xz > 
../chromium_79.0.3945.79.files-removed
mk-origtargz warn: No files matched excluded pattern as the last matching 
glob: *.elf
mk-origtargz warn: No files matched excluded pattern as the last matching 
glob: *.swf
mk-origtargz warn: No files matched excluded pattern as the last matching 
glob: *.orig
echo $(($(date +%s) - $(cat ../chromium_79.0.3945.79.seconds))) seconds
473 seconds
test ! -e chromium-79.0.3945.79 || rm -rf chromium-79.0.3945.79
tar xf ../chromium-79.0.3945.79-lite.tar.xz
echo $(($(date +%s) - $(cat ../chromium_79.0.3945.79.seconds))) seconds
609 seconds
while read line; do rm -rf $line; done < 
../chromium_79.0.3945.79.files-removed
cd chromium-79.0.3945.79 && ../debian/scripts/check-upstream
realpath: ./third_party/perfetto/ui/src/gen: No such file or directory
symlink links to nothing: ./third_party/perfetto/ui/src/gen ../dist/gen
make: *** [debian/rules:207: get-orig-source] Error 1

Greetings,
JJ

Bug#947038: buster-pu: package libburn/1.5.0-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2019-12-19 at 19:35 +, Steve McIntyre wrote:
> We'd like to add a stable update for libburn to fix an important bug
> in cdrskin. 1.5.0-1 (currently in Buster) currently can't burn
> multi-track audio CDs correctly and instead just spoils/wastes
> media. This was reported by Thomas upstream and I've verified this
> behaviour myself. See #946679, where he's given much more detail
> about the problem.

Please go ahead.

Regards,

Adam

Bug#931242: Acknowledgement (vlc: cannot open files with # in name from playlist)

[Martin Maney]

Package: src:vlc
Version: 3.0.8-0+deb10u1

Still present in Buster (vlc 3.0.8-0+deb10u1).

There are other characters that are mishandled by either the m3u
parsing or the path handling (as the path is built from local names in
the m3u), but apparently I didn't report them as they were discovered
and I have no notes with details.  It was more useful to me to rename
things as I came across them, I'm afraid.  :-/

Bug#947001: [R-pkg-team] Bug#947001: r-base blocked by r-bioc-{iranges, s4vectors}

[Dirk Eddelbuettel]

Just to follow-up here:  As upstream for Rcpp, I just ran another reverse
dependency check againt 1700+ packages on a machine I get to use for that,
and had S4Vectors and IRanges issues pop up for three packages. It looks like
an issue with S4Vectors.

But still: Three. Out of 1700+.

Holding the Rcpp upgrade hostage to this is sub-optimal, to put it mildly. It
is a simple bug in another, orthogonal package.  There happens to be a
package using both.  Yet Rcpp gets shot by shrapnel.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#941657: name change: python-lark-parser -> python-lark

[Simon McVittie]

On Mon, 30 Dec 2019 at 17:15:54 +0100, Peter Wienemann wrote:
> https://bugs.debian.org/945823
> 
> which says:
> 
> "use the name you import in preference to the name from the PKG-INFO".
> 
> That is why I decided to change the name to python-lark. But given the
> PyPI name clash this is certainly not optimal either. So this seems to
> be a particular unfortunate case.

If there are two modules on PyPI, both of which you use via
"import lark", then they cannot both be installed correctly into the
system-wide module search path on the same Debian system - if they
were, even if they happen to avoid having directly conflicting files
(because one is /usr/lib/python3/dist-packages/lark.py and the other is
/usr/lib/python3/dist-packages/lark/__init__.py, or similar), installing
both and using "import lark" would not consistently import the one you
intended to use, leading to broken programs.

So the rule has served its purpose: it has detected a conflict that needs
to be avoided somehow.

For users of virtualenv there is perhaps no problem, because you can
install the lark you wanted in a particular virtualenv and avoid installing
the other lark, but Debian packages are a flat global namespace of modules.

There are two options:

* If "lark" on PyPI is a dead project, or otherwise something that is never
  going to be useful to package in Debian for some reason, then perhaps it's
  safe for the lark parser to claim the python3-lark name.

* Otherwise, if its PyPI name is lark-parser, then I would personally
  recommend asking the upstream developer to rename the module you import
  to lark_parser (or maybe larkparser if that's preferred), and packaging
  it as python3-lark-parser (or python3-larkparser), optionally with
  compatibility glue to make "import lark" continue to work (which might not
  get packaged in Debian).

(I'm talking about binary package names python3-foo because those are the
most important thing for avoiding conflicts, but if the binary package
name is python3-foo then it probably makes most sense for the source
package to be python-foo.)

smcv

Bug#947781: nm.debian.org: flag to always display a process in the AM dashboard

[Mattia Rizzolo]

Package: nm.debian.org
Severity: wishlist

There are some processes that really ought to be kept under close
scrutiny of FD, and therefore would be nice to tick a box and keep that
process in the AM dashboard, overriding the _show_process() check.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#947512: dh-make-golang: allow_unknown_hoster parsing error in make.go

[James Montgomery]

> 
> Patch
> I have attached a patch that fixes GitHub Issue 120 [0] and corrects 
> this issue.
> 
> 

The patch has been merged into master by Anthony Fok. See 
https://github.com/Debian/dh-make-golang/issues/120

Will close once new deb hits unstable.

Bug#941657: name change: python-lark-parser -> python-lark

[Peter Wienemann]

Hi Thomas,

I am including the Python team to tap their expertise.

For those not familiar with the topic: We are referring to

https://github.com/lark-parser/lark

which is not in the Debian archive yet (packaging work is still ongoing).

On 29.12.19 23:10, Thomas Andrejak wrote:
> Why changing the name ? it's named lark-parser in pypi.

>From the beginning I felt uncertain how to call the source package:
python-lark-parser or python-lark.

> Moreover, in pypi, there already is a "lark" module which is not lark-parser

When filing the ITP bug I decided to choose python-lark-parser for
exactly this reason although upstream seems to call its software simply
"Lark" in most places.

Later I became aware of

https://bugs.debian.org/945823

which says:

"use the name you import in preference to the name from the PKG-INFO".

That is why I decided to change the name to python-lark. But given the
PyPI name clash this is certainly not optimal either. So this seems to
be a particular unfortunate case.

Any advice is welcome!

Peter

> Le sam. 28 déc. 2019 à 05:03, Peter Wienemann  > a écrit :
> 
> Following the suggestions in
> 
> https://bugs.debian.org/945823
> 
> I have changed the name from python-lark-parser to python-lark.
> 
> The new repository URL is
> 
> https://salsa.debian.org/python-team/modules/python-lark
> 
> Peter

Bug#947159: hardinfo segfaults when running benchmarks

[Bernhard Übelacker]

Dear Maintainer,
the given backtrace should look like below with debug symbols installed.

For some reason it looks like the strchr at line 281 returns a null pointer.

Kind regards,
Bernhard


(gdb) bt no-filter
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
#1  0x76fc4dae in __GI___strdup (s=0x1 ) at strdup.c:41
#2  0x7471f5b4 in bench_result_benchmarkconf (section, key, values) at 
./modules/benchmark/bench_results.c:281
#3  0x7471fa4d in __benchmark_include_results (r, benchmark, 
order_type) at ./modules/benchmark.c:373
#4  0x7471fd8a in benchmark_include_results (benchmark, result) at 
./modules/benchmark.c:408
#5  callback_bfsh () at ./modules/benchmark/benches.c:33
...
(gdb) display/i $pc
1: x/i $pc
=> 0x76fd5206 <__strlen_sse2+38>:   movdqu (%rax),%xmm4

(gdb) list bench_results.c:281
276 b->legacy = 1;
277
278 /* old old format has prefix before cpu name (ex: 4x 
Pentium...) */
279 nx = nx_prefix(key);
280 if (nx > 0) {
281 b->machine->cpu_name = strdup(strchr(key, 'x') + 1);
282 b->machine->threads = nx;
283 } else {
284 b->machine->cpu_name = strdup(key);
285 b->machine->threads = 1;